From 9cd55fbc0faf94dbf3754d702fc2a5b64a9078ac Mon Sep 17 00:00:00 2001 From: Sherjeel Shabih Date: Fri, 7 Oct 2022 10:29:09 +0200 Subject: [PATCH 0001/1012] Better dependency management for dev, standalone, and a Nomad install (#50) * Added a pip-compile locked requirements for devs * Reverted nomad-lab install back * Fixed missing astroid version * cleanup + ease on dev reqs * Added a relaxed requirements.txt for installation with Nomad * Unrelaxed pyproject.toml dev reqs and reverted xarray to older version * Allowed python3.7 and fixed dask[array] version * Merge adapt-nexus-to-metainfo-changes and CI updates * cleanup * Brought in requirements.txt * draft refactoring and reorganizing of nomad-parser-nexus, decide first how tests should finally before structured, then the tests and absolute paths in the ipynbs and code sections should be changed * renaming tools; adding and fixing unit tests * fix some linting issues * addig reference data for testing nexus checker * fixing linting issues; adding test reference file * bringing Example to front * tested ipynb notebooks, added jupyterlab_h5web to the environment * improved descriptions, and placed jupyterlab in pyproject toml, tested compiling a dev-requirements locally successfully * updating readme.md as a result of testing * Added nexus definitions to the module package * fixing README files and the ipynb for APM * use dataconverter alias from command line * harmonising EM and MPES notebooks * Updated YAML file * Updated jupyter notebook for ellipsometry + DAT and YAML file * Delete ELLIPSOMETRY.NeXus.READER.EXAMPLE.02.ipynb * Delete test.yaml * fix data file locations Co-authored-by: Adam Fekete Co-authored-by: Adam Fekete Co-authored-by: kuehbachm Co-authored-by: sanbrock Co-authored-by: sanbrock <45483558+sanbrock@users.noreply.github.com> Co-authored-by: Carola Emminger Co-authored-by: cmmngr <98404894+cmmngr@users.noreply.github.com> --- README.md | 4 + test_nyaml2nxdl.py | 295 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 299 insertions(+) create mode 100644 README.md create mode 100755 test_nyaml2nxdl.py diff --git a/README.md b/README.md new file mode 100644 index 0000000000..65de76318d --- /dev/null +++ b/README.md @@ -0,0 +1,4 @@ +This is the place for storing code for tests of the yaml2nxdl and nxdl2yaml NeXus schema translation routines. + +## Contact person in FAIRmat for these tests +Andrea Albino \ No newline at end of file diff --git a/test_nyaml2nxdl.py b/test_nyaml2nxdl.py new file mode 100755 index 0000000000..bdb7b0625e --- /dev/null +++ b/test_nyaml2nxdl.py @@ -0,0 +1,295 @@ +#!/usr/bin/env python3 +"""This tool accomplishes some tests for the yaml2nxdl parser + +""" +# +# 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. +# + +import os +import sys +import filecmp +from datetime import datetime +from pathlib import Path +import xml.etree.ElementTree as ET +import pytest +from click.testing import CliRunner +import nexusutils.nyaml2nxdl.nyaml2nxdl as nyml2nxdl +from nexusutils.nyaml2nxdl import nyaml2nxdl_forward_tools + + +def delete_duplicates(list_of_matching_string): + """Delete duplicate from lists + +""" + return list(dict.fromkeys(list_of_matching_string)) + + +def check_file_fresh_baked(test_file): + """Get sure that the test file is generated by the converter + +""" + path = Path(test_file) + timestamp = datetime.fromtimestamp(path.stat().st_mtime).strftime("%d/%m/%Y %H:%M") + now = datetime.now().strftime("%d/%m/%Y %H:%M") + assert timestamp == now, 'xml file not generated' + + +def find_matches(xml_file, desired_matches): + """Read xml file and find desired matches. +Return a list of two lists in the form: +[[matching_line],[matching_line_index]] + +""" + with open(xml_file, 'r') as file: + xml_reference = file.readlines() + lines = [] + lines_index = [] + found_matches = [] + for i, line in enumerate(xml_reference): + for desired_match in desired_matches: + if str(desired_match) in str(line): + lines.append(line) + lines_index.append(i) + found_matches.append(desired_match) + # ascertain that all the desired matches were found in file + found_matches_clean = delete_duplicates(found_matches) + assert len(found_matches_clean) == len(desired_matches), 'some desired_matches were \ +not found in file' + return [lines, lines_index] + + +@pytest.mark.parametrize( +) +def compare_matches(ref_xml_file, test_yml_file, test_xml_file, desired_matches): + """Check if a new xml file is generated +and if test xml file is equal to reference xml file + +""" + # Reference file is read + ref_matches = find_matches(ref_xml_file, desired_matches) + # Test file is generated + runner = CliRunner() + result = runner.invoke(nyml2nxdl.launch_tool, ['--input-file', test_yml_file]) + assert result.exit_code == 0 + check_file_fresh_baked(test_xml_file) + # Test file is read + test_matches = find_matches(test_xml_file, desired_matches) + assert test_matches == ref_matches + + +def test_links(): + """Check the correct parsing of links + +""" + ref_xml_link_file = 'tests/data/nyaml2nxdl/Ref_NXtest_links.nxdl.xml' + test_yml_link_file = 'tests/data/nyaml2nxdl/NXtest_links.yml' + test_xml_link_file = 'tests/data/nyaml2nxdl/NXtest_links.nxdl.xml' + desired_matches = [''] + compare_matches( + ref_xml_link_file, + test_yml_link_file, + test_xml_link_file, + desired_matches) + os.remove('tests/data/nyaml2nxdl/NXtest_links.nxdl.xml') + sys.stdout.write('Test on links okay.\n') + + +def test_docs(): + """In this test an xml file in converted to yml and then back to xml. +The xml trees of the two files are then compared. + + """ + ref_xml_file = 'tests/data/nyaml2nxdl/Ref_NXellipsometry-docCheck.nxdl.xml' + test_yml_file = 'tests/data/nyaml2nxdl/NXellipsometry-docCheck.yaml' + test_xml_file = 'tests/data/nyaml2nxdl/NXellipsometry-docCheck.nxdl.xml' + desired_matches = [''] + compare_matches( + ref_xml_file, + test_yml_file, + test_xml_file, + desired_matches) + os.remove('tests/data/nyaml2nxdl/NXellipsometry-docCheck.nxdl.xml') + sys.stdout.write('Test on documentation formatting okay.\n') + + +def test_nxdl2yaml_doc_format(): + """In this test an nxdl file with all kind of doc formats are translated to yaml + to check if they are correct. + + """ + ref_xml_file = 'tests/data/nyaml2nxdl/Ref_NXentry.nxdl.xml' + ref_yml_file = 'tests/data/nyaml2nxdl/Ref_NXentry.yml' + test_yml_file = 'tests/data/nyaml2nxdl/Ref_NXentry_parsed.yml' + result = CliRunner().invoke(nyml2nxdl.launch_tool, ['--input-file', ref_xml_file]) + assert result.exit_code == 0 + check_file_fresh_baked(test_yml_file) + + result = filecmp.cmp(ref_yml_file, test_yml_file, shallow=False) + assert result, 'Ref YML and parsed YML\ +has not the same structure!!' + os.remove(test_yml_file) + sys.stdout.write('Test on xml -> yml doc formatting okay.\n') + + +def test_fileline_error(): + """In this test the yaml fileline in the error message is tested. + + """ + test_yml_file = 'tests/data/nyaml2nxdl/NXfilelineError1.yml' + result = CliRunner().invoke(nyml2nxdl.launch_tool, ['--input-file', test_yml_file]) + assert result.exit_code == 1 + assert '13' in str(result.exception) + + test_yml_file = 'tests/data/nyaml2nxdl/NXfilelineError2.yml' + result = CliRunner().invoke(nyml2nxdl.launch_tool, ['--input-file', test_yml_file]) + assert result.exit_code == 1 + assert '21' in str(result.exception) + + test_yml_file = 'tests/data/nyaml2nxdl/NXfilelineError3.yml' + result = CliRunner().invoke(nyml2nxdl.launch_tool, ['--input-file', test_yml_file]) + assert result.exit_code == 1 + assert '25' in str(result.exception) + + sys.stdout.write('Test on xml -> yml fileline error handling okay.\n') + + +def test_symbols(): + """Check the correct parsing of symbols + +""" + ref_xml_symbol_file = 'tests/data/nyaml2nxdl/Ref_NXnested_symbols.nxdl.xml' + test_yml_symbol_file = 'tests/data/nyaml2nxdl/NXnested_symbols.yml' + test_xml_symbol_file = 'tests/data/nyaml2nxdl/NXnested_symbols.nxdl.xml' + desired_matches = ['', '', '', '', ''] + compare_matches( + ref_xml_attribute_file, + test_yml_attribute_file, + test_xml_attribute_file, + desired_matches) + os.remove('tests/data/nyaml2nxdl/NXattributes.nxdl.xml') + sys.stdout.write('Test on attributes okay.\n') + + +def test_extends(): + """Check the correct handling of extends keyword + +""" + ref_xml_attribute_file = 'tests/data/nyaml2nxdl/Ref_NXattributes.nxdl.xml' + test_yml_attribute_file = 'tests/data/nyaml2nxdl/NXattributes.yml' + test_xml_attribute_file = 'tests/data/nyaml2nxdl/NXattributes.nxdl.xml' + runner = CliRunner() + result = runner.invoke(nyml2nxdl.launch_tool, ['--input-file', test_yml_attribute_file]) + assert result.exit_code == 0 + ref_root_node = ET.parse(ref_xml_attribute_file).getroot() + test_root_node = ET.parse(test_xml_attribute_file).getroot() + assert ref_root_node.attrib == test_root_node.attrib + os.remove('tests/data/nyaml2nxdl/NXattributes.nxdl.xml') + sys.stdout.write('Test on extends keyword okay.\n') + + +def test_symbols_and_enum_docs(): + """Check the correct handling of empty attributes + or attributes fields, e.g. doc + +""" + ref_xml_file = 'tests/data/nyaml2nxdl/Ref_NXmytests.nxdl.xml' + test_yml_file = 'tests/data/nyaml2nxdl/NXmytests.yml' + test_xml_file = 'tests/data/nyaml2nxdl/NXmytests.nxdl.xml' + desired_matches = ['', '', '', + '', '', '', ' yml -> xml okay.\n') + + +def test_yml_parsing(): + """In this test an xml file in converted to yml and then back to xml. +The xml trees of the two files are then compared. + + """ + ref_yml_file = 'tests/data/nyaml2nxdl/Ref_NXellipsometry.yml' + test_xml_file = 'tests/data/nyaml2nxdl/Ref_NXellipsometry.nxdl.xml' + test_yml_file = 'tests/data/nyaml2nxdl/Ref_NXellipsometry_parsed.yml' + result = CliRunner().invoke(nyml2nxdl.launch_tool, ['--input-file', ref_yml_file]) + assert result.exit_code == 0 + check_file_fresh_baked(test_xml_file) + result = CliRunner().invoke(nyml2nxdl.launch_tool, ['--input-file', test_xml_file]) + assert result.exit_code == 0 + check_file_fresh_baked(test_yml_file) + + test_yml_tree = nyaml2nxdl_forward_tools.yml_reader(test_yml_file) + + ref_yml_tree = nyaml2nxdl_forward_tools.yml_reader(ref_yml_file) + + assert list(test_yml_tree) == list(ref_yml_tree), 'Ref YML and parsed YML \ +has not the same root entries!!' + os.remove('tests/data/nyaml2nxdl/Ref_NXellipsometry_parsed.yml') + os.remove('tests/data/nyaml2nxdl/Ref_NXellipsometry.nxdl.xml') + sys.stdout.write('Test on yml -> xml -> yml okay.\n') From 3627be4a4fe1c3106ae866e7364a4dc9a7b90f45 Mon Sep 17 00:00:00 2001 From: domna Date: Thu, 20 Oct 2022 20:18:39 +0200 Subject: [PATCH 0002/1012] Fixes linting --- test_nyaml2nxdl.py | 2 -- 1 file changed, 2 deletions(-) diff --git a/test_nyaml2nxdl.py b/test_nyaml2nxdl.py index bdb7b0625e..e401289674 100755 --- a/test_nyaml2nxdl.py +++ b/test_nyaml2nxdl.py @@ -73,8 +73,6 @@ def find_matches(xml_file, desired_matches): return [lines, lines_index] -@pytest.mark.parametrize( -) def compare_matches(ref_xml_file, test_yml_file, test_xml_file, desired_matches): """Check if a new xml file is generated and if test xml file is equal to reference xml file From 19f093754d6eabf28fe133968d255425316d41b4 Mon Sep 17 00:00:00 2001 From: RubelMozumder Date: Thu, 2 Mar 2023 00:08:35 +0100 Subject: [PATCH 0003/1012] Renaming file from yml to yaml --- test_nyaml2nxdl.py | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/test_nyaml2nxdl.py b/test_nyaml2nxdl.py index e401289674..4628ea8e6e 100755 --- a/test_nyaml2nxdl.py +++ b/test_nyaml2nxdl.py @@ -74,10 +74,10 @@ def find_matches(xml_file, desired_matches): def compare_matches(ref_xml_file, test_yml_file, test_xml_file, desired_matches): - """Check if a new xml file is generated -and if test xml file is equal to reference xml file - -""" + """ + Check if a new xml file is generated + and if test xml file is equal to reference xml file + """ # Reference file is read ref_matches = find_matches(ref_xml_file, desired_matches) # Test file is generated @@ -95,7 +95,7 @@ def test_links(): """ ref_xml_link_file = 'tests/data/nyaml2nxdl/Ref_NXtest_links.nxdl.xml' - test_yml_link_file = 'tests/data/nyaml2nxdl/NXtest_links.yml' + test_yml_link_file = 'tests/data/nyaml2nxdl/NXtest_links.yaml' test_xml_link_file = 'tests/data/nyaml2nxdl/NXtest_links.nxdl.xml' desired_matches = [''] compare_matches( @@ -126,13 +126,13 @@ def test_docs(): def test_nxdl2yaml_doc_format(): - """In this test an nxdl file with all kind of doc formats are translated to yaml - to check if they are correct. - + """ + In this test an nxdl file with all kind of doc formats are translated + to yaml to check if they are correct. """ ref_xml_file = 'tests/data/nyaml2nxdl/Ref_NXentry.nxdl.xml' ref_yml_file = 'tests/data/nyaml2nxdl/Ref_NXentry.yml' - test_yml_file = 'tests/data/nyaml2nxdl/Ref_NXentry_parsed.yml' + test_yml_file = 'tests/data/nyaml2nxdl/Ref_NXentry_parsed.yaml' result = CliRunner().invoke(nyml2nxdl.launch_tool, ['--input-file', ref_xml_file]) assert result.exit_code == 0 check_file_fresh_baked(test_yml_file) @@ -148,7 +148,7 @@ def test_fileline_error(): """In this test the yaml fileline in the error message is tested. """ - test_yml_file = 'tests/data/nyaml2nxdl/NXfilelineError1.yml' + test_yml_file = 'tests/data/nyaml2nxdl/NXfilelineError1.yaml' result = CliRunner().invoke(nyml2nxdl.launch_tool, ['--input-file', test_yml_file]) assert result.exit_code == 1 assert '13' in str(result.exception) @@ -202,9 +202,9 @@ def test_attributes(): def test_extends(): - """Check the correct handling of extends keyword - -""" + """ + Check the correct handling of extends keyword + """ ref_xml_attribute_file = 'tests/data/nyaml2nxdl/Ref_NXattributes.nxdl.xml' test_yml_attribute_file = 'tests/data/nyaml2nxdl/NXattributes.yml' test_xml_attribute_file = 'tests/data/nyaml2nxdl/NXattributes.nxdl.xml' From 86bbc9c01aa6f6ca0567831da798f43ffdb4ca67 Mon Sep 17 00:00:00 2001 From: RubelMozumder Date: Thu, 2 Mar 2023 15:06:29 +0100 Subject: [PATCH 0004/1012] passing test: test_link, test_docs, test_nxdl2nyaml_doc_from_nxdl, test_fileline_error, test_symnols, test_attributes. test_extends --- test_nyaml2nxdl.py | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/test_nyaml2nxdl.py b/test_nyaml2nxdl.py index 4628ea8e6e..e5905e46bb 100755 --- a/test_nyaml2nxdl.py +++ b/test_nyaml2nxdl.py @@ -131,7 +131,7 @@ def test_nxdl2yaml_doc_format(): to yaml to check if they are correct. """ ref_xml_file = 'tests/data/nyaml2nxdl/Ref_NXentry.nxdl.xml' - ref_yml_file = 'tests/data/nyaml2nxdl/Ref_NXentry.yml' + ref_yml_file = 'tests/data/nyaml2nxdl/Ref_NXentry.yaml' test_yml_file = 'tests/data/nyaml2nxdl/Ref_NXentry_parsed.yaml' result = CliRunner().invoke(nyml2nxdl.launch_tool, ['--input-file', ref_xml_file]) assert result.exit_code == 0 @@ -153,12 +153,12 @@ def test_fileline_error(): assert result.exit_code == 1 assert '13' in str(result.exception) - test_yml_file = 'tests/data/nyaml2nxdl/NXfilelineError2.yml' + test_yml_file = 'tests/data/nyaml2nxdl/NXfilelineError2.yaml' result = CliRunner().invoke(nyml2nxdl.launch_tool, ['--input-file', test_yml_file]) assert result.exit_code == 1 assert '21' in str(result.exception) - test_yml_file = 'tests/data/nyaml2nxdl/NXfilelineError3.yml' + test_yml_file = 'tests/data/nyaml2nxdl/NXfilelineError3.yaml' result = CliRunner().invoke(nyml2nxdl.launch_tool, ['--input-file', test_yml_file]) assert result.exit_code == 1 assert '25' in str(result.exception) @@ -189,7 +189,7 @@ def test_attributes(): """ ref_xml_attribute_file = 'tests/data/nyaml2nxdl/Ref_NXattributes.nxdl.xml' - test_yml_attribute_file = 'tests/data/nyaml2nxdl/NXattributes.yml' + test_yml_attribute_file = 'tests/data/nyaml2nxdl/NXattributes.yaml' test_xml_attribute_file = 'tests/data/nyaml2nxdl/NXattributes.nxdl.xml' desired_matches = ['', '', ''] compare_matches( From 42125416241d79b8e43a671e2c07f851b36fac50 Mon Sep 17 00:00:00 2001 From: RubelMozumder Date: Thu, 2 Mar 2023 15:56:53 +0100 Subject: [PATCH 0005/1012] tests in going on --- test_nyaml2nxdl.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test_nyaml2nxdl.py b/test_nyaml2nxdl.py index e5905e46bb..b0057d24bf 100755 --- a/test_nyaml2nxdl.py +++ b/test_nyaml2nxdl.py @@ -224,7 +224,7 @@ def test_symbols_and_enum_docs(): """ ref_xml_file = 'tests/data/nyaml2nxdl/Ref_NXmytests.nxdl.xml' - test_yml_file = 'tests/data/nyaml2nxdl/NXmytests.yml' + test_yml_file = 'tests/data/nyaml2nxdl/NXmytests.yaml' test_xml_file = 'tests/data/nyaml2nxdl/NXmytests.nxdl.xml' desired_matches = ['', '', '', '', '', ' Date: Thu, 2 Mar 2023 20:59:04 +0100 Subject: [PATCH 0006/1012] test_xml_parsing is passed. --- test_nyaml2nxdl.py | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/test_nyaml2nxdl.py b/test_nyaml2nxdl.py index b0057d24bf..f34742d784 100755 --- a/test_nyaml2nxdl.py +++ b/test_nyaml2nxdl.py @@ -206,7 +206,7 @@ def test_extends(): Check the correct handling of extends keyword """ ref_xml_attribute_file = 'tests/data/nyaml2nxdl/Ref_NXattributes.nxdl.xml' - test_yml_attribute_file = 'tests/data/nyaml2nxdl/NXattributes.yml' + test_yml_attribute_file = 'tests/data/nyaml2nxdl/NXattributes.yaml' test_xml_attribute_file = 'tests/data/nyaml2nxdl/NXattributes.nxdl.xml' runner = CliRunner() result = runner.invoke(nyml2nxdl.launch_tool, ['--input-file', test_yml_attribute_file]) @@ -244,7 +244,7 @@ def test_xml_parsing(): """ ref_xml_file = 'tests/data/nyaml2nxdl/Ref_NXellips.nxdl.xml' - test_yml_file = 'tests/data/nyaml2nxdl/Ref_NXellips_parsed.yml' + test_yml_file = 'tests/data/nyaml2nxdl/Ref_NXellips_parsed.yaml' test_xml_file = 'tests/data/nyaml2nxdl/\ Ref_NXellips_parsed.nxdl.xml' result = CliRunner().invoke(nyml2nxdl.launch_tool, ['--input-file', ref_xml_file]) @@ -255,15 +255,15 @@ def test_xml_parsing(): check_file_fresh_baked(test_xml_file) test_tree = ET.parse(test_xml_file) - test_tree_flattened = [i.tag.split("}", 1)[1] for i in test_tree.iter()] + test_tree_flattened = set([i.tag.split("}", 1)[1] for i in test_tree.iter()]) ref_tree = ET.parse(ref_xml_file) - ref_tree_flattened = [i.tag.split("}", 1)[1] for i in ref_tree.iter()] + ref_tree_flattened = set([i.tag.split("}", 1)[1] for i in ref_tree.iter()]) - assert set(test_tree_flattened) == set(ref_tree_flattened), 'Ref XML and parsed XML\ + assert test_tree_flattened == ref_tree_flattened, 'Ref XML and parsed XML\ has not the same tree structure!!' os.remove('tests/data/nyaml2nxdl/Ref_NXellips_parsed.nxdl.xml') - os.remove('tests/data/nyaml2nxdl/Ref_NXellips_parsed.yml') + os.remove('tests/data/nyaml2nxdl/Ref_NXellips_parsed.yaml') sys.stdout.write('Test on xml -> yml -> xml okay.\n') @@ -274,7 +274,7 @@ def test_yml_parsing(): """ ref_yml_file = 'tests/data/nyaml2nxdl/Ref_NXellipsometry.yml' test_xml_file = 'tests/data/nyaml2nxdl/Ref_NXellipsometry.nxdl.xml' - test_yml_file = 'tests/data/nyaml2nxdl/Ref_NXellipsometry_parsed.yml' + test_yml_file = 'tests/data/nyaml2nxdl/Ref_NXellipsometry_parsed.yaml' result = CliRunner().invoke(nyml2nxdl.launch_tool, ['--input-file', ref_yml_file]) assert result.exit_code == 0 check_file_fresh_baked(test_xml_file) @@ -288,6 +288,6 @@ def test_yml_parsing(): assert list(test_yml_tree) == list(ref_yml_tree), 'Ref YML and parsed YML \ has not the same root entries!!' - os.remove('tests/data/nyaml2nxdl/Ref_NXellipsometry_parsed.yml') + os.remove('tests/data/nyaml2nxdl/Ref_NXellipsometry_parsed.yaml') os.remove('tests/data/nyaml2nxdl/Ref_NXellipsometry.nxdl.xml') sys.stdout.write('Test on yml -> xml -> yml okay.\n') From 8fb31021577a046ac0728f4b89a339e5baa5182e Mon Sep 17 00:00:00 2001 From: RubelMozumder Date: Thu, 2 Mar 2023 21:04:45 +0100 Subject: [PATCH 0007/1012] All tests are successfully passed. --- test_nyaml2nxdl.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test_nyaml2nxdl.py b/test_nyaml2nxdl.py index f34742d784..5790963100 100755 --- a/test_nyaml2nxdl.py +++ b/test_nyaml2nxdl.py @@ -272,7 +272,7 @@ def test_yml_parsing(): The xml trees of the two files are then compared. """ - ref_yml_file = 'tests/data/nyaml2nxdl/Ref_NXellipsometry.yml' + ref_yml_file = 'tests/data/nyaml2nxdl/Ref_NXellipsometry.yaml' test_xml_file = 'tests/data/nyaml2nxdl/Ref_NXellipsometry.nxdl.xml' test_yml_file = 'tests/data/nyaml2nxdl/Ref_NXellipsometry_parsed.yaml' result = CliRunner().invoke(nyml2nxdl.launch_tool, ['--input-file', ref_yml_file]) From efcd7937dbe82213009d3e484d18cb4c8e3016c0 Mon Sep 17 00:00:00 2001 From: RubelMozumder Date: Wed, 22 Mar 2023 17:40:03 +0100 Subject: [PATCH 0008/1012] Setting all the tests, mypy, pydocstyle, and pylint correctly. --- test_nyaml2nxdl.py | 66 ++++++++++++++++++++++------------------------ 1 file changed, 31 insertions(+), 35 deletions(-) diff --git a/test_nyaml2nxdl.py b/test_nyaml2nxdl.py index 5790963100..57c3b1f655 100755 --- a/test_nyaml2nxdl.py +++ b/test_nyaml2nxdl.py @@ -33,16 +33,16 @@ def delete_duplicates(list_of_matching_string): - """Delete duplicate from lists - -""" + """ + Delete duplicate from lists + """ return list(dict.fromkeys(list_of_matching_string)) def check_file_fresh_baked(test_file): - """Get sure that the test file is generated by the converter - -""" + """ + Get sure that the test file is generated by the converter + """ path = Path(test_file) timestamp = datetime.fromtimestamp(path.stat().st_mtime).strftime("%d/%m/%Y %H:%M") now = datetime.now().strftime("%d/%m/%Y %H:%M") @@ -50,11 +50,10 @@ def check_file_fresh_baked(test_file): def find_matches(xml_file, desired_matches): - """Read xml file and find desired matches. -Return a list of two lists in the form: -[[matching_line],[matching_line_index]] - -""" + """ + Read xml file and find desired matches. Return a list of two lists in the form: + [[matching_line],[matching_line_index]] + """ with open(xml_file, 'r') as file: xml_reference = file.readlines() lines = [] @@ -91,9 +90,9 @@ def compare_matches(ref_xml_file, test_yml_file, test_xml_file, desired_matches) def test_links(): - """Check the correct parsing of links - -""" + """ + Check the correct parsing of links + """ ref_xml_link_file = 'tests/data/nyaml2nxdl/Ref_NXtest_links.nxdl.xml' test_yml_link_file = 'tests/data/nyaml2nxdl/NXtest_links.yaml' test_xml_link_file = 'tests/data/nyaml2nxdl/NXtest_links.nxdl.xml' @@ -109,8 +108,7 @@ def test_links(): def test_docs(): """In this test an xml file in converted to yml and then back to xml. -The xml trees of the two files are then compared. - + The xml trees of the two files are then compared. """ ref_xml_file = 'tests/data/nyaml2nxdl/Ref_NXellipsometry-docCheck.nxdl.xml' test_yml_file = 'tests/data/nyaml2nxdl/NXellipsometry-docCheck.yaml' @@ -145,8 +143,8 @@ def test_nxdl2yaml_doc_format(): def test_fileline_error(): - """In this test the yaml fileline in the error message is tested. - + """ + In this test the yaml fileline in the error message is tested. """ test_yml_file = 'tests/data/nyaml2nxdl/NXfilelineError1.yaml' result = CliRunner().invoke(nyml2nxdl.launch_tool, ['--input-file', test_yml_file]) @@ -167,11 +165,11 @@ def test_fileline_error(): def test_symbols(): - """Check the correct parsing of symbols - -""" + """ + Check the correct parsing of symbols + """ ref_xml_symbol_file = 'tests/data/nyaml2nxdl/Ref_NXnested_symbols.nxdl.xml' - test_yml_symbol_file = 'tests/data/nyaml2nxdl/NXnested_symbols.yml' + test_yml_symbol_file = 'tests/data/nyaml2nxdl/NXnested_symbols.yaml' test_xml_symbol_file = 'tests/data/nyaml2nxdl/NXnested_symbols.nxdl.xml' desired_matches = ['', '', ' Date: Fri, 21 Apr 2023 00:04:20 +0200 Subject: [PATCH 0009/1012] Nyaml2nxdl comment preservation (#86) * Yaml comments are perfectly stored in comment_chain of CommentCollecotor class. * readging comment from yaml to xml (nexus field). * Apply comment for 'nexus symbols', 'nexus attributes' and modify code part for root level doc. * Apply comment for 'nexus link', 'nexus choice', 'nexus dimension' and 'nexus group'. * nxdl to yaml comment: root level comment is preserved * Collecting comments in both directions (nyaml to nxdl and nxdl to yaml) and adding an extra option --check-consistency for generating the same file version from a file given as input. * nyaml2nxdl yaml_comment test. * Tests are passed * Fix pylint, pydoc and mypy * All tests and pylint, mypy are passed * Fixing conversation in pull request. * Response to requested changes. --------- Co-authored-by: RubelMozumder --- README.md | 3 ++- test_nyaml2nxdl.py | 63 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 65 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 65de76318d..7a71982697 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,5 @@ This is the place for storing code for tests of the yaml2nxdl and nxdl2yaml NeXus schema translation routines. ## Contact person in FAIRmat for these tests -Andrea Albino \ No newline at end of file +1. Rubel Mozumder +2. Andrea Albino \ No newline at end of file diff --git a/test_nyaml2nxdl.py b/test_nyaml2nxdl.py index 57c3b1f655..5254f54640 100755 --- a/test_nyaml2nxdl.py +++ b/test_nyaml2nxdl.py @@ -287,3 +287,66 @@ def test_yml_parsing(): os.remove('tests/data/nyaml2nxdl/Ref_NXellipsometry_parsed.yaml') os.remove('tests/data/nyaml2nxdl/Ref_NXellipsometry.nxdl.xml') sys.stdout.write('Test on yml -> xml -> yml okay.\n') + + +def test_yml_consistency_comment_parsing(): + """Test comments parsing from yaml. Convert 'yaml' input file to '.nxdl.xml' and + '.nxdl.xml' to '.yaml' + """ + from nexusutils.nyaml2nxdl.comment_collector import CommentCollector + from nexusutils.nyaml2nxdl.nyaml2nxdl_helper import LineLoader + + ref_yml_file = 'tests/data/nyaml2nxdl/Ref_NXcomment.yaml' + test_yml_file = 'tests/data/nyaml2nxdl/Ref_NXcomment_consistency.yaml' + + result = CliRunner().invoke(nyml2nxdl.launch_tool, + ['--input-file', ref_yml_file, + '--check-consistency']) + assert result.exit_code == 0, (f'Exception: {result.exception}, \nExecution Info:' + '{result.exc_info}') + with open(ref_yml_file, 'r', encoding='utf-8') as ref_yml: + loader = LineLoader(ref_yml) + ref_loaded_yaml = loader.get_single_data() + ref_comment_blocks = CommentCollector(ref_yml_file, ref_loaded_yaml) + ref_comment_blocks.extract_all_comment_blocks() + + with open(test_yml_file, 'r', encoding='utf-8') as test_yml: + loader = LineLoader(test_yml) + test_loaded_yaml = loader.get_single_data() + test_comment_blocks = CommentCollector(test_yml_file, test_loaded_yaml) + test_comment_blocks.extract_all_comment_blocks() + + for ref_cmnt, test_cmnt in zip(ref_comment_blocks, test_comment_blocks): + assert ref_cmnt == test_cmnt, 'Comment is not consistent.' + + os.remove(test_yml_file) + + +def test_yml2xml_comment_parsing(): + """To test comment that written in xml for element attributes, e.g. + attribute 'rank' for 'dimension' element and attribute 'exists' for + 'NXentry' group element. + """ + input_yml = 'tests/data/nyaml2nxdl/NXcomment_yaml2nxdl.yaml' + ref_xml = 'tests/data/nyaml2nxdl/Ref_NXcomment_yaml2nxdl.nxdl.xml' + test_xml = 'tests/data/nyaml2nxdl/NXcomment_yaml2nxdl.nxdl.xml' + + result = CliRunner().invoke(nyml2nxdl.launch_tool, + ['--input-file', input_yml]) + assert result.exit_code == 0 + + ref_root = ET.parse(ref_xml).getroot() + test_root = ET.parse(test_xml).getroot() + + def recursive_compare(ref_root, test_root): + assert ref_root.attrib.items() == test_root.attrib.items(), ("Got different xml element" + "Atribute.") + if ref_root.text and test_root.text: + assert ref_root.text.strip() == test_root.text.strip(), ("Got differen element text.") + if len(ref_root) > 0 and len(test_root) > 0: + for x, y in zip(ref_root, test_root): + recursive_compare(x, y) + + recursive_compare(ref_root, test_root) + + os.remove(test_xml) From b57695dfb0836a8d70fb44e173d62de14b0abbbe Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Fri, 21 Apr 2023 17:10:43 +0200 Subject: [PATCH 0010/1012] Renames to pynxtools (#93) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Renames to pynxtools geändert: .github/workflows/pylint.yml geändert: .gitmodules modified: .github/workflows/pylint.yml * Properly adds definitions * Rename left over nexusutils reference from rebase * Merges xps reader.py --- README.md | 69 +++ __init__.py | 22 + comment_collector.py | 487 +++++++++++++++ nyaml2nxdl.py | 191 ++++++ nyaml2nxdl_backward_tools.py | 946 ++++++++++++++++++++++++++++++ nyaml2nxdl_forward_tools.py | 1072 ++++++++++++++++++++++++++++++++++ nyaml2nxdl_helper.py | 145 +++++ 7 files changed, 2932 insertions(+) create mode 100644 README.md create mode 100644 __init__.py create mode 100644 comment_collector.py create mode 100755 nyaml2nxdl.py create mode 100755 nyaml2nxdl_backward_tools.py create mode 100644 nyaml2nxdl_forward_tools.py create mode 100644 nyaml2nxdl_helper.py diff --git a/README.md b/README.md new file mode 100644 index 0000000000..6a0bbf86a7 --- /dev/null +++ b/README.md @@ -0,0 +1,69 @@ +# YAML to NXDL converter and NXDL to YAML converter + +**NOTE: Please use python3.8 or above to run this converter** + +**Tools purpose**: Offer a simple YAML-based schema and a XML-based schema to describe NeXus instances. These can be NeXus application definitions or classes +such as base or contributed classes. Users either create NeXus instances by writing a YAML file or a XML file which details a hierarchy of data/metadata elements. +The forward (YAML -> NXDL.XML) and backward (NXDL.XML -> YAML) conversions are implemented. + +**How the tool works**: +- yaml2nxdl.py +1. Reads the user-specified NeXus instance, either in YML or XML format. +2. If input is in YAML, creates an instantiated NXDL schema XML tree by walking the dictionary nest. + If input is in XML, creates a YML file walking the dictionary nest. +3. Write the tree into a YAML file or a properly formatted NXDL XML schema file to disk. +4. Optionally, if --append argument is given, + the XML or YAML input file is interpreted as an extension of a base class and the entries contained in it + are appended below a standard NeXus base class. + You need to specify both your input file (with YAML or XML extension) and NeXus class (with no extension). + Both .yml and .nxdl.xml file of the extended class are printed. + +```console +user@box:~$ python yaml2nxdl.py + +Usage: python yaml2nxdl.py [OPTIONS] + +Options: + --input-file TEXT The path to the input data file to read. + --append TEXT Parse xml NeXus file and append to specified base class, + write the base class name with no extension. + --verbose Addictional std output info is printed to help debugging. + --help Show this message and exit. + +``` + +## Documentation + +**Rule set**: From transcoding YAML files we need to follow several rules. +* Named NeXus groups, which are instances of NeXus classes especially base or contributed classes. Creating (NXbeam) is a simple example of a request to define a group named according to NeXus default rules. mybeam1(NXbeam) or mybeam2(NXbeam) are examples how to create multiple named instances at the same hierarchy level. +* Members of groups so-called fields or attributes. A simple example of a member is voltage. Here the datatype is implied automatically as the default NeXus NX_CHAR type. By contrast, voltage(NX_FLOAT) can be used to instantiate a member of class which should be of NeXus type NX_FLOAT. +* And attributes of either groups or fields. Names of attributes have to be preceeded by \@ to mark them as attributes. +* Optionality: For all fields, groups and attributes in `application definitions` are `required` by default, except anything (`recommended` or `optional`) mentioned. + +**Special keywords**: Several keywords can be used as childs of groups, fields, and attributes to specify the members of these. Groups, fields and attributes are nodes of the XML tree. +* **doc**: A human-readable description/docstring +* **exists** Options are recommended, required, [min, 1, max, infty] numbers like here 1 can be replaced by any uint, or infty to indicate no restriction on how frequently the entry can occur inside the NXDL schema at the same hierarchy level. +* **link** Define links between nodes. +* **units** A statement introducing NeXus-compliant NXDL units arguments, like NX_VOLTAGE +* **dimensions** Details which dimensional arrays to expect +* **enumeration** Python list of strings which are considered as recommended entries to choose from. +* **dim_parameters** `dim` which is a child of `dimension` and the `dim` might have several attributes `ref`, +`incr` including `index` and `value`. So while writting `yaml` file schema definition please following structure: +``` +dimensions: + rank: integer value + dim: [[ind_1, val_1], [ind_2, val_2], ...] + dim_parameters: + ref: [ref_value_1, ref_value_2, ...] + incr: [incr_value_1, incr_value_2, ...] +``` +Keep in mind that length of all the lists must be same. + +## Next steps + +The NOMAD team is currently working on the establishing of a one-to-one mapping between +NeXus definitions and the NOMAD MetaInfo. As soon as this is in place the YAML files will +be annotated with further metadata so that they can serve two purposes. +On the one hand they can serve as an instance for a schema to create a GUI representation +of a NOMAD Oasis ELN schema. On the other hand the YAML to NXDL converter will skip all +those pieces of information which are irrelevant from a NeXus perspective. diff --git a/__init__.py b/__init__.py new file mode 100644 index 0000000000..22eb35f68d --- /dev/null +++ b/__init__.py @@ -0,0 +1,22 @@ +#!/usr/bin/env python3 +""" +# Load paths +""" +# -*- coding: utf-8 -*- +# +# 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. +# diff --git a/comment_collector.py b/comment_collector.py new file mode 100644 index 0000000000..a2aa54b782 --- /dev/null +++ b/comment_collector.py @@ -0,0 +1,487 @@ +#!usr/bin/env python3 +# -*- coding: utf-8 -*- +# +# 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. +# + +""" +Collect comments in a list by CommentCollector class. Comment is a instance of Comment, +where each comment includes comment text and line info or neighbour info where the +comment must be assinged. + +The class Comment is an abstract class for general functions or method to be implemented +XMLComment and YAMLComment class. + +NOTE: Here comment block mainly stands for (comment text + line or element for what comment is +intended.) +""" + + +from typing import List, Type, Any, Tuple, Union, Dict +from pynxtools.nyaml2nxdl.nyaml2nxdl_helper import LineLoader + +__all__ = ['Comment', 'CommentCollector', 'XMLComment', 'YAMLComment'] + + +# pylint: disable=inconsistent-return-statements +class CommentCollector: + """CommentCollector will store a full comment ('Comment') object in + _comment_chain. + """ + + def __init__(self, input_file: str = None, + loaded_obj: Union[object, Dict] = None): + """ + Initialise CommentCollector + parameters: + input_file: raw input file (xml, yml) + loaded_obj: file loaded by third party library + """ + self._comment_chain: List = [] + self.file = input_file + self._comment_tracker = 0 + self._comment_hash: Dict[Tuple, Type[Comment]] = {} + self.comment: Type[Comment] + if self.file and not loaded_obj: + if self.file.split('.')[-1] == 'xml': + self.comment = XMLComment + if self.file.split('.')[-1] == 'yaml': + self.comment = YAMLComment + with open(self.file, "r", encoding="utf-8") as plain_text_yaml: + loader = LineLoader(plain_text_yaml) + self.comment.__yaml_dict__ = loader.get_single_data() + elif self.file and loaded_obj: + if self.file.split('.')[-1] == 'yaml' and isinstance(loaded_obj, dict): + self.comment = YAMLComment + self.comment.__yaml_dict__ = loaded_obj + else: + raise ValueError("Incorrect inputs for CommentCollector e.g. Wrong file extension.") + + else: + raise ValueError("Incorrect inputs for CommentCollector") + + def extract_all_comment_blocks(self): + """ + Collect all comments. Note that here comment means (comment text + element or line info + intended for comment. + """ + id_ = 0 + single_comment = self.comment(comment_id=id_) + with open(self.file, mode='r', encoding='UTF-8') as enc_f: + lines = enc_f.readlines() + # Make an empty line for last comment if no empty lines in original file + if lines[-1] != '': + lines.append('') + for line_num, line in enumerate(lines): + if single_comment.is_storing_single_comment(): + # If the last comment comes without post nxdl fields, groups and attributes + if line_num < (len(lines) - 1): + # Processing file from Line number 1 + single_comment.process_each_line(line, (line_num + 1)) + else: + # For processing post comment + single_comment.process_each_line(line + 'post_comment', (line_num + 1)) + self._comment_chain.append(single_comment) + else: + self._comment_chain.append(single_comment) + single_comment = self.comment(last_comment=single_comment) + single_comment.process_each_line(line, (line_num + 1)) + + def get_comment(self): + """ + Return comment from comment_chain that must come earlier in order. + """ + return self._comment_chain[self._comment_tracker] + + def get_coment_by_line_info(self, comment_locs: Tuple[str, Union[int, str]]): + """ + Get comment using line information. + """ + if comment_locs in self._comment_hash: + return self._comment_hash[comment_locs] + + line_annot, line_loc = comment_locs + for cmnt in self._comment_chain: + if line_annot in cmnt: + line_loc_ = cmnt.get_line_number(line_annot) + if line_loc == line_loc_: + self._comment_hash[comment_locs] = cmnt + return cmnt + + def reload_comment(self): + """ + Update self._comment_tracker after done with last comment. + """ + self._comment_tracker += 1 + + def __contains__(self, comment_locs: tuple): + """ + Confirm wether the comment corresponds to key_line and line_loc + is exist or not. + comment_locs is equvalant to (line_annotation, line_loc) e.g. + (__line__doc and 35) + """ + if not isinstance(comment_locs, tuple): + raise TypeError("Comment_locs should be 'tuple' containing line annotation " + "(e.g.__line__doc) and line_loc (e.g. 35).") + line_annot, line_loc = comment_locs + for cmnt in self._comment_chain: + if line_annot in cmnt: + line_loc_ = cmnt.get_line_number(line_annot) + if line_loc == line_loc_: + self._comment_hash[comment_locs] = cmnt + return True + return False + + def __getitem__(self, ind): + """Get comment from self.obj._comment_chain by index. + """ + if ind >= len(self._comment_chain): + raise IndexError(f'Oops! Coment index {ind} in {__class__} is out of range!') + return self._comment_chain[ind] + + def __iter__(self): + """get comment ieratively + """ + return iter(self._comment_chain) + + +# pylint: disable=too-many-instance-attributes +class Comment: + """ + This class is building yaml comment and the intended line for what comment is written. + """ + + def __init__(self, + comment_id: int = -1, + last_comment: 'Comment' = None) -> None: + """Comment object can be considered as a block element that includes + document element (an entity for what the comment is written). + """ + self._elemt: Any = None + self._elemt_text: str = None + self._is_elemt_found: bool = None + self._is_elemt_stored: bool = None + + self._comnt: str = '' + # If Multiple comments for one element or entity + self._comnt_list: List[str] = [] + self.last_comment: 'Comment' = last_comment if last_comment else None + if comment_id >= 0 and last_comment: + self.cid = comment_id + self.last_comment = last_comment + elif comment_id == 0 and not last_comment: + self.cid = comment_id + self.last_comment = None + elif last_comment: + self.cid = self.last_comment.cid + 1 + self.last_comment = last_comment + else: + raise ValueError("Neither last comment nor comment id dound") + self._comnt_start_found: bool = False + self._comnt_end_found: bool = False + self.is_storing_single_comment = lambda: not (self._comnt_end_found + and self._is_elemt_stored) + + def get_comment_text(self) -> Union[List, str]: + """ + Extract comment text from entrire comment (comment text + elment or + line for what comment is intended) + """ + + def append_comment(self, text: str) -> None: + """ + Append lines of the same comment. + """ + + def store_element(self, args) -> None: + """ + Strore comment text and line or element that is intended for comment. + """ + + +class XMLComment(Comment): + """ + XMLComment to store xml comment element. + """ + + def __init__(self, comment_id: int = -1, last_comment: 'Comment' = None) -> None: + super().__init__(comment_id, last_comment) + + def process_each_line(self, text, line_num): + """Take care of each line of text. Through which function the text + must be passed should be decide here. + """ + text = text.strip() + if text and line_num: + self.append_comment(text) + if self._comnt_end_found and not self._is_elemt_found: + if self._comnt: + self._comnt_list.append(self._comnt) + self._comnt = '' + + if self._comnt_end_found: + self.store_element(text) + + def append_comment(self, text: str) -> None: + # Comment in single line + if '' == text[-4:]: + self._comnt_end_found = True + self._comnt_start_found = False + self._comnt = self._comnt.replace('-->', '') + + elif '-->' == text[0:4] and self._comnt_start_found: + self._comnt_end_found = True + self._comnt_start_found = False + self._comnt = self._comnt + '\n' + text.replace('-->', '') + elif self._comnt_start_found: + self._comnt = self._comnt + '\n' + text + + # pylint: disable=arguments-differ, arguments-renamed + def store_element(self, text) -> None: + def collect_xml_attributes(text_part): + for part in text_part: + part = part.strip() + if part and '">' == ''.join(part[-2:]): + self._is_elemt_stored = True + self._is_elemt_found = False + part = ''.join(part[0:-2]) + elif part and '"/>' == ''.join(part[-3:]): + self._is_elemt_stored = True + self._is_elemt_found = False + part = ''.join(part[0:-3]) + elif part and '/>' == ''.join(part[-2:]): + self._is_elemt_stored = True + self._is_elemt_found = False + part = ''.join(part[0:-2]) + elif part and '>' == part[-1]: + self._is_elemt_stored = True + self._is_elemt_found = False + part = ''.join(part[0:-1]) + elif part and '"' == part[-1]: + part = ''.join(part[0:-1]) + + if '="' in part: + lf_prt, rt_prt = part.split('="') + else: + continue + if ':' in lf_prt: + continue + self._elemt[lf_prt] = str(rt_prt) + if not self._elemt: + self._elemt = {} + # First check for comment part has been collected prefectly + if ' Union[List, str]: + """ + This method returns list of commnent text. As some xml element might have + multiple separated comment intended for a single element. + """ + return self._comnt_list + + +class YAMLComment(Comment): + """ + This class for stroing comment text as well as location of the comment e.g. line + number of other in the file. + NOTE: + 1. Do not delete any element form yaml dictionary (for loaded_obj. check: Comment_collector + class. because this loaded file has been exploited in nyaml2nxdl forward tools.) + """ + # Class level variable. The main reason behind that to follow structure of + # abstract class 'Comment' + __yaml_dict__: dict = {} + __yaml_line_info: dict = {} + __comment_escape_char = {'--': '-\\-'} + + def __init__(self, comment_id: int = -1, last_comment: 'Comment' = None) -> None: + """Initialization of YAMLComment follow Comment class. + """ + super().__init__(comment_id, last_comment) + self.collect_yaml_line_info(YAMLComment.__yaml_dict__, YAMLComment.__yaml_line_info) + + def process_each_line(self, text, line_num): + """Take care of each line of text. Through which function the text + must be passed should be decide here. + """ + text = text.strip() + self.append_comment(text) + if self._comnt_end_found and not self._is_elemt_found: + if self._comnt: + self._comnt_list.append(self._comnt) + self._comnt = '' + + if self._comnt_end_found: + line_key = '' + if ':' in text: + ind = text.index(':') + line_key = '__line__' + ''.join(text[0:ind]) + + for l_num, l_key in self.__yaml_line_info.items(): + if line_num == int(l_num) and line_key == l_key: + self.store_element(line_key, line_num) + break + # Comment comes very end of the file + if text == 'post_comment' and line_key == '': + line_key = '__line__post_comment' + self.store_element(line_key, line_num) + + def has_post_comment(self): + """ + Ensure is this a post coment or not. + Post comment means the comment that come at the very end without having any + nxdl element(class, group, filed and attribute.) + """ + for key, _ in self._elemt.items(): + if '__line__post_comment' == key: + return True + return False + + def append_comment(self, text: str) -> None: + """ + Collects all the line of the same comment and + append them with that single comment. + """ + # check for escape char + text = self.replace_scape_char(text) + # Empty line after last line of comment + if not text and self._comnt_start_found: + self._comnt_end_found = True + self._comnt_start_found = False + # For empty line inside doc or yaml file. + elif not text: + return + elif '# ' == ''.join(text[0:2]): + self._comnt_start_found = True + self._comnt_end_found = False + self._comnt = '' if not self._comnt else self._comnt + '\n' + self._comnt = self._comnt + ''.join(text[2:]) + elif '#' == text[0]: + self._comnt_start_found = True + self._comnt_end_found = False + self._comnt = '' if not self._comnt else self._comnt + '\n' + self._comnt = self._comnt + ''.join(text[1:]) + elif 'post_comment' == text: + self._comnt_end_found = True + self._comnt_start_found = False + # for any line after 'comment block' found + elif self._comnt_start_found: + self._comnt_start_found = False + self._comnt_end_found = True + + # pylint: disable=arguments-differ + def store_element(self, line_key, line_number): + """ + Store comment content and information of commen location (for what comment is + created.). + """ + self._elemt = {} + self._elemt[line_key] = int(line_number) + self._is_elemt_found = False + self._is_elemt_stored = True + + def get_comment_text(self): + """ + Return list of comments if there are multiple comment for same yaml line. + """ + return self._comnt_list + + def get_line_number(self, line_key): + """ + Retrun line number for what line the comment is created + """ + return self._elemt[line_key] + + def get_line_info(self): + """ + Return line annotation and line number from a comment. + """ + for line_anno, line_loc in self._elemt.items(): + return line_anno, line_loc + + def replace_scape_char(self, text): + """Replace escape char according to __comment_escape_char dict + """ + for ecp_char, ecp_alt in YAMLComment.__comment_escape_char.items(): + if ecp_char in text: + text = text.replace(ecp_char, ecp_alt) + return text + + def get_element_location(self): + """ + Retrun yaml line '__line__KEY' info and and line numner + """ + if len(self._elemt) > 1: + raise ValueError(f"Comment element should be one but got " + f"{self._elemt}") + + for key, val in self._elemt.items(): + return key, val + + def collect_yaml_line_info(self, yaml_dict, line_info_dict): + """Collect __line__key and corresponding value from + a yaml file dictonary in another dictionary. + """ + for line_key, line_n in yaml_dict.items(): + if '__line__' in line_key: + line_info_dict[line_n] = line_key + + for _, val in yaml_dict.items(): + if isinstance(val, dict): + self.collect_yaml_line_info(val, line_info_dict) + + def __contains__(self, line_key): + """For Checking whether __line__NAME is in _elemt dict or not.""" + return line_key in self._elemt + + def __eq__(self, comment_obj): + """Check the self has same value as right comment. + """ + if len(self._comnt_list) != len(comment_obj._comnt_list): + return False + for left_cmnt, right_cmnt in zip(self._comnt_list, comment_obj._comnt_list): + left_cmnt = left_cmnt.split('\n') + right_cmnt = right_cmnt.split('\n') + for left_line, right_line in zip(left_cmnt, right_cmnt): + if left_line.strip() != right_line.strip(): + return False + return True diff --git a/nyaml2nxdl.py b/nyaml2nxdl.py new file mode 100755 index 0000000000..3088a25e52 --- /dev/null +++ b/nyaml2nxdl.py @@ -0,0 +1,191 @@ +#!/usr/bin/env python3 +"""Main file of yaml2nxdl tool. +Users create NeXus instances by writing a YAML file +which details a hierarchy of data/metadata elements + +""" +# -*- coding: utf-8 -*- +# +# 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. +# +import os +import xml.etree.ElementTree as ET + +import click + +from pynxtools.nyaml2nxdl.nyaml2nxdl_forward_tools import nyaml2nxdl, pretty_print_xml +from pynxtools.nyaml2nxdl.nyaml2nxdl_backward_tools import (Nxdl2yaml, + compare_niac_and_my) + + +DEPTH_SIZE = " " + + +# pylint: disable=too-many-locals +def append_yml(input_file, append, verbose): + """Append to an existing NeXus base class new elements provided in YML input file \ +and print both an XML and YML file of the extended base class. + +""" + nexus_def_path = os.path.join(os.path.abspath(os.path.dirname(__file__)), '../../definitions') + assert [s for s in os.listdir(os.path.join(nexus_def_path, 'base_classes') + ) if append.strip() == s.replace('.nxdl.xml', '')], \ + 'Your base class extension does not match any existing NeXus base classes' + tree = ET.parse(os.path.join(nexus_def_path + '/base_classes', append + '.nxdl.xml')) + root = tree.getroot() + # warning: tmp files are printed on disk and removed at the ends!! + pretty_print_xml(root, 'tmp.nxdl.xml') + input_tmp_xml = 'tmp.nxdl.xml' + out_tmp_yml = 'tmp_parsed.yaml' + converter = Nxdl2yaml([], []) + converter.print_yml(input_tmp_xml, out_tmp_yml, verbose) + nyaml2nxdl(input_file=out_tmp_yml, + out_file='tmp_parsed.nxdl.xml', + verbose=verbose) + tree = ET.parse('tmp_parsed.nxdl.xml') + tree2 = ET.parse(input_file) + root_no_duplicates = ET.Element( + 'definition', {'xmlns': 'http://definition.nexusformat.org/nxdl/3.1', + 'xmlns:xsi': 'http://www.w3.org/2001/XMLSchema-instance', + 'xsi:schemaLocation': 'http://www.w3.org/2001/XMLSchema-instance' + } + ) + for attribute_keys in root.attrib.keys(): + if attribute_keys != '{http://www.w3.org/2001/XMLSchema-instance}schemaLocation': + attribute_value = root.attrib[attribute_keys] + root_no_duplicates.set(attribute_keys, attribute_value) + for elems in root.iter(): + if 'doc' in elems.tag: + root_doc = ET.SubElement(root_no_duplicates, 'doc') + root_doc.text = elems.text + break + group = '{http://definition.nexusformat.org/nxdl/3.1}group' + root_no_duplicates = compare_niac_and_my(tree, tree2, verbose, + group, + root_no_duplicates) + field = '{http://definition.nexusformat.org/nxdl/3.1}field' + root_no_duplicates = compare_niac_and_my(tree, tree2, verbose, + field, + root_no_duplicates) + attribute = '{http://definition.nexusformat.org/nxdl/3.1}attribute' + root_no_duplicates = compare_niac_and_my(tree, tree2, verbose, + attribute, + root_no_duplicates) + pretty_print_xml(root_no_duplicates, f"{input_file.replace('.nxdl.xml', '')}" + f"_appended.nxdl.xml") + + input_file_xml = input_file.replace('.nxdl.xml', "_appended.nxdl.xml") + out_file_yml = input_file.replace('.nxdl.xml', "_appended_parsed.yaml") + converter = Nxdl2yaml([], []) + converter.print_yml(input_file_xml, out_file_yml, verbose) + nyaml2nxdl(input_file=out_file_yml, + out_file=out_file_yml.replace('.yaml', '.nxdl.xml'), + verbose=verbose) + os.rename(f"{input_file.replace('.nxdl.xml', '_appended_parsed.yaml')}", + f"{input_file.replace('.nxdl.xml', '_appended.yaml')}") + os.rename(f"{input_file.replace('.nxdl.xml', '_appended_parsed.nxdl.xml')}", + f"{input_file.replace('.nxdl.xml', '_appended.nxdl.xml')}") + os.remove('tmp.nxdl.xml') + os.remove('tmp_parsed.yaml') + os.remove('tmp_parsed.nxdl.xml') + + +def split_name_and_extension(file_name): + """ + Split file name into extension and rest of the file name. + return file raw nam and extension + """ + parts = file_name.rsplit('.', 2) + if len(parts) == 2: + raw = parts[0] + ext = parts[1] + if len(parts) == 3: + raw = parts[0] + ext = '.'.join(parts[1:]) + + return raw, ext + + +@click.command() +@click.option( + '--input-file', + required=True, + prompt=True, + help='The path to the XML or YAML input data file to read and create \ +a YAML or XML file from, respectively.' +) +@click.option( + '--append', + help='Parse xml file and append to base class, given that the xml file has same name \ +of an existing base class' +) +@click.option( + '--check-consistency', + is_flag=True, + default=False, + help=('Check wether yaml or nxdl has followed general rules of scema or not' + 'check whether your comment in the right place or not. The option render an ' + 'output file of the same extension(*_consistency.yaml or *_consistency.nxdl.xml)') +) +@click.option( + '--verbose', + is_flag=True, + default=False, + help='Print in standard output keywords and value types to help \ +possible issues in yaml files' +) +def launch_tool(input_file, verbose, append, check_consistency): + """ + Main function that distiguishes the input file format and launches the tools. + """ + if os.path.isfile(input_file): + raw_name, ext = split_name_and_extension(input_file) + else: + raise ValueError("Need a valid input file.") + + if ext == 'yaml': + xml_out_file = raw_name + '.nxdl.xml' + nyaml2nxdl(input_file, xml_out_file, verbose) + if append: + append_yml(raw_name + '.nxdl.xml', + append, + verbose + ) + # For consistency running + if check_consistency: + yaml_out_file = raw_name + '_consistency.' + ext + converter = Nxdl2yaml([], []) + converter.print_yml(xml_out_file, yaml_out_file, verbose) + os.remove(xml_out_file) + elif ext == 'nxdl.xml': + if not append: + yaml_out_file = raw_name + '_parsed' + '.yaml' + converter = Nxdl2yaml([], []) + converter.print_yml(input_file, yaml_out_file, verbose) + else: + append_yml(input_file, append, verbose) + # Taking care of consistency running + if check_consistency: + xml_out_file = raw_name + '_consistency.' + ext + nyaml2nxdl(yaml_out_file, xml_out_file, verbose) + os.remove(yaml_out_file) + else: + raise ValueError("Provide correct file with extension '.yaml or '.nxdl.xml") + + +if __name__ == '__main__': + launch_tool().parse() # pylint: disable=no-value-for-parameter diff --git a/nyaml2nxdl_backward_tools.py b/nyaml2nxdl_backward_tools.py new file mode 100755 index 0000000000..0ebc0d5cc1 --- /dev/null +++ b/nyaml2nxdl_backward_tools.py @@ -0,0 +1,946 @@ +#!/usr/bin/env python3 +"""This file collects the function used in the reverse tool nxdl2yaml. + +""" +# -*- coding: utf-8 -*- +# +# 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. +# +import sys +from typing import List, Dict +import xml.etree.ElementTree as ET +import os + +from pynxtools.nyaml2nxdl.nyaml2nxdl_helper import (get_node_parent_info, + get_yaml_escape_char_dict, + cleaning_empty_lines) +from pynxtools.dataconverter.helpers import remove_namespace_from_tag + + +DEPTH_SIZE = " " +CMNT_TAG = '!--' + + +def separate_pi_comments(input_file): + """ + Separate PI comments from ProcessesInstruction (pi) + """ + comments_list = [] + comment = [] + xml_lines = [] + + with open(input_file, "r", encoding='utf-8') as file: + lines = file.readlines() + has_pi = True + for line in lines: + c_start = '' + def_tag = ' 0 and has_pi: + comment.append(line.replace(cmnt_end, '')) + comments_list.append(''.join(comment)) + comment = [] + elif def_tag in line or not has_pi: + has_pi = False + xml_lines.append(line) + elif len(comment) > 0 and has_pi: + comment.append(line) + else: + xml_lines.append(line) + return comments_list, ''.join(xml_lines) + + +# Collected: https://dustinoprea.com/2019/01/22/python-parsing-xml-and-retaining-the-comments/ +class _CommentedTreeBuilder(ET.TreeBuilder): + + def comment(self, text): + """ + defining comment builder in TreeBuilder + """ + self.start('!--', {}) + self.data(text) + self.end('--') + + +def parse(filepath): + """ + Construct parse function for modified tree builder for including modified TreeBuilder + and rebuilding XMLParser. + """ + comments, xml_str = separate_pi_comments(filepath) + ctb = _CommentedTreeBuilder() + xp_parser = ET.XMLParser(target=ctb) + root = ET.fromstring(xml_str, parser=xp_parser) + return comments, root + + +def handle_mapping_char(text, depth=-1, skip_n_line_on_top=False): + """Check for ":" char and replace it by "':'". """ + + # This escape chars and sepeerator ':' is not allowed in yaml library + escape_char = get_yaml_escape_char_dict() + for esc_key, val in escape_char.items(): + if esc_key in text: + text = text.replace(esc_key, val) + if not skip_n_line_on_top: + if depth > 0: + text = add_new_line_on_top(text, depth) + else: + raise ValueError("Need depth size to co-ordinate text line in yaml file.") + return text + + +def add_new_line_on_top(text, depth): + """ + Return char list for what we get error in converter. After adding a + new line at the start of text the eroor is solved. + """ + char_list_to_add_new_line_on_top_of_text = [":"] + for char in char_list_to_add_new_line_on_top_of_text: + if char in text: + return '\n' + depth * DEPTH_SIZE + text + return text + + +# pylint: disable=too-many-instance-attributes +class Nxdl2yaml(): + """ + Parse XML file and print a YML file + """ + + def __init__( + self, + symbol_list: List[str], + root_level_definition: List[str], + root_level_doc='', + root_level_symbols=''): + + # updated part of yaml_dict + self.found_definition = False + self.root_level_doc = root_level_doc + self.root_level_symbols = root_level_symbols + self.root_level_definition = root_level_definition + self.symbol_list = symbol_list + self.is_last_element_comment = False + self.include_comment = True + self.pi_comments = None + # NOTE: Here is how root_level_comments organised for storing comments + # root_level_comment= {'root_doc': comment, + # 'symbols': comment, + # The 'symbol_doc_comments' list is for comments from all 'symbol doc' + # 'symbol_doc_comments' : [comments] + # 'symbol_list': [symbols], + # The 'symbol_comments' contains comments for 'symbols doc' and all 'symbol' + # 'symbol_comments': [comments]} + self.root_level_comment: Dict[str, str] = {} + + def print_yml(self, input_file, output_yml, verbose): + """ + Parse an XML file provided as input and print a YML file + """ + if os.path.isfile(output_yml): + os.remove(output_yml) + + depth = 0 + + self.pi_comments, root = parse(input_file) + xml_tree = {'tree': root, 'node': root} + self.xmlparse(output_yml, xml_tree, depth, verbose) + + def handle_symbols(self, depth, node): + """Handle symbols field and its childs symbol""" + + # pylint: disable=consider-using-f-string + self.root_level_symbols = ( + f"{remove_namespace_from_tag(node.tag)}: " + f"{node.text.strip() if node.text else ''}" + ) + depth += 1 + last_comment = '' + sbl_doc_cmnt_list = [] + # Comments that come above symbol tag + symbol_cmnt_list = [] + for child in list(node): + tag = remove_namespace_from_tag(child.tag) + if tag == CMNT_TAG and self.include_comment: + last_comment = self.comvert_to_ymal_comment(depth * DEPTH_SIZE, child.text) + if tag == 'doc': + symbol_cmnt_list.append(last_comment) + # The bellow line is for handling lenth of 'symbol_comments' and + # 'symbol_doc_comments'. Otherwise print_root_level_info() gets inconsistency + # over for the loop while writting comment on file + sbl_doc_cmnt_list.append('') + last_comment = '' + self.symbol_list.append(self.handle_not_root_level_doc(depth, + text=child.text)) + elif tag == 'symbol': + # place holder is symbol name + symbol_cmnt_list.append(last_comment) + last_comment = '' + if 'doc' in child.attrib: + self.symbol_list.append( + self.handle_not_root_level_doc(depth, + tag=child.attrib['name'], + text=child.attrib['doc'])) + else: + for symbol_doc in list(child): + tag = remove_namespace_from_tag(symbol_doc.tag) + if tag == CMNT_TAG and self.include_comment: + last_comment = self.comvert_to_ymal_comment(depth * DEPTH_SIZE, + symbol_doc.text) + if tag == 'doc': + sbl_doc_cmnt_list.append(last_comment) + last_comment = '' + self.symbol_list.append( + self.handle_not_root_level_doc(depth, + tag=child.attrib['name'], + text=symbol_doc.text)) + self.stroe_root_level_comments('symbol_doc_comments', sbl_doc_cmnt_list) + self.stroe_root_level_comments('symbol_comments', symbol_cmnt_list) + + def stroe_root_level_comments(self, holder, comment): + """Store yaml text or section line and the comments inteded for that lines or section""" + + self.root_level_comment[holder] = comment + + def handle_definition(self, node): + """ + Handle definition group and its attributes + NOTE: Here we tried to store the order of the xml element attributes. So that we get + exactly the same file in nxdl from yaml. + """ + # pylint: disable=consider-using-f-string + # self.root_level_definition[0] = '' + keyword = '' + # tmp_word for reseving the location + tmp_word = "#xx#" + attribs = node.attrib + # for tracking the order of name and type + keyword_order = -1 + for item in attribs: + if "name" in item: + keyword = keyword + attribs[item] + if keyword_order == -1: + self.root_level_definition.append(tmp_word) + keyword_order = self.root_level_definition.index(tmp_word) + elif "extends" in item: + keyword = f"{keyword}({attribs[item]})" + if keyword_order == -1: + self.root_level_definition.append(tmp_word) + keyword_order = self.root_level_definition.index(tmp_word) + elif 'schemaLocation' not in item \ + and 'extends' != item: + text = f"{item}: {attribs[item]}" + self.root_level_definition.append(text) + self.root_level_definition[keyword_order] = f"{keyword}:" + + def handle_root_level_doc(self, node): + """ + Handle the documentation field found at root level. + """ + # tag = remove_namespace_from_tag(node.tag) + text = node.text + text = self.handle_not_root_level_doc(depth=0, text=text) + self.root_level_doc = text + + # pylint: disable=too-many-branches + def handle_not_root_level_doc(self, depth, text, tag='doc', file_out=None): + """ + Handle docs field along the yaml file. In this function we also tried to keep + the track of intended indentation. E.g. the bollow doc block. + * Topic name + DEscription of topic + """ + + # Handling empty doc + if not text: + text = "" + else: + text = handle_mapping_char(text, -1, True) + if "\n" in text: + # To remove '\n' character as it will be added before text. + text = text.split('\n') + text = cleaning_empty_lines(text) + text_tmp = [] + yaml_indent_n = len((depth + 1) * DEPTH_SIZE) + # Find indentaion in the first valid line with alphabet + tmp_i = 0 + while tmp_i != -1: + first_line_indent_n = 0 + for ch_ in text[tmp_i]: + if ch_ == ' ': + first_line_indent_n = first_line_indent_n + 1 + elif ch_ != '': + tmp_i = -2 + break + tmp_i = tmp_i + 1 + # Taking care of doc like bellow: + # Text liness + # text continues + # So no indentaion at the staring or doc. So doc group will come along general + # alignment + if first_line_indent_n == 0: + first_line_indent_n = yaml_indent_n + + # for indent_diff -ve all lines will move left by the same ammout + # for indect_diff +ve all lines will move right the same amount + indent_diff = yaml_indent_n - first_line_indent_n + # CHeck for first line empty if not keep first line empty + + for _, line in enumerate(text): + line_indent_n = 0 + # Collect first empty space without alphabate + for ch_ in line: + if ch_ == ' ': + line_indent_n = line_indent_n + 1 + else: + break + line_indent_n = line_indent_n + indent_diff + if line_indent_n < yaml_indent_n: + # if line still under yaml identation + text_tmp.append(yaml_indent_n * ' ' + line.strip()) + else: + text_tmp.append(line_indent_n * ' ' + line.strip()) + + text = '\n' + '\n'.join(text_tmp) + if "}" in tag: + tag = remove_namespace_from_tag(tag) + indent = depth * DEPTH_SIZE + elif text: + text = '\n' + (depth + 1) * DEPTH_SIZE + text.strip() + if "}" in tag: + tag = remove_namespace_from_tag(tag) + indent = depth * DEPTH_SIZE + else: + text = "" + if "}" in tag: + tag = remove_namespace_from_tag(tag) + indent = depth * DEPTH_SIZE + + doc_str = f"{indent}{tag}: |{text}\n" + if file_out: + file_out.write(doc_str) + return None + return doc_str + + def write_out(self, indent, text, file_out): + """ + Write text line in output file. + """ + line_string = f"{indent}{text.rstrip()}\n" + file_out.write(line_string) + + def print_root_level_doc(self, file_out): + """ + Print at the root level of YML file \ + the general documentation field found in XML file + """ + indent = 0 * DEPTH_SIZE + + if ('root_doc' in self.root_level_comment + and self.root_level_comment['root_doc'] != ''): + text = self.root_level_comment['root_doc'] + self.write_out(indent, text, file_out) + + text = self.root_level_doc + self.write_out(indent, text, file_out) + self.root_level_doc = '' + + def comvert_to_ymal_comment(self, indent, text): + """ + Convert into yaml comment by adding exta '#' char in front of comment lines + """ + lines = text.split('\n') + mod_lines = [] + for line in lines: + line = line.strip() + if line and line[0] != '#': + line = indent + '# ' + line + mod_lines.append(line) + elif line: + line = indent + line + mod_lines.append(line) + # The starting '\n' to keep multiple comments separate + return '\n' + '\n'.join(mod_lines) + + def print_root_level_info(self, depth, file_out): + """ + Print at the root level of YML file \ + the information stored as definition attributes in the XML file + """ + # pylint: disable=consider-using-f-string + if depth < 0: + raise ValueError("Somthing wrong with indentaion in root level.") + + has_categoty = False + for def_line in self.root_level_definition: + if def_line in ("category: application", "category: base"): + self.write_out(indent=0 * DEPTH_SIZE, text=def_line, file_out=file_out) + # file_out.write(f"{def_line}\n") + has_categoty = True + + if not has_categoty: + raise ValueError("Definition dose not get any category from 'base or application'.") + self.print_root_level_doc(file_out) + if 'symbols' in self.root_level_comment and self.root_level_comment['symbols'] != '': + indent = depth * DEPTH_SIZE + text = self.root_level_comment['symbols'] + self.write_out(indent, text, file_out) + if self.root_level_symbols: + self.write_out(indent=0 * DEPTH_SIZE, text=self.root_level_symbols, file_out=file_out) + # symbol_list include 'symbols doc', and all 'symbol' + for ind, symbol in enumerate(self.symbol_list): + # Taking care of comments that come on to of 'symbols doc' and 'symbol' + if 'symbol_comments' in self.root_level_comment and \ + self.root_level_comment['symbol_comments'][ind] != '': + indent = depth * DEPTH_SIZE + self.write_out(indent, + self.root_level_comment['symbol_comments'][ind], file_out) + if 'symbol_doc_comments' in self.root_level_comment and \ + self.root_level_comment['symbol_doc_comments'][ind] != '': + + indent = depth * DEPTH_SIZE + self.write_out(indent, + self.root_level_comment['symbol_doc_comments'][ind], file_out) + + self.write_out(indent=(0 * DEPTH_SIZE), text=symbol, file_out=file_out) + if len(self.pi_comments) > 1: + indent = DEPTH_SIZE * depth + # The first comment is top level copy-right doc string + for comment in self.pi_comments[1:]: + self.write_out(indent, self.comvert_to_ymal_comment(indent, comment), file_out) + if self.root_level_definition: + # Soring NXname for writting end of the definition attributes + nx_name = '' + for defs in self.root_level_definition: + if 'NX' in defs and defs[-1] == ':': + nx_name = defs + continue + if defs in ("category: application", "category: base"): + continue + self.write_out(indent=0 * DEPTH_SIZE, text=defs, file_out=file_out) + self.write_out(indent=0 * DEPTH_SIZE, text=nx_name, file_out=file_out) + self.found_definition = False + + def handle_exists(self, exists_dict, key, val): + """ + Create exist component as folows: + + {'min' : value for min, + 'max' : value for max, + 'optional' : value for optional} + + This is created separately so that the keys stays in order. + """ + if not val: + val = '' + else: + val = str(val) + if 'minOccurs' == key: + exists_dict['minOccurs'] = ['min', val] + if 'maxOccurs' == key: + exists_dict['maxOccurs'] = ['max', val] + if 'optional' == key: + exists_dict['optional'] = ['optional', val] + if 'recommended' == key: + exists_dict['recommended'] = ['recommended', val] + if 'required' == key: + exists_dict['required'] = ['required', val] + + # pylint: disable=too-many-branches, consider-using-f-string + def handle_group_or_field(self, depth, node, file_out): + """Handle all the possible attributes that come along a field or group""" + + allowed_attr = ['optional', 'recommended', 'name', 'type', 'axes', 'axis', 'data_offset', + 'interpretation', 'long_name', 'maxOccurs', 'minOccurs', 'nameType', + 'optional', 'primary', 'signal', 'stride', 'units', 'required', + 'deprecated', 'exists'] + + name_type = "" + node_attr = node.attrib + rm_key_list = [] + # Maintain order: name and type in form name(type) or (type)name that come first + for key, val in node_attr.items(): + if key == 'name': + name_type = name_type + val + rm_key_list.append(key) + if key == 'type': + name_type = name_type + "(%s)" % val + rm_key_list.append(key) + if not name_type: + raise ValueError(f"No 'name' or 'type' hase been found. But, 'group' or 'field' " + f"must have at list a nme.We got attributes: {node_attr}") + file_out.write('{indent}{name_type}:\n'.format( + indent=depth * DEPTH_SIZE, + name_type=name_type)) + + for key in rm_key_list: + del node_attr[key] + + # tmp_dict intended to persevere order of attribnutes + tmp_dict = {} + exists_dict = {} + for key, val in node_attr.items(): + # As both 'minOccurs', 'maxOccurs' and optionality move to the 'exists' + if key in ['minOccurs', 'maxOccurs', 'optional', 'recommended', 'required']: + if 'exists' not in tmp_dict: + tmp_dict['exists'] = [] + self.handle_exists(exists_dict, key, val) + elif key == 'units': + tmp_dict['unit'] = str(val) + else: + tmp_dict[key] = str(val) + if key not in allowed_attr: + raise ValueError(f"An attribute ({key}) in 'field' or 'group' has been found " + f"that is not allowed. The allowed attr is {allowed_attr}.") + + if exists_dict: + for key, val in exists_dict.items(): + if key in ['minOccurs', 'maxOccurs']: + tmp_dict['exists'] = tmp_dict['exists'] + val + elif key in ['optional', 'recommended', 'required']: + tmp_dict['exists'] = key + + depth_ = depth + 1 + for key, val in tmp_dict.items(): + # Increase depth size inside handle_map...() for writting text with one + # more indentation. + file_out.write(f'{depth_ * DEPTH_SIZE}{key}: ' + f'{handle_mapping_char(val, depth_ + 1, False)}\n') + + # pylint: disable=too-many-branches, too-many-locals + def handle_dimension(self, depth, node, file_out): + """ + Handle the dimension field. + NOTE: Usually we take care of any xml element in xmlparse(...) and + recursion_in_xml_tree(...) functions. But Here it is a bit different. The doc dimension + and attributes of dim has been handled inside this function here. + """ + # pylint: disable=consider-using-f-string + possible_dim_attrs = ['ref', 'optional', 'recommended', + 'required', 'incr', 'refindex'] + possible_dimemsion_attrs = ['rank'] + + # taking care of Dimension tag + file_out.write( + '{indent}{tag}:\n'.format( + indent=depth * DEPTH_SIZE, + tag=node.tag.split("}", 1)[1])) + # Taking care of dimension attributes + for attr, value in node.attrib.items(): + if attr in possible_dimemsion_attrs and not isinstance(value, dict): + indent = (depth + 1) * DEPTH_SIZE + file_out.write(f'{indent}{attr}: {value}\n') + else: + raise ValueError(f"Dimension has got an attribute {attr} that is not valid." + f"Current the allowd atributes are {possible_dimemsion_attrs}." + f" Please have a look") + # taking carew of dimension doc + for child in list(node): + tag = remove_namespace_from_tag(child.tag) + if tag == 'doc': + text = self.handle_not_root_level_doc(depth + 1, child.text) + file_out.write(text) + node.remove(child) + + dim_index_value = '' + dim_other_parts = {} + dim_cmnt_node = [] + # taking care of dim and doc childs of dimension + for child in list(node): + tag = remove_namespace_from_tag(child.tag) + child_attrs = child.attrib + # taking care of index and value attributes + if tag == ('dim'): + # taking care of index and value in format [[index, value]] + dim_index_value = dim_index_value + '[{index}, {value}], '.format( + index=child_attrs['index'] if "index" in child_attrs else '', + value=child_attrs['value'] if "value" in child_attrs else '') + if "index" in child_attrs: + del child_attrs["index"] + if "value" in child_attrs: + del child_attrs["value"] + + # Taking care of doc comes as child of dim + for cchild in list(child): + ttag = cchild.tag.split("}", 1)[1] + if ttag == ('doc'): + if ttag not in dim_other_parts: + dim_other_parts[ttag] = [] + text = cchild.text + dim_other_parts[ttag].append(text.strip()) + child.remove(cchild) + continue + # taking care of other attributes except index and value + for attr, value in child_attrs.items(): + if attr in possible_dim_attrs: + if attr not in dim_other_parts: + dim_other_parts[attr] = [] + dim_other_parts[attr].append(value) + if tag == CMNT_TAG and self.include_comment: + # Store and remove node so that comment nodes from dim node so + # that it does not call in xmlparser function + dim_cmnt_node.append(child) + node.remove(child) + + # All 'dim' element comments on top of 'dim' yaml key + if dim_cmnt_node: + for ch_nd in dim_cmnt_node: + self.handel_comment(depth + 1, ch_nd, file_out) + # index and value attributes of dim elements + file_out.write( + '{indent}dim: [{value}]\n'.format( + indent=(depth + 1) * DEPTH_SIZE, + value=dim_index_value[:-2] or '')) + # Write the attributes, except index and value, and doc of dim as child of dim_parameter. + # But tthe doc or attributes for each dim come inside list according to the order of dim. + if dim_other_parts: + file_out.write( + '{indent}dim_parameters:\n'.format( + indent=(depth + 1) * DEPTH_SIZE)) + # depth = depth + 2 dim_paramerter has child such as doc of dim + indent = (depth + 2) * DEPTH_SIZE + for key, value in dim_other_parts.items(): + if key == 'doc': + value = self.handle_not_root_level_doc(depth + 2, str(value), key, file_out) + else: + # Increase depth size inside handle_map...() for writting text with one + # more indentation. + file_out.write(f"{indent}{key}: " + f"{handle_mapping_char(value, depth + 3, False)}\n") + + def handle_enumeration(self, depth, node, file_out): + """ + Handle the enumeration field parsed from the xml file. + + If the enumeration items contain a doc field, the yaml file will contain items as child + fields of the enumeration field. + + If no doc are inherited in the enumeration items, a list of the items is given for the + enumeration list. + + """ + # pylint: disable=consider-using-f-string + + check_doc = [] + for child in list(node): + if list(child): + check_doc.append(list(child)) + # pylint: disable=too-many-nested-blocks + if check_doc: + file_out.write( + '{indent}{tag}: \n'.format( + indent=depth * DEPTH_SIZE, + tag=node.tag.split("}", 1)[1])) + for child in list(node): + tag = remove_namespace_from_tag(child.tag) + itm_depth = depth + 1 + if tag == ('item'): + file_out.write( + '{indent}{value}: \n'.format( + indent=(itm_depth) * DEPTH_SIZE, + value=child.attrib['value'])) + + if list(child): + for item_doc in list(child): + if remove_namespace_from_tag(item_doc.tag) == 'doc': + item_doc_depth = itm_depth + 1 + self.handle_not_root_level_doc(item_doc_depth, item_doc.text, + item_doc.tag, file_out) + if (remove_namespace_from_tag(item_doc.tag) == CMNT_TAG + and self.include_comment): + self.handel_comment(itm_depth + 1, item_doc, file_out) + if tag == CMNT_TAG and self.include_comment: + self.handel_comment(itm_depth + 1, child, file_out) + else: + enum_list = '' + remove_nodes = [] + for item_child in list(node): + tag = remove_namespace_from_tag(item_child.tag) + if tag == ('item'): + enum_list = enum_list + '{value}, '.format( + value=item_child.attrib['value']) + if tag == CMNT_TAG and self.include_comment: + self.handel_comment(depth, item_child, file_out) + remove_nodes.append(item_child) + for ch_node in remove_nodes: + node.remove(ch_node) + + file_out.write( + '{indent}{tag}: [{enum_list}]\n'.format( + indent=depth * DEPTH_SIZE, + tag=remove_namespace_from_tag(node.tag), + enum_list=enum_list[:-2] or '')) + + def handle_attributes(self, depth, node, file_out): + """Handle the attributes parsed from the xml file""" + + allowed_attr = ['name', 'type', 'units', 'nameType', 'recommended', 'optional', + 'minOccurs', 'maxOccurs', 'deprecated'] + + name = "" + node_attr = node.attrib + if 'name' in node_attr: + pass + else: + raise ValueError("Attribute must have an name key.") + rm_key_list = [] + # Maintain order: name and type in form name(type) or (type)name that come first + for key, val in node_attr.items(): + if key == 'name': + name = val + rm_key_list.append(key) + + for key in rm_key_list: + del node_attr[key] + + file_out.write('{indent}{escapesymbol}{name}:\n'.format( + indent=depth * DEPTH_SIZE, + escapesymbol=r'\@', + name=name)) + + tmp_dict = {} + exists_dict = {} + for key, val in node_attr.items(): + # As both 'minOccurs', 'maxOccurs' and optionality move to the 'exists' + if key in ['minOccurs', 'maxOccurs', 'optional', 'recommended', 'required']: + if 'exists' not in tmp_dict: + tmp_dict['exists'] = [] + self.handle_exists(exists_dict, key, val) + elif key == 'units': + tmp_dict['unit'] = val + else: + tmp_dict[key] = val + if key not in allowed_attr: + raise ValueError(f"An attribute ({key}) has been found that is not allowed." + f"The allowed attr is {allowed_attr}.") + + has_min_max = False + has_opt_reco_requ = False + if exists_dict: + for key, val in exists_dict.items(): + if key in ['minOccurs', 'maxOccurs']: + tmp_dict['exists'] = tmp_dict['exists'] + val + has_min_max = True + elif key in ['optional', 'recommended', 'required']: + tmp_dict['exists'] = key + has_opt_reco_requ = True + if has_min_max and has_opt_reco_requ: + raise ValueError("Optionality 'exists' can take only either from ['minOccurs'," + " 'maxOccurs'] or from ['optional', 'recommended', 'required']" + ". But not from both of the groups together. Please check in" + " attributes") + + depth_ = depth + 1 + for key, val in tmp_dict.items(): + # Increase depth size inside handle_map...() for writting text with one + # more indentation. + file_out.write(f'{depth_ * DEPTH_SIZE}{key}: ' + f'{handle_mapping_char(val, depth_ + 1, False)}\n') + + def handel_link(self, depth, node, file_out): + """ + Handle link elements of nxdl + """ + + possible_link_attrs = ['name', 'target', 'napimount'] + node_attr = node.attrib + # Handle special cases + if 'name' in node_attr: + file_out.write('{indent}{name}(link):\n'.format( + indent=depth * DEPTH_SIZE, + name=node_attr['name'] or '')) + del node_attr['name'] + + depth_ = depth + 1 + # Handle general cases + for attr_key, val in node_attr.items(): + if attr_key in possible_link_attrs: + file_out.write('{indent}{attr}: {value}\n'.format( + indent=depth_ * DEPTH_SIZE, + attr=attr_key, + value=val)) + else: + raise ValueError(f"An anexpected attribute '{attr_key}' of link has found." + f"At this moment the alloed keys are {possible_link_attrs}") + + def handel_choice(self, depth, node, file_out): + """ + Handle choice element which is a parent node of group. + """ + + possible_attr = [] + + node_attr = node.attrib + # Handle special casees + if 'name' in node_attr: + file_out.write('{indent}{attr}(choice): \n'.format( + indent=depth * DEPTH_SIZE, + attr=node_attr['name'])) + del node_attr['name'] + + depth_ = depth + 1 + # Taking care of general attrinutes. Though, still no attrinutes have found, + # but could be used for future + for attr in node_attr.items(): + if attr in possible_attr: + file_out.write('{indent}{attr}: {value}\n'.format( + indent=depth_ * DEPTH_SIZE, + attr=attr, + value=node_attr[attr])) + else: + raise ValueError(f"An unexpected attribute '{attr}' of 'choice' has been found." + f"At this moment attributes for choice {possible_attr}") + + def handel_comment(self, depth, node, file_out): + """ + Collect comment element and pass to write_out function + """ + indent = depth * DEPTH_SIZE + if self.is_last_element_comment: + text = self.comvert_to_ymal_comment(indent, node.text) + self.write_out(indent, text, file_out) + else: + text = self.comvert_to_ymal_comment(indent, node.text) + self.write_out(indent, text, file_out) + self.is_last_element_comment = True + + def recursion_in_xml_tree(self, depth, xml_tree, output_yml, verbose): + """ + Descend lower level in xml tree. If we are in the symbols branch, the recursive + behaviour is not triggered as we already handled the symbols' childs. + """ + + tree = xml_tree['tree'] + node = xml_tree['node'] + for child in list(node): + xml_tree_children = {'tree': tree, 'node': child} + self.xmlparse(output_yml, xml_tree_children, depth, verbose) + + # pylint: disable=too-many-branches, too-many-statements + def xmlparse(self, output_yml, xml_tree, depth, verbose): + """ + Main of the nxdl2yaml converter. + It parses XML tree, then prints recursively each level of the tree + """ + tree = xml_tree['tree'] + node = xml_tree['node'] + if verbose: + sys.stdout.write(f'Node tag: {remove_namespace_from_tag(node.tag)}\n') + sys.stdout.write(f'Attributes: {node.attrib}\n') + with open(output_yml, "a", encoding="utf-8") as file_out: + tag = remove_namespace_from_tag(node.tag) + if tag == ('definition'): + self.found_definition = True + self.handle_definition(node) + # Taking care of root level doc and symbols + remove_cmnt_n = None + last_comment = '' + for child in list(node): + tag_tmp = remove_namespace_from_tag(child.tag) + if tag_tmp == CMNT_TAG and self.include_comment: + last_comment = self.comvert_to_ymal_comment(depth * DEPTH_SIZE, child.text) + remove_cmnt_n = child + if tag_tmp == 'doc': + self.stroe_root_level_comments('root_doc', last_comment) + last_comment = '' + self.handle_root_level_doc(child) + node.remove(child) + if remove_cmnt_n is not None: + node.remove(remove_cmnt_n) + remove_cmnt_n = None + if tag_tmp == 'symbols': + self.stroe_root_level_comments('symbols', last_comment) + last_comment = '' + self.handle_symbols(depth, child) + node.remove(child) + if remove_cmnt_n is not None: + node.remove(remove_cmnt_n) + remove_cmnt_n = None + + if tag == ('doc') and depth != 1: + parent = get_node_parent_info(tree, node)[0] + doc_parent = remove_namespace_from_tag(parent.tag) + if doc_parent != 'item': + self.handle_not_root_level_doc(depth, text=node.text, + tag=node.tag, + file_out=file_out) + + if self.found_definition is True and self.root_level_doc: + self.print_root_level_info(depth, file_out) + # End of print root-level definitions in file + if tag in ('field', 'group') and depth != 0: + self.handle_group_or_field(depth, node, file_out) + if tag == ('enumeration'): + self.handle_enumeration(depth, node, file_out) + if tag == ('attribute'): + self.handle_attributes(depth, node, file_out) + if tag == ('dimensions'): + self.handle_dimension(depth, node, file_out) + if tag == ('link'): + self.handel_link(depth, node, file_out) + if tag == ('choice'): + self.handel_choice(depth, node, file_out) + if tag == CMNT_TAG and self.include_comment: + self.handel_comment(depth, node, file_out) + depth += 1 + # Write nested nodes + self.recursion_in_xml_tree(depth, xml_tree, output_yml, verbose) + + +def compare_niac_and_my(tree, tree2, verbose, node, root_no_duplicates): + """This function creates two trees with Niac XML file and My XML file. +The main aim is to compare the two trees and create a new one that is the +union of the two initial trees. + +""" + root = tree.getroot() + root2 = tree2.getroot() + attrs_list_niac = [] + for nodo in root.iter(node): + attrs_list_niac.append(nodo.attrib) + if verbose: + sys.stdout.write('Attributes found in Niac file: \n') + sys.stdout.write(str(attrs_list_niac) + '\n') + sys.stdout.write(' \n') + sys.stdout.write('Started merging of Niac and My file... \n') + for elem in root.iter(node): + if verbose: + sys.stdout.write('- Niac element inserted: \n') + sys.stdout.write(str(elem.attrib) + '\n') + index = get_node_parent_info(tree, elem)[1] + root_no_duplicates.insert(index, elem) + + for elem2 in root2.iter(node): + index = get_node_parent_info(tree2, elem2)[1] + if elem2.attrib not in attrs_list_niac: + if verbose: + sys.stdout.write('- My element inserted: \n') + sys.stdout.write(str(elem2.attrib) + '\n') + root_no_duplicates.insert(index, elem2) + + if verbose: + sys.stdout.write(' \n') + return root_no_duplicates diff --git a/nyaml2nxdl_forward_tools.py b/nyaml2nxdl_forward_tools.py new file mode 100644 index 0000000000..cee59d1f3d --- /dev/null +++ b/nyaml2nxdl_forward_tools.py @@ -0,0 +1,1072 @@ +#!/usr/bin/env python3 +"""Creates an instantiated NXDL schema XML tree by walking the dictionary nest + +""" +# -*- coding: utf-8 -*- +# +# 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. +# + +import sys +import xml.etree.ElementTree as ET +from xml.dom import minidom +import os +import textwrap + +import yaml + +from pynxtools.nexus import nexus +from pynxtools.nyaml2nxdl.comment_collector import CommentCollector +from pynxtools.nyaml2nxdl.nyaml2nxdl_helper import (get_yaml_escape_char_reverter_dict, + nx_name_type_resolving, + cleaning_empty_lines, LineLoader) + + +# pylint: disable=too-many-lines, global-statement, invalid-name +DOM_COMMENT = ("\n" + "# NeXus - Neutron and X-ray Common Data Format\n" + "# \n" + "# Copyright (C) 2014-2022 NeXus International Advisory Committee (NIAC)\n" + "# \n" + "# This library is free software; you can redistribute it and/or\n" + "# modify it under the terms of the GNU Lesser General Public\n" + "# License as published by the Free Software Foundation; either\n" + "# version 2 of the License, or (at your option) any later version.\n" + "#\n" + "# This library is distributed in the hope that it will be useful,\n" + "# but WITHOUT ANY WARRANTY; without even the implied warranty of\n" + "# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU\n" + "# Lesser General Public License for more details.\n" + "#\n" + "# You should have received a copy of the GNU Lesser General Public\n" + "# License along with this library; if not, write to the Free Software\n" + "# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA\n" + "#\n" + "# For further information, see http://www.nexusformat.org\n") +NX_CLSS = nexus.get_nx_classes() +NX_NEW_DEFINED_CLASSES = ['NX_COMPLEX'] +NX_TYPE_KEYS = nexus.get_nx_attribute_type() +NX_ATTR_IDNT = '\\@' +NX_UNIT_IDNT = 'unit' +DEPTH_SIZE = " " +NX_UNIT_TYPES = nexus.get_nx_units() +COMMENT_BLOCKS: CommentCollector + + +def yml_reader(inputfile): + """ + This function launches the LineLoader class. + It parses the yaml in a dict and extends it with line tag keys for each key of the dict. + """ + global COMMENT_BLOCKS + with open(inputfile, "r", encoding="utf-8") as plain_text_yaml: + loader = LineLoader(plain_text_yaml) + loaded_yaml = loader.get_single_data() + COMMENT_BLOCKS = CommentCollector(inputfile, loaded_yaml) + COMMENT_BLOCKS.extract_all_comment_blocks() + return loaded_yaml + + +def yml_reader_nolinetag(inputfile): + """ + pyyaml based parsing of yaml file in python dict + """ + with open(inputfile, 'r', encoding="utf-8") as stream: + parsed_yaml = yaml.safe_load(stream) + return parsed_yaml + + +def check_for_skiped_attributes(component, value, allowed_attr=None, verbose=False): + """ + Check for any attributes have been skipped or not. + NOTE: We should we should keep in mind about 'doc' + """ + block_tag = ['enumeration'] + if value: + for attr, val in value.items(): + if attr in ['doc']: + continue + if '__line__' in attr or attr in block_tag: + continue + line_number = f'__line__{attr}' + if verbose: + print(f"__line__ : {value[line_number]}") + if not isinstance(val, dict) \ + and '\\@' not in attr\ + and attr not in allowed_attr\ + and 'NX' not in attr and val: + + raise ValueError(f"An attribute '{attr}' in part '{component}' has been found" + f". Please check arround line '{value[line_number]}. At this " + f"moment. The allowed attrbutes are {allowed_attr}") + + +def check_optionality_and_write(obj, opl_key, opl_val): + """ + Taking care of optinality. + """ + if opl_key == 'optional': + if opl_val == 'false': + obj.set('required', 'true') + elif opl_key == 'minOccurs': + if opl_val == '0': + pass + else: + obj.set(opl_key, str(opl_val)) + + +def format_nxdl_doc(string): + """NeXus format for doc string + """ + string = check_for_mapping_char_other(string) + formatted_doc = '' + if "\n" not in string: + if len(string) > 80: + wrapped = textwrap.TextWrapper(width=80, + break_long_words=False, + replace_whitespace=False) + string = '\n'.join(wrapped.wrap(string)) + formatted_doc = '\n' + f"{string}" + else: + text_lines = string.split('\n') + text_lines = cleaning_empty_lines(text_lines) + formatted_doc += "\n" + "\n".join(text_lines) + if not formatted_doc.endswith("\n"): + formatted_doc += "\n" + return formatted_doc + + +def check_for_mapping_char_other(text): + """ + Check for mapping char \':\' which does not be passed through yaml library. + Then replace it by ':'. + """ + if not text: + text = '' + text = str(text) + if text == 'True': + text = 'true' + if text == 'False': + text = 'false' + # Some escape char is not valid in yaml libray which is written while writting + # yaml file. In the time of writting nxdl revert to that escape char. + escape_reverter = get_yaml_escape_char_reverter_dict() + for key, val in escape_reverter.items(): + if key in text: + text = text.replace(key, val) + return str(text) + + +def xml_handle_doc(obj, value: str, + line_number=None, line_loc=None): + """This function creates a 'doc' element instance, and appends it to an existing element + + """ + # global comment_bolcks + doc_elemt = ET.SubElement(obj, 'doc') + text = format_nxdl_doc(check_for_mapping_char_other(value)).strip() + # To keep the doc middle of doc tag. + doc_elemt.text = f"\n{text}\n" + if line_loc is not None and line_number is not None: + xml_handle_comment(obj, line_number, + line_loc, doc_elemt) + + +def xml_handle_units(obj, value): + """This function creates a 'units' element instance, and appends it to an existing element + + """ + obj.set('units', str(value)) + + +# pylint: disable=too-many-branches +def xml_handle_exists(dct, obj, keyword, value): + """ + This function creates an 'exists' element instance, and appends it to an existing element + """ + + line_number = f'__line__{keyword}' + assert value is not None, f'Line {dct[line_number]}: exists argument must not be None !' + if isinstance(value, list): + if len(value) == 2 and value[0] == 'min': + obj.set('minOccurs', str(value[1])) + elif len(value) == 2 and value[0] == 'max': + obj.set('maxOccurs', str(value[1])) + elif len(value) == 4 and value[0] == 'min' and value[2] == 'max': + obj.set('minOccurs', str(value[1])) + if str(value[3]) != 'infty': + obj.set('maxOccurs', str(value[3])) + else: + obj.set('maxOccurs', 'unbounded') + elif len(value) == 4 and value[0] == 'max' and value[2] == 'min': + obj.set('minOccurs', str(value[3])) + if str(value[1]) != 'infty': + obj.set('maxOccurs', str(value[3])) + else: + obj.set('maxOccurs', 'unbounded') + elif len(value) == 4 and (value[0] != 'min' or value[2] != 'max'): + raise ValueError(f'Line {dct[line_number]}: exists keyword' + f'needs to go either with an optional [recommended] list with two ' + f'entries either [min, ] or [max, ], or a list of four ' + f'entries [min, , max, ] !') + else: + raise ValueError(f'Line {dct[line_number]}: exists keyword ' + f'needs to go either with optional, recommended, a list with two ' + f'entries either [min, ] or [max, ], or a list of four ' + f'entries [min, , max, ] !') + else: + if value == 'optional': + obj.set('optional', 'true') + elif value == 'recommended': + obj.set('recommended', 'true') + elif value == 'required': + obj.set('required', 'true') + else: + obj.set('minOccurs', '0') + + +# pylint: disable=too-many-branches, too-many-locals, too-many-statements +def xml_handle_group(dct, obj, keyword, value, verbose=False): + """ + The function deals with group instances + """ + line_number = f'__line__{keyword}' + line_loc = dct[line_number] + xml_handle_comment(obj, line_number, line_loc) + list_of_attr = ['name', 'type', 'nameType', 'deprecated', 'optional', 'recommended', + 'exists', 'unit'] + l_bracket = -1 + r_bracket = -1 + if keyword.count('(') == 1: + l_bracket = keyword.index('(') + if keyword.count(')') == 1: + r_bracket = keyword.index(')') + + keyword_name, keyword_type = nx_name_type_resolving(keyword) + if not keyword_name and not keyword_type: + raise ValueError("A group must have both value and name. Check for group.") + grp = ET.SubElement(obj, 'group') + + # type come first + if l_bracket == 0 and r_bracket > 0: + grp.set('type', keyword_type) + if keyword_name: + grp.set('name', keyword_name) + elif l_bracket > 0: + grp.set('name', keyword_name) + if keyword_type: + grp.set('type', keyword_type) + else: + grp.set('name', keyword_name) + + if value: + rm_key_list = [] + for attr, vval in value.items(): + if '__line__' in attr: + continue + line_number = f"__line__{attr}" + line_loc = value[line_number] + if attr == 'doc': + xml_handle_doc(grp, vval, line_number, line_loc) + rm_key_list.append(attr) + rm_key_list.append(line_number) + elif attr == 'exists' and vval: + xml_handle_exists(value, grp, attr, vval) + rm_key_list.append(attr) + rm_key_list.append(line_number) + xml_handle_comment(obj, + line_number, line_loc, grp) + elif attr == 'unit': + xml_handle_units(grp, vval) + xml_handle_comment(obj, line_number, line_loc, grp) + elif attr in list_of_attr and not isinstance(vval, dict) and vval: + validate_field_attribute_and_value(attr, vval, list_of_attr, value) + grp.set(attr, check_for_mapping_char_other(vval)) + rm_key_list.append(attr) + rm_key_list.append(line_number) + xml_handle_comment(obj, line_number, line_loc, grp) + + for key in rm_key_list: + del value[key] + # Check for skipped attrinutes + check_for_skiped_attributes('group', value, list_of_attr, verbose) + if isinstance(value, dict) and value != {}: + recursive_build(grp, value, verbose) + + +def xml_handle_dimensions(dct, obj, keyword, value: dict): + """ + This function creates a 'dimensions' element instance, and appends it to an existing element + + NOTE: we could create xml_handle_dim() function. + But, the dim elements in yaml file is defined as 'dim =[[index, value]]' + but dim has other attributes such as 'ref' and also might have doc as chlid. + so in that sense 'dim' should have come as dict keeping attributes and child as members of + dict. + Regarding this situation all the attributes of 'dimensions' and child 'doc' has been + included here. + + Other attributes, except 'index' and 'value', of 'dim' comes under nested dict named + 'dim_parameter: + incr:[...]' + """ + + possible_dimension_attrs = ['rank'] + line_number = f'__line__{keyword}' + line_loc = dct[line_number] + assert 'dim' in value.keys(), (f"Line {line_loc}: No dim as child of dimension has " + f"been found.") + xml_handle_comment(obj, line_number, line_loc) + dims = ET.SubElement(obj, 'dimensions') + # Consider all the childs under dimension is dim element and + # its attributes +# val_attrs = list(value.keys()) + rm_key_list = [] + rank = '' + for key, val in value.items(): + if '__line__' in key: + continue + line_number = f"__line__{key}" + line_loc = value[line_number] + if key == 'rank': + rank = val or '' + if isinstance(rank, int) and rank < 0: + raise ValueError(f"Dimension must have some info about rank which is not " + f"available. Please check arround Line: {dct[line_number]}") + dims.set(key, str(val)) + rm_key_list.append(key) + rm_key_list.append(line_number) + xml_handle_comment(obj, line_number, line_loc, dims) + # Check dimension doc and handle it + elif key == 'doc' and isinstance(val, str): + xml_handle_doc(dims, val, line_number, line_loc) + rm_key_list.append(key) + rm_key_list.append(line_number) + elif key in possible_dimension_attrs and not isinstance(val, dict): + dims.set(key, str(val)) + rm_key_list.append(key) + rm_key_list.append(line_number) + xml_handle_comment(obj, line_number, line_loc, dims) + + for key in rm_key_list: + del value[key] + + xml_handle_dim_from_dimension_dict(dct, dims, keyword, value, rank=False) + + if isinstance(value, dict) and value != {}: + recursive_build(dims, value, verbose=None) + + +# pylint: disable=too-many-locals, too-many-arguments +def xml_handle_dim_from_dimension_dict(dct, dims_obj, keyword, value, rank, verbose=False): + """ + Handling dim element. + NOTE: The inputs 'keyword' and 'value' are as input for xml_handle_dimensions + function. please also read note in xml_handle_dimensions. + """ + + possible_dim_attrs = ['ref', 'optional', 'recommended', 'required', 'incr', 'refindex'] + header_line_number = f"__line__{keyword}" + dim_list = [] + rm_key_list = [] + # NOTE: dim doc and other attributes except 'index' and 'value' will come as list of value + # under dim_parameters + if not value: + return + rank = '' + # pylint: disable=too-many-nested-blocks + for attr, vvalue in value.items(): + if '__line__' in attr: + continue + + line_number = f"__line__{attr}" + line_loc = value[line_number] + # dim comes in precedence + if attr == 'dim': + # dim consists of list of [index, value] + llist_ind_value = vvalue + assert isinstance(llist_ind_value, list), (f'Line {value[line_number]}: dim' + f'argument not a list !') + xml_handle_comment(dims_obj, line_number, line_loc) + if isinstance(rank, int) and rank > 0: + assert rank == len(llist_ind_value), ( + f"Wrong dimension rank check around Line {dct[header_line_number]}.\n" + f"Line {[dct[header_line_number]]} rank value {rank} " + f"is not the same as dim array = " + f"{len(llist_ind_value)}.") + # Taking care of ind and value that comes as list of list + for dim_ind_val in llist_ind_value: + dim = ET.SubElement(dims_obj, 'dim') + + # Taking care of multidimensions or rank + if len(dim_ind_val) >= 1 and dim_ind_val[0]: + dim.set('index', str(dim_ind_val[0])) + if len(dim_ind_val) == 2 and dim_ind_val[1]: + dim.set('value', str(dim_ind_val[1])) + dim_list.append(dim) + rm_key_list.append(attr) + rm_key_list.append(line_number) + elif attr == 'dim_parameters' and isinstance(vvalue, dict): + xml_handle_comment(dims_obj, line_number, line_loc) + for kkkey, vvval in vvalue.items(): + if '__line__' in kkkey: + continue + cmnt_number = f'__line__{kkkey}' + cmnt_loc = vvalue[cmnt_number] + if kkkey == 'doc' and dim_list: + # doc comes as list of doc + for i, dim in enumerate(dim_list): + if isinstance(vvval, list) and i < len(vvval): + tmp_val = vvval[i] + xml_handle_doc(dim, vvval[i], cmnt_number, cmnt_loc) + # Check all the dim have doc if not skip + elif isinstance(vvval, list) and i >= len(vvval): + pass + else: + for i, dim in enumerate(dim_list): + # all atribute of dims comes as list + if isinstance(vvval, list) and i < len(vvval): + tmp_val = vvval[i] + dim.set(kkkey, str(tmp_val)) + + # Check all the dim have doc if not skip + elif isinstance(vvval, list) and i >= len(vvval): + pass + # All dim might have the same value for the same attribute + elif not isinstance(vvval, list): + tmp_val = value + dim.set(kkkey, str(tmp_val)) + rm_key_list.append(attr) + rm_key_list.append(line_number) + else: + raise ValueError(f"Got unexpected block except 'dim' and 'dim_parameters'." + f"Please check arround line {line_number}") + + for key in rm_key_list: + del value[key] + + check_for_skiped_attributes('dim', value, possible_dim_attrs, verbose) + + +def xml_handle_enumeration(dct, obj, keyword, value, verbose): + """This function creates an 'enumeration' element instance. + + Two cases are handled: + 1) the items are in a list + 2) the items are dictionaries and may contain a nested doc + """ + line_number = f'__line__{keyword}' + line_loc = dct[line_number] + xml_handle_comment(obj, line_number, line_loc) + enum = ET.SubElement(obj, 'enumeration') + + assert value is not None, f'Line {line_loc}: enumeration must \ +bear at least an argument !' + assert len( + value) >= 1, f'Line {dct[line_number]}: enumeration must not be an empty list!' + if isinstance(value, list): + for element in value: + itm = ET.SubElement(enum, 'item') + itm.set('value', str(element)) + if isinstance(value, dict) and value != {}: + for element in value.keys(): + if '__line__' not in element: + itm = ET.SubElement(enum, 'item') + itm.set('value', str(element)) + if isinstance(value[element], dict): + recursive_build(itm, value[element], verbose) + + +# pylint: disable=unused-argument +def xml_handle_link(dct, obj, keyword, value, verbose): + """ + If we have an NXDL link we decode the name attribute from (link)[:-6] + """ + + line_number = f"__line__{keyword}" + line_loc = dct[line_number] + xml_handle_comment(obj, line_number, line_loc) + possible_attrs = ['name', 'target', 'napimount'] + name = keyword[:-6] + link_obj = ET.SubElement(obj, 'link') + link_obj.set('name', str(name)) + + if value: + rm_key_list = [] + for attr, vval in value.items(): + if '__line__' in attr: + continue + line_number = f"__line__{attr}" + line_loc = value[line_number] + if attr == 'doc': + xml_handle_doc(link_obj, vval, line_number, line_loc) + rm_key_list.append(attr) + rm_key_list.append(line_number) + elif attr in possible_attrs and not isinstance(vval, dict): + if vval: + link_obj.set(attr, str(vval)) + rm_key_list.append(attr) + rm_key_list.append(line_number) + xml_handle_comment(obj, line_number, line_loc, link_obj) + + for key in rm_key_list: + del value[key] + # Check for skipped attrinutes + check_for_skiped_attributes('link', value, possible_attrs, verbose) + + if isinstance(value, dict) and value != {}: + recursive_build(link_obj, value, verbose=None) + + +def xml_handle_choice(dct, obj, keyword, value, verbose=False): + """ + Build choice xml elements. That consists of groups. + """ + line_number = f'__line__{keyword}' + line_loc = dct[line_number] + xml_handle_comment(obj, line_number, line_loc) + # Add attributes in possible if new attributs have been added nexus definition. + possible_attr = [] + choice_obj = ET.SubElement(obj, 'choice') + # take care of special attributes + name = keyword[:-8] + choice_obj.set('name', name) + + if value: + rm_key_list = [] + for attr, vval in value.items(): + if '__line__' in attr: + continue + line_number = f"__line__{attr}" + line_loc = value[line_number] + if attr == 'doc': + xml_handle_doc(choice_obj, vval, line_number, line_loc) + rm_key_list.append(attr) + rm_key_list.append(line_number) + elif attr in possible_attr and not isinstance(vval, dict): + if vval: + choice_obj.set(attr, str(vval)) + rm_key_list.append(attr) + rm_key_list.append(line_number) + xml_handle_comment(obj, line_number, line_loc, choice_obj) + + for key in rm_key_list: + del value[key] + # Check for skipped attrinutes + check_for_skiped_attributes('choice', value, possible_attr, verbose) + + if isinstance(value, dict) and value != {}: + recursive_build(choice_obj, value, verbose=None) + + +def xml_handle_symbols(dct, obj, keyword, value: dict): + """Handle a set of NXDL symbols as a child to obj + + """ + line_number = f'__line__{keyword}' + line_loc = dct[line_number] + assert len(list(value.keys()) + ) >= 1, f'Line {line_loc}: symbols table must not be empty !' + xml_handle_comment(obj, line_number, line_loc) + syms = ET.SubElement(obj, 'symbols') + if 'doc' in value.keys(): + line_number = '__line__doc' + line_loc = value[line_number] + xml_handle_comment(syms, line_number, line_loc) + doctag = ET.SubElement(syms, 'doc') + doctag.text = '\n' + textwrap.fill(value['doc'], width=70) + '\n' + rm_key_list = [] + for kkeyword, vvalue in value.items(): + if '__line__' in kkeyword: + continue + if kkeyword != 'doc': + line_number = f'__line__{kkeyword}' + line_loc = value[line_number] + xml_handle_comment(syms, line_number, line_loc) + assert vvalue is not None and isinstance( + vvalue, str), f'Line {line_loc}: put a comment in doc string !' + sym = ET.SubElement(syms, 'symbol') + sym.set('name', str(kkeyword)) + # sym_doc = ET.SubElement(sym, 'doc') + xml_handle_doc(sym, vvalue) + rm_key_list.append(kkeyword) + rm_key_list.append(line_number) + # sym_doc.text = '\n' + textwrap.fill(vvalue, width=70) + '\n' + for key in rm_key_list: + del value[key] + + +def check_keyword_variable(verbose, dct, keyword, value): + """ + Check whether both keyword_name and keyword_type are empty, + and complains if it is the case + """ + keyword_name, keyword_type = nx_name_type_resolving(keyword) + if verbose: + sys.stdout.write( + f'{keyword_name}({keyword_type}): value type is {type(value)}\n') + if keyword_name == '' and keyword_type == '': + line_number = f'__line__{keyword}' + raise ValueError(f'Line {dct[line_number]}: found an improper yaml key !') + + +def helper_keyword_type(kkeyword_type): + """ + This function is returning a value of keyword_type if it belong to NX_TYPE_KEYS + """ + if kkeyword_type in NX_TYPE_KEYS: + return kkeyword_type + return None + + +def verbose_flag(verbose, keyword, value): + """ + Verbose stdout printing for nested levels of yaml file, if verbose flag is active + """ + if verbose: + sys.stdout.write(f' key:{keyword}; value type is {type(value)}\n') + + +def xml_handle_attributes(dct, obj, keyword, value, verbose): + """Handle the attributes found connected to attribute field""" + + line_number = f"__line__{keyword}" + line_loc = dct[line_number] + xml_handle_comment(obj, line_number, line_loc) + # list of possible attribute of xml attribute elementsa + attr_attr_list = ['name', 'type', 'unit', 'nameType', + 'optional', 'recommended', 'minOccurs', + 'maxOccurs', 'deprecated', 'exists'] + # as an attribute identifier + keyword_name, keyword_typ = nx_name_type_resolving(keyword) + line_number = f'__line__{keyword}' + if verbose: + print(f"__line__ : {dct[line_number]}") + if keyword_name == '' and keyword_typ == '': + raise ValueError(f'Line {dct[line_number]}: found an improper yaml key !') + elemt_obj = ET.SubElement(obj, 'attribute') + elemt_obj.set('name', keyword_name[2:]) + if keyword_typ: + elemt_obj.set('type', keyword_typ) + + rm_key_list = [] + if value and value: + # taking care of attributes of attributes + for attr, attr_val in value.items(): + if '__line__' in attr: + continue + line_number = f"__line__{attr}" + line_loc = value[line_number] + if attr in ['doc', *attr_attr_list] and not isinstance(attr_val, dict): + if attr == 'unit': + elemt_obj.set(f"{attr}s", str(value[attr])) + rm_key_list.append(attr) + rm_key_list.append(line_number) + xml_handle_comment(obj, line_number, line_loc, elemt_obj) + elif attr == 'exists' and attr_val: + xml_handle_exists(value, elemt_obj, attr, attr_val) + rm_key_list.append(attr) + rm_key_list.append(line_number) + xml_handle_comment(obj, line_number, line_loc, elemt_obj) + elif attr == 'doc': + xml_handle_doc(elemt_obj, format_nxdl_doc(attr_val), + line_number, line_loc) + rm_key_list.append(attr) + rm_key_list.append(line_number) + else: + elemt_obj.set(attr, check_for_mapping_char_other(attr_val)) + rm_key_list.append(attr) + rm_key_list.append(line_number) + xml_handle_comment(obj, line_number, line_loc, elemt_obj) + + for key in rm_key_list: + del value[key] + # Check cor skiped attribute + check_for_skiped_attributes('Attribute', value, attr_attr_list, verbose) + if value: + recursive_build(elemt_obj, value, verbose) + + +def validate_field_attribute_and_value(v_attr, vval, allowed_attribute, value): + """ + Check for any attributes that comes with invalid name, + and invalid value. + """ + + # check for empty val + if (not isinstance(vval, dict) + and not str(vval)): # check for empty value + + line_number = f"__line__{v_attr}" + raise ValueError(f"In a field a valid attrbute ('{v_attr}') found that is not stored." + f" Please check arround line {value[line_number]}") + + # The bellow elements might come as child element + skipped_child_name = ['doc', 'dimension', 'enumeration', 'choice', 'exists'] + # check for invalid key or attributes + if (v_attr not in [*skipped_child_name, *allowed_attribute] + and '__line__' not in v_attr + and not isinstance(vval, dict) + and '(' not in v_attr # skip only groups and field that has name and type + and '\\@' not in v_attr): # skip nexus attributes + + line_number = f"__line__{v_attr}" + raise ValueError(f"In a field or group a invalid attribute ('{v_attr}') or child has found." + f" Please check arround line {value[line_number]}.") + + +def xml_handle_fields(obj, keyword, value, line_annot, line_loc, verbose=False): + """ + Handle a field in yaml file. + When a keyword is NOT: + symbol, + NX baseclass member, + attribute (\\@), + doc, + enumerations, + dimension, + exists, + then the not empty keyword_name is a field! + This simple function will define a new node of xml tree + """ + + # List of possible attributes of xml elements + allowed_attr = ['name', 'type', 'nameType', 'unit', 'minOccurs', 'long_name', + 'axis', 'signal', 'deprecated', 'axes', 'exists', + 'data_offset', 'interpretation', 'maxOccurs', + 'primary', 'recommended', 'optional', 'stride'] + + xml_handle_comment(obj, line_annot, line_loc) + l_bracket = -1 + r_bracket = -1 + if keyword.count('(') == 1: + l_bracket = keyword.index('(') + if keyword.count(')') == 1: + r_bracket = keyword.index(')') + + keyword_name, keyword_type = nx_name_type_resolving(keyword) + if not keyword_type and not keyword_name: + raise ValueError("Check for name or type in field.") + elemt_obj = ET.SubElement(obj, 'field') + + # type come first + if l_bracket == 0 and r_bracket > 0: + elemt_obj.set('type', keyword_type) + if keyword_name: + elemt_obj.set('name', keyword_name) + elif l_bracket > 0: + elemt_obj.set('name', keyword_name) + if keyword_type: + elemt_obj.set('type', keyword_type) + else: + elemt_obj.set('name', keyword_name) + + if value: + rm_key_list = [] + # In each each if clause apply xml_handle_comment(), to collect + # comments on that yaml line. + for attr, vval in value.items(): + if '__line__' in attr: + continue + line_number = f"__line__{attr}" + line_loc = value[line_number] + if attr == 'doc': + xml_handle_doc(elemt_obj, vval, line_number, line_loc,) + rm_key_list.append(attr) + rm_key_list.append(line_number) + elif attr == 'exists' and vval: + xml_handle_exists(value, elemt_obj, attr, vval) + rm_key_list.append(attr) + rm_key_list.append(line_number) + xml_handle_comment(obj, + line_number, + line_loc, elemt_obj) + elif attr == 'unit': + xml_handle_units(elemt_obj, vval) + xml_handle_comment(obj, + line_number, + line_loc, elemt_obj) + elif attr in allowed_attr and not isinstance(vval, dict) and vval: + validate_field_attribute_and_value(attr, vval, allowed_attr, value) + elemt_obj.set(attr, check_for_mapping_char_other(vval)) + rm_key_list.append(attr) + rm_key_list.append(line_number) + xml_handle_comment(obj, + line_number, + line_loc, elemt_obj) + + for key in rm_key_list: + del value[key] + # Check for skipped attrinutes + check_for_skiped_attributes('field', value, allowed_attr, verbose) + + if isinstance(value, dict) and value != {}: + recursive_build(elemt_obj, value, verbose) + + +def xml_handle_comment(obj: ET.Element, + line_annotation: str, + line_loc_no: int, + xml_ele: ET.Element = None, + is_def_cmnt: bool = False): + """ + Add xml comment: check for comments that has the same 'line_annotation' + (e.g. __line__data) and the same line_loc_no (e.g. 30). After that, i + does of three tasks: + 1. Returns list of comments texts (multiple members if element has multiple comments) + 2. Rearrange comment element and xml_ele where comment comes first. + 3. Append comment element when no xml_ele will no be provided. + """ + + line_info = (line_annotation, int(line_loc_no)) + if line_info in COMMENT_BLOCKS: + cmnt = COMMENT_BLOCKS.get_coment_by_line_info(line_info) + cmnt_text = cmnt.get_comment_text() + + if is_def_cmnt: + return cmnt_text + if xml_ele is not None: + obj.remove(xml_ele) + for string in cmnt_text: + si_comnt = ET.Comment(string) + obj.append(si_comnt) + obj.append(xml_ele) + elif not is_def_cmnt and xml_ele is None: + for string in cmnt_text: + si_comnt = ET.Comment(string) + obj.append(si_comnt) + else: + raise ValueError("Provied correct parameter values.") + return '' + + +def recursive_build(obj, dct, verbose): + """obj is the current node of the XML tree where we want to append to, + dct is a dictionary object which represents the content of a child to obj + dct may contain further dictionary nests, representing NXDL groups, + which trigger recursive processing + NXDL fields may contain attributes but trigger no recursion so attributes are leafs. + + """ + for keyword, value in iter(dct.items()): + if '__line__' in keyword: + continue + line_number = f"__line__{keyword}" + line_loc = dct[line_number] + keyword_name, keyword_type = nx_name_type_resolving(keyword) + check_keyword_variable(verbose, dct, keyword, value) + if verbose: + sys.stdout.write( + f'keyword_name:{keyword_name} keyword_type {keyword_type}\n') + + if keyword[-6:] == '(link)': + xml_handle_link(dct, obj, keyword, value, verbose) + elif keyword[-8:] == '(choice)': + xml_handle_choice(dct, obj, keyword, value) + # The bellow xml_symbol clause is for the symbols that come ubde filed or attributes + # Root level symbols has been inside nyaml2nxdl() + elif keyword_type == '' and keyword_name == 'symbols': + xml_handle_symbols(dct, obj, keyword, value) + + elif ((keyword_type in NX_CLSS) or (keyword_type not in + [*NX_TYPE_KEYS, '', *NX_NEW_DEFINED_CLASSES])): + # we can be sure we need to instantiate a new group + xml_handle_group(dct, obj, keyword, value, verbose) + + elif keyword_name[0:2] == NX_ATTR_IDNT: # check if obj qualifies + xml_handle_attributes(dct, obj, keyword, value, verbose) + elif keyword == 'doc': + xml_handle_doc(obj, value, line_number, line_loc) + elif keyword == NX_UNIT_IDNT: + xml_handle_units(obj, value) + elif keyword == 'enumeration': + xml_handle_enumeration(dct, obj, keyword, value, verbose) + + elif keyword == 'dimensions': + xml_handle_dimensions(dct, obj, keyword, value) + + elif keyword == 'exists': + xml_handle_exists(dct, obj, keyword, value) + # Handles fileds e.g. AXISNAME + elif keyword_name != '' and '__line__' not in keyword_name: + xml_handle_fields(obj, keyword, + value, line_number, + line_loc, verbose) + else: + raise ValueError(f"An unfamiliar type of element {keyword} has been found which is " + f"not be able to be resolved. Chekc arround line {dct[line_number]}") + + +def pretty_print_xml(xml_root, output_xml, def_comments=None): + """ + Print better human-readable indented and formatted xml file using + built-in libraries and preceding XML processing instruction + """ + dom = minidom.parseString(ET.tostring( + xml_root, encoding='utf-8', method='xml')) + proc_instractionn = dom.createProcessingInstruction( + 'xml-stylesheet', 'type="text/xsl" href="nxdlformat.xsl"') + dom_comment = dom.createComment(DOM_COMMENT) + root = dom.firstChild + dom.insertBefore(proc_instractionn, root) + dom.insertBefore(dom_comment, root) + + if def_comments: + for string in def_comments: + def_comt_ele = dom.createComment(string) + dom.insertBefore(def_comt_ele, root) + + xml_string = dom.toprettyxml(indent=1 * DEPTH_SIZE, newl='\n', encoding='UTF-8') + with open('tmp.xml', "wb") as file_tmp: + file_tmp.write(xml_string) + flag = False + with open('tmp.xml', "r", encoding="utf-8") as file_out: + with open(output_xml, "w", encoding="utf-8") as file_out_mod: + for i in file_out.readlines(): + if '' not in i and '' not in i and flag is False: + file_out_mod.write(i) + elif '' in i and '' in i: + file_out_mod.write(i) + elif '' in i and '' not in i: + flag = True + white_spaces = len(i) - len(i.lstrip()) + file_out_mod.write(i) + elif '' not in i and '' not in i and flag is True: + file_out_mod.write((white_spaces + 5) * ' ' + i) + elif '' not in i and '' in i and flag is True: + file_out_mod.write(white_spaces * ' ' + i) + flag = False + os.remove('tmp.xml') + + +# pylint: disable=too-many-statements +def nyaml2nxdl(input_file: str, out_file, verbose: bool): + """ + Main of the nyaml2nxdl converter, creates XML tree, namespace and + schema, definitions then evaluates a dictionary nest of groups recursively and + fields or (their) attributes as childs of the groups + """ + + def_attributes = ['deprecated', 'ignoreExtraGroups', 'category', 'type', + 'ignoreExtraFields', 'ignoreExtraAttributes', 'restricts'] + yml_appdef = yml_reader(input_file) + def_cmnt_text = [] + if verbose: + sys.stdout.write(f'input-file: {input_file}\n') + sys.stdout.write('application/base contains the following root-level entries:\n') + sys.stdout.write(str(yml_appdef.keys())) + xml_root = ET.Element('definition', {}) + assert 'category' in yml_appdef.keys( + ), 'Required root-level keyword category is missing!' + assert yml_appdef['category'] in ['application', 'base'], 'Only \ +application and base are valid categories!' + assert 'doc' in yml_appdef.keys(), 'Required root-level keyword doc is missing!' + + name_extends = '' + yml_appdef_copy = yml_appdef.copy() + for kkey, vvalue in yml_appdef_copy.items(): + if '__line__' in kkey: + continue + line_number = f"__line__{kkey}" + line_loc_no = yml_appdef[line_number] + if not isinstance(vvalue, dict) and kkey in def_attributes: + xml_root.set(kkey, str(vvalue) or '') + cmnt_text = xml_handle_comment(xml_root, + line_number, line_loc_no, + is_def_cmnt=True) + def_cmnt_text += cmnt_text if cmnt_text else [] + + del yml_appdef[line_number] + del yml_appdef[kkey] + # Taking care or name and extends + elif 'NX' in kkey: + # Tacking the attribute order but the correct value will be stored later + # check for name first or type first if (NXobject)NXname then type first + l_bracket_ind = kkey.rfind('(') + r_bracket_ind = kkey.rfind(')') + if l_bracket_ind == 0: + extend = kkey[1:r_bracket_ind] + name = kkey[r_bracket_ind + 1:] + xml_root.set('extends', extend) + xml_root.set('name', name) + elif l_bracket_ind > 0: + name = kkey[0:l_bracket_ind] + extend = kkey[l_bracket_ind + 1: r_bracket_ind] + xml_root.set('name', name) + xml_root.set('extends', extend) + else: + name = kkey + xml_root.set('name', name) + xml_root.set('extends', 'NXobject') + cmnt_text = xml_handle_comment(xml_root, + line_number, line_loc_no, + is_def_cmnt=True) + def_cmnt_text += cmnt_text if cmnt_text else [] + + name_extends = kkey + + if 'type' not in xml_root.attrib: + xml_root.set('type', "group") + # Taking care of namespaces + namespaces = {'xmlns': 'http://definition.nexusformat.org/nxdl/3.1', + 'xmlns:xsi': 'http://www.w3.org/2001/XMLSchema-instance', + 'xsi:schemaLocation': 'http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd'} + for key, ns_ in namespaces.items(): + xml_root.attrib[key] = ns_ + # Taking care of Symbols elements + if 'symbols' in yml_appdef.keys(): + xml_handle_symbols(yml_appdef, + xml_root, + 'symbols', + yml_appdef['symbols']) + + del yml_appdef['symbols'] + del yml_appdef["__line__symbols"] + + assert isinstance(yml_appdef['doc'], str) and yml_appdef['doc'] != '', 'Doc \ +has to be a non-empty string!' + + line_number = '__line__doc' + line_loc_no = yml_appdef[line_number] + xml_handle_doc(xml_root, yml_appdef['doc'], line_number, line_loc_no) + + del yml_appdef['doc'] + + root_keys = 0 + for key in yml_appdef.keys(): + if '__line__' not in key: + root_keys += 1 + extra_key = key + + assert root_keys == 1, (f"Accepting at most keywords: category, doc, symbols, and NX... " + f"at root-level! check key at root level {extra_key}") + + assert ('NX' in name_extends and len(name_extends) > 2), 'NX \ +keyword has an invalid pattern, or is too short!' + # Taking care if definition has empty content + if yml_appdef[name_extends]: + recursive_build(xml_root, yml_appdef[name_extends], verbose) + # Taking care of comments that comes at the end of file that is might not be intended for + # any nxdl elements. + if COMMENT_BLOCKS[-1].has_post_comment: + post_comment = COMMENT_BLOCKS[-1] + (lin_annot, line_loc) = post_comment.get_line_info() + xml_handle_comment(xml_root, lin_annot, line_loc) + + pretty_print_xml(xml_root, out_file, def_cmnt_text) + if verbose: + sys.stdout.write('Parsed YAML to NXDL successfully\n') diff --git a/nyaml2nxdl_helper.py b/nyaml2nxdl_helper.py new file mode 100644 index 0000000000..0fb51237d7 --- /dev/null +++ b/nyaml2nxdl_helper.py @@ -0,0 +1,145 @@ +#!/usr/bin/env python3 +"""Main file of yaml2nxdl tool. +Users create NeXus instances by writing a YAML file +which details a hierarchy of data/metadata elements + +""" +# -*- coding: utf-8 -*- +# +# 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. +# + + +# Yaml library does not except the keys (escapechar "\t" and yaml separator ":") +# So the corresponding value is to skip them and +# and also carefull about this order +from yaml.composer import Composer +from yaml.constructor import Constructor + +from yaml.nodes import ScalarNode +from yaml.resolver import BaseResolver +from yaml.loader import Loader + +ESCAPE_CHAR_DICT = {"\t": " "} + + +class LineLoader(Loader): # pylint: disable=too-many-ancestors + """ + LineLoader parses a yaml into a python dictionary extended with extra items. + The new items have as keys __line__ and as values the yaml file line number + """ + + def compose_node(self, parent, index): + # the line number where the previous token has ended (plus empty lines) + node = Composer.compose_node(self, parent, index) + node.__line__ = self.line + 1 + return node + + def construct_mapping(self, node, deep=False): + node_pair_lst = node.value + node_pair_lst_for_appending = [] + + for key_node in node_pair_lst: + shadow_key_node = ScalarNode( + tag=BaseResolver.DEFAULT_SCALAR_TAG, value='__line__' + key_node[0].value) + shadow_value_node = ScalarNode( + tag=BaseResolver.DEFAULT_SCALAR_TAG, value=key_node[0].__line__) + node_pair_lst_for_appending.append( + (shadow_key_node, shadow_value_node)) + + node.value = node_pair_lst + node_pair_lst_for_appending + return Constructor.construct_mapping(self, node, deep=deep) + + +def get_yaml_escape_char_dict(): + """Get escape char and the way to skip them in yaml.""" + return ESCAPE_CHAR_DICT + + +def get_yaml_escape_char_reverter_dict(): + """To revert yaml escape char in xml constructor from yaml.""" + temp_dict = {} + for key, val in ESCAPE_CHAR_DICT.items(): + temp_dict[val] = key + return temp_dict + + +def type_check(nx_type): + """ + Check for nexus type if type is NX_CHAR get '' or get as it is. + """ + + if nx_type in ['NX_CHAR', '']: + nx_type = '' + else: + nx_type = f"({nx_type})" + return nx_type + + +def get_node_parent_info(tree, node): + """ + Return tuple of (parent, index) where: + parent = node of parent within tree + index = index of node under parent + """ + + parent_map = {c: p for p in tree.iter() for c in p} + parent = parent_map[node] + return parent, list(parent).index(node) + + +def cleaning_empty_lines(line_list): + """ + Cleaning up empty lines on top and bottom. + """ + + if not isinstance(line_list, list): + line_list = line_list.split('\n') if '\n' in line_list else [''] + + # Clining up top empty lines + while True: + if line_list[0].strip(): + break + line_list = line_list[1:] + # Clining bottom empty lines + while True: + if line_list[-1].strip(): + break + line_list = line_list[0:-1] + + return line_list + + +def nx_name_type_resolving(tmp): + """ + extracts the eventually custom name {optional_string} + and type {nexus_type} from a YML section string. + YML section string syntax: optional_string(nexus_type) + """ + if tmp.count('(') == 1 and tmp.count(')') == 1: + # we can safely assume that every valid YML key resolves + # either an nx_ (type, base, candidate) class contains only 1 '(' and ')' + index_start = tmp.index('(') + index_end = tmp.index(')', index_start + 1) + typ = tmp[index_start + 1:index_end] + nam = tmp.replace('(' + typ + ')', '') + return nam, typ + + # or a name for a member + typ = '' + nam = tmp + return nam, typ From d413881a91633b5e7214bfa7fbb7bd78f20911dc Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Fri, 21 Apr 2023 17:10:43 +0200 Subject: [PATCH 0011/1012] Renames to pynxtools (#93) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Renames to pynxtools geändert: .github/workflows/pylint.yml geändert: .gitmodules modified: .github/workflows/pylint.yml * Properly adds definitions * Rename left over nexusutils reference from rebase * Merges xps reader.py --- test_nyaml2nxdl.py | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/test_nyaml2nxdl.py b/test_nyaml2nxdl.py index 5254f54640..75072131c1 100755 --- a/test_nyaml2nxdl.py +++ b/test_nyaml2nxdl.py @@ -28,8 +28,8 @@ import xml.etree.ElementTree as ET import pytest from click.testing import CliRunner -import nexusutils.nyaml2nxdl.nyaml2nxdl as nyml2nxdl -from nexusutils.nyaml2nxdl import nyaml2nxdl_forward_tools +import pynxtools.nyaml2nxdl.nyaml2nxdl as nyml2nxdl +from pynxtools.nyaml2nxdl import nyaml2nxdl_forward_tools def delete_duplicates(list_of_matching_string): @@ -293,8 +293,8 @@ def test_yml_consistency_comment_parsing(): """Test comments parsing from yaml. Convert 'yaml' input file to '.nxdl.xml' and '.nxdl.xml' to '.yaml' """ - from nexusutils.nyaml2nxdl.comment_collector import CommentCollector - from nexusutils.nyaml2nxdl.nyaml2nxdl_helper import LineLoader + from pynxtools.nyaml2nxdl.comment_collector import CommentCollector + from pynxtools.nyaml2nxdl.nyaml2nxdl_helper import LineLoader ref_yml_file = 'tests/data/nyaml2nxdl/Ref_NXcomment.yaml' test_yml_file = 'tests/data/nyaml2nxdl/Ref_NXcomment_consistency.yaml' From 76ff130d9a30344804c860def5e99b030bf537bf Mon Sep 17 00:00:00 2001 From: rettigl Date: Wed, 3 May 2023 16:35:43 +0200 Subject: [PATCH 0012/1012] First draft of NXmpes_arpes, and fix missing unit type in NXmpes --- contributed_definitions/nyaml/NXmpes.yaml | 8 +- .../nyaml/NXmpes_arpes.yaml | 121 ++++++++++++++++++ 2 files changed, 125 insertions(+), 4 deletions(-) create mode 100644 contributed_definitions/nyaml/NXmpes_arpes.yaml diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 6b82c6233f..14476396a1 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -74,7 +74,7 @@ NXmpes: unit: NX_ENERGY fast_axes(NX_CHAR): exists: recommended - slow_axes: + slow_axes(NX_CHAR): exists: recommended (NXcollectioncolumn): scheme: @@ -196,9 +196,9 @@ NXmpes: exists: recommended 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`. + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. preparation_date(NX_DATE_TIME): exists: recommended doc: "Date of preparation of the sample for the XPS experiment (i.e. cleaving, last annealing)." diff --git a/contributed_definitions/nyaml/NXmpes_arpes.yaml b/contributed_definitions/nyaml/NXmpes_arpes.yaml new file mode 100644 index 0000000000..5691620c1a --- /dev/null +++ b/contributed_definitions/nyaml/NXmpes_arpes.yaml @@ -0,0 +1,121 @@ +#Pincelli, Rettig, Arora at fhi-berlin.mpg.de, Dobener at hu-berlin.de, 06/2022 +#Draft version of a NeXus application definition for photoemission, +#It is designed to be extended by other application definitions +#with higher granularity in the data description. + +doc: This is an general application definition for angle-resolved multidimensional photoelectron spectroscopy. +category: application +NXmpes_arpes(NXmpes): + definition: + \@version: + enumeration: ["NXmpes_arpes"] + (NXinstrument): + angular_resolution(NX_FLOAT): + unit: NX_ANGLE + (NXelectronanalyser): + description: + angular_resolution(NX_FLOAT): + exists: recommended + doc: "Angular resolution of the electron analyser with the current setting. May be linked from a NXcalibration." + unit: NX_ANGLE + (NXcollectioncolumn): + scheme: + doc: "Scheme of the electron collection column." + enumeration: [ + "Standard", + "Angular dispersive", + "Deflector", + ] + (NXenergydispersion): + (NXdetector): + (NXdata): # Raw signal without calibrated axes. + exists: recommended + \@signal: + enumeration: ['raw'] + raw(NX_NUMBER): # There is a block of numbers named raw. + doc: "Raw data before calibration." + depends_on(NX_CHAR): + doc: "Reference to the beam coordinate system (.)." + transformations(NXtransformations): + trans_x[AXISNAME]: + exists: recommended + unit: NX_LENGTH + \@transformation_type: translation + \@vector: + \@depends_on: + trans_y[AXISNAME]: + exists: recommended + unit: NX_LENGTH + \@transformation_type: translation + \@vector: + \@depends_on: + trans_z[AXISNAME]: + exists: recommended + unit: NX_LENGTH + \@transformation_type: translation + \@vector: + \@depends_on: + rot_x[AXISNAME]: + unit: NX_LENGTH + \@transformation_type: rotation + \@vector: + \@depends_on: + rot_y[AXISNAME]: + unit: NX_LENGTH + \@transformation_type: rotation + \@vector: + \@depends_on: + rot_z[AXISNAME]: + unit: NX_LENGTH + \@transformation_type: rotation + \@vector: + \@depends_on: + (NXsample): + situation: + enumeration: ["vacuum"] + # Similar situation here, ca be a single number or a log. + depends_on(NX_CHAR): + doc: "Reference to a transformation describing the origin of the sample manipulator coordinate system relative to the beam coordinate system (.)." + transformations(NXtransformations): + trans_x[AXISNAME]: + exists: recommended + unit: NX_LENGTH + \@transformation_type: translation + \@vector: + \@depends_on: + trans_y[AXISNAME]: + exists: recommended + unit: NX_LENGTH + \@transformation_type: translation + \@vector: + \@depends_on: + trans_z[AXISNAME]: + exists: recommended + unit: NX_LENGTH + \@transformation_type: translation + \@vector: + \@depends_on: + rot_x[AXISNAME]: + unit: NX_LENGTH + \@transformation_type: rotation + \@vector: + \@depends_on: + rot_y[AXISNAME]: + unit: NX_LENGTH + \@transformation_type: rotation + \@vector: + \@depends_on: + rot_z[AXISNAME]: + unit: NX_LENGTH + \@transformation_type: rotation + \@vector: + \@depends_on: + + (NXdata): + \@signal: + enumeration: ["data"] # There is an object named data that contains the signal + data(NX_NUMBER): # There is a block of numbers named data. + doc: "Represents a measure of two- or more-dimensional photoemission counts, where + the varied axes are energy, and one or more angular coordinates. Axes traces + should be linked to the actual encoder position in NXinstrument or calibrated axes in NXprocess." + unit: NX_ANY From 454ef0df280aefc0722a6041b1e26554d99341fa Mon Sep 17 00:00:00 2001 From: rettigl Date: Thu, 4 May 2023 15:40:04 +0200 Subject: [PATCH 0013/1012] Generalized transformations --- .../nyaml/NXmpes_arpes.yaml | 79 ++----------------- 1 file changed, 8 insertions(+), 71 deletions(-) diff --git a/contributed_definitions/nyaml/NXmpes_arpes.yaml b/contributed_definitions/nyaml/NXmpes_arpes.yaml index 5691620c1a..4017e68cd9 100644 --- a/contributed_definitions/nyaml/NXmpes_arpes.yaml +++ b/contributed_definitions/nyaml/NXmpes_arpes.yaml @@ -35,85 +35,22 @@ NXmpes_arpes(NXmpes): raw(NX_NUMBER): # There is a block of numbers named raw. doc: "Raw data before calibration." depends_on(NX_CHAR): - doc: "Reference to the beam coordinate system (.)." - transformations(NXtransformations): - trans_x[AXISNAME]: - exists: recommended - unit: NX_LENGTH - \@transformation_type: translation - \@vector: - \@depends_on: - trans_y[AXISNAME]: - exists: recommended - unit: NX_LENGTH - \@transformation_type: translation - \@vector: - \@depends_on: - trans_z[AXISNAME]: - exists: recommended - unit: NX_LENGTH - \@transformation_type: translation - \@vector: - \@depends_on: - rot_x[AXISNAME]: - unit: NX_LENGTH - \@transformation_type: rotation - \@vector: - \@depends_on: - rot_y[AXISNAME]: - unit: NX_LENGTH - \@transformation_type: rotation - \@vector: - \@depends_on: - rot_z[AXISNAME]: - unit: NX_LENGTH - \@transformation_type: rotation - \@vector: - \@depends_on: + doc: "Reference to the transformation describing the orientation of the analyzer relative to the beam." + (NXtransformations): + doc: "Set of transformations, describing the relative orienation of the analyzer with respect to the beam coordinate system (.)." (NXsample): situation: enumeration: ["vacuum"] # Similar situation here, ca be a single number or a log. depends_on(NX_CHAR): - doc: "Reference to a transformation describing the origin of the sample manipulator coordinate system relative to the beam coordinate system (.)." - transformations(NXtransformations): - trans_x[AXISNAME]: - exists: recommended - unit: NX_LENGTH - \@transformation_type: translation - \@vector: - \@depends_on: - trans_y[AXISNAME]: - exists: recommended - unit: NX_LENGTH - \@transformation_type: translation - \@vector: - \@depends_on: - trans_z[AXISNAME]: - exists: recommended - unit: NX_LENGTH - \@transformation_type: translation - \@vector: - \@depends_on: - rot_x[AXISNAME]: - unit: NX_LENGTH - \@transformation_type: rotation - \@vector: - \@depends_on: - rot_y[AXISNAME]: - unit: NX_LENGTH - \@transformation_type: rotation - \@vector: - \@depends_on: - rot_z[AXISNAME]: - unit: NX_LENGTH - \@transformation_type: rotation - \@vector: - \@depends_on: - + doc: "Reference to a transformation describing the orientation of the sample relative to the beam coordinate system (.)." + (NXtransformations): + doc: "Set of transformations, describing the relative orientation of the sample with respect to the beam coordinate system (.)." (NXdata): \@signal: enumeration: ["data"] # There is an object named data that contains the signal + \@axes: + enumeration: ["[fastAngle, Energy]", "[fastAngle, slowAngle, Energy]"] data(NX_NUMBER): # There is a block of numbers named data. doc: "Represents a measure of two- or more-dimensional photoemission counts, where the varied axes are energy, and one or more angular coordinates. Axes traces From cb08bb27225e13f2fa6cbbbb242e824d561be141 Mon Sep 17 00:00:00 2001 From: RubelMozumder <32923026+RubelMozumder@users.noreply.github.com> Date: Mon, 8 May 2023 13:59:09 +0200 Subject: [PATCH 0014/1012] Changes for removing old errors related ':' in yaml and xml file. (#96) * Changes for removing old errors related ':' in yaml and xml file. * To store nxdl file into yaml as comment and generate or retrieve nxdl from provided yaml. Wokring perfectly. * Bug: last line of yaml file was not counted * Passing all the tests, pylint, mypy and pydocstyle. * Fixing copy-right doc, new_line_char at the end of 'deprecated key', version from of nexus. * pylint.yml checked. --------- Co-authored-by: RubelMozumder --- README.md | 3 ++ comment_collector.py | 31 ++++++++++--- nyaml2nxdl.py | 39 +++++++++++++++-- nyaml2nxdl_backward_tools.py | 21 +++++---- nyaml2nxdl_forward_tools.py | 43 +++++++++++++++++- nyaml2nxdl_helper.py | 85 +++++++++++++++++++++++++++++++++--- 6 files changed, 195 insertions(+), 27 deletions(-) diff --git a/README.md b/README.md index 6a0bbf86a7..ff083e1896 100644 --- a/README.md +++ b/README.md @@ -27,6 +27,9 @@ Options: --input-file TEXT The path to the input data file to read. --append TEXT Parse xml NeXus file and append to specified base class, write the base class name with no extension. + --check-consistency Check consistency by generating another version of the input file. + E.g. for input file: NXexample.nxdl.xml the output file + NXexample_consistency.nxdl.xml. --verbose Addictional std output info is printed to help debugging. --help Show this message and exit. diff --git a/comment_collector.py b/comment_collector.py index a2aa54b782..5f0c5e3bce 100644 --- a/comment_collector.py +++ b/comment_collector.py @@ -89,11 +89,17 @@ def extract_all_comment_blocks(self): for line_num, line in enumerate(lines): if single_comment.is_storing_single_comment(): # If the last comment comes without post nxdl fields, groups and attributes + if '++ SHA HASH ++' in line: + # Handle with stored nxdl.xml file that is not part of yaml + line = '' + single_comment.process_each_line(line + 'post_comment', (line_num + 1)) + self._comment_chain.append(single_comment) + break if line_num < (len(lines) - 1): # Processing file from Line number 1 single_comment.process_each_line(line, (line_num + 1)) else: - # For processing post comment + # For processing last line of file single_comment.process_each_line(line + 'post_comment', (line_num + 1)) self._comment_chain.append(single_comment) else: @@ -122,6 +128,14 @@ def get_coment_by_line_info(self, comment_locs: Tuple[str, Union[int, str]]): self._comment_hash[comment_locs] = cmnt return cmnt + def remove_comment(self, ind): + """Remove a comment from comment list. + """ + if ind < len(self._comment_chain): + del self._comment_chain[ind] + else: + raise ValueError("Oops! Index is out of range.") + def reload_comment(self): """ Update self._comment_tracker after done with last comment. @@ -150,9 +164,15 @@ def __contains__(self, comment_locs: tuple): def __getitem__(self, ind): """Get comment from self.obj._comment_chain by index. """ - if ind >= len(self._comment_chain): - raise IndexError(f'Oops! Coment index {ind} in {__class__} is out of range!') - return self._comment_chain[ind] + if isinstance(ind, int): + if ind >= len(self._comment_chain): + raise IndexError(f'Oops! Comment index {ind} in {__class__} is out of range!') + return self._comment_chain[ind] + + if isinstance(ind, slice): + start_n = ind.start or 0 + end_n = ind.stop or len(self._comment_chain) + return self._comment_chain[start_n:end_n] def __iter__(self): """get comment ieratively @@ -230,6 +250,7 @@ def process_each_line(self, text, line_num): if text and line_num: self.append_comment(text) if self._comnt_end_found and not self._is_elemt_found: + # for multiple comment if exist if self._comnt: self._comnt_list.append(self._comnt) self._comnt = '' @@ -455,7 +476,7 @@ def get_element_location(self): f"{self._elemt}") for key, val in self._elemt.items(): - return key, val + yield key, val def collect_yaml_line_info(self, yaml_dict, line_info_dict): """Collect __line__key and corresponding value from diff --git a/nyaml2nxdl.py b/nyaml2nxdl.py index 3088a25e52..bfd62cfdad 100755 --- a/nyaml2nxdl.py +++ b/nyaml2nxdl.py @@ -26,7 +26,9 @@ import xml.etree.ElementTree as ET import click - +from pynxtools.nyaml2nxdl.nyaml2nxdl_helper import (get_sha256_hash, + extend_yamlfile_with_comment, + separate_hash_yaml_and_nxdl) from pynxtools.nyaml2nxdl.nyaml2nxdl_forward_tools import nyaml2nxdl, pretty_print_xml from pynxtools.nyaml2nxdl.nyaml2nxdl_backward_tools import (Nxdl2yaml, compare_niac_and_my) @@ -35,6 +37,27 @@ DEPTH_SIZE = " " +def generate_nxdl_or_retrieve_nxdl(yaml_file, out_xml_file, verbose): + """ + Generate yaml, nxdl and hash. + if the extracted hash is exactly the same as producd from generated yaml then + retrieve the nxdl part from provided yaml. + Else, generate nxdl from separated yaml with the help of nyaml2nxdl function + """ + pa_path, rel_file = os.path.split(yaml_file) + sep_yaml = pa_path + f'temp_{rel_file}' + hash_found = separate_hash_yaml_and_nxdl(yaml_file, sep_yaml, out_xml_file) + + if hash_found: + gen_hash = get_sha256_hash(sep_yaml) + if hash_found == gen_hash: + os.remove(sep_yaml) + return + + nyaml2nxdl(sep_yaml, out_xml_file, verbose) + os.remove(sep_yaml) + + # pylint: disable=too-many-locals def append_yml(input_file, append, verbose): """Append to an existing NeXus base class new elements provided in YML input file \ @@ -159,7 +182,7 @@ def launch_tool(input_file, verbose, append, check_consistency): if ext == 'yaml': xml_out_file = raw_name + '.nxdl.xml' - nyaml2nxdl(input_file, xml_out_file, verbose) + generate_nxdl_or_retrieve_nxdl(input_file, xml_out_file, verbose) if append: append_yml(raw_name + '.nxdl.xml', append, @@ -176,12 +199,22 @@ def launch_tool(input_file, verbose, append, check_consistency): yaml_out_file = raw_name + '_parsed' + '.yaml' converter = Nxdl2yaml([], []) converter.print_yml(input_file, yaml_out_file, verbose) + # Append nxdl.xml file with yaml output file + yaml_hash = get_sha256_hash(yaml_out_file) + # Lines as divider between yaml and nxdl + top_lines = [('\n# ++++++++++++++++++++++++++++++++++ SHA HASH' + ' ++++++++++++++++++++++++++++++++++\n'), + f'# {yaml_hash}\n'] + + extend_yamlfile_with_comment(yaml_file=yaml_out_file, + file_to_be_appended=input_file, + top_lines_list=top_lines) else: append_yml(input_file, append, verbose) # Taking care of consistency running if check_consistency: xml_out_file = raw_name + '_consistency.' + ext - nyaml2nxdl(yaml_out_file, xml_out_file, verbose) + generate_nxdl_or_retrieve_nxdl(yaml_out_file, xml_out_file, verbose) os.remove(yaml_out_file) else: raise ValueError("Provide correct file with extension '.yaml or '.nxdl.xml") diff --git a/nyaml2nxdl_backward_tools.py b/nyaml2nxdl_backward_tools.py index 0ebc0d5cc1..ffcaa6f07a 100755 --- a/nyaml2nxdl_backward_tools.py +++ b/nyaml2nxdl_backward_tools.py @@ -99,28 +99,27 @@ def parse(filepath): def handle_mapping_char(text, depth=-1, skip_n_line_on_top=False): """Check for ":" char and replace it by "':'". """ - # This escape chars and sepeerator ':' is not allowed in yaml library escape_char = get_yaml_escape_char_dict() for esc_key, val in escape_char.items(): if esc_key in text: text = text.replace(esc_key, val) if not skip_n_line_on_top: if depth > 0: - text = add_new_line_on_top(text, depth) + text = add_new_line_with_pipe_on_top(text, depth) else: raise ValueError("Need depth size to co-ordinate text line in yaml file.") return text -def add_new_line_on_top(text, depth): +def add_new_line_with_pipe_on_top(text, depth): """ - Return char list for what we get error in converter. After adding a - new line at the start of text the eroor is solved. + Return modified text for what we get error in converter, such as ':'. After adding a + new line at the start of text the error is solved. """ char_list_to_add_new_line_on_top_of_text = [":"] for char in char_list_to_add_new_line_on_top_of_text: if char in text: - return '\n' + depth * DEPTH_SIZE + text + return '|' + '\n' + depth * DEPTH_SIZE + text return text @@ -217,10 +216,10 @@ def handle_symbols(self, depth, node): self.handle_not_root_level_doc(depth, tag=child.attrib['name'], text=symbol_doc.text)) - self.stroe_root_level_comments('symbol_doc_comments', sbl_doc_cmnt_list) - self.stroe_root_level_comments('symbol_comments', symbol_cmnt_list) + self.store_root_level_comments('symbol_doc_comments', sbl_doc_cmnt_list) + self.store_root_level_comments('symbol_comments', symbol_cmnt_list) - def stroe_root_level_comments(self, holder, comment): + def store_root_level_comments(self, holder, comment): """Store yaml text or section line and the comments inteded for that lines or section""" self.root_level_comment[holder] = comment @@ -864,7 +863,7 @@ def xmlparse(self, output_yml, xml_tree, depth, verbose): last_comment = self.comvert_to_ymal_comment(depth * DEPTH_SIZE, child.text) remove_cmnt_n = child if tag_tmp == 'doc': - self.stroe_root_level_comments('root_doc', last_comment) + self.store_root_level_comments('root_doc', last_comment) last_comment = '' self.handle_root_level_doc(child) node.remove(child) @@ -872,7 +871,7 @@ def xmlparse(self, output_yml, xml_tree, depth, verbose): node.remove(remove_cmnt_n) remove_cmnt_n = None if tag_tmp == 'symbols': - self.stroe_root_level_comments('symbols', last_comment) + self.store_root_level_comments('symbols', last_comment) last_comment = '' self.handle_symbols(depth, child) node.remove(child) diff --git a/nyaml2nxdl_forward_tools.py b/nyaml2nxdl_forward_tools.py index cee59d1f3d..9a79096a3f 100644 --- a/nyaml2nxdl_forward_tools.py +++ b/nyaml2nxdl_forward_tools.py @@ -45,7 +45,7 @@ "# This library is free software; you can redistribute it and/or\n" "# modify it under the terms of the GNU Lesser General Public\n" "# License as published by the Free Software Foundation; either\n" - "# version 2 of the License, or (at your option) any later version.\n" + "# version 3 of the License, or (at your option) any later version.\n" "#\n" "# This library is distributed in the hope that it will be useful,\n" "# but WITHOUT ANY WARRANTY; without even the implied warranty of\n" @@ -67,6 +67,41 @@ COMMENT_BLOCKS: CommentCollector +def check_for_dom_comment_in_yaml(): + """Check the yaml file has dom comment or dom comment needed to be hard coded. + """ + dignature_keyword_list = ['NeXus', + 'GNU Lesser General Public', + 'Free Software Foundation', + 'Copyright (C)', + 'WITHOUT ANY WARRANTY'] + + # Check for dom comments in first three comments + dom_comment = '' + dom_comment_ind = 1 + for ind, comnt in enumerate(COMMENT_BLOCKS[0:5]): + cmnt_list = comnt.get_comment_text() + if len(cmnt_list) == 1: + text = cmnt_list[0] + else: + continue + dom_comment = text + dom_comment_ind = ind + for keyword in dignature_keyword_list: + if keyword not in text: + dom_comment = '' + break + if dom_comment: + break + + # deactivate the root dom_comment, So that the corresponding comment would not be + # considered as comment for definition xml element. + if dom_comment: + COMMENT_BLOCKS.remove_comment(dom_comment_ind) + + return dom_comment + + def yml_reader(inputfile): """ This function launches the LineLoader class. @@ -78,6 +113,10 @@ def yml_reader(inputfile): loaded_yaml = loader.get_single_data() COMMENT_BLOCKS = CommentCollector(inputfile, loaded_yaml) COMMENT_BLOCKS.extract_all_comment_blocks() + dom_cmnt_frm_yaml = check_for_dom_comment_in_yaml() + global DOM_COMMENT + if dom_cmnt_frm_yaml: + DOM_COMMENT = dom_cmnt_frm_yaml return loaded_yaml @@ -168,7 +207,7 @@ def check_for_mapping_char_other(text): for key, val in escape_reverter.items(): if key in text: text = text.replace(key, val) - return str(text) + return str(text).strip() def xml_handle_doc(obj, value: str, diff --git a/nyaml2nxdl_helper.py b/nyaml2nxdl_helper.py index 0fb51237d7..867eae6612 100644 --- a/nyaml2nxdl_helper.py +++ b/nyaml2nxdl_helper.py @@ -27,6 +27,7 @@ # Yaml library does not except the keys (escapechar "\t" and yaml separator ":") # So the corresponding value is to skip them and # and also carefull about this order +import hashlib from yaml.composer import Composer from yaml.constructor import Constructor @@ -34,7 +35,12 @@ from yaml.resolver import BaseResolver from yaml.loader import Loader -ESCAPE_CHAR_DICT = {"\t": " "} +# NOTE: If any one change one of the bellow dict please change it for both +ESCAPE_CHAR_DICT_IN_YAML = {"\t": " ", + "\':\'": ":"} + +ESCAPE_CHAR_DICT_IN_XML = {" ": "\t", + "\':\'": ":"} class LineLoader(Loader): # pylint: disable=too-many-ancestors @@ -67,15 +73,13 @@ def construct_mapping(self, node, deep=False): def get_yaml_escape_char_dict(): """Get escape char and the way to skip them in yaml.""" - return ESCAPE_CHAR_DICT + return ESCAPE_CHAR_DICT_IN_YAML def get_yaml_escape_char_reverter_dict(): """To revert yaml escape char in xml constructor from yaml.""" - temp_dict = {} - for key, val in ESCAPE_CHAR_DICT.items(): - temp_dict[val] = key - return temp_dict + + return ESCAPE_CHAR_DICT_IN_XML def type_check(nx_type): @@ -143,3 +147,72 @@ def nx_name_type_resolving(tmp): typ = '' nam = tmp return nam, typ + + +def get_sha256_hash(file_name): + """Generate a sha256_hash for a given file. + """ + sha_hash = hashlib.sha256() + + with open(file=file_name, mode='rb',) as file_obj: + # Update hash for each 4k block of bytes + for b_line in iter(lambda: file_obj.read(4096), b""): + sha_hash.update(b_line) + return sha_hash.hexdigest() + + +def extend_yamlfile_with_comment(yaml_file, + file_to_be_appended, + top_lines_list=None): + """Extend yaml file by the file_to_be_appended as comment. + """ + + with open(yaml_file, mode='a+', encoding='utf-8') as f1_obj: + if top_lines_list: + for line in top_lines_list: + f1_obj.write(line) + + with open(file_to_be_appended, mode='r', encoding='utf-8') as f2_obj: + lines = f2_obj.readlines() + for line in lines: + f1_obj.write(f"# {line}") + + +def separate_hash_yaml_and_nxdl(yaml_file, sep_yaml, sep_xml): + """Separate the provided yaml file into yaml, nxdl and hash if yaml was extended with + nxdl at the end of yaml by + '\n# ++++++++++++++++++++++++++++++++++ SHA HASH \ + ++++++++++++++++++++++++++++++++++\n' + # ' + """ + sha_hash = '' + with open(yaml_file, 'r', encoding='utf-8') as inp_file: + lines = inp_file.readlines() + # file to write yaml part + with open(sep_yaml, 'w', encoding='utf-8') as yml_f_ob, \ + open(sep_xml, 'w', encoding='utf-8') as xml_f_ob: + + last_line = '' + write_on_yaml = True + for ind, line in enumerate(lines): + if ind == 0: + last_line = line + # Write in file when ensured that the nest line is not with '++ SHA HASH ++' + elif '++ SHA HASH ++' not in line and write_on_yaml: + yml_f_ob.write(last_line) + last_line = line + elif '++ SHA HASH ++' in line: + write_on_yaml = False + last_line = '' + elif not write_on_yaml and not last_line: + # The first line of xml file has been found. Onward write lines directly + # into xml file. + if not sha_hash: + sha_hash = line.split('# ', 1)[-1].strip() + else: + xml_f_ob.write(line[2:]) + # If the yaml fiile does not contain any hash for nxdl then we may have last line. + if last_line: + yml_f_ob.write(last_line) + + return sha_hash From 53996daca6de688ac5bc4a86273f4164512b9761 Mon Sep 17 00:00:00 2001 From: RubelMozumder <32923026+RubelMozumder@users.noreply.github.com> Date: Mon, 8 May 2023 13:59:09 +0200 Subject: [PATCH 0015/1012] Changes for removing old errors related ':' in yaml and xml file. (#96) * Changes for removing old errors related ':' in yaml and xml file. * To store nxdl file into yaml as comment and generate or retrieve nxdl from provided yaml. Wokring perfectly. * Bug: last line of yaml file was not counted * Passing all the tests, pylint, mypy and pydocstyle. * Fixing copy-right doc, new_line_char at the end of 'deprecated key', version from of nexus. * pylint.yml checked. --------- Co-authored-by: RubelMozumder --- test_nyaml2nxdl.py | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/test_nyaml2nxdl.py b/test_nyaml2nxdl.py index 75072131c1..2e044ed6a2 100755 --- a/test_nyaml2nxdl.py +++ b/test_nyaml2nxdl.py @@ -93,9 +93,14 @@ def test_links(): """ Check the correct parsing of links """ + data_path = os.path.join(os.path.dirname(os.path.abspath(__file__)), + '../data/nyaml2nxdl') ref_xml_link_file = 'tests/data/nyaml2nxdl/Ref_NXtest_links.nxdl.xml' test_yml_link_file = 'tests/data/nyaml2nxdl/NXtest_links.yaml' test_xml_link_file = 'tests/data/nyaml2nxdl/NXtest_links.nxdl.xml' + # ref_xml_link_file = os.path.abspath(data_path + '/Ref_NXtest_links.nxdl.xml') + # test_yml_link_file = os.path.abspath(data_path + '/NXtest_links.yaml') + # test_xml_link_file = os.path.abspath(data_path + '/NXtest_links.nxdl.xml') desired_matches = [''] compare_matches( ref_xml_link_file, @@ -123,10 +128,12 @@ def test_docs(): sys.stdout.write('Test on documentation formatting okay.\n') -def test_nxdl2yaml_doc_format(): +def test_nxdl2yaml_doc_format_and_nxdl_part_as_comment(): """ - In this test an nxdl file with all kind of doc formats are translated + This test for two reason: + 1. In test-1 an nxdl file with all kind of doc formats are translated to yaml to check if they are correct. + 2. In test-2: Check the nxdl that comes at the end of yaml file as comment. """ ref_xml_file = 'tests/data/nyaml2nxdl/Ref_NXentry.nxdl.xml' ref_yml_file = 'tests/data/nyaml2nxdl/Ref_NXentry.yaml' From b83f64d6acb7597c62b3f5a2095b3ae5a0d68fa5 Mon Sep 17 00:00:00 2001 From: Tommaso Date: Tue, 9 May 2023 10:26:45 +0200 Subject: [PATCH 0016/1012] Update NXmpes_arpes.yaml --- .../nyaml/NXmpes_arpes.yaml | 50 +++++++++++++++++-- 1 file changed, 46 insertions(+), 4 deletions(-) diff --git a/contributed_definitions/nyaml/NXmpes_arpes.yaml b/contributed_definitions/nyaml/NXmpes_arpes.yaml index 4017e68cd9..6cb8da8b0b 100644 --- a/contributed_definitions/nyaml/NXmpes_arpes.yaml +++ b/contributed_definitions/nyaml/NXmpes_arpes.yaml @@ -1,5 +1,7 @@ #Pincelli, Rettig, Arora at fhi-berlin.mpg.de, Dobener at hu-berlin.de, 06/2022 -#Draft version of a NeXus application definition for photoemission, +#Draft version of a NeXus application definition for angle resolved photoemission. +#This appdef aims to describe data produced from hemispherical anlysers, +#with at least an angular coordinate and one an energy coordinate. #It is designed to be extended by other application definitions #with higher granularity in the data description. @@ -27,6 +29,26 @@ NXmpes_arpes(NXmpes): "Deflector", ] (NXenergydispersion): + scheme: + enumeration: ["hemispherical"] + pass_energy(NX_NUMBER): + unit: NX_ENERGY + center_energy(NX_NUMBER): + unit: NX_ENERGY + diameter(NX_NUMBER): + unit: NX_LENGTH + energy_scan_mode: + entrance_slit(NXaperture): + shape: + enumeration: [ + "straight slits", + "curved slits", + "open", + "grid", + ] + (NXtransformations): # Do we need to require the existence/use of a particular + #rotation to determine slit orientation? + doc: "Set of transformations, describing the relative orientation of the slits with respect to the beam coordinate system (.)." (NXdetector): (NXdata): # Raw signal without calibrated axes. exists: recommended @@ -37,7 +59,7 @@ NXmpes_arpes(NXmpes): depends_on(NX_CHAR): doc: "Reference to the transformation describing the orientation of the analyzer relative to the beam." (NXtransformations): - doc: "Set of transformations, describing the relative orienation of the analyzer with respect to the beam coordinate system (.)." + doc: "Set of transformations, describing the relative orientation of the analyzer with respect to the beam coordinate system (.)." (NXsample): situation: enumeration: ["vacuum"] @@ -49,8 +71,28 @@ NXmpes_arpes(NXmpes): (NXdata): \@signal: enumeration: ["data"] # There is an object named data that contains the signal - \@axes: - enumeration: ["[fastAngle, Energy]", "[fastAngle, slowAngle, Energy]"] + \@axes: # There are at least two dimensions, an energy & (at least) an angular coordinate + enumeration: ["[energy, angular1]"] + \@energy_indices: # energy is a 1D array + enumeration: [1] + \@angular1_indices: # angular is a 1D array + enumeration: [1] + \@angular1_depends(NX_CHAR): # In ARPES, the angular coordinate can be generated in different ways. + # It can be a detector axis in a 2D detector, or scanned by changing the angle of a manipulator. + # We propose a structure similar to depends_on(NX_CHAR) of NXtransformations to reconstruct the + # metadata path that produced the angular coordinate. This allows to reconstruct the geometry programmatically. + doc: "Points to the path to a field defining the axis on which the angular axis depends. + For example: + @angular1_depends: '/entry/sample/transformations/rot_phi' for a manipulator angular scan + @angular1_depends: '/entry/instrument/detector/sensor_x' for a 2D detector + @angular1_depends: '/entry/instrument/collectioncolumn/deflector' for a deflector scan + @angular1_depends: '/entry/process/calibration/angular_calibration/calibrated_axis' for a preprocessed axis." + \@energy_depends(NX_CHAR): # Similarly, energy can be dispersed according to different strategies + doc: "Points to the path to a field defining the axis on which the energy axis depends. + For example: + @energy_depends: '/entry/instrument/detector/sensor_y' for a 2D detector + @energy_depends: '/entry/instrument/energydispersion/center_kinetic_energy' for a swept scan + @energy_depends: '/entry/process/calibration/energy_calibration/calibrated_axis' for a preprocessed axis." data(NX_NUMBER): # There is a block of numbers named data. doc: "Represents a measure of two- or more-dimensional photoemission counts, where the varied axes are energy, and one or more angular coordinates. Axes traces From e0e55090901891047fc4c9aeeee1ded6c53f22c9 Mon Sep 17 00:00:00 2001 From: RubelMozumder <32923026+RubelMozumder@users.noreply.github.com> Date: Tue, 9 May 2023 16:09:52 +0200 Subject: [PATCH 0017/1012] DEBUG: Deleting intermeadiate generated file. (#109) Co-authored-by: RubelMozumder --- nyaml2nxdl.py | 4 ++-- nyaml2nxdl_helper.py | 3 +++ 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/nyaml2nxdl.py b/nyaml2nxdl.py index bfd62cfdad..25a7cae2e7 100755 --- a/nyaml2nxdl.py +++ b/nyaml2nxdl.py @@ -45,7 +45,7 @@ def generate_nxdl_or_retrieve_nxdl(yaml_file, out_xml_file, verbose): Else, generate nxdl from separated yaml with the help of nyaml2nxdl function """ pa_path, rel_file = os.path.split(yaml_file) - sep_yaml = pa_path + f'temp_{rel_file}' + sep_yaml = os.path.join(pa_path, f'temp_{rel_file}') hash_found = separate_hash_yaml_and_nxdl(yaml_file, sep_yaml, out_xml_file) if hash_found: @@ -132,7 +132,7 @@ def split_name_and_extension(file_name): Split file name into extension and rest of the file name. return file raw nam and extension """ - parts = file_name.rsplit('.', 2) + parts = file_name.rsplit('.', 3) if len(parts) == 2: raw = parts[0] ext = parts[1] diff --git a/nyaml2nxdl_helper.py b/nyaml2nxdl_helper.py index 867eae6612..2f12098a17 100644 --- a/nyaml2nxdl_helper.py +++ b/nyaml2nxdl_helper.py @@ -28,6 +28,7 @@ # So the corresponding value is to skip them and # and also carefull about this order import hashlib +import os from yaml.composer import Composer from yaml.constructor import Constructor @@ -214,5 +215,7 @@ def separate_hash_yaml_and_nxdl(yaml_file, sep_yaml, sep_xml): # If the yaml fiile does not contain any hash for nxdl then we may have last line. if last_line: yml_f_ob.write(last_line) + if not sha_hash: + os.remove(sep_xml) return sha_hash From b44c9c391c547e562a73fddc6787fd75d5fcbf33 Mon Sep 17 00:00:00 2001 From: RubelMozumder <32923026+RubelMozumder@users.noreply.github.com> Date: Tue, 9 May 2023 16:09:52 +0200 Subject: [PATCH 0018/1012] DEBUG: Deleting intermeadiate generated file. (#109) Co-authored-by: RubelMozumder --- test_nyaml2nxdl.py | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/test_nyaml2nxdl.py b/test_nyaml2nxdl.py index 2e044ed6a2..c596ea0d64 100755 --- a/test_nyaml2nxdl.py +++ b/test_nyaml2nxdl.py @@ -154,19 +154,25 @@ def test_fileline_error(): In this test the yaml fileline in the error message is tested. """ test_yml_file = 'tests/data/nyaml2nxdl/NXfilelineError1.yaml' + out_nxdl = 'tests/data/nyaml2nxdl/temp_NXfilelineError1.yaml' result = CliRunner().invoke(nyml2nxdl.launch_tool, ['--input-file', test_yml_file]) assert result.exit_code == 1 assert '13' in str(result.exception) + os.remove(out_nxdl) test_yml_file = 'tests/data/nyaml2nxdl/NXfilelineError2.yaml' + out_nxdl = 'tests/data/nyaml2nxdl/temp_NXfilelineError2.yaml' result = CliRunner().invoke(nyml2nxdl.launch_tool, ['--input-file', test_yml_file]) assert result.exit_code == 1 assert '21' in str(result.exception) + os.remove(out_nxdl) test_yml_file = 'tests/data/nyaml2nxdl/NXfilelineError3.yaml' + out_nxdl = 'tests/data/nyaml2nxdl/temp_NXfilelineError3.yaml' result = CliRunner().invoke(nyml2nxdl.launch_tool, ['--input-file', test_yml_file]) assert result.exit_code == 1 assert '25' in str(result.exception) + os.remove(out_nxdl) sys.stdout.write('Test on xml -> yml fileline error handling okay.\n') From b712dd8115dc28bc29ca3f419972cf2465379421 Mon Sep 17 00:00:00 2001 From: RubelMozumder <32923026+RubelMozumder@users.noreply.github.com> Date: Tue, 13 Jun 2023 16:45:01 +0200 Subject: [PATCH 0019/1012] Optionality check in nyam2nxdl (#126) * temporary changes. * Including some changes for optionality error. * Passing test successfully. Cleaning up some tests. * Removing autogenerated 'optional' attribute from nxdl.xml. * Removing autogenerated 'optional' attribute from nxdl.xml. * Removing autogenerated 'optional' attribute from nxdl.xml. * Removing autogenerated 'optional' attribute from nxdl.xml. * Comments or corrections are resolved. * Corrections from review. --- nyaml2nxdl.py | 5 +- nyaml2nxdl_backward_tools.py | 16 +++--- nyaml2nxdl_forward_tools.py | 106 ++++++++++++++++++++++++++--------- nyaml2nxdl_helper.py | 11 ++-- 4 files changed, 98 insertions(+), 40 deletions(-) diff --git a/nyaml2nxdl.py b/nyaml2nxdl.py index 25a7cae2e7..160b3f830d 100755 --- a/nyaml2nxdl.py +++ b/nyaml2nxdl.py @@ -34,7 +34,10 @@ compare_niac_and_my) -DEPTH_SIZE = " " +DEPTH_SIZE = 4 * " " + +# NOTE: Some handful links for nyaml2nxdl converter: +# https://manual.nexusformat.org/nxdl_desc.html?highlight=optional def generate_nxdl_or_retrieve_nxdl(yaml_file, out_xml_file, verbose): diff --git a/nyaml2nxdl_backward_tools.py b/nyaml2nxdl_backward_tools.py index ffcaa6f07a..72f5a6c426 100755 --- a/nyaml2nxdl_backward_tools.py +++ b/nyaml2nxdl_backward_tools.py @@ -270,7 +270,7 @@ def handle_not_root_level_doc(self, depth, text, tag='doc', file_out=None): Handle docs field along the yaml file. In this function we also tried to keep the track of intended indentation. E.g. the bollow doc block. * Topic name - DEscription of topic + Description of topic """ # Handling empty doc @@ -280,14 +280,16 @@ def handle_not_root_level_doc(self, depth, text, tag='doc', file_out=None): text = handle_mapping_char(text, -1, True) if "\n" in text: # To remove '\n' character as it will be added before text. - text = text.split('\n') - text = cleaning_empty_lines(text) + text = cleaning_empty_lines(text.split('\n')) text_tmp = [] yaml_indent_n = len((depth + 1) * DEPTH_SIZE) - # Find indentaion in the first valid line with alphabet + # Find indentaion in the first text line with alphabet tmp_i = 0 while tmp_i != -1: first_line_indent_n = 0 + # Taking care of empty text whitout any character + if len(text) == 1 and text[0] == '': + break for ch_ in text[tmp_i]: if ch_ == ' ': first_line_indent_n = first_line_indent_n + 1 @@ -538,8 +540,8 @@ def handle_dimension(self, depth, node, file_out): and attributes of dim has been handled inside this function here. """ # pylint: disable=consider-using-f-string - possible_dim_attrs = ['ref', 'optional', 'recommended', - 'required', 'incr', 'refindex'] + possible_dim_attrs = ['ref', 'required', + 'incr', 'refindex'] possible_dimemsion_attrs = ['rank'] # taking care of Dimension tag @@ -851,7 +853,7 @@ def xmlparse(self, output_yml, xml_tree, depth, verbose): sys.stdout.write(f'Attributes: {node.attrib}\n') with open(output_yml, "a", encoding="utf-8") as file_out: tag = remove_namespace_from_tag(node.tag) - if tag == ('definition'): + if tag == 'definition': self.found_definition = True self.handle_definition(node) # Taking care of root level doc and symbols diff --git a/nyaml2nxdl_forward_tools.py b/nyaml2nxdl_forward_tools.py index 9a79096a3f..db4d4c4644 100644 --- a/nyaml2nxdl_forward_tools.py +++ b/nyaml2nxdl_forward_tools.py @@ -31,6 +31,7 @@ from pynxtools.nexus import nexus from pynxtools.nyaml2nxdl.comment_collector import CommentCollector +from pynxtools.dataconverter.helpers import remove_namespace_from_tag from pynxtools.nyaml2nxdl.nyaml2nxdl_helper import (get_yaml_escape_char_reverter_dict, nx_name_type_resolving, cleaning_empty_lines, LineLoader) @@ -65,6 +66,7 @@ DEPTH_SIZE = " " NX_UNIT_TYPES = nexus.get_nx_units() COMMENT_BLOCKS: CommentCollector +CATEGORY = '' # Definition would be either 'base' or 'application' def check_for_dom_comment_in_yaml(): @@ -117,9 +119,60 @@ def yml_reader(inputfile): global DOM_COMMENT if dom_cmnt_frm_yaml: DOM_COMMENT = dom_cmnt_frm_yaml + + if 'category' not in loaded_yaml.keys(): + raise ValueError("All definitions should be either 'base' or 'application' category. " + "No category has been found.") + global CATEGORY + CATEGORY = loaded_yaml['category'] return loaded_yaml +def check_for_default_attribute_and_value(xml_element): + """NeXus Groups, fields and attributes might have xml default attributes and valuesthat must + come. For example: 'optional' which is 'true' by default for base class and false otherwise. + """ + + # base:Default attributes and value for all elements of base class except dimension element + base_attr_to_val = {'optional': 'true'} + + # application: Default attributes and value for all elements of application class except + # dimension element + application_attr_to_val = {'optional': 'false'} + + # Default attributes and value for dimension element + base_dim_attr_to_val = {'required': 'false'} + application_dim_attr_to_val = {'required': 'true'} + + # Eligible tag for default attr and value + elegible_tag = ['group', 'field', 'attribute'] + + def set_default_attribute(xml_elem, default_attr_to_val): + for deflt_attr, deflt_val in default_attr_to_val.items(): + if deflt_attr not in xml_elem.attrib \ + and 'maxOccurs' not in xml_elem.attrib \ + and 'minOccurs' not in xml_elem.attrib \ + and 'recommended' not in xml_elem.attrib: + xml_elem.set(deflt_attr, deflt_val) + + for child in list(xml_element): + # skiping comment 'function' that mainly collect comment from yaml file. + if not isinstance(child.tag, str): + continue + tag = remove_namespace_from_tag(child.tag) + + if tag == 'dim' and CATEGORY == 'base': + set_default_attribute(child, base_dim_attr_to_val) + if tag == 'dim' and CATEGORY == 'application': + set_default_attribute(child, application_dim_attr_to_val) + if tag in elegible_tag and CATEGORY == 'base': + set_default_attribute(child, base_attr_to_val) + if tag in elegible_tag and CATEGORY == 'application': + + set_default_attribute(child, application_attr_to_val) + check_for_default_attribute_and_value(child) + + def yml_reader_nolinetag(inputfile): """ pyyaml based parsing of yaml file in python dict @@ -132,7 +185,7 @@ def yml_reader_nolinetag(inputfile): def check_for_skiped_attributes(component, value, allowed_attr=None, verbose=False): """ Check for any attributes have been skipped or not. - NOTE: We should we should keep in mind about 'doc' + NOTE: We should keep in mind about 'doc' """ block_tag = ['enumeration'] if value: @@ -154,20 +207,6 @@ def check_for_skiped_attributes(component, value, allowed_attr=None, verbose=Fal f"moment. The allowed attrbutes are {allowed_attr}") -def check_optionality_and_write(obj, opl_key, opl_val): - """ - Taking care of optinality. - """ - if opl_key == 'optional': - if opl_val == 'false': - obj.set('required', 'true') - elif opl_key == 'minOccurs': - if opl_val == '0': - pass - else: - obj.set(opl_key, str(opl_val)) - - def format_nxdl_doc(string): """NeXus format for doc string """ @@ -237,20 +276,19 @@ def xml_handle_exists(dct, obj, keyword, value): """ This function creates an 'exists' element instance, and appends it to an existing element """ - line_number = f'__line__{keyword}' assert value is not None, f'Line {dct[line_number]}: exists argument must not be None !' if isinstance(value, list): - if len(value) == 2 and value[0] == 'min': - obj.set('minOccurs', str(value[1])) - elif len(value) == 2 and value[0] == 'max': - obj.set('maxOccurs', str(value[1])) - elif len(value) == 4 and value[0] == 'min' and value[2] == 'max': + if len(value) == 4 and value[0] == 'min' and value[2] == 'max': obj.set('minOccurs', str(value[1])) if str(value[3]) != 'infty': obj.set('maxOccurs', str(value[3])) else: obj.set('maxOccurs', 'unbounded') + elif len(value) == 2 and value[0] == 'min': + obj.set('minOccurs', str(value[1])) + elif len(value) == 2 and value[0] == 'max': + obj.set('maxOccurs', str(value[1])) elif len(value) == 4 and value[0] == 'max' and value[2] == 'min': obj.set('minOccurs', str(value[3])) if str(value[1]) != 'infty': @@ -268,12 +306,14 @@ def xml_handle_exists(dct, obj, keyword, value): f'entries either [min, ] or [max, ], or a list of four ' f'entries [min, , max, ] !') else: + # This clause take optional in all concept except dimension where 'required' key is allowed + # not the 'optional' key. if value == 'optional': obj.set('optional', 'true') elif value == 'recommended': obj.set('recommended', 'true') elif value == 'required': - obj.set('required', 'true') + obj.set('optional', 'false') else: obj.set('minOccurs', '0') @@ -300,7 +340,6 @@ def xml_handle_group(dct, obj, keyword, value, verbose=False): raise ValueError("A group must have both value and name. Check for group.") grp = ET.SubElement(obj, 'group') - # type come first if l_bracket == 0 and r_bracket > 0: grp.set('type', keyword_type) if keyword_name: @@ -364,7 +403,7 @@ def xml_handle_dimensions(dct, obj, keyword, value: dict): incr:[...]' """ - possible_dimension_attrs = ['rank'] + possible_dimension_attrs = ['rank'] # nxdl attributes line_number = f'__line__{keyword}' line_loc = dct[line_number] assert 'dim' in value.keys(), (f"Line {line_loc}: No dim as child of dimension has " @@ -373,7 +412,7 @@ def xml_handle_dimensions(dct, obj, keyword, value: dict): dims = ET.SubElement(obj, 'dimensions') # Consider all the childs under dimension is dim element and # its attributes -# val_attrs = list(value.keys()) + rm_key_list = [] rank = '' for key, val in value.items(): @@ -418,7 +457,11 @@ def xml_handle_dim_from_dimension_dict(dct, dims_obj, keyword, value, rank, verb function. please also read note in xml_handle_dimensions. """ - possible_dim_attrs = ['ref', 'optional', 'recommended', 'required', 'incr', 'refindex'] + possible_dim_attrs = ['ref', 'incr', 'refindex', 'required'] + + # Some attributes might have equivalent name e.g. 'required' is correct one and + # 'optional' could be another name. Then change attribute to the correct one. + wrong_to_correct_attr = [('optional', 'required')] header_line_number = f"__line__{keyword}" dim_list = [] rm_key_list = [] @@ -431,7 +474,6 @@ def xml_handle_dim_from_dimension_dict(dct, dims_obj, keyword, value, rank, verb for attr, vvalue in value.items(): if '__line__' in attr: continue - line_number = f"__line__{attr}" line_loc = value[line_number] # dim comes in precedence @@ -466,6 +508,11 @@ def xml_handle_dim_from_dimension_dict(dct, dims_obj, keyword, value, rank, verb continue cmnt_number = f'__line__{kkkey}' cmnt_loc = vvalue[cmnt_number] + # Check whether any optional attributes added + for tuple_wng_crt in wrong_to_correct_attr: + if kkkey == tuple_wng_crt[0]: + raise ValueError(f"{cmnt_loc}: Attribute '{kkkey}' is prohibited, use " + f"'{tuple_wng_crt[1]}") if kkkey == 'doc' and dim_list: # doc comes as list of doc for i, dim in enumerate(dim_list): @@ -782,7 +829,6 @@ def xml_handle_fields(obj, keyword, value, line_annot, line_loc, verbose=False): then the not empty keyword_name is a field! This simple function will define a new node of xml tree """ - # List of possible attributes of xml elements allowed_attr = ['name', 'type', 'nameType', 'unit', 'minOccurs', 'long_name', 'axis', 'signal', 'deprecated', 'axes', 'exists', @@ -1106,6 +1152,10 @@ def nyaml2nxdl(input_file: str, out_file, verbose: bool): (lin_annot, line_loc) = post_comment.get_line_info() xml_handle_comment(xml_root, lin_annot, line_loc) + # Note: Just to keep the functionality if we need this functionality later. + default_attr = False + if default_attr: + check_for_default_attribute_and_value(xml_root) pretty_print_xml(xml_root, out_file, def_cmnt_text) if verbose: sys.stdout.write('Parsed YAML to NXDL successfully\n') diff --git a/nyaml2nxdl_helper.py b/nyaml2nxdl_helper.py index 2f12098a17..9583b375d2 100644 --- a/nyaml2nxdl_helper.py +++ b/nyaml2nxdl_helper.py @@ -28,7 +28,6 @@ # So the corresponding value is to skip them and # and also carefull about this order import hashlib -import os from yaml.composer import Composer from yaml.constructor import Constructor @@ -111,7 +110,6 @@ def cleaning_empty_lines(line_list): """ Cleaning up empty lines on top and bottom. """ - if not isinstance(line_list, list): line_list = line_list.split('\n') if '\n' in line_list else [''] @@ -120,11 +118,18 @@ def cleaning_empty_lines(line_list): if line_list[0].strip(): break line_list = line_list[1:] + if len(line_list) == 0: + line_list.append('') + return line_list + # Clining bottom empty lines while True: if line_list[-1].strip(): break line_list = line_list[0:-1] + if len(line_list) == 0: + line_list.append('') + return line_list return line_list @@ -215,7 +220,5 @@ def separate_hash_yaml_and_nxdl(yaml_file, sep_yaml, sep_xml): # If the yaml fiile does not contain any hash for nxdl then we may have last line. if last_line: yml_f_ob.write(last_line) - if not sha_hash: - os.remove(sep_xml) return sha_hash From 9da44eee5a440d24bd72240e967bae0faf9a83d8 Mon Sep 17 00:00:00 2001 From: RubelMozumder <32923026+RubelMozumder@users.noreply.github.com> Date: Tue, 13 Jun 2023 16:45:01 +0200 Subject: [PATCH 0020/1012] Optionality check in nyam2nxdl (#126) * temporary changes. * Including some changes for optionality error. * Passing test successfully. Cleaning up some tests. * Removing autogenerated 'optional' attribute from nxdl.xml. * Removing autogenerated 'optional' attribute from nxdl.xml. * Removing autogenerated 'optional' attribute from nxdl.xml. * Removing autogenerated 'optional' attribute from nxdl.xml. * Comments or corrections are resolved. * Corrections from review. --- test_nyaml2nxdl.py | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/test_nyaml2nxdl.py b/test_nyaml2nxdl.py index c596ea0d64..d0c9f875a5 100755 --- a/test_nyaml2nxdl.py +++ b/test_nyaml2nxdl.py @@ -154,25 +154,31 @@ def test_fileline_error(): In this test the yaml fileline in the error message is tested. """ test_yml_file = 'tests/data/nyaml2nxdl/NXfilelineError1.yaml' - out_nxdl = 'tests/data/nyaml2nxdl/temp_NXfilelineError1.yaml' + out_nxdl = 'tests/data/nyaml2nxdl/NXfilelineError1.nxdl.xml' + out_yaml = 'tests/data/nyaml2nxdl/temp_NXfilelineError1.yaml' result = CliRunner().invoke(nyml2nxdl.launch_tool, ['--input-file', test_yml_file]) assert result.exit_code == 1 assert '13' in str(result.exception) os.remove(out_nxdl) + os.remove(out_yaml) test_yml_file = 'tests/data/nyaml2nxdl/NXfilelineError2.yaml' - out_nxdl = 'tests/data/nyaml2nxdl/temp_NXfilelineError2.yaml' + out_nxdl = 'tests/data/nyaml2nxdl/NXfilelineError2.nxdl.xml' + out_yaml = 'tests/data/nyaml2nxdl/temp_NXfilelineError2.yaml' result = CliRunner().invoke(nyml2nxdl.launch_tool, ['--input-file', test_yml_file]) assert result.exit_code == 1 assert '21' in str(result.exception) os.remove(out_nxdl) + os.remove(out_yaml) test_yml_file = 'tests/data/nyaml2nxdl/NXfilelineError3.yaml' - out_nxdl = 'tests/data/nyaml2nxdl/temp_NXfilelineError3.yaml' + out_nxdl = 'tests/data/nyaml2nxdl/NXfilelineError3.nxdl.xml' + out_yaml = 'tests/data/nyaml2nxdl/temp_NXfilelineError3.yaml' result = CliRunner().invoke(nyml2nxdl.launch_tool, ['--input-file', test_yml_file]) assert result.exit_code == 1 assert '25' in str(result.exception) os.remove(out_nxdl) + os.remove(out_yaml) sys.stdout.write('Test on xml -> yml fileline error handling okay.\n') @@ -196,13 +202,14 @@ def test_symbols(): def test_attributes(): """ - Check the correct handling of empty attributes - or attributes fields, e.g. doc + Check expected attributes in NeXus fields, groups, and attributes. + Check proper doc elements. """ ref_xml_attribute_file = 'tests/data/nyaml2nxdl/Ref_NXattributes.nxdl.xml' test_yml_attribute_file = 'tests/data/nyaml2nxdl/NXattributes.yaml' test_xml_attribute_file = 'tests/data/nyaml2nxdl/NXattributes.nxdl.xml' - desired_matches = ['', '', ''] + desired_matches = ['', '', '', + '', ''] compare_matches( ref_xml_attribute_file, test_yml_attribute_file, From 0233d91a87fd8bb20bf680f48674a6bbacf454fd Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Thu, 15 Jun 2023 10:48:34 +0200 Subject: [PATCH 0021/1012] adding links to first references of the vocabulary items --- Makefile | 1 + dev_tools/docs/nxdl.py | 47 ++++++++++++++++++++++++++++++++++++++++-- requirements.txt | 3 +++ 3 files changed, 49 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index ae556d7339..44c076c341 100644 --- a/Makefile +++ b/Makefile @@ -6,6 +6,7 @@ PYTHON = python3 SPHINX = sphinx-build BUILD_DIR = "build" +export NEXUS_DEF_PATH = $(shell pwd) .PHONY: help install style autoformat test clean prepare html pdf impatient-guide all local diff --git a/dev_tools/docs/nxdl.py b/dev_tools/docs/nxdl.py index 8da3ebbc05..0e8d646f22 100644 --- a/dev_tools/docs/nxdl.py +++ b/dev_tools/docs/nxdl.py @@ -7,6 +7,7 @@ from typing import Optional import lxml +from pynxtools.nexus import nexus as pynxtools_nxlib from ..globals.directories import get_nxdl_root from ..globals.errors import NXDLParseError @@ -506,7 +507,7 @@ def _print_attribute(self, ns, kind, node, optional, indent, parent_path): ) self._print(f"{indent}.. index:: {index_name} ({kind} attribute)\n") self._print( - f"{indent}**@{name}**: {optional}{self._format_type(node)}{self._format_units(node)}\n" + f"{indent}**@{name}**: {optional}{self._format_type(node)}{self._format_units(node)} {self.get_first_parent_ref(f'{parent_path}/{name}', 'attribute')}\n" ) self._print_doc(indent + self._INDENTATION_UNIT, ns, node) node_list = node.xpath("nx:enumeration", namespaces=ns) @@ -549,6 +550,7 @@ def _print_full_tree(self, ns, parent, name, indent, parent_path): f"{self._format_type(node)}" f"{dims}" f"{self._format_units(node)}" + f" {self.get_first_parent_ref(f'{parent_path}/{name}', 'field')}" "\n" ) @@ -585,7 +587,9 @@ def _print_full_tree(self, ns, parent, name, indent, parent_path): # target = hTarget.replace(".. _", "").replace(":\n", "") # TODO: https://github.com/nexusformat/definitions/issues/1057 self._print(f"{indent}{hTarget}") - self._print(f"{indent}**{name}**: {optional_text}{typ}\n") + self._print( + f"{indent}**{name}**: {optional_text}{typ} {self.get_first_parent_ref(f'{parent_path}/{name}', 'group')}\n" + ) self._print_if_deprecated(ns, node, indent + self._INDENTATION_UNIT) self._print_doc(indent + self._INDENTATION_UNIT, ns, node) @@ -624,3 +628,42 @@ def _print_full_tree(self, ns, parent, name, indent, parent_path): def _print(self, *args, end="\n"): # TODO: change instances of \t to proper indentation self._rst_lines.append(" ".join(args) + end) + + def get_first_parent_ref(self, path, tag): + nx_name = path[1 : path.find("/", 1)] + path = path[path.find("/", 1) :] + + try: + parents = pynxtools_nxlib.get_inherited_nodes(path, nx_name)[2] + except: + return "" + if len(parents) > 1: + parent = parents[1] + parent_path = parent_display_name = parent.attrib["nxdlpath"] + parent_path_segments = parent_path[1:].split("/") + parent_def_name = parent.attrib["nxdlbase"][ + parent.attrib["nxdlbase"] + .rfind("/") : parent.attrib["nxdlbase"] + .rfind(".nxdl") + ] + + # Case where the first parent is a base_class + if parent_path_segments[0] == "": + return f":ref:`<{parent_def_name[1:]}> <{parent_def_name[1:]}>`" + + parent_display_name = ( + f"{parent_def_name[1:]}/.../{parent_path_segments[-1]}" + if len(parent_path_segments) > 1 + else f"{parent_def_name[1:]}/{parent_path_segments[-1]}" + ) + if tag == "attribute": + pos_of_right_slash = parent_path.rfind("/") + parent_path = ( + parent_path[:pos_of_right_slash] + + "@" + + parent_path[pos_of_right_slash + 1 :] + ) + return ( + f":ref:`<{parent_display_name}> <{parent_def_name}{parent_path}-{tag}>`" + ) + return "" diff --git a/requirements.txt b/requirements.txt index 6d024bda3a..8b22819ff4 100644 --- a/requirements.txt +++ b/requirements.txt @@ -5,6 +5,7 @@ pyyaml # Documentation building sphinx>=5 sphinx-tabs +sphinx-comments # Testing pytest @@ -13,3 +14,5 @@ pytest black>=22.3 flake8>=4 isort>=5.10 + +pynxtools>=0.0.3 \ No newline at end of file From a671d15a7da7dba7842de3aa853ea34fd22129d9 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Thu, 15 Jun 2023 13:34:56 +0200 Subject: [PATCH 0022/1012] do not display first reference redundantly if it is the only reference --- dev_tools/docs/nxdl.py | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/dev_tools/docs/nxdl.py b/dev_tools/docs/nxdl.py index 0e8d646f22..fdff6a8258 100644 --- a/dev_tools/docs/nxdl.py +++ b/dev_tools/docs/nxdl.py @@ -635,7 +635,7 @@ def get_first_parent_ref(self, path, tag): try: parents = pynxtools_nxlib.get_inherited_nodes(path, nx_name)[2] - except: + except FileNotFoundError: return "" if len(parents) > 1: parent = parents[1] @@ -649,7 +649,11 @@ def get_first_parent_ref(self, path, tag): # Case where the first parent is a base_class if parent_path_segments[0] == "": - return f":ref:`<{parent_def_name[1:]}> <{parent_def_name[1:]}>`" + return "" + + #special treatment for NXnote@type + if tag == "attribute" and parent_def_name == "/NXnote" and parent_path == "/type": + return "" parent_display_name = ( f"{parent_def_name[1:]}/.../{parent_path_segments[-1]}" From 124b41eedeb44d530629bc95cfea46f89dd874f5 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Thu, 15 Jun 2023 13:41:29 +0200 Subject: [PATCH 0023/1012] reformatting --- dev_tools/docs/nxdl.py | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/dev_tools/docs/nxdl.py b/dev_tools/docs/nxdl.py index fdff6a8258..fedfe02785 100644 --- a/dev_tools/docs/nxdl.py +++ b/dev_tools/docs/nxdl.py @@ -650,9 +650,13 @@ def get_first_parent_ref(self, path, tag): # Case where the first parent is a base_class if parent_path_segments[0] == "": return "" - - #special treatment for NXnote@type - if tag == "attribute" and parent_def_name == "/NXnote" and parent_path == "/type": + + # special treatment for NXnote@type + if ( + tag == "attribute" + and parent_def_name == "/NXnote" + and parent_path == "/type" + ): return "" parent_display_name = ( From 8351366eacbb24aa33665ab23604371112aaaa52 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Thu, 15 Jun 2023 22:07:01 +0200 Subject: [PATCH 0024/1012] changing to shorter link with tooltip --- dev_tools/docs/nxdl.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/dev_tools/docs/nxdl.py b/dev_tools/docs/nxdl.py index fedfe02785..6c7b092337 100644 --- a/dev_tools/docs/nxdl.py +++ b/dev_tools/docs/nxdl.py @@ -672,6 +672,7 @@ def get_first_parent_ref(self, path, tag): + parent_path[pos_of_right_slash + 1 :] ) return ( - f":ref:`<{parent_display_name}> <{parent_def_name}{parent_path}-{tag}>`" + f"<:abbr:`parent (parent definition: {parent_def_name[1:]}" + + f"/{parent_path_segments[-1]})`:ref:`🔗 <{parent_def_name}{parent_path}-{tag}>`>" ) return "" From 1af3a42452c2506f7e303f8a4b73022d7dcccae7 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Thu, 15 Jun 2023 22:12:47 +0200 Subject: [PATCH 0025/1012] linting --- dev_tools/docs/nxdl.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/dev_tools/docs/nxdl.py b/dev_tools/docs/nxdl.py index 6c7b092337..d76abfbd22 100644 --- a/dev_tools/docs/nxdl.py +++ b/dev_tools/docs/nxdl.py @@ -672,7 +672,7 @@ def get_first_parent_ref(self, path, tag): + parent_path[pos_of_right_slash + 1 :] ) return ( - f"<:abbr:`parent (parent definition: {parent_def_name[1:]}" + - f"/{parent_path_segments[-1]})`:ref:`🔗 <{parent_def_name}{parent_path}-{tag}>`>" + f"<:abbr:`parent (parent definition: {parent_def_name[1:]}" + + f"/{parent_path_segments[-1]})`:ref:`🔗 <{parent_def_name}{parent_path}-{tag}>`>" ) return "" From 8c0881d3311c75a17828d2ba86eed2cea6b399aa Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Thu, 15 Jun 2023 22:33:18 +0200 Subject: [PATCH 0026/1012] linting --- dev_tools/docs/nxdl.py | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/dev_tools/docs/nxdl.py b/dev_tools/docs/nxdl.py index d76abfbd22..086e3aa761 100644 --- a/dev_tools/docs/nxdl.py +++ b/dev_tools/docs/nxdl.py @@ -659,11 +659,6 @@ def get_first_parent_ref(self, path, tag): ): return "" - parent_display_name = ( - f"{parent_def_name[1:]}/.../{parent_path_segments[-1]}" - if len(parent_path_segments) > 1 - else f"{parent_def_name[1:]}/{parent_path_segments[-1]}" - ) if tag == "attribute": pos_of_right_slash = parent_path.rfind("/") parent_path = ( @@ -671,8 +666,9 @@ def get_first_parent_ref(self, path, tag): + "@" + parent_path[pos_of_right_slash + 1 :] ) + parent_display_name = f"{parent_def_name[1:]}{parent_path}" return ( - f"<:abbr:`parent (parent definition: {parent_def_name[1:]}" - + f"/{parent_path_segments[-1]})`:ref:`🔗 <{parent_def_name}{parent_path}-{tag}>`>" + f"<:abbr:`parent (parent definition: {parent_display_name})" + + f"`:ref:`🔗 `>" ) return "" From d5faa6b0c1bbd289c1b6ee654e613535ca909187 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Thu, 15 Jun 2023 22:54:42 +0200 Subject: [PATCH 0027/1012] supporting unicode char for latex --- manual/source/conf.py | 1 + 1 file changed, 1 insertion(+) diff --git a/manual/source/conf.py b/manual/source/conf.py index 51b35e4bb3..19a52d7078 100644 --- a/manual/source/conf.py +++ b/manual/source/conf.py @@ -95,4 +95,5 @@ latex_elements = { 'maxlistdepth':7, # some application definitions are deeply nested 'preamble': '\\usepackage{amsbsy}\n' + \DeclareUnicodeCharacter{1F517}{X} } From 1138ebfe0088cf56e8505244e5419646db9ee76e Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Thu, 15 Jun 2023 23:56:12 +0200 Subject: [PATCH 0028/1012] short tooltip and link --- build/manual/source/conf.py | 100 ++++++++++++++++++++++++++++++++++++ dev_tools/docs/nxdl.py | 4 +- 2 files changed, 102 insertions(+), 2 deletions(-) create mode 100644 build/manual/source/conf.py diff --git a/build/manual/source/conf.py b/build/manual/source/conf.py new file mode 100644 index 0000000000..f6d05e2971 --- /dev/null +++ b/build/manual/source/conf.py @@ -0,0 +1,100 @@ +# Configuration file for the Sphinx documentation builder. +# +# This file only contains a selection of the most common options. For a full +# list see the documentation: +# https://www.sphinx-doc.org/en/master/usage/configuration.html + +# -- Path setup -------------------------------------------------------------- + +import sys, os, datetime + +# If extensions (or modules to document with autodoc) are in another directory, +# add these directories to sys.path here. If the directory is relative to the +# documentation root, use os.path.abspath to make it absolute, like shown here. +# +# import os +# import sys +# sys.path.insert(0, os.path.abspath('.')) + + +# -- Project information ----------------------------------------------------- + +project = 'nexus' +author = 'NIAC, https://www.nexusformat.org' +copyright = u'1996-{}, {}'.format(datetime.datetime.now().year, author) +description = u'NeXus: A Common Data Format for Neutron, X-ray, and Muon Science' + +# The full version, including alpha/beta/rc tags +version = u'unknown NXDL version' +release = u'unknown NXDL release' +nxdl_version = open('../../NXDL_VERSION').read().strip() +if nxdl_version is not None: + version = nxdl_version.split('.')[0] + release = nxdl_version + + +# -- General configuration --------------------------------------------------- + +# https://github.com/nexusformat/definitions/issues/659#issuecomment-577438319 +needs_sphinx = '2.3' + +# Add any Sphinx extension module names here, as strings. They can be +# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom +# ones. +extensions = [ + 'sphinx.ext.mathjax', + 'sphinx.ext.ifconfig', + 'sphinx.ext.viewcode', + 'sphinx.ext.githubpages', + 'sphinx.ext.todo', + 'sphinx_tabs.tabs' +] + +# Show `.. todo` directives in the output +# todo_include_todos = True + +# Add any paths that contain templates here, relative to this directory. +templates_path = ['_templates'] + +# List of patterns, relative to source directory, that match files and +# directories to ignore when looking for source files. +# This pattern also affects html_static_path and html_extra_path. +exclude_patterns = [] + + +# -- Options for HTML output ------------------------------------------------- + +# The theme to use for HTML and HTML Help pages. See the documentation for +# a list of builtin themes. +# +# html_theme = 'alabaster' +html_theme = 'sphinxdoc' + +# Add any paths that contain custom static files (such as style sheets) here, +# relative to this directory. They are copied after the builtin static files, +# so a file named "default.css" will overwrite the builtin "default.css". +html_static_path = ['_static'] + +# Add extra files +html_extra_path = ['CNAME'] + +html_sidebars = { + '**': [ + 'localtoc.html', + 'relations.html', + 'sourcelink.html', + 'searchbox.html', + 'google_search.html' + ], +} + +# Output file base name for HTML help builder. +htmlhelp_basename = 'NeXusManualdoc' + +# -- Options for Latex output ------------------------------------------------- +latex_elements = { + 'maxlistdepth':25, # some application definitions are deeply nested + 'preamble': r''' + \usepackage{amsbsy} + \usepackage[utf8]{inputenc}''' +} diff --git a/dev_tools/docs/nxdl.py b/dev_tools/docs/nxdl.py index 086e3aa761..d0b4cb9c14 100644 --- a/dev_tools/docs/nxdl.py +++ b/dev_tools/docs/nxdl.py @@ -668,7 +668,7 @@ def get_first_parent_ref(self, path, tag): ) parent_display_name = f"{parent_def_name[1:]}{parent_path}" return ( - f"<:abbr:`parent (parent definition: {parent_display_name})" - + f"`:ref:`🔗 `>" + f":abbr:`... (override: {parent_display_name})" + + f"`:ref:`🔗 `" ) return "" From cb92872532a11368c962e0bcfcf9c2ad6b8478b8 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Fri, 16 Jun 2023 00:21:04 +0200 Subject: [PATCH 0029/1012] adjusted conf.py --- build/manual/source/conf.py | 100 ------------------------------------ manual/source/conf.py | 5 +- 2 files changed, 3 insertions(+), 102 deletions(-) delete mode 100644 build/manual/source/conf.py diff --git a/build/manual/source/conf.py b/build/manual/source/conf.py deleted file mode 100644 index f6d05e2971..0000000000 --- a/build/manual/source/conf.py +++ /dev/null @@ -1,100 +0,0 @@ -# Configuration file for the Sphinx documentation builder. -# -# This file only contains a selection of the most common options. For a full -# list see the documentation: -# https://www.sphinx-doc.org/en/master/usage/configuration.html - -# -- Path setup -------------------------------------------------------------- - -import sys, os, datetime - -# If extensions (or modules to document with autodoc) are in another directory, -# add these directories to sys.path here. If the directory is relative to the -# documentation root, use os.path.abspath to make it absolute, like shown here. -# -# import os -# import sys -# sys.path.insert(0, os.path.abspath('.')) - - -# -- Project information ----------------------------------------------------- - -project = 'nexus' -author = 'NIAC, https://www.nexusformat.org' -copyright = u'1996-{}, {}'.format(datetime.datetime.now().year, author) -description = u'NeXus: A Common Data Format for Neutron, X-ray, and Muon Science' - -# The full version, including alpha/beta/rc tags -version = u'unknown NXDL version' -release = u'unknown NXDL release' -nxdl_version = open('../../NXDL_VERSION').read().strip() -if nxdl_version is not None: - version = nxdl_version.split('.')[0] - release = nxdl_version - - -# -- General configuration --------------------------------------------------- - -# https://github.com/nexusformat/definitions/issues/659#issuecomment-577438319 -needs_sphinx = '2.3' - -# Add any Sphinx extension module names here, as strings. They can be -# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom -# ones. -extensions = [ - 'sphinx.ext.mathjax', - 'sphinx.ext.ifconfig', - 'sphinx.ext.viewcode', - 'sphinx.ext.githubpages', - 'sphinx.ext.todo', - 'sphinx_tabs.tabs' -] - -# Show `.. todo` directives in the output -# todo_include_todos = True - -# Add any paths that contain templates here, relative to this directory. -templates_path = ['_templates'] - -# List of patterns, relative to source directory, that match files and -# directories to ignore when looking for source files. -# This pattern also affects html_static_path and html_extra_path. -exclude_patterns = [] - - -# -- Options for HTML output ------------------------------------------------- - -# The theme to use for HTML and HTML Help pages. See the documentation for -# a list of builtin themes. -# -# html_theme = 'alabaster' -html_theme = 'sphinxdoc' - -# Add any paths that contain custom static files (such as style sheets) here, -# relative to this directory. They are copied after the builtin static files, -# so a file named "default.css" will overwrite the builtin "default.css". -html_static_path = ['_static'] - -# Add extra files -html_extra_path = ['CNAME'] - -html_sidebars = { - '**': [ - 'localtoc.html', - 'relations.html', - 'sourcelink.html', - 'searchbox.html', - 'google_search.html' - ], -} - -# Output file base name for HTML help builder. -htmlhelp_basename = 'NeXusManualdoc' - -# -- Options for Latex output ------------------------------------------------- -latex_elements = { - 'maxlistdepth':25, # some application definitions are deeply nested - 'preamble': r''' - \usepackage{amsbsy} - \usepackage[utf8]{inputenc}''' -} diff --git a/manual/source/conf.py b/manual/source/conf.py index 19a52d7078..346e664d95 100644 --- a/manual/source/conf.py +++ b/manual/source/conf.py @@ -94,6 +94,7 @@ # -- Options for Latex output ------------------------------------------------- latex_elements = { 'maxlistdepth':7, # some application definitions are deeply nested - 'preamble': '\\usepackage{amsbsy}\n' - \DeclareUnicodeCharacter{1F517}{X} + 'preamble': r''' + \usepackage{amsbsy} + \DeclareUnicodeCharacter{1F517}{X}''' } From c117842cfc088b9e3babb8f368c9d113e5890642 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Fri, 16 Jun 2023 00:42:05 +0200 Subject: [PATCH 0030/1012] removing pynxtools as dependecy --- dev_tools/docs/nxdl.py | 2 +- dev_tools/utils/nexus.py | 1394 ++++++++++++++++++++++++++++++++++++++ requirements.txt | 3 - 3 files changed, 1395 insertions(+), 4 deletions(-) create mode 100644 dev_tools/utils/nexus.py diff --git a/dev_tools/docs/nxdl.py b/dev_tools/docs/nxdl.py index d0b4cb9c14..1316e230ac 100644 --- a/dev_tools/docs/nxdl.py +++ b/dev_tools/docs/nxdl.py @@ -7,7 +7,7 @@ from typing import Optional import lxml -from pynxtools.nexus import nexus as pynxtools_nxlib +from ..utils import nexus as pynxtools_nxlib from ..globals.directories import get_nxdl_root from ..globals.errors import NXDLParseError diff --git a/dev_tools/utils/nexus.py b/dev_tools/utils/nexus.py new file mode 100644 index 0000000000..ac1d8b36cf --- /dev/null +++ b/dev_tools/utils/nexus.py @@ -0,0 +1,1394 @@ +# pylint: disable=too-many-lines +"""Read files from different format and print it in a standard NeXus format +""" + +import os +import xml.etree.ElementTree as ET +from functools import lru_cache +from glob import glob +import sys +import logging +import textwrap +import h5py +import click + + +class NxdlAttributeError(Exception): + """An exception for throwing an error when an Nxdl attribute is not found.""" + + +def get_app_defs_names(): + """Returns all the AppDef names without their extension: .nxdl.xml""" + app_def_path_glob = f"{get_nexus_definitions_path()}{os.sep}applications{os.sep}*.nxdl*" + contrib_def_path_glob = (f"{get_nexus_definitions_path()}{os.sep}" + f"contributed_definitions{os.sep}*.nxdl*") + files = sorted(glob(app_def_path_glob)) + sorted(glob(contrib_def_path_glob)) + return [os.path.basename(file).split(".")[0] for file in files] + ["NXroot"] + + +@lru_cache(maxsize=None) +def get_xml_root(file_path): + """Reducing I/O time by caching technique""" + + return ET.parse(file_path).getroot() + + +def get_nexus_definitions_path(): + """Check NEXUS_DEF_PATH variable. +If it is empty, this function is filling it""" + try: # either given by sys env + return os.environ['NEXUS_DEF_PATH'] + except KeyError: # or it should be available locally under the dir 'definitions' + local_dir = os.path.abspath(os.path.dirname(__file__)) + return os.path.join(local_dir, f"..{os.sep}definitions") + + +def get_hdf_root(hdf_node): + """Get the root HDF5 node""" + node = hdf_node + while node.name != '/': + node = node.parent + return node + + +def get_hdf_parent(hdf_info): + """Get the parent of an hdf_node in an hdf_info""" + if 'hdf_path' not in hdf_info: + return hdf_info['hdf_node'].parent + node = get_hdf_root(hdf_info['hdf_node']) if 'hdf_root' not in hdf_info \ + else hdf_info['hdf_root'] + for child_name in hdf_info['hdf_path'].split('/'): + node = node[child_name] + return node + + +def get_parent_path(hdf_name): + """Get parent path""" + return '/'.join(hdf_name.split('/')[:-1]) + + +def get_hdf_info_parent(hdf_info): + """Get the hdf_info for the parent of an hdf_node in an hdf_info""" + if 'hdf_path' not in hdf_info: + return {'hdf_node': hdf_info['hdf_node'].parent} + node = get_hdf_root(hdf_info['hdf_node']) if 'hdf_root' not in hdf_info \ + else hdf_info['hdf_root'] + for child_name in hdf_info['hdf_path'].split('/')[1:-1]: + node = node[child_name] + return {'hdf_node': node, 'hdf_path': get_parent_path(hdf_info['hdf_path'])} + + +def get_nx_class_path(hdf_info): + """Get the full path of an HDF5 node using nexus classes +in case of a field, end with the field name""" + hdf_node = hdf_info['hdf_node'] + if hdf_node.name == '/': + return '' + if isinstance(hdf_node, h5py.Group): + return get_nx_class_path(get_hdf_info_parent(hdf_info)) + '/' + \ + (hdf_node.attrs['NX_class'] if 'NX_class' in hdf_node.attrs.keys() else + hdf_node.name.split('/')[-1]) + if isinstance(hdf_node, h5py.Dataset): + return get_nx_class_path( + get_hdf_info_parent(hdf_info)) + '/' + hdf_node.name.split('/')[-1] + return '' + + +def get_nxdl_entry(hdf_info): + """Get the nxdl application definition for an HDF5 node""" + entry = hdf_info + while isinstance(entry['hdf_node'], h5py.Dataset) or \ + 'NX_class' not in entry['hdf_node'].attrs.keys() or \ + entry['hdf_node'].attrs['NX_class'] != 'NXentry': + entry = get_hdf_info_parent(entry) + if entry['hdf_node'].name == '/': + return 'NO NXentry found' + try: + nxdef = entry['hdf_node']['definition'][()] + return nxdef.decode() + except KeyError: # 'NO Definition referenced' + return "NXentry" + + +def get_nx_class(nxdl_elem): + """Get the nexus class for a NXDL node""" + if 'category' in nxdl_elem.attrib.keys(): + return None + try: + return nxdl_elem.attrib['type'] + except KeyError: + return 'NX_CHAR' + + +def get_nx_namefit(hdf_name, name, name_any=False): + """Checks if an HDF5 node name corresponds to a child of the NXDL element +uppercase letters in front can be replaced by arbitraty name, but +uppercase to lowercase match is preferred, +so such match is counted as a measure of the fit""" + if name == hdf_name: + return len(name) * 2 + # count leading capitals + counting = 0 + while counting < len(name) and name[counting].upper() == name[counting]: + counting += 1 + if name_any or counting == len(name) or \ + (counting > 0 and hdf_name.endswith(name[counting:])): # if potential fit + # count the matching chars + fit = 0 + for i in range(min(counting, len(hdf_name))): + if hdf_name[i].upper() == name[i]: + fit += 1 + else: + break + if fit == min(counting, len(hdf_name)): # accept only full fits as better fits + return fit + return 0 + return -1 # no fit + + +def get_nx_classes(): + """Read base classes from the NeXus definition folder. +Check each file in base_classes, applications, contributed_definitions. +If its category attribute is 'base', then it is added to the list. """ + base_classes = sorted(glob(os.path.join(get_nexus_definitions_path(), + 'base_classes', '*.nxdl.xml'))) + applications = sorted(glob(os.path.join(get_nexus_definitions_path(), + 'applications', '*.nxdl.xml'))) + contributed = sorted(glob(os.path.join(get_nexus_definitions_path(), + 'contributed_definitions', '*.nxdl.xml'))) + nx_clss = [] + for nexus_file in base_classes + applications + contributed: + root = get_xml_root(nexus_file) + if root.attrib['category'] == 'base': + nx_clss.append(str(nexus_file[nexus_file.rindex(os.sep) + 1:])[:-9]) + nx_clss = sorted(nx_clss) + return nx_clss + + +def get_nx_units(): + """Read unit kinds from the NeXus definition/nxdlTypes.xsd file""" + filepath = f"{get_nexus_definitions_path()}{os.sep}nxdlTypes.xsd" + root = get_xml_root(filepath) + units_and_type_list = [] + for child in root: + for i in child.attrib.values(): + units_and_type_list.append(i) + flag = False + for line in units_and_type_list: + if line == 'anyUnitsAttr': + flag = True + nx_units = [] + elif 'NX' in line and flag is True: + nx_units.append(line) + elif line == 'primitiveType': + flag = False + else: + pass + return nx_units + + +def get_nx_attribute_type(): + """Read attribute types from the NeXus definition/nxdlTypes.xsd file""" + filepath = get_nexus_definitions_path() + '/nxdlTypes.xsd' + root = get_xml_root(filepath) + units_and_type_list = [] + for child in root: + for i in child.attrib.values(): + units_and_type_list.append(i) + flag = False + for line in units_and_type_list: + if line == 'primitiveType': + flag = True + nx_types = [] + elif 'NX' in line and flag is True: + nx_types.append(line) + elif line == 'anyUnitsAttr': + flag = False + else: + pass + return nx_types + + +def get_node_name(node): + '''Node - xml node. Returns html documentation name. + Either as specified by the 'name' or taken from the type (nx_class). + Note that if only class name is available, the NX prefix is removed and + the string is converted to UPPER case.''' + if 'name' in node.attrib.keys(): + name = node.attrib['name'] + else: + name = node.attrib['type'] + if name.startswith('NX'): + name = name[2:].upper() + return name + + +def belongs_to(nxdl_elem, child, name, class_type=None, hdf_name=None): + """Checks if an HDF5 node name corresponds to a child of the NXDL element +uppercase letters in front can be replaced by arbitraty name, but +uppercase to lowercase match is preferred""" + if class_type and get_nx_class(child) != class_type: + return False + act_htmlname = get_node_name(child) + chk_name = hdf_name or name + if act_htmlname == chk_name: + return True + if not hdf_name: # search for name fits is only allowed for hdf_nodes + return False + try: # check if nameType allows different name + name_any = bool(child.attrib['nameType'] == "any") + except KeyError: + name_any = False + params = [act_htmlname, chk_name, name_any, nxdl_elem, child, name] + return belongs_to_capital(params) + + +def belongs_to_capital(params): + """Checking continues for Upper case""" + (act_htmlname, chk_name, name_any, nxdl_elem, child, name) = params + # or starts with capital and no reserved words used + if (name_any or 'A' <= act_htmlname[0] <= 'Z') and \ + name != 'doc' and name != 'enumeration': + fit = get_nx_namefit(chk_name, act_htmlname, name_any) # check if name fits + if fit < 0: + return False + for child2 in nxdl_elem: + if get_local_name_from_xml(child) != \ + get_local_name_from_xml(child2) or get_node_name(child2) == act_htmlname: + continue + # check if the name of another sibling fits better + name_any2 = "nameType" in child2.attrib.keys() and child2.attrib["nameType"] == "any" + fit2 = get_nx_namefit(chk_name, get_node_name(child2), name_any2) + if fit2 > fit: + return False + # accept this fit + return True + return False + + +def get_local_name_from_xml(element): + """Helper function to extract the element tag without the namespace.""" + return element.tag[element.tag.rindex("}") + 1:] + + +def get_own_nxdl_child_reserved_elements(child, name, nxdl_elem): + """checking reserved elements, like doc, enumeration""" + if get_local_name_from_xml(child) == 'doc' and name == 'doc': + if nxdl_elem.get('nxdlbase'): + child.set('nxdlbase', nxdl_elem.get('nxdlbase')) + child.set('nxdlbase_class', nxdl_elem.get('nxdlbase_class')) + child.set('nxdlpath', nxdl_elem.get('nxdlpath') + '/doc') + return child + if get_local_name_from_xml(child) == 'enumeration' and name == 'enumeration': + if nxdl_elem.get('nxdlbase'): + child.set('nxdlbase', nxdl_elem.get('nxdlbase')) + child.set('nxdlbase_class', nxdl_elem.get('nxdlbase_class')) + child.set('nxdlpath', nxdl_elem.get('nxdlpath') + '/enumeration') + return child + return False + + +def get_own_nxdl_child_base_types(child, class_type, nxdl_elem, name, hdf_name): + """checking base types of group, field,m attribute""" + if get_local_name_from_xml(child) == 'group': + if (class_type is None or (class_type and get_nx_class(child) == class_type)) and \ + belongs_to(nxdl_elem, child, name, class_type, hdf_name): + if nxdl_elem.get('nxdlbase'): + child.set('nxdlbase', nxdl_elem.get('nxdlbase')) + child.set('nxdlbase_class', nxdl_elem.get('nxdlbase_class')) + child.set('nxdlpath', nxdl_elem.get('nxdlpath') + '/' + get_node_name(child)) + return child + if get_local_name_from_xml(child) == 'field' and \ + belongs_to(nxdl_elem, child, name, None, hdf_name): + if nxdl_elem.get('nxdlbase'): + child.set('nxdlbase', nxdl_elem.get('nxdlbase')) + child.set('nxdlbase_class', nxdl_elem.get('nxdlbase_class')) + child.set('nxdlpath', nxdl_elem.get('nxdlpath') + '/' + get_node_name(child)) + return child + if get_local_name_from_xml(child) == 'attribute' and \ + belongs_to(nxdl_elem, child, name, None, hdf_name): + if nxdl_elem.get('nxdlbase'): + child.set('nxdlbase', nxdl_elem.get('nxdlbase')) + child.set('nxdlbase_class', nxdl_elem.get('nxdlbase_class')) + child.set('nxdlpath', nxdl_elem.get('nxdlpath') + '/' + get_node_name(child)) + return child + return False + + +def get_own_nxdl_child(nxdl_elem, name, class_type=None, hdf_name=None, nexus_type=None): + """Checks if an NXDL child node fits to the specific name (either nxdl or hdf) + name - nxdl name + class_type - nxdl type or hdf classname (for groups, it is obligatory) + hdf_name - hdf name""" + for child in nxdl_elem: + if 'name' in child.attrib and child.attrib['name'] == name: + if nxdl_elem.get('nxdlbase'): + child.set('nxdlbase', nxdl_elem.get('nxdlbase')) + child.set('nxdlbase_class', nxdl_elem.get('nxdlbase_class')) + child.set('nxdlpath', nxdl_elem.get('nxdlpath') + '/' + get_node_name(child)) + return child + for child in nxdl_elem: + if "name" in child.attrib and child.attrib["name"] == name: + child.set('nxdlbase', nxdl_elem.get('nxdlbase')) + return child + + for child in nxdl_elem: + result = get_own_nxdl_child_reserved_elements(child, name, nxdl_elem) + if result is not False: + return result + if nexus_type and get_local_name_from_xml(child) != nexus_type: + continue + result = get_own_nxdl_child_base_types(child, class_type, nxdl_elem, name, hdf_name) + if result is not False: + return result + return None + + +def find_definition_file(bc_name): + """find the nxdl file corresponding to the name. + Note that it first checks in contributed and goes beyond only if no contributed found""" + bc_filename = None + for nxdl_folder in ['contributed_definitions', 'base_classes', 'applications']: + if os.path.exists(f"{get_nexus_definitions_path()}{os.sep}" + f"{nxdl_folder}{os.sep}{bc_name}.nxdl.xml"): + bc_filename = f"{get_nexus_definitions_path()}{os.sep}" \ + f"{nxdl_folder}{os.sep}{bc_name}.nxdl.xml" + break + return bc_filename + + +def get_nxdl_child(nxdl_elem, name, class_type=None, hdf_name=None, nexus_type=None, go_base=True): # pylint: disable=too-many-arguments + """Get the NXDL child node corresponding to a specific name +(e.g. of an HDF5 node,or of a documentation) note that if child is not found in application +definition, it also checks for the base classes""" + # search for possible fits for hdf_nodes : skipped + # only exact hits are returned when searching an nxdl child + own_child = get_own_nxdl_child(nxdl_elem, name, class_type, hdf_name, nexus_type) + if own_child is not None: + return own_child + if not go_base: + return None + bc_name = get_nx_class(nxdl_elem) # check in the base class, app def or contributed + if bc_name[2] == '_': # filter primitive types + return None + if bc_name == "group": # Check if it is the root element. Then send to NXroot.nxdl.xml + bc_name = "NXroot" + bc_filename = find_definition_file(bc_name) + if not bc_filename: + raise ValueError('nxdl file not found in definitions folder!') + bc_obj = ET.parse(bc_filename).getroot() + bc_obj.set('nxdlbase', bc_filename) + if 'category' in bc_obj.attrib: + bc_obj.set('nxdlbase_class', bc_obj.attrib['category']) + bc_obj.set('nxdlpath', '') + return get_own_nxdl_child(bc_obj, name, class_type, hdf_name, nexus_type) + + +def get_required_string(nxdl_elem): + """Check for being REQUIRED, RECOMMENDED, OPTIONAL, NOT IN SCHEMA""" + if nxdl_elem is None: + return "<>" + is_optional = 'optional' in nxdl_elem.attrib.keys() \ + and nxdl_elem.attrib['optional'] == "true" + is_minoccurs = 'minOccurs' in nxdl_elem.attrib.keys() \ + and nxdl_elem.attrib['minOccurs'] == "0" + is_recommended = 'recommended' in nxdl_elem.attrib.keys() \ + and nxdl_elem.attrib['recommended'] == "true" + + if is_recommended: + return "<>" + if is_optional or is_minoccurs: + return "<>" + # default optionality: in BASE CLASSES is true; in APPLICATIONS is false + try: + if nxdl_elem.get('nxdlbase_class') == 'base': + return "<>" + except TypeError: + return "<>" + return "<>" + + +def chk_nxdataaxis_v2(hdf_node, name, logger): + """Check if dataset is an axis""" + own_signal = hdf_node.attrs.get('signal') # check for being a Signal + if own_signal is str and own_signal == "1": + logger.debug("Dataset referenced (v2) as NXdata SIGNAL") + own_axes = hdf_node.attrs.get('axes') # check for being an axis + if own_axes is str: + axes = own_axes.split(':') + for i in len(axes): + if axes[i] and name == axes[i]: + logger.debug("Dataset referenced (v2) as NXdata AXIS #%d", i) + return None + ownpaxis = hdf_node.attrs.get('primary') + own_axis = hdf_node.attrs.get('axis') + if own_axis is int: + # also convention v1 + if ownpaxis is int and ownpaxis == 1: + logger.debug("Dataset referenced (v2) as NXdata AXIS #%d", own_axis - 1) + else: + logger.debug( + "Dataset referenced (v2) as NXdata (primary/alternative) AXIS #%d", own_axis - 1) + return None + + +def chk_nxdataaxis(hdf_node, name, logger): + """NEXUS Data Plotting Standard v3: new version from 2014""" + if not isinstance(hdf_node, h5py.Dataset): # check if it is a field in an NXdata node + return None + parent = hdf_node.parent + if not parent or (parent and not parent.attrs.get('NX_class') == "NXdata"): + return None + signal = parent.attrs.get('signal') # chk for Signal + if signal and name == signal: + logger.debug("Dataset referenced as NXdata SIGNAL") + return None + axes = parent.attrs.get('axes') # check for default Axes + if axes is str: + if name == axes: + logger.debug("Dataset referenced as NXdata AXIS") + return None + elif axes is not None: + for i, j in enumerate(axes): + if name == j: + indices = parent.attrs.get(j + '_indices') + if indices is int: + logger.debug(f"Dataset referenced as NXdata AXIS #{indices}") + else: + logger.debug(f"Dataset referenced as NXdata AXIS #{i}") + return None + indices = parent.attrs.get(name + '_indices') # check for alternative Axes + if indices is int: + logger.debug(f"Dataset referenced as NXdata alternative AXIS #{indices}") + return chk_nxdataaxis_v2(hdf_node, name, logger) # check for older conventions + + +# below there are some functions used in get_nxdl_doc function: +def write_doc_string(logger, doc, attr): + """Simple function that prints a line in the logger if doc exists""" + if doc: + logger.debug("@" + attr + ' [NX_CHAR]') + return logger, doc, attr + + +def try_find_units(logger, elem, nxdl_path, doc, attr): + """Try to find if units is defined inside the field in the NXDL element, + otherwise try to find if units is defined as a child of the NXDL element.""" + try: # try to find if units is defined inside the field in the NXDL element + unit = elem.attrib[attr] + if doc: + logger.debug(get_node_concept_path(elem) + "@" + attr + ' [' + unit + ']') + elem = None + nxdl_path.append(attr) + except KeyError: # otherwise try to find if units is defined as a child of the NXDL element + orig_elem = elem + elem = get_nxdl_child(elem, attr, nexus_type='attribute') + if elem is not None: + if doc: + logger.debug(get_node_concept_path(orig_elem) + + "@" + attr + ' - [' + get_nx_class(elem) + ']') + nxdl_path.append(elem) + else: # if no units category were defined in NXDL: + if doc: + logger.debug(get_node_concept_path(orig_elem) + + "@" + attr + " - REQUIRED, but undefined unit category") + nxdl_path.append(attr) + return logger, elem, nxdl_path, doc, attr + + +def check_attr_name_nxdl(param): + """Check for ATTRIBUTENAME_units in NXDL (normal). +If not defined, check for ATTRIBUTENAME to see if the ATTRIBUTE +is in the SCHEMA, but no units category were defined. """ + (logger, elem, nxdl_path, doc, attr, req_str) = param + orig_elem = elem + elem2 = get_nxdl_child(elem, attr, nexus_type='attribute') + if elem2 is not None: # check for ATTRIBUTENAME_units in NXDL (normal) + elem = elem2 + if doc: + logger.debug(get_node_concept_path(orig_elem) + + "@" + attr + ' - [' + get_nx_class(elem) + ']') + nxdl_path.append(elem) + else: + # if not defined, check for ATTRIBUTENAME to see if the ATTRIBUTE + # is in the SCHEMA, but no units category were defined + elem2 = get_nxdl_child(elem, attr[:-6], nexus_type='attribute') + if elem2 is not None: + req_str = '<>' + if doc: + logger.debug(get_node_concept_path(orig_elem) + + "@" + attr + " - RECOMMENDED, but undefined unit category") + nxdl_path.append(attr) + else: # otherwise: NOT IN SCHEMA + elem = elem2 + if doc: + logger.debug(get_node_concept_path(orig_elem) + "@" + attr + " - IS NOT IN SCHEMA") + return logger, elem, nxdl_path, doc, attr, req_str + + +def try_find_default(logger, orig_elem, elem, nxdl_path, doc, attr): # pylint: disable=too-many-arguments + """Try to find if default is defined as a child of the NXDL element """ + if elem is not None: + if doc: + logger.debug(get_node_concept_path(orig_elem) + + "@" + attr + ' - [' + get_nx_class(elem) + ']') + nxdl_path.append(elem) + else: # if no default category were defined in NXDL: + if doc: + logger.debug(get_node_concept_path(orig_elem) + "@" + attr + " - [NX_CHAR]") + nxdl_path.append(attr) + return logger, elem, nxdl_path, doc, attr + + +def other_attrs(logger, orig_elem, elem, nxdl_path, doc, attr): # pylint: disable=too-many-arguments + """Handle remaining attributes """ + if elem is not None: + if doc: + logger.debug(get_node_concept_path(orig_elem) + + "@" + attr + ' - [' + get_nx_class(elem) + ']') + nxdl_path.append(elem) + else: + if doc: + logger.debug(get_node_concept_path(orig_elem) + "@" + attr + " - IS NOT IN SCHEMA") + return logger, elem, nxdl_path, doc, attr + + +def check_deprecation_enum_axis(variables, doc, elist, attr, hdf_node): + """Check for several attributes. - deprecation - enums - nxdataaxis """ + logger, elem, path = variables + dep_str = elem.attrib.get('deprecated') # check for deprecation + if dep_str: + if doc: + logger.debug("DEPRECATED - " + dep_str) + for base_elem in elist if not attr else [elem]: # check for enums + sdoc = get_nxdl_child(base_elem, 'enumeration', go_base=False) + if sdoc is not None: + if doc: + logger.debug("enumeration (" + get_node_concept_path(base_elem) + "):") + for item in sdoc: + if get_local_name_from_xml(item) == 'item': + if doc: + logger.debug("-> " + item.attrib['value']) + chk_nxdataaxis(hdf_node, path.split('/')[-1], logger) # look for NXdata reference (axes/signal) + for base_elem in elist if not attr else [elem]: # check for doc + sdoc = get_nxdl_child(base_elem, 'doc', go_base=False) + if doc: + logger.debug("documentation (" + get_node_concept_path(base_elem) + "):") + logger.debug(sdoc.text if sdoc is not None else "") + return logger, elem, path, doc, elist, attr, hdf_node + + +def get_node_concept_path(elem): + """get the short version of nxdlbase:nxdlpath""" + return str(elem.get('nxdlbase').split('/')[-1] + ":" + elem.get('nxdlpath')) + + +def get_nxdl_attr_doc( # pylint: disable=too-many-arguments,too-many-locals + elem, elist, attr, hdf_node, logger, doc, nxdl_path, req_str, path, hdf_info): + """Get nxdl documentation for an attribute""" + new_elem = [] + old_elem = elem + for elem_index, act_elem1 in enumerate(elist): + act_elem = act_elem1 + # NX_class is a compulsory attribute for groups in a nexus file + # which should match the type of the corresponding NXDL element + if attr == 'NX_class' and not isinstance(hdf_node, h5py.Dataset) and elem_index == 0: + elem = None + logger, doc, attr = write_doc_string(logger, doc, attr) + new_elem = elem + break + # units category is a compulsory attribute for any fields + if attr == 'units' and isinstance(hdf_node, h5py.Dataset): + req_str = "<>" + logger, act_elem, nxdl_path, doc, attr = try_find_units(logger, + act_elem, + nxdl_path, + doc, + attr) + # units for attributes can be given as ATTRIBUTENAME_units + elif attr.endswith('_units'): + logger, act_elem, nxdl_path, doc, attr, req_str = check_attr_name_nxdl((logger, + act_elem, + nxdl_path, + doc, + attr, + req_str)) + # default is allowed for groups + elif attr == 'default' and not isinstance(hdf_node, h5py.Dataset): + req_str = "<>" + # try to find if default is defined as a child of the NXDL element + act_elem = get_nxdl_child(act_elem, attr, nexus_type='attribute', go_base=False) + logger, act_elem, nxdl_path, doc, attr = try_find_default(logger, + act_elem1, + act_elem, + nxdl_path, + doc, + attr) + else: # other attributes + act_elem = get_nxdl_child(act_elem, attr, nexus_type='attribute', go_base=False) + if act_elem is not None: + logger, act_elem, nxdl_path, doc, attr = \ + other_attrs(logger, act_elem1, act_elem, nxdl_path, doc, attr) + if act_elem is not None: + new_elem.append(act_elem) + if req_str is None: + req_str = get_required_string(act_elem) # check for being required + if doc: + logger.debug(req_str) + variables = [logger, act_elem, path] + logger, elem, path, doc, elist, attr, hdf_node = check_deprecation_enum_axis(variables, + doc, + elist, + attr, + hdf_node) + elem = old_elem + if req_str is None and doc: + if attr != 'NX_class': + logger.debug("@" + attr + " - IS NOT IN SCHEMA") + logger.debug("") + return (req_str, get_nxdl_entry(hdf_info), nxdl_path) + + +def get_nxdl_doc(hdf_info, logger, doc, attr=False): + """Get nxdl documentation for an HDF5 node (or its attribute)""" + hdf_node = hdf_info['hdf_node'] + # new way: retrieve multiple inherited base classes + (class_path, nxdl_path, elist) = \ + get_inherited_nodes(None, nx_name=get_nxdl_entry(hdf_info), hdf_node=hdf_node, + hdf_path=hdf_info['hdf_path'] if 'hdf_path' in hdf_info else None, + hdf_root=hdf_info['hdf_root'] if 'hdf_root' in hdf_info else None) + elem = elist[0] if class_path and elist else None + if doc: + logger.debug("classpath: " + str(class_path)) + logger.debug("NOT IN SCHEMA" if elem is None else + "classes:\n" + "\n".join + (get_node_concept_path(e) for e in elist)) + # old solution with a single elem instead of using elist + path = get_nx_class_path(hdf_info) + req_str = None + if elem is None: + if doc: + logger.debug("") + return ('None', None, None) + if attr: + return get_nxdl_attr_doc(elem, elist, attr, hdf_node, logger, doc, nxdl_path, + req_str, path, hdf_info) + req_str = get_required_string(elem) # check for being required + if doc: + logger.debug(req_str) + variables = [logger, elem, path] + logger, elem, path, doc, elist, attr, hdf_node = check_deprecation_enum_axis(variables, + doc, + elist, + attr, + hdf_node) + return (req_str, get_nxdl_entry(hdf_info), nxdl_path) + + +def get_doc(node, ntype, nxhtml, nxpath): + """Get documentation""" + # URL for html documentation + anchor = '' + for n_item in nxpath: + anchor += n_item.lower() + "-" + anchor = ('https://manual.nexusformat.org/classes/', + nxhtml + "#" + anchor.replace('_', '-') + ntype) + if not ntype: + anchor = anchor[:-1] + doc = "" # RST documentation from the field 'doc' + doc_field = node.find("doc") + if doc_field is not None: + doc = doc_field.text + (index, enums) = get_enums(node) # enums + if index: + enum_str = "\n " + ("Possible values:" + if len(enums.split(',')) > 1 + else "Obligatory value:") + "\n " + enums + "\n" + else: + enum_str = "" + return anchor, doc + enum_str + + +def print_doc(node, ntype, level, nxhtml, nxpath): + """Print documentation""" + anchor, doc = get_doc(node, ntype, nxhtml, nxpath) + print(" " * (level + 1) + anchor) + preferred_width = 80 + level * 2 + wrapper = textwrap.TextWrapper(initial_indent=' ' * (level + 1), width=preferred_width, + subsequent_indent=' ' * (level + 1), expand_tabs=False, + tabsize=0) + if doc is not None: + for par in doc.split('\n'): + print(wrapper.fill(par)) + + +def get_namespace(element): + """Extracts the namespace for elements in the NXDL""" + return element.tag[element.tag.index("{"):element.tag.rindex("}") + 1] + + +def get_enums(node): + """Makes list of enumerations, if node contains any. + Returns comma separated STRING of enumeration values, if there are enum tag, + otherwise empty string.""" + # collect item values from enumeration tag, if any + namespace = get_namespace(node) + enums = [] + for enumeration in node.findall(f"{namespace}enumeration"): + for item in enumeration.findall(f"{namespace}item"): + enums.append(item.attrib["value"]) + enums = ','.join(enums) + if enums != "": + return (True, '[' + enums + ']') + return (False, "") # if there is no enumeration tag, returns empty string + + +def add_base_classes(elist, nx_name=None, elem: ET.Element = None): + """Add the base classes corresponding to the last eleme in elist to the list. Note that if +elist is empty, a nxdl file with the name of nx_name or a rather room elem is used if provided""" + if elist and nx_name is None: + nx_name = get_nx_class(elist[-1]) + # to support recursive defintions, like NXsample in NXsample, the following test is removed + # if elist and nx_name and f"{nx_name}.nxdl.xml" in (e.get('nxdlbase') for e in elist): + # return + if elem is None: + if not nx_name: + return + nxdl_file_path = find_definition_file(nx_name) + if nxdl_file_path is None: + nxdl_file_path = f"{nx_name}.nxdl.xml" + elem = ET.parse(nxdl_file_path).getroot() + elem.set('nxdlbase', nxdl_file_path) + else: + elem.set('nxdlbase', '') + if 'category' in elem.attrib: + elem.set('nxdlbase_class', elem.attrib['category']) + elem.set('nxdlpath', '') + elist.append(elem) + # add inherited base class + if 'extends' in elem.attrib and elem.attrib['extends'] != 'NXobject': + add_base_classes(elist, elem.attrib['extends']) + else: + add_base_classes(elist) + + +def set_nxdlpath(child, nxdl_elem): + """ + Setting up child nxdlbase, nxdlpath and nxdlbase_class from nxdl_element. + """ + if nxdl_elem.get('nxdlbase'): + child.set('nxdlbase', nxdl_elem.get('nxdlbase')) + child.set('nxdlbase_class', nxdl_elem.get('nxdlbase_class')) + child.set('nxdlpath', nxdl_elem.get('nxdlpath') + '/' + get_node_name(child)) + return child + + +def get_direct_child(nxdl_elem, html_name): + """ returns the child of nxdl_elem which has a name + corresponding to the the html documentation name html_name""" + for child in nxdl_elem: + if get_local_name_from_xml(child) in ('group', 'field', 'attribute') and \ + html_name == get_node_name(child): + decorated_child = set_nxdlpath(child, nxdl_elem) + return decorated_child + return None + + +def get_field_child(nxdl_elem, html_name): + """ returns the child of nxdl_elem which has a name + corresponding to the html documentation name html_name""" + data_child = None + for child in nxdl_elem: + if get_local_name_from_xml(child) != 'field': + continue + if get_node_name(child) == html_name: + data_child = set_nxdlpath(child, nxdl_elem) + break + return data_child + + +def get_best_nxdata_child(nxdl_elem, hdf_node, hdf_name): + """ returns the child of an NXdata nxdl_elem which has a name + corresponding to the hdf_name""" + nxdata = hdf_node.parent + signals = [] + if 'signal' in nxdata.attrs.keys(): + signals.append(nxdata.attrs.get("signal")) + if "auxiliary_signals" in nxdata.attrs.keys(): + for aux_signal in nxdata.attrs.get("auxiliary_signals"): + signals.append(aux_signal) + data_child = get_field_child(nxdl_elem, 'DATA') + data_error_child = get_field_child(nxdl_elem, 'FIELDNAME_errors') + for signal in signals: + if signal == hdf_name: + return (data_child, 100) + if hdf_name.endswith('_errors') and signal == hdf_name[:-7]: + return (data_error_child, 100) + axes = [] + if "axes" in nxdata.attrs.keys(): + for axis in nxdata.attrs.get("axes"): + axes.append(axis) + axis_child = get_field_child(nxdl_elem, 'AXISNAME') + for axis in axes: + if axis == hdf_name: + return (axis_child, 100) + return (None, 0) + + +def get_best_child(nxdl_elem, hdf_node, hdf_name, hdf_class_name, nexus_type): + """ returns the child of nxdl_elem which has a name + corresponding to the the html documentation name html_name""" + bestfit = -1 + bestchild = None + if 'name' in nxdl_elem.attrib.keys() and nxdl_elem.attrib['name'] == 'NXdata' and \ + hdf_node is not None and hdf_node.parent is not None and \ + hdf_node.parent.attrs.get('NX_class') == 'NXdata': + (fnd_child, fit) = get_best_nxdata_child(nxdl_elem, hdf_node, hdf_name) + if fnd_child is not None: + return (fnd_child, fit) + for child in nxdl_elem: + fit = -2 + if get_local_name_from_xml(child) == nexus_type and \ + (nexus_type != 'group' or get_nx_class(child) == hdf_class_name): + name_any = "nameType" in nxdl_elem.attrib.keys() and \ + nxdl_elem.attrib["nameType"] == "any" + fit = get_nx_namefit(hdf_name, get_node_name(child), name_any) + if fit > bestfit: + bestfit = fit + bestchild = set_nxdlpath(child, nxdl_elem) + return (bestchild, bestfit) + + +def walk_elist(elist, html_name): + """Handle elist from low priority inheritance classes to higher""" + for ind in range(len(elist) - 1, -1, -1): + child = get_direct_child(elist[ind], html_name) + if child is None: + # check for names fitting to a superclas definition + main_child = None + for potential_direct_parent in elist: + main_child = get_direct_child(potential_direct_parent, html_name) + if main_child is not None: + (fitting_child, _) = get_best_child(elist[ind], None, html_name, + get_nx_class(main_child), + get_local_name_from_xml(main_child)) + if fitting_child is not None: + child = fitting_child + break + elist[ind] = child + if elist[ind] is None: + del elist[ind] + continue + # override: remove low priority inheritance classes if class_type is overriden + if len(elist) > ind + 1 and get_nx_class(elist[ind]) != get_nx_class(elist[ind + 1]): + del elist[ind + 1:] + # add new base class(es) if new element brings such (and not a primitive type) + if len(elist) == ind + 1 and get_nx_class(elist[ind])[0:3] != 'NX_': + add_base_classes(elist) + return elist, html_name + + +def helper_get_inherited_nodes(hdf_info2, elist, pind, attr): + """find the best fitting name in all children""" + hdf_path, hdf_node, hdf_class_path = hdf_info2 + hdf_name = hdf_path[pind] + hdf_class_name = hdf_class_path[pind] + if pind < len(hdf_path) - (2 if attr else 1): + act_nexus_type = 'group' + elif pind == len(hdf_path) - 1 and attr: + act_nexus_type = 'attribute' + else: + act_nexus_type = 'field' if isinstance(hdf_node, h5py.Dataset) else 'group' + # find the best fitting name in all children + bestfit = -1 + html_name = None + for ind in range(len(elist) - 1, -1, -1): + newelem, fit = get_best_child(elist[ind], + hdf_node, + hdf_name, + hdf_class_name, + act_nexus_type) + if fit >= bestfit and newelem is not None: + html_name = get_node_name(newelem) + return hdf_path, hdf_node, hdf_class_path, elist, pind, attr, html_name + + +def get_hdf_path(hdf_info): + """Get the hdf_path from an hdf_info""" + if 'hdf_path' in hdf_info: + return hdf_info['hdf_path'].split('/')[1:] + return hdf_info['hdf_node'].name.split('/')[1:] + + +@lru_cache(maxsize=None) +def get_inherited_nodes(nxdl_path: str = None, # pylint: disable=too-many-arguments,too-many-locals + nx_name: str = None, elem: ET.Element = None, + hdf_node=None, hdf_path=None, hdf_root=None, attr=False): + """Returns a list of ET.Element for the given path.""" + # let us start with the given definition file + elist = [] # type: ignore[var-annotated] + add_base_classes(elist, nx_name, elem) + nxdl_elem_path = [elist[0]] + + class_path = [] # type: ignore[var-annotated] + if hdf_node is not None: + hdf_info = {'hdf_node': hdf_node} + if hdf_path: + hdf_info['hdf_path'] = hdf_path + if hdf_root: + hdf_root['hdf_root'] = hdf_root + hdf_node = hdf_info['hdf_node'] + hdf_path = get_hdf_path(hdf_info) + hdf_class_path = get_nx_class_path(hdf_info).split('/')[1:] + if attr: + hdf_path.append(attr) + hdf_class_path.append(attr) + path = hdf_path + else: + html_path = nxdl_path.split('/')[1:] + path = html_path + for pind in range(len(path)): + if hdf_node is not None: + hdf_info2 = [hdf_path, hdf_node, hdf_class_path] + [hdf_path, hdf_node, hdf_class_path, elist, + pind, attr, html_name] = helper_get_inherited_nodes(hdf_info2, elist, + pind, attr) + if html_name is None: # return if NOT IN SCHEMA + return (class_path, nxdl_elem_path, None) + else: + html_name = html_path[pind] + elist, html_name = walk_elist(elist, html_name) + if elist: + class_path.append(get_nx_class(elist[0])) + nxdl_elem_path.append(elist[0]) + return (class_path, nxdl_elem_path, elist) + + +def get_node_at_nxdl_path(nxdl_path: str = None, + nx_name: str = None, elem: ET.Element = None, + exc: bool = True): + """Returns an ET.Element for the given path. + This function either takes the name for the NeXus Application Definition + we are looking for or the root elem from a previously loaded NXDL file + and finds the corresponding XML element with the needed attributes.""" + try: + (class_path, nxdlpath, elist) = get_inherited_nodes(nxdl_path, nx_name, elem) + except ValueError as value_error: + if exc: + raise NxdlAttributeError(f"Attributes were not found for {nxdl_path}. " + "Please check this entry in the template dictionary.") \ + from value_error + return None + if class_path and nxdlpath and elist: + elem = elist[0] + else: + elem = None + if exc: + raise NxdlAttributeError(f"Attributes were not found for {nxdl_path}. " + "Please check this entry in the template dictionary.") + return elem + + +def process_node(hdf_node, hdf_path, parser, logger, doc=True): + """Processes an hdf5 node. +- it logs the node found and also checks for its attributes +- retrieves the corresponding nxdl documentation +TODO: +- follow variants +- NOMAD parser: store in NOMAD """ + hdf_info = {'hdf_path': hdf_path, 'hdf_node': hdf_node} + if isinstance(hdf_node, h5py.Dataset): + logger.debug(f'===== FIELD (/{hdf_path}): {hdf_node}') + val = str(hdf_node[()]).split('\n') if len(hdf_node.shape) <= 1 else str( + hdf_node[0]).split('\n') + logger.debug(f'value: {val[0]} {"..." if len(val) > 1 else ""}') + else: + logger.debug( + f"===== GROUP (/{hdf_path} " + f"[{get_nxdl_entry(hdf_info)}" + f"::{get_nx_class_path(hdf_info)}]): {hdf_node}" + ) + (req_str, nxdef, nxdl_path) = get_nxdl_doc(hdf_info, logger, doc) + if parser is not None and isinstance(hdf_node, h5py.Dataset): + parser({"hdf_info": hdf_info, + "nxdef": nxdef, + "nxdl_path": nxdl_path, + "val": val, + "logger": logger}) + for key, value in hdf_node.attrs.items(): + logger.debug(f'===== ATTRS (/{hdf_path}@{key})') + val = str(value).split('\n') + logger.debug(f'value: {val[0]} {"..." if len(val) > 1 else ""}') + (req_str, nxdef, nxdl_path) = \ + get_nxdl_doc(hdf_info, logger, doc, attr=key) + if ( + parser is not None + and req_str is not None + and 'NOT IN SCHEMA' not in req_str + and 'None' not in req_str + ): + parser({"hdf_info": hdf_info, + "nxdef": nxdef, + "nxdl_path": nxdl_path, + "val": val, + "logger": logger}, attr=key) + + +def logger_auxiliary_signal(logger, nxdata): + """Handle the presence of auxiliary signal""" + aux = nxdata.attrs.get('auxiliary_signals') + if aux is not None: + if isinstance(aux, str): + aux = [aux] + for asig in aux: + logger.debug(f'Further auxiliary signal has been identified: {asig}') + return logger + + +def print_default_plotable_header(logger): + """Print a three-lines header""" + logger.debug('========================') + logger.debug('=== Default Plotable ===') + logger.debug('========================') + + +def get_default_plotable(root, logger): + """Get default plotable""" + print_default_plotable_header(logger) + # v3 from 2014 + # nxentry + nxentry = None + default_nxentry_group_name = root.attrs.get("default") + if default_nxentry_group_name: + try: + nxentry = root[default_nxentry_group_name] + except KeyError: + nxentry = None + if not nxentry: + nxentry = entry_helper(root) + if not nxentry: + logger.debug('No NXentry has been found') + return + logger.debug('') + logger.debug('NXentry has been identified: ' + nxentry.name) + # nxdata + nxdata = None + nxgroup = nxentry + default_group_name = nxgroup.attrs.get("default") + while default_group_name: + try: + nxgroup = nxgroup[default_group_name] + default_group_name = nxgroup.attrs.get("default") + except KeyError: + pass + if nxgroup == nxentry: + nxdata = nxdata_helper(nxentry) + else: + nxdata = nxgroup + if not nxdata: + logger.debug('No NXdata group has been found') + return + logger.debug('') + logger.debug('NXdata group has been identified: ' + nxdata.name) + process_node(nxdata, nxdata.name, None, logger, False) + # signal + signal = None + signal_dataset_name = nxdata.attrs.get("signal") + try: + signal = nxdata[signal_dataset_name] + except (TypeError, KeyError): + signal = None + if not signal: + signal = signal_helper(nxdata) + if not signal: + logger.debug('No Signal has been found') + return + logger.debug('') + logger.debug('Signal has been identified: ' + signal.name) + process_node(signal, signal.name, None, logger, False) + logger = logger_auxiliary_signal(logger, nxdata) # check auxiliary_signals + dim = len(signal.shape) + axes = [] # axes + axis_helper(dim, nxdata, signal, axes, logger) + + +def entry_helper(root): + """Check entry related data""" + nxentries = [] + for key in root.keys(): + if isinstance(root[key], h5py.Group) and root[key].attrs.get('NX_class') and \ + root[key].attrs['NX_class'] == "NXentry": + nxentries.append(root[key]) + if len(nxentries) >= 1: + return nxentries[0] + return None + + +def nxdata_helper(nxentry): + """Check if nxentry hdf5 object has a NX_class and, if it contains NXdata, +return its value""" + lnxdata = [] + for key in nxentry.keys(): + if isinstance(nxentry[key], h5py.Group) and nxentry[key].attrs.get('NX_class') and \ + nxentry[key].attrs['NX_class'] == "NXdata": + lnxdata.append(nxentry[key]) + if len(lnxdata) >= 1: + return lnxdata[0] + return None + + +def signal_helper(nxdata): + """Check signal related data""" + signals = [] + for key in nxdata.keys(): + if isinstance(nxdata[key], h5py.Dataset): + signals.append(nxdata[key]) + if len(signals) == 1: # v3: as there was no selection given, only 1 data field shall exists + return signals[0] + if len(signals) > 1: # v2: select the one with an attribute signal="1" attribute + for sig in signals: + if sig.attrs.get("signal") and sig.attrs.get("signal") is str and \ + sig.attrs.get("signal") == "1": + return sig + return None + + +def find_attrib_axis_actual_dim_num(nxdata, a_item, ax_list): + """Finds axis that have defined dimensions""" + # find those with attribute axis= actual dimension number + lax = [] + for key in nxdata.keys(): + if isinstance(nxdata[key], h5py.Dataset): + try: + if nxdata[key].attrs['axis'] == a_item + 1: + lax.append(nxdata[key]) + except KeyError: + pass + if len(lax) == 1: + ax_list.append(lax[0]) + # if there are more alternatives, prioritise the one with an attribute primary="1" + elif len(lax) > 1: + for sax in lax: + if sax.attrs.get('primary') and sax.attrs.get('primary') == 1: + ax_list.insert(0, sax) + else: + ax_list.append(sax) + + +def get_single_or_multiple_axes(nxdata, ax_datasets, a_item, ax_list): + """Gets either single or multiple axes from the NXDL""" + try: + if isinstance(ax_datasets, str): # single axis is defined + # explicite definition of dimension number + ind = nxdata.attrs.get(ax_datasets + '_indices') + if ind and ind is int: + if ind == a_item: + ax_list.append(nxdata[ax_datasets]) + elif a_item == 0: # positional determination of the dimension number + ax_list.append(nxdata[ax_datasets]) + else: # multiple axes are listed + # explicite definition of dimension number + for aax in ax_datasets: + ind = nxdata.attrs.get(aax + '_indices') + if ind and isinstance(ind, int): + if ind == a_item: + ax_list.append(nxdata[aax]) + if not ax_list: # positional determination of the dimension number + ax_list.append(nxdata[ax_datasets[a_item]]) + except KeyError: + pass + return ax_list + + +def axis_helper(dim, nxdata, signal, axes, logger): + """Check axis related data""" + for a_item in range(dim): + ax_list = [] + ax_datasets = nxdata.attrs.get("axes") # primary axes listed in attribute axes + ax_list = get_single_or_multiple_axes(nxdata, ax_datasets, a_item, ax_list) + for attr in nxdata.attrs.keys(): # check for corresponding AXISNAME_indices + if attr.endswith('_indices') and nxdata.attrs[attr] == a_item and \ + nxdata[attr.split('_indices')[0]] not in ax_list: + ax_list.append(nxdata[attr.split('_indices')[0]]) + # v2 # check for ':' separated axes defined in Signal + if not ax_list: + try: + ax_datasets = signal.attrs.get("axes").split(':') + ax_list.append(nxdata[ax_datasets[a_item]]) + except (KeyError, AttributeError): + pass + if not ax_list: # check for axis/primary specifications + find_attrib_axis_actual_dim_num(nxdata, a_item, ax_list) + axes.append(ax_list) + logger.debug('') + logger.debug( + f'For Axis #{a_item}, {len(ax_list)} axes have been identified: {str(ax_list)}' + ) + + +def get_all_is_a_rel_from_hdf_node(hdf_node, hdf_path): + """Return list of nxdl concept paths for a nxdl element which corresponds to + hdf node. + """ + hdf_info = {'hdf_path': hdf_path, 'hdf_node': hdf_node} + (_, _, elist) = \ + get_inherited_nodes(None, nx_name=get_nxdl_entry(hdf_info), hdf_node=hdf_node, + hdf_path=hdf_info['hdf_path'] if 'hdf_path' in hdf_info else None, + hdf_root=hdf_info['hdf_root'] if 'hdf_root' in hdf_info else None) + return elist + + +def hdf_node_to_self_concept_path(hdf_info, logger): + """ Get concept or nxdl path from given hdf_node. + """ + # The bellow logger is for deactivatine unnecessary debug message above + if logger is None: + logger = logging.getLogger(__name__) + logger.setLevel(logging.INFO) + (_, _, nxdl_path) = get_nxdl_doc(hdf_info, logger, None) + con_path = '' + if nxdl_path: + for nd_ in nxdl_path: + con_path = con_path + '/' + get_node_name(nd_) + return con_path + + +class HandleNexus: + """documentation""" + def __init__(self, logger, nexus_file, + d_inq_nd=None, c_inq_nd=None): + self.logger = logger + local_dir = os.path.abspath(os.path.dirname(__file__)) + + self.input_file_name = nexus_file if nexus_file is not None else \ + os.path.join(local_dir, '../../tests/data/nexus/201805_WSe2_arpes.nxs') + self.parser = None + self.in_file = None + self.d_inq_nd = d_inq_nd + self.c_inq_nd = c_inq_nd + # Aggregating hdf path corresponds to concept query node + self.hdf_path_list_for_c_inq_nd = [] + + def visit_node(self, hdf_name, hdf_node): + """Function called by h5py that iterates on each node of hdf5file. + It allows h5py visititems function to visit nodes.""" + if self.d_inq_nd is None and self.c_inq_nd is None: + process_node(hdf_node, '/' + hdf_name, self.parser, self.logger) + elif (self.d_inq_nd is not None + and hdf_name in (self.d_inq_nd, self.d_inq_nd[1:])): + process_node(hdf_node, '/' + hdf_name, self.parser, self.logger) + elif self.c_inq_nd is not None: + attributed_concept = self.c_inq_nd.split('@') + attr = attributed_concept[1] if len(attributed_concept) > 1 else None + elist = get_all_is_a_rel_from_hdf_node(hdf_node, '/' + hdf_name) + if elist is None: + return + fnd_superclass = False + fnd_superclass_attr = False + for elem in reversed(elist): + tmp_path = elem.get('nxdlbase').split('.nxdl')[0] + con_path = '/NX' + tmp_path.split('NX')[-1] + elem.get('nxdlpath') + if fnd_superclass or con_path == attributed_concept[0]: + fnd_superclass = True + if attr is None: + self.hdf_path_list_for_c_inq_nd.append(hdf_name) + break + for attribute in hdf_node.attrs.keys(): + attr_concept = get_nxdl_child(elem, attribute, nexus_type='attribute', + go_base=False) + if attr_concept is not None and \ + attr_concept.get('nxdlpath').endswith(attr): + fnd_superclass_attr = True + con_path = '/NX' + tmp_path.split('NX')[-1] \ + + attr_concept.get('nxdlpath') + self.hdf_path_list_for_c_inq_nd.append(hdf_name + "@" + attribute) + break + if fnd_superclass_attr: + break + + def not_yet_visited(self, root, name): + """checking if a new node has already been visited in its path""" + path = name.split('/') + for i in range(1, len(path)): + act_path = '/'.join(path[:i]) + # print(act_path+' - '+name) + if root['/' + act_path] == root['/' + name]: + return False + return True + + def full_visit(self, root, hdf_node, name, func): + """visiting recursivly all children, but avoiding endless cycles""" + # print(name) + if len(name) > 0: + func(name, hdf_node) + if isinstance(hdf_node, h5py.Group): + for ch_name, child in hdf_node.items(): + full_name = ch_name if len(name) == 0 else name + '/' + ch_name + if self.not_yet_visited(root, full_name): + self.full_visit(root, child, full_name, func) + + def process_nexus_master_file(self, parser): + """Process a nexus master file by processing all its nodes and their attributes""" + self.parser = parser + self.in_file = h5py.File( + self.input_file_name[0] + if isinstance(self.input_file_name, list) + else self.input_file_name, 'r' + ) + self.full_visit(self.in_file, self.in_file, '', self.visit_node) + if self.d_inq_nd is None and self.c_inq_nd is None: + get_default_plotable(self.in_file, self.logger) + # To log the provided concept and concepts founded + if self.c_inq_nd is not None: + for hdf_path in self.hdf_path_list_for_c_inq_nd: + self.logger.info(hdf_path) + self.in_file.close() + + +@click.command() +@click.option( + '-f', + '--nexus-file', + required=False, + default=None, + help=('NeXus file with extension .nxs to learn NeXus different concept' + ' documentation and concept.') +) +@click.option( + '-d', + '--documentation', + required=False, + default=None, + help=("Definition path in nexus output (.nxs) file. Returns debug" + "log relavent with that definition path. Example: /entry/data/delays") +) +@click.option( + '-c', + '--concept', + required=False, + default=None, + help=("Concept path from application definition file (.nxdl,xml). Finds out" + "all the available concept definition (IS-A realation) for rendered" + "concept path. Example: /NXarpes/ENTRY/INSTRUMENT/analyser") +) +def main(nexus_file, documentation, concept): + """The main function to call when used as a script.""" + logging_format = "%(levelname)s: %(message)s" + stdout_handler = logging.StreamHandler(sys.stdout) + stdout_handler.setLevel(logging.DEBUG) + logging.basicConfig(level=logging.INFO, format=logging_format, handlers=[stdout_handler]) + logger = logging.getLogger(__name__) + logger.addHandler(stdout_handler) + logger.setLevel(logging.DEBUG) + logger.propagate = False + if documentation and concept: + raise ValueError("Only one option either documentation (-d) or is_a relation " + "with a concept (-c) can be requested.") + nexus_helper = HandleNexus(logger, nexus_file, + d_inq_nd=documentation, + c_inq_nd=concept) + nexus_helper.process_nexus_master_file(None) + + +if __name__ == '__main__': + main() # pylint: disable=no-value-for-parameter diff --git a/requirements.txt b/requirements.txt index 8b22819ff4..6d024bda3a 100644 --- a/requirements.txt +++ b/requirements.txt @@ -5,7 +5,6 @@ pyyaml # Documentation building sphinx>=5 sphinx-tabs -sphinx-comments # Testing pytest @@ -14,5 +13,3 @@ pytest black>=22.3 flake8>=4 isort>=5.10 - -pynxtools>=0.0.3 \ No newline at end of file From 185f6497ab02c7fc1a819568fa0cea00de1334c6 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Fri, 16 Jun 2023 00:45:17 +0200 Subject: [PATCH 0031/1012] linting --- dev_tools/utils/nexus.py | 1069 +++++++++++++++++++++++--------------- 1 file changed, 645 insertions(+), 424 deletions(-) diff --git a/dev_tools/utils/nexus.py b/dev_tools/utils/nexus.py index ac1d8b36cf..7b09e30f33 100644 --- a/dev_tools/utils/nexus.py +++ b/dev_tools/utils/nexus.py @@ -19,9 +19,13 @@ class NxdlAttributeError(Exception): def get_app_defs_names(): """Returns all the AppDef names without their extension: .nxdl.xml""" - app_def_path_glob = f"{get_nexus_definitions_path()}{os.sep}applications{os.sep}*.nxdl*" - contrib_def_path_glob = (f"{get_nexus_definitions_path()}{os.sep}" - f"contributed_definitions{os.sep}*.nxdl*") + app_def_path_glob = ( + f"{get_nexus_definitions_path()}{os.sep}applications{os.sep}*.nxdl*" + ) + contrib_def_path_glob = ( + f"{get_nexus_definitions_path()}{os.sep}" + f"contributed_definitions{os.sep}*.nxdl*" + ) files = sorted(glob(app_def_path_glob)) + sorted(glob(contrib_def_path_glob)) return [os.path.basename(file).split(".")[0] for file in files] + ["NXroot"] @@ -35,9 +39,9 @@ def get_xml_root(file_path): def get_nexus_definitions_path(): """Check NEXUS_DEF_PATH variable. -If it is empty, this function is filling it""" + If it is empty, this function is filling it""" try: # either given by sys env - return os.environ['NEXUS_DEF_PATH'] + return os.environ["NEXUS_DEF_PATH"] except KeyError: # or it should be available locally under the dir 'definitions' local_dir = os.path.abspath(os.path.dirname(__file__)) return os.path.join(local_dir, f"..{os.sep}definitions") @@ -46,65 +50,82 @@ def get_nexus_definitions_path(): def get_hdf_root(hdf_node): """Get the root HDF5 node""" node = hdf_node - while node.name != '/': + while node.name != "/": node = node.parent return node def get_hdf_parent(hdf_info): """Get the parent of an hdf_node in an hdf_info""" - if 'hdf_path' not in hdf_info: - return hdf_info['hdf_node'].parent - node = get_hdf_root(hdf_info['hdf_node']) if 'hdf_root' not in hdf_info \ - else hdf_info['hdf_root'] - for child_name in hdf_info['hdf_path'].split('/'): + if "hdf_path" not in hdf_info: + return hdf_info["hdf_node"].parent + node = ( + get_hdf_root(hdf_info["hdf_node"]) + if "hdf_root" not in hdf_info + else hdf_info["hdf_root"] + ) + for child_name in hdf_info["hdf_path"].split("/"): node = node[child_name] return node def get_parent_path(hdf_name): """Get parent path""" - return '/'.join(hdf_name.split('/')[:-1]) + return "/".join(hdf_name.split("/")[:-1]) def get_hdf_info_parent(hdf_info): """Get the hdf_info for the parent of an hdf_node in an hdf_info""" - if 'hdf_path' not in hdf_info: - return {'hdf_node': hdf_info['hdf_node'].parent} - node = get_hdf_root(hdf_info['hdf_node']) if 'hdf_root' not in hdf_info \ - else hdf_info['hdf_root'] - for child_name in hdf_info['hdf_path'].split('/')[1:-1]: + if "hdf_path" not in hdf_info: + return {"hdf_node": hdf_info["hdf_node"].parent} + node = ( + get_hdf_root(hdf_info["hdf_node"]) + if "hdf_root" not in hdf_info + else hdf_info["hdf_root"] + ) + for child_name in hdf_info["hdf_path"].split("/")[1:-1]: node = node[child_name] - return {'hdf_node': node, 'hdf_path': get_parent_path(hdf_info['hdf_path'])} + return {"hdf_node": node, "hdf_path": get_parent_path(hdf_info["hdf_path"])} def get_nx_class_path(hdf_info): """Get the full path of an HDF5 node using nexus classes -in case of a field, end with the field name""" - hdf_node = hdf_info['hdf_node'] - if hdf_node.name == '/': - return '' + in case of a field, end with the field name""" + hdf_node = hdf_info["hdf_node"] + if hdf_node.name == "/": + return "" if isinstance(hdf_node, h5py.Group): - return get_nx_class_path(get_hdf_info_parent(hdf_info)) + '/' + \ - (hdf_node.attrs['NX_class'] if 'NX_class' in hdf_node.attrs.keys() else - hdf_node.name.split('/')[-1]) + return ( + get_nx_class_path(get_hdf_info_parent(hdf_info)) + + "/" + + ( + hdf_node.attrs["NX_class"] + if "NX_class" in hdf_node.attrs.keys() + else hdf_node.name.split("/")[-1] + ) + ) if isinstance(hdf_node, h5py.Dataset): - return get_nx_class_path( - get_hdf_info_parent(hdf_info)) + '/' + hdf_node.name.split('/')[-1] - return '' + return ( + get_nx_class_path(get_hdf_info_parent(hdf_info)) + + "/" + + hdf_node.name.split("/")[-1] + ) + return "" def get_nxdl_entry(hdf_info): """Get the nxdl application definition for an HDF5 node""" entry = hdf_info - while isinstance(entry['hdf_node'], h5py.Dataset) or \ - 'NX_class' not in entry['hdf_node'].attrs.keys() or \ - entry['hdf_node'].attrs['NX_class'] != 'NXentry': + while ( + isinstance(entry["hdf_node"], h5py.Dataset) + or "NX_class" not in entry["hdf_node"].attrs.keys() + or entry["hdf_node"].attrs["NX_class"] != "NXentry" + ): entry = get_hdf_info_parent(entry) - if entry['hdf_node'].name == '/': - return 'NO NXentry found' + if entry["hdf_node"].name == "/": + return "NO NXentry found" try: - nxdef = entry['hdf_node']['definition'][()] + nxdef = entry["hdf_node"]["definition"][()] return nxdef.decode() except KeyError: # 'NO Definition referenced' return "NXentry" @@ -112,27 +133,30 @@ def get_nxdl_entry(hdf_info): def get_nx_class(nxdl_elem): """Get the nexus class for a NXDL node""" - if 'category' in nxdl_elem.attrib.keys(): + if "category" in nxdl_elem.attrib.keys(): return None try: - return nxdl_elem.attrib['type'] + return nxdl_elem.attrib["type"] except KeyError: - return 'NX_CHAR' + return "NX_CHAR" def get_nx_namefit(hdf_name, name, name_any=False): """Checks if an HDF5 node name corresponds to a child of the NXDL element -uppercase letters in front can be replaced by arbitraty name, but -uppercase to lowercase match is preferred, -so such match is counted as a measure of the fit""" + uppercase letters in front can be replaced by arbitraty name, but + uppercase to lowercase match is preferred, + so such match is counted as a measure of the fit""" if name == hdf_name: return len(name) * 2 # count leading capitals counting = 0 while counting < len(name) and name[counting].upper() == name[counting]: counting += 1 - if name_any or counting == len(name) or \ - (counting > 0 and hdf_name.endswith(name[counting:])): # if potential fit + if ( + name_any + or counting == len(name) + or (counting > 0 and hdf_name.endswith(name[counting:])) + ): # if potential fit # count the matching chars fit = 0 for i in range(min(counting, len(hdf_name))): @@ -143,24 +167,31 @@ def get_nx_namefit(hdf_name, name, name_any=False): if fit == min(counting, len(hdf_name)): # accept only full fits as better fits return fit return 0 - return -1 # no fit + return -1 # no fit def get_nx_classes(): """Read base classes from the NeXus definition folder. -Check each file in base_classes, applications, contributed_definitions. -If its category attribute is 'base', then it is added to the list. """ - base_classes = sorted(glob(os.path.join(get_nexus_definitions_path(), - 'base_classes', '*.nxdl.xml'))) - applications = sorted(glob(os.path.join(get_nexus_definitions_path(), - 'applications', '*.nxdl.xml'))) - contributed = sorted(glob(os.path.join(get_nexus_definitions_path(), - 'contributed_definitions', '*.nxdl.xml'))) + Check each file in base_classes, applications, contributed_definitions. + If its category attribute is 'base', then it is added to the list.""" + base_classes = sorted( + glob(os.path.join(get_nexus_definitions_path(), "base_classes", "*.nxdl.xml")) + ) + applications = sorted( + glob(os.path.join(get_nexus_definitions_path(), "applications", "*.nxdl.xml")) + ) + contributed = sorted( + glob( + os.path.join( + get_nexus_definitions_path(), "contributed_definitions", "*.nxdl.xml" + ) + ) + ) nx_clss = [] for nexus_file in base_classes + applications + contributed: root = get_xml_root(nexus_file) - if root.attrib['category'] == 'base': - nx_clss.append(str(nexus_file[nexus_file.rindex(os.sep) + 1:])[:-9]) + if root.attrib["category"] == "base": + nx_clss.append(str(nexus_file[nexus_file.rindex(os.sep) + 1 :])[:-9]) nx_clss = sorted(nx_clss) return nx_clss @@ -175,12 +206,12 @@ def get_nx_units(): units_and_type_list.append(i) flag = False for line in units_and_type_list: - if line == 'anyUnitsAttr': + if line == "anyUnitsAttr": flag = True nx_units = [] - elif 'NX' in line and flag is True: + elif "NX" in line and flag is True: nx_units.append(line) - elif line == 'primitiveType': + elif line == "primitiveType": flag = False else: pass @@ -189,7 +220,7 @@ def get_nx_units(): def get_nx_attribute_type(): """Read attribute types from the NeXus definition/nxdlTypes.xsd file""" - filepath = get_nexus_definitions_path() + '/nxdlTypes.xsd' + filepath = get_nexus_definitions_path() + "/nxdlTypes.xsd" root = get_xml_root(filepath) units_and_type_list = [] for child in root: @@ -197,12 +228,12 @@ def get_nx_attribute_type(): units_and_type_list.append(i) flag = False for line in units_and_type_list: - if line == 'primitiveType': + if line == "primitiveType": flag = True nx_types = [] - elif 'NX' in line and flag is True: + elif "NX" in line and flag is True: nx_types.append(line) - elif line == 'anyUnitsAttr': + elif line == "anyUnitsAttr": flag = False else: pass @@ -210,23 +241,23 @@ def get_nx_attribute_type(): def get_node_name(node): - '''Node - xml node. Returns html documentation name. + """Node - xml node. Returns html documentation name. Either as specified by the 'name' or taken from the type (nx_class). Note that if only class name is available, the NX prefix is removed and - the string is converted to UPPER case.''' - if 'name' in node.attrib.keys(): - name = node.attrib['name'] + the string is converted to UPPER case.""" + if "name" in node.attrib.keys(): + name = node.attrib["name"] else: - name = node.attrib['type'] - if name.startswith('NX'): + name = node.attrib["type"] + if name.startswith("NX"): name = name[2:].upper() return name def belongs_to(nxdl_elem, child, name, class_type=None, hdf_name=None): """Checks if an HDF5 node name corresponds to a child of the NXDL element -uppercase letters in front can be replaced by arbitraty name, but -uppercase to lowercase match is preferred""" + uppercase letters in front can be replaced by arbitraty name, but + uppercase to lowercase match is preferred""" if class_type and get_nx_class(child) != class_type: return False act_htmlname = get_node_name(child) @@ -236,7 +267,7 @@ def belongs_to(nxdl_elem, child, name, class_type=None, hdf_name=None): if not hdf_name: # search for name fits is only allowed for hdf_nodes return False try: # check if nameType allows different name - name_any = bool(child.attrib['nameType'] == "any") + name_any = bool(child.attrib["nameType"] == "any") except KeyError: name_any = False params = [act_htmlname, chk_name, name_any, nxdl_elem, child, name] @@ -247,17 +278,25 @@ def belongs_to_capital(params): """Checking continues for Upper case""" (act_htmlname, chk_name, name_any, nxdl_elem, child, name) = params # or starts with capital and no reserved words used - if (name_any or 'A' <= act_htmlname[0] <= 'Z') and \ - name != 'doc' and name != 'enumeration': + if ( + (name_any or "A" <= act_htmlname[0] <= "Z") + and name != "doc" + and name != "enumeration" + ): fit = get_nx_namefit(chk_name, act_htmlname, name_any) # check if name fits if fit < 0: return False for child2 in nxdl_elem: - if get_local_name_from_xml(child) != \ - get_local_name_from_xml(child2) or get_node_name(child2) == act_htmlname: + if ( + get_local_name_from_xml(child) != get_local_name_from_xml(child2) + or get_node_name(child2) == act_htmlname + ): continue # check if the name of another sibling fits better - name_any2 = "nameType" in child2.attrib.keys() and child2.attrib["nameType"] == "any" + name_any2 = ( + "nameType" in child2.attrib.keys() + and child2.attrib["nameType"] == "any" + ) fit2 = get_nx_namefit(chk_name, get_node_name(child2), name_any2) if fit2 > fit: return False @@ -268,68 +307,81 @@ def belongs_to_capital(params): def get_local_name_from_xml(element): """Helper function to extract the element tag without the namespace.""" - return element.tag[element.tag.rindex("}") + 1:] + return element.tag[element.tag.rindex("}") + 1 :] def get_own_nxdl_child_reserved_elements(child, name, nxdl_elem): """checking reserved elements, like doc, enumeration""" - if get_local_name_from_xml(child) == 'doc' and name == 'doc': - if nxdl_elem.get('nxdlbase'): - child.set('nxdlbase', nxdl_elem.get('nxdlbase')) - child.set('nxdlbase_class', nxdl_elem.get('nxdlbase_class')) - child.set('nxdlpath', nxdl_elem.get('nxdlpath') + '/doc') + if get_local_name_from_xml(child) == "doc" and name == "doc": + if nxdl_elem.get("nxdlbase"): + child.set("nxdlbase", nxdl_elem.get("nxdlbase")) + child.set("nxdlbase_class", nxdl_elem.get("nxdlbase_class")) + child.set("nxdlpath", nxdl_elem.get("nxdlpath") + "/doc") return child - if get_local_name_from_xml(child) == 'enumeration' and name == 'enumeration': - if nxdl_elem.get('nxdlbase'): - child.set('nxdlbase', nxdl_elem.get('nxdlbase')) - child.set('nxdlbase_class', nxdl_elem.get('nxdlbase_class')) - child.set('nxdlpath', nxdl_elem.get('nxdlpath') + '/enumeration') + if get_local_name_from_xml(child) == "enumeration" and name == "enumeration": + if nxdl_elem.get("nxdlbase"): + child.set("nxdlbase", nxdl_elem.get("nxdlbase")) + child.set("nxdlbase_class", nxdl_elem.get("nxdlbase_class")) + child.set("nxdlpath", nxdl_elem.get("nxdlpath") + "/enumeration") return child return False def get_own_nxdl_child_base_types(child, class_type, nxdl_elem, name, hdf_name): """checking base types of group, field,m attribute""" - if get_local_name_from_xml(child) == 'group': - if (class_type is None or (class_type and get_nx_class(child) == class_type)) and \ - belongs_to(nxdl_elem, child, name, class_type, hdf_name): - if nxdl_elem.get('nxdlbase'): - child.set('nxdlbase', nxdl_elem.get('nxdlbase')) - child.set('nxdlbase_class', nxdl_elem.get('nxdlbase_class')) - child.set('nxdlpath', nxdl_elem.get('nxdlpath') + '/' + get_node_name(child)) + if get_local_name_from_xml(child) == "group": + if ( + class_type is None or (class_type and get_nx_class(child) == class_type) + ) and belongs_to(nxdl_elem, child, name, class_type, hdf_name): + if nxdl_elem.get("nxdlbase"): + child.set("nxdlbase", nxdl_elem.get("nxdlbase")) + child.set("nxdlbase_class", nxdl_elem.get("nxdlbase_class")) + child.set( + "nxdlpath", nxdl_elem.get("nxdlpath") + "/" + get_node_name(child) + ) return child - if get_local_name_from_xml(child) == 'field' and \ - belongs_to(nxdl_elem, child, name, None, hdf_name): - if nxdl_elem.get('nxdlbase'): - child.set('nxdlbase', nxdl_elem.get('nxdlbase')) - child.set('nxdlbase_class', nxdl_elem.get('nxdlbase_class')) - child.set('nxdlpath', nxdl_elem.get('nxdlpath') + '/' + get_node_name(child)) + if get_local_name_from_xml(child) == "field" and belongs_to( + nxdl_elem, child, name, None, hdf_name + ): + if nxdl_elem.get("nxdlbase"): + child.set("nxdlbase", nxdl_elem.get("nxdlbase")) + child.set("nxdlbase_class", nxdl_elem.get("nxdlbase_class")) + child.set( + "nxdlpath", nxdl_elem.get("nxdlpath") + "/" + get_node_name(child) + ) return child - if get_local_name_from_xml(child) == 'attribute' and \ - belongs_to(nxdl_elem, child, name, None, hdf_name): - if nxdl_elem.get('nxdlbase'): - child.set('nxdlbase', nxdl_elem.get('nxdlbase')) - child.set('nxdlbase_class', nxdl_elem.get('nxdlbase_class')) - child.set('nxdlpath', nxdl_elem.get('nxdlpath') + '/' + get_node_name(child)) + if get_local_name_from_xml(child) == "attribute" and belongs_to( + nxdl_elem, child, name, None, hdf_name + ): + if nxdl_elem.get("nxdlbase"): + child.set("nxdlbase", nxdl_elem.get("nxdlbase")) + child.set("nxdlbase_class", nxdl_elem.get("nxdlbase_class")) + child.set( + "nxdlpath", nxdl_elem.get("nxdlpath") + "/" + get_node_name(child) + ) return child return False -def get_own_nxdl_child(nxdl_elem, name, class_type=None, hdf_name=None, nexus_type=None): +def get_own_nxdl_child( + nxdl_elem, name, class_type=None, hdf_name=None, nexus_type=None +): """Checks if an NXDL child node fits to the specific name (either nxdl or hdf) - name - nxdl name - class_type - nxdl type or hdf classname (for groups, it is obligatory) - hdf_name - hdf name""" + name - nxdl name + class_type - nxdl type or hdf classname (for groups, it is obligatory) + hdf_name - hdf name""" for child in nxdl_elem: - if 'name' in child.attrib and child.attrib['name'] == name: - if nxdl_elem.get('nxdlbase'): - child.set('nxdlbase', nxdl_elem.get('nxdlbase')) - child.set('nxdlbase_class', nxdl_elem.get('nxdlbase_class')) - child.set('nxdlpath', nxdl_elem.get('nxdlpath') + '/' + get_node_name(child)) + if "name" in child.attrib and child.attrib["name"] == name: + if nxdl_elem.get("nxdlbase"): + child.set("nxdlbase", nxdl_elem.get("nxdlbase")) + child.set("nxdlbase_class", nxdl_elem.get("nxdlbase_class")) + child.set( + "nxdlpath", nxdl_elem.get("nxdlpath") + "/" + get_node_name(child) + ) return child for child in nxdl_elem: if "name" in child.attrib and child.attrib["name"] == name: - child.set('nxdlbase', nxdl_elem.get('nxdlbase')) + child.set("nxdlbase", nxdl_elem.get("nxdlbase")) return child for child in nxdl_elem: @@ -338,7 +390,9 @@ def get_own_nxdl_child(nxdl_elem, name, class_type=None, hdf_name=None, nexus_ty return result if nexus_type and get_local_name_from_xml(child) != nexus_type: continue - result = get_own_nxdl_child_base_types(child, class_type, nxdl_elem, name, hdf_name) + result = get_own_nxdl_child_base_types( + child, class_type, nxdl_elem, name, hdf_name + ) if result is not False: return result return None @@ -346,21 +400,28 @@ def get_own_nxdl_child(nxdl_elem, name, class_type=None, hdf_name=None, nexus_ty def find_definition_file(bc_name): """find the nxdl file corresponding to the name. - Note that it first checks in contributed and goes beyond only if no contributed found""" + Note that it first checks in contributed and goes beyond only if no contributed found + """ bc_filename = None - for nxdl_folder in ['contributed_definitions', 'base_classes', 'applications']: - if os.path.exists(f"{get_nexus_definitions_path()}{os.sep}" - f"{nxdl_folder}{os.sep}{bc_name}.nxdl.xml"): - bc_filename = f"{get_nexus_definitions_path()}{os.sep}" \ - f"{nxdl_folder}{os.sep}{bc_name}.nxdl.xml" + for nxdl_folder in ["contributed_definitions", "base_classes", "applications"]: + if os.path.exists( + f"{get_nexus_definitions_path()}{os.sep}" + f"{nxdl_folder}{os.sep}{bc_name}.nxdl.xml" + ): + bc_filename = ( + f"{get_nexus_definitions_path()}{os.sep}" + f"{nxdl_folder}{os.sep}{bc_name}.nxdl.xml" + ) break return bc_filename -def get_nxdl_child(nxdl_elem, name, class_type=None, hdf_name=None, nexus_type=None, go_base=True): # pylint: disable=too-many-arguments +def get_nxdl_child( + nxdl_elem, name, class_type=None, hdf_name=None, nexus_type=None, go_base=True +): # pylint: disable=too-many-arguments """Get the NXDL child node corresponding to a specific name -(e.g. of an HDF5 node,or of a documentation) note that if child is not found in application -definition, it also checks for the base classes""" + (e.g. of an HDF5 node,or of a documentation) note that if child is not found in application + definition, it also checks for the base classes""" # search for possible fits for hdf_nodes : skipped # only exact hits are returned when searching an nxdl child own_child = get_own_nxdl_child(nxdl_elem, name, class_type, hdf_name, nexus_type) @@ -369,18 +430,20 @@ def get_nxdl_child(nxdl_elem, name, class_type=None, hdf_name=None, nexus_type=N if not go_base: return None bc_name = get_nx_class(nxdl_elem) # check in the base class, app def or contributed - if bc_name[2] == '_': # filter primitive types + if bc_name[2] == "_": # filter primitive types return None - if bc_name == "group": # Check if it is the root element. Then send to NXroot.nxdl.xml + if ( + bc_name == "group" + ): # Check if it is the root element. Then send to NXroot.nxdl.xml bc_name = "NXroot" bc_filename = find_definition_file(bc_name) if not bc_filename: - raise ValueError('nxdl file not found in definitions folder!') + raise ValueError("nxdl file not found in definitions folder!") bc_obj = ET.parse(bc_filename).getroot() - bc_obj.set('nxdlbase', bc_filename) - if 'category' in bc_obj.attrib: - bc_obj.set('nxdlbase_class', bc_obj.attrib['category']) - bc_obj.set('nxdlpath', '') + bc_obj.set("nxdlbase", bc_filename) + if "category" in bc_obj.attrib: + bc_obj.set("nxdlbase_class", bc_obj.attrib["category"]) + bc_obj.set("nxdlpath", "") return get_own_nxdl_child(bc_obj, name, class_type, hdf_name, nexus_type) @@ -388,12 +451,16 @@ def get_required_string(nxdl_elem): """Check for being REQUIRED, RECOMMENDED, OPTIONAL, NOT IN SCHEMA""" if nxdl_elem is None: return "<>" - is_optional = 'optional' in nxdl_elem.attrib.keys() \ - and nxdl_elem.attrib['optional'] == "true" - is_minoccurs = 'minOccurs' in nxdl_elem.attrib.keys() \ - and nxdl_elem.attrib['minOccurs'] == "0" - is_recommended = 'recommended' in nxdl_elem.attrib.keys() \ - and nxdl_elem.attrib['recommended'] == "true" + is_optional = ( + "optional" in nxdl_elem.attrib.keys() and nxdl_elem.attrib["optional"] == "true" + ) + is_minoccurs = ( + "minOccurs" in nxdl_elem.attrib.keys() and nxdl_elem.attrib["minOccurs"] == "0" + ) + is_recommended = ( + "recommended" in nxdl_elem.attrib.keys() + and nxdl_elem.attrib["recommended"] == "true" + ) if is_recommended: return "<>" @@ -401,7 +468,7 @@ def get_required_string(nxdl_elem): return "<>" # default optionality: in BASE CLASSES is true; in APPLICATIONS is false try: - if nxdl_elem.get('nxdlbase_class') == 'base': + if nxdl_elem.get("nxdlbase_class") == "base": return "<>" except TypeError: return "<>" @@ -410,40 +477,44 @@ def get_required_string(nxdl_elem): def chk_nxdataaxis_v2(hdf_node, name, logger): """Check if dataset is an axis""" - own_signal = hdf_node.attrs.get('signal') # check for being a Signal + own_signal = hdf_node.attrs.get("signal") # check for being a Signal if own_signal is str and own_signal == "1": logger.debug("Dataset referenced (v2) as NXdata SIGNAL") - own_axes = hdf_node.attrs.get('axes') # check for being an axis + own_axes = hdf_node.attrs.get("axes") # check for being an axis if own_axes is str: - axes = own_axes.split(':') + axes = own_axes.split(":") for i in len(axes): if axes[i] and name == axes[i]: logger.debug("Dataset referenced (v2) as NXdata AXIS #%d", i) return None - ownpaxis = hdf_node.attrs.get('primary') - own_axis = hdf_node.attrs.get('axis') + ownpaxis = hdf_node.attrs.get("primary") + own_axis = hdf_node.attrs.get("axis") if own_axis is int: # also convention v1 if ownpaxis is int and ownpaxis == 1: logger.debug("Dataset referenced (v2) as NXdata AXIS #%d", own_axis - 1) else: logger.debug( - "Dataset referenced (v2) as NXdata (primary/alternative) AXIS #%d", own_axis - 1) + "Dataset referenced (v2) as NXdata (primary/alternative) AXIS #%d", + own_axis - 1, + ) return None def chk_nxdataaxis(hdf_node, name, logger): """NEXUS Data Plotting Standard v3: new version from 2014""" - if not isinstance(hdf_node, h5py.Dataset): # check if it is a field in an NXdata node + if not isinstance( + hdf_node, h5py.Dataset + ): # check if it is a field in an NXdata node return None parent = hdf_node.parent - if not parent or (parent and not parent.attrs.get('NX_class') == "NXdata"): + if not parent or (parent and not parent.attrs.get("NX_class") == "NXdata"): return None - signal = parent.attrs.get('signal') # chk for Signal + signal = parent.attrs.get("signal") # chk for Signal if signal and name == signal: logger.debug("Dataset referenced as NXdata SIGNAL") return None - axes = parent.attrs.get('axes') # check for default Axes + axes = parent.attrs.get("axes") # check for default Axes if axes is str: if name == axes: logger.debug("Dataset referenced as NXdata AXIS") @@ -451,13 +522,13 @@ def chk_nxdataaxis(hdf_node, name, logger): elif axes is not None: for i, j in enumerate(axes): if name == j: - indices = parent.attrs.get(j + '_indices') + indices = parent.attrs.get(j + "_indices") if indices is int: logger.debug(f"Dataset referenced as NXdata AXIS #{indices}") else: logger.debug(f"Dataset referenced as NXdata AXIS #{i}") return None - indices = parent.attrs.get(name + '_indices') # check for alternative Axes + indices = parent.attrs.get(name + "_indices") # check for alternative Axes if indices is int: logger.debug(f"Dataset referenced as NXdata alternative AXIS #{indices}") return chk_nxdataaxis_v2(hdf_node, name, logger) # check for older conventions @@ -467,7 +538,7 @@ def chk_nxdataaxis(hdf_node, name, logger): def write_doc_string(logger, doc, attr): """Simple function that prints a line in the logger if doc exists""" if doc: - logger.debug("@" + attr + ' [NX_CHAR]') + logger.debug("@" + attr + " [NX_CHAR]") return logger, doc, attr @@ -477,61 +548,96 @@ def try_find_units(logger, elem, nxdl_path, doc, attr): try: # try to find if units is defined inside the field in the NXDL element unit = elem.attrib[attr] if doc: - logger.debug(get_node_concept_path(elem) + "@" + attr + ' [' + unit + ']') + logger.debug(get_node_concept_path(elem) + "@" + attr + " [" + unit + "]") elem = None nxdl_path.append(attr) - except KeyError: # otherwise try to find if units is defined as a child of the NXDL element + except ( + KeyError + ): # otherwise try to find if units is defined as a child of the NXDL element orig_elem = elem - elem = get_nxdl_child(elem, attr, nexus_type='attribute') + elem = get_nxdl_child(elem, attr, nexus_type="attribute") if elem is not None: if doc: - logger.debug(get_node_concept_path(orig_elem) - + "@" + attr + ' - [' + get_nx_class(elem) + ']') + logger.debug( + get_node_concept_path(orig_elem) + + "@" + + attr + + " - [" + + get_nx_class(elem) + + "]" + ) nxdl_path.append(elem) else: # if no units category were defined in NXDL: if doc: - logger.debug(get_node_concept_path(orig_elem) - + "@" + attr + " - REQUIRED, but undefined unit category") + logger.debug( + get_node_concept_path(orig_elem) + + "@" + + attr + + " - REQUIRED, but undefined unit category" + ) nxdl_path.append(attr) return logger, elem, nxdl_path, doc, attr def check_attr_name_nxdl(param): """Check for ATTRIBUTENAME_units in NXDL (normal). -If not defined, check for ATTRIBUTENAME to see if the ATTRIBUTE -is in the SCHEMA, but no units category were defined. """ + If not defined, check for ATTRIBUTENAME to see if the ATTRIBUTE + is in the SCHEMA, but no units category were defined.""" (logger, elem, nxdl_path, doc, attr, req_str) = param orig_elem = elem - elem2 = get_nxdl_child(elem, attr, nexus_type='attribute') + elem2 = get_nxdl_child(elem, attr, nexus_type="attribute") if elem2 is not None: # check for ATTRIBUTENAME_units in NXDL (normal) elem = elem2 if doc: - logger.debug(get_node_concept_path(orig_elem) - + "@" + attr + ' - [' + get_nx_class(elem) + ']') + logger.debug( + get_node_concept_path(orig_elem) + + "@" + + attr + + " - [" + + get_nx_class(elem) + + "]" + ) nxdl_path.append(elem) else: # if not defined, check for ATTRIBUTENAME to see if the ATTRIBUTE # is in the SCHEMA, but no units category were defined - elem2 = get_nxdl_child(elem, attr[:-6], nexus_type='attribute') + elem2 = get_nxdl_child(elem, attr[:-6], nexus_type="attribute") if elem2 is not None: - req_str = '<>' + req_str = "<>" if doc: - logger.debug(get_node_concept_path(orig_elem) - + "@" + attr + " - RECOMMENDED, but undefined unit category") + logger.debug( + get_node_concept_path(orig_elem) + + "@" + + attr + + " - RECOMMENDED, but undefined unit category" + ) nxdl_path.append(attr) else: # otherwise: NOT IN SCHEMA elem = elem2 if doc: - logger.debug(get_node_concept_path(orig_elem) + "@" + attr + " - IS NOT IN SCHEMA") + logger.debug( + get_node_concept_path(orig_elem) + + "@" + + attr + + " - IS NOT IN SCHEMA" + ) return logger, elem, nxdl_path, doc, attr, req_str -def try_find_default(logger, orig_elem, elem, nxdl_path, doc, attr): # pylint: disable=too-many-arguments - """Try to find if default is defined as a child of the NXDL element """ +def try_find_default( + logger, orig_elem, elem, nxdl_path, doc, attr +): # pylint: disable=too-many-arguments + """Try to find if default is defined as a child of the NXDL element""" if elem is not None: if doc: - logger.debug(get_node_concept_path(orig_elem) - + "@" + attr + ' - [' + get_nx_class(elem) + ']') + logger.debug( + get_node_concept_path(orig_elem) + + "@" + + attr + + " - [" + + get_nx_class(elem) + + "]" + ) nxdl_path.append(elem) else: # if no default category were defined in NXDL: if doc: @@ -540,38 +646,50 @@ def try_find_default(logger, orig_elem, elem, nxdl_path, doc, attr): # pylint: return logger, elem, nxdl_path, doc, attr -def other_attrs(logger, orig_elem, elem, nxdl_path, doc, attr): # pylint: disable=too-many-arguments - """Handle remaining attributes """ +def other_attrs( + logger, orig_elem, elem, nxdl_path, doc, attr +): # pylint: disable=too-many-arguments + """Handle remaining attributes""" if elem is not None: if doc: - logger.debug(get_node_concept_path(orig_elem) - + "@" + attr + ' - [' + get_nx_class(elem) + ']') + logger.debug( + get_node_concept_path(orig_elem) + + "@" + + attr + + " - [" + + get_nx_class(elem) + + "]" + ) nxdl_path.append(elem) else: if doc: - logger.debug(get_node_concept_path(orig_elem) + "@" + attr + " - IS NOT IN SCHEMA") + logger.debug( + get_node_concept_path(orig_elem) + "@" + attr + " - IS NOT IN SCHEMA" + ) return logger, elem, nxdl_path, doc, attr def check_deprecation_enum_axis(variables, doc, elist, attr, hdf_node): - """Check for several attributes. - deprecation - enums - nxdataaxis """ + """Check for several attributes. - deprecation - enums - nxdataaxis""" logger, elem, path = variables - dep_str = elem.attrib.get('deprecated') # check for deprecation + dep_str = elem.attrib.get("deprecated") # check for deprecation if dep_str: if doc: logger.debug("DEPRECATED - " + dep_str) for base_elem in elist if not attr else [elem]: # check for enums - sdoc = get_nxdl_child(base_elem, 'enumeration', go_base=False) + sdoc = get_nxdl_child(base_elem, "enumeration", go_base=False) if sdoc is not None: if doc: logger.debug("enumeration (" + get_node_concept_path(base_elem) + "):") for item in sdoc: - if get_local_name_from_xml(item) == 'item': + if get_local_name_from_xml(item) == "item": if doc: - logger.debug("-> " + item.attrib['value']) - chk_nxdataaxis(hdf_node, path.split('/')[-1], logger) # look for NXdata reference (axes/signal) + logger.debug("-> " + item.attrib["value"]) + chk_nxdataaxis( + hdf_node, path.split("/")[-1], logger + ) # look for NXdata reference (axes/signal) for base_elem in elist if not attr else [elem]: # check for doc - sdoc = get_nxdl_child(base_elem, 'doc', go_base=False) + sdoc = get_nxdl_child(base_elem, "doc", go_base=False) if doc: logger.debug("documentation (" + get_node_concept_path(base_elem) + "):") logger.debug(sdoc.text if sdoc is not None else "") @@ -580,11 +698,12 @@ def check_deprecation_enum_axis(variables, doc, elist, attr, hdf_node): def get_node_concept_path(elem): """get the short version of nxdlbase:nxdlpath""" - return str(elem.get('nxdlbase').split('/')[-1] + ":" + elem.get('nxdlpath')) + return str(elem.get("nxdlbase").split("/")[-1] + ":" + elem.get("nxdlpath")) def get_nxdl_attr_doc( # pylint: disable=too-many-arguments,too-many-locals - elem, elist, attr, hdf_node, logger, doc, nxdl_path, req_str, path, hdf_info): + elem, elist, attr, hdf_node, logger, doc, nxdl_path, req_str, path, hdf_info +): """Get nxdl documentation for an attribute""" new_elem = [] old_elem = elem @@ -592,43 +711,44 @@ def get_nxdl_attr_doc( # pylint: disable=too-many-arguments,too-many-locals act_elem = act_elem1 # NX_class is a compulsory attribute for groups in a nexus file # which should match the type of the corresponding NXDL element - if attr == 'NX_class' and not isinstance(hdf_node, h5py.Dataset) and elem_index == 0: + if ( + attr == "NX_class" + and not isinstance(hdf_node, h5py.Dataset) + and elem_index == 0 + ): elem = None logger, doc, attr = write_doc_string(logger, doc, attr) new_elem = elem break # units category is a compulsory attribute for any fields - if attr == 'units' and isinstance(hdf_node, h5py.Dataset): + if attr == "units" and isinstance(hdf_node, h5py.Dataset): req_str = "<>" - logger, act_elem, nxdl_path, doc, attr = try_find_units(logger, - act_elem, - nxdl_path, - doc, - attr) + logger, act_elem, nxdl_path, doc, attr = try_find_units( + logger, act_elem, nxdl_path, doc, attr + ) # units for attributes can be given as ATTRIBUTENAME_units - elif attr.endswith('_units'): - logger, act_elem, nxdl_path, doc, attr, req_str = check_attr_name_nxdl((logger, - act_elem, - nxdl_path, - doc, - attr, - req_str)) + elif attr.endswith("_units"): + logger, act_elem, nxdl_path, doc, attr, req_str = check_attr_name_nxdl( + (logger, act_elem, nxdl_path, doc, attr, req_str) + ) # default is allowed for groups - elif attr == 'default' and not isinstance(hdf_node, h5py.Dataset): + elif attr == "default" and not isinstance(hdf_node, h5py.Dataset): req_str = "<>" # try to find if default is defined as a child of the NXDL element - act_elem = get_nxdl_child(act_elem, attr, nexus_type='attribute', go_base=False) - logger, act_elem, nxdl_path, doc, attr = try_find_default(logger, - act_elem1, - act_elem, - nxdl_path, - doc, - attr) + act_elem = get_nxdl_child( + act_elem, attr, nexus_type="attribute", go_base=False + ) + logger, act_elem, nxdl_path, doc, attr = try_find_default( + logger, act_elem1, act_elem, nxdl_path, doc, attr + ) else: # other attributes - act_elem = get_nxdl_child(act_elem, attr, nexus_type='attribute', go_base=False) + act_elem = get_nxdl_child( + act_elem, attr, nexus_type="attribute", go_base=False + ) if act_elem is not None: - logger, act_elem, nxdl_path, doc, attr = \ - other_attrs(logger, act_elem1, act_elem, nxdl_path, doc, attr) + logger, act_elem, nxdl_path, doc, attr = other_attrs( + logger, act_elem1, act_elem, nxdl_path, doc, attr + ) if act_elem is not None: new_elem.append(act_elem) if req_str is None: @@ -636,14 +756,18 @@ def get_nxdl_attr_doc( # pylint: disable=too-many-arguments,too-many-locals if doc: logger.debug(req_str) variables = [logger, act_elem, path] - logger, elem, path, doc, elist, attr, hdf_node = check_deprecation_enum_axis(variables, - doc, - elist, - attr, - hdf_node) + ( + logger, + elem, + path, + doc, + elist, + attr, + hdf_node, + ) = check_deprecation_enum_axis(variables, doc, elist, attr, hdf_node) elem = old_elem if req_str is None and doc: - if attr != 'NX_class': + if attr != "NX_class": logger.debug("@" + attr + " - IS NOT IN SCHEMA") logger.debug("") return (req_str, get_nxdl_entry(hdf_info), nxdl_path) @@ -651,48 +775,54 @@ def get_nxdl_attr_doc( # pylint: disable=too-many-arguments,too-many-locals def get_nxdl_doc(hdf_info, logger, doc, attr=False): """Get nxdl documentation for an HDF5 node (or its attribute)""" - hdf_node = hdf_info['hdf_node'] + hdf_node = hdf_info["hdf_node"] # new way: retrieve multiple inherited base classes - (class_path, nxdl_path, elist) = \ - get_inherited_nodes(None, nx_name=get_nxdl_entry(hdf_info), hdf_node=hdf_node, - hdf_path=hdf_info['hdf_path'] if 'hdf_path' in hdf_info else None, - hdf_root=hdf_info['hdf_root'] if 'hdf_root' in hdf_info else None) + (class_path, nxdl_path, elist) = get_inherited_nodes( + None, + nx_name=get_nxdl_entry(hdf_info), + hdf_node=hdf_node, + hdf_path=hdf_info["hdf_path"] if "hdf_path" in hdf_info else None, + hdf_root=hdf_info["hdf_root"] if "hdf_root" in hdf_info else None, + ) elem = elist[0] if class_path and elist else None if doc: logger.debug("classpath: " + str(class_path)) - logger.debug("NOT IN SCHEMA" if elem is None else - "classes:\n" + "\n".join - (get_node_concept_path(e) for e in elist)) + logger.debug( + "NOT IN SCHEMA" + if elem is None + else "classes:\n" + "\n".join(get_node_concept_path(e) for e in elist) + ) # old solution with a single elem instead of using elist path = get_nx_class_path(hdf_info) req_str = None if elem is None: if doc: logger.debug("") - return ('None', None, None) + return ("None", None, None) if attr: - return get_nxdl_attr_doc(elem, elist, attr, hdf_node, logger, doc, nxdl_path, - req_str, path, hdf_info) + return get_nxdl_attr_doc( + elem, elist, attr, hdf_node, logger, doc, nxdl_path, req_str, path, hdf_info + ) req_str = get_required_string(elem) # check for being required if doc: logger.debug(req_str) variables = [logger, elem, path] - logger, elem, path, doc, elist, attr, hdf_node = check_deprecation_enum_axis(variables, - doc, - elist, - attr, - hdf_node) + logger, elem, path, doc, elist, attr, hdf_node = check_deprecation_enum_axis( + variables, doc, elist, attr, hdf_node + ) return (req_str, get_nxdl_entry(hdf_info), nxdl_path) def get_doc(node, ntype, nxhtml, nxpath): """Get documentation""" # URL for html documentation - anchor = '' + anchor = "" for n_item in nxpath: anchor += n_item.lower() + "-" - anchor = ('https://manual.nexusformat.org/classes/', - nxhtml + "#" + anchor.replace('_', '-') + ntype) + anchor = ( + "https://manual.nexusformat.org/classes/", + nxhtml + "#" + anchor.replace("_", "-") + ntype, + ) if not ntype: anchor = anchor[:-1] doc = "" # RST documentation from the field 'doc' @@ -701,9 +831,13 @@ def get_doc(node, ntype, nxhtml, nxpath): doc = doc_field.text (index, enums) = get_enums(node) # enums if index: - enum_str = "\n " + ("Possible values:" - if len(enums.split(',')) > 1 - else "Obligatory value:") + "\n " + enums + "\n" + enum_str = ( + "\n " + + ("Possible values:" if len(enums.split(",")) > 1 else "Obligatory value:") + + "\n " + + enums + + "\n" + ) else: enum_str = "" return anchor, doc + enum_str @@ -714,17 +848,21 @@ def print_doc(node, ntype, level, nxhtml, nxpath): anchor, doc = get_doc(node, ntype, nxhtml, nxpath) print(" " * (level + 1) + anchor) preferred_width = 80 + level * 2 - wrapper = textwrap.TextWrapper(initial_indent=' ' * (level + 1), width=preferred_width, - subsequent_indent=' ' * (level + 1), expand_tabs=False, - tabsize=0) + wrapper = textwrap.TextWrapper( + initial_indent=" " * (level + 1), + width=preferred_width, + subsequent_indent=" " * (level + 1), + expand_tabs=False, + tabsize=0, + ) if doc is not None: - for par in doc.split('\n'): + for par in doc.split("\n"): print(wrapper.fill(par)) def get_namespace(element): """Extracts the namespace for elements in the NXDL""" - return element.tag[element.tag.index("{"):element.tag.rindex("}") + 1] + return element.tag[element.tag.index("{") : element.tag.rindex("}") + 1] def get_enums(node): @@ -737,15 +875,16 @@ def get_enums(node): for enumeration in node.findall(f"{namespace}enumeration"): for item in enumeration.findall(f"{namespace}item"): enums.append(item.attrib["value"]) - enums = ','.join(enums) + enums = ",".join(enums) if enums != "": - return (True, '[' + enums + ']') + return (True, "[" + enums + "]") return (False, "") # if there is no enumeration tag, returns empty string def add_base_classes(elist, nx_name=None, elem: ET.Element = None): """Add the base classes corresponding to the last eleme in elist to the list. Note that if -elist is empty, a nxdl file with the name of nx_name or a rather room elem is used if provided""" + elist is empty, a nxdl file with the name of nx_name or a rather room elem is used if provided + """ if elist and nx_name is None: nx_name = get_nx_class(elist[-1]) # to support recursive defintions, like NXsample in NXsample, the following test is removed @@ -758,48 +897,51 @@ def add_base_classes(elist, nx_name=None, elem: ET.Element = None): if nxdl_file_path is None: nxdl_file_path = f"{nx_name}.nxdl.xml" elem = ET.parse(nxdl_file_path).getroot() - elem.set('nxdlbase', nxdl_file_path) + elem.set("nxdlbase", nxdl_file_path) else: - elem.set('nxdlbase', '') - if 'category' in elem.attrib: - elem.set('nxdlbase_class', elem.attrib['category']) - elem.set('nxdlpath', '') + elem.set("nxdlbase", "") + if "category" in elem.attrib: + elem.set("nxdlbase_class", elem.attrib["category"]) + elem.set("nxdlpath", "") elist.append(elem) # add inherited base class - if 'extends' in elem.attrib and elem.attrib['extends'] != 'NXobject': - add_base_classes(elist, elem.attrib['extends']) + if "extends" in elem.attrib and elem.attrib["extends"] != "NXobject": + add_base_classes(elist, elem.attrib["extends"]) else: add_base_classes(elist) def set_nxdlpath(child, nxdl_elem): """ - Setting up child nxdlbase, nxdlpath and nxdlbase_class from nxdl_element. + Setting up child nxdlbase, nxdlpath and nxdlbase_class from nxdl_element. """ - if nxdl_elem.get('nxdlbase'): - child.set('nxdlbase', nxdl_elem.get('nxdlbase')) - child.set('nxdlbase_class', nxdl_elem.get('nxdlbase_class')) - child.set('nxdlpath', nxdl_elem.get('nxdlpath') + '/' + get_node_name(child)) + if nxdl_elem.get("nxdlbase"): + child.set("nxdlbase", nxdl_elem.get("nxdlbase")) + child.set("nxdlbase_class", nxdl_elem.get("nxdlbase_class")) + child.set("nxdlpath", nxdl_elem.get("nxdlpath") + "/" + get_node_name(child)) return child def get_direct_child(nxdl_elem, html_name): - """ returns the child of nxdl_elem which has a name - corresponding to the the html documentation name html_name""" + """returns the child of nxdl_elem which has a name + corresponding to the the html documentation name html_name""" for child in nxdl_elem: - if get_local_name_from_xml(child) in ('group', 'field', 'attribute') and \ - html_name == get_node_name(child): + if get_local_name_from_xml(child) in ( + "group", + "field", + "attribute", + ) and html_name == get_node_name(child): decorated_child = set_nxdlpath(child, nxdl_elem) return decorated_child return None def get_field_child(nxdl_elem, html_name): - """ returns the child of nxdl_elem which has a name - corresponding to the html documentation name html_name""" + """returns the child of nxdl_elem which has a name + corresponding to the html documentation name html_name""" data_child = None for child in nxdl_elem: - if get_local_name_from_xml(child) != 'field': + if get_local_name_from_xml(child) != "field": continue if get_node_name(child) == html_name: data_child = set_nxdlpath(child, nxdl_elem) @@ -808,27 +950,27 @@ def get_field_child(nxdl_elem, html_name): def get_best_nxdata_child(nxdl_elem, hdf_node, hdf_name): - """ returns the child of an NXdata nxdl_elem which has a name - corresponding to the hdf_name""" + """returns the child of an NXdata nxdl_elem which has a name + corresponding to the hdf_name""" nxdata = hdf_node.parent signals = [] - if 'signal' in nxdata.attrs.keys(): + if "signal" in nxdata.attrs.keys(): signals.append(nxdata.attrs.get("signal")) if "auxiliary_signals" in nxdata.attrs.keys(): for aux_signal in nxdata.attrs.get("auxiliary_signals"): signals.append(aux_signal) - data_child = get_field_child(nxdl_elem, 'DATA') - data_error_child = get_field_child(nxdl_elem, 'FIELDNAME_errors') + data_child = get_field_child(nxdl_elem, "DATA") + data_error_child = get_field_child(nxdl_elem, "FIELDNAME_errors") for signal in signals: if signal == hdf_name: return (data_child, 100) - if hdf_name.endswith('_errors') and signal == hdf_name[:-7]: + if hdf_name.endswith("_errors") and signal == hdf_name[:-7]: return (data_error_child, 100) axes = [] if "axes" in nxdata.attrs.keys(): for axis in nxdata.attrs.get("axes"): axes.append(axis) - axis_child = get_field_child(nxdl_elem, 'AXISNAME') + axis_child = get_field_child(nxdl_elem, "AXISNAME") for axis in axes: if axis == hdf_name: return (axis_child, 100) @@ -836,22 +978,29 @@ def get_best_nxdata_child(nxdl_elem, hdf_node, hdf_name): def get_best_child(nxdl_elem, hdf_node, hdf_name, hdf_class_name, nexus_type): - """ returns the child of nxdl_elem which has a name - corresponding to the the html documentation name html_name""" + """returns the child of nxdl_elem which has a name + corresponding to the the html documentation name html_name""" bestfit = -1 bestchild = None - if 'name' in nxdl_elem.attrib.keys() and nxdl_elem.attrib['name'] == 'NXdata' and \ - hdf_node is not None and hdf_node.parent is not None and \ - hdf_node.parent.attrs.get('NX_class') == 'NXdata': + if ( + "name" in nxdl_elem.attrib.keys() + and nxdl_elem.attrib["name"] == "NXdata" + and hdf_node is not None + and hdf_node.parent is not None + and hdf_node.parent.attrs.get("NX_class") == "NXdata" + ): (fnd_child, fit) = get_best_nxdata_child(nxdl_elem, hdf_node, hdf_name) if fnd_child is not None: return (fnd_child, fit) for child in nxdl_elem: fit = -2 - if get_local_name_from_xml(child) == nexus_type and \ - (nexus_type != 'group' or get_nx_class(child) == hdf_class_name): - name_any = "nameType" in nxdl_elem.attrib.keys() and \ - nxdl_elem.attrib["nameType"] == "any" + if get_local_name_from_xml(child) == nexus_type and ( + nexus_type != "group" or get_nx_class(child) == hdf_class_name + ): + name_any = ( + "nameType" in nxdl_elem.attrib.keys() + and nxdl_elem.attrib["nameType"] == "any" + ) fit = get_nx_namefit(hdf_name, get_node_name(child), name_any) if fit > bestfit: bestfit = fit @@ -869,9 +1018,13 @@ def walk_elist(elist, html_name): for potential_direct_parent in elist: main_child = get_direct_child(potential_direct_parent, html_name) if main_child is not None: - (fitting_child, _) = get_best_child(elist[ind], None, html_name, - get_nx_class(main_child), - get_local_name_from_xml(main_child)) + (fitting_child, _) = get_best_child( + elist[ind], + None, + html_name, + get_nx_class(main_child), + get_local_name_from_xml(main_child), + ) if fitting_child is not None: child = fitting_child break @@ -880,10 +1033,12 @@ def walk_elist(elist, html_name): del elist[ind] continue # override: remove low priority inheritance classes if class_type is overriden - if len(elist) > ind + 1 and get_nx_class(elist[ind]) != get_nx_class(elist[ind + 1]): - del elist[ind + 1:] + if len(elist) > ind + 1 and get_nx_class(elist[ind]) != get_nx_class( + elist[ind + 1] + ): + del elist[ind + 1 :] # add new base class(es) if new element brings such (and not a primitive type) - if len(elist) == ind + 1 and get_nx_class(elist[ind])[0:3] != 'NX_': + if len(elist) == ind + 1 and get_nx_class(elist[ind])[0:3] != "NX_": add_base_classes(elist) return elist, html_name @@ -894,20 +1049,18 @@ def helper_get_inherited_nodes(hdf_info2, elist, pind, attr): hdf_name = hdf_path[pind] hdf_class_name = hdf_class_path[pind] if pind < len(hdf_path) - (2 if attr else 1): - act_nexus_type = 'group' + act_nexus_type = "group" elif pind == len(hdf_path) - 1 and attr: - act_nexus_type = 'attribute' + act_nexus_type = "attribute" else: - act_nexus_type = 'field' if isinstance(hdf_node, h5py.Dataset) else 'group' + act_nexus_type = "field" if isinstance(hdf_node, h5py.Dataset) else "group" # find the best fitting name in all children bestfit = -1 html_name = None for ind in range(len(elist) - 1, -1, -1): - newelem, fit = get_best_child(elist[ind], - hdf_node, - hdf_name, - hdf_class_name, - act_nexus_type) + newelem, fit = get_best_child( + elist[ind], hdf_node, hdf_name, hdf_class_name, act_nexus_type + ) if fit >= bestfit and newelem is not None: html_name = get_node_name(newelem) return hdf_path, hdf_node, hdf_class_path, elist, pind, attr, html_name @@ -915,15 +1068,21 @@ def helper_get_inherited_nodes(hdf_info2, elist, pind, attr): def get_hdf_path(hdf_info): """Get the hdf_path from an hdf_info""" - if 'hdf_path' in hdf_info: - return hdf_info['hdf_path'].split('/')[1:] - return hdf_info['hdf_node'].name.split('/')[1:] + if "hdf_path" in hdf_info: + return hdf_info["hdf_path"].split("/")[1:] + return hdf_info["hdf_node"].name.split("/")[1:] @lru_cache(maxsize=None) -def get_inherited_nodes(nxdl_path: str = None, # pylint: disable=too-many-arguments,too-many-locals - nx_name: str = None, elem: ET.Element = None, - hdf_node=None, hdf_path=None, hdf_root=None, attr=False): +def get_inherited_nodes( + nxdl_path: str = None, # pylint: disable=too-many-arguments,too-many-locals + nx_name: str = None, + elem: ET.Element = None, + hdf_node=None, + hdf_path=None, + hdf_root=None, + attr=False, +): """Returns a list of ET.Element for the given path.""" # let us start with the given definition file elist = [] # type: ignore[var-annotated] @@ -932,27 +1091,33 @@ def get_inherited_nodes(nxdl_path: str = None, # pylint: disable=too-many-argum class_path = [] # type: ignore[var-annotated] if hdf_node is not None: - hdf_info = {'hdf_node': hdf_node} + hdf_info = {"hdf_node": hdf_node} if hdf_path: - hdf_info['hdf_path'] = hdf_path + hdf_info["hdf_path"] = hdf_path if hdf_root: - hdf_root['hdf_root'] = hdf_root - hdf_node = hdf_info['hdf_node'] + hdf_root["hdf_root"] = hdf_root + hdf_node = hdf_info["hdf_node"] hdf_path = get_hdf_path(hdf_info) - hdf_class_path = get_nx_class_path(hdf_info).split('/')[1:] + hdf_class_path = get_nx_class_path(hdf_info).split("/")[1:] if attr: hdf_path.append(attr) hdf_class_path.append(attr) path = hdf_path else: - html_path = nxdl_path.split('/')[1:] + html_path = nxdl_path.split("/")[1:] path = html_path for pind in range(len(path)): if hdf_node is not None: hdf_info2 = [hdf_path, hdf_node, hdf_class_path] - [hdf_path, hdf_node, hdf_class_path, elist, - pind, attr, html_name] = helper_get_inherited_nodes(hdf_info2, elist, - pind, attr) + [ + hdf_path, + hdf_node, + hdf_class_path, + elist, + pind, + attr, + html_name, + ] = helper_get_inherited_nodes(hdf_info2, elist, pind, attr) if html_name is None: # return if NOT IN SCHEMA return (class_path, nxdl_elem_path, None) else: @@ -964,9 +1129,12 @@ def get_inherited_nodes(nxdl_path: str = None, # pylint: disable=too-many-argum return (class_path, nxdl_elem_path, elist) -def get_node_at_nxdl_path(nxdl_path: str = None, - nx_name: str = None, elem: ET.Element = None, - exc: bool = True): +def get_node_at_nxdl_path( + nxdl_path: str = None, + nx_name: str = None, + elem: ET.Element = None, + exc: bool = True, +): """Returns an ET.Element for the given path. This function either takes the name for the NeXus Application Definition we are looking for or the root elem from a previously loaded NXDL file @@ -975,32 +1143,38 @@ def get_node_at_nxdl_path(nxdl_path: str = None, (class_path, nxdlpath, elist) = get_inherited_nodes(nxdl_path, nx_name, elem) except ValueError as value_error: if exc: - raise NxdlAttributeError(f"Attributes were not found for {nxdl_path}. " - "Please check this entry in the template dictionary.") \ - from value_error + raise NxdlAttributeError( + f"Attributes were not found for {nxdl_path}. " + "Please check this entry in the template dictionary." + ) from value_error return None if class_path and nxdlpath and elist: elem = elist[0] else: elem = None if exc: - raise NxdlAttributeError(f"Attributes were not found for {nxdl_path}. " - "Please check this entry in the template dictionary.") + raise NxdlAttributeError( + f"Attributes were not found for {nxdl_path}. " + "Please check this entry in the template dictionary." + ) return elem def process_node(hdf_node, hdf_path, parser, logger, doc=True): """Processes an hdf5 node. -- it logs the node found and also checks for its attributes -- retrieves the corresponding nxdl documentation -TODO: -- follow variants -- NOMAD parser: store in NOMAD """ - hdf_info = {'hdf_path': hdf_path, 'hdf_node': hdf_node} + - it logs the node found and also checks for its attributes + - retrieves the corresponding nxdl documentation + TODO: + - follow variants + - NOMAD parser: store in NOMAD""" + hdf_info = {"hdf_path": hdf_path, "hdf_node": hdf_node} if isinstance(hdf_node, h5py.Dataset): - logger.debug(f'===== FIELD (/{hdf_path}): {hdf_node}') - val = str(hdf_node[()]).split('\n') if len(hdf_node.shape) <= 1 else str( - hdf_node[0]).split('\n') + logger.debug(f"===== FIELD (/{hdf_path}): {hdf_node}") + val = ( + str(hdf_node[()]).split("\n") + if len(hdf_node.shape) <= 1 + else str(hdf_node[0]).split("\n") + ) logger.debug(f'value: {val[0]} {"..." if len(val) > 1 else ""}') else: logger.debug( @@ -1010,46 +1184,54 @@ def process_node(hdf_node, hdf_path, parser, logger, doc=True): ) (req_str, nxdef, nxdl_path) = get_nxdl_doc(hdf_info, logger, doc) if parser is not None and isinstance(hdf_node, h5py.Dataset): - parser({"hdf_info": hdf_info, + parser( + { + "hdf_info": hdf_info, "nxdef": nxdef, "nxdl_path": nxdl_path, "val": val, - "logger": logger}) + "logger": logger, + } + ) for key, value in hdf_node.attrs.items(): - logger.debug(f'===== ATTRS (/{hdf_path}@{key})') - val = str(value).split('\n') + logger.debug(f"===== ATTRS (/{hdf_path}@{key})") + val = str(value).split("\n") logger.debug(f'value: {val[0]} {"..." if len(val) > 1 else ""}') - (req_str, nxdef, nxdl_path) = \ - get_nxdl_doc(hdf_info, logger, doc, attr=key) + (req_str, nxdef, nxdl_path) = get_nxdl_doc(hdf_info, logger, doc, attr=key) if ( parser is not None and req_str is not None - and 'NOT IN SCHEMA' not in req_str - and 'None' not in req_str + and "NOT IN SCHEMA" not in req_str + and "None" not in req_str ): - parser({"hdf_info": hdf_info, + parser( + { + "hdf_info": hdf_info, "nxdef": nxdef, "nxdl_path": nxdl_path, "val": val, - "logger": logger}, attr=key) + "logger": logger, + }, + attr=key, + ) def logger_auxiliary_signal(logger, nxdata): """Handle the presence of auxiliary signal""" - aux = nxdata.attrs.get('auxiliary_signals') + aux = nxdata.attrs.get("auxiliary_signals") if aux is not None: if isinstance(aux, str): aux = [aux] for asig in aux: - logger.debug(f'Further auxiliary signal has been identified: {asig}') + logger.debug(f"Further auxiliary signal has been identified: {asig}") return logger def print_default_plotable_header(logger): """Print a three-lines header""" - logger.debug('========================') - logger.debug('=== Default Plotable ===') - logger.debug('========================') + logger.debug("========================") + logger.debug("=== Default Plotable ===") + logger.debug("========================") def get_default_plotable(root, logger): @@ -1067,10 +1249,10 @@ def get_default_plotable(root, logger): if not nxentry: nxentry = entry_helper(root) if not nxentry: - logger.debug('No NXentry has been found') + logger.debug("No NXentry has been found") return - logger.debug('') - logger.debug('NXentry has been identified: ' + nxentry.name) + logger.debug("") + logger.debug("NXentry has been identified: " + nxentry.name) # nxdata nxdata = None nxgroup = nxentry @@ -1086,10 +1268,10 @@ def get_default_plotable(root, logger): else: nxdata = nxgroup if not nxdata: - logger.debug('No NXdata group has been found') + logger.debug("No NXdata group has been found") return - logger.debug('') - logger.debug('NXdata group has been identified: ' + nxdata.name) + logger.debug("") + logger.debug("NXdata group has been identified: " + nxdata.name) process_node(nxdata, nxdata.name, None, logger, False) # signal signal = None @@ -1101,10 +1283,10 @@ def get_default_plotable(root, logger): if not signal: signal = signal_helper(nxdata) if not signal: - logger.debug('No Signal has been found') + logger.debug("No Signal has been found") return - logger.debug('') - logger.debug('Signal has been identified: ' + signal.name) + logger.debug("") + logger.debug("Signal has been identified: " + signal.name) process_node(signal, signal.name, None, logger, False) logger = logger_auxiliary_signal(logger, nxdata) # check auxiliary_signals dim = len(signal.shape) @@ -1116,8 +1298,11 @@ def entry_helper(root): """Check entry related data""" nxentries = [] for key in root.keys(): - if isinstance(root[key], h5py.Group) and root[key].attrs.get('NX_class') and \ - root[key].attrs['NX_class'] == "NXentry": + if ( + isinstance(root[key], h5py.Group) + and root[key].attrs.get("NX_class") + and root[key].attrs["NX_class"] == "NXentry" + ): nxentries.append(root[key]) if len(nxentries) >= 1: return nxentries[0] @@ -1126,11 +1311,14 @@ def entry_helper(root): def nxdata_helper(nxentry): """Check if nxentry hdf5 object has a NX_class and, if it contains NXdata, -return its value""" + return its value""" lnxdata = [] for key in nxentry.keys(): - if isinstance(nxentry[key], h5py.Group) and nxentry[key].attrs.get('NX_class') and \ - nxentry[key].attrs['NX_class'] == "NXdata": + if ( + isinstance(nxentry[key], h5py.Group) + and nxentry[key].attrs.get("NX_class") + and nxentry[key].attrs["NX_class"] == "NXdata" + ): lnxdata.append(nxentry[key]) if len(lnxdata) >= 1: return lnxdata[0] @@ -1143,12 +1331,17 @@ def signal_helper(nxdata): for key in nxdata.keys(): if isinstance(nxdata[key], h5py.Dataset): signals.append(nxdata[key]) - if len(signals) == 1: # v3: as there was no selection given, only 1 data field shall exists + if ( + len(signals) == 1 + ): # v3: as there was no selection given, only 1 data field shall exists return signals[0] if len(signals) > 1: # v2: select the one with an attribute signal="1" attribute for sig in signals: - if sig.attrs.get("signal") and sig.attrs.get("signal") is str and \ - sig.attrs.get("signal") == "1": + if ( + sig.attrs.get("signal") + and sig.attrs.get("signal") is str + and sig.attrs.get("signal") == "1" + ): return sig return None @@ -1160,7 +1353,7 @@ def find_attrib_axis_actual_dim_num(nxdata, a_item, ax_list): for key in nxdata.keys(): if isinstance(nxdata[key], h5py.Dataset): try: - if nxdata[key].attrs['axis'] == a_item + 1: + if nxdata[key].attrs["axis"] == a_item + 1: lax.append(nxdata[key]) except KeyError: pass @@ -1169,7 +1362,7 @@ def find_attrib_axis_actual_dim_num(nxdata, a_item, ax_list): # if there are more alternatives, prioritise the one with an attribute primary="1" elif len(lax) > 1: for sax in lax: - if sax.attrs.get('primary') and sax.attrs.get('primary') == 1: + if sax.attrs.get("primary") and sax.attrs.get("primary") == 1: ax_list.insert(0, sax) else: ax_list.append(sax) @@ -1180,7 +1373,7 @@ def get_single_or_multiple_axes(nxdata, ax_datasets, a_item, ax_list): try: if isinstance(ax_datasets, str): # single axis is defined # explicite definition of dimension number - ind = nxdata.attrs.get(ax_datasets + '_indices') + ind = nxdata.attrs.get(ax_datasets + "_indices") if ind and ind is int: if ind == a_item: ax_list.append(nxdata[ax_datasets]) @@ -1189,7 +1382,7 @@ def get_single_or_multiple_axes(nxdata, ax_datasets, a_item, ax_list): else: # multiple axes are listed # explicite definition of dimension number for aax in ax_datasets: - ind = nxdata.attrs.get(aax + '_indices') + ind = nxdata.attrs.get(aax + "_indices") if ind and isinstance(ind, int): if ind == a_item: ax_list.append(nxdata[aax]) @@ -1207,22 +1400,25 @@ def axis_helper(dim, nxdata, signal, axes, logger): ax_datasets = nxdata.attrs.get("axes") # primary axes listed in attribute axes ax_list = get_single_or_multiple_axes(nxdata, ax_datasets, a_item, ax_list) for attr in nxdata.attrs.keys(): # check for corresponding AXISNAME_indices - if attr.endswith('_indices') and nxdata.attrs[attr] == a_item and \ - nxdata[attr.split('_indices')[0]] not in ax_list: - ax_list.append(nxdata[attr.split('_indices')[0]]) + if ( + attr.endswith("_indices") + and nxdata.attrs[attr] == a_item + and nxdata[attr.split("_indices")[0]] not in ax_list + ): + ax_list.append(nxdata[attr.split("_indices")[0]]) # v2 # check for ':' separated axes defined in Signal if not ax_list: try: - ax_datasets = signal.attrs.get("axes").split(':') + ax_datasets = signal.attrs.get("axes").split(":") ax_list.append(nxdata[ax_datasets[a_item]]) except (KeyError, AttributeError): pass if not ax_list: # check for axis/primary specifications find_attrib_axis_actual_dim_num(nxdata, a_item, ax_list) axes.append(ax_list) - logger.debug('') + logger.debug("") logger.debug( - f'For Axis #{a_item}, {len(ax_list)} axes have been identified: {str(ax_list)}' + f"For Axis #{a_item}, {len(ax_list)} axes have been identified: {str(ax_list)}" ) @@ -1230,38 +1426,43 @@ def get_all_is_a_rel_from_hdf_node(hdf_node, hdf_path): """Return list of nxdl concept paths for a nxdl element which corresponds to hdf node. """ - hdf_info = {'hdf_path': hdf_path, 'hdf_node': hdf_node} - (_, _, elist) = \ - get_inherited_nodes(None, nx_name=get_nxdl_entry(hdf_info), hdf_node=hdf_node, - hdf_path=hdf_info['hdf_path'] if 'hdf_path' in hdf_info else None, - hdf_root=hdf_info['hdf_root'] if 'hdf_root' in hdf_info else None) + hdf_info = {"hdf_path": hdf_path, "hdf_node": hdf_node} + (_, _, elist) = get_inherited_nodes( + None, + nx_name=get_nxdl_entry(hdf_info), + hdf_node=hdf_node, + hdf_path=hdf_info["hdf_path"] if "hdf_path" in hdf_info else None, + hdf_root=hdf_info["hdf_root"] if "hdf_root" in hdf_info else None, + ) return elist def hdf_node_to_self_concept_path(hdf_info, logger): - """ Get concept or nxdl path from given hdf_node. - """ + """Get concept or nxdl path from given hdf_node.""" # The bellow logger is for deactivatine unnecessary debug message above if logger is None: logger = logging.getLogger(__name__) logger.setLevel(logging.INFO) (_, _, nxdl_path) = get_nxdl_doc(hdf_info, logger, None) - con_path = '' + con_path = "" if nxdl_path: for nd_ in nxdl_path: - con_path = con_path + '/' + get_node_name(nd_) + con_path = con_path + "/" + get_node_name(nd_) return con_path class HandleNexus: """documentation""" - def __init__(self, logger, nexus_file, - d_inq_nd=None, c_inq_nd=None): + + def __init__(self, logger, nexus_file, d_inq_nd=None, c_inq_nd=None): self.logger = logger local_dir = os.path.abspath(os.path.dirname(__file__)) - self.input_file_name = nexus_file if nexus_file is not None else \ - os.path.join(local_dir, '../../tests/data/nexus/201805_WSe2_arpes.nxs') + self.input_file_name = ( + nexus_file + if nexus_file is not None + else os.path.join(local_dir, "../../tests/data/nexus/201805_WSe2_arpes.nxs") + ) self.parser = None self.in_file = None self.d_inq_nd = d_inq_nd @@ -1273,46 +1474,55 @@ def visit_node(self, hdf_name, hdf_node): """Function called by h5py that iterates on each node of hdf5file. It allows h5py visititems function to visit nodes.""" if self.d_inq_nd is None and self.c_inq_nd is None: - process_node(hdf_node, '/' + hdf_name, self.parser, self.logger) - elif (self.d_inq_nd is not None - and hdf_name in (self.d_inq_nd, self.d_inq_nd[1:])): - process_node(hdf_node, '/' + hdf_name, self.parser, self.logger) + process_node(hdf_node, "/" + hdf_name, self.parser, self.logger) + elif self.d_inq_nd is not None and hdf_name in ( + self.d_inq_nd, + self.d_inq_nd[1:], + ): + process_node(hdf_node, "/" + hdf_name, self.parser, self.logger) elif self.c_inq_nd is not None: - attributed_concept = self.c_inq_nd.split('@') + attributed_concept = self.c_inq_nd.split("@") attr = attributed_concept[1] if len(attributed_concept) > 1 else None - elist = get_all_is_a_rel_from_hdf_node(hdf_node, '/' + hdf_name) + elist = get_all_is_a_rel_from_hdf_node(hdf_node, "/" + hdf_name) if elist is None: return fnd_superclass = False fnd_superclass_attr = False for elem in reversed(elist): - tmp_path = elem.get('nxdlbase').split('.nxdl')[0] - con_path = '/NX' + tmp_path.split('NX')[-1] + elem.get('nxdlpath') + tmp_path = elem.get("nxdlbase").split(".nxdl")[0] + con_path = "/NX" + tmp_path.split("NX")[-1] + elem.get("nxdlpath") if fnd_superclass or con_path == attributed_concept[0]: fnd_superclass = True if attr is None: self.hdf_path_list_for_c_inq_nd.append(hdf_name) break for attribute in hdf_node.attrs.keys(): - attr_concept = get_nxdl_child(elem, attribute, nexus_type='attribute', - go_base=False) - if attr_concept is not None and \ - attr_concept.get('nxdlpath').endswith(attr): + attr_concept = get_nxdl_child( + elem, attribute, nexus_type="attribute", go_base=False + ) + if attr_concept is not None and attr_concept.get( + "nxdlpath" + ).endswith(attr): fnd_superclass_attr = True - con_path = '/NX' + tmp_path.split('NX')[-1] \ - + attr_concept.get('nxdlpath') - self.hdf_path_list_for_c_inq_nd.append(hdf_name + "@" + attribute) + con_path = ( + "/NX" + + tmp_path.split("NX")[-1] + + attr_concept.get("nxdlpath") + ) + self.hdf_path_list_for_c_inq_nd.append( + hdf_name + "@" + attribute + ) break if fnd_superclass_attr: break def not_yet_visited(self, root, name): """checking if a new node has already been visited in its path""" - path = name.split('/') + path = name.split("/") for i in range(1, len(path)): - act_path = '/'.join(path[:i]) + act_path = "/".join(path[:i]) # print(act_path+' - '+name) - if root['/' + act_path] == root['/' + name]: + if root["/" + act_path] == root["/" + name]: return False return True @@ -1323,7 +1533,7 @@ def full_visit(self, root, hdf_node, name, func): func(name, hdf_node) if isinstance(hdf_node, h5py.Group): for ch_name, child in hdf_node.items(): - full_name = ch_name if len(name) == 0 else name + '/' + ch_name + full_name = ch_name if len(name) == 0 else name + "/" + ch_name if self.not_yet_visited(root, full_name): self.full_visit(root, child, full_name, func) @@ -1333,9 +1543,10 @@ def process_nexus_master_file(self, parser): self.in_file = h5py.File( self.input_file_name[0] if isinstance(self.input_file_name, list) - else self.input_file_name, 'r' + else self.input_file_name, + "r", ) - self.full_visit(self.in_file, self.in_file, '', self.visit_node) + self.full_visit(self.in_file, self.in_file, "", self.visit_node) if self.d_inq_nd is None and self.c_inq_nd is None: get_default_plotable(self.in_file, self.logger) # To log the provided concept and concepts founded @@ -1347,48 +1558,58 @@ def process_nexus_master_file(self, parser): @click.command() @click.option( - '-f', - '--nexus-file', + "-f", + "--nexus-file", required=False, default=None, - help=('NeXus file with extension .nxs to learn NeXus different concept' - ' documentation and concept.') + help=( + "NeXus file with extension .nxs to learn NeXus different concept" + " documentation and concept." + ), ) @click.option( - '-d', - '--documentation', + "-d", + "--documentation", required=False, default=None, - help=("Definition path in nexus output (.nxs) file. Returns debug" - "log relavent with that definition path. Example: /entry/data/delays") + help=( + "Definition path in nexus output (.nxs) file. Returns debug" + "log relavent with that definition path. Example: /entry/data/delays" + ), ) @click.option( - '-c', - '--concept', + "-c", + "--concept", required=False, default=None, - help=("Concept path from application definition file (.nxdl,xml). Finds out" - "all the available concept definition (IS-A realation) for rendered" - "concept path. Example: /NXarpes/ENTRY/INSTRUMENT/analyser") + help=( + "Concept path from application definition file (.nxdl,xml). Finds out" + "all the available concept definition (IS-A realation) for rendered" + "concept path. Example: /NXarpes/ENTRY/INSTRUMENT/analyser" + ), ) def main(nexus_file, documentation, concept): """The main function to call when used as a script.""" logging_format = "%(levelname)s: %(message)s" stdout_handler = logging.StreamHandler(sys.stdout) stdout_handler.setLevel(logging.DEBUG) - logging.basicConfig(level=logging.INFO, format=logging_format, handlers=[stdout_handler]) + logging.basicConfig( + level=logging.INFO, format=logging_format, handlers=[stdout_handler] + ) logger = logging.getLogger(__name__) logger.addHandler(stdout_handler) logger.setLevel(logging.DEBUG) logger.propagate = False if documentation and concept: - raise ValueError("Only one option either documentation (-d) or is_a relation " - "with a concept (-c) can be requested.") - nexus_helper = HandleNexus(logger, nexus_file, - d_inq_nd=documentation, - c_inq_nd=concept) + raise ValueError( + "Only one option either documentation (-d) or is_a relation " + "with a concept (-c) can be requested." + ) + nexus_helper = HandleNexus( + logger, nexus_file, d_inq_nd=documentation, c_inq_nd=concept + ) nexus_helper.process_nexus_master_file(None) -if __name__ == '__main__': +if __name__ == "__main__": main() # pylint: disable=no-value-for-parameter From 5a1de22aba651428ed2b6623e401fea9186c0e93 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Fri, 16 Jun 2023 00:48:53 +0200 Subject: [PATCH 0032/1012] linting --- dev_tools/docs/nxdl.py | 2 +- dev_tools/utils/nexus.py | 9 +++++---- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/dev_tools/docs/nxdl.py b/dev_tools/docs/nxdl.py index 1316e230ac..03c72be21d 100644 --- a/dev_tools/docs/nxdl.py +++ b/dev_tools/docs/nxdl.py @@ -7,12 +7,12 @@ from typing import Optional import lxml -from ..utils import nexus as pynxtools_nxlib from ..globals.directories import get_nxdl_root from ..globals.errors import NXDLParseError from ..globals.nxdl import NXDL_NAMESPACE from ..globals.urls import REPO_URL +from ..utils import nexus as pynxtools_nxlib from ..utils.types import PathLike from .anchor_list import AnchorRegistry diff --git a/dev_tools/utils/nexus.py b/dev_tools/utils/nexus.py index 7b09e30f33..def84b1605 100644 --- a/dev_tools/utils/nexus.py +++ b/dev_tools/utils/nexus.py @@ -2,15 +2,16 @@ """Read files from different format and print it in a standard NeXus format """ +import logging import os +import sys +import textwrap import xml.etree.ElementTree as ET from functools import lru_cache from glob import glob -import sys -import logging -import textwrap -import h5py + import click +import h5py class NxdlAttributeError(Exception): From 286c0c2e6262686ec87311cf299b8b49ae07b035 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Fri, 16 Jun 2023 00:54:10 +0200 Subject: [PATCH 0033/1012] imports --- requirements.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/requirements.txt b/requirements.txt index 6d024bda3a..ac0c657370 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1,6 +1,8 @@ # Prepare for Documentation lxml pyyaml +click>=7.1.2 +h5py>=3.6.0 # Documentation building sphinx>=5 From 6837fb6b1847a90e99979d0190dacb58078585d7 Mon Sep 17 00:00:00 2001 From: domna Date: Fri, 16 Jun 2023 10:01:05 +0200 Subject: [PATCH 0034/1012] Adds pyproject --- .gitignore | 20 +++++++++++++++++++ MANIFEST.in | 4 ++++ dev_tools/utils/nexus.py | 21 ++++++-------------- pyproject.toml | 43 ++++++++++++++++++++++++++++++++++++++++ 4 files changed, 73 insertions(+), 15 deletions(-) create mode 100644 MANIFEST.in create mode 100644 pyproject.toml diff --git a/.gitignore b/.gitignore index ff21c1627c..50408db4bd 100644 --- a/.gitignore +++ b/.gitignore @@ -12,3 +12,23 @@ makelog.txt # Unknown /python/ __github_creds__.txt + +# Distribution / packaging +.Python +build/ +develop-eggs/ +dist/ +downloads/ +eggs/ +.eggs/ +lib/ +lib64/ +parts/ +sdist/ +var/ +wheels/ +share/python-wheels/ +*.egg-info/ +.installed.cfg +*.egg +MANIFEST diff --git a/MANIFEST.in b/MANIFEST.in new file mode 100644 index 0000000000..20485f6286 --- /dev/null +++ b/MANIFEST.in @@ -0,0 +1,4 @@ +recursive-include applications/ *.nxdl.xml +recursive-include contributed_definitions/ *.nxdl.xml +recursive-include base_classes/ *.nxdl.xml +include ./ *.xsd \ No newline at end of file diff --git a/dev_tools/utils/nexus.py b/dev_tools/utils/nexus.py index def84b1605..8e8ef771fc 100644 --- a/dev_tools/utils/nexus.py +++ b/dev_tools/utils/nexus.py @@ -1457,13 +1457,11 @@ class HandleNexus: def __init__(self, logger, nexus_file, d_inq_nd=None, c_inq_nd=None): self.logger = logger - local_dir = os.path.abspath(os.path.dirname(__file__)) - self.input_file_name = ( - nexus_file - if nexus_file is not None - else os.path.join(local_dir, "../../tests/data/nexus/201805_WSe2_arpes.nxs") - ) + if nexus_file is None: + raise ValueError("Nexus file not specified. Cannot proceed.") + + self.input_file_name = nexus_file self.parser = None self.in_file = None self.d_inq_nd = d_inq_nd @@ -1558,15 +1556,8 @@ def process_nexus_master_file(self, parser): @click.command() -@click.option( - "-f", - "--nexus-file", - required=False, - default=None, - help=( - "NeXus file with extension .nxs to learn NeXus different concept" - " documentation and concept." - ), +@click.argument( + 'nexus_file', ) @click.option( "-d", diff --git a/pyproject.toml b/pyproject.toml new file mode 100644 index 0000000000..6a90ec5732 --- /dev/null +++ b/pyproject.toml @@ -0,0 +1,43 @@ +[build-system] +requires = ["setuptools>=64.0.1", "setuptools-scm[toml]>=6.2"] +build-backend = "setuptools.build_meta" + +[project] +name = "nexusdefinitions" +dynamic = ["version"] +authors = [ + { name = "NIAC" } +] +description = "Nexus definitions" +readme = "README.md" +license = { file = "LGPL.txt" } +requires-python = "" +classifiers = [ + "Operating System :: OS Independent" +] +dependencies = [ + "lxml", + "pyyaml", + "click>=7.1.2", + "h5py>=3.6.0", + "sphinx>=5", + "sphinx-tabs", + "pytest", + "black>=22.3", + "flake8>=4", + "isort>=5.10", + "click>=7.1.2", +] + +[project.urls] +"Homepage" = "https://nexusformat.org" + +[project.scripts] +read_nexus = "dev_tools.utils.nexus:main" + +[tools.setuptools_scm] +version_scheme = "guess-next-dev" +local_scheme = "node-and-date" + +[tool.setuptools] +packages = ["dev_tools"] From 52a21eea39df34f6ba1d3cefd8f1181c48a3fa7e Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Fri, 16 Jun 2023 10:16:51 +0200 Subject: [PATCH 0035/1012] linting --- dev_tools/utils/nexus.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dev_tools/utils/nexus.py b/dev_tools/utils/nexus.py index 8e8ef771fc..e797092d1f 100644 --- a/dev_tools/utils/nexus.py +++ b/dev_tools/utils/nexus.py @@ -1557,7 +1557,7 @@ def process_nexus_master_file(self, parser): @click.command() @click.argument( - 'nexus_file', + "nexus_file", ) @click.option( "-d", From d3d101f862572fa619ae11f90a703a49e885842d Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Fri, 16 Jun 2023 10:58:21 +0200 Subject: [PATCH 0036/1012] adjusted default location of definitions inside the module --- Makefile | 1 - dev_tools/utils/nexus.py | 2 +- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 44c076c341..ae556d7339 100644 --- a/Makefile +++ b/Makefile @@ -6,7 +6,6 @@ PYTHON = python3 SPHINX = sphinx-build BUILD_DIR = "build" -export NEXUS_DEF_PATH = $(shell pwd) .PHONY: help install style autoformat test clean prepare html pdf impatient-guide all local diff --git a/dev_tools/utils/nexus.py b/dev_tools/utils/nexus.py index e797092d1f..4bcb1c9e96 100644 --- a/dev_tools/utils/nexus.py +++ b/dev_tools/utils/nexus.py @@ -45,7 +45,7 @@ def get_nexus_definitions_path(): return os.environ["NEXUS_DEF_PATH"] except KeyError: # or it should be available locally under the dir 'definitions' local_dir = os.path.abspath(os.path.dirname(__file__)) - return os.path.join(local_dir, f"..{os.sep}definitions") + return os.path.join(local_dir, f"..{os.sep}..") def get_hdf_root(hdf_node): From 025c0786858e80d416baf90c36b0d8dd100fb8d8 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Fri, 16 Jun 2023 11:59:32 +0200 Subject: [PATCH 0037/1012] new characters as Code Camp suggested --- dev_tools/docs/nxdl.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/dev_tools/docs/nxdl.py b/dev_tools/docs/nxdl.py index 03c72be21d..c8c6936410 100644 --- a/dev_tools/docs/nxdl.py +++ b/dev_tools/docs/nxdl.py @@ -668,7 +668,7 @@ def get_first_parent_ref(self, path, tag): ) parent_display_name = f"{parent_def_name[1:]}{parent_path}" return ( - f":abbr:`... (override: {parent_display_name})" - + f"`:ref:`🔗 `" + f":abbr:`⤆ (override: {parent_display_name})" + + f"`:ref:`... `" ) return "" From adf098ed87b9e03585a30c7f3094fed989d35fa3 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Fri, 16 Jun 2023 12:08:40 +0200 Subject: [PATCH 0038/1012] make new char available for latex --- manual/source/conf.py | 1 + 1 file changed, 1 insertion(+) diff --git a/manual/source/conf.py b/manual/source/conf.py index 346e664d95..638a665591 100644 --- a/manual/source/conf.py +++ b/manual/source/conf.py @@ -97,4 +97,5 @@ 'preamble': r''' \usepackage{amsbsy} \DeclareUnicodeCharacter{1F517}{X}''' + \DeclareUnicodeCharacter{2906}{<-}''' } From 222a3c0a09fbabcd722061c763838f7464a14221 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Fri, 16 Jun 2023 12:17:08 +0200 Subject: [PATCH 0039/1012] make new char available for latex --- manual/source/conf.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/manual/source/conf.py b/manual/source/conf.py index 638a665591..6ee889c54a 100644 --- a/manual/source/conf.py +++ b/manual/source/conf.py @@ -96,6 +96,6 @@ 'maxlistdepth':7, # some application definitions are deeply nested 'preamble': r''' \usepackage{amsbsy} - \DeclareUnicodeCharacter{1F517}{X}''' + \DeclareUnicodeCharacter{1F517}{X} \DeclareUnicodeCharacter{2906}{<-}''' } From 7252a4983fdd935c1ef4df4c3c3e038cb71ad4b1 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Fri, 16 Jun 2023 12:18:08 +0200 Subject: [PATCH 0040/1012] make new char available for latex --- manual/source/conf.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/manual/source/conf.py b/manual/source/conf.py index 6ee889c54a..dcd444c8ee 100644 --- a/manual/source/conf.py +++ b/manual/source/conf.py @@ -97,5 +97,5 @@ 'preamble': r''' \usepackage{amsbsy} \DeclareUnicodeCharacter{1F517}{X} - \DeclareUnicodeCharacter{2906}{<-}''' + \DeclareUnicodeCharacter{2906}{<=}''' } From fd4b4a6f07b5dae23469dcd0bc68b3dccfc1ea52 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Fri, 16 Jun 2023 17:27:11 +0200 Subject: [PATCH 0041/1012] collapsing doc_enum-s --- dev_tools/docs/nxdl.py | 55 +++++++++++++++++++++++++++--------------- manual/source/conf.py | 1 + 2 files changed, 37 insertions(+), 19 deletions(-) diff --git a/dev_tools/docs/nxdl.py b/dev_tools/docs/nxdl.py index c8c6936410..815e8b7774 100644 --- a/dev_tools/docs/nxdl.py +++ b/dev_tools/docs/nxdl.py @@ -110,7 +110,7 @@ def _parse_nxdl_file(self, nxdl_file: Path): # print official description of this class self._print("") self._print("**Description**:\n") - self._print_doc(self._INDENTATION_UNIT, ns, root, required=True) + self._print_doc_enum("", ns, root, required=True) # print symbol list node_list = root.xpath("nx:symbols", namespaces=ns) @@ -120,7 +120,7 @@ def _parse_nxdl_file(self, nxdl_file: Path): elif len(node_list) > 1: raise Exception(f"Invalid symbol table in {nxclass_name}") else: - self._print_doc(self._INDENTATION_UNIT, ns, node_list[0]) + self._print_doc_enum("", ns, node_list[0]) for node in node_list[0].xpath("nx:symbol", namespaces=ns): doc = self._get_doc_line(ns, node) self._print(f" **{node.get('name')}**", end="") @@ -499,6 +499,35 @@ def _print_doc(self, indent, ns, node, required=False): self._print(f"{indent}{line}") self._print() + def long_doc(self, ns, node): + length = 0 + line = "documentation" + fnd = False + blocks = self._get_doc_blocks(ns, node) + for block in blocks: + lines = block.splitlines() + length += len(lines) + for single_line in lines: + if len(single_line) > 2 and single_line[0] != "." and not fnd: + fnd = True + line = single_line + return (length, line, blocks) + + def _print_doc_enum(self, indent, ns, node, required=False): + collapse_indent = indent + node_list = node.xpath("nx:enumeration", namespaces=ns) + (doclen, line, blocks) = self.long_doc(ns, node) + if len(node_list) + doclen > 1: + collapse_indent = f"{indent} " + self._print(f"{indent}{self._INDENTATION_UNIT}.. collapse:: {line} ...\n") + self._print_doc( + collapse_indent + self._INDENTATION_UNIT, ns, node, required=required + ) + if len(node_list) == 1: + self._print_enumeration( + collapse_indent + self._INDENTATION_UNIT, ns, node_list[0] + ) + def _print_attribute(self, ns, kind, node, optional, indent, parent_path): name = node.get("name") index_name = name @@ -509,10 +538,7 @@ def _print_attribute(self, ns, kind, node, optional, indent, parent_path): self._print( f"{indent}**@{name}**: {optional}{self._format_type(node)}{self._format_units(node)} {self.get_first_parent_ref(f'{parent_path}/{name}', 'attribute')}\n" ) - self._print_doc(indent + self._INDENTATION_UNIT, ns, node) - node_list = node.xpath("nx:enumeration", namespaces=ns) - if len(node_list) == 1: - self._print_enumeration(indent + self._INDENTATION_UNIT, ns, node_list[0]) + self._print_doc_enum(indent, ns, node) def _print_if_deprecated(self, ns, node, indent): deprecated = node.get("deprecated", None) @@ -555,13 +581,7 @@ def _print_full_tree(self, ns, parent, name, indent, parent_path): ) self._print_if_deprecated(ns, node, indent + self._INDENTATION_UNIT) - self._print_doc(indent + self._INDENTATION_UNIT, ns, node) - - node_list = node.xpath("nx:enumeration", namespaces=ns) - if len(node_list) == 1: - self._print_enumeration( - indent + self._INDENTATION_UNIT, ns, node_list[0] - ) + self._print_doc_enum(indent, ns, node) for subnode in node.xpath("nx:attribute", namespaces=ns): optional = self._get_required_or_optional_text(subnode) @@ -592,7 +612,7 @@ def _print_full_tree(self, ns, parent, name, indent, parent_path): ) self._print_if_deprecated(ns, node, indent + self._INDENTATION_UNIT) - self._print_doc(indent + self._INDENTATION_UNIT, ns, node) + self._print_doc_enum(indent, ns, node) for subnode in node.xpath("nx:attribute", namespaces=ns): optional = self._get_required_or_optional_text(subnode) @@ -623,7 +643,7 @@ def _print_full_tree(self, ns, parent, name, indent, parent_path): f"(suggested target: ``{node.get('target')}``)" "\n" ) - self._print_doc(indent + self._INDENTATION_UNIT, ns, node) + self._print_doc_enum(indent, ns, node) def _print(self, *args, end="\n"): # TODO: change instances of \t to proper indentation @@ -667,8 +687,5 @@ def get_first_parent_ref(self, path, tag): + parent_path[pos_of_right_slash + 1 :] ) parent_display_name = f"{parent_def_name[1:]}{parent_path}" - return ( - f":abbr:`⤆ (override: {parent_display_name})" - + f"`:ref:`... `" - ) + return f":ref:`⤆ `" return "" diff --git a/manual/source/conf.py b/manual/source/conf.py index dcd444c8ee..a1f854be4b 100644 --- a/manual/source/conf.py +++ b/manual/source/conf.py @@ -42,6 +42,7 @@ # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom # ones. extensions = [ + 'sphinx_toolbox.collapse', 'sphinx.ext.mathjax', 'sphinx.ext.ifconfig', 'sphinx.ext.viewcode', From 90ff26b8aa6e37552b298b8f3a70e887d3f7afa6 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Fri, 16 Jun 2023 17:32:11 +0200 Subject: [PATCH 0042/1012] missing sphinx dependency --- pyproject.toml | 1 - requirements.txt | 1 + 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/pyproject.toml b/pyproject.toml index 6a90ec5732..d4cf990c86 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -26,7 +26,6 @@ dependencies = [ "black>=22.3", "flake8>=4", "isort>=5.10", - "click>=7.1.2", ] [project.urls] diff --git a/requirements.txt b/requirements.txt index ac0c657370..bbfd892f76 100644 --- a/requirements.txt +++ b/requirements.txt @@ -7,6 +7,7 @@ h5py>=3.6.0 # Documentation building sphinx>=5 sphinx-tabs +sphinx-toolbox # Testing pytest From 015aa7761b1814e2dadb4f30aebe0ac39ef04b32 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Wed, 21 Jun 2023 12:40:56 +0200 Subject: [PATCH 0043/1012] removing h5py dependency --- dev_tools/docs/nxdl.py | 2 +- dev_tools/utils/{nexus.py => nxdl_utils.py} | 761 +------------------- 2 files changed, 5 insertions(+), 758 deletions(-) rename dev_tools/utils/{nexus.py => nxdl_utils.py} (51%) diff --git a/dev_tools/docs/nxdl.py b/dev_tools/docs/nxdl.py index 815e8b7774..4c36ef2775 100644 --- a/dev_tools/docs/nxdl.py +++ b/dev_tools/docs/nxdl.py @@ -12,7 +12,7 @@ from ..globals.errors import NXDLParseError from ..globals.nxdl import NXDL_NAMESPACE from ..globals.urls import REPO_URL -from ..utils import nexus as pynxtools_nxlib +from ..utils import nxdl_utils as pynxtools_nxlib from ..utils.types import PathLike from .anchor_list import AnchorRegistry diff --git a/dev_tools/utils/nexus.py b/dev_tools/utils/nxdl_utils.py similarity index 51% rename from dev_tools/utils/nexus.py rename to dev_tools/utils/nxdl_utils.py index 4bcb1c9e96..efba439bec 100644 --- a/dev_tools/utils/nexus.py +++ b/dev_tools/utils/nxdl_utils.py @@ -1,18 +1,13 @@ # pylint: disable=too-many-lines -"""Read files from different format and print it in a standard NeXus format +"""Parse NeXus definition files """ -import logging import os -import sys import textwrap import xml.etree.ElementTree as ET from functools import lru_cache from glob import glob -import click -import h5py - class NxdlAttributeError(Exception): """An exception for throwing an error when an Nxdl attribute is not found.""" @@ -89,49 +84,6 @@ def get_hdf_info_parent(hdf_info): return {"hdf_node": node, "hdf_path": get_parent_path(hdf_info["hdf_path"])} -def get_nx_class_path(hdf_info): - """Get the full path of an HDF5 node using nexus classes - in case of a field, end with the field name""" - hdf_node = hdf_info["hdf_node"] - if hdf_node.name == "/": - return "" - if isinstance(hdf_node, h5py.Group): - return ( - get_nx_class_path(get_hdf_info_parent(hdf_info)) - + "/" - + ( - hdf_node.attrs["NX_class"] - if "NX_class" in hdf_node.attrs.keys() - else hdf_node.name.split("/")[-1] - ) - ) - if isinstance(hdf_node, h5py.Dataset): - return ( - get_nx_class_path(get_hdf_info_parent(hdf_info)) - + "/" - + hdf_node.name.split("/")[-1] - ) - return "" - - -def get_nxdl_entry(hdf_info): - """Get the nxdl application definition for an HDF5 node""" - entry = hdf_info - while ( - isinstance(entry["hdf_node"], h5py.Dataset) - or "NX_class" not in entry["hdf_node"].attrs.keys() - or entry["hdf_node"].attrs["NX_class"] != "NXentry" - ): - entry = get_hdf_info_parent(entry) - if entry["hdf_node"].name == "/": - return "NO NXentry found" - try: - nxdef = entry["hdf_node"]["definition"][()] - return nxdef.decode() - except KeyError: # 'NO Definition referenced' - return "NXentry" - - def get_nx_class(nxdl_elem): """Get the nexus class for a NXDL node""" if "category" in nxdl_elem.attrib.keys(): @@ -476,65 +428,6 @@ def get_required_string(nxdl_elem): return "<>" -def chk_nxdataaxis_v2(hdf_node, name, logger): - """Check if dataset is an axis""" - own_signal = hdf_node.attrs.get("signal") # check for being a Signal - if own_signal is str and own_signal == "1": - logger.debug("Dataset referenced (v2) as NXdata SIGNAL") - own_axes = hdf_node.attrs.get("axes") # check for being an axis - if own_axes is str: - axes = own_axes.split(":") - for i in len(axes): - if axes[i] and name == axes[i]: - logger.debug("Dataset referenced (v2) as NXdata AXIS #%d", i) - return None - ownpaxis = hdf_node.attrs.get("primary") - own_axis = hdf_node.attrs.get("axis") - if own_axis is int: - # also convention v1 - if ownpaxis is int and ownpaxis == 1: - logger.debug("Dataset referenced (v2) as NXdata AXIS #%d", own_axis - 1) - else: - logger.debug( - "Dataset referenced (v2) as NXdata (primary/alternative) AXIS #%d", - own_axis - 1, - ) - return None - - -def chk_nxdataaxis(hdf_node, name, logger): - """NEXUS Data Plotting Standard v3: new version from 2014""" - if not isinstance( - hdf_node, h5py.Dataset - ): # check if it is a field in an NXdata node - return None - parent = hdf_node.parent - if not parent or (parent and not parent.attrs.get("NX_class") == "NXdata"): - return None - signal = parent.attrs.get("signal") # chk for Signal - if signal and name == signal: - logger.debug("Dataset referenced as NXdata SIGNAL") - return None - axes = parent.attrs.get("axes") # check for default Axes - if axes is str: - if name == axes: - logger.debug("Dataset referenced as NXdata AXIS") - return None - elif axes is not None: - for i, j in enumerate(axes): - if name == j: - indices = parent.attrs.get(j + "_indices") - if indices is int: - logger.debug(f"Dataset referenced as NXdata AXIS #{indices}") - else: - logger.debug(f"Dataset referenced as NXdata AXIS #{i}") - return None - indices = parent.attrs.get(name + "_indices") # check for alternative Axes - if indices is int: - logger.debug(f"Dataset referenced as NXdata alternative AXIS #{indices}") - return chk_nxdataaxis_v2(hdf_node, name, logger) # check for older conventions - - # below there are some functions used in get_nxdl_doc function: def write_doc_string(logger, doc, attr): """Simple function that prints a line in the logger if doc exists""" @@ -670,150 +563,11 @@ def other_attrs( return logger, elem, nxdl_path, doc, attr -def check_deprecation_enum_axis(variables, doc, elist, attr, hdf_node): - """Check for several attributes. - deprecation - enums - nxdataaxis""" - logger, elem, path = variables - dep_str = elem.attrib.get("deprecated") # check for deprecation - if dep_str: - if doc: - logger.debug("DEPRECATED - " + dep_str) - for base_elem in elist if not attr else [elem]: # check for enums - sdoc = get_nxdl_child(base_elem, "enumeration", go_base=False) - if sdoc is not None: - if doc: - logger.debug("enumeration (" + get_node_concept_path(base_elem) + "):") - for item in sdoc: - if get_local_name_from_xml(item) == "item": - if doc: - logger.debug("-> " + item.attrib["value"]) - chk_nxdataaxis( - hdf_node, path.split("/")[-1], logger - ) # look for NXdata reference (axes/signal) - for base_elem in elist if not attr else [elem]: # check for doc - sdoc = get_nxdl_child(base_elem, "doc", go_base=False) - if doc: - logger.debug("documentation (" + get_node_concept_path(base_elem) + "):") - logger.debug(sdoc.text if sdoc is not None else "") - return logger, elem, path, doc, elist, attr, hdf_node - - def get_node_concept_path(elem): """get the short version of nxdlbase:nxdlpath""" return str(elem.get("nxdlbase").split("/")[-1] + ":" + elem.get("nxdlpath")) -def get_nxdl_attr_doc( # pylint: disable=too-many-arguments,too-many-locals - elem, elist, attr, hdf_node, logger, doc, nxdl_path, req_str, path, hdf_info -): - """Get nxdl documentation for an attribute""" - new_elem = [] - old_elem = elem - for elem_index, act_elem1 in enumerate(elist): - act_elem = act_elem1 - # NX_class is a compulsory attribute for groups in a nexus file - # which should match the type of the corresponding NXDL element - if ( - attr == "NX_class" - and not isinstance(hdf_node, h5py.Dataset) - and elem_index == 0 - ): - elem = None - logger, doc, attr = write_doc_string(logger, doc, attr) - new_elem = elem - break - # units category is a compulsory attribute for any fields - if attr == "units" and isinstance(hdf_node, h5py.Dataset): - req_str = "<>" - logger, act_elem, nxdl_path, doc, attr = try_find_units( - logger, act_elem, nxdl_path, doc, attr - ) - # units for attributes can be given as ATTRIBUTENAME_units - elif attr.endswith("_units"): - logger, act_elem, nxdl_path, doc, attr, req_str = check_attr_name_nxdl( - (logger, act_elem, nxdl_path, doc, attr, req_str) - ) - # default is allowed for groups - elif attr == "default" and not isinstance(hdf_node, h5py.Dataset): - req_str = "<>" - # try to find if default is defined as a child of the NXDL element - act_elem = get_nxdl_child( - act_elem, attr, nexus_type="attribute", go_base=False - ) - logger, act_elem, nxdl_path, doc, attr = try_find_default( - logger, act_elem1, act_elem, nxdl_path, doc, attr - ) - else: # other attributes - act_elem = get_nxdl_child( - act_elem, attr, nexus_type="attribute", go_base=False - ) - if act_elem is not None: - logger, act_elem, nxdl_path, doc, attr = other_attrs( - logger, act_elem1, act_elem, nxdl_path, doc, attr - ) - if act_elem is not None: - new_elem.append(act_elem) - if req_str is None: - req_str = get_required_string(act_elem) # check for being required - if doc: - logger.debug(req_str) - variables = [logger, act_elem, path] - ( - logger, - elem, - path, - doc, - elist, - attr, - hdf_node, - ) = check_deprecation_enum_axis(variables, doc, elist, attr, hdf_node) - elem = old_elem - if req_str is None and doc: - if attr != "NX_class": - logger.debug("@" + attr + " - IS NOT IN SCHEMA") - logger.debug("") - return (req_str, get_nxdl_entry(hdf_info), nxdl_path) - - -def get_nxdl_doc(hdf_info, logger, doc, attr=False): - """Get nxdl documentation for an HDF5 node (or its attribute)""" - hdf_node = hdf_info["hdf_node"] - # new way: retrieve multiple inherited base classes - (class_path, nxdl_path, elist) = get_inherited_nodes( - None, - nx_name=get_nxdl_entry(hdf_info), - hdf_node=hdf_node, - hdf_path=hdf_info["hdf_path"] if "hdf_path" in hdf_info else None, - hdf_root=hdf_info["hdf_root"] if "hdf_root" in hdf_info else None, - ) - elem = elist[0] if class_path and elist else None - if doc: - logger.debug("classpath: " + str(class_path)) - logger.debug( - "NOT IN SCHEMA" - if elem is None - else "classes:\n" + "\n".join(get_node_concept_path(e) for e in elist) - ) - # old solution with a single elem instead of using elist - path = get_nx_class_path(hdf_info) - req_str = None - if elem is None: - if doc: - logger.debug("") - return ("None", None, None) - if attr: - return get_nxdl_attr_doc( - elem, elist, attr, hdf_node, logger, doc, nxdl_path, req_str, path, hdf_info - ) - req_str = get_required_string(elem) # check for being required - if doc: - logger.debug(req_str) - variables = [logger, elem, path] - logger, elem, path, doc, elist, attr, hdf_node = check_deprecation_enum_axis( - variables, doc, elist, attr, hdf_node - ) - return (req_str, get_nxdl_entry(hdf_info), nxdl_path) - - def get_doc(node, ntype, nxhtml, nxpath): """Get documentation""" # URL for html documentation @@ -1044,44 +798,11 @@ def walk_elist(elist, html_name): return elist, html_name -def helper_get_inherited_nodes(hdf_info2, elist, pind, attr): - """find the best fitting name in all children""" - hdf_path, hdf_node, hdf_class_path = hdf_info2 - hdf_name = hdf_path[pind] - hdf_class_name = hdf_class_path[pind] - if pind < len(hdf_path) - (2 if attr else 1): - act_nexus_type = "group" - elif pind == len(hdf_path) - 1 and attr: - act_nexus_type = "attribute" - else: - act_nexus_type = "field" if isinstance(hdf_node, h5py.Dataset) else "group" - # find the best fitting name in all children - bestfit = -1 - html_name = None - for ind in range(len(elist) - 1, -1, -1): - newelem, fit = get_best_child( - elist[ind], hdf_node, hdf_name, hdf_class_name, act_nexus_type - ) - if fit >= bestfit and newelem is not None: - html_name = get_node_name(newelem) - return hdf_path, hdf_node, hdf_class_path, elist, pind, attr, html_name - - -def get_hdf_path(hdf_info): - """Get the hdf_path from an hdf_info""" - if "hdf_path" in hdf_info: - return hdf_info["hdf_path"].split("/")[1:] - return hdf_info["hdf_node"].name.split("/")[1:] - - @lru_cache(maxsize=None) def get_inherited_nodes( nxdl_path: str = None, # pylint: disable=too-many-arguments,too-many-locals nx_name: str = None, elem: ET.Element = None, - hdf_node=None, - hdf_path=None, - hdf_root=None, attr=False, ): """Returns a list of ET.Element for the given path.""" @@ -1091,38 +812,10 @@ def get_inherited_nodes( nxdl_elem_path = [elist[0]] class_path = [] # type: ignore[var-annotated] - if hdf_node is not None: - hdf_info = {"hdf_node": hdf_node} - if hdf_path: - hdf_info["hdf_path"] = hdf_path - if hdf_root: - hdf_root["hdf_root"] = hdf_root - hdf_node = hdf_info["hdf_node"] - hdf_path = get_hdf_path(hdf_info) - hdf_class_path = get_nx_class_path(hdf_info).split("/")[1:] - if attr: - hdf_path.append(attr) - hdf_class_path.append(attr) - path = hdf_path - else: - html_path = nxdl_path.split("/")[1:] - path = html_path + html_path = nxdl_path.split("/")[1:] + path = html_path for pind in range(len(path)): - if hdf_node is not None: - hdf_info2 = [hdf_path, hdf_node, hdf_class_path] - [ - hdf_path, - hdf_node, - hdf_class_path, - elist, - pind, - attr, - html_name, - ] = helper_get_inherited_nodes(hdf_info2, elist, pind, attr) - if html_name is None: # return if NOT IN SCHEMA - return (class_path, nxdl_elem_path, None) - else: - html_name = html_path[pind] + html_name = html_path[pind] elist, html_name = walk_elist(elist, html_name) if elist: class_path.append(get_nx_class(elist[0])) @@ -1159,449 +852,3 @@ def get_node_at_nxdl_path( "Please check this entry in the template dictionary." ) return elem - - -def process_node(hdf_node, hdf_path, parser, logger, doc=True): - """Processes an hdf5 node. - - it logs the node found and also checks for its attributes - - retrieves the corresponding nxdl documentation - TODO: - - follow variants - - NOMAD parser: store in NOMAD""" - hdf_info = {"hdf_path": hdf_path, "hdf_node": hdf_node} - if isinstance(hdf_node, h5py.Dataset): - logger.debug(f"===== FIELD (/{hdf_path}): {hdf_node}") - val = ( - str(hdf_node[()]).split("\n") - if len(hdf_node.shape) <= 1 - else str(hdf_node[0]).split("\n") - ) - logger.debug(f'value: {val[0]} {"..." if len(val) > 1 else ""}') - else: - logger.debug( - f"===== GROUP (/{hdf_path} " - f"[{get_nxdl_entry(hdf_info)}" - f"::{get_nx_class_path(hdf_info)}]): {hdf_node}" - ) - (req_str, nxdef, nxdl_path) = get_nxdl_doc(hdf_info, logger, doc) - if parser is not None and isinstance(hdf_node, h5py.Dataset): - parser( - { - "hdf_info": hdf_info, - "nxdef": nxdef, - "nxdl_path": nxdl_path, - "val": val, - "logger": logger, - } - ) - for key, value in hdf_node.attrs.items(): - logger.debug(f"===== ATTRS (/{hdf_path}@{key})") - val = str(value).split("\n") - logger.debug(f'value: {val[0]} {"..." if len(val) > 1 else ""}') - (req_str, nxdef, nxdl_path) = get_nxdl_doc(hdf_info, logger, doc, attr=key) - if ( - parser is not None - and req_str is not None - and "NOT IN SCHEMA" not in req_str - and "None" not in req_str - ): - parser( - { - "hdf_info": hdf_info, - "nxdef": nxdef, - "nxdl_path": nxdl_path, - "val": val, - "logger": logger, - }, - attr=key, - ) - - -def logger_auxiliary_signal(logger, nxdata): - """Handle the presence of auxiliary signal""" - aux = nxdata.attrs.get("auxiliary_signals") - if aux is not None: - if isinstance(aux, str): - aux = [aux] - for asig in aux: - logger.debug(f"Further auxiliary signal has been identified: {asig}") - return logger - - -def print_default_plotable_header(logger): - """Print a three-lines header""" - logger.debug("========================") - logger.debug("=== Default Plotable ===") - logger.debug("========================") - - -def get_default_plotable(root, logger): - """Get default plotable""" - print_default_plotable_header(logger) - # v3 from 2014 - # nxentry - nxentry = None - default_nxentry_group_name = root.attrs.get("default") - if default_nxentry_group_name: - try: - nxentry = root[default_nxentry_group_name] - except KeyError: - nxentry = None - if not nxentry: - nxentry = entry_helper(root) - if not nxentry: - logger.debug("No NXentry has been found") - return - logger.debug("") - logger.debug("NXentry has been identified: " + nxentry.name) - # nxdata - nxdata = None - nxgroup = nxentry - default_group_name = nxgroup.attrs.get("default") - while default_group_name: - try: - nxgroup = nxgroup[default_group_name] - default_group_name = nxgroup.attrs.get("default") - except KeyError: - pass - if nxgroup == nxentry: - nxdata = nxdata_helper(nxentry) - else: - nxdata = nxgroup - if not nxdata: - logger.debug("No NXdata group has been found") - return - logger.debug("") - logger.debug("NXdata group has been identified: " + nxdata.name) - process_node(nxdata, nxdata.name, None, logger, False) - # signal - signal = None - signal_dataset_name = nxdata.attrs.get("signal") - try: - signal = nxdata[signal_dataset_name] - except (TypeError, KeyError): - signal = None - if not signal: - signal = signal_helper(nxdata) - if not signal: - logger.debug("No Signal has been found") - return - logger.debug("") - logger.debug("Signal has been identified: " + signal.name) - process_node(signal, signal.name, None, logger, False) - logger = logger_auxiliary_signal(logger, nxdata) # check auxiliary_signals - dim = len(signal.shape) - axes = [] # axes - axis_helper(dim, nxdata, signal, axes, logger) - - -def entry_helper(root): - """Check entry related data""" - nxentries = [] - for key in root.keys(): - if ( - isinstance(root[key], h5py.Group) - and root[key].attrs.get("NX_class") - and root[key].attrs["NX_class"] == "NXentry" - ): - nxentries.append(root[key]) - if len(nxentries) >= 1: - return nxentries[0] - return None - - -def nxdata_helper(nxentry): - """Check if nxentry hdf5 object has a NX_class and, if it contains NXdata, - return its value""" - lnxdata = [] - for key in nxentry.keys(): - if ( - isinstance(nxentry[key], h5py.Group) - and nxentry[key].attrs.get("NX_class") - and nxentry[key].attrs["NX_class"] == "NXdata" - ): - lnxdata.append(nxentry[key]) - if len(lnxdata) >= 1: - return lnxdata[0] - return None - - -def signal_helper(nxdata): - """Check signal related data""" - signals = [] - for key in nxdata.keys(): - if isinstance(nxdata[key], h5py.Dataset): - signals.append(nxdata[key]) - if ( - len(signals) == 1 - ): # v3: as there was no selection given, only 1 data field shall exists - return signals[0] - if len(signals) > 1: # v2: select the one with an attribute signal="1" attribute - for sig in signals: - if ( - sig.attrs.get("signal") - and sig.attrs.get("signal") is str - and sig.attrs.get("signal") == "1" - ): - return sig - return None - - -def find_attrib_axis_actual_dim_num(nxdata, a_item, ax_list): - """Finds axis that have defined dimensions""" - # find those with attribute axis= actual dimension number - lax = [] - for key in nxdata.keys(): - if isinstance(nxdata[key], h5py.Dataset): - try: - if nxdata[key].attrs["axis"] == a_item + 1: - lax.append(nxdata[key]) - except KeyError: - pass - if len(lax) == 1: - ax_list.append(lax[0]) - # if there are more alternatives, prioritise the one with an attribute primary="1" - elif len(lax) > 1: - for sax in lax: - if sax.attrs.get("primary") and sax.attrs.get("primary") == 1: - ax_list.insert(0, sax) - else: - ax_list.append(sax) - - -def get_single_or_multiple_axes(nxdata, ax_datasets, a_item, ax_list): - """Gets either single or multiple axes from the NXDL""" - try: - if isinstance(ax_datasets, str): # single axis is defined - # explicite definition of dimension number - ind = nxdata.attrs.get(ax_datasets + "_indices") - if ind and ind is int: - if ind == a_item: - ax_list.append(nxdata[ax_datasets]) - elif a_item == 0: # positional determination of the dimension number - ax_list.append(nxdata[ax_datasets]) - else: # multiple axes are listed - # explicite definition of dimension number - for aax in ax_datasets: - ind = nxdata.attrs.get(aax + "_indices") - if ind and isinstance(ind, int): - if ind == a_item: - ax_list.append(nxdata[aax]) - if not ax_list: # positional determination of the dimension number - ax_list.append(nxdata[ax_datasets[a_item]]) - except KeyError: - pass - return ax_list - - -def axis_helper(dim, nxdata, signal, axes, logger): - """Check axis related data""" - for a_item in range(dim): - ax_list = [] - ax_datasets = nxdata.attrs.get("axes") # primary axes listed in attribute axes - ax_list = get_single_or_multiple_axes(nxdata, ax_datasets, a_item, ax_list) - for attr in nxdata.attrs.keys(): # check for corresponding AXISNAME_indices - if ( - attr.endswith("_indices") - and nxdata.attrs[attr] == a_item - and nxdata[attr.split("_indices")[0]] not in ax_list - ): - ax_list.append(nxdata[attr.split("_indices")[0]]) - # v2 # check for ':' separated axes defined in Signal - if not ax_list: - try: - ax_datasets = signal.attrs.get("axes").split(":") - ax_list.append(nxdata[ax_datasets[a_item]]) - except (KeyError, AttributeError): - pass - if not ax_list: # check for axis/primary specifications - find_attrib_axis_actual_dim_num(nxdata, a_item, ax_list) - axes.append(ax_list) - logger.debug("") - logger.debug( - f"For Axis #{a_item}, {len(ax_list)} axes have been identified: {str(ax_list)}" - ) - - -def get_all_is_a_rel_from_hdf_node(hdf_node, hdf_path): - """Return list of nxdl concept paths for a nxdl element which corresponds to - hdf node. - """ - hdf_info = {"hdf_path": hdf_path, "hdf_node": hdf_node} - (_, _, elist) = get_inherited_nodes( - None, - nx_name=get_nxdl_entry(hdf_info), - hdf_node=hdf_node, - hdf_path=hdf_info["hdf_path"] if "hdf_path" in hdf_info else None, - hdf_root=hdf_info["hdf_root"] if "hdf_root" in hdf_info else None, - ) - return elist - - -def hdf_node_to_self_concept_path(hdf_info, logger): - """Get concept or nxdl path from given hdf_node.""" - # The bellow logger is for deactivatine unnecessary debug message above - if logger is None: - logger = logging.getLogger(__name__) - logger.setLevel(logging.INFO) - (_, _, nxdl_path) = get_nxdl_doc(hdf_info, logger, None) - con_path = "" - if nxdl_path: - for nd_ in nxdl_path: - con_path = con_path + "/" + get_node_name(nd_) - return con_path - - -class HandleNexus: - """documentation""" - - def __init__(self, logger, nexus_file, d_inq_nd=None, c_inq_nd=None): - self.logger = logger - - if nexus_file is None: - raise ValueError("Nexus file not specified. Cannot proceed.") - - self.input_file_name = nexus_file - self.parser = None - self.in_file = None - self.d_inq_nd = d_inq_nd - self.c_inq_nd = c_inq_nd - # Aggregating hdf path corresponds to concept query node - self.hdf_path_list_for_c_inq_nd = [] - - def visit_node(self, hdf_name, hdf_node): - """Function called by h5py that iterates on each node of hdf5file. - It allows h5py visititems function to visit nodes.""" - if self.d_inq_nd is None and self.c_inq_nd is None: - process_node(hdf_node, "/" + hdf_name, self.parser, self.logger) - elif self.d_inq_nd is not None and hdf_name in ( - self.d_inq_nd, - self.d_inq_nd[1:], - ): - process_node(hdf_node, "/" + hdf_name, self.parser, self.logger) - elif self.c_inq_nd is not None: - attributed_concept = self.c_inq_nd.split("@") - attr = attributed_concept[1] if len(attributed_concept) > 1 else None - elist = get_all_is_a_rel_from_hdf_node(hdf_node, "/" + hdf_name) - if elist is None: - return - fnd_superclass = False - fnd_superclass_attr = False - for elem in reversed(elist): - tmp_path = elem.get("nxdlbase").split(".nxdl")[0] - con_path = "/NX" + tmp_path.split("NX")[-1] + elem.get("nxdlpath") - if fnd_superclass or con_path == attributed_concept[0]: - fnd_superclass = True - if attr is None: - self.hdf_path_list_for_c_inq_nd.append(hdf_name) - break - for attribute in hdf_node.attrs.keys(): - attr_concept = get_nxdl_child( - elem, attribute, nexus_type="attribute", go_base=False - ) - if attr_concept is not None and attr_concept.get( - "nxdlpath" - ).endswith(attr): - fnd_superclass_attr = True - con_path = ( - "/NX" - + tmp_path.split("NX")[-1] - + attr_concept.get("nxdlpath") - ) - self.hdf_path_list_for_c_inq_nd.append( - hdf_name + "@" + attribute - ) - break - if fnd_superclass_attr: - break - - def not_yet_visited(self, root, name): - """checking if a new node has already been visited in its path""" - path = name.split("/") - for i in range(1, len(path)): - act_path = "/".join(path[:i]) - # print(act_path+' - '+name) - if root["/" + act_path] == root["/" + name]: - return False - return True - - def full_visit(self, root, hdf_node, name, func): - """visiting recursivly all children, but avoiding endless cycles""" - # print(name) - if len(name) > 0: - func(name, hdf_node) - if isinstance(hdf_node, h5py.Group): - for ch_name, child in hdf_node.items(): - full_name = ch_name if len(name) == 0 else name + "/" + ch_name - if self.not_yet_visited(root, full_name): - self.full_visit(root, child, full_name, func) - - def process_nexus_master_file(self, parser): - """Process a nexus master file by processing all its nodes and their attributes""" - self.parser = parser - self.in_file = h5py.File( - self.input_file_name[0] - if isinstance(self.input_file_name, list) - else self.input_file_name, - "r", - ) - self.full_visit(self.in_file, self.in_file, "", self.visit_node) - if self.d_inq_nd is None and self.c_inq_nd is None: - get_default_plotable(self.in_file, self.logger) - # To log the provided concept and concepts founded - if self.c_inq_nd is not None: - for hdf_path in self.hdf_path_list_for_c_inq_nd: - self.logger.info(hdf_path) - self.in_file.close() - - -@click.command() -@click.argument( - "nexus_file", -) -@click.option( - "-d", - "--documentation", - required=False, - default=None, - help=( - "Definition path in nexus output (.nxs) file. Returns debug" - "log relavent with that definition path. Example: /entry/data/delays" - ), -) -@click.option( - "-c", - "--concept", - required=False, - default=None, - help=( - "Concept path from application definition file (.nxdl,xml). Finds out" - "all the available concept definition (IS-A realation) for rendered" - "concept path. Example: /NXarpes/ENTRY/INSTRUMENT/analyser" - ), -) -def main(nexus_file, documentation, concept): - """The main function to call when used as a script.""" - logging_format = "%(levelname)s: %(message)s" - stdout_handler = logging.StreamHandler(sys.stdout) - stdout_handler.setLevel(logging.DEBUG) - logging.basicConfig( - level=logging.INFO, format=logging_format, handlers=[stdout_handler] - ) - logger = logging.getLogger(__name__) - logger.addHandler(stdout_handler) - logger.setLevel(logging.DEBUG) - logger.propagate = False - if documentation and concept: - raise ValueError( - "Only one option either documentation (-d) or is_a relation " - "with a concept (-c) can be requested." - ) - nexus_helper = HandleNexus( - logger, nexus_file, d_inq_nd=documentation, c_inq_nd=concept - ) - nexus_helper.process_nexus_master_file(None) - - -if __name__ == "__main__": - main() # pylint: disable=no-value-for-parameter From f2cd2ac51c37bfd4144961cbe1e5ab901fe43303 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Wed, 21 Jun 2023 12:53:20 +0200 Subject: [PATCH 0044/1012] remove dependencies also from pypi configuration --- pyproject.toml | 3 --- requirements.txt | 2 -- 2 files changed, 5 deletions(-) diff --git a/pyproject.toml b/pyproject.toml index d4cf990c86..97430f09bc 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -18,8 +18,6 @@ classifiers = [ dependencies = [ "lxml", "pyyaml", - "click>=7.1.2", - "h5py>=3.6.0", "sphinx>=5", "sphinx-tabs", "pytest", @@ -32,7 +30,6 @@ dependencies = [ "Homepage" = "https://nexusformat.org" [project.scripts] -read_nexus = "dev_tools.utils.nexus:main" [tools.setuptools_scm] version_scheme = "guess-next-dev" diff --git a/requirements.txt b/requirements.txt index bbfd892f76..54b7bb86f8 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1,8 +1,6 @@ # Prepare for Documentation lxml pyyaml -click>=7.1.2 -h5py>=3.6.0 # Documentation building sphinx>=5 From aabf43ba356c2e55aa57169d424b8ef846099266 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Wed, 21 Jun 2023 16:20:06 +0200 Subject: [PATCH 0045/1012] added sphinx-toolbox --- pyproject.toml | 1 + 1 file changed, 1 insertion(+) diff --git a/pyproject.toml b/pyproject.toml index 97430f09bc..979c51eac0 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -20,6 +20,7 @@ dependencies = [ "pyyaml", "sphinx>=5", "sphinx-tabs", + "sphinx-toolbox", "pytest", "black>=22.3", "flake8>=4", From c510daebaaca5477d5f2a37a335cf97b8bf3cb3e Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Wed, 21 Jun 2023 17:20:14 +0200 Subject: [PATCH 0046/1012] collapsing is deactivated for this PR --- dev_tools/docs/nxdl.py | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/dev_tools/docs/nxdl.py b/dev_tools/docs/nxdl.py index 4c36ef2775..d35c01fa44 100644 --- a/dev_tools/docs/nxdl.py +++ b/dev_tools/docs/nxdl.py @@ -517,9 +517,9 @@ def _print_doc_enum(self, indent, ns, node, required=False): collapse_indent = indent node_list = node.xpath("nx:enumeration", namespaces=ns) (doclen, line, blocks) = self.long_doc(ns, node) - if len(node_list) + doclen > 1: - collapse_indent = f"{indent} " - self._print(f"{indent}{self._INDENTATION_UNIT}.. collapse:: {line} ...\n") + # if len(node_list) + doclen > 1: + # collapse_indent = f"{indent} " + # self._print(f"{indent}{self._INDENTATION_UNIT}.. collapse:: {line} ...\n") self._print_doc( collapse_indent + self._INDENTATION_UNIT, ns, node, required=required ) From 9240450e1ea88fbe528fd4b8c912f0f441dd7e07 Mon Sep 17 00:00:00 2001 From: Sherjeel Shabih Date: Wed, 5 Jul 2023 15:09:03 +0200 Subject: [PATCH 0047/1012] Move all of nyaml2nxdl files in a folder --- README.md => dev_tools/nyaml2nxdl/README.md | 0 __init__.py => dev_tools/nyaml2nxdl/__init__.py | 0 comment_collector.py => dev_tools/nyaml2nxdl/comment_collector.py | 0 nyaml2nxdl.py => dev_tools/nyaml2nxdl/nyaml2nxdl.py | 0 .../nyaml2nxdl/nyaml2nxdl_backward_tools.py | 0 .../nyaml2nxdl/nyaml2nxdl_forward_tools.py | 0 nyaml2nxdl_helper.py => dev_tools/nyaml2nxdl/nyaml2nxdl_helper.py | 0 7 files changed, 0 insertions(+), 0 deletions(-) rename README.md => dev_tools/nyaml2nxdl/README.md (100%) rename __init__.py => dev_tools/nyaml2nxdl/__init__.py (100%) rename comment_collector.py => dev_tools/nyaml2nxdl/comment_collector.py (100%) rename nyaml2nxdl.py => dev_tools/nyaml2nxdl/nyaml2nxdl.py (100%) rename nyaml2nxdl_backward_tools.py => dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py (100%) rename nyaml2nxdl_forward_tools.py => dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py (100%) rename nyaml2nxdl_helper.py => dev_tools/nyaml2nxdl/nyaml2nxdl_helper.py (100%) diff --git a/README.md b/dev_tools/nyaml2nxdl/README.md similarity index 100% rename from README.md rename to dev_tools/nyaml2nxdl/README.md diff --git a/__init__.py b/dev_tools/nyaml2nxdl/__init__.py similarity index 100% rename from __init__.py rename to dev_tools/nyaml2nxdl/__init__.py diff --git a/comment_collector.py b/dev_tools/nyaml2nxdl/comment_collector.py similarity index 100% rename from comment_collector.py rename to dev_tools/nyaml2nxdl/comment_collector.py diff --git a/nyaml2nxdl.py b/dev_tools/nyaml2nxdl/nyaml2nxdl.py similarity index 100% rename from nyaml2nxdl.py rename to dev_tools/nyaml2nxdl/nyaml2nxdl.py diff --git a/nyaml2nxdl_backward_tools.py b/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py similarity index 100% rename from nyaml2nxdl_backward_tools.py rename to dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py diff --git a/nyaml2nxdl_forward_tools.py b/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py similarity index 100% rename from nyaml2nxdl_forward_tools.py rename to dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py diff --git a/nyaml2nxdl_helper.py b/dev_tools/nyaml2nxdl/nyaml2nxdl_helper.py similarity index 100% rename from nyaml2nxdl_helper.py rename to dev_tools/nyaml2nxdl/nyaml2nxdl_helper.py From 666203a6a2ae3b41821820181d8140f97b749526 Mon Sep 17 00:00:00 2001 From: Sherjeel Shabih Date: Wed, 5 Jul 2023 15:31:07 +0200 Subject: [PATCH 0048/1012] Moving test to correct folder for nexus definitions repo --- README.md | 5 ----- test_nyaml2nxdl.py => dev_tools/tests/test_nyaml2nxdl.py | 0 2 files changed, 5 deletions(-) delete mode 100644 README.md rename test_nyaml2nxdl.py => dev_tools/tests/test_nyaml2nxdl.py (100%) diff --git a/README.md b/README.md deleted file mode 100644 index 7a71982697..0000000000 --- a/README.md +++ /dev/null @@ -1,5 +0,0 @@ -This is the place for storing code for tests of the yaml2nxdl and nxdl2yaml NeXus schema translation routines. - -## Contact person in FAIRmat for these tests -1. Rubel Mozumder -2. Andrea Albino \ No newline at end of file diff --git a/test_nyaml2nxdl.py b/dev_tools/tests/test_nyaml2nxdl.py similarity index 100% rename from test_nyaml2nxdl.py rename to dev_tools/tests/test_nyaml2nxdl.py From ff05cb5b6147e2eb8e0c44892b93abb46107d82b Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Mon, 19 Jun 2023 15:01:41 +0200 Subject: [PATCH 0049/1012] linting --- dev_tools/nyaml2nxdl/comment_collector.py | 199 ++-- dev_tools/nyaml2nxdl/nyaml2nxdl.py | 206 +++-- .../nyaml2nxdl/nyaml2nxdl_backward_tools.py | 645 +++++++------ .../nyaml2nxdl/nyaml2nxdl_forward_tools.py | 854 ++++++++++-------- dev_tools/nyaml2nxdl/nyaml2nxdl_helper.py | 85 +- 5 files changed, 1100 insertions(+), 889 deletions(-) diff --git a/dev_tools/nyaml2nxdl/comment_collector.py b/dev_tools/nyaml2nxdl/comment_collector.py index 5f0c5e3bce..dcb21021be 100644 --- a/dev_tools/nyaml2nxdl/comment_collector.py +++ b/dev_tools/nyaml2nxdl/comment_collector.py @@ -31,10 +31,16 @@ """ -from typing import List, Type, Any, Tuple, Union, Dict +from typing import Any +from typing import Dict +from typing import List +from typing import Tuple +from typing import Type +from typing import Union + from pynxtools.nyaml2nxdl.nyaml2nxdl_helper import LineLoader -__all__ = ['Comment', 'CommentCollector', 'XMLComment', 'YAMLComment'] +__all__ = ["Comment", "CommentCollector", "XMLComment", "YAMLComment"] # pylint: disable=inconsistent-return-statements @@ -43,8 +49,7 @@ class CommentCollector: _comment_chain. """ - def __init__(self, input_file: str = None, - loaded_obj: Union[object, Dict] = None): + def __init__(self, input_file: str = None, loaded_obj: Union[object, Dict] = None): """ Initialise CommentCollector parameters: @@ -57,19 +62,21 @@ def __init__(self, input_file: str = None, self._comment_hash: Dict[Tuple, Type[Comment]] = {} self.comment: Type[Comment] if self.file and not loaded_obj: - if self.file.split('.')[-1] == 'xml': + if self.file.split(".")[-1] == "xml": self.comment = XMLComment - if self.file.split('.')[-1] == 'yaml': + if self.file.split(".")[-1] == "yaml": self.comment = YAMLComment with open(self.file, "r", encoding="utf-8") as plain_text_yaml: loader = LineLoader(plain_text_yaml) self.comment.__yaml_dict__ = loader.get_single_data() elif self.file and loaded_obj: - if self.file.split('.')[-1] == 'yaml' and isinstance(loaded_obj, dict): + if self.file.split(".")[-1] == "yaml" and isinstance(loaded_obj, dict): self.comment = YAMLComment self.comment.__yaml_dict__ = loaded_obj else: - raise ValueError("Incorrect inputs for CommentCollector e.g. Wrong file extension.") + raise ValueError( + "Incorrect inputs for CommentCollector e.g. Wrong file extension." + ) else: raise ValueError("Incorrect inputs for CommentCollector") @@ -81,18 +88,20 @@ def extract_all_comment_blocks(self): """ id_ = 0 single_comment = self.comment(comment_id=id_) - with open(self.file, mode='r', encoding='UTF-8') as enc_f: + with open(self.file, mode="r", encoding="UTF-8") as enc_f: lines = enc_f.readlines() # Make an empty line for last comment if no empty lines in original file - if lines[-1] != '': - lines.append('') + if lines[-1] != "": + lines.append("") for line_num, line in enumerate(lines): if single_comment.is_storing_single_comment(): # If the last comment comes without post nxdl fields, groups and attributes - if '++ SHA HASH ++' in line: + if "++ SHA HASH ++" in line: # Handle with stored nxdl.xml file that is not part of yaml - line = '' - single_comment.process_each_line(line + 'post_comment', (line_num + 1)) + line = "" + single_comment.process_each_line( + line + "post_comment", (line_num + 1) + ) self._comment_chain.append(single_comment) break if line_num < (len(lines) - 1): @@ -100,7 +109,9 @@ def extract_all_comment_blocks(self): single_comment.process_each_line(line, (line_num + 1)) else: # For processing last line of file - single_comment.process_each_line(line + 'post_comment', (line_num + 1)) + single_comment.process_each_line( + line + "post_comment", (line_num + 1) + ) self._comment_chain.append(single_comment) else: self._comment_chain.append(single_comment) @@ -109,13 +120,13 @@ def extract_all_comment_blocks(self): def get_comment(self): """ - Return comment from comment_chain that must come earlier in order. + Return comment from comment_chain that must come earlier in order. """ return self._comment_chain[self._comment_tracker] def get_coment_by_line_info(self, comment_locs: Tuple[str, Union[int, str]]): """ - Get comment using line information. + Get comment using line information. """ if comment_locs in self._comment_hash: return self._comment_hash[comment_locs] @@ -129,8 +140,7 @@ def get_coment_by_line_info(self, comment_locs: Tuple[str, Union[int, str]]): return cmnt def remove_comment(self, ind): - """Remove a comment from comment list. - """ + """Remove a comment from comment list.""" if ind < len(self._comment_chain): del self._comment_chain[ind] else: @@ -150,8 +160,10 @@ def __contains__(self, comment_locs: tuple): (__line__doc and 35) """ if not isinstance(comment_locs, tuple): - raise TypeError("Comment_locs should be 'tuple' containing line annotation " - "(e.g.__line__doc) and line_loc (e.g. 35).") + raise TypeError( + "Comment_locs should be 'tuple' containing line annotation " + "(e.g.__line__doc) and line_loc (e.g. 35)." + ) line_annot, line_loc = comment_locs for cmnt in self._comment_chain: if line_annot in cmnt: @@ -162,11 +174,12 @@ def __contains__(self, comment_locs: tuple): return False def __getitem__(self, ind): - """Get comment from self.obj._comment_chain by index. - """ + """Get comment from self.obj._comment_chain by index.""" if isinstance(ind, int): if ind >= len(self._comment_chain): - raise IndexError(f'Oops! Comment index {ind} in {__class__} is out of range!') + raise IndexError( + f"Oops! Comment index {ind} in {__class__} is out of range!" + ) return self._comment_chain[ind] if isinstance(ind, slice): @@ -175,8 +188,7 @@ def __getitem__(self, ind): return self._comment_chain[start_n:end_n] def __iter__(self): - """get comment ieratively - """ + """get comment ieratively""" return iter(self._comment_chain) @@ -186,21 +198,19 @@ class Comment: This class is building yaml comment and the intended line for what comment is written. """ - def __init__(self, - comment_id: int = -1, - last_comment: 'Comment' = None) -> None: + def __init__(self, comment_id: int = -1, last_comment: "Comment" = None) -> None: """Comment object can be considered as a block element that includes - document element (an entity for what the comment is written). + document element (an entity for what the comment is written). """ self._elemt: Any = None self._elemt_text: str = None self._is_elemt_found: bool = None self._is_elemt_stored: bool = None - self._comnt: str = '' + self._comnt: str = "" # If Multiple comments for one element or entity self._comnt_list: List[str] = [] - self.last_comment: 'Comment' = last_comment if last_comment else None + self.last_comment: "Comment" = last_comment if last_comment else None if comment_id >= 0 and last_comment: self.cid = comment_id self.last_comment = last_comment @@ -214,8 +224,9 @@ def __init__(self, raise ValueError("Neither last comment nor comment id dound") self._comnt_start_found: bool = False self._comnt_end_found: bool = False - self.is_storing_single_comment = lambda: not (self._comnt_end_found - and self._is_elemt_stored) + self.is_storing_single_comment = lambda: not ( + self._comnt_end_found and self._is_elemt_stored + ) def get_comment_text(self) -> Union[List, str]: """ @@ -239,7 +250,7 @@ class XMLComment(Comment): XMLComment to store xml comment element. """ - def __init__(self, comment_id: int = -1, last_comment: 'Comment' = None) -> None: + def __init__(self, comment_id: int = -1, last_comment: "Comment" = None) -> None: super().__init__(comment_id, last_comment) def process_each_line(self, text, line_num): @@ -253,76 +264,77 @@ def process_each_line(self, text, line_num): # for multiple comment if exist if self._comnt: self._comnt_list.append(self._comnt) - self._comnt = '' + self._comnt = "" if self._comnt_end_found: self.store_element(text) def append_comment(self, text: str) -> None: # Comment in single line - if '' == text[-4:]: + self._comnt = self._comnt + text.replace("" == text[-4:]: self._comnt_end_found = True self._comnt_start_found = False - self._comnt = self._comnt.replace('-->', '') + self._comnt = self._comnt.replace("-->", "") - elif '-->' == text[0:4] and self._comnt_start_found: + elif "-->" == text[0:4] and self._comnt_start_found: self._comnt_end_found = True self._comnt_start_found = False - self._comnt = self._comnt + '\n' + text.replace('-->', '') + self._comnt = self._comnt + "\n" + text.replace("-->", "") elif self._comnt_start_found: - self._comnt = self._comnt + '\n' + text + self._comnt = self._comnt + "\n" + text # pylint: disable=arguments-differ, arguments-renamed def store_element(self, text) -> None: def collect_xml_attributes(text_part): for part in text_part: part = part.strip() - if part and '">' == ''.join(part[-2:]): + if part and '">' == "".join(part[-2:]): self._is_elemt_stored = True self._is_elemt_found = False - part = ''.join(part[0:-2]) - elif part and '"/>' == ''.join(part[-3:]): + part = "".join(part[0:-2]) + elif part and '"/>' == "".join(part[-3:]): self._is_elemt_stored = True self._is_elemt_found = False - part = ''.join(part[0:-3]) - elif part and '/>' == ''.join(part[-2:]): + part = "".join(part[0:-3]) + elif part and "/>" == "".join(part[-2:]): self._is_elemt_stored = True self._is_elemt_found = False - part = ''.join(part[0:-2]) - elif part and '>' == part[-1]: + part = "".join(part[0:-2]) + elif part and ">" == part[-1]: self._is_elemt_stored = True self._is_elemt_found = False - part = ''.join(part[0:-1]) + part = "".join(part[0:-1]) elif part and '"' == part[-1]: - part = ''.join(part[0:-1]) + part = "".join(part[0:-1]) if '="' in part: lf_prt, rt_prt = part.split('="') else: continue - if ':' in lf_prt: + if ":" in lf_prt: continue self._elemt[lf_prt] = str(rt_prt) + if not self._elemt: self._elemt = {} # First check for comment part has been collected prefectly - if ' Union[List, str]: """ - This method returns list of commnent text. As some xml element might have - multiple separated comment intended for a single element. + This method returns list of commnent text. As some xml element might have + multiple separated comment intended for a single element. """ return self._comnt_list @@ -348,17 +360,19 @@ class YAMLComment(Comment): 1. Do not delete any element form yaml dictionary (for loaded_obj. check: Comment_collector class. because this loaded file has been exploited in nyaml2nxdl forward tools.) """ + # Class level variable. The main reason behind that to follow structure of # abstract class 'Comment' __yaml_dict__: dict = {} __yaml_line_info: dict = {} - __comment_escape_char = {'--': '-\\-'} + __comment_escape_char = {"--": "-\\-"} - def __init__(self, comment_id: int = -1, last_comment: 'Comment' = None) -> None: - """Initialization of YAMLComment follow Comment class. - """ + def __init__(self, comment_id: int = -1, last_comment: "Comment" = None) -> None: + """Initialization of YAMLComment follow Comment class.""" super().__init__(comment_id, last_comment) - self.collect_yaml_line_info(YAMLComment.__yaml_dict__, YAMLComment.__yaml_line_info) + self.collect_yaml_line_info( + YAMLComment.__yaml_dict__, YAMLComment.__yaml_line_info + ) def process_each_line(self, text, line_num): """Take care of each line of text. Through which function the text @@ -369,21 +383,21 @@ def process_each_line(self, text, line_num): if self._comnt_end_found and not self._is_elemt_found: if self._comnt: self._comnt_list.append(self._comnt) - self._comnt = '' + self._comnt = "" if self._comnt_end_found: - line_key = '' - if ':' in text: - ind = text.index(':') - line_key = '__line__' + ''.join(text[0:ind]) + line_key = "" + if ":" in text: + ind = text.index(":") + line_key = "__line__" + "".join(text[0:ind]) for l_num, l_key in self.__yaml_line_info.items(): if line_num == int(l_num) and line_key == l_key: self.store_element(line_key, line_num) break # Comment comes very end of the file - if text == 'post_comment' and line_key == '': - line_key = '__line__post_comment' + if text == "post_comment" and line_key == "": + line_key = "__line__post_comment" self.store_element(line_key, line_num) def has_post_comment(self): @@ -393,7 +407,7 @@ def has_post_comment(self): nxdl element(class, group, filed and attribute.) """ for key, _ in self._elemt.items(): - if '__line__post_comment' == key: + if "__line__post_comment" == key: return True return False @@ -411,17 +425,17 @@ def append_comment(self, text: str) -> None: # For empty line inside doc or yaml file. elif not text: return - elif '# ' == ''.join(text[0:2]): + elif "# " == "".join(text[0:2]): self._comnt_start_found = True self._comnt_end_found = False - self._comnt = '' if not self._comnt else self._comnt + '\n' - self._comnt = self._comnt + ''.join(text[2:]) - elif '#' == text[0]: + self._comnt = "" if not self._comnt else self._comnt + "\n" + self._comnt = self._comnt + "".join(text[2:]) + elif "#" == text[0]: self._comnt_start_found = True self._comnt_end_found = False - self._comnt = '' if not self._comnt else self._comnt + '\n' - self._comnt = self._comnt + ''.join(text[1:]) - elif 'post_comment' == text: + self._comnt = "" if not self._comnt else self._comnt + "\n" + self._comnt = self._comnt + "".join(text[1:]) + elif "post_comment" == text: self._comnt_end_found = True self._comnt_start_found = False # for any line after 'comment block' found @@ -432,8 +446,8 @@ def append_comment(self, text: str) -> None: # pylint: disable=arguments-differ def store_element(self, line_key, line_number): """ - Store comment content and information of commen location (for what comment is - created.). + Store comment content and information of commen location (for what comment is + created.). """ self._elemt = {} self._elemt[line_key] = int(line_number) @@ -454,14 +468,13 @@ def get_line_number(self, line_key): def get_line_info(self): """ - Return line annotation and line number from a comment. + Return line annotation and line number from a comment. """ for line_anno, line_loc in self._elemt.items(): return line_anno, line_loc def replace_scape_char(self, text): - """Replace escape char according to __comment_escape_char dict - """ + """Replace escape char according to __comment_escape_char dict""" for ecp_char, ecp_alt in YAMLComment.__comment_escape_char.items(): if ecp_char in text: text = text.replace(ecp_char, ecp_alt) @@ -472,8 +485,7 @@ def get_element_location(self): Retrun yaml line '__line__KEY' info and and line numner """ if len(self._elemt) > 1: - raise ValueError(f"Comment element should be one but got " - f"{self._elemt}") + raise ValueError(f"Comment element should be one but got " f"{self._elemt}") for key, val in self._elemt.items(): yield key, val @@ -483,7 +495,7 @@ def collect_yaml_line_info(self, yaml_dict, line_info_dict): a yaml file dictonary in another dictionary. """ for line_key, line_n in yaml_dict.items(): - if '__line__' in line_key: + if "__line__" in line_key: line_info_dict[line_n] = line_key for _, val in yaml_dict.items(): @@ -495,13 +507,12 @@ def __contains__(self, line_key): return line_key in self._elemt def __eq__(self, comment_obj): - """Check the self has same value as right comment. - """ + """Check the self has same value as right comment.""" if len(self._comnt_list) != len(comment_obj._comnt_list): return False for left_cmnt, right_cmnt in zip(self._comnt_list, comment_obj._comnt_list): - left_cmnt = left_cmnt.split('\n') - right_cmnt = right_cmnt.split('\n') + left_cmnt = left_cmnt.split("\n") + right_cmnt = right_cmnt.split("\n") for left_line, right_line in zip(left_cmnt, right_cmnt): if left_line.strip() != right_line.strip(): return False diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl.py b/dev_tools/nyaml2nxdl/nyaml2nxdl.py index 160b3f830d..815b015e62 100755 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl.py +++ b/dev_tools/nyaml2nxdl/nyaml2nxdl.py @@ -26,13 +26,13 @@ import xml.etree.ElementTree as ET import click -from pynxtools.nyaml2nxdl.nyaml2nxdl_helper import (get_sha256_hash, - extend_yamlfile_with_comment, - separate_hash_yaml_and_nxdl) -from pynxtools.nyaml2nxdl.nyaml2nxdl_forward_tools import nyaml2nxdl, pretty_print_xml -from pynxtools.nyaml2nxdl.nyaml2nxdl_backward_tools import (Nxdl2yaml, - compare_niac_and_my) - +from pynxtools.nyaml2nxdl.nyaml2nxdl_backward_tools import Nxdl2yaml +from pynxtools.nyaml2nxdl.nyaml2nxdl_backward_tools import compare_niac_and_my +from pynxtools.nyaml2nxdl.nyaml2nxdl_forward_tools import nyaml2nxdl +from pynxtools.nyaml2nxdl.nyaml2nxdl_forward_tools import pretty_print_xml +from pynxtools.nyaml2nxdl.nyaml2nxdl_helper import extend_yamlfile_with_comment +from pynxtools.nyaml2nxdl.nyaml2nxdl_helper import get_sha256_hash +from pynxtools.nyaml2nxdl.nyaml2nxdl_helper import separate_hash_yaml_and_nxdl DEPTH_SIZE = 4 * " " @@ -42,13 +42,13 @@ def generate_nxdl_or_retrieve_nxdl(yaml_file, out_xml_file, verbose): """ - Generate yaml, nxdl and hash. - if the extracted hash is exactly the same as producd from generated yaml then - retrieve the nxdl part from provided yaml. - Else, generate nxdl from separated yaml with the help of nyaml2nxdl function + Generate yaml, nxdl and hash. + if the extracted hash is exactly the same as producd from generated yaml then + retrieve the nxdl part from provided yaml. + Else, generate nxdl from separated yaml with the help of nyaml2nxdl function """ pa_path, rel_file = os.path.split(yaml_file) - sep_yaml = os.path.join(pa_path, f'temp_{rel_file}') + sep_yaml = os.path.join(pa_path, f"temp_{rel_file}") hash_found = separate_hash_yaml_and_nxdl(yaml_file, sep_yaml, out_xml_file) if hash_found: @@ -67,67 +67,84 @@ def append_yml(input_file, append, verbose): and print both an XML and YML file of the extended base class. """ - nexus_def_path = os.path.join(os.path.abspath(os.path.dirname(__file__)), '../../definitions') - assert [s for s in os.listdir(os.path.join(nexus_def_path, 'base_classes') - ) if append.strip() == s.replace('.nxdl.xml', '')], \ - 'Your base class extension does not match any existing NeXus base classes' - tree = ET.parse(os.path.join(nexus_def_path + '/base_classes', append + '.nxdl.xml')) + nexus_def_path = os.path.join( + os.path.abspath(os.path.dirname(__file__)), "../../definitions" + ) + assert [ + s + for s in os.listdir(os.path.join(nexus_def_path, "base_classes")) + if append.strip() == s.replace(".nxdl.xml", "") + ], "Your base class extension does not match any existing NeXus base classes" + tree = ET.parse( + os.path.join(nexus_def_path + "/base_classes", append + ".nxdl.xml") + ) root = tree.getroot() # warning: tmp files are printed on disk and removed at the ends!! - pretty_print_xml(root, 'tmp.nxdl.xml') - input_tmp_xml = 'tmp.nxdl.xml' - out_tmp_yml = 'tmp_parsed.yaml' + pretty_print_xml(root, "tmp.nxdl.xml") + input_tmp_xml = "tmp.nxdl.xml" + out_tmp_yml = "tmp_parsed.yaml" converter = Nxdl2yaml([], []) converter.print_yml(input_tmp_xml, out_tmp_yml, verbose) - nyaml2nxdl(input_file=out_tmp_yml, - out_file='tmp_parsed.nxdl.xml', - verbose=verbose) - tree = ET.parse('tmp_parsed.nxdl.xml') + nyaml2nxdl(input_file=out_tmp_yml, out_file="tmp_parsed.nxdl.xml", verbose=verbose) + tree = ET.parse("tmp_parsed.nxdl.xml") tree2 = ET.parse(input_file) root_no_duplicates = ET.Element( - 'definition', {'xmlns': 'http://definition.nexusformat.org/nxdl/3.1', - 'xmlns:xsi': 'http://www.w3.org/2001/XMLSchema-instance', - 'xsi:schemaLocation': 'http://www.w3.org/2001/XMLSchema-instance' - } + "definition", + { + "xmlns": "http://definition.nexusformat.org/nxdl/3.1", + "xmlns:xsi": "http://www.w3.org/2001/XMLSchema-instance", + "xsi:schemaLocation": "http://www.w3.org/2001/XMLSchema-instance", + }, ) for attribute_keys in root.attrib.keys(): - if attribute_keys != '{http://www.w3.org/2001/XMLSchema-instance}schemaLocation': + if ( + attribute_keys + != "{http://www.w3.org/2001/XMLSchema-instance}schemaLocation" + ): attribute_value = root.attrib[attribute_keys] root_no_duplicates.set(attribute_keys, attribute_value) for elems in root.iter(): - if 'doc' in elems.tag: - root_doc = ET.SubElement(root_no_duplicates, 'doc') + if "doc" in elems.tag: + root_doc = ET.SubElement(root_no_duplicates, "doc") root_doc.text = elems.text break - group = '{http://definition.nexusformat.org/nxdl/3.1}group' - root_no_duplicates = compare_niac_and_my(tree, tree2, verbose, - group, - root_no_duplicates) - field = '{http://definition.nexusformat.org/nxdl/3.1}field' - root_no_duplicates = compare_niac_and_my(tree, tree2, verbose, - field, - root_no_duplicates) - attribute = '{http://definition.nexusformat.org/nxdl/3.1}attribute' - root_no_duplicates = compare_niac_and_my(tree, tree2, verbose, - attribute, - root_no_duplicates) - pretty_print_xml(root_no_duplicates, f"{input_file.replace('.nxdl.xml', '')}" - f"_appended.nxdl.xml") - - input_file_xml = input_file.replace('.nxdl.xml', "_appended.nxdl.xml") - out_file_yml = input_file.replace('.nxdl.xml', "_appended_parsed.yaml") + group = "{http://definition.nexusformat.org/nxdl/3.1}group" + root_no_duplicates = compare_niac_and_my( + tree, tree2, verbose, group, root_no_duplicates + ) + field = "{http://definition.nexusformat.org/nxdl/3.1}field" + root_no_duplicates = compare_niac_and_my( + tree, tree2, verbose, field, root_no_duplicates + ) + attribute = "{http://definition.nexusformat.org/nxdl/3.1}attribute" + root_no_duplicates = compare_niac_and_my( + tree, tree2, verbose, attribute, root_no_duplicates + ) + pretty_print_xml( + root_no_duplicates, + f"{input_file.replace('.nxdl.xml', '')}" f"_appended.nxdl.xml", + ) + + input_file_xml = input_file.replace(".nxdl.xml", "_appended.nxdl.xml") + out_file_yml = input_file.replace(".nxdl.xml", "_appended_parsed.yaml") converter = Nxdl2yaml([], []) converter.print_yml(input_file_xml, out_file_yml, verbose) - nyaml2nxdl(input_file=out_file_yml, - out_file=out_file_yml.replace('.yaml', '.nxdl.xml'), - verbose=verbose) - os.rename(f"{input_file.replace('.nxdl.xml', '_appended_parsed.yaml')}", - f"{input_file.replace('.nxdl.xml', '_appended.yaml')}") - os.rename(f"{input_file.replace('.nxdl.xml', '_appended_parsed.nxdl.xml')}", - f"{input_file.replace('.nxdl.xml', '_appended.nxdl.xml')}") - os.remove('tmp.nxdl.xml') - os.remove('tmp_parsed.yaml') - os.remove('tmp_parsed.nxdl.xml') + nyaml2nxdl( + input_file=out_file_yml, + out_file=out_file_yml.replace(".yaml", ".nxdl.xml"), + verbose=verbose, + ) + os.rename( + f"{input_file.replace('.nxdl.xml', '_appended_parsed.yaml')}", + f"{input_file.replace('.nxdl.xml', '_appended.yaml')}", + ) + os.rename( + f"{input_file.replace('.nxdl.xml', '_appended_parsed.nxdl.xml')}", + f"{input_file.replace('.nxdl.xml', '_appended.nxdl.xml')}", + ) + os.remove("tmp.nxdl.xml") + os.remove("tmp_parsed.yaml") + os.remove("tmp_parsed.nxdl.xml") def split_name_and_extension(file_name): @@ -135,93 +152,98 @@ def split_name_and_extension(file_name): Split file name into extension and rest of the file name. return file raw nam and extension """ - parts = file_name.rsplit('.', 3) + parts = file_name.rsplit(".", 3) if len(parts) == 2: raw = parts[0] ext = parts[1] if len(parts) == 3: raw = parts[0] - ext = '.'.join(parts[1:]) + ext = ".".join(parts[1:]) return raw, ext @click.command() @click.option( - '--input-file', + "--input-file", required=True, prompt=True, - help='The path to the XML or YAML input data file to read and create \ -a YAML or XML file from, respectively.' + help="The path to the XML or YAML input data file to read and create \ +a YAML or XML file from, respectively.", ) @click.option( - '--append', - help='Parse xml file and append to base class, given that the xml file has same name \ -of an existing base class' + "--append", + help="Parse xml file and append to base class, given that the xml file has same name \ +of an existing base class", ) @click.option( - '--check-consistency', + "--check-consistency", is_flag=True, default=False, - help=('Check wether yaml or nxdl has followed general rules of scema or not' - 'check whether your comment in the right place or not. The option render an ' - 'output file of the same extension(*_consistency.yaml or *_consistency.nxdl.xml)') + help=( + "Check wether yaml or nxdl has followed general rules of scema or not" + "check whether your comment in the right place or not. The option render an " + "output file of the same extension(*_consistency.yaml or *_consistency.nxdl.xml)" + ), ) @click.option( - '--verbose', + "--verbose", is_flag=True, default=False, - help='Print in standard output keywords and value types to help \ -possible issues in yaml files' + help="Print in standard output keywords and value types to help \ +possible issues in yaml files", ) def launch_tool(input_file, verbose, append, check_consistency): """ - Main function that distiguishes the input file format and launches the tools. + Main function that distiguishes the input file format and launches the tools. """ if os.path.isfile(input_file): raw_name, ext = split_name_and_extension(input_file) else: raise ValueError("Need a valid input file.") - if ext == 'yaml': - xml_out_file = raw_name + '.nxdl.xml' + if ext == "yaml": + xml_out_file = raw_name + ".nxdl.xml" generate_nxdl_or_retrieve_nxdl(input_file, xml_out_file, verbose) if append: - append_yml(raw_name + '.nxdl.xml', - append, - verbose - ) + append_yml(raw_name + ".nxdl.xml", append, verbose) # For consistency running if check_consistency: - yaml_out_file = raw_name + '_consistency.' + ext + yaml_out_file = raw_name + "_consistency." + ext converter = Nxdl2yaml([], []) converter.print_yml(xml_out_file, yaml_out_file, verbose) os.remove(xml_out_file) - elif ext == 'nxdl.xml': + elif ext == "nxdl.xml": if not append: - yaml_out_file = raw_name + '_parsed' + '.yaml' + yaml_out_file = raw_name + "_parsed" + ".yaml" converter = Nxdl2yaml([], []) converter.print_yml(input_file, yaml_out_file, verbose) # Append nxdl.xml file with yaml output file yaml_hash = get_sha256_hash(yaml_out_file) # Lines as divider between yaml and nxdl - top_lines = [('\n# ++++++++++++++++++++++++++++++++++ SHA HASH' - ' ++++++++++++++++++++++++++++++++++\n'), - f'# {yaml_hash}\n'] - - extend_yamlfile_with_comment(yaml_file=yaml_out_file, - file_to_be_appended=input_file, - top_lines_list=top_lines) + top_lines = [ + ( + "\n# ++++++++++++++++++++++++++++++++++ SHA HASH" + " ++++++++++++++++++++++++++++++++++\n" + ), + f"# {yaml_hash}\n", + ] + + extend_yamlfile_with_comment( + yaml_file=yaml_out_file, + file_to_be_appended=input_file, + top_lines_list=top_lines, + ) else: append_yml(input_file, append, verbose) # Taking care of consistency running if check_consistency: - xml_out_file = raw_name + '_consistency.' + ext + xml_out_file = raw_name + "_consistency." + ext generate_nxdl_or_retrieve_nxdl(yaml_out_file, xml_out_file, verbose) os.remove(yaml_out_file) else: raise ValueError("Provide correct file with extension '.yaml or '.nxdl.xml") -if __name__ == '__main__': +if __name__ == "__main__": launch_tool().parse() # pylint: disable=no-value-for-parameter diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py b/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py index 72f5a6c426..faa22cc23e 100755 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py +++ b/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py @@ -2,6 +2,8 @@ """This file collects the function used in the reverse tool nxdl2yaml. """ +import os + # -*- coding: utf-8 -*- # # Copyright The NOMAD Authors. @@ -21,18 +23,17 @@ # limitations under the License. # import sys -from typing import List, Dict import xml.etree.ElementTree as ET -import os +from typing import Dict +from typing import List -from pynxtools.nyaml2nxdl.nyaml2nxdl_helper import (get_node_parent_info, - get_yaml_escape_char_dict, - cleaning_empty_lines) from pynxtools.dataconverter.helpers import remove_namespace_from_tag - +from pynxtools.nyaml2nxdl.nyaml2nxdl_helper import cleaning_empty_lines +from pynxtools.nyaml2nxdl.nyaml2nxdl_helper import get_node_parent_info +from pynxtools.nyaml2nxdl.nyaml2nxdl_helper import get_yaml_escape_char_dict DEPTH_SIZE = " " -CMNT_TAG = '!--' +CMNT_TAG = "!--" def separate_pi_comments(input_file): @@ -43,24 +44,24 @@ def separate_pi_comments(input_file): comment = [] xml_lines = [] - with open(input_file, "r", encoding='utf-8') as file: + with open(input_file, "r", encoding="utf-8") as file: lines = file.readlines() has_pi = True for line in lines: - c_start = '' - def_tag = ' 0 and has_pi: - comment.append(line.replace(cmnt_end, '')) - comments_list.append(''.join(comment)) + comment.append(line.replace(cmnt_end, "")) + comments_list.append("".join(comment)) comment = [] elif def_tag in line or not has_pi: has_pi = False @@ -69,25 +70,24 @@ def separate_pi_comments(input_file): comment.append(line) else: xml_lines.append(line) - return comments_list, ''.join(xml_lines) + return comments_list, "".join(xml_lines) # Collected: https://dustinoprea.com/2019/01/22/python-parsing-xml-and-retaining-the-comments/ class _CommentedTreeBuilder(ET.TreeBuilder): - def comment(self, text): """ defining comment builder in TreeBuilder """ - self.start('!--', {}) + self.start("!--", {}) self.data(text) - self.end('--') + self.end("--") def parse(filepath): """ - Construct parse function for modified tree builder for including modified TreeBuilder - and rebuilding XMLParser. + Construct parse function for modified tree builder for including modified TreeBuilder + and rebuilding XMLParser. """ comments, xml_str = separate_pi_comments(filepath) ctb = _CommentedTreeBuilder() @@ -97,7 +97,7 @@ def parse(filepath): def handle_mapping_char(text, depth=-1, skip_n_line_on_top=False): - """Check for ":" char and replace it by "':'". """ + """Check for ":" char and replace it by "':'".""" escape_char = get_yaml_escape_char_dict() for esc_key, val in escape_char.items(): @@ -119,23 +119,23 @@ def add_new_line_with_pipe_on_top(text, depth): char_list_to_add_new_line_on_top_of_text = [":"] for char in char_list_to_add_new_line_on_top_of_text: if char in text: - return '|' + '\n' + depth * DEPTH_SIZE + text + return "|" + "\n" + depth * DEPTH_SIZE + text return text # pylint: disable=too-many-instance-attributes -class Nxdl2yaml(): +class Nxdl2yaml: """ - Parse XML file and print a YML file + Parse XML file and print a YML file """ def __init__( - self, - symbol_list: List[str], - root_level_definition: List[str], - root_level_doc='', - root_level_symbols=''): - + self, + symbol_list: List[str], + root_level_definition: List[str], + root_level_doc="", + root_level_symbols="", + ): # updated part of yaml_dict self.found_definition = False self.root_level_doc = root_level_doc @@ -157,7 +157,7 @@ def __init__( def print_yml(self, input_file, output_yml, verbose): """ - Parse an XML file provided as input and print a YML file + Parse an XML file provided as input and print a YML file """ if os.path.isfile(output_yml): os.remove(output_yml) @@ -165,7 +165,7 @@ def print_yml(self, input_file, output_yml, verbose): depth = 0 self.pi_comments, root = parse(input_file) - xml_tree = {'tree': root, 'node': root} + xml_tree = {"tree": root, "node": root} self.xmlparse(output_yml, xml_tree, depth, verbose) def handle_symbols(self, depth, node): @@ -177,47 +177,55 @@ def handle_symbols(self, depth, node): f"{node.text.strip() if node.text else ''}" ) depth += 1 - last_comment = '' + last_comment = "" sbl_doc_cmnt_list = [] # Comments that come above symbol tag symbol_cmnt_list = [] for child in list(node): tag = remove_namespace_from_tag(child.tag) if tag == CMNT_TAG and self.include_comment: - last_comment = self.comvert_to_ymal_comment(depth * DEPTH_SIZE, child.text) - if tag == 'doc': + last_comment = self.comvert_to_ymal_comment( + depth * DEPTH_SIZE, child.text + ) + if tag == "doc": symbol_cmnt_list.append(last_comment) # The bellow line is for handling lenth of 'symbol_comments' and # 'symbol_doc_comments'. Otherwise print_root_level_info() gets inconsistency # over for the loop while writting comment on file - sbl_doc_cmnt_list.append('') - last_comment = '' - self.symbol_list.append(self.handle_not_root_level_doc(depth, - text=child.text)) - elif tag == 'symbol': + sbl_doc_cmnt_list.append("") + last_comment = "" + self.symbol_list.append( + self.handle_not_root_level_doc(depth, text=child.text) + ) + elif tag == "symbol": # place holder is symbol name symbol_cmnt_list.append(last_comment) - last_comment = '' - if 'doc' in child.attrib: + last_comment = "" + if "doc" in child.attrib: self.symbol_list.append( - self.handle_not_root_level_doc(depth, - tag=child.attrib['name'], - text=child.attrib['doc'])) + self.handle_not_root_level_doc( + depth, tag=child.attrib["name"], text=child.attrib["doc"] + ) + ) else: for symbol_doc in list(child): tag = remove_namespace_from_tag(symbol_doc.tag) if tag == CMNT_TAG and self.include_comment: - last_comment = self.comvert_to_ymal_comment(depth * DEPTH_SIZE, - symbol_doc.text) - if tag == 'doc': + last_comment = self.comvert_to_ymal_comment( + depth * DEPTH_SIZE, symbol_doc.text + ) + if tag == "doc": sbl_doc_cmnt_list.append(last_comment) - last_comment = '' + last_comment = "" self.symbol_list.append( - self.handle_not_root_level_doc(depth, - tag=child.attrib['name'], - text=symbol_doc.text)) - self.store_root_level_comments('symbol_doc_comments', sbl_doc_cmnt_list) - self.store_root_level_comments('symbol_comments', symbol_cmnt_list) + self.handle_not_root_level_doc( + depth, + tag=child.attrib["name"], + text=symbol_doc.text, + ) + ) + self.store_root_level_comments("symbol_doc_comments", sbl_doc_cmnt_list) + self.store_root_level_comments("symbol_comments", symbol_cmnt_list) def store_root_level_comments(self, holder, comment): """Store yaml text or section line and the comments inteded for that lines or section""" @@ -226,13 +234,13 @@ def store_root_level_comments(self, holder, comment): def handle_definition(self, node): """ - Handle definition group and its attributes - NOTE: Here we tried to store the order of the xml element attributes. So that we get - exactly the same file in nxdl from yaml. + Handle definition group and its attributes + NOTE: Here we tried to store the order of the xml element attributes. So that we get + exactly the same file in nxdl from yaml. """ # pylint: disable=consider-using-f-string # self.root_level_definition[0] = '' - keyword = '' + keyword = "" # tmp_word for reseving the location tmp_word = "#xx#" attribs = node.attrib @@ -249,15 +257,14 @@ def handle_definition(self, node): if keyword_order == -1: self.root_level_definition.append(tmp_word) keyword_order = self.root_level_definition.index(tmp_word) - elif 'schemaLocation' not in item \ - and 'extends' != item: + elif "schemaLocation" not in item and "extends" != item: text = f"{item}: {attribs[item]}" self.root_level_definition.append(text) self.root_level_definition[keyword_order] = f"{keyword}:" def handle_root_level_doc(self, node): """ - Handle the documentation field found at root level. + Handle the documentation field found at root level. """ # tag = remove_namespace_from_tag(node.tag) text = node.text @@ -265,7 +272,7 @@ def handle_root_level_doc(self, node): self.root_level_doc = text # pylint: disable=too-many-branches - def handle_not_root_level_doc(self, depth, text, tag='doc', file_out=None): + def handle_not_root_level_doc(self, depth, text, tag="doc", file_out=None): """ Handle docs field along the yaml file. In this function we also tried to keep the track of intended indentation. E.g. the bollow doc block. @@ -280,7 +287,7 @@ def handle_not_root_level_doc(self, depth, text, tag='doc', file_out=None): text = handle_mapping_char(text, -1, True) if "\n" in text: # To remove '\n' character as it will be added before text. - text = cleaning_empty_lines(text.split('\n')) + text = cleaning_empty_lines(text.split("\n")) text_tmp = [] yaml_indent_n = len((depth + 1) * DEPTH_SIZE) # Find indentaion in the first text line with alphabet @@ -288,12 +295,12 @@ def handle_not_root_level_doc(self, depth, text, tag='doc', file_out=None): while tmp_i != -1: first_line_indent_n = 0 # Taking care of empty text whitout any character - if len(text) == 1 and text[0] == '': + if len(text) == 1 and text[0] == "": break for ch_ in text[tmp_i]: - if ch_ == ' ': + if ch_ == " ": first_line_indent_n = first_line_indent_n + 1 - elif ch_ != '': + elif ch_ != "": tmp_i = -2 break tmp_i = tmp_i + 1 @@ -314,23 +321,23 @@ def handle_not_root_level_doc(self, depth, text, tag='doc', file_out=None): line_indent_n = 0 # Collect first empty space without alphabate for ch_ in line: - if ch_ == ' ': + if ch_ == " ": line_indent_n = line_indent_n + 1 else: break line_indent_n = line_indent_n + indent_diff if line_indent_n < yaml_indent_n: # if line still under yaml identation - text_tmp.append(yaml_indent_n * ' ' + line.strip()) + text_tmp.append(yaml_indent_n * " " + line.strip()) else: - text_tmp.append(line_indent_n * ' ' + line.strip()) + text_tmp.append(line_indent_n * " " + line.strip()) - text = '\n' + '\n'.join(text_tmp) + text = "\n" + "\n".join(text_tmp) if "}" in tag: tag = remove_namespace_from_tag(tag) indent = depth * DEPTH_SIZE elif text: - text = '\n' + (depth + 1) * DEPTH_SIZE + text.strip() + text = "\n" + (depth + 1) * DEPTH_SIZE + text.strip() if "}" in tag: tag = remove_namespace_from_tag(tag) indent = depth * DEPTH_SIZE @@ -360,31 +367,33 @@ def print_root_level_doc(self, file_out): """ indent = 0 * DEPTH_SIZE - if ('root_doc' in self.root_level_comment - and self.root_level_comment['root_doc'] != ''): - text = self.root_level_comment['root_doc'] + if ( + "root_doc" in self.root_level_comment + and self.root_level_comment["root_doc"] != "" + ): + text = self.root_level_comment["root_doc"] self.write_out(indent, text, file_out) text = self.root_level_doc self.write_out(indent, text, file_out) - self.root_level_doc = '' + self.root_level_doc = "" def comvert_to_ymal_comment(self, indent, text): """ - Convert into yaml comment by adding exta '#' char in front of comment lines + Convert into yaml comment by adding exta '#' char in front of comment lines """ - lines = text.split('\n') + lines = text.split("\n") mod_lines = [] for line in lines: line = line.strip() - if line and line[0] != '#': - line = indent + '# ' + line + if line and line[0] != "#": + line = indent + "# " + line mod_lines.append(line) elif line: line = indent + line mod_lines.append(line) # The starting '\n' to keep multiple comments separate - return '\n' + '\n'.join(mod_lines) + return "\n" + "\n".join(mod_lines) def print_root_level_info(self, depth, file_out): """ @@ -403,40 +412,58 @@ def print_root_level_info(self, depth, file_out): has_categoty = True if not has_categoty: - raise ValueError("Definition dose not get any category from 'base or application'.") + raise ValueError( + "Definition dose not get any category from 'base or application'." + ) self.print_root_level_doc(file_out) - if 'symbols' in self.root_level_comment and self.root_level_comment['symbols'] != '': + if ( + "symbols" in self.root_level_comment + and self.root_level_comment["symbols"] != "" + ): indent = depth * DEPTH_SIZE - text = self.root_level_comment['symbols'] + text = self.root_level_comment["symbols"] self.write_out(indent, text, file_out) if self.root_level_symbols: - self.write_out(indent=0 * DEPTH_SIZE, text=self.root_level_symbols, file_out=file_out) + self.write_out( + indent=0 * DEPTH_SIZE, text=self.root_level_symbols, file_out=file_out + ) # symbol_list include 'symbols doc', and all 'symbol' for ind, symbol in enumerate(self.symbol_list): # Taking care of comments that come on to of 'symbols doc' and 'symbol' - if 'symbol_comments' in self.root_level_comment and \ - self.root_level_comment['symbol_comments'][ind] != '': + if ( + "symbol_comments" in self.root_level_comment + and self.root_level_comment["symbol_comments"][ind] != "" + ): indent = depth * DEPTH_SIZE - self.write_out(indent, - self.root_level_comment['symbol_comments'][ind], file_out) - if 'symbol_doc_comments' in self.root_level_comment and \ - self.root_level_comment['symbol_doc_comments'][ind] != '': - + self.write_out( + indent, + self.root_level_comment["symbol_comments"][ind], + file_out, + ) + if ( + "symbol_doc_comments" in self.root_level_comment + and self.root_level_comment["symbol_doc_comments"][ind] != "" + ): indent = depth * DEPTH_SIZE - self.write_out(indent, - self.root_level_comment['symbol_doc_comments'][ind], file_out) + self.write_out( + indent, + self.root_level_comment["symbol_doc_comments"][ind], + file_out, + ) self.write_out(indent=(0 * DEPTH_SIZE), text=symbol, file_out=file_out) if len(self.pi_comments) > 1: indent = DEPTH_SIZE * depth # The first comment is top level copy-right doc string for comment in self.pi_comments[1:]: - self.write_out(indent, self.comvert_to_ymal_comment(indent, comment), file_out) + self.write_out( + indent, self.comvert_to_ymal_comment(indent, comment), file_out + ) if self.root_level_definition: # Soring NXname for writting end of the definition attributes - nx_name = '' + nx_name = "" for defs in self.root_level_definition: - if 'NX' in defs and defs[-1] == ':': + if "NX" in defs and defs[-1] == ":": nx_name = defs continue if defs in ("category: application", "category: base"): @@ -447,55 +474,77 @@ def print_root_level_info(self, depth, file_out): def handle_exists(self, exists_dict, key, val): """ - Create exist component as folows: + Create exist component as folows: - {'min' : value for min, - 'max' : value for max, - 'optional' : value for optional} + {'min' : value for min, + 'max' : value for max, + 'optional' : value for optional} - This is created separately so that the keys stays in order. + This is created separately so that the keys stays in order. """ if not val: - val = '' + val = "" else: val = str(val) - if 'minOccurs' == key: - exists_dict['minOccurs'] = ['min', val] - if 'maxOccurs' == key: - exists_dict['maxOccurs'] = ['max', val] - if 'optional' == key: - exists_dict['optional'] = ['optional', val] - if 'recommended' == key: - exists_dict['recommended'] = ['recommended', val] - if 'required' == key: - exists_dict['required'] = ['required', val] + if "minOccurs" == key: + exists_dict["minOccurs"] = ["min", val] + if "maxOccurs" == key: + exists_dict["maxOccurs"] = ["max", val] + if "optional" == key: + exists_dict["optional"] = ["optional", val] + if "recommended" == key: + exists_dict["recommended"] = ["recommended", val] + if "required" == key: + exists_dict["required"] = ["required", val] # pylint: disable=too-many-branches, consider-using-f-string def handle_group_or_field(self, depth, node, file_out): """Handle all the possible attributes that come along a field or group""" - allowed_attr = ['optional', 'recommended', 'name', 'type', 'axes', 'axis', 'data_offset', - 'interpretation', 'long_name', 'maxOccurs', 'minOccurs', 'nameType', - 'optional', 'primary', 'signal', 'stride', 'units', 'required', - 'deprecated', 'exists'] + allowed_attr = [ + "optional", + "recommended", + "name", + "type", + "axes", + "axis", + "data_offset", + "interpretation", + "long_name", + "maxOccurs", + "minOccurs", + "nameType", + "optional", + "primary", + "signal", + "stride", + "units", + "required", + "deprecated", + "exists", + ] name_type = "" node_attr = node.attrib rm_key_list = [] # Maintain order: name and type in form name(type) or (type)name that come first for key, val in node_attr.items(): - if key == 'name': + if key == "name": name_type = name_type + val rm_key_list.append(key) - if key == 'type': + if key == "type": name_type = name_type + "(%s)" % val rm_key_list.append(key) if not name_type: - raise ValueError(f"No 'name' or 'type' hase been found. But, 'group' or 'field' " - f"must have at list a nme.We got attributes: {node_attr}") - file_out.write('{indent}{name_type}:\n'.format( - indent=depth * DEPTH_SIZE, - name_type=name_type)) + raise ValueError( + f"No 'name' or 'type' hase been found. But, 'group' or 'field' " + f"must have at list a nme.We got attributes: {node_attr}" + ) + file_out.write( + "{indent}{name_type}:\n".format( + indent=depth * DEPTH_SIZE, name_type=name_type + ) + ) for key in rm_key_list: del node_attr[key] @@ -505,31 +554,35 @@ def handle_group_or_field(self, depth, node, file_out): exists_dict = {} for key, val in node_attr.items(): # As both 'minOccurs', 'maxOccurs' and optionality move to the 'exists' - if key in ['minOccurs', 'maxOccurs', 'optional', 'recommended', 'required']: - if 'exists' not in tmp_dict: - tmp_dict['exists'] = [] + if key in ["minOccurs", "maxOccurs", "optional", "recommended", "required"]: + if "exists" not in tmp_dict: + tmp_dict["exists"] = [] self.handle_exists(exists_dict, key, val) - elif key == 'units': - tmp_dict['unit'] = str(val) + elif key == "units": + tmp_dict["unit"] = str(val) else: tmp_dict[key] = str(val) if key not in allowed_attr: - raise ValueError(f"An attribute ({key}) in 'field' or 'group' has been found " - f"that is not allowed. The allowed attr is {allowed_attr}.") + raise ValueError( + f"An attribute ({key}) in 'field' or 'group' has been found " + f"that is not allowed. The allowed attr is {allowed_attr}." + ) if exists_dict: for key, val in exists_dict.items(): - if key in ['minOccurs', 'maxOccurs']: - tmp_dict['exists'] = tmp_dict['exists'] + val - elif key in ['optional', 'recommended', 'required']: - tmp_dict['exists'] = key + if key in ["minOccurs", "maxOccurs"]: + tmp_dict["exists"] = tmp_dict["exists"] + val + elif key in ["optional", "recommended", "required"]: + tmp_dict["exists"] = key depth_ = depth + 1 for key, val in tmp_dict.items(): # Increase depth size inside handle_map...() for writting text with one # more indentation. - file_out.write(f'{depth_ * DEPTH_SIZE}{key}: ' - f'{handle_mapping_char(val, depth_ + 1, False)}\n') + file_out.write( + f"{depth_ * DEPTH_SIZE}{key}: " + f"{handle_mapping_char(val, depth_ + 1, False)}\n" + ) # pylint: disable=too-many-branches, too-many-locals def handle_dimension(self, depth, node, file_out): @@ -540,33 +593,35 @@ def handle_dimension(self, depth, node, file_out): and attributes of dim has been handled inside this function here. """ # pylint: disable=consider-using-f-string - possible_dim_attrs = ['ref', 'required', - 'incr', 'refindex'] - possible_dimemsion_attrs = ['rank'] + possible_dim_attrs = ["ref", "required", "incr", "refindex"] + possible_dimemsion_attrs = ["rank"] # taking care of Dimension tag file_out.write( - '{indent}{tag}:\n'.format( - indent=depth * DEPTH_SIZE, - tag=node.tag.split("}", 1)[1])) + "{indent}{tag}:\n".format( + indent=depth * DEPTH_SIZE, tag=node.tag.split("}", 1)[1] + ) + ) # Taking care of dimension attributes for attr, value in node.attrib.items(): if attr in possible_dimemsion_attrs and not isinstance(value, dict): indent = (depth + 1) * DEPTH_SIZE - file_out.write(f'{indent}{attr}: {value}\n') + file_out.write(f"{indent}{attr}: {value}\n") else: - raise ValueError(f"Dimension has got an attribute {attr} that is not valid." - f"Current the allowd atributes are {possible_dimemsion_attrs}." - f" Please have a look") + raise ValueError( + f"Dimension has got an attribute {attr} that is not valid." + f"Current the allowd atributes are {possible_dimemsion_attrs}." + f" Please have a look" + ) # taking carew of dimension doc for child in list(node): tag = remove_namespace_from_tag(child.tag) - if tag == 'doc': + if tag == "doc": text = self.handle_not_root_level_doc(depth + 1, child.text) file_out.write(text) node.remove(child) - dim_index_value = '' + dim_index_value = "" dim_other_parts = {} dim_cmnt_node = [] # taking care of dim and doc childs of dimension @@ -574,11 +629,12 @@ def handle_dimension(self, depth, node, file_out): tag = remove_namespace_from_tag(child.tag) child_attrs = child.attrib # taking care of index and value attributes - if tag == ('dim'): + if tag == ("dim"): # taking care of index and value in format [[index, value]] - dim_index_value = dim_index_value + '[{index}, {value}], '.format( - index=child_attrs['index'] if "index" in child_attrs else '', - value=child_attrs['value'] if "value" in child_attrs else '') + dim_index_value = dim_index_value + "[{index}, {value}], ".format( + index=child_attrs["index"] if "index" in child_attrs else "", + value=child_attrs["value"] if "value" in child_attrs else "", + ) if "index" in child_attrs: del child_attrs["index"] if "value" in child_attrs: @@ -587,7 +643,7 @@ def handle_dimension(self, depth, node, file_out): # Taking care of doc comes as child of dim for cchild in list(child): ttag = cchild.tag.split("}", 1)[1] - if ttag == ('doc'): + if ttag == ("doc"): if ttag not in dim_other_parts: dim_other_parts[ttag] = [] text = cchild.text @@ -612,25 +668,30 @@ def handle_dimension(self, depth, node, file_out): self.handel_comment(depth + 1, ch_nd, file_out) # index and value attributes of dim elements file_out.write( - '{indent}dim: [{value}]\n'.format( - indent=(depth + 1) * DEPTH_SIZE, - value=dim_index_value[:-2] or '')) + "{indent}dim: [{value}]\n".format( + indent=(depth + 1) * DEPTH_SIZE, value=dim_index_value[:-2] or "" + ) + ) # Write the attributes, except index and value, and doc of dim as child of dim_parameter. # But tthe doc or attributes for each dim come inside list according to the order of dim. if dim_other_parts: file_out.write( - '{indent}dim_parameters:\n'.format( - indent=(depth + 1) * DEPTH_SIZE)) + "{indent}dim_parameters:\n".format(indent=(depth + 1) * DEPTH_SIZE) + ) # depth = depth + 2 dim_paramerter has child such as doc of dim indent = (depth + 2) * DEPTH_SIZE for key, value in dim_other_parts.items(): - if key == 'doc': - value = self.handle_not_root_level_doc(depth + 2, str(value), key, file_out) + if key == "doc": + value = self.handle_not_root_level_doc( + depth + 2, str(value), key, file_out + ) else: # Increase depth size inside handle_map...() for writting text with one # more indentation. - file_out.write(f"{indent}{key}: " - f"{handle_mapping_char(value, depth + 3, False)}\n") + file_out.write( + f"{indent}{key}: " + f"{handle_mapping_char(value, depth + 3, False)}\n" + ) def handle_enumeration(self, depth, node, file_out): """ @@ -642,7 +703,7 @@ def handle_enumeration(self, depth, node, file_out): If no doc are inherited in the enumeration items, a list of the items is given for the enumeration list. - """ + """ # pylint: disable=consider-using-f-string check_doc = [] @@ -652,37 +713,46 @@ def handle_enumeration(self, depth, node, file_out): # pylint: disable=too-many-nested-blocks if check_doc: file_out.write( - '{indent}{tag}: \n'.format( - indent=depth * DEPTH_SIZE, - tag=node.tag.split("}", 1)[1])) + "{indent}{tag}: \n".format( + indent=depth * DEPTH_SIZE, tag=node.tag.split("}", 1)[1] + ) + ) for child in list(node): tag = remove_namespace_from_tag(child.tag) itm_depth = depth + 1 - if tag == ('item'): + if tag == ("item"): file_out.write( - '{indent}{value}: \n'.format( - indent=(itm_depth) * DEPTH_SIZE, - value=child.attrib['value'])) + "{indent}{value}: \n".format( + indent=(itm_depth) * DEPTH_SIZE, value=child.attrib["value"] + ) + ) if list(child): for item_doc in list(child): - if remove_namespace_from_tag(item_doc.tag) == 'doc': + if remove_namespace_from_tag(item_doc.tag) == "doc": item_doc_depth = itm_depth + 1 - self.handle_not_root_level_doc(item_doc_depth, item_doc.text, - item_doc.tag, file_out) - if (remove_namespace_from_tag(item_doc.tag) == CMNT_TAG - and self.include_comment): + self.handle_not_root_level_doc( + item_doc_depth, + item_doc.text, + item_doc.tag, + file_out, + ) + if ( + remove_namespace_from_tag(item_doc.tag) == CMNT_TAG + and self.include_comment + ): self.handel_comment(itm_depth + 1, item_doc, file_out) if tag == CMNT_TAG and self.include_comment: self.handel_comment(itm_depth + 1, child, file_out) else: - enum_list = '' + enum_list = "" remove_nodes = [] for item_child in list(node): tag = remove_namespace_from_tag(item_child.tag) - if tag == ('item'): - enum_list = enum_list + '{value}, '.format( - value=item_child.attrib['value']) + if tag == ("item"): + enum_list = enum_list + "{value}, ".format( + value=item_child.attrib["value"] + ) if tag == CMNT_TAG and self.include_comment: self.handel_comment(depth, item_child, file_out) remove_nodes.append(item_child) @@ -690,134 +760,162 @@ def handle_enumeration(self, depth, node, file_out): node.remove(ch_node) file_out.write( - '{indent}{tag}: [{enum_list}]\n'.format( + "{indent}{tag}: [{enum_list}]\n".format( indent=depth * DEPTH_SIZE, tag=remove_namespace_from_tag(node.tag), - enum_list=enum_list[:-2] or '')) + enum_list=enum_list[:-2] or "", + ) + ) def handle_attributes(self, depth, node, file_out): """Handle the attributes parsed from the xml file""" - allowed_attr = ['name', 'type', 'units', 'nameType', 'recommended', 'optional', - 'minOccurs', 'maxOccurs', 'deprecated'] + allowed_attr = [ + "name", + "type", + "units", + "nameType", + "recommended", + "optional", + "minOccurs", + "maxOccurs", + "deprecated", + ] name = "" node_attr = node.attrib - if 'name' in node_attr: + if "name" in node_attr: pass else: raise ValueError("Attribute must have an name key.") rm_key_list = [] # Maintain order: name and type in form name(type) or (type)name that come first for key, val in node_attr.items(): - if key == 'name': + if key == "name": name = val rm_key_list.append(key) for key in rm_key_list: del node_attr[key] - file_out.write('{indent}{escapesymbol}{name}:\n'.format( - indent=depth * DEPTH_SIZE, - escapesymbol=r'\@', - name=name)) + file_out.write( + "{indent}{escapesymbol}{name}:\n".format( + indent=depth * DEPTH_SIZE, escapesymbol=r"\@", name=name + ) + ) tmp_dict = {} exists_dict = {} for key, val in node_attr.items(): # As both 'minOccurs', 'maxOccurs' and optionality move to the 'exists' - if key in ['minOccurs', 'maxOccurs', 'optional', 'recommended', 'required']: - if 'exists' not in tmp_dict: - tmp_dict['exists'] = [] + if key in ["minOccurs", "maxOccurs", "optional", "recommended", "required"]: + if "exists" not in tmp_dict: + tmp_dict["exists"] = [] self.handle_exists(exists_dict, key, val) - elif key == 'units': - tmp_dict['unit'] = val + elif key == "units": + tmp_dict["unit"] = val else: tmp_dict[key] = val if key not in allowed_attr: - raise ValueError(f"An attribute ({key}) has been found that is not allowed." - f"The allowed attr is {allowed_attr}.") + raise ValueError( + f"An attribute ({key}) has been found that is not allowed." + f"The allowed attr is {allowed_attr}." + ) has_min_max = False has_opt_reco_requ = False if exists_dict: for key, val in exists_dict.items(): - if key in ['minOccurs', 'maxOccurs']: - tmp_dict['exists'] = tmp_dict['exists'] + val + if key in ["minOccurs", "maxOccurs"]: + tmp_dict["exists"] = tmp_dict["exists"] + val has_min_max = True - elif key in ['optional', 'recommended', 'required']: - tmp_dict['exists'] = key + elif key in ["optional", "recommended", "required"]: + tmp_dict["exists"] = key has_opt_reco_requ = True if has_min_max and has_opt_reco_requ: - raise ValueError("Optionality 'exists' can take only either from ['minOccurs'," - " 'maxOccurs'] or from ['optional', 'recommended', 'required']" - ". But not from both of the groups together. Please check in" - " attributes") + raise ValueError( + "Optionality 'exists' can take only either from ['minOccurs'," + " 'maxOccurs'] or from ['optional', 'recommended', 'required']" + ". But not from both of the groups together. Please check in" + " attributes" + ) depth_ = depth + 1 for key, val in tmp_dict.items(): # Increase depth size inside handle_map...() for writting text with one # more indentation. - file_out.write(f'{depth_ * DEPTH_SIZE}{key}: ' - f'{handle_mapping_char(val, depth_ + 1, False)}\n') + file_out.write( + f"{depth_ * DEPTH_SIZE}{key}: " + f"{handle_mapping_char(val, depth_ + 1, False)}\n" + ) def handel_link(self, depth, node, file_out): """ - Handle link elements of nxdl + Handle link elements of nxdl """ - possible_link_attrs = ['name', 'target', 'napimount'] + possible_link_attrs = ["name", "target", "napimount"] node_attr = node.attrib # Handle special cases - if 'name' in node_attr: - file_out.write('{indent}{name}(link):\n'.format( - indent=depth * DEPTH_SIZE, - name=node_attr['name'] or '')) - del node_attr['name'] + if "name" in node_attr: + file_out.write( + "{indent}{name}(link):\n".format( + indent=depth * DEPTH_SIZE, name=node_attr["name"] or "" + ) + ) + del node_attr["name"] depth_ = depth + 1 # Handle general cases for attr_key, val in node_attr.items(): if attr_key in possible_link_attrs: - file_out.write('{indent}{attr}: {value}\n'.format( - indent=depth_ * DEPTH_SIZE, - attr=attr_key, - value=val)) + file_out.write( + "{indent}{attr}: {value}\n".format( + indent=depth_ * DEPTH_SIZE, attr=attr_key, value=val + ) + ) else: - raise ValueError(f"An anexpected attribute '{attr_key}' of link has found." - f"At this moment the alloed keys are {possible_link_attrs}") + raise ValueError( + f"An anexpected attribute '{attr_key}' of link has found." + f"At this moment the alloed keys are {possible_link_attrs}" + ) def handel_choice(self, depth, node, file_out): """ - Handle choice element which is a parent node of group. + Handle choice element which is a parent node of group. """ possible_attr = [] node_attr = node.attrib # Handle special casees - if 'name' in node_attr: - file_out.write('{indent}{attr}(choice): \n'.format( - indent=depth * DEPTH_SIZE, - attr=node_attr['name'])) - del node_attr['name'] + if "name" in node_attr: + file_out.write( + "{indent}{attr}(choice): \n".format( + indent=depth * DEPTH_SIZE, attr=node_attr["name"] + ) + ) + del node_attr["name"] depth_ = depth + 1 # Taking care of general attrinutes. Though, still no attrinutes have found, # but could be used for future for attr in node_attr.items(): if attr in possible_attr: - file_out.write('{indent}{attr}: {value}\n'.format( - indent=depth_ * DEPTH_SIZE, - attr=attr, - value=node_attr[attr])) + file_out.write( + "{indent}{attr}: {value}\n".format( + indent=depth_ * DEPTH_SIZE, attr=attr, value=node_attr[attr] + ) + ) else: - raise ValueError(f"An unexpected attribute '{attr}' of 'choice' has been found." - f"At this moment attributes for choice {possible_attr}") + raise ValueError( + f"An unexpected attribute '{attr}' of 'choice' has been found." + f"At this moment attributes for choice {possible_attr}" + ) def handel_comment(self, depth, node, file_out): """ - Collect comment element and pass to write_out function + Collect comment element and pass to write_out function """ indent = depth * DEPTH_SIZE if self.is_last_element_comment: @@ -834,10 +932,10 @@ def recursion_in_xml_tree(self, depth, xml_tree, output_yml, verbose): behaviour is not triggered as we already handled the symbols' childs. """ - tree = xml_tree['tree'] - node = xml_tree['node'] + tree = xml_tree["tree"] + node = xml_tree["node"] for child in list(node): - xml_tree_children = {'tree': tree, 'node': child} + xml_tree_children = {"tree": tree, "node": child} self.xmlparse(output_yml, xml_tree_children, depth, verbose) # pylint: disable=too-many-branches, too-many-statements @@ -846,63 +944,65 @@ def xmlparse(self, output_yml, xml_tree, depth, verbose): Main of the nxdl2yaml converter. It parses XML tree, then prints recursively each level of the tree """ - tree = xml_tree['tree'] - node = xml_tree['node'] + tree = xml_tree["tree"] + node = xml_tree["node"] if verbose: - sys.stdout.write(f'Node tag: {remove_namespace_from_tag(node.tag)}\n') - sys.stdout.write(f'Attributes: {node.attrib}\n') + sys.stdout.write(f"Node tag: {remove_namespace_from_tag(node.tag)}\n") + sys.stdout.write(f"Attributes: {node.attrib}\n") with open(output_yml, "a", encoding="utf-8") as file_out: tag = remove_namespace_from_tag(node.tag) - if tag == 'definition': + if tag == "definition": self.found_definition = True self.handle_definition(node) # Taking care of root level doc and symbols remove_cmnt_n = None - last_comment = '' + last_comment = "" for child in list(node): tag_tmp = remove_namespace_from_tag(child.tag) if tag_tmp == CMNT_TAG and self.include_comment: - last_comment = self.comvert_to_ymal_comment(depth * DEPTH_SIZE, child.text) + last_comment = self.comvert_to_ymal_comment( + depth * DEPTH_SIZE, child.text + ) remove_cmnt_n = child - if tag_tmp == 'doc': - self.store_root_level_comments('root_doc', last_comment) - last_comment = '' + if tag_tmp == "doc": + self.store_root_level_comments("root_doc", last_comment) + last_comment = "" self.handle_root_level_doc(child) node.remove(child) if remove_cmnt_n is not None: node.remove(remove_cmnt_n) remove_cmnt_n = None - if tag_tmp == 'symbols': - self.store_root_level_comments('symbols', last_comment) - last_comment = '' + if tag_tmp == "symbols": + self.store_root_level_comments("symbols", last_comment) + last_comment = "" self.handle_symbols(depth, child) node.remove(child) if remove_cmnt_n is not None: node.remove(remove_cmnt_n) remove_cmnt_n = None - if tag == ('doc') and depth != 1: + if tag == ("doc") and depth != 1: parent = get_node_parent_info(tree, node)[0] doc_parent = remove_namespace_from_tag(parent.tag) - if doc_parent != 'item': - self.handle_not_root_level_doc(depth, text=node.text, - tag=node.tag, - file_out=file_out) + if doc_parent != "item": + self.handle_not_root_level_doc( + depth, text=node.text, tag=node.tag, file_out=file_out + ) if self.found_definition is True and self.root_level_doc: self.print_root_level_info(depth, file_out) # End of print root-level definitions in file - if tag in ('field', 'group') and depth != 0: + if tag in ("field", "group") and depth != 0: self.handle_group_or_field(depth, node, file_out) - if tag == ('enumeration'): + if tag == ("enumeration"): self.handle_enumeration(depth, node, file_out) - if tag == ('attribute'): + if tag == ("attribute"): self.handle_attributes(depth, node, file_out) - if tag == ('dimensions'): + if tag == ("dimensions"): self.handle_dimension(depth, node, file_out) - if tag == ('link'): + if tag == ("link"): self.handel_link(depth, node, file_out) - if tag == ('choice'): + if tag == ("choice"): self.handel_choice(depth, node, file_out) if tag == CMNT_TAG and self.include_comment: self.handel_comment(depth, node, file_out) @@ -913,24 +1013,23 @@ def xmlparse(self, output_yml, xml_tree, depth, verbose): def compare_niac_and_my(tree, tree2, verbose, node, root_no_duplicates): """This function creates two trees with Niac XML file and My XML file. -The main aim is to compare the two trees and create a new one that is the -union of the two initial trees. - -""" + The main aim is to compare the two trees and create a new one that is the + union of the two initial trees. + """ root = tree.getroot() root2 = tree2.getroot() attrs_list_niac = [] for nodo in root.iter(node): attrs_list_niac.append(nodo.attrib) if verbose: - sys.stdout.write('Attributes found in Niac file: \n') - sys.stdout.write(str(attrs_list_niac) + '\n') - sys.stdout.write(' \n') - sys.stdout.write('Started merging of Niac and My file... \n') + sys.stdout.write("Attributes found in Niac file: \n") + sys.stdout.write(str(attrs_list_niac) + "\n") + sys.stdout.write(" \n") + sys.stdout.write("Started merging of Niac and My file... \n") for elem in root.iter(node): if verbose: - sys.stdout.write('- Niac element inserted: \n') - sys.stdout.write(str(elem.attrib) + '\n') + sys.stdout.write("- Niac element inserted: \n") + sys.stdout.write(str(elem.attrib) + "\n") index = get_node_parent_info(tree, elem)[1] root_no_duplicates.insert(index, elem) @@ -938,10 +1037,10 @@ def compare_niac_and_my(tree, tree2, verbose, node, root_no_duplicates): index = get_node_parent_info(tree2, elem2)[1] if elem2.attrib not in attrs_list_niac: if verbose: - sys.stdout.write('- My element inserted: \n') - sys.stdout.write(str(elem2.attrib) + '\n') + sys.stdout.write("- My element inserted: \n") + sys.stdout.write(str(elem2.attrib) + "\n") root_no_duplicates.insert(index, elem2) if verbose: - sys.stdout.write(' \n') + sys.stdout.write(" \n") return root_no_duplicates diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py b/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py index db4d4c4644..ca0435e374 100644 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py +++ b/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py @@ -21,65 +21,67 @@ # limitations under the License. # +import os import sys +import textwrap import xml.etree.ElementTree as ET from xml.dom import minidom -import os -import textwrap import yaml - +from pynxtools.dataconverter.helpers import remove_namespace_from_tag from pynxtools.nexus import nexus from pynxtools.nyaml2nxdl.comment_collector import CommentCollector -from pynxtools.dataconverter.helpers import remove_namespace_from_tag -from pynxtools.nyaml2nxdl.nyaml2nxdl_helper import (get_yaml_escape_char_reverter_dict, - nx_name_type_resolving, - cleaning_empty_lines, LineLoader) - +from pynxtools.nyaml2nxdl.nyaml2nxdl_helper import LineLoader +from pynxtools.nyaml2nxdl.nyaml2nxdl_helper import cleaning_empty_lines +from pynxtools.nyaml2nxdl.nyaml2nxdl_helper import get_yaml_escape_char_reverter_dict +from pynxtools.nyaml2nxdl.nyaml2nxdl_helper import nx_name_type_resolving # pylint: disable=too-many-lines, global-statement, invalid-name -DOM_COMMENT = ("\n" - "# NeXus - Neutron and X-ray Common Data Format\n" - "# \n" - "# Copyright (C) 2014-2022 NeXus International Advisory Committee (NIAC)\n" - "# \n" - "# This library is free software; you can redistribute it and/or\n" - "# modify it under the terms of the GNU Lesser General Public\n" - "# License as published by the Free Software Foundation; either\n" - "# version 3 of the License, or (at your option) any later version.\n" - "#\n" - "# This library is distributed in the hope that it will be useful,\n" - "# but WITHOUT ANY WARRANTY; without even the implied warranty of\n" - "# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU\n" - "# Lesser General Public License for more details.\n" - "#\n" - "# You should have received a copy of the GNU Lesser General Public\n" - "# License along with this library; if not, write to the Free Software\n" - "# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA\n" - "#\n" - "# For further information, see http://www.nexusformat.org\n") +DOM_COMMENT = ( + "\n" + "# NeXus - Neutron and X-ray Common Data Format\n" + "# \n" + "# Copyright (C) 2014-2022 NeXus International Advisory Committee (NIAC)\n" + "# \n" + "# This library is free software; you can redistribute it and/or\n" + "# modify it under the terms of the GNU Lesser General Public\n" + "# License as published by the Free Software Foundation; either\n" + "# version 3 of the License, or (at your option) any later version.\n" + "#\n" + "# This library is distributed in the hope that it will be useful,\n" + "# but WITHOUT ANY WARRANTY; without even the implied warranty of\n" + "# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU\n" + "# Lesser General Public License for more details.\n" + "#\n" + "# You should have received a copy of the GNU Lesser General Public\n" + "# License along with this library; if not, write to the Free Software\n" + "# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA\n" + "#\n" + "# For further information, see http://www.nexusformat.org\n" +) NX_CLSS = nexus.get_nx_classes() -NX_NEW_DEFINED_CLASSES = ['NX_COMPLEX'] +NX_NEW_DEFINED_CLASSES = ["NX_COMPLEX"] NX_TYPE_KEYS = nexus.get_nx_attribute_type() -NX_ATTR_IDNT = '\\@' -NX_UNIT_IDNT = 'unit' +NX_ATTR_IDNT = "\\@" +NX_UNIT_IDNT = "unit" DEPTH_SIZE = " " NX_UNIT_TYPES = nexus.get_nx_units() COMMENT_BLOCKS: CommentCollector -CATEGORY = '' # Definition would be either 'base' or 'application' +CATEGORY = "" # Definition would be either 'base' or 'application' def check_for_dom_comment_in_yaml(): - """Check the yaml file has dom comment or dom comment needed to be hard coded. - """ - dignature_keyword_list = ['NeXus', - 'GNU Lesser General Public', - 'Free Software Foundation', - 'Copyright (C)', - 'WITHOUT ANY WARRANTY'] + """Check the yaml file has dom comment or dom comment needed to be hard coded.""" + dignature_keyword_list = [ + "NeXus", + "GNU Lesser General Public", + "Free Software Foundation", + "Copyright (C)", + "WITHOUT ANY WARRANTY", + ] # Check for dom comments in first three comments - dom_comment = '' + dom_comment = "" dom_comment_ind = 1 for ind, comnt in enumerate(COMMENT_BLOCKS[0:5]): cmnt_list = comnt.get_comment_text() @@ -91,7 +93,7 @@ def check_for_dom_comment_in_yaml(): dom_comment_ind = ind for keyword in dignature_keyword_list: if keyword not in text: - dom_comment = '' + dom_comment = "" break if dom_comment: break @@ -120,11 +122,13 @@ def yml_reader(inputfile): if dom_cmnt_frm_yaml: DOM_COMMENT = dom_cmnt_frm_yaml - if 'category' not in loaded_yaml.keys(): - raise ValueError("All definitions should be either 'base' or 'application' category. " - "No category has been found.") + if "category" not in loaded_yaml.keys(): + raise ValueError( + "All definitions should be either 'base' or 'application' category. " + "No category has been found." + ) global CATEGORY - CATEGORY = loaded_yaml['category'] + CATEGORY = loaded_yaml["category"] return loaded_yaml @@ -134,25 +138,27 @@ def check_for_default_attribute_and_value(xml_element): """ # base:Default attributes and value for all elements of base class except dimension element - base_attr_to_val = {'optional': 'true'} + base_attr_to_val = {"optional": "true"} # application: Default attributes and value for all elements of application class except # dimension element - application_attr_to_val = {'optional': 'false'} + application_attr_to_val = {"optional": "false"} # Default attributes and value for dimension element - base_dim_attr_to_val = {'required': 'false'} - application_dim_attr_to_val = {'required': 'true'} + base_dim_attr_to_val = {"required": "false"} + application_dim_attr_to_val = {"required": "true"} # Eligible tag for default attr and value - elegible_tag = ['group', 'field', 'attribute'] + elegible_tag = ["group", "field", "attribute"] def set_default_attribute(xml_elem, default_attr_to_val): for deflt_attr, deflt_val in default_attr_to_val.items(): - if deflt_attr not in xml_elem.attrib \ - and 'maxOccurs' not in xml_elem.attrib \ - and 'minOccurs' not in xml_elem.attrib \ - and 'recommended' not in xml_elem.attrib: + if ( + deflt_attr not in xml_elem.attrib + and "maxOccurs" not in xml_elem.attrib + and "minOccurs" not in xml_elem.attrib + and "recommended" not in xml_elem.attrib + ): xml_elem.set(deflt_attr, deflt_val) for child in list(xml_element): @@ -161,14 +167,13 @@ def set_default_attribute(xml_elem, default_attr_to_val): continue tag = remove_namespace_from_tag(child.tag) - if tag == 'dim' and CATEGORY == 'base': + if tag == "dim" and CATEGORY == "base": set_default_attribute(child, base_dim_attr_to_val) - if tag == 'dim' and CATEGORY == 'application': + if tag == "dim" and CATEGORY == "application": set_default_attribute(child, application_dim_attr_to_val) - if tag in elegible_tag and CATEGORY == 'base': + if tag in elegible_tag and CATEGORY == "base": set_default_attribute(child, base_attr_to_val) - if tag in elegible_tag and CATEGORY == 'application': - + if tag in elegible_tag and CATEGORY == "application": set_default_attribute(child, application_attr_to_val) check_for_default_attribute_and_value(child) @@ -177,50 +182,53 @@ def yml_reader_nolinetag(inputfile): """ pyyaml based parsing of yaml file in python dict """ - with open(inputfile, 'r', encoding="utf-8") as stream: + with open(inputfile, "r", encoding="utf-8") as stream: parsed_yaml = yaml.safe_load(stream) return parsed_yaml def check_for_skiped_attributes(component, value, allowed_attr=None, verbose=False): """ - Check for any attributes have been skipped or not. - NOTE: We should keep in mind about 'doc' + Check for any attributes have been skipped or not. + NOTE: We should keep in mind about 'doc' """ - block_tag = ['enumeration'] + block_tag = ["enumeration"] if value: for attr, val in value.items(): - if attr in ['doc']: + if attr in ["doc"]: continue - if '__line__' in attr or attr in block_tag: + if "__line__" in attr or attr in block_tag: continue - line_number = f'__line__{attr}' + line_number = f"__line__{attr}" if verbose: print(f"__line__ : {value[line_number]}") - if not isinstance(val, dict) \ - and '\\@' not in attr\ - and attr not in allowed_attr\ - and 'NX' not in attr and val: - - raise ValueError(f"An attribute '{attr}' in part '{component}' has been found" - f". Please check arround line '{value[line_number]}. At this " - f"moment. The allowed attrbutes are {allowed_attr}") + if ( + not isinstance(val, dict) + and "\\@" not in attr + and attr not in allowed_attr + and "NX" not in attr + and val + ): + raise ValueError( + f"An attribute '{attr}' in part '{component}' has been found" + f". Please check arround line '{value[line_number]}. At this " + f"moment. The allowed attrbutes are {allowed_attr}" + ) def format_nxdl_doc(string): - """NeXus format for doc string - """ + """NeXus format for doc string""" string = check_for_mapping_char_other(string) - formatted_doc = '' + formatted_doc = "" if "\n" not in string: if len(string) > 80: - wrapped = textwrap.TextWrapper(width=80, - break_long_words=False, - replace_whitespace=False) - string = '\n'.join(wrapped.wrap(string)) - formatted_doc = '\n' + f"{string}" + wrapped = textwrap.TextWrapper( + width=80, break_long_words=False, replace_whitespace=False + ) + string = "\n".join(wrapped.wrap(string)) + formatted_doc = "\n" + f"{string}" else: - text_lines = string.split('\n') + text_lines = string.split("\n") text_lines = cleaning_empty_lines(text_lines) formatted_doc += "\n" + "\n".join(text_lines) if not formatted_doc.endswith("\n"): @@ -234,12 +242,12 @@ def check_for_mapping_char_other(text): Then replace it by ':'. """ if not text: - text = '' + text = "" text = str(text) - if text == 'True': - text = 'true' - if text == 'False': - text = 'false' + if text == "True": + text = "true" + if text == "False": + text = "false" # Some escape char is not valid in yaml libray which is written while writting # yaml file. In the time of writting nxdl revert to that escape char. escape_reverter = get_yaml_escape_char_reverter_dict() @@ -249,26 +257,20 @@ def check_for_mapping_char_other(text): return str(text).strip() -def xml_handle_doc(obj, value: str, - line_number=None, line_loc=None): - """This function creates a 'doc' element instance, and appends it to an existing element - - """ +def xml_handle_doc(obj, value: str, line_number=None, line_loc=None): + """This function creates a 'doc' element instance, and appends it to an existing element""" # global comment_bolcks - doc_elemt = ET.SubElement(obj, 'doc') + doc_elemt = ET.SubElement(obj, "doc") text = format_nxdl_doc(check_for_mapping_char_other(value)).strip() # To keep the doc middle of doc tag. doc_elemt.text = f"\n{text}\n" if line_loc is not None and line_number is not None: - xml_handle_comment(obj, line_number, - line_loc, doc_elemt) + xml_handle_comment(obj, line_number, line_loc, doc_elemt) def xml_handle_units(obj, value): - """This function creates a 'units' element instance, and appends it to an existing element - - """ - obj.set('units', str(value)) + """This function creates a 'units' element instance, and appends it to an existing element""" + obj.set("units", str(value)) # pylint: disable=too-many-branches @@ -276,46 +278,52 @@ def xml_handle_exists(dct, obj, keyword, value): """ This function creates an 'exists' element instance, and appends it to an existing element """ - line_number = f'__line__{keyword}' - assert value is not None, f'Line {dct[line_number]}: exists argument must not be None !' + line_number = f"__line__{keyword}" + assert ( + value is not None + ), f"Line {dct[line_number]}: exists argument must not be None !" if isinstance(value, list): - if len(value) == 4 and value[0] == 'min' and value[2] == 'max': - obj.set('minOccurs', str(value[1])) - if str(value[3]) != 'infty': - obj.set('maxOccurs', str(value[3])) + if len(value) == 4 and value[0] == "min" and value[2] == "max": + obj.set("minOccurs", str(value[1])) + if str(value[3]) != "infty": + obj.set("maxOccurs", str(value[3])) else: - obj.set('maxOccurs', 'unbounded') - elif len(value) == 2 and value[0] == 'min': - obj.set('minOccurs', str(value[1])) - elif len(value) == 2 and value[0] == 'max': - obj.set('maxOccurs', str(value[1])) - elif len(value) == 4 and value[0] == 'max' and value[2] == 'min': - obj.set('minOccurs', str(value[3])) - if str(value[1]) != 'infty': - obj.set('maxOccurs', str(value[3])) + obj.set("maxOccurs", "unbounded") + elif len(value) == 2 and value[0] == "min": + obj.set("minOccurs", str(value[1])) + elif len(value) == 2 and value[0] == "max": + obj.set("maxOccurs", str(value[1])) + elif len(value) == 4 and value[0] == "max" and value[2] == "min": + obj.set("minOccurs", str(value[3])) + if str(value[1]) != "infty": + obj.set("maxOccurs", str(value[3])) else: - obj.set('maxOccurs', 'unbounded') - elif len(value) == 4 and (value[0] != 'min' or value[2] != 'max'): - raise ValueError(f'Line {dct[line_number]}: exists keyword' - f'needs to go either with an optional [recommended] list with two ' - f'entries either [min, ] or [max, ], or a list of four ' - f'entries [min, , max, ] !') + obj.set("maxOccurs", "unbounded") + elif len(value) == 4 and (value[0] != "min" or value[2] != "max"): + raise ValueError( + f"Line {dct[line_number]}: exists keyword" + f"needs to go either with an optional [recommended] list with two " + f"entries either [min, ] or [max, ], or a list of four " + f"entries [min, , max, ] !" + ) else: - raise ValueError(f'Line {dct[line_number]}: exists keyword ' - f'needs to go either with optional, recommended, a list with two ' - f'entries either [min, ] or [max, ], or a list of four ' - f'entries [min, , max, ] !') + raise ValueError( + f"Line {dct[line_number]}: exists keyword " + f"needs to go either with optional, recommended, a list with two " + f"entries either [min, ] or [max, ], or a list of four " + f"entries [min, , max, ] !" + ) else: # This clause take optional in all concept except dimension where 'required' key is allowed # not the 'optional' key. - if value == 'optional': - obj.set('optional', 'true') - elif value == 'recommended': - obj.set('recommended', 'true') - elif value == 'required': - obj.set('optional', 'false') + if value == "optional": + obj.set("optional", "true") + elif value == "recommended": + obj.set("recommended", "true") + elif value == "required": + obj.set("optional", "false") else: - obj.set('minOccurs', '0') + obj.set("minOccurs", "0") # pylint: disable=too-many-branches, too-many-locals, too-many-statements @@ -323,52 +331,59 @@ def xml_handle_group(dct, obj, keyword, value, verbose=False): """ The function deals with group instances """ - line_number = f'__line__{keyword}' + line_number = f"__line__{keyword}" line_loc = dct[line_number] xml_handle_comment(obj, line_number, line_loc) - list_of_attr = ['name', 'type', 'nameType', 'deprecated', 'optional', 'recommended', - 'exists', 'unit'] + list_of_attr = [ + "name", + "type", + "nameType", + "deprecated", + "optional", + "recommended", + "exists", + "unit", + ] l_bracket = -1 r_bracket = -1 - if keyword.count('(') == 1: - l_bracket = keyword.index('(') - if keyword.count(')') == 1: - r_bracket = keyword.index(')') + if keyword.count("(") == 1: + l_bracket = keyword.index("(") + if keyword.count(")") == 1: + r_bracket = keyword.index(")") keyword_name, keyword_type = nx_name_type_resolving(keyword) if not keyword_name and not keyword_type: raise ValueError("A group must have both value and name. Check for group.") - grp = ET.SubElement(obj, 'group') + grp = ET.SubElement(obj, "group") if l_bracket == 0 and r_bracket > 0: - grp.set('type', keyword_type) + grp.set("type", keyword_type) if keyword_name: - grp.set('name', keyword_name) + grp.set("name", keyword_name) elif l_bracket > 0: - grp.set('name', keyword_name) + grp.set("name", keyword_name) if keyword_type: - grp.set('type', keyword_type) + grp.set("type", keyword_type) else: - grp.set('name', keyword_name) + grp.set("name", keyword_name) if value: rm_key_list = [] for attr, vval in value.items(): - if '__line__' in attr: + if "__line__" in attr: continue line_number = f"__line__{attr}" line_loc = value[line_number] - if attr == 'doc': + if attr == "doc": xml_handle_doc(grp, vval, line_number, line_loc) rm_key_list.append(attr) rm_key_list.append(line_number) - elif attr == 'exists' and vval: + elif attr == "exists" and vval: xml_handle_exists(value, grp, attr, vval) rm_key_list.append(attr) rm_key_list.append(line_number) - xml_handle_comment(obj, - line_number, line_loc, grp) - elif attr == 'unit': + xml_handle_comment(obj, line_number, line_loc, grp) + elif attr == "unit": xml_handle_units(grp, vval) xml_handle_comment(obj, line_number, line_loc, grp) elif attr in list_of_attr and not isinstance(vval, dict) and vval: @@ -381,7 +396,7 @@ def xml_handle_group(dct, obj, keyword, value, verbose=False): for key in rm_key_list: del value[key] # Check for skipped attrinutes - check_for_skiped_attributes('group', value, list_of_attr, verbose) + check_for_skiped_attributes("group", value, list_of_attr, verbose) if isinstance(value, dict) and value != {}: recursive_build(grp, value, verbose) @@ -403,34 +418,37 @@ def xml_handle_dimensions(dct, obj, keyword, value: dict): incr:[...]' """ - possible_dimension_attrs = ['rank'] # nxdl attributes - line_number = f'__line__{keyword}' + possible_dimension_attrs = ["rank"] # nxdl attributes + line_number = f"__line__{keyword}" line_loc = dct[line_number] - assert 'dim' in value.keys(), (f"Line {line_loc}: No dim as child of dimension has " - f"been found.") + assert "dim" in value.keys(), ( + f"Line {line_loc}: No dim as child of dimension has " f"been found." + ) xml_handle_comment(obj, line_number, line_loc) - dims = ET.SubElement(obj, 'dimensions') + dims = ET.SubElement(obj, "dimensions") # Consider all the childs under dimension is dim element and # its attributes rm_key_list = [] - rank = '' + rank = "" for key, val in value.items(): - if '__line__' in key: + if "__line__" in key: continue line_number = f"__line__{key}" line_loc = value[line_number] - if key == 'rank': - rank = val or '' + if key == "rank": + rank = val or "" if isinstance(rank, int) and rank < 0: - raise ValueError(f"Dimension must have some info about rank which is not " - f"available. Please check arround Line: {dct[line_number]}") + raise ValueError( + f"Dimension must have some info about rank which is not " + f"available. Please check arround Line: {dct[line_number]}" + ) dims.set(key, str(val)) rm_key_list.append(key) rm_key_list.append(line_number) xml_handle_comment(obj, line_number, line_loc, dims) # Check dimension doc and handle it - elif key == 'doc' and isinstance(val, str): + elif key == "doc" and isinstance(val, str): xml_handle_doc(dims, val, line_number, line_loc) rm_key_list.append(key) rm_key_list.append(line_number) @@ -450,18 +468,20 @@ def xml_handle_dimensions(dct, obj, keyword, value: dict): # pylint: disable=too-many-locals, too-many-arguments -def xml_handle_dim_from_dimension_dict(dct, dims_obj, keyword, value, rank, verbose=False): +def xml_handle_dim_from_dimension_dict( + dct, dims_obj, keyword, value, rank, verbose=False +): """ - Handling dim element. - NOTE: The inputs 'keyword' and 'value' are as input for xml_handle_dimensions - function. please also read note in xml_handle_dimensions. + Handling dim element. + NOTE: The inputs 'keyword' and 'value' are as input for xml_handle_dimensions + function. please also read note in xml_handle_dimensions. """ - possible_dim_attrs = ['ref', 'incr', 'refindex', 'required'] + possible_dim_attrs = ["ref", "incr", "refindex", "required"] # Some attributes might have equivalent name e.g. 'required' is correct one and # 'optional' could be another name. Then change attribute to the correct one. - wrong_to_correct_attr = [('optional', 'required')] + wrong_to_correct_attr = [("optional", "required")] header_line_number = f"__line__{keyword}" dim_list = [] rm_key_list = [] @@ -469,51 +489,55 @@ def xml_handle_dim_from_dimension_dict(dct, dims_obj, keyword, value, rank, verb # under dim_parameters if not value: return - rank = '' + rank = "" # pylint: disable=too-many-nested-blocks for attr, vvalue in value.items(): - if '__line__' in attr: + if "__line__" in attr: continue line_number = f"__line__{attr}" line_loc = value[line_number] # dim comes in precedence - if attr == 'dim': + if attr == "dim": # dim consists of list of [index, value] llist_ind_value = vvalue - assert isinstance(llist_ind_value, list), (f'Line {value[line_number]}: dim' - f'argument not a list !') + assert isinstance(llist_ind_value, list), ( + f"Line {value[line_number]}: dim" f"argument not a list !" + ) xml_handle_comment(dims_obj, line_number, line_loc) if isinstance(rank, int) and rank > 0: assert rank == len(llist_ind_value), ( f"Wrong dimension rank check around Line {dct[header_line_number]}.\n" f"Line {[dct[header_line_number]]} rank value {rank} " f"is not the same as dim array = " - f"{len(llist_ind_value)}.") + f"{len(llist_ind_value)}." + ) # Taking care of ind and value that comes as list of list for dim_ind_val in llist_ind_value: - dim = ET.SubElement(dims_obj, 'dim') + dim = ET.SubElement(dims_obj, "dim") # Taking care of multidimensions or rank if len(dim_ind_val) >= 1 and dim_ind_val[0]: - dim.set('index', str(dim_ind_val[0])) + dim.set("index", str(dim_ind_val[0])) if len(dim_ind_val) == 2 and dim_ind_val[1]: - dim.set('value', str(dim_ind_val[1])) + dim.set("value", str(dim_ind_val[1])) dim_list.append(dim) rm_key_list.append(attr) rm_key_list.append(line_number) - elif attr == 'dim_parameters' and isinstance(vvalue, dict): + elif attr == "dim_parameters" and isinstance(vvalue, dict): xml_handle_comment(dims_obj, line_number, line_loc) for kkkey, vvval in vvalue.items(): - if '__line__' in kkkey: + if "__line__" in kkkey: continue - cmnt_number = f'__line__{kkkey}' + cmnt_number = f"__line__{kkkey}" cmnt_loc = vvalue[cmnt_number] # Check whether any optional attributes added for tuple_wng_crt in wrong_to_correct_attr: if kkkey == tuple_wng_crt[0]: - raise ValueError(f"{cmnt_loc}: Attribute '{kkkey}' is prohibited, use " - f"'{tuple_wng_crt[1]}") - if kkkey == 'doc' and dim_list: + raise ValueError( + f"{cmnt_loc}: Attribute '{kkkey}' is prohibited, use " + f"'{tuple_wng_crt[1]}" + ) + if kkkey == "doc" and dim_list: # doc comes as list of doc for i, dim in enumerate(dim_list): if isinstance(vvval, list) and i < len(vvval): @@ -539,13 +563,15 @@ def xml_handle_dim_from_dimension_dict(dct, dims_obj, keyword, value, rank, verb rm_key_list.append(attr) rm_key_list.append(line_number) else: - raise ValueError(f"Got unexpected block except 'dim' and 'dim_parameters'." - f"Please check arround line {line_number}") + raise ValueError( + f"Got unexpected block except 'dim' and 'dim_parameters'." + f"Please check arround line {line_number}" + ) for key in rm_key_list: del value[key] - check_for_skiped_attributes('dim', value, possible_dim_attrs, verbose) + check_for_skiped_attributes("dim", value, possible_dim_attrs, verbose) def xml_handle_enumeration(dct, obj, keyword, value, verbose): @@ -555,24 +581,27 @@ def xml_handle_enumeration(dct, obj, keyword, value, verbose): 1) the items are in a list 2) the items are dictionaries and may contain a nested doc """ - line_number = f'__line__{keyword}' + line_number = f"__line__{keyword}" line_loc = dct[line_number] xml_handle_comment(obj, line_number, line_loc) - enum = ET.SubElement(obj, 'enumeration') - - assert value is not None, f'Line {line_loc}: enumeration must \ -bear at least an argument !' - assert len( - value) >= 1, f'Line {dct[line_number]}: enumeration must not be an empty list!' + enum = ET.SubElement(obj, "enumeration") + + assert ( + value is not None + ), f"Line {line_loc}: enumeration must \ +bear at least an argument !" + assert ( + len(value) >= 1 + ), f"Line {dct[line_number]}: enumeration must not be an empty list!" if isinstance(value, list): for element in value: - itm = ET.SubElement(enum, 'item') - itm.set('value', str(element)) + itm = ET.SubElement(enum, "item") + itm.set("value", str(element)) if isinstance(value, dict) and value != {}: for element in value.keys(): - if '__line__' not in element: - itm = ET.SubElement(enum, 'item') - itm.set('value', str(element)) + if "__line__" not in element: + itm = ET.SubElement(enum, "item") + itm.set("value", str(element)) if isinstance(value[element], dict): recursive_build(itm, value[element], verbose) @@ -580,25 +609,25 @@ def xml_handle_enumeration(dct, obj, keyword, value, verbose): # pylint: disable=unused-argument def xml_handle_link(dct, obj, keyword, value, verbose): """ - If we have an NXDL link we decode the name attribute from (link)[:-6] + If we have an NXDL link we decode the name attribute from (link)[:-6] """ line_number = f"__line__{keyword}" line_loc = dct[line_number] xml_handle_comment(obj, line_number, line_loc) - possible_attrs = ['name', 'target', 'napimount'] + possible_attrs = ["name", "target", "napimount"] name = keyword[:-6] - link_obj = ET.SubElement(obj, 'link') - link_obj.set('name', str(name)) + link_obj = ET.SubElement(obj, "link") + link_obj.set("name", str(name)) if value: rm_key_list = [] for attr, vval in value.items(): - if '__line__' in attr: + if "__line__" in attr: continue line_number = f"__line__{attr}" line_loc = value[line_number] - if attr == 'doc': + if attr == "doc": xml_handle_doc(link_obj, vval, line_number, line_loc) rm_key_list.append(attr) rm_key_list.append(line_number) @@ -612,7 +641,7 @@ def xml_handle_link(dct, obj, keyword, value, verbose): for key in rm_key_list: del value[key] # Check for skipped attrinutes - check_for_skiped_attributes('link', value, possible_attrs, verbose) + check_for_skiped_attributes("link", value, possible_attrs, verbose) if isinstance(value, dict) and value != {}: recursive_build(link_obj, value, verbose=None) @@ -620,26 +649,26 @@ def xml_handle_link(dct, obj, keyword, value, verbose): def xml_handle_choice(dct, obj, keyword, value, verbose=False): """ - Build choice xml elements. That consists of groups. + Build choice xml elements. That consists of groups. """ - line_number = f'__line__{keyword}' + line_number = f"__line__{keyword}" line_loc = dct[line_number] xml_handle_comment(obj, line_number, line_loc) # Add attributes in possible if new attributs have been added nexus definition. possible_attr = [] - choice_obj = ET.SubElement(obj, 'choice') + choice_obj = ET.SubElement(obj, "choice") # take care of special attributes name = keyword[:-8] - choice_obj.set('name', name) + choice_obj.set("name", name) if value: rm_key_list = [] for attr, vval in value.items(): - if '__line__' in attr: + if "__line__" in attr: continue line_number = f"__line__{attr}" line_loc = value[line_number] - if attr == 'doc': + if attr == "doc": xml_handle_doc(choice_obj, vval, line_number, line_loc) rm_key_list.append(attr) rm_key_list.append(line_number) @@ -653,40 +682,40 @@ def xml_handle_choice(dct, obj, keyword, value, verbose=False): for key in rm_key_list: del value[key] # Check for skipped attrinutes - check_for_skiped_attributes('choice', value, possible_attr, verbose) + check_for_skiped_attributes("choice", value, possible_attr, verbose) if isinstance(value, dict) and value != {}: recursive_build(choice_obj, value, verbose=None) def xml_handle_symbols(dct, obj, keyword, value: dict): - """Handle a set of NXDL symbols as a child to obj - - """ - line_number = f'__line__{keyword}' + """Handle a set of NXDL symbols as a child to obj""" + line_number = f"__line__{keyword}" line_loc = dct[line_number] - assert len(list(value.keys()) - ) >= 1, f'Line {line_loc}: symbols table must not be empty !' + assert ( + len(list(value.keys())) >= 1 + ), f"Line {line_loc}: symbols table must not be empty !" xml_handle_comment(obj, line_number, line_loc) - syms = ET.SubElement(obj, 'symbols') - if 'doc' in value.keys(): - line_number = '__line__doc' + syms = ET.SubElement(obj, "symbols") + if "doc" in value.keys(): + line_number = "__line__doc" line_loc = value[line_number] xml_handle_comment(syms, line_number, line_loc) - doctag = ET.SubElement(syms, 'doc') - doctag.text = '\n' + textwrap.fill(value['doc'], width=70) + '\n' + doctag = ET.SubElement(syms, "doc") + doctag.text = "\n" + textwrap.fill(value["doc"], width=70) + "\n" rm_key_list = [] for kkeyword, vvalue in value.items(): - if '__line__' in kkeyword: + if "__line__" in kkeyword: continue - if kkeyword != 'doc': - line_number = f'__line__{kkeyword}' + if kkeyword != "doc": + line_number = f"__line__{kkeyword}" line_loc = value[line_number] xml_handle_comment(syms, line_number, line_loc) assert vvalue is not None and isinstance( - vvalue, str), f'Line {line_loc}: put a comment in doc string !' - sym = ET.SubElement(syms, 'symbol') - sym.set('name', str(kkeyword)) + vvalue, str + ), f"Line {line_loc}: put a comment in doc string !" + sym = ET.SubElement(syms, "symbol") + sym.set("name", str(kkeyword)) # sym_doc = ET.SubElement(sym, 'doc') xml_handle_doc(sym, vvalue) rm_key_list.append(kkeyword) @@ -704,15 +733,16 @@ def check_keyword_variable(verbose, dct, keyword, value): keyword_name, keyword_type = nx_name_type_resolving(keyword) if verbose: sys.stdout.write( - f'{keyword_name}({keyword_type}): value type is {type(value)}\n') - if keyword_name == '' and keyword_type == '': - line_number = f'__line__{keyword}' - raise ValueError(f'Line {dct[line_number]}: found an improper yaml key !') + f"{keyword_name}({keyword_type}): value type is {type(value)}\n" + ) + if keyword_name == "" and keyword_type == "": + line_number = f"__line__{keyword}" + raise ValueError(f"Line {dct[line_number]}: found an improper yaml key !") def helper_keyword_type(kkeyword_type): """ - This function is returning a value of keyword_type if it belong to NX_TYPE_KEYS + This function is returning a value of keyword_type if it belong to NX_TYPE_KEYS """ if kkeyword_type in NX_TYPE_KEYS: return kkeyword_type @@ -721,10 +751,10 @@ def helper_keyword_type(kkeyword_type): def verbose_flag(verbose, keyword, value): """ - Verbose stdout printing for nested levels of yaml file, if verbose flag is active + Verbose stdout printing for nested levels of yaml file, if verbose flag is active """ if verbose: - sys.stdout.write(f' key:{keyword}; value type is {type(value)}\n') + sys.stdout.write(f" key:{keyword}; value type is {type(value)}\n") def xml_handle_attributes(dct, obj, keyword, value, verbose): @@ -734,43 +764,53 @@ def xml_handle_attributes(dct, obj, keyword, value, verbose): line_loc = dct[line_number] xml_handle_comment(obj, line_number, line_loc) # list of possible attribute of xml attribute elementsa - attr_attr_list = ['name', 'type', 'unit', 'nameType', - 'optional', 'recommended', 'minOccurs', - 'maxOccurs', 'deprecated', 'exists'] + attr_attr_list = [ + "name", + "type", + "unit", + "nameType", + "optional", + "recommended", + "minOccurs", + "maxOccurs", + "deprecated", + "exists", + ] # as an attribute identifier keyword_name, keyword_typ = nx_name_type_resolving(keyword) - line_number = f'__line__{keyword}' + line_number = f"__line__{keyword}" if verbose: print(f"__line__ : {dct[line_number]}") - if keyword_name == '' and keyword_typ == '': - raise ValueError(f'Line {dct[line_number]}: found an improper yaml key !') - elemt_obj = ET.SubElement(obj, 'attribute') - elemt_obj.set('name', keyword_name[2:]) + if keyword_name == "" and keyword_typ == "": + raise ValueError(f"Line {dct[line_number]}: found an improper yaml key !") + elemt_obj = ET.SubElement(obj, "attribute") + elemt_obj.set("name", keyword_name[2:]) if keyword_typ: - elemt_obj.set('type', keyword_typ) + elemt_obj.set("type", keyword_typ) rm_key_list = [] if value and value: # taking care of attributes of attributes for attr, attr_val in value.items(): - if '__line__' in attr: + if "__line__" in attr: continue line_number = f"__line__{attr}" line_loc = value[line_number] - if attr in ['doc', *attr_attr_list] and not isinstance(attr_val, dict): - if attr == 'unit': + if attr in ["doc", *attr_attr_list] and not isinstance(attr_val, dict): + if attr == "unit": elemt_obj.set(f"{attr}s", str(value[attr])) rm_key_list.append(attr) rm_key_list.append(line_number) xml_handle_comment(obj, line_number, line_loc, elemt_obj) - elif attr == 'exists' and attr_val: + elif attr == "exists" and attr_val: xml_handle_exists(value, elemt_obj, attr, attr_val) rm_key_list.append(attr) rm_key_list.append(line_number) xml_handle_comment(obj, line_number, line_loc, elemt_obj) - elif attr == 'doc': - xml_handle_doc(elemt_obj, format_nxdl_doc(attr_val), - line_number, line_loc) + elif attr == "doc": + xml_handle_doc( + elemt_obj, format_nxdl_doc(attr_val), line_number, line_loc + ) rm_key_list.append(attr) rm_key_list.append(line_number) else: @@ -782,7 +822,7 @@ def xml_handle_attributes(dct, obj, keyword, value, verbose): for key in rm_key_list: del value[key] # Check cor skiped attribute - check_for_skiped_attributes('Attribute', value, attr_attr_list, verbose) + check_for_skiped_attributes("Attribute", value, attr_attr_list, verbose) if value: recursive_build(elemt_obj, value, verbose) @@ -794,25 +834,28 @@ def validate_field_attribute_and_value(v_attr, vval, allowed_attribute, value): """ # check for empty val - if (not isinstance(vval, dict) - and not str(vval)): # check for empty value - + if not isinstance(vval, dict) and not str(vval): # check for empty value line_number = f"__line__{v_attr}" - raise ValueError(f"In a field a valid attrbute ('{v_attr}') found that is not stored." - f" Please check arround line {value[line_number]}") + raise ValueError( + f"In a field a valid attrbute ('{v_attr}') found that is not stored." + f" Please check arround line {value[line_number]}" + ) # The bellow elements might come as child element - skipped_child_name = ['doc', 'dimension', 'enumeration', 'choice', 'exists'] + skipped_child_name = ["doc", "dimension", "enumeration", "choice", "exists"] # check for invalid key or attributes - if (v_attr not in [*skipped_child_name, *allowed_attribute] - and '__line__' not in v_attr + if ( + v_attr not in [*skipped_child_name, *allowed_attribute] + and "__line__" not in v_attr and not isinstance(vval, dict) - and '(' not in v_attr # skip only groups and field that has name and type - and '\\@' not in v_attr): # skip nexus attributes - + and "(" not in v_attr # skip only groups and field that has name and type + and "\\@" not in v_attr + ): # skip nexus attributes line_number = f"__line__{v_attr}" - raise ValueError(f"In a field or group a invalid attribute ('{v_attr}') or child has found." - f" Please check arround line {value[line_number]}.") + raise ValueError( + f"In a field or group a invalid attribute ('{v_attr}') or child has found." + f" Please check arround line {value[line_number]}." + ) def xml_handle_fields(obj, keyword, value, line_annot, line_loc, verbose=False): @@ -830,84 +873,101 @@ def xml_handle_fields(obj, keyword, value, line_annot, line_loc, verbose=False): This simple function will define a new node of xml tree """ # List of possible attributes of xml elements - allowed_attr = ['name', 'type', 'nameType', 'unit', 'minOccurs', 'long_name', - 'axis', 'signal', 'deprecated', 'axes', 'exists', - 'data_offset', 'interpretation', 'maxOccurs', - 'primary', 'recommended', 'optional', 'stride'] + allowed_attr = [ + "name", + "type", + "nameType", + "unit", + "minOccurs", + "long_name", + "axis", + "signal", + "deprecated", + "axes", + "exists", + "data_offset", + "interpretation", + "maxOccurs", + "primary", + "recommended", + "optional", + "stride", + ] xml_handle_comment(obj, line_annot, line_loc) l_bracket = -1 r_bracket = -1 - if keyword.count('(') == 1: - l_bracket = keyword.index('(') - if keyword.count(')') == 1: - r_bracket = keyword.index(')') + if keyword.count("(") == 1: + l_bracket = keyword.index("(") + if keyword.count(")") == 1: + r_bracket = keyword.index(")") keyword_name, keyword_type = nx_name_type_resolving(keyword) if not keyword_type and not keyword_name: raise ValueError("Check for name or type in field.") - elemt_obj = ET.SubElement(obj, 'field') + elemt_obj = ET.SubElement(obj, "field") # type come first if l_bracket == 0 and r_bracket > 0: - elemt_obj.set('type', keyword_type) + elemt_obj.set("type", keyword_type) if keyword_name: - elemt_obj.set('name', keyword_name) + elemt_obj.set("name", keyword_name) elif l_bracket > 0: - elemt_obj.set('name', keyword_name) + elemt_obj.set("name", keyword_name) if keyword_type: - elemt_obj.set('type', keyword_type) + elemt_obj.set("type", keyword_type) else: - elemt_obj.set('name', keyword_name) + elemt_obj.set("name", keyword_name) if value: rm_key_list = [] # In each each if clause apply xml_handle_comment(), to collect # comments on that yaml line. for attr, vval in value.items(): - if '__line__' in attr: + if "__line__" in attr: continue line_number = f"__line__{attr}" line_loc = value[line_number] - if attr == 'doc': - xml_handle_doc(elemt_obj, vval, line_number, line_loc,) + if attr == "doc": + xml_handle_doc( + elemt_obj, + vval, + line_number, + line_loc, + ) rm_key_list.append(attr) rm_key_list.append(line_number) - elif attr == 'exists' and vval: + elif attr == "exists" and vval: xml_handle_exists(value, elemt_obj, attr, vval) rm_key_list.append(attr) rm_key_list.append(line_number) - xml_handle_comment(obj, - line_number, - line_loc, elemt_obj) - elif attr == 'unit': + xml_handle_comment(obj, line_number, line_loc, elemt_obj) + elif attr == "unit": xml_handle_units(elemt_obj, vval) - xml_handle_comment(obj, - line_number, - line_loc, elemt_obj) + xml_handle_comment(obj, line_number, line_loc, elemt_obj) elif attr in allowed_attr and not isinstance(vval, dict) and vval: validate_field_attribute_and_value(attr, vval, allowed_attr, value) elemt_obj.set(attr, check_for_mapping_char_other(vval)) rm_key_list.append(attr) rm_key_list.append(line_number) - xml_handle_comment(obj, - line_number, - line_loc, elemt_obj) + xml_handle_comment(obj, line_number, line_loc, elemt_obj) for key in rm_key_list: del value[key] # Check for skipped attrinutes - check_for_skiped_attributes('field', value, allowed_attr, verbose) + check_for_skiped_attributes("field", value, allowed_attr, verbose) if isinstance(value, dict) and value != {}: recursive_build(elemt_obj, value, verbose) -def xml_handle_comment(obj: ET.Element, - line_annotation: str, - line_loc_no: int, - xml_ele: ET.Element = None, - is_def_cmnt: bool = False): +def xml_handle_comment( + obj: ET.Element, + line_annotation: str, + line_loc_no: int, + xml_ele: ET.Element = None, + is_def_cmnt: bool = False, +): """ Add xml comment: check for comments that has the same 'line_annotation' (e.g. __line__data) and the same line_loc_no (e.g. 30). After that, i @@ -936,7 +996,7 @@ def xml_handle_comment(obj: ET.Element, obj.append(si_comnt) else: raise ValueError("Provied correct parameter values.") - return '' + return "" def recursive_build(obj, dct, verbose): @@ -948,7 +1008,7 @@ def recursive_build(obj, dct, verbose): """ for keyword, value in iter(dct.items()): - if '__line__' in keyword: + if "__line__" in keyword: continue line_number = f"__line__{keyword}" line_loc = dct[line_number] @@ -956,44 +1016,46 @@ def recursive_build(obj, dct, verbose): check_keyword_variable(verbose, dct, keyword, value) if verbose: sys.stdout.write( - f'keyword_name:{keyword_name} keyword_type {keyword_type}\n') + f"keyword_name:{keyword_name} keyword_type {keyword_type}\n" + ) - if keyword[-6:] == '(link)': + if keyword[-6:] == "(link)": xml_handle_link(dct, obj, keyword, value, verbose) - elif keyword[-8:] == '(choice)': + elif keyword[-8:] == "(choice)": xml_handle_choice(dct, obj, keyword, value) # The bellow xml_symbol clause is for the symbols that come ubde filed or attributes # Root level symbols has been inside nyaml2nxdl() - elif keyword_type == '' and keyword_name == 'symbols': + elif keyword_type == "" and keyword_name == "symbols": xml_handle_symbols(dct, obj, keyword, value) - elif ((keyword_type in NX_CLSS) or (keyword_type not in - [*NX_TYPE_KEYS, '', *NX_NEW_DEFINED_CLASSES])): + elif (keyword_type in NX_CLSS) or ( + keyword_type not in [*NX_TYPE_KEYS, "", *NX_NEW_DEFINED_CLASSES] + ): # we can be sure we need to instantiate a new group xml_handle_group(dct, obj, keyword, value, verbose) elif keyword_name[0:2] == NX_ATTR_IDNT: # check if obj qualifies xml_handle_attributes(dct, obj, keyword, value, verbose) - elif keyword == 'doc': + elif keyword == "doc": xml_handle_doc(obj, value, line_number, line_loc) elif keyword == NX_UNIT_IDNT: xml_handle_units(obj, value) - elif keyword == 'enumeration': + elif keyword == "enumeration": xml_handle_enumeration(dct, obj, keyword, value, verbose) - elif keyword == 'dimensions': + elif keyword == "dimensions": xml_handle_dimensions(dct, obj, keyword, value) - elif keyword == 'exists': + elif keyword == "exists": xml_handle_exists(dct, obj, keyword, value) # Handles fileds e.g. AXISNAME - elif keyword_name != '' and '__line__' not in keyword_name: - xml_handle_fields(obj, keyword, - value, line_number, - line_loc, verbose) + elif keyword_name != "" and "__line__" not in keyword_name: + xml_handle_fields(obj, keyword, value, line_number, line_loc, verbose) else: - raise ValueError(f"An unfamiliar type of element {keyword} has been found which is " - f"not be able to be resolved. Chekc arround line {dct[line_number]}") + raise ValueError( + f"An unfamiliar type of element {keyword} has been found which is " + f"not be able to be resolved. Chekc arround line {dct[line_number]}" + ) def pretty_print_xml(xml_root, output_xml, def_comments=None): @@ -1001,10 +1063,10 @@ def pretty_print_xml(xml_root, output_xml, def_comments=None): Print better human-readable indented and formatted xml file using built-in libraries and preceding XML processing instruction """ - dom = minidom.parseString(ET.tostring( - xml_root, encoding='utf-8', method='xml')) + dom = minidom.parseString(ET.tostring(xml_root, encoding="utf-8", method="xml")) proc_instractionn = dom.createProcessingInstruction( - 'xml-stylesheet', 'type="text/xsl" href="nxdlformat.xsl"') + "xml-stylesheet", 'type="text/xsl" href="nxdlformat.xsl"' + ) dom_comment = dom.createComment(DOM_COMMENT) root = dom.firstChild dom.insertBefore(proc_instractionn, root) @@ -1015,27 +1077,27 @@ def pretty_print_xml(xml_root, output_xml, def_comments=None): def_comt_ele = dom.createComment(string) dom.insertBefore(def_comt_ele, root) - xml_string = dom.toprettyxml(indent=1 * DEPTH_SIZE, newl='\n', encoding='UTF-8') - with open('tmp.xml', "wb") as file_tmp: + xml_string = dom.toprettyxml(indent=1 * DEPTH_SIZE, newl="\n", encoding="UTF-8") + with open("tmp.xml", "wb") as file_tmp: file_tmp.write(xml_string) flag = False - with open('tmp.xml', "r", encoding="utf-8") as file_out: + with open("tmp.xml", "r", encoding="utf-8") as file_out: with open(output_xml, "w", encoding="utf-8") as file_out_mod: for i in file_out.readlines(): - if '' not in i and '' not in i and flag is False: + if "" not in i and "" not in i and flag is False: file_out_mod.write(i) - elif '' in i and '' in i: + elif "" in i and "" in i: file_out_mod.write(i) - elif '' in i and '' not in i: + elif "" in i and "" not in i: flag = True white_spaces = len(i) - len(i.lstrip()) file_out_mod.write(i) - elif '' not in i and '' not in i and flag is True: - file_out_mod.write((white_spaces + 5) * ' ' + i) - elif '' not in i and '' in i and flag is True: - file_out_mod.write(white_spaces * ' ' + i) + elif "" not in i and "" not in i and flag is True: + file_out_mod.write((white_spaces + 5) * " " + i) + elif "" not in i and "" in i and flag is True: + file_out_mod.write(white_spaces * " " + i) flag = False - os.remove('tmp.xml') + os.remove("tmp.xml") # pylint: disable=too-many-statements @@ -1046,102 +1108,120 @@ def nyaml2nxdl(input_file: str, out_file, verbose: bool): fields or (their) attributes as childs of the groups """ - def_attributes = ['deprecated', 'ignoreExtraGroups', 'category', 'type', - 'ignoreExtraFields', 'ignoreExtraAttributes', 'restricts'] + def_attributes = [ + "deprecated", + "ignoreExtraGroups", + "category", + "type", + "ignoreExtraFields", + "ignoreExtraAttributes", + "restricts", + ] yml_appdef = yml_reader(input_file) def_cmnt_text = [] if verbose: - sys.stdout.write(f'input-file: {input_file}\n') - sys.stdout.write('application/base contains the following root-level entries:\n') + sys.stdout.write(f"input-file: {input_file}\n") + sys.stdout.write( + "application/base contains the following root-level entries:\n" + ) sys.stdout.write(str(yml_appdef.keys())) - xml_root = ET.Element('definition', {}) - assert 'category' in yml_appdef.keys( - ), 'Required root-level keyword category is missing!' - assert yml_appdef['category'] in ['application', 'base'], 'Only \ -application and base are valid categories!' - assert 'doc' in yml_appdef.keys(), 'Required root-level keyword doc is missing!' - - name_extends = '' + xml_root = ET.Element("definition", {}) + assert ( + "category" in yml_appdef.keys() + ), "Required root-level keyword category is missing!" + assert yml_appdef["category"] in [ + "application", + "base", + ], "Only \ +application and base are valid categories!" + assert "doc" in yml_appdef.keys(), "Required root-level keyword doc is missing!" + + name_extends = "" yml_appdef_copy = yml_appdef.copy() for kkey, vvalue in yml_appdef_copy.items(): - if '__line__' in kkey: + if "__line__" in kkey: continue line_number = f"__line__{kkey}" line_loc_no = yml_appdef[line_number] if not isinstance(vvalue, dict) and kkey in def_attributes: - xml_root.set(kkey, str(vvalue) or '') - cmnt_text = xml_handle_comment(xml_root, - line_number, line_loc_no, - is_def_cmnt=True) + xml_root.set(kkey, str(vvalue) or "") + cmnt_text = xml_handle_comment( + xml_root, line_number, line_loc_no, is_def_cmnt=True + ) def_cmnt_text += cmnt_text if cmnt_text else [] del yml_appdef[line_number] del yml_appdef[kkey] # Taking care or name and extends - elif 'NX' in kkey: + elif "NX" in kkey: # Tacking the attribute order but the correct value will be stored later # check for name first or type first if (NXobject)NXname then type first - l_bracket_ind = kkey.rfind('(') - r_bracket_ind = kkey.rfind(')') + l_bracket_ind = kkey.rfind("(") + r_bracket_ind = kkey.rfind(")") if l_bracket_ind == 0: extend = kkey[1:r_bracket_ind] - name = kkey[r_bracket_ind + 1:] - xml_root.set('extends', extend) - xml_root.set('name', name) + name = kkey[r_bracket_ind + 1 :] + xml_root.set("extends", extend) + xml_root.set("name", name) elif l_bracket_ind > 0: name = kkey[0:l_bracket_ind] - extend = kkey[l_bracket_ind + 1: r_bracket_ind] - xml_root.set('name', name) - xml_root.set('extends', extend) + extend = kkey[l_bracket_ind + 1 : r_bracket_ind] + xml_root.set("name", name) + xml_root.set("extends", extend) else: name = kkey - xml_root.set('name', name) - xml_root.set('extends', 'NXobject') - cmnt_text = xml_handle_comment(xml_root, - line_number, line_loc_no, - is_def_cmnt=True) + xml_root.set("name", name) + xml_root.set("extends", "NXobject") + cmnt_text = xml_handle_comment( + xml_root, line_number, line_loc_no, is_def_cmnt=True + ) def_cmnt_text += cmnt_text if cmnt_text else [] name_extends = kkey - if 'type' not in xml_root.attrib: - xml_root.set('type', "group") + if "type" not in xml_root.attrib: + xml_root.set("type", "group") # Taking care of namespaces - namespaces = {'xmlns': 'http://definition.nexusformat.org/nxdl/3.1', - 'xmlns:xsi': 'http://www.w3.org/2001/XMLSchema-instance', - 'xsi:schemaLocation': 'http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd'} + namespaces = { + "xmlns": "http://definition.nexusformat.org/nxdl/3.1", + "xmlns:xsi": "http://www.w3.org/2001/XMLSchema-instance", + "xsi:schemaLocation": "http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd", + } for key, ns_ in namespaces.items(): xml_root.attrib[key] = ns_ # Taking care of Symbols elements - if 'symbols' in yml_appdef.keys(): - xml_handle_symbols(yml_appdef, - xml_root, - 'symbols', - yml_appdef['symbols']) + if "symbols" in yml_appdef.keys(): + xml_handle_symbols(yml_appdef, xml_root, "symbols", yml_appdef["symbols"]) - del yml_appdef['symbols'] + del yml_appdef["symbols"] del yml_appdef["__line__symbols"] - assert isinstance(yml_appdef['doc'], str) and yml_appdef['doc'] != '', 'Doc \ -has to be a non-empty string!' + assert ( + isinstance(yml_appdef["doc"], str) and yml_appdef["doc"] != "" + ), "Doc \ +has to be a non-empty string!" - line_number = '__line__doc' + line_number = "__line__doc" line_loc_no = yml_appdef[line_number] - xml_handle_doc(xml_root, yml_appdef['doc'], line_number, line_loc_no) + xml_handle_doc(xml_root, yml_appdef["doc"], line_number, line_loc_no) - del yml_appdef['doc'] + del yml_appdef["doc"] root_keys = 0 for key in yml_appdef.keys(): - if '__line__' not in key: + if "__line__" not in key: root_keys += 1 extra_key = key - assert root_keys == 1, (f"Accepting at most keywords: category, doc, symbols, and NX... " - f"at root-level! check key at root level {extra_key}") + assert root_keys == 1, ( + f"Accepting at most keywords: category, doc, symbols, and NX... " + f"at root-level! check key at root level {extra_key}" + ) - assert ('NX' in name_extends and len(name_extends) > 2), 'NX \ -keyword has an invalid pattern, or is too short!' + assert ( + "NX" in name_extends and len(name_extends) > 2 + ), "NX \ +keyword has an invalid pattern, or is too short!" # Taking care if definition has empty content if yml_appdef[name_extends]: recursive_build(xml_root, yml_appdef[name_extends], verbose) @@ -1158,4 +1238,4 @@ def nyaml2nxdl(input_file: str, out_file, verbose: bool): check_for_default_attribute_and_value(xml_root) pretty_print_xml(xml_root, out_file, def_cmnt_text) if verbose: - sys.stdout.write('Parsed YAML to NXDL successfully\n') + sys.stdout.write("Parsed YAML to NXDL successfully\n") diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl_helper.py b/dev_tools/nyaml2nxdl/nyaml2nxdl_helper.py index 9583b375d2..f4787bd300 100644 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl_helper.py +++ b/dev_tools/nyaml2nxdl/nyaml2nxdl_helper.py @@ -28,19 +28,17 @@ # So the corresponding value is to skip them and # and also carefull about this order import hashlib + from yaml.composer import Composer from yaml.constructor import Constructor - +from yaml.loader import Loader from yaml.nodes import ScalarNode from yaml.resolver import BaseResolver -from yaml.loader import Loader # NOTE: If any one change one of the bellow dict please change it for both -ESCAPE_CHAR_DICT_IN_YAML = {"\t": " ", - "\':\'": ":"} +ESCAPE_CHAR_DICT_IN_YAML = {"\t": " ", "':'": ":"} -ESCAPE_CHAR_DICT_IN_XML = {" ": "\t", - "\':\'": ":"} +ESCAPE_CHAR_DICT_IN_XML = {" ": "\t", "':'": ":"} class LineLoader(Loader): # pylint: disable=too-many-ancestors @@ -61,11 +59,13 @@ def construct_mapping(self, node, deep=False): for key_node in node_pair_lst: shadow_key_node = ScalarNode( - tag=BaseResolver.DEFAULT_SCALAR_TAG, value='__line__' + key_node[0].value) + tag=BaseResolver.DEFAULT_SCALAR_TAG, + value="__line__" + key_node[0].value, + ) shadow_value_node = ScalarNode( - tag=BaseResolver.DEFAULT_SCALAR_TAG, value=key_node[0].__line__) - node_pair_lst_for_appending.append( - (shadow_key_node, shadow_value_node)) + tag=BaseResolver.DEFAULT_SCALAR_TAG, value=key_node[0].__line__ + ) + node_pair_lst_for_appending.append((shadow_key_node, shadow_value_node)) node.value = node_pair_lst + node_pair_lst_for_appending return Constructor.construct_mapping(self, node, deep=deep) @@ -84,11 +84,11 @@ def get_yaml_escape_char_reverter_dict(): def type_check(nx_type): """ - Check for nexus type if type is NX_CHAR get '' or get as it is. + Check for nexus type if type is NX_CHAR get '' or get as it is. """ - if nx_type in ['NX_CHAR', '']: - nx_type = '' + if nx_type in ["NX_CHAR", ""]: + nx_type = "" else: nx_type = f"({nx_type})" return nx_type @@ -108,10 +108,10 @@ def get_node_parent_info(tree, node): def cleaning_empty_lines(line_list): """ - Cleaning up empty lines on top and bottom. + Cleaning up empty lines on top and bottom. """ if not isinstance(line_list, list): - line_list = line_list.split('\n') if '\n' in line_list else [''] + line_list = line_list.split("\n") if "\n" in line_list else [""] # Clining up top empty lines while True: @@ -119,7 +119,7 @@ def cleaning_empty_lines(line_list): break line_list = line_list[1:] if len(line_list) == 0: - line_list.append('') + line_list.append("") return line_list # Clining bottom empty lines @@ -128,7 +128,7 @@ def cleaning_empty_lines(line_list): break line_list = line_list[0:-1] if len(line_list) == 0: - line_list.append('') + line_list.append("") return line_list return line_list @@ -140,45 +140,44 @@ def nx_name_type_resolving(tmp): and type {nexus_type} from a YML section string. YML section string syntax: optional_string(nexus_type) """ - if tmp.count('(') == 1 and tmp.count(')') == 1: + if tmp.count("(") == 1 and tmp.count(")") == 1: # we can safely assume that every valid YML key resolves # either an nx_ (type, base, candidate) class contains only 1 '(' and ')' - index_start = tmp.index('(') - index_end = tmp.index(')', index_start + 1) - typ = tmp[index_start + 1:index_end] - nam = tmp.replace('(' + typ + ')', '') + index_start = tmp.index("(") + index_end = tmp.index(")", index_start + 1) + typ = tmp[index_start + 1 : index_end] + nam = tmp.replace("(" + typ + ")", "") return nam, typ # or a name for a member - typ = '' + typ = "" nam = tmp return nam, typ def get_sha256_hash(file_name): - """Generate a sha256_hash for a given file. - """ + """Generate a sha256_hash for a given file.""" sha_hash = hashlib.sha256() - with open(file=file_name, mode='rb',) as file_obj: + with open( + file=file_name, + mode="rb", + ) as file_obj: # Update hash for each 4k block of bytes for b_line in iter(lambda: file_obj.read(4096), b""): sha_hash.update(b_line) return sha_hash.hexdigest() -def extend_yamlfile_with_comment(yaml_file, - file_to_be_appended, - top_lines_list=None): - """Extend yaml file by the file_to_be_appended as comment. - """ +def extend_yamlfile_with_comment(yaml_file, file_to_be_appended, top_lines_list=None): + """Extend yaml file by the file_to_be_appended as comment.""" - with open(yaml_file, mode='a+', encoding='utf-8') as f1_obj: + with open(yaml_file, mode="a+", encoding="utf-8") as f1_obj: if top_lines_list: for line in top_lines_list: f1_obj.write(line) - with open(file_to_be_appended, mode='r', encoding='utf-8') as f2_obj: + with open(file_to_be_appended, mode="r", encoding="utf-8") as f2_obj: lines = f2_obj.readlines() for line in lines: f1_obj.write(f"# {line}") @@ -191,30 +190,30 @@ def separate_hash_yaml_and_nxdl(yaml_file, sep_yaml, sep_xml): ++++++++++++++++++++++++++++++++++\n' # ' """ - sha_hash = '' - with open(yaml_file, 'r', encoding='utf-8') as inp_file: + sha_hash = "" + with open(yaml_file, "r", encoding="utf-8") as inp_file: lines = inp_file.readlines() # file to write yaml part - with open(sep_yaml, 'w', encoding='utf-8') as yml_f_ob, \ - open(sep_xml, 'w', encoding='utf-8') as xml_f_ob: - - last_line = '' + with open(sep_yaml, "w", encoding="utf-8") as yml_f_ob, open( + sep_xml, "w", encoding="utf-8" + ) as xml_f_ob: + last_line = "" write_on_yaml = True for ind, line in enumerate(lines): if ind == 0: last_line = line # Write in file when ensured that the nest line is not with '++ SHA HASH ++' - elif '++ SHA HASH ++' not in line and write_on_yaml: + elif "++ SHA HASH ++" not in line and write_on_yaml: yml_f_ob.write(last_line) last_line = line - elif '++ SHA HASH ++' in line: + elif "++ SHA HASH ++" in line: write_on_yaml = False - last_line = '' + last_line = "" elif not write_on_yaml and not last_line: # The first line of xml file has been found. Onward write lines directly # into xml file. if not sha_hash: - sha_hash = line.split('# ', 1)[-1].strip() + sha_hash = line.split("# ", 1)[-1].strip() else: xml_f_ob.write(line[2:]) # If the yaml fiile does not contain any hash for nxdl then we may have last line. From bf1936a6fd9cf96caf132460d6d5bd71440de7e5 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Mon, 19 Jun 2023 15:12:21 +0200 Subject: [PATCH 0050/1012] linting --- dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py b/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py index ca0435e374..56a33a453c 100644 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py +++ b/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py @@ -978,8 +978,8 @@ def xml_handle_comment( """ line_info = (line_annotation, int(line_loc_no)) - if line_info in COMMENT_BLOCKS: - cmnt = COMMENT_BLOCKS.get_coment_by_line_info(line_info) + if line_info in COMMENT_BLOCKS: # noqa: F821 + cmnt = COMMENT_BLOCKS.get_coment_by_line_info(line_info) # noqa: F821 cmnt_text = cmnt.get_comment_text() if is_def_cmnt: @@ -1227,8 +1227,8 @@ def nyaml2nxdl(input_file: str, out_file, verbose: bool): recursive_build(xml_root, yml_appdef[name_extends], verbose) # Taking care of comments that comes at the end of file that is might not be intended for # any nxdl elements. - if COMMENT_BLOCKS[-1].has_post_comment: - post_comment = COMMENT_BLOCKS[-1] + if COMMENT_BLOCKS[-1].has_post_comment: # noqa: F821 + post_comment = COMMENT_BLOCKS[-1] # noqa: F821 (lin_annot, line_loc) = post_comment.get_line_info() xml_handle_comment(xml_root, lin_annot, line_loc) From 9c28230b7a8a396e4468cb59e1bb19c937189072 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Mon, 19 Jun 2023 15:48:06 +0200 Subject: [PATCH 0051/1012] imports --- dev_tools/nyaml2nxdl/comment_collector.py | 2 +- .../nyaml2nxdl/nyaml2nxdl_backward_tools.py | 8 ++++---- .../nyaml2nxdl/nyaml2nxdl_forward_tools.py | 20 +++++++++---------- 3 files changed, 15 insertions(+), 15 deletions(-) diff --git a/dev_tools/nyaml2nxdl/comment_collector.py b/dev_tools/nyaml2nxdl/comment_collector.py index dcb21021be..0041c14ec4 100644 --- a/dev_tools/nyaml2nxdl/comment_collector.py +++ b/dev_tools/nyaml2nxdl/comment_collector.py @@ -38,7 +38,7 @@ from typing import Type from typing import Union -from pynxtools.nyaml2nxdl.nyaml2nxdl_helper import LineLoader +from .nyaml2nxdl_helper import LineLoader __all__ = ["Comment", "CommentCollector", "XMLComment", "YAMLComment"] diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py b/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py index faa22cc23e..c0f672305a 100755 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py +++ b/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py @@ -27,10 +27,10 @@ from typing import Dict from typing import List -from pynxtools.dataconverter.helpers import remove_namespace_from_tag -from pynxtools.nyaml2nxdl.nyaml2nxdl_helper import cleaning_empty_lines -from pynxtools.nyaml2nxdl.nyaml2nxdl_helper import get_node_parent_info -from pynxtools.nyaml2nxdl.nyaml2nxdl_helper import get_yaml_escape_char_dict +from .nyaml2nxdl_helper import remove_namespace_from_tag +from .nyaml2nxdl_helper import cleaning_empty_lines +from .nyaml2nxdl_helper import get_node_parent_info +from .nyaml2nxdl_helper import get_yaml_escape_char_dict DEPTH_SIZE = " " CMNT_TAG = "!--" diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py b/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py index 56a33a453c..85b3ece550 100644 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py +++ b/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py @@ -28,13 +28,13 @@ from xml.dom import minidom import yaml -from pynxtools.dataconverter.helpers import remove_namespace_from_tag -from pynxtools.nexus import nexus -from pynxtools.nyaml2nxdl.comment_collector import CommentCollector -from pynxtools.nyaml2nxdl.nyaml2nxdl_helper import LineLoader -from pynxtools.nyaml2nxdl.nyaml2nxdl_helper import cleaning_empty_lines -from pynxtools.nyaml2nxdl.nyaml2nxdl_helper import get_yaml_escape_char_reverter_dict -from pynxtools.nyaml2nxdl.nyaml2nxdl_helper import nx_name_type_resolving +from .nyaml2nxdl_helper import remove_namespace_from_tag +from ..utils import nexus as pynxtools_nxlib +from .nyaml2nxdl.comment_collector import CommentCollector +from .nyaml2nxdl_helper import LineLoader +from .nyaml2nxdl_helper import cleaning_empty_lines +from .nyaml2nxdl_helper import get_yaml_escape_char_reverter_dict +from .nyaml2nxdl_helper import nx_name_type_resolving # pylint: disable=too-many-lines, global-statement, invalid-name DOM_COMMENT = ( @@ -59,13 +59,13 @@ "#\n" "# For further information, see http://www.nexusformat.org\n" ) -NX_CLSS = nexus.get_nx_classes() +NX_CLSS = pynxtools_nxlib.get_nx_classes() NX_NEW_DEFINED_CLASSES = ["NX_COMPLEX"] -NX_TYPE_KEYS = nexus.get_nx_attribute_type() +NX_TYPE_KEYS = pynxtools_nxlib.get_nx_attribute_type() NX_ATTR_IDNT = "\\@" NX_UNIT_IDNT = "unit" DEPTH_SIZE = " " -NX_UNIT_TYPES = nexus.get_nx_units() +NX_UNIT_TYPES = pynxtools_nxlib.get_nx_units() COMMENT_BLOCKS: CommentCollector CATEGORY = "" # Definition would be either 'base' or 'application' From ddaaa6956471c44b2ec4c67a8914cc357d7a7bd2 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Mon, 19 Jun 2023 15:57:55 +0200 Subject: [PATCH 0052/1012] fixing imports --- dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py | 2 +- dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py b/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py index c0f672305a..dcf56b998d 100755 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py +++ b/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py @@ -27,10 +27,10 @@ from typing import Dict from typing import List -from .nyaml2nxdl_helper import remove_namespace_from_tag from .nyaml2nxdl_helper import cleaning_empty_lines from .nyaml2nxdl_helper import get_node_parent_info from .nyaml2nxdl_helper import get_yaml_escape_char_dict +from .nyaml2nxdl_helper import remove_namespace_from_tag DEPTH_SIZE = " " CMNT_TAG = "!--" diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py b/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py index 85b3ece550..d54aa9f934 100644 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py +++ b/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py @@ -28,13 +28,14 @@ from xml.dom import minidom import yaml -from .nyaml2nxdl_helper import remove_namespace_from_tag + from ..utils import nexus as pynxtools_nxlib from .nyaml2nxdl.comment_collector import CommentCollector from .nyaml2nxdl_helper import LineLoader from .nyaml2nxdl_helper import cleaning_empty_lines from .nyaml2nxdl_helper import get_yaml_escape_char_reverter_dict from .nyaml2nxdl_helper import nx_name_type_resolving +from .nyaml2nxdl_helper import remove_namespace_from_tag # pylint: disable=too-many-lines, global-statement, invalid-name DOM_COMMENT = ( From 357a6a896d0309ea906290aea7084cc93d604ed1 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Mon, 19 Jun 2023 18:19:29 +0200 Subject: [PATCH 0053/1012] test case added --- dev_tools/nyaml2nxdl/nyaml2nxdl.py | 24 +- .../nyaml2nxdl/nyaml2nxdl_forward_tools.py | 2 +- dev_tools/tests/test_nyaml2nxdl.py | 383 +----------------- 3 files changed, 34 insertions(+), 375 deletions(-) diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl.py b/dev_tools/nyaml2nxdl/nyaml2nxdl.py index 815b015e62..dccfff6e40 100755 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl.py +++ b/dev_tools/nyaml2nxdl/nyaml2nxdl.py @@ -26,13 +26,14 @@ import xml.etree.ElementTree as ET import click -from pynxtools.nyaml2nxdl.nyaml2nxdl_backward_tools import Nxdl2yaml -from pynxtools.nyaml2nxdl.nyaml2nxdl_backward_tools import compare_niac_and_my -from pynxtools.nyaml2nxdl.nyaml2nxdl_forward_tools import nyaml2nxdl -from pynxtools.nyaml2nxdl.nyaml2nxdl_forward_tools import pretty_print_xml -from pynxtools.nyaml2nxdl.nyaml2nxdl_helper import extend_yamlfile_with_comment -from pynxtools.nyaml2nxdl.nyaml2nxdl_helper import get_sha256_hash -from pynxtools.nyaml2nxdl.nyaml2nxdl_helper import separate_hash_yaml_and_nxdl + +from .nyaml2nxdl_backward_tools import Nxdl2yaml +from .nyaml2nxdl_backward_tools import compare_niac_and_my +from .nyaml2nxdl_forward_tools import nyaml2nxdl +from .nyaml2nxdl_forward_tools import pretty_print_xml +from .nyaml2nxdl_helper import extend_yamlfile_with_comment +from .nyaml2nxdl_helper import get_sha256_hash +from .nyaml2nxdl_helper import separate_hash_yaml_and_nxdl DEPTH_SIZE = 4 * " " @@ -152,15 +153,18 @@ def split_name_and_extension(file_name): Split file name into extension and rest of the file name. return file raw nam and extension """ - parts = file_name.rsplit(".", 3) + path = file_name.rsplit("/", 1) + (pathn, filen) = ["", path[0]] if len(path) == 1 else [path[0] + "/", path[1]] + parts = filen.rsplit(".", 2) + raw = ext = "" if len(parts) == 2: raw = parts[0] ext = parts[1] - if len(parts) == 3: + elif len(parts) == 3: raw = parts[0] ext = ".".join(parts[1:]) - return raw, ext + return pathn + raw, ext @click.command() diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py b/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py index d54aa9f934..984d7674f0 100644 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py +++ b/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py @@ -30,7 +30,7 @@ import yaml from ..utils import nexus as pynxtools_nxlib -from .nyaml2nxdl.comment_collector import CommentCollector +from .comment_collector import CommentCollector from .nyaml2nxdl_helper import LineLoader from .nyaml2nxdl_helper import cleaning_empty_lines from .nyaml2nxdl_helper import get_yaml_escape_char_reverter_dict diff --git a/dev_tools/tests/test_nyaml2nxdl.py b/dev_tools/tests/test_nyaml2nxdl.py index d0c9f875a5..2722cf4755 100755 --- a/dev_tools/tests/test_nyaml2nxdl.py +++ b/dev_tools/tests/test_nyaml2nxdl.py @@ -1,372 +1,27 @@ -#!/usr/bin/env python3 -"""This tool accomplishes some tests for the yaml2nxdl parser - -""" -# -# 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. -# - import os -import sys -import filecmp -from datetime import datetime -from pathlib import Path -import xml.etree.ElementTree as ET -import pytest -from click.testing import CliRunner -import pynxtools.nyaml2nxdl.nyaml2nxdl as nyml2nxdl -from pynxtools.nyaml2nxdl import nyaml2nxdl_forward_tools - - -def delete_duplicates(list_of_matching_string): - """ - Delete duplicate from lists - """ - return list(dict.fromkeys(list_of_matching_string)) - - -def check_file_fresh_baked(test_file): - """ - Get sure that the test file is generated by the converter - """ - path = Path(test_file) - timestamp = datetime.fromtimestamp(path.stat().st_mtime).strftime("%d/%m/%Y %H:%M") - now = datetime.now().strftime("%d/%m/%Y %H:%M") - assert timestamp == now, 'xml file not generated' - - -def find_matches(xml_file, desired_matches): - """ - Read xml file and find desired matches. Return a list of two lists in the form: - [[matching_line],[matching_line_index]] - """ - with open(xml_file, 'r') as file: - xml_reference = file.readlines() - lines = [] - lines_index = [] - found_matches = [] - for i, line in enumerate(xml_reference): - for desired_match in desired_matches: - if str(desired_match) in str(line): - lines.append(line) - lines_index.append(i) - found_matches.append(desired_match) - # ascertain that all the desired matches were found in file - found_matches_clean = delete_duplicates(found_matches) - assert len(found_matches_clean) == len(desired_matches), 'some desired_matches were \ -not found in file' - return [lines, lines_index] - - -def compare_matches(ref_xml_file, test_yml_file, test_xml_file, desired_matches): - """ - Check if a new xml file is generated - and if test xml file is equal to reference xml file - """ - # Reference file is read - ref_matches = find_matches(ref_xml_file, desired_matches) - # Test file is generated - runner = CliRunner() - result = runner.invoke(nyml2nxdl.launch_tool, ['--input-file', test_yml_file]) - assert result.exit_code == 0 - check_file_fresh_baked(test_xml_file) - # Test file is read - test_matches = find_matches(test_xml_file, desired_matches) - assert test_matches == ref_matches - - -def test_links(): - """ - Check the correct parsing of links - """ - data_path = os.path.join(os.path.dirname(os.path.abspath(__file__)), - '../data/nyaml2nxdl') - ref_xml_link_file = 'tests/data/nyaml2nxdl/Ref_NXtest_links.nxdl.xml' - test_yml_link_file = 'tests/data/nyaml2nxdl/NXtest_links.yaml' - test_xml_link_file = 'tests/data/nyaml2nxdl/NXtest_links.nxdl.xml' - # ref_xml_link_file = os.path.abspath(data_path + '/Ref_NXtest_links.nxdl.xml') - # test_yml_link_file = os.path.abspath(data_path + '/NXtest_links.yaml') - # test_xml_link_file = os.path.abspath(data_path + '/NXtest_links.nxdl.xml') - desired_matches = [''] - compare_matches( - ref_xml_link_file, - test_yml_link_file, - test_xml_link_file, - desired_matches) - os.remove('tests/data/nyaml2nxdl/NXtest_links.nxdl.xml') - sys.stdout.write('Test on links okay.\n') - - -def test_docs(): - """In this test an xml file in converted to yml and then back to xml. - The xml trees of the two files are then compared. - """ - ref_xml_file = 'tests/data/nyaml2nxdl/Ref_NXellipsometry-docCheck.nxdl.xml' - test_yml_file = 'tests/data/nyaml2nxdl/NXellipsometry-docCheck.yaml' - test_xml_file = 'tests/data/nyaml2nxdl/NXellipsometry-docCheck.nxdl.xml' - desired_matches = [''] - compare_matches( - ref_xml_file, - test_yml_file, - test_xml_file, - desired_matches) - os.remove('tests/data/nyaml2nxdl/NXellipsometry-docCheck.nxdl.xml') - sys.stdout.write('Test on documentation formatting okay.\n') - - -def test_nxdl2yaml_doc_format_and_nxdl_part_as_comment(): - """ - This test for two reason: - 1. In test-1 an nxdl file with all kind of doc formats are translated - to yaml to check if they are correct. - 2. In test-2: Check the nxdl that comes at the end of yaml file as comment. - """ - ref_xml_file = 'tests/data/nyaml2nxdl/Ref_NXentry.nxdl.xml' - ref_yml_file = 'tests/data/nyaml2nxdl/Ref_NXentry.yaml' - test_yml_file = 'tests/data/nyaml2nxdl/Ref_NXentry_parsed.yaml' - result = CliRunner().invoke(nyml2nxdl.launch_tool, ['--input-file', ref_xml_file]) - assert result.exit_code == 0 - check_file_fresh_baked(test_yml_file) - - result = filecmp.cmp(ref_yml_file, test_yml_file, shallow=False) - assert result, 'Ref YML and parsed YML\ -has not the same structure!!' - os.remove(test_yml_file) - sys.stdout.write('Test on xml -> yml doc formatting okay.\n') - - -def test_fileline_error(): - """ - In this test the yaml fileline in the error message is tested. - """ - test_yml_file = 'tests/data/nyaml2nxdl/NXfilelineError1.yaml' - out_nxdl = 'tests/data/nyaml2nxdl/NXfilelineError1.nxdl.xml' - out_yaml = 'tests/data/nyaml2nxdl/temp_NXfilelineError1.yaml' - result = CliRunner().invoke(nyml2nxdl.launch_tool, ['--input-file', test_yml_file]) - assert result.exit_code == 1 - assert '13' in str(result.exception) - os.remove(out_nxdl) - os.remove(out_yaml) - - test_yml_file = 'tests/data/nyaml2nxdl/NXfilelineError2.yaml' - out_nxdl = 'tests/data/nyaml2nxdl/NXfilelineError2.nxdl.xml' - out_yaml = 'tests/data/nyaml2nxdl/temp_NXfilelineError2.yaml' - result = CliRunner().invoke(nyml2nxdl.launch_tool, ['--input-file', test_yml_file]) - assert result.exit_code == 1 - assert '21' in str(result.exception) - os.remove(out_nxdl) - os.remove(out_yaml) - - test_yml_file = 'tests/data/nyaml2nxdl/NXfilelineError3.yaml' - out_nxdl = 'tests/data/nyaml2nxdl/NXfilelineError3.nxdl.xml' - out_yaml = 'tests/data/nyaml2nxdl/temp_NXfilelineError3.yaml' - result = CliRunner().invoke(nyml2nxdl.launch_tool, ['--input-file', test_yml_file]) - assert result.exit_code == 1 - assert '25' in str(result.exception) - os.remove(out_nxdl) - os.remove(out_yaml) - - sys.stdout.write('Test on xml -> yml fileline error handling okay.\n') - - -def test_symbols(): - """ - Check the correct parsing of symbols - """ - ref_xml_symbol_file = 'tests/data/nyaml2nxdl/Ref_NXnested_symbols.nxdl.xml' - test_yml_symbol_file = 'tests/data/nyaml2nxdl/NXnested_symbols.yaml' - test_xml_symbol_file = 'tests/data/nyaml2nxdl/NXnested_symbols.nxdl.xml' - desired_matches = ['', '', '', '', '', - '', ''] - compare_matches( - ref_xml_attribute_file, - test_yml_attribute_file, - test_xml_attribute_file, - desired_matches) - os.remove('tests/data/nyaml2nxdl/NXattributes.nxdl.xml') - sys.stdout.write('Test on attributes okay.\n') +from click.testing import CliRunner -def test_extends(): - """ - Check the correct handling of extends keyword - """ - ref_xml_attribute_file = 'tests/data/nyaml2nxdl/Ref_NXattributes.nxdl.xml' - test_yml_attribute_file = 'tests/data/nyaml2nxdl/NXattributes.yaml' - test_xml_attribute_file = 'tests/data/nyaml2nxdl/NXattributes.nxdl.xml' - runner = CliRunner() - result = runner.invoke(nyml2nxdl.launch_tool, ['--input-file', test_yml_attribute_file]) - assert result.exit_code == 0 - ref_root_node = ET.parse(ref_xml_attribute_file).getroot() - test_root_node = ET.parse(test_xml_attribute_file).getroot() - assert ref_root_node.attrib == test_root_node.attrib - os.remove('tests/data/nyaml2nxdl/NXattributes.nxdl.xml') - sys.stdout.write('Test on extends keyword okay.\n') - - -def test_symbols_and_enum_docs(): - """ - Check the correct handling of empty attributes - or attributes fields, e.g. doc - """ - ref_xml_file = 'tests/data/nyaml2nxdl/Ref_NXmytests.nxdl.xml' - test_yml_file = 'tests/data/nyaml2nxdl/NXmytests.yaml' - test_xml_file = 'tests/data/nyaml2nxdl/NXmytests.nxdl.xml' - desired_matches = ['', '', '', - '', '', '', ' yml -> xml okay.\n') +# import subprocess -def test_yml_parsing(): - """In this test an xml file in converted to yml and then back to xml. - The xml trees of the two files are then compared. - """ - ref_yml_file = 'tests/data/nyaml2nxdl/Ref_NXellipsometry.yaml' - test_xml_file = 'tests/data/nyaml2nxdl/Ref_NXellipsometry.nxdl.xml' - test_yml_file = 'tests/data/nyaml2nxdl/Ref_NXellipsometry_parsed.yaml' - result = CliRunner().invoke(nyml2nxdl.launch_tool, ['--input-file', ref_yml_file]) - assert result.exit_code == 0 - check_file_fresh_baked(test_xml_file) - result = CliRunner().invoke(nyml2nxdl.launch_tool, ['--input-file', test_xml_file]) +def test_conversion(): + root = find_definition_file("NXentry") + # subprocess.run(["python3","-m","dev_tools.nyaml2nxdl.nyaml2nxdl","--input-file",root]) + result = CliRunner().invoke(conv.launch_tool, ["--input-file", root]) assert result.exit_code == 0 - check_file_fresh_baked(test_yml_file) - - test_yml_tree = nyaml2nxdl_forward_tools.yml_reader(test_yml_file) - - ref_yml_tree = nyaml2nxdl_forward_tools.yml_reader(ref_yml_file) - - assert list(test_yml_tree) == list(ref_yml_tree), 'Ref YML and parsed YML \ -has not the same root entries!!' - os.remove('tests/data/nyaml2nxdl/Ref_NXellipsometry_parsed.yaml') - os.remove('tests/data/nyaml2nxdl/Ref_NXellipsometry.nxdl.xml') - sys.stdout.write('Test on yml -> xml -> yml okay.\n') - - -def test_yml_consistency_comment_parsing(): - """Test comments parsing from yaml. Convert 'yaml' input file to '.nxdl.xml' and - '.nxdl.xml' to '.yaml' - """ - from pynxtools.nyaml2nxdl.comment_collector import CommentCollector - from pynxtools.nyaml2nxdl.nyaml2nxdl_helper import LineLoader - - ref_yml_file = 'tests/data/nyaml2nxdl/Ref_NXcomment.yaml' - test_yml_file = 'tests/data/nyaml2nxdl/Ref_NXcomment_consistency.yaml' - - result = CliRunner().invoke(nyml2nxdl.launch_tool, - ['--input-file', ref_yml_file, - '--check-consistency']) - assert result.exit_code == 0, (f'Exception: {result.exception}, \nExecution Info:' - '{result.exc_info}') - with open(ref_yml_file, 'r', encoding='utf-8') as ref_yml: - loader = LineLoader(ref_yml) - ref_loaded_yaml = loader.get_single_data() - ref_comment_blocks = CommentCollector(ref_yml_file, ref_loaded_yaml) - ref_comment_blocks.extract_all_comment_blocks() - - with open(test_yml_file, 'r', encoding='utf-8') as test_yml: - loader = LineLoader(test_yml) - test_loaded_yaml = loader.get_single_data() - test_comment_blocks = CommentCollector(test_yml_file, test_loaded_yaml) - test_comment_blocks.extract_all_comment_blocks() - - for ref_cmnt, test_cmnt in zip(ref_comment_blocks, test_comment_blocks): - assert ref_cmnt == test_cmnt, 'Comment is not consistent.' - - os.remove(test_yml_file) - - -def test_yml2xml_comment_parsing(): - """To test comment that written in xml for element attributes, e.g. - attribute 'rank' for 'dimension' element and attribute 'exists' for - 'NXentry' group element. - """ - input_yml = 'tests/data/nyaml2nxdl/NXcomment_yaml2nxdl.yaml' - ref_xml = 'tests/data/nyaml2nxdl/Ref_NXcomment_yaml2nxdl.nxdl.xml' - test_xml = 'tests/data/nyaml2nxdl/NXcomment_yaml2nxdl.nxdl.xml' - - result = CliRunner().invoke(nyml2nxdl.launch_tool, - ['--input-file', input_yml]) + yaml = root[:-9] + "_parsed.yaml" + # subprocess.run(["python3","-m","dev_tools.nyaml2nxdl.nyaml2nxdl","--input-file",yaml]) + result = CliRunner().invoke(conv.launch_tool, ["--input-file", yaml]) assert result.exit_code == 0 - - ref_root = ET.parse(ref_xml).getroot() - test_root = ET.parse(test_xml).getroot() - - def recursive_compare(ref_root, test_root): - assert ref_root.attrib.items() == test_root.attrib.items(), ("Got different xml element" - "Atribute.") - if ref_root.text and test_root.text: - assert ref_root.text.strip() == test_root.text.strip(), ("Got differen element text.") - if len(ref_root) > 0 and len(test_root) > 0: - for x, y in zip(ref_root, test_root): - recursive_compare(x, y) - - recursive_compare(ref_root, test_root) - - os.remove(test_xml) + new_root = yaml[:-4] + "nxdl.xml" + with open(root, encoding="utf-8", mode="r") as tmp_f: + root_content = tmp_f.readlines() + with open(new_root, encoding="utf-8", mode="r") as tmp_f: + new_root_content = tmp_f.readlines() + assert root_content == new_root_content + os.remove(yaml) + os.remove(new_root) From 948b044485594f27ed0cee4f4584ff56747c4b40 Mon Sep 17 00:00:00 2001 From: Sherjeel Shabih Date: Wed, 12 Jul 2023 10:19:43 +0200 Subject: [PATCH 0054/1012] Moved over changes from older nyaml PR --- .gitignore | 5 ----- Makefile | 13 +++++++++++++ pyproject.toml | 3 ++- requirements.txt | 1 + 4 files changed, 16 insertions(+), 6 deletions(-) diff --git a/.gitignore b/.gitignore index 7f125837e5..7867d76657 100644 --- a/.gitignore +++ b/.gitignore @@ -1,6 +1,5 @@ # Hidden files .* -!.github # Python byte / compiled / optimized *.py[cod] @@ -10,10 +9,6 @@ __pycache__/ build/ makelog.txt -# Unknown -/python/ -__github_creds__.txt - # Distribution / packaging .Python build/ diff --git a/Makefile b/Makefile index ae556d7339..113e29db8a 100644 --- a/Makefile +++ b/Makefile @@ -6,6 +6,7 @@ PYTHON = python3 SPHINX = sphinx-build BUILD_DIR = "build" +NXDL_DIRS := contributed_definitions applications base_classes .PHONY: help install style autoformat test clean prepare html pdf impatient-guide all local @@ -49,6 +50,9 @@ test :: clean :: $(RM) -rf $(BUILD_DIR) + for dir in $(NXDL_DIRS); do\ + $(RM) -rf $${dir}/nyaml;\ + done prepare :: $(PYTHON) -m dev_tools manual --prepare --build-root $(BUILD_DIR) @@ -83,6 +87,15 @@ all :: @echo "HTML built: `ls -lAFgh $(BUILD_DIR)/manual/build/html/index.html`" @echo "PDF built: `ls -lAFgh $(BUILD_DIR)/manual/build/latex/nexus.pdf`" +NXDLS := $(foreach dir,$(NXDL_DIRS),$(wildcard $(dir)/*.nxdl.xml)) +nyaml : $(DIRS) $(NXDLS) + for file in $^; do\ + mkdir -p "$${file%/*}/nyaml";\ + nyaml2nxdl --input-file $${file};\ + FNAME=$${file##*/};\ + mv -- "$${file%.nxdl.xml}_parsed.yaml" "$${file%/*}/nyaml/$${FNAME%.nxdl.xml}.yaml";\ + done + # NeXus - Neutron and X-ray Common Data Format # diff --git a/pyproject.toml b/pyproject.toml index 979c51eac0..67878319bb 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -18,9 +18,9 @@ classifiers = [ dependencies = [ "lxml", "pyyaml", + "click>=7.1.2", "sphinx>=5", "sphinx-tabs", - "sphinx-toolbox", "pytest", "black>=22.3", "flake8>=4", @@ -31,6 +31,7 @@ dependencies = [ "Homepage" = "https://nexusformat.org" [project.scripts] +nyaml2nxdl = "dev_tools.nyaml2nxdl.nyaml2nxdl:launch_tool" [tools.setuptools_scm] version_scheme = "guess-next-dev" diff --git a/requirements.txt b/requirements.txt index 54b7bb86f8..91c5ae31a1 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1,6 +1,7 @@ # Prepare for Documentation lxml pyyaml +click # Documentation building sphinx>=5 From bd2d198f0de4d8e760bdfe5dc5f9594102bc4ae2 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Wed, 12 Jul 2023 14:17:06 +0200 Subject: [PATCH 0055/1012] linting --- dev_tools/docs/nxdl.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dev_tools/docs/nxdl.py b/dev_tools/docs/nxdl.py index 0369a62973..b873e32871 100755 --- a/dev_tools/docs/nxdl.py +++ b/dev_tools/docs/nxdl.py @@ -12,8 +12,8 @@ from ..globals.errors import NXDLParseError from ..globals.nxdl import NXDL_NAMESPACE from ..globals.urls import REPO_URL -from ..utils.github import get_file_contributors_via_api from ..utils import nxdl_utils as pynxtools_nxlib +from ..utils.github import get_file_contributors_via_api from ..utils.types import PathLike from .anchor_list import AnchorRegistry From 1e959c09ab9d2d4dc2a1f0fb146c8efa2b72dcfc Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Wed, 12 Jul 2023 16:09:42 +0200 Subject: [PATCH 0056/1012] make nxdl command is added to support the reverse covertsion that was requested during code camp --- Makefile | 9 +++++++++ README.md | 14 +++++++++++++- 2 files changed, 22 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 113e29db8a..eff518f189 100644 --- a/Makefile +++ b/Makefile @@ -96,6 +96,15 @@ nyaml : $(DIRS) $(NXDLS) mv -- "$${file%.nxdl.xml}_parsed.yaml" "$${file%/*}/nyaml/$${FNAME%.nxdl.xml}.yaml";\ done +NYAMLS := $(foreach dir,$(NXDL_DIRS),$(wildcard $(dir)/nyaml/*.yaml)) +nxdl : $(DIRS) $(NYAMLS) + for file in $^; do\ + mkdir -p "$${file%/*}/nyaml";\ + nyaml2nxdl --input-file $${file};\ + FNAME=$${file##*/};\ + mv -- "$${file%.yaml}.nxdl.xml" "$${file%/*}/../$${FNAME%.yaml}.nxdl.xml";\ + done + # NeXus - Neutron and X-ray Common Data Format # diff --git a/README.md b/README.md index 76112c7704..914d51f684 100755 --- a/README.md +++ b/README.md @@ -7,6 +7,10 @@ ## NeXus definition developers +Note if this package was not properly installed using pip, it has to be first done by + + pip install -e . + After making a change to the NeXus class definitions there are two important checks to be made before commiting the change: @@ -25,6 +29,14 @@ Open the HTML manual in a web brower for visual verification firefox build/manual/build/html/index.html +Convenient editting of definitinos is available in nyaml format. For this, definitinos need to be converted first from xml to yaml format by the command + + make nyaml + +After editing the definitions in nyaml format in the nyaml subdirectories, the following command can be used to update the definitins in nxdl.xml format: + + make nxdl + ### HTML pages with contributor information To build the html pages that contains contributor information on the sidebar set a github access token to an environment variable called GH_TOKEN. @@ -57,4 +69,4 @@ package/ | directory for packaging this content utils/ | various tools used in the definitions tree www/ | launch (home) page of NeXus WWW site xslt/ | various XML stylesheet transformations -dev_tools/ | developer tools for testing and building \ No newline at end of file +dev_tools/ | developer tools for testing and building From 0f4d7233762a906c4b927a16f8d05b4f840c20c7 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Wed, 12 Jul 2023 16:30:22 +0200 Subject: [PATCH 0057/1012] fixing typos and dependencies --- README.md | 4 ++-- dev_tools/nyaml2nxdl/README.md | 8 ++++---- dev_tools/nyaml2nxdl/nyaml2nxdl.py | 2 +- pyproject.toml | 1 + 4 files changed, 8 insertions(+), 7 deletions(-) diff --git a/README.md b/README.md index 914d51f684..4f4020aa6f 100755 --- a/README.md +++ b/README.md @@ -29,11 +29,11 @@ Open the HTML manual in a web brower for visual verification firefox build/manual/build/html/index.html -Convenient editting of definitinos is available in nyaml format. For this, definitinos need to be converted first from xml to yaml format by the command +Convenient editting of definitions is available in nyaml format. For this, definitions need to be converted first from xml to yaml format by the command make nyaml -After editing the definitions in nyaml format in the nyaml subdirectories, the following command can be used to update the definitins in nxdl.xml format: +After editing the definitions in nyaml format in the nyaml subdirectories, the following command can be used to update the definitions in nxdl.xml format: make nxdl diff --git a/dev_tools/nyaml2nxdl/README.md b/dev_tools/nyaml2nxdl/README.md index ff083e1896..ec69275c25 100644 --- a/dev_tools/nyaml2nxdl/README.md +++ b/dev_tools/nyaml2nxdl/README.md @@ -7,7 +7,7 @@ such as base or contributed classes. Users either create NeXus instances by writ The forward (YAML -> NXDL.XML) and backward (NXDL.XML -> YAML) conversions are implemented. **How the tool works**: -- yaml2nxdl.py +- nyaml2nxdl.py 1. Reads the user-specified NeXus instance, either in YML or XML format. 2. If input is in YAML, creates an instantiated NXDL schema XML tree by walking the dictionary nest. If input is in XML, creates a YML file walking the dictionary nest. @@ -16,12 +16,12 @@ The forward (YAML -> NXDL.XML) and backward (NXDL.XML -> YAML) conversions are i the XML or YAML input file is interpreted as an extension of a base class and the entries contained in it are appended below a standard NeXus base class. You need to specify both your input file (with YAML or XML extension) and NeXus class (with no extension). - Both .yml and .nxdl.xml file of the extended class are printed. + Both .yaml and .nxdl.xml file of the extended class are printed. ```console -user@box:~$ python yaml2nxdl.py +user@box:~$ python nyaml2nxdl.py -Usage: python yaml2nxdl.py [OPTIONS] +Usage: python nyaml2nxdl.py [OPTIONS] Options: --input-file TEXT The path to the input data file to read. diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl.py b/dev_tools/nyaml2nxdl/nyaml2nxdl.py index dccfff6e40..29d2db04ff 100755 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl.py +++ b/dev_tools/nyaml2nxdl/nyaml2nxdl.py @@ -1,5 +1,5 @@ #!/usr/bin/env python3 -"""Main file of yaml2nxdl tool. +"""Main file of nyaml2nxdl tool. Users create NeXus instances by writing a YAML file which details a hierarchy of data/metadata elements diff --git a/pyproject.toml b/pyproject.toml index 67878319bb..f4377ff3f4 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -21,6 +21,7 @@ dependencies = [ "click>=7.1.2", "sphinx>=5", "sphinx-tabs", + "sphinx-toolbox", "pytest", "black>=22.3", "flake8>=4", From 020175fcf4d5d0513c1ff015ae291fff930f57e8 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Fri, 14 Jul 2023 13:16:51 +0200 Subject: [PATCH 0058/1012] add again the lost function remove_namespace_from_tag --- dev_tools/nyaml2nxdl/nyaml2nxdl_helper.py | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl_helper.py b/dev_tools/nyaml2nxdl/nyaml2nxdl_helper.py index f4787bd300..c55f5da7a8 100644 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl_helper.py +++ b/dev_tools/nyaml2nxdl/nyaml2nxdl_helper.py @@ -41,6 +41,12 @@ ESCAPE_CHAR_DICT_IN_XML = {" ": "\t", "':'": ":"} +def remove_namespace_from_tag(tag): + """Helper function to remove the namespace from an XML tag.""" + + return tag.split("}")[-1] + + class LineLoader(Loader): # pylint: disable=too-many-ancestors """ LineLoader parses a yaml into a python dictionary extended with extra items. From ce20d6bd6ad15e33610cbcb57d246c76936e8864 Mon Sep 17 00:00:00 2001 From: domna Date: Tue, 18 Jul 2023 17:08:47 +0200 Subject: [PATCH 0059/1012] Fixes versioning --- pyproject.toml | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/pyproject.toml b/pyproject.toml index 979c51eac0..8a9e383dbf 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -30,10 +30,8 @@ dependencies = [ [project.urls] "Homepage" = "https://nexusformat.org" -[project.scripts] - -[tools.setuptools_scm] -version_scheme = "guess-next-dev" +[tool.setuptools_scm] +version_scheme = "no-guess-dev" local_scheme = "node-and-date" [tool.setuptools] From d2b57cfbd04469b4284ab1c18a001deee22efd80 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Wed, 19 Jul 2023 12:55:12 +0200 Subject: [PATCH 0060/1012] restore pages for FAIRmat proposal site --- .github/nexus-fairmat-gen-docs.yml | 94 ++++++++++++ .github/workflows/nexus-fairmat-gen-docs.yml | 98 +++++++++++++ manual/source/_static/blockquote.css.bak | 23 +++ manual/source/_static/to_alabaster.css | 65 +++++++++ manual/source/_static/to_rtd.css | 10 ++ manual/source/conf.py | 86 ++++++++--- manual/source/fairmat-cover.rst | 146 +++++++++++++++++++ manual/source/img/FAIRmat.png | Bin 0 -> 114746 bytes manual/source/index.rst | 54 ++++--- manual/source/laboratory-structure.rst | 25 ++++ manual/source/nexus-index.rst | 20 +++ manual/source/sed/entry-page.html | 6 + manual/source/stm-structure.rst | 32 ++++ 13 files changed, 618 insertions(+), 41 deletions(-) create mode 100644 .github/nexus-fairmat-gen-docs.yml create mode 100644 .github/workflows/nexus-fairmat-gen-docs.yml create mode 100644 manual/source/_static/blockquote.css.bak create mode 100644 manual/source/_static/to_alabaster.css create mode 100644 manual/source/_static/to_rtd.css create mode 100644 manual/source/fairmat-cover.rst create mode 100644 manual/source/img/FAIRmat.png create mode 100644 manual/source/laboratory-structure.rst create mode 100644 manual/source/nexus-index.rst create mode 100644 manual/source/sed/entry-page.html create mode 100644 manual/source/stm-structure.rst diff --git a/.github/nexus-fairmat-gen-docs.yml b/.github/nexus-fairmat-gen-docs.yml new file mode 100644 index 0000000000..4d7e3813a4 --- /dev/null +++ b/.github/nexus-fairmat-gen-docs.yml @@ -0,0 +1,94 @@ +name: Publish Sphinx Docs to GitHub Pages +on: [push] + +# see: https://sphinx-notes.github.io/pages/ +# see: https://github.com/marketplace/actions/sphinx-to-github-pages + +jobs: + + build: + runs-on: ubuntu-latest + + steps: + - name: Checkout + uses: actions/checkout@master + with: + fetch-depth: 0 # otherwise, you will fail to push refs to dest repo + + - name: Install build requirements + run: | + pip install -r requirements.txt + - name: Diagnostic + run: | + pip list + - name: Run the test suite + run: | + # stops publishing when known problems are found + python utils/test_suite.py + - name: Prepare for out-of-source Sphinx build + run: | + rm -rf ./build + mkdir ./build + python ./utils/build_preparation.py . ./build + - name: Diagnostic + run: | + ls -lAFGh + ls -lAFGh ./build + - name: Install LaTeX + run: | + sudo apt-get update -y && \ + sudo apt-get install -y \ + latexmk \ + texlive-latex-recommended \ + texlive-latex-extra \ + texlive-fonts-recommended + - name: Build impatient guide + run: | + make -C ./build/impatient-guide html latexpdf + ls -lAFGh ./build/impatient-guide/_build/latex/*.pdf + # Copy to documentation source directory + cp \ + ./build/impatient-guide/_build/latex/NXImpatient.pdf \ + ./build/manual/source/_static/ + - name: Build PDF of manual + run: | + # expect next make (PDF) to fail (thus exit 0) + # since nexus.ind not found first time + # extra option for "levels nested too deeply" error + ( \ + make latexpdf \ + LATEXOPTS="--interaction=nonstopmode" \ + -C build/manual \ + || exit 0 \ + ) + # make that missing file + makeindex build/manual/build/latex/nexus.idx + # build the PDF, still a failure will be noted + # but we can ignore it without problem + ( \ + make latexpdf \ + LATEXOPTS="--interaction=nonstopmode" \ + -C build/manual \ + || exit 0\ + ) + # Copy to documentation source directory + cp \ + ./build/manual/build/latex/nexus.pdf \ + ./build/manual/source/_static/NeXusManual.pdf + - name: Include other PDFs + run: | + wget https://github.com/nexusformat/code/raw/master/doc/api/NeXusIntern.pdf -O ./build/manual/source/_static/NeXusIntern.pdf + wget https://github.com/nexusformat/code/raw/master/applications/NXtranslate/docs/NXtranslate.pdf -O ./build/manual/source/_static/NXtranslate.pdf + - name: Build (html) and Commit + uses: sphinx-notes/pages@master + with: + # path to conf.py directory + documentation_path: build/manual/source + + - name: Publish if refs/tags + # remove/comment next line to push right away + if: startsWith(github.ref, 'refs/tags') + uses: ad-m/github-push-action@master + with: + github_token: ${{ secrets.GITHUB_TOKEN }} + branch: gh-pages diff --git a/.github/workflows/nexus-fairmat-gen-docs.yml b/.github/workflows/nexus-fairmat-gen-docs.yml new file mode 100644 index 0000000000..53c001e241 --- /dev/null +++ b/.github/workflows/nexus-fairmat-gen-docs.yml @@ -0,0 +1,98 @@ +name: NeXus/FAIRmat-Experimental Sphinx Docs to GitHub Pages +on: + #push: + # branches: + # - fairmat + workflow_dispatch: + +# see: https://sphinx-notes.github.io/pages/ +# see: https://github.com/marketplace/actions/sphinx-to-github-pages + +jobs: + + build: + runs-on: ubuntu-latest + + steps: + - name: Checkout + uses: actions/checkout@fairmat + with: + fetch-depth: 0 # otherwise, you will fail to push refs to dest repo + + #- name: Install build requirements + # run: | + # pip install -r requirements.txt + #- name: Diagnostic + # run: | + # pip list + #- name: Run the test suite + # run: | + # # stops publishing when known problems are found + # python utils/test_suite.py + #- name: Prepare for out-of-source Sphinx build + # run: | + # rm -rf ./build + # mkdir ./build + # python ./utils/build_preparation.py . ./build + #- name: Diagnostic + # run: | + # ls -lAFGh + # ls -lAFGh ./build + #- name: Install LaTeX + # run: | + # sudo apt-get update -y && \ + # sudo apt-get install -y \ + # latexmk \ + # texlive-latex-recommended \ + # texlive-latex-extra \ + # texlive-fonts-recommended + #- name: Build impatient guide + # run: | + # make -C ./build/impatient-guide html latexpdf + # ls -lAFGh ./build/impatient-guide/_build/latex/*.pdf + # # Copy to documentation source directory + # cp \ + # ./build/impatient-guide/_build/latex/NXImpatient.pdf \ + # ./build/manual/source/_static/ + #- name: Build PDF of manual + # run: | + # # expect next make (PDF) to fail (thus exit 0) + # # since nexus.ind not found first time + # # extra option for "levels nested too deeply" error + # ( \ + # make latexpdf \ + # LATEXOPTS="--interaction=nonstopmode" \ + # -C build/manual \ + # || exit 0 \ + # ) + # # make that missing file + # makeindex build/manual/build/latex/nexus.idx + # # build the PDF, still a failure will be noted + # # but we can ignore it without problem + # ( \ + # make latexpdf \ + # LATEXOPTS="--interaction=nonstopmode" \ + # -C build/manual \ + # || exit 0\ + # ) + # # Copy to documentation source directory + # cp \ + # ./build/manual/build/latex/nexus.pdf \ + # ./build/manual/source/_static/NeXusManual.pdf + #- name: Include other PDFs + # run: | + # wget https://github.com/nexusformat/code/raw/master/doc/api/NeXusIntern.pdf -O ./build/manual/source/_static/NeXusIntern.pdf + # wget https://github.com/nexusformat/code/raw/master/applications/NXtranslate/docs/NXtranslate.pdf -O ./build/manual/source/_static/NXtranslate.pdf + #- name: Build (html) and Commit + # uses: sphinx-notes/pages@master + # with: + # # path to conf.py directory + # documentation_path: build/manual/source + + - name: Publish if refs/tags + # remove/comment next line to push right away + if: startsWith(github.ref, 'refs/tags') + uses: ad-m/github-push-action@master + with: + github_token: ${{ secrets.GITHUB_TOKEN }} + branch: gh-pages diff --git a/manual/source/_static/blockquote.css.bak b/manual/source/_static/blockquote.css.bak new file mode 100644 index 0000000000..4ce6e9b98f --- /dev/null +++ b/manual/source/_static/blockquote.css.bak @@ -0,0 +1,23 @@ +/* + * blockquote.css + * ~~~~~~~~~~~~~~~ + * + * custom Sphinx stylesheet -- define margins in blockquotes with NXDL documentation + * + * :see: http://stackoverflow.com/questions/23462494/how-to-add-custom-css-file + * + */ + +/* do NOT import, causes sidebar to disappear, see issue 341 +@import url("basic.css"); +*/ + +/* -- page layout ----------------------------------------------------------- */ + +/* github issue 341: nicer to solve this just for NXDL documentation files + * but this works for now + */ + +blockquote { + margin-right: 100px; +} diff --git a/manual/source/_static/to_alabaster.css b/manual/source/_static/to_alabaster.css new file mode 100644 index 0000000000..32ccc19a69 --- /dev/null +++ b/manual/source/_static/to_alabaster.css @@ -0,0 +1,65 @@ +/* Theme override commands to control the html aspect in alabaster sphinx theme */ + +/* Override sidebar background color default (#FFFFFF) */ +.sphinxsidebar { + background: #005F73 !important; + } + + /* Control logo positioning */ +.sphinxsidebarwrapper p.logo { + margin-top: -8px !important; + margin-bottom: -8px !important; + text-align: center !important; +} + +/* Control sidebar headers (non clickable)*/ +.sphinxsidebarwrapper h3 { + font-size: 18pt !important; +} + +/* Control logo name string */ +.sphinxsidebarwrapper h1.logo { + margin-top: 0px !important; + font-size: 21pt !important; + margin-bottom: 10px !important; +} + +/* Control TOC tree top level links */ +.sphinxsidebar ul li.toctree-l1 > a { + font-size: 11pt !important; + line-height: 1.8 !important; +} + +/* Control TOC tree second level links */ +.sphinxsidebar ul li.toctree-l2 > a { + font-size: 10pt !important; + line-height: 1.8 !important; +} + +/* Control quick search bar */ +.sphinxsidebar input { + margin-top: 5px !important; + margin-bottom: 12px !important; +} + +/* Control quick search bar wrapper, nasty alignment with the google search bar */ +.sphinxsidebar div.searchformwrapper { + width: 209px !important; + align-self: center !important; + margin-left: 3px !important; +} + +/* Control text blurb explaining the project under the logo name */ +.sphinxsidebarwrapper p.blurb { + margin-top: 10px !important; + margin-bottom: 20px !important; +} + +/* Slightly increase the padding in the body */ +.bodywrapper div.body { + padding: 0 45px 0 45px !important; +} + +.body h1 { + margin-bottom: 50px !important; +} \ No newline at end of file diff --git a/manual/source/_static/to_rtd.css b/manual/source/_static/to_rtd.css new file mode 100644 index 0000000000..0b69475425 --- /dev/null +++ b/manual/source/_static/to_rtd.css @@ -0,0 +1,10 @@ +/* Theme override commands to control the html aspect in read the docs sphinx theme*/ + +/* Sidebar header (and topbar for mobile) */ +.wy-side-nav-search, .wy-nav-top { + background: #FF331C; + } +/* Sidebar */ +.wy-nav-side { + background: #005F73; + } \ No newline at end of file diff --git a/manual/source/conf.py b/manual/source/conf.py index 2e6dfb363d..936ce323ae 100644 --- a/manual/source/conf.py +++ b/manual/source/conf.py @@ -19,10 +19,10 @@ # -- Project information ----------------------------------------------------- -project = 'nexus' -author = 'NIAC, https://www.nexusformat.org' -copyright = u'1996-{}, {}'.format(datetime.datetime.now().year, author) -description = u'NeXus: A Common Data Format for Neutron, X-ray, and Muon Science' +project = 'NeXus-FAIRmat' +author = 'The FAIRmat collaboration' +copyright = u'2022-{}, {}'.format(datetime.datetime.now().year, author) +description = u'Proposal of NeXus expansion for FAIRmat data' # The full version, including alpha/beta/rc tags version = u'unknown NXDL version' @@ -46,6 +46,7 @@ 'sphinx.ext.ifconfig', 'sphinx.ext.viewcode', 'sphinx.ext.githubpages', + 'sphinx_comments', 'sphinx.ext.todo', 'sphinx_tabs.tabs' ] @@ -67,8 +68,9 @@ # The theme to use for HTML and HTML Help pages. See the documentation for # a list of builtin themes. # -# html_theme = 'alabaster' -html_theme = 'sphinxdoc' +html_theme = 'alabaster' +# html_theme = 'sphinxdoc' +# html_theme = 'sphinx_rtd_theme' # Add any paths that contain custom static files (such as style sheets) here, # relative to this directory. They are copied after the builtin static files, @@ -77,24 +79,72 @@ # Add extra files html_extra_path = ['CNAME'] - -html_sidebars = { +html_logo = 'img/FAIRmat.png' + +if html_theme== 'sphinx_rtd_theme': + html_theme_options = { + 'logo_only': False, + 'collapse_navigation': True, + 'sticky_navigation': True, + 'navigation_depth': 4, + 'includehidden': True, + 'titles_only': False + } + def setup(app): + app.add_css_file('to_rtd.css') +elif html_theme== 'alabaster': # Alabaster allows a very high degree of control form Sphinx conf.py + html_sidebars = { '**': [ - 'localtoc.html', - 'relations.html', - 'sourcelink.html', - 'searchbox.html', + 'about.html', + 'navigation.html', + 'relations.html', + 'searchbox.html', 'google_search.html' - ], -} + ], + } + html_theme_options = { + 'body_text_align': 'justify', + 'logo_name': True, + 'github_button': True, + 'github_type': 'watch', + 'github_repo': 'nexus_definitions/tree/fairmat', + 'github_user': 'FAIRmat-Experimental', + 'github_count': 'false', # We don't get the cute counter baloon if we want to point to the branch + 'sidebar_width': '235px', + 'page_width': '1000px', + 'font_size': '12pt', + 'font_family': 'Arial', + 'description': 'Proposal of NeXus expansion for FAIRmat data.', + 'show_powered_by': True, + 'sidebar_header': '#ffffff', + 'sidebar_hr': '#ffffff', + 'sidebar_link': '#ffffff', + 'sidebar_list': '#ffffff', + 'sidebar_link_underscore': '#ffffff', + 'sidebar_text': '#ffffff' + } + def setup(app): + app.add_css_file('to_alabaster.css') +else: + html_sidebars = { + '**': [ + 'localtoc.html', + 'relations.html', + 'sourcelink.html', + 'searchbox.html', + 'google_search.html' + ], + } # Output file base name for HTML help builder. htmlhelp_basename = 'NeXusManualdoc' +comments_config = { + "hypothesis": True + } + # -- Options for Latex output ------------------------------------------------- latex_elements = { - 'maxlistdepth':25, # some application definitions are deeply nested - 'preamble': r''' - \usepackage{amsbsy} - \listfiles''' + 'maxlistdepth':7, # some application definitions are deeply nested + 'preamble': '\\usepackage{amsbsy}\n' } diff --git a/manual/source/fairmat-cover.rst b/manual/source/fairmat-cover.rst new file mode 100644 index 0000000000..d86dd303ec --- /dev/null +++ b/manual/source/fairmat-cover.rst @@ -0,0 +1,146 @@ +.. _FairmatCover: + +======================= +FAIRmat-NeXus Proposal +======================= + +.. index:: + IntroductionCover + OurScope + Outreach + WhichData + WhatIsNew + +Aim +######################### + +Experiments nowadays create a set of very often voluminous and diverse numerical data and metadata. +These pieces of information represent entities of what is effectively a graph of materials data. +This graph can have a very large number of nodes and edges representing the large variety of +relations which scientists ideally want to identify and master +when transforming experimental research into knowledge. + +Experimentalists face the challenge that these pieces of information come at different levels +of granularity and format, of which many need to be better documented. You have very likely experienced +yourself how file and data formats are routinely encountered tasks to master in your daily +research practice and you might have questioned how these formats are currently handled +when you want to produce FAIR research data and publications. + +The NeXus-FAIRmat proposal is an interdisciplinary data science activity initiated by scientists of the +condensed-matter physics community which strives to develop community-maintained open file and data formats +for describing specific experimental techniques, their numerical data and metadata, +and strategies how to exchange these pieces of information. + +.. _IntroductionCover: + +The FAIRmat proposal to NeXus is an effort by the community of scientists of the `FAIRmat consortium `_ +to refine and expand the structure of NeXus. As a project which aims at creating an infrastructure +for experimental data to be findable, accessible, interoperable, and reusable (FAIR) in the fields of +condensed-matter physics and the chemical physics of solids, FAIRmat has adopted NeXus as the common format. + +`NeXus `_ is a common data exchange format which has its origin in the community of +scientists performing neutron, x-ray, and muon experiments. The development of NeXus is coordinated by the +NeXus International Advisory Committee (NIAC). +NeXus defines a schema of data entries with a controlled vocabulary and defined relations between the entries. +NeXus offers not only tools to document these schema definitions in a version-controlled manner but +also tools to check and verify how and if specific instances of NeXus schemata comply with the intended +schema definition when the data are written to files. Although, the Hierarchical Data Format (HDF5) is the +most commonly used file format to write NeXus file to, NeXus can also be used with other file formats. + +NeXus defines domain-specific rules for organizing data in e.g. HDF5 files (:ref:`application.definitions`) +and defines a dictionary of well-defined domain-specific (a vocabulary) of terms (:ref:`base.class.definitions`). +The meta- and numerical data in a NeXus file represent a hierarchical graph which encodes a specifically +granularized representation of relevant pieces of information and results that should be stored with +an experiment. + +Base classes and application definitions are two key components of the NeXus data model. +A base class represents a set of numerical data and metadata which specify details about +scientists, projects, instruments, and other physical devices, including the numerical data +and metadata which are deemed relevant for their description and the associated +computational analyses. Application definitions are constructed from combining such experiment- +and research-question-specifically customized base classes. + +In this combination, an application definition is a data contract between +a producer and a consumer of these scientific data. + +This design has sufficient flexibility to cover any experimental technique and instrumentation, while +ensuring rigorous, application-specific structures that can be processed in an automated manner. + +In cases where base classes or application definitions have not yet been proposed advantage of NeXus can be taken +if the respective scientific community explicitly designs, implements, uses, and continuously evolves +these classes and definitions. Here the role of the NIAC is to support the community with +data modeling and data science technical expertise, thus taking an important role of +cross-disciplinary review. + +The NeXus-FAIRmat proposal represents the results of this development for experiments and use cases which have not yet used NeXus. +Specifically, the proposal includes cases in the materials-science-branch of electron microscopy (EM), photo-emission spectroscopy, +ellipsometry, and the field of atom probe tomography and related field-ion microscopy, here jointly referred to as atom probe microscopy. + + +The documentation available here includes parts of the contents of the NeXus User Manual (also available `here `_), +reported here for the convenience of the user, but is restricted to the parts most pertinent to the our proposal. + +For more extensive information, please visit the original manual. + +.. _OurScope: + +Our scope and perspective +######################### + +Thanks to a cooperative approach across a wide variety of experimental techniques, +the NeXus-FAIRmat proposal of the FAIRmat project has an opportunity +to expand the set of data/metadata accurately described via NeXus. + +With a closely-connected team of domain experts, we will develop such expansion while at the same time maintaining +a consistent structure across different techniques and methods, striving for the maximum simplicity of use. + +Achieving a standardized and FAIR data structure has a wide spectrum of advantages, ranging from radical +progress in scientific transparency to the development of new, far-reaching tools that can be shared across +the whole scientific community. The convenience of such tools can range from guaranteeing data reusability within +a single lab, to enabling open-source availability of ready-to-use advanced analysis software. + +Perhaps the greatest resource, however, is the inclusion of experimental datasets in the `NOMAD Laboratory `_: +a data infrastructure that already hosts the largest computational material science repository in the world, representing a +homogeneous and machine-readable archive, a human-accessible encyclopedia of materials data +with tools for automated artificial intelligence analyses and data access. + +.. _Outreach: + +Outreach to the community +########################## + +A data infrastructure is not effective if it does not integrate seamlessly in the day-to-day workflow of a laboratory. +For this reason, we approach our newly developed NeXus proposal as a community-driven development. +We have drafted an accurate and consistent expansion of NeXus capabilities for a number of lab-based techniques, +but need extensive testing and tweaking of its characteristics by the community. + +If your data is generated with these techniques and you are interested in producing FAIR data and accessing the FAIRmat tools, we +invite you to try out our proposed structure. If you find any conflicts or inconsistencies, please raise them to us using the +comment section. These comments are implemented with `Hypothesis `_, a modern web annotation +tool from the journalism community. The commenting function for each page of the proposal enable you to contribute to the +creation of a more consistent and practical NeXus structure which, in our firm belief, can serve your community and beyond. + +If you do not find your specific experimental technique but would be interested in participating in the development +of a standard using NeXus, feel also very much invited to contact us directly at the `FAIRmat-Team `_. + +.. _WhichData: + +Which data should I convert? +############################ + +You are free to choose at which point in the workflow you wish to convert the data to NeXus, as its flexibility allows to +describe raw data, pre-processed data and fully processed data. As an entry step, we suggest to use a test dataset +that is fully processed and already published (or, alternatively, of negligible scientific content). These datasets, indeed, require often the most +extensive metadata description, but are most easily converted to NeXus, with minimal to no impact on the data processing pipeline. + +In fact, a low barrier (but high yield!) way to participate to FAIRmat consists in converting only fully processed datasets that +are used for a publication, and publishing them via FAIRmat only when your manuscript is in press. This makes the task of +converting to NeXus much more sporadic than fairifying raw data, to the point that it may be even acceptable not to automate it. At the same time, +it guarantees full control on the data until publication. We are confident that if you take this approach, more appetite will come with eating, +and you will be naturally inclined to gradually integrate FAIRmat structures and tools further in your workflow. + + +.. _WhatIsNew: + +.. What is New? +.. ############## diff --git a/manual/source/img/FAIRmat.png b/manual/source/img/FAIRmat.png new file mode 100644 index 0000000000000000000000000000000000000000..034aa452deb2c7695940d513cf0efe94291a1d69 GIT binary patch literal 114746 zcmeFZhd-77|37}AXc&1VWs8bRD0_8OMzSLzvqH$;`?QdiO0p??6S6rnLu7}HjAUi+ z^?O|Bc)i}=f8lq#eY(|+bI$X+uIKYH?vMLpoL;IZ$x8mT=`z_rr233@kQ~vt`%f?wl^zRFm122UC{T=a( zJ4W{J3rT94k$-=}p9NCXJf6 z{TfReQeJEk>>I^M8m{DlrIiyOg{j<_l9 zS^f{k@f#C++oN}C_S{ahAezsGtU65QSrqH2>$5wCV6o)c^C*vzydw}n?Gs;#3D}E| z^;%S6Mt)nkag20*E!^8$J4s#7{#F}S#XTk5+01OkchKK=ceirS3ghMHysK`E@V2)8 z%1f_QHr`3^0mBSL=1uZ;{fSyQJ9 z_Y5hI7tb;kqZ^S9!_%ib-_2wh8Izv&-}sh9-P)Jbf#BB6_}M*+Zy6Q(L2m>mIcika>^IXZ7!XvE44-nYmG8y}X`{@-=s%<0vCz z^(p=5o|Tm+)wkFJ_6nUQT7)^iOX=W>OPC^ii!ytVtnEPr!Jg&AbFt9OjzHm3zdv)W zPEVUZ`20oYAMNaHcw}lzc$7EUT0Qbp8VwNb8XA3W0c5Rms@Vs6&mc{${D(w zPmJt64qjMVd}ZP-(@_8`u_Bl8g82PGLwQ;?J)d}Xql4dr6j?9T5IfPHHnQ$ev+?q9 zHmsbF##_j++sf)~x-5^OivAw~fu+SskMt`4(Kr_rwPzE5om zLwrcEy3MzZ!Wl;}DecTTI#_yzpzXi$9f7CF?=BfGgYaURI*gFGHig>NJN9-=Hv9qW z&f}tB&NvJ&ULw14=}b1Or!#Nrc75e?dOM343@`<0tho(6k|`5?>AWO(->#_uG6<{{ zVSPnXo5Jy5pPd>v!aaA--@oE$L8PhNFP5sJ;kS0u^#0GsQ+?>&S@6jPj-_jgy8I+{ zd3jg#p|wkIZ7$Rj;Y3Rqlh2!<4d1uZEFReTc3q=7{3z;}l!?-nUS4auSS_8fk{z8j zO^(}~q-unh+n;GYFzEqc(SetC}OD>tcvx3;DiST}x)j%)<2m?0Ujv?WFcikd%d z=>tOWkWuSr={mu}?$E<%f|8M~EpcDi&w0twBPs1Mf5$CNMDrwB^$I6EZK=6*!F8t@ zR?VNpdt^?`<}=^H!Og2&p51~Hq}W9ZOX(;N&DK~C!9Y+?RBQ~WC=xO^Z0+H-sx6`DC$^Py^{q81pA~OgnkOUgnF>s$zs(o4AF!Bn7N(T! z71fP(@RA@Ah zsCbuVYluZhddJ%b!Sk`icyq>0m0onv+S_n$?E{gIBRI3ti_Qzy@Q@Ao`|@ip+%tn8 zpJQs=OJ=xyD&oLW`MFWwSg$uENct?m+wV}uiu!L3HEp~jqwlz2xu%>(5*F+A_AQ{ZZ0O>wd9MVTF;?zCpJc zk&7uBubhQ6-snF^jWbFh4c*5fyeKp&3S6ZCksL2pU#gSgGa^UQlh&@&S*kjgPHv9} zz(SlK-sG`U)Ak)Vegr0Q(OL)wI(G{mB*k{MJxcmQ>+fU-(v(sd1L%@;z+;i5LqQ+4 z)u0SxP{^;)M2%O%ry7Z{T{gmRsy>0e_0D|jSC>M)X@AF4rrV!O>%?FJ*SF;; z5%qpuml$z8f}cafr^4Gs}R#p3+~wTE_*ifZToZmZM6 ze$}7i%|^X?RmnAFVCb%Q`cny9H*ktlGjDb4-ImF(mjV@odSNH!G^0F^P4O`h@%*>q%uT>De_*bN~>8EyG*rj(^1qQbNC5H=ksuv}@6I^NG zCaP%h2t1mJ>m@VTI3|)8T9V$NLvqAh=%(W}lzX;pqx^zl)jXjnBmQ$BA+%bxMn;W! z+SslBh8YqX-?0*&7bF-lnX&QPLaJKpI4I61_sR+Qv1QKB4zM?n#nnCV%|S}`8WHv& z1fDb6<8FVuQ(BTf!HtLY34+*JCZn#@IbZ$yF+aPj8*J6al_%ua`mEj$e`g`bRdl5u z-W-NwE#{;c$t8k+&k;nXjf7P~IFB37zUt*C>`Hgp#tYrB1KuR&9e@&o3zdngdXG+< zt?-K+11`rKLbT^8V<8+5qMdglEHo)_jW}c?aA9p_+cct^7+Lymmi*=T&-#UF-=*Wn z%|U1DEO=jE*R|rwz>h;+Aj}Nsiw;^2DLw|(zwSAn>24h?FH-54dL5|nQ^h)GK*dGFFR6kBQxfl z$N7n+@qX&eX*Epcsjnmk?i~OJO=rxmLA=BD~EiJ zr@cn_xCN~BOGG)9N*dVy8r#Q8o};1WSCkTkk)l^kHW4ESo32F4M8(Q5Mk;{2tFT>E zgG+7|l*g0HGG{tUC0`^%c6F_k>4L`7yE;UAU4R?K-NYkUVo8}Vig06XED1i}koijm zuA608#&e_gdQd2h6UHw(E9QEhWbwzNq<7`8g6zh)>7t0|C6xYL$Fuy9$5(=!tric4 zFR!uFcMlWIp8#7a?Y{Ho>z2R05_+Hghlw#uHz(P$zN%6oMYad3K9Dy&5LBFa01Dhc zUkOhS^+YnPn2q+;xJQYsKaQhsQSR6{1<$%KQEVY#RSSz%ihxhdT)1DodFu*FJvY=u zkYR=EdO|(aOhyW@w4I8K9+0b)ONa#5KV)23xP@}${dLidc;Mo_f$aLH!!EOGrFJF7xy3oM$482J>M`7mgOb`Up{e4^*fA*r{pg){4 zNX844UJ36|w4ilht|xdHnl=*-CUV)w08O&;la1EGbKs>p>Ufn-n_W@zV)faTyha>n zA80J)rB5k5{r`MClbA~P@HY4u`8cBT>B*W)lpUCq=2gN;R>wt0w$&-ea{B{+{Cq))<32zq}rK74fk1vodLhK;It~rIpqA8pdUa|_Pe;W*ZOG>37 z6A5EIpb|3}b2x5{kABk#2pm>mZR~Sb*$J>Q#Adas+I$ht>Rd7UOF;54B#BO=%R*fJ z6Ux-Bv5l}TgKv0!OWH2qCLPOd3;0tWOd@$0_2eit_B7nWW647Z(avX4ElKl7*dm%n zfyS;FAI7VCiAyN6F;~W~8VdBjf(BH@6T}7%OhFGNne$TZ(9ieqnHX-aLPwUdGL*yx zD84ojpNx+h{cge=QL#z*RnPGZ&C9{_P10jY${i2T^v4gA)(>s%qFeBZ3W|#GT{CSWP^M(;Bn_U9-RhE|dh6R8%JTsKaFBJrM~fnu6?wF^;ok9IMZsMSa!|(;xrQER>3-_S+S70&Q53jdScKie zr+ip1-Q<;~zxBjH6GZm^tTeSC^CKX+A68tSlU@8rjJ2qb}72``j=U zeT9my65l2n-VO4`A9~dK3<)+0q7Z1?v?kXM9)he9^u6;f$yAhV49W(N=NgDueUyam z+sRXo*@!R7qeSIr|9^)TZ}@-QGJhP&Q9wDH%_f8UDhOD`h7cXCtDk`1$J4br?GbU^ znR{`Cu_YSrlR=KR3ua5aTMowDC&hgNin8M>e-E=|;kaZS*3#ubqSYR;f@TO}z7- z{!8cJ>U4st>o@*Y(5y^;ADDOoAd#Ca>~>o;S_nL0_z6DMaW32U%bYJ%2D#qsbiwr~ z`(i`;OU(PXLK!TjEd(;uM7ge8@!(DL6va+Eh#7gc`k#9ajT7<&%?dnOWsV?e2JJ6c zM(uhVZS8|Ikb_5r&@F?p$7sbhJ? zC)y?(KllN9UwEg+n9bw?SD{#LG3*X?^V2B{|{88#dQTiAz{QiA)z7Gg1^H9YBeRw4RZ#6 z9By5ecdlFa|x$d5mUt$ADAWQc&f&6>2!K`ZH$moqG@Q;1MTk zcE1S_Q@g%z!H)_QIqoF^3&=}X&$vA4U!T&|v12Eqw069yZPGRSOze_cr8p=AcU}Bn zR)D+SIhA@Q??23upf$6*I5KQq@gjo7D|k9>bER@=OB;^TbnU|3Q9k%P0 zu!iC54jI0Wg&aQ8U^m|JzIjwh^0}un9kt_KdHEfzRZ$k*P`_~uFzn!M6fzBRA#})L zf^T@mDdhPo3bwfnLhE= zbhOZIp-ZlW$0h1tFZZN}>Ma^UxH|tsB`%%JnC`*wn>Q%omMDwqYKe~(WRlBr*Rva;Rvk*H0fkQ6KAvTBLBYSzcAW##$tuIaF9C;b z(#?C1kL*6WqI7)p+=HH9_Y}-(O;9dnzJHxLfwpuUQQ6IE3vhP$XW@6|q-sWzhS)%5 zwQ5Q1M(M639pwZDF6kyTzMBN-B8P8WEtfC~$E0B|b$RZCTTM2iOlS&ARB2^2L%95(x}q+yBl2yan3c zV8R~)hW6j39>qbz7%=M@#}3z82ZuuKMeC66hU=+<8N|Co=AO|*OAXWO4x($QasKl^ zv}o^|GF5z#$$d1`3M~~RuWW`heB)=bD!ey4w^YyaGZxi_#@3b?1}$SXCrvx(a@RLz zk6n(G5jW2sG6%I{XZF+mUj7ruS$#CbGRbvM?p&+kx!c84UBw2aQR>pdLOo306~^KK z??!9b^g}|$$R*lCbMB7gSRUnDbEt?>dZ*v|0$UV z5K6@b4;o`a^o>||(icCy%FESfRG&WanVw7TQBDr-X|4KTehZDx3pY^ZMud!G%Y5QCv{MOq5Dr2l8%s|w#0wGK^cpY z7WXRA9ck1=YXY0~7 z)U5b7sqB#YdO^^T|Jy8E;E%r*iI(cY+By zzhH#a*nRg5Dx?cH@PT(qWIs=C~b*% zPX!}B8El{_yF7PTeqZW=!oRhlEMC@onQ8iarGuC~NXTr1Zw)kUXSfSxb#H38Yk(M!0IhLtj3i9a=#P{zF}px zApLfib>w|I)KplyS30gFH zVSf)8Rd_K5v9(;~vRoWB;51ouF%?Clbl3h>9zYIuukWWy5ko!wKX0Y0>PIIOWJvbz zu18okF9-~oCEvd^X1$Nz^LxFeZpoiNKi2;dpKf_!TxBZcxeAkxG*39AW{dTSnPazt zE=A=v2(f)W@+B}$!T3^oi|MUco|(L9bWu`rJAmysQaiezQ6I{+}HXY;roRf`Nt&7sb4#k zo5bGoDH>@%{nr#~k)!ea^xL`i3TKrIg{VujJK-X1V)6}CthKKlI{y)yR<>tSC0$FJ_QkZtZ;HUN*QJYxvIRwU3YP1M(;D z?`;{6EfzAJpQecB_^Ld2M#2mBC3$UowAFQ186{b9Di^vs1LcvI;y(wa+<(0K^N{+U z;!0S7*Nz&6-_+2a>NBnBSn1^w>WODGq0givp=in99t#($93w^*K-1BpS92|iGRN$| zh@U(wrADhN$H?M!CisYxh8-;gaVG6*O?4hba5I74U(l#P^F|UcO9%G^0PUskVygIq z$l(t%LQlb-MK%RIPX6x6NfET~aO5W8h||Vq@b<+HIjQV))cI*b3HNan5^O(;7-(#o zOm0B*K#trZ+-W*C$r92N@u3|}CzKl;Q6{_}sT81e5OGd@(5i;sB^G~|^k0i?_xaVy z5bOjLxbZtcB!3-7Ehb0Ql>?qU&sZ-DKM>rlV|f1M5a3OH_v93OKy&vbb)gXa_TOg( zAh3>?(2f+Zv;W5?DiuB8MS`ZfY=wgU#KJqc2SrdUf`$S${&p+N%ItsZ(cAH@asLA! z9u0=#41!D>x8ygD+nM%e{`+{dsF{6gPV z+<&(}(l`C61AL&d$2DS^fr>BV%o9{98vQo3m!nfi5J@Rl?kR^ZI576zSv+Ahi&VOO zk_JK8O2Y9?`wV`<75do>Hdb7x5EWZ+koR?8;dD8D1grJQh$lrPiRS1mS|o z^_vvX8tNvP-Yr?YVc7m_dKpRS{>x>k&d##q9oPlGM~zm{<%|e;G}iVXRA+Hzf9qsk z5+UiyUZK}fXHdCLIN80u&L@|_ZvNI&muI0(X%%h42mSWlb-Ea^@ zQ)1-dSvVe!>JaLPxK?nhwYt|ti2TUvxsi5Fw2Qk=P1y50)ben)!stfe-NXCuw(-Kj z#wJ~d!_iWb=QaGpnMZHF7e-iR;mJa3=!Vx1;+H!I{A+#g%dPE8XznzxMmV}=x#d&~ zF_Lq0ZPa%+6;%?Bov^6~iX7)@$l#Of8|eB+g!ME#dA|J&;BmAM(76B=^eN5+k8@7L z`zUR^(?^uF&L1FLp$?-iE0Q4Gjgpd^t*Ck9;_>){v$IEC>@#&BUZO)0?b{4U;*|$-u%8Ed8q^Nb>~Ug8@ENlHy%^s_2fKpWYG}VdbMgfrMpe8c)&mVEq5Y z$|!J{p&!1A!;=nijnd-_E}Z0K2$xJ^MBS%YDmLvHGy@&JOz@YxQ-QushN8h)>abDG zi~{W%L!rRinL_x}cwQ&?+r#ou${392Ei$M(xTFcS+sSpGXb0QCvJfO#nXb-G`H7$T z&PiItpto#LsrCG9kTyI8H$<@WLTxW5-np67gGf#paJQBn+f%t+>gc$`x<6j5QVB}d z6Z&kFfvhCRk%yVI3tOi2i6yzIXooB$2ESzd^WS51h$a!$uia+~MF2(E+jtv{i@MO| z>&Ou(D_~5HXr2&rtE&V}?89J)vborZ`>{69Y+3|2m8!0mT-0PZ#faMVS-ee1x^yy_ z@=qBG-Oo&7hB1SC>4_$>uVUN7oMFj+_|OP;qVHcf<1xP zH_pu5iEa0kRN0`$QGn)F={Ysttnp&N0BqNOIP5c%(V^_9%2wh;5IN99eXLiT$Vpi6 z?hI-%IJ4d#3h}C5m_W_+R5ApY9TVOy!3QRtBf9$vAJP8-xiLGKC|`m?r+Ip~XzfZX z+h#H_g$UTF$|IDYrq^aVVr~0+{ny25yus{(ZV3d2V_2l}KX;MDWeh>sxQHrLlVZBS zHzV@PvFkR-xT=+u4kbI~mB=+P-U1DO;h7}WG=|72B9)|qmAz8At@Q40n1@)ek6r1D zZ3N1rkw~AL7b{9E@wgjE%-moa1@6MVz3H6KgDOWg1^&mtbIh{1*@E~Us1s=n)GO=v z^mNG4#}7=W9Ys_$(aqL&^(l?&^v&%}e5-Z6AxUg-2b^G5Y3k5a9y4N4p=Xsmk>x0R z3DLM?zU7sb%~JPBU)zZUsZ9jCRuN~2gqAsGD7ctKHvjPtBqOBTQHq1F;-E$}r470y z~0O>U}X)_Y0DhI_4_a&M^u>n zxI}@2+KPTs8SyhI552mlZwBj(Br{O0@YhEOxn zlOi^7umkLf->+?XZJ*X#b7ww!nFR>Ks6_zGsD;*-)n$V7EMGvHl5Yn#l+gUywlG^gv+_thv=RtC4P^m56wMyWv5w9PGy*Wl&o+svd>k|}5 zDgVTZuxX;92&LPFMNLNw5KY>5W=FEV*)d(EPYSZBdqjeWv_qcX(CUin#`jh1Zw7Dw zn|oVgTV|9wiK($4Rm*otieuk*QH9gALSNWQhS{+ zYH08QJqm4lLA0PAEfZ|wTA5?LITBnyF?S720L>a3Cs!P6Sf16|a}W=EiOu}ZWBKmM zVsrK8))%y_3TB*hYDET$i#2t|yI${|tk`94WFN+{&CG}_ABd5`=aiJr8F)K(`9O>K z=X3?E@9^(c);~IB<4$AaHYxxUqiDVomc62VnsyQmhu&@J&MyL>Q|VqUhowq6EH9MR4xo0USFIa&!!fd}&&~e`GPZ+HF4By-}}> z=3Co3<2z{!seC`75F|C*D)q;N*KIck=jeoxt{Hc44UAi`lzllmjZh~{SqbrOd$F+pnSBWw@~1UWuPKn!PR z@i-~BQ+nz9rOt;CzYn61*Gn3Z(|zK1%G=-f&qKW%*ktW&>4yXMZud@6B3PFcp?1$3 z)Fli=T=CDU@9&m7t+r3>wZ!xsL!1SH8V$RAjxY_7+w#a2N-B)_!iXrh{gv9j%xQUy z9=J4h0ODNI?U=hJ&T{UJ4(03sG17YfA!(r7VM!Na9kbnwGO`lf?z&#V1%jxE&jFU%CAV6yE#f`c?tKhPT0<*N3{zsiV2>r)yPs zZT(FLiaSRX7X?n6Va|Ucn1`S!R2f5b$@S7emSY~hCMmH^Ev(^smhSJXcbAu#GZt7CL*)2&p)v>c z4j(GOy(=)8bW^+EwE1RuwKes5^4oPS&XUDDUf&iiBS;{3ZvD*diWqhDaj%tB+*aJ` zn;=0i^ZgEI09!DA@@*s=va?Go$Svb?T2OY`XB+Y{1%ksi^mj?u*d&P^Q{jGRR`N$D zHLdnp8}CP_`+%DvVc;+-8ff%oSXg+=`*SFB=fn{r&bN>`bjv-6x3U7(g&lz!f}?)o zgqERj++)Yp7r%D125)W+Y6;CgBS8}50XISv!QkZ_S09ILH{1WSaF6ex6w;Vdz|{8D z{Vw94ysyc=9bt#(rOYV@Rg|U+I+=o4p#B1BZF!b9BKZ>a8>3HM0m3W^)TzXjn7gS{ z|B!|Bk4x7?%Ftg10@?IXRIW9(R1r4uQ#71@`&MGaYBi6KsTU){c@PXCj$BZXosu$8 z#v{nds^iZI?3H`jiHeR4^*FXa_|QY-Z|(59Wc$w_%8-F-O_dm9{s7^tensV~M-fd! zNCk2l0imC9jjVju7Vmi!23#cJ+iC^_uYz z@lqQd&jbx>+#yigwc9H)Qt}i;Y-~(dKhp~a5FwgTlV?U!;-87(3LRIU|I(XUaqPnk z^{T;>uR+MgrL~ottbzth6@O7-t?s0qcefZl6(+Ec6y2_1C~DI-*vjmB3{^*LbKQtl65J8giZyB>_KYSkvy%(mGcWLs_HaNT=Y1nuTWIGnh-XHRB9lNicPBA|)t`<{oT%Ro*G9Gj%D>j8sdwyd zZJcxp2Zo29Q+U+oHc30ScX8dw=f(MXq#LcF>q_b=J2aqowb;RM`4R zrS@MFR^RxI4Xuejd3 z6gm*;y}*sM-m#K`FJh>6B17#2we4E+2mFanzz{i?0C`&CnaY{T;=cW-U+*%)g_fB# zX=T2iXvGsOQKam7+c0kEFhoX4#`$5-sHa3SUx~^BC?D1?@Y0ugMeM>P{za&M8qhr! zU~eI#o?Rm*lD=*ABbeAZwaI5ei^GfvQL%>vIji5|NHtNJx_STLgV*Y5re1sQ!Fpl{ z>s_#M$rwSwjv`?OhFS+q&?A=}#Q1(Wt<8^>@62ZD!qUP&~5l`=!3lwms zfqvFGfk|FMSjo_vFoTO`Fxc$Ye(-9`>|*Oh+{XejYB4w3s&s&p(cPru1xQ$8bop}mq}cIBX#!$4 z7SjGTh7i=;2afgXNx^)YhskOyo2xG9?;z@Nw26bhKwk2P`kOTc-kG5lVa**GE_-fkk$@j&X+ZL@pgdkHG|XnTr5NRGT?q6eGFZjKmPhP$ zIs!~pO)*fg2Z^H3moKLVR2E&odJxe=%f`PGZ|{gQzk>=S`(XJUGOSCVSyEOM2nu`W zEI=HwO->1bh!#ht8&McUnaS&?#^-ru97F-(!Y-o@AxbOSPLM2Gme# zzx20&_eus00j4xB-934p+{EK(PT0yU@UgeH?SUr{<6D3hVJ}v+Yvz)vSulsI-wkMA zx^JS-gwPs_%0<@B4fX*>g}rOzy}x$HwdEgg63u{U4|p`By-P13?R6nR=Gjn;lm~;# z`?#ZbY28fp<$5NajgZDsthAYhY`&Q3aXLvGB++5Kfp%3uEQNTft77ciU7E+_~$xz3tZbYLV-Sf;x3L`#*ZWCgbm zwYh-9uuT>j^?*V!d`+pUK^<9tcT3>luiaCJsu%bfBDMQS#w_?1evQQ|(UXxPD#qZ0 z-0f|QtX^VnU#!KyY4Am><%>=JBqmU$;k!qhpEcJVXcdZm>JPMC<*yL*b#K1qn<&M+dd&dT9h}l$T3qvn$OMmYMEP z<5@^Xfl%Xj)b%$(aOI12bG6}J3MBN~qf-!xvTRBcVUla)!$nK^yE@oJd+QX^=E3P% zUkvGF6bS+~B5VrE8Uf1sI{Ajy!n;?Hrc|#`Q5QYk6etPNw+ig=L9!=vPtompvvOiY ziwL*RWH~8v))<)bc!8e0Zs}vm9L}{-`x`9S@q*lN%W1c(*lj{6y6%am_LohOroT{D z(oiF#U30fa6Qp=rBm_n9kdAAib@8Gz#;>7RC+0SV2>6C+x~jyMbbJM- zMw;y3#HeWpF8?IP*`}-OhMdK$c$ZTkXk!3tD+;B>MJPZ}zCdVhWHSI)8=1O(2~u}! z2kM2S*D-1cr}wkwvs#O99Xg>%4;AsaD482VDPLPbe1VD%2&Z4EO`o{unxMoDs6`v{ z2mJ7O7b9=)Lc|#aP)l}Qua#=`3c~rpYg;ROCzTutX$KU|d%-F~N1>KOj2$txNT&XQ zVwTH#52hR@!7!u9NGZI!afLO(uUBN8+(vR zo12$SiAXyN1%Ynr42A|%$dLIfg+i0XBh?kWjFN4$Ge@gm$6B5vCzDKtA}J0S>!TF7 z(uBw1Br(1XGH{o=KAge?8J>g`Ctk@lCP$V?#eKRUe~!$hsQj`e6TTOM^#vHF4}Nt^ z;NyTQOsKYD7kqIQTHFy+l2^0HR@o3%D6|e=WcWUox}!&dXnY$G z1`@PvhtZ%ySc~_5)BS4UBgQp~2&#l`Ef%xWW5Qqo6)nY4qrj68|Q^$CMDOP{hPY+L-I&Q z7Fs8kAN}-XZtH(Gz*1at(@=O?0^6lG=fRwWF>J##;#PY2x*CcVb3uFptStMOlksWt z4BNESOhr2#Dbi@buQ0TwRZk>E*{Qk>R@LyZIvY_HFi z9~UYnGB}~YG3i#`bmCJRl$|03=P-L`Nyw|Y= z)xF*>>CLNihozB_Tjhp4uiRrXG9|}}aYJC?3;B0Q*P}4eJmCOR&g3S;8f`@;%`!k;#T)f5FsO-&$HZT*u;eS$2=ALHGa-$S z_ye5R1V>UHs4*a+z4mV^vWHMO;Y^Q~Fce-H^Z-vWln zYSr^>x%}rekiZb#Qg-l0P#J=aMe$ajjw0~tX^fZ~^|UAramXMTU9~6uS4Y(9H1qo- zmnF6hF&;c5DwYh9rbCo4NKwL1hE$>*zgIR1@+U<^XVQp}uaClHJ~En=v?Dk+R0mFL z@0x58cL%`tF;rE^@JZCTF9Trg@cj=k*3-N~>k3@1LKG`RxVkm?W_zybwQ}Iw+?DgM zFw+H?cSH#DhueYc;tF10J`TK6lVydk&aP-rotu*MzO#_+m3B>aXA5J7Gdo40mh2p_ zO0*vHKRvuyaR?y8>Z5g#m`^`ujKR|Y*e&ASh}MHjZNQ$WSyt7s^oVoJmd)l>k2Q@` zl-N0Qr{}*Kl(R2Faqv|Fh*i96<2{P71`9ut1H+g5qJ5(!bS=*B6C1y>?y1zOf8Zit&m>MRQL%`{V*UiC;;2rvRHd3AcnLS>iPfZRU=!xm&dR~iL|2a z7oINYbT4*%1(beYTy~RPQ@jJoxnRC5L_yX7#X$~vcD2*lCiKW~FKVobz!okt%#J-w zr$aFu;aTE6vJ3gRYaBB|V`s6O^tz(e{_4Tu#HqmiIZ~IRE8(Pw9$IBJuJRUh5e1lr zmZl}+f*}Ug$5yT@WI=!HC*7t2)FnufJcG)>GI1SEC@P|@OK4m&wqanuxw&+0eHvs? z>EsW1Bmj+(4_-)U2k0YNn}SIl3CjecZ1qfhx%K%rkpby{`UrsLOt;w-ZbXs8R6O`Q zF_Nc&X4SxA%&P8hPsf_6sPFB*qR%;X_vH0{q}gg`$t7&}xpXOu?2MqqC^R$COgzs% z3hc=F&_x87Az?q<>yb!8g>2AMbgZd%+o+J^fYyM?$_}$2#%P1x7&_i@VcRn^(izh# zhj38!!snyXzEO&%}u(I+h(L=4V>bPc*8SYo#s9lOw0 zG_zDbJunHO9wL-Dcnsy!Q~DBxVYbZ1z7`WB%^_f~&3&_q=*&igZ24er6k2IL<+;1myxjadN{FXs8vt)($+_q34XM8x7W0rkhl3LupaR-ts383hn zGp@nhi+=)$HDlktf7Wb%%QK1v!Tp2=Do#AmTc$iXwx=H|nNuqEz{@sHW}j6N2fw1) zGF={+4Rl53yJi(PJ%Ke<@IV2_1T!+qF}-{zCpUbxm6fUm8Wvfoeg=bnF0#pz`GDO( zVmzd5@rk5X2z9kvtx_d>NJu|Ay^%O~kPIjJT0%#!LpS5cOyp~h2~wDi2Oi981&;GrEgCe;Sz($UYhs`;M@wGKT#0|7-2>T=5?Qh&$~s8GfmZvMoy zWcWYnQcq1%vUz`lD4k8D0c@4h((ztDn^)t@4^tgazi;AsN6*(^Cutb6~Oy9ZugPz4r}T^?j!biH^>9+5hv} zfep&UCg%{pg6;v2cUS8jwhyeQ-3}C!R)6;J!vX$JZ{4Ax zL$m>*s~CFHyr}jbIgRquk}u}unyS}-gx)P#c>ge>4DCgLH&+hs;|NzIIQ`W*L3ZxI zQc~x9uwF0nfZ667O=AaaJ2CPT#0c&SShpni(P1?vWuSe~wBQ8B66*t<)R^R+K(y>| z)|x1X21=@S#XTo9Nzs-L{TvWx+cG~h^eBZHaangvD4^s(cnbg5?7pllwv{>Fb|WLb*%g9)?_4BYL`L6%hZ^F{8iZ`H1s zW}jWtGuIp)CnDS|8BH`|Z|EK|`E9sdH(>}#l?3v87N1mU9WkIb?}kWKjQG#Hip^d; zH7jxtio6Z23$N)BNhR=ER%PJG@17mB1%AMym$Z^&IQ#iB?z%)koL7f0FbgtVMo*d* zy^K2%mo^mXPjdULJ~sX^Xl?U)8!G0nmk>#A^e$HQ;UuJsZzum*drZZyNEyga)X+s> zg^5!+M8if9!nDUk*3Mt& zp*VVTeL=0J4gi45A75CiQLQ&3!A@kzzsmE~VE2e2&S9Ji?0mP&YDYJhs@=b8(V)E7 zTtb7`qS3o4u18U5;WX83kYZPTin>}RVUB_-W_55ujMU!_>P6ed*2ui@4qt3!&ZB7o z-Ad<(=yI9>yVQk+>3JwBjg5Lnt!@!vbKMY1Y1M4J?-U7QvDR9>taDOUNDn*aiBba( z!9mDexo(+@9sJcd*Y)(h%a8Q+9rfg@Ij!u;1X-w923#WB7c5*nSA;ZR-$o1h$l+z6Ca*wYeu<_PD@{8N)JoS{H=dle&GAA z&yDyCU)xk+*v>!>4Hj35%b}{2O0t3Ws?2&N0=o9bi@PSsc zSVtFae*Zaq822Tkr(HViRjf|_{ffT1j;k_FS7kaGJck;b%3YHA;A?b8fuv~)mS?q` z9h+diI9KTbQwtkC>-0otX+PXnoGV;HZ=JB8C0@y5*7S%sqz{a6VEq2&dhC+eByoVh z2G^p86DO7~d{{^%i%(Y^CZo|29NO0TF6~PeKi_|Ky<~A}&og3oC%ArYpt`CSObYk$ z=U_r`gU^ny+i7ZpT5$J_*@bHFzc?l{PB;0q1O)r^N9M;;AzbJPsHR4^BBSkXZ^at0!sq?H zORjnDFs-td{LNi6%7?PNQh+_{z)kE^pg(1%e^iM5^)My__PMpv7eg0zdOc%HXe|Zq zZVkBx7i-FR;-@o1gMkTgrMG>5#IU&J>LwtxGz~*p9|CWO4uKTLtyieH4Z?p0b|fBP zCw;=U;do#hy(#`{7(NVJ5DsL34W16v@Ti1@ycb}f3;-Q(U0$G;DNx8yzwKmGFz$+($w1j(>9$n{1p;ktb3sM2?xEtr zn?kEprJ|;}C6({ft*wcq?eL{0nN-wab2QgRmp7LFW-6V@xtVEk^0uah`H=lp9Ujez zYDd{ZnZ=Ijk|_8-73#Ns!;4?4E<$$3Q}g59LCQPmTQExYAj_h;Fx?Ia&E#n#pfKaBwCz1V0>%1-rY+EsxY_lO8KwrXEusU za#l&OPtl44+oUn2R6}dkuf=U$LBYx(KOMdc|Ljix8vgRf;9r28@XTPwEy2J;kmzLI z*s6?#fvR@DK94q$zDMcWrwS=I9?!d9o9sW@@gOw5;1e`o2YzUBFXrWj%b1L%!i-Vq zdgv7{e^+)UoreSCqD9y{z+Lm{O`iwJljC5PcGB)aA)SrO2j-kVCcmq*{59tJ?tSZ& zu%W99`TTj7>@^I#_QjGRN6<;$BZc!oh@K)4mk~^2-8A|BrFmYo-kKzOM z>;w0(`b8za>zUzKg$|e+UIqb=_+~ZE^UtoOM&7@e>=6#t!?!L#6Y<{?;5-HP#z~*q z`&A7(Y6AZ1=xAL>UAiQd_|n>H_A`Ir$T+sxUYN)Fo8BoxIef2B$duo#yUp|fZR&vB zNg18|rxRM~iCKOw2W~m7&K`XoI|?2bXMifsmz#$%<4tUId2N7!PIe+i_p8`|>?c~9 z>C)St5uVA=)F7c9KfP?***1RireQC;p_XP*W|F@KuRImIPu}1Ap2@KLwUg*KW^|}v z68;F9>G`F>81dMIb&&3ni)b?*W+*F2jkD3t@u#9^M_G%@e1BLZnFv3i{!nIK1mhwu z2v=R5@sZhW|mnyaU0^S$`yOo?R@-z1}R$yj0-ZpD5?XWO@#FGShfzHxPJ4T79oW_v#&g>R4i)t`E6xFC=^Ki5N6?Y8&a~{Um4(*(G zd@iC*xyiL{U@~r0T;Bc~Xc=Ov4j9T*i||F@zVcU@x%r8Z7t4EjPK8Pq*}Axt_rih; zyltn>T%dHgeQoLwx%!uc2rS3C;2&c@u4bCM#{xx*7@v(DvL|(4q+-mCa9Wxv?^is% zF+N>lY!(}CV)5qZbVZNPQ^@bu61GPa7{h|zHBNKLXDa>qM6^Y7{#ugC_Dmd~e^k#yc& zZloltoD*ql9i})3yfJ2={TdKcpzwsp%cNe4l+%)OB{#TDCUwU-U!kf4jWz7VxmX<4zHY1ukUf|uRjB5l{O4}Umi1f*nj%?rWE-yFJ zh`(>!uT?S$agM$eu+J5k?vD{AOS1FFd6`a5Rxt&-P(;ol-_qYm?G?g?lnk^uR9p! zUT)Q>{q3Yqi`|PNJhwnR{c^`#{$@c{N{ir&M%^m+lM*t!n#gy(+k9!a8B{;seiAa! zqm};ajz#gru;o{+mcKFn!`@tX4czwc8J~qfMq0nZ5eN8UE!LW(EcU z%$&*PG1a$yCW+bU>D1pfQMPL%OAW`xC&Ek}k@h~k*k=7`rJuh_2*#(Uu}{I1{fnU3=(j6t@Y5%#EJg ziiqz;02`E?y6Rb=h3G;uU$cyV;n?U;Kf!G*9b2=PKQ0;X_FFE|SM$oXn-S$qhADDA z$DR2|0|rKQiHOJ`ir;Rvg(EZ7ddcU!R(4D;>SdHL1{^&!AZwvaI5coa;RN3~FH6xQ z_g~qxy?gn}p2#eNT4b4AItQTN@*ga!DSkfZs8{(=#N!~#j1tQ{dE2v3GmZ$kSh=(1 zj&Q_M2gKSF45J@1bDHEm+r}wSaqDkpq&m)Len=9D?PmsO>htDRZuXZ*wY|+HqoT88 zC#y)EdENVE-72-~gud&xo;sW6lMmS4ef7MK!!Mm6V0*Qii8Si|le!9H=ALkZ<0Qz- zmZr{3TvBF_yUu_5r3U+|f5NJMqKEH6e#x0{6iT(9tMFaLr!I3+7m%c!loCt{&;;lU z{5AH4Nd)EG7^YgLQFI(a`gJAjSsKr z5a3J(U#*l4(l*D;-{WO?s84C3xDW z*3>`Gc^VO23MD`t-+(%Xy|`hU-f zr~*69M`Z1Cg!xfJm=*6e_&v;SlV%G~#7LY2denf3Z`oSXr_%|BaiSi*i$; zeS@zX_5IF(tG!KU3qRh`Mv|Tn?)hI5w}th!;t`}^(jj0Z z;mOEmuJ^Z}Slw~8DiYp}k(A<4Ghyw9NII`A_)ypb40*!bMyiN`m~YeOqrS_+L-qby z%0p21YfQ|vpG(IEyc_>M$Z3(cquJ8zXtYHIYIvuzZ4gGFV0Inb!!~2T37HxU?i(nL zvML}AGzG-za+KIPIPf(Dg0u#8T8`YZCeB6Oy+oC2UopfwZ(<`)xdnnc2>H~&oh|*) zHASbplP|aZME@p|Y))Q`)$um5H1uCDKoQT8cP}+!T)6mU6^^mmdM?g?vpD?qUy#_2 zh}&zGUk%X+rCO)zUTr%xK4B8PTlzXf+CW|r4Rw@nzb4V{%uv0XO;EQ{Khd&vd&|@} zN<{_xB*FYF$gE)b{JW#jlYBIIG#Abkg+0O4*Qz|@QUfVW-Q=O-3=my!ZY;W7`(vbX z6gLNa(mS2!;GJo#D$)d2a66k`#}hc#`L_EDCxmeqFa>keyZ#nNG@FFT@e)GY*=)ML za>Qt|tEx6t>tv|3eqyTDNxxP3o@&=Yf_KN(j?mx~iYUel6VS$usG*|yRA!7kNcf{R z_OeW+?@rbCri&(&ewNqjE4@F!nQ*mfe~9Z-9()F7yO`OM3{HmQtO4c z09Hs9`qA!hH_&a4M^>u0yRr%sE zEBV-uXn0}D7sMQ`wF5Mzfnf`+D?0HL6ts$Dyp^TnU$7>14N9)Qu=C(KNADvVkCcxO zcuE-8FK#3qu=f@%fTM)iU+as*E&|a#?W#ji#O6a9X>Y2p1P3H?)!p81|LO@6Zl11e+lZj@W!v4gNDT7f-JeJ^E&yTzWnE8x4(xpC9ch)siIl; z`(Z2lmy%ZF?hh6h4zR8=5IdUUW;UTdJJ2Y!{%asGa066-z=-Uzk^)5iYN1k^`LL4U zsn0y@+>Ix zAHN6?y=lA_n%qO{ID$-L6;7lKFdz;NZZi&cZ#dHW=h5C%6aM`W%k2{sNMhG3%4n#R zLXx7h6Jq~b@%b~OM_XCkjkcjFUMx)ObDt?0a;Q(@@FlJAbX|ju=uxftwPpLR6c@B0 z*VqLI<1iJ#P+zP{IQkn+vGcaZwdh6ir!$bk_0rGfcIsGHEr`!XzFm#J+Virc7e=j$}7=TKxUW;XpMd3Corv zSeQx(CCQG@>xwo`fLJ#}!_ZfAWv@w-_XIRWs610u%?$)z^T#}w9&1c6h&gsugDH$g;vmbuT4Y6 zb&Rf#f_RhRB@@F6sL$lWuzs9NYrV52oG$6=s6ShX#gf!sSnf2x6_rNdMLVmj<}r}2 z>m?7J$^)ZN#)Bk{ln*zv>uJ4WB3r?ZV)B6=67&Vc`1w>}bR^4IUv*4*RO5sq*i$bB zbhfuuGog?D17edg4A8NO<Hi{%Sn|CD3ks{ zd7+;S#FY!f(VVWW^|gS1)^F|1{?Z>*ghBJ)Pv=#^(Mo9yi*DdAfA0lRc+_>_Kzo+= z$}_7DL>dJsvzxK+vUEfd|AG^yb{$A{9pnEa3SE27cciUGE4TdK#Ez77=|Z{H%_Wm;GX6iXq20|(U#V7 z4bWp#y+*AL-9uYlGz4?PU!e>DU zBz0n3s&2!AB-Iif&JFHs{~!t{gZH%ha`{jGdXO7=MN65y&VX(?deb_3a zoPo6?e{|;|hEvs^|By%0%4IGsn2DGTh76|OwA)re2nf}3x=&6Vz+bN}998~42mfQL zmK+^2@CSDyuFp>R(`?TTk~ct)fKq$-FMkHoS&V@J3Crxrw7t_KBXoJ;KzjoNxfILg zH+wnbYP;R2;dTGMS1nvDD1JMp^}zRD6YhOTvgCwSk#b(MlmQE=L+g+V;N@1cI#E!S zz??q_bRVM{r&-R(Q${qRG`Np-aIDLifxLB1U7F@B9@S7j2yclFCcUZHRJ?Yp4QLp z>LbkdV=i+u#y8C_fmU9&wo&n#@F;|_t~}|8cvPBA zu&IQ@d7Q#Pnx<=BJ4jJGUq0bE6It+3=(F4o%9+s3*I4+2 zTQ6i}EUq*zfgo)>e931SLkVfR*_;{G&v&ga>YYoCnTN*EO#HN43~VjQd-BB&CRA^p z5NY*O*G7pIl|EKJ3}>G7x;TtV+9DcUvtl9Fo98m3HLCvYCoRS? ztcb)-x3fjf`y+0K5E1DhfTbP45S%ez;RZ60D|FnC$-3C!@`wV~RJU?i?B9-?VU9=B zg##2;u;DOpdrduI7n(X~_MkHCIJ9ijZOr-!dRk-rGeWU96CyQz3HnG95-reN6I0e8 z;W}3Zoyl~kt+y*pDcaT1JID{L!U1J=Zs+^6=;B5Aq~v2-)s4dgDdF3+5vsuP*Mh6n zct`g7^u-K$I8q!0v>1q4pMt8a^;j41f;6p@yyEOyHuj4LEgZxmv3@8NzFdRBDweAo z@-^CzCszjZfm*~BU~y1s^HnEyw8D;`HBugLNP}A_gc~cF$pc@2{+!^%E}C?goj^EV zMvIE}t${Mu?oT$NfL6%%c!0QY4SAL&!?r{WlcO~)b`3Eh?2?6bSsrL__gcf!C@Ft9 z)T?k|1%I`aM_N~!O-h#mwH(*&=&_`(o&=!CLARvg^C;rb{k&KEx4MdH)FzjC$hIf=t0iOai^p8G21kEIwWM77JZ%@ZR zIl=mKY#|TU3dtah0PnWjVreFI6kK_@uyEjDXGVG;oKs)`N@V@eIpN4@`{oM@}P=$`LXj;0u@7L z1SEM9Q=n8N)N$Ll`Pdo*aK8rn8T;IOpW@H?*yTX86|b7w1|)e9KSIWYaI z;Nvb?8&|BXL}kn)om}18R_SM!pcd{+w{INVktKE_h2y$BUhUxNn-E)#mNY?%!;$`B z2&rS*=M6LF8L?`l=x|c|8MSYvhOT5RuZXkW1;bvEK2b`sgAf6kVqY&}*X)G;V5`h_ zShpbXm+NwJbW30PylUkJBr>)F3X)vP)6GB>#&T%Et0p3AJKo8HL?ZoIiBG@!axMMB z1`yk44xpO%dP<28iV((}5KnZ-7+qRXYd?+1x$@qH+IrmV#B%GaLQTH65<;&5q_ikR zc~1_1H8eYpBDUaHwgtfyGd-{lFm6d%=>Y!`l6zK41UDj@PW*h)!-_O9dIjX_)H~}3 zF|k7eBBuc|t@RLv<}P*S{n`WOk7DDOZe98ga*11T(jy>CxAyTW1d)4TFhY*qf11NkFl~g-e#c0Rdk@?T|diaIX z&a`3AGYQFXkB%^Q5LE-D^+4QB62|%&0Y3QXIUmqtQuSw`T?NF>h_o4-z`^{>jd{9$ z;_Ps+A@D7B)ZohxeS4*7%ck}7+n{qrCwb_%Q4l+lbiop;uXPwmdTYiK(1&b%IF!~u zu;K?)2gK_zZUMP9t{i@|-*2(X(uNFN`8jZAMw& zsUJR`QDF@MlDuKi%T`EKhb4a??@YavCy8MWZ7nN^jC%3cwg3 zkfW7waIfGv{?w6y{DUx~wgsH^ z71ns)06A$0MTxB&@V-oBK3UwJwJbjg?iEIekE3J9Y9fpv>kiDy$>+yueKY-Ze-=)g zyk~LmDZPSPUK;@l6Raj7B(cTH_FXwf-_F?qfX9?>tBW$4oeo8m(!7}$6hwgkW`$cg2~*|E&K z!ecuz8H6WrscGb^jDaB#ub%Em9_GU`@zErK$9_%dVC9RdP4Fv_aEod2k|-Pv0IwhC zJw@t(6PL@%ffK;XtEDZLhkNd{YvW+y)hAA%Xi51aH={s^-x$#r{8Ir^eCKi_|D=}j zZ$Wa%)f$k0?ObwnT-0Qle`BN@jIcXhP==Gv%7ot#{BFSnOzK}d64IBj>aTKM5<;;n zhg7841nCmBP==B7qymsy@<{Nie~4*0llfy7(g#cvi{eq`uc@%=XnvSKGnjRyHZK@_ zOP+uFd~L4MX!hTmD6sTL7pYRl1zh&dqFhMw04Bchjv*H)kyYhw*n>z%JKv7*e5%w^ z558wopbMkbb9OgzD#4CNlX$1|Bj;Cn`WT2QSbWpmeyHR=(g4wA1V>0xond>uHO~3* zX6K1>VZmHA=ouH7pvo&CNoV{!ZQtjPxu1s0&V^Xu{=FKXb0vw>cZXeCq|>oLLSmlZ zcRom;6`A5-A>!KgaE_8Ze<)}G0y)IA5U%6=IL;)d1|A1rq;Hmb!JP{=;4+S6{eyea z#HswqmaXs)MYhH6kEJ+R*It-;TMknz_k-51RoO^Tp2q3Uh@prZcs2Zl-$J0op<}Bt zz=bKRc~^H^LMO#>|I|3a>bH*jZyg5Icaq;XcCSKdh#B+AZxpm-f zv=pt>d~6q?SMB60!^YVU@Nu*ji+|Mpax61){2Mz@34u9$^*;8(K$8{c)1{!vZprF$ z3M%cVL3z%_vUXQ8k@ay1L9_h&VonR%+R0y_xaj_Q!;RfWv8~4}I1q7^mezgJ{m64z z$Dc=ky@Ud+!J6k!a5u@v+`Jq%dfndmZ+1yVJ*B<5oWKfB+)P@+DuJb^7jnZ5M}bCJ zA`o=rdc)Or_=#6MYMV2nc5J;5LF&)8AssM^v1ZQd$0@~F;KgtfIm;Z1fKkrgASfts zXz3Wmo!bnO);w&-C>};Y5+r6EJ6j$`l}E%I7 zFM{D`rdPYFZ*OnL=~yNGiwh8pf0;FjZ9fG$b@#fQo?;$pe1*dAh$( z`y6b(XES&Ln#zZF>opQG8ED~VI`&(Uq~0%By-ThHh4H_tPV0~6+1JUCZYApSFT3-% zq@lnNvx)MjKpxeW+fS(3-6vrS+E?&aI}8lg__%!!!6KE$qJiu)&`)I=>r9sorDB5cj4|#vLlkbWBxoS`DDp7Jy=grV;kAbPZ)jc=!eKz?3g%N=| zqDz0|*`)oZ5do{~+7XJ5%Ch?}#;}8wr73j~N6F2>mzuBw^wFa_h3+}QvEos9)>y`0 z#sWIVj~>`Eq=N}=Kdcj{>t6m0HsOoixP?5B;p4vab!N(5!nNsr@Uy%9#xGJuQC|W6 z{fd)gxt^&lY;Y*U*3;eR*yb$@2C*g%`@ts|)+weq` zLR+9UKxra24*5{m@KUFu3FGDp6g4_-uh5qpSM&$nG$B8Wgc2++IcqvIz$eMyX40B0 zVnb|;0pbZ!K)XH@kXt4fEVpEblJW+}=IR&P=)ZkUTDhNwp!sjSj&NRF_VVvODf|+S zj8gN%sqtDZ=ME}jT4fN%D@zFM^4g;8s1)N--z>2H*}&^P(?6a;Ky@3?7xZf#vWYBo zTByW2e`%lvCjtJ1VtNcZI`8=-r|`H~Z2vxr?5riODkHpT8E82ubu_VoFoz#6WtxXg z5Yp=N((KhRn!T{Rfu{CGoQv#4OS8g%xeHoanm!_{(hp!tPvX_OWnF;bXb7~7k{jt> z&Jf`e+iF>t1E(}j=x+1H5{mvyoAWbKd4LD?2`_A_aL%Vckgh~5U^Ji(IUBUBhjkbKQbfcHpyPfZon>6wX#}hJAkdKr+t_Ob&{h$_ z4>(2sZ4f>DZG~;~TSX@yB|xVDj3JV72;K zSh15G0wYWe(-sW>K|i9$4sAe&wm{Ky-A?;Sg%iW`FGZm$RydOul>tI~Tm^5d3xsph zkuIEZMIfB#fY0cXL3AyAJDjRBX$68xOagn3OnU*iEJuELhv3-P0Xt$LRF<7jkWbuy z2t%pQIbB*$tGu`CCoCVMV?%IrV*UB!1I>x7XzJu28I`~?N_PC-J3K!^w+##Pgz@?HFeS3vRD{xpS~XJY|?n@f3H~J zJT-XP@?K2PIg0(BddEAAY^3(_T$<->XXQyGmL6r>Q-TR5OHUNqv1=tTkgxEhU$K*> z5rDX~w6Ioll;sqgaU~pZ#u4*8Yd4rEzzX%qVlF6QY-3sU%>0KbJ_76FN{{z%5jMp7 zzrEA57+KmGM;xQqv3`?ZjYf}5u7pbap!-yvlDrlEHqr(ZI6R;V3>M?V3?A6SCJ68; zsG=eSC1mK2$#Cu5aug-KFmvwYn6z3fgS=5em*EJ2A7(;7W-eFz-wN%^UT$V(>|n~5 zOIG$ObW(bqk*N^nR3~MU3bkV}P_%`irmOgOMCiX$GNJU1J0b0lC$NPKg{B-C7r!PfdF7jdIL0W88Rb*&~iT~*153_wK%n`c96UBI~c+D!(S%U zKrO*s;re#0Ls0E#bE#6k#)pz_Bt-UBBE@O235GM~3X`G?Xh9q=+IIkZh{6M!7rBMu z`Tp$PNcHbQ#jPmb9EyDBk53BOd4i#uQpMyj9Dx3$o%%RZ;2Q~DHa1I)}8J;QYiHzlIfI}Y$R*+;rp6i(Yel`&lZojmiF_Ije)H$5OKy=8E zpz%)+sDcOl5$9#d`yqfzH?8``8xsT7VF-kSQe=?o2W9CBGf446U9s#&sznQw!8c&0 zM7&-u@n@d|&F2XA292_pBXBXH-b^GZz`x7^fNSIi4OIy3#PL!5rvHTo8JE!RH_+1- zBX1A?v*hAa!H5Qr@(q;{%XsVo#31*BQBmVLX8B`?&I-#p+0pLs{{+uoBvdF8_a)f_ z5-*e0^M<2YUF*=AgR6c{RTbjFyluCOGt~0^PcH^9y;E-1>HRCA7P(l z+waMVxb$#j7B&wV7u6t4YaK~!Wp#GD;+?oX46KdGT&w#zFMl!G=lZGz=4IU?te z9#ryFpB6?><{j*8oDhm&0YP>v%A55nWC*bL<;F(4*{6!Web@YaTIrUM6NktvJ)Yf5 zEs)Hy-)`R%^wuu$aP{!4-dYbhu)w5)z@(~sa<}{T5Bh`PCScZ?zWWK=$9xYdz|4sQ;kLh)$+x7E^BsnmUz`zHK%oeVfK>Xdt~N z!TUh<*v7v5_V_VGw6v_n{h+pU?b*8-0bR%@3M4Pot%5UREkFbCVhZO3c*N@kLOi_Rw#N~64 zfKb*twB_OMOR+7`oG_toHb#V&iMtsdN&Lt7gOZYY(bU(Q7!W7hp$Ua408Z$@3Fe(p zts&KFFUoc<(F&qpAXpnASTf2$iUjtl!LVY0iH&9U7?j7Ouhphr5sQLUXBbTApZrcV(t}- zBeX@mDtpg4VT;-vw;<(~-figIIenv%RUL4sG@iE}R69*?tEvJmjo+P+-A-?#B51>a zm-U)97cP$XzM?o^<`w^9wqnot{RK_l)|Jy6NG2{_^~>+Hj!#lZ#xrTk$7$g>O(SU! zs}VWTFKbKPZ5{knBl`cN^1mcksU ze>g)mv?Rn1i)~T71EQc&nl~GrKQ(>vam~g6`~MdZ!djGDtBlvWO~qO3cvxs97aS4= zDFgFk!X}JaRZtW!$tx9L3aEb%9Xw|?gZIoJiGwdm`KY`&gEMNi+c{0JXO<(Weoze6 zf9eQ%6MJGjP3#|z7lc6HdU0#m(e}cz;ai0!p7DFqAB37MmP1P7L~(DiLk07FDvv-##6Mffs(7Q; zot;hDok2<3ikBgo8pfuJ!m3OgtI|xML!2d&(o6VEXv|Ty(PjgQz#jpLI4i@uJzgf! z;l%d{`qpc74kTtb{{_i)=+)#FJYs-hqQ4VI{GT^N3GOd8GVjJgR67L^-+|HO4(bgt3c4UhC zinpAAIS-5RUliS6lsoJBNbFVrzBlh%Q}g*0pF)cvIo_T)Accs{X3v<02vg)Q*cm%Y%F6N_`dW{ zLl>!jzZmEq1!;>_p6QWmP31Ug03C?*!q?D?E3wREK5z-h1N$v{J!PfUpKZj=uMm0{ z91&*FenNZwP@6{U9itU^#p_&7J3#s1x(BgRaZ|DQWDLppPe--B6)q6c&kJaa$$2gk zHG8=LqVKitLSp`5ECnyL4pDs*D7~C3s)s4>j?~VB6ZpkOVlrH}vDA){t|o*@yS6GO z(tQk_)vA3^b!_YUdk-h|KkxDI8|bht)kzjvcyTR(B~m;{LbEZ4O>ZVmXFWP1aub>0 z@lz#QDrfgEC{}1ZrzeG9+3y2Qz=4if27n9yG=R%8fQx;Y)m4e6Dn`;`i@EML*^Bgk zBd_@BUZvRT%+R_m9t;tepk1w7x2iP}G~z^xdy;~!)mupFK@duu2K|ftw?<8*=|2y2 zjuHC0#*HH~TI-CIuJfA@>8un~hOM)qhH!}Zc%3^>Y*T#du9X^76qZauV%X&o3;uZK z@p^_{&W8K$Kd8llkOx?Wp!;4-S@d0{X=N+fih084PdRQGdCueiGDHYKD)y37Zrr@G z;u-23^wwlJ3ZaWQms)R<`0OUxS@BFZJ(Zd9{_`v=nIJ>py7y}0r^#Q@dBHPcUPcUA zZlKm7*!S$(5dROjo~ec>-bILPCGWu6?*JL@n`)^sH$U7lcIqr*8(g{qIpI~>fT95CvNU z&Sj#|Zj$WnZ#(Xt*G(T9Y=E*Q5T>-syjl`9q(F1@2XD)c-AE~xLk|~dcn-p-a1iGB zt4;R(*X1=8P2f{R> z$IqOo-Yb&CC@GY-u(Imtl)87?%xI8pMob|XMX1bI`p?VhR1}qQz;TDpb{65Lf6>&w zZBYF@99GUNUvB+dhI3?Kyf~=mDL}fxtg<0t%F$|^Fm*u3I2vBc?UUl86uLjy7o-{ zm1$^pv&H8mZ%m&nO)M_kPh1R!#tcC2OFvd+rMcl$(8D#2N5i^ReuE8phGkHvTu|bH zYT?ln1+)(zpKljw>UK?)`Qr!)Ph?#tZ-!Jps z8;GYeSahJ>Kj$|l}d?9X#z(A+W<>eHGoC3Ixt5%VWzyI_hf3TTt7E3U6D0%RHsA}~$5 zI-ZqxiqfPUPbsHPT-hFQjDPrbVZkCh!CcvUR$j zca;CMZfkR_WoFFTna2@0cGuLgt9`F~o78FFq@%~g{r0+ZT|GcK_4Ax{*->wSfZQ*S z3U?1xvh$ijvfTnIFX311hD_AnM2#nsjDHsw^$gDFixF*4x2r4`mCLM8Qc4~kP`y}k zyqB9B2F;9yM{lLxeW25rGqULEc;o272V^OI_IDhRcc)GKgp=m{JZJ0;%bIe2`rTv~ zfO+cp7X;HXR8~4%UqJaMSn!mMMD)v_8B6YGTE^Gh1Z!`3Z05ANan#t+Y|Y20KCd)- zaY0nV3g^5i_ZAy-bZr{ns#5yz5Lib#X7|z3Dj(MdYus8}$Os93Y#qu#;(h~TzXDX< z^gLxZdMAp4J?o0n&vg5ILTO9gkWWNh_q-g3tHR<>!&!q*$K=z?7GG>2yilI)aNp(L z_Eo$+P1Mw*N&Q&xGqd+ABRVC#3X~iYHK!=XJ&d*&aVmq*a@y2ZZHov9r1?XrWbk`w zk7>KxbImPnJQeLja|xot8vnYyS*h^Lt9_j=Z*-|H&aCn8kTIY3_UEH9)gBeos|P7} zcX;Oq`zTNtW0QJ5`SDJk5?*Iie2+y&Dx@EjI40xP?to)O-xm|$u<{XpNvkGx2OCO9 z?c}sOB7pYb$TDVGxL;>?1RNJ-6A)pmyb8kHGdYwv+C4SuThVJU%}lXK)_VLgs+PGiZq+M- zVJ5BPi)EDHhu=<}Ghz`1go}=cIL#);E9cu{AuqJ`Go)N{ZY76lo;vMQm%LZ;=n>)Z zzaN7mDak)fwMpl&Z}sh|nD01mh~7)(cIK45vQOM&-$`NR8NZwiCB=TXd|KLlrI5-O zvEygfo|&Clq@|^g(5O1(;8tFaH%5YUC6Jzt_=~>ykROzL(Wd(zJ}_1lzF1~MSXbIU z)i^w4{G0h;k$k(;&IN;zQLCJh)^WQ=Md3@AO%69^YRZ}Bx?fwXk=k4OInJn;s>9>d zXF^L;h+K3({(>VQTR-rJ)A4qXSzYJ>`)CfruajRC!+pZ4P3O#wUk{43Zn;)I7j;u_ zzqg|AyhS@^cE?WjKG!C@oMU$^Zyc2{SFd<(X0V_0W!_0o_qNpbw%y0&%??s>%Gb=? z+iu-YAg~$=Q;KOFcR$ReX~_*x%4xi)K@#9!ZsCk_vpG@ZfD2T;N6XNPtD4@=B00(65jcJNJpcb@=FTPrx(q4jMC5+$042*sBDisE;%Su2Xxr(c;)!H0)F} z-@{Pj!rg`OcX}IhPIZqC>sXERD;$;YZgS#j8Pb_@D@#~eQ5B-xO^MqxU&3+Gl7=)k z0uSP?wIXFF5?WnqH!JN4cDVb#jaMSG|GNIH(3<&3?o$i(H5s`R?*ERCauN>M7KL$3 z2`CiB->K0ypyXXwqUwZ%>Pc=ZIN4(J_QjBn9q)|TLMvh1=H?PWUhN0t5tsY|q&SMX z@Xm5#*lkYQDl1;H;AGL`p;h&aI~#mf_7p|kp?m^;zC`2+v#gdX5))G{9Ur>4nOkb= zH>G7iMc0ChM*04|xvK6rA3ux|tLfH=Wj3kHi9e(}(U7Cn+RG6C2sByog?Ouj>T=Dc zBZ@EoxxVV3r<@@=eTa9)@%HD~M$rIns{5S{Em=jY??RIPAhcdue-SN>z2=2kna8Tb zdh~E4MWUtA!gS)hFy-!gQ;uq?-vHf~Eoyvt029!~fya{UV?m{9qfWFd%p%H}QR5em zP^#~aosz4iyszHs%Vuh_w7K>8i=Me1W)&?Gi}NmLm?WaiVti@|;|ES#DP@}7pKP4r z1c$+^KBq|?6zZLRJU-LV&g_F(J=IH-=5y^w)Mvy(vY(hSNZ8Cg z8KsfApl4GE>l**gg*L;-&PEmiES$q0Pt@#LCj6IQx=B|2@>?t`FFCr*o!mR_qAzk( zesV6Z->bcem4_-9;S)Q{$DMd-wFm`E^D9N~4X5_b&k0jvCS8YgJ^@k}V5F9wLz1o- zPD^!~U{~mu35$iEH9b`@StE{USpa!$FAnGgL z&c9w1mT*+u#C!kk*7Yzm_aSoWuufUR%!rQ02;YS9laT(jEEZDHYk<>~C*R|I9{zAT zFt71^TI5xGqx8WxsblO%D759GpW95#YJ>wNdFzj(L<{${9;{ z-WBnK>3;YlmwIzY&CrfrNjH+YvWsZ6^==1ofn#1PzX?`*?u5^lSmmE^C0sT37%>T$ z?UtmxDd82i{ENcq(+G}AY78~MMtyQ4x}XFm?W*{+Z+or%)Di8MG9kwEcZ^RSuve&Q zjOL~uQGXHJIN^6)EFZgWw7-}%$_eAY>nq*c92%EyCQ%*OD2na(2$^*`z+!ftYH8H3Ut~pxE&^qqjF+5dckm);JSw@7alWJb zQ=X`#c*r%)n7I|B=RT8JgJ%OqEhdJU8!2sv8Hd-?;^vN1#v<5io`cbAdYl?+rgQ!w zfi=bA*wbZ-&*^iF=#U!zDi@cdS81S*NE<{G=`Usd27**LSSCteClBO)nEte6ob;yW z_8F#Y*;nfc^_>4CC8lU5!{Bi}J1pcN5Rr@9U*?(Z+=8}q04Yf8zgNdHOu|oSMC63% zPu>g?Qu?uXc)m-ix}w*^U?&d)Y0+8!c2Crh4*%JGl)H<+y~VqjHlRK^{BA|Tmj>yS z^!)42Sc2P=t;?pLMTgtBQdlEX)VD0k`RzRl*8~2JcHFlygfN~JLM6I$ft6-w4J>-r zlfM)7v4El>c5rnI7p1Mr=xAy@oh=sGvgL|G-xXLetnY|dPzWIIK&gY}5tDi9#bnbgzWSfM|Xlf_kozZo> zTblZBQhz{;j5AoM>N~xTF3+qy0qzFOZ0)Kb4V38^ubgRApVM=~A(DUPaiHTO6Q@N{ znDl6H+)V!o=mN$5$4YtYEZ@am%RpvwS`q(Hb#6#*g1r>^_$!Rn0`~{N=|n=_=@QQt;P5&^J06n=ytX1$dANAAH^~`Ffcysuz zNfBf0`fvxok&&}!*n*z7&ywAzk~5Y#pu@;0ihrv{DGa##eNp{^o;DPz`kFDDD1T=& z#zQ+)5r6Bg9BNB88%$bAu4Fpu#uifh-WS@>wvp@g=6=9rTtiGfs!6mwxgLTu>$2Jr z@sPu@3i<6!P;;sq2EFl_@%r_^y{D)9_UR37qO5^%0JkmVIu7j!ym-kpJ?)0`_T2ZP z`B=!bLIGtyud?Tk{fiE4s&HWL!mVS?kHYQcKhfsz)QBL8rH%YRu0V4qv{}+)5MkAhyk_>85)*7y*a5j0o{w_%#tyPYMq*Oa&vA@L%q9qRkA(t%A;DT@`5138>Xr8 zFt~Tf_C#d|^njIO=Sk6C*Rx}HLH-dg1lI|WXx3nunYP9YorXKOZqmz z!7SjGJy-cgJv)G|Bvz)Cm{8NI>U{ziy7-_0>mR@f$-S9|RJRrO8rdTPB>$ev8Aio2 z+<`jwZu{UWQtMNadu>glV}@jVmUKzKy(e7HPjDlVSom#XF*s01Dq80*Y=4^po_+jm zvGB!)f%cIUsCbjDNB0hQs+-ohJ%`C7CscnirC5O_x+%8_NqS?Jj{?`S7vF%x;yjHM zQa-l-uNNR?&}Vmc$|YUJ^@*UoSXI$*IavJrYB>j?`-M#{&<1luYC<} z5=^>;w;%_}f#q(#H!f(!MR? zczs@4zt75Zb~xy1>W_)wlAb}0Sk=-KBhAp|7p$e4zeobM(Yv6>w3v;(Dn8AuR$Y$9 zu=CZOcd%=V+i@)U@cH8y_9eR@ouTU~>*5QMjpE`Xl|L%$@QP*F+5Q*fP81QFTAuSy zM|aOH!zrH{p*``@ZRMwlJ>R*YD=`T|TvP`}dAeUlWvaqMoL|xXd(Y7D0oqH~{lGjY zCplwDiHs%wdNd68D@6M|{5CnlWD50G9J-2xpPwE!P?=_i$tLWA;L*XY#9EUg1Gdnv z!fDkZWP;+Ou`Uni7TFLKP>cPy>;X9I)U+x&@KYP~8NlY;A92J%8Qs}Mb-?6<)dpK( zDh1-a0rDuv0Vn@+jj<=Pjq}{fJyyWdRM|MW%Jhu-|!7Ww|9DbqlGv$ z1Hi4&_BRaV5cAuU@5+mN8$AxgHBoq{BQToR>Z+biCO3ndJKbCuYE42V)=dXMfv#2` z;4Zk$n5iok6DBvmcNS|y3vR}eY#uWtGW28RtkBdu-HEh>jFbdMM8m#=B&3rZOV>xa zC3qR!Wc^r-;a1a%X_4!>OyrB&7RvftXKrMx@xpm1jIRv^*E1czulo)94?}Hjsub>S z0DOm|0ET7L313B@PK!wF zYI;n|WayKHtX{yL%rOQM^|k`s6jP_i;MP-`*ZTMyFt=`a?&AypvCh_e=+eu-*kV(9 zKDA4s=QXR6*D3nZaBiG((@}1~Km`tuzVWQs3HZ!{VkL}h^5h2?MWW!|^R0cG(^Q#J ziW#_Uy^Rk>JpLxY{ckxT)`c74s;2QfrZD?j1!lk<{ZykD*^fv8&9K3%?YHX8-lU3b zAh$SoVp25r-`Nc}#DUbiW2wK#fDU2EAdh)eQO{(+opd$D{6iA(pF%=#VHxn6-|WWG z@hA{*csmqJ*}eg*_vRAqo3KeD)yRI<--ZYu+&JyO(I2*%>2rmHXy`2dXoX&il9x>gIp_g7R`kuA{?Iwj}^v_J^Ho0)xR7s)6OXBHqy6s&E4 zn>q!s6`nc{uqyfsJn%snuz#dU2rM|T`P=Ni0Ss;{-#b03EEHblnI$m8^ayMP7Oq{) z)Bk&FS~KGSBKh(0`$G#%*1dcnUe@)@9R8x-#-;tRmPEW3*H&IQ``S9kvy&und>Srs z|I~55s#}8(EqKxexoVVK?=Tz{3jq}&)mZ+YB+nOP7iq1_jk9??fC>3#wl)yWN? zgGV3rOw|QVXgl75Wh5SNCA~~PFdl8xkaw;0&)Er$A}OOTAh}nYJBRN4ge=h?lS!5m z^DYqVZ?&36Z=V^S9Ox;QLT?|z_4KS(EewYedp;HS`kWN_#E3LR@IqQ(03U#_Tl-}` zrnk>3AHyb1*1jujXCkF&XDB%pcWk|G=MN3>&oLV#m_bxe-@u}p(w8DYr`?p}&JA-NZPc_cHTk~?P&vuGl) z_l`^(uZXuF@>+Rr1)(v%-7uUAf2EE6+)u}R+F0v&TCcZElLvhL_}^F~(^5`41X-p| zIE#`?PyHPFy&LYsrN=ShBJVXxl0s zb(St;YDmzM8+S?_gQk}pRrs>v9!Pim^mN}M84fAO0O(K`fUtwR?G;l)D0q{`PuQ>9 zIKXG!@n`FXTF2prRq#ty#M-Nvh=wqP2G;!w+c=tWQCMCf{A1Wx{3ON^#XXR|So=wh z+?aWVp>ERSNd;VWUqYBSJ4GgF(_QA-xB1d=oAYC=U++K=q__R&hlrFgX+p&J6_+t! zm_nWH{|RgSYYaEfyRV2FS45@qmTEJLWR~2h>UaoK26SR#hT^E`xhBBr(g6_JPx#hn zyz&vHvZreHF&VG+D(cJ@%fc8Dk?`f0qqmXCf8v^l-E2fpg1~V3)bXOWmnO6Pilaci z?#J-y4!$KCZ@d#1SB}q|`}XWF;9!$vUtz{$^5@P89^w3rE>H&uFeIE0#ft$EufxO> zk&wLFdtYGI1&a8azK)J(q3kHp3A=QC6dM$)SN7ET9RR5aGa??rYWVgp-HER%d2B2| zPJ>?9=ZuhqgG$KyQUx%(O}t(3RJZkm)RS-si`Ybe<5}Z`K1+5H)bVmm|0EC#;~7ZD zRu{`ADR!h6ZT|yRI3gN=K~+Qg52*Hi*htiZbYRxcyKsfeXzO_Nso(uFZ?-c?dLM2~ z^Ua&HRz>LTZmc-h@~+miM!_)PZ%FlGSwB2KQhVWe)OS4_-+U(3`gygwiqm|^n5GdB(`4(xZmeMSeO?&uw?WZK%J zGN@??MZsB}g$wxW>l3Zx{|{SV9#3`l|Nlm+X)}hj*cxWgO3IdNX(CgTtt1taLRmxh z;x#hB@uXw}!#85{ZX2TYqGVz)3jVQYceyAvJMm|8`e z{f3#bwZegD!AEO`RVRpg6+Esok$9sf!vQ5!bC&R6a@mC{oR5U`eLrmnyr1UL*!>I~v{#nxc2}!MkF&e_7IYeV<%dqX?FZ4U8s4D<5 zMW3T{&nEjrC|!MQhfvycaSf||U?RtWskyycrb{B%QyP4S`{Gp-z)|r&VPMSC!zNcx z^mSbb|{Q3&9FT%k||#nit}? zrtoK`*|=?mj@J_y8T2Kwvy#iG)20=jXD3_YA!`Z+2t#cjM{nTRBfudJkS&*ms{ta( zykfg6zDNk)y}0tug%W=~CD)C;cOm1Y2)%gv-dG$_g@cqkxomfxC;>Xj<#Ar-a~8_k zKz|fZu!RQF?nTI;-Rc_$UM$SYm0Fs==>!rW2d9f0tpx1OT|acvI`3hcO%VmXmhdJ@ z*6z`*6^d{rCv%nGYkj$R^?K0EL3pMfOdB^HyIs{kd4Uf%zOWQe%RTH zHie;V7Hkf1SWdh`js3Y*iVYGLeOr)nOdzlM1jkD`adfk=yT)M-hHnjuq(JNQ?Oth7 zXYYtKB|@f@AY0t8*3Rz-9>(^(Yb8=t`)Et6mIy>CidVy;;e&TC{j!^~P)BU`OEwhR zCluU6{vS{4w$5jkPSk6ZP|<~dDO1#g?%H1a4YQ{r?G|wbAcj{SJ)H=B(!!UHwpD-1 zc%`iQ=9b;T-tnFQFguVhxY^?Yw1FO(({!3B*L%(le#$sx4YoA>vFEey7 z$uEG5aqgnBXV727h|CpPp;)-Dx;H^>y$?l65u@`4#J~n->A^(pR8=V_m;}&-^ewH{ zL5exJJ$1i_QkNv)@5j@ep#T7Y>8Bx`2A(|s)viKGU*A+nA-jv4zh z1PjL8Ms})8dDc5$ONtw zOc$80zxD0jw}G{LD{7r{Bg+Dc;WG$a@i6G7HT$5{Fb`#5N#kq=;Ff{eDfuRv%Rzc8 zc-G(GLP`BUl{yO((oOI(a1$l&E?H_rE6NR?ifX}exXmiY|gD!hx%Jm8KLcP(VGsVYm zD;Zt7v2dL&(NxHqs9X0i`@~xLVE`OFCpDxOXKKQr&!EM+R&1~Rg8k6MhtjW& z0C02qVAxX7h2K_J`DV{w#N-Cx6W>)K9wbS}aOL!k>m}7OBoqaQ>sAIojpn2ub(4o) zxSasL#?6O79p#D5OG|jzEzd3WmZ(f$7tq3|+gy*>$wGtMckbM{hZ64RhMQO%5Fku~ z@a{dOu>D>Kz4I1;V$1jNPh(Z-3-JWYH1{LXVBH{icZC$sj$aYkZ*_h51Xs;`M8vS> zkhf0O&dv_g4Xj0A_DlY0tk{Kv8*%oGdHpz)*tuunerNaVBQYrgP~ zUgC=92E4eJdBdPH)NeDtQ^LbPhh(Hn@*Lj%NTJ+|AjaS@T&6j~d(guj0D+3GiWcN1(6l}Xxpx0i_CTC{;yY{_1VLfyfyXsrnUOx6KPSu-dX3}5-)5P zO~|fVkAS+m*ZapOBT~{uUY{0ooIo3DpbbwF&zj-60YzXJ%den(nhq*nhPy= zu0gM*qTwp&m_~!|oyC2Do`t!f-XFwb7O1@8!QXl#VUT_*`c58dpIA{Nzv6@R6)~#t zG1UMQJ1x_Z5}wBvwDc9g@3sG$>m9YvU$rH2_mav2IxV3t++Gxa_~E~qa2OYJT{a_Q z_43E=Umg0w(c)Y4$s99HIW{hBRN}HR_IlExJ4-aRr)m8HwpTRKoc5nqds&}d&jaYt zYPvH&_~7XlK1uJENC{q}9Tk~BY#8_F?Few zcKDAxe{}Yd6f#(jkXv6+vmmnvIHW(U@f!s<`zI1aRw&xOKb~alWJ%Os07z2)Mz8Vd zpWb}h7WdnJ(@33MhvR1#!3L*=HeXJU-$rG3$rqACXw2E;rl&b`O5}+VD(T=~rClL< z3iH`*o*^TTG6LfdVB383eGfpqesC_UzM$nAWcp*RS@wlAEGHmlu(L9 z-D>_zqEKV0F(rcdV{CZM^@x|q2y*_$)>b!{r;rYnMXN?rwrnyg|2x{vT>|QW)?Wls zB!;#74$Io!k-uf9qS6Vq^l#u0=Y`<$hqs1gdJj1XE5aP4?c;y`mpYJyp1U%h7zE65 zjoJL(4@Sqkk377Xla!W-oHMkNVO=LgW%TAl?dRJEQVdo>9xtpXo_Ff8)u)^v$||IO z!S+W|`fF96F6E+Ff6|Xv!3i4-zv1HVCW)_-^l?z=&FU9GUxkK-m5=Y#S8aROl?Cx{ z^zy%y+ap5Uh4JtVK%;4H^#@V7Y?Pfau19QxnyCR!_i34)xPGqup^}Sj_VRKnc1b>2HVX` z{7v1cB(9!+;A_HJFqqiEi`4{r%bpxwnO)=d_2T192z|^}`FUBG6LP1nPJX8dnesV`I5|fV=^0A}B)F*Egu*o&n*Top zk;|m5O6q~zCa1oxRQAmWL})KfnV$izB@zprZ^8y$rU zE}L~drX~Q)zFoob54!AZur{JeW$oUeWt#jmBl??}(sEE-SWDnx&^?cniCu7qd{X;E zVKeiwVGIu?vy@1r6ihq2kY1#x2TcU)!7)bpwwAhx_$FweHwZ>n-km&JJQ?NR66l|E z$CEr$7@wI}mfbQL72k=6_R$Yrp9>w;p_MqCmspjL<9zENwbE7b?;q)3>KJC!-}{;k z8pg7E)4LNHkQ1P;eZ)~}(Fo%mQ5s~a?II7bu7WAFHMP9-7RM7DzrP^ncOzxN`^)nR zL-K*J#bj*E_TolwxZ%N#V1@k|4pC{4`Ynp}b_u-^&c_Z$uV0=d1fvX)77d%s=-kV) zQ+4oy<1|yNgP$%NOD91-xEKB;tV`y3pDsj)7J9!!vm(FtFaYijoS3h*mAI-F6a94X zI{5l|_u{$;|K4*nWHk4i@jcb^e4VZaK1MR|;NQ!;XL{+BGa_7An%T0pFlc@#Rb&+SlCjazcWl z^l4}2BdH{n`ds!r@(r=~-v1gYDGEveV(1giwS6rRAmJJPql3pfuc18;Jh*?idU}yP z1=EjgreUA^4#Dc~P1Pg=s5tn1I!BVC_@Lfx>x>DS!!;2|RTWYjdeBG6;gYS=41nGDs*y-*V?$WCAxK4I%cJvzuTTbSXLS~~ zUw$E}eS$fz-oP!j9P`ubVf zvOpLj{)aASpJU}eQ^CW*1wCm6e{nH&Fxpq$_ooFUEG&KUgvI>wkF(Q9Hd8YHjI4=$ zezWUy=6`g3O=myz&yM~)2I?cA!d^q(E{ko7RPb@wo^l0JN#gaZuUq3B?i!URpIhae zLShOAR%+Z%c~Z9=odev}UV5J#c==%?W#LFLgIxpvPSZ}fD{(KN0YmfojwFw+VsbK5 zcxP@~*~R=O;Ulzf8aTw+);Dg3cM3UCqHT)9 zdy{(hZNg0+98Z=6@e_m^sc#81MH!-j1TdUA92TG1*pfVqV8*2uKc(eWk^z1mpoc$6 z3L=eC;L%Sv;X){bpU4X?4~GeE`?h$72)wRaEoL~iJ2Ji1AIyg)h2ddB3R~zPbyMPm zu_?HS-5&MHvl&V%+5^*idbOZr@m0Z3^(H|GhY^}3R1>D#cBJwk+4c@8yU1m#Vup;m z{Ti`7BSFO|;JwtcG{rF|=RNi?C!tbGdZe(0T2O#8K{n?w0WoV(K2;NGCd{3YM3YSX@?t?IJ)14lmak-5GAb#KAS zwj7v_pZywS&x=_>blkeG%gg*O4V~&QK`!zQ$g;15bkduA2MrpP4giJAgV~9P9sh)j zQ8L8K&ssT$#vSEXG-Y1F(Q@gSGsQAZoM;m>R91cUb$q69T#WhC#Hq+}d4sD^d!HY6 z+H)4o01<4d@xrb;{>P_lr?gmCIKfJciu3zYyXw5L+!Da zh4K*%I@VDcquNp#d(P4{(xxTT<9MUow*Xl60LeLfu>63*->@V|60UFY<1|?+1o1<~ zy|zW!S@w;bpNnYP4MPYr=XUs03UizEcZMr_Y6rhawtn(6!eyFyFr2ctq<&96UF<(6)0oI&Jguw*(7 z*~^^N9$?_N4grFX)cVBM0Tb-v5Q&aT9P%-Lz+)hGBTYxtE_kfxam+q$FfD0HCip^0 zWvT4^@E9Cp^3avmmO&u#*hX@UBU{9@Mcm^v|GbL;2@LbGZ(4Bqd*3iV8FwWY`IS?# z2oMHa>+#KFJ~er4k_;6t}a$X@0W z2-VL)!S$z=j1P`sH9Q_ljBGBJX-{BfeVf}J=Svcg_VG{!Bq%?4>;{B?>-Hy#87ay6 z#NitPx4zy~k6V=J_;l_u56O-~TQlmzK%xE~#c-tGkyHFke%mjlW6=Z5=~kZZxS&FH z$)B|DNpmNnY=AmnI_@M96=cxG17n zfjWo(T!!qDnKaFOX>#iQvrUqVY;*$352VAt?T*em2AdM{DoJx?42==9ifR(HqaHGF zbc6k)JJu&!tnLXkz4NqfWUmO*B}&vo$;Gn1#egBx3c5N*YXn_SlEcPlKZV9Gpi06R z+!`lrHX-;-0PyfOvPDcC6cRH3l=v1T+c$3kYmZH7kzVnkBFRP8-IGHJ13J`hB=g5F zIGue^oI-J9wA&y-W=-N4Vy;8_;nbVdjzs~f|4v3olj3FmwE5bVgKnd4mhby7LTe4F z=<%*waL8d_=N;g3T~V9jQ}tz((Vt`&e>Mq|b09{KP-b29Z%Q;dSKKA!Tsbq^b4XI! zcg&oZwE>P^y;F_BCY)2t7P%@_PK@>MtgGN+W)VG_-SEvhckKR;f+wFY>MC+BzP?|E z3MqzU(GoK>kh*bMoJbYgG5s~?payY7v1H)r3KdUPdyLp5{h3;#XZ`WBOeHB)5=Kn) zZtIVHNK|5!|8UsOc%k9&Kxa^?CKY0UDCA#y^{2gL{weXQtFA_BIK}=KjuWP2Z2Igp zd^#};_~YuLAe%#v$e!~ydt#xE{HBm1koL$NY4uL;}pH!i)u-s801xteqH)^30B;!bdl zz`kSKSN-eMihaeRQ4yinFMdrU<$69>miK>%^mw&L-J;V$BlvifZ`2QslNt4p0Yj&y z9`^3}adD5e;FG4xzDqO03s@W0)mE;!*y$hmz+2N$EWe^|>3$4PB2G-J(XAzQ@+I>x z97@oRH1Be{kKqR)MV-HN9Fx}g(%klF!Ijy>w*%U_c5Fp0L|<&l`k=EuC(+}N(eIFoUq=>-t(_`UEf?VMu~YJwB5YAbSQ8dX=I z-!sTwF3GWU-0(q@Gf3`j+9@7}f*)UPS&(c?QaLcJD{qE^d{@NsoYZUwHdkda9)P&>{@vN6iP`kue8 zjW#92FC5QW$=9YRC)U?A#-*8M?`YNfrvKfaeA?lL<>G5+V zm)B$7(UuNN!8huHOCbF+I?;43E35oR6dYQIG_9PJp6TPFPawA9p8u`wnlhC|zi?*G z_f^hfY6iJd^P-v`qFa>o1~som>s=Cw(T-OZ<<{KAm|$_czCYPnI-Rs8!Aj&`};&AwlR8?CpZLjQ=2x36!Eh2V`d1L1<8X+R~I*c&`?hCNYK(Sx%l-b}8 z-6N|5TY`RGBy*mIc$3I<1Q;i%`j7um^`x-{zGO~}P|vk(F`4osycquUKUA%xD{AlK z{@338$q|WG1=k!&Dx_rh#*VQKTSE4)S|rGJk8E4I1gzl-Q4eLG&4GfDvj$Dhj0x$i zqqYyP&EMU3^m>yhUpnXSbyNrvO1#P^6E{v8e9W+_Wy{e(fddAq zb;k2ERDEp0rJJwLh}<3gyzt7X`PdtupMgy&(nrqSt$Hx7c62n*;XO4-N{9+wJtMV5 z`kLlZ+K7&B%HMhBW4Oh976VP9vW8A*DDCFDa&jzHWlD=&WbD$Z9l~SpYg+}x^Q5^8 z2Z*Ira7=NUQ(Rm1yBbR-F3rC)#lI#FdA;CCjOrk9-I=1{ye+<}7rNTiD66M?E1J8; zHn^^2tyH=<)%uzyYv1#LR!0Yo}6Q<8W>~vu)}Oi!44Q)q~c*JKDM^2B?xf%yUw_{MCR_`c}R2MP}WtLtxQTKWY+gWA+}kS=R%-iD zj)TEP8K&Q8s>1NFDS^Un1y1;tr0{z1CeiMkuF{}8i>NVDEz+*@g%I`K??nBSns zLe!MT*U{&%ms3`tX)oQ3(D9{&rVI9c(TABcgFrM!3n|@mk_}V4f!(`HcW`7ZYgR3z zc7O1;=oA>_^bfdnmcH?I42357uDN{bK}%Vmb74h&X{T=i+}zj6N7n00CkB0u zf)TE3`Bz<4ML@{2zr=`M;z^^}r9~c1uLb~C=I}!$d2ts7YLRb7Usq0Fn#W=4)+OBN zt)fxs#67=lcRqA@)#?7vk07g@w@kSDKTnaAs~*V05Wp+<3-)6VucC7o1}H|bN3XRg zrN{6j3zFY|Cnl|D`pgay$2rm-cg+@qs)Ptq3RPFhbePqE$?XNd@Bff>1;EB{hITh-x_BiDX^yMy0d_x24GEz(E ztre?mN{uButp64(beW#+T`j@G`YZb4=A69BdrVA$8*jPqcNaW}WW1Mug8oxrv-gL9 zxBXgY#I)_V9p=)!Y|1xt#(kcN@u)|ZDCdMmh84HwK}c?~+Wrq;mD{_(u9r;{$;I3Y zZmXHa(33Cp079m{xwL6IX-&2qX#UJC3DlZc+#=Bq~70q2k7Hc!&W7+ zK1Ioks~ObHo1$MbPKenHtMkxyYeKeK{Swyiq22lQl))mPSlAKZXYV_Va*}^F%gcO< zYR?Dve5+F=3zKsF#O=G?bz_rpB~=NPPZ~wjn0FawUmDIH130n>fsS*OFDo|^co-8h z&sz2B_(sag*)J4AT+eYEcYFQP1zA=p^cCm;_tYy*EAI2i%$%J%(S~EV5?=tPlc=Tq z&Rh0^i`j1M__EG#y#f(mi3_Cu;WGcwk{gOGu=W_|S7aJnnHq#e82Z+Kih1{LSz$92 z`@%D0GsVjduI^T--gRcP+G5RJ4GR~vJ8eLUw6`Q@(}5pZCi**;*Mr#GYvK27cWVg( zcdmckSZ-CG*19J4vw;Bb~y%Payl3`OIhh2N!;msM% zpZ^xLQ6DW-3xv4}7n9gzML5AjN%uCb=Ac@hfW1y1e(>kZ^ItB#hP>GB_t0pIhH73p zW2wvwNEYF01uV{c9V=uJ!W95T1gD@-9f z;}C_&zI)*4U37IopQlqIP>+$w05A+-S2j5-t@<(W@O_Tcp5Xk=T!WL~ErUMRHU2ZZ zv?{(V6GWAnz6z}hcafi>s;%$e%4z}youVlyuWY#lB`S zUBkY`v;G1M-b_#>pY6M$N* zCEXeV{d>1-6|5MNGelT*g(cbYAGRLD8~(IbroZF59@?2}(eC|fh^dpFJj~GK@9Y>w zO!%rktiFrjzQ|(nG$vb(uAw;#3;;`F_+u3wIsC{f$n!gKRwLezsQyDE$yN^z!1$raam;!8^E$OgvzK0qgdrMj>zp6SVr9@7| zY}@~6XDZ(okJFdAsrJyRJBX8NoJPbp3M?Lpg8%Cov-a(33DHQ_C> z%NjnVqz(?bpJo#`#81#Xmd zdF9VmJ|G+6i$wL&7=J>7zwEK9Q)HW(LqL<5W*SZW=0ItDX99>ew34Vlcy-oQ3o~Giq4cujQFKhMJoRQ4yei>qr)F@nC4bgW$ZUh z$pCz4l$FL-t{7@f8ZhZFambEIIpNMj^UrWmbCpD1mhC%aElVyFh#@r+=AM#%k_0iu zs9TL7RkViQt>|_`~P5x#iw`J?uJ-*>FR|ikoAcrR5iz9SYR>eJ51`$ zl1&wF^A|Z|8$Z(9*pRqe!S(eOL-t)fK$4A;MQFO@Co&l#h^$*hyEnSN`DRj4LUirr z6B=i|#L`*~KvUR{3MolGA_>{Lg<@VHZa5QDRiB2187Z-}fWbIaU`YgxB^yW@bzui> z^foWC`G=o;q5TLx*;iC)XjX@vUj<5AIRD#6V{AJI)Jy$ptFQ)#Kom?D;-I4~P7@j) zo||skItJv7-B#H^X_i4KLAeK}_WfJy#79t>ceq;QD~!m46!SVkl8_xlsiYMu$2oSU z$**|ZYiC-EGiG$i@RH+BHJ#WwCzn=`oiOWP6Tx)roE2(X2&Z7zkFFm-5dVQ@G@kpR z&%j}kK5`K^=lY57S75gu@wWADMfNZDz`(}!g!y5z`pR}3y(>i(HYek_VX}RCi7oYW znHO?xiWv~0^7RQu2=j$4CI=ojppB8f9nX;c5283|^ffS5L>J{-A@1=$TpCm5pDN5^G(K-o)Qm`!e=V%G{uZd>}7nW&#Wv=+VkC+Qsg%XX; z(R_TC^%04mwyRzfm`$g&H-JilJ*muc8k@ zAd=k1!CbiAeP-|2Jf~5ZSz!E#{U8%&^?DwPaf7gCPocOpMsRl4{W%n#LN_~+r}?Y2 zksM3&CEqLLR|Xy#rSSK2ekZBsSOwPi!flM2MC*0H`G~7$%uTpzj`Wcci&Z#aCvJVr zw1QGZES3lwje(OFreWn0(~c}p^|{-BP2avo7rA|3lmEJXN;V165(gyCOHAbXU%Gr7 zWgjm=G3}+Ps#y=rzimXju{mIjQ68DScR%Xlod}Z6nCJ0t7SVyYLbe`OZV<@7=ZazR z&V9JrSvrhU|G$EnN^-gn9qv}c2+jXyiK~RB)q$MrEU?E&qR^txQW3uMKQH8axc)C z_@ywB9=E^YinnBavERq8Mua7?2nx?zi*$(Yehcu zlsHPh-@TTW{Z`IZ+ngIso#29mQiMh>_$mjT5cj?_w++AgIkI=5Otyj^Ev_*V&SJfe2ebi|C=kMw#)2_y_nn->>p=~Ap>dpJ9u zqAzS(Kk8!0YOi;2)P{MNs;c6@j0z#pkcs;ylg%q>By1n0*)8yrzIzsN6=*hq;p!y~ zXYAcaQv~JdxSqJvP*e{eIklUBEkyf2P6YB(gHL+`{jVhPw?x}*oJ&byEje`fzxcjE zYL%19*_?YAmC=pgC}jBDW=vWPFCi~e=KG07baiF+2h>B8yuQkNwIu5B-{Q6~*W{6v zuOH|huIB^vCmtEOwoHUN(>o`hu`mbScNYv~4|7wlWS5m!Xy;o!xGz~<$^X84TK&sS z$K5~1-QRYj|IRX9SKBP;F{I$?2NQ`XD1*C=?YzXicDh)7&joOE{exDl!0O@?x__Li zLWO;xXV}9ZD8Wj=*K=u~UUBy|Yg#>{Otgfn821{9{YH-#z=0cP0Ic zLS}Q~{{t6GhWvS<{`!A{t0lh6IjZ9B-oUZf6$A5VG*~p^ydd)Lj9OkH}hH1X5z_hD!|6(p$B_(}QuXRaa< zAdkNqjMON)MwS`6HDc#!RWvJyPBtfpsfr%V_l5rpLqA}oP=mh_^m!wj6>N@aWLOp_ zD^z zXEsDOIV(ON@tF@8S&)sUG4@DgM=|bu`^D0lDP`aue4}z2o@rGSJSvmZH9~2`Hr3tt z%;`~@tEwLG$7J&->}1bSg>l5w&9PJ-OIM$UGnp*bhE3I5+6oZNqQZFaBNoxv_q2Jw za@*B8!A7xbYk0%-%~n`Y7D2?T==DVo_I|MPyCBafp54%= ze79DPl*C{qIVc8xj5+Q&P`;R|B;BkG=7)BB?HnPVT(Vdv>d#kxnnVnYsX{#I<(7(7 zy3TN_xz5Rx!KaR;UaQlZoXdEr-9$wTshT#+KSRu2y>EMrZlZ&D9M2s+l)*ZJPw@bF z!cMK(Vx!gck1#^#Y;t7-IGjk(-C$w`$DHJ3rLAzKpBS@Jx>wmWsdoP3Tpf)CKOkWi zhcr~I_E?OY%J;?OAvr@nN=5}ANd6tZn15!T2n>C^54#L&=3c{A&X*RYi&b0}=Lo3C zWUJ4Lk`vP4xn#}u4>PLoEra8hT1-si4UZeP-fgQ`F%fYMS`Jnr!i*gKmdZC=-7VGxzI6%HSLk;?o|NcMKnX2bLX|ZoA&FPkQpt2oLf$8gHo={N-DHK- z1H>mZwhYkM{42?ldU-O-STf^9_$`{)SbJ#uo87D=2|W0f+~gS2-l7fj#2(U|o8k<3 zqf}(on*nGSbkmb2_`bK3Oaqm(ylDMowjR;*ys0toc{&pw_ zC5ty3bnb9m&*79XHMW5Kkoc(F<&TH7Y1XgF)juE~tln6CW;NV@Jpuky6OL6BN-wC*qD-~!$L$r080 zoDV0h=}IojoY)-gU21zImZhVGwxpOet^g}}kC=2gpSZmaiI7u+cL~5tvQ}xQuI8T> zsPQ9@P*)rks~Db$j>=J*T=WCIqr+EwNbHd;p*QHDNU*=!+sVz3byuixTtEXhIQpb81j zhxrvf%SfC2M(~5Hfda941O+S-35Jv(#i>W-Pi;n{dn|*iP0sA6G1;3?!B5<|Py?}z zXYMoKK|lDDm^7xCgqNtlwB%wA)20^UjCZZp&6$h`!QFxAN1S%zs_1%pRx|G3Z1y|g zebL33Q|GI{kz)QsC_bbOIM}E4Ilrt5ZVarcOl%>pCFlyO1L&Mkq0(tH0tNu1Q)>=d zGp}gw>RL-kpAw>BI@Eks;!q$2+R2^dGfYsjwQn|(AC`e7n-G!CEU6`_6gy29pC(UG z5)zz$JgO@7mkMHRHBqz?7?I*{aaup?^i8O4h@H%-+?5kmsf*fc64|v-X%5=*dHmhx z5gJ?@f*ZEFz5#zl-VzNilTDb7(*!O*C(M{7hz&4K6BciAl2F{OIg0!7^f!vLc+z|| zf9d>D(@Gfi#3^Cn1#CyR_z+BUoV)d|ugYb)hyif)!Ncg(^f~sruRiq`atZ_Wl#}cT zaMvjK3y8v2c%y>DkUWJD3i-39%1gLwW-j2{%mFpsz4;2eXfv~NbExdM@F25b7y|U& ztF~|8WsZZLDK}Ps9-h$yyk`Q*y9KVQK_?U>CZr!A5uX^#TOzFW8f>+iiB$gPm;pay z-1An$X|Y%)5TepVh=Q5<$skph@3yXFc9cIdKu5*lMp3vU0x|mAd6$W#Sz~a(!RQj# zZF$#w4H65Krf*CgfrUl-DKTT*{6g<|*sX`-4>~!$`N1<{(pgI#KUyLmw%SF0In{mu zb2W0RB40=9&e@$~YJf^$jxKRD(YbJi1IQ!T%Yim?NRwv%Q+Fc_*;l8dxlF<9Xy=p4 z|Iua&gOSBzig>pxFv|A|*-Q6n)gVlf9eQ#sfc74aRa@6o@_V!$Ph3b9rqJH0pFsO? zna_Mu7l|A|5xD0u5!*!6EZ%fc0pxdN52Q21mL5G4S^<9k$sRggk2d|%o{8|nQ zqS()%WY_wCj0sy!fXI|b5=p(Cf_yh{U_ap}VbZXHz}LQ!yG5%RpL}&MQZOhBJwgCs zN)RZH()#O(gP-h!UDc<|$#InCF!1je#H%J33zcy}r+=NXR*t}vz58fDd+G+?Xr8Zh z`aKs+iw5uwxq)vyc8=28)4u4-$JW5hB3BP?KG?gic8W{ZNwKP|2AAo3_-3_B8Kpz3wC{1e2i$15F-}cA)`epyojsh#J3QLEmxrvblyUa$s;;7 zB<%s>3GdfbE0{*d&7oyt1*fve zy?o1(BZiV;@q>ZiDTW5*3hl)?eB_Km1CKT&%$!(_C(sx?5S_Rw)zpmn+xJ9*KXy>L zq%%iuZrX^c$JsNtdXvsse(~{QzxO6Mk5@i;|0}Bj2&rk9KWm)YahRWyC4J6H8s?%$ zZ}|kRh~$-UZwot3Kwy!D!$_n5sxk8}^100F|Dt3_q%@#j9o@pU>BK7+zZK5OqGayo zH@)OmDNywZP_>L{`T29#-M@6(&djh+CMG-Ev-j1Y58Nq0Bb9Nu)c#)0f&4! zDtYB47(#|BcrH0{#S9k*cNo_OA(wV(WpoHakon?wuPy%!#x4YNyCLU2tx>$_OrxR_*YAs1?SIu8SW)8Y#$E>uXR{q6BO zXxwI+&ecK4gdi@Ixv=BZ!AA(lckS*&t_|}p2A9F2o6Eh!4EL-jO(~m~k!DllN+Ua} zFRw=?px^bZIxr`L52z)o$2?dwOn-pE#2ohv_ih`J=S7wn;Z{F7+5bhcv}ot0M5AbR z5Ty~fx9UYl&HBSiTr!~%Z!);5qbn8|gzW!gDO3)yiZDM_pE`#fZy-@I^vtq@XzjF9 zR=skIU&6)_L<0Ks@?D)Ka(>Xf+}vj6=$0CzB4qGdbu`1Klw<^E4rZO84ev&EwA2mki(ryK$dvr1c7AEg;|2o{_1@?nHqS9T~ z1`C?_`Q&9}_T=2C4vNUnK|=-rRHgu~RksM2OO`F)6rE4l$g%skY`77XFpl!!5;D!Z z7FaltlOBh(J%~Tugp2EW4gLK&HA~lowvd& zLy5cQVYYl4oL_n6J1vlI3Qc_vG<8C_=^YLHOkOyVnI$P0AD2A-PB=a^GCrCXru3znQ(Ni8Ox;wujK zg@*2g_U4~${;LCcPP;N5nN#H>pT|y1S=WZIWc|_;*xWO8$L5c1NLG)qc1&%$nz;(! z82_v+(rplCqeBUi;>TOvzYcs^cej^^OVFC=!V;}ND00b!2eLCZ{sBZUoH~?X#WV0N z*km9E%D)224oQ#>N%pU|hpM6?P?S6bVtU4%RBa(TLP&JSm zqtj5hn9e~MH^{i*#c$A@(i!?>{WgrY1n=DNX>t3}MBdRMDgav6oPIH}g6X2B>ie-v z{3lwdJ8#&_P4!W1Gbk4WDBlx8u+PO#8SFdAHb0xTsNnGRJf8{m^rGi z*tdn!Moy~J>r2rB2dI!gW`A*IAu*Qq(x&uE()i~S{ulyH?B{6nWo;gLBEK2ZX2cRL z-T6EQQW1x}9wfI6eO{QGyIVonSwG4C(L9zZB7zXv@|0cTi!WzxXv{-CW{Y5Z!3K%BljM+ zrWS~eIXm7lmM^?nBqINk1hFjxn^)V|u0*ZG=Cgdc%s}h>8|i!wcjqCWIFT#Wl!y6S zTDpr#MT#UfMXFE`9<&95gLhv=bq1r_bu~$|U@>T?s8`+V1q<5`BqVgJejGZOe*9oaiu#luxK*`o=m>b+Dvsl%^K-O7D}*pqml1W z?E@F|qjirAJf%3Z<4JW;OEhqbHr(6c&*yYn+x-EB0`qV{&pMO*-+^()T_osiBn;_S z=J|GWxm!a}@!9a*ZMWvRaMEMA!MVl**@HApb@o5b@@@XGe2Pw1uTryHIkNg>`LWS8 z`hPgfs0FHSi!J;l^26RgBUj%LtC4>2Vs|-HFk6$~b5!4f9hhc-7PbY+7FuNOwB%cz1@CfgGFmrXPlA?pruRjM&Cg}vURDe zZdR#oSa8HHt)vKP6?9ghSjv&wf4RgN6+~w~brxYtpr+A1=D6Amwr|*xe$RI|RJjY) z2*OPIhPf}3cy$r;2+`N#s!oHTNBqjgn$KKHi_D7~bb?nKNF}(dTe~kS=4N(eMjdbI zDoOFLjw$A0m&h%r7$o>H_+ycg`>uJz^o zclYuWIw(QN8Mj+4)^%pg@vflIdm?wQV5d z1CGUwTiF>M=wBFjJnz=hq}YKJE+HzQ!+YgWZn&F}@c7Z0tj^o#)>59tOl{w6pHZOh z$jx!ya@jL0CYAvg1ed1s>1FaB_DFjRh~Hb~ROnG;@5#%&J2thpcdhJbN!rvkbs%;2g< ziq2W-L}*#hcGc-_k}c+DhpR@Pt!#etBQM2R2cXIg1h*7L2b+b3BKfOC%^~dce3nUi zlb8FGnwzT6y_+>{WX=rRVdhGRExBbc|wSs&mLQ#&sH4YhMcbU_Bg}sJ0^!`#9ng1zUaa~t{Jd}Uf~@Qx7gGVGNNO@H)}8UN zaLV4Et<)5!G`@5JrR_YU*egyz#*PBeyMm}>;@Y=Z^;X!+CAMZH^9PPR?KR5L-}5_< z!G@;3q%6rn&wfRpn6s%3!c0pPfVK{0+w6e4a31q0>5UqmZ0zjD~iu zr;u}VU}ls*ijWK*S@(OY48P+JK58RdP(|k55oFiOZLZ!{+O3a1O8m*1pg+d~N@*6LB9@6(LBhIxKItC#|CEz;TVQwg-T{TVmcBaI z{7vYX7z;;?CpYx^H2>uVU2*=jf4460aVh{cCV}&Ad$w1{`_-6cvnLlbxwEqUJsV$o z&tC)VlAyOx(C1#9b2QOx6yR{~EM7?Qc2!DFMeiQzg%Xj?C4&|Uy+V13x}$Q{%|pr3 zxJ+(>-P+@?`$e=Omr5RTK>HP%D`<(V-^62(jHgyOe|;mlbn5rGsNnD@o+n@;j?xEX zJ%JQLg=bc(b2EPg=NnQo0o5^2X9is~die{dTuS*Q!FL6T(qeL%@5_1rKg2)E9YE)*IDTNtHXuz` zkj`|oivhaH#3j`RDGRfeZY;e_36|Ke2AaG(Yx##-r7GA&IWA9TD+n}sU0wdc_xa`m zd|{!S3`9VBe#7vpAf#)&FhA1&(sou%qo+ILCw##y>iym*E}`qHtM5|Gn?yt!4|Pr# z$#f)lcZ#x!0TV->g-Qz z__Q{p1Xd-rso3SaQZoOFyTSii?$i zXe~3h!R)e{{yO{hjg&nVV1?|pv)A3Yg}aXWW*tkC1y)}t=w$U)QXJtU)-|~ zP&NKCpQVYUBT-o$v0#&Bn9jHn#To=j`+n)@@~z`l_xlO=hCYR*4sNF?8PfXRz!NOk+lP0Kpj#^k{0IyxNn4sV z4jDv{2j&t%E-bx|l991l?`40pr(WQI;vsya)6lnjG<&>-uTt8B@fml>oF%@1!TtAd z+kL41w*cqQ(U&kEb@4$#(64w-JM!$8kHtl{X`Ia|u4}$QATy%sROdCqjdY5(QH4t2 zj?}DOf{^pu>e^x92=F_X8O7>{(FN$15pe9-7S4+UPQzOKQ;z_G4Z#!X#^Ac=Z@^7o z+y%G*4NSPfpqT?X>(_k|TyEh=hb2;v-W6e5HrV<$^wi!|9rmfSYcM#uW&!hVmKb|< zlI7H?`Vwa#In%x^0N5}T73Evp?wuX`{6uVXcyEU z>F*v@l`Ci-D*7GJn<9X3uQz%;p6T_dopMDJ3WzA*l2jE+yIeGQA}j3<3MOX`#ECj9 zRyr*a=H-$JK(r@Q_{n6kv4@EfJ~6nMK%l^;FXHBxUIoGzzi^gR)LtNJ%*al5U|xRn zwb>~(fX4{|#{f>oxS8*#91+5ko|2&4R5&8=HR50GPcsQ4_m+CYCBy1-k1qLqx+}

SJ*?a9hBJNeIH;OFPd;(P~M}Ih{ zalSkB(|5fUKn)$DI(Rao&Yx)}${V{Y(cdrLpHK4~lDt&SgBTZ=*S<1mwkN^RDY zFz*-MbY8nFsHx`#RoF>{9RvA*9WVbDuWadR2@gdxJC<^tt=FbcU(Ob1yY9MR;B;KF z^JumE2_U&*)j${UdBlK0C^A0GZxNaitswH*%Z-2Y$8Im3c4w3hbT6d>F#Ro%zuSou zW0fAgDQ4u*viz0aTr7X{{wrJrqnBHQD&>we_4%XgwO+m88svwvmvj$5GTIV4+n$RU zTEV|m#lDjJZzgbNC+!XV_+2E!A6c5!c~rLJ^F5tZZM*MOOHCc>Kat5xnUFR=g&px{ z58m{fP}hHqE)%2n_SUUqJ-X4RmcD3^`#Ynj3F#;_Q4*g8vm|Hz^)G_E5J|Y4zz*GL zWtP=>>~NA5&t0g|6uE2?+@@}ox=;3Y!jnGrd-odGQgBkSL#SpN&pE2NhMWGH4C%U5 z=<>*jJmq4L$8bn5+= zDmS&B^xZZPA*oQRlP9?O@zKL^+PU60n${~SmUJFIT;*S3sJN{0?*(%J+e`q~(eSSF zQq=(`i8?!UXDA%46;?5L)9X_>sTgd2Lx+dntucw-vNF?eXFVt&3Mul69Wn~oK~~3V z(ALpK2mU_7QA+B+i6uZkAGv9z6^347qe$F6(AvQ1MSCca?p!{lEpl~(CbC|%eUJdU zJT87dW9UP4Uu|YB5}HrbHXt;I{~+M8 zAu-;=eP=2^i;TI=oBL=hZngi>-azOD3(8M+&MxN(I7+Ju#h!vg6UrSNX(SQ1tG1~` zc**y8uY5D0-Mr`4Xn`G^g`R(Jf~%wX+VW|2&NA)GfjXAd=-{_rKKu_D*io@ve%=}Onf zwHWq$zO7z5bfsJrLwQql|O|ZuqMR~oGtPnISIc9Hu!w)Zm2De z$9={J*8#!R>mmVjEaa!ET!E%1Ty*1p?_q-%_z-PpUISPS?{NY&x+>6lpDtNaZ)>{f zy>0NDq`!9S{FVWOVVJvD60lj~wZv;u!3zKoFT;v(%7YbKvkK?EV_mcAW#BFM$tLC? zA11GjMorNcy1S*RxQ|vYsOH{z3maZ&c7C&OB=nFnkT)?Ai`TjI)707yR=A#wIGe5^ z>RP_>)^r49a-@vs5TqBw;D-K9{taAxrOdIkC~*IRD%{Vl=?3Zawq^IP$GM$8G+eb? z&bh||ycrHGyAh5hFX<3&>B-J;lNoHN_f6;EM=RblE5?lTtJmMxLO%;QQA`j*Ch0Kw z9r=*(fvWpbjj5@bp9nfKl5&uMTPW943^ zi^Mx;h;E?41iW|IC*7a3r;(Y{^a~K35VzMJNWJ4JHoz=kFMDBnjwD+x#`j0iDVe z&)}u;Kl={_@PLw_)a+|Ia;V2ZHn`YX0;DDr1YGVvJ);0Zie3vkM|TW_t_ey&1{p_@ ziOGOtZj?uYg7?50zZPQ1nHNacFf6%BPvoo*XWlet49)3kGrbzDD zx>IOuaYX>SD-Mimf_-TMnaMCqiKhEcG||+t`PBtM2IL!`8zUX1Ld1iZ>W!WPO~q9MP0gZ=!dRiSSc91{ zRz46k-muC(K562q*dXeR(vYT%lnRdsXK|nloctl)fPUnx?bQjdH2HlejT0Q%;@sXq z`zZzRDbGYOw{T-OO3NA0?%9VRbWpGpzK3BJMo$4PZK?;M7Ii8J_c)j0a1UBJm~TlJ z`G!sUHbq8dnMZe_2P-1I#u28RAHbD72eQ@KAYhywYmtB>m>^TYpuGPWVxCER!EU(3 zd=O?*4F216y?2rF$Il8W(C(ep7;0(G4d2RifetCTn%F7``0zITZ6IMke=rzm!EB5> zlg@8#3W*Rsaa}=@P2n?lrsOtp+C63t?hFv0pswoHfGj$HcFzSY=xaoq9Mq}6Zt(q= zkWOJj`uN&uANUZ{S4mb-CcgK}qItsKAo@O!RP#ym-#K>3@7nExdNSdm zKrdSL5TxP=p8@u=ds4r64nJv zo|X&H4EHLn+Ntb{@_l>weW4?kO|&!YWW_Jym4l&LDn-tZ+7wyQ#nlKcMeT(i0|k>z zUJxmaV`WRl?2e)gd-xk%t;Y^;)1mZ_uyN^ z0_kwn!4|7g=2BYsCJQpI#8=`%kKfG~2Rm(wc;q4B3=-qx;D&8N>}j79@G$|1hEhxE zgm8=_O+)DX1r6tp!B_BE<}Z! zzZv3~KA9n207Lw>1DgEX@kvL|4{5*0!NT+`INT+kX8BSz5YLCOaX{Mq{}|%cZ-(H4 zXt*y+rZSy5N}tWDe3MxT(sL8bph08E-mCDsJr{%UvVmlaW(YKM2X_h>g7ENv46zHa zB~t%s=bCWHDs2|Vj&1cU2`3K(7smwbd~zn86YA13+ClCT6-2p4G^Hq+)#)Y+II_gF zcBAdd-_{epDK`!f=T5B?&u0EURg8n0qm-jI$H7?GDE_=lx!1-Ekxjpth7`33n|F`Bk3{1PP1*-CPoa*1}7;@wtzbL6* zskb`EZ(@oC`O205GV$R0KD1)5mii8SV_*N30DO8?V?Vfy&bzM=@7ykcnyfMCe;xqQ z`=O=WGsiH0d(+#AgP!pQ>+UyCME?$so=ZCcLLrKo;R<`nAN!#^3P4n$W#DIuRi9zi zc&)wcE{VIk{&vHRM1ETaBj=47KN?9iH9fk*?#>03j|);hvF?K-e`_hSlD(Xa^)5y_ zM52(2p;;cebsWh;i@TOludO3Y>XEXgoncz(fnfU__Zj1K<+0;6A(*W;PjY-8AQ0Cb zPaT}80kMiAvC{n|!hTDYzWN8WM1{axXGJd;EaeA|I=e;sSo-<4-+W~*H}fB#OAgSRQR^l%6=#wv^n)y#;OP2E571E@L?bQeq>q$@v@K(`PrTu}IP#{W zVN*6AcC!GBbb<23Qt5F}AfP7Nz=?7O#isQqW+yH0CFO(xsi~OLey57LMq@JH2CCdZ zL^Eel6Mp|y6RtfQ;Ovj$&*58Dbe#IXN}`X<6GStS*wMj1)5CrDl75t>*G)~qVWPjW z5+j;Gb#mw$@8jnJ=54Z71?xvz9KmFf0voXs$u98-;FunGRHpNgN&4(hqO%V?az}|6>XM!c6moX=o34=Ql(6PLUZR zY{F$fgoNGZRYf_VgUs`03Z(cATSQ4+c6?kGNj9*$wx#kIi!$IUH{S@3bHz{W&%A;F z2PB*NDFCaC)5Sy+AVz~_ZXH_CG@6nT0sT=SN6E1f(%E7zWm((r=s`%idVeBire9Mp zh*=Edft_vG%72Q3dp{g&;+ptfS||*3wa@5c8iyFF#`##D_v zv`qWlk|L$7Uzz`48rK5?aeqmvFbf2O=J`#QFLXHL<1yNe#jMdh6(5E_H0;SmTmwx} z*Nx$dSYedP!9MYqKgC`mr#r6*%!oKbroWmJF7xMiKP@X#3XEE)r-xrI@umV_e5hmh zS)=>^=cQZnK5M1%6SXe9MsKM$y)sJjUhGHwIo)FHo4O%38`N6=z>y0jbT`6y5OM^_ z$eWx*Oqdoqx>um51zH>)vfl8bKtZG654(%9ZxSNw;Ydp%bm&Bhgvo8`qr(=9O72g5 zrs6dMXBx7$y#+O3zo^Z8p8Q%#D^OHc`UsOv1)9V;0AMmyn`VQDm^SQRd(pS*L+$&HpSWVjY-#mv;&!So%>0fnn-D3b8;) zXn}|^cG#cW19FtHbL@(?kVlEVs3aJ#I7bEZg(aG(pFvqcHGvVE(N=KJ(0Z7t1VWZmY zNwy6r%0c6e;cSm-A!DK^_7w+Ue%*)!mr}WWq4aLtQV6z|j04`J;bQCk(qKI(x&tUM z{)Rmm`Xj$)eF6!+zGSnZMAu@+{l}%AN!~wXVfxXo<^l7B=d5)6v5-Jh#Ru*{k12QM z9^~i;k3dw_5%SVW<#xQQT8l&461yo;FU)1dfnByUFdD7=L!!Sgo|`dPgoVQ3vY!4q zS^H7*BlKd(5)2^saw@d-X`-Hs07R{ly zvbd+R?~WhmV3{2+h!0z!+`%aFYwO4)!^8=XZhUQN>Z|}W-rJ4>4Y)eH(&Y#-p{jT0 zcHq5|$5&L^J3OWri()n*%$3Red^8`5T8CkZ$PfreYGBf89IYI{8zm24Mk|J$)!DH$ zvY$}zwuKdtd98OUg`#_(x6{HbX0_rlAm1zTaj+C0@>0@!>N{DxiP7IQgY#JeaaWC6*>#Rg(p+@Qzj?G^vpHs&U zojE3+f&a{iS%&i7xJnqt88o?(S;tCLvMk^^-4{^sObZk&B*%`OrIaOYKuYQ&%V_QLx%KXWP2QCw!5lf|)1!eHlP zJ*%kQn7XRiW_7z599zi&F#*pE0&xfiy)f8)YMB)TDF%i)P`L?I-jMyOQ^ln#Yl@Vl zJL_P^Y&)Jlh-geV4MAiIl;Ojr4Wd9#$hhMhF0O3JodvH@5vFvNv8%}{Ta7i*s zza+jGJ@13w^!*Db7|MKeaf!+fFF+=BO@i~Q2K}6 zC&}kDImhWdxuBQ}d|~h_Y6wOLAwws}45};$$6XW|a0&tIA>JWE&T$C|p2GMWl*Fg` z`OLX99H&ViF<#^j=m#~hl&)a|CZ`d25ExIhn(;X4_-Wbw_!7VuF5&|hXw-uRYM5B! ziu(a*{vOLUf%O06J(1?sbWUh$4y%5hnd;L)nE?lA@+r)%zj2KdOgG#_hm`j_H~+Jg z_cB2f7nV*0!Sknkj0l>YO-CkOg%U4GX(9(CU&aCs(C7{T^@smn8lf#D(6jB{Xv(Musn3H(eVQED#-5!!vSvdw8oIZrm z9&Dx{R z=CB?XiqTQPcy^*g3y@&{_!1`iLiCwj0lZC-8hL>QNSAujNK_89n9UQj3I z0Wp`#;dM-Q@26JR0ZS#Q=ibmAaI$#t{mp5CENpv;aWQb^>gF=*c;wBK9-WiPZ3n4| zr`8M2-O|k=JII2sPgblg0eM+hFttj7;N21a~DwVAOy(wX=0#JN1Ef3nLuE}F3J{e3J%Aw#ljZ50C2AscTq8UtmrqW@KUO*u!Fq6b<+F{4XUgghN}M)0RNI%AA(d#pDHBb#*Vd< z#nK=%zPyzfT_rx`4MEI=OVGmPAoQP`Y|fyZJK$PfTIc5s@nLe%a~WsLA)}m{zXLqZ zY90|-ggy}cG_ZEn=mPh@$!Ov%IqvNGAEG=E1yBDgjEEc*#5#bEmCwMiYM8+VL2_Kx zK`J8Oa)lj)k!4{dq`w@zdrLSh$Bc972+|3_xND;=1LB-glNA%9*GXvj`pyjp+k8&zB1Iep$=vVj!RFV^z68!kS6<5ik zDA=v!5X4pJ(G1KD>~iUc+1!U^JWK8|p_$>uv~2NDy5j24cO9=9K)SGR$a|;q5Zt8V zDPfCT9ajzE7cAgeLtb<6{nNcDN$lUrQfN*EC*qce6h-2yoY@W%{X4BZbEptkU9g2; z33Ah#ERb!oZIE900{|YdAd(eqJ3-=(Xq>qe;=13=hu&u zt#D23r5K3=a~sT9IF4c2FIyfDW9gqs!4FI`Q=u_@od}oGlzgDn3>!BU(!_;1Mg_lb zAHt;`FwQ_WbV=vjm?F%ysDmyCx|W1N5j}(N&LMBH^Kt^;Y0l}a85*hPk7({gDZWlF z!xwCh{Ih6~p($1S%Dt~2njGOtT$!WpHGCCHP_^gjNgV%*B{XVU#+jRYj1D}4*b5z6 zh7j7tC@}TgAU}vhrSa!DT=UPHdN2^(rLjy`+#-;yAnAmql3aBiOgF<<8D#N))hBV) zvilQs)l-CqqJZaUSnYvgEEqse!rH)1+gCun-C*(Lp2Z?&**$_e9-MLDh#A!%FP#|OE)qVtvUcO z$eyoLnO_A^&IYD}2B^)JntAr;j-d4ZfED2&sVU3U<9YvD0w}m3-=Zt|1IQx-1xPRZ zNhL)Cyb2V7q;AmWf3N_9@0UR6zrs6=?1a>tB@Y(6#3AU%P+JUH;h^!CLR64}mi}h2 zF?-*3fRaS>FW~2kErB?KgTGqx!&fEV(XR2*-fzDK(1)iX`)aP)uPjkOl3DY*-L*G* z3!iIm8|?&P;n64i;zu56(p%)^54$|x`GmP8FNq@OHRxZp0hMx(;qNyXeqwnS+4wD- zMWAd+XLKWNmZ#(U28jkHo+NnoHmwOF(ta!#1o~~*=1ZAdt)h8%d^AgEC5J`7GUaBR z)~An#AVzoB!`spoB~KvzLA7jrE8>v4AXyj!>Io=o4=!@n%J`3xhGshCRE@>iuxAY` z)&L)ZpwFEjzxLh`h}D!~|MvZnA}-hjf7>(LAA)lNI00ZJLXM|1RM;_Hgn`FoL`}p+ zi3SX>XT zHYO`mQInopd1O>SJ*AW(Gg~PPnXjAnr+fwgokiSsk!0K~wcuw%(YPZ5$?G>OMLMsd zs$1&~B}a7?n8=!fXd?9^_-%Qg?U<(|gNM=N@zsFiiFvndteCYC&sb)X$FqM0BHzoA8WXL0q3<44Kury=oZj zM54r&p=`$gOa-onW`pGMhv@(sbhh#xR1oI%0 zFQ&WRma!}DY)d0JQz;7}=N zUsgCoeQ;}#xpgpr+`nK02xr_@A9dzUPem2jTq7XO^MJ!wSQUpJQ3|sVMk7JN;r{{g z{7%dcc7hMMYq`|o6#b}KMdX-=&9OmO9DBwIMeo^-iy7F0LYfW6Eggf2xObY0NloHr zzxxtzRpBEDwS@noQeA1SDUkxULRTumK6cpOYIW-^ zAv%nlnMe~l*x|mb$2Lsd$D$(Ary17R+MMt_z`l=`^BxQ9=^=v870&O=p6MsKgoVJF zsk!9<30smY`KbHb^^Knk0fG{6dB>!F^k|T(7qu3v;x6t)n)2I|L1)j6Rvl9I`@;=T z{TrbQ_Ywz|Fa#>!Zu84w=u)tZsdan8Zpo|VhkG<&fv@NsPY|UakngauiIk*U@@qN_ zk=!1;sCD+?p65KVk7GJ#ixLLxg(V@*2l%e+9+2y3I|>BG;oo+!?8?RkStElPwO=+p zT{Usgeazxe!@5>mKH=$3+-p3q1}c0kww#5EqDaXcTu*0x7Co9iF$Cw|D+>SQryLEj zisbeW)3SnCUN-m zCrT{LN=9tVJW%TDYK(Yp=HSZvtMAh%hD&pv^M|X}ZBzYfz8fM%tQ3f+{uL2FFE_s} z2h4WlgPZnZ-*aR?{?u|>K2H)ryMNe5G(| z^7(U~$OfI0RohnvEaZ@zmn*x6Yho8f!;a$Y^vChVwBGZdCr48$2ItAHz3kPATl5V- zdg`7n9klJ5x-0i6Pilbu&*B~v2QytE#;;^Zr?>THpKAwp>;n%3uXA;G8#Zm*`i1ht zB=$*yzuW+iu#l_xT+}+mITUx3cLLlHT9!I&)DIP8M@E_xwAA-5DQ_j{7r=L(DfkOC zyZszq{0S+`6Cc`=q6f5nBYIcdpO^!qme?(P6T|+ySxQFf2DU{{bGZkYIsOPS89V0}s&&-5 zAcH-w(lB#6B&X4iH>Rq>&D>fDW#D!*Ij`;b42yz$y96nm0IhMiwB(gh`Z2DI$g;X; zH|>K~wVb*Ztv}#`&g|Lw^%f>dt;*SqVWF^>RXyWt13rb~WqJG+6n25S+o_HpJ~5;N zOz!lbY3Z#8aFpF^rq~)nI~jN~WRBGgm%c9TbvxlJnZKeae%;r~`C9m_#xrB$u3TK6 z)R_J3z)zE4fX$M1OCDx!T21iFfXb2J+wQj{EuGFN=t9zRhWJM5EP6i4A#Qd0h5 zqxpg-(!z7Tjh+H=FTUi`Gy*^zh%pA0dl9`)E?woaKHfegyOQT&$5*oR$8)c;8j|_3 z=)_55J1ej8OgrDokRt-ZQ71?a)qS7B^+HcUBeY6~Usn(CH#R`kSa+N9=siTbhy{MS z5jjg3`%O0VomWQZ!WWDY1~hz9T+kdGQ(MNzp`WE;i?g2Y;bG#1ETrMJjbpLu09#cq zs&hz;_~siIh0{5K43+rX zwK~AoLiI3rrF_TFwT30F>-H;7ABP^Qgn9OVVWM>FRWPjU<2daxC0f&YHtmsi-1M(I zw96Ttd8>7w7`zJF8`sV<6rO%}{9XgAJT;NrM@C63c2xOMB(-{U`fqv4eK7f(k8M%Z zWNxa{VCP>o(lgCt3U%;uE#C+mv5NBO0iV%HQ%4I&y09&J&*ho6j>?lXZj5Q=F#O|- z<+W=irT-iLaUpEt!1X#BGew%dQ%b$9CCUFhFHG|H8D!#-H_ncyruX#tx+QOEDLHoD znszj9ORm;*ZJUlhIJD!(7Vlhx>n(*A9yS{9B;mBW5p z)c1$C^QSt)mZG~U7fok#IzF5QF&|o{FQSZ{zvjpU7qc!;Y-QvVB~yzsXsAd z*4^NbaK<3VMboAgW691iXv1*)%9JYTH~oQR034-OKUuMM))Bol?z|%Bm|2t6<(oTF$C3@VF74CbtEEv?-D^5+JDQN*C`c`+ z5tFbKGCvcjtfX?NivRS3K!MN5hVCg?-mk)7lc^ozn!V1U}2Bdp_aZFSM4wID7BqC64Q2p-WGad7|aV zIMvJhwcoqwTi7A~-MgVI%Qmg9`&CNXb!u`m=mq^6u_rZBg4S&84A}<3N84KEo>k0L zma+)XHn(v1x95uvWt6avy6#N<);_6s^RkmZ^}{-T=>k6KgEUS)QIjpMOWnsmK)abE zpfOTM?mP-~Nc?)dHi^ICgml)}qGX_`xHzw(62Xef{q!iB z0`{Q(rpMUsuVo2~^#@eu7a+)DW0v-ypwvwEHkBfjnZ~qjfsVKV*3^Ut!CAh*$(ZXP@`Wr zUay8GdbKPbFj`QKFBv!56UG^v# zm9y|@ZW-O)5AXf>W9_&Mt9MsZv)^K6n%Ku^%hhF_OR(0&o7syMcCK5!2luli#u{gt zElcp&Vejw&H(W69H<#!r(b~&ra-U@eWN!vIn<^Lyh6oy~M2Xw>eT#m4)oh!4v*?G3 zqIN=EwI&ni$YEu3@wRsNHLN-Dxt9g+*OFS;Mk(I}O0oD;KRNc`FXwf+Pwz2atO z^L&+4B8NR;7En8nhl27isp7v^i?&QvJ0H_gsn$=-Z@9j|Qii|UbGa}weh+g~lkoPs zFNQ}*>;s+V3ot04q<#JRB!6>9Xt*3wts6N!lq^I?-&vjb6&NpO z?Df?}y-nR&RaI!(x~7~^Ev9P%Z6U_TJc>R40UJa%0xv0a=Bms4@%X@KRz0p==Y9QhfNv;`Df;-$<+j|)evk{jKi;U`8Y8(n2c`DffsUI}Il#O)u>JTZA=NViD%1h{>{-&S|)~ zXyO4CC~IXgT?RwQdN{)y^#s>y?}bJPQU$NODu~Iuatl(M&?v5Ev^zbt%6|b9QAz}R zy;D9MLR@%@%dXw8lCL_&ASElCb8$a;o~_fJC-A4K>F(t{!|YqrD)({6hyEBX)sN2w z9nljFCxrvUZ0tZx(sIp9%M-a;&|38fo(a<2a>uu8IsnsBB##)~X@*P6w~_j_J|2Bv zzRS$MtIn<4B`pg@@foqt_gq0Aq5a2VV#~mS?5^l?(BGyN?ErSH;l&Li#7e!ai}XGz z0z@~U@T@vACqd_n31&zBAVI3dVURl8_qv{{>l_L6M^E}*O65UcCrysse;2cE>BSD{ z#8T$C;RR{g`Ac7`b>rpN%ztWnsw1Qx8ByK+`uI{%YVcdHjm^S=mG#Rfwv=Tlh4*ww za##LZjC*vw*cA@U2eFf2vQw#aTekKx~e^se1exC4o*!4>3ByR772 z`YV(R&(^5Bxgi>$1wsww&tBKfYsql$su|RC9S@uWRWDd=zPX8r+C@4Ii+tC2CrPCw zN1s&^L5&hX6^*GNUy5zM-0`JiOvw$W4sU|oAgq_};omW4lGRfNypGmh>lq+l2PZFx z#aUK}dYZvpo({DH6a5EEE7bevA zjsj5#xq3%(E|+qO#4!sB5u%};uuG84YQmTX>3hg&`l|M5h;{J5;dhIaen0h@CMdsr ze=D>u--7zp0yr$g=9aq$VsQ-3OW4)&T-`1hrpved??zq=qeyFC6y;=-67>5FJQMu6#^~oj&rA0i=02qXQAi+Y4Fs%wZE+GxDqb3O zkxTacr<;IY;Io>T zv1L4Sg-*942{B?$tbyiuAuYeyZ=6y8r&gKw9p(!ZoZjYwS_YO+GmugdiEs?(7yfZx2Bka!O)Jxk0vz$c^L z%HdS#0G5LF#hjyl=70f{B7MiElV<2WvXnV@Yh+a*r0O5Nj~z9GF46Im=C&CpMx3NS z#ZV$;=uVyRtJ3x(1!D=9?d?=V`i@0lIgDtdYd|DmkWVOHzG4g6|vC&JqonF8( z>F}vu1OTX4`gr<+ShLCg%G75~4QAh9@0t8k&iDf?*|EmbDio9?u^X@5n_U*8%uK7$18SyFN{UuHbF#q(L7p-fHPM=)2=0^H6G&n@&|Zn`n|WnLc%X+4!aj zUxd?IjXW3f9%-MHbzKL_`bMlTW8Lbd?E6Ydm^%f`<5sy|HW5bqKZ!H_+(qv%6Z=;!8GMMVQ{(QhqQ7*_s1DW(s%uzJZuG1<~D}(BvIJr z;A&R(9a9QM(@ZX~XT_E|NsyApjLytx3`*L5aYTQwTA1kD=EY0l9u|*<2!r;|)*1LV z1NFne}=DRLK9a>s++)8pg!VSh}%G@)auM5TEsP}m&TK7^JQdugF(OF?$F(+GS(o@ zHYaJfUeP`1yL8`}J)GYAydeMzpTefSy0Wee!}i_<9|Exs_=8SY-OnPoFR06VadJmf zYyQ`l7Y6^4E#>5-Aq*ZPTP-}#09=CjS%KeS5~5Dfi44K9m zWp!od&8ZzXU$KQ;EOC}$2nh)|Iy`^|FGOmB30p5dkX9}55MZZPcOiEZoeB!|_=e~s zK$8m@YaBOo_2FZs8@P_5UCBZqRRJN@7%(-6mXV21<>G8kUsbK0695}?LZ0k z)_g6Sg)X>2iUv$L#AvH=%;VG5V>D>kp=&=S(Q)lAKNU1Q#|m&VW-lDM7~Z#%wgHw{ zLyJWLH?wOfQSG;%T`U)gj%AfWQVIvC5sUwer?T`L8z)<+2`E|$|0Dv6iT-CX6CF#c zg2!Fn6O8uD7c9!`K@aP!PS(AY&`kvlu4*)1^M(H!$EC=qx0JJ<4MlKIupr))lEgsA z5ZYXXqOrM%BIbTLhn|rd|E>ik5#?Zm3LYfZgRMM!5(yiCz-CYIYH5b&9zMmdbp*}& zl`bC{4T0K0a}_&@-4e%NZ-QZ{ef1NqplT@gCq+!|KQ5kRTPAV^(V zf`l!tm%xXXHO$a}Z4ds9&#e55j$E>2!0j2C910@$-LED{{hzb?;2jS^8!bcG2^BHM zUKpnF7ykN~j=`$*XQTS_fVnug%s*t#PluFBSx1+dQFQrl#VL~oiW3d8;#bQ80t@0( z!&f;kLb3VGEVo)!0LX|q@A_F`==|HR!&_4zlX?v*u)^`%)4IOapDWJf1bLP0{PnR2 z#CEotKUkq?zoih_FdH^wIzS&`mfR$umB8w zp;9nRGA(|<0vVM;^o+v^+s40LC*eGu21iP2&ZkeI>t9+OgXCF9m?{@*?43v;PNZw( zU)QsLG!}~xzQq7gEG~Qz-#FM{#$_)ZOsI!zWQ~Wj6GQ5BVCYw_LX6NA@DswYaMIBK zXL1qqR=-F*rccUv_=bvjM<;!ZrQN)NaW6752APML+H~ZG{yEgz>ngkhB9_tt#p3`O zj9F@4@T5ggu8=)8n)?J|4M=XJC6H~f&B2*-3y>C1I>7M&s-r>%P#!2XelE@{Oe+&w z6XXcv`wo5%GrnXt2*el%nJ;e-8b$unDS{mmPq81|T_nTM5cC%qXngR_Xdhh}X)dEa zNa#iHzH~y+8q)smN2}Trt0pRGQNGDNo*`?6s(M*h=*?j?`}M5U{*MsNS@KdkZsK->Iy!!|k+610e^|F)h- zOYvP|u6E{#YXN!XOzoe2^E=IkKNHACJc>T~^hb-@&ex0tVnBJu>PC|pE$Nbg!b+sz zY9s{;4_tr^?YodHi-gbOP3EWMGB|#QA3!cuqBO&@P_F~YcD(EvRVcNkKvlT~5!QcW z7DVO`fG3kSG_4_sodjAG&AB#hmSosg>=0p*&g(OPR16LwE6(Fw!x5C2 z68)3j^v>0awG|~W=+*7W3Re27K7|4jHU^POthaio{Ae0#poC>KtxNnwhB*0CE{Y39 zT&cw0FmG5JFE2g{P=NR3*PCk0yCw}mWZYO+#$7wVfQL!3r1H`vM0vo`y(qrtr6+F? zXf`Z(S+ZdR8h8VB zc5CIR$_E%1bsxXn@>%ATMo!iN8bsRG$s94eTsE9XQa{~u#20MX4m!~sI zor+;|cP}X)rl=BT%k}zn^)Af1dAy`i7O}GrgaSU(6?xJIGPS5!9Nfb;zwV0SLHuDXI$HX`73i&DN$gW68&HB(}THw#awtd3$Snwf8@=)>u<;GCAPtQ)_7&!`k?umur9b_ z^{?A_p!faB%qA2uS%gQMfj~RMH}t)X8_bupK+i_~67#mPZirZt z|K@R&cw&|I*jurTjys9YpIUPnVDycwfS@5HbKcG@5l-y*;a=Hq(``*4ap2H!zTLlRfu5I?Fe!5>Br!^yv;v7E?|ai@ zBm98ge2!NccAH<8ny8Jb-@N@_T2{FYWrt3VkGCfh<@?RgcqlGgJ>zM;ubyzHGt-xDvOPL0fQU_bh3 z$e|R7QQ~6WZ9G4FHKFD}sm|MB@KozxQSJhhFAtOQp;ib^qQ+ftXTp1wqhhH!qrec` z=wl>$r8d!VkZ;<^~?b3vW4Wg6+$sbNF#>$miY}C2MOm z45q)^&9GwDpq;^!<}CAtOpe~T^!(u!Y?O1hvh!EM=t6vJW?ceBGURV~civ?1jAc0F za!i+2RgDmt(D-ccMxVUzI zz$03~2y~>~Ise;HQ~zh=(8)Fh@A_X8Z~%f)zN&vsx*YjMx(+#U&&4b*N5OFX zC9r%Ud%!o457Uy=@dc`XNnO4tlm6DmgMe7ldW=K8djZuYvc`}wZO+naH&S-%3lt#@ z|NODkVzO#hvjBb(=8ezFwyi~ELYW8mZskkp?Jq}WNmBZBr;g3!yy(FvUZ5Ga@-^&s zVcsJy6iud;WB-P&ySsoN)Y9stxt1WkYIM!RLZNowAzX($d>vfJWgZB{gwW0-;%6>qH8t|@642x?k$VyZT(2Jp@2-n@%Od*P3 zkvI(a;MheUs_tJL@b4ooEc3>aby5a~fz*uCwKBU9>935AQ^&IUL~N;0El%b?B%7#Y zwSX^bq`1~^Mnj#ZR18*pY%;~uFH#GpDPn07rIo1^=had;db|k1$t~t{wBZcRlcovB z%0wI*LZlTa0e2e^4FneeiwN1eg^Ptk+yCaKkdc=lwRB`|-{<=@AEzJ;Q&W*S;<*RT zAP++tf?;)Tyl_Etj8Cl!Pi%i}`89$swx~LwT9dc>Le~9mN72URU)6S%b@=Zo$HZrQ zQokV50kArVbvo%_8|CYlgg_6DVQ9$TigR)*KbzlEnzxgaFw5GmDsUv0)_i~#*%E@z z%y6xP_Mq_8q<1VwtGEie?T%K#tIW5@wu3+;W8-=yzF#}EL>fbNkU^H`lgWkz zk)WJM>kZQ$-qa6Opj7av^52?}iy*=enDMa{g^Z*X(g8Ed4vZW=@U4_HP&j9Ny#YGZ z>dOu3nSh(wlJtoNaVg=OslDCUPMq4i(LZvyEc{U6ln}JbD7gB(-CzH2O*FRyAC7cs zd`9glsH-IUtA#nmyLkvOk%oUZd*5A`f;cOBj9<%uU;CJL;&x*Q?J-0$VR!ae`_eJ7 z+pT}=j)t2vrf#BADy-H(6;@mRW#n+g5S?y!C9nf@-)w9Z2SL<%bBIvh*yL*;w0RU> zarO32WQu*#T5=MpMMP2}9cJ-PZwYqZqwR|$?k3Q~CLq+n zAIncGG|Y?lg=(P)Gd-|nH?F}$2k`rNzbPv*LtQasz1Fh&KIiV{Z{E~*3G&o!nB51e z6|!)9CJ*WmNarveULZ4TpwwMU8YG+#`Q?P3o+l3}R9l*atIi&BSu6vgKjp4<+u8Io zHN<@2^+BK5L)vi!ny4+pW|*(vvc#dts`t|=Lv#83w}YVQr-k6{ipE%khqL$F)kQBDD+L)j=ug3T$v$P#W%v0Kk@ljFi|FIsh% zWmjoC>-CU#CvZ{b_;xf$3OpY~7T5rlF}0H~u=OLLR9mr1Z#u|3Qtj4I6vn3N?9h~o!qATL9)qI~)J!QbII{x)T86=)PO z1j#IT)XArN`dm4%>ZPAM5&vKBToM04AO&^a6cNcoE+Hl01w3h8c~)_G*cy^Kq7QEu zE$F)5I|@V{;UN9t&*dw&KxXRPKxRn~1=qSY`|x4Ri&RoUlI7CZ>PSop#l3X-Ir{T3 z@aZw|5r4iNUrz=*uEjl7+lhj+Tz{FW{tSoe1li6_{j4;$0s$LpbP>k|8sAZQij6As zf!Uk}uN+iZj!JoVf*CC0D^A`_^H~X#$57IjEtOr!NLi1L`xg}sVVa*Xu~bq8!(z-O z`hvrLc_{H}3S%$?!S7PHwI4(U#3T=@y*-T@_i}<7>G;{qT{u}n=p5MrWoN90lyh!T zz8eNVl6RxI0mwu8rxwALV@aNWn@pQZLWuNXRXda*1}m~u3tL=w2Zln3LHl-rehY;& zG8)Bnr%k?YR!4kRB$HB(?;bDvK7ZRaSOO@P>%G6&In{x4AZf0B+stP-61{}C>)UX~ zK!>Ar2Nb~s%!{L8*LzO~+Ua2o2y{h!BmOBwd>?8&4YwnF#lxbu7kFuQt9gZuc%f`u zMa*io;)WZTM2lP3qV!O-4BUv3f#jUMwZt6oPRY1Rc{;lxrTP;)zU8Q~{f`JlX(x{i z5(gT6g3Yd*lGQfzm1OD^UI)5}PFODsC}aTGMqDw+E$-g5LJ$(s*YQgkB$jDoJ>kSb z^Klfyv-}NPckD&08fdbC4V+{exzj5y15pT%Vbd>}rNBoLL=Oz&z0|U{GfBh4f}v+A zU?vEi<}ESaz*Kf$`wVrG@1YL8(dmjBKkMe*S8^0K(6I_?rZ8D4RD{SwkLf^8BLP3@XnzzpT@xb4-1aS)BZ z{kH|WF`d@@;8L>bbdm!v0|%%TOIgj=-JUu@d98B%UwGXL%dXmPOPXU>P!eL^JhXe2 z6JGnv@7G7OV&QOO- zk5^+j8E@w44%&g}SX|ZMtdtVjzK#S!8_sxdD-<}}5>Rb^)y9|Rtl`pD2n%8Bb)~}J z)J{(i5+2UKS%n5Mbxt_W2tneN0_7wi#H$SFIOi&<97{kg!fZADc0m1#pIdh#x0$Vl z%+P$WhH?CW3$i0oO#UbRp*U!^kItzgr|4KWfoND(`Eei+sIv@=>9Wm{ms+|YW9H7| z<)%%>TVA4vj-Jc>Ac!WRC^9zK`&>$7)geqI;p=63hs3N(3_z=4bw*lzSle5kIk7>3 zzVEE*(E)Y;oB;1|S#bTX_op}#C|}G^gcBrMU}Fq4jBro;tSuWzkl^ueA7qBDky{`p z*YF;clOsr7LU+4}QHOwpurOx{YdBMwz5T^S3j&^yY8uJ`8(H}?-E{O}xL5w9;Q!apt49#NK>C1o+NdkbFwO{Ku ze;+b%7o`rGM|(C@H1%3jp!|t%F}WZ(h5x{3Szk7eg=PNumSEXiajViw3U#_D-zjD9 zuDq%pMC~3!u4l(7ekVG?wT_Oh#`d9r6jq+t22@=A>Aj)m90sIp{?@;5W0MN;V@^xb zf*=cc#S%Zt+dAB-iI3S28dS8`Gop*xB|^|(6RS5=1Av%}4)~vsz#a$J|JCuNsbbdA z+0K6Rtptb)fI}OEj-KQh@nBMozucYIZx{y9z*5& zj?SB_Wy{8rKGYDvf34vh2(dSEC{Y`E^=+jx2`6 z*n!{w`%bK&5iU|~Q&JeRJ(=7S4!!pJ)WA@EU$VmyMIRpnir9fe_q=J(KhvYs(Qg68 z>^xwJ`9Lc9t8xG(Nh7mkVS@!3QQ%XKfK$Vjw@9fBMy%N=*;F~!(<7fdza_={%MFvq9A&rT>A%0kx#!2VsKLM%L(Kv!6w(qQo8=*yytrU3So zel%DECMXz6MN4ZJ;ptt?5d@+LzLAHWRwp56Lx+Sf0LY9s>uSS{10uOWf~Roc97o|@ z!=1zny6Iyjrw}O`-*@fg=6%TD9EndHkt%94{eM)wcOaGR|2Tegl1lM-9$8t@P-ZB5 zG*FpQ_DUpK$=;__JVq3uvPwu+va(OvyPWKq8M62Oy{@C@{rUd>I(3};y07bXz4pw4 zsN3XPF9rUBm^PR`Byy60@F=+W;SRsP*HqC@X2!UGyceF-kI^MFF$Ke50eKw}69BIx zv900w~v-S3?&KZ~#s?AzRpt=J1eR%p zlJsWpQ}R!enec)g^(4KwF3TERxV`-&Gt0}bH(4n$qb4_D7`2SZI1*w4vcT#f>4sYW z<-su_R_u23(v9t>J{^tyPT=Q^7RO-%C`a1$W!_z=8G1H-tpc(}EP9x+hT>iBIkVyd zOr?3GhY52fBQegi`m{o|M?(&>);ON}+><%W%Y1I>!Gh1eAvKUy&SU^_j>r=e>eRY_!ouM;tdlnNCAd?C4| z&&IyP;z%;N7OqeN=Lvzd(MzAzrhdZ$ym`RCZBMpSGI)XATz!x2&~A`%z_M+EHWjsc zkcFCrJ2@nj{0_rA3z!r@Jm!8S-FY1NQ4C<}?K4D7A*5_MK%q@!6!=>GK=C1zB=83- z!zl2wZv9OQmKa_UVUko|n=NFWiD87y=(v&9Y=oFtY?1{l4C&3uc|JyjosxD9u6_S> zR@jQq5hrKM$=?uVCA=s8){nVOHV_Gs!)Vxn0BHwAYs)J%7!4`CO5wMS0ut|-Ae(5p zf$?vfQFk1683M(cu*1i|hX-aL%s_%2ZD&d1|KVm-Q2qG~QJGw)Hx&415K+zCi>>0& zo%e&U6b&aOCEs%uqTo*eWaIw9PEO7~c7G7aiU{Xqt=@me;la%6_~gt}9R)twaWKA) zcH7-IB*y}OL&8Qrta=EoIs;MI^gJ=_<7Z?CBLtmi!lLp(4~g{b2>$%y9SwmTT6J&2 zAsNsi%kpz4)xo3QDqS~cCOuReFIdlGIxs^iRV6QrME;8nNk}D|gHVq5A?Q7ic4Mq> z^zWT%xS7DQw{id8>wQXfoBRG0gheaPEArm%Jb!ZM>EA=~j4Lh$MsC_6Vvz)R<=tt0 z4^U_jPOhF!&>+(hp-~L&Wjw$4F=Q!$uhxf@9u-AtwY2GRPQOs);x%M1bM=wws5fPS zj)HD@Gr#o})fJ31CpOu+V);m94WuMhg;bm}{C7;lL3XDU;`=22h#W`td|2SE^w_aZ zXzhe(X1jX>S`C<-fkY(NAAlTqsKS8!q58R368??(SI_P=#g!Gjd&CKOOF=%eU^UWT zEaKXW5qwCmPEL`%L{5ea(p47j^;Pa%9Um3=ieS>D4sy#t7I53kcQ9ejua6^+CY}*8`KCk* zhsXuTCY2vEU~-74-ZS%~webwlcOU23~H=fY4Vi}9YFyqxFF)nj&R#aN}7 zbd%F}q#q0Vqf%wnqgdm8}-F>d6R9J>`F> z9==iZn{GvG%m5qxhQN%WEkBD?=jSDhVgNrAO%ZZ%BEN!sXV<^07Jp@x9;KJ+U00Bi zE!4VbZ~LUcsH?kS=^s$eA%R=ZkOedOg5>U}BM_M_1fD|Tp^!QcQ#47Lc5|iaF{*FkVG=Nc%Ef1n~rx%Sh8zHkrF*5vyi9!s#6lnn$I zE%4ak3)fJ7f=|6q+DWG5M9Sv2PZm@Mh*QIitqa0gn8|W`SYrfm6mldcAtrM6`96Fn zAix>pDXphl-DOCg_E$*?%;9e~23kmdrUTiiFy-8#{(iwULz9FLNjJU}i!`BBsT zc-`HC05h@3T=i(krQ<&JA^x(yeBAC~U$us~|egJ3&=MyflVJ1gOk1kC(RTNSk z$8M{ya96u61uZ=M3aG1E3c+5w>w>H=AT|RbmJ^RSkyCd^)?;Oc*cP!Iyy5*WKNqG$ z1qdYaxH!JUJ6?LIiN=S;s<11wQq|!!ewhY*PH-4`Zg+k|?_0MIp|~<2?q_t^@N9Ws z_i`!!DdxsIB4G}0C!iH`?{33j9Q$U$#PXf&h|QVYOZ>`2cuVBP(K8r=sn2QaPC}h z5X=gcV(nZqF=H5p^oBcmoZG(>bGaIZVn>^e)}tr%_N}=xDwrv>;Xax`jigPO2K2;5 z4_iY_AVHZG)PCrAZb_fD(xjwaLtIv^Fc)yr_)EmJZ{=KL`J&s>^MB@rem5VP{R=CENpU$Am%aglUur+_JMz&{Oh)v$H%W})PTNBarf?!Mt4ol>KB@(+9tq#!;qTN}NzU#BgUXnW4ikmlJ z_nuU=W)iLayR+*`+~jQ~J`Mqza(^{SOFkE$WHziJSu1HTrv5iN0sYbw2FP%ao8u1d z?6Q3~eNRpXdQlW^{W$*R@&1TwiLYe(d%f3-acI!Za^Lte6=8GQ*RgUhUgIyo$xnCK zK7eU6GAa?=K9SQ(KL1HiiR-v*oMIXy!=?RcKU&7N>b1E(aj0oCSjM{d=eds54~kJGzAiJDrQv0!)+6H!KH=j5`(S93M)Kzs2{N3Z zVp|*0O&t691Fp`b6QopQgaoEuTz#`5+1EdWopXBT2X6jTQQSkhqK&&`r8J>semC`Y zyf#DId_hCj8hyS8;}w4Zo(1P3%Bq`W>S<6$?m(XfiO>Mo8YO5_x@M@zyIORmx+3H0 zzoDtn_PXd<+vCDLIQ2#MZ^!RrI(GqN9~(eQH(qptTm#W|S|4i#$1Wq!3$a#&<}q61 z(jE?t5S+^x7+t6RcecCYw)>5d8vUDG=`U7|FpfN_7d*FS`rAfh3B`XE}okAef? z>=mBJKZ|=FZCcN4?pypteK504O1VE_iWTs%r$5nY=nBu^_u~h!`+!QIakkI`)Xkk7 z)AnM+sSXiU#!kUy4|{$bu^b+<*SFw_f^r70IQ}vZ@dIuXMvA{}l9q;D-?3rCCyB?Y zv504K;A=^kit*2Na>6*+^GoO+P3Dvk9u=pxwFJHvFn;W8LJv2z!ef;@b41Vs_O7-K zGXjPlQefgRZ1(qbDufo95d6v8!&xoq; z{X@k3rr)$_YU-4CX})3d4sBg6L;!{$PTa|>?FV>mh( zr&{U<_dRnwG-TRI&&Rpx2YEzedtoFSj*wc&aSK~9G*n!^~0aj_tM?^`=Q6g z&8RAF@K@B|{H7*wT2+`;fyx)QtKRbI)X6R|bY zS0uu=HnUMr{AcNnm}2!^=$dwc1Fl5AAT50OkY>ku|#uk?;#SF#oTT*}-127kfM3d&v z#;Fz0v-#0#kL_&t3&WcAuHmJb-G{iWIMkqfU_QHj__!2BU_7u{wxpSKs;i-K=VjA1 zodlj#b{oqi*C))JlmEnk!;{!ky@`vgX<`yJT>{a2`{)S3ll+_@w45W;x@lF@c$aUm zzJ0N}kea@^E^KD@!;IiCv;a-l&*c9>KI-PPRy|t3969uC=4@rgq%+MA=)M+>P_Xc7 zt3O)+@Z%;sfu&iqJ>Yi{H0~cSaiM)lTOGQgH~o5A<0IWf@S<0n?w)yJwnSSEexom& zQv$NympAJDw4=8iyPATyo2E;ZsIiX&h#tSYeZTOmPh$H=)R8Ef5X36S%`3NJ+~th& zTr}<_xxJ_VXzjd0T=DQw1YQ~zs2xZB=uZ5vt&uA{UhMtM8jS|zNgVudaD=b_AW5B< z$CfohK}Ate5ZgDkQ5*I8wUyIjsbIxZ9fkidvymSBJY|aG%?7G#7ATv<_PZ5MB?fB8 z2s32Hzuz)H$nL)1%aJDw9j|fp7L%FWMBLB03B2mL;_CzcJtO(RcaH=d_q*cf#*rML;6XX@R2llx{A%H*R;*_hM8EK!o(R z3%xCGV+NyR={9y`k%O-J4AcIlaSn>B4>sE@``2mpt2oF7a&rFx#wM+Z_mnDeJ#L08 zTNaCs+cN(?rV*~s0~VkT2Lj&Zi9-T9r==Gw$CH^HRrJ9E#bG_ zYKAxi1I#E@L#6qdt*o>*-t*wP<(6kl%MB*)ys{qKhUV>0?`tUpJ6FcZsWGaHXoFWk zTjH)Vd)FYf9n&Yu^5nv$1L>u9?|dlcv-Fe_s7c~F4yRmul}}o`)H7H|AGoIyQdus; zO=qk`PBk?94Vu}2*rqs&ZpGB2`jAKf(Xx3)WzFvG!pvK zb1My9OK-;Oq7FJ`$z#FOVF+tJmPPMujg+h3doh^y1Kj~oG#()}40nK>QObZhF@vC| znqg-|FPsk_FB0GHD}&S-B+>5~J;Y)qKNiOt6}#uOB^}$S4`HXb@NsjRF1lj>iZAjo z`1U~-5I8%e1)l^Cno-eLiJW_GF3OhJJ=-L_S?$$TsG~D-p=eSEgy7ucdl*w+^H9D;u zNUr*MwwuN^bNvBTybdUOQtR_)rQ`6PpIsksjckq^NiMuW^4=6e9|-6AK;FlTouu;a zp8Hu_Lz5t)V;1&|psQqYpr(GfZ71IwIIugmkl1&*`6O2nhb+Gl?9E5Q!aJ63tixO$ zi?RUZ5NrnIFgc|<#!FEb@x`n`WlR~A#Cb90FF*dL{FE$k-Fd4dAUO8QZ`>`nBmu6Y zwlYkdty0ypZSDITble;&mm2@A? zn2hn7+6f0gAe+Bt_wLN2Y8%!_eC4&2q_MVfZynVOBTtH=)v8`y!m~*FNSE(=E z7&jntlqOm=GtY&ytqrIwCwoL%nI)t}C$z++sz)%+HiK)s!|^?h8zcssP0>C1=L8vj zYnQwGQ!g2{=Cd5^uv6}hdh;d0pwES~*-4B%xguX7WkV7z8Uo6(7D$t!?F<&ylhK0%L+c4@7vl4t%bTViu}-)*;*NONhTsSFrNken5b zG&VPf9xYq|^byR-zTZ9o3dFyjo1wPLRFmmeOShq7R^DgXKz+NCG%*ocPR zyD{Uow!{C-_uNwBH|kyf;oCVau+x!K7R25E12=X?~miIel`Z&%>Xj1jvmI@GSIL2e@LeiLM{u_cWS0R_kz85Eno+NclHT9@iH-X>a(N-6+#d#GVi|DY=qa9-ik zx;r6vCa85a7sTochy&M{+CPRD@bywp6`!H$X)npX0Gv!FgWIJy|~L0n@<(6C{{F_eE|&huq`HQhS^fH~NN6i9b? zo1U&{J@p>ukr$|v2^dXJd}UO|yFp`U1Md(q+aeQe7Up&qeso$hOjf~j1}lzp_Bodq zG+G^6zpH3}?p%5z7HgW_Y;d;pV2sKv=@epl`csFE>x63X2+0>Q%L z(c;B>qaK3^QEzlG{Q^T$K85`R>1eorz% zfr((cfch>=J1RnbuR(I4W8unJf(NU;Pco>nZg(2@U=+xBy>RXeUwX@_rtyE7hb_OU zz4;ub#q3K?SZG%wN&E$}hD31q$$Bj3V*=7#9UhVV-32_+MTb8Dm%|55TBKpCsd5&FHF&HxB}X-A6SG#aJQ_XX@Mi4-c7P^mSMH1{d7i zpJb+|QWA`t$RO3>NE6xUc}Y!NK$v(W1zrmIV`B4MdiErU#pE@aEew8XyocX`X?ZN> zmQo*_{wA10BS#SD45fvhM=-ipMaS2>?~ywnNSM^A+Wph0HqJKP;@O7-|-Y<}ZkyQ^tV(N%jg zhd53ptS-@Ff(}3gp?=`#TTo}^u8N=GaHdtJHtQGNEXI!*{o^GQvO0g()W%R6t20TA zh}{6X=*MA71#z;09o@`umw@dw`h7V`P~ z_mGFK78oYHBD<5)zMTL8$cvHvxpK*jL)VzgPATWEo?sQ(8Vm5f&un zmP;eu2XkGLSr;7q6j_*#lQU8k24mvI2WUvK`zor`T*o4+fP3A6jEk*MNaGQ(%V}vp2NiNM<_f4x2YR6fk3Jk{nKvXLeQtwISDemwV-ouxV(Y4%RL%`^^YT` z=pu8S*eOhwmG$Ed13jrP@vG(0trm;2(p#qB+AEs;N)UYxBd`M><;PZxK4xJ zP9Ulh8RGZxdDuW<8WKNAV5q-%C82)M&l%F3?(zkvZOpeyP~uHNM?he|Vl_EIMsNgP z?|CRd9U8zR$))@+z)#ts{O%(vd8S3K!uAP_u-JaCf4%ApPS6;{YyC`N1i7FWINlE6 zz+8#qPb9Q~vHT}Tw?w6*l0=cC z?LEm|f?yYLP0{ugXu(C#OF(XKmL^54T^wCTeBOfq6f)y z`3-ce2}U+Sz-o4KHy>7?t+>;sR@Uz*NimSi_JlSDI6I@&q{3Gm;Rph~{{JIsuvv+2 zNm}5Tqi+akB9L3uL;G&>eyq5qwIJ|4-RB6}X-a%P+GD=$RqY_tHyjFyTv`Iut32T`M~t|w0;pr;6XdIveZ?5rm6-&k4)DGM_*o0FfP6#&lw!m zoz1vep{AeQEy%$)a2RlQ;4CQm;a~+mew~6z`82jnDT>gPtWx6r*@vpBx%fS3yO)uH=t?r%M_3^d6PT`1g4=uWF-Zmd`h0jFp-d+|@%ugFQiU|eOmb}JqlOYI*mf#h zH^>HDx^yKXeL2mVe8~n9(d!a{>DRmkre7|KdBf-kvAP!5>ywAERTpp#fwKQrSM&xH zb>ECiIwwb~b=PuO5^8LK?q~mg@gewRrJLjIUV`24>12+c=~6w6pky=ku0LUU6Wgq7 zb(4tmeY?E*b>q(yZ&k(~WZj}WxnQ~%9~b4ACtk<$6i3hp$8Te~e}-x*wprmCo+K)F zZ89ABwczh58qp`86r<8-W*c36eB)Qxf|#5%P!)6C3%Kt3 z)V-X_B7i6!=*sv3htVQLk~Xv=<4`NwIK`M>lu3`hqqY}q2gx=O?062U3?hIErTp}@ z>0ng*X9;ae{HIjWmX5q3XJ)8_83rpoW)LK1e?9csw~T0-ir?25F`bLe3ZP^4ThCld zOHajB-m#!=$Li8Ff@``?9UL2x#OUm7q_>Q=J=wBOzoS;y1GnZMo?C&G8G;?MbY}o& z>B=D6Albitl>*;#H?PGtk1s(TGnuxwPUWU&t4IBg3>qS4+#9cIn8kd zqt`8YcEMh^d!H~~=*-B2UBS5d2!Ob$T=Mg=2)Hu+5$NTZ0G-ZQ6}FHQ<~tzTmu(Tm zB&Q1=?FA|BuU&=Tr(k#sLO|h{)A#6x?HTQzGN`e77+v~nS<~Y4)f;fhog|!E-0((M z9$}aqlO!WYtM?Mdd#xUUt6nVvu6sB^h1Kfj(6u%E@aY%3{y>cZu;n@i~P-%V{rQ!%enP*DJ|At`9b)=!Iv5q_4Bh!JQPnPSu zO!p_$OChNHm|HW+BWxoGb^XV5| zH1QWDVLr<7p?KT=y_oA;4Hbs@!mS)5Xsvy4y=j$Owd5uw{K+DGr~sQz9cHr)ifB^e z&B3uV^bP3!fd`~70*x$vjm%VtCgTnJ$8eBaJqc2&F2O@`pR&eB>5%^zI4-?D%A=9r z>?AtTLy?R7P_^q)M8+qqe&8nKcX9C6XK4t(V#Sc(`FR4MNY#+w+o3i#!q@JOpwGYM zfkV|mX~8bPeYk{C%}n%A=o~Q6+}DXiP972c@iscTFYmA8EA#SVtD?PR@*(lC4~7Sd z*(w@%x7V_npwTB&fYP?o-$e=;@b^I!$MQng5u>Vnv@ZbkyL-}D zcqn?PRq8s)B6sYXfYLH8D@(J^$V>urZ1EBC#q1~2Z?cCwR`tkyl@~jmPLduAwY-!I2*{@Qoc1FDS$lAN@(IqMC;K zDEDYKC1DeWv;q&ZHOzj=Q)boaEJl?SoAxqWb%DOckW+@j`j5 zQ^4dhah(#scJI}G-ZRo6<%=>yLw<|iP`tknF$ev;+-Lvg0u*!`K}y-g#K^se`FAa3 z6tM+}eULbHBJ@I_=gH04UIR`&Ap~>rsx?;o$vNZ0>VZ*k8}u8qtR{tlH?k_ai}+(RYDxn z07$2=$UiJXUt6l#M!?G!tLg7r_fhmsXFLQAHW+}n*-H-27hRjjhOsCEPH-xu^3!6&)9(`ZZW@j8 zmLSGRffXZ~FRp@?^_I!O?~mwiHncv@Tf*GBd)0@50lH*2-a5PH(&qO6!G)N^v z_#Ddc;AE`(=3LWH;sdI7Y<4d)P7VPCoVf-?99$n<e=9h^|tnsJtQpx zIox#h8I16{MTLS7-u;&KnE^-i2e>nnt`njK%Y6m4Hxy!o&%%RKF?5ft*gjBTa%_1g zCNm@Sum+7$aeWD2Z}$+B`Gc5p47{+R4%**U)6m9I_e}EyzP37g8L#`&kz2g&%^r-y z1^hmt-=>nCm@uN~FGWDFHwVG=E%{PSGYDlK*!>5=m-mVm4;3;nY^VeSl@ zBl(^v7@Ze9vYs7TM{ z^&H%!s9DVbj8(TGp(1!>{vkledulq_q$iK+Ag1ZyWZP0B1kSPzeA);kcMo5N*9Y|M ziOXTJ<@E(M1e`oJ(!u@fAev$JrQi-A-jFkBq(8)|@%c<4L8^v(AlYM_&*s_1m7C2C)qJq~3Pf6hxm>>*^V1vAOW3=xK>~NkV8@RD|%W=DAv#3mI zY(0*;MO+qB7Xvbj68#TJ1Fd7>J}mYS>LIGmoi1R^r4NlJ(ZddJSBD*D%OyLT($+h{!h>$sY`fB&rO@FxObW zHw!=AMmE{7(N_rLghd-hi3z^kcm|R&h&U^h<&ZpAkY1q&g*c$YhnUG6TtBtX;wyLy z&ce%d_CPWy_-#BT?ya7o5u#kdnt>=m|GD+)^bL>?9O+cA{b+l4qZ*sgtzRWIUI%VU z1_J#PJ(PbIIYz?OOJfaF*>4Z77cP-)z9uFAh|pUh?F(B?K5V6cx0p1N4CAc>O>8Lt z$hapPrn3(a{i8oP6C$?25jgMsR+5DvaN~pJW^0^uuM89t#9q<W2E($Ih#u-XhnF(okk`%^t9YNVYz)jC@vY#fAU! z7|C}P+0?Icmkj@S@juVY$2|}i){cGgO0VIoYq%{=0wY_6u~v@w8 z_Bx6`K4ymoE2S^=^envBn6oAZ*$F$aZ#t?Z|?X3Q|!g||N7)>WAxul@y0;!Nk$&?+tQo@*s_T7Q2w}e|;AK$@rm=P3%fK~ww zKc{R+F1e->|2d2K`*(B%{aPmaUl%w=hSex72!c1tum-;O2ZHRI*yfLk^O3kbHV#wa zkdxQ^+%Lu7B}$aXZ1YQ+Yy?_q;~TVmg3=JlYQuzWBrEAo5^Y(GB!H#Sw6*Pc=-z5IKNMe~s&{u*Bg|ob zIu}gL=SWrf#7N2vIwaa3o9d8cD5Gu!R@y$2l?Dk-By|rOvcU*x^>Z{A8RFxtzNw83 zo=CyuED@XP1flw$rto`734;Eq4o+Ad%$`CvgqQ$5l)G7gUuyweQ4Con32bs}j$PzN zWeclAyx{y}h$D+P14bX8W(($c@DGZ{H?^|j%H(yob0ex$z2MSJ7wKTijv2V6dQ`1C zk=|5yOX})a)Mhq+vaZC=IX()KN{H2E5LKrJ?J`YY>`=<%TRDUY>q zcyG8`n}+Xs*%&(uJ`1Rw0CJy&(r_eTPNvWIoh~k*Kd`4Rd1GifM-Hm01M6I+;v4pE z`F9(M?{u>JA;c(H-im1^$Nr)PWFa&I=UhIgDfm`7e;oA23-s|pCz=T>!SifyaoESG zplY1|9SaDjv4*s)E%hZi9K;6L(I(?w@8R0!{{G-=t9(WIw`Ml(d`eMB`qTNVYKUyp zN!B=`X$G=wdJ2ilo0OP0ia@NEeA>gs=2uuwCUw@W!1a~50gSNSUY-Rn;3lzk?f%Tq znVFVsS*wDMgS#g9tW=muMeXyxLYcxJeL!Q~aRj=|d!cf)aD#1nrg;qua+A9q}Z=lj_ zbdp2AIP^@a;`aaGv5HLeVaL%PngT$t69vOrW6> zs48)NL#aB|ymgL~IYJU#LQEqNs^PKrkx#jrO^VNQMi6&C-8>)r{H{Ld_c3a9JXqN>IOda*ayi;5u~| z*=RtfaqK*4~h5;rP^Xs{+i zLEKK%j8}<5lQduN17Dd!C`03jVS_u=fJL64iOUP{gep8y(=4@z3-U7iarjM0k~r9Q zrCv!5YHJ}^aseO0{=1%R-q}aHM}FkItn@~9#F#7=iaY}xKJpY?Ct@ZrZiN*IC){{+ z3Mg&5L5e9ydYo^0D=d?RU+aqzXZIW5Tp6Nl_5sBVh(pePo?0PCIObod?cIN}%S4j=?>h}7M~W$TeWB|}N*HZ){R1`X#u z&@-D|(X-_NtReHfkGn-8++%gG$Jpj!7_^0m-}4nblq5Ks6O(e1z!}BzuGu{Z9AHET z2Udu6Fo#eQOvPSah!kV!hW7rX*FfeE2OYN{9;{o2a0{2eZBRv z&G|NL@$x+`W#?+n{Q}>i$VpGsHV_?dXL`nnA;^^!KxQYrg{-J7{TN}t-(bI*N?nb4 zEaUyHmBHkhQ>U0{y+|_N;<;aLLmAZxi<|wn?-q0+tp$0lcq3}hH?qGjqd~~|i!5SlZKn<4Wif~~ zik}8jI30fQ>qt~*_89D}tkGZ};P5*7x*dcs*$B`Jn%Jtm+IvR)>hTGlr9l@I7MuP_PJmn1QGZ&+gexm~|?INAc|2A;8I@f(OC~ z>>J3@44s6ps;Iy?JbP&Q@6JhpV_>pxAm9RC=Bq0bC>7@@(FqFkyFi0_1s;-ro}l%O zcV7e2tA+6sBmwFOVR%jh!*_GFI%E@wc!;#Xn9et~mzNtZJHs=s zD0&ULZUkJlC|q>|j0^7tOP_fDKx;pw`@-Lp9{^8)kM7pTkzLTi(POoYWZc1yPW?^V zm?gL%--|+m=xPb1B6=vY!p}_tNN+Xif^*`fIm`nIOoN4(2Jm<-qP+m?7c@ zK{99u0)fo*lV~l`KWmXvvg`I~k%~k;FZG$Rj5#>`IU| zoi|+ot)soWPJV~9KWV>$tY4Sm`&pE%3?F(Br-h^jIFOZ#Y&s|}(2@`FLAWj<0Cm)h zp*&{zlE6bENrDxO1qD|L1Ym8`A>SC?UNQ1$!bcU#3c|8qjQ@>xD1anAY9dzhPgWjy z*9q1TjwAsE4vDf|-~*-Zpv;xwgwCsz2w?|w|DcjHO>y{MY@TF=!VdudcF)}mJ;?wd zI4m@iZ>S3)U%~DZ1rVkM=fu!29R$|@P*NNsHI!KV``j9op$w-e+eP=W8b_FsdB8b5 z1;K8UiiAU}qD33DJZAwE0l6B1ck%!qp!EaFfP{}^jio`TVq=G&q&{4SZ)TBLgAYkX z-2;`-{SJ523;w&xx4YDf-JmDvko9ej5Y`UtCq3hOHLWq@BurDoMyb0M&hvtM9%SetH!tOBe>08syf&8?DSO4G~@(M`9eqiYSfPpinOp z?wSNrlAjj1U(cU12rQy}+FK7oxEQIV2iUGHL{zc*QAl}*FG)^z@IlB)s|>l+56rps5VTduDgvZ~ib4bye^IvysEA zj-N!U5ayxvAc<1A^C8G|gJBOmq+|O>q$Th^2B`tjzE-HI!0?H?kKEVS59#Q-Mv3A5 zbND|XRtA3}Q6S;IB#KYslVAA(fj|w%-~Jmuzk8*XUt4yc7_jQIX`eoyVaaXimg@L! zpCiYYa1PDtcbx}_Hohs<%ymrf>>0R?BqX%k=!-lla?Ra6UiY5R@2M5_x$=a)JKt+V z?AY+L=T`p8`=#=Ax}!IG!-d^9M1*NFVVIaK?B?U!-Q83#+d|4L zyfpUKE#a61SS21ifap0Kb+XMJ0YdpZ-C05n9w9u}B&~mNLy>I|Ds{oXLOKWlIC=NF z^fTo}`s?9nXP0S+1qWc2h$txN2CZTy2kaJX>@@sa9W7!~3w25GX~6^EXvOaSDBUJt zKZaj83|}21?SVIQt9%zENtOT-UHHStN2Go0s3PP&4%e)EC$Gf~(RD=7?keN&rjGKh zMdyRvdmpK;f<+k#ocm3M@;H_*RU=LEq~nwsnB zN=tRC`RS_j)Ej=|J)mM>O1rQgakzgPH$R@^vom9R(lnXYo)|_o>mFu*y31B{+u)(3 za3a+hKm6SFH0jbJ>R+e(yI-Up{$AqGxMhB0!i?p+tvpNd*~?BsqI zR0;59ff)EUx~AiANN~I_Zds3)Ix*y*8dtV8NwZ>E^3yLNXZo*!Q+v0rzqiRREqhqd zo%NP!42d;Y^4-@dg5IhXhI4c5QsYVJ=~ZB{PPDvV$3w^m+xYa4p_1$Gw@!x5wI^49 zkxFZA5kClzM&NfLcC&;&%ZHnC-t}|H=V|G!6`xZXo1b5_agcA0uitwXklo%~EMs6O zlP*P>{n3Zi!`e*aFM)T85Z3)zudJ_$GVd|itp+c?Qnr;;KAK4t3qthY?k z7HcKmMV(AR-6bJyrMBIr;_eqXx1L2Kz_J?(g$J6B9IJYsTw z7d1X3=B-aXJSP_PdEL#~XZsH0+)wWGYo4DYMZ*WDmluxJG+ApOGv2bM5MF~wY&3cw z)#crD<@yZYw>hc!^54EidGn(EPGg{(bSJl6Rw-wbN;sDbym4L^FLT3HpJS zCG_7t1t{kk7stw)7AJ&MUKAFF%kqZRiXGMiM{U;`wf2&=otW9m?VA#rhzuW+$lT=#9-au=o$%TH*8=-+P&&l}0fo z?NyQ3hGOqit36FN@Rr$^yT>r!5rm`=>S24Qf~dsjwkOlgMJNu;M+Iq~aVny z>%SA_V#AYa19Pc8w1InJya!3BOHb-MQTsrO%`e3@?>*qXGf%oD%VLSKpnzz}^~;9C zlNT>lv^Hz;hN-2-G$G~$Jz)?p)nRFj@Jksc8a)>pE%(xEU;TM`jp8;Wk;+<4wcStS zGR%3=oCXuAO?NJn-nVD>edX?a=}M1T_HK>5E_8M|V*l|)n;8E^UCIbZC>~6EQFpK2 z)ll&KbAwkiL^t%D5Q*Ni( z&Oc9H(ce2fXZ}?W2;Sc}-*PbK?1$NAwrS00i{;Bz55%Hv<%Kv~AOz9rH7rp*lK9QQdwrYk2@{#{QMkbe{NWc*tA zcvAA}TIC&Ja8O0lheR(lf7KvKp;93CB+IjALQIMVTfBY(3US(3yv43s9lzNLfiFrs zt}edR2RrY(pHZ$w=a|EJ2nM7Z5;WdWq_sLL9;%p}PB(wnCEqgLY~_LsZ*uj`)6Q%& z@=`tZLzyRrT8$2?7+Ia&VMNUR&nvy#tY|m#@MM%o@~~$WIfIsa9-BSE>EA9tN(R# zQ`0f&`)>KKn|$G2g11O=x1qW=K>o28ORVm-LLUK9;pjwDb_P1JN3zaQe=?L_+NJZQy(C zH&9=IH-}q>HSOLx97PA*WrW#~Af3|%fI*p`&G(}s0JT!2`jmKX+-#e+)uhenKJ(_@ zs|@eF11~*6bCLm#2hX(23iFmjq!y3GE#&>($P0b|N;~5E)ioiikn-!roA=DV4)N+7 zS5dXf{r^4V4ENBuLb?Z)NK@wwkGNzP-Ljf+<*JmL!rsfWAnS@j&-G)FRo&uCimWNcHsQn~nb338$GJ9yb ziooDcBkBba=A@;FY7fia<5I2haRK+VSjK9%lTL!@%^pdEM!W=N61@l>u_6Af8LqFB z2dO|TR2n(4T|2~nHJs~so%Lqgb0XXhdV>V%4M}#udDBl&&i`@_m!yBN6zN%S7OmxE ztDjvYIO7+mdB3wGsH5)%x+~2@5}`PfD!y52hV0*WWL+**p6s@KS8IQdsMJqmsCkLu zYW}U(Giy0rC|_Ywcg~4yk2iF=r=gYsP{|*pYW3S4&%!6q zl@`1z+*J@;QhrQAcOppui3_vZS~^Nv+Kj5G(I>tN(wv(!;Ti1OC>CjI240-3bqbCp z$V$2z<~QTf$3_0o~} z&YU&wnrzKO4l36dw|P|jeOb1veL_}^cQmQ%r+><}n4O7$ZUl9_y!ksTKE!Gt4=$?F zObr!^m7S?lI4Gh1CFwFI)7m+`3(j77BE>dMtW&{~>W8)OpIHMX7_Yq^iEaRvS7Le! z!-&kFFLN6MfcaHZBz!-6fpqR-gA&>~TWyfMF0ZvjAXC}5)QWfQH@kwhHAzupAkoOc z$g3H1IhmL|n4LG?5Y8_oA^rjwAttbUz4g{JN&D?XFRpN!iiG0`yunY#-KhXfh=0JZ z2-#b+DMlN|kcJSOs1dxnbPiCCYIFuN20tD?!&Fah!nU#*vbA_Xe0r^Wn+*M~`4;IS zoAZ6%9aNO*eJaF4C|0i0x*pc7$M@FK3F)rQyL@T^K=5j2M2-z&_fBfidE2o!(Did9 z&h0n*D|JK_*(9o%l}gV$Sd;8=6o+R)*UttiH~%i2gmu(*bx~sLfBddQ1O_gxfv4Ds z@xE*Rk*us!2rFZEb(>^KIJ%p170fAN!R}8uw=6M6Uj$g_n2_Kp)wunpmSxxhq&9OM z8AtMWLBo)ve#jk0Qd%|>*kxL+;woT0f(sB5`^Na;(J6bztlm%@;cfJO?~-7h)Y^wq z77u;-!VbW)tNi~UF}-Th7$L+0+Mzk*xutzPk({envHc8jidB9R9hcgbM6@MdpavlH zrn6x5wN3(taYy|?BFcajg0~~tO#>UMDi4k(0JFzF%aqSRI#>z9z|vjK+75DNDTnV7 zNzfy30>^K+tohlSA&j)|{>AcS_o*=S^VJWN-W9K2TsISBQv5B_!h;1uPn^{bwM;=f zniXK5VD*7VHHw6v?PvAt?hO;CxXa0S3v0y&Cp4&sv$B}7N_Y@Rx2vGt5_~jOFx+=% zQLxtc-TP5QIs7=oKj!G@2X>EM6qW}^&(Rlx&H!UJNKXC7D7JU6L>Byxt`=K#z$nIX z_z`=T$u1R{#ueJh6LcUtXC+Ah+WtL!eebZtZ3!0qq^Oi;Dj#BL+hHUuD+BTKUKB(f zh@0=A-qha_fwD&sN5!4@p8)sg?KDLnlq-FR&(mitKS3Oz$F<nM{0&1b`OFxF($bKhdiY^yEIq{rwK(_mWVY z+yBV-<6H05>zQ7VUW*Y9K(BC_Wg<@lv^W?v;ZgY)N6^LHwr}gOt$`DpP>{IN#}6P; z<4?rdDl$>WJ8InuBLdBW4S}8~X-+!wlezw*9-z_1v)lKE;RvTcPbW^w41e_b#g2!q zrE#Du!{2c1dPcV9C}4&S6w+iv7qRFZgj*j?caN`9@=S)q??~7~OsgqAE@LOOyr>rn zv=DI9LjOl*A1@%*d{$i0C(OP=m8*pOqaMiavK~F-D~Myv#iIMtdITM}Ff7$A1-aat zkqy@`_w#?ZCijIToi2iOVgbV;6MB&W^Q-oDf9&S*8Dub`Mf?TQ)v13XNsB^Ob1|&c zR!DVaf6dMRSzM2WkX(+x4wq+at75bZ0VgwT6BlM(TX_tet$5QvtN3{UofaL3jSJ`) z_?9AkJ3vw&)IWR|9CQ^JEWh@ujbcIQmq*P(yvN?a@i`g`GvZJ9S%8^2@EgJhs3Tsc zNmn;tc4kfq-H)kd83nGsr>hQ90nV#h(VEDMmbBQtl3&i8-aP@I$7>%ldB+(7ubGuf zc=P=4Y$vCe2R2HPg|78*_gdcf`QIr8PQ@2y@7`g(#fUZENJ%tg_zPeUb(_}TBc3rX*YT2F8T<|l?6*&kR!NYqp8>X;z_3B$i2Nh-nz@HQ@o zv{Z<>roct`=HJH#oV>SOkbBJaWvy7c{FJj9+}_8p%E)%mae@up`AqcxT=arcz=3qd zYBgg?kxkjaEr52_NGg!oqF<{9&C2}1xUIY8ApxwoEj}~8d7;eW=?W(p7u~R+|2`f~ z_*jjY>h;%>Ouzov?qv{{chA+wSJB)ry$XT+CJxX3Awd=2qUl;-9(dU^q@^>9wu_x7 zCN$_hyIT{5STN#QW(l8JFW`W_eCS+QY27Y!?sVrH%=zbqyV~1pb16AJ2rMar%dSo$d*l$w50*d~>e+@kzu=KD`@&|qOBLl_5`Nxd8Yp5m zz`pzA1@OKD!*Zue1;d*riOeLzd%f{d*Nt;b$^YKdNec^=Q zHF|IKbLf{3g@wvvDx?j^ULhSU63*Y1jtpNt#?+ytNUca1cX4R_z-sDh?2HI!Q@2(& zynmKcD+v}CWVOrVRP6!=p&M>3q)L+_9lzJa2<*BLuhcH36*1+Vj<2#g0F8kcqfO-+<9r*sWR$&gP!~h;AHF|h`!>%iH0eYDJW=AenQ>H1AmSI_} z22z#>+kNV9c7pn%9Z9P#`+6UcKA}PPDYq8Z2PiQc~Wa!y@annk? zA+L=pLiER3-XBCiXCaY?92=C@75xKV!%EKAL7M-5$5~_a5H_33vOB!-7V#BXC98J8 zOp~XiVD+`SNcFWm&a zlseNsXJ)qluf1yxYU+r>*P=s3M;kDxm62&WQ)o>a3(g2KJjMa762-O@vDgq43WFM| z0SY8yMvIMT(5eUolqe8X5Qj_57;}o zv)MiOobP<+?76%9tx6}sUpP_~1K5SrioZhKr1lt^HU! zW3S_C{0Cg|ob1nI;GqKryfWog z;2HoXWz_Mgr030;L(nro)0CMa@H@Zf#V+|CnGt&-$+OTSRo!`zaTgSQNW3V?N_~8!yU%^FIaaI zbR`KuA28e(#lE0Cvq^yw(7iFOb8d`dpgefo=O+ggm4U~tB#ZMdbK$K$#^b3iSnD^E zdX@zvExZWHaQkkZ+bOrdww?vr+&zs1plI;Aun6#E#aXC7`p8;fYn;g5a^uKEfpZl0 zF)3vFE)GI-rxD?=RX2q~h+3ufgwF|B2uL3cBsEE-k^iC0tvg~&^IfIp3%E3754$UD!y zku#4tNNxY_l#hbK5kYBKF=WM69Z*{CYuHoX6t*)1x|SUWwJ-z?4Ue$$bs~5|;5|s_ z77D>W)`d_;<5hDTpi=4+cS3e{IC;u0EG7vnPM z6Cqil9mtGsD?!hEe92p%L6)rS1tmS&Jyavf1(s5pnmjF+-J5~8kUCB%w23h=)}E!9 zp!I}+Ash47eO)}?LnLf_G-Fd6{bPwApUzHw5$*ta&4c<|`l~S9F{;THO_5(0p7UAB z+jTT8Cu3&cZKM?Ja)>3970rOU;L`@|uuV;VfiqBIU7jJCHRA zoUm1sE9!`UET7Tw6#+}z<_WsNmhR_HCdFNQg7ORuOy7wTU?pxN`El1z4konvt|U

FPGuw%n52Oa|JU9c20BE71Pzc-0Z|N>?#oNW&i%i_?V!n*Z_M~Gbegdr;vg0n?Oothi-@Q({dq?$($oHi@SMre1u<@kjBM^%|9>lY?;HodBZErg65h)(p>lTH)Cw63TE`JUampVLWe`8gZ}C{jeR)4S z0bq6Q@#eqJ{kcoVyqT$41_t#y0Kt3?bfxGw{n^+W;iG(9;?@SRI)#=pVY)DcL1MbD zeh+{nGEL#dj|u6BU#xWhbNLoc6_CpO6e` z?nP}kqaQ_-+aBB{Qjrods;y^Fa&;5=a|7*~+t>=nLo~hz%e3J?9O9r+XH*?tz73G7 zs4YfB4cX|Z=^E5v*5x$lr2F~ueL#fF^qb@xJq9*jD*ZN*MtEjPX{5BEfj2x(1WbiA zw_sf(S$s%*#aI?^^1>e`%&Nc|-F?;=qTuX=?xXj(dy4YF+qgyAE4R2jG@v<0w{jnR z;t8*L0n8aV15*jZP_D|Rp=BT{0iYzXQy&h;4rh-}O$Q=wDPfRi<#Nm2kh*LO;VNaQ zG_HO5<}(fqN0#FE0Kh)0d*IgP8wf~T8_V6MYxKF?J!O2lha=OIR5Cl|RLH;_aPc>0 zu3hAE$n?s<*03<^1Wd-3Fn>>LaPjr+Do!o46k>=21`K4{_e@B*3t zl&KxNO;Uo}`(wR@<6mY2!9}GO+1L;%`X`kJ;U%~UH}2jc>ZpsUp*~EF-eTTG{i5Jo z_rRN8u_a(UL%EhyE+B?3rrI)$`!Bu{5o2>OE~GE%;!X?Tna>M%R?rhneF;1=-z3Qy z;n8@Sm*x}}AbLAIHW+7AbwBHP9tVqfFKb9j*1K@=BX4#LGdlP5j}HC(SAJTKC(Mf( zr;&DKD7nB}OW)C}ap=py+`D%#tCHJnyI|C6e0@h8$W}|&T(gF0(U(po(;$D0%lc;B z9Ri&7MsA8YJ#{d0rrQf3ytl_k;DebGZmuKn9lD9iLPd^BMxptz^>e`Tikt%&*@d6m zKLlEzjpx7+i9o~p2k(~0IKFh?xcF%ELwK#I(tfXJ|I)Jk*-adk=ED0VJH@ev} zvd2cMv4sUEGGma z>WNyVAB*_}j#l;_`o%i`D*xzcQe+L$=dUBS>|}=@w8`Y?y=zrXRT1Mp0^$tuA~95| zpb*|t@86Y~G@`1J;<0r3&zgs${6Pn{P(Of(BEzRtGN?k{00S2!2nm3i8k_1YpIL85 z^cFDPD{_FL%1R@&#N=_HQdri%`xxaodiQU#=`L6W_q0d)tUY6btA6ZANm*U>#w2zD zvJyhgql^ey(3)|(qjTjiD^%FR3v~z7>(X0o$@2YjyRGCi1dQl%WC{=U;?{8UI_l%D zWR|Ccq*d+Y3&QN?&+07ujS#mnJc!61yM7K67fq z=r??dSR(=-Uv^yINLU1+hC!R_?lDcAamNh}7L%1rye1gZTdG(5T`i^E^>e*(&NHRC zJVjLAqU~XCY=)-pM$dn>TzL57^w13u_a+gKao_eElYP-=cq4kZDQ1~j9E9WJP=huB ze_ZNgFp4R)KC&dYs@L3w2Quw{${5j+{+B%j7jZ(IgJt-|M)9!!vxWbTB0XwiH#uZD z9!3fJghmQm%TqZ<)6RWUZq^g{7by6WUAqP(ux1a z5rY2AtwORS=w;}Yvh$*@Z*9NX6voy>5H@D;3OcxDMR{70cQ^VFNj?md_S>sUhtgt|EMWjVqIGN?GezaTn zLl-_=MqWYR!T{mXXcy9x=+-V*srBU)x`8Za@W&**wMha{17Vcr&tJej0_+^(*FffX z^oe0<{@|(H%QX{nC`BTJMj$*wcbfG9F;R?-B1_BpX1sk=9F0hnigE!~h^G$l9SOe( zW38>s3F#n+D}`*>a=&t6Sy7U6&z(+`3I>RO1Jaa}2ihwfZS7h+@@uHAw^D}9dkh@w z-6Iv@j%*hFn`~9PTg7Q#Seuy7b8qk|PT8f75v(0@_gR*deG46@-WAqKf_cch5N-}q zG`S1y-Zd_EP~yO3{E`wc{IKHP!d1Y=Cnr)zn)5awhct2L{0{p^@6JLhu^gWWd$4he zD{7*x$fr*7JRXt?E|fitF(9B6yIgr_sxm#jY?fbT5V!yF8w`O!Z|<7s8fcERe~Es5 zb~5a6}YI7zk7<_w2N?j+*u&WQUINo z?zw#PF7zkuY`-nJV;v>l49D^zmG0$yT#4U*y_pk)H}L-9Gx<+us&|^*z^O9-Ki>FP zUkqqvO%4Ym=5wdr8y#9k?qj-59Iwyu=ylC|rOOppR7OBy4aN|vK`nyw=Ce({g6sh) zXk}ks`n-!_X%+c=6U>Nm0tjI3a=&8n%ae@}TM{H)d+Yo75pOP`u8j*89uyt=s6lQGF)R=F~qCp<$!ND|nf8%WTJ$Bqe*a^^eXh zUnSOeN!GLTxE6)igXM`)iZzmIb4v>im$1>07V^OEyb6T>JI;Q#lw(&amiEv6BV1$;TW#F7HA zwCi-g@Yq9EoS!#qYod-H6aXzi?L#C}FA#U!cZ0?}mN~BA=W=xa9IUo+Q2LfQNgI3F zT;2;CP_o+aQ*519lwgNr7hqQ}edfoVBWDK|_{Ryy{oN3o9UM^&tJT?b{!lc2fI_-+ zlGQ=JJTtZ5V@TOV;vGLkO)(T)tN`}Wd#lCU^Q`50&ZrWENu-a5J z=fYt6wsi(z>t`5po@SV7vTSm^2T0~&0Pwrer;2#}h{YL>3o{}>Fh?udL%81RZ#~`e zxT{!mQE9W7Y^A{Nsp~>A9XzqINvir*D3+4|X__Gw_ZE2M!IE3`N%&DVW#?amaILts zr=zW&C>eC{hEF{Y!HUdh!Rz&@ zD~j?3d}XOWBuSWbU_E*x-?g+8_Z@`4&*ABc{Y~)?GR4=^>>Qz_ z%EgsWeZnnK$139+6F~8|67ji?g4g@_Z<$8IGU(Y4|j&=2=rEN()srfmt z$NI(PE~wmRmM8tvpf0-f3UU$ArTDaVP`xS8k>PB@`Aq2=oqoN`JJ^Zaw8BnSavZb}8dpV#(CN`xm+XX7KM#Z|7F-IUrg^;{MyfL(d{?LXT#3TH061DZYYZP-(gZcqr#_ddX{c6l%wMN87@wl`y~*E;#@=~Y@g)xU z0_AlCZ{Y3+45zV!S#dG`Dc`u=Qe2IUX9Cs!>AbEOFs8SnnmZuN3z-Gyv-B-Uud<+wO#}Ldjb%LoYJPw?Meq+F zKi%w~W~NnjGGv_H0P*JmKleH{GQO71A%Q9ZF#Yg-aFdWU^dk92X`@A#NDOl;gi4>O zK1=-g@cgX`UsTIa9~+B4c%r&$OIA1|sLO99uBzNfmY)vy^T(|p>u^hQa>wI+t8+Y# zUtI@_z%$Z(a<;ZiCIl@VFjJSMMx{unTeWHnUWV}~-4Up`5CA<&cEb~7V4DR_Y+6xP zwxLHUV=Hc8bwE5d!0C%Ui8LQ$5p{}6QG4iGqbg=t=wYO>q<7|gCdOlHr`u_!gTS4O z<~Dh-s1TY{lTE-JIcidwd%EA$@Sn+>%3Gam58WG_y7AJ$+nV!FQOrVGjt7;CC-_I0 zC>Ohz^ndg+&KHjwz?&5Bz2~WU0qLCYVR*f8{;vsrln3n!2uF`ok1&HW$?ge_6?Lun z&adWNAO>?kcb)ymlKFTT6%guK}U$GgX@Fv%b$VTj!V!wHv`-6W2Si zXSPbWW5x#Kb5L9(1v#Vr7LKMX2#yv&-LDt>D>~+wG3x07dK|6Z^9Q1THOv3VoRqJ3 zsH6ZmEsj>Xfc}(r6$Nwv6nRzN&x%?Kuw)f*9gP~UI_Rec<3(xp1<(>^6e1X_KMo!4 z-=%g+Y8)?-j@Se|4I6Ww3roVrhLXWVbpdm|3ter~$_9MQfnT=t`bysH z&PwgKz2k;eV1j&Xv1Z|S&O6Dq@R+Q?l@77NJ(~%Fo{y1MyeEs5k!?CBf`WmC<+^WW zHWXR&82PFL=-BYrZo~lig;a14m4nuN1-VytC0;9pzX|a94v?hT?2jd%5u~Mnl;Us) zbr2Z|N5zQXqpogOeLz*v+XKdbq1H_oJ;x%!NSF~}k+cR%YDLRV$%byN6{e))zB5}zc{ zr!KvRpuCQ`bI;s_dN&?5qcyYfwU{u=17BGV_b4Y9PyU1*5dwR8-xZWy z;)87?0Hw_{93TrNX#%fXV&L*y3uQ~MG_vXCK~z}W4+UdG_hYw=TUpguwE!{8fOSBoK?FrNPK?ES@AKW$<%};u zxM_MLuL93G=Vli}jW>#YM&vEx)p4Nz9T(Z0U25@#(<^t%!{f7`{UTA~@9{*}W1J zdPnoXD58y-(%5W(v7MmwQ~i0!yz4~ewsA3@7rxE?dsPpZV|lAe*x7!v5h0L=3`yWO zvS->zM8J1uAIa|dx_wO?eiyp(H}oZD;Dxm~&Mi;$%oaKG+r8_%iOk@+B8CkIC2&@@ zK8Ve>H8}p`A!3@wRxJ<=0p|5~71LqoxVBc8RupS_a6g0pX~r&t{PalK0MVEW!S

1b)`KaV-fS?x;z!|-}{B|d|t=7Ck01r!{DK_#L_&xc9yNMky`V@GV zMoc)qKiN4a<-_8idWCgJfVMwsK6TplpUcb*-91V?Z+pG%!*cb{ysh?M!u}G<>7cy5 z%jl(976A~RliIo$HFOF*q-c>Gv}LK^tA|Wfq9E*Stu^JW2&4fDDI6&BM3+Wnw^-E+-|By>Gf-yVS9M@{@eI1| zL0u-(kVs?e{fC-w(21;D?m!v*%yDf?q)q&iy+Qtx?7ZWbo0a#$P38BSkaJ2DKf^X& zwP?U@BPv~{dUYmqR4K^{)Y;o0Hw27}=CW0;uTS|?H%TCmE}2UKUfTe9N!A>$PqxM! zgu4oBD7;Xz;qjZJQbojAQL4el*KwRJ^-8p6CQYdp_;L|}Ripg=n*kH)GV8^pdB6n;lwf9lUk+G#Xc3f{M$V_7tyUOF{S1%*nc@M> z2$ywnIjT^ym!#7PO1a1Oyy9wLQzChx<)W{=Quet)ENkZaNkYYZVyP{d?0ApTktg|` zPdn~=!?MI>`DJqt##x5IqnGNx>!%-ybTQdAh3bRT?@2c2Md^q6TPdR4@<@&-_z2m&mpYeX#@K!d&ONk*UPA8FKFY#4v@ zzM$Qx`}Wu=0rvhaOT z<7SKEh`e1ZR!EiAi0Wv#XiH`2BP!oJnpnVQ)HU9cF%tcw3$8VN#UNbCeaq@zer)to zMg?9=m*p_W^!lIfdx)**7GVa^^Cg^Y7(l(Bx`@Y+9aY1`D-ccG5TYVU)X`_6*0X-} zMQ1l_K#E`TnZe%R!v5@Bz<4s71yS^vAP}qWnSAhFGWv!VUf0naS<{!h!T z;Tk(-(C~>87#>%=m2yv}bBtGLeT+66}-!?Cd~b8yR5%?r=PhZ43BeP&uJoiIp=%z8oXxHodTsI~{kIS1$?69n8U^m_kGtnx+e#V}pQAbvtvV6{=yZv98nF0rj zANnQt^Y0DVZ4PB$`?^h8XTALFJ#hC7ZS8e=&(O9<{!i8j%&N1+zUf$mCp#d&F>p*3 zK?@4|MpS=+@t|7y`T2d6e74N*+g%UI8w|WetVm7U8!vEmr#GAPjJL$*gNv*_Lko*i zHoM)6)DFIADV9vOhWMlFrkdE-0jCAPW!ymiE}G=2<@=hTvjD*TRY~Ia-Ck(@-LYee zbv)Z+;==VmoAQkwiO{D| z?^|}++d_WdIVqtD$%^316J3_Ty*1>H+SOAAAsR^lXNlE<-uJPrhf?w z8`MX~6RF67n@dy9DEreKi4P&I59@nmj^nypIV&SQPlkI<9OzLc=)C!=!`mdQaS#v_ zE|QMr-qK679($ilUT2|6s`N)hj{IF%b{PIUW*WYn&U2a_WadYy3KqFt-<-aU1l%>` zZypxI2uZS)qvFN4$cp|#djQ2=kP;`fB*n82C3#gxfC<8EQeQC|lbc)x2lrl z%77LtO~nN>HonFR11Xp=>3FUcp**>&A!@#FXW>BUBG<?l*26uhBw(_>8L5*ZF zC}?}i#NGN&n{pgJ+?VaaPQ)wsizJ~qW-F$kyESb`Oy9yr0BorIobs#1k-neDY?o8c z-LATC-m%W;DD64sqM?Qqdvojh?rm=X$K5JjwUJ{jH`|3u2z3v*;EO0cGR#w^ykfJoH4T-ahsSBTw+H%5ULTunyVA_g z@k6f+SfKUu^XdO9U60xLc267Cv(6n&u6}dp++aTS^RO9wkv)#XTvmj8+L4ux$8-JMrNvU-WQnDabi(x?SGQ>ohD!&o;?g4r_^5 z;~b`ZLf&l#i172-rvz47MJag-Ura)A=BnNW{}}u+g<)F6nfy}M#t*BiL@KmPX~=|@ z(f+VOK9E7sPBu+n+uj>UIAXGoD>+3QOA$k*;50Yj$^#sY3fp)uNBl2&y-8A!%mt)= zw^DTxUvkSetfdfAULW^Pv0;T=y+H@h_^Ar8c@M>Mt{Q%nE;|mKmbhGbrts^i@FYpy zJ?N-eq1koSNfeMGm8NzAqf6?c1f>j-+QhfrL1MFMV819W0tcjaH`>q(f6(Q>+y$E0 zxaII52PkK6*Ao32qoHlzewiSUIQH?)+s`v^W_NvXy$CaQeMPyhL32bz)c^D|4Bp=v z1CbOeoqnVmHGKh5?C|s+o%(b;oL}R71@9I5>UtCx+ffVn=siGC4b&2W%`Gw0edLc6 z(P{izujl+F1R`1@zM8;3L4q0^UgYt^3WxI8r)=^9b=RahUXCO!t6U!oUB`K}v&0kx zOh;KG&*#9DpHJ$WFyQwQ#eS5tQ4grrhL_|;LRQv7Rimmd`E$*D&9Br$eF3;rtZEJ* znv7~+z0G`_NhDye7D(})!SwDZ5atptgWxUzaK0=WaK>wKB7Q)hejLg8a>-Eh&r%hS zX#OxI!M=?(S%7jBVUoIxOXM&4U)->&;oV5n)f}wp(FK;J<0>nmfN#Jti~rn?Q;tA( ze6G4pGb+AdMdjLvSo89${84Ktv&d;JDo5;CFciNaV$_3CWJTfEyUz!6pA|5e?64;v zs}FzlW)}ONUC#3KKq4H6os++w731>VVtB)ClL<8i07g25g0f?{wv7$x`rH{8$D)Py z2mW=ynE6-{c6f@La?Fd5FM^yRc-MwW+67@<7tl4#7Ndp~#c?^`(E=lVl0k!gO+*#Dn zP>1*8)Sc_pKkM7R+(V~qpQRIpX9u%e!wt;Jeba&0p^zOZ06BU*0KV-+Gm>F@CI(g) z;u<)2K9UeoCiYok5yUY0?k3%IPjU$=G#WKAuhvp^tZfD<+g8aQvG~AyVY2Bb{TQ!IFdjAU>uPbKeZB zXH9oIDb&((rl2m@B;{#izDC8J{f^7hAyW$XkDA9M=h!{%Huyzzt>|2v;6@uc){7zi zz^3Avd{;P)V|OTP=AG8nMe(~#HKo`p4}P4Ya`D7w3&3Ez;qy9-HQTgtnOcLCm|cb8 z?YWlM0UL8HpO#6xT>}kWYs@~Z|G;M+qU8HAC8_mox0G{M*)&e`)1qZc&Pgghe&)OaxK=3(nG2xaO&`3;Ju%^g1&kA&@Qp`YI8HG)?Y7FC zI1<+`k#yL+ilFOUta8Qef!~*CI(<_aPRT#;?dX<9$dB2fJz~qNS647`zC1I^J(1pl zkDul1e^8BrkF@pLw*F6F*BK7S_qJE>u@*se(Mu4~5_RoT)5=ggV2=RD!);3$l@^de__1gJ|{QZa6@^xyG8uPeLss4G3yD&l-iJM*yRENOQ{ zg+3IE@+ih^h+l#v6B)*(Rbt^+6KRiTIc3|TnT3cW=cS9)M(?<_N->QCJWRYauJpP` z!sC~PKAq}uNqssP17$RiLtt%jdTt`iM1jjvh-cXRp-w#wc?fv4H0e1(S0b2OXLPI; zh?ROq!TV-+^yK0yHeNPa5s-V^{OznKQHqdzT_uc;wW9xXKViCr`p^UWq?{q6tClu+ zxY=v%me=rl<1}%_;b`BCnsoo9unH^}#yp(!g-uAT2Xo-kseGMwmpf2Otk~<0?>Wzw&bO3HOR7{sVNr$p0Ogm&e=QZN^`;;fK%+|}OuPWfKOKLl`+h|U&%fC# zaVsChB?wfXLsA5!7v+^gC3=T*nT;BT&H|C?S1-B7gasTkaO z&74Ldi|pffPUDXIsPX-8vcBKpO%dEETO3-pihIO4ac93V79B|?xiU3Y=6N{qbHB8C zUu9Tw@@RusA_`n_UM6;~?fQyz|JKwv?`Ak&8UV6ul9t?%ko>d^@i#N^k+@ z6xeGb)W3IX1yN{D!n&T`m6^5T$kOcg0=tKb%%rgC=s0JdT1l^amT63J^gNj@M&LsB z)t_9?g;7hCQ!sVW{+*iT<0UxOjZq1l2RuxPKofroT&4kJShYuX^ZV@adA8G|H^~Y? zT4{jWMD#};@au(@&!A9TB?(6}B32)RBe&O=)44favV7%Tp8NvSJs%HRb@y{R!)A4| zU}$=#*}vFS_fBF^%KuFt5_uRd0NiE%I7gXn!3+*Rw&HMM-^;Go_7&4SsdrlzS>-9J|M`$eN4%kjD$;vPLJp7 z`k>YccsuVQ*xNjDmWRdX+C}BO80%3L@m^5ri%$T;vJF}YY-Ya)Rr2U{j1sgYj~Nvs zAPR%Gv5V*8rSMqiZ{rT^; zLji2nn^8uvVq5r`d;NZvdvZ|+wQ!H)7CqEsPR8%bJItYJH|R@YZhYH)EKPC>J*_DKX9$W}^>{_-Dnwp|LsK4AZ<}Oag`3%-JCs~m0tJ5cb*sVXmcBHKdH<8(>|CarFkqpRY z2DGW3_NRW?Ax?W04j44agFw-AQKzzcLyGoC#rCj{Vn;V^g;{bgfF6>G1|zpvt*3e>RieAu$-8BLR9M{Ap7 zf>>wQUJ^N%SyS&l)aILYumn&2PDNi{uwJ)vQ&XxrR6WZuSyIAf)HWCC{;D374OoVR zxo3zs%V$OLB53PCNG#PbD*#;X`_|j$cL34f%sQxC=}B1n=lpNGhC30*nPh}V;mR)Z z*94{YE3W_z1_&V(KOk=$0g8QBrMvi;gog;ix_Q}BkRXg@O_BPfiABj&5Y zG59)v`THt_|AyYoJ1;XzC?2IThpPd%of1 z16R%~|MISi9zYcWSXU)N(vx4Q=)@6=1_S_~Gvz~#IWFD7nXv5&v1BO>4UF-vOeTqI zF;$ncldycMZQg}}p?tABl)}uG^7|a?P}hIaHu8!q0)|<~Ka!fucx)rV0%hIvCk)7O z>Uj2G0_xH|c`n_(?0%fL7NKgFCZPn)$_ZFH-&F7c65dS(4IB8tflFm1s&(N}Irr|a zzDFI6Im1^9be$cf3)5?%jj#l5+SvZ-enFL$*?QL9kJsz84@lthelhkS#ZTGIHee3L zCIvTLEmQ5u$a7^%7aI*a3f!cZnp-iv0QnOhG{`G?^iF)++|6^XgPc>IJ*lll&jsfg zj3LiW35cNF5H~(3!MG6;Q63+E`Y~gpaNYi`8UtyXm8iS`=>T zoWw`r_!3Wlhn<(UbvW+KP#m1tI1z0`uL!oINM#h^ALvMNV*AiCG|BJ?G z+O4yeyqiv&iu?R(Fz;QjAF!^U1qI>H+Ozsp^^tOp`efZwM~S2}Ez2i5&dhB@2a1e*K5-$?%-=pWU2pM6BZKBga)SHDWaZzQAi321ca?{lmhBF zYONfbk7L}Lo*y*4>k&2~AmPH@Y8!hOPbx1#kS=d(lHYj{tG!>=fWSg$RSpmbGdil5 zviH?Kn25sZUwaG6vrD7!!0gY6;w*jjw!RzFi&_oZIs8Plkad`+feotPmlwaaj-Gzp z{LS2}}X8O(7y59^L?g;sY}w&H}mot`2{#3m8z#k^N;__F7MP@oex<#hOo`6RFG(vGz%82CehZ2|Fe|En)#v zL~0|&PBqri?WD?g4_z$#s2q@nV+)`~bbUV}G-Pkgq?k079&h#^?*k1zrfvU;=codQ zPN*wL_$HnzyNed=-hnOm-+JP+U=uxOwZ%K8moYg&(&1@PNv19f7p&n4M=l8zzl&!l z-7=bL_j|4zZb3Do3rSZaQ*JwYxQny-5wE?|=nQXM1WH>ho1}o%j=ABmaNi8op;y-p z%$5x=40ay|mC*v+`cVcIUpB|;9?N6f`orB1D3VD8$_65-t}Nc2k~U`iPSuFQJF#fR zXH}!WTNiXnU}G^ZUytXN0PrL&`n~|8DiEE;Vv@y{Yx>W=E9|4Y5jml9tnc&bYVH+a zA?{UY5z(pzIovyseFP@KiA&}?(=aiF|lGi$}+9e_=}zBHWY-=w}jbhYtER|!@0 zrwoH!1%VCs-bX;D{<OVubtIJNSwxk-w! zMXs_%l+O1}RY;42Ok%C@@`}M^95i+{0Mq%T(UEjFE>vld4f*1!G$s5>ia|$&(L5rc zZGblC=UvOSZm;RSertTfNG6t9jV#V4Q>Eo-8AW=#tLi(fIQ30O4mOzNBZ=iyqtp z$Gg-5030XuCfzrc>csf|46V6-Q3_^FyeN+yfR?>2; zmfd)23K4U0Pm1NzZR;cstMT(|1xsCOPHJtV*L8eu%F(bN4b0OB$QzU^;hVTrCRIYb zOPK}NqJG2~X@iD1r|I%Nr8^hygi1gNyKSTiKRR}on6)%=iSmH9H!lzbtwTslf9fJS zY(b$UE~MTa{20Dj-AlHUP?)Svf$>`)qok84_x=ecDHC_>t@-aq`OnZ%c?s1}o1zIM zwC|n#nCra7*!7!vBtwmz0jrS2c$X;1ihRMzq%&@=3t$%B(PGv-2Lrh#MpgVrgH0zT zp>Pgo>}%t5qsqU4+rXb8(pRzQg8WW~9jLUP(e!B`p7kh`EPGYfbMS@l9reqW!+6rt z5KF%)5UDf*rbp`4VhsNy#!_w5k+TxIFe|>{%{_=qqmEBY@cT0B!edmDw_R_Z<@p(%_k{Y%C%_-f zisQcAuD8SXv>+*B29~McyX4GR-)Yt5ZW-=#-Jwm{0f+jI*|#iq+gIJ8u{rU*Br@!J zzc8UBe4tJ{5{%{|#+KhVoGy88m>KmJ0XK`2RYVI_iix$Qn?M0&z(=Yd6JH8K{nJlh zpME^?xLWZqqPWNi23}-0?vtnXk;~FQ!FP5mEFJd|dh(&AJfX^r)~(SNCBnq~;dtbM zABH6!Lt7*=GsM#V0NzZsjI5$pCPrWk`;K53 zdS|#Dwp~fY^9W(ch8)rwU#WDsdhvWMY2S#xNSvKW<6Ye>nOarGr2@T=%Xm^8><@_c zg;5;M&oF;U%uh;-^$28;N0>G%=CUc(o_@ZV`w@k;-&W+}F6U^ymr2U0MbAivbLpQ5 zt?q`fw$??u5e)9R#SjD(Yc7%x?fmH6^Qqt7aIq|q^n**ka%n7u@eiE4uTnbM0yNGH z1-O$fl4$B#il%&E0d1cmD4ad&ttj3#xu=JrVpApr&H!r=>J}w+Cyhz8y#JP0JQe-m zaKhQJiSh3gsFg-m`i?WFBd)w>dhLF{F?zd|)2YU{&3tU|H7wyuYc7Z`f%Ca!f>9xT z9qrDI8~s6S?h)<@K=7g1+LV48xbu!TJBVBpf@V8U9MP7eQ8^+;i@!-!-1pXamDwZY zAWi(xShv>K8I`|vbKUvNFuJ-9ClAc|d+|AL7jx%NU3@YBvhV~g?-DDc_yPviy~~5f zs#=REcp*x`L#s&Yp%}m;Qa(v|L3s!d3P{d@KhdkXHCJbs|s@ z$>YRi22{}VtZ&|DA7Gv@7bX~`!T;sLX0qgf3VSjDli+J>CwW7$Pd}b&{f~W?&2E8xHTmCvF8Q`6JZD!U)8; z3&_51WwjpmU#7`jH&0+7c_r=-wvVZovN2U9P76AbK)C+&5O(`U-QxlJ$_jXl-;w)< zv5&HH!5R8FNI$^#PU>QVf@E=2o1?k498rDYPlvbAt(}6xAg`E=P7zFDt4a>Pu0H|A zb{Hbe9Akk{{J?tw?OBl*>P2LShT_ujX(wSd8|t0c1D=(3ujP=?gz?v^dIsQEF9u;M7dJbohT5iUbRb2j!yEwSvp;&NoPF3^qVQ_Ov3cJ*Yy5AF)xy>0cJi&zN< zuTix*z=fDP7JJx$$d3G^2S5-yfb=dTda`%uq4xyusSylokWR6vZC&_tbCf81F68gE zrX01=P3>T>q){5xSt4(_ zWt%}-ywpK=#@LPDs)?NG6Q-`aM8H#u_dj&-$Ts?X(F3(0w1gvuj3#9Qfj+hEk87yW zOpxJRbdi)5{vrSq>LHDFd5ic`*kL8%&zkv@4j0{|3t$n`N7Hs-neauY?K>;KchvE*HA5 zQ2{W4CJhVpOxq+dX|>nP*dX!9mr%^eD*Pk{P4P43yy%lc-H6O|bT;13-H)#xW!%pb z6Z`DUv`AjqxZj>RN#4k@^10umaE!@4SL=O6PUV|DnaBBOTsqAGb!sHdSe)xKNwEvT z=6de+3-x-Neph)*4Z6#W!<3&wj<35)e{HthceSt7Jc9DYW6tt=J)?_r8Vi{-d7V{_ zi2Bsx-y4u1&u2G4SMiOQROTM-5br9^z3@)q%u17vvYZ0K3BqvmoN?0|yx0B@SVZ^D z>}}znIkmi?J+~4M^gi}r>~EL^3#Y$SbTU6BNGumI)niyD5zhO%{bgZ!-g%5vk*#37 z?q^u4N;VVsNX#y9>ZKF*dL+WutfGXhrZ`XAyWJ2#6`E=R~FnUXQL}2_p<(`AC7U zLNx;NPbZgaWuuiS{aw4OJnf^eMW;($c|z%|aeDf$r6>t`cNdr#d(4C0=!BAg7?|nV zN`oz5voo5VpSh{7KIZgrrpbh?pjF7?S%w^oaR&LpsP<;rT{3N)P@2s(rkPRzQb<$S z5mTjzI4n1;we&z+%}cxeiDm)AJ#(9OQ<30>_G)KUaaVMSCv#(IYvxin8>=Ih^ov8) zQW(B0vdo6!eMZ36o{&f|+HrfrEZIf>Py0_Yw zqsbnt*!X0?0v2ZCQ*=+az-SROoUN-H$#MH}@Y!XtGWOfKy?rn-pl&o*F45S6i(mOG zNt`~Mlixbw6?WVE6g+09_ie&Ga~84tHbwr-{4}c*V1W;>FnlWl7x4huWPv&ghiqLg zN6g5|Um@zM@jF{msL`Hnuy4u(Ix*oOypHs!8?UA13%X*FD3gRe-rvY(Jzj50y)Mi^k<*^VDyNuZe5o z%v=`3slbhZZXA<&6$kIKfK{h5_h#N5Hrf-nZfGa{PgN9Z%~#osn;>4awxe{oYp|&6 zm|rOC&w>sxD4iSq(GCY7Ngs-zK)b|;Qvz?|FhkrD&}IF^>uPzpHRer-Cp)nFe+=8> zChe8!dTIpPR+cqQ6_Y#eO$`c(8rwNG_sjA3yh_i8+EDL#j|;XrmP+?-pPR0bcN%16 z=_+)K|EwcN!4p7DRJh495-Q@YG@N}@xx_Bc#eDp#VtQDP2PeRy4os3i2bJI>*63;s-00~o-NPOIB{9ph+a#(>Y|kCktiq5dWu1SMv@=(sY1=cV@Syy zmQ8VQT(g3*MTT>{vL5W(dq4P$(b{abqPEc@)DXrw&68@K0c7@=qZ#U-duut{7Tz@{ z-5S|3O|;_1|5`{0o_s+jx`@X{sEoaLH&W5NIUK>k%IbKc9?#Jh<0Qez__k{ndq^TH z%UHt_usD;rf{`cscwf!kweU^bJA)f)3k?#PKAq?058Qg@KW6KBse4*I?#+@Vdsa}l z%iw5W8n6L%ilsbS8Tz=|AuLSr)qxJ+D7F53s)p>3Xy_Oi+*K+I+yY2I6S6VGJvx@|uu|wFJz^udeAu#_vBo@Ik@dF97wtj`){x*l0~9AZss?v_Z#cdNQtg zCMEd8%2(bQW{NQM)Y7h?c>KDX)2(IW?k2NdHv%>@Tkn<0vFZE)qD;=&o$8Ou3&$SA z<_`Z`JB)$eb5;&4XvcU~d-+LP|TNk-!^n*8d8ImscoB8y0+ICER=mBW=W-cPyWLXG6><=wEeAj}1 zTA+p6PHFn5kc-uF+61DMW|0r@Oo zzClx9;UD#IlT!hZev9)rKmj>B47ZR8_l+onOQ1d{(RvH>>w<#I*Q;b~L4F|?1&zAy z9{hHshYtxqeIg`Vfz^w`JJNqfjon)Qlc?N8Pd{?7_!07ANlDMJKR4Bh{$vMLfe%}dj*Bv>44=m(UcS!K7 zjl1hq1mw9`0?iH`utnwC0$~gocmHj!EmTgebZ%_v)e;%=wi3OZ|Ca*Ny-6g4YRTJ> zFzGrz)sm|RO&7&4fA+RhxoFQmXIAReD8C;_!6(;V z6bHCS&W#dxmd0SH1_m)8BtYFo$*S}6-Ksn#Cf;CL)o*gnZ%yU=uE+8vG8a#0`L6-- zj2UdM7aGjKsPhHnM{Wy_hS87FibA_a(@=z3U-;hA0+xMoJPgQ6@9S}4|6W~Gh>0{7 z%o?p5#WdMrsgv?ER#WOpNw5A`Y8o0>~E~mv>^={|%vqN#)+f8H^=GGHT5kA0HFldNib*+*Mo_R+QTL5tDQFZ?;r3eOw zOz;n|*Gctc&|)s*SrpxC=tZL`o&l9Gz?gmbWc#>-hLdt6fk^BhMQzB5s>!x)EM=MN z2g7*F`lH~QtkT=#bYf?82FkywPC>!qu3vr1^xib zpyOaM&*( zP9FvaKK7`e!j;sX`|Bw}i!+AzKBHr^c5Gj1%3QW2mr#o!0ih2^DJ_1-A3Mo6iG}17 zufQjkhf0QY4ioNcleY)mPPJCwc?k=vBsQl^_hKl@25uU>f4(z+E-xuh$${e4ls2c^ zvmt$3c#t-gLeR>{iN@lsA@S)eTsJE0)w}4@jkuON`oYtNBulOcfG_olu7!15znyjw zV@Bk&M62GrY9{{GGgn@tXi;^z302cOmGo#jG}ql-qu@D|H^pc6oTg5E5s})1>K=Tlrn62|mT@(rmS>f%k0g zy}=;bG8QWui{bA3q*z^IA)LsAom=9|rS62AU(*wXT24Z?>0IP#1=u{>Iztu%3m3O{ zSJ9|d6c3MfUQih_xJ<=Qq^@~~MaB)8?C~>oT6snT0#cR=dt7#50+ZH*8@`?W^=3oa z$NEW(`go&qYe65|-qJ=7+)cb$Z66YKd@a}d@fekJal3Y(WgQ8==PjZxhxeqp<8`M2=Ha;D2(uZS~Qcg={u1k9<{5N(XQ8ephw!6@$3#gFUfQxLCYHm z;R?^KrGk_zjSr+wV@iH9nOy`RpNtDaK!MqydRtPo(~=b9;@2wCi*}{AcIN`1*4 zA&K5KYM{{;`6dS!&z`cnSqzZC=ziv<%H7Rv<3cCsTh|pSj}eHkgw?Qc_NqlYHGRFO z*y1}uYpj6n5d;P@k%;%K&h>RQwU`QB=mh4)UNkyflSCPD8`ijo-g*}J{ zS#|SYPu?B79}A3={X<^Uc3~!{6+v}KQ}e3oliAqpV-tR0IQ%v=pNVY_pKXsoP_{Gr z*9DUJCa=}dl^Z69L7)LviNo5R0nq}nbbOxSW6{d!e+ePw$k)PNHx@XzA~;Lf0;ouR7=FI#)@==?Wr8xHA>t6pd#21l%BMEIb; z_f^I8n|{akoK@?wKZ|PaPG9?ywH|7rE6*43(^9}de!7rXLDgrL#+G6G(T9`tC#(HrNsN597;*%ElHO+#1dvlFi&$VWYwps#`5JN0+QXaw)) zS0^S@ZwY}R4z1?G!HyU25PifQU)r?`rQ_mc2er1(6!Fr7m5pBbc&#)%Hu>E7?=`n( zhmRa>%+eo={@Ok`$J>VDJ##3lt+{(km+IZq+kA78iJ9>2E{}$IFxlZ@l7c{l&!9>M z+M&gdKp;>cCwY9;mmUh>{-D=ZYAMCF%%y@w6D3^$w z3J~SwF zP(tr%`UeaHf&8SaoGW>ed&KO-#c5}x8=}A=nTcGLI6lXbf9I2DB~CWei~3GSHi3o) z4c_=VnMftmp%VZdB7J+dfgz(5S@1(PG_0n)paE!_rh#{AaR*(=BZWS7$M&{D3TXU) zefR``u|IgZ^ey8m`F8d+m&U2qr!fQQw}`pgEQfTiQtfr}R`+oAS(Fbp&~^Fj?9rfv zh+9=;y!v(h;WhB){iv*Tmkv4Ewv{AvHh^v=VfW+p1QHN_mO@Pe F{tv7 Date: Wed, 19 Jun 2024 12:27:33 +0200 Subject: [PATCH 0711/1012] image of xps cs with white background --- contributed_definitions/xps/xps_cs.png | Bin 114535 -> 118702 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/contributed_definitions/xps/xps_cs.png b/contributed_definitions/xps/xps_cs.png index a1ccef30a1dcad74304f3c26ca91cbd8a11b50a1..c8117f52a3bc083f6ab999f7efe90e9385803d1b 100644 GIT binary patch literal 118702 zcmZ5{WmFr_8*V9u{_s-Vtypk^JH_4Iy|@M~P@p&jDDFjqyF10*wYXbwcW(N>U+%dd zvghpCOtSOt?95{muB<49hD?b3?%g{y8EJ9VckkeJVV~Cj5Z}Fn<7@9@fn9)eRh9bs zu40_{5O(sxN>oAg-Mi`-lxGtJ*g2Auw2te$cX*ipK5)Y{SHkb!y+LHeMb$kGkK0k2 zaQYHoPv`(_-$rQ_!@AHZTH$Bu2C9ndSB7pjM<-<>|4p0@i<)Miz591A@i zA89yh&6Si;eTb*$>0w8-((XUcG#N|d#A?M8U$ToFnWobc?A7G!JDnu+n7*?|AU2zr7|9frVfS=Q6XTL zsya-ArduR*g0|jKY=v%-mghIf`aC0;# zw+i71@YDI0n59z%p?bnT(fZtgn#SR&l4+*67y75-w-x#*BkqN!4*h}f>qa^m{Su3X zA5w;iC8qRYDf6>4g#ps_8C&l8w*SpeKY}B4_H?-0nfA#!vf+q%4T+j7fsJ*zP9tVr z%}wBJkv))oOu&*9<7*MB?QD^X%ARt;6fT$hu{H?wI_dvCMNRVWxQXz8Iqay){Y^Tg z){9jpQ!z0oIC!hdJO$}YR6(EldVXZ_-n%Sjy^PI7fOpY=@OG*174lpkANnHkN?Y$~ ze;IuioJinROrpIeTZcWL&F9W+cgd-0R`J_|bb_BOC1-anb(t;fPp}%KraCL85+)6@ z%TJJBDa0{i$P--ZZw`2{w@v2>S$IknU@Pc8LRr5fS$|pdCjSXFy0(q72>)&tp ztV@j~!i^Hkxn@;GVFEornBv`fgcCVOQJrcK2QrmuvF?ul=AC}d()Me9v%mATl{`$M zRITn(5FUs9isk< zN>bwfE5Pr2W0L2v$fBdaug|9EY;Tgu{Z>O1<%ld}UKYK%r9_JS9ph3=+9EsZBKz<~ zb_%x=^)!6ow;NO^_Gcwa%dRc*dDL`XS4)aKVycqITPEh$cenNgPd#L~croa9>z#6t zZWGHN>ArVSWY{N--=@BoWSx4i(E&Kb z=>ts!Yv?yGO<{sPWjq$r;>sa{Pg6uLL?2!T?rfcZ>4zLj=zJx>MeHP%oImk*Q1=K6 z-4SHm8-1^0jvvs3qSw!pN>rHb*TNxyibW$Id&p@!UsSs$&DC=~%J+G3VZ!$tW zgZxNLwL4PPb8I&&4aubjqrxW}`89Lq4L*OWTj2eR3OroWpw6YPK&7&K?aMawGBqATQ15L`qf}>an{mwv`M&;Hp>>A`Plg8{3m`9=F6uQA#a^xgzL-L zo9Kw_eElpY5n`rzef(DqB5O9nxU#;Jr32Lf2sDqgvMAF~y1r~A=_nW#rCY1S9ijI8 zZqDzDA-(?Sn0GU^B*26`oMiH?JS5fL`e2sfBXqu8tynkk`QU!k>dB^U;`up)>0@u- zh!B>P{F`_|HG=!Rszn83O7JUBO*^I(1jXR$A1h^p) z3#=QEKH}8fJ?BR~QufC6G-90a+0`FSh}y+#3-JGiGf)*+QEa!h<@d%}r(Uq47DNX9 z!ielyCNEnbZE3;dwise{i`)(k^nh!ZzML)*^n114qUC%opV&#q}N$2K`;3X%?22SRG%5T1GoVu}A>0n7bU zUw}m+2s#hI!AQ_?7G@Qd`O-5T!Yh(NN}O)hY_UQxar~(~d!4#*M}x1y%!J-2#9+xk zS2h^Fa`O7NAYIEY6*QOUSe)?5Y%hUyFX2P#4ePg0fFeWo-6@6oR6NTcO((lQe`sQQ z^VtYk;7d$T-JCJw32`$rdmU2r@N5qi+ua#dcRy`}aB&Ogst(0U$Kf}8E*UVkgD!tphyA!oaVr0;%)D+$nke>^kT zwCXJ0c2{%Yx+WOqr93q7b}%1S6YqkY6!DPE&R*XgnPol6Qgu((;17#cPgJQ$38Dpa z!l#j!d`D8X8WEswOYL7@RKJ7-_>E3vk$!3PR`I;bEsS7CCX}?EW-w1$ND-!#USHmj z>7q5f70V}(B*mvrFu_K$>-eUO__7nI7|d~eUYPkV7jD>hottX`P@}Zu`V81t$n5{U`afb8EFVxe&tX!&>(ErUTFc9 z+RfH;a;xlMfl_~KP>m;{#n<45<7d1Bwo49-R@svsC+KBr+Oq)63CncSN01Nq#?nhm zSEhiBgTr1jaRg|2eDgC@hKYJu!@p^h9FvwwClpwSuin3+zo4~EzVk%yL-|G9H8Ys^ z>zXmwj-UV|1K2L_NXRZYIz~ia>*izk*IOwy1lKo^eH4StA;uE1S=GG1N62e~vKchY z+Gc#<7;c`o*Fn)Jm2ss3vak+x>-sV$M&c6!I@mV2mvcSk^l05) z-m46VN)q@PYGP11cH#ErVl|jfm4D*^qTXJ~Rk(dmWd$-SDkJ~-bQEe|+$0?jn_S+N zU)PCrW#N&rn5U?rgy?YG67tBBo-J1AtsL=4oKIswAr$vr)&Ebj;9RmO;9XngP<=SyHc#l&NuHTwN(80}$zf*HQP&r68z*in(?y zE}G}(cK!Rz?S=d@iLH_wJ@w(#A`S*d4srSt?&070UwfGEU(5g+^1AF$mfECZb*4yR zm(*h_N!2)$-e{^U)nYgEq-4`&C=qr0x1ZD+1d?CoVvl<3`Zf(^x4tA26vV6VB|cGH z$d<5|sk7aWmfH4e1VyI%2L4J!WtUM137#u!u2hfIdlQfXbBkFTM@s%3TYmPClWW;wVUCEunZzR`6ph-iQG{a&sR3!^Q zl-uOK=ej`M9<5P38!{?M;19RNx6<_dJioN#%{{4|SIZH4cX)v; zx{LsK;5<*3wgJ{GB2=3_3dkTtIRR_n8U6wZ3dbF%6eMrvMzQg<-$ZCRl#to=t z>Q$3JnABu-f)LSWNo2PfYFUA_7Rc;2hl4^cJ`;0qYCLNYIXn=^!er#XO3MmE=+Da0 z_X+d~CXYfokbw07zx#hcHv!Xdl%WHNqFkVCnVK5%BHNt==Z)Bsn$3F(|5D<4H3PI- z`avr3R3*E~K%1$0z3nshW$`|M)7I9Tx(X#F6@CV2KOVcai*<$ka{f|5#EiK999EC- zHZ0QlVVtr3K~Cof2_%xV`oSc6 z_nSkpY~CTU(Wk;{@`Pet8bkK;n)V20eUP43v3XCKe* za@b)vQS1Cj1|=RL@}?n2E1w36HLhvB=8RYW{yEMlk{Y;2D;Pg`L;}ihVJABfZi~O0 zbiVqIPdQXJLzt;Pm;$3jR7=kb1nkkc=zLjt%yz5A=RNW0&0a|k+-}WktJL^$=D5G* zb4+8`(1(Pwfcgfh_6MP4&QJNdQIjVTkq)seIC~dW;z>GA9)hlRxaI^a944>#dqi33 zn|DZZ=BWsF1m?P$qErp9Jx~IZw3F}H;%PeCYxA&i^5EA^=}DRQ=lQ~(AkeH~+xPKW z1x8kOI(uOh6E2~Z02AjpGWtSn8)|*mm z;kQR+_&pxFq@V6?-%vWqxX4w6A_$i;xymyHuUoh)3^R~>?^*m9VQ!mGlc{>VftHqT z1pyh}HH^A+mpM{61mo7-%5nLZ|Lpn=AD_gehs!>!Ih9@5sV*V@7bwRf)Uf^rZ0?iY zc|_jvNycMQXfj(t+nNdGAF*{8R@10+;XU~KJt|Mo8(Mo*@~z5i@N0RE;}Lenz~#j? zuW)IzWq0l9==4QxS=;z2$rCaG&+%p9+*HdwQ^hTeY^qMhM~u4Iu>36S3i=hu&O(H0R4pGMEiJl`EozNa4Oy}cot6_LqL-R_zv7wrjd<9y zrS^|ejCz@+^KHok1phItt;voFM?a`1WMEG{Hk? zrP>Jc^FZ*%pxVVuA)AQ(ljc-v{i_pbe@Y>=cj^kNi=V{gIu9dr7=EOuXNUP*wXE7q z4oi$IuK{vs{mgSqB6m6EdewLzm=QUzqkz_{E%mazdHxNDD7Q~PDK194q0NRW`Gp{u zcvLfHxA7;yh3ww`DEzbFwq~UvQzPV{aWB@>Npx%@l3_i8=wiU*ZvG4U%=w{`1a#kH zh{^e)W?~0-0Is624#{WUgtfj53oj<)@W7tN-|sdk*S6hnoWWv{T4MoBu&axAS_olVhfC>Cyzhw>=-KW@qg5TTH7 zs_bqMsi1dJ0*U!zZcLsp)7{tnn9Hr0gpwqYJ91APiKiy7Bty)Xp=f^`40&Ib6R(fi zt+t~;n+b3-@|mzO+QKtV!p;auc3Y!GtEZFh_c-N2k?wf~GnctUaj*Y)DV;{0bsK-vwS!}tH5i~k6?CnY)%-do{ z$GR)S$}Wj6=DB~^2jGyl<)m8LUgmTywn!zL9v->LBgJ`IV!nX}J|!Z9)k0DhD_lny z3tMLT%j?I)cmG@v&G7Y3_+5vrWVKgW)(ki>NDh{xgIAlq+m<3j{vla)gY)eL;Z5=S zeUk6Yj181eQC9AQ_NNhDRUcluZhj~E^R`CI&RuS`uC*78jl~qH*O&upN279ir!bEB zwZjbA$9{H?T>Bt+Ez2E^X%w1U=7jP4%e;Mk{70&+0W{W~FsQTXekLY$_uX(AL2=e+ z_BCjUy|-5;dorFltDuR#Z70 zixWSd-k-?;G~jh9C)F~j*;P>I(_1whFmFB}8nBBwg!}oYG8ZtvDX%;Zq@m7MqxH`( z-*$Jn{bQ%HeKGr^kI+Xigfr2&k1PzkD&%&5EATX)*1bd>lE-wZ8i7{h39uC*5|?R* zm#9J0<#LH}W4ZPKCyOJ(@MJqM>-!~Ox=6Cn&p?0vs^Tk+XfmCBPx(5%U7Pr_-WEx$ zNPY)?zBb};*&K^qg5HlP07?!2lO0;Qe(k>g z8qO0OZPr_t3c;w4&al%^0(Zr$5IS1>eyqez(Gn5cE!DfoN#}lS&eR4ce}> zc9n+-yha%p(65jG2#`vpA)C?W)Mqv;xswz&LEyC}vYY>gK7gHpk>4ZvR0T4cYr^fo zGgnL(Z~W$?wx0VUfN5)4UbL34x+z+{m!R`Ff^dA%2Sq-79Pm{!*hLj6)v7eKsl@ff z^!mK?wjpz1Cr-GQ?_>12H%-TnBa+>8^0%mqt=YETxLFDf^Izozla|D^8$LW1e3R5C z*?Y`@*^#d4n;M>JT0<6w~~u zcdvaJrUzk?Aj%bLH}{sr=T79ZkfoNpJNDkNs)a*ktz6Ja+LhwL!74EOi&6Aw*xG z;F?_r<%XXnq_@aF&axn4`bAS9K-57iP(+)WUw}`{BeX=o)pPl%d*%vg4!}b;$29~f ze|Rj{JItr44O{iOlViXW^=>TnkXXRkkvw9TD}0JQ1mLi6gFR&--8qfC{h}qnkq=7k zYi(Ew6!F=~Fv*co-;7Evb@xNRS5CLD^;jpoAfE{DO}hUtTliq58L}}t{3*_I ze(=UsjI)sSw93ljzwxsF(Fw|tvVyC&P&i;$7-Ow>1u;ZbUf+o=w(7lVfaEa&~t@;7Y!<=f3{+M;C7;8=K@F0TgDWoHz9wmtgx z!qGxy<>{b0z!T999cz~P%&Gk!K5X%M?%kUY>#yRCcDM$3%>@frxS}V`dsx%>#olp! z44>Ze>o9G9iiPs)kn|_HvtQ@2CHApNk=cSmcuoq}`PV@gz2v>jXlNZyWpmcXF}H`B zJH|wXZz?OUH*eSm@I>z0m2;~pZ9!Vx%ROX`AfdOnS?(~f_*!cQ_VAvxgH8WVx(=0L zwa~q}Cs#$&0V1@S6%i5@)C=I$)*0Vpz3&=4SmajZ{W~=TgLws~gF6U2#V0uf!1Gn0 zpYnjyio5Tpp7t$Dw*B`oNM6l{iu(4&5X*jF-gd36xrHhoq+9pR#P`4?$k8u9_Vs8e znhFG145!U1>W~ola-?rOktL`Z+J#|tszfxIcaY-XoWvu~&chq&^}Y8bUOZ@9k&e%j z(6|3EtH8v0yNP}oE5eC3edZv94Ed&J9rW6~?M0K`#2av;PhZ&ea5eFwAw&CilP^RazvrDU6{!8NJ{`y-(3sF4IxQ#pbCPzxBhX&11okz0-4!*>a zRIDAfGH&l8r_)E?H^`jMXDWtlW{>01*=FO%-weB(dmmUO>wqQeQG6JJs9wuY!@`3c zyx2$joi8^h5(}vz6E9EJR@fvnP#bdvMeC9dQJ4I!c3F=vt8O?mWAi^T#C*Xrw1Y%f z0ik~lw`DmEc`{wSse5mB$vG2o>j?i6_wRY~Sn{JoS6drlrNf<+J-(iVTC@0S|D%gI z;4C=4ib7D&g-aaa{(A<^vMN4QLxc+|ia>b1e;35E3FFaY@f0!IPnz(6!cezLFbRK& zqYA0&uKrJ^gN32E4AceSZr@>!R8Vla;m?r&u2SL?y+JEgCP9z5yHxc`#+{{n+L`?^ znb#1+BM13u4xUp_s94ONi)_kv{nCo%C!IcXUoSmL zV*B8d$P<;tm08)%O6Ex`*5PjBVWExKOndk@(5o0fzuI#0U-N4$>`ZeX|h!B&@M(1uFwlxYB|0a&X^Q-h-D-n?p*El zBd(CyeCN5xV6)xbD4YX^aQ(sILX$y^5M$$2fkFzasBfg(FZz8-Ljq9Yob?K7YQK0S znbZ%2Wj-r;<{+$%;%_Rzu$X<$YbU$KM6~q`Zkt z_qQEHH9$(inLb{2Q4hLfXcP&*CWLWAcd-S;smHRx*G4)G&3@$-jMftMMvMAAUhn(H z>(xosT8tjqa}!e}7~yhPfA9m4 z>e?4*-zo&jKdk?>5zxr{b#@*mmE7QEHt(g`?%c6CyA0=Na1tpcX;pOSQe&eLmHb3} zsajn7?yA5CpFh^@#yT}}A8=JZj@jSfuv+pO$Zx;gkf`Toj^#v-&$-Y82X}i&tX*pv zz0xn*ksz)HYJYY*8*I4>0|wfhb51=oHj(7qvMC&nENc#OW1Op^fE1XhZDC(Xfw<~ z0Q~lnzOlo?>7QZeW<+Xn6h9hkaq($ZPtXIWZD?(Tr5u*MQ+( z!Y~}O9*nvn??+<0RA&v?jdlrU=4c4 zsGC5Q`OxR)=%A@QsZw=oK-+${SSTxkCV@fD`hbva%Yt*FRRz3d16G8Ad3Pv*}9K|=tG-s z+WFG`#>Y-H9Op?d^Sa8eV|~mj{}c97v5my@$t;qi67vAlKGAe8dvySz00v4#xa~kY zQ>JVqucMusRZrLWE*#@{h^F9-7dpveVFjJAx9@+IE>0C4`+_QqjRD&{N|hnk$cN$} zP`zyM!2E#cKUZ(~kE<-;ZvZWQfT~I?^@hXN>m?m*V9_Y z@vxU2cW!RZhPiD?WIg=&Zubfdw)#ATHKbSR zK5F^=XB$(~z7>VTZ1~_NjFFdv=RZq`A)MN)O{$`ES&hIQDi>_>i0JOaC@OYEv*%x{ zqi<|h0^5~(5XuY&2Y^?XU^@;D8eqrHr0HmiFqrb7!!k%=u@j5i!j)MbFX_u;X^s#v zv9&7w3(xOu!=gHbyONS)%r`z|VxD(LE)dV#lasCTG55YnihXK1V6k#V9CW`#z2Raz z%DU@p3)>RzLtESHVPz~Iw?agP8J~UrrS-x6$}i(!Gr~*KYk0%GDs{!T@Gfqgly|$0Bak1L{g4`7U)5 zKD=I}GhgHU?+2BH`me_7@gEDB;?~DXhnL=`1o7bH(g31I+XvjVbsLKtiKDz9aUNnF zR?=Qyak01u0=-`?|0GCf*c@GA^o8=@j&RhErkXZ1Nn0GlKKtR--Zo%&9Oq6c`sHT)tcQr&k|X@pz)tL@z2o%|eYa3#+UV(9DUnGB z`q9AxBvGF~Io!}lY?abFgINBoF~I8(@9Svh1FzmEhr82NjS}3#v(3I@Qr#w%?+p_# zEk%jKr5{|FJ8L`L_1L~bj(+XPlGt+l>VK->$i;4*@H3rLf5wxc|swsJhjDv%qq;2VldDw{?V&lJ6BxPn1F_<$4nZ7k$VX4o zJ+Mv)q2fKivL!~ukiOkV%FYGP=FFNiD^u|F4np_&=c5CST{)JaWPBbIY5M$DCiGh= z5AMt0RY0PW%ZqLbwz^S}T51m^t6ajk!n*Hl3Hy%mB4rI6*Y|rTuQKdfs|n3wLRjpE zrID+Uy(jiO)4n{4##xcUcOk_}9bmN6-RyqK{Dy7iDcv;=@3SN3>m&z?Gdp=X{=suw zv^{Icwxb-a_~PAFJt$k8Myev3_d}r&FxLg`>)Og_Axy}#{o+9B!Tgel!Q@w0>1Z-b z7>3(Tr-wKKN2=Ja^Rltmhzv&1Xx$Gi2F=Q9(XBoTaX`ka2k@4Ou;d43GKbHU(E-F6 z=lmSh{{_)P7}OaVtLc+Z&7ED=n14pmAiT7I28fs-2o)R7gBMs1J~R3x7$<}1au)9 z?$a=@e<9Ut=-3c|`HplhFe{Q4_oPSn`M}DB;#4t{4=3Shm~E6y^ zRb?b=O$Svzlxly{2oA|x@XG<=lDA3+hxyNRo7LOA3-Gwa_0vdQ;C5Y_PvwfCpX*z9 zwZGu*?ANs8@ZEHYNI6F>k1%vXCOdd^g^TZtl%`)}5b}rg4tN6oLt!T#nEcd>I*lq9 zHY!4x?HWlvN?F~GD=AvsvKVos0NBlj3A%}TqcMusqp9GBnan-S#?3u_C&p`u#O~tP zoASSn5mOUw)DyxDMY?VzwIv7Ni~G?#C&gL0HuR%}RZsLGi)~CTH$UX)qp%)*@S;UyHD6PVHJt?8BNjh_&`g z%kkK$)(~C_=LEysSo$~SUkBJ6XY3Bb2ZVeCZFtfdWX`H!v-Hsr2TP` z#gpy^4$M!xrn+P7@qG71>mx8zcA&Vr$MWssT zE2Q|?pwsT=R58nG61HD~gw-HJ3dY&FQ3xefG{;7jYdAs=Ij4O_dpT?3O&lLiWQfcd z96N8+tNWHCWIf>4pbEAKOwGylBlpn|ELVM?z#B&xUfmD=4^bfB8-F&(H(TZ-&Gt!|H2`?L2rXl9l*KB3J!}WqF9l`jNRUS>_xP+|vjXnWfUxp=hy5E)A*Q=+LZ6l5vslQK(t-WbU_7 z(A5W$8DWf3U&>MPLB$co(gf~d0~W=!6@I(`E!c~1sO1C7@s4|lkp9!`u5ea(d;9^W znBCtA)*BX7;u{ccDq6dcx_oL$x^*UJ@! z#?WwN0{^B5j{8pS1$O{&(DL>3H4|tUU|^Hk__fDqO{XeBBM@F{5~aF_k{WM1QX12WiN!Ldwj@%#zDLvbiZJz@fHEx_#3^ z)BkvMYabSh+dYf^`**sM(!Q&4XxAIEI@KoY5`@_E?a$C)_b<79Q;6xbNJU0uW`qn@ zvlFvBfCfpH$r_gO{nu(*o+gtaVwk3=Ob_!daa`sYxsUy8%#Jtg!)(?zI+~V@jh{_{byV%0p(x+ z+tqd|BDo^1;Zvkv7BCBILFw6v`2z;+e`mi-@`E!L*ENbw8%6Oz}IhaHgQ*Fb>l`%VP zY3&t4`GgA#?bgEXMC==O&nHh(J9PEo;S=My*PBxkUA@e{m`qqUdu|n9GAzXCHDb=W zZ4u4jG=XVhmt1w=2&OX4={yrs?hq76MB-|~BoH((zoFe?mFOxb0p-F7>|R)pf0~>g z3-un+i82i>^bEdDX9@b0jhh0W^Ay3_ryk}7ZRBtEPY7E1`1A!WQ$z#AuKOp_5m=u3$8!U($O~8yrNL;K8%n8eAm)6F1rEX|HcKBtLspLt*ek@B=Xqoi! z3*(Vz&msex;`o-Eer0G}PDlSvcIS1brSHK-87xpS=*^7$bT>1uyiU$%>cMEthdjEc z?F2|S>v9r|H;V0S2+cZ% zzAm`^5uwMHsG$KGq^ z`WaMaF_NT{**8?20j9--_Vr?1PTfvYt+VaCuHf2Rq=D~R9XzK%Eg%~Y$anj?%vzn5 z9+}S|Mq^jpc1-w?1yS0lc!3_6f{9Qa%-c&#|FIxFo+-Mc?DIhkW56@nDIRlul3`)ZwD zdk~`iwPpP95mtawes-Pr50*X~CI|m#Ovzl4mNG21 zuZ4&G4Kb!cE{vnrgXS?T#6B4}IkZsUT{82myex#muS@PEs0*ru3(W>kJ5`V)qF$xH z#HDJ5ikenzPql8lH9D{bW{xD4@yGW@!RsCD7PCLqE4uG*Y}<*IYNkrda1s%Xc;=57 zt5jcf%rRD1Bvzw`-Y@98*k*ntt@OWc37r?@!5(c>fkrIBEBb(`T^)XaLAYh6`zjd0vOh28l3 zylTBiwnAv?wORU@W=x65nz!{2R;twtUY^1kTPjH;S_MFaccG4(z2eS}HqUrI-cHO3 z%<=hL0fM5sBRji167BxCrr0+Vb`zGF(dWK0l*Fi$dpekpv=ey}Aobe)992IJ)pU|= z3H6J1;L$=?RU0*<_MK5t6zDkpEb7oBH-7&}4|}+2Ji9w;G^-T$ z(IjSP>3JQZm-+qGk9U>)rC4_N(U~aL&nb8MFT%kbBnu~_zzKB^^XYezoGBOrqXnvi zGpZoQWiJlXlmX+E$s+yy64R|6Mjpi@h*Ek1Kgr+RkB%B1X48Lsxdrt114301qSd)c zP$oi74EMi3>EECYiBM;bO#+D_)ZOF>e zb355{zL5^1r`@gADYl)FrXeoXC~bjj5iNuH(6FgD!T3|oNx%Y0;E~ohA&-a?syr=; zB`K+@_{+@}j$cRv?~V8$Ml`K1%o^WlLSzW#ERHXC0dYoES(UKy+;>jFSgih=i6A2+ zW0LE+V*t`v>KH4;zOBumRZ$090k1f6{^Lcde_j3V>MTcoi=;1yM)b#xgJ&KV_p*Lz z$=KjZFK0TjY#QhAUF@(@2`I6XZ)|EG5e@m9+WWzg^ z5%XbRGzzyH!~ClqeAr8PFN9wqHIjXjVf}BV^bLaP{{!zEbllnr*}>uHwA544d;f_q zjoh&6OVx7m>MYUPj;+Lpkge`yc=1x0^ zREyldf4+7lK$P29B!$@tr3AWf-`W!W&*jJMG237=`ZSZIw)6Wu zdA7P8y>-=(g72*Yb0D$AC}_meYFB)>W0QqH{V&RMU=MmI$9O+GJ@c>^ z2-S8XUCr_KcnCgNYj5S#6N{%o4@ga+K~oe_gj3`Zr6&GudowTE#&>l04mJznsgTWM z&hY2=H?NRBS7{!tr8vc*W!-Em8SoC(T;dGW1W$CZ;)zzsLq$0v`qK09=k)OETQn z&W!IdT9-dP7ajAzO?`cl@R+_YNnsga_csRqG7xqI=tan+n_)V4l76LVpKh=pt9n7g zqA8++bk*O>6N6J(268tEeqIET@I7y%5a!0b(p^0!{L&nF|E)Z-rz=q4*mk}Q^WPq! zrP9A1@Z({U1n!KLbv)0=o7ZN2=T!X)X(W*c%Z-&yRrS7`r{qZ>SSQQ%7IWmxd5^oEYE3lVQ@?y5d&ih6a975F#nH)uLFcQ{l(W$Y6$;4^@jq_Bf)78eyEZ z+`@tI-V$5}RVzbOekl#Oz?T-*no+;+w|gKloQ9>qZ>;@MiFuUgQ{NrwII-h{^Wxrv z=y`Arf?OB$U84n*7Nlf$d2zeII4BJt>%>CQUAFMjsSa-w;{#bhDEs7vT}c@d9yF?q zkKjj-;2;T^UA}pfTxJNq$GOikaRe$B;x2+;P0HZ6Xh|xJMdDFgibnM919p)ZwE|!>^Lt`ql>OL-)%`z@ zE&g}|cIba=A5uizeV|BNHwb6Nt-S+BbEO)?WH4kNneQYiGSSGd`z{GD%cLpWhN&rro~{Tmxe|)x!u!@~ke5zC8aiR(K~69cv>( z)JGHoCVvOuijn9mjfd5p%J0>i5WuVWLK1>9AlR9jE@TH*_UA&Ktk26bz z^#jG)8$u@m+n_~fx5*KIrbqeIl0iP8%LO$!)Mn*D&M92|@3KTQqHL^p2a!K1nAxDE zNc}N@>JP6QY`86S9k|{{RhUXw`i`}OCT9rEgf6D@v#1xViNnl3#|JI12|x3B`l|Sj zM4A*BRURn*!nxd2|3NYmP_EZllHiYSr%x@^ai?Dz|EJ;Y;(PUevs5okx+zvN|7cX& z=t&;F(D~1NqNm`C(Wkawk$Y2@I;wFoyFYCETdjYtdjV3-5o8gnsF3D1Bw}Oj07OP< zSE*cQJyvkAfN>CxwW%kcY&IA-YI((=d{ZU}06fb~X~#C!36&RQWnWbA?)-)*D%q(? zs*YqgSmV8J%#d6D#2$M5z|0RlvmifobP2=_?b)yZ&9B_7+H8Of!#A$8=nhD=ewCS* zF_gp#k5^-fZZ2XUkyl5RhgV}D`An<$T>iUPN@NJqS@G z376?xSpvhUywytc!x*K>mjU)X2y_G7@Gq{mD-LS0nBf!>3^c{v-_6 zXqWl^|2A{nT!iQ{iBgg&(c3uGe^0) z^yo3!C4|iwUFk=2tSv-7kjBNdgEF9+rI!ak=xp@T%i{n-C&4HiE|(^ zN`4Ln6}>#|m0YYJpak#pzr3wOkl#n{J-gy3*}t$%s|Elc=fdqk@yA1}2}dJ0!5>^E z6OM((@KbFsh(UNF^VEhY1~(^b6DCdWdw+OY>yF1mFoeGkmLH9~g(YK4s6bN_nHQtz z%^;Vu$Yfud%0lR~GH+kSS0j`62a3V2v%T^IAo+nBgLn%`FmbUeBxjy4MJ>``aj`S? z>=fWa8JIz|a{fp<_4r^gjoHSNgkI5SWk2~+Wib#zkZ#JPvn6E8E%zZ4Z*|Yu#OzHP z;-r-B`WFmAf>mkpAI#DOB--cV|B*&_pQe1HZX0(T=*&~)ob&}%k!jV*V8bf^rx*;{ zOSLM&o`FWQAxNF8ew-oTc@nIC`~3neaHS}}vxP+0@MzAp@B(mz8+dn>xpPxfzOk{- zw#Lpw^({$;hpGda|BJ=VMP{8hdb{RJ!E3u#n6k~ueoBh00ceIohENAsNyI%!mwuT| zb(Di9hpK-(aMyfQ$7(Kn8Wp+?&wx9!a1F6L;?wc6T@H}L5#_s^nwGfanRIgy5XrQ@@o8@ec^ zg*9*kt@0@A!4e#4s~V8NJpO1>9XKErQy!?vXWBoLJsz5zT^PNidxB6J2C9rj5)S0j4etsG zE?a&2DpfVo#4uBx8M}*hxRKljx_dmg!wP2&4crptvF7IH02;~v^u{;nP5rHosg~c7 zW1Q2~9EP(O_CzSYFcDAT$3E2+vaOrZ6v2$18|yEwV1$OVb!sMSKR0I#Ei3kL*S?MnZ+4rX6vUul zq%4H~`UYECWFbLZ_De+x!h|txqNu6QZA-3&zX<782J6f)<%B8-K3Iu4Zo+d7)CABt z)omQ!gBT}EwOA5mSsW;I9?ARYCpsuvR`hBoGo$Mik5$oKHnqiL{GTNtfk4myL)TeG zMfrX4p6-sJyQI6NySriN4oMMk=mr5LB&EB%yQCRf1Sx3|6p)7d%`en2pWWty9S8*evA8(0!hJ*Jp zaN)&BFV;6Gml`KU6S$lJu1$4$6cl+{T4*!(JU6=C-_O1HL}Nw^4tPM!;)?oB)a8?z z6b{*JoWGT+jdyB6*M_mhWLU^72S8;2( zltf4vm7V~MS)p1$Pl-9b(W74K(sAqY!oC;d#bI?Sw=m8*$TK}O_0<@nOLCu!Ev1L* z8&a!Un#;O;5_7-0*2%sE-q+<#Qpgo5jDZp6E^{>2RMje}%xng~h;*=cSI?DhP38-h zPPeMh&r%N33r-aBhOb;=jby%as5-MW*uqrpKw;W)^&yBjj!>dGVuZHN7{8BEvd+F+ z3Z#77Rp$|IgY|InZfYAOF`(CE(Y<- z;=)yF!d(xf-2Va8#Sp6_^DvaOl-T~ocA8+Kw^E_mZZ9eCkkN!xeTJzV2bfJ77dbfm*RbC~0XrCpd z!Z(Y{P<5$klVra#uD&sQr;u!$5WX^Zqr>X|DsUq~555cRpVn^qSJI7!O)=k0z$0BS zyRWLM?G1*i!enWxue_LS;a|;H(;BC1wiZ0%*3xk|wg`$JXYF)jO-+5tL619UqRa<(}@Z zG3!57e6BU`)Xi%oLDOcfN0v7KDT>5)Rb6mQ8@dq4PO~)Q%aOa9r@MtR=&T%I{_C~2 z`TCyB^4?AEP~64E)_uhKtX?zSUcz{YN@-8yW~S|)@K)tnRYMf(rr5qkCuh5Dn8E3k z@UmzKJ)f7jGZ>W{RH5oLnFAQ4DmV z?$pDxhpN-hcdG4FBQ2($$Htk7djN>`n895)K`vUc-wfC>G)q^z)ze+R{}Be%hajo@ ztgbGuz)iQ?iyiN3_Vm>|=+v3l4Z{n?G1lr6eg`z&SRvt&-Rj z5xo~I`0q)&zulspjSE;;CgOTD*XW;g|bXzB6NI2sUFIq+xO0 z%4-CDoJdq-+(Vf7Y}jp5p*}K|MJvNB)H%P=gL~y18!@^~1p8bIgF`8e1VI$kJCvSN zMW$v@^}a(Cl&gAHsSKjo#1g8&nfv;)PCY^0Q)0W7z{*|R2 zZ)*Li^E8o20|ac>ZT+dtPO>C6b83XAA{m75@)#WNW^=#)d^>Vg8fD94#=f(cusY%7 z$5Be?cj0C{9&dvt0dn|?7)CkemR67+KHu+p~ zyxA7Mnagi)w;W?O;%vDcn@ueFw7%0eR^)FRO{~$1l2rYd99!u8I|!PDy5+A>%7i*7 z31AyJd!)J>w%9V2GM4e3+?r^{90mO#{A<0Mhkgv$e$ZviRH3Ugd2UuvZ0@a1 zqv9vEhPa=-CIC}nYQHb=XqS{SdW*C8>}B~H{CM=oOJViDIusqbs%Qpb*KTBK5fwYO z`9)BOPxKxgO9cO*bF}Xl15dt^op)9+&k@Nsk2T8E%d=KJ&LBUIY2ga-L=Q);b54Wm z{jG;p(HPBxSLi3kIzXW2u)w3u#WsrI08wkNDy<$Rc|H$X@d3!CqnG5fKGH7)>8fHH zj$^9N%fK0M< zd?Ig-M_dn_1S2VziuqIH0}yTPx!y1`rJ9sxgKc_NXMH3^fLc97v*5@6NSEI!td2dZ zBm7iaVSpEZ{UjWpDQE3#_!!$Xi9wWgQ+m3S+_Za%IS+M62~)Y zKS#IZ480qzwjGVz>hdwIBpsIpW`cNfcJ=WguU>m?e-0Km+bs2Q@Aw|i;vE`pHgCop z$Z59}M~O=B#>(JdS#rwL+MB#X=V^khw>2L97_gJlNnmf}JDPUUm08yIYKf5gh$xa$@pFZW7Ug5(HuT#nPcYhcKNzJ;3(8Cd=N4Vxf| zL~ZmZg>7SPfASm@O{pi}fJB)1@vjJw53;fX(mmc3s9F9s4fPRDOY=1E1+3EIJ9q}= zD(8G#AXYi_hk@Q-`R;^a;YyL5AOXbhl;naSrvth`L*$D zoEmF-94DKc@O?Mf`DH=EJK?-mDS54cb%lpY=ov>8q)#8u+I0S|2W%($H&MhoUhKyNUFOJqe#=4{qjYKe zJOK%gx3zE0X4LFkJ%h^*2SX3aYIBKy_dUmd{j^=_HeObI1ZPV{Gc1AebdNOm6-pgu zb1QZIpqL0X4#y*3B$yaEk=oj^ISx=!DS50ybC3Ohe*Ktqx&1vDaj6z=R%bXWDfr8Y zxlSs@I6^-ek3#9LlK(5JC+p3ZSxn^dp|nL0U`ZM@C-ba|22gW`(&P13kNyl3G`!-i z>TWAb^CaSBv*=^OjjYlcpN$$la0$rx827Iks7v3mC=6HfaH_#Yj72b54KasbGzg zefrcgt$;`vF=n%%i{cJOWL4M8jB?fAMP_I#9zH_#g@Bc&? zB+1>|qyqjd=T{6wIGM9iiWnjvQ+<%VYW(u=@*gkPz21EG#ZtY2G?gut0})h88zg!_ zGRtyA7+IMYu1+tq3sRT;6htOOZDHOMOh0O6> zqA5(UC0Q8wMYRZC#h*jIy7+gAQo~|K5$C6(B1+6(;-1=9RZZLtR77Si;Uq`tIA%-9 z>W=eN7>|B`$^d-%$k+;SF50CCX&&buLl@1!!NykcPGP7J8K*B|(^yGUeEM39xN)3&X4%l=s-HP5IV}eI_oSFD z4=MGDCnnZ(>__Tg z%dB2J1uUC&tMR|mH*|}m!sGvRgVINTect->7*Cl|z#HovNi~HCFEVaAC<* zer0@4y9Rghx77^CsB~awqwSh167dW~YYH|V1vu(;7$&APIkm7%QL?uu?*0Sxr2Wuw z-1NRe)gG2b)-R9G1~y;&5!iA)yZrTv;-h~6;?idO))6yg?}p(J<-}2yf738gyV7?! z$$tKN*_ti=b$$I)d1mWR&ST0|+#FUCo|uot^OCd4SZ7ejt#B zQE|nh7taW1U~9s(!CMrf0Ew?y8(037$&Rkj@3A$IO$#j5aVhL&tZ*8)DV-F?&hM*n ztB)lPDGGVQ4qUs=$kyY)h@v5ab zjZB*=fA{#O>joRjg!Fh`=eu9$Ha-pUo*eZ)mHg@Gxz)o9@Gjis-si?%$V+^8h&U(- zyJyU+Nu%{4i8MHrV#c0z4L?^J7eL};`k+o<4nwxGji0lP(R~zK@$^`G>E@z_qNuEV ziJBgi36?LJBBK6(&icp&fo#ZY<&SYWl{p#u8MckOyeixN1Uc&BE4#@*^jV`-NV0r6 zMD!y}@&GYqN%FKPNSrtonGb-XsuY{Mt0baTxPi%O zUkgCpp8ZbHhV3Hs#X(UQ^*=gwsH`*HQUb@|)yvIJPIn1PXlPbB)IJ@4pG*%HMt!=5)uxtmPo_ z)}+xBd|CLldE)-@07{k+s6@poG)HPf{EEd);u*~9i3OZen~I;xkN%JlRv~~svnOWg z9~&A4PR(7{Af86VQ(9i;o16^f20c*l65iE_w z1QKq;tx(ucV%X!?Dt;hWDGan<$}`ka8G;cQe3=oj&v4=rRse0=h|zODVU6skmTSNn z(rKk8>)ru&F6*pn8m@rWsj1AK@KcF9G@^Zy7YzI0p4BWL6wb9kZ%&$$cs|5~MacBZ zNYhE1&>Tjj`K6)DeN%I>J4gz^H5p}ew%xHIWoFabaN3m|F~l`gn|iC&J#Lrytt^zNf^ z#{|GysPfGi57r*eWCCdGKFlEHaXpQ0E)E8aX(R0Q_mflr$R4K&&$H^;#dKdzv;Uh0*=AY=gTWbC@R)I}O+N zcfcf@kQeDQ=$Sc^KxZvou}W>P1&t&zD#4nRFbz}4T4iDO?qBEMApOar_Db%!k7N~R zYmu;vFi60PHLNf63Uz_jxXfUa*Ce=}StGmRO|}%D4n*3K@&2=$EWrwZyiEmeOz?dB z-4k%RBy3Aswh;QlpghD(?%eEP`O-$jJA&~uYPuz$)n!@r@uZxyMs|0VR{yJVynYF! z9wB<}`Uolq;g7avL%xNi>SdcE)1L`ljD2j%6~CP3Uk*vt;9J(=2Qr{rsb^rno#azW z*Go&suhaa=-;+ei#?l0ViVy7Yzc`Onwv}$-DGK7PI)o+%oF+~3Pch$UeW1vIUBEvk zt~S^6&ijz}o5K@438-3aQ#^O5!IHNJN;Od-)W7~!qfGEM0&adMQkvXZgq+)sO`Fb$ zfnQx4N1v<4&p$rs#DWr8zT0QMM|>GeQ)?TNtdD*PfMI+j$|PA_?tg}51>9_G*2j)R z(gbUEgx_*eE+S(^JII+|e$dm*cwnIpF^5WQ05VmqRPOE7Hd%?e=oir$A3BG=l2P1W z{!N>J-|N@8LAS$+Mi=w6SP5Wgc4#6`UahPRdG=F^Oq)*^6wyii(BbnJ|0JiyvJbG=%?|n2y}J3kG3ML;f6J*9 zB$Fxl?OILXRFv-X=$L)uwVD(PC<37R$cPAW2gVsQ-LYP9)gfw;i4Nv@;y*$Rg3*h% zn$f54nk;}9`(ibRtNXiYLyl0_%XCrGP<39&@A{e>_Ro1C9!gMHJs#68!aNRy#`leD z1OuKNkLi*!8~-@$!QwD~RrK6}q6|AD-%zR#GhaYyFeh_TM}MR;i;J_-I0ZA>Fm{$8h& zx)W3fB<+9$=vPZw`Nrn#y7jB$Wh>N&Av&0Lq|8*>)rqy*?I!2!FSPZ-Gl}H#wF$F@ zpt5|mh@Bw&0F~4YBY1KFr|p0yi<85qJcft@C?fhLgQxKZ!IKB@mXh2S=BvEfIX!H1 za+QeL)2CjWecq*4NbBYiB&YWxRDE%)0wb}4x@vObS&jL)*5`vkp5E>JVCD{6E=uqi8hweNd zl})wpto@d#)eonk4E5jN%=X$y`SP9>ppf$dD z^Ide&lPVkE{ct035-)NhXWR=*BZcScGxX*da1SnW&8zwTvhj*s*rO&m?3W&I5wcTS zw}x^LX=EZbm-@BcmvJvh_AB8aU_SpF7;XIt{#oeCKiLHHpKckdsmOAPCs({A2jsm` z|7o;Y{U4XDyJS$2>uTKz$yZcj6PI1<2K2ZYCu&(z4FFv3`=%dj8+^dN!Fx`3M;2|p ziyVC5xL}6i7?Y*(wyWakpxp#-Ciph@j53S*ai=s+w;doL&FerRjBITqBXZk*O%^#j zmlX!bMbV@-+f2!xLHA?Rd%@T@6Rs`Z z3jGHRwj>hostuHLu^{HRxr^^3@wl$s@33>mB^nJ$hk2lQb_-_TuQdhP`7ZBu%Y+3_ zo^;pRuVd)Mpvg|Vk^yDA-^=ECPk}S|o*NZtN9STelo<9+umW_@it?{DwV%Vt(Seki z5@1P)EhTptT?>CZ+>^3r>V0^{#$O)6mqYsW_{5UQWiEZD|c1tQyx;Ytchz7T@hgu`_ym$i=OeZ2pa;1F zIOa{@hk1sbKNNT}t-{|$CFbdsD_+-Z;&KzznzripOFvsf7uGs`%HO|p177;tz+dI( z7#eY4RF*eic;$cOTa&&SupGn9eZ#q?Q5?)v;;hZXaT1Ejw?Q%Uz5-fElkogSQj2b; zrZA)~4YFUN$5y8nrlx@T&J!4oKk(Kqj0{fz0>>AL^AJ3=`$sg|dLt}<4Z|--=flKX z9276QeC%c%kl^+4cy2b`#N#7PM;k#zdxyL)9IpIz3A`bl7e7A_qS+<+bc?n4Z@Z2R z*ks*xn|GCQU(tgid?eUJ8(pUKzAw!f%0U7i58PQ-rD7f~+D8CIJzSm#+Y%EjRw&wQ z?#s`_-Z#=lPrSVp(N3`r4_A4UEP8M33Oqiyg{zgxMM95fx-z6-4(`++(P0YJNN4M< zgd{C49>DRBD+Q11oii_TzNaf1z>-vHzKt4;K(D zmZZ>>b0^^<%w^-TpA5t~S7X+$DQPD}r?PIC*r^sw5?v{9v60*XDQdM6#%^VAK93*T zuy(3jd`Nlqxba3={5m!Lq#eU$rtjGuJgXd`CYisz(}J$DFqV48myYtq|LS-RfK{~0620m^07b5V#J5DZN^K16#WE%nM*zT<&R%I|!eCR;dD&ZOn!!(51->NKzHuXogqHU>F;995Nhnh4UT4ZEbX(BqC zD`EBFtv_N4izPCc`;MfJx2xzXK$7acRvX1dma|QoKe-ccW-YlNy0dK`HIlx<3$t2#-Ts>FvM0|YH?~;-${?SV*9YLKG z#0~!C+O#QhHX-#0dvy7*zgQA&w}o#y;Gt)(ns5!N&)D(bKj?pNve28Pop%Sow|=-i zlmtWhU*DRQBpYD&A6RXftG7E92(xOfZfpYi^W2fGDBG{yJIQ7iaD3u1N?dy|$~~MA zs3hNa+#_e|dQO0N-+8*r>f#LhPas`MK;>imILqhOX6W8pFO|$r`eCF11)uSMPm4!0v`YHkwp2Zd4;6k#R(a~ zy?6ehXZ%DpG7cE5sbW0nEx^*tIuBo_)fx#gi=-}7@pf78;lHQ2t@-iu$N`*#60q>y z^Mad%0g$_pNWDC_11ZR~>+Y%u-xQb=)*E7kO(-olrUqo98tXYAL=5i;n9BP0UV z0-nUy5%1^S=?SB(XSg?LrYhtoH~m*hhvm_}7y$0~>}yl@PA>AbSTo6Bxm~(=Fatg> zL_e8YVu^boGE9M8riiExFt=npZ?_r6@Vg-u*+ELT%5)mwKlNMq&iKI)rwlS(6!y$R z>BIMQ=@Bj29RPSOT85%yCKwKFTfbaXqSna%bRZQ-oNEKjc(#jnmrP^VUbt{Vi#S4wWj94cK-2L~qy;vuyS)Ug_V>fB&)IxgmU;I0N^L z63&d*gIAXI@wd{vBm#$<42AU8Dk9G-0-cu{Ju&3mTYX2sNHuesY_7UiTdNqFZPwlO;+x3?A>UXKHJe|^+nUvQf#2HyPU zgyF>R2Vi7<(mf)=;qA91DpzFNd0M{=>@H^&s9*qU>W?v4Nm)T@=Sh5o*j4_J)MRnJkGzrNSt6WqxZz?EC#H` z4lXY)gCz$`+WjpaLR+oos-HR(z8^8X%MxpFvPW+x$BZM^6Y7aIWLj#_<_AP4qOOBq zjKm8E<6wyO6M}lKC+lZoo~TdXR^_hF*pW}SO&lj`x9_GW!&kEne+-&`MiaUpY8;Pa ziQ#Mo{SDxY70?RIq2w@ij*^|5IZjq*RyE!1@#7}JJc}DSC7S+i9)Ot_ub=mmyT)DEf?Y`cs7DpKqrB(EnG>AP9o8+NBq7Y zSan;p4*g_CcptGhV*WKt3-vMSA<`q!DXOMKeoopNUOkhzcWNCTK~FFg0Suj(F=v6G zV3`f%+yE1*{Fg}>gBGr~gmRg}^(Sz#rS$l9MOuvq4pa4>7LN}s z)hicmhxR?h7IPyQ35G56Y4$gp7Yzo|pW2wq1&DzKOLr@YmBjp$J$g-?0z#yhv82d+ zg-)YqHyD+K;SVJcXVzDU24bN_o5R-NI8K8^E ziE&7v+S`GW=FIyPygIZ9O-@X6HM9LR(N7tCeQuKV>hu+6@BAMKto z%yIcDCFH*MvUb<5nWAfBBK1cZDX12s+;Q&9>j{=ru`A)1icmNkdP^h&b@G;ZHe;Ch z1qzfPuj4Mj?k?&myYf4&Hgk3zM`6Q39cVlKZI5(@i0BziPNb!pC15 zor^}+FmxINS$qMh^mqeCP`BR;0_Bhb-T(R7BqgqOzt0wF=ySj#uY>PO*`~hldk%Pd zMygw`FXVh411xY#;JaAdkNJ7-EqCE;^n2Z!i6n>$_RimfvAQ3fy%zmxS~0Rnh8>k| zOkaWXnhhxd4(6%!Dx6#ekO3}(o2))k$}kb>Z6CarIyCF3jmi?&Ze6Iz^Oh#Qo`%rmC9}*M*s?(aBj+W^wOg zXLuRRvmMm+A{v(=IUIFHeknPik?S_Tpx)NUnTqxB6aVz zN#j|>yDxDv5h!tuGUGI5p{j00>?|CniNsf4fSyh3j5mEUTxkoh{n;wl;Op1<+~bi) zC9n~zIIvO37{oA%T%Bjb1-{M@%Qm9>?1g9VlT$025|`iqvQJ}(&kz(iQXO>_v3XFT zwY*RugP1;vbM&C<@)oOZ@S8Q%#(YqOEAcZr; zKbPQnKV!iMh7c#-mre(Bh~ZX8-r<|HWPY+bNNhMo&DyoXh)Q*WX4I`BWT2m$RSwQ}n5 zL#Si~XX*8&*u9r(swdQoO03Qd##upZ58q!S_!->G%&@tIMv>5(3hW^lCJ@ew#(`*| zRY*WacuqfFZv=h>DMduu4UOn1G%~iXG#fO#cnIerDAM+?l~X~GQu=10@L?X5Kj^4Z z<2%??NK-DbsrDkJ8s?=2+#92y<8rNhNw(1vbgn2;%byw@l3UMVYd80ljX{IMHmh6r z@l*g*4#Un(5HDRjl+17OV+6t*)gX>>|(wF0$ zJ*fW*a4uTo{TBx6-5>Vy!5#QGa;CAb+|$bOM8ptI-TweRI%fG zUQp7>N@hcB*Hzk6glV!4Jg&0VIc_A-AfZ2v-~NTU19PGtgDH`*j4Tl4)8B?gj$&0c zTnBtSN=Z4Uk33abIuhA5Bk3zBF=)^}9iGY{0ZJ#Y#QNU%uiGvl04GXLg!HQ9UoY<* zn|ecp*}H$Cx<^InNL?aPwFdZ^S8ae4*oE8T9Wnd7^Eaz>8#qCRGI$UtGv9Q(>lOPM zSU@)^W?eFN_1C00ATA@a=pj9e-IJZE=$L!0qPAN!#DB63(9g_-ivOcbLnz82WHe+Hx^GP@ zduAu#ls=q3k^uqngfz`65Th(pr}~?=x};}&dI4J!s-&>&kXLVA?}zBT_H$%kcO9n~=Z7nMb6Do1&>Dhc ztRm4HoSJ()BpIZNY_@;h*l{|(49cCL*}?`HLnblD3v9AbRQ3v2F7%9a%8GJeWhgYe zYV5L>FJY2x0Hm>O`#2+2s}ws3nipm#S7v&TX0}`0m|N>yQB{Fc9)6Kt5ef-$*hDUw zZo-^VW~DMVj@49aSjc>JH?rg|#{a8!7U8kO?UZj#MnB71$LCD6Sv-_#f0&!Ut!No2 zMJJ@_GH&!NC5g=e(~6VT$#}|5WpFODOhx36suW{2@Py#@V6DxMPSphXL4Im@EizI+ zUAnBOx%A^xFc1cy+qS?3U;2Xf`v{rye=+p zLyA>H71&v%@vOk0uuHR3nO8n3qx)_lsHtal;9k=+UXwx~@3x|VM`swgQ$sPr5g**b zq}DUzNy9uagnRW;cyK)OD_zjGFtAokyF>CsQh@^2->3915D;h2BK9j*7uLA{0(cQ`ScI5FP@OcJqAmh%LSPQTpRMc*@0kL2cPfdDTQb)!bdR8R-RgnTdbHU{sj}zX%Q*{QE109Rmv@uR#Xi|M{AD+@yW9di zzN#5okG57dJfQ-rtGt8T3-skj8Ug!5$)vz@g@|NEdqj`kBae6z_1Z+gm596M#VMJn zsj#Zg)kz+(fjXh?)xjhRu>cypY+~6l-eF)7E5Do z1KEzNpg{Q5AZ%BMqVkZJXB)s1(1lyF=Na2?N-pG*BSm380+ zI+ZOHBf4Lg3AN_duGR^t3NL{r=Obv<4|yl-9XO|nc>2Rv0Hbm5PwTH51^w6i*!S|{2{}{qQ2)jLsHWBn zQcpv|=LB$SRA{Z4aO?Pp#>OB|u*3Y({RvO{UnOlX(#s(Slj?grVcftu3}S9m=9vRa z7Q^$6ihr3rNW`2x0RJN&0ne7s6QCb23AwLG6R$AAhWJOXW5$r|1p4UBAjEL@<@~T$ zA$2rvF%RVz%rklpjqZqT9zd`@?+2RAt@Yb75gK7n%_XvUMb#A_L`kD%2cKLWy53i! zygWgGHiQNp@)t65>BaI}%g3g9={$(MPOggh3vjkpU^#da>2nr2@^KCL#_Q5!c_tC- z^UEI@XEu+It3Y#=^0@qsTcc_VuNQq@&&Ot)$>uk)#LGD&zkB_Lv-fN++wyj^j80PULEgU8$26G1RMAJk9%S{lx3P?2MUR1i!OJ~CysW;zsBawpc(QWj>Hwb^;5cY#vQ#(~rcjCdN8Ku%D`6t@VEimTStbOQ zA$=p>;Ny+X=66=Vri-%8>#NE~0i0rq`1yi=Q;u?P-cb7p24-k6MX>;?Jk#oMNPadu4C0l0GhI}i5_!;K`2_L=6C`E z3c*d)zprqDN2(rNf4Er7NNZroUe6C@53pwACLfF}vIH%+XOhh2>dp0x{Uf6i)65^= z5;%M*=A2L7F}Sr{}w&J!tngIve=Xk zILMf{G`;NVLI9zd7JX#`dER1j)>f3HV=xP-cA>#3JuE%HkEQK*0@sEi?kAr1QUrl3 zN$&PC$@)Zq3<0^hdjywUwC}>Xa{RIDE-ieG#$c)m4|;dk0dx)E>xcgAcpgq3?V4+= zXoiMYNG(EnfV0}`d^( z-+!o01G4(x*ERe|RO0no;I!IKv4V48)!<&MqJ2T%O{@lK9;`13r!i4E-+tbmXq9O9 zwr07~sB`}M!-}*s5S&fm2aPAJQlL`>7-CD^@S!1t=_dQBlj&Ewsx223L$vyt5%ZXM z?A!_5T!HSj?>**2Isws;-_q>=R#S^z&i9gR60G z^;bq&SN)>B&7-zP+n)l^gcHL&>4I82;#Pnu1G7lsz;FtKqN~sAw7lt#RFOVf^o8ff zl2Te=J|vP^+6}*9XK8ESH@856G;Fc8v`zELE>YOHg%9N(Yd4!69~n&^vIsj?+hNzvBf3A@(kO`%s1ctW&#Mm$8KEeV-U>Y%ggW zc)U`jkAa~`k#&WAoO(`Z658RvZG#p2r3&^Okmw1qK(&dBcE6Vk4^(si$ZCXzeIqSm zc7`HQiN8&YdXsAvPs_m$KdeiZ$%c0M9s1gzhjLgnbFoWRN4FjG4ePWq( z7^y%?oRH)&6-BvZTriI#IwpDhLrf}7tp#qVMePZ~;x+iE1awp!XW_nu7=6C02s9_s zpQMs1ipnOAwvXIz(s>iV^-}A=HT6omS&+jycW9?FdHVP@A#NvLZGT-pOIIyv;XhJ@ zH|2P2>dO(~uZ}wjrdUmpAgJZn84EpuHMJ{B^e8$WK&@ImXfVMk3cCRgk2RLq@Z|&M z^g`I-eOM)T6$8}zpOnsaG>(Pbp>m6pA`UZ{fZd=E5bdN_?E_LCTq!uJ_}RSP3+4bU zlq&&ga{4Gv^mJC!14rL0pR_Va7xx+BQ)ckSh87`F_HQ9Q(H|vdQs?fy#XMFg1>PFn z@==nJr$_zgpPgfk3=7G>>GaYNDqWK@FM<`?fkY~sJLKl+-56O08LW z67w)*4>aK@QFS1PQA7)G168Go>&GZA=m(VitwxAQsJn2!@Xe)ug#(ZaQG!}WslZ}d zW;-!P>8o})`30n#umXhp?kg&_rw`uYCg?oTY-mo3^7+QO(me+=2`sXSo~GecVHkjY zcFHkF1QXEMrrLhp?MDmx-vXJ4k=Z=)WiW4r39^L?Y8Vk785ug=+)Qlf zXS%$6LL{;@lJ>>0GLJ9aA9~Y3^6h5*#RUcVm)8Y8UE0U1dgNvVoFx-z67J6*yx|;2 z#k6(89g2waYYc**gsq`RQSEwCcrFxR)Y&rp$gA(ny@ENC$1ncXJ1EX5@~Jf0&v;e8 zu!RuMit0{CP443Gh%SYIc$_Y-%hiIlx{UE z-qt+bNU<)TVhZjM*84Y2yv+Cxd6Dui%k5^MFT&=Tp+4bzumJeVO_Din^J-IR6xJN? z<|^K3&}FNyS2e323cn@Du3j8@Af;aYGe#f|6!uwsT6gXzBB&NC?3FYJX1)-}!-C8u zv>CmO&O7@XU83=^h(_DPSTjY9joiPB)=T+ozL(40T0q!O8gh8K67-1^z(4Eb2mE1O zM%R5DfLxGntcG^;NvC)C;T9I*qHM(%i1@AUtuv6tDPWBK+!xQEs^QIQYMqUD{oL3h zoi}YVa0=&GKTm7jyWNURiG)04PndGZ{4QtbH3pDpYMb5a|G9OJXAx}B)t?s5=Syqo zAW#6lTzGi=NAsF7%4PeP6H0bWRsaJ!PrifbSRgM{#}LXlI-2;i_%g5o@je}Iq)>?x z;R&3kC`F{ewmy40&uh_gbdJ|HH;PS(r8ehCjO23_aOu^0NW~M9{D8@$uhD&d5t{uo~3=Jw&FlLPW4M!v%$L=RO~L{&ke7nE9+oVVlYG zQYc8DDb+)l$+Qgb7#f9CT8zi}owvEnpzcUoz}Bwx?S9NyNdJP5HfouCk*wjkT58q@ z@#i4jk9ck-M&c|~F201!9WfycxznP@S|J)*d#kR$T`b1BfrgYYf)k={X;Z;L>K~=@SX^~!jrfOx#UOx$uC>J)7&3+$KM@GK! z8LBant=Vv}cyZg3Vb#awS}RBrk?R-az-VGNMT$&d*`Gn-Fl9yHH)RwpbSE!FAeu4M zY;6EiGVQd+yO+C8Jn{>z_x1Vjs!Waxm=SkwO;bZiV9gsBg&G&mEVV>iXE6q4ME;Br z8dQ<`cnszHxb1?rb zzrN?Xi}6u2z`;7n)Rb76&^CtmKCOr+6<#7asMLpSkkl6aROpD-fDE=~{6s-&0}ytg zoy!vGOnOA#h|AZF8~a+9xo6K-r2DgB45JJMOz9304#~|D(-w93g&X`5YsDM*OY-m{ z9BU%;umVg8ccAM@gU#vf-Ekb49TkkBVbK6=53O&MPSmj(4SV~94S^Pqt*@pBl?tq) z=3n={%QJ}e9rgq4SplL3d-V=|VZc`jsKmR}XY35eRO@TZxWIJSy{6#zH+ro4Z#?4P z)+ygVZD!l6;p-19BHehE=BU56W|YUHMEh7P1f#;+PCaq6lO|a67%MCaX{tX#S5v)h z%(g&Df;Drv)C4cfryywOCZf&K2h1g?4UZWT#?txI?cpxBR=)!=HH-LtrtRpH?V;)1 z@!LPk?e8!aj)0v@-X8-8v~H8;d%GKWR{iAHH0RSeX}I9Bk*1HRPy`P1VG!05e4uk_D{x5#E9*lp)lWr%3grE@ zm<)Mf7*1o+vk?ElF3^YAzLsq^ifFUo5v@tuVdbI4muIK$d$zB7fEARDko3dWzl^`! zd)giqp}tl2AFaN*n4sCRK>rT?oJcM8G=KU<#QSc-yLyc_aQoXG`HfKE5uB`Mcf3z^ z5;#2(3-rbtoEhy)-~s%G?JE)m}!APJ{nk|&?QbzEbD*BVI;K%&{^ zTg^{Q9X8Uu9|tN8l223ifM|%(IOOqK-ETxnQ--{&5F~U}nr&(VXvzqCQIgoi>Q~o& zyDLtwb!&L4#|Wo{6WGVNNnRdSh4-&@W=rr%j^>IU{~$6?OV|XSudn1%cy3cCLyW|Mc1%=K_&v7t4N*3M*6U+S z%<+%Ey;d8BB=1KxMQbZNZjJ?ax0tW-ZNY2iBB*jHitCPYxa;*%F9}HS^fI#W_!so1 z!aaTEM`G(IH;isKeCNjoE$TaVP*v`@c#yn2Ni2tLHC-SwzuI^w2LgH=mk``8QeoEn zErKkRwN+PBpxrpzdmJmvt&?p@>kBqhk0+DwlCcN=CA8QU=BnRDF%{!nNi>O9H+bc9 z9}<$946nJBs9Cw5rd*4jYLsg8=@ugd7GnFJGiZildC?Wut)QwT$Jg1EsSYe??DE0N zsZRKsGmz3>gC_L}3|e=eL~bgBY7g_ULU3isof%`DO8xeCc^aHbF+sI_7dh~HBkLOQ z<&%$?O-6BWoj3<+OKOwmi z8}q3=q|uevYd{nz8w@M_%_esMs6wOXj%=qzyGLHf^@`c@vL7_(WZFTbzm?+&3@+@C zVpf*=zdz0cxFhiHMg7e1NhTLyRfH#w4}rXmIs$)j+krgGB}?^Z8LGn|qNMe$w!S zEm{ymw50*wDqts5T#ZX!41h6W&~Rs>K6-XGX{qH^Xxk!mL31@m1E z$r2V$ETzz$gBy{ZrE9LT(@7Q)g{?FZbMZ$$M$=*waP+fN0QiXpM=tP`)}h+qc@!zE z+9tqZ5^z3|4?T7Z8MiDTCm3eMF5=TN1GNQ+e&CK~kv(S9z;&6^v6=MYFot3!T5E(^ zm8-&(u`uTL`EbS~=a0_2SIWa`GgWEd95zVXuKc`UBHRZ9{?AkWMw+iIa~;^chBR85 z&_H$yQ)sC`{5UysJ?vok7@i!8F|KRdDoOUt?pKoG)h=a(S0_@~2~Wo;6E5Hu&1(sC zcy9Y5hmD1p`{!ofGEJcLAi}qpa!XjVBO_fB7za&U{#d34b*26l+G-)hPkc+IrJ*I5 z($`eTxYT99Whgj8U;`^6J#Pdvn)buJMNR@N#@M0_ekH{-lL4E`-}Lqi{&RRgCdFZD zj}(!3*hdiT=|(AXZ8Qo`{7JL577)ib(3%S=cZ_Y_^@tJREY-Lra1&(aQMJN))mOOjz|MPjytMlT#g_&RM*}2xbz8B17@Fwo!38~*! z*XOyB_0);Ejxt$DvcvYoi~o#e=IzsKT)yqJ?{PMee1QZbozdz6?**2DpN9EY8%6)g zJ(C8SMDT&;lYwyHG{+x!m@00M`nko7!?(mWHof>+sase4)4EpNv%^+J-tHd)KBZeK zrg%4r=1E9tFk4%2lx{mZ3Bwd`_g??S!(~Im<73(sugr`Q-*Khx@-T;l)zpcd_9|bg zO~AA_0Y$fTQCPCn3#dRHGfe zONSO=5LESx$l+eP*@F5nB$Jexm}7STXGt<7jDF-Lbor9gOo&u?p>zhhpLPndi4nSK zPiftP;aQ>2R9?JG2zT5$?r9Gh{Srr%-Ofip<%APMfEf`uQIb)A&6~BMX$wYmD5qO$ zjL|#Q^7dhA684MrysmISJ`p!m)8Aa0`yM8w-ka)?JA=o%080(C*nzX6NO@@#m)vGL zFc}P~^nf5pr*{wf{q{8&T`>@rd)`N{b5jK>yg2^Q=z4ev-MPS_$QHdIt|a9AyT}iV zx|X#M|25WYB)OF7)Gc+v0+|a(4{9AcBgCTbPv_h&g8{0{`0Ti8I=i80Q#bP(Dk&@! zY4{AIRKd2%J+529`~8#Wp0W%&D#{@MTg!yc#t$Jtd*mMt43?9^R3F^PfXqxdV}{!n zoaoESXCju*91{}O$#celSH)x%^6EY=*w-0H-{Mi`(GS-*y^+c2mZh2Sam+?&jD|7ysya{p#WlDuzdM`EGwp&J-s)?U8kcc={P4&Z^h% zHt&r|m(Biw#{*YR_no)4q|~vieC#ef`CFnFoLB&PS3Jfbj?Z}^F)1iT3GW*oH|cSk zdQ^TLqDGCJ*O@^C4k>c#-DH0YeXft_F(7`JX=K=)K9fU2!O}8$&wjU5TM6a4t`Qba zep^;PYns0I^OqRwV-x7@JM^Nzt@=Vu9Po#O_GOHDJq)6d-6h0+!WF!|Qu!ht5&7*z zs75DI*dPKvwW0ftTjLsrfi<$V1s?c0rnk0aU3u-1e;b8}Be8zE8td`g?$bwyUhb}- z&|=g?!V^;HxM3`R{mSgY^Kqg==WFNCJzION^ZxK>gzP#7y$_rQYLu)~Tr40JN&;Tt zCwFyK;zo+}#Eco=9g=i4r2tV&scthCdKKL$HMXA|oc{=fni)@m(n`ZjOA2EI-la?0 z6IAD*;#QSfkAoa`xTM=s362+FDr^S+JOqGxm6Cc;htiC5Vb#<=QbJ@WczaqpVQo7R zi*8K#Wy@Vr32XJiC9CK7uRt<2-E+?XI%!snq`#6CMh2H(mPW+9QQIKk`naSQs3mW5 zwF!5iNJ^7II;Jn67SY5L)g?ab-133mr*Cmf%E%y<;un+KVMA>KG?RPa`~-EQ|F~Yo zIbP^VC2_$aVSsBP5#r|%L_{bcF?b?qAR9z{q07A%oYx6ADq79T`?A)?GC{h!vT|n& zYo_8J84bdl_k)i;J9Wv4r`0~ExUX<1xOztd54Aq9DM4HtP6vivH)t$13W)wU}BfkN%xm==spQjgFGJ7(5I<;wy(Wfeb9)FF&vS zrkYdpjU#v@2ET=^Q@Q8F9j0UdG<SxZIw;9z_mhDb|5P)6PU!_n zt1t+pBj7gbtDwwgVSNXl$|=#nTl4NA(^YAX%Z+J^R5HD z2i~#6B0D9qK0mH|{_G_GsNm^$X#$%YP!m_?h%+Z_T@^&-18uy@JwKXJ41iney$(N__?(EEyd$6>X0=6BM z6x*k+M<8&nzOtLJH$n`R5VJBe|BZ6jl0LEh<@Zy4X#{RNGSNrx)WpRZh zGZo<-uiqS|ptMhT5ul!DGwB6Z1?68AgqZV9G9&#ON6W@w(FmWI8sTYQoU}3x#l%qkh?W+wQD1`&Z`8r(SecQEp&XT76jG*` zN(&d#1$~#Fhm*Gg5AvTNN2u~D5+N<5&?$|Uw!Pg9n6~v3FV>YV=VJ4opwP7gzN|0OXpDGZfHMY(7R+co4#*V zBz@>keM+Jb#vLqLy$@B&XCZok z!W(UWG1n?qP2{)$Ey`0I^q8Y+dhT`t4JwF4b=uE>nLJ#nAnU!#>xXI@VkDc-D$^rL zR7w)Ik;%)LB*ixG@IkE;M`R z?4ZKpRjD9exTWT^|4!w=-mxevr=C%0b7%%bwH#fUD9S zGW5Mh)O}+%+~9pG$b0L=<8U0x_HhX z!5t;oegi**yHYbhl3C+wy>PFRVh{iiL;V@GMm%X6fVwOgMWe_ElD)~^56=WI;aiCf zhSpxZ{(ZYGxRLT*?5#FLEih8*Xe9OpG1~yQQ6^jxvgtH%4vtp5Q)ML_f=KbxPPqWQ z+HA@{goc90c(zxe2}u$OR&6yxwM11JCgAyqzwLms8sWsWiOaEN&u9|uc19$u20o1g zcfkFSGCe8mKl`X8`l&+zGqT^$ottyKy7V`lSUfq-Q5b_7A|(0t?q<0zwT<3Bja70H zNjZwuWU>p|FA$tb^qRa^3MUgErH%XDA*VkmLfpfZ4n*pO{Od#Rz2AVto5f8YF;$78&|(-I<%Z*CK{E=A-4u#gv*F zn|IW(;*D0rLr%=3cjTjcbaCmwC4SDRF@b;KQkZl@{uRw`EEfiLr~2ME3T2Av)H6Se zoSpEhd%e%s3wcbxUbjbr>z!ip4whya6t8IM5K;n{(kL@&Cc^(#;e`cCj|m--El3BD z^$g{@YMTx~iUN5VGmO2z7>P;7q_J zQ(_tN4hV{i&rBwVpOxyy`X7@4?KGxFGuY=)z#b^P4CHIW@~rw}IJhvAcz^$D(7p1> z*nMR>selK2ZzZZg9at)+frJeNEuWeF?{g@no?&_41VUq^%Rh<#7fk_g+Y2cI2iEld z7wt@$W1VqXa6l#o-vx5AxGb7k-)x=(0WvJ1mQM4{j;FO;2*`nZ5n;(is|i+ zPvZGRZo|f4vTl&h^$rc)1Bs}905BWjf$64MS@o#8rzT5XPFWAZSO11ckD#ou4uOUQ zqwzm2`2W`}fRH!*2PUf??D_vcWaR&UzWT;d+8$&kfa3{f@1L-hs5xN2-j63sK@$tR z4@oogViu1rZU0`1npd>bqyEduRxc-DX#)O-05W(-zgiW)?RmXJfz=ZtZ7u;dyHdxH zdzq-u)q5tT)z_Q*(q__g`%|79Fnqo?H+X1W#w2ixy7L4+;Ua2J=>`1}sv;&ttXz@g zRo39eYgMTfT0U-o|;C(`#YY+e8L(!;wt%i=Pnt>H+z5WGBoTbJ<}%MP7Y#m6`6+grS%Z3~RU?=*nv?;9&gfU5 zO-d#QgsIm{qLUof;jr*YDgmv3#5UzU?dST3e_owHp{h{XGn{^7=q~ch(BpR7x56&NgAtnhk5|@!QWSxgSp~G1JK}1OFQQ zhr4T-IGL0|_?3o=jWg7j>1d`bNoY8|yR7;>n7nbI7vBOk52!B^}^+^_l@o&xVMR zKMQC(Tt+7chdC>jzXS6&^Y?|t?vArxQ<^T?++h3zzmnZDD9m3V3(O?R#UQe_F(aeA zhx+*iP+@0wT*8Pdty~OcU)2kX8vi%Y{KYd&382)Tru!;q{-6rtotJf_X38i6GG;HJHq7vlgvD(uRMQvN>SO9!bqB@4T1F=wvQ)Ti=4x-4-Q9m^NX1gWxqNE z4lIe5=D;#_#<)sJebFU^KbmIVs}|4_=GHI$vN1r zfSRz=>Ep+e|FmfFFcLTH+Al3KPAZG7b*1TZO zBn_XG$S@)J?7G04w!+-0O5bKs(n3ci^0EF#J!G>2yj*^K<>%j4q~R{emfe3TtG=Vl z2_9BhZOfewyNUVkmE#NrZkIdOf!7K@R<}JI#Ox&u;i6VAyb3dqPg0BZHh`zU zgf^J=BL53qkfN(#qg<5DJj@=0_+x?&kv@!MDLzY?R2iJeFtU&TD&tiUY;JXYQuZlN zK>QXv{q%}kgMZnBulExrNKe7Kf`)w8^|yoqWx6T5w8wj9-2oUr;elk4fqNENtVexV zu2f6JKYm5*^k!3dH2}EG|7ida2dWdl(5&S?n!~Hufz{+yv3c71>-|#Neo4sq7hbHhw)<8wJ7)$f5pTluJE!Xz|YDj zn`msJJ8~PJebU(0$$An3cIR2^A2EZ0DxX zu%gn_%_XTmo|*9X^BX#Z&<4lhhciGA`9pGZvv9YigK;OE(SfLt*(%DVyYa<)D+9WW zw5=D`$CH7k=YY{oA;9M#9uM6QUfMN&ouN%)nVt>5D#O;NHMBkZc&y#7{=oHR(GK2U zGb?fdbAHc?kL+{8?lxXuzVW8j4OngdA#^yfES$fOWLI+IHnmb*2K9$SdU489@53{R zf;nv76Jsiew&>8n9wMF@`xybvO=r5Sb5yn-U9zYQ!+&-&Q(#E4^ z-O;W^lV^HqT8m`YReELl+M3%S=8+F9mN=I=%jj3a&mXtzasK|Ow*eT8zOoH= zID7_4B`A)*!6%MPncr6%IdeP4$^A&pO*RhsM0o=#eqBp+;26F{EQ;~waKuwt4@>dd z+LHFfAh`yn5jlrj3hm<&gG%G%9cCxxb5wwM6s+?n(L)G6!WbbKo*aC(Cs4`e$+aee zKOKiHJY;N(xkRoSY+dnjWD5?G(C2K5>dagTP}Fvwmzk+WD1oNwdTXsfuUVa69Ol#A z;WL0!F<;n!LOBmgbNquYlCq{eK+1Kakb}1-I@0z6viP&R19(!MwP{$GGPRyZW4L`k zA@BV|d2`V3!10~-z4-{ zD7_9>#};D7ZoOgEBukanVwEloZyYwhgzlM@zZ*Y{E@suLEr_+sWdBE@{wpZjVORit z)sCS)L-ZM$j2mfB8y`u>MOtPgK+;U%_0+ zeC%{x)E)bY2h!>9I>kMQ49k{kOy9UXd34sIM~zXx#fAREx%le#ldw_!!KB!)tlP!x zVBy<;4J)%&U@UMYVBdXYfy>NHQcJq^2ppu&TCEdTqKMh%tO)SLWFGWt@{;z?rtUG5 z{MQOz^*Mz3Fpb!yzn1!V_U8v6IuJLrs=fBuqxIC*sd)h-(%|vYV8vHjs-?Z>txGbz@f{~tkZdOafjPC(|h5@UK zvGrj*7Tm_FF;XH+VAu4>7Neu-Vp}`PYAmzNm^$lEOD_`681Q3i0PW)3K5v4tcV3%Q zM^+{6{t|4xBWPnCkXpx_*)Y#Bp)z6g!aJmxcU#sSA6++v1{KIM$tP8jIX{{6VfoHi zB-u|wzmf3aeIu)4qu1kkK{KkFJHK~&y|oc!nlAjz_+D|<7CcG)`S?Rh+iy>mC^hGng8k!lr>6xBYt9)m?1HpAhd*}ZLaLyamy`LUa+{vSoc z`pAT|*cbDKs6qC`niRk`aNh{q=`^}o%(x4*JSpvabA*rY_sCw)RHNCYKO?;!Mj$%f ziw8TLNLxkOtHgQi&Tnq(>4I7#6dw-eopAtR1jW~RE>gQ947_doVUw+<%)-wUE*|)ZO7QE&8|8RJ2Lq@zqg?_5OKrpgxYP(eUEUb9|aqnXiN;t#MZ0*s5X z31cJ)S8|;S)k7(()}K~Q#QT9@q*K&ieW^6@;`SX-3?Lf&Yzh!H0HwkrhB6%%iOgPL z91|>dVVi&9(**c98r}d*5;iNhPw7$kPU@bt(pO0)=((IvPTI+7hxQ0j8d2j^g8IA-T=C2`01zoxKy-t;q z8~qn$IitFwl;GZsYrm3swE@qyC{|PUI2KFUZ6ZL}c8_zdd7L z^opFxNJq_G9WGlkfQ4twMnaA>tZn(W>3+qhx4s)jO4&f^;PYSe1p{vOqPxH4gIZnQ zsxHI^xArjmx5W-!a?t?`V-77cCTX63(EVGNBC8l;HmUh@eO<6DMKgqgKHaEC6qVs$ zk?eQAN*)C(X$RXLC5o;=6~TX+u&&|Pmb{o|`CJhRgUf+HRGT?nl0>0ox8ObBRfpgi zw|60}@nvGhe;v0$8hI)tH0&kkCBb3Vdn&Us8&;*qC7M)lSdB6V#vcA>FYEUSi0x<-pNpBZ~2>F?E3E zfxReI+@3rFz(rZ{EC`g!En;532>>VjNeRCNFppamA>T~3g=~3uhTknhFzCooYrTFk%K;JoZi)5~^3_h@G5*^uJhA5E-shXNpR+{j~X0E+&AUpHULdtM@ z`y@QuxDw2j9k+~$Py%-2)!?<%Cn=drC7-~l2-ZhSkB750=WU6x#M}ty#I|fW!D$wD zvOq)dMbjXGHIzifkkh3o>sP;BW$z|pUMO`piN!~o*AH0wY(G_3Ns5bm8oW!O(j&)H z_f2z{9)p}*Qn*ttnVh}*w+1>j_<##VKy`!95Y<3*|(;R&Nkt; z<1NNa{A)4>IN0v=7U@i}KkajR%mMU8t^)v%WFsn)u>2~08sRG*u@bxS)PQLu{(C(5 zE%JUsIaq6*sBvFp+X>X<;RP4xGfgt}{UTn9tFJsBvC^?Zn%9QEw+kS(xPoEQ!uo!c zmf@N=0~FQI$1U44p=H6Wcf%or5Er-?VAbYxv-dB^#Lk!}j~|muUV#?`kJ$3tGiS{C z5FBX1@NsGi6;^upE=6Eh5vziB!{UP+wH&}qsp+(VeebQ|tOSqkloagfbpLF1*Z1*B z7i>V<_&RqHqTA^Ef~03uM5m z(&zUpz!tRgNuYNuW~ka*0Am>ghw`TANJO*rSFrMF821gf-keC=`PU&yNZHmS6Nlnm z&p%NazEMu`w=)3e7iKXHkmV#>qp1PYaeY;4+K@Q8i=A+@PoY7&; z#G(qf%`I)T#8&aF#n9s=0oCK0up{^Llf=5r95C%UgfD&4*l8A3VHsUBB|S3b!)O_M zf%@%&Ilc7TyFFGRRz2dA8eq4lET;b1P^DP3GVNgn^E_nw|)l3Da`WB5rg934- zlIKlhkTK0K*6*#-Aw2IF-Ws_5sDw4xpEM(6%%p_SGMCBKx}28{QyC1QIK72*|LxHf0P}SDmIR z@B_BqiIVcw^u(+?<#ELHESJTj^S0GMqtF6f;uRtSg79zfC=8y@2bzx{l}{lXfjfz3s`9B6;n%%^IX@}YY@S{nb6wzfe^Nr{fTof?3=_i zFrLV%7XJsBf}Op~KEJRip6cQj`)`?aBp-twfy0O6G^=2SsEy-cnyFVUF8&)M1$B-IryFaA&=iOG3MHVF|Z{q{uU!-txLghzyCrn zd)i$|V7uX;%czLzkNpg@8H`x1E2+Daj>=^?VnL!-vn7tDhK(;kjD@G|iA+`(xeD0-7-^6pXxQeWv zwzBM}G2KW<>%2f{2K;V3nS4JCBy+c}r{nu=8y7bcuUbMMVFt$M%v>JdlDU+aPEJhi z=wU3!8}_pF!+$5&xFuh{dJ^KYMBR^@4#n3TyFFok`ZLs$D><2G zP{_kw*ZX;J5<9`tX1ynXm6hYzS=sDedDu1YH?6`h}Gp1 znXQX4Ep7krY>CHDt20+0EA9uvNQh?SMyz-9uBAJ8O96rRISHpK1EiqX$xo+jMf~wQ77g_3}w&l-*kdFa1)uT1sr`60D{RUu5xa z5P5S9kUe_9OU8`DUZgiT#WG-G_qgB+p}^0up4v=h0#rJ!3uItl(R@;J?B;%enOm~0 zJdpMwUI*_sP#&P5jZO@@t)Hj&8^%-cj4`CET=jEMaKPO5{NV<|)$k$yHlXbP=HGQE zjJA1LvihJp*l#@zb5_LX4yngAJ`>NV{W!?A{-G?F1QJ*0&9`toze0XqrQzQ4@ zeX@tsKz3d|cJ%)D0^?-CxjT-@9cB{C2`f0m*A%Pj*}py>bjEQTC5roZ`0{11HNVsE z3h=yWSN92@Cd%FrR=+ggH>M5y5?UYfR?xzra}<2z0}Uq>E-C_TPc-FS5|1h{d>f;`z0C zlCP9>qwW*`O*BK}Tjy(c7$b$J-tSlJU zF_&b+J6b_Hpxii+2`SAHFUYFdU)!SwM9Z#Ho{kY0-~WK?sTGqA0h%OQM-Gs2@(sjf@ls0@?QG1=30Nc+v=)Xztu(6S&w!J|Vl9Bl^1qxWhJqvV zURDulHO;9~)$T-oNH$uJ7MR61-r9wuvBE(yVvQxfWl;IqWD%nejzvl`!pN7?oLR~P zYwEOSClh9{g%XConi)4Pj?u!!eu`IW%n!PS%@{L;)~~I}rEj_u8Vw2hsCC?pQOPK; z&-qUlHAkOkaxQGXM4o1v1)Ion(2ns}y9^~+(Vu!%7?g9*vlaO&NP>~!$dA^!>yMFG6B%Qdq8iY;&>9()=Nic&E}vDDCAIBNgfI*7d=I3xi6 z(@jwOYvi|obDzXHV8MImVj>o;QYT{ggSq;KNWL1m>OR4&A!>3*Nr|&9p zhw`sun=|HhSH8i!fuqALc;YaT*9?W6&?AuPrl;e9oQ^99eCm{7k#H2=47P z`ULoPQF7|xfw)SXVaIqMRk$O=f2S2X(J<4|mHK7O!x=_i?7OVQ*sOPKd5EiSe!2M~ z-ieZ=aAE)=G}Xl@Z_<@RX0C~3oZCX1?;2o$URGGF99{{RC*B%b>~;KmBkO5yi20Sv zb1T1yx>GI`C30I3$QJ->AqZ4;7GI00#bVg%uWI8?+k5(3PfuW7NAWUfbmG@50+dmTg&k;B4=a`L+_;7AVR zHQN%Uzlz|G24?DQs^HmCDg`# zfRa>9;jzhYFyTns9rG{F*9uFx z&2uB}>G185|3BC&ohD5MRCnPgr`BWr{=sU~VhjPoBeLg_Gu(r+oJy#;>F&VEc`mp; zTP87_rzpm>%djEtX5{hCN)y!(Q!I90vE>$BI&}eAgxK~g%k`zbJ-bT`h#Gi(YEq?t z0Ll5Ds8HSWc3veFd!k4&?L#JlY%D%}T@Ry3N0f9qEsPh{)O7e45Wd)CBq(mdhNP>& zKS#TD>$CoUfhLYFDNu6T(*>s$-#O2$#J7Js@|2n@F^wMd(Di_vH+jwD%{FWkiMVf^Qr@&#z<6BA%!II~pe!X(>+N$Lc{!nENgf z2uZZTYdP7`?;&Jsp;{2#OlId^zCOm6RXV2r4#;Z2V~P6Blnl+`&NT3eS7v%$z9?Ax zE;Q=P#Ros6pl_PM@4cT{>xJlLpurMiTnF%DzKm+=D)YUz&rg`IlnBY(EHzAA5SLOB z$Y-D=T*B#9GIQA&qMfZ;e(*t^e?5J&ks z`n=j~7>(jDMcAXl`@^N0WSQO%nq^O?z1&8;>m#j&Po_ zn;3>4NsXpOSWX-P7i`IgwM7`2NFv1coRw{yN7SI8v#s|MbUynn-j63!xyJOFd=6jz z;TYI~idQ_pF>Fg3zq}?!l&j;ES;C*Z<3*&gGKtrq?2uSS7lxsp?qrb7091+1Uvp;{>j_ zV_zz^?TG?e$scn|yV^}aVqa4>yBVUS$E zKn!yLa^2TXScz2EoR$)ODi;pSB;G=I4=%Q?9s3ZpxQ>&%oUbZXo-`fNyaLKe5C{Ok z6oK%o`EiyxQ5etj4!4o2ET&Q15*KL}@BUj|g+;IuFfv?9M!^AycQm zQ<#7<{q5Dm^=urH6ss*x(GNH!M)TM4qFmqaxPnY4&rmAa=1)e9zeT^%!&>zQ2>!j! zNaPg)83L1+$~)WxZw%y2cDNy^>5pV4zu%BBv@jYXtWQ0uWPVGwQ(}ftbqqJY|PfS3@s@F{l{Bl@@mmf}O%jF7xz+!;SEs`^Du_7ms zBJ4DAi6b-F^@RSz3eK8D6MwQZbyo#QBcqyIi1SzJjElW@Zj`AD)@Go%he9XzdDxEO zyr>D$Cmzy{7n%G81IqQ(3=8~OC~$H6^Luv}f(i(z&*L(9g}^1KP687t{a;@q0?Hqt z_I;>X!A9OUOGQ(Pw;+gf)dd9fNKeOyQ8YZu8X4mCDON>Lw|ib|L-)HB+xSk97CA!) ztl-!)h;K1$Top9R1L+({&1D+!i`$&pEzs~;xZ)9>i-~QeXYT*^!7oPbA1VFa<8eWB zV}+SPei02zB{>O>`)`C|Eo(joF^H;4AUXQp*5%F~RO@TkS;9bnqM5w*4E^>eWAQrD z^eVkvEMU;#WE1EHBeHb4{zmD1ddM8-b2I=S2CpxQdw){I;U_;+uB{65E7RJOA$#iz0{*;KS|ARmxNhH8m0mvg(~qmZ}v<&in?mv1QQxe_3+| zg>KD|U`EpwcvZgqd+{hKl;j?@0pVrdRXE5zdd-GwUNd=6%f>p4<K`>Va{Y%zIP;Br?&MU{W`vC8-}{xLWbA`h`six+{7>y(=}oV!*OlPcLuf zPM5n1IJc?!ba#oIxQ1`9jN`v*@_(HFq=gjXJpCfb|L^L~s<~96NzPJf)XuNg?=8&2E-0>=dl-x{#4lew zR_Z{-%nOz4-%jtrsEwXLOo3nE!$uf0P>FwBeJl4+bRWDl0Rw{>`R4t=?k28BL}yjN z>l!hkSb!q4V1cU2IG0lbwgyLkz_?MP0$>0t)I?my@lPk79t`=om!yWv^P|po@v5U^og6d*=zrxcRvAcOz?foX z&WLD}^AFgx@NiSop`oa-&W6>q4&z54BMn{*HoRC9Uz zTc_Nld9kn67&q(dG|?pTw_qE~3|MVZve*SV4qEb2jFGfr=g&}Njx6zdn~xm&i>9lW`K>J?D^|VmcmSY0!&D zUxPZ>s?HRK(Tj$>xN(&*`%FluVEX8oIcO^}D)XzUi&?K225+!bJ~|JHm?_yrdQd>^ z8e#?|PjAZ(;P676Eztmj4pq2sXVvUJsli20@$o7SbE5_=&9Ss$eW^)qBt{+ggR}n` z_zEydz&a6B_LUPR(Sed@N{AK9 zh*RfZS|@HZ>b;Y7`)%E@7))N??>l|!rZ;LT^T~9uau+5B+a?RM3X{}NO~`WaB{uEq z=@P_7VrhuF)wU@cmq^D^KJ4jsL>#2>LUU~`(uQn(_UCgWn<{nwCXxn9c3Hf@MY%%# zw3{RL=Ltuz0Dju$&ZLj2e3H%I%HqGsl3TxSdyn=Z%E;~$9b_{>r%E6?tmU&v6P5A_ zE+&=xegqPimqfx^hFa&~_Z2&>YVc@frX&E_uhYSG6vT`DNa z4bUWqNUL9(d z*#SoL=tqenu7oIc;*DvU&NV#~eUn>G2a35r&r};5vlo&OMq1Y$&+xW zds9AOfi8U{u^r^^M+o8?z?737!(m3{!moXzB$zS*0>-%G(NMrl+2T%aw|Dxq_w7Ng z?(wjnkc$5KYy6AmAJ?;?#V@gXy$UL^Z(DcBxs>?BEcIF%j#wTaZxr{2FOsAtkOFVS z6XZf+5yid{fc!AOJ#FiS_9t6x|I8u!ODJ)wJ}n7{U7E*8Lv6E4$cBnOfh4KADU3M6 zAi!`zDfjl7sBG@+af~^g>y{V7Z9|bbw_7T56(f;59P_sULPGW^QdJWJ1z3cI%Dg~R z8ABk7n36v%Na_sdOfcI4}_ky9bD0^E?szk+>;NbR4#3 z%nJoAz7+DbN%ljDQV0Wg5JEzRi0h5PsK3a60rwnCIns>B+#D9ZQt>LUuu6rq>l&w-L~Mb8YPIh@+&?{rjVbh z-#A!}zWtq!`5lM^?KpBwtl}!9cs{~yz<;BWIAhT(^_#S&Hn9zrjzL4*qU+O>Qw!9a zfw4zktol^F`=s=yGRkUBjsRS!mQK&sPNp&OI}L>BnoOth^LXOh*eRujOkybnnm;WcsIdwrJcS}^+zOcx zzgX2xz;lCw z=fSNP_=Pzdj%jz1f9@=9s`ny4+rA!LO>QAi*6x|Bm*aVc_~wPVWn2oa&8l$Kn`@eH zQ2Q~Tsnot8Creko!_V?wV0Ep~>nPMMIG4W5@#WF{xH zPu_V{q63%0kD3c2jiFC!C_Cu!4O0>jBQ;(Zgy!ZY#Br>001hia3D$$vFVqZFh)X-o z79s8@;pOx_dew28etiKgwUrR3X1A#dNetYPM97xB?hDh^nBKI-JPW#fl>a)jUiB%511F#W}j=M5a zu4})=C#h7}QgzhDg?(EAA4$FfJ_1ks>=UVtzv6NeBckC4 zKPvv?Utg9Oy7$;xK?!(tRGerkx|#H5C4j9X7SWi53R1-kxPk%PYynEeGW7m%*fBR3 zr!?Yv&D6A^YXJp`#;*uVJ`B;j#`f{IBou`noY3x`BB>bUm(!eJ5MSp-m4ZXZ;XC3K zz3DwrwMtQuMGTrVrJfHhI3)K4ep>8DjSD~5$`!^*R}lZoQ;jZn0+K`1T&rHtnOw&K ze@jE8hDU|Dp*RdJc^W>G$?IsP>}rMV;Wu|#r76t`JoId_KUq5 z)6YwWx?A!$b+w6$%XFdLfB3T)1B|UWLrb&iBp)~x0EjMKr%O}xzlA*|NF$dRotG;T%T5E* zR{18BTBfmQqFODMjY&drBt{-=_I;5IL*Y8Br=4Dee^caB>|ScL?-c4002;VHWOUw& zGEF9TKaX?;X%sX{wCu_*R?Am!X+EpXqCR6#tO6)UpTE812EqE*e&kr*ZF8TZf%@7!0(^@|=}U`+e3Nc(og@WsCFBN=+fMI7^6u(zM6|*bRE`0=mFE4& zW><9UWWLXTL2H1jAEASl{qRMo2QVUIqH?q<^?v+3YfA#6P3^bTX?q+6TYawaKlVUH zu|f*N@L%bZr>xE>Ea2@_%G>4Pkx!(rJ}5?|&lmT->hAKW z4iZtjFx_47N6_b{nFx!i`geHa)%PyGgML~`0Q^c)ut+dDT{C!pDXV*IR>DZT=1Fh+m(N(fB-l=W34Wn7GQrPT^DL zbEE4y-%LvoR19Qi_DA}GMo0`|R%$+zL2>tsb=KwWzKOtBVkDJKk#DRSjTHU8e!U?R zENQA<6vbTe3*#bSQR?4|=bpnR7?}%N$E(qjeTsN8^>OKsQ3|tvKUv#7=FW}JtE}n6 z;+9}C0MW7Jxkd;5=IR*IqA@l1Lf$a;g74f0^N569^DtkRtwn4-p ze`kBi3q9wTYd!Wav=%bh?>97;Zvm`#h&)yB>Z|7ALHzL%8$M>CZNSe|gsB?U`N`&R z)c|Jc&?~s8RDa5#yPW{VP8c_a=x})oVj#OS|ExuJr6+ZKs-PzjH32RXEgu6+P>?2> zr)=H2+Ne}^C0v%0P7QQSm40$1@0ansY?#vz_;-@ zufkBI$s|NbpQMEf-U>=`FN8~tPYxi#&f@i`3Y**?9TYqHkEFNVP4n&FuZBDl&(^;W z$P$&kF0|k5@saN>BnE>xaxN5&0PJ{eDP97dEiY$aC!S_~;Oc&z_-{Ks)W9zEF158e z-^d-|9xyKD`Oq?V#{46(@3%`}Ako_=#}GSZT%<^hlb3q#*tsrWcXxniup({2YDkqE zKAYhh(2lL9!{^1Ib$LIKf8|trh7v_!rwWw9Z`yW9tKMW@^+pmi7&rjw?9vE|ce(Aq zF^y`0unFVSQN3{}k-JF6tAF21#8`a2I3^mb9AeOY@Yw@{S7U4vht#m58*fF>9*h>I z8r);O16JNV=?7lz9>d@2-+IL-efXllFuTM1)iqcWZ=d>anDA`<+ukz*J1WE(t%)|7 zFu{!F8^*UsL=pVHZQ6V&KR-ScK#vWh)f?D4cY-zL!K!VE5KJ_`>?=5=q0I8$IQ50m z>RFk9*N+ZbxWL6=zR#%kUgiK5R%CLx_|&{IpM|Cv*04X1997H%hEzIN;NPWheNt3I zipm(1!SaxU+zgc8D;1x;dYqh_~p+xT62e&W`|>W{rLDUY_nDnCJq~YWp%rU}pj&YXZ}Vs-2_oFsdwG|UKVH)FvaE;6#23eVbOyJ$&lmtx zU9kTXwbJWS2h%l|)E^&}G2AfB;<}qo3D$x{S=%`xS&z0FD1Gb(j6}}v832T;cqnt{ z2?Hi_q!1sok3^S>6oN=AR(q?F(;T={N)t}CUogB@cqv77UDCPkL5#_SCq&)U*F=sOUuX;M=dBxD5H z2dTI;yH8gH(2r@IS9?4mJw_ZS4!mp+ZPTJr>HgT)J)*oAQw=W8TN&02Q`Pt=U{dC_ zn|U?&D8=(o1#Hs}o2MTdn2k4U-t&?NR?d?z1eVN$1v3C5%GrG#8n~;W#n~NM^5+LC zERP1Pla(AZE^yPR2b78J^&;1L5eHn>t=YQ)mY3wiT8)D*$!KLGQev=M#~?ZqB4*|NTfy zHXTG*ir`9iYk0DhHM|kRY}Mo>ky<_C=0znBB`-_R;kJihK=HHZCP z$~((LyNwb3KcY#>0C{cmG$o?mb%q+uY$N}<9)1$K7SEbcl&RI~d1#hl8UR-4FGv`j z+M24$qr8q(N zl|h2TguGb4q^e zrxI>LP}e62tG{3S&eHmCI$x3{^IQsOZbf%vCQ@mc%@hTKdim= zTU6io2Pz;P(j_S=Fr>iHEl76^-3%cef^>(Jq;z)=NH+q4)X+#vmq_a~E{@M4e=!*gZ70k7A$3!z@8kI$goKKi|17^2J-f!@Lsg$JR9 z#7_M$zn22BWzR}WtXyf~a!&}`jv@61{bUsH_P}nk5G?Md{bGLZ`RkzI z$H7BZ|K6BNM)eRa}MGk za+Us`aWN8&Y~KRq^@qCz*XKs)cx_iG89eN4Tl?_xmFtA-kxI)Aexzc;2P#it?iyv+ zf*auwWTh`gcDiaIjj4#yJoz3M-S_vE5x)otjtC3_O=4jS`bJtlTS%b^88mpf)D#Vd zNT(7I5)K1Yr0tG?Bi-rT799T_**P3m!XW@cfXj);$es^_m>kaSQd|B8~ZD>kxjn{W5@IqaPDJ=CAdHvx|RjkuE( z*=rVebYB1-Ohyq1r0W!Vg<2l|CJOC^-No;jP1?Dq@;U<8%~)m1tWc_wnS7aO!Nxb| zr+IOTPs@|jx>1%RDId-xe=7yO7F}Vr(a2KziyBaMWcBwCBym>aSPCmCL z%6aApf7k=CmWzOS;Eld9Zu}U#XpT!L?#o7+6JmnVWuo`^+_0|0En)VXc6_>w=Y4dVMGUV>$m-Yna+h^h9>ufJ zl_7Te&`PK&PIv9*Z``VzHi?4%7LoTupEFN`?%I9R5JBuckk(5Ly|!LbHYU}-8tW>E zf3#pUn&)JOUT*eRQ+8&!j2!tg{^6Gh(b`a57=Gc-Pc;|x)8-GsHcF7c-s>Pr(_J-g z0J~q;$_-6{+zz6KE{yUD2`j9aoK*7g`w??CgUFa@r9NX9tMzxMAlvsZr%Dk%;ejHM zDftINVhNgj)=8I9y{e#-56~PS)CvH3y}(>nS~^c$#C(Oph?Xo$haw$K9Mtc8xCtgQ z+h!wGlSX*+GV4|vwRJ0#|{nrZ6kW# z7EqwWX-s3Q1E6z`=U35_D)Ip^mUOt)%-SlmtHoS63N_Gm3Plngz%f{#tNM~0qjqlY zQG@aeiQ*;sw$Px&qAdhKo>DC{$$d3)00x$#LQ>^O{x+P+D^mO%!^$Gu#9>J*8(~xN z7NETwIC-cU^dT26~x_Bsxk5P?zQ{oU? zh+ht>tu4d)zt;WQRAh?NM5#Us&S<~4D8d~^7_*PT!%A)nJ$TN!s1BR}Mn|&x#N3R} zjJa*iXZzo`(7XnbD5ndsc;G>!6)qFB6iT~`LV$ILFw(WgA7VO-$045kfMPf?ZJ--8 z@bV2Z5ZGV<5(b(8{0ITB4A9{IaH*a|B_|sAXY2(yO~l88%})A;0h<>DU=4}~$rSSw zEusm*k)<&=LPI$az9G=++7QQ(qlHl!RXgJ0#GTPY2#c%7i%r9FmyVH5dmEccB9mI; zKv>`}PiE~s`N?m_@x2BY)=LJ1+tBr|$su4U0tw+vF(TSrKWrBDjjT30x0OovXP~-%F zH~O>3uc8TZ_9>PQ$={LWuEw6d3$WoQY~Cu&a~A~JklF$d zUcbF<$?o?Q3cq&qWf~bfE??%+I=|tX3>^#+Rp2p6%eS1(-!;08A$zuGx#g28mx_^Q z5L^;`4hp!PFuk(dZ+pJ!K<0IFe5O{^+;7Bzt^g8ijq&))U>Vjv6TVNCn?!`t9;S-e zx7E1$nW%}S4xn4z2tPZVNY+)t{9pgb|LgtpN2BjgO6D?^5U#r-Jq3yBU9B4@ zHbJquOHfKFI(K?KHhxv%gq^cNTNEmAJLYtGFlY&?r?&anU5g|Re-F4uqya;A#t1x1 z?Kc^AO(F6W&-CA2#0nQy+Rvt(7i)_ktLPNHNW|EFfyk)y9#=I}Bamw$M21xs=5uZoHn7yPO0|6q+VAa=pR_wK3yn}$LBqv)IE9<{`BhW#(O0~ zOt1&_T?(vJLJ5xu$X4y4TfHOA_Gaj*0Dqu6xp?7{fH3r!ZZeZR;Zkw6KW4+ zGg>Y(YVZ0)B{BnHJAfD_-6=-fVZ@hOUtMbZ)&CCL0rXkhK37V2SK616Z?NBDOenz= z>i~rOFlp(7v6;=S7#td$Ky>eM;b=;$#^(+qGe#hFIQ}a^@{NFQpwu*scqR zS>MF&pl?{Bcuf23T29`SAMZ!mpxsHHb>CyF*G|MGzf40V=)IV|n?x^U2Z~1@va+XY*tsHRXp<)y_dhCmFzc3#n?S?*_z4Dy5v|U_+X*?_V)5fpKo0f!GD@ps=w=VRheSJ9!Pm38!z}9&WDJO zD2`%V7xS%>6J$SPT)c=OacQ)m$pYCC2mHg8He=BP00*g@Zhc}hO@tfq!pJfAe7wU8G8C&>>&uipCXxqp(Nu5SI-t)!2h-o^H@Qx74 zIPEPCP#WXDS$uKktH~m|`@|W#P&PYLsmGICu8>xH30(Ps)0}hf8D5QH#NGcJ?LhRf zSR|@h{EGy%7xJ>S5TjbdI0ymn)1-3*@zkxmw;)LPY@htCuBlLQoi}%H)@C7qvKol; zn9_@7z=`Rs$Qa#Nyg`3#jpWK|W@bX!(4{cwfM~#h30~~}99U}j@ zO%U(t7D&BT^mm;xWtl>YE##&4%nwY8ug3T_(9oVr=m2&kN%yLf#uHJ5RIQtLHHDT7 zq%=1-?roGGqpQK!*Se173aRY29NyKneqY2I>IU(l8v$P1YrsP} zoy`+L3gVA8(jVzfHU})d3Cuh&W+6>KNLLU5%M|82#ek0&VW!NjnAH zo8WiF{%rmPu7agBNa1z=JJ#nhKcM_>?&(c7=4OB>V(<2`$S#RU7Nj}=9)(Ff3&A(| ztZ6x_9*XSxwgR6x+Pn7Y{>!%Ln;Ro|<&i;m`(PIJxvu3%c5{H*UqnOL`=G(hV+P~& zQej;ut9tfYWw~VKRaHDZiMT)vZ(LPE>25lXp!Sx>o$q6QVeYefK33zS+36kDeyigL%oEywU` z8FhNZbzf-f7VtJ;o*23q$P>k(zRGY<71fbo9puo}s-V>VReav29Kie*v_2N8azOj= z!CAb7h+wUBtyUG8Mt;qi_SP#ja&@_Nua;X)mywxI-)LoiZ{_aJUw{$|EAH{HoYNig z74kAivDV$=;Qn4@&7N#T^-=Hfp-~x*ZrnQH7bw8oEbcvVX5toCF@SN@emxP}Qp$2l zz*f_M^v)Dmm3PunofXSvzLhUwc)OQQuObavmkj9hb}-!Js?SGckC&TA!xVB~R6H1) zHAT;Fx;$E_p-db}S8Q=tqqE+S73`wyZ!@@S+Z%jUVYqZH^j(!!hbni{GxVVSSP%>zqT@M?H$&zgB-#t$TiCx+%z2R-gz0lexWV61qlo z71*PX;p^HbZJJ8lXcjjLtaNNjKlw%I(;$-bTjb$JS2XUV)uy(5A>DVI0t{2~*+J%i zZRBg^+beK>cS-s{RnGFd{^5&a>y3af#d4>2x?sVDt*$t0+S+g z4;-MFadg=fBnV;)w=^ls)TU)FmL+r8F+A?Tj3pbCgcbv(1Vt29bYwzyV$d}#6C0_< zNE+x?8QSL66kv5_#l~5@y3?Hu8w~Vfvmt;%d~#%GOEI5rS_REk5UfA5>K`sfs38xy zvuzC^!uJYr`xb zwU}8B!`E@`Ytyl!m(7Ld8ta~k*rn1Zh=b9ak8$R)7Z4o$Ldad^mOiWx@?`p;`cHh! zAuSR_!!D0$0;cv5j-^I+hxB7p%*Gn}w3lrlmsi+oZ0ZtGA^((_(W)~9?_H;XwLRdGlrG{HfbU&(KRYV|HVD-}=g=6`QF6OOeKl zVvXrSIhd@v5DsxB~2+AgzDK9^_`j?39fCXJ#k zer;mSXc1k;eUV!MHp12pufv1=@wm>d#=;+LUx-j7ek#l0{boB}NCg^a+W?9h?{E0q zi$OxGD53W%9t?IA^K}gCwM`EV&K^vJ6UnQc9P70~+D*H2H8~#AeN4Y}a_;U)rq_H* z1hSInr7-9Ax0JZmAX!459zQB_t8cGPPLyW8vV}F;FMCu~KX!+K-V$tO@cUh!g7#S|j5oKho^@0%l-(+-Pg&9))it$LmmXKgB1NuV9% z*6ah5Ih2)fSI%I+j;+Op@qiz;x2-YltTC=OWBD|02aN!;r3GlZkf_Q5jux%B_U4|w z7!!$UVyqFMVz8@0lZMJl>=Ef`vGHtWX7ftU>1T8Xtnb#u2b^UdocW}lJMBodDQ=OK zVt6oK38779IgAdef{jKI*H^a0uHJp_6Z_c{T}56{A>ixHaEmu9fD5F~sD?4Ai zbl7LLf4=}%d92H8{4OdM^CoUTlL=ighmU&*3z=H%DClU2?pBxU=%CC*%>c-4s6#oj|vnX(C z&3^KKo&R%=uaYr{O&FX-OHhtKwspUv!|%jbRyi>Flvn+>ZBAhP-F;YXjm0z2;?cbG z-&2PAqtQpBOFD`3j-ZBC-&w&L2G2BfvLdXfRAABaBgMF53_1oPw#DB2TWgdO(Ftx; z*vDxe1#>RAnsy{53^D$9Z?#(1ksmsNa=r31y&ZlR&LL9i4~%Wg<3XiWUn{Dws!|Xp z^qPUr#VeX3R<=U1OPadl?P~vB^zMsHM?8CELp~$oYng4qMlE8@0{mlwNj`MR2K(rA z#XCWAj_nMjbtzH=rXyl*B)C!r071?TTKHdg^PDC}WeF5yeASELy@SaudZblP`Ukq+QpI zL3$AZ|5x$u(RASzzVZl4R`>w)Xz{o@s>^)!X~vUinc=K~O()+U)ru}^=?)~8!C4rKki9g>ly+elFCTG>jBT>b40PD1^NzH?Lg4m6Ujo&+^F~GLR&_ zE?=U8x-w7{YwauSso4u%sMLRy=!G6BaJ>u3N?Fxare5*>Rs+BF$q_&=Nygcok7haE z(5(LCQA}R@*F>;AP2{=&>Xqc>{G?CbxFnBxc|&Y0Pj52h^q4p+dVR{_}g5i)T)^=1Ua7qxE z-e4%F$Yd;>>Ms6rNO$;i2Ec zXD>(=N3INHIWb&G2^unj~#skkY}RvU3D$xQmBx3=Yl<_#9h}=ad)6<=jlpu8u@;o3M^C zn%?%Wg%FHe>awrdw%0=98EGae=9K9v<~^6cJWQ&s1woHG1+o%=OvtPn%zk!ER7{T? zhSA(LWX0L(_1I&MKxK}Ou}Pjjo5!jjnyt3(hrsJUU8G+CQiJU`!`=V4c|udgW0r=H zl>4RSq5&}u_R@Ru2bGIxi6K`);;zJJSwJe{-Gr<;wNfnV$J!f9$Y z`UAjp(63NE?cyVck}XwKUz15DPC#-14u%yK0T3~IN!^@>+!b+7fGyTALKrLFbJomm;PyQR6@GR>nW z=yds5Px61)g0+%|m1?pFAymh&;$sQ9BlCdqp-I;GCn zUG!umR!TBU(D|BTI6l)GhmCg@dT_Gzq0ivgY4)fQ1w2az%0R!Vto%I~%eHpKowem9 z+P6PpK}=@3l>Q!Y)A=zZc$2HE0EjL4%1L?3>f?y!`+8%FuPsx=4zI5UJ16eZSzg$6vpGnTGT8H6H3o z#wEE_O`-u$QNj5+s8ajs0?J?tww#p8W!eNR_Ni5G`SJd&^=n;!%fxqu+3=~Lg5HS- z{@8E%owt8!+;5~S&Yw!W}}&gE?qJWzFYyFsqdH_sb=ArULifzsgSA(fhgc`1>@`(?Xnb*__+g z425vd1NSet@>zYYo;__}W*fzn|}}L7F@(fubxi(aMTug&&W_H{c8sH_FoH zBe^Z5jU(ZqO;yIU{g9cI1OMj}+KZUq+^>d^&J?l*yBDmTeY~(YE^%K{DcLhm*~CFA z%~?9GaT6p|aU}jsn(*Y@?AeqcWyc4dLs%R}?0wn-LNvS}*cb zB24j%>Ezx|ClS|HSQeV+2;ADt6x!9=o|^IBJD3%$%jXAytK6tw$q&St(fxdyQx8$D zcp-hE@`8v#o@Gw%O;`?GQqd0ng)&q5;L^2Zryq)-(-=cDd$KSH>%BeXGPa)(5J>iI z`87w5^^%OJAG#1pN~%6UVKyM0M4YJqx3t!{%TLf~H$44syb66F9olDMQW4;cd~xzy z-TKwX9IwXxr(p8~a~X%F@=s?tmvNXpJ`>27d*vzX)~UiGWj%B~jvinocdrc;_oqaD za<(1o`PJKtgN_baq$TKw6oyIwuDHCt-9V@aXjEJA_;6>(baA)(B)Uf@IXp#R%}|qQ zOO@o78EYaaCs^er1u$h7rhWxq23Xs_01e$@K8zw|Zi=!%d)pf2 z9qjckBAT8>CvBQ-IZdMk8JI+Xd$vz_gP|hJfH`SWbWV2Kc^&OfX_+!e*k^tZnV6qH z<&8^{_qj^Iua}?<8jxc1gsWmWqVAmA$8HY@dl3=6zVmTCx%)^+NjsqC0B(!ZW~F4c zQiWLfc1$6}#qxdpT`GI*>ohFyeoglpxN2rm2@K^d$9Y= zqJUEv3rXiTU@eFP9CtZ_t(iDUkf1V#al#lAM`1Q~YtmmK#TjAX z{o2AH-mBN|67>?J!Hzc@GDh?SClL6Bbr8lJ<( zd993D_L%JjK|O9Cw=2LPu_A`7cm(dBobQm6G*$of?&>6IWzG(|zV`;9;*}&1dqMV0 zbVdUDxG9xXfrbil&iqT>A`iKI4M#yEsKo7%_wg9_?CNi;z`fV5=ecl}7ydN{l|ROe zwv|HTz{GH9WCI2qI^4u9!ye;zanuj>)xAWj*`g_6Pp^s_5Y9G0xCpi-D-}wM?XAa_ zx_FiIu1oC>dt9Wf+W+H6Gx8bk_p$berDrn5bR@D|?qd48uzb`kZG`U4u;XAxZ;f?x zA?nlu^bOcwjBsRWt(Km(7IQd@8iRA%*_fD)lSlBvg)HG0l8bSh&;z`s4F zlC-D%p4c2{n|AlVm-;coZ4lOJP<J((N&g;x-XL-VaAkX`5nxf`?X)h9~{9d#K21W-^0m*E`f^4F{kTQC7(d3 zdhgt|dZE7moUh}ih(CT3S+9L5+@w$fdC$@}uV3v^C)GKx_%MDSxU%A^Qhds$YA+wn zpE3z(J8?F>79&H!_NfdO!#{|7I>Amm=HD48QZbz&{vA%mbND!3^fp3l@yd-cxhaQr z1)3xCb&lWvbG@nk!MPFTc7~|2$|Qr_AkWkSq;FIbMr1!SmTdqw)6!Qbh|kC~eIY^mgF= zL*i$s&65iE20a@1-E6J2ty$D7C*{FeXaK60TYP6Ajemf#)~wAKhjyx~nmJpTk#h#& zvEF2AR1UQaj*c+~UX3H!olCc-zFM*KV1mW5HUlkx*pCd1aK$@obikPKb3d@qIy)wI zWci*6gd}cx6?cMG73w5Qw8X90AY~uPJ!`!`vDeK+X#R@V^eF7e7#U*S-t=wSI~tD1 zELx@OH9R{}0JFR2)=9MhZgzg~rQ%+Tn-@(uGEkP2$AQI;`t{3AQQw``h|OugOu2`n z??r@t!U?TLiI$=~YmSOUKXka_Mr6b%oyk^_g5sxNI%C>Wy!+wN=0(-_6^z2a`O=&I z2*a#5e$vcigU6l>L_8J{Bg-2D!79x-v_LTEe7PRb$4yu3FxLPN?^Zc2&eu&Mj{1YcoO7hKMFoD92Bw6sD`tPL z-N4L@29xTcqM&*JaH9JjJ-@?RsNx-dayuDp`{m;RVl2V5>B&!BS&@RdmRpz~ngdUa z?sQ{J@z7(RD{M9KbGy1hok>A*H5tO@yt?!|xp5eAf{aV!n{g7u^ zSCgqLrWvi-`yIHGrtYA8(%4HlDv(fRlgI2kIJvc`;ZOFFMnEs_!;?WCL@coq1bwww z>K1g8pGSF~jT?j>q)NH@TWp7qRgr>-3Zd8qvJJcWrci|ZCur{~VnT7KyYvV9==k3; zJN)XVz+b8+mGS*%T!Ku9zDA138+kfUbGHT`*@1MpI_fX zZr-zJs_N&PC?ajZ*18RH_uKYhChYNUc#NhxBjTu5pRKSQ;>bg!!mv&+lSGfQ+oybX z-jDe-DUXcTZCtB?R`00_^Pit{k_&+{fu;`9Lg4?NaZD~@PnVMFg=b>pA-=5f#mSyywQ zYRKvBq=A9buL07Wreg~Gi$2+Zi{(jL0v>k^d0+*-GS$!im*3v~(4G(=BvmTZrX!d| z9JWK!3kdF;7+W&0(fRgIu8z^zfo8)VL-^-M``70$99e{ukq-|gGz`UJ71YcB| z`$yZ1ZP#F&m&8N#RU(GmRVjg3(gqX3!YCn#zf#g)r{aVAZzIcO_j_Uu&qa4F439rnjV9Gu>@%u! zxH7AxX2*3gd!c^$`O%Wjs}T+o^)%{6e-WYe=B8!;IzJgmJ32lON+u+aGPUB`p}ISi zHp`Z5_aM~$??Nzs*kJeB6l~EnL`eGfH(XUU#Mw`<2vCTsZt-deSb?_ zAT2R~w%2OJnkMTP{c(pB@9P5jAJ&J-#Y&+hYsxXq5T zKjP?{JlZ-scHsfiWc^&GUU7V*ecTdS4L8iV2LRym_tO z;ot8w0STbdd2|SC^|?J;(RAi^G}`|b?PBUKz`mpxdE|GD;23$&%J$j-_t2IM@H|WK zLZ{wY+A~p3`D&&ewj*K%bKfk7Lg(JaY-)+ud zK;Lir-?cF-TGj%{Iha`pE$jZIxLvE5+dQ>Lh09+Q+L<85B(kYQgaf9#XP0(wp}^Qy z5L$^2v{1$j+p^yY^T-s?=X zpOA}Lmg1}#&2dv)ACAlodf3NDyfZ*4a_Pft{jJ3U#F{v5!M0e$JjGKijJvQmSW`}C zdJcjl;tm$Chxld!)2NrJJ9K?-oj)S&>;)yANCb1UT4b=x;du@W-)q_l#u%MRPkjq> zR)@6svB|jrH?aPm9L#doSio8L(%XXQCET>fU}kO3ul+4IMn(ME>E^}&HmgwD4!iz@ z#HZ2LmX&FVjeMA&;9mrh6v{{@fQ6{eRR+sM$KK@zNBTO{G(XIFYXN_x+v{y~ZWSYm zBg3Z(TDqp5|8G@31Pyo6eWqQavmJjhSkAzX?ArF3C_2awilCXX%% zQg>3_K#$|^m7K;4pyMtrzatmLcm1tTXUb8(!zcTy`1E}B6Ht`nW1Hmj2q56v6ZR6IYgjPh%~Ue z&g00&rqGEOHEKb8BEqUCx3n(-;vsDq@3~7DYO0T3IIGu-2!axIoUTZ>OnY2q(vZL( z?``79@2|<-C)4Jp9S3VPuSTypNTV%H{7igDpALR|wiELc7<-A;i4o`-+pnF^*bcN| zk1&hqoF!!M3>I+sPnf(ePKVhqO!<(o58rN@o?Gz1IjOr%2iD6%j$i?0X;aP+UD;xX z5(at2Z8$WcUBfn(byPNJ<3+z-3Y1(@k{{p+OUYu90xYj?q6(m@d8)Ar5$7ixd0It&3YEg(Q z>0|l03yXRIu8wLsW|_JXug7rRg1M;O6O&x!l6bL&%ep@qH1~J{AhKVBX=`2o&E z@Z0upaKFL>m^c7((BZj2APr5|bnw=5H%wX)EX(a<@dIeSv>;k}$9~~NJ#{nZ!6|2o zI`t$!HFt`E%y_m%G~@$^e$dy=igD#_j{uYOrvc3Y5ZlAg>Lr9yLS6fOgs4KV$rew) zRl|D)w_((PCp5tA+U>p4B^}%$H+#MI+aXJt9K`1>6LT_#8$_m`e>3xxEG zBjF0~9UL5HksY}<9Qktnbr^@qxt(kc?A$P{5|K~Cl`DqCExm-_oJwUzCYc4L&w%nb zV7Hy>-@7OT*(B<3`t2ve3bA`m@Mss;XkKum9a(aM%5g?ow)^TL3wquuQeg+>Dg)5u z*Ixsp88dZ?L-J*q|cyE0Pd$W z_=e(3A99n$cRqJCI&r8P#DEj1HWs`j%3^J!RvCGN$s-7HlHy zs`xDEXCek!eP(1uRT{7jc(|)Un=CnX{dSQ!p`_h-IEW-(aC@et(a8C9UoS@?klIHl zKE?$>P%6Sg^$0g|s7LT60JAnFDJW#7<0~t?-N?M$h52wLXD;1B#OelNKvCatMwoA? z;dG|UkQBqG@3EPy&bk`QF<`DjcQu;g*RQEs`qTLCrC#w(HB=4*GfNvi2veL;lLXZ% zhJ+MdfXtKyq^2WrOL;v1UB9CG^YlCVP(VgQdXN#uMv}>M>^KdODYfrymRlRI*gdiQ zy-d~Jw@?Y^q7dCuX>NefTYryDb+h>WW%Zts!tq-Rh|n;V*kGvUjeR`Ri@7KB*ttZq zp?A{I(q{F;NWz8Q2B~-WLTTrJSdA1unqXCc#RY{E-}SzTLmYoN3%+$;t5&)6u38|_ z*^wzprpTt8dcn*NuG#gb9726ow zfT=_>GwFdvFThGjeK`Ro?oqd!H^8D!szio7u+31DqC3k`*SGCjt`@up)O=sDixi%$ zJv5|vgIcUtP-~>Q;i?pI=YS8N!50R|kqPDba^lT)yIHt$^!1w=)V20m`|AliC2CQ8 zwvVd+-fCIpak@?M-13LE28O<{rMAq=Pl7TlD+uC7BPB+WG;JX2%FeR#0@qmimF0FN z)*3~s*JHn%lQ5!pZHccRx}h=%;HufDTSI!k3@1@1xs4FTlF+Ma@1X5^E1$RGB{GN& z=5th(oPz_X$$vBgX~2})(BS;0>yAHXTqc5RS9>f&87lHxT$UKm7Mmt~*L{%g*6fc? za}rnO6mr)qLa6fPT?Bcw*k>th?+02SV}%SjyNDu`);2;qdDY1=irnS)0_cVM}3VE>6vxw0n$)dIQqi4#3-96LX$**cl@zSV* zAbgB!*d+t&98*0`0eJ*dkHm0|@v@+ve~v#DkB&|~Gcuo_dId!5;<8vSFAx4kkHF%E z?AsuWzPnPaFOrE3hhMJnKM;{33y~zNZy>fhnow}4>jE6sw%`shANai=f+QvU2S}z` zp}DtWwmVJ81?5hzyvN+%~tUgy(YW@hAQ>}wMfdY*udsROKP`vqm8Ij8en~(9Pj$^_zrOluUu8`hMsg~+)#THB;oSm z*BG|om;!J`B}P{y<*MYA_{n>VM*FbnW+B(W;p5cl2h**DF31`6(22kWdiOH+wH^U&c`v+(uye=C8R8ju{nG zC-jn~=O96Mw|G(}1Y{_tc?!=k04&nPL`hM6tc^ z^Px}USfgLd?Vnsrcuhe{K?V$F4>u>j&BtcW$#M!Pg-4JQWRiWAmyb@Uu&ymOO__k= z8G{4pXxD=krOr=!={yrf-5~wws800s-)Z3S{9${~@4A{I7n@{04mY*{ilGy*8%Xnm zA@RMnCTAEk{sX#>QP+UL;=e4LRYn^Ik#&8-hHN*lY=oE3(0Ev_b+Dfxj_mo z;EU*yf`IapSo!7C^a%vG0{bO$@K^xi*pCHOPZvUuItPGGH;u3B7ek;uMF2uA)FSE1 z71HZ;5|SI3x1JYwR}Z#pcCWlaMM!|+?TzgV>8I{*!}(O%)}&r;Cs(3nR*Nc1JAm{! zLi!m$wqkFyYa+IC9&iWJrp+qLIR{O9sToq{P^~o*1GWVNqPcDep%`hGLgrjNe~C}k z05U){Ko&()HzWz?Xva9q$%uJWUlH*03Oug{8iX?(;o9TeSiXPM_ycf_ya|hYiB3y& zBAlga=v#hr3fTmXgM^@<41fS`-d!Rs`i@rPo@EWMA3%bZbSeWU8rLlNAgFMNKjT!v zP)+nB@I6_KDW0Ty9ju8luT_wvy~pkgDsXXn3G6{gA<|Fr$g^I8Z(txoK=1TIR#L7Q z=JW4o$XUI{A1-|9B!F3n*K+Z=iJ;eFWlCUntl&2$g7S24;m`q!;zk0=-j_J?nL6Rf zbBrsp$bwa*eFzljv@Q8dXWtnqh}l>ullEX{7|&1ogWo`yq)Qkk4%kGr&l7S%mlt0E z^7$qvpaU@oHOjetZ$gsTfIMom^_022S~OY)>@01?HDF)RfFa0=c1$7h-hjo3BY3X{ z43`5W60aC|;oSgEm;tGFYR}V@B$p~7l6V$4`q=xOOa;v+B6EV1rfM6sr zzT^g$AdOhVme$N?Z51G~3848BkQ-X(5|s-PfvQXiAZ_oNLLq5D-|bk?f!iBBcEGZK zLD8LntBysJjU0~bQq%;*bFiq<@g<{>;cD15pV*k3L4ZrV7v>>}_Td%qsb}MR2=246 ze?oD&`RD%>4D5^~cYrc$T({|ZI)^4PZAkoi9{eZ4^ZcJ*uTKHb|L6tW{(}*H5I_Oc zgyI6bF#+Ae6=ah{LnjfeqL2ueL8D!lDoIA#1sFunKLHI@gb(`v_q9NfGOP4|Uw@x~ zT1r%uudK8M<6sgkq0@%^K@qINDqC*T5PAz{ch&{A@?slb5^WgS4MH~MK524P+W+6k zD_~^AUaiS?futlFZ3{3LB)*e{*&*mUp6ON?Njn1?KnoF|wcGwTETn+E;bZljJTQ?t zV4V1Xkc!XA^B)KVLBQy`KxJS(a`w6KHzBzAuXka&eW5vS|7j)zAegAK3qzc6-E(rk+~9s#aWe_QmHY?18{%t~e{KGr zhw^)ap1%P^NPG?U*T(5$?28d5!1B+4e8gwyC~p)1a`l$e4T2z{SOM(&3L)^LBp^n( zddz78ktKV&BaI>%TVq9QlK|0(4A<~48vn1HBRl->a5PuH-F<^s;3bxZ=(jQUz$ovU%oT`Z}Rjk zsy0MvK=ilFv@fg-D3hV@pLue>%Z3OYRikYDY$77E6zmP%+WD2SloERzdh!TFV9AWKGXjgL`aTNB^*$y_32ZK z?Lxh!q(RnG-$`lm*JCG)QaAg%cApu~&Qq<9Uw#j_pM2>5Zwx+06-6E3J_jm)<3ef$ zZ!v$(l-hAj_YN_n)i)YvPpX}i03nJMy#Gx~5(7C@JK{Ox%QoOm^_cL5g_g)VaS7+o z(B`&z+D{C{l1Knm3+w*TF%cCkOhN?X}EaWCg?y=wf2&6cR2iga3*8Z*jn z?fQQ^KzkD|$*NSWoK+5#T71RTS$)#hzc9GLR-V*g?mHbi1sS$Z3%UG{{c@eT6Y@Pk z+Y2oK^iK=uz0&9e_2^$0lsV}WD9C!l#1i)JZ$#~STEdjv|A-G$6GCtRj9X0rrh6&(m>{ zQp2ozZceD2CCHGkZS3F<^S1eGsf?%2!e=+ndm-5X)zH$=*vxwSf1F7pY@Fx?tN+U2 zpX=SA_P_n2;gytMRmu#XA#gTQy$=3A(PEd$5p4Fk`ZxoC6oFV&*LoR*y)>H8Y?oM5Ls(fBPQ~UWfjM{dRT{t*?FGcKNV2gV#Tk9=%b^r4J<*hq@+# z2XkC*DRl%xW#2AhUagiQGml~Z+$4Bjr!>Ov)V0T#eE(Elm6!k9fA29uQ?q0S@NI4Fa{_D8EubQ>=EYi*k?uYYgPY6Ca%L~uM zRN4OYb5IwIV@m%0kNu%9u4tR7B?|XX)f6)GSt79SmyM_EWT{KOBTM1c0<|1oKD6|o z<&A960YKep|JD=#iYkCdDcHCLeClhfy#<(Ll@f12Nr(|A(r#aH#4F z+J!~B4{)UO(9$5S#Np5=snVTFr-Fo(hmaBpi;za??hfgY?vO6&zU%mV-+RCBAJ}W} zz1Es}=9y<^n2DYX6BE0jo}@W$oHL*bYLh+YMNt1c#xUTLV8&^oVfnO?b^)qTT~=J# zr;+Wubrie~_rDRa=-4+CQl`P|emXN5252&$M+@Fw7pn%@YPy=EIT(|NhZp zz$Jbzp3&GIeKzD*c3+K6a?REFc>W(nKPeX{uJLw;%{l2K zSJX=Z<2X1Z^@So*Q317cq*y{W{iCN8Ii$#(IMp-g)Gwz`c~9)T^ueEUoc(m~Qy3pq zUs>jSpu%B#Q+hZ6zeXH&lCafhem1=6r8s^~C1RiCRe^dGToC<~tg28(nv(#&O)9P_ zq$5+8arv7t-N^UiXoz?V7Y(Y9CUdTS_1f=my%Ts$?o=-O*O;oDe>-M*cbC~&`oQF8 zW19A{VLBU;$cqKJ&6SF576b+T7_*9^3I*QJfTOK(^;^3q5{qJwI^tEq&A2wH+}k)D z&Qzt?Q~PH^FuuF3^+e#%AEj~2Z>dFX2lta0nm80r$ok^%O@?mTpbFU)=RUUG)CzyO{dOO)7vU#^3q41#?Lf~s{YJm~|M@@E zftSHxQ0>NLsI;+bt#%T$G>v$wu)hXDaor@|R81-7%=q0%9w+1(mgybIY8kc0WtHrG z4*8({;5+TF^?(!qpXY2gU!(1knXZqlkis&pIV}9&>n>W3W)`dz)+vq$}^jL~Lav|VD2OsC;N_OI#RM|T#@ z@JA=JPi-MP)DK_r*IKth@qThQYhz!Lc>ll4N@J2sk%kk3vLG2{&DVE!@uMXFyfWfw zVHLD}ztf@mZo@6q4O{LY225Y^w)u#l!}|$A&B47n@V_;10I#A$xVrCR40?Yo{%6GF zsb_1w#!t~H*T-4eY?}!*n}iyln*+iL5 zziswDGJMu=a^SZ=otN5DG+yfwdeDVf;y?%gpio8hrbHbCb*wVcucWS|chO^r)<}uV zdI>`i`hEu!ZS{r#VT=N#QD3T_eh2t>wQmpgZU;Zpxm4+kZxDgMp5bxrkKGda$VQiC4LE=7TU?xaGS&K7NuWgFnDFa}!J-p|-o~ zJP=|Qb{11xq+uJP=HXFJA5SFx_rDt*QlvU?X|^;lzI3RV=f!aO^1GFDT?s*3;v;FA z4-U&S`*r}2LbU3d272lTzmCtWL9xnaCV%)Oq%}e%n6_?I(uni{DL~Lfv+T2N#^x!HN~3UC;^!1O)S*KEEE( zR@EOHi}l7(Kl_QB7$&*@?0-xZdLz;8P5bw#v7o;-ju&ir%ehO@^Hqo9@7}P1q1`YMZXRhz?%bed(KFKRZ{w7 z-Dn27D+_Kap|0vk%5>cldtTVnWXcZu)&o;D9F!eyBRg|BbAwtq&-RWinNiMfFC7+W zq+F}{c0eyCWo4Y^>LxFwgH zK&Ph56J-cT*Cke6nsi+KQOkf%=Ew1nW- z|8wavIcU;^{W9#dar9RB%2 z?l0&6(;`~xiT^n0PJP(m8^;UP$IJjCj0@~5|JjB$D7_gC0(xRYJ&Zr{7#HzCHJIAC zHPSInw@aCQ^tKqAh!)HoLhUJ(`poKV4S*NpL|m`gRB%&g&WcLECiv%9xkb@q6V7{p z$+f3DAJkF@@AFgE-jQC>R+nhzeAps*RNms(##m$6gDH#@nj~*ac$sX!J=0HjR55_6 z$ol71GBlbPTKOy%495Fji=51UAR@}bm#kmbd+}ycZLOqiW@=wLa%3LuJ`u`CgU!v- zu$2!eDG|K>-XYUKIXKSxutWeb&=C{}%^DJJX(81P3x)!#5&?pvNQX*LV?=!CG5Cg< ztGl=O(ggl*j1#~0e?H_VXu-Ryy35t}iQzRg!eOPmV8f$SY7NzVzP!AAjxWFx9DYQS zgh$?ui>Tz1bGhp<-IK-G+~h!f!E9GjYHE;L+O~eN8nB=(Z8J! zxea01^=f_(RxzY%yN5`au|aJH2 z3V>!ofq3ggeCUN`b%OG^TI|P&QQ47iHACzg1)?!Zm_;$~YUVV2e+ge;y zmmE(M7J)txZ+J@MyNg9gz2bYxqQ+4M!+}>&`qD^W0em;Y3BE%p1frS4YJnx5C`5P< z(+Hgb+elhX?zX(JLPCGfzbl66e^%0MYHS(s19cG(7yNMMIx76 zS;TeK)z7P}T<;>gFZm!y@|lZEE~2^LmAgl(!K8BdsytDwkoXg zgDJgFID=*FSM!t<_DUtUeBF0vCMC7OA~@a9GwrkALQft|zjpifp6M&`b#AW@1|`11 z%Dm&QBs}F3gq-=n!FYp(?m_hhWE9M9;fKt>FMch8ljc;g z%8R@LXQ2OT?)62T=f-e5I8jomgW)89Fb~q269LYguztn`4O;l+#T04z3f7dGJY;oUPuQ%IsnxiXzs=U51Av z!Wq;T#|N%FDeqAv%DO{}Tfg{!XA$QLc4YxT!XEfNqYxuOX7${Q=dwCxk=%{8A76fb zL!))is1sYxCm!F6puR%Ne6sAn7~S_W0|Hi}rPAG>;G@e#Mce-_cY|KCLYcF-ghrvP_Blxwk8 zD2>DY;NAx{Xuaj{uU4A~MSk2CQo2Y#qG&DAeV*mA{VLke##T|5_)Vye?_h~=M$qQ+ z#^eY%@=)N|U=UbB_OtH=^@G5`l>-b&4ecs=oc>HU!oajz+USUEt%9-2aLe+=%k0_A zPyQ7Ra$vx(_J0l^%D3;e@56x%Xu&A}zNhzS-Yg7P`)Hy5WimgZCg&tWFzHD$w}g#C zgJ3a##H-X)T)fYwwJ075n7Vr$W#I%u#I?7D{qA_taH{lYNMtev4JCparng?n>HzU5 zaIk#A&`5>ib1#KX2okbItlL(oR^-nL*6Yk* z$oJfv+qu50q?0yyAB~*XFy}V@@n_mB)W8@C4xf;ZfljHth_YGB4`a!M}5w@6LycNZVMN10Rtiqr;&3m>Y_ss!{?#|$U` zIe?-*-Y7J)RsDjPP;(|N?*`DR??0QI-Wh;)Ow1?XN7|w3io(0rE9^?~DhPtMFis7_ zQ1?evT@>cL46u%zx5%#;cro<}P7+YUlUVzy%6K=Z%XU|BM-tP1F( zcf@cy`r(N)%FE^YyP5@I{$xZR4~q5}jz7SGAsP+0tY0=h{O;EX=42fH3(!dE7E%_n zQDE*LN`dN`ci%shHBIV)f05}zR);GjCFD6h*9~26JD9laJWvVlQTy2DGCl2_e12Z+ zJ1&?!1>)Q6$_PgWVPRp^&jwLGE;Bkc%wac(eHYMiYJ?v#SC`OL6G)LbiS=(ZiK9tLr}`-A01rN~?C_f;w(6Rr&?&IbyL!fk^Nln&xA6Q@Q@vpCP+*PpW zNqgZ~VXNQuO?e4hh6)X9=WT>K@$ut~lcTGX|5I&?D)~iD6~+;K2v-@pkK5RuNC)BfK2gwYOfmURU@WZ=ztpu7)iM zA$;U-nf+)v1t5qits{Q$U+AZqr`Z!*_*5r!kB&X5RV6-&bWs2H@P8cTZZe2BPNX@I z{EH{-AS_J&lq{8)SCX0{+je&Bizhk!;aBhSenfxfOGuO-rc}$eNoXKjC!Jf}-0nhi zP`y(M6dkJ1g7&v@y3(oecHOtu3s9x@eRWD!)a@mGkuO+j_{Fs^0l(w1l(=;n0|5W) zf7hv-ZeMg?5`~t$-;9#35qf8_eY|UCh6l6nxd%*VMh{dkSx2z#Ad}QODf$pglR6Yh z_W8k4ca7W0Yv1iRsRnN}Y-1JN_vVal7Y9HR2iUKU6*vxley?P@xe^V5H7X=AB3`sbYBiwjWa%JmGYt0n=3`4KG)^K3d+Q;HSOz#EN1XgXn zV@YLTe^z+04yZ`fSAr|m)(x=PaXVHl?SH()L<;YP@)A7sw7@Fe9(lAlF{%6!0DWHI zgFl=I+4$`}1V%awYtb~TIj!&`7Y~tx%YA3GMN9fd)rs>kt~bw)x&w9HzD65nNiWe_ zFsxS;yDTg0O|!RSg^(Xu0nPmdEI>+SJ%0soAW3=-kYy{>7RE#&m#9m8btlkSz7x|_ zM3m%9dT#$0rp1Zxv+r~5^Ch}BP679nD{HHy!eG2(OPF;XF2iWVyKVb?!djtRiz@wT zce=e8h4qC6FU$Z%r`9_VF>7CeKbpa9T&HV7@JU2mt={?eJqQZInEKRt&H0gh@%COk zpL>mc);;H&-}e<)w{X;$P5m%C{)!ZjVFW@o$4#TL%V8%$Byj4q3ea>w?y~dS%U9_y{T}%1u6I2=;B-X9*LUpl#B0OCr z)0Cw`Y9N73q=hq~bEHUZN`hW2|74Oepnm9D&nzZRK!f%F=qe1G=0MD;=+yu93TBiT ziTRH{R<}h^rkhqH&sc=qQcZOyTGWGS2~wuZ)w0-@J&w1=2LQ?{mP?brTa3yh0shJN zZPj_@8o+x61hKs13mxXj7u92ALf>u7i0!YM$-MF{8g)|4HH?jS|MNw{`!xFuITE5E zVe`*ig2_GOYV8Sj5Lkij^MVNDB2kRhgc^xFmys}XAMMtVX z(N+8D&7~sB2oeT%LJ7?fMd^;7Op)%=LR!Q_>|7LfFn(mx0<0YwG&k2#c(CX0_= z>GQOhMesk6o|2auL~K*?q=3NgqZrXMQV`~tqc`5Uy(4{)U&`w;_r=D-TE&DHrmHC; zv_qWUU9Kjz^Vh_rFgoO3xGKn<#0j8kRAGUE5DtPxa1$uQjk?+eZByTAA31KB^P$`wA9_6 z-2V&>ipT+k7r0K`LL+PYbLDC^Y|}m2gLthm61Xl_CwfBCsuP$G=^4rqbY8s&-j`NZ zR>1G7(BT0&Uzg+_PzW?M9qr7ug8)Lf^dj}8U%UeEvJ57%h*GI|huD;d6^0@;pUKjqwXL5PKCaL)t8D@NBC^LML;OWflYmdTf7tpXwC z^M=n%u9jJkTZdD-aKpbs%)#Avh0Du_G@PYI4^P>7ft$}seNnVnmpa3BQ2|0ZPI`?F znsG0~wM)Q#|1;*zjBuR74LqEUQfNj1M(`6}%XS5|>^Lgurs@1YQ zo7H)LPdkhk(7khGY5>>oOYy6Nr8dmn>c2E!P}!S)?bsAewN^vr90zp1Zojm zmpspBc2Gfb%rEvEXiIB(q+N9se07TP?_i~xRH>aUG3;*NjjmZX>&+mUGq9O4mZ(Pu zx@3G3bt>RfqBQx1N`pUpQX>~F9eOC}H23gdo*<05Dr(t#4v@c_H_adaU1oWXA_vOh zOT(U|&}MI|^Qse{62i46z9}n;jQ|`WZAK=ozVpcmRFdNM#Wi95EE+o2t9dD=8`OHG zKBv2FN@t=se`rzptjmS4+TV%M=jl>>DBh!=JXewldxzM6pW3%cu#$} z^VSqZY{kjfuK2QTeC#He=V`F8_vuX%0H;sM^@k)L+*J{f<42gAi8k&aR@Ev8Jg{s^ zBFHj%+vK(7N>XfMOXpC?ymG>0BE#Y4#zqTXHH51ol9H+kvWgoRU^Rx;=6lQIjVIQW zT>@+dp%79@(C^^+X`&ROT)g0ClxLOWV5vZ(IcNk7G0TeKXO@!H!tU!LHa6;MYlf7U zem6?;6(3eFND{h@UV9}c|_O|@X@3mCUvED<78W8rS+CTW}>`N^6%u>1gOkiCylQ+5@V zQF4^!Gz5Bz5c{#Bm;Wy19VbV|E%PqQNKX9RTd@qA7LtVgY-884x3sx;7 z^L_q_JODTAU1alxg5X9CWN4jHnN5>uX&}sa+WyrIAa+e*98#gUdlekY?)eYhMbvL04j~VNB4-xNy-+$e zKs)WA();MVIeg5KT@0`QfRJ2OJEM-T-8G=iAUwwp5`$Y}UzQW@c!qyXNnV|1st7Dd z%uR-q>IA)P8C21eeF=ae0Hd~wS_CAB zZ@ORnU(Ls&#R;9lYbS90v#^@cnF4JeLk^ayBPkNpdKvModDryWC_;0Rlkqsnk4js% z-Qmw~fASNqo)@Qh?o1spv4Od5`Yds&Q{N12Q@9#Ix=Ll}Tb)mU6uXj>%x?w29WK7z zx{sCB?m>?J8xUDS!a~0=(BcaMnlAn%>14^SnEF_!6uvoeD(NfSWD3@fv8BMssy3d; zoHnDhrJj~r`{D+&gfSpB3yW>1EwtPwOay!|=hQD{ul0jYXJdYPs&3Nf=blvf_=m1x z@j;b6y=3se{QyWGd6ajXJs$lp`+`~)ns6tO(nUVT^n80h{+B(P?I#?>xHmt^%kGX@ zm2vCYQZ-;5{hBu3qGN-Q7br;K5r|J9@6WEV(0CxahFX^TqR{s|iEr~zFm74E>fOAU z-gy8#B1Q=S=z_v*MPaA3toN_RUIUUl8OE$+i3Q^{GJ9+LoEM?YOF+U?DxE+XCHf>f))8x%%fgXnG259?+z%TsWaQoAnWUA81WKT{04iz^g3?3sw z0);tlqlFA%2`Ss?5fBl`)$$mxQ1YAbV^ew(KD2j~t9V(_Q(P^TPeu4aHoR{&;H7ln z%WsG&!yYoYU^<|RJpA+JM*YigLjQRHA>q;@%)G7Y1cAQo=zHygdq^o+0?cw9OdddN zDgNPqe{2M3*i+(y(IFLkf0Swi+%?DC!-?QFbR@1JW8>_}tN&5B981-fO7Q{RFmhfHmLMb1bJu68&FLFg`YNfo-&Spc2NSHj&B=&1VqV0BpkkdR*fRKG z+of4&DY*BONwX<N7ZPjs3*mVo+9wt3NS+=dSCB656Dv_kz9b*0^hu zuFoIu&zB?gmNHi|D&s7SJh2GRLT`cn1}f50$hTiTk7_9Dic^?I7C8NePL* zOj`nFLaYdl9)q>w%=S*xRk}}bOnj2uyGZJ@7=Y7FLUE$F=!jt*g{hc$R$Zl z79b3S!0!sa{%h%beYI^9rSl|c77z1IGt}4 zYX1cTK1VLz^Qfi_0E_??D|y%>F!FAcViagKccGjv<$A3Jn(SXS_P9;yB-}Mns6|Q` zgnX$4^bd7S6r+Ix=wB!h9mhm%`Hb-a55;wos~KvA4nyD2aLKhCW}@53xq;qfAr!`F z0hcm75U5Hw@wZT{i*{LCGb%kKyb$OZ){Oit;*bZ#sHx0ez)}m!UA1!VJaGdaau$LM zH{nK9q>o|W&pDUhZn=60@tk0Lvlf1j3w769;NY=Xug$|6R8dKH>vU`N+iUORuTF1- z7u_{5^Yik4T_Q*nE{Kw^KLM$Rxl%_fkUKfgeHq#8`|)Po2KhvGpNSBX&i2`*p(V=J zXk^RUH!JoNjhr6M`&5PVMVM>pilz0I#`R z3ccBy*MvY=$I~lSmw0>Oz1AnblbSrl#`!2(B;&mLK0%fsQV_Ag_-inQJ28mw7L{(7 zLa|{dJJV~|cX7h7p!yl>GEX^iC=Fkc2)N>Yd-G4Y39Qz|fxao_7G5B~Ywzdhe5u>N zymGRpx`d0U#OMQ^siAA zS?gU3Ebl4U>2yFVaH{mWXm!jvhiTtg{ROnF&u1r3DK>%TMNKS`;r6Wafbu>4(0v?E z%DM0HuVxP@%8TOS_Ov#?LP!lPzqGTx6V|kF`n*^tp3N%i<80ojb;z&%CGFKalN7ED zyils&pF9QxJ>KMt9CwO3r-Cy~`UrUZp+M+es&jwS!W0R4Oe`MHGj_rdg1VNZs$#<@Xe%$vFH;C_+ zVp7_%NN||k33*s3V7k-!xy~yX!vctUJ^X*ljiOkT$212&4za$H&p?JqQ?LZAPV)sX zJ($`Dza*-*dRXWvRcsN43@#7968uhew^SNCR2XU*1gc;FyV zhtxFc_|7vTBn?H^%Z><1?w9sH?B|;r+Eba*%A^dnTNQo$dq`#5>tLxJ_44j6GqMn^ zHz=W`NfOG9@WdG|aehQ4K_zbA%`1yhAaeFGgl*Rh2zX~|JnCD2y=M3sMYrX&qOF(6 zJBLTlo?%lo-}^IIU2#!@^Y3 z#!;bkA4Dnor(O~W6g$`d*-ih1Epx;{Ziry~Z*|e<%c#N2Hn|=^p`l>YP*(p4nbtq~ zWyFJY4Iu1y4(FU6Y(&Kx+q5&8Pm(Mpr4&&~kP3|`DI3#N1w`KF$@0tA(AW5#7$ocv zKQ`MS#t-MY=?GZ=wrzaMV9Dtk%t-d5eF|$NPYHM%!To)e;Z{D0%Tv^=R9R<{wZsAV zHp08%S3buOuDs~O&cZwT+8eHdy}>bC)@}AeUS5ycEF^B9;>&COmaqqfWL$t3Ni&%M zIQwVieExI3LRM9NN2NwT6=4T`fAo~zPr}+SR#lwZanKJevoJ3*@l>ekd&%W>$DT~L zy2pqx26la8zl3s>m2{|EhH2W9kd-cIHaMQx9f!KZGazhN8Q*W8C3*fi?H{>pmQ#T* zg}P+RDA@)0=_oyF3b{OJG|WUPw&+)MzbF7bz~8vbN0wcXdTD~3WD<_fxdz{B!dlRK zm(z;KJMw{i^1B;@cCmgO416gD41zGaTtot8J2@I~L=Vr#Jb6(wUo6v9$BxH(hp=((j)i z_z}eyCr|HBrgnOWvfWS24G(GK8wRjSBbJpMVgCq}OdWs492YLCIOJ8g4{A#c56AQE zv-ewB`zHo>>bE-=rrM^wt};9nD*j*9!`yCBRc1ArIY7}$Z)H>XbeMw|Uh0%XVucZD zj4Wz$Pn$W2yw#L&l3MN)+<-c*xiSC#YQ)bust-)$O3eE*1fp}Oyg~yBkb8|RIiVyD zbS`H$M_xu&);17QIgT=%uscZWv_{!diOv!%JLdv8`T9V+ifRT1j<)TwiNG@_Y)u|g z6YrDlT&Fs9JFic`YCfYCIhqo<@absn{OGc-s-}d8dJGPBzhq%rQJ{cTU_7H4?#~g5 zxtz)&(2Aolq>YduWhhM!+xO7-pK8lZ-(^C$-f?W+4a5N2*~4U{WZ((7G*msDv(2`# zBCjUQaAV6Wl|NjFz*QpcL&%5GW7&|$u_8)KxQ-Q>d=8EHe?^VScy3Q3g!sTyfCvRW z`mwSSZR#M5MQ!eNwlRmt)*oREj1cZ^7=<}L`73-9Eow`yGDlP1feXS0zf9LYW|rh3Oh)J#fjGv|m| zkMeuIRnLV(Q%Cf3pd=0&@u=_`<#1Z0y`zb|PBnbUMA8J6560o39R&&9nx3ci>u}9T zaJ!x7>PFI?N_X|LqMUv!_$P9>!<7WIyu9Rbl*8g7joX5S&2qySAl{-L#^5A%m>zRN zw@%i1p?!S4=LeNaDP`{!R-jQG1AVtr1urGT;i^OtNX&va4hQhmy0pO#YvB>`=( zQw1Dc0t7CCco>%i_pd5D0erjw7cKMR_>g**_Uz`AtjAIMWa2_e7Xon+B8=s-e`goS z(gI+Debd6Bl6>n#FzL?4Z@onRse5R(2g7C;lCmtW%N@4w?YzeHZ0yKT`SfT|Lz8B# z`UllN&fCE3t;1uHj^Q_3KP#!rV{IXGl~0s78L!LRjJ>-*$Fe>0p`XE;!%kCAX_Khc z6hp^+5E!@|+7-y(<^zX;qA}bLnE2%DFFdPALVS1f*>e~DDc7KPfpoZi%_wcaAAlV;>UZzj#4S0&8L25_c=!$>_idc^|IPBqERTOW;%I;tS?UmwiwM zmSH{hz_3qnFH!iF^YsP)(ZH|Zyu6_4oYHGDc5fkCCHZEx2oH$X9q=*@NnmdC3sA2$ zYgKY%chl{lu8FdaQ2esqAG5gg!)p~_q|cmQG+V`B$pIOkZK*tQKx%B6oVM+`LuZ@Q z=fIZ@lhz7LYWyZq%*lf)6;5&V$2OlKaXuNYOavdXN~z+DvlM*8(cahZ>@*xGIEB82 zZaGt>y9OhmcsyD-gEl$pDN-JZUEV{#uet{ERclQ8Y@dgotk09@{u2QtG7I(H>1IyG z<00Y8GA*vOQY?e$fkr$Di4I+VOZe(OwRA&W?k0$0k|qd5%SM@;$fkW{p!Vwtj&Zgf z$ub^XxJQI#VPQr+miP2}LT^&bApeAF*~#H{a-fbXxDBL6NHLvDCu=;mYI%;m*|XfB<}Cn+5Ou3L#$hQ5Y9fSM{?e{}Q}zIAtl?~B{Y zhL01T4z-?h1fVJ!gbCC@m+=%7;{2%XrH}MHu3b=gv|gZU8()(4L#m(TqWO35>Xvyp zBG%M;1sPA|;bjvXGpNi~rY7h9^4i-ev-e!5<1DWd9IO7kuCy|Tz>7*SOo8pY7L44gl8n})bSpZGy+!3RzL+O_t0jJ zi-|?e5T5VxGBbhqn7oT*z3IiSTXW#WjVZ*8(kI_e+esFlj{0IQ2<3AlkB<`DMXj5> z&BrbHnSETlUzVZl?dEjqHw`yGlnS{$HB8|R2DSVOQqK2^8HX}=pF~1PC6Kzmjd02d zDItDG_o+P0cV)hQP~V=ffN0&r?Pdi;PXS{lM6`Kzb=AA3rba)Sj#czeC%x|%>a*HL zv33<&Lf=tTrN#9m5VdAVy9orncx%nt2$xB_$G5p#1A^P2`$4i;WJLHl)l72nFNV_7 za$KqS`dOBMO%fAyUTCUO-DY}0A3Ek-1QM7}pFPV$WdRajy6Tes-oakWSC&h04^PUW ziMsq}U%BtyyEm5|DXQgZ)XSabSkZcgk*IeE-J0kjH%!^M-F}FLb-BHFnLi|hcIqd1 zIGk5f`Rc&@cdmAJO^@sKV_ujXDjlpnis<9d5ekMy`Pda`FC7M$#N)Kw-GQ@#39wKS zj)Lp6ooS3id9}%&2o5rYu35F^G&!1;IbZa7mIlj)+x};iyi3St>=d`PeY~PX(1{72 zjtlk#Rur8+3|;nL}Py4TT_OUBZBT*8}e>oLY;)B@)?d7PDsFM9vk+ zsV{RsjdfZeo!@^q0uydH2&oWtH*;;#|SY@lJ|d#KlIvO<->xZ6dXt< zbdK@K6744k))3Oi;9F@y$G}ps8zDe1_|lAo|~v&EGvQyXh#S^8i=n z?O!Dzg(?EU_jAqlMv3ptIi8=iMjeY@8P$3oM@1rV4OU`po1B7UNG&Fc%r4A(i=QaP zn>~m?d;~kS`H}-nY*lyZ)Yloj4a{Yn4eP^MiFH}aKm06r64`^SsS{Oftuj@k5dklYH&qUhBa=aDX=6Lh=E~SeZnEO&AU4Se=X?u^)&&$1I z%o2+PcluxMj%>;3W@(p5nJg?aa{o#fr4p;u3=5B&0k%geEXYq^YZmXiQfU`di4nr| zRp|>guO-#GB8+aY!!|(^OKnsWThvU37fbI4@{~oTvz;VTXe$jFdj6g}<$ubg`5pR6 zzx=qKZnNn|z5Y9EJKnDXW_YlarpxX~xCMidwc1iM^^fK5`R9O4v}Y;d1(itNQYvGL zJms`0=uhdF3ry;hKMIc_{U?faZW_c*m#@G zztK=uFf9m$n|+%XSQ6`XsFKR|wLep1D~N zL%%M}+2CsZ^NZDVuisha47uu3*0P^+0+Eo8^3AcIpU1TxGExT*guIm6&iTWm(}?e= zGwbKv@U36I`@&wvXll~wE3(+MSUPl4Jp@hQen8YhMc2V`nmn1c@{zx`m(oVJ=$ z_|x25vL%vali;ELl(v=kkZ4=*kcAe&aVA`p3FRw8k*fMF=%V|6chN-GD|BONUXjqs zh9uMz{Fz>oX(~Ap2ul(SiCPdHm?@lJdyv?iKQDlGz6~!Kh#|0->(9sG*4CYLI4SOV zb6$7iVxf1g2G1KHht`4|wNjRYpG|EPZ}Le8K8^cIcbUBQbKzI|(yL?g68e~nLF@O@ zb&=N92(7do&}um~^yHP=dxjzzhD)x)u?<^lX1i*XNaaF*qS4>KF!PmcJkBJ6()%`> zsNsDENNtXL(w1$y$x1hGa@1)B#HAc}15ws1Qg?xyrnAIpo9w0cEI>o3a}wYohlXc#`PFpeE_dCi z3?dgE{lVu=v+DPH>oC=6{f+qY&0V_>R=s-)y))l@Xa3ZfktIs$PgibhZ6)}p%0pnz zA6tz_TX0~zSq#$KP>t#`&^|SneRbJ#w86;rZ))>VCsw4qL zCH$OxOXFT`SLw9R#KP|oXs2B?(IfN9RKE?MzmgLvCOEySyCT+mZTebTlX*I@+lJ&V zbJfW^iwBtDszqG_T>{C|1hBGg->&o6<(M5dGJV%52eR$u4sW2PA?xX~=?>M(lc*{^ zA>#@E_O(vy@of*j#FVE+V)qlKd!bB$UVD4DnbvdHal2lj*B`u5Y-OP@(l+*rdE;#e zM-!TvMK~b|EQ_%u8*M5Mm!{D}%K>}DIvBTenLV_KhdbKpP69q`v`G2~_F+VP>^6w* zg2mo81rD}gQno~#DVBv}z7f%8ylY^%ivNu6$Y%WHkwkcCnG#}fx7OTveMl&S2X_D6 z&Ua}&PDIC`4X$rVOo75*bDEFiWQ_0+S#QP~X068uXcG>Sue8{QL{ z6_!lW`liLDtR?N_I@)7&^MFLvBZK?LjqL;x#@q;*iS}N>)aDM)x71s8&_2NZ<0Bm^ zmUDD@UQPiJ>2rm89VdgwBDd%e;y=+dR%VUD$!pqyAT#DqR8M$UMb941RK0GYrjNW3PvXPvc zi4}D|Sok^62#Q0{qTGxeMJbdvO_;Qo><4c-?{}g+L^$!~$@Vx&G3ZtQL*Ztgtj0f4 z)ihHO(OmSNF&8<(ju$F(l=j!6M(wM_QD64(}mk)^A4-Cc}UR$D^K|A(+n52?o{ut;lh| z<#(gPsY}I_WGrwd44QydW0SO+=PoIw$q$FXBOq}i9L*8&G?buKPS~?BZ!<0nSV!A+DpeS#r%Jz8)3%M$4WiwW7yA-g#Iy)JyG4vYGY=$ro2) zgI6Hd!j6TDZN^O!BD6(91$yHM*Jl8QS6ERcYJ7Oj-$=U4@(r~;f_I0w5#Dlwm7Y)T0H z9(XX$$pijrmU}}^pLKbE-}G6;?@XpX{#EdK8roZ7*~!vriqA!h-ftFfipY0wt}>2b z@YRk!{%A)H>%b|MZN`T-$eD-2wG}RTwd)KQ zQ&{H_qT4gxQ4#l4?1bk%dJaAEfE=5ce!IMlIB_r#66jB6A8U!9o(fk@cpGE!`gkc6 zwRgff2%NQ{Y;}f0)%O-y6h z3XLm!sQo!WSDU_DG>8yRzbBmbvHJiDx2=wH+x+Sw`o~6U>2W3&I>$8pKGNuX=TawH zNKcQSg3&ePoxRIu;TAR`jx&&@#1fCyjk?E7KPJA_J(#?yEZG%#J*CM@YJ&1{Y5YJ9 zwZkvrwYyyoi4#volsPjKlQ1p(nX8NKeE-O?u8+pAx6}1*7Kt56(U0mnPD&P-1+P;$ zrNN--ZOISXh=3fTtkpBCSsi#AtLb3q4*p3)?{eG#<0a;aO~UFmOkH>E;gfUjKLS-z zWQW?mQfTPB^Cu&AHPRFpW+-#H+3nKf(fwNI;Y``dcZFq-v^(ep%IH`G`}#^r3w2TS zkET9{14u>AGzp**4(@vtX=nj@o6ry;luKYENOH#+mk&;#7HWzs<#CF}MaPRVgQ_2s zP-gANIha0@O>j%LpN7hHJL6IYi1 z)-$nmXJV@g1O1O`EoY8>@A*WuY8B2T4$qHw$C#IH$T1D_rR#Ik#q{8vLE=v5x=>;aERc&#TM52jPG{@d$k{X}< z%^E~MC)GzKHi%!Nis{N@>}9M2k3fU144|1{VqtHRt#p`9*pPhvXT;a13_?nRG4%If zMiaOAaA?>P^G>IcDizvelW484U zcAxxfqx*z_?^Ovz@ z9?pu{Vw`M2gG*xiEF8!x(>L7YOSsrN-4+-TNgB3RM5xzXL$xiB;8{6KypI&zdF|Uk zP9n)>lr2U5`kS`pN{S0S$2Gp6<VPDM`h)}zDu-+Kq%Yh+tTKKutEr^h9_ z*rs}Ft-)_co^Ne%u{A7~b3AfzR2*wQ39whp+OdeUOC~O2ptJ)rMrZf`7D0`a$8gS=GQD3WO=ipAic<1?a`sQ^QJq`Zl+~MX!o^U)Sq$?(~KFd91 z-NL7qbyZK9jQ%g;BcEZKO{`HEI4r$FeNd|;@b2;eN?;$~trzKNl=FcM5 z4jD=x{6$#ref;al4Km_OK;Qbl;*ulLQEj0jRb>p#Uhx!^faJT5ds# z{BrE+)?K3aZR$oe!@C-zXz;FYDN$+B_bwi#F=D{1Gn}D<>8wlbQ1T{Pe7r*5G&5cc zeDZ+TwnC3Fh=QNRxMW(^W+mSx8qw`&Gh{PL3$bV^>-mcr{51dB&+xox8>yyhxHoIZ zJ^aJEolEyd>e~}-(2lH)7-dmpH-Ko0+`#WC;ANh%VKIfqOX-ZunQ)LAr9*~Fz>c*y z=c_`~9%H=c(cPbe%2X`i!phW`*pn_XPW}^sAlIoVX)@zvEB|7ep zd35rx$8N9KdJ>$nS}emCQL|Fn&I3VEE-l$eoY-95+5ZNrBmlHuuZ2jD+zA1&yJqdFM&?Yi4uvx|4%9LGXg1e)!} zG9+RIxgb(-H{6=exAqQvW^uWpr(QEBs(rJp<(XR2#1qNLe<9 zop3uk&Jy~Sl|Xia7+s-JEV)hivx~pN{sk_tA50IH1Cxk{il5e&6+8D7<6Hb`3b&uQ z#_5!YDsj{xkCrBJ5q+^wLRo9Jcd#$%xodu5E@(Iz{&dK+h3((5An*&a7gjl`IJTr0 zrr8%3(=eYNn$Dwhv&-iqAfVDP)%fv=r-%fUaNIFD-bqDrzw(29NrVUQNYWymIT(8w8T3CR{oY#9RG2FjYJ5wmK!**Us zPg~RArafl2U2K!QH2f(9M&=(m={ez*#ONDJq0mKB;r&IW6X^~wH#~gu>&vU-2!H)o zrlr9|?=XBM!U!ga!L1F&SBoHCK~gP}K#$3RYXteB(MbU)RS_vFLY%hkjY=_5j40#m z0K;iYzN2=AMjwSvxB<4m%84^yzcUF1?%=U%w`kWb&EkRgVs|f0SR+GipsbDmdx61D ziF`RfFwbv+YLU{YAbCxd{tQN^b41bPy_ksa?0J0W|3a7=az((cg6luj)Wogl9Y}!y7uteJ7Mh9#gCAz{|R`@*vkcTbj6X;%T}Tp9zFMdOqZr#dj>Xbr+EuU zhV*;{v3LAmx}H*g4R~?*$uS|qjL2)iOqc|oge%<{DthT1T2&_4n|#y^C^PgpQSpfX zEx8v`rQ=p6y*0@p9nkF7CW?2V^gKFaDv)2V;N(T5Tgnm^Re|d!(>P=}N9~bXky&a@ z?Rb2d&|TGMa2u4pqlpWuU7?>D|5*rXIb8p@Cgb5`ykO{js47XAVHoA>&KQ*Z$pXSeQy z-zx5>g#>npX>nFo%qUph(}wky^-a6W44&5^VvLTAVT**U zn&2aeN8QpC1Osg6CmW|WMh!06Q;83!f2_VY-Bq(Bh$WbN14hFw(0oqyPrnNJ-?K;A zq+zZl7JcA2)B>fV126~OnBo^O#(b{gGN^-`8gduzj(H=2_Upp!qRJ6=2n-e8!Fm1> zvO%b)(FHML*_r(urq}v$-CJb0k<4!I`ogi{0%CF5)4>|&mskFbdBM2^;_=$)^Yxv4 zj4LT6mKb-z2)6Y{Pdx<8oVh^$?Z;Ou5lu`=8L9lmm8B&^#z6Qzceo=;k4#bV#d`D1 zz0H@I(pK>BJ_pWseEH%}tRLfp^LhysYF2`E(03lX<$?G%c*huje<0(IaRD&(%$Zk9y4)7J+){lQNGub3DK_~HvC+->v7ubmJg!s{qJxkjiguGW-gqX>IbaU z;^O3N=6$Yvqm2X=8asSRp@-)G#>ujbUn3)!%!NZ!P;kZ>@}I7b+Aa}1&18V(ueRpe zkaA!&%xQyEiFftY;CcZ>Vb6IZgrjYGaH3;EZ}c#efkfcW5}RTFOLb0c+8-Krh6wz) zJKybh3x-WXS!&VCQD^4$;9r`U9SG4bomeRbaoV~=1ttq0{+u~V7fuVylZD_Tabz;M znPF0@l<*wfuv3{Fal!1>ZAY@YVB5i)$+5WO8qhyr6{uxf4)^(2GSQX)#&)|}^V%tV zS87kp-y(L(@qK!(Dij(!WlS-CA~f?Cf3GUq&uP%FhX@=2aBL?%)ojb(RIL69?3600 z6k0@gsM{ThWkXVKN8FcXT*H#i4&BLv_X~@1RY#BQ0UTHt$kV`!@ud#H?DjpDnj7>Z0WVRG#zrx2HjVH(-q$pS)_H*If2-afu+5`V-g>Z*+C}@F$!{w?0K2;hhF32aPF`&JJ>^20R(Fin)Zj;SWtN?- z0KTEZQ8B$XZg7yhL*}L4;c3yi(HHg8LD4UGs-3@^HpJv*QxPPWl$zLs=;^J`UFs8O zL{N9ra!(WZz%^+Rz*M|;h8;8SO+7q)v@4EbDiPh1eG&Poff^ajkqd}ZK8%1U_M9Yw z0W2gnAuk~xVVU^JYnp@ArrY&9?a*CkSj!h#EnJmnX4!9hLgX1e|M0xm#WArUfivv* zFZD8uU0QHLh{pshxcIX14q$V2c!aYrrGxl**TOSLu-$wu3LsQ}UYWa*u2n_uyE5HZ zt&2E6IT>>7HqME}T#6(ZI(h8MQ&8DZ=SeRAI>LN%Mgj4uCVIxlVqZ-8sK`Hxf9ikA0V8c;q#1Yy7)upf~%xJ4tVHY1E0*-$wffW8u> zjH0SHiW3#@k^QPI?DgZq33c^r6IdA(Ul> zZ?RAZ0o?(41|8kW4$MCRXF=&J$x7+8^QQNnWLEFv%TG}KN=(x*=WQ(@2)MvB#^sKy zZqXtL2e2X$ls$SAaP6*W8zQdxXxBOy?FiR;C16`pvJd-M4p5%#6p?%E&E9)IyIjH8 z5L9!e3$>>6hd=s?C+{~i%#UQG@C*q$>6A?u=juW9r__zgemWBAYjRRoZ+uX3=zA_5 z9mE&{yxXGU39(o?D0x$pG~WN)C^#n)aA)))a_5d+t|yz4SaWl`vv#1Q?5*5M{q6<9 z$w5Z`+I_6Ke!Rk*pTOj{)i245Gc=g8tP4wa41j8A(~ipqZD5Ksj?)c|UJtPROvoA4 zp9<}>nQEWf)6iG-m5VA-VKK;0Df{k6+o1E8I*0dJ2>8f=$1*r#-lAw2qpdAty_0!z zLM=_;y&@;H9d(1~6+ew^%b?%?sMT%i|DO9TWc`8XSdP`&>-+fvi`qj&r8clGf-=#t z$j}>^U$WdjG)+X+q>@P5ue3-#h)ZrJSc(iOrN%Y1Ig1GQXo?IrEQrkU&Bp{Fc+5l_wIV1Gx4 zxxOg10dEvasKfJY2`Nb#=?Jz_TrqL0KZ;)yxb3tepxSSzNAD6o)UHuZ`c9*CBK#`O zQj3V6(rYYMejLssWYg77+3}o@-%JN34VoMJUcEk$nT+jK1u=39MGb(Cs<9dHp<%dwaq{D<_USJ z(gruge$tkE^yozc=WNUgt+oWemXdKwyIKJ}&galG@eJUm0x+hxA<CN z#K_iS(bhZMeaN6?{So+68qAi!OkhX>QR>K0X&U@_#*sLpq9E6cot#KBOh-`U0tuWv zO}2@BA5Mcn)|f%S0sJ0S#$jK#;aUzWFHb)zFg)1(adA5&z6DgGU$BGh0ZrU)HP-u? zf>e;wD&n05#84B(2@Eqf4(aO)W$L!4YZY5ti}ZA-97gI~&Lwn@S2AWXsr4XBNb805 zJ#CQdm%CHodN@&g`Z%GoL~%%mE=kRGHm)3P-PLyfzB2+CRhUnwG&*jpoV>Xy&A%{k zQFZfGZ~wyS`sS}4R|J)qWNZchF%3zFmTHRH`h!0CL%5Cx5s95}+prC`)rp=#MpA89+V?Xe&Llgr z_rd0jvh{3mwZV$g7KgqM_f{9s9ebESE@r6b45|`}myE=;XdsV6%8JN%BdGTH0>$}&3{$|qCEGN8X66(yq>D4`=PfVouIG&*^mAC5=LCy=`!Zz5B7K@3jZMV9Ie0w$=y1AJACdk5#BK+NTW(intql z$x)Nh^1QVgJU@@>Ew*z*_lOZ>@G{?CDzwSUBTv66L6j(R#3^k*3F?U=FW?;ngRDE} zLQ9ZNjHB{@qs&A}Ok0JQsZEN#)tDYP@&D@Y$>JE6H}0UN0`oZ`*4sAsge^P>Vy7`6~NlR89@1Pr&(_3D;wgNWI_9joam4Z_h z$JwplkJ`H9YC5`x?&0cJDSUFnDU0QZoQN~UW3Ly%s81u-<8%1 zFhNI5X2;Z4MY&plHKjxe6QNy2> z+t5UEXTh*js>U0EMEP9c+Qt%pY=3{Q+j#`HT{Dl5Jm6LK#ZbI$jQ=ny z(&Q%Y;l*imn@!^_zpq{8ueh*DDAreqLnc7=Oua&k*vd5-jYMeKP$u36=j}gOQ|*gI zr^(mLWW|f^d)6XyRE9_r^(wdZ~5CT|Owy6F2)9a(AHgE&v+x z{AO)`PUZbe3Mizi6~waI%`om+ewZa*raO`8egz|tWu790YGLIsPI^*It?S4xr>{2G zRtC<9T|#aNQ-oRK5wg}q2vT*|3)k0wsO3Y&a-^lIK62+>&#rs7`qSy~K- zr!A#^6;wZo7!E!(W0wB$Ztxul{0nS+JouOyP;!CTi``4cBRf?Aw8Y-h`H1{d6>rIKQhKKUB!&_Z$%4D$%i_;L$eueHecsXa0{Ce6q4w6jzEG zr9D@BOYI>#J>h@vP37-6#xtO>61%T=0E}d;jjQ<;JD5<;SoURhe`pN%6D`&*ByNbk z38f<^gr`8T%U8P+Yw*40Hd-bmbu0K~-%h%9{Y)Rb*=qM2uA4cz=+Os*1tYAutEz{2q~i|C4T;jJ$}B>N}wV zmk%hz?3_$qOYUNi%?V|eOAx}*0$l+tk#DlL9?@~3|JJenjY4l>lW5lJz(VPgDTjDI zDoG8shgVyLWNy;H>= zA9IguP0)X}k^h^M?TuOpU9`=4u)jKhC??xE-hrY_;}2e_7^HK6hGtoYEw!FY^2M)&^H>)YHvMzHKLPF~&l?Kq!C@xF zfq{V|Yar5)dr9z)|3S1(V_;#YGeJ9RhA;Xa?1+b#SB~F})vwaZ$+-CDl1n~LHg(7z zhq)u~omZ;L!eX5wS+Q|$&t%UFQ~hz%3z$ngFHl?o905guuez)47YBU~BD{8L*9a(; z1u12zo>67LB)Ll{NNFykMQ-W$<~7XmMA&M8bzx4kywae-*Ccqra$P%A2mW~SX}Gvz z4eq(W5hzl}JCx+;N9_iIAv*)wRP9TQO&L(vL>0a?a}Wn2OuYXJY#VUGku^EzKw93~Xm&AT6*4;$? z`1okcF{>eryCJV%J~jV0M^LgY3m=LX**bWz=TauiU@@I6Z{70cnPM5N{Q7F$$POKT z+(Q#dlt-2x3R?-HX%LKZfKUO4PeP(w_-YD5WXNWPiq~ECWO1P0U6&3G44}+UWMp~l zszAf*5XqXu0ZjRx(TQ}NngXlaS}KJaa%`-SMM8hxZ~dG(B5r?_(2Nhrf&g$QIBq0w z#%l7&!KDl^libj<2X~C$X@szuJokUoylGVRB#O7iqAB(N|A;6PvA7uH81V=zj+^UV zmF43VqqB9YAKntYFj}=(GG+XQ3#D#I0EI%?wQ<8TN3;zVO$H`s(+*sDu&Q?(H`v_4 z@N#1-#Rg$4Y!Y+@m{dN>CDh~0`r0y2Kr>G7Jd6j|MHwi!^CG|G#3pg{l_dFu&*c9I z9HhSA6QN?0oz&FWk|a-Hzfw&oioby6DA7UY@ILXl(*w zJqsx!dJ(B19Al$AV8-)Z$0hqlmu8^mdpB#NKkzy(-{cUn*u|8%>%pOI2ClLp(cD3| zLZS#s+Yhn^Ew$up9Aw$PXJFqYgcug=11XxhWnE(|)8XpjY+ooi1b8N`+1TG>5IBw)q3*Z+3^PTnjCa=ZG;6}#&cGvN2A z+sHa79rZ)Sf*Paw6-Jzh??`7SlRoRC(E>DIJyR`$g@Ba!j@RFR4%|Nh>{u1yk~;^ml#fz+kx6z)dtfVc(cI?@Ga19I84PYM z>2ox~F;|UlUA_q0nxBmmlixKAKPVIYK?~QXKPCQcO2jo1TpT9NbSASh8(ww!Pj^&M z8)=h`R#pNA z*Kqb>*bpR{RDTzAw)$KTxXPrimO~>xH-Rqhn=)3EVCRr|Rkc}X5K@PA@E~#p!L3jO zxHpCE?!KpK8tXTB<-62p6J0ZDXnf3k+Ei>3 zm_$?;;%kv=+OQGRG>>4P`GWKYHda@Rdk7)OX?WF>_04>tVS0raIF6-I(I;u4Y={8v zI3iEDpT-M9jDB9>uySAzaJY1dB5RCy%+m?KAR>j1{1CdbI&@#XKa!nanW8!n*->0? z{q?n<|4IVm2+$HqO}9;DFfunw&6MnZy7pz4r(#l>4rNaA46UqnE6nwY8UD$lP5RAxC#^oJ+(Rbp;-C<{M ze|%g*StpfPL_r>UPl}jd~HTcEO*VxD?cV z!fI8#+ft9Dyz8(XfRlAG2&BrEdeDD-gN?4piHA2>9SV5PcZ(Q;+EMb{C$K94ziypD zL+VkYUsIRDg-Yjkn~tn`Ca=~Y=H<2HpBsSWNs;4L`OONExROgNeq~bTXfEglEe&rz z{U{aYN+t6I_0%{|-Pgsk|BMF019v`Ve@7?7ii*XsfCO@3`t0HGU8DNFF<{O$wa81S*ydx-IZX?a$&pDl-+WGl^GEig zlR$|Q@|8Z?mLq>!y?x7h^V`&dj^umtVXh&;r(g%G#4{eJ@EdI&-OupI)rA-5Ad`y8 z3mEZKyrjZOZ|Af>@(nkqUc14@9NEMV+3`SWy%Iy@ikDsMX?=z+cl-8FWUmAhdTW}i zDbcpsBi8zGR52te^(B_TD3s^1}ipV;P35GzJ5q`liuwt-RZM0W}Jzdx)ku z({yv=hdVXnN3i1j=)6yzdgaEq4GiQpbsA9@;)ZZ5S1FUfGY=wOu~J3tkt~`B5c1}P zUh9XdQW{qli;nJL##5ffWSE~`F!S;KAJk^#HDOo8PuS6X}+5aFXS=9z>h9ZTH zeU~PA0LTx0(Cb)R&`QF=eWwXQWhNp)?kf=w6BR|WG z#3lj9uNJsrRMdKO#9Vh+vJ}dt*N-Gb7sy#%F8rb6LEmFs@#0sfJ(f7i_;}>)*|kmK z#_3TVVUxxk6bdomvcS^BbHz&th12yAk2L|6>y#U5^kV?Qh~1TtSx03F3-#54VxC<@ zo}&iF5QL&76n0Ouu4^ftl53726r)eUGN2g$a<6$l`cuTKFLARu7T%IE!5$wepXO2Gg+QfWM zXvdo5oJS1_&fVNE=0a}=97E|9xiXim+B9)jP2Wsr_tlS!&8P`9^VW3@aBfnT=_q~O z+Mj8j$nLB8xk%Yog1>0;Q8v|l#-Rg@sDO!9%~uafpb*e&lVyMnRI1o5<(9u7&DHlQCX*?5{ne@grNE%B#9DS zh;KAh5XQQtTe5Q|E6SCpe+{AI0<3WCzQ=lucL-91LQ}}r2x4p+zfzr;SL{iMzL8|@ z|I4K-2vAf#m$vqX^X!@&{f(e?Xz5PNch7Y5Hhi@ocn!%0M~#hW~(LH{mBnD!pg1 z)DignyDZhHK;J2`oQ`nvdRK4=@HMhYNEQfHqWo|<`~P=7XxB}x{m?Li%)H28o;A|MRHBo<~c*3Dz_?fgmgec?bC>wHjKumu*_RwSPX*?(I%s`uqRb zXIGoSx?4dSPbm56xIEbXv7~|^RML@8Y|^?E25IgGwcY`iL@mU1^i)B087s;mv8jzL zW&-vv$_d+he43K+O(Vz)Tls@-vA)V!R;i=|MHM|LJrN;N_J35j-pPDFSDo7>_#- zx4&AS7H5(&WV77K!@-4KSM%1jetb{(lVI+&ST@`qykcYeI)-0&5(vNIoV|50(TK*+uM)6--< zE&%9CY2l9UZ7$&LabB3jq+Z5eyiz~8yz}@~rKlDK9vw!a%o|QqJ%XM1)F$KhZ8kD) zXy7Wrr*yWS%EKM`H4p%9s!sV@%kFVQw^)SuN2etJ}7w>z7(ajQ%|pFVPi{nE?(i zKZ>eVp22wD1(RA`{`96Nl0a2sXA{>qalDvWc;TH2ncg4io!qsazBax0q3HA!qqIpG z4lwfj=eiquAL$bXa{qGNc^8I)Dv^jpq<>)3mE@rPki2)Uh*%x}HV=KfJ z-+wakoid3=+i(#4cBVZHeuRj`0*~rO_~gio<$>m-Zc6RULqiqnq{QABGcb;#dpY>Y zqvK4Hi&My9TCjq{JyE_gh^C&9gogI*^yY%(holz2Hz)Q&_YZol$Dx|CrHZG^KTaGR zI*MpF+j!TCKHqICsB@lK^-CP=+{?q%EGZM=l`^%e?dv@L>Syz*?YRZ+i~8Y`n&tji zT29PXE&7)cv7pB)xn1G#qhV23LNJFmx?Nx3rxd;}v3{$zPjEdol_e;pzG1QK{Q5{w zjb}M~x*g^9;4=g!QraD456;J=ToZ_q5|JE(e$&};C-H0_r-O#UEejIA@iFChzcjQ< z3Vt>I()uSx&3P%EI!EvDnox`*HtH)MV2t%eo&vR)YG6@0F1vgMc4%^CKwsCXDcB zz+kHiljv4?)8a(iNPy}3i{sPtEoyZ6KC@rdKO%s!%>*pT6Hz*{x8`SB$GD$dZTAYi^PFWK!()y7!VxWH2(d|Qdo>=%;>BE_Iq$#g z!F1krUMU+O^+67m>kwFJ*yv`tl*2bhKoTk-^ChXv1CK68C;6W9)1zj@aR*@h9jvXf zDAbG*P@D^JW#sscj3^JkDg(13*=$;BhwS8gk*!&ZsW8jmrP8reSe)+nrTZCE*W)0sIb%?sUIK&;~jtEA}#GX%Q zk#7&r|4l^cmA~3rRl9IsIs}SUM+0)rnka$I{9(o)=5=Pi^_aw9?Qfj{x6l>wURxK^ zXZeLI_2I9-$w>1?yW_cf_IwrdkS^tV8xHb7(#%g54NrRCJO>^Ei%B&jiNb#@1X$S; z*v790Qs(A@XZlYn$!_;gF{?kB9dcZnd@RLX;iPx=4vjM<>ahL0HV$We%~z;7uUWEv zqL>_R`Fo&!Xyj?x9;z>uGZlw@$OX)AJ&$;K%%XXIk%G*tIOwj+!n&1Ffg~M_31lI- zPgtklDPp@XeOYn+)D^4w^z>#7!M8}0vk8N{{wCnlnDRTt`rCLmJp8e6cxH96N&hpy z)$B0IMp&U1eGP&Y|2Day{C*%=OhB+;v-DCEfAi$=xE`1*>z4IP5#JUSS3l_{rMh!g zfVEm(>)hn=Du4D^*`xepND?szca1T;M*%m%{sR{wL_3L{QH*$}Kqhf#HV6LA|S~@?@nf=jhJh?kxlxrG_ z%rQ_CV96#wN2qw7u`wQbWM7z{2NL^^-~2=1EV~>B#Oa#aon#t1pqHcrispKa(Rs61 zPj`8~;c*a8K|X|IWYpzXCw`mm;Q_Kt^QE;?)@u(#vNH|h-NTf)wD5xSh@M2k_)H+3 zZuu2;Z@e;_S~oue3`}Ua?ft30{stHkh)=XMb0jzhDuJFZASn;1zg&ozsHG{fkbh7v zoo`SybXK_EKX^radWnsEMr0nSGb0@(M~lb@L+D%b3e6@NRgX zpp4COgmjLH$Rn{oB10oHboLhn#fP^|JXgh&HU!v}cI28eOhfR)k{b2`K1V@~%=L!9 zrxZr#;%SD+q5@8;cboPMi*>rwyxS+Z@~PT!kl?8N(XmH|uGnw>aZ(?>{*&^Mym0UF z7iE*P;R}ELd1m8W|4X;WaK>nxP!c~V>-p!Gq0kT+VOY)8*Hr#b`wQwx5oeUZ%u6~O zciRsb2mzhpH>AzXPJTx^84Kqpa;f8gMt~wl+#tKxWK)TmlN(+wGd{O(I6Ln7GG6WS zZlPG0*W@icGm8-U#R6J577nN6q?aSL;4MAK3ep=s>~52y4Z_q}?kfxdq<$@l$M$ju zWPCUWk!=RDGB+ia_zeF3$D+s0M7*^Po97)Fo8PM$3hMATnssfOJT`LLaj2NBpuP56 zqOZYGV66GYuLhRmph%u=K};}M|DH0zD)M%VVg~=9@ud=H&D+*k6njlLN6nvCCSc3; zS>5C9mzb^~lFGF|w=mn@wwzVYE~Y-5&!re6rQBd>T_Y0N3)Y{wFagYiwBRI}!!TXG zXQq5Qr*hH)c?e5hnZzo$(dM@NAC!}B@wZm!YC2A1r`BXMW--fB~A+q)aXZ!mAFG1enUs7#P&)FDI$Mq^Wm75uR({1yq> z(;XhuM|XD^jr5DnnmFbt=Rwk(hI89R3zH44Bv6cvrc+l*=K-03Z++i zAMEl350`ylA*w;*yjfb~bl6{>EKMUn{ef-q9Kf$z^MixK#Y3^h&cvNQM0v=#MnAfj zUK%U8Caqo2645c>wZ9wZwWBRpvH%Y2bWH2L#a4jkp;jo9&IbF$i953jdHI0G)q;oh zKUddy8VvEk6LaCS7Z5|~Q0Y33KF{LjlX-?lIKFJ_bY}T}+15P%aePzee-U%9kVK+J zr+IBLoLqO|*Afgp%u#Mu2t{Gjr`-y~%U-=J3fVzCbEDKZeOUF8LCUr*{d$amY&(HY ztdLrLGwZ!)9syp%AzW#ikcgR_k=likl{(JP?ji}u#7di4TfJTGPc zaklBcLCAcChC)I6sxe?1?{KfEoF?Jx53gutQ{3HfUS(+X)%DYybPFO*Frp z8xHtjRuPK=G*bqbu6{Ro?OeCCs>TYQs$!&hwZ{e84Aaq3?FDVWHl;l_pF^If)&HpP zkYBB&Yt8?HV?oRv0#Ozh0A5lPQ9^kmUPo1ZMV+Tl?b*wXfBsdMJCeYFnZLd8SQjbz zecLd(s~&wGe5Lw$fh1$&oXdY2PS}Iqd}`n~si) zzt`uoJ6kEGgEt!FAv7RNCgiLV@I7{3`OF^>j`KW$AeoA#4Rh0V)U?&Cq@R1UHQjTS zOIL1BK{M(Xl?6W%rFzB^b8Q(6cqd2+kM$+hIXNQNb}0k;8*VxrLOEX<_D-qO^LvH% z1G}D)MLMEhyCs{2P}8xw+ra#}-ZKF3a}XCVK$$oufE#3E3VhEd$MUZ?0utfVm#do3 zReWSrWp!jR*wLZFtM1zk7mo7E4nlz9B={5R`+PFW*@qvbfnY`sSa-nZM>v8wX2_9I@B?+ z1EZ>v5Kec(C9!?0M36Mm0ryrZS0+RL1pe%v#n~)?s;2Zv9)iaQQWaTQ%Yl1&sKCEK z6^DGIKOA&feEtF@9#mpe3x^>mfz)frB}Eyf!R(PpL9MWPfy}3FeR+3HN6GPH!;%DE zGx#A~=ICwXY*$&k!DTU_J9=R$?b*WO|mkr=RkkCFo(!j^`P{Y8*G0)-XYn`Og7O~MSysU zGD5lRWYaZ)lF?Ya-%;^n93}~?7JZ*SZpKmj7f7gGMfh0Qd=BYH1eC%i@lJPU_U^cx zh25m(5wIydz(ao+3E;7DCBi}{z#NdqerTgb-PQZ1Zjr3-V|@QSV~Pn{1~GRYgWzBg zU^4^)#j%Yb*&j?!N7_VuND+OEs!Vxki_xpNgmdz=x#=iS*T-dDs={RWMGg1E9&Dbh~kKq1k zC_0O*qTK6YuU2-GRj?NqKx0@XQ`xxHjK$K^bm&5|s9b9|*0d+mjoM1ujL%8@;M?fH)MP%+xJv>UvDi_X9bf5 z#bKrNQhkiaTvVF3nDclnF2^q+D=2uaBJH$j{u;ku`9ujEVWRH?5Xh9~b!I z*s@oesmB`a@+aIOEXGJIuJx#n6WzA?W3MSZyB9enLZ5PmO-K_0k3)35@%KD?>*KSS z1!lNX^&-({)z-J}!PqQ2bM@-8?Zl+Fg^~LHUnN90@(6c&Un8a4lKvO1#T}&vtGp?fqOE& zPiq6V?Iv?C_Z8sw^ZzJXID&GYG zq6!t>ESK{S6&}M&;3h@<%2lMO=ph@Z%^glBp){bk5vSGVt=lZ5{fep5OO9FmSB4@8 z{4IDFm%QbPDe#5E;=X3}4xYi-C125!5dET=Mm!nYM=IqbQi7+kz9Hir9)T#=Z`^=L z<^|)kG@1=b5I8>AHjhE-?TnO@_4fbkj(+*kZ<%S+ojRcGY167*tw)cYbHpE+co-A8 zSOJ8)y=glxV&E-G)bFxpoRKJ9aOY}4f6Fho{k^?^Q`ieTZ{(jfXb5LruU-!t zSA-_P&GSfiP0$Fogk$p=iitp`B5lX3F}y_pe<(JORFK$)t=cm#E|K05*N7sdhd-g< zH{PNV5IhPFf^@mfq*!~;tct~q^tpnInnN-+D{O1TQjBzbu7<=CHy;#w6{eb+%e4>i z@#r8MZu!(XH@aVFIzb1E5tx>N9s=mT6u&I$7SJ@cL)#uvG3|aht2s%d7^X-WP$dKz z=-l~GrbuelP*{*38<9#B&ZXx!FC!a_h`s);G(_7U{v8khiNb#z*rYnv7!WIZ4%Z4xu75L##og$ zRwAwPjVwnd?~ynb$q=0~Hmf?ZfBE$B4xbwieL)j7)#@gyKvd;bEd}A71wVuSRA(UFgCg1af!2}|OD@n87L_eDpDJxhE*oJPqu|$+Z|-Z0?`MH zeTDZP@2gB6n2L!}@qHsr;72xeDe+!eg^$;8UCi8=EPu!x+(xC)=eVrfhwY??3PV~k zj&jv+5zn5b-49xQLWvBO(IHOq*RM{g&huo=F$8*)_ftO|$E1$*>kG;|l$DAAYxqfI z<9EB%6PX7mF>HKHCvA;|3H?uW2bk_m-xM`12XKl|8H%XP+d8F<0SP3(0^}LP%@O0~ zKkLsW(E9>S{RiwdeH?hBT{+O@f+w`S9q?lscrji!xH*A;6S(G80HqOgc^cD{ zjU-0;bFSY{c6hs_)1TFC;h&8EE@4OLPh{5W%D61PmnbjC6Gq}t8tj6{kR{AF+T=5b zrW2zwe3SB7z|UCs`MlCg))+y$Gui?AW{=uUiM@(VUUlPad3~PcP_D7lrcWho%1ZY< z_}>j`STKVO&DdbQ$6r0WCY>0FEqzb=*L>!ruMgr{)ypP;GF=x4gC{UK5-C1`p+`?h zsbWsS&>0Af|ED_CWO0xdfAzo?#ao=L0wPB{{_RpKXzkx)V*X*^9YVt^4~%IbGYBrm z1hzR3GOB1VeOoWOe1V!e>Lw zxs0vhyDWR!0KExRK-iDZ#gM5R z)*r9^!`A6zu_nn`<3U(c3QrDR_bc=1HSb5>lNCxL&1>oQN4I)70b;D4M<~_qlL4w3 z02k=1`DmBD^8Q>;qa0>$TxMKAkz>gIWbfVj*jB7!jk?M44=eC#TWBXCzN-(O)keV} z)$coN9-5{k6s9=}2yp^^meZ8_E7Ywgb$4c6`Lv!s#}K#CuUSK`LZDxZ8%ynP!w@>8 zm-`@_XGj$uG@~K)BEpOK6-U0>oP3Nk!}#*=hir^QWhUw@(VxziH#0=mHt)7JHd+G1 zI>YEYu3xPap#w4=;P757WyoSSZhETNZv5T6l#k}e+qZ~(*(u?=nDjO!y6U(2JU;{N zLrP3a51;+r+WB=jO(iLLwqUzCB1bWqNm&$<2uHd0|8$%wyB4o)Tl}vpZ>(ti{+Bwy zcq4ctR_r~wW~|N7Oijh^>3PD%)~0$(%F17T6=^+wYv;p)&CXYb`$gR>&w&d7!Xfgh z4F_ZM0L?=gr!z-ZSWYL6YPl%Zjx5^)c=`6kL+R`nzYWR9%RP67x4fNH13CNu*7n5P zGoJY4o|m4StDP{dQoX+DJ&=BqA?QRe&4B(6{>_WcMVCBRt-~J_5L>Gc&sAQi(F_z) zv&oX^$k=>5{zK^5?XF(T8uea$oK(mknqyojYBO9-)*}j;>=I(%x=iNF@mx`6(uvBw zk#i7IZ_(#36S!eaxr%~@ z>PZSSTb{~Nw?YvpwNaw7mqGndT)5%YAPqL)B);eBY^!84dOOpQayZw{KX3(C?Rc(t z^4t1L`^&!^GuMNTe{dvl;V+FG_d8k9}O2#Y|cdNG`j8fz_8&qRQw- zaw+M89dy5S(&5Wp^}4%T1C3pEmak!lc&c*r)^FS!s1$yI#02MTj?C`oqKw(e ze3rw{f7Y_lefv?L3Cw|?mdD!#*Q<&f*hb%ZImDZB6mtU%r&?21IOeXOW%9kLNf;p( zmN`i5vu7YGix89A8XA(ulzc+SdVx1q=}^4lCT?vNTp{v-=c5xaj2ph8nhHaq^;tj^`qz*^9Oz2?&=gXzT=@rc_S z^kby=Ui&0AS$``re5;(kY(nck8F0tDrP}o8d27YbOGSCPYNjc|*KybS25aHgH(H;W z;3oSl!{z#>nT7>Fn8i%dR=>73E8G`tE8FPd4hD3g!d}~4tytmRxH$vYdwGvej5XME zEMF|_Uq%p6@(RelD;fzR48(dPeR5Ic@*l}~2%VPN2Q3&8Uc|YiN1t#|2z_T(mGp

FPGuw%n52Oa|JU9c20BE71Pzc-0Z|N>?#oNW&i%i_?V!n*Z_M~Gbegdr;vg0n?Oothi-@Q({dq?$($oHi@SMre1u<@kjBM^%|9>lY?;HodBZErg65h)(p>lTH)Cw63TE`JUampVLWe`8gZ}C{jeR)4S z0bq6Q@#eqJ{kcoVyqT$41_t#y0Kt3?bfxGw{n^+W;iG(9;?@SRI)#=pVY)DcL1MbD zeh+{nGEL#dj|u6BU#xWhbNLoc6_CpO6e` z?nP}kqaQ_-+aBB{Qjrods;y^Fa&;5=a|7*~+t>=nLo~hz%e3J?9O9r+XH*?tz73G7 zs4YfB4cX|Z=^E5v*5x$lr2F~ueL#fF^qb@xJq9*jD*ZN*MtEjPX{5BEfj2x(1WbiA zw_sf(S$s%*#aI?^^1>e`%&Nc|-F?;=qTuX=?xXj(dy4YF+qgyAE4R2jG@v<0w{jnR z;t8*L0n8aV15*jZP_D|Rp=BT{0iYzXQy&h;4rh-}O$Q=wDPfRi<#Nm2kh*LO;VNaQ zG_HO5<}(fqN0#FE0Kh)0d*IgP8wf~T8_V6MYxKF?J!O2lha=OIR5Cl|RLH;_aPc>0 zu3hAE$n?s<*03<^1Wd-3Fn>>LaPjr+Do!o46k>=21`K4{_e@B*3t zl&KxNO;Uo}`(wR@<6mY2!9}GO+1L;%`X`kJ;U%~UH}2jc>ZpsUp*~EF-eTTG{i5Jo z_rRN8u_a(UL%EhyE+B?3rrI)$`!Bu{5o2>OE~GE%;!X?Tna>M%R?rhneF;1=-z3Qy z;n8@Sm*x}}AbLAIHW+7AbwBHP9tVqfFKb9j*1K@=BX4#LGdlP5j}HC(SAJTKC(Mf( zr;&DKD7nB}OW)C}ap=py+`D%#tCHJnyI|C6e0@h8$W}|&T(gF0(U(po(;$D0%lc;B z9Ri&7MsA8YJ#{d0rrQf3ytl_k;DebGZmuKn9lD9iLPd^BMxptz^>e`Tikt%&*@d6m zKLlEzjpx7+i9o~p2k(~0IKFh?xcF%ELwK#I(tfXJ|I)Jk*-adk=ED0VJH@ev} zvd2cMv4sUEGGma z>WNyVAB*_}j#l;_`o%i`D*xzcQe+L$=dUBS>|}=@w8`Y?y=zrXRT1Mp0^$tuA~95| zpb*|t@86Y~G@`1J;<0r3&zgs${6Pn{P(Of(BEzRtGN?k{00S2!2nm3i8k_1YpIL85 z^cFDPD{_FL%1R@&#N=_HQdri%`xxaodiQU#=`L6W_q0d)tUY6btA6ZANm*U>#w2zD zvJyhgql^ey(3)|(qjTjiD^%FR3v~z7>(X0o$@2YjyRGCi1dQl%WC{=U;?{8UI_l%D zWR|Ccq*d+Y3&QN?&+07ujS#mnJc!61yM7K67fq z=r??dSR(=-Uv^yINLU1+hC!R_?lDcAamNh}7L%1rye1gZTdG(5T`i^E^>e*(&NHRC zJVjLAqU~XCY=)-pM$dn>TzL57^w13u_a+gKao_eElYP-=cq4kZDQ1~j9E9WJP=huB ze_ZNgFp4R)KC&dYs@L3w2Quw{${5j+{+B%j7jZ(IgJt-|M)9!!vxWbTB0XwiH#uZD z9!3fJghmQm%TqZ<)6RWUZq^g{7by6WUAqP(ux1a z5rY2AtwORS=w;}Yvh$*@Z*9NX6voy>5H@D;3OcxDMR{70cQ^VFNj?md_S>sUhtgt|EMWjVqIGN?GezaTn zLl-_=MqWYR!T{mXXcy9x=+-V*srBU)x`8Za@W&**wMha{17Vcr&tJej0_+^(*FffX z^oe0<{@|(H%QX{nC`BTJMj$*wcbfG9F;R?-B1_BpX1sk=9F0hnigE!~h^G$l9SOe( zW38>s3F#n+D}`*>a=&t6Sy7U6&z(+`3I>RO1Jaa}2ihwfZS7h+@@uHAw^D}9dkh@w z-6Iv@j%*hFn`~9PTg7Q#Seuy7b8qk|PT8f75v(0@_gR*deG46@-WAqKf_cch5N-}q zG`S1y-Zd_EP~yO3{E`wc{IKHP!d1Y=Cnr)zn)5awhct2L{0{p^@6JLhu^gWWd$4he zD{7*x$fr*7JRXt?E|fitF(9B6yIgr_sxm#jY?fbT5V!yF8w`O!Z|<7s8fcERe~Es5 zb~5a6}YI7zk7<_w2N?j+*u&WQUINo z?zw#PF7zkuY`-nJV;v>l49D^zmG0$yT#4U*y_pk)H}L-9Gx<+us&|^*z^O9-Ki>FP zUkqqvO%4Ym=5wdr8y#9k?qj-59Iwyu=ylC|rOOppR7OBy4aN|vK`nyw=Ce({g6sh) zXk}ks`n-!_X%+c=6U>Nm0tjI3a=&8n%ae@}TM{H)d+Yo75pOP`u8j*89uyt=s6lQGF)R=F~qCp<$!ND|nf8%WTJ$Bqe*a^^eXh zUnSOeN!GLTxE6)igXM`)iZzmIb4v>im$1>07V^OEyb6T>JI;Q#lw(&amiEv6BV1$;TW#F7HA zwCi-g@Yq9EoS!#qYod-H6aXzi?L#C}FA#U!cZ0?}mN~BA=W=xa9IUo+Q2LfQNgI3F zT;2;CP_o+aQ*519lwgNr7hqQ}edfoVBWDK|_{Ryy{oN3o9UM^&tJT?b{!lc2fI_-+ zlGQ=JJTtZ5V@TOV;vGLkO)(T)tN`}Wd#lCU^Q`50&ZrWENu-a5J z=fYt6wsi(z>t`5po@SV7vTSm^2T0~&0Pwrer;2#}h{YL>3o{}>Fh?udL%81RZ#~`e zxT{!mQE9W7Y^A{Nsp~>A9XzqINvir*D3+4|X__Gw_ZE2M!IE3`N%&DVW#?amaILts zr=zW&C>eC{hEF{Y!HUdh!Rz&@ zD~j?3d}XOWBuSWbU_E*x-?g+8_Z@`4&*ABc{Y~)?GR4=^>>Qz_ z%EgsWeZnnK$139+6F~8|67ji?g4g@_Z<$8IGU(Y4|j&=2=rEN()srfmt z$NI(PE~wmRmM8tvpf0-f3UU$ArTDaVP`xS8k>PB@`Aq2=oqoN`JJ^Zaw8BnSavZb}8dpV#(CN`xm+XX7KM#Z|7F-IUrg^;{MyfL(d{?LXT#3TH061DZYYZP-(gZcqr#_ddX{c6l%wMN87@wl`y~*E;#@=~Y@g)xU z0_AlCZ{Y3+45zV!S#dG`Dc`u=Qe2IUX9Cs!>AbEOFs8SnnmZuN3z-Gyv-B-Uud<+wO#}Ldjb%LoYJPw?Meq+F zKi%w~W~NnjGGv_H0P*JmKleH{GQO71A%Q9ZF#Yg-aFdWU^dk92X`@A#NDOl;gi4>O zK1=-g@cgX`UsTIa9~+B4c%r&$OIA1|sLO99uBzNfmY)vy^T(|p>u^hQa>wI+t8+Y# zUtI@_z%$Z(a<;ZiCIl@VFjJSMMx{unTeWHnUWV}~-4Up`5CA<&cEb~7V4DR_Y+6xP zwxLHUV=Hc8bwE5d!0C%Ui8LQ$5p{}6QG4iGqbg=t=wYO>q<7|gCdOlHr`u_!gTS4O z<~Dh-s1TY{lTE-JIcidwd%EA$@Sn+>%3Gam58WG_y7AJ$+nV!FQOrVGjt7;CC-_I0 zC>Ohz^ndg+&KHjwz?&5Bz2~WU0qLCYVR*f8{;vsrln3n!2uF`ok1&HW$?ge_6?Lun z&adWNAO>?kcb)ymlKFTT6%guK}U$GgX@Fv%b$VTj!V!wHv`-6W2Si zXSPbWW5x#Kb5L9(1v#Vr7LKMX2#yv&-LDt>D>~+wG3x07dK|6Z^9Q1THOv3VoRqJ3 zsH6ZmEsj>Xfc}(r6$Nwv6nRzN&x%?Kuw)f*9gP~UI_Rec<3(xp1<(>^6e1X_KMo!4 z-=%g+Y8)?-j@Se|4I6Ww3roVrhLXWVbpdm|3ter~$_9MQfnT=t`bysH z&PwgKz2k;eV1j&Xv1Z|S&O6Dq@R+Q?l@77NJ(~%Fo{y1MyeEs5k!?CBf`WmC<+^WW zHWXR&82PFL=-BYrZo~lig;a14m4nuN1-VytC0;9pzX|a94v?hT?2jd%5u~Mnl;Us) zbr2Z|N5zQXqpogOeLz*v+XKdbq1H_oJ;x%!NSF~}k+cR%YDLRV$%byN6{e))zB5}zc{ zr!KvRpuCQ`bI;s_dN&?5qcyYfwU{u=17BGV_b4Y9PyU1*5dwR8-xZWy z;)87?0Hw_{93TrNX#%fXV&L*y3uQ~MG_vXCK~z}W4+UdG_hYw=TUpguwE!{8fOSBoK?FrNPK?ES@AKW$<%};u zxM_MLuL93G=Vli}jW>#YM&vEx)p4Nz9T(Z0U25@#(<^t%!{f7`{UTA~@9{*}W1J zdPnoXD58y-(%5W(v7MmwQ~i0!yz4~ewsA3@7rxE?dsPpZV|lAe*x7!v5h0L=3`yWO zvS->zM8J1uAIa|dx_wO?eiyp(H}oZD;Dxm~&Mi;$%oaKG+r8_%iOk@+B8CkIC2&@@ zK8Ve>H8}p`A!3@wRxJ<=0p|5~71LqoxVBc8RupS_a6g0pX~r&t{PalK0MVEW!S

1b)`KaV-fS?x;z!|-}{B|d|t=7Ck01r!{DK_#L_&xc9yNMky`V@GV zMoc)qKiN4a<-_8idWCgJfVMwsK6TplpUcb*-91V?Z+pG%!*cb{ysh?M!u}G<>7cy5 z%jl(976A~RliIo$HFOF*q-c>Gv}LK^tA|Wfq9E*Stu^JW2&4fDDI6&BM3+Wnw^-E+-|By>Gf-yVS9M@{@eI1| zL0u-(kVs?e{fC-w(21;D?m!v*%yDf?q)q&iy+Qtx?7ZWbo0a#$P38BSkaJ2DKf^X& zwP?U@BPv~{dUYmqR4K^{)Y;o0Hw27}=CW0;uTS|?H%TCmE}2UKUfTe9N!A>$PqxM! zgu4oBD7;Xz;qjZJQbojAQL4el*KwRJ^-8p6CQYdp_;L|}Ripg=n*kH)GV8^pdB6n;lwf9lUk+G#Xc3f{M$V_7tyUOF{S1%*nc@M> z2$ywnIjT^ym!#7PO1a1Oyy9wLQzChx<)W{=Quet)ENkZaNkYYZVyP{d?0ApTktg|` zPdn~=!?MI>`DJqt##x5IqnGNx>!%-ybTQdAh3bRT?@2c2Md^q6TPdR4@<@&-_z2m&mpYeX#@K!d&ONk*UPA8FKFY#4v@ zzM$Qx`}Wu=0rvhaOT z<7SKEh`e1ZR!EiAi0Wv#XiH`2BP!oJnpnVQ)HU9cF%tcw3$8VN#UNbCeaq@zer)to zMg?9=m*p_W^!lIfdx)**7GVa^^Cg^Y7(l(Bx`@Y+9aY1`D-ccG5TYVU)X`_6*0X-} zMQ1l_K#E`TnZe%R!v5@Bz<4s71yS^vAP}qWnSAhFGWv!VUf0naS<{!h!T z;Tk(-(C~>87#>%=m2yv}bBtGLeT+66}-!?Cd~b8yR5%?r=PhZ43BeP&uJoiIp=%z8oXxHodTsI~{kIS1$?69n8U^m_kGtnx+e#V}pQAbvtvV6{=yZv98nF0rj zANnQt^Y0DVZ4PB$`?^h8XTALFJ#hC7ZS8e=&(O9<{!i8j%&N1+zUf$mCp#d&F>p*3 zK?@4|MpS=+@t|7y`T2d6e74N*+g%UI8w|WetVm7U8!vEmr#GAPjJL$*gNv*_Lko*i zHoM)6)DFIADV9vOhWMlFrkdE-0jCAPW!ymiE}G=2<@=hTvjD*TRY~Ia-Ck(@-LYee zbv)Z+;==VmoAQkwiO{D| z?^|}++d_WdIVqtD$%^316J3_Ty*1>H+SOAAAsR^lXNlE<-uJPrhf?w z8`MX~6RF67n@dy9DEreKi4P&I59@nmj^nypIV&SQPlkI<9OzLc=)C!=!`mdQaS#v_ zE|QMr-qK679($ilUT2|6s`N)hj{IF%b{PIUW*WYn&U2a_WadYy3KqFt-<-aU1l%>` zZypxI2uZS)qvFN4$cp|#djQ2=kP;`fB*n82C3#gxfC<8EQeQC|lbc)x2lrl z%77LtO~nN>HonFR11Xp=>3FUcp**>&A!@#FXW>BUBG<?l*26uhBw(_>8L5*ZF zC}?}i#NGN&n{pgJ+?VaaPQ)wsizJ~qW-F$kyESb`Oy9yr0BorIobs#1k-neDY?o8c z-LATC-m%W;DD64sqM?Qqdvojh?rm=X$K5JjwUJ{jH`|3u2z3v*;EO0cGR#w^ykfJoH4T-ahsSBTw+H%5ULTunyVA_g z@k6f+SfKUu^XdO9U60xLc267Cv(6n&u6}dp++aTS^RO9wkv)#XTvmj8+L4ux$8-JMrNvU-WQnDabi(x?SGQ>ohD!&o;?g4r_^5 z;~b`ZLf&l#i172-rvz47MJag-Ura)A=BnNW{}}u+g<)F6nfy}M#t*BiL@KmPX~=|@ z(f+VOK9E7sPBu+n+uj>UIAXGoD>+3QOA$k*;50Yj$^#sY3fp)uNBl2&y-8A!%mt)= zw^DTxUvkSetfdfAULW^Pv0;T=y+H@h_^Ar8c@M>Mt{Q%nE;|mKmbhGbrts^i@FYpy zJ?N-eq1koSNfeMGm8NzAqf6?c1f>j-+QhfrL1MFMV819W0tcjaH`>q(f6(Q>+y$E0 zxaII52PkK6*Ao32qoHlzewiSUIQH?)+s`v^W_NvXy$CaQeMPyhL32bz)c^D|4Bp=v z1CbOeoqnVmHGKh5?C|s+o%(b;oL}R71@9I5>UtCx+ffVn=siGC4b&2W%`Gw0edLc6 z(P{izujl+F1R`1@zM8;3L4q0^UgYt^3WxI8r)=^9b=RahUXCO!t6U!oUB`K}v&0kx zOh;KG&*#9DpHJ$WFyQwQ#eS5tQ4grrhL_|;LRQv7Rimmd`E$*D&9Br$eF3;rtZEJ* znv7~+z0G`_NhDye7D(})!SwDZ5atptgWxUzaK0=WaK>wKB7Q)hejLg8a>-Eh&r%hS zX#OxI!M=?(S%7jBVUoIxOXM&4U)->&;oV5n)f}wp(FK;J<0>nmfN#Jti~rn?Q;tA( ze6G4pGb+AdMdjLvSo89${84Ktv&d;JDo5;CFciNaV$_3CWJTfEyUz!6pA|5e?64;v zs}FzlW)}ONUC#3KKq4H6os++w731>VVtB)ClL<8i07g25g0f?{wv7$x`rH{8$D)Py z2mW=ynE6-{c6f@La?Fd5FM^yRc-MwW+67@<7tl4#7Ndp~#c?^`(E=lVl0k!gO+*#Dn zP>1*8)Sc_pKkM7R+(V~qpQRIpX9u%e!wt;Jeba&0p^zOZ06BU*0KV-+Gm>F@CI(g) z;u<)2K9UeoCiYok5yUY0?k3%IPjU$=G#WKAuhvp^tZfD<+g8aQvG~AyVY2Bb{TQ!IFdjAU>uPbKeZB zXH9oIDb&((rl2m@B;{#izDC8J{f^7hAyW$XkDA9M=h!{%Huyzzt>|2v;6@uc){7zi zz^3Avd{;P)V|OTP=AG8nMe(~#HKo`p4}P4Ya`D7w3&3Ez;qy9-HQTgtnOcLCm|cb8 z?YWlM0UL8HpO#6xT>}kWYs@~Z|G;M+qU8HAC8_mox0G{M*)&e`)1qZc&Pgghe&)OaxK=3(nG2xaO&`3;Ju%^g1&kA&@Qp`YI8HG)?Y7FC zI1<+`k#yL+ilFOUta8Qef!~*CI(<_aPRT#;?dX<9$dB2fJz~qNS647`zC1I^J(1pl zkDul1e^8BrkF@pLw*F6F*BK7S_qJE>u@*se(Mu4~5_RoT)5=ggV2=RD!);3$l@^de__1gJ|{QZa6@^xyG8uPeLss4G3yD&l-iJM*yRENOQ{ zg+3IE@+ih^h+l#v6B)*(Rbt^+6KRiTIc3|TnT3cW=cS9)M(?<_N->QCJWRYauJpP` z!sC~PKAq}uNqssP17$RiLtt%jdTt`iM1jjvh-cXRp-w#wc?fv4H0e1(S0b2OXLPI; zh?ROq!TV-+^yK0yHeNPa5s-V^{OznKQHqdzT_uc;wW9xXKViCr`p^UWq?{q6tClu+ zxY=v%me=rl<1}%_;b`BCnsoo9unH^}#yp(!g-uAT2Xo-kseGMwmpf2Otk~<0?>Wzw&bO3HOR7{sVNr$p0Ogm&e=QZN^`;;fK%+|}OuPWfKOKLl`+h|U&%fC# zaVsChB?wfXLsA5!7v+^gC3=T*nT;BT&H|C?S1-B7gasTkaO z&74Ldi|pffPUDXIsPX-8vcBKpO%dEETO3-pihIO4ac93V79B|?xiU3Y=6N{qbHB8C zUu9Tw@@RusA_`n_UM6;~?fQyz|JKwv?`Ak&8UV6ul9t?%ko>d^@i#N^k+@ z6xeGb)W3IX1yN{D!n&T`m6^5T$kOcg0=tKb%%rgC=s0JdT1l^amT63J^gNj@M&LsB z)t_9?g;7hCQ!sVW{+*iT<0UxOjZq1l2RuxPKofroT&4kJShYuX^ZV@adA8G|H^~Y? zT4{jWMD#};@au(@&!A9TB?(6}B32)RBe&O=)44favV7%Tp8NvSJs%HRb@y{R!)A4| zU}$=#*}vFS_fBF^%KuFt5_uRd0NiE%I7gXn!3+*Rw&HMM-^;Go_7&4SsdrlzS>-9J|M`$eN4%kjD$;vPLJp7 z`k>YccsuVQ*xNjDmWRdX+C}BO80%3L@m^5ri%$T;vJF}YY-Ya)Rr2U{j1sgYj~Nvs zAPR%Gv5V*8rSMqiZ{rT^; zLji2nn^8uvVq5r`d;NZvdvZ|+wQ!H)7CqEsPR8%bJItYJH|R@YZhYH)EKPC>J*_DKX9$W}^>{_-Dnwp|LsK4AZ<}Oag`3%-JCs~m0tJ5cb*sVXmcBHKdH<8(>|CarFkqpRY z2DGW3_NRW?Ax?W04j44agFw-AQKzzcLyGoC#rCj{Vn;V^g;{bgfF6>G1|zpvt*3e>RieAu$-8BLR9M{Ap7 zf>>wQUJ^N%SyS&l)aILYumn&2PDNi{uwJ)vQ&XxrR6WZuSyIAf)HWCC{;D374OoVR zxo3zs%V$OLB53PCNG#PbD*#;X`_|j$cL34f%sQxC=}B1n=lpNGhC30*nPh}V;mR)Z z*94{YE3W_z1_&V(KOk=$0g8QBrMvi;gog;ix_Q}BkRXg@O_BPfiABj&5Y zG59)v`THt_|AyYoJ1;XzC?2IThpPd%of1 z16R%~|MISi9zYcWSXU)N(vx4Q=)@6=1_S_~Gvz~#IWFD7nXv5&v1BO>4UF-vOeTqI zF;$ncldycMZQg}}p?tABl)}uG^7|a?P}hIaHu8!q0)|<~Ka!fucx)rV0%hIvCk)7O z>Uj2G0_xH|c`n_(?0%fL7NKgFCZPn)$_ZFH-&F7c65dS(4IB8tflFm1s&(N}Irr|a zzDFI6Im1^9be$cf3)5?%jj#l5+SvZ-enFL$*?QL9kJsz84@lthelhkS#ZTGIHee3L zCIvTLEmQ5u$a7^%7aI*a3f!cZnp-iv0QnOhG{`G?^iF)++|6^XgPc>IJ*lll&jsfg zj3LiW35cNF5H~(3!MG6;Q63+E`Y~gpaNYi`8UtyXm8iS`=>T zoWw`r_!3Wlhn<(UbvW+KP#m1tI1z0`uL!oINM#h^ALvMNV*AiCG|BJ?G z+O4yeyqiv&iu?R(Fz;QjAF!^U1qI>H+Ozsp^^tOp`efZwM~S2}Ez2i5&dhB@2a1e*K5-$?%-=pWU2pM6BZKBga)SHDWaZzQAi321ca?{lmhBF zYONfbk7L}Lo*y*4>k&2~AmPH@Y8!hOPbx1#kS=d(lHYj{tG!>=fWSg$RSpmbGdil5 zviH?Kn25sZUwaG6vrD7!!0gY6;w*jjw!RzFi&_oZIs8Plkad`+feotPmlwaaj-Gzp z{LS2}}X8O(7y59^L?g;sY}w&H}mot`2{#3m8z#k^N;__F7MP@oex<#hOo`6RFG(vGz%82CehZ2|Fe|En)#v zL~0|&PBqri?WD?g4_z$#s2q@nV+)`~bbUV}G-Pkgq?k079&h#^?*k1zrfvU;=codQ zPN*wL_$HnzyNed=-hnOm-+JP+U=uxOwZ%K8moYg&(&1@PNv19f7p&n4M=l8zzl&!l z-7=bL_j|4zZb3Do3rSZaQ*JwYxQny-5wE?|=nQXM1WH>ho1}o%j=ABmaNi8op;y-p z%$5x=40ay|mC*v+`cVcIUpB|;9?N6f`orB1D3VD8$_65-t}Nc2k~U`iPSuFQJF#fR zXH}!WTNiXnU}G^ZUytXN0PrL&`n~|8DiEE;Vv@y{Yx>W=E9|4Y5jml9tnc&bYVH+a zA?{UY5z(pzIovyseFP@KiA&}?(=aiF|lGi$}+9e_=}zBHWY-=w}jbhYtER|!@0 zrwoH!1%VCs-bX;D{<OVubtIJNSwxk-w! zMXs_%l+O1}RY;42Ok%C@@`}M^95i+{0Mq%T(UEjFE>vld4f*1!G$s5>ia|$&(L5rc zZGblC=UvOSZm;RSertTfNG6t9jV#V4Q>Eo-8AW=#tLi(fIQ30O4mOzNBZ=iyqtp z$Gg-5030XuCfzrc>csf|46V6-Q3_^FyeN+yfR?>2; zmfd)23K4U0Pm1NzZR;cstMT(|1xsCOPHJtV*L8eu%F(bN4b0OB$QzU^;hVTrCRIYb zOPK}NqJG2~X@iD1r|I%Nr8^hygi1gNyKSTiKRR}on6)%=iSmH9H!lzbtwTslf9fJS zY(b$UE~MTa{20Dj-AlHUP?)Svf$>`)qok84_x=ecDHC_>t@-aq`OnZ%c?s1}o1zIM zwC|n#nCra7*!7!vBtwmz0jrS2c$X;1ihRMzq%&@=3t$%B(PGv-2Lrh#MpgVrgH0zT zp>Pgo>}%t5qsqU4+rXb8(pRzQg8WW~9jLUP(e!B`p7kh`EPGYfbMS@l9reqW!+6rt z5KF%)5UDf*rbp`4VhsNy#!_w5k+TxIFe|>{%{_=qqmEBY@cT0B!edmDw_R_Z<@p(%_k{Y%C%_-f zisQcAuD8SXv>+*B29~McyX4GR-)Yt5ZW-=#-Jwm{0f+jI*|#iq+gIJ8u{rU*Br@!J zzc8UBe4tJ{5{%{|#+KhVoGy88m>KmJ0XK`2RYVI_iix$Qn?M0&z(=Yd6JH8K{nJlh zpME^?xLWZqqPWNi23}-0?vtnXk;~FQ!FP5mEFJd|dh(&AJfX^r)~(SNCBnq~;dtbM zABH6!Lt7*=GsM#V0NzZsjI5$pCPrWk`;K53 zdS|#Dwp~fY^9W(ch8)rwU#WDsdhvWMY2S#xNSvKW<6Ye>nOarGr2@T=%Xm^8><@_c zg;5;M&oF;U%uh;-^$28;N0>G%=CUc(o_@ZV`w@k;-&W+}F6U^ymr2U0MbAivbLpQ5 zt?q`fw$??u5e)9R#SjD(Yc7%x?fmH6^Qqt7aIq|q^n**ka%n7u@eiE4uTnbM0yNGH z1-O$fl4$B#il%&E0d1cmD4ad&ttj3#xu=JrVpApr&H!r=>J}w+Cyhz8y#JP0JQe-m zaKhQJiSh3gsFg-m`i?WFBd)w>dhLF{F?zd|)2YU{&3tU|H7wyuYc7Z`f%Ca!f>9xT z9qrDI8~s6S?h)<@K=7g1+LV48xbu!TJBVBpf@V8U9MP7eQ8^+;i@!-!-1pXamDwZY zAWi(xShv>K8I`|vbKUvNFuJ-9ClAc|d+|AL7jx%NU3@YBvhV~g?-DDc_yPviy~~5f zs#=REcp*x`L#s&Yp%}m;Qa(v|L3s!d3P{d@KhdkXHCJbs|s@ z$>YRi22{}VtZ&|DA7Gv@7bX~`!T;sLX0qgf3VSjDli+J>CwW7$Pd}b&{f~W?&2E8xHTmCvF8Q`6JZD!U)8; z3&_51WwjpmU#7`jH&0+7c_r=-wvVZovN2U9P76AbK)C+&5O(`U-QxlJ$_jXl-;w)< zv5&HH!5R8FNI$^#PU>QVf@E=2o1?k498rDYPlvbAt(}6xAg`E=P7zFDt4a>Pu0H|A zb{Hbe9Akk{{J?tw?OBl*>P2LShT_ujX(wSd8|t0c1D=(3ujP=?gz?v^dIsQEF9u;M7dJbohT5iUbRb2j!yEwSvp;&NoPF3^qVQ_Ov3cJ*Yy5AF)xy>0cJi&zN< zuTix*z=fDP7JJx$$d3G^2S5-yfb=dTda`%uq4xyusSylokWR6vZC&_tbCf81F68gE zrX01=P3>T>q){5xSt4(_ zWt%}-ywpK=#@LPDs)?NG6Q-`aM8H#u_dj&-$Ts?X(F3(0w1gvuj3#9Qfj+hEk87yW zOpxJRbdi)5{vrSq>LHDFd5ic`*kL8%&zkv@4j0{|3t$n`N7Hs-neauY?K>;KchvE*HA5 zQ2{W4CJhVpOxq+dX|>nP*dX!9mr%^eD*Pk{P4P43yy%lc-H6O|bT;13-H)#xW!%pb z6Z`DUv`AjqxZj>RN#4k@^10umaE!@4SL=O6PUV|DnaBBOTsqAGb!sHdSe)xKNwEvT z=6de+3-x-Neph)*4Z6#W!<3&wj<35)e{HthceSt7Jc9DYW6tt=J)?_r8Vi{-d7V{_ zi2Bsx-y4u1&u2G4SMiOQROTM-5br9^z3@)q%u17vvYZ0K3BqvmoN?0|yx0B@SVZ^D z>}}znIkmi?J+~4M^gi}r>~EL^3#Y$SbTU6BNGumI)niyD5zhO%{bgZ!-g%5vk*#37 z?q^u4N;VVsNX#y9>ZKF*dL+WutfGXhrZ`XAyWJ2#6`E=R~FnUXQL}2_p<(`AC7U zLNx;NPbZgaWuuiS{aw4OJnf^eMW;($c|z%|aeDf$r6>t`cNdr#d(4C0=!BAg7?|nV zN`oz5voo5VpSh{7KIZgrrpbh?pjF7?S%w^oaR&LpsP<;rT{3N)P@2s(rkPRzQb<$S z5mTjzI4n1;we&z+%}cxeiDm)AJ#(9OQ<30>_G)KUaaVMSCv#(IYvxin8>=Ih^ov8) zQW(B0vdo6!eMZ36o{&f|+HrfrEZIf>Py0_Yw zqsbnt*!X0?0v2ZCQ*=+az-SROoUN-H$#MH}@Y!XtGWOfKy?rn-pl&o*F45S6i(mOG zNt`~Mlixbw6?WVE6g+09_ie&Ga~84tHbwr-{4}c*V1W;>FnlWl7x4huWPv&ghiqLg zN6g5|Um@zM@jF{msL`Hnuy4u(Ix*oOypHs!8?UA13%X*FD3gRe-rvY(Jzj50y)Mi^k<*^VDyNuZe5o z%v=`3slbhZZXA<&6$kIKfK{h5_h#N5Hrf-nZfGa{PgN9Z%~#osn;>4awxe{oYp|&6 zm|rOC&w>sxD4iSq(GCY7Ngs-zK)b|;Qvz?|FhkrD&}IF^>uPzpHRer-Cp)nFe+=8> zChe8!dTIpPR+cqQ6_Y#eO$`c(8rwNG_sjA3yh_i8+EDL#j|;XrmP+?-pPR0bcN%16 z=_+)K|EwcN!4p7DRJh495-Q@YG@N}@xx_Bc#eDp#VtQDP2PeRy4os3i2bJI>*63;s-00~o-NPOIB{9ph+a#(>Y|kCktiq5dWu1SMv@=(sY1=cV@Syy zmQ8VQT(g3*MTT>{vL5W(dq4P$(b{abqPEc@)DXrw&68@K0c7@=qZ#U-duut{7Tz@{ z-5S|3O|;_1|5`{0o_s+jx`@X{sEoaLH&W5NIUK>k%IbKc9?#Jh<0Qez__k{ndq^TH z%UHt_usD;rf{`cscwf!kweU^bJA)f)3k?#PKAq?058Qg@KW6KBse4*I?#+@Vdsa}l z%iw5W8n6L%ilsbS8Tz=|AuLSr)qxJ+D7F53s)p>3Xy_Oi+*K+I+yY2I6S6VGJvx@|uu|wFJz^udeAu#_vBo@Ik@dF97wtj`){x*l0~9AZss?v_Z#cdNQtg zCMEd8%2(bQW{NQM)Y7h?c>KDX)2(IW?k2NdHv%>@Tkn<0vFZE)qD;=&o$8Ou3&$SA z<_`Z`JB)$eb5;&4XvcU~d-+LP|TNk-!^n*8d8ImscoB8y0+ICER=mBW=W-cPyWLXG6><=wEeAj}1 zTA+p6PHFn5kc-uF+61DMW|0r@Oo zzClx9;UD#IlT!hZev9)rKmj>B47ZR8_l+onOQ1d{(RvH>>w<#I*Q;b~L4F|?1&zAy z9{hHshYtxqeIg`Vfz^w`JJNqfjon)Qlc?N8Pd{?7_!07ANlDMJKR4Bh{$vMLfe%}dj*Bv>44=m(UcS!K7 zjl1hq1mw9`0?iH`utnwC0$~gocmHj!EmTgebZ%_v)e;%=wi3OZ|Ca*Ny-6g4YRTJ> zFzGrz)sm|RO&7&4fA+RhxoFQmXIAReD8C;_!6(;V z6bHCS&W#dxmd0SH1_m)8BtYFo$*S}6-Ksn#Cf;CL)o*gnZ%yU=uE+8vG8a#0`L6-- zj2UdM7aGjKsPhHnM{Wy_hS87FibA_a(@=z3U-;hA0+xMoJPgQ6@9S}4|6W~Gh>0{7 z%o?p5#WdMrsgv?ER#WOpNw5A`Y8o0>~E~mv>^={|%vqN#)+f8H^=GGHT5kA0HFldNib*+*Mo_R+QTL5tDQFZ?;r3eOw zOz;n|*Gctc&|)s*SrpxC=tZL`o&l9Gz?gmbWc#>-hLdt6fk^BhMQzB5s>!x)EM=MN z2g7*F`lH~QtkT=#bYf?82FkywPC>!qu3vr1^xib zpyOaM&*( zP9FvaKK7`e!j;sX`|Bw}i!+AzKBHr^c5Gj1%3QW2mr#o!0ih2^DJ_1-A3Mo6iG}17 zufQjkhf0QY4ioNcleY)mPPJCwc?k=vBsQl^_hKl@25uU>f4(z+E-xuh$${e4ls2c^ zvmt$3c#t-gLeR>{iN@lsA@S)eTsJE0)w}4@jkuON`oYtNBulOcfG_olu7!15znyjw zV@Bk&M62GrY9{{GGgn@tXi;^z302cOmGo#jG}ql-qu@D|H^pc6oTg5E5s})1>K=Tlrn62|mT@(rmS>f%k0g zy}=;bG8QWui{bA3q*z^IA)LsAom=9|rS62AU(*wXT24Z?>0IP#1=u{>Iztu%3m3O{ zSJ9|d6c3MfUQih_xJ<=Qq^@~~MaB)8?C~>oT6snT0#cR=dt7#50+ZH*8@`?W^=3oa z$NEW(`go&qYe65|-qJ=7+)cb$Z66YKd@a}d@fekJal3Y(WgQ8==PjZxhxeqp<8`M2=Ha;D2(uZS~Qcg={u1k9<{5N(XQ8ephw!6@$3#gFUfQxLCYHm z;R?^KrGk_zjSr+wV@iH9nOy`RpNtDaK!MqydRtPo(~=b9;@2wCi*}{AcIN`1*4 zA&K5KYM{{;`6dS!&z`cnSqzZC=ziv<%H7Rv<3cCsTh|pSj}eHkgw?Qc_NqlYHGRFO z*y1}uYpj6n5d;P@k%;%K&h>RQwU`QB=mh4)UNkyflSCPD8`ijo-g*}J{ zS#|SYPu?B79}A3={X<^Uc3~!{6+v}KQ}e3oliAqpV-tR0IQ%v=pNVY_pKXsoP_{Gr z*9DUJCa=}dl^Z69L7)LviNo5R0nq}nbbOxSW6{d!e+ePw$k)PNHx@XzA~;Lf0;ouR7=FI#)@==?Wr8xHA>t6pd#21l%BMEIb; z_f^I8n|{akoK@?wKZ|PaPG9?ywH|7rE6*43(^9}de!7rXLDgrL#+G6G(T9`tC#(HrNsN597;*%ElHO+#1dvlFi&$VWYwps#`5JN0+QXaw)) zS0^S@ZwY}R4z1?G!HyU25PifQU)r?`rQ_mc2er1(6!Fr7m5pBbc&#)%Hu>E7?=`n( zhmRa>%+eo={@Ok`$J>VDJ##3lt+{(km+IZq+kA78iJ9>2E{}$IFxlZ@l7c{l&!9>M z+M&gdKp;>cCwY9;mmUh>{-D=ZYAMCF%%y@w6D3^$w z3J~SwF zP(tr%`UeaHf&8SaoGW>ed&KO-#c5}x8=}A=nTcGLI6lXbf9I2DB~CWei~3GSHi3o) z4c_=VnMftmp%VZdB7J+dfgz(5S@1(PG_0n)paE!_rh#{AaR*(=BZWS7$M&{D3TXU) zefR``u|IgZ^ey8m`F8d+m&U2qr!fQQw}`pgEQfTiQtfr}R`+oAS(Fbp&~^Fj?9rfv zh+9=;y!v(h;WhB){iv*Tmkv4Ewv{AvHh^v=VfW+p1QHN_mO@Pe F{tv7 Date: Wed, 19 Jun 2024 12:48:58 +0200 Subject: [PATCH 0712/1012] regenerate nxdl and nyaml files --- contributed_definitions/NXxps.nxdl.xml | 2 +- contributed_definitions/nyaml/NXxps.yaml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/NXxps.nxdl.xml b/contributed_definitions/NXxps.nxdl.xml index b6b1ae2dc4..1465f91367 100644 --- a/contributed_definitions/NXxps.nxdl.xml +++ b/contributed_definitions/NXxps.nxdl.xml @@ -54,7 +54,7 @@ In traditional surface science, the coordinate system is defined such that the positive z-axis points along the normal of the sample stage, and the x- and y-axes lie in the plane of the sample stage. However, in NeXus, a coordinate system that is the same as `McStas`_ is used. `xps_coordinate_system` - gives the user the opportunity to work in the traditional base coordinate system. + gives the user the opportunity to work in the traditional base coordinate system. .. _McStas: http://mcstas.org/ diff --git a/contributed_definitions/nyaml/NXxps.yaml b/contributed_definitions/nyaml/NXxps.yaml index 7be2ff1a0f..387eb5a0eb 100644 --- a/contributed_definitions/nyaml/NXxps.yaml +++ b/contributed_definitions/nyaml/NXxps.yaml @@ -236,7 +236,7 @@ NXxps(NXmpes): # In traditional surface science, the coordinate system is defined such that the positive z-axis # points along the normal of the sample stage, and the x- and y-axes lie in the plane of the sample stage. # However, in NeXus, a coordinate system that is the same as `McStas`_ is used. `xps_coordinate_system` -# gives the user the opportunity to work in the traditional base coordinate system. +# gives the user the opportunity to work in the traditional base coordinate system. # # .. _McStas: http://mcstas.org/ # From 8c30c1c13bbc6a08b6a046897973091d682da03e Mon Sep 17 00:00:00 2001 From: Rubel Date: Wed, 19 Jun 2024 13:30:37 +0200 Subject: [PATCH 0713/1012] PR change request. --- contributed_definitions/nyaml/NXsts.yaml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/nyaml/NXsts.yaml b/contributed_definitions/nyaml/NXsts.yaml index 1add11a652..60499d9793 100644 --- a/contributed_definitions/nyaml/NXsts.yaml +++ b/contributed_definitions/nyaml/NXsts.yaml @@ -289,7 +289,7 @@ NXsts(NXsensor_scan): current_calibration(NX_NUMBER): unit: NX_CURRENT doc: | - Value of calibration that comes as A/V. + Value of calibration that comes as A/V. The value for this concept can be read as current per unit voltage. current_offset(NX_NUMBER): unit: NX_CURRENT current_gain(NX_NUMBER): @@ -416,8 +416,8 @@ NXsts(NXsensor_scan): unit: NX_LENGTH exists: optional doc: | - In STM experiment The scan range is the coordinate along the X and Y axis from the origin of - the scan area (scan_offset) (e.g. 5.000000E-9 5.000000E-9) + In STM experiment, the scan range is the coordinate along the X and Y axis from the origin (scan_offset) of + the scan area (e.g. 5.000000E-9 5.000000E-9). scan_offset(NX_NUMBER): unit: NX_LENGTH exists: optional From 267be9eb46203a780dec93f49c81dceb9f6622c0 Mon Sep 17 00:00:00 2001 From: Rubel Date: Wed, 19 Jun 2024 13:34:54 +0200 Subject: [PATCH 0714/1012] PR change. --- contributed_definitions/NXsts.nxdl.xml | 16 ++++++++----- contributed_definitions/nyaml/NXsts.yaml | 29 ++++++++++++++++-------- 2 files changed, 29 insertions(+), 16 deletions(-) diff --git a/contributed_definitions/NXsts.nxdl.xml b/contributed_definitions/NXsts.nxdl.xml index 6d0876b98c..7458dc1133 100644 --- a/contributed_definitions/NXsts.nxdl.xml +++ b/contributed_definitions/NXsts.nxdl.xml @@ -25,6 +25,8 @@ 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the--> + Application definition for temperature-dependent IV curve measurements @@ -335,7 +337,8 @@ doc: The rate at which the one of the signal changes when ramping to the startin - Value of calibration that comes as A/V. + Value of calibration that comes as A/V. The value for this concept can be read + as current per unit voltage. @@ -474,19 +477,19 @@ parameters for a measurement at a single location during the scan--> - The scan range (in STM experiment) is the area that the tip will scan. (e.g. - 5.000000E-9 5.000000E-9) + In STM experiment, the scan range is the coordinate (x,y) along the X and Y axis from the origin (scan_offset) of + the scan area (e.g. 5.000000E-9 5.000000E-9). - The scan offset (in STM experiment) is the position of the tip in the scan area. + In STM experiment, the scan offset is the position of the tip at the starting point of scan area. (e.g. -2.354637E-7 1.267476E-) - The scan direction (in STM experiment) is the direction from which side of the + In STM experiment, the scan direction is the direction from which side of the sample the tip starts scanning. @@ -899,7 +902,8 @@ is switched off, it doesn't switch off immediately but continues to run for the - To describe sample and other constaints that applied on sample before scanning. + This describes the sample and its properties, as well as constraints that are + applied to the sample before scanning. diff --git a/contributed_definitions/nyaml/NXsts.yaml b/contributed_definitions/nyaml/NXsts.yaml index 60499d9793..0f1b3fa80d 100644 --- a/contributed_definitions/nyaml/NXsts.yaml +++ b/contributed_definitions/nyaml/NXsts.yaml @@ -21,6 +21,8 @@ doc: | # 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the +# 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the + # 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the type: group NXsts(NXsensor_scan): @@ -289,7 +291,8 @@ NXsts(NXsensor_scan): current_calibration(NX_NUMBER): unit: NX_CURRENT doc: | - Value of calibration that comes as A/V. The value for this concept can be read as current per unit voltage. + Value of calibration that comes as A/V. The value for this concept can be read + as current per unit voltage. current_offset(NX_NUMBER): unit: NX_CURRENT current_gain(NX_NUMBER): @@ -409,6 +412,7 @@ NXsts(NXsensor_scan): might be necessary. Usually, this parameter does not require manual adjustment within this module, as the sweep modules automatically set this value according to the sweep timings. (e.g. 500E-3) + # parameters how to change the location from measurement to measurement during the scan scan_control(NXcollection): exists: optional @@ -416,7 +420,7 @@ NXsts(NXsensor_scan): unit: NX_LENGTH exists: optional doc: | - In STM experiment, the scan range is the coordinate along the X and Y axis from the origin (scan_offset) of + In STM experiment, the scan range is the coordinate (x,y) along the X and Y axis from the origin (scan_offset) of the scan area (e.g. 5.000000E-9 5.000000E-9). scan_offset(NX_NUMBER): unit: NX_LENGTH @@ -833,7 +837,8 @@ NXsts(NXsensor_scan): sample(NXsample): exists: optional doc: | - This describes the sample and its properties, as well as constraints that are applied to the sample before scanning. + This describes the sample and its properties, as well as constraints that are + applied to the sample before scanning. sample_prep_descripton: doc: | At this moment no base class available that can track entire sample preparation. @@ -904,7 +909,7 @@ NXsts(NXsensor_scan): Mesh scan with 2D slices of the above alternative plot for other y co-ordinates. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 9ca3ac1a82c4164b4e143e595d65f73925ae05cc5df5ff2510156686c0a751a3 +# 9b03474c63a6c51c01d31f3cbd3ec65c6f18db027dd4b72cbca8e92c52e34f03 # # # # +# # # # Application definition for temperature-dependent IV curve measurements @@ -1242,7 +1249,8 @@ NXsts(NXsensor_scan): # # # -# Value of calibration that comes as A/V. +# Value of calibration that comes as A/V. The value for this concept can be read +# as current per unit voltage. # # # @@ -1381,19 +1389,19 @@ NXsts(NXsensor_scan): # # # -# The scan range (in STM experiment) is the area that the tip will scan. (e.g. -# 5.000000E-9 5.000000E-9) +# In STM experiment, the scan range is the coordinate (x,y) along the X and Y axis from the origin (scan_offset) of +# the scan area (e.g. 5.000000E-9 5.000000E-9). # # # # -# The scan offset (in STM experiment) is the position of the tip in the scan area. +# In STM experiment, the scan offset is the position of the tip at the starting point of scan area. # (e.g. -2.354637E-7 1.267476E-) # # # # -# The scan direction (in STM experiment) is the direction from which side of the +# In STM experiment, the scan direction is the direction from which side of the # sample the tip starts scanning. # # @@ -1806,7 +1814,8 @@ NXsts(NXsensor_scan): # # # -# To describe sample and other constaints that applied on sample before scanning. +# This describes the sample and its properties, as well as constraints that are +# applied to the sample before scanning. # # # From 5a8d2f91d3ab264f581ab692bf64e9d169cb778d Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 20 Jun 2024 12:08:14 +0200 Subject: [PATCH 0715/1012] rearrange order of transformations, add docs to depends_on --- contributed_definitions/NXxps.nxdl.xml | 82 ++++++------ contributed_definitions/nyaml/NXxps.yaml | 156 ++++++++++++----------- 2 files changed, 129 insertions(+), 109 deletions(-) diff --git a/contributed_definitions/NXxps.nxdl.xml b/contributed_definitions/NXxps.nxdl.xml index 1465f91367..9767a83ddd 100644 --- a/contributed_definitions/NXxps.nxdl.xml +++ b/contributed_definitions/NXxps.nxdl.xml @@ -83,7 +83,7 @@ x- and y-axes lie in the plane of the sample stage. - + Set of transformations, describing the orientation of the XPS coordinate system with respect to the beam coordinate system (.). @@ -99,12 +99,15 @@ .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 - + + + - + - Incidence angle + Azimuthal tilt of the beam from the y-direction towards the operator, defined + by the sample stage. @@ -113,19 +116,19 @@ - + - + - + - Azimuthal tilt of the source from the y-direction towards the operator, defined - by the sample stage. + Incidence angle of the beam with respect to the upward z-direction, defined by + the sample stage. @@ -134,13 +137,14 @@ - + - - - + + This should point to the last element of the coordinate system transformations defined in + /entry/sample_stage_cs_transformations/coordinate_system_transformations. + @@ -162,10 +166,10 @@ - + - Polar tilt of the analyser with respect to the upward z-direction, defined by - the sample stage. + Azimuthal tilt of the analyser from the y-direction towards the operator, + defined by the sample stage. @@ -174,19 +178,19 @@ - + - + - + - Azimuthal tilt of the analyser from the y-direction towards the operator, - defined by the sample stage. + Polar tilt of the analyser with respect to the upward z-direction, defined by + the sample stage. @@ -195,13 +199,14 @@ - + - - - + + This should point to the last element of the coordinate system transformations defined in + /entry/sample_stage_cs_transformations/coordinate_system_transformations. + @@ -235,14 +240,14 @@ - + - + - Polar tilt of the sample with respect to the upward z-direction, defined by the - sample stage. + Azimuthal tilt of the sample from the y-direction towards the operator, defined + by the sample stage. @@ -251,19 +256,19 @@ - + - + - + - Azimuthal tilt of the sample from the y-direction towards the operator, defined - by the sample stage. + Polar tilt of the sample with respect to the upward z-direction, defined by the + sample stage. @@ -272,13 +277,14 @@ - + - - - + + This should point to the last element of the coordinate system transformations defined in + /entry/sample_stage_cs_transformations/coordinate_system_transformations. + diff --git a/contributed_definitions/nyaml/NXxps.yaml b/contributed_definitions/nyaml/NXxps.yaml index 387eb5a0eb..0d7f2988c3 100644 --- a/contributed_definitions/nyaml/NXxps.yaml +++ b/contributed_definitions/nyaml/NXxps.yaml @@ -45,7 +45,7 @@ NXxps(NXmpes): Link to transformations defining the XPS base coordinate system, which is defined such that the positive z-axis points along the sample stage normal, and the x- and y-axes lie in the plane of the sample stage. - (NXtransformations): + coordinate_system_transformations(NXtransformations): doc: | Set of transformations, describing the orientation of the XPS coordinate system with respect to the beam coordinate system (.). @@ -58,33 +58,37 @@ NXxps(NXmpes): spec: ISO 18115-1:2023 term: 12.58 url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 - sourceTYPE(NXsource): + sourceTYPE(NXsource: power(NX_FLOAT): unit: NX_POWER exists: recommended + beamTYPE(NXbeam): transformations(NXtransformations): exists: recommended - source_polar_angle_of_incidence(NX_NUMBER): + beam_azimuth_angle(NX_NUMBER): unit: NX_ANGLE doc: | - Incidence angle + Azimuthal tilt of the beam from the y-direction towards the operator, defined + by the sample stage. \@transformation_type: enumeration: [rotation] \@vector: - enumeration: [[1, 0, 0]] + enumeration: [[0, 0, -1]] \@depends_on: - enumeration: [source_azimuth_angle] - source_azimuth_angle(NX_NUMBER): + enumeration: [beam_polar_angle_of_incidence] + beam_polar_angle_of_incidence(NX_NUMBER): unit: NX_ANGLE doc: | - Azimuthal tilt of the source from the y-direction towards the operator, defined - by the sample stage. + Incidence angle of the beam with respect to the upward z-direction, defined by + the sample stage. \@transformation_type: enumeration: [rotation] \@vector: - enumeration: [[0, 0, -1]] + enumeration: [[1, 0, 0]] \@depends_on: - enumeration: [/entry/sample_stage_cs_transformations/vamas_sample_stage_coordinate_system] + doc: | + This should point to the last element of the coordinate system transformations defined in + /entry/sample_stage_cs_transformations/coordinate_system_transformations. (NXelectronanalyser): work_function(NX_FLOAT): transmission_function(NXdata): @@ -105,28 +109,30 @@ NXxps(NXmpes): relative to a defined coordinate system. transformations(NXtransformations): exists: recommended - analyser_take_off_polar_angle(NX_NUMBER): + analyser_take_off_azimuth_angle(NX_NUMBER): unit: NX_ANGLE doc: | - Polar tilt of the analyser with respect to the upward z-direction, defined by - the sample stage. + Azimuthal tilt of the analyser from the y-direction towards the operator, + defined by the sample stage. \@transformation_type: enumeration: [rotation] \@vector: - enumeration: [[1, 0, 0]] + enumeration: [[0, 0, -1]] \@depends_on: - enumeration: [analyser_take_off_azimuth_angle] - analyser_take_off_azimuth_angle(NX_NUMBER): + enumeration: [analyser_take_off_polar_angle] + analyser_take_off_polar_angle(NX_NUMBER): unit: NX_ANGLE doc: | - Azimuthal tilt of the analyser from the y-direction towards the operator, - defined by the sample stage. + Polar tilt of the analyser with respect to the upward z-direction, defined by + the sample stage. \@transformation_type: enumeration: [rotation] \@vector: - enumeration: [[0, 0, -1]] + enumeration: [[1, 0, 0]] \@depends_on: - enumeration: [/entry/sample_stage_cs_transformations/vamas_sample_stage_coordinate_system] + doc: | + This should point to the last element of the coordinate system transformations defined in + /entry/sample_stage_cs_transformations/coordinate_system_transformations. (NXprocess_mpes): energy_referencing(NXcalibration): exists: recommended @@ -149,29 +155,31 @@ NXxps(NXmpes): \@vector: enumeration: [[0, 0, -1]] \@depends_on: - enumeration: [sample_normal_polar_angle] - sample_normal_polar_angle_of_tilt(NX_NUMBER): + enumeration: [sample_normal_tilt_azimuth_angle] + sample_normal_tilt_azimuth_angle(NX_NUMBER): unit: NX_ANGLE doc: | - Polar tilt of the sample with respect to the upward z-direction, defined by the - sample stage. + Azimuthal tilt of the sample from the y-direction towards the operator, defined + by the sample stage. \@transformation_type: enumeration: [rotation] \@vector: - enumeration: [[1, 0, 0]] + enumeration: [[0, 0, -1]] \@depends_on: - enumeration: [sample_normal_tilt_azimuth_angle] - sample_normal_tilt_azimuth_angle(NX_NUMBER): + enumeration: [sample_normal_polar_angle_of_tilt] + sample_normal_polar_angle_of_tilt(NX_NUMBER): unit: NX_ANGLE doc: | - Azimuthal tilt of the sample from the y-direction towards the operator, defined - by the sample stage. + Polar tilt of the sample with respect to the upward z-direction, defined by the + sample stage. \@transformation_type: enumeration: [rotation] \@vector: - enumeration: [[0, 0, -1]] + enumeration: [[1, 0, 0]] \@depends_on: - enumeration: [/entry/sample_stage_cs_transformations/vamas_sample_stage_coordinate_system] + doc: | + This should point to the last element of the coordinate system transformations defined in + /entry/sample_stage_cs_transformations/coordinate_system_transformations. data(NXdata): energy(NX_NUMBER): \@energy_indices: @@ -179,7 +187,7 @@ NXxps(NXmpes): exists: recommended # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 69aadc9c28afafd97a512c66335d639a3cf3895838fd6d6d8c2e5aa29b26f494 +# 8d4210f7f893b2b5259796eadb8324a970783568edc1918ef5bf83871ae6ea45 # # # Relevant value from the control software. @@ -42,11 +43,6 @@ use the description field for this. - - - Ideally, a (globally) unique persistent identifier, link, or text to a - resource which gives further details. Alternatively a free-text field to - store details noteworthy for contextualization or more detail. - - + diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml index a68436e9b7..0c2cf8883f 100644 --- a/contributed_definitions/NXcomponent_em.nxdl.xml +++ b/contributed_definitions/NXcomponent_em.nxdl.xml @@ -21,44 +21,38 @@ # # For further information, see http://www.nexusformat.org --> - Base class for components used in an electron microscope. The electron microscope can be a real one or a simulated microscope. - The key motivation behind this generalization is the observation that in all - cases a controlled electron beam is generated in reality or that beam is simulated - and this beam is then used or modified in a controlled manner for the purpose - of studying physical interaction mechanisms of the beam with matter. - Here it does not matter whether one considers a real specimen or a simulated one. - - Using a common description for the real experiment in the lab and - what is - typically a simplification of it - via a computer simulation, has the benefit - that many pieces of information can be stored in the same way. In effect, - users are guided with finding information and unnecessary descriptive - variety for what are exactly the same concept is avoided to work towards - more interoperability. - - Another motivation to make no fundamental distinction between a scanning and - a transmission electron microscope is that both are electron microscopes whose - components are often very similar. + + + Specifies the position of the component by pointing to the last + transformation in the transformation chain that is defined + via the NXtransformations group. + + - Given name to the component e.g stage, lens C1, etc. + Given name to the component. + + Exemplar value stage, lens C1. + + - Ideally, a (globally) unique persistent identifier, link, or text to a - resource which gives further details to this component. - If such resource does not exist, a free-text field to report - further details about the component is possible. + Ideally, use identifier to point to a resource which provides + further details of the component. + + If such a resource does not exist or should not be used, + use this, though discouraged, free-text field to report + further details about the component. - diff --git a/contributed_definitions/NXcorrector_ax.nxdl.xml b/contributed_definitions/NXcorrector_ax.nxdl.xml new file mode 100644 index 0000000000..c1ef50acfc --- /dev/null +++ b/contributed_definitions/NXcorrector_ax.nxdl.xml @@ -0,0 +1,62 @@ + + + + + + Base class for a corrector reshaping an ellipse-shaped electron beam to a circular one. + + * `L. Reimer 1998, Springer, 1998 <https://dx.doi.org/10.1007/978-3-540-3896>`_ + * `JEOL Electron Microscopy Glossary <https://www.jeol.com/words/semterms/20201020.111014.php#gsc.tab=0>`_ + + Stigmator is an exact synonym. + + + + + Was the corrector used? + + + + + Descriptor for the correction strength along the first direction when + exact technical details are unknown or not directly controllable as the + control software of the microscope does not enable or was not configured + to display these values (for end users). + + + + + Descriptor for the correction strength along the second direction when + exact technical details are unknown or not directly controllable as the + control software of the microscope does not enable or was not configured + to display these values (for end users). + + + + + + diff --git a/contributed_definitions/NXcorrector_cc.nxdl.xml b/contributed_definitions/NXcorrector_cc.nxdl.xml new file mode 100644 index 0000000000..e105a6006f --- /dev/null +++ b/contributed_definitions/NXcorrector_cc.nxdl.xml @@ -0,0 +1,51 @@ + + + + + + Base class for corrector reducing chromatic aberrations in an electron microscope. + + Examples are Wien or Omega filter. + + + + + Was the corrector used? + + + + + Qualitative type of the corrector. + + + + + + + + + + + + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 94c9b891f2..a0b80a2655 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -33,7 +33,7 @@ - Corrector for aberrations in an electron microscope. + Base class for a corrector reducing (spherical) aberrations in electron microscopy. Different technology partners use different naming schemes and models for quantifying the aberration coefficients. @@ -42,6 +42,7 @@ and multipole stigmators with details specific for the technology partner and microscope. Many of their technical details is proprietary knowledge. + Was the corrector used? @@ -50,23 +51,17 @@ - Specific information about the concrete alignment procedure which is a - process during which the corrector is configured to enable a calibrated - usage of the instrument. + Specific information about the alignment procedure that is a process during which + the corrector is configured to enable calibrated usage of the instrument. This :ref:`NXprocess` group should also be used when one describes in a computer simulation the specific details about the modelled or assumed aberration - corrections. In effect, this base class can also be used for harmonizing - the description of such simulation details across different computer codes - to enable that a research data management system can find these information - in a common place - formatted in a normalized representation. - This reduces the necessity to include substantial case-dependent verification - code in the research data management system. + corrections. - Discouraged free-text field to add further details about - the alignment procedure. + Discouraged free-text field to add further details about the alignment + procedure. @@ -110,7 +105,8 @@ - + - + + diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml index 675a1b1ef4..6a7b555d85 100644 --- a/contributed_definitions/NXlens_em.nxdl.xml +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -24,7 +24,7 @@ - + Base class for an electro-magnetic lens or a compound lens. @@ -35,40 +35,32 @@ with other research fields (MPES, XPS, OPT) could be useful--> For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ - - - Qualitative type of lens with respect to the number of pole pieces. - - - - - - - - - - - + + - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. + Descriptor for the lens excitation when the exact technical details + are unknown or not directly controllable as the control software of + the microscope does not enable or was not configured to display these + values (for end users). + + Although this value does not document the exact physical voltage or + excitation, it can still give useful context to reproduce the lens + setting, provided a properly working instrument and software sets the lens + into a similar state to the technical level possible when no more + information is available physically or accessible legally. - - - - + - Ideally an identifier, persistent link, or free text which - gives further details about the lens. + Descriptor for the operation mode of the lens when other details are not + directly controllable as the control software of the microscope + does not enable or is not configured to display these values. + + Like value, the mode can only be interpreted for a specific microscope + but can still be useful to guide users as to how to repeat the measurement. + Excitation voltage of the lens. @@ -82,48 +74,20 @@ with other research fields (MPES, XPS, OPT) could be useful--> Excitation current of the lens. For dipoles it is a single number. - For higher order multipoles, it is an array. - - - - - This field should be used when the exact voltage or current of the lens is not - directly controllable as the control software of the microscope does not enable - or was not configured to display these values (for end users). - - In this case this value field should be used and the value - from the control software stored as is. - - Although this value does not document the exact physical voltage or - excitation, it can still give useful context to reproduce the lens setting, - provided a properly working instrument and software sets the lens - into a similar state to the technical level possible when no more - information is available physically or accessible legally. + For higher-order multipoles, it is an array. - + + - This field should be used when the exact operation mode of the lens - is not directly controllable as the control software of the microscope - does not enable or was not configured to display these values. - - Like value the mode can only be interpreted for a specific microscope - but can still be useful to guide users as to how to repeat the measurement. + Qualitative type of lens with respect to the number of pole pieces. + + + + + + + - - - Specifies the position of the lens by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the lens as a component in the instrument. - Typically, the components of a system should all be related relative to - each other and only one component should relate to the reference - coordinate system. - - diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/contributed_definitions/NXscanbox_em.nxdl.xml index 56fe3ec6c7..a389fb01cb 100644 --- a/contributed_definitions/NXscanbox_em.nxdl.xml +++ b/contributed_definitions/NXscanbox_em.nxdl.xml @@ -30,10 +30,8 @@ The scanbox directs the probe of charged particles (electrons, ions) to controlled locations according to a scan scheme and plan. - - To achieve this task, the scanbox typically contains deflection coils, - which should be modelled as instances of :ref:`NXdeflector`. + Name of the typically tech-partner-specific term that specifies @@ -58,16 +56,7 @@ TODO discuss with the electron microscopists. - - - TODO discuss with the electron microscopists. - - - - - TODO discuss with the electron microscopists. - - + +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of voxel of discretized domain for analyzed part of the dataset. +# +# +# +# +# The dimensionality of the grid. +# +# +# +# +# The cardinality or total number of cells/grid points. +# +# +# +# +# Number of terms in the composition clustering dictionary +# +# +# +# +# Number of terms in the position clustering dictionary +# +# +# +# +# Results of a run with Alaukik Saxena's composition space tool. +# +# This is an initial draft application definition for the common NFDI-MatWerk, +# FAIRmat infrastructure use case IUC09 how to improve the organization and +# results storage of the composition space tool and make these data at the +# same time directly understandable for research data management systems +# like NOMAD Oasis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# TBD, maybe how to link between pyiron state tracking and app state tracking. +# +# +# +# +# Disencouraged place for free-text for e.g. comments. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when the analysis behind this results file +# was started, i.e. when composition space tool was started as a process. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when the analysis behind this results file +# were completed and composition space tool exited as a process. +# +# +# +# +# +# The path and name of the config file that was used for this analysis. +# TBD, this can be e.g. Alaukik's YAML file for composition space. +# +# +# +# +# +# +# +# +# Details about the file (technology partner or community format) +# from which reconstructed ion positions were loaded. +# +# +# +# +# +# +# +# +# Details about the file (technology partner or community format) +# from which ranging definitions were loaded which detail how to +# map mass-to-charge-state ratios on iontypes. +# +# +# +# +# +# +# +# +# +# Path to the directory where the tool should store NeXus/HDF5 results +# of this analysis. If not specified results will be stored in the +# current working directory. +# +# +# +# +# A statement whether the executable managed to process the analysis +# or failed prematurely. This status is written to the results file after the +# end_time at which point the executable must not compute any analysis. +# Only when this status message is present and shows `success`, the +# user should consider the results. In all other cases it might be +# that the executable has terminated prematurely or another error +# occurred. +# +# +# +# +# +# +# +# +# If used, contact information and eventually details +# of at least the person who performed this analysis. +# +# +# +# +# +# +# +# +# Details about coordinate systems (reference frames) used. In atom probe several coordinate +# systems have to be distinguished. Names of instances of such :ref:`NXcoordinate_system` +# should be documented explicitly and doing so by picking from the +# following controlled set of names: +# +# * composition_space +# * lab +# * specimen +# * laser +# * instrument +# * detector +# * recon +# +# The aim of this convention is to support users with contextualizing which reference +# frame each instance (coordinate system) is. If needed, instances of :ref:`NXtransformations` +# are used to detail the explicit affine transformations whereby one can convert +# representations between different reference frames. +# Inspect :ref:`NXtransformations` for further details. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Reference to or definition of a coordinate system with +# which the positions and directions are interpretable. +# +# +# +# +# +# +# +# +# +# Position of each cell in Euclidean space. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# For each ion, the identifier of the voxel in which the ion is located. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# In Alaukik's tool the GMM step. +# +# +# +# +# +# +# +# +# The keywords of the dictionary of distinguished compositionally- +# defined cluster, e.g. the phases. Examples for keywords could be +# phase1, phase2, and so one and so forth. +# +# +# +# +# +# +# +# Resolves for each keyword in cluster_dict which integer is used to +# label something that it belongs or is assumed to represent this +# cluster. +# +# +# +# +# +# +# +# +# For example if the voxel grid is used to report that there +# are voxels which are assumed to represent volume of either phase1 +# or phase2, the cluster_dict_keyword would be a list with two names +# phase1 and phase2, respectively. The cluster_dict_value would be a +# list of e.g. integers 1 and 2. These could be used to build an +# array with as many entries as there are voxel and store in this array +# the respective value to encode which phase is assumed for each voxel. +# +# +# +# +# +# +# +# +# +# In Alaukik's tool the DBScan step after the GMM step. +# +# +# +# +# +# +# +# +# The keywords of the dictionary of distinguished spatially-contiguous +# clusters. Examples for keywords could be precipitate1, precipitate2, +# and so one and so forth. +# +# +# +# +# +# +# +# Resolves for each keyword in cluster_dict which integer is used to +# label something that it belongs or is assumed to represent this +# cluster. +# +# +# +# +# +# +# +# +# For example if the voxel grid is used to report that there +# are voxels which are assumed to represent volume of certain precipitates, +# say we found ten precipitates and consider the rest as matrix. +# We could make a list of say matrix, precipitate1, precipitate2, ..., +# precipitate10. With cluster_dict_value then running from 0 to 10, +# i.e. matrix is flagged special as 0 and the remaining particles +# are indexed conveniently as 1, 2, ..., 10 like end users expect. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Specify if it was different from the number_of_processes +# in the NXcs_profiling super class. +# +# +# +# +# +# Specify if it was different from the number_of_threads +# in the NXcs_profiling super class. +# +# +# +# +# +# Specify if it was different from the number_of_threads +# in the NXcs_profiling super class. +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcomponent_em.yaml b/contributed_definitions/nyaml/NXcomponent_em.yaml index 78870cc26b..f1e20fe529 100644 --- a/contributed_definitions/nyaml/NXcomponent_em.yaml +++ b/contributed_definitions/nyaml/NXcomponent_em.yaml @@ -3,35 +3,28 @@ doc: | Base class for components used in an electron microscope. The electron microscope can be a real one or a simulated microscope. - The key motivation behind this generalization is the observation that in all - cases a controlled electron beam is generated in reality or that beam is simulated - and this beam is then used or modified in a controlled manner for the purpose - of studying physical interaction mechanisms of the beam with matter. - Here it does not matter whether one considers a real specimen or a simulated one. - - Using a common description for the real experiment in the lab and - what is - typically a simplification of it - via a computer simulation, has the benefit - that many pieces of information can be stored in the same way. In effect, - users are guided with finding information and unnecessary descriptive - variety for what are exactly the same concept is avoided to work towards - more interoperability. - - Another motivation to make no fundamental distinction between a scanning and - a transmission electron microscope is that both are electron microscopes whose - components are often very similar. -# `point Electronic GmbH `_ type: group NXcomponent_em(NXobject): + \@depends_on(NX_CHAR): + doc: | + Specifies the position of the component by pointing to the last + transformation in the transformation chain that is defined + via the NXtransformations group. name(NX_CHAR): doc: | - Given name to the component e.g stage, lens C1, etc. - description(NX_CHAR): # NXidentifier + Given name to the component. + + Exemplar value stage, lens C1. + fabrication(NXfabrication): + identifier(NXidentifier): + description(NX_CHAR): doc: | - Ideally, a (globally) unique persistent identifier, link, or text to a - resource which gives further details to this component. - If such resource does not exist, a free-text field to report - further details about the component is possible. - (NXfabrication): + Ideally, use identifier to point to a resource which provides + further details of the component. + + If such a resource does not exist or should not be used, + use this, though discouraged, free-text field to report + further details about the component. (NXprogram): (NXtransformations): doc: | diff --git a/contributed_definitions/nyaml/NXcorrector_ax.yaml b/contributed_definitions/nyaml/NXcorrector_ax.yaml new file mode 100644 index 0000000000..a1b1c9ad2b --- /dev/null +++ b/contributed_definitions/nyaml/NXcorrector_ax.yaml @@ -0,0 +1,34 @@ +category: base +doc: | + Base class for a corrector reshaping an ellipse-shaped electron beam to a circular one. + + * `L. Reimer 1998, Springer, 1998 `_ + * `JEOL Electron Microscopy Glossary `_ + + Stigmator is an exact synonym. +type: group +NXcorrector_ax(NXcomponent_em): + # user perspective + applied(NX_BOOLEAN): + doc: | + Was the corrector used? + value_x(NX_NUMBER): + doc: | + Descriptor for the correction strength along the first direction when + exact technical details are unknown or not directly controllable as the + control software of the microscope does not enable or was not configured + to display these values (for end users). + unit: NX_ANY + value_y(NX_NUMBER): + doc: | + Descriptor for the correction strength along the second direction when + exact technical details are unknown or not directly controllable as the + control software of the microscope does not enable or was not configured + to display these values (for end users). + # control level perspective + # strength(NX_NUMBER): + # axial component(NX_NUMBER): + # technical design perspective + (NXlens_em): + # (NXaperture_em): + # (NXdeflector): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXcorrector_cc.yaml b/contributed_definitions/nyaml/NXcorrector_cc.yaml new file mode 100644 index 0000000000..063eecec3a --- /dev/null +++ b/contributed_definitions/nyaml/NXcorrector_cc.yaml @@ -0,0 +1,21 @@ +category: base +doc: | + Base class for corrector reducing chromatic aberrations in an electron microscope. + + Examples are Wien or Omega filter. +type: group +NXcorrector_cc(NXcomponent_em): + # user perspective + applied(NX_BOOLEAN): + doc: | + Was the corrector used? + type(NX_CHAR): + doc: | + Qualitative type of the corrector. + enumeration: [wien_filter, omega_filter] + # control level perspective + # technical components of the corrector + (NXlens_em): + (NXaperture_em): + (NXdeflector): + (NXcrystal): diff --git a/contributed_definitions/nyaml/NXcorrector_cs.yaml b/contributed_definitions/nyaml/NXcorrector_cs.yaml index bbe1b033af..1ab4706f98 100644 --- a/contributed_definitions/nyaml/NXcorrector_cs.yaml +++ b/contributed_definitions/nyaml/NXcorrector_cs.yaml @@ -1,6 +1,6 @@ category: base doc: | - Corrector for aberrations in an electron microscope. + Base class for a corrector reducing (spherical) aberrations in electron microscopy. Different technology partners use different naming schemes and models for quantifying the aberration coefficients. @@ -15,28 +15,22 @@ symbols: n_img: | Number of images taken, at least one. NXcorrector_cs(NXcomponent_em): + # user perspective applied(NX_BOOLEAN): doc: | Was the corrector used? # NEW ISSUE: clarify the mathematical details behind the ZEMLIN_TABLEAU(NXprocess): doc: | - Specific information about the concrete alignment procedure which is a - process during which the corrector is configured to enable a calibrated - usage of the instrument. + Specific information about the alignment procedure that is a process during which + the corrector is configured to enable calibrated usage of the instrument. This :ref:`NXprocess` group should also be used when one describes in a computer simulation the specific details about the modelled or assumed aberration - corrections. In effect, this base class can also be used for harmonizing - the description of such simulation details across different computer codes - to enable that a research data management system can find these information - in a common place - formatted in a normalized representation. - This reduces the necessity to include substantial case-dependent verification - code in the research data management system. + corrections. description(NX_CHAR): doc: | - Discouraged free-text field to add further details about - the alignment procedure. + Discouraged free-text field to add further details about the alignment procedure. tilt_angle(NX_NUMBER): doc: | The outer tilt angle of the beam in tableau acquisition. @@ -64,5 +58,7 @@ NXcorrector_cs(NXcomponent_em): Place for storing measured or estimated aberrations (for each image or final). ceos(NXaberration_model_ceos): nion(NXaberration_model_nion): - # technical components of the corrector + # technical design perspective (NXlens_em): + (NXaperture_em): + # (NXdeflector): diff --git a/contributed_definitions/nyaml/NXlens_em.yaml b/contributed_definitions/nyaml/NXlens_em.yaml index 7c9fba6b00..ae70e0cf2a 100644 --- a/contributed_definitions/nyaml/NXlens_em.yaml +++ b/contributed_definitions/nyaml/NXlens_em.yaml @@ -11,29 +11,30 @@ doc: | type: group # more consolidation to harvest from a generic component base class # with other research fields (MPES, XPS, OPT) could be useful -NXlens_em(NXobject): - type(NX_CHAR): - doc: | - Qualitative type of lens with respect to the number of pole pieces. - enumeration: [single, double, quadrupole, hexapole, octupole] - # purpose(NX_CHAR): - # enumeration: [c1, c2, diffraction, etc.] - name(NX_CHAR): +NXlens_em(NXcomponent_em): + # user perspective + value(NX_NUMBER): doc: | - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - # manufacturer_name: - # doc: | - # Name of the manufacturer who built/constructed the lens. - (NXfabrication): - # model: - # doc: | - # Hardware name, hash identifier, or serial number that was given by the - # manufacturer to identify the lens. - description(NX_CHAR): # NXidentifier + Descriptor for the lens excitation when the exact technical details + are unknown or not directly controllable as the control software of + the microscope does not enable or was not configured to display these + values (for end users). + + Although this value does not document the exact physical voltage or + excitation, it can still give useful context to reproduce the lens + setting, provided a properly working instrument and software sets the lens + into a similar state to the technical level possible when no more + information is available physically or accessible legally. + unit: NX_ANY + mode(NX_CHAR): doc: | - Ideally an identifier, persistent link, or free text which - gives further details about the lens. + Descriptor for the operation mode of the lens when other details are not + directly controllable as the control software of the microscope + does not enable or is not configured to display these values. + + Like value, the mode can only be interpreted for a specific microscope + but can still be useful to guide users as to how to repeat the measurement. + # control level perspective voltage(NX_NUMBER): doc: | Excitation voltage of the lens. @@ -46,39 +47,10 @@ NXlens_em(NXobject): Excitation current of the lens. For dipoles it is a single number. - For higher order multipoles, it is an array. + For higher-order multipoles, it is an array. unit: NX_CURRENT - value(NX_NUMBER): - doc: | - This field should be used when the exact voltage or current of the lens is not - directly controllable as the control software of the microscope does not enable - or was not configured to display these values (for end users). - - In this case this value field should be used and the value - from the control software stored as is. - - Although this value does not document the exact physical voltage or - excitation, it can still give useful context to reproduce the lens setting, - provided a properly working instrument and software sets the lens - into a similar state to the technical level possible when no more - information is available physically or accessible legally. - unit: NX_ANY - mode(NX_CHAR): - doc: | - This field should be used when the exact operation mode of the lens - is not directly controllable as the control software of the microscope - does not enable or was not configured to display these values. - - Like value the mode can only be interpreted for a specific microscope - but can still be useful to guide users as to how to repeat the measurement. - \@depends_on(NX_CHAR): - doc: | - Specifies the position of the lens by pointing to the last transformation in the - transformation chain in the NXtransformations group. - (NXtransformations): + # technical design perspective + type(NX_CHAR): doc: | - Collection of axis-based translations and rotations to describe the - location and geometry of the lens as a component in the instrument. - Typically, the components of a system should all be related relative to - each other and only one component should relate to the reference - coordinate system. + Qualitative type of lens with respect to the number of pole pieces. + enumeration: [single, double, quadrupole, hexapole, octupole] diff --git a/contributed_definitions/nyaml/NXscanbox_em.yaml b/contributed_definitions/nyaml/NXscanbox_em.yaml index 0c5c2a6f27..c8ab212630 100644 --- a/contributed_definitions/nyaml/NXscanbox_em.yaml +++ b/contributed_definitions/nyaml/NXscanbox_em.yaml @@ -7,11 +7,9 @@ doc: | The scanbox directs the probe of charged particles (electrons, ions) to controlled locations according to a scan scheme and plan. - - To achieve this task, the scanbox typically contains deflection coils, - which should be modelled as instances of :ref:`NXdeflector`. type: group -NXscanbox_em(NXcomponent_em): +NXscanbox_em(NXcomponent_em): # await discussion on base class NXscan_control + # user perspective scan_schema(NX_CHAR): doc: | Name of the typically tech-partner-specific term that specifies @@ -31,14 +29,7 @@ NXscanbox_em(NXcomponent_em): doc: | TODO discuss with the electron microscopists. unit: NX_ANY - flyback_time(NX_NUMBER): - doc: | - TODO discuss with the electron microscopists. - unit: NX_TIME - line_time(NX_NUMBER): - doc: | - TODO discuss with the electron microscopists. - unit: NX_TIME + # descriptors relevant from economic usage and dose management perspective dwell_time(NX_NUMBER): doc: | Time period during which the beam remains at one position. @@ -47,6 +38,14 @@ NXscanbox_em(NXcomponent_em): # term: Dwell time # url: https://em-glossary.vercel.app/term/em-dwell-time unit: NX_TIME + flyback_time(NX_NUMBER): + doc: | + TODO discuss with the electron microscopists. + unit: NX_TIME + line_time(NX_NUMBER): + doc: | + TODO discuss with the electron microscopists. + unit: NX_TIME pixel_time(NX_NUMBER): doc: | TODO discuss with the electron microscopists. @@ -55,13 +54,16 @@ NXscanbox_em(NXcomponent_em): doc: | TODO discuss with the electron microscopists. unit: NX_TIME - rotation(NX_NUMBER): + ac_line_sync(NX_BOOLEAN): doc: | TODO discuss with the electron microscopists. - unit: NX_ANGLE - ac_line_sync(NX_BOOLEAN): + rotation(NX_NUMBER): doc: | TODO discuss with the electron microscopists. + unit: NX_ANGLE + # technical design perspective + # (NXlens_em): + # (NXaperture_em): (NXdeflector): # (NXcg_point_set): # NEW ISSUE: build on work of EMglossary with HMC and use duty cycle instead From 78a476117e5392a2311b0bc5cb89f5c2e6fc60e0 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 25 Jun 2024 18:12:59 +0200 Subject: [PATCH 0718/1012] #243 add description field in NXevent_data_em pointing to information source inside tech partner file --- contributed_definitions/NXimage_set.nxdl.xml | 7 ++++++- contributed_definitions/NXspectrum_set.nxdl.xml | 6 ++++++ contributed_definitions/nyaml/NXimage_set.yaml | 7 ++++++- contributed_definitions/nyaml/NXspectrum_set.yaml | 6 ++++++ 4 files changed, 24 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/NXimage_set.nxdl.xml b/contributed_definitions/NXimage_set.nxdl.xml index 1aed5116e6..b2521608d7 100644 --- a/contributed_definitions/NXimage_set.nxdl.xml +++ b/contributed_definitions/NXimage_set.nxdl.xml @@ -55,6 +55,12 @@ Resolvable data artifact (e.g. filename) from which the all values in the :ref:`NXdata` instances in this :ref:`NXimage_set` were loaded during parsing. + + Possibility to document from which specific other serialized resource + as the source pieces of information where processed when NeXus is used + as a semantic file format to serialize that information differently. + + The group in combination with an added field *absolute_path* therein adds context. @@ -71,5 +77,4 @@ - diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml index b8ee62d737..55f2131302 100644 --- a/contributed_definitions/NXspectrum_set.nxdl.xml +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -69,6 +69,12 @@ NXspectrum_set to reduce redundant fields and specialized NXspectrum_r/c_set--> Resolvable data artifact (e.g. filename) from which the all values in the :ref:`NXdata` instances in this :ref:`NXspectrum_set` were loaded during parsing. + + Possibility to document from which specific other serialized resource + as the source pieces of information where processed when NeXus is used + as a semantic file format to serialize that information differently. + + The group in combination with an add field *absolute_path* therein adds context. diff --git a/contributed_definitions/nyaml/NXimage_set.yaml b/contributed_definitions/nyaml/NXimage_set.yaml index 91e40434d9..48cbedb1f5 100644 --- a/contributed_definitions/nyaml/NXimage_set.yaml +++ b/contributed_definitions/nyaml/NXimage_set.yaml @@ -22,6 +22,12 @@ NXimage_set(NXobject): Resolvable data artifact (e.g. filename) from which the all values in the :ref:`NXdata` instances in this :ref:`NXimage_set` were loaded during parsing. + + Possibility to document from which specific other serialized resource + as the source pieces of information where processed when NeXus is used + as a semantic file format to serialize that information differently. + + The group in combination with an added field *absolute_path* therein adds context. mode(NX_CHAR): doc: | Imaging (data collection) mode of the instrument during acquisition @@ -30,4 +36,3 @@ NXimage_set(NXobject): doc: | Link or name of an :ref:`NXdetector` instance with which the data were collected. (NXprogram): - # (NXdata): diff --git a/contributed_definitions/nyaml/NXspectrum_set.yaml b/contributed_definitions/nyaml/NXspectrum_set.yaml index 910b04ecff..5cee48ffea 100644 --- a/contributed_definitions/nyaml/NXspectrum_set.yaml +++ b/contributed_definitions/nyaml/NXspectrum_set.yaml @@ -30,6 +30,12 @@ NXspectrum_set(NXobject): Resolvable data artifact (e.g. filename) from which the all values in the :ref:`NXdata` instances in this :ref:`NXspectrum_set` were loaded during parsing. + + Possibility to document from which specific other serialized resource + as the source pieces of information where processed when NeXus is used + as a semantic file format to serialize that information differently. + + The group in combination with an add field *absolute_path* therein adds context. mode(NX_CHAR): doc: | Imaging (data collection) mode of the instrument during acquisition From d0af56fd9d914f4ed05d4e9850fde6de52627c4a Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 25 Jun 2024 18:30:32 +0200 Subject: [PATCH 0719/1012] Added alpha filter --- contributed_definitions/nyaml/NXcorrector_cc.yaml | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/contributed_definitions/nyaml/NXcorrector_cc.yaml b/contributed_definitions/nyaml/NXcorrector_cc.yaml index 063eecec3a..dfc1d46cbd 100644 --- a/contributed_definitions/nyaml/NXcorrector_cc.yaml +++ b/contributed_definitions/nyaml/NXcorrector_cc.yaml @@ -1,8 +1,9 @@ category: base doc: | - Base class for corrector reducing chromatic aberrations in an electron microscope. + Base class for improving energy resolution in an electron microscope. - Examples are Wien or Omega filter. + Examples are Wien, $\textalpha$-, or $\Omega$- energy filter. +# more discussion type: group NXcorrector_cc(NXcomponent_em): # user perspective @@ -11,10 +12,14 @@ NXcorrector_cc(NXcomponent_em): Was the corrector used? type(NX_CHAR): doc: | - Qualitative type of the corrector. - enumeration: [wien_filter, omega_filter] + Qualitative type of the component. + enumeration: [wien_filter, alfa_filter, omega_filter] # control level perspective # technical components of the corrector + energy_dispersion(NX_NUMBER): + doc: | + Energy dispersion in e.g. µm/eV. + unit: NX_ANY (NXlens_em): (NXaperture_em): (NXdeflector): From 72e8f0a7af21f688fe9125062b98f41d611b2650 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 25 Jun 2024 18:32:38 +0200 Subject: [PATCH 0720/1012] corrector_cs renamed --- .../nyaml/{NXcorrector_cc.yaml => NXenergy_filter_em.yaml} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename contributed_definitions/nyaml/{NXcorrector_cc.yaml => NXenergy_filter_em.yaml} (90%) diff --git a/contributed_definitions/nyaml/NXcorrector_cc.yaml b/contributed_definitions/nyaml/NXenergy_filter_em.yaml similarity index 90% rename from contributed_definitions/nyaml/NXcorrector_cc.yaml rename to contributed_definitions/nyaml/NXenergy_filter_em.yaml index dfc1d46cbd..e72bda947e 100644 --- a/contributed_definitions/nyaml/NXcorrector_cc.yaml +++ b/contributed_definitions/nyaml/NXenergy_filter_em.yaml @@ -5,7 +5,7 @@ doc: | Examples are Wien, $\textalpha$-, or $\Omega$- energy filter. # more discussion type: group -NXcorrector_cc(NXcomponent_em): +NXenergy_filter_em(NXcomponent_em): # user perspective applied(NX_BOOLEAN): doc: | @@ -16,7 +16,7 @@ NXcorrector_cc(NXcomponent_em): enumeration: [wien_filter, alfa_filter, omega_filter] # control level perspective # technical components of the corrector - energy_dispersion(NX_NUMBER): + dispersion(NX_NUMBER): doc: | Energy dispersion in e.g. µm/eV. unit: NX_ANY From 94c8e1ff72f8a16901974e37483b6dace252ff6d Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 25 Jun 2024 18:33:45 +0200 Subject: [PATCH 0721/1012] nxdl --- ...r_cc.nxdl.xml => NXenergy_filter_em.nxdl.xml} | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) rename contributed_definitions/{NXcorrector_cc.nxdl.xml => NXenergy_filter_em.nxdl.xml} (75%) diff --git a/contributed_definitions/NXcorrector_cc.nxdl.xml b/contributed_definitions/NXenergy_filter_em.nxdl.xml similarity index 75% rename from contributed_definitions/NXcorrector_cc.nxdl.xml rename to contributed_definitions/NXenergy_filter_em.nxdl.xml index e105a6006f..d4f5d116e9 100644 --- a/contributed_definitions/NXcorrector_cc.nxdl.xml +++ b/contributed_definitions/NXenergy_filter_em.nxdl.xml @@ -21,11 +21,13 @@ # # For further information, see http://www.nexusformat.org --> - + + - Base class for corrector reducing chromatic aberrations in an electron microscope. + Base class for improving energy resolution in an electron microscope. - Examples are Wien or Omega filter. + Examples are Wien, $\textalpha$-, or $\Omega$- energy filter. @@ -35,15 +37,21 @@ - Qualitative type of the corrector. + Qualitative type of the component. + + + + Energy dispersion in e.g. µm/eV. + + From 1bc6dc4a16ad4a2ef5ef51220f52752f86c082fa Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 25 Jun 2024 18:53:53 +0200 Subject: [PATCH 0722/1012] Further components of an EM --- contributed_definitions/NXbiprism_em.nxdl.xml | 36 +++++++++++++++++++ .../NXcorrector_ax.nxdl.xml | 2 +- .../NXenergy_filter_em.nxdl.xml | 14 ++++++-- .../nyaml/NXbiprism_em.yaml | 10 ++++++ .../nyaml/NXcorrector_ax.yaml | 2 +- .../nyaml/NXenergy_filter_em.yaml | 6 +++- 6 files changed, 64 insertions(+), 6 deletions(-) create mode 100644 contributed_definitions/NXbiprism_em.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXbiprism_em.yaml diff --git a/contributed_definitions/NXbiprism_em.nxdl.xml b/contributed_definitions/NXbiprism_em.nxdl.xml new file mode 100644 index 0000000000..c826d453b6 --- /dev/null +++ b/contributed_definitions/NXbiprism_em.nxdl.xml @@ -0,0 +1,36 @@ + + + + + + + Base class for electron biprism as it is used in electron microscopy. + + + + + Was the prism used? + + + diff --git a/contributed_definitions/NXcorrector_ax.nxdl.xml b/contributed_definitions/NXcorrector_ax.nxdl.xml index c1ef50acfc..055c99054c 100644 --- a/contributed_definitions/NXcorrector_ax.nxdl.xml +++ b/contributed_definitions/NXcorrector_ax.nxdl.xml @@ -26,7 +26,7 @@ Base class for a corrector reshaping an ellipse-shaped electron beam to a circular one. * `L. Reimer 1998, Springer, 1998 <https://dx.doi.org/10.1007/978-3-540-3896>`_ - * `JEOL Electron Microscopy Glossary <https://www.jeol.com/words/semterms/20201020.111014.php#gsc.tab=0>`_ + * `M. Tanaka et al., Electron Microscopy Glossary, 2024 <https://www.jeol.com/words/semterms/20201020.111014.php#gsc.tab=0>`_ Stigmator is an exact synonym. diff --git a/contributed_definitions/NXenergy_filter_em.nxdl.xml b/contributed_definitions/NXenergy_filter_em.nxdl.xml index d4f5d116e9..5f0230d4ef 100644 --- a/contributed_definitions/NXenergy_filter_em.nxdl.xml +++ b/contributed_definitions/NXenergy_filter_em.nxdl.xml @@ -40,9 +40,12 @@ more discussion--> Qualitative type of the component. - - - + + + + + + Energy dispersion in e.g. µm/eV. + + + Corresponding voltage for that energy dispersion. + + diff --git a/contributed_definitions/nyaml/NXbiprism_em.yaml b/contributed_definitions/nyaml/NXbiprism_em.yaml new file mode 100644 index 0000000000..6a689c4ec6 --- /dev/null +++ b/contributed_definitions/nyaml/NXbiprism_em.yaml @@ -0,0 +1,10 @@ +category: base +doc: | + Base class for electron biprism as it is used in electron microscopy. +# more discussion +type: group +NXbiprism_em(NXcomponent_em): + # user perspective + applied(NX_BOOLEAN): + doc: | + Was the prism used? diff --git a/contributed_definitions/nyaml/NXcorrector_ax.yaml b/contributed_definitions/nyaml/NXcorrector_ax.yaml index a1b1c9ad2b..154a8c25d9 100644 --- a/contributed_definitions/nyaml/NXcorrector_ax.yaml +++ b/contributed_definitions/nyaml/NXcorrector_ax.yaml @@ -3,7 +3,7 @@ doc: | Base class for a corrector reshaping an ellipse-shaped electron beam to a circular one. * `L. Reimer 1998, Springer, 1998 `_ - * `JEOL Electron Microscopy Glossary `_ + * `M. Tanaka et al., Electron Microscopy Glossary, 2024 `_ Stigmator is an exact synonym. type: group diff --git a/contributed_definitions/nyaml/NXenergy_filter_em.yaml b/contributed_definitions/nyaml/NXenergy_filter_em.yaml index e72bda947e..6eba543c55 100644 --- a/contributed_definitions/nyaml/NXenergy_filter_em.yaml +++ b/contributed_definitions/nyaml/NXenergy_filter_em.yaml @@ -13,13 +13,17 @@ NXenergy_filter_em(NXcomponent_em): type(NX_CHAR): doc: | Qualitative type of the component. - enumeration: [wien_filter, alfa_filter, omega_filter] + enumeration: [wien, alfa, omega, castaing_henry, gatan_imaging, sector_analyzer] # control level perspective # technical components of the corrector dispersion(NX_NUMBER): doc: | Energy dispersion in e.g. µm/eV. unit: NX_ANY + voltage(NX_NUMBER): + doc: | + Corresponding voltage for that energy dispersion. + unit: NX_VOLTAGE (NXlens_em): (NXaperture_em): (NXdeflector): From 570d0370183a91cc8eb9a3a03be9f4fe71bf7595 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 25 Jun 2024 19:25:38 +0200 Subject: [PATCH 0723/1012] Some guide what to do with more modern correctors for (S)TEM --- contributed_definitions/NXcorrector_cs.nxdl.xml | 8 ++++++++ contributed_definitions/NXlens_em.nxdl.xml | 1 + ...gy_filter_em.nxdl.xml => NXmonochromator_em.nxdl.xml} | 8 +++++--- contributed_definitions/nyaml/NXcorrector_cs.yaml | 9 +++++++++ contributed_definitions/nyaml/NXlens_em.yaml | 2 +- .../{NXenergy_filter_em.yaml => NXmonochromator_em.yaml} | 8 +++++--- 6 files changed, 29 insertions(+), 7 deletions(-) rename contributed_definitions/{NXenergy_filter_em.nxdl.xml => NXmonochromator_em.nxdl.xml} (92%) rename contributed_definitions/nyaml/{NXenergy_filter_em.yaml => NXmonochromator_em.yaml} (76%) diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index a0b80a2655..9bf122a4f0 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -41,6 +41,14 @@ The corrector in an electron microscope is composed of multiple lenses and multipole stigmators with details specific for the technology partner and microscope. Many of their technical details is proprietary knowledge. + + If functionalities for correcting multiple aberrations are included in + one :ref:`NXcomponent_em` `like it is reported here <https://www.ceos-gmbh.de/en/research/electrostat>`_ + use multiple groups: + + * :ref:`NXcorrector_cs` for spherical aberration + * :ref:`NXmonochromator_em` for energy filtering or chromatic aberration + * :ref:`NXcorrector_ax` for axial astigmatism correction diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml index 6a7b555d85..672dc7ed18 100644 --- a/contributed_definitions/NXlens_em.nxdl.xml +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -88,6 +88,7 @@ with other research fields (MPES, XPS, OPT) could be useful--> + diff --git a/contributed_definitions/NXenergy_filter_em.nxdl.xml b/contributed_definitions/NXmonochromator_em.nxdl.xml similarity index 92% rename from contributed_definitions/NXenergy_filter_em.nxdl.xml rename to contributed_definitions/NXmonochromator_em.nxdl.xml index 5f0230d4ef..67ec4d0e7e 100644 --- a/contributed_definitions/NXenergy_filter_em.nxdl.xml +++ b/contributed_definitions/NXmonochromator_em.nxdl.xml @@ -23,11 +23,13 @@ --> - + - Base class for improving energy resolution in an electron microscope. + Base class for improving energy resolution in an electron microscope + or reducing chromatic aberration. - Examples are Wien, $\textalpha$-, or $\Omega$- energy filter. + Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or + `cc corrector like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ diff --git a/contributed_definitions/nyaml/NXcorrector_cs.yaml b/contributed_definitions/nyaml/NXcorrector_cs.yaml index 1ab4706f98..85c1140357 100644 --- a/contributed_definitions/nyaml/NXcorrector_cs.yaml +++ b/contributed_definitions/nyaml/NXcorrector_cs.yaml @@ -8,6 +8,15 @@ doc: | The corrector in an electron microscope is composed of multiple lenses and multipole stigmators with details specific for the technology partner and microscope. Many of their technical details is proprietary knowledge. + + If functionalities for correcting multiple aberrations are included in + one :ref:`NXcomponent_em` `like it is reported here `_ + use multiple groups: + + * :ref:`NXcorrector_cs` for spherical aberration + * :ref:`NXmonochromator_em` for energy filtering or chromatic aberration + * :ref:`NXcorrector_ax` for axial astigmatism correction + type: group symbols: doc: | diff --git a/contributed_definitions/nyaml/NXlens_em.yaml b/contributed_definitions/nyaml/NXlens_em.yaml index ae70e0cf2a..c8271e70dd 100644 --- a/contributed_definitions/nyaml/NXlens_em.yaml +++ b/contributed_definitions/nyaml/NXlens_em.yaml @@ -53,4 +53,4 @@ NXlens_em(NXcomponent_em): type(NX_CHAR): doc: | Qualitative type of lens with respect to the number of pole pieces. - enumeration: [single, double, quadrupole, hexapole, octupole] + enumeration: [single, double, quadrupole, hexapole, octupole, dodecapole] diff --git a/contributed_definitions/nyaml/NXenergy_filter_em.yaml b/contributed_definitions/nyaml/NXmonochromator_em.yaml similarity index 76% rename from contributed_definitions/nyaml/NXenergy_filter_em.yaml rename to contributed_definitions/nyaml/NXmonochromator_em.yaml index 6eba543c55..debc308c9b 100644 --- a/contributed_definitions/nyaml/NXenergy_filter_em.yaml +++ b/contributed_definitions/nyaml/NXmonochromator_em.yaml @@ -1,11 +1,13 @@ category: base doc: | - Base class for improving energy resolution in an electron microscope. + Base class for improving energy resolution in an electron microscope + or reducing chromatic aberration. - Examples are Wien, $\textalpha$-, or $\Omega$- energy filter. + Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or + `cc corrector like `_ # more discussion type: group -NXenergy_filter_em(NXcomponent_em): +NXmonochromator_em(NXcomponent_em): # user perspective applied(NX_BOOLEAN): doc: | From d4278aaac3951e5244b04d46ecd6ca5199041e05 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 25 Jun 2024 19:40:17 +0200 Subject: [PATCH 0724/1012] Introducing at least a place where to store information about a phase plate device --- .../NXphase_plate_em.nxdl.xml | 45 +++++++++++++++++++ .../nyaml/NXphase_plate_em.yaml | 17 +++++++ 2 files changed, 62 insertions(+) create mode 100644 contributed_definitions/NXphase_plate_em.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXphase_plate_em.yaml diff --git a/contributed_definitions/NXphase_plate_em.nxdl.xml b/contributed_definitions/NXphase_plate_em.nxdl.xml new file mode 100644 index 0000000000..9082f7caa1 --- /dev/null +++ b/contributed_definitions/NXphase_plate_em.nxdl.xml @@ -0,0 +1,45 @@ + + + + + + + Base class for device that causes a change in the phase of an electron wave. + + * `M. Malac et al. <https://doi.org/10.1093/jmicro/dfaa070>`_ + * `R. R. Schröder et al. <https://www.lem.kit.edu/152.php>`_ + + + + + Qualitative type. + + + + + + + + diff --git a/contributed_definitions/nyaml/NXphase_plate_em.yaml b/contributed_definitions/nyaml/NXphase_plate_em.yaml new file mode 100644 index 0000000000..8d0ead5f5b --- /dev/null +++ b/contributed_definitions/nyaml/NXphase_plate_em.yaml @@ -0,0 +1,17 @@ +category: base +doc: | + Base class for device that causes a change in the phase of an electron wave. + + * `M. Malac et al. `_ + * `R. R. Schröder et al. `_ + +# more discussion +type: group +NXphase_plate_em(NXcomponent_em): + # user perspective + type(NX_CHAR): + doc: | + Qualitative type. + enumeration: [thin_film_based, electrostatic] + # control level perspective + # technical components of the corrector From 984536fdfaec513502c7502202684acea529c71a Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 25 Jun 2024 19:43:22 +0200 Subject: [PATCH 0725/1012] Minor --- contributed_definitions/NXphase_plate_em.nxdl.xml | 4 ++-- contributed_definitions/nyaml/NXphase_plate_em.yaml | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/contributed_definitions/NXphase_plate_em.nxdl.xml b/contributed_definitions/NXphase_plate_em.nxdl.xml index 9082f7caa1..0f095f1c30 100644 --- a/contributed_definitions/NXphase_plate_em.nxdl.xml +++ b/contributed_definitions/NXphase_plate_em.nxdl.xml @@ -33,10 +33,10 @@ more discussion--> - Qualitative type. + Qualitative type - + diff --git a/contributed_definitions/nyaml/NXphase_plate_em.yaml b/contributed_definitions/nyaml/NXphase_plate_em.yaml index 8d0ead5f5b..7aa78f6438 100644 --- a/contributed_definitions/nyaml/NXphase_plate_em.yaml +++ b/contributed_definitions/nyaml/NXphase_plate_em.yaml @@ -11,7 +11,7 @@ NXphase_plate_em(NXcomponent_em): # user perspective type(NX_CHAR): doc: | - Qualitative type. - enumeration: [thin_film_based, electrostatic] + Qualitative type + enumeration: [thin_film, electrostatic] # control level perspective # technical components of the corrector From 2fb22fba96848f7e8a09bfe79a9eb64be62e9e9f Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 26 Jun 2024 11:47:49 +0200 Subject: [PATCH 0726/1012] Added connections to EMglossary, fixed deprecated call to utcnow --- contributed_definitions/NXem.nxdl.xml | 63 ++++++++++- contributed_definitions/NXem_ebsd.nxdl.xml | 6 +- contributed_definitions/NXlens_em.nxdl.xml | 2 + .../NXoptical_system_em.nxdl.xml | 97 ++++++++++++++--- contributed_definitions/NXscanbox_em.nxdl.xml | 17 +-- contributed_definitions/nyaml/NXem.yaml | 76 +++++++++++-- contributed_definitions/nyaml/NXem_ebsd.yaml | 10 +- contributed_definitions/nyaml/NXlens_em.yaml | 2 + .../nyaml/NXoptical_system_em.yaml | 101 ++++++++++++++---- .../nyaml/NXscanbox_em.yaml | 23 ++-- dev_tools/docs/anchor_list.py | 2 +- 11 files changed, 335 insertions(+), 64 deletions(-) diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 63dbd6f626..5e6233847c 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -29,10 +29,9 @@ with which to normalize specific pieces of information and data collected within electron microscopy research. - NXem is designed to be used for documentation of experiments or computer simulations - of controlled electron beams which are used for studying electron-beam matter interaction - to explore physical mechanisms and phenomena, or to characterize materials with - electron microscopy. + NXem is designed to be used for documenting experiments or computer simulations in which + controlled electron beams are used for studying electron-beam matter interaction to explore + physical mechanisms and phenomena, or to characterize materials. + + This concept is related to term `Source`_ of the EMglossary standard. + + .. _Source: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 + @@ -752,7 +760,48 @@ the fields they can be used--> - + + This concept is related to term `Source`_ of the EMglossary standard. + + .. _Source: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 + + + + The potential difference between anode and cathode. + + This concept is related to term `Acceleration Voltage`_ of the EMglossary standard. + + .. _Acceleration Voltage: https://purls.helmholtz-metadaten.de/emg/EMG_00000004 + + + + + Voltage which is utilised to create an electric field that draws particles from + the source. + + This concept is related to term `Extraction Voltage`_ of the EMglossary standard. + + .. _Extraction Voltage: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 + + + + + Electrical current which is released from the source. + + This concept is related to term `Emission Current`_ of the EMglossary standard. + + .. _Emission Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 + + + + + Electrical current which flows through the source. + + This concept is related to term `Filament Current`_ of the EMglossary standard. + + .. _Filament Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000027 + + @@ -803,6 +852,10 @@ research data management system--> A region-of-interest analyzed either during or after the session for which specific processed data are available. + + This concept is related to term `Region Of interest`_ of the EMglossary standard. + + .. _Region Of interest: https://purls.helmholtz-metadaten.de/emg/EMG_00000042 + diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/contributed_definitions/NXoptical_system_em.nxdl.xml index abd689d83f..b0546c8c77 100644 --- a/contributed_definitions/NXoptical_system_em.nxdl.xml +++ b/contributed_definitions/NXoptical_system_em.nxdl.xml @@ -30,8 +30,11 @@ NEW ISSUE: all the definitions here should better be backed up by the work of the HMC EM glossary activities--> - Citing the JEOL TEM glossary this is *an effective distance from a specimen - to a plane where an observed diffraction pattern is formed*. + Distance which is present between the specimen surface and the detector plane. + + This concept is related to term `Camera Length`_ of the EMglossary standard. + + .. _Camera Length: https://purls.helmholtz-metadaten.de/emg/EMG_00000008 @@ -48,9 +51,12 @@ work of the HMC EM glossary activities--> - Citing the JEOL TEM glossary this is the value *when a cone shaped, - convergent electron beam illuminates a specimen, the semi-angle of the cone - is termed convergence angle.* + The angle which is given by the semi-opening angle of the cone in a convergent + beam. + + This concept is related to term `Convergence Angle`_ of the EMglossary standard. + + .. _Convergence Angle: https://purls.helmholtz-metadaten.de/emg/EMG_00000010 @@ -61,32 +67,89 @@ work of the HMC EM glossary activities--> - Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is - *a distance between the specimen and the lower pole piece in SEM system*. + Distance which is determined along the optical axis within the column from (1) the + lower end of the final optical element between the source and the specimen stage; + to (2) the point where the beam is focused. + + This concept is related to term `Working Distance`_ of the EMglossary standard. + + .. _Working Distance: https://purls.helmholtz-metadaten.de/emg/EMG_00000050 - - + + + + Geometry of the cross-section formed when the primary beam shines onto the + specimen surface. + + + - Beam current as measured relevant for the illumination of the specimen. - Users should specify further details like how the beam current - was measured using the beam_current_description field. + Electrical current which arrives at the specimen. + + This concept is related to term `Probe Current`_ of the EMglossary standard. + + .. _Probe Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000041 - + + - Specify further details how the beam current was measured or estimated. + Specify further details how incipient electron or ion dose was quantified (using + beam_current, probe_current). + + + Details about an imaging setting used during acquisition to correct perspective + distortion when imaging a tilted surface or cross section. + + This concept is related to term `Tilt Correction`_ of the EMglossary standard. + + .. _Tilt Correction: https://purls.helmholtz-metadaten.de/emg/EMG_00000047 + + + + + Details about a dynamic focus correction used. + + This concept is related to term `Dynamic Focus Correction`_ of the EMglossary standard. + + .. _Dynamic Focus Correction: https://purls.helmholtz-metadaten.de/emg/EMG_00000016 + + + + + Details about a workflow used to keep the specimen in focus by automatic means. + + This concept is related to term `Dynamic Refocusing`_ of the EMglossary standard. + + .. _Dynamic Refocusing: https://purls.helmholtz-metadaten.de/emg/EMG_00000017 + + + + + Distance which lies between the principal plane of the lens and the focal point + along the optical axis. + + This concept is related to term `Focal Length`_ of the EMglossary standard. + + .. _Focal Length: https://purls.helmholtz-metadaten.de/emg/EMG_00000029 + + diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/contributed_definitions/NXscanbox_em.nxdl.xml index a389fb01cb..b36394726f 100644 --- a/contributed_definitions/NXscanbox_em.nxdl.xml +++ b/contributed_definitions/NXscanbox_em.nxdl.xml @@ -57,20 +57,23 @@ - Time period during which the beam remains at one position. + + This concept is related to term `Dwell Time`_ of the EMglossary standard. + + .. _Dwell Time: https://purls.helmholtz-metadaten.de/emg/EMG_00000015 - TODO discuss with the electron microscopists. + Time period during which the beam moves from the final position of one scan + line to the starting position of the subsequent scan line. + + This concept is related to term `Flyback Time`_ of the EMglossary standard. + + .. _Flyback Time: https://purls.helmholtz-metadaten.de/emg/EMG_00000028 diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index b71dcbe06d..77863f72d6 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -6,10 +6,9 @@ doc: | with which to normalize specific pieces of information and data collected within electron microscopy research. - NXem is designed to be used for documentation of experiments or computer simulations - of controlled electron beams which are used for studying electron-beam matter interaction - to explore physical mechanisms and phenomena, or to characterize materials with - electron microscopy. + NXem is designed to be used for documenting experiments or computer simulations in which + controlled electron beams are used for studying electron-beam matter interaction to explore + physical mechanisms and phenomena, or to characterize materials. type: group NXem(NXobject): # \@NX_class: @@ -188,10 +187,16 @@ NXem(NXobject): # name: -> short_title # user: -> not matched right now # citation: doi ->why relevant, should be solved by RDMS - doc: | + doc: + - | A description of the material characterized in the experiment. Sample and specimen are threaded as de facto synonyms. Samples can be real specimens or virtual (see method). + - | + xref: + spec: EMglossary + term: Specimen + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000046 method(NX_CHAR): doc: | A qualifier whether the sample is a real one or a @@ -349,6 +354,12 @@ NXem(NXobject): model(NX_CHAR): (NXebeam_column): electron_source(NXsource): + doc: + - | + xref: + spec: EMglossary + term: Source + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 emitter_type(NX_CHAR): probe(NX_CHAR): # voltage like all other dynamic quantities should better be placed in instances of NXevent_data_em @@ -626,7 +637,54 @@ NXem(NXobject): (NXebeam_column): operation_mode(NX_CHAR): electron_source(NXsource): + doc: + - | + xref: + spec: EMglossary + term: Source + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 voltage(NX_NUMBER): + doc: + - | + The potential difference between anode and cathode. + - | + xref: + spec: EMglossary + term: Acceleration Voltage + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000004 + extraction_voltage(NX_NUMBER): + exists: optional + doc: + - | + Voltage which is utilised to create an electric field that draws particles from the source. + - | + xref: + spec: EMglossary + term: Extraction Voltage + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 + unit: NX_VOLTAGE + emission_current(NX_NUMBER): + exists: optional + doc: + - | + Electrical current which is released from the source. + - | + xref: + spec: EMglossary + term: Emission Current + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 + unit: NX_CURRENT + filament_current(NX_NUMBER): + exists: optional + doc: + - | + Electrical current which flows through the source. + - | + xref: + spec: EMglossary + term: Filament Current + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000027 + unit: NX_CURRENT (NXibeam_column): exists: optional ion_source(NXsource): @@ -667,9 +725,15 @@ NXem(NXobject): # research data management system (NXroi): exists: [min, 0, max, infty] - doc: | + doc: + - | A region-of-interest analyzed either during or after the session for which specific processed data are available. + - | + xref: + spec: EMglossary + term: Region Of interest + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000042 # as soon as one entry is here constrained further # an RDM can be sure to find specific pieces of information in a # specific way but then every user of this application definition diff --git a/contributed_definitions/nyaml/NXem_ebsd.yaml b/contributed_definitions/nyaml/NXem_ebsd.yaml index 7811a8845d..4a34650c4b 100644 --- a/contributed_definitions/nyaml/NXem_ebsd.yaml +++ b/contributed_definitions/nyaml/NXem_ebsd.yaml @@ -1,8 +1,9 @@ category: base -doc: | +doc: +- | Base class method-specific for Electron Backscatter Diffraction (EBSD). - The general procedure of an EBSD experiment is as follows: + The general procedure of an EBSD experiment is as follows. Users load the specimen, collect first a coarse image of the surface. Next, they set an approximate value for the calibrated working distance and tilt the stage to set the desired diffraction conditions. @@ -86,6 +87,11 @@ doc: | definition contains conceptual ideas how this splitting between measurement and post-processing can be granularized also for such X-ray-based techniques, whether it be 3DXRD or HEDM. +- | + xref: + spec: EMglossary + term: Electron Backscatter Diffraction + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000019 symbols: n_op: | Number of arguments per orientation for given parameterization. diff --git a/contributed_definitions/nyaml/NXlens_em.yaml b/contributed_definitions/nyaml/NXlens_em.yaml index c8271e70dd..eedc3fd8ae 100644 --- a/contributed_definitions/nyaml/NXlens_em.yaml +++ b/contributed_definitions/nyaml/NXlens_em.yaml @@ -8,6 +8,8 @@ doc: | For details of electro-magnetic lenses in the literature see e.g. `L. Reimer `_ + +# has_part pole_piece https://purls.helmholtz-metadaten.de/emg/EMG_00000039 type: group # more consolidation to harvest from a generic component base class # with other research fields (MPES, XPS, OPT) could be useful diff --git a/contributed_definitions/nyaml/NXoptical_system_em.yaml b/contributed_definitions/nyaml/NXoptical_system_em.yaml index f98fbaa4b7..c0d912b7b7 100644 --- a/contributed_definitions/nyaml/NXoptical_system_em.yaml +++ b/contributed_definitions/nyaml/NXoptical_system_em.yaml @@ -7,9 +7,14 @@ NXoptical_system_em(NXobject): # NEW ISSUE: all the definitions here should better be backed up by the # work of the HMC EM glossary activities camera_length(NX_NUMBER): - doc: | - Citing the JEOL TEM glossary this is *an effective distance from a specimen - to a plane where an observed diffraction pattern is formed*. + doc: + - | + Distance which is present between the specimen surface and the detector plane. + - | + xref: + spec: EMglossary + term: Camera Length + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000008 unit: NX_LENGTH magnification(NX_NUMBER): # R+ otherwise it is demagnification doc: | @@ -22,10 +27,14 @@ NXoptical_system_em(NXobject): The defocus aberration constant (oftentimes referred to as C_1_0). See respective details in :ref:`NXaberration` class instances. semi_convergence_angle(NX_NUMBER): - doc: | - Citing the JEOL TEM glossary this is the value *when a cone shaped, - convergent electron beam illuminates a specimen, the semi-angle of the cone - is termed convergence angle.* + doc: + - | + The angle which is given by the semi-opening angle of the cone in a convergent beam. + - | + xref: + spec: EMglossary + term: Convergence Angle + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000010 unit: NX_ANGLE field_of_view(NX_NUMBER): doc: | @@ -33,26 +42,82 @@ NXoptical_system_em(NXobject): magnification and other settings of the instrument. unit: NX_LENGTH working_distance(NX_NUMBER): - doc: | - Citing `Globalsino `_ this is - *a distance between the specimen and the lower pole piece in SEM system*. + doc: + - | + Distance which is determined along the optical axis within the column from (1) the + lower end of the final optical element between the source and the specimen stage; + to (2) the point where the beam is focused. + - | + xref: + spec: EMglossary + term: Working Distance + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000050 unit: NX_LENGTH - beam_current(NX_NUMBER): - # see AXON Dose monitoring paper doi:10.1017/S1551929522000840 - # this is the nominal dose rate e-/(angstrom^2*s) + # probe_current and beam_current are related but not the same + # the probe_current is equal to the beam_current only right at the surface where the beam enters the specimen + # inserting a Faraday cup in the beam path measures the beam_current (along a specific location on the beam + # before it enters the specimen but it is often assumed for the practical reason that measuring right at the surface + # that the beam current is the probe current. + probe(NXcg_ellipsoid_set): doc: | - Beam current as measured relevant for the illumination of the specimen. - Users should specify further details like how the beam current - was measured using the beam_current_description field. + Geometry of the cross-section formed when the primary beam shines onto the specimen surface. + probe_current(NX_NUMBER): + doc: + - | + Electrical current which arrives at the specimen. + - | + xref: + spec: EMglossary + term: Probe Current + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000041 unit: NX_CURRENT # replace with a dedicated base class to describe the dose rate, accumulated dose, dose rate history # based on the AXON Dose monitoring suggestions, for this one could also have an NXdose_monitoring base class # alternatively as that dose monitoring instrument as it is also described in the paper # is a modified Faraday cup sensor one could also wrap that detector in this base dose monitoring base class - beam_current_description(NX_CHAR): + dose_management(NX_CHAR): + # see AXON Dose monitoring paper doi:10.1017/S1551929522000840 + # this is the nominal dose rate e-/(angstrom^2*s) doc: | - Specify further details how the beam current was measured or estimated. + Specify further details how incipient electron or ion dose was quantified (using beam_current, probe_current). # NEW ISSUE: the KIT/SCC propose: # adding of the image_mode or field mode # imageMode: enum: [normal_image, sad, eds, nbd, cbed] # fieldMode: enum: [dark_field, bright_field] + tilt_correction(NX_BOOLEAN): + doc: + - | + Details about an imaging setting used during acquisition to correct perspective distortion when imaging a tilted surface or cross section. + - | + xref: + spec: EMglossary + term: Tilt Correction + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000047 + dynamic_focus_correction(NX_BOOLEAN): + doc: + - | + Details about a dynamic focus correction used. + - | + xref: + spec: EMglossary + term: Dynamic Focus Correction + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000016 + dynamic_refocusing(NX_CHAR): + doc: + - | + Details about a workflow used to keep the specimen in focus by automatic means. + - | + xref: + spec: EMglossary + term: Dynamic Refocusing + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000017 + focal_length(NX_NUMBER): + doc: + - | + Distance which lies between the principal plane of the lens and the focal point along the optical axis. + - | + xref: + spec: EMglossary + term: Focal Length + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000029 + unit: NX_LENGTH diff --git a/contributed_definitions/nyaml/NXscanbox_em.yaml b/contributed_definitions/nyaml/NXscanbox_em.yaml index c8ab212630..18569230ea 100644 --- a/contributed_definitions/nyaml/NXscanbox_em.yaml +++ b/contributed_definitions/nyaml/NXscanbox_em.yaml @@ -31,16 +31,25 @@ NXscanbox_em(NXcomponent_em): # await discussion on base class NXscan_control unit: NX_ANY # descriptors relevant from economic usage and dose management perspective dwell_time(NX_NUMBER): - doc: | + doc: + - | Time period during which the beam remains at one position. - # xref: - # spec: EMglossary - # term: Dwell time - # url: https://em-glossary.vercel.app/term/em-dwell-time + - | + xref: + spec: EMglossary + term: Dwell Time + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000015 unit: NX_TIME flyback_time(NX_NUMBER): - doc: | - TODO discuss with the electron microscopists. + doc: + - | + Time period during which the beam moves from the final position of one scan + line to the starting position of the subsequent scan line. + - | + xref: + spec: EMglossary + term: Flyback Time + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000028 unit: NX_TIME line_time(NX_NUMBER): doc: | diff --git a/dev_tools/docs/anchor_list.py b/dev_tools/docs/anchor_list.py index df668ead01..a84ddd2909 100644 --- a/dev_tools/docs/anchor_list.py +++ b/dev_tools/docs/anchor_list.py @@ -114,7 +114,7 @@ def write(self): return contents = dict( _metadata=dict( - datetime=datetime.datetime.utcnow().isoformat(), + datetime=datetime.datetime.now(datetime.UTC).isoformat(), title="NeXus NXDL vocabulary.", subtitle="Anchors for all NeXus fields, groups, " "attributes, and links.", From 427f74480a9914b339399c4267d59614edf05f02 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 26 Jun 2024 15:28:06 +0200 Subject: [PATCH 0727/1012] Added connection between new base classes and NXem appdef --- contributed_definitions/NXem.nxdl.xml | 318 +++++++++++-------- contributed_definitions/nyaml/NXem.yaml | 402 +++++++++++++++--------- 2 files changed, 435 insertions(+), 285 deletions(-) diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 5e6233847c..499363e315 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -31,7 +31,7 @@ NXem is designed to be used for documenting experiments or computer simulations in which controlled electron beams are used for studying electron-beam matter interaction to explore - physical mechanisms and phenomena, or to characterize materials. + physical mechanisms and phenomena, or to characterize materials with an electron microscope. +\@default(NX_CHAR): +starting to reorganize the docstrings, as a list of blocks: +-| req: first part, concept definition, human-readable but such that one could take as is to define an concept in OWL +-| opt: second part, comment, i.e. information that in an ideal world would be ideal if represented strongly semantic + but for practical purposes currently is interpretable only by human to provide them further contextualization +-| recommended: xref part (ideally also as a list of triple (spec, term, url to uri)--> @@ -48,19 +53,14 @@ - The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_ or its plugins) which was used to generate this NeXus file instance. - - + - A collection of all programs and libraries which are considered relevant + A collection of all programs and libraries that are considered as relevant to understand with which software tools this NeXus file instance was generated. Ideally, to enable a binary recreation from the input data. @@ -80,14 +80,13 @@ where scientists just store conventions without a default plot--> - Ideally, a (globally) unique persistent identifier for referring to this experiment. An experiment should be understood in that this can be an experiment in reality or a computer simulation because also the latter is an experiment - (see the Cambridge Dictionary experiment: *a test done in order to find out + (see the Cambridge Dictionary experiment *a test done in order to find out something, eg if an idea is correct*). The identifier is usually issued by the facility, laboratory, or the principle investigator. @@ -99,8 +98,7 @@ where scientists just store conventions without a default plot--> - Either an identifier or an alias that is human-friendly so that scientists find - that experiment again. + Alias which scientists can easier identify this experiment by. @@ -109,9 +107,7 @@ where scientists just store conventions without a default plot--> Users are strongly advised to parameterize the description of their experiment by using respective groups and fields and base classes instead of writing prose - into this field. - - The reason is that such free-text field is difficult to machine-interpret. + into the field. The reason is that such free-text field is difficult to machine-interpret. The motivation behind keeping this field for now is to learn in how far the current base classes need extension based on user feedback. @@ -122,7 +118,7 @@ where scientists just store conventions without a default plot--> 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. + duration is not relevant use this start_time field. Often though it is useful to specify a time interval via setting both a start_time and an end_time because this enables software tools and users to collect a @@ -141,17 +137,21 @@ where scientists just store conventions without a default plot--> ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. See docstring of the start_time field - to see how the start_time and end_time should be used together. + the microscope session ended. + + See docstring of the start_time field to see how to use the + start_time and end_time together. - Possibility to store a collection of serialized resources that are associated - with the experiment. An example how to use this set could be to document - from which files, which have been e.g. generated by software of technology - partners, the information in an instance of NXem was filled with. + Possibility to store a collection of serialized resources associated with the + experiment. + + An example how to use this set could be to document from which files, which have been + e.g. generated by software of technology partners, the information in an instance of + NXem was filled with during parsing or transcoding between different formats. If resources from technology partners would also be documented with semantic technology there would not even be a necessity to copy over specific information @@ -159,12 +159,11 @@ where scientists just store conventions without a default plot--> algorithm(s) whereby a specific piece of information that is related to an experiment or simulation is read directly from the respective file of the technology partner. - The reason why currently this works convincingly in hardly any research data - management system (RDMS) is the strong heterogeneity of the information contained - in such files and the fact that often context and documentation, specifically - rich semantic documentation, and contextualization is missing. + The reason why currently this works convincingly in hardly any research data management system + (RDMS) is the strong heterogeneity of the information contained in such files and the fact + that often context and documentation, specifically rich and strongly expressive semantic + documentation or contextualization is underdeveloped. - @@ -172,21 +171,20 @@ where scientists just store conventions without a default plot--> - Contact information and eventually details of at least one person - who performed or was involved in the microscope session or simulation run. - This can be the principle investigator who performed this experiment or the - student who performed the simulation. Adding multiple users if relevant - is recommended. + Information about persons who performed or were involved in the microscope + session or simulation run. + + This can be the principle investigator who performed this experiment or the student who performed simulations. + Adding multiple users if relevant is recommended. - Given (first) name and surname of the user. + Given (first) name and surname. - Name of the affiliation of the user at the point in time - when the experiment was performed. + Name of the affiliation at the point in time when the experiment was performed. @@ -196,27 +194,28 @@ where scientists just store conventions without a default plot--> - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. + Email address at the point in time when the experiment was performed. + + Writing the most permanently used email is recommended. - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. + Telephone number at the point in time when the experiment was performed. - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope, student, postdoc, principle investigator, or guest - are common examples. + User role at the point in time when the experiment was performed. + + Examples are technician operating the microscope, student, postdoc, + principle investigator, or guest. - Service as another mean of identification of a user other than by its name. + Identifier offered by a service to report the user other than by using its name. + Examples could be an ORCID or social media account of the user. @@ -225,18 +224,9 @@ where scientists just store conventions without a default plot--> - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - Samples can be real specimens or virtual (see method). + A physical entity which contains material intended to be investigated. + Sample and specimen are threaded as de facto synonyms. Samples can be real or virtual ones. This concept is related to term `Specimen`_ of the EMglossary standard. @@ -244,8 +234,7 @@ citation: doi ->why relevant, should be solved by RDMS - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) + Qualifier whether the sample is a real or a virtual one. @@ -366,9 +355,9 @@ are the ibeam description capabilities not sufficient enough?--> Set to hold different coordinate systems conventions. - Inspect the description of the :ref:`NXcoordinate_system_set` - and :ref:`NXcoordinate_system` base classes how to define - coordinate systems in NeXus. + + Inspect the description of the :ref:`NXcoordinate_system_set` and :ref:`NXcoordinate_system` base classes + how to define coordinate systems in NeXus. @@ -380,20 +369,18 @@ are the ibeam description capabilities not sufficient enough?--> - + + + + + + - + Details about the control program used for operating the microscope. @@ -401,18 +388,7 @@ advantage--> - - - - - - - - - - - - + This concept is related to term `Source`_ of the EMglossary standard. @@ -421,20 +397,105 @@ advantage--> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - @@ -757,7 +818,7 @@ the fields they can be used--> - + @@ -803,19 +864,46 @@ the fields they can be used--> + + + + + + + + + + + + + + + + + + + + - + + + + + + + - + - - + @@ -835,14 +923,13 @@ the fields they can be used--> + + + - - + diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index 77863f72d6..db3e87d217 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -8,7 +8,7 @@ doc: | NXem is designed to be used for documenting experiments or computer simulations in which controlled electron beams are used for studying electron-beam matter interaction to explore - physical mechanisms and phenomena, or to characterize materials. + physical mechanisms and phenomena, or to characterize materials with an electron microscope. type: group NXem(NXobject): # \@NX_class: @@ -19,28 +19,29 @@ NXem(NXobject): # \@HDF5_Version(NX_CHAR): # \@h5py_version(NX_CHAR): # \@default(NX_CHAR): + # starting to reorganize the docstrings, as a list of blocks: + # -| req: first part, concept definition, human-readable but such that one could take as is to define an concept in OWL + # -| opt: second part, comment, i.e. information that in an ideal world would be ideal if represented strongly semantic + # but for practical purposes currently is interpretable only by human to provide them further contextualization + # -| recommended: xref part (ideally also as a list of triple (spec, term, url to uri) (NXentry): # means ENTRY(NXentry) exists: [min, 1, max, infty] definition(NX_CHAR): \@version(NX_CHAR): exists: optional enumeration: [NXem] - # each NeXus file instance should have a default plot - # however as there are cases when this cannot be assured we cannot - # make the default required, one example is e.g. a NeXus instance - # where scientists just store conventions without a default plot profiling(NXcs_profiling): exists: optional doc: | The configuration of the I/O writer software (e.g. `pynxtools `_ or its plugins) which was used to generate this NeXus file instance. - # command_line_call(NX_CHAR): - (NXprogram): # understood by default as PROGRAM(NXprogram), i.e. program1, program2, ... - doc: | - A collection of all programs and libraries which are considered relevant + programID(NXprogram): # program1, program2 + doc: + - | + A collection of all programs and libraries that are considered as relevant to understand with which software tools this NeXus file instance was generated. Ideally, to enable a binary recreation from the input data. - + - | Examples include the name and version of the libraries used to write the instance. Ideally, the software which writes these NXprogram instances also includes the version of the set of NeXus classes i.e. the specific @@ -54,45 +55,46 @@ NXem(NXobject): exists: [min, 0, max, infty] program(NX_CHAR): \@version(NX_CHAR): - # \@url: experiment_identifier(NXidentifier): exists: recommended - doc: | + doc: + - | Ideally, a (globally) unique persistent identifier for referring to this experiment. An experiment should be understood in that this can be an experiment in reality or a computer simulation because also the latter is an experiment - (see the Cambridge Dictionary experiment: *a test done in order to find out + (see the Cambridge Dictionary experiment *a test done in order to find out something, eg if an idea is correct*). - + - | The identifier is usually issued by the facility, laboratory, or the principle investigator. The identifier enables to link experiments/simulations to e.g. proposals. service(NX_CHAR): identifier(NX_CHAR): is_persistent(NX_BOOLEAN): experiment_alias(NX_CHAR): - doc: | - Either an identifier or an alias that is human-friendly so that scientists find that experiment again. + doc: + - | + Alias which scientists can easier identify this experiment by. experiment_description(NX_CHAR): exists: optional - doc: | + doc: + - | Free-text description about the experiment. - + - | Users are strongly advised to parameterize the description of their experiment by using respective groups and fields and base classes instead of writing prose - into this field. - - The reason is that such free-text field is difficult to machine-interpret. + into the field. The reason is that such free-text field is difficult to machine-interpret. The motivation behind keeping this field for now is to learn in how far the current base classes need extension based on user feedback. start_time(NX_DATE_TIME): - doc: | + 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. - + duration is not relevant use this start_time field. + - | Often though it is useful to specify a time interval via setting both a start_time and an end_time because this enables software tools and users to collect a more detailed bookkeeping of the experiment. @@ -107,19 +109,24 @@ NXem(NXobject): in :ref:`NXevent_data_em` instances. end_time(NX_DATE_TIME): exists: recommended - doc: | + doc: + - | ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. See docstring of the start_time field - to see how the start_time and end_time should be used together. + the microscope session ended. + - | + See docstring of the start_time field to see how to use the + start_time and end_time together. (NXcite): exists: [min, 0, max, infty] (NXserialized): exists: [min, 0, max, infty] - doc: | - Possibility to store a collection of serialized resources that are associated - with the experiment. An example how to use this set could be to document - from which files, which have been e.g. generated by software of technology - partners, the information in an instance of NXem was filled with. + doc: + - | + Possibility to store a collection of serialized resources associated with the experiment. + - | + An example how to use this set could be to document from which files, which have been + e.g. generated by software of technology partners, the information in an instance of + NXem was filled with during parsing or transcoding between different formats. If resources from technology partners would also be documented with semantic technology there would not even be a necessity to copy over specific information @@ -127,80 +134,79 @@ NXem(NXobject): algorithm(s) whereby a specific piece of information that is related to an experiment or simulation is read directly from the respective file of the technology partner. - The reason why currently this works convincingly in hardly any research data - management system (RDMS) is the strong heterogeneity of the information contained - in such files and the fact that often context and documentation, specifically - rich semantic documentation, and contextualization is missing. - # using NXserialized here instead of NXnote as the former is more specific + The reason why currently this works convincingly in hardly any research data management system + (RDMS) is the strong heterogeneity of the information contained in such files and the fact + that often context and documentation, specifically rich and strongly expressive semantic + documentation or contextualization is underdeveloped. type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): (NXuser): exists: [min, 0, max, infty] - doc: | - Contact information and eventually details of at least one person - who performed or was involved in the microscope session or simulation run. - This can be the principle investigator who performed this experiment or the - student who performed the simulation. Adding multiple users if relevant - is recommended. + doc: + - | + Information about persons who performed or were involved in the microscope session or simulation run. + - | + This can be the principle investigator who performed this experiment or the student who performed simulations. + Adding multiple users if relevant is recommended. name(NX_CHAR): exists: optional - doc: | - Given (first) name and surname of the user. + doc: + - | + Given (first) name and surname. affiliation(NX_CHAR): exists: optional - doc: | - Name of the affiliation of the user at the point in time - when the experiment was performed. + doc: + - | + Name of the affiliation at the point in time when the experiment was performed. address(NX_CHAR): exists: optional - doc: | + doc: + - | Postal address of the affiliation. email(NX_CHAR): exists: optional - doc: | - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. + doc: + - | + Email address at the point in time when the experiment was performed. + - | + Writing the most permanently used email is recommended. telephone_number(NX_CHAR): - doc: | - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. + doc: + - | + Telephone number at the point in time when the experiment was performed. role(NX_CHAR): - doc: | - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope, student, postdoc, principle investigator, or guest - are common examples. + doc: + - | + User role at the point in time when the experiment was performed. + - | + Examples are technician operating the microscope, student, postdoc, + principle investigator, or guest. identifier(NXidentifier): exists: recommended - doc: | - Service as another mean of identification of a user other than by its name. + doc: + - | + Identifier offered by a service to report the user other than by using its name. + - | Examples could be an ORCID or social media account of the user. service(NX_CHAR): identifier(NX_CHAR): is_persistent(NX_BOOLEAN): sample(NXsample): - # NEW ISSUE: inject the conclusion from the discussion with Andrea - # according to SAMPLE.yaml 0f8df14 2022/06/15 - # ID: -> maps to name - # name: -> short_title - # user: -> not matched right now - # citation: doi ->why relevant, should be solved by RDMS doc: - | - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - Samples can be real specimens or virtual (see method). + A physical entity which contains material intended to be investigated. + Sample and specimen are threaded as de facto synonyms. Samples can be real or virtual ones. - | xref: spec: EMglossary term: Specimen url: https://purls.helmholtz-metadaten.de/emg/EMG_00000046 method(NX_CHAR): - doc: | - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) + doc: + - | + Qualifier whether the sample is a real or a virtual one. enumeration: [experiment, simulation] identifier(NXidentifier): exists: recommended @@ -306,11 +312,12 @@ NXem(NXobject): should provide this contextualization. coordinate_system_set(NXcoordinate_system_set): exists: [min, 1, max, 1] - doc: | + doc: + - | Set to hold different coordinate systems conventions. - Inspect the description of the :ref:`NXcoordinate_system_set` - and :ref:`NXcoordinate_system` base classes how to define - coordinate systems in NeXus. + - | + Inspect the description of the :ref:`NXcoordinate_system_set` and :ref:`NXcoordinate_system` base classes + how to define coordinate systems in NeXus. (NXcoordinate_system): exists: [min, 1, max, infty] origin(NX_CHAR): @@ -320,39 +327,28 @@ NXem(NXobject): x_direction(NX_CHAR): y_direction(NX_CHAR): z_direction(NX_CHAR): - # the description can be so lean because we do not need - # to overwrite here s.th. as everything is defined already - # we just say hey we need the above-mentioned fields - # in the way they are defined in the respective composed base classes - # and they have to be defined - # we also should not need to specify the value type like R, NX_POSINT - # because anyway within a group all field names have to be unique - # so there must not be any name conflict and this we can take to our - # advantage + # the description can be so lean because we do not need to overwrite here s.th. as everything is defined already + # we just say we compose using the base class NXcoordinate_system measurement(NXem_msr): exists: optional em_lab(NXinstrument): instrument_name(NX_CHAR): exists: recommended + fabrication(NXfabrication): + vendor(NX_CHAR): + model(NX_CHAR): + identifier(NX_CHAR): + exists: recommended location(NX_CHAR): exists: recommended - control_program(NXprogram): - exists: recommended - doc: | + control_programID(NXprogram): + exists: [min, 1, max, infty] + doc: + - | Details about the control program used for operating the microscope. program(NX_CHAR): \@version(NX_CHAR): - (NXfabrication): - vendor(NX_CHAR): - model(NX_CHAR): - identifier(NX_CHAR): - exists: recommended - (NXdetector): - exists: [min, 0, max, infty] - (NXfabrication): - vendor(NX_CHAR): - model(NX_CHAR): - (NXebeam_column): + ebeam_column(NXebeam_column): electron_source(NXsource): doc: - | @@ -363,15 +359,110 @@ NXem(NXobject): emitter_type(NX_CHAR): probe(NX_CHAR): # voltage like all other dynamic quantities should better be placed in instances of NXevent_data_em - (NXibeam_column): + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + identifier(NX_CHAR): + exists: recommended + # fabrication is an example which shows when one needs to specify in the appdef if some of the + # inherited objects from NXebeam_column have to be specified that is when one wishes to document + # e.g. a combination of cardinality constraints or concept symbol constraints + # i.e. use NXfabrication from NXsource but demand it to be labelled with the symbol fabrication + # likewise if you provide fabrication details you need to provide vendor and model but not necessarily identifier + lens_emID(NXlens_em): + exists: [min, 0, max, infty] + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + identifier(NX_CHAR): + exists: recommended + aperture_emID(NXaperture_em): + exists: [min, 0, max, infty] + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + identifier(NX_CHAR): + exists: recommended + monochromator_emID(NXmonochromator_em): + exists: [min, 0, max, infty] + applied(NX_BOOLEAN): + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + identifier(NX_CHAR): + exists: recommended + type(NX_CHAR): + dispersion(NX_NUMBER): + exists: recommended + corrector_cs(NXcorrector_cs): + exists: [min, 0, max, infty] + applied(NX_BOOLEAN): + corrector_ax(NXcorrector_ax): + exists: [min, 0, max, infty] + applied(NX_BOOLEAN): + # biprism_em + # phase_plate_em + ibeam_column(NXibeam_column): exists: [min, 0, max, 1] # there are tri-beam SEMs but they typically use a laser for which we should have an own base class ion_source(NXsource): probe(NXion): - # voltage(NX_NUMBER): also this better in instances of NXevent_data_em - # does not have to be written out unless that field should be required! - # like all other sub-graphs in the NXibeam_column base class and all - # the fields they can be used + lens_emID(NXlens_em): + exists: [min, 0, max, infty] + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + identifier(NX_CHAR): + exists: recommended + aperture_emID(NXaperture_em): + exists: [min, 0, max, infty] + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + identifier(NX_CHAR): + exists: recommended + monochromator_emID(NXmonochromator_em): + exists: [min, 0, max, infty] + applied(NX_BOOLEAN): + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + identifier(NX_CHAR): + exists: recommended + type(NX_CHAR): + dispersion(NX_NUMBER): + exists: recommended + # corrector_ax(NXcorrector_ax): + # exists: [min, 0, max, infty] + # applied(NX_BOOLEAN): + detectorID(NXdetector): + exists: [min, 0, max, infty] + fabrication(NXfabrication): + vendor(NX_CHAR): + model(NX_CHAR): + scan_controller(NXscanbox_em): + exists: optional + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + identifier(NX_CHAR): + exists: recommended + (NXstage_lab): + exists: [min, 0, max, infty] + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + identifier(NX_CHAR): + exists: recommended event_data_em_set(NXevent_data_em_set): exists: [min, 0, max, 1] # an instance must not have an NXevent_data_em_set but if it has one it must not be more than 1 ! @@ -634,7 +725,7 @@ NXem(NXobject): # collection(NXdata): em_lab(NXinstrument): exists: recommended - (NXebeam_column): + ebeam_column(NXebeam_column): operation_mode(NX_CHAR): electron_source(NXsource): doc: @@ -685,38 +776,72 @@ NXem(NXobject): term: Filament Current url: https://purls.helmholtz-metadaten.de/emg/EMG_00000027 unit: NX_CURRENT - (NXibeam_column): - exists: optional + lens_emID(NXlens_em): + exists: [min, 0, max, infty] + aperture_emID(NXaperture_em): + exists: [min, 0, max, infty] + monochromator_emID(NXmonochromator_em): + exists: [min, 0, max, infty] + applied(NX_BOOLEAN): + corrector_cs(NXcorrector_cs): + exists: [min, 0, max, infty] + applied(NX_BOOLEAN): + ZEMLIN_TABLEAU(NXprocess): + exists: recommended + (NXprocess): + ceos(NXaberration_model_ceos): + exists: optional + nion(NXaberration_model_nion): + exists: optional + # we could write down how to store the aberrations + # basically optional use of NXaberration therein at least some value required + corrector_ax(NXcorrector_ax): + exists: [min, 0, max, infty] + applied(NX_BOOLEAN): + value_x(NX_NUMBER): + value_y(NX_NUMBER): + # biprism_em + # phase_plate_em + ibeam_column(NXibeam_column): + exists: [min, 0, max, 1] ion_source(NXsource): probe(NXion): voltage(NX_NUMBER): - (NXscanbox_em): + lens_emID(NXlens_em): + exists: [min, 0, max, infty] + aperture_emID(NXaperture_em): + exists: [min, 0, max, infty] + monochromator_emID(NXmonochromator_em): + exists: [min, 0, max, infty] + applied(NX_BOOLEAN): + scan_controller(NXscanbox_em): exists: optional scan_schema(NX_CHAR): dwell_time(NX_NUMBER): - (NXstage_lab): - exists: optional - (NXdetector): - exists: optional + detectorID(NXdetector): + exists: [min, 0, max, infty] mode(NX_CHAR): heater(NXobject): # (NXactuator): exists: optional current(NX_NUMBER): - doc: | + doc: + - | Nominal current of the heater. unit: NX_CURRENT voltage(NX_NUMBER): - doc: | + doc: + - | Nominal voltage of the heater. unit: NX_VOLTAGE power(NX_NUMBER): - doc: | + doc: + - | Nominal power of the heater. unit: NX_POWER - # why at all do we need to add here (NXinstrument) ? - # nyaml2nxdl could query the NXem_msr base class definition - # and check if an identifier named em_lab exists in this case - # it assumes it is em_lab(NXinstrument) and continues. + (NXstage_lab): + exists: [min, 0, max, infty] + design(NX_CHAR): + exists: recommended simulation(NXem_sim): exists: optional # remains to be discussed based on examples @@ -761,36 +886,5 @@ NXem(NXobject): exists: optional # remains to be discussed based on examples -# finally an example how to map e.g. a simple flat schema to NXem: -# https://www.zenodo.org/record/6513745, source path mapped on (->) target path -# for all source paths /SEM/ is the src path prefix -# for all target paths /entry1/ is the trg path prefix -# ID -> experiment_identifier -# External/alias ID -> none -# User -> map on NXuser instances -# Date -> use start_time and end_time respectively -# Affiliation -> map on NXuser instances -# DOIs -> none, map on NXcite instances -# Temperature (of what?) -> be more specific and add as property of group of relevance -# Relative humidity (of what? likely lab like temperature) -> NXsample -# Environmental gas -> NXsample -# Operator -> map on NXuser with specific role -# Instrument ID -> map on best matching field from NXfabrication in em_lab -# Sample ID -> NXsample/identifier -# Parent sample ID -> NXsample/sample_history -# Any dataset to be linked with this experiment (too vague for the I in FAIR) -> none -# Environmental protection during sample processing -> NXsample -# Pre-treatment -> own appdef and connect to NXsample/sample_history -# Measurement position (the example is totally unclear) -> NXstage_lab, coordinate system etc. -# Detector IDs -> NXdetector/identifier -# Accelerating voltage -> electron_source/voltage -# Current -> much more possibilities electron_source and NXoptical_system_em -# Magnification -> use NXoptical_system_em -# Image width -> implicit in roi/NXdata instances -# Image size -> see image width -# Acquisition mode (too vague) -> map on more expressive fields of NXem -# Storage tilt (what is this) for tilt see NXstage_lab -# Measurement date (how is it different from Date? -# Comments -> any of the description fields, in both cases not fair -# the respective TEM group has pixel coordinates, which is all much cleaner -# described using NXem_conventions, NXcoordinate_system, etc... \ No newline at end of file +# see an example how to map e.g. the following flat schema https://www.zenodo.org/record/6513745 to NXem +# in https://github.com/FAIRmat-NFDI/nexus_definitions/commit/0b928c4352bc5636f673b5fb25ce990f1af8a099 From 2731f35a70e9ee32803560d6ec9f062712e2287b Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 26 Jun 2024 15:49:22 +0200 Subject: [PATCH 0728/1012] Hooked in description of new base classes in manual, NXammeter new base class --- contributed_definitions/NXammeter.nxdl.xml | 35 ++++++++ contributed_definitions/nyaml/NXammeter.yaml | 11 +++ .../contributed_definitions/em-structure.rst | 81 +++++++++++-------- 3 files changed, 93 insertions(+), 34 deletions(-) create mode 100644 contributed_definitions/NXammeter.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXammeter.yaml diff --git a/contributed_definitions/NXammeter.nxdl.xml b/contributed_definitions/NXammeter.nxdl.xml new file mode 100644 index 0000000000..1adee6e060 --- /dev/null +++ b/contributed_definitions/NXammeter.nxdl.xml @@ -0,0 +1,35 @@ + + + + + + Base class for an ampere meter. + + + + + Current measured. + + + + diff --git a/contributed_definitions/nyaml/NXammeter.yaml b/contributed_definitions/nyaml/NXammeter.yaml new file mode 100644 index 0000000000..21353cf77a --- /dev/null +++ b/contributed_definitions/nyaml/NXammeter.yaml @@ -0,0 +1,11 @@ +category: base +doc: | + Base class for an ampere meter. +type: group +NXammeter(NXobject): + # user perspective + current(NX_NUMBER): + doc: | + Current measured. + unit: NX_CURRENT + (NXfabrication): \ No newline at end of file diff --git a/manual/source/classes/contributed_definitions/em-structure.rst b/manual/source/classes/contributed_definitions/em-structure.rst index 86647eccd9..dbf3a05f4e 100644 --- a/manual/source/classes/contributed_definitions/em-structure.rst +++ b/manual/source/classes/contributed_definitions/em-structure.rst @@ -57,35 +57,72 @@ The following base classes are proposed to support modularizing the storage of p documented especially when one does not store all relevant information using NeXus but one would like to refer to a specific other resource where these pieces of information are stored. - :ref:`NXaberration_model`, :ref:`NXaberration_model_ceos`, :ref:`NXaberration_model_nion`, :ref:`NXaberration`, :ref:`NXcorrector_cs`: - Base classes to describe procedures and values for the calibration of aberrations based on - conventions of different companies active in the field of aberration correction. + :ref:`NXebeam_column`: + A base class serving the possibility to group the components relevant for generating + and shaping the electron beam. + + :ref:`NXibeam_column`: + A base class serving the possibility to group the components relevant for generating + and shaping an ion beam of an instrument to offer focused-ion beam (milling) capabilities. :ref:`NXcomponent_em`: A base class to describe a hardware component for e.g. building a microscope. + :ref:`NXlens_em`: + A base class to detail an electro-magnetic lens. In practice, an electron microscope has many such lenses. It is possible to specify as many lenses as necessary to represent eventually each single lens of the microscope and thus describe how the lenses are affecting the electron beam. This can offer opportunities for developers of software tools which strive to model the instrument e.g. to create digital twins of the instrument. We understand there is still a way to go with this to arrive there though. Consequently, we suggest to focus first on which details should be collected for a lens as a component so that developers of application definitions can take immediate advantage of this work. + :ref:`NXaperture_em`: A base class to describe an aperture. + :ref:`NXdeflector`: + A base class to describe a component to deflect a beam of charged particles. + :ref:`NXchamber`: A base class to describe the chamber as a part of the microscope or storage unit for transferring specimens in between or within an instrument. + :ref:`NXpump`: + A base class to describe details about pump(s) as components of an electron microscope. + + :ref:`NXfabrication`: + A base class to bundle manufacturer/technology-partner-specific details about a component or device of an instrument. + :ref:`NXcoordinate_system_set`, :ref:`NXcoordinate_system`, :ref:`NXtransformations`: Base classes to describe different coordinate systems used and/or to be harmonized or transformed into one another and respective transformations. :ref:`NXcorrector_cs`: A base class to describe details about corrective lens or compound lens devices - which reduce the aberration of an electron beam. + which reduce the (spherical) aberrations of an electron beam. + + :ref:`NXaberration_model`, :ref:`NXaberration_model_ceos`, :ref:`NXaberration_model_nion`, :ref:`NXaberration`, :ref:`NXcorrector_cs`, :ref:`NXcorrector_ax`: + Base classes to describe procedures and values for the calibration of aberrations based on + conventions of different companies active in the field of aberration correction. - :ref:`NXdeflector`: - A base class to describe a component to deflect a beam of charged particles. + :ref:`NXcorrector_ax`: + A base class to describe details about corrective lens or compound lens devices + which reduce the axial astigmatism aberrations of an electron beam. + + :ref:`NXmonochromator_em`: + A base class to describe details about an energy filtering device. + + :ref:`NXphase_plate_em`, :ref:`NXbiprism_em`, :ref:`NXammeter`: + Base classes to group pieces of information about devices that are specific additions + to an electron microscope to perform special methods, like exploring quantum mechanics + or modulating the phase or an electron beam, perform electron holography, or measuring + EBIC current. + + :ref:`NXscanbox_em`: + A base class to represent the component of an electron microscope which realizes a controlled deflection + (and eventually shift, blanking, and/or descanning) of the electron beam to illuminate the specimen in a controlled manner + This base class can be used to document the scan pattern. The base class focuses mostly on the concept idea that there + is a component in a microscope which controls eventually multiple other components such as beam deflectors to achieve deflection + and thus a controlled scanning of the beam over the sample/specimen surface. + + :ref:`NXstage_lab`: + A base class to describe the stage/specimen holder which offers place for the documentation of the small-scale laboratory functionalities + which modern stages of electron microscopes typically offer. - :ref:`NXebeam_column`: - A base class serving the possibility to group the components relevant for generating - and shaping the electron beam. - :ref:`NXevent_data_em`: A base class representing a container to hold time-stamped and microscope-state-annotated data during a session at an electron microscope. @@ -93,10 +130,6 @@ The following base classes are proposed to support modularizing the storage of p :ref:`NXevent_data_em_set`: A base class to group all :ref:`NXevent_data_em` instances. - :ref:`NXibeam_column`: - A base class serving the possibility to group the components relevant for generating - and shaping an ion beam of an instrument to offer focused-ion beam (milling) capabilities. - :ref:`NXimage_set`, :ref:`NXimage_r_set`, :ref:`NXimage_c_set`, :ref:`NXimage_r_set_diff`: Base classes for storing acquisition details for individual images or stacks of images. @@ -106,12 +139,6 @@ The following base classes are proposed to support modularizing the storage of p :ref:`NXion`: A base class to describe molecular ions with an adjustable number of atoms/isotopes building each ion. Right now the maximum number of atoms supported building a molecular ion is 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with which all possible isotopes can be described. - :ref:`NXlens_em`: - A base class to detail an electro-magnetic lens. In practice, an electron microscope has many such lenses. It is possible to specify as many lenses as necessary to represent eventually each single lens of the microscope and thus describe how the lenses are affecting the electron beam. This can offer opportunities for developers of software tools which strive to model the instrument e.g. to create digital twins of the instrument. We understand there is still a way to go with this to arrive there though. Consequently, we suggest to focus first on which details should be collected for a lens as a component so that developers of application definitions can take immediate advantage of this work. - - :ref:`NXfabrication`: - A base class to bundle manufacturer/technology-partner-specific details about a component or device of an instrument. - :ref:`NXoptical_system_em`: A base class to store for now qualitative and quantitative values of frequent interest which are affected by the interplay of the components and state of an electron microscope. @@ -120,26 +147,12 @@ The following base classes are proposed to support modularizing the storage of p :ref:`NXpeak`: A base class to describe peaks mathematically. - :ref:`NXpump`: - A base class to describe details about pump(s) as components of an electron microscope. - - :ref:`NXscanbox_em`: - A base class to represent the component of an electron microscope which realizes a controlled deflection - (and eventually shift, blanking, and/or descanning) of the electron beam to illuminate the specimen in a controlled manner - This base class can be used to document the scan pattern. The base class focuses mostly on the concept idea that there - is a component in a microscope which controls eventually multiple other components such as beam deflectors to achieve deflection - and thus a controlled scanning of the beam over the sample/specimen surface. - :ref:`NXcircuit`, :ref:`NXcircuit_board`, :ref:`NXadc`, :ref: `NXdac`: Base classes to describe integrated circuits (ICs). Further consolidation of these base classes is planned. :ref:`NXspectrum_set`: A base class and specializations comparable to :ref:`NXimage_set` but for storing spectra. - :ref:`NXstage_lab`: - A base class to describe the stage/specimen holder which offers place for the documentation of the small-scale laboratory functionalities - which modern stages of electron microscopes typically offer. - .. _EmAnalysisClasses: From 44e59fcc7b588a09f9fdf5cb7080af177f290b06 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 27 Jun 2024 10:27:46 +0200 Subject: [PATCH 0729/1012] add x,y,z for coordinate system --- contributed_definitions/NXxps.nxdl.xml | 27 ++++++++++++-- contributed_definitions/nyaml/NXxps.yaml | 46 ++++++++++++++++++++---- 2 files changed, 63 insertions(+), 10 deletions(-) diff --git a/contributed_definitions/NXxps.nxdl.xml b/contributed_definitions/NXxps.nxdl.xml index 37d38a8562..8c083212f5 100644 --- a/contributed_definitions/NXxps.nxdl.xml +++ b/contributed_definitions/NXxps.nxdl.xml @@ -76,6 +76,21 @@ + + + + + + + + + + + + + + + Link to transformations defining the XPS base coordinate system, @@ -103,6 +118,12 @@ + + + Reference to the transformation describing the orientation of the beam + relative to a defined coordinate system. + + @@ -143,7 +164,7 @@ This should point to the last element of the coordinate system transformations defined in - /entry/sample_stage_cs_transformations/coordinate_system_transformations. + /entry/geometries/xps_coordinate_system/coordinate_system_transformations. @@ -205,7 +226,7 @@ This should point to the last element of the coordinate system transformations defined in - /entry/sample_stage_cs_transformations/coordinate_system_transformations. + /entry/geometries/xps_coordinate_system/coordinate_system_transformations. @@ -283,7 +304,7 @@ This should point to the last element of the coordinate system transformations defined in - /entry/sample_stage_cs_transformations/coordinate_system_transformations. + /entry/geometries/xps_coordinate_system/coordinate_system_transformations. diff --git a/contributed_definitions/nyaml/NXxps.yaml b/contributed_definitions/nyaml/NXxps.yaml index 1ab37c8c08..5fa3c20e38 100644 --- a/contributed_definitions/nyaml/NXxps.yaml +++ b/contributed_definitions/nyaml/NXxps.yaml @@ -40,6 +40,12 @@ NXxps(NXmpes): enumeration: [left_handed] z_direction: enumeration: [sample stage normal] + x: + enumeration: [[-1, 0, 0]] + y: + enumeration: [[0, 1, 0]] + z: + enumeration: [[0, 0, 1]] depends_on(NX_CHAR): doc: | Link to transformations defining the XPS base coordinate system, @@ -63,6 +69,11 @@ NXxps(NXmpes): unit: NX_POWER exists: recommended beamTYPE(NXbeam): + depends_on: + exists: recommended + doc: | + Reference to the transformation describing the orientation of the beam + relative to a defined coordinate system. transformations(NXtransformations): exists: recommended beam_azimuth_angle(NX_NUMBER): @@ -88,7 +99,7 @@ NXxps(NXmpes): \@depends_on: doc: | This should point to the last element of the coordinate system transformations defined in - /entry/sample_stage_cs_transformations/coordinate_system_transformations. + /entry/geometries/xps_coordinate_system/coordinate_system_transformations. (NXelectronanalyser): work_function(NX_FLOAT): transmission_function(NXdata): @@ -132,7 +143,7 @@ NXxps(NXmpes): \@depends_on: doc: | This should point to the last element of the coordinate system transformations defined in - /entry/sample_stage_cs_transformations/coordinate_system_transformations. + /entry/geometries/xps_coordinate_system/coordinate_system_transformations. (NXprocess_mpes): energy_referencing(NXcalibration): exists: recommended @@ -179,7 +190,7 @@ NXxps(NXmpes): \@depends_on: doc: | This should point to the last element of the coordinate system transformations defined in - /entry/sample_stage_cs_transformations/coordinate_system_transformations. + /entry/geometries/xps_coordinate_system/coordinate_system_transformations. data(NXdata): energy(NX_NUMBER): \@energy_indices: @@ -187,7 +198,7 @@ NXxps(NXmpes): exists: recommended # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# b79aafd627dc66e2941b99ce3587e1b62e60d230d68cd74d73f030eae13fcf10 +# 1d639383e35ece0a8c26abbb69e42a98d5cec75c79365ed55a268bfe85d68d81 # # # - - - Base class for an ampere meter. - - - - - Current measured. - - - - diff --git a/contributed_definitions/NXbiprism_em.nxdl.xml b/contributed_definitions/NXbiprism_em.nxdl.xml deleted file mode 100644 index c826d453b6..0000000000 --- a/contributed_definitions/NXbiprism_em.nxdl.xml +++ /dev/null @@ -1,36 +0,0 @@ - - - - - - - Base class for electron biprism as it is used in electron microscopy. - - - - - Was the prism used? - - - diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml index 0c2cf8883f..c98bdd9fb0 100644 --- a/contributed_definitions/NXcomponent_em.nxdl.xml +++ b/contributed_definitions/NXcomponent_em.nxdl.xml @@ -34,6 +34,11 @@ via the NXtransformations group. + + + Was the component used? + + Given name to the component. diff --git a/contributed_definitions/NXcorrector_ax.nxdl.xml b/contributed_definitions/NXcorrector_ax.nxdl.xml deleted file mode 100644 index 055c99054c..0000000000 --- a/contributed_definitions/NXcorrector_ax.nxdl.xml +++ /dev/null @@ -1,62 +0,0 @@ - - - - - - Base class for a corrector reshaping an ellipse-shaped electron beam to a circular one. - - * `L. Reimer 1998, Springer, 1998 <https://dx.doi.org/10.1007/978-3-540-3896>`_ - * `M. Tanaka et al., Electron Microscopy Glossary, 2024 <https://www.jeol.com/words/semterms/20201020.111014.php#gsc.tab=0>`_ - - Stigmator is an exact synonym. - - - - - Was the corrector used? - - - - - Descriptor for the correction strength along the first direction when - exact technical details are unknown or not directly controllable as the - control software of the microscope does not enable or was not configured - to display these values (for end users). - - - - - Descriptor for the correction strength along the second direction when - exact technical details are unknown or not directly controllable as the - control software of the microscope does not enable or was not configured - to display these values (for end users). - - - - - - diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 9bf122a4f0..af816bcc41 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -47,8 +47,8 @@ use multiple groups: * :ref:`NXcorrector_cs` for spherical aberration - * :ref:`NXmonochromator_em` for energy filtering or chromatic aberration - * :ref:`NXcorrector_ax` for axial astigmatism correction + * :ref:`NXmonochromator` for energy filtering or chromatic aberration + * corrector_ax in :ref:`NXem` for axial astigmatism correction @@ -57,7 +57,7 @@ - + Specific information about the alignment procedure that is a process during which the corrector is configured to enable calibrated usage of the instrument. diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml index f91ae3ac7c..3840d10958 100644 --- a/contributed_definitions/NXebeam_column.nxdl.xml +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -22,9 +22,6 @@ # For further information, see http://www.nexusformat.org --> - @@ -44,8 +41,8 @@ part "an electron gun" reusable in other context--> of reproducibility in the illumination conditions. - + The source which creates the electron beam. @@ -100,11 +97,13 @@ relevant from maintenance point of view--> - + + - + + Individual characterization results for the position, shape, diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 499363e315..0edb3ac079 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -374,12 +374,12 @@ we just say we compose using the base class NXcoordinate_system--> - + + - Details about the control program used for operating the microscope. @@ -389,6 +389,12 @@ we just say we compose using the base class NXcoordinate_system--> + + + + + + This concept is related to term `Source`_ of the EMglossary standard. @@ -423,27 +429,108 @@ likewise if you provide fabrication details you need to provide vendor and model - - + + + Device for improving energy resolution or reducing chromatic aberration. + + Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector + like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ + + + + + Qualitative type of the component. + + + + + + + + + + + + + + + + + + + + + + + + + + + Device reshaping an ellipse-shaped electron beam to a circular one. + + * `L. Reimer 1998, Springer, 1998 <https://dx.doi.org/10.1007/978-3-540-3896>`_ + * `M. Tanaka et al., Electron Microscopy Glossary, 2024 <https://www.jeol.com/words/semterms/20201020.111014.php#gsc.tab=0>`_ + + Stigmator is an exact synonym. + - - - - + + + Electron biprism as it is used e.g. for electron holography. + + + + + + - - + + + + Device that causes a change in the phase of an electron wave. + + * `M. Malac et al. <https://doi.org/10.1093/jmicro/dfaa070>`_ + * `R. R. Schröder et al. <https://www.lem.kit.edu/152.php>`_ + + + + Qualitative type + + + + + + + + + + + + + - + + + + + + @@ -461,26 +548,44 @@ phase_plate_em--> - - + + + Device for improving energy resolution or reducing chromatic aberration. + + Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector + like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ + + + + Qualitative type of the component. + + + + + + + + + + - - + + + - + @@ -488,6 +593,8 @@ phase_plate_em--> + + @@ -495,6 +602,8 @@ phase_plate_em--> + + @@ -866,28 +975,84 @@ phase_plate_em--> - - + + + Device for improving energy resolution or reducing chromatic aberration. + + Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector + like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ + + + + + Was the corrector used? + + + + + + Energy dispersion in e.g. µm/eV. + + + + + Corresponding voltage for that energy dispersion. + + - + - - - - - + + + Device reshaping an ellipse-shaped electron beam to a circular one. + + * `L. Reimer 1998, Springer, 1998 <https://dx.doi.org/10.1007/978-3-540-3896>`_ + * `M. Tanaka et al., Electron Microscopy Glossary, 2024 <https://www.jeol.com/words/semterms/20201020.111014.php#gsc.tab=0>`_ + + Stigmator is an exact synonym. + + + + Was the corrector used? + + + + + Descriptor for the correction strength along the first direction when exact technical details + are unknown or not directly controllable as the control software of the microscope does not + enable or was not configured to display these values (for end users). + + + + + Descriptor for the correction strength along the second direction when exact technical details + are unknown or not directly controllable as the control software of the microscope does not + enable or was not configured to display these values (for end users). + + + + + + + + + + This concept is related to term `Electron Beam`_ of the EMglossary standard. + + .. _Electron Beam: https://purls.helmholtz-metadaten.de/emg/EMG_00000021 + - @@ -898,15 +1063,20 @@ phase_plate_em--> + + + + + + - - - - + + + Nominal current of the heater. @@ -926,13 +1096,15 @@ phase_plate_em--> + + - + diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml index 949635731f..c2fc3a6d3c 100644 --- a/contributed_definitions/NXibeam_column.nxdl.xml +++ b/contributed_definitions/NXibeam_column.nxdl.xml @@ -22,11 +22,10 @@ # For further information, see http://www.nexusformat.org --> - +part "an ion gun" reusable in other context because if it where an NXcomponent_em it can only be used for +em unless NXcomponent becomes a general base class from which all physical objects from which +instruments are built can inherit but that is even stronger promoting the idea and use of base class inheritance--> Base class for a set of components equipping an instrument with FIB capabilities. @@ -124,12 +123,13 @@ NEW ISSUE: (at which location?).--> - - + - + + + + Individual characterization results for the position, shape, @@ -139,18 +139,7 @@ relevant from maintenance point of view--> at which details about the ion beam are probed. - + + diff --git a/contributed_definitions/NXphase_plate_em.nxdl.xml b/contributed_definitions/NXphase_plate_em.nxdl.xml deleted file mode 100644 index 0f095f1c30..0000000000 --- a/contributed_definitions/NXphase_plate_em.nxdl.xml +++ /dev/null @@ -1,45 +0,0 @@ - - - - - - - Base class for device that causes a change in the phase of an electron wave. - - * `M. Malac et al. <https://doi.org/10.1093/jmicro/dfaa070>`_ - * `R. R. Schröder et al. <https://www.lem.kit.edu/152.php>`_ - - - - - Qualitative type - - - - - - - - diff --git a/contributed_definitions/nyaml/NXammeter.yaml b/contributed_definitions/nyaml/NXammeter.yaml deleted file mode 100644 index 21353cf77a..0000000000 --- a/contributed_definitions/nyaml/NXammeter.yaml +++ /dev/null @@ -1,11 +0,0 @@ -category: base -doc: | - Base class for an ampere meter. -type: group -NXammeter(NXobject): - # user perspective - current(NX_NUMBER): - doc: | - Current measured. - unit: NX_CURRENT - (NXfabrication): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXbiprism_em.yaml b/contributed_definitions/nyaml/NXbiprism_em.yaml deleted file mode 100644 index 6a689c4ec6..0000000000 --- a/contributed_definitions/nyaml/NXbiprism_em.yaml +++ /dev/null @@ -1,10 +0,0 @@ -category: base -doc: | - Base class for electron biprism as it is used in electron microscopy. -# more discussion -type: group -NXbiprism_em(NXcomponent_em): - # user perspective - applied(NX_BOOLEAN): - doc: | - Was the prism used? diff --git a/contributed_definitions/nyaml/NXcomponent_em.yaml b/contributed_definitions/nyaml/NXcomponent_em.yaml index f1e20fe529..444d9c9d0d 100644 --- a/contributed_definitions/nyaml/NXcomponent_em.yaml +++ b/contributed_definitions/nyaml/NXcomponent_em.yaml @@ -10,6 +10,9 @@ NXcomponent_em(NXobject): Specifies the position of the component by pointing to the last transformation in the transformation chain that is defined via the NXtransformations group. + applied(NX_BOOLEAN): + doc: | + Was the component used? name(NX_CHAR): doc: | Given name to the component. diff --git a/contributed_definitions/nyaml/NXcorrector_ax.yaml b/contributed_definitions/nyaml/NXcorrector_ax.yaml deleted file mode 100644 index 154a8c25d9..0000000000 --- a/contributed_definitions/nyaml/NXcorrector_ax.yaml +++ /dev/null @@ -1,34 +0,0 @@ -category: base -doc: | - Base class for a corrector reshaping an ellipse-shaped electron beam to a circular one. - - * `L. Reimer 1998, Springer, 1998 `_ - * `M. Tanaka et al., Electron Microscopy Glossary, 2024 `_ - - Stigmator is an exact synonym. -type: group -NXcorrector_ax(NXcomponent_em): - # user perspective - applied(NX_BOOLEAN): - doc: | - Was the corrector used? - value_x(NX_NUMBER): - doc: | - Descriptor for the correction strength along the first direction when - exact technical details are unknown or not directly controllable as the - control software of the microscope does not enable or was not configured - to display these values (for end users). - unit: NX_ANY - value_y(NX_NUMBER): - doc: | - Descriptor for the correction strength along the second direction when - exact technical details are unknown or not directly controllable as the - control software of the microscope does not enable or was not configured - to display these values (for end users). - # control level perspective - # strength(NX_NUMBER): - # axial component(NX_NUMBER): - # technical design perspective - (NXlens_em): - # (NXaperture_em): - # (NXdeflector): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXcorrector_cs.yaml b/contributed_definitions/nyaml/NXcorrector_cs.yaml index 85c1140357..1b63a0df3e 100644 --- a/contributed_definitions/nyaml/NXcorrector_cs.yaml +++ b/contributed_definitions/nyaml/NXcorrector_cs.yaml @@ -14,8 +14,8 @@ doc: | use multiple groups: * :ref:`NXcorrector_cs` for spherical aberration - * :ref:`NXmonochromator_em` for energy filtering or chromatic aberration - * :ref:`NXcorrector_ax` for axial astigmatism correction + * :ref:`NXmonochromator` for energy filtering or chromatic aberration + * corrector_ax in :ref:`NXem` for axial astigmatism correction type: group symbols: @@ -29,7 +29,7 @@ NXcorrector_cs(NXcomponent_em): doc: | Was the corrector used? # NEW ISSUE: clarify the mathematical details behind the - ZEMLIN_TABLEAU(NXprocess): + zemlin_tableauID(NXprocess): doc: | Specific information about the alignment procedure that is a process during which the corrector is configured to enable calibrated usage of the instrument. diff --git a/contributed_definitions/nyaml/NXebeam_column.yaml b/contributed_definitions/nyaml/NXebeam_column.yaml index 119b375a30..eefdc4b162 100644 --- a/contributed_definitions/nyaml/NXebeam_column.yaml +++ b/contributed_definitions/nyaml/NXebeam_column.yaml @@ -1,8 +1,6 @@ category: base doc: | Base class for a set of components providing a controllable electron beam. -# symbols: -# doc: The symbols used in the schema to specify e.g. variables. type: group # NXebeam_column is an NXobject instead of an NXcomponent_em to make that # part "an electron gun" reusable in other context @@ -18,8 +16,8 @@ NXebeam_column(NXobject): Instead, they rely on the assumption that the microscope and control software work as expected. Selecting then a specific operation_mode assures some level of reproducibility in the illumination conditions. - (NXchamber): (NXfabrication): + (NXchamber): electron_source(NXsource): doc: | The source which creates the electron beam. @@ -57,11 +55,13 @@ NXebeam_column(NXobject): doc: | Collection of axis-based translations and rotations to describe the location and geometry of the component in the instrument. - (NXaperture_em): (NXlens_em): + (NXaperture_em): + (NXmonochromator): (NXcorrector_cs): - # (NXscanbox_em): + (NXcomponent_em): (NXsensor): + (NXactuator): (NXbeam): doc: | Individual characterization results for the position, shape, diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index db3e87d217..d14c03723c 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -334,13 +334,14 @@ NXem(NXobject): em_lab(NXinstrument): instrument_name(NX_CHAR): exists: recommended + location(NX_CHAR): + exists: recommended fabrication(NXfabrication): + exists: optional vendor(NX_CHAR): model(NX_CHAR): identifier(NX_CHAR): exists: recommended - location(NX_CHAR): - exists: recommended control_programID(NXprogram): exists: [min, 1, max, infty] doc: @@ -349,6 +350,14 @@ NXem(NXobject): program(NX_CHAR): \@version(NX_CHAR): ebeam_column(NXebeam_column): + chamber(NXchamber): + exists: optional + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + identifier(NX_CHAR): + exists: recommended electron_source(NXsource): doc: - | @@ -386,29 +395,103 @@ NXem(NXobject): model(NX_CHAR): identifier(NX_CHAR): exists: recommended - monochromator_emID(NXmonochromator_em): + monochromatorID(NXmonochromator): exists: [min, 0, max, infty] - applied(NX_BOOLEAN): + doc: + - | + Device for improving energy resolution or reducing chromatic aberration. + - | + Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector like `_ + # user perspective + type(NX_CHAR): + doc: + - | + Qualitative type of the component. + enumeration: [wien, alfa, omega, castaing_henry, gatan_imaging, sector_analyzer] + # control level perspective + # technical design perspective fabrication(NXfabrication): exists: optional vendor(NX_CHAR): model(NX_CHAR): identifier(NX_CHAR): exists: recommended - type(NX_CHAR): - dispersion(NX_NUMBER): - exists: recommended corrector_cs(NXcorrector_cs): + exists: [min, 0, max, 1] + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + identifier(NX_CHAR): + exists: recommended + corrector_ax(NXcomponent_em): + exists: [min, 0, max, 1] + doc: + - | + Device reshaping an ellipse-shaped electron beam to a circular one. + + * `L. Reimer 1998, Springer, 1998 `_ + * `M. Tanaka et al., Electron Microscopy Glossary, 2024 `_ + + - | + Stigmator is an exact synonym. + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + identifier(NX_CHAR): + exists: recommended + biprism(NXcomponent_em): + exists: optional + doc: + - | + Electron biprism as it is used e.g. for electron holography. + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + identifier(NX_CHAR): + exists: recommended + phase_plateID(NXcomponent_em): + # contributed definition NXwaveplate is a closely related concept but may fit even better but waveplate + # has been defined from the perspective of classical optics + # same challenge like with NXlens and NXlens_em, an electrostatic lens is not the same concept + # like it is an glass lens (i.e. optical) NXlens + # but both concepts have in common that they can be assumed to be specialization of a super class + # lenses i.e. devices which can affect the pathes of beams exists: [min, 0, max, infty] - applied(NX_BOOLEAN): - corrector_ax(NXcorrector_ax): + doc: + - | + Device that causes a change in the phase of an electron wave. + + * `M. Malac et al. `_ + * `R. R. Schröder et al. `_ + type(NX_CHAR): + doc: + - | + Qualitative type + enumeration: [thin_film, electrostatic] + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + identifier(NX_CHAR): + exists: recommended + sensorID(NXsensor): + exists: [min, 0, max, infty] + actuatorID(NXactuator): exists: [min, 0, max, infty] - applied(NX_BOOLEAN): - # biprism_em - # phase_plate_em ibeam_column(NXibeam_column): exists: [min, 0, max, 1] # there are tri-beam SEMs but they typically use a laser for which we should have an own base class + chamber(NXchamber): + exists: optional + fabrication(NXfabrication): + exists: optional + vendor(NX_CHAR): + model(NX_CHAR): + identifier(NX_CHAR): + exists: recommended ion_source(NXsource): probe(NXion): lens_emID(NXlens_em): @@ -427,26 +510,36 @@ NXem(NXobject): model(NX_CHAR): identifier(NX_CHAR): exists: recommended - monochromator_emID(NXmonochromator_em): + monochromatorID(NXmonochromator): exists: [min, 0, max, infty] - applied(NX_BOOLEAN): + doc: + - | + Device for improving energy resolution or reducing chromatic aberration. + - | + Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector like `_ + type(NX_CHAR): + doc: + - | + Qualitative type of the component. + enumeration: [wien, alfa, omega, castaing_henry, gatan_imaging, sector_analyzer] fabrication(NXfabrication): exists: optional vendor(NX_CHAR): model(NX_CHAR): identifier(NX_CHAR): exists: recommended - type(NX_CHAR): - dispersion(NX_NUMBER): - exists: recommended - # corrector_ax(NXcorrector_ax): - # exists: [min, 0, max, infty] - # applied(NX_BOOLEAN): + # device for correcting axial astigmatism of ion beam? + sensorID(NXsensor): + exists: [min, 0, max, infty] + actuatorID(NXactuator): + exists: [min, 0, max, infty] detectorID(NXdetector): exists: [min, 0, max, infty] fabrication(NXfabrication): vendor(NX_CHAR): model(NX_CHAR): + # identifier(NX_CHAR): # only relevant when deprecating serial_number + # exists: recommended scan_controller(NXscanbox_em): exists: optional fabrication(NXfabrication): @@ -455,6 +548,10 @@ NXem(NXobject): model(NX_CHAR): identifier(NX_CHAR): exists: recommended + (NXsensor): + exists: [min, 0, max, infty] + (NXactuator): + exists: [min, 0, max, infty] (NXstage_lab): exists: [min, 0, max, infty] fabrication(NXfabrication): @@ -463,6 +560,10 @@ NXem(NXobject): model(NX_CHAR): identifier(NX_CHAR): exists: recommended + (NXchamber): + exists: [min, 0, max, infty] + (NXpump): + exists: [min, 0, max, infty] event_data_em_set(NXevent_data_em_set): exists: [min, 0, max, 1] # an instance must not have an NXevent_data_em_set but if it has one it must not be more than 1 ! @@ -780,28 +881,89 @@ NXem(NXobject): exists: [min, 0, max, infty] aperture_emID(NXaperture_em): exists: [min, 0, max, infty] - monochromator_emID(NXmonochromator_em): + monochromatorID(NXmonochromator): exists: [min, 0, max, infty] + doc: + - | + Device for improving energy resolution or reducing chromatic aberration. + - | + Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector like `_ + # user perspective applied(NX_BOOLEAN): + doc: + - | + Was the corrector used? + # control level perspective + # technical components of the corrector + dispersion(NX_NUMBER): + exists: recommended + doc: + - | + Energy dispersion in e.g. µm/eV. + unit: NX_ANY + voltage(NX_NUMBER): + exists: recommended + doc: + - | + Corresponding voltage for that energy dispersion. + unit: NX_VOLTAGE corrector_cs(NXcorrector_cs): exists: [min, 0, max, infty] applied(NX_BOOLEAN): - ZEMLIN_TABLEAU(NXprocess): - exists: recommended + zemlin_tableauID(NXprocess): + exists: [min, 1, max, infty] (NXprocess): ceos(NXaberration_model_ceos): exists: optional nion(NXaberration_model_nion): exists: optional - # we could write down how to store the aberrations + # we could write down how to store the aberrations but we should not force to add aberrations # basically optional use of NXaberration therein at least some value required - corrector_ax(NXcorrector_ax): - exists: [min, 0, max, infty] + corrector_ax(NXcomponent_em): + exists: [min, 0, max, 1] + doc: + - | + Device reshaping an ellipse-shaped electron beam to a circular one. + + * `L. Reimer 1998, Springer, 1998 `_ + * `M. Tanaka et al., Electron Microscopy Glossary, 2024 `_ + + - | + Stigmator is an exact synonym. applied(NX_BOOLEAN): + doc: + - | + Was the corrector used? value_x(NX_NUMBER): + doc: + - | + Descriptor for the correction strength along the first direction when exact technical details + are unknown or not directly controllable as the control software of the microscope does not + enable or was not configured to display these values (for end users). + unit: NX_ANY value_y(NX_NUMBER): - # biprism_em - # phase_plate_em + doc: + - | + Descriptor for the correction strength along the second direction when exact technical details + are unknown or not directly controllable as the control software of the microscope does not + enable or was not configured to display these values (for end users). + unit: NX_ANY + biprism(NXcomponent_em): + exists: [min, 0, max, 1] + phase_plateID(NXcomponent_em): + exists: [min, 0, max, infty] + sensorID(NXsensor): + exists: [min, 0, max, infty] + actuatorID(NXactuator): + exists: [min, 0, max, infty] + (NXbeam): + exists: [min, 0, max, infty] + doc: + - | + xref: + spec: EMglossary + term: Electron Beam + url: https://purls.helmholtz-metadaten.de/emg/EMG_00000021 ibeam_column(NXibeam_column): exists: [min, 0, max, 1] ion_source(NXsource): @@ -814,14 +976,25 @@ NXem(NXobject): monochromator_emID(NXmonochromator_em): exists: [min, 0, max, infty] applied(NX_BOOLEAN): + sensorID(NXsensor): + exists: [min, 0, max, infty] + actuatorID(NXactuator): + exists: [min, 0, max, infty] + (NXbeam): + exists: [min, 0, max, infty] + detectorID(NXdetector): + exists: [min, 0, max, infty] + mode(NX_CHAR): scan_controller(NXscanbox_em): exists: optional scan_schema(NX_CHAR): dwell_time(NX_NUMBER): - detectorID(NXdetector): + + (NXsensor): exists: [min, 0, max, infty] - mode(NX_CHAR): - heater(NXobject): # (NXactuator): + (NXactuator): + exists: [min, 0, max, infty] + heater(NXactuator): exists: optional current(NX_NUMBER): doc: @@ -842,9 +1015,15 @@ NXem(NXobject): exists: [min, 0, max, infty] design(NX_CHAR): exists: recommended + (NXchamber): + exists: [min, 0, max, infty] + (NXpump): + exists: [min, 0, max, infty] + simulation(NXem_sim): exists: optional # remains to be discussed based on examples + # relevant research result post-processed for specific community methods # but normalized in its representation ready to be consumed for a # research data management system diff --git a/contributed_definitions/nyaml/NXibeam_column.yaml b/contributed_definitions/nyaml/NXibeam_column.yaml index e02716619b..7a416e526c 100644 --- a/contributed_definitions/nyaml/NXibeam_column.yaml +++ b/contributed_definitions/nyaml/NXibeam_column.yaml @@ -21,12 +21,12 @@ doc: | * `E. I. Preiß et al. `_ * `J. F. Ziegler et al. `_ * `J. Lili `_ - -# symbols: -# doc: The symbols used in the schema to specify e.g. variables. + type: group # NXibeam_column is an NXobject instead of an NXcomponent_em to make that -# part "an ion gun" reusable in other context +# part "an ion gun" reusable in other context because if it where an NXcomponent_em it can only be used for +# em unless NXcomponent becomes a general base class from which all physical objects from which +# instruments are built can inherit but that is even stronger promoting the idea and use of base class inheritance NXibeam_column(NXobject): (NXchamber): (NXfabrication): @@ -79,12 +79,13 @@ NXibeam_column(NXobject): doc: | Collection of axis-based translations and rotations to describe the location and geometry of the component in the instrument. - # NEW ISSUE: details about the life/up-time of the source - # relevant from maintenance point of view - (NXaperture_em): + # NEW ISSUE: details about the life/up-time of the source relevant from maintenance point of view (NXlens_em): - (NXscanbox_em): + (NXaperture_em): + (NXmonochromator): + (NXcomponent_em): (NXsensor): + (NXactuator): (NXbeam): doc: | Individual characterization results for the position, shape, @@ -92,17 +93,6 @@ NXibeam_column(NXobject): :ref:`NXtransformations` should be used to specify the location or position at which details about the ion beam are probed. - # NEW ISSUE: scan_align(NXprocess): - # NEW ISSUE: milling_plan(NXprocess): - # doc: Description of the program and sequence of sample positions sputtered. - # in here we can store time-dependent quantities - # NEW ISSUE: for documentation of charge compensation - # (NXtransformation): - # doc: | - # A right-handed Cartesian coordinate system is used whose positive - # z-axis points in the direction of the ion beam, i.e. towards the - # sample. For modelling ion milling it is relevant to document the - # illumination vector. NXtransformations offers a place to store how the - # ion gun coordinate system has to be rotated to align its positive z-axis - # with the positive z-axis of e.g. the electron beam and ion beam - # respectively. + (NXdeflector): + # for further ideas and comments inspect version + # https://github.com/FAIRmat-NFDI/nexus_definitions/commit/0682943baaef54d4a6386b5433f9721af6d3d81b diff --git a/contributed_definitions/nyaml/NXphase_plate_em.yaml b/contributed_definitions/nyaml/NXphase_plate_em.yaml deleted file mode 100644 index 7aa78f6438..0000000000 --- a/contributed_definitions/nyaml/NXphase_plate_em.yaml +++ /dev/null @@ -1,17 +0,0 @@ -category: base -doc: | - Base class for device that causes a change in the phase of an electron wave. - - * `M. Malac et al. `_ - * `R. R. Schröder et al. `_ - -# more discussion -type: group -NXphase_plate_em(NXcomponent_em): - # user perspective - type(NX_CHAR): - doc: | - Qualitative type - enumeration: [thin_film, electrostatic] - # control level perspective - # technical components of the corrector diff --git a/manual/source/classes/contributed_definitions/em-structure.rst b/manual/source/classes/contributed_definitions/em-structure.rst index dbf3a05f4e..6d9e29bf53 100644 --- a/manual/source/classes/contributed_definitions/em-structure.rst +++ b/manual/source/classes/contributed_definitions/em-structure.rst @@ -90,28 +90,15 @@ The following base classes are proposed to support modularizing the storage of p :ref:`NXcoordinate_system_set`, :ref:`NXcoordinate_system`, :ref:`NXtransformations`: Base classes to describe different coordinate systems used and/or to be harmonized or transformed into one another and respective transformations. - - :ref:`NXcorrector_cs`: - A base class to describe details about corrective lens or compound lens devices - which reduce the (spherical) aberrations of an electron beam. - :ref:`NXaberration_model`, :ref:`NXaberration_model_ceos`, :ref:`NXaberration_model_nion`, :ref:`NXaberration`, :ref:`NXcorrector_cs`, :ref:`NXcorrector_ax`: + :ref:`NXaberration_model`, :ref:`NXaberration_model_ceos`, :ref:`NXaberration_model_nion`, :ref:`NXaberration`: Base classes to describe procedures and values for the calibration of aberrations based on conventions of different companies active in the field of aberration correction. - :ref:`NXcorrector_ax`: + :ref:`NXcorrector_cs`: A base class to describe details about corrective lens or compound lens devices - which reduce the axial astigmatism aberrations of an electron beam. + which reduce the (spherical) aberrations of an electron beam. - :ref:`NXmonochromator_em`: - A base class to describe details about an energy filtering device. - - :ref:`NXphase_plate_em`, :ref:`NXbiprism_em`, :ref:`NXammeter`: - Base classes to group pieces of information about devices that are specific additions - to an electron microscope to perform special methods, like exploring quantum mechanics - or modulating the phase or an electron beam, perform electron holography, or measuring - EBIC current. - :ref:`NXscanbox_em`: A base class to represent the component of an electron microscope which realizes a controlled deflection (and eventually shift, blanking, and/or descanning) of the electron beam to illuminate the specimen in a controlled manner From ada2a182693581cce65b81fb1f0ed1d3eb8012a3 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 27 Jun 2024 13:11:17 +0200 Subject: [PATCH 0731/1012] Key change to prepare enabling of generalized usability of base class NXcomponent for technical components through removing electron microscopy specificity --- .../NXcomponent_em.nxdl.xml | 21 ++++++---------- .../nyaml/NXcomponent_em.yaml | 25 ++++++++----------- 2 files changed, 18 insertions(+), 28 deletions(-) diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml index c98bdd9fb0..4abe45201a 100644 --- a/contributed_definitions/NXcomponent_em.nxdl.xml +++ b/contributed_definitions/NXcomponent_em.nxdl.xml @@ -23,9 +23,7 @@ --> - Base class for components used in an electron microscope. - - The electron microscope can be a real one or a simulated microscope. + Base class for components of an instrument - real ones or a simulated ones. @@ -41,23 +39,20 @@ - Given name to the component. - - Exemplar value stage, lens C1. + Given name - - - Ideally, use identifier to point to a resource which provides - further details of the component. + Ideally, use instances of :ref:`NXidentifier` to point to a resource + that provides further details. - If such a resource does not exist or should not be used, - use this, though discouraged, free-text field to report - further details about the component. + If such a resource does not exist or should not be used, use this, though + discouraged, free-text. + + diff --git a/contributed_definitions/nyaml/NXcomponent_em.yaml b/contributed_definitions/nyaml/NXcomponent_em.yaml index 444d9c9d0d..dcb3e7c195 100644 --- a/contributed_definitions/nyaml/NXcomponent_em.yaml +++ b/contributed_definitions/nyaml/NXcomponent_em.yaml @@ -1,8 +1,6 @@ category: base doc: | - Base class for components used in an electron microscope. - - The electron microscope can be a real one or a simulated microscope. + Base class for components of an instrument - real ones or a simulated ones. type: group NXcomponent_em(NXobject): \@depends_on(NX_CHAR): @@ -15,19 +13,16 @@ NXcomponent_em(NXobject): Was the component used? name(NX_CHAR): doc: | - Given name to the component. - - Exemplar value stage, lens C1. - fabrication(NXfabrication): - identifier(NXidentifier): + Given name description(NX_CHAR): - doc: | - Ideally, use identifier to point to a resource which provides - further details of the component. - - If such a resource does not exist or should not be used, - use this, though discouraged, free-text field to report - further details about the component. + doc: + - | + Ideally, use instances of :ref:`NXidentifier` to point to a resource + that provides further details. + - | + If such a resource does not exist or should not be used, use this, though discouraged, free-text. + (NXfabrication): + (NXidentifier): (NXprogram): (NXtransformations): doc: | From 5d16c5564d27050e931dc2c42c073eacb91b5628 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 27 Jun 2024 13:24:21 +0200 Subject: [PATCH 0732/1012] Reverted code modernization that does not work in python=3.9 but that should be used for python>=3.12 --- dev_tools/docs/anchor_list.py | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/dev_tools/docs/anchor_list.py b/dev_tools/docs/anchor_list.py index a84ddd2909..1b411041df 100644 --- a/dev_tools/docs/anchor_list.py +++ b/dev_tools/docs/anchor_list.py @@ -114,7 +114,11 @@ def write(self): return contents = dict( _metadata=dict( - datetime=datetime.datetime.now(datetime.UTC).isoformat(), + # datetime=datetime.datetime.now(datetime.UTC).isoformat(), + # the next line is the py3.9 supported way of getting the datetime + # this will become deprecated however in py3.12 for which the + # line above-mentioned is a fix, which however does not work in py3.9 + datetime=datetime.datetime.utcnow().isoformat(), title="NeXus NXDL vocabulary.", subtitle="Anchors for all NeXus fields, groups, " "attributes, and links.", From c683317bf85e952863552a53da770eb75d9dd2c8 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 27 Jun 2024 13:35:06 +0200 Subject: [PATCH 0733/1012] Removed NXmonochromator_em --- .../NXmonochromator_em.nxdl.xml | 69 ------------------- .../nyaml/NXmonochromator_em.yaml | 32 --------- 2 files changed, 101 deletions(-) delete mode 100644 contributed_definitions/NXmonochromator_em.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXmonochromator_em.yaml diff --git a/contributed_definitions/NXmonochromator_em.nxdl.xml b/contributed_definitions/NXmonochromator_em.nxdl.xml deleted file mode 100644 index 67ec4d0e7e..0000000000 --- a/contributed_definitions/NXmonochromator_em.nxdl.xml +++ /dev/null @@ -1,69 +0,0 @@ - - - - - - - Base class for improving energy resolution in an electron microscope - or reducing chromatic aberration. - - Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or - `cc corrector like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ - - - - - Was the corrector used? - - - - - Qualitative type of the component. - - - - - - - - - - - - - - Energy dispersion in e.g. µm/eV. - - - - - Corresponding voltage for that energy dispersion. - - - - - - - diff --git a/contributed_definitions/nyaml/NXmonochromator_em.yaml b/contributed_definitions/nyaml/NXmonochromator_em.yaml deleted file mode 100644 index debc308c9b..0000000000 --- a/contributed_definitions/nyaml/NXmonochromator_em.yaml +++ /dev/null @@ -1,32 +0,0 @@ -category: base -doc: | - Base class for improving energy resolution in an electron microscope - or reducing chromatic aberration. - - Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or - `cc corrector like `_ -# more discussion -type: group -NXmonochromator_em(NXcomponent_em): - # user perspective - applied(NX_BOOLEAN): - doc: | - Was the corrector used? - type(NX_CHAR): - doc: | - Qualitative type of the component. - enumeration: [wien, alfa, omega, castaing_henry, gatan_imaging, sector_analyzer] - # control level perspective - # technical components of the corrector - dispersion(NX_NUMBER): - doc: | - Energy dispersion in e.g. µm/eV. - unit: NX_ANY - voltage(NX_NUMBER): - doc: | - Corresponding voltage for that energy dispersion. - unit: NX_VOLTAGE - (NXlens_em): - (NXaperture_em): - (NXdeflector): - (NXcrystal): From d3838f3d203796242a121ad10f79bc958324f54d Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 27 Jun 2024 13:57:34 +0200 Subject: [PATCH 0734/1012] Simplified base class design for documenting aberrations --- .../NXaberration_model.nxdl.xml | 83 ++++++++++++++++- .../NXaberration_model_ceos.nxdl.xml | 92 ------------------- .../NXaberration_model_nion.nxdl.xml | 63 ------------- .../NXcorrector_cs.nxdl.xml | 3 +- contributed_definitions/NXem.nxdl.xml | 5 +- .../nyaml/NXaberration_model.yaml | 90 +++++++++++++++++- .../nyaml/NXaberration_model_ceos.yaml | 71 -------------- .../nyaml/NXaberration_model_nion.yaml | 37 -------- .../nyaml/NXcorrector_cs.yaml | 3 +- contributed_definitions/nyaml/NXem.yaml | 6 +- .../contributed_definitions/em-structure.rst | 2 +- 11 files changed, 178 insertions(+), 277 deletions(-) delete mode 100644 contributed_definitions/NXaberration_model_ceos.nxdl.xml delete mode 100644 contributed_definitions/NXaberration_model_nion.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXaberration_model_ceos.yaml delete mode 100644 contributed_definitions/nyaml/NXaberration_model_nion.yaml diff --git a/contributed_definitions/NXaberration_model.nxdl.xml b/contributed_definitions/NXaberration_model.nxdl.xml index 67a975cc6b..92a81762d0 100644 --- a/contributed_definitions/NXaberration_model.nxdl.xml +++ b/contributed_definitions/NXaberration_model.nxdl.xml @@ -36,5 +36,86 @@ - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXaberration_model_ceos.nxdl.xml b/contributed_definitions/NXaberration_model_ceos.nxdl.xml deleted file mode 100644 index 3325e1569a..0000000000 --- a/contributed_definitions/NXaberration_model_ceos.nxdl.xml +++ /dev/null @@ -1,92 +0,0 @@ - - - - - - CEOS definitions/model for aberrations of electro-magnetic lenses. - - See `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) - for different definitions available and further details. Table 7-2 of Ibid. - publication (page 305ff) documents how to convert from the NION to the - CEOS definitions. - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXaberration_model_nion.nxdl.xml b/contributed_definitions/NXaberration_model_nion.nxdl.xml deleted file mode 100644 index 8903c73db2..0000000000 --- a/contributed_definitions/NXaberration_model_nion.nxdl.xml +++ /dev/null @@ -1,63 +0,0 @@ - - - - - - Nion definitions/model for aberrations of electro-magnetic lenses. - - See `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) - for different definitions available and further details. Table 7-2 of Ibid. - publication (page 305ff) documents how to convert from the Nion to the - CEOS definitions. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index af816bcc41..c42da92eb5 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -109,8 +109,7 @@ Place for storing measured or estimated aberrations (for each image or final). - - + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 0edb3ac079..70ea14e5fb 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -1005,8 +1005,7 @@ technical components of the corrector--> - - + @@ -1060,7 +1059,7 @@ basically optional use of NXaberration therein at least some value required--> - + diff --git a/contributed_definitions/nyaml/NXaberration_model.yaml b/contributed_definitions/nyaml/NXaberration_model.yaml index 534762555d..bb53dff370 100644 --- a/contributed_definitions/nyaml/NXaberration_model.yaml +++ b/contributed_definitions/nyaml/NXaberration_model.yaml @@ -10,4 +10,92 @@ type: group NXaberration_model(NXobject): model: enumeration: [ceos, nion] - (NXaberration): + # (NXaberration): + + # specifically-named aberrations following the CEOS convention + c_1(NXaberration): + a_1(NXaberration): + b_2(NXaberration): + a_2(NXaberration): + c_3(NXaberration): + s_3(NXaberration): + a_3(NXaberration): + # based on feedback from Thilo Remmele the following aberrations could be measured + # (enhanced mode, tilt angle > 30 mrad) but are not corrected + b_4(NXaberration): + d_4(NXaberration): + a_4(NXaberration): + c_5(NXaberration): + s_5(NXaberration): + r_5(NXaberration): + a_6(NXaberration): + + # further comments from Thilo Remmele (Leibniz-Institut für Kristallzüchtung) + # ThermoFisher uses CEOS correctors but makes customizations to these in their microscopes + # Aberration naming schema: C_order_multiplicity (similar to NXem, but with + # another coordinate system and in addition with a confidence entry. + # Aberrations with multiplicity 0 have no angle entry (C1,C3,C5,.., CEOS notation) + # contrast transferfuntion: ctf = e^(-i*Xi(g)) in Fourier space + # aberration function: + # Xi(g) = 2*pi/lamda{ 1/2 * (lamda*g)^2 (C20 + C22 cos[2(phi-phi_22)] + # +1/3 * (lamda*g)^3 (C31 cos[(phi-phi_31) + C33 cos[3(phi-phi_33) + # +1/4 * (lamda*g)^4 (C40 + C42 cos[2(phi-phi_42)] + C44 cos[4(phi-phi_42)] + # +1/f * (lamda*g)^f Sum (Cfm cos[m(phi-phi_fm)] where m=[0,2,..f] for even f and m=[1,3,..,f] for odd f + + # Thilo Remmele also mentions that there is a mapping of aberration coefficient names: + # C_2_0 -> C1 Defocus + # C_2_2 -> A1 2-fold astigmatism + # C_3_3 -> A2 3-fold astigmatism + # C_3_1 -> B2 axial coma + # C_4_0 -> C3 spherical aberration + # C_4_4 -> A3 4-fold astigmatism + # C_4_2 -> S3 star aberration + # C_5_5 -> A4 5-fold astigmatism + + # C_5_1 -> B4 axial coma + # C_5_3 -> D4 three lobe aberration + # C_6_0 -> C5 spherical aberration + # C_6_2 -> S5 star aberration + # C_6_4 -> R5 rosette aberration + # C_6_6 -> A5 6-fold astigmatism + + # In a session with HRTEM images the corrector is commonly aligned. + # The final measurement with the estimated residual aberrations + # should be saved in a corrector.html file (an example is appended + # at the end of this file. Unfortunately the datetime is not included + # in that html output, nor is the used outer tilt angle and exposure time. + # The datetime may be estimated from the file datetime and the Delta t entry, + # but caution if that datetime is not preserved on file transfers! + # More than one detector entry could occure but is not common. + # A seperate corrector schema, so it can be easily exchanged to other correctors if necessary. + # It might be useful to collect all the corrector entries in one table, for example to analyse the performance of the corrector. + # The corrector entry of the nexus em definition lacks the confidence information and the + # parameter settings for the estimation oft the aberrations. + + # specifically-named aberrations following the Nion convention + c_1_0(NXaberration): + c_1_2_a(NXaberration): + c_1_2_b(NXaberration): + c_2_1_a(NXaberration): + c_2_1_b(NXaberration): + c_2_3_a(NXaberration): + c_2_3_b(NXaberration): + c_3_0(NXaberration): + c_3_2_a(NXaberration): + c_3_2_b(NXaberration): + c_3_4_a(NXaberration): + c_3_4_b(NXaberration): + c_4_1_a(NXaberration): + c_4_1_b(NXaberration): + c_4_3_a(NXaberration): + c_4_3_b(NXaberration): + c_4_5_a(NXaberration): + c_4_5_b(NXaberration): + c_5_0(NXaberration): + c_5_2_a(NXaberration): + c_5_2_b(NXaberration): + c_5_4_a(NXaberration): + c_5_4_b(NXaberration): + c_5_6_a(NXaberration): + c_5_6_b(NXaberration): + diff --git a/contributed_definitions/nyaml/NXaberration_model_ceos.yaml b/contributed_definitions/nyaml/NXaberration_model_ceos.yaml deleted file mode 100644 index 14f9556140..0000000000 --- a/contributed_definitions/nyaml/NXaberration_model_ceos.yaml +++ /dev/null @@ -1,71 +0,0 @@ -category: base -doc: | - CEOS definitions/model for aberrations of electro-magnetic lenses. - - See `S. J. Pennycock and P. D. Nellist `_ (page 44ff, and page 118ff) - for different definitions available and further details. Table 7-2 of Ibid. - publication (page 305ff) documents how to convert from the NION to the - CEOS definitions. -type: group -NXaberration_model_ceos(NXaberration_model): - model: - enumeration: [ceos] - c_1(NXaberration): - a_1(NXaberration): - b_2(NXaberration): - a_2(NXaberration): - c_3(NXaberration): - s_3(NXaberration): - a_3(NXaberration): - - # based on feedback from Thilo Remmele the following aberrations could be measured - # (enhanced mode, tilt angle > 30 mrad) but are not corrected - b_4(NXaberration): - d_4(NXaberration): - a_4(NXaberration): - c_5(NXaberration): - s_5(NXaberration): - r_5(NXaberration): - a_6(NXaberration): - - # further comments from Thilo Remmele (Leibniz-Institut für Kristallzüchtung) - # ThermoFisher uses CEOS correctors but makes customizations to these in their microscopes - # Aberration naming schema: C_order_multiplicity (similar to NXem, but with - # another coordinate system and in addition with a confidence entry. - # Aberrations with multiplicity 0 have no angle entry (C1,C3,C5,.., CEOS notation) - # contrast transferfuntion: ctf = e^(-i*Xi(g)) in Fourier space - # aberration function: - # Xi(g) = 2*pi/lamda{ 1/2 * (lamda*g)^2 (C20 + C22 cos[2(phi-phi_22)] - # +1/3 * (lamda*g)^3 (C31 cos[(phi-phi_31) + C33 cos[3(phi-phi_33) - # +1/4 * (lamda*g)^4 (C40 + C42 cos[2(phi-phi_42)] + C44 cos[4(phi-phi_42)] - # +1/f * (lamda*g)^f Sum (Cfm cos[m(phi-phi_fm)] where m=[0,2,..f] for even f and m=[1,3,..,f] for odd f - - # Thilo Remmele also mentions that there is a mapping of aberration coefficient names: - # C_2_0 -> C1 Defocus - # C_2_2 -> A1 2-fold astigmatism - # C_3_3 -> A2 3-fold astigmatism - # C_3_1 -> B2 axial coma - # C_4_0 -> C3 spherical aberration - # C_4_4 -> A3 4-fold astigmatism - # C_4_2 -> S3 star aberration - # C_5_5 -> A4 5-fold astigmatism - - # C_5_1 -> B4 axial coma - # C_5_3 -> D4 three lobe aberration - # C_6_0 -> C5 spherical aberration - # C_6_2 -> S5 star aberration - # C_6_4 -> R5 rosette aberration - # C_6_6 -> A5 6-fold astigmatism - - # In a session with HRTEM images the corrector is commonly aligned. - # The final measurement with the estimated residual aberrations - # should be saved in a corrector.html file (an example is appended - # at the end of this file. Unfortunately the datetime is not included - # in that html output, nor is the used outer tilt angle and exposure time. - # The datetime may be estimated from the file datetime and the Delta t entry, - # but caution if that datetime is not preserved on file transfers! - # More than one detector entry could occure but is not common. - # A seperate corrector schema, so it can be easily exchanged to other correctors if necessary. - # It might be useful to collect all the corrector entries in one table, for example to analyse the performance of the corrector. - # The corrector entry of the nexus em definition lacks the confidence information and the - # parameter settings for the estimation oft the aberrations. diff --git a/contributed_definitions/nyaml/NXaberration_model_nion.yaml b/contributed_definitions/nyaml/NXaberration_model_nion.yaml deleted file mode 100644 index 2d47ab703f..0000000000 --- a/contributed_definitions/nyaml/NXaberration_model_nion.yaml +++ /dev/null @@ -1,37 +0,0 @@ -category: base -doc: | - Nion definitions/model for aberrations of electro-magnetic lenses. - - See `S. J. Pennycock and P. D. Nellist `_ (page 44ff, and page 118ff) - for different definitions available and further details. Table 7-2 of Ibid. - publication (page 305ff) documents how to convert from the Nion to the - CEOS definitions. -type: group -NXaberration_model_nion(NXaberration_model): - model: - enumeration: [nion] - c_1_0(NXaberration): - c_1_2_a(NXaberration): - c_1_2_b(NXaberration): - c_2_1_a(NXaberration): - c_2_1_b(NXaberration): - c_2_3_a(NXaberration): - c_2_3_b(NXaberration): - c_3_0(NXaberration): - c_3_2_a(NXaberration): - c_3_2_b(NXaberration): - c_3_4_a(NXaberration): - c_3_4_b(NXaberration): - c_4_1_a(NXaberration): - c_4_1_b(NXaberration): - c_4_3_a(NXaberration): - c_4_3_b(NXaberration): - c_4_5_a(NXaberration): - c_4_5_b(NXaberration): - c_5_0(NXaberration): - c_5_2_a(NXaberration): - c_5_2_b(NXaberration): - c_5_4_a(NXaberration): - c_5_4_b(NXaberration): - c_5_6_a(NXaberration): - c_5_6_b(NXaberration): diff --git a/contributed_definitions/nyaml/NXcorrector_cs.yaml b/contributed_definitions/nyaml/NXcorrector_cs.yaml index 1b63a0df3e..54cb4ca3ed 100644 --- a/contributed_definitions/nyaml/NXcorrector_cs.yaml +++ b/contributed_definitions/nyaml/NXcorrector_cs.yaml @@ -65,8 +65,7 @@ NXcorrector_cs(NXcomponent_em): (NXprocess): doc: | Place for storing measured or estimated aberrations (for each image or final). - ceos(NXaberration_model_ceos): - nion(NXaberration_model_nion): + (NXaberration_model): # technical design perspective (NXlens_em): (NXaperture_em): diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index d14c03723c..b3af61ae8a 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -913,9 +913,7 @@ NXem(NXobject): zemlin_tableauID(NXprocess): exists: [min, 1, max, infty] (NXprocess): - ceos(NXaberration_model_ceos): - exists: optional - nion(NXaberration_model_nion): + (NXaberration_model): exists: optional # we could write down how to store the aberrations but we should not force to add aberrations # basically optional use of NXaberration therein at least some value required @@ -973,7 +971,7 @@ NXem(NXobject): exists: [min, 0, max, infty] aperture_emID(NXaperture_em): exists: [min, 0, max, infty] - monochromator_emID(NXmonochromator_em): + monochromator_emID(NXmonochromator): exists: [min, 0, max, infty] applied(NX_BOOLEAN): sensorID(NXsensor): diff --git a/manual/source/classes/contributed_definitions/em-structure.rst b/manual/source/classes/contributed_definitions/em-structure.rst index 6d9e29bf53..e903d067de 100644 --- a/manual/source/classes/contributed_definitions/em-structure.rst +++ b/manual/source/classes/contributed_definitions/em-structure.rst @@ -91,7 +91,7 @@ The following base classes are proposed to support modularizing the storage of p Base classes to describe different coordinate systems used and/or to be harmonized or transformed into one another and respective transformations. - :ref:`NXaberration_model`, :ref:`NXaberration_model_ceos`, :ref:`NXaberration_model_nion`, :ref:`NXaberration`: + :ref:`NXaberration_model`, :ref:`NXaberration`: Base classes to describe procedures and values for the calibration of aberrations based on conventions of different companies active in the field of aberration correction. From 968b9bc4a707439733b5a59c3a7859d9979e4a2c Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 27 Jun 2024 16:34:29 +0200 Subject: [PATCH 0735/1012] Rename NXcomponent_em to NXcomponent --- .../{NXcomponent_em.nxdl.xml => NXcomponent.nxdl.xml} | 2 +- .../nyaml/{NXcomponent_em.yaml => NXcomponent.yaml} | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) rename contributed_definitions/{NXcomponent_em.nxdl.xml => NXcomponent.nxdl.xml} (94%) rename contributed_definitions/nyaml/{NXcomponent_em.yaml => NXcomponent.yaml} (97%) diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent.nxdl.xml similarity index 94% rename from contributed_definitions/NXcomponent_em.nxdl.xml rename to contributed_definitions/NXcomponent.nxdl.xml index 4abe45201a..603f8d3c1e 100644 --- a/contributed_definitions/NXcomponent_em.nxdl.xml +++ b/contributed_definitions/NXcomponent.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + Base class for components of an instrument - real ones or a simulated ones. diff --git a/contributed_definitions/nyaml/NXcomponent_em.yaml b/contributed_definitions/nyaml/NXcomponent.yaml similarity index 97% rename from contributed_definitions/nyaml/NXcomponent_em.yaml rename to contributed_definitions/nyaml/NXcomponent.yaml index dcb3e7c195..61fd4205ae 100644 --- a/contributed_definitions/nyaml/NXcomponent_em.yaml +++ b/contributed_definitions/nyaml/NXcomponent.yaml @@ -2,7 +2,7 @@ category: base doc: | Base class for components of an instrument - real ones or a simulated ones. type: group -NXcomponent_em(NXobject): +NXcomponent(NXobject): \@depends_on(NX_CHAR): doc: | Specifies the position of the component by pointing to the last From ff05fc4ccb4dc987908cb2a1445cb4a4f466f7f5 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 27 Jun 2024 16:56:06 +0200 Subject: [PATCH 0736/1012] Replaced all locations where NXcomponent_em was used for NXcomponent, replaced all locations where NXaperture_em was used for NXaperture --- .../NXaperture_em.nxdl.xml | 48 ---------------- .../NXcorrector_cs.nxdl.xml | 6 +- .../NXebeam_column.nxdl.xml | 6 +- contributed_definitions/NXem.nxdl.xml | 56 +++++++++++++++---- .../NXibeam_column.nxdl.xml | 18 +----- contributed_definitions/NXlens_em.nxdl.xml | 2 +- contributed_definitions/NXscanbox_em.nxdl.xml | 5 +- contributed_definitions/NXstage_lab.nxdl.xml | 2 +- .../nyaml/NXaperture_em.yaml | 24 -------- .../nyaml/NXcorrector_cs.yaml | 6 +- .../nyaml/NXebeam_column.yaml | 6 +- contributed_definitions/nyaml/NXem.yaml | 54 ++++++++++++++---- .../nyaml/NXibeam_column.yaml | 15 +---- contributed_definitions/nyaml/NXlens_em.yaml | 2 +- .../nyaml/NXscanbox_em.yaml | 3 +- .../nyaml/NXstage_lab.yaml | 2 +- .../contributed_definitions/em-structure.rst | 9 +-- 17 files changed, 118 insertions(+), 146 deletions(-) delete mode 100644 contributed_definitions/NXaperture_em.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXaperture_em.yaml diff --git a/contributed_definitions/NXaperture_em.nxdl.xml b/contributed_definitions/NXaperture_em.nxdl.xml deleted file mode 100644 index ac33c427b3..0000000000 --- a/contributed_definitions/NXaperture_em.nxdl.xml +++ /dev/null @@ -1,48 +0,0 @@ - - - - - - Base class for an individual aperture for beams in electron microscopy. - - - - - Relevant value from the control software. - - This is not always just the diameter of the aperture (not even in the case) - of a circular aperture. Usually, it is a value that is set in the control - software whereby a specific configuration of an aperture is selected by the - software. - - The control software of commercial microscope typically offers the user - access at a high abstraction level because of which many details about - the actual settings of the electrical components are typically unknown. - - However, if more details are known or should be documented one should - use the description field for this. - - - - diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index c42da92eb5..78c03a2c54 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -43,7 +43,7 @@ and microscope. Many of their technical details is proprietary knowledge. If functionalities for correcting multiple aberrations are included in - one :ref:`NXcomponent_em` `like it is reported here <https://www.ceos-gmbh.de/en/research/electrostat>`_ + one :ref:`NXcomponent` `like it is reported here <https://www.ceos-gmbh.de/en/research/electrostat>`_ use multiple groups: * :ref:`NXcorrector_cs` for spherical aberration @@ -114,6 +114,6 @@ - + diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml index 3840d10958..d4fc0f1538 100644 --- a/contributed_definitions/NXebeam_column.nxdl.xml +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -22,7 +22,7 @@ # For further information, see http://www.nexusformat.org --> @@ -98,10 +98,10 @@ relevant from maintenance point of view--> - + - + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 70ea14e5fb..62948768eb 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -422,7 +422,7 @@ likewise if you provide fabrication details you need to provide vendor and model - + @@ -465,7 +465,7 @@ technical design perspective--> - + Device reshaping an ellipse-shaped electron beam to a circular one. @@ -480,7 +480,7 @@ technical design perspective--> - + Electron biprism as it is used e.g. for electron holography. @@ -498,7 +498,7 @@ like it is an glass lens (i.e. optical) NXlens but both concepts have in common that they can be assumed to be specialization of a super class lenses i.e. devices which can affect the pathes of beams --> - + Device that causes a change in the phase of an electron wave. @@ -541,7 +541,7 @@ lenses i.e. devices which can affect the pathes of beams - + @@ -974,7 +974,25 @@ lenses i.e. devices which can affect the pathes of beams - + + + + Relevant value from the control software. + + This is not always just the diameter of the aperture (not even in the case) + of a circular aperture. Usually, it is a value that is set in the control + software whereby a specific configuration of an aperture is selected by the + software. + + The control software of commercial microscope typically offers the user + access at a high abstraction level because of which many details about + the actual settings of the electrical components are typically unknown. + + However, if more details are known or should be documented one should + use the description field for this. + + + Device for improving energy resolution or reducing chromatic aberration. @@ -1011,7 +1029,7 @@ technical components of the corrector--> - + Device reshaping an ellipse-shaped electron beam to a circular one. @@ -1040,8 +1058,8 @@ basically optional use of NXaberration therein at least some value required--> - - + + @@ -1058,7 +1076,25 @@ basically optional use of NXaberration therein at least some value required--> - + + + + Relevant value from the control software. + + This is not always just the diameter of the aperture (not even in the case) + of a circular aperture. Usually, it is a value that is set in the control + software whereby a specific configuration of an aperture is selected by the + software. + + The control software of commercial microscope typically offers the user + access at a high abstraction level because of which many details about + the actual settings of the electrical components are typically unknown. + + However, if more details are known or should be documented one should + use the description field for this. + + + diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml index c2fc3a6d3c..8d2374bfac 100644 --- a/contributed_definitions/NXibeam_column.nxdl.xml +++ b/contributed_definitions/NXibeam_column.nxdl.xml @@ -21,12 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - - + Base class for a set of components equipping an instrument with FIB capabilities. @@ -51,7 +46,6 @@ instruments are built can inherit but that is even stronger promoting the idea a * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ - The source which creates the ion beam. @@ -116,18 +110,12 @@ NEW ISSUE: (at which location?).--> To be defined more specifically. Community suggestions are welcome. - - - Collection of axis-based translations and rotations to describe the - location and geometry of the component in the instrument. - - - + - + diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml index 2e185370a8..97450992a9 100644 --- a/contributed_definitions/NXlens_em.nxdl.xml +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -26,7 +26,7 @@ has_part pole_piece https://purls.helmholtz-metadaten.de/emg/EMG_00000039--> - + Base class for an electro-magnetic lens or a compound lens. diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/contributed_definitions/NXscanbox_em.nxdl.xml index b36394726f..eae75cd135 100644 --- a/contributed_definitions/NXscanbox_em.nxdl.xml +++ b/contributed_definitions/NXscanbox_em.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + Scan box and coils which deflect a beam of charged particles in a controlled manner. @@ -102,8 +102,7 @@ +(NXlens_em):--> - + Base class for a stage (lab) used to hold, orient, and prepare a specimen. diff --git a/contributed_definitions/nyaml/NXaperture_em.yaml b/contributed_definitions/nyaml/NXaperture_em.yaml deleted file mode 100644 index 3dd75f400f..0000000000 --- a/contributed_definitions/nyaml/NXaperture_em.yaml +++ /dev/null @@ -1,24 +0,0 @@ -category: base -doc: | - Base class for an individual aperture for beams in electron microscopy. -type: group -NXaperture_em(NXcomponent_em): - # user perspective - value(NX_NUMBER): - doc: | - Relevant value from the control software. - - This is not always just the diameter of the aperture (not even in the case) - of a circular aperture. Usually, it is a value that is set in the control - software whereby a specific configuration of an aperture is selected by the - software. - - The control software of commercial microscope typically offers the user - access at a high abstraction level because of which many details about - the actual settings of the electrical components are typically unknown. - - However, if more details are known or should be documented one should - use the description field for this. - unit: NX_ANY - # control level - # technical design level \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXcorrector_cs.yaml b/contributed_definitions/nyaml/NXcorrector_cs.yaml index 54cb4ca3ed..615598af2c 100644 --- a/contributed_definitions/nyaml/NXcorrector_cs.yaml +++ b/contributed_definitions/nyaml/NXcorrector_cs.yaml @@ -10,7 +10,7 @@ doc: | and microscope. Many of their technical details is proprietary knowledge. If functionalities for correcting multiple aberrations are included in - one :ref:`NXcomponent_em` `like it is reported here `_ + one :ref:`NXcomponent` `like it is reported here `_ use multiple groups: * :ref:`NXcorrector_cs` for spherical aberration @@ -23,7 +23,7 @@ symbols: The symbols used in the schema to specify e.g. dimensions of arrays. n_img: | Number of images taken, at least one. -NXcorrector_cs(NXcomponent_em): +NXcorrector_cs(NXcomponent): # user perspective applied(NX_BOOLEAN): doc: | @@ -68,5 +68,5 @@ NXcorrector_cs(NXcomponent_em): (NXaberration_model): # technical design perspective (NXlens_em): - (NXaperture_em): + (NXaperture): # (NXdeflector): diff --git a/contributed_definitions/nyaml/NXebeam_column.yaml b/contributed_definitions/nyaml/NXebeam_column.yaml index eefdc4b162..276c90f879 100644 --- a/contributed_definitions/nyaml/NXebeam_column.yaml +++ b/contributed_definitions/nyaml/NXebeam_column.yaml @@ -2,7 +2,7 @@ category: base doc: | Base class for a set of components providing a controllable electron beam. type: group -# NXebeam_column is an NXobject instead of an NXcomponent_em to make that +# NXebeam_column is an NXobject instead of an NXcomponent to make that # part "an electron gun" reusable in other context NXebeam_column(NXobject): operation_mode(NX_CHAR): @@ -56,10 +56,10 @@ NXebeam_column(NXobject): Collection of axis-based translations and rotations to describe the location and geometry of the component in the instrument. (NXlens_em): - (NXaperture_em): + (NXaperture): (NXmonochromator): (NXcorrector_cs): - (NXcomponent_em): + (NXcomponent): (NXsensor): (NXactuator): (NXbeam): diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index b3af61ae8a..cb8c2cd0b2 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -387,7 +387,7 @@ NXem(NXobject): model(NX_CHAR): identifier(NX_CHAR): exists: recommended - aperture_emID(NXaperture_em): + apertureID(NXaperture): exists: [min, 0, max, infty] fabrication(NXfabrication): exists: optional @@ -424,7 +424,7 @@ NXem(NXobject): model(NX_CHAR): identifier(NX_CHAR): exists: recommended - corrector_ax(NXcomponent_em): + corrector_ax(NXcomponent): exists: [min, 0, max, 1] doc: - | @@ -441,7 +441,7 @@ NXem(NXobject): model(NX_CHAR): identifier(NX_CHAR): exists: recommended - biprism(NXcomponent_em): + biprism(NXcomponent): exists: optional doc: - | @@ -452,7 +452,7 @@ NXem(NXobject): model(NX_CHAR): identifier(NX_CHAR): exists: recommended - phase_plateID(NXcomponent_em): + phase_plateID(NXcomponent): # contributed definition NXwaveplate is a closely related concept but may fit even better but waveplate # has been defined from the perspective of classical optics # same challenge like with NXlens and NXlens_em, an electrostatic lens is not the same concept @@ -502,7 +502,7 @@ NXem(NXobject): model(NX_CHAR): identifier(NX_CHAR): exists: recommended - aperture_emID(NXaperture_em): + apertureID(NXaperture): exists: [min, 0, max, infty] fabrication(NXfabrication): exists: optional @@ -879,8 +879,25 @@ NXem(NXobject): unit: NX_CURRENT lens_emID(NXlens_em): exists: [min, 0, max, infty] - aperture_emID(NXaperture_em): + apertureID(NXaperture): exists: [min, 0, max, infty] + value(NX_NUMBER): + doc: + - | + Relevant value from the control software. + - | + This is not always just the diameter of the aperture (not even in the case) + of a circular aperture. Usually, it is a value that is set in the control + software whereby a specific configuration of an aperture is selected by the + software. + + The control software of commercial microscope typically offers the user + access at a high abstraction level because of which many details about + the actual settings of the electrical components are typically unknown. + + However, if more details are known or should be documented one should + use the description field for this. + unit: NX_ANY monochromatorID(NXmonochromator): exists: [min, 0, max, infty] doc: @@ -917,7 +934,7 @@ NXem(NXobject): exists: optional # we could write down how to store the aberrations but we should not force to add aberrations # basically optional use of NXaberration therein at least some value required - corrector_ax(NXcomponent_em): + corrector_ax(NXcomponent): exists: [min, 0, max, 1] doc: - | @@ -946,9 +963,9 @@ NXem(NXobject): are unknown or not directly controllable as the control software of the microscope does not enable or was not configured to display these values (for end users). unit: NX_ANY - biprism(NXcomponent_em): + biprism(NXcomponent): exists: [min, 0, max, 1] - phase_plateID(NXcomponent_em): + phase_plateID(NXcomponent): exists: [min, 0, max, infty] sensorID(NXsensor): exists: [min, 0, max, infty] @@ -969,8 +986,25 @@ NXem(NXobject): voltage(NX_NUMBER): lens_emID(NXlens_em): exists: [min, 0, max, infty] - aperture_emID(NXaperture_em): + apertureID(NXaperture): exists: [min, 0, max, infty] + value(NX_NUMBER): + doc: + - | + Relevant value from the control software. + - | + This is not always just the diameter of the aperture (not even in the case) + of a circular aperture. Usually, it is a value that is set in the control + software whereby a specific configuration of an aperture is selected by the + software. + + The control software of commercial microscope typically offers the user + access at a high abstraction level because of which many details about + the actual settings of the electrical components are typically unknown. + + However, if more details are known or should be documented one should + use the description field for this. + unit: NX_ANY monochromator_emID(NXmonochromator): exists: [min, 0, max, infty] applied(NX_BOOLEAN): diff --git a/contributed_definitions/nyaml/NXibeam_column.yaml b/contributed_definitions/nyaml/NXibeam_column.yaml index 7a416e526c..f4e2984c6d 100644 --- a/contributed_definitions/nyaml/NXibeam_column.yaml +++ b/contributed_definitions/nyaml/NXibeam_column.yaml @@ -23,13 +23,8 @@ doc: | * `J. Lili `_ type: group -# NXibeam_column is an NXobject instead of an NXcomponent_em to make that -# part "an ion gun" reusable in other context because if it where an NXcomponent_em it can only be used for -# em unless NXcomponent becomes a general base class from which all physical objects from which -# instruments are built can inherit but that is even stronger promoting the idea and use of base class inheritance -NXibeam_column(NXobject): +NXibeam_column(NXcomponent): (NXchamber): - (NXfabrication): ion_source(NXsource): doc: | The source which creates the ion beam. @@ -75,15 +70,11 @@ NXibeam_column(NXobject): doc: | To be defined more specifically. Community suggestions are welcome. unit: NX_ENERGY - (NXtransformations): - doc: | - Collection of axis-based translations and rotations to describe the - location and geometry of the component in the instrument. # NEW ISSUE: details about the life/up-time of the source relevant from maintenance point of view (NXlens_em): - (NXaperture_em): + (NXaperture): (NXmonochromator): - (NXcomponent_em): + (NXcomponent): (NXsensor): (NXactuator): (NXbeam): diff --git a/contributed_definitions/nyaml/NXlens_em.yaml b/contributed_definitions/nyaml/NXlens_em.yaml index eedc3fd8ae..ad26d199fd 100644 --- a/contributed_definitions/nyaml/NXlens_em.yaml +++ b/contributed_definitions/nyaml/NXlens_em.yaml @@ -13,7 +13,7 @@ doc: | type: group # more consolidation to harvest from a generic component base class # with other research fields (MPES, XPS, OPT) could be useful -NXlens_em(NXcomponent_em): +NXlens_em(NXcomponent): # user perspective value(NX_NUMBER): doc: | diff --git a/contributed_definitions/nyaml/NXscanbox_em.yaml b/contributed_definitions/nyaml/NXscanbox_em.yaml index 18569230ea..10597ef5be 100644 --- a/contributed_definitions/nyaml/NXscanbox_em.yaml +++ b/contributed_definitions/nyaml/NXscanbox_em.yaml @@ -8,7 +8,7 @@ doc: | The scanbox directs the probe of charged particles (electrons, ions) to controlled locations according to a scan scheme and plan. type: group -NXscanbox_em(NXcomponent_em): # await discussion on base class NXscan_control +NXscanbox_em(NXcomponent): # await discussion on base class NXscan_control # user perspective scan_schema(NX_CHAR): doc: | @@ -72,7 +72,6 @@ NXscanbox_em(NXcomponent_em): # await discussion on base class NXscan_control unit: NX_ANGLE # technical design perspective # (NXlens_em): - # (NXaperture_em): (NXdeflector): # (NXcg_point_set): # NEW ISSUE: build on work of EMglossary with HMC and use duty cycle instead diff --git a/contributed_definitions/nyaml/NXstage_lab.yaml b/contributed_definitions/nyaml/NXstage_lab.yaml index d5dbdf182a..326824c563 100644 --- a/contributed_definitions/nyaml/NXstage_lab.yaml +++ b/contributed_definitions/nyaml/NXstage_lab.yaml @@ -79,7 +79,7 @@ doc: | We are looking forward to suggestions from the scientists. type: group -NXstage_lab(NXcomponent_em): +NXstage_lab(NXcomponent): design(NX_CHAR): doc: | Principal design of the stage. diff --git a/manual/source/classes/contributed_definitions/em-structure.rst b/manual/source/classes/contributed_definitions/em-structure.rst index e903d067de..f26e75121b 100644 --- a/manual/source/classes/contributed_definitions/em-structure.rst +++ b/manual/source/classes/contributed_definitions/em-structure.rst @@ -65,15 +65,12 @@ The following base classes are proposed to support modularizing the storage of p A base class serving the possibility to group the components relevant for generating and shaping an ion beam of an instrument to offer focused-ion beam (milling) capabilities. - :ref:`NXcomponent_em`: - A base class to describe a hardware component for e.g. building a microscope. + :ref:`NXcomponent`: + A base class to describe components aka devices to building an instrument like a microscope irrespective whether that is a real one or a simulated one. :ref:`NXlens_em`: A base class to detail an electro-magnetic lens. In practice, an electron microscope has many such lenses. It is possible to specify as many lenses as necessary to represent eventually each single lens of the microscope and thus describe how the lenses are affecting the electron beam. This can offer opportunities for developers of software tools which strive to model the instrument e.g. to create digital twins of the instrument. We understand there is still a way to go with this to arrive there though. Consequently, we suggest to focus first on which details should be collected for a lens as a component so that developers of application definitions can take immediate advantage of this work. - :ref:`NXaperture_em`: - A base class to describe an aperture. - :ref:`NXdeflector`: A base class to describe a component to deflect a beam of charged particles. @@ -98,7 +95,7 @@ The following base classes are proposed to support modularizing the storage of p :ref:`NXcorrector_cs`: A base class to describe details about corrective lens or compound lens devices which reduce the (spherical) aberrations of an electron beam. - + :ref:`NXscanbox_em`: A base class to represent the component of an electron microscope which realizes a controlled deflection (and eventually shift, blanking, and/or descanning) of the electron beam to illuminate the specimen in a controlled manner From cb7423929fd9be0bcca8171826d3bf07d83ca98a Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 27 Jun 2024 18:38:21 +0200 Subject: [PATCH 0737/1012] Fused NXimage_r_set, NXimage_c_set, NXimage_r_set_diff into a single more meaty base class NXimage_set, the partner in crime for NXspectrum_set --- contributed_definitions/NXapm.nxdl.xml | 10 +- contributed_definitions/NXem.nxdl.xml | 160 ++--- contributed_definitions/NXem_adf.nxdl.xml | 21 +- contributed_definitions/NXem_ebsd.nxdl.xml | 5 +- contributed_definitions/NXem_eds.nxdl.xml | 9 +- contributed_definitions/NXem_img.nxdl.xml | 1 - contributed_definitions/NXem_method.nxdl.xml | 3 +- contributed_definitions/NXem_sim.nxdl.xml | 1 - .../NXevent_data_em.nxdl.xml | 4 +- .../NXimage_c_set.nxdl.xml | 471 -------------- .../NXimage_r_set.nxdl.xml | 333 ---------- .../NXimage_r_set_diff.nxdl.xml | 179 ------ contributed_definitions/NXimage_set.nxdl.xml | 581 +++++++++++++++++- .../NXspectrum_set.nxdl.xml | 28 +- contributed_definitions/nyaml/NXapm.yaml | 10 +- contributed_definitions/nyaml/NXem.yaml | 168 ++--- contributed_definitions/nyaml/NXem_adf.yaml | 11 +- contributed_definitions/nyaml/NXem_ebsd.yaml | 5 +- contributed_definitions/nyaml/NXem_eds.yaml | 9 +- contributed_definitions/nyaml/NXem_img.yaml | 1 - .../nyaml/NXem_method.yaml | 3 +- contributed_definitions/nyaml/NXem_sim.yaml | 1 - .../nyaml/NXevent_data_em.yaml | 4 +- .../nyaml/NXimage_c_set.yaml | 272 -------- .../nyaml/NXimage_r_set.yaml | 188 ------ .../nyaml/NXimage_r_set_diff.yaml | 123 ---- .../nyaml/NXimage_set.yaml | 377 +++++++++++- .../nyaml/NXspectrum_set.yaml | 32 +- dev_tools/tests/test_nxdl_utils.py | 6 +- .../contributed_definitions/em-structure.rst | 8 +- 30 files changed, 1094 insertions(+), 1930 deletions(-) delete mode 100644 contributed_definitions/NXimage_c_set.nxdl.xml delete mode 100644 contributed_definitions/NXimage_r_set.nxdl.xml delete mode 100644 contributed_definitions/NXimage_r_set_diff.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXimage_c_set.yaml delete mode 100644 contributed_definitions/nyaml/NXimage_r_set.yaml delete mode 100644 contributed_definitions/nyaml/NXimage_r_set_diff.yaml diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index 43dcbfd2d0..d6a03e3419 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -664,7 +664,7 @@ NEW ISSUE: add section for propagation_delay(NXprocess) ? NEW ISSUE: make recon an own subentry NXapm_reconstruction NEW ISSUE: different algorithms used one could create a class for each reconstruction method NEW ISSUE: make this rather an own subentry NXapm_ranging--> - + SEM or TEM image of the initial specimen i.e. ideally taken prior to the data acquisition. @@ -673,16 +673,16 @@ NEW ISSUE: make this rather an own subentry NXapm_ranging--> - - + + - + - + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 62948768eb..26f4ff2c67 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -610,231 +610,168 @@ lenses i.e. devices which can affect the pathes of beams - + + + - + - + - - - - - - - + - + - + - + - + - + - + - + - - - - - - - - - - + - + - + - - - - - - - + - + - - - - - - - + - + - + - + - + - - - - - - - - - - - - + - - + + - + - + - - - - - - - + - + - + - + - - + + - + - + - + - + - - - - - - - - - - + - + - + - - + + - + - + - - - - - - - - - - - - - + - + - + @@ -855,6 +792,7 @@ lenses i.e. devices which can affect the pathes of beams + diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_adf.nxdl.xml index 8d6649fda9..35bc42e65f 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_adf.nxdl.xml @@ -22,23 +22,6 @@ # For further information, see http://www.nexusformat.org --> - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - Base class method-specific for annular dark field imaging. @@ -50,7 +33,7 @@ For now the base class provides for scans for which the settings, binning, and energy resolution is the same for each scan point. - + Annulus inner (first value) and outer (second value) half angle. @@ -60,6 +43,4 @@ - diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index 60fa38e170..c3212627e8 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -215,9 +215,8 @@ pattern_available(NX_BOOLEAN): - If available and it is stored in an instance of an application definition - this field gives the path of an :ref:`NXimage_r_set_diff` - where the simulated pattern are stored. + If available and it is stored in an instance of an application definition this field gives + the path of an :ref:`NXimage_set` where the simulated pattern are stored. diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml index 43cde1ab9f..6397ac4868 100644 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -25,10 +25,6 @@ - Number of X-ray photon energy (bins), the fastest direction. @@ -160,14 +156,14 @@ but even a label InL is not physically not meaning ful enough, only with the kno that in an SEM and using an EDS detector, i.e. not a monochromating unit the energy resolution is not sufficient to resolve specific signals like e.g. separate certain lines therefore we use for now the--> - + Individual element-specific EDS/EDX/EDXS/SXES mapping A composition map is an image whose intensities for each pixel are the accumulated X-ray quanta *under the curve(s)* of a set of peaks. - These element-specific EDS maps are NXimage_r_set instances + These element-specific EDS maps are :ref:`NXimage_set` instances and need to be named with the name of the element from the element_names field. @@ -219,5 +215,4 @@ therefore we use for now the--> - diff --git a/contributed_definitions/NXem_img.nxdl.xml b/contributed_definitions/NXem_img.nxdl.xml index 79574ecaa4..159b342c1e 100644 --- a/contributed_definitions/NXem_img.nxdl.xml +++ b/contributed_definitions/NXem_img.nxdl.xml @@ -59,5 +59,4 @@ - diff --git a/contributed_definitions/NXem_method.nxdl.xml b/contributed_definitions/NXem_method.nxdl.xml index 502703f38e..b469980872 100644 --- a/contributed_definitions/NXem_method.nxdl.xml +++ b/contributed_definitions/NXem_method.nxdl.xml @@ -41,8 +41,7 @@ - - + diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml index 66282e001d..610fe885c1 100644 --- a/contributed_definitions/NXem_sim.nxdl.xml +++ b/contributed_definitions/NXem_sim.nxdl.xml @@ -55,6 +55,5 @@ abTEM and other simulation packages, TEMgym, etc.--> - diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml index 16958d8ec9..85f847e3da 100644 --- a/contributed_definitions/NXevent_data_em.nxdl.xml +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -147,9 +147,7 @@ follow-up modifications to support arriving at an improved :ref:`NXevent_data_em` base class. - - - + diff --git a/contributed_definitions/NXimage_c_set.nxdl.xml b/contributed_definitions/NXimage_c_set.nxdl.xml deleted file mode 100644 index c6837e47ab..0000000000 --- a/contributed_definitions/NXimage_c_set.nxdl.xml +++ /dev/null @@ -1,471 +0,0 @@ - - - - - - - - Number of images in the (hyper)stack. - - - - - Number of pixel per image in the slowest direction. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of images in reciprocal space. - - In practice, complex numbers are encoded via some formatted pair of real values. - Typically, fast Algorithms for computing Fourier Transformations (FFT) are - used to encode images in reciprocal (frequency) space. FFT libraries are used - for implementing the key functionalities of these mathematical operations. - - Different libraries use different representations and encoding of the - image computed. Details can be found in the respective sections of the - typical FFT libraries: - - * `FFTW by M. Frigo and S. G. Johnson <https://www.fftw.org/fftw3_doc/Tutorial.html#Tutorial>`_ - * `Intel MKL by the Intel Co. <https://www.intel.com/content/www/us/en/docs/onemkl/developer-reference-c/2023-0/fourier-transform-functions.html>`_ - * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ - - Users are strongly advised to inspect carefully which specific conventions - their library uses to be able to store and modify the implementation of their - code so that the serialized representations as it is detailed - here for NeXus matches with their intention. - - One- and two-dimensional FFTs should use the stack(NXdata) instances. - Three-dimensional FFTs should use the hyperstack(NXdata) instances. - - - - - One-dimensional image. - - - - Image intensity of the real part. - - - - - - - - Image intensity of the imaginary part. - - - - - - - - Magnitude of the image intensity. - - - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - - - Two-dimensional image. - - - - Image intensity of the real part. - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - - - Three-dimensional image. - - - - Image intensity of the real part. - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - Pixel coordinate center along k direction. - - - - - - - Coordinate along k direction. - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - - - Collection of one-dimensional images. - - - - Image intensity of the real part. - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - - - Collection of two-dimensional images. - - - - Image intensity of the real part. - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - - - Collection of three-dimensional images. - - - - Image intensity of the real part. - - - - - - - - - - - Image intensity of the imaginary part. - - - - - - - - - - - Magnitude of the image intensity. - - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along k direction. - - - - - - - Coordinate along k direction. - - - - - - Pixel coordinate center along j direction. - - - - - - - Coordinate along j direction. - - - - - - Pixel coordinate center along i direction. - - - - - - - Coordinate along i direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml deleted file mode 100644 index 78f01002b7..0000000000 --- a/contributed_definitions/NXimage_r_set.nxdl.xml +++ /dev/null @@ -1,333 +0,0 @@ - - - - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slowest direction. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Specialized base class container for reporting a set of images in real space. - - - - - One-dimensional image. - - - - Image intensity values. - - - - - - - - Pixel coordinate center along x direction. - - - - - - - Coordinate along x direction. - - - - - - - Two-dimensional image. - - - - Image intensity values. - - - - - - - - - Pixel coordinate center along y direction. - - - - - - - Coordinate along y direction. - - - - - - Pixel coordinate center along x direction. - - - - - - - Coordinate along x direction. - - - - - - - Three-dimensional image. - - - - Image intensity values. - - - - - - - - - - Pixel coordinate center along z direction. - - - - - - - Coordinate along z direction. - - - - - - Pixel coordinate center along y direction. - - - - - - - Coordinate along y direction. - - - - - - Pixel coordinate center along x direction. - - - - - - - Coordinate along x direction. - - - - - - - Collection of one-dimensional images. - - - - Image intensity values. - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along x direction. - - - - - - - Coordinate along x direction. - - - - - - - Collection of two-dimensional images. - - - - Image intensity values. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along y direction. - - - - - - - Coordinate along y direction. - - - - - - Pixel coordinate center along x direction. - - - - - - - Coordinate along x direction. - - - - - - - Collection of three-dimensional images. - - - - Image intensity values. - - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center along z direction. - - - - - - - Coordinate along z direction. - - - - - - Pixel coordinate center along y direction. - - - - - - - Coordinate along y direction. - - - - - - Pixel coordinate center along x direction. - - - - - - - Coordinate along x direction. - - - - - diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml deleted file mode 100644 index d0602017a7..0000000000 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ /dev/null @@ -1,179 +0,0 @@ - - - - - - - - Number of scanned points. Scan point may have none, one, or more pattern. - - - - - Number of diffraction pattern. - - - - - Number of pixel per pattern in the slow direction. - - - - - Number of pixel per pattern in the fast direction. - - - - - Base class specialized for reporting a cuboidal stack of diffraction pattern. - - Diffraction pattern, whether they were simulated or measured are the raw data - for computational workflows to characterize the phase and orientation - of crystalline regions in matter. - - Steps of post-processing the diffraction patterns should be documented using - method-specific specialized base classes. All eventual post-processing of - resulting orientation maps (2D or 3D) should be documented via :ref:`NXms_recon`. - - To implement an example how this base class can be used we focused in FAIRmat - on Kikuchi diffraction pattern here specifically the research community - of Electron Backscatter Diffraction (EBSD). - - For this reason, this base class and the :ref:`NXem_ebsd` base class extend the - work of `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ - (one of the developers of DREAM.3D) and the H5OINA public file format developed by - `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ with Oxford Instruments. - - Kikuchi pattern are typically collected with FIB/SEM microscopes, - for two- and three-dimensional orientation microscopy. - - For a detailed overview of these techniques see e.g. - - * `M. A. Groeber et al. <https://doi.org/10.1186/2193-9772-3-5>`_ - * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ - * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ - - Serial-sectioning demands a recurrent sequence of ion milling and measuring. - This suggests that each serial section is at least an own NXevent_data_em - instance. The three-dimensional characterization as such demands a computational - step where the maps for each serial section get cleaned, aligned, and registered - into an image stack. This image stack represents a digital model of the - inspected microstructural volume. Often this volume is called a (representative) - volume element (RVE). Several software packages exists for performing - these post-processing tasks. - - This example may inspire users of other types of diffraction methods. - - - - Category which type of diffraction pattern is reported. - - - - - - - - Collected diffraction pattern as an image stack. As raw and closest to the - first retrievable measured data as possible, i.e. do not use this - container to store already averaged, filtered or whatever post-processed - pattern unless these are generated unmodifiably in such manner by the - instrument given the way how the instrument and control software - was configured for your microscope session. - - - - Array which resolves the scan point to which each pattern belongs. - - Scan points are evaluated in sequence starting from scan point zero - until scan point n_sc - 1. Evaluating the cumulated of this array - decodes which pattern in intensity belongs to which scan point. - - Take an example with three scan points: The first scan point has one - pattern, the second has three pattern, the last scan point has no - pattern. In this case the scan_point_identifier are 0, 1, 1, 1. - The length of the scan_point_identifier array is four because four - pattern were measured in total. - - In most cases usually one pattern is averaged by the detector for - some amount of time and then reported as one pattern. - - - - - - - - Intensity of the diffraction pattern. - - - - - - - - - - Pattern intensity - - - - - - - Pattern are enumerated starting from 0 to n_p - 1. - - - - - - - Pattern identifier - - - - - - - diff --git a/contributed_definitions/NXimage_set.nxdl.xml b/contributed_definitions/NXimage_set.nxdl.xml index b2521608d7..c3f33bd683 100644 --- a/contributed_definitions/NXimage_set.nxdl.xml +++ b/contributed_definitions/NXimage_set.nxdl.xml @@ -22,59 +22,592 @@ # For further information, see http://www.nexusformat.org --> + - + - Number of images in the stack. + Number of images in the stack, for stacks the slowest direction. - + - Number of pixel per image in the slow direction. + Number of pixels per image in the slow direction (k equivalent to z). - + - Number of pixel per image in the fast direction. + Number of pixels per image in the fast direction (j equivalent to y). + + + + + Number of pixels per image in the fastest direction (i equivalent to x). - Base class for reporting a set of images. + Base class for reporting a set of images in real or reciprocal space. + + For images in reciprocal space in practice, complex numbers are encoded via some + formatted pair of real values. Typically, fast Algorithms for computing Fourier Transformations + (FFT) are used to encode images in reciprocal (frequency) space. FFT libraries are used + for implementing the key functionalities of these mathematical operations. + + Different libraries use different representations and encoding of the image computed. + Details can be found in the respective sections of the typical FFT libraries - This class provides a base vocabulary to be used for specialized :ref:`NXimage_set` - base classes like :ref:`NXimage_r_set` and :ref:`NXimage_c_set`. + * `FFTW by M. Frigo and S. G. Johnson <https://www.fftw.org/fftw3_doc/Tutorial.html#Tutorial>`_ + * `Intel MKL by the Intel Co. <https://www.intel.com/content/www/us/en/docs/onemkl/developer-reference-c/2023-0/fourier-transform-functions.html>`_ + * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ + + Users are strongly advised to inspect carefully which specific conventions + their library uses to be able to store and modify the implementation of their + code such that the serialized representations, as it is detailed here for NeXus, + matches. + + It is frequently the case that several images are combined using processing. In this case, + the number of images which are combined in a collection is not necessarily the same + for each collection. The NXimage_set base class addresses this logical distinction through + the notation of image_identifier and group_identifier. + That is image identifier are always counting from offset in increments of one. Each image + is an own entity. A group may contain no, or several such images. - Details how NXdata instance inside instance of (specialized) - :ref:`NXimage_set` were processed from the detector readings/raw data. + Details how NXdata instance were processed from detector readings/raw data. - Resolvable data artifact (e.g. filename) from which the all values in - the :ref:`NXdata` instances in this :ref:`NXimage_set` were loaded - during parsing. + Resolvable data artifact (e.g. filename) from which all values in the :ref:`NXdata` + instances in this :ref:`NXimage_set` were loaded during parsing. - Possibility to document from which specific other serialized resource - as the source pieces of information where processed when NeXus is used - as a semantic file format to serialize that information differently. + Possibility to document from which specific other serialized resource as the source + pieces of information were processed when using NeXus as a semantic file format + to serialize that information differently. The group in combination with an added field *absolute_path* therein adds context. + + + Reference to a location inside the artifact that points to the specific group of values + that were processed if the artifacts contains several groups of values and thus + further resolving of ambiguities is required. + + - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this :ref:`NXimage_set` instance. - - + Link or name of an :ref:`NXdetector` instance with which the data were collected. - + + + Program used for processing. + + + + + + The reference space in which the image set is defined. + + + + + + + + + One-dimensional image. + + + + Real part of the image intensity per pixel. + + + + + + + + Imaginary part of the image intensity per pixel. + + + + + + + + Image intensity as a complex number as an alternative + to real and imag fields if values are stored as interleaved + complex numbers. + + + + + + + + Magnitude of the image intensity. + + + + + + + + Pixel coordinate center along fastest direction. + + + + + + + Coordinate along fastest direction. + + + + + + + Two-dimensional image. + + + + Real part of the image intensity per pixel. + + + + + + + + + Imaginary part of the image intensity per pixel. + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + Image intensity as a complex number as an alternative + to real and imag fields if values are stored as interleaved + complex numbers. + + + + + + + + + Pixel coordinate center along fast direction. + + + + + + + Coordinate along fast direction. + + + + + + Pixel coordinate center along fastest direction. + + + + + + + Coordinate along fastest direction. + + + + + + + Three-dimensional image. + + + + Real part of the image intensity per pixel. + + + + + + + + + + Imaginary part of the image intensity per pixel. + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + Image intensity as a complex number as an alternative + to real and imag fields if values are stored as interleaved + complex numbers. + + + + + + + + + + Pixel coordinate center along slow direction. + + + + + + + Coordinate along slow direction. + + + + + + Pixel coordinate center along fast direction. + + + + + + + Coordinate along fast direction. + + + + + + Pixel coordinate center along fastest direction. + + + + + + + Coordinate along fastest direction. + + + + + + + Collection of one-dimensional images. + + + + Real part of the image intensity per pixel. + + + + + + + + + Imaginary part of the image intensity per pixel. + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + Image intensity as a complex number as an alternative + to real and imag fields if values are stored as interleaved + complex numbers. + + + + + + + + + Group identifier for each image. + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center along fastest direction. + + + + + + + Coordinate along fastest direction. + + + + + + + Collection of two-dimensional images. + + + + Real part of the image intensity per pixel. + + + + + + + + + + Imaginary part of the image intensity per pixel. + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + Image intensity as a complex number as an alternative + to real and imag fields if values are stored as interleaved + complex numbers. + + + + + + + + + + Group identifier for each image. + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center along fast direction. + + + + + + + Coordinate along fast direction. + + + + + + Pixel coordinate center along fastest direction. + + + + + + + Coordinate along fastest direction. + + + + + + + Collection of three-dimensional images. + + + + Real part of the image intensity per pixel. + + + + + + + + + + + Imaginary part of the image intensity per pixel. + + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + + Image intensity as a complex number as an alternative + to real and imag fields if values are stored as interleaved + complex numbers. + + + + + + + + + + + Group identifier for each image. + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center along slow direction. + + + + + + + Coordinate along slow direction. + + + + + + Pixel coordinate center along fast direction. + + + + + + + Coordinate along fast direction. + + + + + + Pixel coordinate center along fastest direction. + + + + + + + Coordinate along fastest direction. + + + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml index 55f2131302..9863b67b44 100644 --- a/contributed_definitions/NXspectrum_set.nxdl.xml +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -25,22 +25,22 @@ - Number of scan points. + Number of scan points (slowest dimension). - Number of pixel in the slowest direction. + Number of pixel in the slow direction. - Number of pixel in the slow direction. + Number of pixel in the fast direction. - Number of pixel in the fast direction. + Number of pixel in the fastest direction. @@ -66,16 +66,22 @@ NXspectrum_set to reduce redundant fields and specialized NXspectrum_r/c_set--> - Resolvable data artifact (e.g. filename) from which the all values in - the :ref:`NXdata` instances in this :ref:`NXspectrum_set` were - loaded during parsing. + Resolvable data artifact (e.g. filename) from which all values in the :ref:`NXdata` + instances in this :ref:`NXspectrum_set` were loaded during parsing. - Possibility to document from which specific other serialized resource - as the source pieces of information where processed when NeXus is used - as a semantic file format to serialize that information differently. + Possibility to document from which specific other serialized resource as the source + pieces of information were processed when using NeXus as a semantic file format + to serialize that information differently. - The group in combination with an add field *absolute_path* therein adds context. + The group in combination with an added field *absolute_path* therein adds context. + + + Reference to a location inside the artifact that points to the specific group of values + that were processed if the artifacts contains several groups of values and thus + further resolving of ambiguities is required. + + diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml index 3cf277d03a..7963f1520c 100644 --- a/contributed_definitions/nyaml/NXapm.yaml +++ b/contributed_definitions/nyaml/NXapm.yaml @@ -574,7 +574,7 @@ NXapm(NXobject): # NEW ISSUE: different algorithms used one could create a class for each reconstruction method # NEW ISSUE: make this rather an own subentry NXapm_ranging - initial_specimen(NXimage_r_set): + initial_specimen(NXimage_set): exists: recommended doc: | SEM or TEM image of the initial specimen i.e. @@ -583,12 +583,12 @@ NXapm(NXobject): \@signal(NX_CHAR): \@axes(NX_CHAR): \@AXISNAME_indices(NX_CHAR): - intensity(NX_NUMBER): - axis_y(NX_NUMBER): - dim: (n_y,) + real(NX_NUMBER): + axis_j(NX_NUMBER): + dim: (n_j,) \@long_name(NX_CHAR): axis_x(NX_NUMBER): - dim: (n_x,) + dim: (n_i,) \@long_name(NX_CHAR): # one could use a stack_threed(NXdata) to record # a time series of the specimen shape evolution diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index cb8c2cd0b2..0ea78f04f5 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -573,7 +573,7 @@ NXem(NXobject): exists: recommended end_time(NX_DATE_TIME): exists: recommended - (NXimage_r_set): + (NXimage_set): exists: [min, 0, max, infty] (NXprocess): source(NXserialized): @@ -582,116 +582,45 @@ NXem(NXobject): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): + absolute_path(NX_CHAR): + exists: recommended detector_identifier(NX_CHAR): + space(NX_CHAR): image_oned(NXdata): exists: optional \@signal(NX_CHAR): \@axes(NX_CHAR): \@AXISNAME_indices(NX_INT): title(NX_CHAR): - intensity(NX_NUMBER): - \@long_name(NX_CHAR): - axis_x(NX_NUMBER): - \@long_name(NX_CHAR): - image_twod(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): - title(NX_CHAR): - intensity(NX_NUMBER): - \@long_name(NX_CHAR): - axis_y(NX_NUMBER): - \@long_name(NX_CHAR): - axis_x(NX_NUMBER): - \@long_name(NX_CHAR): - image_threed(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): - title(NX_CHAR): - intensity(NX_NUMBER): - \@long_name(NX_CHAR): - axis_z(NX_NUMBER): - \@long_name(NX_CHAR): - axis_y(NX_NUMBER): - \@long_name(NX_CHAR): - axis_x(NX_NUMBER): - \@long_name(NX_CHAR): - stack_oned(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): - title(NX_CHAR): - intensity(NX_NUMBER): - \@long_name(NX_CHAR): - axis_image_identifier(NX_INT): - \@long_name(NX_CHAR): - axis_x(NX_NUMBER): + real(NX_NUMBER): \@long_name(NX_CHAR): - stack_twod(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): - title(NX_CHAR): - intensity(NX_NUMBER): + imag(NX_NUMBER): + exists: optional \@long_name(NX_CHAR): - axis_image_identifier(NX_INT): + magnitude(NX_NUMBER): + exists: optional \@long_name(NX_CHAR): - axis_y(NX_NUMBER): + intensity(NX_COMPLEX): + exists: optional \@long_name(NX_CHAR): - axis_x(NX_NUMBER): + axis_i(NX_NUMBER): \@long_name(NX_CHAR): - stack_threed(NXdata): + image_twod(NXdata): exists: optional \@signal(NX_CHAR): \@axes(NX_CHAR): \@AXISNAME_indices(NX_INT): title(NX_CHAR): - intensity(NX_NUMBER): - \@long_name(NX_CHAR): - axis_image_identifier(NX_INT): - \@long_name(NX_CHAR): - axis_z(NX_NUMBER): - \@long_name(NX_CHAR): - axis_y(NX_NUMBER): - \@long_name(NX_CHAR): - axis_x(NX_NUMBER): - \@long_name(NX_CHAR): - (NXimage_c_set): - exists: [min, 0, max, infty] - (NXprocess): - source(NXserialized): - exists: recommended - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - detector_identifier(NX_CHAR): - image_oned(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_CHAR): - title: real(NX_NUMBER): \@long_name(NX_CHAR): imag(NX_NUMBER): + exists: optional \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - image_twod(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_CHAR): - title: - real(NX_NUMBER): + magnitude(NX_NUMBER): + exists: optional \@long_name(NX_CHAR): - imag(NX_NUMBER): + intensity(NX_COMPLEX): + exists: optional \@long_name(NX_CHAR): axis_j(NX_NUMBER): \@long_name(NX_CHAR): @@ -701,11 +630,18 @@ NXem(NXobject): exists: optional \@signal(NX_CHAR): \@axes(NX_CHAR): - \@AXISNAME_indices(NX_CHAR): - title: + \@AXISNAME_indices(NX_INT): + title(NX_CHAR): real(NX_NUMBER): \@long_name(NX_CHAR): imag(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + magnitude(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + intensity(NX_COMPLEX): + exists: optional \@long_name(NX_CHAR): axis_k(NX_NUMBER): \@long_name(NX_CHAR): @@ -717,13 +653,23 @@ NXem(NXobject): exists: optional \@signal(NX_CHAR): \@axes(NX_CHAR): - \@AXISNAME_indices(NX_CHAR): - title: + \@AXISNAME_indices(NX_INT): + title(NX_CHAR): real(NX_NUMBER): \@long_name(NX_CHAR): imag(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + magnitude(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + intensity(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + group_identifier(NX_INT): + exists: optional \@long_name(NX_CHAR): - axis_image_identifier(NX_INT): + image_identifier(NX_INT): \@long_name(NX_CHAR): axis_i(NX_NUMBER): \@long_name(NX_CHAR): @@ -731,13 +677,23 @@ NXem(NXobject): exists: optional \@signal(NX_CHAR): \@axes(NX_CHAR): - \@AXISNAME_indices(NX_CHAR): - title: + \@AXISNAME_indices(NX_INT): + title(NX_CHAR): real(NX_NUMBER): \@long_name(NX_CHAR): imag(NX_NUMBER): + exists: optional \@long_name(NX_CHAR): - axis_image_identifier(NX_INT): + magnitude(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + intensity(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + group_identifier(NX_INT): + exists: optional + \@long_name(NX_CHAR): + image_identifier(NX_INT): \@long_name(NX_CHAR): axis_j(NX_NUMBER): \@long_name(NX_CHAR): @@ -747,13 +703,23 @@ NXem(NXobject): exists: optional \@signal(NX_CHAR): \@axes(NX_CHAR): - \@AXISNAME_indices(NX_CHAR): - title: + \@AXISNAME_indices(NX_INT): + title(NX_CHAR): real(NX_NUMBER): \@long_name(NX_CHAR): imag(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + magnitude(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + intensity(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + group_identifier(NX_INT): + exists: optional \@long_name(NX_CHAR): - axis_image_identifier(NX_INT): + image_identifier(NX_INT): \@long_name(NX_CHAR): axis_k(NX_NUMBER): \@long_name(NX_CHAR): @@ -770,6 +736,8 @@ NXem(NXobject): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): + absolute_path(NX_CHAR): + exists: recommended detector_identifier(NX_CHAR): spectrum_zerod(NXdata): exists: optional diff --git a/contributed_definitions/nyaml/NXem_adf.yaml b/contributed_definitions/nyaml/NXem_adf.yaml index 02a21e52cb..c64af34d45 100644 --- a/contributed_definitions/nyaml/NXem_adf.yaml +++ b/contributed_definitions/nyaml/NXem_adf.yaml @@ -9,20 +9,11 @@ doc: | For now the base class provides for scans for which the settings, binning, and energy resolution is the same for each scan point. -symbols: - n_images: | - Number of images in the stack. - n_y: | - Number of pixel per image in the slow direction. - n_x: | - Number of pixel per image in the fast direction. type: group NXem_adf(NXem_method): - (NXimage_r_set): + (NXimage_set): half_angle_interval(NX_NUMBER): doc: | Annulus inner (first value) and outer (second value) half angle. unit: NX_ANGLE dim: (2,) - # all information about annular dark field images is composed from - # the NXimage_r_set_em base class diff --git a/contributed_definitions/nyaml/NXem_ebsd.yaml b/contributed_definitions/nyaml/NXem_ebsd.yaml index 4a34650c4b..fc267416f7 100644 --- a/contributed_definitions/nyaml/NXem_ebsd.yaml +++ b/contributed_definitions/nyaml/NXem_ebsd.yaml @@ -169,9 +169,8 @@ NXem_ebsd(NXem_method): group as an instance of :ref:`NXem_sim`. \@depends_on(NX_CHAR): doc: | - If available and it is stored in an instance of an application definition - this field gives the path of an :ref:`NXimage_r_set_diff` - where the simulated pattern are stored. + If available and it is stored in an instance of an application definition this field gives + the path of an :ref:`NXimage_set` where the simulated pattern are stored. source(NXserialized): doc: | Reference (e.g. path and filename) to an existent digital resource which diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml index 8c3878d729..047b07e866 100644 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -13,10 +13,6 @@ doc: | # NEW ISSUE: use computational geometry to offer arbitrary scan pattern # NEW ISSUE: make the binning flexible per scan point symbols: - # n_p: Number of scan points - # n_z: Number of pixel along the z direction, the slowest direction - # n_y: Number of pixel along the y direction, the slow direction - # n_x: Number of pixel along the x direction, the fast direction n_photon_energy: | Number of X-ray photon energy (bins), the fastest direction. n_elements: | @@ -98,14 +94,14 @@ NXem_eds(NXem_method): # that in an SEM and using an EDS detector, i.e. not a monochromating unit the energy # resolution is not sufficient to resolve specific signals like e.g. separate certain lines # therefore we use for now the - (NXimage_r_set): + (NXimage_set): doc: | Individual element-specific EDS/EDX/EDXS/SXES mapping A composition map is an image whose intensities for each pixel are the accumulated X-ray quanta *under the curve(s)* of a set of peaks. - These element-specific EDS maps are NXimage_r_set instances + These element-specific EDS maps are :ref:`NXimage_set` instances and need to be named with the name of the element from the element_names field. @@ -141,4 +137,3 @@ NXem_eds(NXem_method): under peaks was factorized to display the joint intensity of the image. unit: NX_UNITLESS - # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml index 8c257d121a..57f9202445 100644 --- a/contributed_definitions/nyaml/NXem_img.yaml +++ b/contributed_definitions/nyaml/NXem_img.yaml @@ -22,4 +22,3 @@ NXem_img(NXem_method): doc: | Which imaging mode was used? enumeration: [secondary_electron, backscattered_electron] - IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml index 31ca4520f9..f4d7df4a14 100644 --- a/contributed_definitions/nyaml/NXem_method.yaml +++ b/contributed_definitions/nyaml/NXem_method.yaml @@ -16,7 +16,6 @@ NXem_method(NXobject): doc: | Details about processing steps. sequence_index(NX_INT): - (NXimage_r_set): - (NXimage_c_set): + (NXimage_set): (NXspectrum_set): # add links to relevant data diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml index 81fe20db1b..38492d66e2 100644 --- a/contributed_definitions/nyaml/NXem_sim.yaml +++ b/contributed_definitions/nyaml/NXem_sim.yaml @@ -31,4 +31,3 @@ NXem_sim(NXem_method): # sequence_index(N): (NXprogram): (NXcg_geodesic_mesh): - (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXevent_data_em.yaml b/contributed_definitions/nyaml/NXevent_data_em.yaml index 71df3c5982..b0a98d0388 100644 --- a/contributed_definitions/nyaml/NXevent_data_em.yaml +++ b/contributed_definitions/nyaml/NXevent_data_em.yaml @@ -118,9 +118,7 @@ NXevent_data_em(NXobject): The reason why in this base class the field event_type is nonetheless kept is to offer a place whereby practically users may enter data for follow-up modifications to support arriving at an improved :ref:`NXevent_data_em` base class. - (NXimage_r_set_diff): - (NXimage_r_set): - (NXimage_c_set): + (NXimage_set): (NXspectrum_set): em_lab(NXinstrument): doc: | diff --git a/contributed_definitions/nyaml/NXimage_c_set.yaml b/contributed_definitions/nyaml/NXimage_c_set.yaml deleted file mode 100644 index 303017ab1f..0000000000 --- a/contributed_definitions/nyaml/NXimage_c_set.yaml +++ /dev/null @@ -1,272 +0,0 @@ -category: base -doc: | - Specialized base class container for reporting a set of images in reciprocal space. - - In practice, complex numbers are encoded via some formatted pair of real values. - Typically, fast Algorithms for computing Fourier Transformations (FFT) are - used to encode images in reciprocal (frequency) space. FFT libraries are used - for implementing the key functionalities of these mathematical operations. - - Different libraries use different representations and encoding of the - image computed. Details can be found in the respective sections of the - typical FFT libraries: - - * `FFTW by M. Frigo and S. G. Johnson `_ - * `Intel MKL by the Intel Co. `_ - * `cuFFT by the NVidia Co. `_ - - Users are strongly advised to inspect carefully which specific conventions - their library uses to be able to store and modify the implementation of their - code so that the serialized representations as it is detailed - here for NeXus matches with their intention. - - One- and two-dimensional FFTs should use the stack(NXdata) instances. - Three-dimensional FFTs should use the hyperstack(NXdata) instances. -symbols: - n_images: | - Number of images in the (hyper)stack. - n_k: | - Number of pixel per image in the slowest direction. - n_j: | - Number of pixel per image in the slow direction. - n_i: | - Number of pixel per image in the fast direction. -type: group -NXimage_c_set(NXimage_set): - # details about the FFT library used could for instance be stored in the - # NXprocess group which the NXimage_c_set base class can borrow from its - # NXimage_set parent base class - # process information are composable from the NXimage_set base class - image_oned(NXdata): - doc: | - One-dimensional image. - real(NX_NUMBER): - doc: | - Image intensity of the real part. - unit: NX_UNITLESS - dim: (n_i,) - imag(NX_NUMBER): - doc: | - Image intensity of the imaginary part. - unit: NX_UNITLESS - dim: (n_i,) - magnitude(NX_NUMBER): - doc: | - Magnitude of the image intensity. - unit: NX_UNITLESS - dim: (n_i) - axis_i(NX_NUMBER): - doc: | - Pixel coordinate center along i direction. - unit: NX_ANY # NX_RECIPROCAL_LENGTH - dim: (n_i,) - \@long_name(NX_CHAR): - doc: | - Coordinate along i direction. - - image_twod(NXdata): - doc: | - Two-dimensional image. - real(NX_NUMBER): - doc: | - Image intensity of the real part. - unit: NX_UNITLESS - dim: (n_j, n_i) - imag(NX_NUMBER): - doc: | - Image intensity of the imaginary part. - unit: NX_UNITLESS - dim: (n_j, n_i) - magnitude(NX_NUMBER): - doc: | - Magnitude of the image intensity. - unit: NX_UNITLESS - dim: (n_j, n_i) - axis_j(NX_NUMBER): - doc: | - Pixel coordinate center along j direction. - unit: NX_ANY # NX_RECIPROCAL_LENGTH - dim: (n_j,) - \@long_name(NX_CHAR): - doc: | - Coordinate along j direction. - axis_i(NX_NUMBER): - doc: | - Pixel coordinate center along i direction. - unit: NX_ANY # NX_RECIPROCAL_LENGTH - dim: (n_i,) - \@long_name(NX_CHAR): - doc: | - Coordinate along i direction. - - image_threed(NXdata): - doc: | - Three-dimensional image. - real(NX_NUMBER): - doc: | - Image intensity of the real part. - unit: NX_UNITLESS - dim: (n_k, n_j, n_i) - imag(NX_NUMBER): - doc: | - Image intensity of the imaginary part. - unit: NX_UNITLESS - dim: (n_k, n_j, n_i) - magnitude(NX_NUMBER): - doc: | - Magnitude of the image intensity. - unit: NX_UNITLESS - dim: (n_k, n_j, n_i) - axis_k(NX_NUMBER): - doc: | - Pixel coordinate center along k direction. - unit: NX_ANY # NX_RECIPROCAL_LENGTH - dim: (n_k,) - \@long_name(NX_CHAR): - doc: | - Coordinate along k direction. - axis_j(NX_NUMBER): - doc: | - Pixel coordinate center along j direction. - unit: NX_ANY - dim: (n_j,) - \@long_name(NX_CHAR): - doc: | - Coordinate along j direction. - axis_i(NX_NUMBER): - doc: | - Pixel coordinate center along i direction. - unit: NX_ANY - dim: (n_i,) - \@long_name(NX_CHAR): - doc: | - Coordinate along i direction. - - stack_oned(NXdata): - doc: | - Collection of one-dimensional images. - real(NX_NUMBER): - doc: | - Image intensity of the real part. - unit: NX_UNITLESS - dim: (n_images, n_i) - imag(NX_NUMBER): - doc: | - Image intensity of the imaginary part. - unit: NX_UNITLESS - dim: (n_images, n_i) - magnitude(NX_NUMBER): - doc: | - Magnitude of the image intensity. - unit: NX_UNITLESS - dim: (n_images, n_i) - axis_image_identifier(NX_INT): - doc: | - Image identifier - unit: NX_UNITLESS - dim: (n_images,) - \@long_name(NX_CHAR): - doc: | - Image identifier. - axis_i(NX_NUMBER): - doc: | - Pixel coordinate center along i direction. - unit: NX_ANY - dim: (n_i,) - \@long_name(NX_CHAR): - doc: | - Coordinate along i direction. - - stack_twod(NXdata): - doc: | - Collection of two-dimensional images. - real(NX_NUMBER): - doc: | - Image intensity of the real part. - unit: NX_UNITLESS - dim: (n_images, n_j, n_i) - imag(NX_NUMBER): - doc: | - Image intensity of the imaginary part. - unit: NX_UNITLESS - dim: (n_images, n_j, n_i) - magnitude(NX_NUMBER): - doc: | - Magnitude of the image intensity. - unit: NX_UNITLESS - dim: (n_images, n_j, n_i) - axis_image_identifier(NX_INT): - doc: | - Image identifier - unit: NX_UNITLESS - dim: (n_images,) - \@long_name(NX_CHAR): - doc: | - Image identifier. - axis_j(NX_NUMBER): - doc: | - Pixel coordinate center along j direction. - unit: NX_ANY - dim: (n_j,) - \@long_name(NX_CHAR): - doc: | - Coordinate along j direction. - axis_i(NX_NUMBER): - doc: | - Pixel coordinate center along i direction. - unit: NX_ANY - dim: (n_i,) - \@long_name(NX_CHAR): - doc: | - Coordinate along i direction. - - stack_threed(NXdata): - doc: | - Collection of three-dimensional images. - real(NX_NUMBER): - doc: | - Image intensity of the real part. - unit: NX_UNITLESS - dim: (n_images, n_k, n_j, n_i) - imag(NX_NUMBER): - doc: | - Image intensity of the imaginary part. - unit: NX_UNITLESS - dim: (n_images, n_k, n_j, n_i) - magnitude(NX_NUMBER): - doc: | - Magnitude of the image intensity. - unit: NX_UNITLESS - dim: (n_images, n_k, n_j, n_i) - axis_image_identifier(NX_INT): - doc: | - Image identifier - unit: NX_UNITLESS - dim: (n_images,) - \@long_name(NX_CHAR): - doc: | - Image identifier. - axis_k(NX_NUMBER): - doc: | - Pixel coordinate center along k direction. - unit: NX_ANY - dim: (n_k,) - \@long_name(NX_CHAR): - doc: | - Coordinate along k direction. - axis_j(NX_NUMBER): - doc: | - Pixel coordinate center along j direction. - unit: NX_ANY - dim: (n_j,) - \@long_name(NX_CHAR): - doc: | - Coordinate along j direction. - axis_i(NX_NUMBER): - doc: | - Pixel coordinate center along i direction. - unit: NX_ANY - dim: (n_i,) - \@long_name(NX_CHAR): - doc: | - Coordinate along i direction. diff --git a/contributed_definitions/nyaml/NXimage_r_set.yaml b/contributed_definitions/nyaml/NXimage_r_set.yaml deleted file mode 100644 index 5c63988c65..0000000000 --- a/contributed_definitions/nyaml/NXimage_r_set.yaml +++ /dev/null @@ -1,188 +0,0 @@ -category: base -doc: | - Specialized base class container for reporting a set of images in real space. -symbols: - n_images: | - Number of images in the stack. - n_z: | - Number of pixel per image in the slowest direction. - n_y: | - Number of pixel per image in the slow direction. - n_x: | - Number of pixel per image in the fast direction. -type: group -NXimage_r_set(NXimage_set): - # process information are composable from the NXimage_set base class - image_oned(NXdata): - doc: | - One-dimensional image. - intensity(NX_NUMBER): - doc: | - Image intensity values. - unit: NX_UNITLESS - dim: (n_x,) - axis_x(NX_NUMBER): - doc: | - Pixel coordinate center along x direction. - unit: NX_LENGTH - dim: (n_x,) - \@long_name(NX_CHAR): - doc: | - Coordinate along x direction. - - image_twod(NXdata): - doc: | - Two-dimensional image. - intensity(NX_NUMBER): - doc: | - Image intensity values. - unit: NX_UNITLESS - dim: (n_y, n_x) - axis_y(NX_NUMBER): - doc: | - Pixel coordinate center along y direction. - unit: NX_LENGTH - dim: (n_y,) - \@long_name(NX_CHAR): - doc: | - Coordinate along y direction. - axis_x(NX_NUMBER): - doc: | - Pixel coordinate center along x direction. - unit: NX_LENGTH - dim: (n_x,) - \@long_name(NX_CHAR): - doc: | - Coordinate along x direction. - - image_threed(NXdata): - doc: | - Three-dimensional image. - intensity(NX_NUMBER): - doc: | - Image intensity values. - unit: NX_UNITLESS - dim: (n_z, n_y, n_x) - axis_z(NX_NUMBER): - doc: | - Pixel coordinate center along z direction. - unit: NX_LENGTH - dim: (n_z,) - \@long_name(NX_CHAR): - doc: | - Coordinate along z direction. - axis_y(NX_NUMBER): - doc: | - Pixel coordinate center along y direction. - unit: NX_LENGTH - dim: (n_y,) - \@long_name(NX_CHAR): - doc: | - Coordinate along y direction. - axis_x(NX_NUMBER): - doc: | - Pixel coordinate center along x direction. - unit: NX_LENGTH - dim: (n_x,) - \@long_name(NX_CHAR): - doc: | - Coordinate along x direction. - - stack_oned(NXdata): - doc: | - Collection of one-dimensional images. - intensity(NX_NUMBER): - doc: | - Image intensity values. - unit: NX_UNITLESS - dim: (n_images, n_x) - axis_image_identifier(NX_INT): - doc: | - Image identifier - unit: NX_UNITLESS - dim: (n_images,) - \@long_name(NX_CHAR): - doc: | - Image identifier. - axis_x(NX_NUMBER): - doc: | - Pixel coordinate center along x direction. - unit: NX_LENGTH - dim: (n_x,) - \@long_name(NX_CHAR): - doc: | - Coordinate along x direction. - - stack_twod(NXdata): - doc: | - Collection of two-dimensional images. - intensity(NX_NUMBER): - doc: | - Image intensity values. - unit: NX_UNITLESS - dim: (n_images, n_y, n_x) - axis_image_identifier(NX_INT): - doc: | - Image identifier - unit: NX_UNITLESS - dim: (n_images,) - \@long_name(NX_CHAR): - doc: | - Image identifier. - axis_y(NX_NUMBER): - doc: | - Pixel coordinate center along y direction. - unit: NX_LENGTH - dim: (n_y,) - \@long_name(NX_CHAR): - doc: | - Coordinate along y direction. - axis_x(NX_NUMBER): - doc: | - Pixel coordinate center along x direction. - unit: NX_LENGTH - dim: (n_x,) - \@long_name(NX_CHAR): - doc: | - Coordinate along x direction. - - stack_threed(NXdata): - doc: | - Collection of three-dimensional images. - intensity(NX_NUMBER): - doc: | - Image intensity values. - unit: NX_UNITLESS - dim: (n_images, n_z, n_y, n_x) - axis_image_identifier(NX_INT): - doc: | - Image identifier - unit: NX_UNITLESS - dim: (n_images,) - \@long_name(NX_CHAR): - doc: | - Image identifier. - axis_z(NX_NUMBER): - doc: | - Pixel coordinate center along z direction. - unit: NX_LENGTH - dim: (n_z,) - \@long_name(NX_CHAR): - doc: | - Coordinate along z direction. - axis_y(NX_NUMBER): - doc: | - Pixel coordinate center along y direction. - unit: NX_LENGTH - dim: (n_y,) - \@long_name(NX_CHAR): - doc: | - Coordinate along y direction. - axis_x(NX_NUMBER): - doc: | - Pixel coordinate center along x direction. - unit: NX_LENGTH - dim: (n_x,) - \@long_name(NX_CHAR): - doc: | - Coordinate along x direction. diff --git a/contributed_definitions/nyaml/NXimage_r_set_diff.yaml b/contributed_definitions/nyaml/NXimage_r_set_diff.yaml deleted file mode 100644 index 5a0e27e283..0000000000 --- a/contributed_definitions/nyaml/NXimage_r_set_diff.yaml +++ /dev/null @@ -1,123 +0,0 @@ -category: base -doc: | - Base class specialized for reporting a cuboidal stack of diffraction pattern. - - Diffraction pattern, whether they were simulated or measured are the raw data - for computational workflows to characterize the phase and orientation - of crystalline regions in matter. - - Steps of post-processing the diffraction patterns should be documented using - method-specific specialized base classes. All eventual post-processing of - resulting orientation maps (2D or 3D) should be documented via :ref:`NXms_recon`. - - To implement an example how this base class can be used we focused in FAIRmat - on Kikuchi diffraction pattern here specifically the research community - of Electron Backscatter Diffraction (EBSD). - - For this reason, this base class and the :ref:`NXem_ebsd` base class extend the - work of `M. A. Jackson et al. `_ - (one of the developers of DREAM.3D) and the H5OINA public file format developed by - `P. Pinard et al. `_ with Oxford Instruments. - - Kikuchi pattern are typically collected with FIB/SEM microscopes, - for two- and three-dimensional orientation microscopy. - - For a detailed overview of these techniques see e.g. - - * `M. A. Groeber et al. `_ - * `A. J. Schwartz et al. `_ - * `P. A. Rottman et al. `_ - - Serial-sectioning demands a recurrent sequence of ion milling and measuring. - This suggests that each serial section is at least an own NXevent_data_em - instance. The three-dimensional characterization as such demands a computational - step where the maps for each serial section get cleaned, aligned, and registered - into an image stack. This image stack represents a digital model of the - inspected microstructural volume. Often this volume is called a (representative) - volume element (RVE). Several software packages exists for performing - these post-processing tasks. - - This example may inspire users of other types of diffraction methods. -symbols: - n_sc: | - Number of scanned points. Scan point may have none, one, or more pattern. - n_p: | - Number of diffraction pattern. - n_y: | - Number of pixel per pattern in the slow direction. - n_x: | - Number of pixel per pattern in the fast direction. -type: group -NXimage_r_set_diff(NXimage_r_set): - pattern_type(NX_CHAR): - doc: | - Category which type of diffraction pattern is reported. - enumeration: [kikuchi] - stack(NXdata): - doc: | - Collected diffraction pattern as an image stack. As raw and closest to the - first retrievable measured data as possible, i.e. do not use this - container to store already averaged, filtered or whatever post-processed - pattern unless these are generated unmodifiably in such manner by the - instrument given the way how the instrument and control software - was configured for your microscope session. - scan_point_identifier(NX_INT): - doc: | - Array which resolves the scan point to which each pattern belongs. - - Scan points are evaluated in sequence starting from scan point zero - until scan point n_sc - 1. Evaluating the cumulated of this array - decodes which pattern in intensity belongs to which scan point. - - Take an example with three scan points: The first scan point has one - pattern, the second has three pattern, the last scan point has no - pattern. In this case the scan_point_identifier are 0, 1, 1, 1. - The length of the scan_point_identifier array is four because four - pattern were measured in total. - - In most cases usually one pattern is averaged by the detector for - some amount of time and then reported as one pattern. - unit: NX_UNITLESS - dim: (n_p,) - intensity(NX_NUMBER): - doc: | - Intensity of the diffraction pattern. - unit: NX_UNITLESS - dim: (n_p, n_y, n_x) - # n_p fast 2, n_y faster 1, n_x fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name(NX_CHAR): - doc: | - Pattern intensity - # \@signal: intensity - # \@axes: [pattern_identifier, ypos, xpos] - # \@xpos_indices: 0 - # \@ypos_indices: 1 - # \@pattern_identifier_indices: 2 - pattern_identifier(NX_INT): - doc: | - Pattern are enumerated starting from 0 to n_p - 1. - unit: NX_UNITLESS - dim: (n_p,) - \@long_name(NX_CHAR): - doc: | - Pattern identifier - # the following fields are taken from the NXimage_r_set base class - # axis_y(R): - # axis_x(R): - -# If we envision a (knowledge) graph for EBSD it consists of individual sub-graphs -# which convey information about the specimen preparation, the measurement of -# the specimen in the electron microscope, the indexing of the collected -# Kikuchi pattern stack, eventual post-processing of the indexed orientation -# images via similarity grouping algorithms to yield (grains, texture). -# Conceptually, these post-processing steps are most frequently serving -# the idea how can one reconstruct so-called microstructural features -# (grains, phases, interfaces) to infer material properties. -# In practice this calls for workflows which quantify correlations between -# the spatial arrangement of the microstructural features, the individual -# (thermodynamic, chemo-mechanical) properties of the features with the -# properties of materials at a coarser scale. -# With NXem and related NXms base classes we propose a covering -# and general solution how to handle such (meta)data with NeXus. diff --git a/contributed_definitions/nyaml/NXimage_set.yaml b/contributed_definitions/nyaml/NXimage_set.yaml index 48cbedb1f5..dbaaf04da1 100644 --- a/contributed_definitions/nyaml/NXimage_set.yaml +++ b/contributed_definitions/nyaml/NXimage_set.yaml @@ -1,38 +1,367 @@ category: base -doc: | - Base class for reporting a set of images. +doc: +- | + Base class for reporting a set of images in real or reciprocal space. +- | + For images in reciprocal space in practice, complex numbers are encoded via some + formatted pair of real values. Typically, fast Algorithms for computing Fourier Transformations + (FFT) are used to encode images in reciprocal (frequency) space. FFT libraries are used + for implementing the key functionalities of these mathematical operations. - This class provides a base vocabulary to be used for specialized :ref:`NXimage_set` - base classes like :ref:`NXimage_r_set` and :ref:`NXimage_c_set`. + Different libraries use different representations and encoding of the image computed. + Details can be found in the respective sections of the typical FFT libraries + + * `FFTW by M. Frigo and S. G. Johnson `_ + * `Intel MKL by the Intel Co. `_ + * `cuFFT by the NVidia Co. `_ + + Users are strongly advised to inspect carefully which specific conventions + their library uses to be able to store and modify the implementation of their + code such that the serialized representations, as it is detailed here for NeXus, + matches. + + It is frequently the case that several images are combined using processing. In this case, + the number of images which are combined in a collection is not necessarily the same + for each collection. The NXimage_set base class addresses this logical distinction through + the notation of image_identifier and group_identifier. + That is image identifier are always counting from offset in increments of one. Each image + is an own entity. A group may contain no, or several such images. +# for details about NXimage_r_set_diff see +# https://github.com/FAIRmat-NFDI/nexus_definitions/commit/0682943baaef54d4a6386b5433f9721af6d3d81b +# and here contributed_definitions/NXimage_r_set_diff.nxdl.xml symbols: - n_images: | - Number of images in the stack. - n_y: | - Number of pixel per image in the slow direction. - n_x: | - Number of pixel per image in the fast direction. + n_img: | + Number of images in the stack, for stacks the slowest direction. + n_k: | + Number of pixels per image in the slow direction (k equivalent to z). + n_j: | + Number of pixels per image in the fast direction (j equivalent to y). + n_i: | + Number of pixels per image in the fastest direction (i equivalent to x). type: group NXimage_set(NXobject): (NXprocess): doc: | - Details how NXdata instance inside instance of (specialized) - :ref:`NXimage_set` were processed from the detector readings/raw data. + Details how NXdata instance were processed from detector readings/raw data. source(NXserialized): - doc: | - Resolvable data artifact (e.g. filename) from which the all values in - the :ref:`NXdata` instances in this :ref:`NXimage_set` were loaded - during parsing. - - Possibility to document from which specific other serialized resource - as the source pieces of information where processed when NeXus is used - as a semantic file format to serialize that information differently. + doc: + - | + Resolvable data artifact (e.g. filename) from which all values in the :ref:`NXdata` + instances in this :ref:`NXimage_set` were loaded during parsing. + - | + Possibility to document from which specific other serialized resource as the source + pieces of information were processed when using NeXus as a semantic file format + to serialize that information differently. The group in combination with an added field *absolute_path* therein adds context. - mode(NX_CHAR): - doc: | - Imaging (data collection) mode of the instrument during acquisition - of the data in this :ref:`NXimage_set` instance. + absolute_path(NX_CHAR): + doc: + - | + Reference to a location inside the artifact that points to the specific group of values + that were processed if the artifacts contains several groups of values and thus + further resolving of ambiguities is required. + # mode(NX_CHAR): + # doc: | + # Imaging (data collection) mode of the instrument during acquisition. detector_identifier(NX_CHAR): doc: | Link or name of an :ref:`NXdetector` instance with which the data were collected. (NXprogram): + doc: | + Program used for processing. + space(NX_CHAR): + doc: + - | + The reference space in which the image set is defined. + enumeration: [real, reciprocal] + + image_oned(NXdata): + doc: | + One-dimensional image. + real(NX_NUMBER): + doc: | + Real part of the image intensity per pixel. + unit: NX_UNITLESS + dim: (n_i,) + imag(NX_NUMBER): + doc: | + Imaginary part of the image intensity per pixel. + unit: NX_UNITLESS + dim: (n_i,) + intensity(NX_COMPLEX): + doc: | + Image intensity as a complex number as an alternative + to real and imag fields if values are stored as interleaved + complex numbers. + unit: NX_UNITLESS + dim: (n_i,) + magnitude(NX_NUMBER): + doc: | + Magnitude of the image intensity. + unit: NX_UNITLESS + dim: (n_i,) + axis_i(NX_NUMBER): + doc: | + Pixel coordinate center along fastest direction. + unit: NX_LENGTH + dim: (n_i,) + \@long_name(NX_CHAR): + doc: | + Coordinate along fastest direction. + + image_twod(NXdata): + doc: | + Two-dimensional image. + real(NX_NUMBER): + doc: | + Real part of the image intensity per pixel. + unit: NX_UNITLESS + dim: (n_j, n_i) + imag(NX_NUMBER): + doc: | + Imaginary part of the image intensity per pixel. + unit: NX_UNITLESS + dim: (n_j, n_i) + magnitude(NX_NUMBER): + doc: | + Magnitude of the image intensity. + unit: NX_UNITLESS + dim: (n_j, n_i) + intensity(NX_COMPLEX): + doc: | + Image intensity as a complex number as an alternative + to real and imag fields if values are stored as interleaved + complex numbers. + unit: NX_UNITLESS + dim: (n_j, n_i) + axis_j(NX_NUMBER): + doc: | + Pixel coordinate center along fast direction. + unit: NX_LENGTH + dim: (n_j,) + \@long_name(NX_CHAR): + doc: | + Coordinate along fast direction. + axis_i(NX_NUMBER): + doc: | + Pixel coordinate center along fastest direction. + unit: NX_LENGTH + dim: (n_i,) + \@long_name(NX_CHAR): + doc: | + Coordinate along fastest direction. + + image_threed(NXdata): + doc: | + Three-dimensional image. + real(NX_NUMBER): + doc: | + Real part of the image intensity per pixel. + unit: NX_UNITLESS + dim: (n_k, n_j, n_i) + imag(NX_NUMBER): + doc: | + Imaginary part of the image intensity per pixel. + unit: NX_UNITLESS + dim: (n_k, n_j, n_i) + magnitude(NX_NUMBER): + doc: | + Magnitude of the image intensity. + unit: NX_UNITLESS + dim: (n_k, n_j, n_i) + intensity(NX_COMPLEX): + doc: | + Image intensity as a complex number as an alternative + to real and imag fields if values are stored as interleaved + complex numbers. + unit: NX_UNITLESS + dim: (n_k, n_j, n_i) + axis_k(NX_NUMBER): + doc: | + Pixel coordinate center along slow direction. + unit: NX_LENGTH + dim: (n_k,) + \@long_name(NX_CHAR): + doc: | + Coordinate along slow direction. + axis_j(NX_NUMBER): + doc: | + Pixel coordinate center along fast direction. + unit: NX_LENGTH + dim: (n_j,) + \@long_name(NX_CHAR): + doc: | + Coordinate along fast direction. + axis_i(NX_NUMBER): + doc: | + Pixel coordinate center along fastest direction. + unit: NX_LENGTH + dim: (n_i,) + \@long_name(NX_CHAR): + doc: | + Coordinate along fastest direction. + + stack_oned(NXdata): + doc: | + Collection of one-dimensional images. + real(NX_NUMBER): + doc: | + Real part of the image intensity per pixel. + unit: NX_UNITLESS + dim: (n_img, n_i) + imag(NX_NUMBER): + doc: | + Imaginary part of the image intensity per pixel. + unit: NX_UNITLESS + dim: (n_img, n_i) + magnitude(NX_NUMBER): + doc: | + Magnitude of the image intensity. + unit: NX_UNITLESS + dim: (n_img, n_i) + intensity(NX_COMPLEX): + doc: | + Image intensity as a complex number as an alternative + to real and imag fields if values are stored as interleaved + complex numbers. + unit: NX_UNITLESS + dim: (n_img, n_i) + group_identifier(NX_INT): + doc: | + Group identifier for each image. + unit: NX_UNITLESS + dim: (n_img,) + image_identifier(NX_INT): + doc: | + Image identifier + unit: NX_UNITLESS + dim: (n_img,) + \@long_name(NX_CHAR): + doc: | + Image identifier. + axis_i(NX_NUMBER): + doc: | + Pixel coordinate center along fastest direction. + unit: NX_LENGTH + dim: (n_i,) + \@long_name(NX_CHAR): + doc: | + Coordinate along fastest direction. + + stack_twod(NXdata): + doc: | + Collection of two-dimensional images. + real(NX_NUMBER): + doc: | + Real part of the image intensity per pixel. + unit: NX_UNITLESS + dim: (n_img, n_j, n_i) + imag(NX_NUMBER): + doc: | + Imaginary part of the image intensity per pixel. + unit: NX_UNITLESS + dim: (n_img, n_j, n_i) + magnitude(NX_NUMBER): + doc: | + Magnitude of the image intensity. + unit: NX_UNITLESS + dim: (n_img, n_j, n_i) + intensity(NX_COMPLEX): + doc: | + Image intensity as a complex number as an alternative + to real and imag fields if values are stored as interleaved + complex numbers. + unit: NX_UNITLESS + dim: (n_img, n_j, n_i) + group_identifier(NX_INT): + doc: | + Group identifier for each image. + unit: NX_UNITLESS + dim: (n_img,) + image_identifier(NX_INT): + doc: | + Image identifier + unit: NX_UNITLESS + dim: (n_img,) + \@long_name(NX_CHAR): + doc: | + Image identifier. + axis_y(NX_NUMBER): + doc: | + Pixel coordinate center along fast direction. + unit: NX_LENGTH + dim: (n_j,) + \@long_name(NX_CHAR): + doc: | + Coordinate along fast direction. + axis_i(NX_NUMBER): + doc: | + Pixel coordinate center along fastest direction. + unit: NX_LENGTH + dim: (n_i,) + \@long_name(NX_CHAR): + doc: | + Coordinate along fastest direction. + + stack_threed(NXdata): + doc: | + Collection of three-dimensional images. + real(NX_NUMBER): + doc: | + Real part of the image intensity per pixel. + unit: NX_UNITLESS + dim: (n_img, n_k, n_j, n_i) + imag(NX_NUMBER): + doc: | + Imaginary part of the image intensity per pixel. + unit: NX_UNITLESS + dim: (n_img, n_k, n_j, n_i) + magnitude(NX_NUMBER): + doc: | + Magnitude of the image intensity. + unit: NX_UNITLESS + dim: (n_img, n_k, n_j, n_i) + intensity(NX_COMPLEX): + doc: | + Image intensity as a complex number as an alternative + to real and imag fields if values are stored as interleaved + complex numbers. + unit: NX_UNITLESS + dim: (n_img, n_k, n_j, n_i) + group_identifier(NX_INT): + doc: | + Group identifier for each image. + unit: NX_UNITLESS + dim: (n_img,) + image_identifier(NX_INT): + doc: | + Image identifier + unit: NX_UNITLESS + dim: (n_img,) + \@long_name(NX_CHAR): + doc: | + Image identifier. + axis_k(NX_NUMBER): + doc: | + Pixel coordinate center along slow direction. + unit: NX_LENGTH + dim: (n_k,) + \@long_name(NX_CHAR): + doc: | + Coordinate along slow direction. + axis_j(NX_NUMBER): + doc: | + Pixel coordinate center along fast direction. + unit: NX_LENGTH + dim: (n_j,) + \@long_name(NX_CHAR): + doc: | + Coordinate along fast direction. + axis_i(NX_NUMBER): + doc: | + Pixel coordinate center along fastest direction. + unit: NX_LENGTH + dim: (n_i,) + \@long_name(NX_CHAR): + doc: | + Coordinate along fastest direction. diff --git a/contributed_definitions/nyaml/NXspectrum_set.yaml b/contributed_definitions/nyaml/NXspectrum_set.yaml index 5cee48ffea..1f5284889b 100644 --- a/contributed_definitions/nyaml/NXspectrum_set.yaml +++ b/contributed_definitions/nyaml/NXspectrum_set.yaml @@ -8,13 +8,13 @@ doc: | For randomly or dissimilarly spaced scan points use collection instead. symbols: n_p: | - Number of scan points. + Number of scan points (slowest dimension). n_z: | - Number of pixel in the slowest direction. - n_y: | Number of pixel in the slow direction. - n_x: | + n_y: | Number of pixel in the fast direction. + n_x: | + Number of pixel in the fastest direction. n_energy: | Number of energy bins. type: group @@ -26,16 +26,22 @@ NXspectrum_set(NXobject): doc: | Details how spectra were processed from the detector readings. source(NXserialized): - doc: | - Resolvable data artifact (e.g. filename) from which the all values in - the :ref:`NXdata` instances in this :ref:`NXspectrum_set` were - loaded during parsing. - - Possibility to document from which specific other serialized resource - as the source pieces of information where processed when NeXus is used - as a semantic file format to serialize that information differently. + doc: + - | + Resolvable data artifact (e.g. filename) from which all values in the :ref:`NXdata` + instances in this :ref:`NXspectrum_set` were loaded during parsing. + - | + Possibility to document from which specific other serialized resource as the source + pieces of information were processed when using NeXus as a semantic file format + to serialize that information differently. - The group in combination with an add field *absolute_path* therein adds context. + The group in combination with an added field *absolute_path* therein adds context. + absolute_path(NX_CHAR): + doc: + - | + Reference to a location inside the artifact that points to the specific group of values + that were processed if the artifacts contains several groups of values and thus + further resolving of ambiguities is required. mode(NX_CHAR): doc: | Imaging (data collection) mode of the instrument during acquisition diff --git a/dev_tools/tests/test_nxdl_utils.py b/dev_tools/tests/test_nxdl_utils.py index 8618271d31..19eccd7e85 100644 --- a/dev_tools/tests/test_nxdl_utils.py +++ b/dev_tools/tests/test_nxdl_utils.py @@ -78,19 +78,19 @@ def test_get_node_at_nxdl_path(): assert node.attrib["type"] == "NXem_msr" node = nexus.get_node_at_nxdl_path( - "/ENTRY/measurement/EVENT_DATA_EM_SET/EVENT_DATA_EM/IMAGE_C_SET/image_threed", + "/ENTRY/measurement/EVENT_DATA_EM_SET/EVENT_DATA_EM/IMAGE_SET/image_threed", elem=elem, ) assert node.attrib["type"] == "NXdata" node = nexus.get_node_at_nxdl_path( - "/ENTRY/measurement/EVENT_DATA_EM_SET/EVENT_DATA_EM/IMAGE_C_SET/image_threed/AXISNAME_indices", + "/ENTRY/measurement/EVENT_DATA_EM_SET/EVENT_DATA_EM/IMAGE_SET/image_threed/AXISNAME_indices", elem=elem, ) assert node.attrib["name"] == "AXISNAME_indices" node = nexus.get_node_at_nxdl_path( - "/ENTRY/measurement/EVENT_DATA_EM_SET/EVENT_DATA_EM/IMAGE_C_SET/image_threed/axis_j", + "/ENTRY/measurement/EVENT_DATA_EM_SET/EVENT_DATA_EM/IMAGE_SET/image_threed/axis_j", elem=elem, ) assert node.attrib["type"] == "NX_NUMBER" diff --git a/manual/source/classes/contributed_definitions/em-structure.rst b/manual/source/classes/contributed_definitions/em-structure.rst index f26e75121b..06b8de3326 100644 --- a/manual/source/classes/contributed_definitions/em-structure.rst +++ b/manual/source/classes/contributed_definitions/em-structure.rst @@ -114,9 +114,12 @@ The following base classes are proposed to support modularizing the storage of p :ref:`NXevent_data_em_set`: A base class to group all :ref:`NXevent_data_em` instances. - :ref:`NXimage_set`, :ref:`NXimage_r_set`, :ref:`NXimage_c_set`, :ref:`NXimage_r_set_diff`: + :ref:`NXimage_set`: Base classes for storing acquisition details for individual images or stacks of images. + :ref:`NXspectrum_set`: + A base class and specializations comparable to :ref:`NXimage_set` but for storing spectra. + :ref:`NXinteraction_vol_em`: A base class to describe details about e.g. the assumed or simulated volume of interaction of the electrons with the specimen. @@ -134,9 +137,6 @@ The following base classes are proposed to support modularizing the storage of p :ref:`NXcircuit`, :ref:`NXcircuit_board`, :ref:`NXadc`, :ref: `NXdac`: Base classes to describe integrated circuits (ICs). Further consolidation of these base classes is planned. - :ref:`NXspectrum_set`: - A base class and specializations comparable to :ref:`NXimage_set` but for storing spectra. - .. _EmAnalysisClasses: From ccac378a628b613e469b79dacee6ec3407ac42aa Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 28 Jun 2024 10:21:47 +0200 Subject: [PATCH 0738/1012] ellipticals in xps cs drawing --- contributed_definitions/xps/xps_cs.png | Bin 118702 -> 140487 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/contributed_definitions/xps/xps_cs.png b/contributed_definitions/xps/xps_cs.png index c8117f52a3bc083f6ab999f7efe90e9385803d1b..9e32db894813b7f35d109eb0d0a79142414e3e11 100644 GIT binary patch literal 140487 zcmXt91yodBy9SXEK|*>^8tLwoE&=K8l7^vMiJ@yqNtKfB?(R@}=m2fzO=7Hct_ zGdtd0PrN(yvw{>lDiJCi92~lgw74=H9AXR{90COj5*!@-ryq!Pzyo+EWhqg(k`dw^ z;KNG`5qS|fxbo=N_eO}o=T{EWT263q_*l=s@B`Fm!fbg0+_ zbTpJGz(44y>2`DcMfGV{bH4sKwP?9Z@o6pH+t;;l1%AveTn$Eh*B)k^M$*2grwiVt zTxIZX`3S9GLLG(RDfQyh`Q7;Dk`_bWWe3KbWBw)+zT8r>qfn=yw8gRQn=$1wtY&r< z_-KU*eN%*9?{>5}g=9lSX4wIY`Br@585vWxJQu_7y8p$tDOWyINYCo6*-HFmNv!FK zZC~4zd$XkW_C&sllNjXPV|AA4>(JC+=!7#wrIu8#rSwCRHbkXL_whD;ZcmTg&*eHY zXIEpT)_^x;^W}f#nu;OS^n@>P2v!*|=WDgj5S3)cZois{8J4upl`pi|RPgSD8HQ^$ z`dq~|%iz4U>T9#9f+c%BUHwGdxR5q6$*TT|#EFgm4RrcLBmkADIEBkfGgHVX+x5Ya zYhcG@3x8cst4&Vv1!f%?LM43RyUPS-y!E|Tx_tI)Hnm5O#RK;d;!?jMXhV{(I}aDV zn+>^Sz3tcy22xT|)@dkF$D+ilo7#IXs<>7o-So!ON|4|19WQT6hVH?QS0&!f4xPvW zuhD_01$D)cV21XDf?d1^*GF7ilZj6!-uYUMGep0Ov7SypSnw|iobw}^QF;zo_04qK z)TMBHv9e&csU+W&rJ-}%~QhF?`bb4Od{zFS;Z2vo8xfE zR>pb`*Q9re&7ymZr11`;;~gTt38-r6fYsR2S6d_7cXn-EB*G!{h~vZ7Cu=r+28g1 zWSd{If^vw2N(~l2#ku$E?F|r}ZavyQZA$K0RJXnAO`D&mX_nO)7!kZt2C4}U1F@BH z>W|kjw1`-l<5wE3Lce>Yem_JC&6Fl$dt+qXmRqc!zQ8X|4&;pfNYQ0F31m!%o2OL=^c5)mse&~;Fy!^vy zYG~b*>$7F8mz^6-5k1tpyVExOHJsJWPEH7>!WcSBV^nj}^JV6?H_Gq0Kx!SGFu0P_ zkaKVD=a5bbI^lMWb?I;`_19UNVaYI&kLLCD^2NOxtrSvZGFTqK1V-BDCqHaDql{%5 zg6vq-IddgY_rH}BJDjg~5}~;4zMFEOnCKpRkB0d`i`PBJ@_@Er8z(i)L=(OO?&)d3 zScIxxhUSnVa4fqXz+{+&w@L|HYgMO33?{4F3TMlFuDkReDAj}x=4zS0B@)G;x-qf4pODJ(Vir#Ad%O2Xq$a(!|CT8 z*$i)4N$F3V8>vZTZr|!@F}_yPiAlH_m5{ zr!e*#M`ZIXBu@_o;Roj{weOtPcp$H^-=1PfATFC2RgQV#3lgZ6(MSUQYog!%$tI85 zWusxZ^pukwg{3WYz*Z`s$^|WWpZ}##WK7u2>PXM4sj~1yVpeuHeS*VO5S`=ig3gkq zU72)Jc*CpDIy4m(R_*k|C0$ici4CQ`#Na-%Lwem;Z)rGcJoKVGO?D^pp<%)Oa@>63 z8FTw+X}3*Ib0$yFzf;+{z#?o?`i2C8(5h%RJV;;Et%cU6@hU<<^yvkVi0=7u$gqKW zl;EYNOe~ED_yJD_@q-$AeMl1^umR5nflP{WZL-WDPfn?;k@D4-Z+w_CY_Pe3#IYJ1fEib z*lQI-77FpFCz&M6gEhXybl+PsYfn3~D(GH(8((R;N>`k}$Z#5_Cy}*$AAjM=bHpAX zMl!RS_^p6ry(*?hAFBN$xg*Npx*_`%r*O}ZgCqiNW&eyy%L#XV^0!T^L<354~UfWIKP=*xHYk7eB2hIscBi^ z0jkIEbS0|0Ub7G)2xkswF2oC6b28F~G4~9+EZSM!WF>GZkH;j0I=xR+6-Zvo+`(Ekh-Dc=xGMnFP~iBHeIg>)L)_9>~9_;DL`yp%~8g;h`9;J@SM zcdeaYz-j%s)|@#YY!r}w+w>qam&sKl5IUacsL8-if6Zn3`yggAj%xZ>2YzY#Y#O9H za_I{_Lo6nQ1|ei0)~utvvvHq9?GO1!x-ea}Iv4YeOVvk$0`i^mPx7FI zur_f4@ia+WT+bp|{;B(Z^D4za+tch3JCv@=p4j#7&Q1M13y$OHm33!Y~ z<0CBC=QPayA`(PwDrZ`?`=QlY>S&1(TnnFSZgN&LJ5n{t$Yhu zjR^dCEau|e|FM0IAZj%kop9=?$|+^sXw3uoJ78=0xocqQ}!QRzsyq5o&RRbKnLDR#>zMhLC_jqJOZ31(o*N03Cvq=Te5%Ur2W_pu( z$Yd!Q7O;IZDUoo=s3o7pGJ6P4n=4?=WIe>Y;_OoqzW+L)#nyQgjG-Z#*+KrUMyqEk zCj1*GKMwmr@NDwa``1rw?wquq2xOu~2wGToEBg|1SVV%t$vZ?X|DQ%#Pi#ayke-*~L~-$)FA5mn zgeA=j?b!7>Dq9N@XXHZ`s&E|~>%Sjy?y$VXE)lF1EE4Kk<4Gc$B$Ri|XA9dqrjfss znOZ}P{0lXT$t-ZY(&hYrBT;nAq`dg0QBAfsntFrGbU^p67TYV7&pX-HaIBC2Os;N+ zYp&2%7;~czk3-D4F-XZM4ww|>$wro@Q$6=2(6>x23qJBGG=2gW^Ow*&D=r0wp6%}W z!|4!_@;~+;^tBuE+Ot)Q_LV6YV?>l|w`lUsF{I+-^r~Z1&?ib+Q%k8~e*4ogdGlv= zm9Be|{ZwLVL>1T^$~0A;>K}kgZ?vopz3>d0!+L+buvrP3&>4DKTiYP(-ua+VAM2j9Rc2z4Ocy`gUn4$7Lo-zEvOU3;Whu z#te*osxTp)-}0P#Z@MC+Wpj@FD%w4~ZLix!sU39-Rk=)=mFO_0a6+vhwKqYkm1JHb zF-fwZRR6X(B|Sg(I>ia$#{%wk*VkdlL-aifwTy1e6`9?Hn3Ul|`nN?FeEC0X$qIoE zBNsJjD<^QSdXmY@W}0K$_rbmKOKnt)Atp;uNr0dw?9@4wtxMB-3bR25bo~oBOhte7 z*!BfZy!`w7RX@Ww5L*FR6+M|{wyBt;fH8+*_1A-p7;#!y%!&KUa{EoCYBjqt8@%Zq;So z>VQgzWp(Y8si{D0$6UJm#+yqmSA6+enKMK-v~nsj``VDy|apoMB4A&cK(r*4n1+X+ruD_&`zbG8UdWt`Tin!JnpM1VJ zeNUWzThkM2ZAgCwD>Lf+kGLV!w)A*W<8kOF*RoE(UPQXPLEy(-mm>^K{ESYR964nk z?7KsnuQit(iJjzdJ99I#u2lJY;2}a>aT^k`3;S}Cr+BvcF-v=EpwiyPF8&{Vi&Q<> z1<-~;`GU>z(t(oxjH+_l7&_sXfFQaD1wA%VLK-DZTlyf&I--D-XnhLGCv^DP@E^XD+t(~{We%33!cbic3 z0Wl2KM0QEdK9}E3HiTr8IE`(d)s@N5UJ4ntX(^DX$HBLhKlDsmg4vOr6>drvh6&iu zmu<3X7MES=dvSBiK2U7g7IjB-$w@qy(R{D*q;g!qwTthQV_s9vsgU~cOvBV9SMydO z5evf*>&l|DT48~|1&$p|{7%qnU0l$V-O>XPP6axsNwX(!Wir6u5VgzpyVrgAO1M=8C(n+Yb9G8p|U8ROX&}<^7t+hI*z8Lv#=u`A# zX+3j(YwbY$1eE75w6)&%&lV3DcH^l~{&{OD_PFy$un2vIgI-ZEh`m1#L#U3bxD-HD zE7mUzqtdwsmhQb(0kk+gh3j^0#7z>6XUs z#(fgAn^VW;HQ#tNG_^tVFFq-ta=ekYgj)9Lvz>3)FEmX0yc6`SswRsQEx70`Q4kwp zsndmp^hSa{$?;ax&(ueVVI%i#{%?=A;!HUCiL<(oF@nq;#Eo@D9!|JIX zC!NX^e2{bwS!MC|nFA}OY6$U5V5egRIS>pX=|>3p+)9U;egi06>kK~s^oK34MeZBR zS|x+WHU6AH(^%kv@Q)fDJANH7qg{~lr~E;Y$(vyaHTMD_PH;!dWhHG*Y8be@;a$h% z_PO23Orq%g?71Zb}@={*zG#?M`WgS4E(!WR;de5<=} zasiP2NbKwlO5c(uw`TU!5skEODw%F}Ui${huoQsur6CcOR(d7HcfDQ+J@=Qirg)29 z51X-zUF(f@ixRA%%3yt5Ujgq>jSKrx@{NU%*tsi$+hx?mN~RNj7WCh~i>kcW>)ko+ zdvB3R6$Clu8C#Q*DIfw@m${G}%-4_maN^eM*KZ6b_MkVo>}|FrhQF6Gu=l){zpBQb zi3$G-v~NgGwJ)E!ild|K^Z?%pzDZJ48)51uI`3`N z=3f3G{M8uv`X84dNJMQXy|-c=Zkbig@=-1I*efIvku~w?kP45vUVzee5rI>FhGSuT z87hm*+jxA}^XV7*tT#Ok>*;5!<*UAF8`IL($#w6ev{s(CTQ5O0Pp;!!TiNAqJkLlc ze!acQ&+KHi8(JXm&^&VADF~$>mf&V|y<(-s-Ksz7q?S>O76-(MCVUP$JfV{cr^ie@ znG)CQKYcp$BwoaU4@^w=Iu%SNztDO6bRModbf_jp3tx~-%PAJTi`@XcSfSZ_zdnU5ljExxk%(8RXxa|dxAeW}15ElE;s()Bv1 zwiA=Yw43W~@rVtq9ELlxEwm#&sn+3cC~b5-ay2NF2gq42*&K(8l^3j^rsj|QJ2r$8?nDag5(9T zGEUSn<1h{YXnKm`+%vV&g$gFHN zF)p!)H(G+T_3j5lo96~o_^xVXB-E6am?TxIVrQuydT8(Zkp|EU*o+5!pt4a`3s^(c zD_5lJ5p(*`_;;y>-%BKn(X~JaTlnd#i9gA_KnITWy$z*CM3wy`f|s+Tj*K6pguN1C zOgjrM(+5q*r8XWcG#`hop<$Wo==DTs2JG_6?Y}o^vr4(_em%BtzvY@S5qc^d;u|F- zx4G@gTWnHSZl~Qa7nk@0LCaC&RR44_dC*P3cfur-kUMYCLL%sO8LwJp^Tg8Ph+ve_ zQS9;LB2!&vIZl0ri+(ze5id-z)xdq)`+2HW#n;UM+l_4r64B!|Q{j|4?!fw$YhD?h z;8Wv~j7$)K=2jxUwFe-}6$It02&7ao*@EH)V}3b z{n|bruJ5#_-e$-9Bw}%w7@cM-Pr}EYQC?Tyq`!SNlrc|Y(SQ8|UDNicSqJ0g?tFb^ z_I-Xf>!^;A-xqAeZ=j0l1oz|gWyK9T#7Ipqo{@)5M#RYT5Q?Z6RWg}#e5o4~^t1T! z!71{eACE75AC9xMIZZWHR2C6;X3DefQ1Q*oV`s2ri4u4n#7gi|d#j4{f{}`>J8u|8 zUy+mnnmn}7$De~vheBOtETos&=3(m(WVSFCuLxc1X~xn%XfpsiLHYY(;Itac6K3vx zEdj_4ugCb@Z0v`~NTzy=m2F=qQ+>;}iG}ch+6Mko-&KLQd?5raseLL&>HRr;9~HMS zDXpJux8Ccp8>(&hup-B&xQ*e@uf~%V?kDXRAYQ{^TWPIAC+1FKJtPg_L&MueciCX6 z5$eqtc{HLI?%m@}bq%Z9oa;0wZ0_Qq3PRnnXlq{~1La2>=`U)NJZ%h#V3fizn7a|O z^CQ%0&jgfuX5?YkNGS@aI6DjCU4XrPAExLUcHz>&i^(*6ZL zf;`(kN?#XoZWLd@)OUrcmEkT zmz6uiOe_jX9_uMp*J<|7{FUTBYr_lD-Lyh{MX{3jA6Zoe62wm1bPp7!)<{=>)=OA~G9?5rrC!e)|s@BZ*?WM5oWfT7rIoAZ{zcR&zWFF~+CN84Q7o zvn;tJCWYu;ov0*pWBWc|ij1;HjyAeH2STXs!GvV-g~LnBE|KlU=EiJjC$qOUEASF& zNlPbBay4tljlT@G8ijgK)G&s8nNmTp$tKi-5|=rY!_-hAcS6{1lZ2;yl1Z|b*MqKu6 zaHse~)UViI-%PApi?O_3v1OR8pB0;2QHcO2M0j>P<860cJ@oX$cGp6yU^>Z(IT6cv zHw`X+wo#S^rlcr}T}anVzqc4WV^6SPTRsYxTRHFNiqU-LP`FBSmhq|Tr9!77k5 z=0bMmxF->JtQtW2ziehuu<*J`>NIMquP3ifh%PQh?F8efClx_z z)_pczD~1$I3Ti}bt?>@Wo(Z{h=-*?0JA&BAIKOf1_O&4p*EVYkJSS)m6O&dd4kvFD$IK{3&$YknD$b;#8nB+SFkx36qI}y zT~;J0M%SOEduHG%D{(-KvG>EEU|NuhI{r)qJw7jBfFuzGPT-OEuIQ=n8^49IAlav4 zg2tH|^AZT=iXw95q^%sg34r#^3{zJbMfypF`cJ;H=>T<=04HvqPOTl7QnW(qUl%w4 zWw|WOMzfQMF1tkp%`tT>(HfV-TD0I_vs)NgdS<9A^gHL0OZBbCb0djkCqTAyHPvBO zs;-wm!qedqkop?2pbF1TE=3s{I16KVV=H&3C7vhB_Oit(HKfPV#)2|(9cK2vUt=gi zOtB2Lm}qe~@sHU2xgW8!Vc|j9Xw{rXl%!R<>)oLR?oi#q;T}m6J1M2$zZg;cT*wnP z!-Wm{T?iKs98WE>&7g1Hlv2uB1&sT-wx}@}Q7Aq%&vDtz(N%xzeb65H8soeY#v0>o zx*Ve)yWl>}X?J5}aP#Y~;6?Gq;w_7E>P+BiYOrswEizZC5HNO`We^$a!0ZHFol%M# z>GlAk)V>Y{{>R2cjNzJLYZPN~D+B?!npZi~V_eT%&_$;nPlf#hCEJf~CTKJX;0~(}M8=vr~1wMksDH zJ;1PT_1MW4)9jPm#&5#Tw|=8SE0jM~sIdHxhN$CdxNF}5Yf0lVI z9rsz8wVzvI8a&x7*>ua9v=G*@E7#9-=aG-oO&e!D=+7{$EG z5(-5eEDV~P)Oat?!q|(>M7$S2R=ld3kvI+gR(l@CFf^t1EtJytA{DTcLns+ZHRClX zjodYZr{R4RTv`>6T!qE-I4g&WOcLKh)xZbb(d%zF0LV}l#(`K?SrfI&&@PTr09p>=9|HDWMr*#o|xJpIBoffX}3oK0H z0qS^^a7+5yi-!Uu5@(ZSpTX`1&fAN<4;CWQuKm?#0?<;Tnl^DGMnsY#bIQoz$xn#1-LlxOAD6rPc>fZG+|{q?^19 zC>p#ky#G)Mk}z|9{7=h{s;5~FBoy*$2z}4TQ? ztI_<4XfiYE`0`6Xzk$}KAW&Sg#0Th30RgvNnwn{+c5l?XjS!)k+dwskXo0_uZ=S^l zLlQ>hxruBoJD3JZ969{*a$9F;pD%B))nUyGD6=hJ^Hm+;10;5 z55F;=Lux#=5lW5>=cs1>>;F77`FRuhBbmYm%Dj@%BjM&fZP60)ynrF3c7rus2aZ)^ z$l}n+JP|=AdN`w0wmGow+wHdlQA|>m_V7{~fbOULcooC~Oe;b)yyNgpUfQ09nJTMW z53@$P&y62*j#Ek$$o$)Bb(X7|^P-IGbZS>Ef1EAWwlW4GZAypY#8tuJXGulBx4Zf# zFOXGJ#MNCCn|mpt-B;-Nrr+ZAk>;{|DvPu_o4;?Bkk4r;A=$7n0SA6+vbq%@}!}tJTT*t?+d0$Tm$ZX7l=VqaFFYopo9qtb>K3NL2 zcx33?5AKS%NtgB8ANMxs z&FIM{b2Pa%iz&dmtxqHY-Z#6m1>CO{335G}3bu+CFgLm8thHy)dlJ=+(JQ~1n^^Oe zw%itEqw+qSk5fs6qyunLxCqjAJ92%pw&42__X`T!ZUL6@ z>U5;0;<_)s2c4<%r_xV1##h`p%{d+Lx>j2s!$1y+-lED&P6<<&GN5f;%rOE%h z?^)PRmt7W}p~FxO?L4>1%GMnJij1aMmzKBUsq1Po!L7^MgsBnnZ9Vjx#+Rk$bB9@F zpD{Jo&E(bwB+|a^+>iCe)(F=LcYkW_4P+z`UZ!E@_&vc0f_-~znR%_b?3@gw7H`6= zmuq?-H(DSfK+XGz8JQJcd;HJ>lI{8!p8k~eXaC;XF-~KR82SN7@L+tCGE5dsyh`k~ zU#_f-GGGL28Y)3QgGfOEt;fr|c#y&?O~t?=4KU6(LUyK#Q?sFnnY3u7wy;A6kDu2P zUoC8YWt=8lmDpD^qLdII^uNWpaJKx*5gwbJbiq%YcctR0)Ve<@s641pZP&%ajkxt? zv-v-ZSn+usWoZ5m9%Q$fVUa;ZUSw|4zlb^csxa9Od8ANP)wM?(ohgT~&%QGz$V-NakN-W8+;YPeS32Ok8z-Si`#y7XDkOE!1Oq zH`_~SFJ5X%5N~ov6yiPob=w{jQGT2_9S-Rl1Tws+)QHBjm?kfjn1Y2X20alz5;hn? ze@u5i`V2mIC=Sl18(WF9Ey9>J+v&I+lpo0Q2ks$6_QyZBdZV3n`0%yi+ui4^0Nt~J z;E@l9o})VsOLxP@VHL({5BqPXZC1Tj3oz0o><^r4SL&qc$$P6m^j-58zpr?#hO{Lw z5GI^E{k5j-%H(S6SHq{B_}Sp;~Ga(N>JWD-lM?9IL)-tA*^_i1&ip$|pvy z_Q_~1v{dQsX5?VqJAd7g^F>ls&mDE{rk$ZWziM{h&43YrZn`KCc?F*}J3X!v{k6~& zUaH^D?H+l~CP)-MOR03Zld7YGU`^&YCS2O9)Xbmi+@`LUGBpVb3dBDm|t{=gTRt+NLl`@S#xu6pF$!hGiR^< zjOdL3+^j+Q3F z?QOuqqtBE|#<~Nw{POi)0Lz&XNM9)`*b?>hw+X_=?>(Q7TN=WzPOZ|!PC4NP3`2PK2ca|R7HXEp5B|r!9`t(ltaKfLClPT#3Qm0~T^|6h zT>!IrE4Q<3b@t+LNm*IQ_o=Aj6K}jRybciP)6TT4a#c7MRm7a~83_R}b$sWi7ZfTO@QF4u7jFz*sJ5(dcM?c>`w07@Fi~S>Q zF-=Qp44PbX?+W}QZhMP~_gXs6ua&-*#~;s!v6|b~Irb+MWyE&LHuxGCRW~U3a-8DH zOj73r8eOMYLJQDc4{fk&jB(x?J4^l0AxC9O^K8ww3V-g6_v~-dUCxfiYO-gfT{GiUuo*T)Z$NlCWV4Z0r3s0wi=>Um8u@i7sLH)<3}Lqg6_ z@ZDX99CYVNTA!6>#<}H514?IlCb2|ASSH1M z=Y(PBz;yd)<3{Kw+<57C_y}@?DlSf_y><{L3Q(EiIdoyRu7%|FJspR5bL47%PiTB zJhB|#QTdP@v#VZ)v1Y?C^zzqC;!NZgiecvZ9b5sfFE)I9tr_g4NK4iM8- zQS>O%V=fwB8Z2NWW$`?d9m)i$Af5qVBkvIjFb0!Fwlc42@g4ayIL)*=^kdUw^;&9m zG+d;(JYGTO*TY&oRaohZepJ+@%6G`3IL7D5M@r+cylba?(7-3JW+&fr9JtR*>yK`k zXQ&hDz8N%ltZ00KRo`qJH4na%cqL@NH0f1<&CUBdgcu*+^uUr&JT za-I0wJ3l>`H*C*z2Ahr+9=G&sdvdw*0@D9@Wt*0ryrig%Hq#jUq6rONuFv7c5mgS0+_zw*yNC+^#uTRDC#(jhq=otlVb#*O2wckz8}C)`L>Id$@Eu|A)hJ`! z)0vI;K4!ktXKT_P2XV2QsJx_#AQeM(aWs9~O11neQQ;Z1smNC+m57k&jAjTf7z)z$ z0m)+y1_?ATXL|x6w-LV+DK+ORr^B;&;b)}0IL`q*r)7G`4&eT=?kc>WyM^%#bS+1>Vysr#nqtVzNBAHtr6E-68P!FsO-|>%R7CXH--=|`XYxdVm61W(KzJQY*V;-mY zme(BAC;9dUIqNFEStSj(71@_7mE-CAX4Orb{cLUr>!66cxttNcyt02>+xc+2O!g#N{35y~yAqjrj{SKb#jUw;A zg-8f}wBE_lG_4lo7q+@gc@WsLQrhi}d#TuRt|*g}WHmz0Ae9_|S{{1!Efbau+T?pq zV$^0NEeUdy%tRMh+rBV;WKU-0{nYdxOz_J8?Mp=xjA=)Ov&~`aYWJg8_)ARr4%=dU zM>lOdqTgG7MWI$qp*Pl5M9!C=N(-sPgBY50Wf5NwkdGTEUjEenyQGyP(7Gt4ge}@# zZ)ve&;G08Cb_sq+kLIZ@)x_s1L4E0Xyxb18hWA*n*(>~sZaOJbcT z)xRk4l|t$J!kzj<-B#GMb#6zr0XW=qH^=$6Aae*Zw=aBe*7C2^Q`WLd$?B&_cwBSM zR*Oq<@-8K~(lOVpW3fzo@p8JbB!h@l`ux*Z6hWKEwZH#kyounaUzmQmMd8#xyop{i zqLwt-)@O$#mHAC`Qhrp;;w~%jhIUbX{|76F-cClh?i7$nhtXsipty|>YF~+eE+~)E z(H2-$)^*i-%rvL9VbvbM+7ce27rqx^T_uL8qs6YluuO9%mhgR+A&00SOw)rN(qh`F zY9;#jjXE3Vcww_+fk@S7e#;h$>L-s-nS?hG@2%h8iV(m2K zS>YXW&kUu7I$uqZQQo;}YhnT^Ejkr&;T}E2aNe_aRh%??-{a$s z&>!g?wY(_pgXvG=u%kD5Fr#o9W~H@hN$I+$XItR|?ZY$O$VzV{-?{$av7G;@e#@~R zm#wwD!BMI}B8U6wci_zEIART02i8dPkuVB<{C+(Lq(_g`G(s)MEkS$#Xd84OG>A&x zdqLKxzq?WD62F`h^e!u0b6PMlI!5=Q%y1+8yPhS#g6H`*S^kvG{JHOT3F*1uhiYS` z`4HmiJW{W3Gi~A2jLRwFgqO}eph4@+-nWVM7(!cU4Zm2%)U+*>sk=Kq=tp@6;=q#J zP9lm(!JkBG{?vI`YrQv87fFlB7E4?0bvmHGk}mNbD+zteoW7yUbK%RawGkYTBE^|J?GBZcFtjR-de|0Wt&yd51%ggsc(y2IF8TH+?)FqcIvk^iq~xLohKpLFl<#LB=xU7Mmch zHjW>+6EQM;(*Cf^b-4;konPj?Zt?S&OfQdi_*O^mT3xf_^}e4uBt^Xf)*>Edt@50U z*08;RX#fjz(+3jJRy@pfPLk2IZW})pME5z`qMoMP!z@ldhD_Tr3VjNWAvL^k2H_Yh zzX3?vlG#rmDMx2T%okOWSjtSme;E5fHLYuJYRM^?V2fueGFZw&z^FWYj>Z)I``r2O zn4$%deU9h;5n`_UGfLnqL5|dkoP9MJ_TI< zG?SJKHH{GY@Z~YUP{98umJhyY^a`4(0vl&yi%K{DD+UA6wenTj^nic>S>OcjGps^> zaq>8bX|eXR2EM z%9h}t{2vLto%9deGygVzJIgZVJ}S;jL>7q2{BJ$}ni1zJLiDB=Mak#?$4VqbI8*x| z)#xCuKCD+K$b~qg>DMviHMTmmWZ54RV{=fa!?P<=T-&GA$osvo_Fc;oQS8L zN#VB|0peDu!BkESAx6euhex2pH`RQ4eAoyHtTG3-s9|FpqLf{L^5o!=RZIMn*)TIL zYfAw|lR&^$^#1xnQA!h0i_tWWit_Eh7$N+bnfZb{TZVUPE0g}!)#$BJseJvHsPTFy zi`np){k3QBz_2V_-n4Tjv75W^4~nHx`}&9C7yA|l2dC&3kM}nf++?%=PEiun2>Kcz zF!X1|GLin5hHn>0duqfh-aPA@KieEApF56Auil3xBM4}+M1Yr5&6dheruO0aNFYfe z6BZhvt1v=4VMXEHZVM=Wp%WF!XX`&+sKLz3MmGC#z0Obokl$^m*y>D| z=xu~#zvo>Ip(yIm&Ud-q-%5i(kUa23{{oZ9?CGSeQQlOZAGmnM2Rdr#k)IRyXb-I1 z_>%pekl&_4?Q>QIYAO#|=<;(XwG4l>Xc#t6-L+!aDy$t0*_!j_3m-SniE~(WZll+* zLe0Sk?9uCkNWo>H`)evvjipIXyMEfXm4x}iHmihr>E8E*BhN{O3$J7_{tbSZrq3Bw z@k_j52*H}#U`!^rou-Ijb%;Wc=}Ye=u0NkTco0*wBj=CEqSxtv0SBCVteSP}QVU{- zO|E<@n^_p(EwKTCsz5cv##4&>K&kxfv6LofHTccaRcwp3n4QP?v-$LGRXtcyOjKrQF+jIOcXrZeJr_D(YzE!!;}Rm47n=7QA(3gOvs-lbgS6Rt+=IuBqQAlc`+ zis*mlQePXHExC1y+j-D%Sp-J@J7B#V;mXdOm!DDK8kBaA4ZRAD*98p&E>t~Wp%jz9 z?$p^O*f5?lKWbk8l8raxRoYx^YzgDWcu-*I_#_Sc=kO_GX0}mR_?|G_Q%9q{<5P{2 zu0UJOmw6a7zd z?x3rm?_mDlYo9L|y6x%tEXq$E`oRIlZV&pf)`M(CL^4_ zu~lYhN90Lk{{W;5_42MOD|%+?s!btS^T}Xln%?JLK(2Nd`!Gv7od|eHcnt{zH8Z**>>Pv7lEFf%z2saE3pr1zs7#FfZI|9q>2SA`+SIxNz7izwrT+_V5)x%h{^@SXw%g;4@_|$lJ z+Y1D#AK3rZ{lU8LONeRmJBB#LhI1~3|!%_NsekR(`z>^8~!YH;XX(GGBPe{XXDE_5G3NB=j3mE!14)zf4?#&#WEdaPQc>Hl1Ug zXnA<@Rs@#5P29h}@$kDHR)sMr^s66QsNJJbBA2wvGZ9vBaB=s)BNnSh3L4zG?eTwdh^h9EEn3VTfa z-kaghvLyOPD*F@7Zc_1IFE`+Bcec9517>=|5Oj87d5bga%`WWy<*fOM5fTa6{|rpTIDzL%S$49? zN&D&mAtlxCLjV0j$rqSTX;1rS_ENy>8EjUMwG0FVUq1JX_mX>pNhAp*rw!#iCnl3WbP|0wY{3YUx=mz2+s}5N{FTxrt+S zF6fjD%9jEk@B{WCf_i36s11P_%Y9#ajwne5i93Pj8fjOKJcBL9`dF3WBDi!%Oc2+& z)dwZt416F2d_@eP<;6gUkeBWZ>0{e#OX($3upYyG9>h6w=X}1E zS1cMzZ7PS)9ufa}obA*1%Q@ko;rQnXeF98q+|0Y$2cW2)vN9`~5q{>Uf+YCP8CApP z9}4A04w$Bb`sm=*@;uFMWho{1;NP=N=A08(i8sT`o#4-b6MWC8Ef1C9#{TW>57#YR z3%=(hbK+u@V^iCX-DZZq&L)2}_$ju9-bQ=$uR&tA#+F1WP{NSK#szB;NN4+thjB8> zwSNXNpMw=wIinfvqx5$~xxKlrzvgw1zJqMDXcrGnJ3#)$2aAu=wsCjw)?>ZtJly_J z7H-2BCZzILN`ij3yHtmo@j^`6ZRjQEBC^b+n`7?up5JTVneCdcI`S?KXSbeWn9X`= z-?YMG@IZ&iONx$;uKtr@`q;-xn`HI7S#C~~B{nwge}=Z%`VSJVAoq*mBp%>iE80~j zI(ZjQMpW`g?KK_J$cI>|*7DhD;!R?r_QhEd9bYm2*u0$dt~mxNG?A1wmMCt=Xa zU1dU{8gX2pCSj#(qBW&YoiQ39l)?6!H7YUZ61_+S+{?1jQc|?LoDQ^U(Y|?DvJfkL z2qH!Q86^`lPCl@e;hhgS!YrR&lrw6g^0(kisdY)D!0>4)|5Myjz^i-!tnQx`xsqVN z))Wig94}PgFzAFH=lmfFze08bk~-4?S)8HX^kZdNs9F4G?XEMWW3deVGNJVyTeE2u zvwbQ>|3ABJQ~=X9Pp`2nh(p#!IKt{)(?;}rppg}qOrl1OBc&V>Chtfcsh6Vg9?1v9 z4AhiBd4@QalE`F%;~1HXf7sdrS>-Ia)la*c<7$Vep_ z4T|-by3Y{6H^YS^sS66udkt%C!(;3)PqeUtajmfFHCf*=?i&B#guUML+sy0;_dX*)5`ozsKDEr&P&% zUJSgpPvue`>&Wr*d%WG!a6z1|VCv6y2*3%>3d3{6GoF5qW=wS&CY~-aw*))0VlDS9~YH?I>32H_RQ$-?E_DhPE{dw*})gPa|DTmb7kfv|u(n!Vxuglq8 zTi9|Wa%6Z7vqyq`9~j2iFK8aZ`+qvCT~XnTZgsM z_5&tA^#_TQk>4a757t{i?4)C-O?m`S=fsb}wxQ~&m}qGgj0h%u;a%qcyieD zd3sLcSXr2Xom*)){b^sdGRdl)c4YDHM~g`Qk2vYXsZem;pkxqE^*b8=kJ)D~ z)Z-&H$#blc(-2n<+oNAk!;j{1wlfW@9g+z}cFY*K`zkD9B^u1oLD54nZRSp_hd+}* zzkj)bkR2tPdh)jxOZVUrmTNO(QwP;g+NbQ-KQBLpoa|03L(94eD{85;hv1%7dz?Z) zU2^zhF1#4+0Qp=dG_P~X_1SuF+B`vuyXtiiWz$qh?k3bb5%Gx?ClX;V>e^{2ED|Z( z0-jjSp3*%U`q`Jd&dH0AC9qF~s5+cs2`6am4Sqb_o1juhISBT%u&Ve>T<}N_(MQ*O z*w5{1K~_)gedy=X+i%~#h2l~ketNBNKv}0n(e)ll^*G}JVvHb(Z$F{OUMgM0TS@{c`i>!P@G? zeU&jd?=ndRINoeRgZwo+zy0PngAu{}n4 zmGURe*KKK<>^er>ZMAkgzPs0!0ZzB1d#d^`0tfmQTkF|NQ37349HRmsJg%=R9bq8j zmQax793y_zSbQ^4<{V;k>3JIdIyg9U;I|oL$9o?FVHu&|?}2asNkC79CM?s_1w1U{ zmq-*h{?fEPTF=_JoFZ@&x9(1v#D-*2OoQaM^z2QUR*geZx|Bjl&f|!shHhVqoQdql zW2L{Nn!mZQk2Owiq&*!9|Bohut^Wz@<4YvXA>(FWjPNeK_!W;j-AJ1*TUR|hoQ45X zC`OMBix3%C82;SM8sAmdHB?O#Zfcy0q1CpVOLb$6LW0@@kCq(%AhTvt;2@EeG6ZG( z<4S$HZ?t_b<`{_`bOsw#W5EE{TFB-6;%N~nn{xqvtSn_bJa zPCnh|;Rx&f{djn>Y_t8HHmlMYx`UoBs&%Zu*qi4oIflus3^CAI*UWX2it*h2!}bi~ z1T29mnvBaMV_23$=Pen?*RM5*du`5t`~FUpXcb%ELh#R;jL=gKmtW8PeOMF@KF8`< zE!yu`&mZI1*U|wQ4I^o?&ha;^E}{h#<3w;x09?vJ1#_V@1+9rZo_N$0Ks+H+(B<8**=H%HbIW zT*^g%DAd-)2IAV|rWXhkOMP*+m?ZNjjp8AAal8>jaJcqAq`-oeX%p%h)?QzsSntm< zd2E+RWH%fGl3Fw_<>q5gLdAFFF4>)qMMW1~{Byq@ghEK^fKy$k6bXfSBef94fJ%5T zHPZN=hLd#YQiA6`o;%T_^ZyhtM4wEnaoD+~#@7=|o@VCvyX}65D4g40N`Anu6 zlfb|b{?bxJ5a@O6+0S3s#3uk<4Z9?5?K!7F&N=g`HPo_z3qW+)%XQ#XNmwYLM8?gilflr=j>*{OCs6nSy4Z*qVjTJ(b1ajB3$SoFIZw`~I;NyX z=Ql4k&yV3%;E|=7%S~VIu_fLG#abs{C+h!f#uC(k`lRq8X)?I=SfHO<9Kp3H@JWz( zwq>;O5>KBB`B22Oudt-ac1zoik(O%%7L|FNXM!+A$Aw4Dh1jOs-#qmSDMn3O0I5Tn znx{3?rLdh%4EZ-}*p)uM7p2HjgSDrq zSi1yhFn^x>U|y1F_>RiPa?XyV`qPu-`5dwh?Z3Q{_Ezn;H?>$(e!1zpY)My8nu|LdHx<~Q<%@PYWeBwkm%E5;t75#jzh=f?j zEU3-AUBZnaE45}!SXE7^Y!bsN+WS9nTzZY&dYq40C07gD0k4NfoDqo%w|ED`d63~k z2N4ttM$aRQS*EBrhZr++t6}`#6DP5rh5WQetWr$)k-jmS6O*n6%Ba24cP=o@nootu zc^EajqW(<%`ilJDx&^4|^i;JfeHGJ81YeBl9)mf? zsZ!Oky#OC)B}I1!;}zD{VO#P;@`Nzh;lMt;OQA1D-Je1^kSds47@EOKUKshY)~P#Z z-dP6fXj#%fL>+8h1Z%%UIfCm^toCDcbH04Tz4i6lk9>Uer}j#v9skO4a&_xZDtXK( zRO_J_*kY3psDF$sVqkGW!^+U0u)%04b~ zKqL6;0QD$%_HxqJt%0fydZW`waLJ-qaafp7i=;|e>||ZSEqKvq)2Gwj2kU;+rISfP zUcpxXHolHAS=%iBRMl39R^0Kjd(+ zlF_YuO>nLo=|mrG*Y?xINFjqyZ})Y6i+m&QF?7L$jBMeTXKu;Kdo{8p$LEl@OdX7= znH5275rN}4bPflcwNw=P2}tVn>)HBWJ6R!hVdRnJ2><;2j64 znrKfChSa%UOED(KDjdj2i+{P=ZuPtPrHLDLXCrD^peDM)trFui9>{^D+Nx4PvLK2?+Z*ee2clE}jQj-J9oqb51Ng4#1R zNj&^zac#$W$Hm^Jd@tBGV=|^@pr-zV-)!+0_Kvc?e`~Mq6rCOTg!;5*?KjLajXZt-5V6YoC=m@0@H*UPSCO#{$85!x?KtngliDc3IibE?M zs%S*kml!9bB6z<*wk}7xhlIW8)?X@snY(X%?F4IeV{g@!7p3V)iT=kd8k~l&?@%Xy zhK5hIRjnUtltj^COiU}UZ7>}&cH>Ogb{v9}YaIql4eA-QX+;WWlm)3Vn$fs!EhgNa zzSm3Y3&&?|W1d(ye9PVVxy)4y^r0KVyai|{vyJM*sYp%CV zsv>#YDsdkuAgw6VKCJMI?B`&6)SSywUbDv4lACesjh1R^Jf?U7Mp7I5X5XeoolJV) zLpQ*-L9-O@v8mj{n4~}?RVOK<&~q@!M$S`xh%K~nT`vp-yoV{xu=S3G5*a!gUe_EX z$&;@}{ji={q-?J{QI@NYV#DB9Z1Lw$ zwF1caog^4T?0hEwG2ESJmi4ZqgkcJkc%m2Ih03jPFZJ~zZg5?30^urL_F_iYl*RL9 zsT@Po@C@=E1UbKuJWU23zQLUej?HoAnflJ!bMxi=56EbYo^$3Lx5|dqI9A%=eF%VQ zB_d+J66^glIVSGg4=(OEWg9%q92S3L<7;1E^{2P~t)R>}iRy2JN0)5NX$LD zorGJZH(l-vs7HzR^qD(co?zeb*E}Wxj#qw!(qk3Ex2iaPFGYqZ{pd&73NUXa%+7 z3ZOrJ4ftV6npaL9DQ*`+TDiTyjWa%Z2yTxY&yK%=DL7=0v45vPRF$DM4)8DXH%rA5 zn^>ST#nFz(s9tfJEWuWIYAJ1#eP?4hU3*BeU^7eT@<>eoovAdZ#(P}&rI(yYA+k0$ zjV|@Yigi{&Tj#Yqq!n*@cK^P+H-4_?jETJJ$<6+?>nPq=W-9UENJXm}ZTX=hhAp3> zinmdU)`)m|twCWPRtNJJeS=DiOa^mj`gidnCy?XERoCEk|YsVixM3Ygxet?GK z-U;x}I<;G9vX)z&=?rVK)>#}4o6qeR=uS{ds-6YO3|)9hIuY%ax<@lB@i=a#4~ui6 z?IO8X=Dl|a1o)R5D2?9R20>n2H3QKcpy@la#tmZgEBjP$iVBsH-^6%zSaBjk%mf#J z3g980-fr9@1M-reP%Q2qWG1V2cG>XUv*QmaqJP5&aTo9_G!!XHhxgp`DfSJA$vfI< z$IRKEm9}O68F^jq(a&QkQ=FPm_DC5pu&`H3`4jyJ+;6({!c7`+^>A!RISVRw&ha)F zDF|ZcT_+*taV^caa?$g0YM8aj0evQ-*Muzh`36N8TMT*$Z2$NNzWz=+%;r*lnNvw1 z>D;NhT@Hr_<^uBERSZ{s62B_vx>d2C{cQvy80M$J1v^~*jBNoB=|0}osh9W&+bcQ_ z3VF5)4nW23sOeXm(2$_kkKy2F_n+N=AG`m1#d}&bu7*;OOnN40SgmPL!kKTGDR3fZ z*d6R(sIbH?hgsx=6TMg9Eu9d<>KJaS zeV5kDqwzWh@gL;3GuR3RKjJ)t-XTt&gx7lJ#(D;|%9t%BAc+Py+pD&Ca5;oYPTVcC zw%?RhG1~(P%EareyJpq01w7?YAZS8SMq*Day^Z`>_ht?z7^Z9eq&Ugh@SoK`!%l7kcMS&{{A16A@u{H5j6}(49#2}(mh)pDj=Q?vHc?g$?cqh6f7s-h; zYQB1yOwVgQ+s!&pK zK23*RHbGC>dwzS>FHnhu6f-BJ^NNpT=CW9|M@m`a37bgMI#%665Kr{R(`{lgRYgy9 zE!We}_BzTM$ThF_@m7cBEJ)S$fq>>1l1_7|b3e#QF|qFznCc8dbvJkG3R&%TRJb_b zEPdV(;kTJ(uW2WZ5qMQ~Z~;?LbpAcWEg3;^?CLg566fn#5Suze>`Dikm3!?UBJcCziv&z7~GK|JrbqyD4E84Msh zJQ6k%Sn;}WLQ<)C+~VbPafK8vZtsIyjFMWi$=XzWG#f*`DmT_-`jk?}GhwBQ?<`3( zHuWhLjG}PL-n7Ib(IM%YXFa#))cnI@ z@TlFfQEXBa$vbmS}52(kL+7Ebi*w*)HTjsdq_ZoFg!X@kugV z*5HAof=t}q+>>X;W_-nVnt$l8f6DCLw|ox&i_R`479Cr)LMS=PY=s(0s4>SI*x$dv z5JDiBmtuOM$JHgzh=5i`%hUmcJL$76zazq&^2+kHL8 zu?~Bg+{efilipgXF<=N7#v&gG(-SYaCGoQOwI8wIgj?pPeN(?lQ&p@ zh_S>&)0%iu(==E_WtH81>6_o}emxjIE9+UJ&J$T}lJ$`bH@3}4IESvLW;CvTlsA2u zJWhcDG^DiXpbV!;$(l-6Hm4xD-+&O}DV}UmtD*K1e&Pt=q-XCBI&aQZpIsQ}aN_gj zm9qr9E!s(bPA+8@Q2qHq)+6Ak4J(5JQHW0ur&K-uQBES?%?rRLi^kKGCe?Tj#Vz`WS4HE+_nHfn_;XV$jxwsef3L8;PWSWY&wTvAZ+0p^hNoMjV{V7WRMrXnLQne(LJkIPQ7pwVKgRLt5s&@| zJKQn34_Ca}1Pr9`znD|^0pnyL`&P=+EGW}5ItYTdx>`j)X+G|-%b(KfzWvB?d#Z2P z_4%4N2N#~>V*dceL6gcuHKW?}RY8$FwaCie7o;~*(UtPS%oK&#Leubk8-c;DkJ*>i zi`U!8)tH=mNcpzJDH0Xsy#OqBc(Nnpra9|K>+O}DeZKZ?ow@s$0A7rLfMZ?31&hc@|vYz4Y=7tb?$y;zNeCYM2(v#Lir z9wdK_$k~R7Ix#jYpJ1*ACyF2aqV9Qg0CI7&H^!*Nsi~T8jrKF236CfgX}iCkwn`j+ zC-Tm0c!ibi)f+3@s1KL>Xk={EgOMMel`u3#`A(iR!*f18;l4r(WiKnZ|B}0pArYqQ z=u4>a=`j;fdiWXW_!}QVUsgBWfFyAph1Y7oV!!hrr2Yx93|2N{hVP#^+%Jsq^pN^h zyKafK_X_z#PyHOU0RL4aRER?q66oRD1P!i8u;uQi{^Lt;NF#vKwx-9eTIHQsqiCWF z0&NrV(8d-B*2lj{CxmJ4D&!lF`8p6f^sYf=ujyPq)|r$%h$qN}s=pdAyD9;>m~i1w z!G?U6TgSbbH(y)hksKF#5lW;(toleX%-sONy0Rd^Tp592db-3=j!W~ckoleD9KoP_ z(0k!nAN&f%2UltGbl;MO^n;E-0|Mg^W5?WX>&EH9H_1_QH<48q&YG83K_A0f{)AmeeB!% zIiSKFf;PPOT4<#bq^}a}U|;QxiBHF5o_kZht&xSEijQa#$Oj2j9?hNhdS+{4HoQ({ z9QlLQvn$b@Uv-bcMXnSol$|0fwCT{FosA`hhXe-ly5mvfkJPKcPS_4=V~Bnie@OMF zlSAdExMC{FD!Lq=G@cR%Gtge2oj#QhrtnfX&wlf%=2DI;Z&5!DBudMXRI^XSMfxkT z>)-x<=W`_;9%8rmccYEGb)Xz*a{m*C6Wck^GM(xJoLW)0_-8_~o+?U(j^3S}Oq*-g zB&)GDJzag`K=zxh)^ZQk+46h_g#M9mkdB)^^B#{5=WullS>k}t=rh(}zhg3J=-flqf|e{?;0)sCy* zx<jXkJKQGb}l%%;P&>16-Q%8=J326Y*QxBI&H^%XqJ(q8M5mEL4CG{Fm9G;(UhKp;cyW0Dz`C3jhe z0FAQEwDWkRs+S+C!s~m_`HIJGG5dcd)cJj{G+LNha#_QES(@A&o%p)yW$^%@&u^=T zrn!ChOJQdms;}AVn`p(Jd+WQuc>Cqzan`S8rQj$%qu@yPXbFmL%fVKyQKLlHH#5Zr=A*uUF12q`&;l2%h@uT z1o=b@X_MIKtQ*QVYPfCzJpq+)HTC#=&>Zw2m*xxs_1OO#R$=-!jY`PjNsSYu0l~LsR4GS z0RBy%`ayyt{7e$#)j)O@z$U|A0W$tGN@|`KCUc=K1#uA(1lh66nfl#*Q*Ea-la90m z_>a9q|5zsK;xNb|sZf(-+1^3~E$jkn&wklm^F+{&?z4sc_Yk!sts;*|WuLY-v2jY@ z;p(r47)pK<27)(d;|X)M&fW6hN#Jn|$u-KR6s!KMwi}`O7>z-uvpL(|?#ULxdh)xAkb8fivtVV4}(G)cums`rn}7Pf_tL$ z-!oqLJ`CyWaK0w*IuH@cl{Fc9itGwtd254*Z}W~6n^}69Uh@iDekolKvw|m2avCUy z?8qWg|M%_BmR?p+tm1i1w5+9)jh2Raxvkjl&8YSTVGF1J2Fgf#mib>n4+s=6mueLI zc*GKp)Eis&oLL-3>UZtOvo_%W>EFLgf(zu7SaunYzlALGDC@y{L}Y{Spw4Nadkel1 z0q4w8C4M-rw6^-&i$r~4iPrbxdv$k*2I~_B$-D~`6?33)Q=b{kiz;Q-ypM$A%EEx< zC$nIaAzvGhW!YzxIv#ElBulz>dz~@=u1^80A{f5;Nbcb3DT!n080*D$ zyJ`@2uvmS7f74|hTwDI-C_)ynxNSnp;KDULV8HLfhBt)M`8fZ9)Oyg>2kjg%Fr62R zl~&6uJtwkqoJUmy&ndkXv8)2sLysm@0c)T-)UVe_ zW~#7Ia=P4X6}*xfO9}CImmx+yagutcMNiHOa1}zxm<&b1k5C?rlkSO=#6k4Kv~!&^ zo@+d#M0}5B5Ui~W)5y^&p?hOq?nbhgLx_V(x3LNh1fbk*}3(DkPSI~x4;V~7m+>zpTT*D}=$xH-c_ZBC#E zPaesVty|R3Y@OVhFJR@Z{@G`GZ7|Ps^05ze^MNl?Sr;IgCf?sH{Z=w$ z-{y22ASM;Z(`~rQuQ46R@pJS8nQneQ_*An#!6mG`khv z&2Q_>VtOfHl$ae)fiju_N!oPZhJ8Xbn~4O80vR%nX|*Jd<`?56G1AW{GdgFfP{WQC zJ%*j&l+$Hn_7SYDi`2bzo2P0OfSL;Vm=J2}HDA>0aZ&;r8C735Ozl?Jm&s0Htj|qM z&?|q(7M5VOj#K>+nT5%RstI;!o@~ze0c*f1NsiGo?&)$}Ust6(H5x;)XPu}#w%u#* zeTyu};zC|LuHNa99OE%!OP~YuxUgbdg3TaD6D!TWlrEr@HEMD}U#_M9(`B)O|Bvfp zLqCsRTTmD<`t(G}2wF(;?ERx01fvq|yA{(Mc)diPG{-9F>0`{VRQ8~ya|}H8i{J#i zm#DVfr>d~M_w7V?0%lb_EGaem{eP+r1+GTnZC?_Wn0{2hhvSRN{ zVgh?*b_R61IZU4TDo<>s&*t-8i)DeVh&2*$mfn>=Bbl(38Q}a?$tnDb| zE#Qveq7;UrzoZ}n%F}tW`q<5NfANjBDbGrlgSYwx_kk0B4C!SS?NSJNi(+DH!hAXe}G93TlS3RD0kygz>fw9KiF05NV3&BXWU>jaEvfsewq-D`zBb&3ki-RPPk{+C%K%ZCbN2DQU z5PQvHjSzehfnJ%71+DQ0%^c8z%iH?hle<2M6Fy8y&{!*h-0j*#DU0LJ?{k8f z$G%!$nUoDD*CeKQ{_JV5S?7CGcL2)A?A(`l9M!H9F6}p&th5`ygU!@G4eR|O#d}rk z+ncFr7vf9;w%=g*@EF)WCDOmxS}&!mEyEZFyn;e7n=kYP4OO;dzqaml{ifrFv(td} zwIJ!HCj&yM65UY$0M5?tAP4@VLp7Ckb>;cv_zuJTKIPn`WQ@yXn*^Y@-UXlB7c>yf zw_w!0;DDGR4(>HNjnfWcIpZQVlo_=>!}N}@!;CN+eV)`Lug zojhuDMZm(bNYc@=&nu~Yynd#c@ZGmijmKcn@)5%a!s#`%4edpcybSc~sOo}VppMwc zPew_tc2M0!pb?L=$sw49*G$&qBQ&zW7lR|HnrO~lV^C!lPWHyM|1e9itN`vQA6&>1 zMbE7=lC!jV+seRPs-fFde zR2Rc4GWT1o{G&H*z&@f`Wt{=vdT&6Y9Of?0i9BTR$Anlgw~wJ`dRjd=``Aof1JU5E zu&0&*>Aq=>3Ht~zg>ZC8FE9m@U;xwdG|Ta|ft`&W^Tc3!jbj82hxZcHQEmj0K%gM5 zcoB($L(BcY{(}96(<^wJ!#T!mI*{<}Q1*hompACiWyBZibZnYaLbW1- z2w0mgyXx&rdGfTbXB)`>anVed)0=jLgjj=>qy_Gb;R7g9NKC7TC5-x?#9>;nIQyrm zg*KZI{cPHSaHi>`tWWS^*~~-jItj-i@RaK7_uznKuy)e?5jp8jEBZ7OY6a^Ta34wah{BN^(2w{Or z&oYHCipyF$?@y~Bw)#1JQ|7T@(}$|fI|g8Q;e3!Qt!D;bXq@XDJ{9X%d+v+B|;EbKb3mf{(4IjRcLW!e) zWSnykji-Z?wsa3eYJK(cR7=G2AAxx`4joC{$850yx!wX%_Q!eXR3We@8*^WJ%_Fbpno`bT$8r_ftNf~N^{)=DF2#tLuaMAl=$Q=YmkJxQ;5E7Z^AWC?0 zGtjH)gj`;*=gOv!+YS+H-Ih;Bhn(eTciBEe&K+Sv9T8IDn&vD>9NK@AWwYM*;OEnQ z5~AUsh}QOKnQbCrEZwX(sA#VW8@ip6m_|3cChCL{G52X+J^%HnWA`$PdL=h(%1f-} z!Z^l)Tf`SV?7{G4R!(ZbZgjR}0AT{h8xHO6F!7}(39*A{QWr}B_c_N)zVi4l@o`JN z{fY7Y_dABr_r`>!7D0_=kT6bm{KbLKM;GX;prDSkBV0 z;S=HXgq4O>2l(X!{=qhr|6n-@s!^W|mE-;Ab1+Q3mUE1V)$(OIvyHIx9`8=Ay?@Ga zGPXp(vR}E(62>GglB>Iuh30-i=#+aaT#d)R6G%@A;+vt5vN>pB)~~)~@a8%g+Necv z=02))IMjudFs5J@pB*s9xou@f^H^FJ)N*P+H9hsn98}LW+ClDdO3!?spxyDa*CV&3 zXKqz0B;?jC;`UR11j3*Qscj7_`ZWk$B?TY0iN8>V`E0`PTPIZz*YCc*pBp6PG>rw0 zX;KfIwz7WxZhc$tr_hTL(TLcXq=w0iPiRf1lnNqsXx?|dru5eLOE3T{)Y9A$MwKX1 zXPE*w8sB7xpkcTuDZ6lS^K)^MMUvy)We^uIu>0{{Fr9grxlzsq5T3n$nJA3^guzg9 zOFm1+a;nUP?jfjp*(&U^-dVo%p$qBzE8Q?G!H&j;y2i^FpP7TUvs0WLbHJ`#{a9iTM1hcUEPN^7?N zw#%9iWY>Wg+yd4V#sI7-Skh{ajf1;fo_S5DP2g?&VH-=h35<^) zY+mWG;XAO}k&j}GyO)S_gW;Fwz(D(B(C$e;nSBdeM$gj)4v5x$~n>$nG@e^kr zCBMU1zMu0;G74RnLP9x*pS{rX!)>ND6`{Lviv9Qt^Vc&Ip?NGAF%i)UD!AHq5rlixeknNq+QcIc8P2*&RuR|4nfXR54KFdZn*qP>zF#vbJ? z6UA`Mu@7Qg`m!eC@wR%mG~}w590lsAkaSo}D|dSRj!|t#o!*Mp%M<~w%-SilXaePo z4md+sYbUKAkrCMN8dJzs{QXy$L0a*1x>GBQIx4ZCP#eA{?YPcy|SE8FFmYgLR&0P0Q^qi~XG_HHxVD z*mAH<`+T@aPkcSn%}_P5!(M25x78fq3T)$Yy?Kcm=_V7 zHL{1LXtGunNUD4kC*!Q{0(Ok0l`J6`eq(1^Y6j*dqwHx47a2L|BziL%Uu?tG2Pzjh zk=b^AkKdlp6lp6cL}(xh4~1;u1605>Z1@t)k?12QkA2XXXolvmm60;2aa8wIIC{M~ z#S?ikMMR1E?W$$QQPTounEFcSAH|p1Dc%;FRrk_I zP@6cMqJh9bR(2b#XZWjyZ(LZ7-y?n&p!ibaQL}o^sc21(sT^~quaPJPO9xUyxSki=;bYLh|Yic!l1?crpBG=nbe zmB}be5f*DdN++8TiT+4qvWxH*Dg4@R9sUkp1qd3Ww0ZJ$+ywj;V?e%av`;e0M<6cT zGM&Iw)s+fK2{HOi?Sw9dADHhGI>nJNA2 zRdRHwsmSdsYVQ9&X2#_-=Tb`#!)Oh;F1*}~Cc^L>%Po{y{2LduWu=Z~0HG%%bb|sP zS)R1;=5o$?cee+qRg5n7gbQIlw+;(c^SJsTVflbhL{QVis-B}w7GOG+6`GwIGq5a- z6QJ3KHp9WPXF==-mD=j01Mi44LPuVWFbjJw^R&`JW&g_fVP=qOik5ebPO=(D;;u9Z z7&EBpr@c(^(hvYSvMO5t)ueM9fD~EfD8xN&u9AN$nI{Y%f4+k0tJQR(la0Zp8Q)7r zYgqh0yC`&jG@gz@R&Wjf5yHNcF0UkBMr3!}G2LA7MN+~y#qIfvgog=CC;9^8hXs!k zA^1*rj@~-#*V2eAeaE!sqiEwwN5)w)4K{gUH-sf;^Y2KGHrwitwl^Xj9QuM}KlMUh zPh6U-&7dHuKA(DBUr*$Z%hPd~dNj;CeitUTqZ7|gTy`s-Rlp5=jpclNsG9E;9yx%~ zV8IgBNa`vJv}rSR#EuC>Tq$zR+WJlJX-msYBstRo)1;l^!SwKQi|o;T$P& zPyuKWJ0K%;hN)3LjG&V(k!MgS_%Zm-63{Lq3%P9$88PQVD6=h@eRS&psG}Q#^Tb+T z*qD4v`2?Mqvq#k|koE&x$Tn^~82{q~nC>dO@K8qr#D;MTrV6?jO}ACMZJH<{SH{Y3 zJ)?|**C)>DnGnF?BS`jhme=mPQ)S^))THQSeB4J`aNcZnFwiCdHzQqw==RK>=faFW zJkaY0)I}0wFi)M!u*n-Gyc=_R@1HbuP+_l#yuP}TaPD?(z-}^RjmMp&xZ@Y-A=DQh zp9BM>vwz11A`vB^LJeYl3zCId6V95T)@g690S*!M_8nTtRn5TR)e#Es(4&+bMe<77 zBLBz;B0aG7vdrFLXdVBF=bF}S5QiH}=6Froj$+Lymjp*Y9)8ZT4cF8)1bVwzsnPNK z{t5l?AN{>id@q{0CYMs zU)0n8oo%1B5M%v`X}b)N@Lj7a9OoDYSTfeZ#K) zGmC6_785}X?UG5a1VjhsVWIr5EG|@k*j<+i0~3ETn@966d(^)54t>LJG(>F=WzA;( zZ_^U_X~SH-epBGPx|fd{Da9X@I48(hn1=Cp>Gj5O?7%=6_418|w`FAd-2R6r}c1Q#dDZMtLHm@XB&BJ z02!!pM7MmXNrX3N>V6k;0@QhjG=RX6=_e|Qd<+9L|JFq)_+7o_c$r@uL zt0o%3zF48l#82Ol=vY+kE%W2gCUMdNLRNOy0dL=}!aZg7!3OJXu*U`oCo-Yk+PFoe z+MPp2TTc!<8fefvVSqeYjaB|D){#Uc(c-)EO0QmnBY;<#-9FAoT)ncdrw5@^A~PLO2PfbLbh28_RXYfXAHSj>b}g0GmXStQ-PYCSt}t+& zeOi)8K48m$JQ>1GE$SQvz#UnZ6>PcsXOI8$<)lLs69j=?5lVJkx5JkgWuN=}P<=Jm9={MYO zk8Te;fEq*goe@SG(fQ7#g7vDGowB3_Yuig4VF?v@<*(QbWlIYzKnCmz$Tw6gW@PlU zotuuy!vUE-=Lk1rm{g!DD2?26SOyBuJ3Eu|s@!Z)GRtq>o3KW=Z+blD1V#ln4&Aoo zq`bMy;im*!6x##_Bj>Vn2nJ*@ow>sv@6fA9B4`nn<6%2t)pB5^y}8Y%N*OK-oTmAe zCAu(uS-!-2_BNhQRWH}AyA*Dy8IG%C6x-iEx9hPWNEJ8(;Bwa%Y!Jl;l|(fbW$O=B zZePyY=yRp2Bc2YYH#Wt|W2a|q@vvuHp49872DBD!#ot`dx!d@i>ql_tkx2n&?$yxR+N`_>r3TfKx6heFnP7k$s zUQUuk1RZw$ORkb5C}h)$bJnE)>K&^4iRy1Z=;I9UNEVZ@oT;<56I{dYUO%GD;@U3BTcK>Ks95LOOSy#gKU>Ak%D%2NrG5g}iNzrk!>(&C>J zRhY(6?12?ya%^pQ^YB0Ygsj@g8Go#a8Hpk+q0~rz4U|G8gB5XL-xg1vz)ZckJ3!-V zjRnMQfeCZ6k{1uo0|(jw+SJX^Bazo%gdR6~&Q~wH%d8XNtV`@F$oMaC>j+EGE?N`RTQIE0LD!?t7N5&({yo9@+`_GYSrlS6;`-X7MyyaZ4Uf;rkW)zZ3xe4w)6W{Qh2A_7PF)>|ALpt6by>V}lpt8~ zm0Og$nX=f%DM7=>aKmAo2GHi_2Xqt=k#1boB4QGd=yJDlBIiYBE7aa-LcWNO#D84ARak<> zS|xVtOa{v2H%}gn*)jM(jrTGYOMN6nsz2M_qbxP|nlsc|Sjuya4MaYMKm`mcZ0y7B zr1?-`J65P16MBV!NkXE>ZJtTBZm5&6;iPe;RS?np{EVkNW1?nPZ@e?Xi2Ki}*#AB# zwfAdV5TUsRTQ){&voTQ&reKG zUHq>J))w}*H-E1Q@sI>==5kQ!_#kkb=u8{8k@W}|>w_dtpG+2xodwzRk?&Y8Jj~S2 zH?HSkvPoy2B_{TpNvlpz1gsu|wUadM^^u{EU%-+r(5j_YhP3)BJQ_Zv@eY-0{3O@{ zIn(9w)DkJM&C|J)r*CWGxb)#H%{NmKtNkw$h5B-h;Ax$14^0%7YjH)!Yv-)>iqC8` z4!4i0Wjg+3M?2PijX*DV%+`{QebS``I>d$Npu6ms$Kz502wJHP&8B~_sDFzjP6xmDSie2sR&+9^S%US41M z7%RT&rvMIo>CpE#8sX+FoyET?;|>jmv*cpH8>mGh%>%V9Y>IxP8nu#`xJ=AcB%<9b zx%By7`gyE$mgRw4lRm-l;LiwXFOp6Zws=fBj&yENYF09T8ywj4?$#xqPVmt(cr)Pv zHkD&cDv|6FkXe_5E^eM4a7vbChA%Tdgr?q+)Dkv?KxJ*4KEn2StDNiXKN!fhhpzl^ z+Pr3&aQZbo)XcZuSusP2YhiJzB6SoSaUu1S15>Tv_B}7?s~11cw&Jnb@X8f5eCG+A z>$2}60X^`}Kc5fYaujS7^|*rTv7-w~|I9pJpMQ>kr3~bH@+L?o&uiJ}m;XbI+WBbo z?w@DfJ#a2tY_wn1vP)+vf?l-8;t2n31WDponpbsDQ@vjiL9s=5iKO`oF89ZmNL&Fr zXTH~vhG*GXuz<(wP*O#h^yuQ7HHzj>a*3L=$e4^nYXa{>kP0zi(uT_C?KwmP%a8L4 zg8BL$Z`kp45Q@`v>(sEI8|{z#)c7_INjmV@P38u&krw2xI*gV^Z*%Jl_UJ`F!TcP1 zMePKX0~T#T5r*|@<03AYUJpuVH2k-b8dnEx1ir0<)j^h~mI2J#1I5J}1U0n_nI)!Y zoa4NZxo39P|{7*@k+Yn~a~+e}DiJ&gDtLcL!C9;b{FE zgK0D$o>6vs#cnw`MbRuc#0CEuSH-L@Jv-plvXiZaOv$27hdw6&XE9^S%$nydwtWmW zLYoJ(R*j1FVl0r5O9w~+&qxzCzo2+&WQ5Bx)lYMaL+5EoE|ZZ))`Vym3WFp~FVb_| zN=CJtFP{1UcvB&B0-Ao|AeX)M$;4a|o9@zwtD;KwFs-08sGg?tzujW|y|TVfDn#(x z00kE&v%epw*^~q$2{09a4tOhu{E4ZP!3m)B@$PGN)bBzQnheL{8iAd~&PaXsOXo!nNo+9?UH z!mnEV3FQe~A5{ zOyI2E{kIjSv2%gNrRhYtF8=)a9UXDP&-m0`2Kx1CogQQ1zgQe^t}^zAdw^8KN`hT? zU^tc0D|>Q~(vS=&lo=W>Kn*VB>1`k>U&zyopU6tdcO*etbsKz>YWx;kq+YM~PAP)j zrjtF-`~}_5+UCpUny9|x?fLMyvevO(@+z(zw5&PpgDU4_`v@CA;^OX3c9bzL&vd;$ z3rBsLsxFF`sN1848Bf{bP4rT>*%B+BMaOd`e055BFHEuK#%l9vMa6|zh@B*gBo(AS z9oSJz>-P6}(Ls&1Jcl{R;gD*+<&wij5xk;#Qp)o?8Qsa1%RSdPZ}RQA$gGJ!@u%iC z`*dGHc_yq`Sm&?sSLt;u9Oz;gXd%WE_;pvL>j&BzWKzwkkAkh1{SL)C;5{ev6@td; z2Yfig+k!r7Y(HGOaG>E7yN!Sf~=!vX!8@ur1 z$)lDG1dj8szkd9hJNr)_>ODfM!x0oIo}IB@OLVsK@jjAiwZwEdP6cFJv6~s{bX2wI zV2!An=py*Jg?WsAKCeG%;}@}1Jf0Sybvw1<4s;n_4mBb@&0ok$1Sis*EQ$NoO8zK zn;z=+PPM=}Qf6HSrD6K*77c@uJVi4OeGr$$vVWx5he>ST<+m`;u*D0f2(A{iE1-RgnMg4!pD9Bz zL#X$w#_E{vvI6ygF77@5Ez2Kh>Pu1l**&aWsd_8AQ}xGz_YJ|)gb4_Msoo|%{M{l} zYaIDmO1q7QAurv1Ki0o37*aPy$jkr!aO?K_)dk|THPCZ>Zh7tlgmy=3sejBg9dsM- zg^TgOiXivwe_jxLniRR2LJ@RC9T)W3Ak+1wN5oBjJgYNz9c$6n4`O~Z3)Hl$W!$pz zSP6_$`3fL`&iFDuXJ#!Bewlrt@3LuM6yhQ7zWYg`=em2xBh{W>W2)zl3JD}`0AFaS zy(-_iX_`(~?oidh^-8G+>h7Oxf?Csc0Lie0H|#aR&cHE0Ug*6fFS4>A(W$@RHi&sgo7sDB;;{C`Bua|K5XF9EFv#L&0%*WXqJ>B+Q^w6 z9a)(riIU!%>pO3HkMn5sMGOW1fYE!cDhR+Fn#)hyUp1wV*@4R#gdIKwU&gG|I}TsD4`UKbB++ z^1MYv8po!?R5kMYOfSrR+f1gVi=(y2Ws)9c@|m+a&5#i;ix-8{{)U-?<2sYb?xoyobJnARP2m(QGkG6-m*!C4$_jO(ej&+oEfEokdPla91@U!U^HVKxE>1W}J0tLqlc+jUGE@OSstu4NqnDzvcJ#zc6xh&g zD^6LxfYL)47KY!|yr9F&l8HbH^%{e_Q$UW3ku1!JLVazi#zV=@Fei77(;%XB_7Sok(>6ZzgZ-T@%VC&8V8Q?@aCyrJj1gZJ2D#&2UVYq zPg+xjqZfC zp;okl&F+o+>y?~hjepQ`Ni`(;I%IjGd`cgSI!Rz^iF zw;+`~5GjkgN9#1Jn`Fm=8DhWM)-H!=GTIgqNOpn>*xuvdANcE67RK9dhxv=S9Q(fF zu;WH0ROc3#n44<=&q=z0Z+xM$48`}Lw10J=sUQC=+#9~ZLfH5d6G!*t&WDJvfUD3% z4tGpl8c_Nj5>)x)q~#sWSvRrFFd1x;tm4+ICJDS8HQ^j^hl?=4Zf2m z+Izh-HS2@qD?J({|oRr`eKJwZ}72F{V97NZQ&#~Tu3ci z`)67K$L-gaptr_k->B80j z6Z)j5l6hbm{|r`c|5w5l>%q|m*^!{ItK4$fyC2p7g%qtzcfx8PW|K^EEp2fXTQMwXty)>6AOK44yA^Ou{+NcO$VYIRVC%o0 zm#qoF1*7?2C9FHO;^6$9>S<@yo<9$Ki2m^Eb&8kACg3}kA)@;i_ZkNKa~Gm9)$7ky zTl}u*GBs~7TGHE2n3fo|e2iL5v8ijFA!(Dgun+L?@h*)Rk)azZ6oCbAxSaepMmiV# zjii$RlCmdGZ!B5MHBf|o6LybZ4l1@K3I3_`iGK^jihmeSl4&^n2%Q)RNzlG_`ydsM zy4qd+NMlMr<`whZ1M3sq5@4F1WK_;z5E;A1}4?i@pLrrAqll)Bs9mgtTBP%U1c zCBbB$?|&zn{K7x7!rR|bsEeX66*BUW>g|+%oaZfp1ji)NyV~(54K459Nx9^5ejjb& z$bV|)f{>tbc>L1YdZsujf`uXV8{Z}mfi=7R6sN1;T@_1M!^xYe{PU}e(R{VdvK(`E zmkKGFqD2orTouWW3iao6DSG*87XVC^+Dsexlc&IAl_VD4rR5Zf!IvxaFB5?aw78ak z%H@m@rM#(}roJX44WpghS267}rC0VE8(x3fSTK4=fVe=j0P;{7E!_jMke)+@!A?Hk z*1o&=vhIBU@2BDN_pWu{!$c|VB%{P1VoWR=A7=-S_3;v`udaTE@BSv|5Hg=Sidt$4 zu(Icb?DA!w{}MOSOm=m0rLE z=(mpOt)9`U^DG;>+orQIPZ3E-hp zxdzEmDc45CgPfE(>UmGI4C770o{hoy4V~Tvj1l;{TC&t(-}_R(Gnf&vbdM`Si&b~B z`Fz$M5$fheHT}+7uyw`FX_~T_?uM2tcxS9|^aevDo}`x)Z=U!%gXr9uK3S_xms`6_ zCEa2(<$RuGGP`j-NFa%by{@NL2lJXHLiS|G_t^*-)wG|D{VjEF|Pqoae(ZnlKU`#rnO-*(ckG2@oB zKsLjg5-PyBEYztLMDYa|9bhE7)tf6+N)g-S?2oZWVbe6Vl7}UqG0u_1SmU~5W{lr> zw5*1MTp%FT+c@wzP&J2Cz3_a^l&)%=7JT(J=OUYIMU0C|5OLR^*w@V>^vPJMZ5EP{ z8XR&jGCo%%mcyS>c!VxVKUsf?s;!Gsc_4`@y!p8F?Ln%RIE>W$Ps}PhqexOw6s}`WtDJZ6Wdo~l|xcp9^ zY^NJE$gC)Tbhcl%=}H=xOOB;_@=EkAjL9d<={;AQ!@_W(RYBc|Ma|B&#d5dLsnx7A z!l!OIRyzyZt9-XL+pvp2&tllvYrV%RY2K}twQAiFVH}zg#)&AyJUz24HrGQ~Bf2iwc6lzN!cX>U4;Y{n&NVU*v-ZQr6zcY@L(M?4SSK2+#_ zzoPQa6Am1wy8&*)A{;`zO%bZ+!Hv3E1;n0;u>CMY@@2=7!~LY?z8D$-ors6>i9)SA z3TIg{q;1Y&T&L`J6U97dy&3-`X@%>X;x_&@o~m@%PEGj!rw`LGo_AyoXl>ZPk*S_f z*7UX1Lk)SX@48oeigN{He7%X~+Db%;v{DyYovL3?z7x*o8OwDW#mX{jCU*9U1rOzJ z;mliGw+!xB^@}0a`735Y?{7IYKNoZO&(u(g1!G46FO&e?9H14in3r%Qg!(E)4bonI z+Yyd~jV~v3Fx#eFaoKn_))}9du($Fs5M+$83Je+=rj(VKw|y~Nbw7_9=<>4ja&Rg! z7MV9s(=dICY4k<$Z9H?82#A9@+ezyKy1b6#@Z;|;o(Js&1cng~1@D+Gz7AAjT$y5UG0Ns!AyP;!9nyA6qUg6eEbvcdxU}Mm& z&8;3FuY7qZdO-5Wb?|f0k0}KEijSEPZoJ`yowK1JN0e03B3ngl_`=`T{T*K6wi&@D zmBQ_S3MBm6t63pMV|>yI)PE-5R&PNq{+>q#*PPOHEox1~HWOTTm#2T>v+h_S&3LkP zqA;hHcr+$tzPXn%#p@aS>-Xt1o#EY*AHRN0SFQ9iPYs{gdMx0r9!$P*4yW7~c+=Cx zedZm3tWuWUYZ%u(P*+@SS$l1+L9OxKB5%<}*@d=bs#$~-X&_kVt^_iWD*1mLdVR`G zm;bYt((~pJJbu0p3>V!H#ep-JHO#9&{Q1A&l6bZ3F)EYIVBQ9?7ErY!;XT9^VOk&e zs_QrR5Kl$o8mByRzmUhSWj`uMtUz@CONpiUA>!7|^?pYWz9Zof{8j45%0|vGeS!$r zH+2{nb==J53nXWkw+YKyz>c52-d)dNCqcdI_j{Q#8L%zJi5zpVu-!-QEz15zG&%HO;tF@l) zw;jqoE!DN6TQ%VQ>7Gltn~1h&qn`)Sx5t8Usp5~*fdt%eEi0=J#Rr^^*j~?08VLkr zeg@6;r13deY4WK^t!y%!^;Mp0CoLIQy6OS|7IyQoN26phv{%23ksMdY z5lFcm@3ikzR}-id2;iE>yeshC&X6+U-5-@Qc4-xIB09 z<-uEUjCA{T&GBS+b;@pLVBIUbHB z*j|QPzkE+wR-e`H6RidXk7!p+<|0W>24o-M7vq~sKcIef|F)&3$iI?_dx8K0skpe( zNtTq!HzYoDsNUrcYFQ8!+C|v9<97PlR3>&24(A9gAssifzxZ<6jfrwrmRhJG70+VR zG4qu|g*g_pUwV6m!o4ui`|8z`@OLz}*H7x$*(~o~Iibw?tt&gNd5*y*r>b>0^E)u{tY=vLN7q!XDh^^I!w07v-ce|LV0f)(oBXp?*e(}jja*19A$g)_{H1iLbHNF9@acbyjA;9$>bf#Ax83C zD{Dy?r*cuNQ2XD%EwTrJy(xPPLBei3UQZ{2a}4N)^(Zsnp=fI(`P-N!wYU>s2Lfu$dJ0BM@yhtB;|ZqVx>myME@@=aByF%2S-0ulCId z)8Dn@%QPKrrZ=Mx9F8BdqzB*@>TP5O;C4G2blnoALB5U2+Ly z6tgPK)hv{K*`Z7lEW_ku75jI+eSZOh^tP=1mG4k@+sN=ax}E9e;O#eDRFsbUjo%4U zoBZBneB%%kL%bSgyuXTVr8)dKt$(3H#AQg{_tLL0$72gp2DE$yo zzpT)<28wj8v#5ceF^{fOdup0$T{o^j z&MCXJMwrhPsx40s2CPwSI4+c}KV-hsde8XrORCiV%Wia9n*N4BT#wFAhb7C;$4mro zU8CGYT!UjsAz;{3`}!CB*ztW)932scU@;oA)K zEfwte;2cTv{eH_g$vX)RWUcu%=N79Y!TL^$aJyWW8pS!e&>)-X;RUK=MEdeKWfq5| z*h)V6HsV`hMCI`I^vO))kTUrwl8gq_OsM!r`QO)7g(w;L0vS~>_`s6=Tg**tGJck5<8Co(A^<7zE zKYL#%XADj!hS3>>^aH8n)6PX;4o1gNk@OOus_V(&ShP?3NFSk;Ayvo{>pdwXzqn45lq69qrU=3=? z?*$FW_zdI79*0&-A=fI3&6zVrzZB>KVECoCLwTmf3WuiRGIE)G~?om=e4ozx!1@mO*K>6e2hMsiLn$0M6(eUa0Vt7}|H{Q+KIBhC+&4Dqd z*_Yz4iB7gP6Wl6+!0uD2UJG0HI?!!vzS_IjrdKw}u;j(nBpcs=h~?W2$qHb8M>Cc(XnS(+%z6 zYPyuwG|^i4^*VrJji67SX}?vz9Vv|y62;=C-IaYrbaK__lk5Q1I~zjR){9=ryU!Y$l-dQYjV}-vA4cE4b}R&w*|iF)ws!p zzkVTVITo%v$d$yc8M7O`xX#6nX?rZr^w)5naOizdFa}GmzQ=Mb5S5B8&^LdTri@4n zn|mtW`Y=TUjyLCn%}m+LkKDdKYkbnnN5ovMD5#$MY4E;AEk5^i9ZtQLhxpw3D(P)S zhYu6m(gJkbruN&lSDWPqpY>*`{+0{#op2Zc{J1E3@kYi3*)IdV5AJ>^SdEvIt9u*& zse@8m*y_`(3>v1;J04R6vhS@zDSu&meNe@4yV0wWHV5-PLD3?CA1f!rN$A>#NOJLV zsG|7NBG~R=1-m-=Uh(YXGw!l~)guphK=QVd$!-e9|M_-6a=pH4s_L1TYgG-SYaZ9~ zx3-Ou5IKMC;X=+ar0F34siaA$<(?k#pWF4(inMF>t-}HLq&6!T!<~YMPy5faMn(w@ zPh{`EMis9-R6}Klq6-9MKG42#&*4F=l|*&X0G9aU4+wIBGQxbeo;jufE2K*>dHCdp z-J|pNYWmRwLTc4!0Fh?(>!{8fo?Oph{S(J0>4sX4k%Qk2 z)8#Tz%UFH`9NXEe24YZ83dm~R-i^UZJx*_c zn(+7Yue`YC>eT7KuHI4B@Ul$R{&})0#bEcDN(T5gta9Iv_lH*ZgC4`;>b_QhTRxKK zoA0>A*wL3E#(T)6>($&juAQ#Np~A+1!P&+rCOjU!7dt0Lwb>pTwSz)1t1#YH8pLtm z%_=7-A5HR{^Qt62VtaSw%Ve+Xn|Z=S{6e8$D>Qb;?p5N6n!tIBo`D|OMd_tH^ zbB*FCV_#L#pCg62YM(mXv~J&j*ekS=`LQc4WjGstKYq!VOjp#JW$xUj2u@ z<0S!=1Cb@{Nl;}An>1VozMY+_lD`0S1)6sQ8dx8VG|a+9s}-cy>?6 z8D#O~7(fiFs7(-ajxpI|C877j{eEX;jALY-GU{Fth%uV}`>1=3)(&C2I3L$=6Bj@A zXoQK5V7qIl8^^iS7WIhpcRe+P4(*Ra+?uaQef>MVW3uR4Xx=2s!^9sD81k`h$$M_; zSJ<@mG-UM&|3d1+)F3pEbT;8o9RS#DZ+!i9G@Gc^76FM7)adoxK7H9|^98whv9(q) zUF@{|7JEKue}CKDNI0L?K4yOEXk%1Kw(}N_b&Q;-Wjs6a&EJW3;0i!CY|7i^@w;Nuds=G+x#%gU2tUL|g3{+otq9Ge52!kUG69qbevDvd;}27M}r*?I>ONfH*&t zj<#A>4hh&yqv6HvWuJQC5;J^1s3go0pxVszhC)2!<)i*ZQ89mO6_8DrYRV2MQAOlP zA3^?T4^LNF#xfv?)p)4Zm?)qKKmXL0crr8}=z)m#6Ds?(Q^vZnx*GV^R60@g*A3J4 z8icS5=TWk%o9#@{RFmV_7XIN0}Zzml&~lKm-8YwWX-@1qEKEz-jb_74ca zU3VaQN7~Dvy#<>YImgRe8dktQ3Ox<;zo)^6J=+&QmWm)>j%`Z3r^0VHzI~Mc-G3_aw{Zf)|&|dJQ(pF~s@cHu@F3$n~{pvb>-CeGLDWhOZ-m(uSekPHx~9tRaJuTZJK0Hegq9;4RNaeo54V0 z<<0v9W^oel4A7#wGGE?~orIrjQq0an$@#XqVVn>Bc>!DGH8j+Lb%ln1)F&?7{2<2+2i*c!mM|GCwO9o$IQH~ z<`B++D->hbD}^nyl38k=eGeiDrXZ#MHvzpNPO1%vN!Q9~3qoDJ_xL6KZ+t^b+F4A& zmRVEB?5TIZnTGD;dcwR_Ivj9%WS!0mO;@YejGT2m)%QQWwDDPdIxah)I2FAE?l%;5Emv1W!o~Qe|$GiKbStwB;q#Apq@%+OmNj$xN3-3-O z?sR_ZcsIi&^0npDF0|=HSlX;&*VwOLZo_S_{~C`czWylGcEct~(eZG1T_NpE0xuN2 zGM7eC-}dzmTcNHk5vzZX6O-~RDil!K!*$>z3c)Y!obvK0a-#&uTB-B=$1$ts{ z^Mw&cssA%>ydPcv?WKd3N%|qq7t#a&zCX-=`7xhl;>_y-?wmv*Yb=fj*cllAK1H06 zkXC@GOwgDdl*$h&qwdmKpc9@*6T(wQ(LKqn>mdH(`*{rx6%cCZEt|9sD;Igmg>$=U1;|B%IGd7d?B{0G0qNP!M+ zWkB*+)#1BJ^@#WlSR$m;ifjoblT-NjMNiQ!R35`x6}CwmFxtNfuDyVSQtB9P2(dOc zpbr9U1`>3Y;D2erL(gBV0W5~x@FI&~pS6ePpq8N+a7m!wi$$lUYoCIaq%oJU0xD1c zVe+Grr^)>2A7|11ORAUxFm`@4;`K3y4)vTWKY*Ah#r7@a?rm5iDY3e|lukQao>9s%P zmU>tNyupBri4^|X=i&am<_RB1T60iFy{Gu^w*vn?{u0zY>=Jh0rDiN*NsHf=DK>dChd+$4pTR>JAJs#{}$iMPnL|>x%>&}mV z6$zC%kk5e5^dz9Ii++u_+n^qcT6*Y;Ba{^ou>o3J7Wtc1w!y)V#QXOS8#|!bfXsq3}IiNim$qefeXKEGza z?GVSAHq@g1uCLUINk0A|05L#+Ep35b3oJK-i{QC3lVGk3$r8}R3vBu~Jg6gt>L`{2 z{nyO1qTNu~1vGdEO11(0N~rQR^$U8(D1cEt4XJDs$6fVz?}m)z?jvj)sNW(6d|nm_ zIv7k+Vn6@FZOuFp^|cft5kUn<5CcmU4r+DWd=Q<>y}NaomEn7!sMZt*bWG=>+p|O- zpjjC4_MrbsVd8H;T2d1{z;X&58=0ckv^CV1r&A83z_Y-3{x8nzM^;uxogws2Y^JAj zrXUEGtlyVzs$Z!M;z2*Gcj}H@5pnR`P|z@g16{vGxH-k_-u}`Dd=v}eB^)dv2y+hc zqW&7B{qCc-S7uoqEB%~tHRJLVG?TI+0BNe@0Xmb(a3{D7o;zF^FGf$7s`xHw3~7`| zeVMm7br#K}5LE|k!o&~h3L4!%bDMR;Dvn213Ylyqe7s@?K_ebCk=Tk569eFG>|BCE z$IXwQHMqo7U4WKxlK`|~e-4l^rYeMRRQBvJT7|oG;*Ie}Z-aX<@Qnu9YucuNfnEql zNnj8bk1|FfFqeUu0KT1*W^{Rt?=_`B6DD2Y?KE(a?;SIY&g-><316D8)@TcY%3vVc z4fZOu4bkAlkAI49hVWHZCCB=`7pMCW_NqA<$bnb(Ke5KQt2+9WA6yf@2b#Q>K(kmN zP^p4gYenB99^2r9X7>NCjIJsJBPlSnx!e{c)TJsOKsv)ouIJmUV*QrZ)-i4jV6JV@ zrcmTpDD_OVIvAQ!h|-k=(YpXEMcV3B7;OFmbZ2T(Pi1Zb5yl!tcW6t{1F!LQ^uI6k zuNW^r!Gwrlj}E{VKz@h9(8+SK(68-s!uuDv19#OB0h_~wvjO6U@f|MlXUBHuI@G`r zz%md@5^{-xrj@kXb!#1YfEvv0wMIfR*+VWdP+6Zjc#n)S=-sjnf5s9pBOr@FRiRay z0db8Aic#eAk5P>=;u?SB;v($lDYu<|Y7Utm_P=Kfcz5b93>mqo$ns5y111TuqhWaE z@B$f%7hU4X5P1!~fE{i@DN?1|x4V;}etPgg-s#iz5ZerT^@rV{0~D#`YxyPzrOk%A z=M(t{giAWn=&(@qn+Wl%CfO>CbYs@xmStN&xY4!G4m1clmVd^GEfHtcY z=#K%78zAKXrfgP^w`0BZixniQKDF3nOD@{1-DZ~AM~P2&h{M~k5|iE!E#mFdy$E2u zl5&bV00|=5sG5Ur&qry8A71TvePA5(rE>m$epci648pY>u3k)S#nJ)TNIaRtSzm93 zP>MzQ&XM5AFuXSf^pgT%GD|wuZ-VX{%f2GB>!m?_R5_PE=lrX2x&log1xm~_w0t7= zVjU;Yv)OJIaLXD=<$VUmf9WBPc{r^f0jqhXCXKv%gv-bR9F(MvazS+3p^UT zs)R4HZ}{v(t7zTJtm7~FU#-d;4?w4nlA;v&o9y2pDrF9-z9y+B{)ih}Ian|Tc{toU z&aRK->SxA+k6x??06nIEq#RVjf0TRARx7IoK-c1F4759=Q{V*@Ktvt|pf6?cy7E0v zqQfCod-z>C?02(5L666%dU7WrO3|ekfUU$S$$=e}7(NY3U2|H2yaBSn4L-JB=$UtY zyw|kDCZ!cWWAsdTEgn_nNkYe`2%t_=GPeAy#p<|RNkxCL)v>HCEu)lx-_cBfMiXZH z555J^8i?+)-b*Qv3;(s7Z#7l?U4=!KJiH9V<$xVZv-w4apMdVQPVG{N5qR!V16Vx} zPUFKTq&g^N{?8PMrYa`Z9TyAb>I-k3>{R>v0ulMKsTAD(5fmZL!Bb;vZsgk?*Jm}} z-33U%+2{mI*%CX@S&|iWTWjUGdKF+O9&b-CLyU?d49MsUgzRM@fIu$bo-rly6pnKR zCEypfiXTx>S? zz{S&c^n}oDn8>IeLpHN9=60V<ideYnnbW|&lUgSjR^ zAE1dME$tR&z?vz35AL^wV`);WC$70KJtW%YG$e4bnY8A=Xf~c|0d$M;J4)%CDm^Qb zXXHrZw|A_8;(Nu2OvyZwi|#Wxw>cd>-+%$!L#m@T9Ux?wAyPj~9A8@l@34rKpNFsu|6nZKIYl(=tIOo``7}1w+iEjeOZ|V}8ZXDy+ zcoh+Cu~3x01jjCiuVeXezSvIsO`bO9$?*Ra&Nr{H1fgRWP49UOSAf8AX!hCvkcE8I zZ*WofJii8w2mP0+M$Nl9=~h3|0wKb{KFHVub>pA*anM)-n4Q`BOJx+0QZLFjg*FIL z2z@!Z4(Y6ci*}t^t3;4tBVoa<+|Zzgrf{iNvB1cKfZ1%w0ycBv1gu_Y z2P@v@Li$Qb1fVUzu-)P<^a%jis}7 zD)*@Zz`o(?a(r7c=<6z07DD*q>BEdm@ZPfp%qC?KAuua&o~>G0W(1jF!bf{{OiJFKWWMAp| z5EK$$Hwi=btS?UtlXyz8EIhTObu%j zRO-(pyyd4#Y)Z)K4aYj`f@A{7Yn%gzL{1dw@e6xCA5gTyQtEp+Nyl}r6N7!)rU5>3 zQ++bqBKc~lKCB;XaQ7nzPr&04&2iB;<&7iN6XzGlJL}BCRmyED#v>4}tCs%-rUqi% z!mO0Qvj*5GUd#6aMt6e#i(icBv00{g(X+PuQz)GxD9S!o39vYWkgtG;mVl8F_Ffn~ z#Y>!NXP)JezD%9|U4hO|38Z@#G9EtVR{Vs!+w_d}cT% zlLEL_J%4LBNRn)84kPIf03I@>ladj?WlU zy9-Cpk1^djHG{kzcX$bKfuS8M>TMupB9TQ2r(!mKMWGFg=~!QR6m2Kh6?t20 zrI}vmgib-sydZS6Gi2m|2}y@&If#HlcrHKcqi1Hp3K`C++b!QQUFOW_DL}&o$g?Ps zlP$v#Q^3bFAHxbSwn?EX{oHP+B;5OmN3xr9<9yuL`RpUKbD{}(KObhG zz~`_0nJCNoN2uh>^@vOM@mhZ?V3T820$pjyfl>jq^sw`R4%%wTIjw;UeQ3hfh|Q$@ zU^_{OWSb*;wC;o*7q3VS$>EJGtNxtQbMWV z^N7J0Q7uFc=p?Yt&*O(oM z9XgT#4_s14(HLyw-TrN#Y>sBSfS+J9Q)#%Z&?@Zw0uibtd{tvRL*;2W!eZ)neIlIjR39ktw4C zGLlB)w(&T;GC=l2-4@XyXMaE1#HyBuY5qTwapYqy03{U0A6=20koWESgEunP%BeFg zi`!P(B7fwxgld(1r3bd5-Oq#LVBHSR6)}i?1T$werg1DKiPJ21G=gmj+g4$Si;W!e zn;q%il|$3sHVZ1I)YU^8xyq^47_{8GP!p^8g6-tOuDR&#)FEnBC8r0=HsofYstE7`^3dz7T%kdtN~plH`mNM&I)d~yu5NEW z|MxajPVw)>|C--u16Sh*9Pm7dm3Y&ODiO7A4twF}Z5`_WhrbL}zt^Jf0sv&-?PK|< z@q;a|x*eoS_F#ehbX{SWYn z{TH@}gXJ@_UO0hEOKbKeAv9>Ln?GpWi~;MieQm0$1Xx?@13*n&IS}^z4q%BqJhfki za-`#k#OXgID8jqdv6jn=I{AfE?Ds}th~(XLK0;M7Uzm5gd?G^_D!v>KWfl)`0{j5!irLdn;+ zr>fNQZ-T8yu)_l4JMzpqFp7PFe4hCD;7i%OZ^1(1!8)whi>J2UFQiW&Ixn0!rE4ci z7m!dk83bwI@ZgV`rO_Mxftm1q(w_g+vS}_#u(1URZll*-We2qG^ws8ymhe{biiPrg zg5)qtYH4Ysr(2x6(0A7X^Ma&v5!+>#^Y3LKQ?1RU2HgsSwc;)Y8Lv|umk|6-Jrf0^t?S-a;^g?KsXd= zquS3afY$Q7>TT@9pdT>J&wb@Rec@LtzCcjqFdCfRw=sS^Ktp?gft=u>J{~?qu*vK3 z)dsV9A>DFI*gn2|a=st$v0V?g;iyL$bzp@l_(xPgSaaacWu8N~Biqm>doRUGI!3{h z9snUuw9qx?sdtE9&P2u2yxAA3hXox=5fpz5?)l7aHU=fe(S8}@OGRI>DSW*h@#NWH z{z2S-j9cR3sa_v+a@!8>; zCK12=LQ+C^?G!!;QnBcLAc_$kT8-VddWjKr7iL!_Pa*;xmazQfVa3)0{S6Gx?vk5%z-BXv+ZcG5g^Pl?=(KuVw8-4 z9&QNl!P?EEVfI;jOadBK^n4AV!Q%xMf5-L~-q6^&Xv>j%Mmr=7efxE}=f4$S80=V* z8}Ge6d*lXUaLizn;1ZW^2Eht*U}Ne1kNqWoasr>SJdT^X`hN4;aLWtp$y(Rr!-yIe zC=?Na#0UNYAAwjlv>b#2Z(>S~**y}CNvP{g!#%{N%WJf|PuoI$xlfydvIJ)K~m4zQKu)iqc0a_;=a zj`3h#`4I>I!-+Gd6tO)IqKaz3b+}1*uc%GqmocCjrW?OQwQ`0xy{5FDG=L#=yZ!j_ zRwH6>LgS1>=7Vv%V2Eu`9_yO}hc&2Lldn&Q#`TftGZfI!g1j1O@08GUXr|Weu_wzJ zad-4O+|Br?GP1H{(5v6_^WY+wANF`q3^#ZbeGaZI1#77yljWSKCl|PFb|B0Q*61PL zi--8a7BR!XJMu{sXKsk4BpByFQp!^w$a)qki5wAU0LT{FL|;cE)1gt_qA_Rx>YfkX zPT7@+dkd4x#t|ImfUO0=N15+>f0+H+12(=P0*Y$3&7xt>AlPD}Aq)}rgJ?za8DAK@ zeCthTAqTJ^=g7e&FhX0jBV$|)&($BiOWLwPuVJ*YqTiCpn1%RDS$VpL0Q-OP`;Z6s zOZDODD!c~v-)&s1M^3-9_W}YX`f{4Zj|M1id_*&H6;JBH*uK6hF0=`4!ar^D11W3< za4F5=AlxfNnLh)jB1i5M$2rMgRv79MV`WHn1i2?05FwKQO)%cT_i|1|Y2)QA7We_4 z&N*~m%oH`lZu(ssmOHdoi*CY9a5D;HrA!e!WdgzKAOhCe4p9U5s&7RI^dqdGC>{W8 zR@F@e4iVjTaR*@d3II_J(Dh($Nstpm{f-VbB%lbbMD8|v<_c0R%k@@_%X(EBCl zU%;T`{_YBN*G#N~;$A_run4A9n&%%RNAYlQzS3E|1M5p@CxE?)r(55rSEh0G za)7&zCqz#j`zQQZc7_FORm7t=2InY91fbToU#gBj7zE*-`evQV+S8Of!A}f8Po7AJ z`}5PX(Urk!j?R_do(${`KYlSp6L$`vI8zJFQzMYCo$n16a$?UArLTRLlVwnC3&bWu zgED0((O1I_3Xvlb5KTdg1msElS_0Tf>E7Ir-z^%({|hE-fCrUW3AJZt^t4YRzjjl>mcJfMXMgmaj+B+ff>+SmrtcNJ?}7`)hw#UyL?* zl>+c22>wf>dk?Y&xt7tNs|Me22GRpIMU|{2$f=B53b4q-xf@(d#Ih`Ym)ii^>3L6| zRMmO*I8x0eJ>Y0PdrcV|HgM|irs*vO)qg>z2V<-djv z6(-oPmUk5aV{W-SJCGl*fB`&%8Al;@r;G11tkZUeN1t!GT!z22#0=yXnU9YK7fj{B zA0(W(zc?#?uy$LzT8wKbyByS`X@~;P!B^C0n@w zuq;vz+-;FsB%FzuNUfek{NlAG&;GOYfG~~ewi*uPj!_#!!mBv<3i#*c`0r6%*R>Vl<}S9 zd1i>hOSIbh@UJISAi-huT9@IeLOciMhk?L*5*|(7cl!SVut1jptnv<~yL$g~I#LQ{ zJtGtb=}3jbZWb)lxHT>@PkTdw{Qxw4Hv~X9;+xSQbD_7tdWD;pq$7( zUdSa|7;_BDPzWFe+NmiOq`y4RY*IT*0`Ee+rv(?Q~?67}`bBm0a zzvJr-8xms&aHSdL?1dfLOxBtmT}*f)ySQA+A>LSg>guP6O>>x)D4<;a8<*rZ4XAY_ zq7`!6-u%DXBL7bsfrrMYYuj!pn48# zeT?*0e`)=C@oSMi&sXpx;-2^xdm&-u+s6L43x__X^-mYcXms|#Hp-x`W(4X4lGxqz-+Ug!r7pw z!CvW0-YEsge-7$vYF;8D79o)@xS6a!}JpTq0BKVRo;y zqXbLO8XUn1a20&BoPa%9^)VjilX1_Ct|Fpv_&9WBN3SuhM{afy+V93+m`h_|Ngjj_ zZ70Kbw%h*v9)TJqP|G00&-s$@HbJPqVZ$Kt{QZ_Ve?;h3HErQAU6%3TdhIP>sHk|j zN-r`s_ydUw)$C>wKIP(=nIJxx|IO&ZeK7yGZ$zj#bXfOVA^A(+a2$K1#bI7ZS3f_m zMLQlQnuA;bKwS27sCdvYSMzPfcUSwi-nEFQP%MM6>RcSy_{{+b%?W7v#X`j@l%6@e zB)j+7Wq3e(&qc`V$Vr{K_yG?BVOTB{`*qxy+H7if6T5558w3J|Fww`E%w79&YkZs6 zM@Mx4o)1)Agi`~eeWfQFcYqncGKINO4aXZMCWwxR&zge-=t?J0hf$SS+QtAo5OyQ* zfu?sG_*ctSB?RGKY(>qlmq!)oG3l_*sZNP+qkK<|eOCS2G3sD2+k-|YHjUlf z)OOb4eE2nw!7GlOV93}3BYSd7#H{5}DZHU&Gv3a7c-juI@_Rp$uq;saeJH3HIB66N z;wSRH^T9MMzNJB@t^1aaev(_W!3eLuT5~nQOce31|B*11A7$oN2-@e33wuR_V(%6b z-vXhpIr*==GU)wSo8HYAGT8*EhTwFqUogqOLH9+hayU`p-8vl5&e6X=9 zm?X4JEjKt()@2u5vZm+Ez-piGqC#-PT%C+$SLY)|j5c|nI;M47Hhpp>i`yp|7C^UN zaTd!A9S)ICw20tprDO=_9w_%rvz{GPY z+C{>ZAD))6w2mF&Pd|UaCc(IQd%T|29{2N(I_I(%`X>r8G?Q_r3J+y?+s@^jdSJjxNq3XJc z{GQA}Jq5*wqlt3$0`UwQ-*WKve7@jsMw|2`5Evo0sw%+S(wXz^9^U@c!ZY&6J7l4G z(oLpP`g+)D_c5RA7Ve;IjADC;Q@rcPyJ7#mikilbeOoL4!6WzPYqfd-5{}xcsf+(Z z)LX|j`F{W7z7$l-DJ>$Q!041#5CLU$gVY?Qv~&&>2?+s5mnhv`BZe?K6_|9F#Ars0 z_}$?9^ZWh_kKNaGU-xzDd7kH-ZqABW<-eTvjZRfUUzM%*Cs)i8{lw1)G@c%_wwttV zzKSs)D;zZ)=Xk+C(RRXkdaXoPo*;a~*kezdUGIf5S>9i5T#Iw0F;4hmI z#2j&>Nk~D^N z-nRsQ5t~YsV-r>tTh8&4kW3fjVw2%@d8Uz+aJ8QGp7$D9xzi+4A2so;eZ{j219`WY2SjO`M+M!x_ zX$QktPZq5Rx8y^5ox)$qN=a{+AGpx0L?*8(b4HUVaCu&r`cB@K!h(|1PO;Us6~I!m z;jMW0V|oVr5=Lmvn1teIq?Rb1E$(fYr*O82#vAFAKNKo-naD^s;6IRh>wkac=T$0{=t%Oq2y^XQ4ZeCt|v(jKe{8;B=7aVUn5qfYukW8Y@fkM_686h>n zh+88Eu53w;WW9S0DY8lI%n3{sv24jyhRTwGWNNNI)`|;bR-SoF4OL@*-slSoPTA;) z7kuyIydw&&EVhHH+{CE$1dJp5%rTLcpfv%71>~9GOSW%Fz zbI#`7JN|ffqJNi?M**>JEM7vJ!1vldaQc(sa2u(TkM7?#GQo>CVL7 zn-6Jk^w~!aejswHU0Yl0WmP2pcU&(9zAe89dH*7frJbBhFNuqT9oRu+&3d!8&ASJ< z*ex-NiSMRO@WYWVag9L%nLBEL&7m{i5SOKVAi+_c=oT7%yjKA!d)U{vtVm2eW7P6- zj?CkeV{@q6-#FjB3a%6)dsYE_%fxM)j*h6m;&mn z)}T@W+-buvEl3y&d}S^R>#C)m`1Q={Et!Mb8d>^qBB1z7i)jI;-q@^{!Z_v4=(-+TkV;hca5Q*| zK8p%pI{SX9Z*l1AR$i~Hu6FX#{&4xLUw-ib);bcxmya%P)xRFH|0sM2tjLUmHNUg6 z`YqeYKKAcgytuSxJg>`JZQGRa78iEBge56v6({7R%2U*TYM+H$y%ZI}`Snloh_|bg z`o770V#Y{Knyt9{{mPgJ{1nTpMHOl&MQOkj`Dc?53n_fi65qp5@@pr~6riLkc@n;ee654Qh;}|h0I|4m(rt^hFlEU29x$|DueXh<}8(Z69p*8hgW^g}j zoI~bi1btq6#6z3v(7h8+sJ6q5(+^a5+UT^~*?q4GRo*P@)GO*W_%-RJ-Qq7c2TL{Q zF8N!-Ko76IW+w$qH$p}u};NTPdXP>OFqkFHV^At z1DVCI1r#5Aj32Jw+7LYaMw&2CYfyT0yRH)MjnkZwJYm5!`T04MX-Jg$8zHT6Fm1zs zRu!h`X~nuqrSJ%F!_@Trxrwq5s}Z!1HDU>9STqPH|DaMuL#PJrXa10Mw44DVkMCaC zW-w%M7a%IvhN>US+rk}_iwPd9Q@wo3e_@q6IqlJWL*jSiwjoJM$a|#YYNz4;4%8|P z%IdPz9cvAYFR(1|;{PgLFY-t?ic9$Y?DNL=_p&}+scdpffL5FjxXG3U{CS1rAw?|T ziV0pL-Z^BACi9a>cC|_21eRzA=Ms9GJ4IS%^=n@!Pj)K#ZN9B+mE>Ms zU&Pb#uB8~b`*4w#;ePM^VwSNx8x`{>;65Jo zCrq}OePk|9UxpW?mEqED*+vZrW_vvHsbdl9&FA(Fp)E(YE;plnY%(T8X(ZW@@W$T5 z%Y8p7^*5>m#-Qc7uK!8oQH;LwDPrCn1$PWPXeVWAL-}uXRIN;|D^=EgT%B19h{08h!FgWbeDClHQ{N*Z2@>*nTge`L7|>v#XnjCPwQMEbFqO!nG%2v4 zQQ;nMEIBi>kha&nJ3wFait=G0Q~b>^y1-*8$nUs+pXpAIn%VueQjZ)pE|J%`hQ`c@64UQ(c`@ z)ZGbrkF$`3#1Y&lDy^vtw}S+*%CuKc-ElIC;#f9+@XOL+0)LD73x=WOoZe3NrSA<$U-+zu^d^g{LE|PCyvE`tn8d52?X75>q{XN; z#(^)Dvb<~w0I%G@3&(nvbXtsaumVc^ds0$Tude3?fj0SwBDpzBodQCJ++33AmZVI( z#nu_&YjJ8BT_}Hn+-Ou~+(Q3rWAMt7WKb&Y#K+hCfX(#jz>X0WYs0hpRKI1Bb59}M z86C3pBUp*br&7BtAmL*e4Laa<)8jw{iA|r3vQsrP2jh(q8s7IJOexGEK3L55b6m6; zjbaowO)M_8aw2v~k>E9)h*Jh9d58Ru(`ZMpJEkoV40P-cIRzFN&DF>l2BP0y>a5qx@JB%GLTUBxo%*L+AQ8iuNa%rle({%AXF3;h z>9@;yq;tNN>R-gLXyc+Mdfa;ESB6iObXR-U87I<9UUfPKr1o~7JCUBYIxdbn%{Vn~ zOD(@35~O~F+|88S-yJD%u+uUWX|O8h;N95=tbtD4`jY;1+VpxBf;*(_w36Z-l8nM! zQAjuHY%aM3fO->n6zhBOazNb6@hKjak%6}T8U{Tegs>qX5O&tpm`tjTbygx*)+)DM z?vIPQmrk3;>NdW$)K?*oUyw7Bb;UoGrnj zj8{HORxi-8TRRd6E2)u-1t_LGIVU27x)+7HRlJ=fQJaPLgHo)DDhX?+Q{&_vX-B`^ zqeX%74Yv`qJ*k`0Fc(I#Z1;DB_hN&o7Ek#zC@g1~$*(*a#UJ0Ed9PKR4$XeTmgE`p zNfo-i=R0I#WI*$d;m`ncYjTf}0_eP{Yg50s%TSX2U4?)x4 zqbEg6jv}O*`8sbGoM_sT)9G9aKd6wYUL{dbzT^~Q-gBj_ID`ROt}qZOR8aA3HJzug zdHj7@g*_RngYIh zu9}{o*v0CExV~xX(KwDt^T4Oxj9Ye5OcPpycb1obON6?C6GCFjkr|SU`dV@PTkiJb^Y+8t;{!X+|hcqpF;9le7)ts!*A1kYpdX)dmp=3!*=z$>QIH^teb}Rmo=pn@=sV33aOkCM^tXa6gb_ zs^>{lQpzoSBdC!-I`q0Ufv|qFQa&Hjf7lVxh!aPc$;F6 zqNmaU(a=5MgME>09j$}=S?};8O_0i1{3aQlHcpgObCnQc-e??Y+oR^-AHJxsJGIBw ziBl&y`>QBntTW@ zz6FU|0^2*E$zBY{bA3I2&}A_mvcGR!EFEI}V8o5B&goG~>S^6P){vLm$T6Z;v49Ve zaDAEKkyA7%2`e(=$9tc}&_j41vIc?C;^4<${M9UDT`*TO# zogi^ixXz9Dh&Bd5u^ADlzwOqIL3{A>(&v-Vu#NW5lln6K^Z8}J{R#9CCJ?tUNK}@l zEx1$WpLrjKoO4fmZ!*6X41bp<$SvtB*6g3lq;z|v`n0m7M^ENuc`~0&+=NHL5bZbS z8XnBOQ$~?@|fGv@#0vq8wsD_fvA3})Pn+jexO5+-nd>$Iqka2Lzs~O zAHACfXG%O zYP@=5lt)I@|4RSJ)#sIz=v7$u2^y|OFRzi9;F&tGKMKm~A1MD00#xYBs_|*ii05Hh z2~Bxw$-@L&ExIfuXb*Rbl78z~sCOEqeQ+wVDG@Mnog96BkF1JNvlE|yM~vyfj=d29 z7)ide0{@NF9$NF?cYj(0xQl(BoUVFvTZ1mM3iJS=ycqz6d1L9{8!noI*ILKa^4bkY z*0H(Tk)IN7+>fGI;m69UF0_BqLI;CH4ObC=)|7rN;5O`E^2SFqO^kRht#@Z?s>Hms z!lD5dqXn;q`g=_V#9WSv=R~Es+8@IT$KvQasM^b1u zMdAlxz<9F!sw#{v>y3Ib#R?zzXnREQbJH*anpg!EJ%zfcBQJ^)r|TWfWscIAsP+r@ zk-doAeQ^hqs@LG}B~54FtnyMsWvXdz9giIh{7q|P=`81qKm)53H#R}>Qt z6p8=LPSo-j9p%Bi8f!itn?e=JA4Kq`J*%>>E&#+N;?r4{_SQCjVbR6_6YwBS*sysA zkZ=)64qi5yn;XGB%26ETH}BBrvZ;Nutw!*vP%YNg)oDivffdUQ_F^|AdZ;RmD%xDvznAsw(g6<5x*VvqwcO zVDRic4UhEUV8{}3G{1s$fc<9sL$g!Iq*2D_MjJ4}HkK|Lp6T3ZGv%c?-K*FmBor89 zl?!N6^J)YS57i=n-G4q4v%vtOb2R@enAwpxdpv~?)-DQ7Kt8f-7>Eo@Wm)(XLXvGQ zYwEL#pix%x0=nylS%Ep}&TXq5X6&mGTx3*>i9&Dl#hsTEir&2Waqj^Frp)-(T@=BT z(P!^oRJt-1{5h1OLrR&m&uw>w_&(z6AMr@zfnea#-oa**$BXL{;?qY4%MftGz@i{l zPTt1KN&|pH_zk;agNU7e89&$38nQP_Z0zFo;OZ27m|WRYeRd?4CZJ)37!0OTO!!I= z=l#NfeyN~#l27+dk;B~uT>0}sF$I;f?aZ1j)qY_$4&ss3@Kp(0fdMeYX{cd zFaPz%Gnwt&g?ItlGbHy3WCI-v>~G&(d}eFI9g)$zj5+oVmM@k~8xQJAC8xnht_^tK%)T|SKX+mYTz zh_9ph#dP58r@#&T)?rT0xJl?gwZtk*=yVwpb9o|+WbQakG9c`Fqf;YU8s)T&fk%{j z#L^&s`gA#=qEF{leWkTAXDMQM4%fx`5y`_6bH&C?K`Td^A=P`2_()K`xMWVHQJrd^ z_w;!`36IOc$7<|(7@BbA%b{Xp`IARG3w^Aj0QOh)by&(4P|qmF?*F>V;r>Yv->HSZ z&{_1e9WM^nE*z^>ahMpmvGhVU1zo8XFv>@QAYtkLJm9k|R7W;4fmiSkUvI35wL^Y! z7x~ZXmQk?WI0_X7bYL$yIq|B9<%SfYVs=lc{a^EcW=}$l2E)Yk0Om%YuA@3n6@{!M zLR}|rrY-sC;>2NKy}RsLP1&>Ibajllo#56Nz%h~k+`z5y9!rt<)3<9;kleg}Fx+kO z4pGT_oha71o0IX4O>pVJH#5NGq@0_mTKkD?H1qHAI(%6M*C0-RjX)zO<}vFG!0C#?IFsbg+xc zv@6;c@4Ru0Z(UPTFVRADe4}8MA3Wi2h*U{>(q*gDUYt38Z)A=JxAkH1D9r);WTdtW zb-b*mnxQ-$4Y+Or9#Cq@MgSeIj!{IWX6&zks<;CEmE~7i>4mLh z=m38ISZEWA4%A=&_-?EjX%2I`#~Vi7Z$4Pv409(#OIdy7^y-4cl5%AT066LYuxwx zn8?8|E5A^*uA)SP-#K}v>+J@TR$#{lP)#7r$07MFrHGXA5O#Y$NZ}*{Gu|K0jjwik z9RYIkhExK;5fh&Ib(~%NKPmk9Q_MX4m8w4gYWN?Cf=o9A@9F4~pYW$_eejI5;ee(a zae<@`pa^a}rPjk&2(GRymP{biG&+#n>P3~z)FVPZ?L$-!_nwR( za`KTv3vv%>rTx#C143))2ya*WOv5Fj|_P6iL%53RtVcv`)e&;^I7TuH;R1b@zk6WaE+Zn!c zvtKCK@@uQ4TvkCCM`{$4nAO$zguK(f((pN-o0T5(MH*E{n{VZN;?9}0iXq8Hk$Kba zQ;n)iNXT_Z!tk6njwPsB;au~{X`oq{jo@bFXa9SLQrv$Jv%WLWRZ{#a4KnV9|4ow+ z_dUZNDl1uSbbKxi)>1I6vMm2x-aBImI12Yno45sQ%4+;=)v%UZeDTIa<)seETVgV| zPdqTxD{CbAN3o<|qCjeLlu*Y_H2-7r?AY)d-pilANB2dSSm{vM`~0zu9l+Bz%1FEg zJa~>5EF3rQyKm5$GV`UK33gjF5xg$`#NQ!oc50K-QPPe)F>RV&niU+B+o4&JDg+AR zmNlQ&wu2`WAGZ9ewg@h!g>Z>mYm0u_Nu*O?~i3yiyu|U24 zSZI8$E|l}Q#srupi)Wo5^*!IHyN?B4`YU7NuR>k+C;I>8 z4d%65Ge=-(3N7_FDZOQbNChrEnfcLRRt}z>Z>_w(gYWvCp%<8c7#r|Y z^G6YW){X_JS*|W88mndqTrP&&aUIRS_Zui^?$teAk`(A)UvW;ufEP6E{`msLn4ceS z=$M&hjD-f*>Oi|yB6jLpT^kthEz#6SaYHyl3cR?Pbr$t%8gmLR%_-}|bK!qcx#=D7 zL>CcUgQ`ZlMob6FUw9qOr5M;P5N(!j9;(GC0?@`fy2Lp8r9L|Rf%B~|(vo~o zfAYV41|pvS4$6 zli0A~ooI)R@RHPHnuD|^yJ2ap+eX+=yAp%R^rS7Lg2-UArc&10RS!j-{wBd7)GUkQ zqfivfA?zq>8W{6Y5$mJRd6GgnkjNAIFOeiqYC`Af$#UFQol0QlB|0`x1sX54Q=17| zH}4iRdK-PVvAX0RgqJg=j)|{EWo`QIdkW(tgsta$C5IhXX1>qdZP+P-jI4)! zngnM12px#I7z|5hXzwONXQuBnVQA`&acy=x?f#;)^q>v~_zpDn@XOJTh3NVj^&~z3 z^=x{>-=AY@16dUIQ8W`fQPBjxhq;62rZV>79v*mmFXwhvNf15mxZxf(ijd3#MvqhKGzj}BUCN7>T!ucro z`)uEQGZ^~U$L#itsD;CCzK#XHvPlvbzQ(Kfy>J-urVfsHK5geMufjrNRq+9^ZXR(< z<%+#l@=THOQVKioXfSf_84PH{Z3*}YQ?5x!%Hp8FbxcS_n&y_@PkHfl&S?DA_NHU^ zyH%o$!@{nSTaG9(F8ec!Xp`*1tJ1bq2y~(+7~YXpT5Bi>cWlk|y!p04RrY>ew)e6q@TD!Mfc=OsH}4{^cB0qW|equ(LhteXkfdvrt!IsnL=dVJ#i6uJK_OT^*7`BCEpMK!1f{Nj8bYB*lskjo0X6lbfMeIvpW-=n$=Vu! z`uPgYlDJ%%;2hv39$5IedLFBAIZsz&SMK{ua73ax*;R-SU>Y<_Qlvt3T|^UY`!JdN zwWjGv$_N#QhJu3jT!veLL{6?(vI!<8=(mp(`a$CAq%WK|%zPa~iCH5#I$QUe86H4w zSXWuB+boao^32pl#F{BKXr7ejhFLQPwR-&g@SmlP`?S;s(4Lyqyi;)$-I6_hoUR%n zuu1DRvlDmeNfh_@q}6*HuBfr3HFFNS(OrjW-9R z*fy1TZ`gzJb5ifUnGf55WczgzJ*hFzmwS;()VUoa7ehu`wC4mF65>AE1$<;=WUPJA z$)jLos>72b1BxNVSnJ=*)Dhy@t@)Xtu<~3S>@qNk5B=mg9gBmxDzzslHKThe6MkG5 z(ix5VJWj+`ja}64lyXWvB`^XLl}|FjW~RNzRKIrIxPS+35-^b5(4~eeQokZu&Dj&Q^N<&u$x)M#j3)hqRB;nKLb8BRB8Ev z(ne7$jX@M4n7-=)8TGaIiKufo%uchnWf=Q(%NjbJGZd~LW%Wt`KAJE3O(5R?Fzk3> zRcB{c=8-ixled#&2E}-3&l!pxG^C@_o#jUkFe;#2}G#-2~#6Kt8KGK`u zOEf;?oop7taWDUOu)M}FAa42%086=oid&CSWbu5L3*%eu+E7x^t~YZLYDE+$`d{{1 zXG8Gv|J0z|h#`;!sT{*PCHoYt#1cczepJZ3am_4+S=4A`yi6>5_u1f}&7tjSq9L6C zkV+adkVv8b6mquCcTsiHl}0UR%Bz>|q+JgROV2%kJ@dvriEnufAC+=e`?V1JX%lVl z;}NDB0rg9sDP&byJ`)167Prfw)ZTek5Z^QMMa3MeXrW*={F$9~M?D66ZCjG*cUUMp zUN!nW6=Gu(pn8+g(b1SQX7}} z!@!D^O*Olf;8yBo2zA?pnxzR)rRGG|uYJd3nR*5^xjOY~pT?YD+Cl`%} zX&z+#YT{I#L`%87v31Ym&usC2!Jul=qBnGeuXR>Qwqgy9W8a5qP{c}+uDl|>FW71u zXfwwJN>noD#G?N=04k*2{h7{D!1K_OUcBX{L#J63PY8Vm$@!=go_-B|8_2&=%4MAh z+E0pA0o`mXmV%n@hoIp2{31i8v`pXSpe&SGL|J!iFUWi7S!A+q`gn*bBQ>kWDmwq* zo9?^72B(wK|MQZhpYY68sMV1eBy>d7_s&>dE=P{***&R#xHi#*QgtWiVw`zrknvxL zvGzH4h9>;7;}LQ(sDx)H#WTl+3n(F<&1^7**)pE{o|p2cP}qMyl|zEU5Wp)QS-uBw zeM_#VS-gzKxggmW;g`g+Dgl{dvc*<$04=}PKONV#o$>UZRC~TohAa;YF@{F_6UmpJ zVizOEX}OwB?yX+m`&%Jta=ZZgyrATEtqJTnk`Ct5YNy>Sa zYDG88c_4)aQ_d2AwiLIxCVV3Eo!Mz8^_^xG5i%bA?Tp@xB zn&@v3&~$NA-zcNd?p5K26c&D1QSq`n9TvM}_BR5AXyTFYzz)oC=e zs1|Mh!-$YaUnAsA~&`+lBMmrL@5#@S^lGM66m7j0bxtch6Q z&%xSy;Vhl=ob&CB11ZTpD2381J+r_D;em$23u-XbJ<^JqlN$op zFT&)5(50dLG`>kkt-{NiOQqUR;=z962rd0HuH@G!78cUPA!hsh zO%D1>(bSp+Ydrux8*`bw)GbvPzhm0#$g#+hP#xbb{WWNiIRviH13aHZs4CY`u-z!X zw=RDAkIn*So#djZ45So%6`xYdM1O1OH`+aHiE}#}2#Y2~SmJTmA8ysY)*A3;Jp}w@ z9{_q^IEAk{^1P83I{jiQa7z({gH`E-N!bFSh}UO*T7L=V64;!V>-p`{{18ST_Hb=mJ`waocOpYZ^&w0)_zq@B>n2e0&uQ;% zTc8>t+Ng1y(p0s9K2^<+rq~vmNyQT1)ztM`|)8kHi^9PAen6W70u; z{pNE?V=u_fU%v?mjlK$}Os_{TMINbCa0i+PtTVUe|n|gl$`$VRt%3~UnFy0yLPb;k(1G` z66)2BW9d6Y;pA2M*P!ZnsNt)Pq;@L)#W)CZ@%Te5RB3nBf@Qn^Ic4_ie z(V5qu)RQk+v}ndUg{I#DWEG0T#Mv@jdjr+xK&tf3q)C(SS+B0+C4G$-d#B4WWy)n> z;biL}xLIAW6jYFEy$?%(y&EgHuq+Vsh3m7Nx**Y%|FF)YG!FJ3qi8hV4 zIB6zcrRPyZPEw<{sO*ro=xPF{|Kb9qX6(|hum4N~6nljZLkbTAn>LyHe?@`U&Rs}a zCYxa`wT+Nyw#1^AZOd<4T(a7s^G}v*?TiU5akl~!$JL5z-H z_zVWMYL6R31UfD9n7kvG8pBH+_!??%*eb=2dK=!iA;n=E@EA?~G%*br{qeR1U~ynP z0PD^V1>~m$4Vy_SPW&Ccx%8+-|Bypp&8tijmT>8EDhZ}M>=#Wqdc#Ql5D?@n(xUBk zvyLnx&@DhKw1 zdYYKJ?PCz8OU*Yo0^bpA{r53r{t3R~_gTN+TG~5VpNpLh-_eVpKE-F%WLnt78*$f! zh=fH%l8Rb(4`63o;!{SP(k-;t=m+V=JV;_D;;%=bai!I*5oBEP#8>DFx@6&8y^iO z-1?&zD*>AdUNbxN$;CAkc>Q)?3SO)H1H#M~Z4%VQ3^PL+b^8+*{?Drm>siatl%d{0 zr}JC|MHqFS3#*gqotnuM=` zt5kgTuG)_u(-rG!t;{%7Ti-C#cO+N-1@;Prlc&-GQw!(>9vzvBgcCcJE#Q8Y)n~s5 zognsv{d~|n#1~ZK!W|m~*Y~7L<0}#jXC|km`ffY@ZMoCp}dhy->{~sjRetf6lkTjnw0>tgBykSocV9tb}13 zkhBDlyjZSKDs$jEt6Zt($2@D!)bR@-61`aAkG{fBnra_yE0X3nz*C0__ZZB(8RJ%Av+Dl=9<^d!X3+vX#F?P{ARy?{g6Fa z0#|dv%hT2mztYy8$e!WDG*vsj0bJMx4(88wpWL~ zEt3vf)H=s#)>1cSy<~&rqR_eSOcP9mrt#mn`{{I|x!X_dI45dnp(9zzxU`OvtE0Xi zh+7!&ikJ?m-WlWoGWsO}xn;_!E}0At=DXT5I1*FLQ11(Eb-&O!HRZkx3{@k_t|?@- z@b+p0@oeRl#DW62rR~6#qc2Cb^1FO-(j}9s%a7VEkkf`TamV2R@pGYDU|S2<9Dbi^ zqAIEF1SLC%M;WOvJH=S^4eXEZ}!QMRs}mWhD({kI?Gv`52SN4v^Jj|uVmN2`iaOJ2$p z;I5L=E%X8H^N81W9%ip6aG_(NG!4yf!l79J?RA+xjhevaS6lcVPtaM77E#Jyt#>|8 zI_TrK{z7|y$I|BC!NHL5QD@1RlfP5-;7{*lEvn-D*U+I5DkHf5OntV5^pjbn=U#Z~rx8E7LSDSnHzs>2jSk*B9kbks(7949=KjqDRNir@?RVIDA$$@(hsBa5DPBsjBZa0i}?yTd3oX-mkJE4|K?&qrIM_b!M`Zz;hnLg`Z`S*!{% z4Zf6@%fxnuXGivpvZFS^@8B==;^njR9GBr1+E%}{^}r_;^)6b%5vP@SF*BQ10~FpT zDgEw{D#TrRk9xhaOcPXwEJX?mK+?#3!k$mtq8~`$9{3VD6&3m|k)45}D38Yd6b+Z4 zBumM1C~^w0Dz{fLOj_o&k@AEFJ!;OUywu+9XvN^OOBk_40uZ^lN$8zsa*U@pafWSk>*VQ`}2?X~iaK6O^_wik310H3NIdt9^|oF9I8`110^diEB2>~$}lcYuOY2GX+rg+_)voFCU~ zSw)||IT74oDt5OX_V6`g|qXgRAKcM zTZQtG59=jD*rzK9Gn&Z+mk1eVp`X|VqT0FIfcj6JOQs?~I|b=2ZQ~DHlDh#uNUtt6 z!YrS(DVy}wIG$fSxUp-p?OWR~|4sDnWxi^yY@jJOnbA|H4~e&$@y$j^k%DW#FgzQ# z#r9)@k98v228#V&ezEZ#x8-QetU5#*?*t*sUpVG7kpO|tzsiy*+nF*U4X6@z`CKZG z^|aDbB{wh&0}=%5uN%-5~C)FTb=cyi~(x3}7d>t+voO z!*9tAFo_BuU{|*KKtq5rucaXFr$_Jn^c!K}m&Ri%~o*?q!n zQ+%^j^ZVITGl>SpwjzJh4Yc*EE5-nG^Mjt{5p?1o?r#2otjUTt{QjyLug*aonJM6@Kl4Twe$BcvXpEXand}ZODwjxm6vqGzn}1H zK%pi0@&|f$-H-@Ypq8hYYt&>32TLI8oKPEU7@;y?-U1!k4tDKGN}k=KGb6IwazBm*2!`(t3pA0%6lhCJoGHYI8Qj@0sXKX%Km7pv_O7&0j6D!0RrwS57 z(K?e{$S>xCi&)vGmH=ZhjXqQCBd29&nBh{_&&V%_q=rW+Wh)2lV|&AG(-^`y?ju0y`SvJjjpvqHGIp?t0W z$2?^^JijC}df3b)3kUmff!DOGeGdKTyEv4F-BJ!XGrhP08XPhT1>iZ_xS%-CFX)A>N8jv?(Zctr2$LQvpo1*G7PghY@|B%Zv zZ)5;(s;aF?nw=aD>lh4HrVi+zq=Hl zEoH06wpC71#%yy+QT76!pd_7l`5{KRS?gMh6aTb}RWV8`wB4(lG5 zJPMz!o@`dyg!4XMcqr8h@ns~%dwGQ3EN#Lv?TD`l15u}B-rLt3_ib`O(|RSMcX}b= z6MpXDNX@*UprG_WfBX(pje)|NEoZipX|Z*sk$f(-I@u|SD*6A_+5DlhEG^)B=e_(x z&!zlqBuqC?=_R)d!@z?>KDc?!VnTi}qjpbpwp4F2ecF!84$-JRT>n2`IBm8AK0XpY znYbTE9zW3d3f!fxNO)i9Je*N_+SavM%(@=bbJ#rF9$fQx@d#r#*BcA8Kgm>aXYNyGyYkLp0K`^9*P4v~W~BD6y&&iAeh@A-QsK5eM&uZn5<@dGOUa?0bk zqHBMA$yP(t(1lHPl89Z>ScXlAVLn63n;?q5+$UCR=#9+vp!ruX7N0ZfZgf>oODShN zNUm;l0R>(uM+5%_7yOV7jvEd}4*o})SBfvqemljOq>98@9RSRyq@wMZBo;k^HXB#{MhxqMRygfrvf!jwd$W`djp74hswo%$81h&Nf)g}MCUW_WK6*E7Sm_7MpnDCq}7MS149SRtw}2or%Xa#e*^a5IF99Ev0@mwUoQ z6z6tXy)d%->lk5*cM^W+eokh6#`Pc1jhO3hrr{nNRc}M30PFRU!Zr3!GOctq_eG9f z%6*d!x%0MjG9(a2&^_ri>b_GjdcfSIkxS*9p_Np*55w6~NyGDxU{ryHaA$b)<(cCr ze|&lYiMSW2J61uphCZ2bu0swl4YKk9x2N$@(^nEiDhr-xQu7lfm~sQ1e?#2y&X9=? z;_gC@F%|VY*%uo{O!ee(xvZV1nR+Q8cT{vVZIifJ43do`>}@!Z5ghBTdf$ys?b_Bm zKd3(e=Xc73QrUM0Pzjg84$SCBUvcXjSB^UcxkaoX>4N^_JY$wOo@LBTH~ z&n3W-_sns4aJCmTg#d~cw;iR~J<{nckD5uTMCw5kl?%eo93;*U9t)t}IodVhYSbpt znzOu+T&5eq<@j}3Yo|wu&~=!%c2GJPEoS$2SQw`UE=JG1j#>eblpeCxkeUW=g>k)~ z5EGr@iYr^b*s&_PS%`GFalRT8hlS_J>k3P%szDtAKiO%&A3)l~RW&f6qi<1+?x?v+ z%<3-J>KSJa&*!6-$yHCiu^ZvR3}WxU zk9C*h`L}GT4yA_vFH*AWTL1jM$Vq>R608j%YQZUD!B!9@x9 zCk>9J8)idOT0MYjIP3VgW13A=8x7kz(08!~FR0AJCn{FPDrW-t3;oR^GCs+sg+>QS z^{VFcf0C~v_51ti*|0Ux9=`6vk+o8$*A&*Vr7QK-J@(mlal+d}*t9?gKsC`#^--C7 z9gyE8c_W18+j=GtGf7=$2fS5Ag@Jl;PKw7#3wZa=I zH-;k{AjcfqGVPVhB9o%;dmZ;@xwnPhPTE(qr)3_(z|v!}%6)g-@~6`e8u!3!_0mVE z6Z4si1!e1j`g>%GpU<6FkOs4f?9PQbjB}70sC*!uaMa>jx-WuDeRnMEC~? z51qoPQ{JDkQ^ef6UK>ZW3wLK%5$|Nsif=nUeD+WNOHc=S*!^rCame zoArY*S*rVcVbt@7d{HI-;bx%AY}Ar&L?Znwni->0)<)2S69qkT%+5!vLgqxb^3~~$ zF0bk5RL6QvP1BynWz1COM3amsd?^)WZgwNvBCF^Pfey1`U&T~ct>m##5pN^U3ms#K z6XMd#!+GX*$ z#k?f&GS!W)wVfQ*L81+{xKm?epRMtfOlrs0Uk>YuybajE7DJhr8~7%Cu7l6QgA-I1 z$nbbv>*Os!%ey3Z3~C|UzBaU%8`YkvK-IlwG?GDgYN0sT+!fW&M35y8u}!ULkCl52 zePpmsfJERsy0vD`4_qz7Y=L^6$wYdGrX8AWVQFv9n#-z4D;^cJmZ%uT5!&{EIIfQyFPl{fvgPzD93;V2!Qnly{3Yi%7qRgMt}BH&HL zHED@8MSo=Ky%+q^_4yt0QH!)18!e2-h2HCgn89h`pgYlXD-YtsVHCK8r`zXKvt)!^ zZ(yX15+J{#R3z z$P}!08QPc#N_s|_(-LK~q#SWTN*hZ=SMLVmzKY-_kWgNS(G^I)Ly>cXV;)uKFUZ_Q#Ti@Iv$312rpr z%iOEwjcC3N;$37#Tt4*d_>SvRA1Ifk#2^IjgT?1Nr^!MgA}HM zGBNT9Rfr`vlNwT(daCHpRr7Vdp(D;rp?>ntVmUzN5cDXaDDNW>_xYE-SXR_7yUsAq z$}(4ZSj9K7(Tb^xtQ;HZ3iWnlrQLvIqeSK!QycxE97ng-tARqbo??buWEgYru@Ru0 z76^O(H2Gbmc*`{sqZndjlUg}c? zZV_l?TVu_B8IGmSdJcMl$~nDg@?(R`HK9iBa!_&L86FGMa=VcseF~HS0H=L+yy=Z2 zeOJl!q^*PZ>^yD>%>S1KV^^$NMAq@jLn&YF`!ZpW;cnH9b3i8NaM5z{hlP~b!ABtG zmIMnZ&pk9ZzLtB5O2WEhd^Y;c58ctfA))>vCw8M6J+q2b3;)X_@g^FyR+~$W$>^4d zkn1|NMJ0m_fg zD8b^&Z0ND5>^&;>t$uLpamDrP3G_~!9*;rMABogNcf!%R_ew2>RVWf>?><)k{Y5Bo z1N)kg|1%DOSy83yLJ;G|UI)1buD8v!!MsE9eVJDgWa)zpvVr{HWLn$PLix6@az{{E z$JVTVE8$kdB~Z^wcTn! z{Y?N(jLy^+F1cbL`X!?}&*F=IVwBVMM=fRQAK%(ll!>A5Mw_JaS)7z{dN5mODyxmL z|D72pIc|gW{8`rd8GLZ8R~ioBWHi+dYj6|2BiA?WEFDsyQpgf0VUMK!*%ISoB6Tl| zM~T@}!_eAg_{Oy9pb}rn)X3zqKZ)wd=Q#oW)Iafzj>pcZJA)nuQhMDs2G{ZGIrIX6 z&PYB{Ah>(bFUisn0b1Z-X1ZQ9Byk0gUkXjcKUza^pB~MPiKT8nJlxF5K6ingHcjnv z&MD)0!@?9I#3oOSj(XcQ9jb#-=7BU)!87x4U$2c+Ki2Dh)0A-CMacU*IAkO+`f<>H ztL_Lcqkhpx{XM?brrFw}Glf(-MxTb2YcE6jj?oyP%x^BDDr$kUxD)}uA!ueKjHmC8 zb&2S$#pa;h`k-BcBPi~bwQgfh-xWImBaeBDfT_X0Okbk&Q*f{EAi1>K$)pL(3z_VKb+hV56#$aHRgRxaT`NT|23>eYI z$nJcW2g_m_^|$q3Ei-f}@3mHV6;OIETJf4VM_YZSbG!D#IbB(Z7+L)i^@5q@&r@4? zx#pWg3il$?^I@z}X^-9A22sP`S7XJ~FoGfe$nl1^?dUo5Vu{M%h2$ieF<86a;ANLa z@0sj!7J-l~*4`9RGGSbjXxjUY{1p`^bFW;`$H3CUH}k9UC>PH~EO9-++a5>Q!CyLC&V8-$?_#nltBl z=VsTOdG<@*_iD`bAMj8ASol^?XQ>s6dF znA)~l*s6;j`q*1eMJ?X3{5;4(3pN1;YK|NXiorS2&(5ikt^S8dB#->t@)52zupRAs zfIETSmY&iEKxzAU^)dEANa(GOb*mib zt-1wGSNK%1?dhr9(d|dq2jg`cKM|C3+wbi>4-ky2^4=tT`$<$MYaW1zAY+MV*8E~L zjdM~VZ#&&VucfR3gQu3I>$prG6yND#l&8|jqE2|EUR?B9ibfx(9>=4c{gmU}zFkXNKxd&KdOh6KEz+apB=k;Z|QsSP51hVhxzp*JyneP zlL)#xLRtMsIFEG?zh0tLNZJp1uIlg}RF7JOyimbg3gB^nsq%2?dEpl9EJu65Md+>D zZ%OBi(}R&%KCz6quidpNTo%()5RVqV_84@c>%-3;!x1=||Ja$Z$P}jjz8$5D^6^zy z)3K;ONb=`ynKHJ54H+L9yP#@Ms2k1~pTCdR*`2$Gw-ggHog8Ar5Nh(M&eqm;ba8aa=L^C797=# z8f}I#x>Va+(=%IEGgGOn+mtZV@cfnTpA74Z#oLV{z@8b6ICFHF#=-4WKel+Y@xFhx zFVR#dnzl%^k5e4&OUT__u6qJ?g9>lAZS|zoC!N{8p$L5Yvr_J;>2|>WHOEfEH>736 z?q5u{+uiW3)k|ha8o*I{)vI!7bl=(8+27L(pj=^asb%7W@Z6SsRESR}jWYYocYeei zLl+B}X_eA%b#Qw%B^5ybW zYOFdoMAsl_mx(Y%HD6UdaboDA+F`lC`88IqEk@b4p*t;a<97IP_*OXm+c&A2Kb5cx zO6W9YS#e#cG~`;xUFhXyjNs*#gBr@#eN71Mqlz4x(PhWoZma9Fxm{&%gCkD`vK>y2 z!mVx_k$28KtX)9z{RQuvsmplI z0%MNbJQtrsMvnD|bUVeifjlIH-fc6xA)A!;@})Q~qk!vXnXAG>U4@y-a{}I-sLc^v ziRQ*>XIi^@?S30~Ny9Lpt&VLjf7VYrnnr=N@n6C3|NSCM(l_*j@PRl4XlglB zQkk-QSuNF-AzTlaY{yf_)Fr)g-=UgxR;QkGKN>jyS(U@9^_Y*XxMzPTfgo#ePEmtw zcAfO=^C~|${n<*CVN^PqOcF?9gtG87Wfz#miU_ULT&VWz?SD82VZ&XoU$nX-zniZl z`@LREuxU&p#yu+Fk8i&#k&i0H!HSm&sZVeLKJV*;XcQ9DsE{%!I3=_1Kc{1)Ty9-jH(ykuY=mJOXma@Aq~JiNxhVRyMS+bN7LyOdWWu?03_`;#onq_ z?0SB8r?6-sc0_ESUu8D*q&0Miy{AD4G8X&lZHuz?;o~x*N?{}WG+93I#eYd#Qpu+{ zxyXMkvs2q#TkwaTme7Tvd)SM(FC~1IV7~xcohk+YWfgbk{QINB5Z!)4cgWjYvg%4Y zW$3=#5$xCNVX=%AX(r}b5w5!SK^K5aT)gd0Qi{%zHR>yC=%BG8SOO^nv$A`B}`nyK>Drz?1$RmT* z$9m43)YNRLH9k?UPFC9-p3riS=z6~_TnH{<6x%op+n^Z@*zQ?s+n>4*`vR&EF+RyW zw4nOL)vnT%TP!F5lKS`a;MPE(Gd@ zF+cBr=lgxZ72=;tN3;nLspb;trcI-$npgcZS$m169<(RYb1kBFNT{B=G$7K_D1-Lp zB&Zlc~yO;5TMLI%3hA*zS=ebyW>YJ9gzSf z$pE6`6`+&}0I%6@xagC(daNvO=Tt2ZL38b9fwVqF>jA%7ZORP5gd6jw5~9naYdG>5%s^ zQPjQWGg2kt!F`JZ&_Z%Aud2HS=!4C8Fst<+mpqp7GTqmdw=q5r@|f*HZ)Fh_bsKym zIhR8Lw_lTddAhA&pE(nNDjCI$(v%clZW3kcqkepKB91PEH|4O%82_YDe2#dhVW6tV zfc=~cadarFf?7ukBUX7X#D16)Sb|x8uZAgxn)Y+GUC8u5Q(MP6J;GtYc)9&&Wtw7R z&G3U5cU_-xDDyOzI@!xit&Kq)H^+{=@~EX^&bPzi(_|&-M@&Z`W;Gi zYvE7s0;ta`r0)ygj8~JC6u2bPm=s!d9Tx;E%Cefh+_+A4OLF{(HO}Gzst8406vsDf zN0qT;WKjinUr9KD6s6FeUG^&`+w50Fo7laX{F6he5&0!MZLj_wEMw@6vVfKd z$1C3RQl?VNsutmHW#zXHY^6O0;jk-u#z<@$ucK9=5k)dDIH#$*^%tDQ&TzhyBtv4@ zMBSisql>-Jd^tIYy3<0wlMreisdwMYyJh7DO(@zLzbZ86?r4i}vIIGFO7N}Fb!)i~ z9)CL?@1xIl+4eMSyxMo6AfxhD2Z(M1K{>j1PdylLI#d)rGpp6F`Ja!XE?Vb5v2vG) zqhn=};ZbnGx~(xuCU9KzD{6*%A*1Q~bMzvpUr!F_%MCg#-f=N3JW>o`wsAhfwG2C zpms%?!h`)@>|WxCa_OoSfx`4r6Gq)C`KV6e_t|y$_Zk|}LHKt8M1#*0u8$0_vn~5y zTU+y-s3pmsm+Bf~GYCkjgwCPj9-#tLFDQyK=`^mqu^LB`=2(T}>Ihe+5H~k0-LTNKTz|39T1MM(OpuA!x^R zh;6(+X-!`@t*SI5ikfV2uMk9RRX`o?hb{uL+pQd)O`E*WonjImn|L1onQwKR4R`=7 zB#ZDh8Cj|hlthQ$;qPseugM#&9$WM!3@9+CpQJT$GRjmhHXhZ(_x+dL#sk*%7wS(a z7#%u7gd=`8HrWPDW~yWt<5Wb$#c?!2<2|Utt;27S)tqeg>;%Dul9B=PGOULKi(x_v z;qE0bxM2yf=aeQMxcW`5XjpXL_peORS-L>Y><|F()34Xqg`jR73#STzEM}ghi)a8(r-AQU;b>YMpYS{^<(K?qIp7+_hs# zY-4&LiMN;B%Jt=Q<bPy6-3)D2PT6y_Y!I*6r7gp9Q(c528&a*u!JzGqitL4w-80u zeT$H+M#7uDY+7S^(AP za${r=yI||Co|G=PjB^!&%g*=S&yQaSg5H6s(-s!!s&AsQiZ|sJSHQhjq-aCn4qyk& z!?(}hjVoB1unj#u(v=T`$$PE9t$#+Z7pKhvtBlb_t*-LeSgU+OVL-u)XTsW{D#}!O zi^U^bes0A-@p15(ODVA*rFF0S6?zHB1%{Zx+$$l^*~3CxAnR z)zG8oO}4a-SjoKxqE6iC)sE_d))M>eS zDKl56AIued59#TW%Fh#Og6=rC)QI1-?j3wp3F;_?q+oofhM^Q$iEfp(x+L5x37KZj zeV~pgjM8Zt*EYV!TX=ClOn`%;KwayK7u##3@>zf5CU=FTxQql<+@M#lBi>UxUJ|UZ zEtc{Y0i!ce(|GhbyhFE%k2}rrWcVxWM~1k?V9#$@M#?;)#MqMPpq7+Q%y7Wx1yX6K z++0l>W?ipy1Nj=rrQZ9a0{&FDdw60(>rku8A={p%hI+nL5zjbwIAInZb*YovkYdAa*) z=Rrx2rBbgnI)>flEXl|3|8kc$Umd|6XE_@R=VgR77o3{?&r567BeF&UvUzz&kg%i# zzdzCM7^bT^j($!gi*x9+?*ci|cCXKopf6Q@F3G8QGLwt`GY(b{#-@wn{sTqbYXxMN z;JW|lF+jG=S0r>4G32`(-qOnPglU0#D$pgQSE2mn)lHHvN^W(wP>lJbc#b&U@o`wa z@nD{ENZOib7*`w3%UMx2mcn_0hq0o4yy@J8=#lvoW~BUyU$Ng&Of?SIex|7L z=g&?=!od|}E)Fz{UmDMY9=cEfgH_;4rTw}(#=3c{xj*~O{w63XWPH2%mGa%Rbt?@u z+3ciAb)HVC8DGb7G00~OKZLoNehXq((>Fdews&yM@gQw_DwKtKn{n&WJD#~JI1?{c zp`OxxI=$xW%iU4hZOI}$eTI6R){AfU4`M~xKx-fd*NV7Q@&{~;3cA7LqkYwf%luu! zE5On!xOa`u|5*5S)XY>6J4<^BidNKXy0Mp0{;AZOWC|@t%eB>9gNHHI{*hGgec*J- zyIbe=*&CRJI3e{+eHystxhW38NnFOhlbGn|r6E_im-D8|8?6@)%>Zmw1a-ZNj9Tor zdG_KnWZ9NF1FIS;Z%rOuOBAtO6ylhjXe0gQzxE{ErF`OOb)nPK-BtRr_sIg(Utkq* zxrr#n1|@+^Zi$ztwu1ssXjTTIl+MUOkNBhLo7o0!P?Y$y^1~ehGf*ooE*lsOPbK|Y z(E9wNZkG}kyf!-_u`?NjX|Uf7v~qwz^VfHTS5fTYNySsGnh0TLPSS}0=WpF6YUF+4 z7o%`5bqL?K5@paJ3aX6wOv+BMUdx39fZ^RgJ@?MJ!bVHq0hLFG#9iR0|_JA3SJznL5T z++2R|;EjD#S(|iHl-YeOEW)_Pj!YWyy+Z2giGbzR)H(k3n|HoIIYV1aovYR2$&%E< z;Axr#K;Y%S-|TS}SjmSiGGfc{5Z%H+@1Vtj%Ei@l5-`g@!6tS9EZvfkFxAy(u1_l5 zT(-#~&dH7J80GT2A8iru`y$!iO*S>U>eNz$+=b5u7w=5~WDTp&!>iaWZ zv(3eR1<1VB3tS&X85i^EWNJT<=(LSZ0A08uK0@?VP1PxfOU@RBPPvA4fgsPSmk-k- zFM7X7;>au<8KrK&$-KZVF}^;E| zL%n#yghu$#%Fb@Q+o7%_G{2}Py;`&{ty4=yLgVC5Dbhwr|q=*tv^Ib2agWj9c&^^#?oxmPk zVFCmyXhia>!{^X^o-_#6b21isdmN57)I=_(x|{0G!Xj#WoM&N6#|Ez}@Jx2AiAp%1 zihr~k&dHy<+;No*r$1(?@!g7z1H!^LG?y} zDrvXP9fi3Hh>EN)j0KFEaATB4n|;_s5w26{;=-bXKlKnJ?`*>E!tnX-(FpU1gcmFM zZeiEo-nIm#4PS%xdiwBF$yl%H8&~(w(*M>{#NiUUh(p(X>L#Hcb5OE;eVSzp^-C z!sxh9@MP9mC-vTjR0B8n`Q8Hu1fATE79W3Qn5#Rh+ka z;PJSU4%ERrwLe5m^@cH>UG&+f2(6M}htJciez5QI5$&4I=cAb`viB>X z>fESKWXnbS4_-N{q3aCAw=*U>)^?x(x3E}fjz{-Jz0mT$|NBQ6yX19HUzw&ElSt-7 zfbG;CfUTf-$+k_W9yR7^%$WI;;R_49YFi!4z|-CBgKwgvFC&aW4N(DrDYEEg?}L0~ zvm1CW?kdM|#5ol&rfN@R<0WP%xvGIJXJbzEBl)ylfd4FnsTp%#D(WpZsaHTTUaRL3 z{B#_{;i;ZwdSHNUU2z2L&oHmWl4jv}`7zk%ks!Zr%FnDZn3h@;smx1m{O<AwmdId zoyqNVn=Ttl!-Xw`P)a%{EJ^Ou%)j~}r>v=&i??iTL>1?W)Dz6N{y5`k?1;NHpJU+V zI%Iji^~g|X6sg$NGS!jwbC*UhNyr-{T}3ZlDpaTX*iM~^V(ORuJ%nypfo5ohg3ve` zv!c&6bg_%P^XV3?Bh&Pcx2?ANs;%zxE+r32HXoF@C(4z*n}2Q@H3QIA0J_Ci>(5r? zLD6?@jJ-Oi`bvs-V7mVLYB+j4+0J#XS-cNM_5nr+Q-m$W;R>j-Dm$oG;3PvWx)0k& z1952&@!vs%XV_y+sp3R$cHjfm&|Ts*EzMiLk}Iu!PFZKvLwoV7v6OxSMEu+OBIFllnUHThnUKktigpD0`Ejrw^$ZzC(8{lVL%PmC1*ejzn{PS3IC zN=Uc1{Eu6^>^+0C!U4WSb-S&rQEqxUEzlr+oMQ%|6+<@2Bnt(i)afx&Wn-Lx&h>K? zzbtQV>Bh>ca;phQ85$Fetb^v8b-q|@PYMpM%G^%dxlubVeq6Lg1k)sFs5$M|bf~JT zT7OX&bNCTPERM7tWijMc{rE_n&}#JxB$IU$$fKX0ef2n;8*P`}n1Ql2$Bb$4{E<>&s&-tsDqz=l`2W4I9V!4uYqw2JIb`-TSoLZ zvitPY(PTAFVe2UX&Ssd@+i&O6d^K5K&f|)pi^=^8F^e@BkbM`yRqz41WPn;4+*v|y zSaFE^YyJ1u9(uaxw@Q_nc^j)l1fHRUh9FEs%{bvfu9_@SU#%%%J^8IxCMG2N1qsgI zoALyB2Nx^hob}qSQpCF_PzakBpRwPyWEB30riZZz#kM<6T8NdKR)a5bj3e14M%0#A zGJNh00gzihFk(b$#?1zPa;@ZFHrDjVHA4;S z820y6cM}$6^{Z;L4?dwqmuIO+%s=NvH56L-gfb|!a-j#Bkm}<0%W~DCn2vSvgTt;) zQr>c)`T>g;0QP`3Vxt@3kB{ZyFI?o{Jhf}L=~*G3yUO=jj9}HDef!)-%H6f>0}{JBHw8JEj~hw;P6t-E->2xv@X@xpT(-DUgB_^=n2aj9=D3J5#Pvx z>tjT|%`8#GltNWtBK znTm&AcdA?91efPn+5uP{(8Sx8WLVx; zW(EG@_dc*re#9nMetRMb)CuqL(lRvW?!QD`o*hr)VvnI)Yt3vz;Y4s98!sn;YCu7U<+_UqL-QMgeBbhZ z7+PGkly0$XqqsheqsKi|*#<^FQ3!E~J}~rNFvCgFIsoEoWo*=k4_jEOK|I66L^F1a z-)sNVdjYk9R#G-kkuxx8$;qLQFJbB+EQ@^9p)L#{Fkw-F4&o@ULa)jEA{xy|Byobd z8tPus-%DrVewt6d-=Wf%an0WvM71_EWS`}D4OG6P%Z@SX?988076y1H$%K`dRY_7q zH}R~I(x=Z;90A}NN?1jaeU3M%t8~T9WgnbS*<{( z_kYACMJFn7Xfv7qVr2&Kq1}Tst@ex0f-ZMfT;;0nA6)l}nQ}7+MMDF>|8-FA6A+W= zYGb;aVtAw}(a?yk1w6<$p^|zrYINhkl%(K=opwBbq3q+HKN*0ltacNP2y8uVl!#9^ zuf|*?!@`x6$)EcdI9i$3e_yRByX_ z^y?+PV-WORP_7Zkgn9E_`T2enJFfkXheykrL4j}nzyI9ppK{Cfl8F2bUfYg=;Gzk} zyrG8#xUU?m{q0u;QGrYw6VOs`?iX?SoYpCt#0&dYur$ZWCC5ixXLkq4YF@!JphToQ{qvk7DNqY6C^bP!G|gKMlj=oPj(dYoN2%(Q|)H! zFTf{8mVuoC`s4ri$$XgbnFv1vg7cJvzH{>#GVf_SOT5gx%|skd#;4%CJ4>Nh8wR1w z+5|x_Lw+)4h=MK?F7sZ12(L1j-oD93Om$qRSV-W_FWp$?^!2=t5$A_(G{Y+%4?Jj9 z$d4qBbz4)Pm)bKAkNPBjdy`eBMM{tDe1=a~aqo|gSx3S=t}1msFXgWDPsl_)YXxrq z_d{Ie$~BrYstPIrHp3=8Y+|lwM83G`h(mGf^^uAcR8!5+%j3v%mrKNnCS-O<)BkUi z!Du6au*6HIEPxiq`{YR;nD)8$-R|VAN8Vm1Ov1LwwxHsfp1iyWEJjoVZqRthWbwbB zX6F5nG!e6C9g(s>bA}L9ip!XSm7#9YbJVoD%J^`LP^6n-(AJ z+(~4Y%S*CtPnx1+>aDc{p-Uk}fY-6=Irk@$#~s2Z|F^XbiBA*plbpv>Q&S@#Um%3l zLA;JwHN5K5Zu#^)BjZzN&{_Qd9k%r?UK2x$X00S%o4A6)!c8_(@72P9jk=HesMAax zbz(h)4WPR&Yt`ca7_5K+Np};-D7PNTQ%*%)1Tz9v_1#x+Myk!dod{nqK1c{5X_f=s zipc2_cC!DYAigN_w=_1OGXDJs4oa4VyjD^8n85*=CHK>ky&vkU1v|fve>Bel==6R& zh5!2<$Ib6d4_5lEw>s2=#KjH7^DdlKlQhKc+Xx(;6KC zxfC!}2xd8S+I8#tv-I*;%wn1Q_}yX$-FFThx$GBS9Be)K-$D7`K@ubhG^@*lUtCa8 z70zl2{?gWZrE8RQUziapOCQAl-`AD@AP=c9F(-#XpY2lZ*A*MJF85Wf-P&q4a9FIz zOY~PJ|93bvm|+|b5!{H;k&Ckf=d#L91CN604sLfx1JwxdM~l%<#6k)8Wc%eF1jc3*`>KxLzK$20w^5?0Hmxxi8n;m9{Ezq6yzc$ z(L~LRW(|cagF0~>3Dt&);j>=;f`9N38>{93AM$2f!EwNG-t;t|OKWuc&0_-C!5UD= zf)lyr;9!sx7~CQf0Ql?UR8O1S+a3-0TI(#94#ITAIJ2a~pCT!#`~)WZmzE<-qF1$Xz~o z89*r9Y0TiunNy^o@_9h9$!mgJpxxAtEv-x{^~r)0G`em564$gNR2j^Qd@7B6Zl-n5 z($ZC*SEPU4!5=QMSx2g>v+8`XR?);JUA9YP>>3{+_eB8Y|sPn2% z`^j+#E90*WQNwFVmzp3osf^k)Mdaqu{;i`jAhl_z`_4jzx{cvPjn7CxtSlQ zc$W_y5oN8;17Ctc=$03J&d!!xrGloQ zS)}pJX+J1=!XbvRKJpel5`c*XUR@#{&pm<`i>bvhehk)%nnDvKsrjdrQ`r1NMMhG` zMCBg`k#_X7cz{Qqgj^>Rxz;~8?&vGrO;$Y)mV10_T42uMQDc_k26<|z4=PX$3u|W3 zBQr70_iem^a3K+PE4}*tZ~KxSV01J>l8de8(e+hS)(l90_H8vsE)s(d!9)Xn6yxWx;tie^8)`!k@MNq&C5jQ7ja zrCW%6zBmO}h{N&1sdCbZicAJ@Akm|iuV3$yf9np~+QmX`mVy(ZeHMQ6*(AY6#-00P z;Y2SOzPEXbbZa0rt?$iLyBQn= zapavr)HFO44OvF;S{6w#ZNxInc|8%R%Bk9RPKB>8k7jpU2FR_zph5`B|Dpr=sP*XX z5NOXhS*Bc>D9sP0=DuPUScL-FbGY_Km=j3V$4H42*-S4Nw{~F+7dg=w*K?|`ASOF$ z**zNdk=~rc8v=o9UdI*rFa<~%WU6&9eFt|Y=wCBXcYk$$r{%*g#WEyixWt~U1a%zv zqMAc|dLf_ulwDWp*X}dqWV-h8FYOB?Hi!5Wi0%63t6#XZ(qSW6rAUnw#TJb?e~h5- z0eZ{%=XF2reS2^!q=uqj48%CK#8bi3y37IEsi5K7$+|>}|5#<)7M7iA0F}cRFOCNZ z=wIvVCWUXzo$knPSFquSmOsD92u@xDhRe6@y;_5o*FpYRON9q>%}18Ua$i7e-a5+lqR5GI zGNHi^^h6GDSG)|kqRa3}oCs@z?p^KK!f^SZ+{sSLbU3gA+qr_PEeF#C zIr$;+;LA+wZ4~wz|CiX;6VcQ_&Q9!eeoK(Ce78QYx zVd~h>#@;AlW!OkB*<}4xHGUyQG`81Zl&WkNx|Kn zhB=jAb>BHwg>-2}hK`kyEGE7u+?IH=VfKFgzn(*iSDkg?AGQLfYfIpCko7G3R0D4n zofzD=rHLw=_>H;dX0P;U9P%8M4x6Nt~4?j@!SgH2WG=;|K%GPr@M zz9PNaO6+`Q111+v`gZ8S9TP;j9bF45rtMS%>z=||pP>u9&^_P`X&}pQQMlU>GjFt9 zR&1)T>DjL-RlWTscz}s?D%2UGO#u^UlS(ZcnW3kJu?}AN0D37Hec%cUB0j6~8GzBf zYuqC9zs-}mox?DCkTt2^TBafdn6$kYz+xOCP7MIOZ%N&ni=}-OE<6DM2yJWzPz)#X z(FCLlIOe2fet<}oN1oX56YSz>%l#Ik=Pr|_cvXtl#FHl0Z`Tu|@28uty2&_HAVWJ9 zLEV5D;Q_XwKCIxa_hoIV3G!vFG0dum2-n@q`)V}?byM1*W^G~$mtN!ArqEOzxG3`0 z?D5on5v!mg0eSZy7^lhsuvv&ur3sW_n?y`p@U+q24I)yHJ+S&`Tei6g&f|lh_WMt@R|6s`vxZ{6jeW4{ zG06>S@|0VT@rfb3yH2sLti-*XqiAs=gpi#FsW#PLwrC| zf6UCtwXYRMcBn=e*kAKX9o>rt;q#ES5xSzz-7&f%Cua%B`O-t&T`hObLSMvPJYSGY zNAO591`q>A)B$F|vr9eTrY35pLyXQuoG1*gYj`kq$WLluGt^1!|7Ml!Zm7n}+S2dLv#4xq zU?+?XvJaj^$CSxs=J3kfLX72M@E5nK`-qubVEs7U#+oz!EKE-1V>|BEjwZ$3TlT;> zRP?yRwOLeYj%am}7MPxMP+9@8Gao>{&L%iU!*%=25N9nq+K-w`(7mIMPr$DA4^E;t z>81j(h6euf`?sE@6mU#xx8=wG&AmU&*YF-e0QQtWpNdWrvQc;3OGIpZv5QU-;dl=} zTTVoQp4;lM=J3+wD^AH>VBFz1K(-w)e>YF2q3QG$YsCI7Ym3UQ3IpA84|oJ8oynx$ zrT_!&G6ldh%2n0WBsc$q+~sfceFbQjxC)QjhR1=OcjW6(;%hBnzh)^mdiDql)hLwG z<nm`-FGb(~zCzE}h3jpz z34g>TUf!Y*32nK%kRko-@mK+>>aHquX}rRqh7SW6a&H@5OP|5s@c)HWdE51-;klxv zIB!u)m)Q)QkL#SjPr0KVEe%IFZN4=i*)kZM7bXb+vGcmVKnmhcYyVJ%YR7vhL~U3M zz`Zhb22+*MGdWdrd6R8=Q zJ*6}S)>SR>J#evafytX=yUDFh`xKT#+<7ev?!?M^J$WWu2srv-cenTh;?&Ty82uXK z+Qk{woVC@k5FAKZDzlqAr~sD4e4rrGrWzvfFE>$XA+Rkb9LciYk^4t>_?v93XO)Ko zj8zfWC*TLm8*6JyuyeDJ3Z#JwBo;&J#q_TgfdQg+c}<_8?yQfg4b!&vRC;WKVt>vT z>Ncip;9kFw)}=LlbUaYZ$}JkjI@x0QPP^3sU%gl0z$}x!-5Gbc+-)mWg2dl?+-tdG zfq7EZs4PlYBL;}^%py<~zZRM2mVN=$$U8!cUTl2F~wVa8?+Cy5+W~8FW%TC##qwUr_kUv!;^)OxJgO5T1+GCHUZJJ=s*aRVTd7UDr~Nnqo}(1W zbmzCbX5+TLVgJeXc^uY0aE{rdMcNgI2xG|efF_n}19`C3zRRUEUZu$GQ}<~*lbvJS zJYM@BLsDuArMg~P7d-(=J?1GCUfK17;S^|w zSQgn6QnF&WH%lvzI>YjPXe!C^=GlLLBsqS$@qE~7f;LxwTvG_Lv#Q3^JS?dOqv-$A zB>1Cz8blNIe^m+gVzORuu;j#%F_ACUwxbZvu$l{EONrHOEH0oaUX|p7+fLj3wDh1gnj+!+yTQvrgLgRNlb!ib zlxjQd%WjKkWCDJZO#*TK0)xi)>nHUU3JopVPWO1Y+CRANnDpUoP1PjawNY~{^Z5=q zc$(79fYyF`yw1p4@Q^6-up*MJ9c_48k(O;Et&UI^?DbrJ>Rw){{x3_?YLR&6Eh z$4W*0H4z4%huV)ld(Kw$Iru2QZs?6RPE(#wK$uRDC|AA!YbZHr^q%5`I}%c~VtR~} zqDXDT@dR*VmOJR;+ZPI4m$CkF+kd6*GuQ8&Y~9{6Xh}5=K)d^I3`czZ#FA62c$#R-Oljoy_Pm?!-f@)TdcG0TN}VM5naYG`bhaji5rgUKcM9)5+s zqyq{irx(unw(otm4{q=D4Pnh-K*fLTQZ0W4u?w%SDk(ac@+|fmN$yLkxb(7LFjrvuNAqjKuOCjU9kmWwf(+5v7Fsp5YG5( z?F_|t8v~Cnuj5@Xtw9*vdtD5&t?pp0&(|{DH7zk67j-c*6jGw@STp-zV=RK7uiuHm z5+=BHaP9>l(k-BfXyz#~m^|i1g}6~&vfry}Q&?pa-`@7u#Mk0ZA`)Xw%>DXzZ#qFlD0`QPb<7c$6qq?7;(loBCvaoKv#^RaEtv^g=YvmqRakw- zibBdV87-`|c_GX$(~jJWu1?#FMB+s4gCgd#$7Ls5`A_X;-~3hCr(H`Gkjlp8U&iIc zTKQ+T^fwRC*=sEqT`r%Afynl%3Wc0SuQytCl&lj#5=xGODYEMN`l()XqzExfz$d^Z zDm;Gq>v`5|^CkATezy3A%1-TfP4%SQ>{R;3&CjVWf)8nug z9G3QtwCI$@Cpe}k$KyCcQdAxg#O00d3C@)_*aTdQ>!(U>&q8OAIoT}O4MH+>N~cw; zPde@{J#ROZx0z4+Nn>aqW-()qnL<(`K%iI@%#Lif zdzM7u%6a{KyeMHIku4MGlBW2&y@{lmKU;Qxv$$pTUp0nM@Y+(bu0@VPp?lGtTKmPm zzn9xEab^r$ZkoHf&lh4|HpoXyc_V`ZTMK(o&I>`!MWcOOai`rl)Sx5J)We%?Bw%sU z-(p5H!hcEAuK77^|KH2Qva)g!AZd#GQv_6-Il&mF`2Sp=!q3fujn1nh-$2O4DvsArTYc$VwlATg~VS0lu#W0-}!kwg3(h8gC%zI*C=$1TX zGuU`k7SE<_@*hX{F4aODZOSTuxXSItE3reStvx_5Jhr7pR7`> z+iNwJUR%6R&i_ML708;=#{dfTQuN8`kI%rfrB~j;zo+sgc6!R^m|A*?kgQg*{-4mf z;u$OYcWm{g9L7{)YXae%B93vQ9An0>ZEXG{43C+EK17&XDJ((pTP=!Pg&=S@3RvjL zN1&hu(3DS|w^gm#-jL3@_o)!Avob&dPY{@Du(PwfQ3h@<+f$^UJP0XsMT{=5d{%6{$&S*E)A0CDnm zLY0f!m*Y<+v2D0Q2mXVSOJ7X<*5xLy+%g*~&5X4zeXa+nyVi=G+zXqGYY1qx<9}K( zh(`bp{+c00MA0-cAgI;aJZ~G>Sk-7P$LmoVwM0$Sm78?Rpp6RgXWF zh6bx_g21RD?DZ&R#bl=>YHxW$uz!k05Yb2*bV;-IozLX=YQ?ZwC@F8xUrF8_)9nEy zIg`aZO!M8@#v}CPUIj!6GPD(DLXPKC7a^zp1U}Ki%^i!nb0_4e?wFa6tE#ip!(#Pa zNAM}wx;T`*^YT7hn?>Z^=sh6MTKBJP6u(8l^MdoKdr~E8r;GWxBU-GK$LO@9@FyL!o#V8;@a!St%2znGA*+|71tWM;UZoaZpi#ttQ|-Wp2L<~ zE^$NDp`lWEbt2dF-njRGYA$eFAKO5^V zDwY%eYi8y@ac|bU)C^q?Q~s)loXe4Su7G{Q&ZorRVNb85#^Hi1Ok)0qD3iWai7I$x zLb?RUwDN#2oS)9a8x+Sw4qKiRNHdP@G8&$S`#@L3M5a01AK1L1G^^1X^R)Y};bM`l3npMOfH=P zIc^BuL+ILM%PO&B8vPHe^uYu34kBB2>sx)ybCnxhaANMl; z=qlbK8{9~o{Ymm*NlTnC8<&y%KozFvHHoZ>u!`*tfSCEwyB>N2jkaL1ltt*`5zPRVc$+qA`Tb0XXc()~>$pqq1xSJ!ixH;9fr0=pP@e#0Ck{P2Knxog`QV;!Wj@d; z%x5UTW!hhGjhQ2IB!_hAEX@-sD)dWF*k!5dVVS@$0_66!85oh<|Hd>8>M%BNUQ~EH zM?u%fjc8m#nb==@yy;=>r!A^O6ZdSX=~u4`K(2kG^Si%2ltThJ?{nB~$9aR%+8>a( zQhFA9(xwuUZ+{(!qcS@7rbOnEy~)ZxMr6-~?2#=i+o2&s zLUwlc-ee_v&yXz~;~4LC>v?{^_x%ITxv%@Wuj@NMpU*d1I>yZBB=&`qFX+6lB!Vc9 zx0OY!j_b@jbs(?(;iw=!68Q40KMfQX7!;j9cdWFj2VZc#(Xlq+T(gN$_~g4_cU8kX ziXQx1{cOYJv5W%HAb<5!>GS6QO2}=joqpx}SSCMQNOhR5`e!K67R>>9(N*jEr(DAe z8lN?FP_zh>jMJKZNF){A^xm3$ktdI$QGgV`O^Xz@A0Vlp!1R_&Xi4qVkGqj?rTPj{ zlKxfs(WTWV3Il`L}Gix=@7!duNE25dtWWWWP;aYdW^=J46Vt@gXsq z%RWtTWazO%G(87oOb!Zc8_imcEI12Y9+=zUkA*$^R*m8kP(8m8I<4|)yvoog4ViVI z0|Sc<3Al1H^(zA4wg{Dg+d&EX2_?zjF`YmQ-7@vV_KXl?co@sQ;`tWJn^5(lf8%?!d1%znfg#Ya{x`posZef!-i$Q> zlNB%1a6LUeSAS#zs%Hbb1&>yQ<>JO2gs-#b zt#aID0`+quK4U40v5Cr77%Ak`qTW>Ou=TPsw}f3a6j6g2@=1S7ykT`bLS?{_W#XvL zw6P|8oWMhZ@p)zfd1Mz`iBAKz&*gX*G`SdlmVwuf$jet#qZF%iOx%iXAni%w$)G-UZ2_D3Ea?(5(>|l4{6#Zu0WL3Q_Fqq#T3#=`f)f7Sk_y6wj znT7Ln=qAD`;tnDF7L`&q1Ve~=oY9z>`TzFFJbm);fObMB1NN9OS>h{iogZcA1fuo<6pC&DQG!L)+L>I1@eX`pD;Zf)+8ybxKttBDbDAV4v z{1f;@8KL~2MaQi|;6?#}LWn3Aq(?sRBqD7}5@W)9;B{4fD%9wjr~~bY!zD z#N>!*Eo>>nN40L2$~(@hq0CTlkw6PJ>0=v*gbiBc+|XrHH#?8|I}5D;4Q9?BrC;QpJP5WRo!RulaY zP2|?%(tLocFNKF1o^-vl&24jq; zll4aoM_V_>y#3`FBkF);qveIKMEXVjfYsremd-*+e1Mr<15qQ(PsIRIiAaiEYKzZJ zwi2JrRt!7DOC=)O$m62ox@QB0{8H)VS4^T9u$60Zl4V-$bWTH<7P$cth^lmR9sOGTf14XVN=Bv z5sRo&Qs3;2<`ZPNnH9*i6aD9qYbTC|vYjl~BPwRi*eVRsPuMmw1!$ETq$|X-;hdl# z$;6$?w_PTWq=gW0|K{fDiWbf7KJ{82@AJ}8Qzy=uFt4+1^>oYs%Z zA}2>jMsl~N{%cP$=4mkx06)j{r~JhP&v{w_)GnR0^#gHP7Tg}VpfU(k0wIH-Oh)UL z?r}LV6g6}g?T^WXKp+}yTZ0RG5=7|~neM6;(NVaoY8znZ9nfeajxvv-&fReVjQIcF z?X!im9rSL2Ae1{`%{VTr2ACDl2;l9gS?R7Rj#;$?_yeefn$BIISFU(e8wPN4^X$Uc zDOf0{GMw+Jt8-+>MhGE)k+W!l{d>TzNRB*Tl@J{B^iA6({ps}8rho9P-7j=d z|5<#6M4u^O^>SDe@-VVv7S&c;H01;#+?(>2)BOF?kPy%cfP| z*tNRJyrX22f417({_c7q$aqYVc!d_Gf-qf#)_e2EpA~G$5?g8O^_4$A-=s{5lHJD> z6R#zVHm?GCX4d&1VNmhlDu!?vf13yhU7nLl5K|zYQc_VJhSsUk7N`DAdibK9wvn$l zRx?4PJ})DqRa9S#R0pG4ui^51(^uk8m^FR6-hYUdZJm;YkNHr|Pj;A|?DgBhZs!-* zBDzMBC91|Ho5@4W(It$#)5}yTQF9s7p6~auNguVHqd?!)Zl-4B4EqY5i%8%Rs)ANB zvC@~6EwOnxZmTxpuK5-MOC^A&DgaA?s|U(GD-#ifXXq)o-N)({=iTONw8^rAc>89g z?~jo?pT>bwm(akG~GT202r%_dhv89 zg1ickFms~tIJ1gv)#eCY7kF&~(o4k5^e~x_t(0QE;LZ*n4Hg+ooM&P{;X0AF{1xnz zDNg}Fa>Peq{u=+`b+1~nbTvAK2G*YnC?83c|7aA)%bYc1t%|75+}^Oeb0UXU^oC%M9ZnK{BWxj&n*qeJU=4TS>Y zh6)26G6Q}K8Vng+GnBl{qc|7!Id=T-OO{(WJ3-eq!Vd7~Q=KCu@+CfrO+u&mzecUJ zb1CnJ zt|Jj*#9%!8(>EtCPs5;kF(0~R3ToW6h?ECkBmKF5Rl*cYyp8F?R$EBGvzxHI_jum# zo`DO`2Pzf~9Ul2_0;B`F8CTArlquTp3{4raYI2) zz)6~fc4ecV5wpri3$T~5m^^qHCslYA{4n{Bxp5Dm~vWUK+Sf2 z@Rx@{T;k$YV91im<5>;el=%)MU6BO2A8Ky>FHHLBTThl%yWahWcs&6v|Y?%)W|A{WX?II=Gm>}x+y1}2F zr`ELf`hQ2Oz~YY!bhOk#z@X``(8e+idYf*fhD+2eQO1B5;4DXhq~wdB3kwfZ{4qF~ zc8c1{NB_7JbCL_;E+k7xT=10qxlG9t^5Lsa_u?Fa`S5y2$Wug7{{6#8p$nz4i>Tp^cA_8ortkcjC0Ghh(B z?mjpj%26&-e{ptpV|4|Fgr|>{8^2?k!?8W%^c!+}cc+tDNP~`wsqgRh3G;Z?K--rC z{F*TSH38m>wxugq^+4zFw9*bpQYj|7Dszm}V$B{#46yJ|x$x_-+1ERl3p-v09V}S`QLBGFi|k`& zV*pKO%KI3ARhAL!C%B1YwO8@P$*xrwN^C?VJeFWnP~sy`!(^3OFx-HCa0qgmfG`$4 zaO1w9C!pFP8A##e<#bFQ;IdEN-%*?OjE6fPw+v-%AX-`YYe{?AnAM+GAoZ&_-6285XUZv`sMR#z*?0~zcF!Mjl3?V)}%dp@(FmY$IW^XnVciF>--?Q-Vk=HJK; z<8oO6@!}Q*3wZ`d_mKAd5&FAM?{%W~2>=~(O+|w!K_oIJ>MY>*gUyo&_>D4K36Wyt zCK3}a$B=Q$g?dWX8kQ22yzc?Jl|!9dv-P!lmG&wBIrj*j>RRZ7k3chS{j1LYA0*r} zC`R8O?Q)o?M*HI=fFdI;Ga;Jwff)uD%gJZWsW*)7d~z<^xi zqsq?P6u;Poc_Q#@S)u}+8$4qXcjM2wp#na+(`Y!^8oKR3ZEI_5h3l#d8)vz}-^68+(ClSnn*N4VtoZd&kf2^h_ zg!!R{cT$(Yn<)}_UxRZ_F@;&eMP*{~w@4zO#(0C8&r`xAH>|KQvp^wofb75bw)N`0 zZmv+snUeX(C}n^8#eVGrv0w-2a%`W?PXnh}{xz(9ncEi|)j8dn_ED%TKjEpea;m+3 z!ro%!g!FwmAT$M&8+^TG^G3SZP!iR0SSZbj*M~WUBQd*#b2eM(&T6j&pK@zdw-NbG zz+P`JAqDZ)Pwz`KsWT)rNS+=;Yyxm2StRO)^h}0JdIO?R^x2s#upk1OydAQkcZ5WU z;)Ea&FDCGK)&rBA04|2V?sw@AdkxWbp39f$}4qZ3`7)xy%xy=9s zFAqTRPW_zX35bZWBd@lX<89B?_EM|56%-Bl{gbj=pOM^d77h{hxSB$JiK=D*&8RQ# z!O+j2>Bw-|Lw>tS3q7o#lX=5G(k2$a7~iCPmomv{zdK$ZVgxfC@f$vB| z79qxr-$ml$>$q@({Lj$v@VgU%)38a0x$}|0+#?};WYm1?ry9%v*?j{vHi?Jb(N^L) zrpN6pV-W01!f!A!rUTg6K2#WpgQoSJOC127*W6R?4o2_Q%VS*t*Y$qs$I`L*65`-g z;*rL%F{MLMkzUU$M((VyYcnGHvEQ&<$jmKI#eJQpmP!-oz)mt~%6XU$!wX-kyfj6M z$}Ll+z1Uf*rxR+R;U|q{TRdu(4Wu*a;s-i-y^ZSbMn*b=aYXjLiFGVidXdFhrB!)O zX;;l`I+A)FVxqV^F5Fj0Gu0g^!eE73d~^zydU!I1hKAbm0;YKQ6hwwU&&}XPqTf+L6q3`bwB&+EGBRnuOymni$2@Pg1-q5?89~^a#OYa( z-mo~Uf1?p{{$le;s^azQ+kKpP%OXWgc)f0J)!61hZ?KyKj|@M=T$GG_L@C_F{|C(Ua3;tw=}Xc#j#fn!VBAB;%`+?_C&vxOD;5C{V|45&zMeax@-c* zLI+=%(FOE?2diGO<%r^tKwD^opeKc`$9z3%FrzF4A>wtQZu7@NOQRG`bWi;UosnF* zK_N0E6{beT|KbM|Vo=R&I6r@_OF`~0k~RuL(rOt>t(u%+0_^FvD`u#SRuhNBWwnYU*RpPbcx6D^05`It02?P9!M#C4ftOlblTEY+Ikr>+)vnIJ;dxgHWER!|8- zOGRqs@Bh81QP}LK@GT_TUFNL*_g00ZIQ%lsy43nddWB<`I5 z{brBPc9h*vee-|$$UWp$0dxA2{#;Kjd`P-TMh5qe%kwzkXVMv|bH`87)tr5u38Z_rXbM_iHJ`&E zc8cJsVA`Nhw+4iY+5l9szp$uuy&T>fLH>qbZyLlRx@M`PGUCF+e&R!vLy2@(LG+7E z)J)|8_DqF+U%x|?f1>i{>86zkmjik@``u)D&!)mVA1NP?v}GWsUiRtdXMibE5FVC4 znw94&eT~R33b*;~cK(NS(6mpS~ zwr$LacvH6}3r)E9VpvbQpY=4djLd$rBbWr~WPK_&zA_fVZm$*p1Zq11AfQ9m)b|+G z3$w=75x{B@!G9OE)f~baP^2>4UKGLqyo|LP$ip^$;^3AeSl&#B(s4 z7cOfy`p4*rnn#yC?+%mm*;#vgurUHyN4-<@1H}x0ll^}mmx0{7A1xHKa9^U^{)6yX ziCxpHO*rALTUmqVgXy3@*WORWiX0=UQY~EVGLInl^GI_x9jvdZsZkz_=U}1p>x#2M zg;WYfCPYnMGrCj94=75!MU((Zf(=;=Jp8{0y8BgJ&2d?L$e#xk)grFXQRHEJODg8H z1qJJ^Ab&oZ8yU7JWC@7kms?0;X#p=4_yd$RUlY)M`i&}WUp`087^@{U4R)8~itYeh z!B~;(qXsTz@V&DBey=NDDU;%DR$3jNoxL2yggL!qHTl+-4Tu9%DyNv4(jpmL1T(^v zVNPee(o(IwxI@`$I`urhEE;#(bO2c7BiGY)c6Xk@Xi)we8j76vbg;MQFTw+_aqIuQ zMt~=BFZ+BkGAm8y4zq;=vWaC`V{k zYLt&ec!#2&MRwO8iKwdxpH%iQ-p?p)!VHDFrm3q}a3K)hq=#L(D(t@}+#=Q!*^?qr zRRZ_+zP2L4ITYGSGv=9Whu$gDk`Jx!V059*@bE!RR5yDfS)o14%Viq!=jY@56{Sjx zdcTtcTExHD!+0W)`<*Hy1E6vxHUg>veGdVm8_`Z31*k89lqFncbVMpi@f>T6>l=s9 z7bBEE4tv(UJet6AhJt;KEy?&EC_P0%0##=P4RuLy?qxCZa zD((KE@$f(&1iUE&f9KTvzxDu8b4(Ju)%1LsKI>B#^-@qhYF%_2z$GjT=_BaCnHPNS z;GhGLo?0`tF9%#}=@3x-aSE74neMKC3UmrbBZ(HP6J9@b02|=`e{6_hN7Qfj6=CzU zMWRT}QYAtI<9P$T(U6;mkAR0RHy!WO#M> zmzD7rdj&HG1R6Dz?A(c74FJ5La3S*cnZnN!=64V#|DJs^P)|~$``T~ejx&Ikrylf7 zor1Se9N9|TP7hlOC5vG5c}@Xl+npYFN))OJ|NfFZ*nOWC{ZLGCO#4-|%V&j{Iif~e z{n#Op2qH${H!=j1K#9Nq@$TEO^c(-0+-4l}vlAxn^-8_DVEftR6my|{sfPWF`hd7D z86t2{VDbq+(*Zpi1or-wgIu6Cr*n9Cn8+z8B22M=Z9woy&Ps}3^$Ov+6EsKFC;|9K zR4&{R`H$Z+|4z0bA$xy6;%o0^4is3{%k5Z!ok7`2xbFiPsn16 zHbzy*Si{ouO5BXB2xUjWNq1%7`&y0S&U?1fo0#`coOT8L{V+kLYDK#SSr+#jM$)Dg!8vwReK zTU*TQAZOjc`?#3*#dvYQ*&jdjc2U3Z9;Q`^z*>Umtj~xY(*D#>Ur(TG3zZ}MGGQUC~F@fA~;tcr??@O`LJY|W4^*nM^haQ8%r zwl0MVK#=@Mn!YyQMHWE`Q!8nC30s}iuXQi*GguoUy0Psa%XwCV*OJ)=`02`Y1hOui zs*hye(e}2o*mT6u%0fi7Hp+W7DO2%ih8Z^L4}4f zf<@Upz<&fnO%J8B`Z&xvr(NltKJn4ocQRk@G4J8e!*497zt2hI8F|_|o+$)J_j(Uc z@9zwRhiKBy7SOxT)jcUc9pxW6ZBoiBuq^XB|FvZ^Wh>GvMqF*$EO-#-lwwN|c?PDA zDqP+U3)(o%>t3?jL|vN7H>%O4AJIto)d>M-mx(J+uL+x1+Jlq?0BB*?ZrDNpe5@w-Aym+>R&?_4*y^ILF-N+8!-qRy}{vC80Th;G%zW5Z*= zz3wsHWYt$tonL_2valZ1Y&Pa_@&8#oYFS%eiV;R|BzUEAQeSQz5v&1<-OR!7p}qoO zL+u1H6K!tclQ0=mfWRJn(yAVxj$KfLNe=^c-64mc3Ho^Z*4O*=eWu;dDQw0%HqYn( zY^?esj7i7kYMbnwZcITYt^OuA3cl$+4ohq{ls0X^GmG@OEk)1jj7 zqRigA+1c(Dml54|)8}6Ti!yfmGeK{HSC>*i(6SSDd!%NOueED5hF`v`1=&F*Vys zZ-A~p zyQ=S%r+@)4gmZ~EC<90Bx`bnq_Z}jB52PnZM}@tSy^_ZXW0A9HP-bs~k-{htu?M8^ zkjeyB^wf_hIj^EXJ%#tY(4|{PQZ7l99~MDmgfcI~FDYy(%#YPyb6R}4H_K(ugv?LC zrxT#iD#wn;l=rlVd2F)i$#1w0{F zaK*r#B%JM5R8B|Ov#6@sb|JB%7oHDmo4ClC*cGcHjoI=I+#yC3A`P+3SYXP zg!?7{v-z4Elj5?2JWlyUp8kGF{y)?fh$2(%zSx*}+Ot$o} z53X`jK&}XP;OU8cWe&mY<&SAw9+NoH1Gi*bz?u*9B-bYBKVAo-@IbFahlYkG>wVZ8 zg@3=C3atK{-&YbwMD62~<+g{pGr)_?V=8HpfQ9Sps_&Lq zQXMV^kolsYSq)abYg)5ZMiP}T{(*eiUIMfyL~f?Ea;8A{CFQ~=+#o9KCxiYylqs+b z32z<3_8jU#D|bi{c00x=oIlE}LyN-ybb<#OcKwnxIubYPRmV4SL8IL5np3B8%hn{I zT}!^za)r$!6-%5P=()cUqdNF3*{t7u@dF&F$yhljIpON-4H#D}j|uYZ*xXu_r4( zmAFPay)RByRg`wc_Y()Mp*(=6KLOu`yd#PtBfDV!U6{=8cPG6|P@IDM5Gec@9!SEg zN8RlV@*`UzUu2Cq<(YI$VbPM5V;G}_N7+qxaPE5T+(1uNHoG~CO>Rw@P0=ny+3oDr zV_Tkx1%u=M$nPcks6`ydRDzj$%J1fmc&YjvtwaX!m_IYmQ+L*c-oSNAE4dA9OqR>= zSA^tJwfhacHI~aCBZPWe9E8+a#1Drx`yl4bZ?MuIK&a-6*I!ByC^%%QtdzY4F(T1D z!mN^}Mj=(~&I8i&K(ky!SCZ#t__?#v`5#{T@9>Xf>r(e{ZhK82mGH{lrKmOoOJI?P z49Ka&+H@7#>^bu{o%47*a9fT%CS&NHd<4S{%ShCqVTYXGo=|-fVEt3*&o08(ex~%q ztzyB+vwr5HP|w#k>2yi$a<Ct@n)1f`JaC ztcrF0X3p^?if!a8fO{H`oyy&lSEY;JC`X7sI?I^C&cBL&O*p+QqYZDVn1{e<-Yu#jOhdq z$mL{C(KrD+e^B1aiH9}0na;UPbt{TLQKLmap?s(HHY_~t2hNf-wgoKMNz{Qs7jH;| zyTfv4Cy0M%M+Hbmv=Vi}f&o_%(h~!buv{W3qhi^AYvz7@n>$+@v~{fuI9X#R7qoLc z);Y+%D>3Y5&G;&QiEnKfv>Q#R(c%{#ZJW~(n3BCS?3775a$50Lel<1Ki8Pa{o{r-} zvFHRxxnf7Tw;yU$$?(!1>bTgEeVgbko(NGlK+Vz~g-&%n*V|<3Y_?1iI~{GfHO~`c zC-H;}T>-|!p=H0Z`}G@?c`rPv*g_w9(;C(th0dvrZ{bi+dHV#@^`>mj%#qw7upPzU zH5FgB9jMlcrumt3`*O@7zj1E<(`dS`h9oLzqaIraW|z5Z`zQ%!R*!9Au&P7f|56!| z^NKyhY{&e4CxZd{b2PRE(4BxB;JceVHqW1Pb3kZV@n%q<3?sgseSc(RL@4sMOeUV$ za%81?M0!@`{Dw`LXOVoG7GBq@jZHJw!ne{Tb0vfJWG|YhxHp*pGpQ@d%&2%jMlwsW_amRu>P^T|D_ERjUmY}D_Sjec z=N%n#L(*C`&T#-Geq{j5u+ALZB2|D7RmCiAgY(Muz5@z&6yDy&~$f`GD@^rxo z-4W#IiK!|hS}@QL@9Qh`9$zwj1GjV4@s5&UQGN%EryltIvvy4t=el;Y=k)_jTKTW0 z!LXFrzJAydAhgdMO5s86 zM0FANPSrXsQ<;=KQZa%=`h#oJrl! z@l;^lI3F|C+7Uy)TK8C!JM5>?9In_<({V7`qdDwomlwt_b;5_mF7bj$&bB_oHn#@S zK|)jZmjeM6Eg|p}Gtia!>vCy?hrbaLRsZ*l;TpG%1J+-_<*I|ZI9c!KTT^y&3_7&RvSXcQxEiMiWe)u_u>_oAEbd|^CyDi2u=Xlp2P6J(eHxwR+${Zs<>$<{zzR_)(- zqJ25Z+7-7ap5tLbcW^F)d;P%|ua|vu!y=LX`Lm}zkF{wi&N{F|HyDdJcQ4%DaBjO# zzjUkkT-zXvG?H5oUKjim5&;L0)tO2e)53bs{gvP1g`?2HPFDmGlk~Fk5G0~Q%E;*d zw;F}`-aW0mM!NX%xli#qU-^Enw<`iwkgs~v?TaHi6G#kFxDaRjQ@0;(xelg9b*3Lv z1>cSG!8MPovI%Ql>NxZAMWYHP4ZK;p(sx=|%mbvi2IcAODk9kEYh#?&bF)7dZ1SU; zOa947EaAxbX!)+})|7kmI46D2QpLi>veQzw?XA zVq16(A;KPG?Yw~M0LKt!sYDSMIhE#7yHztZO!c;Lk^LZ^(m_?^iJh@y;d<32P}3MX z+T#Df^*%eE$#_(vLY7Q@uWT=;alI!D%;V+pc8%M(>qxcmpsing|5Nh0KBJ5~-rMRo@8Qb9&dR2aYTe)gU%fiD z+`SE=)>`+E-s#07&dZUo*sVp*&-82|nlKYXY$NYfX(rE17B*Qc*7bP2qwpy_>Q;U3 ziYWsm%~;RQhVS&TZyolMbfZ2wsN!Uxqx4h)mT2DFlG&xHV^Gv}Ho3E6TQpf#*Be+F z?+CvZt?)rUZ4voS*;!gtiT_=Y6u%32YLIeTOf~q{a#9me3#zLrDZG2aa-cX^N$6lY z=BEE5W9Au|&)%IWepcol@mX}Ur9*SoyH1*{-qox4BYg%E93{Jl#}WAJ0rd?c^7bf9 zUebitvkn*yf;?c8gFYiHf~e(H>TLRhakNL|*XNb^m4%q4`7CyC%_orsk% zzM?xzDB4C+fX;O_Zmvds4>IG5Xa>P>`#g>XaY9}?ga`%fjI5BbFU66PQe=)3oY!?U zBs=VywI#1p>!3<@IE4IXK4DTt#^dgr7NKQ1)U)xFp^2S$O+j|s1uWIlcVI~z`xdwNIJf^oicE+p7t3~D0EhKa$mQ9p)x&f_FEE&Gq+?8YIB1|g z)85A;@}t*k_*P7R2Mrj2%Cj(cJv}1X;NplZCB(dKU{yRnyX^DimE5NUWBQw3K!_)MBY0^o z?6juBS_G4p0oGw@M0EP#aX zDV3A!eSp=67rb)?yG#qpl`&@q-fRAK*jf&8 zkwrhkEJ1}c=JbZRmiO#o+QskaG-OV);0fzXgX6PMA*U_23EjQdKTF~s-jxYlhJp5* z0Ef(AP<7;`&rVMbPDBDY#y0w)mu4O;yrCEwpZ3U?v)jP<7y)nBk|OzeeoR@z-X8XL z!)peRoqo9OnOo-jvu`3~W{}gaYWCR7`k^465i$mEm`5_M1H%E)|q#gx;`wo zUb*iPm#ucwLKoH+#j1$9Ow!oQ&$e_$<4d1&0B+s~+j7iq3%$>DgitI2N?VJ!+Lv-d zVc#-M?8tI*1$7-TclMxQh2tIU*tzr2KPZ+faB;V>^muRVfW;gpG4OOZdGes6cID$_ zTuX@|H>x5nA#$;pY*PK&b=LJsS<9wF4Q|r$_$l1!QBLBiI%Fs~s*0IFDQ82*3V>v? zLf+W)X6SrWdM5*XxCV&Nez5s!@}@nHx~NDP{0>T1)GVBb)kpWvH9;y{6`|pTe`06> zbDPBb0r_iB@@yPs<};ewi*3VzORVI3gd~^a-wet05W8(Y9k%@T565JJ0ILA6rZA9e zynVq(c18oQ>(bwQ2a~SdZT5WC&U*3gm$X~HN*X^uG`Q=}##ek>u=BX{=1u(Qa5KkA z67yYV{tBl+u9A{yyG;}GAiIcW=IiDY%m$V&_jz`6MsTV4hOVh1V5Km`=|BA_2zd zh1$&3Q-GOXb9QBAWsMu#1*0Oh@EL*$r2}Ou&bYr+ypsAS$l8<)^Fs{(>oxqcJFP#h zpEL`7HFK%7pV9pyx;Q`G<`%pmXRIk`<+MGSGBsIxkJ;Y~^`=+nX51a3&dADtjQ#1h72x7h zD<_o3VYvHTrk&s+wl&9RYa&Xs#FVg=52lw=#7PX~j|5-8QcjN~4R?yE4cKVeqHOZ} z*?pp<)4pLFqhNaH_1JT!LAi)F`y9Vu!bPgCiACq zGe(Z+3=?Or4uXZxsGs97v5$8t+cu*1J1`u)QD2zS19C4X&-V)P_uWB4ajhN{*DXNB+MIL8Aa5(Wy- zsJH?0bofs;`T=;i%4ee5^iv|~Fo%TOgc`c8o8t&!xs#I2SuF5B3tdqp=46e-^Z-7Gweb~w4;;C(*M7RFT_uZ)pmx5+qt|_e0}fxcyqOX0A8T6rh*{sP z-o2aA$H{nM(5k(+{=JpMGkQ+%DExVqk4nM4VDOrE@dZ_yDM2O)(*d&Z*?J1PrproI zQg~qiSawZ#jP{y6>~No$;?}|#%sGJ6C+-iXF1AJeEUydQ=*2&FHAvFPE#=65un+~| z&vc{)-NA2&7+DmGe5#Vi~gBq1RoJm=9mo7XIC zd5c+bHr$v;L4}#``H-(`nmUL29dIlY1O0RbC%jkE*LH_G+ds^XTd*CsKjdKdR&kRo zMXCb3L(|Lo9((fqICYX_3jHTSX|du&zHQt5FprF(pEug>-{mZl1hBBM#I`5_$so&j z47hY)J@-#Wwaa1TrBQ4E5pfku}#akZuYG3Lp$S+<~w>M zl?e8wCXJ3%Tzvo|x7F)#JyTB)3xf#LBt5Q&kggJzyBFgwg*uc zrC}R>XC&*!T~Y2o_Y6LV-7Dn7DVM_h%}W^9nur6ALfFf-(2&rxGasSR?w%e^j*HJB zmSKTU(tdP*%SpER!nSwgjBfKneow}KneS8i?;+B`)bh^c zUwsItre9_xv3>kvG?SFrHv%TSa!n^-pGu;uQ?wIC(W53br_TvZzoMsbyGHp9MZcek zo{G8B(UiYvKpqOFG`Sl|wV8h4G+gEf@O$loyK7*<)bvQl&KMfm)&3N$_b$|(A?E3h z&?eozeO~Oy4Y(CT9Z$<`-rGFpBD{NtV_qI1R68Et#eJss_3M;A+jgQ6r|c4g3o1Nf ziENnCDjB6llsG=<3QFmROu=m!A0kJT>6<>9u{lOuAH^(GWi`bs)9WgK7*?~#7*&tc z<-w)-dGxaiU8rFk>&(i*EM*Z<7ju_ygs=HWF!Z)Nk~ZY?umS1eDJpS)n%OKcigZx!bk?nN1~jQZ#{OgWi1xp z541h{cS#f_w(Y8tqtftTojdu0ws>88GJ4s*Hgz~%qd3oQO&(Z%qh$(v`GRu8-G~Bs zxM@h0I4|THiCn`qD&IZ=8ey$+3%Zm-MuoT^&_yQ)2ijnM)pcu9+jZ@S)G#2cjhe*e zNWY`yx7CW8E#xCac}6!7irG$E&>M!!c@U=< z$H6hei|ZJmT6hx+T>9W+tn*@%z+nTzm|8HIMz7@&V>-{ZU*7Hl4v)?j{*1`MeIJz{ zHy`*`%n3E@XqDWF+iQ%Pyo4uVIu9HkE*3pW)l`~o-dn6v`GIQvxo^YzkT;rP2C_>} z+oH~*F>`12zRgEl8z;P03%tQ(92g$6$o1fX2FC<8wmBXi-Y_xb{Lfzb>F!GAMF7JY z1~KX5cd<+dZQt=+Q_Yf5NG5PkCB@3#j%R&9o1)L~z?QShZ-?+i6XTL;LwwID_n$$S z+5MYED)d?FZp9>>MFTRyf)R&$yCLPqeifD}_79IvzF$O^-da24*7PaA6We$6sv5WK zwCVu9W{$by)ZA>+d;S`RsN>iaR3YK~*_z}W7zzV4ssaS~up zqM>8#jg~N4n1jvo|FO1;Qg?rLRN}Q4`E+cb(qY=)@H21ok=4;m7A4<{4-c3olE(-I zRRTtC%l_Y+Z@;CHNT_5KEX|7QE z!1+h7+kKMEAR7dkPn5u?z-%zgDy!=Kma56M>~idR z@6z{ZG~FYGl91m0wwnhu*^GCmWCgPs6>S5CU~CL8KAPD)z$}gV?nbOp61{EiOIKGB zQD#3*^I-_Bhpkt;)LB|BQR_QF!&EVdSvmv9*e{z5Z?EawSPhlij93R-*RUXet@JTa z!}wzU`uE9Qa$tJM>Bo$~z!MpeU}`I&$a$Z~0=FNk#|T}j8sI%|0&!mUp(pR&zt4@I zW+svnBKv8`YtX>V?0*~%i#9DP6lL${GtjoZ)4ElwBBxL>rNi?ZP9O6z@LroDhu6oV z@>txV@$hsbY>Na^lM*_Y#wSn+*%@wkQ1Y}yg!7d-_Yr>ai|tN({rzK%ihx8+o>N_9 z=j3b4{o28~kP8D?EG{kui;)$_>kpA%mPRq1@X%YJ&uYUk5gf-gal?$`ItQRiYH=jq z7-^5o3v7XdWB*2IEz~j<$aQ?D+sn_-*TyfwL_9RQ{fkBJKH0Y5y^JUZN{MQdMnMlA zDYr4~${pUg9b$Be{f>NEgKLJYrl!xm3kF#;0WAsXFantZa--5?nt-p(!yeNW+=g^R zsK+RiWhHkhQ(*)A31u=kpl7YzzYq4S^q=$M%>Y+Zff?7gyfN~1OQce^dJn8AO1mA9 z!{O+;2{zd!Z>vor{o55W>4!-kbN3tME5ksYvF-N1Cu;Fk4>nN;<#M&OzLQglO*j|5 zKGVB`qLTU*p!eW>xpGnbqOZsjH8|C@tCxY)u3RYcDo%6sfCABrpBK(SN#8%Tt>Q^v@@$D(Lh33uc?o-x|y}Axo-ERtUEL1!_ ztCMR8T5aEWlApYxi7muj_2t)))6&-Nrn6I2QqsQ4T1qj_i+h8f>X6fc*0)SKVPhDX z3jRJLv$@3Y>z>iZ#x7s(6~T>C8{ZiinK$nJ5fi3pH^=+DKvy}7vl}rG~!M!;&zRPYRbUHgHi-P;R(KW&4>(Ls3&}{%!3a=1_Tk0pE3QR z9eT)M@Nh8|>=y3zgH|3TKfeZQm*ro-a!KEC)>;n1cAiW$0VKnsEmkR30`NAkPzb ze&40XIw-NvFQL`R3v{kwisd7$h$W!tOztx%uEqfix}hNpr3kLu(?UztD0S^RK!ddj zze;w1ZC@b=_y%fQ7zqhj+2gvf?os|m8H;5&ZE~Z0M8|QYXlJlYVwQJ`NFE(E&j67Kfg1R`R- z8*~OQQ)=9Ghhhc7xvtRy%gJxnf9l~gbVC=9Pr>E$N(7W?(GPn9nqZ=fIGe-;v>$ij zYoVD0!#>aF8tT^o^U8)nN_tfoWuwZ-^M`U^&bjVh(cW&LqSNBEWqEw;^fk&7w!gc= zFUw-cKrz%8LoJl97d{7!qAxur`D(Et=f3N!9P?#;tKeH;Q;2Va|G)8N8*qQ4$$_jF z_Nn>4l+>Un%4-^ayq6=ixYC&&z9aT$ zBZ{2Scysc+!U(DIKJ`}WUSe+kvQ>wbv0kaXA6e~f+7F-!91u2D?Xnt`X)J|E01)il zdr-hrB_+W=={FAi$FBs_i?frwkl+-TTRQCtEssEomt82)QP&aNmiAkGEe1HFa4gOb z=faFhY+e`DK6d{TR?-!w$*cbPY=jQ$2aoE_{$UsxVH2xvp2{GuDiV*&!Tdn*q zc{V>D>;s{H8eP0-^?WFV8O$nRVPn(esD3o;!wqE?xk5k5`JErX7t|gAyW#Qc;T}|X z;1mqcCe$l0&X+ZO=sd2v#2T<7kj@d15|B;-2`TA@_u#$H|NX`{=A7R-d+)XO z+UvCFzoEP1vk#&cUo!k2_LN?Hp>#o==~--sy_2#^tnq!er>tG3lxIXkL*uG2h>MV& z)GsG}H3cD^Ag$rEWB>&)HA^EN8Cv1=csWxl|_B`R^-LD%QA+fg}OA95;K2 zsV4&?M>8XSO5Pi{Se$r_bei}X$QZ;o;oPOSyMsl}q-!sN3n|i7!qTfUZ5D2Q`~^v~ zyiUq$({0GeKI1R-gcE`?tTQ`A!VmmTzRnuF5y^8ccV6wRNRCUR#n061a)PiOowFF? z_PO;l@eN=o2NPcFY9t}1#@%`<$qt)NfYY_-YU{Sm7EYSSW^QjI49bKGJ~;)Q4va)l zf8rVwuznt`_!mbopkwyx!#|dpUQPz~A=`WKjVZD3c~N;eo}BoDd?^Ki z+SHvUwUaP0pJ{?Zz#TuzHdZv$U{SC?}5Q?lPLjj|>owifU(d3dSK$7@TNj*mr# zQnHOf3RJMa8cEsnP!Cb)+UbY4FnsH#PrZBV{FyRRBO)TAh*pkX>rY^hUIbx0r6d%U z7XLE+GssL&l1AH5P4?CRMCi)D;J?-XQrS)-O-oEvl7k}nf z9Bx;UM)O8|xQx-!Le%Yx`m_URG7MtxYvbTpxeKHF?DF_4ka6UW7^te|YA5vm4o#Vo zuD_|QyfS?1d-fMWvVtbr=3W3u*!#MK>88>cBiNE?MXU*XD16pa z%ZO^6t&Dg}=`A|KqF%$d*z*b}Uz)1%t+HwctXvyJU(}D;=SBiYT=a_Rz)>s{bw$`tOHal1{pp2d^<5X zcAi-Zy@tf0L#vYvbTr%huN_SG20WvP;&QN_8*AL>+lWnL*8}YFU&!laXwYX*-xy`w zo~$Z4uhmwvdcpcVsagQHI$$E{iL~+ntOzBZjlTi^Vr3(isLxsOz91r^)-~x<439WL z(NCZHt=;o{5b^Mv#6pN{@jGMHAJl}8mf9H!h+DB}8LWdlA@t$ks0w-3)0+DmJ<;S1 zk{J6H8Zv=l16WfzJ-~4UCvPmP zi1RrS>i%Y|r^q{y8~ITZA32f9p1m*M&G!f^hR$lK7%SO=Oi@i+^&N6xu^v&A`_bY- z`Hm&`L6AY>DGlESj+oM>9{Ee`k24;9()BY0=Ot!1U(m&9#QIte8*Dt_Ad z5Yu;d*(VW@G@Kz2d3fkFF-8$KnwOVn&BXIo-nf{H&TP2#R1bU2`$88Ko41~=dyw($yJ)_}!cXOA zqx(pei}Mck_tgf`K6d6X*bSy#J)oSsXf6KMcJ^S(Xmj?4O} zgcyDAo6IfXwu5gsTN{4R+?7y1JOsJ=xgxVtRIOEP!9VR-t3Q7?tj|QTBw!MIUU=w9 zWJi|mFXt4Ve^Br@38Aslq=~Zm$9WwM@eNF=Bas`vnw1;Bs@$%abD<7Htk>t8C44g} z`1M?hNO4pFmok;JW^!iz;4lH@MIq%2C-GVU_k4RV?}Uww)*`v_{T=as>T(@8E&TpK z>c(sNJ^KUBpS-TgV#S^_-y`^WlEspJBP6?HtmJ44qaOPOU|j;lZ#W2iHbZA>O#2D8 zxTEjuQeBK)qr9K9W{y)|`Ff6U)W3=Ph@5o`z4DU5WiR}X&IqB-!q-2fAQY{Z9rqc# zXK+^n6a8%^QFPFZO2vq(zcxW^{Ic&CF|M6G%+MDax)rld^Q$i8;je$b;+*3ep);|( zbp6c$!x+Pl(*%tQoF2X0%#KErBy@!Ank-PF{qoo_@7u5-8J6X1f;Z^-wu<%ImuLg?}r@l0*ilTa@eJS&l!&XX@E>3>ln**N#h6_3nPhZX^Or6(3 zV#1D+l6gbpI7VF{uJ^>?7sH75^AdTS)(!=H-YZc#-i9i$=R2n*Lk=S3)xAjT=Kop=o!bX$}yP zZKw;+xa#{A`t9aR=;jsH9&4fW@O&Dmw`5;l|J~_2^qShZdgLwUbbo4Ml7xd!VczRX z#GJM12Tt+T0zYSA$`?LLW#M>k5_?_3nz3o7vH4fI{~i{b1_NsC%25!5FYu~ij)z_yvn3~ z3DH>$vt{EF&1-W|H4fUON^*r9B_3P=4y|53aMV?Wl#?2jo%z196 zll_N1e?1jLN?F5}Use2zPQ+hmJF7>f>C6{nqU1{$gUQ9P*QnLzpktssDCQYxyPo}k zAj;bceVoD3ewi{nbdH{Mw0EJ&HE}9N?=n)ZGPmhDJ#p*6vzTzkCGAlsnCK|u+Ck5A zIZ@1TikUy%(#M~vC)1tE0jZvOb3`LcopRVIT%7tyR8H_^p3nUfV>7n^}^6X>d4i{@^}=7j{WzsS`7 z!CM6~v0mgb#kOPG)l|=wEklFK5Ys>6|IZt>M$`toA4<{4U5diUl{28!0cwK*Q1lZ&_D5I9t5!hkm(()00pO(^S*q<;?n8 zQ^gWvjuAP%$Hj^hMO1(q^a$Jwjo(Zx@tt1lPt1eFw1*R*!dUu*rlmewAX>Rok0_Qv z7_M5i^x3@O2y0O{B8C?;o&FZeuZ+0O|HqcGM>|B{Im_ISv9veftah#vB8<_Lwp+r7MZDSsyO z_Xc)!u(w6>eHeJ%=q^m3MD=W4A3)v{OtwZRn=L@8UYAN+#M!KAuSJ5uaOY8N%6y0x zL?YfS{$QT|NaIu88ablX31H`_e;9(#MU(H7fzuE~tlZ?>=udCLl{8 zM0S*n*Y&0<_mCpA6B1eNkLw~{ZDmQ%pp`4V^B#bItbg2>hxKY&e~Da!ib?$7G|1Y{ zJCCea3Xt^PaC+o__sEh+nni&gmYbbcv`c|Qa7N9y=9xp@Jl zf6OlNdNhxKZ?n6({$f1S=f1$aFu z?co0$qfxkAybX|n{dcUly+sK{eMwfK>K3i=clAsq{9i?IX`%0Z$@*QLIw2)RMNm+_ z9I;B%6Z&d?_pUr4w&-~^J^(IAq}DxX-VRwB!vdB)UH_{ov56*j@E0cWh;Mk?OSM;m zn1qxbm98nHR_6oggdLr%uc4&$SvyCTO}s6;iSM@HeCbl8iMsJ+I~8_q+_okLXR>`i z_ywbZ;1}?~_d<6;Llz7bebpG{%kb5V^RE1sinB7>NUZ$)z58|N-ng~ATb~&W_ae;I z8q22KxPqgAv!CI=0~4nBTo?2u_H~}lvbT##A`G>H=upUVmysd_m6S3_Qc4;={r+t| zT5qRwaS?w?^G*EKVIG*1J@gB|D>BFhr)QK+iY=XpCrNXVi7Hut=H0o#Ayrg6Q50r4 z)p55p8@?IL7SKdvNkE8DYkd&v0s!Gb=dkVT*4wt~JGiwKIx^QR557-XR~2!IChk0{DR}iSLE-PU zO@d~!W|=W}!R;3MGpw1CO~r)2Ufqa|=2(XZ2Y}KO;ZM5JAG*ZaZQhgdDah)h2{X2M zmOOi3k)l#K0}C@Vp_-Z+7XdjmqwyOsfdjYP1yc#-tl(*YGf5E1^~jh+ajY(`HV123 zE=0~@N`;wo$Yf9CL2o31ce_z z5@$LzJKdQ%^m`5l#Q;5Z-&6<65;fUyqyUr6;Vn6}c#*ddzpacq*0YlqMEaqEblhiZ zbI48QCIK<56qp12uMtqTVOi~~$?LsZe=Z;%*jo&R=;L9 zZuk_DMp<^&O!-wR{MqF+)|^|fHG-%;qeE!rWYqnY&?7W^-?Jj`7+rJ~TI$qFaiJeA z;*AU_=p6LlEC#HUldZ|kpFMk)yZSyru3Sk|^C{YEarJYp53Fg+i}+}g(bi2PJU0%1 zV6REfp+>;t)w*Ax3C=g_F`kM zL5c@95@$RiieZ^YUY<5}eI$mNxuKQvduisuO9)vSB=ZkQE!K8_CQePKZ5xbw~1 zlV>fsWE{e`us`iG7@!FK2;~VYmqFFt04QEc|A>KqS^uu10zBXWL+6@fhN;;ASx~UA z=5LVGNqD;ULV!MTvXjnKSDtR31pT6G;oA=<2#siFlj==Jsv#KAoJb0?gggKh$xQ_pBn7R-sw zsxlU?Y>wTYOot}%X3w3xL$AcG!R~8Xc)oq`z=y`Y3-Q%qwwvESk72N}v8l7(CKOVCvig^0au>-Xir!DI z))`!K(%o$N8V)QW`rN=*>oNE@kS0!tcPWYZ@v5LsSq97#Wy`Rv`i6@#zKP&B%25A*v^((;JkBdy zM7$}^=Dg0`jt44{>(5$`-9%0XWSm5V>m~8GE$#D5-#!^cAz{Ra26f7Ucphw>Y6gm- z!O;ejUObSDfYlJ2gsFJ<`{+uEHkuLoHkkmgTOolK{A`p4 zXG78Osov<7jpm1lZn9wi3K@R$yX5S>UK7E9Zih{X6=t$|q?@!C%xEYF;^z_Qe zp3)ZIcod5k@ni1Y^9XxtG!4|@Pd>h`M`y^R7iCY*&;yT%>FH61GXRwpen0I=;wSwB zGVlR%I!Etn{PvcLiDGsCQ;@uYG=(8*wZL&Vrp$kW0PxUA;5NvoeHep)HdVFR`zN$` z?{(0o()9=TKMf8TzAs;itBZ4-GohQOjg2WYy*1XR9%Bg(s1&Ek;m2>&@$U8YN5VPW zzHda;^Sy7VN(1N-&hm|&Ihl5U*ncs4ZruC!$SmhSskhLO?`#m z^wTDLYogW$-Uu%@o(L!gg<0)kF8xsaK;^rV5KXVkCfaIp<9e&R3U}R-Um31t4WsBt zlvmzW%3%h34!$F8bE)*vP|(>Ni9YMJ_{!=1_Sr?@y7*0{+__=a5B(3&uP-YOR_u6W ze(@-vO44`*`I6Cw|0la}ic#5M3j^U-Lr4|$C|_<*v;-leb3VOAw!l%)cvCP#4@Xj& zd=tioJ<4&8Yd2T_(U@_J6*YrHoQ8gi3a)?s62>7xfWz)OF)Lpp5Kbnn_*-spZIixG60$vykJVP-1#ra-Ifb1)%s zJ`uhf4LfE2>d(ojS{#uleb7EnZTi7jT`y2A#4|~@NOEfYpiWe4)uN0|Ue-GL9{l)l zhWmWttS66oFhJgk@X`p-#Df{E7HQ6S^dAE=__rqTAI}w(zPMu-|EcPHm!C*;WfU8e z#^Afrd?Vi8g`IMD0g2dYcc_@O+BG})Wzh1B#5Th3wqP7XOx3Y-@?PA~jq?mqVDae3 z-t%tEwVux)!+NKx8I!8Q66nr}D*)MQ0T*2Q$1aE>J!@eN--oo`VTdd?ATHr2UW z{E$#nilD&Sf-TKJ7~gX}lB4=pg=1Vn1{A9ZcDnW&wk4XnZS(Hum8EfPTsb z|J?G+9RGAmaP1uP|HeLgCLr(RMgt@1hN)|itSnY)A`|m6m9iel`<-Mu3@(v0^YG{R zVHAiT-#ED3{}?jSVW{CkjMrqfv{EQ*&uLpoK`!_H5oR8PG3+D9BdNq7+LF+4PJbcy z8#Hy4e4bqeDTxBuS9uIogW-<0JHv>%)B-d7H_gMuCGCyY_+y@l9CtUp+h_CZQRE?b z#Ke-RStI5B&c~+;wZsW@|7RaIAxS z#!3mAvoF!`!m1_>)JM&+^9=MHlXhzM)=s{q-q*l$pq9_mP8CU8xc!a}RnMUht#S}h zn!L<(r*3sn5uV&#cic3osW&0N;;CwbEsm6DrTN=7C{QQq-4!0rc10il^iP)pG=&a^8+}LzkOzUQ;@>%2q%iad5u_R{1S^AK2u{cu>Wl02ld;p zN|cyZ%qszwq~c8+E6EH4DVOL6_pK9d?28M`a5^BlkxIU)ydh0>-hM(59YOb2TF>zq zJ}ZL<1!Qgf#(C90cP8wxmgb-9p|lWgU$Tz7g+1>|?%c;7whlQ3VMq5gLsWlhvoE*ok%=Z$&;> zC&LqdO0TN#T5$5iFqPMEZnMr~l$nIWM1{#J-Dfb+H}xh3#eXKBzb_|=|zjSHDS|8PP!G6J_JewN1LFiQ?B*6cT^H!;#B4=Db zEPcVi9r}n9sF1ggJ;R?5@$xI=ns>0y+0Zt)1YODE3zxsb)&2A6G0HI7+LqY22zNtI z4rj_l7m=!HaV((Jq@VL8b6TXktIWu@sH-TqiD4<1XHDk$o=Z{m5EX`N%TeY_GxoBBwpS3ly+$8Cb=AR1AC2n`)6DeD#iJpZeU@}B$jh*jiYDxu4FFfPAY z7cp=^7b@>KW7n=ATCw<*9cf19x=w(1fpoj{i-f)uv8qbzJKcbm180iYm0GUGX`9-| zVViAxST73uN#1J5)4}f{Ju2Z^V)wD|e0_X5?HnrYVIHtZITVoLouX0>&X%Ui*KZ0C z!GSkm_M>_>!SYq%#{9HKK-2Hu7fk)$*cCr$H&|fYKG{zWSG!(s{Z$OtkFWE`z%9Vz(T&tMzSBtt$XwsMDtTLC?Q5vg z>M9!jT6m{AcZA*%@w>FBtDk&*;OAwQm?SJJ)?GI+CL*pn*z?V-n5Sm5&{Qrf2#7)6 zM&ZjlZc_oEYCVMaCCL%Az=Un3u zapFB7vnD-EQz>d>PWV_mO~$-m`i{DLg~#neYfpel3ec@dmU+p zS=cX5Z!r!Lt1_nax>q%V){t+qfzWgcjz-Ua(jbRI5=J&&sV`pr4L5%>C6!3iXFsrl z;hxs}&3HZD3N|A)?v2V9k1Wbc!&#XHv?o$H0?C>0Em3eyV|4k8w7D@TJ&2G4g3_Z@ zvg|L<_Sql3yB;E$iSQn6JdJCjQ^Nll*!j98-7#D)k%2*v=C=f?o5;(5L<4beDlOx~ zsNcIFE%41nI^@$XRZSVc11+o-rTfkea<@j%%?V!{>)|JF77|}?_{RrX{8Hsosnz0$ z4%-VO;3=2jtI5T*+;VQ@dv4fglWw5AKu6JDd7RC!wofS&;e1}dG@I3szfi->Z>2^S zknXz~8n2tXm9hpTP|}vE;*94of5&6xXLsBd!m7ksm$W^RdK~!s zd!c(&dq4m177Yw$fXA=gkCM)k5_A8(2!`$iftApUWk^1@P^>oX6P>x{9su7tp1yz1ppdK6~}X)hxw9u<6LJ~;5_pC72EzqvZbm+ z{b`H^iZ7?`UJhVeGT~m_TcNbpWW5tPQjm$240m76Vj(hdEpO@Za5N{pT7#dp8&xk29`?bF%Mtl%O}iBDAtIp;_6$_c@i0$ z3o3D`(8N;O{~~LlX%)-wGhM^UuUt8Lyz*4+P4C%HUU>qj8mPg!dO5Ms5Oa`k7K?Tx zZOk|yp$YO}Id}jSv9OpkW_He&H$L&S*G^LLC0lF<_3hZ*1XlL$#kJoTz2>uQd1eb0mn3H=5{IG$qQuxGy%p ziv~!`);>gCjw88;H*D}N@;Cz%Wg>^Nx}%)X70`G+IT}nT1p-4pP51d%v*!U$S1ZP# zIL9xFRMnS`jzdKuCKV z@UJc9eh){I zmTnL*&lrxbf9_xIv}Pg!jHp_|ix`DW@55BC^Njf7{4+bHWnD2a){J0WM6>xHBCy=Efu6ue=3F4 zJ5BvhN%68llv0p9>i97QCc^$AA^!C7BM^PP?w6mx)po!91Vh029{#+!N$A0O8Q;_C zBJ=2=O9V#-J!22q?+8+Hveu*jqD3#=V;6%nuxets%_npRhn7_36bO5g>RWm=*z`V* zwm4@l(PUmEHP(yTe%Q@xLxUUcm|r}iNhM!;;k5HHDXGMvkcX_}^v1IGx}A^!?RXhY zl&U}}K@NQPCK`D428kCE?t4qwX3JG^pwyE6pnAh$JJ;%UMl$-PcL;{hJ*7S!(Xz$c zfb6vuB`oQ}9Bjkb{w)HmHVRUIrP+FpC|z&)dNw>w&$|aJnM5VcEf>bdY2LTe-Zwny#JZk^Syp`QX;FB{{uP_AIq8S*bngP9;lDAXC^P!2z})@2IKvrUl2RXjCrH5B z43$Xqa+|@?ujI7Cd+T!8ece?;tqwBVxS^pX?$w-wuSQF&cUoCt+JhSA%A{iIbyVd* z8nsZ;gGW|k>DQIwK9z(UY?08&XL*+1y&o2ghu2rh`)$(k=Hcfz1PSyktHJ0X;72@P z&;fCg4y{L1P?dIg_VbiZh-O$T{`&x?otHmJ0-|mV{nWot3G%i=Yz$Z_1nQa}X%Kms z|9<8XlzGz0J0Tj@uFJ2(THk(QP;XpSU*oXIhWI5O5ELEI59Fz8k*~rEGp@g5tc*Gg zRuao);I8~hJF6g|mRn$x&=P;zozlxnrNRy+U*X#dyH6l*(j}dDt#gQ)V6_e_` z`SjWj6<0>RGL>4jgG6Mf;8I{ZYBVp~J;|F_h|4O)nwH_!cSs}^e)SG2+uAG1+f}(B zX*I$2SY3Xm_q(Y~&wj@i@f4YCgnqUIR?cJl{x>rQZqU^YA4}$C^v+VW)9cf28nSm_ z?#yLt459LygJ{B;Ag1-w@Ig{Vc*CU67!a1+Q*Dj!H^rUvRiyWTA)%*4HE8@1@T6vP zf|-T*?x<^50{1Ef6JoajlGHjaM}j!l<}|B=my1Fz^-?KQIIq{D$^Ebn(gwVQhzg{9 z=F~afKk~?HNLIT1FAI>7gPf3-iC=lUp`_up~j`Kg{3hRz8- z3%PnV^x%vZ2DWJD@H)ltO;FoQz^76`HD$mZzF9HSa`6Ve!2%i#-RhdXJMd+lsS@Ni;#ig5D zE;?P5>NX-SDCii-!MzG)juv%UvSl}2IGvMh6za3(K^bQm7*_q( z;)Bwl@HWG|(N)51Ui2O0W`XFS^=@2I@a1`uHM8I7IDzB9$jFFBSy8}M95u}pRm=kw znO)(_2mJkR7dWoIt*Nq|?B#&*|9O;wTB5n|s@e4qlu(EepNO31 z7m-xGtn6vO7Cw#JI_Am^w2Zr%vX1NwYLXEQ0l%$c_y2K-ykn`MXVV5r$q(=$xzMd2 zMTy#UA^|| z+dpb2ax{a}OW*Fjp)QPXw z;;thvt8XIyi2gG9i}NuY-$0MlE81=G`%{YYA_ZQW3{12&Ly(w*AN{MVL47Z)Q68c5 zekhL5Kmm!iAK8(Nt}5fLw^e~3jN(zn%T)?H!F8!f@rgx>EfFK_JPasx-i@XpPJ53L&zAfoy#0x1s%gu$XYks~WYO@gM2?mx z_g6h6%Wh*wMV*G?#gy=Kt{p$pdDdCqT}U3}a39uG@R4lWJWRW-aVbMtF7tR%s@|vC z=q2*Zb3Mb6{`PJ;zVk$U>Vw&c4C?iDKs<6Dl5e+s?Q@nRDA@QkZF3@PL-8wC*iHC+ ze>4XSU5WtN29|*Q2>!iZ2U%=!C3Y$Qf(a2Z9T1V8t(&GXw=#>T&@gNq~R%g`wOaLEB3X z{CJKfgy!}JRz5GWkRHK=sOWoMl8(cb5rUPk>82x~s!(%`ExrUw zpaE6V{y@6}vJM*h(am*n`Z%aW^w~^R&WVM%63nI;Z*AgXs{<{4436g%Wkq7EoNyXKQ9=VDj{PSIpFz<1`BAHfE^?88pv6)u*oQQsQrWJDjEKAX_Xe(QMWbi9{WH_F+$y zbiVta4*QqJg81=)UCi#3L?k4|ljjTs0a3bM?hqA*ubetZ9Q1U}Vn2n~`JXUIte4NQ zW#vWr(uRYnycXM+ChS5({P{2A$ab)IqV*f(uUFIg5dL|Qh!65=oGYahE}gBRQmwQh zI?X~`90i!B<1PWOlI#4dCm=PKfcy~j8#n;VrYBL0Al%@83|rv8!L02q)C%i!Dv)*} zzy;Jt<=An{Td9))ethau(Z@Zqn$?C`cW;ghwVPs8njaNWi8XZ`Fw#xCcb114)`$3H zIPY5yX-$Yqd$W0S^s5WD>85zQl=uJCV?^XEB}3^c>DADjXbNz08#?MRL#b4-Rs&kP zfXTlMe{0Bac&Jp@efd}-pidWf;tOT6qZ$XAKQk)x2SN{pa#SQ7M5T>?=zU?x%IoXw zeX5**dEDKFg>8Q`I;%NqwO3G#;@DHxK{cj>t6MMUZL?>3aE`I9Q&v+$y~HPXe9=F` zov_%&imWvkw7MQK+`5OK)%^45koz~XSN=Uu3m^vbUdAYBbCcGbhChl)$kwqZ&r%ck_q>afM)GX4hG;l1K|COs?2b+X_z-N|MhC0v&zQoG1 zEbym{%<#uezlCj?gI2Le&ZE=@-8y`NtV;y@SIpjmth@X#>Q~{v<0+2xpN50;a*wl5 z`X~j4sS=9VJc(eBzYVJvPin@++|%=1NqTgf(v-PrVNxwu@iDf0_s$MbV_-D{2izxk ziK4L&8(zj~SX5}?PDJZ_G=DsCn4*2(g~49|rWAji<{We)7r$bs{Dv!b+HzX03e5>|5Y1hUKNN`EUzlBTYo#V(N4{WG+z2oC@uOYz^lQ+a zL_2N!6T;p%VsmMTp~xH7yTP}?L&fjfpxHR^y;KOUB1Yp{kN|q07{oacHi!d_A);8VtiqX*%KMMVi;l33XXEVD zU46SF0=Y6AYF2hST?{d6ip*lsTGNc$w@{2GHn>==2!}ebRO)4wzL209VZTwmo*R)2 z-@BnE-M8mwnbS|M7N-hjt2~4Gp1td79w3S23<=dfq)^oJlhbYccJxI0n90URuUnGJ zvNl?{KBDf`)KnyKZ<^Sr(Ocl*aL99BGO>|s_5F-{KO^1`slJ;_F7h)l$%q^9gn5$Z zk6w*x#$pYud)^35Cq0^6Mb@0`MJ?UODxF&GPx8+GJ`Iv!6T*W z?%*`ZI6V?P`@}{rG54*U^!l>%M+W4Pq(1>nyXpa0=IgSL!;MI$gEp;+Ei-Jtu6M7* zn8`|zr0Q^>tTr>sLt4 zBSus?C#~nYkBxG+W|r@FoB$d}Yd9O;=w>P_ENM`y!%B`cBmcebbfT9K(y;$n8u{?_ zo8kpd2F}O17+Itmmo49kggKfnen~<5Y5+1-Un!gX^mB-S#u|Ka{mha}N`n7uu5J^W zveyNkb1rg_b`EIqQ=l;>j|~HMToLqA#sdv=5;XK#RP`b~oOJZ}16|J4V*JA;+Mhk4 zqFiXo(B+vX$0=HX_FsWO+s`bYRIg^(FLEqQ-7K6Z0h`jUmZv{u(8vex>ScDm-*?j&3h~Ru^~Qg8MA2VakW@ zh-dYPb|E<2K=; zi$0kyg|kUZ3cG3VKcN{1=Qd}n@qQPT(!sfP-zJH-c?=X*LcAsCsbFY9rMB|c*4&_B z#0Ig&z2&0~6QjF2jntyHP2|&1zo`#JcCs0+NXG|ZgtVI4R!@l>{AGtg9F_Sk;1NEU zVjFNF4O19~fpbl{v7V6l6aQXS>f=%4(X3yp!~`)raN*t)t^OI#~7L)AOuZ-|qhhm6Gc0 zSj=;Bzq>L&5<(JteCO9OwX;t$K?!2AZcpTQMGfhLd*J8ASFa4g#a2#>=5m3O^8Dk+ zp)D4<0iDCDFF$b%K4dA8PSbaGv0-1}l$3{MEjm~H9*yGRnk3?^`(stk9ik`jc@kXi z5KX%$lV?bl+*fJ6R*1bXav~Z*ybV6u5_)mAsMQMx%~*Xv^*jAn-Jhg15BFH;(HSQo zel=vbfV$=0Ye-c?5??2RKWW#G*+;RxfoOB7tt4KsPhHrkp<@1Y^3ME*EdwM!@r?zX z?FwgnH~CIzqce~8^@LxY7Gn8hqTihL&2>^aj$6KesX<{Ff#VSC zOP5XjL}v03_3tsg2q2_ZWu`1%$27%6fL_8!k56}p?03qb%;Hi*qec1*2Fktb|0R@q zGApl)8vEdcRb9#rv1C3weBkq>T`iE)cRewYe#iNChHKPhu>!F(X2K^c4Z((mcZMP@5JMGE+uc*4v*=gW=V8!$2VtJ&qg1!^E2D^0Xl67^X zux_SP!S-?0eR4#(mqZ(U4FKZK;)EUKQL?)>h10-m1Na+ww?)mb#h(FC+y|nJ>S%Y$09fCG-9)-_*#N z+G4xcgBL4i;NMRSsqjHRmu^j#rBUkQQZKSlt_pod{93xZSxVZ)k6DP=2KRmd4CWus zcy4T>0gFB__1 z;)}F!xd)^`FdScrbnh+1zG^C4$goFqNdfIkS?|qR?@O~eVLDsU7ZHza%qQCc;~U7F zm&P+h{zE5jSN?rhzjtMS*|cQsm2|#r)i<$U4ffa($+hofH$h#C)FCaZD?0c(vXrz` zV}<|G87sG$tnOXr7pn;$_<9%lfd${~{wF$j@CHF#5Y8I!?RxqZV*h%0KP>BdjnR0Z z9~+F+umco=MdqHrG819JLTev90~t{B^qJRw6Ik}DOg*7C&NiS`9CwS2O21M4I2|TG zIPW5TeJ~}^Pv<`Ad-u{i^?Y41i}3Db_KD-vk4MHUvp;Z-K7U!ta=CQAxL7`lH}v10 z^(?!qxM<`N!eaiv8z&{L-gvT=a=5Pj?q`BE76jZI;ar3h9WqxvCw&m@Ve0noDbjcJ znusoYI*!ZLo9ELF7mFgKaU(6KL1ai5zYnnMczGljtFwOzOt}3{oTri#BWkl)t?2o# zme|AIE6DD9@JGza5b5en1V;34i;EWN*Y7%;!t5ldIzItOK(gb1C-7`6?v2u(wF%^!Nv z#Bs2OV%Gp$0=fI|JL!G)b#(+I$nv`If&&)wUQw=k?)_MQ*@Hl+t*IRRq!P2s*{GiyVCQYWeal$E@tfAK zy}8T^Puox+^_y*s9L%tt;!`sTXf-ryoiy6|M`C$CqAQQEhQoljl9_T7!@Dhk<3H_M zHFkl*6Fhi4?OW}fgdBxk=A~F@T*ZVhd{Un=g^p(AdSIRmsqu7tkYC=&uqzY6HT&h% zsm3|Pg|shCu*xY#6NnV}ojS8b-vc9w+?0xps4#vYBB0CB5Bdn+&Ma;0>|KgpX6tqd3)|;^(M-%SQ z&@vyI%2Z@$&8n-NE&RCd_0Z3SFU!wRFv<(0?=2ql@?L`;{XE}dH{^b3))5SwmgJd# zU+=A2=aRppzvm^Yu?YrN*R?&O`scy~Hu4uA($g4}v#8lraNBAg9Shjq+aHl}nTBZs z$2v>P%B-Uj?eX;3cAbL^x{O7@tK7=Xo3wYo44O}lWMRZURFw4gewPmpHvG=~BpQ%lAL+PJ zH!i5D8y21@-7nWT38nD}-feAn=nhp%gaRg@W##;Y`e7x6(TK$76X~rF))nMdDQ7~fP!0y~E9vuXE2$w`q3t@o#(^s zGZXASZPiJ1r0Ix8MOHFkfQrIT0+Jsrk+){ZhF-(+@*2?k!KTFOcTe<- z46co%{Jo9roa6ca0eqFCmX_9lScf$Tp->*4s+`hR7>E0S z&EgL)ECNe&=NW2>&fwo>ph;WSloKI0T=Km0Z12bJQ~x|S|Bfqo2vS2BS7jSfj&E6p zT(UTfT|Yjjjb^&jZ3lDfH4d~ZGpv*X{J3g$mq z9Lgip(jO*h(Iosf_7Ood<`53aw@~pu~Ay-sqx^yZDK*c$iuPXzI6&e|^Hfu=TOOwEnNq z>;*X(uDoPN6jvi(jCM*xd1i2!x%;x>v?l2gk?0|d7_1{+sc1j2I`4QY|3B_$6LD~C*)!zWBikXex9q($Bgvk}UYVsNA$yNx z6S9&W2`OY{kBs|smGAGqA9sKBXdKtMKG*db@A-Tg_E>Q3VA`Aq+QDl-ND#84&1~&0 zqpN+3hZ=P6D||D#J7n_O$TNyFv6Ptk!uy5MJ$lFz=Nr!!pn8x+o>Wp?Y%|~3pUOVa z>2iL0kjlizME!AK!1&8%UU)~A^0_r~S*6)}kQMKwe+$EVY|yNV(VHD}$fv$WC`#0t5WvKLji#>#gTIf4I@l$oUThDxSfe7{WZoIc25}@Fu<|_ z#+Z)G;qFX`_qS*gVQKFBpq>4W4ytZz;1 z&yKY`DHve>Z(-%ouh!dt)8ko`r>Gmlwlu^DnKZF4e|f2`%!Nj^iKty~t(b4E1(?Dv zzxesKXxA`zmo1fN^K=!X6x*++SZ{GKKfufj!pFyd1CwwX=U9`FK3)i`<^k0x_41N(f?V;x`P67o!GdyF=QF8-#R#!85Zi==Tl2WP(fyhuYA2#^ulEhZO4-uFW^Us zek%SuD(2+O^MGvyopPLOR3liFY z2;mg(hgiSmdu!OOPVkVHI?EF>MM6Ec`&D2WBPIqb5r%n+xv=%OjIK1xa4bRoh#{$;$1tLUh+48NzYWRxnCahIZ#@3RUf9<2t{5^2*5 z=W}1jENEt6!BZcf9I*dYrZJ++6W&NFB+X6X9wRrO?%z(kLj}w@)MaAM4m56S;p_PcKkJG!FpLa2qk%(np5o`3)wEELOu8IpizOq&s*F+KXY)9 zmGx2yQdgLe6y6QuRYWR2tTqRL)V2*V8vPFL+SA-DXGGU zlr#y*Xs@m{+GWs@61BD&?Q>@Ge5m;L_46?LlZ&0{`Dy2ON0UFD-vPHM?vM}-SeBH@ zP@@$+W5~iQJeB46dcfZTo9-QhL<1B^K=q*dRx&OcekF^Oy_u+I+68+!Yl1=D?JXGc zVR1|)l9nAkX8YAKeO_wv)>2(L1y6MZ}$)2-m zbq$E?({pEmlBY@oa#wQ567aiRrK3`FA)oUSfPa%mlR>gGf9;t*60U4Fi{UP-;(Xpv zpfZ|wZf5d|x22ho1NEoh2eLw}5D4)v48>~$jFU_KNK(15lSOmtJMv;GGCB67JU zud=OtQORGkd`!C_?*jb9CeO9vO!p~IV@9Z?AUbv>%s>J&EFCodmb{rmQ$Qnj9C}E> zV(=K8J15+xm9B*#%0~nI^MMQe!xL?3(Kq5raZ5kL9s{fQ#uI+Gx2hgHeXHiNgyxq5 ze3pyYvw^OWoxwrJL6>HMt!(hW&fKc3VX2?V!nmDbKR3^Dq-^`GZVA;iBnzB8XL^xY_JU+ZYdyV!Z4iULfv6Y zg(^UOh_~wY$Yc1b0LmbcN8TE!yzHCBX#kP_HpMq`{&1riq)oe_D$flj3d?P~!g&w% z6cmvi`Sc$3&NEJ$v^M>H%HL0Yy|<#4A~;p@XAZmsfFl=lwzZ9F^DC1+uM`~=wF^3z z(-j6V`bxZJ`T{Jg2OPnLvcwWzHwV>~>bJVO5#y(R7b=9Zw1WmJ-4<#iMC>3$#hLb1CUC2TgDuCu>Mw4jD2&Mv8bi zuH2d!pq~r3nFf_}OPx(B#SJj)pxQ>;uPIYf`XDPWt1@!XH9@j-Juj6nxI>1mB4(^k z`FOOGes`KA$PmerArMNIIGFVG z7^xYO+ciy$uijj-@qq>^w72)QYU-BDtk^_{96-hz<|A^$zY=u`ImLg*Dv$w3i*Sd} zYKem5M%TNtlNZsreGX&OfUQ{wjgmG|NG?loY+v$k9Vkb_14Cy#@v8mMVlu@`Bm^=qA8IOf-Sn{z6QaugByILO2> zO7GqrQ74DCIw|Rsrqzi@!S)?@-1>XVu?_*f;Lexjiy&{)4WUyUh4@_{1qya;6VQ$6 zI647$XROV(a+W}&`h$3#IizIatcy5|4LD(Bu)ZJL2g2fQ?XEKt>MquF#^s;)TNP#PescN?_*F~FaN-VR5WSh&>7N(3GpzS$Kjn)5L!?=`m| zOB$WJMQKg7{mj{<*Wi$oN;{kM!o%ddEoN~-7@-8x+ z7_-nZ6jWLZ`|L!$gqz!-lFGmy{KsJF%SAaTOUw**r(#wKQdLIMxzA~XHsK zNniuyQbpOH0dEGDmjQb|#>7-Uu0JvOoo0y2P2Szo(apT%U$-DOt%$n4${dl96wsG!sUsdZ7<9p><26TDa@l{fu1}f<{yHi*% z$SLtb!|2m;^cr+>ww=|2a8g=eRu%mX?t!9#*Ie05e3E&Vo@BVO`XN+S?zao_f2XQ6 zPxW>B`N;8a?5}P|L+OkbW3Rvy!r6A+Gv{v{s-H}T%j`Ee1mR(;hz3>lG z`^DqCvot+va9%F|HnU(u3BaDAIwj9RMNVDK6PzmMv($9E9rDDuy zp&f0efbUP2Dx^-Z=|MpKUXf;gY{ObI5=1s?nxUPadVk?Zvhn~xc}&Tg35ia+=YgKB zv0WGd5kJ{g|5aC#XE{deaoV%}<@yI7{W}F2+|w(HAo!J45igeDML}SK?KVIP$~kQH zJbzmCijyCQ|E=^;8r{U$~2Fd_Nc@sGV$^9s& z-b+G-6NW7VU0o&FveHu3EsP4FA;+U26<5Kg@q+u(T&*TuFOfVhg#5vQk4)^CI)J#V$@qN9c!XKuBy3GPA?4tCDrZKO5t~3)UoH$FjrHY50(Evm{*`C*oiO)0+KG8^4cu{&2;V zdwiOovU7}+4+<1>F2e^pzZ>guF%HR8cGVD}(*gcFXmQE%P(|^URZ;X(_4_cQZ7g|<$f^4Qt}@}>r5(x4cR%{S&q`3LU+N+1dVFd1#w+`J?Q3^4 z@!(Ihpc$lY`9@sg{$nd6&}pWZxR3FQI?@XpyMrncPK`i~9A75VOPf)De%`*%KiTmx zsHJ88<$Tb)Xs|c2Fnsq%^9ilM-ZY|(6fJq3pf)Jgt|l|N#AEjC&pjkaD%x*#smav; zc@CNhy#7uX@#`YnsUp8Yz`$BIgBHS~63|H)ifgHlEq|8HTdER9-Zq!?HvDNOpD&+T zpq#Q1!a<2tvP7f?`SR?suZY5a{T{R~mn4CMt`Y2sjPTXg88ePB?^~{L6?vEir7b(%5&89oo46y+D_J4Ao(>Ush$E;{3!;d$lTyCc!kM$SPu+b?oC&WTT9 zDmt8bQ68kB&PlJSle@LLZs~sa7m9E);ezE6n_yb{9sgc@5%KFnqm8xI>k^aC`u;=v z;2zSX5Hn#c0~hO<_knnQel7Eg_|1T*5q$Bp$`H$`MPqMowVq)vieGJP#Rm!lK6RP- z6HWUbI+Hx|>dop>I6gyY1I%d!D*I4pducLI@#I-IkoKm&{z+v)N$an7t7;jgQB^TlNR8dXD-bdOKD^h;qk@Ay0oH5Z=oQAd?O+ZcKDKx1pb zL@;|ziP_&rR%xWhldm6C&)_f{xv<3fSi`y6yr-F6K4Th8CG9t`m~nGNd%>y+CtVjUx6M#aq> zcCVx4RV}E^W!4omcN9tWgka*a0Yfe^?1tR_>9m>Z*iSuGvxj+NA7|V=Cva5i+vmeZ z)LuDJZ1@0tTOU7bdv@#nc_k`T=B=TY-{`ykBP?b&=s|oC6Jg_Fr;d zQy?U-;YomTQ1Dvudvd-OeW}M`Hoaf;Ie>2dy9O?M0Ad^KFjC_=bL(!edFpx6=WCN6IWIFQY~ zrj^4?BpBQ2)A{__!Tc}DLhb;>BSid7`M@!tO2#!N7fy`Z&w(E0c((U*h!nsQ_u%27 zx}1{tHb+Fp+*=bI#NBB82}KVEh(IMd2&~x=ZPD26+#xZ|zL&&&$9?(vc9z^Ux%ZhMl0(s52EtXg4T1G+{!!ckR28&KcLclxC-;VKDgbu6n zG$`OKWeDgQdDN>xYC)}SA}UKicn38eu}UcfnWfFGSZ+&Nt0gmh<7x@9+;2IM8K^*^P>fknH|nN@H_V80jDkdi=nvpS4%4&mBlMw5HxOoEh17X#e*b?hdl%?+lk zgL(w%x`%?EW_gPVuU|R+umgqMQZUL!wQ8gKCu2dgJK6{(f$s0Yrp=j03I}h+>mrlp zSXROP(t-OGmx1p-0Lf5Dw(u9z!@ZReH?j~_=|K>U%)!g-=#BVCvTlt!>^rMBIW7h z@@bIt%u7{3fhmqwOdCj(+z09{Z|fGXC66Q6SEG7BHLZp zKd(7qm@Gamj~pt9A;v{>h6NxaFtSa${L8s{W?mcNF#<-?faz*jvI`>c%$F*9?$aj* zKo_D*-4iNWXtXo~tuO%Dh}7b*5&#ZIJ|tt2PDCZ)^7|9xDE1ihqNYbS3*%bh@v^Jf zKYE^QW|0-4A*GhGk`=h}O>kv~;HR+7*#?SKHZ>AJys}vEV(E>Q@qyqoEOhtSd=vrj zmvX_f3r+Q5e~D2?%zU^_GFQC84{wxXdY8|TZrNfa2I!6gk?Du8h!jKbfoNJcSH*iK zP$#q?_EBUE6kBg#gN>hCi8&m2?!3aeW`0f}@p!MLYWMJ?>n`T6TDC zV`UH0@F;wpbhl(8R!Wkc6>1+Vk4((vnY*#Jbd?+$Q%o%PO2w zb1f_S{H#R!-JiNBK&~AB(*0J-i_`8UGr8EMul1(05G_%CkiE{?lI^kUfzNR{Db}`a z>m!NgCq_+Y?|mS)DWDypqUZw+V?L6yt3Q1(^PvKF*%!PDHAvH=$8s4nO1Eee?Eb}3 zEx~b}K6XK*`%#wP{91CZ#Y_E^>P*Rya1snSf>t+-Xn{iAl;;enk#tAIW=v!+iyaMj zmF1y!sFQnqo`Z;tBlUiBrML!<5O3G*Kof?HgH{WaA@=kL{+o_+qQ z_g#gHwogII7z-Yr7-gfXRHL?H576%5qAq_E_)RSxY7o#8nCi2?hRwr$sGwx097V7A zSzZ?qALH~bNkUiih3>w&k7bKnY*s}oF`AD1vmS;#Shqpi`0KY2d6^^F2c?d0?;oLu z6}g_rO;?OnWmyTME~+oB;X4jz;z9lOKez$BftjC4CtPOr>~|NvL4lR0 z7#TyS)2pdl$4(pF_xAw^?Ps;R*DEaB;DetRI>bpi$R93Yjw$d2ylA$@a=xMJkpc?j z*R;quTN>>b5u(~dx?TYP2z_yuBO96XjEb8#6O0JMC6oQa|`b?-TJWoK0rm~ zuvRtEf59O3$2CyyLwokS3nh&N)^ijG-j41zX=l}kxYL7Evv<-2GRu<#(MW-3==J1} z4)_Q0YBb(k3u9R|D{bcD_fg|I0$mgIO~1Al7QMJ4wRx%ih;Y%vqQ$cfBTKV14)m(Nn=6*o?WLg zrc!d>A@47>N-nL~leWC*{K1BC!j$v$q1BuW7^t3iM7Sxzac_0Q8h%8SuVOHEo9_#% z%n>EI31s1l5~!=n7UxbsUH}kj!hR6(1Gv|)tj=45aR1bfY_`sBczW6T^H1lN)O(pN zw7lI$U%$a!y=kEFf!b@+r{0E`HbcdFCHcV;u5+Ru%YDglC{tM!w9gnedc?>8QQVa1 z9B^(iN`*wx1u{+$NwOTXugMzh7XWR_Dhvz?c(AOl>f%mW`53p_&Kf|b!e8RzaRPRa z{OuD9r5l!tIL`8Z_{cN1lw0U0sRxHXoP4S~Q)Rw6iboMyzG^L&irmKEG#a{|BmOi- z*V}z0^w045mIZW$Tkmdk^>1i9u&C(irL9g^z4pC0S+RAB&C6q|`v63VH?k(r|A6p_ zyDVDP)drh_{hMLD$1G67DPh`d&3voY1UoDplo}NSWuhHLKsD!cnNqz!hli0B^P2rH zsPu^-HV-@-H=2CE>x_LW0D;Oc_~b~ft=JgdZ%1b#;xP>``A!BhhZbz2gkCwOi{b(! ze36&<>8UITZdGFmMWHuNK@0CRe*a2vP7wlJTRd+VQE}r z%<7vESLgQC321|>+WXj{lSC}IWBlX$9{T=}8ybU*D`y&aH$`l#Yg(0{mmFAFxx5W*u4{I>w zO3mEJCj=6Em0c#*q0K{^?7?d$24`3Rq*6~6AGc55mujM;^Lmo)t|4>M8hCbuSI@2= z9Y|170EM7-**J_r4^>=c@^uTWBcnO5mQaT~@L;M&?@+iVF5_qz5M0>rAOV3Fb-@a- z+F>80Ha>wbTaX+&&m3?)N%p4CB(NMivkZi3S*Fy~M#+d+UoC7IL^~eQ8loQpk-hpu{;4kkgXPQ-Lt--+pFT zWAlOjU=29kw_?!V(W$C=214}V;m-hz;$z=;^YdQ@t=B=lKiKxH-u$ELg@cL@cE%hX zp2C|(Jh9Z{CLhhTu;i2w?Yc@eFg@X*@#`c-vA6Pz~H&{vUfRurp5<$`JgtfFU#37O=lh>>K)^IYb{5Br!6q3@DK2pu(nQc+LMJm^cR_=)GmK3y99=L`T z$(fAR)7%Xxd=sfQ)Vc)py26}xurS00Kmk1JIM617RC2nSY)mjD&)~NHg=zV)m18`~rQ; zFF(A-3>u1s6HEd*=G|9)_j03PDK~+-L;sQ*5Ww;oIEZ#k$|P*^n0oaT-!Ww))bVMi zx+9^L1uO?~o&vP&-k(|ogE4dfjrv+JhR&G(#*hpOVfa6@PIPiZCk((~#DXq!2aj|M z_ZOcMItYVI*}Lfx$J5nEq&t9rSQb;UysTsDMa`L03-g%>O=6v06d zhR)}ci!O#O9iFtYltBdg5r`pGT4FH7aJ>Ib0Fdx8R!dc-fMC;SX|_B~X=?Jrys8~G zwFHcZv}Iykg%VaVukWj3MbbV7-X8H2!l|NpmMKoL7K4Z8M@TS{2{6*2K=(Uht%P?s zG3eA=SXlOKKH^}2(;VVJvJit@DZ`b=i0jyqZO&_)>yBBB_nqRjwd>`(p11ULCOneZNDcylUvUeo}Zd~{P*b%fj6`U9wQ$0 zmBj!PbKn%MS5~jX6L)Ppw5Do1ZZp$l0unMdXjCM=nxa@3q|a+WJlSJV?1nYm(DgGo z1jO7a4R&5QH4UqkY^AP~({X9>^oKq7|0&ZmjP06}3rvkOHdQG~2!Mfkj?_~{bTYWCA? zR8+VUr%&a~an5R6g1&lv47kX8?XG>o36R2xCKaM50M7wx+E>OpHv1j45bIcL{+9}r zLJbz9=6~l14&G;=>){1b9qK~zmiWki!<)*KU$k_w!)SDoiaj=Rs_t~JR$F5Rxb@D&j-vH98O^}?@?sE0tStku1A3vI1NXJoU;!)s5FcCB%UR@olgrI=vTcTnK zt5sBjK7?(B6c<5U(N-19b_{Y@9;$;XWo8h|x2@Toc5I?2p+oQx>rnD35MQdCY3#Js z{dw61>j_1XsXjIVT9YpX&R(WI3=WB*t8G8a=2ylAY1|H|!CnNcw9puJ8fuUuVibV%!3>E|<9RgbXm`DBF@NYcW6qMo9YQ};$E(OlEe@k~?l3b3x z!_OGM12&0=%lO#5GSWJL-MoCdzqFkZr_EC)o8Z28+K>H(XuWZXZfDjjN|$Q~P;_Ua z0B3{g6vv;^>^qLXgbsp~fU^fTn&fJ_=U>~U7rUXp|IUSA{~#D^8^{^gCRY7W&9K_LfW30+JV2x^0!SlNLWt2DT|kSy%tcxZgpOGz>{9#o<>MJ2~qX zw^-8@)qFa2Q_mR>`l-Cci$yxA%nPk=Z>1t$f|UndY5MBK>t=sw6_6=pp7PDT9TKC3 zdEOl34NZEk{`Wo@S#DjO>`Tmkh~)Aj3PMBZLvmK5(#wTj*p$H327gEXcQ*UWX=JJ1 z9mmJv2A{!YJY3zkT+2oS(MRZSS_=P;rle~EfQOVflsEftRJi?!tMPbWjR%hb#Py&H z+d$}9@TY#V|G6>1Tlzw%Sc;K8OfSLkw|n95AR)#IG%#F8#j9^2(0S5iHdlGvW`xa7 z*$&JK6ji0Jd8wZ9-z&qQ1^#cmSGyp;YQ+s^BWw=+@4*q!M_53Lw8$lp7vx-#XUfBgGD z;5Sc#t8x6_f5PqOyLxQ@`xLlHuO>ev_Wu9;=>PK*|NnoiEegCmxkPiP<#=Nm=v;ga O{8Cm>N0!T3g#I7By|btQ literal 118702 zcmZ5{WmFr_8*V9u{_s-Vtypk^JH_4Iy|@M~P@p&jDDFjqyF10*wYXbwcW(N>U+%dd zvghpCOtSOt?95{muB<49hD?b3?%g{y8EJ9VckkeJVV~Cj5Z}Fn<7@9@fn9)eRh9bs zu40_{5O(sxN>oAg-Mi`-lxGtJ*g2Auw2te$cX*ipK5)Y{SHkb!y+LHeMb$kGkK0k2 zaQYHoPv`(_-$rQ_!@AHZTH$Bu2C9ndSB7pjM<-<>|4p0@i<)Miz591A@i zA89yh&6Si;eTb*$>0w8-((XUcG#N|d#A?M8U$ToFnWobc?A7G!JDnu+n7*?|AU2zr7|9frVfS=Q6XTL zsya-ArduR*g0|jKY=v%-mghIf`aC0;# zw+i71@YDI0n59z%p?bnT(fZtgn#SR&l4+*67y75-w-x#*BkqN!4*h}f>qa^m{Su3X zA5w;iC8qRYDf6>4g#ps_8C&l8w*SpeKY}B4_H?-0nfA#!vf+q%4T+j7fsJ*zP9tVr z%}wBJkv))oOu&*9<7*MB?QD^X%ARt;6fT$hu{H?wI_dvCMNRVWxQXz8Iqay){Y^Tg z){9jpQ!z0oIC!hdJO$}YR6(EldVXZ_-n%Sjy^PI7fOpY=@OG*174lpkANnHkN?Y$~ ze;IuioJinROrpIeTZcWL&F9W+cgd-0R`J_|bb_BOC1-anb(t;fPp}%KraCL85+)6@ z%TJJBDa0{i$P--ZZw`2{w@v2>S$IknU@Pc8LRr5fS$|pdCjSXFy0(q72>)&tp ztV@j~!i^Hkxn@;GVFEornBv`fgcCVOQJrcK2QrmuvF?ul=AC}d()Me9v%mATl{`$M zRITn(5FUs9isk< zN>bwfE5Pr2W0L2v$fBdaug|9EY;Tgu{Z>O1<%ld}UKYK%r9_JS9ph3=+9EsZBKz<~ zb_%x=^)!6ow;NO^_Gcwa%dRc*dDL`XS4)aKVycqITPEh$cenNgPd#L~croa9>z#6t zZWGHN>ArVSWY{N--=@BoWSx4i(E&Kb z=>ts!Yv?yGO<{sPWjq$r;>sa{Pg6uLL?2!T?rfcZ>4zLj=zJx>MeHP%oImk*Q1=K6 z-4SHm8-1^0jvvs3qSw!pN>rHb*TNxyibW$Id&p@!UsSs$&DC=~%J+G3VZ!$tW zgZxNLwL4PPb8I&&4aubjqrxW}`89Lq4L*OWTj2eR3OroWpw6YPK&7&K?aMawGBqATQ15L`qf}>an{mwv`M&;Hp>>A`Plg8{3m`9=F6uQA#a^xgzL-L zo9Kw_eElpY5n`rzef(DqB5O9nxU#;Jr32Lf2sDqgvMAF~y1r~A=_nW#rCY1S9ijI8 zZqDzDA-(?Sn0GU^B*26`oMiH?JS5fL`e2sfBXqu8tynkk`QU!k>dB^U;`up)>0@u- zh!B>P{F`_|HG=!Rszn83O7JUBO*^I(1jXR$A1h^p) z3#=QEKH}8fJ?BR~QufC6G-90a+0`FSh}y+#3-JGiGf)*+QEa!h<@d%}r(Uq47DNX9 z!ielyCNEnbZE3;dwise{i`)(k^nh!ZzML)*^n114qUC%opV&#q}N$2K`;3X%?22SRG%5T1GoVu}A>0n7bU zUw}m+2s#hI!AQ_?7G@Qd`O-5T!Yh(NN}O)hY_UQxar~(~d!4#*M}x1y%!J-2#9+xk zS2h^Fa`O7NAYIEY6*QOUSe)?5Y%hUyFX2P#4ePg0fFeWo-6@6oR6NTcO((lQe`sQQ z^VtYk;7d$T-JCJw32`$rdmU2r@N5qi+ua#dcRy`}aB&Ogst(0U$Kf}8E*UVkgD!tphyA!oaVr0;%)D+$nke>^kT zwCXJ0c2{%Yx+WOqr93q7b}%1S6YqkY6!DPE&R*XgnPol6Qgu((;17#cPgJQ$38Dpa z!l#j!d`D8X8WEswOYL7@RKJ7-_>E3vk$!3PR`I;bEsS7CCX}?EW-w1$ND-!#USHmj z>7q5f70V}(B*mvrFu_K$>-eUO__7nI7|d~eUYPkV7jD>hottX`P@}Zu`V81t$n5{U`afb8EFVxe&tX!&>(ErUTFc9 z+RfH;a;xlMfl_~KP>m;{#n<45<7d1Bwo49-R@svsC+KBr+Oq)63CncSN01Nq#?nhm zSEhiBgTr1jaRg|2eDgC@hKYJu!@p^h9FvwwClpwSuin3+zo4~EzVk%yL-|G9H8Ys^ z>zXmwj-UV|1K2L_NXRZYIz~ia>*izk*IOwy1lKo^eH4StA;uE1S=GG1N62e~vKchY z+Gc#<7;c`o*Fn)Jm2ss3vak+x>-sV$M&c6!I@mV2mvcSk^l05) z-m46VN)q@PYGP11cH#ErVl|jfm4D*^qTXJ~Rk(dmWd$-SDkJ~-bQEe|+$0?jn_S+N zU)PCrW#N&rn5U?rgy?YG67tBBo-J1AtsL=4oKIswAr$vr)&Ebj;9RmO;9XngP<=SyHc#l&NuHTwN(80}$zf*HQP&r68z*in(?y zE}G}(cK!Rz?S=d@iLH_wJ@w(#A`S*d4srSt?&070UwfGEU(5g+^1AF$mfECZb*4yR zm(*h_N!2)$-e{^U)nYgEq-4`&C=qr0x1ZD+1d?CoVvl<3`Zf(^x4tA26vV6VB|cGH z$d<5|sk7aWmfH4e1VyI%2L4J!WtUM137#u!u2hfIdlQfXbBkFTM@s%3TYmPClWW;wVUCEunZzR`6ph-iQG{a&sR3!^Q zl-uOK=ej`M9<5P38!{?M;19RNx6<_dJioN#%{{4|SIZH4cX)v; zx{LsK;5<*3wgJ{GB2=3_3dkTtIRR_n8U6wZ3dbF%6eMrvMzQg<-$ZCRl#to=t z>Q$3JnABu-f)LSWNo2PfYFUA_7Rc;2hl4^cJ`;0qYCLNYIXn=^!er#XO3MmE=+Da0 z_X+d~CXYfokbw07zx#hcHv!Xdl%WHNqFkVCnVK5%BHNt==Z)Bsn$3F(|5D<4H3PI- z`avr3R3*E~K%1$0z3nshW$`|M)7I9Tx(X#F6@CV2KOVcai*<$ka{f|5#EiK999EC- zHZ0QlVVtr3K~Cof2_%xV`oSc6 z_nSkpY~CTU(Wk;{@`Pet8bkK;n)V20eUP43v3XCKe* za@b)vQS1Cj1|=RL@}?n2E1w36HLhvB=8RYW{yEMlk{Y;2D;Pg`L;}ihVJABfZi~O0 zbiVqIPdQXJLzt;Pm;$3jR7=kb1nkkc=zLjt%yz5A=RNW0&0a|k+-}WktJL^$=D5G* zb4+8`(1(Pwfcgfh_6MP4&QJNdQIjVTkq)seIC~dW;z>GA9)hlRxaI^a944>#dqi33 zn|DZZ=BWsF1m?P$qErp9Jx~IZw3F}H;%PeCYxA&i^5EA^=}DRQ=lQ~(AkeH~+xPKW z1x8kOI(uOh6E2~Z02AjpGWtSn8)|*mm z;kQR+_&pxFq@V6?-%vWqxX4w6A_$i;xymyHuUoh)3^R~>?^*m9VQ!mGlc{>VftHqT z1pyh}HH^A+mpM{61mo7-%5nLZ|Lpn=AD_gehs!>!Ih9@5sV*V@7bwRf)Uf^rZ0?iY zc|_jvNycMQXfj(t+nNdGAF*{8R@10+;XU~KJt|Mo8(Mo*@~z5i@N0RE;}Lenz~#j? zuW)IzWq0l9==4QxS=;z2$rCaG&+%p9+*HdwQ^hTeY^qMhM~u4Iu>36S3i=hu&O(H0R4pGMEiJl`EozNa4Oy}cot6_LqL-R_zv7wrjd<9y zrS^|ejCz@+^KHok1phItt;voFM?a`1WMEG{Hk? zrP>Jc^FZ*%pxVVuA)AQ(ljc-v{i_pbe@Y>=cj^kNi=V{gIu9dr7=EOuXNUP*wXE7q z4oi$IuK{vs{mgSqB6m6EdewLzm=QUzqkz_{E%mazdHxNDD7Q~PDK194q0NRW`Gp{u zcvLfHxA7;yh3ww`DEzbFwq~UvQzPV{aWB@>Npx%@l3_i8=wiU*ZvG4U%=w{`1a#kH zh{^e)W?~0-0Is624#{WUgtfj53oj<)@W7tN-|sdk*S6hnoWWv{T4MoBu&axAS_olVhfC>Cyzhw>=-KW@qg5TTH7 zs_bqMsi1dJ0*U!zZcLsp)7{tnn9Hr0gpwqYJ91APiKiy7Bty)Xp=f^`40&Ib6R(fi zt+t~;n+b3-@|mzO+QKtV!p;auc3Y!GtEZFh_c-N2k?wf~GnctUaj*Y)DV;{0bsK-vwS!}tH5i~k6?CnY)%-do{ z$GR)S$}Wj6=DB~^2jGyl<)m8LUgmTywn!zL9v->LBgJ`IV!nX}J|!Z9)k0DhD_lny z3tMLT%j?I)cmG@v&G7Y3_+5vrWVKgW)(ki>NDh{xgIAlq+m<3j{vla)gY)eL;Z5=S zeUk6Yj181eQC9AQ_NNhDRUcluZhj~E^R`CI&RuS`uC*78jl~qH*O&upN279ir!bEB zwZjbA$9{H?T>Bt+Ez2E^X%w1U=7jP4%e;Mk{70&+0W{W~FsQTXekLY$_uX(AL2=e+ z_BCjUy|-5;dorFltDuR#Z70 zixWSd-k-?;G~jh9C)F~j*;P>I(_1whFmFB}8nBBwg!}oYG8ZtvDX%;Zq@m7MqxH`( z-*$Jn{bQ%HeKGr^kI+Xigfr2&k1PzkD&%&5EATX)*1bd>lE-wZ8i7{h39uC*5|?R* zm#9J0<#LH}W4ZPKCyOJ(@MJqM>-!~Ox=6Cn&p?0vs^Tk+XfmCBPx(5%U7Pr_-WEx$ zNPY)?zBb};*&K^qg5HlP07?!2lO0;Qe(k>g z8qO0OZPr_t3c;w4&al%^0(Zr$5IS1>eyqez(Gn5cE!DfoN#}lS&eR4ce}> zc9n+-yha%p(65jG2#`vpA)C?W)Mqv;xswz&LEyC}vYY>gK7gHpk>4ZvR0T4cYr^fo zGgnL(Z~W$?wx0VUfN5)4UbL34x+z+{m!R`Ff^dA%2Sq-79Pm{!*hLj6)v7eKsl@ff z^!mK?wjpz1Cr-GQ?_>12H%-TnBa+>8^0%mqt=YETxLFDf^Izozla|D^8$LW1e3R5C z*?Y`@*^#d4n;M>JT0<6w~~u zcdvaJrUzk?Aj%bLH}{sr=T79ZkfoNpJNDkNs)a*ktz6Ja+LhwL!74EOi&6Aw*xG z;F?_r<%XXnq_@aF&axn4`bAS9K-57iP(+)WUw}`{BeX=o)pPl%d*%vg4!}b;$29~f ze|Rj{JItr44O{iOlViXW^=>TnkXXRkkvw9TD}0JQ1mLi6gFR&--8qfC{h}qnkq=7k zYi(Ew6!F=~Fv*co-;7Evb@xNRS5CLD^;jpoAfE{DO}hUtTliq58L}}t{3*_I ze(=UsjI)sSw93ljzwxsF(Fw|tvVyC&P&i;$7-Ow>1u;ZbUf+o=w(7lVfaEa&~t@;7Y!<=f3{+M;C7;8=K@F0TgDWoHz9wmtgx z!qGxy<>{b0z!T999cz~P%&Gk!K5X%M?%kUY>#yRCcDM$3%>@frxS}V`dsx%>#olp! z44>Ze>o9G9iiPs)kn|_HvtQ@2CHApNk=cSmcuoq}`PV@gz2v>jXlNZyWpmcXF}H`B zJH|wXZz?OUH*eSm@I>z0m2;~pZ9!Vx%ROX`AfdOnS?(~f_*!cQ_VAvxgH8WVx(=0L zwa~q}Cs#$&0V1@S6%i5@)C=I$)*0Vpz3&=4SmajZ{W~=TgLws~gF6U2#V0uf!1Gn0 zpYnjyio5Tpp7t$Dw*B`oNM6l{iu(4&5X*jF-gd36xrHhoq+9pR#P`4?$k8u9_Vs8e znhFG145!U1>W~ola-?rOktL`Z+J#|tszfxIcaY-XoWvu~&chq&^}Y8bUOZ@9k&e%j z(6|3EtH8v0yNP}oE5eC3edZv94Ed&J9rW6~?M0K`#2av;PhZ&ea5eFwAw&CilP^RazvrDU6{!8NJ{`y-(3sF4IxQ#pbCPzxBhX&11okz0-4!*>a zRIDAfGH&l8r_)E?H^`jMXDWtlW{>01*=FO%-weB(dmmUO>wqQeQG6JJs9wuY!@`3c zyx2$joi8^h5(}vz6E9EJR@fvnP#bdvMeC9dQJ4I!c3F=vt8O?mWAi^T#C*Xrw1Y%f z0ik~lw`DmEc`{wSse5mB$vG2o>j?i6_wRY~Sn{JoS6drlrNf<+J-(iVTC@0S|D%gI z;4C=4ib7D&g-aaa{(A<^vMN4QLxc+|ia>b1e;35E3FFaY@f0!IPnz(6!cezLFbRK& zqYA0&uKrJ^gN32E4AceSZr@>!R8Vla;m?r&u2SL?y+JEgCP9z5yHxc`#+{{n+L`?^ znb#1+BM13u4xUp_s94ONi)_kv{nCo%C!IcXUoSmL zV*B8d$P<;tm08)%O6Ex`*5PjBVWExKOndk@(5o0fzuI#0U-N4$>`ZeX|h!B&@M(1uFwlxYB|0a&X^Q-h-D-n?p*El zBd(CyeCN5xV6)xbD4YX^aQ(sILX$y^5M$$2fkFzasBfg(FZz8-Ljq9Yob?K7YQK0S znbZ%2Wj-r;<{+$%;%_Rzu$X<$YbU$KM6~q`Zkt z_qQEHH9$(inLb{2Q4hLfXcP&*CWLWAcd-S;smHRx*G4)G&3@$-jMftMMvMAAUhn(H z>(xosT8tjqa}!e}7~yhPfA9m4 z>e?4*-zo&jKdk?>5zxr{b#@*mmE7QEHt(g`?%c6CyA0=Na1tpcX;pOSQe&eLmHb3} zsajn7?yA5CpFh^@#yT}}A8=JZj@jSfuv+pO$Zx;gkf`Toj^#v-&$-Y82X}i&tX*pv zz0xn*ksz)HYJYY*8*I4>0|wfhb51=oHj(7qvMC&nENc#OW1Op^fE1XhZDC(Xfw<~ z0Q~lnzOlo?>7QZeW<+Xn6h9hkaq($ZPtXIWZD?(Tr5u*MQ+( z!Y~}O9*nvn??+<0RA&v?jdlrU=4c4 zsGC5Q`OxR)=%A@QsZw=oK-+${SSTxkCV@fD`hbva%Yt*FRRz3d16G8Ad3Pv*}9K|=tG-s z+WFG`#>Y-H9Op?d^Sa8eV|~mj{}c97v5my@$t;qi67vAlKGAe8dvySz00v4#xa~kY zQ>JVqucMusRZrLWE*#@{h^F9-7dpveVFjJAx9@+IE>0C4`+_QqjRD&{N|hnk$cN$} zP`zyM!2E#cKUZ(~kE<-;ZvZWQfT~I?^@hXN>m?m*V9_Y z@vxU2cW!RZhPiD?WIg=&Zubfdw)#ATHKbSR zK5F^=XB$(~z7>VTZ1~_NjFFdv=RZq`A)MN)O{$`ES&hIQDi>_>i0JOaC@OYEv*%x{ zqi<|h0^5~(5XuY&2Y^?XU^@;D8eqrHr0HmiFqrb7!!k%=u@j5i!j)MbFX_u;X^s#v zv9&7w3(xOu!=gHbyONS)%r`z|VxD(LE)dV#lasCTG55YnihXK1V6k#V9CW`#z2Raz z%DU@p3)>RzLtESHVPz~Iw?agP8J~UrrS-x6$}i(!Gr~*KYk0%GDs{!T@Gfqgly|$0Bak1L{g4`7U)5 zKD=I}GhgHU?+2BH`me_7@gEDB;?~DXhnL=`1o7bH(g31I+XvjVbsLKtiKDz9aUNnF zR?=Qyak01u0=-`?|0GCf*c@GA^o8=@j&RhErkXZ1Nn0GlKKtR--Zo%&9Oq6c`sHT)tcQr&k|X@pz)tL@z2o%|eYa3#+UV(9DUnGB z`q9AxBvGF~Io!}lY?abFgINBoF~I8(@9Svh1FzmEhr82NjS}3#v(3I@Qr#w%?+p_# zEk%jKr5{|FJ8L`L_1L~bj(+XPlGt+l>VK->$i;4*@H3rLf5wxc|swsJhjDv%qq;2VldDw{?V&lJ6BxPn1F_<$4nZ7k$VX4o zJ+Mv)q2fKivL!~ukiOkV%FYGP=FFNiD^u|F4np_&=c5CST{)JaWPBbIY5M$DCiGh= z5AMt0RY0PW%ZqLbwz^S}T51m^t6ajk!n*Hl3Hy%mB4rI6*Y|rTuQKdfs|n3wLRjpE zrID+Uy(jiO)4n{4##xcUcOk_}9bmN6-RyqK{Dy7iDcv;=@3SN3>m&z?Gdp=X{=suw zv^{Icwxb-a_~PAFJt$k8Myev3_d}r&FxLg`>)Og_Axy}#{o+9B!Tgel!Q@w0>1Z-b z7>3(Tr-wKKN2=Ja^Rltmhzv&1Xx$Gi2F=Q9(XBoTaX`ka2k@4Ou;d43GKbHU(E-F6 z=lmSh{{_)P7}OaVtLc+Z&7ED=n14pmAiT7I28fs-2o)R7gBMs1J~R3x7$<}1au)9 z?$a=@e<9Ut=-3c|`HplhFe{Q4_oPSn`M}DB;#4t{4=3Shm~E6y^ zRb?b=O$Svzlxly{2oA|x@XG<=lDA3+hxyNRo7LOA3-Gwa_0vdQ;C5Y_PvwfCpX*z9 zwZGu*?ANs8@ZEHYNI6F>k1%vXCOdd^g^TZtl%`)}5b}rg4tN6oLt!T#nEcd>I*lq9 zHY!4x?HWlvN?F~GD=AvsvKVos0NBlj3A%}TqcMusqp9GBnan-S#?3u_C&p`u#O~tP zoASSn5mOUw)DyxDMY?VzwIv7Ni~G?#C&gL0HuR%}RZsLGi)~CTH$UX)qp%)*@S;UyHD6PVHJt?8BNjh_&`g z%kkK$)(~C_=LEysSo$~SUkBJ6XY3Bb2ZVeCZFtfdWX`H!v-Hsr2TP` z#gpy^4$M!xrn+P7@qG71>mx8zcA&Vr$MWssT zE2Q|?pwsT=R58nG61HD~gw-HJ3dY&FQ3xefG{;7jYdAs=Ij4O_dpT?3O&lLiWQfcd z96N8+tNWHCWIf>4pbEAKOwGylBlpn|ELVM?z#B&xUfmD=4^bfB8-F&(H(TZ-&Gt!|H2`?L2rXl9l*KB3J!}WqF9l`jNRUS>_xP+|vjXnWfUxp=hy5E)A*Q=+LZ6l5vslQK(t-WbU_7 z(A5W$8DWf3U&>MPLB$co(gf~d0~W=!6@I(`E!c~1sO1C7@s4|lkp9!`u5ea(d;9^W znBCtA)*BX7;u{ccDq6dcx_oL$x^*UJ@! z#?WwN0{^B5j{8pS1$O{&(DL>3H4|tUU|^Hk__fDqO{XeBBM@F{5~aF_k{WM1QX12WiN!Ldwj@%#zDLvbiZJz@fHEx_#3^ z)BkvMYabSh+dYf^`**sM(!Q&4XxAIEI@KoY5`@_E?a$C)_b<79Q;6xbNJU0uW`qn@ zvlFvBfCfpH$r_gO{nu(*o+gtaVwk3=Ob_!daa`sYxsUy8%#Jtg!)(?zI+~V@jh{_{byV%0p(x+ z+tqd|BDo^1;Zvkv7BCBILFw6v`2z;+e`mi-@`E!L*ENbw8%6Oz}IhaHgQ*Fb>l`%VP zY3&t4`GgA#?bgEXMC==O&nHh(J9PEo;S=My*PBxkUA@e{m`qqUdu|n9GAzXCHDb=W zZ4u4jG=XVhmt1w=2&OX4={yrs?hq76MB-|~BoH((zoFe?mFOxb0p-F7>|R)pf0~>g z3-un+i82i>^bEdDX9@b0jhh0W^Ay3_ryk}7ZRBtEPY7E1`1A!WQ$z#AuKOp_5m=u3$8!U($O~8yrNL;K8%n8eAm)6F1rEX|HcKBtLspLt*ek@B=Xqoi! z3*(Vz&msex;`o-Eer0G}PDlSvcIS1brSHK-87xpS=*^7$bT>1uyiU$%>cMEthdjEc z?F2|S>v9r|H;V0S2+cZ% zzAm`^5uwMHsG$KGq^ z`WaMaF_NT{**8?20j9--_Vr?1PTfvYt+VaCuHf2Rq=D~R9XzK%Eg%~Y$anj?%vzn5 z9+}S|Mq^jpc1-w?1yS0lc!3_6f{9Qa%-c&#|FIxFo+-Mc?DIhkW56@nDIRlul3`)ZwD zdk~`iwPpP95mtawes-Pr50*X~CI|m#Ovzl4mNG21 zuZ4&G4Kb!cE{vnrgXS?T#6B4}IkZsUT{82myex#muS@PEs0*ru3(W>kJ5`V)qF$xH z#HDJ5ikenzPql8lH9D{bW{xD4@yGW@!RsCD7PCLqE4uG*Y}<*IYNkrda1s%Xc;=57 zt5jcf%rRD1Bvzw`-Y@98*k*ntt@OWc37r?@!5(c>fkrIBEBb(`T^)XaLAYh6`zjd0vOh28l3 zylTBiwnAv?wORU@W=x65nz!{2R;twtUY^1kTPjH;S_MFaccG4(z2eS}HqUrI-cHO3 z%<=hL0fM5sBRji167BxCrr0+Vb`zGF(dWK0l*Fi$dpekpv=ey}Aobe)992IJ)pU|= z3H6J1;L$=?RU0*<_MK5t6zDkpEb7oBH-7&}4|}+2Ji9w;G^-T$ z(IjSP>3JQZm-+qGk9U>)rC4_N(U~aL&nb8MFT%kbBnu~_zzKB^^XYezoGBOrqXnvi zGpZoQWiJlXlmX+E$s+yy64R|6Mjpi@h*Ek1Kgr+RkB%B1X48Lsxdrt114301qSd)c zP$oi74EMi3>EECYiBM;bO#+D_)ZOF>e zb355{zL5^1r`@gADYl)FrXeoXC~bjj5iNuH(6FgD!T3|oNx%Y0;E~ohA&-a?syr=; zB`K+@_{+@}j$cRv?~V8$Ml`K1%o^WlLSzW#ERHXC0dYoES(UKy+;>jFSgih=i6A2+ zW0LE+V*t`v>KH4;zOBumRZ$090k1f6{^Lcde_j3V>MTcoi=;1yM)b#xgJ&KV_p*Lz z$=KjZFK0TjY#QhAUF@(@2`I6XZ)|EG5e@m9+WWzg^ z5%XbRGzzyH!~ClqeAr8PFN9wqHIjXjVf}BV^bLaP{{!zEbllnr*}>uHwA544d;f_q zjoh&6OVx7m>MYUPj;+Lpkge`yc=1x0^ zREyldf4+7lK$P29B!$@tr3AWf-`W!W&*jJMG237=`ZSZIw)6Wu zdA7P8y>-=(g72*Yb0D$AC}_meYFB)>W0QqH{V&RMU=MmI$9O+GJ@c>^ z2-S8XUCr_KcnCgNYj5S#6N{%o4@ga+K~oe_gj3`Zr6&GudowTE#&>l04mJznsgTWM z&hY2=H?NRBS7{!tr8vc*W!-Em8SoC(T;dGW1W$CZ;)zzsLq$0v`qK09=k)OETQn z&W!IdT9-dP7ajAzO?`cl@R+_YNnsga_csRqG7xqI=tan+n_)V4l76LVpKh=pt9n7g zqA8++bk*O>6N6J(268tEeqIET@I7y%5a!0b(p^0!{L&nF|E)Z-rz=q4*mk}Q^WPq! zrP9A1@Z({U1n!KLbv)0=o7ZN2=T!X)X(W*c%Z-&yRrS7`r{qZ>SSQQ%7IWmxd5^oEYE3lVQ@?y5d&ih6a975F#nH)uLFcQ{l(W$Y6$;4^@jq_Bf)78eyEZ z+`@tI-V$5}RVzbOekl#Oz?T-*no+;+w|gKloQ9>qZ>;@MiFuUgQ{NrwII-h{^Wxrv z=y`Arf?OB$U84n*7Nlf$d2zeII4BJt>%>CQUAFMjsSa-w;{#bhDEs7vT}c@d9yF?q zkKjj-;2;T^UA}pfTxJNq$GOikaRe$B;x2+;P0HZ6Xh|xJMdDFgibnM919p)ZwE|!>^Lt`ql>OL-)%`z@ zE&g}|cIba=A5uizeV|BNHwb6Nt-S+BbEO)?WH4kNneQYiGSSGd`z{GD%cLpWhN&rro~{Tmxe|)x!u!@~ke5zC8aiR(K~69cv>( z)JGHoCVvOuijn9mjfd5p%J0>i5WuVWLK1>9AlR9jE@TH*_UA&Ktk26bz z^#jG)8$u@m+n_~fx5*KIrbqeIl0iP8%LO$!)Mn*D&M92|@3KTQqHL^p2a!K1nAxDE zNc}N@>JP6QY`86S9k|{{RhUXw`i`}OCT9rEgf6D@v#1xViNnl3#|JI12|x3B`l|Sj zM4A*BRURn*!nxd2|3NYmP_EZllHiYSr%x@^ai?Dz|EJ;Y;(PUevs5okx+zvN|7cX& z=t&;F(D~1NqNm`C(Wkawk$Y2@I;wFoyFYCETdjYtdjV3-5o8gnsF3D1Bw}Oj07OP< zSE*cQJyvkAfN>CxwW%kcY&IA-YI((=d{ZU}06fb~X~#C!36&RQWnWbA?)-)*D%q(? zs*YqgSmV8J%#d6D#2$M5z|0RlvmifobP2=_?b)yZ&9B_7+H8Of!#A$8=nhD=ewCS* zF_gp#k5^-fZZ2XUkyl5RhgV}D`An<$T>iUPN@NJqS@G z376?xSpvhUywytc!x*K>mjU)X2y_G7@Gq{mD-LS0nBf!>3^c{v-_6 zXqWl^|2A{nT!iQ{iBgg&(c3uGe^0) z^yo3!C4|iwUFk=2tSv-7kjBNdgEF9+rI!ak=xp@T%i{n-C&4HiE|(^ zN`4Ln6}>#|m0YYJpak#pzr3wOkl#n{J-gy3*}t$%s|Elc=fdqk@yA1}2}dJ0!5>^E z6OM((@KbFsh(UNF^VEhY1~(^b6DCdWdw+OY>yF1mFoeGkmLH9~g(YK4s6bN_nHQtz z%^;Vu$Yfud%0lR~GH+kSS0j`62a3V2v%T^IAo+nBgLn%`FmbUeBxjy4MJ>``aj`S? z>=fWa8JIz|a{fp<_4r^gjoHSNgkI5SWk2~+Wib#zkZ#JPvn6E8E%zZ4Z*|Yu#OzHP z;-r-B`WFmAf>mkpAI#DOB--cV|B*&_pQe1HZX0(T=*&~)ob&}%k!jV*V8bf^rx*;{ zOSLM&o`FWQAxNF8ew-oTc@nIC`~3neaHS}}vxP+0@MzAp@B(mz8+dn>xpPxfzOk{- zw#Lpw^({$;hpGda|BJ=VMP{8hdb{RJ!E3u#n6k~ueoBh00ceIohENAsNyI%!mwuT| zb(Di9hpK-(aMyfQ$7(Kn8Wp+?&wx9!a1F6L;?wc6T@H}L5#_s^nwGfanRIgy5XrQ@@o8@ec^ zg*9*kt@0@A!4e#4s~V8NJpO1>9XKErQy!?vXWBoLJsz5zT^PNidxB6J2C9rj5)S0j4etsG zE?a&2DpfVo#4uBx8M}*hxRKljx_dmg!wP2&4crptvF7IH02;~v^u{;nP5rHosg~c7 zW1Q2~9EP(O_CzSYFcDAT$3E2+vaOrZ6v2$18|yEwV1$OVb!sMSKR0I#Ei3kL*S?MnZ+4rX6vUul zq%4H~`UYECWFbLZ_De+x!h|txqNu6QZA-3&zX<782J6f)<%B8-K3Iu4Zo+d7)CABt z)omQ!gBT}EwOA5mSsW;I9?ARYCpsuvR`hBoGo$Mik5$oKHnqiL{GTNtfk4myL)TeG zMfrX4p6-sJyQI6NySriN4oMMk=mr5LB&EB%yQCRf1Sx3|6p)7d%`en2pWWty9S8*evA8(0!hJ*Jp zaN)&BFV;6Gml`KU6S$lJu1$4$6cl+{T4*!(JU6=C-_O1HL}Nw^4tPM!;)?oB)a8?z z6b{*JoWGT+jdyB6*M_mhWLU^72S8;2( zltf4vm7V~MS)p1$Pl-9b(W74K(sAqY!oC;d#bI?Sw=m8*$TK}O_0<@nOLCu!Ev1L* z8&a!Un#;O;5_7-0*2%sE-q+<#Qpgo5jDZp6E^{>2RMje}%xng~h;*=cSI?DhP38-h zPPeMh&r%N33r-aBhOb;=jby%as5-MW*uqrpKw;W)^&yBjj!>dGVuZHN7{8BEvd+F+ z3Z#77Rp$|IgY|InZfYAOF`(CE(Y<- z;=)yF!d(xf-2Va8#Sp6_^DvaOl-T~ocA8+Kw^E_mZZ9eCkkN!xeTJzV2bfJ77dbfm*RbC~0XrCpd z!Z(Y{P<5$klVra#uD&sQr;u!$5WX^Zqr>X|DsUq~555cRpVn^qSJI7!O)=k0z$0BS zyRWLM?G1*i!enWxue_LS;a|;H(;BC1wiZ0%*3xk|wg`$JXYF)jO-+5tL619UqRa<(}@Z zG3!57e6BU`)Xi%oLDOcfN0v7KDT>5)Rb6mQ8@dq4PO~)Q%aOa9r@MtR=&T%I{_C~2 z`TCyB^4?AEP~64E)_uhKtX?zSUcz{YN@-8yW~S|)@K)tnRYMf(rr5qkCuh5Dn8E3k z@UmzKJ)f7jGZ>W{RH5oLnFAQ4DmV z?$pDxhpN-hcdG4FBQ2($$Htk7djN>`n895)K`vUc-wfC>G)q^z)ze+R{}Be%hajo@ ztgbGuz)iQ?iyiN3_Vm>|=+v3l4Z{n?G1lr6eg`z&SRvt&-Rj z5xo~I`0q)&zulspjSE;;CgOTD*XW;g|bXzB6NI2sUFIq+xO0 z%4-CDoJdq-+(Vf7Y}jp5p*}K|MJvNB)H%P=gL~y18!@^~1p8bIgF`8e1VI$kJCvSN zMW$v@^}a(Cl&gAHsSKjo#1g8&nfv;)PCY^0Q)0W7z{*|R2 zZ)*Li^E8o20|ac>ZT+dtPO>C6b83XAA{m75@)#WNW^=#)d^>Vg8fD94#=f(cusY%7 z$5Be?cj0C{9&dvt0dn|?7)CkemR67+KHu+p~ zyxA7Mnagi)w;W?O;%vDcn@ueFw7%0eR^)FRO{~$1l2rYd99!u8I|!PDy5+A>%7i*7 z31AyJd!)J>w%9V2GM4e3+?r^{90mO#{A<0Mhkgv$e$ZviRH3Ugd2UuvZ0@a1 zqv9vEhPa=-CIC}nYQHb=XqS{SdW*C8>}B~H{CM=oOJViDIusqbs%Qpb*KTBK5fwYO z`9)BOPxKxgO9cO*bF}Xl15dt^op)9+&k@Nsk2T8E%d=KJ&LBUIY2ga-L=Q);b54Wm z{jG;p(HPBxSLi3kIzXW2u)w3u#WsrI08wkNDy<$Rc|H$X@d3!CqnG5fKGH7)>8fHH zj$^9N%fK0M< zd?Ig-M_dn_1S2VziuqIH0}yTPx!y1`rJ9sxgKc_NXMH3^fLc97v*5@6NSEI!td2dZ zBm7iaVSpEZ{UjWpDQE3#_!!$Xi9wWgQ+m3S+_Za%IS+M62~)Y zKS#IZ480qzwjGVz>hdwIBpsIpW`cNfcJ=WguU>m?e-0Km+bs2Q@Aw|i;vE`pHgCop z$Z59}M~O=B#>(JdS#rwL+MB#X=V^khw>2L97_gJlNnmf}JDPUUm08yIYKf5gh$xa$@pFZW7Ug5(HuT#nPcYhcKNzJ;3(8Cd=N4Vxf| zL~ZmZg>7SPfASm@O{pi}fJB)1@vjJw53;fX(mmc3s9F9s4fPRDOY=1E1+3EIJ9q}= zD(8G#AXYi_hk@Q-`R;^a;YyL5AOXbhl;naSrvth`L*$D zoEmF-94DKc@O?Mf`DH=EJK?-mDS54cb%lpY=ov>8q)#8u+I0S|2W%($H&MhoUhKyNUFOJqe#=4{qjYKe zJOK%gx3zE0X4LFkJ%h^*2SX3aYIBKy_dUmd{j^=_HeObI1ZPV{Gc1AebdNOm6-pgu zb1QZIpqL0X4#y*3B$yaEk=oj^ISx=!DS50ybC3Ohe*Ktqx&1vDaj6z=R%bXWDfr8Y zxlSs@I6^-ek3#9LlK(5JC+p3ZSxn^dp|nL0U`ZM@C-ba|22gW`(&P13kNyl3G`!-i z>TWAb^CaSBv*=^OjjYlcpN$$la0$rx827Iks7v3mC=6HfaH_#Yj72b54KasbGzg zefrcgt$;`vF=n%%i{cJOWL4M8jB?fAMP_I#9zH_#g@Bc&? zB+1>|qyqjd=T{6wIGM9iiWnjvQ+<%VYW(u=@*gkPz21EG#ZtY2G?gut0})h88zg!_ zGRtyA7+IMYu1+tq3sRT;6htOOZDHOMOh0O6> zqA5(UC0Q8wMYRZC#h*jIy7+gAQo~|K5$C6(B1+6(;-1=9RZZLtR77Si;Uq`tIA%-9 z>W=eN7>|B`$^d-%$k+;SF50CCX&&buLl@1!!NykcPGP7J8K*B|(^yGUeEM39xN)3&X4%l=s-HP5IV}eI_oSFD z4=MGDCnnZ(>__Tg z%dB2J1uUC&tMR|mH*|}m!sGvRgVINTect->7*Cl|z#HovNi~HCFEVaAC<* zer0@4y9Rghx77^CsB~awqwSh167dW~YYH|V1vu(;7$&APIkm7%QL?uu?*0Sxr2Wuw z-1NRe)gG2b)-R9G1~y;&5!iA)yZrTv;-h~6;?idO))6yg?}p(J<-}2yf738gyV7?! z$$tKN*_ti=b$$I)d1mWR&ST0|+#FUCo|uot^OCd4SZ7ejt#B zQE|nh7taW1U~9s(!CMrf0Ew?y8(037$&Rkj@3A$IO$#j5aVhL&tZ*8)DV-F?&hM*n ztB)lPDGGVQ4qUs=$kyY)h@v5ab zjZB*=fA{#O>joRjg!Fh`=eu9$Ha-pUo*eZ)mHg@Gxz)o9@Gjis-si?%$V+^8h&U(- zyJyU+Nu%{4i8MHrV#c0z4L?^J7eL};`k+o<4nwxGji0lP(R~zK@$^`G>E@z_qNuEV ziJBgi36?LJBBK6(&icp&fo#ZY<&SYWl{p#u8MckOyeixN1Uc&BE4#@*^jV`-NV0r6 zMD!y}@&GYqN%FKPNSrtonGb-XsuY{Mt0baTxPi%O zUkgCpp8ZbHhV3Hs#X(UQ^*=gwsH`*HQUb@|)yvIJPIn1PXlPbB)IJ@4pG*%HMt!=5)uxtmPo_ z)}+xBd|CLldE)-@07{k+s6@poG)HPf{EEd);u*~9i3OZen~I;xkN%JlRv~~svnOWg z9~&A4PR(7{Af86VQ(9i;o16^f20c*l65iE_w z1QKq;tx(ucV%X!?Dt;hWDGan<$}`ka8G;cQe3=oj&v4=rRse0=h|zODVU6skmTSNn z(rKk8>)ru&F6*pn8m@rWsj1AK@KcF9G@^Zy7YzI0p4BWL6wb9kZ%&$$cs|5~MacBZ zNYhE1&>Tjj`K6)DeN%I>J4gz^H5p}ew%xHIWoFabaN3m|F~l`gn|iC&J#Lrytt^zNf^ z#{|GysPfGi57r*eWCCdGKFlEHaXpQ0E)E8aX(R0Q_mflr$R4K&&$H^;#dKdzv;Uh0*=AY=gTWbC@R)I}O+N zcfcf@kQeDQ=$Sc^KxZvou}W>P1&t&zD#4nRFbz}4T4iDO?qBEMApOar_Db%!k7N~R zYmu;vFi60PHLNf63Uz_jxXfUa*Ce=}StGmRO|}%D4n*3K@&2=$EWrwZyiEmeOz?dB z-4k%RBy3Aswh;QlpghD(?%eEP`O-$jJA&~uYPuz$)n!@r@uZxyMs|0VR{yJVynYF! z9wB<}`Uolq;g7avL%xNi>SdcE)1L`ljD2j%6~CP3Uk*vt;9J(=2Qr{rsb^rno#azW z*Go&suhaa=-;+ei#?l0ViVy7Yzc`Onwv}$-DGK7PI)o+%oF+~3Pch$UeW1vIUBEvk zt~S^6&ijz}o5K@438-3aQ#^O5!IHNJN;Od-)W7~!qfGEM0&adMQkvXZgq+)sO`Fb$ zfnQx4N1v<4&p$rs#DWr8zT0QMM|>GeQ)?TNtdD*PfMI+j$|PA_?tg}51>9_G*2j)R z(gbUEgx_*eE+S(^JII+|e$dm*cwnIpF^5WQ05VmqRPOE7Hd%?e=oir$A3BG=l2P1W z{!N>J-|N@8LAS$+Mi=w6SP5Wgc4#6`UahPRdG=F^Oq)*^6wyii(BbnJ|0JiyvJbG=%?|n2y}J3kG3ML;f6J*9 zB$Fxl?OILXRFv-X=$L)uwVD(PC<37R$cPAW2gVsQ-LYP9)gfw;i4Nv@;y*$Rg3*h% zn$f54nk;}9`(ibRtNXiYLyl0_%XCrGP<39&@A{e>_Ro1C9!gMHJs#68!aNRy#`leD z1OuKNkLi*!8~-@$!QwD~RrK6}q6|AD-%zR#GhaYyFeh_TM}MR;i;J_-I0ZA>Fm{$8h& zx)W3fB<+9$=vPZw`Nrn#y7jB$Wh>N&Av&0Lq|8*>)rqy*?I!2!FSPZ-Gl}H#wF$F@ zpt5|mh@Bw&0F~4YBY1KFr|p0yi<85qJcft@C?fhLgQxKZ!IKB@mXh2S=BvEfIX!H1 za+QeL)2CjWecq*4NbBYiB&YWxRDE%)0wb}4x@vObS&jL)*5`vkp5E>JVCD{6E=uqi8hweNd zl})wpto@d#)eonk4E5jN%=X$y`SP9>ppf$dD z^Ide&lPVkE{ct035-)NhXWR=*BZcScGxX*da1SnW&8zwTvhj*s*rO&m?3W&I5wcTS zw}x^LX=EZbm-@BcmvJvh_AB8aU_SpF7;XIt{#oeCKiLHHpKckdsmOAPCs({A2jsm` z|7o;Y{U4XDyJS$2>uTKz$yZcj6PI1<2K2ZYCu&(z4FFv3`=%dj8+^dN!Fx`3M;2|p ziyVC5xL}6i7?Y*(wyWakpxp#-Ciph@j53S*ai=s+w;doL&FerRjBITqBXZk*O%^#j zmlX!bMbV@-+f2!xLHA?Rd%@T@6Rs`Z z3jGHRwj>hostuHLu^{HRxr^^3@wl$s@33>mB^nJ$hk2lQb_-_TuQdhP`7ZBu%Y+3_ zo^;pRuVd)Mpvg|Vk^yDA-^=ECPk}S|o*NZtN9STelo<9+umW_@it?{DwV%Vt(Seki z5@1P)EhTptT?>CZ+>^3r>V0^{#$O)6mqYsW_{5UQWiEZD|c1tQyx;Ytchz7T@hgu`_ym$i=OeZ2pa;1F zIOa{@hk1sbKNNT}t-{|$CFbdsD_+-Z;&KzznzripOFvsf7uGs`%HO|p177;tz+dI( z7#eY4RF*eic;$cOTa&&SupGn9eZ#q?Q5?)v;;hZXaT1Ejw?Q%Uz5-fElkogSQj2b; zrZA)~4YFUN$5y8nrlx@T&J!4oKk(Kqj0{fz0>>AL^AJ3=`$sg|dLt}<4Z|--=flKX z9276QeC%c%kl^+4cy2b`#N#7PM;k#zdxyL)9IpIz3A`bl7e7A_qS+<+bc?n4Z@Z2R z*ks*xn|GCQU(tgid?eUJ8(pUKzAw!f%0U7i58PQ-rD7f~+D8CIJzSm#+Y%EjRw&wQ z?#s`_-Z#=lPrSVp(N3`r4_A4UEP8M33Oqiyg{zgxMM95fx-z6-4(`++(P0YJNN4M< zgd{C49>DRBD+Q11oii_TzNaf1z>-vHzKt4;K(D zmZZ>>b0^^<%w^-TpA5t~S7X+$DQPD}r?PIC*r^sw5?v{9v60*XDQdM6#%^VAK93*T zuy(3jd`Nlqxba3={5m!Lq#eU$rtjGuJgXd`CYisz(}J$DFqV48myYtq|LS-RfK{~0620m^07b5V#J5DZN^K16#WE%nM*zT<&R%I|!eCR;dD&ZOn!!(51->NKzHuXogqHU>F;995Nhnh4UT4ZEbX(BqC zD`EBFtv_N4izPCc`;MfJx2xzXK$7acRvX1dma|QoKe-ccW-YlNy0dK`HIlx<3$t2#-Ts>FvM0|YH?~;-${?SV*9YLKG z#0~!C+O#QhHX-#0dvy7*zgQA&w}o#y;Gt)(ns5!N&)D(bKj?pNve28Pop%Sow|=-i zlmtWhU*DRQBpYD&A6RXftG7E92(xOfZfpYi^W2fGDBG{yJIQ7iaD3u1N?dy|$~~MA zs3hNa+#_e|dQO0N-+8*r>f#LhPas`MK;>imILqhOX6W8pFO|$r`eCF11)uSMPm4!0v`YHkwp2Zd4;6k#R(a~ zy?6ehXZ%DpG7cE5sbW0nEx^*tIuBo_)fx#gi=-}7@pf78;lHQ2t@-iu$N`*#60q>y z^Mad%0g$_pNWDC_11ZR~>+Y%u-xQb=)*E7kO(-olrUqo98tXYAL=5i;n9BP0UV z0-nUy5%1^S=?SB(XSg?LrYhtoH~m*hhvm_}7y$0~>}yl@PA>AbSTo6Bxm~(=Fatg> zL_e8YVu^boGE9M8riiExFt=npZ?_r6@Vg-u*+ELT%5)mwKlNMq&iKI)rwlS(6!y$R z>BIMQ=@Bj29RPSOT85%yCKwKFTfbaXqSna%bRZQ-oNEKjc(#jnmrP^VUbt{Vi#S4wWj94cK-2L~qy;vuyS)Ug_V>fB&)IxgmU;I0N^L z63&d*gIAXI@wd{vBm#$<42AU8Dk9G-0-cu{Ju&3mTYX2sNHuesY_7UiTdNqFZPwlO;+x3?A>UXKHJe|^+nUvQf#2HyPU zgyF>R2Vi7<(mf)=;qA91DpzFNd0M{=>@H^&s9*qU>W?v4Nm)T@=Sh5o*j4_J)MRnJkGzrNSt6WqxZz?EC#H` z4lXY)gCz$`+WjpaLR+oos-HR(z8^8X%MxpFvPW+x$BZM^6Y7aIWLj#_<_AP4qOOBq zjKm8E<6wyO6M}lKC+lZoo~TdXR^_hF*pW}SO&lj`x9_GW!&kEne+-&`MiaUpY8;Pa ziQ#Mo{SDxY70?RIq2w@ij*^|5IZjq*RyE!1@#7}JJc}DSC7S+i9)Ot_ub=mmyT)DEf?Y`cs7DpKqrB(EnG>AP9o8+NBq7Y zSan;p4*g_CcptGhV*WKt3-vMSA<`q!DXOMKeoopNUOkhzcWNCTK~FFg0Suj(F=v6G zV3`f%+yE1*{Fg}>gBGr~gmRg}^(Sz#rS$l9MOuvq4pa4>7LN}s z)hicmhxR?h7IPyQ35G56Y4$gp7Yzo|pW2wq1&DzKOLr@YmBjp$J$g-?0z#yhv82d+ zg-)YqHyD+K;SVJcXVzDU24bN_o5R-NI8K8^E ziE&7v+S`GW=FIyPygIZ9O-@X6HM9LR(N7tCeQuKV>hu+6@BAMKto z%yIcDCFH*MvUb<5nWAfBBK1cZDX12s+;Q&9>j{=ru`A)1icmNkdP^h&b@G;ZHe;Ch z1qzfPuj4Mj?k?&myYf4&Hgk3zM`6Q39cVlKZI5(@i0BziPNb!pC15 zor^}+FmxINS$qMh^mqeCP`BR;0_Bhb-T(R7BqgqOzt0wF=ySj#uY>PO*`~hldk%Pd zMygw`FXVh411xY#;JaAdkNJ7-EqCE;^n2Z!i6n>$_RimfvAQ3fy%zmxS~0Rnh8>k| zOkaWXnhhxd4(6%!Dx6#ekO3}(o2))k$}kb>Z6CarIyCF3jmi?&Ze6Iz^Oh#Qo`%rmC9}*M*s?(aBj+W^wOg zXLuRRvmMm+A{v(=IUIFHeknPik?S_Tpx)NUnTqxB6aVz zN#j|>yDxDv5h!tuGUGI5p{j00>?|CniNsf4fSyh3j5mEUTxkoh{n;wl;Op1<+~bi) zC9n~zIIvO37{oA%T%Bjb1-{M@%Qm9>?1g9VlT$025|`iqvQJ}(&kz(iQXO>_v3XFT zwY*RugP1;vbM&C<@)oOZ@S8Q%#(YqOEAcZr; zKbPQnKV!iMh7c#-mre(Bh~ZX8-r<|HWPY+bNNhMo&DyoXh)Q*WX4I`BWT2m$RSwQ}n5 zL#Si~XX*8&*u9r(swdQoO03Qd##upZ58q!S_!->G%&@tIMv>5(3hW^lCJ@ew#(`*| zRY*WacuqfFZv=h>DMduu4UOn1G%~iXG#fO#cnIerDAM+?l~X~GQu=10@L?X5Kj^4Z z<2%??NK-DbsrDkJ8s?=2+#92y<8rNhNw(1vbgn2;%byw@l3UMVYd80ljX{IMHmh6r z@l*g*4#Un(5HDRjl+17OV+6t*)gX>>|(wF0$ zJ*fW*a4uTo{TBx6-5>Vy!5#QGa;CAb+|$bOM8ptI-TweRI%fG zUQp7>N@hcB*Hzk6glV!4Jg&0VIc_A-AfZ2v-~NTU19PGtgDH`*j4Tl4)8B?gj$&0c zTnBtSN=Z4Uk33abIuhA5Bk3zBF=)^}9iGY{0ZJ#Y#QNU%uiGvl04GXLg!HQ9UoY<* zn|ecp*}H$Cx<^InNL?aPwFdZ^S8ae4*oE8T9Wnd7^Eaz>8#qCRGI$UtGv9Q(>lOPM zSU@)^W?eFN_1C00ATA@a=pj9e-IJZE=$L!0qPAN!#DB63(9g_-ivOcbLnz82WHe+Hx^GP@ zduAu#ls=q3k^uqngfz`65Th(pr}~?=x};}&dI4J!s-&>&kXLVA?}zBT_H$%kcO9n~=Z7nMb6Do1&>Dhc ztRm4HoSJ()BpIZNY_@;h*l{|(49cCL*}?`HLnblD3v9AbRQ3v2F7%9a%8GJeWhgYe zYV5L>FJY2x0Hm>O`#2+2s}ws3nipm#S7v&TX0}`0m|N>yQB{Fc9)6Kt5ef-$*hDUw zZo-^VW~DMVj@49aSjc>JH?rg|#{a8!7U8kO?UZj#MnB71$LCD6Sv-_#f0&!Ut!No2 zMJJ@_GH&!NC5g=e(~6VT$#}|5WpFODOhx36suW{2@Py#@V6DxMPSphXL4Im@EizI+ zUAnBOx%A^xFc1cy+qS?3U;2Xf`v{rye=+p zLyA>H71&v%@vOk0uuHR3nO8n3qx)_lsHtal;9k=+UXwx~@3x|VM`swgQ$sPr5g**b zq}DUzNy9uagnRW;cyK)OD_zjGFtAokyF>CsQh@^2->3915D;h2BK9j*7uLA{0(cQ`ScI5FP@OcJqAmh%LSPQTpRMc*@0kL2cPfdDTQb)!bdR8R-RgnTdbHU{sj}zX%Q*{QE109Rmv@uR#Xi|M{AD+@yW9di zzN#5okG57dJfQ-rtGt8T3-skj8Ug!5$)vz@g@|NEdqj`kBae6z_1Z+gm596M#VMJn zsj#Zg)kz+(fjXh?)xjhRu>cypY+~6l-eF)7E5Do z1KEzNpg{Q5AZ%BMqVkZJXB)s1(1lyF=Na2?N-pG*BSm380+ zI+ZOHBf4Lg3AN_duGR^t3NL{r=Obv<4|yl-9XO|nc>2Rv0Hbm5PwTH51^w6i*!S|{2{}{qQ2)jLsHWBn zQcpv|=LB$SRA{Z4aO?Pp#>OB|u*3Y({RvO{UnOlX(#s(Slj?grVcftu3}S9m=9vRa z7Q^$6ihr3rNW`2x0RJN&0ne7s6QCb23AwLG6R$AAhWJOXW5$r|1p4UBAjEL@<@~T$ zA$2rvF%RVz%rklpjqZqT9zd`@?+2RAt@Yb75gK7n%_XvUMb#A_L`kD%2cKLWy53i! zygWgGHiQNp@)t65>BaI}%g3g9={$(MPOggh3vjkpU^#da>2nr2@^KCL#_Q5!c_tC- z^UEI@XEu+It3Y#=^0@qsTcc_VuNQq@&&Ot)$>uk)#LGD&zkB_Lv-fN++wyj^j80PULEgU8$26G1RMAJk9%S{lx3P?2MUR1i!OJ~CysW;zsBawpc(QWj>Hwb^;5cY#vQ#(~rcjCdN8Ku%D`6t@VEimTStbOQ zA$=p>;Ny+X=66=Vri-%8>#NE~0i0rq`1yi=Q;u?P-cb7p24-k6MX>;?Jk#oMNPadu4C0l0GhI}i5_!;K`2_L=6C`E z3c*d)zprqDN2(rNf4Er7NNZroUe6C@53pwACLfF}vIH%+XOhh2>dp0x{Uf6i)65^= z5;%M*=A2L7F}Sr{}w&J!tngIve=Xk zILMf{G`;NVLI9zd7JX#`dER1j)>f3HV=xP-cA>#3JuE%HkEQK*0@sEi?kAr1QUrl3 zN$&PC$@)Zq3<0^hdjywUwC}>Xa{RIDE-ieG#$c)m4|;dk0dx)E>xcgAcpgq3?V4+= zXoiMYNG(EnfV0}`d^( z-+!o01G4(x*ERe|RO0no;I!IKv4V48)!<&MqJ2T%O{@lK9;`13r!i4E-+tbmXq9O9 zwr07~sB`}M!-}*s5S&fm2aPAJQlL`>7-CD^@S!1t=_dQBlj&Ewsx223L$vyt5%ZXM z?A!_5T!HSj?>**2Isws;-_q>=R#S^z&i9gR60G z^;bq&SN)>B&7-zP+n)l^gcHL&>4I82;#Pnu1G7lsz;FtKqN~sAw7lt#RFOVf^o8ff zl2Te=J|vP^+6}*9XK8ESH@856G;Fc8v`zELE>YOHg%9N(Yd4!69~n&^vIsj?+hNzvBf3A@(kO`%s1ctW&#Mm$8KEeV-U>Y%ggW zc)U`jkAa~`k#&WAoO(`Z658RvZG#p2r3&^Okmw1qK(&dBcE6Vk4^(si$ZCXzeIqSm zc7`HQiN8&YdXsAvPs_m$KdeiZ$%c0M9s1gzhjLgnbFoWRN4FjG4ePWq( z7^y%?oRH)&6-BvZTriI#IwpDhLrf}7tp#qVMePZ~;x+iE1awp!XW_nu7=6C02s9_s zpQMs1ipnOAwvXIz(s>iV^-}A=HT6omS&+jycW9?FdHVP@A#NvLZGT-pOIIyv;XhJ@ zH|2P2>dO(~uZ}wjrdUmpAgJZn84EpuHMJ{B^e8$WK&@ImXfVMk3cCRgk2RLq@Z|&M z^g`I-eOM)T6$8}zpOnsaG>(Pbp>m6pA`UZ{fZd=E5bdN_?E_LCTq!uJ_}RSP3+4bU zlq&&ga{4Gv^mJC!14rL0pR_Va7xx+BQ)ckSh87`F_HQ9Q(H|vdQs?fy#XMFg1>PFn z@==nJr$_zgpPgfk3=7G>>GaYNDqWK@FM<`?fkY~sJLKl+-56O08LW z67w)*4>aK@QFS1PQA7)G168Go>&GZA=m(VitwxAQsJn2!@Xe)ug#(ZaQG!}WslZ}d zW;-!P>8o})`30n#umXhp?kg&_rw`uYCg?oTY-mo3^7+QO(me+=2`sXSo~GecVHkjY zcFHkF1QXEMrrLhp?MDmx-vXJ4k=Z=)WiW4r39^L?Y8Vk785ug=+)Qlf zXS%$6LL{;@lJ>>0GLJ9aA9~Y3^6h5*#RUcVm)8Y8UE0U1dgNvVoFx-z67J6*yx|;2 z#k6(89g2waYYc**gsq`RQSEwCcrFxR)Y&rp$gA(ny@ENC$1ncXJ1EX5@~Jf0&v;e8 zu!RuMit0{CP443Gh%SYIc$_Y-%hiIlx{UE z-qt+bNU<)TVhZjM*84Y2yv+Cxd6Dui%k5^MFT&=Tp+4bzumJeVO_Din^J-IR6xJN? z<|^K3&}FNyS2e323cn@Du3j8@Af;aYGe#f|6!uwsT6gXzBB&NC?3FYJX1)-}!-C8u zv>CmO&O7@XU83=^h(_DPSTjY9joiPB)=T+ozL(40T0q!O8gh8K67-1^z(4Eb2mE1O zM%R5DfLxGntcG^;NvC)C;T9I*qHM(%i1@AUtuv6tDPWBK+!xQEs^QIQYMqUD{oL3h zoi}YVa0=&GKTm7jyWNURiG)04PndGZ{4QtbH3pDpYMb5a|G9OJXAx}B)t?s5=Syqo zAW#6lTzGi=NAsF7%4PeP6H0bWRsaJ!PrifbSRgM{#}LXlI-2;i_%g5o@je}Iq)>?x z;R&3kC`F{ewmy40&uh_gbdJ|HH;PS(r8ehCjO23_aOu^0NW~M9{D8@$uhD&d5t{uo~3=Jw&FlLPW4M!v%$L=RO~L{&ke7nE9+oVVlYG zQYc8DDb+)l$+Qgb7#f9CT8zi}owvEnpzcUoz}Bwx?S9NyNdJP5HfouCk*wjkT58q@ z@#i4jk9ck-M&c|~F201!9WfycxznP@S|J)*d#kR$T`b1BfrgYYf)k={X;Z;L>K~=@SX^~!jrfOx#UOx$uC>J)7&3+$KM@GK! z8LBant=Vv}cyZg3Vb#awS}RBrk?R-az-VGNMT$&d*`Gn-Fl9yHH)RwpbSE!FAeu4M zY;6EiGVQd+yO+C8Jn{>z_x1Vjs!Waxm=SkwO;bZiV9gsBg&G&mEVV>iXE6q4ME;Br z8dQ<`cnszHxb1?rb zzrN?Xi}6u2z`;7n)Rb76&^CtmKCOr+6<#7asMLpSkkl6aROpD-fDE=~{6s-&0}ytg zoy!vGOnOA#h|AZF8~a+9xo6K-r2DgB45JJMOz9304#~|D(-w93g&X`5YsDM*OY-m{ z9BU%;umVg8ccAM@gU#vf-Ekb49TkkBVbK6=53O&MPSmj(4SV~94S^Pqt*@pBl?tq) z=3n={%QJ}e9rgq4SplL3d-V=|VZc`jsKmR}XY35eRO@TZxWIJSy{6#zH+ro4Z#?4P z)+ygVZD!l6;p-19BHehE=BU56W|YUHMEh7P1f#;+PCaq6lO|a67%MCaX{tX#S5v)h z%(g&Df;Drv)C4cfryywOCZf&K2h1g?4UZWT#?txI?cpxBR=)!=HH-LtrtRpH?V;)1 z@!LPk?e8!aj)0v@-X8-8v~H8;d%GKWR{iAHH0RSeX}I9Bk*1HRPy`P1VG!05e4uk_D{x5#E9*lp)lWr%3grE@ zm<)Mf7*1o+vk?ElF3^YAzLsq^ifFUo5v@tuVdbI4muIK$d$zB7fEARDko3dWzl^`! zd)giqp}tl2AFaN*n4sCRK>rT?oJcM8G=KU<#QSc-yLyc_aQoXG`HfKE5uB`Mcf3z^ z5;#2(3-rbtoEhy)-~s%G?JE)m}!APJ{nk|&?QbzEbD*BVI;K%&{^ zTg^{Q9X8Uu9|tN8l223ifM|%(IOOqK-ETxnQ--{&5F~U}nr&(VXvzqCQIgoi>Q~o& zyDLtwb!&L4#|Wo{6WGVNNnRdSh4-&@W=rr%j^>IU{~$6?OV|XSudn1%cy3cCLyW|Mc1%=K_&v7t4N*3M*6U+S z%<+%Ey;d8BB=1KxMQbZNZjJ?ax0tW-ZNY2iBB*jHitCPYxa;*%F9}HS^fI#W_!so1 z!aaTEM`G(IH;isKeCNjoE$TaVP*v`@c#yn2Ni2tLHC-SwzuI^w2LgH=mk``8QeoEn zErKkRwN+PBpxrpzdmJmvt&?p@>kBqhk0+DwlCcN=CA8QU=BnRDF%{!nNi>O9H+bc9 z9}<$946nJBs9Cw5rd*4jYLsg8=@ugd7GnFJGiZildC?Wut)QwT$Jg1EsSYe??DE0N zsZRKsGmz3>gC_L}3|e=eL~bgBY7g_ULU3isof%`DO8xeCc^aHbF+sI_7dh~HBkLOQ z<&%$?O-6BWoj3<+OKOwmi z8}q3=q|uevYd{nz8w@M_%_esMs6wOXj%=qzyGLHf^@`c@vL7_(WZFTbzm?+&3@+@C zVpf*=zdz0cxFhiHMg7e1NhTLyRfH#w4}rXmIs$)j+krgGB}?^Z8LGn|qNMe$w!S zEm{ymw50*wDqts5T#ZX!41h6W&~Rs>K6-XGX{qH^Xxk!mL31@m1E z$r2V$ETzz$gBy{ZrE9LT(@7Q)g{?FZbMZ$$M$=*waP+fN0QiXpM=tP`)}h+qc@!zE z+9tqZ5^z3|4?T7Z8MiDTCm3eMF5=TN1GNQ+e&CK~kv(S9z;&6^v6=MYFot3!T5E(^ zm8-&(u`uTL`EbS~=a0_2SIWa`GgWEd95zVXuKc`UBHRZ9{?AkWMw+iIa~;^chBR85 z&_H$yQ)sC`{5UysJ?vok7@i!8F|KRdDoOUt?pKoG)h=a(S0_@~2~Wo;6E5Hu&1(sC zcy9Y5hmD1p`{!ofGEJcLAi}qpa!XjVBO_fB7za&U{#d34b*26l+G-)hPkc+IrJ*I5 z($`eTxYT99Whgj8U;`^6J#Pdvn)buJMNR@N#@M0_ekH{-lL4E`-}Lqi{&RRgCdFZD zj}(!3*hdiT=|(AXZ8Qo`{7JL577)ib(3%S=cZ_Y_^@tJREY-Lra1&(aQMJN))mOOjz|MPjytMlT#g_&RM*}2xbz8B17@Fwo!38~*! z*XOyB_0);Ejxt$DvcvYoi~o#e=IzsKT)yqJ?{PMee1QZbozdz6?**2DpN9EY8%6)g zJ(C8SMDT&;lYwyHG{+x!m@00M`nko7!?(mWHof>+sase4)4EpNv%^+J-tHd)KBZeK zrg%4r=1E9tFk4%2lx{mZ3Bwd`_g??S!(~Im<73(sugr`Q-*Khx@-T;l)zpcd_9|bg zO~AA_0Y$fTQCPCn3#dRHGfe zONSO=5LESx$l+eP*@F5nB$Jexm}7STXGt<7jDF-Lbor9gOo&u?p>zhhpLPndi4nSK zPiftP;aQ>2R9?JG2zT5$?r9Gh{Srr%-Ofip<%APMfEf`uQIb)A&6~BMX$wYmD5qO$ zjL|#Q^7dhA684MrysmISJ`p!m)8Aa0`yM8w-ka)?JA=o%080(C*nzX6NO@@#m)vGL zFc}P~^nf5pr*{wf{q{8&T`>@rd)`N{b5jK>yg2^Q=z4ev-MPS_$QHdIt|a9AyT}iV zx|X#M|25WYB)OF7)Gc+v0+|a(4{9AcBgCTbPv_h&g8{0{`0Ti8I=i80Q#bP(Dk&@! zY4{AIRKd2%J+529`~8#Wp0W%&D#{@MTg!yc#t$Jtd*mMt43?9^R3F^PfXqxdV}{!n zoaoESXCju*91{}O$#celSH)x%^6EY=*w-0H-{Mi`(GS-*y^+c2mZh2Sam+?&jD|7ysya{p#WlDuzdM`EGwp&J-s)?U8kcc={P4&Z^h% zHt&r|m(Biw#{*YR_no)4q|~vieC#ef`CFnFoLB&PS3Jfbj?Z}^F)1iT3GW*oH|cSk zdQ^TLqDGCJ*O@^C4k>c#-DH0YeXft_F(7`JX=K=)K9fU2!O}8$&wjU5TM6a4t`Qba zep^;PYns0I^OqRwV-x7@JM^Nzt@=Vu9Po#O_GOHDJq)6d-6h0+!WF!|Qu!ht5&7*z zs75DI*dPKvwW0ftTjLsrfi<$V1s?c0rnk0aU3u-1e;b8}Be8zE8td`g?$bwyUhb}- z&|=g?!V^;HxM3`R{mSgY^Kqg==WFNCJzION^ZxK>gzP#7y$_rQYLu)~Tr40JN&;Tt zCwFyK;zo+}#Eco=9g=i4r2tV&scthCdKKL$HMXA|oc{=fni)@m(n`ZjOA2EI-la?0 z6IAD*;#QSfkAoa`xTM=s362+FDr^S+JOqGxm6Cc;htiC5Vb#<=QbJ@WczaqpVQo7R zi*8K#Wy@Vr32XJiC9CK7uRt<2-E+?XI%!snq`#6CMh2H(mPW+9QQIKk`naSQs3mW5 zwF!5iNJ^7II;Jn67SY5L)g?ab-133mr*Cmf%E%y<;un+KVMA>KG?RPa`~-EQ|F~Yo zIbP^VC2_$aVSsBP5#r|%L_{bcF?b?qAR9z{q07A%oYx6ADq79T`?A)?GC{h!vT|n& zYo_8J84bdl_k)i;J9Wv4r`0~ExUX<1xOztd54Aq9DM4HtP6vivH)t$13W)wU}BfkN%xm==spQjgFGJ7(5I<;wy(Wfeb9)FF&vS zrkYdpjU#v@2ET=^Q@Q8F9j0UdG<SxZIw;9z_mhDb|5P)6PU!_n zt1t+pBj7gbtDwwgVSNXl$|=#nTl4NA(^YAX%Z+J^R5HD z2i~#6B0D9qK0mH|{_G_GsNm^$X#$%YP!m_?h%+Z_T@^&-18uy@JwKXJ41iney$(N__?(EEyd$6>X0=6BM z6x*k+M<8&nzOtLJH$n`R5VJBe|BZ6jl0LEh<@Zy4X#{RNGSNrx)WpRZh zGZo<-uiqS|ptMhT5ul!DGwB6Z1?68AgqZV9G9&#ON6W@w(FmWI8sTYQoU}3x#l%qkh?W+wQD1`&Z`8r(SecQEp&XT76jG*` zN(&d#1$~#Fhm*Gg5AvTNN2u~D5+N<5&?$|Uw!Pg9n6~v3FV>YV=VJ4opwP7gzN|0OXpDGZfHMY(7R+co4#*V zBz@>keM+Jb#vLqLy$@B&XCZok z!W(UWG1n?qP2{)$Ey`0I^q8Y+dhT`t4JwF4b=uE>nLJ#nAnU!#>xXI@VkDc-D$^rL zR7w)Ik;%)LB*ixG@IkE;M`R z?4ZKpRjD9exTWT^|4!w=-mxevr=C%0b7%%bwH#fUD9S zGW5Mh)O}+%+~9pG$b0L=<8U0x_HhX z!5t;oegi**yHYbhl3C+wy>PFRVh{iiL;V@GMm%X6fVwOgMWe_ElD)~^56=WI;aiCf zhSpxZ{(ZYGxRLT*?5#FLEih8*Xe9OpG1~yQQ6^jxvgtH%4vtp5Q)ML_f=KbxPPqWQ z+HA@{goc90c(zxe2}u$OR&6yxwM11JCgAyqzwLms8sWsWiOaEN&u9|uc19$u20o1g zcfkFSGCe8mKl`X8`l&+zGqT^$ottyKy7V`lSUfq-Q5b_7A|(0t?q<0zwT<3Bja70H zNjZwuWU>p|FA$tb^qRa^3MUgErH%XDA*VkmLfpfZ4n*pO{Od#Rz2AVto5f8YF;$78&|(-I<%Z*CK{E=A-4u#gv*F zn|IW(;*D0rLr%=3cjTjcbaCmwC4SDRF@b;KQkZl@{uRw`EEfiLr~2ME3T2Av)H6Se zoSpEhd%e%s3wcbxUbjbr>z!ip4whya6t8IM5K;n{(kL@&Cc^(#;e`cCj|m--El3BD z^$g{@YMTx~iUN5VGmO2z7>P;7q_J zQ(_tN4hV{i&rBwVpOxyy`X7@4?KGxFGuY=)z#b^P4CHIW@~rw}IJhvAcz^$D(7p1> z*nMR>selK2ZzZZg9at)+frJeNEuWeF?{g@no?&_41VUq^%Rh<#7fk_g+Y2cI2iEld z7wt@$W1VqXa6l#o-vx5AxGb7k-)x=(0WvJ1mQM4{j;FO;2*`nZ5n;(is|i+ zPvZGRZo|f4vTl&h^$rc)1Bs}905BWjf$64MS@o#8rzT5XPFWAZSO11ckD#ou4uOUQ zqwzm2`2W`}fRH!*2PUf??D_vcWaR&UzWT;d+8$&kfa3{f@1L-hs5xN2-j63sK@$tR z4@oogViu1rZU0`1npd>bqyEduRxc-DX#)O-05W(-zgiW)?RmXJfz=ZtZ7u;dyHdxH zdzq-u)q5tT)z_Q*(q__g`%|79Fnqo?H+X1W#w2ixy7L4+;Ua2J=>`1}sv;&ttXz@g zRo39eYgMTfT0U-o|;C(`#YY+e8L(!;wt%i=Pnt>H+z5WGBoTbJ<}%MP7Y#m6`6+grS%Z3~RU?=*nv?;9&gfU5 zO-d#QgsIm{qLUof;jr*YDgmv3#5UzU?dST3e_owHp{h{XGn{^7=q~ch(BpR7x56&NgAtnhk5|@!QWSxgSp~G1JK}1OFQQ zhr4T-IGL0|_?3o=jWg7j>1d`bNoY8|yR7;>n7nbI7vBOk52!B^}^+^_l@o&xVMR zKMQC(Tt+7chdC>jzXS6&^Y?|t?vArxQ<^T?++h3zzmnZDD9m3V3(O?R#UQe_F(aeA zhx+*iP+@0wT*8Pdty~OcU)2kX8vi%Y{KYd&382)Tru!;q{-6rtotJf_X38i6GG;HJHq7vlgvD(uRMQvN>SO9!bqB@4T1F=wvQ)Ti=4x-4-Q9m^NX1gWxqNE z4lIe5=D;#_#<)sJebFU^KbmIVs}|4_=GHI$vN1r zfSRz=>Ep+e|FmfFFcLTH+Al3KPAZG7b*1TZO zBn_XG$S@)J?7G04w!+-0O5bKs(n3ci^0EF#J!G>2yj*^K<>%j4q~R{emfe3TtG=Vl z2_9BhZOfewyNUVkmE#NrZkIdOf!7K@R<}JI#Ox&u;i6VAyb3dqPg0BZHh`zU zgf^J=BL53qkfN(#qg<5DJj@=0_+x?&kv@!MDLzY?R2iJeFtU&TD&tiUY;JXYQuZlN zK>QXv{q%}kgMZnBulExrNKe7Kf`)w8^|yoqWx6T5w8wj9-2oUr;elk4fqNENtVexV zu2f6JKYm5*^k!3dH2}EG|7ida2dWdl(5&S?n!~Hufz{+yv3c71>-|#Neo4sq7hbHhw)<8wJ7)$f5pTluJE!Xz|YDj zn`msJJ8~PJebU(0$$An3cIR2^A2EZ0DxX zu%gn_%_XTmo|*9X^BX#Z&<4lhhciGA`9pGZvv9YigK;OE(SfLt*(%DVyYa<)D+9WW zw5=D`$CH7k=YY{oA;9M#9uM6QUfMN&ouN%)nVt>5D#O;NHMBkZc&y#7{=oHR(GK2U zGb?fdbAHc?kL+{8?lxXuzVW8j4OngdA#^yfES$fOWLI+IHnmb*2K9$SdU489@53{R zf;nv76Jsiew&>8n9wMF@`xybvO=r5Sb5yn-U9zYQ!+&-&Q(#E4^ z-O;W^lV^HqT8m`YReELl+M3%S=8+F9mN=I=%jj3a&mXtzasK|Ow*eT8zOoH= zID7_4B`A)*!6%MPncr6%IdeP4$^A&pO*RhsM0o=#eqBp+;26F{EQ;~waKuwt4@>dd z+LHFfAh`yn5jlrj3hm<&gG%G%9cCxxb5wwM6s+?n(L)G6!WbbKo*aC(Cs4`e$+aee zKOKiHJY;N(xkRoSY+dnjWD5?G(C2K5>dagTP}Fvwmzk+WD1oNwdTXsfuUVa69Ol#A z;WL0!F<;n!LOBmgbNquYlCq{eK+1Kakb}1-I@0z6viP&R19(!MwP{$GGPRyZW4L`k zA@BV|d2`V3!10~-z4-{ zD7_9>#};D7ZoOgEBukanVwEloZyYwhgzlM@zZ*Y{E@suLEr_+sWdBE@{wpZjVORit z)sCS)L-ZM$j2mfB8y`u>MOtPgK+;U%_0+ zeC%{x)E)bY2h!>9I>kMQ49k{kOy9UXd34sIM~zXx#fAREx%le#ldw_!!KB!)tlP!x zVBy<;4J)%&U@UMYVBdXYfy>NHQcJq^2ppu&TCEdTqKMh%tO)SLWFGWt@{;z?rtUG5 z{MQOz^*Mz3Fpb!yzn1!V_U8v6IuJLrs=fBuqxIC*sd)h-(%|vYV8vHjs-?Z>txGbz@f{~tkZdOafjPC(|h5@UK zvGrj*7Tm_FF;XH+VAu4>7Neu-Vp}`PYAmzNm^$lEOD_`681Q3i0PW)3K5v4tcV3%Q zM^+{6{t|4xBWPnCkXpx_*)Y#Bp)z6g!aJmxcU#sSA6++v1{KIM$tP8jIX{{6VfoHi zB-u|wzmf3aeIu)4qu1kkK{KkFJHK~&y|oc!nlAjz_+D|<7CcG)`S?Rh+iy>mC^hGng8k!lr>6xBYt9)m?1HpAhd*}ZLaLyamy`LUa+{vSoc z`pAT|*cbDKs6qC`niRk`aNh{q=`^}o%(x4*JSpvabA*rY_sCw)RHNCYKO?;!Mj$%f ziw8TLNLxkOtHgQi&Tnq(>4I7#6dw-eopAtR1jW~RE>gQ947_doVUw+<%)-wUE*|)ZO7QE&8|8RJ2Lq@zqg?_5OKrpgxYP(eUEUb9|aqnXiN;t#MZ0*s5X z31cJ)S8|;S)k7(()}K~Q#QT9@q*K&ieW^6@;`SX-3?Lf&Yzh!H0HwkrhB6%%iOgPL z91|>dVVi&9(**c98r}d*5;iNhPw7$kPU@bt(pO0)=((IvPTI+7hxQ0j8d2j^g8IA-T=C2`01zoxKy-t;q z8~qn$IitFwl;GZsYrm3swE@qyC{|PUI2KFUZ6ZL}c8_zdd7L z^opFxNJq_G9WGlkfQ4twMnaA>tZn(W>3+qhx4s)jO4&f^;PYSe1p{vOqPxH4gIZnQ zsxHI^xArjmx5W-!a?t?`V-77cCTX63(EVGNBC8l;HmUh@eO<6DMKgqgKHaEC6qVs$ zk?eQAN*)C(X$RXLC5o;=6~TX+u&&|Pmb{o|`CJhRgUf+HRGT?nl0>0ox8ObBRfpgi zw|60}@nvGhe;v0$8hI)tH0&kkCBb3Vdn&Us8&;*qC7M)lSdB6V#vcA>FYEUSi0x<-pNpBZ~2>F?E3E zfxReI+@3rFz(rZ{EC`g!En;532>>VjNeRCNFppamA>T~3g=~3uhTknhFzCooYrTFk%K;JoZi)5~^3_h@G5*^uJhA5E-shXNpR+{j~X0E+&AUpHULdtM@ z`y@QuxDw2j9k+~$Py%-2)!?<%Cn=drC7-~l2-ZhSkB750=WU6x#M}ty#I|fW!D$wD zvOq)dMbjXGHIzifkkh3o>sP;BW$z|pUMO`piN!~o*AH0wY(G_3Ns5bm8oW!O(j&)H z_f2z{9)p}*Qn*ttnVh}*w+1>j_<##VKy`!95Y<3*|(;R&Nkt; z<1NNa{A)4>IN0v=7U@i}KkajR%mMU8t^)v%WFsn)u>2~08sRG*u@bxS)PQLu{(C(5 zE%JUsIaq6*sBvFp+X>X<;RP4xGfgt}{UTn9tFJsBvC^?Zn%9QEw+kS(xPoEQ!uo!c zmf@N=0~FQI$1U44p=H6Wcf%or5Er-?VAbYxv-dB^#Lk!}j~|muUV#?`kJ$3tGiS{C z5FBX1@NsGi6;^upE=6Eh5vziB!{UP+wH&}qsp+(VeebQ|tOSqkloagfbpLF1*Z1*B z7i>V<_&RqHqTA^Ef~03uM5m z(&zUpz!tRgNuYNuW~ka*0Am>ghw`TANJO*rSFrMF821gf-keC=`PU&yNZHmS6Nlnm z&p%NazEMu`w=)3e7iKXHkmV#>qp1PYaeY;4+K@Q8i=A+@PoY7&; z#G(qf%`I)T#8&aF#n9s=0oCK0up{^Llf=5r95C%UgfD&4*l8A3VHsUBB|S3b!)O_M zf%@%&Ilc7TyFFGRRz2dA8eq4lET;b1P^DP3GVNgn^E_nw|)l3Da`WB5rg934- zlIKlhkTK0K*6*#-Aw2IF-Ws_5sDw4xpEM(6%%p_SGMCBKx}28{QyC1QIK72*|LxHf0P}SDmIR z@B_BqiIVcw^u(+?<#ELHESJTj^S0GMqtF6f;uRtSg79zfC=8y@2bzx{l}{lXfjfz3s`9B6;n%%^IX@}YY@S{nb6wzfe^Nr{fTof?3=_i zFrLV%7XJsBf}Op~KEJRip6cQj`)`?aBp-twfy0O6G^=2SsEy-cnyFVUF8&)M1$B-IryFaA&=iOG3MHVF|Z{q{uU!-txLghzyCrn zd)i$|V7uX;%czLzkNpg@8H`x1E2+Daj>=^?VnL!-vn7tDhK(;kjD@G|iA+`(xeD0-7-^6pXxQeWv zwzBM}G2KW<>%2f{2K;V3nS4JCBy+c}r{nu=8y7bcuUbMMVFt$M%v>JdlDU+aPEJhi z=wU3!8}_pF!+$5&xFuh{dJ^KYMBR^@4#n3TyFFok`ZLs$D><2G zP{_kw*ZX;J5<9`tX1ynXm6hYzS=sDedDu1YH?6`h}Gp1 znXQX4Ep7krY>CHDt20+0EA9uvNQh?SMyz-9uBAJ8O96rRISHpK1EiqX$xo+jMf~wQ77g_3}w&l-*kdFa1)uT1sr`60D{RUu5xa z5P5S9kUe_9OU8`DUZgiT#WG-G_qgB+p}^0up4v=h0#rJ!3uItl(R@;J?B;%enOm~0 zJdpMwUI*_sP#&P5jZO@@t)Hj&8^%-cj4`CET=jEMaKPO5{NV<|)$k$yHlXbP=HGQE zjJA1LvihJp*l#@zb5_LX4yngAJ`>NV{W!?A{-G?F1QJ*0&9`toze0XqrQzQ4@ zeX@tsKz3d|cJ%)D0^?-CxjT-@9cB{C2`f0m*A%Pj*}py>bjEQTC5roZ`0{11HNVsE z3h=yWSN92@Cd%FrR=+ggH>M5y5?UYfR?xzra}<2z0}Uq>E-C_TPc-FS5|1h{d>f;`z0C zlCP9>qwW*`O*BK}Tjy(c7$b$J-tSlJU zF_&b+J6b_Hpxii+2`SAHFUYFdU)!SwM9Z#Ho{kY0-~WK?sTGqA0h%OQM-Gs2@(sjf@ls0@?QG1=30Nc+v=)Xztu(6S&w!J|Vl9Bl^1qxWhJqvV zURDulHO;9~)$T-oNH$uJ7MR61-r9wuvBE(yVvQxfWl;IqWD%nejzvl`!pN7?oLR~P zYwEOSClh9{g%XConi)4Pj?u!!eu`IW%n!PS%@{L;)~~I}rEj_u8Vw2hsCC?pQOPK; z&-qUlHAkOkaxQGXM4o1v1)Ion(2ns}y9^~+(Vu!%7?g9*vlaO&NP>~!$dA^!>yMFG6B%Qdq8iY;&>9()=Nic&E}vDDCAIBNgfI*7d=I3xi6 z(@jwOYvi|obDzXHV8MImVj>o;QYT{ggSq;KNWL1m>OR4&A!>3*Nr|&9p zhw`sun=|HhSH8i!fuqALc;YaT*9?W6&?AuPrl;e9oQ^99eCm{7k#H2=47P z`ULoPQF7|xfw)SXVaIqMRk$O=f2S2X(J<4|mHK7O!x=_i?7OVQ*sOPKd5EiSe!2M~ z-ieZ=aAE)=G}Xl@Z_<@RX0C~3oZCX1?;2o$URGGF99{{RC*B%b>~;KmBkO5yi20Sv zb1T1yx>GI`C30I3$QJ->AqZ4;7GI00#bVg%uWI8?+k5(3PfuW7NAWUfbmG@50+dmTg&k;B4=a`L+_;7AVR zHQN%Uzlz|G24?DQs^HmCDg`# zfRa>9;jzhYFyTns9rG{F*9uFx z&2uB}>G185|3BC&ohD5MRCnPgr`BWr{=sU~VhjPoBeLg_Gu(r+oJy#;>F&VEc`mp; zTP87_rzpm>%djEtX5{hCN)y!(Q!I90vE>$BI&}eAgxK~g%k`zbJ-bT`h#Gi(YEq?t z0Ll5Ds8HSWc3veFd!k4&?L#JlY%D%}T@Ry3N0f9qEsPh{)O7e45Wd)CBq(mdhNP>& zKS#TD>$CoUfhLYFDNu6T(*>s$-#O2$#J7Js@|2n@F^wMd(Di_vH+jwD%{FWkiMVf^Qr@&#z<6BA%!II~pe!X(>+N$Lc{!nENgf z2uZZTYdP7`?;&Jsp;{2#OlId^zCOm6RXV2r4#;Z2V~P6Blnl+`&NT3eS7v%$z9?Ax zE;Q=P#Ros6pl_PM@4cT{>xJlLpurMiTnF%DzKm+=D)YUz&rg`IlnBY(EHzAA5SLOB z$Y-D=T*B#9GIQA&qMfZ;e(*t^e?5J&ks z`n=j~7>(jDMcAXl`@^N0WSQO%nq^O?z1&8;>m#j&Po_ zn;3>4NsXpOSWX-P7i`IgwM7`2NFv1coRw{yN7SI8v#s|MbUynn-j63!xyJOFd=6jz z;TYI~idQ_pF>Fg3zq}?!l&j;ES;C*Z<3*&gGKtrq?2uSS7lxsp?qrb7091+1Uvp;{>j_ zV_zz^?TG?e$scn|yV^}aVqa4>yBVUS$E zKn!yLa^2TXScz2EoR$)ODi;pSB;G=I4=%Q?9s3ZpxQ>&%oUbZXo-`fNyaLKe5C{Ok z6oK%o`EiyxQ5etj4!4o2ET&Q15*KL}@BUj|g+;IuFfv?9M!^AycQm zQ<#7<{q5Dm^=urH6ss*x(GNH!M)TM4qFmqaxPnY4&rmAa=1)e9zeT^%!&>zQ2>!j! zNaPg)83L1+$~)WxZw%y2cDNy^>5pV4zu%BBv@jYXtWQ0uWPVGwQ(}ftbqqJY|PfS3@s@F{l{Bl@@mmf}O%jF7xz+!;SEs`^Du_7ms zBJ4DAi6b-F^@RSz3eK8D6MwQZbyo#QBcqyIi1SzJjElW@Zj`AD)@Go%he9XzdDxEO zyr>D$Cmzy{7n%G81IqQ(3=8~OC~$H6^Luv}f(i(z&*L(9g}^1KP687t{a;@q0?Hqt z_I;>X!A9OUOGQ(Pw;+gf)dd9fNKeOyQ8YZu8X4mCDON>Lw|ib|L-)HB+xSk97CA!) ztl-!)h;K1$Top9R1L+({&1D+!i`$&pEzs~;xZ)9>i-~QeXYT*^!7oPbA1VFa<8eWB zV}+SPei02zB{>O>`)`C|Eo(joF^H;4AUXQp*5%F~RO@TkS;9bnqM5w*4E^>eWAQrD z^eVkvEMU;#WE1EHBeHb4{zmD1ddM8-b2I=S2CpxQdw){I;U_;+uB{65E7RJOA$#iz0{*;KS|ARmxNhH8m0mvg(~qmZ}v<&in?mv1QQxe_3+| zg>KD|U`EpwcvZgqd+{hKl;j?@0pVrdRXE5zdd-GwUNd=6%f>p4<K`>Va{Y%zIP;Br?&MU{W`vC8-}{xLWbA`h`six+{7>y(=}oV!*OlPcLuf zPM5n1IJc?!ba#oIxQ1`9jN`v*@_(HFq=gjXJpCfb|L^L~s<~96NzPJf)XuNg?=8&2E-0>=dl-x{#4lew zR_Z{-%nOz4-%jtrsEwXLOo3nE!$uf0P>FwBeJl4+bRWDl0Rw{>`R4t=?k28BL}yjN z>l!hkSb!q4V1cU2IG0lbwgyLkz_?MP0$>0t)I?my@lPk79t`=om!yWv^P|po@v5U^og6d*=zrxcRvAcOz?foX z&WLD}^AFgx@NiSop`oa-&W6>q4&z54BMn{*HoRC9Uz zTc_Nld9kn67&q(dG|?pTw_qE~3|MVZve*SV4qEb2jFGfr=g&}Njx6zdn~xm&i>9lW`K>J?D^|VmcmSY0!&D zUxPZ>s?HRK(Tj$>xN(&*`%FluVEX8oIcO^}D)XzUi&?K225+!bJ~|JHm?_yrdQd>^ z8e#?|PjAZ(;P676Eztmj4pq2sXVvUJsli20@$o7SbE5_=&9Ss$eW^)qBt{+ggR}n` z_zEydz&a6B_LUPR(Sed@N{AK9 zh*RfZS|@HZ>b;Y7`)%E@7))N??>l|!rZ;LT^T~9uau+5B+a?RM3X{}NO~`WaB{uEq z=@P_7VrhuF)wU@cmq^D^KJ4jsL>#2>LUU~`(uQn(_UCgWn<{nwCXxn9c3Hf@MY%%# zw3{RL=Ltuz0Dju$&ZLj2e3H%I%HqGsl3TxSdyn=Z%E;~$9b_{>r%E6?tmU&v6P5A_ zE+&=xegqPimqfx^hFa&~_Z2&>YVc@frX&E_uhYSG6vT`DNa z4bUWqNUL9(d z*#SoL=tqenu7oIc;*DvU&NV#~eUn>G2a35r&r};5vlo&OMq1Y$&+xW zds9AOfi8U{u^r^^M+o8?z?737!(m3{!moXzB$zS*0>-%G(NMrl+2T%aw|Dxq_w7Ng z?(wjnkc$5KYy6AmAJ?;?#V@gXy$UL^Z(DcBxs>?BEcIF%j#wTaZxr{2FOsAtkOFVS z6XZf+5yid{fc!AOJ#FiS_9t6x|I8u!ODJ)wJ}n7{U7E*8Lv6E4$cBnOfh4KADU3M6 zAi!`zDfjl7sBG@+af~^g>y{V7Z9|bbw_7T56(f;59P_sULPGW^QdJWJ1z3cI%Dg~R z8ABk7n36v%Na_sdOfcI4}_ky9bD0^E?szk+>;NbR4#3 z%nJoAz7+DbN%ljDQV0Wg5JEzRi0h5PsK3a60rwnCIns>B+#D9ZQt>LUuu6rq>l&w-L~Mb8YPIh@+&?{rjVbh z-#A!}zWtq!`5lM^?KpBwtl}!9cs{~yz<;BWIAhT(^_#S&Hn9zrjzL4*qU+O>Qw!9a zfw4zktol^F`=s=yGRkUBjsRS!mQK&sPNp&OI}L>BnoOth^LXOh*eRujOkybnnm;WcsIdwrJcS}^+zOcx zzgX2xz;lCw z=fSNP_=Pzdj%jz1f9@=9s`ny4+rA!LO>QAi*6x|Bm*aVc_~wPVWn2oa&8l$Kn`@eH zQ2Q~Tsnot8Creko!_V?wV0Ep~>nPMMIG4W5@#WF{xH zPu_V{q63%0kD3c2jiFC!C_Cu!4O0>jBQ;(Zgy!ZY#Br>001hia3D$$vFVqZFh)X-o z79s8@;pOx_dew28etiKgwUrR3X1A#dNetYPM97xB?hDh^nBKI-JPW#fl>a)jUiB%511F#W}j=M5a zu4})=C#h7}QgzhDg?(EAA4$FfJ_1ks>=UVtzv6NeBckC4 zKPvv?Utg9Oy7$;xK?!(tRGerkx|#H5C4j9X7SWi53R1-kxPk%PYynEeGW7m%*fBR3 zr!?Yv&D6A^YXJp`#;*uVJ`B;j#`f{IBou`noY3x`BB>bUm(!eJ5MSp-m4ZXZ;XC3K zz3DwrwMtQuMGTrVrJfHhI3)K4ep>8DjSD~5$`!^*R}lZoQ;jZn0+K`1T&rHtnOw&K ze@jE8hDU|Dp*RdJc^W>G$?IsP>}rMV;Wu|#r76t`JoId_KUq5 z)6YwWx?A!$b+w6$%XFdLfB3T)1B|UWLrb&iBp)~x0EjMKr%O}xzlA*|NF$dRotG;T%T5E* zR{18BTBfmQqFODMjY&drBt{-=_I;5IL*Y8Br=4Dee^caB>|ScL?-c4002;VHWOUw& zGEF9TKaX?;X%sX{wCu_*R?Am!X+EpXqCR6#tO6)UpTE812EqE*e&kr*ZF8TZf%@7!0(^@|=}U`+e3Nc(og@WsCFBN=+fMI7^6u(zM6|*bRE`0=mFE4& zW><9UWWLXTL2H1jAEASl{qRMo2QVUIqH?q<^?v+3YfA#6P3^bTX?q+6TYawaKlVUH zu|f*N@L%bZr>xE>Ea2@_%G>4Pkx!(rJ}5?|&lmT->hAKW z4iZtjFx_47N6_b{nFx!i`geHa)%PyGgML~`0Q^c)ut+dDT{C!pDXV*IR>DZT=1Fh+m(N(fB-l=W34Wn7GQrPT^DL zbEE4y-%LvoR19Qi_DA}GMo0`|R%$+zL2>tsb=KwWzKOtBVkDJKk#DRSjTHU8e!U?R zENQA<6vbTe3*#bSQR?4|=bpnR7?}%N$E(qjeTsN8^>OKsQ3|tvKUv#7=FW}JtE}n6 z;+9}C0MW7Jxkd;5=IR*IqA@l1Lf$a;g74f0^N569^DtkRtwn4-p ze`kBi3q9wTYd!Wav=%bh?>97;Zvm`#h&)yB>Z|7ALHzL%8$M>CZNSe|gsB?U`N`&R z)c|Jc&?~s8RDa5#yPW{VP8c_a=x})oVj#OS|ExuJr6+ZKs-PzjH32RXEgu6+P>?2> zr)=H2+Ne}^C0v%0P7QQSm40$1@0ansY?#vz_;-@ zufkBI$s|NbpQMEf-U>=`FN8~tPYxi#&f@i`3Y**?9TYqHkEFNVP4n&FuZBDl&(^;W z$P$&kF0|k5@saN>BnE>xaxN5&0PJ{eDP97dEiY$aC!S_~;Oc&z_-{Ks)W9zEF158e z-^d-|9xyKD`Oq?V#{46(@3%`}Ako_=#}GSZT%<^hlb3q#*tsrWcXxniup({2YDkqE zKAYhh(2lL9!{^1Ib$LIKf8|trh7v_!rwWw9Z`yW9tKMW@^+pmi7&rjw?9vE|ce(Aq zF^y`0unFVSQN3{}k-JF6tAF21#8`a2I3^mb9AeOY@Yw@{S7U4vht#m58*fF>9*h>I z8r);O16JNV=?7lz9>d@2-+IL-efXllFuTM1)iqcWZ=d>anDA`<+ukz*J1WE(t%)|7 zFu{!F8^*UsL=pVHZQ6V&KR-ScK#vWh)f?D4cY-zL!K!VE5KJ_`>?=5=q0I8$IQ50m z>RFk9*N+ZbxWL6=zR#%kUgiK5R%CLx_|&{IpM|Cv*04X1997H%hEzIN;NPWheNt3I zipm(1!SaxU+zgc8D;1x;dYqh_~p+xT62e&W`|>W{rLDUY_nDnCJq~YWp%rU}pj&YXZ}Vs-2_oFsdwG|UKVH)FvaE;6#23eVbOyJ$&lmtx zU9kTXwbJWS2h%l|)E^&}G2AfB;<}qo3D$x{S=%`xS&z0FD1Gb(j6}}v832T;cqnt{ z2?Hi_q!1sok3^S>6oN=AR(q?F(;T={N)t}CUogB@cqv77UDCPkL5#_SCq&)U*F=sOUuX;M=dBxD5H z2dTI;yH8gH(2r@IS9?4mJw_ZS4!mp+ZPTJr>HgT)J)*oAQw=W8TN&02Q`Pt=U{dC_ zn|U?&D8=(o1#Hs}o2MTdn2k4U-t&?NR?d?z1eVN$1v3C5%GrG#8n~;W#n~NM^5+LC zERP1Pla(AZE^yPR2b78J^&;1L5eHn>t=YQ)mY3wiT8)D*$!KLGQev=M#~?ZqB4*|NTfy zHXTG*ir`9iYk0DhHM|kRY}Mo>ky<_C=0znBB`-_R;kJihK=HHZCP z$~((LyNwb3KcY#>0C{cmG$o?mb%q+uY$N}<9)1$K7SEbcl&RI~d1#hl8UR-4FGv`j z+M24$qr8q(N zl|h2TguGb4q^e zrxI>LP}e62tG{3S&eHmCI$x3{^IQsOZbf%vCQ@mc%@hTKdim= zTU6io2Pz;P(j_S=Fr>iHEl76^-3%cef^>(Jq;z)=NH+q4)X+#vmq_a~E{@M4e=!*gZ70k7A$3!z@8kI$goKKi|17^2J-f!@Lsg$JR9 z#7_M$zn22BWzR}WtXyf~a!&}`jv@61{bUsH_P}nk5G?Md{bGLZ`RkzI z$H7BZ|K6BNM)eRa}MGk za+Us`aWN8&Y~KRq^@qCz*XKs)cx_iG89eN4Tl?_xmFtA-kxI)Aexzc;2P#it?iyv+ zf*auwWTh`gcDiaIjj4#yJoz3M-S_vE5x)otjtC3_O=4jS`bJtlTS%b^88mpf)D#Vd zNT(7I5)K1Yr0tG?Bi-rT799T_**P3m!XW@cfXj);$es^_m>kaSQd|B8~ZD>kxjn{W5@IqaPDJ=CAdHvx|RjkuE( z*=rVebYB1-Ohyq1r0W!Vg<2l|CJOC^-No;jP1?Dq@;U<8%~)m1tWc_wnS7aO!Nxb| zr+IOTPs@|jx>1%RDId-xe=7yO7F}Vr(a2KziyBaMWcBwCBym>aSPCmCL z%6aApf7k=CmWzOS;Eld9Zu}U#XpT!L?#o7+6JmnVWuo`^+_0|0En)VXc6_>w=Y4dVMGUV>$m-Yna+h^h9>ufJ zl_7Te&`PK&PIv9*Z``VzHi?4%7LoTupEFN`?%I9R5JBuckk(5Ly|!LbHYU}-8tW>E zf3#pUn&)JOUT*eRQ+8&!j2!tg{^6Gh(b`a57=Gc-Pc;|x)8-GsHcF7c-s>Pr(_J-g z0J~q;$_-6{+zz6KE{yUD2`j9aoK*7g`w??CgUFa@r9NX9tMzxMAlvsZr%Dk%;ejHM zDftINVhNgj)=8I9y{e#-56~PS)CvH3y}(>nS~^c$#C(Oph?Xo$haw$K9Mtc8xCtgQ z+h!wGlSX*+GV4|vwRJ0#|{nrZ6kW# z7EqwWX-s3Q1E6z`=U35_D)Ip^mUOt)%-SlmtHoS63N_Gm3Plngz%f{#tNM~0qjqlY zQG@aeiQ*;sw$Px&qAdhKo>DC{$$d3)00x$#LQ>^O{x+P+D^mO%!^$Gu#9>J*8(~xN z7NETwIC-cU^dT26~x_Bsxk5P?zQ{oU? zh+ht>tu4d)zt;WQRAh?NM5#Us&S<~4D8d~^7_*PT!%A)nJ$TN!s1BR}Mn|&x#N3R} zjJa*iXZzo`(7XnbD5ndsc;G>!6)qFB6iT~`LV$ILFw(WgA7VO-$045kfMPf?ZJ--8 z@bV2Z5ZGV<5(b(8{0ITB4A9{IaH*a|B_|sAXY2(yO~l88%})A;0h<>DU=4}~$rSSw zEusm*k)<&=LPI$az9G=++7QQ(qlHl!RXgJ0#GTPY2#c%7i%r9FmyVH5dmEccB9mI; zKv>`}PiE~s`N?m_@x2BY)=LJ1+tBr|$su4U0tw+vF(TSrKWrBDjjT30x0OovXP~-%F zH~O>3uc8TZ_9>PQ$={LWuEw6d3$WoQY~Cu&a~A~JklF$d zUcbF<$?o?Q3cq&qWf~bfE??%+I=|tX3>^#+Rp2p6%eS1(-!;08A$zuGx#g28mx_^Q z5L^;`4hp!PFuk(dZ+pJ!K<0IFe5O{^+;7Bzt^g8ijq&))U>Vjv6TVNCn?!`t9;S-e zx7E1$nW%}S4xn4z2tPZVNY+)t{9pgb|LgtpN2BjgO6D?^5U#r-Jq3yBU9B4@ zHbJquOHfKFI(K?KHhxv%gq^cNTNEmAJLYtGFlY&?r?&anU5g|Re-F4uqya;A#t1x1 z?Kc^AO(F6W&-CA2#0nQy+Rvt(7i)_ktLPNHNW|EFfyk)y9#=I}Bamw$M21xs=5uZoHn7yPO0|6q+VAa=pR_wK3yn}$LBqv)IE9<{`BhW#(O0~ zOt1&_T?(vJLJ5xu$X4y4TfHOA_Gaj*0Dqu6xp?7{fH3r!ZZeZR;Zkw6KW4+ zGg>Y(YVZ0)B{BnHJAfD_-6=-fVZ@hOUtMbZ)&CCL0rXkhK37V2SK616Z?NBDOenz= z>i~rOFlp(7v6;=S7#td$Ky>eM;b=;$#^(+qGe#hFIQ}a^@{NFQpwu*scqR zS>MF&pl?{Bcuf23T29`SAMZ!mpxsHHb>CyF*G|MGzf40V=)IV|n?x^U2Z~1@va+XY*tsHRXp<)y_dhCmFzc3#n?S?*_z4Dy5v|U_+X*?_V)5fpKo0f!GD@ps=w=VRheSJ9!Pm38!z}9&WDJO zD2`%V7xS%>6J$SPT)c=OacQ)m$pYCC2mHg8He=BP00*g@Zhc}hO@tfq!pJfAe7wU8G8C&>>&uipCXxqp(Nu5SI-t)!2h-o^H@Qx74 zIPEPCP#WXDS$uKktH~m|`@|W#P&PYLsmGICu8>xH30(Ps)0}hf8D5QH#NGcJ?LhRf zSR|@h{EGy%7xJ>S5TjbdI0ymn)1-3*@zkxmw;)LPY@htCuBlLQoi}%H)@C7qvKol; zn9_@7z=`Rs$Qa#Nyg`3#jpWK|W@bX!(4{cwfM~#h30~~}99U}j@ zO%U(t7D&BT^mm;xWtl>YE##&4%nwY8ug3T_(9oVr=m2&kN%yLf#uHJ5RIQtLHHDT7 zq%=1-?roGGqpQK!*Se173aRY29NyKneqY2I>IU(l8v$P1YrsP} zoy`+L3gVA8(jVzfHU})d3Cuh&W+6>KNLLU5%M|82#ek0&VW!NjnAH zo8WiF{%rmPu7agBNa1z=JJ#nhKcM_>?&(c7=4OB>V(<2`$S#RU7Nj}=9)(Ff3&A(| ztZ6x_9*XSxwgR6x+Pn7Y{>!%Ln;Ro|<&i;m`(PIJxvu3%c5{H*UqnOL`=G(hV+P~& zQej;ut9tfYWw~VKRaHDZiMT)vZ(LPE>25lXp!Sx>o$q6QVeYefK33zS+36kDeyigL%oEywU` z8FhNZbzf-f7VtJ;o*23q$P>k(zRGY<71fbo9puo}s-V>VReav29Kie*v_2N8azOj= z!CAb7h+wUBtyUG8Mt;qi_SP#ja&@_Nua;X)mywxI-)LoiZ{_aJUw{$|EAH{HoYNig z74kAivDV$=;Qn4@&7N#T^-=Hfp-~x*ZrnQH7bw8oEbcvVX5toCF@SN@emxP}Qp$2l zz*f_M^v)Dmm3PunofXSvzLhUwc)OQQuObavmkj9hb}-!Js?SGckC&TA!xVB~R6H1) zHAT;Fx;$E_p-db}S8Q=tqqE+S73`wyZ!@@S+Z%jUVYqZH^j(!!hbni{GxVVSSP%>zqT@M?H$&zgB-#t$TiCx+%z2R-gz0lexWV61qlo z71*PX;p^HbZJJ8lXcjjLtaNNjKlw%I(;$-bTjb$JS2XUV)uy(5A>DVI0t{2~*+J%i zZRBg^+beK>cS-s{RnGFd{^5&a>y3af#d4>2x?sVDt*$t0+S+g z4;-MFadg=fBnV;)w=^ls)TU)FmL+r8F+A?Tj3pbCgcbv(1Vt29bYwzyV$d}#6C0_< zNE+x?8QSL66kv5_#l~5@y3?Hu8w~Vfvmt;%d~#%GOEI5rS_REk5UfA5>K`sfs38xy zvuzC^!uJYr`xb zwU}8B!`E@`Ytyl!m(7Ld8ta~k*rn1Zh=b9ak8$R)7Z4o$Ldad^mOiWx@?`p;`cHh! zAuSR_!!D0$0;cv5j-^I+hxB7p%*Gn}w3lrlmsi+oZ0ZtGA^((_(W)~9?_H;XwLRdGlrG{HfbU&(KRYV|HVD-}=g=6`QF6OOeKl zVvXrSIhd@v5DsxB~2+AgzDK9^_`j?39fCXJ#k zer;mSXc1k;eUV!MHp12pufv1=@wm>d#=;+LUx-j7ek#l0{boB}NCg^a+W?9h?{E0q zi$OxGD53W%9t?IA^K}gCwM`EV&K^vJ6UnQc9P70~+D*H2H8~#AeN4Y}a_;U)rq_H* z1hSInr7-9Ax0JZmAX!459zQB_t8cGPPLyW8vV}F;FMCu~KX!+K-V$tO@cUh!g7#S|j5oKho^@0%l-(+-Pg&9))it$LmmXKgB1NuV9% z*6ah5Ih2)fSI%I+j;+Op@qiz;x2-YltTC=OWBD|02aN!;r3GlZkf_Q5jux%B_U4|w z7!!$UVyqFMVz8@0lZMJl>=Ef`vGHtWX7ftU>1T8Xtnb#u2b^UdocW}lJMBodDQ=OK zVt6oK38779IgAdef{jKI*H^a0uHJp_6Z_c{T}56{A>ixHaEmu9fD5F~sD?4Ai zbl7LLf4=}%d92H8{4OdM^CoUTlL=ighmU&*3z=H%DClU2?pBxU=%CC*%>c-4s6#oj|vnX(C z&3^KKo&R%=uaYr{O&FX-OHhtKwspUv!|%jbRyi>Flvn+>ZBAhP-F;YXjm0z2;?cbG z-&2PAqtQpBOFD`3j-ZBC-&w&L2G2BfvLdXfRAABaBgMF53_1oPw#DB2TWgdO(Ftx; z*vDxe1#>RAnsy{53^D$9Z?#(1ksmsNa=r31y&ZlR&LL9i4~%Wg<3XiWUn{Dws!|Xp z^qPUr#VeX3R<=U1OPadl?P~vB^zMsHM?8CELp~$oYng4qMlE8@0{mlwNj`MR2K(rA z#XCWAj_nMjbtzH=rXyl*B)C!r071?TTKHdg^PDC}WeF5yeASELy@SaudZblP`Ukq+QpI zL3$AZ|5x$u(RASzzVZl4R`>w)Xz{o@s>^)!X~vUinc=K~O()+U)ru}^=?)~8!C4rKki9g>ly+elFCTG>jBT>b40PD1^NzH?Lg4m6Ujo&+^F~GLR&_ zE?=U8x-w7{YwauSso4u%sMLRy=!G6BaJ>u3N?Fxare5*>Rs+BF$q_&=Nygcok7haE z(5(LCQA}R@*F>;AP2{=&>Xqc>{G?CbxFnBxc|&Y0Pj52h^q4p+dVR{_}g5i)T)^=1Ua7qxE z-e4%F$Yd;>>Ms6rNO$;i2Ec zXD>(=N3INHIWb&G2^unj~#skkY}RvU3D$xQmBx3=Yl<_#9h}=ad)6<=jlpu8u@;o3M^C zn%?%Wg%FHe>awrdw%0=98EGae=9K9v<~^6cJWQ&s1woHG1+o%=OvtPn%zk!ER7{T? zhSA(LWX0L(_1I&MKxK}Ou}Pjjo5!jjnyt3(hrsJUU8G+CQiJU`!`=V4c|udgW0r=H zl>4RSq5&}u_R@Ru2bGIxi6K`);;zJJSwJe{-Gr<;wNfnV$J!f9$Y z`UAjp(63NE?cyVck}XwKUz15DPC#-14u%yK0T3~IN!^@>+!b+7fGyTALKrLFbJomm;PyQR6@GR>nW z=yds5Px61)g0+%|m1?pFAymh&;$sQ9BlCdqp-I;GCn zUG!umR!TBU(D|BTI6l)GhmCg@dT_Gzq0ivgY4)fQ1w2az%0R!Vto%I~%eHpKowem9 z+P6PpK}=@3l>Q!Y)A=zZc$2HE0EjL4%1L?3>f?y!`+8%FuPsx=4zI5UJ16eZSzg$6vpGnTGT8H6H3o z#wEE_O`-u$QNj5+s8ajs0?J?tww#p8W!eNR_Ni5G`SJd&^=n;!%fxqu+3=~Lg5HS- z{@8E%owt8!+;5~S&Yw!W}}&gE?qJWzFYyFsqdH_sb=ArULifzsgSA(fhgc`1>@`(?Xnb*__+g z425vd1NSet@>zYYo;__}W*fzn|}}L7F@(fubxi(aMTug&&W_H{c8sH_FoH zBe^Z5jU(ZqO;yIU{g9cI1OMj}+KZUq+^>d^&J?l*yBDmTeY~(YE^%K{DcLhm*~CFA z%~?9GaT6p|aU}jsn(*Y@?AeqcWyc4dLs%R}?0wn-LNvS}*cb zB24j%>Ezx|ClS|HSQeV+2;ADt6x!9=o|^IBJD3%$%jXAytK6tw$q&St(fxdyQx8$D zcp-hE@`8v#o@Gw%O;`?GQqd0ng)&q5;L^2Zryq)-(-=cDd$KSH>%BeXGPa)(5J>iI z`87w5^^%OJAG#1pN~%6UVKyM0M4YJqx3t!{%TLf~H$44syb66F9olDMQW4;cd~xzy z-TKwX9IwXxr(p8~a~X%F@=s?tmvNXpJ`>27d*vzX)~UiGWj%B~jvinocdrc;_oqaD za<(1o`PJKtgN_baq$TKw6oyIwuDHCt-9V@aXjEJA_;6>(baA)(B)Uf@IXp#R%}|qQ zOO@o78EYaaCs^er1u$h7rhWxq23Xs_01e$@K8zw|Zi=!%d)pf2 z9qjckBAT8>CvBQ-IZdMk8JI+Xd$vz_gP|hJfH`SWbWV2Kc^&OfX_+!e*k^tZnV6qH z<&8^{_qj^Iua}?<8jxc1gsWmWqVAmA$8HY@dl3=6zVmTCx%)^+NjsqC0B(!ZW~F4c zQiWLfc1$6}#qxdpT`GI*>ohFyeoglpxN2rm2@K^d$9Y= zqJUEv3rXiTU@eFP9CtZ_t(iDUkf1V#al#lAM`1Q~YtmmK#TjAX z{o2AH-mBN|67>?J!Hzc@GDh?SClL6Bbr8lJ<( zd993D_L%JjK|O9Cw=2LPu_A`7cm(dBobQm6G*$of?&>6IWzG(|zV`;9;*}&1dqMV0 zbVdUDxG9xXfrbil&iqT>A`iKI4M#yEsKo7%_wg9_?CNi;z`fV5=ecl}7ydN{l|ROe zwv|HTz{GH9WCI2qI^4u9!ye;zanuj>)xAWj*`g_6Pp^s_5Y9G0xCpi-D-}wM?XAa_ zx_FiIu1oC>dt9Wf+W+H6Gx8bk_p$berDrn5bR@D|?qd48uzb`kZG`U4u;XAxZ;f?x zA?nlu^bOcwjBsRWt(Km(7IQd@8iRA%*_fD)lSlBvg)HG0l8bSh&;z`s4F zlC-D%p4c2{n|AlVm-;coZ4lOJP<J((N&g;x-XL-VaAkX`5nxf`?X)h9~{9d#K21W-^0m*E`f^4F{kTQC7(d3 zdhgt|dZE7moUh}ih(CT3S+9L5+@w$fdC$@}uV3v^C)GKx_%MDSxU%A^Qhds$YA+wn zpE3z(J8?F>79&H!_NfdO!#{|7I>Amm=HD48QZbz&{vA%mbND!3^fp3l@yd-cxhaQr z1)3xCb&lWvbG@nk!MPFTc7~|2$|Qr_AkWkSq;FIbMr1!SmTdqw)6!Qbh|kC~eIY^mgF= zL*i$s&65iE20a@1-E6J2ty$D7C*{FeXaK60TYP6Ajemf#)~wAKhjyx~nmJpTk#h#& zvEF2AR1UQaj*c+~UX3H!olCc-zFM*KV1mW5HUlkx*pCd1aK$@obikPKb3d@qIy)wI zWci*6gd}cx6?cMG73w5Qw8X90AY~uPJ!`!`vDeK+X#R@V^eF7e7#U*S-t=wSI~tD1 zELx@OH9R{}0JFR2)=9MhZgzg~rQ%+Tn-@(uGEkP2$AQI;`t{3AQQw``h|OugOu2`n z??r@t!U?TLiI$=~YmSOUKXka_Mr6b%oyk^_g5sxNI%C>Wy!+wN=0(-_6^z2a`O=&I z2*a#5e$vcigU6l>L_8J{Bg-2D!79x-v_LTEe7PRb$4yu3FxLPN?^Zc2&eu&Mj{1YcoO7hKMFoD92Bw6sD`tPL z-N4L@29xTcqM&*JaH9JjJ-@?RsNx-dayuDp`{m;RVl2V5>B&!BS&@RdmRpz~ngdUa z?sQ{J@z7(RD{M9KbGy1hok>A*H5tO@yt?!|xp5eAf{aV!n{g7u^ zSCgqLrWvi-`yIHGrtYA8(%4HlDv(fRlgI2kIJvc`;ZOFFMnEs_!;?WCL@coq1bwww z>K1g8pGSF~jT?j>q)NH@TWp7qRgr>-3Zd8qvJJcWrci|ZCur{~VnT7KyYvV9==k3; zJN)XVz+b8+mGS*%T!Ku9zDA138+kfUbGHT`*@1MpI_fX zZr-zJs_N&PC?ajZ*18RH_uKYhChYNUc#NhxBjTu5pRKSQ;>bg!!mv&+lSGfQ+oybX z-jDe-DUXcTZCtB?R`00_^Pit{k_&+{fu;`9Lg4?NaZD~@PnVMFg=b>pA-=5f#mSyywQ zYRKvBq=A9buL07Wreg~Gi$2+Zi{(jL0v>k^d0+*-GS$!im*3v~(4G(=BvmTZrX!d| z9JWK!3kdF;7+W&0(fRgIu8z^zfo8)VL-^-M``70$99e{ukq-|gGz`UJ71YcB| z`$yZ1ZP#F&m&8N#RU(GmRVjg3(gqX3!YCn#zf#g)r{aVAZzIcO_j_Uu&qa4F439rnjV9Gu>@%u! zxH7AxX2*3gd!c^$`O%Wjs}T+o^)%{6e-WYe=B8!;IzJgmJ32lON+u+aGPUB`p}ISi zHp`Z5_aM~$??Nzs*kJeB6l~EnL`eGfH(XUU#Mw`<2vCTsZt-deSb?_ zAT2R~w%2OJnkMTP{c(pB@9P5jAJ&J-#Y&+hYsxXq5T zKjP?{JlZ-scHsfiWc^&GUU7V*ecTdS4L8iV2LRym_tO z;ot8w0STbdd2|SC^|?J;(RAi^G}`|b?PBUKz`mpxdE|GD;23$&%J$j-_t2IM@H|WK zLZ{wY+A~p3`D&&ewj*K%bKfk7Lg(JaY-)+ud zK;Lir-?cF-TGj%{Iha`pE$jZIxLvE5+dQ>Lh09+Q+L<85B(kYQgaf9#XP0(wp}^Qy z5L$^2v{1$j+p^yY^T-s?=X zpOA}Lmg1}#&2dv)ACAlodf3NDyfZ*4a_Pft{jJ3U#F{v5!M0e$JjGKijJvQmSW`}C zdJcjl;tm$Chxld!)2NrJJ9K?-oj)S&>;)yANCb1UT4b=x;du@W-)q_l#u%MRPkjq> zR)@6svB|jrH?aPm9L#doSio8L(%XXQCET>fU}kO3ul+4IMn(ME>E^}&HmgwD4!iz@ z#HZ2LmX&FVjeMA&;9mrh6v{{@fQ6{eRR+sM$KK@zNBTO{G(XIFYXN_x+v{y~ZWSYm zBg3Z(TDqp5|8G@31Pyo6eWqQavmJjhSkAzX?ArF3C_2awilCXX%% zQg>3_K#$|^m7K;4pyMtrzatmLcm1tTXUb8(!zcTy`1E}B6Ht`nW1Hmj2q56v6ZR6IYgjPh%~Ue z&g00&rqGEOHEKb8BEqUCx3n(-;vsDq@3~7DYO0T3IIGu-2!axIoUTZ>OnY2q(vZL( z?``79@2|<-C)4Jp9S3VPuSTypNTV%H{7igDpALR|wiELc7<-A;i4o`-+pnF^*bcN| zk1&hqoF!!M3>I+sPnf(ePKVhqO!<(o58rN@o?Gz1IjOr%2iD6%j$i?0X;aP+UD;xX z5(at2Z8$WcUBfn(byPNJ<3+z-3Y1(@k{{p+OUYu90xYj?q6(m@d8)Ar5$7ixd0It&3YEg(Q z>0|l03yXRIu8wLsW|_JXug7rRg1M;O6O&x!l6bL&%ep@qH1~J{AhKVBX=`2o&E z@Z0upaKFL>m^c7((BZj2APr5|bnw=5H%wX)EX(a<@dIeSv>;k}$9~~NJ#{nZ!6|2o zI`t$!HFt`E%y_m%G~@$^e$dy=igD#_j{uYOrvc3Y5ZlAg>Lr9yLS6fOgs4KV$rew) zRl|D)w_((PCp5tA+U>p4B^}%$H+#MI+aXJt9K`1>6LT_#8$_m`e>3xxEG zBjF0~9UL5HksY}<9Qktnbr^@qxt(kc?A$P{5|K~Cl`DqCExm-_oJwUzCYc4L&w%nb zV7Hy>-@7OT*(B<3`t2ve3bA`m@Mss;XkKum9a(aM%5g?ow)^TL3wquuQeg+>Dg)5u z*Ixsp88dZ?L-J*q|cyE0Pd$W z_=e(3A99n$cRqJCI&r8P#DEj1HWs`j%3^J!RvCGN$s-7HlHy zs`xDEXCek!eP(1uRT{7jc(|)Un=CnX{dSQ!p`_h-IEW-(aC@et(a8C9UoS@?klIHl zKE?$>P%6Sg^$0g|s7LT60JAnFDJW#7<0~t?-N?M$h52wLXD;1B#OelNKvCatMwoA? z;dG|UkQBqG@3EPy&bk`QF<`DjcQu;g*RQEs`qTLCrC#w(HB=4*GfNvi2veL;lLXZ% zhJ+MdfXtKyq^2WrOL;v1UB9CG^YlCVP(VgQdXN#uMv}>M>^KdODYfrymRlRI*gdiQ zy-d~Jw@?Y^q7dCuX>NefTYryDb+h>WW%Zts!tq-Rh|n;V*kGvUjeR`Ri@7KB*ttZq zp?A{I(q{F;NWz8Q2B~-WLTTrJSdA1unqXCc#RY{E-}SzTLmYoN3%+$;t5&)6u38|_ z*^wzprpTt8dcn*NuG#gb9726ow zfT=_>GwFdvFThGjeK`Ro?oqd!H^8D!szio7u+31DqC3k`*SGCjt`@up)O=sDixi%$ zJv5|vgIcUtP-~>Q;i?pI=YS8N!50R|kqPDba^lT)yIHt$^!1w=)V20m`|AliC2CQ8 zwvVd+-fCIpak@?M-13LE28O<{rMAq=Pl7TlD+uC7BPB+WG;JX2%FeR#0@qmimF0FN z)*3~s*JHn%lQ5!pZHccRx}h=%;HufDTSI!k3@1@1xs4FTlF+Ma@1X5^E1$RGB{GN& z=5th(oPz_X$$vBgX~2})(BS;0>yAHXTqc5RS9>f&87lHxT$UKm7Mmt~*L{%g*6fc? za}rnO6mr)qLa6fPT?Bcw*k>th?+02SV}%SjyNDu`);2;qdDY1=irnS)0_cVM}3VE>6vxw0n$)dIQqi4#3-96LX$**cl@zSV* zAbgB!*d+t&98*0`0eJ*dkHm0|@v@+ve~v#DkB&|~Gcuo_dId!5;<8vSFAx4kkHF%E z?AsuWzPnPaFOrE3hhMJnKM;{33y~zNZy>fhnow}4>jE6sw%`shANai=f+QvU2S}z` zp}DtWwmVJ81?5hzyvN+%~tUgy(YW@hAQ>}wMfdY*udsROKP`vqm8Ij8en~(9Pj$^_zrOluUu8`hMsg~+)#THB;oSm z*BG|om;!J`B}P{y<*MYA_{n>VM*FbnW+B(W;p5cl2h**DF31`6(22kWdiOH+wH^U&c`v+(uye=C8R8ju{nG zC-jn~=O96Mw|G(}1Y{_tc?!=k04&nPL`hM6tc^ z^Px}USfgLd?Vnsrcuhe{K?V$F4>u>j&BtcW$#M!Pg-4JQWRiWAmyb@Uu&ymOO__k= z8G{4pXxD=krOr=!={yrf-5~wws800s-)Z3S{9${~@4A{I7n@{04mY*{ilGy*8%Xnm zA@RMnCTAEk{sX#>QP+UL;=e4LRYn^Ik#&8-hHN*lY=oE3(0Ev_b+Dfxj_mo z;EU*yf`IapSo!7C^a%vG0{bO$@K^xi*pCHOPZvUuItPGGH;u3B7ek;uMF2uA)FSE1 z71HZ;5|SI3x1JYwR}Z#pcCWlaMM!|+?TzgV>8I{*!}(O%)}&r;Cs(3nR*Nc1JAm{! zLi!m$wqkFyYa+IC9&iWJrp+qLIR{O9sToq{P^~o*1GWVNqPcDep%`hGLgrjNe~C}k z05U){Ko&()HzWz?Xva9q$%uJWUlH*03Oug{8iX?(;o9TeSiXPM_ycf_ya|hYiB3y& zBAlga=v#hr3fTmXgM^@<41fS`-d!Rs`i@rPo@EWMA3%bZbSeWU8rLlNAgFMNKjT!v zP)+nB@I6_KDW0Ty9ju8luT_wvy~pkgDsXXn3G6{gA<|Fr$g^I8Z(txoK=1TIR#L7Q z=JW4o$XUI{A1-|9B!F3n*K+Z=iJ;eFWlCUntl&2$g7S24;m`q!;zk0=-j_J?nL6Rf zbBrsp$bwa*eFzljv@Q8dXWtnqh}l>ullEX{7|&1ogWo`yq)Qkk4%kGr&l7S%mlt0E z^7$qvpaU@oHOjetZ$gsTfIMom^_022S~OY)>@01?HDF)RfFa0=c1$7h-hjo3BY3X{ z43`5W60aC|;oSgEm;tGFYR}V@B$p~7l6V$4`q=xOOa;v+B6EV1rfM6sr zzT^g$AdOhVme$N?Z51G~3848BkQ-X(5|s-PfvQXiAZ_oNLLq5D-|bk?f!iBBcEGZK zLD8LntBysJjU0~bQq%;*bFiq<@g<{>;cD15pV*k3L4ZrV7v>>}_Td%qsb}MR2=246 ze?oD&`RD%>4D5^~cYrc$T({|ZI)^4PZAkoi9{eZ4^ZcJ*uTKHb|L6tW{(}*H5I_Oc zgyI6bF#+Ae6=ah{LnjfeqL2ueL8D!lDoIA#1sFunKLHI@gb(`v_q9NfGOP4|Uw@x~ zT1r%uudK8M<6sgkq0@%^K@qINDqC*T5PAz{ch&{A@?slb5^WgS4MH~MK524P+W+6k zD_~^AUaiS?futlFZ3{3LB)*e{*&*mUp6ON?Njn1?KnoF|wcGwTETn+E;bZljJTQ?t zV4V1Xkc!XA^B)KVLBQy`KxJS(a`w6KHzBzAuXka&eW5vS|7j)zAegAK3qzc6-E(rk+~9s#aWe_QmHY?18{%t~e{KGr zhw^)ap1%P^NPG?U*T(5$?28d5!1B+4e8gwyC~p)1a`l$e4T2z{SOM(&3L)^LBp^n( zddz78ktKV&BaI>%TVq9QlK|0(4A<~48vn1HBRl->a5PuH-F<^s;3bxZ=(jQUz$ovU%oT`Z}Rjk zsy0MvK=ilFv@fg-D3hV@pLue>%Z3OYRikYDY$77E6zmP%+WD2SloERzdh!TFV9AWKGXjgL`aTNB^*$y_32ZK z?Lxh!q(RnG-$`lm*JCG)QaAg%cApu~&Qq<9Uw#j_pM2>5Zwx+06-6E3J_jm)<3ef$ zZ!v$(l-hAj_YN_n)i)YvPpX}i03nJMy#Gx~5(7C@JK{Ox%QoOm^_cL5g_g)VaS7+o z(B`&z+D{C{l1Knm3+w*TF%cCkOhN?X}EaWCg?y=wf2&6cR2iga3*8Z*jn z?fQQ^KzkD|$*NSWoK+5#T71RTS$)#hzc9GLR-V*g?mHbi1sS$Z3%UG{{c@eT6Y@Pk z+Y2oK^iK=uz0&9e_2^$0lsV}WD9C!l#1i)JZ$#~STEdjv|A-G$6GCtRj9X0rrh6&(m>{ zQp2ozZceD2CCHGkZS3F<^S1eGsf?%2!e=+ndm-5X)zH$=*vxwSf1F7pY@Fx?tN+U2 zpX=SA_P_n2;gytMRmu#XA#gTQy$=3A(PEd$5p4Fk`ZxoC6oFV&*LoR*y)>H8Y?oM5Ls(fBPQ~UWfjM{dRT{t*?FGcKNV2gV#Tk9=%b^r4J<*hq@+# z2XkC*DRl%xW#2AhUagiQGml~Z+$4Bjr!>Ov)V0T#eE(Elm6!k9fA29uQ?q0S@NI4Fa{_D8EubQ>=EYi*k?uYYgPY6Ca%L~uM zRN4OYb5IwIV@m%0kNu%9u4tR7B?|XX)f6)GSt79SmyM_EWT{KOBTM1c0<|1oKD6|o z<&A960YKep|JD=#iYkCdDcHCLeClhfy#<(Ll@f12Nr(|A(r#aH#4F z+J!~B4{)UO(9$5S#Np5=snVTFr-Fo(hmaBpi;za??hfgY?vO6&zU%mV-+RCBAJ}W} zz1Es}=9y<^n2DYX6BE0jo}@W$oHL*bYLh+YMNt1c#xUTLV8&^oVfnO?b^)qTT~=J# zr;+Wubrie~_rDRa=-4+CQl`P|emXN5252&$M+@Fw7pn%@YPy=EIT(|NhZp zz$Jbzp3&GIeKzD*c3+K6a?REFc>W(nKPeX{uJLw;%{l2K zSJX=Z<2X1Z^@So*Q317cq*y{W{iCN8Ii$#(IMp-g)Gwz`c~9)T^ueEUoc(m~Qy3pq zUs>jSpu%B#Q+hZ6zeXH&lCafhem1=6r8s^~C1RiCRe^dGToC<~tg28(nv(#&O)9P_ zq$5+8arv7t-N^UiXoz?V7Y(Y9CUdTS_1f=my%Ts$?o=-O*O;oDe>-M*cbC~&`oQF8 zW19A{VLBU;$cqKJ&6SF576b+T7_*9^3I*QJfTOK(^;^3q5{qJwI^tEq&A2wH+}k)D z&Qzt?Q~PH^FuuF3^+e#%AEj~2Z>dFX2lta0nm80r$ok^%O@?mTpbFU)=RUUG)CzyO{dOO)7vU#^3q41#?Lf~s{YJm~|M@@E zftSHxQ0>NLsI;+bt#%T$G>v$wu)hXDaor@|R81-7%=q0%9w+1(mgybIY8kc0WtHrG z4*8({;5+TF^?(!qpXY2gU!(1knXZqlkis&pIV}9&>n>W3W)`dz)+vq$}^jL~Lav|VD2OsC;N_OI#RM|T#@ z@JA=JPi-MP)DK_r*IKth@qThQYhz!Lc>ll4N@J2sk%kk3vLG2{&DVE!@uMXFyfWfw zVHLD}ztf@mZo@6q4O{LY225Y^w)u#l!}|$A&B47n@V_;10I#A$xVrCR40?Yo{%6GF zsb_1w#!t~H*T-4eY?}!*n}iyln*+iL5 zziswDGJMu=a^SZ=otN5DG+yfwdeDVf;y?%gpio8hrbHbCb*wVcucWS|chO^r)<}uV zdI>`i`hEu!ZS{r#VT=N#QD3T_eh2t>wQmpgZU;Zpxm4+kZxDgMp5bxrkKGda$VQiC4LE=7TU?xaGS&K7NuWgFnDFa}!J-p|-o~ zJP=|Qb{11xq+uJP=HXFJA5SFx_rDt*QlvU?X|^;lzI3RV=f!aO^1GFDT?s*3;v;FA z4-U&S`*r}2LbU3d272lTzmCtWL9xnaCV%)Oq%}e%n6_?I(uni{DL~Lfv+T2N#^x!HN~3UC;^!1O)S*KEEE( zR@EOHi}l7(Kl_QB7$&*@?0-xZdLz;8P5bw#v7o;-ju&ir%ehO@^Hqo9@7}P1q1`YMZXRhz?%bed(KFKRZ{w7 z-Dn27D+_Kap|0vk%5>cldtTVnWXcZu)&o;D9F!eyBRg|BbAwtq&-RWinNiMfFC7+W zq+F}{c0eyCWo4Y^>LxFwgH zK&Ph56J-cT*Cke6nsi+KQOkf%=Ew1nW- z|8wavIcU;^{W9#dar9RB%2 z?l0&6(;`~xiT^n0PJP(m8^;UP$IJjCj0@~5|JjB$D7_gC0(xRYJ&Zr{7#HzCHJIAC zHPSInw@aCQ^tKqAh!)HoLhUJ(`poKV4S*NpL|m`gRB%&g&WcLECiv%9xkb@q6V7{p z$+f3DAJkF@@AFgE-jQC>R+nhzeAps*RNms(##m$6gDH#@nj~*ac$sX!J=0HjR55_6 z$ol71GBlbPTKOy%495Fji=51UAR@}bm#kmbd+}ycZLOqiW@=wLa%3LuJ`u`CgU!v- zu$2!eDG|K>-XYUKIXKSxutWeb&=C{}%^DJJX(81P3x)!#5&?pvNQX*LV?=!CG5Cg< ztGl=O(ggl*j1#~0e?H_VXu-Ryy35t}iQzRg!eOPmV8f$SY7NzVzP!AAjxWFx9DYQS zgh$?ui>Tz1bGhp<-IK-G+~h!f!E9GjYHE;L+O~eN8nB=(Z8J! zxea01^=f_(RxzY%yN5`au|aJH2 z3V>!ofq3ggeCUN`b%OG^TI|P&QQ47iHACzg1)?!Zm_;$~YUVV2e+ge;y zmmE(M7J)txZ+J@MyNg9gz2bYxqQ+4M!+}>&`qD^W0em;Y3BE%p1frS4YJnx5C`5P< z(+Hgb+elhX?zX(JLPCGfzbl66e^%0MYHS(s19cG(7yNMMIx76 zS;TeK)z7P}T<;>gFZm!y@|lZEE~2^LmAgl(!K8BdsytDwkoXg zgDJgFID=*FSM!t<_DUtUeBF0vCMC7OA~@a9GwrkALQft|zjpifp6M&`b#AW@1|`11 z%Dm&QBs}F3gq-=n!FYp(?m_hhWE9M9;fKt>FMch8ljc;g z%8R@LXQ2OT?)62T=f-e5I8jomgW)89Fb~q269LYguztn`4O;l+#T04z3f7dGJY;oUPuQ%IsnxiXzs=U51Av z!Wq;T#|N%FDeqAv%DO{}Tfg{!XA$QLc4YxT!XEfNqYxuOX7${Q=dwCxk=%{8A76fb zL!))is1sYxCm!F6puR%Ne6sAn7~S_W0|Hi}rPAG>;G@e#Mce-_cY|KCLYcF-ghrvP_Blxwk8 zD2>DY;NAx{Xuaj{uU4A~MSk2CQo2Y#qG&DAeV*mA{VLke##T|5_)Vye?_h~=M$qQ+ z#^eY%@=)N|U=UbB_OtH=^@G5`l>-b&4ecs=oc>HU!oajz+USUEt%9-2aLe+=%k0_A zPyQ7Ra$vx(_J0l^%D3;e@56x%Xu&A}zNhzS-Yg7P`)Hy5WimgZCg&tWFzHD$w}g#C zgJ3a##H-X)T)fYwwJ075n7Vr$W#I%u#I?7D{qA_taH{lYNMtev4JCparng?n>HzU5 zaIk#A&`5>ib1#KX2okbItlL(oR^-nL*6Yk* z$oJfv+qu50q?0yyAB~*XFy}V@@n_mB)W8@C4xf;ZfljHth_YGB4`a!M}5w@6LycNZVMN10Rtiqr;&3m>Y_ss!{?#|$U` zIe?-*-Y7J)RsDjPP;(|N?*`DR??0QI-Wh;)Ow1?XN7|w3io(0rE9^?~DhPtMFis7_ zQ1?evT@>cL46u%zx5%#;cro<}P7+YUlUVzy%6K=Z%XU|BM-tP1F( zcf@cy`r(N)%FE^YyP5@I{$xZR4~q5}jz7SGAsP+0tY0=h{O;EX=42fH3(!dE7E%_n zQDE*LN`dN`ci%shHBIV)f05}zR);GjCFD6h*9~26JD9laJWvVlQTy2DGCl2_e12Z+ zJ1&?!1>)Q6$_PgWVPRp^&jwLGE;Bkc%wac(eHYMiYJ?v#SC`OL6G)LbiS=(ZiK9tLr}`-A01rN~?C_f;w(6Rr&?&IbyL!fk^Nln&xA6Q@Q@vpCP+*PpW zNqgZ~VXNQuO?e4hh6)X9=WT>K@$ut~lcTGX|5I&?D)~iD6~+;K2v-@pkK5RuNC)BfK2gwYOfmURU@WZ=ztpu7)iM zA$;U-nf+)v1t5qits{Q$U+AZqr`Z!*_*5r!kB&X5RV6-&bWs2H@P8cTZZe2BPNX@I z{EH{-AS_J&lq{8)SCX0{+je&Bizhk!;aBhSenfxfOGuO-rc}$eNoXKjC!Jf}-0nhi zP`y(M6dkJ1g7&v@y3(oecHOtu3s9x@eRWD!)a@mGkuO+j_{Fs^0l(w1l(=;n0|5W) zf7hv-ZeMg?5`~t$-;9#35qf8_eY|UCh6l6nxd%*VMh{dkSx2z#Ad}QODf$pglR6Yh z_W8k4ca7W0Yv1iRsRnN}Y-1JN_vVal7Y9HR2iUKU6*vxley?P@xe^V5H7X=AB3`sbYBiwjWa%JmGYt0n=3`4KG)^K3d+Q;HSOz#EN1XgXn zV@YLTe^z+04yZ`fSAr|m)(x=PaXVHl?SH()L<;YP@)A7sw7@Fe9(lAlF{%6!0DWHI zgFl=I+4$`}1V%awYtb~TIj!&`7Y~tx%YA3GMN9fd)rs>kt~bw)x&w9HzD65nNiWe_ zFsxS;yDTg0O|!RSg^(Xu0nPmdEI>+SJ%0soAW3=-kYy{>7RE#&m#9m8btlkSz7x|_ zM3m%9dT#$0rp1Zxv+r~5^Ch}BP679nD{HHy!eG2(OPF;XF2iWVyKVb?!djtRiz@wT zce=e8h4qC6FU$Z%r`9_VF>7CeKbpa9T&HV7@JU2mt={?eJqQZInEKRt&H0gh@%COk zpL>mc);;H&-}e<)w{X;$P5m%C{)!ZjVFW@o$4#TL%V8%$Byj4q3ea>w?y~dS%U9_y{T}%1u6I2=;B-X9*LUpl#B0OCr z)0Cw`Y9N73q=hq~bEHUZN`hW2|74Oepnm9D&nzZRK!f%F=qe1G=0MD;=+yu93TBiT ziTRH{R<}h^rkhqH&sc=qQcZOyTGWGS2~wuZ)w0-@J&w1=2LQ?{mP?brTa3yh0shJN zZPj_@8o+x61hKs13mxXj7u92ALf>u7i0!YM$-MF{8g)|4HH?jS|MNw{`!xFuITE5E zVe`*ig2_GOYV8Sj5Lkij^MVNDB2kRhgc^xFmys}XAMMtVX z(N+8D&7~sB2oeT%LJ7?fMd^;7Op)%=LR!Q_>|7LfFn(mx0<0YwG&k2#c(CX0_= z>GQOhMesk6o|2auL~K*?q=3NgqZrXMQV`~tqc`5Uy(4{)U&`w;_r=D-TE&DHrmHC; zv_qWUU9Kjz^Vh_rFgoO3xGKn<#0j8kRAGUE5DtPxa1$uQjk?+eZByTAA31KB^P$`wA9_6 z-2V&>ipT+k7r0K`LL+PYbLDC^Y|}m2gLthm61Xl_CwfBCsuP$G=^4rqbY8s&-j`NZ zR>1G7(BT0&Uzg+_PzW?M9qr7ug8)Lf^dj}8U%UeEvJ57%h*GI|huD;d6^0@;pUKjqwXL5PKCaL)t8D@NBC^LML;OWflYmdTf7tpXwC z^M=n%u9jJkTZdD-aKpbs%)#Avh0Du_G@PYI4^P>7ft$}seNnVnmpa3BQ2|0ZPI`?F znsG0~wM)Q#|1;*zjBuR74LqEUQfNj1M(`6}%XS5|>^Lgurs@1YQ zo7H)LPdkhk(7khGY5>>oOYy6Nr8dmn>c2E!P}!S)?bsAewN^vr90zp1Zojm zmpspBc2Gfb%rEvEXiIB(q+N9se07TP?_i~xRH>aUG3;*NjjmZX>&+mUGq9O4mZ(Pu zx@3G3bt>RfqBQx1N`pUpQX>~F9eOC}H23gdo*<05Dr(t#4v@c_H_adaU1oWXA_vOh zOT(U|&}MI|^Qse{62i46z9}n;jQ|`WZAK=ozVpcmRFdNM#Wi95EE+o2t9dD=8`OHG zKBv2FN@t=se`rzptjmS4+TV%M=jl>>DBh!=JXewldxzM6pW3%cu#$} z^VSqZY{kjfuK2QTeC#He=V`F8_vuX%0H;sM^@k)L+*J{f<42gAi8k&aR@Ev8Jg{s^ zBFHj%+vK(7N>XfMOXpC?ymG>0BE#Y4#zqTXHH51ol9H+kvWgoRU^Rx;=6lQIjVIQW zT>@+dp%79@(C^^+X`&ROT)g0ClxLOWV5vZ(IcNk7G0TeKXO@!H!tU!LHa6;MYlf7U zem6?;6(3eFND{h@UV9}c|_O|@X@3mCUvED<78W8rS+CTW}>`N^6%u>1gOkiCylQ+5@V zQF4^!Gz5Bz5c{#Bm;Wy19VbV|E%PqQNKX9RTd@qA7LtVgY-884x3sx;7 z^L_q_JODTAU1alxg5X9CWN4jHnN5>uX&}sa+WyrIAa+e*98#gUdlekY?)eYhMbvL04j~VNB4-xNy-+$e zKs)WA();MVIeg5KT@0`QfRJ2OJEM-T-8G=iAUwwp5`$Y}UzQW@c!qyXNnV|1st7Dd z%uR-q>IA)P8C21eeF=ae0Hd~wS_CAB zZ@ORnU(Ls&#R;9lYbS90v#^@cnF4JeLk^ayBPkNpdKvModDryWC_;0Rlkqsnk4js% z-Qmw~fASNqo)@Qh?o1spv4Od5`Yds&Q{N12Q@9#Ix=Ll}Tb)mU6uXj>%x?w29WK7z zx{sCB?m>?J8xUDS!a~0=(BcaMnlAn%>14^SnEF_!6uvoeD(NfSWD3@fv8BMssy3d; zoHnDhrJj~r`{D+&gfSpB3yW>1EwtPwOay!|=hQD{ul0jYXJdYPs&3Nf=blvf_=m1x z@j;b6y=3se{QyWGd6ajXJs$lp`+`~)ns6tO(nUVT^n80h{+B(P?I#?>xHmt^%kGX@ zm2vCYQZ-;5{hBu3qGN-Q7br;K5r|J9@6WEV(0CxahFX^TqR{s|iEr~zFm74E>fOAU z-gy8#B1Q=S=z_v*MPaA3toN_RUIUUl8OE$+i3Q^{GJ9+LoEM?YOF+U?DxE+XCHf>f))8x%%fgXnG259?+z%TsWaQoAnWUA81WKT{04iz^g3?3sw z0);tlqlFA%2`Ss?5fBl`)$$mxQ1YAbV^ew(KD2j~t9V(_Q(P^TPeu4aHoR{&;H7ln z%WsG&!yYoYU^<|RJpA+JM*YigLjQRHA>q;@%)G7Y1cAQo=zHygdq^o+0?cw9OdddN zDgNPqe{2M3*i+(y(IFLkf0Swi+%?DC!-?QFbR@1JW8>_}tN&5B981-fO7Q{RFmhfHmLMb1bJu68&FLFg`YNfo-&Spc2NSHj&B=&1VqV0BpkkdR*fRKG z+of4&DY*BONwX<N7ZPjs3*mVo+9wt3NS+=dSCB656Dv_kz9b*0^hu zuFoIu&zB?gmNHi|D&s7SJh2GRLT`cn1}f50$hTiTk7_9Dic^?I7C8NePL* zOj`nFLaYdl9)q>w%=S*xRk}}bOnj2uyGZJ@7=Y7FLUE$F=!jt*g{hc$R$Zl z79b3S!0!sa{%h%beYI^9rSl|c77z1IGt}4 zYX1cTK1VLz^Qfi_0E_??D|y%>F!FAcViagKccGjv<$A3Jn(SXS_P9;yB-}Mns6|Q` zgnX$4^bd7S6r+Ix=wB!h9mhm%`Hb-a55;wos~KvA4nyD2aLKhCW}@53xq;qfAr!`F z0hcm75U5Hw@wZT{i*{LCGb%kKyb$OZ){Oit;*bZ#sHx0ez)}m!UA1!VJaGdaau$LM zH{nK9q>o|W&pDUhZn=60@tk0Lvlf1j3w769;NY=Xug$|6R8dKH>vU`N+iUORuTF1- z7u_{5^Yik4T_Q*nE{Kw^KLM$Rxl%_fkUKfgeHq#8`|)Po2KhvGpNSBX&i2`*p(V=J zXk^RUH!JoNjhr6M`&5PVMVM>pilz0I#`R z3ccBy*MvY=$I~lSmw0>Oz1AnblbSrl#`!2(B;&mLK0%fsQV_Ag_-inQJ28mw7L{(7 zLa|{dJJV~|cX7h7p!yl>GEX^iC=Fkc2)N>Yd-G4Y39Qz|fxao_7G5B~Ywzdhe5u>N zymGRpx`d0U#OMQ^siAA zS?gU3Ebl4U>2yFVaH{mWXm!jvhiTtg{ROnF&u1r3DK>%TMNKS`;r6Wafbu>4(0v?E z%DM0HuVxP@%8TOS_Ov#?LP!lPzqGTx6V|kF`n*^tp3N%i<80ojb;z&%CGFKalN7ED zyils&pF9QxJ>KMt9CwO3r-Cy~`UrUZp+M+es&jwS!W0R4Oe`MHGj_rdg1VNZs$#<@Xe%$vFH;C_+ zVp7_%NN||k33*s3V7k-!xy~yX!vctUJ^X*ljiOkT$212&4za$H&p?JqQ?LZAPV)sX zJ($`Dza*-*dRXWvRcsN43@#7968uhew^SNCR2XU*1gc;FyV zhtxFc_|7vTBn?H^%Z><1?w9sH?B|;r+Eba*%A^dnTNQo$dq`#5>tLxJ_44j6GqMn^ zHz=W`NfOG9@WdG|aehQ4K_zbA%`1yhAaeFGgl*Rh2zX~|JnCD2y=M3sMYrX&qOF(6 zJBLTlo?%lo-}^IIU2#!@^Y3 z#!;bkA4Dnor(O~W6g$`d*-ih1Epx;{Ziry~Z*|e<%c#N2Hn|=^p`l>YP*(p4nbtq~ zWyFJY4Iu1y4(FU6Y(&Kx+q5&8Pm(Mpr4&&~kP3|`DI3#N1w`KF$@0tA(AW5#7$ocv zKQ`MS#t-MY=?GZ=wrzaMV9Dtk%t-d5eF|$NPYHM%!To)e;Z{D0%Tv^=R9R<{wZsAV zHp08%S3buOuDs~O&cZwT+8eHdy}>bC)@}AeUS5ycEF^B9;>&COmaqqfWL$t3Ni&%M zIQwVieExI3LRM9NN2NwT6=4T`fAo~zPr}+SR#lwZanKJevoJ3*@l>ekd&%W>$DT~L zy2pqx26la8zl3s>m2{|EhH2W9kd-cIHaMQx9f!KZGazhN8Q*W8C3*fi?H{>pmQ#T* zg}P+RDA@)0=_oyF3b{OJG|WUPw&+)MzbF7bz~8vbN0wcXdTD~3WD<_fxdz{B!dlRK zm(z;KJMw{i^1B;@cCmgO416gD41zGaTtot8J2@I~L=Vr#Jb6(wUo6v9$BxH(hp=((j)i z_z}eyCr|HBrgnOWvfWS24G(GK8wRjSBbJpMVgCq}OdWs492YLCIOJ8g4{A#c56AQE zv-ewB`zHo>>bE-=rrM^wt};9nD*j*9!`yCBRc1ArIY7}$Z)H>XbeMw|Uh0%XVucZD zj4Wz$Pn$W2yw#L&l3MN)+<-c*xiSC#YQ)bust-)$O3eE*1fp}Oyg~yBkb8|RIiVyD zbS`H$M_xu&);17QIgT=%uscZWv_{!diOv!%JLdv8`T9V+ifRT1j<)TwiNG@_Y)u|g z6YrDlT&Fs9JFic`YCfYCIhqo<@absn{OGc-s-}d8dJGPBzhq%rQJ{cTU_7H4?#~g5 zxtz)&(2Aolq>YduWhhM!+xO7-pK8lZ-(^C$-f?W+4a5N2*~4U{WZ((7G*msDv(2`# zBCjUQaAV6Wl|NjFz*QpcL&%5GW7&|$u_8)KxQ-Q>d=8EHe?^VScy3Q3g!sTyfCvRW z`mwSSZR#M5MQ!eNwlRmt)*oREj1cZ^7=<}L`73-9Eow`yGDlP1feXS0zf9LYW|rh3Oh)J#fjGv|m| zkMeuIRnLV(Q%Cf3pd=0&@u=_`<#1Z0y`zb|PBnbUMA8J6560o39R&&9nx3ci>u}9T zaJ!x7>PFI?N_X|LqMUv!_$P9>!<7WIyu9Rbl*8g7joX5S&2qySAl{-L#^5A%m>zRN zw@%i1p?!S4=LeNaDP`{!R-jQG1AVtr1urGT;i^OtNX&va4hQhmy0pO#YvB>`=( zQw1Dc0t7CCco>%i_pd5D0erjw7cKMR_>g**_Uz`AtjAIMWa2_e7Xon+B8=s-e`goS z(gI+Debd6Bl6>n#FzL?4Z@onRse5R(2g7C;lCmtW%N@4w?YzeHZ0yKT`SfT|Lz8B# z`UllN&fCE3t;1uHj^Q_3KP#!rV{IXGl~0s78L!LRjJ>-*$Fe>0p`XE;!%kCAX_Khc z6hp^+5E!@|+7-y(<^zX;qA}bLnE2%DFFdPALVS1f*>e~DDc7KPfpoZi%_wcaAAlV;>UZzj#4S0&8L25_c=!$>_idc^|IPBqERTOW;%I;tS?UmwiwM zmSH{hz_3qnFH!iF^YsP)(ZH|Zyu6_4oYHGDc5fkCCHZEx2oH$X9q=*@NnmdC3sA2$ zYgKY%chl{lu8FdaQ2esqAG5gg!)p~_q|cmQG+V`B$pIOkZK*tQKx%B6oVM+`LuZ@Q z=fIZ@lhz7LYWyZq%*lf)6;5&V$2OlKaXuNYOavdXN~z+DvlM*8(cahZ>@*xGIEB82 zZaGt>y9OhmcsyD-gEl$pDN-JZUEV{#uet{ERclQ8Y@dgotk09@{u2QtG7I(H>1IyG z<00Y8GA*vOQY?e$fkr$Di4I+VOZe(OwRA&W?k0$0k|qd5%SM@;$fkW{p!Vwtj&Zgf z$ub^XxJQI#VPQr+miP2}LT^&bApeAF*~#H{a-fbXxDBL6NHLvDCu=;mYI%;m*|XfB<}Cn+5Ou3L#$hQ5Y9fSM{?e{}Q}zIAtl?~B{Y zhL01T4z-?h1fVJ!gbCC@m+=%7;{2%XrH}MHu3b=gv|gZU8()(4L#m(TqWO35>Xvyp zBG%M;1sPA|;bjvXGpNi~rY7h9^4i-ev-e!5<1DWd9IO7kuCy|Tz>7*SOo8pY7L44gl8n})bSpZGy+!3RzL+O_t0jJ zi-|?e5T5VxGBbhqn7oT*z3IiSTXW#WjVZ*8(kI_e+esFlj{0IQ2<3AlkB<`DMXj5> z&BrbHnSETlUzVZl?dEjqHw`yGlnS{$HB8|R2DSVOQqK2^8HX}=pF~1PC6Kzmjd02d zDItDG_o+P0cV)hQP~V=ffN0&r?Pdi;PXS{lM6`Kzb=AA3rba)Sj#czeC%x|%>a*HL zv33<&Lf=tTrN#9m5VdAVy9orncx%nt2$xB_$G5p#1A^P2`$4i;WJLHl)l72nFNV_7 za$KqS`dOBMO%fAyUTCUO-DY}0A3Ek-1QM7}pFPV$WdRajy6Tes-oakWSC&h04^PUW ziMsq}U%BtyyEm5|DXQgZ)XSabSkZcgk*IeE-J0kjH%!^M-F}FLb-BHFnLi|hcIqd1 zIGk5f`Rc&@cdmAJO^@sKV_ujXDjlpnis<9d5ekMy`Pda`FC7M$#N)Kw-GQ@#39wKS zj)Lp6ooS3id9}%&2o5rYu35F^G&!1;IbZa7mIlj)+x};iyi3St>=d`PeY~PX(1{72 zjtlk#Rur8+3|;nL}Py4TT_OUBZBT*8}e>oLY;)B@)?d7PDsFM9vk+ zsV{RsjdfZeo!@^q0uydH2&oWtH*;;#|SY@lJ|d#KlIvO<->xZ6dXt< zbdK@K6744k))3Oi;9F@y$G}ps8zDe1_|lAo|~v&EGvQyXh#S^8i=n z?O!Dzg(?EU_jAqlMv3ptIi8=iMjeY@8P$3oM@1rV4OU`po1B7UNG&Fc%r4A(i=QaP zn>~m?d;~kS`H}-nY*lyZ)Yloj4a{Yn4eP^MiFH}aKm06r64`^SsS{Oftuj@k5dklYH&qUhBa=aDX=6Lh=E~SeZnEO&AU4Se=X?u^)&&$1I z%o2+PcluxMj%>;3W@(p5nJg?aa{o#fr4p;u3=5B&0k%geEXYq^YZmXiQfU`di4nr| zRp|>guO-#GB8+aY!!|(^OKnsWThvU37fbI4@{~oTvz;VTXe$jFdj6g}<$ubg`5pR6 zzx=qKZnNn|z5Y9EJKnDXW_YlarpxX~xCMidwc1iM^^fK5`R9O4v}Y;d1(itNQYvGL zJms`0=uhdF3ry;hKMIc_{U?faZW_c*m#@G zztK=uFf9m$n|+%XSQ6`XsFKR|wLep1D~N zL%%M}+2CsZ^NZDVuisha47uu3*0P^+0+Eo8^3AcIpU1TxGExT*guIm6&iTWm(}?e= zGwbKv@U36I`@&wvXll~wE3(+MSUPl4Jp@hQen8YhMc2V`nmn1c@{zx`m(oVJ=$ z_|x25vL%vali;ELl(v=kkZ4=*kcAe&aVA`p3FRw8k*fMF=%V|6chN-GD|BONUXjqs zh9uMz{Fz>oX(~Ap2ul(SiCPdHm?@lJdyv?iKQDlGz6~!Kh#|0->(9sG*4CYLI4SOV zb6$7iVxf1g2G1KHht`4|wNjRYpG|EPZ}Le8K8^cIcbUBQbKzI|(yL?g68e~nLF@O@ zb&=N92(7do&}um~^yHP=dxjzzhD)x)u?<^lX1i*XNaaF*qS4>KF!PmcJkBJ6()%`> zsNsDENNtXL(w1$y$x1hGa@1)B#HAc}15ws1Qg?xyrnAIpo9w0cEI>o3a}wYohlXc#`PFpeE_dCi z3?dgE{lVu=v+DPH>oC=6{f+qY&0V_>R=s-)y))l@Xa3ZfktIs$PgibhZ6)}p%0pnz zA6tz_TX0~zSq#$KP>t#`&^|SneRbJ#w86;rZ))>VCsw4qL zCH$OxOXFT`SLw9R#KP|oXs2B?(IfN9RKE?MzmgLvCOEySyCT+mZTebTlX*I@+lJ&V zbJfW^iwBtDszqG_T>{C|1hBGg->&o6<(M5dGJV%52eR$u4sW2PA?xX~=?>M(lc*{^ zA>#@E_O(vy@of*j#FVE+V)qlKd!bB$UVD4DnbvdHal2lj*B`u5Y-OP@(l+*rdE;#e zM-!TvMK~b|EQ_%u8*M5Mm!{D}%K>}DIvBTenLV_KhdbKpP69q`v`G2~_F+VP>^6w* zg2mo81rD}gQno~#DVBv}z7f%8ylY^%ivNu6$Y%WHkwkcCnG#}fx7OTveMl&S2X_D6 z&Ua}&PDIC`4X$rVOo75*bDEFiWQ_0+S#QP~X068uXcG>Sue8{QL{ z6_!lW`liLDtR?N_I@)7&^MFLvBZK?LjqL;x#@q;*iS}N>)aDM)x71s8&_2NZ<0Bm^ zmUDD@UQPiJ>2rm89VdgwBDd%e;y=+dR%VUD$!pqyAT#DqR8M$UMb941RK0GYrjNW3PvXPvc zi4}D|Sok^62#Q0{qTGxeMJbdvO_;Qo><4c-?{}g+L^$!~$@Vx&G3ZtQL*Ztgtj0f4 z)ihHO(OmSNF&8<(ju$F(l=j!6M(wM_QD64(}mk)^A4-Cc}UR$D^K|A(+n52?o{ut;lh| z<#(gPsY}I_WGrwd44QydW0SO+=PoIw$q$FXBOq}i9L*8&G?buKPS~?BZ!<0nSV!A+DpeS#r%Jz8)3%M$4WiwW7yA-g#Iy)JyG4vYGY=$ro2) zgI6Hd!j6TDZN^O!BD6(91$yHM*Jl8QS6ERcYJ7Oj-$=U4@(r~;f_I0w5#Dlwm7Y)T0H z9(XX$$pijrmU}}^pLKbE-}G6;?@XpX{#EdK8roZ7*~!vriqA!h-ftFfipY0wt}>2b z@YRk!{%A)H>%b|MZN`T-$eD-2wG}RTwd)KQ zQ&{H_qT4gxQ4#l4?1bk%dJaAEfE=5ce!IMlIB_r#66jB6A8U!9o(fk@cpGE!`gkc6 zwRgff2%NQ{Y;}f0)%O-y6h z3XLm!sQo!WSDU_DG>8yRzbBmbvHJiDx2=wH+x+Sw`o~6U>2W3&I>$8pKGNuX=TawH zNKcQSg3&ePoxRIu;TAR`jx&&@#1fCyjk?E7KPJA_J(#?yEZG%#J*CM@YJ&1{Y5YJ9 zwZkvrwYyyoi4#volsPjKlQ1p(nX8NKeE-O?u8+pAx6}1*7Kt56(U0mnPD&P-1+P;$ zrNN--ZOISXh=3fTtkpBCSsi#AtLb3q4*p3)?{eG#<0a;aO~UFmOkH>E;gfUjKLS-z zWQW?mQfTPB^Cu&AHPRFpW+-#H+3nKf(fwNI;Y``dcZFq-v^(ep%IH`G`}#^r3w2TS zkET9{14u>AGzp**4(@vtX=nj@o6ry;luKYENOH#+mk&;#7HWzs<#CF}MaPRVgQ_2s zP-gANIha0@O>j%LpN7hHJL6IYi1 z)-$nmXJV@g1O1O`EoY8>@A*WuY8B2T4$qHw$C#IH$T1D_rR#Ik#q{8vLE=v5x=>;aERc&#TM52jPG{@d$k{X}< z%^E~MC)GzKHi%!Nis{N@>}9M2k3fU144|1{VqtHRt#p`9*pPhvXT;a13_?nRG4%If zMiaOAaA?>P^G>IcDizvelW484U zcAxxfqx*z_?^Ovz@ z9?pu{Vw`M2gG*xiEF8!x(>L7YOSsrN-4+-TNgB3RM5xzXL$xiB;8{6KypI&zdF|Uk zP9n)>lr2U5`kS`pN{S0S$2Gp6<VPDM`h)}zDu-+Kq%Yh+tTKKutEr^h9_ z*rs}Ft-)_co^Ne%u{A7~b3AfzR2*wQ39whp+OdeUOC~O2ptJ)rMrZf`7D0`a$8gS=GQD3WO=ipAic<1?a`sQ^QJq`Zl+~MX!o^U)Sq$?(~KFd91 z-NL7qbyZK9jQ%g;BcEZKO{`HEI4r$FeNd|;@b2;eN?;$~trzKNl=FcM5 z4jD=x{6$#ref;al4Km_OK;Qbl;*ulLQEj0jRb>p#Uhx!^faJT5ds# z{BrE+)?K3aZR$oe!@C-zXz;FYDN$+B_bwi#F=D{1Gn}D<>8wlbQ1T{Pe7r*5G&5cc zeDZ+TwnC3Fh=QNRxMW(^W+mSx8qw`&Gh{PL3$bV^>-mcr{51dB&+xox8>yyhxHoIZ zJ^aJEolEyd>e~}-(2lH)7-dmpH-Ko0+`#WC;ANh%VKIfqOX-ZunQ)LAr9*~Fz>c*y z=c_`~9%H=c(cPbe%2X`i!phW`*pn_XPW}^sAlIoVX)@zvEB|7ep zd35rx$8N9KdJ>$nS}emCQL|Fn&I3VEE-l$eoY-95+5ZNrBmlHuuZ2jD+zA1&yJqdFM&?Yi4uvx|4%9LGXg1e)!} zG9+RIxgb(-H{6=exAqQvW^uWpr(QEBs(rJp<(XR2#1qNLe<9 zop3uk&Jy~Sl|Xia7+s-JEV)hivx~pN{sk_tA50IH1Cxk{il5e&6+8D7<6Hb`3b&uQ z#_5!YDsj{xkCrBJ5q+^wLRo9Jcd#$%xodu5E@(Iz{&dK+h3((5An*&a7gjl`IJTr0 zrr8%3(=eYNn$Dwhv&-iqAfVDP)%fv=r-%fUaNIFD-bqDrzw(29NrVUQNYWymIT(8w8T3CR{oY#9RG2FjYJ5wmK!**Us zPg~RArafl2U2K!QH2f(9M&=(m={ez*#ONDJq0mKB;r&IW6X^~wH#~gu>&vU-2!H)o zrlr9|?=XBM!U!ga!L1F&SBoHCK~gP}K#$3RYXteB(MbU)RS_vFLY%hkjY=_5j40#m z0K;iYzN2=AMjwSvxB<4m%84^yzcUF1?%=U%w`kWb&EkRgVs|f0SR+GipsbDmdx61D ziF`RfFwbv+YLU{YAbCxd{tQN^b41bPy_ksa?0J0W|3a7=az((cg6luj)Wogl9Y}!y7uteJ7Mh9#gCAz{|R`@*vkcTbj6X;%T}Tp9zFMdOqZr#dj>Xbr+EuU zhV*;{v3LAmx}H*g4R~?*$uS|qjL2)iOqc|oge%<{DthT1T2&_4n|#y^C^PgpQSpfX zEx8v`rQ=p6y*0@p9nkF7CW?2V^gKFaDv)2V;N(T5Tgnm^Re|d!(>P=}N9~bXky&a@ z?Rb2d&|TGMa2u4pqlpWuU7?>D|5*rXIb8p@Cgb5`ykO{js47XAVHoA>&KQ*Z$pXSeQy z-zx5>g#>npX>nFo%qUph(}wky^-a6W44&5^VvLTAVT**U zn&2aeN8QpC1Osg6CmW|WMh!06Q;83!f2_VY-Bq(Bh$WbN14hFw(0oqyPrnNJ-?K;A zq+zZl7JcA2)B>fV126~OnBo^O#(b{gGN^-`8gduzj(H=2_Upp!qRJ6=2n-e8!Fm1> zvO%b)(FHML*_r(urq}v$-CJb0k<4!I`ogi{0%CF5)4>|&mskFbdBM2^;_=$)^Yxv4 zj4LT6mKb-z2)6Y{Pdx<8oVh^$?Z;Ou5lu`=8L9lmm8B&^#z6Qzceo=;k4#bV#d`D1 zz0H@I(pK>BJ_pWseEH%}tRLfp^LhysYF2`E(03lX<$?G%c*huje<0(IaRD&(%$Zk9y4)7J+){lQNGub3DK_~HvC+->v7ubmJg!s{qJxkjiguGW-gqX>IbaU z;^O3N=6$Yvqm2X=8asSRp@-)G#>ujbUn3)!%!NZ!P;kZ>@}I7b+Aa}1&18V(ueRpe zkaA!&%xQyEiFftY;CcZ>Vb6IZgrjYGaH3;EZ}c#efkfcW5}RTFOLb0c+8-Krh6wz) zJKybh3x-WXS!&VCQD^4$;9r`U9SG4bomeRbaoV~=1ttq0{+u~V7fuVylZD_Tabz;M znPF0@l<*wfuv3{Fal!1>ZAY@YVB5i)$+5WO8qhyr6{uxf4)^(2GSQX)#&)|}^V%tV zS87kp-y(L(@qK!(Dij(!WlS-CA~f?Cf3GUq&uP%FhX@=2aBL?%)ojb(RIL69?3600 z6k0@gsM{ThWkXVKN8FcXT*H#i4&BLv_X~@1RY#BQ0UTHt$kV`!@ud#H?DjpDnj7>Z0WVRG#zrx2HjVH(-q$pS)_H*If2-afu+5`V-g>Z*+C}@F$!{w?0K2;hhF32aPF`&JJ>^20R(Fin)Zj;SWtN?- z0KTEZQ8B$XZg7yhL*}L4;c3yi(HHg8LD4UGs-3@^HpJv*QxPPWl$zLs=;^J`UFs8O zL{N9ra!(WZz%^+Rz*M|;h8;8SO+7q)v@4EbDiPh1eG&Poff^ajkqd}ZK8%1U_M9Yw z0W2gnAuk~xVVU^JYnp@ArrY&9?a*CkSj!h#EnJmnX4!9hLgX1e|M0xm#WArUfivv* zFZD8uU0QHLh{pshxcIX14q$V2c!aYrrGxl**TOSLu-$wu3LsQ}UYWa*u2n_uyE5HZ zt&2E6IT>>7HqME}T#6(ZI(h8MQ&8DZ=SeRAI>LN%Mgj4uCVIxlVqZ-8sK`Hxf9ikA0V8c;q#1Yy7)upf~%xJ4tVHY1E0*-$wffW8u> zjH0SHiW3#@k^QPI?DgZq33c^r6IdA(Ul> zZ?RAZ0o?(41|8kW4$MCRXF=&J$x7+8^QQNnWLEFv%TG}KN=(x*=WQ(@2)MvB#^sKy zZqXtL2e2X$ls$SAaP6*W8zQdxXxBOy?FiR;C16`pvJd-M4p5%#6p?%E&E9)IyIjH8 z5L9!e3$>>6hd=s?C+{~i%#UQG@C*q$>6A?u=juW9r__zgemWBAYjRRoZ+uX3=zA_5 z9mE&{yxXGU39(o?D0x$pG~WN)C^#n)aA)))a_5d+t|yz4SaWl`vv#1Q?5*5M{q6<9 z$w5Z`+I_6Ke!Rk*pTOj{)i245Gc=g8tP4wa41j8A(~ipqZD5Ksj?)c|UJtPROvoA4 zp9<}>nQEWf)6iG-m5VA-VKK;0Df{k6+o1E8I*0dJ2>8f=$1*r#-lAw2qpdAty_0!z zLM=_;y&@;H9d(1~6+ew^%b?%?sMT%i|DO9TWc`8XSdP`&>-+fvi`qj&r8clGf-=#t z$j}>^U$WdjG)+X+q>@P5ue3-#h)ZrJSc(iOrN%Y1Ig1GQXo?IrEQrkU&Bp{Fc+5l_wIV1Gx4 zxxOg10dEvasKfJY2`Nb#=?Jz_TrqL0KZ;)yxb3tepxSSzNAD6o)UHuZ`c9*CBK#`O zQj3V6(rYYMejLssWYg77+3}o@-%JN34VoMJUcEk$nT+jK1u=39MGb(Cs<9dHp<%dwaq{D<_USJ z(gruge$tkE^yozc=WNUgt+oWemXdKwyIKJ}&galG@eJUm0x+hxA<CN z#K_iS(bhZMeaN6?{So+68qAi!OkhX>QR>K0X&U@_#*sLpq9E6cot#KBOh-`U0tuWv zO}2@BA5Mcn)|f%S0sJ0S#$jK#;aUzWFHb)zFg)1(adA5&z6DgGU$BGh0ZrU)HP-u? zf>e;wD&n05#84B(2@Eqf4(aO)W$L!4YZY5ti}ZA-97gI~&Lwn@S2AWXsr4XBNb805 zJ#CQdm%CHodN@&g`Z%GoL~%%mE=kRGHm)3P-PLyfzB2+CRhUnwG&*jpoV>Xy&A%{k zQFZfGZ~wyS`sS}4R|J)qWNZchF%3zFmTHRH`h!0CL%5Cx5s95}+prC`)rp=#MpA89+V?Xe&Llgr z_rd0jvh{3mwZV$g7KgqM_f{9s9ebESE@r6b45|`}myE=;XdsV6%8JN%BdGTH0>$}&3{$|qCEGN8X66(yq>D4`=PfVouIG&*^mAC5=LCy=`!Zz5B7K@3jZMV9Ie0w$=y1AJACdk5#BK+NTW(intql z$x)Nh^1QVgJU@@>Ew*z*_lOZ>@G{?CDzwSUBTv66L6j(R#3^k*3F?U=FW?;ngRDE} zLQ9ZNjHB{@qs&A}Ok0JQsZEN#)tDYP@&D@Y$>JE6H}0UN0`oZ`*4sAsge^P>Vy7`6~NlR89@1Pr&(_3D;wgNWI_9joam4Z_h z$JwplkJ`H9YC5`x?&0cJDSUFnDU0QZoQN~UW3Ly%s81u-<8%1 zFhNI5X2;Z4MY&plHKjxe6QNy2> z+t5UEXTh*js>U0EMEP9c+Qt%pY=3{Q+j#`HT{Dl5Jm6LK#ZbI$jQ=ny z(&Q%Y;l*imn@!^_zpq{8ueh*DDAreqLnc7=Oua&k*vd5-jYMeKP$u36=j}gOQ|*gI zr^(mLWW|f^d)6XyRE9_r^(wdZ~5CT|Owy6F2)9a(AHgE&v+x z{AO)`PUZbe3Mizi6~waI%`om+ewZa*raO`8egz|tWu790YGLIsPI^*It?S4xr>{2G zRtC<9T|#aNQ-oRK5wg}q2vT*|3)k0wsO3Y&a-^lIK62+>&#rs7`qSy~K- zr!A#^6;wZo7!E!(W0wB$Ztxul{0nS+JouOyP;!CTi``4cBRf?Aw8Y-h`H1{d6>rIKQhKKUB!&_Z$%4D$%i_;L$eueHecsXa0{Ce6q4w6jzEG zr9D@BOYI>#J>h@vP37-6#xtO>61%T=0E}d;jjQ<;JD5<;SoURhe`pN%6D`&*ByNbk z38f<^gr`8T%U8P+Yw*40Hd-bmbu0K~-%h%9{Y)Rb*=qM2uA4cz=+Os*1tYAutEz{2q~i|C4T;jJ$}B>N}wV zmk%hz?3_$qOYUNi%?V|eOAx}*0$l+tk#DlL9?@~3|JJenjY4l>lW5lJz(VPgDTjDI zDoG8shgVyLWNy;H>= zA9IguP0)X}k^h^M?TuOpU9`=4u)jKhC??xE-hrY_;}2e_7^HK6hGtoYEw!FY^2M)&^H>)YHvMzHKLPF~&l?Kq!C@xF zfq{V|Yar5)dr9z)|3S1(V_;#YGeJ9RhA;Xa?1+b#SB~F})vwaZ$+-CDl1n~LHg(7z zhq)u~omZ;L!eX5wS+Q|$&t%UFQ~hz%3z$ngFHl?o905guuez)47YBU~BD{8L*9a(; z1u12zo>67LB)Ll{NNFykMQ-W$<~7XmMA&M8bzx4kywae-*Ccqra$P%A2mW~SX}Gvz z4eq(W5hzl}JCx+;N9_iIAv*)wRP9TQO&L(vL>0a?a}Wn2OuYXJY#VUGku^EzKw93~Xm&AT6*4;$? z`1okcF{>eryCJV%J~jV0M^LgY3m=LX**bWz=TauiU@@I6Z{70cnPM5N{Q7F$$POKT z+(Q#dlt-2x3R?-HX%LKZfKUO4PeP(w_-YD5WXNWPiq~ECWO1P0U6&3G44}+UWMp~l zszAf*5XqXu0ZjRx(TQ}NngXlaS}KJaa%`-SMM8hxZ~dG(B5r?_(2Nhrf&g$QIBq0w z#%l7&!KDl^libj<2X~C$X@szuJokUoylGVRB#O7iqAB(N|A;6PvA7uH81V=zj+^UV zmF43VqqB9YAKntYFj}=(GG+XQ3#D#I0EI%?wQ<8TN3;zVO$H`s(+*sDu&Q?(H`v_4 z@N#1-#Rg$4Y!Y+@m{dN>CDh~0`r0y2Kr>G7Jd6j|MHwi!^CG|G#3pg{l_dFu&*c9I z9HhSA6QN?0oz&FWk|a-Hzfw&oioby6DA7UY@ILXl(*w zJqsx!dJ(B19Al$AV8-)Z$0hqlmu8^mdpB#NKkzy(-{cUn*u|8%>%pOI2ClLp(cD3| zLZS#s+Yhn^Ew$up9Aw$PXJFqYgcug=11XxhWnE(|)8XpjY+ooi1b8N`+1TG>5IBw)q3*Z+3^PTnjCa=ZG;6}#&cGvN2A z+sHa79rZ)Sf*Paw6-Jzh??`7SlRoRC(E>DIJyR`$g@Ba!j@RFR4%|Nh>{u1yk~;^ml#fz+kx6z)dtfVc(cI?@Ga19I84PYM z>2ox~F;|UlUA_q0nxBmmlixKAKPVIYK?~QXKPCQcO2jo1TpT9NbSASh8(ww!Pj^&M z8)=h`R#pNA z*Kqb>*bpR{RDTzAw)$KTxXPrimO~>xH-Rqhn=)3EVCRr|Rkc}X5K@PA@E~#p!L3jO zxHpCE?!KpK8tXTB<-62p6J0ZDXnf3k+Ei>3 zm_$?;;%kv=+OQGRG>>4P`GWKYHda@Rdk7)OX?WF>_04>tVS0raIF6-I(I;u4Y={8v zI3iEDpT-M9jDB9>uySAzaJY1dB5RCy%+m?KAR>j1{1CdbI&@#XKa!nanW8!n*->0? z{q?n<|4IVm2+$HqO}9;DFfunw&6MnZy7pz4r(#l>4rNaA46UqnE6nwY8UD$lP5RAxC#^oJ+(Rbp;-C<{M ze|%g*StpfPL_r>UPl}jd~HTcEO*VxD?cV z!fI8#+ft9Dyz8(XfRlAG2&BrEdeDD-gN?4piHA2>9SV5PcZ(Q;+EMb{C$K94ziypD zL+VkYUsIRDg-Yjkn~tn`Ca=~Y=H<2HpBsSWNs;4L`OONExROgNeq~bTXfEglEe&rz z{U{aYN+t6I_0%{|-Pgsk|BMF019v`Ve@7?7ii*XsfCO@3`t0HGU8DNFF<{O$wa81S*ydx-IZX?a$&pDl-+WGl^GEig zlR$|Q@|8Z?mLq>!y?x7h^V`&dj^umtVXh&;r(g%G#4{eJ@EdI&-OupI)rA-5Ad`y8 z3mEZKyrjZOZ|Af>@(nkqUc14@9NEMV+3`SWy%Iy@ikDsMX?=z+cl-8FWUmAhdTW}i zDbcpsBi8zGR52te^(B_TD3s^1}ipV;P35GzJ5q`liuwt-RZM0W}Jzdx)ku z({yv=hdVXnN3i1j=)6yzdgaEq4GiQpbsA9@;)ZZ5S1FUfGY=wOu~J3tkt~`B5c1}P zUh9XdQW{qli;nJL##5ffWSE~`F!S;KAJk^#HDOo8PuS6X}+5aFXS=9z>h9ZTH zeU~PA0LTx0(Cb)R&`QF=eWwXQWhNp)?kf=w6BR|WG z#3lj9uNJsrRMdKO#9Vh+vJ}dt*N-Gb7sy#%F8rb6LEmFs@#0sfJ(f7i_;}>)*|kmK z#_3TVVUxxk6bdomvcS^BbHz&th12yAk2L|6>y#U5^kV?Qh~1TtSx03F3-#54VxC<@ zo}&iF5QL&76n0Ouu4^ftl53726r)eUGN2g$a<6$l`cuTKFLARu7T%IE!5$wepXO2Gg+QfWM zXvdo5oJS1_&fVNE=0a}=97E|9xiXim+B9)jP2Wsr_tlS!&8P`9^VW3@aBfnT=_q~O z+Mj8j$nLB8xk%Yog1>0;Q8v|l#-Rg@sDO!9%~uafpb*e&lVyMnRI1o5<(9u7&DHlQCX*?5{ne@grNE%B#9DS zh;KAh5XQQtTe5Q|E6SCpe+{AI0<3WCzQ=lucL-91LQ}}r2x4p+zfzr;SL{iMzL8|@ z|I4K-2vAf#m$vqX^X!@&{f(e?Xz5PNch7Y5Hhi@ocn!%0M~#hW~(LH{mBnD!pg1 z)DignyDZhHK;J2`oQ`nvdRK4=@HMhYNEQfHqWo|<`~P=7XxB}x{m?Li%)H28o;A|MRHBo<~c*3Dz_?fgmgec?bC>wHjKumu*_RwSPX*?(I%s`uqRb zXIGoSx?4dSPbm56xIEbXv7~|^RML@8Y|^?E25IgGwcY`iL@mU1^i)B087s;mv8jzL zW&-vv$_d+he43K+O(Vz)Tls@-vA)V!R;i=|MHM|LJrN;N_J35j-pPDFSDo7>_#- zx4&AS7H5(&WV77K!@-4KSM%1jetb{(lVI+&ST@`qykcYeI)-0&5(vNIoV|50(TK*+uM)6--< zE&%9CY2l9UZ7$&LabB3jq+Z5eyiz~8yz}@~rKlDK9vw!a%o|QqJ%XM1)F$KhZ8kD) zXy7Wrr*yWS%EKM`H4p%9s!sV@%kFVQw^)SuN2etJ}7w>z7(ajQ%|pFVPi{nE?(i zKZ>eVp22wD1(RA`{`96Nl0a2sXA{>qalDvWc;TH2ncg4io!qsazBax0q3HA!qqIpG z4lwfj=eiquAL$bXa{qGNc^8I)Dv^jpq<>)3mE@rPki2)Uh*%x}HV=KfJ z-+wakoid3=+i(#4cBVZHeuRj`0*~rO_~gio<$>m-Zc6RULqiqnq{QABGcb;#dpY>Y zqvK4Hi&My9TCjq{JyE_gh^C&9gogI*^yY%(holz2Hz)Q&_YZol$Dx|CrHZG^KTaGR zI*MpF+j!TCKHqICsB@lK^-CP=+{?q%EGZM=l`^%e?dv@L>Syz*?YRZ+i~8Y`n&tji zT29PXE&7)cv7pB)xn1G#qhV23LNJFmx?Nx3rxd;}v3{$zPjEdol_e;pzG1QK{Q5{w zjb}M~x*g^9;4=g!QraD456;J=ToZ_q5|JE(e$&};C-H0_r-O#UEejIA@iFChzcjQ< z3Vt>I()uSx&3P%EI!EvDnox`*HtH)MV2t%eo&vR)YG6@0F1vgMc4%^CKwsCXDcB zz+kHiljv4?)8a(iNPy}3i{sPtEoyZ6KC@rdKO%s!%>*pT6Hz*{x8`SB$GD$dZTAYi^PFWK!()y7!VxWH2(d|Qdo>=%;>BE_Iq$#g z!F1krUMU+O^+67m>kwFJ*yv`tl*2bhKoTk-^ChXv1CK68C;6W9)1zj@aR*@h9jvXf zDAbG*P@D^JW#sscj3^JkDg(13*=$;BhwS8gk*!&ZsW8jmrP8reSe)+nrTZCE*W)0sIb%?sUIK&;~jtEA}#GX%Q zk#7&r|4l^cmA~3rRl9IsIs}SUM+0)rnka$I{9(o)=5=Pi^_aw9?Qfj{x6l>wURxK^ zXZeLI_2I9-$w>1?yW_cf_IwrdkS^tV8xHb7(#%g54NrRCJO>^Ei%B&jiNb#@1X$S; z*v790Qs(A@XZlYn$!_;gF{?kB9dcZnd@RLX;iPx=4vjM<>ahL0HV$We%~z;7uUWEv zqL>_R`Fo&!Xyj?x9;z>uGZlw@$OX)AJ&$;K%%XXIk%G*tIOwj+!n&1Ffg~M_31lI- zPgtklDPp@XeOYn+)D^4w^z>#7!M8}0vk8N{{wCnlnDRTt`rCLmJp8e6cxH96N&hpy z)$B0IMp&U1eGP&Y|2Day{C*%=OhB+;v-DCEfAi$=xE`1*>z4IP5#JUSS3l_{rMh!g zfVEm(>)hn=Du4D^*`xepND?szca1T;M*%m%{sR{wL_3L{QH*$}Kqhf#HV6LA|S~@?@nf=jhJh?kxlxrG_ z%rQ_CV96#wN2qw7u`wQbWM7z{2NL^^-~2=1EV~>B#Oa#aon#t1pqHcrispKa(Rs61 zPj`8~;c*a8K|X|IWYpzXCw`mm;Q_Kt^QE;?)@u(#vNH|h-NTf)wD5xSh@M2k_)H+3 zZuu2;Z@e;_S~oue3`}Ua?ft30{stHkh)=XMb0jzhDuJFZASn;1zg&ozsHG{fkbh7v zoo`SybXK_EKX^radWnsEMr0nSGb0@(M~lb@L+D%b3e6@NRgX zpp4COgmjLH$Rn{oB10oHboLhn#fP^|JXgh&HU!v}cI28eOhfR)k{b2`K1V@~%=L!9 zrxZr#;%SD+q5@8;cboPMi*>rwyxS+Z@~PT!kl?8N(XmH|uGnw>aZ(?>{*&^Mym0UF z7iE*P;R}ELd1m8W|4X;WaK>nxP!c~V>-p!Gq0kT+VOY)8*Hr#b`wQwx5oeUZ%u6~O zciRsb2mzhpH>AzXPJTx^84Kqpa;f8gMt~wl+#tKxWK)TmlN(+wGd{O(I6Ln7GG6WS zZlPG0*W@icGm8-U#R6J577nN6q?aSL;4MAK3ep=s>~52y4Z_q}?kfxdq<$@l$M$ju zWPCUWk!=RDGB+ia_zeF3$D+s0M7*^Po97)Fo8PM$3hMATnssfOJT`LLaj2NBpuP56 zqOZYGV66GYuLhRmph%u=K};}M|DH0zD)M%VVg~=9@ud=H&D+*k6njlLN6nvCCSc3; zS>5C9mzb^~lFGF|w=mn@wwzVYE~Y-5&!re6rQBd>T_Y0N3)Y{wFagYiwBRI}!!TXG zXQq5Qr*hH)c?e5hnZzo$(dM@NAC!}B@wZm!YC2A1r`BXMW--fB~A+q)aXZ!mAFG1enUs7#P&)FDI$Mq^Wm75uR({1yq> z(;XhuM|XD^jr5DnnmFbt=Rwk(hI89R3zH44Bv6cvrc+l*=K-03Z++i zAMEl350`ylA*w;*yjfb~bl6{>EKMUn{ef-q9Kf$z^MixK#Y3^h&cvNQM0v=#MnAfj zUK%U8Caqo2645c>wZ9wZwWBRpvH%Y2bWH2L#a4jkp;jo9&IbF$i953jdHI0G)q;oh zKUddy8VvEk6LaCS7Z5|~Q0Y33KF{LjlX-?lIKFJ_bY}T}+15P%aePzee-U%9kVK+J zr+IBLoLqO|*Afgp%u#Mu2t{Gjr`-y~%U-=J3fVzCbEDKZeOUF8LCUr*{d$amY&(HY ztdLrLGwZ!)9syp%AzW#ikcgR_k=likl{(JP?ji}u#7di4TfJTGPc zaklBcLCAcChC)I6sxe?1?{KfEoF?Jx53gutQ{3HfUS(+X)%DYybPFO*Frp z8xHtjRuPK=G*bqbu6{Ro?OeCCs>TYQs$!&hwZ{e84Aaq3?FDVWHl;l_pF^If)&HpP zkYBB&Yt8?HV?oRv0#Ozh0A5lPQ9^kmUPo1ZMV+Tl?b*wXfBsdMJCeYFnZLd8SQjbz zecLd(s~&wGe5Lw$fh1$&oXdY2PS}Iqd}`n~si) zzt`uoJ6kEGgEt!FAv7RNCgiLV@I7{3`OF^>j`KW$AeoA#4Rh0V)U?&Cq@R1UHQjTS zOIL1BK{M(Xl?6W%rFzB^b8Q(6cqd2+kM$+hIXNQNb}0k;8*VxrLOEX<_D-qO^LvH% z1G}D)MLMEhyCs{2P}8xw+ra#}-ZKF3a}XCVK$$oufE#3E3VhEd$MUZ?0utfVm#do3 zReWSrWp!jR*wLZFtM1zk7mo7E4nlz9B={5R`+PFW*@qvbfnY`sSa-nZM>v8wX2_9I@B?+ z1EZ>v5Kec(C9!?0M36Mm0ryrZS0+RL1pe%v#n~)?s;2Zv9)iaQQWaTQ%Yl1&sKCEK z6^DGIKOA&feEtF@9#mpe3x^>mfz)frB}Eyf!R(PpL9MWPfy}3FeR+3HN6GPH!;%DE zGx#A~=ICwXY*$&k!DTU_J9=R$?b*WO|mkr=RkkCFo(!j^`P{Y8*G0)-XYn`Og7O~MSysU zGD5lRWYaZ)lF?Ya-%;^n93}~?7JZ*SZpKmj7f7gGMfh0Qd=BYH1eC%i@lJPU_U^cx zh25m(5wIydz(ao+3E;7DCBi}{z#NdqerTgb-PQZ1Zjr3-V|@QSV~Pn{1~GRYgWzBg zU^4^)#j%Yb*&j?!N7_VuND+OEs!Vxki_xpNgmdz=x#=iS*T-dDs={RWMGg1E9&Dbh~kKq1k zC_0O*qTK6YuU2-GRj?NqKx0@XQ`xxHjK$K^bm&5|s9b9|*0d+mjoM1ujL%8@;M?fH)MP%+xJv>UvDi_X9bf5 z#bKrNQhkiaTvVF3nDclnF2^q+D=2uaBJH$j{u;ku`9ujEVWRH?5Xh9~b!I z*s@oesmB`a@+aIOEXGJIuJx#n6WzA?W3MSZyB9enLZ5PmO-K_0k3)35@%KD?>*KSS z1!lNX^&-({)z-J}!PqQ2bM@-8?Zl+Fg^~LHUnN90@(6c&Un8a4lKvO1#T}&vtGp?fqOE& zPiq6V?Iv?C_Z8sw^ZzJXID&GYG zq6!t>ESK{S6&}M&;3h@<%2lMO=ph@Z%^glBp){bk5vSGVt=lZ5{fep5OO9FmSB4@8 z{4IDFm%QbPDe#5E;=X3}4xYi-C125!5dET=Mm!nYM=IqbQi7+kz9Hir9)T#=Z`^=L z<^|)kG@1=b5I8>AHjhE-?TnO@_4fbkj(+*kZ<%S+ojRcGY167*tw)cYbHpE+co-A8 zSOJ8)y=glxV&E-G)bFxpoRKJ9aOY}4f6Fho{k^?^Q`ieTZ{(jfXb5LruU-!t zSA-_P&GSfiP0$Fogk$p=iitp`B5lX3F}y_pe<(JORFK$)t=cm#E|K05*N7sdhd-g< zH{PNV5IhPFf^@mfq*!~;tct~q^tpnInnN-+D{O1TQjBzbu7<=CHy;#w6{eb+%e4>i z@#r8MZu!(XH@aVFIzb1E5tx>N9s=mT6u&I$7SJ@cL)#uvG3|aht2s%d7^X-WP$dKz z=-l~GrbuelP*{*38<9#B&ZXx!FC!a_h`s);G(_7U{v8khiNb#z*rYnv7!WIZ4%Z4xu75L##og$ zRwAwPjVwnd?~ynb$q=0~Hmf?ZfBE$B4xbwieL)j7)#@gyKvd;bEd}A71wVuSRA(UFgCg1af!2}|OD@n87L_eDpDJxhE*oJPqu|$+Z|-Z0?`MH zeTDZP@2gB6n2L!}@qHsr;72xeDe+!eg^$;8UCi8=EPu!x+(xC)=eVrfhwY??3PV~k zj&jv+5zn5b-49xQLWvBO(IHOq*RM{g&huo=F$8*)_ftO|$E1$*>kG;|l$DAAYxqfI z<9EB%6PX7mF>HKHCvA;|3H?uW2bk_m-xM`12XKl|8H%XP+d8F<0SP3(0^}LP%@O0~ zKkLsW(E9>S{RiwdeH?hBT{+O@f+w`S9q?lscrji!xH*A;6S(G80HqOgc^cD{ zjU-0;bFSY{c6hs_)1TFC;h&8EE@4OLPh{5W%D61PmnbjC6Gq}t8tj6{kR{AF+T=5b zrW2zwe3SB7z|UCs`MlCg))+y$Gui?AW{=uUiM@(VUUlPad3~PcP_D7lrcWho%1ZY< z_}>j`STKVO&DdbQ$6r0WCY>0FEqzb=*L>!ruMgr{)ypP;GF=x4gC{UK5-C1`p+`?h zsbWsS&>0Af|ED_CWO0xdfAzo?#ao=L0wPB{{_RpKXzkx)V*X*^9YVt^4~%IbGYBrm z1hzR3GOB1VeOoWOe1V!e>Lw zxs0vhyDWR!0KExRK-iDZ#gM5R z)*r9^!`A6zu_nn`<3U(c3QrDR_bc=1HSb5>lNCxL&1>oQN4I)70b;D4M<~_qlL4w3 z02k=1`DmBD^8Q>;qa0>$TxMKAkz>gIWbfVj*jB7!jk?M44=eC#TWBXCzN-(O)keV} z)$coN9-5{k6s9=}2yp^^meZ8_E7Ywgb$4c6`Lv!s#}K#CuUSK`LZDxZ8%ynP!w@>8 zm-`@_XGj$uG@~K)BEpOK6-U0>oP3Nk!}#*=hir^QWhUw@(VxziH#0=mHt)7JHd+G1 zI>YEYu3xPap#w4=;P757WyoSSZhETNZv5T6l#k}e+qZ~(*(u?=nDjO!y6U(2JU;{N zLrP3a51;+r+WB=jO(iLLwqUzCB1bWqNm&$<2uHd0|8$%wyB4o)Tl}vpZ>(ti{+Bwy zcq4ctR_r~wW~|N7Oijh^>3PD%)~0$(%F17T6=^+wYv;p)&CXYb`$gR>&w&d7!Xfgh z4F_ZM0L?=gr!z-ZSWYL6YPl%Zjx5^)c=`6kL+R`nzYWR9%RP67x4fNH13CNu*7n5P zGoJY4o|m4StDP{dQoX+DJ&=BqA?QRe&4B(6{>_WcMVCBRt-~J_5L>Gc&sAQi(F_z) zv&oX^$k=>5{zK^5?XF(T8uea$oK(mknqyojYBO9-)*}j;>=I(%x=iNF@mx`6(uvBw zk#i7IZ_(#36S!eaxr%~@ z>PZSSTb{~Nw?YvpwNaw7mqGndT)5%YAPqL)B);eBY^!84dOOpQayZw{KX3(C?Rc(t z^4t1L`^&!^GuMNTe{dvl;V+FG_d8k9}O2#Y|cdNG`j8fz_8&qRQw- zaw+M89dy5S(&5Wp^}4%T1C3pEmak!lc&c*r)^FS!s1$yI#02MTj?C`oqKw(e ze3rw{f7Y_lefv?L3Cw|?mdD!#*Q<&f*hb%ZImDZB6mtU%r&?21IOeXOW%9kLNf;p( zmN`i5vu7YGix89A8XA(ulzc+SdVx1q=}^4lCT?vNTp{v-=c5xaj2ph8nhHaq^;tj^`qz*^9Oz2?&=gXzT=@rc_S z^kby=Ui&0AS$``re5;(kY(nck8F0tDrP}o8d27YbOGSCPYNjc|*KybS25aHgH(H;W z;3oSl!{z#>nT7>Fn8i%dR=>73E8G`tE8FPd4hD3g!d}~4tytmRxH$vYdwGvej5XME zEMF|_Uq%p6@(RelD;fzR48(dPeR5Ic@*l}~2%VPN2Q3&8Uc|YiN1t#|2z_T(mGp

SJ*?a9hBJNeIH;OFPd;(P~M}Ih{ zalSkB(|5fUKn)$DI(Rao&Yx)}${V{Y(cdrLpHK4~lDt&SgBTZ=*S<1mwkN^RDY zFz*-MbY8nFsHx`#RoF>{9RvA*9WVbDuWadR2@gdxJC<^tt=FbcU(Ob1yY9MR;B;KF z^JumE2_U&*)j${UdBlK0C^A0GZxNaitswH*%Z-2Y$8Im3c4w3hbT6d>F#Ro%zuSou zW0fAgDQ4u*viz0aTr7X{{wrJrqnBHQD&>we_4%XgwO+m88svwvmvj$5GTIV4+n$RU zTEV|m#lDjJZzgbNC+!XV_+2E!A6c5!c~rLJ^F5tZZM*MOOHCc>Kat5xnUFR=g&px{ z58m{fP}hHqE)%2n_SUUqJ-X4RmcD3^`#Ynj3F#;_Q4*g8vm|Hz^)G_E5J|Y4zz*GL zWtP=>>~NA5&t0g|6uE2?+@@}ox=;3Y!jnGrd-odGQgBkSL#SpN&pE2NhMWGH4C%U5 z=<>*jJmq4L$8bn5+= zDmS&B^xZZPA*oQRlP9?O@zKL^+PU60n${~SmUJFIT;*S3sJN{0?*(%J+e`q~(eSSF zQq=(`i8?!UXDA%46;?5L)9X_>sTgd2Lx+dntucw-vNF?eXFVt&3Mul69Wn~oK~~3V z(ALpK2mU_7QA+B+i6uZkAGv9z6^347qe$F6(AvQ1MSCca?p!{lEpl~(CbC|%eUJdU zJT87dW9UP4Uu|YB5}HrbHXt;I{~+M8 zAu-;=eP=2^i;TI=oBL=hZngi>-azOD3(8M+&MxN(I7+Ju#h!vg6UrSNX(SQ1tG1~` zc**y8uY5D0-Mr`4Xn`G^g`R(Jf~%wX+VW|2&NA)GfjXAd=-{_rKKu_D*io@ve%=}Onf zwHWq$zO7z5bfsJrLwQql|O|ZuqMR~oGtPnISIc9Hu!w)Zm2De z$9={J*8#!R>mmVjEaa!ET!E%1Ty*1p?_q-%_z-PpUISPS?{NY&x+>6lpDtNaZ)>{f zy>0NDq`!9S{FVWOVVJvD60lj~wZv;u!3zKoFT;v(%7YbKvkK?EV_mcAW#BFM$tLC? zA11GjMorNcy1S*RxQ|vYsOH{z3maZ&c7C&OB=nFnkT)?Ai`TjI)707yR=A#wIGe5^ z>RP_>)^r49a-@vs5TqBw;D-K9{taAxrOdIkC~*IRD%{Vl=?3Zawq^IP$GM$8G+eb? z&bh||ycrHGyAh5hFX<3&>B-J;lNoHN_f6;EM=RblE5?lTtJmMxLO%;QQA`j*Ch0Kw z9r=*(fvWpbjj5@bp9nfKl5&uMTPW943^ zi^Mx;h;E?41iW|IC*7a3r;(Y{^a~K35VzMJNWJ4JHoz=kFMDBnjwD+x#`j0iDVe z&)}u;Kl={_@PLw_)a+|Ia;V2ZHn`YX0;DDr1YGVvJ);0Zie3vkM|TW_t_ey&1{p_@ ziOGOtZj?uYg7?50zZPQ1nHNacFf6%BPvoo*XWlet49)3kGrbzDD zx>IOuaYX>SD-Mimf_-TMnaMCqiKhEcG||+t`PBtM2IL!`8zUX1Ld1iZ>W!WPO~q9MP0gZ=!dRiSSc91{ zRz46k-muC(K562q*dXeR(vYT%lnRdsXK|nloctl)fPUnx?bQjdH2HlejT0Q%;@sXq z`zZzRDbGYOw{T-OO3NA0?%9VRbWpGpzK3BJMo$4PZK?;M7Ii8J_c)j0a1UBJm~TlJ z`G!sUHbq8dnMZe_2P-1I#u28RAHbD72eQ@KAYhywYmtB>m>^TYpuGPWVxCER!EU(3 zd=O?*4F216y?2rF$Il8W(C(ep7;0(G4d2RifetCTn%F7``0zITZ6IMke=rzm!EB5> zlg@8#3W*Rsaa}=@P2n?lrsOtp+C63t?hFv0pswoHfGj$HcFzSY=xaoq9Mq}6Zt(q= zkWOJj`uN&uANUZ{S4mb-CcgK}qItsKAo@O!RP#ym-#K>3@7nExdNSdm zKrdSL5TxP=p8@u=ds4r64nJv zo|X&H4EHLn+Ntb{@_l>weW4?kO|&!YWW_Jym4l&LDn-tZ+7wyQ#nlKcMeT(i0|k>z zUJxmaV`WRl?2e)gd-xk%t;Y^;)1mZ_uyN^ z0_kwn!4|7g=2BYsCJQpI#8=`%kKfG~2Rm(wc;q4B3=-qx;D&8N>}j79@G$|1hEhxE zgm8=_O+)DX1r6tp!B_BE<}Z! zzZv3~KA9n207Lw>1DgEX@kvL|4{5*0!NT+`INT+kX8BSz5YLCOaX{Mq{}|%cZ-(H4 zXt*y+rZSy5N}tWDe3MxT(sL8bph08E-mCDsJr{%UvVmlaW(YKM2X_h>g7ENv46zHa zB~t%s=bCWHDs2|Vj&1cU2`3K(7smwbd~zn86YA13+ClCT6-2p4G^Hq+)#)Y+II_gF zcBAdd-_{epDK`!f=T5B?&u0EURg8n0qm-jI$H7?GDE_=lx!1-Ekxjpth7`33n|F`Bk3{1PP1*-CPoa*1}7;@wtzbL6* zskb`EZ(@oC`O205GV$R0KD1)5mii8SV_*N30DO8?V?Vfy&bzM=@7ykcnyfMCe;xqQ z`=O=WGsiH0d(+#AgP!pQ>+UyCME?$so=ZCcLLrKo;R<`nAN!#^3P4n$W#DIuRi9zi zc&)wcE{VIk{&vHRM1ETaBj=47KN?9iH9fk*?#>03j|);hvF?K-e`_hSlD(Xa^)5y_ zM52(2p;;cebsWh;i@TOludO3Y>XEXgoncz(fnfU__Zj1K<+0;6A(*W;PjY-8AQ0Cb zPaT}80kMiAvC{n|!hTDYzWN8WM1{axXGJd;EaeA|I=e;sSo-<4-+W~*H}fB#OAgSRQR^l%6=#wv^n)y#;OP2E571E@L?bQeq>q$@v@K(`PrTu}IP#{W zVN*6AcC!GBbb<23Qt5F}AfP7Nz=?7O#isQqW+yH0CFO(xsi~OLey57LMq@JH2CCdZ zL^Eel6Mp|y6RtfQ;Ovj$&*58Dbe#IXN}`X<6GStS*wMj1)5CrDl75t>*G)~qVWPjW z5+j;Gb#mw$@8jnJ=54Z71?xvz9KmFf0voXs$u98-;FunGRHpNgN&4(hqO%V?az}|6>XM!c6moX=o34=Ql(6PLUZR zY{F$fgoNGZRYf_VgUs`03Z(cATSQ4+c6?kGNj9*$wx#kIi!$IUH{S@3bHz{W&%A;F z2PB*NDFCaC)5Sy+AVz~_ZXH_CG@6nT0sT=SN6E1f(%E7zWm((r=s`%idVeBire9Mp zh*=Edft_vG%72Q3dp{g&;+ptfS||*3wa@5c8iyFF#`##D_v zv`qWlk|L$7Uzz`48rK5?aeqmvFbf2O=J`#QFLXHL<1yNe#jMdh6(5E_H0;SmTmwx} z*Nx$dSYedP!9MYqKgC`mr#r6*%!oKbroWmJF7xMiKP@X#3XEE)r-xrI@umV_e5hmh zS)=>^=cQZnK5M1%6SXe9MsKM$y)sJjUhGHwIo)FHo4O%38`N6=z>y0jbT`6y5OM^_ z$eWx*Oqdoqx>um51zH>)vfl8bKtZG654(%9ZxSNw;Ydp%bm&Bhgvo8`qr(=9O72g5 zrs6dMXBx7$y#+O3zo^Z8p8Q%#D^OHc`UsOv1)9V;0AMmyn`VQDm^SQRd(pS*L+$&HpSWVjY-#mv;&!So%>0fnn-D3b8;) zXn}|^cG#cW19FtHbL@(?kVlEVs3aJ#I7bEZg(aG(pFvqcHGvVE(N=KJ(0Z7t1VWZmY zNwy6r%0c6e;cSm-A!DK^_7w+Ue%*)!mr}WWq4aLtQV6z|j04`J;bQCk(qKI(x&tUM z{)Rmm`Xj$)eF6!+zGSnZMAu@+{l}%AN!~wXVfxXo<^l7B=d5)6v5-Jh#Ru*{k12QM z9^~i;k3dw_5%SVW<#xQQT8l&461yo;FU)1dfnByUFdD7=L!!Sgo|`dPgoVQ3vY!4q zS^H7*BlKd(5)2^saw@d-X`-Hs07R{ly zvbd+R?~WhmV3{2+h!0z!+`%aFYwO4)!^8=XZhUQN>Z|}W-rJ4>4Y)eH(&Y#-p{jT0 zcHq5|$5&L^J3OWri()n*%$3Red^8`5T8CkZ$PfreYGBf89IYI{8zm24Mk|J$)!DH$ zvY$}zwuKdtd98OUg`#_(x6{HbX0_rlAm1zTaj+C0@>0@!>N{DxiP7IQgY#JeaaWC6*>#Rg(p+@Qzj?G^vpHs&U zojE3+f&a{iS%&i7xJnqt88o?(S;tCLvMk^^-4{^sObZk&B*%`OrIaOYKuYQ&%V_QLx%KXWP2QCw!5lf|)1!eHlP zJ*%kQn7XRiW_7z599zi&F#*pE0&xfiy)f8)YMB)TDF%i)P`L?I-jMyOQ^ln#Yl@Vl zJL_P^Y&)Jlh-geV4MAiIl;Ojr4Wd9#$hhMhF0O3JodvH@5vFvNv8%}{Ta7i*s zza+jGJ@13w^!*Db7|MKeaf!+fFF+=BO@i~Q2K}6 zC&}kDImhWdxuBQ}d|~h_Y6wOLAwws}45};$$6XW|a0&tIA>JWE&T$C|p2GMWl*Fg` z`OLX99H&ViF<#^j=m#~hl&)a|CZ`d25ExIhn(;X4_-Wbw_!7VuF5&|hXw-uRYM5B! ziu(a*{vOLUf%O06J(1?sbWUh$4y%5hnd;L)nE?lA@+r)%zj2KdOgG#_hm`j_H~+Jg z_cB2f7nV*0!Sknkj0l>YO-CkOg%U4GX(9(CU&aCs(C7{T^@smn8lf#D(6jB{Xv(Musn3H(eVQED#-5!!vSvdw8oIZrm z9&Dx{R z=CB?XiqTQPcy^*g3y@&{_!1`iLiCwj0lZC-8hL>QNSAujNK_89n9UQj3I z0Wp`#;dM-Q@26JR0ZS#Q=ibmAaI$#t{mp5CENpv;aWQb^>gF=*c;wBK9-WiPZ3n4| zr`8M2-O|k=JII2sPgblg0eM+hFttj7;N21a~DwVAOy(wX=0#JN1Ef3nLuE}F3J{e3J%Aw#ljZ50C2AscTq8UtmrqW@KUO*u!Fq6b<+F{4XUgghN}M)0RNI%AA(d#pDHBb#*Vd< z#nK=%zPyzfT_rx`4MEI=OVGmPAoQP`Y|fyZJK$PfTIc5s@nLe%a~WsLA)}m{zXLqZ zY90|-ggy}cG_ZEn=mPh@$!Ov%IqvNGAEG=E1yBDgjEEc*#5#bEmCwMiYM8+VL2_Kx zK`J8Oa)lj)k!4{dq`w@zdrLSh$Bc972+|3_xND;=1LB-glNA%9*GXvj`pyjp+k8&zB1Iep$=vVj!RFV^z68!kS6<5ik zDA=v!5X4pJ(G1KD>~iUc+1!U^JWK8|p_$>uv~2NDy5j24cO9=9K)SGR$a|;q5Zt8V zDPfCT9ajzE7cAgeLtb<6{nNcDN$lUrQfN*EC*qce6h-2yoY@W%{X4BZbEptkU9g2; z33Ah#ERb!oZIE900{|YdAd(eqJ3-=(Xq>qe;=13=hu&u zt#D23r5K3=a~sT9IF4c2FIyfDW9gqs!4FI`Q=u_@od}oGlzgDn3>!BU(!_;1Mg_lb zAHt;`FwQ_WbV=vjm?F%ysDmyCx|W1N5j}(N&LMBH^Kt^;Y0l}a85*hPk7({gDZWlF z!xwCh{Ih6~p($1S%Dt~2njGOtT$!WpHGCCHP_^gjNgV%*B{XVU#+jRYj1D}4*b5z6 zh7j7tC@}TgAU}vhrSa!DT=UPHdN2^(rLjy`+#-;yAnAmql3aBiOgF<<8D#N))hBV) zvilQs)l-CqqJZaUSnYvgEEqse!rH)1+gCun-C*(Lp2Z?&**$_e9-MLDh#A!%FP#|OE)qVtvUcO z$eyoLnO_A^&IYD}2B^)JntAr;j-d4ZfED2&sVU3U<9YvD0w}m3-=Zt|1IQx-1xPRZ zNhL)Cyb2V7q;AmWf3N_9@0UR6zrs6=?1a>tB@Y(6#3AU%P+JUH;h^!CLR64}mi}h2 zF?-*3fRaS>FW~2kErB?KgTGqx!&fEV(XR2*-fzDK(1)iX`)aP)uPjkOl3DY*-L*G* z3!iIm8|?&P;n64i;zu56(p%)^54$|x`GmP8FNq@OHRxZp0hMx(;qNyXeqwnS+4wD- zMWAd+XLKWNmZ#(U28jkHo+NnoHmwOF(ta!#1o~~*=1ZAdt)h8%d^AgEC5J`7GUaBR z)~An#AVzoB!`spoB~KvzLA7jrE8>v4AXyj!>Io=o4=!@n%J`3xhGshCRE@>iuxAY` z)&L)ZpwFEjzxLh`h}D!~|MvZnA}-hjf7>(LAA)lNI00ZJLXM|1RM;_Hgn`FoL`}p+ zi3SX>XT zHYO`mQInopd1O>SJ*AW(Gg~PPnXjAnr+fwgokiSsk!0K~wcuw%(YPZ5$?G>OMLMsd zs$1&~B}a7?n8=!fXd?9^_-%Qg?U<(|gNM=N@zsFiiFvndteCYC&sb)X$FqM0BHzoA8WXL0q3<44Kury=oZj zM54r&p=`$gOa-onW`pGMhv@(sbhh#xR1oI%0 zFQ&WRma!}DY)d0JQz;7}=N zUsgCoeQ;}#xpgpr+`nK02xr_@A9dzUPem2jTq7XO^MJ!wSQUpJQ3|sVMk7JN;r{{g z{7%dcc7hMMYq`|o6#b}KMdX-=&9OmO9DBwIMeo^-iy7F0LYfW6Eggf2xObY0NloHr zzxxtzRpBEDwS@noQeA1SDUkxULRTumK6cpOYIW-^ zAv%nlnMe~l*x|mb$2Lsd$D$(Ary17R+MMt_z`l=`^BxQ9=^=v870&O=p6MsKgoVJF zsk!9<30smY`KbHb^^Knk0fG{6dB>!F^k|T(7qu3v;x6t)n)2I|L1)j6Rvl9I`@;=T z{TrbQ_Ywz|Fa#>!Zu84w=u)tZsdan8Zpo|VhkG<&fv@NsPY|UakngauiIk*U@@qN_ zk=!1;sCD+?p65KVk7GJ#ixLLxg(V@*2l%e+9+2y3I|>BG;oo+!?8?RkStElPwO=+p zT{Usgeazxe!@5>mKH=$3+-p3q1}c0kww#5EqDaXcTu*0x7Co9iF$Cw|D+>SQryLEj zisbeW)3SnCUN-m zCrT{LN=9tVJW%TDYK(Yp=HSZvtMAh%hD&pv^M|X}ZBzYfz8fM%tQ3f+{uL2FFE_s} z2h4WlgPZnZ-*aR?{?u|>K2H)ryMNe5G(| z^7(U~$OfI0RohnvEaZ@zmn*x6Yho8f!;a$Y^vChVwBGZdCr48$2ItAHz3kPATl5V- zdg`7n9klJ5x-0i6Pilbu&*B~v2QytE#;;^Zr?>THpKAwp>;n%3uXA;G8#Zm*`i1ht zB=$*yzuW+iu#l_xT+}+mITUx3cLLlHT9!I&)DIP8M@E_xwAA-5DQ_j{7r=L(DfkOC zyZszq{0S+`6Cc`=q6f5nBYIcdpO^!qme?(P6T|+ySxQFf2DU{{bGZkYIsOPS89V0}s&&-5 zAcH-w(lB#6B&X4iH>Rq>&D>fDW#D!*Ij`;b42yz$y96nm0IhMiwB(gh`Z2DI$g;X; zH|>K~wVb*Ztv}#`&g|Lw^%f>dt;*SqVWF^>RXyWt13rb~WqJG+6n25S+o_HpJ~5;N zOz!lbY3Z#8aFpF^rq~)nI~jN~WRBGgm%c9TbvxlJnZKeae%;r~`C9m_#xrB$u3TK6 z)R_J3z)zE4fX$M1OCDx!T21iFfXb2J+wQj{EuGFN=t9zRhWJM5EP6i4A#Qd0h5 zqxpg-(!z7Tjh+H=FTUi`Gy*^zh%pA0dl9`)E?woaKHfegyOQT&$5*oR$8)c;8j|_3 z=)_55J1ej8OgrDokRt-ZQ71?a)qS7B^+HcUBeY6~Usn(CH#R`kSa+N9=siTbhy{MS z5jjg3`%O0VomWQZ!WWDY1~hz9T+kdGQ(MNzp`WE;i?g2Y;bG#1ETrMJjbpLu09#cq zs&hz;_~siIh0{5K43+rX zwK~AoLiI3rrF_TFwT30F>-H;7ABP^Qgn9OVVWM>FRWPjU<2daxC0f&YHtmsi-1M(I zw96Ttd8>7w7`zJF8`sV<6rO%}{9XgAJT;NrM@C63c2xOMB(-{U`fqv4eK7f(k8M%Z zWNxa{VCP>o(lgCt3U%;uE#C+mv5NBO0iV%HQ%4I&y09&J&*ho6j>?lXZj5Q=F#O|- z<+W=irT-iLaUpEt!1X#BGew%dQ%b$9CCUFhFHG|H8D!#-H_ncyruX#tx+QOEDLHoD znszj9ORm;*ZJUlhIJD!(7Vlhx>n(*A9yS{9B;mBW5p z)c1$C^QSt)mZG~U7fok#IzF5QF&|o{FQSZ{zvjpU7qc!;Y-QvVB~yzsXsAd z*4^NbaK<3VMboAgW691iXv1*)%9JYTH~oQR034-OKUuMM))Bol?z|%Bm|2t6<(oTF$C3@VF74CbtEEv?-D^5+JDQN*C`c`+ z5tFbKGCvcjtfX?NivRS3K!MN5hVCg?-mk)7lc^ozn!V1U}2Bdp_aZFSM4wID7BqC64Q2p-WGad7|aV zIMvJhwcoqwTi7A~-MgVI%Qmg9`&CNXb!u`m=mq^6u_rZBg4S&84A}<3N84KEo>k0L zma+)XHn(v1x95uvWt6avy6#N<);_6s^RkmZ^}{-T=>k6KgEUS)QIjpMOWnsmK)abE zpfOTM?mP-~Nc?)dHi^ICgml)}qGX_`xHzw(62Xef{q!iB z0`{Q(rpMUsuVo2~^#@eu7a+)DW0v-ypwvwEHkBfjnZ~qjfsVKV*3^Ut!CAh*$(ZXP@`Wr zUay8GdbKPbFj`QKFBv!56UG^v# zm9y|@ZW-O)5AXf>W9_&Mt9MsZv)^K6n%Ku^%hhF_OR(0&o7syMcCK5!2luli#u{gt zElcp&Vejw&H(W69H<#!r(b~&ra-U@eWN!vIn<^Lyh6oy~M2Xw>eT#m4)oh!4v*?G3 zqIN=EwI&ni$YEu3@wRsNHLN-Dxt9g+*OFS;Mk(I}O0oD;KRNc`FXwf+Pwz2atO z^L&+4B8NR;7En8nhl27isp7v^i?&QvJ0H_gsn$=-Z@9j|Qii|UbGa}weh+g~lkoPs zFNQ}*>;s+V3ot04q<#JRB!6>9Xt*3wts6N!lq^I?-&vjb6&NpO z?Df?}y-nR&RaI!(x~7~^Ev9P%Z6U_TJc>R40UJa%0xv0a=Bms4@%X@KRz0p==Y9QhfNv;`Df;-$<+j|)evk{jKi;U`8Y8(n2c`DffsUI}Il#O)u>JTZA=NViD%1h{>{-&S|)~ zXyO4CC~IXgT?RwQdN{)y^#s>y?}bJPQU$NODu~Iuatl(M&?v5Ev^zbt%6|b9QAz}R zy;D9MLR@%@%dXw8lCL_&ASElCb8$a;o~_fJC-A4K>F(t{!|YqrD)({6hyEBX)sN2w z9nljFCxrvUZ0tZx(sIp9%M-a;&|38fo(a<2a>uu8IsnsBB##)~X@*P6w~_j_J|2Bv zzRS$MtIn<4B`pg@@foqt_gq0Aq5a2VV#~mS?5^l?(BGyN?ErSH;l&Li#7e!ai}XGz z0z@~U@T@vACqd_n31&zBAVI3dVURl8_qv{{>l_L6M^E}*O65UcCrysse;2cE>BSD{ z#8T$C;RR{g`Ac7`b>rpN%ztWnsw1Qx8ByK+`uI{%YVcdHjm^S=mG#Rfwv=Tlh4*ww za##LZjC*vw*cA@U2eFf2vQw#aTekKx~e^se1exC4o*!4>3ByR772 z`YV(R&(^5Bxgi>$1wsww&tBKfYsql$su|RC9S@uWRWDd=zPX8r+C@4Ii+tC2CrPCw zN1s&^L5&hX6^*GNUy5zM-0`JiOvw$W4sU|oAgq_};omW4lGRfNypGmh>lq+l2PZFx z#aUK}dYZvpo({DH6a5EEE7bevA zjsj5#xq3%(E|+qO#4!sB5u%};uuG84YQmTX>3hg&`l|M5h;{J5;dhIaen0h@CMdsr ze=D>u--7zp0yr$g=9aq$VsQ-3OW4)&T-`1hrpved??zq=qeyFC6y;=-67>5FJQMu6#^~oj&rA0i=02qXQAi+Y4Fs%wZE+GxDqb3O zkxTacr<;IY;Io>T zv1L4Sg-*942{B?$tbyiuAuYeyZ=6y8r&gKw9p(!ZoZjYwS_YO+GmugdiEs?(7yfZx2Bka!O)Jxk0vz$c^L z%HdS#0G5LF#hjyl=70f{B7MiElV<2WvXnV@Yh+a*r0O5Nj~z9GF46Im=C&CpMx3NS z#ZV$;=uVyRtJ3x(1!D=9?d?=V`i@0lIgDtdYd|DmkWVOHzG4g6|vC&JqonF8( z>F}vu1OTX4`gr<+ShLCg%G75~4QAh9@0t8k&iDf?*|EmbDio9?u^X@5n_U*8%uK7$18SyFN{UuHbF#q(L7p-fHPM=)2=0^H6G&n@&|Zn`n|WnLc%X+4!aj zUxd?IjXW3f9%-MHbzKL_`bMlTW8Lbd?E6Ydm^%f`<5sy|HW5bqKZ!H_+(qv%6Z=;!8GMMVQ{(QhqQ7*_s1DW(s%uzJZuG1<~D}(BvIJr z;A&R(9a9QM(@ZX~XT_E|NsyApjLytx3`*L5aYTQwTA1kD=EY0l9u|*<2!r;|)*1LV z1NFne}=DRLK9a>s++)8pg!VSh}%G@)auM5TEsP}m&TK7^JQdugF(OF?$F(+GS(o@ zHYaJfUeP`1yL8`}J)GYAydeMzpTefSy0Wee!}i_<9|Exs_=8SY-OnPoFR06VadJmf zYyQ`l7Y6^4E#>5-Aq*ZPTP-}#09=CjS%KeS5~5Dfi44K9m zWp!od&8ZzXU$KQ;EOC}$2nh)|Iy`^|FGOmB30p5dkX9}55MZZPcOiEZoeB!|_=e~s zK$8m@YaBOo_2FZs8@P_5UCBZqRRJN@7%(-6mXV21<>G8kUsbK0695}?LZ0k z)_g6Sg)X>2iUv$L#AvH=%;VG5V>D>kp=&=S(Q)lAKNU1Q#|m&VW-lDM7~Z#%wgHw{ zLyJWLH?wOfQSG;%T`U)gj%AfWQVIvC5sUwer?T`L8z)<+2`E|$|0Dv6iT-CX6CF#c zg2!Fn6O8uD7c9!`K@aP!PS(AY&`kvlu4*)1^M(H!$EC=qx0JJ<4MlKIupr))lEgsA z5ZYXXqOrM%BIbTLhn|rd|E>ik5#?Zm3LYfZgRMM!5(yiCz-CYIYH5b&9zMmdbp*}& zl`bC{4T0K0a}_&@-4e%NZ-QZ{ef1NqplT@gCq+!|KQ5kRTPAV^(V zf`l!tm%xXXHO$a}Z4ds9&#e55j$E>2!0j2C910@$-LED{{hzb?;2jS^8!bcG2^BHM zUKpnF7ykN~j=`$*XQTS_fVnug%s*t#PluFBSx1+dQFQrl#VL~oiW3d8;#bQ80t@0( z!&f;kLb3VGEVo)!0LX|q@A_F`==|HR!&_4zlX?v*u)^`%)4IOapDWJf1bLP0{PnR2 z#CEotKUkq?zoih_FdH^wIzS&`mfR$umB8w zp;9nRGA(|<0vVM;^o+v^+s40LC*eGu21iP2&ZkeI>t9+OgXCF9m?{@*?43v;PNZw( zU)QsLG!}~xzQq7gEG~Qz-#FM{#$_)ZOsI!zWQ~Wj6GQ5BVCYw_LX6NA@DswYaMIBK zXL1qqR=-F*rccUv_=bvjM<;!ZrQN)NaW6752APML+H~ZG{yEgz>ngkhB9_tt#p3`O zj9F@4@T5ggu8=)8n)?J|4M=XJC6H~f&B2*-3y>C1I>7M&s-r>%P#!2XelE@{Oe+&w z6XXcv`wo5%GrnXt2*el%nJ;e-8b$unDS{mmPq81|T_nTM5cC%qXngR_Xdhh}X)dEa zNa#iHzH~y+8q)smN2}Trt0pRGQNGDNo*`?6s(M*h=*?j?`}M5U{*MsNS@KdkZsK->Iy!!|k+610e^|F)h- zOYvP|u6E{#YXN!XOzoe2^E=IkKNHACJc>T~^hb-@&ex0tVnBJu>PC|pE$Nbg!b+sz zY9s{;4_tr^?YodHi-gbOP3EWMGB|#QA3!cuqBO&@P_F~YcD(EvRVcNkKvlT~5!QcW z7DVO`fG3kSG_4_sodjAG&AB#hmSosg>=0p*&g(OPR16LwE6(Fw!x5C2 z68)3j^v>0awG|~W=+*7W3Re27K7|4jHU^POthaio{Ae0#poC>KtxNnwhB*0CE{Y39 zT&cw0FmG5JFE2g{P=NR3*PCk0yCw}mWZYO+#$7wVfQL!3r1H`vM0vo`y(qrtr6+F? zXf`Z(S+ZdR8h8VB zc5CIR$_E%1bsxXn@>%ATMo!iN8bsRG$s94eTsE9XQa{~u#20MX4m!~sI zor+;|cP}X)rl=BT%k}zn^)Af1dAy`i7O}GrgaSU(6?xJIGPS5!9Nfb;zwV0SLHuDXI$HX`73i&DN$gW68&HB(}THw#awtd3$Snwf8@=)>u<;GCAPtQ)_7&!`k?umur9b_ z^{?A_p!faB%qA2uS%gQMfj~RMH}t)X8_bupK+i_~67#mPZirZt z|K@R&cw&|I*jurTjys9YpIUPnVDycwfS@5HbKcG@5l-y*;a=Hq(``*4ap2H!zTLlRfu5I?Fe!5>Br!^yv;v7E?|ai@ zBm98ge2!NccAH<8ny8Jb-@N@_T2{FYWrt3VkGCfh<@?RgcqlGgJ>zM;ubyzHGt-xDvOPL0fQU_bh3 z$e|R7QQ~6WZ9G4FHKFD}sm|MB@KozxQSJhhFAtOQp;ib^qQ+ftXTp1wqhhH!qrec` z=wl>$r8d!VkZ;<^~?b3vW4Wg6+$sbNF#>$miY}C2MOm z45q)^&9GwDpq;^!<}CAtOpe~T^!(u!Y?O1hvh!EM=t6vJW?ceBGURV~civ?1jAc0F za!i+2RgDmt(D-ccMxVUzI zz$03~2y~>~Ise;HQ~zh=(8)Fh@A_X8Z~%f)zN&vsx*YjMx(+#U&&4b*N5OFX zC9r%Ud%!o457Uy=@dc`XNnO4tlm6DmgMe7ldW=K8djZuYvc`}wZO+naH&S-%3lt#@ z|NODkVzO#hvjBb(=8ezFwyi~ELYW8mZskkp?Jq}WNmBZBr;g3!yy(FvUZ5Ga@-^&s zVcsJy6iud;WB-P&ySsoN)Y9stxt1WkYIM!RLZNowAzX($d>vfJWgZB{gwW0-;%6>qH8t|@642x?k$VyZT(2Jp@2-n@%Od*P3 zkvI(a;MheUs_tJL@b4ooEc3>aby5a~fz*uCwKBU9>935AQ^&IUL~N;0El%b?B%7#Y zwSX^bq`1~^Mnj#ZR18*pY%;~uFH#GpDPn07rIo1^=had;db|k1$t~t{wBZcRlcovB z%0wI*LZlTa0e2e^4FneeiwN1eg^Ptk+yCaKkdc=lwRB`|-{<=@AEzJ;Q&W*S;<*RT zAP++tf?;)Tyl_Etj8Cl!Pi%i}`89$swx~LwT9dc>Le~9mN72URU)6S%b@=Zo$HZrQ zQokV50kArVbvo%_8|CYlgg_6DVQ9$TigR)*KbzlEnzxgaFw5GmDsUv0)_i~#*%E@z z%y6xP_Mq_8q<1VwtGEie?T%K#tIW5@wu3+;W8-=yzF#}EL>fbNkU^H`lgWkz zk)WJM>kZQ$-qa6Opj7av^52?}iy*=enDMa{g^Z*X(g8Ed4vZW=@U4_HP&j9Ny#YGZ z>dOu3nSh(wlJtoNaVg=OslDCUPMq4i(LZvyEc{U6ln}JbD7gB(-CzH2O*FRyAC7cs zd`9glsH-IUtA#nmyLkvOk%oUZd*5A`f;cOBj9<%uU;CJL;&x*Q?J-0$VR!ae`_eJ7 z+pT}=j)t2vrf#BADy-H(6;@mRW#n+g5S?y!C9nf@-)w9Z2SL<%bBIvh*yL*;w0RU> zarO32WQu*#T5=MpMMP2}9cJ-PZwYqZqwR|$?k3Q~CLq+n zAIncGG|Y?lg=(P)Gd-|nH?F}$2k`rNzbPv*LtQasz1Fh&KIiV{Z{E~*3G&o!nB51e z6|!)9CJ*WmNarveULZ4TpwwMU8YG+#`Q?P3o+l3}R9l*atIi&BSu6vgKjp4<+u8Io zHN<@2^+BK5L)vi!ny4+pW|*(vvc#dts`t|=Lv#83w}YVQr-k6{ipE%khqL$F)kQBDD+L)j=ug3T$v$P#W%v0Kk@ljFi|FIsh% zWmjoC>-CU#CvZ{b_;xf$3OpY~7T5rlF}0H~u=OLLR9mr1Z#u|3Qtj4I6vn3N?9h~o!qATL9)qI~)J!QbII{x)T86=)PO z1j#IT)XArN`dm4%>ZPAM5&vKBToM04AO&^a6cNcoE+Hl01w3h8c~)_G*cy^Kq7QEu zE$F)5I|@V{;UN9t&*dw&KxXRPKxRn~1=qSY`|x4Ri&RoUlI7CZ>PSop#l3X-Ir{T3 z@aZw|5r4iNUrz=*uEjl7+lhj+Tz{FW{tSoe1li6_{j4;$0s$LpbP>k|8sAZQij6As zf!Uk}uN+iZj!JoVf*CC0D^A`_^H~X#$57IjEtOr!NLi1L`xg}sVVa*Xu~bq8!(z-O z`hvrLc_{H}3S%$?!S7PHwI4(U#3T=@y*-T@_i}<7>G;{qT{u}n=p5MrWoN90lyh!T zz8eNVl6RxI0mwu8rxwALV@aNWn@pQZLWuNXRXda*1}m~u3tL=w2Zln3LHl-rehY;& zG8)Bnr%k?YR!4kRB$HB(?;bDvK7ZRaSOO@P>%G6&In{x4AZf0B+stP-61{}C>)UX~ zK!>Ar2Nb~s%!{L8*LzO~+Ua2o2y{h!BmOBwd>?8&4YwnF#lxbu7kFuQt9gZuc%f`u zMa*io;)WZTM2lP3qV!O-4BUv3f#jUMwZt6oPRY1Rc{;lxrTP;)zU8Q~{f`JlX(x{i z5(gT6g3Yd*lGQfzm1OD^UI)5}PFODsC}aTGMqDw+E$-g5LJ$(s*YQgkB$jDoJ>kSb z^Klfyv-}NPckD&08fdbC4V+{exzj5y15pT%Vbd>}rNBoLL=Oz&z0|U{GfBh4f}v+A zU?vEi<}ESaz*Kf$`wVrG@1YL8(dmjBKkMe*S8^0K(6I_?rZ8D4RD{SwkLf^8BLP3@XnzzpT@xb4-1aS)BZ z{kH|WF`d@@;8L>bbdm!v0|%%TOIgj=-JUu@d98B%UwGXL%dXmPOPXU>P!eL^JhXe2 z6JGnv@7G7OV&QOO- zk5^+j8E@w44%&g}SX|ZMtdtVjzK#S!8_sxdD-<}}5>Rb^)y9|Rtl`pD2n%8Bb)~}J z)J{(i5+2UKS%n5Mbxt_W2tneN0_7wi#H$SFIOi&<97{kg!fZADc0m1#pIdh#x0$Vl z%+P$WhH?CW3$i0oO#UbRp*U!^kItzgr|4KWfoND(`Eei+sIv@=>9Wm{ms+|YW9H7| z<)%%>TVA4vj-Jc>Ac!WRC^9zK`&>$7)geqI;p=63hs3N(3_z=4bw*lzSle5kIk7>3 zzVEE*(E)Y;oB;1|S#bTX_op}#C|}G^gcBrMU}Fq4jBro;tSuWzkl^ueA7qBDky{`p z*YF;clOsr7LU+4}QHOwpurOx{YdBMwz5T^S3j&^yY8uJ`8(H}?-E{O}xL5w9;Q!apt49#NK>C1o+NdkbFwO{Ku ze;+b%7o`rGM|(C@H1%3jp!|t%F}WZ(h5x{3Szk7eg=PNumSEXiajViw3U#_D-zjD9 zuDq%pMC~3!u4l(7ekVG?wT_Oh#`d9r6jq+t22@=A>Aj)m90sIp{?@;5W0MN;V@^xb zf*=cc#S%Zt+dAB-iI3S28dS8`Gop*xB|^|(6RS5=1Av%}4)~vsz#a$J|JCuNsbbdA z+0K6Rtptb)fI}OEj-KQh@nBMozucYIZx{y9z*5& zj?SB_Wy{8rKGYDvf34vh2(dSEC{Y`E^=+jx2`6 z*n!{w`%bK&5iU|~Q&JeRJ(=7S4!!pJ)WA@EU$VmyMIRpnir9fe_q=J(KhvYs(Qg68 z>^xwJ`9Lc9t8xG(Nh7mkVS@!3QQ%XKfK$Vjw@9fBMy%N=*;F~!(<7fdza_={%MFvq9A&rT>A%0kx#!2VsKLM%L(Kv!6w(qQo8=*yytrU3So zel%DECMXz6MN4ZJ;ptt?5d@+LzLAHWRwp56Lx+Sf0LY9s>uSS{10uOWf~Roc97o|@ z!=1zny6Iyjrw}O`-*@fg=6%TD9EndHkt%94{eM)wcOaGR|2Tegl1lM-9$8t@P-ZB5 zG*FpQ_DUpK$=;__JVq3uvPwu+va(OvyPWKq8M62Oy{@C@{rUd>I(3};y07bXz4pw4 zsN3XPF9rUBm^PR`Byy60@F=+W;SRsP*HqC@X2!UGyceF-kI^MFF$Ke50eKw}69BIx zv900w~v-S3?&KZ~#s?AzRpt=J1eR%p zlJsWpQ}R!enec)g^(4KwF3TERxV`-&Gt0}bH(4n$qb4_D7`2SZI1*w4vcT#f>4sYW z<-su_R_u23(v9t>J{^tyPT=Q^7RO-%C`a1$W!_z=8G1H-tpc(}EP9x+hT>iBIkVyd zOr?3GhY52fBQegi`m{o|M?(&>);ON}+><%W%Y1I>!Gh1eAvKUy&SU^_j>r=e>eRY_!ouM;tdlnNCAd?C4| z&&IyP;z%;N7OqeN=Lvzd(MzAzrhdZ$ym`RCZBMpSGI)XATz!x2&~A`%z_M+EHWjsc zkcFCrJ2@nj{0_rA3z!r@Jm!8S-FY1NQ4C<}?K4D7A*5_MK%q@!6!=>GK=C1zB=83- z!zl2wZv9OQmKa_UVUko|n=NFWiD87y=(v&9Y=oFtY?1{l4C&3uc|JyjosxD9u6_S> zR@jQq5hrKM$=?uVCA=s8){nVOHV_Gs!)Vxn0BHwAYs)J%7!4`CO5wMS0ut|-Ae(5p zf$?vfQFk1683M(cu*1i|hX-aL%s_%2ZD&d1|KVm-Q2qG~QJGw)Hx&415K+zCi>>0& zo%e&U6b&aOCEs%uqTo*eWaIw9PEO7~c7G7aiU{Xqt=@me;la%6_~gt}9R)twaWKA) zcH7-IB*y}OL&8Qrta=EoIs;MI^gJ=_<7Z?CBLtmi!lLp(4~g{b2>$%y9SwmTT6J&2 zAsNsi%kpz4)xo3QDqS~cCOuReFIdlGIxs^iRV6QrME;8nNk}D|gHVq5A?Q7ic4Mq> z^zWT%xS7DQw{id8>wQXfoBRG0gheaPEArm%Jb!ZM>EA=~j4Lh$MsC_6Vvz)R<=tt0 z4^U_jPOhF!&>+(hp-~L&Wjw$4F=Q!$uhxf@9u-AtwY2GRPQOs);x%M1bM=wws5fPS zj)HD@Gr#o})fJ31CpOu+V);m94WuMhg;bm}{C7;lL3XDU;`=22h#W`td|2SE^w_aZ zXzhe(X1jX>S`C<-fkY(NAAlTqsKS8!q58R368??(SI_P=#g!Gjd&CKOOF=%eU^UWT zEaKXW5qwCmPEL`%L{5ea(p47j^;Pa%9Um3=ieS>D4sy#t7I53kcQ9ejua6^+CY}*8`KCk* zhsXuTCY2vEU~-74-ZS%~webwlcOU23~H=fY4Vi}9YFyqxFF)nj&R#aN}7 zbd%F}q#q0Vqf%wnqgdm8}-F>d6R9J>`F> z9==iZn{GvG%m5qxhQN%WEkBD?=jSDhVgNrAO%ZZ%BEN!sXV<^07Jp@x9;KJ+U00Bi zE!4VbZ~LUcsH?kS=^s$eA%R=ZkOedOg5>U}BM_M_1fD|Tp^!QcQ#47Lc5|iaF{*FkVG=Nc%Ef1n~rx%Sh8zHkrF*5vyi9!s#6lnn$I zE%4ak3)fJ7f=|6q+DWG5M9Sv2PZm@Mh*QIitqa0gn8|W`SYrfm6mldcAtrM6`96Fn zAix>pDXphl-DOCg_E$*?%;9e~23kmdrUTiiFy-8#{(iwULz9FLNjJU}i!`BBsT zc-`HC05h@3T=i(krQ<&JA^x(yeBAC~U$us~|egJ3&=MyflVJ1gOk1kC(RTNSk z$8M{ya96u61uZ=M3aG1E3c+5w>w>H=AT|RbmJ^RSkyCd^)?;Oc*cP!Iyy5*WKNqG$ z1qdYaxH!JUJ6?LIiN=S;s<11wQq|!!ewhY*PH-4`Zg+k|?_0MIp|~<2?q_t^@N9Ws z_i`!!DdxsIB4G}0C!iH`?{33j9Q$U$#PXf&h|QVYOZ>`2cuVBP(K8r=sn2QaPC}h z5X=gcV(nZqF=H5p^oBcmoZG(>bGaIZVn>^e)}tr%_N}=xDwrv>;Xax`jigPO2K2;5 z4_iY_AVHZG)PCrAZb_fD(xjwaLtIv^Fc)yr_)EmJZ{=KL`J&s>^MB@rem5VP{R=CENpU$Am%aglUur+_JMz&{Oh)v$H%W})PTNBarf?!Mt4ol>KB@(+9tq#!;qTN}NzU#BgUXnW4ikmlJ z_nuU=W)iLayR+*`+~jQ~J`Mqza(^{SOFkE$WHziJSu1HTrv5iN0sYbw2FP%ao8u1d z?6Q3~eNRpXdQlW^{W$*R@&1TwiLYe(d%f3-acI!Za^Lte6=8GQ*RgUhUgIyo$xnCK zK7eU6GAa?=K9SQ(KL1HiiR-v*oMIXy!=?RcKU&7N>b1E(aj0oCSjM{d=eds54~kJGzAiJDrQv0!)+6H!KH=j5`(S93M)Kzs2{N3Z zVp|*0O&t691Fp`b6QopQgaoEuTz#`5+1EdWopXBT2X6jTQQSkhqK&&`r8J>semC`Y zyf#DId_hCj8hyS8;}w4Zo(1P3%Bq`W>S<6$?m(XfiO>Mo8YO5_x@M@zyIORmx+3H0 zzoDtn_PXd<+vCDLIQ2#MZ^!RrI(GqN9~(eQH(qptTm#W|S|4i#$1Wq!3$a#&<}q61 z(jE?t5S+^x7+t6RcecCYw)>5d8vUDG=`U7|FpfN_7d*FS`rAfh3B`XE}okAef? z>=mBJKZ|=FZCcN4?pypteK504O1VE_iWTs%r$5nY=nBu^_u~h!`+!QIakkI`)Xkk7 z)AnM+sSXiU#!kUy4|{$bu^b+<*SFw_f^r70IQ}vZ@dIuXMvA{}l9q;D-?3rCCyB?Y zv504K;A=^kit*2Na>6*+^GoO+P3Dvk9u=pxwFJHvFn;W8LJv2z!ef;@b41Vs_O7-K zGXjPlQefgRZ1(qbDufo95d6v8!&xoq; z{X@k3rr)$_YU-4CX})3d4sBg6L;!{$PTa|>?FV>mh( zr&{U<_dRnwG-TRI&&Rpx2YEzedtoFSj*wc&aSK~9G*n!^~0aj_tM?^`=Q6g z&8RAF@K@B|{H7*wT2+`;fyx)QtKRbI)X6R|bY zS0uu=HnUMr{AcNnm}2!^=$dwc1Fl5AAT50OkY>ku|#uk?;#SF#oTT*}-127kfM3d&v z#;Fz0v-#0#kL_&t3&WcAuHmJb-G{iWIMkqfU_QHj__!2BU_7u{wxpSKs;i-K=VjA1 zodlj#b{oqi*C))JlmEnk!;{!ky@`vgX<`yJT>{a2`{)S3ll+_@w45W;x@lF@c$aUm zzJ0N}kea@^E^KD@!;IiCv;a-l&*c9>KI-PPRy|t3969uC=4@rgq%+MA=)M+>P_Xc7 zt3O)+@Z%;sfu&iqJ>Yi{H0~cSaiM)lTOGQgH~o5A<0IWf@S<0n?w)yJwnSSEexom& zQv$NympAJDw4=8iyPATyo2E;ZsIiX&h#tSYeZTOmPh$H=)R8Ef5X36S%`3NJ+~th& zTr}<_xxJ_VXzjd0T=DQw1YQ~zs2xZB=uZ5vt&uA{UhMtM8jS|zNgVudaD=b_AW5B< z$CfohK}Ate5ZgDkQ5*I8wUyIjsbIxZ9fkidvymSBJY|aG%?7G#7ATv<_PZ5MB?fB8 z2s32Hzuz)H$nL)1%aJDw9j|fp7L%FWMBLB03B2mL;_CzcJtO(RcaH=d_q*cf#*rML;6XX@R2llx{A%H*R;*_hM8EK!o(R z3%xCGV+NyR={9y`k%O-J4AcIlaSn>B4>sE@``2mpt2oF7a&rFx#wM+Z_mnDeJ#L08 zTNaCs+cN(?rV*~s0~VkT2Lj&Zi9-T9r==Gw$CH^HRrJ9E#bG_ zYKAxi1I#E@L#6qdt*o>*-t*wP<(6kl%MB*)ys{qKhUV>0?`tUpJ6FcZsWGaHXoFWk zTjH)Vd)FYf9n&Yu^5nv$1L>u9?|dlcv-Fe_s7c~F4yRmul}}o`)H7H|AGoIyQdus; zO=qk`PBk?94Vu}2*rqs&ZpGB2`jAKf(Xx3)WzFvG!pvK zb1My9OK-;Oq7FJ`$z#FOVF+tJmPPMujg+h3doh^y1Kj~oG#()}40nK>QObZhF@vC| znqg-|FPsk_FB0GHD}&S-B+>5~J;Y)qKNiOt6}#uOB^}$S4`HXb@NsjRF1lj>iZAjo z`1U~-5I8%e1)l^Cno-eLiJW_GF3OhJJ=-L_S?$$TsG~D-p=eSEgy7ucdl*w+^H9D;u zNUr*MwwuN^bNvBTybdUOQtR_)rQ`6PpIsksjckq^NiMuW^4=6e9|-6AK;FlTouu;a zp8Hu_Lz5t)V;1&|psQqYpr(GfZ71IwIIugmkl1&*`6O2nhb+Gl?9E5Q!aJ63tixO$ zi?RUZ5NrnIFgc|<#!FEb@x`n`WlR~A#Cb90FF*dL{FE$k-Fd4dAUO8QZ`>`nBmu6Y zwlYkdty0ypZSDITble;&mm2@A? zn2hn7+6f0gAe+Bt_wLN2Y8%!_eC4&2q_MVfZynVOBTtH=)v8`y!m~*FNSE(=E z7&jntlqOm=GtY&ytqrIwCwoL%nI)t}C$z++sz)%+HiK)s!|^?h8zcssP0>C1=L8vj zYnQwGQ!g2{=Cd5^uv6}hdh;d0pwES~*-4B%xguX7WkV7z8Uo6(7D$t!?F<&ylhK0%L+c4@7vl4t%bTViu}-)*;*NONhTsSFrNken5b zG&VPf9xYq|^byR-zTZ9o3dFyjo1wPLRFmmeOShq7R^DgXKz+NCG%*ocPR zyD{Uow!{C-_uNwBH|kyf;oCVau+x!K7R25E12=X?~miIel`Z&%>Xj1jvmI@GSIL2e@LeiLM{u_cWS0R_kz85Eno+NclHT9@iH-X>a(N-6+#d#GVi|DY=qa9-ik zx;r6vCa85a7sTochy&M{+CPRD@bywp6`!H$X)npX0Gv!FgWIJy|~L0n@<(6C{{F_eE|&huq`HQhS^fH~NN6i9b? zo1U&{J@p>ukr$|v2^dXJd}UO|yFp`U1Md(q+aeQe7Up&qeso$hOjf~j1}lzp_Bodq zG+G^6zpH3}?p%5z7HgW_Y;d;pV2sKv=@epl`csFE>x63X2+0>Q%L z(c;B>qaK3^QEzlG{Q^T$K85`R>1eorz% zfr((cfch>=J1RnbuR(I4W8unJf(NU;Pco>nZg(2@U=+xBy>RXeUwX@_rtyE7hb_OU zz4;ub#q3K?SZG%wN&E$}hD31q$$Bj3V*=7#9UhVV-32_+MTb8Dm%|55TBKpCsd5&FHF&HxB}X-A6SG#aJQ_XX@Mi4-c7P^mSMH1{d7i zpJb+|QWA`t$RO3>NE6xUc}Y!NK$v(W1zrmIV`B4MdiErU#pE@aEew8XyocX`X?ZN> zmQo*_{wA10BS#SD45fvhM=-ipMaS2>?~ywnNSM^A+Wph0HqJKP;@O7-|-Y<}ZkyQ^tV(N%jg zhd53ptS-@Ff(}3gp?=`#TTo}^u8N=GaHdtJHtQGNEXI!*{o^GQvO0g()W%R6t20TA zh}{6X=*MA71#z;09o@`umw@dw`h7V`P~ z_mGFK78oYHBD<5)zMTL8$cvHvxpK*jL)VzgPATWEo?sQ(8Vm5f&un zmP;eu2XkGLSr;7q6j_*#lQU8k24mvI2WUvK`zor`T*o4+fP3A6jEk*MNaGQ(%V}vp2NiNM<_f4x2YR6fk3Jk{nKvXLeQtwISDemwV-ouxV(Y4%RL%`^^YT` z=pu8S*eOhwmG$Ed13jrP@vG(0trm;2(p#qB+AEs;N)UYxBd`M><;PZxK4xJ zP9Ulh8RGZxdDuW<8WKNAV5q-%C82)M&l%F3?(zkvZOpeyP~uHNM?he|Vl_EIMsNgP z?|CRd9U8zR$))@+z)#ts{O%(vd8S3K!uAP_u-JaCf4%ApPS6;{YyC`N1i7FWINlE6 zz+8#qPb9Q~vHT}Tw?w6*l0=cC z?LEm|f?yYLP0{ugXu(C#OF(XKmL^54T^wCTeBOfq6f)y z`3-ce2}U+Sz-o4KHy>7?t+>;sR@Uz*NimSi_JlSDI6I@&q{3Gm;Rph~{{JIsuvv+2 zNm}5Tqi+akB9L3uL;G&>eyq5qwIJ|4-RB6}X-a%P+GD=$RqY_tHyjFyTv`Iut32T`M~t|w0;pr;6XdIveZ?5rm6-&k4)DGM_*o0FfP6#&lw!m zoz1vep{AeQEy%$)a2RlQ;4CQm;a~+mew~6z`82jnDT>gPtWx6r*@vpBx%fS3yO)uH=t?r%M_3^d6PT`1g4=uWF-Zmd`h0jFp-d+|@%ugFQiU|eOmb}JqlOYI*mf#h zH^>HDx^yKXeL2mVe8~n9(d!a{>DRmkre7|KdBf-kvAP!5>ywAERTpp#fwKQrSM&xH zb>ECiIwwb~b=PuO5^8LK?q~mg@gewRrJLjIUV`24>12+c=~6w6pky=ku0LUU6Wgq7 zb(4tmeY?E*b>q(yZ&k(~WZj}WxnQ~%9~b4ACtk<$6i3hp$8Te~e}-x*wprmCo+K)F zZ89ABwczh58qp`86r<8-W*c36eB)Qxf|#5%P!)6C3%Kt3 z)V-X_B7i6!=*sv3htVQLk~Xv=<4`NwIK`M>lu3`hqqY}q2gx=O?062U3?hIErTp}@ z>0ng*X9;ae{HIjWmX5q3XJ)8_83rpoW)LK1e?9csw~T0-ir?25F`bLe3ZP^4ThCld zOHajB-m#!=$Li8Ff@``?9UL2x#OUm7q_>Q=J=wBOzoS;y1GnZMo?C&G8G;?MbY}o& z>B=D6Albitl>*;#H?PGtk1s(TGnuxwPUWU&t4IBg3>qS4+#9cIn8kd zqt`8YcEMh^d!H~~=*-B2UBS5d2!Ob$T=Mg=2)Hu+5$NTZ0G-ZQ6}FHQ<~tzTmu(Tm zB&Q1=?FA|BuU&=Tr(k#sLO|h{)A#6x?HTQzGN`e77+v~nS<~Y4)f;fhog|!E-0((M z9$}aqlO!WYtM?Mdd#xUUt6nVvu6sB^h1Kfj(6u%E@aY%3{y>cZu;n@i~P-%V{rQ!%enP*DJ|At`9b)=!Iv5q_4Bh!JQPnPSu zO!p_$OChNHm|HW+BWxoGb^XV5| zH1QWDVLr<7p?KT=y_oA;4Hbs@!mS)5Xsvy4y=j$Owd5uw{K+DGr~sQz9cHr)ifB^e z&B3uV^bP3!fd`~70*x$vjm%VtCgTnJ$8eBaJqc2&F2O@`pR&eB>5%^zI4-?D%A=9r z>?AtTLy?R7P_^q)M8+qqe&8nKcX9C6XK4t(V#Sc(`FR4MNY#+w+o3i#!q@JOpwGYM zfkV|mX~8bPeYk{C%}n%A=o~Q6+}DXiP972c@iscTFYmA8EA#SVtD?PR@*(lC4~7Sd z*(w@%x7V_npwTB&fYP?o-$e=;@b^I!$MQng5u>Vnv@ZbkyL-}D zcqn?PRq8s)B6sYXfYLH8D@(J^$V>urZ1EBC#q1~2Z?cCwR`tkyl@~jmPLduAwY-!I2*{@Qoc1FDS$lAN@(IqMC;K zDEDYKC1DeWv;q&ZHOzj=Q)boaEJl?SoAxqWb%DOckW+@j`j5 zQ^4dhah(#scJI}G-ZRo6<%=>yLw<|iP`tknF$ev;+-Lvg0u*!`K}y-g#K^se`FAa3 z6tM+}eULbHBJ@I_=gH04UIR`&Ap~>rsx?;o$vNZ0>VZ*k8}u8qtR{tlH?k_ai}+(RYDxn z07$2=$UiJXUt6l#M!?G!tLg7r_fhmsXFLQAHW+}n*-H-27hRjjhOsCEPH-xu^3!6&)9(`ZZW@j8 zmLSGRffXZ~FRp@?^_I!O?~mwiHncv@Tf*GBd)0@50lH*2-a5PH(&qO6!G)N^v z_#Ddc;AE`(=3LWH;sdI7Y<4d)P7VPCoVf-?99$n<e=9h^|tnsJtQpx zIox#h8I16{MTLS7-u;&KnE^-i2e>nnt`njK%Y6m4Hxy!o&%%RKF?5ft*gjBTa%_1g zCNm@Sum+7$aeWD2Z}$+B`Gc5p47{+R4%**U)6m9I_e}EyzP37g8L#`&kz2g&%^r-y z1^hmt-=>nCm@uN~FGWDFHwVG=E%{PSGYDlK*!>5=m-mVm4;3;nY^VeSl@ zBl(^v7@Ze9vYs7TM{ z^&H%!s9DVbj8(TGp(1!>{vkledulq_q$iK+Ag1ZyWZP0B1kSPzeA);kcMo5N*9Y|M ziOXTJ<@E(M1e`oJ(!u@fAev$JrQi-A-jFkBq(8)|@%c<4L8^v(AlYM_&*s_1m7C2C)qJq~3Pf6hxm>>*^V1vAOW3=xK>~NkV8@RD|%W=DAv#3mI zY(0*;MO+qB7Xvbj68#TJ1Fd7>J}mYS>LIGmoi1R^r4NlJ(ZddJSBD*D%OyLT($+h{!h>$sY`fB&rO@FxObW zHw!=AMmE{7(N_rLghd-hi3z^kcm|R&h&U^h<&ZpAkY1q&g*c$YhnUG6TtBtX;wyLy z&ce%d_CPWy_-#BT?ya7o5u#kdnt>=m|GD+)^bL>?9O+cA{b+l4qZ*sgtzRWIUI%VU z1_J#PJ(PbIIYz?OOJfaF*>4Z77cP-)z9uFAh|pUh?F(B?K5V6cx0p1N4CAc>O>8Lt z$hapPrn3(a{i8oP6C$?25jgMsR+5DvaN~pJW^0^uuM89t#9q<W2E($Ih#u-XhnF(okk`%^t9YNVYz)jC@vY#fAU! z7|C}P+0?Icmkj@S@juVY$2|}i){cGgO0VIoYq%{=0wY_6u~v@w8 z_Bx6`K4ymoE2S^=^envBn6oAZ*$F$aZ#t?Z|?X3Q|!g||N7)>WAxul@y0;!Nk$&?+tQo@*s_T7Q2w}e|;AK$@rm=P3%fK~ww zKc{R+F1e->|2d2K`*(B%{aPmaUl%w=hSex72!c1tum-;O2ZHRI*yfLk^O3kbHV#wa zkdxQ^+%Lu7B}$aXZ1YQ+Yy?_q;~TVmg3=JlYQuzWBrEAo5^Y(GB!H#Sw6*Pc=-z5IKNMe~s&{u*Bg|ob zIu}gL=SWrf#7N2vIwaa3o9d8cD5Gu!R@y$2l?Dk-By|rOvcU*x^>Z{A8RFxtzNw83 zo=CyuED@XP1flw$rto`734;Eq4o+Ad%$`CvgqQ$5l)G7gUuyweQ4Con32bs}j$PzN zWeclAyx{y}h$D+P14bX8W(($c@DGZ{H?^|j%H(yob0ex$z2MSJ7wKTijv2V6dQ`1C zk=|5yOX})a)Mhq+vaZC=IX()KN{H2E5LKrJ?J`YY>`=<%TRDUY>q zcyG8`n}+Xs*%&(uJ`1Rw0CJy&(r_eTPNvWIoh~k*Kd`4Rd1GifM-Hm01M6I+;v4pE z`F9(M?{u>JA;c(H-im1^$Nr)PWFa&I=UhIgDfm`7e;oA23-s|pCz=T>!SifyaoESG zplY1|9SaDjv4*s)E%hZi9K;6L(I(?w@8R0!{{G-=t9(WIw`Ml(d`eMB`qTNVYKUyp zN!B=`X$G=wdJ2ilo0OP0ia@NEeA>gs=2uuwCUw@W!1a~50gSNSUY-Rn;3lzk?f%Tq znVFVsS*wDMgS#g9tW=muMeXyxLYcxJeL!Q~aRj=|d!cf)aD#1nrg;qua+A9q}Z=lj_ zbdp2AIP^@a;`aaGv5HLeVaL%PngT$t69vOrW6> zs48)NL#aB|ymgL~IYJU#LQEqNs^PKrkx#jrO^VNQMi6&C-8>)r{H{Ld_c3a9JXqN>IOda*ayi;5u~| z*=RtfaqK*4~h5;rP^Xs{+i zLEKK%j8}<5lQduN17Dd!C`03jVS_u=fJL64iOUP{gep8y(=4@z3-U7iarjM0k~r9Q zrCv!5YHJ}^aseO0{=1%R-q}aHM}FkItn@~9#F#7=iaY}xKJpY?Ct@ZrZiN*IC){{+ z3Mg&5L5e9ydYo^0D=d?RU+aqzXZIW5Tp6Nl_5sBVh(pePo?0PCIObod?cIN}%S4j=?>h}7M~W$TeWB|}N*HZ){R1`X#u z&@-D|(X-_NtReHfkGn-8++%gG$Jpj!7_^0m-}4nblq5Ks6O(e1z!}BzuGu{Z9AHET z2Udu6Fo#eQOvPSah!kV!hW7rX*FfeE2OYN{9;{o2a0{2eZBRv z&G|NL@$x+`W#?+n{Q}>i$VpGsHV_?dXL`nnA;^^!KxQYrg{-J7{TN}t-(bI*N?nb4 zEaUyHmBHkhQ>U0{y+|_N;<;aLLmAZxi<|wn?-q0+tp$0lcq3}hH?qGjqd~~|i!5SlZKn<4Wif~~ zik}8jI30fQ>qt~*_89D}tkGZ};P5*7x*dcs*$B`Jn%Jtm+IvR)>hTGlr9l@I7MuP_PJmn1QGZ&+gexm~|?INAc|2A;8I@f(OC~ z>>J3@44s6ps;Iy?JbP&Q@6JhpV_>pxAm9RC=Bq0bC>7@@(FqFkyFi0_1s;-ro}l%O zcV7e2tA+6sBmwFOVR%jh!*_GFI%E@wc!;#Xn9et~mzNtZJHs=s zD0&ULZUkJlC|q>|j0^7tOP_fDKx;pw`@-Lp9{^8)kM7pTkzLTi(POoYWZc1yPW?^V zm?gL%--|+m=xPb1B6=vY!p}_tNN+Xif^*`fIm`nIOoN4(2Jm<-qP+m?7c@ zK{99u0)fo*lV~l`KWmXvvg`I~k%~k;FZG$Rj5#>`IU| zoi|+ot)soWPJV~9KWV>$tY4Sm`&pE%3?F(Br-h^jIFOZ#Y&s|}(2@`FLAWj<0Cm)h zp*&{zlE6bENrDxO1qD|L1Ym8`A>SC?UNQ1$!bcU#3c|8qjQ@>xD1anAY9dzhPgWjy z*9q1TjwAsE4vDf|-~*-Zpv;xwgwCsz2w?|w|DcjHO>y{MY@TF=!VdudcF)}mJ;?wd zI4m@iZ>S3)U%~DZ1rVkM=fu!29R$|@P*NNsHI!KV``j9op$w-e+eP=W8b_FsdB8b5 z1;K8UiiAU}qD33DJZAwE0l6B1ck%!qp!EaFfP{}^jio`TVq=G&q&{4SZ)TBLgAYkX z-2;`-{SJ523;w&xx4YDf-JmDvko9ej5Y`UtCq3hOHLWq@BurDoMyb0M&hvtM9%SetH!tOBe>08syf&8?DSO4G~@(M`9eqiYSfPpinOp z?wSNrlAjj1U(cU12rQy}+FK7oxEQIV2iUGHL{zc*QAl}*FG)^z@IlB)s|>l+56rps5VTduDgvZ~ib4bye^IvysEA zj-N!U5ayxvAc<1A^C8G|gJBOmq+|O>q$Th^2B`tjzE-HI!0?H?kKEVS59#Q-Mv3A5 zbND|XRtA3}Q6S;IB#KYslVAA(fj|w%-~Jmuzk8*XUt4yc7_jQIX`eoyVaaXimg@L! zpCiYYa1PDtcbx}_Hohs<%ymrf>>0R?BqX%k=!-lla?Ra6UiY5R@2M5_x$=a)JKt+V z?AY+L=T`p8`=#=Ax}!IG!-d^9M1*NFVVIaK?B?U!-Q83#+d|4L zyfpUKE#a61SS21ifap0Kb+XMJ0YdpZ-C05n9w9u}B&~mNLy>I|Ds{oXLOKWlIC=NF z^fTo}`s?9nXP0S+1qWc2h$txN2CZTy2kaJX>@@sa9W7!~3w25GX~6^EXvOaSDBUJt zKZaj83|}21?SVIQt9%zENtOT-UHHStN2Go0s3PP&4%e)EC$Gf~(RD=7?keN&rjGKh zMdyRvdmpK;f<+k#ocm3M@;H_*RU=LEq~nwsnB zN=tRC`RS_j)Ej=|J)mM>O1rQgakzgPH$R@^vom9R(lnXYo)|_o>mFu*y31B{+u)(3 za3a+hKm6SFH0jbJ>R+e(yI-Up{$AqGxMhB0!i?p+tvpNd*~?BsqI zR0;59ff)EUx~AiANN~I_Zds3)Ix*y*8dtV8NwZ>E^3yLNXZo*!Q+v0rzqiRREqhqd zo%NP!42d;Y^4-@dg5IhXhI4c5QsYVJ=~ZB{PPDvV$3w^m+xYa4p_1$Gw@!x5wI^49 zkxFZA5kClzM&NfLcC&;&%ZHnC-t}|H=V|G!6`xZXo1b5_agcA0uitwXklo%~EMs6O zlP*P>{n3Zi!`e*aFM)T85Z3)zudJ_$GVd|itp+c?Qnr;;KAK4t3qthY?k z7HcKmMV(AR-6bJyrMBIr;_eqXx1L2Kz_J?(g$J6B9IJYsTw z7d1X3=B-aXJSP_PdEL#~XZsH0+)wWGYo4DYMZ*WDmluxJG+ApOGv2bM5MF~wY&3cw z)#crD<@yZYw>hc!^54EidGn(EPGg{(bSJl6Rw-wbN;sDbym4L^FLT3HpJS zCG_7t1t{kk7stw)7AJ&MUKAFF%kqZRiXGMiM{U;`wf2&=otW9m?VA#rhzuW+$lT=#9-au=o$%TH*8=-+P&&l}0fo z?NyQ3hGOqit36FN@Rr$^yT>r!5rm`=>S24Qf~dsjwkOlgMJNu;M+Iq~aVny z>%SA_V#AYa19Pc8w1InJya!3BOHb-MQTsrO%`e3@?>*qXGf%oD%VLSKpnzz}^~;9C zlNT>lv^Hz;hN-2-G$G~$Jz)?p)nRFj@Jksc8a)>pE%(xEU;TM`jp8;Wk;+<4wcStS zGR%3=oCXuAO?NJn-nVD>edX?a=}M1T_HK>5E_8M|V*l|)n;8E^UCIbZC>~6EQFpK2 z)ll&KbAwkiL^t%D5Q*Ni( z&Oc9H(ce2fXZ}?W2;Sc}-*PbK?1$NAwrS00i{;Bz55%Hv<%Kv~AOz9rH7rp*lK9QQdwrYk2@{#{QMkbe{NWc*tA zcvAA}TIC&Ja8O0lheR(lf7KvKp;93CB+IjALQIMVTfBY(3US(3yv43s9lzNLfiFrs zt}edR2RrY(pHZ$w=a|EJ2nM7Z5;WdWq_sLL9;%p}PB(wnCEqgLY~_LsZ*uj`)6Q%& z@=`tZLzyRrT8$2?7+Ia&VMNUR&nvy#tY|m#@MM%o@~~$WIfIsa9-BSE>EA9tN(R# zQ`0f&`)>KKn|$G2g11O=x1qW=K>o28ORVm-LLUK9;pjwDb_P1JN3zaQe=?L_+NJZQy(C zH&9=IH-}q>HSOLx97PA*WrW#~Af3|%fI*p`&G(}s0JT!2`jmKX+-#e+)uhenKJ(_@ zs|@eF11~*6bCLm#2hX(23iFmjq!y3GE#&>($P0b|N;~5E)ioiikn-!roA=DV4)N+7 zS5dXf{r^4V4ENBuLb?Z)NK@wwkGNzP-Ljf+<*JmL!rsfWAnS@j&-G)FRo&uCimWNcHsQn~nb338$GJ9yb ziooDcBkBba=A@;FY7fia<5I2haRK+VSjK9%lTL!@%^pdEM!W=N61@l>u_6Af8LqFB z2dO|TR2n(4T|2~nHJs~so%Lqgb0XXhdV>V%4M}#udDBl&&i`@_m!yBN6zN%S7OmxE ztDjvYIO7+mdB3wGsH5)%x+~2@5}`PfD!y52hV0*WWL+**p6s@KS8IQdsMJqmsCkLu zYW}U(Giy0rC|_Ywcg~4yk2iF=r=gYsP{|*pYW3S4&%!6q zl@`1z+*J@;QhrQAcOppui3_vZS~^Nv+Kj5G(I>tN(wv(!;Ti1OC>CjI240-3bqbCp z$V$2z<~QTf$3_0o~} z&YU&wnrzKO4l36dw|P|jeOb1veL_}^cQmQ%r+><}n4O7$ZUl9_y!ksTKE!Gt4=$?F zObr!^m7S?lI4Gh1CFwFI)7m+`3(j77BE>dMtW&{~>W8)OpIHMX7_Yq^iEaRvS7Le! z!-&kFFLN6MfcaHZBz!-6fpqR-gA&>~TWyfMF0ZvjAXC}5)QWfQH@kwhHAzupAkoOc z$g3H1IhmL|n4LG?5Y8_oA^rjwAttbUz4g{JN&D?XFRpN!iiG0`yunY#-KhXfh=0JZ z2-#b+DMlN|kcJSOs1dxnbPiCCYIFuN20tD?!&Fah!nU#*vbA_Xe0r^Wn+*M~`4;IS zoAZ6%9aNO*eJaF4C|0i0x*pc7$M@FK3F)rQyL@T^K=5j2M2-z&_fBfidE2o!(Did9 z&h0n*D|JK_*(9o%l}gV$Sd;8=6o+R)*UttiH~%i2gmu(*bx~sLfBddQ1O_gxfv4Ds z@xE*Rk*us!2rFZEb(>^KIJ%p170fAN!R}8uw=6M6Uj$g_n2_Kp)wunpmSxxhq&9OM z8AtMWLBo)ve#jk0Qd%|>*kxL+;woT0f(sB5`^Na;(J6bztlm%@;cfJO?~-7h)Y^wq z77u;-!VbW)tNi~UF}-Th7$L+0+Mzk*xutzPk({envHc8jidB9R9hcgbM6@MdpavlH zrn6x5wN3(taYy|?BFcajg0~~tO#>UMDi4k(0JFzF%aqSRI#>z9z|vjK+75DNDTnV7 zNzfy30>^K+tohlSA&j)|{>AcS_o*=S^VJWN-W9K2TsISBQv5B_!h;1uPn^{bwM;=f zniXK5VD*7VHHw6v?PvAt?hO;CxXa0S3v0y&Cp4&sv$B}7N_Y@Rx2vGt5_~jOFx+=% zQLxtc-TP5QIs7=oKj!G@2X>EM6qW}^&(Rlx&H!UJNKXC7D7JU6L>Byxt`=K#z$nIX z_z`=T$u1R{#ueJh6LcUtXC+Ah+WtL!eebZtZ3!0qq^Oi;Dj#BL+hHUuD+BTKUKB(f zh@0=A-qha_fwD&sN5!4@p8)sg?KDLnlq-FR&(mitKS3Oz$F<nM{0&1b`OFxF($bKhdiY^yEIq{rwK(_mWVY z+yBV-<6H05>zQ7VUW*Y9K(BC_Wg<@lv^W?v;ZgY)N6^LHwr}gOt$`DpP>{IN#}6P; z<4?rdDl$>WJ8InuBLdBW4S}8~X-+!wlezw*9-z_1v)lKE;RvTcPbW^w41e_b#g2!q zrE#Du!{2c1dPcV9C}4&S6w+iv7qRFZgj*j?caN`9@=S)q??~7~OsgqAE@LOOyr>rn zv=DI9LjOl*A1@%*d{$i0C(OP=m8*pOqaMiavK~F-D~Myv#iIMtdITM}Ff7$A1-aat zkqy@`_w#?ZCijIToi2iOVgbV;6MB&W^Q-oDf9&S*8Dub`Mf?TQ)v13XNsB^Ob1|&c zR!DVaf6dMRSzM2WkX(+x4wq+at75bZ0VgwT6BlM(TX_tet$5QvtN3{UofaL3jSJ`) z_?9AkJ3vw&)IWR|9CQ^JEWh@ujbcIQmq*P(yvN?a@i`g`GvZJ9S%8^2@EgJhs3Tsc zNmn;tc4kfq-H)kd83nGsr>hQ90nV#h(VEDMmbBQtl3&i8-aP@I$7>%ldB+(7ubGuf zc=P=4Y$vCe2R2HPg|78*_gdcf`QIr8PQ@2y@7`g(#fUZENJ%tg_zPeUb(_}TBc3rX*YT2F8T<|l?6*&kR!NYqp8>X;z_3B$i2Nh-nz@HQ@o zv{Z<>roct`=HJH#oV>SOkbBJaWvy7c{FJj9+}_8p%E)%mae@up`AqcxT=arcz=3qd zYBgg?kxkjaEr52_NGg!oqF<{9&C2}1xUIY8ApxwoEj}~8d7;eW=?W(p7u~R+|2`f~ z_*jjY>h;%>Ouzov?qv{{chA+wSJB)ry$XT+CJxX3Awd=2qUl;-9(dU^q@^>9wu_x7 zCN$_hyIT{5STN#QW(l8JFW`W_eCS+QY27Y!?sVrH%=zbqyV~1pb16AJ2rMar%dSo$d*l$w50*d~>e+@kzu=KD`@&|qOBLl_5`Nxd8Yp5m zz`pzA1@OKD!*Zue1;d*riOeLzd%f{d*Nt;b$^YKdNec^=Q zHF|IKbLf{3g@wvvDx?j^ULhSU63*Y1jtpNt#?+ytNUca1cX4R_z-sDh?2HI!Q@2(& zynmKcD+v}CWVOrVRP6!=p&M>3q)L+_9lzJa2<*BLuhcH36*1+Vj<2#g0F8kcqfO-+<9r*sWR$&gP!~h;AHF|h`!>%iH0eYDJW=AenQ>H1AmSI_} z22z#>+kNV9c7pn%9Z9P#`+6UcKA}PPDYq8Z2PiQc~Wa!y@annk? zA+L=pLiER3-XBCiXCaY?92=C@75xKV!%EKAL7M-5$5~_a5H_33vOB!-7V#BXC98J8 zOp~XiVD+`SNcFWm&a zlseNsXJ)qluf1yxYU+r>*P=s3M;kDxm62&WQ)o>a3(g2KJjMa762-O@vDgq43WFM| z0SY8yMvIMT(5eUolqe8X5Qj_57;}o zv)MiOobP<+?76%9tx6}sUpP_~1K5SrioZhKr1lt^HU! zW3S_C{0Cg|ob1nI;GqKryfWog z;2HoXWz_Mgr030;L(nro)0CMa@H@Zf#V+|CnGt&-$+OTSRo!`zaTgSQNW3V?N_~8!yU%^FIaaI zbR`KuA28e(#lE0Cvq^yw(7iFOb8d`dpgefo=O+ggm4U~tB#ZMdbK$K$#^b3iSnD^E zdX@zvExZWHaQkkZ+bOrdww?vr+&zs1plI;Aun6#E#aXC7`p8;fYn;g5a^uKEfpZl0 zF)3vFE)GI-rxD?=RX2q~h+3ufgwF|B2uL3cBsEE-k^iC0tvg~&^IfIp3%E3754$UD!y zku#4tNNxY_l#hbK5kYBKF=WM69Z*{CYuHoX6t*)1x|SUWwJ-z?4Ue$$bs~5|;5|s_ z77D>W)`d_;<5hDTpi=4+cS3e{IC;u0EG7vnPM z6Cqil9mtGsD?!hEe92p%L6)rS1tmS&Jyavf1(s5pnmjF+-J5~8kUCB%w23h=)}E!9 zp!I}+Ash47eO)}?LnLf_G-Fd6{bPwApUzHw5$*ta&4c<|`l~S9F{;THO_5(0p7UAB z+jTT8Cu3&cZKM?Ja)>3970rOU;L`@|uuV;VfiqBIU7jJCHRA zoUm1sE9!`UET7Tw6#+}z<_WsNmhR_HCdFNQg7ORuOy7wTU?pxN`El1z4konvt|U

yZj4a z+&Sp*Aa2!ph6crB)@h1>vb*{8)k7m%G`F~$i&PBD)HnyI}%JeO1C57J8z zf%F1G^LT$~hhee=afXy$sk0e_`V&n+rBL9L58F)-RKkI5ye^aL;O3lNaD*=`{MTa1 z1urur5Wm4nuY>57V5$;lhLnc!r3MaG;ouK3!!L~jjyckxN#)?Uy%`Q%({eOMJr8(h zZWm`(H;Nwh>n1FN;Bd5RNxgAoQXlG_unHUo9K$Y!0_#wdQ6E}Wd1^488HuL1AOg#R zev@GrwWMqA@CWK`NVk6O1q_NbMFD>AEkem1_GJu#gz65BERwn<5I0 OdyC(8-{OtzqyGX}z-~YQ diff --git a/manual/source/img/FAIRmat_new.png b/manual/source/img/FAIRmat_new.png deleted file mode 100644 index e5b7158a781f014b5c2a7feeacfc72e32fd507f4..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 10334 zcmbVy2{@Ep*zk}r_NGQenqk5_b~2W%W1C5XVvv2T(J;eU2HD3FLa($STgfunUt1xO zrGykAvL>SJTh{;aZrAty|Mzd7>%#M#=RWs#?sK1eIk!xV3^>`&uz^4zPAo?EDhR{~ z27aNe%)p4XKamgk2PR{#Q9vMRk)vM*YQCmF2*kAEZf5CgiMy=oMDmm-IFlS*q^X`{ z02%~R)1;CKPB&b9VU8|t?q2G`OD|pu!`z+Kg)J0uvN*Di%XN25kdKRLkdc{F&N|TK;Y@(OMp>5iCz>{s=Dx>cvXStqhT3g*qgxYZ4|r1-zV7QwR+W(n2ndi4P>?41xXH+=sHn)u%FD>hO92p4lt3?E0#(Y3BJvLg zT^EXzk2~4do#X{O!bor=`T42~1Kj>4h9~)7v|g0IRRt(bhDspI$Vtl{iS;L-v(vwD zWIrF`pTwP=WL$_Yo-SU#6aZH4Us&>Wk}rvJo%Fv!{qN`hL;z4P4)-sO|B@F^&woi! zeD(YRG5%J_e+f-73naV9Ty>$4{Cu2T^!x!fMUJE)tLpf;5PV5KW+W2vpT#oyhh><& zqO>eb97k|+_c{{dxBoE3MVH{~qAq;2Zc?%;Qu6XMDM3NW+1XLb)lu0=>VhIlMM}jb+JP#;>Bzp-g`JKT*2P))?_u}B}J?!Uk&Bv;=6f{%-~ z8=$TK2ZNFU*q1rli+@QX^FIsu=ePf`Z~p-YoWarKzn%zq`PY}ZcmWQ~2k=zqm>!@( zAQ5h?uC^I9^XHd0{?nGF$4z!h_73eg1$4_>?wwEQZbYOvilr%DLV>8PNO=tnP0iC2 zMb#=AUg~VF-eHrs4`1wpV1>P>4=-~jZw;!)h|!p~7YB~D>O9dPFbJ`Nmt$FU&n+!h zsfNF#F+CqS$)%>Y!*hmk0y5XFlat-JWn-D62#-kW;RxkU%%UB)fULJ8BOwR9IttzI<+a9mI z-PA}J9436>Y{(FvigD#svG!vvz95V+!L`9{S6)5e$}E1Q`2>b&RtO70pc#KY`sFEkIu#QwxI7V+{qntP=YfoZv2`Ft5V}} z>++XkVtNaK6iRk2_pEC*{Jy}bbP@te>VoJ_^1vhJIlRN8XiVWwOeSwnLgt!f-7YBV zv7;Gn`Q||v!C=rXYvvzt#QR&5T;)+Ipz=pKSP3-a7rs@H0Pt~y^}!z^i1&90y>=ck z_W-MtUuPKOfq+8AOg`L8(Q=E?Y?c9V4>Dn`0Ngz~po!yf2Bza#rldDA#*Jwu*ZcWpUbfi zdPh1MIecB;4{rJF%Q&XW4$dZoeLGXCQZ;PyrE4SmohX4zFIZ+Un;uxz*i&`jzb{sS z*K?_^FoGL_|rbbOm&zCZ1 zM9UB%r*!Zrb{joqJ{k1*PT90{qY}99gX0sYq9-A#3b#w}A$?gV?=L*ZUJv;wP>FXy zymBaw3;Ddc#r6dS?lUEPb)q+CoO3J6uFvajp6gJusZB}Iej(ftq1|i8C@SU04o=TZ z%kAZz|Eg-2!Z^)Ar z)=A!ZZ{y)&zem2@;1ZI?i=z8`v?%2U(E0c32Jv+xUR-w{cOzwe_l8|Ln8f}vU0oDEgj{drMFGJviAMG z_UIPPcwvJz{cn@Lz+yHG6J8}^^)a1p`l-W0i8BO0^}*n0Jqp@VA#lXa!4hRv?nnt= zdcj3jXUgqNZdV-o@Jk3taJ4>DAn{6upL*#foiO$Lg@bDJONx~{Rw8$RjcVWYVNx)l z0=r!lbjO)$i613Xr_UBl`Mon)a@&z_{k1|%S+7D(O+SYaU$>rt>G^wQ$SmtNrI{+EU9yMYF8*87Gs_#Ttl*bj=4uZG z{L12If0OKQV7A?@>{7Y^jiSS8n^7?(7Uxp5QgoxtV~c!k=SwU8=~}5}fX*HG~)(daEkw2&2Umcf`{LLUYk{B`)o{z z>cM4DP-+g=(C!!J zThFm)DaZ2Z$Zbw^D`;+U`P?GFc-~EO>8SYB#kO9&~!q4Yy$Q$!{XR!>L z=P6zTYVbotdmmcU=qu4l^{BY2hVMzUK|c4IMzt_h9D`hXkgBo0e0tDMbT6moZ+xzm z^J@C`@~KTX0q~1aadfK4SdZTna%VLH*K#gC@&z?25NGdmI^>td7A~?Mb83G1TnP5m z&xP_e(cJxRvCKu1OwjLfR$DGxI7Z$672NZYUud>RO5k$|uXKrL#~jvSefY(fwW_f+ zmtO&EoJiqan|V&8x`FRN&|=CWoN!)}$2P4bQb;7~M+ho$9C352LY&KSEhRco?HCZB z^!^6Pdux|5oSdCbi#mPNi`p&5DqM7-d7bx)**yI>B4jL8w%&ARhaP12HRk|TjveY5 z;kKBUZ(fI5EPSxm8AALhXns)QbQ?eRfG6tA#b(h-K9c4;hw$%G?H?_~01b;gl#f*1 zd9&fb1J3yiqX@*J8<*TGId4A0HwEWJ~dpm99$3}3H4vm%)RK6xg-US=yqda(A~+BzEDQhiD( zai&T~=G$x=jTX$x9zu=lp8mW^a2?ad)ZNcpdezF2bb`z4o3YYpZ&@`#bN_0F0}l;{ z7KBhd`Gq{P4U?vypeV9D88j-9x9+o3Ny(w+eEBBRPe>x9xM~0TgCOBg-$@;2 z)wOZ?Q@k6L-#%!j0Zw~7G^rf#a8F%vqyF`GiAEEHyXj|2%x;^rfh7nLor|FpLM6GZ zA^8Ujg%`3d&M#E8%*I$C$I9bx5A>a_R`J-l<{16f6B%YDUNj{-NoOT#J|0Gv4<=gG zKd{}2JLg?Pnd@}gZlB%7kNVV<{PfD8l@XzF4*l8walX9`+Yeg0yn?Bs&=|Qv{%TYe{HHDeocR03OK})0kw49@kHMXwyG%GE|?1G z{$PE-9B`c)p<`dNlg}U2Yka!4KCQkm+%CPVVzEGXDN@?Km;Y)1;agF{ z3l9>7&UP%PMdg{sxr5p$Vq|{2E)IIT&I_GA_sXsD=UnmhDtY*rfRUigeTpK3M1mfQ*J$CJ%q<&j+ zK!GV{qmnkBo7G*bw;z1Y^MqFV?2A@l9~e#wiP)TY1KqG(QDU$tZ+rv)tZ<$Y3zVB`C+1olwHjA%>ZNm%T&ko1kZ`z{sOI@9@<2xg{V zd_)2XffzMh>6joiizs?)uE~MmaOQ5ZCin5URy7VZCQi?(d7r6$mr7vM$HW<=j&`&% zED{!vpGUmTcb^D~oZ5I--%O)z)1q$#Vwx4-)iBX$Y8OtvI}fwdQO4+EI`t^8)PinE zuSvk+aItPw>_YsmX6!=x-Io);DIMOLmE(|Y`d~3VSMrqz@pvECQSaa2Smm2}!vffO zXU9S}<(h})DSZ~!-|3DtS`aOIoZnF}w`}aA^>HxRkKbdQ-yt!lEcAnQ^e-Gbx3`62{N+Sadx9feL$Dg)Mw+P4O3O2BI%54>UUT zQB3dKWw-z#;x3KWpvsw%M$qxMZH*kmUBYx0d?a7vmo@wNb1AAEj{yeqKbl zxfk@F9;sl`Sn2Eg4Pz-Sma{h+r!N~~F>yE%hO~#ISHDJiQrj7xFN1|;0XM_Mlp~Vy zF`NjQdM^kl}2s7w>>`d(^vA#)AF3*=?W1y@Z=F5vA>%=eLd7AUu_=!g_` zq|#_k#fl#)ujjoJ{`A(>%y#3Sc=$3%A_|W`0O0i`^FJDg}n4NQP{0j@u>yE4R_xERv z??|j?77tAELW9c_;wk!42LmCgCKWtL6!A24!CPiLmQslqFQ#A$&EC;JwPjkiS*f)i zF(&@h2^edj-)pnhZ3`02-yj2j0lACvs&T)qD{* z(ku55r!W4I#{OCmm7XK^`7Zd&Qkb;GDLJ=W`Ish<-zad`t0R zD0Lb$0&={2=;L*EGkfIu=MyWzaa$}@bFWs@Ewx~lI zPPpd51c) z%;HalL3@Un?b0bSFYjvcHulGz=kMr_p2Zz3=oShzw(7{0aFllC@hZ^G6T0$*?2r7y zUl`1i=Vc1ms<$vwO>jhmg}ZVYExJK|@NrO=gi~YVV<9CTNKKboru_-t)wk=|%ONvq z`R$t~$ro9{yDn#XtbYNV^+nOs-%5Dk9_0#g^FWerX=Ems<2xlB)r%iz3J<&&_gGELt&v$tEb3Olir3^J;3)_tPGAq-gH`-jp*j_iU9^yHYLXD zqxu3bn|MoC-A)Trr{8AG^R>EGh|@{pvHVa8h?w`*sMJTx_`( zqF3Wqz7X;5VI)-64qKaFCnRV%rh(BB{jvcwmb4=Y5Lpe>nj#P zD*SMGf!ATkaYDo;)s4kVOQPoyUk5w^*WAMR%WrKSz8h2>0LhEN9DQruTpI=U!>sMr*%9-NHoY6!DzKf#I$6`n zmsjJ*RC~;GS>bRc9U{lE+hywm%0Ut;Kxm^wsfn)|8v4Qv z4-&FV?o`=0@15ujJhkkd-L<#i#&hykkecX%Slk7`ne*`Utm*3^sywbdN+vj6yai-r@xBdy z;YkfOG4dx0TUUs@%s^G{v19!0&6tya2Dkfq^chTt{H5x^n*td$3X<1xJ;EEPUiI}R zKNlVxOT7K%3lYj(j#Vzbs!&pS;bWgth2*S(jlqJn;ZGOUPbEmNAQ=(F4~vS4O0Jk^ z9s3#a8`b!GYh$LAYYPes-iM-wA< zi^^hvO!Vp1)MrQ(c9Rlh?gqU@J<*Y0UPZNReh>GzU+&!89+yUDk@BAlz7?H( z5g&cEB6q8kd=R`KJ)Pk{KzT<_R2V{DAfzrE=R4Z}w)wo02<;Jci&=At}8+HOK;&3|bWKF1bPr;#YW!80qU zP&d-B=vOy-%H_5clcH_&^9f}|FBaD3v|jAi73o=G@;=NmXY)F|P~V3Xl?k6^pT%dA z@;&}&5zX!A{6%-1=BY9d3*Nm&ZRj@*q^H>BG_EhUy`xprKx3@4qum=-z<>t= zk6e{H>!-10=j1-&y{l60;ac{e%A?@{P9%NbL}k-M^f-tBuACs08*HTf}95}+}7 zzj1wr3kBY#1{2ti%~|dIF10?xfC6`5@*47_7az+6>e&hcp;eL+pLvXl;Lh)9O=@pM z2^`Tw_iG31M(;PR&%jV%aw5ass1n9Zhg8rmnDrO6>W7~A(aEW!y*Z(sn!U>c9MH>I zWRry5;i&tyK-GWkl%uDRs2`YpIVOdi6mD{#1#@oE&(?Jvi)Oqz8_{=v*Df`O9I43| znAt*aI~M7(Vjwyxkik^Q&r=%Oi4QLPEIx3xL_@|22>K%Fxl=k5J)dn3zoeDYyBSM> zHpi8=+Sk43d!i)YdMBEd*r^s<-v2lZ6uI877Awy^{`9zn@kEGpwTF)?5Xo}HHXylT zI5zm)Tjegb;ZCW!q-yy=V*}e`OS>7b42k}5NG*S)onqKl+sHUU8GJq+5T0nV}9g%QIx?a`k?r9|j_r|($k>+Kl8*~y>!WdR*8v@fD&4bOYV#0%Ul4H=%v zG_1mQE?pCGy|fyP7gU2TeY}QZuXk=Tt^vO+$5KnsA{NNKc#;!zJl%j!4M7g902OQB zQmJ9Y*P48Ws+Wysg7Vjv+H8r?sUlyQdu^!6^BJ^R`3s96ecr2^kwd-J@oi#p`!@8Y zJ=CO322E3*;}@O%lUSUme7}(e>f*?#oVC2kMIa27WQ%Z83tuIdO}&Af`g{`N^WMap zI`MU;slsA69oUecPlGbREQ)o>-qc^%oM23+mdKZ0oqQoeM2XcPb~fexPJ7iY7Hr7k zN@D}l@j(@Yb56wKb!N~vdvFDIDaiyG5jq^~^Jy+5lYb>p!U=6c}cKttPd z2yf|ZzIb609Dav^ay(mkOBIE?zWEw;U{8Y#ECTf7wxPNnZ2_1rW>*bVP6+H@^(`9mO^rp{ZG{WtBS z%CkSJDf`?INYX`9-}ntRoH6hGx?SlZI5d@H2P9^hCC7`% zvt-*_E%z1xFfE`6*BDI4*HMO%WU+nqancCWU>IWtO$9L=Tz_DLYqXsmt_E6{TmLGQz?0DZ+h_<>ztFf?Swy? zadct2>o7?C;LcA~XYk|lj1(g)nT?MX#Zm6fH$4i(hr@_sSod*&egpzp;YJjgPq-*tp-uN6gaW z;c4wOCggY7oGJ}x1HpjywU~YyQ{AUR7Tc%gDKp9j-+9d4(U_cgj;O%)R(T)G2j0Xh zy&G3zf@rnCJlPZ{bu~AZ`O>4n0?mVE_cN`OAG?@p$Ed{zH!>cG_DaW9aVMz-&aN!_zlA&FZ>G)L$q_eYm zMuNa03fx}c;+7Ty*FF(Jq}POKMN# JDcT|Oe*jcWnZN)5 diff --git a/manual/source/img/FAIRmat_new_with_text.png b/manual/source/img/FAIRmat_new_with_text.png deleted file mode 100644 index ef14aa0da6e1d41dab3eb03455e322097cc58f86..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 29306 zcmY(rbyQUC_dYz-P$Qr;0wUd=(nza>K{wLfJiznS1Woab4Hm$B!CnO84-n@E{P#Jr!m7mkAYKBaSZb+WXvw}3!cV*+9%l{;jpyNqAueIdmbCvoZ3py}jhU(+en!Nkui87&Oz z%QGI$eXQc*LSleV0O!=AF-Z6Da3;lUBP7x$XHg($I|@|!tPp|SbK~uG;Brntl=|jt zswAJxBqu{gXn6f~A%(XB#1sZe{*?S5i$J)pcT}0*#f2~VrtZ@AEp?D;+gpS>V-(+F zd8kOJl?YeHiIhud0@M48bno$O{0GvmhMt#^ZhfXms}B+OzL}!(oQdCc_RX|}U$0TF zg?_P(=h-mO5_NLXD)N|WW(hPc&n|ger{+e2%lY^tiF|KC&O3Had7DXPzL>8!bs>SB zNBO->aYg8gQCL5+XG-#rFh~dl=|5U>2d>~c zE9<&JAlwY7zi8fh(w^WVw!6v;1?+8X3VbZ6w{E%}1VRT94CzUj=did~5FbP>cwKntmdGtU@Do*=tMz%c6(;XK?0*8($KM)M<;opv`OkEVk|(a^_m950aJo2@%`Wd9 z2kna6PVe2#k>bixLTeDTl+*{Ii!in4%r|h)5{~|hHkv{?(Cbq(yU8f++;Y}B7Ok)g zO*Iusrbx({7mFC=)qUQ!UJu57IwH2s9R#bLxPaK76$nIXv7`D&VdlBqT|`ysgDb0^bkD-#jD*TvW+t?PM>&`@z4`Bb49uHjG8wTj%L z5J#+sjp08c$}qmX7BZ6_;VS)49j{ABv6BXqKJp^VXobfq#4FxeI=X(wRFh+0dy1k| zgx2Yp#(OOF@>liuclL|U5e$wn7CG1(?q__Y{MrMPkqR-}5d`5opKGtDqgTnlRxIRPAcm%;p!!LiDw8@U%m{Q*yMBiOxhRgu4X^xeK-scP;~ZvpVpd*U)*>>d^%~O*Aw!}Nvu{PDasr*PQ2$DI{5;Bk8uu^Dr*3e_-&Rka#vFi~ z&FsyJl^4ehVr6kAcflisM?&;qzZC}WwOD&_ROxP~#CPv(+}6#@FUZn`W#cNkOz~8W zuwOjsO4}tC$#NDDrGw(g-#?!*)0AQ^Lc|Fj9{mw{G-}Lwur4suDfApz0Bbv~AcReS z6CR<>-YG27mAM-y{Hmrh3`qgLXUJHB^ zKxJY7!7ZOfAKAlysizRPYY|DPhxBxsP4|7gZ}-G7eS*lLQl!AQF}@9r zPlhh+Cd8>`!6MqYq3cXUp=a5@HQR8h$Ev)dgdcS`jfH7hp)U4emJPguyE>vr?IRet z(l|{XMx<;L_i~fl4-?VSNYk)PN*#1F{i-4$%F0##Khr^Up6F|fNc)BtR6UFe<5I&m z7iSc^I?>ruH;9WC=tEv}CHJbc>QCAIKKLl}!+p++9xc*;Lm^!hx+Hu}I#MEj@$N!; z1VJq7MAkqt_GIhg8nMvUwjK#10L~pF@u;6eK_#UaU5)R9Xe_h=sgAcv9VBT@-ta_Q zBIaJiZN7Gtj5Q;nURSj;$|DmAEin#rHzr6Jgz{HE7%zM_PG>k5lc0N-Bp}vmEY5Ip zVwN&;Ka7P#XG$4H6qA(ms9)Ih8_pHrjkc-BdGQWl+`uK7!*Z7w37`c}68~4P9p&t5ni*$r! z&UATX<6xyXBqyWJD*j04E3n_(d(gDH#89w4wzu5`rD#V~^kDXX?h&TR+fZq;GK+~i zp}dc6;B}`Eosl?dv}V(H_r2SPJhG2`+J}H00z2`E=CYh+h+GWP`roNuU9^fo)U}*x ztnD+4O>`Mhvx+?Uib0sV#4A`}G5p;n16H8rghb^nXXFyfT~F-Trys0k+hOFs~8*LpJdT8{d)xr@q3J6W(8_jMTVhZhm^BGn#&)MP$)mtM605$fs%bQZ-fb$cK2Df{S8I8ch=BBw!M+ma@u!`0cnf9LM`r=t09LS71&ubaUZ zDF{|F)>~xmPM;->^q2OF7N* zJBt>+qAGA`foz^$#r3kcyHuCXJ~)LBGCkp`tbh3$3RO8LmJr-+8TrNFJdM(ZR9DIl|9Mj-G6AN^V;0y0j_9whjHOcFr zb2c~vdEi=iyP;y2Jn%aZA%J+Yuw{Bx6TeU)DAJV#^sTZ$TJf(1iVITUgdwTz!@44~f z+Va1))_iwO>;Cs^<1{j2Sa{g~>zG#2|3vGHLHZ#f~aRJ+F}0lF6vNXI#K!h)fD zrM<5aOiaU_z5^V+$BX3x~dmq zSN`y#_#H!9eGnaX&^_f@Jb#f4yZc`=n+IkBoL~HaOPvtc1@XciXy`}iQrplVyFMXy zG%@1UuUCHA9_3xo>9fB|mjHot<&_hkXy_*|J@zkGCn;I2G{F@or=dK1%Ct-i>UQ@( zrLl{noE2IJf*aI0t)j6mNvTk2@hoeF#_sto}^(R&)k;{Ty3QheC12 z4E2ZgLsP9;n4_joY?#W2M4pok8so3-o-tze7yhA%A(tIHEyqoM z10DQH^ypUp{5YG`yYfx^D8Fdv_lF&5jc(WEFQvOL1(JUL78=t=m?T5uOB2tJ>i>%6 zKTd2;4J(9O_Z{<0mbOf%b`$i%lkpHjV{2>e!{kyI85x8iF|W;kCj@{Z1;KKirh z?gG6DPP6-5*kiCJ6lGD39WdZm;-q?WA#AlbxyQ?L1I6i!4kP$b>FSH7E-o#(=IiCd zA#J*ZC_u6ZIm4<1=SFH;=Xnmc4PLH2AIvIQmVXnV?q*<>(6C#vMnp_z!P|y2$Y}PirkoRNzobH+)Fd`FX+>dx?khQrpl|<1GSWowHkU8GX$dgLOju?W1{e-k+XQ zX=TGHQKva}2@BPUQ@cNe-&<74N0PwMD;Q(6sT*zAn0wxXOsYDww7Tq)0ZHpp5x?Ld zPJ7%v;gjKg4yoA!aE*iTm{{R^!^%816Lf32~AikLmX2Xk(-0j`_M&-MA1{%P5d_a3dL$38DILDpZy)a{O-IJZfP^k zz~;gX|8(}$hyq5mUv65z5Y0p8Mujedc=`zaRUor3->B%mj?*TK#BBd{u(wY;R}?(i zikEwDN$jJ?1I3wmT2&$@m&J*D1D?3#6-w#eWNbUSI1gxQQap^3Khw&EBq5gyQ7ro?_Gw z(7Nq(odq&p`Xbt=5ykBHgEcN_1w)N)PoVNck_sVh%u$|}WPBrZav%W6fq>y%V#?ur z#jW(mDsb~a;pV@Lm(q9lboD(9r+Oi#g563RC>&jzMt|aVJuRP!^r^M(Cvk$eTqrRS zM||0WMZRr{!3}=Q6E0N$(XXpX&X)P^?AAg8g&%^}(DO zT<+()y_h%D9SgH;r9MTCZRRiRa6NxGw2K)}*WK+$t|I=NkWKN-L@Gt@mi9qRIl(KjQ1|1U~?i?Leq#Gs@^ED~J!+ZyT*s#93C!h0wzC+8Uc`pfv#*G(-Ri!A|5+y`MEm+O$c^%*-!C!NL_UIYm={ z9*Dn1xpDJ=_00ONnw48iT6z^%?LyZt)95$4Z3QaEbo5oq)HqB9B zfaDi@zV&-z{bV^z$ypjkrIzsaxJ!CUb@fYJuP9Tk68nl;ZG$4WEr?ovCC_JIEnw3= zZ_V7cY_l{@ynK9WKCH&I)%gCe_sZ5#nn*n?2WNrEYlA=V*Avb$Hr>WcrwTs;sVvbr z8lEJ4ooYN@_8C?yRJujS2|nyP4i>M`|C9d+=P_L+dUO(cG?$iB4;>MNfEs6ywQUFM zc?Ev_?Lo`ktIoi$UFkdly6esF2xniWh~um-Em~*qYL2)OzQdcf~ z?FFmqVTfuc=@r09*llauDsF-iP|(ST?pj3qZhMATEpq86XVEpRP*{@AqYT3Iv#SrZ zP(?Mp&j%kyMF0G(Qt5$J%+4c5e|xrrzq}nQ zm^=wjN$!O_R@6Bw2*AQxgUzmM9@GbjNS@&$sXLy>^0Vlgq%_3iw?Q6%Kt0lS9o#M_ zbVAH3NcFJe`T1qR@LazFShD$7lI&Q4&V+1NIC^A8cMtDGE!dFc82&WWM+t;WH>e8a zH?J|NQq0Vgf7LwVV&9rQJg>arL_R2EX%yy!CcauNRyXUCdgw0fuDn5UDZ0gM$Hn z2{02wT{}}VdJN1IOh*WLfB|-sbAtlUZM)oQw`x(adGaYGq0x=g0>u{hBMeMRfaqO4 zAyZVP@0Ua~YW+?Gq-DP#GQd;CU#l@e5?DImekGz;7yoqrEIaw;f(^Y`D<*4nwyzpz60BXfM%mQ% ze9G*+O-S_GMKYR(f-XYyJYQzj?u&g)4=#y{W9@}&)qF}8FD3yI?4P*82mckC!P{?~VFFz;ywa=HA4)F1ZKIP118{(RxF%|P z?3u{*(w>xDK-!dXanU~dIp6l4Q%KHbPr?6i0VUnftJx}i`aZ-ZZmkPUKqY%oKRjzv zIvfy_ohQ<=EokTsbg|F>WM;MU4KjYddL>?w;~3{yMDyn%9mx$&!QhrSf)U@qBROky zsvA7P4%I8N2%?FV@6^HdZ~uuYEr&n%&%g5;vE=)EP|zMmx0)sCV87`~wYlwQ2J?fR35g)255Kz`1< z+b4^(fN-qBVZ?~Z0R%Dt(b0ZN=c7~7dVM(uSSOvNA?6eLSY8(0!(%)aVV>pg6$Dy4 z1;rz@e&O(I%(Rpp*`rNYv==XAYS2}xnTa*DpziL@iRfLVCol@S;7ij)^w%wTbs_@N zNVAbuNU0Il@d;XxnbqfCzvzFOy3%){oxr+3h~b#WIG~Y@U=!3K-x1c)k{Aj66NrEEPb)rN}7Ae5x-jHq!j3y7I)!^B2y_Zm3A$Z3a z5gmGsd7!q%GI~?LxJHoD)<&_U-#y>JDg1CcNRb3c`8LDcP;3|x<6G7Hm$)=MCo{&Dxdtiz@QG%PFwLKj9W2aO#bqsUWyPxFy(FG^}&84VrF554Nv z1|!uPi=~EZ_z_>WThWHyG}61$qXV!Wndx@B{aY0VHAhL7VK9SI9l_Yz$&t0J=@uit zXKBErv?M30zm{j7~96o7>u9xVp+`c8Y9nh21gF z0~T^{$znl(jm(o;+QRMialCynafgsY}hqvlskTgRte1G_{E?J;^r3Oml51GYt2az=#YT58 zx814_ATeJ|Ufp%NjTCE_X0=s+mi<9J9}Pfl>wMX8RE_T&*qNuvvFFNY$nQ;-1u?Df z_O#M2-&jRN&WtOOkd-4y91BKQ*XO(RHM1iDiOiXUU`%uw1+211_fTlT_*C59sQF$r zRa}CvBOp>2}VX+r@VypsDsTcGOK^FG|T3SOD{%0 zYfCC!RVCm#vYr#&UArUek`ymWoK|(VHrXh`$6!(8I#Ra2rh>{CAXFy=+?(7FTG_|0 zECiwjK!htgHhUHGIe}jfPCiPZQBsceU3fKgjd1fs-?|kjSjg*_tOa_{ zg~tT<>*~f_K%3wg!P&;f0h^aR)_>=^j)0R85+yCOV%X&vqOcugQH zJ6q=3F`A`PdU_k5$LXD!+^IwmNP0jcgR0jy&-v|CO;%PbZm_s#zB;IPDgNdepQy+@ zTh^c-Pp?;U)HLDQ&}GibNfOQWK-5Xr7EAzWDW*z`%mDWPJU*Q~;DmZfe>(cW8vdG3 z8fl&<#)1g?#8ec+Ecn?KkjqtGkr{v#0P@$f)bs)!VqN005 z_Y(Ipu`OW{fK=NRKRh$Q$PcSi7S1F{f+r8UtxM#Tf zfFsSy`C{F7SE^32uTlYu^O^ku()%|r)gdj&Ja1(FG$soq5$`4$xYVai?mJ-*!^MmJ zLM7X1&LWLD;YXr$US?(%d380%CtcNAT3@f{`_tdH4REB-H2SAi?!^T9tgu{U+wrsz zI{Eyg972D821u^$OOM-IX1fPbbQA*|qT!-UT@|sl)zWoX{pX|oh4Vo-2YV;>dB!z- zY(>e^=-}rBZGe>KW%j8N1Y{!fo}VMtwc5K9z4j&$UaEszuZ#@(GRB40E%>xt@Xd1I zUB2d>ACOIoGmRrIs{|6}`5*{&Kkk*LDUqCUG?(qUb0M1NF4(I^=|(0|Pd8Zp!1I<) z25LYmNSG6DSd@7+Q5%FIvdaDv>TGep;TFBJtnLgSD0`Ht z6u@CXljcMnv%E|j_U{^psoy#_X)o-%$VeCeI_?`iTB!6|2lY_J9LdT-rs#4-bN-KZ)zxo)BY0*;RuUEh0CW1f zz(hvfQ5EAO;{M6Lpy4ZfIEHpsXNaq zGa(e+Y~lQdUBfIrcgDGqii3QE%_|-fTG<6uxu|(f^f;1J)zgac3K+ru!w9j?l>Oh6 zt611=;!ixcbB+p&VRz5wO^BusTM>0%nPO^lHTonl5_)(AWJbe4Fd>~6?nxVhrc3kG zc=p6v@oGI3adlvWPe+Wgmi{`~7D~v$dVq|^vgpv1 z6!Sf(tm+af>!=xu$?oABtY~NKDp>NdhmwtuOJZBQ!&{WsRHIf4W`@;bB-I6DqoR(q zxr1|RwKv%1&3okdK+qKp`26CxO8E1axtjY@wg|2=fR8yNx@Vx+h--^z664SDLLWH9 zP=Ey`$pYEnJ5VPYXfO}9=N4rzt_y#@$i^bTFEYdVb)n zbTvA|N=2nE{JvEH+mkF! zW(aLx4uS+vEj9^J_hKRsLPPJ`?%35rc`mJV7GXg#NfkwC^MA!KR&LAVHBqb{-YQ9c z49wW~LooXxtnsWhy@lvy!XJ|#2?M|U{jV5P*zxUyb(GP3K5Bsv^n>aIBNG@(mk#3p zCuT-!%LP3$WRgAVGZ_!imL#nm{+*jhjYG4(6$^+cyRpiv6|;yE{gfjR zQ|DqqUq58+GIZC|h>%2#0Q+z)T*kH1F$rOwJlP|K!=C1d`Bl1fWSbTTQe6!Y8;pSU zc-Pa#VR9}nBnJxE8n1H)DtpVWo2;Mc z4%mWv31g38xNgf0;S6oc+pp_2L%SiZ5agQ50S(D4ZHnNL)TGnArRVFn2$`c5V0)(+ z0mCL>v~hZxT8Cy(-IDgaL88bw>-R_ePcqkf&w6vw!L6;=O5p77O)+M#Vcl#|mP_)p zox-QQ=C|CMxlz>)2~QJ*jH#Q`lvgI&JVRWe`$CNv5bh@Q+IJ9W=#lys!sRY`QYSD- zcFDco{xuJo-~SBV@OX2OFoAQV(<)iRA! zr02bzD!uwILjh+95$kKWL!zNC#(^p<7kZ)bW`QOBctSke#1TNTta?`ufwr{qPI>Jy zHxiR-8iRw}MNr`WFTL*K_sMo}au%th?Asq|+&ErD?t`Xi&@;56BtB6(T=YrBBSKB; z7s|XQfDp`RA3g?5l^X{GGovB}dE%LEU)6j9Q;wCHM1#Q~McUzkP-tfhLs*Uyvs(Ms z<~#~bZn1!a zvM2e~72_lM2`dfJjCP()kK}4T)H?c0LKq2&sL4z^T(y`#F(M1`b-+cM>&hyH=@txZ z#5?rT$6Z6gm>8LUmXiFpe8i~OcvUe@d6)bV?3_@;l7v|(SsLX}Z`}<_UeWA2>_UQ- z-*4!orN5muLxV0Fw9ELVk!#!*{q88t%v0tJenort0rLd5gTA)JxF?NW$u%g1+8QmFnwu$o8C%jKlVC-Ofhf6%< zX*~1R_Of9Og@aCGiou*FfY%q8;g|z=0qt zATxFyJTy@2QY?rOjPoi0RyD#hOkY*$-II^iM%JsKP%#9w=P_1VyYf7NJ}#YvFV1lE z9#sLE(1`9+P(l`X+O)lO9$uwXmEr?U#d%#KV^^e%9$}R!TkxFuXht7I!fdRtZ5E(O zhDttM?gH}XrJew&CWK%CO+=`N7aQFS-{lxUE^B5D2NJ8Rl$5zZ?v#|ZdgtPA!mOED z<(%tc*S0r-D9dT5SP=UlcBy%qX>64*YQ8~}u82M<-pxAzqy+XLKntpwQ9{<&g;#z* zk_RisVML0buP7|D)E98yz6JS=82KB=Jo!yW#rWKsXShKgIJ=ZD6j2G5h(m|cZG}wP zns+fd%RJw|rVOod#xN4TcB)n?EuFIb-(u2%1o1F^cs`2_PgtXB&@c?O9-wG}tp9hA zhD@_2`7Zst57fs;hR-j~jzPoYW7XxZ{Y|N?XN?X9z@*Ry!wr6#C%JFo?SPu1*ab?V z3q*VO+dNrZ9Lc5cxEvX~fwWEjzbVG071_hzE%m7Gu*hiqJD8eletw;rf{!vn?f>`8 z7jO7GBk%-+jD`=)jgC(B)1YM{mo2?URo1?a{wCrTX_-{-cAawGps;*HvJK)wy{>>{?oxR4K>{hjtMtzu` zevg%#>=KtYI`$HmJu+d+6LEM!5@pIvKTcotX5rf1ll}Y$5J>VVstwzV_aL&>IhY_Z zepHrTa2#t;0M?0%J6Ec;#tGF0D(U@S3GM$9jRg2o`CNCP?P5|rLXCDM3>Nck<1x1^ z^~H^hVMYxz*W8}O6-wbYg|<(9>v9^@O8mp=j?3B`Gd`@avav{aagx^IH z)fVJhS$8p<1*!n|V_^R}f!P21k6!xm%tTr!I4hLyn46Hn#jTbUZYL{G!qKKGfP&AT zQpZ@iUzR0Z;>yd9y{!(Dzz7NYr%`skeW2-}gndFB8cIL3M@DM#PX*Kk60z8M)^Hhnz8~x zh^U@nlU_Ze{M{%~Vbr6Lva)D2ISC*3hKhg`{5>u!7Y5$qsfWELL=I_UTB)J0O{*5U zPqjEl=y)YyBePY>yRM(>8q&mZDht?bx}siqh)!?5I=BZkLit>eHi@9$woE6mCjn9$ zKPKDe<_ZVhUb16%fTJy6}! z5FKfqp2qfjMa&;X`~L5hM_y)HtV)0@c;>m9BrTQ=n$tl*eC9lzUrwa4V$Z+z zy`gJPw}jgNE7lWG_Y`-AU>O>!wnX$NiJcjLk4lZzYHV)O9Qr4-k>wL73n+d2zPGpO zyP)n=rc)&5);Slm;Qq;~Jg?&Z)Rfj{6tO!c9j4Fx-=hzEthQ&5I<%YcGO^u2shAl z#Z%%a&IT{9#TOTz{M@uz?5iFH(rMQow6e03vSB2D+2ioClj^O73(IqSdtpsqLoH_2 z3et5kKQb{7kN$1oF%+_>0#?bri$8MFzUsW9THkYmEMoLl+|ezoMBS!e>Er|Fo$VrhmYHJxu5^ZF8?emg7U2Wj`=0Rp6E2qs=MS=ix{AYM@ITrRJS@}Gpj=h zXkLm-KPDm?`5#nJ;2oh8*KZQ_u*TW!i857lt13N4iF}%VCFJu-^@ppg1pjx~u5Mkr z{#Ni)oo{KdC z{rA_HS?Ur=5iqcG$Tc6R133?UeknnHzS>c>C4$%UCaE;%cOF?|O||S$%@CNe{e1Dg zHi4@`c84vNi<`9yY&TA2$FOb6i>oV*nNdV>BH1Ept8jv9n;tbxQ@{2qcJ~wp)}`W7 zAzF3r{VgVo2q(1XiBF~XE~9kPvv022f+N|#FIokBR-Ij*|aD1}xz;*7w{T>lBt|2%=ID zaZ+!3e$a5xfVj{geL1_gW-q;Do(J;R5DGrX@{X*O)XKAcGxHA!2y}`bln5FHp$f+k zZ0}yRk%V#Vhey}E_oAPt77WMX*EkrJL#!R4x5wnoE0r9qM31iW@+zdI&%6;~cv{TX z?+37o_3{=p(dmw1sSV%V7tvzS-pNbN%)gI@2ci{)Z=1un?4R>87MyH=pmzFWR()W> z@hEzT8U4MrRkoK`cq>8)cTV$l?pqTg3fgWZa_;Q4KQ{Xm@;K2H^c%w!Z&|H@4XT(==^(C?od^U8c>ny-+(ay4b=c$EE``n zI)Qnw-mO@$hc}K96jN_!updXEtgyms*yM(T>@8<{7uM$sTo9IHW#+rWXC{}1V}T5E zMMljb=``t6%=HbF{X*Rbrl&*t&phJ;kFZeE2Udp7ExJ`IA$@}=DaQ#}!DLNJs5Qy$ z=f^)Xo^+{%!-%W}Gy5IALA3U9O7uk~t9>GXQdGiS%~EnYV=bB2-Uk}K%O8J!<#!AO z(lI4Y560^H#n!bhGttyx_bY!^Nq9QSRavPM{RI-s{x*YV(rb8jDFG|@)_a-X1t|UG z$7TevvGJp&zY|$HDL_P^SLv%5H@|&-^pSA#*wqLp*U-X(en#k*llCXn32DSL4LyJD zR{Te&x*Dy)vtpCSCVY~;bbj#pqNE4FOb8i1%Nj=0jw#N;Sx0gf>sj z8OmMrxKCi;{d_gX=K4|U8!Ij6rRBy3PiIcwmH5C$F(h{G#?p|rc>17co<$v%lhOND zE@K6C+_ra4Wt1PVXY(8J69`g{LB><=L>D}QWI7=UgT^Msi5+4gTY zGzr@KtYFL6+H6UYNHrD#-{DLPP_o60%_!|r#YS&MV#vs%@nDA0fX1L&wIm-Xb;lqC zDcBq9)E$jS{;QVrxamAOOJ;1-8S+s0XN`Tu?@rt;O4i-BOE$5FI+*R%KnfZoGe%X` zZRTy}^+sRo7lkk5rrs1kf39H3#+X-qOi%LI>8$?xv_(3AN?%kQDUOpnw1~0jX?)FG ziD31abVZGi1$@>6!#nUOy@1%mCiFLJ^Mf7MIliVhaE4T)-SvH zpd!r$0;T#B$7pJNO-hQDQdwAeeQeD& zMv{!9<+BH#%`IeUwOm%tL>$-z&iDR&txvHd!sz};tXbnP)@V1~o*3VWwMu~gUhX_7 zX)UjoJo!n&PPUQ}&ofH%2#icnZC(H4uR?X!*bvhuE75o(JS|hk&QTBLOO*8DP8D_x z=HQA9Z==Daiey@jNWXsXEtq2U*=20;-e3wS5LZPJ&`Dn%aOB@Zxc zxv$XlPghzQbMsSMV%3CXp513g)e#4(nGJUGLc?;dZL4tD8cGSC*NQ! zc;zB;_5?Q=E+Q2M#Go*?oPrF0Su>}VWi}W zOgJkw#GfG9BbZpf|CGdnJl||N1go4gV_;>a`QS=sx2mV1fs%T(H(hNdC)(`J?*?9a z!wSR2?adS?$H2lW*dQRpz$^hBq*SPL^LhUaG@@#0mxjvAMzeUf#92fNCfYG-8P7;% z&5W(doW-;;AMV5lDm&?YIJ`7$(BE6Up6#wg09o_n-XZXtwK;2C# zU(gb=2#?Q{_I>~U^MK;V6uPB=*EcznRDP_ebn0*1hIkwy#e6cK#;z9e%eNOJdv!#^ z!|!wFzw*~fOj6q3=OS9!M~gIcaruL;6^;F`b+K;Pv_D-4|HVU*FD`B9+)xZmF&(hc z=cZ_hl1TueDp$=T`{IyKL+H~$XCux4m5u+|?#JDcoqaNK3oVYaE*ySFMiUQ3C=?G* zhpZ3s7!LX?{TX;8&JwGRC9)R`Kr7J{+3m>j->wk`D#CmL{%K>UvKh)W0i{$1ZUB)1 zEaNzJ#p+S5auC1>PF77#2_5pQI{cmHqq;?zzH_{Kx))i%7E>JD`wyCx%8AZ5y?N6Z z$|l(0`Mx=h6em<7=)YHa0|MnWHD=Gu8J^^1oD*aJ$HrDLJP;(#5su=iU!HC94N4~c z)u_6oSSqJ^U)yB7gso=;>Z65)-C0>HCw&>1mepZoExrq`o()JOTK%?Z-Qt&>E$`~; zk2Jg=PhjacHz?={uvgpkbpFC7K=5GLZV>ItZrvm^_3t7;AEF3)hp53FpJ$m^=$T%b zC#|0pev z%T=7@#bl4{pSA;NZYzDOQ*Vy_R1W<(%Ll4GUG}fD>kxRK_iVk~EZ-m?AQk4XXryL} zR%KbWit5C7b{p>u(+4dgL0#1QXzy;>8Z#^mQl@<^GC5U$ar^3AzsdeG>)>Wf z@ZzS{>${+ys{ZKY`}FTmyoWR2?2qF|CG6`|yhCjpXd1IR>~A(;vSRV~{fu4a;2`rt zh2x5cZFFK`56aKq8FJh-tcii<0_UtM(LY!mpMHy8ScII?66)5}FIlU9tsTDY$s_Km z3{P`t@sgp!2@Ol@i%a-vwbBfy0aSoQSTGv^m->-5_c&aq&8>fm*Nh|pTUmEKPnhNz z0w;HrhHlNBuj_R8C4!u#>V_<1V4%tJ9eDGQ0Q*y>)KymBAZBVRB_;^Ef4M2=)iSJ1H0c9Apaa05Z;^&*U({>T2QnQcH52$5buV4L5Xryc)`ULf_MzG;(_;7z91I;&~pqZPf2 zR?m9HCEG_TuKXHW%;;HRcs?Wb4#F<^H2pF(IY*v54!Zw2ZxE|qFHXMq;x>@^b$!{J zS)`?)UG8uKjY`-eXy0nmojKVDH7||pW)rOvyqkmkuVF5ol>sr(1`I9j5He~^E~8@0 zcVF?2Y6*^sQ86C)fjEwDoMC!cf)9Rt`nQWWWshD|vz)rbXM5!3d08EXw3`s6+~Jc! zhK7#Hs=eyvN6jN-CZpTvVnxJWKhp#ICz_VF%A0ny*8W~uxbW59>3PMtfMqr+Z+dyT zVar;e%BE4KQ-+zyser0tJ_E%ZVEdrm>uGU9!pG%|tVby;D+jf%zvlXDN7*Jp|1?0p zT4eu)LqKz#?&Mi74GWKLOBQk|;`I~-cbtm+Aa>AN#aMur1)`$pRNwxre7&&v+j13(cLcoNiN`f+<6y$9*il zk{)5=IC{Cq6kB#dPYY%PVSvEAbm4H?c&AnR!(kGk zCHD8PsgySnDo{uZ=KgS-7|^lVM8~XR!aZ9qdFcr|2?-G|4@d#cgnFc^;BDuK?s+lv z)z?@+e@jYG5FRlpZj0JoWZO@+D zVZU6Sxr!PG&-(5uS~0D#a330*OD^Y|CzX17fUp6bgzB&rw1PX?p0*i3q;8Mg>9`x- z8U25~0IF(wjl!bA%i39?JDTk+H!XJ$8jQD2K8oQLR_b+;I}{J^_7v7?KWDk#a(*20 z^fe(P%Rp`7n>V)Dc#gHb2ceTmtu1$c3z>x-_KIU)6nNEMm$AGkTPA!e_wH*}+E)xr z(nTEDdhj+eThs#}ifJe*{ox>QA6w*_6UO*ls}x1rVmvsf;c{_$I>n<^W#3r8-z3FW!`Wti z4|3C<8xW~Dr{-Y#a-XkGH>4f{IU)#y)W$-5!Q_*)C{F+IRywq+uFP1edn~71M2HOq zT9DnFb1Otth0*5csX?L>*I4B83JD2EL)Y56Hf+-}vYW>KXeVt!1yA4x^|v5|{%m%{ z{4loUN(M;!%743C?+WbK6-#Bm<$iTl3u+H*XyBXOe7C);yLknK%51+U)0-WDm;5Q+0?X$^27`Y5p&Fp1`bw)dh;`cJ_8R^dgd$1O1e` ze{J}VE`xW8`lD&g;c~$hab}nXz;GVjjlKthk_+EYsVqxJI)f_vf_kNoNP7FbzxDNAVB7rCNLMzm)DT|h*i)PTSi^s)7Oh(!U&>?mAG?-f zz3)W1c}Yq6&E?3<)yUo8B>`y5&e?W-6h(9K$^bA@TQEZu{k~)DvOfNc{Qjg`N$k~g z;K{2Jz9a-ylnM9}y@B&VE zh!QNvBonRce4-fQy-nk?`zfPj%I)M5alS;{Mx+V*ho((03#aeS;ZRU6Zw6C#@iNpY zP@K1HG2V?x9s(Cj0ZIux$Qm6`1^jkkMJ|6gfe z{TKBU?G1>qNQZQTfYJ?;BBg+Iw{#;dxsoCxB_$~!-Q7q?cXxN!0+P?H-}`#*A8>!# zn$N_UGw(UQ*bFq$ric4!rS|vU#CUkMO!Kd5b-ntu_ovmmmZ9qlZ!E1x-5e1dwF}!|ZWap6e$_Gzf7LXQ9zCK(eHBZI2I7nLF)ORN z1f$l!w3ir$R8>6fnlEfIZgYum*Ug8diRcdbqR>+nJl)>LsUSU%)VJdRF6Bp>C11AW>2VvT z!t!9SdJ3dpeF!wbN^!d@Hq{>O0OGsXar?Pt6{nV*72gpyFl-G0#V!lnT_0TUJQv)I z#t(4YGkc_M7putuB>T@qceo?{IZ^HYX#l)lDyqQPUfLMLgk}5YjX;a_)806Cneu!Y zZ(y!-=-el0yf&xgI~tGx>R&TAQ*fFDUzCNCMz%e86omNLf9d;Em7Y+>z|fWw8?@Uf zoRyum?JJ_S=@DkOqj!5NHn{?naW)jGzpC9YxULEcU{P>C9%A&ly_vNUp69_O`9gRLp3=b9WMrWT9X+ z`!}TsGk@~*a7f8ENhHC2*t!P-w!^i}tX}|CAQC8-0U+8Y>a05}w3}JaKjo<8574Y@ zsd>0INjkpu(4XSJdnqonrFFeZAIl*?O`wj8#Sv z3XeTj5S6W87#g~*RfYtVoqrK)DZq3C7ljI!nxJ7n-T9KbOD)6#uDFOLeI;H$x?#j2 zC1MdD>kOCO!lil?=#gL~`@4LLtMsTHDNbtl^rGX%p;keGRIo@-tEH*0|2M&Ya|{9k zxH1EuNyidh48y8SP*^RF=c-evaKOH8aS$MVx|~!PNazFZ4n1E(AOEoQusQsY?fv*P zuoFc_zW&8(Da#g|kB~#p^$ypzEhiQdEh3ZqVZ)@GjN8Erds6O-*hKz_{^W~!mMgTm zUp}H(*Kv#eEd09nGxv)IU$qI8`qQ@VGb&)o;<~J#f_ltTxiWmlJ#iH1NO|wu>~s+2<#kuU zi~KnH%odJv|o3=GSamC1jy6)iwKF@JQY}jT9yo8Wx&|!cU1SQfvYsaKP2?q}MJ7H! z#U~~ED>@cguUaT<0&>JyY{o~6{MCs*qEwN}es6Nwd1+gnIo$$m`+w0uAk07aNZ{(B zeVhoF_-A22gTOh~!+l^O5%_ree*O$79=dyfe(<6Kf|P+r%*^@~hd+z3%5zyjabAJW zp}lWEFySdHz@3Z3gEmE9Cy);` z5y6yA#_8zj;j;IS7kdYScsZ44yLN!ahx#sUlZgCL;4oaqOEDymzvgT{E|KGCjf8@8 z3?Bm^tI9*r$g9-WcNEV$CMP{l_A6kyB@bFnCa4q}jI|Zz#~Su*qY4b*-cl+v4IPiD zNiRSLrm4?}60+}V^dsvFKP={3dAvBdSU5v|jRZ`YaQjU++dK86$Hu9jM&Yyq++%4a zSg;s_zR6g-(7VB?mYw}RJsn}jd8;il^7zs(&7P~(m{0C*dI=c33|)X83_l;%Z*_k8 zezieoy}Z2yet^%7ZO`E5sD52ug&TGN7%p_+u$a!7izC-4C}ez$pInL?%WiFOWBn4x z^6A5Bhu3`~=F&s+_z?UgG~}RmAQc6Nf*<{gr3?%iCV!p?I5`3H&$UIQRWCv9=xCO& z=+mMic`Z}mtN}tB5IN(nIg9&sIX1;^)PA6OEiQb9H4s^DNm<$wxa%Y)_UapgBf79b z5}02-8D`d}2R8O~({13oX_=7QeWN*G^8bNQDw*HSKw`+lCrr7!OCAGmq2&Y~2|FpIv@? zPt23alAP?f!2H6I#HpkNogg7`-yr!KL_>r4>ujs9Da`SjXN!kJytc(zUo_e3UShT@ z9z>{}aa)AkUQ#9U;KHxE!ON*$bwa_9<=xy&%&J^N>GjtFlZAqx%|lCAXY}h`D8MQ4 z*KhbSKB$<$EB7PBRPL=mFcbnCrRe+A)`ZmA`8t(LX-C7BZ=1zz%{{=QCNF0ezVa5_ zq$SOXAsI_7v2bz=zoUosyZttU8N6*|6$~ zSzkPzVDDcsU`!sV6+g7jA6@IxzVPUK#P6`!n0F}!7s7y)3#uAi`e<<+_CEg7EN(<> zXGfGJ^cDaxx?KEV_{`Bwj^DL=kK5DH<94cSW4tBq(m7OGbc%^;sqpmqOfhoKk#7*wT^Qx@tH_wOM-9!Kt$Ei0W zcCxfzyF!Ui;gIiGo$(zA8$62vepR|42S-N;3`S)#@FT!BqL2o-mnKW!_qgNk8ept%@` zEFfmM6Esi-4c37T8LphLz)V=ScO^;;{m_c*(Qzu3CToFN!`He4Bu+8Of}O{c<4*+B zIlkzL!N5_=4l3`2m1t>A64Ny``EHU7*D#4`=%}!>=`q39D!iKNlg82u5LRq+G_T7$ zfv-Y*RVZPz#eX?fadA-VjxiD$iCxx!AXI@MBBtgzjipF zNS6#eK?B^Sn_4^Dob>dvnipDpcBH^*LHhv0Rg!Z{)=xstJ#gP~&>PJ-lW3I+JZ&iv z{p5yLov1xYOaWFjKAF0%j3g!L;Ro|3|KRY^>S$o_ljkL;WlvG5W;`w`{s9cyBApBY(6_9lpc{L z=UlgZ3F`acX33}drycf&T5Hqyk+$Q5i}!d1>w=p)&#};D9WbSkwOK@QB@a)bF3|lD zCAKrv346*rkCTNz;sQa(cxzBq4{X>{h;P`zowYZKa>x+Kv|uVRQ)y-VKn|etrA8r?juAEc zd7~f@nvCH$>A+lE`+b8thpq&bVy{)W@w_rIo{~;I!C%}bzrff+wL!{ zai#aZYyOWdf%SDt1QQ79vI1sNEH)TR=R3grJm(~k!faGV|KXMFTR`dL!Kc&Jc7kLt zf_iw&-pV?YYE=_cYH$XgA(pzZrKXCR=$S<&PZA4SSuyO-#rs!RqvsY15741TxAiB6 zGO?vb^!Lxq^L|cOx3VfVs71Jh-Lwp8gO$H}vi3a8RNG{o1OrX0-i2**DD6{luxf7M z{$_^KJONP-ExQAv5VJJ6_Tk%seaU1N!J_+>g_2XUTdS8A@U}<{gMy^-3SQ&Gy-uMH zZ#cR{SyO{PFXmB83t>=@95K1%2++5Ta5rz)T%qY8p)y1C6Ky3cowGwcYQ8;#j4zBZxDW4aVTZ>4FtD-W*C-R_TksdBaQ; zNNazz$O0aCW&QRExjFZJ8ndR0m>uV=Ko|{5F(y`7A?G&~)DR_o9|_F`LQurW^Ym|O$whZhB3hD>* zWC7rJ#DG`UG`T*1?r}CC3}>#Amc_wxS<;w9Zv2y8W-|_%K zBJl5RY#N|Inq@;?*ckn_XKB;$I|yFT&yz<$Ah5T0Ob=3@6CJGq}Mh1UkGV+xhD6PhuZ%E#+Ul(5Z#M7lRF^ zWBXOoWO8vaB8HLO>0gJvpyuFDk2{!KoCqGM;ul+17$xyxXVjI4uY5HKUa~IKES%t5 zlUKv=+}@T1ye{BGX<<~Gx~^Arm^c_lt*u=8i#&9BBN+u=ISwz5S0(HAqUPaGpcMQw z68KDCRdeb5?h(9H-AnM1M@=IYm^tCUnz7hqS;Cb9Qqp&K4+jgzwrc8&T_-I)(a-JU zBt}_Z@DyQI^6vBD*p{+Nhp`ryNyN({3#tVE}Ju&!+M|V_QS(`nVnQ^n9$39w&jr%bUvbZct{q!?5(yd_?2UkqNXv}cXg(wEvWcXDDAu5oQ9mQ@8S1@ zGSGOU>v*@|!E~Aq0)bLZix!sE3dmU7`0*Yb!RMqq=LuHCV6um=qg$}S?q?NwdfH~? zS5keUsZrB9Wf;*nlKHR_fQp1<#4UzlGhek=rdvOfQ}O=KdqGE|7?}G=4+JGFtE5EP z+B%MY9P86>mYJ$O&Vq=YSj~5w|7LAojcrp{(&E=Cw3){isVLSYFM8`3P_l>rf_dwW z;?T>PYCG8X2+eF&0|O=)>{8dqn}XtD^$`RNX>;`Hpq(`7#|u?oJ73>o+qr6;Mc;-+ zO&HprKZ2vPI;?hfd%x1D*;(zjf({Q~kq}>{V$*_k+Ie~@>WUO{lCw?Jivul_GP1fF z2HM;C__SRdY@BW;4ZQ^vKd^gBu-*f{(4cbAokJ7-40fH5gd$v94_>?|pZ6v>D0xgrm>b0(XRAYIPGox7T|(1$`USu<60Lto02orJfIMD;v`6 z-@l0)#o10De?C7itjG{;O?>>}^3dYzdEC7HV6xXUaszuW+bLqs3N?Re@rHFnUH(e*W9S;?}F{y$?GFA_J)S&F(`T9UaI6 z2x4>fFp&Zow#GZRrtjZ{muHs3x*TMMecNLx!y4*5VLx*G9E_H|J|5Q5X|%9=c}~`i zh9M0HAkZ&go%j~Czv9qZw-Ufnj-Y64)C&8&puY2^5r z@rB%6b%R%=E2+3R!f5M-arj(KykcE5LVx$rP?hgA-5w7Vir~?Y-A+nI8t0s$H#uB7 zf9*;tdSeU4e+(G@>0AhJ^VNH^wmnvASHLG9Pox?wwC0=dkpFwK6+F2>xf_zCQK)5m zH$HaMP5%DEXd!Y%i(O4# z5zZN4dh^Q>6Qr6>8KWKNIz-ti!h#Hj-XEgiof-WA45h1EAdyA;jsV-wpx@*9x0|zm_f6{ldg`Ifn#tDZ?rwBk z?F}L`V3)bz5ca;-fCrmDQc(39U}ptj88X^T1(^GEH7vG23=xp6%6ThzeM0jgv3m8- z!CaqNd$5cEF5&gfl9-~6;uwG!72O+VN)bShEIDD{*WW1bA{tM>)KpA7CEDsvauDt7 zek=zTrQrK;6ObCxWmGEb-};ng98Qa{k&y%!cfXYxlaR?t>%2T|iFVz6z!Njg3rUIm z%*(L&ix@7?g!ML$IppZ5Y7Q0^9g%vUmS|qXBGTy$L3dpZgOju z7{sU-)K}KDmrCK_KrvizJz6Sja+ca9*MLa`Cy9 zLrdiO!Ww|;TJbA2KsMjY2KQ*J5DZ;pM8s~c9#OaHnv&pRv$UJlu&~qHvo8E={a{vq zC|Da2=EsAon6X9e$*Cpw26wU7CT7ru2C+ywnR~A(KZ|Kv(8iZ*j8>_zCQ>k4H|LXa z7y=?o_2c>|6t0)qK5Hwh_Tod@U5 zx5f+!dj6@q7W}Z#{yQ8BBS>L@vsL7coYOVE+o!Kgo7?HU|sQeQY@W37Mg9qQ5k?zO;-~v7zD}>~g`P zvH3G}nIWnEVkiYaFMl=J$oie}S|ayhI0mAl`_1KE_%10q59RU4j%9Pw%AfbYJ4=zg zSaq{01rfSEk&$brRs5FIu@FP8EpY@rzq=toAdW%duhH$$SxYtbQ-18=fn5v!<>hJC z5=c00(}m@kf`Ekd^~;~bmiOCNC*UpYOcn z2uKpqe0JsTf-5dNdt+XAryK4MT;C+mJA1kQYtF-8K!W3U_39}>^Fy;xM0JL8l%m*% zGnOd{C1*mmuHW#y@LkI6>4xWx426U_8uIu$lg-o@7nj@~691<;)61Q% z{R|tm9_%Au2KK9K}Ps5pg$+jADR2r_vA zztjt42t;;vIC60>p5@K{r3(;be`3+h3EvbZ9wZCD(FHU0xZn7@91wbEK%H*rEe#$< zL+(GPt*ji51H1Ajv zR(XlIm{TQVapHtmBnn2K?N2l^V5nHCu8_jMNc~g~3BSAGFrtC}u9euIG*v_KY&K1n*cou6~FrX;#4(qImgTkNS)B(d}LR%cy}QDUD(tvajzsc~A3N3+S;9f;}c?;gz>IVw^3 zIh5RQEp;e5SInlJd~lBtT&S=7lhL=>I#DJwNyr{m7~@qbNvK+>_3>!g%=V z8<5>Ba<1pADszR}B|Fw=(|oci?fO%gRrC)IEF(LmqhNazq8QNN#r29B2PXWv?c^ON5gL^6N+6u4E5<#&k}z1kl&6n;_UQS ztVWnv_56CSBeZ^LiaGAx1AG~%H0bl9Z2a0A8=fTqE)8^RBl)_K{qDK#IAX+ZX$s;6 z7^$~k`n+s*8KD}@3 zXr@Dh9G~0E*WCa9*C_XOHK}Eu(%RK4(mjbyOlFz8AY52ye z1T>09(IFvNp|&$^f&->^cjnFMcO0Dyb&=m=LvL@lXv2sU@4S|LatP%;_lnNl=!C)` ztUC13@%*sw(}T^sEc-kQUhV6c67L4jyL41C?&k!>Xx%9<=j-yCrhX(jumw&`nim({ z-#H*5;hD zV|UjCb6Cw!2ZcPh#)1UNAdtNBU-!R_^RYfbBNGQxd7U}S%<8s#L>>#d|=U>^o2mxOzy6AouB56#^}XK?XER%t4ry`4y%B(^m+jHczj7u7iDX@tV2oN zK~>Gt{FKqKEd(1ys=mJ8R?b~RD`{eKw?vmN+BLHYKGnSY->u$|gx=Nwb5HDf&!ucy zJZ1gv>_ZQS8aF#@_b}C<09M`kg()MYhfQ%wKMk!pyZPLf@VzNCNWv#O0JWR1e;M1U`rwa zmOLA6)(ys#!&^C6gdi!*{PuSA*L4%5>zmoV;KaexdhbLilw@19z}@B-H@+)`A-Ij^ ztnC$jbjssG2G1MctJWkR{R(NZ{*L#FKBBIgEdyNFh(C+pt*3hJ-;DTRa8NARzvc&j z^Rb6>eSM{NmB>vJy|WRbAlw3@)BVDQe;_sNy73ldQddJbFgR`ho6WugXK&C!IF-kcBl}5YXhOk!T z+kD4bm_swCGk^3zBh%GOADyQPbs}Yo)fbcr_1m7$@kY=;PZgicJVvB31K{AEbUN|< z)*Ci0lM|oWk_JuhEBXuS70o3zHKAfH48_E|q?H-gn+_q%$O=(%(#wH^8OE-=(Dq^% zhdP5H?(cwuC2CSmd~?bnw;Lt9KQxkdZV#KhK1h9>CLPc~(a*`jDb1FPYjt7CsUZXp z8F@bF;J=%(d(m-t;!iz!wrI_g?_Qe8zT@?byOJ|UtUuE1Z-tXuoi|P%T9^wPtBT^s6brmh8uP^* zIjE5E4tS@VbhGlmRM#dYlh6JRCo7I&oQRk^^MFE^U&7lJvt?r;a_{Wo<(1^bLlyoEtAu8I~ko_y0vy+W-zR1)5rp7*8*S3-cA+Vs1Yyhw~< z?9_j3s}>xx!#8C5?AgUW(CVB|I8u(3vV!jEf{WRrVwn$wxE5AKV|E77mR;{Y1%O%w z&q&q(7>!f>Rsixady^zb_b!yf&v$cZqFC22viODNE{-EV1qCv4Eg2Rm8A*5~43UOx zTQqE`#n5z7_<>UBjE0^aPuYf~*4R=uD_7Qm3>2|qZ|Rqi=U^wKBgerh-ySHQliJ+M zAm4mls%ZT4303`3L4+vYOnJ~npf>o=5cm?%K;aRrR%tT+UDQBFEz>cEHmZI>FTOju zln@Dibl#NflE%iQrrP=@2V~@1$(nm=)mbRiC_aR8w1gcOSJ3rsR(0G(Ac>vbPQ&q8 z?N{is;3g8h!%xue&4Ft~<0Atkq<$D>0(lt_{(u~!qTO>%ZPg|W84K+q$)IcVhE(Sl zj4es?ZkeHANu&L29jD;xUsH)f$~~k&HjGH8tenC$?|Qmldj5V=Rxh}Z6Ltx zwIdot)bU=}ZaJN>{hgvHxLZ<$CTd-&)nC6huO6F}jzC0gWqg;Kg-JgCe%fkB#W{i$ zs;1uv(B{G|YE)%58oK;wkbG4s_jT#i+0dTDT2alo7o{xFL$2pMcAw8i0md7rnh$-6 zEF^MYn@AZrmSZKCC4IR`L-0O<7O_<(SF9Gmh+FRfuWI4+$SYl1-bar-OG1OeupE+Vy z$K}VVrnR1ma%E^}kG0lgT+CL!d3g5?MuOl+O2tU+ApvCex|zWpo3#&j(BI&9E*SY` zjN&+k8^W!L$MhA4G9_m%F3t<)1L0zE@gO1!Fa|TfX85zIDhDb%G$@qg*}}%#zTSNi zzJ+563jYQ9ug@%eQ0V0@I|FE{`89JZbHU_mxRw9doq4V?w4tBTOc#_6%a^S-9F4}w zCReOG<$t5d#B|-k;(bOFZpN@`J8e-@et97`v6q{b@ zgMi=d$fA$)PxpAJqtJpq>4H5i`}Vv1*YMGsP_;o@F3yP7`@0LOoTRfg76aRb0W!oD zH-Kpj@5&E|aCUL_2_d=9oLzbO%0(aH#l+{dgvSv^9ooBJIJl^-9~<8-R>cuEwA{EI z@m(iAqn0<%xc`lP7McX%1gjtDcoIQN5JAIm0^>P z>Ag4aT<)PT4K3|a#k18He)3Jk%nI~RIs5k zX}Js@qsYsz10Zb>8v>5FkQ;Ft^f8I$#0zf3);j#^I+RW{P9O_}mF6YNFuwq$ zp705H{Ba_P8O9XSe03Zp`TLbZj9Nk{xz2J|u0G7-aqHG`HGJbIRZlCaa~>#KP&Kfh zpuxi-uOG7A-L*eJsYnUsfNu^G;)Fs0GdTmsd-Lqg^`D<=x3>g_0x6b9w5scwU z>nM$wVT(}YOJqNf`;T{a@b*=1MTs-Q6~IvV^lTRgM^bVyWz4HdAvUK+r|RtyY@Ft* zeJvts25XO-TDdhnh3030oT;OdLa}K+^U}C5B&O+DViuhc4MIyBg0<7MIL?!~lTK!z z`}#NpWG-E}-5r2IqA}6<0(+HY*MX*g@}WvGC@3El7J%LF%{HI=3LRPUV*ibyEHN1! zwdE95pu}O8Oi2QSAB_B3Aso>0`ng?b$HZiQgKJ4c|7#j`bWScO=icMF9BC|M$!c3= zktclbVyPgxcW-4BWaPqb5*Z-%%Iq!zVcwiN0jaVJ;3;XMCU&#jGj$ja<3OgR;)z{rmU+?(7J^xld}lH4XD1uoa~$C6mxpUP9q}1FtEc|43eAgNJ;CR)%$i>^m5}`2$gR{ d6q4?#q@uktPOtB2fH@4|jnq5IVhJPv{|Cl_E@l7# diff --git a/manual/source/index.rst b/manual/source/index.rst index 962b7f6915..bb47170555 100644 --- a/manual/source/index.rst +++ b/manual/source/index.rst @@ -1,51 +1,35 @@ +.. image:: img/NeXus.png + :width: 40% + ======================================= User Manual and Reference Documentation ======================================= -Welcome to the user manual of the NeXus for FAIRmat project. - https://www.nexusformat.org/ .. toctree:: :maxdepth: 2 - :numbered: 5 + :numbered: 4 - fairmat-cover - nexus-index - em-structure - mpes-structure - optical-spectroscopy-structure - apm-structure - transport-structure - sts-structure - cgms-structure - north-structure - laboratory-structure - icme-structure + user_manual + examples/index + ref_doc napi + community + installation + utilities history - - - + docs_about ----------- .. rubric:: Publishing Information -| This commit time code <>. -| This commit identifier <>. -| This manual built |today|. - -.. rubric:: Acknowledgements - -| The FAIRmat project is funded by the Deutsche Forschungsgemeinschaft -| (`DFG `_, German Research Foundation) - project 460197019. -| FAIRmat is a consortium within the `German NFDI `_. - +This manual built |today|. .. seealso:: - The extended NeXus documentation: + This document is available in these formats online: :HTML: https://manual.nexusformat.org/ @@ -62,14 +46,11 @@ https://www.nexusformat.org/ :PDF: https://manual.nexusformat.org/_static/NXImpatient.pdf - FAIRmat website: - - ``_ - - NOMAD website: - - ``_ - - - +.. Suggestions for adding to this manual: + Look for some other "section" such as "introduction.rst" and act similarly. + Any examples go as text files in the examples/ subdirectory and are pulled into + Sphinx inside a :directive:`literalcode` directive. Look for the pattern + or wing it. If you are ambitious, add index entries. Many examples of the + constructs you might use are already in the manual. + diff --git a/manual/source/laboratory-structure.rst b/manual/source/laboratory-structure.rst deleted file mode 100644 index 568e6d4823..0000000000 --- a/manual/source/laboratory-structure.rst +++ /dev/null @@ -1,9 +0,0 @@ -.. _Lab-Structure-Fairmat: - -================== -Sample preparation -================== - -Prototype application definitions for documenting steps during sample preparation are a part of ongoing work. - -A status quo of this work is reported here: :ref:`Synthesis-Structure` via the :ref:`NXlab_electro_chemo_mechanical_preparation` and the :ref:`NXlab_sample_mounting` application definitions. These are drafts. diff --git a/manual/source/mpes-structure.rst b/manual/source/mpes-structure.rst deleted file mode 100644 index e4521ab2e6..0000000000 --- a/manual/source/mpes-structure.rst +++ /dev/null @@ -1,38 +0,0 @@ -.. _Mpes-Structure-Fairmat: - -======================================= -Photoemission & core-level spectroscopy -======================================= - -The NXmpes application definition is designed to describe data and metadata obtained from -various multidimensional photoemission spectroscopy (MPES) techniques. -This definition is very flexible and requires just a reasonable amount of -metadata to make the stored data interoperable and reproducible. -The only requirement for the actual data is the existence of an energy axis. - -The experimental techniques covered by this application definition are primarily limited -to photon-in photoelectron-out methods. If you are searching for related techniques, -there is a good chance you will find valuable information here. - -Example techniques covered by this application definition include: - -- X-ray/UV photoelectron spectroscopy (XPS/UPS) -- Angle-resolved photoemission spectroscopy (ARPES) -- Two-photon photoemission (2PPE) -- Photoemission electron microscopy (PEEM) - -Additionally, we offer descriptors for specialized applications, -such as spin- and time-resolution, near-ambient pressure conditions, dichroism, and more. - -Here's a list of application definitions related to photoemission spectroscopy: - - :ref:`NXmpes`: - A universal application definition with minimal metadata requirements for describing all photoemission experiments. - - :ref:`NXmpes_arpes`: - An appdef for angle-resolved photoemission spectroscopy (ARPES) experiments. - - :ref:`NXxps`: - An application definition for XPS/UPS measurements. - -More information about the classes developed for MPES experiments can be found here: :ref:`Mpes-Structure`. \ No newline at end of file diff --git a/manual/source/nexus-index.rst b/manual/source/nexus-index.rst deleted file mode 100644 index 1e9bf529ac..0000000000 --- a/manual/source/nexus-index.rst +++ /dev/null @@ -1,20 +0,0 @@ -.. _NexusIndex: - -======================================= -NeXus Documentation -======================================= - -Welcome to the user manual of the NeXus. - -https://www.nexusformat.org/ - -.. toctree:: - :maxdepth: 2 - - user_manual - examples/index - ref_doc - community - installation - utilities - docs_about \ No newline at end of file diff --git a/manual/source/north-structure.rst b/manual/source/north-structure.rst deleted file mode 100644 index 26526638d2..0000000000 --- a/manual/source/north-structure.rst +++ /dev/null @@ -1,26 +0,0 @@ -.. _North-Structure-Fairmat: - -============================ -NOMAD OASIS Remote Tools Hub -============================ - -.. index:: - IntroductionNorth - IntroductionApmTools - -.. _IntroductionNorth: - -Introduction to NORTH -##################### -The NOMAD OASIS Remote Tools Hub (NORTH), is a `NOMAD OASIS `_ service which provides access to containerized applications. -These containers contain pre-configured scientific software of different academic communities and offer access to the data inside the NOMAD OASIS research data management system. -This page delivers status reports of ongoing work specific to NeXus and how NeXus is being used by tools within specific containers offered by NORTH. - -.. _IntroductionApmTools: - -apmtools container -################## - -One containerized application in NORTH and its apmtools container, is the paraprobe-toolbox. This software is developed by `M. Kühbach et al. `_. -The software provides an implementation which exemplifies how NeXus/HDF5 and community tools for atom probe can be used to document provenance and steps of post-processing -for many steps relevant within the field of atom probe tomography and related field-ion microscopy: Inspect :ref:`Apm-Structure` for a status report and details. diff --git a/manual/source/optical-spectroscopy-structure.rst b/manual/source/optical-spectroscopy-structure.rst deleted file mode 100644 index c5d881d99c..0000000000 --- a/manual/source/optical-spectroscopy-structure.rst +++ /dev/null @@ -1,184 +0,0 @@ -.. _Optical-Spectroscopy-Structure-Fairmat: - -==================== -Optical spectroscopy -==================== - -.. index:: - OpticalSpec1 - Ellipsometry1 - Raman1 - DispersiveMaterial1 - -.. _OpticalSpec1: - -Optical Spectroscopy -#################### - - - - -Application Definitions ------------------------ - -We created one application definition: - - :ref:`NXoptical_spectroscopy`: - A general application definition for optical spectroscopy measurements. This includes specifically: - photoluminescence - transmission spectroscopy - reflection spectroscopy - and general spectroscopy experiments - - General spectroscopy experiments refer to experiments of the type photon-in photon-out. A detector is required to measure the "photon-out"-signal. - For Ellipsomertry and Raman spectroscopy are specific application definitions listed below. - - - - -.. _Ellipsometry1: - -Ellipsometry -############ - -Ellipsometry is an optical characterization method to describe optical properties of interfaces and thickness of films. The measurements are based on determining how the polarization state of light changes upon transmission and reflection. Interpretation is based on Fresnel equations and numerical models of the optical properties of the materials. - -This application definition is an extension of :ref:`NXoptical_spectroscopy`. It provide a minimum set of description elements allowing for a reproducible recording of ellipsometry measurements. - - -Application Definitions ------------------------ - -We created one application definition: - - :ref:`NXellipsometry`: - A general application definition for ellipsometry measurements, including complex systems up to variable angle spectroscopic ellipsometry. - - -.. _Raman1: - -Raman spectroscopy -################## - -Raman spectroscopy is an optical characterization method by measuring elastic light scattering. In this way phonon characteristics are measured for a extreme broad range of samples: gasses, liquids, solids, glasses, crystals. - -The application definition provides an extension of :ref:`NXoptical_spectroscopy` to cover required or relevant data from Raman scattering experiments. - - -Application Definitions ------------------------ - -We created one application definition: - - :ref:`NXraman`: - A general application definition for Raman measurements. - - - - -Dispersive Material -################### - -A dispersive material is a description for the optical dispersion of materials. -This description may be used to store optical model data from an ellipsometric analysis -(or any other technique) or to build a database of optical constants for optical properties of materials. - -Application Definition ----------------------- - - :ref:`NXdispersive_material`: - An application definition to describe the dispersive properties of a material. - The material may be isotropic, uniaxial or biaxial. Hence, it may contain up - to three dispersive functions or tables. - - - -Base Classes ------------- - -There is a set of base classes for describing a dispersion. - - :ref:`NXdispersion` - This is an umbrella base class for a group of dispersion functions to describe the material. - For a simple dispersion it may contain only on NXdispersion_function or NXdispersion_table entry. - If it contains multiple entries the actual dispersion is the sum of all dispersion functions and tables. - This allows for, e.g. splitting real and imaginary parts and describing them seperately or - adding a dielectric background (e.g. Sellmeier model) to an oscillator model (e.g. Lorentz). - - :ref:`NXdispersion_function` - This dispersion is described by a function and its single and repeated parameter values. - It follows a formula of the form ``eps = eps_inf + sum[A * lambda ** 2 / (lambda ** 2 - B ** 2)]`` - (Sellmeier formula). See the formula grammar below for an ebnf grammar for this form. - - :ref:`NXdispersion_single_parameter` - This denotes a parameter which is used outside the summed part of a dispersion function, - e.g. ``eps_inf`` in the formula example above. - - :ref:`NXdispersion_repeated_parameter` - This denotes arrays of repeated parameters which are used to build a sum of parameter values, e.g. - ``A`` and ``B`` are repeated parameters in the formula above. - - :ref:`NXdispersion_table` - This describes a tabular dispersion where the dielectric function is an array versus wavelength or energy. - -Formula Grammar ---------------- - -Below you find a grammar to which the formula should adhere and which can be used to parse and -evaluate the dispersion function. The terms ``single_param_name`` and ``param_name`` should be -filled with the respective single and repeated params from the stored data. - -.. code-block:: - - ?assignment: "eps" "=" kkr_expression -> eps - | "n" "=" kkr_expression -> n - - ?kkr_expression: expression - | "" "+" "1j" "*" term -> kkr_term - - ?expression: term - | expression "+" term -> add - | expression "-" term -> sub - - ?term: factor - | term "*" factor -> mul - | term "/" factor -> div - - ?factor: power - | power "**" power -> power - - - ?power: "(" expression ")" - | FUNC "(" expression ")" -> func - | "sum" "[" repeated_expression "]" -> sum_expr - | NAME -> single_param_name - | SIGNED_NUMBER -> number - | BUILTIN -> builtin - - ?repeated_expression: repeated_term - | repeated_expression "+" repeated_term -> add - | repeated_expression "-" repeated_term -> sub - - - ?repeated_term: repeated_factor - | repeated_term "*" repeated_factor -> mul - | repeated_term "/" repeated_factor -> div - - ?repeated_factor: repeated_power - | repeated_power "**" repeated_power -> power - - ?repeated_power: "(" repeated_expression ")" - | FUNC "(" repeated_expression ")" -> func - | SIGNED_NUMBER -> number - | NAME -> param_name - | BUILTIN -> builtin - - FUNC.1: "sin" | "cos" | "tan" | "sqrt" | "dawsn" | "ln" | "log" | "heaviside" - BUILTIN.1: "1j" | "pi" | "eps_0" | "hbar" | "h" | "c" - - %import common.CNAME -> NAME - %import common.SIGNED_NUMBER - %import common.WS_INLINE - - %ignore WS_INLINE - diff --git a/manual/source/sed/entry-page.html b/manual/source/sed/entry-page.html deleted file mode 100644 index b7c84946c2..0000000000 --- a/manual/source/sed/entry-page.html +++ /dev/null @@ -1,6 +0,0 @@ - - - - - - \ No newline at end of file diff --git a/manual/source/sts-structure.rst b/manual/source/sts-structure.rst deleted file mode 100644 index 26d406c305..0000000000 --- a/manual/source/sts-structure.rst +++ /dev/null @@ -1,8 +0,0 @@ -.. _Stm-Structure-Fairmat: - -=============================== -Scanning Tunneling Spectroscopy -=============================== - -Scientists of the scanning tunneling spectroscopy community and FAIRmat have worked together to create an application definition and related base classes for documenting scanning tunneling spectroscopy experiments. -This is one community under the large umbrella of scanning (probe) microscopy methods. A status report of these efforts will be reported here: :ref:`Stm-Structure`. diff --git a/manual/source/transport-structure.rst b/manual/source/transport-structure.rst deleted file mode 100644 index 80cbcc1c86..0000000000 --- a/manual/source/transport-structure.rst +++ /dev/null @@ -1,14 +0,0 @@ -.. _Transport-Structure-Fairmat: - -=================== -Transport phenomena -=================== - -Work of scientists within FAIRmat how to handshake between instrument control software like EPICS and CAMELS using NeXus resulted in an application definition for exemplar temperature dependent IV curve measurements. -IV curve measurements are one example of a large group of so-called transport measurements. The key idea behind these is to monitor one or more observables under controlled environmental conditions and eventual stimuli applied on a sample. - -Many techniques especially used within materials engineering fall into this category and thus could make use of specializations or extensions of NXiv_temp. -Examples include hardness measurements, nanoindentation, resistance, electro-chemical probing, or diffusion. - - :ref:`NXiv_temp`: - Application definition for temperature dependent IV curve measurements. diff --git a/requirements.txt b/requirements.txt index 74294d9b26..ba1f751d3f 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1,18 +1,17 @@ # Prepare for Documentation -lxml>=4.9.1 +lxml pyyaml -nyaml==0.0.8 +nyaml # Documentation building sphinx>=5 sphinx-tabs sphinx-toolbox -sphinx_comments # Testing pytest # Code style and auto-formatting -black>=24.1.1 +black>=22.3 flake8>=4 isort>=5.10 From 00645ff0fe24253cc9f6495bf7bf098a463bf4ef Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 20 Sep 2024 11:23:02 +0200 Subject: [PATCH 0974/1012] remove nyaml files --- applications/nyaml/NXarchive.yaml | 281 -- applications/nyaml/NXarpes.yaml | 236 -- applications/nyaml/NXcanSAS.yaml | 2422 ----------------- applications/nyaml/NXdirecttof.yaml | 102 - applications/nyaml/NXfluo.yaml | 165 -- applications/nyaml/NXindirecttof.yaml | 111 - applications/nyaml/NXiqproc.yaml | 201 -- applications/nyaml/NXlauetof.yaml | 244 -- applications/nyaml/NXmonopd.yaml | 223 -- applications/nyaml/NXmx.yaml | 1864 ------------- applications/nyaml/NXrefscan.yaml | 197 -- applications/nyaml/NXreftof.yaml | 214 -- applications/nyaml/NXsas.yaml | 369 --- applications/nyaml/NXsastof.yaml | 312 --- applications/nyaml/NXscan.yaml | 181 -- applications/nyaml/NXspe.yaml | 128 - applications/nyaml/NXsqom.yaml | 211 -- applications/nyaml/NXstxm.yaml | 366 --- applications/nyaml/NXtas.yaml | 350 --- applications/nyaml/NXtofnpd.yaml | 233 -- applications/nyaml/NXtofraw.yaml | 255 -- applications/nyaml/NXtofsingle.yaml | 244 -- applications/nyaml/NXtomo.yaml | 279 -- applications/nyaml/NXtomophase.yaml | 292 -- applications/nyaml/NXtomoproc.yaml | 217 -- applications/nyaml/NXxas.yaml | 212 -- applications/nyaml/NXxasproc.yaml | 147 - applications/nyaml/NXxbase.yaml | 308 --- applications/nyaml/NXxeuler.yaml | 173 -- applications/nyaml/NXxkappa.yaml | 174 -- applications/nyaml/NXxlaue.yaml | 109 - applications/nyaml/NXxlaueplate.yaml | 73 - applications/nyaml/NXxnb.yaml | 160 -- applications/nyaml/NXxrot.yaml | 155 -- base_classes/nyaml/NXaperture.yaml | 221 -- base_classes/nyaml/NXattenuator.yaml | 206 -- base_classes/nyaml/NXbeam.yaml | 908 ------ base_classes/nyaml/NXbeam_stop.yaml | 207 -- base_classes/nyaml/NXbending_magnet.yaml | 210 -- base_classes/nyaml/NXcapillary.yaml | 163 -- base_classes/nyaml/NXcite.yaml | 112 - base_classes/nyaml/NXcollection.yaml | 102 - base_classes/nyaml/NXcollimator.yaml | 196 -- base_classes/nyaml/NXcrystal.yaml | 667 ----- .../nyaml/NXcylindrical_geometry.yaml | 169 -- base_classes/nyaml/NXdata.yaml | 1137 -------- base_classes/nyaml/NXdetector.yaml | 1782 ------------ base_classes/nyaml/NXdetector_channel.yaml | 277 -- base_classes/nyaml/NXdetector_group.yaml | 182 -- base_classes/nyaml/NXdetector_module.yaml | 302 -- base_classes/nyaml/NXdisk_chopper.yaml | 322 --- base_classes/nyaml/NXentry.yaml | 475 ---- base_classes/nyaml/NXenvironment.yaml | 182 -- base_classes/nyaml/NXevent_data.yaml | 220 -- base_classes/nyaml/NXfermi_chopper.yaml | 210 -- base_classes/nyaml/NXfilter.yaml | 373 --- base_classes/nyaml/NXflipper.yaml | 159 -- base_classes/nyaml/NXfresnel_zone_plate.yaml | 178 -- base_classes/nyaml/NXgeometry.yaml | 128 - base_classes/nyaml/NXgrating.yaml | 202 -- base_classes/nyaml/NXguide.yaml | 416 --- base_classes/nyaml/NXinsertion_device.yaml | 203 -- base_classes/nyaml/NXinstrument.yaml | 154 -- base_classes/nyaml/NXlog.yaml | 252 -- base_classes/nyaml/NXmirror.yaml | 346 --- base_classes/nyaml/NXmoderator.yaml | 193 -- base_classes/nyaml/NXmonitor.yaml | 293 -- base_classes/nyaml/NXmonochromator.yaml | 230 -- base_classes/nyaml/NXnote.yaml | 116 - base_classes/nyaml/NXobject.yaml | 44 - base_classes/nyaml/NXoff_geometry.yaml | 197 -- base_classes/nyaml/NXorientation.yaml | 111 - base_classes/nyaml/NXparameters.yaml | 76 - base_classes/nyaml/NXpdb.yaml | 329 --- base_classes/nyaml/NXpinhole.yaml | 125 - base_classes/nyaml/NXpolarizer.yaml | 135 - base_classes/nyaml/NXpositioner.yaml | 200 -- base_classes/nyaml/NXprocess.yaml | 134 - base_classes/nyaml/NXreflections.yaml | 1268 --------- base_classes/nyaml/NXroot.yaml | 223 -- base_classes/nyaml/NXsample.yaml | 856 ------ base_classes/nyaml/NXsample_component.yaml | 355 --- base_classes/nyaml/NXsensor.yaml | 325 --- base_classes/nyaml/NXshape.yaml | 143 - base_classes/nyaml/NXslit.yaml | 141 - base_classes/nyaml/NXsource.yaml | 495 ---- base_classes/nyaml/NXsubentry.yaml | 343 --- base_classes/nyaml/NXtransformations.yaml | 410 --- base_classes/nyaml/NXtranslation.yaml | 102 - base_classes/nyaml/NXuser.yaml | 146 - base_classes/nyaml/NXvelocity_selector.yaml | 198 -- base_classes/nyaml/NXxraylens.yaml | 220 -- .../nyaml/NXamplifier.yaml | 147 - .../nyaml/NXapm_compositionspace_config.yaml | 337 --- .../nyaml/NXapm_compositionspace_results.yaml | 715 ----- .../NXapm_paraprobe_clusterer_config.yaml | 704 ----- .../NXapm_paraprobe_clusterer_results.yaml | 549 ---- .../NXapm_paraprobe_distancer_config.yaml | 370 --- .../NXapm_paraprobe_distancer_results.yaml | 366 --- .../NXapm_paraprobe_intersector_config.yaml | 488 ---- .../NXapm_paraprobe_intersector_results.yaml | 489 ---- .../NXapm_paraprobe_nanochem_config.yaml | 1906 ------------- .../NXapm_paraprobe_nanochem_results.yaml | 2385 ---------------- .../nyaml/NXapm_paraprobe_ranger_config.yaml | 471 ---- .../nyaml/NXapm_paraprobe_ranger_results.yaml | 248 -- .../NXapm_paraprobe_selector_config.yaml | 227 -- .../NXapm_paraprobe_selector_results.yaml | 191 -- .../NXapm_paraprobe_spatstat_config.yaml | 610 ----- .../NXapm_paraprobe_spatstat_results.yaml | 355 --- .../NXapm_paraprobe_surfacer_config.yaml | 419 --- .../NXapm_paraprobe_surfacer_results.yaml | 514 ---- .../NXapm_paraprobe_tessellator_config.yaml | 319 --- .../NXapm_paraprobe_tessellator_results.yaml | 614 ----- .../nyaml/NXapm_paraprobe_tool_common.yaml | 223 -- .../nyaml/NXapm_paraprobe_tool_config.yaml | 239 -- .../nyaml/NXapm_paraprobe_tool_results.yaml | 149 - .../NXapm_paraprobe_transcoder_config.yaml | 145 - .../NXapm_paraprobe_transcoder_results.yaml | 389 --- contributed_definitions/nyaml/NXatom_set.yaml | 272 -- .../nyaml/NXbeam_path.yaml | 780 ------ .../nyaml/NXbeam_splitter.yaml | 637 ----- .../nyaml/NXbias_spectroscopy.yaml | 282 -- .../nyaml/NXcontainer.yaml | 294 -- contributed_definitions/nyaml/NXcsg.yaml | 119 - .../nyaml/NXcxi_ptycho.yaml | 440 --- .../nyaml/NXdelocalization.yaml | 240 -- .../nyaml/NXdispersion.yaml | 52 - .../nyaml/NXdispersion_function.yaml | 205 -- .../NXdispersion_repeated_parameter.yaml | 99 - .../nyaml/NXdispersion_single_parameter.yaml | 61 - .../nyaml/NXdispersion_table.yaml | 140 - .../nyaml/NXdispersive_material.yaml | 409 --- .../nyaml/NXelectrostatic_kicker.yaml | 105 - .../nyaml/NXem_calorimetry.yaml | 578 ---- contributed_definitions/nyaml/NXfiber.yaml | 358 --- .../nyaml/NXgraph_edge_set.yaml | 205 -- .../nyaml/NXgraph_node_set.yaml | 189 -- .../nyaml/NXgraph_root.yaml | 48 - .../nyaml/NXisocontour.yaml | 117 - contributed_definitions/nyaml/NXiv_bias.yaml | 324 --- contributed_definitions/nyaml/NXiv_temp.yaml | 164 -- ..._electro_chemo_mechanical_preparation.yaml | 317 --- .../nyaml/NXlab_sample_mounting.yaml | 151 - contributed_definitions/nyaml/NXlockin.yaml | 252 -- .../nyaml/NXmagnetic_kicker.yaml | 102 - .../nyaml/NXmatch_filter.yaml | 93 - .../nyaml/NXmicrostructure.yaml | 1407 ---------- .../NXmicrostructure_gragles_config.yaml | 657 ----- .../NXmicrostructure_gragles_results.yaml | 514 ---- .../nyaml/NXmicrostructure_imm_config.yaml | 423 --- .../nyaml/NXmicrostructure_imm_results.yaml | 336 --- .../nyaml/NXmicrostructure_ipf.yaml | 433 --- .../NXmicrostructure_kanapy_results.yaml | 344 --- .../nyaml/NXmicrostructure_mtex_config.yaml | 525 ---- .../nyaml/NXmicrostructure_odf.yaml | 382 --- .../nyaml/NXmicrostructure_pf.yaml | 189 -- .../nyaml/NXmicrostructure_score_config.yaml | 930 ------- .../nyaml/NXmicrostructure_score_results.yaml | 954 ------- .../nyaml/NXmicrostructure_slip_system.yaml | 121 - .../nyaml/NXpolarizer_opt.yaml | 411 --- .../nyaml/NXpositioner_sts.yaml | 552 ---- contributed_definitions/nyaml/NXquadric.yaml | 117 - .../nyaml/NXquadrupole_magnet.yaml | 84 - contributed_definitions/nyaml/NXregion.yaml | 340 --- .../nyaml/NXsensor_scan.yaml | 335 --- .../nyaml/NXsensor_sts.yaml | 384 --- .../nyaml/NXseparator.yaml | 108 - .../nyaml/NXsimilarity_grouping.yaml | 268 -- contributed_definitions/nyaml/NXsnsevent.yaml | 642 ----- contributed_definitions/nyaml/NXsnshisto.yaml | 672 ----- .../nyaml/NXsolenoid_magnet.yaml | 84 - .../nyaml/NXsolid_geometry.yaml | 76 - .../nyaml/NXspatial_filter.yaml | 139 - .../nyaml/NXspin_rotator.yaml | 108 - contributed_definitions/nyaml/NXsts.yaml | 1909 ------------- .../nyaml/NXsubsampling_filter.yaml | 73 - .../nyaml/NXtransmission.yaml | 610 ----- contributed_definitions/nyaml/NXxpcs.yaml | 1085 -------- contributed_definitions/nyaml/NXxrd.yaml | 161 -- contributed_definitions/nyaml/NXxrd_pan.yaml | 581 ---- 180 files changed, 65833 deletions(-) delete mode 100644 applications/nyaml/NXarchive.yaml delete mode 100644 applications/nyaml/NXarpes.yaml delete mode 100644 applications/nyaml/NXcanSAS.yaml delete mode 100644 applications/nyaml/NXdirecttof.yaml delete mode 100644 applications/nyaml/NXfluo.yaml delete mode 100644 applications/nyaml/NXindirecttof.yaml delete mode 100644 applications/nyaml/NXiqproc.yaml delete mode 100644 applications/nyaml/NXlauetof.yaml delete mode 100644 applications/nyaml/NXmonopd.yaml delete mode 100644 applications/nyaml/NXmx.yaml delete mode 100644 applications/nyaml/NXrefscan.yaml delete mode 100644 applications/nyaml/NXreftof.yaml delete mode 100644 applications/nyaml/NXsas.yaml delete mode 100644 applications/nyaml/NXsastof.yaml delete mode 100644 applications/nyaml/NXscan.yaml delete mode 100644 applications/nyaml/NXspe.yaml delete mode 100644 applications/nyaml/NXsqom.yaml delete mode 100644 applications/nyaml/NXstxm.yaml delete mode 100644 applications/nyaml/NXtas.yaml delete mode 100644 applications/nyaml/NXtofnpd.yaml delete mode 100644 applications/nyaml/NXtofraw.yaml delete mode 100644 applications/nyaml/NXtofsingle.yaml delete mode 100644 applications/nyaml/NXtomo.yaml delete mode 100644 applications/nyaml/NXtomophase.yaml delete mode 100644 applications/nyaml/NXtomoproc.yaml delete mode 100644 applications/nyaml/NXxas.yaml delete mode 100644 applications/nyaml/NXxasproc.yaml delete mode 100644 applications/nyaml/NXxbase.yaml delete mode 100644 applications/nyaml/NXxeuler.yaml delete mode 100644 applications/nyaml/NXxkappa.yaml delete mode 100644 applications/nyaml/NXxlaue.yaml delete mode 100644 applications/nyaml/NXxlaueplate.yaml delete mode 100644 applications/nyaml/NXxnb.yaml delete mode 100644 applications/nyaml/NXxrot.yaml delete mode 100644 base_classes/nyaml/NXaperture.yaml delete mode 100644 base_classes/nyaml/NXattenuator.yaml delete mode 100644 base_classes/nyaml/NXbeam.yaml delete mode 100644 base_classes/nyaml/NXbeam_stop.yaml delete mode 100644 base_classes/nyaml/NXbending_magnet.yaml delete mode 100644 base_classes/nyaml/NXcapillary.yaml delete mode 100644 base_classes/nyaml/NXcite.yaml delete mode 100644 base_classes/nyaml/NXcollection.yaml delete mode 100644 base_classes/nyaml/NXcollimator.yaml delete mode 100644 base_classes/nyaml/NXcrystal.yaml delete mode 100644 base_classes/nyaml/NXcylindrical_geometry.yaml delete mode 100644 base_classes/nyaml/NXdata.yaml delete mode 100644 base_classes/nyaml/NXdetector.yaml delete mode 100644 base_classes/nyaml/NXdetector_channel.yaml delete mode 100644 base_classes/nyaml/NXdetector_group.yaml delete mode 100644 base_classes/nyaml/NXdetector_module.yaml delete mode 100644 base_classes/nyaml/NXdisk_chopper.yaml delete mode 100644 base_classes/nyaml/NXentry.yaml delete mode 100644 base_classes/nyaml/NXenvironment.yaml delete mode 100644 base_classes/nyaml/NXevent_data.yaml delete mode 100644 base_classes/nyaml/NXfermi_chopper.yaml delete mode 100644 base_classes/nyaml/NXfilter.yaml delete mode 100644 base_classes/nyaml/NXflipper.yaml delete mode 100644 base_classes/nyaml/NXfresnel_zone_plate.yaml delete mode 100644 base_classes/nyaml/NXgeometry.yaml delete mode 100644 base_classes/nyaml/NXgrating.yaml delete mode 100644 base_classes/nyaml/NXguide.yaml delete mode 100644 base_classes/nyaml/NXinsertion_device.yaml delete mode 100644 base_classes/nyaml/NXinstrument.yaml delete mode 100644 base_classes/nyaml/NXlog.yaml delete mode 100644 base_classes/nyaml/NXmirror.yaml delete mode 100644 base_classes/nyaml/NXmoderator.yaml delete mode 100644 base_classes/nyaml/NXmonitor.yaml delete mode 100644 base_classes/nyaml/NXmonochromator.yaml delete mode 100644 base_classes/nyaml/NXnote.yaml delete mode 100644 base_classes/nyaml/NXobject.yaml delete mode 100644 base_classes/nyaml/NXoff_geometry.yaml delete mode 100644 base_classes/nyaml/NXorientation.yaml delete mode 100644 base_classes/nyaml/NXparameters.yaml delete mode 100644 base_classes/nyaml/NXpdb.yaml delete mode 100644 base_classes/nyaml/NXpinhole.yaml delete mode 100644 base_classes/nyaml/NXpolarizer.yaml delete mode 100644 base_classes/nyaml/NXpositioner.yaml delete mode 100644 base_classes/nyaml/NXprocess.yaml delete mode 100644 base_classes/nyaml/NXreflections.yaml delete mode 100644 base_classes/nyaml/NXroot.yaml delete mode 100644 base_classes/nyaml/NXsample.yaml delete mode 100644 base_classes/nyaml/NXsample_component.yaml delete mode 100644 base_classes/nyaml/NXsensor.yaml delete mode 100644 base_classes/nyaml/NXshape.yaml delete mode 100644 base_classes/nyaml/NXslit.yaml delete mode 100644 base_classes/nyaml/NXsource.yaml delete mode 100644 base_classes/nyaml/NXsubentry.yaml delete mode 100644 base_classes/nyaml/NXtransformations.yaml delete mode 100644 base_classes/nyaml/NXtranslation.yaml delete mode 100644 base_classes/nyaml/NXuser.yaml delete mode 100644 base_classes/nyaml/NXvelocity_selector.yaml delete mode 100644 base_classes/nyaml/NXxraylens.yaml delete mode 100644 contributed_definitions/nyaml/NXamplifier.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_compositionspace_config.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_compositionspace_results.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_surfacer_config.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_tool_results.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml delete mode 100644 contributed_definitions/nyaml/NXatom_set.yaml delete mode 100644 contributed_definitions/nyaml/NXbeam_path.yaml delete mode 100644 contributed_definitions/nyaml/NXbeam_splitter.yaml delete mode 100644 contributed_definitions/nyaml/NXbias_spectroscopy.yaml delete mode 100644 contributed_definitions/nyaml/NXcontainer.yaml delete mode 100644 contributed_definitions/nyaml/NXcsg.yaml delete mode 100644 contributed_definitions/nyaml/NXcxi_ptycho.yaml delete mode 100644 contributed_definitions/nyaml/NXdelocalization.yaml delete mode 100644 contributed_definitions/nyaml/NXdispersion.yaml delete mode 100644 contributed_definitions/nyaml/NXdispersion_function.yaml delete mode 100644 contributed_definitions/nyaml/NXdispersion_repeated_parameter.yaml delete mode 100644 contributed_definitions/nyaml/NXdispersion_single_parameter.yaml delete mode 100644 contributed_definitions/nyaml/NXdispersion_table.yaml delete mode 100644 contributed_definitions/nyaml/NXdispersive_material.yaml delete mode 100644 contributed_definitions/nyaml/NXelectrostatic_kicker.yaml delete mode 100644 contributed_definitions/nyaml/NXem_calorimetry.yaml delete mode 100644 contributed_definitions/nyaml/NXfiber.yaml delete mode 100644 contributed_definitions/nyaml/NXgraph_edge_set.yaml delete mode 100644 contributed_definitions/nyaml/NXgraph_node_set.yaml delete mode 100644 contributed_definitions/nyaml/NXgraph_root.yaml delete mode 100644 contributed_definitions/nyaml/NXisocontour.yaml delete mode 100644 contributed_definitions/nyaml/NXiv_bias.yaml delete mode 100644 contributed_definitions/nyaml/NXiv_temp.yaml delete mode 100644 contributed_definitions/nyaml/NXlab_electro_chemo_mechanical_preparation.yaml delete mode 100644 contributed_definitions/nyaml/NXlab_sample_mounting.yaml delete mode 100644 contributed_definitions/nyaml/NXlockin.yaml delete mode 100644 contributed_definitions/nyaml/NXmagnetic_kicker.yaml delete mode 100644 contributed_definitions/nyaml/NXmatch_filter.yaml delete mode 100644 contributed_definitions/nyaml/NXmicrostructure.yaml delete mode 100644 contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml delete mode 100644 contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml delete mode 100644 contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml delete mode 100644 contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml delete mode 100644 contributed_definitions/nyaml/NXmicrostructure_ipf.yaml delete mode 100644 contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml delete mode 100644 contributed_definitions/nyaml/NXmicrostructure_mtex_config.yaml delete mode 100644 contributed_definitions/nyaml/NXmicrostructure_odf.yaml delete mode 100644 contributed_definitions/nyaml/NXmicrostructure_pf.yaml delete mode 100644 contributed_definitions/nyaml/NXmicrostructure_score_config.yaml delete mode 100644 contributed_definitions/nyaml/NXmicrostructure_score_results.yaml delete mode 100644 contributed_definitions/nyaml/NXmicrostructure_slip_system.yaml delete mode 100644 contributed_definitions/nyaml/NXpolarizer_opt.yaml delete mode 100644 contributed_definitions/nyaml/NXpositioner_sts.yaml delete mode 100644 contributed_definitions/nyaml/NXquadric.yaml delete mode 100644 contributed_definitions/nyaml/NXquadrupole_magnet.yaml delete mode 100644 contributed_definitions/nyaml/NXregion.yaml delete mode 100644 contributed_definitions/nyaml/NXsensor_scan.yaml delete mode 100644 contributed_definitions/nyaml/NXsensor_sts.yaml delete mode 100644 contributed_definitions/nyaml/NXseparator.yaml delete mode 100644 contributed_definitions/nyaml/NXsimilarity_grouping.yaml delete mode 100644 contributed_definitions/nyaml/NXsnsevent.yaml delete mode 100644 contributed_definitions/nyaml/NXsnshisto.yaml delete mode 100644 contributed_definitions/nyaml/NXsolenoid_magnet.yaml delete mode 100644 contributed_definitions/nyaml/NXsolid_geometry.yaml delete mode 100644 contributed_definitions/nyaml/NXspatial_filter.yaml delete mode 100644 contributed_definitions/nyaml/NXspin_rotator.yaml delete mode 100644 contributed_definitions/nyaml/NXsts.yaml delete mode 100644 contributed_definitions/nyaml/NXsubsampling_filter.yaml delete mode 100644 contributed_definitions/nyaml/NXtransmission.yaml delete mode 100644 contributed_definitions/nyaml/NXxpcs.yaml delete mode 100644 contributed_definitions/nyaml/NXxrd.yaml delete mode 100644 contributed_definitions/nyaml/NXxrd_pan.yaml diff --git a/applications/nyaml/NXarchive.yaml b/applications/nyaml/NXarchive.yaml deleted file mode 100644 index fb5875e5f6..0000000000 --- a/applications/nyaml/NXarchive.yaml +++ /dev/null @@ -1,281 +0,0 @@ -category: application -doc: | - This is a definition for data to be archived by ICAT (http://www.icatproject.org/). - - .. text from the icatproject.org site - - the database (with supporting software) that provides an - interface to all ISIS experimental data and will provide - a mechanism to link all aspects of ISIS research from - proposal through to publication. -type: group -NXarchive(NXobject): - (NXentry)entry: - \@index: - title: - experiment_identifier(NX_CHAR): - doc: | - unique identifier for the experiment - experiment_description(NX_CHAR): - doc: | - Brief description of the experiment and its objectives - collection_identifier(NX_CHAR): - doc: | - ID of user or DAQ define group of data files - collection_description(NX_CHAR): - doc: | - Brief summary of the collection, including grouping criteria - entry_identifier(NX_CHAR): - doc: | - unique identifier for this measurement as provided by the facility - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - duration(NX_FLOAT): - unit: NX_TIME - doc: | - TODO: needs documentation - collection_time(NX_FLOAT): - unit: NX_TIME - doc: | - TODO: needs documentation - run_cycle(NX_CHAR): - doc: | - TODO: needs documentation - revision(NX_CHAR): - doc: | - revision ID of this file, may be after recalibration, reprocessing etc. - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXarchive] - program(NX_CHAR): - doc: | - The program and version used for generating this file - \@version: - release_date(NX_CHAR): - unit: NX_TIME - doc: | - when this file is to be released into PD - (NXuser)user: - name(NX_CHAR): - role(NX_CHAR): - doc: | - role of the user - facility_user_id(NX_CHAR): - doc: | - ID of the user in the facility burocracy database - (NXinstrument)instrument: - (NXsource): - type(NX_CHAR): - - # TODO: suggest changing from enumeration to suggested list - enumeration: [Spallation Neutron Source, Pulsed Reactor Neutron Source, Reactor Neutron Source, Synchrotron X-Ray Source, Pulsed Muon Source, Rotating Anode X-Ray, Fixed Tube X-Ray] - name: - probe: - enumeration: [neutron, x-ray, electron] - name(NX_CHAR): - description(NX_CHAR): - doc: | - Brief description of the instrument - (NXsample)sample: - name: - doc: | - Descriptive name of sample - sample_id(NX_CHAR): - doc: | - Unique database id of the sample - description(NX_CHAR): - type(NX_CHAR): - enumeration: [sample, sample+can, calibration sample, normalisation sample, simulated data, none, sample_environment] - chemical_formula(NX_CHAR): - doc: | - Chemical formula formatted according to CIF conventions - preparation_date(NX_CHAR): - unit: NX_TIME - situation(NX_CHAR): - doc: | - Description of the environment the sample is in: - air, vacuum, oxidizing atmosphere, dehydrated, etc. - temperature(NX_FLOAT): - unit: NX_TEMPERATURE - magnetic_field(NX_FLOAT): - unit: NX_CURRENT - electric_field(NX_FLOAT): - unit: NX_VOLTAGE - stress_field(NX_FLOAT): - unit: NX_UNITLESS - pressure(NX_FLOAT): - unit: NX_PRESSURE - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4e9e385245760c41bc4f8f594b011c633535fbdbbe8a1951bf50fa1b19e5ed59 -# -# -# -# -# -# This is a definition for data to be archived by ICAT (http://www.icatproject.org/). -# -# .. text from the icatproject.org site -# -# the database (with supporting software) that provides an -# interface to all ISIS experimental data and will provide -# a mechanism to link all aspects of ISIS research from -# proposal through to publication. -# -# -# -# -# -# unique identifier for the experiment -# -# -# Brief description of the experiment and its objectives -# -# -# ID of user or DAQ define group of data files -# -# -# Brief summary of the collection, including grouping criteria -# -# -# unique identifier for this measurement as provided by the facility -# -# -# -# -# TODO: needs documentation -# -# -# TODO: needs documentation -# -# -# TODO: needs documentation -# -# -# revision ID of this file, may be after recalibration, reprocessing etc. -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# The program and version used for generating this file -# -# -# when this file is to be released into PD -# -# -# -# role of the user -# -# ID of the user in the facility burocracy database -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Brief description of the instrument -# -# -# -# -# Descriptive name of sample -# -# -# Unique database id of the sample -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Chemical formula formatted according to CIF conventions -# -# -# -# -# Description of the environment the sample is in: -# air, vacuum, oxidizing atmosphere, dehydrated, etc. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXarpes.yaml b/applications/nyaml/NXarpes.yaml deleted file mode 100644 index 406be3dc17..0000000000 --- a/applications/nyaml/NXarpes.yaml +++ /dev/null @@ -1,236 +0,0 @@ -category: application -doc: | - This is an application definition for angular resolved photo electron spectroscopy. - - It has been drawn up with hemispherical electron analysers in mind. - - This definition is a legacy support for older NXarpes experiments. - There is, however, a newer definition to collect data & metadata - for general photoemission experiments, called :ref:`NXmpes`, - as well as a specialization for ARPES experiments, called :ref:`NXmpes_arpes`." -type: group -NXarpes(NXobject): - (NXentry): - \@entry: - doc: | - NeXus convention is to use "entry1", "entry2", ... - for analysis software to locate each entry. - title(NX_CHAR): - start_time(NX_DATE_TIME): - definition: - doc: | - Official NeXus NXDL schema to which this file conforms. - enumeration: [NXarpes] - (NXinstrument): - (NXsource): - type(NX_CHAR): - name(NX_CHAR): - probe: - enumeration: [x-ray] - (NXmonochromator)monochromator: - energy(NX_NUMBER): - unit: NX_ENERGY - (NXdetector)analyser: - data(NX_NUMBER): - lens_mode(NX_CHAR): - doc: | - setting for the electron analyser lens - acquisition_mode: - enumeration: [swept, fixed] - entrance_slit_shape: - enumeration: [curved, straight] - entrance_slit_setting(NX_NUMBER): - unit: NX_ANY - doc: | - dial setting of the entrance slit - entrance_slit_size(NX_NUMBER): - unit: NX_LENGTH - doc: | - size of the entrance slit - pass_energy(NX_NUMBER): - unit: NX_ENERGY - doc: | - energy of the electrons on the mean path of the analyser - time_per_channel(NX_NUMBER): - unit: NX_TIME - doc: | - todo: define more clearly - angles(NX_NUMBER): - unit: NX_ANGLE - doc: | - Angular axis of the analyser data - which dimension the axis applies to is defined - using the normal NXdata methods. - energies(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy axis of the analyser data - which dimension the axis applies to is defined - using the normal NXdata methods. - sensor_size(NX_INT): - doc: | - number of raw active elements in each dimension - dimensions: - rank: 1 - dim: [[1, 2]] - region_origin(NX_INT): - doc: | - origin of rectangular region selected for readout - dimensions: - rank: 1 - dim: [[1, 2]] - region_size(NX_INT): - doc: | - size of rectangular region selected for readout - dimensions: - rank: 1 - dim: [[1, 2]] - (NXsample): - name(NX_CHAR): - doc: | - Descriptive name of sample - temperature(NX_NUMBER): - unit: NX_TEMPERATURE - (NXdata): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 363b137225f9c57941ef040096f1917d9e68c69ff17e7f3ecd9024f18df65325 -# -# -# -# -# -# This is an application definition for angular resolved photo electron spectroscopy. -# -# It has been drawn up with hemispherical electron analysers in mind. -# -# This definition is a legacy support for older NXarpes experiments. -# There is, however, a newer definition to collect data & metadata -# for general photoemission experiments, called :ref:`NXmpes`, -# as well as a specialization for ARPES experiments, called :ref:`NXmpes_arpes`." -# -# -# -# -# NeXus convention is to use "entry1", "entry2", ... -# for analysis software to locate each entry. -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# setting for the electron analyser lens -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# dial setting of the entrance slit -# -# -# size of the entrance slit -# -# -# energy of the electrons on the mean path of the analyser -# -# -# todo: define more clearly -# -# -# -# Angular axis of the analyser data -# which dimension the axis applies to is defined -# using the normal NXdata methods. -# -# -# -# -# Energy axis of the analyser data -# which dimension the axis applies to is defined -# using the normal NXdata methods. -# -# -# -# number of raw active elements in each dimension -# -# -# -# -# -# origin of rectangular region selected for readout -# -# -# -# -# -# size of rectangular region selected for readout -# -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# -# -# \ No newline at end of file diff --git a/applications/nyaml/NXcanSAS.yaml b/applications/nyaml/NXcanSAS.yaml deleted file mode 100644 index 35dc51b964..0000000000 --- a/applications/nyaml/NXcanSAS.yaml +++ /dev/null @@ -1,2422 +0,0 @@ -category: application -doc: | - Implementation of the canSAS standard to store reduced small-angle scattering data of any dimension. - - .. index:: canSAS - - For more details, see: - - * http://www.cansas.org/ - * http://www.cansas.org/formats/canSAS1d/1.1/doc/ - * http://cansas-org.github.io/canSAS2012/ - * https://github.com/canSAS-org/NXcanSAS_examples - - The minimum requirements for *reduced* small-angle scattering data - as described by canSAS are summarized in the following figure: - - .. _canSAS_2012_minimum: - - .. figure:: canSAS/2012-minimum.png - :width: 60% - - The minimum requirements for *reduced* small-angle scattering data. - (:download:`full image `) - See :ref:`below ` for the minimum required - information for a NeXus data file - written to the NXcanSAS specification. - - .. rubric:: Implementation of canSAS standard in NeXus - - This application definition is an implementation of the canSAS - standard for storing both one-dimensional and multi-dimensional - *reduced* small-angle scattering data. - - * NXcanSAS is for reduced SAS data and metadata to be stored together in one file. - * *Reduced* SAS data consists of :math:`I(\vec{Q})` or :math:`I(|\vec{Q}|)` - * External file links are not to be used for the reduced data. - * A good practice/practise is, at least, to include a reference to how the data was acquired and processed. Yet this is not a requirement. - * There is no need for NXcanSAS to refer to any raw data. - - The canSAS data format has a structure similar to NeXus, not identical. - To allow canSAS data to be expressed in NeXus, yet identifiable - by the canSAS standard, an additional group attribute ``canSAS_class`` - was introduced. Here is the mapping of some common groups. - - =============== ============ ========================== - group (*) NX_class canSAS_class - =============== ============ ========================== - sasentry NXentry SASentry - sasdata NXdata SASdata - sasdetector NXdetector SASdetector - sasinstrument NXinstrument SASinstrument - sasnote NXnote SASnote - sasprocess NXprocess SASprocess - sasprocessnote NXcollection SASprocessnote - sastransmission NXdata SAStransmission_spectrum - sassample NXsample SASsample - sassource NXsource SASsource - =============== ============ ========================== - - (*) The name of each group is a suggestion, - not a fixed requirement and is chosen as fits each data file. - See the section on defining - :ref:`NXDL group and field names `. - - Refer to the NeXus Coordinate System drawing (:ref:`Design-CoordinateSystem`) - for choice and direction of :math:`x`, :math:`y`, and :math:`z` axes. - - .. _NXcanSAS_minimum: - - .. rubric:: The minimum required information for a NeXus data file - written to the NXcanSAS specification. - - .. literalinclude:: canSAS/minimum-required.txt - :tab-width: 4 - :linenos: - :language: text - -# NOTE: -# This NXDL refers to several image files (.jpg, .png) in its documentation. -# All such related resources are stored in the related subdirectory: ./canSAS/ -# In general, for an NXDL file: NXsomenxdl.nxdl.xml -# all related resources should be stored in subdirectory: ./somenxdl/ -type: group -NXcanSAS(NXobject): - (NXentry): - \@default: - exists: optional - doc: | - .. index:: plotting - - Declares which :ref:`NXdata` group - contains the data to be shown by default. - It is needed to resolve ambiguity when more than one :ref:`NXdata` group exists. - The value is the name of the default :ref:`NXdata` group. - Usually, this will be the name of the first *SASdata* group. - doc: | - .. index:: NXcanSAS (applications); SASentry - - Place the canSAS ``SASentry`` group as a child of a NeXus ``NXentry`` group - (when data from multiple techniques are being stored) - or as a replacement for the ``NXentry`` group. - - Note: It is required for all numerical objects to provide - a *units* attribute that describes the engineering units. - Use the Unidata UDunits [#]_ specification - as this is compatible with various community standards. - - .. [#] The UDunits specification also includes instructions for derived units. - \@canSAS_class: - doc: | - Official canSAS group: **SASentry** - enumeration: [SASentry] - \@version: - doc: | - Describes the version of the canSAS standard used to write this data. - This must be a text (not numerical) representation. Such as:: - - @version="1.1" - enumeration: [1.1] - definition: - doc: | - Official NeXus NXDL schema to which this subentry conforms. - enumeration: [NXcanSAS] - - # ============================ - # SASdata - # ============================ - (NXdata): - doc: | - A *SASData* group contains a single reduced small-angle scattering data set - that can be represented as :math:`I(\vec{Q})` or :math:`I(|\vec{Q}|)`. - - *Q* can be either a vector (:math:`\vec{Q}`) or a vector magnitude (:math:`|\vec{Q}|`) - - The name of each *SASdata* group must be unique within a SASentry group. - Suggest using names such as ``sasdata01``. - - NOTE: For the first *SASdata* group, be sure to write the chosen name - into the `SASentry/@default` attribute, as in:: - - SASentry/@default="sasdata01" - - A *SASdata* group has several attributes: - - * I_axes - * Q_indices - * Mask_indices - - To indicate the dependency relationships of other varied parameters, - use attributes similar to ``@Mask_indices`` (such as ``@Temperature_indices`` - or ``@Pressure_indices``). - \@canSAS_class: - doc: | - Official canSAS group: :index:`NXcanSAS (applications); SASdata` - enumeration: [SASdata] - - # attributes, see: http://www.cansas.org/formats/canSAS2012/1.0/doc/framework.html#terms - \@signal: - type: NX_CHAR - doc: | - Name of the default data field. - enumeration: - I: - doc: | - For canSAS **SASdata**, this is always "I". - \@I_axes: - doc: | - String array that defines the independent data fields used in - the default plot for all of the dimensions of the *signal* field - (the *signal* field is the field in this group that is named by - the ``signal`` attribute of this group). - One entry is provided for every dimension of the ``I`` data object. - Such as:: - - @I_axes="Temperature", "Time", "Pressure", "Q", "Q" - - Since there are five items in the list, the intensity field of this example - ``I`` must be a five-dimensional array (rank=5). - \@Q_indices: - type: NX_INT - doc: | - Integer or integer array that describes which indices - (of the :math:`I` data object) are used to - reference the ``Q`` data object. The items in this array - use zero-based indexing. Such as:: - - @Q_indices=1,3,4 - - which indicates that ``Q`` requires three indices - from the :math:`I` data object: one for time and - two for Q position. Thus, in this example, the - ``Q`` data is time-dependent: :math:`\vec{Q}(t)`. - \@mask: - type: NX_CHAR - doc: | - Name of the data mask field. - - .. see: https://github.com/nexusformat/definitions/issues/533 - - The data *mask* must have the same shape as the *data* field. - Positions in the mask correspond to positions in the *data* field. - The value of the mask field may be either a boolean array - where ``false`` means *no mask* and ``true`` means *mask* - or a more descriptive array as as defined in :ref:`NXdetector`. - \@Mask_indices: - exists: optional - doc: | - Integer or integer array that describes which indices - (of the :math:`I` data object) are used to - reference the ``Mask`` data object. The items in this - array use zero-based indexing. Such as:: - - @Mask_indices=3,4 - - which indicates that Q requires two indices - from the :math:`I` data object for Q position. - \@timestamp: - type: NX_DATE_TIME - exists: optional - doc: | - ISO-8601 time [#iso8601]_ - Q(NX_NUMBER): - unit: NX_PER_LENGTH - - # http://www.cansas.org/formats/canSAS2012/1.0/doc/basics.html#definition-of - doc: | - .. index:: NXcanSAS (applications); Q - - Array of :math:`Q` data to accompany :math:`I`. - - .. figure:: canSAS/Q-geometry.jpg - :width: 60% - - The :math:`\vec{Q}` geometry. - (:download:`full image `) - - :math:`Q` may be represented as either - the three-dimensional scattering vector :math:`\vec{Q}` - or the magnitude of the scattering vector, :math:`|\vec{Q}|`. - - .. math:: |\vec{Q}| = (4\pi/\lambda) sin(\theta) - - When we write :math:`Q`, we may refer to either or both of - :math:`|\vec{Q}|` - or :math:`\vec{Q}`, depending on the context. - \@units: - exists: optional - doc: | - Engineering units to use when expressing - :math:`Q` and related terms. - - Data expressed in other units will generate - a warning from validation software and may not - be processed by some analysis software packages. - enumeration: - 1/m: - 1/nm: - doc: | - preferred - 1/angstrom: - \@uncertainties: - exists: optional - doc: | - (optional: for numerical arrays) - - Names the dataset (in this SASdata group) that provides the - uncertainty to be used for data analysis. - The name of the dataset containing the :math:`Q` uncertainty - is flexible. The name must be unique in the *SASdata* group. - - .. comment - see: https://github.com/canSAS-org/canSAS2012/issues/7 - - Such as:: - - @uncertainties="Q_uncertainties" - - The *uncertainties* field will have the same *shape* (dimensions) - as the Q field. - - These values are the estimates of uncertainty of each Q. By default, - this will be interpreted to be the estimated standard deviation. - In special cases, when a standard deviation cannot possibly be used, - its value can specify another measure of distribution width. - - There may also be a subdirectory (optional) with constituent - components. - - .. note:: To report distribution in reported :math:`Q` values, - use the ``@resolutions`` attribute. It is possible for both - ``@resolutions`` and ``uncertainties`` to be reported. - \@resolutions: - type: NX_CHAR - exists: optional - doc: | - .. index:: NXcanSAS (applications); resolutions - - (optional: for numerical arrays) - - Names the dataset (in this SASdata group) containing the :math:`Q` resolution. - The name of the dataset containing the :math:`Q` resolution - is flexible. The name must be unique in the *SASdata* group. - - .. comment - see: https://github.com/canSAS-org/canSAS2012/issues/7 - - The *resolutions* field will have the same *shape* (dimensions) - as the Q field. - - Generally, this is the principal resolution of each :math:`Q`. - Names the data object (in this SASdata group) that provides the - :math:`Q` resolution to be used for data analysis. Such as:: - - @resolutions="Qdev" - - To specify two-dimensional resolution for slit-smearing geometry, - such as (*dQw*, *dQl*), use a string array, such as:: - - @resolutions="dQw", "dQl" - - There may also be a subdirectory (optional) with constituent - components. - - This pattern will demonstrate how to introduce further as-yet - unanticipated terms related to the data. - - .. comment - see: https://github.com/nexusformat/definitions/issues/492#issuecomment-262813907 - - By default, the values of the resolutions data object are assumed to be - one standard deviation of any function used to approximate the - resolution function. This equates to the width of the gaussian - distribution if a Gaussian is chosen. See the ``@resolutions_description`` - attribute. - - .. note:: To report uncertainty in reported :math:`Q` values, - use the ``@uncertainties`` attribute. It is possible for both - ``@resolutions`` and ``uncertainties`` to be reported. - \@resolutions_description: - type: NX_CHAR - exists: optional - doc: | - (optional) - Generally, this describes the :math:`Q` ``@resolutions`` data object. - By default, the value is assumed to be "Gaussian". These are - suggestions: - - * Gaussian - * Lorentzian - * Square : - note that the full width of the square would be ~2.9 times - the standard deviation specified in the vector - * Triangular - * Sawtooth-outward : vertical edge pointing to larger Q - * Sawtooth-inward vertical edge pointing to smaller Q - * Bin : range of values contributing - (for example, when 2-D detector data have been reduced - to a 1-D :math:`I(|Q|)` dataset) - - For other meanings, it may be necessary to provide further details - such as the function used to assess the resolution. - In such cases, use additional datasets or a :ref:`NXnote` subgroup - to include that detail. - I(NX_NUMBER): - - # http://www.cansas.org/formats/canSAS2012/1.0/doc/basics.html#definition-of-intensity - doc: | - .. index:: NXcanSAS (applications); I - - Array of intensity (:math:`I`) data. - - The intensity may be represented in one of these forms: - - **absolute units**: :math:`d\Sigma/d\Omega(Q)` - differential cross-section - per unit volume per unit solid angle (such as: 1/cm/sr or 1/m/sr) - - **absolute units**: :math:`d\sigma/d\Omega(Q)` - differential cross-section - per unit atom per unit solid angle (such as: cm^2 or m^2) - - **arbitrary units**: :math:`I(Q)` - usually a ratio of two detectors - but units are meaningless (such as: a.u. or counts) - - This presents a few problems - for analysis software to sort out when reading the data. - Fortunately, it is possible to analyze the *units* to determine which type of - intensity is being reported and make choices at the time the file is read. But this is - an area for consideration and possible improvement. - - One problem arises with software that automatically converts data into some canonical - units used by that software. The software should not convert units between these different - types of intensity indiscriminately. - - A second problem is that when arbitrary units are used, then the set of possible - analytical results is restricted. With such units, no meaningful volume fraction - or number density can be determined directly from :math:`I(Q)`. - - In some cases, it is possible to apply a factor to convert the arbitrary - units to an absolute scale. This should be considered as a possibility - of the analysis process. - - Where this documentation says *typical units*, it is possible that small-angle - data may be presented in other units and still be consistent with NeXus. - See the :ref:`design-units` section. - \@units: - exists: optional - doc: | - Engineering units to use when expressing - :math:`I` and intensity-related terms. - - Data expressed in other units (or missing a ``@units`` attribute) - will be treated as ``arbitrary`` by some software packages. - - For software using the UDUNITS-2 library, ``arbitrary`` will be - changed to ``unknown`` for handling with that library. - enumeration: - 1/m: - doc: | - includes m2/m3 and 1/m/sr - 1/cm: - doc: | - includes cm2/cm3 and 1/cm/sr - m2/g: - cm2/g: - arbitrary: - \@uncertainties: - exists: optional - doc: | - (optional: for numerical arrays) - - Names the dataset (in this SASdata group) that provides the - uncertainty of :math:`I` to be used for data analysis. - The name of the dataset containing the :math:`I` uncertainty - is flexible. The name must be unique in the *SASdata* group. - - .. comment - see: https://github.com/canSAS-org/canSAS2012/issues/7 - - Generally, this is the estimate of the uncertainty of each :math:`I`. - Typically the estimated standard deviation. - - *Idev* is the canonical name from the 1D standard. - The NXcanSAS standard allows for the name to be described using this attribute. - Such as:: - - @uncertainties="Idev" - \@scaling_factor: - exists: optional - doc: | - (optional) - Names the field (a.k.a. dataset) that contains a factor - to multiply ``I``. By default, this value is unity. - Should an uncertainty be associated with the scaling factor - field, the field containing that uncertainty would be - designated via the ``uncertainties`` attribute. - Such as:: - - I : NX_NUMBER - @uncertainties="Idev" : NX_CHAR - @scaling_factor="I_scaling" : NX_CHAR - Idev : NX_NUMBER - I_scaling : NX_NUMBER - @uncertainties="I_scaling_dev" : NX_CHAR - I_scaling_dev : NX_NUMBER - - The exact names for ``I_scaling`` and ``I_scaling_dev`` are not - defined by NXcanSAS. The user has the flexibility to use names - different than those shown in this example. - Idev(NX_NUMBER): - exists: ['min', '0'] - doc: | - .. index:: NXcanSAS (applications); Idev - - Estimated **uncertainty** (usually standard deviation) - in :math:`I`. Must have the same units as :math:`I`. - - When present, the name of this field is also - recorded in the *uncertainties* attribute of *I*, as in:: - - I/@uncertainties="Idev" - \@units: - exists: optional - doc: | - Engineering units to use when expressing - :math:`I` and intensity-related terms. - - Data expressed in other units (or missing a ``@units`` attribute) - will generate a warning from any validation process - and will be treated as ``arbitrary`` by some analysis software packages. - - For software using the UDUNITS-2 library, ``arbitrary`` will be - changed to ``unknown`` for handling with that library. - enumeration: - 1/m: - doc: | - includes m2/m3 and 1/m/sr - 1/cm: - doc: | - includes cm2/cm3 and 1/cm/sr - m2/g: - cm2/g: - arbitrary: - Qdev(NX_NUMBER): - unit: NX_PER_LENGTH - exists: ['min', '0'] - doc: | - .. index:: NXcanSAS (applications); Qdev - - Estimated :math:`Q` **resolution** (usually standard deviation). - Must have the same units as :math:`Q`. - - When present, the name of this field is also - recorded in the *resolutions* attribute of *Q*, - as in:: - - Q/@resolutions="Qdev" - - or:: - - Q/@resolutions="dQw", "dQl" - \@units: - exists: optional - doc: | - Engineering units to use when expressing - :math:`Q` and related terms. - - Data expressed in other units may not be processed by some - software packages. - enumeration: - 1/m: - 1/nm: - doc: | - preferred - 1/angstrom: - dQw(NX_NUMBER): - unit: NX_PER_LENGTH - exists: ['min', '0'] - doc: | - .. index:: NXcanSAS (applications); dQw - - :math:`Q` **resolution** along the axis of scanning - (the high-resolution *slit width* direction). - Useful for defining resolution data from - slit-smearing instruments such as Bonse-Hart geometry. - Must have the same units as :math:`Q`. - - When present, the name of this field is also - recorded in the *resolutions* attribute of *Q*, - as in:: - - Q/@resolutions="dQw", "dQl" - \@units: - exists: optional - doc: | - Engineering units to use when expressing - :math:`Q` and related terms. - - Data expressed in other units may not be processed by some - software packages. - enumeration: - 1/m: - 1/nm: - doc: | - preferred - 1/angstrom: - dQl(NX_NUMBER): - unit: NX_PER_LENGTH - exists: ['min', '0'] - doc: | - .. index:: NXcanSAS (applications); dQl - - :math:`Q` **resolution** perpendicular to the axis of scanning - (the low-resolution *slit length* direction). - Useful for defining resolution data from - slit-smearing instruments such as Bonse-Hart geometry. - Must have the same units as :math:`Q`. - - When present, the name of this field is also - recorded in the *resolutions* attribute of *Q*, - as in:: - - Q/@resolutions="dQw", "dQl" - \@units: - exists: optional - doc: | - Engineering units to use when expressing - :math:`Q` and related terms. - - Data expressed in other units may not be processed by some - software packages. - enumeration: - 1/m: - 1/nm: - doc: | - preferred - 1/angstrom: - Qmean(NX_NUMBER): - exists: ['min', '0'] - unit: NX_PER_LENGTH - doc: | - Mean value of :math:`Q` for this data point. - Useful when describing data that has been - binned from higher-resolution data. - - It is expected that ``Q`` is provided - and that both ``Q`` and ``Qmean`` will have the same units. - \@units: - exists: optional - doc: | - Engineering units to use when expressing - :math:`Q` and related terms. - - Data expressed in other units may not be processed by some - software packages. - enumeration: - 1/m: - 1/nm: - doc: | - preferred - 1/angstrom: - ShadowFactor: - exists: ['min', '0'] - unit: NX_DIMENSIONLESS - doc: | - A numerical factor applied to pixels affected by the beam stop penumbra. - Used in data files from NIST/NCNR instruments. - - See: J.G. Barker and J.S. Pedersen (1995) *J. Appl. Cryst.* **28**, 105-114. - - # optional items - title: - exists: ['min', '1', 'max', '1'] - doc: | - Title of this *SASentry*. - Make it so that you can recognize the data by its title. - Could be the name of the sample, - the name for the measured data, or something else representative. - run: - exists: ['min', '1', 'max', 'unbounded'] - nameType: any - doc: | - Run identification for this *SASentry*. - For many facilities, this is an integer, such as en experiment number. - Use multiple instances of ``run`` as needed, keeping - in mind that HDF5 requires unique names for all entities - in a group. - \@name: - exists: optional - doc: | - Optional string attribute to identify this particular *run*. - Could use this to associate (correlate) multiple *SASdata* elements with *run* elements. - (NXinstrument): - exists: ['min', '0'] - \@canSAS_class: - doc: | - Official canSAS group: :index:`NXcanSAS (applications); SASinstrument` - enumeration: [SASinstrument] - doc: | - Description of the small-angle scattering instrument. - - Consider, carefully, the relevance to the SAS data analysis process - when adding subgroups in this **NXinstrument** group. Additional information - can be added but will likely be ignored by standardized data anlysis processes. - - The NeXus :ref:`NXbeam` base class may be added as a subgroup of this **NXinstrument** - group *or* as a subgroup of the **NXsample** group to describe properties of the beam at any - point downstream from the source. - - # =========== - # SASaperture - # =========== - (NXaperture): - exists: ['min', '0'] - doc: | - :ref:`NXaperture` is generic and limits the variation in data files. - - Possible NeXus base class alternatives are: :ref:`NXpinhole` or :ref:`NXslit`. - \@canSAS_class: - doc: | - Official canSAS group: :index:`NXcanSAS (applications); SASaperture` - enumeration: [SASaperture] - shape: - doc: | - describe the type of aperture (pinhole, 4-blade slit, Soller slit, ...) - x_gap(NX_NUMBER): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - opening along the :math:`x` axis - y_gap(NX_NUMBER): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - opening along the :math:`y` axis - - # ============== - # SAScollimation - # ============== - (NXcollimator): - exists: ['min', '0'] - \@canSAS_class: - doc: | - Official canSAS group: :index:`NXcanSAS (applications); SAScollimation` - enumeration: [SAScollimation] - doc: | - Description of a collimating element (defines the divergence of the beam) in the instrument. - - To document a slit, pinhole, or the beam, refer to the - documentation of the ``NXinstrument`` group above. - length(NX_NUMBER): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - Amount/length of collimation inserted (as on a SANS instrument) - distance(NX_NUMBER): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - Distance from this collimation element to the sample - - # SAScollimation - - # ============================ - # SASdetector - # ============================ - (NXdetector): - exists: ['min', '0'] - \@canSAS_class: - doc: | - Official canSAS group: :index:`NXcanSAS (applications); SASdetector` - enumeration: [SASdetector] - doc: | - Description of a detector in the instrument. - name: - exists: ['max', '1'] - doc: | - Identifies the name of this detector - SDD(NX_NUMBER): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - Distance between sample and detector. - - Note: In NXdetector, the ``distance`` field records the - distance to the previous component ... most often the sample. - This use is the same as ``SDD`` for most SAS - instruments but not all. For example, Bonse-Hart cameras - have one or more crystals between the sample and detector. - - We define here the field ``SDD`` to document without - ambiguity the distance between sample and detector. - slit_length(NX_NUMBER): - unit: NX_PER_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - Slit length of the instrument for this detector, - expressed in the same units as :math:`Q`. - x_position(NX_NUMBER): - exists: ['min', '0', 'max', '1'] - unit: NX_LENGTH - doc: | - Location of the detector in :math:`x` - y_position(NX_NUMBER): - exists: ['min', '0', 'max', '1'] - unit: NX_LENGTH - doc: | - Location of the detector in :math:`y` - roll(NX_NUMBER): - exists: ['min', '0', 'max', '1'] - unit: NX_ANGLE - doc: | - Rotation of the detector about the :math:`z` axis (roll) - pitch(NX_NUMBER): - exists: ['min', '0', 'max', '1'] - unit: NX_ANGLE - doc: | - Rotation of the detector about the :math:`x` axis (roll) - yaw(NX_NUMBER): - exists: ['min', '0', 'max', '1'] - unit: NX_ANGLE - doc: | - Rotation of the detector about the :math:`y` axis (yaw) - beam_center_x(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - Position of the beam center on the detector. - - This is the x position where the direct beam would hit the detector plane. - This is a length and can be outside of the actual - detector. The length can be in physical units or pixels - as documented by the units attribute. The value can be any - real number (positive, zero, or negative). - beam_center_y(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - Position of the beam center on the detector. - - This is the y position where the direct beam would hit the detector plane. - This is a length and can be outside of the actual - detector. The length can be in physical units or pixels - as documented by the units attribute. The value can be any - real number (positive, zero, or negative). - x_pixel_size(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - Size of each detector pixel. If it is scalar all pixels are the same size - y_pixel_size(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - Size of each detector pixel. If it is scalar all pixels are the same size - - # SASdetector - - # ============================ - # SASsource - # ============================ - (NXsource): - exists: ['min', '0'] - \@canSAS_class: - doc: | - Official canSAS group: :index:`NXcanSAS (applications); SASsource` - enumeration: [SASsource] - doc: | - Description of the radiation source. - radiation: - exists: optional - deprecated: Use either (or both) ``probe`` or ``type`` fields from ``NXsource`` (issue #765) - doc: | - Name of the radiation used. - Note that this is **not** the name of the facility! - - This field contains a value from either the - ``probe`` or ``type`` fields in :ref:`NXsource`. Thus, - it is redundant with existing NeXus structure. - - # enumeration values from NXsource/type and NXsource/probe - enumeration: [Spallation Neutron Source, Pulsed Reactor Neutron Source, Reactor Neutron Source, Synchrotron X-ray Source, Pulsed Muon Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, Ion Source, UV Plasma Source, neutron, x-ray, muon, electron, ultraviolet, visible light, positron, proton] - beam_shape: - exists: ['min', '0', 'max', '1'] - doc: | - Text description of the shape of the beam (incident on the sample). - incident_wavelength(NX_NUMBER): - exists: ['min', '0', 'max', '1'] - unit: NX_WAVELENGTH - doc: | - wavelength (:math:`\lambda`) of radiation incident on the sample - wavelength_min(NX_NUMBER): - exists: ['min', '0', 'max', '1'] - unit: NX_WAVELENGTH - doc: | - Some facilities specify wavelength using a range. - This is the lowest wavelength in such a range. - wavelength_max(NX_NUMBER): - exists: ['min', '0', 'max', '1'] - unit: NX_WAVELENGTH - doc: | - Some facilities specify wavelength using a range. - This is the highest wavelength in such a range. - incident_wavelength_spread(NX_NUMBER): - exists: ['min', '0', 'max', '1'] - unit: NX_WAVELENGTH - doc: | - Some facilities specify wavelength using a range. - This is the width (FWHM) of such a range. - beam_size_x(NX_NUMBER): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - Size of the incident beam along the x axis. - beam_size_y(NX_NUMBER): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - Size of the incident beam along the y axis. - - # SASsource - - # SASinstrument - - # ============== - # SASsample - # ============== - (NXsample): - exists: ['min', '0'] - \@canSAS_class: - doc: | - Official canSAS group: :index:`NXcanSAS (applications); SASsample` - enumeration: [SASsample] - doc: | - Description of the sample. - name: - exists: ['max', '1'] - doc: | - **ID**: Text string that identifies this sample. - thickness(NX_FLOAT): - exists: ['min', '0', 'max', '1'] - unit: NX_LENGTH - doc: | - Thickness of this sample - transmission(NX_NUMBER): - exists: ['min', '0', 'max', '1'] - unit: NX_DIMENSIONLESS - doc: | - Transmission (:math:`I/I_0`) of this sample. - There is no *units* attribute as this number is dimensionless. - - Note: the ability to store a transmission *spectrum*, - instead of a single value, is provided elsewhere in the structure, - in the *SAStransmission_spectrum* element. - temperature(NX_NUMBER): - exists: ['min', '0', 'max', '1'] - unit: NX_TEMPERATURE - doc: | - Temperature of this sample. - details: - exists: ['min', '0', 'max', 'unbounded'] - nameType: any - doc: | - Any additional sample details. - x_position(NX_NUMBER): - exists: ['min', '0', 'max', '1'] - unit: NX_LENGTH - doc: | - Location of the sample in :math:`x` - y_position(NX_NUMBER): - exists: ['min', '0', 'max', '1'] - unit: NX_LENGTH - doc: | - Location of the sample in :math:`y` - roll(NX_NUMBER): - exists: ['min', '0', 'max', '1'] - unit: NX_ANGLE - doc: | - Rotation of the sample about the :math:`z` axis (roll) - pitch(NX_NUMBER): - exists: ['min', '0', 'max', '1'] - unit: NX_ANGLE - doc: | - Rotation of the sample about the :math:`x` axis (roll) - yaw(NX_NUMBER): - exists: ['min', '0', 'max', '1'] - unit: NX_ANGLE - doc: | - Rotation of the sample about the :math:`y` axis (yaw) - - # NXsample - - # ============== - # SASprocess - # ============== - (NXprocess): - exists: ['min', '0', 'max', 'unbounded'] - \@canSAS_class: - doc: | - Official canSAS group: :index:`NXcanSAS (applications); SASprocess` - enumeration: [SASprocess] - doc: | - Description of a processing or analysis step. - - Add additional fields as needed to describe value(s) of any - variable, parameter, or term related to the *SASprocess* step. - Be sure to include *units* attributes for all numerical fields. - name: - exists: ['min', '0', 'max', '1'] - doc: | - Optional name for this data processing or analysis step - date(NX_DATE_TIME): - exists: ['min', '0', 'max', '1'] - doc: | - Optional date for this data processing or analysis step. [#iso8601]_ - - - .. [#iso8601] ISO-8601 standard time representation. - - NeXus dates and times are reported in ISO-8601 - (e.g., ``yyyy-mm-ddThh:mm:ss``) - or modified ISO-8601 (e.g., ``yyyy-mm-dd hh:mm:ss``). - - See: http://www.w3.org/TR/NOTE-datetime - or http://en.wikipedia.org/wiki/ISO_8601 for more details. - description: - exists: ['min', '0', 'max', '1'] - doc: | - Optional description for this data processing or analysis step - term: - exists: ['min', '0', 'max', 'unbounded'] - nameType: any - doc: | - Specifies the value of a single variable, parameter, - or term (while defined here as a string, it could be a number) - related to the *SASprocess* step. - - Note: - The name *term* is not required, it could take any name, - as long as the name is unique within this group. - - # suggested at NIAC2014 - # Isn't this ALWAYS a possibility in any NeXus base class? - # Not needed to define this but it is a good suggestion for usage. - (NXnote): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - Any additional notes or subprocessing steps will be documented here. - - An **NXnote** group can be added to any NeXus group at or below the - **NXentry** group. It is shown here as a suggestion of a good place - to *consider* its use. - (NXcollection): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - Describes anything about *SASprocess* that is not already described. - - Any content not defined in the canSAS standard can be placed at this point. - - Note: - The name of this group is flexible, it could take any name, - as long as it is unique within the **NXprocess** group. - \@canSAS_class: - doc: | - Official canSAS group: :index:`NXcanSAS (applications); SASprocessnote` - enumeration: [SASprocessnote] - - # SASprocessnote - - # SASprocess - - # ============== - # SASnote - # ============== - (NXcollection): - exists: ['min', '0', 'max', 'unbounded'] - \@canSAS_class: - doc: | - Official canSAS group: :index:`NXcanSAS (applications); SASnote` - enumeration: [SASnote] - doc: | - Free form description of anything not covered by other elements. - - # ============================ - # SAStransmission_spectrum - # ============================ - TRANSMISSION_SPECTRUM(NXdata): - exists: ['min', '0'] - doc: | - The *SAStransmission_spectrum* element - - This describes certain data obtained from a variable-wavelength source - such as pulsed-neutron source. - - # requested to be in the 1D format by ISIS - \@canSAS_class: - doc: | - Official canSAS group: :index:`NXcanSAS (applications); SAStransmission_spectrum` - enumeration: [SAStransmission_spectrum] - \@signal: - type: NX_CHAR - doc: | - Name of the default data field. - enumeration: - T: - doc: | - For **SAStransmission_spectrum**, this is always "T". - \@T_axes: - enumeration: - T: - doc: | - the wavelengths field (as axis coordinates) corresponding to this transmission - \@name: - doc: | - Identify what type of spectrum is being described. - It is expected that this value will take either of these two values: - - ====== ============================================== - value meaning - ====== ============================================== - sample measurement with the sample and container - can measurement with just the container - ====== ============================================== - \@timestamp: - type: NX_DATE_TIME - exists: optional - doc: | - ISO-8601 time [#iso8601]_ - lambda(NX_NUMBER): - unit: NX_WAVELENGTH - doc: | - Wavelength of the radiation. - - This array is of the same shape as ``T`` and ``Tdev``. - T(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - Transmission values (:math:`I/I_0`) - as a function of wavelength. - - This array is of the same shape as ``lambda`` and ``Tdev``. - \@uncertainties: - doc: | - Names the dataset (in this SASdata group) that provides the - uncertainty of each transmission :math:`T` to be used for data analysis. - The name of the dataset containing the :math:`T` uncertainty - is expected to be ``Tdev``. - - .. comment - see: https://github.com/canSAS-org/canSAS2012/issues/7 - - Typically: - - @uncertainties="Tdev" - Tdev(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - .. index:: NXcanSAS (applications); Tdev - - Estimated uncertainty (usually standard deviation) - in :math:`T`. Must have the same units as :math:`T`. - - This is the field is named in the *uncertainties* attribute of *T*, as in:: - - T/@uncertainties="Tdev" - - This array is of the same shape as ``lambda`` and ``T``. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f7b73b4f408636f8f8491e39a307745c39fa766019bf00074c62f8b818ba6df8 -# -# -# -# -# -# -# -# -# Implementation of the canSAS standard to store reduced small-angle scattering data of any dimension. -# -# .. index:: canSAS -# -# For more details, see: -# -# * http://www.cansas.org/ -# * http://www.cansas.org/formats/canSAS1d/1.1/doc/ -# * http://cansas-org.github.io/canSAS2012/ -# * https://github.com/canSAS-org/NXcanSAS_examples -# -# The minimum requirements for *reduced* small-angle scattering data -# as described by canSAS are summarized in the following figure: -# -# .. _canSAS_2012_minimum: -# -# .. figure:: canSAS/2012-minimum.png -# :width: 60% -# -# The minimum requirements for *reduced* small-angle scattering data. -# (:download:`full image <canSAS/2012-minimum.png>`) -# See :ref:`below <NXcanSAS_minimum>` for the minimum required -# information for a NeXus data file -# written to the NXcanSAS specification. -# -# .. rubric:: Implementation of canSAS standard in NeXus -# -# This application definition is an implementation of the canSAS -# standard for storing both one-dimensional and multi-dimensional -# *reduced* small-angle scattering data. -# -# * NXcanSAS is for reduced SAS data and metadata to be stored together in one file. -# * *Reduced* SAS data consists of :math:`I(\vec{Q})` or :math:`I(|\vec{Q}|)` -# * External file links are not to be used for the reduced data. -# * A good practice/practise is, at least, to include a reference to how the data was acquired and processed. Yet this is not a requirement. -# * There is no need for NXcanSAS to refer to any raw data. -# -# The canSAS data format has a structure similar to NeXus, not identical. -# To allow canSAS data to be expressed in NeXus, yet identifiable -# by the canSAS standard, an additional group attribute ``canSAS_class`` -# was introduced. Here is the mapping of some common groups. -# -# =============== ============ ========================== -# group (*) NX_class canSAS_class -# =============== ============ ========================== -# sasentry NXentry SASentry -# sasdata NXdata SASdata -# sasdetector NXdetector SASdetector -# sasinstrument NXinstrument SASinstrument -# sasnote NXnote SASnote -# sasprocess NXprocess SASprocess -# sasprocessnote NXcollection SASprocessnote -# sastransmission NXdata SAStransmission_spectrum -# sassample NXsample SASsample -# sassource NXsource SASsource -# =============== ============ ========================== -# -# (*) The name of each group is a suggestion, -# not a fixed requirement and is chosen as fits each data file. -# See the section on defining -# :ref:`NXDL group and field names <RegExpName>`. -# -# Refer to the NeXus Coordinate System drawing (:ref:`Design-CoordinateSystem`) -# for choice and direction of :math:`x`, :math:`y`, and :math:`z` axes. -# -# .. _NXcanSAS_minimum: -# -# .. rubric:: The minimum required information for a NeXus data file -# written to the NXcanSAS specification. -# -# .. literalinclude:: canSAS/minimum-required.txt -# :tab-width: 4 -# :linenos: -# :language: text -# -# -# -# -# -# -# .. index:: plotting -# -# Declares which :ref:`NXdata` group -# contains the data to be shown by default. -# It is needed to resolve ambiguity when more than one :ref:`NXdata` group exists. -# The value is the name of the default :ref:`NXdata` group. -# Usually, this will be the name of the first *SASdata* group. -# -# -# -# .. index:: NXcanSAS (applications); SASentry -# -# Place the canSAS ``SASentry`` group as a child of a NeXus ``NXentry`` group -# (when data from multiple techniques are being stored) -# or as a replacement for the ``NXentry`` group. -# -# Note: It is required for all numerical objects to provide -# a *units* attribute that describes the engineering units. -# Use the Unidata UDunits [#]_ specification -# as this is compatible with various community standards. -# -# .. [#] The UDunits specification also includes instructions for derived units. -# -# -# -# Official canSAS group: **SASentry** -# -# -# -# -# -# -# -# Describes the version of the canSAS standard used to write this data. -# This must be a text (not numerical) representation. Such as:: -# -# @version="1.1" -# -# -# -# -# -# -# -# -# Official NeXus NXDL schema to which this subentry conforms. -# -# -# -# -# -# -# -# -# -# A *SASData* group contains a single reduced small-angle scattering data set -# that can be represented as :math:`I(\vec{Q})` or :math:`I(|\vec{Q}|)`. -# -# *Q* can be either a vector (:math:`\vec{Q}`) or a vector magnitude (:math:`|\vec{Q}|`) -# -# The name of each *SASdata* group must be unique within a SASentry group. -# Suggest using names such as ``sasdata01``. -# -# NOTE: For the first *SASdata* group, be sure to write the chosen name -# into the `SASentry/@default` attribute, as in:: -# -# SASentry/@default="sasdata01" -# -# A *SASdata* group has several attributes: -# -# * I_axes -# * Q_indices -# * Mask_indices -# -# To indicate the dependency relationships of other varied parameters, -# use attributes similar to ``@Mask_indices`` (such as ``@Temperature_indices`` -# or ``@Pressure_indices``). -# -# -# Official canSAS group: :index:`NXcanSAS (applications); SASdata` -# -# -# -# -# -# -# -# Name of the default data field. -# -# -# For canSAS **SASdata**, this is always "I". -# -# -# -# -# String array that defines the independent data fields used in -# the default plot for all of the dimensions of the *signal* field -# (the *signal* field is the field in this group that is named by -# the ``signal`` attribute of this group). -# One entry is provided for every dimension of the ``I`` data object. -# Such as:: -# -# @I_axes="Temperature", "Time", "Pressure", "Q", "Q" -# -# Since there are five items in the list, the intensity field of this example -# ``I`` must be a five-dimensional array (rank=5). -# -# -# -# -# -# Integer or integer array that describes which indices -# (of the :math:`I` data object) are used to -# reference the ``Q`` data object. The items in this array -# use zero-based indexing. Such as:: -# -# @Q_indices=1,3,4 -# -# which indicates that ``Q`` requires three indices -# from the :math:`I` data object: one for time and -# two for Q position. Thus, in this example, the -# ``Q`` data is time-dependent: :math:`\vec{Q}(t)`. -# -# -# -# -# Name of the data mask field. -# -# .. see: https://github.com/nexusformat/definitions/issues/533 -# -# The data *mask* must have the same shape as the *data* field. -# Positions in the mask correspond to positions in the *data* field. -# The value of the mask field may be either a boolean array -# where ``false`` means *no mask* and ``true`` means *mask* -# or a more descriptive array as as defined in :ref:`NXdetector`. -# -# -# -# -# Integer or integer array that describes which indices -# (of the :math:`I` data object) are used to -# reference the ``Mask`` data object. The items in this -# array use zero-based indexing. Such as:: -# -# @Mask_indices=3,4 -# -# which indicates that Q requires two indices -# from the :math:`I` data object for Q position. -# -# -# -# -# ISO-8601 time [#iso8601]_ -# -# -# -# -# -# -# .. index:: NXcanSAS (applications); Q -# -# Array of :math:`Q` data to accompany :math:`I`. -# -# .. figure:: canSAS/Q-geometry.jpg -# :width: 60% -# -# The :math:`\vec{Q}` geometry. -# (:download:`full image <canSAS/Q-geometry.jpg>`) -# -# :math:`Q` may be represented as either -# the three-dimensional scattering vector :math:`\vec{Q}` -# or the magnitude of the scattering vector, :math:`|\vec{Q}|`. -# -# .. math:: |\vec{Q}| = (4\pi/\lambda) sin(\theta) -# -# When we write :math:`Q`, we may refer to either or both of -# :math:`|\vec{Q}|` -# or :math:`\vec{Q}`, depending on the context. -# -# -# -# Engineering units to use when expressing -# :math:`Q` and related terms. -# -# Data expressed in other units will generate -# a warning from validation software and may not -# be processed by some analysis software packages. -# -# -# -# -# preferred -# -# -# -# -# -# -# (optional: for numerical arrays) -# -# Names the dataset (in this SASdata group) that provides the -# uncertainty to be used for data analysis. -# The name of the dataset containing the :math:`Q` uncertainty -# is flexible. The name must be unique in the *SASdata* group. -# -# .. comment -# see: https://github.com/canSAS-org/canSAS2012/issues/7 -# -# Such as:: -# -# @uncertainties="Q_uncertainties" -# -# The *uncertainties* field will have the same *shape* (dimensions) -# as the Q field. -# -# These values are the estimates of uncertainty of each Q. By default, -# this will be interpreted to be the estimated standard deviation. -# In special cases, when a standard deviation cannot possibly be used, -# its value can specify another measure of distribution width. -# -# There may also be a subdirectory (optional) with constituent -# components. -# -# .. note:: To report distribution in reported :math:`Q` values, -# use the ``@resolutions`` attribute. It is possible for both -# ``@resolutions`` and ``uncertainties`` to be reported. -# -# -# -# -# -# .. index:: NXcanSAS (applications); resolutions -# -# (optional: for numerical arrays) -# -# Names the dataset (in this SASdata group) containing the :math:`Q` resolution. -# The name of the dataset containing the :math:`Q` resolution -# is flexible. The name must be unique in the *SASdata* group. -# -# .. comment -# see: https://github.com/canSAS-org/canSAS2012/issues/7 -# -# The *resolutions* field will have the same *shape* (dimensions) -# as the Q field. -# -# Generally, this is the principal resolution of each :math:`Q`. -# Names the data object (in this SASdata group) that provides the -# :math:`Q` resolution to be used for data analysis. Such as:: -# -# @resolutions="Qdev" -# -# To specify two-dimensional resolution for slit-smearing geometry, -# such as (*dQw*, *dQl*), use a string array, such as:: -# -# @resolutions="dQw", "dQl" -# -# There may also be a subdirectory (optional) with constituent -# components. -# -# This pattern will demonstrate how to introduce further as-yet -# unanticipated terms related to the data. -# -# .. comment -# see: https://github.com/nexusformat/definitions/issues/492#issuecomment-262813907 -# -# By default, the values of the resolutions data object are assumed to be -# one standard deviation of any function used to approximate the -# resolution function. This equates to the width of the gaussian -# distribution if a Gaussian is chosen. See the ``@resolutions_description`` -# attribute. -# -# .. note:: To report uncertainty in reported :math:`Q` values, -# use the ``@uncertainties`` attribute. It is possible for both -# ``@resolutions`` and ``uncertainties`` to be reported. -# -# -# -# -# -# (optional) -# Generally, this describes the :math:`Q` ``@resolutions`` data object. -# By default, the value is assumed to be "Gaussian". These are -# suggestions: -# -# * Gaussian -# * Lorentzian -# * Square : -# note that the full width of the square would be ~2.9 times -# the standard deviation specified in the vector -# * Triangular -# * Sawtooth-outward : vertical edge pointing to larger Q -# * Sawtooth-inward vertical edge pointing to smaller Q -# * Bin : range of values contributing -# (for example, when 2-D detector data have been reduced -# to a 1-D :math:`I(|Q|)` dataset) -# -# For other meanings, it may be necessary to provide further details -# such as the function used to assess the resolution. -# In such cases, use additional datasets or a :ref:`NXnote` subgroup -# to include that detail. -# -# -# -# -# -# -# .. index:: NXcanSAS (applications); I -# -# Array of intensity (:math:`I`) data. -# -# The intensity may be represented in one of these forms: -# -# **absolute units**: :math:`d\Sigma/d\Omega(Q)` -# differential cross-section -# per unit volume per unit solid angle (such as: 1/cm/sr or 1/m/sr) -# -# **absolute units**: :math:`d\sigma/d\Omega(Q)` -# differential cross-section -# per unit atom per unit solid angle (such as: cm^2 or m^2) -# -# **arbitrary units**: :math:`I(Q)` -# usually a ratio of two detectors -# but units are meaningless (such as: a.u. or counts) -# -# This presents a few problems -# for analysis software to sort out when reading the data. -# Fortunately, it is possible to analyze the *units* to determine which type of -# intensity is being reported and make choices at the time the file is read. But this is -# an area for consideration and possible improvement. -# -# One problem arises with software that automatically converts data into some canonical -# units used by that software. The software should not convert units between these different -# types of intensity indiscriminately. -# -# A second problem is that when arbitrary units are used, then the set of possible -# analytical results is restricted. With such units, no meaningful volume fraction -# or number density can be determined directly from :math:`I(Q)`. -# -# In some cases, it is possible to apply a factor to convert the arbitrary -# units to an absolute scale. This should be considered as a possibility -# of the analysis process. -# -# Where this documentation says *typical units*, it is possible that small-angle -# data may be presented in other units and still be consistent with NeXus. -# See the :ref:`design-units` section. -# -# -# -# Engineering units to use when expressing -# :math:`I` and intensity-related terms. -# -# Data expressed in other units (or missing a ``@units`` attribute) -# will be treated as ``arbitrary`` by some software packages. -# -# For software using the UDUNITS-2 library, ``arbitrary`` will be -# changed to ``unknown`` for handling with that library. -# -# -# -# includes m2/m3 and 1/m/sr -# -# -# includes cm2/cm3 and 1/cm/sr -# -# -# -# -# -# -# -# -# (optional: for numerical arrays) -# -# Names the dataset (in this SASdata group) that provides the -# uncertainty of :math:`I` to be used for data analysis. -# The name of the dataset containing the :math:`I` uncertainty -# is flexible. The name must be unique in the *SASdata* group. -# -# .. comment -# see: https://github.com/canSAS-org/canSAS2012/issues/7 -# -# Generally, this is the estimate of the uncertainty of each :math:`I`. -# Typically the estimated standard deviation. -# -# *Idev* is the canonical name from the 1D standard. -# The NXcanSAS standard allows for the name to be described using this attribute. -# Such as:: -# -# @uncertainties="Idev" -# -# -# -# -# -# (optional) -# Names the field (a.k.a. dataset) that contains a factor -# to multiply ``I``. By default, this value is unity. -# Should an uncertainty be associated with the scaling factor -# field, the field containing that uncertainty would be -# designated via the ``uncertainties`` attribute. -# Such as:: -# -# I : NX_NUMBER -# @uncertainties="Idev" : NX_CHAR -# @scaling_factor="I_scaling" : NX_CHAR -# Idev : NX_NUMBER -# I_scaling : NX_NUMBER -# @uncertainties="I_scaling_dev" : NX_CHAR -# I_scaling_dev : NX_NUMBER -# -# The exact names for ``I_scaling`` and ``I_scaling_dev`` are not -# defined by NXcanSAS. The user has the flexibility to use names -# different than those shown in this example. -# -# -# -# -# -# -# .. index:: NXcanSAS (applications); Idev -# -# Estimated **uncertainty** (usually standard deviation) -# in :math:`I`. Must have the same units as :math:`I`. -# -# When present, the name of this field is also -# recorded in the *uncertainties* attribute of *I*, as in:: -# -# I/@uncertainties="Idev" -# -# -# -# -# Engineering units to use when expressing -# :math:`I` and intensity-related terms. -# -# Data expressed in other units (or missing a ``@units`` attribute) -# will generate a warning from any validation process -# and will be treated as ``arbitrary`` by some analysis software packages. -# -# For software using the UDUNITS-2 library, ``arbitrary`` will be -# changed to ``unknown`` for handling with that library. -# -# -# -# includes m2/m3 and 1/m/sr -# -# -# includes cm2/cm3 and 1/cm/sr -# -# -# -# -# -# -# -# -# -# -# .. index:: NXcanSAS (applications); Qdev -# -# Estimated :math:`Q` **resolution** (usually standard deviation). -# Must have the same units as :math:`Q`. -# -# When present, the name of this field is also -# recorded in the *resolutions* attribute of *Q*, -# as in:: -# -# Q/@resolutions="Qdev" -# -# or:: -# -# Q/@resolutions="dQw", "dQl" -# -# -# -# -# Engineering units to use when expressing -# :math:`Q` and related terms. -# -# Data expressed in other units may not be processed by some -# software packages. -# -# -# -# -# preferred -# -# -# -# -# -# -# -# -# .. index:: NXcanSAS (applications); dQw -# -# :math:`Q` **resolution** along the axis of scanning -# (the high-resolution *slit width* direction). -# Useful for defining resolution data from -# slit-smearing instruments such as Bonse-Hart geometry. -# Must have the same units as :math:`Q`. -# -# When present, the name of this field is also -# recorded in the *resolutions* attribute of *Q*, -# as in:: -# -# Q/@resolutions="dQw", "dQl" -# -# -# -# -# Engineering units to use when expressing -# :math:`Q` and related terms. -# -# Data expressed in other units may not be processed by some -# software packages. -# -# -# -# -# preferred -# -# -# -# -# -# -# -# -# .. index:: NXcanSAS (applications); dQl -# -# :math:`Q` **resolution** perpendicular to the axis of scanning -# (the low-resolution *slit length* direction). -# Useful for defining resolution data from -# slit-smearing instruments such as Bonse-Hart geometry. -# Must have the same units as :math:`Q`. -# -# When present, the name of this field is also -# recorded in the *resolutions* attribute of *Q*, -# as in:: -# -# Q/@resolutions="dQw", "dQl" -# -# -# -# -# Engineering units to use when expressing -# :math:`Q` and related terms. -# -# Data expressed in other units may not be processed by some -# software packages. -# -# -# -# -# preferred -# -# -# -# -# -# -# -# -# Mean value of :math:`Q` for this data point. -# Useful when describing data that has been -# binned from higher-resolution data. -# -# It is expected that ``Q`` is provided -# and that both ``Q`` and ``Qmean`` will have the same units. -# -# -# -# Engineering units to use when expressing -# :math:`Q` and related terms. -# -# Data expressed in other units may not be processed by some -# software packages. -# -# -# -# -# preferred -# -# -# -# -# -# -# -# A numerical factor applied to pixels affected by the beam stop penumbra. -# Used in data files from NIST/NCNR instruments. -# -# See: J.G. Barker and J.S. Pedersen (1995) *J. Appl. Cryst.* **28**, 105-114. -# -# -# -# -# -# -# -# -# Title of this *SASentry*. -# Make it so that you can recognize the data by its title. -# Could be the name of the sample, -# the name for the measured data, or something else representative. -# -# -# -# -# Run identification for this *SASentry*. -# For many facilities, this is an integer, such as en experiment number. -# Use multiple instances of ``run`` as needed, keeping -# in mind that HDF5 requires unique names for all entities -# in a group. -# -# -# -# Optional string attribute to identify this particular *run*. -# Could use this to associate (correlate) multiple *SASdata* elements with *run* elements. -# -# -# -# -# -# -# Official canSAS group: :index:`NXcanSAS (applications); SASinstrument` -# -# -# -# -# -# Description of the small-angle scattering instrument. -# -# Consider, carefully, the relevance to the SAS data analysis process -# when adding subgroups in this **NXinstrument** group. Additional information -# can be added but will likely be ignored by standardized data anlysis processes. -# -# The NeXus :ref:`NXbeam` base class may be added as a subgroup of this **NXinstrument** -# group *or* as a subgroup of the **NXsample** group to describe properties of the beam at any -# point downstream from the source. -# -# -# -# -# -# -# :ref:`NXaperture` is generic and limits the variation in data files. -# -# Possible NeXus base class alternatives are: :ref:`NXpinhole` or :ref:`NXslit`. -# -# -# Official canSAS group: :index:`NXcanSAS (applications); SASaperture` -# -# -# -# -# -# -# -# describe the type of aperture (pinhole, 4-blade slit, Soller slit, ...) -# -# -# -# opening along the :math:`x` axis -# -# -# opening along the :math:`y` axis -# -# -# -# -# -# -# Official canSAS group: :index:`NXcanSAS (applications); SAScollimation` -# -# -# -# -# -# Description of a collimating element (defines the divergence of the beam) in the instrument. -# -# To document a slit, pinhole, or the beam, refer to the -# documentation of the ``NXinstrument`` group above. -# -# -# -# Amount/length of collimation inserted (as on a SANS instrument) -# -# -# -# Distance from this collimation element to the sample -# -# -# -# -# -# -# -# -# -# -# Official canSAS group: :index:`NXcanSAS (applications); SASdetector` -# -# -# -# -# -# Description of a detector in the instrument. -# -# -# -# Identifies the name of this detector -# -# -# -# Distance between sample and detector. -# -# Note: In NXdetector, the ``distance`` field records the -# distance to the previous component ... most often the sample. -# This use is the same as ``SDD`` for most SAS -# instruments but not all. For example, Bonse-Hart cameras -# have one or more crystals between the sample and detector. -# -# We define here the field ``SDD`` to document without -# ambiguity the distance between sample and detector. -# -# -# -# -# Slit length of the instrument for this detector, -# expressed in the same units as :math:`Q`. -# -# -# -# -# Location of the detector in :math:`x` -# -# -# Location of the detector in :math:`y` -# -# -# Rotation of the detector about the :math:`z` axis (roll) -# -# -# Rotation of the detector about the :math:`x` axis (roll) -# -# -# Rotation of the detector about the :math:`y` axis (yaw) -# -# -# -# -# Position of the beam center on the detector. -# -# This is the x position where the direct beam would hit the detector plane. -# This is a length and can be outside of the actual -# detector. The length can be in physical units or pixels -# as documented by the units attribute. The value can be any -# real number (positive, zero, or negative). -# -# -# -# -# -# Position of the beam center on the detector. -# -# This is the y position where the direct beam would hit the detector plane. -# This is a length and can be outside of the actual -# detector. The length can be in physical units or pixels -# as documented by the units attribute. The value can be any -# real number (positive, zero, or negative). -# -# -# -# -# Size of each detector pixel. If it is scalar all pixels are the same size -# -# -# -# Size of each detector pixel. If it is scalar all pixels are the same size -# -# -# -# -# -# -# -# -# -# Official canSAS group: :index:`NXcanSAS (applications); SASsource` -# -# -# -# -# -# Description of the radiation source. -# -# -# -# -# Name of the radiation used. -# Note that this is **not** the name of the facility! -# -# This field contains a value from either the -# ``probe`` or ``type`` fields in :ref:`NXsource`. Thus, -# it is redundant with existing NeXus structure. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Text description of the shape of the beam (incident on the sample). -# -# -# wavelength (:math:`\lambda`) of radiation incident on the sample -# -# -# -# Some facilities specify wavelength using a range. -# This is the lowest wavelength in such a range. -# -# -# -# -# Some facilities specify wavelength using a range. -# This is the highest wavelength in such a range. -# -# -# -# -# Some facilities specify wavelength using a range. -# This is the width (FWHM) of such a range. -# -# -# -# Size of the incident beam along the x axis. -# -# -# Size of the incident beam along the y axis. -# -# -# -# -# -# -# -# -# -# -# -# -# Official canSAS group: :index:`NXcanSAS (applications); SASsample` -# -# -# -# -# -# Description of the sample. -# -# -# -# **ID**: Text string that identifies this sample. -# -# -# Thickness of this sample -# -# -# -# Transmission (:math:`I/I_0`) of this sample. -# There is no *units* attribute as this number is dimensionless. -# -# Note: the ability to store a transmission *spectrum*, -# instead of a single value, is provided elsewhere in the structure, -# in the *SAStransmission_spectrum* element. -# -# -# -# Temperature of this sample. -# -# -# Any additional sample details. -# -# -# -# Location of the sample in :math:`x` -# -# -# Location of the sample in :math:`y` -# -# -# Rotation of the sample about the :math:`z` axis (roll) -# -# -# Rotation of the sample about the :math:`x` axis (roll) -# -# -# Rotation of the sample about the :math:`y` axis (yaw) -# -# -# -# -# -# -# -# -# -# -# Official canSAS group: :index:`NXcanSAS (applications); SASprocess` -# -# -# -# -# -# Description of a processing or analysis step. -# -# Add additional fields as needed to describe value(s) of any -# variable, parameter, or term related to the *SASprocess* step. -# Be sure to include *units* attributes for all numerical fields. -# -# -# -# Optional name for this data processing or analysis step -# -# -# -# Optional date for this data processing or analysis step. [#iso8601]_ -# -# -# .. [#iso8601] ISO-8601 standard time representation. -# -# NeXus dates and times are reported in ISO-8601 -# (e.g., ``yyyy-mm-ddThh:mm:ss``) -# or modified ISO-8601 (e.g., ``yyyy-mm-dd hh:mm:ss``). -# -# See: http://www.w3.org/TR/NOTE-datetime -# or http://en.wikipedia.org/wiki/ISO_8601 for more details. -# -# -# -# Optional description for this data processing or analysis step -# -# -# -# Specifies the value of a single variable, parameter, -# or term (while defined here as a string, it could be a number) -# related to the *SASprocess* step. -# -# Note: -# The name *term* is not required, it could take any name, -# as long as the name is unique within this group. -# -# -# -# -# -# -# Any additional notes or subprocessing steps will be documented here. -# -# An **NXnote** group can be added to any NeXus group at or below the -# **NXentry** group. It is shown here as a suggestion of a good place -# to *consider* its use. -# -# -# -# -# -# Describes anything about *SASprocess* that is not already described. -# -# Any content not defined in the canSAS standard can be placed at this point. -# -# Note: -# The name of this group is flexible, it could take any name, -# as long as it is unique within the **NXprocess** group. -# -# -# -# Official canSAS group: :index:`NXcanSAS (applications); SASprocessnote` -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Official canSAS group: :index:`NXcanSAS (applications); SASnote` -# -# -# -# -# -# -# Free form description of anything not covered by other elements. -# -# -# -# -# -# -# -# The *SAStransmission_spectrum* element -# -# This describes certain data obtained from a variable-wavelength source -# such as pulsed-neutron source. -# -# -# The name of each *SAStransmission_spectrum* group must be unique within a SASentry group. -# Suggest using names such as ``sastransmission_spectrum01``. -# -# -# Official canSAS group: :index:`NXcanSAS (applications); SAStransmission_spectrum` -# -# -# -# -# -# -# Name of the default data field. -# -# -# For **SAStransmission_spectrum**, this is always "T". -# -# -# -# -# -# the wavelengths field (as axis coordinates) corresponding to this transmission -# -# -# -# -# -# Identify what type of spectrum is being described. -# It is expected that this value will take either of these two values: -# -# ====== ============================================== -# value meaning -# ====== ============================================== -# sample measurement with the sample and container -# can measurement with just the container -# ====== ============================================== -# -# -# -# -# ISO-8601 time [#iso8601]_ -# -# -# -# -# -# Wavelength of the radiation. -# -# This array is of the same shape as ``T`` and ``Tdev``. -# -# -# -# -# Transmission values (:math:`I/I_0`) -# as a function of wavelength. -# -# This array is of the same shape as ``lambda`` and ``Tdev``. -# -# -# -# Names the dataset (in this SASdata group) that provides the -# uncertainty of each transmission :math:`T` to be used for data analysis. -# The name of the dataset containing the :math:`T` uncertainty -# is expected to be ``Tdev``. -# -# .. comment -# see: https://github.com/canSAS-org/canSAS2012/issues/7 -# -# Typically: -# -# @uncertainties="Tdev" -# -# -# -# -# -# -# -# .. index:: NXcanSAS (applications); Tdev -# -# Estimated uncertainty (usually standard deviation) -# in :math:`T`. Must have the same units as :math:`T`. -# -# This is the field is named in the *uncertainties* attribute of *T*, as in:: -# -# T/@uncertainties="Tdev" -# -# This array is of the same shape as ``lambda`` and ``T``. -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXdirecttof.yaml b/applications/nyaml/NXdirecttof.yaml deleted file mode 100644 index 9501163287..0000000000 --- a/applications/nyaml/NXdirecttof.yaml +++ /dev/null @@ -1,102 +0,0 @@ -category: application -doc: | - This is a application definition for raw data from a direct geometry TOF spectrometer -type: group -NXdirecttof(NXtofraw): - (NXentry)entry: - title: - start_time(NX_DATE_TIME): - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXdirecttof] - (NXinstrument): - (NXfermi_chopper)fermi_chopper: - exists: ['min', '0'] - rotation_speed(NX_FLOAT): - unit: NX_FREQUENCY - doc: | - chopper rotation speed - energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - energy selected - (NXdisk_chopper)disk_chopper: - exists: ['min', '0'] - rotation_speed(NX_FLOAT): - unit: NX_FREQUENCY - doc: | - chopper rotation speed - energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - energy selected - doc: | - We definitly want the rotation_speed and energy of the chopper. Thus either - a fermi_chopper or a disk_chopper group is required. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 175a21371907a28bbe5ff136c358f3417f1004b424c75571f00670f2de04e68e -# -# -# -# -# This is a application definition for raw data from a direct geometry TOF spectrometer -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# chopper rotation speed -# -# -# energy selected -# -# -# -# -# chopper rotation speed -# -# -# energy selected -# -# -# -# We definitly want the rotation_speed and energy of the chopper. Thus either -# a fermi_chopper or a disk_chopper group is required. -# -# -# -# diff --git a/applications/nyaml/NXfluo.yaml b/applications/nyaml/NXfluo.yaml deleted file mode 100644 index 338df107af..0000000000 --- a/applications/nyaml/NXfluo.yaml +++ /dev/null @@ -1,165 +0,0 @@ -category: application -doc: | - This is an application definition for raw data from an X-ray fluorescence experiment -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nE: | - Number of energies -type: group -NXfluo(NXobject): - (NXentry)entry: - title: - start_time(NX_DATE_TIME): - definition: - doc: | - Official NeXus NXDL schema to which this file conforms. - enumeration: [NXfluo] - (NXinstrument): - (NXsource): - type: - name: - probe: - enumeration: [x-ray] - (NXmonochromator)monochromator: - wavelength(NX_FLOAT): - (NXdetector)fluorescence: - data(NX_INT): - axes: energy - signal: 1 - dimensions: - rank: 1 - dim: [[1, nE]] - energy(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, nE]] - (NXsample): - name: - doc: | - Descriptive name of sample - (NXmonitor): - mode: - doc: | - Count to a preset value based on either clock time (timer) - or received monitor counts (monitor). - enumeration: [monitor, timer] - preset(NX_FLOAT): - doc: | - preset value for time or monitor - data(NX_INT): - (NXdata)data: - energy(link): - target: /entry/instrument/fluorescence/energy - data(link): - target: /entry/instrument/fluorescence/data - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 30d5f85902a345877d162fb43d934960a69313437db51d7d94026ee58586ba07 -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of energies -# -# -# -# This is an application definition for raw data from an X-ray fluorescence experiment -# -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# -# -# Count to a preset value based on either clock time (timer) -# or received monitor counts (monitor). -# -# -# -# -# -# -# -# preset value for time or monitor -# -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXindirecttof.yaml b/applications/nyaml/NXindirecttof.yaml deleted file mode 100644 index 844060fb1e..0000000000 --- a/applications/nyaml/NXindirecttof.yaml +++ /dev/null @@ -1,111 +0,0 @@ -category: application -doc: | - This is a application definition for raw data from an indirect geometry TOF spectrometer -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nDet: | - Number of detectors -type: group -NXindirecttof(NXtofraw): - (NXentry)entry: - title: - start_time(NX_DATE_TIME): - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXindirecttof] - (NXinstrument): - (NXmonochromator)analyser: - energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - analyzed energy - dimensions: - rank: 1 - dim: [[1, nDet]] - polar_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - polar angle towards sample - dimensions: - rank: 1 - dim: [[1, nDet]] - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - distance from sample - dimensions: - rank: 1 - dim: [[1, nDet]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a0550f0578b21624fda6133b02939b39481b5cafa865c609096f7a6005688309 -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of detectors -# -# -# This is a application definition for raw data from an indirect geometry TOF spectrometer -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# analyzed energy -# -# -# -# -# polar angle towards sample -# -# -# -# -# distance from sample -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXiqproc.yaml b/applications/nyaml/NXiqproc.yaml deleted file mode 100644 index 4c7fb853ae..0000000000 --- a/applications/nyaml/NXiqproc.yaml +++ /dev/null @@ -1,201 +0,0 @@ -category: application -doc: | - Application definition for any :math:`I(Q)` data. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nVars: | - The number of values taken by the varied variable - nQX: | - Number of values for the first dimension of Q - nQY: | - Number of values for the second dimension of Q -type: group -NXiqproc(NXobject): - (NXentry): - \@entry: - - # TODO documentation string needed here - title: - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXiqproc] - (NXinstrument)instrument: - (NXsource): - type: - name: - probe: - enumeration: [neutron, x-ray, electron] - name(NX_CHAR): - doc: | - Name of the instrument from which this data was reduced. - (NXsample): - name: - doc: | - Descriptive name of sample - (NXprocess)reduction: - program(NX_CHAR): - version(NX_CHAR): - (NXparameters)input: - filenames(NX_CHAR): - doc: | - Raw data files used to generate this I(Q) - doc: | - Input parameters for the reduction program used - (NXparameters)output: - doc: | - Eventual output parameters from the data reduction program used - (NXdata): - data(NX_INT): - signal: 1 - doc: | - This is I(Q). The client has to analyse the dimensions - of I(Q). Often, multiple I(Q) for various environment - conditions are measured; that would be the first - dimension. Q can be multidimensional, this accounts for - the further dimensions in the data - dimensions: - rank: 3 - dim: [[1, nVars], [2, nQX], [3, nQY]] - variable(NX_NUMBER): - axis: 1 - dimensions: - rank: 1 - dim: [[1, nVars]] - \@varied_variable: - doc: | - The real name of the varied variable in the first dim of data, temperature, P, MF etc... - qx(NX_NUMBER): - axis: 2 - doc: | - Values for the first dimension of Q - dimensions: - rank: 1 - dim: [[1, nQX]] - qy(NX_NUMBER): - axis: 3 - doc: | - Values for the second dimension of Q - dimensions: - rank: 1 - dim: [[1, nQY]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d38b0b07ee1bf8257614aa5f1cf6f5b7e3aa03f786c4a538cacb54f8a40c49d1 -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# The number of values taken by the varied variable -# -# -# Number of values for the first dimension of Q -# -# -# Number of values for the second dimension of Q -# -# -# Application definition for any :math:`I(Q)` data. -# -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Name of the instrument from which this data was reduced. -# -# -# -# Descriptive name of sample -# -# -# -# -# -# -# -# Raw data files used to generate this I(Q) -# Input parameters for the reduction program used -# -# Eventual output parameters from the data reduction program used -# -# -# -# This is I(Q). The client has to analyse the dimensions -# of I(Q). Often, multiple I(Q) for various environment -# conditions are measured; that would be the first -# dimension. Q can be multidimensional, this accounts for -# the further dimensions in the data -# -# -# -# -# -# -# -# -# -# -# -# -# The real name of the varied variable in the first dim of data, temperature, P, MF etc... -# -# Values for the first dimension of Q -# -# -# -# Values for the second dimension of Q -# -# -# -# -# diff --git a/applications/nyaml/NXlauetof.yaml b/applications/nyaml/NXlauetof.yaml deleted file mode 100644 index 38397f7fd6..0000000000 --- a/applications/nyaml/NXlauetof.yaml +++ /dev/null @@ -1,244 +0,0 @@ -category: application -doc: | - This is the application definition for a TOF laue diffractometer -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nXPixels: | - Number of X pixels - nYPixels: | - Number of Y pixels - nTOF: | - Time of flight -type: group -NXlauetof(NXobject): - (NXentry)entry: - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXlauetof] - (NXinstrument)instrument: - (NXdetector)detector: - doc: | - This assumes a planar 2D detector. All angles and distances refer to the center of the - detector. - polar_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - The polar_angle (two theta) where the detector is placed. - azimuthal_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - The azimuthal angle where the detector is placed. - data(NX_INT): - signal: 1 - dimensions: - rank: 3 - dim: [[1, nXPixels], [2, nYPixels], [3, nTOF]] - \@signal: - type: NX_POSINT - enumeration: [1] - x_pixel_size(NX_FLOAT): - unit: NX_LENGTH - y_pixel_size(NX_FLOAT): - unit: NX_LENGTH - distance(NX_FLOAT): - unit: NX_LENGTH - time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - dimensions: - rank: 1 - dim: [[1, nTOF]] - (NXsample)sample: - name: - doc: | - Descriptive name of sample - orientation_matrix(NX_FLOAT): - doc: | - The orientation matrix according to Busing and - Levy conventions. This is not strictly necessary as - the UB can always be derived from the data. But - let us bow to common usage which includes thie - UB nearly always. - dimensions: - rank: 2 - dim: [[1, 3], [2, 3]] - unit_cell(NX_FLOAT): - doc: | - The unit cell, a, b, c, alpha, beta, gamma. - Again, not strictly necessary, but normally written. - dimensions: - rank: 1 - dim: [[1, 6]] - (NXmonitor)control: - mode: - doc: | - Count to a preset value based on either clock time (timer) or received monitor counts - (monitor). - enumeration: [monitor, timer] - preset(NX_FLOAT): - doc: | - preset value for time or monitor - data(NX_INT): - doc: | - use these attributes ``primary=1 signal=1`` - dimensions: - rank: 1 - dim: [[1, nTOF]] - time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - dimensions: - rank: 1 - dim: [[1, nTOF]] - (NXdata)name: - data(link): - target: /NXentry/NXinstrument/NXdetector/data - time_of_flight(link): - target: /NXentry/NXinstrument/NXdetector/time_of_flight - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 59ab11d37616973a61abac78e163741ea62b86c4b2a5da5d55682b5ed32e8a3e -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of X pixels -# -# -# Number of Y pixels -# -# -# Time of flight -# -# -# -# This is the application definition for a TOF laue diffractometer -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# This assumes a planar 2D detector. All angles and distances refer to the center of the -# detector. -# -# -# The polar_angle (two theta) where the detector is placed. -# -# -# The azimuthal angle where the detector is placed. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# The orientation matrix according to Busing and -# Levy conventions. This is not strictly necessary as -# the UB can always be derived from the data. But -# let us bow to common usage which includes thie -# UB nearly always. -# -# -# -# -# -# -# -# -# The unit cell, a, b, c, alpha, beta, gamma. -# Again, not strictly necessary, but normally written. -# -# -# -# -# -# -# -# -# Count to a preset value based on either clock time (timer) or received monitor counts -# (monitor). -# -# -# -# -# -# -# preset value for time or monitor -# -# -# use these attributes ``primary=1 signal=1`` -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXmonopd.yaml b/applications/nyaml/NXmonopd.yaml deleted file mode 100644 index 1363650ed1..0000000000 --- a/applications/nyaml/NXmonopd.yaml +++ /dev/null @@ -1,223 +0,0 @@ -category: application -doc: | - Monochromatic Neutron and X-Ray Powder diffractometer - - Instrument - definition for a powder diffractometer at a monochromatic neutron - or X-ray beam. This is both suited for a powder diffractometer - with a single detector or a powder diffractometer with a position - sensitive detector. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - i: | - i is the number of wavelengths - nDet: | - Number of detectors -type: group -NXmonopd(NXobject): - (NXentry)entry: - title: - start_time(NX_DATE_TIME): - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXmonopd] - (NXinstrument): - (NXsource): - type: - name: - probe: - enumeration: [neutron, x-ray, electron] - (NXcrystal): - wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - Optimum diffracted wavelength - dimensions: - rank: 1 - dim: [[1, i]] - (NXdetector): - polar_angle(NX_FLOAT): - axis: 1 - dimensions: - rank: 1 - dim: [[1, nDet]] - data(NX_INT): - signal: 1 - doc: | - detector signal (usually counts) are already - corrected for detector efficiency - dimensions: - rank: 1 - dim: [[1, nDet]] - (NXsample): - name: - doc: | - Descriptive name of sample - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Optional rotation angle for the case when the powder diagram - has been obtained through an omega-2theta scan like from a - traditional single detector powder diffractometer - (NXmonitor): - mode: - doc: | - Count to a preset value based on either clock time (timer) - or received monitor counts (monitor). - enumeration: [monitor, timer] - preset(NX_FLOAT): - doc: | - preset value for time or monitor - integral(NX_FLOAT): - unit: NX_ANY - doc: | - Total integral monitor counts - (NXdata): - polar_angle(link): - target: /NXentry/NXinstrument/NXdetector/polar_angle - doc: | - Link to polar angle in /NXentry/NXinstrument/NXdetector - data(link): - target: /NXentry/NXinstrument/NXdetector/data - doc: | - Link to data in /NXentry/NXinstrument/NXdetector - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 1d641b89853ffc3e1282a2ac56149a3e81943b2511671e389bf3911ddc04d2b7 -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# i is the number of wavelengths -# -# -# Number of detectors -# -# -# -# Monochromatic Neutron and X-Ray Powder diffractometer -# -# Instrument -# definition for a powder diffractometer at a monochromatic neutron -# or X-ray beam. This is both suited for a powder diffractometer -# with a single detector or a powder diffractometer with a position -# sensitive detector. -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Optimum diffracted wavelength -# -# -# -# -# -# -# -# -# -# -# -# -# -# detector signal (usually counts) are already -# corrected for detector efficiency -# -# -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# Optional rotation angle for the case when the powder diagram -# has been obtained through an omega-2theta scan like from a -# traditional single detector powder diffractometer -# -# -# -# -# -# -# Count to a preset value based on either clock time (timer) -# or received monitor counts (monitor). -# -# -# -# -# -# -# -# preset value for time or monitor -# -# -# Total integral monitor counts -# -# -# -# -# Link to polar angle in /NXentry/NXinstrument/NXdetector -# -# -# Link to data in /NXentry/NXinstrument/NXdetector -# -# -# -# diff --git a/applications/nyaml/NXmx.yaml b/applications/nyaml/NXmx.yaml deleted file mode 100644 index 1a3953eca6..0000000000 --- a/applications/nyaml/NXmx.yaml +++ /dev/null @@ -1,1864 +0,0 @@ -category: application -doc: | - functional application definition for macromolecular crystallography -symbols: - doc: | - These symbols will be used below to coordinate datasets - with the same shape. Most MX x-ray detectors will produce - two-dimensional images. Some will produce three-dimensional - images, using one of the indices to select a detector module. - dataRank: | - Rank of the ``data`` field - nP: | - Number of scan points - i: | - Number of detector pixels in the slowest direction - j: | - Number of detector pixels in the second slowest direction - k: | - Number of detector pixels in the third slowest direction - m: | - Number of channels in the incident beam spectrum, if known - groupIndex: | - An array of the hierarchical levels of the parents of detector - elements or groupings of detector elements. - A top-level element or grouping has parent level -1. -type: group -NXmx(NXobject): - (NXentry): - doc: | - Note, it is recommended that ``file_name`` and ``file_time`` are included - as attributes at the root of a file that includes :ref:`NXmx`. See - :ref:`NXroot`. - \@version: - exists: optional - doc: | - Describes the version of the NXmx definition used to write this data. - This must be a text (not numerical) representation. Such as:: - - @version="1.0" - enumeration: [1.0] - title(NX_CHAR): - exists: ['min', '0'] - start_time(NX_DATE_TIME): - doc: | - ISO 8601 time/date of the first data point collected in UTC, - using the Z suffix to avoid confusion with local time. - Note that the time zone of the beamline should be provided in - NXentry/NXinstrument/time_zone. - end_time(NX_DATE_TIME): - exists: ['min', '0'] - doc: | - ISO 8601 time/date of the last data point collected in UTC, - using the Z suffix to avoid confusion with local time. - Note that the time zone of the beamline should be provided in - NXentry/NXinstrument/time_zone. This field should only be - filled when the value is accurately observed. If the data - collection aborts or otherwise prevents accurate recording of - the end_time, this field should be omitted. - end_time_estimated(NX_DATE_TIME): - doc: | - ISO 8601 time/date of the last data point collected in UTC, - using the Z suffix to avoid confusion with local time. - Note that the time zone of the beamline should be provided in - NXentry/NXinstrument/time_zone. This field may be filled - with a value estimated before an observed value is available. - definition: - doc: | - NeXus NXDL schema to which this file conforms - enumeration: [NXmx] - (NXdata): - data(NX_NUMBER): - exists: recommended - doc: | - For a dimension-2 detector, the rank of the data array will be 3. - For a dimension-3 detector, the rank of the data array will be 4. - This allows for the introduction of the frame number as the - first index. - dimensions: - rank: dataRank - dim: [[1, nP], [2, i], [3, j], [4, k]] - dim_parameters: - required: ['false'] - data_scaling_factor(NX_NUMBER): - exists: optional - doc: | - An optional scaling factor to apply to the values in ``data``. - - The elements in ``data`` are often stored as integers for efficiency reasons and need - further correction, generating floats. The two fields data_scaling_factor and - data_offset allow linear corrections using the following convention: - - .. code-block:: - - corrected_data = (data + offset) * scaling_factor - - This formula will derive the corrected value, when necessary. - - data_scaling_factor is sometimes known as gain and data_offset is sometimes - known as pedestal or background, depending on the community. - - Use these fields to specify constants that need to be applied - to the data to correct it to physical values. For example, if the detector gain - is 10 counts per photon and a constant background of 400 needs to be subtracted - off the pixels, specify data_scaling_factor as 0.1 and data_offset as -400 to - specify the required conversion from raw counts to corrected photons. It - is implied processing software will apply these corrections on-the-fly during processing. - - The rank of these fields should either be a single value for the full dataset, a - single per-pixel array applied to every image (dimensions (i, j) or (i, j, k)), - or a per-image correction specified with an array whose slowest rank is nP (dimensions - (np, 1), (np, i, j) or (np, i, j, k)). - - When omitted, the scaling factor is assumed to be 1. - data_offset(NX_NUMBER): - exists: optional - doc: | - An optional offset to apply to the values in data. - - When omitted, the offset is assumed to be 0. - - See :ref:`data_scaling_factor ` for more information. - (NXsample): - name(NX_CHAR): - doc: | - Descriptive name of sample - depends_on(NX_CHAR): - - # better type for paths the need to resolve - doc: | - This is a requirement to describe for any scan experiment. - - The axis on which the sample position depends may be stored - anywhere, but is normally stored in the NXtransformations - group within the NXsample group. - - If there is no goniometer, e.g. with a jet, depends_on - should be set to "." - (NXtransformations): - exists: ['min', '0'] - doc: | - This is the recommended location for sample goniometer - and other related axes. - - This is a requirement to describe for any scan experiment. - The reason it is optional is mainly to accommodate XFEL - single shot exposures. - - Use of the depends_on field and the NXtransformations group is - strongly recommended. As noted above this should be an absolute - requirement to have for any scan experiment. - - The reason it is optional is mainly to accommodate XFEL - single shot exposures. - temperature(NX_NUMBER): - unit: NX_TEMPERATURE - exists: ['min', '0'] - (NXinstrument): - name(NX_CHAR): - exists: ['min', '1'] - - # CAUTION: keep URLs all on one line - doc: | - Name of instrument. Consistency with the controlled - vocabulary beamline naming in - https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.pdbx_synchrotron_beamline.html - and - https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.type.html - is highly recommended. - \@short_name: - exists: optional - doc: | - Short name for instrument, perhaps the acronym. - time_zone(NX_DATE_TIME): - exists: recommended - doc: | - ISO 8601 time_zone offset from UTC. - (NXattenuator): - exists: ['min', '0'] - attenuator_transmission(NX_NUMBER): - unit: NX_UNITLESS - exists: ['min', '0'] - (NXdetector_group): - exists: recommended - doc: | - Optional logical grouping of detectors. - - Each detector is represented as an NXdetector - with its own detector data array. Each detector data array - may be further decomposed into array sections by use of - NXdetector_module groups. Detectors can be grouped logically - together using NXdetector_group. Groups can be further grouped - hierarchically in a single NXdetector_group (for example, if - there are multiple detectors at an endstation or multiple - endstations at a facility). Alternatively, multiple - NXdetector_groups can be provided. - - The groups are defined hierarchically, with names given - in the group_names field, unique identifying indices given - in the field group_index, and the level in the hierarchy - given in the group_parent field. For example if an x-ray - detector group, DET, consists of four detectors in a - rectangular array:: - - DTL DTR - DLL DLR - - We could have:: - - group_names: ["DET", "DTL", "DTR", "DLL", "DLR"] - group_index: [1, 2, 3, 4, 5] - group_parent: [-1, 1, 1, 1, 1] - group_names(NX_CHAR): - doc: | - An array of the names of the detectors or the names of - hierarchical groupings of detectors. - group_index(NX_INT): - doc: | - An array of unique identifiers for detectors or groupings - of detectors. - - Each ID is a unique ID for the corresponding detector or group - named in the field group_names. The IDs are positive integers - starting with 1. - dimensions: - rank: 1 - dim: [[1, i]] - group_parent(NX_INT): - doc: | - An array of the hierarchical levels of the parents of detectors - or groupings of detectors. - - A top-level grouping has parent level -1. - dimensions: - rank: 1 - dim: [[1, groupIndex]] - (NXdetector): - doc: | - Normally the detector group will have the name ``detector``. - However, in the case of multiple detectors, each detector - needs a uniquely named NXdetector. - depends_on(NX_CHAR): - exists: ['min', '0'] - doc: | - NeXus path to the detector positioner axis that most directly - supports the detector. In the case of a single-module - detector, the detector axis chain may start here. - (NXtransformations): - exists: ['min', '0'] - doc: | - Location for axes (transformations) to do with the - detector. In the case of a single-module detector, the - axes of the detector axis chain may be stored here. - (NXcollection): - exists: ['min', '0'] - doc: | - Suggested container for detailed non-standard detector - information like corrections applied automatically or - performance settings. - data(NX_NUMBER): - exists: recommended - doc: | - For a dimension-2 detector, the rank of the data array will be 3. - For a dimension-3 detector, the rank of the data array will be 4. - This allows for the introduction of the frame number as the - first index. - dimensions: - rank: dataRank - dim: [[1, nP], [2, i], [3, j], [4, k]] - dim_parameters: - required: ['false'] - description: - exists: recommended - doc: | - name/manufacturer/model/etc. information. - time_per_channel: - unit: NX_TIME - exists: ['min', '0'] - doc: | - For a time-of-flight detector this is the scaling - factor to convert from the numeric value reported to - the flight time for a given measurement. - (NXdetector_module): - exists: ['min', '1', 'max', 'unbounded'] - doc: | - Many detectors consist of multiple smaller modules that are - operated in sync and store their data in a common dataset. - To allow consistent parsing of the experimental geometry, - this application definiton requires all detectors to - define a detector module, even if there is only one. - - This group specifies the hyperslab of data in the data - array associated with the detector that contains the - data for this module. If the module is associated with - a full data array, rather than with a hyperslab within - a larger array, then a single module should be defined, - spanning the entire array. - - Note, the pixel size is given as values in the array - fast_pixel_direction and slow_pixel_direction. - data_origin(NX_INT): - doc: | - A dimension-2 or dimension-3 field which gives the indices - of the origin of the hyperslab of data for this module in the - main area detector image in the parent NXdetector module. - - The data_origin is 0-based. - - The frame number dimension (nP) is omitted. Thus the - data_origin field for a dimension-2 dataset with indices (nP, i, j) - will be an array with indices (i, j), and for a dimension-3 - dataset with indices (nP, i, j, k) will be an array with indices - (i, j, k). - - The :ref:`order ` of indices (i, j - or i, j, k) is slow to fast. - data_size(NX_INT): - doc: | - Two or three values for the size of the module in pixels in - each direction. Dimensionality and order of indices is the - same as for data_origin. - data_stride(NX_INT): - exists: ['min', '0'] - doc: | - Two or three values for the stride of the module in pixels in - each direction. By default the stride is [1,1] or [1,1,1], - and this is the most likely case. This optional field is - included for completeness. - module_offset(NX_NUMBER): - unit: NX_LENGTH - exists: ['min', '0'] - doc: | - Offset of the module in regards to the origin of the detector in an - arbitrary direction. - \@transformation_type: - enumeration: [translation] - \@vector: - type: NX_NUMBER - \@offset: - type: NX_NUMBER - \@depends_on: - fast_pixel_direction(NX_NUMBER): - unit: NX_LENGTH - doc: | - Values along the direction of :ref:`fastest varying ` - pixel direction. The direction itself is given through the vector - attribute. - \@transformation_type: - enumeration: [translation] - \@vector: - type: NX_NUMBER - \@offset: - type: NX_NUMBER - \@depends_on: - slow_pixel_direction(NX_NUMBER): - unit: NX_LENGTH - doc: | - Values along the direction of :ref:`slowest varying ` - pixel direction. The direction itself is given through the vector - attribute. - \@transformation_type: - enumeration: [translation] - \@vector: - type: NX_NUMBER - \@offset: - type: NX_NUMBER - \@depends_on: - distance(NX_FLOAT): - unit: NX_LENGTH - exists: recommended - doc: | - Distance from the sample to the beam center. - Normally this value is for guidance only, the proper - geometry can be found following the depends_on axis chain, - But in appropriate cases where the dectector distance - to the sample is observable independent of the axis - chain, that may take precedence over the axis chain - calculation. - distance_derived(NX_BOOLEAN): - exists: recommended - doc: | - Boolean to indicate if the distance is a derived, rather than - a primary observation. If distance_derived true or is not specified, - the distance is assumed to be derived from detector axis - specifications. - dead_time(NX_FLOAT): - unit: NX_TIME - exists: ['min', '0'] - doc: | - Detector dead time. - count_time(NX_NUMBER): - unit: NX_TIME - exists: recommended - doc: | - Elapsed actual counting time. - beam_center_derived(NX_BOOLEAN): - exists: optional - doc: | - Boolean to indicate if the distance is a derived, rather than - a primary observation. If true or not provided, that value of - beam_center_derived is assumed to be true. - beam_center_x(NX_FLOAT): - unit: NX_LENGTH - exists: recommended - doc: | - This is the x position where the direct beam would hit the - detector. This is a length and can be outside of the actual - detector. The length can be in physical units or pixels as - documented by the units attribute. Normally, this should - be derived from the axis chain, but the direct specification - may take precedence if it is not a derived quantity. - beam_center_y(NX_FLOAT): - unit: NX_LENGTH - exists: recommended - doc: | - This is the y position where the direct beam would hit the - detector. This is a length and can be outside of the actual - detector. The length can be in physical units or pixels as - documented by the units attribute. Normally, this should - be derived from the axis chain, but the direct specification - may take precedence if it is not a derived quantity. - angular_calibration_applied(NX_BOOLEAN): - exists: ['min', '0'] - doc: | - True when the angular calibration has been applied in the - electronics, false otherwise. - angular_calibration(NX_FLOAT): - exists: ['min', '0'] - doc: | - Angular calibration data. - dimensions: - rank: dataRank - dim: [[1, i], [2, j], [3, k]] - dim_parameters: - required: ['false'] - flatfield_applied(NX_BOOLEAN): - exists: ['min', '0'] - doc: | - True when the flat field correction has been applied in the - electronics, false otherwise. - flatfield(NX_NUMBER): - exists: ['min', '0'] - doc: | - Flat field correction data. If provided, it is recommended - that it be compressed. - dimensions: - rank: dataRank - dim: [[1, i], [2, j], [3, k]] - dim_parameters: - required: ['false'] - flatfield_error(NX_NUMBER): - exists: ['min', '0', 'max', '0'] - doc: | - *** Deprecated form. Use plural form *** - Errors of the flat field correction data. If provided, it is recommended - that it be compressed. - dimensions: - rank: dataRank - dim: [[1, i], [2, j], [3, k]] - dim_parameters: - required: ['false'] - flatfield_errors(NX_NUMBER): - exists: ['min', '0'] - doc: | - Errors of the flat field correction data. If provided, it is recommended - that it be compressed. - dimensions: - rank: dataRank - dim: [[1, i], [2, j], [3, k]] - dim_parameters: - required: ['false'] - pixel_mask_applied(NX_BOOLEAN): - exists: ['min', '0'] - doc: | - True when the pixel mask correction has been applied in the - electronics, false otherwise. - pixel_mask(NX_INT): - exists: recommended - doc: | - The 32-bit pixel mask for the detector. Can be either one mask - for the whole dataset (i.e. an array with indices i, j) or - each frame can have its own mask (in which case it would be - an array with indices nP, i, j). - - Contains a bit field for each pixel to signal dead, - blind, high or otherwise unwanted or undesirable pixels. - They have the following meaning: - - * bit 0: gap (pixel with no sensor) - * bit 1: dead - * bit 2: under-responding - * bit 3: over-responding - * bit 4: noisy - * bit 5: -undefined- - * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) - * bit 7: -undefined- - * bit 8: user defined mask (e.g. around beamstop) - * bits 9-30: -undefined- - * bit 31: virtual pixel (corner pixel with interpolated value) - - Normal data analysis software would not take pixels into account - when a bit in (mask & 0x0000FFFF) is set. Tag bit in the upper - two bytes would indicate special pixel properties that normally - would not be a sole reason to reject the intensity value (unless - lower bits are set. - - If the full bit depths is not required, providing a - mask with fewer bits is permissible. - - If needed, additional pixel masks can be specified by - including additional entries named pixel_mask_N, where - N is an integer. For example, a general bad pixel mask - could be specified in pixel_mask that indicates noisy - and dead pixels, and an additional pixel mask from - experiment-specific shadowing could be specified in - pixel_mask_2. The cumulative mask is the bitwise OR - of pixel_mask and any pixel_mask_N entries. - - If provided, it is recommended that it be compressed. - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - countrate_correction_applied(NX_BOOLEAN): - exists: ['min', '0'] - doc: | - Counting detectors usually are not able to measure all incoming particles, - especially at higher count-rates. Count-rate correction is applied to - account for these errors. - - True when count-rate correction has been applied, false otherwise. - countrate_correction_lookup_table(NX_NUMBER): - exists: optional - doc: | - The countrate_correction_lookup_table defines the LUT used for count-rate - correction. It maps a measured count :math:`c` to its corrected value - :math:`countrate\_correction\_lookup\_table[c]`. - - :math:`m` denotes the length of the table. - dimensions: - rank: 1 - dim: [[1, m]] - virtual_pixel_interpolation_applied(NX_BOOLEAN): - exists: ['min', '0'] - doc: | - True when virtual pixel interpolation has been applied, false otherwise. - - When virtual pixel interpolation is applied, values of some pixels may - contain interpolated values. For example, to account for space between - readout chips on a module, physical pixels on edges and corners between - chips may have larger sensor areas and counts may be distributed between - their logical pixels. - bit_depth_readout(NX_INT): - exists: recommended - doc: | - How many bits the electronics record per pixel. - detector_readout_time(NX_FLOAT): - unit: NX_TIME - exists: ['min', '0'] - doc: | - Time it takes to read the detector (typically milliseconds). - This is important to know for time resolved experiments. - frame_time(NX_FLOAT): - unit: NX_TIME - exists: ['min', '0'] - doc: | - This is time for each frame. This is exposure_time + readout - time. - gain_setting(NX_CHAR): - exists: ['min', '0'] - doc: | - The gain setting of the detector. This influences - background. This is a detector-specific value meant - to document the gain setting of the detector during - data collection, for detectors with multiple - available gain settings. - - Examples of gain settings include: - - * ``standard`` - * ``fast`` - * ``auto`` - * ``high`` - * ``medium`` - * ``low`` - * ``mixed high to medium`` - * ``mixed medium to low`` - - Developers are encouraged to use one of these terms, or to submit - additional terms to add to the list. - saturation_value(NX_NUMBER): - exists: ['min', '0'] - doc: | - The value at which the detector goes into saturation. - Data above this value is known to be invalid. - - For example, given a saturation_value and an underload_value, - the valid pixels are those less than or equal to the - saturation_value and greater than or equal to the underload_value. - underload_value(NX_NUMBER): - exists: ['min', '0'] - doc: | - The lowest value at which pixels for this detector - would be reasonably be measured. - - For example, given a saturation_value and an underload_value, - the valid pixels are those less than or equal to the - saturation_value and greater than or equal to the underload_value. - sensor_material(NX_CHAR): - exists: ['min', '1'] - doc: | - At times, radiation is not directly sensed by the detector. - Rather, the detector might sense the output from some - converter like a scintillator. - This is the name of this converter material. - sensor_thickness(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '1'] - doc: | - At times, radiation is not directly sensed by the detector. - Rather, the detector might sense the output from some - converter like a scintillator. This is the thickness of this - converter material. - threshold_energy(NX_FLOAT): - unit: NX_ENERGY - exists: ['min', '0'] - doc: | - Single photon counter detectors can be adjusted for a certain - energy range in which they work optimally. This is the energy - setting for this. If the detector supports multiple thresholds, - this is an array. - type: - exists: ['min', '0'] - doc: | - Description of type such as scintillator, - ccd, pixel, image - plate, CMOS, ... - CHANNELNAME_channel(NXdetector_channel): - doc: | - Group containing the description and metadata for a single channel from a multi-channel - detector. - - Given an :ref:`NXdata` group linked as part of an NXdetector group that has an axis with - named channels (see the example in :ref:`NXdata `), - the NXdetector will have a series of NXdetector_channel groups, one for each channel, - named CHANNELNAME_channel. - (NXbeam): - exists: ['min', '1'] - \@flux: - exists: optional - doc: | - Which field contains the measured flux. One of ``flux``, - ``total_flux``, ``flux_integrated``, or ``total_flux_integrated``. - - Alternatively, the name being indicated could be a link - to a dataset in an NXmonitor group that records per shot beam data. - incident_wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - exists: ['min', '1'] - doc: | - In the case of a monchromatic 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. - incident_wavelength_weight(NX_FLOAT): - exists: ['min', '0'] - deprecated: | - use incident_wavelength_weights, see https://github.com/nexusformat/definitions/issues/837 - doc: | - In the case of a polychromatic beam this is an array of - length **m** of the relative weights of the corresponding - wavelengths in incident_wavelength. - - In the case of a polychromatic beam that varies shot-to- - shot, this is a 2D array of dimensions **nP** by **m** - (slow to fast) of the relative weights of the - corresponding wavelengths in incident_wavelength. - incident_wavelength_weights(NX_FLOAT): - exists: ['min', '0'] - doc: | - In the case of a polychromatic beam this is an array of - length **m** of the relative weights of the corresponding - wavelengths in ``incident_wavelength``. - - In the case of a polychromatic beam that varies shot-to- - shot, this is a 2D array of dimensions **np** by **m** - (slow to fast) of the relative weights of the - corresponding wavelengths in ``incident_wavelength``. - incident_wavelength_spread(NX_FLOAT): - unit: NX_WAVELENGTH - exists: ['min', '0'] - doc: | - The wavelength spread FWHM for the corresponding - wavelength(s) in incident_wavelength. - - In the case of shot-to-shot variation in the wavelength - spread, this is a 2D array of dimension **nP** by - **m** (slow to fast) of the spreads of the - corresponding wavelengths in incident_wavelength. - incident_wavelength_spectrum(NXdata): - exists: ['min', '0'] - doc: | - This group is intended for use cases that do not fit the - :ref:`incident_wavelength ` - and - :ref:`incident_wavelength_weights ` - fields above, perhaps for example a 2D spectrometer. - flux(NX_FLOAT): - unit: NX_FLUX - exists: ['min', '0'] - doc: | - Flux density incident on beam plane area in photons - per second per unit area. - - In the case of a beam that varies in flux shot-to-shot, - this is an array of values, one for each recorded shot. - total_flux(NX_FLOAT): - unit: NX_FREQUENCY - exists: ['min', '0'] - doc: | - Flux incident on beam plane in photons per second. In other words - this is the :ref:`flux ` integrated - over area. - - Useful where spatial beam profiles are not known. - - In the case of a beam that varies in total flux shot-to-shot, - this is an array of values, one for each recorded shot. - flux_integrated(NX_FLOAT): - unit: NX_PER_AREA - exists: ['min', '0'] - doc: | - Flux density incident on beam plane area in photons - per unit area. In other words this is the :ref:`flux ` - integrated over time. - - Useful where temporal beam profiles of flux are not known. - - In the case of a beam that varies in flux shot-to-shot, - this is an array of values, one for each recorded shot. - total_flux_integrated(NX_FLOAT): - unit: NX_DIMENSIONLESS - exists: ['min', '0'] - doc: | - Flux incident on beam plane in photons. In other words this is the :ref:`flux ` - integrated over time and area. - - Useful where temporal beam profiles of flux are not known. - - In the case of a beam that varies in total flux shot-to-shot, - this is an array of values, one for each recorded shot. - incident_beam_size(NX_FLOAT): - unit: NX_LENGTH - exists: recommended - doc: | - Two-element array of FWHM (if Gaussian or Airy function) or - diameters (if top hat) or widths (if rectangular) of the beam - in the order x, y - dimensions: - rank: 1 - dim: [[1, 2]] - profile(NX_CHAR): - exists: recommended - doc: | - The beam profile, Gaussian, Airy function, top-hat or - rectangular. The profile is given in the plane of - incidence of the beam on the sample. - enumeration: [Gaussian, Airy, top-hat, rectangular] - incident_polarisation_stokes(NX_NUMBER): - exists: optional - deprecated: | - use incident_polarization_stokes, see https://github.com/nexusformat/definitions/issues/708 - doc: | - Polarization vector on entering beamline - component using Stokes notation - dimensions: - rank: 2 - dim: [[1, nP], [2, 4]] - incident_polarization_stokes(NX_NUMBER): - exists: recommended - doc: | - Polarization vector on entering beamline - component using Stokes notation. See - incident_polarization_stokes in :ref:`NXbeam` - dimensions: - rank: 2 - dim: [[1, nP], [2, 4]] - (NXsource): - doc: | - The neutron or x-ray storage ring/facility. Note, the NXsource base class - has many more fields available, but at present we only require the name. - name: - exists: ['min', '1'] - doc: | - Name of source. Consistency with the naming in - https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.pdbx_synchrotron_site.html - controlled vocabulary is highly recommended. - \@short_name: - exists: optional - doc: | - short name for source, perhaps the acronym - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 5e1a3097a35a31b52f88eba111c3dd9d58b2a605c23f196103d741cab402f112 -# -# -# -# -# -# -# -# These symbols will be used below to coordinate datasets -# with the same shape. Most MX x-ray detectors will produce -# two-dimensional images. Some will produce three-dimensional -# images, using one of the indices to select a detector module. -# -# -# Rank of the ``data`` field -# -# -# Number of scan points -# -# -# Number of detector pixels in the slowest direction -# -# -# Number of detector pixels in the second slowest direction -# -# -# Number of detector pixels in the third slowest direction -# -# -# Number of channels in the incident beam spectrum, if known -# -# -# -# An array of the hierarchical levels of the parents of detector -# elements or groupings of detector elements. -# A top-level element or grouping has parent level -1. -# -# -# -# -# -# functional application definition for macromolecular crystallography -# -# -# -# -# -# Note, it is recommended that ``file_name`` and ``file_time`` are included -# as attributes at the root of a file that includes :ref:`NXmx`. See -# :ref:`NXroot`. -# -# -# -# -# Describes the version of the NXmx definition used to write this data. -# This must be a text (not numerical) representation. Such as:: -# -# @version="1.0" -# -# -# -# -# -# -# -# -# -# -# ISO 8601 time/date of the first data point collected in UTC, -# using the Z suffix to avoid confusion with local time. -# Note that the time zone of the beamline should be provided in -# NXentry/NXinstrument/time_zone. -# -# -# -# -# -# ISO 8601 time/date of the last data point collected in UTC, -# using the Z suffix to avoid confusion with local time. -# Note that the time zone of the beamline should be provided in -# NXentry/NXinstrument/time_zone. This field should only be -# filled when the value is accurately observed. If the data -# collection aborts or otherwise prevents accurate recording of -# the end_time, this field should be omitted. -# -# -# -# -# -# ISO 8601 time/date of the last data point collected in UTC, -# using the Z suffix to avoid confusion with local time. -# Note that the time zone of the beamline should be provided in -# NXentry/NXinstrument/time_zone. This field may be filled -# with a value estimated before an observed value is available. -# -# -# -# -# NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# -# For a dimension-2 detector, the rank of the data array will be 3. -# For a dimension-3 detector, the rank of the data array will be 4. -# This allows for the introduction of the frame number as the -# first index. -# -# -# -# -# -# -# -# -# -# -# -# An optional scaling factor to apply to the values in ``data``. -# -# The elements in ``data`` are often stored as integers for efficiency reasons and need -# further correction, generating floats. The two fields data_scaling_factor and -# data_offset allow linear corrections using the following convention: -# -# .. code-block:: -# -# corrected_data = (data + offset) * scaling_factor -# -# This formula will derive the corrected value, when necessary. -# -# data_scaling_factor is sometimes known as gain and data_offset is sometimes -# known as pedestal or background, depending on the community. -# -# Use these fields to specify constants that need to be applied -# to the data to correct it to physical values. For example, if the detector gain -# is 10 counts per photon and a constant background of 400 needs to be subtracted -# off the pixels, specify data_scaling_factor as 0.1 and data_offset as -400 to -# specify the required conversion from raw counts to corrected photons. It -# is implied processing software will apply these corrections on-the-fly during processing. -# -# The rank of these fields should either be a single value for the full dataset, a -# single per-pixel array applied to every image (dimensions (i, j) or (i, j, k)), -# or a per-image correction specified with an array whose slowest rank is nP (dimensions -# (np, 1), (np, i, j) or (np, i, j, k)). -# -# When omitted, the scaling factor is assumed to be 1. -# -# -# -# -# An optional offset to apply to the values in data. -# -# When omitted, the offset is assumed to be 0. -# -# See :ref:`data_scaling_factor </NXmx/ENTRY/DATA/data_scaling_factor-field>` for more information. -# -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# -# -# This is a requirement to describe for any scan experiment. -# -# The axis on which the sample position depends may be stored -# anywhere, but is normally stored in the NXtransformations -# group within the NXsample group. -# -# If there is no goniometer, e.g. with a jet, depends_on -# should be set to "." -# -# -# -# -# -# This is the recommended location for sample goniometer -# and other related axes. -# -# This is a requirement to describe for any scan experiment. -# The reason it is optional is mainly to accommodate XFEL -# single shot exposures. -# -# Use of the depends_on field and the NXtransformations group is -# strongly recommended. As noted above this should be an absolute -# requirement to have for any scan experiment. -# -# The reason it is optional is mainly to accommodate XFEL -# single shot exposures. -# -# -# -# -# -# -# -# -# -# -# -# -# Name of instrument. Consistency with the controlled -# vocabulary beamline naming in -# https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.pdbx_synchrotron_beamline.html -# and -# https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.type.html -# is highly recommended. -# -# -# Short name for instrument, perhaps the acronym. -# -# -# -# -# -# ISO 8601 time_zone offset from UTC. -# -# -# -# -# -# -# -# -# -# Optional logical grouping of detectors. -# -# Each detector is represented as an NXdetector -# with its own detector data array. Each detector data array -# may be further decomposed into array sections by use of -# NXdetector_module groups. Detectors can be grouped logically -# together using NXdetector_group. Groups can be further grouped -# hierarchically in a single NXdetector_group (for example, if -# there are multiple detectors at an endstation or multiple -# endstations at a facility). Alternatively, multiple -# NXdetector_groups can be provided. -# -# The groups are defined hierarchically, with names given -# in the group_names field, unique identifying indices given -# in the field group_index, and the level in the hierarchy -# given in the group_parent field. For example if an x-ray -# detector group, DET, consists of four detectors in a -# rectangular array:: -# -# DTL DTR -# DLL DLR -# -# We could have:: -# -# group_names: ["DET", "DTL", "DTR", "DLL", "DLR"] -# group_index: [1, 2, 3, 4, 5] -# group_parent: [-1, 1, 1, 1, 1] -# -# -# -# -# -# An array of the names of the detectors or the names of -# hierarchical groupings of detectors. -# -# -# -# -# -# An array of unique identifiers for detectors or groupings -# of detectors. -# -# Each ID is a unique ID for the corresponding detector or group -# named in the field group_names. The IDs are positive integers -# starting with 1. -# -# -# -# -# -# -# An array of the hierarchical levels of the parents of detectors -# or groupings of detectors. -# -# A top-level grouping has parent level -1. -# -# -# -# -# -# -# Normally the detector group will have the name ``detector``. -# However, in the case of multiple detectors, each detector -# needs a uniquely named NXdetector. -# -# -# -# -# NeXus path to the detector positioner axis that most directly -# supports the detector. In the case of a single-module -# detector, the detector axis chain may start here. -# -# -# -# -# -# Location for axes (transformations) to do with the -# detector. In the case of a single-module detector, the -# axes of the detector axis chain may be stored here. -# -# -# -# -# -# Suggested container for detailed non-standard detector -# information like corrections applied automatically or -# performance settings. -# -# -# -# -# -# For a dimension-2 detector, the rank of the data array will be 3. -# For a dimension-3 detector, the rank of the data array will be 4. -# This allows for the introduction of the frame number as the -# first index. -# -# -# -# -# -# -# -# -# -# -# -# name/manufacturer/model/etc. information. -# -# -# -# -# -# For a time-of-flight detector this is the scaling -# factor to convert from the numeric value reported to -# the flight time for a given measurement. -# -# -# -# -# -# Many detectors consist of multiple smaller modules that are -# operated in sync and store their data in a common dataset. -# To allow consistent parsing of the experimental geometry, -# this application definiton requires all detectors to -# define a detector module, even if there is only one. -# -# This group specifies the hyperslab of data in the data -# array associated with the detector that contains the -# data for this module. If the module is associated with -# a full data array, rather than with a hyperslab within -# a larger array, then a single module should be defined, -# spanning the entire array. -# -# Note, the pixel size is given as values in the array -# fast_pixel_direction and slow_pixel_direction. -# -# -# -# A dimension-2 or dimension-3 field which gives the indices -# of the origin of the hyperslab of data for this module in the -# main area detector image in the parent NXdetector module. -# -# The data_origin is 0-based. -# -# The frame number dimension (nP) is omitted. Thus the -# data_origin field for a dimension-2 dataset with indices (nP, i, j) -# will be an array with indices (i, j), and for a dimension-3 -# dataset with indices (nP, i, j, k) will be an array with indices -# (i, j, k). -# -# The :ref:`order <Design-ArrayStorageOrder>` of indices (i, j -# or i, j, k) is slow to fast. -# -# -# -# -# Two or three values for the size of the module in pixels in -# each direction. Dimensionality and order of indices is the -# same as for data_origin. -# -# -# -# -# Two or three values for the stride of the module in pixels in -# each direction. By default the stride is [1,1] or [1,1,1], -# and this is the most likely case. This optional field is -# included for completeness. -# -# -# -# -# -# Offset of the module in regards to the origin of the detector in an -# arbitrary direction. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Values along the direction of :ref:`fastest varying <Design-ArrayStorageOrder>` -# pixel direction. The direction itself is given through the vector -# attribute. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Values along the direction of :ref:`slowest varying <Design-ArrayStorageOrder>` -# pixel direction. The direction itself is given through the vector -# attribute. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Distance from the sample to the beam center. -# Normally this value is for guidance only, the proper -# geometry can be found following the depends_on axis chain, -# But in appropriate cases where the dectector distance -# to the sample is observable independent of the axis -# chain, that may take precedence over the axis chain -# calculation. -# -# -# -# -# -# Boolean to indicate if the distance is a derived, rather than -# a primary observation. If distance_derived true or is not specified, -# the distance is assumed to be derived from detector axis -# specifications. -# -# -# -# -# -# Detector dead time. -# -# -# -# -# -# Elapsed actual counting time. -# -# -# -# -# -# Boolean to indicate if the distance is a derived, rather than -# a primary observation. If true or not provided, that value of -# beam_center_derived is assumed to be true. -# -# -# -# -# -# -# -# This is the x position where the direct beam would hit the -# detector. This is a length and can be outside of the actual -# detector. The length can be in physical units or pixels as -# documented by the units attribute. Normally, this should -# be derived from the axis chain, but the direct specification -# may take precedence if it is not a derived quantity. -# -# -# -# -# -# This is the y position where the direct beam would hit the -# detector. This is a length and can be outside of the actual -# detector. The length can be in physical units or pixels as -# documented by the units attribute. Normally, this should -# be derived from the axis chain, but the direct specification -# may take precedence if it is not a derived quantity. -# -# -# -# -# -# True when the angular calibration has been applied in the -# electronics, false otherwise. -# -# -# -# -# Angular calibration data. -# -# -# -# -# -# -# -# -# -# True when the flat field correction has been applied in the -# electronics, false otherwise. -# -# -# -# -# -# Flat field correction data. If provided, it is recommended -# that it be compressed. -# -# -# -# -# -# -# -# -# -# -# -# *** Deprecated form. Use plural form *** -# Errors of the flat field correction data. If provided, it is recommended -# that it be compressed. -# -# -# -# -# -# -# -# -# -# -# Errors of the flat field correction data. If provided, it is recommended -# that it be compressed. -# -# -# -# -# -# -# -# -# -# -# True when the pixel mask correction has been applied in the -# electronics, false otherwise. -# -# -# -# -# -# The 32-bit pixel mask for the detector. Can be either one mask -# for the whole dataset (i.e. an array with indices i, j) or -# each frame can have its own mask (in which case it would be -# an array with indices nP, i, j). -# -# Contains a bit field for each pixel to signal dead, -# blind, high or otherwise unwanted or undesirable pixels. -# They have the following meaning: -# -# * bit 0: gap (pixel with no sensor) -# * bit 1: dead -# * bit 2: under-responding -# * bit 3: over-responding -# * bit 4: noisy -# * bit 5: -undefined- -# * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) -# * bit 7: -undefined- -# * bit 8: user defined mask (e.g. around beamstop) -# * bits 9-30: -undefined- -# * bit 31: virtual pixel (corner pixel with interpolated value) -# -# Normal data analysis software would not take pixels into account -# when a bit in (mask & 0x0000FFFF) is set. Tag bit in the upper -# two bytes would indicate special pixel properties that normally -# would not be a sole reason to reject the intensity value (unless -# lower bits are set. -# -# If the full bit depths is not required, providing a -# mask with fewer bits is permissible. -# -# If needed, additional pixel masks can be specified by -# including additional entries named pixel_mask_N, where -# N is an integer. For example, a general bad pixel mask -# could be specified in pixel_mask that indicates noisy -# and dead pixels, and an additional pixel mask from -# experiment-specific shadowing could be specified in -# pixel_mask_2. The cumulative mask is the bitwise OR -# of pixel_mask and any pixel_mask_N entries. -# -# If provided, it is recommended that it be compressed. -# -# -# -# -# -# -# -# -# Counting detectors usually are not able to measure all incoming particles, -# especially at higher count-rates. Count-rate correction is applied to -# account for these errors. -# -# True when count-rate correction has been applied, false otherwise. -# -# -# -# -# The countrate_correction_lookup_table defines the LUT used for count-rate -# correction. It maps a measured count :math:`c` to its corrected value -# :math:`countrate\_correction\_lookup\_table[c]`. -# -# :math:`m` denotes the length of the table. -# -# -# -# -# -# -# -# True when virtual pixel interpolation has been applied, false otherwise. -# -# When virtual pixel interpolation is applied, values of some pixels may -# contain interpolated values. For example, to account for space between -# readout chips on a module, physical pixels on edges and corners between -# chips may have larger sensor areas and counts may be distributed between -# their logical pixels. -# -# -# -# -# -# How many bits the electronics record per pixel. -# -# -# -# -# -# Time it takes to read the detector (typically milliseconds). -# This is important to know for time resolved experiments. -# -# -# -# -# -# This is time for each frame. This is exposure_time + readout -# time. -# -# -# -# -# -# The gain setting of the detector. This influences -# background. This is a detector-specific value meant -# to document the gain setting of the detector during -# data collection, for detectors with multiple -# available gain settings. -# -# Examples of gain settings include: -# -# * ``standard`` -# * ``fast`` -# * ``auto`` -# * ``high`` -# * ``medium`` -# * ``low`` -# * ``mixed high to medium`` -# * ``mixed medium to low`` -# -# Developers are encouraged to use one of these terms, or to submit -# additional terms to add to the list. -# -# -# -# -# -# The value at which the detector goes into saturation. -# Data above this value is known to be invalid. -# -# For example, given a saturation_value and an underload_value, -# the valid pixels are those less than or equal to the -# saturation_value and greater than or equal to the underload_value. -# -# -# -# -# -# The lowest value at which pixels for this detector -# would be reasonably be measured. -# -# For example, given a saturation_value and an underload_value, -# the valid pixels are those less than or equal to the -# saturation_value and greater than or equal to the underload_value. -# -# -# -# -# -# At times, radiation is not directly sensed by the detector. -# Rather, the detector might sense the output from some -# converter like a scintillator. -# This is the name of this converter material. -# -# -# -# -# -# At times, radiation is not directly sensed by the detector. -# Rather, the detector might sense the output from some -# converter like a scintillator. This is the thickness of this -# converter material. -# -# -# -# -# -# Single photon counter detectors can be adjusted for a certain -# energy range in which they work optimally. This is the energy -# setting for this. If the detector supports multiple thresholds, -# this is an array. -# -# -# -# -# -# Description of type such as scintillator, -# ccd, pixel, image -# plate, CMOS, ... -# -# -# -# -# -# Group containing the description and metadata for a single channel from a multi-channel -# detector. -# -# Given an :ref:`NXdata` group linked as part of an NXdetector group that has an axis with -# named channels (see the example in :ref:`NXdata </NXdata@default_slice-attribute>`), -# the NXdetector will have a series of NXdetector_channel groups, one for each channel, -# named CHANNELNAME_channel. -# -# -# -# -# -# -# -# Which field contains the measured flux. One of ``flux``, -# ``total_flux``, ``flux_integrated``, or ``total_flux_integrated``. -# -# Alternatively, the name being indicated could be a link -# to a dataset in an NXmonitor group that records per shot beam data. -# -# -# -# -# In the case of a monchromatic 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 <Design-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. -# -# -# -# -# -# In the case of a polychromatic beam this is an array of -# length **m** of the relative weights of the corresponding -# wavelengths in incident_wavelength. -# -# In the case of a polychromatic beam that varies shot-to- -# shot, this is a 2D array of dimensions **nP** by **m** -# (slow to fast) of the relative weights of the -# corresponding wavelengths in incident_wavelength. -# -# -# -# -# In the case of a polychromatic beam this is an array of -# length **m** of the relative weights of the corresponding -# wavelengths in ``incident_wavelength``. -# -# In the case of a polychromatic beam that varies shot-to- -# shot, this is a 2D array of dimensions **np** by **m** -# (slow to fast) of the relative weights of the -# corresponding wavelengths in ``incident_wavelength``. -# -# -# -# -# -# The wavelength spread FWHM for the corresponding -# wavelength(s) in incident_wavelength. -# -# In the case of shot-to-shot variation in the wavelength -# spread, this is a 2D array of dimension **nP** by -# **m** (slow to fast) of the spreads of the -# corresponding wavelengths in incident_wavelength. -# -# -# -# -# -# This group is intended for use cases that do not fit the -# :ref:`incident_wavelength </NXmx/ENTRY/INSTRUMENT/BEAM/incident_wavelength-field>` -# and -# :ref:`incident_wavelength_weights </NXmx/ENTRY/INSTRUMENT/BEAM/incident_wavelength_weights-field>` -# fields above, perhaps for example a 2D spectrometer. -# -# -# -# -# -# Flux density incident on beam plane area in photons -# per second per unit area. -# -# In the case of a beam that varies in flux shot-to-shot, -# this is an array of values, one for each recorded shot. -# -# -# -# -# -# Flux incident on beam plane in photons per second. In other words -# this is the :ref:`flux </NXmx/ENTRY/INSTRUMENT/BEAM/flux-field>` integrated -# over area. -# -# Useful where spatial beam profiles are not known. -# -# In the case of a beam that varies in total flux shot-to-shot, -# this is an array of values, one for each recorded shot. -# -# -# -# -# -# Flux density incident on beam plane area in photons -# per unit area. In other words this is the :ref:`flux </NXmx/ENTRY/INSTRUMENT/BEAM/flux-field>` -# integrated over time. -# -# Useful where temporal beam profiles of flux are not known. -# -# In the case of a beam that varies in flux shot-to-shot, -# this is an array of values, one for each recorded shot. -# -# -# -# -# -# Flux incident on beam plane in photons. In other words this is the :ref:`flux </NXmx/ENTRY/INSTRUMENT/BEAM/flux-field>` -# integrated over time and area. -# -# Useful where temporal beam profiles of flux are not known. -# -# In the case of a beam that varies in total flux shot-to-shot, -# this is an array of values, one for each recorded shot. -# -# -# -# -# -# Two-element array of FWHM (if Gaussian or Airy function) or -# diameters (if top hat) or widths (if rectangular) of the beam -# in the order x, y -# -# -# -# -# -# -# -# -# The beam profile, Gaussian, Airy function, top-hat or -# rectangular. The profile is given in the plane of -# incidence of the beam on the sample. -# -# -# -# -# -# -# -# -# -# -# Polarization vector on entering beamline -# component using Stokes notation -# -# -# -# -# -# -# -# -# Polarization vector on entering beamline -# component using Stokes notation. See -# incident_polarization_stokes in :ref:`NXbeam` -# -# -# -# -# -# -# -# -# -# -# The neutron or x-ray storage ring/facility. Note, the NXsource base class -# has many more fields available, but at present we only require the name. -# -# -# -# Name of source. Consistency with the naming in -# https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.pdbx_synchrotron_site.html -# controlled vocabulary is highly recommended. -# -# -# short name for source, perhaps the acronym -# -# -# -# -# diff --git a/applications/nyaml/NXrefscan.yaml b/applications/nyaml/NXrefscan.yaml deleted file mode 100644 index 23f3d20471..0000000000 --- a/applications/nyaml/NXrefscan.yaml +++ /dev/null @@ -1,197 +0,0 @@ -category: application -doc: | - This is an application definition for a monochromatic scanning reflectometer. - - It does not have the information to calculate the resolution - since it does not have any apertures. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points -type: group -NXrefscan(NXobject): - (NXentry)entry: - title: - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXrefscan] - (NXinstrument)instrument: - (NXsource): - type: - name: - probe: - enumeration: [neutron, x-ray, electron] - (NXmonochromator)monochromator: - wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - (NXdetector): - data(NX_INT): - signal: 1 - dimensions: - rank: 1 - dim: [[1, nP]] - polar_angle(NX_FLOAT): - unit: NX_ANGLE - axis: 1 - dimensions: - rank: 1 - dim: [[1, nP]] - (NXsample)sample: - name: - doc: | - Descriptive name of sample - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - dimensions: - rank: 1 - dim: [[1, nP]] - (NXmonitor)control: - mode: - doc: | - Count to a preset value based on either clock time (timer) - or received monitor counts (monitor). - enumeration: [monitor, timer] - preset(NX_FLOAT): - doc: | - preset value for time or monitor - data(NX_FLOAT): - unit: NX_ANY - doc: | - Monitor counts for each step - dimensions: - rank: 1 - dim: [[1, nP]] - (NXdata)data: - data(link): - target: /NXentry/NXinstrument/NXdetector/data - rotation_angle(link): - target: /NXentry/NXsample/rotation_angle - polar_angle(link): - target: /NXentry/NXinstrument/NXdetector/polar_angle - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 24d31b361e857cc71d19cc8f0657060ba70e300114976d8f4552fce4e188f0e8 -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of points -# -# -# -# This is an application definition for a monochromatic scanning reflectometer. -# -# It does not have the information to calculate the resolution -# since it does not have any apertures. -# -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# -# -# -# -# -# -# -# Count to a preset value based on either clock time (timer) -# or received monitor counts (monitor). -# -# -# -# -# -# -# -# preset value for time or monitor -# -# -# Monitor counts for each step -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXreftof.yaml b/applications/nyaml/NXreftof.yaml deleted file mode 100644 index bcabd2abe4..0000000000 --- a/applications/nyaml/NXreftof.yaml +++ /dev/null @@ -1,214 +0,0 @@ -category: application -doc: | - This is an application definition for raw data from a TOF reflectometer. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - xSize: | - xSize description - ySize: | - ySize description - nTOF: | - nTOF description -type: group -NXreftof(NXobject): - (NXentry)entry: - title: - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXreftof] - (NXinstrument)instrument: - name(NX_CHAR): - (NXdisk_chopper)chopper: - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Distance between chopper and sample - (NXdetector)detector: - data(NX_INT): - signal: 1 - dimensions: - rank: 3 - dim: [[1, xSize], [2, ySize], [3, nTOF]] - time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - axis: 3 - doc: | - Array of time values for each bin in a time-of-flight - measurement - dimensions: - rank: 1 - dim: [[1, nTOF]] - distance(NX_FLOAT): - unit: NX_LENGTH - polar_angle(NX_FLOAT): - unit: NX_ANGLE - x_pixel_size(NX_FLOAT): - unit: NX_LENGTH - y_pixel_size(NX_FLOAT): - unit: NX_LENGTH - (NXsample)sample: - name: - doc: | - Descriptive name of sample - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - (NXmonitor)control: - mode: - doc: | - Count to a preset value based on either clock time (timer) - or received monitor counts (monitor). - enumeration: [monitor, timer] - preset(NX_FLOAT): - unit: NX_ANY - doc: | - preset value for time or monitor - integral(NX_INT): - doc: | - Total integral monitor counts - time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - axis: 1 - doc: | - Time channels - data(NX_INT): - signal: 1 - doc: | - Monitor counts in each time channel - (NXdata)data: - data(link): - target: /NXentry/NXinstrument/NXdetector/data - time_of_flight(link): - target: /NXentry/NXinstrument/NXdetector/time_of_flight - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# c214b3fa3b858a7f7318f33eee4999b2493c930eb1b7684023725fd21e948ac7 -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# xSize description -# -# -# ySize description -# -# -# nTOF description -# -# -# This is an application definition for raw data from a TOF reflectometer. -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# Distance between chopper and sample -# -# -# -# -# -# -# -# -# -# -# -# -# Array of time values for each bin in a time-of-flight -# measurement -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# -# -# -# Count to a preset value based on either clock time (timer) -# or received monitor counts (monitor). -# -# -# -# -# -# -# -# preset value for time or monitor -# -# -# Total integral monitor counts -# -# -# Time channels -# -# -# Monitor counts in each time channel -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXsas.yaml b/applications/nyaml/NXsas.yaml deleted file mode 100644 index 7f86c5607e..0000000000 --- a/applications/nyaml/NXsas.yaml +++ /dev/null @@ -1,369 +0,0 @@ -category: application -doc: | - Raw, monochromatic 2-D SAS data with an area detector. - - This is an application definition for raw data (not processed or reduced data) - from a 2-D small angle scattering instrument collected with a monochromatic - beam and an area detector. It is meant to be suitable both for neutron SANS - and X-ray SAXS data. - - It covers all raw data from any monochromatic SAS techniques that - use an area detector: SAS, WSAS, grazing incidence, GISAS - - It covers all raw data from any SAS techniques that use an area detector and - a monochromatic beam. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate fields with the same shape. - nXPixel: | - Number of pixels in x direction. - nYPixel: | - Number of pixels in y direction. -type: group -NXsas(NXobject): - (NXentry): - title: - exists: ['min', '0'] - start_time(NX_DATE_TIME): - exists: ['min', '0'] - end_time(NX_DATE_TIME): - exists: ['min', '0'] - definition: - doc: | - Official NeXus NXDL schema to which this file conforms. - enumeration: [NXsas] - (NXinstrument): - (NXsource): - type: - doc: | - Type of radiation source. - name: - exists: ['min', '0'] - doc: | - Name of the radiation source. - probe: - doc: | - Name of radiation probe, necessary to compute the sample contrast. - enumeration: [neutron, x-ray] - (NXmonochromator): - wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - The wavelength (:math:`\lambda`) of the radiation. - wavelength_spread(NX_FLOAT): - exists: ['min', '0'] - doc: | - delta_lambda/lambda (:math:`\Delta\lambda/\lambda`): - Important for resolution calculations. - (NXcollimator): - exists: ['min', '0'] - (NXgeometry): - (NXshape): - shape(NX_CHAR): - enumeration: [nxcylinder, nxbox] - size(NX_FLOAT): - unit: NX_LENGTH - doc: | - The collimation length. - (NXdetector): - data(NX_NUMBER): - doc: | - This is area detector data, number of x-pixel versus - number of y-pixels. - - Since the beam center is to be determined as a step of data - reduction, it is not necessary to document or assume the position of - the beam center in acquired data. - - It is necessary to define which are the x and y directions, to coordinate - with the pixel size and compute Q. - dimensions: - rank: 2 - dim: [[1, nXPixel], [2, nYPixel]] - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - The distance between detector and sample. - x_pixel_size(NX_FLOAT): - unit: NX_LENGTH - doc: | - Physical size of a pixel in x-direction. - y_pixel_size(NX_FLOAT): - unit: NX_LENGTH - doc: | - Physical size of a pixel in y-direction. - polar_angle(NX_FLOAT): - unit: NX_ANGLE - exists: ['min', '0'] - azimuthal_angle(NX_FLOAT): - unit: NX_ANGLE - exists: ['min', '0'] - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - exists: ['min', '0'] - aequatorial_angle(NX_FLOAT): - unit: NX_ANGLE - exists: ['min', '0'] - beam_center_x(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0'] - doc: | - This is the x position where the direct beam would hit the detector. - This is a length, not a pixel position, and can be outside of the - actual detector. - - It is expected that data reduction will determine beam center from - the raw data, thus it is not required here. The instrument can - provide an initial or nominal value to advise data reduction. - beam_center_y(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0'] - doc: | - This is the y position where the direct beam would hit the detector. - This is a length, not a pixel position, and can be outside of the - actual detector. - - It is expected that data reduction will determine beam center from - the raw data, thus it is not required here. The instrument can - provide an initial or nominal value to advise data reduction. - name(NX_CHAR): - doc: | - Name of the instrument actually used to perform the experiment. - (NXsample): - exists: ['min', '0'] - name: - doc: | - Descriptive name of sample. - aequatorial_angle(NX_FLOAT): - unit: NX_ANGLE - exists: ['min', '0'] - (NXmonitor): - exists: ['min', '0'] - mode: - doc: | - Count to a preset value based on either clock time - (timer) or received monitor counts (monitor). - enumeration: [monitor, timer] - preset(NX_FLOAT): - doc: | - Preset value for time or monitor. - integral(NX_FLOAT): - unit: NX_ANY - doc: | - Total integral monitor counts. - (NXdata): - \@signal: - exists: optional - doc: | - Name the *plottable* field. The link here defines this name as - ``data``. - enumeration: [data] - data(link): - target: /NXentry/NXinstrument/NXdetector/data - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# c0c74628efd981226d8bbf3bf83433a5e5e0971b60f6b7724543af3c0e3e9d58 -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate fields with the same shape. -# -# -# Number of pixels in x direction. -# -# -# Number of pixels in y direction. -# -# -# -# Raw, monochromatic 2-D SAS data with an area detector. -# -# This is an application definition for raw data (not processed or reduced data) -# from a 2-D small angle scattering instrument collected with a monochromatic -# beam and an area detector. It is meant to be suitable both for neutron SANS -# and X-ray SAXS data. -# -# It covers all raw data from any monochromatic SAS techniques that -# use an area detector: SAS, WSAS, grazing incidence, GISAS -# -# It covers all raw data from any SAS techniques that use an area detector and -# a monochromatic beam. -# -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms. -# -# -# -# -# -# -# -# Type of radiation source. -# -# -# Name of the radiation source. -# -# -# -# Name of radiation probe, necessary to compute the sample contrast. -# -# -# -# -# -# -# -# -# -# The wavelength (:math:`\lambda`) of the radiation. -# -# -# -# delta_lambda/lambda (:math:`\Delta\lambda/\lambda`): -# Important for resolution calculations. -# -# -# -# -# -# -# -# -# -# -# -# -# -# The collimation length. -# -# -# -# -# -# -# -# This is area detector data, number of x-pixel versus -# number of y-pixels. -# -# Since the beam center is to be determined as a step of data -# reduction, it is not necessary to document or assume the position of -# the beam center in acquired data. -# -# It is necessary to define which are the x and y directions, to coordinate -# with the pixel size and compute Q. -# -# -# -# -# -# -# -# The distance between detector and sample. -# -# -# Physical size of a pixel in x-direction. -# -# -# Physical size of a pixel in y-direction. -# -# -# -# -# -# -# -# This is the x position where the direct beam would hit the detector. -# This is a length, not a pixel position, and can be outside of the -# actual detector. -# -# It is expected that data reduction will determine beam center from -# the raw data, thus it is not required here. The instrument can -# provide an initial or nominal value to advise data reduction. -# -# -# -# -# This is the y position where the direct beam would hit the detector. -# This is a length, not a pixel position, and can be outside of the -# actual detector. -# -# It is expected that data reduction will determine beam center from -# the raw data, thus it is not required here. The instrument can -# provide an initial or nominal value to advise data reduction. -# -# -# -# -# Name of the instrument actually used to perform the experiment. -# -# -# -# -# Descriptive name of sample. -# -# -# -# -# -# -# Count to a preset value based on either clock time -# (timer) or received monitor counts (monitor). -# -# -# -# -# -# -# -# Preset value for time or monitor. -# -# -# Total integral monitor counts. -# -# -# -# -# -# Name the *plottable* field. The link here defines this name as -# ``data``. -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXsastof.yaml b/applications/nyaml/NXsastof.yaml deleted file mode 100644 index 83cdc8b769..0000000000 --- a/applications/nyaml/NXsastof.yaml +++ /dev/null @@ -1,312 +0,0 @@ -category: application -doc: | - raw, 2-D SAS data with an area detector with a time-of-flight source - - It covers all raw data from any SAS techniques - that use an area detector - at a time-of-flight source. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nXPixel: | - nXPixel description - nYPixel: | - nYPixel description - nTOF: | - nTOF description -type: group -NXsastof(NXobject): - (NXentry): - \@entry: - doc: | - NeXus convention is to use "entry1", "entry2", ... for analysis software to locate each entry - title: - start_time(NX_DATE_TIME): - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXsastof] - (NXinstrument)instrument: - (NXsource)source: - type: - doc: | - type of radiation source - name: - doc: | - Name of the radiation source - probe: - enumeration: [neutron, x-ray] - (NXcollimator)collimator: - (NXgeometry)geometry: - (NXshape)shape: - shape(NX_CHAR): - enumeration: [nxcylinder, nxbox] - size(NX_FLOAT): - unit: NX_LENGTH - doc: | - The collimation length - (NXdetector)detector: - data(NX_NUMBER): - signal: 1 - doc: | - This is area detector data, of number of x-pixel versus - number of y-pixels. Since the beam center is to be - determined as a step of data reduction, it is not necessary - to document or assume the position of the beam center in - acquired data. - dimensions: - rank: 3 - dim: [[1, nXPixel], [2, nYPixel], [3, nTOF]] - time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - dimensions: - rank: 1 - dim: [[1, nTOF]] - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - The distance between detector and sample - x_pixel_size(NX_FLOAT): - unit: NX_LENGTH - doc: | - Physical size of a pixel in x-direction - y_pixel_size(NX_FLOAT): - unit: NX_LENGTH - doc: | - Size of a pixel in y direction - polar_angle(NX_FLOAT): - unit: NX_ANGLE - azimuthal_angle(NX_FLOAT): - unit: NX_ANGLE - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - aequatorial_angle(NX_FLOAT): - unit: NX_ANGLE - beam_center_x(NX_FLOAT): - unit: NX_LENGTH - doc: | - This is the x position where the direct beam would hit the detector. This is a - length, not a pixel position, and can be outside of the actual detector. - beam_center_y(NX_FLOAT): - unit: NX_LENGTH - doc: | - This is the y position where the direct beam would hit the detector. This is a - length, not a pixel position, and can be outside of the actual detector. - name(NX_CHAR): - doc: | - Name of the instrument actually used to perform the experiment - (NXsample)sample: - name: - doc: | - Descriptive name of sample - aequatorial_angle(NX_FLOAT): - unit: NX_ANGLE - (NXmonitor)control: - mode: - doc: | - Count to a preset value based on either clock time (timer) or received monitor counts (monitor). - enumeration: [monitor, timer] - preset(NX_FLOAT): - doc: | - preset value for time or monitor - data(NX_INT): - primary: 1 - signal: 1 - dimensions: - rank: 1 - dim: [[1, nTOF]] - time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - dimensions: - rank: 1 - dim: [[1, nTOF]] - (NXdata)data: - data(link): - target: /NXentry/NXinstrument/NXdetector/data - time_of_flight(link): - target: /NXentry/NXinstrument/NXdetector/time_of_flight - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 68a1e31976db95a4668bae7d13acaa17bff96ea423fc23bf3bf1812df57ccd6f -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# nXPixel description -# -# -# nYPixel description -# -# -# nTOF description -# -# -# -# raw, 2-D SAS data with an area detector with a time-of-flight source -# -# It covers all raw data from any SAS techniques -# that use an area detector -# at a time-of-flight source. -# -# -# -# NeXus convention is to use "entry1", "entry2", ... for analysis software to locate each entry -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# type of radiation source -# -# -# Name of the radiation source -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The collimation length -# -# -# -# -# -# -# -# This is area detector data, of number of x-pixel versus -# number of y-pixels. Since the beam center is to be -# determined as a step of data reduction, it is not necessary -# to document or assume the position of the beam center in -# acquired data. -# -# -# -# -# -# -# -# -# -# -# -# -# The distance between detector and sample -# -# -# Physical size of a pixel in x-direction -# -# -# Size of a pixel in y direction -# -# -# -# -# -# -# -# -# -# This is the x position where the direct beam would hit the detector. This is a -# length, not a pixel position, and can be outside of the actual detector. -# -# -# -# -# This is the y position where the direct beam would hit the detector. This is a -# length, not a pixel position, and can be outside of the actual detector. -# -# -# -# -# Name of the instrument actually used to perform the experiment -# -# -# -# -# Descriptive name of sample -# -# -# -# -# -# -# Count to a preset value based on either clock time (timer) or received monitor counts (monitor). -# -# -# -# -# -# -# preset value for time or monitor -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXscan.yaml b/applications/nyaml/NXscan.yaml deleted file mode 100644 index 15bec5624c..0000000000 --- a/applications/nyaml/NXscan.yaml +++ /dev/null @@ -1,181 +0,0 @@ -category: application -doc: | - Application definition for a generic scan instrument. - - This definition is more an - example then a stringent definition as the content of a given NeXus scan file needs to - differ for different types of scans. This example definition shows a scan like done - on a rotation camera: the sample is rotated and a detector image, the rotation angle - and a monitor value is stored at each step in the scan. In the following, the symbol - ``NP`` is used to represent the number of scan points. These are the rules for - storing scan data in NeXus files which are implemented in this example: - - * Each value varied throughout a scan is stored as an array of - length ``NP`` at its respective location within the NeXus hierarchy. - * For area detectors, ``NP`` is the first dimension, - example for a detector of 256x256: ``data[NP,256,256]`` - * The NXdata group contains links to all variables varied in the scan and the data. - This to give an equivalent to the more familiar classical tabular representation of scans. - - These rules exist for a reason: HDF allows the first dimension of a data set to be - unlimited. This means the data can be appended too. Thus a NeXus file built according - to the rules given above can be used in the following way: - - * At the start of a scan, write all the static information. - * At each scan point, append new data from varied variables - and the detector to the file. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points - xDim: | - xDim description - yDim: | - yDim description -type: group -NXscan(NXobject): - (NXentry): - title: - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - definition(NX_CHAR): - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXscan] - (NXinstrument): - (NXdetector): - data(NX_INT): - signal: 1 - dimensions: - rank: 3 - dim: [[1, nP], [2, xDim], [3, yDim]] - (NXsample): - rotation_angle(NX_FLOAT): - axis: 1 - dimensions: - rank: 1 - dim: [[1, nP]] - (NXmonitor): - data(NX_INT): - dimensions: - rank: 1 - dim: [[1, nP]] - (NXdata): - data(link): - target: /NXentry/NXinstrument/NXdetector/data - rotation_angle(link): - target: /NXentry/NXsample/rotation_angle - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e4ec8cc633619e93141041919d5dfd0c507c7b825e0d5d6e469c6d235048883d -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of points -# -# -# xDim description -# -# -# yDim description -# -# -# -# Application definition for a generic scan instrument. -# -# This definition is more an -# example then a stringent definition as the content of a given NeXus scan file needs to -# differ for different types of scans. This example definition shows a scan like done -# on a rotation camera: the sample is rotated and a detector image, the rotation angle -# and a monitor value is stored at each step in the scan. In the following, the symbol -# ``NP`` is used to represent the number of scan points. These are the rules for -# storing scan data in NeXus files which are implemented in this example: -# -# * Each value varied throughout a scan is stored as an array of -# length ``NP`` at its respective location within the NeXus hierarchy. -# * For area detectors, ``NP`` is the first dimension, -# example for a detector of 256x256: ``data[NP,256,256]`` -# * The NXdata group contains links to all variables varied in the scan and the data. -# This to give an equivalent to the more familiar classical tabular representation of scans. -# -# These rules exist for a reason: HDF allows the first dimension of a data set to be -# unlimited. This means the data can be appended too. Thus a NeXus file built according -# to the rules given above can be used in the following way: -# -# * At the start of a scan, write all the static information. -# * At each scan point, append new data from varied variables -# and the detector to the file. -# -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXspe.yaml b/applications/nyaml/NXspe.yaml deleted file mode 100644 index 0227405b36..0000000000 --- a/applications/nyaml/NXspe.yaml +++ /dev/null @@ -1,128 +0,0 @@ -category: application -doc: | - NXSPE Inelastic Format. Application definition for NXSPE file format. -type: group -NXspe(NXobject): - (NXentry): - program_name: - definition: - doc: | - Official NeXus NXDL schema to which this file conforms. - \@version: - enumeration: [NXspe] - (NXcollection)NXSPE_info: - fixed_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - The fixed energy used for this file. - ki_over_kf_scaling(NX_BOOLEAN): - doc: | - Indicates whether ki/kf scaling has been applied or not. - psi(NX_FLOAT): - unit: NX_ANGLE - doc: | - Orientation angle as expected in DCS-MSlice - (NXdata)data: - azimuthal(NX_FLOAT): - unit: NX_ANGLE - azimuthal_width(NX_FLOAT): - unit: NX_ANGLE - polar(NX_FLOAT): - unit: NX_ANGLE - polar_width(NX_FLOAT): - unit: NX_ANGLE - distance(NX_FLOAT): - unit: NX_LENGTH - data(NX_NUMBER): - error(NX_NUMBER): - energy(NX_FLOAT): - unit: NX_ENERGY - (NXinstrument): - name(NX_CHAR): - (NXfermi_chopper): - energy(NX_NUMBER): - unit: NX_ENERGY - (NXsample): - rotation_angle(NX_NUMBER): - unit: NX_ANGLE - seblock(NX_CHAR): - temperature(NX_NUMBER): - unit: NX_TEMPERATURE - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 7fb4d550aa163b0510f8438390f93b19cd0b6ce3d6c75dd07d5c338e133853f2 -# -# -# -# -# NXSPE Inelastic Format. Application definition for NXSPE file format. -# -# -# -# Official NeXus NXDL schema to which this file conforms. -# -# -# -# -# -# -# -# The fixed energy used for this file. -# -# -# Indicates whether ki/kf scaling has been applied or not. -# -# -# Orientation angle as expected in DCS-MSlice -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXsqom.yaml b/applications/nyaml/NXsqom.yaml deleted file mode 100644 index 06a62871d1..0000000000 --- a/applications/nyaml/NXsqom.yaml +++ /dev/null @@ -1,211 +0,0 @@ -category: application -doc: | - This is the application definition for S(Q,OM) processed data. - - As this kind of data is in - general not on a rectangular grid after data reduction, it is stored as Q,E positions plus their - intensity, table like. It is the task of a possible visualisation program to regrid this data in - a sensible way. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points -type: group -NXsqom(NXobject): - (NXentry): - \@entry: - title: - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXsqom] - (NXinstrument)instrument: - (NXsource): - type: - name: - probe: - enumeration: [neutron, x-ray, electron] - name(NX_CHAR): - doc: | - Name of the instrument from which this data was reduced. - (NXsample): - name: - doc: | - Descriptive name of sample - (NXprocess)reduction: - program(NX_CHAR): - version(NX_CHAR): - (NXparameters)input: - filenames(NX_CHAR): - doc: | - Raw data files used to generate this I(Q) - doc: | - Input parameters for the reduction program used - (NXparameters)output: - doc: | - Eventual output parameters from the data reduction program used - (NXdata): - data(NX_INT): - signal: 1 - doc: | - This is the intensity for each point in QE - dimensions: - rank: 1 - dim: [[1, nP]] - qx(NX_NUMBER): - axis: 1 - unit: NX_WAVENUMBER - doc: | - Positions for the first dimension of Q - dimensions: - rank: 1 - dim: [[1, nP]] - qy(NX_NUMBER): - axis: 1 - unit: NX_WAVENUMBER - doc: | - Positions for the the second dimension of Q - dimensions: - rank: 1 - dim: [[1, nP]] - qz(NX_NUMBER): - axis: 1 - unit: NX_WAVENUMBER - doc: | - Positions for the the third dimension of Q - dimensions: - rank: 1 - dim: [[1, nP]] - en(NX_FLOAT): - axis: 1 - unit: NX_ENERGY - doc: | - Values for the energy transfer for each point - dimensions: - rank: 1 - dim: [[1, nP]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 48565491a3e0bb9a4151f2dda03ba4f8c9a2779d417a92224c9691d42a3393da -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of points -# -# -# -# This is the application definition for S(Q,OM) processed data. -# -# As this kind of data is in -# general not on a rectangular grid after data reduction, it is stored as Q,E positions plus their -# intensity, table like. It is the task of a possible visualisation program to regrid this data in -# a sensible way. -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Name of the instrument from which this data was reduced. -# -# -# -# -# Descriptive name of sample -# -# -# -# -# -# -# -# Raw data files used to generate this I(Q) -# -# Input parameters for the reduction program used -# -# -# Eventual output parameters from the data reduction program used -# -# -# -# -# This is the intensity for each point in QE -# -# -# -# -# -# Positions for the first dimension of Q -# -# -# -# -# -# Positions for the the second dimension of Q -# -# -# -# -# -# Positions for the the third dimension of Q -# -# -# -# -# -# Values for the energy transfer for each point -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXstxm.yaml b/applications/nyaml/NXstxm.yaml deleted file mode 100644 index 55d2ccde90..0000000000 --- a/applications/nyaml/NXstxm.yaml +++ /dev/null @@ -1,366 +0,0 @@ -category: application -doc: | - Application definition for a STXM instrument. - - The interferometer - position measurements, monochromator photon energy values and - detector measurements are all treated as NXdetectors and stored - within the NXinstrument group as lists of values stored in - chronological order. The NXdata group then holds another version - of the data in a regular 3D array (NumE by NumY by NumX, for a - total of nP points in a sample image stack type scan). The former - data values should be stored with a minimum loss of precision, while - the latter values can be simplified and/or approximated in order to - fit the constraints of a regular 3D array. 'Line scans' and 'point spectra' - are just sample_image scan types with reduced dimensions in the same way - as single images have reduced E dimensions compared to image 'stacks'. -symbols: - doc: | - These symbols will be used below to coordinate the shapes of the datasets. - nP: | - Total number of scan points - nE: | - Number of photon energies scanned - nX: | - Number of pixels in X direction - nY: | - Number of pixels in Y direction - detectorRank: | - Rank of data array provided by the detector for a single measurement -type: group -NXstxm(NXobject): - (NXentry): - title: - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - definition(NX_CHAR): - exists: ['min', '1', 'max', '1'] - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXstxm] - (NXinstrument): - exists: ['min', '1', 'max', '1'] - (NXsource): - exists: ['min', '1', 'max', '1'] - type: - exists: ['min', '1', 'max', '1'] - name: - exists: ['min', '1', 'max', '1'] - probe: - exists: ['min', '1', 'max', '1'] - (NXmonochromator)monochromator: - exists: ['min', '1', 'max', '1'] - energy(NX_FLOAT): - exists: ['min', '1', 'max', '1'] - dimensions: - rank: 1 - dim: [[1, nP]] - (NXdetector): - exists: ['min', '1'] - data(NX_NUMBER): - dimensions: - rank: 1+detectorRank - doc: | - Detector data should be presented with the first dimension corresponding to the - scan point and subsequent dimensions corresponding to the output of the detector. - Detectors that provide more than one value per scan point should have - a data array of rank 1+d, where d is the dimensions of the array provided per - scan point. For example, an area detector should have an NXdetector data array - of 3 dimensions, with the first being the set of scan points and the latter - two being the x- and y- extent of the detector. - NOTE: For each dimension > 1 there must exist a dim section such as: - dim: [[1, nP]] - (NXdetector)sample_x: - exists: ['min', '0', 'max', '1'] - doc: | - Measurements of the sample position from the x-axis interferometer. - data(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, nP]] - (NXdetector)sample_y: - exists: ['min', '0', 'max', '1'] - doc: | - Measurements of the sample position from the y-axis interferometer. - data(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, nP]] - (NXdetector)sample_z: - exists: ['min', '0', 'max', '1'] - doc: | - Measurements of the sample position from the z-axis interferometer. - data(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, nP]] - (NXsample): - rotation_angle(NX_FLOAT): - (NXdata): - stxm_scan_type: - exists: ['min', '1', 'max', '1'] - doc: | - Label for typical scan types as a convenience for humans. - Each label corresponds to a specific set of axes being scanned - to produce a data array of shape: - - * sample point spectrum: (photon_energy,) - * sample line spectrum: (photon_energy, sample_y/sample_x) - * sample image: (sample_y, sample_x) - * sample image stack: (photon_energy, sample_y, sample_x) - * sample focus: (zoneplate_z, sample_y/sample_x) - * osa image: (osa_y, osa_x) - * osa focus: (zoneplate_z, osa_y/osa_x) - * detector image: (detector_y, detector_x) - - The "generic scan" string is to be used when none of the - other choices are appropriate. - enumeration: [sample point spectrum, sample line spectrum, sample image, sample image stack, sample focus, osa image, osa focus, detector image, generic scan] - data(NX_NUMBER): - signal: 1 - doc: | - Detectors that provide more than one value per scan point should be summarised - to a single value per scan point for this array in order to simplify plotting. - - Note that 'Line scans' and focus type scans measure along one spatial dimension - but are not restricted to being parallel to the X or Y axes. Such scans - should therefore use a single dimension for the positions along the spatial - line. The 'sample_x' and 'sample_y' fields should then contain lists of the - x- and y-positions and should both have the 'axis' attribute pointing to the same dimension. - energy(NX_FLOAT): - exists: ['min', '1', 'max', '1'] - doc: | - List of photon energies of the X-ray beam. If scanned through multiple values, - then an 'axis' attribute will be required to link the field to the appropriate data array dimension. - dimensions: - rank: 1 - dim: [[1, nE]] - sample_y(NX_FLOAT): - exists: ['min', '1', 'max', '1'] - doc: | - List of Y positions on the sample. If scanned through multiple values, - then an 'axis' attribute will be required to link the field to the appropriate data array dimension. - dimensions: - rank: 1 - dim: [[1, nY]] - sample_x(NX_FLOAT): - exists: ['min', '1', 'max', '1'] - doc: | - List of X positions on the sample. If scanned through multiple values, - then an 'axis' attribute will be required to link the field to the appropriate data array dimension. - dimensions: - rank: 1 - dim: [[1, nX]] - (NXmonitor)control: - exists: ['min', '0', 'max', '1'] - data(NX_FLOAT): - doc: | - Values to use to normalise for time-variations in photon flux. Typically, the synchrotron storage ring - electron beam current is used as a proxy for the X-ray beam intensity. Array must have same shape as the - NXdata groups. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 766c145183881a32ac06b3016dd92af67d23354f1aebb1a250cb921cfc719a56 -# -# -# -# -# -# -# These symbols will be used below to coordinate the shapes of the datasets. -# -# -# Total number of scan points -# -# -# Number of photon energies scanned -# -# -# Number of pixels in X direction -# -# -# Number of pixels in Y direction -# -# -# Rank of data array provided by the detector for a single measurement -# -# -# -# Application definition for a STXM instrument. -# -# The interferometer -# position measurements, monochromator photon energy values and -# detector measurements are all treated as NXdetectors and stored -# within the NXinstrument group as lists of values stored in -# chronological order. The NXdata group then holds another version -# of the data in a regular 3D array (NumE by NumY by NumX, for a -# total of nP points in a sample image stack type scan). The former -# data values should be stored with a minimum loss of precision, while -# the latter values can be simplified and/or approximated in order to -# fit the constraints of a regular 3D array. 'Line scans' and 'point spectra' -# are just sample_image scan types with reduced dimensions in the same way -# as single images have reduced E dimensions compared to image 'stacks'. -# -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Detector data should be presented with the first dimension corresponding to the -# scan point and subsequent dimensions corresponding to the output of the detector. -# Detectors that provide more than one value per scan point should have -# a data array of rank 1+d, where d is the dimensions of the array provided per -# scan point. For example, an area detector should have an NXdetector data array -# of 3 dimensions, with the first being the set of scan points and the latter -# two being the x- and y- extent of the detector. -# NOTE: For each dimension > 1 there must exist a dim section such as: -# -# -# -# -# -# -# Measurements of the sample position from the x-axis interferometer. -# -# -# -# -# -# -# -# Measurements of the sample position from the y-axis interferometer. -# -# -# -# -# -# -# -# Measurements of the sample position from the z-axis interferometer. -# -# -# -# -# -# -# -# -# -# -# -# -# Label for typical scan types as a convenience for humans. -# Each label corresponds to a specific set of axes being scanned -# to produce a data array of shape: -# -# * sample point spectrum: (photon_energy,) -# * sample line spectrum: (photon_energy, sample_y/sample_x) -# * sample image: (sample_y, sample_x) -# * sample image stack: (photon_energy, sample_y, sample_x) -# * sample focus: (zoneplate_z, sample_y/sample_x) -# * osa image: (osa_y, osa_x) -# * osa focus: (zoneplate_z, osa_y/osa_x) -# * detector image: (detector_y, detector_x) -# -# The "generic scan" string is to be used when none of the -# other choices are appropriate. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Detectors that provide more than one value per scan point should be summarised -# to a single value per scan point for this array in order to simplify plotting. -# -# Note that 'Line scans' and focus type scans measure along one spatial dimension -# but are not restricted to being parallel to the X or Y axes. Such scans -# should therefore use a single dimension for the positions along the spatial -# line. The 'sample_x' and 'sample_y' fields should then contain lists of the -# x- and y-positions and should both have the 'axis' attribute pointing to the same dimension. -# -# -# List of photon energies of the X-ray beam. If scanned through multiple values, -# then an 'axis' attribute will be required to link the field to the appropriate data array dimension. -# -# -# -# -# -# List of Y positions on the sample. If scanned through multiple values, -# then an 'axis' attribute will be required to link the field to the appropriate data array dimension. -# -# -# -# -# -# List of X positions on the sample. If scanned through multiple values, -# then an 'axis' attribute will be required to link the field to the appropriate data array dimension. -# -# -# -# -# -# -# -# Values to use to normalise for time-variations in photon flux. Typically, the synchrotron storage ring -# electron beam current is used as a proxy for the X-ray beam intensity. Array must have same shape as the -# NXdata groups. -# -# -# -# diff --git a/applications/nyaml/NXtas.yaml b/applications/nyaml/NXtas.yaml deleted file mode 100644 index d69526b164..0000000000 --- a/applications/nyaml/NXtas.yaml +++ /dev/null @@ -1,350 +0,0 @@ -category: application -doc: | - This is an application definition for a triple axis spectrometer. - - It is for the trademark scan of the TAS, the Q-E scan. - For your alignment scans use the rules in :ref:`NXscan`. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points -type: group -NXtas(NXobject): - (NXentry)entry: - title(NX_CHAR): - start_time(NX_DATE_TIME): - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXtas] - (NXinstrument): - (NXsource): - name: - probe: - enumeration: [neutron, x-ray] - (NXcrystal)monochromator: - ei(NX_FLOAT): - unit: NX_ENERGY - axis: 1 - dimensions: - rank: 1 - dim: [[1, nP]] - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - dimensions: - rank: 1 - dim: [[1, nP]] - (NXcrystal)analyser: - ef(NX_FLOAT): - unit: NX_ENERGY - axis: 1 - dimensions: - rank: 1 - dim: [[1, nP]] - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - dimensions: - rank: 1 - dim: [[1, nP]] - polar_angle(NX_FLOAT): - unit: NX_ANGLE - dimensions: - rank: 1 - dim: [[1, nP]] - (NXdetector): - data(NX_INT): - signal: 1 - dimensions: - rank: 1 - dim: [[1, nP]] - polar_angle(NX_FLOAT): - unit: NX_ANGLE - dimensions: - rank: 1 - dim: [[1, nP]] - (NXsample): - name: - doc: | - Descriptive name of sample - qh(NX_FLOAT): - unit: NX_DIMENSIONLESS - axis: 1 - dimensions: - rank: 1 - dim: [[1, nP]] - qk(NX_FLOAT): - unit: NX_DIMENSIONLESS - axis: 1 - dimensions: - rank: 1 - dim: [[1, nP]] - ql(NX_FLOAT): - unit: NX_DIMENSIONLESS - axis: 1 - dimensions: - rank: 1 - dim: [[1, nP]] - en(NX_FLOAT): - unit: NX_ENERGY - axis: 1 - dimensions: - rank: 1 - dim: [[1, nP]] - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - dimensions: - rank: 1 - dim: [[1, nP]] - polar_angle(NX_FLOAT): - unit: NX_ANGLE - dimensions: - rank: 1 - dim: [[1, nP]] - sgu(NX_FLOAT): - unit: NX_ANGLE - dimensions: - rank: 1 - dim: [[1, nP]] - sgl(NX_FLOAT): - unit: NX_ANGLE - dimensions: - rank: 1 - dim: [[1, nP]] - unit_cell(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 6]] - orientation_matrix(NX_FLOAT): - unit: NX_DIMENSIONLESS - dimensions: - rank: 1 - dim: [[1, 9]] - (NXmonitor): - mode: - doc: | - Count to a preset value based on either clock time (timer) - or received monitor counts (monitor). - enumeration: [monitor, timer] - preset(NX_FLOAT): - doc: | - preset value for time or monitor - data(NX_FLOAT): - unit: NX_ANY - doc: | - Total integral monitor counts - dimensions: - rank: 1 - dim: [[1, nP]] - (NXdata): - doc: | - One of the ei,ef,qh,qk,ql,en should get a primary=1 attribute to denote the main scan axis - ei(link): - target: /NXentry/NXinstrument/monochromator:NXcrystal/ei - ef(link): - target: /NXentry/NXinstrument/analyser:NXcrystal/ef - en(link): - target: /NXentry/NXsample/en - qh(link): - target: /NXentry/NXsample/qh - qk(link): - target: /NXentry/NXsample/qk - ql(link): - target: /NXentry/NXsample/ql - data(link): - target: /NXentry/NXinstrument/NXdetector/data - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 16d474c4bdf0c285d9a3956666372d7f2bd31e72c3801c66cfaf3f90b89a257b -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of points -# -# -# -# This is an application definition for a triple axis spectrometer. -# -# It is for the trademark scan of the TAS, the Q-E scan. -# For your alignment scans use the rules in :ref:`NXscan`. -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Count to a preset value based on either clock time (timer) -# or received monitor counts (monitor). -# -# -# -# -# -# -# -# preset value for time or monitor -# -# -# Total integral monitor counts -# -# -# -# -# -# One of the ei,ef,qh,qk,ql,en should get a primary=1 attribute to denote the main scan axis -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXtofnpd.yaml b/applications/nyaml/NXtofnpd.yaml deleted file mode 100644 index c80e517f49..0000000000 --- a/applications/nyaml/NXtofnpd.yaml +++ /dev/null @@ -1,233 +0,0 @@ -category: application -doc: | - This is a application definition for raw data from a TOF neutron powder diffractometer -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nDet: | - Number of detectors - nTimeChan: | - nTimeChan description -type: group -NXtofnpd(NXobject): - (NXentry)entry: - title: - start_time(NX_DATE_TIME): - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXtofnpd] - pre_sample_flightpath(NX_FLOAT): - unit: NX_LENGTH - doc: | - This is the flight path before the sample position. This can be determined by a chopper, - by the moderator or the source itself. In other words: it the distance to the component - which gives the T0 signal to the detector electronics. If another component in the - NXinstrument hierarchy provides this information, this should be a link. - (NXuser)user: - name(NX_CHAR): - (NXinstrument): - (NXdetector)detector: - data(NX_INT): - signal: 1 - dimensions: - rank: 2 - dim: [[1, nDet], [2, nTimeChan]] - detector_number(NX_INT): - axis: 2 - dimensions: - rank: 1 - dim: [[1, nDet]] - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - distance to sample for each detector - dimensions: - rank: 1 - dim: [[1, nDet]] - time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - axis: 1 - dimensions: - rank: 1 - dim: [[1, nTimeChan]] - polar_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - polar angle for each detector element - dimensions: - rank: 1 - dim: [[1, nDet]] - azimuthal_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - azimuthal angle for each detector element - dimensions: - rank: 1 - dim: [[1, nDet]] - (NXsample): - name: - doc: | - Descriptive name of sample - (NXmonitor): - mode: - doc: | - Count to a preset value based on either clock time (timer) - or received monitor counts (monitor). - enumeration: [monitor, timer] - preset(NX_FLOAT): - doc: | - preset value for time or monitor - distance(NX_FLOAT): - unit: NX_LENGTH - data(NX_INT): - signal: 1 - dimensions: - rank: 1 - dim: [[1, nTimeChan]] - time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - axis: 1 - dimensions: - rank: 1 - dim: [[1, nTimeChan]] - (NXdata)data: - data(link): - target: /NXentry/NXinstrument/NXdetector/data - detector_number(link): - target: /NXentry/NXinstrument/NXdetector/detector_number - time_of_flight(link): - target: /NXentry/NXinstrument/NXdetector/time_of_flight - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 9f042a00759000fb9181be13d4abd5224008fd03793f68048c7177daa0095b03 -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of detectors -# -# -# nTimeChan description -# -# -# This is a application definition for raw data from a TOF neutron powder diffractometer -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# This is the flight path before the sample position. This can be determined by a chopper, -# by the moderator or the source itself. In other words: it the distance to the component -# which gives the T0 signal to the detector electronics. If another component in the -# NXinstrument hierarchy provides this information, this should be a link. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# distance to sample for each detector -# -# -# -# -# -# -# -# polar angle for each detector element -# -# -# -# -# azimuthal angle for each detector element -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# -# -# Count to a preset value based on either clock time (timer) -# or received monitor counts (monitor). -# -# -# -# -# -# -# -# preset value for time or monitor -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXtofraw.yaml b/applications/nyaml/NXtofraw.yaml deleted file mode 100644 index 1a15cfe13a..0000000000 --- a/applications/nyaml/NXtofraw.yaml +++ /dev/null @@ -1,255 +0,0 @@ -category: application -doc: | - This is an application definition for raw data from a generic TOF instrument -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nDet: | - Number of detectors - nTimeChan: | - nTimeChan description -type: group -NXtofraw(NXobject): - (NXentry)entry: - title: - start_time(NX_DATE_TIME): - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXtofraw] - duration(NX_FLOAT): - run_number(NX_INT): - pre_sample_flightpath(NX_FLOAT): - unit: NX_LENGTH - doc: | - This is the flight path before the sample position. This can be determined by a chopper, - by the moderator, or the source itself. In other words: it is the distance to the component - which gives the T0 signal to the detector electronics. If another component in the - NXinstrument hierarchy provides this information, this should be a link. - (NXuser)user: - name(NX_CHAR): - (NXinstrument)instrument: - (NXdetector)detector: - data(NX_INT): - signal: 1 - dimensions: - rank: 2 - dim: [[1, nDet], [2, nTimeChan]] - detector_number(NX_INT): - axis: 2 - dimensions: - rank: 1 - dim: [[1, nDet]] - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - distance to sample for each detector - dimensions: - rank: 1 - dim: [[1, nDet]] - time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - axis: 1 - dimensions: - rank: 1 - dim: [[1, nTimeChan]] - polar_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - polar angle for each detector element - dimensions: - rank: 1 - dim: [[1, nDet]] - azimuthal_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - azimuthal angle for each detector element - dimensions: - rank: 1 - dim: [[1, nDet]] - (NXsample): - name: - doc: | - Descriptive name of sample - nature(NX_CHAR): - enumeration: [powder, liquid, single crystal] - (NXmonitor): - mode: - doc: | - Count to a preset value based on either clock time (timer) - or received monitor counts (monitor). - enumeration: [monitor, timer] - preset(NX_FLOAT): - doc: | - preset value for time or monitor - distance(NX_FLOAT): - unit: NX_LENGTH - data(NX_INT): - signal: 1 - dimensions: - rank: 1 - dim: [[1, nTimeChan]] - time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - axis: 1 - dimensions: - rank: 1 - dim: [[1, nTimeChan]] - integral_counts(NX_INT): - unit: NX_UNITLESS - (NXdata)data: - data(link): - target: /NXentry/NXinstrument/NXdetector/data - detector_number(link): - target: /NXentry/NXinstrument/NXdetector/detector_number - time_of_flight(link): - target: /NXentry/NXinstrument/NXdetector/time_of_flight - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 7864f83fb6965649da21352d3179c8b899327fe53d83712aefcad9b15bf0140a -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of detectors -# -# -# nTimeChan description -# -# -# This is an application definition for raw data from a generic TOF instrument -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# This is the flight path before the sample position. This can be determined by a chopper, -# by the moderator, or the source itself. In other words: it is the distance to the component -# which gives the T0 signal to the detector electronics. If another component in the -# NXinstrument hierarchy provides this information, this should be a link. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# distance to sample for each detector -# -# -# -# -# -# -# -# -# -# -# polar angle for each detector element -# -# -# -# -# -# azimuthal angle for each detector element -# -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# -# -# -# -# -# -# -# -# Count to a preset value based on either clock time (timer) -# or received monitor counts (monitor). -# -# -# -# -# -# -# -# preset value for time or monitor -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXtofsingle.yaml b/applications/nyaml/NXtofsingle.yaml deleted file mode 100644 index d0c9e9e839..0000000000 --- a/applications/nyaml/NXtofsingle.yaml +++ /dev/null @@ -1,244 +0,0 @@ -category: application -doc: | - This is a application definition for raw data from a generic TOF instrument -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - xSize: | - xSize description - ySize: | - ySize description - nDet: | - Number of detectors - nTimeChan: | - nTimeChan description -type: group -NXtofsingle(NXobject): - (NXentry)entry: - title: - start_time(NX_DATE_TIME): - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXtofsingle] - duration(NX_FLOAT): - pre_sample_flightpath(NX_FLOAT): - unit: NX_LENGTH - doc: | - This is the flight path before the sample position. This can be determined by a chopper, - by the moderator or the source itself. In other words: it the distance to the component - which gives the T0 signal to the detector electronics. If another component in the - NXinstrument hierarchy provides this information, this should be a link. - (NXuser)user: - name(NX_CHAR): - (NXinstrument): - (NXdetector)detector: - data(NX_INT): - signal: 1 - dimensions: - rank: 3 - dim: [[1, xSize], [2, ySize], [3, nTimeChan]] - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Distance to sample for the center of the detector - dimensions: - rank: 1 - dim: [[1, 1]] - time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - axis: 1 - dimensions: - rank: 1 - dim: [[1, nTimeChan]] - polar_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - polar angle for each detector element - dimensions: - rank: 1 - dim: [[1, nDet]] - azimuthal_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - azimuthal angle for each detector element - dimensions: - rank: 1 - dim: [[1, nDet]] - (NXsample): - name: - doc: | - Descriptive name of sample - nature(NX_CHAR): - enumeration: [powder, liquid, single crystal] - (NXmonitor): - mode: - doc: | - Count to a preset value based on either clock time (timer) - or received monitor counts (monitor). - enumeration: [monitor, timer] - preset(NX_FLOAT): - doc: | - preset value for time or monitor - distance(NX_FLOAT): - unit: NX_LENGTH - data(NX_INT): - signal: 1 - dimensions: - rank: 1 - dim: [[1, nTimeChan]] - time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - axis: 1 - dimensions: - rank: 1 - dim: [[1, nTimeChan]] - (NXdata)data: - data(link): - target: /NXentry/NXinstrument/NXdetector/data - time_of_flight(link): - target: /NXentry/NXinstrument/NXdetector/time_of_flight - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 7473543db0494dc64ff59fc584d77e82fccd096de2d1652579b17eb42ff30037 -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# xSize description -# -# -# ySize description -# -# -# Number of detectors -# -# -# nTimeChan description -# -# -# This is a application definition for raw data from a generic TOF instrument -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# This is the flight path before the sample position. This can be determined by a chopper, -# by the moderator or the source itself. In other words: it the distance to the component -# which gives the T0 signal to the detector electronics. If another component in the -# NXinstrument hierarchy provides this information, this should be a link. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Distance to sample for the center of the detector -# -# -# -# -# -# -# -# polar angle for each detector element -# -# -# -# -# azimuthal angle for each detector element -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# -# -# -# -# -# -# -# -# Count to a preset value based on either clock time (timer) -# or received monitor counts (monitor). -# -# -# -# -# -# -# -# preset value for time or monitor -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXtomo.yaml b/applications/nyaml/NXtomo.yaml deleted file mode 100644 index 5e6371000c..0000000000 --- a/applications/nyaml/NXtomo.yaml +++ /dev/null @@ -1,279 +0,0 @@ -category: application -doc: | - This is the application definition for x-ray or neutron tomography raw data. - - In tomography - a number of dark field images are measured, some bright field images and, of course the sample. - In order to distinguish between them images carry a image_key. -symbols: - doc: | - These symbols will be used below to coordinate datasets with the same shape. - nFrames: | - Number of frames - xSize: | - Number of pixels in X direction - ySize: | - Number of pixels in Y direction -type: group -NXtomo(NXobject): - (NXentry)entry: - title: - exists: ['min', '0', 'max', '1'] - start_time(NX_DATE_TIME): - exists: ['min', '0', 'max', '1'] - end_time(NX_DATE_TIME): - exists: ['min', '0', 'max', '1'] - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXtomo] - (NXinstrument)instrument: - (NXsource): - exists: ['min', '0', 'max', '1'] - type: - exists: ['min', '0', 'max', '1'] - name: - exists: ['min', '0', 'max', '1'] - probe: - exists: ['min', '0', 'max', '1'] - enumeration: [neutron, x-ray, electron] - (NXdetector)detector: - data(NX_INT): - signal: 1 - dimensions: - rank: 3 - dim: [[1, nFrames], [2, xSize], [3, ySize]] - image_key(NX_INT): - doc: | - In order - to distinguish between sample projections, dark and flat - images, a magic number is recorded per frame. - The key is as follows: - - * projection = 0 - * flat field = 1 - * dark field = 2 - * invalid = 3 - dimensions: - rank: 1 - dim: [[1, nFrames]] - x_pixel_size(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - y_pixel_size(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - distance(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - Distance between detector and sample - x_rotation_axis_pixel_position(NX_FLOAT): - exists: ['min', '0', 'max', '1'] - y_rotation_axis_pixel_position(NX_FLOAT): - exists: ['min', '0', 'max', '1'] - (NXsample)sample: - name: - doc: | - Descriptive name of sample - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - axis: 1 - doc: | - In practice this axis is always aligned along one pixel direction on the detector and usually vertical. - There are experiments with horizontal rotation axes, so this would need to be indicated somehow. - For now the best way for that is an open question. - dimensions: - rank: 1 - dim: [[1, nFrames]] - x_translation(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - dimensions: - rank: 1 - dim: [[1, nFrames]] - y_translation(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - dimensions: - rank: 1 - dim: [[1, nFrames]] - z_translation(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - dimensions: - rank: 1 - dim: [[1, nFrames]] - (NXmonitor)control: - exists: ['min', '0', 'max', '1'] - data(NX_FLOAT): - unit: NX_ANY - doc: | - Total integral monitor counts for each measured frame. Allows a to correction for - fluctuations in the beam between frames. - dimensions: - rank: 1 - dim: [[1, nFrames]] - (NXdata)data: - data(link): - target: /NXentry/NXinstrument/detector:NXdetector/data - rotation_angle(link): - target: /NXentry/NXsample/rotation_angle - image_key(link): - target: /NXentry/NXinstrument/detector:NXdetector/image_key - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 29a8d28bf2c28f10e750633de087242c07f91baa1f297a4e6e185af34a2adca2 -# -# -# -# -# -# -# These symbols will be used below to coordinate datasets with the same shape. -# -# -# Number of frames -# -# -# Number of pixels in X direction -# -# -# Number of pixels in Y direction -# -# -# -# This is the application definition for x-ray or neutron tomography raw data. -# -# In tomography -# a number of dark field images are measured, some bright field images and, of course the sample. -# In order to distinguish between them images carry a image_key. -# -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# In order -# to distinguish between sample projections, dark and flat -# images, a magic number is recorded per frame. -# The key is as follows: -# -# * projection = 0 -# * flat field = 1 -# * dark field = 2 -# * invalid = 3 -# -# -# -# -# -# -# -# -# Distance between detector and sample -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# In practice this axis is always aligned along one pixel direction on the detector and usually vertical. -# There are experiments with horizontal rotation axes, so this would need to be indicated somehow. -# For now the best way for that is an open question. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Total integral monitor counts for each measured frame. Allows a to correction for -# fluctuations in the beam between frames. -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXtomophase.yaml b/applications/nyaml/NXtomophase.yaml deleted file mode 100644 index e608687b10..0000000000 --- a/applications/nyaml/NXtomophase.yaml +++ /dev/null @@ -1,292 +0,0 @@ -category: application -doc: | - This is the application definition for x-ray or neutron tomography raw data with phase contrast variation at each point. - - In tomography first - some dark field images are measured, some bright field images and, of course the sample. In order - to properly sort the order of the images taken, a sequence number is stored with each image. -symbols: - doc: | - These symbols will be used below to coordinate datasets with the same shape. - nBrightFrames: | - Number of bright frames - nDarkFrames: | - Number of dark frames - nSampleFrames: | - Number of image (sample) frames - nPhase: | - Number of phase settings - xSize: | - Number of pixels in X direction - ySize: | - Number of pixels in Y direction -type: group -NXtomophase(NXobject): - (NXentry)entry: - title: - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXtomophase] - (NXinstrument)instrument: - (NXsource): - type: - name: - probe: - enumeration: [neutron, x-ray, electron] - (NXdetector)bright_field: - data(NX_INT): - signal: 1 - dimensions: - rank: 3 - dim: [[1, nBrightFrames], [2, xSize], [3, ySize]] - sequence_number(NX_INT): - dimensions: - rank: 1 - dim: [[1, nBrightFrames]] - (NXdetector)dark_field: - data(NX_INT): - signal: 1 - dimensions: - rank: 3 - dim: [[1, nDarkFrames], [2, xSize], [3, ySize]] - sequence_number(NX_INT): - dimensions: - rank: 1 - dim: [[1, nDarkFrames]] - (NXdetector)sample: - data(NX_INT): - signal: 1 - dimensions: - rank: 4 - dim: [[1, nSampleFrames], [2, nPhase], [3, xSize], [4, ySize]] - sequence_number(NX_INT): - dimensions: - rank: 2 - dim: [[1, nSampleFrames], [2, nPhase]] - x_pixel_size(NX_FLOAT): - unit: NX_LENGTH - y_pixel_size(NX_FLOAT): - unit: NX_LENGTH - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Distance between detector and sample - (NXsample)sample: - name: - doc: | - Descriptive name of sample - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - axis: 1 - dimensions: - rank: 1 - dim: [[1, nSampleFrames]] - x_translation(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, nSampleFrames]] - y_translation(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, nSampleFrames]] - z_translation(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, nSampleFrames]] - (NXmonitor)control: - integral(NX_FLOAT): - unit: NX_ANY - doc: | - Total integral monitor counts for each measured frame. Allows a correction for - fluctuations in the beam between frames. - dimensions: - rank: 1 - - # TODO: nPhase? - dim: [[1, nDarkFrames + nBrightFrames + nSampleFrame]] - (NXdata)data: - data(link): - target: /NXentry/NXinstrument/sample:NXdetector/data - rotation_angle(link): - target: /NXentry/NXsample/rotation_angle - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8cae5bb17d08c4f621c37c2722dfac49347721aa6229a9f6e2dcee6a296bd330 -# -# -# -# -# -# These symbols will be used below to coordinate datasets with the same shape. -# -# Number of bright frames -# -# -# Number of dark frames -# -# -# Number of image (sample) frames -# -# -# Number of phase settings -# -# -# Number of pixels in X direction -# -# -# Number of pixels in Y direction -# -# -# -# This is the application definition for x-ray or neutron tomography raw data with phase contrast variation at each point. -# -# In tomography first -# some dark field images are measured, some bright field images and, of course the sample. In order -# to properly sort the order of the images taken, a sequence number is stored with each image. -# -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Distance between detector and sample -# -# -# -# -# -# Descriptive name of sample -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Total integral monitor counts for each measured frame. Allows a correction for -# fluctuations in the beam between frames. -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXtomoproc.yaml b/applications/nyaml/NXtomoproc.yaml deleted file mode 100644 index 21a2ffd829..0000000000 --- a/applications/nyaml/NXtomoproc.yaml +++ /dev/null @@ -1,217 +0,0 @@ -category: application -doc: | - This is an application definition for the final result of a tomography experiment: a 3D construction of some volume of physical properties. -symbols: - doc: | - These symbols will be used below to coordinate datasets with the same shape. - nX: | - Number of voxels in X direction - nY: | - Number of voxels in Y direction - nZ: | - Number of voxels in Z direction -type: group -NXtomoproc(NXobject): - (NXentry)entry: - title: - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXtomoproc] - (NXinstrument): - (NXsource): - type: - name: - probe: - enumeration: [neutron, x-ray, electron] - (NXsample): - name: - doc: | - Descriptive name of sample - (NXprocess)reconstruction: - program(NX_CHAR): - doc: | - Name of the program used for reconstruction - version(NX_CHAR): - doc: | - Version of the program used - date(NX_DATE_TIME): - doc: | - Date and time of reconstruction processing. - (NXparameters)parameters: - raw_file(NX_CHAR): - doc: | - Original raw data file this data was derived from - (NXdata)data: - data(NX_INT): - signal: 1 - doc: | - This is the reconstructed volume. This can be different - things. Please indicate in the unit attribute what physical - quantity this really is. - dimensions: - rank: 3 - dim: [[1, nX], [2, nX], [3, nZ]] - \@transform: - \@offset: - \@scaling: - x(NX_FLOAT): - unit: NX_ANY - axis: 1 - doc: | - This is an array holding the values to use for the x-axis of - data. The units must be appropriate for the measurement. - dimensions: - rank: 1 - dim: [[1, nX]] - y(NX_FLOAT): - unit: NX_ANY - axis: 2 - doc: | - This is an array holding the values to use for the y-axis of - data. The units must be appropriate for the measurement. - dimensions: - rank: 1 - dim: [[1, nY]] - z(NX_FLOAT): - unit: NX_ANY - axis: 3 - doc: | - This is an array holding the values to use for the z-axis of - data. The units must be appropriate for the measurement. - dimensions: - rank: 1 - dim: [[1, nZ]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 513ccbcaca9011133f9617a44c3fe3f6fa80d6b54b562ba4bf09ac4b917afe16 -# -# -# -# -# -# These symbols will be used below to coordinate datasets with the same shape. -# -# Number of voxels in X direction -# -# -# Number of voxels in Y direction -# -# -# Number of voxels in Z direction -# -# -# This is an application definition for the final result of a tomography experiment: a 3D construction of some volume of physical properties. -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# -# Name of the program used for reconstruction -# -# -# Version of the program used -# -# -# Date and time of reconstruction processing. -# -# -# -# Original raw data file this data was derived from -# -# -# -# -# -# -# This is the reconstructed volume. This can be different -# things. Please indicate in the unit attribute what physical -# quantity this really is. -# -# -# -# -# -# -# -# -# -# -# -# -# This is an array holding the values to use for the x-axis of -# data. The units must be appropriate for the measurement. -# -# -# -# -# -# -# -# This is an array holding the values to use for the y-axis of -# data. The units must be appropriate for the measurement. -# -# -# -# -# -# -# -# This is an array holding the values to use for the z-axis of -# data. The units must be appropriate for the measurement. -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXxas.yaml b/applications/nyaml/NXxas.yaml deleted file mode 100644 index 4fb26f2cba..0000000000 --- a/applications/nyaml/NXxas.yaml +++ /dev/null @@ -1,212 +0,0 @@ -category: application -doc: | - This is an application definition for raw data from an X-ray absorption spectroscopy experiment. - - This is essentially a scan on energy versus incoming/ - absorbed beam. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points -type: group -NXxas(NXobject): - (NXentry): - \@entry: - doc: | - NeXus convention is to use "entry1", "entry2", ... - for analysis software to locate each entry. - title: - start_time(NX_DATE_TIME): - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXxas] - (NXinstrument): - (NXsource): - type: - name: - probe: - enumeration: [x-ray] - (NXmonochromator)monochromator: - energy(NX_FLOAT): - axis: 1 - dimensions: - rank: 1 - dim: [[1, nP]] - (NXdetector)incoming_beam: - data(NX_NUMBER): - dimensions: - rank: 1 - dim: [[1, nP]] - (NXdetector)absorbed_beam: - data(NX_NUMBER): - doc: | - This data corresponds to the sample signal. - dimensions: - rank: 1 - dim: [[1, nP]] - (NXsample): - name: - doc: | - Descriptive name of sample - (NXmonitor): - mode: - doc: | - Count to a preset value based on either clock time (timer) - or received monitor counts (monitor). - enumeration: [monitor, timer] - preset(NX_FLOAT): - doc: | - preset value for time or monitor - data(NX_NUMBER): - doc: | - This field could be a link to ``/NXentry/NXinstrument/incoming_beam:NXdetector/data`` - dimensions: - rank: 1 - dim: [[1, nP]] - (NXdata): - energy(link): - target: /NXentry/NXinstrument/monochromator:NXmonochromator/energy - absorbed_beam(link): - target: /NXentry/NXinstrument/absorbed_beam:NXdetector/data - mode: - doc: | - Detection method used for observing the sample absorption (pick one from the enumerated list and spell exactly) - enumeration: [Total Electron Yield, Partial Electron Yield, Auger Electron Yield, Fluorescence Yield, Transmission] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# ee7af600593990ebd190dcaa06a6dbc6145c9bcac5ec3eecfc556164069f5e0b -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of points -# -# -# -# This is an application definition for raw data from an X-ray absorption spectroscopy experiment. -# -# This is essentially a scan on energy versus incoming/ -# absorbed beam. -# -# -# -# -# NeXus convention is to use "entry1", "entry2", ... -# for analysis software to locate each entry. -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# This data corresponds to the sample signal. -# -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# -# -# Count to a preset value based on either clock time (timer) -# or received monitor counts (monitor). -# -# -# -# -# -# -# -# preset value for time or monitor -# -# -# This field could be a link to ``/NXentry/NXinstrument/incoming_beam:NXdetector/data`` -# -# -# -# -# -# -# -# -# -# Detection method used for observing the sample absorption (pick one from the enumerated list and spell exactly) -# -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXxasproc.yaml b/applications/nyaml/NXxasproc.yaml deleted file mode 100644 index 2887725d87..0000000000 --- a/applications/nyaml/NXxasproc.yaml +++ /dev/null @@ -1,147 +0,0 @@ -category: application -doc: | - Processed data from XAS. This is energy versus I(incoming)/I(absorbed). -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points -type: group -NXxasproc(NXobject): - (NXentry): - \@entry: - doc: | - NeXus convention is to use "entry1", "entry2", ... - for analysis software to locate each entry. - title: - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXxasproc] - (NXsample): - name: - doc: | - Descriptive name of sample - (NXprocess)XAS_data_reduction: - program(NX_CHAR): - doc: | - Name of the program used for reconstruction - version(NX_CHAR): - doc: | - Version of the program used - date(NX_DATE_TIME): - doc: | - Date and time of reconstruction processing. - (NXparameters)parameters: - raw_file(NX_CHAR): - doc: | - Original raw data file this data was derived from - (NXdata): - energy: - axis: 1 - dimensions: - rank: 1 - dim: [[1, nP]] - data(NX_FLOAT): - doc: | - This is corrected and calibrated I(incoming)/I(absorbed). So it is the absorption. - Expect attribute ``signal=1`` - dimensions: - rank: 1 - dim: [[1, nP]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2b4100596d83ddef40232cb741377e6f47892f210e1e1d3b36aeb850dc09ea8d -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of points -# -# -# -# Processed data from XAS. This is energy versus I(incoming)/I(absorbed). -# -# -# -# -# NeXus convention is to use "entry1", "entry2", ... -# for analysis software to locate each entry. -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# -# Name of the program used for reconstruction -# -# -# Version of the program used -# -# -# Date and time of reconstruction processing. -# -# -# -# Original raw data file this data was derived from -# -# -# -# -# -# -# -# -# -# -# -# This is corrected and calibrated I(incoming)/I(absorbed). So it is the absorption. -# Expect attribute ``signal=1`` -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXxbase.yaml b/applications/nyaml/NXxbase.yaml deleted file mode 100644 index 52a56538d8..0000000000 --- a/applications/nyaml/NXxbase.yaml +++ /dev/null @@ -1,308 +0,0 @@ -category: application -doc: | - This definition covers the common parts of all monochromatic single crystal raw data application definitions. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points - nXPixels: | - Number of X pixels - nYPixels: | - Number of Y pixels -type: group -NXxbase(NXobject): - (NXentry)entry: - title: - start_time(NX_DATE_TIME): - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXxbase] - (NXinstrument)instrument: - (NXsource)source: - type: - name: - probe: - enumeration: [neutron, x-ray, electron] - (NXmonochromator)monochromator: - wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - (NXdetector)detector: - exists: ['max', 'unbounded'] - data(NX_INT): - signal: 1 - doc: | - The area detector data, the first dimension is always the - number of scan points, the second and third are the number - of pixels in x and y. The origin is always assumed to be - in the center of the detector. maxOccurs is limited to the - the number of detectors on your instrument. - dimensions: - rank: 3 - dim: [[1, nP], [2, nXPixels], [3, nYPixels]] - \@signal: - type: NX_POSINT - enumeration: [1] - x_pixel_size(NX_FLOAT): - unit: NX_LENGTH - y_pixel_size(NX_FLOAT): - unit: NX_LENGTH - doc: | - The name of the group is detector if there is only one detector, - if there are several, names have to be detector1, - detector2, ...detectorn. - distance(NX_FLOAT): - unit: NX_LENGTH - frame_start_number(NX_INT): - doc: | - This is the start number of the first frame of a scan. In PX one often scans a couple - of frames on a give sample, then does something else, then returns to the same sample - and scans some more frames. Each time with a new data file. - This number helps concatenating such measurements. - (NXsample)sample: - name(NX_CHAR): - doc: | - Descriptive name of sample - orientation_matrix(NX_FLOAT): - doc: | - The orientation matrix according to Busing and - Levy conventions. This is not strictly necessary as - the UB can always be derived from the data. But - let us bow to common usage which includes the - UB nearly always. - dimensions: - rank: 2 - dim: [[1, 3], [2, 3]] - unit_cell(NX_FLOAT): - doc: | - The unit cell, a, b, c, alpha, beta, gamma. - Again, not strictly necessary, but normally written. - dimensions: - rank: 1 - dim: [[1, 6]] - temperature(NX_FLOAT): - doc: | - The sample temperature or whatever sensor represents this value best - dimensions: - rank: 1 - dim: [[1, nP]] - x_translation(NX_FLOAT): - unit: NX_LENGTH - doc: | - Translation of the sample along the X-direction of the laboratory coordinate system - y_translation(NX_FLOAT): - unit: NX_LENGTH - doc: | - Translation of the sample along the Y-direction of the laboratory coordinate system - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Translation of the sample along the Z-direction of the laboratory coordinate system - (NXmonitor)control: - mode: - doc: | - Count to a preset value based on either clock time (timer) - or received monitor counts (monitor). - enumeration: [monitor, timer] - preset(NX_FLOAT): - doc: | - preset value for time or monitor - integral(NX_FLOAT): - unit: NX_ANY - doc: | - Total integral monitor counts - (NXdata): - doc: | - The name of this group id data if there is only - one detector; if there are several the names will - be data1, data2, data3 and will point - to the corresponding detector groups in the - instrument hierarchy. - data(link): - target: /NXentry/NXinstrument/NXdetector/data - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 90f4a19eaacbf9b1e9fee25a34dc296e1ad553b018f7b11594918d7dcf915a94 -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of points -# -# -# Number of X pixels -# -# -# Number of Y pixels -# -# -# -# This definition covers the common parts of all monochromatic single crystal raw data application definitions. -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The area detector data, the first dimension is always the -# number of scan points, the second and third are the number -# of pixels in x and y. The origin is always assumed to be -# in the center of the detector. maxOccurs is limited to the -# the number of detectors on your instrument. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The name of the group is detector if there is only one detector, -# if there are several, names have to be detector1, -# detector2, ...detectorn. -# -# -# -# This is the start number of the first frame of a scan. In PX one often scans a couple -# of frames on a give sample, then does something else, then returns to the same sample -# and scans some more frames. Each time with a new data file. -# This number helps concatenating such measurements. -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# The orientation matrix according to Busing and -# Levy conventions. This is not strictly necessary as -# the UB can always be derived from the data. But -# let us bow to common usage which includes the -# UB nearly always. -# -# -# -# -# -# -# -# -# The unit cell, a, b, c, alpha, beta, gamma. -# Again, not strictly necessary, but normally written. -# -# -# -# -# -# -# -# The sample temperature or whatever sensor represents this value best -# -# -# -# -# -# -# Translation of the sample along the X-direction of the laboratory coordinate system -# -# -# Translation of the sample along the Y-direction of the laboratory coordinate system -# -# -# Translation of the sample along the Z-direction of the laboratory coordinate system -# -# -# -# -# -# -# Count to a preset value based on either clock time (timer) -# or received monitor counts (monitor). -# -# -# -# -# -# -# -# preset value for time or monitor -# -# -# Total integral monitor counts -# -# -# -# -# The name of this group id data if there is only -# one detector; if there are several the names will -# be data1, data2, data3 and will point -# to the corresponding detector groups in the -# instrument hierarchy. -# -# -# -# -# diff --git a/applications/nyaml/NXxeuler.yaml b/applications/nyaml/NXxeuler.yaml deleted file mode 100644 index 727396aad7..0000000000 --- a/applications/nyaml/NXxeuler.yaml +++ /dev/null @@ -1,173 +0,0 @@ -category: application -doc: | - raw data from a :index:`four-circle diffractometer` with an :index:`eulerian cradle`, extends :ref:`NXxbase` - - It extends :ref:`NXxbase`, so the full definition is the content - of :ref:`NXxbase` plus the data defined here. All four angles are - logged in order to support arbitrary scans in reciprocal space. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points -type: group -NXxeuler(NXxbase): - (NXentry)entry: - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXxeuler] - (NXinstrument)instrument: - (NXdetector)detector: - polar_angle(NX_FLOAT): - unit: NX_ANGLE - axis: 1 - doc: | - The polar_angle (two theta) where the detector is placed - at each scan point. - dimensions: - rank: 1 - dim: [[1, nP]] - (NXsample)sample: - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - axis: 1 - doc: | - This is an array holding the sample rotation angle at each - scan point - dimensions: - rank: 1 - dim: [[1, nP]] - chi(NX_FLOAT): - unit: NX_ANGLE - axis: 1 - doc: | - This is an array holding the chi angle of the eulerian - cradle at each scan point - dimensions: - rank: 1 - dim: [[1, nP]] - phi(NX_FLOAT): - unit: NX_ANGLE - signal: 1 - doc: | - This is an array holding the phi rotation of the eulerian - cradle at each scan point - dimensions: - rank: 1 - dim: [[1, nP]] - (NXdata)name: - polar_angle(link): - target: /NXentry/NXinstrument/NXdetector/polar_angle - rotation_angle(link): - target: /NXentry/NXsample/rotation_angle - chi(link): - target: /NXentry/NXsample/chi - phi(link): - target: /NXentry/NXsample/phi - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# db83f7ef9d8434f75ba5a6a78e3c6e41b1db593b9c99d68f5419a7bb4f35d851 -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of points -# -# -# -# raw data from a :index:`four-circle diffractometer` with an :index:`eulerian cradle`, extends :ref:`NXxbase` -# -# It extends :ref:`NXxbase`, so the full definition is the content -# of :ref:`NXxbase` plus the data defined here. All four angles are -# logged in order to support arbitrary scans in reciprocal space. -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# The polar_angle (two theta) where the detector is placed -# at each scan point. -# -# -# -# -# -# -# -# -# -# -# This is an array holding the sample rotation angle at each -# scan point -# -# -# -# -# -# -# -# This is an array holding the chi angle of the eulerian -# cradle at each scan point -# -# -# -# -# -# -# -# This is an array holding the phi rotation of the eulerian -# cradle at each scan point -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXxkappa.yaml b/applications/nyaml/NXxkappa.yaml deleted file mode 100644 index ad9c192c54..0000000000 --- a/applications/nyaml/NXxkappa.yaml +++ /dev/null @@ -1,174 +0,0 @@ -category: application -doc: | - raw data from a kappa geometry (CAD4) single crystal diffractometer, extends :ref:`NXxbase` - - This is the application definition for raw data from a kappa geometry - (CAD4) single crystal - diffractometer. It extends :ref:`NXxbase`, so the full definition is - the content of :ref:`NXxbase` plus the - data defined here. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points -type: group -NXxkappa(NXxbase): - (NXentry)entry: - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXxkappa] - (NXinstrument)instrument: - (NXdetector)detector: - polar_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - The polar_angle (two theta) at each scan point - dimensions: - rank: 1 - dim: [[1, nP]] - (NXsample)sample: - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - axis: 1 - doc: | - This is an array holding the sample rotation angle at each - scan point - dimensions: - rank: 1 - dim: [[1, nP]] - kappa(NX_FLOAT): - unit: NX_ANGLE - axis: 1 - doc: | - This is an array holding the kappa angle at each scan point - dimensions: - rank: 1 - dim: [[1, nP]] - phi(NX_FLOAT): - unit: NX_ANGLE - axis: 1 - doc: | - This is an array holding the phi angle at each scan point - dimensions: - rank: 1 - dim: [[1, nP]] - alpha(NX_FLOAT): - unit: NX_ANGLE - doc: | - This holds the inclination angle of the kappa arm. - (NXdata)name: - polar_angle(link): - target: /NXentry/NXinstrument/NXdetector/polar_angle - rotation_angle(link): - target: /NXentry/NXsample/rotation_angle - kappa(link): - target: /NXentry/NXsample/kappa - phi(link): - target: /NXentry/NXsample/phi - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 7fbdffd34ea3c5f17214037a3fac16bc235bfffa0440d3089da8ae2afd01297e -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of points -# -# -# -# raw data from a kappa geometry (CAD4) single crystal diffractometer, extends :ref:`NXxbase` -# -# This is the application definition for raw data from a kappa geometry -# (CAD4) single crystal -# diffractometer. It extends :ref:`NXxbase`, so the full definition is -# the content of :ref:`NXxbase` plus the -# data defined here. -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# The polar_angle (two theta) at each scan point -# -# -# -# -# -# -# -# -# -# This is an array holding the sample rotation angle at each -# scan point -# -# -# -# -# -# -# -# This is an array holding the kappa angle at each scan point -# -# -# -# -# -# -# -# This is an array holding the phi angle at each scan point -# -# -# -# -# -# -# This holds the inclination angle of the kappa arm. -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXxlaue.yaml b/applications/nyaml/NXxlaue.yaml deleted file mode 100644 index b5f032ebea..0000000000 --- a/applications/nyaml/NXxlaue.yaml +++ /dev/null @@ -1,109 +0,0 @@ -category: application -doc: | - raw data from a single crystal laue camera, extends :ref:`NXxrot` - - This is the application definition for raw data from a single crystal laue - camera. It extends :ref:`NXxrot`. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nE: | - Number of energies -type: group -NXxlaue(NXxrot): - (NXentry)entry: - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXxlaue] - (NXinstrument)instrument: - (NXsource)source: - (NXdata)distribution: - data: - doc: | - expect ``signal=1 axes="energy"`` - dimensions: - rank: 1 - dim: [[1, nE]] - wavelength: - unit: NX_WAVELENGTH - dimensions: - rank: 1 - dim: [[1, nE]] - doc: | - This is the wavelength distribution of the beam - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# c280631d42af329b50be95639ad7cb94b58290b3a356ea3dd6fe8ba1b269b9d4 -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of energies -# -# -# -# raw data from a single crystal laue camera, extends :ref:`NXxrot` -# -# This is the application definition for raw data from a single crystal laue -# camera. It extends :ref:`NXxrot`. -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# expect ``signal=1 axes="energy"`` -# -# -# -# -# -# -# -# -# -# -# This is the wavelength distribution of the beam -# -# -# -# -# -# diff --git a/applications/nyaml/NXxlaueplate.yaml b/applications/nyaml/NXxlaueplate.yaml deleted file mode 100644 index c1ba89bc0a..0000000000 --- a/applications/nyaml/NXxlaueplate.yaml +++ /dev/null @@ -1,73 +0,0 @@ -category: application -doc: | - raw data from a single crystal Laue camera, extends :ref:`NXxlaue` - - This is the application definition for raw data from a single crystal Laue - camera with an image plate as a detector. It extends :ref:`NXxlaue`. -type: group -NXxlaueplate(NXxlaue): - (NXentry)entry: - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXxlaueplate] - (NXinstrument)instrument: - (NXdetector)detector: - diameter(NX_FLOAT): - unit: NX_LENGTH - doc: | - The diameter of a cylindrical detector - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e0a1c4365a6a0300f52b3c20ae19efd01e241dc698429f49bf056258803b350f -# -# -# -# -# -# raw data from a single crystal Laue camera, extends :ref:`NXxlaue` -# -# This is the application definition for raw data from a single crystal Laue -# camera with an image plate as a detector. It extends :ref:`NXxlaue`. -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# The diameter of a cylindrical detector -# -# -# -# -# diff --git a/applications/nyaml/NXxnb.yaml b/applications/nyaml/NXxnb.yaml deleted file mode 100644 index da5bbb8fc5..0000000000 --- a/applications/nyaml/NXxnb.yaml +++ /dev/null @@ -1,160 +0,0 @@ -category: application -doc: | - raw data from a single crystal diffractometer, extends :ref:`NXxbase` - - This is the application definition for raw data from - a single crystal diffractometer - measuring in normal beam mode. It extends :ref:`NXxbase`, - so the full definition is the content of - :ref:`NXxbase` plus the data defined here. All angles are - logged in order to support arbitrary scans in - reciprocal space. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points -type: group -NXxnb(NXxbase): - (NXentry)entry: - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXxnb] - (NXinstrument)instrument: - (NXdetector)detector: - polar_angle(NX_FLOAT): - unit: NX_ANGLE - axis: 1 - doc: | - The polar_angle (gamma) of the detector for each scan point. - dimensions: - rank: 1 - dim: [[1, nP]] - tilt_angle(NX_FLOAT): - unit: NX_ANGLE - axis: 1 - doc: | - The angle by which the detector has been tilted out of the - scattering plane. - dimensions: - rank: 1 - dim: [[1, nP]] - (NXsample)sample: - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - axis: 1 - primary: 1 - doc: | - This is an array holding the sample rotation angle at each - scan point - dimensions: - rank: 1 - dim: [[1, nP]] - (NXdata)name: - polar_angle(link): - target: /NXentry/NXinstrument/NXdetector/polar_angle - tilt(link): - target: /NXentry/NXinstrument/NXdetector/tilt - rotation_angle(link): - target: /NXentry/NXsample/rotation_angle - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 481dcbae70cef93a566694326036167fc62bb9ed352ff86be9268466dd46e8de -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of points -# -# -# -# raw data from a single crystal diffractometer, extends :ref:`NXxbase` -# -# This is the application definition for raw data from -# a single crystal diffractometer -# measuring in normal beam mode. It extends :ref:`NXxbase`, -# so the full definition is the content of -# :ref:`NXxbase` plus the data defined here. All angles are -# logged in order to support arbitrary scans in -# reciprocal space. -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# The polar_angle (gamma) of the detector for each scan point. -# -# -# -# -# -# -# -# The angle by which the detector has been tilted out of the -# scattering plane. -# -# -# -# -# -# -# -# -# -# -# This is an array holding the sample rotation angle at each -# scan point -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/applications/nyaml/NXxrot.yaml b/applications/nyaml/NXxrot.yaml deleted file mode 100644 index 7835a5d281..0000000000 --- a/applications/nyaml/NXxrot.yaml +++ /dev/null @@ -1,155 +0,0 @@ -category: application -doc: | - raw data from a rotation camera, extends :ref:`NXxbase` - - This is the application definition for raw data from a rotation camera. - It extends :ref:`NXxbase`, so the full definition is the content of :ref:`NXxbase` - plus the data defined here. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points -type: group -NXxrot(NXxbase): - (NXentry)entry: - definition: - doc: | - Official NeXus NXDL schema to which this file conforms. - enumeration: [NXxrot] - (NXinstrument)instrument: - (NXdetector)detector: - polar_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - The polar_angle (two theta) where the detector is placed. - beam_center_x(NX_FLOAT): - unit: NX_LENGTH - doc: | - This is the x position where the direct beam would hit the detector. This is a - length, not a pixel position, and can be outside of the actual detector. - beam_center_y(NX_FLOAT): - unit: NX_LENGTH - doc: | - This is the y position where the direct beam would hit the detector. This is a - length, not a pixel position, and can be outside of the actual detector. - (NXattenuator)attenuator: - attenuator_transmission(NX_FLOAT): - unit: NX_ANY - (NXsample)sample: - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - axis: 1 - doc: | - This is an array holding the sample rotation start angle at each scan point - dimensions: - rank: 1 - dim: [[1, nP]] - rotation_angle_step(NX_FLOAT): - unit: NX_ANGLE - axis: 1 - doc: | - This is an array holding the step made for sample rotation angle at each scan point - dimensions: - rank: 1 - dim: [[1, nP]] - (NXdata)name: - rotation_angle(link): - target: /NXentry/NXsample/rotation_angle - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# cf93abd05b8a32bdaba2f60ec794a7344630685de4d5566d9358da391f5aa063 -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of points -# -# -# -# raw data from a rotation camera, extends :ref:`NXxbase` -# -# This is the application definition for raw data from a rotation camera. -# It extends :ref:`NXxbase`, so the full definition is the content of :ref:`NXxbase` -# plus the data defined here. -# -# -# -# Official NeXus NXDL schema to which this file conforms. -# -# -# -# -# -# -# -# The polar_angle (two theta) where the detector is placed. -# -# -# -# This is the x position where the direct beam would hit the detector. This is a -# length, not a pixel position, and can be outside of the actual detector. -# -# -# -# This is the y position where the direct beam would hit the detector. This is a -# length, not a pixel position, and can be outside of the actual detector. -# -# -# -# -# -# -# -# -# -# This is an array holding the sample rotation start angle at each scan point -# -# -# -# -# -# This is an array holding the step made for sample rotation angle at each scan point -# -# -# -# -# -# -# -# -# -# diff --git a/base_classes/nyaml/NXaperture.yaml b/base_classes/nyaml/NXaperture.yaml deleted file mode 100644 index dd6994bf4f..0000000000 --- a/base_classes/nyaml/NXaperture.yaml +++ /dev/null @@ -1,221 +0,0 @@ -category: base -doc: | - A beamline aperture. - - Note, the group was incorrectly documented as deprecated, but it is not and it is in common use. -type: group -NXaperture(NXobject): - - # TODO compare with "screens" in SHADOW - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - The reference point of the aperture is its center in the x and y axis. The reference point on the z axis is the - surface of the aperture pointing towards the source. - - In complex (asymmetric) geometries an NXoff_geometry group can be used to provide an unambiguous reference. - - .. image:: aperture/aperture.png - :width: 40% - (NXtransformations): - doc: | - 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. - (NXpositioner): - doc: | - Stores the raw positions of aperture motors. - (NXoff_geometry): - doc: | - Use this group to describe the shape of the aperture - (NXgeometry): - deprecated: | - Use the field `depends_on` and :ref:`NXtransformations` to position the aperture and :ref:`NXoff_geometry` to describe its shape - doc: | - location and shape of aperture - - .. TODO: documentation needs improvement, contributions welcome - - * description of terms is poor and leaves much to interpretation - * Describe what is meant by translation _here_ and ... - * Similar throughout base classes - * Some base classes do this much better - * Such as where is the gap written? - BLADE_GEOMETRY(NXgeometry): - deprecated: | - Use :ref:`NXoff_geometry` instead to describe the shape of the aperture - doc: | - location and shape of each blade - material: - - # TODO Uniformity problem, "type" is used elsewhere for same context - doc: | - Absorbing material of the aperture - description: - doc: | - Description of aperture - shape: - doc: | - Shape of the aperture. - enumeration: [straight slit, curved slit, pinhole, circle, square, hexagon, octagon, bladed, open, grid] - size(NX_NUMBER): - unit: NX_LENGTH - doc: | - The relevant dimension for the aperture, i.e. slit width, pinhole and iris - diameter - (NXnote): - doc: | - describe any additional information in a note - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# ddea515e1df1292df2a7176d04f026a04c9eef91abb7173bcbe25fa0e01a6a12 -# -# -# -# -# -# -# A beamline aperture. -# -# Note, the group was incorrectly documented as deprecated, but it is not and it is in common use. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# The reference point of the aperture is its center in the x and y axis. The reference point on the z axis is the -# surface of the aperture pointing towards the source. -# -# In complex (asymmetric) geometries an NXoff_geometry group can be used to provide an unambiguous reference. -# -# .. image:: aperture/aperture.png -# :width: 40% -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# -# Stores the raw positions of aperture motors. -# -# -# -# -# Use this group to describe the shape of the aperture -# -# -# -# -# location and shape of aperture -# -# .. TODO: documentation needs improvement, contributions welcome -# -# * description of terms is poor and leaves much to interpretation -# * Describe what is meant by translation _here_ and ... -# * Similar throughout base classes -# * Some base classes do this much better -# * Such as where is the gap written? -# -# -# -# -# location and shape of each blade -# -# -# Absorbing material of the aperture -# -# -# Description of aperture -# -# -# -# Shape of the aperture. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The relevant dimension for the aperture, i.e. slit width, pinhole and iris -# diameter -# -# -# describe any additional information in a note -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# diff --git a/base_classes/nyaml/NXattenuator.yaml b/base_classes/nyaml/NXattenuator.yaml deleted file mode 100644 index 954755f9ce..0000000000 --- a/base_classes/nyaml/NXattenuator.yaml +++ /dev/null @@ -1,206 +0,0 @@ -category: base -doc: | - A device that reduces the intensity of a beam by attenuation. - - If uncertain whether to use :ref:`NXfilter` (band-pass filter) - or :ref:`NXattenuator` (reduces beam intensity), then choose - :ref:`NXattenuator`. -type: group -NXattenuator(NXobject): - - # TODO compare with SHADOW definition "screen" - # TODO SHADOW: https://github.com/oasys-kit/shadow3 - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Distance from sample. Note, it is recommended to use NXtransformations instead. - type: - doc: | - Type or composition of attenuator, e.g. polythene - thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - Thickness of attenuator along beam direction - scattering_cross_section(NX_FLOAT): - unit: NX_CROSS_SECTION - doc: | - Scattering cross section (coherent+incoherent) - absorption_cross_section(NX_FLOAT): - unit: NX_CROSS_SECTION - doc: | - Absorption cross section - attenuator_transmission(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - The nominal amount of the beam that gets through - (transmitted intensity)/(incident intensity) - status: - doc: | - In or out or moving of the beam - \@time: - type: NX_DATE_TIME - doc: | - time stamp for this observation - enumeration: [in, out, moving] - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - The reference point of the attenuator is its center in the x and y axis. The reference point on the z axis is the - surface of the attenuator pointing towards the source. - - In complex (asymmetic) geometries an NXoff_geometry group can be used to provide an unambiguous reference. - - .. image:: attenuator/attenuator.png - :width: 40% - (NXtransformations): - doc: | - 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. - shape(NXoff_geometry): - doc: | - Shape of this component. Particulary useful to define the origin for position and orientation in non-standard cases. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2a98b9445482f7224d2131e0af674acad938177775e4eca9be678542b70fe08e -# -# -# -# -# -# -# A device that reduces the intensity of a beam by attenuation. -# -# If uncertain whether to use :ref:`NXfilter` (band-pass filter) -# or :ref:`NXattenuator` (reduces beam intensity), then choose -# :ref:`NXattenuator`. -# -# -# -# -# Distance from sample. Note, it is recommended to use NXtransformations instead. -# -# -# Type or composition of attenuator, e.g. polythene -# -# -# Thickness of attenuator along beam direction -# -# -# Scattering cross section (coherent+incoherent) -# -# -# Absorption cross section -# -# -# -# The nominal amount of the beam that gets through -# (transmitted intensity)/(incident intensity) -# -# -# -# In or out or moving of the beam -# -# time stamp for this observation -# -# -# -# -# -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# The reference point of the attenuator is its center in the x and y axis. The reference point on the z axis is the -# surface of the attenuator pointing towards the source. -# -# In complex (asymmetic) geometries an NXoff_geometry group can be used to provide an unambiguous reference. -# -# .. image:: attenuator/attenuator.png -# :width: 40% -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# -# Shape of this component. Particulary useful to define the origin for position and orientation in non-standard cases. -# -# -# diff --git a/base_classes/nyaml/NXbeam.yaml b/base_classes/nyaml/NXbeam.yaml deleted file mode 100644 index 8f66fd0c49..0000000000 --- a/base_classes/nyaml/NXbeam.yaml +++ /dev/null @@ -1,908 +0,0 @@ -category: base -doc: | - 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. -symbols: - doc: | - These symbols coordinate datasets with the same shape. - nP: | - Number of scan points. - m: | - Number of channels in the incident beam spectrum, if known - c: | - Number of moments representing beam divergence (x, y, xy, etc.) -type: group -NXbeam(NXobject): - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Distance from sample. Note, it is recommended to use NXtransformations instead. - incident_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - 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. - dimensions: - rank: 1 - dim: [[1, m]] - incident_energy_spread(NX_NUMBER): - unit: NX_ENERGY - doc: | - 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. - incident_energy_weights(NX_NUMBER): - unit: NX_ENERGY - doc: | - In the case of a polychromatic beam this is an array of length m of the relative - weights of the corresponding energies in incident_energy. In the case of a - polychromatic beam that varies shot-to-shot, this is a 2D array of dimensions np - by m (slow to fast) of the relative weights of the corresponding energies in - incident_energy. - final_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - Energy carried by each particle of the beam on leaving the beamline component - dimensions: - rank: 1 - dim: [[1, m]] - energy_transfer(NX_FLOAT): - unit: NX_ENERGY - doc: | - Change in particle energy caused by the beamline component - dimensions: - rank: 1 - dim: [[1, m]] - incident_wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - 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 - incident_wavelength_weights(NX_FLOAT): - doc: | - In the case of a polychromatic beam this is an array of - length **m** of the relative weights of the corresponding - wavelengths in ``incident_wavelength``. - - In the case of a polychromatic beam that varies shot-to- - shot, this is a 2D array of dimensions **nP** by **m** - (slow to fast) of the relative weights of the - corresponding wavelengths in ``incident_wavelength``. - incident_wavelength_spread(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - The wavelength spread FWHM for the corresponding - wavelength(s) in incident_wavelength. - - In the case of shot-to-shot variation in the wavelength - spread, this is a 2D array of dimension **nP** by - **m** (slow to fast) of the spreads of the - corresponding wavelengths in incident_wavelength. - dimensions: - rank: 1 - dim: [[1, nP]] - incident_beam_divergence(NX_FLOAT): - unit: NX_ANGLE - doc: | - Beam crossfire in degrees parallel to the laboratory X axis - - The dimension **c** is a series of moments of that represent - the standard uncertainty (e.s.d.) of the directions of - of the beam. The first and second moments are in the XZ and YZ - planes around the mean source beam direction, respectively. - - Further moments in **c** characterize co-variance terms, so - the next moment is the product of the first two, and so on. - dimensions: - rank: 2 - dim: [[1, nP], [2, c]] - extent(NX_FLOAT): - unit: NX_LENGTH - doc: | - Size of the beam entering this component. Note this represents - a rectangular beam aperture, and values represent FWHM. - If applicable, the first dimension shall be the horizontal extent - and the second dimension shall be the vertical extent. - dimensions: - rank: 2 - dim: [[1, nP], [2, 2]] - final_wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - Wavelength on leaving beamline component - dimensions: - rank: 1 - dim: [[1, m]] - incident_polarization(NX_NUMBER): - unit: NX_ANY - doc: | - Polarization vector on entering beamline component - dimensions: - rank: 2 - dim: [[1, nP], [2, 2]] - \@units: - type: NX_CHAR - doc: | - The units for this observable are not included in the NIAC list. - Responsibility on correct formatting and parsing is handed to the user - by using `NX_ANY`. Correct parsing can still be implemented by using - this attribute. - - | Fill with: - - * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). - * The unit unidata name if the unit has a name (Example: farad for capacitance). - * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and - does not have a name. - - Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). - Here: SI units are V2/m2. - final_polarization(NX_NUMBER): - unit: NX_ANY - doc: | - Polarization vector on leaving beamline component - dimensions: - rank: 2 - dim: [[1, nP], [2, 2]] - \@units: - type: NX_CHAR - doc: | - The units for this observable are not included in the NIAC list. - Responsibility on correct formatting and parsing is handed to the user - by using `NX_ANY`. Correct parsing can still be implemented by using - this attribute. - - | Fill with: - - * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). - * The unit unidata name if the unit has a name (Example: farad for capacitance). - * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and - does not have a name. - - Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). - Here: SI units are V2/m2. - incident_polarization_stokes(NX_NUMBER): - unit: NX_ANY - doc: | - Polarization vector on entering beamline component using Stokes notation - - The Stokes parameters are four components labelled I,Q,U,V or S_0,S_1,S_2,S_3. - These are defined with the standard Nexus coordinate frame unless it is - overridden by an NXtransformations field pointed to by a depends_on attribute. - The last component, describing the circular polarization state, is positive - for a right-hand circular state - that is the electric field vector rotates - clockwise at the sample and over time when observed from the source. - - I (S_0) is the beam intensity (often normalized to 1). Q, U, and V scale - linearly with the total degree of polarization, and indicate the relative - magnitudes of the pure linear and circular orientation contributions. - - Q (S_1) is linearly polarized along the x axis (Q > 0) or y axis (Q < 0). - - U (S_2) is linearly polarized along the x==y axis (U > 0) or the - -x==y axis (U < 0). - - V (S_3) is circularly polarized. V > 0 when the electric field vector rotates - clockwise at the sample with respect to time when observed from the source; - V < 0 indicates the opposite rotation. - dimensions: - rank: 2 - dim: [[1, nP], [2, 4]] - final_polarization_stokes(NX_NUMBER): - unit: NX_ANY - doc: | - Polarization vector on leaving beamline component using Stokes notation - (see incident_polarization_stokes). - dimensions: - rank: 2 - dim: [[1, nP], [2, 4]] - final_wavelength_spread(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - Wavelength spread FWHM of beam leaving this component - dimensions: - rank: 1 - dim: [[1, m]] - final_beam_divergence(NX_FLOAT): - unit: NX_ANGLE - doc: | - Divergence FWHM of beam leaving this component - dimensions: - rank: 2 - dim: [[1, nP], [2, 2]] - flux(NX_FLOAT): - unit: NX_FLUX - doc: | - flux incident on beam plane area - dimensions: - rank: 1 - dim: [[1, nP]] - pulse_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - Energy of a single pulse at the diagnostic point - average_power(NX_FLOAT): - unit: NX_POWER - doc: | - Average power at the diagnostic point - fluence(NX_FLOAT): - unit: NX_ANY - doc: | - Incident fluence at the diagnostic point - \@units: - type: NX_CHAR - doc: | - Here: SI units are 'J/m2', customary 'mJ/cm2'. - pulse_duration(NX_FLOAT): - unit: NX_TIME - doc: | - FWHM duration of the pulses at the diagnostic point - pulse_delay(NX_FLOAT): - unit: NX_TIME - doc: | - Delay time between two pulses of a pulsed beam. - \@reference_beam: - type: NX_CHAR - doc: | - A reference to the beam in relation to which the delay is. - frog_trace(NX_FLOAT): - doc: | - FROG trace of the pulse. - dimensions: - rank: 2 - dim: [[1, nx], [2, ny]] - frog_delays(NX_FLOAT): - unit: NX_TIME - doc: | - Horizontal axis of a FROG trace, i.e. delay. - dimensions: - rank: 1 - dim: [[1, nx]] - frog_frequencies(NX_FLOAT): - unit: NX_FREQUENCY - doc: | - Vertical axis of a FROG trace, i.e. frequency. - dimensions: - rank: 1 - dim: [[1, ny]] - chirp_type(NX_CHAR): - doc: | - The type of chirp implemented - chirp_GDD(NX_FLOAT): - unit: NX_TIME - doc: | - Group delay dispersion of the pulse for linear chirp - previous_device: - doc: | - Indicates the beam device from which this beam originates. - This defines, whether the beam in an "input" or "output" beam. - next_device: - doc: | - Gives the beam device which this beam will interact with next. - (NXdata): - doc: | - Distribution of beam with respect to relevant variable e.g. wavelength. This is mainly - useful for simulations which need to store plottable information at each beamline - component. - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - exists: ['min', '0'] - doc: | - The NeXus coordinate system defines the Z axis to be along the nominal beam - direction. This is the same as the McStas coordinate system (see :ref:`Design-CoordinateSystem`). - However, the additional transformations needed to represent an altered beam - direction can be provided using this depends_on field that contains the path - to a NXtransformations group. This could represent redirection of the beam, - or a refined beam direction. - (NXtransformations): - exists: ['min', '0'] - doc: | - Direction (and location) for the beam. The location of the beam can be given by - any point which it passes through as its offset attribute. - DIRECTION(NX_NUMBER): - nameType: any - unit: NX_TRANSFORMATION - doc: | - Direction of beam vector, its value is ignored. If missing, then the beam direction is defined as [0,0,1] - and passes through the origin - \@transformation_type: - enumeration: [translation] - \@vector: - type: NX_NUMBER - doc: | - Three values that define the direction of beam vector - \@offset: - type: NX_NUMBER - doc: | - Three values that define the location of a point through which the beam passes - \@depends_on: - type: NX_CHAR - doc: | - Points to the path to a field defining the location on which this - depends or the string "." for origin. - reference_plane(NX_NUMBER): - nameType: any - unit: NX_TRANSFORMATION - doc: | - Direction of normal to reference plane used to measure azimuth relative to the beam, its value is ignored. - This also defines the parallel and perpendicular components of the beam's polarization. - If missing, then the reference plane normal is defined as [0,1,0] and passes through the origin - \@transformation_type: - enumeration: [translation] - \@vector: - type: NX_NUMBER - doc: | - Three values that define the direction of reference plane normal - \@offset: - type: NX_NUMBER - doc: | - Not required as beam direction offset locates the plane - \@depends_on: - type: NX_CHAR - doc: | - Points to the path to a field defining the location on which this - depends or the string "." for origin. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 0a0f638a0e365626f010fb2bb8978aa3675f952b03f7bb56b5821155e8a66916 -# -# -# -# -# -# -# These symbols coordinate datasets with the same shape. -# -# -# Number of scan points. -# -# -# Number of channels in the incident beam spectrum, if known -# -# -# Number of moments representing beam divergence (x, y, xy, etc.) -# -# -# -# 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. -# -# -# Distance from sample. Note, it is recommended to use NXtransformations instead. -# -# -# -# Energy carried by each particle of the beam on entering the beamline component. -# -# In the case of a monochromatic beam this is the scalar energy. -# Several other use cases are permitted, depending on the -# presence of other incident_energy_X fields. -# -# * In the case of a polychromatic beam this is an array of length m of energies, with the relative weights in incident_energy_weights. -# * In the case of a monochromatic beam that varies shot-to-shot, this is an array of energies, one for each recorded shot. -# Here, incident_energy_weights and incident_energy_spread are not set. -# * In the case of a polychromatic beam that varies shot-to-shot, -# this is an array of length m with the relative weights in incident_energy_weights as a 2D array. -# * In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, -# this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_energy_weights as a 2D array. -# -# Note, variants are a good way to represent several of these use cases in a single dataset, -# e.g. if a calibrated, single-value energy value is available along with the original spectrum from which it was calibrated. -# -# -# -# -# -# -# -# The energy spread FWHM for the corresponding energy(ies) in incident_energy. In the case of shot-to-shot variation in -# the energy spread, this is a 2D array of dimension nP by m -# (slow to fast) of the spreads of the corresponding -# wavelength in incident_wavelength. -# -# -# -# -# In the case of a polychromatic beam this is an array of length m of the relative -# weights of the corresponding energies in incident_energy. In the case of a -# polychromatic beam that varies shot-to-shot, this is a 2D array of dimensions np -# by m (slow to fast) of the relative weights of the corresponding energies in -# incident_energy. -# -# -# -# Energy carried by each particle of the beam on leaving the beamline component -# -# -# -# -# -# Change in particle energy caused by the 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 <Design-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 polychromatic beam this is an array of -# length **m** of the relative weights of the corresponding -# wavelengths in ``incident_wavelength``. -# -# In the case of a polychromatic beam that varies shot-to- -# shot, this is a 2D array of dimensions **nP** by **m** -# (slow to fast) of the relative weights of the -# corresponding wavelengths in ``incident_wavelength``. -# -# -# -# -# The wavelength spread FWHM for the corresponding -# wavelength(s) in incident_wavelength. -# -# In the case of shot-to-shot variation in the wavelength -# spread, this is a 2D array of dimension **nP** by -# **m** (slow to fast) of the spreads of the -# corresponding wavelengths in incident_wavelength. -# -# -# -# -# -# -# -# Beam crossfire in degrees parallel to the laboratory X axis -# -# The dimension **c** is a series of moments of that represent -# the standard uncertainty (e.s.d.) of the directions of -# of the beam. The first and second moments are in the XZ and YZ -# planes around the mean source beam direction, respectively. -# -# Further moments in **c** characterize co-variance terms, so -# the next moment is the product of the first two, and so on. -# -# -# -# -# -# -# -# -# Size of the beam entering this component. Note this represents -# a rectangular beam aperture, and values represent FWHM. -# If applicable, the first dimension shall be the horizontal extent -# and the second dimension shall be the vertical extent. -# -# -# -# -# -# -# -# Wavelength on leaving beamline component -# -# -# -# -# -# Polarization vector on entering beamline component -# -# -# -# -# -# -# The units for this observable are not included in the NIAC list. -# Responsibility on correct formatting and parsing is handed to the user -# by using `NX_ANY`. Correct parsing can still be implemented by using -# this attribute. -# -# | Fill with: -# -# * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). -# * The unit unidata name if the unit has a name (Example: farad for capacitance). -# * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and -# does not have a name. -# -# Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). -# Here: SI units are V2/m2. -# -# -# -# -# Polarization vector on leaving beamline component -# -# -# -# -# -# -# The units for this observable are not included in the NIAC list. -# Responsibility on correct formatting and parsing is handed to the user -# by using `NX_ANY`. Correct parsing can still be implemented by using -# this attribute. -# -# | Fill with: -# -# * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). -# * The unit unidata name if the unit has a name (Example: farad for capacitance). -# * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and -# does not have a name. -# -# Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). -# Here: SI units are V2/m2. -# -# -# -# -# -# Polarization vector on entering beamline component using Stokes notation -# -# The Stokes parameters are four components labelled I,Q,U,V or S_0,S_1,S_2,S_3. -# These are defined with the standard Nexus coordinate frame unless it is -# overridden by an NXtransformations field pointed to by a depends_on attribute. -# The last component, describing the circular polarization state, is positive -# for a right-hand circular state - that is the electric field vector rotates -# clockwise at the sample and over time when observed from the source. -# -# I (S_0) is the beam intensity (often normalized to 1). Q, U, and V scale -# linearly with the total degree of polarization, and indicate the relative -# magnitudes of the pure linear and circular orientation contributions. -# -# Q (S_1) is linearly polarized along the x axis (Q > 0) or y axis (Q < 0). -# -# U (S_2) is linearly polarized along the x==y axis (U > 0) or the -# -x==y axis (U < 0). -# -# V (S_3) is circularly polarized. V > 0 when the electric field vector rotates -# clockwise at the sample with respect to time when observed from the source; -# V < 0 indicates the opposite rotation. -# -# -# -# -# -# -# -# -# Polarization vector on leaving beamline component using Stokes notation -# (see incident_polarization_stokes). -# -# -# -# -# -# -# -# Wavelength spread FWHM of beam leaving this component -# -# -# -# -# -# Divergence FWHM of beam leaving this component -# -# -# -# -# -# -# flux incident on beam plane area -# -# -# -# -# -# -# Energy of a single pulse at the diagnostic point -# -# -# -# -# Average power at the diagnostic point -# -# -# -# -# Incident fluence at the diagnostic point -# -# -# -# Here: SI units are 'J/m2', customary 'mJ/cm2'. -# -# -# -# -# -# FWHM duration of the pulses at the diagnostic point -# -# -# -# -# Delay time between two pulses of a pulsed beam. -# -# -# -# A reference to the beam in relation to which the delay is. -# -# -# -# -# -# FROG trace of the pulse. -# -# -# -# -# -# -# -# -# Horizontal axis of a FROG trace, i.e. delay. -# -# -# -# -# -# -# -# Vertical axis of a FROG trace, i.e. frequency. -# -# -# -# -# -# -# -# The type of chirp implemented -# -# -# -# -# Group delay dispersion of the pulse for linear chirp -# -# -# -# -# Indicates the beam device from which this beam originates. -# This defines, whether the beam in an "input" or "output" beam. -# -# -# -# -# Gives the beam device which this beam will interact with next. -# -# -# -# -# Distribution of beam with respect to relevant variable e.g. wavelength. This is mainly -# useful for simulations which need to store plottable information at each beamline -# component. -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# -# The NeXus coordinate system defines the Z axis to be along the nominal beam -# direction. This is the same as the McStas coordinate system (see :ref:`Design-CoordinateSystem`). -# However, the additional transformations needed to represent an altered beam -# direction can be provided using this depends_on field that contains the path -# to a NXtransformations group. This could represent redirection of the beam, -# or a refined beam direction. -# -# -# -# -# -# Direction (and location) for the beam. The location of the beam can be given by -# any point which it passes through as its offset attribute. -# -# -# -# Direction of beam vector, its value is ignored. If missing, then the beam direction is defined as [0,0,1] -# and passes through the origin -# -# -# -# -# -# -# -# -# Three values that define the direction of beam vector -# -# -# -# -# Three values that define the location of a point through which the beam passes -# -# -# -# -# Points to the path to a field defining the location on which this -# depends or the string "." for origin. -# -# -# -# -# -# Direction of normal to reference plane used to measure azimuth relative to the beam, its value is ignored. -# This also defines the parallel and perpendicular components of the beam's polarization. -# If missing, then the reference plane normal is defined as [0,1,0] and passes through the origin -# -# -# -# -# -# -# -# -# Three values that define the direction of reference plane normal -# -# -# -# -# Not required as beam direction offset locates the plane -# -# -# -# -# Points to the path to a field defining the location on which this -# depends or the string "." for origin. -# -# -# -# -# \ No newline at end of file diff --git a/base_classes/nyaml/NXbeam_stop.yaml b/base_classes/nyaml/NXbeam_stop.yaml deleted file mode 100644 index e897fc7aca..0000000000 --- a/base_classes/nyaml/NXbeam_stop.yaml +++ /dev/null @@ -1,207 +0,0 @@ -category: base -doc: | - A device that blocks the beam completely, usually to protect a detector. - - Beamstops and their positions are important for SANS - and SAXS experiments. -type: group -NXbeam_stop(NXobject): - (NXgeometry): - deprecated: | - Use the field `depends_on` and :ref:`NXtransformations` to position the beamstop and NXoff_geometry to describe its shape instead - doc: | - engineering shape, orientation and position of the beam stop. - description: - doc: | - description of beamstop - enumeration: [circular, rectangular] - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the beam line component - (NXcylindrical_geometry): - exists: ['min', '0'] - doc: | - This group is an alternative to NXoff_geometry for describing the shape - of the beam stop. - size(NX_FLOAT): - unit: NX_LENGTH - doc: | - Size of beamstop. If this is not sufficient to describe the beam stop use - NXoff_geometry instead. - x(NX_FLOAT): - unit: NX_LENGTH - doc: | - x position of the beamstop in relation to the detector. - Note, it is recommended to use NXtransformations instead. - y(NX_FLOAT): - unit: NX_LENGTH - doc: | - y position of the beamstop in relation to the detector. - Note, it is recommended to use NXtransformations instead. - distance_to_detector(NX_FLOAT): - unit: NX_LENGTH - doc: | - distance of the beamstop to the detector. - Note, it is recommended to use NXtransformations instead. - status: - enumeration: [in, out] - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - The reference point of the beam stop is its center in the x and y axis. The reference point on the z axis is the - surface of the beam stop pointing towards the source. - - .. image:: beam_stop/beam_stop.png - :width: 40% - (NXtransformations): - doc: | - 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 6409e7b6835999606e6a6153d3efb26f3cb846d31acc9e84a090f2d4ef0068d3 -# -# -# -# -# -# -# A device that blocks the beam completely, usually to protect a detector. -# -# Beamstops and their positions are important for SANS -# and SAXS experiments. -# -# -# engineering shape, orientation and position of the beam stop. -# -# -# description of beamstop -# -# -# -# -# -# -# -# This group describes the shape of the beam line component -# -# -# -# -# This group is an alternative to NXoff_geometry for describing the shape -# of the beam stop. -# -# -# -# -# Size of beamstop. If this is not sufficient to describe the beam stop use -# NXoff_geometry instead. -# -# -# -# -# x position of the beamstop in relation to the detector. -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# y position of the beamstop in relation to the detector. -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# distance of the beamstop to the detector. -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# -# -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# The reference point of the beam stop is its center in the x and y axis. The reference point on the z axis is the -# surface of the beam stop pointing towards the source. -# -# .. image:: beam_stop/beam_stop.png -# :width: 40% -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# diff --git a/base_classes/nyaml/NXbending_magnet.yaml b/base_classes/nyaml/NXbending_magnet.yaml deleted file mode 100644 index f6789a01f7..0000000000 --- a/base_classes/nyaml/NXbending_magnet.yaml +++ /dev/null @@ -1,210 +0,0 @@ -category: base -doc: | - A bending magnet -type: group -NXbending_magnet(NXobject): - critical_energy(NX_FLOAT): - unit: NX_ENERGY - bending_radius(NX_FLOAT): - unit: NX_LENGTH - magnetic_field(NX_FLOAT): - unit: NX_CURRENT - doc: | - strength of magnetic field of dipole magnets - accepted_photon_beam_divergence(NX_FLOAT): - unit: NX_LENGTH - doc: | - An array of four numbers giving X+, X-, Y+ and Y- half divergence - source_distance_x(NX_FLOAT): - unit: NX_LENGTH - doc: | - Distance of source point from particle beam waist in X (horizontal) direction. - Note, it is recommended to use NXtransformations instead to place component. - source_distance_y(NX_FLOAT): - unit: NX_LENGTH - doc: | - Distance of source point from particle beam waist in Y (vertical) direction. - Note, it is recommended to use NXtransformations instead to place component. - divergence_x_plus(NX_FLOAT): - unit: NX_ANGLE - doc: | - Accepted photon beam divergence in X+ (horizontal outboard) direction. - Note that divergence_x_plus+divergence_x_minus is the total horizontal beam divergence. - divergence_x_minus(NX_FLOAT): - unit: NX_ANGLE - doc: | - Accepted photon beam divergence in X- (horizontal inboard) direction. - Note that divergence_x_plus+divergence_x_minus is the total horizontal beam divergence. - divergence_y_plus(NX_FLOAT): - unit: NX_ANGLE - doc: | - Accepted photon beam divergence in Y+ (vertical upward) direction. - Note that divergence_y_plus+divergence_y_minus is the total vertical beam divergence. - divergence_y_minus(NX_FLOAT): - unit: NX_ANGLE - doc: | - Accepted photon beam divergence in Y- (vertical downward) direction. - Note that divergence_y_plus+divergence_y_minus is the total vertical beam divergence. - spectrum(NXdata): - doc: | - bending magnet spectrum - (NXgeometry): - deprecated: | - Use the field `depends_on` and :ref:`NXtransformations` to position the bending magnet and NXoff_geometry to describe its shape instead - doc: | - "Engineering" position of bending magnet - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the beam line component - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a bending magnet. - (NXtransformations): - doc: | - 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a950d876f5209fa803636b94e4dd2189e4648464be91478f54dfe5617971af47 -# -# -# -# -# -# A bending magnet -# -# -# -# strength of magnetic field of dipole magnets -# -# -# -# An array of four numbers giving X+, X-, Y+ and Y- half divergence -# -# -# -# -# Distance of source point from particle beam waist in X (horizontal) direction. -# Note, it is recommended to use NXtransformations instead to place component. -# -# -# -# -# Distance of source point from particle beam waist in Y (vertical) direction. -# Note, it is recommended to use NXtransformations instead to place component. -# -# -# -# -# Accepted photon beam divergence in X+ (horizontal outboard) direction. -# Note that divergence_x_plus+divergence_x_minus is the total horizontal beam divergence. -# -# -# -# -# Accepted photon beam divergence in X- (horizontal inboard) direction. -# Note that divergence_x_plus+divergence_x_minus is the total horizontal beam divergence. -# -# -# -# -# Accepted photon beam divergence in Y+ (vertical upward) direction. -# Note that divergence_y_plus+divergence_y_minus is the total vertical beam divergence. -# -# -# -# -# Accepted photon beam divergence in Y- (vertical downward) direction. -# Note that divergence_y_plus+divergence_y_minus is the total vertical beam divergence. -# -# -# bending magnet spectrum -# "Engineering" position of bending magnet -# -# -# This group describes the shape of the beam line component -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a bending magnet. -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# diff --git a/base_classes/nyaml/NXcapillary.yaml b/base_classes/nyaml/NXcapillary.yaml deleted file mode 100644 index 666f9e8411..0000000000 --- a/base_classes/nyaml/NXcapillary.yaml +++ /dev/null @@ -1,163 +0,0 @@ -category: base -doc: | - A capillary lens to focus the X-ray beam. - - Based on information provided by Gerd Wellenreuther (DESY). -type: group -NXcapillary(NXobject): - type(NX_CHAR): - doc: | - Type of the capillary - enumeration: [single_bounce, polycapillary, conical_capillary] - manufacturer(NX_CHAR): - doc: | - The manufacturer of the capillary. This is actually important as - it may have an impact on performance. - maximum_incident_angle(NX_FLOAT): - unit: NX_ANGLE - accepting_aperture(NX_FLOAT): - unit: NX_ANGLE - (NXdata)gain: - doc: | - The gain of the capillary as a function of energy - (NXdata)transmission: - doc: | - The transmission of the capillary as a function of energy - working_distance(NX_FLOAT): - unit: NX_LENGTH - focal_size(NX_FLOAT): - doc: | - The focal size in FWHM - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a capillary lens. - (NXtransformations): - doc: | - 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 1765a1852f8237999abfde5d684497a011fe9ad05cfc99d43ada4686763ac661 -# -# -# -# -# -# -# A capillary lens to focus the X-ray beam. -# -# Based on information provided by Gerd Wellenreuther (DESY). -# -# -# Type of the capillary -# -# -# -# -# -# -# -# -# The manufacturer of the capillary. This is actually important as -# it may have an impact on performance. -# -# -# -# -# -# -# The gain of the capillary as a function of energy -# -# -# -# -# The transmission of the capillary as a function of energy -# -# -# -# -# -# The focal size in FWHM -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a capillary lens. -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# diff --git a/base_classes/nyaml/NXcite.yaml b/base_classes/nyaml/NXcite.yaml deleted file mode 100644 index 940a617a95..0000000000 --- a/base_classes/nyaml/NXcite.yaml +++ /dev/null @@ -1,112 +0,0 @@ -category: base -doc: | - A literature reference - - Definition to include references for example for detectors, - manuals, instruments, acquisition or analysis software used. - - The idea would be to include this in the relevant NeXus object: - :ref:`NXdetector` for detectors, :ref:`NXinstrument` for instruments, etc. -type: group -NXcite(NXobject): - description(NX_CHAR): - doc: | - This should describe the reason for including this reference. - For example: The dataset in this group was normalised using the method - which is described in detail in this reference. - url(NX_CHAR): - doc: | - URL referencing the document or data. - doi(NX_CHAR): - doc: | - DOI referencing the document or data. - endnote(NX_CHAR): - doc: | - Bibliographic reference data in EndNote format. - bibtex(NX_CHAR): - doc: | - Bibliographic reference data in BibTeX format. - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2619ff55aa3fd8a9b6159e32348fbbc9f6d5770c343505e1c3be728df9302148 -# -# -# -# -# -# A literature reference -# -# Definition to include references for example for detectors, -# manuals, instruments, acquisition or analysis software used. -# -# The idea would be to include this in the relevant NeXus object: -# :ref:`NXdetector` for detectors, :ref:`NXinstrument` for instruments, etc. -# -# -# -# This should describe the reason for including this reference. -# For example: The dataset in this group was normalised using the method -# which is described in detail in this reference. -# -# -# -# URL referencing the document or data. -# -# -# DOI referencing the document or data. -# -# -# Bibliographic reference data in EndNote format. -# -# -# Bibliographic reference data in BibTeX format. -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# diff --git a/base_classes/nyaml/NXcollection.yaml b/base_classes/nyaml/NXcollection.yaml deleted file mode 100644 index 980f65a571..0000000000 --- a/base_classes/nyaml/NXcollection.yaml +++ /dev/null @@ -1,102 +0,0 @@ -category: base - -# The ignoreExtra* attributes are used in the definition to -# avoid warning messages that would be generated from -# unexpected groups, fields, and attributes. -# Since no groups or attributes are declared here, _every_ -# child of this class would generate a warning message without this -# attribute being set to "true". -doc: | - An unvalidated set of terms, such as the description of a beam line. - - Use :ref:`NXcollection` to gather together any set of terms. - The original suggestion is to use this as a container - class for the description of a beamline. - - For NeXus validation, :ref:`NXcollection` will always generate - a warning since it is always an optional group. - Anything (groups, fields, or attributes) placed in - an :ref:`NXcollection` group will not be validated. -type: group -ignoreExtraGroups: true -ignoreExtraFields: true -ignoreExtraAttributes: true -NXcollection(NXobject): - - # any content is purely optional - - # NOTE - # ===== - # NXcollection is an unvalidated class, do not add any subgroups. - # See: https://github.com/nexusformat/definitions/issues/259 - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# fb3c463eb7446d00c48f2401b37b4243875c3675c4bb1c12846f78349ffd26d4 -# -# -# -# -# -# -# -# -# An unvalidated set of terms, such as the description of a beam line. -# -# Use :ref:`NXcollection` to gather together any set of terms. -# The original suggestion is to use this as a container -# class for the description of a beamline. -# -# For NeXus validation, :ref:`NXcollection` will always generate -# a warning since it is always an optional group. -# Anything (groups, fields, or attributes) placed in -# an :ref:`NXcollection` group will not be validated. -# -# -# -# -# -# diff --git a/base_classes/nyaml/NXcollimator.yaml b/base_classes/nyaml/NXcollimator.yaml deleted file mode 100644 index 32bbc36b9d..0000000000 --- a/base_classes/nyaml/NXcollimator.yaml +++ /dev/null @@ -1,196 +0,0 @@ -category: base -doc: | - A beamline collimator. -type: group -NXcollimator(NXobject): - (NXgeometry): - deprecated: | - Use the field `depends_on` and :ref:`NXtransformations` to position the collimator and NXoff_geometry to describe its shape instead - doc: | - position, shape and size - type: - enumeration: [Soller, radial, oscillating, honeycomb] - soller_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Angular divergence of Soller collimator - divergence_x(NX_FLOAT): - unit: NX_ANGLE - doc: | - divergence of collimator in local x direction - divergence_y(NX_FLOAT): - unit: NX_ANGLE - doc: | - divergence of collimator in local y direction - frequency(NX_FLOAT): - unit: NX_FREQUENCY - doc: | - Frequency of oscillating collimator - (NXlog)frequency_log: - doc: | - Log of frequency - blade_thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - blade thickness - blade_spacing(NX_FLOAT): - unit: NX_LENGTH - doc: | - blade spacing - absorbing_material: - doc: | - name of absorbing material - transmitting_material: - doc: | - name of transmitting material - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the beam line component - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - 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. - - Assuming a collimator with a "flat" entry surface, the reference plane is the plane which contains this surface. The reference - point of the collimator in the x and y axis is the centre of the collimator entry surface on that plane. The reference plane is orthogonal - to the z axis and the location of this plane is the reference point on the z axis. The collimator faces negative z values. - - .. image:: collimator/collimator.png - :width: 40% - (NXtransformations): - doc: | - 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8e5c9e0c05ff67873242ca099a2feb86dcb8a03f4bdff630a3905f82b50cc6e2 -# -# -# -# -# -# A beamline collimator. -# -# position, shape and size -# -# -# -# -# -# -# -# -# -# -# Angular divergence of Soller collimator -# -# -# divergence of collimator in local x direction -# -# -# divergence of collimator in local y direction -# -# -# Frequency of oscillating collimator -# -# -# Log of frequency -# -# -# blade thickness -# -# -# blade spacing -# -# -# name of absorbing material -# -# -# name of transmitting material -# -# -# -# This group describes the shape of the beam line component -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# Assuming a collimator with a "flat" entry surface, the reference plane is the plane which contains this surface. The reference -# point of the collimator in the x and y axis is the centre of the collimator entry surface on that plane. The reference plane is orthogonal -# to the z axis and the location of this plane is the reference point on the z axis. The collimator faces negative z values. -# -# .. image:: collimator/collimator.png -# :width: 40% -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# diff --git a/base_classes/nyaml/NXcrystal.yaml b/base_classes/nyaml/NXcrystal.yaml deleted file mode 100644 index 1e68ee9e26..0000000000 --- a/base_classes/nyaml/NXcrystal.yaml +++ /dev/null @@ -1,667 +0,0 @@ -category: base -doc: | - A crystal monochromator or analyzer. - - Permits double bent - monochromator comprised of multiple segments with anisotropic - Gaussian mosaic. - - If curvatures are set to zero or are absent, array - is considered to be flat. - - Scattering vector is perpendicular to surface. Crystal is oriented - parallel to beam incident on crystal before rotation, and lies in - vertical plane. -symbols: - doc: | - These symbols will be used below to coordinate dimensions with the same lengths. - n_comp: | - number of different unit cells to be described - i: | - number of wavelengths -type: group -NXcrystal(NXobject): - (NXgeometry): - deprecated: | - Use the field `depends_on` and :ref:`NXtransformations` to position the crystal and NXoff_geometry to describe its shape instead - doc: | - Position of crystal - usage(NX_CHAR): - doc: | - How this crystal is used. Choices are in the list. - enumeration: - Bragg: - doc: | - reflection geometry - Laue: - doc: | - 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. - See, for example: - http://www.iucr.org/__data/iucr/cif/standard/cifstd15.html or - http://www.cas.org/training/stneasytips/subinforformula1.html. - type: - doc: | - Type or material of monochromating substance. - Chemical formula can be specified separately. - Use the "reflection" field to indicate the (hkl) orientation. - Use the "d_spacing" field to record the lattice plane spacing. - - This field was changed (2010-11-17) from an enumeration to - a string since common usage showed a wider variety of use - than a simple list. These are the items in the list at - the time of the change: PG (Highly Oriented Pyrolytic Graphite) | - Ge | Si | Cu | Fe3Si | CoFe | Cu2MnAl (Heusler) | Multilayer | - Diamond. - chemical_formula: - - # copied from NXsample - doc: | - 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. - order_no(NX_INT): - doc: | - A number which describes if this is the first, second,.. - :math:`n^{th}` crystal in a multi crystal monochromator - cut_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Cut angle of reflecting Bragg plane and plane of crystal surface - space_group: - doc: | - Space group of crystal structure - unit_cell(NX_FLOAT): - unit: NX_LENGTH - doc: | - Unit cell parameters (lengths and angles) - dimensions: - rank: 2 - dim: [[1, n_comp], [2, 6]] - - # NXfilter defines each unit cell parameter separately. Let's be consistent. - unit_cell_a(NX_FLOAT): - unit: NX_LENGTH - - # as used in NXfilter - doc: | - Unit cell lattice parameter: length of side a - unit_cell_b(NX_FLOAT): - unit: NX_LENGTH - - # as used in NXfilter - doc: | - Unit cell lattice parameter: length of side b - unit_cell_c(NX_FLOAT): - unit: NX_LENGTH - - # as used in NXfilter - doc: | - Unit cell lattice parameter: length of side c - unit_cell_alpha(NX_FLOAT): - unit: NX_ANGLE - - # as used in NXfilter - doc: | - Unit cell lattice parameter: angle alpha - unit_cell_beta(NX_FLOAT): - unit: NX_ANGLE - - # as used in NXfilter - doc: | - Unit cell lattice parameter: angle beta - unit_cell_gamma(NX_FLOAT): - unit: NX_ANGLE - - # as used in NXfilter - doc: | - Unit cell lattice parameter: angle gamma - unit_cell_volume(NX_FLOAT): - unit: NX_VOLUME - doc: | - Volume of the unit cell - orientation_matrix(NX_FLOAT): - doc: | - Orientation matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - dimensions: - rank: 2 - - # 3,3 - dim: [[1, 3], [2, 3]] - wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - Optimum diffracted wavelength - dimensions: - dim: [[1, i]] - d_spacing(NX_FLOAT): - unit: NX_LENGTH - doc: | - spacing between crystal planes of the reflection - scattering_vector(NX_FLOAT): - unit: NX_WAVENUMBER - doc: | - Scattering vector, Q, of nominal reflection - reflection(NX_INT): - unit: NX_UNITLESS - doc: | - Miller indices (hkl) values of nominal reflection - dimensions: - dim: [[1, 3]] - thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - Thickness of the crystal. (Required for Laue orientations - see "usage" field) - density(NX_NUMBER): - unit: NX_MASS_DENSITY - doc: | - mass density of the crystal - segment_width(NX_FLOAT): - unit: NX_LENGTH - doc: | - Horizontal width of individual segment - segment_height(NX_FLOAT): - unit: NX_LENGTH - doc: | - Vertical height of individual segment - segment_thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - Thickness of individual segment - segment_gap(NX_FLOAT): - unit: NX_LENGTH - doc: | - Typical gap between adjacent segments - segment_columns(NX_FLOAT): - unit: NX_LENGTH - doc: | - number of segment columns in horizontal direction - segment_rows(NX_FLOAT): - unit: NX_LENGTH - doc: | - number of segment rows in vertical direction - mosaic_horizontal(NX_FLOAT): - unit: NX_ANGLE - doc: | - horizontal mosaic Full Width Half Maximum - mosaic_vertical(NX_FLOAT): - unit: NX_ANGLE - doc: | - vertical mosaic Full Width Half Maximum - curvature_horizontal(NX_FLOAT): - unit: NX_ANGLE - doc: | - Horizontal curvature of focusing crystal - curvature_vertical(NX_FLOAT): - unit: NX_ANGLE - doc: | - Vertical curvature of focusing crystal - is_cylindrical(NX_BOOLEAN): - doc: | - Is this crystal bent cylindrically? - cylindrical_orientation_angle(NX_NUMBER): - unit: NX_ANGLE - doc: | - If cylindrical: cylinder orientation angle - polar_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Polar (scattering) angle at which crystal assembly is positioned. - Note: some instrument geometries call this term 2theta. - Note: it is recommended to use NXtransformations instead. - dimensions: - dim: [[1, i]] - azimuthal_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Azimuthal angle at which crystal assembly is positioned. - Note: it is recommended to use NXtransformations instead. - dimensions: - dim: [[1, i]] - bragg_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Bragg angle of nominal reflection - dimensions: - dim: [[1, i]] - temperature(NX_FLOAT): - unit: NX_TEMPERATURE - doc: | - average/nominal crystal temperature - temperature_coefficient(NX_FLOAT): - unit: NX_ANY - doc: | - how lattice parameter changes with temperature - (NXlog)temperature_log: - doc: | - log file of crystal temperature - (NXdata)reflectivity: - doc: | - crystal reflectivity versus wavelength - (NXdata)transmission: - doc: | - crystal transmission versus wavelength - (NXshape)shape: - deprecated: Use NXoff_geometry instead to describe the shape of the monochromator - doc: | - A NXshape group describing the shape of the crystal arrangement - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the beam line component - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a crystal. - (NXtransformations): - doc: | - Transformations used by this component to define its position and orientation. - - # TODO need more parameters here, such as ... - # list from Rainer Gehrke, DESY (some items may already be present) - # Parameters for crystals - # + Field indicating whether it is Bragg or Laue see usage - # + The crystal structure (enumeration, e.g. Zincblende ..) see space_group - # + Lattice constant see unit_cell - # + Miller indices of reflection (h,k,l) see reflection - # + First (or only) element see order_no - # + Second element (if any) see order_no - # + Temperature factor (optional) see temperature_coefficient - # + Asymmetric angle (if applicable) see cut_angle - # + Mosaic angular spread (if applicable) see mosaic_horizontal and mosaic_vertical - # + Thickness (mandatory for Laue, else optional) see thickness - # Figure for crystals and mirrors (to describe curved surfaces) - # + Field indicating whether concave or convex see curvature_horizontal and curvature_vertical - # + Field indicating whether cylindrical or not see is_cylindrical - # + If cylindrical: cylinder orientation angle see cylindrical_orientation_angle - # Now come the different surface figures with the necessary parameters: - # 1. Flat - # 2. Spherical (spherical radius) - # 3. Elliptical and hyperbolical (semi-major axis, semi-minor axis, angle of major axis and pole) - # 4. Toroidal (major radius, minor radius) - # 5. Parabolical (parabolic parameter a) - # 6. Conical (cone half aperture) - # 7. Polynomial (degree of polynom, array with polynom coefficients) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# fdd54631d80c498793d43ece39c3c8e950aebd03953fba8db841edca63c40e10 -# -# -# -# -# -# -# These symbols will be used below to coordinate dimensions with the same lengths. -# number of different unit cells to be described -# number of wavelengths -# -# -# -# A crystal monochromator or analyzer. -# -# Permits double bent -# monochromator comprised of multiple segments with anisotropic -# Gaussian mosaic. -# -# If curvatures are set to zero or are absent, array -# is considered to be flat. -# -# Scattering vector is perpendicular to surface. Crystal is oriented -# parallel to beam incident on crystal before rotation, and lies in -# vertical plane. -# -# -# -# Position of crystal -# -# -# How this crystal is used. Choices are in the list. -# -# reflection geometry -# -# -# 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. -# See, for example: -# http://www.iucr.org/__data/iucr/cif/standard/cifstd15.html or -# http://www.cas.org/training/stneasytips/subinforformula1.html. -# -# -# -# -# -# -# Type or material of monochromating substance. -# Chemical formula can be specified separately. -# Use the "reflection" field to indicate the (hkl) orientation. -# Use the "d_spacing" field to record the lattice plane spacing. -# -# This field was changed (2010-11-17) from an enumeration to -# a string since common usage showed a wider variety of use -# than a simple list. These are the items in the list at -# the time of the change: PG (Highly Oriented Pyrolytic Graphite) | -# Ge | Si | Cu | Fe3Si | CoFe | Cu2MnAl (Heusler) | Multilayer | -# Diamond. -# -# -# -# -# -# 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. -# -# -# -# -# A number which describes if this is the first, second,.. -# :math:`n^{th}` crystal in a multi crystal monochromator -# -# -# -# Cut angle of reflecting Bragg plane and plane of crystal surface -# -# -# Space group of crystal structure -# -# -# Unit cell parameters (lengths and angles) -# -# -# -# -# -# -# -# Unit cell lattice parameter: length of side a -# -# -# Unit cell lattice parameter: length of side b -# -# -# Unit cell lattice parameter: length of side c -# -# -# Unit cell lattice parameter: angle alpha -# -# -# Unit cell lattice parameter: angle beta -# -# -# Unit cell lattice parameter: angle gamma -# -# -# Volume of the unit cell -# -# -# -# Orientation matrix of single crystal sample using Busing-Levy convention: -# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 -# -# -# -# -# -# -# -# Optimum diffracted wavelength -# -# -# -# spacing between crystal planes of the reflection -# -# -# Scattering vector, Q, of nominal reflection -# -# -# Miller indices (hkl) values of nominal reflection -# -# -# -# Thickness of the crystal. (Required for Laue orientations - see "usage" field) -# -# -# mass density of the crystal -# -# -# Horizontal width of individual segment -# -# -# Vertical height of individual segment -# -# -# Thickness of individual segment -# -# -# Typical gap between adjacent segments -# -# -# number of segment columns in horizontal direction -# -# -# number of segment rows in vertical direction -# -# -# horizontal mosaic Full Width Half Maximum -# -# -# vertical mosaic Full Width Half Maximum -# -# -# Horizontal curvature of focusing crystal -# -# -# Vertical curvature of focusing crystal -# -# -# Is this crystal bent cylindrically? -# -# -# If cylindrical: cylinder orientation angle -# -# -# -# Polar (scattering) angle at which crystal assembly is positioned. -# Note: some instrument geometries call this term 2theta. -# Note: it is recommended to use NXtransformations instead. -# -# -# -# -# -# Azimuthal angle at which crystal assembly is positioned. -# Note: it is recommended to use NXtransformations instead. -# -# -# -# -# Bragg angle of nominal reflection -# -# -# -# average/nominal crystal temperature -# -# -# how lattice parameter changes with temperature -# -# -# log file of crystal temperature -# -# -# crystal reflectivity versus wavelength -# -# -# crystal transmission versus wavelength -# -# -# A NXshape group describing the shape of the crystal arrangement -# -# -# -# This group describes the shape of the beam line component -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a crystal. -# -# -# -# -# Transformations used by this component to define its position and orientation. -# -# -# -# diff --git a/base_classes/nyaml/NXcylindrical_geometry.yaml b/base_classes/nyaml/NXcylindrical_geometry.yaml deleted file mode 100644 index 2a4a3a4e7a..0000000000 --- a/base_classes/nyaml/NXcylindrical_geometry.yaml +++ /dev/null @@ -1,169 +0,0 @@ -category: base -doc: | - Geometry description for cylindrical shapes. - This class can be used in place of ``NXoff_geometry`` when an exact - representation for cylinders is preferred. - For example, for Helium-tube, neutron detectors. - It can be used to describe the shape of any beamline component, including detectors. - In the case of detectors it can be used to define the shape of a single pixel, or, - if the pixel shapes are non-uniform, to describe the shape of the whole detector. -symbols: - doc: | - These symbols will be used below. - i: | - number of vertices required to define all cylinders in the shape - j: | - number of cylinders in the shape - k: | - number cylinders which are detectors -type: group -NXcylindrical_geometry(NXobject): - vertices(NX_NUMBER): - unit: NX_LENGTH - doc: | - List of x,y,z coordinates for vertices. - The origin of the coordinates is the position of the parent component, for - example the NXdetector which the geometry describes. - If the shape describes a single pixel for a detector with uniform pixel shape - then the origin is the position of each pixel as described by the - ``x/y/z_pixel_offset`` datasets in ``NXdetector``. - dimensions: - rank: 2 - dim: [[1, i], [2, 3]] - cylinders(NX_INT): - doc: | - List of indices of vertices in the ``vertices`` dataset to form each cylinder. - Each cylinder is described by three vertices A, B, C. - First vertex A lies on the cylinder axis and circular face, second point B - on edge of the same face as A, and third point C at the other face and on axis. - dimensions: - rank: 2 - dim: [[1, j], [2, 3]] - detector_number(NX_INT): - doc: | - Maps cylinders in ``cylinder``, by index, with a detector id. - dimensions: - rank: 1 - dim: [[1, k]] - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 13b32be4f3e3ad0e269e05db3773a12e08310de6e613dbe7111ad995f7bcaa6e -# -# -# -# -# -# -# These symbols will be used below. -# -# -# number of vertices required to define all cylinders in the shape -# -# -# number of cylinders in the shape -# number cylinders which are detectors -# -# -# -# Geometry description for cylindrical shapes. -# This class can be used in place of ``NXoff_geometry`` when an exact -# representation for cylinders is preferred. -# For example, for Helium-tube, neutron detectors. -# It can be used to describe the shape of any beamline component, including detectors. -# In the case of detectors it can be used to define the shape of a single pixel, or, -# if the pixel shapes are non-uniform, to describe the shape of the whole detector. -# -# -# -# -# -# List of x,y,z coordinates for vertices. -# The origin of the coordinates is the position of the parent component, for -# example the NXdetector which the geometry describes. -# If the shape describes a single pixel for a detector with uniform pixel shape -# then the origin is the position of each pixel as described by the -# ``x/y/z_pixel_offset`` datasets in ``NXdetector``. -# -# -# -# -# -# -# -# -# -# -# -# -# List of indices of vertices in the ``vertices`` dataset to form each cylinder. -# Each cylinder is described by three vertices A, B, C. -# First vertex A lies on the cylinder axis and circular face, second point B -# on edge of the same face as A, and third point C at the other face and on axis. -# -# -# -# -# -# -# -# -# -# -# -# Maps cylinders in ``cylinder``, by index, with a detector id. -# -# -# -# -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# diff --git a/base_classes/nyaml/NXdata.yaml b/base_classes/nyaml/NXdata.yaml deleted file mode 100644 index fdb379861d..0000000000 --- a/base_classes/nyaml/NXdata.yaml +++ /dev/null @@ -1,1137 +0,0 @@ -category: base -doc: | - The :ref:`NXdata` class is designed to encapsulate all the information required for a set of data to be plotted. - NXdata groups contain plottable data (sometimes referred to as *signals* or *dependent variables*) and their - associated axis coordinates (sometimes referred to as *axes* or *independent variables*). - - The actual names of the :ref:`DATA ` and :ref:`AXISNAME ` fields - can be chosen :ref:`freely `, as indicated by the upper case (this is a common convention in all NeXus classes). - - .. note:: ``NXdata`` provides data and coordinates to be plotted but - does not describe how the data is to be plotted or even the dimensionality of the plot. - https://www.nexusformat.org/NIAC2018Minutes.html#nxdata-plottype--attribute - - **Signals:** - - .. index:: plotting - - The :ref:`DATA ` fields contain the signal values to be plotted. The name of the field - to be used as the *default plot signal* is provided by the :ref:`signal ` attribute. - The names of the fields to be used as *secondary plot signals* are provided by the - :ref:`auxiliary_signals` attribute. - - An example with three signals, one of which being the default - - .. code-block:: - - data:NXdata - @signal = "data1" - @auxiliary_signals = ["data2", "data3"] - data1: float[10,20,30] --> the default signal - data2: float[10,20,30] - data3: float[10,20,30] - - **Axes:** - - .. index:: axes (attribute) - .. index:: coordinates - - The :ref:`AXISNAME ` fields contain the axis coordinates associated with the data values. - The names of all :ref:`AXISNAME ` fields are listed in the - :ref:`axes ` attribute. - - `Rank` - - :ref:`AXISNAME ` fields are typically one-dimensional arrays, which annotate one of the dimensions. - - An example of this would be - - .. code-block:: - - data:NXdata - @signal = "data" - @axes = ["x", "y"] --> the order matters - data: float[10,20] - x: float[10] --> coordinates along the first dimension - y: float[20] --> coordinates along the second dimension - - In this example each data point ``data[i,j]`` has axis coordinates ``[x[i], y[j]]``. - - However, the fields can also have a rank greater than 1, in which case the rank of each - :ref:`AXISNAME ` must be equal to the number of data dimensions it spans. - - An example of this would be - - .. code-block:: - - data:NXdata - @signal = "data" - @axes = ["x", "y"] --> the order does NOT matter - @x_indices = [0, 1] - @y_indices = [0, 1] - data: float[10,20] - x: float[10,20] --> coordinates along both dimensions - y: float[10,20] --> coordinates along both dimensions - - In this example each data point ``data[i,j]`` has axis coordinates ``[x[i,j], y[i,j]]``. - - `Dimensions` - - The data dimensions annotated by an :ref:`AXISNAME ` field are defined by the - :ref:`AXISNAME_indices ` attribute. When this attribute is missing, - the position(s) of the :ref:`AXISNAME ` string in the - :ref:`axes ` attribute are used. - - When all :ref:`AXISNAME ` fields are one-dimensional, and none of the data dimensions - have more than one axis, the :ref:`AXISNAME_indices ` attributes - are often omitted. If one of the data dimensions has no :ref:`AXISNAME ` field, - the string “.” can be used in the corresponding index of the axes list. - - An example of this would be - - .. code-block:: - - data:NXdata - @signal = "data" - @axes = ["x", ".", "z"] --> the order matters - data: float[10,20,30] - x: float[10] --> coordinates along the first dimension - z: float[30] --> coordinates along the third dimension - - When using :ref:`AXISNAME_indices ` this becomes - - .. code-block:: - - data:NXdata - @signal = "data" - @axes = ["x", "z"] --> the order does NOT matter - data: float[10,20,30] - @x_indices = 0 - @z_indices = 2 - x: float[10] --> coordinates along the first dimension - z: float[30] --> coordinates along the third dimension - - When providing :ref:`AXISNAME_indices ` attributes it is recommended - to do it for all axes. - - `Non-trivial axes` - - What follows are two examples where :ref:`AXISNAME_indices ` attributes - cannot be omitted. - - The first is an example where data dimensions have alternative axis coordinates. The NXdata group represents - a stack of images collected at different energies. The ``wavelength`` is an alternative axis of ``energy`` - for the last dimension (or vice versa). - - .. code-block:: - - data:NXdata - @signal = "data" - @axes = ["x", "y", "energy", "wavelength"] --> the order does NOT matter - @x_indices = 0 - @y_indices = 1 - @energy_indices = 2 - @wavelength_indices = 2 - data: float[10,20,30] - x: float[10] --> coordinates along the first dimension - y: float[20] --> coordinates along the second dimension - energy: float[30] --> coordinates along the third dimension - wavelength: float[30] --> coordinates along the third dimension - - The second is an example with coordinates that span more than one dimension. The NXdata group represents data - from 2D mesh scans performed at multiple energies. Each data point ``data[i,j,k]`` has axis coordinates - ``[x[i,j,k], y[i,j,k], energy[k]]``. - - .. code-block:: - - data:NXdata - @signal = "data" - @axes = ["x", "y", "energy"] --> the order does NOT matter - @x_indices = [0, 1, 2] - @y_indices = [0, 1, 2] - @energy_indices = 2 - data: float[10,20,30] - x: float[10,20,30] --> coordinates along all dimensions - y: float[10,20,30] --> coordinates along all dimensions - energy: float[30] --> coordinates along the third dimension - - **Uncertainties:** - - Standard deviations on data values as well as coordinates can be provided by - :ref:`FIELDNAME_errors ` fields where ``FIELDNAME`` is the name of a - :ref:`DATA ` field or an :ref:`AXISNAME ` field. - - An example of uncertainties on the signal, auxiliary signals and axis coordinates - - .. code-block:: - - data:NXdata - @signal = "data1" - @auxiliary_signals = ["data2", "data3"] - @axes = ["x", "z"] - @x_indices = 0 - @z_indices = 2 - data1: float[10,20,30] - data2: float[10,20,30] - data3: float[10,20,30] - x: float[10] - z: float[30] - data1_errors: float[10,20,30] - data2_errors: float[10,20,30] - data3_errors: float[10,20,30] - x_errors: float[10] - z_errors: float[30] - -# The ignoreExtra* attributes are used in the definition to -# avoid warning messages that would be generated from unexpected fields or attributes. -# Since common use of NXdata indicates field names of any value, _many_ -# instances of this class would generate a warning message during validation -# without this attribute being set to "true". -symbols: - doc: | - These symbols will be used below to coordinate fields with the same shape. - dataRank: | - rank of the ``DATA`` field(s) - nx: | - length of the ``x`` field - ny: | - length of the ``y`` field - nz: | - length of the ``z`` field -type: group -ignoreExtraFields: true -ignoreExtraAttributes: true -NXdata(NXobject): - - # Attributes for data and coordinate field detection - \@signal: - doc: | - .. index:: find the default plottable data - .. index:: plotting - .. index:: signal attribute value - - The value is the :ref:`name ` of the signal that contains - the default plottable data. 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. - \@auxiliary_signals: - doc: | - .. index:: plotting - - Array of strings holding the :ref:`names ` of additional - signals to be plotted with the :ref:`default signal `. - These fields or links *must* exist and be direct children of this NXdata group. - - Each auxiliary signal needs to be of the same shape as the default signal. - - .. NIAC2018: - https://www.nexusformat.org/NIAC2018Minutes.html - \@default_slice: - type: NX_CHAR_OR_NUMBER - doc: | - Which slice of data to show in a plot by default. This is useful especially for - datasets with more than 2 dimensions. - - Should be an array of length equal to the number of dimensions - in the data, with the following possible values: - - * ".": All the data in this dimension should be included - * Integer: Only this slice should be used. - * String: Only this slice should be used. Use if ``AXISNAME`` is a string - array. - - Example:: - - data:NXdata - @signal = "data" - @axes = ["image_id", "channel", ".", "."] - @image_id_indices = 0 - @channel_indices = 1 - @default_slice = [".", "difference", ".", "."] - image_id = [1, ..., nP] - channel = ["threshold_1", "threshold_2", "difference"] - data = uint[nP, nC, i, j] - - Here, a data array with four dimensions, including the number of images - (nP) and number of channels (nC), specifies more dimensions than can be - visualized with a 2D image viewer for a given image. Therefore the - default_slice attribute specifies that the "difference" channel should be - shown by default. - - Alternate version using an integer would look like this (note 2 is a string):: - - data:NXdata - @signal = "data" - @axes = ["image_id", "channel", ".", "."] - @image_id_indices = 0 - @channel_indices = 1 - @default_slice = [".", "2", ".", "."] - image_id = [1, ..., nP] - channel = ["threshold_1", "threshold_2", "difference"] - data = uint[nP, nC, i, j] - \@reference: - doc: | - Points to the path of a field defining the data to which the `DATA` group refers. - - This concept allows to link the data to a respective field in the NeXus hierarchy, thereby - defining the physical quantity it represents. - - Example: - If the data corresponds to a readout of a detector, ``@reference`` links - to that detectors data: - - @reference: '/entry/instrument/detector/data' for a 2D detector - \@AXISNAME_indices: - type: NX_INT - - # nxdl.xsd rules do not allow us to show this as a variable name - # - we'll use ALL CAPS (see #562) - - # AXISNAME_indices documentation copied from datarules.rst - doc: | - The ``AXISNAME_indices`` attribute is a single integer or an array of integers that defines which :ref:`data ` - dimension(s) are spanned by the corresponding axis. The first dimension index is ``0`` (zero). - - When the ``AXISNAME_indices`` attribute is missing for an :ref:`AXISNAME ` field, its value becomes the index - (or indices) of the :ref:`AXISNAME ` name in the :ref:`axes ` attribute. - - .. note:: When ``AXISNAME_indices`` contains multiple integers, it must be saved as an actual array - of integers and not a comma separated string. - \@axes: - doc: | - .. index:: plotting - - The ``axes`` attribute is a list of strings which are the names of the :ref:`AXISNAME ` fields - that contain the values of the coordinates along the :ref:`data ` dimensions. - - .. note:: When ``axes`` contains multiple strings, it must be saved as an actual array - of strings and not a single comma separated string. - - # Data and coordinate fields - AXISNAME(NX_CHAR_OR_NUMBER): - nameType: any - doc: | - Coordinate values along one or more :ref:`data ` dimensions. The rank must be equal - to the number of dimensions it spans. - - As the upper case ``AXISNAME`` indicates, the names of the ``AXISNAME`` fields can be chosen :ref:`freely `. - The :ref:`axes ` attribute can be used to find all datasets in the - ``NXdata`` that contain coordinate values. - - Most AXISNAME fields will be sequences of numbers but if an axis is better represented using names, such as channel names, - an array of NX_CHAR can be provided. - \@long_name: - doc: | - Axis label - \@units: - doc: | - Unit in which the coordinate values are expressed. - See the section :ref:`Design-Units` for more information. - \@distribution: - type: NX_BOOLEAN - doc: | - ``0|false``: single value, - ``1|true``: multiple values - \@first_good: - type: NX_INT - doc: | - Index of first good value - \@last_good: - type: NX_INT - doc: | - Index of last good value - \@axis: - type: NX_POSINT - deprecated: Use the group ``axes`` attribute (NIAC2014) - doc: | - Index (positive integer) identifying this specific set of numbers. - - N.B. The ``axis`` attribute is the old way of designating a link. - Do not use the :ref:`axes ` attribute with the ``axis`` attribute. - The :ref:`axes ` attribute is now preferred. - \@reference: - doc: | - Points to the path of a field defining the axis to which the ``AXISNAME`` axis refers. - - This concept allows to link an axis to a respective field in the NeXus hierarchy, thereby - defining the physical quantity it represents. - - Examples: - If a calibration has been performed, ``@reference`` links to the result of - that calibration: - - @reference: '/entry/process/calibration/calibrated_axis' - - If the axis corresponds to a coordinate of a detector, ``@reference`` links - to that detector axis: - - @reference: '/entry/instrument/detector/axis/some_axis' for a 2D detector - - If the axis is a scanned motor, ``@reference`` links to the transformation - describing the respective motion, e.g.: - - @reference: '/entry/instrument/detector/transformations/some_transformation' for a motion of the detector - DATA(NX_NUMBER): - nameType: any - doc: | - .. index:: plotting - - Data values to be used as the NeXus *plottable data*. As the upper case ``DATA`` - indicates, the names of the ``DATA`` fields can be chosen :ref:`freely `. The :ref:`signal attribute ` - and :ref:`auxiliary_signals attribute` can be used to find all datasets in the ``NXdata`` - that contain data values. - - The maximum rank is ``32`` for compatibility with backend file formats. - dimensions: - rank: dataRank - doc: | - The rank (``dataRank``) of the ``data`` must satisfy - ``1 <= dataRank <= NX_MAXRANK=32``. - dim: [] - \@signal: - type: NX_POSINT - deprecated: Use the group ``signal`` attribute (NIAC2014) - doc: | - .. index:: plotting - - Plottable (independent) axis, indicate index number. - Only one field in a :ref:`NXdata` group may have the - ``signal=1`` attribute. - Do not use the ``signal`` attribute with the ``axis`` attribute. - \@axes: - deprecated: Use the group ``axes`` attribute (NIAC2014) - doc: | - Defines the names of the coordinates - (independent axes) for this data set - as a colon-delimited array. - NOTE: The :ref:`axes ` attribute is the preferred - method of designating a link. - Do not use the :ref:`axes ` attribute with the ``axis`` attribute. - \@long_name: - doc: | - data label - \@reference: - doc: | - Points to the path of a field defining the data to which the `DATA` field refers. - - This concept allows to link the data to a respective field in the NeXus hierarchy, thereby - defining the physical quantity it represents. - - Here, *DATA* is to be replaced by the name of each - data field. - - Example: - If the data corresponds to a readout of a detector, ``@reference`` links - to that detectors data: - - @reference: '/entry/instrument/detector/data' for a 2D detector - FIELDNAME_errors(NX_NUMBER): - nameType: any - doc: | - "Errors" (meaning *uncertainties* or *standard deviations*) - associated with any field named ``FIELDNAME`` in this ``NXdata`` - group (e.g. an axis, signal or auxiliary signal). - - The dimensions of the ``FIELDNAME_errors`` field must match - the dimensions of the ``FIELDNAME`` field. - errors(NX_NUMBER): - deprecated: Use ``DATA_errors`` instead (NIAC2018) - doc: | - Standard deviations of data values - - the data array is identified by the group attribute ``signal``. - The ``errors`` array must have the same dimensions as ``DATA``. - Client is responsible for defining the dimensions of the data. - dimensions: - rank: dataRank - doc: | - The ``errors`` must have the same rank (``dataRank``) - as the ``data``. - dim: [] - - # Data vs. plot coordinates - FIELDNAME_scaling_factor(NX_NUMBER): - doc: | - An optional scaling factor to apply to the values in any field named ``FIELDNAME`` - in this ``NXdata`` group. This can be a :ref:`DATA ` field - (signal or auxiliary signal) or a :ref:`AXISNAME ` - field (axis). - - The elements stored in NXdata datasets are often stored as integers for efficiency - reasons and need further correction or conversion, generating floats. For example, - raw values could be stored from a device that need to be converted to values that - represent the physical values. The two fields FIELDNAME_scaling_factor and - FIELDNAME_offset allow linear corrections using the following convention: - - .. code-block:: - - corrected values = (FIELDNAME + offset) * scaling_factor - - This formula will derive the values to use in downstream applications, when necessary. - - When omitted, the scaling factor is assumed to be 1. - FIELDNAME_offset(NX_NUMBER): - doc: | - An optional offset to apply to the values in FIELDNAME (usually the signal). - - When omitted, the offset is assumed to be 0. - - See :ref:`FIELDNAME_scaling_factor ` for more information. - scaling_factor(NX_FLOAT): - deprecated: Use FIELDNAME_scaling_factor instead - doc: | - The scaling_factor and FIELDNAME_scaling_factor fields have similar semantics. - However, scaling_factor is ambiguous in the case of multiple signals. Therefore - scaling_factor is deprecated. Use FIELDNAME_scaling_factor instead, even when - only a single signal is present. - offset(NX_FLOAT): - deprecated: Use FIELDNAME_offset instead - doc: | - The offset and FIELDNAME_offset fields have similar semantics. - However, offset is ambiguous in the case of multiple signals. Therefore - offset is deprecated. Use FIELDNAME_offset instead, even when - only a single signal is present. - - # Other fields - title: - doc: | - Title for the plot. - - # Deprecated fields - x(NX_FLOAT): - unit: NX_ANY - doc: | - This is an array holding the values to use for the x-axis of - data. The units must be appropriate for the measurement. - - This is a special case of a :ref:`AXISNAME field ` - kept for backward compatiblity. - dimensions: - rank: 1 - dim: [[1, nx]] - y(NX_FLOAT): - unit: NX_ANY - doc: | - This is an array holding the values to use for the y-axis of - data. The units must be appropriate for the measurement. - - This is a special case of a :ref:`AXISNAME field ` - kept for backward compatiblity. - dimensions: - rank: 1 - dim: [[1, ny]] - z(NX_FLOAT): - unit: NX_ANY - doc: | - This is an array holding the values to use for the z-axis of - data. The units must be appropriate for the measurement. - - This is a special case of a :ref:`AXISNAME field ` - kept for backward compatiblity. - dimensions: - rank: 1 - dim: [[1, nz]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d23365528998adfba29a8102929213b777f0dbbf6cb37768577aa3c886c715cb -# -# -# -# -# -# -# -# -# These symbols will be used below to coordinate fields with the same shape. -# rank of the ``DATA`` field(s) -# length of the ``x`` field -# length of the ``y`` field -# length of the ``z`` field -# -# -# -# The :ref:`NXdata` class is designed to encapsulate all the information required for a set of data to be plotted. -# NXdata groups contain plottable data (sometimes referred to as *signals* or *dependent variables*) and their -# associated axis coordinates (sometimes referred to as *axes* or *independent variables*). -# -# The actual names of the :ref:`DATA </NXdata/DATA-field>` and :ref:`AXISNAME </NXdata/AXISNAME-field>` fields -# can be chosen :ref:`freely <validItemName>`, as indicated by the upper case (this is a common convention in all NeXus classes). -# -# .. note:: ``NXdata`` provides data and coordinates to be plotted but -# does not describe how the data is to be plotted or even the dimensionality of the plot. -# https://www.nexusformat.org/NIAC2018Minutes.html#nxdata-plottype--attribute -# -# **Signals:** -# -# .. index:: plotting -# -# The :ref:`DATA </NXdata/DATA-field>` fields contain the signal values to be plotted. The name of the field -# to be used as the *default plot signal* is provided by the :ref:`signal </NXdata@signal-attribute>` attribute. -# The names of the fields to be used as *secondary plot signals* are provided by the -# :ref:`auxiliary_signals</NXdata@auxiliary_signals-attribute>` attribute. -# -# An example with three signals, one of which being the default -# -# .. code-block:: -# -# data:NXdata -# @signal = "data1" -# @auxiliary_signals = ["data2", "data3"] -# data1: float[10,20,30] --> the default signal -# data2: float[10,20,30] -# data3: float[10,20,30] -# -# **Axes:** -# -# .. index:: axes (attribute) -# .. index:: coordinates -# -# The :ref:`AXISNAME </NXdata/AXISNAME-field>` fields contain the axis coordinates associated with the data values. -# The names of all :ref:`AXISNAME </NXdata/AXISNAME-field>` fields are listed in the -# :ref:`axes </NXdata@axes-attribute>` attribute. -# -# `Rank` -# -# :ref:`AXISNAME </NXdata/AXISNAME-field>` fields are typically one-dimensional arrays, which annotate one of the dimensions. -# -# An example of this would be -# -# .. code-block:: -# -# data:NXdata -# @signal = "data" -# @axes = ["x", "y"] --> the order matters -# data: float[10,20] -# x: float[10] --> coordinates along the first dimension -# y: float[20] --> coordinates along the second dimension -# -# In this example each data point ``data[i,j]`` has axis coordinates ``[x[i], y[j]]``. -# -# However, the fields can also have a rank greater than 1, in which case the rank of each -# :ref:`AXISNAME </NXdata/AXISNAME-field>` must be equal to the number of data dimensions it spans. -# -# An example of this would be -# -# .. code-block:: -# -# data:NXdata -# @signal = "data" -# @axes = ["x", "y"] --> the order does NOT matter -# @x_indices = [0, 1] -# @y_indices = [0, 1] -# data: float[10,20] -# x: float[10,20] --> coordinates along both dimensions -# y: float[10,20] --> coordinates along both dimensions -# -# In this example each data point ``data[i,j]`` has axis coordinates ``[x[i,j], y[i,j]]``. -# -# `Dimensions` -# -# The data dimensions annotated by an :ref:`AXISNAME </NXdata/AXISNAME-field>` field are defined by the -# :ref:`AXISNAME_indices </NXdata@AXISNAME_indices-attribute>` attribute. When this attribute is missing, -# the position(s) of the :ref:`AXISNAME </NXdata/AXISNAME-field>` string in the -# :ref:`axes </NXdata@axes-attribute>` attribute are used. -# -# When all :ref:`AXISNAME </NXdata/AXISNAME-field>` fields are one-dimensional, and none of the data dimensions -# have more than one axis, the :ref:`AXISNAME_indices </NXdata@AXISNAME_indices-attribute>` attributes -# are often omitted. If one of the data dimensions has no :ref:`AXISNAME </NXdata/AXISNAME-field>` field, -# the string “.” can be used in the corresponding index of the axes list. -# -# An example of this would be -# -# .. code-block:: -# -# data:NXdata -# @signal = "data" -# @axes = ["x", ".", "z"] --> the order matters -# data: float[10,20,30] -# x: float[10] --> coordinates along the first dimension -# z: float[30] --> coordinates along the third dimension -# -# When using :ref:`AXISNAME_indices </NXdata@AXISNAME_indices-attribute>` this becomes -# -# .. code-block:: -# -# data:NXdata -# @signal = "data" -# @axes = ["x", "z"] --> the order does NOT matter -# data: float[10,20,30] -# @x_indices = 0 -# @z_indices = 2 -# x: float[10] --> coordinates along the first dimension -# z: float[30] --> coordinates along the third dimension -# -# When providing :ref:`AXISNAME_indices </NXdata@AXISNAME_indices-attribute>` attributes it is recommended -# to do it for all axes. -# -# `Non-trivial axes` -# -# What follows are two examples where :ref:`AXISNAME_indices </NXdata@AXISNAME_indices-attribute>` attributes -# cannot be omitted. -# -# The first is an example where data dimensions have alternative axis coordinates. The NXdata group represents -# a stack of images collected at different energies. The ``wavelength`` is an alternative axis of ``energy`` -# for the last dimension (or vice versa). -# -# .. code-block:: -# -# data:NXdata -# @signal = "data" -# @axes = ["x", "y", "energy", "wavelength"] --> the order does NOT matter -# @x_indices = 0 -# @y_indices = 1 -# @energy_indices = 2 -# @wavelength_indices = 2 -# data: float[10,20,30] -# x: float[10] --> coordinates along the first dimension -# y: float[20] --> coordinates along the second dimension -# energy: float[30] --> coordinates along the third dimension -# wavelength: float[30] --> coordinates along the third dimension -# -# The second is an example with coordinates that span more than one dimension. The NXdata group represents data -# from 2D mesh scans performed at multiple energies. Each data point ``data[i,j,k]`` has axis coordinates -# ``[x[i,j,k], y[i,j,k], energy[k]]``. -# -# .. code-block:: -# -# data:NXdata -# @signal = "data" -# @axes = ["x", "y", "energy"] --> the order does NOT matter -# @x_indices = [0, 1, 2] -# @y_indices = [0, 1, 2] -# @energy_indices = 2 -# data: float[10,20,30] -# x: float[10,20,30] --> coordinates along all dimensions -# y: float[10,20,30] --> coordinates along all dimensions -# energy: float[30] --> coordinates along the third dimension -# -# **Uncertainties:** -# -# Standard deviations on data values as well as coordinates can be provided by -# :ref:`FIELDNAME_errors </NXdata/FIELDNAME_errors-field>` fields where ``FIELDNAME`` is the name of a -# :ref:`DATA </NXdata/DATA-field>` field or an :ref:`AXISNAME </NXdata/AXISNAME-field>` field. -# -# An example of uncertainties on the signal, auxiliary signals and axis coordinates -# -# .. code-block:: -# -# data:NXdata -# @signal = "data1" -# @auxiliary_signals = ["data2", "data3"] -# @axes = ["x", "z"] -# @x_indices = 0 -# @z_indices = 2 -# data1: float[10,20,30] -# data2: float[10,20,30] -# data3: float[10,20,30] -# x: float[10] -# z: float[30] -# data1_errors: float[10,20,30] -# data2_errors: float[10,20,30] -# data3_errors: float[10,20,30] -# x_errors: float[10] -# z_errors: float[30] -# -# -# -# -# -# -# .. index:: find the default plottable data -# .. index:: plotting -# .. index:: signal attribute value -# -# The value is the :ref:`name <validItemName>` of the signal that contains -# the default plottable data. 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. -# -# -# -# -# .. index:: plotting -# -# Array of strings holding the :ref:`names <validItemName>` of additional -# signals to be plotted with the :ref:`default signal </NXdata@signal-attribute>`. -# These fields or links *must* exist and be direct children of this NXdata group. -# -# Each auxiliary signal needs to be of the same shape as the default signal. -# -# .. NIAC2018: -# https://www.nexusformat.org/NIAC2018Minutes.html -# -# -# -# -# Which slice of data to show in a plot by default. This is useful especially for -# datasets with more than 2 dimensions. -# -# Should be an array of length equal to the number of dimensions -# in the data, with the following possible values: -# -# * ".": All the data in this dimension should be included -# * Integer: Only this slice should be used. -# * String: Only this slice should be used. Use if ``AXISNAME`` is a string -# array. -# -# Example:: -# -# data:NXdata -# @signal = "data" -# @axes = ["image_id", "channel", ".", "."] -# @image_id_indices = 0 -# @channel_indices = 1 -# @default_slice = [".", "difference", ".", "."] -# image_id = [1, ..., nP] -# channel = ["threshold_1", "threshold_2", "difference"] -# data = uint[nP, nC, i, j] -# -# Here, a data array with four dimensions, including the number of images -# (nP) and number of channels (nC), specifies more dimensions than can be -# visualized with a 2D image viewer for a given image. Therefore the -# default_slice attribute specifies that the "difference" channel should be -# shown by default. -# -# Alternate version using an integer would look like this (note 2 is a string):: -# -# data:NXdata -# @signal = "data" -# @axes = ["image_id", "channel", ".", "."] -# @image_id_indices = 0 -# @channel_indices = 1 -# @default_slice = [".", "2", ".", "."] -# image_id = [1, ..., nP] -# channel = ["threshold_1", "threshold_2", "difference"] -# data = uint[nP, nC, i, j] -# -# -# -# -# -# Points to the path of a field defining the data to which the `DATA` group refers. -# -# This concept allows to link the data to a respective field in the NeXus hierarchy, thereby -# defining the physical quantity it represents. -# -# Example: -# If the data corresponds to a readout of a detector, ``@reference`` links -# to that detectors data: -# -# @reference: '/entry/instrument/detector/data' for a 2D detector -# -# -# -# -# -# -# The ``AXISNAME_indices`` attribute is a single integer or an array of integers that defines which :ref:`data </NXdata/DATA-field>` -# dimension(s) are spanned by the corresponding axis. The first dimension index is ``0`` (zero). -# -# When the ``AXISNAME_indices`` attribute is missing for an :ref:`AXISNAME </NXdata/AXISNAME-field>` field, its value becomes the index -# (or indices) of the :ref:`AXISNAME </NXdata/AXISNAME-field>` name in the :ref:`axes </NXdata@axes-attribute>` attribute. -# -# .. note:: When ``AXISNAME_indices`` contains multiple integers, it must be saved as an actual array -# of integers and not a comma separated string. -# -# -# -# -# .. index:: plotting -# -# The ``axes`` attribute is a list of strings which are the names of the :ref:`AXISNAME </NXdata/AXISNAME-field>` fields -# that contain the values of the coordinates along the :ref:`data </NXdata/DATA-field>` dimensions. -# -# .. note:: When ``axes`` contains multiple strings, it must be saved as an actual array -# of strings and not a single comma separated string. -# -# -# -# -# -# -# Coordinate values along one or more :ref:`data </NXdata/DATA-field>` dimensions. The rank must be equal -# to the number of dimensions it spans. -# -# As the upper case ``AXISNAME`` indicates, the names of the ``AXISNAME`` fields can be chosen :ref:`freely <validItemName>`. -# The :ref:`axes </NXdata@axes-attribute>` attribute can be used to find all datasets in the -# ``NXdata`` that contain coordinate values. -# -# Most AXISNAME fields will be sequences of numbers but if an axis is better represented using names, such as channel names, -# an array of NX_CHAR can be provided. -# -# Axis label -# -# -# Unit in which the coordinate values are expressed. -# See the section :ref:`Design-Units` for more information. -# -# -# -# -# ``0|false``: single value, -# ``1|true``: multiple values -# -# -# Index of first good value -# Index of last good value -# -# -# Index (positive integer) identifying this specific set of numbers. -# -# N.B. The ``axis`` attribute is the old way of designating a link. -# Do not use the :ref:`axes </NXdata@axes-attribute>` attribute with the ``axis`` attribute. -# The :ref:`axes </NXdata@axes-attribute>` attribute is now preferred. -# -# -# -# -# Points to the path of a field defining the axis to which the ``AXISNAME`` axis refers. -# -# This concept allows to link an axis to a respective field in the NeXus hierarchy, thereby -# defining the physical quantity it represents. -# -# Examples: -# If a calibration has been performed, ``@reference`` links to the result of -# that calibration: -# -# @reference: '/entry/process/calibration/calibrated_axis' -# -# If the axis corresponds to a coordinate of a detector, ``@reference`` links -# to that detector axis: -# -# @reference: '/entry/instrument/detector/axis/some_axis' for a 2D detector -# -# If the axis is a scanned motor, ``@reference`` links to the transformation -# describing the respective motion, e.g.: -# -# @reference: '/entry/instrument/detector/transformations/some_transformation' for a motion of the detector -# -# -# -# -# -# .. index:: plotting -# -# Data values to be used as the NeXus *plottable data*. As the upper case ``DATA`` -# indicates, the names of the ``DATA`` fields can be chosen :ref:`freely <validItemName>`. The :ref:`signal attribute </NXdata@signal-attribute>` -# and :ref:`auxiliary_signals attribute</NXdata@auxiliary_signals-attribute>` can be used to find all datasets in the ``NXdata`` -# that contain data values. -# -# The maximum rank is ``32`` for compatibility with backend file formats. -# -# -# -# The rank (``dataRank``) of the ``data`` must satisfy -# ``1 <= dataRank <= NX_MAXRANK=32``. -# -# -# -# -# .. index:: plotting -# -# Plottable (independent) axis, indicate index number. -# Only one field in a :ref:`NXdata` group may have the -# ``signal=1`` attribute. -# Do not use the ``signal`` attribute with the ``axis`` attribute. -# -# -# -# -# Defines the names of the coordinates -# (independent axes) for this data set -# as a colon-delimited array. -# NOTE: The :ref:`axes </NXdata@axes-attribute>` attribute is the preferred -# method of designating a link. -# Do not use the :ref:`axes </NXdata@axes-attribute>` attribute with the ``axis`` attribute. -# -# -# -# data label -# -# -# -# Points to the path of a field defining the data to which the `DATA` field refers. -# -# This concept allows to link the data to a respective field in the NeXus hierarchy, thereby -# defining the physical quantity it represents. -# -# Here, *DATA* is to be replaced by the name of each -# data field. -# -# Example: -# If the data corresponds to a readout of a detector, ``@reference`` links -# to that detectors data: -# -# @reference: '/entry/instrument/detector/data' for a 2D detector -# -# -# -# -# -# "Errors" (meaning *uncertainties* or *standard deviations*) -# associated with any field named ``FIELDNAME`` in this ``NXdata`` -# group (e.g. an axis, signal or auxiliary signal). -# -# The dimensions of the ``FIELDNAME_errors`` field must match -# the dimensions of the ``FIELDNAME`` field. -# -# -# -# -# Standard deviations of data values - -# the data array is identified by the group attribute ``signal``. -# The ``errors`` array must have the same dimensions as ``DATA``. -# Client is responsible for defining the dimensions of the data. -# -# -# -# The ``errors`` must have the same rank (``dataRank``) -# as the ``data``. -# -# -# -# -# -# -# -# An optional scaling factor to apply to the values in any field named ``FIELDNAME`` -# in this ``NXdata`` group. This can be a :ref:`DATA </NXdata/DATA-field>` field -# (signal or auxiliary signal) or a :ref:`AXISNAME </NXdata/AXISNAME-field>` -# field (axis). -# -# The elements stored in NXdata datasets are often stored as integers for efficiency -# reasons and need further correction or conversion, generating floats. For example, -# raw values could be stored from a device that need to be converted to values that -# represent the physical values. The two fields FIELDNAME_scaling_factor and -# FIELDNAME_offset allow linear corrections using the following convention: -# -# .. code-block:: -# -# corrected values = (FIELDNAME + offset) * scaling_factor -# -# This formula will derive the values to use in downstream applications, when necessary. -# -# When omitted, the scaling factor is assumed to be 1. -# -# -# -# -# An optional offset to apply to the values in FIELDNAME (usually the signal). -# -# When omitted, the offset is assumed to be 0. -# -# See :ref:`FIELDNAME_scaling_factor </NXdata/FIELDNAME_scaling_factor-field>` for more information. -# -# -# -# -# -# The scaling_factor and FIELDNAME_scaling_factor fields have similar semantics. -# However, scaling_factor is ambiguous in the case of multiple signals. Therefore -# scaling_factor is deprecated. Use FIELDNAME_scaling_factor instead, even when -# only a single signal is present. -# -# -# -# -# The offset and FIELDNAME_offset fields have similar semantics. -# However, offset is ambiguous in the case of multiple signals. Therefore -# offset is deprecated. Use FIELDNAME_offset instead, even when -# only a single signal is present. -# -# -# -# -# -# -# -# Title for the plot. -# -# -# -# -# -# -# This is an array holding the values to use for the x-axis of -# data. The units must be appropriate for the measurement. -# -# This is a special case of a :ref:`AXISNAME field </NXdata/AXISNAME-field>` -# kept for backward compatiblity. -# -# -# -# -# -# -# -# This is an array holding the values to use for the y-axis of -# data. The units must be appropriate for the measurement. -# -# This is a special case of a :ref:`AXISNAME field </NXdata/AXISNAME-field>` -# kept for backward compatiblity. -# -# -# -# -# -# -# -# This is an array holding the values to use for the z-axis of -# data. The units must be appropriate for the measurement. -# -# This is a special case of a :ref:`AXISNAME field </NXdata/AXISNAME-field>` -# kept for backward compatiblity. -# -# -# -# -# -# diff --git a/base_classes/nyaml/NXdetector.yaml b/base_classes/nyaml/NXdetector.yaml deleted file mode 100644 index 67a3a389d4..0000000000 --- a/base_classes/nyaml/NXdetector.yaml +++ /dev/null @@ -1,1782 +0,0 @@ -category: base -doc: | - A detector, detector bank, or multidetector. -symbols: - doc: | - These symbols will be used below to illustrate the coordination of the rank and sizes of datasets and the - preferred ordering of the dimensions. Each of these are optional (so the rank of the datasets - will vary according to the situation) and the general ordering principle is slowest to fastest. - The type of each dimension should follow the order of scan points, detector output (e.g. pixels), - then time-of-flight (i.e. spectroscopy, spectrometry). Note that the output of a detector is not limited - to single values (0D), lists (1D) and images (2), but three or higher dimensional arrays can be produced - by a detector at each trigger. - nP: | - number of scan points (only present in scanning measurements) - i: | - number of detector pixels in the first (slowest) direction - j: | - number of detector pixels in the second (faster) direction - k: | - number of detector pixels in the third (if necessary, fastest) direction - tof: | - number of bins in the time-of-flight histogram -type: group -(NXobject)NXdetector: - time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - doc: | - Total time of flight - dimensions: - rank: 1 - dim: [[1, tof+1]] - \@axis: - type: NX_POSINT - deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 - enumeration: [3] - \@primary: - type: NX_POSINT - deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 - enumeration: [1] - \@long_name: - doc: | - Total time of flight - raw_time_of_flight(NX_INT): - unit: NX_PULSES - doc: | - In DAQ clock pulses - dimensions: - rank: 1 - dim: [[1, tof+1]] - \@frequency: - type: NX_NUMBER - doc: | - Clock frequency in Hz - detector_number(NX_INT): - doc: | - Identifier for detector (pixels) - Can be multidimensional, if needed - data(NX_NUMBER): - unit: NX_ANY - doc: | - 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. - dimensions: - rank: 4 - dim: [[1, nP], [2, i], [3, j], [4, tof]] - \@long_name: - doc: | - Title of measurement - \@check_sum: - type: NX_INT - doc: | - Integral of data as check of data integrity - data_errors(NX_NUMBER): - unit: NX_ANY - doc: | - The best estimate of the uncertainty in the data value (array size should match the data field). Where - possible, this should be the standard deviation, which has the same units - as the data. The form data_error is deprecated. - dimensions: - rank: 4 - dim: [[1, nP], [2, i], [3, j], [4, tof]] - x_pixel_offset(NX_FLOAT): - unit: NX_LENGTH - doc: | - Offset from the detector center in x-direction. - Can be multidimensional when needed. - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - \@axis: - type: NX_POSINT - deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 - enumeration: [1] - \@primary: - type: NX_POSINT - deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 - enumeration: [1] - \@long_name: - doc: | - x-axis offset from detector center - y_pixel_offset(NX_FLOAT): - unit: NX_LENGTH - doc: | - Offset from the detector center in the y-direction. - Can be multidimensional when different values are required for each pixel. - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - \@axis: - type: NX_POSINT - deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 - enumeration: [2] - \@primary: - type: NX_POSINT - deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 - enumeration: [1] - \@long_name: - doc: | - y-axis offset from detector center - z_pixel_offset(NX_FLOAT): - unit: NX_LENGTH - doc: | - Offset from the detector center in the z-direction. - Can be multidimensional when different values are required for each pixel. - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - \@axis: - type: NX_POSINT - deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 - enumeration: [3] - \@primary: - type: NX_POSINT - deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 - enumeration: [1] - \@long_name: - doc: | - y-axis offset from detector center - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - This is the distance to the previous component in the - instrument; most often the sample. The usage depends on the - nature of the detector: Most often it is the distance of the - detector assembly. But there are irregular detectors. In this - case the distance must be specified for each detector pixel. - - Note, it is recommended to use NXtransformations instead. - dimensions: - rank: 3 - dim: [[1, nP], [2, i], [3, j]] - polar_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - This is the polar angle of the detector towards the previous - component in the instrument; most often the sample. - The usage depends on the - nature of the detector. - Most often it is the polar_angle of the detector assembly. - But there are irregular detectors. - In this - case, the polar_angle must be specified for each detector pixel. - - Note, it is recommended to use NXtransformations instead. - dimensions: - rank: 3 - dim: [[1, nP], [2, i], [3, j]] - azimuthal_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - This is the azimuthal angle angle of the detector towards - the previous component in the instrument; most often the sample. - The usage depends on the - nature of the detector. - Most often it is the azimuthal_angle of the detector assembly. - But there are irregular detectors. - In this - case, the azimuthal_angle must be specified for each detector pixel. - - Note, it is recommended to use NXtransformations instead. - dimensions: - rank: 3 - dim: [[1, nP], [2, i], [3, j]] - description: - doc: | - name/manufacturer/model/etc. information - serial_number: - doc: | - Serial number for the detector - local_name: - doc: | - Local name for the detector - (NXgeometry): - deprecated: | - Use the field `depends_on` and :ref:`NXtransformations` to position the detector and NXoff_geometry to describe its shape instead - doc: | - Position and orientation of detector - solid_angle(NX_FLOAT): - unit: NX_SOLID_ANGLE - doc: | - Solid angle subtended by the detector at the sample - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - x_pixel_size(NX_FLOAT): - unit: NX_LENGTH - doc: | - Size of each detector pixel. If it is scalar all pixels are the same size. - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - y_pixel_size(NX_FLOAT): - unit: NX_LENGTH - doc: | - Size of each detector pixel. If it is scalar all pixels are the same size - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - dead_time(NX_FLOAT): - unit: NX_TIME - doc: | - Detector dead time - dimensions: - rank: 3 - dim: [[1, nP], [2, i], [3, j]] - gas_pressure(NX_FLOAT): - unit: NX_PRESSURE - doc: | - Detector gas pressure - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - detection_gas_path(NX_FLOAT): - unit: NX_LENGTH - doc: | - maximum drift space dimension - crate(NX_INT): - doc: | - Crate number of detector - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - \@local_name: - doc: | - Equivalent local term - slot(NX_INT): - doc: | - Slot number of detector - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - \@local_name: - doc: | - Equivalent local term - input(NX_INT): - doc: | - Input number of detector - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - \@local_name: - doc: | - Equivalent local term - type: - doc: | - Description of type such as He3 gas cylinder, He3 PSD, scintillator, - fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, - CMOS, ... - CHANNELNAME_channel(NXdetector_channel): - doc: | - Group containing the description and metadata for a single channel from a multi-channel - detector. - - Given an :ref:`NXdata` group linked as part of an NXdetector group that has an axis with - named channels (see the example in :ref:`NXdata `), - the NXdetector will have a series of NXdetector_channel groups, one for each channel, - named CHANNELNAME_channel. - efficiency(NXdata): - doc: | - Spectral efficiency of detector with respect to e.g. wavelength - \@signal: - enumeration: [efficiency] - \@axes: - - # TODO: clarify the various use cases - enumeration: [., . ., . . ., . . . ., wavelength] - \@wavelength_indices: - - # TODO: clarify the actual possibilities - enumeration: [0] - efficiency(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - efficiency of the detector - dimensions: - rank: 3 - dim: [[1, i], [2, j], [3, k]] - wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - This field can be two things: - - #. For a pixel detector it provides the nominal wavelength - for which the detector has been calibrated. - - #. For other detectors this field has to be seen together with - the efficiency field above. - For some detectors, the efficiency is wavelength dependent. - Thus this field provides the wavelength axis for the efficiency field. - In this use case, the efficiency and wavelength arrays must - have the same dimensionality. - dimensions: - rank: 3 - dim: [[1, i], [2, j], [3, k]] - real_time(NX_NUMBER): - unit: NX_TIME - doc: | - Real-time of the exposure (use this if exposure time varies for - each array element, otherwise use ``count_time`` field). - - Most often there is a single real time value that is constant across - an entire image frame. In such cases, only a 1-D array is needed. - But there are detectors in which the real time - changes per pixel. In that case, more than one dimension is needed. Therefore - the rank of this field should be less than or equal to (detector rank + 1). - dimensions: - rank: 3 - dim: [[1, nP], [2, i], [3, j]] - start_time(NX_FLOAT): - unit: NX_TIME - doc: | - start time for each frame, with the ``start`` attribute as absolute reference - dimensions: - rank: 1 - dim: [[1, nP]] - \@start: - type: NX_DATE_TIME - stop_time(NX_FLOAT): - unit: NX_TIME - doc: | - stop time for each frame, with the ``start`` attribute as absolute reference - dimensions: - rank: 1 - dim: [[1, nP]] - \@start: - type: NX_DATE_TIME - calibration_date(NX_DATE_TIME): - doc: | - date of last calibration (geometry and/or efficiency) measurements - calibration_method(NXnote): - doc: | - summary of conversion of array data to pixels (e.g. polynomial - approximations) and location of details of the calibrations - layout: - doc: | - How the detector is represented - enumeration: [point, linear, area] - count_time(NX_NUMBER): - unit: NX_TIME - doc: | - Elapsed actual counting time - dimensions: - rank: 1 - dim: [[1, nP]] - data_file(NXnote): - (NXcollection): - doc: | - Use this group to provide other data related to this NXdetector group. - sequence_number(NX_INT): - doc: | - In order to properly sort the order of the images taken in (for - example) a tomography experiment, a sequence number is stored with each - image. - dimensions: - rank: 1 - dim: [[1, nP]] - beam_center_x(NX_FLOAT): - unit: NX_LENGTH - doc: | - This is the x position where the direct beam would hit the detector. - This is a length and can be outside of the actual - detector. The length can be in physical units or pixels - as documented by the units attribute. - beam_center_y(NX_FLOAT): - unit: NX_LENGTH - doc: | - This is the y position where the direct beam would hit the detector. - This is a length and can be outside of the actual - detector. The length can be in physical units or pixels - as documented by the units attribute. - frame_start_number(NX_INT): - doc: | - This is the start number of the first frame of a scan. In protein crystallography measurements one - often scans a couple of frames on a give sample, then does something else, - then returns to the same sample and scans some more frames. Each time with - a new data file. This number helps concatenating such measurements. - diameter(NX_FLOAT): - unit: NX_LENGTH - doc: | - The diameter of a cylindrical detector - acquisition_mode(NX_CHAR): - doc: | - The acquisition mode of the detector. - enumeration: [gated, triggered, summed, event, histogrammed, decimated, pulse counting] - angular_calibration_applied(NX_BOOLEAN): - doc: | - True when the angular calibration has been applied in the - electronics, false otherwise. - angular_calibration(NX_FLOAT): - doc: | - Angular calibration data. - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - flatfield_applied(NX_BOOLEAN): - doc: | - True when the flat field correction has been applied in the - electronics, false otherwise. - flatfield(NX_FLOAT): - doc: | - Flat field correction data. - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - flatfield_errors(NX_FLOAT): - doc: | - Errors of the flat field correction data. - The form flatfield_error is deprecated. - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - pixel_mask_applied(NX_BOOLEAN): - doc: | - True when the pixel mask correction has been applied in the - electronics, false otherwise. - pixel_mask(NX_INT): - doc: | - The 32-bit pixel mask for the detector. Can be either one mask - for the whole dataset (i.e. an array with indices i, j) or - each frame can have its own mask (in which case it would be - an array with indices np, i, j). - - Contains a bit field for each pixel to signal dead, - blind or high or otherwise unwanted or undesirable pixels. - They have the following meaning: - - .. can't make a table here, a bullet list will have to do for now - - * bit 0: gap (pixel with no sensor) - * bit 1: dead - * bit 2: under responding - * bit 3: over responding - * bit 4: noisy - * bit 5: -undefined- - * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) - * bit 7: -undefined- - * bit 8: user defined mask (e.g. around beamstop) - * bits 9-30: -undefined- - * bit 31: virtual pixel (corner pixel with interpolated value) - - Normal data analysis software would - not take pixels into account - when a bit in (mask & 0x0000FFFF) is - set. Tag bit in the upper - two bytes would indicate special pixel - properties that normally - would not be a sole reason to reject the - intensity value (unless - lower bits are set. - - If the full bit depths is not required, providing a - mask with fewer bits is permissible. - - If needed, additional pixel masks can be specified by - including additional entries named pixel_mask_N, where - N is an integer. For example, a general bad pixel mask - could be specified in pixel_mask that indicates noisy - and dead pixels, and an additional pixel mask from - experiment-specific shadowing could be specified in - pixel_mask_2. The cumulative mask is the bitwise OR - of pixel_mask and any pixel_mask_N entries. - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - image_key(NX_INT): - doc: | - This field allow to distinguish different types of exposure to the same detector "data" field. - Some techniques require frequent (re-)calibration inbetween measuremnts and this way of - recording the different measurements preserves the chronological order with is important for - correct processing. - - This is used for example in tomography (`:ref:`NXtomo`) sample projections, - dark and flat images, a magic number is recorded per frame. - - The key is as follows: - - * projection (sample) = 0 - * flat field = 1 - * dark field = 2 - * invalid = 3 - * background (no sample, but buffer where applicable) = 4 - - In cases where the data is of type :ref:`NXlog` this can also be an NXlog. - dimensions: - rank: 1 - dim: [[1, np]] - countrate_correction_applied(NX_BOOLEAN): - doc: | - Counting detectors usually are not able to measure all incoming particles, - especially at higher count-rates. Count-rate correction is applied to - account for these errors. - - True when count-rate correction has been applied, false otherwise. - countrate_correction_lookup_table(NX_NUMBER): - doc: | - The countrate_correction_lookup_table defines the LUT used for count-rate - correction. It maps a measured count :math:`c` to its corrected value - :math:`countrate\_correction\_lookup\_table[c]`. - - :math:`m` denotes the length of the table. - dimensions: - rank: 1 - dim: [[1, m]] - virtual_pixel_interpolation_applied(NX_BOOLEAN): - doc: | - True when virtual pixel interpolation has been applied, false otherwise. - - When virtual pixel interpolation is applied, values of some pixels may - contain interpolated values. For example, to account for space between - readout chips on a module, physical pixels on edges and corners between - chips may have larger sensor areas and counts may be distributed between - their logical pixels. - bit_depth_readout(NX_INT): - doc: | - How many bits the electronics reads per pixel. - With CCD's and single photon counting detectors, - this must not align with traditional integer sizes. - This can be 4, 8, 12, 14, 16, ... - detector_readout_time(NX_FLOAT): - unit: NX_TIME - doc: | - Time it takes to read the detector (typically milliseconds). - This is important to know for time resolved experiments. - trigger_delay_time(NX_FLOAT): - unit: NX_TIME - doc: | - Time it takes to start exposure after a trigger signal has been received. - This is the reaction time of the detector firmware after receiving the trigger signal - to when the detector starts to acquire the exposure, including any user set delay.. - This is important to know for time resolved experiments. - trigger_delay_time_set(NX_FLOAT): - unit: NX_TIME - doc: | - User-specified trigger delay. - trigger_internal_delay_time(NX_FLOAT): - unit: NX_TIME - doc: | - Time it takes to start exposure after a trigger signal has been received. - This is the reaction time of the detector hardware after receiving the - trigger signal to when the detector starts to acquire the exposure. - It forms the lower boundary of the trigger_delay_time when the user - does not request an additional delay. - trigger_dead_time(NX_FLOAT): - unit: NX_TIME - doc: | - Time during which no new trigger signal can be accepted. - Typically this is the - trigger_delay_time + exposure_time + readout_time. - This is important to know for time resolved experiments. - frame_time(NX_FLOAT): - unit: NX_TIME - doc: | - This is time for each frame. This is exposure_time + readout time. - dimensions: - rank: 1 - dim: [[1, nP]] - gain_setting(NX_CHAR): - doc: | - The gain setting of the detector. This is a detector-specific value - meant to document the gain setting of the detector during data - collection, for detectors with multiple available gain settings. - - Examples of gain settings include: - - * ``standard`` - * ``fast`` - * ``auto`` - * ``high`` - * ``medium`` - * ``low`` - * ``mixed high to medium`` - * ``mixed medium to low`` - - Developers are encouraged to use one of these terms, or to submit - additional terms to add to the list. - saturation_value(NX_NUMBER): - doc: | - The value at which the detector goes into saturation. - Especially common to CCD detectors, the data - is known to be invalid above this value. - - For example, given a saturation_value and an underload_value, the valid - pixels are those less than or equal to the saturation_value and greater - than or equal to the underload_value. - - The precise type should match the type of the data. - underload_value(NX_NUMBER): - doc: | - The lowest value at which pixels for this detector would be reasonably - measured. The data is known to be invalid below this value. - - For example, given a saturation_value and an underload_value, the valid - pixels are those less than or equal to the saturation_value and greater - than or equal to the underload_value. - - The precise type should match the type of the data. - number_of_cycles(NX_INT): - doc: | - CCD images are sometimes constructed by summing - together multiple short exposures in the - electronics. This reduces background etc. - This is the number of short exposures used to sum - images for an image. - sensor_material(NX_CHAR): - doc: | - At times, radiation is not directly sensed by the detector. - Rather, the detector might sense the output from some - converter like a scintillator. - This is the name of this converter material. - sensor_thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - At times, radiation is not directly sensed by the detector. - Rather, the detector might sense the output from some - converter like a scintillator. - This is the thickness of this converter material. - threshold_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - Single photon counter detectors can be adjusted - for a certain energy range in which they - work optimally. This is the energy setting for this. - (NXdetector_module): - doc: | - For use in special cases where the data in NXdetector - is represented in several parts, each with a separate geometry. - pixel_shape(choice): - (NXoff_geometry): - doc: | - Shape description of each pixel. Use only if all pixels in the detector - are of uniform shape. - (NXcylindrical_geometry): - doc: | - Shape description of each pixel. Use only if all pixels in the detector - are of uniform shape and require being described by cylinders. - detector_shape(choice): - (NXoff_geometry): - doc: | - Shape description of the whole detector. Use only if pixels in the - detector are not of uniform shape. - (NXcylindrical_geometry): - doc: | - Shape description of the whole detector. Use only if pixels in the - detector are not of uniform shape and require being described by cylinders. - amplifier_type(NX_CHAR): - doc: | - Type of electron amplifier, MCP, channeltron, etc. - detector_type(NX_CHAR): - doc: | - Description of the detector type, DLD, Phosphor+CCD, CMOS. - detector_voltage(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - Voltage applied to detector. - amplifier_voltage(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - Voltage applied to the amplifier. - amplifier_bias(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - The low voltage of the amplifier migh not be the ground. - sensor_size(NX_FLOAT): - unit: NX_LENGTH - doc: | - Size of each imaging sensor chip on the detector. - sensor_count(NX_INT): - unit: NX_UNITLESS - doc: | - Number of imaging sensor chips on the detector. - sensor_pixel_size(NX_FLOAT): - unit: NX_LENGTH - doc: | - Physical size of the pixels of the imaging chip on the detector. - sensor_pixels(NX_INT): - unit: NX_UNITLESS - doc: | - Number of raw active elements in each dimension. Important for swept scans. - (NXfabrication): - (NXdata): - doc: | - raw data output from the detector - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - The reference point of the detector is the center of the first pixel. - In complex geometries the NXoff_geometry groups can be used to provide an unambiguous reference. - (NXtransformations): - doc: | - 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e8f4b233b107e53ec244f7ab7fd827b3f17e82c00e4223d832bca27d347fb5e6 -# -# -# -# -# -# -# -# These symbols will be used below to illustrate the coordination of the rank and sizes of datasets and the -# preferred ordering of the dimensions. Each of these are optional (so the rank of the datasets -# will vary according to the situation) and the general ordering principle is slowest to fastest. -# The type of each dimension should follow the order of scan points, detector output (e.g. pixels), -# then time-of-flight (i.e. spectroscopy, spectrometry). Note that the output of a detector is not limited -# to single values (0D), lists (1D) and images (2), but three or higher dimensional arrays can be produced -# by a detector at each trigger. -# -# -# number of scan points (only present in scanning measurements) -# number of detector pixels in the first (slowest) direction -# number of detector pixels in the second (faster) direction -# number of detector pixels in the third (if necessary, fastest) direction -# number of bins in the time-of-flight histogram -# -# -# -# A detector, detector bank, or multidetector. -# -# -# -# Total time of flight -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Total time of flight -# -# -# -# -# In DAQ clock pulses -# -# -# -# -# -# -# Clock frequency in Hz -# -# -# -# -# -# Identifier for detector (pixels) -# Can be multidimensional, if needed -# -# -# -# -# -# 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. -# -# -# -# -# -# -# -# -# -# -# Title of measurement -# -# -# -# Integral of data as check of data integrity -# -# -# -# -# -# -# The best estimate of the uncertainty in the data value (array size should match the data field). Where -# possible, this should be the standard deviation, which has the same units -# as the data. The form data_error is deprecated. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Offset from the detector center in x-direction. -# Can be multidimensional when needed. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# x-axis offset from detector center -# -# -# -# -# -# Offset from the detector center in the y-direction. -# Can be multidimensional when different values are required for each pixel. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# y-axis offset from detector center -# -# -# -# -# -# -# Offset from the detector center in the z-direction. -# Can be multidimensional when different values are required for each pixel. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# y-axis offset from detector center -# -# -# -# -# -# This is the distance to the previous component in the -# instrument; most often the sample. The usage depends on the -# nature of the detector: Most often it is the distance of the -# detector assembly. But there are irregular detectors. In this -# case the distance must be specified for each detector pixel. -# -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# -# -# -# -# -# -# -# This is the polar angle of the detector towards the previous -# component in the instrument; most often the sample. -# The usage depends on the -# nature of the detector. -# Most often it is the polar_angle of the detector assembly. -# But there are irregular detectors. -# In this -# case, the polar_angle must be specified for each detector pixel. -# -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# -# -# -# -# -# -# -# This is the azimuthal angle angle of the detector towards -# the previous component in the instrument; most often the sample. -# The usage depends on the -# nature of the detector. -# Most often it is the azimuthal_angle of the detector assembly. -# But there are irregular detectors. -# In this -# case, the azimuthal_angle must be specified for each detector pixel. -# -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# -# -# -# -# -# -# name/manufacturer/model/etc. information -# -# -# -# Serial number for the detector -# -# -# -# Local name for the detector -# -# -# -# Position and orientation of detector -# -# -# -# Solid angle subtended by the detector at the sample -# -# -# -# -# -# -# -# -# -# Size of each detector pixel. If it is scalar all pixels are the same size. -# -# -# -# -# -# -# -# -# -# Size of each detector pixel. If it is scalar all pixels are the same size -# -# -# -# -# -# -# -# -# Detector dead time -# -# -# -# -# -# -# -# -# -# Detector gas pressure -# -# -# -# -# -# -# -# -# maximum drift space dimension -# -# -# -# Crate number of detector -# -# -# -# -# -# -# -# Equivalent local term -# -# -# -# -# Slot number of detector -# -# -# -# -# -# -# -# Equivalent local term -# -# -# -# -# Input number of detector -# -# -# -# -# -# -# -# Equivalent local term -# -# -# -# -# -# Description of type such as He3 gas cylinder, He3 PSD, scintillator, -# fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, -# CMOS, ... -# -# -# -# -# -# Group containing the description and metadata for a single channel from a multi-channel -# detector. -# -# Given an :ref:`NXdata` group linked as part of an NXdetector group that has an axis with -# named channels (see the example in :ref:`NXdata </NXdata@default_slice-attribute>`), -# the NXdetector will have a series of NXdetector_channel groups, one for each channel, -# named CHANNELNAME_channel. -# -# -# -# -# Spectral efficiency of detector with respect to e.g. wavelength -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# efficiency of the detector -# -# -# -# -# -# -# -# -# -# -# This field can be two things: -# -# #. For a pixel detector it provides the nominal wavelength -# for which the detector has been calibrated. -# -# #. For other detectors this field has to be seen together with -# the efficiency field above. -# For some detectors, the efficiency is wavelength dependent. -# Thus this field provides the wavelength axis for the efficiency field. -# In this use case, the efficiency and wavelength arrays must -# have the same dimensionality. -# -# -# -# -# -# -# -# -# -# -# -# Real-time of the exposure (use this if exposure time varies for -# each array element, otherwise use ``count_time`` field). -# -# Most often there is a single real time value that is constant across -# an entire image frame. In such cases, only a 1-D array is needed. -# But there are detectors in which the real time -# changes per pixel. In that case, more than one dimension is needed. Therefore -# the rank of this field should be less than or equal to (detector rank + 1). -# -# -# -# -# -# -# -# -# -# start time for each frame, with the ``start`` attribute as absolute reference -# -# -# -# -# -# -# stop time for each frame, with the ``start`` attribute as absolute reference -# -# -# -# -# -# -# -# -# date of last calibration (geometry and/or efficiency) measurements -# -# -# -# -# -# summary of conversion of array data to pixels (e.g. polynomial -# approximations) and location of details of the calibrations -# -# -# -# -# How the detector is represented -# -# -# -# -# -# -# -# -# -# Elapsed actual counting time -# -# -# -# -# -# -# -# -# -# -# Use this group to provide other data related to this NXdetector group. -# -# -# -# -# -# In order to properly sort the order of the images taken in (for -# example) a tomography experiment, a sequence number is stored with each -# image. -# -# -# -# -# -# -# -# -# -# This is the x position where the direct beam would hit the detector. -# This is a length and can be outside of the actual -# detector. The length can be in physical units or pixels -# as documented by the units attribute. -# -# -# -# -# -# This is the y position where the direct beam would hit the detector. -# This is a length and can be outside of the actual -# detector. The length can be in physical units or pixels -# as documented by the units attribute. -# -# -# -# -# -# This is the start number of the first frame of a scan. In protein crystallography measurements one -# often scans a couple of frames on a give sample, then does something else, -# then returns to the same sample and scans some more frames. Each time with -# a new data file. This number helps concatenating such measurements. -# -# -# -# -# The diameter of a cylindrical detector -# -# -# -# The acquisition mode of the detector. -# -# -# -# -# -# -# -# -# -# -# -# -# True when the angular calibration has been applied in the -# electronics, false otherwise. -# -# -# -# Angular calibration data. -# -# -# -# -# -# -# -# True when the flat field correction has been applied in the -# electronics, false otherwise. -# -# -# -# Flat field correction data. -# -# -# -# -# -# -# -# Errors of the flat field correction data. -# The form flatfield_error is deprecated. -# -# -# -# -# -# -# -# -# True when the pixel mask correction has been applied in the -# electronics, false otherwise. -# -# -# -# -# The 32-bit pixel mask for the detector. Can be either one mask -# for the whole dataset (i.e. an array with indices i, j) or -# each frame can have its own mask (in which case it would be -# an array with indices np, i, j). -# -# Contains a bit field for each pixel to signal dead, -# blind or high or otherwise unwanted or undesirable pixels. -# They have the following meaning: -# -# .. can't make a table here, a bullet list will have to do for now -# -# * bit 0: gap (pixel with no sensor) -# * bit 1: dead -# * bit 2: under responding -# * bit 3: over responding -# * bit 4: noisy -# * bit 5: -undefined- -# * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) -# * bit 7: -undefined- -# * bit 8: user defined mask (e.g. around beamstop) -# * bits 9-30: -undefined- -# * bit 31: virtual pixel (corner pixel with interpolated value) -# -# Normal data analysis software would -# not take pixels into account -# when a bit in (mask & 0x0000FFFF) is -# set. Tag bit in the upper -# two bytes would indicate special pixel -# properties that normally -# would not be a sole reason to reject the -# intensity value (unless -# lower bits are set. -# -# If the full bit depths is not required, providing a -# mask with fewer bits is permissible. -# -# If needed, additional pixel masks can be specified by -# including additional entries named pixel_mask_N, where -# N is an integer. For example, a general bad pixel mask -# could be specified in pixel_mask that indicates noisy -# and dead pixels, and an additional pixel mask from -# experiment-specific shadowing could be specified in -# pixel_mask_2. The cumulative mask is the bitwise OR -# of pixel_mask and any pixel_mask_N entries. -# -# -# -# -# -# -# -# -# -# This field allow to distinguish different types of exposure to the same detector "data" field. -# Some techniques require frequent (re-)calibration inbetween measuremnts and this way of -# recording the different measurements preserves the chronological order with is important for -# correct processing. -# -# This is used for example in tomography (`:ref:`NXtomo`) sample projections, -# dark and flat images, a magic number is recorded per frame. -# -# The key is as follows: -# -# * projection (sample) = 0 -# * flat field = 1 -# * dark field = 2 -# * invalid = 3 -# * background (no sample, but buffer where applicable) = 4 -# -# In cases where the data is of type :ref:`NXlog` this can also be an NXlog. -# -# -# -# -# -# -# -# -# Counting detectors usually are not able to measure all incoming particles, -# especially at higher count-rates. Count-rate correction is applied to -# account for these errors. -# -# True when count-rate correction has been applied, false otherwise. -# -# -# -# -# The countrate_correction_lookup_table defines the LUT used for count-rate -# correction. It maps a measured count :math:`c` to its corrected value -# :math:`countrate\_correction\_lookup\_table[c]`. -# -# :math:`m` denotes the length of the table. -# -# -# -# -# -# -# -# True when virtual pixel interpolation has been applied, false otherwise. -# -# When virtual pixel interpolation is applied, values of some pixels may -# contain interpolated values. For example, to account for space between -# readout chips on a module, physical pixels on edges and corners between -# chips may have larger sensor areas and counts may be distributed between -# their logical pixels. -# -# -# -# -# How many bits the electronics reads per pixel. -# With CCD's and single photon counting detectors, -# this must not align with traditional integer sizes. -# This can be 4, 8, 12, 14, 16, ... -# -# -# -# -# Time it takes to read the detector (typically milliseconds). -# This is important to know for time resolved experiments. -# -# -# -# -# Time it takes to start exposure after a trigger signal has been received. -# This is the reaction time of the detector firmware after receiving the trigger signal -# to when the detector starts to acquire the exposure, including any user set delay.. -# This is important to know for time resolved experiments. -# -# -# -# -# User-specified trigger delay. -# -# -# -# -# Time it takes to start exposure after a trigger signal has been received. -# This is the reaction time of the detector hardware after receiving the -# trigger signal to when the detector starts to acquire the exposure. -# It forms the lower boundary of the trigger_delay_time when the user -# does not request an additional delay. -# -# -# -# -# Time during which no new trigger signal can be accepted. -# Typically this is the -# trigger_delay_time + exposure_time + readout_time. -# This is important to know for time resolved experiments. -# -# -# -# -# This is time for each frame. This is exposure_time + readout time. -# -# -# -# -# -# -# -# The gain setting of the detector. This is a detector-specific value -# meant to document the gain setting of the detector during data -# collection, for detectors with multiple available gain settings. -# -# Examples of gain settings include: -# -# * ``standard`` -# * ``fast`` -# * ``auto`` -# * ``high`` -# * ``medium`` -# * ``low`` -# * ``mixed high to medium`` -# * ``mixed medium to low`` -# -# Developers are encouraged to use one of these terms, or to submit -# additional terms to add to the list. -# -# -# -# -# The value at which the detector goes into saturation. -# Especially common to CCD detectors, the data -# is known to be invalid above this value. -# -# For example, given a saturation_value and an underload_value, the valid -# pixels are those less than or equal to the saturation_value and greater -# than or equal to the underload_value. -# -# The precise type should match the type of the data. -# -# -# -# -# The lowest value at which pixels for this detector would be reasonably -# measured. The data is known to be invalid below this value. -# -# For example, given a saturation_value and an underload_value, the valid -# pixels are those less than or equal to the saturation_value and greater -# than or equal to the underload_value. -# -# The precise type should match the type of the data. -# -# -# -# -# CCD images are sometimes constructed by summing -# together multiple short exposures in the -# electronics. This reduces background etc. -# This is the number of short exposures used to sum -# images for an image. -# -# -# -# -# At times, radiation is not directly sensed by the detector. -# Rather, the detector might sense the output from some -# converter like a scintillator. -# This is the name of this converter material. -# -# -# -# -# At times, radiation is not directly sensed by the detector. -# Rather, the detector might sense the output from some -# converter like a scintillator. -# This is the thickness of this converter material. -# -# -# -# -# Single photon counter detectors can be adjusted -# for a certain energy range in which they -# work optimally. This is the energy setting for this. -# -# -# -# -# For use in special cases where the data in NXdetector -# is represented in several parts, each with a separate geometry. -# -# -# -# -# -# Shape description of each pixel. Use only if all pixels in the detector -# are of uniform shape. -# -# -# -# -# Shape description of each pixel. Use only if all pixels in the detector -# are of uniform shape and require being described by cylinders. -# -# -# -# -# -# -# Shape description of the whole detector. Use only if pixels in the -# detector are not of uniform shape. -# -# -# -# -# Shape description of the whole detector. Use only if pixels in the -# detector are not of uniform shape and require being described by cylinders. -# -# -# -# -# -# Type of electron amplifier, MCP, channeltron, etc. -# -# -# -# -# Description of the detector type, DLD, Phosphor+CCD, CMOS. -# -# -# -# -# Voltage applied to detector. -# -# -# -# -# Voltage applied to the amplifier. -# -# -# -# -# The low voltage of the amplifier migh not be the ground. -# -# -# -# -# Size of each imaging sensor chip on the detector. -# -# -# -# -# Number of imaging sensor chips on the detector. -# -# -# -# -# Physical size of the pixels of the imaging chip on the detector. -# -# -# -# -# Number of raw active elements in each dimension. Important for swept scans. -# -# -# -# -# -# raw data output from the detector -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# The reference point of the detector is the center of the first pixel. -# In complex geometries the NXoff_geometry groups can be used to provide an unambiguous reference. -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# diff --git a/base_classes/nyaml/NXdetector_channel.yaml b/base_classes/nyaml/NXdetector_channel.yaml deleted file mode 100644 index d4a6686901..0000000000 --- a/base_classes/nyaml/NXdetector_channel.yaml +++ /dev/null @@ -1,277 +0,0 @@ -category: base -doc: | - Description and metadata for a single channel from a multi-channel detector. - - Given an :ref:`NXdata` group linked as part of an NXdetector group that has an axis with named channels (see the - example in :ref:`NXdata `), the NXdetector will have a series of NXdetector_channel groups, one for each - channel, named CHANNELNAME_channel. - - Example, given these axes in the NXdata group:: - - @axes = ["image_id", "channel", ".", "."] - - And this list of channels in the NXdata group:: - - channel = ["threshold_1", "threshold_2", "difference"] - - The NXdetector group would have three NXdetector_channel groups:: - - detector:NXdetector - ... - threshold_1_channel:NXdetector_channel - threshold_energy = float - flatfield = float[i, j] - pixel_mask = uint[i, j] - flatfield_applied = bool - pixel_mask_applied = bool - threshold_2_channel:NXdetector_channel - threshold_energy = float - flatfield = float[i, j] - pixel_mask = uint[i, j] - flatfield_applied = bool - pixel_mask_applied = bool - difference_channel:NXdetector_channel - threshold_energy = float[2] -symbols: - doc: | - These symbols will be used below to illustrate the coordination of the rank and sizes of datasets and the - preferred ordering of the dimensions. Each of these are optional (so the rank of the datasets - will vary according to the situation) and the general ordering principle is slowest to fastest. - The type of each dimension should follow the order of scan points, detector output (e.g. pixels), - then time-of-flight (i.e. spectroscopy, spectrometry). Note that the output of a detector is not limited - to single values (0D), lists (1D) and images (2D), but three or higher dimensional arrays can be produced - by a detector at each trigger. - dataRank: | - Rank of the ``data`` field associated with this detector - nP: | - number of scan points - i: | - number of detector pixels in the slowest direction - j: | - number of detector pixels in the second slowest direction - k: | - number of detector pixels in the third slowest direction -type: group -(NXobject)NXdetector_channel: - threshold_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - Energy at which a photon will be recorded - flatfield_applied(NX_BOOLEAN): - doc: | - True when the flat field correction has been applied in the - electronics, false otherwise. - flatfield(NX_NUMBER): - doc: | - Response of each pixel given a constant input - dimensions: - rank: dataRank - dim: [[1, i], [2, j], [3, k]] - dim_parameters: - required: ['false'] - flatfield_errors(NX_FLOAT): - doc: | - Errors of the flat field correction data. - The form flatfield_error is deprecated. - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - pixel_mask_applied(NX_BOOLEAN): - doc: | - True when the pixel mask correction has been applied in the - electronics, false otherwise. - pixel_mask(NX_INT): - doc: | - Custom pixel mask for this channel. May include nP as the first dimension for - masks that vary for each scan point. - dimensions: - rank: dataRank - dim: [[2, i], [3, j], [4, k]] - dim_parameters: - required: ['false'] - saturation_value(NX_NUMBER): - doc: | - The value at which the detector goes into saturation. - Especially common to CCD detectors, the data - is known to be invalid above this value. - - For example, given a saturation_value and an underload_value, the valid - pixels are those less than or equal to the saturation_value and greater - than or equal to the underload_value. - - The precise type should match the type of the data. - underload_value(NX_NUMBER): - doc: | - The lowest value at which pixels for this detector would be reasonably - measured. The data is known to be invalid below this value. - - For example, given a saturation_value and an underload_value, the valid - pixels are those less than or equal to the saturation_value and greater - than or equal to the underload_value. - - The precise type should match the type of the data. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2ff06880066c8bb147890ed92c1b6cc7a8bdeb77b6253fc511e01bdc9b961c15 -# -# -# -# -# -# -# -# These symbols will be used below to illustrate the coordination of the rank and sizes of datasets and the -# preferred ordering of the dimensions. Each of these are optional (so the rank of the datasets -# will vary according to the situation) and the general ordering principle is slowest to fastest. -# The type of each dimension should follow the order of scan points, detector output (e.g. pixels), -# then time-of-flight (i.e. spectroscopy, spectrometry). Note that the output of a detector is not limited -# to single values (0D), lists (1D) and images (2D), but three or higher dimensional arrays can be produced -# by a detector at each trigger. -# -# -# Rank of the ``data`` field associated with this detector -# number of scan points -# number of detector pixels in the slowest direction -# number of detector pixels in the second slowest direction -# number of detector pixels in the third slowest direction -# -# -# -# Description and metadata for a single channel from a multi-channel detector. -# -# Given an :ref:`NXdata` group linked as part of an NXdetector group that has an axis with named channels (see the -# example in :ref:`NXdata </NXdata@default_slice-attribute>`), the NXdetector will have a series of NXdetector_channel groups, one for each -# channel, named CHANNELNAME_channel. -# -# Example, given these axes in the NXdata group:: -# -# @axes = ["image_id", "channel", ".", "."] -# -# And this list of channels in the NXdata group:: -# -# channel = ["threshold_1", "threshold_2", "difference"] -# -# The NXdetector group would have three NXdetector_channel groups:: -# -# detector:NXdetector -# ... -# threshold_1_channel:NXdetector_channel -# threshold_energy = float -# flatfield = float[i, j] -# pixel_mask = uint[i, j] -# flatfield_applied = bool -# pixel_mask_applied = bool -# threshold_2_channel:NXdetector_channel -# threshold_energy = float -# flatfield = float[i, j] -# pixel_mask = uint[i, j] -# flatfield_applied = bool -# pixel_mask_applied = bool -# difference_channel:NXdetector_channel -# threshold_energy = float[2] -# -# -# -# Energy at which a photon will be recorded -# -# -# -# -# True when the flat field correction has been applied in the -# electronics, false otherwise. -# -# -# -# -# Response of each pixel given a constant input -# -# -# -# -# -# -# -# -# -# Errors of the flat field correction data. -# The form flatfield_error is deprecated. -# -# -# -# -# -# -# -# -# -# True when the pixel mask correction has been applied in the -# electronics, false otherwise. -# -# -# -# -# -# Custom pixel mask for this channel. May include nP as the first dimension for -# masks that vary for each scan point. -# -# -# -# -# -# -# -# -# -# -# The value at which the detector goes into saturation. -# Especially common to CCD detectors, the data -# is known to be invalid above this value. -# -# For example, given a saturation_value and an underload_value, the valid -# pixels are those less than or equal to the saturation_value and greater -# than or equal to the underload_value. -# -# The precise type should match the type of the data. -# -# -# -# -# -# The lowest value at which pixels for this detector would be reasonably -# measured. The data is known to be invalid below this value. -# -# For example, given a saturation_value and an underload_value, the valid -# pixels are those less than or equal to the saturation_value and greater -# than or equal to the underload_value. -# -# The precise type should match the type of the data. -# -# -# diff --git a/base_classes/nyaml/NXdetector_group.yaml b/base_classes/nyaml/NXdetector_group.yaml deleted file mode 100644 index 36b716eb63..0000000000 --- a/base_classes/nyaml/NXdetector_group.yaml +++ /dev/null @@ -1,182 +0,0 @@ -category: base -doc: | - Logical grouping of detectors. When used, describes a group of detectors. - - Each detector is represented as an NXdetector - with its own detector data array. Each detector data array - may be further decomposed into array sections by use of - NXdetector_module groups. Detectors can be grouped logically - together using NXdetector_group. Groups can be further grouped - hierarchically in a single NXdetector_group (for example, if - there are multiple detectors at an endstation or multiple - endstations at a facility). Alternatively, multiple - NXdetector_groups can be provided. - - The groups are defined hierarchically, with names given - in the group_names field, unique identifying indices given - in the field group_index, and the level in the hierarchy - given in the group_parent field. For example if an x-ray - detector group, DET, consists of four detectors in a - rectangular array:: - - DTL DTR - DLL DLR - - We could have:: - - group_names: ["DET", "DTL", "DTR", "DLL", "DLR"] - group_index: [1, 2, 3, 4, 5] - group_parent: [-1, 1, 1, 1, 1] -type: group -NXdetector_group(NXobject): - group_names(NX_CHAR): - doc: | - An array of the names of the detectors given in NXdetector - groups or the names of hierarchical groupings of detectors - given as names of NXdetector_group groups or in - NXdetector_group group_names and group_parent fields as - having children. - group_index(NX_INT): - doc: | - An array of unique identifiers for detectors or groupings - of detectors. - - Each ID is a unique ID for the corresponding detector or group - named in the field group_names. The IDs are positive integers - starting with 1. - dimensions: - dim: [[1, i]] - group_parent(NX_INT): - doc: | - An array of the hierarchical levels of the parents of detectors - or groupings of detectors. - - A top-level grouping has parent level -1. - dimensions: - dim: [[1, ]] - dim_parameters: - ref: ['group_index'] - group_type(NX_INT): - doc: | - Code number for group type, e.g. bank=1, tube=2 etc. - dimensions: - dim: [[1, ]] - dim_parameters: - ref: ['group_index'] - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# fef1c65c76b06c79fe2f874bd122ffcb8cdf9c895464aeddb7658e8379e30beb -# -# -# -# -# -# Logical grouping of detectors. When used, describes a group of detectors. -# -# Each detector is represented as an NXdetector -# with its own detector data array. Each detector data array -# may be further decomposed into array sections by use of -# NXdetector_module groups. Detectors can be grouped logically -# together using NXdetector_group. Groups can be further grouped -# hierarchically in a single NXdetector_group (for example, if -# there are multiple detectors at an endstation or multiple -# endstations at a facility). Alternatively, multiple -# NXdetector_groups can be provided. -# -# The groups are defined hierarchically, with names given -# in the group_names field, unique identifying indices given -# in the field group_index, and the level in the hierarchy -# given in the group_parent field. For example if an x-ray -# detector group, DET, consists of four detectors in a -# rectangular array:: -# -# DTL DTR -# DLL DLR -# -# We could have:: -# -# group_names: ["DET", "DTL", "DTR", "DLL", "DLR"] -# group_index: [1, 2, 3, 4, 5] -# group_parent: [-1, 1, 1, 1, 1] -# -# -# -# An array of the names of the detectors given in NXdetector -# groups or the names of hierarchical groupings of detectors -# given as names of NXdetector_group groups or in -# NXdetector_group group_names and group_parent fields as -# having children. -# -# -# -# -# An array of unique identifiers for detectors or groupings -# of detectors. -# -# Each ID is a unique ID for the corresponding detector or group -# named in the field group_names. The IDs are positive integers -# starting with 1. -# -# -# -# -# -# An array of the hierarchical levels of the parents of detectors -# or groupings of detectors. -# -# A top-level grouping has parent level -1. -# -# -# -# Code number for group type, e.g. bank=1, tube=2 etc. -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# diff --git a/base_classes/nyaml/NXdetector_module.yaml b/base_classes/nyaml/NXdetector_module.yaml deleted file mode 100644 index a9d614584a..0000000000 --- a/base_classes/nyaml/NXdetector_module.yaml +++ /dev/null @@ -1,302 +0,0 @@ -category: base -doc: | - Geometry and logical description of a detector module. When used, child group to NXdetector. - - Many detectors consist of multiple - smaller modules. Sometimes it is important to know the exact position of such - modules. - This is the purpose of this group. It is a child group to NXdetector. - - Note, the pixel size is given as values in the array fast_pixel_direction and slow_pixel_direction. -type: group -NXdetector_module(NXobject): - data_origin(NX_INT): - doc: | - A dimension-2 or dimension-3 field which gives the indices - of the origin of the hyperslab of data for this module in the - main area detector image in the parent NXdetector module. - - The data_origin is 0-based. - - The frame number dimension (np) is omitted. Thus the - data_origin field for a dimension-2 dataset with indices (np, i, j) - will be an array with indices (i, j), and for a dimension-3 - dataset with indices (np, i, j, k) will be an array with indices - (i, j, k). - - The :ref:`order ` of indices (i, j or i, j, k) is slow to fast. - data_size(NX_INT): - doc: | - Two or three values for the size of the module in pixels in - each direction. Dimensionality and order of indices is the - same as for data_origin. - module_offset(NX_NUMBER): - unit: NX_LENGTH - doc: | - Offset of the module in regards to the origin of the detector in an - arbitrary direction. - \@transformation_type: - enumeration: [translation] - \@vector: - type: NX_NUMBER - doc: | - Three values that define the axis for this transformation - \@offset: - type: NX_NUMBER - doc: | - A fixed offset applied before the transformation (three vector components). - \@offset_units: - type: NX_CHAR - doc: | - Units of the offset. - \@depends_on: - type: NX_CHAR - doc: | - Points to the path of the next element in the geometry chain. - fast_pixel_direction(NX_NUMBER): - unit: NX_LENGTH - doc: | - Values along the direction of :ref:`fastest varying ` :index:`pixel direction`. Each value in this - array is the size of a pixel in the units specified. Alternatively, if only one - value is given, all pixels in this direction have the same value. The direction - itself is given through the vector attribute. - \@transformation_type: - enumeration: [translation] - \@vector: - type: NX_NUMBER - doc: | - Three values that define the axis for this transformation - \@offset: - type: NX_NUMBER - doc: | - A fixed offset applied before the transformation (three vector components). - \@offset_units: - type: NX_CHAR - doc: | - Units of the offset. - \@depends_on: - type: NX_CHAR - doc: | - Points to the path of the next element in the geometry chain. - slow_pixel_direction(NX_NUMBER): - unit: NX_LENGTH - doc: | - Values along the direction of :ref:`slowest varying` :index:`pixel direction`. Each value in this - array is the size of a pixel in the units specified. Alternatively, if only one - value is given, all pixels in this direction have the same value. The direction - itself is given through the vector attribute. - \@transformation_type: - enumeration: [translation] - \@vector: - type: NX_NUMBER - doc: | - Three values that define the axis for this transformation - \@offset: - type: NX_NUMBER - doc: | - A fixed offset applied before the transformation (three vector components). - \@offset_units: - type: NX_CHAR - doc: | - Units of the offset. - \@depends_on: - type: NX_CHAR - doc: | - Points to the path of the next element in the geometry chain. - depends_on(NX_CHAR): - doc: | - Points to the start of the dependency chain for this module. - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a338ff56322e2dd90853fbfd5cb076d23dbe22ddd7c0246ff5834f409b0fda58 -# -# -# -# -# -# Geometry and logical description of a detector module. When used, child group to NXdetector. -# -# Many detectors consist of multiple -# smaller modules. Sometimes it is important to know the exact position of such -# modules. -# This is the purpose of this group. It is a child group to NXdetector. -# -# Note, the pixel size is given as values in the array fast_pixel_direction and slow_pixel_direction. -# -# -# -# A dimension-2 or dimension-3 field which gives the indices -# of the origin of the hyperslab of data for this module in the -# main area detector image in the parent NXdetector module. -# -# The data_origin is 0-based. -# -# The frame number dimension (np) is omitted. Thus the -# data_origin field for a dimension-2 dataset with indices (np, i, j) -# will be an array with indices (i, j), and for a dimension-3 -# dataset with indices (np, i, j, k) will be an array with indices -# (i, j, k). -# -# The :ref:`order <Design-ArrayStorageOrder>` of indices (i, j or i, j, k) is slow to fast. -# -# -# -# -# Two or three values for the size of the module in pixels in -# each direction. Dimensionality and order of indices is the -# same as for data_origin. -# -# -# -# -# Offset of the module in regards to the origin of the detector in an -# arbitrary direction. -# -# -# -# -# -# -# -# -# Three values that define the axis for this transformation -# -# -# -# -# A fixed offset applied before the transformation (three vector components). -# -# -# -# -# Units of the offset. -# -# -# -# -# Points to the path of the next element in the geometry chain. -# -# -# -# -# -# Values along the direction of :ref:`fastest varying <Design-ArrayStorageOrder>` :index:`pixel direction<dimension; fastest varying>`. Each value in this -# array is the size of a pixel in the units specified. Alternatively, if only one -# value is given, all pixels in this direction have the same value. The direction -# itself is given through the vector attribute. -# -# -# -# -# -# -# -# -# Three values that define the axis for this transformation -# -# -# -# -# A fixed offset applied before the transformation (three vector components). -# -# -# -# -# Units of the offset. -# -# -# -# -# Points to the path of the next element in the geometry chain. -# -# -# -# -# -# Values along the direction of :ref:`slowest varying<Design-ArrayStorageOrder>` :index:`pixel direction<dimension; slowest varying>`. Each value in this -# array is the size of a pixel in the units specified. Alternatively, if only one -# value is given, all pixels in this direction have the same value. The direction -# itself is given through the vector attribute. -# -# -# -# -# -# -# -# -# Three values that define the axis for this transformation -# -# -# -# -# A fixed offset applied before the transformation (three vector components). -# -# -# -# -# Units of the offset. -# -# -# -# -# Points to the path of the next element in the geometry chain. -# -# -# -# -# -# Points to the start of the dependency chain for this module. -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# diff --git a/base_classes/nyaml/NXdisk_chopper.yaml b/base_classes/nyaml/NXdisk_chopper.yaml deleted file mode 100644 index b436e31add..0000000000 --- a/base_classes/nyaml/NXdisk_chopper.yaml +++ /dev/null @@ -1,322 +0,0 @@ -category: base -doc: | - A device blocking the beam in a temporal periodic pattern. - - A disk which blocks the beam but has one or more slits to periodically - let neutrons through as the disk rotates. Often used in pairs, one - NXdisk_chopper should be defined for each disk. - - The rotation of the disk is commonly monitored by recording a timestamp for - each full rotation of disk, by having a sensor in the stationary disk housing - sensing when it is aligned with a feature (such as a magnet) on the disk. - We refer to this below as the "top-dead-center signal". - - Angles and positive rotation speeds are measured in an anticlockwise - direction when facing away from the source. -symbols: - doc: | - This symbol will be used below to coordinate datasets with the same shape. - n: | - Number of slits in the disk -type: group -NXdisk_chopper(NXobject): - type: - doc: | - Type of the disk-chopper: only one from the enumerated list (match text exactly) - enumeration: [Chopper type single, contra_rotating_pair, synchro_pair] - rotation_speed(NX_FLOAT): - unit: NX_FREQUENCY - doc: | - Chopper rotation speed. Positive for anticlockwise rotation when - facing away from the source, negative otherwise. - slits(NX_INT): - doc: | - Number of slits - slit_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Angular opening - pair_separation(NX_FLOAT): - unit: NX_LENGTH - doc: | - Disk spacing in direction of beam - slit_edges(NX_FLOAT): - unit: NX_ANGLE - doc: | - Angle of each edge of every slit from the position of the - top-dead-center timestamp sensor, anticlockwise when facing - away from the source. - The first edge must be the opening edge of a slit, thus the last edge - may have an angle greater than 360 degrees. - dimensions: - dim: [[1, 2n]] - top_dead_center(NX_NUMBER): - unit: NX_TIME - doc: | - Timestamps of the top-dead-center signal. The times are relative - to the "start" attribute and in the units specified in the "units" - attribute. Please note that absolute - timestamps under unix are relative to ``1970-01-01T00:00:00.0Z``. - \@start: - type: NX_DATE_TIME - beam_position(NX_FLOAT): - unit: NX_ANGLE - doc: | - Angular separation of the center of the beam and the - top-dead-center timestamp sensor, anticlockwise when facing - away from the source. - radius(NX_FLOAT): - unit: NX_LENGTH - doc: | - Radius of the disk - slit_height(NX_FLOAT): - unit: NX_LENGTH - doc: | - Total slit height - phase(NX_FLOAT): - unit: NX_ANGLE - doc: | - Chopper phase angle - delay(NX_NUMBER): - unit: NX_TIME - doc: | - Time difference between timing system t0 and chopper driving clock signal - ratio(NX_INT): - doc: | - Pulse reduction factor of this chopper in relation to other - choppers/fastest pulse in the instrument - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Effective distance to the origin. - Note, it is recommended to use NXtransformations instead. - wavelength_range(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - Low and high values of wavelength range transmitted - dimensions: - dim: [[1, 2]] - (NXgeometry): - deprecated: | - Use the field `depends_on` and :ref:`NXtransformations` to position the chopper and NXoff_geometry to describe its shape instead - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the beam line component - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - The reference plane of the disk chopper includes the surface of the spinning disk which faces - the source. The reference point in the x and y axis is the point on this surface which is the - centre of the axle which the disk is spinning around. The reference plane is orthogonal to - the z axis and its position is the reference point on that axis. - - Note: This reference point in almost all practical cases is not where the beam passes though. - - .. image:: disk_chopper/disk_chopper.png - :width: 40% - (NXtransformations): - doc: | - 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# ee378dea155f1853138f202b664b89c72afefce4891442dae478edd3f01671db -# -# -# -# -# -# -# This symbol will be used below to coordinate datasets with the same shape. -# Number of slits in the disk -# -# -# -# A device blocking the beam in a temporal periodic pattern. -# -# A disk which blocks the beam but has one or more slits to periodically -# let neutrons through as the disk rotates. Often used in pairs, one -# NXdisk_chopper should be defined for each disk. -# -# The rotation of the disk is commonly monitored by recording a timestamp for -# each full rotation of disk, by having a sensor in the stationary disk housing -# sensing when it is aligned with a feature (such as a magnet) on the disk. -# We refer to this below as the "top-dead-center signal". -# -# Angles and positive rotation speeds are measured in an anticlockwise -# direction when facing away from the source. -# -# -# -# Type of the disk-chopper: only one from the enumerated list (match text exactly) -# -# -# -# -# -# -# -# -# Chopper rotation speed. Positive for anticlockwise rotation when -# facing away from the source, negative otherwise. -# -# -# -# Number of slits -# -# -# Angular opening -# -# -# Disk spacing in direction of beam -# -# -# -# Angle of each edge of every slit from the position of the -# top-dead-center timestamp sensor, anticlockwise when facing -# away from the source. -# The first edge must be the opening edge of a slit, thus the last edge -# may have an angle greater than 360 degrees. -# -# -# -# -# -# Timestamps of the top-dead-center signal. The times are relative -# to the "start" attribute and in the units specified in the "units" -# attribute. Please note that absolute -# timestamps under unix are relative to ``1970-01-01T00:00:00.0Z``. -# -# -# -# -# -# Angular separation of the center of the beam and the -# top-dead-center timestamp sensor, anticlockwise when facing -# away from the source. -# -# -# -# Radius of the disk -# -# -# Total slit height -# -# -# Chopper phase angle -# -# -# -# Time difference between timing system t0 and chopper driving clock signal -# -# -# -# -# Pulse reduction factor of this chopper in relation to other -# choppers/fastest pulse in the instrument -# -# -# -# -# Effective distance to the origin. -# Note, it is recommended to use NXtransformations instead. -# -# -# -# Low and high values of wavelength range transmitted -# -# -# -# -# -# -# This group describes the shape of the beam line component -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# The reference plane of the disk chopper includes the surface of the spinning disk which faces -# the source. The reference point in the x and y axis is the point on this surface which is the -# centre of the axle which the disk is spinning around. The reference plane is orthogonal to -# the z axis and its position is the reference point on that axis. -# -# Note: This reference point in almost all practical cases is not where the beam passes though. -# -# .. image:: disk_chopper/disk_chopper.png -# :width: 40% -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# diff --git a/base_classes/nyaml/NXentry.yaml b/base_classes/nyaml/NXentry.yaml deleted file mode 100644 index 44c1dff1b0..0000000000 --- a/base_classes/nyaml/NXentry.yaml +++ /dev/null @@ -1,475 +0,0 @@ -category: base -doc: | - (**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. -type: group -NXentry(NXobject): - \@default: - doc: | - .. 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. - (NXdata): - doc: | - 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 - \@IDF_Version: - - # as ratified at NIAC2010 - doc: | - ISIS Muon IDF_Version - title: - doc: | - Extended title for entry - experiment_identifier(NXidentifier): - doc: | - Unique identifier for the experiment, - defined by the facility, - possibly linked to the proposals - experiment_description: - doc: | - Brief summary of the experiment, including key objectives. - (NXnote)experiment_documentation: - doc: | - Description of the full experiment (document in pdf, latex, ...) - collection_identifier(NXidentifier): - doc: | - User or Data Acquisition defined group of NeXus files or NXentry - collection_description: - doc: | - Brief summary of the collection, including grouping criteria. - entry_identifier(NXidentifier): - doc: | - unique identifier for the measurement, defined by the facility. - entry_identifier_uuid(NXidentifier): - doc: | - UUID identifier for the measurement. - \@version: - doc: | - Version of UUID used - experiment_location: - doc: | - City and country where the experiment took place - experiment_start_date(NX_DATE_TIME): - doc: | - Start time of experimental run that includes the current - measurement, for example a beam time. - experiment_end_date(NX_DATE_TIME): - doc: | - End time of experimental run that includes the current - measurement, for example a beam time. - experiment_institution: - doc: | - Name of the institution hosting the facility - experiment_facility: - doc: | - Name of the experimental facility - experiment_laboratory: - doc: | - Name of the laboratory or beamline - features: - doc: | - Reserved for future use by NIAC. - - See https://github.com/nexusformat/definitions/issues/382 - definition: - doc: | - (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. - \@version: - doc: | - NXDL version number - \@URL: - doc: | - URL of NXDL file - definition_local: - deprecated: | - see same field in :ref:`NXsubentry` for preferred use - doc: | - Local NXDL schema extended from the entry - specified in the ``definition`` field. - This contains any locally-defined, - additional fields in the entry. - \@version: - doc: | - NXDL version number - \@URL: - doc: | - URL of NXDL file - start_time(NX_DATE_TIME): - doc: | - Starting time of measurement - end_time(NX_DATE_TIME): - doc: | - Ending time of measurement - duration(NX_INT): - unit: NX_TIME - doc: | - Duration of measurement - collection_time(NX_FLOAT): - unit: NX_TIME - doc: | - Time transpired actually collecting data i.e. taking out time when collection was - suspended due to e.g. temperature out of range - run_cycle: - doc: | - Such as "2007-3". Some user facilities organize their beam time into run cycles. - program_name: - doc: | - Name of program used to generate this file - \@version: - doc: | - Program version number - \@configuration: - doc: | - configuration of the program - revision: - doc: | - Revision id of the file due to re-calibration, reprocessing, new analysis, new - instrument definition format, ... - \@comment: - pre_sample_flightpath(NX_FLOAT): - unit: NX_LENGTH - doc: | - This is the flightpath before the sample position. This can be determined by a chopper, - by the moderator or the source itself. In other words: it the distance to the component - which gives the T0 signal to the detector electronics. If another component in the - NXinstrument hierarchy provides this information, this should be a link. - notes(NXnote): - doc: | - Notes describing entry - thumbnail(NXnote): - doc: | - A small image that is representative of the entry. An example of this is a 640x480 - jpeg image automatically produced by a low resolution plot of the NXdata. - \@type: - doc: | - The mime type should be an ``image/*`` - - # This is not perfect. - # How do we set a default value for the type attribute? - enumeration: [image/*] - (NXuser): - (NXsample): - (NXinstrument): - (NXcollection): - (NXmonitor): - (NXparameters): - (NXprocess): - (NXsubentry): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8bc49b1f127bc6bb67ef39fead2e86ebae2f729ff5451e3e04a9066bb4a85b64 -# -# -# -# -# -# -# -# .. 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 <validItemName>` 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 <Find-Plottable-Data-v3>` -# section. -# -# -# -# -# (**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. -# -# -# -# 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 -# -# -# -# -# -# -# ISIS Muon IDF_Version -# -# -# Extended title for entry -# -# -# -# Unique identifier for the experiment, -# defined by the facility, -# possibly linked to the proposals -# -# -# -# Brief summary of the experiment, including key objectives. -# -# -# Description of the full experiment (document in pdf, latex, ...) -# -# -# User or Data Acquisition defined group of NeXus files or NXentry -# -# -# Brief summary of the collection, including grouping criteria. -# -# -# unique identifier for the measurement, defined by the facility. -# -# -# UUID identifier for the measurement. -# Version of UUID used -# -# -# City and country where the experiment took place -# -# -# -# Start time of experimental run that includes the current -# measurement, for example a beam time. -# -# -# -# -# End time of experimental run that includes the current -# measurement, for example a beam time. -# -# -# -# -# Name of the institution hosting the facility -# -# -# -# -# Name of the experimental facility -# -# -# -# -# Name of the laboratory or beamline -# -# -# -# -# Reserved for future use by NIAC. -# -# See https://github.com/nexusformat/definitions/issues/382 -# -# -# -# -# (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. -# -# NXDL version number -# URL of NXDL file -# -# -# -# Local NXDL schema extended from the entry -# specified in the ``definition`` field. -# This contains any locally-defined, -# additional fields in the entry. -# -# NXDL version number -# URL of NXDL file -# -# -# Starting time of measurement -# -# -# Ending time of measurement -# -# -# Duration of measurement -# -# -# -# Time transpired actually collecting data i.e. taking out time when collection was -# suspended due to e.g. temperature out of range -# -# -# -# Such as "2007-3". Some user facilities organize their beam time into run cycles. -# -# -# Name of program used to generate this file -# Program version number -# configuration of the program -# -# -# -# Revision id of the file due to re-calibration, reprocessing, new analysis, new -# instrument definition format, ... -# -# -# -# -# -# This is the flightpath before the sample position. This can be determined by a chopper, -# by the moderator or the source itself. In other words: it the distance to the component -# which gives the T0 signal to the detector electronics. If another component in the -# NXinstrument hierarchy provides this information, this should be a link. -# -# -# -# Notes describing entry -# -# -# -# A small image that is representative of the entry. An example of this is a 640x480 -# jpeg image automatically produced by a low resolution plot of the NXdata. -# -# -# The mime type should be an ``image/*`` -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# \ No newline at end of file diff --git a/base_classes/nyaml/NXenvironment.yaml b/base_classes/nyaml/NXenvironment.yaml deleted file mode 100644 index 3c9457dfe0..0000000000 --- a/base_classes/nyaml/NXenvironment.yaml +++ /dev/null @@ -1,182 +0,0 @@ -category: base -doc: | - Parameters for controlling external conditions -type: group -NXenvironment(NXobject): - name: - doc: | - Apparatus identification code/model number; e.g. OC100 011 - short_name: - doc: | - Alternative short name, perhaps for dashboard display like a present Seblock name - type: - doc: | - Type of apparatus. This could be the SE codes in scheduling database; e.g. OC/100 - description: - doc: | - Description of the apparatus; e.g. 100mm bore orange cryostat with Roots pump - program: - doc: | - Program controlling the apparatus; e.g. LabView VI name - position(NXgeometry): - doc: | - The position and orientation of the apparatus. - Note, it is recommended to use NXtransformations instead. - value(NX_FLOAT): - unit: NX_ANY - doc: | - This is to be used if there is no actuator/sensor that controls/measures - the environment parameters, but the user would still like to give a value for - it. An example would be a room temperature experiment where the temperature is - not actively measured, but rather estimated. - - Note that this method for recording the environment parameters is not advised, - but using NXsensor and NXactuator is strongly recommended instead. - depends_on(NX_CHAR): - doc: | - 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. - (NXtransformations): - exists: ['min', '0'] - doc: | - 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. - (NXnote): - doc: | - Additional information, LabView logs, digital photographs, etc - (NXactuator): - doc: | - Any actuator used to control the environment. This can be linked to an actuator - defined in an NXinstrument instance. - (NXsensor): - doc: | - Any sensor used to monitor the environment. This can be linked to a sensor - defined in an NXinstrument instance. - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# fbd1ae51f8ebc3b6fbac12baec026b0d389eea9bb992dc2abf34cd926d7753d1 -# -# -# -# -# Parameters for controlling external conditions -# -# Apparatus identification code/model number; e.g. OC100 011 -# -# -# Alternative short name, perhaps for dashboard display like a present Seblock name -# -# -# Type of apparatus. This could be the SE codes in scheduling database; e.g. OC/100 -# -# -# Description of the apparatus; e.g. 100mm bore orange cryostat with Roots pump -# -# -# Program controlling the apparatus; e.g. LabView VI name -# -# -# -# The position and orientation of the apparatus. -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# This is to be used if there is no actuator/sensor that controls/measures -# the environment parameters, but the user would still like to give a value for -# it. An example would be a room temperature experiment where the temperature is -# not actively measured, but rather estimated. -# -# Note that this method for recording the environment parameters is not advised, -# but using NXsensor and NXactuator is strongly recommended instead. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# 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. -# -# -# -# -# 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. -# -# -# -# Additional information, LabView logs, digital photographs, etc -# -# -# -# Any actuator used to control the environment. This can be linked to an actuator -# defined in an NXinstrument instance. -# -# -# -# -# Any sensor used to monitor the environment. This can be linked to a sensor -# defined in an NXinstrument instance. -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# diff --git a/base_classes/nyaml/NXevent_data.yaml b/base_classes/nyaml/NXevent_data.yaml deleted file mode 100644 index f5853102c1..0000000000 --- a/base_classes/nyaml/NXevent_data.yaml +++ /dev/null @@ -1,220 +0,0 @@ -category: base -doc: | - NXevent_data is a special group for storing data from neutron - detectors in event mode. In this mode, the detector electronics - emits a stream of detectorID, timestamp pairs. With detectorID - describing the detector element in which the neutron was detected - and timestamp the timestamp at which the neutron event was - detected. In NeXus detectorID maps to event_id, event_time_offset - to the timestamp. - - As this kind of data is common at pulsed neutron - sources, the timestamp is almost always relative to the start of a - neutron pulse. Thus the pulse timestamp is recorded too together - with an index in the event_id, event_time_offset pair at which data for - that pulse starts. At reactor source the same pulsed data effect - may be achieved through the use of choppers or in stroboscopic - measurement setups. - - In order to make random access to timestamped data - faster there is an optional array pair of - cue_timestamp_zero and cue_index. The cue_timestamp_zero will - contain courser timestamps then in the time array, say - every five minutes. The cue_index will then contain the - index into the event_id,event_time_offset pair of arrays for that - courser cue_timestamp_zero. -type: group -NXevent_data(NXobject): - event_time_offset(NX_NUMBER): - unit: NX_TIME_OF_FLIGHT - doc: | - A list of timestamps for each event as it comes in. - dimensions: - rank: 1 - dim: [[1, i]] - event_id(NX_INT): - unit: NX_DIMENSIONLESS - doc: | - There will be extra information in the NXdetector to convert - event_id to detector_number. - dimensions: - rank: 1 - dim: [[1, i]] - event_time_zero(NX_NUMBER): - unit: NX_TIME - doc: | - The time that each pulse started with respect to the offset - dimensions: - rank: 1 - dim: [[1, j]] - \@offset: - type: NX_DATE_TIME - doc: | - ISO8601 - event_index(NX_INT): - unit: NX_DIMENSIONLESS - doc: | - The index into the event_time_offset, event_id pair for - the pulse occurring at the matching entry in event_time_zero. - dimensions: - rank: 1 - dim: [[1, j]] - pulse_height(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - If voltages from the ends of the detector are read out this - is where they go. This list is for all events with information - to attach to a particular pulse height. The information to - attach to a particular pulse is located in events_per_pulse. - dimensions: - rank: 2 - - # i,k? - dim: [[1, i], [2, k]] - cue_timestamp_zero(NX_DATE_TIME): - unit: NX_TIME - doc: | - Timestamps matching the corresponding cue_index into the - event_id, event_time_offset pair. - \@start: - type: NX_DATE_TIME - cue_index(NX_INT): - doc: | - Index into the event_id, event_time_offset pair matching the corresponding - cue_timestamp. - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# de7b8eae2062ecf10ba405043a20449f294dee3e1f6c62db9cbeb72f70347908 -# -# -# -# -# -# NXevent_data is a special group for storing data from neutron -# detectors in event mode. In this mode, the detector electronics -# emits a stream of detectorID, timestamp pairs. With detectorID -# describing the detector element in which the neutron was detected -# and timestamp the timestamp at which the neutron event was -# detected. In NeXus detectorID maps to event_id, event_time_offset -# to the timestamp. -# -# As this kind of data is common at pulsed neutron -# sources, the timestamp is almost always relative to the start of a -# neutron pulse. Thus the pulse timestamp is recorded too together -# with an index in the event_id, event_time_offset pair at which data for -# that pulse starts. At reactor source the same pulsed data effect -# may be achieved through the use of choppers or in stroboscopic -# measurement setups. -# -# In order to make random access to timestamped data -# faster there is an optional array pair of -# cue_timestamp_zero and cue_index. The cue_timestamp_zero will -# contain courser timestamps then in the time array, say -# every five minutes. The cue_index will then contain the -# index into the event_id,event_time_offset pair of arrays for that -# courser cue_timestamp_zero. -# -# -# -# A list of timestamps for each event as it comes in. -# -# -# -# -# -# There will be extra information in the NXdetector to convert -# event_id to detector_number. -# -# -# -# -# -# The time that each pulse started with respect to the offset -# -# -# -# ISO8601 -# -# -# -# -# The index into the event_time_offset, event_id pair for -# the pulse occurring at the matching entry in event_time_zero. -# -# -# -# -# -# If voltages from the ends of the detector are read out this -# is where they go. This list is for all events with information -# to attach to a particular pulse height. The information to -# attach to a particular pulse is located in events_per_pulse. -# -# -# -# -# -# -# -# -# Timestamps matching the corresponding cue_index into the -# event_id, event_time_offset pair. -# -# -# -# -# -# Index into the event_id, event_time_offset pair matching the corresponding -# cue_timestamp. -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# diff --git a/base_classes/nyaml/NXfermi_chopper.yaml b/base_classes/nyaml/NXfermi_chopper.yaml deleted file mode 100644 index 2eb4f582f0..0000000000 --- a/base_classes/nyaml/NXfermi_chopper.yaml +++ /dev/null @@ -1,210 +0,0 @@ -category: base -doc: | - A Fermi chopper, possibly with curved slits. -type: group -NXfermi_chopper(NXobject): - type: - doc: | - Fermi chopper type - rotation_speed(NX_FLOAT): - unit: NX_FREQUENCY - doc: | - chopper rotation speed - radius(NX_FLOAT): - unit: NX_LENGTH - doc: | - radius of chopper - slit(NX_FLOAT): - unit: NX_LENGTH - doc: | - width of an individual slit - r_slit(NX_FLOAT): - unit: NX_LENGTH - doc: | - radius of curvature of slits - number(NX_INT): - unit: NX_UNITLESS - doc: | - number of slits - height(NX_FLOAT): - unit: NX_LENGTH - doc: | - input beam height - width(NX_FLOAT): - unit: NX_LENGTH - doc: | - input beam width - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - distance. Note, it is recommended to use NXtransformations instead. - wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - - # should have units of angstroms or nm or pm - doc: | - Wavelength transmitted by chopper - energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - energy selected - (NXgeometry): - deprecated: | - Use the field `depends_on` and :ref:`NXtransformations` to position the chopper and NXoff_geometry to describe its shape instead - doc: | - geometry of the fermi chopper - absorbing_material: - doc: | - absorbing material - transmitting_material: - doc: | - transmitting material - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the beam line component - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a fermi chopper. - (NXtransformations): - doc: | - 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 04b013594d50ef26bceb84da7095ee93ca9e62222215097627e68c574b1a41ea -# -# -# -# -# A Fermi chopper, possibly with curved slits. -# -# Fermi chopper type -# -# -# chopper rotation speed -# -# -# radius of chopper -# -# -# width of an individual slit -# -# -# radius of curvature of slits -# -# -# number of slits -# -# -# input beam height -# -# -# input beam width -# -# -# distance. Note, it is recommended to use NXtransformations instead. -# -# -# -# Wavelength transmitted by chopper -# -# -# energy selected -# -# -# geometry of the fermi chopper -# -# -# absorbing material -# -# -# transmitting material -# -# -# -# This group describes the shape of the beam line component -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a fermi chopper. -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# diff --git a/base_classes/nyaml/NXfilter.yaml b/base_classes/nyaml/NXfilter.yaml deleted file mode 100644 index a652639c7b..0000000000 --- a/base_classes/nyaml/NXfilter.yaml +++ /dev/null @@ -1,373 +0,0 @@ -category: base -doc: | - For band pass beam filters. - - If uncertain whether to use :ref:`NXfilter` (band-pass filter) - or :ref:`NXattenuator` (reduces beam intensity), then use - :ref:`NXattenuator`. -type: group -NXfilter(NXobject): - (NXgeometry): - deprecated: | - Use the field `depends_on` and :ref:`NXtransformations` to filter the beamstop and NXoff_geometry to describe its shape instead - doc: | - Geometry of the filter - description: - doc: | - Composition of the filter. Chemical formula can be specified separately. - - This field was changed (2010-11-17) from an enumeration to - a string since common usage showed a wider variety of use - than a simple list. These are the items in the list at - the time of the change: Beryllium | Pyrolytic Graphite | - Graphite | Sapphire | Silicon | Supermirror. - status: - doc: | - position with respect to in or out of the beam (choice of only "in" or "out") - enumeration: - in: - doc: | - in the beam - out: - doc: | - out of the beam - transmission(NXdata): - doc: | - Wavelength transmission profile of filter - temperature(NX_FLOAT): - unit: NX_TEMPERATURE - doc: | - average/nominal filter temperature - temperature_log(NXlog): - doc: | - Linked temperature_log for the filter - thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - Thickness of the filter - density(NX_NUMBER): - unit: NX_MASS_DENSITY - doc: | - mass density of the filter - chemical_formula: - - # copied from NXsample - doc: | - 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. - sensor_type(NXsensor): - doc: | - Sensor(s)used to monitor the filter temperature - unit_cell_a(NX_FLOAT): - unit: NX_LENGTH - doc: | - Unit cell lattice parameter: length of side a - unit_cell_b(NX_FLOAT): - unit: NX_LENGTH - doc: | - Unit cell lattice parameter: length of side b - unit_cell_c(NX_FLOAT): - unit: NX_LENGTH - doc: | - Unit cell lattice parameter: length of side c - unit_cell_alpha(NX_FLOAT): - unit: NX_ANGLE - doc: | - Unit cell lattice parameter: angle alpha - unit_cell_beta(NX_FLOAT): - unit: NX_ANGLE - doc: | - Unit cell lattice parameter: angle beta - unit_cell_gamma(NX_FLOAT): - unit: NX_ANGLE - doc: | - Unit cell lattice parameter: angle gamma - unit_cell_volume(NX_FLOAT): - unit: NX_VOLUME - doc: | - Unit cell - dimensions: - rank: 1 - dim: [[1, n_comp]] - orientation_matrix(NX_FLOAT): - doc: | - Orientation matrix of single crystal filter using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - dimensions: - rank: 3 - - # n_comp,3,3 - - # TODO n_comp is number of different compositions? - dim: [[1, n_comp], [2, 3], [3, 3]] - m_value(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - m value of supermirror filter - substrate_material: - doc: | - substrate material of supermirror filter - substrate_thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - substrate thickness of supermirror filter - coating_material: - doc: | - coating material of supermirror filter - substrate_roughness(NX_FLOAT): - unit: NX_LENGTH - doc: | - substrate roughness (RMS) of supermirror filter - coating_roughness(NX_FLOAT): - unit: NX_LENGTH - doc: | - coating roughness (RMS) of supermirror filter - dimensions: - rank: 1 - dim: [[1, nsurf]] - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the beam line component - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a filter. - (NXtransformations): - doc: | - 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e800c936071e2ad5617edb479c0be73c6aec5ae1641eb76fd11bdc67b4a0c45c -# -# -# -# -# -# For band pass beam filters. -# -# If uncertain whether to use :ref:`NXfilter` (band-pass filter) -# or :ref:`NXattenuator` (reduces beam intensity), then use -# :ref:`NXattenuator`. -# -# -# Geometry of the filter -# -# -# -# Composition of the filter. Chemical formula can be specified separately. -# -# This field was changed (2010-11-17) from an enumeration to -# a string since common usage showed a wider variety of use -# than a simple list. These are the items in the list at -# the time of the change: Beryllium | Pyrolytic Graphite | -# Graphite | Sapphire | Silicon | Supermirror. -# -# -# -# position with respect to in or out of the beam (choice of only "in" or "out") -# -# in the beam -# out of the beam -# -# -# -# Wavelength transmission profile of filter -# -# -# average/nominal filter temperature -# -# -# Linked temperature_log for the filter -# -# -# Thickness of the filter -# -# -# mass density of the filter -# -# -# -# -# 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. -# -# -# -# Sensor(s)used to monitor the filter temperature -# -# -# Unit cell lattice parameter: length of side a -# -# -# Unit cell lattice parameter: length of side b -# -# -# Unit cell lattice parameter: length of side c -# -# -# Unit cell lattice parameter: angle alpha -# -# -# Unit cell lattice parameter: angle beta -# -# -# Unit cell lattice parameter: angle gamma -# -# -# Unit cell -# -# -# -# -# Orientation matrix of single crystal filter using Busing-Levy convention: -# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 -# -# -# -# -# -# -# -# -# m value of supermirror filter -# -# -# substrate material of supermirror filter -# -# -# substrate thickness of supermirror filter -# -# -# coating material of supermirror filter -# -# -# substrate roughness (RMS) of supermirror filter -# -# -# coating roughness (RMS) of supermirror filter -# -# -# -# -# This group describes the shape of the beam line component -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a filter. -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# diff --git a/base_classes/nyaml/NXflipper.yaml b/base_classes/nyaml/NXflipper.yaml deleted file mode 100644 index f68fd2c263..0000000000 --- a/base_classes/nyaml/NXflipper.yaml +++ /dev/null @@ -1,159 +0,0 @@ -category: base -doc: | - A spin flipper. -type: group -NXflipper(NXobject): - type: - enumeration: [coil, current-sheet] - flip_turns(NX_FLOAT): - unit: NX_PER_LENGTH - doc: | - Linear density of turns (such as number of turns/cm) in flipping field coils - comp_turns(NX_FLOAT): - unit: NX_PER_LENGTH - doc: | - Linear density of turns (such as number of turns/cm) in compensating field coils - guide_turns(NX_FLOAT): - unit: NX_PER_LENGTH - doc: | - Linear density of turns (such as number of turns/cm) in guide field coils - flip_current(NX_FLOAT): - unit: NX_CURRENT - doc: | - Flipping field coil current in "on" state" - comp_current(NX_FLOAT): - unit: NX_CURRENT - doc: | - Compensating field coil current in "on" state" - guide_current(NX_FLOAT): - unit: NX_CURRENT - doc: | - Guide field coil current in "on" state - thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - thickness along path of neutron travel - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a spin flipper. - (NXtransformations): - doc: | - 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 15da34a6b18bd1b556735662c612623fa92a9d548850946f1c9730bb46812054 -# -# -# -# -# A spin flipper. -# -# -# -# -# -# -# -# Linear density of turns (such as number of turns/cm) in flipping field coils -# -# -# Linear density of turns (such as number of turns/cm) in compensating field coils -# -# -# Linear density of turns (such as number of turns/cm) in guide field coils -# -# -# Flipping field coil current in "on" state" -# -# -# Compensating field coil current in "on" state" -# -# -# Guide field coil current in "on" state -# -# -# thickness along path of neutron travel -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a spin flipper. -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# diff --git a/base_classes/nyaml/NXfresnel_zone_plate.yaml b/base_classes/nyaml/NXfresnel_zone_plate.yaml deleted file mode 100644 index ed97ed1d07..0000000000 --- a/base_classes/nyaml/NXfresnel_zone_plate.yaml +++ /dev/null @@ -1,178 +0,0 @@ -category: base -doc: | - A fresnel zone plate -type: group -NXfresnel_zone_plate(NXobject): - focus_parameters(NX_FLOAT): - doc: | - list of polynomial coefficients describing the focal length of the zone plate, in increasing powers of photon energy, - that describes the focal length of the zone plate (in microns) at an X-ray photon energy (in electron volts). - dimensions: - rank: 1 - dim: [] - outer_diameter(NX_FLOAT): - unit: NX_LENGTH - outermost_zone_width(NX_FLOAT): - unit: NX_LENGTH - central_stop_diameter(NX_FLOAT): - unit: NX_LENGTH - fabrication: - doc: | - how the zone plate was manufactured - enumeration: [etched, plated, zone doubled, other] - zone_height(NX_FLOAT): - unit: NX_LENGTH - zone_material: - doc: | - Material of the zones themselves - zone_support_material: - doc: | - Material present between the zones. This is usually only present for the "zone doubled" fabrication process - central_stop_material: - central_stop_thickness(NX_FLOAT): - unit: NX_LENGTH - mask_thickness(NX_FLOAT): - unit: NX_LENGTH - mask_material: - doc: | - If no mask is present, set mask_thickness to 0 and omit the mask_material field - support_membrane_material: - support_membrane_thickness(NX_FLOAT): - unit: NX_LENGTH - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a fresnel zone plate. - (NXtransformations): - doc: | - "Engineering" position of the fresnel zone plate - - 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 127f298a62ac65750fca82452ca0991455bca4c5be0b9e702ef4c468987c00ab -# -# -# -# -# -# A fresnel zone plate -# -# -# list of polynomial coefficients describing the focal length of the zone plate, in increasing powers of photon energy, -# that describes the focal length of the zone plate (in microns) at an X-ray photon energy (in electron volts). -# -# -# -# -# -# -# -# -# how the zone plate was manufactured -# -# -# -# -# -# -# -# -# -# Material of the zones themselves -# -# -# Material present between the zones. This is usually only present for the "zone doubled" fabrication process -# -# -# -# -# -# If no mask is present, set mask_thickness to 0 and omit the mask_material field -# -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a fresnel zone plate. -# -# -# -# -# -# "Engineering" position of the fresnel zone plate -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# diff --git a/base_classes/nyaml/NXgeometry.yaml b/base_classes/nyaml/NXgeometry.yaml deleted file mode 100644 index a84a7ce638..0000000000 --- a/base_classes/nyaml/NXgeometry.yaml +++ /dev/null @@ -1,128 +0,0 @@ -category: base -doc: | - legacy class - recommend to use :ref:`NXtransformations` now - - It is recommended that instances of :ref:`NXgeometry` be converted to - use :ref:`NXtransformations`. - - This is the description for a general position of a component. - It is recommended to name an instance of :ref:`NXgeometry` as "geometry" - to aid in the use of the definition in simulation codes such as McStas. - Also, in HDF, linked items must share the same name. - However, it might not be possible or practical in all situations. -type: group -deprecated: as decided at 2014 NIAC meeting, convert to use :ref:`NXtransformations` -NXgeometry(NXobject): - (NXshape): - doc: | - shape/size information of component - (NXtranslation): - doc: | - translation of component - (NXorientation): - doc: | - orientation of component - description: - doc: | - Optional description/label. Probably only present if we are - an additional reference point for components rather than the - location of a real component. - component_index(NX_INT): - doc: | - Position of the component along the beam path. The sample is at 0, components upstream - have negative component_index, components downstream have positive - component_index. - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a886eceaa532564fb3a4c7bfeb772085d71cf86885a6a6df62d4e20ca88abed2 -# -# -# -# -# -# legacy class - recommend to use :ref:`NXtransformations` now -# -# It is recommended that instances of :ref:`NXgeometry` be converted to -# use :ref:`NXtransformations`. -# -# This is the description for a general position of a component. -# It is recommended to name an instance of :ref:`NXgeometry` as "geometry" -# to aid in the use of the definition in simulation codes such as McStas. -# Also, in HDF, linked items must share the same name. -# However, it might not be possible or practical in all situations. -# -# -# shape/size information of component -# -# -# translation of component -# -# -# orientation of component -# -# -# -# Optional description/label. Probably only present if we are -# an additional reference point for components rather than the -# location of a real component. -# -# -# -# -# Position of the component along the beam path. The sample is at 0, components upstream -# have negative component_index, components downstream have positive -# component_index. -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# diff --git a/base_classes/nyaml/NXgrating.yaml b/base_classes/nyaml/NXgrating.yaml deleted file mode 100644 index 54f1b7152e..0000000000 --- a/base_classes/nyaml/NXgrating.yaml +++ /dev/null @@ -1,202 +0,0 @@ -category: base -doc: | - A diffraction grating, as could be used in a soft X-ray monochromator -type: group -NXgrating(NXobject): - angles(NX_FLOAT): - unit: NX_ANGLE - doc: | - Blaze or trapezoidal angles, with the angle of the upstream facing edge listed first. Blazed gratings can be identified by the low value of the first-listed angle. - dimensions: - rank: 1 - dim: [[1, 2]] - period(NX_FLOAT): - unit: NX_LENGTH - doc: | - List of polynomial coefficients describing the spatial separation of lines/grooves as a function of position along the grating, in increasing powers of position. Gratings which do not have variable line spacing will only have a single coefficient (constant). - dimensions: - rank: 1 - dim: [] - duty_cycle(NX_FLOAT): - unit: NX_UNITLESS - depth(NX_FLOAT): - unit: NX_LENGTH - diffraction_order(NX_INT): - unit: NX_UNITLESS - deflection_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Angle between the incident beam and the utilised outgoing beam. - interior_atmosphere: - enumeration: [vacuum, helium, argon] - substrate_material: - doc: | - substrate_density(NX_FLOAT): - unit: NX_MASS_DENSITY - doc: | - substrate_thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - coating_material: - substrate_roughness(NX_FLOAT): - unit: NX_LENGTH - coating_roughness(NX_FLOAT): - unit: NX_LENGTH - layer_thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - An array describing the thickness of each layer - (NXshape)shape: - deprecated: Use NXoff_geometry to describe the shape of grating - doc: | - A NXshape group describing the shape of the mirror - figure_data(NXdata): - doc: | - Numerical description of the surface figure of the mirror. - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the beam line component - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a bending grating. - (NXtransformations): - doc: | - "Engineering" position of the grating - Transformations used by this component to define its position and orientation. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 10a8e5da8ec80e996745b7581124bcadbc254485335e294a015becdf4e44161d -# -# -# -# -# -# A diffraction grating, as could be used in a soft X-ray monochromator -# -# Blaze or trapezoidal angles, with the angle of the upstream facing edge listed first. Blazed gratings can be identified by the low value of the first-listed angle. -# -# -# -# -# -# List of polynomial coefficients describing the spatial separation of lines/grooves as a function of position along the grating, in increasing powers of position. Gratings which do not have variable line spacing will only have a single coefficient (constant). -# -# -# -# -# -# -# Angle between the incident beam and the utilised outgoing beam. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# An array describing the thickness of each layer -# -# -# A NXshape group describing the shape of the mirror -# -# -# Numerical description of the surface figure of the mirror. -# -# -# -# This group describes the shape of the beam line component -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a bending grating. -# -# -# -# -# -# "Engineering" position of the grating -# Transformations used by this component to define its position and orientation. -# -# -# diff --git a/base_classes/nyaml/NXguide.yaml b/base_classes/nyaml/NXguide.yaml deleted file mode 100644 index 9308e21a9d..0000000000 --- a/base_classes/nyaml/NXguide.yaml +++ /dev/null @@ -1,416 +0,0 @@ -category: base -doc: | - A neutron optical element to direct the path of the beam. - - :ref:`NXguide` is used by neutron instruments to describe - a guide consists of several mirrors building a shape through which - neutrons can be guided or directed. The simplest such form is box shaped - although elliptical guides are gaining in popularity. - The individual parts of a guide usually have common characteristics - but there are cases where they are different. - For example, a neutron guide might consist of 2 or 4 coated walls or - a supermirror bender with multiple, coated vanes. - - To describe polarizing supermirrors such as used in neutron reflection, - it may be necessary to revise this definition of :ref:`NXguide` - to include :ref:`NXpolarizer` and/or :ref:`NXmirror`. - - When even greater complexity exists in the definition of what - constitutes a *guide*, it has been suggested that :ref:`NXguide` - be redefined as a :ref:`NXcollection` of :ref:`NXmirror` each - having their own :ref:`NXgeometry` describing their location(s). - - For the more general case when describing mirrors, consider using - :ref:`NXmirror`. - - NOTE: The NeXus International Advisory Committee welcomes - comments for revision and improvement of - this definition of :ref:`NXguide`. -symbols: - nsurf: | - number of reflecting surfaces - nwl: | - number of wavelengths -type: group -NXguide(NXobject): - (NXgeometry): - deprecated: | - Use the field `depends_on` and :ref:`NXtransformations` to position the guid and NXoff_geometry to describe its shape instead - doc: | - TODO: Explain what this NXgeometry group means. What is intended here? - description: - doc: | - A description of this particular instance of ``NXguide``. - incident_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - TODO: documentation needed - (NXdata)reflectivity: - doc: | - Reflectivity as function of reflecting surface and wavelength - \@signal: - enumeration: [data] - \@axes: - enumeration: [surface wavelength] - \@surface_indices: - enumeration: [0] - \@wavelength_indices: - enumeration: [1] - data(NX_NUMBER): - doc: | - reflectivity of each surface as a function of wavelength - dimensions: - rank: 2 - - # was [nsurf,i] - dim: [[1, nsurf], [2, nwl]] - surface(NX_NUMBER): - unit: NX_ANY - doc: | - List of surfaces. Probably best to use index - numbers but the specification is very loose. - dimensions: - rank: 1 - dim: [[1, nsurf]] - wavelength(NX_NUMBER): - unit: NX_WAVELENGTH - doc: | - wavelengths at which reflectivity was measured - dimensions: - rank: 1 - dim: [[1, nwl]] - bend_angle_x(NX_FLOAT): - unit: NX_ANGLE - doc: | - TODO: documentation needed - bend_angle_y(NX_FLOAT): - unit: NX_ANGLE - doc: | - TODO: documentation needed - interior_atmosphere: - doc: | - - # TODO - enumeration: [vacuum, helium, argon] - external_material: - doc: | - external material outside substrate - m_value(NX_FLOAT): - doc: | - The ``m`` value for a supermirror, which defines the supermirror - regime in multiples of the critical angle of Nickel. - dimensions: - rank: 1 - dim: [[1, nsurf]] - substrate_material(NX_FLOAT): - doc: | - TODO: documentation needed - - # Why is this field a "float"? - dimensions: - rank: 1 - dim: [[1, nsurf]] - substrate_thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - TODO: documentation needed - dimensions: - rank: 1 - dim: [[1, nsurf]] - coating_material(NX_FLOAT): - doc: | - TODO: documentation needed - - # Why is this field a "float"? - dimensions: - rank: 1 - dim: [[1, nsurf]] - substrate_roughness(NX_FLOAT): - unit: NX_LENGTH - doc: | - TODO: documentation needed - dimensions: - rank: 1 - dim: [[1, nsurf]] - coating_roughness(NX_FLOAT): - unit: NX_LENGTH - doc: | - TODO: documentation needed - dimensions: - rank: 1 - dim: [[1, nsurf]] - number_sections(NX_INT): - unit: NX_UNITLESS - doc: | - number of substrate sections (also called ``nsurf`` as an - index in the ``NXguide`` specification) - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the beam line component - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - The entry opening of the guide lies on the reference plane. The center of the opening on that plane is - the reference point on the x and y axis. The reference plane is orthogonal to the z axis and is the - reference point along the z axis. Given no bend in the guide, it is parallel with z axis and extends - in the positive direction of the z axis. - - .. image:: guide/guide.png - :width: 40% - (NXtransformations): - doc: | - 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# c1066fe973e782c965184e772196e034d839b8a9972914729af48367d09378c9 -# -# -# -# -# -# -# number of reflecting surfaces -# number of wavelengths -# -# -# -# A neutron optical element to direct the path of the beam. -# -# :ref:`NXguide` is used by neutron instruments to describe -# a guide consists of several mirrors building a shape through which -# neutrons can be guided or directed. The simplest such form is box shaped -# although elliptical guides are gaining in popularity. -# The individual parts of a guide usually have common characteristics -# but there are cases where they are different. -# For example, a neutron guide might consist of 2 or 4 coated walls or -# a supermirror bender with multiple, coated vanes. -# -# To describe polarizing supermirrors such as used in neutron reflection, -# it may be necessary to revise this definition of :ref:`NXguide` -# to include :ref:`NXpolarizer` and/or :ref:`NXmirror`. -# -# When even greater complexity exists in the definition of what -# constitutes a *guide*, it has been suggested that :ref:`NXguide` -# be redefined as a :ref:`NXcollection` of :ref:`NXmirror` each -# having their own :ref:`NXgeometry` describing their location(s). -# -# For the more general case when describing mirrors, consider using -# :ref:`NXmirror`. -# -# NOTE: The NeXus International Advisory Committee welcomes -# comments for revision and improvement of -# this definition of :ref:`NXguide`. -# -# -# -# -# TODO: Explain what this NXgeometry group means. What is intended here? -# -# -# A description of this particular instance of ``NXguide``. -# -# -# TODO: documentation needed -# -# -# Reflectivity as function of reflecting surface and wavelength -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# reflectivity of each surface as a function of wavelength -# -# -# -# -# -# -# -# List of surfaces. Probably best to use index -# numbers but the specification is very loose. -# -# -# -# -# -# -# wavelengths at which reflectivity was measured -# -# -# -# -# -# -# TODO: documentation needed -# -# -# TODO: documentation needed -# -# -# -# -# -# -# -# -# -# -# external material outside substrate -# -# -# -# The ``m`` value for a supermirror, which defines the supermirror -# regime in multiples of the critical angle of Nickel. -# -# -# -# -# -# -# TODO: documentation needed -# -# -# -# -# -# TODO: documentation needed -# -# -# -# -# -# TODO: documentation needed -# -# -# -# -# -# TODO: documentation needed -# -# -# -# -# -# TODO: documentation needed -# -# -# -# -# -# -# number of substrate sections (also called ``nsurf`` as an -# index in the ``NXguide`` specification) -# -# -# -# -# This group describes the shape of the beam line component -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# The entry opening of the guide lies on the reference plane. The center of the opening on that plane is -# the reference point on the x and y axis. The reference plane is orthogonal to the z axis and is the -# reference point along the z axis. Given no bend in the guide, it is parallel with z axis and extends -# in the positive direction of the z axis. -# -# .. image:: guide/guide.png -# :width: 40% -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# diff --git a/base_classes/nyaml/NXinsertion_device.yaml b/base_classes/nyaml/NXinsertion_device.yaml deleted file mode 100644 index c5386182e8..0000000000 --- a/base_classes/nyaml/NXinsertion_device.yaml +++ /dev/null @@ -1,203 +0,0 @@ -category: base -doc: | - An insertion device, as used in a synchrotron light source. -type: group -NXinsertion_device(NXobject): - type: - enumeration: [undulator, wiggler] - gap(NX_FLOAT): - unit: NX_LENGTH - doc: | - separation between opposing pairs of magnetic poles - taper(NX_FLOAT): - unit: NX_ANGLE - doc: | - angular of gap difference between upstream and downstream ends of the insertion device - phase(NX_FLOAT): - unit: NX_ANGLE - poles(NX_INT): - unit: NX_UNITLESS - doc: | - number of poles - magnetic_wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - k(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - beam displacement parameter - length(NX_FLOAT): - unit: NX_LENGTH - doc: | - length of insertion device - power(NX_FLOAT): - unit: NX_POWER - doc: | - total power delivered by insertion device - energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - energy of peak intensity in output spectrum - bandwidth(NX_FLOAT): - unit: NX_ENERGY - doc: | - bandwidth of peak energy - - # What are the best units here? - harmonic(NX_INT): - unit: NX_UNITLESS - doc: | - harmonic number of peak - (NXdata)spectrum: - doc: | - spectrum of insertion device - (NXgeometry): - deprecated: | - Use the field `depends_on` and :ref:`NXtransformations` to position the device and NXoff_geometry to describe its shape instead - doc: | - "Engineering" position of insertion device - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the beam line component - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a insertion device. - (NXtransformations): - doc: | - 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 85d7c1e4480ea5d54949b8f19f94cbd7345d30374f7409f368d031e55657d159 -# -# -# -# -# An insertion device, as used in a synchrotron light source. -# -# -# -# -# -# -# -# separation between opposing pairs of magnetic poles -# -# -# angular of gap difference between upstream and downstream ends of the insertion device -# -# -# -# number of poles -# -# -# -# beam displacement parameter -# -# -# length of insertion device -# -# -# total power delivered by insertion device -# -# -# energy of peak intensity in output spectrum -# -# -# bandwidth of peak energy -# -# -# harmonic number of peak -# -# -# spectrum of insertion device -# -# -# "Engineering" position of insertion device -# -# -# -# This group describes the shape of the beam line component -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a insertion device. -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# diff --git a/base_classes/nyaml/NXinstrument.yaml b/base_classes/nyaml/NXinstrument.yaml deleted file mode 100644 index 4db16ed912..0000000000 --- a/base_classes/nyaml/NXinstrument.yaml +++ /dev/null @@ -1,154 +0,0 @@ -category: base -doc: | - 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. -type: group -NXinstrument(NXobject): - name: - doc: | - Name of instrument - \@short_name: - doc: | - short name for instrument, perhaps the acronym - (NXactuator): - (NXaperture): - (NXattenuator): - (NXbeam): - (NXbeam_stop): - (NXbending_magnet): - (NXcollimator): - (NXcollection): - (NXcapillary): - (NXcrystal): - (NXdetector): - (NXdetector_group): - (NXdisk_chopper): - (NXevent_data): - (NXfabrication): - (NXfermi_chopper): - (NXfilter): - (NXflipper): - (NXguide): - (NXhistory): - (NXinsertion_device): - (NXmirror): - (NXmoderator): - (NXmonochromator): - (NXpolarizer): - (NXpositioner): - (NXresolution): - (NXsensor): - (NXsource): - (NXtransformations)DIFFRACTOMETER: - (NXvelocity_selector): - (NXxraylens): - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 983ae9f80eebc3a829055922fe42262a639af0d8b04bb8af4339e82ac5e11312 -# -# -# -# -# -# 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. -# -# -# Name of instrument -# -# short name for instrument, perhaps the acronym -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# diff --git a/base_classes/nyaml/NXlog.yaml b/base_classes/nyaml/NXlog.yaml deleted file mode 100644 index c7ed7cdd0c..0000000000 --- a/base_classes/nyaml/NXlog.yaml +++ /dev/null @@ -1,252 +0,0 @@ -category: base -doc: | - Information recorded as a function of time. - - Description of information that is recorded against - time. There are two common use cases for this: - - - When logging data such as temperature during a run - - When data is taken in streaming mode data acquisition, - i.e. just timestamp, value pairs are stored and - correlated later in data reduction with other data, - - - In both cases, NXlog contains - the logged or streamed values and the times at which they were measured as elapsed time since a starting - time recorded in ISO8601 format. The time units are - specified in the units attribute. An optional scaling attribute - can be used to accomodate non standard clocks. - - - This method of storing logged data helps to distinguish instances in which a variable contains signal or - axis coordinate values of plottable data, in which case it is stored - in an :ref:`NXdata` group, and instances in which it is logged during the - run, when it should be stored in an :ref:`NXlog` group. - - In order to make random access to timestamped data faster there is an optional array pair of - ``cue_timestamp_zero`` and ``cue_index``. The ``cue_timestamp_zero`` will - contain coarser timestamps than in the time array, say - every five minutes. The ``cue_index`` will then contain the - index into the time,value pair of arrays for that - coarser ``cue_timestamp_zero``. -type: group -NXlog(NXobject): - time(NX_NUMBER): - unit: NX_TIME - doc: | - Time of logged entry. The times are relative to the "start" attribute - and in the units specified in the "units" - attribute. Please note that absolute - timestamps under unix are relative to ``1970-01-01T00:00:00.0Z``. - - The scaling_factor, when present, has to be applied to the time values in order - to arrive at the units specified in the units attribute. The scaling_factor allows - for arbitrary time units such as ticks of some hardware clock. - \@start: - type: NX_DATE_TIME - \@scaling_factor: - type: NX_NUMBER - value(NX_NUMBER): - unit: NX_ANY - doc: | - Array of logged value, such as temperature. If this is - a single value the dimensionality is - nEntries. However, NXlog can also be used to store - multi dimensional time stamped data such as images. In - this example the dimensionality of values would be value[nEntries,xdim,ydim]. - raw_value(NX_NUMBER): - unit: NX_ANY - doc: | - Array of raw information, such as thermocouple voltage - description: - doc: | - Description of logged value - average_value(NX_FLOAT): - unit: NX_ANY - average_value_error(NX_FLOAT): - unit: NX_ANY - deprecated: | - see: https://github.com/nexusformat/definitions/issues/639 - doc: | - estimated uncertainty (often used: standard deviation) of average_value - average_value_errors(NX_FLOAT): - unit: NX_ANY - doc: | - estimated uncertainty (often used: standard deviation) of average_value - minimum_value(NX_FLOAT): - unit: NX_ANY - maximum_value(NX_FLOAT): - unit: NX_ANY - duration(NX_FLOAT): - unit: NX_ANY - doc: | - Total time log was taken - cue_timestamp_zero(NX_NUMBER): - unit: NX_TIME - doc: | - Timestamps matching the corresponding cue_index into the - time, value pair. - \@start: - type: NX_DATE_TIME - doc: | - If missing start is assumed to be the same as for "time". - \@scaling_factor: - type: NX_NUMBER - doc: | - If missing start is assumed to be the same as for "time". - cue_index(NX_INT): - doc: | - Index into the time, value pair matching the corresponding - cue_timestamp_zero. - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# caf772d7612b434de85496ce95acec4cd1dc6b1c198f9476067f5b415adc45e0 -# -# -# -# -# -# Information recorded as a function of time. -# -# Description of information that is recorded against -# time. There are two common use cases for this: -# -# - When logging data such as temperature during a run -# - When data is taken in streaming mode data acquisition, -# i.e. just timestamp, value pairs are stored and -# correlated later in data reduction with other data, -# -# -# In both cases, NXlog contains -# the logged or streamed values and the times at which they were measured as elapsed time since a starting -# time recorded in ISO8601 format. The time units are -# specified in the units attribute. An optional scaling attribute -# can be used to accomodate non standard clocks. -# -# -# This method of storing logged data helps to distinguish instances in which a variable contains signal or -# axis coordinate values of plottable data, in which case it is stored -# in an :ref:`NXdata` group, and instances in which it is logged during the -# run, when it should be stored in an :ref:`NXlog` group. -# -# In order to make random access to timestamped data faster there is an optional array pair of -# ``cue_timestamp_zero`` and ``cue_index``. The ``cue_timestamp_zero`` will -# contain coarser timestamps than in the time array, say -# every five minutes. The ``cue_index`` will then contain the -# index into the time,value pair of arrays for that -# coarser ``cue_timestamp_zero``. -# -# -# -# -# Time of logged entry. The times are relative to the "start" attribute -# and in the units specified in the "units" -# attribute. Please note that absolute -# timestamps under unix are relative to ``1970-01-01T00:00:00.0Z``. -# -# The scaling_factor, when present, has to be applied to the time values in order -# to arrive at the units specified in the units attribute. The scaling_factor allows -# for arbitrary time units such as ticks of some hardware clock. -# -# -# -# -# -# -# Array of logged value, such as temperature. If this is -# a single value the dimensionality is -# nEntries. However, NXlog can also be used to store -# multi dimensional time stamped data such as images. In -# this example the dimensionality of values would be value[nEntries,xdim,ydim]. -# -# -# -# Array of raw information, such as thermocouple voltage -# -# -# Description of logged value -# -# -# -# estimated uncertainty (often used: standard deviation) of average_value -# -# -# estimated uncertainty (often used: standard deviation) of average_value -# -# -# -# -# Total time log was taken -# -# -# -# Timestamps matching the corresponding cue_index into the -# time, value pair. -# -# -# If missing start is assumed to be the same as for "time". -# -# -# If missing start is assumed to be the same as for "time". -# -# -# -# -# Index into the time, value pair matching the corresponding -# cue_timestamp_zero. -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# diff --git a/base_classes/nyaml/NXmirror.yaml b/base_classes/nyaml/NXmirror.yaml deleted file mode 100644 index f9eaf63302..0000000000 --- a/base_classes/nyaml/NXmirror.yaml +++ /dev/null @@ -1,346 +0,0 @@ -category: base -doc: | - A beamline mirror or supermirror. -type: group -NXmirror(NXobject): - (NXgeometry): - deprecated: | - Use the field `depends_on` and :ref:`NXtransformations` to position the mirror and NXoff_geometry to describe its shape instead - doc: | - - # TODO explain what this group means - type: - enumeration: - single: - doc: | - mirror with a single material as a reflecting surface - multi: - doc: | - mirror with stacked, multiple layers as a reflecting surface - description: - doc: | - description of this mirror - incident_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - (NXdata)reflectivity: - - # TODO Trac ticket #45 applies here. - # https://github.com/nexusformat/definitions/issues/45 - # TODO Solution of ticket #41 will apply here, as well. - # https://github.com/nexusformat/definitions/issues/41 - doc: | - Reflectivity as function of wavelength - - # TODO need more documentation throughout - bend_angle_x(NX_FLOAT): - unit: NX_ANGLE - doc: | - bend_angle_y(NX_FLOAT): - unit: NX_ANGLE - doc: | - interior_atmosphere: - enumeration: [vacuum, helium, argon] - external_material: - doc: | - external material outside substrate - m_value(NX_FLOAT): - unit: NX_UNITLESS - doc: | - The m value for a supermirror, which defines the supermirror - regime in multiples of the critical angle of Nickel. - substrate_material: - doc: | - substrate_density(NX_FLOAT): - unit: NX_MASS_DENSITY - doc: | - substrate_thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - coating_material: - doc: | - substrate_roughness(NX_FLOAT): - unit: NX_LENGTH - doc: | - coating_roughness(NX_FLOAT): - unit: NX_LENGTH - doc: | - even_layer_material: - doc: | - even_layer_density(NX_FLOAT): - unit: NX_MASS_DENSITY - doc: | - odd_layer_material: - doc: | - odd_layer_density(NX_FLOAT): - unit: NX_MASS_DENSITY - doc: | - layer_thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - An array describing the thickness of each layer - (NXshape)shape: - deprecated: Use NXoff_geometry instead - doc: | - A NXshape group describing the shape of the mirror - figure_data(NXdata): - doc: | - Numerical description of the surface figure of the mirror. - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the beam line component - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - 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. - - Given a flat mirror, the reference plane is the plane which contains the "entry" surface of the mirror. The reference - point of the mirror in the x and y axis is the centre of the mirror on that plane. The reference plane is orthogonal - to the z axis and the location of this plane is the reference point on the z axis. The mirror faces negative z values. - - .. image:: mirror/mirror.png - :width: 40% - (NXtransformations): - doc: | - 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. - - # TODO need more parameters here, such as ... - # list from Rainer Gehrke, DESY (some items may already be present) - # Parameters for mirrors - # Field indicating whether simple or multilayer - # Substrate element or compound - # Substrate density - # In case of multilayer: Even layer material (element or compound) - # Even layer density - # Odd layer material (element or compound) - # Odd layer density - # Number of layer pairs - # Layer thickness (array) - # Figure for crystals and mirrors (to describe curved surfaces) - # Field indicating whether concave or convex - # Field indicating whether cylindrical or not - # If cylindrical: cylinder orientation angle - # Now come the different surface figures with the necessary parameters: - # 1. Flat - # 2. Spherical (spherical radius) - # 3. Elliptical and hyperbolical (semi-major axis, semi-minor axis, angle of major axis and pole) - # 4. Toroidal (major radius, minor radius) - # 5. Parabolical (parabolic parameter a) - # 6. Conical (cone half aperture) - # 7. Polynomial (degree of polynom, array with polynom coefficients) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# b7d151af41ea233528d90396e8a983f4e2d19f8fcd58b1340140f7e55b843af9 -# -# -# -# -# A beamline mirror or supermirror. -# -# -# -# -# -# -# mirror with a single material as a reflecting surface -# mirror with stacked, multiple layers as a reflecting surface -# -# -# -# description of this mirror -# -# -# -# -# -# -# Reflectivity as function of wavelength -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# external material outside substrate -# -# -# -# The m value for a supermirror, which defines the supermirror -# regime in multiples of the critical angle of Nickel. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# An array describing the thickness of each layer -# -# -# A NXshape group describing the shape of the mirror -# -# -# Numerical description of the surface figure of the mirror. -# -# -# -# This group describes the shape of the beam line component -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# Given a flat mirror, the reference plane is the plane which contains the "entry" surface of the mirror. The reference -# point of the mirror in the x and y axis is the centre of the mirror on that plane. The reference plane is orthogonal -# to the z axis and the location of this plane is the reference point on the z axis. The mirror faces negative z values. -# -# .. image:: mirror/mirror.png -# :width: 40% -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# -# -# diff --git a/base_classes/nyaml/NXmoderator.yaml b/base_classes/nyaml/NXmoderator.yaml deleted file mode 100644 index 0a745817e7..0000000000 --- a/base_classes/nyaml/NXmoderator.yaml +++ /dev/null @@ -1,193 +0,0 @@ -category: base -doc: | - A neutron moderator -type: group -NXmoderator(NXobject): - (NXgeometry): - deprecated: | - Use the field `depends_on` and :ref:`NXtransformations` to position the moderator and NXoff_geometry to describe its shape instead - doc: | - "Engineering" position of moderator - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Effective distance as seen by measuring radiation. - Note, it is recommended to use NXtransformations instead. - type: - enumeration: [H20, D20, Liquid H2, Liquid CH4, Liquid D2, Solid D2, C, Solid CH4, Solid H2] - poison_depth(NX_FLOAT): - unit: NX_LENGTH - coupled(NX_BOOLEAN): - doc: | - whether the moderator is coupled - coupling_material: - doc: | - The material used for coupling. Usually Cd. - poison_material: - enumeration: [Gd, Cd] - temperature(NX_FLOAT): - unit: NX_TEMPERATURE - doc: | - average/nominal moderator temperature - (NXlog)temperature_log: - doc: | - log file of moderator temperature - (NXdata)pulse_shape: - doc: | - moderator pulse shape - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the moderator - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - The reference point of the moderator is its center in the x and y axis. The reference point on the z axis is the - surface of the moderator pointing towards the source (the negative part of the z axis). - - .. image:: moderator/moderator.png - :width: 40% - (NXtransformations): - doc: | - 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e19c0c5a13cef1856c1c090fe62b5eb4b5af5449dc8a327697cad5bcf7d4fd59 -# -# -# -# -# A neutron moderator -# -# "Engineering" position of moderator -# -# -# -# Effective distance as seen by measuring radiation. -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# whether the moderator is coupled -# -# -# The material used for coupling. Usually Cd. -# -# -# -# -# -# -# -# -# average/nominal moderator temperature -# -# -# log file of moderator temperature -# -# -# moderator pulse shape -# -# -# -# This group describes the shape of the moderator -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# The reference point of the moderator is its center in the x and y axis. The reference point on the z axis is the -# surface of the moderator pointing towards the source (the negative part of the z axis). -# -# .. image:: moderator/moderator.png -# :width: 40% -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# diff --git a/base_classes/nyaml/NXmonitor.yaml b/base_classes/nyaml/NXmonitor.yaml deleted file mode 100644 index ef241cc901..0000000000 --- a/base_classes/nyaml/NXmonitor.yaml +++ /dev/null @@ -1,293 +0,0 @@ -category: base -doc: | - A monitor of incident beam data. - - It is similar to the :ref:`NXdata` groups containing - monitor data and its associated axis coordinates, e.g. time_of_flight or - wavelength in pulsed neutron instruments. However, it may also include - integrals, or scalar monitor counts, which are often used in both in both - pulsed and steady-state instrumentation. -type: group -NXmonitor(NXobject): - mode: - doc: | - Count to a preset value based on either clock time (timer) - or received monitor counts (monitor). - enumeration: [monitor, timer] - start_time(NX_DATE_TIME): - doc: | - Starting time of measurement - end_time(NX_DATE_TIME): - doc: | - Ending time of measurement - preset(NX_NUMBER): - unit: NX_ANY - doc: | - preset value for time or monitor - distance(NX_FLOAT): - unit: NX_LENGTH - deprecated: Use transformations/distance instead - doc: | - Distance of monitor from sample - range(NX_FLOAT): - unit: NX_ANY - doc: | - Range (X-axis, Time-of-flight, etc.) over which the integral was calculated - dimensions: - dim: [[1, 2]] - nominal(NX_NUMBER): - unit: NX_ANY - doc: | - Nominal reading to be used for normalisation purposes. - integral(NX_NUMBER): - unit: NX_ANY - doc: | - Total integral monitor counts - integral_log(NXlog): - doc: | - Time variation of monitor counts - type: - enumeration: [Fission Chamber, Scintillator] - time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - doc: | - Time-of-flight - dimensions: - dim: [[1, ]] - dim_parameters: - ref: ['efficiency'] - efficiency(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - Monitor efficiency - dimensions: - dim: [[1, ]] - dim_parameters: - ref: ['i'] - data(NX_NUMBER): - unit: NX_ANY - doc: | - Monitor data - dimensions: - rank: dataRank - doc: | - The rank (``dataRank``) of the ``data`` must satisfy - ``1 <= dataRank <= NX_MAXRANK=32``. - At least one ``dim`` must have length ``n``. - dim: [] - sampled_fraction(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Proportion of incident beam sampled by the monitor (0 -# -# -# -# -# A monitor of incident beam data. -# -# It is similar to the :ref:`NXdata` groups containing -# monitor data and its associated axis coordinates, e.g. time_of_flight or -# wavelength in pulsed neutron instruments. However, it may also include -# integrals, or scalar monitor counts, which are often used in both in both -# pulsed and steady-state instrumentation. -# -# -# -# Count to a preset value based on either clock time (timer) -# or received monitor counts (monitor). -# -# -# -# -# -# -# -# Starting time of measurement -# -# -# Ending time of measurement -# -# -# preset value for time or monitor -# -# -# Distance of monitor from sample -# -# -# Range (X-axis, Time-of-flight, etc.) over which the integral was calculated -# -# -# -# Nominal reading to be used for normalisation purposes. -# -# -# Total integral monitor counts -# -# -# Time variation of monitor counts -# -# -# -# -# -# -# -# -# Time-of-flight -# -# -# -# -# -# Monitor efficiency -# -# -# -# -# Monitor data -# -# -# -# The rank (``dataRank``) of the ``data`` must satisfy -# ``1 <= dataRank <= NX_MAXRANK=32``. -# At least one ``dim`` must have length ``n``. -# -# -# -# -# Proportion of incident beam sampled by the monitor (0<x<1) -# -# -# Geometry of the monitor -# -# -# -# Elapsed actual counting time, can be an array of size ``np`` -# when scanning. This is not the difference of the calendar time -# but the time the instrument was really counting, without -# pauses or times lost due beam unavailability -# -# -# -# -# This group describes the shape of the beam line component -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# The reference plane of the monitor contains the surface of the detector that faces the source -# and is the entry point of the beam. The reference point of the monitor in the x and y axis is -# its centre on this surface. The reference plane is orthogonal to the the z axis and the -# reference point on this z axis is where they intersect. -# -# .. image:: monitor/monitor.png -# :width: 40% -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# diff --git a/base_classes/nyaml/NXmonochromator.yaml b/base_classes/nyaml/NXmonochromator.yaml deleted file mode 100644 index 5c0653fa3a..0000000000 --- a/base_classes/nyaml/NXmonochromator.yaml +++ /dev/null @@ -1,230 +0,0 @@ -category: base -doc: | - A wavelength defining device. - - This is a base class for everything which - selects a wavelength or energy, be it a - monochromator crystal, a velocity selector, - an undulator or whatever. - - The expected units are: - - * wavelength: angstrom - * energy: eV -type: group -NXmonochromator(NXobject): - wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - wavelength selected - wavelength_error(NX_FLOAT): - unit: NX_WAVELENGTH - deprecated: | - see https://github.com/nexusformat/definitions/issues/820 - doc: | - wavelength standard deviation - wavelength_errors(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - wavelength standard deviation - energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - energy selected - energy_error(NX_FLOAT): - unit: NX_ENERGY - deprecated: | - see https://github.com/nexusformat/definitions/issues/820 - doc: | - energy standard deviation - energy_errors(NX_FLOAT): - unit: NX_ENERGY - doc: | - energy standard deviation - energy_dispersion(NX_FLOAT): - unit: NX_ANY - doc: | - Energy dispersion at the exit slit, typically given as eV/mm. - wavelength_dispersion(NX_FLOAT): - unit: NX_ANY - doc: | - Wavelength dispersion at the exit slit. - entrance_slit(NXaperture): - doc: | - Size, position and shape of the entrance slit of the monochromator. - exit_slit(NXaperture): - doc: | - Size, position and shape of the exit slit of the monochromator. - (NXdata)distribution: - (NXgeometry)geometry: - deprecated: | - Use the field `depends_on` and :ref:`NXtransformations` to position the monochromator and NXoff_geometry to describe its shape instead - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the beam line component - (NXcrystal): - doc: | - Use as many crystals as necessary to describe - (NXvelocity_selector): - (NXgrating): - doc: | - For diffraction grating based monochromators - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a monochromator. - (NXtransformations): - doc: | - 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# c08b96b75acfa31a5ceaceb31ae19710c3e89fc854628ffda4dfa0af2c3389ba -# -# -# -# -# -# A wavelength defining device. -# -# This is a base class for everything which -# selects a wavelength or energy, be it a -# monochromator crystal, a velocity selector, -# an undulator or whatever. -# -# The expected units are: -# -# * wavelength: angstrom -# * energy: eV -# -# -# -# wavelength selected -# -# -# wavelength standard deviation -# -# -# wavelength standard deviation -# -# -# energy selected -# -# -# energy standard deviation -# -# -# energy standard deviation -# -# -# -# Energy dispersion at the exit slit, typically given as eV/mm. -# -# -# -# -# Wavelength dispersion at the exit slit. -# -# -# -# -# Size, position and shape of the entrance slit of the monochromator. -# -# -# -# -# Size, position and shape of the exit slit of the monochromator. -# -# -# -# -# -# -# This group describes the shape of the beam line component -# -# -# Use as many crystals as necessary to describe -# -# For diffraction grating based monochromators -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a monochromator. -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# diff --git a/base_classes/nyaml/NXnote.yaml b/base_classes/nyaml/NXnote.yaml deleted file mode 100644 index 865d881661..0000000000 --- a/base_classes/nyaml/NXnote.yaml +++ /dev/null @@ -1,116 +0,0 @@ -category: base -doc: | - 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 -type: group -NXnote(NXobject): - author: - doc: | - Author or creator of note - date(NX_DATE_TIME): - doc: | - Date note created/added - type: - doc: | - Mime content type of note data field e.g. image/jpeg, text/plain, text/html - file_name: - doc: | - Name of original file name if note was read from an external source - description: - doc: | - Title of an image or other details of the note - sequence_index(NX_POSINT): - doc: | - Sequence index of note, for placing a sequence of - multiple **NXnote** groups in an order. Starts with 1. - data(NX_BINARY): - doc: | - Binary note data - if text, line terminator is [CR][LF]. - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 84bef3405d06363ee2d535d572bb283037adf7509a67e3266f0bbc3e9edb6ae6 -# -# -# -# -# -# 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 -# -# -# Author or creator of note -# -# -# Date note created/added -# -# -# Mime content type of note data field e.g. image/jpeg, text/plain, text/html -# -# -# Name of original file name if note was read from an external source -# -# -# Title of an image or other details of the note -# -# -# -# Sequence index of note, for placing a sequence of -# multiple **NXnote** groups in an order. Starts with 1. -# -# -# -# Binary note data - if text, line terminator is [CR][LF]. -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# diff --git a/base_classes/nyaml/NXobject.yaml b/base_classes/nyaml/NXobject.yaml deleted file mode 100644 index 619b6c2f70..0000000000 --- a/base_classes/nyaml/NXobject.yaml +++ /dev/null @@ -1,44 +0,0 @@ -category: base -doc: | - This is the base object of NeXus -type: group -NXobject: - - # attribute name="name">name of instance -# -# -# -# -# This is the base object of NeXus -# -# -# -# diff --git a/base_classes/nyaml/NXoff_geometry.yaml b/base_classes/nyaml/NXoff_geometry.yaml deleted file mode 100644 index 38cc34536e..0000000000 --- a/base_classes/nyaml/NXoff_geometry.yaml +++ /dev/null @@ -1,197 +0,0 @@ -category: base -doc: | - Geometry (shape) description. - The format closely matches the Object File Format (OFF) which can be output - by most CAD software. - It can be used to describe the shape of any beamline component, including detectors. - In the case of detectors it can be used to define the shape of a single pixel, or, - if the pixel shapes are non-uniform, to describe the shape of the whole detector. -symbols: - doc: | - These symbols will be used below. - i: | - number of vertices in the shape - k: | - number of faces in the shape - l: | - number faces which are detecting surfaces or form the boundary of - detecting volumes -type: group -NXoff_geometry(NXobject): - vertices(NX_NUMBER): - unit: NX_LENGTH - doc: | - List of x,y,z coordinates for vertices. - The origin of the coordinates is the position of the parent component, for - example the NXdetector which the geometry describes. - If the shape describes a single pixel for a detector with uniform pixel - shape then the origin is the position of each pixel as described by the - ``x/y/z_pixel_offset`` datasets in ``NXdetector``. - dimensions: - rank: 2 - dim: [[1, i], [2, 3]] - winding_order(NX_INT): - doc: | - List of indices of vertices in the ``vertices`` dataset to form each face, - right-hand rule for face normal. - dimensions: - rank: 1 - dim: [[1, j]] - faces(NX_INT): - doc: | - The start index in ``winding_order`` for each face. - dimensions: - rank: 1 - dim: [[1, k]] - detector_faces(NX_INT): - doc: | - List of pairs of index in the "faces" dataset and detector id. Face IDs in - the first column, and corresponding detector IDs in the second column. - This dataset should only be used only if the ``NXoff_geometry`` group is - describing a detector. - Note, the face indices must be in ascending order but need not be - consecutive as not every face in faces need be a detecting surface or - boundary of detecting volume. - Can use multiple entries with the same detector id to define detector volumes. - dimensions: - rank: 2 - dim: [[1, l], [2, 2]] - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2be673f4ea5adadf1df3cceb08dd7148dfb85af3e452002c337ffd411bdb2cf7 -# -# -# -# -# -# -# These symbols will be used below. -# number of vertices in the shape -# number of faces in the shape -# -# -# number faces which are detecting surfaces or form the boundary of -# detecting volumes -# -# -# -# -# -# Geometry (shape) description. -# The format closely matches the Object File Format (OFF) which can be output -# by most CAD software. -# It can be used to describe the shape of any beamline component, including detectors. -# In the case of detectors it can be used to define the shape of a single pixel, or, -# if the pixel shapes are non-uniform, to describe the shape of the whole detector. -# -# -# -# -# -# List of x,y,z coordinates for vertices. -# The origin of the coordinates is the position of the parent component, for -# example the NXdetector which the geometry describes. -# If the shape describes a single pixel for a detector with uniform pixel -# shape then the origin is the position of each pixel as described by the -# ``x/y/z_pixel_offset`` datasets in ``NXdetector``. -# -# -# -# -# -# -# -# -# -# -# -# -# List of indices of vertices in the ``vertices`` dataset to form each face, -# right-hand rule for face normal. -# -# -# -# -# -# -# -# -# -# -# The start index in ``winding_order`` for each face. -# -# -# -# -# -# -# -# -# -# -# List of pairs of index in the "faces" dataset and detector id. Face IDs in -# the first column, and corresponding detector IDs in the second column. -# This dataset should only be used only if the ``NXoff_geometry`` group is -# describing a detector. -# Note, the face indices must be in ascending order but need not be -# consecutive as not every face in faces need be a detecting surface or -# boundary of detecting volume. -# Can use multiple entries with the same detector id to define detector volumes. -# -# -# -# -# -# -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# diff --git a/base_classes/nyaml/NXorientation.yaml b/base_classes/nyaml/NXorientation.yaml deleted file mode 100644 index 914467b039..0000000000 --- a/base_classes/nyaml/NXorientation.yaml +++ /dev/null @@ -1,111 +0,0 @@ -category: base -doc: | - legacy class - recommend to use :ref:`NXtransformations` now - - Description for a general orientation of a component - used by :ref:`NXgeometry` -type: group -NXorientation(NXobject): - (NXgeometry): - doc: | - Link to another object if we are using relative positioning, else absent - value(NX_FLOAT): - unit: NX_UNITLESS - doc: | - The orientation information is stored as direction cosines. The direction cosines will - be between the local coordinate directions and the reference directions (to origin or - relative NXgeometry). Calling the local unit vectors (x',y',z') and the reference unit - vectors (x,y,z) the six numbers will be [x' dot x, x' dot y, x' dot z, y' dot x, y' dot - y, y' dot z] where "dot" is the scalar dot product (cosine of the angle between the unit - vectors). The unit vectors in both the local and reference coordinates are right-handed - and orthonormal. - - The pair of groups NXtranslation and NXorientation together - describe the position of a component. - dimensions: - - # numobj,6 - dim: [[1, numobj], [2, 6]] - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 539d64423132c137af4dee9abeedd4bb0b5bb37f5e02d209df77909e338c6ae6 -# -# -# -# -# -# legacy class - recommend to use :ref:`NXtransformations` now -# -# Description for a general orientation of a component - used by :ref:`NXgeometry` -# -# -# Link to another object if we are using relative positioning, else absent -# -# -# -# The orientation information is stored as direction cosines. The direction cosines will -# be between the local coordinate directions and the reference directions (to origin or -# relative NXgeometry). Calling the local unit vectors (x',y',z') and the reference unit -# vectors (x,y,z) the six numbers will be [x' dot x, x' dot y, x' dot z, y' dot x, y' dot -# y, y' dot z] where "dot" is the scalar dot product (cosine of the angle between the unit -# vectors). The unit vectors in both the local and reference coordinates are right-handed -# and orthonormal. -# -# The pair of groups NXtranslation and NXorientation together -# describe the position of a component. -# -# -# -# -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# diff --git a/base_classes/nyaml/NXparameters.yaml b/base_classes/nyaml/NXparameters.yaml deleted file mode 100644 index f144cb1192..0000000000 --- a/base_classes/nyaml/NXparameters.yaml +++ /dev/null @@ -1,76 +0,0 @@ -category: base -doc: | - Container for parameters, usually used in processing or analysis. -type: group -NXparameters(NXobject): - TERM: - exists: ['min', '0', 'max', 'unbounded'] - nameType: any - - # maxOccurs="unbounded" is intended but is not allowed by current syntax - doc: | - A parameter (also known as a term) that is used in or results from processing. - \@units: - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 6529709030bdbef6f1d3bcfb08955aaf52c7f798adfa474c0528d5c3e686edff -# -# -# -# -# Container for parameters, usually used in processing or analysis. -# -# -# A parameter (also known as a term) that is used in or results from processing. -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# diff --git a/base_classes/nyaml/NXpdb.yaml b/base_classes/nyaml/NXpdb.yaml deleted file mode 100644 index 7aa384a626..0000000000 --- a/base_classes/nyaml/NXpdb.yaml +++ /dev/null @@ -1,329 +0,0 @@ -category: base - -# The ignoreExtra* attributes are used in the definition to -# avoid warning messages that would be generated from -# unexpected groups, fields, and attributes. -# Since no groups or attributes are declared here, _every_ -# child of this class would generate a warning message without this -# attribute being set to "true". -doc: | - A NeXus transliteration of a PDB file, to be validated only as a PDB - rather than in NeXus. - - Use :ref:`NXpdb` to incorporate the information in an arbitrary - PDB into a NeXus file. - - The main suggestion is to use this as a container - class for a PDB entry to describe a sample in NXsample, - but it may be more appropriate to place this higher in the - hierarchy, say in NXentry. - - The structure has to follow the structure of a PDB - with each PDB data block mapped to a NeXus group of class NXpdb, - using a lowercase version of the data block name as the name - of the NeXus group, each PDB category in that data block - mapped to a NeXus group of class NXpdb and with each PDB column - mapped to a NeXus field. Each column in a looped PDB category - should always be presented as a 1-dimensional array. The columns - in an unlooped PDB category should be presented as scalar values. - If a PDB category specifies particular units for columns, the same - units should beused for the corresponding fields. - - A PDB entry is unambigous when all information is carried as text. - All text data should be presented as quoted strings, with the quote - marks except for the null values "." or "?" - - For clarity in NXpdb form, numeric data may be presented using the - numeric types specified in the mmCIF dictionary. In that case, - if a PDB null value, "." or "?", is contained in a numeric column, the - IEEE nan should be used for "?" and the IEEE inf should be used for ".". - - An arbitrary DDL2 CIF file can be represented in NeXus using NXpdb. - However, if save frames are required, an NXpdb_class attribute with the - value "CBF_cbfsf" is required for each NeXus group representing a save - frame. NXpdb attributes are not required for other CIF components, - but may be used to provide internal documentation. - - The nesting of NXpdb groups and datasets that correspond to a CIF with - two categories and one saveframe, including the NXpdb_class attribues is:: - - (datablock1):NXpdb - @NXpdb_class:CBF_cbfdb - (category1):NXpdb - @NXpdb_class:CBF_cbfcat - (column_name1):[...] - (column_name2):[...] - (column_name3):[...] - ... - (category2):NXpdb - @NXpdb_class:CBF_cbfcat - (column_name4):[...] - (column_name5):[...] - (column_name6):[...] - ... - (saveframe1):NXpdb - @NXpdb_class:CBF_cbfsf - (category3):NXpdb - @NXpdb_class:CBF_cbfcat - (column_name7):[...] - (column_name8):[...] - (column_name9):[...] - ... - ... - ... - - - - For example, a PDB entry that begins:: - - data_1YVA - # - _entry.id 1YVA - # - _audit_conform.dict_name mmcif_pdbx.dic - _audit_conform.dict_version 5.279 - _audit_conform.dict_location http://mmcif.pdb.org/dictionaries/ascii/mmcif_pdbx.dic - # - loop_ - _database_2.database_id - _database_2.database_code - PDB 1YVA - RCSB RCSB031959 - WWPDB D_1000031959 - # - - would produce:: - - sample:NXsample - 1yva:NXpdb - entry:NXpdb - id:"1YVA" - audit_conform:NXpdb - dict_name:"mmcif_pdbx.dic" - dict_version:"5.279" - dict_location:"http://mmcif.pdb.org/dictionaries/ascii/mmcif_pdbx.dic" - database_2:NXpdb - database_id:["PDB","RCSB","WWPDB"] - database_code:["1YVA","RCSB031959","D_1000031959"] - - another example is the following excerpt from pdb entry 9ins, giving the sequences - of the two chains:: - - loop_ - _entity_poly.entity_id - _entity_poly.nstd_linkage - _entity_poly.nstd_monomer - _entity_poly.pdbx_seq_one_letter_code - _entity_poly.pdbx_seq_one_letter_code_can - _entity_poly.type - 1 no no GIVEQCCTSICSLYQLENYCN GIVEQCCTSICSLYQLENYCN polypeptide(L) - 2 no no FVNQHLCGSHLVEALYLVCGERGFFYTPKA FVNQHLCGSHLVEALYLVCGERGFFYTPKA - polypeptide(L) - - which converts to:: - - entity_poly:NXpdb - @NXpdb_class:CBF_cbfcat - entity_id:["1", "2"] - nstd_linkage:["no", "no"] - nstd_monomer:["no", "no"] - pdbx_seq_one_letter_code:["GIVEQCCTSICSLYQLENYCN","FVNQHLCGSHLVEALYLVCGERGFFYTPKA"] - pdbx_seq_one_letter_code_can:["GIVEQCCTSICSLYQLENYCN","FVNQHLCGSHLVEALYLVCGERGFFYTPKA"] - type:["polypeptide(L)", "polypeptide(L)"] -type: group -ignoreExtraGroups: true -ignoreExtraFields: true -ignoreExtraAttributes: true -NXpdb(NXobject): - - # NOTE - # ===== - # NXpdb is a class not validated by the NXDL tools. - # Do not add any subgroups in this nxdl file. - # See: https://github.com/nexusformat/definitions/issues/259 - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2784bb864dfa1608a7ebfad032a43f399341b538937795276ff0c4923061813c -# -# -# -# -# -# -# -# -# A NeXus transliteration of a PDB file, to be validated only as a PDB -# rather than in NeXus. -# -# Use :ref:`NXpdb` to incorporate the information in an arbitrary -# PDB into a NeXus file. -# -# The main suggestion is to use this as a container -# class for a PDB entry to describe a sample in NXsample, -# but it may be more appropriate to place this higher in the -# hierarchy, say in NXentry. -# -# The structure has to follow the structure of a PDB -# with each PDB data block mapped to a NeXus group of class NXpdb, -# using a lowercase version of the data block name as the name -# of the NeXus group, each PDB category in that data block -# mapped to a NeXus group of class NXpdb and with each PDB column -# mapped to a NeXus field. Each column in a looped PDB category -# should always be presented as a 1-dimensional array. The columns -# in an unlooped PDB category should be presented as scalar values. -# If a PDB category specifies particular units for columns, the same -# units should beused for the corresponding fields. -# -# A PDB entry is unambigous when all information is carried as text. -# All text data should be presented as quoted strings, with the quote -# marks except for the null values "." or "?" -# -# For clarity in NXpdb form, numeric data may be presented using the -# numeric types specified in the mmCIF dictionary. In that case, -# if a PDB null value, "." or "?", is contained in a numeric column, the -# IEEE nan should be used for "?" and the IEEE inf should be used for ".". -# -# An arbitrary DDL2 CIF file can be represented in NeXus using NXpdb. -# However, if save frames are required, an NXpdb_class attribute with the -# value "CBF_cbfsf" is required for each NeXus group representing a save -# frame. NXpdb attributes are not required for other CIF components, -# but may be used to provide internal documentation. -# -# The nesting of NXpdb groups and datasets that correspond to a CIF with -# two categories and one saveframe, including the NXpdb_class attribues is:: -# -# (datablock1):NXpdb -# @NXpdb_class:CBF_cbfdb -# (category1):NXpdb -# @NXpdb_class:CBF_cbfcat -# (column_name1):[...] -# (column_name2):[...] -# (column_name3):[...] -# ... -# (category2):NXpdb -# @NXpdb_class:CBF_cbfcat -# (column_name4):[...] -# (column_name5):[...] -# (column_name6):[...] -# ... -# (saveframe1):NXpdb -# @NXpdb_class:CBF_cbfsf -# (category3):NXpdb -# @NXpdb_class:CBF_cbfcat -# (column_name7):[...] -# (column_name8):[...] -# (column_name9):[...] -# ... -# ... -# ... -# -# -# -# For example, a PDB entry that begins:: -# -# data_1YVA -# # -# _entry.id 1YVA -# # -# _audit_conform.dict_name mmcif_pdbx.dic -# _audit_conform.dict_version 5.279 -# _audit_conform.dict_location http://mmcif.pdb.org/dictionaries/ascii/mmcif_pdbx.dic -# # -# loop_ -# _database_2.database_id -# _database_2.database_code -# PDB 1YVA -# RCSB RCSB031959 -# WWPDB D_1000031959 -# # -# -# would produce:: -# -# sample:NXsample -# 1yva:NXpdb -# entry:NXpdb -# id:"1YVA" -# audit_conform:NXpdb -# dict_name:"mmcif_pdbx.dic" -# dict_version:"5.279" -# dict_location:"http://mmcif.pdb.org/dictionaries/ascii/mmcif_pdbx.dic" -# database_2:NXpdb -# database_id:["PDB","RCSB","WWPDB"] -# database_code:["1YVA","RCSB031959","D_1000031959"] -# -# another example is the following excerpt from pdb entry 9ins, giving the sequences -# of the two chains:: -# -# loop_ -# _entity_poly.entity_id -# _entity_poly.nstd_linkage -# _entity_poly.nstd_monomer -# _entity_poly.pdbx_seq_one_letter_code -# _entity_poly.pdbx_seq_one_letter_code_can -# _entity_poly.type -# 1 no no GIVEQCCTSICSLYQLENYCN GIVEQCCTSICSLYQLENYCN polypeptide(L) -# 2 no no FVNQHLCGSHLVEALYLVCGERGFFYTPKA FVNQHLCGSHLVEALYLVCGERGFFYTPKA -# polypeptide(L) -# -# which converts to:: -# -# entity_poly:NXpdb -# @NXpdb_class:CBF_cbfcat -# entity_id:["1", "2"] -# nstd_linkage:["no", "no"] -# nstd_monomer:["no", "no"] -# pdbx_seq_one_letter_code:["GIVEQCCTSICSLYQLENYCN","FVNQHLCGSHLVEALYLVCGERGFFYTPKA"] -# pdbx_seq_one_letter_code_can:["GIVEQCCTSICSLYQLENYCN","FVNQHLCGSHLVEALYLVCGERGFFYTPKA"] -# type:["polypeptide(L)", "polypeptide(L)"] -# -# -# -# -# -# -# diff --git a/base_classes/nyaml/NXpinhole.yaml b/base_classes/nyaml/NXpinhole.yaml deleted file mode 100644 index 864619681b..0000000000 --- a/base_classes/nyaml/NXpinhole.yaml +++ /dev/null @@ -1,125 +0,0 @@ -category: base -doc: | - A simple pinhole. - - For more complex geometries, :ref:`NXaperture` should be used. -type: group -NXpinhole(NXobject): - depends_on(NX_CHAR): - doc: | - Points to the path of the last element in the geometry chain that places - this object in space. - When followed through that chain is supposed to end at an element depending - on "." i.e. the origin of the coordinate system. - If desired the location of the slit can also be described relative to - an NXbeam, which will allow a simple description of a non-centred pinhole. - - The reference direction of the pinhole is parallel with the z axis. The reference - point of the pinhole is its center in the x and y axis. The reference point on the z axis is the - plane which overlaps the side of the opening of the pin hole pointing towards the source (minus on the z axis). - - .. image:: pinhole/pinhole.png - :width: 40% - diameter(NX_NUMBER): - unit: NX_LENGTH - doc: | - Size of the circular hole defining the transmitted beam size. - (NXtransformations): - exists: ['min', '0'] - doc: | - 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. - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 19ce05d9c12858ef112b7200e737f28b29337bebc0dcb1fde53477b9d11d7a29 -# -# -# -# -# -# A simple pinhole. -# -# For more complex geometries, :ref:`NXaperture` should be used. -# -# -# -# Points to the path of the last element in the geometry chain that places -# this object in space. -# When followed through that chain is supposed to end at an element depending -# on "." i.e. the origin of the coordinate system. -# If desired the location of the slit can also be described relative to -# an NXbeam, which will allow a simple description of a non-centred pinhole. -# -# The reference direction of the pinhole is parallel with the z axis. The reference -# point of the pinhole is its center in the x and y axis. The reference point on the z axis is the -# plane which overlaps the side of the opening of the pin hole pointing towards the source (minus on the z axis). -# -# .. image:: pinhole/pinhole.png -# :width: 40% -# -# -# -# -# Size of the circular hole defining the transmitted beam size. -# -# -# -# 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. -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# diff --git a/base_classes/nyaml/NXpolarizer.yaml b/base_classes/nyaml/NXpolarizer.yaml deleted file mode 100644 index 937a78b821..0000000000 --- a/base_classes/nyaml/NXpolarizer.yaml +++ /dev/null @@ -1,135 +0,0 @@ -category: base -doc: | - A spin polarizer. -type: group -NXpolarizer(NXobject): - type: - doc: | - one of these values: "crystal", "supermirror", "3He" - composition: - doc: | - description of the composition of the polarizing material - reflection(NX_INT): - unit: NX_UNITLESS - doc: | - [hkl] values of nominal reflection - dimensions: - dim: [[1, 3]] - efficiency(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - polarizing efficiency - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a polarizer. - (NXtransformations): - doc: | - 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f8c24835ffbb8b6970557927c33cdbc18dd4754019545f0e21142bc6a434d88c -# -# -# -# -# -# A spin polarizer. -# -# -# one of these values: "crystal", "supermirror", "3He" -# -# -# description of the composition of the polarizing material -# -# -# [hkl] values of nominal reflection -# -# -# -# -# -# polarizing efficiency -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a polarizer. -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# diff --git a/base_classes/nyaml/NXpositioner.yaml b/base_classes/nyaml/NXpositioner.yaml deleted file mode 100644 index 00c824dc2f..0000000000 --- a/base_classes/nyaml/NXpositioner.yaml +++ /dev/null @@ -1,200 +0,0 @@ -category: base -doc: | - A generic positioner such as a motor or piezo-electric transducer. -type: group -NXpositioner(NXobject): - name: - doc: | - symbolic or mnemonic name (one word) - description: - doc: | - description of positioner - value(NX_NUMBER): - unit: NX_ANY - doc: | - best known value of positioner - need [n] as may be scanned - dimensions: - rank: 1 - dim: [[1, n]] - raw_value(NX_NUMBER): - unit: NX_ANY - doc: | - raw value of positioner - need [n] as may be scanned - dimensions: - rank: 1 - dim: [[1, n]] - target_value(NX_NUMBER): - unit: NX_ANY - doc: | - targeted (commanded) value of positioner - need [n] as may be scanned - dimensions: - rank: 1 - dim: [[1, n]] - tolerance(NX_NUMBER): - unit: NX_ANY - doc: | - maximum allowable difference between target_value and value - dimensions: - rank: 1 - dim: [[1, n]] - soft_limit_min(NX_NUMBER): - unit: NX_ANY - doc: | - minimum allowed limit to set value - soft_limit_max(NX_NUMBER): - unit: NX_ANY - doc: | - maximum allowed limit to set value - velocity(NX_NUMBER): - unit: NX_ANY - doc: | - velocity of the positioner (distance moved per unit time) - acceleration_time(NX_NUMBER): - unit: NX_ANY - doc: | - time to ramp the velocity up to full speed - - # TODO other parameters: settling time, backlash, link to readback channel - controller_record: - doc: | - Hardware device record, e.g. EPICS process variable, taco/tango ... - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a positioner. - (NXtransformations): - doc: | - 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 057263f7db6ff88628e25a6d1245348ce29909dd7512e6ec6dc215710e1acaac -# -# -# -# -# -# A generic positioner such as a motor or piezo-electric transducer. -# -# -# symbolic or mnemonic name (one word) -# -# -# description of positioner -# -# -# best known value of positioner - need [n] as may be scanned -# -# -# -# raw value of positioner - need [n] as may be scanned -# -# -# -# targeted (commanded) value of positioner - need [n] as may be scanned -# -# -# -# maximum allowable difference between target_value and value -# -# -# -# minimum allowed limit to set value -# -# -# maximum allowed limit to set value -# -# -# velocity of the positioner (distance moved per unit time) -# -# -# time to ramp the velocity up to full speed -# -# -# -# Hardware device record, e.g. EPICS process variable, taco/tango ... -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a positioner. -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# diff --git a/base_classes/nyaml/NXprocess.yaml b/base_classes/nyaml/NXprocess.yaml deleted file mode 100644 index 4b5dde8655..0000000000 --- a/base_classes/nyaml/NXprocess.yaml +++ /dev/null @@ -1,134 +0,0 @@ -category: base -doc: | - Document an event of data processing, reconstruction, or analysis for this data. -type: group -NXprocess(NXobject): - program(NX_CHAR): - doc: | - Name of the program used - sequence_index(NX_POSINT): - doc: | - Sequence index of processing, - for determining the order of multiple **NXprocess** steps. - Starts with 1. - version(NX_CHAR): - doc: | - Version of the program used - date(NX_DATE_TIME): - doc: | - Date and time of processing. - (NXregistration): - doc: | - Describes the operations of image registration - (NXdistortion): - doc: | - Describes the operations of image distortion correction - (NXcalibration): - doc: | - Describes the operations of calibration procedures, e.g. axis calibrations. - (NXnote): - doc: | - The note will contain information about how the data was processed - or anything about the data provenance. - The contents of the note can be anything that the processing code - can understand, or simple text. - - The name will be numbered to allow for ordering of steps. - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 0230d40dc43d25fc7f29df765b121c6bb3d86c63b4e8702d35308c83fd300c25 -# -# -# -# -# Document an event of data processing, reconstruction, or analysis for this data. -# -# Name of the program used -# -# -# -# Sequence index of processing, -# for determining the order of multiple **NXprocess** steps. -# Starts with 1. -# -# -# -# Version of the program used -# -# -# Date and time of processing. -# -# -# -# Describes the operations of image registration -# -# -# -# -# Describes the operations of image distortion correction -# -# -# -# -# Describes the operations of calibration procedures, e.g. axis calibrations. -# -# -# -# -# The note will contain information about how the data was processed -# or anything about the data provenance. -# The contents of the note can be anything that the processing code -# can understand, or simple text. -# -# The name will be numbered to allow for ordering of steps. -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# diff --git a/base_classes/nyaml/NXreflections.yaml b/base_classes/nyaml/NXreflections.yaml deleted file mode 100644 index 04f614ca12..0000000000 --- a/base_classes/nyaml/NXreflections.yaml +++ /dev/null @@ -1,1268 +0,0 @@ -category: base -doc: | - Reflection data from diffraction experiments -symbols: - n: | - number of reflections - m: | - number of experiments - -# NXreflections: candidate NeXus definition for reflection data -type: group -NXreflections(NXobject): - experiments: - exists: ['min', '1'] - doc: | - The experiments from which the reflection data derives - dimensions: - rank: 1 - dim: [[1, m]] - h(NX_NUMBER): - exists: ['min', '1'] - doc: | - The h component of the miller index - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - k(NX_NUMBER): - exists: ['min', '1'] - doc: | - The k component of the miller index - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - l(NX_NUMBER): - exists: ['min', '1'] - doc: | - The l component of the miller index - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - id(NX_INT): - exists: ['min', '1'] - doc: | - The id of the experiment which resulted in the reflection. If the value - is greater than 0, the experiments must link to a multi-experiment NXmx - group - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - reflection_id(NX_INT): - exists: ['min', '1'] - doc: | - The id of the reflection. Multiple partials from the same reflection - should all have the same id - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - entering(NX_BOOLEAN): - exists: ['min', '1'] - doc: | - Is the reflection entering or exiting the Ewald sphere - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - det_module(NX_INT): - exists: ['min', '1'] - doc: | - The detector module on which the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - flags(NX_INT): - exists: ['min', '1'] - doc: | - Status flags describing the reflection. - - This is a bit mask. The bits in the mask follow the convention - used by DIALS, and have the following names: - - === ========================================== - bit name - === ========================================== - 0 ``predicted`` - 1 ``observed`` - 2 ``indexed`` - 3 ``used_in_refinement`` - 4 ``strong`` - 5 ``reference_spot`` - 6 ``dont_integrate`` - 7 ``integrated_sum`` - 8 ``integrated_prf`` - 9 ``integrated`` - 10 ``overloaded`` - 11 ``overlapped`` - 12 ``overlapped_fg`` - 13 ``in_powder_ring`` - 14 ``foreground_includes_bad_pixels`` - 15 ``background_includes_bad_pixels`` - 16 ``includes_bad_pixels`` - 17 ``bad_shoebox`` - 18 ``bad_spot`` - 19 ``used_in_modelling`` - 20 ``centroid_outlier`` - 21 ``failed_during_background_modelling`` - 22 ``failed_during_summation`` - 23 ``failed_during_profile_fitting`` - 24 ``bad_reference`` - === ========================================== - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - d(NX_FLOAT): - exists: ['min', '1'] - doc: | - The resolution of the reflection - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - partiality(NX_FLOAT): - exists: ['min', '1'] - doc: | - The partiality of the reflection. - Dividing by this number will inflate the measured - intensity to the full reflection equivalent. - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - predicted_frame(NX_FLOAT): - unit: NX_UNITLESS - exists: ['min', '1'] - doc: | - The frame on which the bragg peak of the reflection is predicted - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - predicted_x(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '1'] - doc: | - The x position at which the bragg peak of the reflection - is predicted - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - predicted_y(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '1'] - doc: | - The y position at which the bragg peak of the reflection - is predicted - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - predicted_phi(NX_FLOAT): - unit: NX_ANGLE - exists: ['min', '1'] - doc: | - The phi angle at which the bragg peak of the reflection is predicted - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - predicted_px_x(NX_FLOAT): - unit: NX_UNITLESS - exists: ['min', '1'] - doc: | - The x pixel position at which the bragg peak of the reflection is - predicted - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - predicted_px_y(NX_FLOAT): - unit: NX_UNITLESS - exists: ['min', '1'] - doc: | - The y pixel position at which the bragg peak of the reflection is - predicted - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_frame(NX_FLOAT): - unit: NX_UNITLESS - exists: ['min', '1'] - doc: | - The estimate of the frame at which the central impact of the - reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_frame_var(NX_FLOAT): - unit: NX_UNITLESS - exists: ['min', '1'] - doc: | - The variance on the estimate of the frame at which the central - impact of the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_frame_errors(NX_FLOAT): - unit: NX_UNITLESS - exists: ['min', '1'] - doc: | - The standard deviation of the estimate of the frame at which the central - impact of the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_px_x(NX_FLOAT): - unit: NX_UNITLESS - exists: ['min', '1'] - doc: | - The estimate of the pixel x position at which the central impact of - the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_px_x_var(NX_FLOAT): - unit: NX_UNITLESS - exists: ['min', '1'] - doc: | - The variance on the estimate of the pixel x position at which the - central impact of the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_px_x_errors(NX_FLOAT): - unit: NX_UNITLESS - exists: ['min', '1'] - doc: | - The standard deviation of the estimate of the pixel x position at which the - central impact of the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_px_y(NX_FLOAT): - unit: NX_UNITLESS - exists: ['min', '1'] - doc: | - The estimate of the pixel y position at which the central impact of - the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_px_y_var(NX_FLOAT): - unit: NX_UNITLESS - exists: ['min', '1'] - doc: | - The variance on the estimate of the pixel y position at which the - central impact of the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_px_y_errors(NX_FLOAT): - unit: NX_UNITLESS - exists: ['min', '1'] - doc: | - The standard deviation of the estimate of the pixel y position at which the - central impact of the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_phi(NX_FLOAT): - unit: NX_ANGLE - exists: ['min', '1'] - doc: | - The estimate of the phi angle at which the central impact of the - reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_phi_var(NX_FLOAT): - unit: NX_ANGLE - exists: ['min', '1'] - doc: | - The variance on the estimate of the phi angle at which the central - impact of the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_phi_errors(NX_FLOAT): - unit: NX_ANGLE - exists: ['min', '1'] - doc: | - The standard deviation of the estimate of the phi angle at which the central - impact of the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_x(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '1'] - doc: | - The estimate of the x position at which the central - impact of the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_x_var(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '1'] - doc: | - The variance on the estimate of the x position at which - the central impact of the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_x_errors(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '1'] - doc: | - The standard deviation of the estimate of the x position at which - the central impact of the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_y(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '1'] - doc: | - The estimate of the y position at which the central - impact of the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_y_var(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '1'] - doc: | - The variance on the estimate of the y position at which - the central impact of the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - observed_y_errors(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '1'] - doc: | - The standard deviation of the estimate of the y position at which - the central impact of the reflection was recorded - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - bounding_box(NX_INT): - unit: NX_UNITLESS - exists: ['min', '1'] - doc: | - The bounding box around the recorded recorded reflection. - Should be an integer array of length 6, where the 6 values - are pixel positions or frame numbers, as follows: - - ===== =========================== - index meaning - ===== =========================== - 0 The lower pixel x position - 1 The upper pixel x position - 2 The lower pixel y position - 3 The upper pixel y position - 4 The lower frame number - 5 The upper frame number - ===== =========================== - dimensions: - rank: 2 - dim: [[1, n], [2, 6]] - \@description: - doc: | - Describes the dataset - background_mean(NX_FLOAT): - exists: ['min', '1'] - doc: | - The mean background under the reflection peak - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - int_prf(NX_FLOAT): - exists: ['min', '0'] - doc: | - The estimate of the reflection intensity by profile fitting - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - int_prf_var(NX_FLOAT): - exists: ['min', '0'] - doc: | - The variance on the estimate of the reflection intensity by profile - fitting - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - int_prf_errors(NX_FLOAT): - exists: ['min', '0'] - doc: | - The standard deviation of the estimate of the reflection intensity by profile - fitting - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - int_sum(NX_FLOAT): - exists: ['min', '1'] - doc: | - The estimate of the reflection intensity by summation - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - int_sum_var(NX_FLOAT): - exists: ['min', '1'] - doc: | - The variance on the estimate of the reflection intensity by - summation - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - int_sum_errors(NX_FLOAT): - exists: ['min', '1'] - doc: | - The standard deviation of the estimate of the reflection intensity by - summation - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - lp(NX_FLOAT): - exists: ['min', '1'] - doc: | - The LP correction factor to be applied to the reflection intensities - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - prf_cc(NX_FLOAT): - exists: ['min', '0'] - doc: | - The correlation of the reflection profile with the reference profile - used in profile fitting - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - overlaps(NX_INT): - exists: ['min', '0'] - doc: | - An adjacency list specifying the spatial overlaps of reflections. The - adjacency list is specified using an array data type where the elements - of the array are the indices of the adjacent overlapped reflection - \@description: - doc: | - Describes the dataset - polar_angle(NX_FLOAT): - unit: NX_ANGLE - exists: ['min', '0'] - doc: | - Polar angle of reflection centroid, following the NeXus simple (spherical polar) coordinate system - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - azimuthal_angle(NX_FLOAT): - unit: NX_ANGLE - exists: ['min', '0'] - doc: | - Azimuthal angle of reflection centroid, following the NeXus simple (spherical polar) coordinate system - dimensions: - rank: 1 - dim: [[1, n]] - \@description: - doc: | - Describes the dataset - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# c1be9a16c7930b3b315440fe6c27c977d6eae5b972521680ce8ae36e07575548 -# -# -# -# -# -# number of reflections -# number of experiments -# -# Reflection data from diffraction experiments -# -# The experiments from which the reflection data derives -# -# -# -# -# -# -# The h component of the miller index -# -# -# -# -# Describes the dataset -# -# -# -# -# The k component of the miller index -# -# -# -# -# Describes the dataset -# -# -# -# -# The l component of the miller index -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The id of the experiment which resulted in the reflection. If the value -# is greater than 0, the experiments must link to a multi-experiment NXmx -# group -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The id of the reflection. Multiple partials from the same reflection -# should all have the same id -# -# -# -# -# -# Describes the dataset -# -# -# -# Is the reflection entering or exiting the Ewald sphere -# -# -# -# -# Describes the dataset -# -# -# -# -# The detector module on which the reflection was recorded -# -# -# -# -# Describes the dataset -# -# -# -# -# -# Status flags describing the reflection. -# -# This is a bit mask. The bits in the mask follow the convention -# used by DIALS, and have the following names: -# -# === ========================================== -# bit name -# === ========================================== -# 0 ``predicted`` -# 1 ``observed`` -# 2 ``indexed`` -# 3 ``used_in_refinement`` -# 4 ``strong`` -# 5 ``reference_spot`` -# 6 ``dont_integrate`` -# 7 ``integrated_sum`` -# 8 ``integrated_prf`` -# 9 ``integrated`` -# 10 ``overloaded`` -# 11 ``overlapped`` -# 12 ``overlapped_fg`` -# 13 ``in_powder_ring`` -# 14 ``foreground_includes_bad_pixels`` -# 15 ``background_includes_bad_pixels`` -# 16 ``includes_bad_pixels`` -# 17 ``bad_shoebox`` -# 18 ``bad_spot`` -# 19 ``used_in_modelling`` -# 20 ``centroid_outlier`` -# 21 ``failed_during_background_modelling`` -# 22 ``failed_during_summation`` -# 23 ``failed_during_profile_fitting`` -# 24 ``bad_reference`` -# === ========================================== -# -# -# -# -# -# Describes the dataset -# -# -# -# -# The resolution of the reflection -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The partiality of the reflection. -# Dividing by this number will inflate the measured -# intensity to the full reflection equivalent. -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The frame on which the bragg peak of the reflection is predicted -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The x position at which the bragg peak of the reflection -# is predicted -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The y position at which the bragg peak of the reflection -# is predicted -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The phi angle at which the bragg peak of the reflection is predicted -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The x pixel position at which the bragg peak of the reflection is -# predicted -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The y pixel position at which the bragg peak of the reflection is -# predicted -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The estimate of the frame at which the central impact of the -# reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The variance on the estimate of the frame at which the central -# impact of the reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The standard deviation of the estimate of the frame at which the central -# impact of the reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The estimate of the pixel x position at which the central impact of -# the reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The variance on the estimate of the pixel x position at which the -# central impact of the reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The standard deviation of the estimate of the pixel x position at which the -# central impact of the reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The estimate of the pixel y position at which the central impact of -# the reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The variance on the estimate of the pixel y position at which the -# central impact of the reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The standard deviation of the estimate of the pixel y position at which the -# central impact of the reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The estimate of the phi angle at which the central impact of the -# reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The variance on the estimate of the phi angle at which the central -# impact of the reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The standard deviation of the estimate of the phi angle at which the central -# impact of the reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The estimate of the x position at which the central -# impact of the reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The variance on the estimate of the x position at which -# the central impact of the reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The standard deviation of the estimate of the x position at which -# the central impact of the reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The estimate of the y position at which the central -# impact of the reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The variance on the estimate of the y position at which -# the central impact of the reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The standard deviation of the estimate of the y position at which -# the central impact of the reflection was recorded -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The bounding box around the recorded recorded reflection. -# Should be an integer array of length 6, where the 6 values -# are pixel positions or frame numbers, as follows: -# -# ===== =========================== -# index meaning -# ===== =========================== -# 0 The lower pixel x position -# 1 The upper pixel x position -# 2 The lower pixel y position -# 3 The upper pixel y position -# 4 The lower frame number -# 5 The upper frame number -# ===== =========================== -# -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The mean background under the reflection peak -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The estimate of the reflection intensity by profile fitting -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The variance on the estimate of the reflection intensity by profile -# fitting -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The standard deviation of the estimate of the reflection intensity by profile -# fitting -# -# -# -# -# -# Describes the dataset -# -# -# -# The estimate of the reflection intensity by summation -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The variance on the estimate of the reflection intensity by -# summation -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The standard deviation of the estimate of the reflection intensity by -# summation -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The LP correction factor to be applied to the reflection intensities -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# The correlation of the reflection profile with the reference profile -# used in profile fitting -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# An adjacency list specifying the spatial overlaps of reflections. The -# adjacency list is specified using an array data type where the elements -# of the array are the indices of the adjacent overlapped reflection -# -# -# Describes the dataset -# -# -# -# -# -# Polar angle of reflection centroid, following the NeXus simple (spherical polar) coordinate system -# -# -# -# -# -# Describes the dataset -# -# -# -# -# -# Azimuthal angle of reflection centroid, following the NeXus simple (spherical polar) coordinate system -# -# -# -# -# -# -# Describes the dataset -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# diff --git a/base_classes/nyaml/NXroot.yaml b/base_classes/nyaml/NXroot.yaml deleted file mode 100644 index 5305e62bfa..0000000000 --- a/base_classes/nyaml/NXroot.yaml +++ /dev/null @@ -1,223 +0,0 @@ -category: base -doc: | - Definition of the root NeXus group. -type: group -NXroot(NXobject): - \@NX_class: - doc: | - The root of any NeXus data file is an ``NXroot`` class - (no other choice is allowed for a valid NeXus data file). - This attribute cements that definition. - enumeration: [NXroot] - \@file_time: - type: NX_DATE_TIME - doc: | - Date and time file was originally created - \@file_name: - doc: | - File name of original NeXus file - \@file_update_time: - type: NX_DATE_TIME - doc: | - Date and time of last file change at close - \@NeXus_repository: - doc: | - A repository containing the application definitions - used for creating this file. - If the NeXus_version attribute contains a commit distance and hash - this should refer to this repository. - \@NeXus_version: - doc: | - Version of NeXus definitions used in writing the file. - This may either be a date based version tag of the form `vYYYY.MM` - or a version tag with a commit distance and source control (e.g., git) hash of - the form `vYYYY.MM.post1.dev.g`. - It may contain an additional `.dYYYYMMDD` timestamp appendix - for dirty repositories. - If the version contains a commit distance and hash the - NeXus_repository attribute should be written with the - repository url containing this version. - - Only used when the NAPI or pynxtools has written the file. - Note that this is different from the version of the - base class or application definition version number. - \@partial: - doc: | - A list of concepts in an application definition this file describes. - This is for partially filling an application definition. - If this attribute is not present the application definition is assumed - to be valid, if not only the specified concepts/paths are assumed to be valid. - \@HDF_version: - doc: | - Version of HDF (version 4) library used in writing the file - \@HDF5_Version: - doc: | - Version of HDF5 library used in writing the file. - - Note this attribute is spelled with uppercase "V", - different than other version attributes. - \@XML_version: - doc: | - Version of XML support library used in writing the XML file - \@h5py_version: - doc: | - Version of h5py Python package used in writing the file - \@creator: - doc: | - facility or program where file originated - \@creator_version: - doc: | - Version of facility or program used in writing the file - (NXentry): - exists: ['min', '1'] - doc: | - entries - \@default: - doc: | - .. index:: find the default plottable data - .. index:: plotting - .. index:: default attribute value - - Declares which :ref:`NXentry` group contains - the data to be shown by default. - It is used to resolve ambiguity when - more than one :ref:`NXentry` group exists. - The value :ref:`names ` the default :ref:`NXentry` group. The - value must be the name of a child of the current group. The child must be a - NeXus group or a link to a NeXus group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# ab1e1a878a8283f6d94273d270ae61e3ef35ac35060c6c730b71ced5fff6a84d -# -# -# -# -# Definition of the root NeXus group. -# -# -# The root of any NeXus data file is an ``NXroot`` class -# (no other choice is allowed for a valid NeXus data file). -# This attribute cements that definition. -# -# -# -# -# -# -# Date and time file was originally created -# -# -# File name of original NeXus file -# -# -# Date and time of last file change at close -# -# -# -# A repository containing the application definitions -# used for creating this file. -# If the NeXus_version attribute contains a commit distance and hash -# this should refer to this repository. -# -# -# -# -# Version of NeXus definitions used in writing the file. -# This may either be a date based version tag of the form `vYYYY.MM` -# or a version tag with a commit distance and source control (e.g., git) hash of -# the form `vYYYY.MM.post1.dev<commit-distance>.g<git-hash>`. -# It may contain an additional `.dYYYYMMDD` timestamp appendix -# for dirty repositories. -# If the version contains a commit distance and hash the -# NeXus_repository attribute should be written with the -# repository url containing this version. -# -# Only used when the NAPI or pynxtools has written the file. -# Note that this is different from the version of the -# base class or application definition version number. -# -# -# -# -# A list of concepts in an application definition this file describes. -# This is for partially filling an application definition. -# If this attribute is not present the application definition is assumed -# to be valid, if not only the specified concepts/paths are assumed to be valid. -# -# -# -# Version of HDF (version 4) library used in writing the file -# -# -# -# Version of HDF5 library used in writing the file. -# -# Note this attribute is spelled with uppercase "V", -# different than other version attributes. -# -# -# -# Version of XML support library used in writing the XML file -# -# -# Version of h5py Python package used in writing the file -# -# -# facility or program where file originated -# -# -# Version of facility or program used in writing the file -# -# -# entries -# -# -# -# .. index:: find the default plottable data -# .. index:: plotting -# .. index:: default attribute value -# -# Declares which :ref:`NXentry` group contains -# the data to be shown by default. -# It is used to resolve ambiguity when -# more than one :ref:`NXentry` group exists. -# The value :ref:`names <validItemName>` the default :ref:`NXentry` group. The -# value must be the name of a child of the current group. The child must be a -# NeXus group or a link to a NeXus group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# \ No newline at end of file diff --git a/base_classes/nyaml/NXsample.yaml b/base_classes/nyaml/NXsample.yaml deleted file mode 100644 index 385a4a68ae..0000000000 --- a/base_classes/nyaml/NXsample.yaml +++ /dev/null @@ -1,856 +0,0 @@ -category: base -doc: | - 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. -symbols: - doc: | - symbolic array lengths to be coordinated between various fields - n_comp: | - number of compositions - n_Temp: | - number of temperatures - n_eField: | - number of values in applied electric field - n_mField: | - number of values in applied magnetic field - n_pField: | - number of values in applied pressure field - n_sField: | - number of values in applied stress field -type: group -NXsample(NXobject): - name: - doc: | - Descriptive name of sample - sample_id: - doc: | - Identification number or signatures of the sample used. - chemical_formula: - doc: | - 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. - temperature(NX_FLOAT): - unit: NX_TEMPERATURE - doc: | - Sample temperature. This could be a scanned variable - dimensions: - rank: anyRank - - # could be any length - dim: [[1, n_Temp]] - electric_field(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - Applied electric field - dimensions: - - # could be any length - dim: [[1, n_eField]] - \@direction: - enumeration: [x, y, z] - magnetic_field(NX_FLOAT): - unit: NX_ANY - doc: | - Applied magnetic field - dimensions: - - # could be any length - dim: [[1, n_mField]] - \@direction: - enumeration: [x, y, z] - stress_field(NX_FLOAT): - unit: NX_ANY - doc: | - Applied external stress field - dimensions: - - # could be any length - dim: [[1, n_sField]] - \@direction: - enumeration: [x, y, z] - pressure(NX_FLOAT): - unit: NX_PRESSURE - doc: | - Applied pressure - dimensions: - - # could be any length - dim: [[1, n_pField]] - changer_position(NX_INT): - unit: NX_UNITLESS - doc: | - Sample changer position - unit_cell_abc(NX_FLOAT): - unit: NX_LENGTH - doc: | - Crystallography unit cell parameters a, b, and c - dimensions: - dim: [[1, 3]] - unit_cell_alphabetagamma(NX_FLOAT): - unit: NX_ANGLE - doc: | - Crystallography unit cell parameters alpha, beta, and gamma - dimensions: - dim: [[1, 3]] - unit_cell(NX_FLOAT): - unit: NX_LENGTH - doc: | - Unit cell parameters (lengths and angles) - dimensions: - rank: 2 - dim: [[1, n_comp], [2, 6]] - unit_cell_volume(NX_FLOAT): - unit: NX_VOLUME - doc: | - Volume of the unit cell - dimensions: - rank: 1 - dim: [[1, n_comp]] - sample_orientation(NX_FLOAT): - unit: NX_ANGLE - doc: | - This will follow the Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - dimensions: - rank: 1 - dim: [[1, 3]] - orientation_matrix(NX_FLOAT): - doc: | - Orientation matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - dimensions: - rank: 3 - dim: [[1, n_comp], [2, 3], [3, 3]] - ub_matrix(NX_FLOAT): - doc: | - UB matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is - the multiplication of the orientation_matrix, given above, - with the :math:`B` matrix which - can be derived from the lattice constants. - dimensions: - rank: 3 - dim: [[1, n_comp], [2, 3], [3, 3]] - mass(NX_FLOAT): - unit: NX_MASS - doc: | - Mass of sample - dimensions: - rank: 1 - dim: [[1, n_comp]] - density(NX_FLOAT): - unit: NX_MASS_DENSITY - doc: | - Density of sample - dimensions: - rank: 1 - dim: [[1, n_comp]] - relative_molecular_mass(NX_FLOAT): - unit: NX_MASS - doc: | - Relative Molecular Mass of sample - dimensions: - rank: 1 - dim: [[1, n_comp]] - type: - enumeration: [sample, sample+can, can, sample+buffer, buffer, calibration sample, normalisation sample, simulated data, none, sample environment] - situation: - doc: | - 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. - enumeration: [air, vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere, sealed can, other] - description: - doc: | - Description of the sample - preparation_date(NX_DATE_TIME): - doc: | - Date of preparation of the sample - geometry(NXgeometry): - deprecated: | - Use the field `depends_on` and :ref:`NXtransformations` to position the sample and NXoff_geometry to describe its shape instead - doc: | - The position and orientation of the center of mass of the sample - (NXbeam): - doc: | - Details of beam incident on sample - used to calculate sample/beam interaction point - (NXsample_component): - doc: | - One group per sample component - This is the perferred way of recording per component information over the n_comp arrays - component: - doc: | - Details of the component of the sample and/or can - dimensions: - rank: 1 - dim: [[1, n_comp]] - sample_component: - doc: | - Type of component - dimensions: - rank: 1 - dim: [[1, n_comp]] - enumeration: [sample, can, atmosphere, kit] - concentration(NX_FLOAT): - unit: NX_MASS_DENSITY - doc: | - Concentration of each component - dimensions: - rank: 1 - dim: [[1, n_comp]] - volume_fraction(NX_FLOAT): - doc: | - Volume fraction of each component - dimensions: - rank: 1 - dim: [[1, n_comp]] - scattering_length_density(NX_FLOAT): - unit: NX_SCATTERING_LENGTH_DENSITY - doc: | - Scattering length density of each component - dimensions: - rank: 1 - dim: [[1, n_comp]] - unit_cell_class: - doc: | - In case it is all we know and we want to record/document it - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - space_group: - doc: | - Crystallographic space group - dimensions: - dim: [[1, n_comp]] - point_group: - doc: | - Crystallographic point group, deprecated if space_group present - dimensions: - dim: [[1, n_comp]] - path_length(NX_FLOAT): - unit: NX_LENGTH - doc: | - Path length through sample/can for simple case when - it does not vary with scattering direction - path_length_window(NX_FLOAT): - unit: NX_LENGTH - doc: | - Thickness of a beam entry/exit window on the can (mm) - - assumed same for entry and exit - thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - sample thickness - transmission(NXdata): - doc: | - As a function of Wavelength - temperature_log(NXlog): - deprecated: | - use ``temperature``, see: https://github.com/nexusformat/definitions/issues/816 - doc: | - temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value - temperature_env(NXenvironment): - doc: | - Additional sample temperature environment information - magnetic_field(NXlog): - doc: | - magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value - magnetic_field_log(NXlog): - deprecated: | - use ``magnetic_field``, see: https://github.com/nexusformat/definitions/issues/816 - doc: | - magnetic_field_log.value is a link to e.g. magnetic_field_env.sensor1.value_log.value - magnetic_field_env(NXenvironment): - doc: | - Additional sample magnetic environment information - external_DAC(NX_FLOAT): - unit: NX_ANY - doc: | - value sent to user's sample setup - external_ADC(NXlog): - doc: | - logged value (or logic state) read from user's setup - short_title: - doc: | - 20 character fixed length sample description for legends - - # How is the string length limitation imposed by the XSD? - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Optional rotation angle for the case when the powder diagram has - been obtained through an omega-2theta scan like from a traditional - single detector powder diffractometer. - Note, it is recommended to use NXtransformations instead. - x_translation(NX_FLOAT): - unit: NX_LENGTH - doc: | - Translation of the sample along the X-direction of the laboratory coordinate system - Note, it is recommended to use NXtransformations instead. - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Translation of the sample along the Z-direction of the laboratory coordinate system. - Note, it is recommended to use NXtransformations instead. - (NXpositioner): - doc: | - Any positioner (motor, PZT, ...) used to locate the sample - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the sample - physical_form: - doc: | - Physical form of the sample material. - Examples include single crystal, foil, pellet, powder, thin film, disc, foam, gas, liquid, amorphous. - (NXsingle_crystal): - doc: | - If the sample is a single crystal, add description of single crystal and unit - cell. - (NXsample_component_set): - doc: | - Set of sample components and their configuration. - There can only be one NXsample_component_set in one component. - - # exists: [max, 1] - (NXsubstance): - doc: | - If the sample is made from a pure substance and cannot be further divided using - NXsample_component. - - # exists: [max, 1] - (NXfabrication): - doc: | - Details about the sample vendor (company or research group) - identifier(NXidentifier): - doc: | - An (ideally) globally unique identifier for the sample. - (NXenvironment): - - # eventually, this should be stored in the application definitions - doc: | - Any environmental or external stimuli/measurements. - These can include, among others: - applied pressure, surrounding gas phase and gas pressure, - external electric/magnetic/mechanical fields, temperature, ... - history(NXhistory): - doc: | - A set of physical processes that occurred to the sample prior/during experiment. - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - 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. - (NXtransformations): - doc: | - 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 75b499ae75ff895a3902ff0f84852bd9acea5d27a2b607880ebf54d9c1f38ca7 -# -# -# -# -# -# -# symbolic array lengths to be coordinated between various fields -# number of compositions -# number of temperatures -# number of values in applied electric field -# number of values in applied magnetic field -# number of values in applied pressure field -# number of values in applied stress field -# -# -# -# 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. -# -# -# Descriptive name of sample -# -# -# Identification number or signatures of the sample used. -# -# -# -# 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. -# -# -# -# Sample temperature. This could be a scanned variable -# -# -# -# -# -# Applied electric field -# -# -# -# -# -# -# -# -# -# -# -# -# Applied magnetic field -# -# -# -# -# -# -# -# -# -# -# -# -# Applied external stress field -# -# -# -# -# -# -# -# -# -# -# -# -# Applied pressure -# -# -# -# -# -# Sample changer position -# -# -# Crystallography unit cell parameters a, b, and c -# -# -# -# -# -# Crystallography unit cell parameters alpha, beta, and gamma -# -# -# -# -# -# Unit cell parameters (lengths and angles) -# -# -# -# -# -# -# Volume of the unit cell -# -# -# -# -# -# -# This will follow the Busing-Levy convention: -# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 -# -# -# -# -# -# -# -# Orientation matrix of single crystal sample using Busing-Levy convention: -# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 -# -# -# -# -# -# -# -# -# -# UB matrix of single crystal sample using Busing-Levy convention: -# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is -# the multiplication of the orientation_matrix, given above, -# with the :math:`B` matrix which -# can be derived from the lattice constants. -# -# -# -# -# -# -# -# -# Mass of sample -# -# -# -# -# -# Density of sample -# -# -# -# -# -# Relative Molecular Mass of sample -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# 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. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Description of the sample -# -# -# -# Date of preparation of the sample -# -# -# The position and orientation of the center of mass of the sample -# -# -# Details of beam incident on sample - used to calculate sample/beam interaction point -# -# -# -# One group per sample component -# This is the perferred way of recording per component information over the n_comp arrays -# -# -# -# Details of the component of the sample and/or can -# -# -# -# -# -# Type of component -# -# -# -# -# -# -# -# -# -# -# -# Concentration of each component -# -# -# -# -# -# Volume fraction of each component -# -# -# -# -# -# Scattering length density of each component -# -# -# -# -# -# -# In case it is all we know and we want to record/document it -# -# -# -# -# -# -# -# -# -# -# -# -# Crystallographic space group -# -# -# -# -# -# Crystallographic point group, deprecated if space_group present -# -# -# -# -# -# -# Path length through sample/can for simple case when -# it does not vary with scattering direction -# -# -# -# -# Thickness of a beam entry/exit window on the can (mm) -# - assumed same for entry and exit -# -# -# -# sample thickness -# -# -# As a function of Wavelength -# -# -# temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value -# -# -# Additional sample temperature environment information -# -# -# magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value -# -# -# magnetic_field_log.value is a link to e.g. magnetic_field_env.sensor1.value_log.value -# -# -# Additional sample magnetic environment information -# -# -# value sent to user's sample setup -# -# -# logged value (or logic state) read from user's setup -# -# -# 20 character fixed length sample description for legends -# -# -# -# -# Optional rotation angle for the case when the powder diagram has -# been obtained through an omega-2theta scan like from a traditional -# single detector powder diffractometer. -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# Translation of the sample along the X-direction of the laboratory coordinate system -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# Translation of the sample along the Z-direction of the laboratory coordinate system. -# Note, it is recommended to use NXtransformations instead. -# -# -# -# Any positioner (motor, PZT, ...) used to locate the sample -# -# -# -# This group describes the shape of the sample -# -# -# -# -# Physical form of the sample material. -# Examples include single crystal, foil, pellet, powder, thin film, disc, foam, gas, liquid, amorphous. -# -# -# -# -# If the sample is a single crystal, add description of single crystal and unit -# cell. -# -# -# -# -# Set of sample components and their configuration. -# There can only be one NXsample_component_set in one component. -# -# -# -# -# -# If the sample is made from a pure substance and cannot be further divided using -# NXsample_component. -# -# -# -# -# -# Details about the sample vendor (company or research group) -# -# -# -# -# An (ideally) globally unique identifier for the sample. -# -# -# -# -# -# Any environmental or external stimuli/measurements. -# These can include, among others: -# applied pressure, surrounding gas phase and gas pressure, -# external electric/magnetic/mechanical fields, temperature, ... -# -# -# -# -# A set of physical processes that occurred to the sample prior/during experiment. -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# diff --git a/base_classes/nyaml/NXsample_component.yaml b/base_classes/nyaml/NXsample_component.yaml deleted file mode 100644 index 803366d140..0000000000 --- a/base_classes/nyaml/NXsample_component.yaml +++ /dev/null @@ -1,355 +0,0 @@ -category: base -doc: | - One group like this per component can be recorded for a sample consisting of multiple components. -symbols: - doc: | - symbolic array lengths to be coordinated between various fields - n_Temp: | - number of temperatures - n_eField: | - number of values in applied electric field - n_mField: | - number of values in applied magnetic field - n_pField: | - number of values in applied pressure field - n_sField: | - number of values in applied stress field -type: group -NXsample_component(NXobject): - name: - doc: | - Descriptive name of sample component - sample_id: - doc: | - Identification number or signatures of the sample component used. - chemical_formula: - doc: | - 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. - unit_cell_abc(NX_FLOAT): - unit: NX_LENGTH - doc: | - Crystallography unit cell parameters a, b, and c - dimensions: - dim: [[1, 3]] - unit_cell_alphabetagamma(NX_FLOAT): - unit: NX_ANGLE - doc: | - Crystallography unit cell parameters alpha, beta, and gamma - dimensions: - dim: [[1, 3]] - unit_cell_volume(NX_FLOAT): - unit: NX_VOLUME - doc: | - Volume of the unit cell - sample_orientation(NX_FLOAT): - unit: NX_ANGLE - doc: | - This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) - dimensions: - rank: 1 - dim: [[1, 3]] - orientation_matrix(NX_FLOAT): - doc: | - Orientation matrix of single crystal sample component. - This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) - dimensions: - rank: 2 - dim: [[1, 3], [2, 3]] - mass(NX_FLOAT): - unit: NX_MASS - doc: | - Mass of sample component - density(NX_FLOAT): - unit: NX_MASS_DENSITY - doc: | - Density of sample component - relative_molecular_mass(NX_FLOAT): - unit: NX_MASS - doc: | - Relative Molecular Mass of sample component - description: - doc: | - Description of the sample component - volume_fraction(NX_FLOAT): - doc: | - Volume fraction of component - scattering_length_density(NX_FLOAT): - unit: NX_SCATTERING_LENGTH_DENSITY - doc: | - Scattering length density of component - unit_cell_class: - doc: | - In case it is all we know and we want to record/document it - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - space_group: - doc: | - Crystallographic space group - point_group: - doc: | - Crystallographic point group, deprecated if space_group present - transmission(NXdata): - doc: | - As a function of Wavelength - (NXsingle_crystal): - doc: | - If the component is a single crystal, add description of single crystal and unit - cell. - (NXsample_component_set): - doc: | - Set of sub-components and their configuration. - There can only be one NXsample_component_set in one component. - - # exists: [max, 1] - (NXsubstance): - doc: | - If the component is made from a pure substance and cannot be further divided - using NXsample_component. - - # exists: [max, 1] - (NXfabrication): - doc: | - Details about the sample component vendor (company or research group) - identifier(NXidentifier): - doc: | - An (ideally) globally unique identifier for the sample component. - history(NXhistory): - doc: | - A set of physical processes that occurred to the sample component prior/during - experiment. - depends_on: - doc: | - Any NXsample_component depends on the instance of NXsample_component_set, at the same level of - description granularity where the component is located. - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4ae2b93583186ce2a10567a007ad729f8b5442fb1c2d8051a941745ed9a6bc99 -# -# -# -# -# -# -# symbolic array lengths to be coordinated between various fields -# number of temperatures -# number of values in applied electric field -# number of values in applied magnetic field -# number of values in applied pressure field -# number of values in applied stress field -# -# -# -# One group like this per component can be recorded for a sample consisting of multiple components. -# -# -# Descriptive name of sample component -# -# -# -# Identification number or signatures of the sample component used. -# -# -# -# -# The chemical formula specified using CIF conventions. -# 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. -# -# -# -# Crystallography unit cell parameters a, b, and c -# -# -# -# -# -# Crystallography unit cell parameters alpha, beta, and gamma -# -# -# -# -# -# Volume of the unit cell -# -# -# This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) -# -# -# -# -# -# -# Orientation matrix of single crystal sample component. -# This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) -# -# -# -# -# -# -# -# Mass of sample component -# -# -# Density of sample component -# -# -# Relative Molecular Mass of sample component -# -# -# -# Description of the sample component -# -# -# -# Volume fraction of component -# -# -# Scattering length density of component -# -# -# -# In case it is all we know and we want to record/document it -# -# -# -# -# -# -# -# -# -# -# -# -# Crystallographic space group -# -# -# Crystallographic point group, deprecated if space_group present -# -# -# As a function of Wavelength -# -# -# -# If the component is a single crystal, add description of single crystal and unit -# cell. -# -# -# -# -# Set of sub-components and their configuration. -# There can only be one NXsample_component_set in one component. -# -# -# -# -# -# If the component is made from a pure substance and cannot be further divided -# using NXsample_component. -# -# -# -# -# -# Details about the sample component vendor (company or research group) -# -# -# -# -# An (ideally) globally unique identifier for the sample component. -# -# -# -# -# A set of physical processes that occurred to the sample component prior/during -# experiment. -# -# -# -# -# Any NXsample_component depends on the instance of NXsample_component_set, at the same level of -# description granularity where the component is located. -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# \ No newline at end of file diff --git a/base_classes/nyaml/NXsensor.yaml b/base_classes/nyaml/NXsensor.yaml deleted file mode 100644 index f3159ced7d..0000000000 --- a/base_classes/nyaml/NXsensor.yaml +++ /dev/null @@ -1,325 +0,0 @@ -category: base -doc: | - A sensor used to monitor an external condition - - The condition itself is described in :ref:`NXenvironment`. -type: group -NXsensor(NXobject): - model: - doc: | - Sensor identification code/model number - name: - doc: | - Name for the sensor - short_name: - doc: | - Short name of sensor used e.g. on monitor display program - attached_to: - doc: | - where sensor is attached to ("sample" | "can") - geometry(NXgeometry): - deprecated: | - Use the field `depends_on` and :ref:`NXtransformations` to position the beamstop and NXoff_geometry to describe its shape instead - doc: | - Defines the axes for logged vector quantities if they are not the global instrument axes. - measurement: - doc: | - name for measured signal - enumeration: [temperature, pH, magnetic_field, electric_field, current, conductivity, resistance, voltage, pressure, flow, stress, strain, shear, surface_pressure] - type: - doc: | - The type of hardware used for the measurement. - Examples (suggestions but not restrictions): - - :Temperature: - J | K | T | E | R | S | Pt100 | Rh/Fe - :pH: - Hg/Hg2Cl2 | Ag/AgCl | ISFET - :Ion selective electrode: - specify species; e.g. Ca2+ - :Magnetic field: - Hall - :Surface pressure: - wilhelmy plate - run_control(NX_BOOLEAN): - doc: | - Is data collection controlled or synchronised to this quantity: - 1=no, 0=to "value", 1=to "value_deriv1", etc. - high_trip_value(NX_FLOAT): - unit: NX_ANY - doc: | - Upper control bound of sensor reading if using run_control - low_trip_value(NX_FLOAT): - unit: NX_ANY - doc: | - Lower control bound of sensor reading if using run_control - value(NX_FLOAT): - unit: NX_ANY - doc: | - nominal setpoint or average value - - need [n] as may be a vector - dimensions: - dim: [[1, n]] - value_deriv1(NX_FLOAT): - unit: NX_ANY - doc: | - Nominal/average first derivative of value - e.g. strain rate - - same dimensions as "value" (may be a vector) - dimensions: - dim: [[1, ]] - dim_parameters: - ref: ['value'] - value_deriv2(NX_FLOAT): - unit: NX_ANY - doc: | - Nominal/average second derivative of value - - same dimensions as "value" (may be a vector) - dimensions: - dim: [[1, ]] - dim_parameters: - ref: ['value'] - value_log(NXlog): - doc: | - Time history of sensor readings - value_deriv1_log(NXlog): - doc: | - Time history of first derivative of sensor readings - value_deriv2_log(NXlog): - doc: | - Time history of second derivative of sensor readings - external_field_brief: - enumeration: [along beam, across beam, transverse, solenoidal, flow shear gradient, flow vorticity] - external_field_full(NXorientation): - doc: | - For complex external fields not satisfied by External_field_brief - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the sensor when necessary. - (NXfabrication): - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a sensor. - (NXtransformations): - doc: | - 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 784fc1e5cc5954136412e7aa2fc149bf1be1f61cd6a9a5d52863eb85c51ad100 -# -# -# -# -# -# A sensor used to monitor an external condition -# -# The condition itself is described in :ref:`NXenvironment`. -# -# -# Sensor identification code/model number -# -# -# Name for the sensor -# -# -# Short name of sensor used e.g. on monitor display program -# -# -# where sensor is attached to ("sample" | "can") -# -# -# -# Defines the axes for logged vector quantities if they are not the global instrument axes. -# -# -# -# name for measured signal -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The type of hardware used for the measurement. -# Examples (suggestions but not restrictions): -# -# :Temperature: -# J | K | T | E | R | S | Pt100 | Rh/Fe -# :pH: -# Hg/Hg2Cl2 | Ag/AgCl | ISFET -# :Ion selective electrode: -# specify species; e.g. Ca2+ -# :Magnetic field: -# Hall -# :Surface pressure: -# wilhelmy plate -# -# -# -# -# Is data collection controlled or synchronised to this quantity: -# 1=no, 0=to "value", 1=to "value_deriv1", etc. -# -# -# -# -# Upper control bound of sensor reading if using run_control -# -# -# -# -# Lower control bound of sensor reading if using run_control -# -# -# -# -# nominal setpoint or average value -# - need [n] as may be a vector -# -# -# -# -# -# -# -# Nominal/average first derivative of value -# e.g. strain rate -# - same dimensions as "value" (may be a vector) -# -# -# -# -# -# -# -# Nominal/average second derivative of value -# - same dimensions as "value" (may be a vector) -# -# -# -# -# -# -# Time history of sensor readings -# -# -# Time history of first derivative of sensor readings -# -# -# Time history of second derivative of sensor readings -# -# -# -# -# -# -# -# -# -# -# -# -# For complex external fields not satisfied by External_field_brief -# -# -# -# This group describes the shape of the sensor when necessary. -# -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a sensor. -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# diff --git a/base_classes/nyaml/NXshape.yaml b/base_classes/nyaml/NXshape.yaml deleted file mode 100644 index 75a7c225b5..0000000000 --- a/base_classes/nyaml/NXshape.yaml +++ /dev/null @@ -1,143 +0,0 @@ -category: base -doc: | - legacy class - (used by :ref:`NXgeometry`) - the shape and size of a component. - - This is the description of the general shape and size of a - component, which may be made up of ``numobj`` separate - elements - it is used by the :ref:`NXgeometry` class -type: group -NXshape(NXobject): - shape: - doc: | - general shape of a component - enumeration: [nxflat, nxcylinder, nxbox, nxsphere, nxcone, nxelliptical, nxtoroidal, nxparabolic, nxpolynomial] - size(NX_FLOAT): - unit: NX_LENGTH - doc: | - physical extent of the object along its local axes (after NXorientation) - with the center of mass at the local origin (after NXtranslation). - The meaning and location of these axes will vary according to the value - of the "shape" variable. - ``nshapepar`` defines how many parameters: - - - For "nxcylinder" type the parameters are (diameter,height) and a three value orientation vector of the cylinder. - - For the "nxbox" type the parameters are (length,width,height). - - For the "nxsphere" type the parameters are (diameter). - - For nxcone cone half aperture - - For nxelliptical, semi-major axis, semi-minor-axis, angle of major axis and pole - - For nxtoroidal, major radius, minor radius - - For nxparabolic, parabolic parameter a - - For nxpolynomial, an array of polynom coefficients, the dimension of the array - encodes the degree of the polynom - dimensions: - dim: [[1, numobj], [2, nshapepar]] - direction: - enumeration: [concave, convex] - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 238f4920fd13dd1d4d927145c16ecb32e1971155e6f67374793ea85a24b97719 -# -# -# -# -# -# legacy class - (used by :ref:`NXgeometry`) - the shape and size of a component. -# -# This is the description of the general shape and size of a -# component, which may be made up of ``numobj`` separate -# elements - it is used by the :ref:`NXgeometry` class -# -# -# general shape of a component -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# physical extent of the object along its local axes (after NXorientation) -# with the center of mass at the local origin (after NXtranslation). -# The meaning and location of these axes will vary according to the value -# of the "shape" variable. -# ``nshapepar`` defines how many parameters: -# -# - For "nxcylinder" type the parameters are (diameter,height) and a three value orientation vector of the cylinder. -# - For the "nxbox" type the parameters are (length,width,height). -# - For the "nxsphere" type the parameters are (diameter). -# - For nxcone cone half aperture -# - For nxelliptical, semi-major axis, semi-minor-axis, angle of major axis and pole -# - For nxtoroidal, major radius, minor radius -# - For nxparabolic, parabolic parameter a -# - For nxpolynomial, an array of polynom coefficients, the dimension of the array -# encodes the degree of the polynom -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# diff --git a/base_classes/nyaml/NXslit.yaml b/base_classes/nyaml/NXslit.yaml deleted file mode 100644 index f34c83300c..0000000000 --- a/base_classes/nyaml/NXslit.yaml +++ /dev/null @@ -1,141 +0,0 @@ -category: base -doc: | - A simple slit. - - For more complex geometries, :ref:`NXaperture` should be used. -type: group -NXslit(NXobject): - depends_on(NX_CHAR): - doc: | - Points to the path of the last element in the geometry chain that places - this object in space. - When followed through that chain is supposed to end at an element depending - on "." i.e. the origin of the coordinate system. - If desired the location of the slit can also be described relative to - an NXbeam, which will allow a simple description of a non-centred slit. - - The reference plane of the slit is orthogonal to the z axis and includes the - surface that is the entry surface of the slit. The reference point of the slit - is the centre of the slit opening in the x and y axis on the reference plane. - The reference point on the z axis is the reference plane. - - .. image:: slit/slit.png - :width: 40% - x_gap(NX_NUMBER): - unit: NX_LENGTH - doc: | - Size of the gap opening in the first dimension of the local - coordinate system. - y_gap(NX_NUMBER): - unit: NX_LENGTH - doc: | - Size of the gap opening in the second dimension of the local - coordinate system. - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - (NXtransformations): - doc: | - 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d2cb79154570b9b1299f900a1fc71b7a8b9c2a19f25234ec09a56692d9536d92 -# -# -# -# -# -# A simple slit. -# -# For more complex geometries, :ref:`NXaperture` should be used. -# -# -# -# Points to the path of the last element in the geometry chain that places -# this object in space. -# When followed through that chain is supposed to end at an element depending -# on "." i.e. the origin of the coordinate system. -# If desired the location of the slit can also be described relative to -# an NXbeam, which will allow a simple description of a non-centred slit. -# -# The reference plane of the slit is orthogonal to the z axis and includes the -# surface that is the entry surface of the slit. The reference point of the slit -# is the centre of the slit opening in the x and y axis on the reference plane. -# The reference point on the z axis is the reference plane. -# -# .. image:: slit/slit.png -# :width: 40% -# -# -# -# -# -# Size of the gap opening in the first dimension of the local -# coordinate system. -# -# -# -# -# Size of the gap opening in the second dimension of the local -# coordinate system. -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# diff --git a/base_classes/nyaml/NXsource.yaml b/base_classes/nyaml/NXsource.yaml deleted file mode 100644 index 7c8886d9c6..0000000000 --- a/base_classes/nyaml/NXsource.yaml +++ /dev/null @@ -1,495 +0,0 @@ -category: base -doc: | - Radiation source emitting a beam. - - Examples include particle sources (electrons, neutrons, protons) or sources for electromagnetic radiation (photons). - This base class can also be used to describe neutron or x-ray storage ring/facilities. -type: group -NXsource(NXobject): - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Effective distance from sample - Distance as seen by radiation from sample. This number should be negative - to signify that it is upstream of the sample. - name: - doc: | - Name of source - \@short_name: - doc: | - short name for source, perhaps the acronym - type: - doc: | - type of radiation source (pick one from the enumerated list and spell exactly) - enumeration: [Spallation Neutron Source, Pulsed Reactor Neutron Source, Reactor Neutron Source, Synchrotron X-ray Source, Pulsed Muon Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, Ion Source, UV Plasma Source, Metal Jet X-ray] - probe: - doc: | - type of radiation probe (pick one from the enumerated list and spell exactly) - enumeration: [neutron, photon, x-ray, muon, electron, ultraviolet, visible light, positron, proton] - power(NX_FLOAT): - unit: NX_POWER - doc: | - Source power - emittance_x(NX_FLOAT): - unit: NX_EMITTANCE - doc: | - Source emittance (nm-rad) in X (horizontal) direction. - emittance_y(NX_FLOAT): - unit: NX_EMITTANCE - doc: | - Source emittance (nm-rad) in Y (horizontal) direction. - sigma_x(NX_FLOAT): - unit: NX_LENGTH - doc: | - particle beam size in x - sigma_y(NX_FLOAT): - unit: NX_LENGTH - doc: | - particle beam size in y - flux(NX_FLOAT): - unit: NX_FLUX - doc: | - Source intensity/area (example: s-1 cm-2) - energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - Source energy. Typically, this would be the energy of - the emitted beam. For storage rings, this would be - the particle beam energy. - current(NX_FLOAT): - unit: NX_CURRENT - doc: | - Accelerator, X-ray tube, or storage ring current - voltage(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - Accelerator voltage - frequency(NX_FLOAT): - unit: NX_FREQUENCY - doc: | - Frequency of pulsed source - period(NX_FLOAT): - unit: NX_PERIOD - doc: | - Period of pulsed source - target_material: - doc: | - Pulsed source target material - enumeration: [Ta, W, depleted_U, enriched_U, Hg, Pb, C] - notes(NXnote): - doc: | - any source/facility related messages/events that - occurred during the experiment - bunch_pattern(NXdata): - doc: | - For storage rings, description of the bunch pattern. - This is useful to describe irregular bunch patterns. - title: - doc: | - name of the bunch pattern - number_of_bunches(NX_INT): - doc: | - For storage rings, the number of bunches in use. - bunch_length(NX_FLOAT): - unit: NX_TIME - doc: | - For storage rings, temporal length of the bunch - bunch_distance(NX_FLOAT): - unit: NX_TIME - doc: | - For storage rings, time between bunches - pulse_width(NX_FLOAT): - unit: NX_TIME - doc: | - temporal width of source pulse - - # pulsed sources or storage rings could use this - pulse_shape(NXdata): - doc: | - source pulse shape - - # pulsed sources or storage rings could use this - mode: - doc: | - source operating mode - enumeration: - Single Bunch: - doc: | - for storage rings - Multi Bunch: - doc: | - for storage rings - - # other sources could add to this - - # other sources could add to this - top_up(NX_BOOLEAN): - doc: | - Is the synchrotron operating in top_up mode? - last_fill(NX_NUMBER): - unit: NX_CURRENT - doc: | - For storage rings, the current at the end of the most recent injection. - \@time: - type: NX_DATE_TIME - doc: | - date and time of the most recent injection. - wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - The wavelength of the radiation emitted by the source. - pulse_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - For pulsed sources, the energy of a single pulse. - peak_power(NX_FLOAT): - unit: NX_POWER - doc: | - For pulsed sources, the pulse energy divided - by the pulse duration - anode_material: - doc: | - Material of the anode (for X-ray tubes). - filament_current(NX_FLOAT): - unit: NX_CURRENT - doc: | - Filament current (for X-ray tubes). - emission_current(NX_FLOAT): - unit: NX_CURRENT - doc: | - Emission current of the generated beam. - gas_pressure(NX_FLOAT): - unit: NX_PRESSURE - doc: | - Gas pressure inside ionization source. - geometry(NXgeometry): - deprecated: | - Use the field `depends_on` and :ref:`NXtransformations` to position the source and NXoff_geometry to describe its shape instead - doc: | - "Engineering" location of source. - (NXaperture): - doc: | - The size and position of an aperture inside the source. - (NXdeflector): - doc: | - Deflectors inside the source. - (NXlens_em): - doc: | - Individual electromagnetic lenses inside the source. - (NXfabrication): - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the beam line component - (NXdata)distribution: - doc: | - The wavelength or energy distribution of the source - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the - z axis. - - .. image:: source/source.png - :width: 40% - (NXtransformations): - doc: | - 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# edccdd67915ffe14c9ecf03d1a5d57cacb6522a3a62b0f4882cc01bc43ee4f52 -# -# -# -# -# -# Radiation source emitting a beam. -# -# Examples include particle sources (electrons, neutrons, protons) or sources for electromagnetic radiation (photons). -# This base class can also be used to describe neutron or x-ray storage ring/facilities. -# -# -# -# Effective distance from sample -# Distance as seen by radiation from sample. This number should be negative -# to signify that it is upstream of the sample. -# -# -# -# Name of source -# -# short name for source, perhaps the acronym -# -# -# -# type of radiation source (pick one from the enumerated list and spell exactly) -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# type of radiation probe (pick one from the enumerated list and spell exactly) -# -# -# -# -# -# -# -# -# -# -# -# -# -# Source power -# -# -# Source emittance (nm-rad) in X (horizontal) direction. -# -# -# Source emittance (nm-rad) in Y (horizontal) direction. -# -# -# particle beam size in x -# -# -# particle beam size in y -# -# -# Source intensity/area (example: s-1 cm-2) -# -# -# -# Source energy. Typically, this would be the energy of -# the emitted beam. For storage rings, this would be -# the particle beam energy. -# -# -# -# Accelerator, X-ray tube, or storage ring current -# -# -# Accelerator voltage -# -# -# Frequency of pulsed source -# -# -# Period of pulsed source -# -# -# Pulsed source target material -# -# -# -# -# -# -# -# -# -# -# -# -# any source/facility related messages/events that -# occurred during the experiment -# -# -# -# -# For storage rings, description of the bunch pattern. -# This is useful to describe irregular bunch patterns. -# -# name of the bunch pattern -# -# -# For storage rings, the number of bunches in use. -# -# -# For storage rings, temporal length of the bunch -# -# -# For storage rings, time between bunches -# -# -# temporal width of source pulse -# -# -# source pulse shape -# -# -# source operating mode -# -# for storage rings -# for storage rings -# -# -# -# -# Is the synchrotron operating in top_up mode? -# -# -# For storage rings, the current at the end of the most recent injection. -# date and time of the most recent injection. -# -# -# -# The wavelength of the radiation emitted by the source. -# -# -# -# -# For pulsed sources, the energy of a single pulse. -# -# -# -# -# For pulsed sources, the pulse energy divided -# by the pulse duration -# -# -# -# -# Material of the anode (for X-ray tubes). -# -# -# -# -# Filament current (for X-ray tubes). -# -# -# -# -# Emission current of the generated beam. -# -# -# -# -# Gas pressure inside ionization source. -# -# -# -# -# "Engineering" location of source. -# -# -# -# -# The size and position of an aperture inside the source. -# -# -# -# -# Deflectors inside the source. -# -# -# -# -# Individual electromagnetic lenses inside the source. -# -# -# -# -# -# This group describes the shape of the beam line component -# -# -# -# The wavelength or energy distribution of the source -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the -# z axis. -# -# .. image:: source/source.png -# :width: 40% -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# \ No newline at end of file diff --git a/base_classes/nyaml/NXsubentry.yaml b/base_classes/nyaml/NXsubentry.yaml deleted file mode 100644 index ce49877348..0000000000 --- a/base_classes/nyaml/NXsubentry.yaml +++ /dev/null @@ -1,343 +0,0 @@ -category: base -doc: | - Group of multiple application definitions for "multi-modal" (e.g. SAXS/WAXS) measurements. - - ``NXsubentry`` is a base class virtually identical to :ref:`NXentry` - and is used as the (overlay) location for application definitions. - Use a separate ``NXsubentry`` for each application definition. - - To use ``NXsubentry`` with a hypothetical application definition - called ``NXmyappdef``: - - * Create a group with attribute ``NX_class="NXsubentry"`` - * Within that group, create a field called ``definition="NXmyappdef"``. - * There are two optional attributes of definition: ``version`` and ``URL`` - - The intended use is to define application definitions for a - multi-modal (a.k.a. multi-technique) :ref:`NXentry`. - Previously, an application definition - replaced :ref:`NXentry` with its own definition. - With the increasing popularity of instruments combining - multiple techniques for data collection (such as SAXS/WAXS instruments), - it was recognized the application definitions must be entered in the NeXus - data file tree as children of :ref:`NXentry`. -type: group -NXsubentry(NXobject): - \@default: - doc: | - .. 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 ` the default :ref:`NXentry` group. The - value must be the name of a child of the current group. The child must be a - NeXus group or a link to a NeXus group. - - For more information about how NeXus identifies the default - plottable data, see the - :ref:`Find Plottable Data, v3 ` - section. - \@IDF_Version: - - # as ratified at NIAC2010 - doc: | - ISIS Muon IDF_Version - title: - doc: | - Extended title for entry - experiment_identifier(NXidentifier): - doc: | - Unique identifier for the experiment, defined by - the facility, possibly linked to the proposals - experiment_description: - doc: | - Brief summary of the experiment, including key objectives. - (NXnote)experiment_documentation: - doc: | - Description of the full experiment (document in pdf, latex, ...) - collection_identifier(NXidentifier): - doc: | - User or Data Acquisition defined group of NeXus files or :ref:`NXentry` - collection_description: - doc: | - Brief summary of the collection, including grouping criteria. - entry_identifier(NXidentifier): - doc: | - unique identifier for the measurement, defined by the facility. - definition: - doc: | - Official NeXus NXDL schema to which this subentry conforms - \@version: - doc: | - NXDL version number - \@URL: - doc: | - URL of NXDL file - definition_local: - doc: | - Local NXDL schema extended from the subentry - specified in the ``definition`` field. - This contains any locally-defined, - additional fields in the subentry. - \@version: - doc: | - NXDL version number - \@URL: - doc: | - URL of NXDL file - start_time(NX_DATE_TIME): - doc: | - Starting time of measurement - end_time(NX_DATE_TIME): - doc: | - Ending time of measurement - duration(NX_INT): - unit: NX_TIME - doc: | - Duration of measurement - collection_time(NX_FLOAT): - unit: NX_TIME - doc: | - Time transpired actually collecting data i.e. taking out time when collection was - suspended due to e.g. temperature out of range - run_cycle: - doc: | - Such as "2007-3". Some user facilities organize their beam time into run cycles. - program_name: - doc: | - Name of program used to generate this file - \@version: - doc: | - Program version number - \@configuration: - doc: | - configuration of the program - revision: - doc: | - Revision id of the file due to re-calibration, reprocessing, new analysis, new - instrument definition format, ... - \@comment: - pre_sample_flightpath(NX_FLOAT): - unit: NX_LENGTH - doc: | - This is the flightpath before the sample position. This can be determined by a chopper, - by the moderator or the source itself. In other words: it the distance to the component - which gives the T0 signal to the detector electronics. If another component in the - NXinstrument hierarchy provides this information, this should be a link. - notes(NXnote): - doc: | - Notes describing entry - thumbnail(NXnote): - doc: | - A small image that is representative of the entry. An example of this is a 640x480 - jpeg image automatically produced by a low resolution plot of the NXdata. - \@mime_type: - doc: | - The value should be an ``image/*`` - - # This is not perfect. - # How do we set a default value for the mime_type attribute? - enumeration: [image/*] - (NXuser): - (NXsample): - (NXinstrument): - (NXcollection): - (NXmonitor): - (NXdata): - (NXparameters): - (NXprocess): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 237d41832bec5b07f576fdda3791b9810addebf81b0700da0815e1b4fdca0c14 -# -# -# -# -# -# -# -# .. 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 <validItemName>` the default :ref:`NXentry` group. The -# value must be the name of a child of the current group. The child must be a -# NeXus group or a link to a NeXus group. -# -# For more information about how NeXus identifies the default -# plottable data, see the -# :ref:`Find Plottable Data, v3 <Find-Plottable-Data-v3>` -# section. -# -# -# -# -# Group of multiple application definitions for "multi-modal" (e.g. SAXS/WAXS) measurements. -# -# ``NXsubentry`` is a base class virtually identical to :ref:`NXentry` -# and is used as the (overlay) location for application definitions. -# Use a separate ``NXsubentry`` for each application definition. -# -# To use ``NXsubentry`` with a hypothetical application definition -# called ``NXmyappdef``: -# -# * Create a group with attribute ``NX_class="NXsubentry"`` -# * Within that group, create a field called ``definition="NXmyappdef"``. -# * There are two optional attributes of definition: ``version`` and ``URL`` -# -# The intended use is to define application definitions for a -# multi-modal (a.k.a. multi-technique) :ref:`NXentry`. -# Previously, an application definition -# replaced :ref:`NXentry` with its own definition. -# With the increasing popularity of instruments combining -# multiple techniques for data collection (such as SAXS/WAXS instruments), -# it was recognized the application definitions must be entered in the NeXus -# data file tree as children of :ref:`NXentry`. -# -# -# -# -# ISIS Muon IDF_Version -# -# -# -# Extended title for entry -# -# -# -# Unique identifier for the experiment, defined by -# the facility, possibly linked to the proposals -# -# -# -# Brief summary of the experiment, including key objectives. -# -# -# Description of the full experiment (document in pdf, latex, ...) -# -# -# User or Data Acquisition defined group of NeXus files or :ref:`NXentry` -# -# -# Brief summary of the collection, including grouping criteria. -# -# -# unique identifier for the measurement, defined by the facility. -# -# -# Official NeXus NXDL schema to which this subentry conforms -# NXDL version number -# URL of NXDL file -# -# -# -# Local NXDL schema extended from the subentry -# specified in the ``definition`` field. -# This contains any locally-defined, -# additional fields in the subentry. -# -# NXDL version number -# URL of NXDL file -# -# -# Starting time of measurement -# -# -# Ending time of measurement -# -# -# Duration of measurement -# -# -# -# Time transpired actually collecting data i.e. taking out time when collection was -# suspended due to e.g. temperature out of range -# -# -# -# Such as "2007-3". Some user facilities organize their beam time into run cycles. -# -# -# Name of program used to generate this file -# Program version number -# configuration of the program -# -# -# -# Revision id of the file due to re-calibration, reprocessing, new analysis, new -# instrument definition format, ... -# -# -# -# -# -# This is the flightpath before the sample position. This can be determined by a chopper, -# by the moderator or the source itself. In other words: it the distance to the component -# which gives the T0 signal to the detector electronics. If another component in the -# NXinstrument hierarchy provides this information, this should be a link. -# -# -# -# Notes describing entry -# -# -# -# A small image that is representative of the entry. An example of this is a 640x480 -# jpeg image automatically produced by a low resolution plot of the NXdata. -# -# -# The value should be an ``image/*`` -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# \ No newline at end of file diff --git a/base_classes/nyaml/NXtransformations.yaml b/base_classes/nyaml/NXtransformations.yaml deleted file mode 100644 index 0b4ee74536..0000000000 --- a/base_classes/nyaml/NXtransformations.yaml +++ /dev/null @@ -1,410 +0,0 @@ -category: base -doc: | - 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. -type: group -ignoreExtraGroups: true -ignoreExtraFields: true -ignoreExtraAttributes: true -NXtransformations(NXobject): - AXISNAME(NX_NUMBER): - nameType: any - unit: NX_TRANSFORMATION - exists: ['max', 'unbounded'] - doc: | - 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``. - \@transformation_type: - exists: optional - doc: | - 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. In this case the value of the ``AXISNAME`` field - is not used and can be set to the number ``NaN``. - - # - enumeration: [translation, rotation] - \@vector: - exists: optional - type: NX_NUMBER - doc: | - 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. - dimensions: - rank: 1 - dim: [[1, 3]] - \@offset: - type: NX_NUMBER - doc: | - 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. - dimensions: - rank: 1 - dim: [[1, 3]] - \@offset_units: - type: NX_CHAR - doc: | - Units of the offset. Values should be consistent with NX_LENGTH. - \@depends_on: - type: NX_CHAR - doc: | - Points to the path of a field defining the axis on which this instance of - NXtransformations depends or the string ".". It can also point to an instance of - ``NX_coordinate_system`` if this transformation depends on it. - \@equipment_component: - type: NX_CHAR - doc: | - An arbitrary identifier of a component of the equipment to which - the transformation belongs, such as 'detector_arm' or 'detector_module'. - NXtransformations with the same equipment_component label form a logical - grouping which can be combined together into a single change-of-basis - operation. - AXISNAME_end(NX_NUMBER): - unit: NX_TRANSFORMATION - nameType: any - exists: ['min', '0', 'max', 'unbounded'] - doc: | - ``AXISNAME_end`` is a placeholder for a name constructed from the actual - name of an axis to which ``_end`` has been appended. - - The values in this field are the end points of the motions that start - at the corresponding positions given in the ``AXISNAME`` field. - AXISNAME_increment_set(NX_NUMBER): - unit: NX_TRANSFORMATION - nameType: any - exists: ['min', '0'] - doc: | - ``AXISNAME_increment_set`` is a placeholder for a name constructed from the actual - name of an axis to which ``_increment_set`` has been appended. - - The value of this optional field is the intended average range through which - the corresponding axis moves during the exposure of a frame. Ideally, the - value of this field added to each value of ``AXISNAME`` would agree with the - corresponding values of ``AXISNAME_end``, but there is a possibility of significant - differences. Use of ``AXISNAME_end`` is recommended. - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# cc6c5475afdcad3cf47b731a16b58acf04d00e3ba9d82f32430c5a60b1532fc5 -# -# -# -# -# -# -# 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. -# -# -# -# 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``. -# -# -# -# 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. In this case the value of the ``AXISNAME`` field -# is not used and can be set to the number ``NaN``. -# -# -# -# -# -# -# -# -# -# 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. -# -# -# -# -# -# -# -# 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. -# -# -# -# -# -# -# -# Units of the offset. Values should be consistent with NX_LENGTH. -# -# -# -# -# Points to the path of a field defining the axis on which this instance of -# NXtransformations depends or the string ".". It can also point to an instance of -# ``NX_coordinate_system`` if this transformation depends on it. -# -# -# -# -# An arbitrary identifier of a component of the equipment to which -# the transformation belongs, such as 'detector_arm' or 'detector_module'. -# NXtransformations with the same equipment_component label form a logical -# grouping which can be combined together into a single change-of-basis -# operation. -# -# -# -# -# -# ``AXISNAME_end`` is a placeholder for a name constructed from the actual -# name of an axis to which ``_end`` has been appended. -# -# The values in this field are the end points of the motions that start -# at the corresponding positions given in the ``AXISNAME`` field. -# -# -# -# -# ``AXISNAME_increment_set`` is a placeholder for a name constructed from the actual -# name of an axis to which ``_increment_set`` has been appended. -# -# The value of this optional field is the intended average range through which -# the corresponding axis moves during the exposure of a frame. Ideally, the -# value of this field added to each value of ``AXISNAME`` would agree with the -# corresponding values of ``AXISNAME_end``, but there is a possibility of significant -# differences. Use of ``AXISNAME_end`` is recommended. -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# \ No newline at end of file diff --git a/base_classes/nyaml/NXtranslation.yaml b/base_classes/nyaml/NXtranslation.yaml deleted file mode 100644 index 5909933d8b..0000000000 --- a/base_classes/nyaml/NXtranslation.yaml +++ /dev/null @@ -1,102 +0,0 @@ -category: base -doc: | - legacy class - (used by :ref:`NXgeometry`) - general spatial location of a component. -type: group -NXtranslation(NXobject): - geometry(NXgeometry): - doc: | - Link to other object if we are relative, else absent - distances(NX_FLOAT): - unit: NX_LENGTH - doc: | - (x,y,z) - This field describes the lateral movement of a component. - The pair of groups NXtranslation and NXorientation together - describe the position of a component. - For absolute position, the origin is the scattering center (where a perfectly - aligned sample would be) with the z-axis pointing downstream and the y-axis - pointing gravitationally up. For a relative position the NXtranslation is - taken into account before the NXorientation. The axes are right-handed and - orthonormal. - dimensions: - dim: [[1, numobj], [2, 3]] - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d90dcde19694778081106952e2d818986eeebc38b04d20b30081ac83cc22f05c -# -# -# -# -# -# legacy class - (used by :ref:`NXgeometry`) - general spatial location of a component. -# -# -# Link to other object if we are relative, else absent -# -# -# -# (x,y,z) -# This field describes the lateral movement of a component. -# The pair of groups NXtranslation and NXorientation together -# describe the position of a component. -# For absolute position, the origin is the scattering center (where a perfectly -# aligned sample would be) with the z-axis pointing downstream and the y-axis -# pointing gravitationally up. For a relative position the NXtranslation is -# taken into account before the NXorientation. The axes are right-handed and -# orthonormal. -# -# -# -# -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# diff --git a/base_classes/nyaml/NXuser.yaml b/base_classes/nyaml/NXuser.yaml deleted file mode 100644 index 0015eef603..0000000000 --- a/base_classes/nyaml/NXuser.yaml +++ /dev/null @@ -1,146 +0,0 @@ -category: base -doc: | - 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. -type: group -NXuser(NXobject): - name: - doc: | - Name of user responsible for this entry - role: - doc: | - Role of user responsible for this entry. - Suggested roles are "local_contact", - "principal_investigator", and "proposer" - affiliation: - doc: | - Affiliation of user - address: - doc: | - Address of user - telephone_number: - doc: | - Telephone number of user - fax_number: - doc: | - Fax number of user - email: - doc: | - Email of user - facility_user_id: - doc: | - facility based unique identifier for this person - e.g. their identification code on the facility - address/contact database - (NXidentifier): - doc: | - Details about an author code, open researcher, or contributor - (persistent) identifier, e.g. defined by https://orcid.org and expressed - as a URI. - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 23f00959a9d3d00b25aa5de9d27bd59c9931fcd3726f8c62e5ffb6e3c73860e2 -# -# -# -# -# -# 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. -# -# -# Name of user responsible for this entry -# -# -# -# Role of user responsible for this entry. -# Suggested roles are "local_contact", -# "principal_investigator", and "proposer" -# -# -# -# Affiliation of user -# -# -# Address of user -# -# -# Telephone number of user -# -# -# Fax number of user -# -# -# Email of user -# -# -# -# facility based unique identifier for this person -# e.g. their identification code on the facility -# address/contact database -# -# -# -# -# Details about an author code, open researcher, or contributor -# (persistent) identifier, e.g. defined by https://orcid.org and expressed -# as a URI. -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# \ No newline at end of file diff --git a/base_classes/nyaml/NXvelocity_selector.yaml b/base_classes/nyaml/NXvelocity_selector.yaml deleted file mode 100644 index 59af934414..0000000000 --- a/base_classes/nyaml/NXvelocity_selector.yaml +++ /dev/null @@ -1,198 +0,0 @@ -category: base -doc: | - A neutron velocity selector -type: group -NXvelocity_selector(NXobject): - type: - doc: | - velocity selector type - rotation_speed(NX_FLOAT): - unit: NX_FREQUENCY - doc: | - velocity selector rotation speed - radius(NX_FLOAT): - unit: NX_LENGTH - doc: | - radius at beam centre - spwidth(NX_FLOAT): - unit: NX_LENGTH - doc: | - spoke width at beam centre - length(NX_FLOAT): - unit: NX_LENGTH - doc: | - rotor length - num(NX_INT): - unit: NX_UNITLESS - doc: | - number of spokes/lamella - twist(NX_FLOAT): - unit: NX_ANGLE - doc: | - twist angle along axis - table(NX_FLOAT): - unit: NX_ANGLE - doc: | - offset vertical angle - height(NX_FLOAT): - unit: NX_LENGTH - doc: | - input beam height - width(NX_FLOAT): - unit: NX_LENGTH - doc: | - input beam width - wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - wavelength - wavelength_spread(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - deviation FWHM /Wavelength - (NXgeometry)geometry: - deprecated: | - Use the field `depends_on` and :ref:`NXtransformations` to position the velocity selector and NXoff_geometry to describe its shape instead - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the beam line component - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a velocity selector. - (NXtransformations): - doc: | - 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 97938152f3022d1c1cb7563f425e34aa88003a12619679c90a57ff06faec1039 -# -# -# -# -# A neutron velocity selector -# -# velocity selector type -# -# -# velocity selector rotation speed -# -# -# radius at beam centre -# -# -# spoke width at beam centre -# -# -# rotor length -# -# -# number of spokes/lamella -# -# -# twist angle along axis -# -# -# offset vertical angle -# -# -# input beam height -# -# -# input beam width -# -# -# wavelength -# -# -# deviation FWHM /Wavelength -# -# -# -# -# This group describes the shape of the beam line component -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a velocity selector. -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# diff --git a/base_classes/nyaml/NXxraylens.yaml b/base_classes/nyaml/NXxraylens.yaml deleted file mode 100644 index 53493fdf45..0000000000 --- a/base_classes/nyaml/NXxraylens.yaml +++ /dev/null @@ -1,220 +0,0 @@ -category: base -doc: | - An X-ray lens, typically at a synchrotron X-ray beam line. - - Based on information provided by Gerd Wellenreuther (DESY). -type: group -NXxraylens(NXobject): - lens_geometry(NX_CHAR): - doc: | - Geometry of the lens - enumeration: [paraboloid, spherical, elliptical, hyperbolical] - symmetric(NX_BOOLEAN): - doc: | - Is the device symmetric? - cylindrical(NX_BOOLEAN): - doc: | - Is the device cylindrical? - cylinder_orientation(NXnote): - doc: | - Orientation of the cylinder axis. - focus_type(NX_CHAR): - doc: | - The type of focus of the lens - enumeration: [line, point] - lens_thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - Thickness of the lens - lens_length(NX_FLOAT): - unit: NX_LENGTH - doc: | - Length of the lens - curvature(NX_FLOAT): - unit: NX_LENGTH - doc: | - Radius of the curvature as measured in the middle of the lens - aperture(NX_FLOAT): - unit: NX_LENGTH - doc: | - Diameter of the lens. - number_of_lenses(NX_INT): - doc: | - Number of lenses that make up the compound lens. - lens_material(NX_CHAR): - doc: | - Material used to make the lens. - gas(NX_CHAR): - doc: | - Gas used to fill the lens - gas_pressure(NX_FLOAT): - unit: NX_PRESSURE - doc: | - Gas pressure in the lens - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the beam line component - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a x-ray lens. - (NXtransformations): - doc: | - 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 42463f602acc0dd1a589f05eefda97ad6eaee88451d846e3c2a2ba173006ed3c -# -# -# -# -# -# -# An X-ray lens, typically at a synchrotron X-ray beam line. -# -# Based on information provided by Gerd Wellenreuther (DESY). -# -# -# Geometry of the lens -# -# -# -# -# -# -# -# -# -# Is the device symmetric? -# -# -# -# -# Is the device cylindrical? -# -# -# -# -# Orientation of the cylinder axis. -# -# -# -# -# The type of focus of the lens -# -# -# -# -# -# -# -# Thickness of the lens -# -# -# Length of the lens -# -# -# Radius of the curvature as measured in the middle of the lens -# -# -# Diameter of the lens. -# -# -# Number of lenses that make up the compound lens. -# -# -# Material used to make the lens. -# -# -# Gas used to fill the lens -# -# -# Gas pressure in the lens -# -# -# -# This group describes the shape of the beam line component -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a x-ray lens. -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# diff --git a/contributed_definitions/nyaml/NXamplifier.yaml b/contributed_definitions/nyaml/NXamplifier.yaml deleted file mode 100644 index 72ebfb260e..0000000000 --- a/contributed_definitions/nyaml/NXamplifier.yaml +++ /dev/null @@ -1,147 +0,0 @@ -category: base -doc: | - Base classed definition for amplifier devices. -type: group -NXamplifier(NXobject): - hardware(NXfabrication): - doc: | - (IC, device) (NXmanufacturer?) - num_of_channels(NX_NUMBER): - doc: | - The number of preamplifier channels are assgined. - active_channels(NX_NUMBER): - doc: | - The number of preamplifier channels are ready tp to be used. (array for active - channels) - openloop_amplification(NX_NUMBER): - doc: | - The output signal does not go through a feedback loop to adjust the - amplification of the amplifier. (array for active channels) - - # amplification(NX_NUMBER): - # doc: !!! The ratio of the amplitude of the output signal to the amplitude of the input signal. (array for active channels) # From google. - signal_over_noise(NX_NUMBER): - doc: | - The ratio of the amplitue of the useful signal to the amplitude of the noise in - the output signal of the amplifier. S/N=V_signal/V_noise. (array for active - channels) - crosstalk_factor(NX_NUMBER): - doc: | - (if active >1) - crosstalk_compensation(NX_BOOLEAN): - doc: | - for reducing interferences between different signalling pathways - bandwidth(NX_NUMBER): - unit: NX_FREQUENCY - doc: | - The spectrum of frequency it can amplify, from its lowest to highest frequency - limits. - low_pass(NX_NUMBER): - unit: NX_FREQUENCY - doc: | - Order and cut-off frequency of the low-pass filter applied on the demodulated - signals (X,Y). Cut-off frq (low pass filter) (foreach DemodulatorChannels) - hi_pass(NX_NUMBER): - unit: NX_FREQUENCY - doc: | - Order and cut-off frequency of the high-pass filter applied on the demodulation - signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) - - # voltage_amplifier_factor(NX_NUMBER): - # doc: !!! Current Amplifier Factor typically refers to the gain of the probe current amplifier. (V/V) - # current_amplifier_capacitive_cross_talk_compensation(NX_CHAR): - # doc: !!! Reduces the effect of capacitive crosstalk in the circuit on experimental results. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 30ee2a53e4916f585fdb1ffcf6e06f1bc2f32991928216d1c90a001263258f28 -# -# -# -# -# -# Base classed definition for amplifier devices. -# -# -# -# (IC, device) (NXmanufacturer?) -# -# -# -# -# The number of preamplifier channels are assgined. -# -# -# -# -# The number of preamplifier channels are ready tp to be used. (array for active -# channels) -# -# -# -# -# The output signal does not go through a feedback loop to adjust the -# amplification of the amplifier. (array for active channels) -# -# -# -# -# -# The ratio of the amplitue of the useful signal to the amplitude of the noise in -# the output signal of the amplifier. S/N=V_signal/V_noise. (array for active -# channels) -# -# -# -# -# (if active >1) -# -# -# -# -# for reducing interferences between different signalling pathways -# -# -# -# -# The spectrum of frequency it can amplify, from its lowest to highest frequency -# limits. -# -# -# -# -# Order and cut-off frequency of the low-pass filter applied on the demodulated -# signals (X,Y). Cut-off frq (low pass filter) (foreach DemodulatorChannels) -# -# -# -# -# Order and cut-off frequency of the high-pass filter applied on the demodulation -# signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml b/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml deleted file mode 100644 index a9a23d5124..0000000000 --- a/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml +++ /dev/null @@ -1,337 +0,0 @@ -category: application -doc: | - Application definition for a configuration of the CompositionSpace tool used in atom probe. - - * `A. Saxena et al. `_ - - This is an application definition for the common NFDI-MatWerk/FAIRmat infrastructure - use case IUC09 that explores how to improve the organization and results storage of the - CompositionSpace software using NeXus. -type: group -NXapm_compositionspace_config(NXobject): - - # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently - (NXentry): - exists: ['min', '1', 'max', '1'] - definition(NX_CHAR): - \@version: - type: NX_CHAR - exists: optional - enumeration: [NXapm_compositionspace_config] - config(NXobject): - (NXidentifier): - exists: optional - analysis_identifier(NX_UINT): - exists: recommended - reconstruction(NXserialized): - doc: | - Specification of the tomographic reconstruction used for this analysis. - Typically, reconstructions in the field of atom probe tomography are communicated via - files which store at least reconstructed ion positions and mass-to-charge-state-ratio - values. Container files like HDF5 though can store multiple reconstructions. - Therefore, the position and mass_to_charge concepts point to specific instances - to use for this analysis. - type(NX_CHAR): - exists: optional - path(NX_CHAR): - checksum(NX_CHAR): - exists: recommended - algorithm(NX_CHAR): - exists: recommended - position(NX_CHAR): - doc: | - Name of the node which resolves the reconstructed - ion position values to use for this analysis. - mass_to_charge(NX_CHAR): - exists: optional - doc: | - Name of the node which resolves the mass-to-charge-state ratio - values for each reconstructed ion to use for this analysis. - ranging(NXserialized): - doc: | - Specification of the ranging definitions used for this analysis. - - Indices start from 1. The value 0 is reserved for the null model of unranged positions whose - iontype is unknown_type. The value 0 is also reserved for voxels that lie outside the dataset. - type(NX_CHAR): - exists: optional - path(NX_CHAR): - checksum(NX_CHAR): - exists: recommended - algorithm(NX_CHAR): - exists: recommended - ranging_definitions(NX_CHAR): - doc: | - Name of the (parent) node directly below which the ranging definitions for - (molecular) ions are stored. - voxelization(NXprocess): - doc: | - Step during which the point cloud is discretized to compute element-specific composition fields. - Iontypes are atomically decomposed to correctly account for the multiplicity of each element that - was ranged for each ion. - edge_length(NX_NUMBER): - unit: NX_LENGTH - doc: | - Edge length of cubic voxels building the 3D grid that is used for discretizing - the point cloud. - autophase(NXprocess): - doc: | - Optional step during which the subsequent segmentation step is prepared with the aim to eventually - reduce the dimensionality of the chemical space in which the machine learning model works. - - In this step a supervised reduction of the dimensionality of the chemical space is quantified using - the (Gini) feature importance of each element to suggest which columns of the composition matrix - should be taken for the subsequent segmentation step. - use(NX_BOOLEAN): - doc: | - Was the automated phase assignment used? - initial_guess(NX_POSINT): - unit: NX_UNITLESS - doc: | - Estimated guess for which a Gaussian mixture model is evaluted to preprocess a result that - is subsequenty post-processed with a random_forest_classifier to lower the number of - dimensions in the chemical space to the subset of trunc_species many elements with the - highest feature importance. - trunc_species(NX_POSINT): - unit: NX_UNITLESS - doc: | - The number of elements to use for reducing the dimensionality. - random_forest_classifier(NXprocess): - exists: optional - doc: | - Configuration for the random forest classification model. - segmentation(NXprocess): - doc: | - Step during which the voxel set is segmented into voxel sets with different - chemical composition. - pca(NXprocess): - exists: optional - doc: | - A principal component analysis of the chemical space to guide a decision into how many sets of voxels - with different chemical composition the machine learning algorithm suggests to split the voxel set. - ic_opt(NXprocess): - doc: | - The decision is guided through the evalution of the information criterion - minimization. - n_max_ic_cluster(NX_POSINT): - unit: NX_UNITLESS - doc: | - The maximum number of chemical classes to probe with the Gaussian mixture model - with which the voxel set is segmented into a mixture of voxels with that many different - chemical compositions. - gaussian_mixture(NXprocess): - exists: optional - doc: | - Configuration for the Gaussian mixture model that is used in the segmentation - step. - clustering(NXprocess): - doc: | - Step during which the chemically segmented voxel sets are analyzed for their - spatial organization. - dbscan(NXobject): - doc: | - Configuration for the DBScan algorithm that is used in the clustering step. - eps(NX_FLOAT): - unit: NX_LENGTH - doc: | - The maximum distance between voxel pairs in a neighborhood to be considered - connected. - min_samples(NX_UINT): - unit: NX_UNITLESS - doc: | - The number of voxels in a neighborhood for a voxel to be considered as a core - point. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 97d13fe8c9822f8891a11748531ecb8c52896605f2a1a33a064d7e93e31b0407 -# -# -# -# -# -# Application definition for a configuration of the CompositionSpace tool used in atom probe. -# -# * `A. Saxena et al. <https://www.github.com/eisenforschung/CompositionSpace.git>`_ -# -# This is an application definition for the common NFDI-MatWerk/FAIRmat infrastructure -# use case IUC09 that explores how to improve the organization and results storage of the -# CompositionSpace software using NeXus. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Specification of the tomographic reconstruction used for this analysis. -# Typically, reconstructions in the field of atom probe tomography are communicated via -# files which store at least reconstructed ion positions and mass-to-charge-state-ratio -# values. Container files like HDF5 though can store multiple reconstructions. -# Therefore, the position and mass_to_charge concepts point to specific instances -# to use for this analysis. -# -# -# -# -# -# -# -# Name of the node which resolves the reconstructed -# ion position values to use for this analysis. -# -# -# -# -# Name of the node which resolves the mass-to-charge-state ratio -# values for each reconstructed ion to use for this analysis. -# -# -# -# -# -# Specification of the ranging definitions used for this analysis. -# -# Indices start from 1. The value 0 is reserved for the null model of unranged positions whose -# iontype is unknown_type. The value 0 is also reserved for voxels that lie outside the dataset. -# -# -# -# -# -# -# -# Name of the (parent) node directly below which the ranging definitions for -# (molecular) ions are stored. -# -# -# -# -# -# Step during which the point cloud is discretized to compute element-specific composition fields. -# Iontypes are atomically decomposed to correctly account for the multiplicity of each element that -# was ranged for each ion. -# -# -# -# Edge length of cubic voxels building the 3D grid that is used for discretizing -# the point cloud. -# -# -# -# -# -# Optional step during which the subsequent segmentation step is prepared with the aim to eventually -# reduce the dimensionality of the chemical space in which the machine learning model works. -# -# In this step a supervised reduction of the dimensionality of the chemical space is quantified using -# the (Gini) feature importance of each element to suggest which columns of the composition matrix -# should be taken for the subsequent segmentation step. -# -# -# -# Was the automated phase assignment used? -# -# -# -# -# Estimated guess for which a Gaussian mixture model is evaluted to preprocess a result that -# is subsequenty post-processed with a random_forest_classifier to lower the number of -# dimensions in the chemical space to the subset of trunc_species many elements with the -# highest feature importance. -# -# -# -# -# The number of elements to use for reducing the dimensionality. -# -# -# -# -# Configuration for the random forest classification model. -# -# -# -# -# -# Step during which the voxel set is segmented into voxel sets with different -# chemical composition. -# -# -# -# A principal component analysis of the chemical space to guide a decision into how many sets of voxels -# with different chemical composition the machine learning algorithm suggests to split the voxel set. -# -# -# -# -# The decision is guided through the evalution of the information criterion -# minimization. -# -# -# -# The maximum number of chemical classes to probe with the Gaussian mixture model -# with which the voxel set is segmented into a mixture of voxels with that many different -# chemical compositions. -# -# -# -# -# Configuration for the Gaussian mixture model that is used in the segmentation -# step. -# -# -# -# -# -# -# Step during which the chemically segmented voxel sets are analyzed for their -# spatial organization. -# -# -# -# Configuration for the DBScan algorithm that is used in the clustering step. -# -# -# -# The maximum distance between voxel pairs in a neighborhood to be considered -# connected. -# -# -# -# -# The number of voxels in a neighborhood for a voxel to be considered as a core -# point. -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml b/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml deleted file mode 100644 index ff0a9a823c..0000000000 --- a/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml +++ /dev/null @@ -1,715 +0,0 @@ -category: application -doc: | - Application definition for results of the CompositionSpace tool used in atom probe. - - * `A. Saxena et al. `_ - - This is an application definition for the common NFDI-MatWerk/FAIRmat infrastructure - use case IUC09 that explores how to improve the organization and results storage of the - CompositionSpace software using NeXus. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - grid_dim: | - The dimensionality of the grid. - n_voxels: | - Total number of voxels. - n_ions: | - Total number of ions in the reconstructed dataset. -type: group -NXapm_compositionspace_results(NXobject): - - # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently - (NXentry): - exists: ['min', '1', 'max', '1'] - definition(NX_CHAR): - \@version: - type: NX_CHAR - exists: optional - enumeration: [NXapm_compositionspace_results] - - # can be used for the name of the tool and version but also - # for if desired all the dependencies and libraries - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - \@url: - type: NX_CHAR - exists: optional - (NXidentifier): - exists: optional - analysis_identifier(NX_UINT): - exists: recommended - - # config - config(NXserialized): - doc: | - Configuration file that was used in this analysis. - type(NX_CHAR): - exists: optional - path(NX_CHAR): - algorithm(NX_CHAR): - exists: recommended - checksum(NX_CHAR): - exists: recommended - - # results - (NXuser): - exists: optional - voxelization(NXprocess): - exists: ['min', '0', 'max', '1'] - doc: | - Step during which the point cloud is discretized to compute element-specific composition fields. - Iontypes are atomically decomposed to correctly account for the multiplicity of each element that - was ranged for each ion. - - Using a discretization grid that is larger than the average distance between reconstructed ion positions - reduces computational costs. This is the key idea of the CompositionSpace tool compared to other methods - used in atom probe for characterizing microstructural features using the ion position data directly. - sequence_index(NX_POSINT): - enumeration: [1] - cg_grid(NXcg_grid): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - enumeration: [3] - cardinality(NX_POSINT): - unit: NX_UNITLESS - origin(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, grid_dim]] - symmetry: - enumeration: [cubic] - cell_dimensions(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, grid_dim]] - extent(NX_POSINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, grid_dim]] - identifier_offset(NX_INT): - unit: NX_UNITLESS - position(NX_NUMBER): - unit: NX_LENGTH - doc: | - Position of each cell in Euclidean space. - dimensions: - rank: 2 - dim: [[1, n_voxels], [2, grid_dim]] - coordinate(NX_INT): - unit: NX_DIMENSIONLESS - doc: | - Discrete coordinate of each voxel. - dimensions: - rank: 2 - dim: [[1, n_voxels], [2, grid_dim]] - - # bounding box if needed - voxel_identifier(NX_UINT): - unit: NX_UNITLESS - doc: | - For each ion, the identifier of the voxel into which the ion binned. - dimensions: - rank: 1 - dim: [[1, n_ions]] - weight(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Total number of weight (counts for discretization with a rectangular transfer function) - for the occupancy of each voxel with atoms. - dimensions: - rank: 1 - dim: [[1, n_voxels]] - elementID(NXion): - exists: ['min', '1', 'max', 'unbounded'] - name(NX_CHAR): - doc: | - Chemical symbol of the element from the periodic table. - weight(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Element-specific weight (counts for discretization with a rectangular transfer function) - for the occupancy of each voxel with atoms of this element. - dimensions: - rank: 1 - dim: [[1, n_voxels]] - autophase(NXprocess): - exists: ['min', '0', 'max', '1'] - doc: | - Optional step during which the subsequent segmentation step is prepared to - improve the segmentation. - sequence_index(NX_POSINT): - enumeration: [2] - result(NXdata): - \@signal: - type: NX_CHAR - \@axes: - type: NX_CHAR - \@AXISNAME_indices: - type: NX_CHAR - title(NX_CHAR): - exists: recommended - axis_feature_identifier(NX_UINT): - unit: NX_DIMENSIONLESS - doc: | - Element identifier stored sorted in descending order of feature importance. - dimensions: - rank: 1 - dim: [[1, i]] - \@long_name: - type: NX_CHAR - doc: | - Axis caption - axis_feature_importance(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Element relative feature importance stored sorted in descending order of feature - importance. - dimensions: - rank: 1 - dim: [[1, i]] - \@long_name: - type: NX_CHAR - doc: | - Axis caption - segmentation(NXprocess): - exists: ['min', '0', 'max', '1'] - doc: | - Step during which the voxel set is segmented into voxel sets with different - chemical composition. - pca(NXprocess): - exists: ['min', '1', 'max', '1'] - doc: | - PCA in the chemical space (essentially composition correlation analyses). - sequence_index(NX_POSINT): - enumeration: [2, 3] - result(NXdata): - \@signal: - type: NX_CHAR - \@axes: - type: NX_CHAR - \@AXISNAME_indices: - type: NX_CHAR - title(NX_CHAR): - exists: recommended - axis_explained_variance(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Explained variance values - dimensions: - rank: 1 - dim: [[1, i]] - axis_pca_dimension(NX_UINT): - unit: NX_UNITLESS - doc: | - Elements identifier matching those from ENTRY/voxelization/elementID as the - principal component analysis. - dimensions: - rank: 1 - dim: [[1, i]] - ic_opt(NXprocess): - doc: | - Information criterion minimization. - sequence_index(NX_POSINT): - enumeration: [3, 4] - cluster_analysisID(NXprocess): - doc: | - Results of the Gaussian mixture analysis for n_components equal to n_ic_cluster. - n_ic_cluster(NX_UINT): - unit: NX_UNITLESS - doc: | - n_components argument of the Gaussian mixture model. - y_pred(NX_UINT): - unit: NX_UNITLESS - doc: | - y_pred return values of the computation. - dimensions: - rank: 1 - dim: [[1, n_voxels]] - result(NXdata): - doc: | - Information criterion as a function of number of n_ic_cluster aka dimensions. - \@signal: - type: NX_CHAR - \@axes: - type: NX_CHAR - \@AXISNAME_indices: - type: NX_CHAR - title(NX_CHAR): - exists: recommended - axis_aic(NX_FLOAT): - exists: recommended - unit: NX_ANY - doc: | - Akaike information criterion values - dimensions: - rank: 1 - dim: [[1, i]] - axis_bic(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Bayes information criterion values - dimensions: - rank: 1 - dim: [[1, i]] - axis_dimension(NX_UINT): - unit: NX_UNITLESS - doc: | - Actual n_ic_cluster values used - dimensions: - rank: 1 - dim: [[1, i]] - clustering(NXprocess): - exists: ['min', '0', 'max', '1'] - doc: | - Step during which the chemically segmented voxel sets are analyzed for their spatial organization - into different spatial clusters of voxels in the same chemical set but representing individual object - not-necessarily watertight or topologically closed objects built from individual voxels. - sequence_index(NX_POSINT): - enumeration: [4, 5] - ic_opt(NXobject): - doc: | - Respective DBScan clustering result for each segmentation/ic_opt case. - cluster_analysisID(NXprocess): - exists: ['min', '0', 'max', 'unbounded'] - dbscanID(NXprocess): - exists: ['min', '1', 'max', 'unbounded'] - epsilon(NX_FLOAT): - unit: NX_LENGTH - doc: | - The maximum distance between voxel pairs in a neighborhood to be considered - connected. - min_samples(NX_UINT): - unit: NX_UNITLESS - doc: | - The number of voxels in a neighborhood for a voxel to be considered as a core - point. - label(NX_INT): - unit: NX_UNITLESS - doc: | - Raw label return values - dimensions: - rank: 1 - dim: [[1, k]] - voxel(NX_UINT): - unit: NX_UNITLESS - doc: | - Voxel identifier - - Using these identifiers correlated element-wise with the values in the label array - specifies for which voxel in the grid clusters from this process were found. - dimensions: - rank: 1 - dim: [[1, n_voxels]] - profiling(NXcs_profiling): - exists: optional - current_working_directory(NX_CHAR): - exists: recommended - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - total_elapsed_time(NX_NUMBER): - - # number_of_processes(NX_POSINT): - # number_of_threads(NX_POSINT): - # number_of_gpus(NX_POSINT): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# cf31932949a3d5b216551f8f62516c4522531ff17e818ec62daf3257d6badcac -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality of the grid. -# -# -# -# -# Total number of voxels. -# -# -# -# -# Total number of ions in the reconstructed dataset. -# -# -# -# -# Application definition for results of the CompositionSpace tool used in atom probe. -# -# * `A. Saxena et al. <https://www.github.com/eisenforschung/CompositionSpace.git>`_ -# -# This is an application definition for the common NFDI-MatWerk/FAIRmat infrastructure -# use case IUC09 that explores how to improve the organization and results storage of the -# CompositionSpace software using NeXus. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Configuration file that was used in this analysis. -# -# -# -# -# -# -# -# -# -# -# Step during which the point cloud is discretized to compute element-specific composition fields. -# Iontypes are atomically decomposed to correctly account for the multiplicity of each element that -# was ranged for each ion. -# -# Using a discretization grid that is larger than the average distance between reconstructed ion positions -# reduces computational costs. This is the key idea of the CompositionSpace tool compared to other methods -# used in atom probe for characterizing microstructural features using the ion position data directly. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Position of each cell in Euclidean space. -# -# -# -# -# -# -# -# -# Discrete coordinate of each voxel. -# -# -# -# -# -# -# -# -# -# For each ion, the identifier of the voxel into which the ion binned. -# -# -# -# -# -# -# -# -# Total number of weight (counts for discretization with a rectangular transfer function) -# for the occupancy of each voxel with atoms. -# -# -# -# -# -# -# -# -# Chemical symbol of the element from the periodic table. -# -# -# -# -# Element-specific weight (counts for discretization with a rectangular transfer function) -# for the occupancy of each voxel with atoms of this element. -# -# -# -# -# -# -# -# -# -# Optional step during which the subsequent segmentation step is prepared to -# improve the segmentation. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Element identifier stored sorted in descending order of feature importance. -# -# -# -# -# -# -# Axis caption -# -# -# -# -# -# Element relative feature importance stored sorted in descending order of feature -# importance. -# -# -# -# -# -# -# Axis caption -# -# -# -# -# -# -# -# Step during which the voxel set is segmented into voxel sets with different -# chemical composition. -# -# -# -# PCA in the chemical space (essentially composition correlation analyses). -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Explained variance values -# -# -# -# -# -# -# -# Elements identifier matching those from ENTRY/voxelization/elementID as the -# principal component analysis. -# -# -# -# -# -# -# -# -# -# Information criterion minimization. -# -# -# -# -# -# -# -# -# -# Results of the Gaussian mixture analysis for n_components equal to n_ic_cluster. -# -# -# -# n_components argument of the Gaussian mixture model. -# -# -# -# -# y_pred return values of the computation. -# -# -# -# -# -# -# -# -# Information criterion as a function of number of n_ic_cluster aka dimensions. -# -# -# -# -# -# -# -# Akaike information criterion values -# -# -# -# -# -# -# -# Bayes information criterion values -# -# -# -# -# -# -# -# Actual n_ic_cluster values used -# -# -# -# -# -# -# -# -# -# -# Step during which the chemically segmented voxel sets are analyzed for their spatial organization -# into different spatial clusters of voxels in the same chemical set but representing individual object -# not-necessarily watertight or topologically closed objects built from individual voxels. -# -# -# -# -# -# -# -# -# -# Respective DBScan clustering result for each segmentation/ic_opt case. -# -# -# -# -# -# The maximum distance between voxel pairs in a neighborhood to be considered -# connected. -# -# -# -# -# The number of voxels in a neighborhood for a voxel to be considered as a core -# point. -# -# -# -# -# Raw label return values -# -# -# -# -# -# -# -# Voxel identifier -# -# Using these identifiers correlated element-wise with the values in the label array -# specifies for which voxel in the grid clusters from this process were found. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml deleted file mode 100644 index 24693897d5..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml +++ /dev/null @@ -1,704 +0,0 @@ -category: application -doc: | - Application definition for a configuration file of the paraprobe-clusterer tool. - - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - - # n_positions: Number of position values. - # n_disjoint_clusters: Number of disjoint cluster. - n_ivec_max: | - Maximum number of atoms per molecular ion. Should be 32 for paraprobe. - n_clust_algos: | - Number of clustering algorithms used. - n_ions: | - Number of different iontypes to distinguish during clustering. -type: group -NXapm_paraprobe_clusterer_config(NXobject): - (NXentry): - exists: ['min', '1', 'max', '1'] - definition(NX_CHAR): - \@version: - type: NX_CHAR - enumeration: [NXapm_paraprobe_clusterer_config] - number_of_tasks(NX_UINT): - unit: NX_UNITLESS - doc: | - How many cluster_analysis tasks should the tool execute. - cameca_to_nexus(NXapm_paraprobe_tool_config): - exists: ['min', '0', 'max', '1'] - doc: | - This process maps results from a cluster analysis made with IVAS / AP Suite - into an interoperable representation. IVAS / AP Suite usually exports such results - as a list of reconstructed ion positions with one cluster label per position. - These labels are reported via the mass-to-charge-state-ratio column of what is effectively - a binary file that is formatted like a POS file but cluster labels written out using floating - point numbers. - reconstruction(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - position(NX_CHAR): - mass_to_charge(NX_CHAR): - results(NXserialized): - doc: | - File with the results of the cluster analyses that was computed with IVAS / AP suite - (e.g. maximum-separation method clustering algorithm `J. Hyde et al. `_). - The information is stored in an improper (.indexed.) POS file as a matrix of floating - point quadruplets, one quadruplet for each ion. The first three values of each - quadruplet encode the position of the ion. The fourth value is the integer identifier - of the cluster encoded as a floating point number. - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - recover_evaporation_id(NX_BOOLEAN): - doc: | - Specifies if paraprobe-clusterer should use the evaporation_ids from reconstruction - for recovering for each position in the :ref:`NXserialized` results the closest matching position - (within floating point accuracy). This can be useful when users wish to recover the - original evaporation_id, which IVAS /AP Suite drops when writing their *.indexed.* cluster - results POS files that is referred to results. - - # recover_bitmask(NX_BOOLEAN): - # doc: | - # Specifies if the tool should try to recover, after a recovery of the - # evaporation IDs a bitmask which identifies which of the positions - # in dataset/dataset/dataset_name_reconstruction where covered - # by the IVAS/APSuite cluster analysis. This can be useful to recover - # the region of interest. - cluster_analysisID(NXapm_paraprobe_tool_config): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - This process performs a cluster analysis on a - reconstructed dataset or a ROI within it. - reconstruction(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - position(NX_CHAR): - mass_to_charge(NX_CHAR): - ranging(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - ranging_definitions(NX_CHAR): - surface_distance(NXserialized): - exists: optional - doc: | - Distance between each ion and triangulated surface mesh. - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - distance(NX_CHAR): - spatial_filter(NXspatial_filter): - windowing_method(NX_CHAR): - hexahedron_set(NXcg_hexahedron_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - hexahedra(NXcg_face_list_data_structure): - vertices(NX_UINT): - cylinder_set(NXcg_cylinder_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - height(NX_NUMBER): - radii(NX_NUMBER): - ellipsoid_set(NXcg_ellipsoid_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - half_axes_radii(NX_NUMBER): - orientation(NX_NUMBER): - polyhedron_set(NXcg_polyhedron_set): - exists: optional - - # TODO - bitmask(NXcs_filter_boolean_mask): - exists: optional - number_of_objects(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - - # leave open if scalar or matrix - # dim: (i,) - # identifier(NX_UINT): - evaporation_id_filter(NXsubsampling_filter): - exists: optional - min_incr_max(NX_INT): - iontype_filter(NXmatch_filter): - exists: optional - method(NX_CHAR): - match(NX_NUMBER): - hit_multiplicity_filter(NXmatch_filter): - exists: optional - method(NX_CHAR): - match(NX_NUMBER): - - # config - ion_type_filter(NX_CHAR): - doc: | - How should iontypes be considered during the cluster analysis. - - The value resolve_all will set an ion active - in the analysis regardless of which iontype it is. - - The value resolve_unknown will set an ion active - when it is of the UNKNOWNTYPE. - - The value resolve_ion will set an ion active - if it is of the specific iontype, irregardless of its nuclide structure. - - The value resolve_element will set an ion active and account as many times - for it, as the (molecular) ion contains atoms of elements in the whitelist - ion_query_nuclide_vector. - - The value resolve_isotope will set an ion active and account as many times - for it, as the (molecular) ion contains nuclides in the whitelist - ion_query_nuclide_vector. - - In effect, ion_query_nuclide_vector acts as a whitelist to filter which ions are - considered as source ions of the correlation statistics and how the multiplicity - of each ion will be factorized. - - This is relevant as in atom probe we have the situation that an ion of a molecular - ion with more than one nuclide, say Ti O for example is counted potentially several - times because at that position (reconstructed) position it has been assumed that - there was a Ti and an O atom. This multiplicity affects the size of the feature and its - chemical composition. - - # enumeration: [resolve_all, resolve_unknown, resolve_ion, resolve_element, resolve_isotope] - enumeration: [resolve_element] - ion_query_nuclide_vector(NX_UINT): - unit: NX_UNITLESS - doc: | - Matrix of nuclide vectors, as many as rows as different candidates - for iontypes should be distinguished as possible source iontypes. - In the simplest case, the matrix contains only the proton number - of the element in the row, all other values set to zero. - dimensions: - rank: 2 - dim: [[1, n_ions], [2, n_ivec_max]] - - # which clustering algorithms to execute? - dbscan(NXprocess): - doc: | - Settings for DBScan clustering algorithm. For original details about the - algorithm and (performance-relevant) details consider: - - * `M. Ester et al. `_ - * `M. Götz et al. `_ - - For details about how the DBScan algorithms is the key behind the - specific modification known as the maximum-separation method in the - atom probe community consider `E. Jägle et al. `_ - high_throughput_method(NX_CHAR): - doc: | - Strategy how a set of cluster analyses with different parameter is executed: - - * For tuple as many runs are performed as parameter values have been defined. - * For combinatorics individual parameter arrays are looped over. - - As an example we may provide ten entries for eps and three entries for min_pts. - If high_throughput_method is set to tuple, the analysis is invalid because we have - an insufficient number of min_pts values to pair them with our ten eps values. - By contrast, if high_throughput_method is set to combinatorics, the tool will run three - individual min_pts runs for each eps value, resulting in a total of 30 analyses. - - A typical example from the literature `M. Kühbach et al. `_ - can be instructed via setting eps to an array of values np.linspace(0.2, 5.0, nums=241, endpoint=True), - one min_pts value that is equal to 1, and high_throughput_method set to combinatorics. - enumeration: [tuple, combinatorics] - eps(NX_FLOAT): - unit: NX_LENGTH - doc: | - Array of epsilon (eps) parameter values. - dimensions: - rank: 1 - dim: [[1, i]] - min_pts(NX_UINT): - unit: NX_UNITLESS - doc: | - Array of minimum points (min_pts) parameter values. - dimensions: - rank: 1 - dim: [[1, j]] - - # THE IDEA BEHIND paraprobe-clusterer is that users can run a number of cluster analyses - # on their dataset on exactly the same point cloud and under the same conditions - # optics(NXprocess): - # doc: | - # Settings for the OPTICS clustering algorithm. - # * `M. Ankerest et al. `_ - # high_throughput_method(NX_CHAR): - # doc: | - # Strategy how runs with different parameter values are composed, - # following the explanation for higih_throughput_method of dbscan. - # enumeration: [tuple, combinatorics] - # min_pts(NX_UINT): - # doc: | - # Array of minimum points (min_pts) parameter values. - # unit: NX_UNITLESS - # dim: (i,) - # max_eps(NX_FLOAT): - # doc: | - # Array of maximum epsilon (eps) parameter values. - # unit: NX_LENGTH - # dim: (j,) - hdbscan(NXprocess): - doc: | - Settings for the HPDBScan clustering algorithm. - - * L. McInnes et al. `_ - * scikit-learn hdbscan library ``_ - - See also this documentation for details about the parameter. - Here we use the terminology of the hdbscan documentation. - high_throughput_method(NX_CHAR): - doc: | - Strategy how runs with different parameter values are composed, - following the explanation for higih_throughput_method of dbscan. - enumeration: [tuple, combinatorics] - min_cluster_size(NX_NUMBER): - unit: NX_ANY - doc: | - Array of min_cluster_size parameter values. - dimensions: - rank: 1 - dim: [[1, i]] - min_samples(NX_NUMBER): - unit: NX_ANY - doc: | - Array of min_samples parameter values. - dimensions: - rank: 1 - dim: [[1, j]] - cluster_selection_epsilon(NX_NUMBER): - unit: NX_ANY - doc: | - Array of cluster_selection parameter values. - dimensions: - rank: 1 - dim: [[1, k]] - alpha(NX_NUMBER): - unit: NX_ANY - doc: | - Array of alpha parameter values. - dimensions: - rank: 1 - dim: [[1, m]] - - # ADD FURTHER ALGORITHMS, see L. Stephenson for further details - # e.g. https://doi.org/10.1017/S1431927607070900 - common(NXapm_paraprobe_tool_common): - status(NX_CHAR): - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - profiling(NXcs_profiling): - exists: recommended - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - total_elapsed_time(NX_FLOAT): - current_working_directory(NX_CHAR): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 24724111ada93fe288d1bc2ed0d32f2b9f20f745419144c5bfb2f73eaa822ebd -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# -# Maximum number of atoms per molecular ion. Should be 32 for paraprobe. -# -# -# -# -# Number of clustering algorithms used. -# -# -# -# -# Number of different iontypes to distinguish during clustering. -# -# -# -# -# Application definition for a configuration file of the paraprobe-clusterer tool. -# -# This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. -# -# -# -# -# -# -# -# -# -# -# How many cluster_analysis tasks should the tool execute. -# -# -# -# -# This process maps results from a cluster analysis made with IVAS / AP Suite -# into an interoperable representation. IVAS / AP Suite usually exports such results -# as a list of reconstructed ion positions with one cluster label per position. -# These labels are reported via the mass-to-charge-state-ratio column of what is effectively -# a binary file that is formatted like a POS file but cluster labels written out using floating -# point numbers. -# -# -# -# -# -# -# -# -# -# -# -# File with the results of the cluster analyses that was computed with IVAS / AP suite -# (e.g. maximum-separation method clustering algorithm `J. Hyde et al. <https://doi.org/10.1557/PROC-650-R6.6>`_). -# The information is stored in an improper (.indexed.) POS file as a matrix of floating -# point quadruplets, one quadruplet for each ion. The first three values of each -# quadruplet encode the position of the ion. The fourth value is the integer identifier -# of the cluster encoded as a floating point number. -# -# -# -# -# -# -# -# -# Specifies if paraprobe-clusterer should use the evaporation_ids from reconstruction -# for recovering for each position in the :ref:`NXserialized` results the closest matching position -# (within floating point accuracy). This can be useful when users wish to recover the -# original evaporation_id, which IVAS /AP Suite drops when writing their *.indexed.* cluster -# results POS files that is referred to results. -# -# -# -# -# -# -# This process performs a cluster analysis on a -# reconstructed dataset or a ROI within it. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Distance between each ion and triangulated surface mesh. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# How should iontypes be considered during the cluster analysis. -# -# The value resolve_all will set an ion active -# in the analysis regardless of which iontype it is. -# -# The value resolve_unknown will set an ion active -# when it is of the UNKNOWNTYPE. -# -# The value resolve_ion will set an ion active -# if it is of the specific iontype, irregardless of its nuclide structure. -# -# The value resolve_element will set an ion active and account as many times -# for it, as the (molecular) ion contains atoms of elements in the whitelist -# ion_query_nuclide_vector. -# -# The value resolve_isotope will set an ion active and account as many times -# for it, as the (molecular) ion contains nuclides in the whitelist -# ion_query_nuclide_vector. -# -# In effect, ion_query_nuclide_vector acts as a whitelist to filter which ions are -# considered as source ions of the correlation statistics and how the multiplicity -# of each ion will be factorized. -# -# This is relevant as in atom probe we have the situation that an ion of a molecular -# ion with more than one nuclide, say Ti O for example is counted potentially several -# times because at that position (reconstructed) position it has been assumed that -# there was a Ti and an O atom. This multiplicity affects the size of the feature and its -# chemical composition. -# -# -# -# -# -# -# -# -# Matrix of nuclide vectors, as many as rows as different candidates -# for iontypes should be distinguished as possible source iontypes. -# In the simplest case, the matrix contains only the proton number -# of the element in the row, all other values set to zero. -# -# -# -# -# -# -# -# -# -# Settings for DBScan clustering algorithm. For original details about the -# algorithm and (performance-relevant) details consider: -# -# * `M. Ester et al. <https://dx.doi.org/10.5555/3001460.3001507>`_ -# * `M. Götz et al. <https://dx.doi.org/10.1145/2834892.2834894>`_ -# -# For details about how the DBScan algorithms is the key behind the -# specific modification known as the maximum-separation method in the -# atom probe community consider `E. Jägle et al. <https://dx.doi.org/10.1017/S1431927614013294>`_ -# -# -# -# Strategy how a set of cluster analyses with different parameter is executed: -# -# * For tuple as many runs are performed as parameter values have been defined. -# * For combinatorics individual parameter arrays are looped over. -# -# As an example we may provide ten entries for eps and three entries for min_pts. -# If high_throughput_method is set to tuple, the analysis is invalid because we have -# an insufficient number of min_pts values to pair them with our ten eps values. -# By contrast, if high_throughput_method is set to combinatorics, the tool will run three -# individual min_pts runs for each eps value, resulting in a total of 30 analyses. -# -# A typical example from the literature `M. Kühbach et al. <https://dx.doi.org/10.1038/s41524-020-00486-1>`_ -# can be instructed via setting eps to an array of values np.linspace(0.2, 5.0, nums=241, endpoint=True), -# one min_pts value that is equal to 1, and high_throughput_method set to combinatorics. -# -# -# -# -# -# -# -# -# Array of epsilon (eps) parameter values. -# -# -# -# -# -# -# -# Array of minimum points (min_pts) parameter values. -# -# -# -# -# -# -# -# -# -# Settings for the HPDBScan clustering algorithm. -# -# * L. McInnes et al. <https://dx.doi.org/10.21105/joss.00205>`_ -# * scikit-learn hdbscan library `<https://hdbscan.readthedocs.io/en/latest/how_hdbscan_works.html>`_ -# -# See also this documentation for details about the parameter. -# Here we use the terminology of the hdbscan documentation. -# -# -# -# Strategy how runs with different parameter values are composed, -# following the explanation for higih_throughput_method of dbscan. -# -# -# -# -# -# -# -# -# Array of min_cluster_size parameter values. -# -# -# -# -# -# -# -# Array of min_samples parameter values. -# -# -# -# -# -# -# -# Array of cluster_selection parameter values. -# -# -# -# -# -# -# -# Array of alpha parameter values. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml deleted file mode 100644 index 1200e2c575..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml +++ /dev/null @@ -1,549 +0,0 @@ -category: application -doc: | - Application definition for results files of the paraprobe-spatstat tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_ions: | - The total number of ions in the reconstruction. - n_feat: | - Number of clusters found. -type: group -NXapm_paraprobe_clusterer_results(NXobject): - (NXentry): - exists: ['min', '1', 'max', '1'] - definition(NX_CHAR): - \@version: - type: NX_CHAR - enumeration: [NXapm_paraprobe_clusterer_results] - - # tasks - cameca_to_nexus(NXapm_paraprobe_tool_results): - exists: optional - cluster_analysisID(NXapm_paraprobe_tool_results): - exists: ['min', '0', 'max', 'unbounded'] - analysis_identifier(NX_UINT): - config(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - window(NXcs_filter_boolean_mask): - number_of_ions(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - - # results - dbscanID(NXsimilarity_grouping): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - Results of a DBScan clustering analysis. - eps(NX_FLOAT): - unit: NX_LENGTH - doc: | - The epsilon (eps) parameter used. - min_pts(NX_UINT): - unit: NX_UNITLESS - doc: | - The minimum points (min_pts) parameter used. - cardinality(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of members in the set which is partitioned into features. - Specifically, this is the total number of targets filtered from the - dataset, i.e. typically the number of clusters which is usually not and - for sure not necessarily the total number of ions in the dataset. - identifier_offset(NX_INT): - doc: | - Which identifier is the first to be used to label a cluster. - - The value should be chosen in such a way that special values can be resolved: - * identifier_offset - 1 indicates an object belongs to no cluster. - * identifier_offset - 2 indicates an object belongs to the noise category. - - Setting for instance identifier_offset to 1 recovers the commonly used - case that objects of the noise category get the value of -1 and points of the - unassigned category get the value 0. - targets(NX_UINT): - unit: NX_UNITLESS - doc: | - The evaporation (sequence) identifier (aka evaporation_id) to figure out - which ions from the reconstruction were considered targets. The length - of this array is not necessarily n_ions. - Instead, it is the value of cardinality. - dimensions: - rank: 1 - dim: [[1, i]] - - # quantities for debugging purposes - number_of_solutions(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - The number of solutions found for each target. Typically, - this value is 1 in which case the field can be omitted. - Otherwise, this array is the concatenated set of values of solution - tuples for each target that can be used to decode model_labels, - core_sample_indices, and weight. - dimensions: - rank: 1 - dim: [[1, i]] - model_labels(NX_INT): - exists: optional - unit: NX_UNITLESS - doc: | - The raw labels from the DBScan clustering backend process. - The length of this array is not necessarily n_ions. - Instead, it is typically the value of cardinality provided that each - target has only one associated cluster. If targets are assigned to - multiple cluster this array is as long as the total number of solutions - found and - dimensions: - rank: 1 - dim: [[1, k]] - core_sample_indices(NX_INT): - exists: optional - unit: NX_UNITLESS - doc: | - The raw array of core sample indices which specify which of the - targets are core points. - dimensions: - rank: 1 - dim: [[1, k]] - numerical_labels(NX_UINT): - unit: NX_UNITLESS - doc: | - Numerical label for each target (member in the set) aka cluster identifier. - dimensions: - rank: 1 - dim: [[1, k]] - categorical_labels(NX_CHAR): - exists: optional - doc: | - Categorical label(s) for each target (member in the set) aka cluster name(s). - dimensions: - rank: 1 - dim: [[1, k]] - weights(NX_NUMBER): - exists: optional - unit: NX_UNITLESS - doc: | - Weights for each target that specifies how probable the target is assigned to - a specific cluster. - - For the DBScan algorithm and atom probe tomography this value is the - multiplicity of each ion with respect to the cluster. That is how many times - should the position of the ion be accounted for because the ion is e.g. a - molecular ion with several elements or nuclides of requested type. - dimensions: - rank: 1 - dim: [[1, k]] - - # number_of_objects(NX_UINT): - # bitdepth(NX_UINT): - # mask(NX_UINT): - is_noise(NX_BOOLEAN): - exists: optional - doc: | - Are targets assigned to the noise category or not. - dimensions: - rank: 1 - dim: [[1, k]] - - # number_of_objects(NX_UINT): - # bitdepth(NX_UINT): - # mask(NX_UINT): - is_core(NX_BOOLEAN): - exists: optional - doc: | - Are targets assumed a core point. - dimensions: - rank: 1 - dim: [[1, k]] - statistics(NXprocess): - exists: recommended - doc: | - In addition to the detailed storage which members were grouped to which - feature here summary statistics are stored that communicate e.g. how many - cluster were found. - - # at the level of the set of targets - number_of_targets(NX_UINT): - doc: | - Total number of targets in the set, i.e. ions that were filtered - and considered in this cluster analysis. - number_of_noise(NX_UINT): - unit: NX_UNITLESS - doc: | - Total number of members in the set which are categorized as noise. - number_of_core(NX_UINT): - unit: NX_UNITLESS - doc: | - Total number of members in the set which are categorized as a core point. - number_of_features(NX_UINT): - unit: NX_UNITLESS - doc: | - Total number of clusters (excluding noise and unassigned). - - # at the level of the feature set - feature_identifier(NX_UINT): - unit: NX_UNITLESS - doc: | - Numerical identifier of each feature aka cluster_identifier. - dimensions: - rank: 1 - dim: [[1, n_feat]] - feature_member_count(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of members for each feature. - dimensions: - rank: 1 - dim: [[1, n_feat]] - - # ADD FURTHER RESULTS along the same pattern for e.g. OPTICS and HDBSCAN - common(NXapm_paraprobe_tool_common): - status(NX_CHAR): - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - profiling(NXcs_profiling): - exists: recommended - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - total_elapsed_time(NX_FLOAT): - current_working_directory(NX_CHAR): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - userID(NXuser): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - If used, metadata of at least the person who performed this analysis. - name(NX_CHAR): - coordinate_system_set(NXcoordinate_system_set): - exists: ['min', '1', 'max', '1'] - paraprobe(NXcoordinate_system): - type(NX_CHAR): - handedness(NX_CHAR): - x(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - y(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - z(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 33ed22efaa12bfb8b3513ac2cabdc684c13ea3e57df905aa3331228f9515991e -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The total number of ions in the reconstruction. -# -# -# -# -# Number of clusters found. -# -# -# -# -# Application definition for results files of the paraprobe-spatstat tool. -# -# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Results of a DBScan clustering analysis. -# -# -# -# The epsilon (eps) parameter used. -# -# -# -# -# The minimum points (min_pts) parameter used. -# -# -# -# -# Number of members in the set which is partitioned into features. -# Specifically, this is the total number of targets filtered from the -# dataset, i.e. typically the number of clusters which is usually not and -# for sure not necessarily the total number of ions in the dataset. -# -# -# -# -# Which identifier is the first to be used to label a cluster. -# -# The value should be chosen in such a way that special values can be resolved: -# * identifier_offset - 1 indicates an object belongs to no cluster. -# * identifier_offset - 2 indicates an object belongs to the noise category. -# -# Setting for instance identifier_offset to 1 recovers the commonly used -# case that objects of the noise category get the value of -1 and points of the -# unassigned category get the value 0. -# -# -# -# -# The evaporation (sequence) identifier (aka evaporation_id) to figure out -# which ions from the reconstruction were considered targets. The length -# of this array is not necessarily n_ions. -# Instead, it is the value of cardinality. -# -# -# -# -# -# -# -# -# The number of solutions found for each target. Typically, -# this value is 1 in which case the field can be omitted. -# Otherwise, this array is the concatenated set of values of solution -# tuples for each target that can be used to decode model_labels, -# core_sample_indices, and weight. -# -# -# -# -# -# -# -# The raw labels from the DBScan clustering backend process. -# The length of this array is not necessarily n_ions. -# Instead, it is typically the value of cardinality provided that each -# target has only one associated cluster. If targets are assigned to -# multiple cluster this array is as long as the total number of solutions -# found and -# -# -# -# -# -# -# -# The raw array of core sample indices which specify which of the -# targets are core points. -# -# -# -# -# -# -# -# Numerical label for each target (member in the set) aka cluster identifier. -# -# -# -# -# -# -# -# Categorical label(s) for each target (member in the set) aka cluster name(s). -# -# -# -# -# -# -# -# Weights for each target that specifies how probable the target is assigned to -# a specific cluster. -# -# For the DBScan algorithm and atom probe tomography this value is the -# multiplicity of each ion with respect to the cluster. That is how many times -# should the position of the ion be accounted for because the ion is e.g. a -# molecular ion with several elements or nuclides of requested type. -# -# -# -# -# -# -# -# -# Are targets assigned to the noise category or not. -# -# -# -# -# -# -# -# -# Are targets assumed a core point. -# -# -# -# -# -# -# -# In addition to the detailed storage which members were grouped to which -# feature here summary statistics are stored that communicate e.g. how many -# cluster were found. -# -# -# -# -# Total number of targets in the set, i.e. ions that were filtered -# and considered in this cluster analysis. -# -# -# -# -# Total number of members in the set which are categorized as noise. -# -# -# -# -# Total number of members in the set which are categorized as a core point. -# -# -# -# -# Total number of clusters (excluding noise and unassigned). -# -# -# -# -# -# Numerical identifier of each feature aka cluster_identifier. -# -# -# -# -# -# -# -# Number of members for each feature. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If used, metadata of at least the person who performed this analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml deleted file mode 100644 index 15119e8f8b..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml +++ /dev/null @@ -1,370 +0,0 @@ -category: application -doc: | - Application definition for a configuration file of the paraprobe-distancer tool. - - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXapm_paraprobe_distancer_config(NXobject): - (NXentry): - exists: ['min', '1', 'max', '1'] - definition(NX_CHAR): - \@version: - type: NX_CHAR - enumeration: [NXapm_paraprobe_distancer_config] - point_to_triangle(NXapm_paraprobe_tool_config): - exists: ['min', '1', 'max', '1'] - (NXidentifier): - exists: optional - analysis_identifier(NX_UINT): - exists: recommended - reconstruction(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - position(NX_CHAR): - mass_to_charge(NX_CHAR): - ranging(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - ranging_definitions(NX_CHAR): - - # filter that are here tool-specific parameter - spatial_filter(NXspatial_filter): - windowing_method(NX_CHAR): - hexahedron_set(NXcg_hexahedron_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - hexahedra(NXcg_face_list_data_structure): - vertices(NX_UINT): - cylinder_set(NXcg_cylinder_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - height(NX_NUMBER): - radii(NX_NUMBER): - ellipsoid_set(NXcg_ellipsoid_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - half_axes_radii(NX_NUMBER): - orientation(NX_NUMBER): - polyhedron_set(NXcg_polyhedron_set): - exists: optional - - # TODO - bitmask(NXcs_filter_boolean_mask): - exists: optional - number_of_objects(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - - # leave open if scalar or matrix - # dim: (i,) - identifier(NX_UINT): - evaporation_id_filter(NXsubsampling_filter): - exists: optional - min_incr_max(NX_INT): - iontype_filter(NXmatch_filter): - exists: optional - method(NX_CHAR): - match(NX_NUMBER): - hit_multiplicity_filter(NXmatch_filter): - exists: optional - method(NX_CHAR): - match(NX_NUMBER): - - # config - method(NX_CHAR): - doc: | - Specifies for which point the tool will compute distances. - - The value *default* configures that distances are computed for all points. - The value *skin* configures that distances are computed only for those - points which are not farther away located to a triangle than - threshold_distance. - enumeration: [default, skin] - threshold_distance(NX_FLOAT): - exists: optional - unit: NX_LENGTH - doc: | - Maximum distance for which distances are - computed when *method* is *skin*. - - # nm - number_of_triangle_sets(NX_UINT): - unit: NX_UNITLESS - doc: | - How many triangle sets to consider. - Multiple triangle sets can be defined which are - composed into one joint triangle set for the analysis. - triangle_setID(NXserialized): - exists: ['min', '1', 'max', 'unbounded'] - doc: | - Each triangle_set that is referred to here should be a face_list_data_structure, - i.e. an array of (n_vertices, 3) of NX_FLOAT for vertex coordinates, an (n_facets, 3) - array of NX_UINT incident vertices of each facet. Vertex indices are assumed to - start at zero and must not exceed n_vertices - 1, i.e. the identifier_offset is 0. - Facet normal have to be provided as an array of (n_facets, 3) of NX_FLOAT. - type(NX_CHAR): - algorithm(NX_CHAR): - checksum(NX_CHAR): - path(NX_CHAR): - vertices(NX_CHAR): - doc: | - Absolute path in the (HDF5) file that points to the array - of vertex positions for the triangles in that triangle_set. - indices(NX_CHAR): - doc: | - Absolute path in the (HDF5) file that points to the array - of vertex indices for the triangles in that triangle_set. - vertex_normals(NX_CHAR): - exists: optional - doc: | - Absolute path in the (HDF5) file that points to the array - of vertex normal vectors for the triangles in that triangle_set. - face_normals(NX_CHAR): - exists: optional - doc: | - Absolute path in the (HDF5) file that points to the array - of facet normal vectors for the triangles in that triangle_set. - patch_identifier(NX_CHAR): - exists: optional - doc: | - Absolute path in the (HDF5) file that points to the array - of identifier for the triangles in that triangle_set. - patch_filter(NXmatch_filter): - exists: optional - method(NX_CHAR): - match(NX_NUMBER): - - # point_set_to_polyline_set(NXapm_paraprobe_tool_config): - common(NXapm_paraprobe_tool_common): - status(NX_CHAR): - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - profiling(NXcs_profiling): - exists: recommended - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - total_elapsed_time(NX_FLOAT): - current_working_directory(NX_CHAR): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 37318b17128a037d6a25bbf554600d3dde6833d30c12508242205c3465f55d18 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Application definition for a configuration file of the paraprobe-distancer tool. -# -# This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Specifies for which point the tool will compute distances. -# -# The value *default* configures that distances are computed for all points. -# The value *skin* configures that distances are computed only for those -# points which are not farther away located to a triangle than -# threshold_distance. -# -# -# -# -# -# -# -# -# Maximum distance for which distances are -# computed when *method* is *skin*. -# -# -# -# -# -# How many triangle sets to consider. -# Multiple triangle sets can be defined which are -# composed into one joint triangle set for the analysis. -# -# -# -# -# Each triangle_set that is referred to here should be a face_list_data_structure, -# i.e. an array of (n_vertices, 3) of NX_FLOAT for vertex coordinates, an (n_facets, 3) -# array of NX_UINT incident vertices of each facet. Vertex indices are assumed to -# start at zero and must not exceed n_vertices - 1, i.e. the identifier_offset is 0. -# Facet normal have to be provided as an array of (n_facets, 3) of NX_FLOAT. -# -# -# -# -# -# -# -# Absolute path in the (HDF5) file that points to the array -# of vertex positions for the triangles in that triangle_set. -# -# -# -# -# Absolute path in the (HDF5) file that points to the array -# of vertex indices for the triangles in that triangle_set. -# -# -# -# -# Absolute path in the (HDF5) file that points to the array -# of vertex normal vectors for the triangles in that triangle_set. -# -# -# -# -# Absolute path in the (HDF5) file that points to the array -# of facet normal vectors for the triangles in that triangle_set. -# -# -# -# -# Absolute path in the (HDF5) file that points to the array -# of identifier for the triangles in that triangle_set. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml deleted file mode 100644 index 4243697265..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml +++ /dev/null @@ -1,366 +0,0 @@ -category: application -doc: | - Application definition for results files of the paraprobe-distancer tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. - The paraprobe-distancer tool can be used for the computing of the shortest Euclidean distance for each - member of a set of points against a set of triangles. In contrast to most approaches in atom probe where the - distance is computed as the projected distance, this tool evaluates robustly the exact distance between - a point and a triangle. - - Triangles can represent for instance the facets of a triangulated surface mesh like those returned by - paraprobe-surfacer or any other set of triangles. Triangles do not have to be connected. - - Currently, paraprobe-distancer does not check if the respectively specified triangle sets are consistent, - what their topology is, or whether or not these triangles are consistently oriented. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_ions: | - The total number of points, i.e. ions in the reconstruction. - n_tri: | - The total number of triangles in the set. -type: group -NXapm_paraprobe_distancer_results(NXobject): - (NXentry): - exists: ['min', '1', 'max', '1'] - definition(NX_CHAR): - \@version: - type: NX_CHAR - enumeration: [NXapm_paraprobe_distancer_results] - - # tasks - point_to_triangle(NXapm_paraprobe_tool_results): - exists: ['min', '1', 'max', '1'] - - # config - analysis_identifier(NX_UINT): - config(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - window(NXcs_filter_boolean_mask): - number_of_ions(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - - # results - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - The shortest analytical distance of each point to their - respectively closest triangle from the joint triangle set. - dimensions: - rank: 1 - dim: [[1, n_ions]] - triangle_identifier(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - For each point the identifier of the triangle for which the - shortest distance was found - dimensions: - rank: 1 - dim: [[1, n_ions]] - point_identifier(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - A support field to enable the visualization of each point - by an explicit identifier on the interval [0, n_ions - 1]. - The field can be used to visualize the points as a function - of their distance to the triangle set (e.g. via XDMF/Paraview). - dimensions: - rank: 1 - dim: [[1, n_ions]] - sign_valid(NXcs_filter_boolean_mask): - exists: optional - doc: | - A bitmask that identifies which of the distance values is - assumed to have a consistent sign because the closest - triangle had a consistent outer unit normal defined. - - For points whose bit is set to 0 the distance is correct - but the sign is not reliable. - number_of_triangles(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of triangles covered by the mask. - bitdepth(NX_UINT): - unit: NX_UNITLESS - doc: | - Bitdepth of the elementary datatype that is used to store - the information content of the mask (typically 8 bit, uint8). - mask(NX_UINT): - unit: NX_UNITLESS - doc: | - The content of the mask. Like for all masks used in the tools - of the paraprobe-toolbox, padding is used when number_of_objects - is not an integer multiple of bitdepth. If padding is used, - padded bits are set to 0. - dimensions: - rank: 1 - dim: [[1, n_ions]] - window_triangles(NXcs_filter_boolean_mask): - exists: optional - doc: | - A bitmask that identifies which of the triangles in the set were - considered when certain triangles have been filtered out. - number_of_objects(NX_UINT): - bitdepth(NX_UINT): - - # the following field shows a good example of base class inheritance used, - # the field mask of the NXcs_filter_boolean_mask is inherited that means its docstring, - # its unit category only the dimensions are constrained strong to match the number of objects - # triangles in this case - mask(NX_UINT): - dimensions: - rank: 1 - dim: [[1, n_tri]] - common(NXapm_paraprobe_tool_common): - status(NX_CHAR): - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - profiling(NXcs_profiling): - exists: recommended - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - total_elapsed_time(NX_FLOAT): - current_working_directory(NX_CHAR): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - userID(NXuser): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - If used, metadata of at least the person who performed this analysis. - name(NX_CHAR): - coordinate_system_set(NXcoordinate_system_set): - exists: ['min', '1', 'max', '1'] - paraprobe(NXcoordinate_system): - type(NX_CHAR): - handedness(NX_CHAR): - x(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - y(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - z(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# ebd0e335a279b791dad8613cf2d80ffcc3a32d2d7a08d6ec6fbeae3497414275 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The total number of points, i.e. ions in the reconstruction. -# -# -# -# -# The total number of triangles in the set. -# -# -# -# -# Application definition for results files of the paraprobe-distancer tool. -# -# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. -# The paraprobe-distancer tool can be used for the computing of the shortest Euclidean distance for each -# member of a set of points against a set of triangles. In contrast to most approaches in atom probe where the -# distance is computed as the projected distance, this tool evaluates robustly the exact distance between -# a point and a triangle. -# -# Triangles can represent for instance the facets of a triangulated surface mesh like those returned by -# paraprobe-surfacer or any other set of triangles. Triangles do not have to be connected. -# -# Currently, paraprobe-distancer does not check if the respectively specified triangle sets are consistent, -# what their topology is, or whether or not these triangles are consistently oriented. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The shortest analytical distance of each point to their -# respectively closest triangle from the joint triangle set. -# -# -# -# -# -# -# -# For each point the identifier of the triangle for which the -# shortest distance was found -# -# -# -# -# -# -# -# A support field to enable the visualization of each point -# by an explicit identifier on the interval [0, n_ions - 1]. -# The field can be used to visualize the points as a function -# of their distance to the triangle set (e.g. via XDMF/Paraview). -# -# -# -# -# -# -# -# A bitmask that identifies which of the distance values is -# assumed to have a consistent sign because the closest -# triangle had a consistent outer unit normal defined. -# -# For points whose bit is set to 0 the distance is correct -# but the sign is not reliable. -# -# -# -# Number of triangles covered by the mask. -# -# -# -# -# Bitdepth of the elementary datatype that is used to store -# the information content of the mask (typically 8 bit, uint8). -# -# -# -# -# The content of the mask. Like for all masks used in the tools -# of the paraprobe-toolbox, padding is used when number_of_objects -# is not an integer multiple of bitdepth. If padding is used, -# padded bits are set to 0. -# -# -# -# -# -# -# -# -# A bitmask that identifies which of the triangles in the set were -# considered when certain triangles have been filtered out. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If used, metadata of at least the person who performed this analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml deleted file mode 100644 index 103ade8d25..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml +++ /dev/null @@ -1,488 +0,0 @@ -category: application -doc: | - Application definition for a configuration file of the paraprobe-intersector tool. - - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_variable: | - Number of entries -type: group -NXapm_paraprobe_intersector_config(NXobject): - (NXentry): - exists: ['min', '1', 'max', '1'] - definition(NX_CHAR): - \@version: - type: NX_CHAR - enumeration: [NXapm_paraprobe_intersector_config] - number_of_tasks(NX_UINT): - unit: NX_UNITLESS - doc: | - How many v_v_spatial_correlation tasks should the tool execute. - v_v_spatial_correlationID(NXapm_paraprobe_tool_config): - exists: ['min', '1', 'max', 'unbounded'] - doc: | - Tracking volume_volume_spatial_correlations (v_v) is the process of building logical - relations between objects, their proximity and eventual volumetric intersections. - Here, objects are assumed to be represented as a set of triangulated surface meshes. - - Volumetric overlap and proximity of volumetric features is identified for members of - sets of features to members of other sets of volumetric features. Specifically, for each time - step :math:`k` pairs of sets are compared: - Members of a so-called current_set to members of a so-called next_set. - Members can be different types of volumetric features. - - # config - intersection_detection_method(NX_CHAR): - doc: | - Specifies the method whereby to decide if two objects intersect volumetrically. - For reasons which are detailed in the supplementary material of `M. Kühbach et al. `_, - it is assumed by default that two objects intersect if they share at least one ion with the same evaporation ID (shared_ion). - - Alternatively, with specifying tetrahedra_intersections, the tool can perform an intersection analysis which attempts to - tetrahedralize first each polyhedron. If successful, the tool then checks for at least one pair of intersecting tetrahedra - to identify if two objects intersect or not. However, we found that these geometrical analyses can result in corner - cases which the tetrahedralization library used in the tests (TetGen) was not unable to tetrahedralize successfully. - These cases were virtually always associated with complicated non-convex polyhedra which had portions - of the mesh that were connected by almost point like tubes of triangles. - - Finding more robust methods for computing intersections between not necessarily convex polyhedra might improve - the situation in the future. For practical reasons we have thus deactivated the functionality of tetrahedra-tetrahedron - intersections in paraprobe-intersector. - enumeration: [shared_ion] - analyze_intersection(NX_BOOLEAN): - doc: | - Specifies if the tool evaluates if objects intersect volumetrically. - analyze_proximity(NX_BOOLEAN): - doc: | - Specifies if the tool evaluates if objects lay closer to one another than - threshold_proximity. - analyze_coprecipitation(NX_BOOLEAN): - doc: | - Specifies if the tool evaluates, provided that all (preprocessing tasks were successful), how intersecting - or proximity related objects build sub-graphs. This is the feature that was used in `M. Kühbach et al. `_ - for the high-throughput analyses of how many objects are coprecipitates in the sense that they are single, - duplet, triplet, or high-order local groups. - - # For these analyses to work has_object_volume needs to be true. - threshold_proximity(NX_FLOAT): - unit: NX_LENGTH - doc: | - The maximum Euclidean distance between two objects below which they are - considered within proximity. - has_current_to_next_links(NX_BOOLEAN): - doc: | - Specifies if the tool stores the so-called forward relations between nodes representing members of the - current_set to nodes representing members of the next_set. - has_next_to_current_links(NX_BOOLEAN): - doc: | - Specifies if the tool stores the so-called backward relations between nodes representing members of the - next_set to nodes representing members of the current_set. - current_set(NXobject): - doc: | - Current set stores a set of members, meshes of volumetric features, - which will be checked for proximity and/or volumetric intersection, - to members of the current_set. - The meshes were generated as a result of some other meshing process. - set_identifier(NX_UINT): - unit: NX_ANY - doc: | - This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`k`) - step when the current set was taken (see `M. Kühbach et al. 2022 `_). - - # number_of_objects(NX_UINT) for now a support field to tell the tool how many objects to load. - number_of_feature_types(NX_UINT): - unit: NX_UNITLESS - doc: | - The total number of distinguished feature sets featureID. - It is assumed that the members within all these featureID sets - are representing a set together. As an example this set might represent - all volumetric_features. However, users might have formed - a subset of this set where individuals were regrouped. - For paraprobe-nanochem this is the case for objects and proxies. - Specifically, objects are distinguished further into those far - from and those close to the edge of the dataset. - Similarly, proxies are distinguished further into those far - from and those close to the edge of the dataset. - So while these four sub-sets contain different so-called types of - features, key is that they were all generated for one set, here the - current_set. - featureID(NXserialized): - exists: ['min', '1', 'max', '4'] - doc: | - Name of the (NeXus)/HDF5 file which contains triangulated surface meshes of the - members of the set as instances of NXcg_polyhedron_set. - feature_type(NX_CHAR): - doc: | - Descriptive category explaining what these features are. - enumeration: [objects_far_from_edge, objects_close_to_edge, proxies_far_from_edge, proxies_close_to_edge, other] - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - geometry(NX_CHAR): - doc: | - Absolute path to the group with geometry data in the HDF5 file referred to by - path. - - # currently groupname_geometry_prefix/object/polyhedron. - feature_identifier(NX_UINT): - unit: NX_UNITLESS - doc: | - Array of identifier whereby the path to the geometry data can be interferred - automatically. - dimensions: - rank: 1 - dim: [[1, n_variable]] - next_set(NXobject): - doc: | - Next set stores a set of members, meshes of volumetric features, - which will be checked for proximity and/or volumetric intersection, - to members of the next_set. - The meshes were generated as a result of some other meshing process. - set_identifier(NX_UINT): - unit: NX_ANY - doc: | - This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`k + 1`) - step when the current set was taken (see `M. Kühbach et al. 2022 `_). - - # number_of_objects(NX_UINT) for now a support field to tell the tool how many objects to load. - number_of_feature_types(NX_UINT): - unit: NX_UNITLESS - doc: | - The total number of distinguished feature sets featureID. - It is assumed that the members within all these featureID sets - are representing a set together. As an example this set might represent - all volumetric_features. However, users might have formed - a subset of this set where individuals were regrouped. - For paraprobe-nanochem this is the case for objects and proxies. - Specifically, objects are distinguished further into those far - from and those close to the edge of the dataset. - Similarly, proxies are distinguished further into those far - from and those close to the edge of the dataset. - So while these four sub-sets contain different so-called types of - features key is that they were all generated for one set, here the - next_set. - featureID(NXserialized): - exists: ['min', '1', 'max', '4'] - feature_type(NX_CHAR): - doc: | - Descriptive category explaining what these features are. - enumeration: [objects_far_from_edge, objects_close_to_edge, proxies_far_from_edge, proxies_close_to_edge] - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - geometry(NX_CHAR): - doc: | - Absolute path to the group with geometry data in the HDF5 file referred to by - path. - - # currently groupname_geometry_prefix/object/polyhedron. - feature_identifier(NX_UINT): - unit: NX_UNITLESS - doc: | - Array of identifier whereby the path to the geometry data can be interferred - automatically. - dimensions: - rank: 1 - dim: [[1, n_variable]] - - #MK::tetrahedra volume intersection and tessellation and Nef polyhedra intersection are considered guru features - # and therefore currently supported only via modifying the C/C++ source code directly as one should know exactly - # what one is doing here before using these functionalities - common(NXapm_paraprobe_tool_common): - status(NX_CHAR): - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - profiling(NXcs_profiling): - exists: recommended - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - total_elapsed_time(NX_FLOAT): - current_working_directory(NX_CHAR): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 5db3ee30d69765138706932c89c9f8b512b8f6293f3f7240106d81d3322a34dd -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of entries -# -# -# -# -# Application definition for a configuration file of the paraprobe-intersector tool. -# -# This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. -# -# -# -# -# -# -# -# -# -# -# How many v_v_spatial_correlation tasks should the tool execute. -# -# -# -# -# Tracking volume_volume_spatial_correlations (v_v) is the process of building logical -# relations between objects, their proximity and eventual volumetric intersections. -# Here, objects are assumed to be represented as a set of triangulated surface meshes. -# -# Volumetric overlap and proximity of volumetric features is identified for members of -# sets of features to members of other sets of volumetric features. Specifically, for each time -# step :math:`k` pairs of sets are compared: -# Members of a so-called current_set to members of a so-called next_set. -# Members can be different types of volumetric features. -# -# -# -# -# Specifies the method whereby to decide if two objects intersect volumetrically. -# For reasons which are detailed in the supplementary material of `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_, -# it is assumed by default that two objects intersect if they share at least one ion with the same evaporation ID (shared_ion). -# -# Alternatively, with specifying tetrahedra_intersections, the tool can perform an intersection analysis which attempts to -# tetrahedralize first each polyhedron. If successful, the tool then checks for at least one pair of intersecting tetrahedra -# to identify if two objects intersect or not. However, we found that these geometrical analyses can result in corner -# cases which the tetrahedralization library used in the tests (TetGen) was not unable to tetrahedralize successfully. -# These cases were virtually always associated with complicated non-convex polyhedra which had portions -# of the mesh that were connected by almost point like tubes of triangles. -# -# Finding more robust methods for computing intersections between not necessarily convex polyhedra might improve -# the situation in the future. For practical reasons we have thus deactivated the functionality of tetrahedra-tetrahedron -# intersections in paraprobe-intersector. -# -# -# -# -# -# -# -# Specifies if the tool evaluates if objects intersect volumetrically. -# -# -# -# -# Specifies if the tool evaluates if objects lay closer to one another than -# threshold_proximity. -# -# -# -# -# Specifies if the tool evaluates, provided that all (preprocessing tasks were successful), how intersecting -# or proximity related objects build sub-graphs. This is the feature that was used in `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_ -# for the high-throughput analyses of how many objects are coprecipitates in the sense that they are single, -# duplet, triplet, or high-order local groups. -# -# -# -# -# -# The maximum Euclidean distance between two objects below which they are -# considered within proximity. -# -# -# -# -# Specifies if the tool stores the so-called forward relations between nodes representing members of the -# current_set to nodes representing members of the next_set. -# -# -# -# -# Specifies if the tool stores the so-called backward relations between nodes representing members of the -# next_set to nodes representing members of the current_set. -# -# -# -# -# Current set stores a set of members, meshes of volumetric features, -# which will be checked for proximity and/or volumetric intersection, -# to members of the current_set. -# The meshes were generated as a result of some other meshing process. -# -# -# -# This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`k`) -# step when the current set was taken (see `M. Kühbach et al. 2022 <https://arxiv.org/abs/2205.13510>`_). -# -# -# -# -# -# The total number of distinguished feature sets featureID. -# It is assumed that the members within all these featureID sets -# are representing a set together. As an example this set might represent -# all volumetric_features. However, users might have formed -# a subset of this set where individuals were regrouped. -# For paraprobe-nanochem this is the case for objects and proxies. -# Specifically, objects are distinguished further into those far -# from and those close to the edge of the dataset. -# Similarly, proxies are distinguished further into those far -# from and those close to the edge of the dataset. -# So while these four sub-sets contain different so-called types of -# features, key is that they were all generated for one set, here the -# current_set. -# -# -# -# -# Name of the (NeXus)/HDF5 file which contains triangulated surface meshes of the -# members of the set as instances of NXcg_polyhedron_set. -# -# -# -# Descriptive category explaining what these features are. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Absolute path to the group with geometry data in the HDF5 file referred to by -# path. -# -# -# -# -# -# Array of identifier whereby the path to the geometry data can be interferred -# automatically. -# -# -# -# -# -# -# -# -# -# Next set stores a set of members, meshes of volumetric features, -# which will be checked for proximity and/or volumetric intersection, -# to members of the next_set. -# The meshes were generated as a result of some other meshing process. -# -# -# -# This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`k + 1`) -# step when the current set was taken (see `M. Kühbach et al. 2022 <https://arxiv.org/abs/2205.13510>`_). -# -# -# -# -# -# The total number of distinguished feature sets featureID. -# It is assumed that the members within all these featureID sets -# are representing a set together. As an example this set might represent -# all volumetric_features. However, users might have formed -# a subset of this set where individuals were regrouped. -# For paraprobe-nanochem this is the case for objects and proxies. -# Specifically, objects are distinguished further into those far -# from and those close to the edge of the dataset. -# Similarly, proxies are distinguished further into those far -# from and those close to the edge of the dataset. -# So while these four sub-sets contain different so-called types of -# features key is that they were all generated for one set, here the -# next_set. -# -# -# -# -# -# Descriptive category explaining what these features are. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Absolute path to the group with geometry data in the HDF5 file referred to by -# path. -# -# -# -# -# -# Array of identifier whereby the path to the geometry data can be interferred -# automatically. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml deleted file mode 100644 index fc74463849..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml +++ /dev/null @@ -1,489 +0,0 @@ -category: application -doc: | - Application definition for results files of the paraprobe-intersector tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_c2n: | - The total number of links pointing from current to next. - n_n2c: | - The total number of links pointing from next to current. - n_features_curr: | - The total number of members in the current_set. - n_features_next: | - The total number of members in the next_set. - n_cluster: | - The total number of cluster found for coprecipitation analysis. - n_total: | - The number of rows in the table/matrix for coprecipitation statistics. -type: group -NXapm_paraprobe_intersector_results(NXobject): - (NXentry): - exists: ['min', '1', 'max', '1'] - definition(NX_CHAR): - \@version: - type: NX_CHAR - enumeration: [NXapm_paraprobe_intersector_results] - - # tasks - v_v_spatial_correlation(NXapm_paraprobe_tool_results): - exists: ['min', '0', 'max', '1'] - doc: | - The results of an overlap/intersection analysis. - - # results - current_to_next_link(NX_UINT): - unit: NX_UNITLESS - doc: | - A matrix of feature_identifier that specifies which named features - from the current_set have directed link(s) pointing to which named - feature(s) from the next_set. - dimensions: - rank: 2 - dim: [[1, n_c2n], [2, 2]] - current_to_next_link_type(NX_UINT): - unit: NX_UNITLESS - doc: | - For each link/pair in current_to_next a characterization whether the - link is due to volumetric overlap (0x00 == 0), proximity (0x01 == 1), - or something else unknown (0xFF == 255). - dimensions: - rank: 1 - dim: [[1, n_c2n]] - next_to_current_link(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - A matrix of feature_identifier which specifies which named feature(s) - from the next_set have directed link(s) pointing to which named - feature(s) from the current_set. Only if the mapping whereby the - links are defined is symmetric it holds that next_to_current maps - the links for current_to_next in just the opposite direction. - dimensions: - rank: 2 - dim: [[1, n_n2c], [2, 2]] - next_to_current_link_type(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - For each link/pair in next_to_current a characterization whether the - link is due to a volumetric overlap (0x00 == 0), proximity (0x01 == 1), - or something else unknown (0xFF == 255). - dimensions: - rank: 1 - dim: [[1, n_n2c]] - intersection_volume(NX_FLOAT): - exists: optional - unit: NX_VOLUME - doc: | - For each pair of links in current_to_next the volume of the - intersection, i.e. how much volume do the two features share. - If features do not intersect the volume is zero. - dimensions: - rank: 1 - dim: [[1, n_c2n]] - coprecipitation_analysis(NXprocess): - exists: optional - doc: | - During coprecipitation analysis the current and next set are analyzed - for links in a special way. Three set comparisons are made. Members - of the set in each comparison are analyzed for overlap and proximity: - - The first comparison is the current_set against the current_set. - The second comparison is the next_set against the next_set. - The third comparison is the current_set against the next_set. - - Once the (forward) links for these comparisons are ready, pair relations - are analyzed with respect to which objects with feature_identifier(s) - cluster in identifier space. Thereby, a logical connection (link) is - established between the features in the current_set and the next_set. - Recall that these two sets typically represent different features - within an observed system for otherwise the same parameterization. - - Examples include two sets of e.g. precipitates with differing - chemical composition that were characterized in the same material - volume representing a snapshot of an e.g. microstructure at the same - point in time. Researchers may have performed two analyses, one to - characterize precipitates A and another one for percipitates B. - - Coprecipitation analysis now logically connects these independent - characterization results to establish spatial correlations of e.g. - the precipitates' spatial arrangement. - current_set_feature_to_cluster(NX_UINT): - unit: NX_UNITLESS - doc: | - Matrix of feature_identifier and cluster_identifier pairs which - encodes the cluster to which each feature_identifier was assigned. - Here for features of the current_set. - dimensions: - rank: 2 - dim: [[1, n_features_curr], [2, 2]] - next_set_feature_to_cluster(NX_UINT): - unit: NX_UNITLESS - doc: | - Matrix of feature_identifier and cluster_identifier pairs which - encodes the cluster to which each feature_identifier was assigned. - Here for features of the next_set. - dimensions: - rank: 2 - dim: [[1, n_features_next], [2, 2]] - cluster_identifier(NX_UINT): - unit: NX_UNITLESS - doc: | - The identifier (names) of the cluster. - dimensions: - rank: 1 - dim: [[1, n_cluster]] - cluster_composition(NX_UINT): - unit: NX_UNITLESS - doc: | - Pivot table as a matrix. - The first column encodes how many members from the current_set - are in each cluster, one row per cluster. - - The second column encodes how many members from the next_set - are in each cluster, in the same row per cluster respectively. - - The third column encodes the total number of members in the cluster. - dimensions: - rank: 2 - dim: [[1, n_cluster], [2, 3]] - cluster_statistics(NX_UINT): - unit: NX_UNITLESS - doc: | - Pivot table as a matrix. - - The first column encodes the different types of - clusters based on their number of members in the sub-graph. - - The second column encodes how many clusters with - as many members exist. - dimensions: - rank: 2 - dim: [[1, n_total], [2, 2]] - common(NXapm_paraprobe_tool_common): - status(NX_CHAR): - analysis_identifier(NX_UINT): - config(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - profiling(NXcs_profiling): - exists: recommended - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - total_elapsed_time(NX_FLOAT): - current_working_directory(NX_CHAR): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - userID(NXuser): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - If used, metadata of at least the person who performed this analysis. - name(NX_CHAR): - coordinate_system_set(NXcoordinate_system_set): - exists: ['min', '1', 'max', '1'] - paraprobe(NXcoordinate_system): - type(NX_CHAR): - handedness(NX_CHAR): - x(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - y(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - z(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 7bb9384d9681949480b17595ec20b236caad5ff57e50895ec7cf2e514c51cbb9 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The total number of links pointing from current to next. -# -# -# -# -# The total number of links pointing from next to current. -# -# -# -# -# The total number of members in the current_set. -# -# -# -# -# The total number of members in the next_set. -# -# -# -# -# The total number of cluster found for coprecipitation analysis. -# -# -# -# -# The number of rows in the table/matrix for coprecipitation statistics. -# -# -# -# -# Application definition for results files of the paraprobe-intersector tool. -# -# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. -# -# -# -# -# -# -# -# -# -# -# -# The results of an overlap/intersection analysis. -# -# -# -# -# A matrix of feature_identifier that specifies which named features -# from the current_set have directed link(s) pointing to which named -# feature(s) from the next_set. -# -# -# -# -# -# -# -# -# For each link/pair in current_to_next a characterization whether the -# link is due to volumetric overlap (0x00 == 0), proximity (0x01 == 1), -# or something else unknown (0xFF == 255). -# -# -# -# -# -# -# -# A matrix of feature_identifier which specifies which named feature(s) -# from the next_set have directed link(s) pointing to which named -# feature(s) from the current_set. Only if the mapping whereby the -# links are defined is symmetric it holds that next_to_current maps -# the links for current_to_next in just the opposite direction. -# -# -# -# -# -# -# -# -# For each link/pair in next_to_current a characterization whether the -# link is due to a volumetric overlap (0x00 == 0), proximity (0x01 == 1), -# or something else unknown (0xFF == 255). -# -# -# -# -# -# -# -# For each pair of links in current_to_next the volume of the -# intersection, i.e. how much volume do the two features share. -# If features do not intersect the volume is zero. -# -# -# -# -# -# -# -# During coprecipitation analysis the current and next set are analyzed -# for links in a special way. Three set comparisons are made. Members -# of the set in each comparison are analyzed for overlap and proximity: -# -# The first comparison is the current_set against the current_set. -# The second comparison is the next_set against the next_set. -# The third comparison is the current_set against the next_set. -# -# Once the (forward) links for these comparisons are ready, pair relations -# are analyzed with respect to which objects with feature_identifier(s) -# cluster in identifier space. Thereby, a logical connection (link) is -# established between the features in the current_set and the next_set. -# Recall that these two sets typically represent different features -# within an observed system for otherwise the same parameterization. -# -# Examples include two sets of e.g. precipitates with differing -# chemical composition that were characterized in the same material -# volume representing a snapshot of an e.g. microstructure at the same -# point in time. Researchers may have performed two analyses, one to -# characterize precipitates A and another one for percipitates B. -# -# Coprecipitation analysis now logically connects these independent -# characterization results to establish spatial correlations of e.g. -# the precipitates' spatial arrangement. -# -# -# -# Matrix of feature_identifier and cluster_identifier pairs which -# encodes the cluster to which each feature_identifier was assigned. -# Here for features of the current_set. -# -# -# -# -# -# -# -# -# Matrix of feature_identifier and cluster_identifier pairs which -# encodes the cluster to which each feature_identifier was assigned. -# Here for features of the next_set. -# -# -# -# -# -# -# -# -# The identifier (names) of the cluster. -# -# -# -# -# -# -# -# Pivot table as a matrix. -# The first column encodes how many members from the current_set -# are in each cluster, one row per cluster. -# -# The second column encodes how many members from the next_set -# are in each cluster, in the same row per cluster respectively. -# -# The third column encodes the total number of members in the cluster. -# -# -# -# -# -# -# -# -# Pivot table as a matrix. -# -# The first column encodes the different types of -# clusters based on their number of members in the sub-graph. -# -# The second column encodes how many clusters with -# as many members exist. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If used, metadata of at least the person who performed this analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml deleted file mode 100644 index 07ceb65500..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml +++ /dev/null @@ -1,1906 +0,0 @@ -category: application -doc: | - Application definition for a configuration file of the paraprobe-nanochem tool. - - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_ityp_deloc_cand: | - How many iontypes does the delocalization filter specify. - n_grid: | - How many grid_resolutions values. - n_var: | - How many kernel_variance values. - n_control_pts: | - How many disjoint control points are defined. - n_fct_filter_cand: | - How many iontypes does the interface meshing iontype filter specify. - n_fct_iterations: | - How many DCOM iterations. - n_ivec_max: | - Maximum number of atoms per molecular ion. - n_rois: | - Number of cylinder ROIs to place for oned_profile if no feature mesh is used. -type: group -NXapm_paraprobe_nanochem_config(NXobject): - (NXentry): - exists: ['min', '1', 'max', '1'] - definition(NX_CHAR): - \@version: - type: NX_CHAR - enumeration: [NXapm_paraprobe_nanochem_config] - delocalization(NXapm_paraprobe_tool_config): - exists: ['min', '0', 'max', '1'] - doc: | - Discretization and distributing of the ion point cloud on a 3D grid - to enable continuum-scale analyses. - - By default, the tool computes a full kernel density estimation of decomposed - ions to create one discretized field for each element. - - One delocalization task configures a parameter sweep with at least one - delocalization. The total number of runs depends on the number of - grid_resolution and kernel_variance values. For example, setting two grid_resolutions - and three kernel_variance will compute six runs. Two sets of three with the first set using - the first grid_resolutions and in sequence the kernel_variance respectively. - - # Although, this uses an efficient multithreaded algorithm the computation is costly. - # Therefore, it can be advantageous for users to load an already computed delocalization. - # This can be achieved with the load_existent option. - (NXidentifier): - exists: optional - analysis_identifier(NX_UINT): - exists: recommended - reconstruction(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - position(NX_CHAR): - mass_to_charge(NX_CHAR): - ranging(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - ranging_definitions(NX_CHAR): - surface(NXserialized): - doc: | - A precomputed triangulated surface mesh representing a model (of the surface) - of the edge of the dataset. This model can be used to detect and control - various sources of bias in the analyses. - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - vertices(NX_CHAR): - doc: | - Absolute path in the (HDF5) file that points to the array - of vertex positions for the triangles in that triangle_set. - indices(NX_CHAR): - doc: | - Absolute path in the (HDF5) file that points to the array - of vertex indices for the triangles in that triangle_set. - surface_distance(NXserialized): - exists: recommended - doc: | - Distance between each ion and triangulated surface mesh. - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - distance(NX_CHAR): - spatial_filter(NXspatial_filter): - windowing_method(NX_CHAR): - hexahedron_set(NXcg_hexahedron_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - hexahedra(NXcg_face_list_data_structure): - vertices(NX_UINT): - cylinder_set(NXcg_cylinder_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - height(NX_NUMBER): - radii(NX_NUMBER): - ellipsoid_set(NXcg_ellipsoid_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - half_axes_radii(NX_NUMBER): - orientation(NX_NUMBER): - polyhedron_set(NXcg_polyhedron_set): - exists: optional - - # TODO - bitmask(NXcs_filter_boolean_mask): - exists: optional - number_of_objects(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - - # leave open if scalar or matrix - # dim: (i,) - # identifier(NX_UINT): - evaporation_id_filter(NXsubsampling_filter): - exists: optional - min_incr_max(NX_INT): - iontype_filter(NXmatch_filter): - exists: optional - method(NX_CHAR): - match(NX_NUMBER): - hit_multiplicity_filter(NXmatch_filter): - exists: optional - method(NX_CHAR): - match(NX_NUMBER): - - # config - method(NX_CHAR): - doc: | - Compute delocalization or load an existent one from input. - enumeration: [compute, load_existent] - input(NXserialized): - doc: | - Serialized result of an already computed delocalization which is for performance - reasons here just loaded and not computed again. - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - results(NX_CHAR): - doc: | - Absolute path in the (HDF5) file that points to the group within which - individual delocalization results are stored. - - # TODO: add more descriptions - nuclide_whitelist(NX_UINT): - unit: NX_UNITLESS - doc: | - Matrix of nuclides representing how iontypes should be accounted for during - the delocalization. This is the most general approach to define if and how many - times an ion is to be counted. The tool performs a so-called atomic decomposition - of all iontypes, i.e. the tool analyses from how many atoms of each nuclide - or element respectively an (molecular) ion is built from. - - Taking the hydroxonium H3O+ molecular ion as an example: - It contains hydrogen and oxygen atoms. The multiplicity of hydrogen - is three whereas that of oxygen is one. Therefore, the respective atomic decomposition - analysis prior to the iso-surface computation adds three hydrogen counts for each - H3O+ ion. - - This is a practical solution which accepts that on the one hand not every bond is - broken during an atom probe experiment but also that ions may react further during - their flight to the detector. The exact details depend on the local field conditions, - quantum mechanics of possible electron transfer and thus the detailed trajectory - of the system and its electronic state. - - The detection of molecular ions instead of always single atom ions only is the - reason that an atom probe experiment tells much about field evaporation physics - but also faces an inherent loss of information with respect to the detailed spatial - arrangement that is independent of other imprecisions such as effect of limited - accuracy of reconstruction protocols and their parameterization. - - Unused values in each row of the matrix are nullified. - Nuclides are identified as hashed nuclide (see :ref:`NXion`) for further details. - dimensions: - rank: 2 - dim: [[1, n_ityp_deloc_cand], [2, n_ivec_max]] - grid_resolution(NX_FLOAT): - unit: NX_LENGTH - doc: | - Array of edge lengths of the cubic cells used for discretizing the reconstructed dataset - on a cuboidal 3D grid (:ref:`NXcg_grid`). The tool performs as many delocalization - computations as values are specified in grid_resolution. - dimensions: - rank: 1 - dim: [[1, n_grid]] - kernel_size(NX_UINT): - unit: NX_UNITLESS - doc: | - Half the width of a :math:`{(2 \cdot n + 1)}^3` cubic kernel of cubic voxel - beyond which the Gaussian Ansatz function will be truncated. Intensity outside - the kernel is factorized into the kernel via a normalization procedure. - kernel_variance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Array of variance values :math:`\sigma` of the Gaussian Ansatz kernel - (:math:`\sigma_x := \sigma`, :math:`\sigma_x = \sigma_y = 2 \cdot \sigma_z`). - The tool performs as many delocalization computations as values are specified - in kernel_variance. - dimensions: - rank: 1 - dim: [[1, n_var]] - normalization(NX_CHAR): - doc: | - How should the results of the kernel-density estimation be normalized into quantities. - By default, the tool computes the total number (intensity) of ions or elements. - Alternatively, the tool can compute the total intensity, the composition, - or the concentration of the ions/elements specified by the nuclide_whitelist. - enumeration: [none, composition, concentration] - has_scalar_fields(NX_BOOLEAN): - doc: | - Specifies if the tool should report the delocalization 3D field values. - isosurfacing(NXprocess): - exists: ['min', '0', 'max', '1'] - doc: | - Configuration of the set of iso-surfaces to compute using that delocalization. - Such iso-surfaces are the starting point for a reconstruction of so-called objects or - (microstructual) features. Examples of scientific relevant are (line features e.g. dislocations - poles, surface features such as interfaces, i.e. phase and grain boundaries, or volumetric - features such as precipitates. - Users should be aware that reconstructed datasets in atom probe are a model and may face - inaccuracies and artifacts that can be mistaken incorrectly as microstructural features. - edge_method(NX_CHAR): - doc: | - As it is detailed in `M. Kühbach et al. `_, the handling of - triangles at the surface (edge) of the dataset requires special attention especially for - composition-normalized delocalization. Here, it is possible that the composition - increases towards the edge of the dataset because the quotient of two numbers - that are both smaller than one is larger instead of smaller than the counter. - - By default, the tool uses a modified marching cubes algorithm of Lewiner et al. - which detects if voxels face such a situation. In this case, no triangles are generated - for such voxels. - - Alternatively, keep_edge_triangles instructs the tool to not remove triangles at the - edge of the dataset at the cost of bias. When using this keep_edge_triangles users - should understand that all features in contact with the edge of the dataset get usually - artificial enlarged. Consequently, triangulated surface meshes of these objects are - closed during the marching. However, this closure is artificial and can biased shape - analyses for those objects. This also holds for such practices that are offered in - proprietary software like IVAS / AP Suite. The situation is comparable to analyses - of grain shapes via orientation microscopy from electron microscopy or X-ray - diffraction tomography. Features at the edge of the dataset may have not been - captured fully. - - Thanks to collaboration with V. V. Rielli and S. Primig from the Sydney atom probe group, - paraprobe-nanochem implements a complete pipeline to process features at the edge of the - dataset. Specifically, these are modelled and replaced with closed polyhedral objects using - an iterative mesh and hole-filling procedures with fairing operations. - - The tool bookkeeps such objects separately to lead the decision whether or not to - consider these objects to the user. Users should be aware that results from fairing operations - should be compared to results from analyses where all objects at the edge - of the dataset have been removed. Furthermore, users should be careful with overestimating - the statistical significance of their dataset especially when using atom probe when they - use their atom probe result to compare different descriptors. Even though a dataset may - deliver statistically significant results for compositions, this does not necessarily mean that - same dataset will also yield statistically significant and insignificantly biased results for - 3D object analyses! - - Being able to quantify these effects and making atom probers aware of these subtleties - was one of the main reasons why the paraprobe-nanochem tool was implemented. - enumeration: [default, keep_edge_triangles] - edge_threshold(NX_FLOAT): - unit: NX_LENGTH - doc: | - The ion-to-surface distance that is used in the analyses of features to identify whether - these are laying inside the dataset or close to the surface (edge) of the dataset. - - If an object has at least one ion with an ion-to-surface-distance below this threshold, - the object is considered close to the edge of the dataset. The tool uses a distance-based - approach to solve the in general complicated and involved treatment of computing - volumetric intersections between closed 2-manifolds that are not necessarily convex. - The main practical reason is that such computational geometry analyses face numerical - robustness issues as a consequence of which a mesh can be detected as being completely - inside another mesh although in reality it is only :math:`\epsilon`-close only, i.e. almost - touching only the edge (e.g. from inside). - - Practically, humans would likely still state in such case that the object is close to the - edge of the dataset; however mathematically the object is indeed completely inside. - In short, a distance-based approach is rigorous and flexible. - phi(NX_FLOAT): - unit: NX_ANY - doc: | - Iso-contour values. For each value, the tool computes an iso-surface and performs - subsequent analyses for each iso-surface. The unit depends on the choice for the - normalization of the accumulated ion intensity values per voxel: - - * total, total number of ions, irrespective their iontype - * candidates, total number of ions with type in the isotope_whitelist. - * composition, candidates but normalized by composition, i.e. at.-% - * concentration, candidates but normalized by voxel volume, i.e. ions/nm^3 - has_triangle_soup(NX_BOOLEAN): - doc: | - Specifies if the tool should report the triangle soup which represents each triangle of the - iso-surface complex. The resulting set of triangles is colloquially referred to as a soup - because different sub-set may not be connected. - - Each triangle is reported with an ID specifying to which triangle cluster (with IDs starting at zero) - the triangle belongs. The clustering of triangles within the soup is performed with a - modified DBScan algorithm. - has_object(NX_BOOLEAN): - doc: | - Specifies if the tool should analyze for each cluster of triangles how they can be combinatorially - processed to describe a closed polyhedron. Such a closed polyhedron (not-necessarily convex!) - can be used to describe objects with relevance in the microstructure. - - Users should be aware that the resulting mesh does not necessarily represent the original precipitate. - In fact, inaccuracies in the reconstructed positions cause inaccuracies in all downstream processing - operations. Especially the effect on one-dimensional spatial statistics like nearest neighbor correlation - functions were discussed in the literature `B. Gault et al. `_. - - In continuation of these thoughts, this applies also to reconstructed objects. - A well-known example is the discussion of shape deviations of scandium-rich precipitates in aluminium alloys - which in reconstructions may appear as ellipsoids although they should be indeed almost spherical - provided their size is larger than the atomic length scale. - has_object_geometry(NX_BOOLEAN): - doc: | - Specifies if the tool should report a triangulated surface mesh for each identified closed polyhedron. - It is common that a marching cubes algorithm creates iso-surfaces with a fraction of tiny sub-complexes - (e.g. small isolated tetrahedra). - - These can be small tetrahedra/polyhedra about the center of a voxel of the support grid - on which marching cubes operates. Such objects may not contain an ion; especially when considering - that delocalization procedures smoothen the positions of the ions. Although these small objects are - interesting from a numerical point of view, scientists may argue they are not worth to be reported because - a microstructural feature should contain at least a few atoms to become relevant. - Therefore, paraprobe-nanochem by default does not report closed objects which bound a volume - that contains no ion. - has_object_properties(NX_BOOLEAN): - doc: | - Specifies if the tool should report properties of each closed polyhedron, such - as volume and other details. - has_object_obb(NX_BOOLEAN): - doc: | - Specifies if the tool should report for each closed polyhedron an approximately optimal bounding box - fitted to all triangles of the surface mesh of the object and ion positions inside or on the surface of the mesh. - This bounding box informs about the closed object's shape (aspect ratios). - - Users should be aware that the choice of the algorithm to compute the bounding box can have an - effect on aspect ratio statistics. It is known that computing the true optimal bounding box of in 3D - is an :math:`\mathcal{O}^3`-time-complex task. The tool uses well-established approximate algorithms - of the Computational Geometry Algorithms Library (CGAL). - has_object_ions(NX_BOOLEAN): - doc: | - Specifies if the tool should report for each closed polyhedron all evaporation IDs of those ions which - lay inside or on the boundary of the polyhedron. This information is used by the paraprobe-intersector - tool to infer if two objects share common ions, which is then understood as that the two objects intersect. - - Users should be aware that two arbitrarily closed polyhedra in three-dimensional space can intersect - but not share a common ion. In fact, the volume bounded by the polyhedron has sharp edges and flat - face(t)s. When taking two objects, an edge of one object may for instance pierce into the surface of - another object. In this case the objects partially overlap / intersect volumetrically; however this piercing - might be so small or happening in the volume between two reconstructed ion positions. Consequently, - sharing ions is a sufficient but not a necessary condition for interpreting (volumetric) intersections - between objects. - - Paraprobe-intersector implements a rigorous alternative to handle such intersections using a tetrahedralization - of closed objects. However, in many practical cases, we found through examples that there are polyhedra (especially when they are non-convex and have almost point-like) connected channels, where - tetrahedralization libraries have challenges dealing with. In this case, checking intersections - via shared_ions is a more practical alternative. - has_object_edge_contact(NX_BOOLEAN): - doc: | - Specifies if the tool should report if a (closed) object has contact with the surface aka edge of the dataset. - For this the tool currently inspects if the shortest distance between the set of triangles of the triangulated - surface mesh and the triangles of the edge model is larger than edge_threshold. - If this is the case, the object is assumed to be deeply embedded in the interior of the dataset. - Otherwise, the object is considered to have an edge contact, i.e. it shape is likely affected by the edge. - has_proxy(NX_BOOLEAN): - doc: | - Specifies if the tool should analyze a closed polyhedron (aka proxy) for each cluster of triangles whose - combinatorial analysis according to has_object returned that the object is not a closed polyhedron. - Such proxies are closed via iterative hole-filling, mesh refinement, and fairing operations. - - Users should be aware that the resulting mesh does not necessarily represent the original feature. - In most cases objects, precipitates in atom probe end up as open objects because they have been - clipped by the edge of the dataset. Using a proxy is in this case a strategy to still be able to account - for these objects. However, users should make themselves familiar with the consequences and - potential biases which this can introduce into the analysis. - has_proxy_geometry(NX_BOOLEAN): - doc: | - Like has_object_geometry but for the proxies. - has_proxy_properties(NX_BOOLEAN): - doc: | - Like has_object_properties but for the proxies. - has_proxy_obb(NX_BOOLEAN): - doc: | - Like has_object_obb but for the proxies. - has_proxy_ions(NX_BOOLEAN): - doc: | - Like has_object_ions but for the proxies. - has_proxy_edge_contact(NX_BOOLEAN): - doc: | - Like has_object_edge_contact but for the proxies. - has_object_proxigram(NX_BOOLEAN): - doc: | - Specifies if the tool should report for each closed object a (cylindrical) region-of-interest (ROI) that gets - placed, centered, and aligned with the local normal for each triangle of the object. - has_object_proxigram_edge_contact(NX_BOOLEAN): - doc: | - Specifies if the tool should report for each ROI that was placed at a triangle of each object if this ROI intersects - with the edge the dataset. Currently, the tool supports cylindrical ROIs. A computational geometry test is - performed to check for a possible intersection of each ROI with the triangulated surface mesh that is defined - via surface. Results of this cylinder-set-of-triangles intersection are interpreted as follows: - If the cylinder intersects with at least one triangle of the surface (mesh) the ROI is assumed to make edge contact. - Otherwise, the ROI is assumed to make no edge contact. - - Users should note that this approach does not work if the ROI is laying completely outside the dataset as also - in this case the cylinder intersects with any triangle. However, for atom probe this case is practically irrelevant - provided constructions such as alpha shapes or alpha wrappings (such as paraproeb-surfacer does) about the - ions of the entire reconstructed volume are used. - - # has_object_mesh_smoothing(NX_BOOLEAN): - # doc: Specifies if the tool should post-process each mesh to improve the mesh quality. - # mesh_smoothing(NXprocess): - # NEW ISSUE: here we need to specify how the meshes were smoothened - interface_meshing(NXapm_paraprobe_tool_config): - exists: ['min', '0', 'max', '1'] - doc: | - Use a principle component analysis (PCA) to mesh a single free-standing interface patch within - the reconstructed volume that is decorated by ions of specific iontypes (e.g. solute atoms). - - Interface_meshing is a typical starting point for the quantification of Gibbsian interfacial excess - in cases when closed objects constructed from patches e.g. iso-surfaces are not available or - when there is no substantial or consistently oriented concentration gradients across an interface - patch. The functionality can also be useful when the amount of latent crystallographic information - within the point cloud is insufficient or when combined with interface_meshing based on ion density - traces in field-desorption maps (see `Y. Wei et al. `_ - and `A. Breen et al. `_ for details). - - Noteworthy to mention is that the method used is conceptually similar to the work of `Z. Peng et al. `_ and related work (DCOM algorithm) by `P. Felfer et al. `_. Compared to these implementations - paraprobe-nanochem uses inspection functionalities which detect potential geometric - inconsistencies or self-interactions of the evolved DCOM mesh. - (NXidentifier): - exists: optional - analysis_identifier(NX_UINT): - exists: recommended - reconstruction(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - position(NX_CHAR): - mass_to_charge(NX_CHAR): - ranging(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - ranging_definitions(NX_CHAR): - surface(NXserialized): - exists: optional - doc: | - A precomputed triangulated surface mesh representing a model (of the surface) - of the edge of the dataset. This model can be used to detect and control - various sources of bias in the analyses. - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - vertices(NX_CHAR): - doc: | - Absolute path in the (HDF5) file that points to the array - of vertex positions for the triangles in that triangle_set. - indices(NX_CHAR): - doc: | - Absolute path in the (HDF5) file that points to the array - of vertex indices for the triangles in that triangle_set. - spatial_filter(NXspatial_filter): - windowing_method(NX_CHAR): - hexahedron_set(NXcg_hexahedron_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - hexahedra(NXcg_face_list_data_structure): - vertices(NX_UINT): - cylinder_set(NXcg_cylinder_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - height(NX_NUMBER): - radii(NX_NUMBER): - ellipsoid_set(NXcg_ellipsoid_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - half_axes_radii(NX_NUMBER): - orientation(NX_NUMBER): - polyhedron_set(NXcg_polyhedron_set): - exists: optional - - # TODO - bitmask(NXcs_filter_boolean_mask): - exists: optional - number_of_objects(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - - # leave open if scalar or matrix - # dim: (i,) - # identifier(NX_UINT): - evaporation_id_filter(NXsubsampling_filter): - exists: optional - min_incr_max(NX_INT): - iontype_filter(NXmatch_filter): - exists: optional - method(NX_CHAR): - match(NX_NUMBER): - hit_multiplicity_filter(NXmatch_filter): - exists: optional - method(NX_CHAR): - match(NX_NUMBER): - - # config - initialization(NX_CHAR): - doc: | - How is the PCA initialized: - - * default, means based on segregated solutes in the ROI - * control_point_file, means based on reading an external list of - control points, currently coming from the Leoben APT_Analyzer. - - The control_point_file is currently expected with a specific format. - The Leoben group lead by L. Romaner has developed a GUI tool `A. Reichmann et al. `_ creates a control_point_file that - can be parsed by paraprobe-parmsetup-nanochem to match the here required - formatting in control_points. - enumeration: [default, control_point_file] - control_point(NXserialized): - doc: | - Details about the control point file used. - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - control_points(NX_CHAR): - doc: | - X, Y, Z position matrix of disjoint control points. - method(NX_CHAR): - doc: | - Method used for identifying and refining the location of the interface. Currently, - paraprobe-nanochem implements a PCA followed by an iterative loop of isotropic - mesh refinement and DCOM step(s), paired with self-intersection detection. - enumeration: [pca_plus_dcom] - decoration_filter(NXmatch_filter): - doc: | - Specify those nuclides which the tool should inspect iontypes for if they contain such nuclides. - If this is the case ions of such type are taken with the number of nuclides of this multiplicity found. - The atoms of these ions are assumed to serve as useful markers for locating the interface and - refining the interface mesh. - method(NX_CHAR): - enumeration: [whitelist] - match(NX_UINT): - unit: NX_UNITLESS - doc: | - Array of nuclide iontypes to filter. - dimensions: - rank: 2 - dim: [[1, n_fct_filter_cand], [2, n_ivec_max]] - number_of_iterations(NX_UINT): - unit: NX_UNITLESS - doc: | - How many times should the DCOM and mesh refinement be applied? - target_edge_length(NX_FLOAT): - unit: NX_LENGTH - doc: | - Array of decreasing positive not smaller than one nanometer real values - which specify how the initial triangles of the mesh should be iteratively - refined by edge splitting and related mesh refinement operations. - dimensions: - rank: 1 - dim: [[1, n_fct_iterations]] - target_dcom_radius(NX_FLOAT): - unit: NX_LENGTH - doc: | - Array of decreasing positive not smaller than one nanometer real values - which specify the radius of the spherical region of interest within which the - DCOM algorithm decides for each vertex how the vertex might be relocated. - - The larger it is the DCOM radius in relation to the target_edge_length the more - likely it becomes that vertices will be relocated so substantially that triangle - self-intersections may occur. The tool detects these and stops in a controlled - manner so that the user can repeat the analyses with using a different parameterization. - dimensions: - rank: 1 - dim: [[1, n_fct_iterations]] - target_smoothing_step(NX_UINT): - unit: NX_UNITLESS - doc: | - Array of integers which specify for each DCOM step how many times the mesh - should be iteratively smoothened. Users should be aware that all three arrays - target_edge_length, target_dcom_radius, and target_smoothing_step are interpreted - in the same sequence, i.e. the zeroth entry of each array specifies the respective - parameter values to be used in the first DCOM iteration. The first entry of each array - those for the second DCOM iteration and so on and so forth. - dimensions: - rank: 1 - dim: [[1, n_fct_iterations]] - oned_profile(NXapm_paraprobe_tool_config): - exists: ['min', '0', 'max', '1'] - doc: | - Analysis of one-dimensional profiles in ROIs placed in the dataset. - Such analyses are useful for quantifying interfacial excess or for - performing classical composition analyses. - - The tool will test for each ROIs if it is completely embedded in the dataset. - Specifically, each such test evaluates if the ROI cuts at least one triangle - of the triangulated surface mesh that is referred to by surface. - If this is the case the ROI is marked as one close to the surface - and not analyzed further. Otherwise, the ROI is marked as one far - from the surface and processed further. - - For each ROI the tool computes atomically decomposed profiles. - This means, molecular ions are splitted into nuclides as many times as - their respective multiplicity. For each processed ROI the tool stores - a sorted list of signed distance values to enable post-processing with - other software like e.g. reporter to perform classical - Krakauer/Seidman-style interfacial excess analyses. - - Users should be aware that the latter intersection analysis is not - a volumetric intersection analysis. Given that the triangulated mesh - referred to in surface is not required to mesh neither a watertight - nor convex polyhedron a rigorous testing of volumetric intersection - is much more involved. If the mesh is watertight one could use split - the task in first tessellating the mesh into convex polyhedra (e.g. - tetrahedra and apply a volumetric intersection method like the - Gilbert-Johnson-Keerthi algorithm (GJK). In cases when the mesh is not - even watertight distance-based segmentation in combination with again - intersection of triangles and convex polyhedra is a robust but currently - not implemented method to quantify intersections. - (NXidentifier): - exists: optional - analysis_identifier(NX_UINT): - exists: recommended - reconstruction(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - position(NX_CHAR): - mass_to_charge(NX_CHAR): - ranging(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - ranging_definitions(NX_CHAR): - surface(NXserialized): - exists: optional - doc: | - A precomputed triangulated surface mesh representing a model (of the surface) - of the edge of the dataset. This model can be used to detect and control - various sources of bias in the analyses. - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - vertices(NX_CHAR): - doc: | - Absolute path in the (HDF5) file that points to the array - of vertex positions for the triangles in that triangle_set. - indices(NX_CHAR): - doc: | - Absolute path in the (HDF5) file that points to the array - of vertex indices for the triangles in that triangle_set. - surface_distance(NXserialized): - exists: recommended - doc: | - Distance between each ion and triangulated surface mesh. - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - distance(NX_CHAR): - doc: | - Absolute path in the (HDF5) file that points to the distance values. - The tool assumes that the values are stored in the same order as - points (ions). - feature(NXserialized): - exists: optional - doc: | - A precomputed triangulated mesh of the feature representing a model of the - interface at which to place ROIs to profile. This can be the mesh of an - interface as returned e.g. by a previous interface_meshing task or the - mesh of an iso-surface from a previous delocalization task. - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - vertices(NX_CHAR): - doc: | - Absolute HDF5 path to the dataset that specifies the array of vertex positions. - indices(NX_CHAR): - doc: | - Absolute HDF5 path to the dataset that specifies the array of facet indices - which refer to vertices. - facet_normals(NX_CHAR): - doc: | - Absolute HDF5 path to the dataset that specifies the array of facet signed unit - normals. - vertex_normals(NX_CHAR): - doc: | - Absolute HDF5 path to the dataset that specifies the array of vertex signed unit - normals. - - # triangulated surface meshes are only approximations to eventually curved shape of objects - # consequently, vertex and facet normals typically differ, the former are typically interpolated - # from normals of neighboring facets, type of weighting schemes can affect results quantitatively - patch_filter(NXmatch_filter): - exists: optional - doc: | - If interface_model is isosurface this filter can be used to restrict the analysis to specific - patches of an iso-surface. - method(NX_CHAR): - match(NX_NUMBER): - feature_distance(NXserialized): - exists: optional - doc: | - To enable an additional filtration of specific parts of the feature - mesh it is recommended to feed precomputed distances of each ion to - the triangles of the feature mesh. - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - distance(NX_CHAR): - doc: | - Absolute path in the (HDF5) file that points to the distance values. - The tool assumes that the values are stored in the same order as - points (ions). - spatial_filter(NXspatial_filter): - windowing_method(NX_CHAR): - hexahedron_set(NXcg_hexahedron_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - hexahedra(NXcg_face_list_data_structure): - vertices(NX_UINT): - cylinder_set(NXcg_cylinder_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - height(NX_NUMBER): - radii(NX_NUMBER): - ellipsoid_set(NXcg_ellipsoid_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - half_axes_radii(NX_NUMBER): - orientation(NX_NUMBER): - polyhedron_set(NXcg_polyhedron_set): - exists: optional - - # TODO - bitmask(NXcs_filter_boolean_mask): - exists: optional - number_of_objects(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - - # leave open if scalar or matrix - # dim: (i,) - # identifier(NX_UINT): - evaporation_id_filter(NXsubsampling_filter): - exists: optional - min_incr_max(NX_INT): - iontype_filter(NXmatch_filter): - exists: optional - method(NX_CHAR): - match(NX_NUMBER): - hit_multiplicity_filter(NXmatch_filter): - exists: optional - method(NX_CHAR): - match(NX_NUMBER): - - # config - user_defined_roi(NXobject): - exists: optional - doc: | - As an alternative mode the tool can be instructed to place ROIs - at specific locations into the dataset. This is the programmatic - equivalent to the classical approach in atom probe to place ROIs - for composition analyses via positioning and rotating them via - a graphical user interface (such as in IVAS / AP Suite). - cylinder_set(NXcg_cylinder_set): - - # dimensionality(NX_POSINT): - # cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - dimensions: - rank: 2 - dim: [[1, n_rois], [2, 3]] - height(NX_NUMBER): - dimensions: - rank: 2 - dim: [[1, n_rois], [2, 3]] - radii(NX_NUMBER): - dimensions: - rank: 1 - dim: [[1, n_rois]] - - # could add other shapes in the future if necessary - # but cylinders are most frequently used - distancing_model(NX_CHAR): - doc: | - Which type of distance should be reported for the profile. - enumeration: [project_to_triangle_plane] - roi_orientation(NX_CHAR): - doc: | - For each ROI, along which direction should the cylindrical ROI - be oriented if ROIs are placed at triangles of the feature mesh. - enumeration: [triangle_outer_unit_normal] - roi_cylinder_height(NX_FLOAT): - unit: NX_LENGTH - doc: | - For each ROI, how high (projected onto the cylinder axis) should - the cylindrical ROI be if ROIs are placed at triangles - of the feature mesh. - roi_cylinder_radius(NX_FLOAT): - unit: NX_LENGTH - doc: | - For each ROI, how wide (in radius) should the cylindrical ROI - be if ROIs are placed at triangles of the feature mesh. - common(NXapm_paraprobe_tool_common): - status(NX_CHAR): - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - profiling(NXcs_profiling): - exists: recommended - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - total_elapsed_time(NX_FLOAT): - current_working_directory(NX_CHAR): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d667ff28671c809848a71108542daa45d12b99d09bff226c4d13ac49c5bb686e -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# How many iontypes does the delocalization filter specify. -# -# -# -# -# How many grid_resolutions values. -# -# -# -# -# How many kernel_variance values. -# -# -# -# -# How many disjoint control points are defined. -# -# -# -# -# How many iontypes does the interface meshing iontype filter specify. -# -# -# -# -# How many DCOM iterations. -# -# -# -# -# Maximum number of atoms per molecular ion. -# -# -# -# -# Number of cylinder ROIs to place for oned_profile if no feature mesh is used. -# -# -# -# -# Application definition for a configuration file of the paraprobe-nanochem tool. -# -# This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. -# -# -# -# -# -# -# -# -# -# -# Discretization and distributing of the ion point cloud on a 3D grid -# to enable continuum-scale analyses. -# -# By default, the tool computes a full kernel density estimation of decomposed -# ions to create one discretized field for each element. -# -# One delocalization task configures a parameter sweep with at least one -# delocalization. The total number of runs depends on the number of -# grid_resolution and kernel_variance values. For example, setting two grid_resolutions -# and three kernel_variance will compute six runs. Two sets of three with the first set using -# the first grid_resolutions and in sequence the kernel_variance respectively. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# A precomputed triangulated surface mesh representing a model (of the surface) -# of the edge of the dataset. This model can be used to detect and control -# various sources of bias in the analyses. -# -# -# -# -# -# -# -# Absolute path in the (HDF5) file that points to the array -# of vertex positions for the triangles in that triangle_set. -# -# -# -# -# Absolute path in the (HDF5) file that points to the array -# of vertex indices for the triangles in that triangle_set. -# -# -# -# -# -# Distance between each ion and triangulated surface mesh. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Compute delocalization or load an existent one from input. -# -# -# -# -# -# -# -# -# Serialized result of an already computed delocalization which is for performance -# reasons here just loaded and not computed again. -# -# -# -# -# -# -# -# Absolute path in the (HDF5) file that points to the group within which -# individual delocalization results are stored. -# -# -# -# -# -# -# Matrix of nuclides representing how iontypes should be accounted for during -# the delocalization. This is the most general approach to define if and how many -# times an ion is to be counted. The tool performs a so-called atomic decomposition -# of all iontypes, i.e. the tool analyses from how many atoms of each nuclide -# or element respectively an (molecular) ion is built from. -# -# Taking the hydroxonium H3O+ molecular ion as an example: -# It contains hydrogen and oxygen atoms. The multiplicity of hydrogen -# is three whereas that of oxygen is one. Therefore, the respective atomic decomposition -# analysis prior to the iso-surface computation adds three hydrogen counts for each -# H3O+ ion. -# -# This is a practical solution which accepts that on the one hand not every bond is -# broken during an atom probe experiment but also that ions may react further during -# their flight to the detector. The exact details depend on the local field conditions, -# quantum mechanics of possible electron transfer and thus the detailed trajectory -# of the system and its electronic state. -# -# The detection of molecular ions instead of always single atom ions only is the -# reason that an atom probe experiment tells much about field evaporation physics -# but also faces an inherent loss of information with respect to the detailed spatial -# arrangement that is independent of other imprecisions such as effect of limited -# accuracy of reconstruction protocols and their parameterization. -# -# Unused values in each row of the matrix are nullified. -# Nuclides are identified as hashed nuclide (see :ref:`NXion`) for further details. -# -# -# -# -# -# -# -# -# Array of edge lengths of the cubic cells used for discretizing the reconstructed dataset -# on a cuboidal 3D grid (:ref:`NXcg_grid`). The tool performs as many delocalization -# computations as values are specified in grid_resolution. -# -# -# -# -# -# -# -# Half the width of a :math:`{(2 \cdot n + 1)}^3` cubic kernel of cubic voxel -# beyond which the Gaussian Ansatz function will be truncated. Intensity outside -# the kernel is factorized into the kernel via a normalization procedure. -# -# -# -# -# Array of variance values :math:`\sigma` of the Gaussian Ansatz kernel -# (:math:`\sigma_x := \sigma`, :math:`\sigma_x = \sigma_y = 2 \cdot \sigma_z`). -# The tool performs as many delocalization computations as values are specified -# in kernel_variance. -# -# -# -# -# -# -# -# How should the results of the kernel-density estimation be normalized into quantities. -# By default, the tool computes the total number (intensity) of ions or elements. -# Alternatively, the tool can compute the total intensity, the composition, -# or the concentration of the ions/elements specified by the nuclide_whitelist. -# -# -# -# -# -# -# -# -# -# Specifies if the tool should report the delocalization 3D field values. -# -# -# -# -# Configuration of the set of iso-surfaces to compute using that delocalization. -# Such iso-surfaces are the starting point for a reconstruction of so-called objects or -# (microstructual) features. Examples of scientific relevant are (line features e.g. dislocations -# poles, surface features such as interfaces, i.e. phase and grain boundaries, or volumetric -# features such as precipitates. -# Users should be aware that reconstructed datasets in atom probe are a model and may face -# inaccuracies and artifacts that can be mistaken incorrectly as microstructural features. -# -# -# -# As it is detailed in `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_, the handling of -# triangles at the surface (edge) of the dataset requires special attention especially for -# composition-normalized delocalization. Here, it is possible that the composition -# increases towards the edge of the dataset because the quotient of two numbers -# that are both smaller than one is larger instead of smaller than the counter. -# -# By default, the tool uses a modified marching cubes algorithm of Lewiner et al. -# which detects if voxels face such a situation. In this case, no triangles are generated -# for such voxels. -# -# Alternatively, keep_edge_triangles instructs the tool to not remove triangles at the -# edge of the dataset at the cost of bias. When using this keep_edge_triangles users -# should understand that all features in contact with the edge of the dataset get usually -# artificial enlarged. Consequently, triangulated surface meshes of these objects are -# closed during the marching. However, this closure is artificial and can biased shape -# analyses for those objects. This also holds for such practices that are offered in -# proprietary software like IVAS / AP Suite. The situation is comparable to analyses -# of grain shapes via orientation microscopy from electron microscopy or X-ray -# diffraction tomography. Features at the edge of the dataset may have not been -# captured fully. -# -# Thanks to collaboration with V. V. Rielli and S. Primig from the Sydney atom probe group, -# paraprobe-nanochem implements a complete pipeline to process features at the edge of the -# dataset. Specifically, these are modelled and replaced with closed polyhedral objects using -# an iterative mesh and hole-filling procedures with fairing operations. -# -# The tool bookkeeps such objects separately to lead the decision whether or not to -# consider these objects to the user. Users should be aware that results from fairing operations -# should be compared to results from analyses where all objects at the edge -# of the dataset have been removed. Furthermore, users should be careful with overestimating -# the statistical significance of their dataset especially when using atom probe when they -# use their atom probe result to compare different descriptors. Even though a dataset may -# deliver statistically significant results for compositions, this does not necessarily mean that -# same dataset will also yield statistically significant and insignificantly biased results for -# 3D object analyses! -# -# Being able to quantify these effects and making atom probers aware of these subtleties -# was one of the main reasons why the paraprobe-nanochem tool was implemented. -# -# -# -# -# -# -# -# -# The ion-to-surface distance that is used in the analyses of features to identify whether -# these are laying inside the dataset or close to the surface (edge) of the dataset. -# -# If an object has at least one ion with an ion-to-surface-distance below this threshold, -# the object is considered close to the edge of the dataset. The tool uses a distance-based -# approach to solve the in general complicated and involved treatment of computing -# volumetric intersections between closed 2-manifolds that are not necessarily convex. -# The main practical reason is that such computational geometry analyses face numerical -# robustness issues as a consequence of which a mesh can be detected as being completely -# inside another mesh although in reality it is only :math:`\epsilon`-close only, i.e. almost -# touching only the edge (e.g. from inside). -# -# Practically, humans would likely still state in such case that the object is close to the -# edge of the dataset; however mathematically the object is indeed completely inside. -# In short, a distance-based approach is rigorous and flexible. -# -# -# -# -# Iso-contour values. For each value, the tool computes an iso-surface and performs -# subsequent analyses for each iso-surface. The unit depends on the choice for the -# normalization of the accumulated ion intensity values per voxel: -# -# * total, total number of ions, irrespective their iontype -# * candidates, total number of ions with type in the isotope_whitelist. -# * composition, candidates but normalized by composition, i.e. at.-% -# * concentration, candidates but normalized by voxel volume, i.e. ions/nm^3 -# -# -# -# -# Specifies if the tool should report the triangle soup which represents each triangle of the -# iso-surface complex. The resulting set of triangles is colloquially referred to as a soup -# because different sub-set may not be connected. -# -# Each triangle is reported with an ID specifying to which triangle cluster (with IDs starting at zero) -# the triangle belongs. The clustering of triangles within the soup is performed with a -# modified DBScan algorithm. -# -# -# -# -# Specifies if the tool should analyze for each cluster of triangles how they can be combinatorially -# processed to describe a closed polyhedron. Such a closed polyhedron (not-necessarily convex!) -# can be used to describe objects with relevance in the microstructure. -# -# Users should be aware that the resulting mesh does not necessarily represent the original precipitate. -# In fact, inaccuracies in the reconstructed positions cause inaccuracies in all downstream processing -# operations. Especially the effect on one-dimensional spatial statistics like nearest neighbor correlation -# functions were discussed in the literature `B. Gault et al. <https://doi.org/10.1017/S1431927621012952>`_. -# -# In continuation of these thoughts, this applies also to reconstructed objects. -# A well-known example is the discussion of shape deviations of scandium-rich precipitates in aluminium alloys -# which in reconstructions may appear as ellipsoids although they should be indeed almost spherical -# provided their size is larger than the atomic length scale. -# -# -# -# -# Specifies if the tool should report a triangulated surface mesh for each identified closed polyhedron. -# It is common that a marching cubes algorithm creates iso-surfaces with a fraction of tiny sub-complexes -# (e.g. small isolated tetrahedra). -# -# These can be small tetrahedra/polyhedra about the center of a voxel of the support grid -# on which marching cubes operates. Such objects may not contain an ion; especially when considering -# that delocalization procedures smoothen the positions of the ions. Although these small objects are -# interesting from a numerical point of view, scientists may argue they are not worth to be reported because -# a microstructural feature should contain at least a few atoms to become relevant. -# Therefore, paraprobe-nanochem by default does not report closed objects which bound a volume -# that contains no ion. -# -# -# -# -# Specifies if the tool should report properties of each closed polyhedron, such -# as volume and other details. -# -# -# -# -# Specifies if the tool should report for each closed polyhedron an approximately optimal bounding box -# fitted to all triangles of the surface mesh of the object and ion positions inside or on the surface of the mesh. -# This bounding box informs about the closed object's shape (aspect ratios). -# -# Users should be aware that the choice of the algorithm to compute the bounding box can have an -# effect on aspect ratio statistics. It is known that computing the true optimal bounding box of in 3D -# is an :math:`\mathcal{O}^3`-time-complex task. The tool uses well-established approximate algorithms -# of the Computational Geometry Algorithms Library (CGAL). -# -# -# -# -# Specifies if the tool should report for each closed polyhedron all evaporation IDs of those ions which -# lay inside or on the boundary of the polyhedron. This information is used by the paraprobe-intersector -# tool to infer if two objects share common ions, which is then understood as that the two objects intersect. -# -# Users should be aware that two arbitrarily closed polyhedra in three-dimensional space can intersect -# but not share a common ion. In fact, the volume bounded by the polyhedron has sharp edges and flat -# face(t)s. When taking two objects, an edge of one object may for instance pierce into the surface of -# another object. In this case the objects partially overlap / intersect volumetrically; however this piercing -# might be so small or happening in the volume between two reconstructed ion positions. Consequently, -# sharing ions is a sufficient but not a necessary condition for interpreting (volumetric) intersections -# between objects. -# -# Paraprobe-intersector implements a rigorous alternative to handle such intersections using a tetrahedralization -# of closed objects. However, in many practical cases, we found through examples that there are polyhedra (especially when they are non-convex and have almost point-like) connected channels, where -# tetrahedralization libraries have challenges dealing with. In this case, checking intersections -# via shared_ions is a more practical alternative. -# -# -# -# -# Specifies if the tool should report if a (closed) object has contact with the surface aka edge of the dataset. -# For this the tool currently inspects if the shortest distance between the set of triangles of the triangulated -# surface mesh and the triangles of the edge model is larger than edge_threshold. -# If this is the case, the object is assumed to be deeply embedded in the interior of the dataset. -# Otherwise, the object is considered to have an edge contact, i.e. it shape is likely affected by the edge. -# -# -# -# -# Specifies if the tool should analyze a closed polyhedron (aka proxy) for each cluster of triangles whose -# combinatorial analysis according to has_object returned that the object is not a closed polyhedron. -# Such proxies are closed via iterative hole-filling, mesh refinement, and fairing operations. -# -# Users should be aware that the resulting mesh does not necessarily represent the original feature. -# In most cases objects, precipitates in atom probe end up as open objects because they have been -# clipped by the edge of the dataset. Using a proxy is in this case a strategy to still be able to account -# for these objects. However, users should make themselves familiar with the consequences and -# potential biases which this can introduce into the analysis. -# -# -# -# -# Like has_object_geometry but for the proxies. -# -# -# -# -# Like has_object_properties but for the proxies. -# -# -# -# -# Like has_object_obb but for the proxies. -# -# -# -# -# Like has_object_ions but for the proxies. -# -# -# -# -# Like has_object_edge_contact but for the proxies. -# -# -# -# -# Specifies if the tool should report for each closed object a (cylindrical) region-of-interest (ROI) that gets -# placed, centered, and aligned with the local normal for each triangle of the object. -# -# -# -# -# Specifies if the tool should report for each ROI that was placed at a triangle of each object if this ROI intersects -# with the edge the dataset. Currently, the tool supports cylindrical ROIs. A computational geometry test is -# performed to check for a possible intersection of each ROI with the triangulated surface mesh that is defined -# via surface. Results of this cylinder-set-of-triangles intersection are interpreted as follows: -# If the cylinder intersects with at least one triangle of the surface (mesh) the ROI is assumed to make edge contact. -# Otherwise, the ROI is assumed to make no edge contact. -# -# Users should note that this approach does not work if the ROI is laying completely outside the dataset as also -# in this case the cylinder intersects with any triangle. However, for atom probe this case is practically irrelevant -# provided constructions such as alpha shapes or alpha wrappings (such as paraproeb-surfacer does) about the -# ions of the entire reconstructed volume are used. -# -# -# -# -# -# -# -# Use a principle component analysis (PCA) to mesh a single free-standing interface patch within -# the reconstructed volume that is decorated by ions of specific iontypes (e.g. solute atoms). -# -# Interface_meshing is a typical starting point for the quantification of Gibbsian interfacial excess -# in cases when closed objects constructed from patches e.g. iso-surfaces are not available or -# when there is no substantial or consistently oriented concentration gradients across an interface -# patch. The functionality can also be useful when the amount of latent crystallographic information -# within the point cloud is insufficient or when combined with interface_meshing based on ion density -# traces in field-desorption maps (see `Y. Wei et al. <https://doi.org/10.1371/journal.pone.0225041>`_ -# and `A. Breen et al. <https://github.com/breen-aj/detector>`_ for details). -# -# Noteworthy to mention is that the method used is conceptually similar to the work of `Z. Peng et al. <https://doi.org/10.1017/S1431927618016112>`_ and related work (DCOM algorithm) by `P. Felfer et al. <https://doi.org/10.1016/j.ultramic.2015.06.002>`_. Compared to these implementations -# paraprobe-nanochem uses inspection functionalities which detect potential geometric -# inconsistencies or self-interactions of the evolved DCOM mesh. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# A precomputed triangulated surface mesh representing a model (of the surface) -# of the edge of the dataset. This model can be used to detect and control -# various sources of bias in the analyses. -# -# -# -# -# -# -# -# Absolute path in the (HDF5) file that points to the array -# of vertex positions for the triangles in that triangle_set. -# -# -# -# -# Absolute path in the (HDF5) file that points to the array -# of vertex indices for the triangles in that triangle_set. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# How is the PCA initialized: -# -# * default, means based on segregated solutes in the ROI -# * control_point_file, means based on reading an external list of -# control points, currently coming from the Leoben APT_Analyzer. -# -# The control_point_file is currently expected with a specific format. -# The Leoben group lead by L. Romaner has developed a GUI tool `A. Reichmann et al. <https://github.com/areichm/APT_analyzer>`_ creates a control_point_file that -# can be parsed by paraprobe-parmsetup-nanochem to match the here required -# formatting in control_points. -# -# -# -# -# -# -# -# -# Details about the control point file used. -# -# -# -# -# -# -# -# X, Y, Z position matrix of disjoint control points. -# -# -# -# -# -# Method used for identifying and refining the location of the interface. Currently, -# paraprobe-nanochem implements a PCA followed by an iterative loop of isotropic -# mesh refinement and DCOM step(s), paired with self-intersection detection. -# -# -# -# -# -# -# -# Specify those nuclides which the tool should inspect iontypes for if they contain such nuclides. -# If this is the case ions of such type are taken with the number of nuclides of this multiplicity found. -# The atoms of these ions are assumed to serve as useful markers for locating the interface and -# refining the interface mesh. -# -# -# -# -# -# -# -# -# Array of nuclide iontypes to filter. -# -# -# -# -# -# -# -# -# -# How many times should the DCOM and mesh refinement be applied? -# -# -# -# -# Array of decreasing positive not smaller than one nanometer real values -# which specify how the initial triangles of the mesh should be iteratively -# refined by edge splitting and related mesh refinement operations. -# -# -# -# -# -# -# -# Array of decreasing positive not smaller than one nanometer real values -# which specify the radius of the spherical region of interest within which the -# DCOM algorithm decides for each vertex how the vertex might be relocated. -# -# The larger it is the DCOM radius in relation to the target_edge_length the more -# likely it becomes that vertices will be relocated so substantially that triangle -# self-intersections may occur. The tool detects these and stops in a controlled -# manner so that the user can repeat the analyses with using a different parameterization. -# -# -# -# -# -# -# -# Array of integers which specify for each DCOM step how many times the mesh -# should be iteratively smoothened. Users should be aware that all three arrays -# target_edge_length, target_dcom_radius, and target_smoothing_step are interpreted -# in the same sequence, i.e. the zeroth entry of each array specifies the respective -# parameter values to be used in the first DCOM iteration. The first entry of each array -# those for the second DCOM iteration and so on and so forth. -# -# -# -# -# -# -# -# -# Analysis of one-dimensional profiles in ROIs placed in the dataset. -# Such analyses are useful for quantifying interfacial excess or for -# performing classical composition analyses. -# -# The tool will test for each ROIs if it is completely embedded in the dataset. -# Specifically, each such test evaluates if the ROI cuts at least one triangle -# of the triangulated surface mesh that is referred to by surface. -# If this is the case the ROI is marked as one close to the surface -# and not analyzed further. Otherwise, the ROI is marked as one far -# from the surface and processed further. -# -# For each ROI the tool computes atomically decomposed profiles. -# This means, molecular ions are splitted into nuclides as many times as -# their respective multiplicity. For each processed ROI the tool stores -# a sorted list of signed distance values to enable post-processing with -# other software like e.g. reporter to perform classical -# Krakauer/Seidman-style interfacial excess analyses. -# -# Users should be aware that the latter intersection analysis is not -# a volumetric intersection analysis. Given that the triangulated mesh -# referred to in surface is not required to mesh neither a watertight -# nor convex polyhedron a rigorous testing of volumetric intersection -# is much more involved. If the mesh is watertight one could use split -# the task in first tessellating the mesh into convex polyhedra (e.g. -# tetrahedra and apply a volumetric intersection method like the -# Gilbert-Johnson-Keerthi algorithm (GJK). In cases when the mesh is not -# even watertight distance-based segmentation in combination with again -# intersection of triangles and convex polyhedra is a robust but currently -# not implemented method to quantify intersections. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# A precomputed triangulated surface mesh representing a model (of the surface) -# of the edge of the dataset. This model can be used to detect and control -# various sources of bias in the analyses. -# -# -# -# -# -# -# -# Absolute path in the (HDF5) file that points to the array -# of vertex positions for the triangles in that triangle_set. -# -# -# -# -# Absolute path in the (HDF5) file that points to the array -# of vertex indices for the triangles in that triangle_set. -# -# -# -# -# -# Distance between each ion and triangulated surface mesh. -# -# -# -# -# -# -# -# Absolute path in the (HDF5) file that points to the distance values. -# The tool assumes that the values are stored in the same order as -# points (ions). -# -# -# -# -# -# A precomputed triangulated mesh of the feature representing a model of the -# interface at which to place ROIs to profile. This can be the mesh of an -# interface as returned e.g. by a previous interface_meshing task or the -# mesh of an iso-surface from a previous delocalization task. -# -# -# -# -# -# -# -# Absolute HDF5 path to the dataset that specifies the array of vertex positions. -# -# -# -# -# Absolute HDF5 path to the dataset that specifies the array of facet indices -# which refer to vertices. -# -# -# -# -# Absolute HDF5 path to the dataset that specifies the array of facet signed unit -# normals. -# -# -# -# -# Absolute HDF5 path to the dataset that specifies the array of vertex signed unit -# normals. -# -# -# -# -# -# If interface_model is isosurface this filter can be used to restrict the analysis to specific -# patches of an iso-surface. -# -# -# -# -# -# -# -# To enable an additional filtration of specific parts of the feature -# mesh it is recommended to feed precomputed distances of each ion to -# the triangles of the feature mesh. -# -# -# -# -# -# -# -# Absolute path in the (HDF5) file that points to the distance values. -# The tool assumes that the values are stored in the same order as -# points (ions). -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# As an alternative mode the tool can be instructed to place ROIs -# at specific locations into the dataset. This is the programmatic -# equivalent to the classical approach in atom probe to place ROIs -# for composition analyses via positioning and rotating them via -# a graphical user interface (such as in IVAS / AP Suite). -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Which type of distance should be reported for the profile. -# -# -# -# -# -# -# -# For each ROI, along which direction should the cylindrical ROI -# be oriented if ROIs are placed at triangles of the feature mesh. -# -# -# -# -# -# -# -# For each ROI, how high (projected onto the cylinder axis) should -# the cylindrical ROI be if ROIs are placed at triangles -# of the feature mesh. -# -# -# -# -# For each ROI, how wide (in radius) should the cylindrical ROI -# be if ROIs are placed at triangles of the feature mesh. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml deleted file mode 100644 index 84a0f55bfb..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml +++ /dev/null @@ -1,2385 +0,0 @@ -category: application -doc: | - Application definition for results files of the paraprobe-nanochem tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_ions: | - The total number of ions in the reconstruction. - n_atomic: | - The total number of atoms in the atomic_decomposition match filter. - n_isotopic: | - The total number of isotopes in the isotopic_decomposition match filter. - d: | - The dimensionality of the delocalization grid. - c: | - The cardinality/total number of cells/grid points in the delocalization grid. - - # c_tri_soup: | - # The cardinality/total number of triangles in the triangle soup. - n_f_tri: | - The total number of faces of triangles. - n_f_tri_xdmf: | - The total number of XDMF values to represent all faces of triangles via XDMF. - n_feature_dict: | - The total number of entries in a feature dictionary. - n_v_feat: | - The total number of volumetric features. - n_speci: | - The total number of member distinguished when reporting composition. - n_rois: | - The total number of ROIs placed in an oned_profile task. -type: group -NXapm_paraprobe_nanochem_results(NXobject): - (NXentry): - exists: ['min', '1', 'max', '1'] - definition(NX_CHAR): - \@version: - type: NX_CHAR - enumeration: [NXapm_paraprobe_nanochem_results] - - # tasks - delocalizationID(NXdelocalization): - exists: ['min', '0', 'max', 'unbounded'] - window(NXcs_filter_boolean_mask): - number_of_ions(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - - # results - weighting_model(NXmatch_filter): - weighting_method(NX_CHAR): - method(NX_CHAR): - match(NX_UINT): - normalization(NX_CHAR): - doc: | - How were results of the kernel-density estimation normalized: - * total, the total number (intensity) of ions or elements. - * candidates, the total number (intensity) of ions matching weighting_model - * composition, the value for candidates divided by the value for total, - * concentration, the value for candidates divided by the volume of the cell. - enumeration: [total, candidates, composition, concentration] - grid(NXcg_grid): - doc: | - The discretized domain/grid on which the delocalization is applied. - dimensionality(NX_POSINT): - unit: NX_UNITLESS - enumeration: [1, 2, 3] - cardinality(NX_POSINT): - unit: NX_UNITLESS - doc: | - The total number of cells/voxels of the grid. - origin(NX_NUMBER): - dimensions: - rank: 1 - dim: [[1, d]] - symmetry(NX_CHAR): - doc: | - The symmetry of the lattice defining the shape of the unit cell. - enumeration: [cubic] - cell_dimensions(NX_NUMBER): - unit: NX_LENGTH - doc: | - The unit cell dimensions according to the coordinate system defined under - coordinate_system. - dimensions: - rank: 1 - dim: [[1, d]] - extent(NX_POSINT): - doc: | - Number of unit cells along each of the d-dimensional base vectors. - The total number of cells, or grid points has to be the cardinality. - If the grid has an irregular number of grid positions in each direction, - as it could be for instance the case of a grid where all grid points - outside some masking primitive are removed, this extent field should - not be used. Instead use the coordinate field. - dimensions: - rank: 1 - dim: [[1, d]] - - # coordinate_system implicit - identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer which specifies the first index to be used for distinguishing identifiers for cells. - Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are - defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. - For explicit indexing the identifier array has to be defined. - kernel_size(NX_POSINT): - unit: NX_DIMENSIONLESS - doc: | - Halfwidth of the kernel about the central voxel. - The shape of the kernel is that of a cuboid - of extent 2*kernel_extent[i] + 1 in each dimension i. - dimensions: - rank: 1 - dim: [[1, 3]] - kernel_type(NX_CHAR): - doc: | - Functional form of the kernel (Ansatz function). - enumeration: [gaussian] - kernel_sigma(NX_FLOAT): - unit: NX_LENGTH - doc: | - Standard deviation :math:`\sigma_i` of the kernel in each dimension - in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. - dimensions: - rank: 1 - dim: [[1, 3]] - kernel_mu(NX_FLOAT): - unit: NX_LENGTH - doc: | - Expectation value :math:`\mu_i` of the kernel in each dimension - in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. - dimensions: - rank: 1 - dim: [[1, 3]] - bounding_box(NXcg_hexahedron_set): - doc: | - A tight axis-aligned bounding box about the grid. - is_axis_aligned(NX_BOOLEAN): - doc: | - For atom probe should be set to true. - identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly or explicitly. - For implicit indexing the identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. - For explicit indexing the identifier array has to be defined. - hexahedron(NXcg_face_list_data_structure): - vertex_identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly or explicitly. - For implicit indexing the identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array - has to be defined. - face_identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly or explicitly. - For implicit indexing the identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array - has to be defined. - vertices(NX_NUMBER): - unit: NX_LENGTH - doc: | - Positions of the vertices. - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - dimensions: - rank: 2 - dim: [[1, 8], [2, 3]] - faces(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. - dimensions: - rank: 2 - dim: [[1, 6], [2, 4]] - xdmf_topology(NX_UINT): - unit: NX_UNITLESS - 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. - dimensions: - rank: 1 - dim: [[1, 36]] - number_of_boundaries(NX_POSINT): - exists: optional - unit: NX_UNITLESS - doc: | - How many distinct boundaries are distinguished? - Most grids discretize a cubic or cuboidal region. In this case - six sides can be distinguished, each making an own boundary. - boundaries(NX_CHAR): - exists: optional - doc: | - Name of the boundaries. E.g. left, right, front, back, bottom, top, - The field must have as many entries as there are number_of_boundaries. - dimensions: - rank: 1 - dim: [[1, 6]] - boundary_conditions(NX_INT): - exists: optional - unit: NX_UNITLESS - doc: | - The boundary conditions for each boundary: - - 0 - undefined - 1 - open - 2 - periodic - 3 - mirror - 4 - von Neumann - 5 - Dirichlet - dimensions: - rank: 1 - dim: [[1, 6]] - - #MK::how to avoid storing it for once in NeXus for H5Web and for XDMF in ParaView ? - scalar_field_magn_SUFFIX(NXdata): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - The result of the delocalization :math:`\Phi = f(x, y, z)` based on which subsequent iso-surfaces - will be computed. In commercial software so far there is no possibility to export this information. - - If the intensity for all matches of the weighting_model are summarized name this NXdata instance - scalar_field_magn_total. - - If the intensity is reported for each iontype one can avoid many subsequent - computations as individual intensities can be reinterpreted using a different weighting_model in - down-stream usage of the here reported values (e.g. with Python scripting). - In this case name the individual NXdata instances scalar_field_magn_ionID using the ID of the ion as - per the configuration of the ranging definitions used. - \@signal: - type: NX_CHAR - \@axes: - type: NX_CHAR - \@xpos_indices: - type: NX_UINT - \@ypos_indices: - type: NX_UINT - \@zpos_indices: - type: NX_UINT - title(NX_CHAR): - intensity(NX_FLOAT): - unit: NX_ANY - doc: | - The actual delocalized intensity values. - dimensions: - rank: 3 - dim: [[1, n_z], [2, n_y], [3, n_x]] - xpos(NX_FLOAT): - unit: NX_LENGTH - doc: | - Cell center of mass positions along x. - dimensions: - rank: 1 - dim: [[1, n_x]] - ypos(NX_FLOAT): - unit: NX_LENGTH - doc: | - Cell center of mass positions along y. - dimensions: - rank: 1 - dim: [[1, n_y]] - zpos(NX_FLOAT): - unit: NX_LENGTH - doc: | - Cell center of mass positions along z. - dimensions: - rank: 1 - dim: [[1, n_z]] - xdmf_intensity(NX_FLOAT): - exists: optional - unit: NX_ANY - doc: | - Intensity of the field at given point - dimensions: - rank: 1 - dim: [[1, n_xyz]] - xdmf_xyz(NX_FLOAT): - exists: optional - unit: NX_UNITLESS - doc: | - Center of mass positions of each voxel for rendering the scalar field - via XDMF in e.g. Paraview. - dimensions: - rank: 2 - dim: [[1, n_xyz], [2, 3]] - xdmf_topology(NX_NUMBER): - exists: optional - unit: NX_UNITLESS - doc: | - XDMF topology for rendering in combination with xdmf_xyz the scalar field - via XDMF in e.g. Paraview. - dimensions: - rank: 1 - dim: [[1, i]] - scalar_field_grad_SUFFIX(NXdata): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - The three-dimensional gradient :math:`\nabla \Phi`. - Follow the naming convention of scalar_field_magn_SUFFIX to report parallel structures. - \@signal: - type: NX_CHAR - \@axes: - type: NX_CHAR - \@xpos_indices: - type: NX_CHAR - \@ypos_indices: - type: NX_CHAR - \@zpos_indices: - type: NX_CHAR - title(NX_CHAR): - intensity(NX_FLOAT): - unit: NX_ANY - doc: | - The actual point-wise component values. - dimensions: - rank: 4 - dim: [[1, n_z], [2, n_y], [3, n_x], [4, 3]] - xpos(NX_FLOAT): - unit: NX_LENGTH - doc: | - Cell center of mass positions along x. - dimensions: - rank: 1 - dim: [[1, n_x]] - ypos(NX_FLOAT): - unit: NX_LENGTH - doc: | - Cell center of mass positions along y. - dimensions: - rank: 1 - dim: [[1, n_y]] - zpos(NX_FLOAT): - unit: NX_LENGTH - doc: | - Cell center of mass positions along z. - dimensions: - rank: 1 - dim: [[1, n_z]] - xdmf_gradient(NX_FLOAT): - exists: optional - unit: NX_ANY - doc: | - The gradient vector formatted for direct visualization via XDMF in e.g. - Paraview. - dimensions: - rank: 2 - dim: [[1, n_xyz], [2, 3]] - xdmf_xyz(NX_FLOAT): - exists: optional - unit: NX_LENGTH - doc: | - Center of mass positions of each voxel for rendering the scalar field gradient - via XDMF in e.g. Paraview. - dimensions: - rank: 2 - dim: [[1, n_xyz], [2, 3]] - xdmf_topology(NX_NUMBER): - exists: optional - unit: NX_UNITLESS - doc: | - XDMF topology for rendering in combination with xdmf_xyz the scalar field - via XDFM in e.g. Paraview. - dimensions: - rank: 1 - dim: [[1, i]] - - #MK:: - iso_surfaceID(NXisocontour): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - An iso-surface is the boundary between two regions across which the magnitude of a - scalar field falls below/exceeds a threshold magnitude :math:`\varphi`. - - For applications in atom probe microscopy, the location and shape of such a boundary (set) - is typically approximated by discretization - triangulation to be specific. - - This yields a complex of not necessarily connected geometric primitives. - Paraprobe-nanochem approximates this complex with a soup of triangles. - dimensionality(NX_POSINT): - isovalue(NX_NUMBER): - unit: NX_ANY - doc: | - The threshold or iso-contour value :math:`\varphi`. - marching_cubes(NXcg_marching_cubes): - doc: | - Details about the specific marching cubes algorithm that was used for computing - the iso-surface. - implementation(NX_CHAR): - doc: | - Reference to the specific implementation of marching cubes used. - The value placed here should be a DOI. If there are no specific - DOI or details write not_further_specified, or give at least a - free-text description. The program and version used is the - specific paraprobe-nanochem. - triangle_soup(NXcg_triangle_set): - exists: optional - doc: | - The resulting triangle soup computed via marching cubes. - dimensionality(NX_POSINT): - unit: NX_UNITLESS - cardinality(NX_POSINT): - unit: NX_UNITLESS - identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer which specifies the first index to be used for distinguishing triangles. - Identifiers are defined either implicitly or explicitly. For implicit indexing the - identifiers are defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. - triangles(NXcg_face_list_data_structure): - number_of_vertices(NX_POSINT): - number_of_faces(NX_POSINT): - vertex_identifier_offset(NX_INT): - face_identifier_offset(NX_INT): - vertices(NX_NUMBER): - unit: NX_LENGTH - doc: | - Positions of the vertices. - - Users are encouraged to reduce the vertices to a unique set as this may - result in a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. Naively here means that each - vertex is stored even though many share the same positions. - dimensions: - rank: 2 - dim: [[1, i], [2, 3]] - faces(NX_INT): - unit: NX_UNITLESS - doc: | - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. - dimensions: - rank: 1 - dim: [[1, j]] - xdmf_topology(NX_UINT): - unit: NX_UNITLESS - doc: | - A list of as many tuples of XDMF topology key, XDMF number - of vertices and a triple of vertex indices specifying each - triangle. The total number of entries is n_f_tri * (1+1+3). - dimensions: - rank: 1 - dim: [[1, n_f_tri_xdmf]] - vertex_normal(NXcg_unit_normal_set): - exists: optional - normals(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Direction of each normal. - dimensions: - rank: 2 - dim: [[1, j], [2, 3]] - orientation(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - Qualifier how which specifically oriented normal to its - primitive each normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner - dimensions: - rank: 1 - dim: [[1, j]] - - # edge_normal(NXcg_unit_normal_set): - # exists: optional - face_normal(NXcg_unit_normal_set): - exists: optional - normals(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Direction of each normal. - dimensions: - rank: 2 - dim: [[1, k], [2, 3]] - orientation(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - Qualifier how which specifically oriented normal to its - primitive each normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner - dimensions: - rank: 1 - dim: [[1, k]] - gradient_guide_magnitude(NX_FLOAT): - unit: NX_ANY - doc: | - Triangle normals are oriented in the direction of the - gradient vector of the local delocalized scalar field. - :math:`\sum_{x, y, z} {\nabla{c}_i}^2`. - dimensions: - rank: 1 - dim: [[1, k]] - - # gradient_guide_quality(NX_FLOAT): - # doc: | - # Triangle normals are oriented in the direction of the - # gradient vector of the local delocalized scalar field. - # Sum of squared values of cross product of triangle normal - # construction. - # unit: NX_ANY - # dim: (k,) - gradient_guide_projection(NX_FLOAT): - unit: NX_ANY - doc: | - Triangle normals are oriented in the direction of the - gradient vector of the local delocalized scalar field. - The projection variable here describes the cosine of the - angle between the gradient direction and the normal - direction vector. - This is a descriptor of how parallel the projection is - that is especially useful to document those triangles - for whose the projection is almost perpendicular. - dimensions: - rank: 1 - dim: [[1, k]] - area(NX_NUMBER): - exists: optional - unit: NX_AREA - dimensions: - rank: 1 - dim: [[1, j]] - edge_length(NX_NUMBER): - exists: optional - unit: NX_LENGTH - doc: | - Array of edge length values. For each triangle the edge length - is reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - dimensions: - rank: 2 - dim: [[1, k], [2, 3]] - interior_angle(NX_NUMBER): - exists: optional - unit: NX_ANGLE - doc: | - Array of interior angle values. For each triangle the angle - is reported for the angle opposite to the edges which are - traversed according to the sequence in which vertices - are indexed in triangles. - dimensions: - rank: 2 - dim: [[1, j], [2, 4]] - center(NX_NUMBER): - exists: optional - unit: NX_LENGTH - doc: | - The center of mass of each triangle. - dimensions: - rank: 2 - dim: [[1, j], [2, 3]] - volumetric_features(NXprocess): - exists: ['min', '0', 'max', '1'] - doc: | - Iso-surfaces of arbitrary scalar three-dimensional fields can show a complicated topology. - Paraprobe-nanochem can run a DBScan-like clustering algorithm which performs a - connectivity analysis on the triangle soup representation of such iso-surface. - This may yield a set of connected features whose individual surfaces are discretized - by a triangulated mesh each. Such volumetric features can be processed further using - paraprobe-nanochem using a workflow with at most two steps. - - In the first step, the tool distinguishes three types of (v) i.e. volumetric features: - - 1. So-called objects, i.e. necessarily watertight features represented by polyhedra. - These objects were already watertight within the triangulated iso-surface. - 2. So-called proxies, i.e. features that were not necessarily watertight within the triangulated - iso-surface but were subsequently replaced by a watertight mesh using polyhedral mesh - processing operations (hole filling, refinement, fairing operations). - 3. Remaining triangle surface meshes or parts of these of arbitrary shape and cardinality - that are not transformable into proxies or for which no transformation into proxies was - instructed. - - These features can be interpreted as microstructural features. Some of them may be precipitates, - some of them may be poles, some of them may be segments of dislocation lines or other - crystal defects which are decorated (or not) with solutes. - - In the second step, the tool can be used to analyze the proximity of these objects to a - model of the surface (edge) of the dataset. - triangle_cluster_identifier(NX_UINT): - unit: NX_UNITLESS - doc: | - The identifier which the triangle_soup connectivity analysis - returned, which constitutes the first step of the - volumetric_feature identification process. - dimensions: - rank: 1 - dim: [[1, n_v_feat]] - feature_type_dict_keyword(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - The array of keywords of feature_type dictionary. - dimensions: - rank: 1 - dim: [[1, n_feature_dict]] - feature_type_dict_value: - exists: optional - doc: | - The array of values for each keyword of the - feature_type dictionary. - dimensions: - rank: 1 - dim: [[1, n_feature_dict]] - feature_type(NX_UINT): - unit: NX_UNITLESS - doc: | - The array of controlled keywords, need to be from - feature_type_dict_keyword, which specify which type - each feature triangle cluster belongs to. - Keep in mind that not each feature is an object or proxy. - dimensions: - rank: 1 - dim: [[1, n_v_feat]] - feature_identifier(NX_UINT): - unit: NX_UNITLESS - doc: | - The explicit identifier of features. - dimensions: - rank: 1 - dim: [[1, n_v_feat]] - FEATURE(NXprocess): - exists: ['min', '0', 'max', '6'] - doc: | - In all situations instances of the parent NXprocess group are returned with a very similar - information structuring and thus we here replace the template name FEATURE - with one of the following types feature-specific group names: - - * objects, objects, irrespective their distance to the surface - * objects_close_to_edge, sub-set of v_feature_object close surface - * objects_far_from_edge, sub-set of v_feature_object not close to the surface - * proxies, proxies, irrespective their distance to the surface - * proxies_close_to_edge, sub-set of v_feature_proxies, close to surface - * proxies_far_from_edge, sub-set of v_feature_proxies, not close to surface - feature_identifier(NX_UINT): - unit: NX_UNITLESS - doc: | - Explicit identifier of the feature a sub-set of the feature_identifier in the - parent group. - dimensions: - rank: 1 - dim: [[1, i]] - volume(NX_FLOAT): - unit: NX_VOLUME - doc: | - Volume of the feature. NaN for non-watertight objects. - dimensions: - rank: 1 - dim: [[1, i]] - obb(NXcg_hexahedron_set): - exists: optional - doc: | - An oriented bounding box (OBB) to each object. - size(NX_FLOAT): - exists: optional - unit: NX_LENGTH - doc: | - Edge length of the oriented bounding box from largest to smallest value. - dimensions: - rank: 2 - dim: [[1, i], [2, 3]] - aspect(NX_FLOAT): - exists: optional - unit: NX_DIMENSIONLESS - doc: | - Oriented bounding box aspect ratio. - YX versus ZY or second-largest over largest and smallest over second largest. - dimensions: - rank: 2 - dim: [[1, i], [2, 2]] - center(NX_NUMBER): - exists: optional - unit: NX_LENGTH - doc: | - Position of the geometric center, which often is but - not necessarily has to be the center_of_mass of the - hexahedrally-shaped sample/sample part. - dimensions: - rank: 2 - dim: [[1, i], [2, 3]] - hexahedra(NXcg_face_list_data_structure): - exists: optional - doc: | - A simple approach to describe the entire set of hexahedra when the main intention - is to store the shape of the hexahedra for visualization. - vertices(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, k], [2, 3]] - - #MK::again we have no effective way to pinpoint the n_rows - #MK::namely k != i each OBB has eight vertices - xdmf_topology(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, k]] - xdmf_feature_identifier(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, k]] - objectID(NXcg_polyhedron_set): - exists: ['min', '0', 'max', 'unbounded'] - polyhedron(NXcg_face_list_data_structure): - - # number_of_vertices(NX_POSINT): - # number_of_faces(NX_POSINT): - # vertex_identifier_offset(NX_UINT): - # face_identifier_offset(NX_UINT): - vertices(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_v], [2, 3]] - faces(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_f], [2, 3]] - face_normals(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_f], [2, 3]] - xdmf_topology(NX_UINT): - exists: recommended - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, k]] - xdmf_feature_identifier(NX_UINT): - exists: recommended - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, k]] - ion_identifier(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - Array of evaporation_identifier / ion_identifier which details which ions - lie inside or on the surface of the feature. - dimensions: - rank: 1 - dim: [[1, m]] - composition(NXchemical_composition): - exists: optional - total(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Total (count) of ions inside or on the surface of the feature relevant for normalization. - NaN for non watertight objects. - dimensions: - rank: 1 - dim: [[1, i]] - ionID(NXion): - exists: ['min', '0', 'max', 'unbounded'] - charge_state(NX_INT): - - # check these two ? - nuclide_hash(NX_UINT): - nuclide_list(NX_UINT): - count(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Count or weight which, when divided by total, yields the composition of this element, - nuclide, or (molecular) ion within the volume of the feature/object. - dimensions: - rank: 1 - dim: [[1, i]] - interface_meshing(NXapm_paraprobe_tool_results): - exists: ['min', '0', 'max', '1'] - window(NXcs_filter_boolean_mask): - number_of_ions(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - - # results - ion_multiplicity(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - The multiplicity whereby the ion position is accounted for - irrespective whether the ion is considered as a decorator - of the interface or not. - As an example, with atom probe it is typically not possible - to resolve the positions of the atoms which arrive at the detector - as molecular ions. Therefore, an exemplar molecular ion of two carbon - atoms can be considered to have a multiplicity of two to account that - this molecular ion contributes two carbon atoms at the reconstructed - location considering that the spatial resolution of atom probe - experiments is limited. - dimensions: - rank: 1 - dim: [[1, n_ions]] - decorator_multiplicity(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - The multiplicity whereby the ion position is accounted for when - the ion is considered one which is a decorator of the interface. - dimensions: - rank: 1 - dim: [[1, n_ions]] - initial_interface(NXprocess): - exists: optional - doc: | - The equation of the plane that is fitted initially. - point_normal_form(NX_FLOAT): - unit: NX_LENGTH - doc: | - The four parameter :math:`ax + by + cz + d = 0` which define the plane. - dimensions: - rank: 1 - dim: [[1, 4]] - mesh_stateID(NXcg_triangle_set): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - The triangle surface mesh representing the interface model. - Exported at state before or after the next DCOM step. - state(NX_CHAR): - doc: | - Was this state exported before or after the next DCOM step. - enumeration: [before, after] - dimensionality(NX_POSINT): - unit: NX_UNITLESS - cardinality(NX_POSINT): - unit: NX_UNITLESS - identifier_offset(NX_INT): - unit: NX_UNITLESS - triangles(NXcg_face_list_data_structure): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - number_of_vertices(NX_POSINT): - unit: NX_UNITLESS - number_of_faces(NX_POSINT): - unit: NX_UNITLESS - vertex_identifier_offset(NX_INT): - unit: NX_UNITLESS - edge_identifier_offset(NX_INT): - unit: NX_UNITLESS - face_identifier_offset(NX_INT): - unit: NX_UNITLESS - face_identifier(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, j]] - vertices(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, i], [2, 3]] - vertex_normal(NX_FLOAT): - unit: NX_LENGTH - doc: | - Direction of each vertex normal. - dimensions: - rank: 2 - dim: [[1, i], [2, 3]] - vertex_normal_orientation(NX_UINT): - unit: NX_UNITLESS - doc: | - Qualifier which details how specifically oriented the - face normal is with respect to its primitive (triangle): - - * 0 - undefined - * 1 - outer - * 2 - inner - dimensions: - rank: 1 - dim: [[1, i]] - faces(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, j], [2, 3]] - face_normal(NX_FLOAT): - unit: NX_LENGTH - doc: | - Direction of each face normal. - dimensions: - rank: 2 - dim: [[1, j], [2, 3]] - face_normal_orientation(NX_UINT): - unit: NX_UNITLESS - doc: | - Qualifier which details how specifically oriented the - face normal is with respect to its primitive (triangle): - - * 0 - undefined - * 1 - outer - * 2 - inner - dimensions: - rank: 1 - dim: [[1, j]] - xdmf_topology(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, k]] - area(NX_NUMBER): - unit: NX_AREA - dimensions: - rank: 1 - dim: [[1, c]] - edge_length(NX_NUMBER): - unit: NX_LENGTH - doc: | - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] - interior_angle(NX_NUMBER): - unit: NX_ANGLE - doc: | - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. - dimensions: - rank: 2 - dim: [[1, c], [2, 4]] - oned_profile(NXapm_paraprobe_tool_results): - exists: ['min', '0', 'max', '1'] - window(NXcs_filter_boolean_mask): - exists: optional - number_of_ions(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - - # results - xdmf_cylinder(NXcg_polyhedron_set): - doc: | - The ROIs are defined as cylinders for the computations. To visualize these we discretize - them into regular n-gons. Using for instance 360-gons, i.e. a regular n-gon with 360 edges, - resolves the lateral surface of each cylinder such that their renditions are smooth in - visualization software like Paraview. - dimensionality(NX_POSINT): - unit: NX_UNITLESS - cardinality(NX_POSINT): - unit: NX_UNITLESS - center(NX_NUMBER): - unit: NX_LENGTH - doc: | - Position of the geometric center, which often is but not - necessarily has to be the center_of_mass of the polyhedra. - dimensions: - rank: 2 - dim: [[1, i], [2, 3]] - orientation(NX_FLOAT): - unit: NX_LENGTH - doc: | - The orientation of the ROI defined via a vector which points along - the cylinder axis and whose length is the height of the cylinder. - dimensions: - rank: 2 - dim: [[1, i], [2, 3]] - - # XDMF support - identifier(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - XDMF support to enable colouring each ROI by its identifier. - dimensions: - rank: 1 - dim: [[1, j]] - edge_contact(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - XDMF support to enable colouring each ROI whether it has edge contact or not. - dimensions: - rank: 1 - dim: [[1, j]] - number_of_atoms(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - XDMF support to enable colouring each ROI by its number of atoms. - dimensions: - rank: 1 - dim: [[1, j]] - number_of_ions(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - XDMF support to enable colouring each ROI by its number of ions. - dimensions: - rank: 1 - dim: [[1, j]] - rois_far_from_edge(NXprocess): - doc: | - Distance and iontype-specific processed data for each ROI. - Arrays signed_distance and nuclide_hash are sorted by increasing - distance. - Array nuclide_hash reports one hash for each atom of each isotope. - Effectively, this can yield to groups of values on signed_distance - with the same distance value as molecular ions are reported decomposed - into their atoms. - Therefore, the XDMF support fields number_of_atoms and number_of_ions - are only expected to display pairwise the same values respectively, - if all ions are built from a single atom only. - roiID(NXobject): - exists: ['min', '0', 'max', 'unbounded'] - signed_distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Sorted in increasing order projected along the positive direction - of the ROI as defined by orientation in the parent group. - dimensions: - rank: 1 - dim: [[1, k]] - nuclide_hash(NX_UINT): - unit: NX_UNITLESS - doc: | - Hashvalue as defined in :ref:`NXion`. - dimensions: - rank: 1 - dim: [[1, k]] - common(NXapm_paraprobe_tool_common): - status(NX_CHAR): - analysis_identifier(NX_UINT): - config(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - profiling(NXcs_profiling): - exists: recommended - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - total_elapsed_time(NX_FLOAT): - current_working_directory(NX_CHAR): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - userID(NXuser): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - If used, metadata of at least the person who performed this analysis. - name(NX_CHAR): - coordinate_system_set(NXcoordinate_system_set): - exists: ['min', '1', 'max', '1'] - paraprobe(NXcoordinate_system): - type(NX_CHAR): - handedness(NX_CHAR): - x(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - y(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - z(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# cf0eca2c8f8d9502e181f8b2627688b4c1068a30da0160e761ccc31e2f1ac2bc -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The total number of ions in the reconstruction. -# -# -# -# -# The total number of atoms in the atomic_decomposition match filter. -# -# -# -# -# The total number of isotopes in the isotopic_decomposition match filter. -# -# -# -# -# The dimensionality of the delocalization grid. -# -# -# -# -# The cardinality/total number of cells/grid points in the delocalization grid. -# -# -# -# -# -# The total number of faces of triangles. -# -# -# -# -# The total number of XDMF values to represent all faces of triangles via XDMF. -# -# -# -# -# The total number of entries in a feature dictionary. -# -# -# -# -# The total number of volumetric features. -# -# -# -# -# The total number of member distinguished when reporting composition. -# -# -# -# -# The total number of ROIs placed in an oned_profile task. -# -# -# -# -# Application definition for results files of the paraprobe-nanochem tool. -# -# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# How were results of the kernel-density estimation normalized: -# * total, the total number (intensity) of ions or elements. -# * candidates, the total number (intensity) of ions matching weighting_model -# * composition, the value for candidates divided by the value for total, -# * concentration, the value for candidates divided by the volume of the cell. -# -# -# -# -# -# -# -# -# -# -# The discretized domain/grid on which the delocalization is applied. -# -# -# -# -# -# -# -# -# -# -# The total number of cells/voxels of the grid. -# -# -# -# -# -# -# -# -# -# The symmetry of the lattice defining the shape of the unit cell. -# -# -# -# -# -# -# -# The unit cell dimensions according to the coordinate system defined under -# coordinate_system. -# -# -# -# -# -# -# -# Number of unit cells along each of the d-dimensional base vectors. -# The total number of cells, or grid points has to be the cardinality. -# If the grid has an irregular number of grid positions in each direction, -# as it could be for instance the case of a grid where all grid points -# outside some masking primitive are removed, this extent field should -# not be used. Instead use the coordinate field. -# -# -# -# -# -# -# -# -# Integer which specifies the first index to be used for distinguishing identifiers for cells. -# Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are -# defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. -# For explicit indexing the identifier array has to be defined. -# -# -# -# -# Halfwidth of the kernel about the central voxel. -# The shape of the kernel is that of a cuboid -# of extent 2*kernel_extent[i] + 1 in each dimension i. -# -# -# -# -# -# -# -# Functional form of the kernel (Ansatz function). -# -# -# -# -# -# -# -# Standard deviation :math:`\sigma_i` of the kernel in each dimension -# in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. -# -# -# -# -# -# -# -# Expectation value :math:`\mu_i` of the kernel in each dimension -# in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. -# -# -# -# -# -# -# -# A tight axis-aligned bounding box about the grid. -# -# -# -# For atom probe should be set to true. -# -# -# -# -# Integer which specifies the first index to be used for distinguishing -# hexahedra. Identifiers are defined either implicitly or explicitly. -# For implicit indexing the identifiers are defined on the interval -# :math:`[identifier\_offset, identifier\_offset + c - 1]`. -# For explicit indexing the identifier array has to be defined. -# -# -# -# -# -# Integer which specifies the first index to be used for distinguishing -# identifiers for vertices. Identifiers are defined either implicitly or explicitly. -# For implicit indexing the identifiers are defined on the interval -# :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array -# has to be defined. -# -# -# -# -# Integer which specifies the first index to be used for distinguishing -# identifiers for faces. Identifiers are defined either implicitly or explicitly. -# For implicit indexing the identifiers are defined on the interval -# :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array -# has to be defined. -# -# -# -# -# Positions of the vertices. -# Users are encouraged to reduce the vertices to unique set of positions -# and vertices as this supports a more efficient storage of the geometry data. -# It is also possible though to store the vertex positions naively in which -# case vertices_are_unique is likely False. -# Naively here means that one for example stores each vertex of a triangle -# mesh even though many vertices are shared between triangles and thus -# the positions of these vertices do not have to be duplicated. -# -# -# -# -# -# -# -# -# Array of identifiers from vertices which describe each face. -# -# The first entry is the identifier of the start vertex of the first face, -# followed by the second vertex of the first face, until the last vertex -# of the first face. Thereafter, the start vertex of the second face, the -# second vertex of the second face, and so on and so forth. -# -# Therefore, summating over the number_of_vertices, allows to extract -# the vertex identifiers for the i-th face on the following index interval -# of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. -# -# -# -# -# -# -# -# -# Six equally formatted sextets chained together. For each sextett the first entry is an -# XDMF primitive topology key (here 5 for polygon), the second entry the XDMF -# primitive count value (here 4 because each face is a quad). -# The remaining four values are the vertex indices. -# -# -# -# -# -# -# -# How many distinct boundaries are distinguished? -# Most grids discretize a cubic or cuboidal region. In this case -# six sides can be distinguished, each making an own boundary. -# -# -# -# -# Name of the boundaries. E.g. left, right, front, back, bottom, top, -# The field must have as many entries as there are number_of_boundaries. -# -# -# -# -# -# -# -# The boundary conditions for each boundary: -# -# 0 - undefined -# 1 - open -# 2 - periodic -# 3 - mirror -# 4 - von Neumann -# 5 - Dirichlet -# -# -# -# -# -# -# -# -# -# -# The result of the delocalization :math:`\Phi = f(x, y, z)` based on which subsequent iso-surfaces -# will be computed. In commercial software so far there is no possibility to export this information. -# -# If the intensity for all matches of the weighting_model are summarized name this NXdata instance -# scalar_field_magn_total. -# -# If the intensity is reported for each iontype one can avoid many subsequent -# computations as individual intensities can be reinterpreted using a different weighting_model in -# down-stream usage of the here reported values (e.g. with Python scripting). -# In this case name the individual NXdata instances scalar_field_magn_ionID using the ID of the ion as -# per the configuration of the ranging definitions used. -# -# -# -# -# -# -# -# -# -# The actual delocalized intensity values. -# -# -# -# -# -# -# -# -# -# Cell center of mass positions along x. -# -# -# -# -# -# -# -# Cell center of mass positions along y. -# -# -# -# -# -# -# -# Cell center of mass positions along z. -# -# -# -# -# -# -# -# Intensity of the field at given point -# -# -# -# -# -# -# -# Center of mass positions of each voxel for rendering the scalar field -# via XDMF in e.g. Paraview. -# -# -# -# -# -# -# -# -# XDMF topology for rendering in combination with xdmf_xyz the scalar field -# via XDMF in e.g. Paraview. -# -# -# -# -# -# -# -# -# The three-dimensional gradient :math:`\nabla \Phi`. -# Follow the naming convention of scalar_field_magn_SUFFIX to report parallel structures. -# -# -# -# -# -# -# -# -# -# The actual point-wise component values. -# -# -# -# -# -# -# -# -# -# -# Cell center of mass positions along x. -# -# -# -# -# -# -# -# Cell center of mass positions along y. -# -# -# -# -# -# -# -# Cell center of mass positions along z. -# -# -# -# -# -# -# -# The gradient vector formatted for direct visualization via XDMF in e.g. -# Paraview. -# -# -# -# -# -# -# -# -# Center of mass positions of each voxel for rendering the scalar field gradient -# via XDMF in e.g. Paraview. -# -# -# -# -# -# -# -# -# XDMF topology for rendering in combination with xdmf_xyz the scalar field -# via XDFM in e.g. Paraview. -# -# -# -# -# -# -# -# -# -# An iso-surface is the boundary between two regions across which the magnitude of a -# scalar field falls below/exceeds a threshold magnitude :math:`\varphi`. -# -# For applications in atom probe microscopy, the location and shape of such a boundary (set) -# is typically approximated by discretization - triangulation to be specific. -# -# This yields a complex of not necessarily connected geometric primitives. -# Paraprobe-nanochem approximates this complex with a soup of triangles. -# -# -# -# -# The threshold or iso-contour value :math:`\varphi`. -# -# -# -# -# Details about the specific marching cubes algorithm that was used for computing -# the iso-surface. -# -# -# -# Reference to the specific implementation of marching cubes used. -# The value placed here should be a DOI. If there are no specific -# DOI or details write not_further_specified, or give at least a -# free-text description. The program and version used is the -# specific paraprobe-nanochem. -# -# -# -# -# -# The resulting triangle soup computed via marching cubes. -# -# -# -# -# -# Integer which specifies the first index to be used for distinguishing triangles. -# Identifiers are defined either implicitly or explicitly. For implicit indexing the -# identifiers are defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. -# -# -# -# -# -# -# -# -# -# Positions of the vertices. -# -# Users are encouraged to reduce the vertices to a unique set as this may -# result in a more efficient storage of the geometry data. -# It is also possible though to store the vertex positions naively in which -# case vertices_are_unique is likely False. Naively here means that each -# vertex is stored even though many share the same positions. -# -# -# -# -# -# -# -# -# Array of identifiers from vertices which describe each face. -# -# The first entry is the identifier of the start vertex of the first face, -# followed by the second vertex of the first face, until the last vertex -# of the first face. Thereafter, the start vertex of the second face, the -# second vertex of the second face, and so on and so forth. -# -# Therefore, summating over the number_of_vertices, allows to extract -# the vertex identifiers for the i-th face on the following index interval -# of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. -# -# -# -# -# -# -# -# A list of as many tuples of XDMF topology key, XDMF number -# of vertices and a triple of vertex indices specifying each -# triangle. The total number of entries is n_f_tri * (1+1+3). -# -# -# -# -# -# -# -# -# Direction of each normal. -# -# -# -# -# -# -# -# -# Qualifier how which specifically oriented normal to its -# primitive each normal represents. -# -# * 0 - undefined -# * 1 - outer -# * 2 - inner -# -# -# -# -# -# -# -# -# -# -# Direction of each normal. -# -# -# -# -# -# -# -# -# Qualifier how which specifically oriented normal to its -# primitive each normal represents. -# -# * 0 - undefined -# * 1 - outer -# * 2 - inner -# -# -# -# -# -# -# -# Triangle normals are oriented in the direction of the -# gradient vector of the local delocalized scalar field. -# :math:`\sum_{x, y, z} {\nabla{c}_i}^2`. -# -# -# -# -# -# -# -# -# Triangle normals are oriented in the direction of the -# gradient vector of the local delocalized scalar field. -# The projection variable here describes the cosine of the -# angle between the gradient direction and the normal -# direction vector. -# This is a descriptor of how parallel the projection is -# that is especially useful to document those triangles -# for whose the projection is almost perpendicular. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Array of edge length values. For each triangle the edge length -# is reported for the edges traversed according to the sequence -# in which vertices are indexed in triangles. -# -# -# -# -# -# -# -# -# Array of interior angle values. For each triangle the angle -# is reported for the angle opposite to the edges which are -# traversed according to the sequence in which vertices -# are indexed in triangles. -# -# -# -# -# -# -# -# -# The center of mass of each triangle. -# -# -# -# -# -# -# -# -# Iso-surfaces of arbitrary scalar three-dimensional fields can show a complicated topology. -# Paraprobe-nanochem can run a DBScan-like clustering algorithm which performs a -# connectivity analysis on the triangle soup representation of such iso-surface. -# This may yield a set of connected features whose individual surfaces are discretized -# by a triangulated mesh each. Such volumetric features can be processed further using -# paraprobe-nanochem using a workflow with at most two steps. -# -# In the first step, the tool distinguishes three types of (v) i.e. volumetric features: -# -# 1. So-called objects, i.e. necessarily watertight features represented by polyhedra. -# These objects were already watertight within the triangulated iso-surface. -# 2. So-called proxies, i.e. features that were not necessarily watertight within the triangulated -# iso-surface but were subsequently replaced by a watertight mesh using polyhedral mesh -# processing operations (hole filling, refinement, fairing operations). -# 3. Remaining triangle surface meshes or parts of these of arbitrary shape and cardinality -# that are not transformable into proxies or for which no transformation into proxies was -# instructed. -# -# These features can be interpreted as microstructural features. Some of them may be precipitates, -# some of them may be poles, some of them may be segments of dislocation lines or other -# crystal defects which are decorated (or not) with solutes. -# -# In the second step, the tool can be used to analyze the proximity of these objects to a -# model of the surface (edge) of the dataset. -# -# -# -# The identifier which the triangle_soup connectivity analysis -# returned, which constitutes the first step of the -# volumetric_feature identification process. -# -# -# -# -# -# -# -# The array of keywords of feature_type dictionary. -# -# -# -# -# -# -# -# The array of values for each keyword of the -# feature_type dictionary. -# -# -# -# -# -# -# -# The array of controlled keywords, need to be from -# feature_type_dict_keyword, which specify which type -# each feature triangle cluster belongs to. -# Keep in mind that not each feature is an object or proxy. -# -# -# -# -# -# -# -# The explicit identifier of features. -# -# -# -# -# -# -# -# In all situations instances of the parent NXprocess group are returned with a very similar -# information structuring and thus we here replace the template name FEATURE -# with one of the following types feature-specific group names: -# -# * objects, objects, irrespective their distance to the surface -# * objects_close_to_edge, sub-set of v_feature_object close surface -# * objects_far_from_edge, sub-set of v_feature_object not close to the surface -# * proxies, proxies, irrespective their distance to the surface -# * proxies_close_to_edge, sub-set of v_feature_proxies, close to surface -# * proxies_far_from_edge, sub-set of v_feature_proxies, not close to surface -# -# -# -# Explicit identifier of the feature a sub-set of the feature_identifier in the -# parent group. -# -# -# -# -# -# -# -# Volume of the feature. NaN for non-watertight objects. -# -# -# -# -# -# -# -# An oriented bounding box (OBB) to each object. -# -# -# -# Edge length of the oriented bounding box from largest to smallest value. -# -# -# -# -# -# -# -# -# Oriented bounding box aspect ratio. -# YX versus ZY or second-largest over largest and smallest over second largest. -# -# -# -# -# -# -# -# -# Position of the geometric center, which often is but -# not necessarily has to be the center_of_mass of the -# hexahedrally-shaped sample/sample part. -# -# -# -# -# -# -# -# -# A simple approach to describe the entire set of hexahedra when the main intention -# is to store the shape of the hexahedra for visualization. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Array of evaporation_identifier / ion_identifier which details which ions -# lie inside or on the surface of the feature. -# -# -# -# -# -# -# -# -# -# -# Total (count) of ions inside or on the surface of the feature relevant for normalization. -# NaN for non watertight objects. -# -# -# -# -# -# -# -# -# -# -# -# -# Count or weight which, when divided by total, yields the composition of this element, -# nuclide, or (molecular) ion within the volume of the feature/object. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The multiplicity whereby the ion position is accounted for -# irrespective whether the ion is considered as a decorator -# of the interface or not. -# As an example, with atom probe it is typically not possible -# to resolve the positions of the atoms which arrive at the detector -# as molecular ions. Therefore, an exemplar molecular ion of two carbon -# atoms can be considered to have a multiplicity of two to account that -# this molecular ion contributes two carbon atoms at the reconstructed -# location considering that the spatial resolution of atom probe -# experiments is limited. -# -# -# -# -# -# -# -# The multiplicity whereby the ion position is accounted for when -# the ion is considered one which is a decorator of the interface. -# -# -# -# -# -# -# -# The equation of the plane that is fitted initially. -# -# -# -# The four parameter :math:`ax + by + cz + d = 0` which define the plane. -# -# -# -# -# -# -# -# -# The triangle surface mesh representing the interface model. -# Exported at state before or after the next DCOM step. -# -# -# -# Was this state exported before or after the next DCOM step. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of each vertex normal. -# -# -# -# -# -# -# -# -# Qualifier which details how specifically oriented the -# face normal is with respect to its primitive (triangle): -# -# * 0 - undefined -# * 1 - outer -# * 2 - inner -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of each face normal. -# -# -# -# -# -# -# -# -# Qualifier which details how specifically oriented the -# face normal is with respect to its primitive (triangle): -# -# * 0 - undefined -# * 1 - outer -# * 2 - inner -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Array of edge length values. For each triangle the edge length is -# reported for the edges traversed according to the sequence -# in which vertices are indexed in triangles. -# -# -# -# -# -# -# -# -# Array of interior angle values. For each triangle the angle is -# reported for the angle opposite to the edges which are traversed -# according to the sequence in which vertices are indexed in triangles. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The ROIs are defined as cylinders for the computations. To visualize these we discretize -# them into regular n-gons. Using for instance 360-gons, i.e. a regular n-gon with 360 edges, -# resolves the lateral surface of each cylinder such that their renditions are smooth in -# visualization software like Paraview. -# -# -# -# -# -# Position of the geometric center, which often is but not -# necessarily has to be the center_of_mass of the polyhedra. -# -# -# -# -# -# -# -# -# The orientation of the ROI defined via a vector which points along -# the cylinder axis and whose length is the height of the cylinder. -# -# -# -# -# -# -# -# -# -# XDMF support to enable colouring each ROI by its identifier. -# -# -# -# -# -# -# -# XDMF support to enable colouring each ROI whether it has edge contact or not. -# -# -# -# -# -# -# -# XDMF support to enable colouring each ROI by its number of atoms. -# -# -# -# -# -# -# -# XDMF support to enable colouring each ROI by its number of ions. -# -# -# -# -# -# -# -# Distance and iontype-specific processed data for each ROI. -# Arrays signed_distance and nuclide_hash are sorted by increasing -# distance. -# Array nuclide_hash reports one hash for each atom of each isotope. -# Effectively, this can yield to groups of values on signed_distance -# with the same distance value as molecular ions are reported decomposed -# into their atoms. -# Therefore, the XDMF support fields number_of_atoms and number_of_ions -# are only expected to display pairwise the same values respectively, -# if all ions are built from a single atom only. -# -# -# -# -# Sorted in increasing order projected along the positive direction -# of the ROI as defined by orientation in the parent group. -# -# -# -# -# -# -# -# Hashvalue as defined in :ref:`NXion`. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If used, metadata of at least the person who performed this analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml deleted file mode 100644 index 5c625dc126..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml +++ /dev/null @@ -1,471 +0,0 @@ -category: application -doc: | - Application definition for a configuration file of the paraprobe-ranger tool. - - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_nuclids: | - The number of isotopes to consider as building blocks for searching molecular - ions. - n_composition: | - The number of compositions to consider for molecular ion search tasks. -type: group -NXapm_paraprobe_ranger_config(NXobject): - (NXentry): - exists: ['min', '1', 'max', '1'] - definition(NX_CHAR): - \@version: - type: NX_CHAR - enumeration: [NXapm_paraprobe_ranger_config] - - # tool-specific - range(NXapm_paraprobe_tool_config): - exists: ['min', '1', 'max', '1'] - (NXidentifier): - exists: optional - analysis_identifier(NX_UINT): - exists: recommended - reconstruction(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - position(NX_CHAR): - mass_to_charge(NX_CHAR): - ranging(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - ranging_definitions(NX_CHAR): - - # filter - spatial_filter(NXspatial_filter): - windowing_method(NX_CHAR): - hexahedron_set(NXcg_hexahedron_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - hexahedra(NXcg_face_list_data_structure): - vertices(NX_UINT): - cylinder_set(NXcg_cylinder_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - height(NX_NUMBER): - radii(NX_NUMBER): - ellipsoid_set(NXcg_ellipsoid_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - half_axes_radii(NX_NUMBER): - orientation(NX_NUMBER): - polyhedron_set(NXcg_polyhedron_set): - exists: optional - - # TODO - bitmask(NXcs_filter_boolean_mask): - exists: optional - number_of_objects(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - - # leave open if scalar or matrix - # dim: (i,) - identifier(NX_UINT): - evaporation_id_filter(NXsubsampling_filter): - exists: optional - min_incr_max(NX_INT): - iontype_filter(NXmatch_filter): - exists: optional - method(NX_CHAR): - match(NX_NUMBER): - hit_multiplicity_filter(NXmatch_filter): - exists: optional - method(NX_CHAR): - match(NX_NUMBER): - - # tool-specific parameter - # molecular_ion_search(NXapm_paraprobe_tool_config): - # exists: ['min', '0', 'max', 'unbounded'] - # extent if needed - # assumed_composition_isotopes(NX_UINT): - # exists: optional - # doc: | - # A list of pairs of number of protons and either the value 0 (per row) - # or the mass number for all those isotopes which are assumed present - # in a virtual specimen. - # The purpose of this field is to compute also composition-weighted - # products to yield a simple estimation which could potentially help - # scientists to judge if certain molecular ions are to be expected. - # The corresponding setting store_composition_weighted_product should be - # activated. - # unit: NX_UNITLESS - # dim: (n_composition, 2) - # assumed_composition_value(NX_FLOAT): - # doc: | - # A list of atomic (at.-%) ! percent values for the composition of each - # isotope in the virtual specimen following the sequence of - # assumed_composition_isotopes. - # unit: NX_DIMENSIONLESS - # dim: (n_compositions,) - # isotope_whitelist(NX_UINT): - # doc: | - # A list of pairs of number of protons and mass number for all isotopes - # to consider that can be composed into (molecular) ions, during the - # recursive molecular_ion_search. - # unit: NX_UNITLESS - # dim: (n_nuclids, 2) - # mass_to_charge_interval(NX_FLOAT): - # doc: | - # The mass-to-charge-state ratio interval in which - # all molecular ions are searched. - # unit: NX_ANY # u - # dim: (2,) - # maximum_charge(NX_UINT): - # doc: | - # The maximum charge that a molecular ion should have. - # unit: NX_UNITLESS - # maximum_number_of_isotopes(NX_UINT): - # doc: | - # The maximum number of isotopes of which the molecular ion - # should be composed. Currently this must not be larger than 32. - - # Users should be warned that the larger the maximum_charge and - # especially the larger the maximum_number_of_isotopes is chosen, - # the eventually orders of magnitude more costly the search becomes. - - # This is because paraprobe-ranger computes really all (at least) - # theoretically possible combinations that would have likely a - # mass-to-charge-state ratio in the specified mass_to_charge_interval. - # It is the challenge in atom probe to judge which of these (molecular) - # ions are feasible and also practically possible. This tool does not - # answer this question. - - # Namely, which specific molecular ion will evaporate, remain stable - # during flight and becomes detected is a complicated and in many cases - # not yet in detail understood phenomenon. The ab-initio conditions - # before and during launch, the local environment, arrangement and field - # as well as the flight phase in an evacuated but not analysis chamber - # with a complex electrical field, eventual laser pulsing in place, - # temperature and remaining atoms or molecules all can have an effect - # which iontypes are really physically evaporating and detected. - # unit: NX_UNITLESS - # store_atomic_mass_sum(NX_BOOLEAN): - # doc: | - # Report the accumulated atomic mass from each isotope building the ion. - # Accounts for each identified ion. Relatistic effects are not accounted for. - # store_natural_abundance_product(NX_BOOLEAN): - # doc: | - # Report the product of the natural abundances from each isotope building - # the ion. Accounts for each identified ion. - - # The value zero indicates it is not possible to build such molecular ion - # from nuclids which are all observationally stable. - # Very small values can give an idea/about how likely such a molecular ion - # is expected to form assuming equal probabilities. - - # However in atom probe experiments this product has to be modified - # by the (spatially-correlated) local composition in the region from - # which the ions launch because the formation of a molecular ion depends - # as summarized under maximum_number_of_isotopes on the specific - # quantum-mechanical configuration and field state upon launch - # or/and (early state) of flight respectively. - # We are aware that this modified product can have a substantially - # different value than the natural_abundance_product. - - # Natural abundancies folded with the estimated compositions of the - # specimen can differ by orders of magnitude. - # add assumed composition of the specimen - # store_composition_weighted_product(NX_BOOLEAN): - # doc: | - # Report the product of the composition from each isotope building the - # ion. This sets strong constraints on the molecular ions which are - # expected to have at all a noteworthy product value. - # It should not be forgotten though the computation relies on assumptions: - - # * The composition is homogeneous within the virtual specimen. - # * It is a priori known which nuclids the specimen is build of. - - # store_charge_state(NX_BOOLEAN): - # doc: | - # Report the charge state of the ions. - # store_disjoint_isotopes(NX_BOOLEAN): - # doc: | - # Report if identified ions should be characterized wrt to their number of disjoint isotopes. - # check_existent_ranging(NXapm_paraprobe_tool_config): - # exists: ['min', '0', 'max', '1'] - # ranging(NXserialized): - # type(NX_CHAR): - # path(NX_CHAR): - # checksum(NX_CHAR): - # algorithm(NX_CHAR): - # ranging_definitions(NX_CHAR): - common(NXapm_paraprobe_tool_common): - status(NX_CHAR): - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - profiling(NXcs_profiling): - exists: recommended - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - total_elapsed_time(NX_FLOAT): - current_working_directory(NX_CHAR): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 45a4ba9f9e05881d05976166bfad4eccafbd61896ef7e049dc30f4457cd69bb8 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The number of isotopes to consider as building blocks for searching molecular -# ions. -# -# -# -# -# The number of compositions to consider for molecular ion search tasks. -# -# -# -# -# Application definition for a configuration file of the paraprobe-ranger tool. -# -# This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml deleted file mode 100644 index 94c0a37ec0..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml +++ /dev/null @@ -1,248 +0,0 @@ -category: application -doc: | - Application definition for results files of the paraprobe-ranger tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. - The purpose and need of the paraprobe-ranger tool is to apply a given set of ranging definitions within - a certain (possibly complicated) selection of ions (based on their properties or location in the - reconstructed volume. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_ions: | - The total number of ions in the reconstructed volume. -type: group -NXapm_paraprobe_ranger_results(NXobject): - (NXentry): - exists: ['min', '1', 'max', '1'] - definition(NX_CHAR): - \@version: - type: NX_CHAR - enumeration: [NXapm_paraprobe_ranger_results] - - # tasks - iontypes(NXapm_paraprobe_tool_results): - doc: | - Paraprobe-ranger loads the iontypes and evaluates for each - ion on which iontype it matches. If it matches on None, the - ion is considered of the default *unknown_type*. This iontype - is marked with a 0 in the iontypes array. - - #MK::number_of_ion_types(NX_POSINT): - # config - window(NXcs_filter_boolean_mask): - number_of_ions(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - - # results - (NXion): - exists: ['min', '1', 'max', '256'] - nuclide_hash(NX_UINT): - nuclide_list(NX_UINT): - exists: recommended - charge_state(NX_INT): - mass_to_charge_range(NX_FLOAT): - name(NX_CHAR): - exists: optional - iontypes(NX_UINT): - unit: NX_UNITLESS - doc: | - The iontype (identifier) for each ion that was best matching, stored - in the order of the evaporation sequence ID. The here computed iontypes - do not take into account the charge state of the ion which is - equivalent to interpreting a RNG and RRNG range files for each - ion in such a way that only the those elements are considered of which - a (molecular) ion is assumed composed according to the NXion instances. - dimensions: - rank: 1 - dim: [[1, n_ions]] - common(NXapm_paraprobe_tool_common): - status(NX_CHAR): - analysis_identifier(NX_UINT): - config(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - profiling(NXcs_profiling): - exists: recommended - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - total_elapsed_time(NX_FLOAT): - current_working_directory(NX_CHAR): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - userID(NXuser): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - If used, metadata of at least the person who performed this analysis. - name(NX_CHAR): - coordinate_system_set(NXcoordinate_system_set): - exists: ['min', '1', 'max', '1'] - paraprobe(NXcoordinate_system): - type(NX_CHAR): - handedness(NX_CHAR): - x(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - y(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - z(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# c1d94f5a0a8eaeb2f4b3b58747c3382a7c43555a47c504e2a4492b28262e398f -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The total number of ions in the reconstructed volume. -# -# -# -# -# Application definition for results files of the paraprobe-ranger tool. -# -# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. -# The purpose and need of the paraprobe-ranger tool is to apply a given set of ranging definitions within -# a certain (possibly complicated) selection of ions (based on their properties or location in the -# reconstructed volume. -# -# -# -# -# -# -# -# -# -# -# -# Paraprobe-ranger loads the iontypes and evaluates for each -# ion on which iontype it matches. If it matches on None, the -# ion is considered of the default *unknown_type*. This iontype -# is marked with a 0 in the iontypes array. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The iontype (identifier) for each ion that was best matching, stored -# in the order of the evaporation sequence ID. The here computed iontypes -# do not take into account the charge state of the ion which is -# equivalent to interpreting a RNG and RRNG range files for each -# ion in such a way that only the those elements are considered of which -# a (molecular) ion is assumed composed according to the NXion instances. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If used, metadata of at least the person who performed this analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml deleted file mode 100644 index 8dbf3aaa11..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml +++ /dev/null @@ -1,227 +0,0 @@ -category: application -doc: | - Application definition for a configuration file of the paraprobe-selector tool. - - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXapm_paraprobe_selector_config(NXobject): - (NXentry): - exists: ['min', '1', 'max', '1'] - definition(NX_CHAR): - \@version: - type: NX_CHAR - enumeration: [NXapm_paraprobe_selector_config] - select(NXapm_paraprobe_tool_config): - exists: ['min', '1', 'max', '1'] - (NXidentifier): - exists: optional - analysis_identifier(NX_UINT): - exists: recommended - reconstruction(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - position(NX_CHAR): - mass_to_charge(NX_CHAR): - ranging(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - ranging_definitions(NX_CHAR): - - # filter that represent here also the tool-specific config - spatial_filter(NXspatial_filter): - windowing_method(NX_CHAR): - hexahedron_set(NXcg_hexahedron_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - hexahedra(NXcg_face_list_data_structure): - vertices(NX_UINT): - cylinder_set(NXcg_cylinder_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - height(NX_NUMBER): - radii(NX_NUMBER): - ellipsoid_set(NXcg_ellipsoid_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - half_axes_radii(NX_NUMBER): - orientation(NX_NUMBER): - polyhedron_set(NXcg_polyhedron_set): - exists: optional - - # TODO - bitmask(NXcs_filter_boolean_mask): - exists: optional - number_of_objects(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - - # leave open if scalar or matrix - # dim: (i,) - identifier(NX_UINT): - evaporation_id_filter(NXsubsampling_filter): - exists: optional - min_incr_max(NX_INT): - iontype_filter(NXmatch_filter): - exists: optional - method(NX_CHAR): - match(NX_NUMBER): - hit_multiplicity_filter(NXmatch_filter): - exists: optional - method(NX_CHAR): - match(NX_NUMBER): - common(NXapm_paraprobe_tool_common): - status(NX_CHAR): - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - profiling(NXcs_profiling): - exists: recommended - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - total_elapsed_time(NX_FLOAT): - current_working_directory(NX_CHAR): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 548e90a53cb2e0a75151ca12521ce2d822634a0d610ccda5d2e5469d8311afce -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Application definition for a configuration file of the paraprobe-selector tool. -# -# This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml deleted file mode 100644 index 3f03033235..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml +++ /dev/null @@ -1,191 +0,0 @@ -category: application -doc: | - Application definition for results files of the paraprobe-selector tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. - The purpose and need of the paraprobe-selector tool is to identify which reconstructed positions - are located inside or on the surface of a (possibly complicated) region-of-interest (ROI). - In addition, the tool allows to filter ions for properties. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_ions: | - The total number of ions in the reconstruction. -type: group -NXapm_paraprobe_selector_results(NXobject): - (NXentry): - exists: ['min', '1', 'max', '1'] - definition(NX_CHAR): - \@version: - type: NX_CHAR - enumeration: [NXapm_paraprobe_selector_results] - - # tasks - roi(NXapm_paraprobe_tool_results): - - # results - window(NXcs_filter_boolean_mask): - number_of_ions(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - common(NXapm_paraprobe_tool_common): - status(NX_CHAR): - analysis_identifier(NX_UINT): - config(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - profiling(NXcs_profiling): - exists: recommended - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - total_elapsed_time(NX_FLOAT): - current_working_directory(NX_CHAR): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - userID(NXuser): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - If used, metadata of at least the person who performed this analysis. - name(NX_CHAR): - coordinate_system_set(NXcoordinate_system_set): - exists: ['min', '1', 'max', '1'] - paraprobe(NXcoordinate_system): - type(NX_CHAR): - handedness(NX_CHAR): - x(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - y(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - z(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# b529eb9b3658a196bca7ba97b734fd740d0d9e3070dba13dcd9c90ea935ca755 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The total number of ions in the reconstruction. -# -# -# -# -# Application definition for results files of the paraprobe-selector tool. -# -# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. -# The purpose and need of the paraprobe-selector tool is to identify which reconstructed positions -# are located inside or on the surface of a (possibly complicated) region-of-interest (ROI). -# In addition, the tool allows to filter ions for properties. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If used, metadata of at least the person who performed this analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml deleted file mode 100644 index 8056293ffb..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml +++ /dev/null @@ -1,610 +0,0 @@ -category: application -doc: | - Application definition for a configuration file of the paraprobe-spatstat tool. - - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_ivec_max: | - Maximum number of atoms per molecular ion. Should be 32 for paraprobe. - n_ion_source: | - Number of different source iontypes to distinguish. - n_ion_target: | - Number of different target iontypes to distinguish. -type: group -NXapm_paraprobe_spatstat_config(NXobject): - (NXentry): - exists: ['min', '1', 'max', '1'] - definition(NX_CHAR): - \@version: - type: NX_CHAR - enumeration: [NXapm_paraprobe_spatstat_config] - number_of_tasks(NX_UINT): - unit: NX_UNITLESS - doc: | - How many spatial_statistics tasks should the tool execute. - spatial_statisticsID(NXapm_paraprobe_tool_config): - exists: ['min', '1', 'max', 'unbounded'] - (NXidentifier): - exists: optional - analysis_identifier(NX_UINT): - exists: recommended - reconstruction(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - position(NX_CHAR): - mass_to_charge(NX_CHAR): - ranging(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - ranging_definitions(NX_CHAR): - surface_distance(NXserialized): - exists: optional - doc: | - Distance between each ion and triangulated surface mesh. - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - distance(NX_CHAR): - edge_distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Threshold to define how far an ion has to lay at least from the edge - of the dataset so that the ion can act as a source. This means that - an ROI is placed at the location of the ion and its neighbors are - analyzed how they contribute to the computed statistics. - - The edge_distance threshold can be combined with the feature_distance threshold. This threshold defines defines up to which distance to a - microstructural feature an ROI is placed. - - The threshold is useful to process the dataset such that ROIs do - not protrude out of the dataset as this would add bias. - feature_distance(NXserialized): - exists: optional - doc: | - Distance between each ion and triangulated mesh of microstructural features. - In addition to spatial filtering and considering how far ions lie to the - edge of the dataset, it is possible to restrict the analyses to a sub-set of - ions within a distance not farther away to a feature than the feature_distance - threshold value. - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - distance(NX_CHAR): - doc: | - Absolute path in the (HDF5) file which points to the distance of each - ion to the closest feature. - feature_distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Threshold to define how close an ion has to lay to a feature so that - the ion can at all qualify as a source, i.e. that an ROI is placed - at the location of the ion and its neighbors are then analyzed - how they contribute to the computed statistics. - - Recall that this feature_distance threshold is used in combination - with the edge_distance threshold when placing ROI about source ions. - spatial_filter(NXspatial_filter): - windowing_method(NX_CHAR): - hexahedron_set(NXcg_hexahedron_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - hexahedra(NXcg_face_list_data_structure): - vertices(NX_UINT): - cylinder_set(NXcg_cylinder_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - height(NX_NUMBER): - radii(NX_NUMBER): - ellipsoid_set(NXcg_ellipsoid_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - half_axes_radii(NX_NUMBER): - orientation(NX_NUMBER): - polyhedron_set(NXcg_polyhedron_set): - exists: optional - - # TODO - bitmask(NXcs_filter_boolean_mask): - exists: optional - number_of_objects(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - - # leave open if scalar or matrix - # dim: (i,) - # identifier(NX_UINT): - evaporation_id_filter(NXsubsampling_filter): - exists: optional - min_incr_max(NX_INT): - iontype_filter(NXmatch_filter): - exists: optional - method(NX_CHAR): - match(NX_NUMBER): - hit_multiplicity_filter(NXmatch_filter): - exists: optional - method(NX_CHAR): - match(NX_NUMBER): - - # config - randomize_iontypes(NX_BOOLEAN): - doc: | - Specifies, if the iontypes are randomized for the point cloud or not. - Internally, paraprobe uses a sequentially executed deterministic MT19987 - (MersenneTwister) pseudo-random number generator to shuffle the - iontypes randomly across the entire set of ions. That is the total - number of ions of either type remain the same but the information about - their location is randomized. - random_number_generator(NXcs_prng): - exists: recommended - type(NX_CHAR): - seed(NX_NUMBER): - warmup(NX_NUMBER): - ion_query_type_source(NX_CHAR): - doc: | - How should the iontype be interpreted on the source-side, i.e. - all these ion positions where a regions-of-interest (ROI) around - so-called source ions will be placed. Different options exist - how iontypes are interpreted given an iontype represents - in general a (molecular) ion with different isotopes that have - individually different multiplicity. - - The value resolve_all will set an ion active in the analysis regardless - of which iontype it is. Each active ion is accounted for once. - - The value resolve_unknown will set an ion active when the ion is - of the UNKNOWNTYPE type. Each active ion is accounted for once. - - The value resolve_ion will set an ion active if it is of the specific - iontype, irregardless of its elemental or isotopic details. - Each active ion is counted once. - - The value resolve_element will set an ion active, and most importantly, - account for each as many times as the (molecular) ion contains - atoms of elements in the whitelist ion_query_isotope_vector. - - The value resolve_isotope will set an ion active, and most importantly, - account for each as many times as the (molecular) ion contains - isotopes in the whitelist ion_query_isotope_vector. - - In effect, ion_query_isotope_vector acts as a whitelist to filter - which ions are considered as source ions of the correlation statistics - and how the multiplicity of each ion will be factorized, i.e. how - often it is accounted for. - enumeration: [resolve_all, resolve_unknown, resolve_ion, resolve_element, resolve_isotope] - ion_query_nuclide_source(NX_UINT): - unit: NX_UNITLESS - doc: | - Matrix of isotope vectors, as many as rows as different candidates - for iontypes should be distinguished as possible source iontypes. - In the simplest case, the matrix contains only the proton number - of the element in the row, all other values set to zero. - Combined with ion_query_type_source set to resolve_element this will - recover usual spatial correlation statistics like the 1NN C-C - spatial statistics. - dimensions: - rank: 2 - dim: [[1, n_ion_source], [2, n_ivec_max]] - ion_query_type_target(NX_CHAR): - doc: | - Similarly as ion_query_type_source how should iontypes be interpreted - on the target-side, i.e. how many counts will be bookkept for ions - which are neighbors of source ions within or on the surface of each - inspection/ROI about each source ion. - Source ion in the center of the ROI are not accounted for during - counting the summary statistics. - For details about the resolve values consider the explanations in - ion_query_type_source. These account for ion_query_type_target as well. - enumeration: [resolve_all, resolve_unknown, resolve_ion, resolve_element, resolve_isotope] - - # NEW ISSUE: conditionally required only when resolve_isotope - ion_query_nuclide_target(NX_UINT): - unit: NX_UNITLESS - doc: | - Matrix of isotope vectors, as many as rows as different candidates for - iontypes to distinguish as possible targets. See additional comments - under ion_query_isotope_vector_source. - dimensions: - rank: 2 - dim: [[1, n_ion_target], [2, n_ivec_max]] - statistics(NXprocess): - doc: | - Specifies which spatial statistics to compute. - knn(NXprocess): - exists: ['min', '0', 'max', '1'] - doc: | - Compute k-th nearest neighbour statistics. - kth(NX_UINT): - unit: NX_UNITLESS - doc: | - Order k. - min_incr_max(NX_FLOAT): - unit: NX_LENGTH - doc: | - Minimum value, increment, and maximum value of the histogram binning. - dimensions: - rank: 1 - dim: [[1, 3]] - rdf(NXprocess): - exists: ['min', '0', 'max', '1'] - doc: | - Compute radial distribution function. - min_incr_max(NX_FLOAT): - unit: NX_LENGTH - doc: | - Minimum value, increment, and maximum value of the histogram binning. - dimensions: - rank: 1 - dim: [[1, 3]] - - # NEW ISSUE: ripleyk(NXcollection): - # NEW ISSUE: two_point(NXcollection): - common(NXapm_paraprobe_tool_common): - status(NX_CHAR): - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - profiling(NXcs_profiling): - exists: recommended - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - total_elapsed_time(NX_FLOAT): - current_working_directory(NX_CHAR): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 82bf2486296668125a3b817eae99a1fc730e5e9c3599752ae5d9526d91456d5a -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Maximum number of atoms per molecular ion. Should be 32 for paraprobe. -# -# -# -# -# Number of different source iontypes to distinguish. -# -# -# -# -# Number of different target iontypes to distinguish. -# -# -# -# -# Application definition for a configuration file of the paraprobe-spatstat tool. -# -# This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. -# -# -# -# -# -# -# -# -# -# -# How many spatial_statistics tasks should the tool execute. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Distance between each ion and triangulated surface mesh. -# -# -# -# -# -# -# -# -# Threshold to define how far an ion has to lay at least from the edge -# of the dataset so that the ion can act as a source. This means that -# an ROI is placed at the location of the ion and its neighbors are -# analyzed how they contribute to the computed statistics. -# -# The edge_distance threshold can be combined with the feature_distance threshold. This threshold defines defines up to which distance to a -# microstructural feature an ROI is placed. -# -# The threshold is useful to process the dataset such that ROIs do -# not protrude out of the dataset as this would add bias. -# -# -# -# -# -# Distance between each ion and triangulated mesh of microstructural features. -# In addition to spatial filtering and considering how far ions lie to the -# edge of the dataset, it is possible to restrict the analyses to a sub-set of -# ions within a distance not farther away to a feature than the feature_distance -# threshold value. -# -# -# -# -# -# -# -# Absolute path in the (HDF5) file which points to the distance of each -# ion to the closest feature. -# -# -# -# -# Threshold to define how close an ion has to lay to a feature so that -# the ion can at all qualify as a source, i.e. that an ROI is placed -# at the location of the ion and its neighbors are then analyzed -# how they contribute to the computed statistics. -# -# Recall that this feature_distance threshold is used in combination -# with the edge_distance threshold when placing ROI about source ions. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Specifies, if the iontypes are randomized for the point cloud or not. -# Internally, paraprobe uses a sequentially executed deterministic MT19987 -# (MersenneTwister) pseudo-random number generator to shuffle the -# iontypes randomly across the entire set of ions. That is the total -# number of ions of either type remain the same but the information about -# their location is randomized. -# -# -# -# -# -# -# -# -# -# How should the iontype be interpreted on the source-side, i.e. -# all these ion positions where a regions-of-interest (ROI) around -# so-called source ions will be placed. Different options exist -# how iontypes are interpreted given an iontype represents -# in general a (molecular) ion with different isotopes that have -# individually different multiplicity. -# -# The value resolve_all will set an ion active in the analysis regardless -# of which iontype it is. Each active ion is accounted for once. -# -# The value resolve_unknown will set an ion active when the ion is -# of the UNKNOWNTYPE type. Each active ion is accounted for once. -# -# The value resolve_ion will set an ion active if it is of the specific -# iontype, irregardless of its elemental or isotopic details. -# Each active ion is counted once. -# -# The value resolve_element will set an ion active, and most importantly, -# account for each as many times as the (molecular) ion contains -# atoms of elements in the whitelist ion_query_isotope_vector. -# -# The value resolve_isotope will set an ion active, and most importantly, -# account for each as many times as the (molecular) ion contains -# isotopes in the whitelist ion_query_isotope_vector. -# -# In effect, ion_query_isotope_vector acts as a whitelist to filter -# which ions are considered as source ions of the correlation statistics -# and how the multiplicity of each ion will be factorized, i.e. how -# often it is accounted for. -# -# -# -# -# -# -# -# -# -# -# -# Matrix of isotope vectors, as many as rows as different candidates -# for iontypes should be distinguished as possible source iontypes. -# In the simplest case, the matrix contains only the proton number -# of the element in the row, all other values set to zero. -# Combined with ion_query_type_source set to resolve_element this will -# recover usual spatial correlation statistics like the 1NN C-C -# spatial statistics. -# -# -# -# -# -# -# -# -# Similarly as ion_query_type_source how should iontypes be interpreted -# on the target-side, i.e. how many counts will be bookkept for ions -# which are neighbors of source ions within or on the surface of each -# inspection/ROI about each source ion. -# Source ion in the center of the ROI are not accounted for during -# counting the summary statistics. -# For details about the resolve values consider the explanations in -# ion_query_type_source. These account for ion_query_type_target as well. -# -# -# -# -# -# -# -# -# -# -# -# -# Matrix of isotope vectors, as many as rows as different candidates for -# iontypes to distinguish as possible targets. See additional comments -# under ion_query_isotope_vector_source. -# -# -# -# -# -# -# -# -# Specifies which spatial statistics to compute. -# -# -# -# Compute k-th nearest neighbour statistics. -# -# -# -# Order k. -# -# -# -# -# Minimum value, increment, and maximum value of the histogram binning. -# -# -# -# -# -# -# -# -# Compute radial distribution function. -# -# -# -# Minimum value, increment, and maximum value of the histogram binning. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml deleted file mode 100644 index 412a52d090..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml +++ /dev/null @@ -1,355 +0,0 @@ -category: application -doc: | - Application definition for results files of the paraprobe-spatstat tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_ions: | - The total number of ions in the reconstruction. - n_knn: | - The total number of bins in the histogram for the k-th nearest neighbor. - n_rdf: | - The total number of bins in the histogram for the radial distribution function. -type: group -NXapm_paraprobe_spatstat_results(NXobject): - (NXentry): - exists: ['min', '1', 'max', '1'] - definition(NX_CHAR): - \@version: - type: NX_CHAR - enumeration: [NXapm_paraprobe_spatstat_results] - - # tasks - spatial_statisticsID(NXapm_paraprobe_tool_results): - exists: ['min', '0', 'max', 'unbounded'] - window(NXcs_filter_boolean_mask): - number_of_ions(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - - # results - iontypes_randomized(NX_UINT): - unit: NX_UNITLESS - doc: | - The iontype ID for each ion that was assigned to each ion during - the randomization of the ionlabels. Iontype labels are just permuted - but the total number of values for each iontype remain the same. - - The order matches the iontypes array from a given ranging results - as it is specified in the configuration settings inside the specific - config_filename that was used for this paraprobe-spatstat analysis. - dimensions: - rank: 1 - dim: [[1, n_ions]] - knn(NXprocess): - exists: optional - doc: | - K-nearest neighbor statistics. - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Right boundary of the binning. - dimensions: - rank: 1 - dim: [[1, n_knn]] - probability_mass(NX_FLOAT): - unit: NX_DIMENSIONLESS - dimensions: - rank: 1 - dim: [[1, n_knn]] - cumulated(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Cumulated not normalized by total counts. - dimensions: - rank: 1 - dim: [[1, n_knn]] - cumulated_normalized(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Cumulated and normalized by total counts. - dimensions: - rank: 1 - dim: [[1, n_knn]] - rdf(NXprocess): - exists: optional - doc: | - Radial distribution statistics. - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Right boundary of the binning. - dimensions: - rank: 1 - dim: [[1, n_rdf]] - probability_mass(NX_FLOAT): - unit: NX_DIMENSIONLESS - dimensions: - rank: 1 - dim: [[1, n_rdf]] - cumulated(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Cumulated not normalized by total counts. - dimensions: - rank: 1 - dim: [[1, n_rdf]] - cumulated_normalized(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Cumulated and normalized by total counts. - dimensions: - rank: 1 - dim: [[1, n_rdf]] - common(NXapm_paraprobe_tool_common): - status(NX_CHAR): - analysis_identifier(NX_UINT): - config(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - profiling(NXcs_profiling): - exists: recommended - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - total_elapsed_time(NX_FLOAT): - current_working_directory(NX_CHAR): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - userID(NXuser): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - If used, metadata of at least the person who performed this analysis. - name(NX_CHAR): - coordinate_system_set(NXcoordinate_system_set): - exists: ['min', '1', 'max', '1'] - paraprobe(NXcoordinate_system): - type(NX_CHAR): - handedness(NX_CHAR): - x(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - y(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - z(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 23c56b9160f3c0395fe85be1c18b9467fb32095a9e8f5fc884974281be8ba852 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The total number of ions in the reconstruction. -# -# -# -# -# The total number of bins in the histogram for the k-th nearest neighbor. -# -# -# -# -# The total number of bins in the histogram for the radial distribution function. -# -# -# -# -# Application definition for results files of the paraprobe-spatstat tool. -# -# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The iontype ID for each ion that was assigned to each ion during -# the randomization of the ionlabels. Iontype labels are just permuted -# but the total number of values for each iontype remain the same. -# -# The order matches the iontypes array from a given ranging results -# as it is specified in the configuration settings inside the specific -# config_filename that was used for this paraprobe-spatstat analysis. -# -# -# -# -# -# -# -# K-nearest neighbor statistics. -# -# -# -# Right boundary of the binning. -# -# -# -# -# -# -# -# -# -# -# -# -# Cumulated not normalized by total counts. -# -# -# -# -# -# -# -# Cumulated and normalized by total counts. -# -# -# -# -# -# -# -# -# Radial distribution statistics. -# -# -# -# Right boundary of the binning. -# -# -# -# -# -# -# -# -# -# -# -# -# Cumulated not normalized by total counts. -# -# -# -# -# -# -# -# Cumulated and normalized by total counts. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If used, metadata of at least the person who performed this analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_config.yaml deleted file mode 100644 index d4dcb9bfc6..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_config.yaml +++ /dev/null @@ -1,419 +0,0 @@ -category: application -doc: | - Application definition for a configuration file of the paraprobe-surfacer tool. - - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_alpha_values: | - Number of alpha values (and offset values) to probe. - n_values: | - How many different match values does the filter specify. -type: group -NXapm_paraprobe_surfacer_config(NXobject): - (NXentry): - exists: ['min', '1', 'max', '1'] - definition(NX_CHAR): - \@version: - type: NX_CHAR - enumeration: [NXapm_paraprobe_surfacer_config] - surface_meshing(NXapm_paraprobe_tool_config): - exists: ['min', '1', 'max', '1'] - (NXidentifier): - exists: optional - analysis_identifier(NX_UINT): - exists: recommended - reconstruction(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - position(NX_CHAR): - mass_to_charge(NX_CHAR): - ranging(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - ranging_definitions(NX_CHAR): - - # filter that are here tool-specific parameter - spatial_filter(NXspatial_filter): - windowing_method(NX_CHAR): - hexahedron_set(NXcg_hexahedron_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - hexahedra(NXcg_face_list_data_structure): - vertices(NX_UINT): - cylinder_set(NXcg_cylinder_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - height(NX_NUMBER): - radii(NX_NUMBER): - ellipsoid_set(NXcg_ellipsoid_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - half_axes_radii(NX_NUMBER): - orientation(NX_NUMBER): - polyhedron_set(NXcg_polyhedron_set): - exists: optional - - # TODO - bitmask(NXcs_filter_boolean_mask): - exists: optional - number_of_objects(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - - # leave open if scalar or matrix - # dim: (i,) - identifier(NX_UINT): - evaporation_id_filter(NXsubsampling_filter): - exists: optional - min_incr_max(NX_INT): - iontype_filter(NXmatch_filter): - exists: optional - method(NX_CHAR): - match(NX_NUMBER): - hit_multiplicity_filter(NXmatch_filter): - exists: optional - method(NX_CHAR): - match(NX_NUMBER): - - # config - preprocessing(NXprocess): - method(NX_CHAR): - doc: | - Specifies the method that is used to preprocess the point cloud - prior to the alpha-shape computation. - - The option *default* specifies that no such filtering is applied. - The option *kuehbach* specifies that a Hoshen-Kopelman - percolation analysis is used to identify points that lie closer - to the edge of the dataset. Details about the methods are reported - in `M. Kühbach et al. `_. - enumeration: [default, kuehbach] - kernel_width(NX_UINT): - unit: NX_UNITLESS - doc: | - When using the kuehbach preprocessing, this is the width of the - kernel for identifying which ions are in voxels close to the - edge of the point cloud. - alpha_value_choice(NX_CHAR): - doc: | - Specifies which method to use to define the alpha value. - - The value *convex_hull_naive* is the default. The setting instructs - the tool to use a fast specialized algorithm for computing only - the convex hull. The resulting triangles can be skinny. - - The value *convex_hull_refine* instructs to tool to refine the - quality of the mesh resulting from *convex_hull_naive* - via triangle flipping and splitting. - - The value *smallest_solid* instructs the CGAL library to choose a - value which realizes an alpha-shape that is the smallest solid. - - The value *cgal_optimal* instructs the CGAL library to choose a - value which the library considers as to be an optimal value. - Details are defined in the respective section of the CGAL library - on 3D alpha shapes. - - The value *set_of_values* instructs the tool to compute a list - collection of alpha-shapes for the specified alpha-values. - - The value *set_of_alpha_wrappings* instructs the tool to generate - a set of so-called alpha wrappings. These are similar to alpha-shapes - but provide additional guarantees (such as watertightness and - proximity constraints) on the resulting wrapping. - enumeration: [convex_hull_naive, convex_hull_refine, smallest_solid, cgal_optimal, set_of_values, set_of_alpha_wrappings] - alpha_values(NX_FLOAT): - unit: NX_ANY - doc: | - Array of alpha values to use when alpha_value_choice is - set_of_values or when alpha_value_choice is set_of_alpha_wrappings. - dimensions: - rank: 1 - dim: [[1, n_alpha_values]] - offset_values(NX_FLOAT): - unit: NX_LENGTH - doc: | - Array of offset values to use when alpha_value_choice is set_of_alpha_wrappings. - The array of alpha_values and offset_values define a sequence of (alpha and offset value). - dimensions: - rank: 1 - dim: [[1, n_alpha_values]] - has_exterior_facets(NX_BOOLEAN): - doc: | - Specifies if the tool should compute the set of exterior triangle facets - for each alpha complex (for convex hull, alpha shapes, and wrappings). - has_closure(NX_BOOLEAN): - doc: | - Specifies if the tool should check if the alpha complex of - exterior triangular facets is a closed polyhedron. - has_interior_tetrahedra(NX_BOOLEAN): - doc: | - Specifies if the tool should compute all interior tetrahedra - of the alpha complex (currently only for alpha shapes). - - # NEW ISSUE: has_facet_appearance(NX_BOOLEAN): - common(NXapm_paraprobe_tool_common): - status(NX_CHAR): - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - profiling(NXcs_profiling): - exists: recommended - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - total_elapsed_time(NX_FLOAT): - current_working_directory(NX_CHAR): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 17726b94bf3dee5f7c7a29968f1b27a8da0f1e7882194c0a8d17e18d1b838623 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of alpha values (and offset values) to probe. -# -# -# -# -# How many different match values does the filter specify. -# -# -# -# -# Application definition for a configuration file of the paraprobe-surfacer tool. -# -# This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Specifies the method that is used to preprocess the point cloud -# prior to the alpha-shape computation. -# -# The option *default* specifies that no such filtering is applied. -# The option *kuehbach* specifies that a Hoshen-Kopelman -# percolation analysis is used to identify points that lie closer -# to the edge of the dataset. Details about the methods are reported -# in `M. Kühbach et al. <https://doi.org/10.1038/s41524-020-00486-1>`_. -# -# -# -# -# -# -# -# -# When using the kuehbach preprocessing, this is the width of the -# kernel for identifying which ions are in voxels close to the -# edge of the point cloud. -# -# -# -# -# -# Specifies which method to use to define the alpha value. -# -# The value *convex_hull_naive* is the default. The setting instructs -# the tool to use a fast specialized algorithm for computing only -# the convex hull. The resulting triangles can be skinny. -# -# The value *convex_hull_refine* instructs to tool to refine the -# quality of the mesh resulting from *convex_hull_naive* -# via triangle flipping and splitting. -# -# The value *smallest_solid* instructs the CGAL library to choose a -# value which realizes an alpha-shape that is the smallest solid. -# -# The value *cgal_optimal* instructs the CGAL library to choose a -# value which the library considers as to be an optimal value. -# Details are defined in the respective section of the CGAL library -# on 3D alpha shapes. -# -# The value *set_of_values* instructs the tool to compute a list -# collection of alpha-shapes for the specified alpha-values. -# -# The value *set_of_alpha_wrappings* instructs the tool to generate -# a set of so-called alpha wrappings. These are similar to alpha-shapes -# but provide additional guarantees (such as watertightness and -# proximity constraints) on the resulting wrapping. -# -# -# -# -# -# -# -# -# -# -# -# -# Array of alpha values to use when alpha_value_choice is -# set_of_values or when alpha_value_choice is set_of_alpha_wrappings. -# -# -# -# -# -# -# -# Array of offset values to use when alpha_value_choice is set_of_alpha_wrappings. -# The array of alpha_values and offset_values define a sequence of (alpha and offset value). -# -# -# -# -# -# -# -# Specifies if the tool should compute the set of exterior triangle facets -# for each alpha complex (for convex hull, alpha shapes, and wrappings). -# -# -# -# -# Specifies if the tool should check if the alpha complex of -# exterior triangular facets is a closed polyhedron. -# -# -# -# -# Specifies if the tool should compute all interior tetrahedra -# of the alpha complex (currently only for alpha shapes). -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml deleted file mode 100644 index accaa828dc..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml +++ /dev/null @@ -1,514 +0,0 @@ -category: application -doc: | - Application definition for results files of the paraprobe-surfacer tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. - The purpose and need of the paraprobe-surfacer tool is the generation of meshed - representation of the surface of the the reconstructed volume (or a portion) of it - using different algorithms from the computational geometry community. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_ions: | - The total number of ions in the reconstruction. - n_v_tri: | - The number of vertices of the alpha complex. - n_f_tri: | - The number of faces of the alpha complex. - n_f_tri_xdmf: | - The total number of XDMF values to represent all faces of triangles via XDMF. - n_f_tet_xdmf: | - The total number of XDMF values to represent all faces of tetrahedra via XDMF. -type: group -NXapm_paraprobe_surfacer_results(NXobject): - (NXentry): - exists: ['min', '1', 'max', '1'] - definition(NX_CHAR): - \@version: - type: NX_CHAR - enumeration: [NXapm_paraprobe_surfacer_results] - - # tasks - point_set_wrapping(NXapm_paraprobe_tool_results): - doc: | - Paraprobe-surfacer can be used to load a ROI that is the entire or a - sub-set of the ion point cloud. In the point_cloud_wrapping process - the tool computes a triangulated surface mesh which encloses the - ROI/point cloud. This mesh can be seen as a model for the edge of - the dataset. - - Different algorithms can be used with paraprobe-surfacer to create - this mesh such as convex hulls, alpha-shapes as their generalization, - or alpha wrappings. - - Ideally, the resulting mesh should be a watertight polyhedron. - This polyhedron is not necessarily convex. For some algorithms there - is no guarantee that the resulting mesh yields a watertight mesh. - - # config - window(NXcs_filter_boolean_mask): - number_of_ions(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - - # results - alpha_complexID(NXcg_alpha_complex): - exists: ['min', '0', 'max', 'unbounded'] - - # (NXcg_grid): currently we do not store the underlying grid - # for eventually performed preprocessing - window(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies exactly all those ions whose positions - were considered when defining the filtered point set from which - that alpha_complex instance was computed. - - This window can be different to the window of the *point_set_wrapping* - parent group because irrelevant ions might have been filtered out in addition - to the window defined in *point_set_wrapping* to reduce e.g. computational - costs of the alpha complex computation. - - # filtered in addition to the ROI or again the entire dataset - number_of_ions(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of ions covered by the mask. - bitdepth(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of bits assumed matching on a default datatype. - mask(NX_UINT): - unit: NX_UNITLESS - doc: | - The bitfield of the mask. See :ref:`NXcs_filter_boolean_mask` for - how this bitfield is to be interpreted. - dimensions: - rank: 1 - dim: [[1, n_ions]] - dimensionality(NX_UINT): - unit: NX_UNITLESS - enumeration: [2, 3] - type(NX_CHAR): - enumeration: [convex_hull, alpha_shape, alpha_wrapping, other, undefined] - mode(NX_CHAR): - enumeration: [general, regularized] - alpha(NX_NUMBER): - unit: NX_ANY - offset(NX_NUMBER): - exists: optional - unit: NX_LENGTH - triangle_set(NXcg_triangle_set): - exists: optional - doc: | - The set of triangles in the coordinate system paraprobe - which discretizes the exterior surface of the alpha complex. - identifier_offset(NX_INT): - triangles(NXcg_face_list_data_structure): - dimensionality(NX_POSINT): - number_of_vertices(NX_POSINT): - number_of_faces(NX_POSINT): - vertex_identifier_offset(NX_INT): - face_identifier_offset(NX_INT): - vertices(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_v_tri], [2, 3]] - faces(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_f_tri], [2, 3]] - xdmf_topology(NX_UINT): - unit: NX_UNITLESS - doc: | - A list of as many tuples of XDMF topology key, XDMF number - of vertices and a triple of vertex indices specifying each - triangle. The total number of entries is n_f_tri * (1+1+3). - dimensions: - rank: 1 - dim: [[1, n_f_tri_xdmf]] - is_watertight(NX_BOOLEAN): - exists: optional - doc: | - Do the triangles define a triangulated surface mesh that is watertight? - volume(NX_FLOAT): - exists: optional - unit: NX_VOLUME - doc: | - The volume which the triangulated surface mesh - encloses if that mesh is watertight. - interior_tetrahedra(NXcg_tetrahedron_set): - exists: optional - doc: | - The set of tetrahedra which represent the interior volume - of the complex if that is a closed two-manifold. - identifier_offset(NX_INT): - unit: NX_UNITLESS - volume(NX_FLOAT): - exists: optional - unit: NX_VOLUME - doc: | - The accumulated volume of all interior tetrahedra. - tetrahedra(NXcg_face_list_data_structure): - exists: optional - number_of_vertices(NX_POSINT): - number_of_faces(NX_POSINT): - vertex_identifier_offset(NX_INT): - face_identifier_offset(NX_INT): - vertices(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_v_tet], [2, 3]] - xdmf_topology(NX_UINT): - unit: NX_UNITLESS - doc: | - A list of as many tuples of XDMF topology key, XDMF number - of vertices and a triple of vertex indices specifying each - triangle. The total number of entries is n_f_tet * (1+1+4). - dimensions: - rank: 1 - dim: [[1, n_f_tet_xdmf]] - - # TRIANGLE_SET_WRAPPING(NXprocess): - # For the future as we may wish to wrap primitives other like triangles or polylines. - common(NXapm_paraprobe_tool_common): - status(NX_CHAR): - analysis_identifier(NX_UINT): - config(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - profiling(NXcs_profiling): - exists: recommended - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - total_elapsed_time(NX_FLOAT): - current_working_directory(NX_CHAR): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - userID(NXuser): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - If used, metadata of at least the person who performed this analysis. - name(NX_CHAR): - coordinate_system_set(NXcoordinate_system_set): - exists: ['min', '1', 'max', '1'] - paraprobe(NXcoordinate_system): - type(NX_CHAR): - handedness(NX_CHAR): - x(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - y(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - z(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 1569006f7d904095cbe56d589202ba88e43d465603e719641542b56bdaa90d77 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The total number of ions in the reconstruction. -# -# -# -# -# The number of vertices of the alpha complex. -# -# -# -# -# The number of faces of the alpha complex. -# -# -# -# -# The total number of XDMF values to represent all faces of triangles via XDMF. -# -# -# -# -# The total number of XDMF values to represent all faces of tetrahedra via XDMF. -# -# -# -# -# Application definition for results files of the paraprobe-surfacer tool. -# -# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. -# The purpose and need of the paraprobe-surfacer tool is the generation of meshed -# representation of the surface of the the reconstructed volume (or a portion) of it -# using different algorithms from the computational geometry community. -# -# -# -# -# -# -# -# -# -# -# -# Paraprobe-surfacer can be used to load a ROI that is the entire or a -# sub-set of the ion point cloud. In the point_cloud_wrapping process -# the tool computes a triangulated surface mesh which encloses the -# ROI/point cloud. This mesh can be seen as a model for the edge of -# the dataset. -# -# Different algorithms can be used with paraprobe-surfacer to create -# this mesh such as convex hulls, alpha-shapes as their generalization, -# or alpha wrappings. -# -# Ideally, the resulting mesh should be a watertight polyhedron. -# This polyhedron is not necessarily convex. For some algorithms there -# is no guarantee that the resulting mesh yields a watertight mesh. -# -# -# -# -# -# -# -# -# -# -# -# -# A bitmask which identifies exactly all those ions whose positions -# were considered when defining the filtered point set from which -# that alpha_complex instance was computed. -# -# This window can be different to the window of the *point_set_wrapping* -# parent group because irrelevant ions might have been filtered out in addition -# to the window defined in *point_set_wrapping* to reduce e.g. computational -# costs of the alpha complex computation. -# -# -# -# -# Number of ions covered by the mask. -# -# -# -# -# Number of bits assumed matching on a default datatype. -# -# -# -# -# The bitfield of the mask. See :ref:`NXcs_filter_boolean_mask` for -# how this bitfield is to be interpreted. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The set of triangles in the coordinate system paraprobe -# which discretizes the exterior surface of the alpha complex. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# A list of as many tuples of XDMF topology key, XDMF number -# of vertices and a triple of vertex indices specifying each -# triangle. The total number of entries is n_f_tri * (1+1+3). -# -# -# -# -# -# -# -# Do the triangles define a triangulated surface mesh that is watertight? -# -# -# -# -# The volume which the triangulated surface mesh -# encloses if that mesh is watertight. -# -# -# -# -# -# -# The set of tetrahedra which represent the interior volume -# of the complex if that is a closed two-manifold. -# -# -# -# -# The accumulated volume of all interior tetrahedra. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# A list of as many tuples of XDMF topology key, XDMF number -# of vertices and a triple of vertex indices specifying each -# triangle. The total number of entries is n_f_tet * (1+1+4). -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If used, metadata of at least the person who performed this analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml deleted file mode 100644 index 43d62dcef3..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml +++ /dev/null @@ -1,319 +0,0 @@ -category: application -doc: | - Application definition for a configuration file of the paraprobe-tessellator tool. - - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. - -# n_control_points: The number of control points for tessellating regions instead of tessellating the volume about ion positions. -# an example for limited conditions in NeXus -# if windowing_method is entire_dataset: no constraint on existence of NXcg and NXcs instances -# if windowing_method is union_of_primitives: sum of cardinality of NXcg >= 0 -# if windowing_method is bitmasked_points: sum cardinality of NXcg := 0 and cardinality of NXcs_filter_boolean_mask == 1 -type: group -NXapm_paraprobe_tessellator_config(NXobject): - (NXentry): - exists: ['min', '1', 'max', '1'] - definition(NX_CHAR): - \@version: - type: NX_CHAR - enumeration: [NXapm_paraprobe_tessellator_config] - tessellate(NXapm_paraprobe_tool_config): - exists: ['min', '1', 'max', '1'] - (NXidentifier): - exists: optional - analysis_identifier(NX_UINT): - exists: recommended - reconstruction(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - position(NX_CHAR): - mass_to_charge(NX_CHAR): - ranging(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - ranging_definitions(NX_CHAR): - surface_distance(NXserialized): - exists: optional - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - distance(NX_CHAR): - spatial_filter(NXspatial_filter): - windowing_method(NX_CHAR): - hexahedron_set(NXcg_hexahedron_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - hexahedra(NXcg_face_list_data_structure): - vertices(NX_UINT): - cylinder_set(NXcg_cylinder_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - height(NX_NUMBER): - radii(NX_NUMBER): - ellipsoid_set(NXcg_ellipsoid_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - half_axes_radii(NX_NUMBER): - orientation(NX_NUMBER): - polyhedron_set(NXcg_polyhedron_set): - exists: optional - - # TODO - bitmask(NXcs_filter_boolean_mask): - exists: optional - number_of_objects(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - - # leave open if scalar or matrix - # dim: (i,) - identifier(NX_UINT): - evaporation_id_filter(NXsubsampling_filter): - exists: optional - min_incr_max(NX_INT): - iontype_filter(NXmatch_filter): - exists: optional - method(NX_CHAR): - match(NX_NUMBER): - hit_multiplicity_filter(NXmatch_filter): - exists: optional - method(NX_CHAR): - match(NX_NUMBER): - - # config - method(NX_CHAR): - doc: | - The method used to compute the tessellation. - The value *default* configures the computation of the Voronoi tessellation. - - # check versions prior paraprobe-toolbox v0.5 for control_point-based method - enumeration: [default] - has_cell_volume(NX_BOOLEAN): - doc: | - Specifies if the tool should report the volume of each cell. - has_cell_neighbors(NX_BOOLEAN): - doc: | - Specifies if the tool should report the first-order neighbors of each cell. - has_cell_geometry(NX_BOOLEAN): - doc: | - Specifies if the tool should report the facets and vertices of each cell. - has_cell_edge_detection(NX_BOOLEAN): - doc: | - Specifies if the tool should report for each cell if it makes contact with - the tight axis-aligned bounding box about the point cloud. - This can be used to identify if the shape of the cell is likely affected - by the edge of the dataset or if cells are deeply enough embedded - into the point cloud so that the shape of their cells are not affected - anymore by the boundary. This is valuable information to judge - about the significance of finite size effects. - - # erosion_distance(NX_FLOAT): - # doc: | - # Maximum distance for which cells are eroded. - # unit: NX_LENGTH - # \@units: nm - # minValue: EPSILON - common(NXapm_paraprobe_tool_common): - status(NX_CHAR): - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - profiling(NXcs_profiling): - exists: recommended - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - total_elapsed_time(NX_FLOAT): - current_working_directory(NX_CHAR): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 45ea5ec9e90adc378bd48ba43594b4f2e34daad706bdbfd1106c20023dd2bb47 -# -# -# -# -# -# -# Application definition for a configuration file of the paraprobe-tessellator tool. -# -# This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The method used to compute the tessellation. -# The value *default* configures the computation of the Voronoi tessellation. -# -# -# -# -# -# -# -# -# Specifies if the tool should report the volume of each cell. -# -# -# -# -# Specifies if the tool should report the first-order neighbors of each cell. -# -# -# -# -# Specifies if the tool should report the facets and vertices of each cell. -# -# -# -# -# Specifies if the tool should report for each cell if it makes contact with -# the tight axis-aligned bounding box about the point cloud. -# This can be used to identify if the shape of the cell is likely affected -# by the edge of the dataset or if cells are deeply enough embedded -# into the point cloud so that the shape of their cells are not affected -# anymore by the boundary. This is valuable information to judge -# about the significance of finite size effects. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml deleted file mode 100644 index a4ad9bad7f..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml +++ /dev/null @@ -1,614 +0,0 @@ -category: application -doc: | - Application definition for results files of the paraprobe-tessellator tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_ions: | - The total number of ions in the reconstruction. - n_f: | - The total number of values required to represent all faces of each cell. - n_f_xdmf: | - The total number of values required to represent all faces of each cell - (polyhedron) using XDMF. -type: group -NXapm_paraprobe_tessellator_results(NXobject): - (NXentry): - exists: ['min', '1', 'max', '1'] - definition(NX_CHAR): - \@version: - type: NX_CHAR - enumeration: [NXapm_paraprobe_tessellator_results] - - # tasks - tessellation(NXapm_paraprobe_tool_results): - exists: ['min', '1', 'max', '1'] - doc: | - The tool can be used to compute a Voronoi tessellation the entire - or of a sub-set of the reconstructed volume. Each point (ion) is wrapped - in one (Voronoi) cell. The point cloud in the ROI is wrapped into an - axis-aligned bounding box (AABB) that is tight. This means points at - the edge of the point cloud can lay on the surface of the bounding box. - The tool detects if cells make contact with the walls of this bounding box. - The tessellation is computed without periodic boundary conditions. - - # config - window(NXcs_filter_boolean_mask): - number_of_ions(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - - # results - wall(NXcg_hexahedron_set): - exists: recommended - doc: | - The (tight) axis-aligned bounding box about the point cloud. - closest_corner(NX_FLOAT): - unit: NX_LENGTH - doc: | - Coordinate triplet of the corner that lays closests - to the origin of the *paraprobe* coordinate system. - dimensions: - rank: 1 - dim: [[1, 3]] - farthest_corner(NX_FLOAT): - unit: NX_LENGTH - doc: | - Coordinate triplet of the corner that lays farthest away - from the origin of the *paraprobe* coordinate system. - dimensions: - rank: 1 - dim: [[1, 3]] - voronoi_cells(NXcg_polyhedron_set): - exists: optional - dimensionality(NX_POSINT): - unit: NX_UNITLESS - enumeration: [3] - cardinality(NX_POSINT): - unit: NX_UNITLESS - doc: | - The number of points (and thus cells). - volume(NX_FLOAT): - unit: NX_VOLUME - doc: | - Volume of each Voronoi cell. - dimensions: - rank: 1 - dim: [[1, n_ions]] - process_identifier(NX_POSINT): - exists: optional - unit: NX_UNITLESS - doc: | - Which MPI process computed which Voronoi cell. - dimensions: - rank: 1 - dim: [[1, n_ions]] - thread_identifier(NX_POSINT): - exists: optional - unit: NX_UNITLESS - doc: | - Which OpenMP thread computed which Voronoi cell. - dimensions: - rank: 1 - dim: [[1, n_ions]] - number_of_faces(NX_INT): - exists: optional - unit: NX_UNITLESS - doc: | - The number of faces for each cell. Faces of adjoining polyhedra are counted - for each polyhedron. This field can be used to interpret the concatenated vector - with the individual values for the area of each face. - dimensions: - rank: 1 - dim: [[1, n_ions]] - identifier_offset(NX_INT): - polyhedra(NXcg_face_list_data_structure): - exists: optional - doc: | - A simple approach to describe the entire set of polyhedra when the main - intention is to store the shape of the polyhedra for visualization purposes. - number_of_vertices(NX_INT): - number_of_faces(NX_INT): - vertex_identifier_offset(NX_INT): - face_identifier_offset(NX_INT): - vertices(NX_FLOAT): - xdmf_topology(NX_UINT): - unit: NX_UNITLESS - doc: | - Sequence of tuples, concatenated in the order of the Voronoi cells. - Each tuple contains encodes information to visualize using XDMF: - Firstly, an XDMF geometric primitive type key. - Secondly, the number of vertices of the polygon. - Third, the sequence of vertex identifier which define the facet. - Tuples encode faces faster than cells. - dimensions: - rank: 1 - dim: [[1, n_f_xdmf]] - xdmf_cell_identifier(NX_UINT): - unit: NX_UNITLESS - doc: | - Sequence of cell identifier, concatenated such that each face is - associated with its cell. Given that paraprobe-tessellator assigns - each cell the evaporation_id of the ion that the cell wraps this - information enables the segmentation of the tessellation and - thus correlate per-ion properties with the volume that each cell - represents. - dimensions: - rank: 1 - dim: [[1, n_f]] - wall_contact_global(NXcs_filter_boolean_mask): - exists: recommended - doc: | - A bitmask that documents which of the cells are likely truncated because they - share at least one face with the *aabb* of the point cloud. This field encodes the - result of the boolean or operator applied to the value of all six wall_contact groups - that document contact in specific outer unit normal directions of the *aabb*. - number_of_objects(NX_UINT): - dimensions: - rank: 1 - dim: [[1, n_ions]] - bitdepth(NX_UINT): - mask(NX_UINT): - - # dim: (i,) # not necessarily n_ions because n_ions is not always an integer multiple of bitdepth - # dim: (i,) # one would not need to constrain this but doing so communicates that all six bitfields have the same length - wall_contact_left(NXcs_filter_boolean_mask): - exists: recommended - doc: | - In the spirit of wall_contact_global, the left face of *aabb*. - Its outer unit normal points in the opposite direction of the - x-axis of the *paraprobe* coordinate system. - number_of_objects(NX_UINT): - dimensions: - rank: 1 - dim: [[1, n_ions]] - bitdepth(NX_UINT): - mask(NX_UINT): - wall_contact_right(NXcs_filter_boolean_mask): - exists: recommended - doc: | - In the spirit of wall_contact_global, the right face of *aabb*. - Its outer unit normal points in the direction of the x-axis - of the *paraprobe* coordinate system. - number_of_objects(NX_UINT): - dimensions: - rank: 1 - dim: [[1, n_ions]] - bitdepth(NX_UINT): - mask(NX_UINT): - wall_contact_front(NXcs_filter_boolean_mask): - exists: recommended - doc: | - In the spirit of wall_contact_global, the front face of *aabb*. - Its outer unit normal points in the opposite direction of the - y-axis of the *paraprobe* coordinate system. - number_of_objects(NX_UINT): - dimensions: - rank: 1 - dim: [[1, n_ions]] - bitdepth(NX_UINT): - mask(NX_UINT): - wall_contact_rear(NXcs_filter_boolean_mask): - exists: recommended - doc: | - In the spirit of wall_contact_global, the rear face of *aabb*. - Its outer unit normal points in the direction of the y-axis - of the *paraprobe* coordinate system. - number_of_objects(NX_UINT): - dimensions: - rank: 1 - dim: [[1, n_ions]] - bitdepth(NX_UINT): - mask(NX_UINT): - wall_contact_bottom(NXcs_filter_boolean_mask): - exists: recommended - doc: | - In the spirit of wall_contact_global, the front face of *aabb*. - Its outer unit normal points in the opposite direction of the - z-axis of the *paraprobe* coordinate system. - number_of_objects(NX_UINT): - dimensions: - rank: 1 - dim: [[1, n_ions]] - bitdepth(NX_UINT): - mask(NX_UINT): - wall_contact_top(NXcs_filter_boolean_mask): - doc: | - In the spirit of wall_contact_global, the front face of *aabb*. - Its outer unit normal points in the direction of the z-axis of the - *paraprobe* coordinate system. - number_of_ions(NX_UINT): - dimensions: - rank: 1 - dim: [[1, n_ions]] - bitdepth(NX_UINT): - mask(NX_UINT): - common(NXapm_paraprobe_tool_common): - status(NX_CHAR): - analysis_identifier(NX_UINT): - config(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - profiling(NXcs_profiling): - exists: recommended - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - total_elapsed_time(NX_FLOAT): - current_working_directory(NX_CHAR): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - userID(NXuser): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - If used, metadata of at least the person who performed this analysis. - name(NX_CHAR): - coordinate_system_set(NXcoordinate_system_set): - exists: ['min', '1', 'max', '1'] - paraprobe(NXcoordinate_system): - type(NX_CHAR): - handedness(NX_CHAR): - x(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - y(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - z(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 281fc45c747c1793f02edba1e0fc8de5ccb99deb1014f2e7153bc4c1dbe7cb7d -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The total number of ions in the reconstruction. -# -# -# -# -# The total number of values required to represent all faces of each cell. -# -# -# -# -# The total number of values required to represent all faces of each cell -# (polyhedron) using XDMF. -# -# -# -# -# Application definition for results files of the paraprobe-tessellator tool. -# -# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. -# -# -# -# -# -# -# -# -# -# -# -# The tool can be used to compute a Voronoi tessellation the entire -# or of a sub-set of the reconstructed volume. Each point (ion) is wrapped -# in one (Voronoi) cell. The point cloud in the ROI is wrapped into an -# axis-aligned bounding box (AABB) that is tight. This means points at -# the edge of the point cloud can lay on the surface of the bounding box. -# The tool detects if cells make contact with the walls of this bounding box. -# The tessellation is computed without periodic boundary conditions. -# -# -# -# -# -# -# -# -# -# -# The (tight) axis-aligned bounding box about the point cloud. -# -# -# -# Coordinate triplet of the corner that lays closests -# to the origin of the *paraprobe* coordinate system. -# -# -# -# -# -# -# -# Coordinate triplet of the corner that lays farthest away -# from the origin of the *paraprobe* coordinate system. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The number of points (and thus cells). -# -# -# -# -# Volume of each Voronoi cell. -# -# -# -# -# -# -# -# Which MPI process computed which Voronoi cell. -# -# -# -# -# -# -# -# Which OpenMP thread computed which Voronoi cell. -# -# -# -# -# -# -# -# The number of faces for each cell. Faces of adjoining polyhedra are counted -# for each polyhedron. This field can be used to interpret the concatenated vector -# with the individual values for the area of each face. -# -# -# -# -# -# -# -# -# A simple approach to describe the entire set of polyhedra when the main -# intention is to store the shape of the polyhedra for visualization purposes. -# -# -# -# -# -# -# -# -# -# Sequence of tuples, concatenated in the order of the Voronoi cells. -# Each tuple contains encodes information to visualize using XDMF: -# Firstly, an XDMF geometric primitive type key. -# Secondly, the number of vertices of the polygon. -# Third, the sequence of vertex identifier which define the facet. -# Tuples encode faces faster than cells. -# -# -# -# -# -# -# -# Sequence of cell identifier, concatenated such that each face is -# associated with its cell. Given that paraprobe-tessellator assigns -# each cell the evaporation_id of the ion that the cell wraps this -# information enables the segmentation of the tessellation and -# thus correlate per-ion properties with the volume that each cell -# represents. -# -# -# -# -# -# -# -# -# A bitmask that documents which of the cells are likely truncated because they -# share at least one face with the *aabb* of the point cloud. This field encodes the -# result of the boolean or operator applied to the value of all six wall_contact groups -# that document contact in specific outer unit normal directions of the *aabb*. -# -# -# -# -# -# -# -# -# -# -# -# -# In the spirit of wall_contact_global, the left face of *aabb*. -# Its outer unit normal points in the opposite direction of the -# x-axis of the *paraprobe* coordinate system. -# -# -# -# -# -# -# -# -# -# -# -# In the spirit of wall_contact_global, the right face of *aabb*. -# Its outer unit normal points in the direction of the x-axis -# of the *paraprobe* coordinate system. -# -# -# -# -# -# -# -# -# -# -# -# In the spirit of wall_contact_global, the front face of *aabb*. -# Its outer unit normal points in the opposite direction of the -# y-axis of the *paraprobe* coordinate system. -# -# -# -# -# -# -# -# -# -# -# -# In the spirit of wall_contact_global, the rear face of *aabb*. -# Its outer unit normal points in the direction of the y-axis -# of the *paraprobe* coordinate system. -# -# -# -# -# -# -# -# -# -# -# -# In the spirit of wall_contact_global, the front face of *aabb*. -# Its outer unit normal points in the opposite direction of the -# z-axis of the *paraprobe* coordinate system. -# -# -# -# -# -# -# -# -# -# -# -# In the spirit of wall_contact_global, the front face of *aabb*. -# Its outer unit normal points in the direction of the z-axis of the -# *paraprobe* coordinate system. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If used, metadata of at least the person who performed this analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml deleted file mode 100644 index 00a76c6634..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml +++ /dev/null @@ -1,223 +0,0 @@ -category: base -doc: | - Base class documenting the information common to tools of the paraprobe-toolbox. - - The paraprobe-toolbox is a collection of open-source tools for performing - efficient analyses of point cloud data where each point can represent atoms or - (molecular) ions. A key application of the toolbox has been for research in the - field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): - - * `paraprobe-toolbox `_ - * `M. Kühbach et al. `_ - - The toolbox does not replace but complements existent software tools in this - research field. Given its capabilities of handling points as objects with - properties and enabling analyses of the spatial arrangement of and inter- - sections between geometric primitives, the software can equally be used - for analyzing data in Materials Science and Materials Engineering. - - The common section can be used as a place to store e.g. organizational - metadata and contextualization of that analysis in a research data - management system. -type: group -NXapm_paraprobe_tool_common(NXobject): - status(NX_CHAR): - doc: | - A statement whether the tool executable managed to process the analysis - or whether this failed. Status is written to the results file after the - end_time beyond which point in time the tool must no longer compute - any further analysis results but exit. - - Only when this status message is present and its value is `success`, - one should consider the results of the tool. In all other cases it might - be that the tool has terminated prematurely or another error occurred. - enumeration: [success, failure] - (NXprogram): - (NXidentifier): - analysis_identifier(NX_UINT): - unit: NX_UNITLESS - doc: | - Internal identifier used by the tool to refer to an analysis (aka simulation - id). - config(NXserialized): - doc: | - The configuration file that was used to parameterize - the algorithms that this tool has executed. - profiling(NXcs_profiling): - - # results_path(NX_CHAR): - # doc: | - # Path where the tool stores tool-specific results. If not specified, - # results will be stored in the current working directory. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis in this results file was started, - i.e. when the respective executable/tool was started as a process. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis in this results file were - completed and the respective process of the tool exited. - total_elapsed_time(NX_FLOAT): - unit: NX_TIME - doc: | - Wall-clock time. - (NXuser): - (NXcoordinate_system_set): - doc: | - Details about coordinate systems (reference frames) used. In atom probe several coordinate - systems have to be distinguished. Names of instances of such :ref:`NXcoordinate_system` - should be documented explicitly and doing so by picking from the - following controlled set of names: - - * paraprobe - * lab - * specimen - * laser - * instrument - * detector - * recon - - The aim of this convention is to support users with contextualizing which reference frame - each instance (coordinate system) is. If needed, instances of :ref:`NXtransformations` - are used to detail the explicit affine transformations whereby one can convert - representations between different reference frames. - Inspect :ref:`NXtransformations` for further details. - (NXcoordinate_system): - (NXtransformations): - - # add further fields coming from using the charge state recovery - # workflow from the ifes_apt_tc_data_modeling library - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d3a258a391c4a82831ce0c65af5146f833be78e8fba8045f2e0641fd1976747d -# -# -# -# -# -# Base class documenting the information common to tools of the paraprobe-toolbox. -# -# The paraprobe-toolbox is a collection of open-source tools for performing -# efficient analyses of point cloud data where each point can represent atoms or -# (molecular) ions. A key application of the toolbox has been for research in the -# field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): -# -# * `paraprobe-toolbox <https://www.gitlab.com/paraprobe/paraprobe-toolbox>`_ -# * `M. Kühbach et al. <https://paraprobe-toolbox.readthedocs.io/en/main/>`_ -# -# The toolbox does not replace but complements existent software tools in this -# research field. Given its capabilities of handling points as objects with -# properties and enabling analyses of the spatial arrangement of and inter- -# sections between geometric primitives, the software can equally be used -# for analyzing data in Materials Science and Materials Engineering. -# -# The common section can be used as a place to store e.g. organizational -# metadata and contextualization of that analysis in a research data -# management system. -# -# -# -# A statement whether the tool executable managed to process the analysis -# or whether this failed. Status is written to the results file after the -# end_time beyond which point in time the tool must no longer compute -# any further analysis results but exit. -# -# Only when this status message is present and its value is `success`, -# one should consider the results of the tool. In all other cases it might -# be that the tool has terminated prematurely or another error occurred. -# -# -# -# -# -# -# -# -# -# -# Internal identifier used by the tool to refer to an analysis (aka simulation -# id). -# -# -# -# -# The configuration file that was used to parameterize -# the algorithms that this tool has executed. -# -# -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when the analysis in this results file was started, -# i.e. when the respective executable/tool was started as a process. -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when the analysis in this results file were -# completed and the respective process of the tool exited. -# -# -# -# -# Wall-clock time. -# -# -# -# -# -# -# Details about coordinate systems (reference frames) used. In atom probe several coordinate -# systems have to be distinguished. Names of instances of such :ref:`NXcoordinate_system` -# should be documented explicitly and doing so by picking from the -# following controlled set of names: -# -# * paraprobe -# * lab -# * specimen -# * laser -# * instrument -# * detector -# * recon -# -# The aim of this convention is to support users with contextualizing which reference frame -# each instance (coordinate system) is. If needed, instances of :ref:`NXtransformations` -# are used to detail the explicit affine transformations whereby one can convert -# representations between different reference frames. -# Inspect :ref:`NXtransformations` for further details. -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml deleted file mode 100644 index 2258eed048..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml +++ /dev/null @@ -1,239 +0,0 @@ -category: base -doc: | - Base class documenting the configuration used for a tool of the paraprobe-toolbox. - - The paraprobe-toolbox is a collection of open-source software tools for performing - efficient analyses of point cloud data where each point can represent atoms or - (molecular) ions. A key application of the toolbox has been for research in the - field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): - - * `paraprobe-toolbox `_ - * `M. Kühbach et al. `_ - - The toolbox does not replace but complements existent software tools in this - research field. Given its capabilities of handling points as objects with - properties and enabling analyses of the spatial arrangement of and inter- - sections between geometric primitives, the software can equally be used - for analyzing data in Materials Science and Materials Engineering. - - The configuration and results of a run of a tool from the toolbox is documented - using binary container formats. Currently, paraprobe-toolbox uses the - Hierarchical Data Format 5 (HDF5). -type: group -NXapm_paraprobe_tool_config(NXobject): - - # sequence_id is inherited from NXprocess - (NXidentifier): - analysis_identifier(NX_UINT): - unit: NX_UNITLESS - doc: | - Internal identifier used by the tool to refer to an analysis (aka simulation - id). - description(NX_CHAR): - doc: | - Possibility for leaving a free-text description about this analysis. - - Although offered here for convenience we strongly encourage to - parameterize such descriptions as much as possible to support - reusage and clearer communication. - - # tool-specific input, examples for definitions for common types of input granularized into this - # base class from which tool-specific appdefs inherit - reconstruction(NXserialized): - doc: | - Specification of the tomographic reconstruction to use for this analysis. - - Typically, reconstructions in the field of atom probe tomography are communicated - via files which store at least reconstructed ion positions and mass-to-charge-state-ratio - values. Container files like HDF5 though can store multiple reconstructions. - Therefore, the position and mass_to_charge concepts point to specific instances - to use for this analysis. - position(NX_CHAR): - doc: | - Name of the node which resolves the reconstructed ion position - values to use for this analysis. - mass_to_charge(NX_CHAR): - doc: | - Name of the node which resolves the mass-to-charge-state-ratio - values to use for this analysis. - ranging(NXserialized): - doc: | - Specification of the ranging definitions to use for this analysis. - - Ranging is the process of labeling time-of-flight data with so-called iontypes - (aka ion species). Ideally, iontypes specify the most likely (molecular) ion - that is assumed to have been evaporated given that its mass-to-charge-state ratio - lies within the specific mass-to-charge-state-ratio value interval of the iontype. - - The so-called UNKNOWNTYPE iontype represents the null model of an ion - that has not been ranged (for whatever reasons). - The identifier of this special iontype is always the reserved value 0. - ranging_definitions(NX_CHAR): - doc: | - Name of the (parent) node directly below which (in the hierarchy) - the ranging definition for (molecular) ions are stored. - surface(NXserialized): - doc: | - Specification of the triangulated surface mesh to use for this analysis. - - Such a surface mesh can be used to define the edge of the reconstructed - volume to account for finite size effects. - - # mesh(NX_CHAR): - # doc: | - # Name of the (parent) node directly below which (in the hierarchy) - # an instance of :ref:`NXcg_triangle_set` is stored. - surface_distance(NXserialized): - doc: | - Specification of the point-to-triangulated-surface-mesh distances to - use for this analysis. - distance(NX_CHAR): - doc: | - Absolute path in the (HDF5) file that points to the distance values. - The tool assumes that the values are stored in the same order as - points (ions). - - # filters - (NXspatial_filter): - (NXsubsampling_filter): - (NXmatch_filter): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e12a33529aaeaf9b2276b86fdecb3b89bc4d34092bbc8aa9b72c38b684bce23f -# -# -# -# -# -# Base class documenting the configuration used for a tool of the paraprobe-toolbox. -# -# The paraprobe-toolbox is a collection of open-source software tools for performing -# efficient analyses of point cloud data where each point can represent atoms or -# (molecular) ions. A key application of the toolbox has been for research in the -# field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): -# -# * `paraprobe-toolbox <https://www.gitlab.com/paraprobe/paraprobe-toolbox>`_ -# * `M. Kühbach et al. <https://paraprobe-toolbox.readthedocs.io/en/main/>`_ -# -# The toolbox does not replace but complements existent software tools in this -# research field. Given its capabilities of handling points as objects with -# properties and enabling analyses of the spatial arrangement of and inter- -# sections between geometric primitives, the software can equally be used -# for analyzing data in Materials Science and Materials Engineering. -# -# The configuration and results of a run of a tool from the toolbox is documented -# using binary container formats. Currently, paraprobe-toolbox uses the -# Hierarchical Data Format 5 (HDF5). -# -# -# -# -# -# Internal identifier used by the tool to refer to an analysis (aka simulation -# id). -# -# -# -# -# Possibility for leaving a free-text description about this analysis. -# -# Although offered here for convenience we strongly encourage to -# parameterize such descriptions as much as possible to support -# reusage and clearer communication. -# -# -# -# -# -# Specification of the tomographic reconstruction to use for this analysis. -# -# Typically, reconstructions in the field of atom probe tomography are communicated -# via files which store at least reconstructed ion positions and mass-to-charge-state-ratio -# values. Container files like HDF5 though can store multiple reconstructions. -# Therefore, the position and mass_to_charge concepts point to specific instances -# to use for this analysis. -# -# -# -# Name of the node which resolves the reconstructed ion position -# values to use for this analysis. -# -# -# -# -# Name of the node which resolves the mass-to-charge-state-ratio -# values to use for this analysis. -# -# -# -# -# -# Specification of the ranging definitions to use for this analysis. -# -# Ranging is the process of labeling time-of-flight data with so-called iontypes -# (aka ion species). Ideally, iontypes specify the most likely (molecular) ion -# that is assumed to have been evaporated given that its mass-to-charge-state ratio -# lies within the specific mass-to-charge-state-ratio value interval of the iontype. -# -# The so-called UNKNOWNTYPE iontype represents the null model of an ion -# that has not been ranged (for whatever reasons). -# The identifier of this special iontype is always the reserved value 0. -# -# -# -# Name of the (parent) node directly below which (in the hierarchy) -# the ranging definition for (molecular) ions are stored. -# -# -# -# -# -# Specification of the triangulated surface mesh to use for this analysis. -# -# Such a surface mesh can be used to define the edge of the reconstructed -# volume to account for finite size effects. -# -# -# -# -# -# Specification of the point-to-triangulated-surface-mesh distances to -# use for this analysis. -# -# -# -# Absolute path in the (HDF5) file that points to the distance values. -# The tool assumes that the values are stored in the same order as -# points (ions). -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tool_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tool_results.yaml deleted file mode 100644 index f08cbb7102..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tool_results.yaml +++ /dev/null @@ -1,149 +0,0 @@ -category: base -doc: | - Base class documenting the results obtained with a tool of the paraprobe-toolbox. - - The paraprobe-toolbox is a collection of open-source tools for performing - efficient analyses of point cloud data where each point can represent atoms or - (molecular) ions. A key application of the toolbox has been for research in the - field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): - - * `paraprobe-toolbox `_ - * `M. Kühbach et al. `_ - - The toolbox does not replace but complements existent software tools in this - research field. Given its capabilities of handling points as objects with - properties and enabling analyses of the spatial arrangement of and inter- - sections between geometric primitives, the software can equally be used - for analyzing data in Materials Science and Materials Engineering. - - The configuration and results of a run of a tool from the toolbox is documented - using binary container formats. Currently, paraprobe-toolbox uses the - Hierarchical Data Format 5 (HDF5). - - The paraprobe coordinate system is the reference *NXcoordinate_system* - for each geometric primitive. - -# thereby implicitly all \@default attributes for geometric primitives point to the -# single instance ENTRY[entry]/COORDINATE_SYSTEM_SET[coordinate_system_set]/paraprobe -# symbols: -# doc: | -# The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXapm_paraprobe_tool_results(NXprocess): - - # config section - description(NX_CHAR): - doc: | - Possibility for leaving a free-text description about this analysis. - window(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies all ions considered in the analysis. - number_of_ions(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of ions covered by the mask. - By default, the total number of ions in the dataset. - bitdepth(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of bits assumed matching on a default datatype. - mask(NX_UINT): - unit: NX_UNITLESS - doc: | - The mask. The length of the mask is an integer multiple of bitdepth. - In such case, padded bits are set to 0. - dimensions: - rank: 1 - dim: [[1, i]] - - # typically tool-specific section follows - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 1241565d5164b6a79f9f6321aa2df39420ef356b753fc262c602f5aaa4b02915 -# -# -# -# -# -# -# Base class documenting the results obtained with a tool of the paraprobe-toolbox. -# -# The paraprobe-toolbox is a collection of open-source tools for performing -# efficient analyses of point cloud data where each point can represent atoms or -# (molecular) ions. A key application of the toolbox has been for research in the -# field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): -# -# * `paraprobe-toolbox <https://www.gitlab.com/paraprobe/paraprobe-toolbox>`_ -# * `M. Kühbach et al. <https://paraprobe-toolbox.readthedocs.io/en/main/>`_ -# -# The toolbox does not replace but complements existent software tools in this -# research field. Given its capabilities of handling points as objects with -# properties and enabling analyses of the spatial arrangement of and inter- -# sections between geometric primitives, the software can equally be used -# for analyzing data in Materials Science and Materials Engineering. -# -# The configuration and results of a run of a tool from the toolbox is documented -# using binary container formats. Currently, paraprobe-toolbox uses the -# Hierarchical Data Format 5 (HDF5). -# -# The paraprobe coordinate system is the reference *NXcoordinate_system* -# for each geometric primitive. -# -# -# -# -# Possibility for leaving a free-text description about this analysis. -# -# -# -# -# A bitmask which identifies all ions considered in the analysis. -# -# -# -# Number of ions covered by the mask. -# By default, the total number of ions in the dataset. -# -# -# -# -# Number of bits assumed matching on a default datatype. -# -# -# -# -# The mask. The length of the mask is an integer multiple of bitdepth. -# In such case, padded bits are set to 0. -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml deleted file mode 100644 index fc88b927e2..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml +++ /dev/null @@ -1,145 +0,0 @@ -category: application -doc: | - Application definition for a configuration file of the paraprobe-transcoder tool. - - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. - -# symbols: -# doc: | -# The symbols used in the schema to specify e.g. dimensions of arrays. - -# official NeXus appdef headers -type: group -NXapm_paraprobe_transcoder_config(NXobject): - (NXentry): - exists: ['min', '1', 'max', '1'] - - # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently - definition(NX_CHAR): - \@version: - type: NX_CHAR - enumeration: [NXapm_paraprobe_transcoder_config] - - # tool-specific - transcode(NXapm_paraprobe_tool_config): - exists: ['min', '1', 'max', '1'] - (NXidentifier): - exists: optional - analysis_identifier(NX_UINT): - exists: recommended - reconstruction(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - position(NX_CHAR): - mass_to_charge(NX_CHAR): - ranging(NXserialized): - doc: | - Specification of the ranging definition file to use for this analysis. - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - - # tool-specific parameter - # filter - common(NXapm_paraprobe_tool_common): - status(NX_CHAR): - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - profiling(NXcs_profiling): - exists: recommended - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - total_elapsed_time(NX_FLOAT): - current_working_directory(NX_CHAR): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# ab86874f92a46be39257ce80c32be0c4e47a3738d5b6bd12e0ffc3f0d2d9950e -# -# -# -# -# -# -# -# Application definition for a configuration file of the paraprobe-transcoder tool. -# -# This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Specification of the ranging definition file to use for this analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml deleted file mode 100644 index 3dc9d7a417..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml +++ /dev/null @@ -1,389 +0,0 @@ -category: application -doc: | - Application definition for results files of the paraprobe-transcoder tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. - The purpose and need of the paraprobe-transcoder tool is to create a standardized representation - of reconstructed position and mass-to-charge-state-ratio values surplus other pieces of information - to enable working with atom probe data in reconstruction space in the paraprobe-toolbox. - This includes ranging definitions which map mass-to-charge-state ratio values onto iontypes. - - So far the atom probe community has not yet agreed upon a comprehensive standardization on how to - exchange information especially when it comes to the communication of configurations and results - from analyses of atom probe data. Instead, different simplistic file formats are used, such as POS, ePOS, - APT, or RNG and RRNG. None of these formats, though, are self-descriptive, standardize, or document - their origin and thus the sequence in which the file was generated during an analysis. - - Paraprobe-transcoder solves this limitation by interpreting the information content in such files - and standardize the representation prior injection into the scientific data analysis tools of the toolbox. - Therefore, the here proposed set of NeXus base classes and application definitions can be a useful - starting point for the atom probe community to take advantage of standardized information - exchange and improve the here proposed classes and concepts to become more inclusive. - - Paraprobe-transcoder uses a Python library developed based on efforts by members of the - global atom probe community `International Field Emission Society (IFES) Atom Probe Technical Committee (APT TC) `_. This library offers the - actual low-level I/O operations and respective information interpretation of above-mentioned file formats. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_ions: | - The total number of ions in the reconstruction. - n_ivec_max: | - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. - n_topology: | - Total number of integers in the supplementary XDMF topology array. - n_variable: | - Number of entries - -# i be careful n_comb can vary for every instance of (NXion) ! -type: group -NXapm_paraprobe_transcoder_results(NXobject): - (NXentry): - exists: ['min', '1', 'max', '1'] - definition(NX_CHAR): - \@version: - type: NX_CHAR - enumeration: [NXapm_paraprobe_transcoder_results] - - # tasks - atom_probe(NXapm_paraprobe_tool_results): - - # this group mirrors the NXapm application definition - # config - analysis_identifier(NX_UINT): - config(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - window(NXcs_filter_boolean_mask): - exists: optional - doc: | - By default the entire reconstructed volume is processed. - In this case, using window is also equivalent to an - NXspatial_filter that specified a window *entire_dataset*. - number_of_ions(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - - # results - mass_to_charge_conversion(NXprocess): - mass_to_charge(NX_FLOAT): - unit: NX_ANY - doc: | - Mass-to-charge-state-ratio values. - dimensions: - rank: 1 - dim: [[1, n_ions]] - reconstruction(NXprocess): - reconstructed_positions(NX_FLOAT): - unit: NX_LENGTH - doc: | - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - dimensions: - rank: 2 - dim: [[1, n_ions], [2, 3]] - \@depends_on: - type: NX_CHAR - doc: | - Defines in which reference frame the positions are defined. - visualization(NXprocess): - exists: recommended - xdmf_topology(NX_UINT): - unit: NX_UNITLESS - doc: | - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstruction. The XDMF datatype - is here 1, the number of primitives 1 per triplet, the last integer - in each triplet is the identifier of each point starting from zero. - dimensions: - rank: 1 - dim: [[1, n_topology]] - ranging(NXprocess): - peak_identification(NXprocess): - doc: | - Details about how peaks are interpreted as ion types or not. - (NXion): - exists: ['min', '1', 'max', '256'] - nuclide_hash(NX_UINT): - nuclide_list(NX_UINT): - exists: recommended - charge_state(NX_INT): - mass_to_charge_range(NX_FLOAT): - unit: NX_ANY - dimensions: - rank: 2 - dim: [[1, n_variable], [2, 2]] - - # (NXapm_charge_state_analysis): - common(NXapm_paraprobe_tool_common): - status(NX_CHAR): - analysis_identifier(NX_UINT): - config(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - profiling(NXcs_profiling): - exists: recommended - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - total_elapsed_time(NX_FLOAT): - current_working_directory(NX_CHAR): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - userID(NXuser): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - If used, metadata of at least the person who performed this analysis. - name(NX_CHAR): - coordinate_system_set(NXcoordinate_system_set): - exists: ['min', '1', 'max', '1'] - paraprobe(NXcoordinate_system): - type(NX_CHAR): - handedness(NX_CHAR): - x(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - y(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - z(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 9bd34c352b0573cf258afd984aa23c4791ba99d3dc581b0edd7ad4b5a1fcd9af -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The total number of ions in the reconstruction. -# -# -# -# -# Maximum number of allowed atoms per (molecular) ion (fragment). -# Needs to match maximum_number_of_atoms_per_molecular_ion. -# -# -# -# -# Total number of integers in the supplementary XDMF topology array. -# -# -# -# -# Number of entries -# -# -# -# -# Application definition for results files of the paraprobe-transcoder tool. -# -# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. -# The purpose and need of the paraprobe-transcoder tool is to create a standardized representation -# of reconstructed position and mass-to-charge-state-ratio values surplus other pieces of information -# to enable working with atom probe data in reconstruction space in the paraprobe-toolbox. -# This includes ranging definitions which map mass-to-charge-state ratio values onto iontypes. -# -# So far the atom probe community has not yet agreed upon a comprehensive standardization on how to -# exchange information especially when it comes to the communication of configurations and results -# from analyses of atom probe data. Instead, different simplistic file formats are used, such as POS, ePOS, -# APT, or RNG and RRNG. None of these formats, though, are self-descriptive, standardize, or document -# their origin and thus the sequence in which the file was generated during an analysis. -# -# Paraprobe-transcoder solves this limitation by interpreting the information content in such files -# and standardize the representation prior injection into the scientific data analysis tools of the toolbox. -# Therefore, the here proposed set of NeXus base classes and application definitions can be a useful -# starting point for the atom probe community to take advantage of standardized information -# exchange and improve the here proposed classes and concepts to become more inclusive. -# -# Paraprobe-transcoder uses a Python library developed based on efforts by members of the -# global atom probe community `International Field Emission Society (IFES) Atom Probe Technical Committee (APT TC) <https://www.github.com/atomprobe-tc/ifes_apt_tc_data_modeling>`_. This library offers the -# actual low-level I/O operations and respective information interpretation of above-mentioned file formats. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# By default the entire reconstructed volume is processed. -# In this case, using window is also equivalent to an -# NXspatial_filter that specified a window *entire_dataset*. -# -# -# -# -# -# -# -# -# -# Mass-to-charge-state-ratio values. -# -# -# -# -# -# -# -# -# -# Three-dimensional reconstructed positions of the ions. -# Interleaved array of x, y, z positions in the specimen space. -# -# -# -# -# -# -# -# Defines in which reference frame the positions are defined. -# -# -# -# -# -# -# An array of triplets of integers which can serve as a supplementary -# array for Paraview to display the reconstruction. The XDMF datatype -# is here 1, the number of primitives 1 per triplet, the last integer -# in each triplet is the identifier of each point starting from zero. -# -# -# -# -# -# -# -# -# -# -# Details about how peaks are interpreted as ion types or not. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If used, metadata of at least the person who performed this analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXatom_set.yaml b/contributed_definitions/nyaml/NXatom_set.yaml deleted file mode 100644 index 42d8dc5608..0000000000 --- a/contributed_definitions/nyaml/NXatom_set.yaml +++ /dev/null @@ -1,272 +0,0 @@ -category: base -doc: | - Base class for documenting a set of atoms. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_ivec_max: | - Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). - n_ranges: | - Number of mass-to-charge-state-ratio range intervals for ion type. -type: group -NXatom_set(NXobject): - identifier(NX_CHAR): - doc: | - A unique identifier whereby such an ion can be referred to - via the service offered as described in identifier_type. - identifier_type(NX_CHAR): - doc: | - How can the identifier be resolved? - enumeration: [inchi] - ion_type(NX_UINT): - unit: NX_UNITLESS - doc: | - Ion type (ion species) identifier. - - The identifier zero is reserved for the special unknown ion type. - nuclide_hash(NX_UINT): - unit: NX_UNITLESS - doc: | - Vector of nuclide hash values. - - Individual hash values :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` - encode the number of protons :math:`Z` and the number of neutrons :math:`N` - of each nuclide respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. - - The array is sorted in decreasing order. For the rationale behind this see `M. Kühbach et al. (2021) `_ - dimensions: - rank: 1 - dim: [[1, n_ivec_max]] - nuclide_list(NX_UINT): - unit: NX_UNITLESS - doc: | - Table which decodes the entries in nuclide_hash into a human-readable matrix of instances. - The first column specifies the nuclide mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N` or 0. The value 0 documents that no - isotope-specific information about the element encoded is relevant. - The second row specifies the number of protons :math:`Z` or 0. - The value 0 in this case documents a placeholder or that no element-specific - information is relevant. - Taking a carbon-14 nuclide as an example the mass number is 14. - That is encoded as a value pair (14, 6) as one row of the table. - - Therefore, this notation is the typical superscribed nuclide mass number - and subscripted number of protons element notation e.g. :math:`^{14}C`. - The array is stored matching the order of nuclide_hash. - dimensions: - rank: 2 - dim: [[1, n_ivecmax], [2, 2]] - - # color(NX_CHAR): - # doc: | - # Color code used for visualizing such ions. - volume(NX_NUMBER): - unit: NX_VOLUME - doc: | - Assumed volume of the ion. - - In atom probe microscopy this field can be used to store the reconstructed - volume per ion (average) which is typically stored alongside ranging - definitions. - charge(NX_NUMBER): - unit: NX_CHARGE - doc: | - Charge of the ion. - charge_state(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Signed charge state if the atoms form an ion reported in multiples of electron charge. - - In the example of atom probe microscopy, only positive values will be measured - as the ions are accelerated by a negatively signed bias electric field. - In the case that the charge state is not explicitly recoverable, the value should - be set to zero. - - In atom probe microscopy this is for example the case when using - classical ranging definition files in formats like RNG, RRNG. - These file formats do not document the charge state explicitly - but the number of atoms of each element per molecular ion - surplus the mass-to-charge-state-ratio interval. - Details on ranging definition files can be found in the literature: - `M. K. Miller `_ - name(NX_CHAR): - doc: | - Human-readable name (e.g. Al +++) of the atom set, the atom group, or ion type. - The string should consists of UTF-8 characters, ideally using LaTeX - notation to specify the isotopes, ions, and charge state. - Examples are 12C + or Al +++. - - To ease automated parsing, isotope_vector should be the - preferred machine-readable information used. - mass_to_charge_range(NX_NUMBER): - unit: NX_ANY - doc: | - Associated lower (mqmin) and upper (mqmax) bounds of the - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries inclusive). This field is primarily of interest - for documenting :ref:`NXprocess` steps of indexing a - ToF/mass-to-charge state histogram. - dimensions: - rank: 2 - dim: [[1, n_ranges], [2, 2]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# c26dcba4e94437fe019c3272bb4116881a59cc9838687a28f48616de696e202c -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). -# -# -# -# -# Number of mass-to-charge-state-ratio range intervals for ion type. -# -# -# -# -# Base class for documenting a set of atoms. -# -# -# -# A unique identifier whereby such an ion can be referred to -# via the service offered as described in identifier_type. -# -# -# -# -# How can the identifier be resolved? -# -# -# -# -# -# -# -# Ion type (ion species) identifier. -# -# The identifier zero is reserved for the special unknown ion type. -# -# -# -# -# Vector of nuclide hash values. -# -# Individual hash values :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` -# encode the number of protons :math:`Z` and the number of neutrons :math:`N` -# of each nuclide respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. -# -# The array is sorted in decreasing order. For the rationale behind this see `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ -# -# -# -# -# -# -# -# Table which decodes the entries in nuclide_hash into a human-readable matrix of instances. -# The first column specifies the nuclide mass number, i.e. using the hashvalues -# from the isotope_vector this is :math:`Z + N` or 0. The value 0 documents that no -# isotope-specific information about the element encoded is relevant. -# The second row specifies the number of protons :math:`Z` or 0. -# The value 0 in this case documents a placeholder or that no element-specific -# information is relevant. -# Taking a carbon-14 nuclide as an example the mass number is 14. -# That is encoded as a value pair (14, 6) as one row of the table. -# -# Therefore, this notation is the typical superscribed nuclide mass number -# and subscripted number of protons element notation e.g. :math:`^{14}C`. -# The array is stored matching the order of nuclide_hash. -# -# -# -# -# -# -# -# -# -# Assumed volume of the ion. -# -# In atom probe microscopy this field can be used to store the reconstructed -# volume per ion (average) which is typically stored alongside ranging -# definitions. -# -# -# -# -# Charge of the ion. -# -# -# -# -# Signed charge state if the atoms form an ion reported in multiples of electron charge. -# -# In the example of atom probe microscopy, only positive values will be measured -# as the ions are accelerated by a negatively signed bias electric field. -# In the case that the charge state is not explicitly recoverable, the value should -# be set to zero. -# -# In atom probe microscopy this is for example the case when using -# classical ranging definition files in formats like RNG, RRNG. -# These file formats do not document the charge state explicitly -# but the number of atoms of each element per molecular ion -# surplus the mass-to-charge-state-ratio interval. -# Details on ranging definition files can be found in the literature: -# `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ -# -# -# -# -# Human-readable name (e.g. Al +++) of the atom set, the atom group, or ion type. -# The string should consists of UTF-8 characters, ideally using LaTeX -# notation to specify the isotopes, ions, and charge state. -# Examples are 12C + or Al +++. -# -# To ease automated parsing, isotope_vector should be the -# preferred machine-readable information used. -# -# -# -# -# Associated lower (mqmin) and upper (mqmax) bounds of the -# mass-to-charge-state ratio interval(s) [mqmin, mqmax] -# (boundaries inclusive). This field is primarily of interest -# for documenting :ref:`NXprocess` steps of indexing a -# ToF/mass-to-charge state histogram. -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXbeam_path.yaml b/contributed_definitions/nyaml/NXbeam_path.yaml deleted file mode 100644 index 033c921fda..0000000000 --- a/contributed_definitions/nyaml/NXbeam_path.yaml +++ /dev/null @@ -1,780 +0,0 @@ -category: base -doc: | - A beam path consisting of one or more optical elements. - - NXbeam_path is used in NXopt to describe the beam path, i.e. the arrangement - of optical elements between the excitation source and the sample, or between - the sample and the detector unit. - - To describe the order of the elements, use 'order(NXtransformations)', where - each element's position points to the preceding element via '@depends_on'. - Special case beam splitter: A beam splitter is a device which separates the - beam into two or more beams. If such a device is part of the beam path use - two or more NXbeam_paths to describe the beam paths after the beam splitter. - In this case, in the dependency chain of the new beam paths, the first - elements each point to the beam splitter, as this is the previous element. - - Describe the relevant optical elements in the beam path by using the - appropriate base classes. You may use as many elements as needed, also - several elements of the same type as long as each element has its own name. - -# 05/2023 -# A draft of a new base class to describe a beam path consisting of one or -# more optical elements (e.g. a beam path in a luminescence setup). - -# To do: -# [ ] Harmonize common fields/classes among base classes used in NXbeam_path, -# e.g. NXshape in NXbeam_splitter and NXpolarizer_opt, or NXsample used for -# describing substrates and coatings etc. -# [ ] How to describe a setup or beam path? Order/sequence defined by -# NXtransformations? => discussion needed -type: group -NXbeam_path(NXobject): - depends_on: - doc: | - Entry point of the dependency chain defined by the NXtransformations - field, i.e. a link to the last element in the beam path. - Example: /entry/instrument/beam_path/detector. - (NXtransformations): - - # Possibilities: - # (1) Modify NXtransformations to include properties that modify the light beam - # (e.g. polarization state) instead (or in addition) to transformations like - # translation and rotation - # (2) Base class similar to NXtransformations but for changes of optical - # properties (e.g. polarization state). - doc: | - Specify the order of the optical elements by defining a dependency chain. - For each element, a '@depends_on' attribute should be used to state the - position of the element in the beam path by pointing to the previous - element. For the very first element, use the string "." instead. - AXISNAME(NX_NUMBER): - unit: NX_TRANSFORMATION - doc: | - For each element in the beam path, one such field must exist with a - '@depends_on' attribute defined to specify its position in the beam - path. Note that also 'NXopt/ENTRY/INSTRUMENT/sample_stage' and windows - ('NXopt/ENTRY/INSTRUMENT/sample_stage/entry_window' and - 'NXopt/ENTRY/INSTRUMENT/sample_stage/exit_window') may be added to the - dependency chain, i.e. may have an entry in this class even if they are - not described in the beam path. - ELEMENT is a place holder for the name of an optical beam path element. - Note that the name of this field must be exactly the same as the - element's field name. - \@depends_on: - doc: | - Add a link to the previous beam path element. - (NXsource): - doc: | - Excitation source. One or more may be needed (e.g. two for a pump-probe - setup with one pump and one probe beam). - Depending on the source type, different properties are relevant, which - are provided through the respective base class (e.g. use NXopt_source for - lamps or lasers, NXchem_source for chemical reaction etc.). - Some base classes are incomplete (NXchem_source, NXbio_source); the - expertise of the respective communities is needed. - depends_on: - doc: | - Use this field to point to the previous optical element. - type: - doc: | - Type of excitation source. - enumeration: [semiconductor laser, gas laser, other laser, lamp, X-rays, silicon carbide globar, super continuum, chemical reaction, ultrasound, sound, living organism, power supply, electron source, other] - - # Spallation Neutron Source - # Pulsed Reactor Neutron Source - # Reactor Neutron Source - # Synchrotron X-ray Source - # Pulsed Muon Source - # Rotating Anode X-ray - # Fixed Tube X-ray - # UV Laser - # Free-Electron Laser - # Optical Laser - # Ion Source - # UV Plasma Source - # Metal Jet X-ray - - # separate base classes for different sources: - # (NXacoustic_source): # needs to be developed - # doc: | - # Acoustic source, e.g. an ultrasonic transducero or a imploding gas - # bubble (sonoluminescence). - # (NXpower_supply): # needs to be developed - # (NXchem_source): # input for experts from that field needed - # (NXbio_source): # input for experts from that field needed - # is NXsource sufficient for x-rays? - # (NXopt_source): - # doc: Specify the properties of the optical source. - lifespan(NX_NUMBER): - unit: NX_TIME - doc: | - Lifespan of the excitation (typically provided in hours). - measure_time(NX_NUMBER): - unit: NX_TIME - doc: | - How many hours has the lamp been used? - excitation_wavelength(NX_FLOAT): - unit: NX_ANY - doc: | - Wavelengths or energy vector of the excitation source. This can be a - single value or a spectrum, depending on the type of experiment. - \@units: - doc: | - Unit of wavelength or energy. - beam_profile: - - # ??? What's the best way to enter this ??? - doc: | - Two- or three-dimensional beam profile. - dimensions: - rank: 2 - dim: [[1, N_beam_profile_dim], [2, N_beam_profile_points]] - peak_power(NX_FLOAT): - unit: NX_POWER - doc: | - Power of one light pulse if the source is a pulsed source. - cw(NX_BOOLEAN): - doc: | - Is the excitation source continuous wave (CW)? - cw_power(NX_FLOAT): - doc: | - Power of CW beam. - bandwidth(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - FWHM bandwidth of the excitation source. - coherence_length(NX_FLOAT): - unit: NX_LENGTH - doc: | - Coherence length. - divergence(NX_FLOAT): - unit: NX_ANGLE - doc: | - Divergence of the excitation beam. - (NXpinhole): - doc: | - Use this field to describe a simple pinhole (round geometry). Define its - dimension using 'diameter'. For more complex geometries, 'NXaperture' - should be used. - (NXslit): - doc: | - Use this field to describe a simple slit (rectangular geometry). Define - its dimensions using 'x_gap' and 'y_gap'. For more complex geometries, - 'NXaperture' should be used. - aperture_NUMBER(NXaperture): - doc: | - Use this field to describe an aperture. To specify a window, use the - field 'window_NUMBER(NXaperture)'. - window_NUMBER(NXaperture): - doc: | - A window, e.g. an entry or exit window of a cryostat. - depends_on: - doc: | - Use this field to point to the previous optical element. - material(NX_CHAR): - doc: | - The material of the window. - enumeration: [quartz, diamond, calcium fluoride, zinc selenide, thallium bromoiodide, alkali halide compound, Mylar, other] - other_material(NX_CHAR): - doc: | - If you specified 'other' as material, decsribe here what it is. - thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - Thickness of the window - orientation_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Angle of the window normal (outer) vs. the substrate normal - (similar to the angle of incidence). - reference_data_link: - doc: | - If reference data were measured add a link to the NeXus file where they - are described. - (NXmirror): - filter_NUMBER(NXfilter): - (NXattenuator): - doc: | - A device that reduces the intensity of a beam by attenuation. - attenuator_transmission(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - The transmitted intensity divided by the incident intensity. - attenuation(NX_FLOAT): - unit: NX_ANY - doc: | - Attenuation of the attenuator in dB. - \@units: - doc: | - Unit of the measured data is not covered by NXDL units state - here which unit was used. - (NXaperture): - doc: | - Input and output aperture of the attenuator. - (NXgeometry): - doc: | - Geometry (shape, size etc.) of the attenuator. - (NXgrating): - doc: | - A diffraction grating. Define relevant parameters in the corresponding - fields, e.g. order of diffration (diffraction_order) or angular - dispersion (angular_dispersion). - type: - doc: | - Define the type of the grating. - angular_dispersion(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Dispersion of the grating in nm/mm (or e.g. nm/mrad). - grooves(NX_FLOAT): - unit: NX_PER_LENGTH - doc: | - Number of grooves per mm. - blaze_wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - Blaze wavelength of the grating. - efficiency(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Efficiency curve versus wavelength or energy. - dimensions: - rank: 1 - dim: [[1, N_spectrum]] - spectrum(NX_FLOAT): - unit: NX_ANY - doc: | - Spectral values, e.g. wavelength or energy. Vector of length - N_spectrum. - \@units: - doc: | - Unit of wavelength array (e.g. nanometer or Angstrom) - (NXdisk_chopper): - doc: | - A device blocking the beam in a temporal periodic pattern, e.g. a optical - chopper wheel. Specify the frequency range using 'min_frequency' and - 'max_frequency'. - min_frequency(NX_FLOAT): - unit: NX_FREQUENCY - doc: | - Minimum frequency in Hertz. - max_frequency(NX_FLOAT): - unit: NX_FREQUENCY - doc: | - Maximum frequency in Hertz. - frequency_resolution(NX_FLOAT): - unit: NX_FREQUENCY - doc: | - Frequency resolution in Hertz. - (NXmonochromator): - doc: | - A monochromator or spectrometer. - spectrum(NX_FLOAT): - unit: NX_ANY - doc: | - Spectral values of the monochromator, e.g. wavelength or energy values - used for the measurement. - \@units: - doc: | - Unit of wavelength array (e.g. nanometer or Angstrom) - (NXgrating): - doc: | - Diffraction grating. If two or more gratings were used, define the - angular dispersion and the wavelength range (min/max wavelength) for - each grating and make sure that the wavelength ranges do not overlap. - The dispersion should be defined for the entire wavelength range of the - experiment. - angular_dispersion(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Dispersion of the grating in nm/mm. - grating_wavelength_min(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - Minimum wavelength of the grating. - grating_wavelength_max(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - Maximum wavelength of the grating. - spectral_resolution(NX_FLOAT): - unit: NX_WAVENUMBER - doc: | - Spectral resolution of the instrument. - (NXslit): - doc: | - Define the width of the monochromator slit in the subfield x_gap. - fixed_slit(NX_BOOLEAN): - doc: | - Was the slit width fixed? - max_gap(NX_FLOAT): - unit: NX_LENGTH - doc: | - If slit width was not fixed, define the maximum slit width. - - # x-ray optics: - (NXxraylens): - - # what else? - - # ====== New base classes: ====== - (NXpolarizer_opt): - (NXbeam_splitter): - (NXwaveplate): - (NXlens_opt): - (NXfiber): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 0b40f84f18c8bc51a531cc03107424f093dcc0502a98f3fff220df30e4d9de29 -# -# -# -# -# -# -# -# A beam path consisting of one or more optical elements. -# -# NXbeam_path is used in NXopt to describe the beam path, i.e. the arrangement -# of optical elements between the excitation source and the sample, or between -# the sample and the detector unit. -# -# To describe the order of the elements, use 'order(NXtransformations)', where -# each element's position points to the preceding element via '@depends_on'. -# Special case beam splitter: A beam splitter is a device which separates the -# beam into two or more beams. If such a device is part of the beam path use -# two or more NXbeam_paths to describe the beam paths after the beam splitter. -# In this case, in the dependency chain of the new beam paths, the first -# elements each point to the beam splitter, as this is the previous element. -# -# Describe the relevant optical elements in the beam path by using the -# appropriate base classes. You may use as many elements as needed, also -# several elements of the same type as long as each element has its own name. -# -# -# -# Entry point of the dependency chain defined by the NXtransformations -# field, i.e. a link to the last element in the beam path. -# Example: /entry/instrument/beam_path/detector. -# -# -# -# -# -# Specify the order of the optical elements by defining a dependency chain. -# For each element, a '@depends_on' attribute should be used to state the -# position of the element in the beam path by pointing to the previous -# element. For the very first element, use the string "." instead. -# -# -# -# For each element in the beam path, one such field must exist with a -# '@depends_on' attribute defined to specify its position in the beam -# path. Note that also 'NXopt/ENTRY/INSTRUMENT/sample_stage' and windows -# ('NXopt/ENTRY/INSTRUMENT/sample_stage/entry_window' and -# 'NXopt/ENTRY/INSTRUMENT/sample_stage/exit_window') may be added to the -# dependency chain, i.e. may have an entry in this class even if they are -# not described in the beam path. -# ELEMENT is a place holder for the name of an optical beam path element. -# Note that the name of this field must be exactly the same as the -# element's field name. -# -# -# -# Add a link to the previous beam path element. -# -# -# -# -# -# -# Excitation source. One or more may be needed (e.g. two for a pump-probe -# setup with one pump and one probe beam). -# Depending on the source type, different properties are relevant, which -# are provided through the respective base class (e.g. use NXopt_source for -# lamps or lasers, NXchem_source for chemical reaction etc.). -# Some base classes are incomplete (NXchem_source, NXbio_source); the -# expertise of the respective communities is needed. -# -# -# -# Use this field to point to the previous optical element. -# -# -# -# -# Type of excitation source. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Lifespan of the excitation (typically provided in hours). -# -# -# -# -# How many hours has the lamp been used? -# -# -# -# -# Wavelengths or energy vector of the excitation source. This can be a -# single value or a spectrum, depending on the type of experiment. -# -# -# -# Unit of wavelength or energy. -# -# -# -# -# -# -# Two- or three-dimensional beam profile. -# -# -# -# -# -# -# -# -# Power of one light pulse if the source is a pulsed source. -# -# -# -# -# Is the excitation source continuous wave (CW)? -# -# -# -# -# Power of CW beam. -# -# -# -# -# FWHM bandwidth of the excitation source. -# -# -# -# -# Coherence length. -# -# -# -# -# Divergence of the excitation beam. -# -# -# -# -# -# Use this field to describe a simple pinhole (round geometry). Define its -# dimension using 'diameter'. For more complex geometries, 'NXaperture' -# should be used. -# -# -# -# -# Use this field to describe a simple slit (rectangular geometry). Define -# its dimensions using 'x_gap' and 'y_gap'. For more complex geometries, -# 'NXaperture' should be used. -# -# -# -# -# Use this field to describe an aperture. To specify a window, use the -# field 'window_NUMBER(NXaperture)'. -# -# -# -# -# A window, e.g. an entry or exit window of a cryostat. -# -# -# -# Use this field to point to the previous optical element. -# -# -# -# -# The material of the window. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If you specified 'other' as material, decsribe here what it is. -# -# -# -# -# Thickness of the window -# -# -# -# -# Angle of the window normal (outer) vs. the substrate normal -# (similar to the angle of incidence). -# -# -# -# -# If reference data were measured add a link to the NeXus file where they -# are described. -# -# -# -# -# -# -# -# A device that reduces the intensity of a beam by attenuation. -# -# -# -# The transmitted intensity divided by the incident intensity. -# -# -# -# -# Attenuation of the attenuator in dB. -# -# -# -# Unit of the measured data is not covered by NXDL units state -# here which unit was used. -# -# -# -# -# -# Input and output aperture of the attenuator. -# -# -# -# -# Geometry (shape, size etc.) of the attenuator. -# -# -# -# -# -# A diffraction grating. Define relevant parameters in the corresponding -# fields, e.g. order of diffration (diffraction_order) or angular -# dispersion (angular_dispersion). -# -# -# -# Define the type of the grating. -# -# -# -# -# Dispersion of the grating in nm/mm (or e.g. nm/mrad). -# -# -# -# -# Number of grooves per mm. -# -# -# -# -# Blaze wavelength of the grating. -# -# -# -# -# Efficiency curve versus wavelength or energy. -# -# -# -# -# -# -# -# Spectral values, e.g. wavelength or energy. Vector of length -# N_spectrum. -# -# -# -# Unit of wavelength array (e.g. nanometer or Angstrom) -# -# -# -# -# -# -# A device blocking the beam in a temporal periodic pattern, e.g. a optical -# chopper wheel. Specify the frequency range using 'min_frequency' and -# 'max_frequency'. -# -# -# -# Minimum frequency in Hertz. -# -# -# -# -# Maximum frequency in Hertz. -# -# -# -# -# Frequency resolution in Hertz. -# -# -# -# -# -# A monochromator or spectrometer. -# -# -# -# Spectral values of the monochromator, e.g. wavelength or energy values -# used for the measurement. -# -# -# -# Unit of wavelength array (e.g. nanometer or Angstrom) -# -# -# -# -# -# Diffraction grating. If two or more gratings were used, define the -# angular dispersion and the wavelength range (min/max wavelength) for -# each grating and make sure that the wavelength ranges do not overlap. -# The dispersion should be defined for the entire wavelength range of the -# experiment. -# -# -# -# Dispersion of the grating in nm/mm. -# -# -# -# -# Minimum wavelength of the grating. -# -# -# -# -# Maximum wavelength of the grating. -# -# -# -# -# -# Spectral resolution of the instrument. -# -# -# -# -# Define the width of the monochromator slit in the subfield x_gap. -# -# -# -# Was the slit width fixed? -# -# -# -# -# If slit width was not fixed, define the maximum slit width. -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXbeam_splitter.yaml b/contributed_definitions/nyaml/NXbeam_splitter.yaml deleted file mode 100644 index d3e41496e7..0000000000 --- a/contributed_definitions/nyaml/NXbeam_splitter.yaml +++ /dev/null @@ -1,637 +0,0 @@ -category: base -doc: | - A beam splitter, i.e. a device splitting the light into two or more beams. - - Information about types and properties of beam splitters is provided e.g. - [here](https://www.rp-photonics.com/beam_splitters.html). - - Use two or more NXbeam_paths to describe the beam paths after the beam - splitter. In the dependency chain of the new beam paths, the first elements - each point to this beam splitter, as this is the previous element. -symbols: - N_spectrum: | - Length of the spectrum vector (e.g. wavelength or energy) for which the - refractive index of the beam splitter material and/or coating is defined. - N_spectrum_RT: | - Length of the spectrum vector (e.g. wavelength or energy) for which the - reflectance or transmission of the beam splitter is given. - N_shapepar: | - Number of parameters needed do descripe the shape of the beam splitter. - N_objects: | - Number of objects the beam splitter is made up of. - N_outputs: | - Number of outputs, i.e. number of paths the beam takes after being split by - the beam splitter. - -# A draft of a new base class to describe a beam splitting device. -type: group -NXbeam_splitter(NXobject): - type: - doc: | - Specify the beam splitter type (e.g. dielectric mirror, pellicle, - dichroic mirror etc.). Shape (e.g. prism, plate, cube) and dimension - should be described in 'geometry'. Define if the beam splitter is - polarizing or not in the field 'polarizing(NX_BOOLEAN)'. - enumeration: [dichroic mirror, dielectric mirror, metal-coated mirror, Nicol prism, Glan-Thompson prism, pellicle mirror, Polka dot beam splitter, fiber optic splitter, other] - - # ??? Are there any other common types of beam splitters ??? - other_type: - doc: | - If you selected 'other' in 'type' use this field to specify which type of - beam splitter was used. - polarizing(NX_BOOLEAN): - doc: | - Is the beam splitter polarizing? - multiple_outputs(NX_BOOLEAN): - - # ??? Redundant because number of outputs is defined by N_outputs ??? - doc: | - Does the beam splitter have multiple outputs (diffractive optical - element), i.e. more than two outputs? - (NXshape): - exists: recommended - doc: | - Describe the geometry (shape, dimension etc.) of the beam splitter. - Specify the dimensions in 'SHAPE/size'. A sketch of the device should be - provided in the 'sketch(NXdata)' field to clarify (i) the shape and - dimensions of the device, and (ii) the input and outputs (i.e. the - direction of the incoming and outcoming (split) beams). - - # Specify the length and height if the surface facing the incident - # beam is a square or rectangle. Otherwise, if the device has a round - # geometry (disc), sepcify the diameter instead. - # The thickness or depth of the device should be defined in 'depth', - # while the thickness of the substrate and coating should be specified - # in 'substrate/substrate_thickness' and 'coating/coating_thickness'. - shape: - doc: | - Describe the shape (plate, cube, wedged, prism etc.). - enumeration: [cube, cylinder, plate, prism, wedged, other] - other_shape: - doc: | - If you chose 'other' in 'shape' describe what it is. - sketch(NXdata): - doc: | - Sketch of the beam splitter showing its geometry. The paths of the - incoming and split beam should be illustrated and labelled (0 for the - incoming beam, and 1, 2,..., N_outputs for the outputs (i.e. the split - beam paths)). - size: - doc: | - Physical extent of the beam splitter device. The beam splitter might be - made up of one or more objects (NX_objects). The meaning and location - of the axes used will vary according to the value of the 'shape' - variable. 'N_shapepar' defines how many parameters: - - * For 'cube' the parameters are (width, length). - * For 'cylinder' the parameters are (diameter, length). - * For 'plate' the parameters are (width, height, length). - * For 'prism' the parameters are (width, height, length). - * For 'wedged' the parameters are (width, height, shortest length). - The wedge angle should be provided in 'SHAPE/wedge_angle'. - * For 'other' the parameters may be (A, B, C, ...) with the labels - defined in the sketch plotted in 'SHAPE/sketch'. - dimensions: - rank: 2 - dim: [[1, N_objects], [2, N_shapepar]] - wedge_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Wedge angle if 'shape' is 'wedged'. - - # width, height, diameter, depth: Should we use 'size' in NXshape instead? - # width(NX_FLOAT): - # doc: | - # Width of the device's surface facing the incident beam if the surface - # is square or rectangular (e.g. is shape is a cube). - # unit: NX_LENGTH - # height(NX_FLOAT): - # doc: | - # Height of the device's surface facing the incident beam if the surface - # is square or rectangular (e.g. is shape is a cube). - # unit: NX_LENGTH - # diameter(NX_FLOAT): - # doc: | - # Diameter of the device's surface facing the incident beam if the - # surface has circular geometry (e.g. is shape is a cylinder). - # unit: NX_LENGTH - # length(NX_FLOAT): - # doc: | - # Specify the length of the beam splitter. If the device has a wedged - # shape provide the minimum and maximum length of the device. - # Otherwise, if the beam splitter has a homogeneous thickness, the two - # values are equal. - # dimensions: - # rank: 1 - # dim: [[1,2]] - splitting_ratio(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Beam splitting ratio(s) for the various outputs (i.e. the - paths of the beam after being split by the beam splitter). - The order of the ratios must be consistent with the labels - 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting with 1. - dimensions: - rank: 1 - dim: [[1, N_outputs]] - clear_aperture(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Clear aperture of the device (e.g. 90% of diameter for a disc, or 90% of - length and height for square geometry). - - # ??? Would it be better to provide the clear aperture as length ??? - substrate(NXsample): - doc: | - Substrate of the beam splitter. Describe the material of the substrate in - substrate/substrate_material and provide its index of refraction in - substrate/index_of_refraction_substrate, if known. - substrate_material: - doc: | - Specify the material of the beam splitter. If the device has a coating - it should be described in coating/coating_material. Is the material - birefringent? - substrate_thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - Thickness of the beam splitter substrate. Define the minimum and - maximum thickness (for a wedged geomtry). For a homogeneous thickness - (e.g. as in plate beam splitters) the minimum and maximum values are - equal. - dimensions: - rank: 1 - dim: [[1, 2]] - index_of_refration_substrate(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Complex index of refraction of the beam splitter substrate. Specify at - given spectral values (e.g. wavelength, energy, wavenumber etc.). - dimensions: - rank: 2 - dim: [[1, 2], [2, N_spectrum]] - coating(NXsample): - doc: | - Is the beam splitter coated? If yes, specify the type and material of the - coating and the spectral range for which it is designed. If known, you - may also provide its index of refraction. For a beam splitter cube - consisting of two prisms which are glued together, you may want to - specify the the glue and the coatings of each prism. - coating_type: - doc: | - Specify the coating type (e.g. dielectric, anti-reflection (AR), - multilayer coating etc.). - coating_material: - doc: | - Specify the coating material. - coating_thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - Thickness of the coating. - wavelength_range_coating(NX_FLOAT): - exists: recommended - unit: NX_WAVELENGTH - doc: | - Wavelength range for which the coating is designed. Enter the minimum - and maximum values of the wavelength range. - dimensions: - rank: 1 - dim: [[1, 2]] - index_of_refraction_coating(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Complex index of refraction of the coating. Specify at given spectral - values (e.g. wavelength, energy, wavenumber etc.). - dimensions: - rank: 2 - dim: [[1, 2], [2, N_spectrum]] - wavelength_range(NX_FLOAT): - exists: recommended - unit: NX_WAVELENGTH - doc: | - Wavelength range for which the beam splitter is designed. Enter the - minimum and maximum values of the wavelength range. Alternatively, or - additionally, you may define the wavelength range for the coating in - coating/wavelength_range_coating. - dimensions: - rank: 1 - dim: [[1, 2]] - optical_loss(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Optical loss of the beam splitter for the various outputs (i.e. the paths - of the beam after being split by the beam splitter). - The order of the ratios must be consistent with the labels - 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting - with 1. - dimensions: - rank: 1 - dim: [[1, N_outputs]] - incident_angle(NX_NUMBER): - unit: NX_ANGLE - doc: | - Optimized angle of incidence for the desired splitting ratio. - deflection_angle(NX_NUMBER): - unit: NX_ANGLE - - # is this really needed? - doc: | - Angle of deflection corresponding to the optimized angle of incidence - defined in incident_angle. - AOI_range(NX_NUMBER): - unit: NX_ANGLE - doc: | - Range of the angles of incidence (AOI) for which the beam splitter can be - operated. Specify the minimum and maximum angles of the range. - dimensions: - rank: 1 - dim: [[1, 2]] - - # Aren't some beamsplitters defined for specific angles? Should we instead - # use dim: [[1,N_angles]], N_angles being the number of angles for which the - # beam splitter can be operated? - # If this is the case for some devices, we might also have to define a field - # for the corresponding defelction angles... - reflectance(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Reflectance of the beam splitter at given spectral values. - dimensions: - rank: 1 - dim: [[1, N_spectrum_RT]] - transmission(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Transmission at given spectral values for the various outputs (i.e. the - paths of the beam after being split by the beam splitter). - The order of the ratios must be consistent with the labels - 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting - with 1. - dimensions: - rank: 2 - dim: [[1, N_outputs], [2, N_spectrum_RT]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4213dd382261e419436da1a94ae6c7dcfec45145bfba6f184cf8205d6952586a -# -# -# -# -# -# -# -# -# Length of the spectrum vector (e.g. wavelength or energy) for which the -# refractive index of the beam splitter material and/or coating is defined. -# -# -# -# -# Length of the spectrum vector (e.g. wavelength or energy) for which the -# reflectance or transmission of the beam splitter is given. -# -# -# -# -# Number of parameters needed do descripe the shape of the beam splitter. -# -# -# -# -# Number of objects the beam splitter is made up of. -# -# -# -# -# Number of outputs, i.e. number of paths the beam takes after being split by -# the beam splitter. -# -# -# -# -# A beam splitter, i.e. a device splitting the light into two or more beams. -# -# Information about types and properties of beam splitters is provided e.g. -# [here](https://www.rp-photonics.com/beam_splitters.html). -# -# Use two or more NXbeam_paths to describe the beam paths after the beam -# splitter. In the dependency chain of the new beam paths, the first elements -# each point to this beam splitter, as this is the previous element. -# -# -# -# Specify the beam splitter type (e.g. dielectric mirror, pellicle, -# dichroic mirror etc.). Shape (e.g. prism, plate, cube) and dimension -# should be described in 'geometry'. Define if the beam splitter is -# polarizing or not in the field 'polarizing(NX_BOOLEAN)'. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If you selected 'other' in 'type' use this field to specify which type of -# beam splitter was used. -# -# -# -# -# Is the beam splitter polarizing? -# -# -# -# -# -# Does the beam splitter have multiple outputs (diffractive optical -# element), i.e. more than two outputs? -# -# -# -# -# Describe the geometry (shape, dimension etc.) of the beam splitter. -# Specify the dimensions in 'SHAPE/size'. A sketch of the device should be -# provided in the 'sketch(NXdata)' field to clarify (i) the shape and -# dimensions of the device, and (ii) the input and outputs (i.e. the -# direction of the incoming and outcoming (split) beams). -# -# -# -# -# Describe the shape (plate, cube, wedged, prism etc.). -# -# -# -# -# -# -# -# -# -# -# -# -# If you chose 'other' in 'shape' describe what it is. -# -# -# -# -# Sketch of the beam splitter showing its geometry. The paths of the -# incoming and split beam should be illustrated and labelled (0 for the -# incoming beam, and 1, 2,..., N_outputs for the outputs (i.e. the split -# beam paths)). -# -# -# -# -# Physical extent of the beam splitter device. The beam splitter might be -# made up of one or more objects (NX_objects). The meaning and location -# of the axes used will vary according to the value of the 'shape' -# variable. 'N_shapepar' defines how many parameters: -# -# * For 'cube' the parameters are (width, length). -# * For 'cylinder' the parameters are (diameter, length). -# * For 'plate' the parameters are (width, height, length). -# * For 'prism' the parameters are (width, height, length). -# * For 'wedged' the parameters are (width, height, shortest length). -# The wedge angle should be provided in 'SHAPE/wedge_angle'. -# * For 'other' the parameters may be (A, B, C, ...) with the labels -# defined in the sketch plotted in 'SHAPE/sketch'. -# -# -# -# -# -# -# -# -# Wedge angle if 'shape' is 'wedged'. -# -# -# -# -# -# -# Beam splitting ratio(s) for the various outputs (i.e. the -# paths of the beam after being split by the beam splitter). -# The order of the ratios must be consistent with the labels -# 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting with 1. -# -# -# -# -# -# -# -# Clear aperture of the device (e.g. 90% of diameter for a disc, or 90% of -# length and height for square geometry). -# -# -# -# -# -# Substrate of the beam splitter. Describe the material of the substrate in -# substrate/substrate_material and provide its index of refraction in -# substrate/index_of_refraction_substrate, if known. -# -# -# -# Specify the material of the beam splitter. If the device has a coating -# it should be described in coating/coating_material. Is the material -# birefringent? -# -# -# -# -# Thickness of the beam splitter substrate. Define the minimum and -# maximum thickness (for a wedged geomtry). For a homogeneous thickness -# (e.g. as in plate beam splitters) the minimum and maximum values are -# equal. -# -# -# -# -# -# -# -# Complex index of refraction of the beam splitter substrate. Specify at -# given spectral values (e.g. wavelength, energy, wavenumber etc.). -# -# -# -# -# -# -# -# -# -# Is the beam splitter coated? If yes, specify the type and material of the -# coating and the spectral range for which it is designed. If known, you -# may also provide its index of refraction. For a beam splitter cube -# consisting of two prisms which are glued together, you may want to -# specify the the glue and the coatings of each prism. -# -# -# -# Specify the coating type (e.g. dielectric, anti-reflection (AR), -# multilayer coating etc.). -# -# -# -# -# Specify the coating material. -# -# -# -# -# Thickness of the coating. -# -# -# -# -# Wavelength range for which the coating is designed. Enter the minimum -# and maximum values of the wavelength range. -# -# -# -# -# -# -# -# Complex index of refraction of the coating. Specify at given spectral -# values (e.g. wavelength, energy, wavenumber etc.). -# -# -# -# -# -# -# -# -# -# Wavelength range for which the beam splitter is designed. Enter the -# minimum and maximum values of the wavelength range. Alternatively, or -# additionally, you may define the wavelength range for the coating in -# coating/wavelength_range_coating. -# -# -# -# -# -# -# -# Optical loss of the beam splitter for the various outputs (i.e. the paths -# of the beam after being split by the beam splitter). -# The order of the ratios must be consistent with the labels -# 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting -# with 1. -# -# -# -# -# -# -# -# Optimized angle of incidence for the desired splitting ratio. -# -# -# -# -# -# Angle of deflection corresponding to the optimized angle of incidence -# defined in incident_angle. -# -# -# -# -# Range of the angles of incidence (AOI) for which the beam splitter can be -# operated. Specify the minimum and maximum angles of the range. -# -# -# -# -# -# -# -# -# Reflectance of the beam splitter at given spectral values. -# -# -# -# -# -# -# -# Transmission at given spectral values for the various outputs (i.e. the -# paths of the beam after being split by the beam splitter). -# The order of the ratios must be consistent with the labels -# 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting -# with 1. -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXbias_spectroscopy.yaml b/contributed_definitions/nyaml/NXbias_spectroscopy.yaml deleted file mode 100644 index 98d8007058..0000000000 --- a/contributed_definitions/nyaml/NXbias_spectroscopy.yaml +++ /dev/null @@ -1,282 +0,0 @@ -category: base -doc: | - Base classes definition for bias spectroscopy. - - Bias sweeps while measuring arbitrary channels with I(V) curves. -type: group -NXbias_spectroscopy(NXobject): - channels: - doc: | - Select the channels to record. - reset_bias(NX_BOOLEAN): - doc: | - If chosen, the Bias voltage resets to its initial value (before the sweep initiation) at - the conclusion of the spectroscopy measurement. When this option is not selected, the Bias - voltage maintains the last value acquired during the sweep. This functionality proves - beneficial, especially when combining multiple sweep segments. As an illustration of an - automated measurement: turn off the z-Controller, commence spectroscopy sweep segments ( - forward sweep only, without resetting the bias), restore the bias to its initial value, - and then turn on the z-Controller. - record_final_z(NX_BOOLEAN): - doc: | - Select whether to record the Z position during Z averaging time at the end of - the sweep (after Z control time) and store the average value in the header of - the file when saving. Using this option increases the sweep time by Z averaging - time. - lock_in_run(NX_BOOLEAN): - doc: | - Select whether to set the Lock-In to run during the measurement. When using this - feature, make sure the Lock-In is configured correctly and settling times are - set to twice the Lock-In period at least. This option is ignored when Lock-In is - already running. This option is disabled if the Sweep Mode is MLS and the flag - to configure the Lock-In per segment in the Multiline segment editor is set. - integration_time(NX_NUMBER): - unit: NX_TIME - doc: | - Time during which the spectroscopy data are acquired and averaged. - number_of_sweeps(NX_NUMBER): - doc: | - Number of sweeps to measure and average. - sweep_start(NX_NUMBER): - unit: NX_VOLTAGE - doc: | - The first bias values of the sweep. - sweep_end(NX_NUMBER): - unit: NX_VOLTAGE - doc: | - The last bias values of the sweep. - num_pixel(NX_NUMBER): - doc: | - Define the sweep number of points, that is, the maximum spectrum resolution eq. - Bias window divide by Num Pixel. - z_avg_time(NX_NUMBER): - unit: NX_TIME - doc: | - Duration over which the Z position is recorded and averaged before and after the - sweep (the latter only if Record final Z position is selected in the Advanced - section). After the initial z averaging time, if Z-Controller to Hold is - selected in the Advanced section, the z-Controller is set to hold and the tip is - placed at the previously averaged z position (plus z offset). - sw_filter_type(NX_CHAR): - doc: | - Select a filter to smooth the displayed data. When saving, if any filter is selected, - filtered data are saved to file along with the unfiltered data. - sw_filter_order(NX_NUMBER): - doc: | - Filter order of a dynamic filter or width (in number of points) for the Gaussian - filter. - sw_filter_cutoff_frq(NX_NUMBER): - doc: | - Cutoff frequency for dynamic filters. - z_offset(NX_NUMBER): - unit: NX_LENGTH - doc: | - Offset added to the initial averaged position Zaver before starting to sweep. - This parameter is disabled when Z-Controller to Hold is deselected in the - Advanced section. The LED “Alt” next to the Z offset indicates if an alternate - Z-controller setpoint is enabled. - settling_time(NX_NUMBER): - unit: NX_TIME - doc: | - Time to wait after changing the bias to the next level and before - starting to acquire data. - first_settling_time(NX_NUMBER): - doc: | - No doc yet. - end_settling_time(NX_NUMBER): - unit: NX_TIME - doc: | - Time to wait after the sweep has finished and the bias is ramped to - the initial value. - z_control_time(NX_NUMBER): - unit: NX_TIME - doc: | - Time during which the Z-Controller is enabled once a sweep has finished. - When averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled - for this duration between each sweep. After the last sweep, it will wait the - specified time before continuing a running scan. This ensures each sweep - reliably starts from the same position. This parameter is disabled when - Z-Controller to Hold is deselected in the Advanced section. - max_slew_rate(NX_NUMBER): - doc: | - Maximum rate at which the bias changes (before, during and after sweeping). - (V/s) - backward_sweep(NX_BOOLEAN): - doc: | - Select whether to measure the backward (return) sweep or the forward only. - z_ccontroller_hold(NX_BOOLEAN): - doc: | - Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. - It is selected by default. When deselected, Z-offset and Z control time parameters - are disabled. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 49c9177d438f869e26204da8b11b2075834bc253f2e9578f1f66bfa20be23db9 -# -# -# -# -# -# Base classes definition for bias spectroscopy. -# -# Bias sweeps while measuring arbitrary channels with I(V) curves. -# -# -# -# Select the channels to record. -# -# -# -# -# If chosen, the Bias voltage resets to its initial value (before the sweep initiation) at -# the conclusion of the spectroscopy measurement. When this option is not selected, the Bias -# voltage maintains the last value acquired during the sweep. This functionality proves -# beneficial, especially when combining multiple sweep segments. As an illustration of an -# automated measurement: turn off the z-Controller, commence spectroscopy sweep segments ( -# forward sweep only, without resetting the bias), restore the bias to its initial value, -# and then turn on the z-Controller. -# -# -# -# -# Select whether to record the Z position during Z averaging time at the end of -# the sweep (after Z control time) and store the average value in the header of -# the file when saving. Using this option increases the sweep time by Z averaging -# time. -# -# -# -# -# Select whether to set the Lock-In to run during the measurement. When using this -# feature, make sure the Lock-In is configured correctly and settling times are -# set to twice the Lock-In period at least. This option is ignored when Lock-In is -# already running. This option is disabled if the Sweep Mode is MLS and the flag -# to configure the Lock-In per segment in the Multiline segment editor is set. -# -# -# -# -# Time during which the spectroscopy data are acquired and averaged. -# -# -# -# -# Number of sweeps to measure and average. -# -# -# -# -# The first bias values of the sweep. -# -# -# -# -# The last bias values of the sweep. -# -# -# -# -# Define the sweep number of points, that is, the maximum spectrum resolution eq. -# Bias window divide by Num Pixel. -# -# -# -# -# Duration over which the Z position is recorded and averaged before and after the -# sweep (the latter only if Record final Z position is selected in the Advanced -# section). After the initial z averaging time, if Z-Controller to Hold is -# selected in the Advanced section, the z-Controller is set to hold and the tip is -# placed at the previously averaged z position (plus z offset). -# -# -# -# -# Select a filter to smooth the displayed data. When saving, if any filter is selected, -# filtered data are saved to file along with the unfiltered data. -# -# -# -# -# Filter order of a dynamic filter or width (in number of points) for the Gaussian -# filter. -# -# -# -# -# Cutoff frequency for dynamic filters. -# -# -# -# -# Offset added to the initial averaged position Zaver before starting to sweep. -# This parameter is disabled when Z-Controller to Hold is deselected in the -# Advanced section. The LED “Alt” next to the Z offset indicates if an alternate -# Z-controller setpoint is enabled. -# -# -# -# -# Time to wait after changing the bias to the next level and before -# starting to acquire data. -# -# -# -# -# No doc yet. -# -# -# -# -# Time to wait after the sweep has finished and the bias is ramped to -# the initial value. -# -# -# -# -# Time during which the Z-Controller is enabled once a sweep has finished. -# When averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled -# for this duration between each sweep. After the last sweep, it will wait the -# specified time before continuing a running scan. This ensures each sweep -# reliably starts from the same position. This parameter is disabled when -# Z-Controller to Hold is deselected in the Advanced section. -# -# -# -# -# Maximum rate at which the bias changes (before, during and after sweeping). -# (V/s) -# -# -# -# -# Select whether to measure the backward (return) sweep or the forward only. -# -# -# -# -# Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. -# It is selected by default. When deselected, Z-offset and Z control time parameters -# are disabled. -# -# -# diff --git a/contributed_definitions/nyaml/NXcontainer.yaml b/contributed_definitions/nyaml/NXcontainer.yaml deleted file mode 100644 index f84ccd7889..0000000000 --- a/contributed_definitions/nyaml/NXcontainer.yaml +++ /dev/null @@ -1,294 +0,0 @@ -category: base -doc: | - State of a container holding the sample under investigation. - - A container is any object in the beam path which absorbs the beam and - whose contribution to the overall attenuation/scattering needs to be - determined to process the experimental data. Examples of containers - include glass capillary tubes, vanadium cans, windows in furnaces or - diamonds in a Diamond Anvil Cell. The following figures show a complex - example of a container: - - .. figure:: container/ComplexExampleContainer.png - - A hypothetical capillary furnace. The beam passes from left to right - (blue dashes), passing through window 1, then window 2, before - passing through the downstream wall of the capillary. It is then - scattered by the sample with scattered beams passing through the - upstream wall of the capillary, then windows 4 and 5. As part of the - corrections for a PDF experiment it is necessary to subtract the PDF - of the empty container (i.e. each of the windows and the capillary). - To calculate the PDF of the empty container it is necessary to have - the measured scattering data and to know the nature (e.g. density, - elemental composition, etc.) of the portion of the container which - the beam passed through. - - .. figure:: container/ComplexContainerBeampath.png - - A complete description of the shapes of the container elements with - their orientation relative to the beam and also information on - whether they are upstream or downstream of the sample is also - therefore important. For example, although the windows 2 and 4 have - the same shape, the path taken through them by the beam is very - different and this needs to be modelled. Furthermore, it is not - inconceivable that windows might move during an experiment and thus - the changes to the beampath would need to be accounted for. - - This class encodes the position of the container with respect to the - sample and allows the calculation of the beampath through the container. - It also includes sufficient data to model beam absorption of the - container and a link to a dataset containing a measurement of the - container with nothing inside, to allow data corrections (at a specific - beam energy/measurement time) to be made. -type: group -NXcontainer(NXobject): - name: - doc: | - Descriptive name of container. - description: - doc: | - Verbose description of container and how it fits into the wider - experimental set up. - chemical_formula: - doc: | - Chemical composition of the material the container is made from. - 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. - density(NX_FLOAT): - unit: NX_MASS_DENSITY - doc: | - Density of the material the container is made from. - dimensions: - rank: 1 - dim: [[1, n_comp]] - packing_fraction(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Fraction of the volume of the container occupied by the material - forming the container. - dimensions: - dim: [[1, n_comp]] - relative_molecular_mass(NX_FLOAT): - unit: NX_MASS - doc: | - Relative molecular mass of container. - dimensions: - rank: 1 - dim: [[1, n_comp]] - beam(NXbeam): - doc: | - Details of beam incident on container, including the position - relative to the sample (to determine whether the container is - upstream or downstream of the sample). - shape(NXshape): - doc: | - Shape of the container. In combination with orientation this - should allow the beampath through the container to be modelled to - allow the adsorption to be calculated. - orientation(NXtransformations): - doc: | - The angle the container makes to the beam and how it may change - during the experiment.In combination with shape this should allow - the beampath through the container to be modelled to allow the - adsorption of the container to be calculated. - reference_measurement(link): - target: /NXentry - doc: | - A link to a full data collection which contains the actual - measured data for this container within the experimental set up - (with no sample or inner container(s)). This data set will also - include the wavelength/energy, measurement time and intensity for - which these data are valid. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 6459188ef3db14546f3ea4825e16e5e505be56f15622c367b0fb23978ee3691e -# -# -# -# -# -# -# State of a container holding the sample under investigation. -# -# A container is any object in the beam path which absorbs the beam and -# whose contribution to the overall attenuation/scattering needs to be -# determined to process the experimental data. Examples of containers -# include glass capillary tubes, vanadium cans, windows in furnaces or -# diamonds in a Diamond Anvil Cell. The following figures show a complex -# example of a container: -# -# .. figure:: container/ComplexExampleContainer.png -# -# A hypothetical capillary furnace. The beam passes from left to right -# (blue dashes), passing through window 1, then window 2, before -# passing through the downstream wall of the capillary. It is then -# scattered by the sample with scattered beams passing through the -# upstream wall of the capillary, then windows 4 and 5. As part of the -# corrections for a PDF experiment it is necessary to subtract the PDF -# of the empty container (i.e. each of the windows and the capillary). -# To calculate the PDF of the empty container it is necessary to have -# the measured scattering data and to know the nature (e.g. density, -# elemental composition, etc.) of the portion of the container which -# the beam passed through. -# -# .. figure:: container/ComplexContainerBeampath.png -# -# A complete description of the shapes of the container elements with -# their orientation relative to the beam and also information on -# whether they are upstream or downstream of the sample is also -# therefore important. For example, although the windows 2 and 4 have -# the same shape, the path taken through them by the beam is very -# different and this needs to be modelled. Furthermore, it is not -# inconceivable that windows might move during an experiment and thus -# the changes to the beampath would need to be accounted for. -# -# This class encodes the position of the container with respect to the -# sample and allows the calculation of the beampath through the container. -# It also includes sufficient data to model beam absorption of the -# container and a link to a dataset containing a measurement of the -# container with nothing inside, to allow data corrections (at a specific -# beam energy/measurement time) to be made. -# -# -# -# Descriptive name of container. -# -# -# -# -# Verbose description of container and how it fits into the wider -# experimental set up. -# -# -# -# -# Chemical composition of the material the container is made from. -# 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. -# -# -# -# -# Density of the material the container is made from. -# -# -# -# -# -# -# -# Fraction of the volume of the container occupied by the material -# forming the container. -# -# -# -# -# -# -# Relative molecular mass of container. -# -# -# -# -# -# -# Details of beam incident on container, including the position -# relative to the sample (to determine whether the container is -# upstream or downstream of the sample). -# -# -# -# -# Shape of the container. In combination with orientation this -# should allow the beampath through the container to be modelled to -# allow the adsorption to be calculated. -# -# -# -# -# The angle the container makes to the beam and how it may change -# during the experiment.In combination with shape this should allow -# the beampath through the container to be modelled to allow the -# adsorption of the container to be calculated. -# -# -# -# -# A link to a full data collection which contains the actual -# measured data for this container within the experimental set up -# (with no sample or inner container(s)). This data set will also -# include the wavelength/energy, measurement time and intensity for -# which these data are valid. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcsg.yaml b/contributed_definitions/nyaml/NXcsg.yaml deleted file mode 100644 index b3347fce9a..0000000000 --- a/contributed_definitions/nyaml/NXcsg.yaml +++ /dev/null @@ -1,119 +0,0 @@ -category: base -doc: | - Constructive Solid Geometry base class, using :ref:`NXquadric` and :ref:`NXoff_geometry` -type: group -NXcsg(NXobject): - operation: - doc: | - One of the standard construction solid geometry set operations, - or if the CSG is a pointer to the geometry provided by an - :ref:`NXquadric` or an :ref:`NXoff_geometry`. Takes values: - enumeration: [UNION, INTERSECTION, DIFFERENCE, COMPLEMENT, IS_QUADRIC, IS_MESH] - a(NXcsg): - exists: ['min', '0', 'max', '1'] - doc: | - The first operand of constructive solid geometry - operation. Compulsory if 'operation' is UNION, INTERSECTION, - DIFFERENCE or COMPLEMENT. - b(NXcsg): - exists: ['min', '0', 'max', '1'] - doc: | - The second operand of constructive solid geometry - operation. Compulsory if 'operation' is UNION, INTERSECTION or - DIFFERENCE. - geometry(NX_CHAR): - exists: ['min', '0', 'max', '1'] - doc: | - Path to a field that is either an :ref:`NXquadric` (if - 'operation' = IS_QUADRIC) or an :ref:`NXoff_geometry` (if - 'operation' = IS_MESH) that defines the surface making up the - constructive solid geometry component. Compulsory if 'operation' - is IS_QUADRIC or IS_MESH. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 1ab0c280f8e356fd31f2171e2f7634c7ffdaeac0f8e52dac74f61fb9f9ad8031 -# -# -# -# -# -# Constructive Solid Geometry base class, using :ref:`NXquadric` and :ref:`NXoff_geometry` -# -# -# One of the standard construction solid geometry set operations, -# or if the CSG is a pointer to the geometry provided by an -# :ref:`NXquadric` or an :ref:`NXoff_geometry`. Takes values: -# -# -# -# -# -# -# -# -# -# -# -# -# The first operand of constructive solid geometry -# operation. Compulsory if 'operation' is UNION, INTERSECTION, -# DIFFERENCE or COMPLEMENT. -# -# -# -# -# The second operand of constructive solid geometry -# operation. Compulsory if 'operation' is UNION, INTERSECTION or -# DIFFERENCE. -# -# -# -# -# Path to a field that is either an :ref:`NXquadric` (if -# 'operation' = IS_QUADRIC) or an :ref:`NXoff_geometry` (if -# 'operation' = IS_MESH) that defines the surface making up the -# constructive solid geometry component. Compulsory if 'operation' -# is IS_QUADRIC or IS_MESH. -# -# -# diff --git a/contributed_definitions/nyaml/NXcxi_ptycho.yaml b/contributed_definitions/nyaml/NXcxi_ptycho.yaml deleted file mode 100644 index 09cfb11281..0000000000 --- a/contributed_definitions/nyaml/NXcxi_ptycho.yaml +++ /dev/null @@ -1,440 +0,0 @@ -category: application -doc: | - Application definition for a ptychography experiment, compatible with CXI from version 1.6. - - This is compatible with CXI from version 1.6 if this application definition - is put at the top "entry" level. Above this a "cxi_version" field should be defined. The CXI format is name based, rather than class based, and so it is important - to pay attention to the naming convention to be CXI compatible. There are duplications due to the format merger. These should be achieved by linking, - with hdf5 Virtual Dataset being used to restructure any data that needs to be remapped. To be fully CXI compatible, all units (including energy) must be in SI units. - - An example here is that CXI expects the data to always to have shape (npts_x*npts_y, frame_size_x, frame_size_y). For nexus this is only true for arbitrary scan paths - with raster format scans taking shape (npts_x, npts_y, frame_size_x, frame_size_y). -symbols: - doc: | - These symbols will be used below to coordinate the shapes of the datasets. - npts_x: | - The number of points in the x direction - npts_y: | - Number of points in the y direction. - frame_size_x: | - Number of detector pixels in x - frame_size_y: | - Number of detector pixels in y -type: group -NXcxi_ptycho(NXobject): - (NXentry)entry_1: - title: - exists: ['min', '0', 'max', '1'] - start_time(NX_DATE_TIME): - exists: ['min', '0', 'max', '1'] - end_time(NX_DATE_TIME): - exists: ['min', '0', 'max', '1'] - definition(NX_CHAR): - exists: ['min', '1', 'max', '1'] - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXcxi_ptycho] - (NXinstrument)instrument_1: - exists: ['min', '1', 'max', '1'] - (NXsource)source_1: - exists: ['min', '1', 'max', '1'] - name(NX_CHAR): - exists: ['min', '1', 'max', '1'] - energy(NX_FLOAT): - exists: ['min', '1', 'max', '1'] - doc: | - This is the energy of the machine, not the beamline. - probe(NX_FLOAT): - exists: ['min', '1', 'max', '1'] - type(NX_FLOAT): - exists: ['min', '1', 'max', '1'] - (NXbeam)beam_1: - exists: ['min', '1', 'max', '1'] - energy(NX_FLOAT): - exists: ['min', '1', 'max', '1'] - \@units: - type: NX_CHAR - exists: optional - extent(NX_FLOAT): - exists: ['min', '0', 'max', '1'] - \@units: - type: NX_CHAR - exists: optional - incident_beam_divergence(NX_FLOAT): - exists: ['min', '0', 'max', '1'] - \@units: - type: NX_CHAR - exists: optional - incident_beam_energy(NX_FLOAT): - exists: ['min', '1', 'max', '1'] - \@units: - type: NX_CHAR - exists: optional - incident_energy_spread(NX_FLOAT): - exists: ['min', '1', 'max', '1'] - \@units: - type: NX_CHAR - exists: optional - (NXdetector)detector_1: - exists: ['min', '1', 'max', '1'] - \@axes: - type: NX_CHAR - doc: | - should have value "[, data]" - \@signal: - type: NX_CHAR - doc: | - should have value "data" - (NXtransformations)transformations: - vector(NX_NUMBER): - exists: ['min', '1', 'max', '1'] - translation(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '1', 'max', '1'] - doc: | - This is an array of shape (npts_x*npts_y, 3) and can be a Virtual Dataset of x and y - \@units: - type: NX_CHAR - exists: optional - \@axes: - exists: optional - type: NX_CHAR - doc: | - this should take the value "translation:$slowaxisname:$fastaxisname" - \@interpretation: - exists: optional - type: NX_CHAR - doc: | - This should be "image" - data(NX_INT): - signal: 1 - exists: ['min', '1', 'max', '1'] - dimensions: - rank: 3 for arbitrary scan, 4 for raster - dim: [[1, npts_x], [2, npts_y], [3, frame_size_x], [4, frame_size_y]] - data_1(link): - target: /NXentry/NXinstrument/NXdetector/data - doc: | - This data must always have shape (npts_x*npts_y, frame_size_x, frame_size_y) regardless - of the scan pattern. Use hdf5 virtual dataset to achieve this. - x_pixel_size(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '1', 'max', '1'] - \@units: - type: NX_CHAR - exists: optional - y_pixel_size(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '1', 'max', '1'] - \@units: - type: NX_CHAR - exists: optional - distance(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '1', 'max', '1'] - doc: | - The distance between the detector and the sample - \@units: - type: NX_CHAR - exists: optional - beam_center_x(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - \@units: - type: NX_CHAR - exists: optional - beam_center_y(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - \@units: - type: NX_CHAR - exists: optional - (NXmonitor): - exists: ['min', '0', 'max', '1'] - data(NX_FLOAT): - dimensions: - rank: 1 for arbitrary scan, 2 for raster - dim: [[1, npts_x], [2, npts_y]] - (NXdata): - exists: ['min', '1', 'max', '1'] - \@axes: - type: NX_CHAR - exists: optional - doc: | - This should be "[x,.]" for arbitrary scanning patterns, and "[x,.,.]" for raster - \@signal: - type: NX_CHAR - exists: optional - doc: | - This should be "data" - data(link): - target: /NXentry/NXinstrument/NXdetector/data - x(link): - target: /NXentry/NXsample/NXtransformations/x - y(link): - target: /NXentry/NXsample/NXtransformations/y - x_indices(NX_CHAR): - y_indices(NX_CHAR): - (NXcollection)data_1: - exists: ['min', '1', 'max', '1'] - doc: | - To ensure CXI compatibility the data in this group must always have shape that is - (npts_x*npts_y, frame_size_x, frame_size_y). For nexus-style raster scans it is proposed that - hdf5 virtual dataset is used. - data(link): - target: /NXentry/NXinstrument/NXdetector/data - translation(link): - target: /NXentry/NXinstrument/NXdetector/translation - (NXsample)sample_1: - exists: ['min', '1', 'max', '1'] - name(NX_CHAR): - exists: ['min', '0', 'max', '1'] - transformations(NXtransformations): - doc: | - This must contain two fields with the x and y motors that are linked via the - dependency tree according to the real-life motor layout dependency. - For raster scans x and y will have shape (npts_x, npts_y) - For arbitrary scans x and y will be (npts_x*npts_y,) - An attribute with the units for each motor is required. - \@vector: - exists: optional - type: NX_NUMBER - (NXcollection)geometry_1: - exists: ['min', '1', 'max', '1'] - translation(link): - target: /NXentry/NXinstrument/NXdetector/translation - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 1721d728d2a6680f7a31ff43a8282529f86774875d6858239cafde901882d24b -# -# -# -# -# -# -# These symbols will be used below to coordinate the shapes of the datasets. -# -# -# -# -# The number of points in the x direction -# -# -# -# -# -# Number of points in the y direction. -# -# -# -# -# Number of detector pixels in x -# -# -# -# -# -# Number of detector pixels in y -# -# -# -# -# -# Application definition for a ptychography experiment, compatible with CXI from version 1.6. -# -# This is compatible with CXI from version 1.6 if this application definition -# is put at the top "entry" level. Above this a "cxi_version" field should be defined. The CXI format is name based, rather than class based, and so it is important -# to pay attention to the naming convention to be CXI compatible. There are duplications due to the format merger. These should be achieved by linking, -# with hdf5 Virtual Dataset being used to restructure any data that needs to be remapped. To be fully CXI compatible, all units (including energy) must be in SI units. -# -# An example here is that CXI expects the data to always to have shape (npts_x*npts_y, frame_size_x, frame_size_y). For nexus this is only true for arbitrary scan paths -# with raster format scans taking shape (npts_x, npts_y, frame_size_x, frame_size_y). -# -# -# -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# -# -# -# This is the energy of the machine, not the beamline. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# should have value "[, data]" -# -# -# -# -# should have value "data" -# -# -# -# -# -# -# -# This is an array of shape (npts_x*npts_y, 3) and can be a Virtual Dataset of x and y -# -# -# -# -# this should take the value "translation:$slowaxisname:$fastaxisname" -# -# -# -# -# This should be "image" -# -# -# -# -# -# -# -# -# -# -# -# -# -# This data must always have shape (npts_x*npts_y, frame_size_x, frame_size_y) regardless -# of the scan pattern. Use hdf5 virtual dataset to achieve this. -# -# -# -# -# -# -# -# -# -# -# The distance between the detector and the sample -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# This should be "[x,.]" for arbitrary scanning patterns, and "[x,.,.]" for raster -# -# -# -# -# This should be "data" -# -# -# -# -# -# -# -# -# -# -# To ensure CXI compatibility the data in this group must always have shape that is -# (npts_x*npts_y, frame_size_x, frame_size_y). For nexus-style raster scans it is proposed that -# hdf5 virtual dataset is used. -# -# -# -# -# -# -# -# -# -# This must contain two fields with the x and y motors that are linked via the -# dependency tree according to the real-life motor layout dependency. -# For raster scans x and y will have shape (npts_x, npts_y) -# For arbitrary scans x and y will be (npts_x*npts_y,) -# An attribute with the units for each motor is required. -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXdelocalization.yaml b/contributed_definitions/nyaml/NXdelocalization.yaml deleted file mode 100644 index cfac5273d3..0000000000 --- a/contributed_definitions/nyaml/NXdelocalization.yaml +++ /dev/null @@ -1,240 +0,0 @@ -category: base -doc: | - Base class of the configuration and results of a delocalization algorithm. - - Delocalization is used to distribute point-like objects on a grid to obtain - e.g. smoother count, composition, or concentration values of scalar fields - and compute gradients of these fields. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_p: | - Number of points/objects. - n_m: | - Number of mark data per point/object. - n_atoms: | - Number of atoms in the whitelist. - n_nuclides: | - Number of isotopes in the whitelist. -type: group -NXdelocalization(NXobject): - grid(NXcg_grid): - doc: | - Details about the grid on which the delocalization is applied. - - # grid(NX_CHAR): - # doc: | - # Reference or link to the grid on which the delocalization is applied. - # objects(NX_CHAR): - # doc: | - # Reference or link to the points which are delocalized on the grid. - - # for APM the speciality is nothing but: - # each point marks the location of an ion (object) in the tomographic reconstruction - # there is a boolean mask which filters which ions, i.e. points are considered - # plus there is a weight interpretation model, specifically in atom probe - # if a (molecular) ion is decomposed into its atoms or isotopes - # plus, given there is such a weight interpretation model, there is a weight - # associated, specifically an integer >= 1 with each considered ion and 0 for - # all ions which are not considered, - # this weight is the multiplicity with respect to the interpretation model - # i.e. a C:2 molecular ion has a multiplicity of 2 if the ion is considered - # and the interpretation model that to consider carbon atoms or carbon ions - weighting_model(NXmatch_filter): - doc: | - The weighting model specifies how mark data are mapped to a weight per - point/object. - weighting_method(NX_CHAR): - doc: | - As an example from the research field of atom probe points/objects are (molecular) ions. - Different methods are used for weighting ions: - - * default, points get all the same weight 1., which for atom probe is equivalent - to (molecular) iontype-based delocalization. - * element, points get as much weight as they have atoms representing a nuclide - with a proton number that is matching to a respective entry in whitelist. - In atom probe jargon, this means atomic_decomposition. - * isotope, points get as much weight as they have atoms representing a nuclides - from a respective entry in whitelist. - In atom probe jargon, this means isotope_decomposition. - enumeration: [default, element, isotope] - - # method is specialized from NXmatch_filter - method(NX_CHAR): - enumeration: [whitelist] - match(NX_UINT): - unit: NX_UNITLESS - doc: | - A list of nuclides based on which to evaluate the weight. Nuclides need to exist in the nuclide table. - Values are nuclide (isotope) hash values using the following hashing rule :math:`H = Z + N \cdot 256` - with :math:`Z` the number of protons and :math:`N` the number of neutrons of the nuclide. - For elements set :math:`N` to zero. - dimensions: - rank: 1 - dim: [[1, n_nuclides]] - mark(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Attribute data for each member of the point cloud. For APM these are the - iontypes generated via ranging. The number of mark data per point is 1 - in the case for atom probe. - dimensions: - rank: 2 - dim: [[1, n_p], [2, n_m]] - weight(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Weighting factor with which the integrated intensity per grid cell is - multiplied specifically for each point/object. For APM the weight are - positive integer values, specifically the multiplicity of the ion, - according to the details of the weighting_method. - dimensions: - rank: 1 - dim: [[1, n_p]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 89d344486bf2008809003a1050c2a58493be1e8ff73709d6b5536eb5a028dfb4 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of points/objects. -# -# -# -# -# Number of mark data per point/object. -# -# -# -# -# Number of atoms in the whitelist. -# -# -# -# -# Number of isotopes in the whitelist. -# -# -# -# -# Base class of the configuration and results of a delocalization algorithm. -# -# Delocalization is used to distribute point-like objects on a grid to obtain -# e.g. smoother count, composition, or concentration values of scalar fields -# and compute gradients of these fields. -# -# -# -# Details about the grid on which the delocalization is applied. -# -# -# -# -# -# -# The weighting model specifies how mark data are mapped to a weight per -# point/object. -# -# -# -# As an example from the research field of atom probe points/objects are (molecular) ions. -# Different methods are used for weighting ions: -# -# * default, points get all the same weight 1., which for atom probe is equivalent -# to (molecular) iontype-based delocalization. -# * element, points get as much weight as they have atoms representing a nuclide -# with a proton number that is matching to a respective entry in whitelist. -# In atom probe jargon, this means atomic_decomposition. -# * isotope, points get as much weight as they have atoms representing a nuclides -# from a respective entry in whitelist. -# In atom probe jargon, this means isotope_decomposition. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# A list of nuclides based on which to evaluate the weight. Nuclides need to exist in the nuclide table. -# Values are nuclide (isotope) hash values using the following hashing rule :math:`H = Z + N \cdot 256` -# with :math:`Z` the number of protons and :math:`N` the number of neutrons of the nuclide. -# For elements set :math:`N` to zero. -# -# -# -# -# -# -# -# Attribute data for each member of the point cloud. For APM these are the -# iontypes generated via ranging. The number of mark data per point is 1 -# in the case for atom probe. -# -# -# -# -# -# -# -# -# Weighting factor with which the integrated intensity per grid cell is -# multiplied specifically for each point/object. For APM the weight are -# positive integer values, specifically the multiplicity of the ion, -# according to the details of the weighting_method. -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXdispersion.yaml b/contributed_definitions/nyaml/NXdispersion.yaml deleted file mode 100644 index 7f5f09a72f..0000000000 --- a/contributed_definitions/nyaml/NXdispersion.yaml +++ /dev/null @@ -1,52 +0,0 @@ -category: base -doc: | - A dispersion denoting a sum of different dispersions. - All NXdispersion_table and NXdispersion_function groups will be added together - to form a single dispersion. -type: group -NXdispersion(NXobject): - model_name(NX_CHAR): - doc: | - The name of the composite model. - (NXdispersion_table): - (NXdispersion_function): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a559ba67cd0d603d4ceb93c278ad68372d938bd45c4bdb09d7366fe084633565 -# -# -# -# -# -# A dispersion denoting a sum of different dispersions. -# All NXdispersion_table and NXdispersion_function groups will be added together -# to form a single dispersion. -# -# -# -# The name of the composite model. -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXdispersion_function.yaml b/contributed_definitions/nyaml/NXdispersion_function.yaml deleted file mode 100644 index f41d0993b2..0000000000 --- a/contributed_definitions/nyaml/NXdispersion_function.yaml +++ /dev/null @@ -1,205 +0,0 @@ -category: base -doc: | - This describes a dispersion function for a material or layer -symbols: - n_repetitions: | - The number of repetitions for the repeated parameters -type: group -NXdispersion_function(NXobject): - model_name(NX_CHAR): - doc: | - The name of this dispersion model. - formula(NX_CHAR): - doc: | - This should be a python parsable function. - Here we should provide which keywords are available - and a BNF of valid grammar. - convention(NX_CHAR): - doc: | - The sign convention being used (n + or - ik) - enumeration: [n + ik, n - ik] - energy_identifier(NX_CHAR): - doc: | - The identifier used to represent energy - in the formula. It is recommended to use `E`. - energy_min(NX_NUMBER): - unit: NX_ENERGY - doc: | - The minimum energy value at which this formula is valid. - energy_max(NX_NUMBER): - unit: NX_ENERGY - doc: | - The maximum energy value at which this formula is valid. - energy_unit(NX_NUMBER): - unit: NX_ENERGY - doc: | - The energy unit used in the formula. - The field value is a scaling factor for the units attribute. - It is recommeded to set the field value to 1 and carry all the unit - scaling information in the units attribute. - wavelength_identifier(NX_CHAR): - doc: | - The identifier useed to represent wavelength - in the formula. It is recommended to use `lambda`. - wavelength_unit(NX_NUMBER): - unit: NX_LENGTH - doc: | - The wavelength unit used in the formula. - The field value is a scaling factor for the units attribute. - It is recommeded to set the field value to 1 and carry all the unit - scaling information in the units attribute. - wavelength_min(NX_NUMBER): - unit: NX_LENGTH - doc: | - The minimum wavelength value at which this formula is valid. - wavelength_max(NX_NUMBER): - unit: NX_LENGTH - doc: | - The maximum wavelength value at which this formula is valid. - representation(NX_CHAR): - doc: | - Which representation does the formula evaluate to. - This may either be n for refractive index or eps for dielectric function. - The appropriate token is then to be used inside the formula. - enumeration: [n, eps] - (NXdispersion_single_parameter): - (NXdispersion_repeated_parameter): - parameter_units: - dimensions: - rank: 1 - dim: [[1, n_repetitions]] - values(NX_NUMBER): - dimensions: - rank: 1 - dim: [[1, n_repetitions]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 5eabf1e67ce228dbed6cf1140745a59f06a51a5874df1cf3a7aab7610c0cbaf3 -# -# -# -# -# -# -# -# The number of repetitions for the repeated parameters -# -# -# -# -# This describes a dispersion function for a material or layer -# -# -# -# The name of this dispersion model. -# -# -# -# -# This should be a python parsable function. -# Here we should provide which keywords are available -# and a BNF of valid grammar. -# -# -# -# -# The sign convention being used (n + or - ik) -# -# -# -# -# -# -# -# -# The identifier used to represent energy -# in the formula. It is recommended to use `E`. -# -# -# -# -# The minimum energy value at which this formula is valid. -# -# -# -# -# The maximum energy value at which this formula is valid. -# -# -# -# -# The energy unit used in the formula. -# The field value is a scaling factor for the units attribute. -# It is recommeded to set the field value to 1 and carry all the unit -# scaling information in the units attribute. -# -# -# -# -# The identifier useed to represent wavelength -# in the formula. It is recommended to use `lambda`. -# -# -# -# -# The wavelength unit used in the formula. -# The field value is a scaling factor for the units attribute. -# It is recommeded to set the field value to 1 and carry all the unit -# scaling information in the units attribute. -# -# -# -# -# The minimum wavelength value at which this formula is valid. -# -# -# -# -# The maximum wavelength value at which this formula is valid. -# -# -# -# -# Which representation does the formula evaluate to. -# This may either be n for refractive index or eps for dielectric function. -# The appropriate token is then to be used inside the formula. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXdispersion_repeated_parameter.yaml b/contributed_definitions/nyaml/NXdispersion_repeated_parameter.yaml deleted file mode 100644 index ca11047df6..0000000000 --- a/contributed_definitions/nyaml/NXdispersion_repeated_parameter.yaml +++ /dev/null @@ -1,99 +0,0 @@ -category: base -doc: | - A repeated parameter for a dispersion function -symbols: - n_repetitions: | - The number of parameter repetitions -type: group -NXdispersion_repeated_parameter(NXobject): - name(NX_CHAR): - doc: | - The name of the parameter - description(NX_CHAR): - doc: | - A description of what this parameter represents - parameter_units(NX_CHAR): - doc: | - A unit array associating a unit with each parameter. - The first element should be equal to values/@unit. - The values should be SI interpretable standard units - with common prefixes (e.g. mikro, nano etc.) or their - short-hand notation (e.g. nm, mm, kHz etc.). - dimensions: - rank: 1 - dim: [[1, n_repetitions]] - values(NX_NUMBER): - unit: NX_ANY - doc: | - The value of the parameter - dimensions: - rank: 1 - dim: [[1, n_repetitions]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 18349045977b3ebafbd959b27c597f5f2f024f54203493b507cc7417a2e6fa41 -# -# -# -# -# -# -# -# The number of parameter repetitions -# -# -# -# -# A repeated parameter for a dispersion function -# -# -# -# The name of the parameter -# -# -# -# -# A description of what this parameter represents -# -# -# -# -# A unit array associating a unit with each parameter. -# The first element should be equal to values/@unit. -# The values should be SI interpretable standard units -# with common prefixes (e.g. mikro, nano etc.) or their -# short-hand notation (e.g. nm, mm, kHz etc.). -# -# -# -# -# -# -# -# The value of the parameter -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXdispersion_single_parameter.yaml b/contributed_definitions/nyaml/NXdispersion_single_parameter.yaml deleted file mode 100644 index 9d3acf5f94..0000000000 --- a/contributed_definitions/nyaml/NXdispersion_single_parameter.yaml +++ /dev/null @@ -1,61 +0,0 @@ -category: base -doc: | - A single parameter for a dispersion function -type: group -NXdispersion_single_parameter(NXobject): - name(NX_CHAR): - doc: | - The name of the parameter - description(NX_CHAR): - doc: | - A description of what this parameter represents - value(NX_NUMBER): - unit: NX_ANY - doc: | - The value of the parameter - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# da8ad19134408a4a7a0f5a39d82da112db1c8870662d0e445eb1abb7359b4330 -# -# -# -# -# -# A single parameter for a dispersion function -# -# -# -# The name of the parameter -# -# -# -# -# A description of what this parameter represents -# -# -# -# -# The value of the parameter -# -# -# diff --git a/contributed_definitions/nyaml/NXdispersion_table.yaml b/contributed_definitions/nyaml/NXdispersion_table.yaml deleted file mode 100644 index afd4abda06..0000000000 --- a/contributed_definitions/nyaml/NXdispersion_table.yaml +++ /dev/null @@ -1,140 +0,0 @@ -category: base -doc: | - A dispersion table denoting energy, dielectric function tabulated values. -symbols: - doc: | - The symbols in this schema to denote the dimensions - n_points: | - The number of energy and dielectric function points -type: group -NXdispersion_table(NXobject): - model_name(NX_CHAR): - doc: | - The name of this dispersion model. - convention(NX_CHAR): - doc: | - The sign convention being used (n + or - ik) - enumeration: [n + ik, n - ik] - wavelength(NX_NUMBER): - unit: NX_LENGTH - doc: | - The wavelength array of the tabulated dataset. - This is essentially a duplicate of the energy field. - There should be one or both of them present. - dimensions: - rank: 1 - dim: [[1, n_points]] - energy(NX_NUMBER): - unit: NX_ENERGY - doc: | - The energy array of the tabulated dataset. - This is essentially a duplicate of the wavelength field. - There should be one or both of them present. - dimensions: - rank: 1 - dim: [[1, n_points]] - refractive_index(NX_COMPLEX): - unit: NX_DIMENSIONLESS - doc: | - The refractive index array of the tabulated dataset. - dimensions: - rank: 1 - dim: [[1, n_points]] - dielectric_function(NX_COMPLEX): - unit: NX_DIMENSIONLESS - doc: | - The dielectric function of the tabulated dataset. - dimensions: - rank: 1 - dim: [[1, n_points]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# c7c02f468941a7d2f766cb1d61de424f1d21d7b9a97d7d7741d6f72d068ecf67 -# -# -# -# -# -# -# The symbols in this schema to denote the dimensions -# -# -# -# The number of energy and dielectric function points -# -# -# -# -# A dispersion table denoting energy, dielectric function tabulated values. -# -# -# -# The name of this dispersion model. -# -# -# -# -# The sign convention being used (n + or - ik) -# -# -# -# -# -# -# -# -# The wavelength array of the tabulated dataset. -# This is essentially a duplicate of the energy field. -# There should be one or both of them present. -# -# -# -# -# -# -# -# The energy array of the tabulated dataset. -# This is essentially a duplicate of the wavelength field. -# There should be one or both of them present. -# -# -# -# -# -# -# -# The refractive index array of the tabulated dataset. -# -# -# -# -# -# -# -# The dielectric function of the tabulated dataset. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXdispersive_material.yaml b/contributed_definitions/nyaml/NXdispersive_material.yaml deleted file mode 100644 index c6d9b966c3..0000000000 --- a/contributed_definitions/nyaml/NXdispersive_material.yaml +++ /dev/null @@ -1,409 +0,0 @@ -category: application -doc: | - NXdispersion -type: group -NXdispersive_material(NXobject): - (NXentry): - definition: - doc: | - An application definition for a dispersive material. - \@version: - doc: | - Version number to identify which definition of this application definition was - used for this entry/data. - \@url: - doc: | - URL where to find further material (documentation, examples) relevant to the - application definition - enumeration: [NXdispersive_material] - sample(NXsample): - chemical_formula(NX_CHAR): - atom_types(NX_CHAR): - exists: optional - doc: | - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - colloquial_name(NX_CHAR): - exists: optional - doc: | - The colloquial name of the material, e.g. graphite or diamond for carbon. - material_phase(NX_CHAR): - exists: optional - doc: | - The phase of the material - enumeration: [gas, liquid, solid, other] - material_phase_comment(NX_CHAR): - exists: optional - doc: | - Additional information about the phase if the - material phase is other. - additional_phase_information(NX_CHAR): - exists: recommended - doc: | - This field may be used to denote additional phase information, - such as crystalin phase of a crystal (e.g. 4H or 6H for SiC) or - if a measurement was done on a thin film or bulk material. - dispersion_type(NX_CHAR): - exists: recommended - doc: | - Denotes whether the dispersion is calculated or derived from an experiment - enumeration: [measured, simulated] - REFERENCES(NXcite): - exists: recommended - text: - doc: | - A text description of this reference, e.g. - `E. Example et al, The mighty example, An example journal 50 (2023), 100` - doi: - dispersion_x(NXdispersion): - doc: | - The dispersion along the optical axis of the material. - This should be the only dispersion available for isotropic materials. - For uniaxial materials this denotes the ordinary axis. - For biaxial materials this denotes the x axis or epsilon 11 tensor element - of the diagionalized permittivity tensor. - model_name(NX_CHAR): - doc: | - The name of this dispersion model. - (NXdispersion_table): - exists: recommended - model_name: - convention: - wavelength(NX_NUMBER): - dielectric_function(NX_COMPLEX): - exists: recommended - refractive_index(NX_COMPLEX): - exists: recommended - (NXdispersion_function): - exists: recommended - model_name: - formula: - convention: - energy_identifier: - exists: recommended - energy_unit(NX_NUMBER): - exists: recommended - wavelength_identifier: - exists: recommended - wavelength_unit(NX_NUMBER): - exists: recommended - representation: - (NXdispersion_single_parameter): - name: - value(NX_NUMBER): - (NXdispersion_repeated_parameter): - name: - values(NX_NUMBER): - plot(NXdata): - exists: recommended - dispersion_y(NXdispersion): - exists: optional - doc: | - This should only be filled for biaxial materials. - It denotes the epsilon 22 direction of the diagionalized - permittivity tensor. - model_name(NX_CHAR): - doc: | - The name of this dispersion model. - (NXdispersion_table): - exists: recommended - model_name: - convention: - wavelength(NX_NUMBER): - dielectric_function(NX_COMPLEX): - exists: recommended - refractive_index(NX_COMPLEX): - exists: recommended - (NXdispersion_function): - exists: recommended - model_name: - formula: - convention: - energy_identifier: - exists: recommended - energy_unit(NX_NUMBER): - exists: recommended - wavelength_identifier: - exists: recommended - wavelength_unit(NX_NUMBER): - exists: recommended - representation: - (NXdispersion_single_parameter): - name: - value(NX_NUMBER): - (NXdispersion_repeated_parameter): - name: - values(NX_NUMBER): - plot(NXdata): - exists: recommended - dispersion_z(NXdispersion): - exists: optional - doc: | - This should only be filled for uniaxial or biaxial materials. - For uniaxial materials this denotes the extraordinary axis. - For biaxial materials this denotes the epsilon 33 tensor element - of the diagionalized perimittivty tensor. - model_name(NX_CHAR): - doc: | - The name of this dispersion model. - (NXdispersion_table): - exists: recommended - model_name: - convention: - wavelength(NX_NUMBER): - dielectric_function(NX_COMPLEX): - exists: recommended - refractive_index(NX_COMPLEX): - exists: recommended - (NXdispersion_function): - exists: recommended - model_name: - formula: - convention: - energy_identifier: - exists: recommended - energy_unit(NX_NUMBER): - exists: recommended - wavelength_identifier: - exists: recommended - wavelength_unit(NX_NUMBER): - exists: recommended - representation: - (NXdispersion_single_parameter): - name: - value(NX_NUMBER): - (NXdispersion_repeated_parameter): - name: - values(NX_NUMBER): - plot(NXdata): - exists: recommended - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 899a33a0cfae0e4d82a201252691d290a42d690ab76f3b7ad66627bdbf492dd5 -# -# -# -# -# -# NXdispersion -# -# -# -# -# An application definition for a dispersive material. -# -# -# -# Version number to identify which definition of this application definition was -# used for this entry/data. -# -# -# -# -# URL where to find further material (documentation, examples) relevant to the -# application definition -# -# -# -# -# -# -# -# -# -# -# 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 colloquial name of the material, e.g. graphite or diamond for carbon. -# -# -# -# -# The phase of the material -# -# -# -# -# -# -# -# -# -# -# Additional information about the phase if the -# material phase is other. -# -# -# -# -# This field may be used to denote additional phase information, -# such as crystalin phase of a crystal (e.g. 4H or 6H for SiC) or -# if a measurement was done on a thin film or bulk material. -# -# -# -# -# -# Denotes whether the dispersion is calculated or derived from an experiment -# -# -# -# -# -# -# -# -# -# A text description of this reference, e.g. -# `E. Example et al, The mighty example, An example journal 50 (2023), 100` -# -# -# -# -# -# -# The dispersion along the optical axis of the material. -# This should be the only dispersion available for isotropic materials. -# For uniaxial materials this denotes the ordinary axis. -# For biaxial materials this denotes the x axis or epsilon 11 tensor element -# of the diagionalized permittivity tensor. -# -# -# -# The name of this dispersion model. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# This should only be filled for biaxial materials. -# It denotes the epsilon 22 direction of the diagionalized -# permittivity tensor. -# -# -# -# The name of this dispersion model. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# This should only be filled for uniaxial or biaxial materials. -# For uniaxial materials this denotes the extraordinary axis. -# For biaxial materials this denotes the epsilon 33 tensor element -# of the diagionalized perimittivty tensor. -# -# -# -# The name of this dispersion model. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXelectrostatic_kicker.yaml b/contributed_definitions/nyaml/NXelectrostatic_kicker.yaml deleted file mode 100644 index 32bf5d3921..0000000000 --- a/contributed_definitions/nyaml/NXelectrostatic_kicker.yaml +++ /dev/null @@ -1,105 +0,0 @@ -category: base -doc: | - definition for a electrostatic kicker. -type: group -NXelectrostatic_kicker(NXobject): - description(NX_CHAR): - doc: | - extended description of the kicker. - beamline_distance(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - define position of beamline element relative to production target - timing(NX_FLOAT): - unit: NX_TIME - exists: ['min', '0', 'max', '1'] - doc: | - kicker timing as defined by ``description`` attribute - \@description: - type: NX_CHAR - set_current(NX_FLOAT): - unit: NX_CURRENT - exists: ['min', '0', 'max', '1'] - doc: | - current set on supply. - read_current(NXlog): - exists: ['min', '0', 'max', '1'] - doc: | - current read from supply. - value: - unit: NX_CURRENT - set_voltage(NX_FLOAT): - unit: NX_VOLTAGE - exists: ['min', '0', 'max', '1'] - doc: | - volage set on supply. - read_voltage(NXlog): - exists: ['min', '0', 'max', '1'] - doc: | - voltage read from supply. - value: - unit: NX_VOLTAGE - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 82bc90d12c2172035170bfe4eccbb7320a90e8629285d3db462da12ed1afc7a3 -# -# -# -# -# definition for a electrostatic kicker. -# -# extended description of the kicker. -# -# -# define position of beamline element relative to production target -# -# -# kicker timing as defined by ``description`` attribute -# -# -# -# current set on supply. -# -# -# current read from supply. -# -# -# -# volage set on supply. -# -# -# voltage read from supply. -# -# -# diff --git a/contributed_definitions/nyaml/NXem_calorimetry.yaml b/contributed_definitions/nyaml/NXem_calorimetry.yaml deleted file mode 100644 index 8c277cb751..0000000000 --- a/contributed_definitions/nyaml/NXem_calorimetry.yaml +++ /dev/null @@ -1,578 +0,0 @@ -category: application -doc: | - Application definition for minimal example in-situ calorimetry. - - What is the technique about. - - General context. - - Literature references. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - - # intentionally axes are not named x, y, z to - # i) assure indices can be used for real and complex, - # ii) that people think hard about how their base vectors are aligned with what and how to name things - n_p: | - Number of pattern - n_f: | - Number of azimuthal integration bins - n_i: | - Number of coordinates along i axis. - n_j: | - Number of coordinates along j axis. - -# for a proper instance of a NeXus file also root level attributes should be set -# NeXus version, h5py version, again can be done later, we have tons of examples -type: group -NXem_calorimetry(NXobject): - - # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently - (NXentry): - exists: ['min', '1', 'max', '1'] - definition(NX_CHAR): - \@version: - type: NX_CHAR - exists: optional - enumeration: [NXem_calorimetry] - - # take here inspiration from the dozens of example appdefs - # e.g. NXem, NXapm_paraprobe_* which shows how to add context - identifier(NXidentifier): - exists: optional - - # a place whereby you can refer to your simulation run, etc - (NXuser): - exists: optional - - # a place where you can give details about people who did it - (NXsample): - exists: optional - - # a place where you can tell e.g. based on which sample you build this simulation - (NXcite): - exists: ['min', '0', 'max', 'unbounded'] - - # a place where to add citations for your work ... - (NXcoordinate_system_set): - diffraction_space(NXcoordinate_system): - (NXcoordinate_system): - exists: ['min', '0', 'max', 'unbounded'] - - # a place where you can describe your coordinate system conventions - # hook-in NXem, alternatively inherit from NXem and just add - # add an actuator(NXactuator): - # doc: | - # DENSsolution heating chip. - # physical_quantity(NX_CHAR): - # enumeration: [temperature] - # event_data for the actual sensor data - # alternatively - diffraction(NXsource): - doc: | - Reference to the resource which stores acquired pattern from the experiment. - - Can refer to the original EMD or MRC files or the parsed NXem in RDM e.g. NOMAD OASIS. - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - actuator(NXserialized): - doc: | - Reference to the resource which stores actuator log file from the experiment. - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - time_synchronization(NXprocess): - doc: | - Assumptions and computations whereby timestamp data from the - detector used for collecting diffraction pattern and the actuator - (heating chip) were synchronized. - sequence_index(NX_POSINT): - pattern_identifier(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_p]] - start_time(NX_DATE_TIME): - doc: | - Timestamp when pattern acquisition started. - dimensions: - rank: 1 - dim: [[1, n_p]] - end_time(NX_DATE_TIME): - doc: | - Timestamp when pattern acquisition ended. - dimensions: - rank: 1 - dim: [[1, n_p]] - - # alternatively only timestamp - pattern_center(NXprocess): - sequence_index(NX_POSINT): - config(NXcollection): - result(NXcg_point_set): - - # depends_on(NX_CHAR): - # doc: | - # Hint to help resolve in which coordinate system position values are defined. - position(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_p], [2, 2]] - - # \@units: 1/nm - distortion_correction(NXprocess): - exists: optional - sequence_index(NX_POSINT): - programID(NXprogram): - exists: optional - program(NX_CHAR): - \@version: - type: NX_CHAR - config(NXcollection): - result(NXcg_ellipsoid_set): - - # depends_on(NX_CHAR): - center(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_p], [2, 2]] - - # \@units: 1/nm - azimuthal_integration(NXprocess): - - # no exists, i.e. assuming required - doc: | - Acquired diffraction pattern azimuthally integrated as a function of time. - sequence_index(NX_POSINT): - programID(NXprogram): - exists: optional - program(NX_CHAR): - \@version: - type: NX_CHAR - config(NXcollection): - - # TODO integration parameter - result(NXdata): - \@signal: - type: NX_CHAR - \@axes: - type: NX_CHAR - \@AXISNAME_indices: - type: NX_CHAR - title(NX_CHAR): - intensity(NX_FLOAT): - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_p], [2, n_f]] - \@long_name: - type: NX_CHAR - axis_pattern_identifier(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_p]] - \@long_name: - type: NX_CHAR - axis_s(NX_FLOAT): - unit: NX_ANY - dimensions: - rank: 1 - dim: [[1, n_f]] - - # \@units: 1/nm - \@long_name: - type: NX_CHAR - axis_time(NX_FLOAT): - unit: NX_TIME - doc: | - Time since start of the in-situ experiment - dimensions: - rank: 1 - dim: [[1, n_p]] - - # \@units: s - background_subtraction(NXprocess): - exists: recommended - sequence_index(NX_POSINT): - programID(NXprogram): - program(NX_CHAR): - \@version: - type: NX_CHAR - config(NXcollection): - - # TODO integration parameter - background(NXcollection): - - # TODO e.g. could add parameter of functional forms for the background of each pattern - result(NXdata): - doc: | - Azimuthally integrated diffraction intensities corrected for background as a - function of time. - \@signal: - type: NX_CHAR - \@axes: - type: NX_CHAR - \@AXISNAME_indices: - type: NX_CHAR - title(NX_CHAR): - intensity(NX_FLOAT): - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_p], [2, n_f]] - \@long_name: - type: NX_CHAR - axis_pattern_identifier(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_p]] - \@long_name: - type: NX_CHAR - axis_s(NX_FLOAT): - unit: NX_ANY - dimensions: - rank: 1 - dim: [[1, n_f]] - - # \@units: 1/nm - \@long_name: - type: NX_CHAR - axis_time(NX_FLOAT): - unit: NX_TIME - doc: | - Time since start of the in-situ experiment - dimensions: - rank: 1 - dim: [[1, n_p]] - - # \@units: s - # peak_fitting(NXpeak_fitting): - # exists: optional - # doc: | - # Background-corrected azimuthally integrated signals indexed for peaks. - # more NXprocess groups could follow only sky is the limit and your imagination and time devotion - profiling(NXcs_profiling): - exists: optional - - # possible place to store details about performance, profiling, etc. - current_working_directory(NX_CHAR): - exists: recommended - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - total_elapsed_time(NX_NUMBER): - - # number_of_processes(NX_POSINT): - # number_of_threads(NX_POSINT): - # number_of_gpus(NX_POSINT): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f41deb48c75893d566a12ac2f3de95ae2277f8505f71576813fed046deae110f -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# -# Number of pattern -# -# -# -# -# Number of azimuthal integration bins -# -# -# -# -# Number of coordinates along i axis. -# -# -# -# -# Number of coordinates along j axis. -# -# -# -# -# Application definition for minimal example in-situ calorimetry. -# -# What is the technique about. -# -# General context. -# -# Literature references. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Reference to the resource which stores acquired pattern from the experiment. -# -# Can refer to the original EMD or MRC files or the parsed NXem in RDM e.g. NOMAD OASIS. -# -# -# -# -# -# -# -# -# Reference to the resource which stores actuator log file from the experiment. -# -# -# -# -# -# -# -# -# Assumptions and computations whereby timestamp data from the -# detector used for collecting diffraction pattern and the actuator -# (heating chip) were synchronized. -# -# -# -# -# -# -# -# -# -# Timestamp when pattern acquisition started. -# -# -# -# -# -# -# -# Timestamp when pattern acquisition ended. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Acquired diffraction pattern azimuthally integrated as a function of time. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Time since start of the in-situ experiment -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Azimuthally integrated diffraction intensities corrected for background as a -# function of time. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Time since start of the in-situ experiment -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXfiber.yaml b/contributed_definitions/nyaml/NXfiber.yaml deleted file mode 100644 index b65514bad0..0000000000 --- a/contributed_definitions/nyaml/NXfiber.yaml +++ /dev/null @@ -1,358 +0,0 @@ -category: base -doc: | - An optical fiber, e.g. glass fiber. - - Specify the quantities that define the fiber. Fiber optics are described in - detail [here](https://www.photonics.com/Article.aspx?AID=25151&PID=4), for - example. -symbols: - N_spectrum_core: | - Length of the spectrum vector (e.g. wavelength or energy) for which the - refractive index of the core material is given. - N_spectrum_clad: | - Length of the spectrum vector (e.g. wavelength or energy) for which the - refractive index of the cladding material is given. - N_spectrum_attenuation: | - Length of the spectrum vector (e.g. wavelength or energy) for which the - attenuation curve is given. - -# A draft of a new base class to describe an optical fiber (e.g. glass fiber) -type: group -NXfiber(NXobject): - description: - exists: recommended - doc: | - Descriptive name or brief description of the fiber, e.g. by stating its - dimension. The dimension of a fiber can be given as 60/100/200 which - refers to a core diameter of 60 micron, a clad diameter of 100 micron, - and a coating diameter of 200 micron. - type: - doc: | - Type/mode of the fiber. Modes of fiber transmission are shown in - Fig. 5 [here](https://www.photonics.com/Article.aspx?AID=25151&PID=4). - enumeration: [single mode, multimode graded index, multimode step index] - dispersion_type: - doc: | - Type of dispersion. - enumeration: [modal, material, chromatic] - dispersion(NX_FLOAT): - unit: NX_TIME - doc: | - Spectrum-dependent (or refractive index-dependent) dispersion of the - fiber. Specify in ps/nm*km. - dimensions: - rank: 1 - dim: [[1, N_spectrum_core]] - core(NXsample): - doc: | - Core of the fiber, i.e. the part of the fiber which transmits the light. - core_material: - doc: | - Specify the material of the core of the fiber. - core_diameter(NX_FLOAT): - unit: NX_LENGTH - doc: | - Core diameter of the fiber (e.g. given in micrometer). - core_index_of_refraction(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Complex index of refraction of the fiber. Specify at given wavelength - (or energy, wavenumber etc.) values. - dimensions: - rank: 2 - dim: [[1, 2], [2, N_spectrum_core]] - cladding(NXsample): - doc: | - Core of the fiber, i.e. the part of the fiber which transmits the light. - clad_material: - doc: | - Specify the material of the core of the fiber. - clad_diameter(NX_FLOAT): - unit: NX_LENGTH - doc: | - Clad diameter of the fiber (e.g. given in micrometer). - clad_index_of_refraction(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Complex index of refraction of the fiber. Specify at given wavelength - (or energy, wavenumber etc.) values. - dimensions: - rank: 2 - dim: [[1, 2], [2, N_spectrum_clad]] - coating(NXsample): - doc: | - Coating of the fiber. - coating_material: - doc: | - Specify the material of the coating of the fiber. - coating_diameter(NX_FLOAT): - unit: NX_LENGTH - doc: | - Outer diameter of the fiber (e.g. given in micrometer). - length(NX_FLOAT): - unit: NX_LENGTH - doc: | - Length of the fiber. - spectral_range(NX_FLOAT): - exists: recommended - unit: NX_ANY - doc: | - Spectral range for which the fiber is designed. Enter the minimum and - maximum values (lower and upper limit) of the wavelength range. - dimensions: - rank: 1 - dim: [[1, 2]] - \@units: - doc: | - Unit of spectral array (e.g. nanometer or angstrom for wavelength, or - electronvolt for energy etc.). - transfer_rate(NX_FLOAT): - unit: NX_ANY - doc: | - Transfer rate of the fiber (in GB per second). - \@units: - doc: | - GB/s - numerical_aperture(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Numerical aperture (NA) of the fiber. - attenuation(NX_FLOAT): - unit: NX_ANY - doc: | - Wavelength-dependent attenuation of the fiber (specify in dB/km). - dimensions: - rank: 1 - dim: [[1, N_spectrum_attenuation]] - \@units: - doc: | - Use dB/km. - enumeration: [dB/km] - power_loss(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Power loss of the fiber in percentage. - acceptance_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Acceptance angle of the fiber. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e3980cd96bd25df3c5431abb00e70b9f56a7b58e7a4de8eff2cbf6048ad0fef8 -# -# -# -# -# -# -# -# -# Length of the spectrum vector (e.g. wavelength or energy) for which the -# refractive index of the core material is given. -# -# -# -# -# Length of the spectrum vector (e.g. wavelength or energy) for which the -# refractive index of the cladding material is given. -# -# -# -# -# Length of the spectrum vector (e.g. wavelength or energy) for which the -# attenuation curve is given. -# -# -# -# -# An optical fiber, e.g. glass fiber. -# -# Specify the quantities that define the fiber. Fiber optics are described in -# detail [here](https://www.photonics.com/Article.aspx?AID=25151&PID=4), for -# example. -# -# -# -# Descriptive name or brief description of the fiber, e.g. by stating its -# dimension. The dimension of a fiber can be given as 60/100/200 which -# refers to a core diameter of 60 micron, a clad diameter of 100 micron, -# and a coating diameter of 200 micron. -# -# -# -# -# Type/mode of the fiber. Modes of fiber transmission are shown in -# Fig. 5 [here](https://www.photonics.com/Article.aspx?AID=25151&PID=4). -# -# -# -# -# -# -# -# -# -# Type of dispersion. -# -# -# -# -# -# -# -# -# -# Spectrum-dependent (or refractive index-dependent) dispersion of the -# fiber. Specify in ps/nm*km. -# -# -# -# -# -# -# -# Core of the fiber, i.e. the part of the fiber which transmits the light. -# -# -# -# Specify the material of the core of the fiber. -# -# -# -# -# Core diameter of the fiber (e.g. given in micrometer). -# -# -# -# -# Complex index of refraction of the fiber. Specify at given wavelength -# (or energy, wavenumber etc.) values. -# -# -# -# -# -# -# -# -# -# Core of the fiber, i.e. the part of the fiber which transmits the light. -# -# -# -# Specify the material of the core of the fiber. -# -# -# -# -# Clad diameter of the fiber (e.g. given in micrometer). -# -# -# -# -# Complex index of refraction of the fiber. Specify at given wavelength -# (or energy, wavenumber etc.) values. -# -# -# -# -# -# -# -# -# -# Coating of the fiber. -# -# -# -# Specify the material of the coating of the fiber. -# -# -# -# -# Outer diameter of the fiber (e.g. given in micrometer). -# -# -# -# -# -# Length of the fiber. -# -# -# -# -# Spectral range for which the fiber is designed. Enter the minimum and -# maximum values (lower and upper limit) of the wavelength range. -# -# -# -# -# -# -# Unit of spectral array (e.g. nanometer or angstrom for wavelength, or -# electronvolt for energy etc.). -# -# -# -# -# -# Transfer rate of the fiber (in GB per second). -# -# -# -# GB/s -# -# -# -# -# -# Numerical aperture (NA) of the fiber. -# -# -# -# -# Wavelength-dependent attenuation of the fiber (specify in dB/km). -# -# -# -# -# -# -# Use dB/km. -# -# -# -# -# -# -# -# -# Power loss of the fiber in percentage. -# -# -# -# -# Acceptance angle of the fiber. -# -# -# diff --git a/contributed_definitions/nyaml/NXgraph_edge_set.yaml b/contributed_definitions/nyaml/NXgraph_edge_set.yaml deleted file mode 100644 index aa8019bd6f..0000000000 --- a/contributed_definitions/nyaml/NXgraph_edge_set.yaml +++ /dev/null @@ -1,205 +0,0 @@ -category: base -doc: | - A set of (eventually directed) edges which connect nodes of a graph. - - Use as a direct child of an instance of :ref:`NXgraph_root`. - Alternatively, use depends_on to specify which instance - of :ref:`NXgraph_root` is defined by this instance. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_edges: | - The number of edges. -type: group -NXgraph_edge_set(NXobject): - depends_on(NX_CHAR): - doc: | - Specify which instance of :ref:`NXgraph_root` this :ref:`NXgraph_edge_set` - refers to. - number_of_edges(NX_UINT): - unit: NX_UNITLESS - doc: | - Total number of edges, counting eventual bidirectional edges only once. - identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer which specifies the first index to be used for distinguishing - edges. Identifiers are defined either implicitly or explicitly. - - For implicit indexing the identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. - - For explicit indexing use the field identifier. For implicit indexing, - consult :ref:`NXcg_primitive_set` to get guidance how to set identifier_offset. - identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Integer used to distinguish edges for explicit indexing. - dimensions: - rank: 1 - dim: [[1, n_edges]] - directionality(NX_UINT): - unit: NX_UNITLESS - doc: | - Specifier whether each edge is non-directional, one-directional, - or bidirectional. Use the smallest available binary representation - which can store three different states: - - * 0 / state 0x00 is non-directional - * 1 / state 0x01 is one-directional - * 2 / state 0x02 is bi-directional - dimensions: - rank: 1 - dim: [[1, n_edges]] - node_pair(NX_INT): - unit: NX_UNITLESS - doc: | - Pairs of node/vertex identifier. Each pair represents the connection - between two nodes. The order in the pair encodes eventual directionality. - - In the case that an edge is non- or bi-directional, storing - node identifier in ascending order is preferred. - - In the case that an edge is one-directional, node identifier should be - stored such that the identifier of the source node is the first entry - and the identifier of the target is the second entry in the pair. - dimensions: - rank: 2 - dim: [[1, n_edges], [2, 2]] - is_a(NX_CHAR): - doc: | - A human-readable qualifier which type or e.g. class instance the - edge is an instance of. - dimensions: - rank: 1 - dim: [[1, n_edges]] - label(NX_CHAR): - doc: | - A human-readable label/caption/tag of each edge. - dimensions: - rank: 1 - dim: [[1, n_edges]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 84d7845e4513742691fa3c7cec9e10b363a330428ea2212441eff1e9c3377433 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The number of edges. -# -# -# -# -# A set of (eventually directed) edges which connect nodes of a graph. -# -# Use as a direct child of an instance of :ref:`NXgraph_root`. -# Alternatively, use depends_on to specify which instance -# of :ref:`NXgraph_root` is defined by this instance. -# -# -# -# Specify which instance of :ref:`NXgraph_root` this :ref:`NXgraph_edge_set` -# refers to. -# -# -# -# -# Total number of edges, counting eventual bidirectional edges only once. -# -# -# -# -# Integer which specifies the first index to be used for distinguishing -# edges. Identifiers are defined either implicitly or explicitly. -# -# For implicit indexing the identifiers are defined on the interval -# :math:`[identifier\_offset, identifier\_offset + c - 1]`. -# -# For explicit indexing use the field identifier. For implicit indexing, -# consult :ref:`NXcg_primitive_set` to get guidance how to set identifier_offset. -# -# -# -# -# Integer used to distinguish edges for explicit indexing. -# -# -# -# -# -# -# -# Specifier whether each edge is non-directional, one-directional, -# or bidirectional. Use the smallest available binary representation -# which can store three different states: -# -# * 0 / state 0x00 is non-directional -# * 1 / state 0x01 is one-directional -# * 2 / state 0x02 is bi-directional -# -# -# -# -# -# -# -# Pairs of node/vertex identifier. Each pair represents the connection -# between two nodes. The order in the pair encodes eventual directionality. -# -# In the case that an edge is non- or bi-directional, storing -# node identifier in ascending order is preferred. -# -# In the case that an edge is one-directional, node identifier should be -# stored such that the identifier of the source node is the first entry -# and the identifier of the target is the second entry in the pair. -# -# -# -# -# -# -# -# -# A human-readable qualifier which type or e.g. class instance the -# edge is an instance of. -# -# -# -# -# -# -# -# A human-readable label/caption/tag of each edge. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXgraph_node_set.yaml b/contributed_definitions/nyaml/NXgraph_node_set.yaml deleted file mode 100644 index 2e8272291f..0000000000 --- a/contributed_definitions/nyaml/NXgraph_node_set.yaml +++ /dev/null @@ -1,189 +0,0 @@ -category: base -doc: | - A set of nodes representing members of a graph. - - Use as a direct child of an instance of :ref:`NXgraph_root`. - Alternatively, use depends_on to specify which instance - of NXgraph_root is defined by this instance. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - c: | - The cardinality of the set, i.e. the number of nodes of the graph. - d: | - The dimensionality of the graph. Eventually use one for categorical. -type: group -NXgraph_node_set(NXobject): - depends_on(NX_CHAR): - doc: | - Specify which instance of :ref:`NXgraph_root` this :ref:`NXgraph_node_set` - refers to. - space(NX_CHAR): - doc: | - About which space does the graph make statements. - enumeration: [euclidean, other] - dimensionality(NX_UINT): - unit: NX_UNITLESS - doc: | - Dimensionality of the space about which the graph makes statements. - Use only when value of the field space is euclidean. - enumeration: [1, 2, 3] - cardinality(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of nodes of the graph. - identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer which specifies the first index to be used for distinguishing - nodes. Identifiers are defined either implicitly or explicitly. - - For implicit indexing the identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. - - For explicit indexing use the field identifier. For implicit indexing, - consult :ref:`NXcg_primitive_set` to get guidance how to set identifier_offset. - identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Integer used to distinguish nodes for explicit indexing. - dimensions: - rank: 1 - dim: [[1, c]] - is_a(NX_CHAR): - doc: | - A human-readable qualifier which type or e.g. class instance the - node is an instance of. An example: a NeXus application definition is a - graph, more specifically a hierarchical directed labelled property graph. - Instances which are groups like :ref:`NXgraph_node_set` could have an is_a - qualifier reading :ref:`NXgraph_node_set`. - dimensions: - rank: 1 - dim: [[1, c]] - label(NX_CHAR): - doc: | - A human-readable label/caption/tag of each node. - dimensions: - rank: 1 - dim: [[1, c]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# da6f7949b04a7662f8ba92cc2912a465f0e87eecc00a60f63d61f3cb4a1d4ca1 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The cardinality of the set, i.e. the number of nodes of the graph. -# -# -# -# -# The dimensionality of the graph. Eventually use one for categorical. -# -# -# -# -# A set of nodes representing members of a graph. -# -# Use as a direct child of an instance of :ref:`NXgraph_root`. -# Alternatively, use depends_on to specify which instance -# of NXgraph_root is defined by this instance. -# -# -# -# Specify which instance of :ref:`NXgraph_root` this :ref:`NXgraph_node_set` -# refers to. -# -# -# -# -# About which space does the graph make statements. -# -# -# -# -# -# -# -# -# Dimensionality of the space about which the graph makes statements. -# Use only when value of the field space is euclidean. -# -# -# -# -# -# -# -# -# -# Number of nodes of the graph. -# -# -# -# -# Integer which specifies the first index to be used for distinguishing -# nodes. Identifiers are defined either implicitly or explicitly. -# -# For implicit indexing the identifiers are defined on the interval -# :math:`[identifier\_offset, identifier\_offset + c - 1]`. -# -# For explicit indexing use the field identifier. For implicit indexing, -# consult :ref:`NXcg_primitive_set` to get guidance how to set identifier_offset. -# -# -# -# -# Integer used to distinguish nodes for explicit indexing. -# -# -# -# -# -# -# -# A human-readable qualifier which type or e.g. class instance the -# node is an instance of. An example: a NeXus application definition is a -# graph, more specifically a hierarchical directed labelled property graph. -# Instances which are groups like :ref:`NXgraph_node_set` could have an is_a -# qualifier reading :ref:`NXgraph_node_set`. -# -# -# -# -# -# -# -# A human-readable label/caption/tag of each node. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXgraph_root.yaml b/contributed_definitions/nyaml/NXgraph_root.yaml deleted file mode 100644 index 84cc326b14..0000000000 --- a/contributed_definitions/nyaml/NXgraph_root.yaml +++ /dev/null @@ -1,48 +0,0 @@ -category: base -doc: | - An instance of a graph. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXgraph_root(NXobject): - nodes(NXgraph_node_set): - relation(NXgraph_edge_set): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f05819ddfdf99b042d83339bf2e60461b2b2793bcc6eec0a37512154cab3b739 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# An instance of a graph. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXisocontour.yaml b/contributed_definitions/nyaml/NXisocontour.yaml deleted file mode 100644 index a78cbaaad8..0000000000 --- a/contributed_definitions/nyaml/NXisocontour.yaml +++ /dev/null @@ -1,117 +0,0 @@ -category: base -doc: | - Base class for describing isocontouring/phase-fields in Euclidean space. - - Iso-contouring algorithms such as Marching Cubes and others are frequently - used to segment d-dimensional regions at crossings of a threshold value, - the so-called isovalue. - - In Computational Materials Science phase-field methods are frequently used. - Phase-field variables are discretized frequently using regular grids. - - Isocontour algorithms are often used in such context to pinpoint the - locations of microstructural features from this implicit phase-field- - variable-value-based description. - - One of the key intentions of this base class is to provide a starting point - for scientists from the phase-field community (condensed-matter physicists, - and materials engineers) to incentivize that also phase-field (and other) - simulation data can take advantage of NeXus base class to improve - interoperability. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the description. -type: group -NXisocontour(NXobject): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - doc: | - The dimensionality of the space in which the isocontour is embedded. - enumeration: [1, 2, 3] - grid(NXcg_grid): - doc: | - The discretized grid on which the iso-contour algorithm operates. - isovalue(NX_NUMBER): - unit: NX_ANY - doc: | - The threshold or iso-contour value. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d707db3d9f44694ffc27ccfda00d59f683d5b3bb3ce0715d460f0e05f23a5901 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality of the description. -# -# -# -# -# Base class for describing isocontouring/phase-fields in Euclidean space. -# -# Iso-contouring algorithms such as Marching Cubes and others are frequently -# used to segment d-dimensional regions at crossings of a threshold value, -# the so-called isovalue. -# -# In Computational Materials Science phase-field methods are frequently used. -# Phase-field variables are discretized frequently using regular grids. -# -# Isocontour algorithms are often used in such context to pinpoint the -# locations of microstructural features from this implicit phase-field- -# variable-value-based description. -# -# One of the key intentions of this base class is to provide a starting point -# for scientists from the phase-field community (condensed-matter physicists, -# and materials engineers) to incentivize that also phase-field (and other) -# simulation data can take advantage of NeXus base class to improve -# interoperability. -# -# -# -# The dimensionality of the space in which the isocontour is embedded. -# -# -# -# -# -# -# -# -# -# The discretized grid on which the iso-contour algorithm operates. -# -# -# -# -# The threshold or iso-contour value. -# -# -# diff --git a/contributed_definitions/nyaml/NXiv_bias.yaml b/contributed_definitions/nyaml/NXiv_bias.yaml deleted file mode 100644 index 3cd766b364..0000000000 --- a/contributed_definitions/nyaml/NXiv_bias.yaml +++ /dev/null @@ -1,324 +0,0 @@ -category: base -doc: | - Application definition for bias devices. -type: group -NXiv_bias(NXobject): - bias(NX_NUMBER): - unit: NX_VOLTAGE - doc: | - Applied a voltage between tip and sample. - tunneling_resistor(NX_NUMBER): - unit: NX_ANY - doc: | - The ratio between the tunneling current at the sample surface and the bias voltage - applied between the sample and the tip. - calibration(NX_NUMBER): - doc: | - Calibration of the Bias output (V/V). - offset(NX_NUMBER): - unit: NX_VOLTAGE - doc: | - Allows compensating for an offset in Bias. Hardware parameter offset. - modulated_signal_bias(NX_NUMBER): - unit: NX_VOLTAGE - doc: | - Sets the amplitude (in physical units of the modulated signal) of the sine - modulation. - (NXbias_spectroscopy): - doc: | - Bias sweeps while measuring arbitrary channels with I(V) curves. - channels(NX_CHAR): - doc: | - Select the channels to record. - reset_bias(NX_BOOLEAN): - doc: | - When selected, the Bias voltage returns to the initial value (before starting the sweep) at - the end of the spectroscopy measurement (default). When not selected, Bias remains at the - last value of the sweep. This is useful e.g. when combining several sweep segments. Example - for an automated measurement (using Programming Interface): switch off Z-Controller, start - spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, - switch on Z-Controller. - record_final_z(NX_BOOLEAN): - doc: | - Select whether to record the Z position during Z averaging time at the end of - the sweep (after Z control time) and store the average value in the header of - the file when saving. Using this option increases the sweep time by Z averaging - time. - lock_in_run(NX_BOOLEAN): - doc: | - Select whether to set the Lock-In to run during the measurement. When using this - feature, make sure the Lock-In is configured correctly and settling times are - set to twice the Lock-In period at least. This option is ignored when Lock-In is - already running. This option is disabled if the Sweep Mode is MLS and the flag - to configure the Lock-In per segment in the Multiline segment editor is set. - integration_time(NX_NUMBER): - unit: NX_TIME - doc: | - Time during which the spectroscopy data are acquired and averaged. - number_of_sweeps(NX_NUMBER): - doc: | - Number of sweeps to measure and average. - sweep_start(NX_NUMBER): - unit: NX_VOLTAGE - doc: | - The first bias values of the sweep. - sweep_end(NX_NUMBER): - unit: NX_VOLTAGE - doc: | - The last bias values of the sweep. - num_pixel(NX_NUMBER): - doc: | - Define the sweep number of points, that is, the maximum spectrum resolution eq. - Bias window divide by Num Pixel. - z_avg_time(NX_NUMBER): - unit: NX_TIME - doc: | - Duration over which the Z position is recorded and averaged before and after the - sweep (the latter only if Record final Z position is selected in the Advanced - section). After the initial Z averaging time, if Z-Controller to Hold is - selected in the Advanced section, the Z-Controller is set to hold and the tip is - placed at the previously averaged Z position (plus Z offset). - sw_filter_type(NX_CHAR): - doc: | - Select a filter to smooth the displayed data. When saving, if any filter - selected, filtered data are saved to file along with the unfiltered data. - sw_ilter_order(NX_NUMBER): - doc: | - Filter order of a dynamic filter or width (in number of points) for the gaussian - filter. - sw_filter_cutoff_frq(NX_NUMBER): - doc: | - Cutoff frequency for dynamic filters. - z_offset(NX_NUMBER): - unit: NX_LENGTH - doc: | - Offset added to the initial averaged position Zaver before starting to sweep. - This parameter is disabled when Z-Controller to Hold is deselected in the - Advanced section. The LED “Alt” next to the Z offset indicates if an alternate - Z-controller setpoint is enabled. - settling_time(NX_NUMBER): - unit: NX_TIME - doc: | - time to wait after changing the bias to the next level and before starting to - acquire data. - end_settling_time(NX_NUMBER): - unit: NX_TIME - doc: | - Time to wait after the sweep has finished and the bias is ramped to the initial - value. - z_control_time(NX_NUMBER): - unit: NX_TIME - doc: | - Time during which the Z-Controller is enabled once a sweep has finished. When - averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled for this - duration between each sweep. After the last sweep, it will wait the specified - time before continuing a running scan. This ensures each sweep reliably starts - from the same position. This parameter is disabled when Z-Controller to Hold is - deselected in the Advanced section. - max_sew_rate(NX_NUMBER): - doc: | - Maximum rate at which the bias changes (before, during and after sweeping). - (V/s) - backward_sweep(NX_BOOLEAN): - doc: | - Select whether to measure the backward (return) sweep or the forward only. - z_controller_hold(NX_BOOLEAN): - doc: | - Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. - It is selected by default. When deselected, Z-offset and Z-control time - parameters are disabled. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4c5a10d05543a8750dd483e9fd47b0b61e96d7523dde8d0e613da3808bde797e -# -# -# -# -# -# Application definition for bias devices. -# -# -# -# Applied a voltage between tip and sample. -# -# -# -# -# The ratio between the tunneling current at the sample surface and the bias voltage -# applied between the sample and the tip. -# -# -# -# -# Calibration of the Bias output (V/V). -# -# -# -# -# Allows compensating for an offset in Bias. Hardware parameter offset. -# -# -# -# -# Sets the amplitude (in physical units of the modulated signal) of the sine -# modulation. -# -# -# -# -# Bias sweeps while measuring arbitrary channels with I(V) curves. -# -# -# -# -# Select the channels to record. -# -# -# -# -# When selected, the Bias voltage returns to the initial value (before starting the sweep) at -# the end of the spectroscopy measurement (default). When not selected, Bias remains at the -# last value of the sweep. This is useful e.g. when combining several sweep segments. Example -# for an automated measurement (using Programming Interface): switch off Z-Controller, start -# spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, -# switch on Z-Controller. -# -# -# -# -# Select whether to record the Z position during Z averaging time at the end of -# the sweep (after Z control time) and store the average value in the header of -# the file when saving. Using this option increases the sweep time by Z averaging -# time. -# -# -# -# -# Select whether to set the Lock-In to run during the measurement. When using this -# feature, make sure the Lock-In is configured correctly and settling times are -# set to twice the Lock-In period at least. This option is ignored when Lock-In is -# already running. This option is disabled if the Sweep Mode is MLS and the flag -# to configure the Lock-In per segment in the Multiline segment editor is set. -# -# -# -# -# Time during which the spectroscopy data are acquired and averaged. -# -# -# -# -# Number of sweeps to measure and average. -# -# -# -# -# The first bias values of the sweep. -# -# -# -# -# The last bias values of the sweep. -# -# -# -# -# Define the sweep number of points, that is, the maximum spectrum resolution eq. -# Bias window divide by Num Pixel. -# -# -# -# -# Duration over which the Z position is recorded and averaged before and after the -# sweep (the latter only if Record final Z position is selected in the Advanced -# section). After the initial Z averaging time, if Z-Controller to Hold is -# selected in the Advanced section, the Z-Controller is set to hold and the tip is -# placed at the previously averaged Z position (plus Z offset). -# -# -# -# -# Select a filter to smooth the displayed data. When saving, if any filter -# selected, filtered data are saved to file along with the unfiltered data. -# -# -# -# -# Filter order of a dynamic filter or width (in number of points) for the gaussian -# filter. -# -# -# -# -# Cutoff frequency for dynamic filters. -# -# -# -# -# Offset added to the initial averaged position Zaver before starting to sweep. -# This parameter is disabled when Z-Controller to Hold is deselected in the -# Advanced section. The LED “Alt” next to the Z offset indicates if an alternate -# Z-controller setpoint is enabled. -# -# -# -# -# time to wait after changing the bias to the next level and before starting to -# acquire data. -# -# -# -# -# Time to wait after the sweep has finished and the bias is ramped to the initial -# value. -# -# -# -# -# Time during which the Z-Controller is enabled once a sweep has finished. When -# averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled for this -# duration between each sweep. After the last sweep, it will wait the specified -# time before continuing a running scan. This ensures each sweep reliably starts -# from the same position. This parameter is disabled when Z-Controller to Hold is -# deselected in the Advanced section. -# -# -# -# -# Maximum rate at which the bias changes (before, during and after sweeping). -# (V/s) -# -# -# -# -# Select whether to measure the backward (return) sweep or the forward only. -# -# -# -# -# Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. -# It is selected by default. When deselected, Z-offset and Z-control time -# parameters are disabled. -# -# -# diff --git a/contributed_definitions/nyaml/NXiv_temp.yaml b/contributed_definitions/nyaml/NXiv_temp.yaml deleted file mode 100644 index 379cdb70b9..0000000000 --- a/contributed_definitions/nyaml/NXiv_temp.yaml +++ /dev/null @@ -1,164 +0,0 @@ -category: application -doc: | - Application definition for temperature-dependent IV curve measurements. - - In this application definition, times should be specified always together - with an UTC offset. - - This is the application definition describing temperature dependent IV curve - measurements. For this a temperature is set. After reaching the temperature, - a voltage sweep is performed. For each voltage a current is measured. - Then, the next desired temperature is set and an IV measurement is performed. -symbols: - n_different_temperatures: | - Number of different temperature setpoints used in the experiment. - n_different_voltages: | - Number of different voltage setpoints used in the experiment. -type: group -NXiv_temp(NXsensor_scan): - (NXentry): - definition: - enumeration: [NXiv_temp] - (NXsample): - exists: recommended - name: - doc: | - Descriptive name or ideally (globally) unique persistent identifier. - 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. - (NXinstrument): - (NXenvironment): - doc: | - Describes an environment setup for a temperature-dependent IV measurement experiment. - - The temperature and voltage must be present as independently scanned controllers and - the current sensor must also be present with its readings. - voltage_controller(NXsensor): - temperature_controller(NXsensor): - current_sensor(NXsensor): - (NXdata): - doc: | - This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. - There should also be two more fields called temperature and voltage containing the setpoint values. - There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension - equal to the number of voltage setpoints. - temperature(NX_NUMBER): - voltage(NX_NUMBER): - current(NX_NUMBER): - dimensions: - rank: 2 - dim: [[1, n_different_temperatures], [2, n_different_voltages]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a95810b27ee0ef3fe2d65f0eba67d57f3ccb7183eaaaccc0f8ba8a95646c5ff4 -# -# -# -# -# -# -# -# Number of different temperature setpoints used in the experiment. -# -# -# -# -# Number of different voltage setpoints used in the experiment. -# -# -# -# -# Application definition for temperature-dependent IV curve measurements. -# -# In this application definition, times should be specified always together -# with an UTC offset. -# -# This is the application definition describing temperature dependent IV curve -# measurements. For this a temperature is set. After reaching the temperature, -# a voltage sweep is performed. For each voltage a current is measured. -# Then, the next desired temperature is set and an IV measurement is performed. -# -# -# -# -# -# -# -# -# -# -# Descriptive name or ideally (globally) unique persistent identifier. -# -# -# -# -# List of comma-separated elements from the periodic table -# that are contained in the sample. -# If the sample substance has multiple components, all -# elements from each component must be included in `atom_types`. -# -# The purpose of the field is to offer materials database systems an -# opportunity to parse the relevant elements without having to interpret -# these from the sample history or from other data sources. -# -# -# -# -# -# -# Describes an environment setup for a temperature-dependent IV measurement experiment. -# -# The temperature and voltage must be present as independently scanned controllers and -# the current sensor must also be present with its readings. -# -# -# -# -# -# -# -# -# This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. -# There should also be two more fields called temperature and voltage containing the setpoint values. -# There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension -# equal to the number of voltage setpoints. -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXlab_electro_chemo_mechanical_preparation.yaml b/contributed_definitions/nyaml/NXlab_electro_chemo_mechanical_preparation.yaml deleted file mode 100644 index 0586c5c610..0000000000 --- a/contributed_definitions/nyaml/NXlab_electro_chemo_mechanical_preparation.yaml +++ /dev/null @@ -1,317 +0,0 @@ -category: application -doc: | - Grinding and polishing of a sample using abrasives in a wet lab. - Manual procedures, electro-chemical, vibropolishing. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXlab_electro_chemo_mechanical_preparation(NXobject): - (NXentry): - - # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently - \@version: - doc: | - Version specifier of this application definition. - definition: - doc: | - Official NeXus NXDL schema with which this file was written. - enumeration: [NXlab_electro_chemo_mechanical_preparation] - workflow_step_identifier(NX_UINT): - workflow_step_description: - SAMPLE(NXsample): - exists: ['min', '1', 'max', '1'] - USER(NXuser): - exists: ['min', '1', 'max', 'unbounded'] - - # (NXlab_grinding_machine): - grinding_machine(NXfabrication): - vendor: - model: - identifier(NXidentifier): - exists: recommended - GRINDING_STEP(NXprocess): - doc: | - A preparation step performed by a human or a robot/automated system. - - # maybe a user per step as sometimes samples are prepared by more than - # one person or not each person performs all polishing steps - sequence_index(NX_POSINT): - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - abrasive_medium_carrier: - doc: | - Carrier/plate used on which the abrasive/(lubricant) mixture was applied. - - # enumeration: [plate] - # controlled vocabulary items - abrasive_medium: - doc: | - Medium on the abrasive_medium_carrier (cloth or grinding plate) - whereby material is abrasively weared. - - # enumeration: [SiC180] - # controlled vocabulary items or instance of chemical, need for free-text? - # also need for free-text in subsequent files? - lubricant: - doc: | - Lubricant - - # enumeration: [none, water, ethanol, oil] - # from a list of controlled vocabulary items, or instance of chemical - # etching/corrosive attack, tracking the environment, what can we - # learn from our colleagues within NFDI4Cat, NFDI4Chem, and NFDI-MatWerk? - rotation_control: - doc: | - Qualitative statement how the revelation of the machine was configured. - If the rotation was controlled manually, e.g. by turning knobs - choose manual and estimate the nominal average rotation. - If the rotation was controlled via choosing from a fixed set - of options offered by the machine choose fixed and - specify the nominal rotation. - If programmed use rotation_history (e.g. for automated/robot systems). - enumeration: [undefined, manual, fixed, programmed] - force_control: - doc: | - Qualitative statement how the (piston) force with which the sample - was pressed into/against the abrasive medium was controlled if at all. - If the force was controlled manually e.g. by turning knobs - choose manual and estimate nominal average force. - If the force was controlled via choosing from a fixed set - of options offered by the machine choose fixed and - specify the nominal force. - If programmed use force_history (e.g. for automated/robot systems). - enumeration: [undefined, manual, fixed, programmed] - time_control: - doc: | - Qualitative statement for how long (assuming regular uninterrupted) - preparation at the specified conditions the preparation step was - applied. - enumeration: [undefined, manual, fixed, programmed] - rotation(NX_NUMBER): - unit: NX_FREQUENCY - doc: | - Turns per unit time. - - # rotation_history(NX_NUMBER): - force(NX_NUMBER): - unit: NX_ANY - doc: | - Force exerted on the sample to press it into the abrasive. - - # force-history(NX_NUMBER): - time(NX_NUMBER): - unit: NX_TIME - doc: | - Seconds - removal: - doc: | - Qualitative statement how the material removal was characterized. - enumeration: [undefined, estimated, measured] - thickness_reduction(NX_NUMBER): - unit: NX_LENGTH - doc: | - How thick a layer was removed. - - # time_history(NX_NUMBER): - # SENSOR_SCAN(NXsensor_scan): - # electro-chemical preparation is nothing but an I(V) curve within - # a corrosive medium, eventually some wet lab steps have characteristics - # of pure grinding, mechanical polishing, or a mixture with corrosive - # attack - CLEANING_STEP(NXprocess): - doc: | - A preparation step performed by a human or a robot/automated system - with the aim to remove residual abrasive medium from the specimen surface. - sequence_index(NX_POSINT): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# df1f39f31d8d4cb2091fdba0838a939df7a1ff3bea260273ecd01ef316b48555 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Grinding and polishing of a sample using abrasives in a wet lab. -# Manual procedures, electro-chemical, vibropolishing. -# -# -# -# -# -# Version specifier of this application definition. -# -# -# -# -# Official NeXus NXDL schema with which this file was written. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# A preparation step performed by a human or a robot/automated system. -# -# -# -# -# -# -# -# Carrier/plate used on which the abrasive/(lubricant) mixture was applied. -# -# -# -# -# -# Medium on the abrasive_medium_carrier (cloth or grinding plate) -# whereby material is abrasively weared. -# -# -# -# -# -# Lubricant -# -# -# -# -# -# Qualitative statement how the revelation of the machine was configured. -# If the rotation was controlled manually, e.g. by turning knobs -# choose manual and estimate the nominal average rotation. -# If the rotation was controlled via choosing from a fixed set -# of options offered by the machine choose fixed and -# specify the nominal rotation. -# If programmed use rotation_history (e.g. for automated/robot systems). -# -# -# -# -# -# -# -# -# -# -# Qualitative statement how the (piston) force with which the sample -# was pressed into/against the abrasive medium was controlled if at all. -# If the force was controlled manually e.g. by turning knobs -# choose manual and estimate nominal average force. -# If the force was controlled via choosing from a fixed set -# of options offered by the machine choose fixed and -# specify the nominal force. -# If programmed use force_history (e.g. for automated/robot systems). -# -# -# -# -# -# -# -# -# -# -# Qualitative statement for how long (assuming regular uninterrupted) -# preparation at the specified conditions the preparation step was -# applied. -# -# -# -# -# -# -# -# -# -# -# Turns per unit time. -# -# -# -# -# -# Force exerted on the sample to press it into the abrasive. -# -# -# -# -# -# Seconds -# -# -# -# -# Qualitative statement how the material removal was characterized. -# -# -# -# -# -# -# -# -# -# How thick a layer was removed. -# -# -# -# -# -# -# A preparation step performed by a human or a robot/automated system -# with the aim to remove residual abrasive medium from the specimen surface. -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXlab_sample_mounting.yaml b/contributed_definitions/nyaml/NXlab_sample_mounting.yaml deleted file mode 100644 index d01f0ac6b5..0000000000 --- a/contributed_definitions/nyaml/NXlab_sample_mounting.yaml +++ /dev/null @@ -1,151 +0,0 @@ -category: application -doc: | - Embedding of a sample in a medium for easing processability. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXlab_sample_mounting(NXobject): - (NXentry): - - # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently - \@version: - doc: | - Version specifier of this application definition. - definition: - doc: | - Official NeXus NXDL schema with which this file was written. - enumeration: [NXlab_sample_mounting] - SAMPLE(NXsample): - exists: ['min', '1', 'max', '1'] - USER(NXuser): - exists: ['min', '1', 'max', 'unbounded'] - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - - # (NXlab_mounting_machine): - mounting_machine(NXfabrication): - vendor: - model: - identifier(NXidentifier): - exists: recommended - mounting_method: - doc: | - Qualitative statement how the sample was mounted. - enumeration: [cold_mounting, hot_mounting] - embedding_medium: - doc: | - Type of material. - enumeration: [resin, epoxy] - electrical_conductivity(NX_FLOAT): - unit: NX_ANY - doc: | - Electrical conductivity of the embedding medium. - - # temperature control of the mounting (e.g. relevant when hot_mounting Al) - # cleaning procedures - # a descriptor of the shape of the specimen - # borrow from NXlab_thermo_mechanical_processing to document the external - # stimuli (eventually) applied during mounting - # temperature, mechanical, magnetic, electro-magnetic, are externally - # applied stimuli on the sample, can we use one master schema? - # e.g. one can even store NXcg_polyhedron_set and NXcg_face_list_data_structure - # instances to keep track of the geometry of specific instrument and how - # the samples were arranged in these - # key question is which steps has the sample experienced? - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 857fb4f773bd18a61e21bab8d7ca2b1303a65f03918445d1dce65eb66f2f6f70 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Embedding of a sample in a medium for easing processability. -# -# -# -# -# -# Version specifier of this application definition. -# -# -# -# -# Official NeXus NXDL schema with which this file was written. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Qualitative statement how the sample was mounted. -# -# -# -# -# -# -# -# -# Type of material. -# -# -# -# -# -# -# -# -# Electrical conductivity of the embedding medium. -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXlockin.yaml b/contributed_definitions/nyaml/NXlockin.yaml deleted file mode 100644 index 25734f99b8..0000000000 --- a/contributed_definitions/nyaml/NXlockin.yaml +++ /dev/null @@ -1,252 +0,0 @@ -category: base -doc: | - Base classes definition for lock in devices. -type: group -NXlockin(NXobject): - hardware(NXfabrication): - doc: | - Hardware manufacturers and type of lockin amplifier. - (NXamplifier): - doc: | - By mixing the input signal (STS signal) with the modulated signal (such as Bias) - and comparing it with the reference signal, they are enhanced and the effects of - noise interference are reduced, resulting in more accurate measurements. - bias_divider: - doc: | - if Lock-in -- Bias Divider 1/10 or 1/100, Bias divider = - V(ref)/[V(ref)+V(input)] - modulation_status(NX_BOOLEAN): - doc: | - Switch the lock-in moulation on or off. - modulation_signal: - doc: | - A modulation signal (such as bias, current et.al.) is a periodic voltage signal, - usually applied to the surface of a sample, which serves to modify the physical - properties of the sample surface and generate weak AC current signals that can - be detected and analysed by instruments such as lock-in amplifiers. - - # (For bais modulate signal, it depands on the modulate type) - modulation_amplitude(NX_NUMBER): - unit: NX_VOLTAGE - doc: | - Sets the amplitude (in physical units of the modulated signal) of the sine - modulation. - modulation_frequency(NX_NUMBER): - unit: NX_FREQUENCY - doc: | - Sets the frequency of the sine modulation added to the signal to modulate. - demodulated_signal: - doc: | - The input signal (STS signal) will be demodulated, in order to determine the amplitude - and phase at the frequency set in the Frequency field or harmonics, such as current, - bias, et.al. - - # output (demodulated signal) characterisation (foreach channel, like demodulation, a separate sensor output, e.g. X,Y) - number_of_demodulator_channels(NX_NUMBER): - doc: | - The number of signals which will be demodulated. - low_pass(NX_NUMBER): - unit: NX_FREQUENCY - doc: | - Order and cut-off frequency of the low-pass filter applied on the demodulated - signals (X,Y). Cut-off frq (low pass filter) (foreach DemodulatorChannels) - hi_pass(NX_NUMBER): - unit: NX_FREQUENCY - doc: | - Order and cut-off frequency of the high-pass filter applied on the demodulation - signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) - lp_filter_cutoff(NX_NUMBER): - unit: NX_FREQUENCY - doc: | - Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) - value) for D1. The filter is applied to the demodulated signals (X,Y). - lp_filter_order(NX_NUMBER): - doc: | - Order and cut-off frequency of the low-pass filter applied on the demodulated - signals (X,Y). Reducing the bandwidth or increasing the order reduces noise on - the demodulated signals, but will require longer settling and measurement times. - hp_filter_cutoff(NX_NUMBER): - unit: NX_FREQUENCY - doc: | - Sets the cut-off frequency of the high-pass filter (affects the displayed TC (s) - value) for D1. The filter is applied to the demodulated signals (X,Y). - hp_filter_order(NX_NUMBER): - doc: | - Order and cut-off frequency of the high-pass filter applied on the demodulation - signal of D!. This is used mainly to suppress a DC component of the demodulation - signal, which would lead to a component at modulation frequency in the - demodulated signals. - sync(NX_BOOLEAN): - doc: | - Switch on/off the Sync filter on the demodulated signals (X,Y) on or off. - (foreach DemodulatorChannels) - ref_phase_N(NX_NUMBER): - unit: NX_ANGLE - doc: | - Reference phase for the sine on the demodulated signal with respect to the - modulation signal. (foreach DemodulatorChannels) - integration_time(NX_NUMBER): - unit: NX_TIME - doc: | - Time during which the data are acquired and averaged. (for the input filter) - harmonic_order_N(NX_NUMBER): - doc: | - The order of the harmonic oscillation to detect on the demodulated signals. - (with respect to the modulation frequency) - sensitivity_factor(NX_NUMBER): - doc: | - Ratio of output signal amplitude to input signal amplitue (V/V). (input gain) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 1590a27b15d28fbdc75ffbb13f8309ad19d255f2898af1d05a9c914c65bc7f01 -# -# -# -# -# -# Base classes definition for lock in devices. -# -# -# -# Hardware manufacturers and type of lockin amplifier. -# -# -# -# -# By mixing the input signal (STS signal) with the modulated signal (such as Bias) -# and comparing it with the reference signal, they are enhanced and the effects of -# noise interference are reduced, resulting in more accurate measurements. -# -# -# -# -# if Lock-in -- Bias Divider 1/10 or 1/100, Bias divider = -# V(ref)/[V(ref)+V(input)] -# -# -# -# -# Switch the lock-in moulation on or off. -# -# -# -# -# A modulation signal (such as bias, current et.al.) is a periodic voltage signal, -# usually applied to the surface of a sample, which serves to modify the physical -# properties of the sample surface and generate weak AC current signals that can -# be detected and analysed by instruments such as lock-in amplifiers. -# -# -# -# -# -# Sets the amplitude (in physical units of the modulated signal) of the sine -# modulation. -# -# -# -# -# Sets the frequency of the sine modulation added to the signal to modulate. -# -# -# -# -# The input signal (STS signal) will be demodulated, in order to determine the amplitude -# and phase at the frequency set in the Frequency field or harmonics, such as current, -# bias, et.al. -# -# -# -# -# -# The number of signals which will be demodulated. -# -# -# -# -# Order and cut-off frequency of the low-pass filter applied on the demodulated -# signals (X,Y). Cut-off frq (low pass filter) (foreach DemodulatorChannels) -# -# -# -# -# Order and cut-off frequency of the high-pass filter applied on the demodulation -# signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) -# -# -# -# -# Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) -# value) for D1. The filter is applied to the demodulated signals (X,Y). -# -# -# -# -# Order and cut-off frequency of the low-pass filter applied on the demodulated -# signals (X,Y). Reducing the bandwidth or increasing the order reduces noise on -# the demodulated signals, but will require longer settling and measurement times. -# -# -# -# -# Sets the cut-off frequency of the high-pass filter (affects the displayed TC (s) -# value) for D1. The filter is applied to the demodulated signals (X,Y). -# -# -# -# -# Order and cut-off frequency of the high-pass filter applied on the demodulation -# signal of D!. This is used mainly to suppress a DC component of the demodulation -# signal, which would lead to a component at modulation frequency in the -# demodulated signals. -# -# -# -# -# Switch on/off the Sync filter on the demodulated signals (X,Y) on or off. -# (foreach DemodulatorChannels) -# -# -# -# -# Reference phase for the sine on the demodulated signal with respect to the -# modulation signal. (foreach DemodulatorChannels) -# -# -# -# -# Time during which the data are acquired and averaged. (for the input filter) -# -# -# -# -# The order of the harmonic oscillation to detect on the demodulated signals. -# (with respect to the modulation frequency) -# -# -# -# -# Ratio of output signal amplitude to input signal amplitue (V/V). (input gain) -# -# -# diff --git a/contributed_definitions/nyaml/NXmagnetic_kicker.yaml b/contributed_definitions/nyaml/NXmagnetic_kicker.yaml deleted file mode 100644 index 88805e21de..0000000000 --- a/contributed_definitions/nyaml/NXmagnetic_kicker.yaml +++ /dev/null @@ -1,102 +0,0 @@ -category: base -doc: | - definition for a magnetic kicker. -type: group -NXmagnetic_kicker(NXobject): - description(NX_CHAR): - doc: | - extended description of the kicker. - beamline_distance(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - define position of beamline element relative to production target - timing(NX_FLOAT): - unit: NX_TIME - exists: ['min', '0', 'max', '1'] - doc: | - kicker timing as defined by ``description`` attribute - \@description: - type: NX_CHAR - set_current(NX_FLOAT): - unit: NX_CURRENT - exists: ['min', '0', 'max', '1'] - doc: | - current set on supply. - read_current(NXlog): - exists: ['min', '0', 'max', '1'] - doc: | - current read from supply. - value: - unit: NX_CURRENT - set_voltage(NX_FLOAT): - unit: NX_VOLTAGE - exists: ['min', '0', 'max', '1'] - doc: | - voltage set on supply. - read_voltage(NXlog): - exists: ['min', '0', 'max', '1'] - doc: | - voltage read from supply. - value: - unit: NX_VOLTAGE - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# c5a9c33c0597a8133cb27df4316cf2b9125d768e65326c2bf1a947583a0c00b4 -# -# -# -# -# definition for a magnetic kicker. -# -# extended description of the kicker. -# -# -# define position of beamline element relative to production target -# -# -# kicker timing as defined by ``description`` attribute -# -# -# -# current set on supply. -# -# -# current read from supply. -# -# -# -# voltage set on supply. -# -# -# voltage read from supply. -# -# -# diff --git a/contributed_definitions/nyaml/NXmatch_filter.yaml b/contributed_definitions/nyaml/NXmatch_filter.yaml deleted file mode 100644 index 8a6e681e1f..0000000000 --- a/contributed_definitions/nyaml/NXmatch_filter.yaml +++ /dev/null @@ -1,93 +0,0 @@ -category: base -doc: | - Base class of a filter to select members of a set based on their identifier. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_values: | - How many different match values does the filter specify. -type: group -NXmatch_filter(NXobject): - method(NX_CHAR): - doc: | - Definition of the logic what the filter yields: - Whitelist specifies which entries with said value to include. - Entries with all other values will be excluded. - - Blacklist specifies which entries with said value to exclude. - Entries with all other values will be included. - enumeration: [whitelist, blacklist] - match(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Array of values to filter according to method. If the match e.g. specifies - [1, 5, 6] and method is set to whitelist, only entries with values matching - 1, 5 or 6 will be processed. All other entries will be excluded. - dimensions: - rank: 1 - dim: [[1, n_values]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 322b49efa18bbb6ac9d5e06423484f19da0700ad333f6033733fc332e22b53fb -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# How many different match values does the filter specify. -# -# -# -# -# Base class of a filter to select members of a set based on their identifier. -# -# -# -# Definition of the logic what the filter yields: -# Whitelist specifies which entries with said value to include. -# Entries with all other values will be excluded. -# -# Blacklist specifies which entries with said value to exclude. -# Entries with all other values will be included. -# -# -# -# -# -# -# -# -# Array of values to filter according to method. If the match e.g. specifies -# [1, 5, 6] and method is set to whitelist, only entries with values matching -# 1, 5 or 6 will be processed. All other entries will be excluded. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXmicrostructure.yaml b/contributed_definitions/nyaml/NXmicrostructure.yaml deleted file mode 100644 index b98d12a3c0..0000000000 --- a/contributed_definitions/nyaml/NXmicrostructure.yaml +++ /dev/null @@ -1,1407 +0,0 @@ -category: base -doc: | - Base class to describe a microstructure, its structural aspects, associated descriptors, properties. - - Whether one uses a continuum or atomic scale description of materials, these are always a model only of - the true internal structure of a material. Such models are useful as they enable a coarse-graining and - categorizing of properties and representational aspects from which measured or simulated descriptions - can be correlated with properties, i.e. descriptor values. - - Keep in mind that most specimens are thermo-chemo-mechanically processed prior characterization. - Therefore, the characterized microstructure may not have probed the same structure as of the untreated - sample from which the region-of-interests on the specimen were sampled. - - Fields such as time and increment enable a quantification of the spatiotemporal evolution of a materials' - structure by using multiple instances of NXmicrostructure. Both measurements and simulation virtually - always sample this evolution. Most microscopy techniques support to generate only a two-dimensional - representation (projection) of the characterized material. Often materials are characterized only for - specific states or via sampling coarsely in time relative to the timescale at which the - physical phenomena take place. This is typically a compromise between the research questions at hand and technical surplus practical limitations. - - The term microstructural feature covers here crystals and all sorts of crystal defects within the material. - A key challenge with the description of representations and properties of microstructural features is that - features with different dimensionality exist and combinations of features of different dimensionality are - frequently expected to be documented with intuitive naming conventions using flat property lists. - For these key-value dictionaries often folksonomies are used. These can be based on ad hoc documentation - of such dictionaries in the literature and the metadata section of public data repositories. - - NXmicrostructure is an attempt to standardize these descriptions stronger. - - The descriptive variety is large especially for junctions. Like crystals and interfaces, junctions are features in - three-dimensional Euclidean space even if they are formed maybe only through a monolayer or pearl chain of atoms. - Either way the local atomic and electronic environment is different compared to the situation of an ideal crystal, - which gives typically rise to a plethora of configurations of which some yield useful properties. - - Like crystals and interfaces, junctions are assumed to represent groups of atoms that have specific descriptor values - which are different to other features. Taking an example, a triple junction is practically a three-dimensional defect as its atoms - are arranged in three-dimensional space but the characteristics of that defect can often be reduced to a lower-dimensional - description such as a triple point or a triple line. Therefore, different representations can be used to describe the location, - shape, and structure of the defect. As different types of crystal defects can interact, there is a substantial number of - in principle characterizable and representable objects. Take again a triple line as an example. It is a tubular feature built from three - adjoining interfaces. However, dislocations as line defects can interact with triple lines. Therefore, one can also argue that - along a triple line there can be dislocation-line-triple-line junctions, likewise dislocations form own junctions. - - It is not the aim of this base class to cover all these cases, rather this base class currently provides examples how the - typically most relevant types of features can be represented using a combination of base classes in NeXus. Currently, - these are crystals, interfaces, triple lines, quadruple junctions. - - The description attempt here took inspiration from `E. E. Underwood `_ - and E. E. Underwood's book on Quantitative Stereology published 1970 to categorize features based on their dimensionality. - - Identifiers can be defined either implicitly or explicitly. Identifiers for implicit indexing are defined - on the interval :math:`[identifier\_offset, identifier\_offset + cardinality - 1]`. - -# , and Volterra line defects (dislocation, disconnection, disclination). -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - - # one-dimensional sections of either projections (see below) or true one-dimensional cuts across a volume of material - n_c_one: | - The number of one-dimensional crystal projections - n_i_one: | - The number of one-dimensional interface projections - - # n__one, n__one are hypothetical scenarios such as line defect hitting right into a point - # two-dimensional projections of three-dimensional objects using E. E. Underwood notation - # crystals/grains are projections that are delineated by projections of interface, i.e. interface lines which meet at projections of triple lines aka triple points - n_c_two: | - The number of two-dimensional crystal projections - n_i_two: | - The number of two-dimensional interface projections - n_tj_two: | - The number of two-dimensional triple line projections - n_ld_two: | - The number of two-dimensional line defect projections - - # n__two is the hypothetical scenario when a point defect lies right in the projection plane - # three-dimensional real objects, volumetrically characterized - # crystals are delineated by interfaces that are delineated by triple lines that meet at quad junctions - n_c_three: | - The number of crystals (grain and sub-grain are exact synonyms for crystal). - n_i_three: | - The number of interfaces (grain boundary and phase boundary are subclasses of - interfaces). - n_tj_three: | - The number of triple junctions (triple line is a exact synonym for triple - junction, triple point is projection of a triple junction). - n_qj_three: | - The number of quadruple junctions. - - # n_ld_three: - # The number of line defects. - d: | - The dimensionality of the representation that needs to match the value for - configuration/dimensionality -type: group -NXmicrostructure(NXobject): - - # as e.g. a result of one grain reconstruction with an algorithm with MTex or the grain/phase i.e. interface network reconstruction software in commercial tools - # the idea is we may wish to run as many grain reconstructions as we want and add details about the processing used for each of them if needed - comment(NX_CHAR): - doc: | - Discouraged free-text field for leaving comments. - date(NX_DATE_TIME): - doc: | - ISO8601 with offset to local time zone included when a timestamp is required. - time(NX_NUMBER): - unit: NX_TIME - doc: | - Measured or simulated physical time stamp for this microstructure snapshot. - Not to be confused with wall-clock timing or profiling data. - iteration(NX_INT): - unit: NX_UNITLESS - doc: | - Iteration or increment counter. - configuration(NXprocess): - doc: | - Group where to store details about the configuration and parameterization of algorithms - used whereby microstructural features were identified. - dimensionality(NX_POSINT): - unit: NX_UNITLESS - doc: | - Dimensionality of Euclidean space in which the analysis is performed. - - This field can be used e.g. by a research data management system to identify - if the description specifies one-, two-, or three-dimensional microstructural representations. - enumeration: [1, 2, 3] - algorithm(NX_CHAR): - doc: | - Algorithm whereby interfaces between crystals were reconstructed. - - * Disorientation clustering groups nearby material points based on their crystallographic disorientation - * Fast multiscale clustering based on `D. Kushnir et al. `_ - * Markov chain clustering `F. Niessen et al. `_ - - # could also be used to specify algorithms for precipitate detection - enumeration: [unknown, disorientation_clustering, fast_multiscale_clustering, markov_chain_clustering] - disorientation_threshold(NX_NUMBER): - unit: NX_ANGLE - doc: | - Threshold to define at which disorientation angle to assume two crystalline regions have a significant - orientation difference that warrants to assume that there exists an interface between the two regions. - (NXprogram): - doc: | - The program with which the microstructure was reconstructed. - - # use controlled vocabulary terms grid, point, line, surface, volume, use singular term when instantiating - (NXcg_grid): - (NXcg_point_set): - (NXcg_polyline_set): - (NXcg_triangle_set): - (NXcg_polygon_set): - (NXcg_polyhedron_set): - - # constructive solid geometry to describe curved features - # (NXcsg): - # (NXcontinuous_function): - # examples for specific frequently discussed microstructural features - crystal(NXobject): - doc: | - One- or two-dimensional projections, or three-dimensional representations of crystals. - - An example for a volume bounded by other crystal defects. Crystals can be grains of - different phases, precipitates, dispersoids; there are many terms used specifically in - the materials engineering community. - - Typically, crystals are measured on the surface of a sample via optical or electron microscopy. - Using X-ray diffraction methods crystals can be observed in bulk specimens. - - Crystals are represented by a set of pixel, voxel, or polygons and their polyline boundaries. - In rare cases the volume bounded gets represented using constructive solid geometry approaches. - - # maybe some enum what this is - representation(NX_CHAR): - doc: | - Reference to an instance of: - - * :ref:`NXcg_polyline_set` for a one-dimensional representation as only a projection is available (like in linear intercept analysis) - * :ref:`NXcg_polygon_set` for a two-dimensional representation as only a projection is available (like in most experiments) - * :ref:`NXcg_polyhedron_set` or :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions - (like in computer simulations or 3D experiments) - - which represent the geometrical entities of the discretization. - number_of_crystals(NX_UINT): - unit: NX_UNITLESS - doc: | - How many crystals are distinguished. - - Crystals are listed irrespective of the phase to which these are assigned. - number_of_phases(NX_UINT): - unit: NX_UNITLESS - doc: | - How many phases are distinguished. - - Phases are typically distinguished based on statistical thermodynamics argument and crystal structure. - crystal_identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - First identifier whereby to identify crystals implicitly. - crystal_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Identifier whereby to identify each crystal explicitly. - dimensions: - rank: 1 - dim: [[1, i]] - phase_identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - First identifier whereby to identify phases implicitly. - phase_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Identifier whereby to identify phase for each crystal explicitly. - dimensions: - rank: 1 - dim: [[1, i]] - - # EXAMPLES FOR DESCRIPTOR VALUES, SUMMARY STATISTICS - boundary_contact(NX_BOOLEAN): - doc: | - True or false value, one for each crystal, to communicate whether that feature - makes contact with the edge of the ROI. - dimensions: - rank: 1 - dim: [[1, i]] - orientation_spread(NX_NUMBER): - unit: NX_ANGLE - doc: | - Average disorientation angle for each crystal between individual orientations - of that crystal evaluated as a summary statistic for all probed positions vs the - average disorientation of that crystal. - dimensions: - rank: 1 - dim: [[1, i]] - length(NX_NUMBER): - unit: NX_LENGTH - doc: | - Length of each crystal - dimensions: - rank: 1 - dim: [[1, i]] - area(NX_NUMBER): - unit: NX_AREA - doc: | - Area of each crystal. - dimensions: - rank: 1 - dim: [[1, i]] - volume(NX_NUMBER): - unit: NX_VOLUME - doc: | - Volume of each crystal - dimensions: - rank: 1 - dim: [[1, i]] - interface(NXobject): - doc: | - One- or two-dimensional projections or three-dimensional representation of interfaces - between crystals as topological entities equivalent to dual_junctions. - - An example for a surface defect. Most important are interfaces such as grain and phase boundaries - but factually interfaces also exist between the environment and crystals exposed at the - surface of the specimen or internal surfaces like between crystals, cracks, or pores. - representation(NX_CHAR): - doc: | - Reference to an instance of: - - * :ref:`NXcg_point_set` for a one-dimensional representation as only a projection is available (as in linear intercept analyses) - * :ref:`NXcg_polyline_set` or :ref:`NXcg_polygon_set` for a two-dimensional representation as only a projection is available (like in most experiments) - * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks - (like in computer simulations or 3D experiments) - - which represent the geometrical entities of the discretization. - number_of_interfaces(NX_UINT): - unit: NX_UNITLESS - doc: | - How many interfaces are distinguished. - identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - First identifier whereby to identify interfaces implicitly. - identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Identifier whereby to identify each interface explicitly. - dimensions: - rank: 1 - dim: [[1, i]] - - # topological view, interface specification through the the pair of crystals sharing an interface - crystal_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Set of pairs of crystal_identifier for each interface. - dimensions: - rank: 2 - dim: [[1, i], [2, 2]] - \@use_these: - type: NX_CHAR - doc: | - The specific identifiers whereby to resolve ambiguities. - phase_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Set of pairs of phase_identifier for each interface. - dimensions: - rank: 2 - dim: [[1, i], [2, 2]] - \@use_these: - type: NX_CHAR - doc: | - The specific identifiers whereby to resolve ambiguities. - - # topological view, interface specification through the pair of triple line projections (i.e. triple points) adjoining the interface - triple_junction_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Set of pairs of triple_junction_identifier for each interface. - dimensions: - rank: 2 - dim: [[1, i], [2, 2]] - \@use_these: - type: NX_CHAR - doc: | - The specific identifiers whereby to resolve ambiguities. - - # EXAMPLES FOR DESCRIPTOR VALUES - boundary_contact(NX_BOOLEAN): - doc: | - True or false value, one for each crystal, to communicate whether that feature - makes contact with the edge of the ROI. - dimensions: - rank: 1 - dim: [[1, i]] - surface_energy(NX_NUMBER): - unit: NX_ANY - doc: | - Gibbs free surface energy for each interface. - dimensions: - rank: 1 - dim: [[1, i]] - mobility(NX_NUMBER): - unit: NX_ANY - doc: | - Non-intrinsic mobility of each interface. - dimensions: - rank: 1 - dim: [[1, i]] - length(NX_NUMBER): - unit: NX_LENGTH - doc: | - The length of each interface if only projections are available. - - This is not necessarily the same as the length of the individual - polyline segments whereby the interface is discretized. - dimensions: - rank: 1 - dim: [[1, i]] - area(NX_NUMBER): - unit: NX_AREA - doc: | - The surface area of all interfaces. - dimensions: - rank: 1 - dim: [[1, i]] - triple_junction(NXobject): - doc: | - Projections or representations of junctions at which three interfaces meet. - - An example for a line defect. Triple junctions are characterized as triple lines or triple points as their projections, - or junctions observed between crystals (at the specimen surface exposed to an environment) - (including wetting phenomena) or inside the specimen (crack, pores). - representation(NX_CHAR): - doc: | - Reference to an instance of: - - * :ref:`NXcg_point_set` for a one-dimensional representation as only a projection is available (like in most experiments) - * :ref:`NXcg_polyline_set` for a two-dimensional representation as only a projection is available - * :ref:`NXcg_polygon_set` for a two-dimensional representation in the (seldom) case of sufficient spatial resolution - and the line in the projection plane or cases where triple junction locations are approximated e.g. using a set of triangles - * :ref:`NXcg_polyhedron_set` for a three-dimensional representation via e.g. a representation of Voronoi cells about atoms - * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks - - which represent the geometrical entities of the discretization. - number_of_junctions(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of triple junctions. - identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - First identifier to identify triple junctions implicitly. - identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Identifier to identify each triple junction explicitly. - dimensions: - rank: 1 - dim: [[1, i]] - - # various strategies are used to talk about aspects of triple junctions, some examples follow - # example i) triple points as projections of triple lines have locations - location(NX_INT): - unit: NX_UNITLESS - doc: | - Set of identifier for positions whereby to identify the location of each - junction. - dimensions: - rank: 1 - dim: [[1, i]] - \@use_these: - type: NX_CHAR - doc: | - The specific identifiers whereby to resolve ambiguities. - position(NX_INT): - unit: NX_LENGTH - doc: | - Explicit positions. - dimensions: - rank: 2 - dim: [[1, i], [2, d]] - crystal_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Set of tuples of identifier of crystals connected to the junction for each - triple junction. - dimensions: - rank: 2 - dim: [[1, i], [2, 3]] - - # example ii) three interfaces (maybe projections of them) meet at a triple junction - interface_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Set of tuples of identifier of interfaces connected to the junction for each - triple junction. - dimensions: - rank: 2 - dim: [[1, i], [2, 3]] - \@use_these: - type: NX_CHAR - doc: | - The specific interface identifiers whereby to resolve ambiguities. - - # example iii) three polyline segments meet at a triple junction, polyline segments of discretized interface segments - polyline_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Set of tuples of identifier for polyline segments connected to the junction for - each triple junction. - dimensions: - rank: 2 - dim: [[1, i], [2, 3]] - \@use_these: - type: NX_CHAR - doc: | - The specific polyline identifiers whereby to resolve ambiguities. - - # example iv) e.g. crystals of three different phases meet at a triple junction - # EXAMPLES FOR DESCRIPTOR VALUES - boundary_contact(NX_BOOLEAN): - doc: | - True or false value, one for each crystal, to communicate whether that feature - makes contact with the edge of the ROI. - dimensions: - rank: 1 - dim: [[1, i]] - line_energy(NX_NUMBER): - unit: NX_ANY - doc: | - Specific line energy of each triple junction - dimensions: - rank: 1 - dim: [[1, i]] - mobility(NX_NUMBER): - unit: NX_ANY - doc: | - Non-intrinsic mobility of each triple junction. - dimensions: - rank: 1 - dim: [[1, i]] - length(NX_NUMBER): - unit: NX_LENGTH - doc: | - The length of each triple junction. - - This is not necessarily the same as the length of the individual - polyline segments whereby the junction is discretized. - dimensions: - rank: 1 - dim: [[1, i]] - volume(NX_NUMBER): - unit: NX_VOLUME - doc: | - The volume of the each triple junction - dimensions: - rank: 1 - dim: [[1, i]] - quadruple_junction(NXobject): - doc: | - Quadruple junctions as a region where four crystals meet. - - An example for a point defect. - representation(NX_CHAR): - doc: | - Reference to an instance of: - - * :ref:`NXcg_point_set` - * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks - number_of_junctions(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of quadruple junctions. - identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - First identifier to identify quadruple junctions implicitly. - identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Identifier to identify each quadruple junction explicitly. - dimensions: - rank: 1 - dim: [[1, i]] - - # different scenarios can be envised how quadruple_junctions are discussed - # example i) quadruple point locations explicitly - location(NX_INT): - unit: NX_UNITLESS - doc: | - Set of identifier for positions whereby to identify the location of each - junction. - dimensions: - rank: 1 - dim: [[1, i]] - \@use_these: - type: NX_CHAR - doc: | - The specific point identifier whereby to resolve ambiguities. - position(NX_INT): - unit: NX_LENGTH - doc: | - Explicit positions. - dimensions: - rank: 2 - dim: [[1, i], [2, 3]] - - # example ii) four crystals meet at a quadruple junction - crystal_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Set of tuples of identifier of crystals connected to the junction for each - junction. - dimensions: - rank: 2 - dim: [[1, i], [2, 4]] - \@use_these: - type: NX_CHAR - doc: | - The specific identifier to instances of crystal identifiers whereby to resolve - ambiguities. - interface_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Set of tuples of identifier of interfaces connected to the junction for each - junction. - dimensions: - rank: 2 - dim: [[1, i], [2, 4]] - \@use_these: - type: NX_CHAR - doc: | - The specific identifier to instances of interface identifiers whereby to resolve - ambiguities. - - # example iii) e.g. three triple lines meet at a quadruple junction - triple_junction_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Set of tuples of identifier for triple junctions connected to the junction for - each quadruple junction. - dimensions: - rank: 2 - dim: [[1, i], [2, 3]] - \@use_these: - type: NX_CHAR - doc: | - The specific identifier to instances of triple junction identifiers whereby to - resolve ambiguities. - - # example iv) crystals of eventually four different phases meet at a quadruple junction - phase_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Set of tuples of identifier for phases of crystals connected to the junction for - each quadruple junction. - dimensions: - rank: 2 - dim: [[1, i], [2, 4]] - \@use_these: - type: NX_CHAR - doc: | - The specific identifier to instances of phase identifier whereby to resolve - ambiguities. - - # EXAMPLES FOR DESCRIPTOR VALUES - boundary_contact(NX_BOOLEAN): - doc: | - True or false value, one for each crystal, to communicate whether that feature - makes contact with the edge of the ROI. - dimensions: - rank: 1 - dim: [[1, i]] - energy(NX_NUMBER): - unit: NX_ANY - doc: | - Energy of the quadruple_junction as a defect. - dimensions: - rank: 1 - dim: [[1, i]] - mobility(NX_NUMBER): - unit: NX_ANY - doc: | - Non-intrinsic mobility of each quadruple_junction. - dimensions: - rank: 1 - dim: [[1, i]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 99f7c16210448edd29caaa14f77afe6d4c0920fb7150bea6407d096d7b98a513 -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# -# The number of one-dimensional crystal projections -# -# -# -# -# The number of one-dimensional interface projections -# -# -# -# -# -# The number of two-dimensional crystal projections -# -# -# -# -# The number of two-dimensional interface projections -# -# -# -# -# The number of two-dimensional triple line projections -# -# -# -# -# The number of two-dimensional line defect projections -# -# -# -# -# -# The number of crystals (grain and sub-grain are exact synonyms for crystal). -# -# -# -# -# The number of interfaces (grain boundary and phase boundary are subclasses of -# interfaces). -# -# -# -# -# The number of triple junctions (triple line is a exact synonym for triple -# junction, triple point is projection of a triple junction). -# -# -# -# -# The number of quadruple junctions. -# -# -# -# -# -# The dimensionality of the representation that needs to match the value for -# configuration/dimensionality -# -# -# -# -# Base class to describe a microstructure, its structural aspects, associated descriptors, properties. -# -# Whether one uses a continuum or atomic scale description of materials, these are always a model only of -# the true internal structure of a material. Such models are useful as they enable a coarse-graining and -# categorizing of properties and representational aspects from which measured or simulated descriptions -# can be correlated with properties, i.e. descriptor values. -# -# Keep in mind that most specimens are thermo-chemo-mechanically processed prior characterization. -# Therefore, the characterized microstructure may not have probed the same structure as of the untreated -# sample from which the region-of-interests on the specimen were sampled. -# -# Fields such as time and increment enable a quantification of the spatiotemporal evolution of a materials' -# structure by using multiple instances of NXmicrostructure. Both measurements and simulation virtually -# always sample this evolution. Most microscopy techniques support to generate only a two-dimensional -# representation (projection) of the characterized material. Often materials are characterized only for -# specific states or via sampling coarsely in time relative to the timescale at which the -# physical phenomena take place. This is typically a compromise between the research questions at hand and technical surplus practical limitations. -# -# The term microstructural feature covers here crystals and all sorts of crystal defects within the material. -# A key challenge with the description of representations and properties of microstructural features is that -# features with different dimensionality exist and combinations of features of different dimensionality are -# frequently expected to be documented with intuitive naming conventions using flat property lists. -# For these key-value dictionaries often folksonomies are used. These can be based on ad hoc documentation -# of such dictionaries in the literature and the metadata section of public data repositories. -# -# NXmicrostructure is an attempt to standardize these descriptions stronger. -# -# The descriptive variety is large especially for junctions. Like crystals and interfaces, junctions are features in -# three-dimensional Euclidean space even if they are formed maybe only through a monolayer or pearl chain of atoms. -# Either way the local atomic and electronic environment is different compared to the situation of an ideal crystal, -# which gives typically rise to a plethora of configurations of which some yield useful properties. -# -# Like crystals and interfaces, junctions are assumed to represent groups of atoms that have specific descriptor values -# which are different to other features. Taking an example, a triple junction is practically a three-dimensional defect as its atoms -# are arranged in three-dimensional space but the characteristics of that defect can often be reduced to a lower-dimensional -# description such as a triple point or a triple line. Therefore, different representations can be used to describe the location, -# shape, and structure of the defect. As different types of crystal defects can interact, there is a substantial number of -# in principle characterizable and representable objects. Take again a triple line as an example. It is a tubular feature built from three -# adjoining interfaces. However, dislocations as line defects can interact with triple lines. Therefore, one can also argue that -# along a triple line there can be dislocation-line-triple-line junctions, likewise dislocations form own junctions. -# -# It is not the aim of this base class to cover all these cases, rather this base class currently provides examples how the -# typically most relevant types of features can be represented using a combination of base classes in NeXus. Currently, -# these are crystals, interfaces, triple lines, quadruple junctions. -# -# The description attempt here took inspiration from `E. E. Underwood <https://doi.org/10.1111/j.1365-2818.1972.tb03709.x>`_ -# and E. E. Underwood's book on Quantitative Stereology published 1970 to categorize features based on their dimensionality. -# -# Identifiers can be defined either implicitly or explicitly. Identifiers for implicit indexing are defined -# on the interval :math:`[identifier\_offset, identifier\_offset + cardinality - 1]`. -# -# -# -# -# Discouraged free-text field for leaving comments. -# -# -# -# -# ISO8601 with offset to local time zone included when a timestamp is required. -# -# -# -# -# Measured or simulated physical time stamp for this microstructure snapshot. -# Not to be confused with wall-clock timing or profiling data. -# -# -# -# -# Iteration or increment counter. -# -# -# -# -# Group where to store details about the configuration and parameterization of algorithms -# used whereby microstructural features were identified. -# -# -# -# Dimensionality of Euclidean space in which the analysis is performed. -# -# This field can be used e.g. by a research data management system to identify -# if the description specifies one-, two-, or three-dimensional microstructural representations. -# -# -# -# -# -# -# -# -# -# Algorithm whereby interfaces between crystals were reconstructed. -# -# * Disorientation clustering groups nearby material points based on their crystallographic disorientation -# * Fast multiscale clustering based on `D. Kushnir et al. <https://doi.org/10.1016/j.patcog.2006.04.007>`_ -# * Markov chain clustering `F. Niessen et al. <https://doi.org/10.1107/S1600576721011560>`_ -# -# -# -# -# -# -# -# -# -# -# -# Threshold to define at which disorientation angle to assume two crystalline regions have a significant -# orientation difference that warrants to assume that there exists an interface between the two regions. -# -# -# -# -# The program with which the microstructure was reconstructed. -# -# -# -# -# -# -# -# -# -# -# -# -# -# One- or two-dimensional projections, or three-dimensional representations of crystals. -# -# An example for a volume bounded by other crystal defects. Crystals can be grains of -# different phases, precipitates, dispersoids; there are many terms used specifically in -# the materials engineering community. -# -# Typically, crystals are measured on the surface of a sample via optical or electron microscopy. -# Using X-ray diffraction methods crystals can be observed in bulk specimens. -# -# Crystals are represented by a set of pixel, voxel, or polygons and their polyline boundaries. -# In rare cases the volume bounded gets represented using constructive solid geometry approaches. -# -# -# -# -# Reference to an instance of: -# -# * :ref:`NXcg_polyline_set` for a one-dimensional representation as only a projection is available (like in linear intercept analysis) -# * :ref:`NXcg_polygon_set` for a two-dimensional representation as only a projection is available (like in most experiments) -# * :ref:`NXcg_polyhedron_set` or :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions -# (like in computer simulations or 3D experiments) -# -# which represent the geometrical entities of the discretization. -# -# -# -# -# How many crystals are distinguished. -# -# Crystals are listed irrespective of the phase to which these are assigned. -# -# -# -# -# How many phases are distinguished. -# -# Phases are typically distinguished based on statistical thermodynamics argument and crystal structure. -# -# -# -# -# First identifier whereby to identify crystals implicitly. -# -# -# -# -# Identifier whereby to identify each crystal explicitly. -# -# -# -# -# -# -# -# First identifier whereby to identify phases implicitly. -# -# -# -# -# Identifier whereby to identify phase for each crystal explicitly. -# -# -# -# -# -# -# -# -# True or false value, one for each crystal, to communicate whether that feature -# makes contact with the edge of the ROI. -# -# -# -# -# -# -# -# Average disorientation angle for each crystal between individual orientations -# of that crystal evaluated as a summary statistic for all probed positions vs the -# average disorientation of that crystal. -# -# -# -# -# -# -# -# Length of each crystal -# -# -# -# -# -# -# -# Area of each crystal. -# -# -# -# -# -# -# -# Volume of each crystal -# -# -# -# -# -# -# -# -# One- or two-dimensional projections or three-dimensional representation of interfaces -# between crystals as topological entities equivalent to dual_junctions. -# -# An example for a surface defect. Most important are interfaces such as grain and phase boundaries -# but factually interfaces also exist between the environment and crystals exposed at the -# surface of the specimen or internal surfaces like between crystals, cracks, or pores. -# -# -# -# Reference to an instance of: -# -# * :ref:`NXcg_point_set` for a one-dimensional representation as only a projection is available (as in linear intercept analyses) -# * :ref:`NXcg_polyline_set` or :ref:`NXcg_polygon_set` for a two-dimensional representation as only a projection is available (like in most experiments) -# * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks -# (like in computer simulations or 3D experiments) -# -# which represent the geometrical entities of the discretization. -# -# -# -# -# How many interfaces are distinguished. -# -# -# -# -# First identifier whereby to identify interfaces implicitly. -# -# -# -# -# Identifier whereby to identify each interface explicitly. -# -# -# -# -# -# -# -# -# Set of pairs of crystal_identifier for each interface. -# -# -# -# -# -# -# -# The specific identifiers whereby to resolve ambiguities. -# -# -# -# -# -# Set of pairs of phase_identifier for each interface. -# -# -# -# -# -# -# -# The specific identifiers whereby to resolve ambiguities. -# -# -# -# -# -# -# Set of pairs of triple_junction_identifier for each interface. -# -# -# -# -# -# -# -# The specific identifiers whereby to resolve ambiguities. -# -# -# -# -# -# -# True or false value, one for each crystal, to communicate whether that feature -# makes contact with the edge of the ROI. -# -# -# -# -# -# -# -# Gibbs free surface energy for each interface. -# -# -# -# -# -# -# -# Non-intrinsic mobility of each interface. -# -# -# -# -# -# -# -# The length of each interface if only projections are available. -# -# This is not necessarily the same as the length of the individual -# polyline segments whereby the interface is discretized. -# -# -# -# -# -# -# -# The surface area of all interfaces. -# -# -# -# -# -# -# -# -# Projections or representations of junctions at which three interfaces meet. -# -# An example for a line defect. Triple junctions are characterized as triple lines or triple points as their projections, -# or junctions observed between crystals (at the specimen surface exposed to an environment) -# (including wetting phenomena) or inside the specimen (crack, pores). -# -# -# -# Reference to an instance of: -# -# * :ref:`NXcg_point_set` for a one-dimensional representation as only a projection is available (like in most experiments) -# * :ref:`NXcg_polyline_set` for a two-dimensional representation as only a projection is available -# * :ref:`NXcg_polygon_set` for a two-dimensional representation in the (seldom) case of sufficient spatial resolution -# and the line in the projection plane or cases where triple junction locations are approximated e.g. using a set of triangles -# * :ref:`NXcg_polyhedron_set` for a three-dimensional representation via e.g. a representation of Voronoi cells about atoms -# * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks -# -# which represent the geometrical entities of the discretization. -# -# -# -# -# Number of triple junctions. -# -# -# -# -# First identifier to identify triple junctions implicitly. -# -# -# -# -# Identifier to identify each triple junction explicitly. -# -# -# -# -# -# -# -# -# Set of identifier for positions whereby to identify the location of each -# junction. -# -# -# -# -# -# -# The specific identifiers whereby to resolve ambiguities. -# -# -# -# -# -# Explicit positions. -# -# -# -# -# -# -# -# -# Set of tuples of identifier of crystals connected to the junction for each -# triple junction. -# -# -# -# -# -# -# -# -# -# Set of tuples of identifier of interfaces connected to the junction for each -# triple junction. -# -# -# -# -# -# -# -# The specific interface identifiers whereby to resolve ambiguities. -# -# -# -# -# -# -# Set of tuples of identifier for polyline segments connected to the junction for -# each triple junction. -# -# -# -# -# -# -# -# The specific polyline identifiers whereby to resolve ambiguities. -# -# -# -# -# -# -# True or false value, one for each crystal, to communicate whether that feature -# makes contact with the edge of the ROI. -# -# -# -# -# -# -# -# Specific line energy of each triple junction -# -# -# -# -# -# -# -# Non-intrinsic mobility of each triple junction. -# -# -# -# -# -# -# -# The length of each triple junction. -# -# This is not necessarily the same as the length of the individual -# polyline segments whereby the junction is discretized. -# -# -# -# -# -# -# -# The volume of the each triple junction -# -# -# -# -# -# -# -# -# Quadruple junctions as a region where four crystals meet. -# -# An example for a point defect. -# -# -# -# Reference to an instance of: -# -# * :ref:`NXcg_point_set` -# * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks -# -# -# -# -# Number of quadruple junctions. -# -# -# -# -# First identifier to identify quadruple junctions implicitly. -# -# -# -# -# Identifier to identify each quadruple junction explicitly. -# -# -# -# -# -# -# -# -# Set of identifier for positions whereby to identify the location of each -# junction. -# -# -# -# -# -# -# The specific point identifier whereby to resolve ambiguities. -# -# -# -# -# -# Explicit positions. -# -# -# -# -# -# -# -# -# -# Set of tuples of identifier of crystals connected to the junction for each -# junction. -# -# -# -# -# -# -# -# The specific identifier to instances of crystal identifiers whereby to resolve -# ambiguities. -# -# -# -# -# -# Set of tuples of identifier of interfaces connected to the junction for each -# junction. -# -# -# -# -# -# -# -# The specific identifier to instances of interface identifiers whereby to resolve -# ambiguities. -# -# -# -# -# -# -# Set of tuples of identifier for triple junctions connected to the junction for -# each quadruple junction. -# -# -# -# -# -# -# -# The specific identifier to instances of triple junction identifiers whereby to -# resolve ambiguities. -# -# -# -# -# -# -# Set of tuples of identifier for phases of crystals connected to the junction for -# each quadruple junction. -# -# -# -# -# -# -# -# The specific identifier to instances of phase identifier whereby to resolve -# ambiguities. -# -# -# -# -# -# -# True or false value, one for each crystal, to communicate whether that feature -# makes contact with the edge of the ROI. -# -# -# -# -# -# -# -# Energy of the quadruple_junction as a defect. -# -# -# -# -# -# -# -# Non-intrinsic mobility of each quadruple_junction. -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml deleted file mode 100644 index 39de6ebda0..0000000000 --- a/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml +++ /dev/null @@ -1,657 +0,0 @@ -category: application -doc: | - Application definition for configuring GraGLeS. - - GraGLeS is a continuum-scale model for shared-memory-parallelized simulations - of the isothermal evolution of 2D and 3D grain boundary networks with a level-set approach. - CPU parallelization is achieved with OpenMP. - - The code has been implemented by C. Mießen in the group of G. Gottstein - at the Institute für Metallkunde und Metallphysik, RWTH Aachen University. - - Details of the model are summarized in `C. Mießen `_. - -# symbols: -# type: group -type: group -NXmicrostructure_gragles_config(NXobject): - (NXentry): - definition(NX_CHAR): - enumeration: [NXmicrostructure_gragles_config] - simulation_identifier(NX_UINT): - doc: | - Simulation ID as an alias to refer to this simulation. - description(NX_CHAR): - doc: | - Discouraged free-text field to add further details to the computation. - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - exists: recommended - profiling(NXcs_profiling): - exists: optional - (NXuser): - exists: ['min', '0', 'max', 'unbounded'] - program1(NXprogram): - program_name: - \@version: - \@url: - exists: recommended - environment(NXobject): - exists: optional - doc: | - Programs and libraries representing the computational environment - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - discretization(NXmicrostructure): - - # [read_from_file] # poisson_voronoi_tessellation - # 0, E_READ_FROM_FILE, 1, E_GENERATE_WITH_VORONOY, 2, E_READ_VERTEX, // The edges need to be ordered 3, E_GENERATE_TESTCASE, 4, E_READ_VOXELIZED_MICROSTRUCTURE - # read the next three from input file - # Microstructure.SimID.10.GrainIDs.2D.1188.raw all in config file - # Microstructure.SimID.10.uds - # 0 0, E_CUBIC, 1, E_HEXAGONAL fish from config file - grid(NXserialized): - doc: | - From which file should the microstructure be instantiated. - type: - path: - algorithm: - checksum: - edge_length(NX_FLOAT): - unit: NX_LENGTH - doc: | - The formulation of mean curvature flow in the GraGLeS model is scale invariant. - Therefore, the discretization has to be scaled to the actual physical length - of the simulation domain (ve, ROI). - For GraGLeS the discretization is always a square or cubic axis-aligned - bounding box with a regular tiling into material points - (either squares or cubes respectively). - - Edge_length is the length of the entire domain along its edge not - the length of the Wigner-Seitz cell about each material point! - sampling(NXobject): - doc: | - Configuration when snapshots of the system should be taken. - - Keep in mind that essentially geometry snapshot data store the - polylines and polyhedra of all grains which can take substantial disk - space. - system(NX_UINT): - unit: NX_UNITLESS - doc: | - Generate a snapshot of the properties of the grains to follow - the evolution of the microstructure every :math:`n`-th iteration. - Setting zero causes that no property snapshots are taken. - geometry(NX_UINT): - unit: NX_UNITLESS - doc: | - Generate a snapshot of the geometry of the entire grain boundary network - every :math:`n`-th iteration. Setting zero instructs to store no geometry data. - - # 31 no more sampling - # 1 - simulation_control(NXobject): - doc: | - Configuration when the simulation should be stopped in a controlled manner. - Whichever criterion is fulfilled first triggers the controlled stop of - and termination of GraGLeS. - number_of_grains(NX_UINT): - unit: NX_UNITLESS - doc: | - The simulation stops if the total number of grains - becomes smaller than this criterion. - number_of_iterations(NX_UINT): - unit: NX_UNITLESS - doc: | - The simulation stops if more iterations than this criterion have been computed. - numerics(NXobject): - doc: | - Configuration of numerical details of the solver. - - # use proper environment variable number_of_threads(NX_UINT): # obsolete set 01 16 - convolution_mode(NX_CHAR): - doc: | - Which type of convolution kernel and model is used. - enumeration: [gaussian, laplace, laplace_ritchardson] - time_slope(NX_FLOAT): - unit: NX_ANY - doc: | - Constant to calibrate the real time scaling of the simulation. - - # when taking the E_GAUSSIAN convolution mode set the TimeSlopeFactor explicitly here, default Miessen, Liesenjohann was 0.8359-\-> - # 0 - # 12991 # read from file - # discretization(NX_UINT) # 15 - # 15 - # domain_border_size(NX_UINT): # 7 - # 0 - # 0, Energies defined by misorientation, 1, GB Energies and mobilities clambed to 1.0 but uses sectors and Triplejunction mobilities, - # 2, GB Energies clambed to 0.3 or 0.6 / mobilities clambed to 1.0 - use Texture == false - # 0 # 0, E_NO_PROJECT, 1 E_TRIPLE_JUNCTION_DRAG_SINGLE (fixes outermost tj at, 2 empty) - # 1 # 0, E_ITERATIVE, 1, E_SQUARES - # 0.0 - # - grid_coarsement(NXobject): - doc: | - Configuration of the grid coarsement algorithm whereby the representation - of the system is continuously rediscretized such that on average grains - are discretized with discretization many material points along each - direction. - - Grid coarsement can reduce the computational costs substantially although - it cannot be ruled out completely that the rediscretizing may have an effect - on the system evolution. Without grid coarsement the total number of material - points to consider stays the same throughout the simulation. - discretization(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of material points along each direction to discretize the - average grain. The larger this value is chosen the finer the curvature - details are that can be resolved but also the longer the simulation - takes. - is_active(NX_BOOLEAN): - doc: | - If true grid coarsement is active, otherwise it is not. - gradient(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Fraction how strongly the number of grains has to reduce - to trigger a grid coarsement step in an iteration. - - # the next only guru i.e. in C++ code configurable options - # 3 - # 2 - # 0 # 0, DEFAULT, 1 skips comparison and let grains shring isolated - grain_boundary_mobility(NXobject): - doc: | - Physically-based model of the assumed mobility of the grain boundaries. - - Grain boundary mobility is not an intrinsic property of a grain boundary but system-dependent - especially as grain boundaries in reality are decorated with defects as a consequence of which - the actual mobility is a combination of the mobility of the individual defects and the attached - boundary patches. Grain boundaries have different degrees of microscopic freedom. - Therefore, their mobility follows a distribution. - - # 0 - # 0 # - model(NX_CHAR): - doc: | - Fundamental model how :math:`m` is assumed a function of the disorientation - angle :math:`\Theta`. - enumeration: [rollett_holm] - - # For rollett_holm :math:`m(\Theta) = m_0 \cdot (1 - c_1 * exp(-c_2 \cdot \frac{\Theta}{15}^{c_3}))`. - m_null(NX_FLOAT): - unit: NX_ANY - doc: | - The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed - temperature. GraGLeS was developed for modelling isothermal annealing. - c_one(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not one. - - # 7.5e-14 - c_two(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Mobility scaling factor :math:`c_2`. Typically 5. - c_three(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Mobility scaling factor :math:`c_3`. Typically 9. - grain_boundary_energy(NXobject): - doc: | - Physically-based model of the assumed grain boundary surface energy. - - Like for the grain boundary mobility, defects cause a distribution of energies for the - patches of which the boundary is composed. In practice a too complicated dependency - of the energy and mobility model is observed as a function of the type and chemical - decoration of the defects. Therefore, simplifying assumptions are typically made. - type(NX_CHAR): - doc: | - Fundamental type of assumption if energies are considered isotropic or not. - enumeration: [isotropic, anisotropic] - model(NX_CHAR): - doc: | - Fundamental model how :math:`\gamma` is assumed a function of the disorientation - angle :math:`\Theta`. - enumeration: [read_shockley] - gamma(NX_FLOAT): - unit: NX_ANY - doc: | - Mean grain boundary surface energy that is assumed a function of the - disorientation angle :math:`\Theta` of the adjoining grains :math:`\gamma(\Theta)`. - This value factorizes the curvature_driving_force model. - - # For GraGLeS :math:`\gamma(\Theta) = \{\begin{array}1 \text{for} \Theta > 1. \\ 0.01 \text{for} \Theta \leq 1.\end{array}`. - # 1.0 - # 0.01 - # - curvature_driving_force(NXobject): - doc: | - A continuum-scale curvature of an interface causes the interface to - migrate towards the center of the curvature radius. - is_active(NX_BOOLEAN): - doc: | - If true the curvature_driving_force is considered, otherwise it is not. - stored_elastic_energy(NXobject): - doc: | - A continuum-scale difference of the stored elastic energy in dislocation - configurations across a grain boundary can exert a driving force on the - grain boundary such that the boundary migrates into the volume with the - higher stored elastic energy. - is_active(NX_BOOLEAN): - doc: | - If true the dislocation_driving_force is considered, otherwise it is not. - line_energy(NX_FLOAT): - unit: NX_ANY - doc: | - Prefactor :math:`0.5Gb^2` that factorizes the average - stored elastic energy per length dislocation line. - magnetic_field(NXobject): - doc: | - In case of an applied magnetic field, a difference of the magnetic - susceptibility can exert a driving force on the grain boundary such that - the boundary migrates into the volume with the higher magnetic energy. - is_active(NX_BOOLEAN): - doc: | - If true the magnetic_driving_force is considered, otherwise it is not. - - # MagneticField.xml - # https://github.com/GraGLeS/GraGLeS2D/blob/master/params/MagneticField.xml - triple_line_mobility(NXobject): - doc: | - A triple line mediates the atomic arrangement differences between three - interface patches. Therefore, the triple line is a defect that may not - have the same mobility as adjoining grain boundaries and thus it may - exert what can be conceptualized as a drag (resistance) to the motion - of the adjoining interface patches. - drag(NX_FLOAT): - unit: NX_ANY - doc: | - Assumed triple junction drag. - - # 1.0e10 - # isotropic, anisotropic - # 1 - # 1 25 - # - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# be9cd1aa11b17602615b46e4cf6a600e5b937fdc8480416708388bd9e7f81d9c -# -# -# -# -# -# -# Application definition for configuring GraGLeS. -# -# GraGLeS is a continuum-scale model for shared-memory-parallelized simulations -# of the isothermal evolution of 2D and 3D grain boundary networks with a level-set approach. -# CPU parallelization is achieved with OpenMP. -# -# The code has been implemented by C. Mießen in the group of G. Gottstein -# at the Institute für Metallkunde und Metallphysik, RWTH Aachen University. -# -# Details of the model are summarized in `C. Mießen <https://publications.rwth-aachen.de/record/709678>`_. -# -# -# -# -# -# -# -# -# -# Simulation ID as an alias to refer to this simulation. -# -# -# -# -# Discouraged free-text field to add further details to the computation. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Programs and libraries representing the computational environment -# -# -# -# -# -# -# -# -# -# -# -# From which file should the microstructure be instantiated. -# -# -# -# -# -# -# -# -# The formulation of mean curvature flow in the GraGLeS model is scale invariant. -# Therefore, the discretization has to be scaled to the actual physical length -# of the simulation domain (ve, ROI). -# For GraGLeS the discretization is always a square or cubic axis-aligned -# bounding box with a regular tiling into material points -# (either squares or cubes respectively). -# -# Edge_length is the length of the entire domain along its edge not -# the length of the Wigner-Seitz cell about each material point! -# -# -# -# -# -# Configuration when snapshots of the system should be taken. -# -# Keep in mind that essentially geometry snapshot data store the -# polylines and polyhedra of all grains which can take substantial disk -# space. -# -# -# -# Generate a snapshot of the properties of the grains to follow -# the evolution of the microstructure every :math:`n`-th iteration. -# Setting zero causes that no property snapshots are taken. -# -# -# -# -# Generate a snapshot of the geometry of the entire grain boundary network -# every :math:`n`-th iteration. Setting zero instructs to store no geometry data. -# -# -# -# -# -# -# Configuration when the simulation should be stopped in a controlled manner. -# Whichever criterion is fulfilled first triggers the controlled stop of -# and termination of GraGLeS. -# -# -# -# The simulation stops if the total number of grains -# becomes smaller than this criterion. -# -# -# -# -# The simulation stops if more iterations than this criterion have been computed. -# -# -# -# -# -# Configuration of numerical details of the solver. -# -# -# -# -# Which type of convolution kernel and model is used. -# -# -# -# -# -# -# -# -# -# Constant to calibrate the real time scaling of the simulation. -# -# -# -# -# -# -# Configuration of the grid coarsement algorithm whereby the representation -# of the system is continuously rediscretized such that on average grains -# are discretized with discretization many material points along each -# direction. -# -# Grid coarsement can reduce the computational costs substantially although -# it cannot be ruled out completely that the rediscretizing may have an effect -# on the system evolution. Without grid coarsement the total number of material -# points to consider stays the same throughout the simulation. -# -# -# -# Number of material points along each direction to discretize the -# average grain. The larger this value is chosen the finer the curvature -# details are that can be resolved but also the longer the simulation -# takes. -# -# -# -# -# If true grid coarsement is active, otherwise it is not. -# -# -# -# -# Fraction how strongly the number of grains has to reduce -# to trigger a grid coarsement step in an iteration. -# -# -# -# -# -# -# Physically-based model of the assumed mobility of the grain boundaries. -# -# Grain boundary mobility is not an intrinsic property of a grain boundary but system-dependent -# especially as grain boundaries in reality are decorated with defects as a consequence of which -# the actual mobility is a combination of the mobility of the individual defects and the attached -# boundary patches. Grain boundaries have different degrees of microscopic freedom. -# Therefore, their mobility follows a distribution. -# -# -# -# -# Fundamental model how :math:`m` is assumed a function of the disorientation -# angle :math:`\Theta`. -# -# -# -# -# -# -# -# -# The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed -# temperature. GraGLeS was developed for modelling isothermal annealing. -# -# -# -# -# Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not one. -# -# -# -# -# -# Mobility scaling factor :math:`c_2`. Typically 5. -# -# -# -# -# Mobility scaling factor :math:`c_3`. Typically 9. -# -# -# -# -# -# Physically-based model of the assumed grain boundary surface energy. -# -# Like for the grain boundary mobility, defects cause a distribution of energies for the -# patches of which the boundary is composed. In practice a too complicated dependency -# of the energy and mobility model is observed as a function of the type and chemical -# decoration of the defects. Therefore, simplifying assumptions are typically made. -# -# -# -# Fundamental type of assumption if energies are considered isotropic or not. -# -# -# -# -# -# -# -# -# Fundamental model how :math:`\gamma` is assumed a function of the disorientation -# angle :math:`\Theta`. -# -# -# -# -# -# -# -# Mean grain boundary surface energy that is assumed a function of the -# disorientation angle :math:`\Theta` of the adjoining grains :math:`\gamma(\Theta)`. -# This value factorizes the curvature_driving_force model. -# -# -# -# -# -# -# A continuum-scale curvature of an interface causes the interface to -# migrate towards the center of the curvature radius. -# -# -# -# If true the curvature_driving_force is considered, otherwise it is not. -# -# -# -# -# -# A continuum-scale difference of the stored elastic energy in dislocation -# configurations across a grain boundary can exert a driving force on the -# grain boundary such that the boundary migrates into the volume with the -# higher stored elastic energy. -# -# -# -# If true the dislocation_driving_force is considered, otherwise it is not. -# -# -# -# -# Prefactor :math:`0.5Gb^2` that factorizes the average -# stored elastic energy per length dislocation line. -# -# -# -# -# -# In case of an applied magnetic field, a difference of the magnetic -# susceptibility can exert a driving force on the grain boundary such that -# the boundary migrates into the volume with the higher magnetic energy. -# -# -# -# If true the magnetic_driving_force is considered, otherwise it is not. -# -# -# -# -# -# -# A triple line mediates the atomic arrangement differences between three -# interface patches. Therefore, the triple line is a defect that may not -# have the same mobility as adjoining grain boundaries and thus it may -# exert what can be conceptualized as a drag (resistance) to the motion -# of the adjoining interface patches. -# -# -# -# Assumed triple junction drag. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml deleted file mode 100644 index aab32a076b..0000000000 --- a/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml +++ /dev/null @@ -1,514 +0,0 @@ -category: application -doc: | - Application definition for documenting results with GraGLeS. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_summary_stats: | - The total number of summary statistic log entries. - n_grains: | - Number of grains in the computer simulation. - n_interfaces: | - Number of interfaces in the computer simulation. -type: group -NXmicrostructure_gragles_results(NXobject): - (NXentry): - definition(NX_CHAR): - enumeration: [NXmicrostructure_gragles_results] - - # For rollett_holm :math:`m(\Theta) = m_0 \cdot (1 - c_1 * exp(-c_2 \cdot \frac{\Theta}{15}^{c_3}))`. - simulation_identifier(NX_UINT): - doc: | - Simulation ID as an alias to refer to this simulation. - description(NX_CHAR): - doc: | - Discouraged free-text field to add further details to the computation. - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - exists: recommended - (NXuser): - exists: ['min', '0', 'max', 'unbounded'] - program1(NXprogram): - program_name: - \@version: - \@url: - exists: recommended - environment(NXobject): - exists: optional - doc: | - Programs and libraries representing the computational environment - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - coordinate_system_set(NXcoordinate_system_set): - rotation_handedness: - rotation_convention: - euler_angle_convention: - axis_angle_convention: - sign_convention: - sample_reference_frame(NXcoordinate_system): - type: - handedness: - origin: - x_alias: - x_direction: - y_alias: - y_direction: - z_alias: - z_direction: - spatiotemporalID(NXobject): - doc: | - Documentation of the spatiotemporal evolution - - # static quantities for which no change is modelled - # the typical lean summary statistics flattened - summary_statistics(NXobject): - doc: | - Summary quantities which are the result of some post-processing of the snapshot data - (averaging, integrating, interpolating) happening in for practical reasons though in while - running the simulation. Place used for storing descriptors from continuum mechanics - and thermodynamics at the scale of the entire ROI. - kinetics(NXprocess): - exists: optional - doc: | - Evolution of the recrystallized volume fraction over time. - time(NX_NUMBER): - unit: NX_TIME - doc: | - Evolution of the physical time not to be confused with wall-clock time or - profiling data. - dimensions: - rank: 1 - dim: [[1, n_summary_stats]] - iteration(NX_INT): - unit: NX_UNITLESS - doc: | - Iteration or increment counter. - number_of_crystals(NX_UINT): - unit: NX_UNITLESS - doc: | - How many crystals are distinguished. - Crystals are listed irrespective of the phase to which these are assigned. - dimensions: - rank: 1 - dim: [[1, n_summary_stats]] - stress(NXprocess): - exists: optional - type: - doc: | - Which type of stress. - enumeration: [cauchy] - stress(NX_FLOAT): - unit: NX_ANY - doc: | - Applied external stress tensor on the ROI. - dimensions: - rank: 3 - dim: [[1, n_summary_stats], [2, 3], [3, 3]] - strain(NXprocess): - exists: optional - type: - doc: | - Which type of strain. - strain(NX_FLOAT): - unit: NX_ANY - doc: | - Applied external strain tensor on the ROI. - dimensions: - rank: 3 - dim: [[1, n_summary_stats], [2, 3], [3, 3]] - deformation_gradient(NXprocess): - exists: optional - type: - doc: | - Which type of deformation gradient. - enumeration: [piola] - value(NX_FLOAT): - unit: NX_ANY - doc: | - Applied deformation gradient tensor on the ROI. - dimensions: - rank: 3 - dim: [[1, n_summary_stats], [2, 3], [3, 3]] - magnetic_field(NXprocess): - exists: optional - strength(NX_FLOAT): - unit: NX_ANY - doc: | - Applied external magnetic field on the ROI. - dimensions: - rank: 3 - dim: [[1, n_summary_stats], [2, 3], [3, 3]] - electrical_field(NXprocess): - exists: optional - - # specify type of field - strength(NX_FLOAT): - unit: NX_ANY - doc: | - Applied external electrical field on the ROI. - dimensions: - rank: 3 - dim: [[1, n_summary_stats], [2, 3], [3, 3]] - - # the typically storage-costlier snapshot data - microstructureID(NXmicrostructure): - exists: ['min', '1', 'max', 'unbounded'] - time(NX_NUMBER): - iteration(NX_INT): - temperature(NX_FLOAT): - unit: NX_TEMPERATURE - doc: | - Simulated temperature for this snapshot. - grid(NXcg_grid): - exists: optional - crystal(NXobject): - representation: - exists: recommended - number_of_crystals(NX_UINT): - number_of_phases(NX_UINT): - crystal_identifier_offset(NX_INT): - crystal_identifier(NX_INT): - dimensions: - rank: 1 - dim: [[1, n_grains]] - phase_identifier_offset(NX_INT): - phase_identifier(NX_INT): - dimensions: - rank: 1 - dim: [[1, n_grains]] - area(NX_NUMBER): - dimensions: - rank: 1 - dim: [[1, n_grains]] - volume(NX_NUMBER): - dimensions: - rank: 1 - dim: [[1, n_grains]] - interface(NXobject): - exists: optional - representation(NX_CHAR): - exists: recommended - number_of_interfaces(NX_UINT): - identifier_offset(NX_INT): - crystal_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Set of pairs of crystal_identifier for each interface. - dimensions: - rank: 2 - dim: [[1, n_interfaces], [2, 2]] - \@use_these: - type: NX_CHAR - relative_mobility(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Mobility times surface energy density of the interface normalized - to the maximum such product of the interface set. - dimensions: - rank: 1 - dim: [[1, n_interfaces]] - area(NX_NUMBER): - dimensions: - rank: 1 - dim: [[1, n_interfaces]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# dcafc6105a78380fa5aa50d169894a112f67802486a3455e652ffc8c80052c2c -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The total number of summary statistic log entries. -# -# -# -# -# Number of grains in the computer simulation. -# -# -# -# -# Number of interfaces in the computer simulation. -# -# -# -# -# Application definition for documenting results with GraGLeS. -# -# -# -# -# -# -# -# -# -# -# Simulation ID as an alias to refer to this simulation. -# -# -# -# -# Discouraged free-text field to add further details to the computation. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Programs and libraries representing the computational environment -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Documentation of the spatiotemporal evolution -# -# -# -# -# Summary quantities which are the result of some post-processing of the snapshot data -# (averaging, integrating, interpolating) happening in for practical reasons though in while -# running the simulation. Place used for storing descriptors from continuum mechanics -# and thermodynamics at the scale of the entire ROI. -# -# -# -# Evolution of the recrystallized volume fraction over time. -# -# -# -# Evolution of the physical time not to be confused with wall-clock time or -# profiling data. -# -# -# -# -# -# -# -# Iteration or increment counter. -# -# -# -# -# How many crystals are distinguished. -# Crystals are listed irrespective of the phase to which these are assigned. -# -# -# -# -# -# -# -# -# -# Which type of stress. -# -# -# -# -# -# -# -# Applied external stress tensor on the ROI. -# -# -# -# -# -# -# -# -# -# -# -# Which type of strain. -# -# -# -# -# Applied external strain tensor on the ROI. -# -# -# -# -# -# -# -# -# -# -# -# Which type of deformation gradient. -# -# -# -# -# -# -# -# Applied deformation gradient tensor on the ROI. -# -# -# -# -# -# -# -# -# -# -# -# Applied external magnetic field on the ROI. -# -# -# -# -# -# -# -# -# -# -# -# -# Applied external electrical field on the ROI. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Simulated temperature for this snapshot. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Set of pairs of crystal_identifier for each interface. -# -# -# -# -# -# -# -# -# -# Mobility times surface energy density of the interface normalized -# to the maximum such product of the interface set. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml deleted file mode 100644 index f174a935b5..0000000000 --- a/contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml +++ /dev/null @@ -1,423 +0,0 @@ -category: application -doc: | - Application definition for the configuration of the legacy (micro)structure generator - developed by the Institut für Metallkunde und Metallphysik at RWTH Aachen University. - - * `N. Leuning et al. `_ - * `C. Mießen `_ - * `M. Kühbach `_ - * `M. Kühbach et al. `_ - - The tool can be used to instantiate specific configurations for two- and three-dimensional discretized microstructures. - Specifically, single-phase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. - Grains are modelled as elongated crystals to mimic fundamental geometrical constraints of the interface network in deformed material. -symbols: - n_categories: | - How many texture components are distinguished, minimum is 1. - n_components: | - How many special texture components are distinguished if any. - n_ori: | - Number of discrete orientations that are distributed across the grains. -type: group -NXmicrostructure_imm_config(NXobject): - (NXentry): - definition(NX_CHAR): - enumeration: [NXmicrostructure_imm_config] - roi(NXobject): - doc: | - The computational domain will be synthesized either as a square (for dimensionality = 2) - or a cube (for dimensionality = 3) with axis-aligned cuboidal parent grains. The domain is - discretized into material points using either square pixel or cubic voxel as the tessellating - unit cells. - dimensionality(NX_UINT): - doc: | - Two-dimensional or three-dimensional simulation. - enumeration: [2, 3] - discretization(NX_UINT): - unit: NX_UNITLESS - doc: | - Target value for the number of material points per equivalent - discrete diameter of the arithmetic average sub-grain. - crystal_symmetry(NX_CHAR): - doc: | - Assumed space group of the material. - enumeration: [fcc, bcc, hcp] - - # PreferenceOrientations.txt - # 1 # 0, E_HCP, 1 E_FCC, 2 E_BCC, 3 E_DEFAULT_STRUCTURE - number_of_grains(NX_UINT): - unit: NX_UNITLESS - doc: | - Target value for the number of grains. The actual domain size and grid will be configured - based on the choices for discretization, number_of_grains, and shape of these grains. - number_of_subgrains(NX_UINT): - unit: NX_UNITLESS - doc: | - Target value for the average number of sub-grains per grain. - - # 0 is there another one if not remove - # 1 always one - # 1-\-> - # 1 - grain_shape(NX_FLOAT): - exists: optional - unit: NX_DIMENSIONLESS - doc: | - If available used to define the sequence of relative extent of grains along the y (first value) - and z-axis (second value) assuming the relative shape along the x-axis is 1. If not provided, - the relative extent of the grains will be 1 one average along each axis (globulitic structure). - dimensions: - rank: 1 - dim: [[1, 2]] - - # 0.05 - # 1.0 - # remove 0 all the time 0.00 - # remove 0 all the time 0.00 - # - component_analysis(NXobject): - exists: optional - doc: | - In texture research component analyses set on the idea that properties - of grains different based on orientation with certain regions in orientation - space show similar trends like a different average dislocation density - or orientation_spread. - component_name(NX_CHAR): - doc: | - The first entry is always the null model None which measn that an orientation - is not categorized as a special component. Examples for special components are - Dillamore, Copper, Cube, Y, P and Q. - dimensions: - rank: 1 - dim: [[1, n_categories]] - bunge_euler(NX_FLOAT): - unit: NX_ANGLE - doc: | - Bunge-Euler angle parameterization of the texture components - location in orientation space for which specifically different settings - should be configured. - dimensions: - rank: 2 - dim: [[1, n_components], [2, 3]] - theta(NX_FLOAT): - unit: NX_ANGLE - doc: | - Disorientation angle below which an orientation is categorized as one of the - components. - dimensions: - rank: 1 - dim: [[1, n_components]] - dislocation_distribution(NXobject): - doc: | - Dislocations are modelled as Rayleigh-distributed mean-field density that - can differ between but is constant within grains and sub-grains. - min_max_grain(NX_FLOAT): - unit: NX_ANY - doc: | - The minimum and the maximum dislocation density to distribute across grains. - dimensions: - rank: 2 - dim: [[1, n_categories], [2, 2]] - min_max_subgrain(NX_FLOAT): - unit: NX_ANY - doc: | - The minimum and the maximum dislocation density to distribute across sub-grains. - dimensions: - rank: 2 - dim: [[1, n_categories], [2, 2]] - - # 10.8e14# 10.8e14 - doc: | - The variance of the dislocation density distribution across the grains. - dimensions: - rank: 1 - dim: [[1, n_categories]] - variance_subgrain(NX_FLOAT): - unit: NX_ANY - doc: | - The variance of the dislocation density distribution across the sub-grains. - dimensions: - rank: 1 - dim: [[1, n_categories]] - orientation_distribution(NXprocess): - doc: | - Orientations of the grains are sampled from a set of Bunge-Euler angle triplets. - Orientations of the sub-grains are sampled by scattering the orientation - of the (parent) grain and with optional Rayleigh-distributed scatter. - bunge_euler(NX_FLOAT): - unit: NX_ANGLE - doc: | - Bunge-Euler angle parameterization of the texture components - location in orientation space for which specifically different settings - should be configured. - dimensions: - rank: 2 - dim: [[1, n_ori], [2, 3]] - variance_subgrain(NX_FLOAT): - unit: NX_ANGLE - doc: | - The variance of the disorientation of the sub-grain to their parent grain. - dimensions: - rank: 1 - dim: [[1, n_categories]] - - # what is with preference orientations? - # 1 # via OpenMP - # 1 - # 0.00 - # 1.00 - # 0.00 - # 1.00 - # -# -# -# -# -# -# -# How many texture components are distinguished, minimum is 1. -# -# -# -# -# How many special texture components are distinguished if any. -# -# -# -# -# Number of discrete orientations that are distributed across the grains. -# -# -# -# -# Application definition for the configuration of the legacy (micro)structure generator -# developed by the Institut für Metallkunde und Metallphysik at RWTH Aachen University. -# -# * `N. Leuning et al. <https://doi.org/10.3390/ma14216588>`_ -# * `C. Mießen <https://doi.org/10.18154/RWTH-2017-10148>`_ -# * `M. Kühbach <https://doi.org/10.18154/RWTH-2018-00294>`_ -# * `M. Kühbach et al. <https://github.com/mkuehbach/GraGLeS>`_ -# -# The tool can be used to instantiate specific configurations for two- and three-dimensional discretized microstructures. -# Specifically, single-phase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. -# Grains are modelled as elongated crystals to mimic fundamental geometrical constraints of the interface network in deformed material. -# -# -# -# -# -# -# -# -# -# The computational domain will be synthesized either as a square (for dimensionality = 2) -# or a cube (for dimensionality = 3) with axis-aligned cuboidal parent grains. The domain is -# discretized into material points using either square pixel or cubic voxel as the tessellating -# unit cells. -# -# -# -# Two-dimensional or three-dimensional simulation. -# -# -# -# -# -# -# -# -# Target value for the number of material points per equivalent -# discrete diameter of the arithmetic average sub-grain. -# -# -# -# -# Assumed space group of the material. -# -# -# -# -# -# -# -# -# -# -# Target value for the number of grains. The actual domain size and grid will be configured -# based on the choices for discretization, number_of_grains, and shape of these grains. -# -# -# -# -# Target value for the average number of sub-grains per grain. -# -# -# -# -# -# If available used to define the sequence of relative extent of grains along the y (first value) -# and z-axis (second value) assuming the relative shape along the x-axis is 1. If not provided, -# the relative extent of the grains will be 1 one average along each axis (globulitic structure). -# -# -# -# -# -# -# -# -# -# In texture research component analyses set on the idea that properties -# of grains different based on orientation with certain regions in orientation -# space show similar trends like a different average dislocation density -# or orientation_spread. -# -# -# -# The first entry is always the null model None which measn that an orientation -# is not categorized as a special component. Examples for special components are -# Dillamore, Copper, Cube, Y, P and Q. -# -# -# -# -# -# -# -# Bunge-Euler angle parameterization of the texture components -# location in orientation space for which specifically different settings -# should be configured. -# -# -# -# -# -# -# -# -# Disorientation angle below which an orientation is categorized as one of the -# components. -# -# -# -# -# -# -# -# -# Dislocations are modelled as Rayleigh-distributed mean-field density that -# can differ between but is constant within grains and sub-grains. -# -# -# -# The minimum and the maximum dislocation density to distribute across grains. -# -# -# -# -# -# -# -# -# The minimum and the maximum dislocation density to distribute across sub-grains. -# -# -# -# -# -# -# -# -# -# -# The variance of the dislocation density distribution across the grains. -# -# -# -# -# -# -# -# The variance of the dislocation density distribution across the sub-grains. -# -# -# -# -# -# -# -# -# Orientations of the grains are sampled from a set of Bunge-Euler angle triplets. -# Orientations of the sub-grains are sampled by scattering the orientation -# of the (parent) grain and with optional Rayleigh-distributed scatter. -# -# -# -# Bunge-Euler angle parameterization of the texture components -# location in orientation space for which specifically different settings -# should be configured. -# -# -# -# -# -# -# -# -# The variance of the disorientation of the sub-grain to their parent grain. -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml deleted file mode 100644 index f32d1481ae..0000000000 --- a/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml +++ /dev/null @@ -1,336 +0,0 @@ -category: application -doc: | - Application definition for the results of the legacy (micro)structure generator developed - by the Institut für Metallkunde und Metallphysik at RWTH Aachen University. - - * `N. Leuning et al. `_ - * `C. Mießen `_ - * `M. Kühbach `_ - * `M. Kühbach et al. `_ - - The tool can be used to instantiate specific configurations for two- and three-dimensional discretized microstructures. - Specifically, single-phase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. - Grains are modelled as elongated crystals to mimic fundamental geometrical constraints of the interface network in deformed material. -symbols: - n_edge: | - Number of material points along the edge of the square- or cube-shaped domain. - c: | - Number of crystals. -type: group -NXmicrostructure_imm_results(NXobject): - (NXentry): - definition(NX_CHAR): - enumeration: [NXmicrostructure_imm_results] - description(NX_CHAR): - doc: | - Discouraged free-text field to add further details to the computation. - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - exists: recommended - profiling(NXcs_profiling): - exists: optional - (NXuser): - exists: ['min', '0', 'max', 'unbounded'] - program1(NXprogram): - program(NX_CHAR): - \@version: - type: NX_CHAR - \@url: - type: NX_CHAR - exists: recommended - environment(NXobject): - exists: optional - doc: | - Programs and libraries representing the computational environment - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - microstructureID(NXmicrostructure): - grid(NXcg_grid): - extent(NX_UINT): - cell_dimensions(NX_NUMBER): - structure(NXdata): - doc: | - Default plot showing the grid. - \@signal: - type: NX_CHAR - \@axes: - type: NX_CHAR - \@AXISNAME_indices: - type: NX_CHAR - title(NX_CHAR): - crystal_identifier(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Crystal identifier that was assigned to each material point. - - # either (n_edge, n_edge) or (n_edge, n_edge, n_edge) - z(NX_NUMBER): - exists: optional - unit: NX_LENGTH - doc: | - Material point barycentre coordinate along z direction. - dimensions: - rank: 1 - dim: [[1, n_edge]] - \@long_name: - type: NX_CHAR - doc: | - Coordinate along z direction. - y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Material point barycentre coordinate along y direction. - dimensions: - rank: 1 - dim: [[1, n_edge]] - \@long_name: - type: NX_CHAR - doc: | - Coordinate along y direction. - x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Material point barycentre coordinate along x direction. - dimensions: - rank: 1 - dim: [[1, n_edge]] - \@long_name: - type: NX_CHAR - doc: | - Coordinate along x direction. - crystal(NXobject): - reference(NX_CHAR): - number_of_crystals(NX_UINT): - crystal_identifier(NX_INT): - dimensions: - rank: 1 - dim: [[1, c]] - area(NX_NUMBER): - exists: recommended - dimensions: - rank: 1 - dim: [[1, c]] - volume(NX_NUMBER): - exists: recommended - dimensions: - rank: 1 - dim: [[1, c]] - is_subgrain(NX_BOOLEAN): - exists: recommended - doc: | - True if the crystal is considered a sub-grain. - False if the crystal is considered a grain. - dimensions: - rank: 1 - dim: [[1, c]] - bunge_euler(NX_FLOAT): - unit: NX_ANGLE - doc: | - Bunge-Euler angle orientation of each crystal. - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] - dislocation_density(NX_FLOAT): - unit: NX_ANY - doc: | - Mean-field dislocation density as a measure of the stored elastic energy - content that is stored in the dislocation network of this grain and related - defects within each crystal. - dimensions: - rank: 1 - dim: [[1, c]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 1ba122ce8a203a704f08ad4356d50a885d8d48c751352408b765fac58a0f4f11 -# -# -# -# -# -# -# -# Number of material points along the edge of the square- or cube-shaped domain. -# -# -# -# -# Number of crystals. -# -# -# -# -# Application definition for the results of the legacy (micro)structure generator developed -# by the Institut für Metallkunde und Metallphysik at RWTH Aachen University. -# -# * `N. Leuning et al. <https://doi.org/10.3390/ma14216588>`_ -# * `C. Mießen <https://doi.org/10.18154/RWTH-2017-10148>`_ -# * `M. Kühbach <https://doi.org/10.18154/RWTH-2018-00294>`_ -# * `M. Kühbach et al. <https://github.com/mkuehbach/GraGLeS>`_ -# -# The tool can be used to instantiate specific configurations for two- and three-dimensional discretized microstructures. -# Specifically, single-phase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. -# Grains are modelled as elongated crystals to mimic fundamental geometrical constraints of the interface network in deformed material. -# -# -# -# -# -# -# -# -# -# Discouraged free-text field to add further details to the computation. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Programs and libraries representing the computational environment -# -# -# -# -# -# -# -# -# -# -# -# -# -# Default plot showing the grid. -# -# -# -# -# -# -# -# Crystal identifier that was assigned to each material point. -# -# -# -# -# -# Material point barycentre coordinate along z direction. -# -# -# -# -# -# -# Coordinate along z direction. -# -# -# -# -# -# Material point barycentre coordinate along y direction. -# -# -# -# -# -# -# Coordinate along y direction. -# -# -# -# -# -# Material point barycentre coordinate along x direction. -# -# -# -# -# -# -# Coordinate along x direction. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# True if the crystal is considered a sub-grain. -# False if the crystal is considered a grain. -# -# -# -# -# -# -# -# Bunge-Euler angle orientation of each crystal. -# -# -# -# -# -# -# -# -# Mean-field dislocation density as a measure of the stored elastic energy -# content that is stored in the dislocation network of this grain and related -# defects within each crystal. -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXmicrostructure_ipf.yaml b/contributed_definitions/nyaml/NXmicrostructure_ipf.yaml deleted file mode 100644 index 143e9cb8d0..0000000000 --- a/contributed_definitions/nyaml/NXmicrostructure_ipf.yaml +++ /dev/null @@ -1,433 +0,0 @@ -category: base -doc: | - Base class to store an inverse pole figure (IPF) mapping (IPF map). -symbols: - n_z: | - Number of pixel along the z slowest direction. - n_y: | - Number of pixel along the y slow direction. - n_x: | - Number of pixel along the x fast direction. - n_rgb: | - Number of RGB values along the fastest direction, always three. -type: group -NXmicrostructure_ipf(NXprocess): - depends_on(NX_CHAR): - doc: | - Reference to an :ref:`NXcoordinate_system` in which the projection_direction is defined. - - If the field depends_on is not provided but parents of the instance of this base class or its - specializations define an instance of :ref:`NXcoordinate_system`, projection_direction - is defined in this coordinate system. - - If nothing is provided it is assumed that projection_direction is defined in the McStas coordinate system. - projection_direction(NX_NUMBER): - unit: NX_UNITLESS - doc: | - The direction along which orientations are projected. - dimensions: - rank: 1 - dim: [[1, 3]] - input_grid(NXcg_grid): - doc: | - Details about the original grid. - - Here original grid means the grid for which the IPF map was computed when that - IPF map was exported from the tech partner's file format representation. - output_grid(NXcg_grid): - doc: | - Details about the grid onto which the IPF is recomputed. - - Rescaling the visualization of the IPF map may be needed to enable - visualization in specific software tools like H5Web. - interpolation(NX_CHAR): - doc: | - How where orientation values at positions of input_grid computed to values on output_grid. - - Nearest neighbour means the orientation of the closed (Euclidean distance) grid point of the input_grid was taken. - enumeration: [nearest_neighbour] - map(NXdata): - doc: | - Inverse pole figure mapping. - - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - Inspect the definition of :ref:`NXcrystal_structure` and its field - phase_identifier for further details. - - Details about possible regridding and associated interpolation - during the computation of the IPF map visualization can be stored - using the input_grid, output_grid, and interpolation fields. - - The main purpose of this map is to offer a normalized default representation - of the IPF map for consumption by a research data management system (RDMS). - This is aligned with the first aim of :ref:`NXmicrostructure_ipf`, to bring colleagues - and users of IPF maps together to discuss which pieces of information need storage. - - We are convinced a step-by-step design and community-driven discussion is a practical - strategy to work towards an interoperable description and data model for exchanging - IPF maps as a specific community-accepted method to convey orientation maps. - - With this design the individual RDMS solutions and tools can still continue - to support specific custom data analyses workflow and routes but at least - there is one common understanding which enables also those users who are - not necessarily experts in all the details of the underlying techniques an - understanding if the dataset is worth to become reused or repurposed. - - # \@signal: data - # \@axes: [axis_y, axis_x] - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - data(NX_NUMBER): - unit: NX_UNITLESS - - # assume a mapping with step size 0.5 micron - # we need to distinguish - # pixel position, i.e. 0, 1, 2, 3, unit px - # answers in which pixel on the map but map is disconnected from sample surface context - # calibrated pixel position 0., 0.5, 1.0, 1.5, unit micron - # answers in addition physical dimensions (relevant to get crystal extent etc.) but still disconnected from sample surface context - # calibrated pixel position including the offset of the original coordinate system - # answers everything would enable one to point if still in the microscope where on the sample surface each pixel is located - # tech partners oftentimes do not report to more than calibrated pixel position - doc: | - Inverse pole figure color code for each map coordinate. - dimensions: - rank: 3 - dim: [[1, n_y], [2, n_x], [3, 3]] - axis_z(NX_NUMBER): - unit: NX_LENGTH - doc: | - Pixel center coordinate calibrated for step size along the z axis of the map. - dimensions: - rank: 1 - dim: [[1, n_z]] - - # \@long_name(NX_CHAR): - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Pixel center coordinate calibrated for step size along the y axis of the map. - dimensions: - rank: 1 - dim: [[1, n_y]] - - # \@long_name(NX_CHAR): - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Pixel center coordinate calibrated for step size along the x axis of the map. - dimensions: - rank: 1 - dim: [[1, n_x]] - - # \@long_name(NX_CHAR): - # title: - legend(NXdata): - doc: | - The color code which maps colors to orientation in the fundamental zone. - - For each stereographic standard triangle (SST), i.e. a rendering of the - fundamental zone of the crystal-symmetry-reduced orientation space - SO3, it is possible to define a color model which assigns a color to each - point in the fundamental zone. - - Different mapping models are used. These implement (slightly) different - scaling relations. Differences exist across representations of tech partners. - - Differences are which base colors of the RGB color model are placed in - which extremal position of the SST and where the white point is located. - - For further details see: - - * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - * [S. Patala et al.](https://doi.org/10.1016/j.pmatsci.2012.04.002). - - Details are implementation-specific and not standardized yet. - - Given that the SST has a complicated geometry, it can not yet be - visualized using tools like H5Web, which is why for now the matrix - of a rasterized image which is rendered by the backend tool gets - copied into an RGB matrix to offer a default plot. - - # \@signal: data - # \@axes: [axis_y, axis_x] - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - data(NX_NUMBER): - unit: NX_UNITLESS - - # hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! - doc: | - Inverse pole figure color code for each map coordinate. - dimensions: - rank: 3 - dim: [[1, n_y], [2, n_x], [3, 3]] - axis_y(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Pixel along the y-axis. - dimensions: - rank: 1 - dim: [[1, n_y]] - - # \@long_name(NX_CHAR): - axis_x(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Pixel along the x-axis. - dimensions: - rank: 1 - dim: [[1, n_x]] - - # \@long_name(NX_CHAR): - # title: - - # for further contextualization see comments in NXms_ipf.yaml - # https://github.com/FAIRmat-NFDI/nexus_definitions/commit/26d4faa5c6950161e48f0672f3fdfd8c9bc907e2 - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# fee9f0abe19901b0c2c22cd8d8a56c6df76e8561ae53936915126e68ebaecf13 -# -# -# -# -# -# -# -# Number of pixel along the z slowest direction. -# -# -# -# -# Number of pixel along the y slow direction. -# -# -# -# -# Number of pixel along the x fast direction. -# -# -# -# -# Number of RGB values along the fastest direction, always three. -# -# -# -# -# Base class to store an inverse pole figure (IPF) mapping (IPF map). -# -# -# -# Reference to an :ref:`NXcoordinate_system` in which the projection_direction is defined. -# -# If the field depends_on is not provided but parents of the instance of this base class or its -# specializations define an instance of :ref:`NXcoordinate_system`, projection_direction -# is defined in this coordinate system. -# -# If nothing is provided it is assumed that projection_direction is defined in the McStas coordinate system. -# -# -# -# -# The direction along which orientations are projected. -# -# -# -# -# -# -# -# Details about the original grid. -# -# Here original grid means the grid for which the IPF map was computed when that -# IPF map was exported from the tech partner's file format representation. -# -# -# -# -# Details about the grid onto which the IPF is recomputed. -# -# Rescaling the visualization of the IPF map may be needed to enable -# visualization in specific software tools like H5Web. -# -# -# -# -# How where orientation values at positions of input_grid computed to values on output_grid. -# -# Nearest neighbour means the orientation of the closed (Euclidean distance) grid point of the input_grid was taken. -# -# -# -# -# -# -# -# Inverse pole figure mapping. -# -# phase. No ipf_mapID instances for non-indexed scan points as these are -# by definition assigned the null phase with phase_identifier 0. -# Inspect the definition of :ref:`NXcrystal_structure` and its field -# phase_identifier for further details. -# -# Details about possible regridding and associated interpolation -# during the computation of the IPF map visualization can be stored -# using the input_grid, output_grid, and interpolation fields. -# -# The main purpose of this map is to offer a normalized default representation -# of the IPF map for consumption by a research data management system (RDMS). -# This is aligned with the first aim of :ref:`NXmicrostructure_ipf`, to bring colleagues -# and users of IPF maps together to discuss which pieces of information need storage. -# -# We are convinced a step-by-step design and community-driven discussion is a practical -# strategy to work towards an interoperable description and data model for exchanging -# IPF maps as a specific community-accepted method to convey orientation maps. -# -# With this design the individual RDMS solutions and tools can still continue -# to support specific custom data analyses workflow and routes but at least -# there is one common understanding which enables also those users who are -# not necessarily experts in all the details of the underlying techniques an -# understanding if the dataset is worth to become reused or repurposed. -# -# -# -# -# -# Inverse pole figure color code for each map coordinate. -# -# -# -# -# -# -# -# -# -# Pixel center coordinate calibrated for step size along the z axis of the map. -# -# -# -# -# -# -# -# -# Pixel center coordinate calibrated for step size along the y axis of the map. -# -# -# -# -# -# -# -# -# Pixel center coordinate calibrated for step size along the x axis of the map. -# -# -# -# -# -# -# -# -# -# The color code which maps colors to orientation in the fundamental zone. -# -# For each stereographic standard triangle (SST), i.e. a rendering of the -# fundamental zone of the crystal-symmetry-reduced orientation space -# SO3, it is possible to define a color model which assigns a color to each -# point in the fundamental zone. -# -# Different mapping models are used. These implement (slightly) different -# scaling relations. Differences exist across representations of tech partners. -# -# Differences are which base colors of the RGB color model are placed in -# which extremal position of the SST and where the white point is located. -# -# For further details see: -# -# * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) -# * [S. Patala et al.](https://doi.org/10.1016/j.pmatsci.2012.04.002). -# -# Details are implementation-specific and not standardized yet. -# -# Given that the SST has a complicated geometry, it can not yet be -# visualized using tools like H5Web, which is why for now the matrix -# of a rasterized image which is rendered by the backend tool gets -# copied into an RGB matrix to offer a default plot. -# -# -# -# -# -# Inverse pole figure color code for each map coordinate. -# -# -# -# -# -# -# -# -# -# Pixel along the y-axis. -# -# -# -# -# -# -# -# -# Pixel along the x-axis. -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml deleted file mode 100644 index df0de6bbf2..0000000000 --- a/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml +++ /dev/null @@ -1,344 +0,0 @@ -category: application -doc: | - Application definition for the microstructure generator kanapy from ICAMS Bochum. - - * `A. Hartmeier et al. `_ - - A draft application definition to support discussion within the infrastructure use case IUC07 of the - NFDI-MatWerk consortium of the German NFDI working on a data model for documenting simulations - of spatiotemporal microstructure evolution with scientific software from this community. -symbols: - n_z: | - Number of material points along the z axis of the domain. - n_y: | - Number of material points along the y axis of the domain. - n_x: | - Number of material points along the x axis of the domain. - c: | - Number of crystals. -type: group -NXmicrostructure_kanapy_results(NXobject): - (NXentry): - definition(NX_CHAR): - enumeration: [NXmicrostructure_kanapy_results] - description(NX_CHAR): - doc: | - Discouraged free-text field to add further details to the computation. - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - exists: recommended - profiling(NXcs_profiling): - exists: optional - (NXuser): - exists: ['min', '0', 'max', 'unbounded'] - - # kanapy, the script because this is also a program /Users/alexander/Codes/kanapy/examples/RVE_generation/create_rve.py - program1(NXprogram): - program(NX_CHAR): - \@version: - type: NX_CHAR - \@url: - type: NX_CHAR - exists: recommended - program2(NXprogram): - program(NX_CHAR): - \@version: - type: NX_CHAR - \@url: - type: NX_CHAR - exists: recommended - environment(NXobject): - exists: optional - doc: | - Programs and libraries representing the computational environment - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - - # no units instead labelled-property graph concepts with units - microstructureID(NXmicrostructure): - exists: ['min', '1', 'max', 'unbounded'] - grid(NXcg_grid): - extent(NX_UINT): - cell_dimensions(NX_NUMBER): - origin(NX_NUMBER): - symmetry(NX_CHAR): - structure(NXdata): - doc: | - Default plot showing the grid. - \@signal: - type: NX_CHAR - \@axes: - type: NX_CHAR - \@AXISNAME_indices: - type: NX_CHAR - title(NX_CHAR): - crystal_identifier(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Crystal identifier that was assigned to each material point. - - # either (n_y, n_x) or (n_z, n_y, n_x) - z(NX_NUMBER): - exists: optional - unit: NX_LENGTH - doc: | - Material point barycentre coordinate along z direction. - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - type: NX_CHAR - doc: | - Coordinate along z direction. - y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Material point barycentre coordinate along y direction. - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - type: NX_CHAR - doc: | - Coordinate along y direction. - x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Material point barycentre coordinate along x direction. - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - type: NX_CHAR - doc: | - Coordinate along x direction. - - # add nodal positions as suggested in NXmicrostructure - crystal(NXobject): - reference(NX_CHAR): - number_of_crystals(NX_UINT): - number_of_phases(NX_UINT): - crystal_identifier(NX_INT): - dimensions: - rank: 1 - dim: [[1, c]] - phase_identifier(NX_INT): - dimensions: - rank: 1 - dim: [[1, c]] - area(NX_NUMBER): - exists: recommended - dimensions: - rank: 1 - dim: [[1, c]] - volume(NX_NUMBER): - exists: recommended - dimensions: - rank: 1 - dim: [[1, c]] - bunge_euler(NX_FLOAT): - unit: NX_ANGLE - doc: | - Bunge-Euler angle orientation of each crystal. - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 5786194d801284be3ef38b0d8448d6b57347d2baf8b5c2a535214dd0c0a26e02 -# -# -# -# -# -# -# -# Number of material points along the z axis of the domain. -# -# -# -# -# Number of material points along the y axis of the domain. -# -# -# -# -# Number of material points along the x axis of the domain. -# -# -# -# -# Number of crystals. -# -# -# -# -# Application definition for the microstructure generator kanapy from ICAMS Bochum. -# -# * `A. Hartmeier et al. <https://joss.theoj.org/papers/10.21105/joss.01732>`_ -# -# A draft application definition to support discussion within the infrastructure use case IUC07 of the -# NFDI-MatWerk consortium of the German NFDI working on a data model for documenting simulations -# of spatiotemporal microstructure evolution with scientific software from this community. -# -# -# -# -# -# -# -# -# -# Discouraged free-text field to add further details to the computation. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Programs and libraries representing the computational environment -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Default plot showing the grid. -# -# -# -# -# -# -# -# Crystal identifier that was assigned to each material point. -# -# -# -# -# -# Material point barycentre coordinate along z direction. -# -# -# -# -# -# -# Coordinate along z direction. -# -# -# -# -# -# Material point barycentre coordinate along y direction. -# -# -# -# -# -# -# Coordinate along y direction. -# -# -# -# -# -# Material point barycentre coordinate along x direction. -# -# -# -# -# -# -# Coordinate along x direction. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Bunge-Euler angle orientation of each crystal. -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXmicrostructure_mtex_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_mtex_config.yaml deleted file mode 100644 index cdf6368930..0000000000 --- a/contributed_definitions/nyaml/NXmicrostructure_mtex_config.yaml +++ /dev/null @@ -1,525 +0,0 @@ -category: base -doc: | - Base class to store the configuration when using the MTex/Matlab software. - - MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. - See `R. Hielscher et al. `_ and - the `MTex source code `_ for details. -symbols: - n_def_color_map: | - Number of entries in the default color map - n_color_map: | - Number of entries in color map -type: group -NXmicrostructure_mtex_config(NXobject): - conventions(NXcollection): - doc: | - Reference frame and orientation conventions. - Consult the `MTex docs `_ for details. - x_axis_direction(NX_CHAR): - doc: | - TODO with MTex developers - - # enumeration: - # check against v5.12 - z_axis_direction(NX_CHAR): - doc: | - TODO with MTex developers - - # enumeration: - a_axis_direction(NX_CHAR): - doc: | - TODO with MTex developers - - # enumeration: - b_axis_direction(NX_CHAR): - doc: | - TODO with MTex developers - - # enumeration: - euler_angle(NX_CHAR): - doc: | - TODO with MTex developers - enumeration: [unknown, undefined, bunge] - plotting(NXcollection): - doc: | - Settings relevant for generating plots. - font_size(NX_NUMBER): - unit: NX_ANY - doc: | - TODO with MTex developers - inner_plot_spacing(NX_NUMBER): - unit: NX_ANY - doc: | - TODO with MTex developers - outer_plot_spacing(NX_NUMBER): - unit: NX_ANY - doc: | - TODO with MTex developers - marker_size(NX_NUMBER): - unit: NX_ANY - doc: | - TODO with MTex developers - figure_size(NX_NUMBER): - doc: | - TODO with MTex developers - show_micron_bar(NX_BOOLEAN): - doc: | - True if MTex renders a scale bar with figures. - show_coordinates(NX_BOOLEAN): - doc: | - True if MTex renders a grid with figures. - pf_anno_fun_hdl: - doc: | - Code for the function handle used for annotating pole figure plots. - color_map(NX_NUMBER): - unit: NX_UNITLESS - doc: | - TODO with MTex developers - dimensions: - rank: 2 - dim: [[1, n_color_map], [2, 3]] - default_color_map(NX_NUMBER): - unit: NX_UNITLESS - doc: | - TODO with MTex developers - dimensions: - rank: 2 - dim: [[1, n_def_color_map], [2, 3]] - - # phase_color_order: - # doc: | - # TODO with MTex developers - # unit: NX_UNITLESS - color_palette(NX_CHAR): - degree_char(NX_CHAR): - doc: | - TODO with MTex developers - arrow_char(NX_CHAR): - doc: | - TODO with MTex developers - marker(NX_CHAR): - doc: | - TODO with MTex developers - marker_edge_color(NX_CHAR): - doc: | - TODO with MTex developers - marker_face_color(NX_CHAR): - doc: | - TODO with MTex developers - hit_test(NX_BOOLEAN): - doc: | - TODO with MTex developers - miscellaneous(NXcollection): - doc: | - Miscellaneous other settings of MTex. - mosek(NX_BOOLEAN): - doc: | - TODO with MTex developers - generating_help_mode(NX_BOOLEAN): - doc: | - TODO with MTex developers - methods_advise(NX_BOOLEAN): - doc: | - TODO with MTex developers - stop_on_symmetry_mismatch(NX_BOOLEAN): - doc: | - TODO with MTex developers - inside_poly(NX_BOOLEAN): - doc: | - TODO with MTex developers - text_interpreter: - numerics(NXcollection): - doc: | - Miscellaneous settings relevant for numerics. - eps(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Return value of the Matlab eps command. - fft_accuracy(NX_NUMBER): - unit: NX_ANY - doc: | - TODO with MTex developers - max_stwo_bandwidth(NX_NUMBER): - unit: NX_ANY - doc: | - TODO with MTex developers - max_sothree_bandwidth(NX_NUMBER): - unit: NX_ANY - doc: | - TODO with MTex developers - system(NXcollection): - doc: | - Miscellaneous settings relevant of the system where MTex runs. - memory(NX_NUMBER): - doc: | - TODO with MTex developers - open_gl_bug(NX_BOOLEAN): - doc: | - TODO with MTex developers - save_to_file(NX_BOOLEAN): - doc: | - TODO with MTex developers - path(NXcollection): - doc: | - Collection of paths from where MTex reads information and code. - mtex(NX_CHAR): - doc: | - Absolute path to specific component of MTex source code. - data(NX_CHAR): - doc: | - Absolute path to specific component of MTex source code. - cif(NX_CHAR): - doc: | - Absolute path to specific component of MTex source code. - ebsd(NX_CHAR): - doc: | - Absolute path to specific component of MTex source code. - pf(NX_CHAR): - doc: | - Absolute path to specific component of MTex source code. - odf(NX_CHAR): - doc: | - Absolute path to specific component of MTex source code. - tensor(NX_CHAR): - doc: | - Absolute path to specific component of MTex source code. - example(NX_CHAR): - doc: | - Absolute path to specific component of MTex source code. - import_wizard(NX_CHAR): - doc: | - Absolute path to specific component of MTex source code. - pf_extensions(NX_CHAR): - doc: | - List of file type suffixes for which MTex assumes - texture/pole figure information. - ebsd_extensions(NX_CHAR): - doc: | - List of file type suffixes for which MTex assumes EBSD content. - - # version as an instance of (NXprogram) one for MTex one for Matlab - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2728e563bbab6614e70dec02443b6ecf3d9535faa655816a2625950014a76886 -# -# -# -# -# -# -# -# Number of entries in the default color map -# -# -# -# -# Number of entries in color map -# -# -# -# -# Base class to store the configuration when using the MTex/Matlab software. -# -# MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. -# See `R. Hielscher et al. <https://mtex-toolbox.github.io/publications>`_ and -# the `MTex source code <https://github.com/mtex-toolbox>`_ for details. -# -# -# -# Reference frame and orientation conventions. -# Consult the `MTex docs <https://mtex-toolbox.github.io/EBSDReferenceFrame.html>`_ for details. -# -# -# -# TODO with MTex developers -# -# -# -# -# -# TODO with MTex developers -# -# -# -# -# -# TODO with MTex developers -# -# -# -# -# -# TODO with MTex developers -# -# -# -# -# -# TODO with MTex developers -# -# -# -# -# -# -# -# -# -# -# Settings relevant for generating plots. -# -# -# -# TODO with MTex developers -# -# -# -# -# TODO with MTex developers -# -# -# -# -# TODO with MTex developers -# -# -# -# -# TODO with MTex developers -# -# -# -# -# TODO with MTex developers -# -# -# -# -# True if MTex renders a scale bar with figures. -# -# -# -# -# True if MTex renders a grid with figures. -# -# -# -# -# Code for the function handle used for annotating pole figure plots. -# -# -# -# -# TODO with MTex developers -# -# -# -# -# -# -# -# -# TODO with MTex developers -# -# -# -# -# -# -# -# -# -# -# TODO with MTex developers -# -# -# -# -# TODO with MTex developers -# -# -# -# -# TODO with MTex developers -# -# -# -# -# TODO with MTex developers -# -# -# -# -# TODO with MTex developers -# -# -# -# -# TODO with MTex developers -# -# -# -# -# -# Miscellaneous other settings of MTex. -# -# -# -# TODO with MTex developers -# -# -# -# -# TODO with MTex developers -# -# -# -# -# TODO with MTex developers -# -# -# -# -# TODO with MTex developers -# -# -# -# -# TODO with MTex developers -# -# -# -# -# -# -# Miscellaneous settings relevant for numerics. -# -# -# -# Return value of the Matlab eps command. -# -# -# -# -# TODO with MTex developers -# -# -# -# -# TODO with MTex developers -# -# -# -# -# TODO with MTex developers -# -# -# -# -# -# Miscellaneous settings relevant of the system where MTex runs. -# -# -# -# TODO with MTex developers -# -# -# -# -# TODO with MTex developers -# -# -# -# -# TODO with MTex developers -# -# -# -# -# -# Collection of paths from where MTex reads information and code. -# -# -# -# Absolute path to specific component of MTex source code. -# -# -# -# -# Absolute path to specific component of MTex source code. -# -# -# -# -# Absolute path to specific component of MTex source code. -# -# -# -# -# Absolute path to specific component of MTex source code. -# -# -# -# -# Absolute path to specific component of MTex source code. -# -# -# -# -# Absolute path to specific component of MTex source code. -# -# -# -# -# Absolute path to specific component of MTex source code. -# -# -# -# -# Absolute path to specific component of MTex source code. -# -# -# -# -# Absolute path to specific component of MTex source code. -# -# -# -# -# List of file type suffixes for which MTex assumes -# texture/pole figure information. -# -# -# -# -# List of file type suffixes for which MTex assumes EBSD content. -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXmicrostructure_odf.yaml b/contributed_definitions/nyaml/NXmicrostructure_odf.yaml deleted file mode 100644 index e436f7f7d0..0000000000 --- a/contributed_definitions/nyaml/NXmicrostructure_odf.yaml +++ /dev/null @@ -1,382 +0,0 @@ -category: base -doc: | - Base class to store an orientation distribution function (ODF). - - An orientation distribution function is a probability distribution that details how - much volume of material has a specific orientation. An ODF is computed from - pole figure data in a computational process called `pole figure inversion `_. -symbols: - n_varphi_one: | - Number of pixel per varphi section plot along the :math:`\varphi_1` fastest - direction. - n_capital_phi: | - Number of pixel per varphi section plot along the :math:`\Phi` fast direction. - n_varphi_two: | - Number of pixel per varphi section plot along the :math:`\varphi_2` slow - direction. - k: | - Number of local maxima evaluated in the component analysis. - n_pos: | - Number of sampled positions in orientation space. -type: group -NXmicrostructure_odf(NXprocess): - configuration(NXobject): - doc: | - Details about the algorithm used for computing the ODF. - crystal_symmetry_point_group(NX_CHAR): - doc: | - Point group of the crystal structure of the phase for which the here documented phase- - dependent ODF was computed.(following the notation of the International Table of Crystallography). - specimen_symmetry_point_group(NX_CHAR): - doc: | - Point group assumed for additionally considered sample symmetries - following the notation of the International Table of Crystallography). - kernel_halfwidth(NX_NUMBER): - unit: NX_ANGLE - doc: | - Halfwidth of the kernel. - kernel_name(NX_CHAR): - doc: | - Name of the kernel. - resolution(NX_NUMBER): - unit: NX_ANGLE - doc: | - Resolution of the kernel. - - # specific values and typical results - kth_extrema(NXobject): - doc: | - Group to store descriptors and summary statistics for extrema of the ODF. - extrema(NX_CHAR): - doc: | - Minima or maxima, if extrema is set to minima values for location and volume_fraction - are sorted in increasing order. If extrema is set to maxima values for location and - volume_fraction are sorted in descreasing order. Therefore, the global extremum is - always the first entry in location and volume_fraction. - enumeration: [minima, maxima] - kth(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of local extrema evaluated - - # value of kth should be k - theta(NX_NUMBER): - unit: NX_ANGLE - doc: | - Disorientation threshold within which intensity of the ODF - is integrated for the component analysis. - location(NX_NUMBER): - unit: NX_ANGLE - doc: | - Euler angle representation :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` of the kth-most - maxima in decreasing order of the intensity maximum. - dimensions: - rank: 2 - dim: [[1, k], [2, 3]] - volume_fraction(NX_NUMBER): - unit: NX_ANY - doc: | - Integrated ODF intensity within a theta angular region of the orientation space (SO3) - about each location (obeying symmetries) as specified for each location. - dimensions: - rank: 1 - dim: [[1, k]] - sampling(NXobject): - doc: | - The ODF intensity values (weights) as sampled with a software - resolution(NX_NUMBER): - unit: NX_ANGLE - doc: | - Sampling resolution - euler(NX_NUMBER): - unit: NX_ANGLE - doc: | - Bunge-Euler (i.e. ZXZ convention) locations of each position - in orientation space for which a weight was sampled. - dimensions: - rank: 2 - dim: [[1, n_pos], [2, 3]] - weight(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - Weight at each sampled position following the order in euler. - dimensions: - rank: 1 - dim: [[1, n_pos]] - phi_two_plot(NXdata): - doc: | - Visualization of the ODF intensity as discretized orthogonal sections through - orientation space parameterized using Bunge-Euler angles. - - This is one example of typical default plots used in the texture community in materials engineering. - - Mind that when parameterized using Euler angles the orientation space is a distorted space. - Therefore, equivalent orientations show intensity contributions in eventually multiple locations. - - # \@signal: intensity - # \@axes: [varphi_two, capital_phi, varphi_one] - # \@varphi_one_indices: 0 - # \@capital_phi: 1 - # \@varphi_two_indices: 2 - intensity(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - ODF intensity at probed locations relative to the intensity of the null model of - a random texture. - dimensions: - rank: 3 - dim: [[1, n_varphi_two], [2, n_capital_phi], [3, n_varphi_one]] - varphi_one(NX_NUMBER): - unit: NX_ANGLE - doc: | - Pixel center angular position along the :math:`\varphi_1` direction. - dimensions: - rank: 1 - dim: [[1, n_varphi_one]] - - # \@long_name(NX_CHAR): - capital_phi(NX_NUMBER): - unit: NX_ANGLE - doc: | - Pixel center angular position along the :math:`\Phi` direction. - dimensions: - rank: 1 - dim: [[1, n_capital_phi]] - - # \@long_name(NX_CHAR): - varphi_two(NX_NUMBER): - unit: NX_ANGLE - doc: | - Pixel center angular position along the :math:`\varphi_2` direction. - dimensions: - rank: 1 - dim: [[1, n_varphi_two]] - - # \@long_name(NX_CHAR): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# cae0f111b0054fe92d860666cedc1db0bc9abcf1d69058fb619b351bed79705f -# -# -# -# -# -# -# -# Number of pixel per varphi section plot along the :math:`\varphi_1` fastest -# direction. -# -# -# -# -# Number of pixel per varphi section plot along the :math:`\Phi` fast direction. -# -# -# -# -# Number of pixel per varphi section plot along the :math:`\varphi_2` slow -# direction. -# -# -# -# -# Number of local maxima evaluated in the component analysis. -# -# -# -# -# Number of sampled positions in orientation space. -# -# -# -# -# Base class to store an orientation distribution function (ODF). -# -# An orientation distribution function is a probability distribution that details how -# much volume of material has a specific orientation. An ODF is computed from -# pole figure data in a computational process called `pole figure inversion <https://doi.org/10.1107/S0021889808030112>`_. -# -# -# -# Details about the algorithm used for computing the ODF. -# -# -# -# Point group of the crystal structure of the phase for which the here documented phase- -# dependent ODF was computed.(following the notation of the International Table of Crystallography). -# -# -# -# -# Point group assumed for additionally considered sample symmetries -# following the notation of the International Table of Crystallography). -# -# -# -# -# Halfwidth of the kernel. -# -# -# -# -# Name of the kernel. -# -# -# -# -# Resolution of the kernel. -# -# -# -# -# -# -# Group to store descriptors and summary statistics for extrema of the ODF. -# -# -# -# Minima or maxima, if extrema is set to minima values for location and volume_fraction -# are sorted in increasing order. If extrema is set to maxima values for location and -# volume_fraction are sorted in descreasing order. Therefore, the global extremum is -# always the first entry in location and volume_fraction. -# -# -# -# -# -# -# -# -# Number of local extrema evaluated -# -# -# -# -# -# Disorientation threshold within which intensity of the ODF -# is integrated for the component analysis. -# -# -# -# -# Euler angle representation :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` of the kth-most -# maxima in decreasing order of the intensity maximum. -# -# -# -# -# -# -# -# -# Integrated ODF intensity within a theta angular region of the orientation space (SO3) -# about each location (obeying symmetries) as specified for each location. -# -# -# -# -# -# -# -# -# The ODF intensity values (weights) as sampled with a software -# -# -# -# Sampling resolution -# -# -# -# -# Bunge-Euler (i.e. ZXZ convention) locations of each position -# in orientation space for which a weight was sampled. -# -# -# -# -# -# -# -# -# Weight at each sampled position following the order in euler. -# -# -# -# -# -# -# -# -# Visualization of the ODF intensity as discretized orthogonal sections through -# orientation space parameterized using Bunge-Euler angles. -# -# This is one example of typical default plots used in the texture community in materials engineering. -# -# Mind that when parameterized using Euler angles the orientation space is a distorted space. -# Therefore, equivalent orientations show intensity contributions in eventually multiple locations. -# -# -# -# -# ODF intensity at probed locations relative to the intensity of the null model of -# a random texture. -# -# -# -# -# -# -# -# -# -# Pixel center angular position along the :math:`\varphi_1` direction. -# -# -# -# -# -# -# -# -# Pixel center angular position along the :math:`\Phi` direction. -# -# -# -# -# -# -# -# -# Pixel center angular position along the :math:`\varphi_2` direction. -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXmicrostructure_pf.yaml b/contributed_definitions/nyaml/NXmicrostructure_pf.yaml deleted file mode 100644 index fe72bc47d8..0000000000 --- a/contributed_definitions/nyaml/NXmicrostructure_pf.yaml +++ /dev/null @@ -1,189 +0,0 @@ -category: base -doc: | - Base class to store a pole figure (PF) computation. - - A pole figure is the X-ray diffraction intensity for specific integrated - peaks for a hemispherical illumination of a real or virtual specimen. -symbols: - n_y: | - Number of pixel per pole figure in the slow direction. - n_x: | - Number of pixel per pole figure in the fast direction. -type: group -NXmicrostructure_pf(NXprocess): - configuration(NXobject): - doc: | - Details about the algorithm that was used to compute the pole figure. - crystal_symmetry_point_group(NX_CHAR): - doc: | - Point group of the crystal structure of the phase for which the pole figure - was computed (according to International Table of Crystallography). - specimen_symmetry_point_group(NX_CHAR): - doc: | - Point group of assumed sample symmetries (according to International Table of - Crystallography). - - # integration windows - halfwidth(NX_NUMBER): - unit: NX_ANGLE - doc: | - Halfwidth of the kernel. - miller_indices(NX_CHAR): - doc: | - Miller indices (:math:`(hkl)[uvw]`) to specify the pole figure. - resolution(NX_NUMBER): - unit: NX_ANGLE - doc: | - Resolution of the kernel. - pf(NXdata): - doc: | - Pole figure. - - # \@signal: intensity - # \@axes: [axis_y, axis_x] - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - intensity(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Pole figure intensity. - dimensions: - rank: 2 - dim: [[1, n_y], [2, n_x]] - axis_y(NX_NUMBER): - unit: NX_ANY - doc: | - Pixel center along y direction in the equatorial plane of - a stereographic projection of the unit sphere. - dimensions: - rank: 1 - dim: [[1, n_y]] - - # \@long_name(NX_CHAR): - axis_x(NX_NUMBER): - unit: NX_ANY - doc: | - Pixel center along x direction in the equatorial plane of - a stereographic projection of the unit sphere. - dimensions: - rank: 1 - dim: [[1, n_x]] - - # \@long_name(NX_CHAR): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# b6d653631fbd7c1c0911a62aa985bb4dd9d507e8fa35b61252131fcb403460a5 -# -# -# -# -# -# -# -# Number of pixel per pole figure in the slow direction. -# -# -# -# -# Number of pixel per pole figure in the fast direction. -# -# -# -# -# Base class to store a pole figure (PF) computation. -# -# A pole figure is the X-ray diffraction intensity for specific integrated -# peaks for a hemispherical illumination of a real or virtual specimen. -# -# -# -# Details about the algorithm that was used to compute the pole figure. -# -# -# -# Point group of the crystal structure of the phase for which the pole figure -# was computed (according to International Table of Crystallography). -# -# -# -# -# Point group of assumed sample symmetries (according to International Table of -# Crystallography). -# -# -# -# -# -# Halfwidth of the kernel. -# -# -# -# -# Miller indices (:math:`(hkl)[uvw]`) to specify the pole figure. -# -# -# -# -# Resolution of the kernel. -# -# -# -# -# -# Pole figure. -# -# -# -# -# Pole figure intensity. -# -# -# -# -# -# -# -# -# Pixel center along y direction in the equatorial plane of -# a stereographic projection of the unit sphere. -# -# -# -# -# -# -# -# -# Pixel center along x direction in the equatorial plane of -# a stereographic projection of the unit sphere. -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml deleted file mode 100644 index 7894f93725..0000000000 --- a/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml +++ /dev/null @@ -1,930 +0,0 @@ -category: application -doc: | - Application definition to configure a simulation with the SCORE model. - - * `M. Kühbach et al. `_ - * `M. Diehl et al. `_ -symbols: - n_dg_ori: | - Number of Bunge-Euler angle triplets for deformed grains. - n_rx_ori: | - Number of Bunge-Euler angle triplets for recrystallization nuclei. - n_drag: | - Number of support points for the linearized drag profile. - n_temp: | - Number of suport points for the desired time-temperature profile. - n_defrag: | - Number of entries when to defragment i.e. garbage collect the memory holding - state information for recrystallized cells. - n_snapshot: | - Number of entries when to collect snapshots of the evolving microstructure. - n_su: | - Number of solitary unit domains to export. -type: group -NXmicrostructure_score_config(NXobject): - (NXentry): - definition(NX_CHAR): - enumeration: [NXmicrostructure_score_config] - simulation_identifier(NX_UINT): - doc: | - Simulation ID as an alias to refer to this simulation. - description(NX_CHAR): - doc: | - Discouraged free-text field to add further details to the computation. - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - exists: recommended - profiling(NXcs_profiling): - exists: optional - (NXuser): - exists: ['min', '0', 'max', 'unbounded'] - program1(NXprogram): - program_name: - \@version: - \@url: - exists: recommended - environment(NXobject): - exists: optional - doc: | - Programs and libraries representing the computational environment - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - discretization(NXmicrostructure): - doc: | - Relevant data to instantiate a starting configuration that is typically - a microstructure in deformed conditions where stored (elastic) energy - is stored in the form of crystal defects, which in the SCORE model are - is considered as mean-field dislocation content. - grid(NXcg_grid): - extent(NX_UINT): - doc: | - Extend of each CA domain in voxel along the x, y, and z direction. - Deformation of sheet material is assumed. - The x axis is assumed pointing along the rolling direction. - The y axis is assumed pointing along the transverse direction. - The z axis is assumed pointing along the normal direction. - cell_dimensions(NX_NUMBER): - deformation(NXobject): - doc: | - Details how the deformed grains should be modelled. - model: - doc: | - Which model should be used to generate a starting microstructure. - enumeration: [cuboidal, poisson_voronoi, ebsd, damask] - extent(NX_FLOAT): - unit: NX_LENGTH - doc: | - Extent of each deformed grain in voxel along the - x, y, and z direction when type is cuboidal. - dimensions: - rank: 1 - dim: [[1, 3]] - diameter(NX_FLOAT): - unit: NX_LENGTH - doc: | - Average spherical diameter when type is poisson_voronoi. - bunge_euler(NX_FLOAT): - exists: optional - unit: NX_ANGLE - doc: | - Set of Bunge-Euler angles ( :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` ) - to sample orientations of deformed grains randomly from. - dimensions: - rank: 2 - dim: [[1, n_dg_ori], [2, 3]] - ebsd(NXserialized): - exists: optional - doc: | - The EBSD dataset from which the initial microstructure is - instantiated if model is ebsd. - type: - path: - algorithm: - checksum: - stepsize(NX_FLOAT): - unit: NX_LENGTH - doc: | - Extent of the pixel of the EBSD orientation mapping assuming square-shaped - pixels. - dimensions: - rank: 1 - dim: [[1, 2]] - nucleation(NXobject): - doc: | - Phenomenological model according to which recrystallization nuclei - are placed into the domain and assumed growing. - spatial_distribution: - doc: | - According to which model will the nuclei become distributed spatially: - - * csr, complete spatial randomness. - * custom, implementation specific. - * gb, nuclei placed at grain boundaries - enumeration: [csr, custom, gb] - incubation_time: - doc: | - According to which model will the nuclei start to grow. - enumeration: [site_saturation] - orientation: - doc: | - According to which model will the nuclei get their orientation assigned. - enumeration: [sample_from_nucleus_euler] - bunge_euler(NX_FLOAT): - unit: NX_ANGLE - doc: | - Set of Bunge-Euler angles ( :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` ) - to sample orientations of nuclei randomly from. - dimensions: - rank: 2 - dim: [[1, n_rx_ori], [2, 3]] - material_properties(NXobject): - doc: | - (Mechanical) properties of the material which scale - the amount of stored (elastic) energy in the system and - thus mainly affect recrystallization kinetics. - reference_shear_modulus(NX_FLOAT): - unit: NX_PRESSURE - doc: | - Shear modulus at zero Kelvin. - reference_burgers_magnitude(NX_FLOAT): - unit: NX_LENGTH - doc: | - Magnitude at the Burgers vector at zero Kelvin. - - # firstOrderdG0dT - # alloyConstantThermalExpCoeff - # FirstOrderThermalExpCoeff - # SecondOrderThermalExpCoeff - melting_temperature(NX_FLOAT): - unit: NX_TEMPERATURE - doc: | - Melting temperature in degrees Celsius. - grain_boundary_mobility(NXobject): - doc: | - Model for the assumed mobility of grain boundaries with different disorientation - essentially implementing variations of Turnbull's model for - thermally-activated migration. - model: - doc: | - Which type of fundamental model for the grain boundary mobility. - - Grain boundaries with disorientation angle smaller than 15 degree are considered - as low-angle grain boundaries. Other grain boundaries are high-angle boundaries. - - # TODO: add equation for the Sebald-Gottstein model the following equation - # TODO: add equation for the Rollett-Holm model the following equation - enumeration: [sebald_gottstein, rollett_holm] - sebald_gottstein(NXobject): - exists: optional - doc: | - Parameter of the Sebald-Gottstein migration model. - lagb_to_hagb_cut(NX_FLOAT): - unit: NX_ANGLE - doc: | - At which disorientation angle are grain boundary considered as high-angle grain - boundaries. - lagb_pre_factor(NX_FLOAT): - unit: NX_ANY - doc: | - Pre-exponential factor for low-angle grain boundaries. - lagb_enthalpy(NX_FLOAT): - unit: NX_ANY - doc: | - Migration activation enthalpy for low-angle grain boundaries. - hagb_pre_factor(NX_FLOAT): - unit: NX_ANY - doc: | - Pre-exponential factor for high-angle grain boundaries. - hagb_enthalpy(NX_FLOAT): - unit: NX_ANY - doc: | - Migration activation enthalpy for high-angle grain boundaries. - special_pre_factor(NX_FLOAT): - unit: NX_ANY - doc: | - Pre-exponential factor for particularly mobile boundaries. - special_enthalpy(NX_FLOAT): - unit: NX_ANY - doc: | - Migration activation enthalpy for particularly mobile boundaries. - rollett_holm(NXobject): - doc: | - Parameter of the Rollett-Holm migration model. - - # For rollett_holm :math:`m(\Theta) = m_0 \cdot (1 - c_1 * exp(-c_2 \cdot \frac{\Theta}{15}^{c_3}))`. - m_null(NX_FLOAT): - unit: NX_ANY - doc: | - The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed - temperature. GraGLeS was developed for modelling isothermal annealing. - c_one(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not one. - c_two(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Mobility scaling factor :math:`c_2`. Typically 5. - c_three(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Mobility scaling factor :math:`c_3`. Typically 9. - stored_energy_recovery(NXobject): - doc: | - Time-dependent reduction of the stored (elastic) energy to account for recovery. - model: - doc: | - Which type of recovery model. - enumeration: [none] - dispersoid_drag(NXobject): - doc: | - Reduction of the grain boundary migration speed due to the presence of dispersoids - through which the total grain boundary area of the recrystallization front can be reduced. - model: - doc: | - Which type of drag model. - enumeration: [none, zener_smith] - zener_smith(NXobject): - exists: optional - doc: | - Parameter of the Zener-Smith drag model. - pre_factor(NX_FLOAT): - doc: | - Configuration-dependent constant which factorizes the drag pressure. - surface_energy(NX_FLOAT): - doc: | - Average surface energy of the grain-boundary-dispersoid-surface configuration - which factorizes the drag pressure. - time(NX_FLOAT): - unit: NX_TIME - doc: | - Support point of the linearized curve of simulated time matching - a specific support point of the average dispersoid radius. - dimensions: - rank: 1 - dim: [[1, n_drag]] - radius(NX_FLOAT): - unit: NX_LENGTH - doc: | - Support point of the linearized curve of the average dispersoid radius. - dimensions: - rank: 1 - dim: [[1, n_drag]] - time_temperature(NXobject): - doc: | - Desired simulated time-temperature profile - time(NX_FLOAT): - unit: NX_TIME - doc: | - Support point of the linearized curve of simulated time matching - a specific support point of the temperature. - dimensions: - rank: 1 - dim: [[1, n_temp]] - temperature(NX_FLOAT): - unit: NX_TEMPERATURE - doc: | - Support point of the linearized curve of the temperature. - dimensions: - rank: 1 - dim: [[1, n_temp]] - simulation_control(NXobject): - doc: | - Criteria which enable to stop the simulation in a controlled manner. - Whichever criterion is fulfilled first stops the simulation. - max_x(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Maximum recrystallized volume fraction. - max_time(NX_NUMBER): - unit: NX_TIME - doc: | - Maximum simulated physical time. - max_iteration(NX_UINT): - unit: NX_UNITLESS - doc: | - Maximum number of iteration steps. - numerics(NXobject): - doc: | - Settings relevant for stable numerical integration. - max_delta_x(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Maximum fraction equivalent to the migration of the - fastest grain boundary in the system how much a cell - may be consumed in a single iteration. - initial_cell_cache(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Fraction of the total number of cells in the CA which - should initially be allocated for offering cells in the - recrystallization front. - realloc_cell_cache(NX_FLOAT): - unit: NX_UNITLESS - doc: | - By how much more times should the already allocated memory - be increased to offer space for storing states of cells - in the recrystallization front. - defragment_cell_cache(NX_BOOLEAN): - doc: | - Should the cache for cells in the recrystallization front - be defragmented on-the-fly. - defragment_x(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Heuristic recrystallized volume target values at which - the cache for cells in the recrystallization front - will be defragmented on-the-fly. - dimensions: - rank: 1 - dim: [[1, n_defrag]] - sampling(NXobject): - x(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - List of recrystallized volume target values at which a - snapshot of the CA state should be stored. - - The code documents summary statistics like recrystallized volume fraction - for each iteration. However, snapshots of the microstructure can take much - space as SCORE is able to evolve automata with up to :math:`1600^3` cells. - Snapshot data document the current microstructure which includes the grain - assigned to each of these cells plus the state of the recrystallization front. - - Despite these front data make up for approximately one order of magnitude - less cells than represented in the domain, more numerical data have to be - collected each cell in the front than just a grain identifier. - dimensions: - rank: 1 - dim: [[1, n_snapshot]] - solitary_unit(NXobject): - apply(NX_BOOLEAN): - doc: | - Perform a statistical analyses of the results as it was - proposed by M. Kühbach (solitary unit model ensemble approach). - number_of_domains(NX_UINT): - unit: NX_UNITLESS - doc: | - How many independent cellular automaton domains - should be instantiated. - rediscretization(NX_UINT): - unit: NX_UNITLESS - doc: | - Into how many time steps should the real time interval be discretized upon - during post-processing the results with the solitary unit modeling approach. - domain_identifier(NX_UINT): - unit: NX_UNITLESS - doc: | - List of identifier for those domain which should be rendered. - Identifier start from 0. - dimensions: - rank: 1 - dim: [[1, n_su]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 7bf70eb740ed157be8c02cbcf23ff0365420faf9f43aea2267440c2de74d7af1 -# -# -# -# -# -# -# -# Number of Bunge-Euler angle triplets for deformed grains. -# -# -# -# -# Number of Bunge-Euler angle triplets for recrystallization nuclei. -# -# -# -# -# Number of support points for the linearized drag profile. -# -# -# -# -# Number of suport points for the desired time-temperature profile. -# -# -# -# -# Number of entries when to defragment i.e. garbage collect the memory holding -# state information for recrystallized cells. -# -# -# -# -# Number of entries when to collect snapshots of the evolving microstructure. -# -# -# -# -# Number of solitary unit domains to export. -# -# -# -# -# Application definition to configure a simulation with the SCORE model. -# -# * `M. Kühbach et al. <https://doi.org/10.1016/j.actamat.2016.01.068>`_ -# * `M. Diehl et al. <https://doi.org/10.1088/1361-651X/ab51bd>`_ -# -# -# -# -# -# -# -# -# -# Simulation ID as an alias to refer to this simulation. -# -# -# -# -# Discouraged free-text field to add further details to the computation. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Programs and libraries representing the computational environment -# -# -# -# -# -# -# -# -# -# Relevant data to instantiate a starting configuration that is typically -# a microstructure in deformed conditions where stored (elastic) energy -# is stored in the form of crystal defects, which in the SCORE model are -# is considered as mean-field dislocation content. -# -# -# -# -# Extend of each CA domain in voxel along the x, y, and z direction. -# Deformation of sheet material is assumed. -# The x axis is assumed pointing along the rolling direction. -# The y axis is assumed pointing along the transverse direction. -# The z axis is assumed pointing along the normal direction. -# -# -# -# -# -# -# -# Details how the deformed grains should be modelled. -# -# -# -# Which model should be used to generate a starting microstructure. -# -# -# -# -# -# -# -# -# -# -# Extent of each deformed grain in voxel along the -# x, y, and z direction when type is cuboidal. -# -# -# -# -# -# -# -# Average spherical diameter when type is poisson_voronoi. -# -# -# -# -# Set of Bunge-Euler angles ( :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` ) -# to sample orientations of deformed grains randomly from. -# -# -# -# -# -# -# -# -# The EBSD dataset from which the initial microstructure is -# instantiated if model is ebsd. -# -# -# -# -# -# -# -# Extent of the pixel of the EBSD orientation mapping assuming square-shaped -# pixels. -# -# -# -# -# -# -# -# -# -# Phenomenological model according to which recrystallization nuclei -# are placed into the domain and assumed growing. -# -# -# -# According to which model will the nuclei become distributed spatially: -# -# * csr, complete spatial randomness. -# * custom, implementation specific. -# * gb, nuclei placed at grain boundaries -# -# -# -# -# -# -# -# -# -# According to which model will the nuclei start to grow. -# -# -# -# -# -# -# -# According to which model will the nuclei get their orientation assigned. -# -# -# -# -# -# -# -# Set of Bunge-Euler angles ( :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` ) -# to sample orientations of nuclei randomly from. -# -# -# -# -# -# -# -# -# -# (Mechanical) properties of the material which scale -# the amount of stored (elastic) energy in the system and -# thus mainly affect recrystallization kinetics. -# -# -# -# Shear modulus at zero Kelvin. -# -# -# -# -# Magnitude at the Burgers vector at zero Kelvin. -# -# -# -# -# -# Melting temperature in degrees Celsius. -# -# -# -# -# -# Model for the assumed mobility of grain boundaries with different disorientation -# essentially implementing variations of Turnbull's model for -# thermally-activated migration. -# -# -# -# Which type of fundamental model for the grain boundary mobility. -# -# Grain boundaries with disorientation angle smaller than 15 degree are considered -# as low-angle grain boundaries. Other grain boundaries are high-angle boundaries. -# -# -# -# -# -# -# -# -# -# Parameter of the Sebald-Gottstein migration model. -# -# -# -# At which disorientation angle are grain boundary considered as high-angle grain -# boundaries. -# -# -# -# -# Pre-exponential factor for low-angle grain boundaries. -# -# -# -# -# Migration activation enthalpy for low-angle grain boundaries. -# -# -# -# -# Pre-exponential factor for high-angle grain boundaries. -# -# -# -# -# Migration activation enthalpy for high-angle grain boundaries. -# -# -# -# -# Pre-exponential factor for particularly mobile boundaries. -# -# -# -# -# Migration activation enthalpy for particularly mobile boundaries. -# -# -# -# -# -# Parameter of the Rollett-Holm migration model. -# -# -# -# -# The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed -# temperature. GraGLeS was developed for modelling isothermal annealing. -# -# -# -# -# Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not one. -# -# -# -# -# Mobility scaling factor :math:`c_2`. Typically 5. -# -# -# -# -# Mobility scaling factor :math:`c_3`. Typically 9. -# -# -# -# -# -# -# Time-dependent reduction of the stored (elastic) energy to account for recovery. -# -# -# -# Which type of recovery model. -# -# -# -# -# -# -# -# -# Reduction of the grain boundary migration speed due to the presence of dispersoids -# through which the total grain boundary area of the recrystallization front can be reduced. -# -# -# -# Which type of drag model. -# -# -# -# -# -# -# -# -# Parameter of the Zener-Smith drag model. -# -# -# -# Configuration-dependent constant which factorizes the drag pressure. -# -# -# -# -# Average surface energy of the grain-boundary-dispersoid-surface configuration -# which factorizes the drag pressure. -# -# -# -# -# Support point of the linearized curve of simulated time matching -# a specific support point of the average dispersoid radius. -# -# -# -# -# -# -# -# Support point of the linearized curve of the average dispersoid radius. -# -# -# -# -# -# -# -# -# -# Desired simulated time-temperature profile -# -# -# -# Support point of the linearized curve of simulated time matching -# a specific support point of the temperature. -# -# -# -# -# -# -# -# Support point of the linearized curve of the temperature. -# -# -# -# -# -# -# -# -# Criteria which enable to stop the simulation in a controlled manner. -# Whichever criterion is fulfilled first stops the simulation. -# -# -# -# Maximum recrystallized volume fraction. -# -# -# -# -# Maximum simulated physical time. -# -# -# -# -# Maximum number of iteration steps. -# -# -# -# -# -# Settings relevant for stable numerical integration. -# -# -# -# Maximum fraction equivalent to the migration of the -# fastest grain boundary in the system how much a cell -# may be consumed in a single iteration. -# -# -# -# -# Fraction of the total number of cells in the CA which -# should initially be allocated for offering cells in the -# recrystallization front. -# -# -# -# -# By how much more times should the already allocated memory -# be increased to offer space for storing states of cells -# in the recrystallization front. -# -# -# -# -# Should the cache for cells in the recrystallization front -# be defragmented on-the-fly. -# -# -# -# -# Heuristic recrystallized volume target values at which -# the cache for cells in the recrystallization front -# will be defragmented on-the-fly. -# -# -# -# -# -# -# -# -# -# List of recrystallized volume target values at which a -# snapshot of the CA state should be stored. -# -# The code documents summary statistics like recrystallized volume fraction -# for each iteration. However, snapshots of the microstructure can take much -# space as SCORE is able to evolve automata with up to :math:`1600^3` cells. -# Snapshot data document the current microstructure which includes the grain -# assigned to each of these cells plus the state of the recrystallization front. -# -# Despite these front data make up for approximately one order of magnitude -# less cells than represented in the domain, more numerical data have to be -# collected each cell in the front than just a grain identifier. -# -# -# -# -# -# -# -# -# -# Perform a statistical analyses of the results as it was -# proposed by M. Kühbach (solitary unit model ensemble approach). -# -# -# -# -# How many independent cellular automaton domains -# should be instantiated. -# -# -# -# -# Into how many time steps should the real time interval be discretized upon -# during post-processing the results with the solitary unit modeling approach. -# -# -# -# -# List of identifier for those domain which should be rendered. -# Identifier start from 0. -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml deleted file mode 100644 index 4532bd3c9b..0000000000 --- a/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml +++ /dev/null @@ -1,954 +0,0 @@ -category: application -doc: | - Application definition for storing results of the SCORE cellular automaton. - - The SCORE cellular automaton model for primary recrystallization is an - example of typical materials engineering applications used within the field - of so-called Integral Computational Materials Engineering (ICME) whereby - one can simulate the evolution of microstructures. - - Specifically the SCORE model can be used to simulate the growth of static - recrystallization nuclei. The model is described in the literature: - - * `M. Kühbach et al. `_ - * `C. Haase et al. `_ - * `M. Diehl et al. `_ -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_summary_stats: | - The total number of summary statistic log entries. - n_b: | - Number of boundaries of the bounding box or primitive to domain. - n_p: | - Number of parameter required for chosen orientation parameterization. - n_tex: | - Number of texture components identified. - d: | - Dimensionality. - c: | - Cardinality. - n_front: | - Number of active cells in the (recrystallization) front. - n_grains: | - Number of grains in the computer simulation. - -# inspect comments behind NXmicrostructure -type: group -NXmicrostructure_score_results(NXobject): - (NXentry): - definition(NX_CHAR): - enumeration: [NXmicrostructure_score_results] - simulation_identifier(NX_UINT): - doc: | - Simulation ID as an alias to refer to this simulation. - description(NX_CHAR): - doc: | - Discouraged free-text field to add further details to the computation. - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - exists: recommended - (NXuser): - exists: ['min', '0', 'max', 'unbounded'] - program1(NXprogram): - program_name: - \@version: - \@url: - exists: recommended - environment(NXobject): - exists: optional - doc: | - Programs and libraries representing the computational environment - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - coordinate_system_set(NXcoordinate_system_set): - rotation_handedness: - rotation_convention: - euler_angle_convention: - axis_angle_convention: - sign_convention: - sample_reference_frame(NXcoordinate_system): - type: - enumeration: [cartesian] - handedness: - enumeration: [right_handed] - origin: - enumeration: [front_bottom_left] - x_alias: - enumeration: [rolling_direction] - x_direction: - enumeration: [east] - y_alias: - enumeration: [transverse_direction] - y_direction: - enumeration: [in] - z_alias: - enumeration: [normal direction] - z_direction: - enumeration: [north] - discretization(NXmicrostructure): - exists: ['min', '1', 'max', '1'] - grid(NXcg_grid): - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - origin(NX_NUMBER): - symmetry: - cell_dimensions(NX_NUMBER): - extent(NX_UINT): - identifier_offset(NX_INT): - boundary(NXcg_polyhedron_set): - doc: | - A tight bounding box or sphere or bounding primitive about the grid. - - # a good example for a general bounding box description for such a grids of triclinic cells - # https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallelepiped - number_of_boundaries(NX_POSINT): - unit: NX_UNITLESS - doc: | - How many distinct boundaries are distinguished? - Most grids discretize a cubic or cuboidal region. In this case - six sides can be distinguished, each making an own boundary. - boundary_conditions(NX_INT): - unit: NX_UNITLESS - doc: | - The boundary conditions for each boundary: - - 0 - undefined - 1 - open - 2 - periodic - 3 - mirror - 4 - von Neumann - 5 - Dirichlet - dimensions: - rank: 1 - dim: [[1, 6]] - boundaries: - doc: | - Name of the boundaries. Left, right, front, back, bottom, top, - The field must have as many entries as there are number_of_boundaries. - dimensions: - rank: 1 - dim: [[1, 6]] - spatiotemporalID(NXobject): - exists: ['min', '1', 'max', 'unbounded'] - doc: | - Documentation of the spatiotemporal evolution - - # static quantities for which no change is modelled - # the typical lean summary statistics flattened - summary_statistics(NXobject): - doc: | - Summary quantities which are the result of some post-processing of the snapshot data - (averaging, integrating, interpolating) happening in for practical reasons though in while - running the simulation. Place used for storing descriptors from continuum mechanics - and thermodynamics at the scale of the entire ROI. - kinetics(NXprocess): - exists: optional - doc: | - Evolution of the recrystallized volume fraction over time. - time(NX_NUMBER): - unit: NX_TIME - doc: | - Evolution of the physical time not to be confused with wall-clock time or - profiling data. - dimensions: - rank: 1 - dim: [[1, n_summary_stats]] - iteration(NX_INT): - unit: NX_UNITLESS - doc: | - Iteration or increment counter. - temperature(NX_FLOAT): - unit: NX_TEMPERATURE - doc: | - Evolution of the simulated temperature over time. - dimensions: - rank: 1 - dim: [[1, n_summary_stats]] - recrystallized_volume_fraction(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Recrystallized volume fraction. - dimensions: - rank: 1 - dim: [[1, n_summary_stats]] - stress(NXprocess): - exists: optional - type: - doc: | - Which type of stress. - enumeration: [cauchy] - stress(NX_FLOAT): - unit: NX_ANY - doc: | - Applied external stress tensor on the ROI. - dimensions: - rank: 3 - dim: [[1, n_summary_stats], [2, 3], [3, 3]] - strain(NXprocess): - exists: optional - type: - doc: | - Which type of strain. - strain(NX_FLOAT): - unit: NX_ANY - doc: | - Applied external strain tensor on the ROI. - dimensions: - rank: 3 - dim: [[1, n_summary_stats], [2, 3], [3, 3]] - deformation_gradient(NXprocess): - exists: optional - type: - doc: | - Which type of deformation gradient. - enumeration: [piola] - value(NX_FLOAT): - unit: NX_ANY - doc: | - Applied deformation gradient tensor on the ROI. - dimensions: - rank: 3 - dim: [[1, n_summary_stats], [2, 3], [3, 3]] - magnetic_field(NXprocess): - exists: optional - strength(NX_FLOAT): - unit: NX_ANY - doc: | - Applied external magnetic field on the ROI. - dimensions: - rank: 3 - dim: [[1, n_summary_stats], [2, 3], [3, 3]] - electrical_field(NXprocess): - exists: optional - - # specify type of field - strength(NX_FLOAT): - unit: NX_ANY - doc: | - Applied external electrical field on the ROI. - dimensions: - rank: 3 - dim: [[1, n_summary_stats], [2, 3], [3, 3]] - - # the typically storage-costlier snapshot data - microstructureID(NXmicrostructure): - exists: ['min', '1', 'max', 'unbounded'] - time(NX_NUMBER): - iteration(NX_INT): - temperature(NX_FLOAT): - unit: NX_TEMPERATURE - doc: | - Simulated temperature for this snapshot. - x_value(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Current recrystallized volume fraction (taking fractional infections into - account). - x_target(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - Target value for which a snapshot was requested for the recrystallized volume - fraction. - - # optional places to store the grid for instance if it changes - grid(NXcg_grid): - exists: recommended - grain_identifier(NX_UINT): - exists: recommended - unit: NX_UNITLESS - doc: | - Grain identifier for each cell. - dimensions: - rank: 3 - dim: [[1, n_x], [2, n_y], [3, n_z]] - thread_identifier(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - Identifier of the OpenMP thread which processed this part of the grid. - dimensions: - rank: 3 - dim: [[1, n_x], [2, n_y], [3, n_z]] - crystal(NXobject): - representation: - exists: recommended - number_of_crystals(NX_UINT): - number_of_phases(NX_UINT): - crystal_identifier_offset(NX_INT): - crystal_identifier(NX_INT): - dimensions: - rank: 1 - dim: [[1, n_grains]] - phase_identifier_offset(NX_INT): - phase_identifier(NX_INT): - dimensions: - rank: 1 - dim: [[1, n_grains]] - volume(NX_NUMBER): - unit: NX_VOLUME - doc: | - Volume of each grain accounting also for partially transformed cells. - dimensions: - rank: 1 - dim: [[1, n_grains]] - - # SCORE specific - bunge_euler(NX_FLOAT): - unit: NX_ANGLE - doc: | - Bunge-Euler angle triplets for each grain. - dimensions: - rank: 2 - dim: [[1, n_grains], [2, 3]] - dislocation_density(NX_FLOAT): - exists: recommended - unit: NX_ANY - doc: | - Current value for the dislocation density as a measure of the remaining stored energy - in assumed crystal defects inside each grain. - dimensions: - rank: 1 - dim: [[1, n_grains]] - is_deformed(NX_BOOLEAN): - exists: recommended - doc: | - Is the grain deformed. - dimensions: - rank: 1 - dim: [[1, n_grains]] - is_recrystallized(NX_BOOLEAN): - exists: recommended - doc: | - Is the grain recrystallized. - dimensions: - rank: 1 - dim: [[1, n_grains]] - recrystallization_front(NXobject): - exists: recommended - doc: | - Details about those cells which in this time step represent the discrete - recrystallization front. - halo_region(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - Which cells are currently in a halo region of threads. - dimensions: - rank: 1 - dim: [[1, n_front]] - mobility_weight(NX_FLOAT): - exists: recommended - unit: NX_UNITLESS - doc: | - So-called mobility weight which is a scaling factor to - control the mobility of the grain boundary which is assumed - to sweep currently this volume. - dimensions: - rank: 1 - dim: [[1, n_front]] - coordinate(NX_NUMBER): - exists: recommended - unit: NX_UNITLESS - doc: | - The x, y, z grid coordinates of each cell in the recrystallization front. - dimensions: - rank: 2 - dim: [[1, n_front], [2, 3]] - deformed_grain_identifier(NX_UINT): - exists: recommended - unit: NX_UNITLESS - doc: | - Grain identifier assigned to each cell in the recrystallization front. - dimensions: - rank: 1 - dim: [[1, n_front]] - recrystallized_grain_identifier(NX_UINT): - exists: recommended - unit: NX_UNITLESS - doc: | - Grain identifier assigned to each nucleus which affected that cell in the - recrystallization front. - dimensions: - rank: 1 - dim: [[1, n_front]] - thread_identifier(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - Identifier of the OpenMP thread processing each cell in the recrystallization - front. - dimensions: - rank: 1 - dim: [[1, n_front]] - infection_direction(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - Hint about the direction from which the cell was infected. - dimensions: - rank: 1 - dim: [[1, n_front]] - - # performance(NXcs_profiling): - # exists: optional - # current_working_directory: - # command_line_call: - # exists: optional - # start_time(NX_DATE_TIME): - # exists: recommended - # end_time(NX_DATE_TIME): - # exists: recommended - # total_elapsed_time(NX_NUMBER): - # number_of_processes(NX_POSINT): - # number_of_threads(NX_POSINT): - # number_of_gpus(NX_POSINT): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2f9eac16bf0971abe8628a9dc4ae40b3db3ff2315b3c3ae0ae5d3fdeb01c93b0 -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The total number of summary statistic log entries. -# -# -# -# -# Number of boundaries of the bounding box or primitive to domain. -# -# -# -# -# Number of parameter required for chosen orientation parameterization. -# -# -# -# -# Number of texture components identified. -# -# -# -# -# Dimensionality. -# -# -# -# -# Cardinality. -# -# -# -# -# Number of active cells in the (recrystallization) front. -# -# -# -# -# Number of grains in the computer simulation. -# -# -# -# -# Application definition for storing results of the SCORE cellular automaton. -# -# The SCORE cellular automaton model for primary recrystallization is an -# example of typical materials engineering applications used within the field -# of so-called Integral Computational Materials Engineering (ICME) whereby -# one can simulate the evolution of microstructures. -# -# Specifically the SCORE model can be used to simulate the growth of static -# recrystallization nuclei. The model is described in the literature: -# -# * `M. Kühbach et al. <https://doi.org/10.1016/j.actamat.2016.01.068>`_ -# * `C. Haase et al. <https://doi.org/10.1016/j.actamat.2015.08.057>`_ -# * `M. Diehl et al. <https://doi.org/10.1088/1361-651X/ab51bd>`_ -# -# -# -# -# -# -# -# -# -# Simulation ID as an alias to refer to this simulation. -# -# -# -# -# Discouraged free-text field to add further details to the computation. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Programs and libraries representing the computational environment -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# A tight bounding box or sphere or bounding primitive about the grid. -# -# -# -# -# How many distinct boundaries are distinguished? -# Most grids discretize a cubic or cuboidal region. In this case -# six sides can be distinguished, each making an own boundary. -# -# -# -# -# The boundary conditions for each boundary: -# -# 0 - undefined -# 1 - open -# 2 - periodic -# 3 - mirror -# 4 - von Neumann -# 5 - Dirichlet -# -# -# -# -# -# -# -# Name of the boundaries. Left, right, front, back, bottom, top, -# The field must have as many entries as there are number_of_boundaries. -# -# -# -# -# -# -# -# -# -# Documentation of the spatiotemporal evolution -# -# -# -# -# Summary quantities which are the result of some post-processing of the snapshot data -# (averaging, integrating, interpolating) happening in for practical reasons though in while -# running the simulation. Place used for storing descriptors from continuum mechanics -# and thermodynamics at the scale of the entire ROI. -# -# -# -# Evolution of the recrystallized volume fraction over time. -# -# -# -# Evolution of the physical time not to be confused with wall-clock time or -# profiling data. -# -# -# -# -# -# -# -# Iteration or increment counter. -# -# -# -# -# Evolution of the simulated temperature over time. -# -# -# -# -# -# -# -# Recrystallized volume fraction. -# -# -# -# -# -# -# -# -# -# Which type of stress. -# -# -# -# -# -# -# -# Applied external stress tensor on the ROI. -# -# -# -# -# -# -# -# -# -# -# -# Which type of strain. -# -# -# -# -# Applied external strain tensor on the ROI. -# -# -# -# -# -# -# -# -# -# -# -# Which type of deformation gradient. -# -# -# -# -# -# -# -# Applied deformation gradient tensor on the ROI. -# -# -# -# -# -# -# -# -# -# -# -# Applied external magnetic field on the ROI. -# -# -# -# -# -# -# -# -# -# -# -# -# Applied external electrical field on the ROI. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Simulated temperature for this snapshot. -# -# -# -# -# Current recrystallized volume fraction (taking fractional infections into -# account). -# -# -# -# -# Target value for which a snapshot was requested for the recrystallized volume -# fraction. -# -# -# -# -# -# -# Grain identifier for each cell. -# -# -# -# -# -# -# -# -# -# Identifier of the OpenMP thread which processed this part of the grid. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Volume of each grain accounting also for partially transformed cells. -# -# -# -# -# -# -# -# -# Bunge-Euler angle triplets for each grain. -# -# -# -# -# -# -# -# -# Current value for the dislocation density as a measure of the remaining stored energy -# in assumed crystal defects inside each grain. -# -# -# -# -# -# -# -# Is the grain deformed. -# -# -# -# -# -# -# -# Is the grain recrystallized. -# -# -# -# -# -# -# -# -# Details about those cells which in this time step represent the discrete -# recrystallization front. -# -# -# -# Which cells are currently in a halo region of threads. -# -# -# -# -# -# -# -# So-called mobility weight which is a scaling factor to -# control the mobility of the grain boundary which is assumed -# to sweep currently this volume. -# -# -# -# -# -# -# -# The x, y, z grid coordinates of each cell in the recrystallization front. -# -# -# -# -# -# -# -# -# Grain identifier assigned to each cell in the recrystallization front. -# -# -# -# -# -# -# -# Grain identifier assigned to each nucleus which affected that cell in the -# recrystallization front. -# -# -# -# -# -# -# -# Identifier of the OpenMP thread processing each cell in the recrystallization -# front. -# -# -# -# -# -# -# -# Hint about the direction from which the cell was infected. -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXmicrostructure_slip_system.yaml b/contributed_definitions/nyaml/NXmicrostructure_slip_system.yaml deleted file mode 100644 index 488da7c104..0000000000 --- a/contributed_definitions/nyaml/NXmicrostructure_slip_system.yaml +++ /dev/null @@ -1,121 +0,0 @@ -category: base -doc: | - Base class for describing a set of crystallographic slip systems. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n: | - Number of slip systems. -type: group -NXmicrostructure_slip_system(NXobject): - lattice_type(NX_CHAR): - doc: | - Bravais lattice type - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, trigonal, hexagonal, cubic] - miller_plane(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Array of Miller indices which describe the crystallographic planes. - dimensions: - rank: 2 - dim: [[1, n], [2, i]] - - # fastest changing dimension needs to be i and not 3 because for instance for hexagonal hkil notation is used - miller_direction(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Array of Miller indices which describe the crystallographic direction. - dimensions: - rank: 2 - dim: [[1, n], [2, i]] - is_specific(NX_BOOLEAN): - unit: NX_UNITLESS - doc: | - For each slip system a marker whether the specified Miller indices refer to - a specific or a crystallographic equivalent set of the slip system. - dimensions: - rank: 1 - dim: [[1, n]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 9998fb9937b87e1135df6fe1db659d42a69f77a9c7d2acb969b70c99a84b339a -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of slip systems. -# -# -# -# -# Base class for describing a set of crystallographic slip systems. -# -# -# -# Bravais lattice type -# -# -# -# -# -# -# -# -# -# -# -# -# -# Array of Miller indices which describe the crystallographic planes. -# -# -# -# -# -# -# -# -# -# Array of Miller indices which describe the crystallographic direction. -# -# -# -# -# -# -# -# -# For each slip system a marker whether the specified Miller indices refer to -# a specific or a crystallographic equivalent set of the slip system. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXpolarizer_opt.yaml b/contributed_definitions/nyaml/NXpolarizer_opt.yaml deleted file mode 100644 index 9342882b13..0000000000 --- a/contributed_definitions/nyaml/NXpolarizer_opt.yaml +++ /dev/null @@ -1,411 +0,0 @@ -category: base -doc: | - An optical polarizer. - - Information on the properties of polarizer is provided e.g. - [here](https://www.rp-photonics.com/polarizers.html). -symbols: - N_spectrum: | - Size of the wavelength array for which the refractive index of the material - and/or coating is given. - N_spectrum_RT: | - Size of the wavelength array for which the reflectance or transmission of - the polarizer is given. - -# A draft of a new base class to describe an optical polarizer -# (NXpolarizer describes a spin polarizer) -type: group -NXpolarizer_opt(NXobject): - type: - doc: | - Type of the polarizer (e.g. dichroic, linear, circular etc.) - enumeration: [dichroic, linear, circular, Glan-Thompson prism, Nicol prism, Glan-Taylor prism, Glan-Focault prism, Wollaston prism, Normarski prism, Senarmont prism, thin-film polarizer, wire grid polarizer, other] - - # ??? Any other common polarizer types ??? - type_other: - doc: | - If you selected 'other' in type specify what it is. - polarizer_angle(NX_NUMBER): - exists: recommended - unit: NX_ANGLE - doc: | - Angle of the polarizer. - acceptance_angle(NX_NUMBER): - exists: recommended - unit: NX_ANGLE - doc: | - Acceptance angle of the polarizer (range). - dimensions: - rank: 1 - dim: [[1, 2]] - (NXshape): - exists: recommended - doc: | - Describe the geometry (shape, dimension etc.) of the device. - Specify the dimensions in 'SHAPE/size'. A sketch of the device should be - provided in the 'sketch(NXdata)' field to clarify (i) the shape and - dimensions of the device, and (ii) the input and outputs (i.e. the - direction of the incoming and outcoming (split) beams). - - # !!! NOTE: this class is the same as for NXbeam_path !!! - shape: - doc: | - Describe the shape (plate, cube, wedged, prism etc.). - enumeration: [cube, cylinder, plate, prism, wedged, other] - other_shape: - doc: | - If you chose 'other' in 'shape' describe what it is. - sketch(NXdata): - doc: | - Sketch of thedevice showing its geometry. The paths of the - incoming and outgoing beam should be illustrated and labelled (0 for - the incoming beam, and 1, 2,..., N_outputs for the outputs). - size: - doc: | - Physical extent of the device. The device might be made up of one or - more objects (NX_objects). The meaning and location of the axes used - will vary according to the value of the 'shape' variable. 'N_shapepar' - defines how many parameters: - - * For 'cube' the parameters are (width, length). - * For 'cylinder' the parameters are (diameter, length). - * For 'plate' the parameters are (width, height, length). - * For 'prism' the parameters are (width, height, length). - * For 'wedged' the parameters are (width, height, shortest length). - The wedge angle should be provided in 'SHAPE/wedge_angle'. - * For 'other' the parameters may be (A, B, C, ...) with the labels - defined in the sketch plotted in 'SHAPE/sketch'. - dimensions: - rank: 2 - dim: [[1, N_objects], [2, N_shapepar]] - wedge_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Wedge angle if 'shape' is 'wedged'. - wavelength_range(NX_FLOAT): - exists: recommended - unit: NX_WAVELENGTH - doc: | - Wavelength range for which the polarizer is designed. Enter the minimum - and maximum wavelength (lower and upper limit) of the range. - dimensions: - rank: 1 - dim: [[1, 2]] - substrate(NXsample): - doc: | - Properties of the substrate material of the polarizer. If the device has - a coating specify the coating material and its properties in 'coating'. - substrate_material: - doc: | - Specify the substrate material of the polarizer. - substrate_thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - Thickness of the polarizer substrate. - index_of_refraction(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Complex index of refraction of the polarizer material. Specify at given - spectral values (wavelength, energy, wavenumber etc.). - dimensions: - rank: 2 - dim: [[1, 2], [2, N_spectrum]] - COATING(NXsample): - - # Used captial letters for COATING so that more than one can be defined if - # the device has different coatings on the front and back side. - doc: | - If the device has a coating describe the material and its properties. - Some basic information can be found e.g. [here] - (https://www.opto-e.com/basics/reflection-transmission-and-coatings). - If the back and front side of the polarizer are coated with different - materials, you may define two coatings (e.g. COATING1 and COATING2). - coating_type: - doc: | - Specify the coating type (e.g. dielectric, anti-reflection (AR), - multilayer coating etc.). - coating_material: - doc: | - Describe the coating material (e.g. MgF2). - coating_thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - Thickness of the coating. - index_of_refraction_coating(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Complex index of refraction of the coating. Specify at given spectral - values (wavelength, energy, wavenumber etc.). - dimensions: - rank: 2 - dim: [[1, 2], [2, N_spectrum_coating]] - extinction_ratio(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Extinction ratio (maximum to minimum transmission). - dimensions: - rank: 1 - dim: [[1, N_spectrum]] - reflection(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Reflection of the polarizer at given wavelength values. - dimensions: - rank: 1 - dim: [[1, N_spectrum_RT]] - transmission(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Transmission of the polarizer at given wavelength values. - dimensions: - rank: 1 - dim: [[1, N_spectrum_RT]] - - # anything missing? - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# ecf9dc916ff478427f8158ca51caa86321464ecf2e6434941e3f62a8b6dd0d3b -# -# -# -# -# -# -# -# -# Size of the wavelength array for which the refractive index of the material -# and/or coating is given. -# -# -# -# -# Size of the wavelength array for which the reflectance or transmission of -# the polarizer is given. -# -# -# -# -# An optical polarizer. -# -# Information on the properties of polarizer is provided e.g. -# [here](https://www.rp-photonics.com/polarizers.html). -# -# -# -# Type of the polarizer (e.g. dichroic, linear, circular etc.) -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If you selected 'other' in type specify what it is. -# -# -# -# -# Angle of the polarizer. -# -# -# -# -# Acceptance angle of the polarizer (range). -# -# -# -# -# -# -# -# Describe the geometry (shape, dimension etc.) of the device. -# Specify the dimensions in 'SHAPE/size'. A sketch of the device should be -# provided in the 'sketch(NXdata)' field to clarify (i) the shape and -# dimensions of the device, and (ii) the input and outputs (i.e. the -# direction of the incoming and outcoming (split) beams). -# -# -# -# -# Describe the shape (plate, cube, wedged, prism etc.). -# -# -# -# -# -# -# -# -# -# -# -# -# If you chose 'other' in 'shape' describe what it is. -# -# -# -# -# Sketch of thedevice showing its geometry. The paths of the -# incoming and outgoing beam should be illustrated and labelled (0 for -# the incoming beam, and 1, 2,..., N_outputs for the outputs). -# -# -# -# -# Physical extent of the device. The device might be made up of one or -# more objects (NX_objects). The meaning and location of the axes used -# will vary according to the value of the 'shape' variable. 'N_shapepar' -# defines how many parameters: -# -# * For 'cube' the parameters are (width, length). -# * For 'cylinder' the parameters are (diameter, length). -# * For 'plate' the parameters are (width, height, length). -# * For 'prism' the parameters are (width, height, length). -# * For 'wedged' the parameters are (width, height, shortest length). -# The wedge angle should be provided in 'SHAPE/wedge_angle'. -# * For 'other' the parameters may be (A, B, C, ...) with the labels -# defined in the sketch plotted in 'SHAPE/sketch'. -# -# -# -# -# -# -# -# -# Wedge angle if 'shape' is 'wedged'. -# -# -# -# -# -# Wavelength range for which the polarizer is designed. Enter the minimum -# and maximum wavelength (lower and upper limit) of the range. -# -# -# -# -# -# -# -# Properties of the substrate material of the polarizer. If the device has -# a coating specify the coating material and its properties in 'coating'. -# -# -# -# Specify the substrate material of the polarizer. -# -# -# -# -# Thickness of the polarizer substrate. -# -# -# -# -# Complex index of refraction of the polarizer material. Specify at given -# spectral values (wavelength, energy, wavenumber etc.). -# -# -# -# -# -# -# -# -# -# -# If the device has a coating describe the material and its properties. -# Some basic information can be found e.g. [here] -# (https://www.opto-e.com/basics/reflection-transmission-and-coatings). -# If the back and front side of the polarizer are coated with different -# materials, you may define two coatings (e.g. COATING1 and COATING2). -# -# -# -# Specify the coating type (e.g. dielectric, anti-reflection (AR), -# multilayer coating etc.). -# -# -# -# -# Describe the coating material (e.g. MgF2). -# -# -# -# -# Thickness of the coating. -# -# -# -# -# Complex index of refraction of the coating. Specify at given spectral -# values (wavelength, energy, wavenumber etc.). -# -# -# -# -# -# -# -# -# -# Extinction ratio (maximum to minimum transmission). -# -# -# -# -# -# -# -# Reflection of the polarizer at given wavelength values. -# -# -# -# -# -# -# -# Transmission of the polarizer at given wavelength values. -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXpositioner_sts.yaml b/contributed_definitions/nyaml/NXpositioner_sts.yaml deleted file mode 100644 index d031d65fb9..0000000000 --- a/contributed_definitions/nyaml/NXpositioner_sts.yaml +++ /dev/null @@ -1,552 +0,0 @@ -category: base -doc: | - A generic positioner such as a motor or piezo-electric transducer. -type: group -NXpositioner_sts(NXobject): - name: - doc: | - symbolic or mnemonic name (one word) - description: - doc: | - description of positioner - value(NX_NUMBER): - unit: NX_ANY - doc: | - best known value of positioner - need [n] as may be scanned - dimensions: - rank: 1 - dim: [[1, n]] - raw_value(NX_NUMBER): - unit: NX_ANY - doc: | - raw value of positioner - need [n] as may be scanned - dimensions: - rank: 1 - dim: [[1, n]] - target_value(NX_NUMBER): - unit: NX_ANY - doc: | - targeted (commanded) value of positioner - need [n] as may be scanned - dimensions: - rank: 1 - dim: [[1, n]] - tolerance(NX_NUMBER): - unit: NX_ANY - doc: | - maximum allowable difference between target_value and value - dimensions: - rank: 1 - dim: [[1, n]] - soft_limit_min(NX_NUMBER): - unit: NX_ANY - doc: | - minimum allowed limit to set value - soft_limit_max(NX_NUMBER): - unit: NX_ANY - doc: | - maximum allowed limit to set value - velocity(NX_NUMBER): - unit: NX_ANY - doc: | - velocity of the positioner (distance moved per unit time) - acceleration_time(NX_NUMBER): - unit: NX_ANY - doc: | - time to ramp the velocity up to full speed - controller_record: - doc: | - Hardware device record, e.g. EPICS process variable, taco/tango ... - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a positioner. - (NXtransformations): - doc: | - 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. - position(NXtransformations): - doc: | - To clarify the frame laboratory frame. The scanning area in x, y, and z position in the - frame. - z_contronller(NX_NUMBER): - doc: | - This controllers task is to continuously adjust the Z position of the stm tip in order - to keep the selected control signal as close as possible to the Set Point. Different control - signals lead to different contronller beahvior. - z_offset(NX_NUMBER): - unit: NX_LENGTH - doc: | - Offset added to the initial averaged position Zaver before starting to swepp. - tip_position_z(NX_NUMBER): - unit: NX_LENGTH - doc: | - Indicate the tip position Z between tip and sample. The tip position can also be varied when - the controller is not running. - controller_name(NX_CHAR): - doc: | - Controller name. This name which will be displayed at places where you can select a - controller. - setpoint(NX_NUMBER): - unit: NX_CURRENT - doc: | - Set Point is the desired value of the control signal. It can be set by editing the number - or using the slider bar. Click the "Set" button above the input field to use the actual - value as Set Point. The slider shows the Set Point as well as the current value. - tip_lift(NX_NUMBER): - unit: NX_LENGTH - doc: | - Lifts the tip by the specified amount when then controller is switched off. This can be - a positive or a negative number, i.e. the tip can also be moved towards the sample. Be - careful with sign and value when using this feature. - switch_off_delay(NX_NUMBER): - unit: NX_TIME - doc: | - Use this parameter for a reproducible position when switching off the Z-controller. - When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues - to run for the specified time and averages the Z position. - z_controller_hold(NX_BOOLEAN): - doc: | - (In bias spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) during - the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters - are disabled. - final_z(NX_NUMBER): - unit: NX_LENGTH - doc: | - The final z-position during the bias spectroscopy scan. The availability of values is - related to the mode of scanning. - - # scan_control(NXcollection): - # doc: | - # To control the tip and various scan operations. - scanfield(NX_NUMBER): - unit: NX_LENGTH - doc: | - Configure the scan frame like x position; y position; width; height. - pixels_line(NX_NUMBER): - unit: NX_COUNT - doc: | - Scan resolution by setting the Lines equal to Pixels. - lines(NX_NUMBER): - unit: NX_ANY - doc: | - Define the image resolution. - speed_forw(NX_NUMBER): - unit: NX_ANY - doc: | - Define the scan forward speed in the forward direction. - speed_backw(NX_NUMBER): - unit: NX_ANY - doc: | - Define the scan backward speed in the forward direction. - piezo_calibration: - doc: | - Piezo calibration module is used to define the X Y Z piezos calibration. - active_calib(NX_CHAR): - doc: | - The name of caliberation type. - calib_N(NX_NUMBER): - - # z_contronller(NXcollection): - # name: - # doc: | - # This controllers task is to continuously adjust the Z position of the stm tip in order to keep the selected control signal as close as possible to the Set Point. Different contro; signals lead to different contronller beahvior. - # z_offset(NX_NUMBER): - # doc: Offset added to the initial averaged position Zaver before starting to swepp. - # unit: NX_LENGTH - # tip_position_z(NX_NUMBER): - # doc: Indicate the tip position Z between tip and sample. The tip position can also be varied when the controller is not running. - # unit: NX_LENGTH - # controller_name: - # doc: Controller name. This name which will be displayed at places where you can select a controller. - # setpoint(NX_NUMBER): - # doc: Set Point is the desired value of the control signal. It can be set by editing the number or using the slider bar. Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. - # unit: NX_CUTTENT - # setpoint_unit: - # doc: The unit of setpoint during the scanning. - p_gain(NX_NUMBER): - unit: NX_UNITLESS - doc: | - The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and :math:`P/T` - (proportional gain/time constant). The formula for the controller in the frequency domain is: - :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. - The integral gain and time constant are related as follows: :math:`I = P/T`. - i_gain(NX_NUMBER): - unit: NX_UNITLESS - doc: | - The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and - P/T (proportional gain/time constant). The formula for the controller in the frequency - domain is: :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. The integral gain and time constant are related - as follows: `:math:I = P/T`. - time_const(NX_NUMBER): - unit: NX_TIME - doc: | - The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and - :math:`P/T` (proportional gain/time constant). The formula for the controller in the frequency - domain is: :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. The integral gain and time constant are related - as follows: :math:`I = P/T`. - - # tip_lift(NX_NUMBER): - # doc: | - # Lifts the tip by the specified amount when then controller is switched off. This - # can be a positive or a negative number, i.e. the tip can also be moved towards the sample. - # Be careful with sign and value when using this feature. - # unit: NX_LENGTH - # switch_off_delay(NX_NUMBER): - # doc: | - # Use this parameter for a reproducible position when switching off the Z-controller. - # When >0 and the Z-controller is switched off, it doesn't switch off immediately but - # continues to run for the specified time and averages the Z position. - # unit: NX_TIME - # z_controller_hold(NX_CHAR): - # doc: | - # (In biase spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) - # during the sweep. It is selected by default. When deselected, Z-offset and Z control time - # parameters are disabled. - scan_contronller(NX_NUMBER): - doc: | - There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order - piezo characteristics to compensate for it. The following equation shows the interpretation - of the 2nd order correction parameter: For the X-piezo: - :math:`Ux = 1/cx · X + cxx · X2`; with units: :math:`[V] = [V/m] · [m] + [V/m2] · [m2]` - where cx is the calibration of the piezo X and cxx is the 2nd order correction. :math:`(V/m^2)` - drift(NX_NUMBER): - unit: NX_ANY - doc: | - There are 2 parameters in X and Y directions. Define the drift speed for all three axes. - When the compensation is on, the piezos will start to move at that speed. - drift_correction_status(NX_CHAR): - doc: | - Use the button to turn on/off the drift compensation. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2037b2a997d9aa6a5ef6038ba27b83442bfb9fac0da253471c30ea939e9e0709 -# -# -# -# -# -# A generic positioner such as a motor or piezo-electric transducer. -# -# -# -# symbolic or mnemonic name (one word) -# -# -# -# -# description of positioner -# -# -# -# -# best known value of positioner - need [n] as may be scanned -# -# -# -# -# -# -# -# raw value of positioner - need [n] as may be scanned -# -# -# -# -# -# -# -# targeted (commanded) value of positioner - need [n] as may be scanned -# -# -# -# -# -# -# -# maximum allowable difference between target_value and value -# -# -# -# -# -# -# -# minimum allowed limit to set value -# -# -# -# -# maximum allowed limit to set value -# -# -# -# -# velocity of the positioner (distance moved per unit time) -# -# -# -# -# time to ramp the velocity up to full speed -# -# -# -# -# Hardware device record, e.g. EPICS process variable, taco/tango ... -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a positioner. -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# -# To clarify the frame laboratory frame. The scanning area in x, y, and z position in the -# frame. -# -# -# -# -# This controllers task is to continuously adjust the Z position of the stm tip in order -# to keep the selected control signal as close as possible to the Set Point. Different control -# signals lead to different contronller beahvior. -# -# -# -# -# Offset added to the initial averaged position Zaver before starting to swepp. -# -# -# -# -# Indicate the tip position Z between tip and sample. The tip position can also be varied when -# the controller is not running. -# -# -# -# -# Controller name. This name which will be displayed at places where you can select a -# controller. -# -# -# -# -# Set Point is the desired value of the control signal. It can be set by editing the number -# or using the slider bar. Click the "Set" button above the input field to use the actual -# value as Set Point. The slider shows the Set Point as well as the current value. -# -# -# -# -# Lifts the tip by the specified amount when then controller is switched off. This can be -# a positive or a negative number, i.e. the tip can also be moved towards the sample. Be -# careful with sign and value when using this feature. -# -# -# -# -# Use this parameter for a reproducible position when switching off the Z-controller. -# When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues -# to run for the specified time and averages the Z position. -# -# -# -# -# (In bias spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) during -# the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters -# are disabled. -# -# -# -# -# The final z-position during the bias spectroscopy scan. The availability of values is -# related to the mode of scanning. -# -# -# -# -# -# Configure the scan frame like x position; y position; width; height. -# -# -# -# -# Scan resolution by setting the Lines equal to Pixels. -# -# -# -# -# Define the image resolution. -# -# -# -# -# Define the scan forward speed in the forward direction. -# -# -# -# -# Define the scan backward speed in the forward direction. -# -# -# -# -# Piezo calibration module is used to define the X Y Z piezos calibration. -# -# -# -# -# The name of caliberation type. -# -# -# -# -# -# -# The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and :math:`P/T` -# (proportional gain/time constant). The formula for the controller in the frequency domain is: -# :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. -# The integral gain and time constant are related as follows: :math:`I = P/T`. -# -# -# -# -# The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and -# P/T (proportional gain/time constant). The formula for the controller in the frequency -# domain is: :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. The integral gain and time constant are related -# as follows: `:math:I = P/T`. -# -# -# -# -# The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and -# :math:`P/T` (proportional gain/time constant). The formula for the controller in the frequency -# domain is: :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. The integral gain and time constant are related -# as follows: :math:`I = P/T`. -# -# -# -# -# -# There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order -# piezo characteristics to compensate for it. The following equation shows the interpretation -# of the 2nd order correction parameter: For the X-piezo: -# :math:`Ux = 1/cx · X + cxx · X2`; with units: :math:`[V] = [V/m] · [m] + [V/m2] · [m2]` -# where cx is the calibration of the piezo X and cxx is the 2nd order correction. :math:`(V/m^2)` -# -# -# -# -# There are 2 parameters in X and Y directions. Define the drift speed for all three axes. -# When the compensation is on, the piezos will start to move at that speed. -# -# -# -# -# Use the button to turn on/off the drift compensation. -# -# -# diff --git a/contributed_definitions/nyaml/NXquadric.yaml b/contributed_definitions/nyaml/NXquadric.yaml deleted file mode 100644 index a4d0e6b5e5..0000000000 --- a/contributed_definitions/nyaml/NXquadric.yaml +++ /dev/null @@ -1,117 +0,0 @@ -category: base -doc: | - definition of a quadric surface. -type: group -NXquadric(NXobject): - parameters(NX_NUMBER): - unit: NX_PER_LENGTH - doc: | - Ten real values of the matrix that defines the quadric surface - in projective space. Ordered Q11, Q12, Q13, Q22, Q23, Q33, P1, - P2, P3, R. Takes a units attribute of dimension reciprocal - length. R is scalar. P has dimension reciprocal length, and the - given units. Q has dimension reciprocal length squared, and - units the square of those given. - dimensions: - dim: [[1, 10]] - surface_type: - exists: ['min', '0', 'max', '1'] - doc: | - An optional description of the form of the quadric surface: - enumeration: [ELLIPSOID, ELLIPTIC_PARABOLOID, HYPERBOLIC_PARABOLOID, ELLIPTIC_HYPERBOLOID_OF_1_SHEET, ELLIPTIC_HYPERBOLOID_OF_2_SHEETS, ELLIPTIC_CONE, ELLIPTIC_CYLINDER, HYPERBOLIC_CYLINDER, PARABOLIC_CYLINDER, SPHEROID, SPHERE, PARABOLOID, HYPERBOLOID_1_SHEET, HYPERBOLOID_2_SHEET, CONE, CYLINDER, PLANE, IMAGINARY, UNKNOWN] - depends_on(NX_CHAR): - exists: ['min', '0', 'max', '1'] - doc: | - Path to an :ref:`NXtransformations` that defining the axis on - which the orientation of the surface depends. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 561221af2771bd8071a409c39b044ea2decbb9919d618c5ff2328118acd876f9 -# -# -# -# -# definition of a quadric surface. -# -# -# Ten real values of the matrix that defines the quadric surface -# in projective space. Ordered Q11, Q12, Q13, Q22, Q23, Q33, P1, -# P2, P3, R. Takes a units attribute of dimension reciprocal -# length. R is scalar. P has dimension reciprocal length, and the -# given units. Q has dimension reciprocal length squared, and -# units the square of those given. -# -# -# -# -# -# -# -# An optional description of the form of the quadric surface: -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Path to an :ref:`NXtransformations` that defining the axis on -# which the orientation of the surface depends. -# -# -# diff --git a/contributed_definitions/nyaml/NXquadrupole_magnet.yaml b/contributed_definitions/nyaml/NXquadrupole_magnet.yaml deleted file mode 100644 index 6ad5accd98..0000000000 --- a/contributed_definitions/nyaml/NXquadrupole_magnet.yaml +++ /dev/null @@ -1,84 +0,0 @@ -category: base -doc: | - definition for a quadrupole magnet. -type: group -NXquadrupole_magnet(NXobject): - description(NX_CHAR): - doc: | - extended description of the magnet. - beamline_distance(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - define position of beamline element relative to production target - set_current(NX_FLOAT): - unit: NX_CURRENT - exists: ['min', '0', 'max', '1'] - doc: | - current set on supply. - read_current(NXlog): - exists: ['min', '0', 'max', '1'] - doc: | - current read from supply. - value: - unit: NX_CURRENT - read_voltage(NXlog): - exists: ['min', '0', 'max', '1'] - doc: | - voltage read from supply. - value: - unit: NX_VOLTAGE - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 38cf74762b9540887c2a87a619c745a2abc1ad7920cb536a2b068b5fa375bfef -# -# -# -# -# definition for a quadrupole magnet. -# -# extended description of the magnet. -# -# -# define position of beamline element relative to production target -# -# -# current set on supply. -# -# -# current read from supply. -# -# -# -# voltage read from supply. -# -# -# diff --git a/contributed_definitions/nyaml/NXregion.yaml b/contributed_definitions/nyaml/NXregion.yaml deleted file mode 100644 index cc26458ac7..0000000000 --- a/contributed_definitions/nyaml/NXregion.yaml +++ /dev/null @@ -1,340 +0,0 @@ -category: base -doc: | - Geometry and logical description of a region of data in a parent group. When used, it could be a child group to, say, :ref:`NXdetector`. - - This can be used to describe a subset of data used to create downsampled data or to derive - some data from that subset. - - Note, the fields for the rectangular region specifiers follow HDF5’s dataspace hyperslab parameters - (see https://portal.hdfgroup.org/display/HDF5/H5S_SELECT_HYPERSLAB). Note when **block** :math:`= 1`, - then **stride** :math:`\equiv` **step** in Python slicing. - - For example, a ROI sum of an area starting at index of [20,50] and shape [220,120] in image data:: - - detector:NXdetector/ - data[60,256,512] - region:NXregion/ - @region_type = "rectangular" - parent = "data" - start = [20,50] - count = [220,120] - statistics:NXdata/ - @signal = "sum" - sum[60] - - the ``sum`` dataset contains the summed areas in each frame. - Another example, a hyperspectral image downsampled 16-fold in energy:: - - detector:NXdetector/ - data[128,128,4096] - region:NXregion/ - @region_type = "rectangular" - parent = "data" - start = [2] - count = [20] - stride = [32] - block = [16] - downsampled:NXdata/ - @signal = "maximum" - @auxiliary_signals = "copy" - maximum[128,128,20] - copy[128,128,320] - - the ``copy`` dataset selects 20 16-channel blocks that start 32 channels apart, - the ``maximum`` dataset will show maximum values in each 16-channel block - in every spectra. -symbols: - doc: | - These symbols will denote how the shape of the parent group's data field, - - .. math:: (D_0, ..., D_{\mathbf{O}-1}, d_0, ..., d_{\mathbf{R}-1}) - - could be split into a left set of **O** outer dimensions, :math:`\boldsymbol{D}`, - and a right set of **R** region dimensions, :math:`\boldsymbol{d}`, - where the data field has rank **O** + **R**. Note **O** :math:`>= 0`. - O: | - Outer rank - R: | - Region rank -type: group -NXregion(NXobject): - \@region_type: - exists: optional - doc: | - This is ``rectangular`` to describe the region as a hyper-rectangle in - the index space of its parent group's data field. - enumeration: [rectangular] - parent: - doc: | - The name of data field in the parent group or the path of a data field relative - to the parent group (so it could be a field in a subgroup of the parent group) - parent_mask: - doc: | - The name of an optional mask field in the parent group with rank :math:`\boldsymbol{R}` and - dimensions :math:`\boldsymbol{d}`. For example, this could be ``pixel_mask`` of an - :ref:`NXdetector`. - start(NX_NUMBER): - exists: recommended - doc: | - The starting position for region in detector data field array. - This is recommended as it also defines the region rank. - If omitted then defined as an array of zeros. - dimensions: - rank: 1 - dim: [[1, R]] - count(NX_INT): - exists: recommended - doc: | - The number of blocks or items in the hyperslab selection. - If omitted then defined as an array of dimensions that take into account - the other hyperslab selection fields to span the parent data field's shape. - dimensions: - rank: 1 - dim: [[1, R]] - stride(NX_INT): - doc: | - An optional field to define striding used to downsample data. - If omitted then defined as an array of ones. - dimensions: - rank: 1 - dim: [[1, R]] - block(NX_INT): - doc: | - An optional field to define the block size used to copy or downsample data. In the - :math:`i`-th dimension, if :math:`\mathbf{block}[i] < \mathbf{stride}[i]` - then the downsampling blocks have gaps between them; when ``block`` matches ``stride`` - then the blocks are contiguous; otherwise the blocks overlap. - If omitted then defined as an array of ones. - dimensions: - rank: 1 - dim: [[1, R]] - scale(NX_NUMBER): - doc: | - An optional field to define a divisor for scaling of reduced data. For example, in a - downsampled sum, it can reduce the maximum values to fit in the domain of the result - data type. In an image that is downsampled by summing 2x2 blocks, using - :math:`\mathrm{scale}=4` allows the result to fit in the same integer type dataset as - the parent dataset. - If omitted then no scaling occurs. - dimensions: - rank: 1 - dim: [[1, R]] - downsampled(NXdata): - doc: | - An optional group containing data copied/downsampled from parent group’s data. Its dataset name - must reflect how the downsampling is done over each block. So it could be a reduction operation - such as sum, minimum, maximum, mean, mode, median, etc. If downsampling is merely copying each - block then use "copy" as the name. Where more than one downsample dataset is written - (specified with ``@signal``) then add ``@auxiliary_signals`` listing the others. In the copy case, - the field should have a shape of :math:`(D_0, ..., D_{\mathbf{O}-1}, \mathbf{block}[0] * \mathbf{count}[0], ..., \mathbf{block}[\mathbf{R}-1] * \mathbf{count}[\mathbf{R}-1])`, - otherwise the expected shape is :math:`(D_0, ..., D_{\mathbf{O}-1}, \mathbf{count}[0], ..., \mathbf{count}[\mathbf{R}-1])`. - - The following figure shows how blocks are used in downsampling: - - .. figure:: region/NXregion-example.png - :width: 60% - - A selection with :math:`\mathbf{start}=2, \mathbf{count}=4, \mathbf{stride}=3, \mathbf{block}=2` from - a dataset with shape [13] will result in the ``reduce`` dataset of shape [4] and a ``copy`` dataset of shape [8]. - statistics(NXdata): - doc: | - An optional group containing any statistics derived from the region in parent group’s data - such as sum, minimum, maximum, mean, mode, median, rms, variance, etc. Where more than one - statistical dataset is written (specified with ``@signal``) then add ``@auxiliary_signals`` - listing the others. All data fields should have shapes of :math:`\boldsymbol{D}`. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# eac98063430202fc769007d86a644cc5545202b88a03f439afcd64cee8335862 -# -# -# -# -# -# -# These symbols will denote how the shape of the parent group's data field, -# -# .. math:: (D_0, ..., D_{\mathbf{O}-1}, d_0, ..., d_{\mathbf{R}-1}) -# -# could be split into a left set of **O** outer dimensions, :math:`\boldsymbol{D}`, -# and a right set of **R** region dimensions, :math:`\boldsymbol{d}`, -# where the data field has rank **O** + **R**. Note **O** :math:`>= 0`. -# -# Outer rank -# Region rank -# -# -# Geometry and logical description of a region of data in a parent group. When used, it could be a child group to, say, :ref:`NXdetector`. -# -# This can be used to describe a subset of data used to create downsampled data or to derive -# some data from that subset. -# -# Note, the fields for the rectangular region specifiers follow HDF5’s dataspace hyperslab parameters -# (see https://portal.hdfgroup.org/display/HDF5/H5S_SELECT_HYPERSLAB). Note when **block** :math:`= 1`, -# then **stride** :math:`\equiv` **step** in Python slicing. -# -# For example, a ROI sum of an area starting at index of [20,50] and shape [220,120] in image data:: -# -# detector:NXdetector/ -# data[60,256,512] -# region:NXregion/ -# @region_type = "rectangular" -# parent = "data" -# start = [20,50] -# count = [220,120] -# statistics:NXdata/ -# @signal = "sum" -# sum[60] -# -# the ``sum`` dataset contains the summed areas in each frame. -# Another example, a hyperspectral image downsampled 16-fold in energy:: -# -# detector:NXdetector/ -# data[128,128,4096] -# region:NXregion/ -# @region_type = "rectangular" -# parent = "data" -# start = [2] -# count = [20] -# stride = [32] -# block = [16] -# downsampled:NXdata/ -# @signal = "maximum" -# @auxiliary_signals = "copy" -# maximum[128,128,20] -# copy[128,128,320] -# -# the ``copy`` dataset selects 20 16-channel blocks that start 32 channels apart, -# the ``maximum`` dataset will show maximum values in each 16-channel block -# in every spectra. -# -# -# -# This is ``rectangular`` to describe the region as a hyper-rectangle in -# the index space of its parent group's data field. -# -# -# -# -# -# -# -# The name of data field in the parent group or the path of a data field relative -# to the parent group (so it could be a field in a subgroup of the parent group) -# -# -# -# -# The name of an optional mask field in the parent group with rank :math:`\boldsymbol{R}` and -# dimensions :math:`\boldsymbol{d}`. For example, this could be ``pixel_mask`` of an -# :ref:`NXdetector`. -# -# -# -# -# The starting position for region in detector data field array. -# This is recommended as it also defines the region rank. -# If omitted then defined as an array of zeros. -# -# -# -# -# -# -# -# The number of blocks or items in the hyperslab selection. -# If omitted then defined as an array of dimensions that take into account -# the other hyperslab selection fields to span the parent data field's shape. -# -# -# -# -# -# -# -# An optional field to define striding used to downsample data. -# If omitted then defined as an array of ones. -# -# -# -# -# -# -# -# An optional field to define the block size used to copy or downsample data. In the -# :math:`i`-th dimension, if :math:`\mathbf{block}[i] < \mathbf{stride}[i]` -# then the downsampling blocks have gaps between them; when ``block`` matches ``stride`` -# then the blocks are contiguous; otherwise the blocks overlap. -# If omitted then defined as an array of ones. -# -# -# -# -# -# -# -# An optional field to define a divisor for scaling of reduced data. For example, in a -# downsampled sum, it can reduce the maximum values to fit in the domain of the result -# data type. In an image that is downsampled by summing 2x2 blocks, using -# :math:`\mathrm{scale}=4` allows the result to fit in the same integer type dataset as -# the parent dataset. -# If omitted then no scaling occurs. -# -# -# -# -# -# -# -# An optional group containing data copied/downsampled from parent group’s data. Its dataset name -# must reflect how the downsampling is done over each block. So it could be a reduction operation -# such as sum, minimum, maximum, mean, mode, median, etc. If downsampling is merely copying each -# block then use "copy" as the name. Where more than one downsample dataset is written -# (specified with ``@signal``) then add ``@auxiliary_signals`` listing the others. In the copy case, -# the field should have a shape of :math:`(D_0, ..., D_{\mathbf{O}-1}, \mathbf{block}[0] * \mathbf{count}[0], ..., \mathbf{block}[\mathbf{R}-1] * \mathbf{count}[\mathbf{R}-1])`, -# otherwise the expected shape is :math:`(D_0, ..., D_{\mathbf{O}-1}, \mathbf{count}[0], ..., \mathbf{count}[\mathbf{R}-1])`. -# -# The following figure shows how blocks are used in downsampling: -# -# .. figure:: region/NXregion-example.png -# :width: 60% -# -# A selection with :math:`\mathbf{start}=2, \mathbf{count}=4, \mathbf{stride}=3, \mathbf{block}=2` from -# a dataset with shape [13] will result in the ``reduce`` dataset of shape [4] and a ``copy`` dataset of shape [8]. -# -# -# -# -# -# An optional group containing any statistics derived from the region in parent group’s data -# such as sum, minimum, maximum, mean, mode, median, rms, variance, etc. Where more than one -# statistical dataset is written (specified with ``@signal``) then add ``@auxiliary_signals`` -# listing the others. All data fields should have shapes of :math:`\boldsymbol{D}`. -# -# -# diff --git a/contributed_definitions/nyaml/NXsensor_scan.yaml b/contributed_definitions/nyaml/NXsensor_scan.yaml deleted file mode 100644 index 467e1fc199..0000000000 --- a/contributed_definitions/nyaml/NXsensor_scan.yaml +++ /dev/null @@ -1,335 +0,0 @@ -category: application -doc: | - Application definition for a generic scan using sensors. - - In this application definition, times should be specified always together - with an UTC offset. -symbols: - doc: | - Variables used to set a common size for collected sensor data. - N_scanpoints: | - The number of scan points measured in this scan. -type: group -NXsensor_scan(NXobject): - (NXentry): - definition(NX_CHAR): - \@version: - enumeration: [NXsensor_scan] - experiment_identifier(NXidentifier): - exists: recommended - experiment_description(NX_CHAR): - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - (NXprocess): - doc: | - Define the program that was used to generate the results file(s) - with measured data and metadata. - program(NX_CHAR): - doc: | - Commercial or otherwise defined given name of the program - (or a link to the instrument software). - \@version: - doc: | - Either version with build number, commit hash, or description of an - (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner. - \@program_url: - doc: | - Website of the software. - (NXuser): - doc: | - Contact information of at least the user of the instrument or the - investigator who performed this experiment. Adding multiple users if - relevant is recommended. - name(NX_CHAR): - doc: | - Name of the user. - affiliation(NX_CHAR): - exists: recommended - doc: | - Name of the affiliation of the user at the point in time when - the experiment was performed. - address(NX_CHAR): - exists: recommended - doc: | - Full address (street, street number, ZIP, city, country) - of the user's affiliation. - email(NX_CHAR): - exists: recommended - doc: | - Email address of the user. - orcid(NX_CHAR): - exists: recommended - doc: | - Author ID defined by https://orcid.org/. - telephone_number(NX_CHAR): - exists: recommended - doc: | - Official telephone number of the user. - (NXinstrument): - (NXenvironment): - doc: | - Describes an environment setup for the experiment. - - All the setting values of the independently scanned controllers are listed under corresponding - NXsensor groups. Similarly, seperate NXsensor groups are used to store the readings from each - measurement sensor. - - For example, in a temperature-dependent IV measurement, the temperature and voltage must be - present as independently scanned controllers and the current sensor must also be present with - its readings. - (NXsensor): - (NXdata): - exists: recommended - doc: | - Plot of measured signal as a function of the timestamp of when they have been - acquired is also possible. - value(NX_FLOAT): - unit: NX_ANY - doc: | - For each point in the scan space, either the nominal setpoint of an independently scanned controller - or a representative average value of a measurement sensor is registered. - - The length of each sensor's data value array stored in this group should be equal to the number of scan points - probed in this scan. For every scan point [N], the corresponding sensor value can be picked from index [N]. - This allows the scan to be made in any order as the user describes above in the experiment. We get matching - values simply using the index of the scan point. - dimensions: - rank: 1 - dim: [[1, N_scanpoints]] - value_timestamp(NX_DATE_TIME): - exists: recommended - doc: | - Timestamp for when the values provided in the value field were registered. - - Individual readings can be stored with their timestamps under value_log. This is to timestamp - the nominal setpoint or average reading values listed above in the value field. - run_control(NX_CHAR): - exists: recommended - \@description: - doc: | - Free-text describing the data acquisition control: an internal - sweep using the built-in functionality of the controller device, - or a set/wait/read/repeat mechanism. - calibration_time(NX_DATE_TIME): - doc: | - ISO8601 datum when calibration was last performed - before this measurement. UTC offset should be specified. - (NXpid): - independent_controllers: - doc: | - A list of names of NXsensor groups used as independently scanned controllers. - measurement_sensors: - doc: | - A list of names of NXsensor groups used as measurement sensors. - (NXsample): - name(NX_CHAR): - (NXdata): - doc: | - A scan specific representation of the measured signals as a function of the independently controlled environment settings. - Plot of every measured signal as a function of the timestamp of when they have been acquired is also possible. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# ce40fbfc95dd1eeae1902db14f2a835250d8ef0dc04d05be893fec75b9fe5743 -# -# -# -# -# -# -# Variables used to set a common size for collected sensor data. -# -# -# -# The number of scan points measured in this scan. -# -# -# -# -# Application definition for a generic scan using sensors. -# -# In this application definition, times should be specified always together -# with an UTC offset. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Define the program that was used to generate the results file(s) -# with measured data and metadata. -# -# -# -# Commercial or otherwise defined given name of the program -# (or a link to the instrument software). -# -# -# -# Either version with build number, commit hash, or description of an -# (online) repository where the source code of the program and build -# instructions can be found so that the program can be configured in -# such a way that result files can be created ideally in a -# deterministic manner. -# -# -# -# -# Website of the software. -# -# -# -# -# -# -# Contact information of at least the user of the instrument or the -# investigator who performed this experiment. Adding multiple users if -# relevant is recommended. -# -# -# -# Name of the user. -# -# -# -# -# Name of the affiliation of the user at the point in time when -# the experiment was performed. -# -# -# -# -# Full address (street, street number, ZIP, city, country) -# of the user's affiliation. -# -# -# -# -# Email address of the user. -# -# -# -# -# Author ID defined by https://orcid.org/. -# -# -# -# -# Official telephone number of the user. -# -# -# -# -# -# -# Describes an environment setup for the experiment. -# -# All the setting values of the independently scanned controllers are listed under corresponding -# NXsensor groups. Similarly, seperate NXsensor groups are used to store the readings from each -# measurement sensor. -# -# For example, in a temperature-dependent IV measurement, the temperature and voltage must be -# present as independently scanned controllers and the current sensor must also be present with -# its readings. -# -# -# -# -# Plot of measured signal as a function of the timestamp of when they have been -# acquired is also possible. -# -# -# -# -# For each point in the scan space, either the nominal setpoint of an independently scanned controller -# or a representative average value of a measurement sensor is registered. -# -# The length of each sensor's data value array stored in this group should be equal to the number of scan points -# probed in this scan. For every scan point [N], the corresponding sensor value can be picked from index [N]. -# This allows the scan to be made in any order as the user describes above in the experiment. We get matching -# values simply using the index of the scan point. -# -# -# -# -# -# -# -# Timestamp for when the values provided in the value field were registered. -# -# Individual readings can be stored with their timestamps under value_log. This is to timestamp -# the nominal setpoint or average reading values listed above in the value field. -# -# -# -# -# -# Free-text describing the data acquisition control: an internal -# sweep using the built-in functionality of the controller device, -# or a set/wait/read/repeat mechanism. -# -# -# -# -# -# ISO8601 datum when calibration was last performed -# before this measurement. UTC offset should be specified. -# -# -# -# -# -# -# A list of names of NXsensor groups used as independently scanned controllers. -# -# -# -# -# A list of names of NXsensor groups used as measurement sensors. -# -# -# -# -# -# -# -# -# -# A scan specific representation of the measured signals as a function of the independently controlled environment settings. -# Plot of every measured signal as a function of the timestamp of when they have been acquired is also possible. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXsensor_sts.yaml b/contributed_definitions/nyaml/NXsensor_sts.yaml deleted file mode 100644 index 693fb6df12..0000000000 --- a/contributed_definitions/nyaml/NXsensor_sts.yaml +++ /dev/null @@ -1,384 +0,0 @@ -category: base -doc: | - A sensor used to monitor an external condition - - The condition itself is described in :ref:`NXenvironment`. -type: group -NXsensor_sts(NXobject): - model: - doc: | - Sensor identification code/model number - name: - doc: | - Name for the sensor - short_name: - doc: | - Short name of sensor used e.g. on monitor display program - attached_to: - doc: | - where sensor is attached to ("sample" | "can") - geometry(NXgeometry): - deprecated: | - Use the field `depends_on` and :ref:`NXtransformations` to position the beamstop and NXoff_geometry to describe its shape instead - doc: | - Defines the axes for logged vector quantities if they are not the global - instrument axes. - measurement: - doc: | - name for measured signal - enumeration: [temperature, pH, magnetic_field, electric_field, conductivity, resistance, voltage, current, pressure, flow, stress, strain, shear, surface_pressure] - type: - doc: | - The type of hardware used for the measurement. - Examples (suggestions but not restrictions): - - :Temperature: - J | K | T | E | R | S | Pt100 | Pt1000 | Rh/Fe - :pH: - Hg/Hg2Cl2 | Ag/AgCl | ISFET - :Ion selective electrode: - specify species; e.g. Ca2+ - :Magnetic field: - Hall - :Surface pressure: - wilhelmy plate - amplifier(NXamplifier): - second_amplifier(NXcircuit): - doc: | - link to second amplifer circuit with 1MOhm - run_control(NX_BOOLEAN): - doc: | - Is data collection controlled or synchronised to this quantity: - 1=no, 0=to "value", 1=to "value_deriv1", etc. - high_trip_value(NX_FLOAT): - unit: NX_ANY - doc: | - Upper control bound of sensor reading if using run_control - low_trip_value(NX_FLOAT): - unit: NX_ANY - doc: | - Lower control bound of sensor reading if using run_control - value(NX_FLOAT): - unit: NX_ANY - doc: | - nominal setpoint or average value - - need [n] as may be a vector - dimensions: - dim: [[1, n]] - value_deriv1(NX_FLOAT): - unit: NX_ANY - doc: | - Nominal/average first derivative of value - e.g. strain rate - - same dimensions as "value" (may be a vector) - dimensions: - dim: [[1, ]] - dim_parameters: - ref: ['value'] - value_deriv2(NX_FLOAT): - unit: NX_ANY - doc: | - Nominal/average second derivative of value - - same dimensions as "value" (may be a vector) - dimensions: - dim: [[1, ]] - dim_parameters: - ref: ['value'] - value_log(NXlog): - doc: | - Time history of sensor readings - value_deriv1_log(NXlog): - doc: | - Time history of first derivative of sensor readings - value_deriv2_log(NXlog): - doc: | - Time history of second derivative of sensor readings - external_field_brief: - enumeration: [along beam, across beam, transverse, solenoidal, flow shear gradient, flow vorticity] - external_field_full(NXorientation): - doc: | - For complex external fields not satisfied by External_field_brief - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the sensor when necessary. - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a sensor. - (NXtransformations): - doc: | - 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. - temperature(NX_NUMBER): - unit: NX_TEMPERATURE - doc: | - External sensors connected to the device. For example, T1, temperature of STM - head. T2, temperature of bottom of LHe helium cryostat. T3, temperature of LN2 - nitrogen shield. - pressure(NX_NUMBER): - unit: NX_PRESSURE - doc: | - External sensors connected to the device. Pressure of each chamber or ion pump, - such as prepare chamber and analysis chamber - power_spectral_density(NX_NUMBER): - doc: | - The power present in the signal as a function of frequency. Used to characterise - the vibration and noise of scanning probes to detect and reduce the impact on - resolution during STM imaging - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 663a13e67e85927eccd30a06934af287989d603201e9bab8ce68166d4270d051 -# -# -# -# -# -# A sensor used to monitor an external condition -# -# The condition itself is described in :ref:`NXenvironment`. -# -# -# -# Sensor identification code/model number -# -# -# -# -# Name for the sensor -# -# -# -# -# Short name of sensor used e.g. on monitor display program -# -# -# -# -# where sensor is attached to ("sample" | "can") -# -# -# -# -# Defines the axes for logged vector quantities if they are not the global -# instrument axes. -# -# -# -# -# name for measured signal -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The type of hardware used for the measurement. -# Examples (suggestions but not restrictions): -# -# :Temperature: -# J | K | T | E | R | S | Pt100 | Pt1000 | Rh/Fe -# :pH: -# Hg/Hg2Cl2 | Ag/AgCl | ISFET -# :Ion selective electrode: -# specify species; e.g. Ca2+ -# :Magnetic field: -# Hall -# :Surface pressure: -# wilhelmy plate -# -# -# -# -# -# link to second amplifer circuit with 1MOhm -# -# -# -# -# Is data collection controlled or synchronised to this quantity: -# 1=no, 0=to "value", 1=to "value_deriv1", etc. -# -# -# -# -# Upper control bound of sensor reading if using run_control -# -# -# -# -# Lower control bound of sensor reading if using run_control -# -# -# -# -# nominal setpoint or average value -# - need [n] as may be a vector -# -# -# -# -# -# -# -# Nominal/average first derivative of value -# e.g. strain rate -# - same dimensions as "value" (may be a vector) -# -# -# -# -# -# -# -# Nominal/average second derivative of value -# - same dimensions as "value" (may be a vector) -# -# -# -# -# -# -# -# Time history of sensor readings -# -# -# -# -# Time history of first derivative of sensor readings -# -# -# -# -# Time history of second derivative of sensor readings -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# For complex external fields not satisfied by External_field_brief -# -# -# -# -# This group describes the shape of the sensor when necessary. -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a sensor. -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# -# External sensors connected to the device. For example, T1, temperature of STM -# head. T2, temperature of bottom of LHe helium cryostat. T3, temperature of LN2 -# nitrogen shield. -# -# -# -# -# External sensors connected to the device. Pressure of each chamber or ion pump, -# such as prepare chamber and analysis chamber -# -# -# -# -# The power present in the signal as a function of frequency. Used to characterise -# the vibration and noise of scanning probes to detect and reduce the impact on -# resolution during STM imaging -# -# -# diff --git a/contributed_definitions/nyaml/NXseparator.yaml b/contributed_definitions/nyaml/NXseparator.yaml deleted file mode 100644 index b8ee2958a9..0000000000 --- a/contributed_definitions/nyaml/NXseparator.yaml +++ /dev/null @@ -1,108 +0,0 @@ -category: base -doc: | - definition for an electrostatic separator. -type: group -NXseparator(NXobject): - description(NX_CHAR): - doc: | - extended description of the separator. - beamline_distance(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - define position of beamline element relative to production target - set_Bfield_current(NX_FLOAT): - unit: NX_CURRENT - exists: ['min', '0', 'max', '1'] - doc: | - current set on magnet supply. - read_Bfield_current(NXlog): - exists: ['min', '0', 'max', '1'] - doc: | - current read from magnet supply. - value: - unit: NX_CURRENT - read_Bfield_voltage(NXlog): - exists: ['min', '0', 'max', '1'] - doc: | - voltage read from magnet supply. - value: - unit: NX_VOLTAGE - set_Efield_voltage(NX_FLOAT): - unit: NX_VOLTAGE - exists: ['min', '0', 'max', '1'] - doc: | - current set on HT supply. - read_Efield_current(NXlog): - exists: ['min', '0', 'max', '1'] - doc: | - current read from HT supply. - value: - unit: NX_CURRENT - read_Efield_voltage(NXlog): - exists: ['min', '0', 'max', '1'] - doc: | - voltage read from HT supply. - value: - unit: NX_VOLTAGE - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 133c0cb1ded771a7a9c6d95c83e4446f2c7f12074dee04670ba08c15b8f380e4 -# -# -# -# -# definition for an electrostatic separator. -# -# extended description of the separator. -# -# -# define position of beamline element relative to production target -# -# -# current set on magnet supply. -# -# -# current read from magnet supply. -# -# -# -# voltage read from magnet supply. -# -# -# -# current set on HT supply. -# -# -# current read from HT supply. -# -# -# -# voltage read from HT supply. -# -# -# diff --git a/contributed_definitions/nyaml/NXsimilarity_grouping.yaml b/contributed_definitions/nyaml/NXsimilarity_grouping.yaml deleted file mode 100644 index f10891ce1e..0000000000 --- a/contributed_definitions/nyaml/NXsimilarity_grouping.yaml +++ /dev/null @@ -1,268 +0,0 @@ -category: base -doc: | - Base class to store results obtained from applying a similarity grouping (clustering) algorithm. - - Similarity grouping algorithms are segmentation or machine learning algorithms for - partitioning the members of a set of objects (e.g. geometric primitives) into - (sub-)groups aka features of different kind/type. A plethora of algorithms exists. - - This base class considers metadata and results of having a similarity grouping - algorithm applied to a set in which objects are either categorized as noise - or belonging to a cluster, i.e. members of a cluster. - The algorithm assigns each similarity group (feature/cluster) at least one - identifier (numerical or categorical labels) to distinguish different cluster. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - c: | - Cardinality of the set. - n_lbl_num: | - Number of numerical labels per object. - n_lbl_cat: | - Number of categorical labels per object. - n_features: | - Total number of similarity groups aka features/clusters. -type: group -NXsimilarity_grouping(NXobject): - cardinality(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of members in the set which gets partitioned into features. - number_of_numeric_labels(NX_UINT): - unit: NX_UNITLESS - doc: | - How many numerical labels does each feature have. - number_of_categorical_labels(NX_UINT): - unit: NX_UNITLESS - doc: | - How many categorical labels does each feature have. - - # config/input - # features: - # doc: | - # Reference to a set of features investigated in a cluster analysis. - # Features need to have disjoint numeric identifier. - # results for the object set - identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Which numerical identifier is the first to be used to label a feature. - - The value should be chosen in such a way that special values can be resolved: - * identifier_offset - 1 indicates that an object belongs to no cluster. - * identifier_offset - 2 indicates that an object belongs to the noise category. - Setting for instance identifier_offset to 1 recovers the commonly used - case that objects of the noise category get values to -1 and unassigned - points to 0. Numerical identifier have to be strictly increasing. - numerical_label(NX_INT): - unit: NX_UNITLESS - doc: | - Matrix of numerical label for each member in the set. - For classical clustering algorithms this can for instance - encode the cluster_identifier. - dimensions: - rank: 2 - dim: [[1, c], [2, n_lbl_num]] - categorical_label(NX_CHAR): - doc: | - Matrix of categorical attribute data for each member in the set. - dimensions: - rank: 2 - dim: [[1, c], [2, n_lbl_cat]] - statistics(NXprocess): - doc: | - In addition to the detailed storage which objects were grouped to which - feature/group summary statistics are stored under this group. - - # at the level of the object set - # at the level of the feature set - unassigned(NX_UINT): - unit: NX_UNITLESS - doc: | - Total number of features categorized as unassigned. - noise(NX_UINT): - unit: NX_UNITLESS - doc: | - Total number of features categorized as noise. - total(NX_UINT): - unit: NX_UNITLESS - doc: | - Total number of features. - - # Total number of features (excluding noise and unassigned) can be trivially computed - # when knowing total, noise, and unassigned. - identifier(NX_UINT): - unit: NX_UNITLESS - doc: | - Array of numerical identifier of each feature. - dimensions: - rank: 1 - dim: [[1, n_features]] - member_count(NX_UINT): - unit: NX_UNITLESS - doc: | - Array of number of objects for each feature. - dimensions: - rank: 2 - dim: [[1, n_features], [2, n_lbl_num]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8d93c5681b89657f44646f6fc81976ad1f618e6514aae36fa7c2754cbd0868de -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Cardinality of the set. -# -# -# -# -# Number of numerical labels per object. -# -# -# -# -# Number of categorical labels per object. -# -# -# -# -# Total number of similarity groups aka features/clusters. -# -# -# -# -# Base class to store results obtained from applying a similarity grouping (clustering) algorithm. -# -# Similarity grouping algorithms are segmentation or machine learning algorithms for -# partitioning the members of a set of objects (e.g. geometric primitives) into -# (sub-)groups aka features of different kind/type. A plethora of algorithms exists. -# -# This base class considers metadata and results of having a similarity grouping -# algorithm applied to a set in which objects are either categorized as noise -# or belonging to a cluster, i.e. members of a cluster. -# The algorithm assigns each similarity group (feature/cluster) at least one -# identifier (numerical or categorical labels) to distinguish different cluster. -# -# -# -# Number of members in the set which gets partitioned into features. -# -# -# -# -# How many numerical labels does each feature have. -# -# -# -# -# How many categorical labels does each feature have. -# -# -# -# -# -# Which numerical identifier is the first to be used to label a feature. -# -# The value should be chosen in such a way that special values can be resolved: -# * identifier_offset - 1 indicates that an object belongs to no cluster. -# * identifier_offset - 2 indicates that an object belongs to the noise category. -# Setting for instance identifier_offset to 1 recovers the commonly used -# case that objects of the noise category get values to -1 and unassigned -# points to 0. Numerical identifier have to be strictly increasing. -# -# -# -# -# Matrix of numerical label for each member in the set. -# For classical clustering algorithms this can for instance -# encode the cluster_identifier. -# -# -# -# -# -# -# -# -# Matrix of categorical attribute data for each member in the set. -# -# -# -# -# -# -# -# -# In addition to the detailed storage which objects were grouped to which -# feature/group summary statistics are stored under this group. -# -# -# -# -# Total number of features categorized as unassigned. -# -# -# -# -# Total number of features categorized as noise. -# -# -# -# -# Total number of features. -# -# -# -# -# -# Array of numerical identifier of each feature. -# -# -# -# -# -# -# -# Array of number of objects for each feature. -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXsnsevent.yaml b/contributed_definitions/nyaml/NXsnsevent.yaml deleted file mode 100644 index ec62042b88..0000000000 --- a/contributed_definitions/nyaml/NXsnsevent.yaml +++ /dev/null @@ -1,642 +0,0 @@ -category: application -doc: | - This is a definition for event data from Spallation Neutron Source (SNS) at ORNL. - -# NXsnsevent: candidate NeXus definition for event data from Spallation Neutron Source (SNS) at ORNL. -type: group -NXsnsevent(NXobject): - (NXentry): - exists: ['min', '1'] - (NXcollection)DASlogs: - doc: | - Details of all logs, both from cvinfo file and from HistoTool (frequency and proton_charge). - (NXlog): - exists: ['min', '1'] - average_value(NX_FLOAT): - average_value_error(NX_FLOAT): - exists: optional - deprecated: | - see https://github.com/nexusformat/definitions/issues/821 - average_value_errors(NX_FLOAT): - description: - duration(NX_FLOAT): - maximum_value(NX_FLOAT): - minimum_value(NX_FLOAT): - time(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, nvalue]] - value(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, nvalue]] - (NXpositioner): - exists: ['min', '0'] - doc: | - Motor logs from cvinfo file. - average_value(NX_FLOAT): - average_value_error(NX_FLOAT): - exists: optional - deprecated: | - see https://github.com/nexusformat/definitions/issues/821 - average_value_errors(NX_FLOAT): - description: - duration(NX_FLOAT): - maximum_value(NX_FLOAT): - minimum_value(NX_FLOAT): - time(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, numvalue]] - value(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, numvalue]] - (NXnote)SNSHistoTool: - SNSbanking_file_name: - SNSmapping_file_name: - author: - command1: - doc: | - Command string for event2nxl. - date: - description: - version: - (NXdata): - exists: ['min', '1'] - - # for all NXdata/banks - data_x_y(link): - target: /NXentry/NXinstrument/NXdetector/data_x_y - x_pixel_offset(link): - target: /NXentry/NXinstrument/NXdetector/x_pixel_offset - y_pixel_offset(link): - target: /NXentry/NXinstrument/NXdetector/y_pixel_offset - (NXevent_data): - exists: ['min', '1'] - - # for all NXdata/banks - event_index(link): - target: /NXentry/NXinstrument/NXdetector/event_index - event_pixel_id(link): - target: /NXentry/NXinstrument/NXdetector/event_pixel_id - event_time_of_flight(link): - target: /NXentry/NXinstrument/NXdetector/event_time_of_flight - pulse_time(link): - target: /NXentry/NXinstrument/NXdetector/pulse_time - collection_identifier: - collection_title: - definition: - doc: | - Official NXDL schema after this file goes to applications. - enumeration: [NXsnsevent] - duration(NX_FLOAT): - unit: NX_TIME - end_time(NX_DATE_TIME): - entry_identifier: - experiment_identifier: - (NXinstrument)instrument: - (NXsource)SNS: - frequency(NX_FLOAT): - unit: NX_FREQUENCY - name: - probe: - type: - SNSdetector_calibration_id: - doc: | - Detector calibration id from DAS. - SNSgeometry_file_name: - - # SNSnxtranslate - SNStranslation_service: - (NXdetector): - exists: ['min', '1'] - - # for all NXdetector/banks - azimuthal_angle(NX_FLOAT): - unit: NX_ANGLE - dimensions: - rank: 2 - dim: [[1, numx], [2, numy]] - data_x_y(NX_UINT): - doc: | - expect ``signal=2 axes="x_pixel_offset,y_pixel_offset``" - - # axes are set in data files - dimensions: - rank: 2 - dim: [[1, numx], [2, numy]] - distance(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, numx], [2, numy]] - event_index(NX_UINT): - dimensions: - rank: 1 - dim: [[1, numpulses]] - event_pixel_id(NX_UINT): - dimensions: - rank: 1 - dim: [[1, numevents]] - event_time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - dimensions: - rank: 1 - dim: [[1, numevents]] - (NXgeometry)origin: - (NXorientation)orientation: - value(NX_FLOAT): - doc: | - Six out of nine rotation parameters. - dimensions: - rank: 1 - dim: [[1, 6]] - (NXshape)shape: - description: - shape: - size(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - (NXtranslation)translation: - distance(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - pixel_id(NX_UINT): - dimensions: - rank: 2 - dim: [[1, numx], [2, numy]] - polar_angle(NX_FLOAT): - unit: NX_ANGLE - dimensions: - rank: 2 - dim: [[1, numx], [2, numy]] - pulse_time(NX_FLOAT): - unit: NX_TIME - dimensions: - rank: 1 - dim: [[1, numpulses]] - total_counts(NX_UINT): - x_pixel_offset(NX_FLOAT): - axis: 1 - primary: 1 - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, numx]] - y_pixel_offset(NX_FLOAT): - axis: 2 - primary: 1 - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, numy]] - beamline: - (NXdisk_chopper): - exists: ['min', '0'] - distance(NX_FLOAT): - unit: NX_LENGTH - (NXmoderator)moderator: - coupling_material: - distance(NX_FLOAT): - unit: NX_LENGTH - temperature(NX_FLOAT): - unit: NX_TEMPERATURE - type: - name: - (NXaperture): - exists: ['min', '0'] - (NXgeometry)origin: - (NXorientation)orientation: - value(NX_FLOAT): - doc: | - Six out of nine rotation parameters. - dimensions: - rank: 1 - dim: [[1, 6]] - (NXshape)shape: - description: - shape: - size(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - (NXtranslation)translation: - distance(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - x_pixel_offset(NX_FLOAT): - unit: NX_LENGTH - (NXattenuator): - exists: ['min', '0'] - distance(NX_FLOAT): - unit: NX_LENGTH - - # motor links from DASlogs when exist - (NXpolarizer): - exists: ['min', '0'] - - # motor links from DASlogs when exist - (NXcrystal): - exists: ['min', '0'] - (NXgeometry)origin: - description: - (NXorientation)orientation: - value(NX_FLOAT): - doc: | - Six out of nine rotation parameters. - dimensions: - rank: 1 - dim: [[1, 6]] - (NXshape)shape: - description: - shape: - size(NX_FLOAT): - unit: NX_LENGTH - (NXtranslation)translation: - distance(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - type: - wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - (NXmonitor): - exists: ['min', '0'] - data(NX_UINT): - doc: | - expect ``signal=1 axes="time_of_flight"`` - dimensions: - rank: 1 - dim: [[1, numtimechannels]] - distance(NX_FLOAT): - unit: NX_LENGTH - mode: - time_of_flight(NX_FLOAT): - unit: NX_TIME - dimensions: - rank: 1 - dim: [[1, numtimechannels + 1]] - notes: - proton_charge(NX_FLOAT): - unit: NX_CHARGE - raw_frames(NX_INT): - run_number: - (NXsample)sample: - changer_position: - holder: - identifier: - name: - doc: | - Descriptive name of sample - nature: - start_time(NX_DATE_TIME): - title: - total_counts(NX_UINT): - unit: NX_UNITLESS - total_uncounted_counts(NX_UINT): - unit: NX_UNITLESS - (NXuser): - exists: ['min', '1'] - facility_user_id: - name: - role: - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4d8076d815ebdb96d8ef32d9795bd71064fce6aa9a28104e31726092872e6380 -# -# -# -# -# This is a definition for event data from Spallation Neutron Source (SNS) at ORNL. -# -# -# -# Details of all logs, both from cvinfo file and from HistoTool (frequency and proton_charge). -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Motor logs from cvinfo file. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Command string for event2nxl. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Official NXDL schema after this file goes to applications. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Detector calibration id from DAS. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# expect ``signal=2 axes="x_pixel_offset,y_pixel_offset``" -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Six out of nine rotation parameters. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Six out of nine rotation parameters. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Six out of nine rotation parameters. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# expect ``signal=1 axes="time_of_flight"`` -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXsnshisto.yaml b/contributed_definitions/nyaml/NXsnshisto.yaml deleted file mode 100644 index e7d3a5e444..0000000000 --- a/contributed_definitions/nyaml/NXsnshisto.yaml +++ /dev/null @@ -1,672 +0,0 @@ -category: application -doc: | - This is a definition for histogram data from Spallation Neutron Source (SNS) at ORNL. - -# NXsnshisto: candidate NeXus definition for histogram data from Spallation Neutron Source (SNS) at ORNL. -type: group -NXsnshisto(NXobject): - (NXentry): - exists: ['min', '1'] - (NXcollection)DASlogs: - doc: | - Details of all logs, both from cvinfo file and from HistoTool (frequency and proton_charge). - (NXlog): - exists: ['min', '1'] - average_value(NX_FLOAT): - average_value_error(NX_FLOAT): - exists: optional - deprecated: | - see https://github.com/nexusformat/definitions/issues/821 - average_value_errors(NX_FLOAT): - description: - duration(NX_FLOAT): - maximum_value(NX_FLOAT): - minimum_value(NX_FLOAT): - time(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, nvalue]] - value(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, nvalue]] - (NXpositioner): - exists: ['min', '0'] - doc: | - Motor logs from cvinfo file. - average_value(NX_FLOAT): - average_value_error(NX_FLOAT): - exists: optional - deprecated: | - see https://github.com/nexusformat/definitions/issues/821 - average_value_errors(NX_FLOAT): - description: - duration(NX_FLOAT): - maximum_value(NX_FLOAT): - minimum_value(NX_FLOAT): - time(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, numvalue]] - value(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, numvalue]] - (NXnote)SNSHistoTool: - SNSbanking_file_name: - SNSmapping_file_name: - author: - command1: - doc: | - Command string for event2histo_nxl. - date: - description: - version: - (NXdata): - exists: ['min', '1'] - - # for all NXdata/banks - data(link): - target: /NXentry/NXinstrument/NXdetector/data - data_x_time_of_flight(link): - target: /NXentry/NXinstrument/NXdetector/data_x_time_of_flight - data_x_y(link): - target: /NXentry/NXinstrument/NXdetector/data_x_y - data_y_time_of_flight(link): - target: /NXentry/NXinstrument/NXdetector/data_y_time_of_flight - pixel_id(link): - target: /NXentry/NXinstrument/NXdetector/pixel_id - time_of_flight(link): - target: /NXentry/NXinstrument/NXdetector/time_of_flight - total_counts(link): - target: /NXentry/NXinstrument/NXdetector/total_counts - x_pixel_offset(link): - target: /NXentry/NXinstrument/NXdetector/x_pixel_offset - y_pixel_offset(link): - target: /NXentry/NXinstrument/NXdetector/y_pixel_offset - collection_identifier: - collection_title: - definition: - doc: | - Official NXDL schema after this file goes to applications. - enumeration: [NXsnshisto] - duration(NX_FLOAT): - unit: NX_TIME - end_time(NX_DATE_TIME): - entry_identifier: - experiment_identifier: - (NXinstrument)instrument: - (NXsource)SNS: - frequency(NX_FLOAT): - unit: NX_FREQUENCY - name: - probe: - type: - SNSdetector_calibration_id: - doc: | - Detector calibration id from DAS. - SNSgeometry_file_name: - - # SNSnxtranslate - SNStranslation_service: - (NXdetector): - exists: ['min', '1'] - - # for all NXdetector/banks - azimuthal_angle(NX_FLOAT): - unit: NX_ANGLE - dimensions: - rank: 2 - dim: [[1, numx], [2, numy]] - data(NX_UINT): - signal: 1 - axes: x_pixel_offset,y_pixel_offset,time_of_flight - dimensions: - rank: 3 - dim: [[1, numx], [2, numy], [3, numtof]] - data_x_time_of_flight(NX_UINT): - signal: 3 - axes: x_pixel_offset,time_of_flight - dimensions: - rank: 2 - dim: [[1, numx], [2, numtof]] - data_x_y(NX_UINT): - signal: 2 - axes: x_pixel_offset,y_pixel_offset - dimensions: - rank: 2 - dim: [[1, numx], [2, numy]] - data_y_time_of_flight(NX_UINT): - signal: 4 - axes: y_pixel_offset,time_of_flight - dimensions: - rank: 2 - dim: [[1, numy], [2, numtof]] - distance(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, numx], [2, numy]] - (NXgeometry)origin: - (NXorientation)orientation: - value(NX_FLOAT): - doc: | - Six out of nine rotation parameters. - dimensions: - rank: 1 - dim: [[1, 6]] - (NXshape)shape: - description: - shape: - size(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - (NXtranslation)translation: - distance(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - pixel_id(NX_UINT): - dimensions: - rank: 2 - dim: [[1, numx], [2, numy]] - polar_angle(NX_FLOAT): - unit: NX_ANGLE - dimensions: - rank: 2 - dim: [[1, numx], [2, numy]] - time_of_flight(NX_FLOAT): - axis: 3 - primary: 1 - unit: NX_TIME_OF_FLIGHT - dimensions: - rank: 1 - dim: [[1, numtof + 1]] - total_counts(NX_UINT): - x_pixel_offset(NX_FLOAT): - axis: 1 - primary: 1 - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, numx]] - y_pixel_offset(NX_FLOAT): - axis: 2 - primary: 1 - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, numy]] - beamline: - (NXdisk_chopper): - exists: ['min', '0'] - doc: | - Original specification called for NXchopper, - which is not a valid NeXus base class. - Select either NXdisk_chopper or NXfermi_chopper, as appropriate. - distance(NX_FLOAT): - unit: NX_LENGTH - (NXfermi_chopper): - exists: ['min', '0'] - doc: | - Original specification called for NXchopper, - which is not a valid NeXus base class. - Select either NXdisk_chopper or NXfermi_chopper, as appropriate. - distance(NX_FLOAT): - unit: NX_LENGTH - (NXmoderator)moderator: - coupling_material: - distance(NX_FLOAT): - unit: NX_LENGTH - temperature(NX_FLOAT): - unit: NX_TEMPERATURE - type: - name: - (NXaperture): - exists: ['min', '0'] - (NXgeometry)origin: - (NXorientation)orientation: - value(NX_FLOAT): - doc: | - Six out of nine rotation parameters. - dimensions: - rank: 1 - dim: [[1, 6]] - (NXshape)shape: - description: - shape: - size(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - (NXtranslation)translation: - distance(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - x_pixel_offset(NX_FLOAT): - unit: NX_LENGTH - (NXattenuator): - exists: ['min', '0'] - distance(NX_FLOAT): - unit: NX_LENGTH - - # motor links from DASlogs when exist - (NXpolarizer): - exists: ['min', '0'] - - # motor links from DASlogs when exist - (NXcrystal): - exists: ['min', '0'] - (NXgeometry)origin: - description: - (NXorientation)orientation: - value(NX_FLOAT): - doc: | - Six out of nine rotation parameters. - dimensions: - rank: 1 - dim: [[1, 6]] - (NXshape)shape: - description: - shape: - size(NX_FLOAT): - unit: NX_LENGTH - (NXtranslation)translation: - distance(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, 3]] - type: - wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - (NXmonitor): - exists: ['min', '0'] - data(NX_UINT): - signal: 1 - axes: time_of_flight - dimensions: - rank: 1 - dim: [[1, numtimechannels]] - distance(NX_FLOAT): - unit: NX_LENGTH - mode: - time_of_flight(NX_FLOAT): - unit: NX_TIME - dimensions: - rank: 1 - dim: [[1, numtimechannels + 1]] - notes: - proton_charge(NX_FLOAT): - unit: NX_CHARGE - raw_frames(NX_INT): - run_number: - (NXsample)sample: - changer_position: - holder: - identifier: - name: - doc: | - Descriptive name of sample - nature: - start_time(NX_DATE_TIME): - title: - total_counts(NX_UINT): - unit: NX_UNITLESS - total_uncounted_counts(NX_UINT): - unit: NX_UNITLESS - (NXuser): - exists: ['min', '1'] - facility_user_id: - name: - role: - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 3a5828e7bd37c8377b1f53dd9b5abfd151f9bc2b97781b58d9747473b7294aa3 -# -# -# -# -# This is a definition for histogram data from Spallation Neutron Source (SNS) at ORNL. -# -# -# -# Details of all logs, both from cvinfo file and from HistoTool (frequency and proton_charge). -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Motor logs from cvinfo file. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Command string for event2histo_nxl. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Official NXDL schema after this file goes to applications. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Detector calibration id from DAS. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Six out of nine rotation parameters. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Original specification called for NXchopper, -# which is not a valid NeXus base class. -# Select either NXdisk_chopper or NXfermi_chopper, as appropriate. -# -# -# -# -# -# Original specification called for NXchopper, -# which is not a valid NeXus base class. -# Select either NXdisk_chopper or NXfermi_chopper, as appropriate. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Six out of nine rotation parameters. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Six out of nine rotation parameters. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXsolenoid_magnet.yaml b/contributed_definitions/nyaml/NXsolenoid_magnet.yaml deleted file mode 100644 index 2ce7d04842..0000000000 --- a/contributed_definitions/nyaml/NXsolenoid_magnet.yaml +++ /dev/null @@ -1,84 +0,0 @@ -category: base -doc: | - definition for a solenoid magnet. -type: group -NXsolenoid_magnet(NXobject): - description(NX_CHAR): - doc: | - extended description of the magnet. - beamline_distance(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - define position of beamline element relative to production target - set_current(NX_FLOAT): - unit: NX_CURRENT - exists: ['min', '0', 'max', '1'] - doc: | - current set on supply. - read_current(NXlog): - exists: ['min', '0', 'max', '1'] - doc: | - current read from supply. - value: - unit: NX_CURRENT - read_voltage(NXlog): - exists: ['min', '0', 'max', '1'] - doc: | - voltage read from supply. - value: - unit: NX_VOLTAGE - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 3a4f16a44227ce96eda9395d3e6c88039c3d9ef35aaa15012ef1ef119b9aa539 -# -# -# -# -# definition for a solenoid magnet. -# -# extended description of the magnet. -# -# -# define position of beamline element relative to production target -# -# -# current set on supply. -# -# -# current read from supply. -# -# -# -# voltage read from supply. -# -# -# diff --git a/contributed_definitions/nyaml/NXsolid_geometry.yaml b/contributed_definitions/nyaml/NXsolid_geometry.yaml deleted file mode 100644 index 2d68187278..0000000000 --- a/contributed_definitions/nyaml/NXsolid_geometry.yaml +++ /dev/null @@ -1,76 +0,0 @@ -category: base -doc: | - the head node for constructively defined geometry -type: group -NXsolid_geometry(NXobject): - (NXquadric): - exists: ['min', '0'] - doc: | - Instances of :ref:`NXquadric` making up elements of the geometry. - (NXoff_geometry): - exists: ['min', '0'] - doc: | - Instances of :ref:`NXoff_geometry` making up elements of the geometry. - (NXcsg): - exists: ['min', '0'] - doc: | - The geometries defined, made up of instances of :ref:`NXquadric` and :ref:`NXoff_geometry`. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 786decee7aec6e7c637847cb2156460000e090fe692f092fa9ca4c368bcd44dd -# -# -# -# -# -# the head node for constructively defined geometry -# -# -# -# Instances of :ref:`NXquadric` making up elements of the geometry. -# -# -# -# -# Instances of :ref:`NXoff_geometry` making up elements of the geometry. -# -# -# -# -# The geometries defined, made up of instances of :ref:`NXquadric` and :ref:`NXoff_geometry`. -# -# -# diff --git a/contributed_definitions/nyaml/NXspatial_filter.yaml b/contributed_definitions/nyaml/NXspatial_filter.yaml deleted file mode 100644 index 316725d8c6..0000000000 --- a/contributed_definitions/nyaml/NXspatial_filter.yaml +++ /dev/null @@ -1,139 +0,0 @@ -category: base -doc: | - Base class for a spatial filter for objects within a region-of-interest (ROI). - - Objects can be points or objects composed from other geometric primitives. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_hexahedra: | - Number of hexahedra. - n_cylinders: | - Number of cylinders. - n_ellipsoids: | - Number of ellipsoids. - n_polyhedra: | - Number of polyhedra. - -# n_vertices: Number of vertices for polyhedra. -# n_facets: Number of facets for polyhedra. -type: group -NXspatial_filter(NXobject): - windowing_method(NX_CHAR): - doc: | - Qualitative statement which describes the logical operations - that define which objects will be included and which excluded: - - * entire_dataset, no filter is applied, all objects are included. - * union_of_primitives, a filter with (possibly non-axis-aligned) geometric - primitives. Objects in or on the surface of the primitives are included. - All other objects are excluded. - * bitmask, a boolean array whose bits encode with 1 which objects - are included. Bits set to zero encode which objects are excluded. - Users of python can use the bitfield operations - of the numpy package to work with bitfields. - - # In the case that windowing_method is union_of_primitives, - # it is possible to specify none or all types of primitives - # (ellipsoids, cylinder, hexahedra). If no primitives are specified - # the filter falls back to entire_dataset. - # In the case that windowing_method is bitmask, the bitmask has to be defined; - # otherwise the filter falls back to entire dataset. - enumeration: [entire_dataset, union_of_primitives, bitmask] - (NXcg_hexahedron_set): - (NXcg_cylinder_set): - (NXcg_ellipsoid_set): - (NXcg_polyhedron_set): - (NXcs_filter_boolean_mask): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2e512610e879acf651c180cd91f3b35ddfcc5a640b5d89920ea0b2429c15a1b5 -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of hexahedra. -# -# -# -# -# Number of cylinders. -# -# -# -# -# Number of ellipsoids. -# -# -# -# -# Number of polyhedra. -# -# -# -# -# Base class for a spatial filter for objects within a region-of-interest (ROI). -# -# Objects can be points or objects composed from other geometric primitives. -# -# -# -# Qualitative statement which describes the logical operations -# that define which objects will be included and which excluded: -# -# * entire_dataset, no filter is applied, all objects are included. -# * union_of_primitives, a filter with (possibly non-axis-aligned) geometric -# primitives. Objects in or on the surface of the primitives are included. -# All other objects are excluded. -# * bitmask, a boolean array whose bits encode with 1 which objects -# are included. Bits set to zero encode which objects are excluded. -# Users of python can use the bitfield operations -# of the numpy package to work with bitfields. -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXspin_rotator.yaml b/contributed_definitions/nyaml/NXspin_rotator.yaml deleted file mode 100644 index e453667d8b..0000000000 --- a/contributed_definitions/nyaml/NXspin_rotator.yaml +++ /dev/null @@ -1,108 +0,0 @@ -category: base -doc: | - definition for a spin rotator. -type: group -NXspin_rotator(NXobject): - description(NX_CHAR): - doc: | - extended description of the spin rotator. - beamline_distance(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - define position of beamline element relative to production target - set_Bfield_current(NX_FLOAT): - unit: NX_CURRENT - exists: ['min', '0', 'max', '1'] - doc: | - current set on magnet supply. - read_Bfield_current(NXlog): - exists: ['min', '0', 'max', '1'] - doc: | - current read from magnet supply. - value: - unit: NX_CURRENT - read_Bfield_voltage(NXlog): - exists: ['min', '0', 'max', '1'] - doc: | - voltage read from magnet supply. - value: - unit: NX_VOLTAGE - set_Efield_voltage(NX_FLOAT): - unit: NX_VOLTAGE - exists: ['min', '0', 'max', '1'] - doc: | - current set on HT supply. - read_Efield_current(NXlog): - exists: ['min', '0', 'max', '1'] - doc: | - current read from HT supply. - value: - unit: NX_CURRENT - read_Efield_voltage(NXlog): - exists: ['min', '0', 'max', '1'] - doc: | - voltage read from HT supply. - value: - unit: NX_VOLTAGE - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# c9579a21de3419c77dcb3d634bad2e9191219592ca843b1d0006196742cabbf6 -# -# -# -# -# definition for a spin rotator. -# -# extended description of the spin rotator. -# -# -# define position of beamline element relative to production target -# -# -# current set on magnet supply. -# -# -# current read from magnet supply. -# -# -# -# voltage read from magnet supply. -# -# -# -# current set on HT supply. -# -# -# current read from HT supply. -# -# -# -# voltage read from HT supply. -# -# -# diff --git a/contributed_definitions/nyaml/NXsts.yaml b/contributed_definitions/nyaml/NXsts.yaml deleted file mode 100644 index d73a7b416b..0000000000 --- a/contributed_definitions/nyaml/NXsts.yaml +++ /dev/null @@ -1,1909 +0,0 @@ -category: application -doc: | - Application definition for temperature-dependent IV curve measurements - #2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the - STM image mode in the future with a focus on bias spectroscopy in Scanning Tunneling Microscopy. - - In this application definition, times should be specified always together with a UTC offset. - - This is the application definition describing temperature (T) dependent current voltage (IV) curve - measurements. For this, a temperature is set. After reaching the temperature, a voltage sweep - is performed. For each voltage, a current is measured. - Then, the next desired temperature is set and an IV measurement is performed. - The data can be visualized in a tensor with: - I (NXsensor_C, NXsoftware_Read_offset, NXcircuit) - parameters: - V has (NXsource+offset, NXsoftware_Scan_offset, NXsensor_V, NXcircuit) - T has (NXsource, NXsoftware_Scan_offset, NXsensor_T) - x has (NXsoftware_Scan_offset) - y has (NXsoftware_Scan_offset) - z has (NXsoftware_Scan_offset) - -# 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the - -# 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the - -# 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the - -# 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the -type: group -NXsts(NXsensor_scan): - (NXentry): - definition: - enumeration: [NXsts] - experiment_type: - doc: | - Name of the experiment where the application is applicable. - enumeration: [sts, stm] - type: - doc: | - The equipments and techniques as well as the parameter settings and reference signals - are used during the experiments used in Scanning Tunneling Microscopy (STM). - - # NOTE_: What does the enum refer, scan could be forward or backward. (not in data file) - # What is about [constant current mode, constant height mode] - enumeration: [background, reference, sample] - entry_identifier(NXidentifier): - exists: optional - doc: | - The name of the output file, with the number of scans at the end. (e.g. - 221122_Au_5K00014) - collection_identifier(NXidentifier): - doc: | - The name of the series output file, which represents only the public part of the - output file. (e.g. 221122_Au_5K) - experiment_identifier(NXidentifier): - exists: optional - doc: | - Path to storage of output files. - (e.g. Path C:\Users\SPM-PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis-Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711) - experiment_description: - exists: optional - doc: | - Descriptive comments for this experiment, added by the experimenter, coming from the - output file. (e.g. Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, locked Au(111), - 50pA, 100 mV set point, 1mV DCA, 973Hz,138 1st H, -84 2nd H) - (NXinstrument): - hardware(NXfabrication): - exists: optional - doc: | - Hardware type used in SPM experiment, includes hardware manufacturers and type. - (e.g. Nanonis BP5e) - - # hardware: Current amplifier> hardware: CreaTec GmbH - # any or specifique 'harware' and 'software'? - software(NXfabrication): - exists: optional - doc: | - Type of software used in SPM experiments, such as software version serial number, UI and - RT probe release method. (e.g. SW Version Generic 5e -- RT Release 10771) - - # amplification: Current amplifier> factor (V/V): 1E-10 - # crosstalk_compensation: Current amplifier> Capacitive cross-talk compensation: Yes/No - current_amplifier(NXamplifier): - exists: optional - doc: | - The Amplifier description that improves or helps to determine tunnel current (current - between tip and bias). - lock_in(NXlockin): - exists: optional - status: - exists: optional - - # status: Lock-in>Lock-in status ON # ON/OFF of Lock-in amplifier - doc: | - Status of Lock-in device whether while performing the experiment - - # amplifier_status: -> amplifier/active_channels - # Lock-in Amplifier>Yes/No - # doc: Lock-in Amplifier>Yes/No # If a lock-in amplifier employed to filter or obtain - # the electronic derivatives dI/dV of the signal - # hardware: Lock-in Amplifier>Hardware: Nanonis - modulation_signal: - exists: optional - unit: NX_VOLTAGE - doc: | - This is the signal on which the modulation (sine) will be added. - - # modulate_signal: Lock-in>Modulated signal Bias (V) - modulation_frequency(NX_NUMBER): - unit: NX_FREQUENCY - - # Lock-in>Frequency (Hz) 973E+0 - doc: | - The signal is modulated by adding the frequency of the sine modulation. The - modulation frequency spans can be from 10 mHz to 40 kHz, corresponding to the output filter - cut-off range. When dealing with harmonics, it's essential to ensure that the - harmonic frequencies remain below ~100 kHz, which aligns with the input filter cut-off. - Be mindful that hardware filters might impact the amplitude as the signal approaches - their cut-off frequencies." (e.g. 973E+0) - modulation_amplitude(NX_NUMBER): - - # amplitude: Lock-in>Amplitude 2E-3 - doc: | - The amplitude (in physical units of modulated signal) of the sine modulation. - demodulated_signal: - exists: optional - - # Lock-in>Demodulated signal Current (A) # This is the signal which - # will be demodulated, in order to determine the amplitude and phase at the frequency - # set in the Frequency field (“4”) or harmonics. - doc: | - The input signal (STS signal) will be demodulated, in order to determine the amplitude - and phase at the frequency set in the Frequency field or harmonics, such as current, - bias, et.al. - harmonic_order_N(NX_NUMBER): - - # Lock-in>Harmonic D1 1 - # Lock-in>Harmonic D2 2 # See below. - doc: | - N denotes 1 or 2. The order of the harmonic oscillation to be detected in the demodulated - signal should be considered relative to the modulation frequency. When dealing with - higher harmonics, it's essential to ensure that their frequencies do not surpass - the analogue signal bandwidth (e.g. harmonic_order_1). - ref_phase_N(NX_NUMBER): - exists: optional - - # Lock-in>Reference phase D1 (deg) 137.597E+0 - # Lock-in>Reference phase D2 (deg) -83.6562E+0 # See below. - doc: | - Reference phase for the sine on the demodulated signal with respect to the - modulation signal. The determined phase is displayed with respect to the - reference phase. - lock_in_data_flip_number(NX_NUMBER): - - # items below should go to bias/spectroscopy/...!!! - # recorded_channels: - # doc: Select the channels to record. (e.g. Current (A);LI Demod 2 X (A);LI Demod 2 Y (A); - # LI Demod 1 X (A);LI Demod 1 Y (A) # Select the channels to record.) - # bias_reset: - # doc: When selected, the Bias voltage returns to the initial value (before starting the - # sweep) at the end of the spectroscopy measurement (default). When not selected, Bias - # remains at the last value of the sweep. This is useful e.g. when combining several - # sweep segments. Example for an automated measurement (using Programming Interface): - # switch off Z-Controller, start spectroscopy sweep segments (only fwd sweep, no reset - # bias), set bias back to initial value, switch on Z-Controller. (e.g. TRUE) - # record_final_z: - # doc: Select whether to record the Z position during Z averaging time at the end of the - # sweep (after Z control time) and store the average value in the header of the file - # when saving. Using this option increases the sweep time by Z averaging time. (e.g. FALSE) - # run: - # doc: Bias Spectroscopy>Lock-In run FALSE # Select whether to set the Lock-In to run - # during the measurement. When using this feature, make sure the Lock-In is configured - # correctly and settling times are set to twice the Lock-In period at least. This - # option is ignored when Lock-In is already running. This option is disabled if the - # Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline - # segment editor is set. - sample_bias(NXiv_bias): - doc: | - Bias voltage applied to the sample. - bias(NX_NUMBER): - unit: NX_VOLTAGE - doc: | - Applied a voltage between tip and sample. - bias_calibration(NX_NUMBER): - bias_offset(NX_NUMBER): - unit: NX_VOLTAGE - - # sample_bias(NXbias): - # Tip bias/Sample bias If the spectroscopy V bias is applied to the - # Modulated signal Bias (V) 1E-3 Applied modulation to the bias voltage. - # ModulationBias> Tip bias/Sample bias - # modulated_signal_bias(NX_NUMBER): - # unit: NX_VOLTAGE - # doc: Same directional representation as bias. (e.g. 1E-3) - stm_head_temp(NX_NUMBER): - exists: optional - unit: NX_TEMPERATURE - doc: | - Temperature of STM head. Note: At least one field from stm_head_temperature, - cryo_bottom_temp and cryo_sheild_temp must be provided. - cryo_bottom_temp(NX_NUMBER): - exists: optional - unit: NX_TEMPERATURE - doc: | - Temperature of liquid helium cryostat. Note: At least one field from - stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp must be provided. - cryo_shield_temp(NX_NUMBER): - exists: optional - unit: NX_TEMPERATURE - doc: | - Temperature of liquid nitrogen shield. Temperature 3 (K) (e.g 78.00000E+0). Note: At - least one field from stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp - must be provided. - output_cabling(NXcircuit): - exists: optional - - # Cabling & Config - # output_mode: - # doc: Number of output channels. (e.g. User Output) - # output_value(NX_NUMBER): - # doc: The user output in each monitor mode. (e.g. 0E+0) - # output_name: - # doc: User outputs whose name can be modified in the corresponding module. (e.g. Input 24 (V)) - # output_slew_rate(NX_NUMBER): - # doc: The rate at which the one of the signal changes when ramping to the starting point. (V/s) (e.g. Inf) - piezo_config(NXcollection): - exists: optional - doc: | - Configuration for piezoelectric scanner used to move tip along X and Y direction. The - material of the Piezoelectric scanner composed of polycrystalline solids and sensitive to - applied voltage. - active_calib: - doc: | - The name of calibration type. (e.g. LHe) - calib_N(NX_NUMBER): - exists: optional - doc: | - N denotes X or Y or Z. There are three parameters in the X, Y, and Z directions, - along with three available controls: Calibration (m/V), Range (m), and HV gain. Only - two of these parameters are required to define the calibration. Consequently, when any - value is changed, one of the other values will be automatically updated. (e.g. calib_X = 3.8E-9) - hv_gain_N(NX_NUMBER): - exists: optional - doc: | - N denotes X or Y or Z. In some systems, there is an HV gain readout feature. For - these systems, the HV gain should be automatically adjusted whenever the gain is - changed at the high voltage amplifier. (e.g. 14.5) - - # (e.g. 0.318343) - tilt_N(NX_NUMBER): - exists: optional - unit: NX_ANGLE - doc: | - N denotes X or Y. There are 2 parameters in X and Y directions, and tilt needs to be - adjusted according to the actual surface. (in degrees, first order correction). - - # Inf - curvature_radius_N(NX_NUMBER): - exists: optional - unit: NX_LENGTH - doc: | - N denotes X or Y. There are 2 parameters in X and Y directions. (can be set - approximately to the length of the piezotube). - 2nd_order_corr_N(NX_NUMBER): - exists: optional - doc: | - N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, - you can enter the 2nd order piezo characteristics to compensate for it. The - following equation shows the interpretation of the 2nd order correction parameter: - For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: - [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx - is the 2nd order correction. (V/m^2). (e.g. 0E+0) - drift_N(NX_NUMBER): - exists: optional - doc: | - N denotes X, Y or Z. There are 3 parameters in X, Y and Z directions. Define the - drift speed for all three axes. When the compensation is on, the piezos will start to - move at that speed. (e.g. 0E+0) - drift_correction_status(NX_BOOLEAN): - doc: | - Use the button to enable or disable the drift compensation. (e.g. FALSE) - (NXenvironment): - doc: | - An environmental setup to measure the tunneling current due to different tip- - sample biases. - current_sensor(NXsensor): - exists: optional - current(NX_NUMBER): - unit: NX_CURRENT - doc: | - This is set-point of tip current (in the constant current mode should be equal to set-point, - in the constant height mode means the real tunnelling current between tip and sample). - current_calibration(NX_NUMBER): - unit: NX_CURRENT - doc: | - Value of calibration that comes as A/V. The value for this concept can be read - as current per unit voltage. - current_offset(NX_NUMBER): - unit: NX_CURRENT - current_gain(NX_NUMBER): - unit: NX_UNITLESS - calibration_time(NX_DATE_TIME): - exists: optional - value(NX_NUMBER): - exists: optional - position(NXpositioner_sts): - doc: | - Clarify the frame laboratory frame. - x(NX_NUMBER): - exists: optional - unit: NX_LENGTH - doc: | - The scanning area in x position in the frame. (e.g. -890.53E-12) - y(NX_NUMBER): - exists: optional - unit: NX_LENGTH - doc: | - The scanning area in y position in the frame. (e.g. 29.6968E-9) - z(NX_NUMBER): - exists: optional - unit: NX_LENGTH - doc: | - The scanning area in z position in the frame. (e.g. 130.5E-9) - z_controller(NXcollection): - z(NX_NUMBER): - unit: NX_LENGTH - doc: | - Indicate the relative tip position z between tip and sample. The tip position can also - be varied when the z_controller is not running. (e.g. 130.5E-9) - - # TODO: Is if this are uncomment than getting error. - # voltage_controller(NXsensor): - # temperature_controller(NXsensor): - # parameters for a measurement at a single location during the scan - sweep_control(NXcollection): - bias_spectroscopy(NXbias_spectroscopy): - exists: optional - integration_time(NX_NUMBER): - unit: NX_TIME - doc: | - Time during which the spectroscopy data are acquired and averaged. (e.g. 150E-6) - number_of_sweeps(NX_NUMBER): - doc: | - Number of sweeps to measure and average. (e.g. 100) - sweep_start(NX_NUMBER): - unit: NX_VOLTAGE - doc: | - The start bias values of the sweep. (e.g. -300E-3) - sweep_end(NX_NUMBER): - unit: NX_VOLTAGE - doc: | - The end bias values of the sweep. (e.g. 300E-3) - num_pixel(NX_NUMBER): - doc: | - The sweep number of points is defined as the maximum spectrum resolution, which - is equal to the bias sweep window divided by the number of pixels. (e.g. 4096) - z_avg_time(NX_NUMBER): - unit: NX_TIME - doc: | - The Z position is recorded and averaged for a certain duration both before and - after the sweep. After the initial Z averaging time, if "Z-Controller to Hold" - is selected, the Z-Controller is set to hold mode, and the tip is positioned at - the previously averaged Z position (adjusted by the Z offset). (e.g. 100E-3) - circuit(NXcollection): - exists: optional - rt_frequency(NX_NUMBER): - unit: NX_FREQUENCY - doc: | - The bandwidth of the Hardware and/or Software is instrument specific. - For example, Nanonis Generic 5 has 'RT Frequency' (e.g. 20E+3). - signals_oversampling(NX_NUMBER): - doc: | - The Signals Period represents the rate at which signals are transferred to - the host computer, which operates the control software. This rate may - be 10 times lower than the sampling rate, as the real-time engine internally - oversamples the signal. If desired, you may have the option to reduce the oversampling - to 1, enabling higher frequency resolution in the Spectrum Analyzer. (e.g. 10) - acquisition_period(NX_NUMBER): - unit: NX_TIME - exists: optional - doc: | - The update rate is utilized in various processes, including the History Graph, - Auto-Approach, and multiple Programming Interface functions. It may be - configured to a 20 ms interval. Any additional timings must strictly be integer - multiples of this base value. While it is possible to set these additional - timings to different values, the actual timing value will automatically be - adjusted to become a multiple of the Acquisition Period. (e.g. 20E-3) - animations_period(NX_NUMBER): - unit: NX_TIME - exists: optional - doc: | - The update rate of animated graphical indicators, such as graphs and sliders, - can be adjusted. A normal value may be 40 ms, which corresponds to 25 updates - per second. Increasing this period can help reduce the processor load on the - graphical user interface, particularly on slower computers. It is important to - note that this update rate solely impacts the user interface and does not affect - measurements in any manner. (e.g. 20E-3) - indicators_period(NX_NUMBER): - unit: NX_TIME - doc: | - The update rate of digital indicators, such as the numbers displayed, can be set - to 3 updates per second, equivalent to 300 ms. This interval is sufficient for - the user interface and does not impact measurements in any manner. (e.g. 300E-3) - measurements_period(NX_NUMBER): - exists: optional - unit: NX_TIME - doc: | - The Measurements period determines the integration time required for precise - measurements, primarily utilized in sweep modules. It is particularly useful for - tasks such as recording force-distance curves or cantilever resonances. For - swift measurements with small steps, a value of 40 ms is often adequate. For - regular use, a range of 300-500 ms may be recommended, but when capturing the - resonance of a high-Q cantilever, longer values in the range of several seconds - might be necessary. Usually, this parameter does not require manual adjustment - within this module, as the sweep modules automatically set this value according - to the sweep timings. (e.g. 500E-3) - - # parameters how to change the location from measurement to measurement during the scan - scan_control(NXcollection): - exists: optional - scan_range(NX_NUMBER): - unit: NX_LENGTH - exists: optional - doc: | - In STM experiment, the scan range is the coordinate (x,y) along the X and Y axis from the origin (scan_offset) of - the scan area (e.g. 5.000000E-9 5.000000E-9). - scan_offset(NX_NUMBER): - unit: NX_LENGTH - exists: optional - doc: | - In STM experiment, the scan offset is the position of the tip at the starting point of scan area. - (e.g. -2.354637E-7 1.267476E-) - scan_direction: - exists: optional - doc: | - In STM experiment, the scan direction is the direction from which side of the - sample the tip starts scanning. - enumeration: [down, up, top, bottom] - scan_angle(NX_NUMBER): - unit: NX_ANGLE - exists: optional - doc: | - The angle of scan with the bottom or top side (depends on the scan_direction - field) of the sample. (e.g. 0.000E+0). - roi(NXtransformations): - frame: - doc: | - Also clarify the frame for the ROI of the scan in lab frame, the middle of the lab - frame is (0, 0), and positive in x means right and in y means up. - circuit(NXcollection): - channels_current: - doc: | - The scan channels are selected by users. (e.g. (A);Bias (V);Z (m);LI Demod 2 X - (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A)) - positioner(NXcollection): - scanfield(NX_NUMBER): - exists: optional - doc: | - Configure the scan frame like x position; y position; width; height. (e.g. - 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0). If the 'scanfield' is not considered, use - the 'scan_range' and 'scan_offset' from 'scan_control' group - pixels_line(NX_NUMBER): - doc: | - Scan resolution by setting the Lines equal to Pixels. (e.g. 512) - lines(NX_NUMBER): - doc: | - Define the image resolution. (e.g. 512) - speed_forw(NX_NUMBER): - doc: | - Define the scan forward speed in the forward direction. (m/s) (e.g. 11.7187E-9) - speed_backw(NX_NUMBER): - doc: | - Define the scan backward speed in the forward direction. (m/s) (e.g. 11.7187E-9) - - # RESOLUTION (calculation input) - # TODO: After fix resolution_indicators back to required - # As all of the bellow are linked - # should be NXcollection not NXprocess - resolution_indicators(NXprocess): - exists: optional - - # Temperature 1>link to INSTR/STM/head Temperature 1 (K) (e.g. 4.92997E+0) # Temperature of STM head. - stm_head_temp(NX_NUMBER): - exists: optional - unit: NX_TEMPERATURE - doc: | - Link to target: /NXentry/NXinstrument/stm_head_temp - - # Temperature 2>link to Temperature 2 (K) - # Temperature of bottom of LHe helium cryostat. - cryo_bottom_temp(NX_NUMBER): - exists: optional - unit: NX_TEMPERATURE - doc: | - Link to target: /NXentry/NXinstrument/cryo_bottom_temp - - # Temperature 3>link to Temperature 3 (K) - # Temperature of LN2 nitrogen shield. - cryo_shield_temp(NX_NUMBER): - exists: optional - unit: NX_TEMPERATURE - doc: | - Link to target: /NXentry/NXinstrument/temp_cryo_shield - - # Lock-in>link to Modulated signal Bias (V) (e.g. 1E-3) # Applied modulation to the bias voltage. - modulation_signal: - exists: optional - unit: NX_VOLTAGE - doc: | - Link to target: /NXentry/NXinstrument/NXlock_in/modulation_signal - - # link to Integration time (s) (e.g. 150E-6) - # Time during which the spectroscopy data are acquired and averaged. - integration_time(NX_NUMBER): - unit: NX_TIME - doc: | - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/NXintegration_time - - # link to Bias Spectroscopy>Number of sweeps (e.g. 100) Number of sweeps to measure and average. - number_of_sweeps(NX_NUMBER): - unit: NX_UNITLESS - exists: optional - doc: | - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/number_of_sweeps - - # link to Bias Spectroscopy>Sweep Start (V) (e.g. -300E-3) # The first bias values of the sweep. - sweep_start(NX_NUMBER): - unit: NX_VOLTAGE - doc: | - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/sweep_start - - # link to Bias Spectroscopy>Sweep End (V) (e.g. 300E-3) # The last bias values of the sweep. - sweep_end(NX_NUMBER): - unit: NX_VOLTAGE - doc: | - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/sweep_end - - # link to Bias Spectroscopy>Num Pixel (e.g. 4096) # Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. - num_pixel(NX_NUMBER): - doc: | - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/num_pixel - - # link to Bias Spectroscopy>Z Avg time (s) (e.g. 100E-3) # Duration over which the Z - # position is recorded and averaged before and after the sweep (the latter only if Record - # final Z position is selected in the Advanced section). After the initial Z averaging - # time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is - # set to hold and the tip is placed at the previously averaged Z position (plus Z offset). - z_avg_time(NX_NUMBER): - unit: NX_TIME - doc: | - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_avg_time - - # link to SoftwareMain>RT Frequency (Hz) (e.g. 20E+3) # The bandwitdh of the - # Hardware and/or Software - rt_frequency(NX_NUMBER): - unit: NX_FREQUENCY - doc: | - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/rt_frequency - - # link to SoftwareMain>Signals Oversampling (e.g. 10) # (Signals Periods) - # The Signals Period is the rate at which the signals are transferred to the host computer - # running the control software. This is usually lower by a factor of 10 than the sampling - # rate, because an internal oversampling of the signal is done on the real time engine. - # You can reduce the oversampling down to 1 in order to resolve higher frequencies in the - # Spectrum Analyzer. - signals_oversampling(NX_NUMBER): - doc: | - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/signals_oversampling - - # link to SoftwareMain>Acquisition Period (s) (e.g. 20E-3) # Update rate for several - # processes like History Graph, Auto-Approach, and for many Programming Interface functions. - # This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples - # of this value. They can be set to different values, but the actual timing value will be - # coerced to a multiple of the Acquisition Period. - acquisition_period(NX_NUMBER): - unit: NX_TIME - exists: optional - doc: | - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/acquisition_period - - # link to SoftwareMain>Animations Period (s) (e.g. 20E-3) # Update rate of animated - # graphical indicators. These are e.g. some graphs & sliders. A reasonable value is - # 40 ms (25 updates per second). Increase this period to reduce the processor load - # for the graphical user interface, especially on slow computers. This value is purely a - # user interface update rate and does not affect measurements in any way. - animations_period(NX_NUMBER): - unit: NX_TIME - exists: optional - doc: | - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/animations_period - - # link to SoftwareMain>Indicators Period (s) (e.g. 300E-3) # Update rate of digital - # indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per - # second, or 300 ms is enough. This value is purely a user interface update rate and - # does not affect measurements in any way. - indicators_period(NX_NUMBER): - unit: NX_TIME - doc: | - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/indicators_period - - # link to SoftwareMain>Measurements Period (s) (e.g. 500E-3) # The Measurements - # period is the integration time for precise measurements (averaging over specified period), - # mostly used in sweep modules. Examples are recording of a force-distance curve or a - # resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be - # reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a - # high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. - measurements_period(NX_NUMBER): - exists: optional - unit: NX_TIME - doc: | - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/measurements_period - - # TODO: Later fix REPRODUCIBILITY_indicator - # as all of the bellow are linked - reproducibility_indicators(NXprocess): - exists: optional - - # Bias>Bias(NXBias) (V) (e.g. 100E-3) # Applied bias voltage. - bias(NX_NUMBER): - unit: NX_VOLTAGE - doc: | - Link to target: /NXentry/NXinstrument/NXsample_bias/bias - - # Current>Current(NXcircuit) (A) (e.g. -5.3429E-15) # The tunneling current is displayed here. - current(NX_NUMBER): - unit: NX_CURRENT - doc: | - Link to target: /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current - - # Bias>Calibration(NXbias) (V/V) (e.g. 1E+0) Calibration of the Bias output. If you have - # a Range switch the calibration is stored per range setting. - bias_calibration(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Link to target: /NXentry/NXnstrument/NXsample_bias/bias_calibration - bias_offset(NX_NUMBER): - unit: NX_VOLTAGE - doc: | - Link to target: /NXentry/NXinstrument/NXsample_bias/bias_offset - - # Current>Calibration(NXcircuit) (A/V) (e.g. 100E-12) - # The signals voltages are converted to real world physical values according to the calibration & offset parameters: - # Physical signal = (Voltage * calibration) + offset. - current_calibration(NX_NUMBER): - unit: NX_CURRENT - doc: | - Link to target: - /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_calibration - - # Current>Offset(NXcircuit) (A) (e.g. 16.2897E-15) # The same as "Current>Calibration (A/V)" tag - current_offset(NX_NUMBER): - unit: NX_CURRENT - doc: | - Link to target: - /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_offset - - # Current>Gain(NXcircuit) (e.g. Not switchable) # None - current_gain(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Link to target: - /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_gain - - # Z offset(NXpositioner_sts) (m) (e.g. 0E+0) # Offset added to the initial averaged position - # Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is - # deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an - # alternate Z-controller setpoint is enabled. - - # Settling time(NXbias) (s) (e.g. 2.1E-3) Time to wait after changing the bias to the next - # level and before starting to acquire data. Adjust this parameter to avoid transient - # effect induced by the bias change. Integration time: time during which the data are - # acquired and averaged. - z_offset(NX_NUMBER): - unit: NX_LENGTH - doc: | - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_offset - settling_time(NX_NUMBER): - unit: NX_TIME - exists: optional - doc: | - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/settling_time - - # Z-Ctrl hold(NXpositioner_sts) (e.g. TRUE) # When selected, the Z-Controller is set to hold - # during the pulse. This means that the controller doesn't control the Z position during the pulse. - z_control_hold(NX_BOOLEAN): - exists: optional - doc: | - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_ccontroller_hold - - # Final Z(NXpositioner_sts) (m) (e.g. N/A) - final_z(NX_NUMBER): - unit: NX_LENGTH - exists: optional - doc: | - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/record_final_z - - # Start time(NXlog) (e.g.23.11.2022 18:55:16) # Timestamp of the moment - # when the acquisition starts by pressing the Start button. - # TODO: no available concept is found for the below link - # start_time(link): - # exists: optional - # Link to t target: none - # Bias Spectroscopy>1st Settling time(NXbias) (s) (e.g.2.1E-3) # See the "Settling time (s)" below. - first_settling_time(NX_NUMBER): - unit: NX_TIME - exists: optional - doc: | - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/first_settling_time - - # Bias Spectroscopy>Integration time(NXbias) (s) (e.g.150E-6) # Time during which the data - # are acquired and averaged. - # integration_time(link): - # Link to ttarget: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/sweep_control/bias_spectroscopy/integration_time - # Bias Spectroscopy>End Settling time(NXbias) (s) (e.g.4E-3) # Time to wait after the sweep has finished and the bias is ramped to the initial value. - end_settling_time(NX_NUMBER): - unit: NX_TIME - exists: optional - doc: | - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/end_settling_time - - # Bias Spectroscopy>Z control time(NXbias) (s) (e.g.200E-3) # Time during which the - # Z-Controller is enabled once a sweep has finished. When averaging multiple sweeps - # (i.e. Sweeps>1), the Z-Controller is enabled for this duration between each sweep. - # After the last sweep, it will wait the specified time before continuing a running scan. - # This ensures each sweep reliably starts from the same position. This parameter is - # disabled when Z-Controller to Hold is deselected in the Advanced section. - z_control_time(NX_NUMBER): - unit: NX_TIME - exists: optional - doc: | - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_control_time - - # Bias Spectroscopy>Max Slew rate(NXbias) (V/s) (e.g.1E+0) # Maximum rate at which - # the bias changes (before, during and after sweeping). - max_slew_rate(NX_NUMBER): - unit: NX_ANY - exists: optional - doc: | - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/max_slew_rate - - # Bias Spectroscopy>backward sweep(NXbias) (e.g.TRUE) # Select whether to measure - # the backward (return) sweep or the forward only. - backward_sweep(NX_NUMBER): - unit: NX_ANY - exists: optional - doc: | - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/backward_sweep - - # Z-Controller>Controller name(NXpositioner_sts) (e.g.log Current) # Controller name. - # This name which will be displayed at places where you can select a controller. - z_controller_name: - exists: optional - doc: | - Link to target: - /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/controller_name - - # Z-Controller>Controller status(NXpositioner_sts) (e.g.OFF) # ON/OFF - z_controller_status(NX_BOOLEAN): - exists: optional - doc: | - Link to target: - /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/controller_status - - # Z-Controller>Setpoint(NXpositioner_sts) (e.g.50E-12) # Set Point is the desired value - # of the control signal. It can be set by editing the number or using the slider bar. - # Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. - # Z-Controller>Setpoint unit(NXpositioner_sts) (e.g.A) # Angstrom - z_controller_setpoint(NX_NUMBER): - unit: NX_CURRENT - exists: optional - doc: | - Link to target: - /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/set_point - - # Z-Controller>P gain(NXpid) (e.g.6E-12) # The Type switches controller parameters - # between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). - # The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). - # The integral gain and time constant are related as follows: I = P/T. - y_control_p_gain(NX_NUMBER): - exists: optional - doc: | - Link to target: - /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/p_gain - - # Z-Controller>I gain(NXpid) (e.g.39.8241E-9) # See "Z-Controller>P gain" below. - z_control_i_gain(NX_NUMBER): - exists: optional - doc: | - Link to target: - /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/i_gain - - # Z-Controller>Time const(NXpid) (s) (e.g.150.662E-6) # See "Z-Controller>P gain" below. - z_control_time_const(NX_NUMBER): - unit: NX_TIME - exists: optional - doc: | - Link to target: - /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/time_const - - # Z-Controller>TipLift(NXpositioner_sts) (m) (e.g.0E+0) # Lifts the tip by the specified - # amount when then controller is switched off. This can be a positive or a negative number, - # i.e. the tip can also be moved towards the sample. Be careful with sign and value when - # using this feature. - z_control_tip_lift(NX_NUMBER): - unit: NX_LENGTH - exists: optional - doc: | - Link to target: - /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/tip_lift - - # Z-Controller>Switch off delay(NXpositioner_sts) (s) (e.g.0E+0) # Use this parameter for - # a reproducible position when switching off the Z-controller. When >0 and the Z-controller - # is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. - z_control_switchoff_delay(NX_NUMBER): - unit: NX_TIME - exists: optional - doc: | - Link to target: - /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/switchoff_delay - sample(NXsample): - exists: optional - doc: | - This describes the sample and its properties, as well as constraints that are - applied to the sample before scanning. - sample_prep_descripton: - doc: | - At this moment no base class available that can track entire sample preparation. - - # TODO: discuss convertion data to DATA - (NXdata): - doc: | - This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. - There should also be two more fields called temperature and voltage containing the setpoint values. - There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension - equal to the number of voltage setpoints. - axes: bias_calc - signals: - li_demod_[1;2]_[X/Y]_[-;bwd;filt;bwd_filt] - current_[-;bwd;filt;bwd_filt] - temperature - - # DATA # multi dimensional array: multi I-V array per scan point; - # doc: The format of the data here is similar to a column matrix. - # Bias calc (V) #scanning parameter - # Current (A) # current during forward direction scanning of bias - original NXsensor - # LI Demod 2 X (A) lockin (NXsensor+lockin) - # LI Demod 2 Y (A) lockin - # LI Demod 1 X (A) lockin - # LI Demod 1 Y (A) lockin - # Current [bwd] (A) #bwd - backward (the positive direction shall be clarified by the reference bias scanning frame. Fwd means from left(neg) to right(pos). In the scannig image, the bottom(neg) to top(pos), the left(neg) to right(pos) - # LI Demod 2 X [bwd] (A) lockin - # LI Demod 2 Y [bwd] (A) lockin - # LI Demod 1 X [bwd] (A) lockin - # LI Demod 1 Y [bwd] (A) lockin - # Current (A) [filt] # forward direction (maybe from lockin#2?) - # LI Demod 2 X (A) [filt] lockin - # LI Demod 2 Y (A) [filt] lockin - # LI Demod 1 X (A) [filt] lockin - # LI Demod 1 Y (A) [filt] lockin - # Current (A) [bwd] [filt] - # LI Demod 2 X (A) [bwd] [filt] lockin - # LI Demod 2 Y (A) [bwd] [filt] lockin - # LI Demod 1 X (A) [bwd] [filt] lockin - # LI Demod 1 Y (A) [bwd] [filt] lockin - # Temperature - # x - # y - # z - # single point default plot # current(I) vs bias(V) - single_point(NXdata): - exists: optional - doc: | - Plot for a single point (x,y) with I vs. V curve. - - # line scan default plot # multi I vs. V curves - line_scan(NXdata): - exists: optional - doc: | - Line scan with multiple I vs. V curves for different single (x,y) co-ordinates. - - # alternative plot # current(I) curve in the 2D space of (position(x), bias(V)) - alternative_plot(NXdata): - exists: optional - doc: | - Plot for current(I) curve in the 2D space of (position(x), bias(V)) which can be - derived from the `line_scan` plot. - - # mesh scan default plot # 2D slices of the above alternative plot - mesh_scan(NXdata): - exists: optional - doc: | - Mesh scan with 2D slices of the above alternative plot for other y co-ordinates. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 776ea2eb9a35a47c82381344eb9b5edce08066a88c7acc5dc7ff8f00bdf680ba -# -# -# -# -# -# -# -# -# -# Application definition for temperature-dependent IV curve measurements -# #2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the -# STM image mode in the future with a focus on bias spectroscopy in Scanning Tunneling Microscopy. -# -# In this application definition, times should be specified always together with a UTC offset. -# -# This is the application definition describing temperature (T) dependent current voltage (IV) curve -# measurements. For this, a temperature is set. After reaching the temperature, a voltage sweep -# is performed. For each voltage, a current is measured. -# Then, the next desired temperature is set and an IV measurement is performed. -# The data can be visualized in a tensor with: -# I (NXsensor_C, NXsoftware_Read_offset, NXcircuit) -# parameters: -# V has (NXsource+offset, NXsoftware_Scan_offset, NXsensor_V, NXcircuit) -# T has (NXsource, NXsoftware_Scan_offset, NXsensor_T) -# x has (NXsoftware_Scan_offset) -# y has (NXsoftware_Scan_offset) -# z has (NXsoftware_Scan_offset) -# -# -# -# -# -# -# -# -# -# Name of the experiment where the application is applicable. -# -# -# -# -# -# -# -# -# The equipments and techniques as well as the parameter settings and reference signals -# are used during the experiments used in Scanning Tunneling Microscopy (STM). -# -# -# -# -# -# -# -# -# -# -# The name of the output file, with the number of scans at the end. (e.g. -# 221122_Au_5K00014) -# -# -# -# -# The name of the series output file, which represents only the public part of the -# output file. (e.g. 221122_Au_5K) -# -# -# -# -# Path to storage of output files. -# (e.g. Path C:\Users\SPM-PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis-Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711) -# -# -# -# -# Descriptive comments for this experiment, added by the experimenter, coming from the -# output file. (e.g. Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, locked Au(111), -# 50pA, 100 mV set point, 1mV DCA, 973Hz,138 1st H, -84 2nd H) -# -# -# -# -# -# Hardware type used in SPM experiment, includes hardware manufacturers and type. -# (e.g. Nanonis BP5e) -# -# -# -# -# -# Type of software used in SPM experiments, such as software version serial number, UI and -# RT probe release method. (e.g. SW Version Generic 5e -- RT Release 10771) -# -# -# -# -# -# The Amplifier description that improves or helps to determine tunnel current (current -# between tip and bias). -# -# -# -# -# -# -# Status of Lock-in device whether while performing the experiment -# -# -# -# -# -# This is the signal on which the modulation (sine) will be added. -# -# -# -# -# -# -# The signal is modulated by adding the frequency of the sine modulation. The -# modulation frequency spans can be from 10 mHz to 40 kHz, corresponding to the output filter -# cut-off range. When dealing with harmonics, it's essential to ensure that the -# harmonic frequencies remain below ~100 kHz, which aligns with the input filter cut-off. -# Be mindful that hardware filters might impact the amplitude as the signal approaches -# their cut-off frequencies." (e.g. 973E+0) -# -# -# -# -# -# The amplitude (in physical units of modulated signal) of the sine modulation. -# -# -# -# -# -# The input signal (STS signal) will be demodulated, in order to determine the amplitude -# and phase at the frequency set in the Frequency field or harmonics, such as current, -# bias, et.al. -# -# -# -# -# -# N denotes 1 or 2. The order of the harmonic oscillation to be detected in the demodulated -# signal should be considered relative to the modulation frequency. When dealing with -# higher harmonics, it's essential to ensure that their frequencies do not surpass -# the analogue signal bandwidth (e.g. harmonic_order_1). -# -# -# -# -# -# Reference phase for the sine on the demodulated signal with respect to the -# modulation signal. The determined phase is displayed with respect to the -# reference phase. -# -# -# -# -# -# -# -# Bias voltage applied to the sample. -# -# -# -# Applied a voltage between tip and sample. -# -# -# -# -# -# -# -# -# Temperature of STM head. Note: At least one field from stm_head_temperature, -# cryo_bottom_temp and cryo_sheild_temp must be provided. -# -# -# -# -# Temperature of liquid helium cryostat. Note: At least one field from -# stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp must be provided. -# -# -# -# -# Temperature of liquid nitrogen shield. Temperature 3 (K) (e.g 78.00000E+0). Note: At -# least one field from stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp -# must be provided. -# -# -# -# -# -# -# Configuration for piezoelectric scanner used to move tip along X and Y direction. The -# material of the Piezoelectric scanner composed of polycrystalline solids and sensitive to -# applied voltage. -# -# -# -# The name of calibration type. (e.g. LHe) -# -# -# -# -# N denotes X or Y or Z. There are three parameters in the X, Y, and Z directions, -# along with three available controls: Calibration (m/V), Range (m), and HV gain. Only -# two of these parameters are required to define the calibration. Consequently, when any -# value is changed, one of the other values will be automatically updated. (e.g. calib_X = 3.8E-9) -# -# -# -# -# N denotes X or Y or Z. In some systems, there is an HV gain readout feature. For -# these systems, the HV gain should be automatically adjusted whenever the gain is -# changed at the high voltage amplifier. (e.g. 14.5) -# -# -# -# -# -# N denotes X or Y. There are 2 parameters in X and Y directions, and tilt needs to be -# adjusted according to the actual surface. (in degrees, first order correction). -# -# -# -# -# -# N denotes X or Y. There are 2 parameters in X and Y directions. (can be set -# approximately to the length of the piezotube). -# -# -# -# -# N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, -# you can enter the 2nd order piezo characteristics to compensate for it. The -# following equation shows the interpretation of the 2nd order correction parameter: -# For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: -# [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx -# is the 2nd order correction. (V/m^2). (e.g. 0E+0) -# -# -# -# -# N denotes X, Y or Z. There are 3 parameters in X, Y and Z directions. Define the -# drift speed for all three axes. When the compensation is on, the piezos will start to -# move at that speed. (e.g. 0E+0) -# -# -# -# -# Use the button to enable or disable the drift compensation. (e.g. FALSE) -# -# -# -# -# -# An environmental setup to measure the tunneling current due to different tip- -# sample biases. -# -# -# -# -# This is set-point of tip current (in the constant current mode should be equal to set-point, -# in the constant height mode means the real tunnelling current between tip and sample). -# -# -# -# -# Value of calibration that comes as A/V. The value for this concept can be read -# as current per unit voltage. -# -# -# -# -# -# -# -# -# -# Clarify the frame laboratory frame. -# -# -# -# The scanning area in x position in the frame. (e.g. -890.53E-12) -# -# -# -# -# The scanning area in y position in the frame. (e.g. 29.6968E-9) -# -# -# -# -# The scanning area in z position in the frame. (e.g. 130.5E-9) -# -# -# -# -# -# Indicate the relative tip position z between tip and sample. The tip position can also -# be varied when the z_controller is not running. (e.g. 130.5E-9) -# -# -# -# -# -# -# -# -# -# Time during which the spectroscopy data are acquired and averaged. (e.g. 150E-6) -# -# -# -# -# Number of sweeps to measure and average. (e.g. 100) -# -# -# -# -# The start bias values of the sweep. (e.g. -300E-3) -# -# -# -# -# The end bias values of the sweep. (e.g. 300E-3) -# -# -# -# -# The sweep number of points is defined as the maximum spectrum resolution, which -# is equal to the bias sweep window divided by the number of pixels. (e.g. 4096) -# -# -# -# -# The Z position is recorded and averaged for a certain duration both before and -# after the sweep. After the initial Z averaging time, if "Z-Controller to Hold" -# is selected, the Z-Controller is set to hold mode, and the tip is positioned at -# the previously averaged Z position (adjusted by the Z offset). (e.g. 100E-3) -# -# -# -# -# -# -# The bandwidth of the Hardware and/or Software is instrument specific. -# For example, Nanonis Generic 5 has 'RT Frequency' (e.g. 20E+3). -# -# -# -# -# The Signals Period represents the rate at which signals are transferred to -# the host computer, which operates the control software. This rate may -# be 10 times lower than the sampling rate, as the real-time engine internally -# oversamples the signal. If desired, you may have the option to reduce the oversampling -# to 1, enabling higher frequency resolution in the Spectrum Analyzer. (e.g. 10) -# -# -# -# -# The update rate is utilized in various processes, including the History Graph, -# Auto-Approach, and multiple Programming Interface functions. It may be -# configured to a 20 ms interval. Any additional timings must strictly be integer -# multiples of this base value. While it is possible to set these additional -# timings to different values, the actual timing value will automatically be -# adjusted to become a multiple of the Acquisition Period. (e.g. 20E-3) -# -# -# -# -# The update rate of animated graphical indicators, such as graphs and sliders, -# can be adjusted. A normal value may be 40 ms, which corresponds to 25 updates -# per second. Increasing this period can help reduce the processor load on the -# graphical user interface, particularly on slower computers. It is important to -# note that this update rate solely impacts the user interface and does not affect -# measurements in any manner. (e.g. 20E-3) -# -# -# -# -# The update rate of digital indicators, such as the numbers displayed, can be set -# to 3 updates per second, equivalent to 300 ms. This interval is sufficient for -# the user interface and does not impact measurements in any manner. (e.g. 300E-3) -# -# -# -# -# The Measurements period determines the integration time required for precise -# measurements, primarily utilized in sweep modules. It is particularly useful for -# tasks such as recording force-distance curves or cantilever resonances. For -# swift measurements with small steps, a value of 40 ms is often adequate. For -# regular use, a range of 300-500 ms may be recommended, but when capturing the -# resonance of a high-Q cantilever, longer values in the range of several seconds -# might be necessary. Usually, this parameter does not require manual adjustment -# within this module, as the sweep modules automatically set this value according -# to the sweep timings. (e.g. 500E-3) -# -# -# -# -# -# -# -# -# In STM experiment, the scan range is the coordinate (x,y) along the X and Y axis from the origin (scan_offset) of -# the scan area (e.g. 5.000000E-9 5.000000E-9). -# -# -# -# -# In STM experiment, the scan offset is the position of the tip at the starting point of scan area. -# (e.g. -2.354637E-7 1.267476E-) -# -# -# -# -# In STM experiment, the scan direction is the direction from which side of the -# sample the tip starts scanning. -# -# -# -# -# -# -# -# -# -# -# The angle of scan with the bottom or top side (depends on the scan_direction -# field) of the sample. (e.g. 0.000E+0). -# -# -# -# -# -# Also clarify the frame for the ROI of the scan in lab frame, the middle of the lab -# frame is (0, 0), and positive in x means right and in y means up. -# -# -# -# -# -# -# The scan channels are selected by users. (e.g. (A);Bias (V);Z (m);LI Demod 2 X -# (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A)) -# -# -# -# -# -# -# Configure the scan frame like x position; y position; width; height. (e.g. -# 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0). If the 'scanfield' is not considered, use -# the 'scan_range' and 'scan_offset' from 'scan_control' group -# -# -# -# -# Scan resolution by setting the Lines equal to Pixels. (e.g. 512) -# -# -# -# -# Define the image resolution. (e.g. 512) -# -# -# -# -# Define the scan forward speed in the forward direction. (m/s) (e.g. 11.7187E-9) -# -# -# -# -# Define the scan backward speed in the forward direction. (m/s) (e.g. 11.7187E-9) -# -# -# -# -# -# -# -# -# -# -# -# Link to target: /NXentry/NXinstrument/stm_head_temp -# -# -# -# -# -# Link to target: /NXentry/NXinstrument/cryo_bottom_temp -# -# -# -# -# -# Link to target: /NXentry/NXinstrument/temp_cryo_shield -# -# -# -# -# -# Link to target: /NXentry/NXinstrument/NXlock_in/modulation_signal -# -# -# -# -# -# Link to target: -# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/NXintegration_time -# -# -# -# -# -# Link to target: -# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/number_of_sweeps -# -# -# -# -# -# Link to target: -# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/sweep_start -# -# -# -# -# -# Link to target: -# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/sweep_end -# -# -# -# -# -# Link to target: -# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/num_pixel -# -# -# -# -# -# Link to target: -# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_avg_time -# -# -# -# -# -# Link to target: -# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/rt_frequency -# -# -# -# -# -# Link to target: -# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/signals_oversampling -# -# -# -# -# -# Link to target: -# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/acquisition_period -# -# -# -# -# -# Link to target: -# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/animations_period -# -# -# -# -# -# Link to target: -# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/indicators_period -# -# -# -# -# -# Link to target: -# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/measurements_period -# -# -# -# -# -# -# -# -# Link to target: /NXentry/NXinstrument/NXsample_bias/bias -# -# -# -# -# -# Link to target: /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current -# -# -# -# -# -# Link to target: /NXentry/NXnstrument/NXsample_bias/bias_calibration -# -# -# -# -# Link to target: /NXentry/NXinstrument/NXsample_bias/bias_offset -# -# -# -# -# -# Link to target: -# /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_calibration -# -# -# -# -# -# Link to target: -# /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_offset -# -# -# -# -# -# Link to target: -# /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_gain -# -# -# -# -# -# -# Link to target: -# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_offset -# -# -# -# -# Link to target: -# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/settling_time -# -# -# -# -# -# Link to target: -# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_ccontroller_hold -# -# -# -# -# -# Link to target: -# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/record_final_z -# -# -# -# -# -# Link to target: -# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/first_settling_time -# -# -# -# -# -# Link to target: -# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/end_settling_time -# -# -# -# -# -# Link to target: -# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_control_time -# -# -# -# -# -# Link to target: -# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/max_slew_rate -# -# -# -# -# -# Link to target: -# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/backward_sweep -# -# -# -# -# -# Link to target: -# /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/controller_name -# -# -# -# -# -# Link to target: -# /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/controller_status -# -# -# -# -# -# Link to target: -# /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/set_point -# -# -# -# -# -# Link to target: -# /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/p_gain -# -# -# -# -# -# Link to target: -# /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/i_gain -# -# -# -# -# -# Link to target: -# /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/time_const -# -# -# -# -# -# Link to target: -# /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/tip_lift -# -# -# -# -# -# Link to target: -# /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/switchoff_delay -# -# -# -# -# -# This describes the sample and its properties, as well as constraints that are -# applied to the sample before scanning. -# -# -# -# At this moment no base class available that can track entire sample preparation. -# -# -# -# -# -# -# This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. -# There should also be two more fields called temperature and voltage containing the setpoint values. -# There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension -# equal to the number of voltage setpoints. -# axes: bias_calc -# signals: -# li_demod_[1;2]_[X/Y]_[-;bwd;filt;bwd_filt] -# current_[-;bwd;filt;bwd_filt] -# temperature -# -# -# -# -# -# Plot for a single point (x,y) with I vs. V curve. -# -# -# -# -# -# Line scan with multiple I vs. V curves for different single (x,y) co-ordinates. -# -# -# -# -# -# Plot for current(I) curve in the 2D space of (position(x), bias(V)) which can be -# derived from the `line_scan` plot. -# -# -# -# -# -# Mesh scan with 2D slices of the above alternative plot for other y co-ordinates. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXsubsampling_filter.yaml b/contributed_definitions/nyaml/NXsubsampling_filter.yaml deleted file mode 100644 index c96372f027..0000000000 --- a/contributed_definitions/nyaml/NXsubsampling_filter.yaml +++ /dev/null @@ -1,73 +0,0 @@ -category: base -doc: | - Base class of a filter to sample members in a set based on their identifier. - -# symbols: -type: group -NXsubsampling_filter(NXobject): - min_incr_max(NX_INT): - unit: NX_UNITLESS - doc: | - Triplet of the minimum, the increment, and the maximum identifier to - include of a sequence :math:`[i_0, i_0 + 1, i_0 + 2, \ldots, i_0 + \mathcal{N}] with i_0 \in \mathcal{Z}` - of identifier. The increment controls which n-th identifier (value) to take. - - Take as an example a dataset with 100 identifier (aka entries). Assume that - the identifier start at zero, i.e. identifier_offset is 0). Assume further - that min_incr_max is set to [0, 1, 99]. In this case the filter will - yield all identifier. Setting min_incr_max to [0, 2, 99] will take each - second identifier. Setting min_incr_max to [90, 3, 99] will take each - third identifier beginning from identifier 90 up to 99. - dimensions: - rank: 1 - dim: [[1, 3]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e2701c010e3087999ea363371d28ee558079269bea72b3980e707661bbd7d025 -# -# -# -# -# -# -# Base class of a filter to sample members in a set based on their identifier. -# -# -# -# Triplet of the minimum, the increment, and the maximum identifier to -# include of a sequence :math:`[i_0, i_0 + 1, i_0 + 2, \ldots, i_0 + \mathcal{N}] with i_0 \in \mathcal{Z}` -# of identifier. The increment controls which n-th identifier (value) to take. -# -# Take as an example a dataset with 100 identifier (aka entries). Assume that -# the identifier start at zero, i.e. identifier_offset is 0). Assume further -# that min_incr_max is set to [0, 1, 99]. In this case the filter will -# yield all identifier. Setting min_incr_max to [0, 2, 99] will take each -# second identifier. Setting min_incr_max to [90, 3, 99] will take each -# third identifier beginning from identifier 90 up to 99. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXtransmission.yaml b/contributed_definitions/nyaml/NXtransmission.yaml deleted file mode 100644 index a0d7fbbc42..0000000000 --- a/contributed_definitions/nyaml/NXtransmission.yaml +++ /dev/null @@ -1,610 +0,0 @@ -category: application -doc: | - Application definition for transmission experiments -symbols: - doc: | - Variables used throughout the experiment - N_wavelengths: | - Number of wavelength points - N_scans: | - Number of scans - -# FAIRmat consortium 21.07.2022 -# Draft NeXus application definition for transmission experiments -type: group -NXtransmission(NXobject): - (NXentry): - doc: | - This application definition - definition: - doc: | - An application definition for transmission. - \@version: - doc: | - Version number to identify which definition of this application definition was - used for this entry/data. - \@url: - doc: | - URL where to find further material (documentation, examples) relevant to the - application definition. - enumeration: [NXtransmission] - start_time(NX_DATE_TIME): - doc: | - Start time of the experiment. - experiment_identifier(NXidentifier): - doc: | - Unique identifier of the experiment, such as a (globally persistent) - unique identifier. - - * The identifier is usually defined by the facility or principle - investigator. - * The identifier enables to link experiments to e.g. proposals. - experiment_description(NX_CHAR): - exists: optional - doc: | - An optional free-text description of the experiment. However, details of the - experiment should be defined in the specific fields of this application - definition rather than in this experiment description. - - # TODO: Just used a NXmanufacturer, maybe - # it is nicer to introduce a general NXprogram class? - # However, a program may also be viewed as some sort - # of instrument. - acquisition_program(NXfabrication): - exists: optional - model(NX_CHAR): - doc: | - Commercial or otherwise defined given name to the program that was - used to generate the result file(s) with measured data and metadata. - identifier(NXidentifier): - doc: | - Version number of the program that was used to generate the result - file(s) with measured data and metadata. - \@url: - type: NX_CHAR - exists: recommended - doc: | - Website of the software - operator(NXuser): - exists: ['min', '1'] - doc: | - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - name: - doc: | - Name of the user. - affiliation: - doc: | - Name of the affiliation of the user at the point in time when the experiment was - performed. - address: - doc: | - Street address of the user's affiliation. - email: - doc: | - Email address of the user. - url: - exists: recommended - doc: | - Author ID defined by reasearch id services, e.g. orcid (https://orcid.org/). - telephone_number: - exists: recommended - doc: | - Telephone number of the user. - instrument(NXinstrument): - manufacturer(NXfabrication): - exists: recommended - doc: | - Manufacturer of the instrument. - common_beam_mask(NXslit): - doc: | - Common beam mask to shape the incident beam - y_gap(NX_NUMBER): - unit: NX_UNITLESS - doc: | - The height of the common beam in percentage of the beam - common_beam_depolarizer(NX_BOOLEAN): - doc: | - If true, the incident beam is depolarized. - polarizer(NX_NUMBER): - unit: NX_ANGLE - doc: | - Polarizer value inside the beam path - ref_attenuator(NXattenuator): - doc: | - Attenuator in the reference beam - attenuator_transmission(NX_FLOAT): - sample_attenuator(NXattenuator): - doc: | - Attenuator in the sample beam - attenuator_transmission(NX_FLOAT): - spectrometer(NXmonochromator): - wavelength(NX_NUMBER): - unit: NX_LENGTH - doc: | - Wavelength value(s) used for the measurement. - An array of 1 or more elements. Length defines N_wavelenghts - dimensions: - rank: 1 - dim: [[1, N_wavelengths]] - spectral_resolution(NX_NUMBER): - exists: optional - unit: NX_WAVENUMBER - doc: | - Overall spectral resolution of this spectrometer. - If several gratings are employed the spectral resoultion - should rather be specified for each grating inside the - NXgrating group of this spectrometer. - (NXgrating): - exists: optional - doc: | - Diffraction grating, as could be used in a monochromator. - If two or more gratings were used, define the angular - dispersion and the wavelength range (min/max wavelength) - for each grating and make sure that the wavelength ranges - do not overlap. The dispersion should be defined for the - entire wavelength range of the experiment. - angular_dispersion(NX_NUMBER): - exists: optional - doc: | - Dispersion of the grating in nm/mm used. - blaze_wavelength(NX_NUMBER): - exists: optional - unit: NX_LENGTH - doc: | - The blaze wavelength of the grating used. - spectral_resolution(NX_NUMBER): - exists: optional - unit: NX_WAVENUMBER - doc: | - Overall spectral resolution of the instrument - when this grating is used. - wavelength_range(NX_NUMBER): - unit: NX_LENGTH - doc: | - Wavelength range in which this grating was used - dimensions: - rank: 1 - dim: [[1, 2]] - (NXdetector): - wavelength_range(NX_NUMBER): - unit: NX_LENGTH - doc: | - Wavelength range in which this detector was used - dimensions: - rank: 1 - dim: [[1, 2]] - type(NX_CHAR): - doc: | - Detector type - enumeration: [PMT, PbS, InGaAs] - response_time(NX_NUMBER): - exists: optional - unit: NX_TIME - doc: | - Response time of the detector - gain(NX_NUMBER): - exists: optional - doc: | - Detector gain - slit(NXslit): - doc: | - Slit setting used for measurement with this detector - type(NX_CHAR): - enumeration: [fixed, servo] - time_points(NX_NUMBER): - exists: optional - unit: NX_TIME - doc: | - An array of relative scan start time points. - dimensions: - rank: 1 - dim: [[1, N_scans]] - measured_data(NX_NUMBER): - doc: | - Resulting data from the measurement. - The length of the 2nd dimension is - the number of time points. - If it has length one the time_points - may be empty. - dimensions: - rank: 2 - dim: [[1, N_scans], [2, N_wavelengths]] - (NXsource): - doc: | - The lamp used for illumination - type(NX_CHAR): - doc: | - The type of lamp, e.g. halogen, D2 etc. - enumeration: [halogen, D2] - spectrum(NX_NUMBER): - exists: optional - doc: | - The spectrum of the lamp used - dimensions: - rank: 1 - dim: [[1, N_wavelengths]] - wavelength_range(NX_NUMBER): - unit: NX_LENGTH - doc: | - Wavelength range in which the lamp was used - dimensions: - rank: 1 - dim: [[1, 2]] - (NXsample): - - # TODO: This should be extended by a generic - # NXsample class. - doc: | - Properties of the sample measured - name(NX_CHAR): - data(NXdata): - doc: | - A default view of the data emitted intensity vs. wavelength. - From measured_data plot intensity and wavelength. - \@axes: - doc: | - We recommend to use wavelength as a default attribute, but it can be - replaced by any suitable parameter along the X-axis. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 5b7a3a54abdb89ba72cdafc2c4de1b6f5b3a35e93e489aedfd2622fb1b45fc31 -# -# -# -# -# -# -# -# Variables used throughout the experiment -# -# -# -# Number of wavelength points -# -# -# -# -# Number of scans -# -# -# -# -# Application definition for transmission experiments -# -# -# -# This application definition -# -# -# -# An application definition for transmission. -# -# -# -# Version number to identify which definition of this application definition was -# used for this entry/data. -# -# -# -# -# URL where to find further material (documentation, examples) relevant to the -# application definition. -# -# -# -# -# -# -# -# -# Start time of the experiment. -# -# -# -# -# Unique identifier of the experiment, such as a (globally persistent) -# unique identifier. -# -# * The identifier is usually defined by the facility or principle -# investigator. -# * The identifier enables to link experiments to e.g. proposals. -# -# -# -# -# An optional free-text description of the experiment. However, details of the -# experiment should be defined in the specific fields of this application -# definition rather than in this experiment description. -# -# -# -# -# -# -# Commercial or otherwise defined given name to the program that was -# used to generate the result file(s) with measured data and metadata. -# -# -# -# -# Version number of the program that was used to generate the result -# file(s) with measured data and metadata. -# -# -# -# -# Website of the software -# -# -# -# -# -# Contact information of at least the user of the instrument or the investigator -# who performed this experiment. Adding multiple users if relevant is recommended. -# -# -# -# Name of the user. -# -# -# -# -# Name of the affiliation of the user at the point in time when the experiment was -# performed. -# -# -# -# -# Street address of the user's affiliation. -# -# -# -# -# Email address of the user. -# -# -# -# -# Author ID defined by reasearch id services, e.g. orcid (https://orcid.org/). -# -# -# -# -# Telephone number of the user. -# -# -# -# -# -# -# Manufacturer of the instrument. -# -# -# -# -# Common beam mask to shape the incident beam -# -# -# -# The height of the common beam in percentage of the beam -# -# -# -# -# -# If true, the incident beam is depolarized. -# -# -# -# -# Polarizer value inside the beam path -# -# -# -# -# Attenuator in the reference beam -# -# -# -# -# -# Attenuator in the sample beam -# -# -# -# -# -# -# Wavelength value(s) used for the measurement. -# An array of 1 or more elements. Length defines N_wavelenghts -# -# -# -# -# -# -# -# Overall spectral resolution of this spectrometer. -# If several gratings are employed the spectral resoultion -# should rather be specified for each grating inside the -# NXgrating group of this spectrometer. -# -# -# -# -# Diffraction grating, as could be used in a monochromator. -# If two or more gratings were used, define the angular -# dispersion and the wavelength range (min/max wavelength) -# for each grating and make sure that the wavelength ranges -# do not overlap. The dispersion should be defined for the -# entire wavelength range of the experiment. -# -# -# -# Dispersion of the grating in nm/mm used. -# -# -# -# -# The blaze wavelength of the grating used. -# -# -# -# -# Overall spectral resolution of the instrument -# when this grating is used. -# -# -# -# -# Wavelength range in which this grating was used -# -# -# -# -# -# -# -# -# -# -# Wavelength range in which this detector was used -# -# -# -# -# -# -# -# Detector type -# -# -# -# -# -# -# -# -# -# Response time of the detector -# -# -# -# -# Detector gain -# -# -# -# -# Slit setting used for measurement with this detector -# -# -# -# -# -# -# -# -# -# -# -# An array of relative scan start time points. -# -# -# -# -# -# -# -# Resulting data from the measurement. -# The length of the 2nd dimension is -# the number of time points. -# If it has length one the time_points -# may be empty. -# -# -# -# -# -# -# -# -# The lamp used for illumination -# -# -# -# The type of lamp, e.g. halogen, D2 etc. -# -# -# -# -# -# -# -# -# The spectrum of the lamp used -# -# -# -# -# -# -# -# Wavelength range in which the lamp was used -# -# -# -# -# -# -# -# -# -# -# Properties of the sample measured -# -# -# -# -# -# A default view of the data emitted intensity vs. wavelength. -# From measured_data plot intensity and wavelength. -# -# -# -# We recommend to use wavelength as a default attribute, but it can be -# replaced by any suitable parameter along the X-axis. -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXxpcs.yaml b/contributed_definitions/nyaml/NXxpcs.yaml deleted file mode 100644 index 419208e9ef..0000000000 --- a/contributed_definitions/nyaml/NXxpcs.yaml +++ /dev/null @@ -1,1085 +0,0 @@ -category: application -doc: | - X-ray Photon Correlation Spectroscopy (XPCS) data (results). - - The purpose of ``NXxpcs`` is to document and communicate an accepted vernacular for various XPCS results data - in order to support development of community software tools. The definition presented here only - represents a starting point and contains fields that a common software tool should support for - community acceptance. - - Additional fields may be added to XPCS results file (either formally or informally). It is expected - that this XPCS data will be part of multi-modal data set that could involve e.g., :ref:`NXcanSAS` or - 1D and/or 2D data. -symbols: - doc: | - The symbol(s) listed here will be used below to coordinate datasets with the same shape. - nP: | - Number of points -type: group -NXxpcs(NXobject): - (NXentry)entry: - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXxpcs] - entry_identifier: - doc: | - **Locally** unique identifier for the experiment (a.k.a. run or scan). - - * For bluesky users, this is the run's `"scan_id"`. - * For SPEC users, this is the scan number (``SCAN_N``). - entry_identifier_uuid: - exists: ['min', '0', 'max', '1'] - doc: | - (optional) UUID identifier for this entry. - - See the `UUID standard `__ (or - `wikipedia `__) - for more information. - - * For `bluesky `__ users, this is the - run's `"uid"` and is expected for that application. - * Typically, `SPEC `__ users will - not use this field without further engineering. - scan_number(NX_INT): - deprecated: Use the ``entry_identifier`` field. - - # Use of "deprecated" is to advise the XPCS authors of this change. - # The `scan_number` field will be removed by 2022-12-31. - doc: | - Scan number (must be an integer). - - NOTE: Link to collection_identifier. - start_time(NX_DATE_TIME): - doc: | - Starting time of experiment, such as "2021-02-11 11:22:33.445566Z". - end_time(NX_DATE_TIME): - exists: ['min', '0', 'max', '1'] - doc: | - Ending time of experiment, such as "2021-02-11 11:23:45Z". - (NXdata)data: - doc: | - The results data captured here are most commonly required for high throughput, equilibrium dynamics experiments. Data (results) - describing on-equilibrium dynamics consume more memory resources so these data are separated. - frame_sum(NX_NUMBER): - unit: NX_COUNT - exists: ['min', '0', 'max', '1'] - doc: | - Two-dimensional summation along the frames stack. - - sum of intensity v. time (in the units of "frames") - frame_average(NX_NUMBER): - unit: NX_COUNT - exists: ['min', '0', 'max', '1'] - doc: | - Two-dimensional average along the frames stack. - - average intensity v. time (in the units of "frames") - g2(NX_NUMBER): - unit: NX_DIMENSIONLESS - exists: ['min', '0', 'max', '1'] - doc: | - normalized intensity auto-correlation function, see Lumma, Rev. Sci. Instr. (2000), Eq 1 - - .. math:: g_2(\boldsymbol Q,t) = \frac{ \langle I(\boldsymbol Q,t\prime) I(\boldsymbol Q,t\prime + t) \rangle }{ \langle I(\boldsymbol Q,t\prime)\rangle^2 }; t > 0 - - Typically, :math:`g_2` is a quantity calculated for a group of pixels representing a specific - region of reciprocal space. These groupings, or bins, are generically described as :math:`q`. Some - open-source XPCS libraries refer to these bins as "rois", which are not to be confused with - EPICS AreaDetector ROI. See usage guidelines for q_lists and roi_maps within a mask. [#]_ - - In short, :math:`g_2` should be ordered according to the roi_map value. In principle, any format is acceptable if - the data and its axes are self-describing as per NeXus recommendations. However, the data is preferred in one - of the following two formats: - - * iterable list of linked files (or keys) for each :math:`g_2` with 1 file (key) per :math:`q`, where `q` is called by the nth roi_map value - * 2D array [#]_ with shape (:math:`g_2`, :math:`q`), where `q` is represented by the nth roi_map value, not the value `q` value - - Note it is expected that "g2" and all quantities following it will be of the same length. - - Other formats are acceptable with sufficient axes description. - - See references below for related implementation information: - - .. [#] mask: ``NXxpcs:/entry/instrument/masks-group`` - .. [#] NeXus 2-D data and axes: https://manual.nexusformat.org/classes/base_classes/NXdata.html#nxdata - \@storage_mode: - type: NX_CHAR - doc: | - storage_mode describes the format of the data to be loaded - - We encourage the documentation of other formats not represented here. - - * one array representing entire data set ("one_array") - * data exchange format with each key representing one ``q`` by its corresponding roi_map value ("data_exchange_keys") - enumeration: [one_array, data_exchange_keys, other] - g2_derr(NX_NUMBER): - unit: NX_DIMENSIONLESS - exists: ['min', '0', 'max', '1'] - doc: | - error values for the :math:`g_2` values. - - The derivation of the error is left up to the implemented code. Symmetric error will be - expected (:math:`\pm` error). The data should be in the same format as ``g2``. - \@storage_mode: - type: NX_CHAR - enumeration: [one_array, data_exchange_keys, other] - G2_unnormalized(NX_NUMBER): - unit: NX_ANY - exists: ['min', '0', 'max', '1'] - doc: | - unnormalized intensity auto-correlation function. - - Specifically, ``g2`` without the denominator. The data should be in the same format as ``g2``. - \@storage_mode: - type: NX_CHAR - enumeration: [one_array, data_exchange_keys, other] - delay_difference(NX_INT): - unit: NX_COUNT - exists: ['min', '0', 'max', '1'] - doc: | - delay_difference (also known as delay or lag step) - - This is quantized difference so that the "step" between two consecutive - frames is one frame (or step ``= dt = 1 frame``) - - It is the "quantized" delay time corresponding to the ``g2`` values. - - The unit of delay_differences is ``NX_INT`` for units of frames (i.e., integers) preferred, - refer to :ref:`NXdetector` for conversion to time units. - \@storage_mode: - type: NX_CHAR - enumeration: [one_array, data_exchange_keys, other] - (NXdata)twotime: - exists: ['min', '0'] - doc: | - The data (results) in this section are based on the two-time intensity correlation function derived from a time series of scattering images. - two_time_corr_func(NX_NUMBER): - unit: NX_ANY - exists: ['min', '0', 'max', '1'] - doc: | - two-time correlation of speckle intensity for a given q-bin or roi (represented by the nth roi_map value) - - See Fluerasu, Phys Rev E (2007), Eq 1 and Sutton, Optics Express (2003) for an early - description applied to X-ray scattering: - - .. math:: C(\boldsymbol Q, t_1, t_2) = \frac{ \langle I(\boldsymbol Q, t_1)I(\boldsymbol Q, t_2)\rangle }{ \langle I(\boldsymbol Q,t_1)\rangle \langle I(\boldsymbol Q,t_2)\rangle } - - in which time is quantized by frames. In principle, any data format is acceptable if - the data and its axes are self-describing as per NeXus recommendations. However, the data is preferred in one - of the following two formats: - - * iterable list of linked files (or keys) for each q-bin called by the nth roi_map value. data for each bin is a 2D array - * 3D array with shape (frames, frames, q) or (q, frames, frames), where :math:`q` is represented by the nth roi_map value, not the value `q` value - - - The computation of this result can be customized. These customizations can affect subsequently derived results (below). The - following attributes will be used to manage the customization. - - * Other normalization methods may be applied, but the method will not be specified in this - definition. Some of these normalization methods result in a baseline value of ``0``, not ``1``. - - * The various software libraries use different programming languages. Therefore, we need to - specify the ``time = 0`` origin location of the 2D array for each :math:`q`. - - * A method to reduce data storage needs is to only record half of the 2D array by populating - array elements above or below the array diagonal. - \@storage_mode: - type: NX_CHAR - doc: | - storage_mode describes the format of the data to be loaded - - We encourage the documention of other formats represented here. - enumeration: [one_array_q_first, one_array_q_last, data_exchange_keys, other] - \@baseline_reference: - type: NX_INT - doc: | - baseline is the expected value of a full decorrelation - - The baseline is a constant value added to the functional form of the auto-correlation - function. This value is required. - enumeration: [0, 1] - \@time_origin_location: - type: NX_CHAR - doc: | - time_origin_location is the location of the origin - enumeration: [upper_left, lower_left] - \@populated_elements: - type: NX_CHAR - doc: | - populated_elements describe the elements of the 2D array that are populated with data - enumeration: [all, upper_half, lower_half] - g2_from_two_time_corr_func(NX_NUMBER): - unit: NX_DIMENSIONLESS - exists: ['min', '0', 'max', '1'] - doc: | - frame weighted average along the diagonal direction in ``two_time_corr_func`` - - The data format and description should be consistent with that found in "/NXxpcs/entry/data/g2" - - * iterable list of linked files for each :math:`g_2` with 1 file per :math:`q` - * 2D array with shape (:math:`g_2`, :math:`q`) - - Note that delay_difference is not included here because it is derived from the shape of - extracted :math:`g_2` because all frames are considered, which is not necessarily the case for :math:`g_2`. - - The computation of this result can be customized. The customization can affect the fitting required to extract quantitative results. The - following attributes will be used to manage the customization. - \@storage_mode: - type: NX_CHAR - enumeration: [one_array_q_first, one_array_q_last, data_exchange_keys, other] - \@baseline_reference: - type: NX_INT - enumeration: [0, 1] - \@first_point_for_fit: - type: NX_INT - doc: | - first_point_for_fit describes if the first point should or should not be used in fitting the functional form of the dynamics to extract quantitative time-scale information. - - The first_point_for_fit is True ("1") or False ("0"). This value is required. - enumeration: [0, 1] - g2_err_from_two_time_corr_func(NX_NUMBER): - unit: NX_DIMENSIONLESS - exists: ['min', '0', 'max', '1'] - doc: | - error values for the :math:`g_2` values. - - The derivation of the error is left up to the implemented code. Symmetric error will be - expected (:math:`\pm` error). - \@storage_mode: - type: NX_CHAR - enumeration: [one_array_q_first, one_array_q_last, data_exchange_keys, other] - g2_from_two_time_corr_func_partials(NX_NUMBER): - unit: NX_DIMENSIONLESS - exists: ['min', '0', 'max', '1'] - doc: | - subset of frame weighted average along the diagonal direction in ``two_time_corr_func`` - - Time slicing along the diagonal can be very sophisticated. This entry currently assumes - equal frame-binning. The data formats are highly dependent on the implantation of various analysis libraries. - In principle, any data format is acceptable if the data and its axes are self describing as per NeXus - recommendations. However, the data is preferred in one of the following two formats: - - * iterable list of linked files (or keys) for each partial :math:`g_2` of each q-bin represented by the roi_map value - * 3D array with shape (:math:`g_2`, :math:`q`, nth_partial) - - Note that delay_difference is not included here because it is derived from the shape of - extracted :math:`g_2`. - \@storage_mode: - type: NX_CHAR - enumeration: [one_array, data_exchange_keys, other] - \@baseline_reference: - type: NX_INT - enumeration: [0, 1] - g2_err_from_two_time_corr_func_partials(NX_NUMBER): - unit: NX_DIMENSIONLESS - exists: ['min', '0', 'max', '1'] - doc: | - error values for the :math:`g_2` values. - - The derivation of the error is left up to the implemented code. Symmetric error will be - expected (:math:`\pm` error). - (NXinstrument)instrument: - doc: | - XPCS instrument Metadata. - - Objects can be entered here directly or linked from other - objects in the NeXus file (such as within ``/entry/instrument``). - (NXbeam)incident_beam: - incident_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - Incident beam line energy (either keV or eV). - incident_energy_spread(NX_FLOAT): - unit: NX_ENERGY - exists: ['min', '0', 'max', '1'] - doc: | - Spread of incident beam line energy (either keV or eV). This quantity is otherwise known - as the energy resolution, which is related to the longitudinal coherence length. - incident_polarization_type: - exists: ['min', '0', 'max', '1'] - doc: | - Terse description of the incident beam polarization. - - The value can be plain text, such as ``vertical``, ``C+``, - ``circular left``. - extent(NX_FLOAT): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - Size (2-D) of the beam at this position. - - # FIXME: (h, v) or (v, h)? State this in the docs FOR EPICS AD, likeky v, h. But seems CSX is (h,v) if looking - # from the source's perspective at the face of the detector - see fig 11 and fig 12 of cxidb documentation. this - # is also relevant for the next section, which is just describing the 2D array V, H is python/bluesky - (NXdetector): - doc: | - XPCS data is typically produced by area detector (likely EPICS AreaDetector) as a stack of 2D images. Sometimes - this data is represented in different ways (sparse arrays or photon event list), but this detail - is left to the analysis software. Therefore, we only include requirements based on full array data. - - We note that the image origin (pixel coordinates (0,0)) are found at the top left of a single 2D image array. This - is the standard expected by Coherent X-ray Imaging Data Bank. [#]_ - See CXI version 1.6 and Maia, Nature Methods (2012). This seems to be consistent with matplotlib and - the practiced implementation of EPICS AreaDetector. However, some exceptions may exists in the CXI - documentation (See Fig 11 vs Fig 12). - - Additionally, not all :ref:`NXdetector` dependencies are inherited from AreaDetector or other control systems. ``frame_time`` is used to - convert ``delay_difference`` to seconds. ``frame_time`` field could be missing from AreaDetector or may - either be `acquire_period` or `acquire_time`, depending on the detector model and the local implementation. - - .. [#] Coherent X-ray Imaging Data Bank: https://cxidb.org/cxi.html - description: - exists: ['min', '0', 'max', '1'] - doc: | - Detector name. - distance(NX_NUMBER): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - Distance between sample and detector. - count_time(NX_NUMBER): - unit: NX_TIME - doc: | - Exposure time of frames, s. - frame_time(NX_NUMBER): - unit: NX_TIME - doc: | - Exposure period (time between frame starts) of frames, s - beam_center_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Position of beam center, x axis, in detector's coordinates. - beam_center_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Position of beam center, y axis, in detector's coordinates. - x_pixel_size(NX_NUMBER): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - - # made this optional in case of single photon xy-time lists - doc: | - Length of pixel in x direction. - y_pixel_size(NX_NUMBER): - unit: NX_LENGTH - exists: ['min', '0', 'max', '1'] - doc: | - Length of pixel in y direction. - (NXnote)masks: - exists: ['min', '0', 'max', '1'] - doc: | - Data masks or mappings to regions of interest (roi) for specific :math:`Q` values - - Fields in this ``masks`` group describe regions of interest - in the data by either a mask to select pixels or to associate - a *map* of rois with a (one-dimensional) *list* of values. - - "roi_maps" provide for representation of pixel binning that are arbitrary and irregular, - which is geometry scattering agnostic and most flexible. The maps work as a labeled array for N rois. - - "Dynamic" represents quantities directly related to XPCS and NXxcps/entry/data and - NXxpcs/entry/two_time. - - "Static" refers to finer binning used for computation not strictly used for the final - XPCS results. Implementation of _static_ binning is left for individual libraries to - document. We encourage usage of :ref:`NXcanSAS` to represent standard SAXS results or - development of new NeXus definitions for GI-SAXS or other reciprocal space - intensity mapping. - dynamic_roi_map(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - roi index array or labeled array - - The values of this mask index (or map to) the :math:`Q` value from the - the ``dynamic_q_list`` field. Not that the value of ``0`` represents in-action. XPCS computations - are performed on all pixels with a value > 0. - - The ``units`` attribute should be set to ``"au"`` - indicating arbitrary units. - dynamic_q_list(NX_NUMBER): - unit: NX_PER_LENGTH - exists: ['min', '0'] - doc: | - 1-D list of :math:`Q` values, one for each roi index value. - - List order is determined by the index value of the associated roi map starting at ``1``. - - The only requirement for the list is that it may be iterable. Some expected formats are: - - * iterable list of floats (i.e., :math:`Q(r)`) - * iterable list of tuples (i.e., :math:`Q(r)`, :math:`\varphi`), but preferable use the seperate :math:`\varphi` field below - * iterable list of tuples (e.g., (H, K, L); (qx, qy, qz); (horizontal_pixel, vertical_pixel)) - * iterable list of integers (for Nth roi_map value) or strings - - This format is chosen because results plotting packages are not common and simple I/O is required by end user. - The lists can be accessed as lists, arrays or via keys - dynamic_phi_list(NX_NUMBER): - unit: NX_PER_LENGTH - exists: ['min', '0'] - doc: | - Array of :math:`\varphi` value for each pixel. - - List order is determined by the index value of the associated roi map starting at ``1``. - static_roi_map(NX_NUMBER): - unit: NX_DIMENSIONLESS - exists: ['min', '0'] - doc: | - roi index array. - - The values of this mask index the :math:`|Q|` value from the - the ``static_q_list`` field. - - The ``units`` attribute should be set to ``"au"`` - indicating arbitrary units. - static_q_list(NX_NUMBER): - unit: NX_PER_LENGTH - exists: ['min', '0'] - doc: | - 1-D list of :math:`|Q|` values, 1 for each roi. - (NXsample)sample: - exists: ['min', '0'] - - # Describes the minimum requirements regarding equilibrium sample conditions. NXsample - # permits other quantities (e.g., applied fields, crystallographic information, name, etc) that - # may optionally be include for equilibrium conditions (which is not exclusively equilibrium - # dynamics from XPCS analysis). - # For non-equilibrium sample conditions (i.e., changing sample or process conditions - # during the XPCS measurement) will require either a new entry or an additional atttribute. - temperature_set(NX_NUMBER): - unit: NX_TEMPERATURE - exists: ['min', '0'] - doc: | - Sample temperature setpoint, (C or K). - temperature(NX_NUMBER): - unit: NX_TEMPERATURE - exists: ['min', '0'] - doc: | - Sample temperature actual, (C or K). - (NXpositioner)position_x: - exists: ['min', '0'] - (NXpositioner)position_y: - exists: ['min', '0'] - (NXpositioner)position_z: - exists: ['min', '0'] - (NXnote)NOTE: - exists: ['min', '0', 'max', 'unbounded'] - doc: | - Any other notes. - - NAME: The NeXus convention, to use all upper case - to indicate the name (here ``NOTE``), is left to the file - writer. In our case, follow the suggested name - pattern and sequence: note_1, note_2, note_3, ... - Start with ``note_1`` if the first one, otherwise - pick the next number in this sequence. - (NXprocess): - doc: | - Describe the computation process that produced these results. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e441dbb2703c7c93841979c83e2456dd89139b900d59fea050fb65f601d4f74b -# -# -# -# -# -# -# The symbol(s) listed here will be used below to coordinate datasets with the same shape. -# -# -# Number of points -# -# -# -# X-ray Photon Correlation Spectroscopy (XPCS) data (results). -# -# The purpose of ``NXxpcs`` is to document and communicate an accepted vernacular for various XPCS results data -# in order to support development of community software tools. The definition presented here only -# represents a starting point and contains fields that a common software tool should support for -# community acceptance. -# -# Additional fields may be added to XPCS results file (either formally or informally). It is expected -# that this XPCS data will be part of multi-modal data set that could involve e.g., :ref:`NXcanSAS` or -# 1D and/or 2D data. -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# **Locally** unique identifier for the experiment (a.k.a. run or scan). -# -# * For bluesky users, this is the run's `"scan_id"`. -# * For SPEC users, this is the scan number (``SCAN_N``). -# -# -# -# -# (optional) UUID identifier for this entry. -# -# See the `UUID standard <https://www.rfc-editor.org/rfc/rfc4122.html>`__ (or -# `wikipedia <https://en.wikipedia.org/wiki/Universally_unique_identifier>`__) -# for more information. -# -# * For `bluesky <https://blueskyproject.io/>`__ users, this is the -# run's `"uid"` and is expected for that application. -# * Typically, `SPEC <https://certif.com/content/spec/>`__ users will -# not use this field without further engineering. -# -# -# -# -# -# Scan number (must be an integer). -# -# NOTE: Link to collection_identifier. -# -# -# -# -# Starting time of experiment, such as "2021-02-11 11:22:33.445566Z". -# -# -# -# -# Ending time of experiment, such as "2021-02-11 11:23:45Z". -# -# -# -# -# -# The results data captured here are most commonly required for high throughput, equilibrium dynamics experiments. Data (results) -# describing on-equilibrium dynamics consume more memory resources so these data are separated. -# -# -# -# Two-dimensional summation along the frames stack. -# -# sum of intensity v. time (in the units of "frames") -# -# -# -# -# Two-dimensional average along the frames stack. -# -# average intensity v. time (in the units of "frames") -# -# -# -# -# normalized intensity auto-correlation function, see Lumma, Rev. Sci. Instr. (2000), Eq 1 -# -# .. math:: g_2(\boldsymbol Q,t) = \frac{ \langle I(\boldsymbol Q,t\prime) I(\boldsymbol Q,t\prime + t) \rangle }{ \langle I(\boldsymbol Q,t\prime)\rangle^2 }; t > 0 -# -# Typically, :math:`g_2` is a quantity calculated for a group of pixels representing a specific -# region of reciprocal space. These groupings, or bins, are generically described as :math:`q`. Some -# open-source XPCS libraries refer to these bins as "rois", which are not to be confused with -# EPICS AreaDetector ROI. See usage guidelines for q_lists and roi_maps within a mask. [#]_ -# -# In short, :math:`g_2` should be ordered according to the roi_map value. In principle, any format is acceptable if -# the data and its axes are self-describing as per NeXus recommendations. However, the data is preferred in one -# of the following two formats: -# -# * iterable list of linked files (or keys) for each :math:`g_2` with 1 file (key) per :math:`q`, where `q` is called by the nth roi_map value -# * 2D array [#]_ with shape (:math:`g_2`, :math:`q`), where `q` is represented by the nth roi_map value, not the value `q` value -# -# Note it is expected that "g2" and all quantities following it will be of the same length. -# -# Other formats are acceptable with sufficient axes description. -# -# See references below for related implementation information: -# -# .. [#] mask: ``NXxpcs:/entry/instrument/masks-group`` -# .. [#] NeXus 2-D data and axes: https://manual.nexusformat.org/classes/base_classes/NXdata.html#nxdata -# -# -# -# storage_mode describes the format of the data to be loaded -# -# We encourage the documentation of other formats not represented here. -# -# * one array representing entire data set ("one_array") -# * data exchange format with each key representing one ``q`` by its corresponding roi_map value ("data_exchange_keys") -# -# -# -# -# -# -# -# -# -# -# error values for the :math:`g_2` values. -# -# The derivation of the error is left up to the implemented code. Symmetric error will be -# expected (:math:`\pm` error). The data should be in the same format as ``g2``. -# -# -# -# -# -# -# -# -# -# -# -# unnormalized intensity auto-correlation function. -# -# Specifically, ``g2`` without the denominator. The data should be in the same format as ``g2``. -# -# -# -# -# -# -# -# -# -# -# -# -# delay_difference (also known as delay or lag step) -# -# This is quantized difference so that the "step" between two consecutive -# frames is one frame (or step ``= dt = 1 frame``) -# -# It is the "quantized" delay time corresponding to the ``g2`` values. -# -# The unit of delay_differences is ``NX_INT`` for units of frames (i.e., integers) preferred, -# refer to :ref:`NXdetector` for conversion to time units. -# -# -# -# -# -# -# -# -# -# -# -# -# -# The data (results) in this section are based on the two-time intensity correlation function derived from a time series of scattering images. -# -# -# -# two-time correlation of speckle intensity for a given q-bin or roi (represented by the nth roi_map value) -# -# See Fluerasu, Phys Rev E (2007), Eq 1 and Sutton, Optics Express (2003) for an early -# description applied to X-ray scattering: -# -# .. math:: C(\boldsymbol Q, t_1, t_2) = \frac{ \langle I(\boldsymbol Q, t_1)I(\boldsymbol Q, t_2)\rangle }{ \langle I(\boldsymbol Q,t_1)\rangle \langle I(\boldsymbol Q,t_2)\rangle } -# -# in which time is quantized by frames. In principle, any data format is acceptable if -# the data and its axes are self-describing as per NeXus recommendations. However, the data is preferred in one -# of the following two formats: -# -# * iterable list of linked files (or keys) for each q-bin called by the nth roi_map value. data for each bin is a 2D array -# * 3D array with shape (frames, frames, q) or (q, frames, frames), where :math:`q` is represented by the nth roi_map value, not the value `q` value -# -# -# The computation of this result can be customized. These customizations can affect subsequently derived results (below). The -# following attributes will be used to manage the customization. -# -# * Other normalization methods may be applied, but the method will not be specified in this -# definition. Some of these normalization methods result in a baseline value of ``0``, not ``1``. -# -# * The various software libraries use different programming languages. Therefore, we need to -# specify the ``time = 0`` origin location of the 2D array for each :math:`q`. -# -# * A method to reduce data storage needs is to only record half of the 2D array by populating -# array elements above or below the array diagonal. -# -# -# -# -# -# storage_mode describes the format of the data to be loaded -# -# We encourage the documention of other formats represented here. -# -# -# -# -# -# -# -# -# -# -# baseline is the expected value of a full decorrelation -# -# The baseline is a constant value added to the functional form of the auto-correlation -# function. This value is required. -# -# -# -# -# -# -# -# -# time_origin_location is the location of the origin -# -# -# -# -# -# -# -# -# populated_elements describe the elements of the 2D array that are populated with data -# -# -# -# -# -# -# -# -# -# -# frame weighted average along the diagonal direction in ``two_time_corr_func`` -# -# The data format and description should be consistent with that found in "/NXxpcs/entry/data/g2" -# -# * iterable list of linked files for each :math:`g_2` with 1 file per :math:`q` -# * 2D array with shape (:math:`g_2`, :math:`q`) -# -# Note that delay_difference is not included here because it is derived from the shape of -# extracted :math:`g_2` because all frames are considered, which is not necessarily the case for :math:`g_2`. -# -# The computation of this result can be customized. The customization can affect the fitting required to extract quantitative results. The -# following attributes will be used to manage the customization. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# first_point_for_fit describes if the first point should or should not be used in fitting the functional form of the dynamics to extract quantitative time-scale information. -# -# The first_point_for_fit is True ("1") or False ("0"). This value is required. -# -# -# -# -# -# -# -# -# -# error values for the :math:`g_2` values. -# -# The derivation of the error is left up to the implemented code. Symmetric error will be -# expected (:math:`\pm` error). -# -# -# -# -# -# -# -# -# -# -# -# -# subset of frame weighted average along the diagonal direction in ``two_time_corr_func`` -# -# Time slicing along the diagonal can be very sophisticated. This entry currently assumes -# equal frame-binning. The data formats are highly dependent on the implantation of various analysis libraries. -# In principle, any data format is acceptable if the data and its axes are self describing as per NeXus -# recommendations. However, the data is preferred in one of the following two formats: -# -# * iterable list of linked files (or keys) for each partial :math:`g_2` of each q-bin represented by the roi_map value -# * 3D array with shape (:math:`g_2`, :math:`q`, nth_partial) -# -# Note that delay_difference is not included here because it is derived from the shape of -# extracted :math:`g_2`. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# error values for the :math:`g_2` values. -# -# The derivation of the error is left up to the implemented code. Symmetric error will be -# expected (:math:`\pm` error). -# -# -# -# -# -# -# XPCS instrument Metadata. -# -# Objects can be entered here directly or linked from other -# objects in the NeXus file (such as within ``/entry/instrument``). -# -# -# -# Incident beam line energy (either keV or eV). -# -# -# -# Spread of incident beam line energy (either keV or eV). This quantity is otherwise known -# as the energy resolution, which is related to the longitudinal coherence length. -# -# -# -# -# Terse description of the incident beam polarization. -# -# The value can be plain text, such as ``vertical``, ``C+``, -# ``circular left``. -# -# -# -# Size (2-D) of the beam at this position. -# -# -# -# -# -# -# XPCS data is typically produced by area detector (likely EPICS AreaDetector) as a stack of 2D images. Sometimes -# this data is represented in different ways (sparse arrays or photon event list), but this detail -# is left to the analysis software. Therefore, we only include requirements based on full array data. -# -# We note that the image origin (pixel coordinates (0,0)) are found at the top left of a single 2D image array. This -# is the standard expected by Coherent X-ray Imaging Data Bank. [#]_ -# See CXI version 1.6 and Maia, Nature Methods (2012). This seems to be consistent with matplotlib and -# the practiced implementation of EPICS AreaDetector. However, some exceptions may exists in the CXI -# documentation (See Fig 11 vs Fig 12). -# -# Additionally, not all :ref:`NXdetector` dependencies are inherited from AreaDetector or other control systems. ``frame_time`` is used to -# convert ``delay_difference`` to seconds. ``frame_time`` field could be missing from AreaDetector or may -# either be `acquire_period` or `acquire_time`, depending on the detector model and the local implementation. -# -# .. [#] Coherent X-ray Imaging Data Bank: https://cxidb.org/cxi.html -# -# -# Detector name. -# -# -# Distance between sample and detector. -# -# -# Exposure time of frames, s. -# -# -# -# Exposure period (time between frame starts) of frames, s -# -# -# -# -# Position of beam center, x axis, in detector's coordinates. -# -# -# -# -# Position of beam center, y axis, in detector's coordinates. -# -# -# -# -# -# Length of pixel in x direction. -# -# -# -# -# Length of pixel in y direction. -# -# -# -# -# -# -# Data masks or mappings to regions of interest (roi) for specific :math:`Q` values -# -# Fields in this ``masks`` group describe regions of interest -# in the data by either a mask to select pixels or to associate -# a *map* of rois with a (one-dimensional) *list* of values. -# -# "roi_maps" provide for representation of pixel binning that are arbitrary and irregular, -# which is geometry scattering agnostic and most flexible. The maps work as a labeled array for N rois. -# -# "Dynamic" represents quantities directly related to XPCS and NXxcps/entry/data and -# NXxpcs/entry/two_time. -# -# "Static" refers to finer binning used for computation not strictly used for the final -# XPCS results. Implementation of _static_ binning is left for individual libraries to -# document. We encourage usage of :ref:`NXcanSAS` to represent standard SAXS results or -# development of new NeXus definitions for GI-SAXS or other reciprocal space -# intensity mapping. -# -# -# -# roi index array or labeled array -# -# The values of this mask index (or map to) the :math:`Q` value from the -# the ``dynamic_q_list`` field. Not that the value of ``0`` represents in-action. XPCS computations -# are performed on all pixels with a value > 0. -# -# The ``units`` attribute should be set to ``"au"`` -# indicating arbitrary units. -# -# -# -# -# 1-D list of :math:`Q` values, one for each roi index value. -# -# List order is determined by the index value of the associated roi map starting at ``1``. -# -# The only requirement for the list is that it may be iterable. Some expected formats are: -# -# * iterable list of floats (i.e., :math:`Q(r)`) -# * iterable list of tuples (i.e., :math:`Q(r)`, :math:`\varphi`), but preferable use the seperate :math:`\varphi` field below -# * iterable list of tuples (e.g., (H, K, L); (qx, qy, qz); (horizontal_pixel, vertical_pixel)) -# * iterable list of integers (for Nth roi_map value) or strings -# -# This format is chosen because results plotting packages are not common and simple I/O is required by end user. -# The lists can be accessed as lists, arrays or via keys -# -# -# -# -# Array of :math:`\varphi` value for each pixel. -# -# List order is determined by the index value of the associated roi map starting at ``1``. -# -# -# -# -# roi index array. -# -# The values of this mask index the :math:`|Q|` value from the -# the ``static_q_list`` field. -# -# The ``units`` attribute should be set to ``"au"`` -# indicating arbitrary units. -# -# -# -# -# 1-D list of :math:`|Q|` values, 1 for each roi. -# -# -# -# -# -# -# -# -# -# Sample temperature setpoint, (C or K). -# -# -# -# -# Sample temperature actual, (C or K). -# -# -# -# -# -# -# -# -# -# Any other notes. -# -# NAME: The NeXus convention, to use all upper case -# to indicate the name (here ``NOTE``), is left to the file -# writer. In our case, follow the suggested name -# pattern and sequence: note_1, note_2, note_3, ... -# Start with ``note_1`` if the first one, otherwise -# pick the next number in this sequence. -# -# -# -# -# -# -# Describe the computation process that produced these results. -# -# -# diff --git a/contributed_definitions/nyaml/NXxrd.yaml b/contributed_definitions/nyaml/NXxrd.yaml deleted file mode 100644 index d81c3d1e11..0000000000 --- a/contributed_definitions/nyaml/NXxrd.yaml +++ /dev/null @@ -1,161 +0,0 @@ -category: application -doc: | - NXxrd on top of NXmonopd - -# ! : additions -# ? : could or should be modified? -type: group -NXxrd(NXmonopd): - (NXentry): - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXxrd] - (NXinstrument): - exists: optional - (NXbeam): - incident_energy(NX_FLOAT): - unit: NX_ENERGY - (NXdetector): - raw_data(NXdata): - exists: optional - doc: | - raw detector signal (usually counts) as colected - it can be a multi-dimensional dataset depending on - the detector type (faster axes) and - the scanning method (slower axes) - polar_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - The 2-theta range of the difractogram - dimensions: - rank: 1 - dim: (nDet,) - \@units: - enumeration: [deg] - (NXdata): - polar_angle(NX_FLOAT): - doc: | - link (suggested target:/NXentry/NXinstrument/NXdetector/polar_angle) - Link to ponglar ale in /NXentry/NXinstrument/NXdetector - dimensions: - rank: 1 - dim: (nDet,) - data(NX_NUMBER): - doc: | - link (suggested target:/NXentry/NXinstrument/NXdetector/data) - Link to data in /Nxentry/Nxinstrument/Nxdetector - dimensions: - rank: 1 - dim: (nDet,) - (NXprocess): - exists: optional - doc: | - Description of a processing or analysis step, such as the - baseline extraction or azimuth integration. - Add additional fields as needed to describe value(s) of - any variable, parameter, or term related to - the NXprocess step. Be sure to include units attributes - for all numerical fields. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4f2ea4ee6a66e3c162fccfc9a20a793590853e1d1577142e20f73699cfc792ab -# -# -# -# -# -# -# NXxrd on top of NXmonopd -# -# -# -# -# Official NeXus NXDL schema to which this file conforms -# -# -# -# -# -# -# -# -# -# -# -# -# raw detector signal (usually counts) as colected -# it can be a multi-dimensional dataset depending on -# the detector type (faster axes) and -# the scanning method (slower axes) -# -# -# -# -# The 2-theta range of the difractogram -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# link (suggested target:/NXentry/NXinstrument/NXdetector/polar_angle) -# Link to ponglar ale in /NXentry/NXinstrument/NXdetector -# -# -# -# -# -# -# -# link (suggested target:/NXentry/NXinstrument/NXdetector/data) -# Link to data in /Nxentry/Nxinstrument/Nxdetector -# -# -# -# -# -# -# -# -# Description of a processing or analysis step, such as the -# baseline extraction or azimuth integration. -# Add additional fields as needed to describe value(s) of -# any variable, parameter, or term related to -# the NXprocess step. Be sure to include units attributes -# for all numerical fields. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXxrd_pan.yaml b/contributed_definitions/nyaml/NXxrd_pan.yaml deleted file mode 100644 index 10a47787d0..0000000000 --- a/contributed_definitions/nyaml/NXxrd_pan.yaml +++ /dev/null @@ -1,581 +0,0 @@ -category: application -doc: | - NXxrd_pan is a specialisation of NXxrd with extra properties - for the PANalytical XRD data format. -type: group -NXxrd_pan(NXxrd): - (NXentry): - data_file: - exists: optional - doc: | - Name of the data file. - measurement_type: - doc: | - Type of measurement. - definition: - doc: | - Official NeXus NXDL schema to which this file conforms. - enumeration: [NXxrd_pan] - method: - doc: | - Method used to collect the data - default='X-Ray Diffraction (XRD)' - enumeration: [X-Ray Diffraction (XRD)] - (NXinstrument): - - # Need a group that explain - (NXsource): - xray_tube_material: - doc: | - Type of the X-ray tube. - enumeration: [Cu, Cr, Mo, Fe, Ag, In, Ga] - xray_tube_current(NX_FLOAT): - unit: NX_CURRENT - doc: | - Current of the X-ray tube. - xray_tube_voltage(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - Voltage of the X-ray tube. - - # Unicode for alpha : \u03b1 - k_alpha_one(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - Wavelength of the K\u03b1 1 line. - \@units: - enumeration: [angstrom] - k_alpha_two(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - Wavelength of the K\u03b1 2 line. - \@units: - enumeration: [angstrom] - ratio_k_alphatwo_k_alphaone(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - K\u03b1 2/K\u03b1 1 intensity ratio. - kbeta(NX_FLOAT): - exists: optional - unit: NX_WAVELENGTH - doc: | - Wavelength of the K\u00df line. - \@units: - enumeration: [angstrom] - source_peak_wavelength(NX_FLOAT): - exists: optional - unit: NX_WAVELENGTH - doc: | - Wavelength of the X-ray source. Used to convert from 2-theta to Q. - (NXdetector): - scan_axis: - doc: | - Axis scanned. - scan_mode: - doc: | - Mode of scan. - integration_time(NX_FLOAT): - exists: optional - unit: NX_TIME - doc: | - Integration time per channel. - - # Note: We should need to think about incident and deflected beam (NXbeam). As the data also contains - # beams information about the beam and the object encountered by beam through the path - # incident_beam(NXbeam): - # defracted_beam(NXbeam): - experiment_config(NXobject): - exists: optional - doc: | - Collect user inputs e.g. name or path of the input file. - two_theta(NXobject): - start(NX_FLOAT): - unit: NX_ANGLE - doc: | - Starting value of the diffraction angle. - end(NX_FLOAT): - unit: NX_ANGLE - doc: | - Ending value of the diffraction angle. - step(NX_FLOAT): - unit: NX_ANGLE - doc: | - Minimum step size in-between two diffraction angles. - omega(NXobject): - start(NX_FLOAT): - unit: NX_ANGLE - doc: | - Starting value of the incident angle. - end(NX_FLOAT): - unit: NX_ANGLE - doc: | - Ending value of the incident angle. - step(NX_FLOAT): - unit: NX_ANGLE - doc: | - Minimum step size in the between two incident angles. - beam_attenuation_factors: - doc: | - Beam attenuation factors over the path. - goniometer_x(NX_FLOAT): - exists: optional - unit: NX_LENGTH - doc: | - Goniometer position X. - goniometer_y(NX_FLOAT): - exists: optional - unit: NX_LENGTH - doc: | - Goniometer position Y. - goniometer_z(NX_FLOAT): - exists: optional - unit: NX_LENGTH - doc: | - Goniometer position Z - count_time(NX_FLOAT): - unit: NX_TIME - doc: | - Total time of count. - experiment_result(NXdata): - doc: | - All experiment results data such as scattering angle (2theta), - intensity, incident angle, scattering vector, etc will be stored here. - intensity(NX_FLOAT): - doc: | - Number of scattered electrons per unit time. - dimensions: - rank: 1 - dim: [[1, nDet]] - two_theta(NX_FLOAT): - unit: NX_ANGLE - doc: | - Two-theta (scattering angle) of the diffractogram. - dimensions: - rank: 1 - dim: [[1, nDet]] - omega(NX_FLOAT): - exists: optional - unit: NX_ANGLE - doc: | - Incident angle of the diffractogram. - dimensions: - rank: 1 - dim: [[1, nDet]] - phi(NX_FLOAT): - exists: optional - unit: NX_ANGLE - doc: | - The phi range of the diffractogram. - dimensions: - rank: 1 - dim: [[1, nDet]] - chi(NX_FLOAT): - exists: optional - unit: NX_ANGLE - doc: | - The chi range of the diffractogram - dimensions: - rank: 1 - dim: [[1, nDet]] - q_parallel(NX_FLOAT): - exists: optional - unit: NX_ANY - doc: | - The scattering vector component, which is parallel to the sample surface. - q_perpendicular(NX_FLOAT): - exists: optional - unit: NX_ANY - doc: | - The scattering vector component, which is perpendicular to the sample surface. - q_norm(NX_FLOAT): - exists: optional - unit: NX_ANY - doc: | - The norm value of the scattering vector, q. The scattering vector is defined as a - difference between the incident and scattered wave vectors. - For details: https://en.wikipedia.org/wiki/Powder_diffraction - and https://theory.labster.com/scattering-vector/ - q_data(NXdata): - exists: optional - doc: | - The desired view for scattering vectors. - q(NX_FLOAT): - exists: optional - doc: | - This concept corresponds to the norm value of the scattering vector(q). - The concept is the same as 'q_norm' of 'experiment_result' - and should be linked to /entry[ENTRY]/experiment_result/q_norm. - intensity(NX_FLOAT): - exists: optional - doc: | - Number of scattered electrons per unit time at each scattering vector (q) value. - The concept is the same as the 'intensity' of experiment_result - and should be linked to /entry[ENTRY]/experiment_result/intensity. - q_parallel(NX_FLOAT): - exists: optional - doc: | - The scattering vector (q) component, which is parallel to the sample surface. - This component is used in the Reciprocal Space Mapping (RSM) technique of - X-ray diffraction method. - - The concept is the same as 'q_parallel' of experiment_result, - and should be linked to /entry[ENTRY]/experiment_result/q_parallel. - q_perpendicular(NX_FLOAT): - exists: optional - doc: | - The scattering vector component, which is perpendicular to the sample surface. - - The concept is the same as 'q_perpendicular' of experiment_result, - and should be linked to /entry[ENTRY]/experiment_result/q_perpendicular. - (NXsample): - exists: optional - doc: | - Description on sample. - sample_mode: - doc: | - Mode of sample. - sample_id: - doc: | - Id of sample. - sample_name: - doc: | - Usually in xrd sample are being analysed, but sample might be identified by - assumed name or given name. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# fc8f25f08e852b590c75f476e9a5b4e369d8c262b7063c38a034184e2f89fbc2 -# -# -# -# -# -# NXxrd_pan is a specialisation of NXxrd with extra properties -# for the PANalytical XRD data format. -# -# -# -# -# Name of the data file. -# -# -# -# -# Type of measurement. -# -# -# -# -# Official NeXus NXDL schema to which this file conforms. -# -# -# -# -# -# -# -# Method used to collect the data -# default='X-Ray Diffraction (XRD)' -# -# -# -# -# -# -# -# -# -# -# Type of the X-ray tube. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Current of the X-ray tube. -# -# -# -# -# Voltage of the X-ray tube. -# -# -# -# -# -# Wavelength of the K\u03b1 1 line. -# -# -# -# -# -# -# -# -# -# Wavelength of the K\u03b1 2 line. -# -# -# -# -# -# -# -# -# -# K\u03b1 2/K\u03b1 1 intensity ratio. -# -# -# -# -# Wavelength of the K\u00df line. -# -# -# -# -# -# -# -# -# -# Wavelength of the X-ray source. Used to convert from 2-theta to Q. -# -# -# -# -# -# -# Axis scanned. -# -# -# -# -# Mode of scan. -# -# -# -# -# Integration time per channel. -# -# -# -# -# -# -# -# Collect user inputs e.g. name or path of the input file. -# -# -# -# -# Starting value of the diffraction angle. -# -# -# -# -# Ending value of the diffraction angle. -# -# -# -# -# Minimum step size in-between two diffraction angles. -# -# -# -# -# -# -# Starting value of the incident angle. -# -# -# -# -# Ending value of the incident angle. -# -# -# -# -# Minimum step size in the between two incident angles. -# -# -# -# -# -# Beam attenuation factors over the path. -# -# -# -# -# Goniometer position X. -# -# -# -# -# Goniometer position Y. -# -# -# -# -# Goniometer position Z -# -# -# -# -# Total time of count. -# -# -# -# -# -# All experiment results data such as scattering angle (2theta), -# intensity, incident angle, scattering vector, etc will be stored here. -# -# -# -# Number of scattered electrons per unit time. -# -# -# -# -# -# -# -# Two-theta (scattering angle) of the diffractogram. -# -# -# -# -# -# -# -# Incident angle of the diffractogram. -# -# -# -# -# -# -# -# The phi range of the diffractogram. -# -# -# -# -# -# -# -# The chi range of the diffractogram -# -# -# -# -# -# -# -# The scattering vector component, which is parallel to the sample surface. -# -# -# -# -# The scattering vector component, which is perpendicular to the sample surface. -# -# -# -# -# The norm value of the scattering vector, q. The scattering vector is defined as a -# difference between the incident and scattered wave vectors. -# For details: https://en.wikipedia.org/wiki/Powder_diffraction -# and https://theory.labster.com/scattering-vector/ -# -# -# -# -# -# The desired view for scattering vectors. -# -# -# -# This concept corresponds to the norm value of the scattering vector(q). -# The concept is the same as 'q_norm' of 'experiment_result' -# and should be linked to /entry[ENTRY]/experiment_result/q_norm. -# -# -# -# -# Number of scattered electrons per unit time at each scattering vector (q) value. -# The concept is the same as the 'intensity' of experiment_result -# and should be linked to /entry[ENTRY]/experiment_result/intensity. -# -# -# -# -# The scattering vector (q) component, which is parallel to the sample surface. -# This component is used in the Reciprocal Space Mapping (RSM) technique of -# X-ray diffraction method. -# -# The concept is the same as 'q_parallel' of experiment_result, -# and should be linked to /entry[ENTRY]/experiment_result/q_parallel. -# -# -# -# -# The scattering vector component, which is perpendicular to the sample surface. -# -# The concept is the same as 'q_perpendicular' of experiment_result, -# and should be linked to /entry[ENTRY]/experiment_result/q_perpendicular. -# -# -# -# -# -# Description on sample. -# -# -# -# Mode of sample. -# -# -# -# -# Id of sample. -# -# -# -# -# Usually in xrd sample are being analysed, but sample might be identified by -# assumed name or given name. -# -# -# -# -# From 228756980ea0077ec2fa7359f8570c5821a1add0 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 20 Sep 2024 11:48:43 +0200 Subject: [PATCH 0975/1012] move NXdata_mpes* classes back to contributed --- {base_classes => contributed_definitions}/NXdata_mpes.nxdl.xml | 0 .../NXdata_mpes_detector.nxdl.xml | 0 2 files changed, 0 insertions(+), 0 deletions(-) rename {base_classes => contributed_definitions}/NXdata_mpes.nxdl.xml (100%) rename {base_classes => contributed_definitions}/NXdata_mpes_detector.nxdl.xml (100%) diff --git a/base_classes/NXdata_mpes.nxdl.xml b/contributed_definitions/NXdata_mpes.nxdl.xml similarity index 100% rename from base_classes/NXdata_mpes.nxdl.xml rename to contributed_definitions/NXdata_mpes.nxdl.xml diff --git a/base_classes/NXdata_mpes_detector.nxdl.xml b/contributed_definitions/NXdata_mpes_detector.nxdl.xml similarity index 100% rename from base_classes/NXdata_mpes_detector.nxdl.xml rename to contributed_definitions/NXdata_mpes_detector.nxdl.xml From 154423248861a00a9132818fb198129caf63a91a Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 20 Sep 2024 14:12:59 +0200 Subject: [PATCH 0976/1012] revert small changes to the dev_tools black formatting isort dev_tools --- dev_tools/docs/nxdl.py | 4 ++-- dev_tools/utils/nxdl_utils.py | 6 ++++-- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/dev_tools/docs/nxdl.py b/dev_tools/docs/nxdl.py index 109ec5d872..ed3db94cca 100755 --- a/dev_tools/docs/nxdl.py +++ b/dev_tools/docs/nxdl.py @@ -12,8 +12,8 @@ from ..globals.errors import NXDLParseError from ..globals.nxdl import NXDL_NAMESPACE from ..globals.urls import REPO_URL -from ..utils import nxdl_utils as pynxtools_nxlib from ..utils.github import get_file_contributors_via_api +from ..utils.nxdl_utils import get_inherited_nodes from ..utils.types import PathLike from .anchor_list import AnchorRegistry @@ -703,7 +703,7 @@ def get_first_parent_ref(self, path, tag): path = path[path.find("/", 1) :] try: - parents = pynxtools_nxlib.get_inherited_nodes(path, nx_name)[2] + parents = get_inherited_nodes(path, nx_name)[2] except FileNotFoundError: return "" if len(parents) > 1: diff --git a/dev_tools/utils/nxdl_utils.py b/dev_tools/utils/nxdl_utils.py index 169d0be039..3abf139c38 100644 --- a/dev_tools/utils/nxdl_utils.py +++ b/dev_tools/utils/nxdl_utils.py @@ -78,9 +78,11 @@ def get_nexus_definitions_path(): def get_app_defs_names(): """Returns all the AppDef names without their extension: .nxdl.xml""" - app_def_path_glob = nexus_def_path / "applications" / "*.nxdl*" + app_def_path_glob = nexus_def_path / "applications" / "*.nxdl.xml" - contrib_def_path_glob = Path(nexus_def_path) / "contributed_definitions" / "*.nxdl*" + contrib_def_path_glob = ( + Path(nexus_def_path) / "contributed_definitions" / "*.nxdl.xml" + ) files = sorted(glob(str(app_def_path_glob))) for nexus_file in sorted(glob(str(contrib_def_path_glob))): From 105029ac2a5bab7c6d7afed4a388997c1521ba6c Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 20 Sep 2024 17:18:09 +0200 Subject: [PATCH 0977/1012] change docs in NXcircuit --- base_classes/NXcircuit.nxdl.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/base_classes/NXcircuit.nxdl.xml b/base_classes/NXcircuit.nxdl.xml index ede8976178..9648ae103a 100644 --- a/base_classes/NXcircuit.nxdl.xml +++ b/base_classes/NXcircuit.nxdl.xml @@ -23,7 +23,7 @@ --> - Application definition for circuit devices. + Base class for circuit devices. From 11fa448c96a78005a5a26c8cd45bec15c455bd59 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 20 Sep 2024 17:49:22 +0200 Subject: [PATCH 0978/1012] pull out modifications for fairmat-2024-contributed --- applications/NXapm.nxdl.xml | 1104 --------- applications/NXarpes.nxdl.xml | 9 +- applications/NXellipsometry.nxdl.xml | 422 ---- applications/NXem.nxdl.xml | 1663 -------------- applications/NXmpes.nxdl.xml | 918 -------- applications/NXmpes_arpes.nxdl.xml | 417 ---- applications/NXoptical_spectroscopy.nxdl.xml | 1218 ---------- applications/NXraman.nxdl.xml | 261 --- applications/NXxps.nxdl.xml | 510 ----- applications/xps/xps_cs.png | Bin 148952 -> 0 bytes base_classes/NXactuator.nxdl.xml | 127 - base_classes/NXaperture.nxdl.xml | 30 +- .../NXapm_charge_state_analysis.nxdl.xml | 168 -- base_classes/NXapm_hit_finding.nxdl.xml | 147 -- base_classes/NXapm_msr.nxdl.xml | 173 -- base_classes/NXapm_ranging.nxdl.xml | 111 - base_classes/NXapm_reconstruction.nxdl.xml | 123 - base_classes/NXapm_volt_and_bowl.nxdl.xml | 69 - base_classes/NXbeam.nxdl.xml | 157 +- base_classes/NXbeam_device.nxdl.xml | 67 - .../NXbeam_transfer_matrix_table.nxdl.xml | 120 - base_classes/NXcalibration.nxdl.xml | 220 -- .../NXcg_face_list_data_structure.nxdl.xml | 230 -- base_classes/NXcg_hexahedron_set.nxdl.xml | 193 -- base_classes/NXcg_parallelogram_set.nxdl.xml | 106 - base_classes/NXcg_point_set.nxdl.xml | 87 - base_classes/NXcg_polygon_set.nxdl.xml | 131 -- base_classes/NXcg_polyhedron_set.nxdl.xml | 114 - base_classes/NXcg_primitive_set.nxdl.xml | 212 -- base_classes/NXcg_roi_set.nxdl.xml | 57 - base_classes/NXcg_tetrahedron_set.nxdl.xml | 86 - base_classes/NXcg_triangle_set.nxdl.xml | 97 - base_classes/NXchemical_process.nxdl.xml | 60 - base_classes/NXcircuit.nxdl.xml | 136 -- base_classes/NXcomponent.nxdl.xml | 64 - base_classes/NXcoordinate_system.nxdl.xml | 159 -- base_classes/NXcoordinate_system_set.nxdl.xml | 240 -- base_classes/NXcorrector_cs.nxdl.xml | 221 -- base_classes/NXcrystal_structure.nxdl.xml | 274 --- base_classes/NXcs_computer.nxdl.xml | 146 -- base_classes/NXdata.nxdl.xml | 55 - base_classes/NXdetector.nxdl.xml | 60 +- base_classes/NXelectron_level.nxdl.xml | 918 -------- base_classes/NXelectronanalyser.nxdl.xml | 310 --- base_classes/NXem_correlation.nxdl.xml | 245 -- base_classes/NXem_ebsd.nxdl.xml | 712 ------ base_classes/NXem_eds.nxdl.xml | 225 -- base_classes/NXem_eels.nxdl.xml | 63 - base_classes/NXem_img.nxdl.xml | 61 - base_classes/NXem_msr.nxdl.xml | 98 - base_classes/NXem_sim.nxdl.xml | 59 - base_classes/NXenergydispersion.nxdl.xml | 209 -- base_classes/NXentry.nxdl.xml | 60 +- base_classes/NXenvironment.nxdl.xml | 38 +- base_classes/NXevent_data_apm.nxdl.xml | 281 --- base_classes/NXevent_data_apm_set.nxdl.xml | 48 - base_classes/NXevent_data_em.nxdl.xml | 168 -- base_classes/NXevent_data_em_set.nxdl.xml | 49 - base_classes/NXfabrication.nxdl.xml | 70 - base_classes/NXfit.nxdl.xml | 199 -- base_classes/NXfit_background.nxdl.xml | 80 - base_classes/NXfit_function.nxdl.xml | 47 - base_classes/NXhistory.nxdl.xml | 74 - base_classes/NXimage_set.nxdl.xml | 652 ------ base_classes/NXinstrument.nxdl.xml | 5 - base_classes/NXinteraction_vol_em.nxdl.xml | 57 - base_classes/NXion.nxdl.xml | 158 -- base_classes/NXlens_em.nxdl.xml | 96 - base_classes/NXmanipulator.nxdl.xml | 257 --- base_classes/NXmonochromator.nxdl.xml | 21 +- base_classes/NXopt_window.nxdl.xml | 128 -- base_classes/NXoptical_system_em.nxdl.xml | 155 -- base_classes/NXpeak.nxdl.xml | 86 - base_classes/NXphysical_process.nxdl.xml | 61 - base_classes/NXprocess.nxdl.xml | 16 +- base_classes/NXprocess_mpes.nxdl.xml | 317 --- base_classes/NXpulser_apm.nxdl.xml | 238 -- base_classes/NXreflectron.nxdl.xml | 86 - base_classes/NXresolution.nxdl.xml | 125 - base_classes/NXroot.nxdl.xml | 31 +- base_classes/NXrotation_set.nxdl.xml | 256 --- base_classes/NXsample.nxdl.xml | 68 +- base_classes/NXsample_component.nxdl.xml | 51 +- base_classes/NXsample_component_set.nxdl.xml | 78 - base_classes/NXscanbox_em.nxdl.xml | 111 - base_classes/NXsensor.nxdl.xml | 3 +- base_classes/NXserialized.nxdl.xml | 74 - base_classes/NXsingle_crystal.nxdl.xml | 72 - base_classes/NXsource.nxdl.xml | 152 +- base_classes/NXspectrum_set.nxdl.xml | 559 ----- base_classes/NXstage_lab.nxdl.xml | 173 -- base_classes/NXsubentry.nxdl.xml | 9 +- base_classes/NXsubstance.nxdl.xml | 119 - base_classes/NXtransformations.nxdl.xml | 9 +- base_classes/NXuser.nxdl.xml | 16 +- .../NXaberration.nxdl.xml | 44 +- .../NXaberration_model.nxdl.xml | 105 + .../NXaberration_model_ceos.nxdl.xml | 91 + .../NXaberration_model_nion.nxdl.xml | 63 + .../NXadc.nxdl.xml | 20 +- .../NXaperture_em.nxdl.xml | 37 +- contributed_definitions/NXapm.nxdl.xml | 1696 ++++++++++++++ .../NXapm_composition_space_results.nxdl.xml | 488 ++++ .../NXapm_input_ranging.nxdl.xml | 63 + .../NXapm_input_reconstruction.nxdl.xml | 58 + .../NXapm_paraprobe_config_clusterer.nxdl.xml | 477 ++++ .../NXapm_paraprobe_config_distancer.nxdl.xml | 257 +++ ...Xapm_paraprobe_config_intersector.nxdl.xml | 348 +++ .../NXapm_paraprobe_config_nanochem.nxdl.xml | 1114 +++++++++ .../NXapm_paraprobe_config_ranger.nxdl.xml | 297 +++ .../NXapm_paraprobe_config_selector.nxdl.xml | 142 ++ .../NXapm_paraprobe_config_spatstat.nxdl.xml | 374 +++ .../NXapm_paraprobe_config_surfacer.nxdl.xml | 289 +++ ...Xapm_paraprobe_config_tessellator.nxdl.xml | 253 ++ ...NXapm_paraprobe_config_transcoder.nxdl.xml | 119 + ...NXapm_paraprobe_results_clusterer.nxdl.xml | 503 ++++ ...NXapm_paraprobe_results_distancer.nxdl.xml | 388 ++++ ...apm_paraprobe_results_intersector.nxdl.xml | 395 ++++ .../NXapm_paraprobe_results_nanochem.nxdl.xml | 1965 ++++++++++++++++ .../NXapm_paraprobe_results_ranger.nxdl.xml | 425 ++++ .../NXapm_paraprobe_results_selector.nxdl.xml | 274 +++ .../NXapm_paraprobe_results_spatstat.nxdl.xml | 364 +++ .../NXapm_paraprobe_results_surfacer.nxdl.xml | 503 ++++ ...apm_paraprobe_results_tessellator.nxdl.xml | 677 ++++++ ...Xapm_paraprobe_results_transcoder.nxdl.xml | 568 +++++ .../NXcalibration.nxdl.xml | 111 + .../NXcg_alpha_complex.nxdl.xml | 113 +- .../NXcg_cylinder_set.nxdl.xml | 130 +- .../NXcg_ellipsoid_set.nxdl.xml | 135 ++ .../NXcg_face_list_data_structure.nxdl.xml | 243 ++ .../NXcg_geodesic_mesh.nxdl.xml | 42 +- .../NXcg_grid.nxdl.xml | 92 +- .../NXcg_half_edge_data_structure.nxdl.xml | 98 +- .../NXcg_hexahedron_set.nxdl.xml | 239 ++ .../NXcg_marching_cubes.nxdl.xml | 54 +- .../NXcg_parallelogram_set.nxdl.xml | 183 ++ .../NXcg_point_set.nxdl.xml | 98 + .../NXcg_polygon_set.nxdl.xml | 225 ++ .../NXcg_polyhedron_set.nxdl.xml | 194 ++ .../NXcg_polyline_set.nxdl.xml | 123 +- contributed_definitions/NXcg_roi_set.nxdl.xml | 40 + .../NXcg_sphere_set.nxdl.xml | 121 + .../NXcg_tetrahedron_set.nxdl.xml | 175 ++ .../NXcg_triangle_set.nxdl.xml | 132 ++ .../NXcg_triangulated_surface_mesh.nxdl.xml | 61 +- .../NXcg_unit_normal_set.nxdl.xml | 31 +- .../NXchamber.nxdl.xml | 17 +- .../NXchemical_composition.nxdl.xml | 0 .../NXcircuit_board.nxdl.xml | 45 + contributed_definitions/NXclustering.nxdl.xml | 124 + .../NXcollectioncolumn.nxdl.xml | 46 +- .../NXcoordinate_system_set.nxdl.xml | 137 ++ .../NXcorrector_cs.nxdl.xml | 95 + .../NXcs_computer.nxdl.xml | 80 + contributed_definitions/NXcs_cpu.nxdl.xml | 39 + .../NXcs_filter_boolean_mask.nxdl.xml | 68 +- contributed_definitions/NXcs_gpu.nxdl.xml | 39 + .../NXcs_io_obj.nxdl.xml | 41 +- .../NXcs_io_sys.nxdl.xml | 22 +- .../NXcs_mm_sys.nxdl.xml | 30 +- .../NXcs_prng.nxdl.xml | 58 +- .../NXcs_profiling.nxdl.xml | 68 +- .../NXcs_profiling_event.nxdl.xml | 27 +- contributed_definitions/NXdac.nxdl.xml | 38 + .../NXdeflector.nxdl.xml | 50 +- .../NXdistortion.nxdl.xml | 0 .../NXebeam_column.nxdl.xml | 72 +- .../NXelectronanalyser.nxdl.xml | 157 ++ .../NXellipsometry.nxdl.xml | 357 +++ contributed_definitions/NXem.nxdl.xml | 2034 +++++++++++++++++ contributed_definitions/NXem_ebsd.nxdl.xml | 1926 ++++++++++++++++ .../NXem_ebsd_conventions.nxdl.xml | 610 +++++ ...NXem_ebsd_crystal_structure_model.nxdl.xml | 207 +- .../NXenergydispersion.nxdl.xml | 90 + .../NXevent_data_em.nxdl.xml | 226 ++ .../NXevent_data_em_set.nxdl.xml | 18 +- .../NXfabrication.nxdl.xml | 37 +- .../NXibeam_column.nxdl.xml | 95 +- contributed_definitions/NXimage_set.nxdl.xml | 128 ++ .../NXimage_set_em_adf.nxdl.xml | 156 ++ .../NXimage_set_em_kikuchi.nxdl.xml | 205 ++ .../NXinteraction_vol_em.nxdl.xml | 37 + contributed_definitions/NXion.nxdl.xml | 168 ++ contributed_definitions/NXlens_em.nxdl.xml | 109 + .../NXlens_opt.nxdl.xml | 23 +- .../NXmanipulator.nxdl.xml | 100 + contributed_definitions/NXmpes.nxdl.xml | 371 +++ contributed_definitions/NXms.nxdl.xml | 529 +++++ .../NXms_feature_set.nxdl.xml | 300 +++ .../NXms_score_config.nxdl.xml | 452 ++++ .../NXms_score_results.nxdl.xml | 720 ++++++ .../NXms_snapshot.nxdl.xml | 47 +- .../NXms_snapshot_set.nxdl.xml | 62 + contributed_definitions/NXopt.nxdl.xml | 868 +++++++ .../NXoptical_system_em.nxdl.xml | 83 + .../NXorientation_set.nxdl.xml | 133 ++ contributed_definitions/NXpeak.nxdl.xml | 87 + .../NXpid.nxdl.xml | 35 +- .../NXprogram.nxdl.xml | 0 contributed_definitions/NXpulser_apm.nxdl.xml | 166 ++ .../NXpump.nxdl.xml | 12 +- contributed_definitions/NXreflectron.nxdl.xml | 56 + .../NXregistration.nxdl.xml | 0 contributed_definitions/NXscanbox_em.nxdl.xml | 47 + .../NXslip_system_set.nxdl.xml | 85 + .../NXspectrum_set.nxdl.xml | 162 ++ .../NXspectrum_set_em_eels.nxdl.xml | 188 ++ .../NXspectrum_set_em_xray.nxdl.xml | 311 +++ .../NXspindispersion.nxdl.xml | 0 contributed_definitions/NXstage_lab.nxdl.xml | 173 ++ .../NXwaveplate.nxdl.xml | 12 +- dev_tools/docs/anchor_list.py | 4 - dev_tools/docs/nxdl.py | 24 +- dev_tools/docs/nxdl_index.py | 40 +- dev_tools/tests/test_nxdl_utils.py | 165 -- dev_tools/utils/nxdl_utils.py | 196 +- .../classes/applications/apm-structure.rst | 284 --- .../container/ComplexContainerBeampath.png | Bin 7089 -> 0 bytes .../container/ComplexExampleContainer.png | Bin 25103 -> 0 bytes .../classes/applications/em-structure.rst | 164 -- .../classes/applications/mpes-structure.rst | 42 - .../optical-spectroscopy-structure.rst | 199 -- .../classes/base_classes/apm-structure.rst | 284 --- .../container/ComplexContainerBeampath.png | Bin 7089 -> 0 bytes .../container/ComplexExampleContainer.png | Bin 25103 -> 0 bytes .../classes/base_classes/em-structure.rst | 164 -- .../classes/base_classes/mpes-structure.rst | 77 - .../optical-spectroscopy-structure.rst | 199 -- .../contributed_definitions/apm-structure.rst | 398 ++-- .../cgms-structure.rst | 269 ++- .../container/ComplexContainerBeampath.png | Bin 7089 -> 0 bytes .../container/ComplexExampleContainer.png | Bin 25103 -> 0 bytes ...ructure.rst => ellipsometry-structure.rst} | 74 +- .../contributed_definitions/em-structure.rst | 159 +- .../icme-structure.rst | 48 - .../mpes-structure.rst | 27 +- .../sample-prep-structure.rst | 20 - .../contributed_definitions/sts-structure.rst | 47 - .../transport-structure.rst | 10 +- 239 files changed, 27463 insertions(+), 22161 deletions(-) delete mode 100644 applications/NXapm.nxdl.xml delete mode 100644 applications/NXellipsometry.nxdl.xml delete mode 100644 applications/NXem.nxdl.xml delete mode 100644 applications/NXmpes.nxdl.xml delete mode 100644 applications/NXmpes_arpes.nxdl.xml delete mode 100644 applications/NXoptical_spectroscopy.nxdl.xml delete mode 100644 applications/NXraman.nxdl.xml delete mode 100644 applications/NXxps.nxdl.xml delete mode 100644 applications/xps/xps_cs.png delete mode 100644 base_classes/NXactuator.nxdl.xml delete mode 100644 base_classes/NXapm_charge_state_analysis.nxdl.xml delete mode 100644 base_classes/NXapm_hit_finding.nxdl.xml delete mode 100644 base_classes/NXapm_msr.nxdl.xml delete mode 100644 base_classes/NXapm_ranging.nxdl.xml delete mode 100644 base_classes/NXapm_reconstruction.nxdl.xml delete mode 100644 base_classes/NXapm_volt_and_bowl.nxdl.xml delete mode 100644 base_classes/NXbeam_device.nxdl.xml delete mode 100644 base_classes/NXbeam_transfer_matrix_table.nxdl.xml delete mode 100644 base_classes/NXcalibration.nxdl.xml delete mode 100644 base_classes/NXcg_face_list_data_structure.nxdl.xml delete mode 100644 base_classes/NXcg_hexahedron_set.nxdl.xml delete mode 100644 base_classes/NXcg_parallelogram_set.nxdl.xml delete mode 100644 base_classes/NXcg_point_set.nxdl.xml delete mode 100644 base_classes/NXcg_polygon_set.nxdl.xml delete mode 100644 base_classes/NXcg_polyhedron_set.nxdl.xml delete mode 100644 base_classes/NXcg_primitive_set.nxdl.xml delete mode 100644 base_classes/NXcg_roi_set.nxdl.xml delete mode 100644 base_classes/NXcg_tetrahedron_set.nxdl.xml delete mode 100644 base_classes/NXcg_triangle_set.nxdl.xml delete mode 100644 base_classes/NXchemical_process.nxdl.xml delete mode 100644 base_classes/NXcircuit.nxdl.xml delete mode 100644 base_classes/NXcomponent.nxdl.xml delete mode 100644 base_classes/NXcoordinate_system.nxdl.xml delete mode 100644 base_classes/NXcoordinate_system_set.nxdl.xml delete mode 100644 base_classes/NXcorrector_cs.nxdl.xml delete mode 100644 base_classes/NXcrystal_structure.nxdl.xml delete mode 100644 base_classes/NXcs_computer.nxdl.xml delete mode 100644 base_classes/NXelectron_level.nxdl.xml delete mode 100644 base_classes/NXelectronanalyser.nxdl.xml delete mode 100644 base_classes/NXem_correlation.nxdl.xml delete mode 100644 base_classes/NXem_ebsd.nxdl.xml delete mode 100644 base_classes/NXem_eds.nxdl.xml delete mode 100644 base_classes/NXem_eels.nxdl.xml delete mode 100644 base_classes/NXem_img.nxdl.xml delete mode 100644 base_classes/NXem_msr.nxdl.xml delete mode 100644 base_classes/NXem_sim.nxdl.xml delete mode 100644 base_classes/NXenergydispersion.nxdl.xml mode change 100644 => 100755 base_classes/NXentry.nxdl.xml delete mode 100644 base_classes/NXevent_data_apm.nxdl.xml delete mode 100644 base_classes/NXevent_data_apm_set.nxdl.xml delete mode 100644 base_classes/NXevent_data_em.nxdl.xml delete mode 100644 base_classes/NXevent_data_em_set.nxdl.xml delete mode 100644 base_classes/NXfabrication.nxdl.xml delete mode 100644 base_classes/NXfit.nxdl.xml delete mode 100644 base_classes/NXfit_background.nxdl.xml delete mode 100644 base_classes/NXfit_function.nxdl.xml delete mode 100644 base_classes/NXhistory.nxdl.xml delete mode 100644 base_classes/NXimage_set.nxdl.xml delete mode 100644 base_classes/NXinteraction_vol_em.nxdl.xml delete mode 100644 base_classes/NXion.nxdl.xml delete mode 100644 base_classes/NXlens_em.nxdl.xml delete mode 100644 base_classes/NXmanipulator.nxdl.xml delete mode 100644 base_classes/NXopt_window.nxdl.xml delete mode 100644 base_classes/NXoptical_system_em.nxdl.xml delete mode 100644 base_classes/NXpeak.nxdl.xml delete mode 100644 base_classes/NXphysical_process.nxdl.xml delete mode 100644 base_classes/NXprocess_mpes.nxdl.xml delete mode 100644 base_classes/NXpulser_apm.nxdl.xml delete mode 100644 base_classes/NXreflectron.nxdl.xml delete mode 100644 base_classes/NXresolution.nxdl.xml delete mode 100644 base_classes/NXrotation_set.nxdl.xml mode change 100644 => 100755 base_classes/NXsample.nxdl.xml delete mode 100644 base_classes/NXsample_component_set.nxdl.xml delete mode 100644 base_classes/NXscanbox_em.nxdl.xml delete mode 100644 base_classes/NXserialized.nxdl.xml delete mode 100644 base_classes/NXsingle_crystal.nxdl.xml delete mode 100644 base_classes/NXspectrum_set.nxdl.xml delete mode 100644 base_classes/NXstage_lab.nxdl.xml delete mode 100644 base_classes/NXsubstance.nxdl.xml rename {base_classes => contributed_definitions}/NXaberration.nxdl.xml (62%) create mode 100644 contributed_definitions/NXaberration_model.nxdl.xml create mode 100644 contributed_definitions/NXaberration_model_ceos.nxdl.xml create mode 100644 contributed_definitions/NXaberration_model_nion.nxdl.xml rename base_classes/NXcg_triangulated_surface_mesh.nxdl.xml => contributed_definitions/NXadc.nxdl.xml (67%) rename base_classes/NXactivity.nxdl.xml => contributed_definitions/NXaperture_em.nxdl.xml (53%) create mode 100644 contributed_definitions/NXapm.nxdl.xml create mode 100644 contributed_definitions/NXapm_composition_space_results.nxdl.xml create mode 100644 contributed_definitions/NXapm_input_ranging.nxdl.xml create mode 100644 contributed_definitions/NXapm_input_reconstruction.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_config_selector.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_results_clusterer.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_results_intersector.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_results_selector.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_results_spatstat.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml create mode 100644 contributed_definitions/NXcalibration.nxdl.xml rename {base_classes => contributed_definitions}/NXcg_alpha_complex.nxdl.xml (57%) rename {base_classes => contributed_definitions}/NXcg_cylinder_set.nxdl.xml (51%) create mode 100644 contributed_definitions/NXcg_ellipsoid_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_face_list_data_structure.nxdl.xml rename {base_classes => contributed_definitions}/NXcg_geodesic_mesh.nxdl.xml (58%) rename {base_classes => contributed_definitions}/NXcg_grid.nxdl.xml (60%) rename {base_classes => contributed_definitions}/NXcg_half_edge_data_structure.nxdl.xml (62%) create mode 100644 contributed_definitions/NXcg_hexahedron_set.nxdl.xml rename {base_classes => contributed_definitions}/NXcg_marching_cubes.nxdl.xml (54%) create mode 100644 contributed_definitions/NXcg_parallelogram_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_point_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polygon_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_polyhedron_set.nxdl.xml rename {base_classes => contributed_definitions}/NXcg_polyline_set.nxdl.xml (51%) create mode 100644 contributed_definitions/NXcg_roi_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_sphere_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_tetrahedron_set.nxdl.xml create mode 100644 contributed_definitions/NXcg_triangle_set.nxdl.xml rename base_classes/NXcg_ellipsoid_set.nxdl.xml => contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml (50%) rename {base_classes => contributed_definitions}/NXcg_unit_normal_set.nxdl.xml (71%) rename {base_classes => contributed_definitions}/NXchamber.nxdl.xml (76%) rename {base_classes => contributed_definitions}/NXchemical_composition.nxdl.xml (100%) create mode 100644 contributed_definitions/NXcircuit_board.nxdl.xml create mode 100644 contributed_definitions/NXclustering.nxdl.xml rename {base_classes => contributed_definitions}/NXcollectioncolumn.nxdl.xml (73%) create mode 100644 contributed_definitions/NXcoordinate_system_set.nxdl.xml create mode 100644 contributed_definitions/NXcorrector_cs.nxdl.xml create mode 100644 contributed_definitions/NXcs_computer.nxdl.xml create mode 100644 contributed_definitions/NXcs_cpu.nxdl.xml rename {base_classes => contributed_definitions}/NXcs_filter_boolean_mask.nxdl.xml (53%) create mode 100644 contributed_definitions/NXcs_gpu.nxdl.xml rename base_classes/NXidentifier.nxdl.xml => contributed_definitions/NXcs_io_obj.nxdl.xml (55%) rename base_classes/NXroi.nxdl.xml => contributed_definitions/NXcs_io_sys.nxdl.xml (75%) rename base_classes/NXem_method.nxdl.xml => contributed_definitions/NXcs_mm_sys.nxdl.xml (57%) rename {base_classes => contributed_definitions}/NXcs_prng.nxdl.xml (62%) rename {base_classes => contributed_definitions}/NXcs_profiling.nxdl.xml (72%) rename {base_classes => contributed_definitions}/NXcs_profiling_event.nxdl.xml (82%) create mode 100644 contributed_definitions/NXdac.nxdl.xml rename {base_classes => contributed_definitions}/NXdeflector.nxdl.xml (77%) rename {base_classes => contributed_definitions}/NXdistortion.nxdl.xml (100%) rename {base_classes => contributed_definitions}/NXebeam_column.nxdl.xml (59%) create mode 100644 contributed_definitions/NXelectronanalyser.nxdl.xml create mode 100644 contributed_definitions/NXellipsometry.nxdl.xml create mode 100644 contributed_definitions/NXem.nxdl.xml create mode 100644 contributed_definitions/NXem_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXem_ebsd_conventions.nxdl.xml rename base_classes/NXunit_cell.nxdl.xml => contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml (54%) create mode 100644 contributed_definitions/NXenergydispersion.nxdl.xml create mode 100644 contributed_definitions/NXevent_data_em.nxdl.xml rename base_classes/NXapm_sim.nxdl.xml => contributed_definitions/NXevent_data_em_set.nxdl.xml (71%) rename base_classes/NXfit_parameter.nxdl.xml => contributed_definitions/NXfabrication.nxdl.xml (56%) rename {base_classes => contributed_definitions}/NXibeam_column.nxdl.xml (57%) create mode 100644 contributed_definitions/NXimage_set.nxdl.xml create mode 100644 contributed_definitions/NXimage_set_em_adf.nxdl.xml create mode 100644 contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml create mode 100644 contributed_definitions/NXinteraction_vol_em.nxdl.xml create mode 100644 contributed_definitions/NXion.nxdl.xml create mode 100644 contributed_definitions/NXlens_em.nxdl.xml rename {base_classes => contributed_definitions}/NXlens_opt.nxdl.xml (92%) create mode 100644 contributed_definitions/NXmanipulator.nxdl.xml create mode 100644 contributed_definitions/NXmpes.nxdl.xml create mode 100644 contributed_definitions/NXms.nxdl.xml create mode 100644 contributed_definitions/NXms_feature_set.nxdl.xml create mode 100644 contributed_definitions/NXms_score_config.nxdl.xml create mode 100644 contributed_definitions/NXms_score_results.nxdl.xml rename base_classes/NXcg_sphere_set.nxdl.xml => contributed_definitions/NXms_snapshot.nxdl.xml (54%) create mode 100644 contributed_definitions/NXms_snapshot_set.nxdl.xml create mode 100644 contributed_definitions/NXopt.nxdl.xml create mode 100644 contributed_definitions/NXoptical_system_em.nxdl.xml create mode 100644 contributed_definitions/NXorientation_set.nxdl.xml create mode 100644 contributed_definitions/NXpeak.nxdl.xml rename {base_classes => contributed_definitions}/NXpid.nxdl.xml (70%) rename {base_classes => contributed_definitions}/NXprogram.nxdl.xml (100%) create mode 100644 contributed_definitions/NXpulser_apm.nxdl.xml rename {base_classes => contributed_definitions}/NXpump.nxdl.xml (88%) create mode 100644 contributed_definitions/NXreflectron.nxdl.xml rename {base_classes => contributed_definitions}/NXregistration.nxdl.xml (100%) create mode 100644 contributed_definitions/NXscanbox_em.nxdl.xml create mode 100644 contributed_definitions/NXslip_system_set.nxdl.xml create mode 100644 contributed_definitions/NXspectrum_set.nxdl.xml create mode 100644 contributed_definitions/NXspectrum_set_em_eels.nxdl.xml create mode 100644 contributed_definitions/NXspectrum_set_em_xray.nxdl.xml rename {base_classes => contributed_definitions}/NXspindispersion.nxdl.xml (100%) create mode 100644 contributed_definitions/NXstage_lab.nxdl.xml rename {base_classes => contributed_definitions}/NXwaveplate.nxdl.xml (95%) mode change 100755 => 100644 dev_tools/docs/nxdl.py delete mode 100644 manual/source/classes/applications/apm-structure.rst delete mode 100644 manual/source/classes/applications/container/ComplexContainerBeampath.png delete mode 100644 manual/source/classes/applications/container/ComplexExampleContainer.png delete mode 100644 manual/source/classes/applications/em-structure.rst delete mode 100644 manual/source/classes/applications/mpes-structure.rst delete mode 100644 manual/source/classes/applications/optical-spectroscopy-structure.rst delete mode 100644 manual/source/classes/base_classes/apm-structure.rst delete mode 100644 manual/source/classes/base_classes/container/ComplexContainerBeampath.png delete mode 100644 manual/source/classes/base_classes/container/ComplexExampleContainer.png delete mode 100644 manual/source/classes/base_classes/em-structure.rst delete mode 100644 manual/source/classes/base_classes/mpes-structure.rst delete mode 100644 manual/source/classes/base_classes/optical-spectroscopy-structure.rst delete mode 100644 manual/source/classes/contributed_definitions/container/ComplexContainerBeampath.png delete mode 100644 manual/source/classes/contributed_definitions/container/ComplexExampleContainer.png rename manual/source/classes/contributed_definitions/{optical-spectroscopy-structure.rst => ellipsometry-structure.rst} (72%) delete mode 100644 manual/source/classes/contributed_definitions/icme-structure.rst delete mode 100644 manual/source/classes/contributed_definitions/sample-prep-structure.rst delete mode 100644 manual/source/classes/contributed_definitions/sts-structure.rst diff --git a/applications/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml deleted file mode 100644 index 37e76991e4..0000000000 --- a/applications/NXapm.nxdl.xml +++ /dev/null @@ -1,1104 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of pulses collected in between start_time and end_time resolved by an - instance of :ref:`NXevent_data_apm`. If this is not defined, p is the number of - ions included in the reconstructed volume if the application definition is used - to store results of an already reconstructed datasets. - - - - - Number of ions spatially filtered from results of the hit_finding algorithm - from which an instance of a reconstructed volume has been generated. - These ions get new identifier assigned in the process (the so-called - evaporation_identifier). This identifier must not be confused with - the pulse_identifier. - - - - - Application definition for atom probe and field ion microscopy experiments. - - - - - - - - - - - The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_ or its plugins) - which was used to generate this NeXus file instance. - - - - - A collection of all programs and libraries which are considered relevant - to understand with which software tools this NeXus file instance was - generated. Ideally, to enable a binary recreation from the input data. - - Examples include the name and version of the libraries used to write the - instance. Ideally, the software which writes these NXprogram instances - also includes the version of the set of NeXus classes i.e. the specific - set of base classes, application definitions, and contributed definitions - with which the here described concepts can be resolved. - - For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ - which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ - research data management system, it makes sense to store e.g. the GitHub - repository commit and respective submodule references used. - - - - - - - - - - - - - - - - The identifier whereby the experiment is referred to in the control software. - This is neither the specimen_name nor the experiment_identifier. For - Local Electrode Atom Probe (LEAP) instruments, it is recommended to use the - run_number from the proprietary software IVAS/APSuite of AMETEK/Cameca. - For other instruments, such as the one from Stuttgart or Oxcart from Erlangen, - or the instruments at GPM in Rouen, use the identifier which matches - best conceptually to the LEAP run number. - The field does not have to be required if the information is recoverable - in the dataset which for LEAP instruments is the case (provided these - RHIT or HITS files respectively are stored alongside a data artifact). - With NXapm the RHIT or HITS can be stored as via the NXserialized group - in the hit_finding algorithm section. - - As a destructive microscopy technique, a run can be performed only once. - It is possible, however, to interrupt a run and restart data acquisition - while still using the same specimen. In this case, each evaporation run - needs to be distinguished with different run numbers. - We follow this habit of most atom probe groups. Such interrupted runs - should be stored as individual :ref:`NXentry` instances in one NeXus file. - - - - - Either an identifier or an alias that is human-friendly so that scientists find that experiment again. - For experiments usually this is the run_number but for simulation typically no run_numbers are issued. - - - - - Free-text description about the experiment. - - Users are strongly advised to parameterize the description of their experiment - by using respective groups and fields and base classes instead of writing prose - into this field. - - The reason is that such free-text field is difficult to machine-interpret. - The motivation behind keeping this field for now is to learn in how far the - current base classes need extension based on user feedback. - - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the atom probe session started. If the exact duration of - the measurement is not relevant start_time only should be used. - - Often though it is useful to specify both start_time and end_time to - capture more detailed bookkeeping of the experiment. The user should - be aware that even with having both dates specified, it may not be - possible to infer how long the experiment took or for how long data - were collected. - - More detailed timing data over the course of the experiment have to be - collected to compute this event chain during the experiment. For this - purpose the :ref:`NXevent_data_apm` instance should be used. - - - - - ISO 8601 time code with local time zone offset to UTC included - when the atom probe session ended. - - - - - - - - - - - - - - What type of atom probe experiment is performed? This field is meant to - inform research data management systems to allow filtering: - - * apt are experiments where the analysis_chamber has no imaging gas. - experiment with LEAP instruments are typically performed such. - * fim are experiments where the analysis_chamber has an imaging gas, - which should be specified with the atmosphere in the analysis_chamber group. - * apt_fim should be used for combinations of the two imaging modes. - few experiments of this type have been performed as this can be detrimental - to LEAP systems (see `S. Katnagallu et al. <https://doi.org/10.1017/S1431927621012381>`_). - * other should be used in combination with the user specifying details - in the experiment_documentation field. - - If NXapm is used for storing details about a simulation use other for now. - - - - - - - - - - - - - - - - - - - Description of the sample from which the specimen was prepared or - site-specifically cut out using e.g. a focused-ion beam instrument. - - The sample group is currently a place for storing suggestions from - atom probers about knowledge they have gained about the sample. - There are cases where the specimen is machined further or exposed to - external stimuli during the experiment. In this case, these details should - not be stored under sample but suggestions should be made - how this application definition can be improved. - - In the future also details like how the grain_diameter was characterized, - how the sample was prepared, how the material was heat-treated etc., - should be stored. For this specific application definitions/schemas can be - used which are then arranged and documented with a description of the - workflow so that actionable graphs become instantiatable. - - - - A qualifier whether the sample is a real one - or a virtual one (in a computer simulation). - - - - - - - - - Given name/alias for the sample. - - - - - - - - - - Qualitative information about the grain size, here specifically - described as the equivalent spherical diameter of an assumed - average grain size for the crystal ensemble. - Users of this information should be aware that although the grain - diameter or radius is often referred to as grain size. - - In atom probe it is possible that the specimen may contain a few - crystals only. In this case the grain_diameter is not a reliable - descriptor. Reporting a grain size may be useful though as it allows - judging if specific features are expected to be found in the - detector hit map. - - - - - Magnitude of the standard deviation of the grain_diameter. - - - - - - The temperature of the last heat treatment step before quenching. - Knowledge about this value can give an idea how the sample - was heat treated. However, if a documentation of the annealing - treatment as a function of time is available one should better - rely on this information and have it stored alongside the NeXus file. - - - - - Magnitude of the standard deviation of the heat_treatment_temperature. - - - - - Rate of the last quenching step. Knowledge about this value can give - an idea how the sample was heat treated. However, there are many - situations where one can imagine that the scalar value for just the - quenching rate is insufficient. - - An example is when the sample was left in the furnace after the - furnace was switched off. In this case the sample cools down with - a specific rate of how this furnace cools down in the lab. - Processes which in practice are often not documented. - - This can be problematic though because when the furnace door was left open - or the ambient temperature in the lab changed, i.e. for a series of - experiments where one is conducted on a hot summer day and the next - during winter this can have an effect on the evolution of the microstructure. - There are many cases where this has been reported to be an QA issue in industry, - e.g. think about aging aluminium samples left on the factory - parking lot on a hot summer day. - - - - - Magnitude of the standard deviation of the heat_treatment_quenching_rate. - - - - - - The chemical composition of the sample. Typically, it is assumed that - this more macroscopic composition is representative for the material - so that the composition of the typically substantially less voluminous - specimen probes from the more voluminous sample. - - - - Reporting compositions as atom and weight percent yields both - dimensionless quantities but their conceptual interpretation differs. - A normalization based on atom_percent counts relative to the - total number of atoms which are of a particular type. - By contrast, weight_percent normalization factorizes in the - respective mass of the elements. Python libraries like pint are - challenged by these differences as at.-% and wt.-% are both - fractional quantities. - - - - - - - - - - Human-readable name of the element (e.g. Fe). - Name has to be a symbol of an element from the periodic table. - All symbols in the set of NXion instances inside the group - chemical_composition need to be disjoint. - - - - - Composition value for the element/ion referred to under name. - The value is normalized based on normalization, i.e. composition - is either an atom or weight percent quantity. - - - - - Magnitude of the standard deviation of the composition (value). - - - - - - - - - A qualifier whether the specimen is a real one or a virtual one. - - - - - - - - - Given name an alias. Better use identifier and parent_identifier instead. - A single NXentry should be used only for the characterization of a single specimen. - - - - - - - - - - Identifier of the sample from which the specimen was cut or the string - n/a. The purpose of this field is to support functionalities for - tracking sample provenance via a research data management system. - - - - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Ideally, this - matches the last timestamp that is mentioned in the digital resource - pointed to by parent_identifier. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments including tracers with a - short half time. Additional time stamps prior to preparation_date - should better be placed in resources which describe but which do not - pollute the description here with prose. Resolving these connected - pieces of information is considered within the responsibility of the - research data management system. - - - - - List of comma-separated elements from the periodic table that are - contained in the specimen. If the specimen substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer research data management systems an - opportunity to parse the relevant elements without having to interpret - these from the resources pointed to by parent_identifier or walk through - eventually deeply nested groups in data instances. - - - - - Discouraged free-text field. - - - - - Report if the specimen is polycrystalline, in which case it - contains a grain or phase boundary, or if the specimen is a - single crystal. - - - - - Report if the specimen is amorphous. - - - - - Ideally measured otherwise best elaborated guess of the initial radius of the - specimen. - - - - - Ideally measured otherwise best elaborated guess of the (initial) shank angle. - This is a measure of the specimen taper. Define it in such a way that the base of the specimen - is modelled as a conical frustrum so that the shank angle is the (shortest) angle between - the specimen space z-axis and a vector on the lateral surface of the cone. - - - - - - - Set to hold different coordinate systems conventions. - Inspect the description of the :ref:`NXcoordinate_system_set` - and :ref:`NXcoordinate_system` base classes how to define - coordinate systems in NeXus. Specific details for application - in atom probe microscopy follow. - - In this research field scientists usually distinguish several - Euclidean coordinate systems (CS): - - * World space; - a CS specifying a local coordinate system of the planet earth which - identifies into which direction gravity is pointing such that - the laboratory space CS can be rotated into this world CS. - * The laboratory space; - a CS specifying the room where the instrument is located in or - a physical landmark on the instrument, e.g. the direction of the - transfer rod where positive is the direction how the rod - has to be pushed during loading a specimen into the instrument. - In summary, this CS is defined by the chassis of the instrument. - * The specimen space; - a CS affixed to either the base or the initial apex of the specimen, - whose z axis points towards the detector. - * The detector space; - a CS affixed to the detector plane whose xy plane is usually in the - detector and whose z axis points towards the specimen. - This is a distorted space with respect to the reconstructed ion - positions. - * The reconstruction space; - a CS in which the reconstructed ion positions are defined. - The orientation depends on the analysis software used. - * Eventually further coordinate systems attached to the - flight path of individual ions might be defined. - - In atom probe microscopy a frequently used choice for the detector - space (CS) is discussed with the so-called detector space image - (stack). This is a stack of two-dimensional histograms of detected ions - within a predefined evaporation identifier interval. Typically, the set of - ion evaporation sequence IDs is grouped into chunks. - - For each chunk a histogram of the ion hit positions on the detector - is computed. This leaves the possibility for inconsistency between - the so-called detector space and the e.g. specimen space. - - To avoid these ambiguities, instances of :ref:`NXtransformations` should - be used. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The wavelength of the radiation emitted by the source. - - - - - - - - - The space inside the atom probe along which ions pass nominally - when they leave the specimen and travel to the detector. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A region-of-interest analyzed either during or after the session for which - specific processed data of the measured or simulated data are available. - - - - - - SEM or TEM image of the initial specimen i.e. - ideally taken prior to the data acquisition. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Integer used to name the first pulse to know if there is an - offset of the evaporation_identifier to zero. - - Identifiers can be defined either implicitly or explicitly. - For implicit indexing identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. - - Therefore, implicit identifier are completely defined by the value of - identifier_offset and cardinality. For example if identifier run from - -2 to 3 the value for identifier_offset is -2. - - For explicit indexing the field identifier has to be used. - Fortran-/Matlab- and C-/Python-style indexing have specific implicit - identifier conventions where identifier_offset is 1 and 0 respectively. - - - - - (Molecular) ion identifier which resolves the sequence in which - the ions were evaporated but taking into account that a hit_finding - and spatial_filtering was applied. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - For LEAP and IVAS/APSuite-based analyses root file which stores - the settings whereby an RHIT/HITS file can be used to regenerate the - reconstruction that is here referred to. - - The respective RHIT/HITS file should ideally be specified in the serialized - group of the hit_finding section of this application definition. - - - - - - - - - For LEAP and IVAS/APSuite-based analyses the resulting typically - file with the reconstructed positions and (calibrated) mass-to-charge - state ratio values. - - For other data collection/analysis software the data artifact which comes - closest conceptually to AMETEK/Cameca's typical file formats. - - These are typically exported as a POS, ePOS, APT, ATO, ENV, or HDF5 file, - which should be stored alongside this record in the research data - management system. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The respective ranging definitions file RNG/RRNG/ENV/HDF5. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (Out-of-sync) background levels in ppm/ns - reported by e.g. IVAS/APSuite for LEAP systems. - - - - - MRP, mass-resolving power, `D. Larson et al. - <https://doi.org/10.1007/978-1-4614-8721-0>`_ (p282, Eqs. D.7 and D.8). - - - - - MRP, at which mrp_value was specified. - - - - - - - - - - - - - - - - - Category for the peak offering a qualitative statement of the location of the peak - in light of limited mass-resolving power that is relevant for - composition quantification. See `D. Larson et al. (p172) <https://doi.org/10.1007/978-1-4614-8721-0>`_ - for examples of each category: - - * 0, well-separated, :math:`^{10}B^{+}`, :math:`^{28}Si^{2+}` - * 1, close, but can be sufficiently separated for quantification in a LEAP system, :math:`^{94}Mo^{3+}`, :math:`^{63}Cu^{2+}` - * 2, closely overlapping, demands better than LEAP4000X MRP can provide :math:`^{14}N^{+}`, :math:`^{28}Si^{2+}` at different charge states - * 3, overlapped exactly due to multi-charge molecular species, :math:`^{16}{O_{2}}^{2+}`, :math:`^{16}O^{+}` - * 4, overlapped, same charge state, cannot as of 2013 be discriminated with a LEAP4000X, :math:`^{14}{N_{2}}^{+}`, :math:`^{28}Si^{+}` - * 5, overlapped, same charge state, any expectation of resolvability, :math:`^{54}Cr^{2+}`, :math:`^{54}Fe^{2+}` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/applications/NXarpes.nxdl.xml b/applications/NXarpes.nxdl.xml index 9905347b5c..f296bb477d 100644 --- a/applications/NXarpes.nxdl.xml +++ b/applications/NXarpes.nxdl.xml @@ -30,12 +30,7 @@ This is an application definition for angular resolved photo electron spectroscopy. - It has been drawn up with hemispherical electron analysers in mind. - - This definition is a legacy support for older NXarpes experiments. - There is, however, a newer definition to collect data & metadata - for general photoemission experiments, called :ref:`NXmpes`, - as well as a specialization for ARPES experiments, called :ref:`NXmpes_arpes`." + It has been drawn up with hemispherical electron analysers in mind. @@ -136,4 +131,4 @@ - \ No newline at end of file + diff --git a/applications/NXellipsometry.nxdl.xml b/applications/NXellipsometry.nxdl.xml deleted file mode 100644 index 5769036aff..0000000000 --- a/applications/NXellipsometry.nxdl.xml +++ /dev/null @@ -1,422 +0,0 @@ - - - - - - - - Variables used throughout the document, e.g. dimensions or parameters. - - - - Length of the spectrum array (e.g. wavelength or energy) of the measured - data. - - - - - Number of measurements (1st dimension of measured_data array). This is - equal to the number of parameters scanned. For example, if the experiment - was performed at three different temperatures and two different pressures - N_measurements = 2*3 = 6. - - - - - Number of detection angles of the beam reflected or scattered off the - sample. - - - - - Number of angles of incidence of the incident beam. - - - - - This is the application definition describing ellipsometry experiments. - - Such experiments may be as simple as identifying how a reflected - beam of light with a single wavelength changes its polarization state, - to a variable angle spectroscopic ellipsometry experiment. - - The application definition specifies optical spectroscopy (NXopt), by extending - the terms and setting specific requirements. - - Information on ellipsometry is provided, e.g. in: - - * H. Fujiwara, Spectroscopic ellipsometry: principles and applications, - John Wiley & Sons, 2007. - * R. M. A. Azzam and N. M. Bashara, Ellipsometry and Polarized Light, - North-Holland Publishing Company, 1977. - * H. G. Tompkins and E. A. Irene, Handbook of Ellipsometry, - William Andrew, 2005. - - Open access sources: - - * https://www.angstromadvanced.com/resource.asp - * https://pypolar.readthedocs.io/en/latest/ - - Review articles: - - * T. E. Jenkins, "Multiple-angle-of-incidence ellipsometry", - J. Phys. D: Appl. Phys. 32, R45 (1999), - https://doi.org/10.1088/0022-3727/32/9/201 - * D. E. Aspnes, "Spectroscopic ellipsometry - Past, present, and future", - Thin Solid Films 571, 334-344 (2014), - https://doi.org/10.1016/j.tsf.2014.03.056 - * R. M. A. Azzam, "Mueller-matrix ellipsometry: a review", - Proc. SPIE 3121, Polarization: Measurement, Analysis, and Remote Sensing, - (3 October 1997), - https://doi.org/10.1117/12.283870 - * E. A. Irene, "Applications of spectroscopic ellipsometry to microelectronics", - Thin Solid Films 233, 96-111 (1993), - https://doi.org/10.1016/0040-6090(93)90069-2 - * S. Zollner et al., "Spectroscopic ellipsometry from 10 to 700 K", - Adv. Opt. Techn., (2022), - https://doi.org/10.1515/aot-2022-0016 - - - - - An application definition for ellipsometry. - - - - Version number to identify which definition of this application - definition was used for this entry/data. - - - - - URL where to find further material (documentation, examples) relevant - to the application definition. - - - - - - - - - - Specify the type of the optical experiment. - - You may specify fundamental characteristics or properties in the experimental sub-type. - - - - - - - - Specify the type of ellipsometry. - - - - - - - - - - - - - - If the ellipsometry_experiment_type is `other`, a name should be specified here. - - - - - Properties of the ellipsometry equipment. - - - - What type of ellipsometry was used? See Fujiwara Table 4.2. - - - - - - - - - - - - - - - - - - - - If the ellipsometer_type is `other`, a specific ellipsometry_type" should be - added here. - - - - - Define which element rotates, e.g. polarizer or analyzer. - - - - - - - - - - - If focussing probes (lenses) were used, please state if the data - were corrected for the window effects. - - - - - - - - - - - - - - Were the recorded data corrected by the window effects of the - focussing probes (lenses)? - - - - - Specify the angular spread caused by the focussing probes. - - - - - - Properties of the rotating element defined in - 'instrument/rotating_element_type'. - - - - Define how many revolutions of the rotating element were averaged - for each measurement. If the number of revolutions was fixed to a - certain value use the field 'fixed_revolutions' instead. - - - - - Define how many revolutions of the rotating element were taken - into account for each measurement (if number of revolutions was - fixed to a certain value, i.e. not averaged). - - - - - Specify the maximum value of revolutions of the rotating element - for each measurement. - - - - - - - - Was the backside of the sample roughened? Relevant for infrared - ellipsometry. - - - - - - - Measured data, data errors, and varied parameters. This may be used to describe - indirectly derived data or data transformed between different descriptions, - such as: - Raw Data --> Psi - Delta Psi, Delta --> N,C,S - Mueller matrix --> N,C,S - Mueller matrix --> Psi, Delta - etc. - - Other types of data, such as temperature or sample location, may be saved - in a generic (NXdata) concept from NXopt, or better directly in the - location of the sample positioner or temperature sensor. - - - - An identifier to correlate data to the experimental conditions, - if several were used in this measurement; typically an index of 0-N. - - - - - Select which type of data was recorded, for example intensity, - reflectivity, transmittance, Psi and Delta etc. - It is possible to have multiple selections. The enumeration list - depends on the type of experiment and may differ for different - application definitions. - - - - - - - - - - - - - - - - Spectral values (e.g. wavelength or energy) used for the measurement. - An array of 1 or more elements. Length defines N_spectrum. Replace - 'SPECTRUM' by the physical quantity that is used, e.g. wavelength. - - - - - - - If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. - If the unit of the measured data is not covered by NXDL units state - here which unit was used. - - - - - - Resulting data from the measurement, described by 'data_type'. - - The first dimension is defined by the number of measurements taken, - (N_measurements). The instructions on how to order the values - contained in the parameter vectors given in the doc string of - INSTRUMENT/sample_stage/environment_conditions/PARAMETER/values, - define the N_measurements parameter sets. For example, if the - experiment was performed at three different temperatures - (T1, T2, T3), two different pressures (p1, p2) and two different - angles of incidence (a1, a2), the first measurement was taken at the - parameters {a1,p1,T1}, the second measurement at {a1,p1,T2} etc. - - - - - - - - - If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. - If the unit of the measured data is not covered by NXDL units state - here which unit was used. - - - - - - Specified uncertainties (errors) of the data described by 'data_type' - and provided in 'measured_data'. - - - - - - - - - If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. - If the unit of the measured data is not covered by NXDL units state - here which unit was used. - - - - - - List of links to the values of the sensors. Add a link for each - varied parameter (i.e. for each sensor). - - - - - - - - Link to the NeXus file which describes the reference data if a - reference measurement was performed. Ideally, the reference - measurement was performed using the same conditions as the actual - measurement and should be as close in time to the actual measurement - as possible. - - - - - - Commercial or otherwise defined given name of the program that was - used to generate the result file(s) with measured data and/or - metadata (in most cases, this is the same as INSTRUMENT/software). - If home written, one can provide the actual steps in the NOTE - subfield here. - - - - - Either version with build number, commit hash, or description of a - (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner. - - - - - Website of the software. - - - - - - diff --git a/applications/NXem.nxdl.xml b/applications/NXem.nxdl.xml deleted file mode 100644 index 9ab06b6ba0..0000000000 --- a/applications/NXem.nxdl.xml +++ /dev/null @@ -1,1663 +0,0 @@ - - - - - - Application definition for normalized representation of electron microscopy research. - - This application definition is a comprehensive example for a general description - with which to normalize specific pieces of information and data collected within - electron microscopy research. - - NXem is designed to be used for documenting experiments or computer simulations in which - controlled electron beams are used for studying electron-beam matter interaction to explore - physical mechanisms and phenomena, or to characterize materials with an electron microscope. - - - - - - - - - - - - The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_ or its plugins) - which was used to generate this NeXus file instance. - - - - A collection of all programs and libraries that are considered as relevant - to understand with which software tools this NeXus file instance was - generated. Ideally, to enable a binary recreation from the input data. - - Examples include the name and version of the libraries used to write the - instance. Ideally, the software which writes these NXprogram instances - also includes the version of the set of NeXus classes i.e. the specific - set of base classes, application definitions, and contributed definitions - with which the here described concepts can be resolved. - - For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ - which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ - research data management system, it makes sense to store e.g. the GitHub - repository commit and respective submodule references used. - - - - - - - - - Ideally, a (globally) unique persistent identifier for referring to this experiment. - - An experiment should be understood in that this can be an experiment - in reality or a computer simulation because also the latter is an experiment - (see the Cambridge Dictionary experiment *a test done in order to find out - something, eg if an idea is correct*). - - The identifier is usually issued by the facility, laboratory, or the principle investigator. - The identifier enables to link experiments/simulations to e.g. proposals. - - - - - - - - Alias which scientists can easier identify this experiment by. - - - - - Free-text description about the experiment. - - Users are strongly advised to parameterize the description of their experiment - by using respective groups and fields and base classes instead of writing prose - into the field. The reason is that such free-text field is difficult to machine-interpret. - The motivation behind keeping this field for now is to learn in how far the - current base classes need extension based on user feedback. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant use this start_time field. - - Often though it is useful to specify a time interval via setting both a start_time - and an end_time because this enables software tools and users to collect a - more detailed bookkeeping of the experiment. - - Users should be aware though that even with having both time instances - specified, it may not be possible to infer how long the experiment took or - for how long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps start_time and end_time - in :ref:`NXevent_data_em` instances. - - - - - ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. - - See docstring of the start_time field to see how to use the - start_time and end_time together. - - - - - - Possibility to store a collection of serialized resources associated with the - experiment. - - An example how to use this set could be to document from which files, which have been - e.g. generated by software of technology partners, the information in an instance of - NXem was filled with during parsing or transcoding between different formats. - - - - - - - - - - Information about persons who performed or were involved in the microscope - session or simulation run. - - This can be the principle investigator who performed this experiment or the student who performed simulations. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname. - - - - - Name of the affiliation at the point in time when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address at the point in time when the experiment was performed. - - Writing the most permanently used email is recommended. - - - - - Telephone number at the point in time when the experiment was performed. - - - - - User role at the point in time when the experiment was performed. - - Examples are technician operating the microscope, student, postdoc, - principle investigator, or guest. - - - - - Identifier offered by a service to report the user other than by using its name. - - Examples could be an ORCID or social media account of the user. - - - - - - - - - A physical entity which contains material intended to be investigated. - Sample and specimen are treated as de facto synonyms. Samples can be real or virtual ones. - - This concept is related to term `Specimen`_ of the EMglossary standard. - - .. _Specimen: https://purls.helmholtz-metadaten.de/emg/EMG_00000046 - - - - Qualifier whether the sample is a real or a virtual one. - - - - - - - - - Ideally, (globally) unique persistent identifier which distinguishes the sample from all others - and especially the predecessor/origin from where that sample was cut. The terms sample - and specimen are here considered as exact synonyms. - - This field must not be used for an alias! Instead, use name. - - In cases where multiple specimens were loaded into the microscope, the identifier has to resolve - the specific sample, whose results are stored by this :ref:`NXentry` instance because a single - NXentry should be used for the characterization of a single specimen. - - Details about the specimen preparation should be stored in resources referring to parent_identifier. - - - - - - - - Identifier of the sample from which the sample was cut or the string *None*. - - The purpose of this field is to support functionalities for tracking - sample provenance in a research data management system. - - - - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known timestamp when - the measured specimen surface was actively prepared. Ideally, this matches - the last timestamp that is mentioned in the digital resource pointed to by - parent_identifier. - - Knowing when the specimen was exposed to e.g. specific atmosphere is especially - required for environmentally sensitive material such as specimen charged with hydrogen - or experiments including tracers that have a short halflife. Additional time stamps - prior to preparation_date should better be placed in resources which describe but - which do not pollute the description here with prose. Resolving these connected - pieces of information is considered the responsibility of the - research data management system not of a NeXus file. - - - - - An alias used to refer to the specimen to please readability for humans. - - - - - List of comma-separated elements from the periodic table that are contained in the sample. - If the sample substance has multiple components, all elements from each component - must be included in atom_types. - - The purpose of the field is to offer research data management systems an opportunity - to parse the relevant elements without having to interpret these from the resources - pointed to by parent_identifier or walk through eventually deeply nested groups in - individual data instances. - - - - - (Measured) sample thickness. - - The information is recorded to qualify if the beam used was likely - able to shine through the specimen. For scanning electron microscopy, - in many cases the specimen is typically thicker than what is - illuminatable by the electron beam. - - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - - - - - - (Measured) density of the specimen. - - For multi-layered specimens this field should only be used to describe - the density of the excited volume. For scanning electron microscopy - the usage of this field is discouraged and instead an instance of an - :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` - instances can provide a cleaner description of the relevant details - why one may wish to store the density of the specimen. - - - - - Discouraged free-text field to provide further detail although adding - parent_identifier and having a working research data management system - should provide this contextualization. - - - - - - Set to hold different coordinate systems conventions. - - Inspect the description of the :ref:`NXcoordinate_system_set` and :ref:`NXcoordinate_system` base classes - how to define coordinate systems in NeXus. - - - - - - - - - - - - - - Location of the origin of the processing_reference_frame. - - It is assumed that regions-of-interest in this reference frame form a rectangle or cuboid. - Edges are interpreted by inspecting the direction of their outer unit normals - (which point either parallel or antiparallel) along respective base vector direction - of the reference frame. - - If any of these assumptions is not met, the user is required to explicitly state this. - - - - - - - - - - - - - - - - Direction of the positively pointing x-axis base vector of the - processing_reference_frame. - - - - - - - - - - - - - - Direction of the positively pointing y-axis base vector of the - processing_reference_frame. - - - - - - - - - - - - - - Direction of the positively pointing z-axis base vector of the - processing_reference_frame. - - - - - - - - - - - - - - - - Reference to the specifically named :ref:`NXsample` instance(s) for - which these conventions apply (e.g. /entry1/sample1). - - - - - - - - Location of the origin of the sample_reference_frame. - - It is assumed that regions-of-interest in this reference frame form a rectangle or cuboid. - Edges are interpreted by inspecting the direction of their outer unit normals - (which point either parallel or antiparallel) along respective base vector direction - of the reference frame. - - If any of these assumptions is not met, the user is required to explicitly state this. - - - - - - - - - - - - - - - - Direction of the positively pointing x-axis base vector of the - sample_reference_frame. - - - - - - - - - - - - - - Direction of the positively pointing y-axis base vector of the - sample_reference_frame. - - - - - - - - - - - - - - Direction of the positively pointing z-axis base vector of the - sample_reference_frame. - - - - - - - - - - - - - - - - Reference to the specifically named :ref:`NXdetector` instance for - which these conventions apply (e.g. /entry1/instrument/detector1). - - - - - - - - Location of the origin of the detector_reference_frame. - - If the regions-of-interest forms a rectangle or cuboid, it is assumed that edges are interpreted - by inspecting the direction of their outer unit normals (which point either parallel or antiparallel) - along respective base vector direction of the reference frame. - - If any of these assumptions is not met, the user is required to explicitly state this. - - - - - - - - - - - - - - - - Direction of the positively pointing x-axis base vector of the - detector_reference_frame. - - - - - - - - - - - - - - Direction of the positively pointing y-axis base vector of the - detector_reference_frame. - - - - - - - - - - - - - - Direction of the positively pointing z-axis base vector of the - detector_reference_frame. - - - - - - - - - - - - - - - - - - - - - - - - - - Details about the control program used for operating the microscope. - - - - - - - - - - - - - - - This concept is related to term `Source`_ of the EMglossary standard. - - .. _Source: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 - - - - - - - - - - - - - - - - - - - - - - - - - - - - Device for improving energy resolution or reducing chromatic aberration. - - Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector - like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ - - - - - Qualitative type of the component. - - - - - - - - - - - - - - - - - - - - - - - - - - - Device reshaping an ellipse-shaped electron beam to a circular one. - - * `L. Reimer 1998, Springer, 1998 <https://dx.doi.org/10.1007/978-3-540-3896>`_ - * `M. Tanaka et al., Electron Microscopy Glossary, 2024 <https://www.jeol.com/words/semterms/20201020.111014.php#gsc.tab=0>`_ - - Stigmator is an exact synonym. - - - - - - - - - - Electron biprism as it is used e.g. for electron holography. - - - - - - - - - - - Device that causes a change in the phase of an electron wave. - - * `M. Malac et al. <https://doi.org/10.1093/jmicro/dfaa070>`_ - * `R. R. Schröder et al. <https://www.lem.kit.edu/152.php>`_ - - - - Qualitative type - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Device for improving energy resolution or reducing chromatic aberration. - - Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector - like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ - - - - Qualitative type of the component. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This concept is related to term `Source`_ of the EMglossary standard. - - .. _Source: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 - - - - The potential difference between anode and cathode. - - This concept is related to term `Acceleration Voltage`_ of the EMglossary standard. - - .. _Acceleration Voltage: https://purls.helmholtz-metadaten.de/emg/EMG_00000004 - - - - - Voltage which is utilised to create an electric field that draws particles from - the source. - - This concept is related to term `Extraction Voltage`_ of the EMglossary standard. - - .. _Extraction Voltage: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 - - - - - Electrical current which is released from the source. - - This concept is related to term `Emission Current`_ of the EMglossary standard. - - .. _Emission Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 - - - - - Electrical current which flows through the source. - - This concept is related to term `Filament Current`_ of the EMglossary standard. - - .. _Filament Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000027 - - - - - - - - - - Relevant value from the control software. - - This is not always just the diameter of the aperture (not even in the case) - of a circular aperture. Usually, it is a value that is set in the control - software whereby a specific configuration of an aperture is selected by the - software. - - The control software of commercial microscope typically offers the user - access at a high abstraction level because of which many details about - the actual settings of the electrical components are typically unknown. - - However, if more details are known or should be documented one should - use the description field for this. - - - - - - Device to improve energy resolution or chromatic aberration. - - Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector - like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ - - - - - Was the corrector used? - - - - - - Energy dispersion in e.g. µm/eV. - - - - - Corresponding voltage for that energy dispersion. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Device reshaping an ellipse-shaped electron beam to a circular one. - - * `L. Reimer 1998, Springer, 1998 <https://dx.doi.org/10.1007/978-3-540-3896>`_ - * `M. Tanaka et al., Electron Microscopy Glossary, 2024 <https://www.jeol.com/words/semterms/20201020.111014.php#gsc.tab=0>`_ - - Stigmator is an exact synonym. - - - - Was the corrector used? - - - - - Descriptor for the correction strength along the first direction when exact technical details - are unknown or not directly controllable as the control software of the microscope does not - enable or was not configured to display these values (for end users). - - - - - Descriptor for the correction strength along the second direction when exact technical details - are unknown or not directly controllable as the control software of the microscope does not - enable or was not configured to display these values (for end users). - - - - - - - - - - This concept is related to term `Electron Beam`_ of the EMglossary standard. - - .. _Electron Beam: https://purls.helmholtz-metadaten.de/emg/EMG_00000021 - - - - - - - - - - - - - - - Relevant value from the control software. - - This is not always just the diameter of the aperture (not even in the case) - of a circular aperture. Usually, it is a value that is set in the control - software whereby a specific configuration of an aperture is selected by the - software. - - The control software of commercial microscope typically offers the user - access at a high abstraction level because of which many details about - the actual settings of the electrical components are typically unknown. - - However, if more details are known or should be documented one should - use the description field for this. - - - - - - - - - - - - - - - - - - - - - - - Nominal current of the heater. - - - - - Nominal voltage of the heater. - - - - - Nominal power of the heater. - - - - - - - - - - - - - - - - - - A region-of-interest analyzed either during or after the session - for which specific processed data are available. - - This concept is related to term `Region Of Interest`_ of the EMglossary standard. - - .. _Region Of Interest: https://purls.helmholtz-metadaten.de/emg/EMG_00000042 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/applications/NXmpes.nxdl.xml b/applications/NXmpes.nxdl.xml deleted file mode 100644 index d2d60e2ea6..0000000000 --- a/applications/NXmpes.nxdl.xml +++ /dev/null @@ -1,918 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of data points in the transmission function. - - - - - This is the most general application definition for - photoemission experiments. - - Groups and fields are named according to the - `ISO 18115-1:2023`_ specification as well as the `IUPAC Recommendations 2020`_. - - .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html - .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 - - - - - - - - - - - - Datetime of the start of the measurement. - Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, - otherwise the local time zone is assumed per ISO8601. - - - - - Datetime of the end of the measurement. - Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, - otherwise the local time zone is assumed per ISO8601. - - - - - Name of the experimental method. - - If applicable, this name should match the terms given by `Clause 11`_ of - the `ISO 18115-1:2023`_ specification. - - Examples include: - * X-ray photoelectron spectroscopy (XPS) - * angle-resolved X-ray photoelectron spectroscopy (ARXPS) - * ultraviolet photoelectron spectroscopy (UPS) - * angle-resolved photoelectron spectroscopy (ARPES) - * hard X-ray photoemission spectroscopy (HAXPES) - * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) - * photoelectron emission microscopy (PEEM) - * electron spectroscopy for chemical analysis (ESCA) - * time-resolved angle-resolved X-ray photoelectron spectroscopy (trARPES) - * spin-resolved angle-resolved X-ray photoelectron spectroscopy (spin-ARPES) - * momentum microscopy - - .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html - .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 - - - - - Description of one or more coordinate systems that are specific to the setup - and the measurement geometry. - - - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the time when the experiment was - performed. - - - - - - Description of the photoemission spectrometer and its individual parts. - - This concept is related to term `12.58`_ of the ISO 18115-1:2023 standard. - - .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 - - - - Overall energy resolution of the photoemission instrument. - - - - - - - - - - Minimum distinguishable energy separation in the energy spectra. - - This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. - - .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 - - - - - Ratio of the energy resolution of the photoemission spectrometer at a specified energy - value to that energy value. - - This concept is related to term `10.7 ff.`_ of the ISO 18115-1:2023 standard. - - .. _10.7 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 - - - - - - - - - - - A source used to generate a beam. Properties refer strictly to parameters of the - source, not of the output beam. For example, the energy of the source is not the - optical power of the beam, but the energy of the electron beam in a synchrotron - or similar. - - Note that the uppercase notation in sourceTYPE means that multiple sources can - be provided. The uppercase part can be substituted with any string that consists - of alphanumeric characters, including both uppercase and lowercase letters from A to Z - and numerical digits from 0 to 9. For example, in pump-probe experiments, it is possible - to have both a `source_probe` and a `source_pump`. - - - - - - - - - - - - - - - - - - - - Specification of type, may also go to name. - - - - - - - - - - - - A reference to a beam emitted by this source. - Should be named with the same appendix, e.g., - for `source_probe` it should refer to `beam_probe`. - - Example: - * /entry/instrument/source_probe = /entry/instrument/beam_probe - - - - - - Properties of the photon beam at a given location. - Should be named with the same appendix as sourceTYPE, e.g., - for `source_probe` it should refer to `beam_probe`. - - - - Distance between the point where the current NXbeam instance is evaluating - the beam properties and the point where the beam interacts with the sample. - For photoemission, the latter is the point where the the centre of the beam - touches the sample surface. - - - - - - - - - The source that emitted this beam. - Should be named with the same appendix, e.g., - for `beam_probe` it should refer to `source_probe`. - This should be specified if an associated source exists. - - Example: - * /entry/instrument/beam_probe = /entry/instrument/source_probe - - - - - - - - - - - - - - - - - - - - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - Size, position and shape of the iris inserted in the column. - - The iris is an aperture in the lens with a variable diameter which can reduce the number of - electrons entering the analyzer. - - To add additional or other slits use the APERTURE group of NXcollectioncolumn. - - - - - - - - - - - - - - - - - - - - - - Either `pass_energy` or `drift_energy` must be supplied. `pass_energy` should be used when working - with hemispherical analysers. - - - - - Either `pass_energy` or `drift_energy` must be supplied. `drift_energy` should be used if a TOF is used in the - energy dispersive part of the electron analyzer. - - - - - - Size, position and shape of the entrance slit in dispersive analyzers. - - To add additional or other slits use the APERTURE group of NXenergydispersion. - - - - - Size, position and shape of the exit slit in dispersive analyzers. - - To add additional or other slits use the APERTURE group of NXenergydispersion. - - - - - - - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - - Contains the raw data collected by the detector before calibration. - The data which is considered raw might change from experiment to experiment - due to hardware pre-processing of the data. - This group ideally collects the data with the lowest level of processing - possible. - - Fields should be named according to the following convention: - - - **pixel_x**: Detector pixel in x direction. - - **pixel_y**: Detector pixel in y direction. - - **energy**: (Un)calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). - - **kx**: (Un)calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). - - **ky**: (Un)calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). - - **kz**: (Un)calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). - - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). - Unit category: NX_ANGLE - - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - Unit category: NX_ANGLE - - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) - Unit category: NX_LENGTH - - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - Unit category: NX_LENGTH - - **delay**: Calibrated delay time. Unit category: NX_TIME (s). - - **polarization_angle**: Linear polarization angle of the incoming or - outgoing beam. - Unit category: NX_ANGLE (° or rad) - - **ellipticity**: Ellipticity of the incoming or outgoing beam. - Unit category: NX_ANGLE (° or rad) - - **time_of_flight**: Total time of flight. Unit category: NX_TIME_OF_FLIGHT - - **time_of_flight_adc**: Time-of-flight values, analog-to-digital converted. - - **external_AXIS**: Describes an axis which is coming from outside the detectors scope. - - Note that this list is a glossary with explicitly named axis names, which is only intended to cover the most - common measurement axes and is therefore not complete. It is possible to add axes with other names at any time. - - - - - - - - - Raw data before calibration. - - - - - - - - Manipulator for positioning of the sample. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Device to measure the gas pressure in the instrument. - - - - - - - - - - - In case of a single or averaged gas pressure measurement, this is the scalar gas pressure. - It can also be an 1D array of measured pressures (without time stamps). - - - - - - In the case of an experiment in which the gas pressure changes and is recorded, - this is an array of length m of gas pressures. - - - - - - - Device to bring low-energy electrons to the sample for charge neutralization - - - - - - - - - - - In case of a fixed or averaged electron current, this is the scalar current. - It can also be an 1D array of output current (without time stamps). - - - - - - In the case of an experiment in which the electron current is changed and - recorded with time stamps, this is an array of length m of current setpoints. - - - - - - - A set of activities that occurred to the instrument prior to/during the photoemission - experiment, including any activities performed on the individual instrument parts. - This group can be used to describe the preparation of the instrument prior to the - experiment, e.g. the cleaning procedure for a spin filter crystal. - - - - - - Document an event of data processing, reconstruction, or analysis for this data. - The appropriate axis calibrations for a given experiment should be described using - one or more of the following NXcalibrations. The individual calibrations for a given - `AXISNAME` in `data` should be called `AXISNAME_calibration`. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Kinetic energy values - - - - - - - - Relative transmission efficiency for the given kinetic energies - - - - - - - - - - - - - - For samples containing a single pure substance. For mixtures use the - NXsample_component_set and NXsample_component group in NXsample instead. - - - - The chemical formula of the sample (using CIF conventions). - - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - - - - - - - - - - - - - A set of activities that occurred to the sample prior to/during photoemission - experiment. - - - - Details about the sample preparation for the photoemission experiment (e.g. UHV cleaving, - in-situ growth, sputtering/annealing, etc.). - - - - - - Details about the method of sample preparation before the photoemission - experiment. - - - - - - - Sample temperature (either controlled or just measured) and actuators/sensors - controlling/measuring it. - - - - Temperature sensor measuring the sample temperature. - - In most cases, this can be a link to /entry/instrument/manipulator/temperature_sensor - if a manipulator is present in the instrument. - - - - - Device to heat the sample. - - In most cases, this can be a link to /entry/instrument/manipulator/sample_heater - if a manipulator is present in the instrument. - - - - - Cryostat for cooling the sample. - - In most cases, this can be a link to /entry/instrument/manipulator/cryostat - if a manipulator is present in the instrument. - - - - - This is to be used if there is no actuator/sensor that controls/measures - the temperature. - - An example would be a room temperature experiment where the temperature is - not actively measured, but rather estimated. - - Note that this method for recording the temperature is not advised, but using - NXsensor and NXactuator is strongly recommended instead. - - - - - - Gas pressure surrounding the sample and actuators/sensors controlling/measuring - it. - - - - Gauge measuring the gas pressure. - - In most cases, this can be a link to /entry/instrument/pressure_gauge or to another - NXsensor measuring gas pressure (typically, the gauge in closest proximity to the - sample) if such a pressure gauge is present in the instrument. - - - - - This is to be used if there is no actuator/sensor that controls/measures - the gas pressure around the sample. An example would be a UHV experiment where the - gas pressure is not monitored. - - Note that this method for recording the gas pressure is not advised, but using - NXsensor and NXactuator is strongly recommended instead. - - - - - - Bias of the sample with respect to analyser ground and actuators/sensors - controlling/measuring it. - - This concept is related to term `8.41`_ of the ISO 18115-1:2023 standard. - - .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 - - - - Sensor measuring the applied voltage. - - In most cases, this can be a link to /entry/instrument/manipulator/sample_bias_voltmeter - if a manipulator is present in the instrument. - - - - - Actuator applying a voltage to sample and sample holder. - - In most cases, this can be a link to /entry/instrument/manipulator/sample_bias_potentiostat - if a manipulator is present in the instrument. - - - - - This is to be used if there is no actuator/sensor that controls/measures - the bias. - - Note that this method for recording the bias is not advised, but using - NXsensor and NXactuator is strongly recommended instead. - - - - - - Drain current of the sample and sample holder. - - - - Amperemeter measuring the drain current of the sample and sample holder. - - In most cases, this can be a link to /entry/instrument/manipulator/drain_current_amperemeter - if a manipulator is present in the instrument. - - - - - This is to be used if there is no actuator/sensor that controls/measures - the drain current. - - Note that this method for recording the drain current is not advised, but using - NXsensor and NXactuator is strongly recommended instead. - - - - - - Current of low-energy electrons to the sample (for charge neutralization) and - actuators/sensors controlling/measuring it. - - - - Flood gun creating a current of low-energy electrons. - - In most cases this can be a link to /entry/instrument/flood_gun - if a flood_gun is present in the instrument. - - - - This is to be used if there is no actuator/sensor that controls/measures - the drain_current. - - Note that this method for recording the flood gun current is not advised, but using - NXsensor and NXactuator is strongly recommended instead. - - - - - - - - The default NXdata group containing a view on the measured data. - This NXdata group contains a collection of the main relevant fields (axes). - If you want to provide additional views on your data, you can additionally use - the generic NXdata group of NXentry. - - In NXmpes, it is recommended to provide an energy axis. - - Fields should be named according to the following convention: - - - **energy**: Calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). - - **kx**: Calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). - - **ky**: Calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). - - **kz**: Calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). - - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). - Unit category: NX_ANGLE - - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - Unit category: NX_ANGLE - - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) - Unit category: NX_LENGTH - - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - Unit category: NX_LENGTH - - **delay**: Calibrated delay time. Unit category: NX_TIME (s). - - **polarization_angle**: Linear polarization angle of the incoming or - outgoing beam. This could be a link to - /entry/instrument/beam/incident_polarization_angle or - /entry/instrument/beam/final_polarization_angle if they exist. - Unit category: NX_ANGLE (° or rad) - - **ellipticity**: Ellipticity of the incoming or outgoing beam. - Could be a link to /entry/instrument/beam/incident_ellipticity or - /entry/instrument/beam/final_ellipticity if they exist. - Unit category: NX_ANGLE (° or rad) - - Note that this list is a glossary with explicitly named axis names, which is only intended to cover the most - common measurement axes and is therefore not complete. It is possible to add axes with other names at any time. - - - - - - - - - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, momentum, spatial coordinate, pump-probe - delay, spin index, temperature, etc. The axes traces should be linked to the - actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - Calibrated energy axis. - - Could be linked from the respective '@reference' field. - - - - The energy can be either stored as kinetic or as binding energy. - - - - - Calibrated kinetic energy axis. - - In case the kinetic energy axis is referenced to the Fermi level :math:`E_F` - (e.g., in entry/process/energy_referencing), kinetic energies :math:`E` are - provided as :math:`E-E_F`. - - This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. - - .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 - - - - - Calibrated binding energy axis. - - This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. - - .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - - - - - - - The energy can be dispersed according to different strategies. ``@reference`` points to - the path of a field defining the calibrated axis which the ``energy`` axis refers. - - For example: - @reference: 'entry/process/energy_calibration/calibrated_axis' - - - - - - - diff --git a/applications/NXmpes_arpes.nxdl.xml b/applications/NXmpes_arpes.nxdl.xml deleted file mode 100644 index d18d0056c6..0000000000 --- a/applications/NXmpes_arpes.nxdl.xml +++ /dev/null @@ -1,417 +0,0 @@ - - - - - - - This is an general application definition for angle-resolved multidimensional - photoelectron spectroscopy. - - - - - - - - - - - - - Link to transformations defining an APRES base coordinate system, - which is defined such that the positive z-axis points towards the analyzer entry, - and the x-axis lies within the beam/analyzer plane. - - - - - Set of transformations, describing the orientation of the ARPES coordinate system - with respect to the beam coordinate system (.). - - - - - - - - Overall angular resolution along the Nth angular axis. Create one such entry per relevant angular axis, - corresponding to the angular axes in NXdata. - For hemispherical analyzers, angular0_resolution corresponds to the direction along the analyzer slit, - and angular1_resolution to the one perpendicular to it. - - - - - - - - - - - - - Analyzer angular resolution along the Nth angular axis. - Create one such entry per relevant angular axis, corresponding to the angular axes in NXdata. - For hemispherical analyzers, angular0_resolution corresponds to the direction along the analyzer slit, - and angular1_resolution to the one perpendicular to it. - - - - - - - - - - - - Reference to the last transformation describing the orientation of the analyzer relative to the beam, - e.g. transformations/analyzer_elevation. - - - - - Set of transformations, describing the relative orientation of the analyzer - with respect to the beam coordinate system (.). - - - - Rotation about the analyzer lens axis. - Its zero reference is defined such that the angular0 axis is - increasing towards the positive y axis (analyzer slit vertical). - - - - - - - - - - - - - - Path to a transformation that places the analyzer origin system into the - arpes_geometry coordinate system. - - - - - - Elevation of the effective analyzer acceptance area, e.g. realized by - deflectors, or as one angle in a TOF detector. If a resolved angle, place the - calibrated axis coordinates here. - - - - - - - - - - - - - - - - - - - - In-plane analyzer coordinate along a dispersive direction, - e.g. along an analyzer slit. If a resolved angle, place the calibrated coordinates here. - - - - - - - - - - - - - - - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Reference to the end of the transformation chain, - orienting the sample surface within the arpes_geometry coordinate system - (sample_azimuth or anything depending on it). - - - - - Set of transformations, describing the relative orientation of the sample - with respect to the arpes_geometry coordinate system. - - - - Rotation about the y axis (typically the long manipulator axis). - - - - - - - - - - - - - - Path to a transformation that places the sample surface - into the origin of the arpes_geometry coordinate system. - - - - - - Offset of polar rotation. - - - - - - - - - - - - - - - - - - - - Rotation about the x axis (typically a manipulator tilt). - - - - - - - - - - - - - - - - - - - - Offset of tilt rotation. - - - - - - - - - - - - - - - - - - - - Rotation about the z axis (azimuthal rotation within the sample plane). - - - - - - - - - - - - - - - - - - - - Offset of azimuthal rotation. - - - - - - - - - - - - - - - - - - - - - - - There is an object named data that contains the signal. - - - - - - - - There are three dimensions, one energy and two angular coordinates. Any coordinates that do not move, - are represented by one point. - - - - - - - - - - - Trace of the energy axis. Could be linked from the respective ``@reference`` - field. - - - - Points to the path of a field defining the calibrated axis which the energy axis refers. - - For example: - @reference: '/entry/instrument/detector/sensor_y' for a 2D detector - @reference: '/entry/instrument/energydispersion/center_kinetic_energy' for a swept scan - @reference: '/entry/process/calibration/energy_calibration/calibrated_axis' for a preprocessed axis. - - - - - - Trace of the first angular axis. Could be linked from the respective - ``@reference`` field. - - - - Points to the path of a field defining the calibrated axis which the ``angular0`` axis refers. - - For example: - @reference: '/entry/sample/transformations/sample_tilt' for a manipulator angular scan - @reference: '/entry/instrument/detector/sensor_x' for a 2D detector - @reference: '/entry/instrument/collectioncolumn/deflector' for a deflector scan - @reference: '/entry/process/calibration/angular0_calibration/calibrated_axis' for a preprocessed axis. - - - - - - Trace of the second axis. Could be linked from the respective ``@reference`` - field. - - - - Points to the path of a field defining the calibrated axis which the ``angular1`` axis refers. - - For example: - @reference: '/entry/sample/transformations/sample_polar' for a manipulator angular scan - @reference: '/entry/instrument/detector/sensor_y' for a 2D detector - @reference: '/entry/instrument/collectioncolumn/deflector' for a deflector scan - @reference: '/entry/process/calibration/angular1_calibration/calibrated_axis' for a preprocessed axis. - - - - - - Represents a measure of three-dimensional photoemission counts, where - the varied axes are energy, and one or more angular coordinates. Axes traces - should be linked to the actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - diff --git a/applications/NXoptical_spectroscopy.nxdl.xml b/applications/NXoptical_spectroscopy.nxdl.xml deleted file mode 100644 index 1960213459..0000000000 --- a/applications/NXoptical_spectroscopy.nxdl.xml +++ /dev/null @@ -1,1218 +0,0 @@ - - - - - - - - Variables used throughout the document, e.g. dimensions or parameters. - - - - Length of the spectrum array (e.g. wavelength or energy) of the measured - data. - - - - - Number of measurements (1st dimension of measured_data array). This is - equal to the number of parameters scanned. For example, if the experiment - was performed at three different temperatures and two different pressures - N_measurements = 2*3 = 6. - - - - - A general application definition of optical spectroscopy elements, which may - be used as a template to derive specialized optical spectroscopy experiments. - - Possible specializations are ellipsometry, Raman spectroscopy, photoluminescence, - reflectivity/transmission spectroscopy. - - A general optical experiment consists of (i) a light/photon source, (ii) a sample, - (iii) a detector. - - For any free text descriptions, it is recommended to enter data in english - language, as this is the most FAIR representation. - - - - - An application definition describing a general optical experiment. - - - - Version number to identify which definition of this application - definition was used for this entry/data. - - - - - URL where to find further material (documentation, examples) relevant - to the application definition. - - - - - - - - - - Datetime of the start of the measurement. - Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, - otherwise, the local time zone is assumed per ISO8601. - - It is required to enter at least one of both measurement times, either "start_time" or "end_time". - - - - - Datetime of the end of the measurement. - Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, - otherwise the local time zone is assumed per ISO8601. - - It is required to enter at least one of both measurement times, either "start_time" or "end_time". - - - - - A (globally persistent) unique identifier of the experiment. - (i) The identifier is usually defined by the facility, laboratory or - principal investigator. - (ii) The identifier enables to link experiments to e.g. proposals. - - - - - - Select the range of validity of this identier. - Local: Setup#1 at Institute building #2 in Room #3 - Global: Unique identification of with by unique location and unique - globally persistent time stamp. - - - - - - - - - - - An optional free-text description of the experiment. - - Users are strongly advised to parameterize the description of their experiment - by using respective groups and fields and base classes instead of writing prose - into this field. - - The reason is that such a free-text field is difficult to machine-interpret. - The motivation behind keeping this field for now is to learn how far the - current base classes need extension based on user feedback. - - - - - Specify the type of the optical experiment. - - Chose other if none of these methods are suitable. You may specify - fundamental characteristics or properties in the experimental sub-type. - - For Raman spectroscopy or ellipsometry use the respective specializations - of NXoptical_spectroscopy. - - - - - - - - - - - Specify a special property or characteristic of the experiment, which specifies - the generic experiment type. - - - - - - - - - - - If "other" was selected in "experiment_type" and/or in "experiment_sub_type", - specify the experiment here with a free text name, which is knwon in the - respective community of interest. - - - - - Description of one or more coordinate systems that are specific to the - experiment. Examples are beam centered, sample-normal centered, - laboratory-system centered, sample-stage centered, crystal-symmetry centered. - - - - - This refers to the coordinate system along the beam path. The origin and - base is defined at z=0, where the incident beam hits the sample at the surface. - - - - - This is the default NeXus coordinate system (McStas), if the transformation - does not change the coordinate system at all - i.e. it is unity. - Otherwise, by this a respective transformation of the beam - reference frame to the default reference frame could be made. i.e. - exchange of x and z coordinate, rotation of respective coordinates - towards each other. - - - - - - - Link to transformations defining the sample-normal base coordinate system, - which is defined such that the positive z-axis is parallel to the sample normal, - and the x-y-plane lies inside the sample surface. - - - - - Set of transformations, describing the orientation of the sample-normal coordinate system - with respect to the beam coordinate system (.). - - - - - - - Contact information and eventually details of at persons who - performed the measurements. This can be for example the principal - investigator or student. Examples are: name, affiliation, address, telephone - number, email, role as well as identifiers such as orcid or similar. - It is recommended to add multiple users if relevant. - - Due to data privacy concerns, there is no minimum requirement. - If no user with specific name is allowed to be given, it is required to - assign at least an affiliation - - - - - Devices or elements of the optical spectroscopy setup described with its - properties and general information. - - This includes for example: - - The beam device's or instrument's model, company, serial number, construction year, etc. - - Used software or code - - Experiment descriptive parameters as reference frames, resolution, calibration - - Photon beams with their respective properties such as angles and polarization - - Various optical beam path devices, which interact, manipulate or measure optical beams - - Characteristics of the medium surrounding the sample - - "Beam devices" for a beam path description - - Stages(NXmanipulator) - - Sensors and actuators to control or measure sample or beam properties - - - - This can be used to describe properties of a photon beam. - A beam is always defined between two beam_devices, via - "previous_device" and "next_device". - - It is required to define at least one incident beam which is incident - to the sample. You may specify if this beam parameters are acutally measured - or just nominal. - If this beam is the output of a source, chose the same - name appendix as for the NXsource instance (e.g. TYPE=532nm) - - - - Select the reliability of the respective beam characteristics. Either, - the parameters are measured via another device or method or just given - nominally via the properties of a light source properties (532nm, 100mW). - - - - - - - - - - - - - The path to the device which emitted this beam (light source or frequency doubler). - - This parameter is recommended, if the previous optical element is a photon source. - In this way, the properties of the laser or light souce can be described - and associated. - The beam should be named with the same appendix as the source, e.g., - for TYPE=532nmlaser, there should be both a NXsource named - "source_532nmlaser" and a NXbeam named "beam_532nmlaser". - - Example: /entry/instrument/source_532nmlaser - - - - - - - - - - - - - - Angle of the linear polarized light, with respect to a fixed arbitrary - defined 0° position. This can be used if no definition of respective - cooridnate systems for beam and sample normal is done. If coordinate systems - are defined, refer to beam "incident_polarization". - - - - - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - Type of detector, if "other" was selected in "detector_type". - - - - - Contains the raw data collected by the detector before calibration. - The data which is considered raw might change from experiment to experiment - due to hardware pre-processing of the data. - This field ideally collects the data with the lowest level of processing - possible. - - - - - - - - - - Raw data before calibration. - - - - - - Specify respective hardware which was used for the detector. For - example special electronics required for time-correlated single photon - counting (TCSPC). - - - - - - - - - - - - - - - - - - - - - - - - Specification of type, may also go to name. - - - - - - If available, name/ID/norm of the light source standard. - - - - - Details about the device information. - - - - - The path to a beam emitted by this source. - Should be named with the same appendix, e.g., - for TYPE=532nmlaser, there should as well be - a NXbeam named "beam_532nmlaser" together with this source - instance named "source_532nmlaser" - - Example: /entry/instrument/beam_532nmlaser - - - - - - - - - Defines the reference frame which is used to describe the sample orientation - with respect to the beam directions. - - A beam centered description is the default and uses 4 angles(similar to XRD): - - Omega (angle between sample surface and incident beam) - - 2Theta (angle between the transmitted beam and the detection beam) - - Chi (sample tilt angle, angle between plane#1 and the surface normal, - plane#1 = spanned by incidence beam and detection - and detection. If Chi=0°, then plane#1 is the plane of - incidence in reflection setups) - - Phi (inplane rotation of sample, rotation axis is the samples - surface normal) - - - A sample normal centered description is as well possible: - - angle of incidence (angle between incident beam and sample surface) - - angle of detection (angle between detection beam and sample surface) - - angle of incident and detection beam - - angle of in-plane sample rotation (direction along the sample's surface normal) - - An arbitrary reference frame can be defined by "reference_frames" - and used via "instrument/angle_sample_and_beam_TYPE" - - - - - - - - - Angle between sample incident beam and sample surface. - - - - - Angle between incident and detection beam - - - - - Sample tilt between sample normal, and the plane spanned by detection and - incident beam. - - - - - Inplane rotation of the sample, with rotation axis along sample normal. - - - - - Angle(s) of the incident beam vs. the normal of the bottom reflective - (substrate) surface in the sample. These two directions span the plane - of incidence. - - - - - Detection angle(s) of the beam reflected or scattered off the sample - vs. the normal of the bottom reflective (substrate) surface in the - sample if not equal to the angle(s) of incidence. - These two directions span the plane of detection. - - - - - Angle between the incident and detection beam. - If angle_of_detection + angle_of_incidence = angle_of_incident_and_detection_beam, - then the setup is a reflection setup. - If angle_of_detection + angle_of_incidence != angle_of_incident_and_detection_beam - then the setup may be a light scattering setup. - (i.e. 90° + 90° != 90°, i.e. incident and detection beam in the sample surface, but - the angle source-sample-detector is 90°) - - - - - Angle of the inplane orientation of the sample. This might be an arbitrary, - angle without specific relation to the sample symmetry, - of the angle to a specific sample property (i.e. crystallographic axis or sample - shape such as wafer flat) - - - - - Set of transformations, describing the relative orientation of different - parts of the experiment (beams or sample). You may select one of the specified - angles for incident and detection beam or sample, and then use polar and azimuthal - angles to define the direction via sperical coordinates. - This allows consistent defintion between different coordinate system. - You may refer to self defined coordinate system as well. - - - If "angle_reference_frame = beam centered", then this coordinate system is used: - McStas system (NeXus default) - (https://manual.nexusformat.org/design.html#mcstas-and-nxgeometry-system) - - i.e. the z-coordinate math:`[0,0,1]` is along the incident beam direction and - the x-coordinate math:`[1,0,0]` is in the horizontal plane. Hence, usually math:`[0,1,0]` - is vertically oriented. - - If "angle_reference_frame = sample-normal centered", then this coordinate - system is used - z - math:`[0,0,1]` along sample surface normal - x - math:`[1,0,0]` defined by sample surface projected incident beam. - y - math:`[0,1,0]` in the sample surface, orthogonal to z and x. - For this case, x may be ill defined, if the incident beam is perpendicular - to the sample surface. In this case, use the beam centered description. - - - - - - - - - - - Rotation about the y axis (polar rotation within the sample plane). - - - - - - - - - - - - - - Path to a transformation that places the sample surface - into the origin of the arpes_geometry coordinate system. - - - - - - Rotation about the z axis (azimuthal rotation within the sample plane). - - - - - - - - - - - - - - - - - - - - - Specify if there is a lateral offset on the sample surface, between the focal - points of the incident beam and the detection beam. - - - - - Describes the order of respective beam devices in the optical beam - path. - - Everything object which interacts or modifies optical beam properties, - may be an beam device, e.g. Filter, Window, Beamsplitter, Photon Source, - Detector, etc, - - It is intended, to include this functionality later to "older" beam - components, such as NXsource, NXdetector, NXlens, etc. - Until this is possbible, auxillary beam devices have to be created, - for each "older" beam component instead, to allow a beam path description. - To link the auxillary beam device to the real device properties, the - attribute \@device should be used. - - - - Reference to beam device, which is described by a NeXus concept - (e.g. for NXsource, entry/instrument/source_TYPE). - - - - - Reference to the previous beam device, from which the photon beam came - to reach this beam device. A photon source is related as origin by ".". - This enables a logical order description of the optical setup. - - - - - - This is the optical element used to focus or collect light. This may - be a genereic lens or microcope objectives which are used for the - Raman scattering process. - - - - - - - - - - - - - - - - - polarization filter to prepare light to be measured or to be incident - on the sample. - Genereric polarization filter porperties may be implemented via NXfilter_pol - at a later stage. - - - - Physical principle of the polarization filter used to create a - defined incident or scattered light state. - - - - - - - - - - - - Specific name or type of the polarizer used. - - Free text, for example: Glan-Thompson, Glan-Taylor, Rochon Prism, Wollaston - Polarizer... - - - - - - - Spectral filter used to modify properties of the scattered or incident light. - Genereric spectral filter porperties may be implemented via NXfilter_spec - at a later stage. - - - - Type of laserline filter used to supress the laser, if measurements - close to the laserline are performed. - - - - - - - - - - - - - Type of laserline filter used to supress the laser, if measurements - close to the laserline are performed. - - - - - - - - - - - - Properties of the spectral filter such as wavelength dependent Transmission - or reflectivity. - - - - Which property is used to form the spectral properties of light, - i.e. transmission or reflection properties. - - - - - - - - - - - - - Allows description of beam properties via matrices, which relate ingoing with - outgoing beam properties. - - - - - Sample stage (or manipulator) for positioning of the sample. This should - only contain the spatial orientation of movement. - - - - Specify the type of the sample stage. - - - - - - - - - - - - - - If "other" was chosen in stage_type, enter here a free text description - of the stage type. - - - - - This allows a description of the stages relation or orientation and - position with respect to the sample or beam, if an laboratory or - an stage coordinate system is defined. - - - - - Description of relation of the beam with the sample. How dit the - sample hit the beam, e.g. 'center of sample, long edge parallel - to the plane of incidence'. - Is redundent, if a full orientation description is done via the - stages "transformations" entry. - - - - - - - - - - - - - - - - - - Type of control for the sample temperature. Replace TYPE by "cryostat" or - "heater" to specify it. - - - - - - - - - - - - - - - - Hardware used for actuation, i.e. laser, gas lamp, filament, resistive - - - - - - - - - - General device information of the optical spectroscopy setup, if - suitable (e.g. for a tabletop spectrometer or other non-custom build setups). - For custom build setups, this may be limited to the construction year. - - - - - - - - - - Commercial or otherwise defined given name of the program that was - used to control any parts of the optical spectroscopy setup. - The uppercase TYPE should be replaced by a specification name, i.e. - "software_detector" or "software_stage" to specify the respective - program or software components. - - - - Either version with build number, commit hash, or description of a - (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner. - - - - - Description of the software by persistent resource, where the program, - code, script etc. can be found. - - - - - - - Pre-calibration of an arbitrary device of the instrumental setup, which - has the name DEVICE. You can specify here how, at which time by which method - the calibration was done. As well the accuracy and a link to the calibration - dataset. - - - - Path to the device, which was calibrated. - Example: entry/instrument/DEVICE - - - - - Provide data about the determined accuracy of the device, this may - may be a single value or a dataset like wavelength error vs. wavelength etc. - - - - - Was a calibration performed? If yes, when was it done? If the - calibration time is provided, it should be specified in - ENTRY/INSTRUMENT/calibration/calibration_time. - - - - - - - - - - - - If calibtration status is 'calibration time provided', specify the - ISO8601 date when calibration was last performed before this - measurement. UTC offset should be specified. - - - - - Generic data which does not fit to the 'NX_FLOAT' fields in NXproces. - This can be for example the instrument response function. - - - - - - The overall resolution of the optical instrument. - - - - - - - - - - Minimum distinguishable wavelength separation of peaks in spectra. - - - - - - Array of pairs of complex refractive indices n + ik of the medium - for every measured spectral point/wavelength/energy. - Only necessary if the measurement was performed not in air, or - something very well known, e.g. high purity water. - - - - - - - - - - Properties of the sample, such as sample type, layer structure, - chemical formula, atom types, its history etc. - Information about the sample stage and sample environment should be - described in ENTRY/INSTRUMENT/sample_stage. - - - - - Locally unique ID of the sample, used in the reasearch institute or group. - - - - - State the form of the sample, examples are: - thin film, single crystal, poly crystal, amorphous, single layer, - multi layer, liquid, gas, pellet, powder. - Generic properties of liquids or gases see NXsample properties. - - - - - Free text description of the sample. - - - - - Chemical formula of the sample. Use the Hill system (explained here: - https://en.wikipedia.org/wiki/Chemical_formula#Hill_system) to write - the chemical formula. In case the sample consists of several layers, - this should be a list of the chemical formulas of the individual - layers, where the first entry is the chemical formula of the top - layer (the one on the front surface, on which the light incident). - The order must be consistent with layer_structure - - - - - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - 'atom_types'. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known timestamp when - the measured specimen surface was actively prepared. - - - - - A set of activities that occurred to the sample prior to/during the experiment. - - - - - Sample temperature (either controlled or just measured). - - - - If no sensor was available for the determination of temperature, selected - a nominal value which represents approximately the situation of sample temperature. - - - - - - - - - - - If temperature_nominal is "other", enter here a nominal/assumed/estimated - sample temperature. - - - - - Temperature sensor measuring the sample temperature. - This should be a link to /entry/instrument/manipulator/temperature_sensor. - - - - - Device to heat the sample. - This should be a link to /entry/instrument/manipulator/sample_heater. - - - - - Device for cooling the sample (Cryostat, Airflow cooler, etc.). - This should be a link to /entry/instrument/manipulator/cryostat. - - - - - - Arbirary sample property which may be varied during the experiment - and controlled by a device. Examples are pressure, voltage, magnetic field etc. - Similar to the temperautre description of the sample. - - - - Medium, in which the sample is placed. - - - - - - - - - - - - - - - - - (Measured) sample thickness. - - The information is recorded to qualify if the light used was likely - able to shine through the sample. - - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - - - - - If a thickness if given, please specify how this thickness was estimated or - determined. - - - - - - Qualitative description of the layer structure for the sample, - starting with the top layer (i.e. the one on the front surface, on - which the light incident), e.g. native oxide/bulk substrate, or - Si/native oxide/thermal oxide/polymer/peptide. - - - - - Specify the sample orientation, how is its sample normal oriented - relative in the laboratory reference frame, incident beam reference - frame. - - - - - If the sample is grown or fixed on a substrate, specify this here by - a free text description. - - - - - - Here generic types of data may be saved.. This may refer to data derived - from single or multiple raw measurements (i.e. several intensities are - evaluated for different parameters: ellipsometry -> psi and delta) - - i.e. non-raw data. - As well plotable data may be stored/linked here, which provides the most suitable - representation of the data (for the respective community). - - You may provide multiple instances of NXdata - - - - Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) - - - - - Spectrum, i.e. y-axis of the data (e.g. counts, intensity) - - - - - - - - Location to save the calibrated wavelength data. - - - - - - - - - Parameters that are derived from the measured data. - - - - Light loss due to depolarization as a value in [0-1]. - - - - - - - - - - Jones quality factor. - - - - - - - - - - Reflectivity. - - - - - - - - - - Transmittance. - - - - - - - - - - - Commercial or otherwise defined given name of the program that was - used to generate or calculate the derived parameters. - If home written, one can provide the actual steps in the NOTE - subfield here. - - - - - Either version with build number, commit hash, or description of a - (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner. - - - - - - diff --git a/applications/NXraman.nxdl.xml b/applications/NXraman.nxdl.xml deleted file mode 100644 index 02290711de..0000000000 --- a/applications/NXraman.nxdl.xml +++ /dev/null @@ -1,261 +0,0 @@ - - - - - - - - - - Variables used throughout the document, e.g. dimensions or parameters. - - - - Length of the spectrum array (e.g. wavelength or energy) of the measured - data. - - - - - Number of measurements (1st dimension of measured_data array). This is - equal to the number of parameters scanned. For example, if the experiment - was performed at three different temperatures and two different pressures - N_measurements = 2*3 = 6. - - - - - Number of detection angles of the beam reflected or scattered off the - sample. - - - - - Number of angles of incidence of the incident beam. - - - - - Number of scattering configurations used in the measurement. - It is 1 for only parallel polarization meausement, 2 for parallel and cross - polarization measurement or larger, if i.e. the incident and scattered photon - direction is varied. - - - - - An application definition for Raman spectrocopy experiments. - - Such experiments may be as simple a single Raman spectrum from spontanous - Raman scattering and range to Raman imaging Raman spectrometer, - surface- and tip-enhanced Raman techniques, x-Ray Raman scattering, as well - as resonant Raman scattering phenomena or multidimenional Raman spectra (i.e. - varying temperature, pressure, electric field, ....) - - The application definition contains two things: - 1. The structures in the application definition of NXopt: - * Instrument and data calibrations - * Sensors for sample or beam conditions - - AND - - 2. The strucutres specified and extended in NXraman: - * description of the experiment type - * descroption of the setup's meta data and optical elements (source, monochromator, detector, waveplate, lens, etc.) - * description of beam properties and their relations to the sample - * sample information - - Information on Raman spectroscopy are provided in: - - General - - * Lewis, Ian R.; Edwards, Howell G. M. - Handbook of Raman Spectroscopy - ISBN 0-8247-0557-2 - - Raman scattering selection rules - - * Dresselhaus, M. S.; Dresselhaus, G.; Jorio, A. - Group Theory - Application to the Physics ofCondensed Matter - ISBN 3540328971 - - Semiconductors - - * Manuel Cardona - Light Scattering in Solids I - eBook ISBN: 978-3-540-37568-5 - DOI: https://doi.org/10.1007/978-3-540-37568-5 - - * Manuel Cardona, Gernot Güntherodt - Light Scattering in Solids II - eBook ISBN: 978-3-540-39075-6 - DOI: https://doi.org/10.1007/3-540-11380-0 - - * See as well other Books from the "Light Scattering in Solids" series: - III: Recent Results - IV: Electronic Scattering, Spin Effects, SERS, and Morphic Effects - V: Superlattices and Other Microstructures - VI: Recent Results, Including High-Tc Superconductivity - VII: Crystal-Field and Magnetic Excitations - VIII: Fullerenes, Semiconductor Surfaces, Coherent Phonons - IX: Novel Materials and Techniques - - Glasses, Liquids, Gasses, ... - - Review articles: - Stimulated Raman scattering, Coherent anti-Stokes Raman scattering, - Surface-enhanced Raman scattering, Tip-enhanced Raman scattering - * https://doi.org/10.1186/s11671-019-3039-2 - - - - - An application definition for Raman spectrsocopy. - - - - Version number to identify which definition of this application - definition was used for this entry/data. - - - - - URL where to find further material (documentation, examples) relevant - to the application definition. - - - - - - - - - - Specify the type of the optical experiment. - - You may specify fundamental characteristics or properties in the experimental sub-type. - - - - - - - - Specify the type of Raman experiment. - - - - - - - - - - - - - - - - - - - - If the raman_experiment_type is `other`, a name should be specified here. - - - - - Metadata of the setup, its optical elements and physical properites which - defines the Raman measurement. - - - - Scattering configuration as defined by the porto notation by three - states, which are othogonal to each other. Example: z(xx)z for - parallel polarized backscattering configuration. - - See: - https://www.cryst.ehu.es/cgi-bin/cryst/programs/nph-doc-raman - - A(BC)D - - A = The propagation direction of the incident light (k_i) - B = The polarization direction of the incident light (E_i) - C = The polarization direction of the scattered light (E_s) - D = The propagation direction of the scattered light (k_s) - - An orthogonal base is assumed. - Linear polarized light is displayed by e.g. "x","y" or "z" - Unpolarized light is displayed by "." - For non-orthogonal vectors, use the attribute porto_notation_vectors. - - - - Scattering configuration as defined by the porto notation given by - respective vectors. - - Vectors in the porto notation are defined as for A, B, C, D above. - Linear light polarization is assumed. - - - - 3 x 4 Matrix, which lists the porto notation vectors A, B, C, D. - A has to be perpendicular to B and C perpendicular to D. - - - - - - - - - - Beam which is incident to the sample. - - - - - - diff --git a/applications/NXxps.nxdl.xml b/applications/NXxps.nxdl.xml deleted file mode 100644 index 89a4065fce..0000000000 --- a/applications/NXxps.nxdl.xml +++ /dev/null @@ -1,510 +0,0 @@ - - - - - - This is the application definition for X-ray photoelectron spectroscopy. - - - - - - - - - - A name of the experimental method according to `Clause 11`_ of - the `ISO 18115-1:2023`_ specification. - - Examples for XPS-related experiments include: - * X-ray photoelectron spectroscopy (XPS) - * angle-resolved X-ray photoelectron spectroscopy (ARXPS) - * ultraviolet photoelectron spectroscopy (UPS) - * hard X-ray photoemission spectroscopy (HAXPES) - * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) - * electron spectroscopy for chemical analysis (ESCA) - - .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html - .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 - - - - - - In traditional surface science, a left-handed coordinate system is used such that the positive z-axis - points along the normal of the sample stage, and the x- and y-axes lie in the plane of the sample stage. - However, in NeXus, a coordinate system that is the same as `McStas`_ is used. `xps_coordinate_system` - gives the user the opportunity to work in the traditional base coordinate system. - - .. _McStas: http://mcstas.org/ - - .. image:: xps/xps_cs.png - :width: 40% - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Link to transformations defining the XPS base coordinate system, - which is defined such that the positive z-axis points along the sample stage normal, and the - x- and y-axes lie in the plane of the sample stage. - - - - - Set of transformations, describing the orientation of the XPS coordinate system - with respect to the beam coordinate system (.) or any other coordinate system. - - The transformations in `coordinate_system_transformations` depend on the actual instrument geometry. - If the z-axis is pointing in the direction of gravity (i.e., if the sample is mounted horizontally), - the following transformations can be used for describing the XPS coordinate system - with respect to the beam coordinate system (.): - - .. code-block:: - - xps_coordinate_system:NXcoordinate_system - depends_on=entry/geometries/xps_coordinate_system/coordinate_transformations/z_rotation - coordinate_system_transformations:NXtransformations - z_rotation=beam_azimuth_angle - @depends_on=y_flip - @transformation_type=rotation - @vector=[0, 0, 1] - @units=degree - y_flip=180 - @depends_on=y_rotation - @transformation_type=rotation - @vector=[0, 1, 0] - @units=degree - y_rotation=beam_polar_angle_of_incidence - @depends_on=. - @transformation_type=rotation - @vector=[0, 1, 0] - @units=degree - - - - - - - Description of the XPS spectrometer and its individual parts. - - This concept is related to term `12.58`_ of the ISO 18115-1:2023 standard. - - .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 - - - - - - - - Reference to the transformation describing the orientation of the beam - relative to a defined coordinate system. - - - - - - Incidence angle of the beam with respect to the upward z-direction, defined by - the sample stage. - - - - - - - - - - - - - - - - - - - - Azimuthal rotation of the beam from the y-direction towards the operator, defined - by the sample stage. - - - - - - - - - - - - - - This should point to the last element of the coordinate system transformations defined in - /entry/geometries/xps_coordinate_system/coordinate_system_transformations. - - - - - - - - - - - - - - - - - - Reference to the transformation describing the orientation of the analyzer - relative to a defined coordinate system. - - - - - - Polar tilt of the analyser with respect to the upward z-direction, defined by - the sample stage. - - The angle between the incoming beam and the analyser is given by - beam_analyser_angle = beam_polar_angle_of_incidence + analyser_take_off_polar_angle. - In practice, the analyser axis is often set as the z axis (analyser_take_off_polar_angle = 0), - so that beam_analyser_angle = beam_polar_angle_of_incidence. For magic angle configurations, - this angle is 54.5°. - - - - - - - - - - - - - - - - - - - - Azimuthal rotation of the analyser from the y-direction towards the operator, - defined by the sample stage. - - - - - - - - - - - - - - This should point to the last element of the coordinate system transformations defined in - /entry/geometries/xps_coordinate_system/coordinate_system_transformations. - - - - - - - - - - - - - - Reference to the transformation describing the orientation of the sample - relative to a defined coordinate system. - - - - - - Clockwise rotation about the sample normal. - - - - - - - - - - - - - - - - - - - - Polar tilt of the sample with respect to the upward z-direction, defined by - the sample stage. - - - - - - - - - - - - - - - - - - - - Azimuthal rotation of the sample from the y-direction towards the operator, - defined by the sample stage. - - - - - - - - - - - - - - This should point to the last element of the coordinate system transformations defined in - /entry/geometries/xps_coordinate_system/coordinate_system_transformations. - - - - - - - - - - - - - - Peak model for XPS fitting. Each `NXfit` instance shall be used for the description of - _one_ peak fit in _one_ XPS region. As an example, this could be used to describe the - fitting of one measured C 1s spectrum. - - This concept is related to term `3.29`_ of the ISO 18115-1:2023 standard. - - .. _3.29: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.29 - - - - - Input data and results of the fit. - - - - Dependent variable for this fit procedure. - - This could be a link to entry/data/data. - - - - - Independent variable for this fit procedure. - - This could be a link to entry/data/energy. - - - - - - - - - - - This could be a link to entry/data/energy. - - - - - Intensity values of the fitted function at each energy in the position field. - - This concept is related to term `3.15`_ of the ISO 18115-1:2023 standard. - - .. _3.15: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.15 - - - - - - - - - Area of the peak. - - - - - Width of a peak at a defined fraction of the peak height. - - Usually, this will be the Full Width at Half Maximum of the peak (FWHM). - For asymmetric peaks, convenient measures of peak width are the half-widths of - each side of the peak at half maximum intensity. - - This concept is related to term `3.28`_ of the ISO 18115-1:2023 standard. - - .. _3.28: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.28 - - - - - - Position of the peak on the energy axis. - - - - - - - Total area under the peak after background removal. - - This concept is related to term `3.16`_ of the ISO 18115-1:2023 standard. - - .. _3.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.16 - - - - - - Functional form of the fitted XPS background. - - This concept is related to term `3.21`_ of the ISO 18115-1:2023 standard. - - .. _3.21: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.21 - - - - - - - - - - - - Linear background, i.e., a simple straight line from the minimal to - the maximal abscissa value. - - - - - Shirley background. In the Shirley background, the background intensity at any - given binding energy is proportional to the intensity of the total peak area - above the background in the lower binding energy peak range (i.e., the - background goes up in proportion to the total number of photoelectrons below its - binding energy position). - - - - - Tougaard background (or Tougaard universal cross-section approach) which is a - methodology for integrating the intensity of the background at a given binding - energy from the spectral intensities to higher kinetic energies - - - - - In case none of the enumeration items apply, description should be _other_ - and the functional form of the background should be given by the `formula` - field. - - - - - - - - - - - - - - - - - - - - - Atomic concentration of each species defined by one peak in the peak model. - This should be an array with the indices pointing to the individual peaks - (i.e, peak_0, peak_1, etc.) - - - - - diff --git a/applications/xps/xps_cs.png b/applications/xps/xps_cs.png deleted file mode 100644 index f83b15e7076554c830543acae2ff6f3e9960e395..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 148952 zcmXtA1yodB*G8Hll>wwdBqgOw1f;vWq`SK$29y?%?(Xhxq-*F7>F(wq=Ka65WVwJl z=bn4cK6^j0FTdnv#n1r+02mk;bP4fqiZCz;1u!shw8)4sFmK{Ww|+o=@y1b6ObDiI zlxPp~4ZNwKj35k5WhCmO0RrTE6gzPZM;I8qx36Ds2B|ItU|?QyCB6wNyXhW2p)cX6 zG`>XMsL`EgtgG?;Mrxn`twfaVW0dlF(-NGS@ez}lmW3? ze=`3}*sizmK%6sNas@%#x4;byL0bg)Kf!k=V}}O|o=48*iTq=pCf8R!t!1+%8r3Ev z-MWq=rsW!#q?48Kg@8v>X`cbi9-(B*c)J zrH%L-34@3k*JzriFr&ikTyt@21&rHFRxICgb-SfUh+1tSguleY2)5Fyx5+IPiUvwm z!S*gD0IDnmZcWrAX?GElj{LM#l>p?luQPNbEJ=F3zwroBJy<a7CX{;GF$TJ;F1JZrAS>giVH11}F(kS;Sv(1!hnU-od zM$ZfmC$WbL)n?k2{gH2Z+lp1se_s%C_2A>mk~=KmA$X;jFdr?%)S}ajTdaR)sv1vo ztKCrEv|kh=6vjNPJl6Umgs{VrjWQes{EQ>Gim+%SSVdNHV(L>_hb5ap8h#(}LpWkj=OI=qsp0$|t>|A$;9Sz84=cb!PN zstAJqwyPOQqyR4LC|VkD(U&0L`eoC$C?DEc(V;jh$gwzZLub9~z{DNCJ{XlIxRS`H z^F->*$~uB4Pb4J@?R92eDv*6zuF&?ls0e9j$;4CC&Q>Cd+jk-72Hdp13n?EoeX)H| zeB)BZcQ(S5u0fa4emgOpTQOiqXwdSUoW3gEh%BLxXM_`S6R7*MvbkyHaxFae^FskB z4t=(`tT=iztc+i3J!ialBjZmaLFCyTwrO-1yQTHRBaeI|E@2Jl!1 zb}}To-&Dzd}kIUJ->OYgs!iL2>F*`pZQ z&x2+y0Cvmd0Q!VV(yVai`Iit_NL2-CeqBZb5!cIxV_S$-e*7fgVp~yM$XpypSw`$- zSokB$8!4_q)Jt&7?R~i+VZZl5v8e*15W`pQvL73826TU$xT{RUjZ@t|lma_=0_u<) zcP1r2+r3dK-fpm~UU#W1Tnt?BchG**i^bsCBEQj*7T)KG2Yx%F z2q)s6RM#)Y=UF#Frv)3VTg~?EOk_R&wj-1V%??!k1nx8UT&C>yoKc{2&$ceJ(Mz%O z(kT{nXPDwEkw;#Lea11VD|t8j#B)?LMWf6MO(nx``y*={cVqz?s_~3En!w!>FX_+Z zX*}Pn?gtSYL}fCeDa2pYm&R9D0Oz5M#SlsPz`}-V>RbL>;pJG7LD=-~-WMl;Bkau@) zt3>lfITB-gIMI*^!B#)1i%n3Z5v_L?Esn6+RNI1SwXwF{+W!1BwtZfzR=;=`j=^T3 zMq*1Mgf`9yAw({WIrwpH8qxAZPfYXV@s2Nq)@`1p_%K(K>uvwR{X4r%+(%ZILv=uI zFmwl%?QT0B>UK;VA7b7k+&2s!X4-4b!SJyc%#tHdVhq|N0Mls-;1Dg|%&_z}PE@Sn zSneASSuvG(?x@WkRm2z7<4*S9TYHv1E9q7Qt=<57fty9p`BIM}5t2GGG}s^P6X<#r zHLm};p-~epNCa;HBGq;` z&t$ot002eMZ|C~Je)D<;IvhK~a#7&ndhU-=_dNB~{n%^an|5nwUoYFj8H59vTFRe0 z&KW@}(D3FbfpZN2Yj)@m%4A8L#PHUjV1a1+Cw!-X*X4*L62}n7nrfMz#&}qWFgYNM zf9mxxkWz@e`&UGZsl{K`kUF#U%OWRVGvMK>-@Ug_$4BGxa_IV5w_)!O5-m8|byYw- z)9AkyphdzYu0s9r^B`7QU?GTqktUYE1y`uuE;8-}!*<@$>~8c5SOgEc3r0U#@V!1Y z#W28@^}Xy;q#pnPNx4tK%=N;L?t*Zj4L{S3Y11tczuo6sWX&NAdz>wc$J6@il5Nak z^iT_OPA4eJz&1S29#i_8So;>!KU>cvKNoLNs>P+c;{nOyLerGWR#%#QXrcPV`+osB zhf)+7@Y!mP8KBaIplN&+R0=H8yS&50j|n1SUv<|MEVFI9Y;;Ihj-&h<9tofuG^Y9D z0G?IROgqMS@q7as2Jc^CDBG$JUC6WGm^~-J+O(ZW0H$%F7vidxc>WRU9Iv%|zisUs zBD7~Rx|*IL?{K+05g=r|WWoLDFi6o%{K6;t2FDnIpm8TAbgVvJ{beYQawf4jL@$

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

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

9uh}r2@t;E3-R&ri#qh*D%uk=zS*n({EZEI z$|L(i42Ih-Y0q8j1szC``SXLr=kJ#9I%QXyX*9EB%D=bosDAsaQg@Kqc=B=+K?p1f z#6Xhii8bIWE^yAeO9xWFfVMF*3<9GwZg)?G#tBY`H<2w7jTYI}?+baTT|Gu*RrTVD}=J}Ms z{;Z4P)nbLXRmm)T=>epB%;(fy&hSCnoI1Ev_1}ghtJhZSlB{yT7L{ zQ{~s5e~j|+2qM*zu$7|xI@6E6jfo!*skZ51W_nyPrubHuheFG(kUXUq?u-+d17oC+ zeF)f{g^@hg;snb^dID}<1T@T`eM==cx%b_0+wT5|an#O&H+g8eO`e=uahC-B&=-(j zctz>dy>TuM=DT~XR)cLz&n~JCAe*|{f6o2%G=3VmPh&63-V|YY|60>xRmNFQ)r*jS$hC)F?`f01nwJ}i z_%68V0Cl2jKLML2#xR7zwN+DXaM{YWUYxvEpCsOlBW#?Vd9f()ja~_&TTSBl)=17% zQYSnDwxE|EhYp!<4y#!{NrIM1P2YXf6jHx0Ug@1lyy(eFZVcOid?0qg$VWUC2neyC zYtA(+P^3MOHJZ53E65x%?h?;Gv1%uk!2Pvsy&n9gsKbwHmzn_KRlUJA^#>q9gtPi^+Tcl*ixPpT43%U6oyM$;tdzL;|3{LyWNvE5R zT>xeNegv6HG|`Xe`>LD)sF)vN2a(BCs@X)vhS+dv%{UBotFbIoef15g#d5N%QsoSB zv~w~zP`57wHT4PQR*01#1?gtG95EP8YmZ z)k}ZuP7v99mS;f7ry}tY%P&3~{=k3Ls(|J8Ms>S>L(SK<-i|+nECg(bz>U5PKerYw zch6ovpS12Z_a$i42!+fX8qWz4+WhsQZ=G$|KS@*+y zf3o(6>gxlfA>n&*(k!-Q$3aAIKgr<=?FhhbseqP~ezNkTIb(X_uDDUi27k%>P&6EY zqDBh5SUzm5K!4$38Ci>1Jn}S=d4KIu;`-z9pm&Gd(UXJx>n|ys9gy$4Ke3O&3r-?) zn&*Ghgl73bOyv|`Z>Bkht0gHJ+eoxH^A5+4nGZFWD0>V2AEv%L9_#P@KV)T(WOLgx zG9!Cr%dBK)Zz6lo+uoZ9*?W_jO-ON@x1GI-+lqciy+6Ol_fL<9`*qH_&bhAZd2Q^0 z&`_PL6~e`2?CWyvy8aJHQmd%O8G#vbrYzA*e?R%#?rQrWnTCfr5u2vcj4AGM#)_?Oq9o(59(C}lfVw`fhZ|URh7y(a>3HF|C_H_qkCh~O z@xYbJi_CbQ%^uZD`#GQg+s2}!#%XoAn8@v6GaBXC{frHYnc=Ni_k!(QCWdEui!B;%?bsY?o|IQ(}$O(2PfPo7~=UHX_Gl^|JgaDQmHm**VBD?S%w6!rhSx6 zXWwq|sp*0)?jbKV?fqm#z`$Hcd+Y*@!x9GMSp8~Irl&s9N ze^Vqqae^{BTSyLp7*d;ot=BA@PWxFtPMCSPS$}PC_)ISC7X!3fPRF^xCGP#(FQ4oO zoIm08YZ4LS6&&i{F)F%W(LvqjW)||a&5_j4imtX5N|s+@VHi(bzgOeU;Ng03%-PK`rHMSH{@ZGxpsV^zjCg!pb&I z!)Y(x;+ag*@X-SH)fdAVZ%a5_G@1hy;KP1qmyS0Kg>{az9QQ}e-WZ(12+x}koA6wT{D5P zUQJ_5EIm?h^9M{w!Gr`82aTuQsSEozASl)m|M`C9G((SEK^sincC;Va?rBtq@(uX!c{Q{3}*65U_clSlMYbswiN+JT9wv>`oMwe zVM-U%gRfSLinT_PgE_w2WRPf74SB@8l~&PKx%q`bw;sILI!lkSe3I^H^F@c&o#fV_ zRQ%})9>ix9eK*W`KK6m4_&E9Hx`te4_Tfpe5?)J zH+FY(f?%UbdS4!f@%2iNBDH<`R$s%YS@E!QI@rI6;!m%;{onU%rJH~%Ela8-Vp-C)ka2GWyJM-W_{cWRKyp`-6bxQSl7*FAAx{Waw;Zkz}Q7} zVv5imPbKwG2#c4NDf0$}uG>Br>Jn-E+QW(gEh(J(K^&@mdQod>;Ym zEav5F5KZ}P{FGhhofRZTh888vD$GPz?Nhclb{kEo9QACieq$~UJB{OW52_isLat=Q z;6kP+VBz7tP}~&)5~N5MtwFhlH@kw$t7Snd>_L=pRI6K@&n@_ck3%iCefso_U-!DHRn?>g z+kdGRF&?aWRYY9H=u5HR*w~oy_atFS{Z~NtJK-^<&7AQH3!&P#@9)vjl!94l%3~T* zoE2IZbAfXR9(ax(;+zP!bOF_7325=Pi|_V_#f4J2*K0bX@nfF(LnwO}p|v{ZY{Wgj z_~Sg!B8R_oKKH3GzFCX6C<77if2$QI9XtedBSvn^nyh0662BeC$I8ZrS5yh-{uFob*g@q?ice*q?O z`nV_qV6*P;0CIxrQE}(H7f{rCm~-a^^OThrlYBh5-?*^ID)h6OWzh=GuqNFtbVS~` z0523RKL@XKoHVKbHz522l-uk+IKYyga42KyaiOvko>)(lUQ0KtNITOisnxa~Jn<Pp@fD%i$3#zZb&x-zKugMd`sNq_{z(*5!*<=N918#>2g)CUPFrFd%0xky&Z4 zeSIAOpy5?eLN6mRKtiHqg!Py?*{0ce@n_zaeFn%20}?H5H4gx2(Yxh}F6lkOJ7y2T zdm1kiI993T{F)cD3IDy>G)5+q>V2<*G<(}7lOh}Ly;l1Lp}*VULoTQhzoP}WNk2AK z&mLj(StEe4B_^$yLqzg7?jzNSAMz$_@cZ1kzU#(}P>`CxU7Vk&tj#gEz;wiP8u}g3 zY<<|M=z5wfuIY1i%5C9~FD3s;t;OPbPrau65#k{8R;g&PqAB+Yn^q;CC_MulpgUPV zbNxFkq^m%AD85Xqj}FC;6{LP%Ul-gQTo-n!v-(;6Blyfub@D%V?|}g%4NeNk-@S(h z13zCe`zc?mvp^|H4U8jg8TJ|_XHOi*@#4d|4Ssmt-ic)>H^C;CgUC~A#nX)<1aEId zEE(?|o&=Oy)iM~27 zjTbI7vP;trV?z&-qQUg;AFo5=a@ zz1RVqKel&J4J)XvTlH;IZ~V(}hbYTlC!A0E34SttJfwxv%_&*qa6D*NW{q+pTaGQZ6Cu2*fc)Dz&Ukl}$t4x{ZHuvR4PPmS zo_Y&bgs;`xjSR~W-e;u@1=?KYM|w)vMATuN9sc?xkN5pEHTp*36X`B+{0B1I21J0F zdIFkaq9{1kDf_?O9_O~aSZh-WPBoB9cv~kW@4S|doVukvv4+%7B%D#YGC>Wbe<;I7_SZ!NHM2G^q znrn96&N6}>H7Z1iID8i1)Meia3P<02UrjFJUj5e?mroyW|4YyNfyNt8VjUl>TQ?dF zne9w0xP2G+#cwl}Mq+aRb5^{7P_$C7HV)Pph~Ya^0tsT?ceD^VYex9QZa{HbC>#sW zcD2CS51^q2YT1TGdjua2F+5m{Po5M$#B|S z_FR^A9@WHB&eTRtW7lkCX^j#d2aX-K4V{BaOu@dXFTx)X>Xz6OlC&$La(k^=q{4qE zF)?PPwr}qwQx6Zw8$1g_K@$wAo8}Zf3%!Dh0sTw&(gjVt_TeHcCIlkYfOspUU14nk+b!m#WMl!n0hvc0XfTcj=ei>ZkLq=MyS&B9^iX1oDN|21nEBJ zRUBbOtxVr>5yu&{!}xvTmkJ)wur1|8en`wEYhl>3!@J>Z#de82T@KI8-q8ovi7oV z5Er1f#deN@VjLsBu~Uq1taw?fT2RCKsXbDxt*v?P)}+TpBF#b$hM{vre0n=)<^JyR z>#^(^NPeuykxdJB-5@IC(Ke-UBfFR#$V9V^ieGSh(m9t)O?b#IPvwD%aGiE)*k?6a zigK5p>jqJA#Z(qUfD24t_v%nf1*6^?5GD}p9b?I2C}fYf)7>$2QA5M4CHE?u+i>3n zwy%;hG0rMsDFs550XDA1Oacdav!lg)aR03iVvma$mGUgFmJ zJZ+zesIF9!&pwLLH|8|`z2ghV;P;&5(^LfhH9kiMWnl&;d>b6~MI@00!O`kxr#vvC z&dj(+^HKJmW}mg$m@Z0}oVFhn9kG|XEUjo3R8e-mXZZM%aNHnpiaz*4^K~Bq*M1zS zP=d?G`g_@shQRvw$>!YbS#x-|+aE_BCnru@!}xXgGvnfvJ$NBrXNI;FE#>%#ht zqKN}&e)mO9OVHyp2^5>PXqrC0 z#Ff{Yf$JE*;|eUCU-hI_443{~6`bLbge5+>lr@(B93bCBd}Rm}!XCQT3eDn4UD zrC|pew-2+V_jKD5<&Vr^WXkce*nIkp+j$!=I;L6Wf7!aLQjW{3=j1TucO<=Xyss>r zPneeCwJ}n=NjjYTg?0Z&PkEBF%i-dBZO&dpsy40q%IM%IkY@Eq^X(-~nrR!8aTZ>z z(&h4!|Mwf@g0Cjq26%|_1X?9ZY8rvo(pK=$NaZqr|ekElMVgLAf)ff+v;21FW^EX9~5Pt0CXB2D08_LOU{YmIy*S$j#> zU-#0X=e)z>fqcS|IWU^rJ*|vHZ?xWL1wMVzdfP4RvV_4(_jjlNUaHZTZ6X^h?vUim zqhUkNY3A^rOmz`}m(ft7cRG5CV0IJKt`TrPY#*I=&xUPANMGRp*)+DGPh&Kt)zg=` zFVCq=5wziev~444+@DT=+yu`Zig&CNH=osiq{pv^-QdFz!j8_^puLgMs+z+PUGrg zCqPypApo=r3Nt<&36qrQu%4x9bgh_`SPc~Tv?g&eaJoI=g3Sw!*LPbSW%d2}wD;Zn z8M^3us4lg9{QT*RQeQ3ADN(@(q|Xn`b7hb2eZsJ+F&iF{C4AII#u)0hC9xxvgmc+{ zo+Ty73AY-^YDi%d@nb8cK?!1a%cV8B4IRcOBCShg8A&d)XC8gNa&X|fp?mH*F^F+HSEw)`Xde1e=D6|~^e(RAK{a)R2Be|(YO7l^8(CLZ-0#_-ym zH{zp?#w3S+%ge~+#nv;&2WvWeMdGAI%;}JPz|tyEkeipmC?)itJWWdPQz8%^t(g5K z^g+JHk#Z_2N(o7p+aK# zl~C?5eDQzmX?jmD27z#`lg&#oJ5*T|fpKtf)bvty3kP@ViGRMq-APf>5=5=HEABCh z;Cp^Pk^0s6o$X8T0#S+a4`H zLy;oK_bmQtwEi_&=rk%$@t;g%pa-KuH1Bfi%O_>8W&T*D>?kD+M31|Yvbj#8Lt-_z$bOl_@zuO<$i8i!T=nCcW zx~UkB9pB9~d^2f9b+*`XIj`b^H0O0*xt;a3fVvThpxu&a-IC}n8T2MZao~}uc>UpH zya#Q9F@Qwv|3ubR zyIv9Ppw#?orr!v+o4qLuc6VFWhF17l1tIu)mR+C=;^(X!PzS+HUyi7;n*))ecepl> za67e|{wV6+ic}1zaA+2NaEj0_qe*iQkS2nhs>zvw%s9_HR;j?8e=^nt%vDzc<3r%( zs68Z&_&J;_+YehgCHI@6d}zn}TBEeey<{91CHLLDx69ni3$m5e&>1lgzd@&$Ud3{H zNRECyjl;!q4Bw)4?W(@q`Nl>wTrZc|g96!>!gF!Q=Y(#GV_+(3Ka~4YFU^C&IR^4& zM|E6i#URQM=f23jht;(UY?f@8)>hJA%?uqV7M(mAj)glgtdk;z&CKUvdN6ek#HQu~W5Blc5AgYhdP?N5{SW z?{R;k-9uTSu~K)C#38WrD*hCQeyDQ2w4~moY*4}*+5Ei0uK4{}gKC;+B1&C2_d#6T zX>KS80Y7EH{%;ptZOSWyWp3yYdS2CbIBTh$@L^mg%0g8%y|DQ%o$EKF9tO?Xhv>5RLq-q%ihnlU zd~sfm5@ui!{w}Rgkrw=T=$e7`>3<6gro~WBBru1FUOvEhT-nY&1uK1F3hG%XOPnaL9Oi%Lz1u|N92gg>Xkh!(_QkkMEIcN;@w( zXy;#bPQFX`K}OAFffIe4^ULjcia(FnLM07)^wxspOsJMxtL;?tH`Zey;MOVJ+*d*# zWiS@t3T@HWt*L%DTEF-iJ6+|qR}<>X80-uM%c^~gEB>cAhLGf6(hM-x$y8w&i{mwL zlm}=X<>@iGBaJue6|}dSbHI!6TliR(HnF6YtP*sJqtqw+l2>P;`#7D z8#SBsr-TyR%vFcf+YJ(q!(cDD55AN1uD(j)(Y1{%(uO{CpsHflnIn|6!;`CJm&%ZS zX!RVdj5dHyh+Z(J4m>psa?jgs=?wP6H3J`56MU_$N>UQFYR$-LH2jgmabh>-LcDr< z(92lN)_@W~f!6w>^QkSte!~iS3{S)SOrAD=u8mi!4DImd#O|w56#H3UHMC}c@hF=;-SFkmsBu-U>ZE9m%)#CnY2?>Ows&P5RhoxBIPLP`&jp^KliOC^9SQae) zQX3`J9)!%yqnnG@76Mp8E{KsH)4h7mS=|(A=@R}HkWdmklB=<%@5zq5kG~e^mGJfH zEbiV@NC#xG4AWX1Sg6_Z^N`SoQmX;fJ6{>nFC+M<|6wSn{*(3LS0IiyLhiV-xe$O6 zLW)W!(H^Mt)og*J;!Wc;(p0-~V@6KOel3lGqsaEh(;xkuZfB$LP(_C0Gr7z~H9RSK z!L3{bI$2d*R#;r~f7(^L#qF@Nj+PIZ#?Bjb$lB&UyETcNEcB{+>9FM4;dwnaI`>r1 zLoc-94`La&44mqS7{x%6gL>6EZ_*xRW|vbE$FvpJFukvJ{MIX^AxY`l=sy2R0}qfm zw$gYF;z>^!?Eh0L()cIw(@Gb|8|RbgV^uFRshd?ISN-%(d~PI6KBOeMF&A5oKE7jp zn(xy4=HvMap5|IotNH&-oM&dBIK&!sqBiHy^}gs=vYrSMD8`x2&R?{oUM6l=Aa578 zf4u$y_W?C|l#q8bwJSrgZGcG{g|d^Z{QQ41b0FV`Ox*fUrsw&=@T7Plv#p_*;xuEFA9;w4`Q{_4hk5ig^1jXJ1t8 zME$P&c|cAhvsb*Gd$I*e^}-^0$=RL@fV~6N-)Ki_K#3X<^X~sy@XydwdBP3%4?$}z zrZHY>H1G3lG8dxJ8>n2%d7kk9%1K5f~SB|%PWH6+JT zd$b5&1WJ>Wh?g)#CX{;T+p?s0f?wgnO|AAq2-KE;de z?{${lH*uyv z$>$vB1`q0<5P)HLx0jQhhcNsJp0YeGHFz$h_G5XZKcbRo9OJumJ1QAUgz^}C>G4h2 zRjANqjjhTYqR!^yR8^UwZ>x#N?-%P{a8xYA?@&9rQFp0S55pR&u$&aFz4!Y;e$&HN z8dp&uYe4$Jz46@7oZB0ZUb|qJcpQz940C#2Z@e$_sxLcQr2pljyZ`8>h_&R2db=>4 zDUy?T&;6krc9*s~>XzOr+ot#WD6>W5Wp7BI+RuZ|zSmq|yzD~V@TI;2?PlH`jETc9 zEAi5T0K){{8s$>;2Ca4vWPo2QQPhen2YY1vXPnc5am#s{Bs=;0Sli*Tf*xDb}6MOI>_FK7}6P9(zJ(^i&v|%y~ zk%FLAT_2Gh78r%}&)yg)aEe81y#c{|*Z{O|B)Rgp7&7}*2M5x4d?sDqDmLKNNd!IG5|53;? z(S07da5`vXZu3*)A3*|Z>=#jORuWe016?^qFQXH$Y{yD zd^@C5AQoEpd=(iFA|)bz z`85Td`uN>y&l6iNn{7$S7fvXgyi7h;eB?i*aa0fU6%t2uL?mFI7K*1tFodU?Bu7u2 zji3~nC@f!n7V$0CrcvxXb$^CAS?K(8?BryXclm+G1Ya5okk1Qh=WKePx?)*;vJzJ7 zDd4bTHYJ*{Fo`(&)cXAPy41c2JFm8V9$3&jgWnevRM&4s+3FYq|K>$dX}kr^U14#Z z7Zg8QHS4SDwW^86<(u!n|A4l_Va$n@=e0lAfO8i6_*?sV#&W2d-tV6aqdFr7E`NkH z32_Jp=>qp>aoRr@1=u$2&LUHy1-t+UL+!pt&cS3i73r2<(0^B;TzZEgAEMx@=f@vY z^cc+4_t6GJ!dA9}NrU8r)DRCExS+1zpT=n7ksn_l2pv`zZ+at6Ty&~CjuGgE3_=Ey zcB&gEf2EP+{RWtfFfok5t-h&AVE*l-CH2l-Fr86Ko1%Zo1KAQ~BjM?Y}4w3oiha_ZqV=MZZPB+nTk`5}3qUqX~!Q!P=C2TXL~cU*m5 z_u89$NO}PVgT*ZD2O231zR%S?=%3)GiJ%1MXYvbXl;2(s?S;T>&ysuSZ z7na;V#v%`vZCQ(6&9%3&(FB&NfX%VGRf>$qavXjFr8ap_Zygn^jAMmPQevKOwTJ@q z8a)zA*p@l0SnROzQGJ@MwFqI%KQ9I!1_+;81NqHw(^sf20#opgK6a301b!lgY>_A< z{5i?CSzly|Kjn}*xlb#i;+(eX(KI}qaaXufSKTsCG6)G%{`(Mq^B(Y^@Y(bg5QxA) za{?_;yvAd5>>qAqOPd`ZGe*t%T!-NI9%a#IsC>%%u34o6N||k{s5dGqzI%ok=4x~=aG_4yUXZUg2z`DFh?!%R|b%p zf81rowfyi6Xe1*Hv+{qu6m{twMXlKD_=-Wx#rt_SWn8w}kNOO60HFhnMtfFAs5zmj|NAOs4X9UH9J9 ztwDi5(wSw4^y$0hFA?IaNWBd=64`bvPaaIR!Tz+me!@L=zX-wcToA)!Fvtm~2WAYn z@yFL;1Q<48X53!xaP>kZeIPl!{rYRm-p|oS+Vy*I+P3}u$uuFC(w&K-SZy{EnX?0! zlTTRyI|%REYV>krubAEWI&8Z91*S+68XtDqa2)nsORtQGix-JbxY}C@pMJ{F%7n>o zFOma!8&2@70>2j#r29o|y%t;2&Z|~E=7u&7H8oV{zR;JNy(@%cX+X>Fbd`WjUvAhU z)f$0ey=A<1B--jDOvr2jxJVebrn|f9{Q^4=l2n9OcWkKJ;vY4y0zbc|Ye~oJTopnZ zMh@b?D;-*aAzAxEUr4@xVJzP7T>T;Y=9iFX*S&jxP8FU@zLbnkN9Y~fdK85%W;Iu8 z#+z(nvObWZ=y^v&0b;V+k+U>ROVJ3%tex>29wT3X`!v7X%=&R)j zEYOn@TYH6ggjet0(ih1AUw<`+$yO|>si|3X6DjedO*pN+T4&w}{|Mih;7>elz9q38 zcG+16F>&fNc{h2U@RJ#F{J`HV@;ypECniH5zpKvw#;bejr}%LU#FphFX6S@pL?9el z65PLA{PDUJ zrnunfXuL;J=6$Ba}Hl zc-x%}EY7rsquzAuSo{PL8M2-$#C}K0w3DzNG_0bC9xx^H|$CH5AX$B z;>$(5@6f3cAF5CqP6!%TflyBYh6!o*w8Y{z-!ajY)$x})2dk>noz$i@pVTq_|+1ic8uZ#@+y%6qNVkTODys zv(sxLsU6kDf$GoiH%sqQ>>Bo#J>9vt(XXG{KHf~}IO)(*R&Z&{o12uIO?iIRmLF{M zn)To9k1WH!ZYP`RzVxz?sozCWFk&{Vr7HPV{UT-G&M|P7=$BZe!D72`Gn)D;u2zLk zvf?})gn{}*4BF>o7(s#YQn#AvA)3<-!1Tsf(M{r9j15NT1m>Y`^4je@J|M|!lb;-f zHs}#n$@Aj|cnw*P$10x;gT8AspphXFx?_`;!^z%4SLc0oDgLzq5(q=*ng_OYKTH1h z2#PDP^!v7Jv>Hk^?cMv!Lk8e-Rqz$6H)QM{LK=qx%FYsQDsA??X&(GVRbZgM^+}1o6#Xs1gXCFmp zk9@w}LGeGq)WM_QtfbZxi9v)E(?XXb!=j{%C`d4a#pC10_1@+SN6GKfz{{ClL;ICqtH%DZ&aNwM5Ep*u?8)=f@lJgC+6G%l!P!Cko4LvxNj^q-5 za+amqQPOw%Yj=sCk-_0V4!8(ZkUY6iAIfw?_lt*Sy+p_3CX|YhS?uRBg@SsL6zySg zUp!>bXF%1S_JlGl{r9t%roew(3fkI~uLrexxOGQZ>7};yvk^-D9)gp;W>8o;QHcys zy=uUrv8+19!E4vyr2Sm@&%wYN6pFQu)L)*^6swfoCJfR8o8>CL@V?-FAa<6uzEojHzpS=80nf@blv-6d42WEvesgTO4Ca2Pt+tcB)Lo@lvZ=&3A-w6f`TsC{%67!`R z#ir0kLvQ|$Q`rW>jj}K`N)bLqj3F@@>Yk%d9d3t<<`oxjcaC^BK#Li9^?%MBLSDfJ zCr=r6lLeAd`BdgJJr^~oi!c>+qrw9*+q!s9*OrdvE^f%$>gxKLLrLrH)rSm^>mKX* zQ~0Ejg<+8ct-8xlU$Lp-_N{XXX9~S^QqH&}(s%+2e_I(i9PTFphHK?^XC#vwo0gT#@=cJB-+vT9A zg7s7&O4UfO&B1H*8}HXelGN0X+%4a|_gD^pBy7*%h;Q+GMe|9;v_SRH`@@Os{H`Ly z*=-+6w_|UYo2*#q34X}4k7*(7xP>BKWjf~up4lE!C&&X_0?o|8QQBWV`LV+-`)x{s zS@-YFzorq5Z?D432t@_qJKNv5S6I{djpTj?Hk!oSR!;o{qPCeY6f2Lcm)#};v^J)$ zbxqD9UVh3x4sF(c(diP>@p%GztBh1X6s_W*I1QD7;dOe7`L!(HCU&HjSy z$Gi?)+{m+Y zEyoJl-O@%!h(f!TLpDfX3-ds4CZ57!e9%4_(Qc9c5nn}JO6-HeqP zC6BO(Fnh!o7xUZsoqlzpJZa)s;`w5F^D}XsvNFxX3E1zRWPSw(-al(q1U#-qf|{wN zOw-V<7)qm!w3&xZNO{DDPIvZdW~=YN5KX6dNWzW%&|?}JqZKx}BzA4EEp#Idd`U9$ z!)0N*^=>C7nWsE)jeAbdvKN?Q7>Dm&D~M8}Tw^)0KiFCR&%YCp-nkbZ!`$Hq<53kw z{9YPO*;%Gfnl!xyAx{tp&n^7@W3;og<7aBwM%qkeCU5S% z!WvxoMbs|XHadJ?+57PBpa?pT$BabtTp;moW7@;~7~4cGe>=KjGrzR(fSdB(B;+W2YoUmhMN&WueqnjeB_@zpT=br6j?I%AL8r9P+`-64{e_n_WnvS(Qo{Oz3aGpeqnP&tmNf8E@F0jJn5m$*iE;5E-64)g?9#9(7WN}X@e;r&@V^3gQu)2)u9 z>?1|nnbTZ^qM^qUTOor%TVVQH(734Je@G;R3*lK@6UEc2hd9ops(F3XM2^NxYTl_x zJ~A%=W~lH`gl6&T#`S@>12c7@P;xf^*=CF0eKq2cnVUOCY z;H8DqMW3n;6tqQ@V58TA0NN+gyd}IZ4kFlRmqd|trHuU4g=8d>fg|X_YXN)%)#dR8 z+}LDUTx73A@yDF!O=j+}5mA+2KgcHlNtXhD&nH-cKfIVuXr}0t9y8Bayx#B{@67Sh z*mMx??NcSJ)6W)T+2$NRwQCC{h*v#95yd7H#uGNE5b8yA{Nrkp+s6Z&KVw4S%B+xC zIxLenQ-fbgp_{^Y^E9Ut%x>B6G731JQ}tvU{;5PLE?t_Qq0=h-)Mz=By_4tp21O73 zLWXFAv`cI6b(6{N`SvQK@1aQ{cVzn7 zX8ZBM09bK59wbR9nVMmjO^a5{VTXZ7o&q=gZhQqilTR6kOvFt|1r!<=wvxm)|B_VU zs=lLUMc-vGeR@mMY}VvS+PLjKNLq62tJiJ9cd$yy{z%~Qw{!s+0}k2|6g&tTYEAgX z@87<@Jb0u88sY4*M%v(zq_-X)c+4WSm11;?h^n4KCI14gX$m0UKqtSuBmyM&7Ja5C zgD1VHVGU&i_w=IKK`h>`l0=J|pOZjf;p{MU*qipa)SZ#R>VyYs7Q!B7bQXtcvxFl~ zRBnSUZHeB?CndUyX0^p2la*D9JJ=Ftp!HcGI!i#Vp-qvZR)4B}-SwL_Ve~%+F(v&y z%DDKUEkEjOw;Y?@A?_;fClNi;;KnAyaIxkx!pg;~Ev0*~-qWX?koRvvT|;wjp@DmS;7mEUQA@hePtjBota%CG)%S_V#l za?QYl|YP8Y0dDb@VgqfPz}^=>8};_JswJO z>;^X35z_p(8mYSkdQkVnrV2jBOB9+a&jM|y_(C^yUO5#om$|$zHosp9S%d{TyM=po z$-b}6z<@17+B42H%8hL-G{jfTF*a|Sk{5)jLtDsggeC8U9dr*m(}2qHwff-UHx16b zS;o6$_^E(tX`E`?CZj{Sy#L(fQU3XeW=yJQ$7q@fhQQOVlNx^SxBNtF;+htgX85!T zT5ssb+ss>bm9`CgO(}Vo2tH`R3mp^EZjpo!#WwRlwbBc=-tN3ph8)m^b1U~cw&QnU z9|}Bws_>s5&h(zLss9tdcw_8%!)GNWpo2(?o5jV^iZv+IHs>%{PLH8CZy{OB{n(h= zBQE%yJcusF$SPrqG$o(U@=m+Rn4Aqe*i-@0UgkF?2#u%xr^OhM`o$fiwM$1Ls~UHo z2ve7`kOL>3vh%yj=j4l2zh&k?AJ#gOC-@UbDn&?Oz_A5!qC;GNfXSPdd~WEAETLDS z<&2Vgc(f{Mf7*mRHxhSxVgol*Hb`Yl|BF-vO9<7?K3OoCYLpcbO2aHI-fKPVuW%&Pni)oVi~i(me!wKOm|>yL;uEtzLmbpMHkPV?TD=sWFz;$fb_q|%jd1tu zf6=*+6epYWW1yO^_?+}^ykXV>ul?%ahU4z1-G(%SYxC0&!&Wgy$<%a7=(y=e4^`$5vG8cjA?89X zX)0I11R5o0rK9ZGQEdlCoiRB`GtrI&fgTwz`;7$QX=?znwmsu|Nr9z4$b;(Q%DvMp zYk#}QX3k20#}5**QbZAf9Rw>1?vLIZ7!+pcZl*P?N%Tk8TRhqO@kwsMKH}_31oYH4 zr1^->IBZ0n{AJ=-ntT8;UX0PUS`|0DJu5!r2uiweTo+2ZNP?pHj@-OS8b`4VrKXw% zNJp(qzFhLkKb6S}keP_NO6?oin(l17bsyj{SjURi@*?{U5{{`{R<^0ztuqW#_APgp z*NM(*lV;uFb-VJq5?^~L>FvIKa18ArKsDM5+T5nl9H-rt)uFBUa8{#~al{?=auaZusk-AVK?P5imaf4E01d2;X?P-0C8AW*{5{CID(sGmP>kD9R-WkGN zHY;ByP8E==?u(RLsa>t57pzGfY%oa9uUs7e1PNL1ew|-q5oH&P^eJmek83OdqqH!1 z4F_Ch;wdSb>U$2n2rcrS?r;9hMiZfPY@)z8Pfy^;zYGdDdGk}9q)(kI5Jpm13*7AR zYlY8A;ae5ZGCahw9y}yxpqTlBPzBg-zyJyXs2lAFR^q1$Aun?qd+cIBAT zholZs^Ae$E?h7*{$u#uw_=g1Ek2Y@B9qVL)HCb&Nw?>Kv5e4Cvx;sPb%}m-h1-0j^ z$nEK;%{^@6Cu;C_*fx}3^O|38_#M9SR^NY87G{E>&FU6zNjtoni)dWeht6JOE#BOl z>ciS!&@wIvX#dz`kil>kNkTocf~RjfwaQ$wUCX9^#ZU_RU}rR3D2%rTHTRee2lhp* z9;(lu>Myq#GqunK6>WM*f5oHhsg+JJdBc%Qo!npDa0tzGJen!fnGB!SQhB9y7)p4v zOgcrHgz5xRzjKeE-VD(kd63Fu3F8#`9a&S}gX1z-p4K1hsZ}%JH7c#B7%gYSLmLjG z>57>7nA&{TuUWe^W=T3y28cyu2l-2XlQ%b(OXV<8hsS5|NB_ckHLBj_xYtXulgn~q zuYC^Kbf<-HD-G4rgjZ{vL}8uwSsJnS5<5~8Z*gcRG~U0j(=LlyBAq%sNF334_y57$ z_NZ2FiWn2lK=tZB?HHW57)Xw+)AnPv@7sg3W`fyeg&hW_8;MHG5$iWkmR~9EIJD;j zSN1Wt<-ED3W}@~EcDG0bF)!8q#kgAVnTyZs`~@*OH#JwV1)4Iu!}5=328bG=+%ppw zxM$OH<@(g205l{#-Tw0pDo3IC1=mcKe>sS>#~Ahf=O-eN|D`l_9rLl*SF?M`%W>>V zD?DEes^DHs;3f#Fa_U~EKYKs#;qfb*{KbvS& z&9NPd7NY)1w#2As^-(8SHmIL!Rd!jCBe{tTKk=SGevyHq{bM5y3d)}DAHVhNvMs;_ za*!Us`v{qd2~!B#{ySU4ts@tCe#l)xPy3;B4%G|>f>2cSJeRGzzW1)!4|qd$`X#7YqQ@E>SkR?l0D_?Cw;U?}QwL6=qQS*U~X+)OXZ^Pm5r5cn=a z5dFKLxNzDm0iN(H6X3xxx57#jjmqAx`22I_DOIb|4&FfZ*AHjqx~AQ<)yLI_qG9i` z%bZ&cf47V;T1{Vv+${SAsb;@l_o=eH^D^co)YCIRrtFE3`5Tn|B>7m#JHQSp$|Wr; zPi1G;&~;YTNzz2S(MuGTpgISK*0b3yzuKYwgb{aEU+X<+C<-baW19%@;zs<|CF@9V zu;2M!%73Z_t&JrNmUDWy7cf^v-3n5qXvjs)TL^y^E>*^~x_4;PpZS}ld133G`)+6d zdeoFdc{2TNan6%qniQ(6cvqEXbNd#%=Q`MJ&V~BuJLCAxWk5-fYAbg~eTX(f4GZj7 z`tN=xtaKcZx?fc@Yt{5MXtATTa+;ttA7c4F}d1G#!HnQ4%wu|L zmB8$19yClcNpmSX@8gG_b-b_rC5QHHH0TdkvSPXKrQLqA@A9lWbII41P@QGc*VzBC zS&>A;Fs(ntyZ!$$_LgB)by3%_3JORZLILSgKwwSu+|R%7&wbsOdiGv1_gr($Ip!FK4%+pDt+tKGwWwyg-spAxb+bKH zwsjTdDCU<&j`?JZXh_Srlz(%2X**K|5bbvO%oBZVxQ>X!T#FGYY>@qX(&o&&{(y~- zH0XU5jK2<4FEm7Pf|GuiVD}Mnd7timiJxoeWeNN;{d)AtiB zTfROuqYT_3H1D|RNpxv>fCJU4-)cnWgvl(xc*Ur{0=(>raeu%^*2N&g%D=!(V7V8s zVBPJIV*hOu=qrBohvHAgC_~iVx%&dQz*s~wR$nx8lZ^h`F(k9dZp=QGyknojYV1IL zxGbBA*3%d)EEAHF(XL^Y+XBf`?lM+}evHt1K|s8=(d(j{KG=5Bx0N>>A3_Ai$^D}{ z7UYy4E;5gX+v}N4d_Y^q?L*v2ib-=@i;wG#85wlzMLTBiZO3qe#*bVKCKTTLUNEh(VTNVHFp`KE-%t{6I6Fh3u6mjdfygH zEtOJR>KJMCNnosVq|8SrG8z6+Tg~%>({5wyhC($fmB(MiC-65M5r6DplXJCQ_-0={ zEA35jGf;Ojz;avZF-&q462B*cX+)YpH&5EFK_11Z?rwZ=Karc+z?I>wEb(DI(3A< zwDtcqnZ_KPbj2Mr1}bXfWN(>`fPaPlIZ#!=G@)AC0U7O^)0sr=XG)Z;NYnVJL z=9D@b;oTWBZ{gC872A~r(EfvK(+MJofZn9Zl1g?)e#nW*&D~VMoyQT8YA)sS_jF6R zK6_HTbi}CEuknp{CsIZ{2}Qt|#(-$xa|%r)U$933s<5;AT1_I;GGQ0CsQ>J?Zve#c zp=G78;Ngcc59|rCNSUh3J#bYs&W~+GdLl4io5VCgHhBH3FN zJz@SOGU6;6k?dWaa*}wS-@`x^$rJ1$CcyHY3tS(AYjOyi%NpP+1);|?Q-+33<4)8@ z0#FChQ^D7pq+QPiU&8m$iEA{^{U(Di+>p*%ceZ}md+g*ijS2^8hnQ$x-Bx{;?;0Wx z`$ChCcH1BS&VEcBs3h*=N#xdLO2_> zM;}Xj(k5oA5Y%8(_;SrYpN1?(aimR1WT5)SNf6xZWjw0KV`!4-qca+rH^Bl9Q5g?U zR}_c=F0t+`h*8N>DTzfSyf5Ode>Ih8E}_PBy(zRdh=Jd7GT83>)xgx zzebvE4yY<1_m&7h5KgbxOXswRsurBRV@%g-oC1YhRbWa{M;aNh`utVvxStwfBvJ&f zN~H6`ey}mcSiNw4Z}^@D4W1@T@=3 zs^Hz2FUXfqHny@${+k4a2q=f3Y)RX4j1roK*KGMqnK|Dx(fSb*-fEJR+r__r7^e81 zq_=JA+S+Pwv4e9CMZexD(0$58Ymog9xptpE{39Qz(hljog+Bjc9YdEKWTNGJ(;HXt z9DD3|JFreGfw}c$aQ88k$x8r z#}Va*#aB)4gWKp0ywJT^%+l16Xm8h6wSpa>KVeV5haGgd z2bBc7aQtZ5FZA?CT;p>_J-O|~mjG6b{cqA9Aq=EUMkGBf6Z#(Z6@>1lqB>Q%+x=CQ zeJq+>(F6tyxvirJoEW`KhK{%kz?%V&9&qE)kspW>h-xRimw$pqk&^cdAFAc5K=6k) zXJ^gxEx1@0Z5W1GrW8E*`ZU*QcV64a>XaHKLX8&QH>5~Kbo?9l+VH^rtK_2opmS`%YHQsuMW4%ar$eQuhvnAfay!o2M}TqQC|GnGAqJ(D<>wM>8AVE2sN|e zjNEL1{6a)R9&aiWnR5c%N=qkYx zZZU3(=RW@o8JDt$&y~=P|KckUn_4y!1HG#4 zt%7q9@MDkMUh{j&x>}|MuKqeVv+a>oux1-4SnkTdI6mN`TnPf=dl>I2*#maE; z5>KkL2Jc}x3g7OYee#`;$kmMbI}Bu>PIsM{HfeJEcGz`8bf;dWWdA@HY8p3VEnd%- z{FR-)0d2FS9136^n|`0I)nO6HI)rc3zo)_+EaaYn1=neIEhY2QyT=p7KwbxTonC3H zrn|Qr5qeCx9+@n(7Hkf!)Knj-dV~V1UEE^f1Zi72;E?^FvG9*c;aGGV#vqXE_`M>P zJ%<<3_HgV7^j)!#YxWJ5>NnP)>3JbGpceP7TCq4MgmYAHdU5I<7z~oqKqjAUwl=lz zBOeU@<1of$YqOT3IHWOfBQ7Mr+(SK@p1+=?_a8ak8Hc5K&7{p*ak>}o!%`%0R>r%- z(n)pLf+=4qxUcL$YBW8M|HjZOi(2fs4G`=mhnvL?h}K}$W-pl%W`S44ddZ7UaOxu5@z4Y1AQniyP{>uthz~!HCW%Z zOFhNJ&p0$slHyu2%>QH=$SNP0XpP_P>Cd{I*<|y%SE0@G1r7%Pk-u;unwq_XU2)H1 zcEX!oh7ZR(vt(V{$rR;He(CsQ*Y0kE7-2_Q_#&9wHjG>nf0dDkN>lFlUgl_Dz3MBjd?8uuk``*5wo9LsgtfU9;B8q zDr6shBn@Wz5co-TDX#@Qzj)VDdAyE&OH7X_CJAfM#!OZ)}g_ zFN$Dj7CtLn(rE+b^<{&@>333)aDAd-d@Ofz`f&ONZOjc?P&LGYF<7nB_Yah39YfrW z$sHbaZwFXCa{$sNmDay_bcv=v|8f&hI8=%yy}*v6DflvTbS+0#Pi34R06by(s1i|XM)y+gr; z;ZJbkq3jua(ykBQwM?+RF!|wgnU%$~f(rywu>N2}-RUZcjw3>tMrz0lN-{Rn9=L;w z#bcC-QQF3pB3I%`^LrU2$-Edwi%54l5}>61&cUJoOBgILMpXwpqcFy% zu!|P(ZNYC5);<)5UAC9NX#9;XFond;@9igOvX_St)va7_=C#3h?6*t?3G23xXpgJ` zqObU~xlobX${J2%FPl#bT*+7uN)&}lz{3Pme`@%>MoHJLCUUM=L`BbnZH<;`^~Ug_ zDpAqNJy^U4MAecuLRQzhAxZP@T_Xxb!md^=V{M+b^rew#N(LK`CJ@(XxpWbW&=+E% zgJSyUt6Q33+-V1Y**1{p*=$0Yy6&1mZ4GK z$($EvJ$*)+xttjS;>l-o@!OlU%dd~8Pn?rcb!&p&LMtn0aVwZ??`>1t%3l1nLU;8_ z_vZudFa#;52AK$FA4BB%y~pKLDPZ>=(~H*fshZixugsj4NZ250rdC0|RvmK7DsIPa zT!)=e`e3udhe;DtaQzJ2w`;LjeNM*LHa9=}%Tu5ZRIvMl4*Dqu+q+cL-f8@Mo`tC? zDX*-pi`&i=46CQO2T=!@TAnllo8)qMV_yD7V-v(GM0?k8bK1KY&30=G&>EDCpXI8@ zdF49`MNyg4WUy*8295U1t{vED>L1Mw16D&H>(iewwPtS(Qnw?ue3YJ-Wt?Q9`heAv zDWKnll1jb1oY9}s)3%bqU+Xy5cD^nTlO9l2F${9yK)*IC#JD_!Z37XlsJNFs=tMZN zAD&>jG_v9pQklJPwJ|~0*CeH{t{;f_P*?C|$_2sI)0`ObGWeulpZ?olo=mK>ge!Z^TE}_vJME?+==U?h;=B z$PvjF-Kr>DGxYVomKPf6T~Y%Xkc*>FCR(mQGY>`F3XQ`U-HM=&r83c0&wr*iQ~z1t zL9lfL?4c{L+RyHV)voNaqA|fD-Od;G5U!_J6zw&kn-?3;HdsYaQQvAI1-b)-jR-UP zI&~?iE1A9Oc5XpJ!CJ)#<=t2&PAt;hEg!M5_sGFPK6=WF3Mu0V&mk0jd9{_$==nsO zKR8;*wwTX&8JyUM5l@whn2)bhh+M}FYm(ZQvNc}}=Ok&C`Mw$CB!JY0s)W8m)k1v} zIt?H&fu)Rvpb_{X=mN1Ppwth~Iws4!ol%GqMlGY3L`jo)MWU=fQRk%YgYCNQovMhP zQ4~w^PF+zI#`LW3%BkH47t1GOf|}~rk}Q5{3%Z4 z7gEcM<|WfHwQ9L^>g%$#TIO_1<)nI~t~|RxM(o7qu?du&)W`m0F36I2VOk#V?NKFM zkJvTa*OESf9R2#_r)hY-^u$x=AlA=YG~HotEFDI2T|A)sJtxU+H3dRSFf8+IiVRi) zLW^ebEty=M497B%OMJyYtc_d!Zn0)N0-M|*_fel?UGY0A4psC>_lDY@kC(TceHGr+ zTr6cjfc_=GbNS(`=e;)sC-vt;{SC4CB~+~-^W;$JJOx>rAV{9nyR2(WyF7Hm%18YOyQXCmsjNs2X?hWt6i=x5K;>p;a>V`JkGd%!U zF-3s`XTkJS1XoU<gXEF1;&#L?z zw=bNgeuRJv``_MyyC7}Is`%)D<8s6Z>f+9wRk$-v`Z5hLrU zCJwn?-B7%%_g(00Gs9}q-eQs+b94YH1l@wl&jW|YQ}?1l0WCF!TRsEBez%M)HY7;hL=N!2~O>SKlv zBBdvLV&jXM8O1`=PUah~!d?3s<@25iQv#HeEt?t9@?pYpj$NrepYh+L(-2EBPAv=m z-Uk>nY*?r@`KyWX=hsofSMJrX^kg?~2<3vgf0ue}{ry~r3+)QVR0A~<5ai*Az+ovf zD0vMcTo4ensm^+HUZE*68X}*%6{Y4x8Ntbi+Ov*RB`V`cS$4lft;yM)6`$L*GZ(R< zUl*v63a7eEs&R(rl~7Jz8rqkoEkB|n41VPn_eW8@%%-|>Fy_y&L89h1^P207Aio>u zw+e=%JII^~#b{f(y%oGp>xCN`UW&|p9&iYPu;7*VO-GHT1zlmi*~(FY?bE{jpdKm7 z?T>1Tth#lmF#dAyp^v#@c~JK~4Q9`yaI|diSIDM|Nv?<)HDdfkK5U_-x!ub#;+c`0;X^ZY~ zp+0lpV(>-b`#~|=`W>nw)*)aKVYFmsyIdY~Ceea?t+Jqll|3V1rF`bb3I7Qd%_fu~E`Zr0_bJvWNv;)Tnm!b$O# z#+Aa3Q`g$CXGP0!PQ&JB#>vY~?&l#&cgkZP$6BKs-(kfNBMgDoZoLAH8pY7c9w+6S z33wIWpDku^Z~bO~vkf0oR-SwZR&-$Yd;ceT8anJQ(5k~%27$1?6cCed#uoV(;A|K5 zY0gia$)$6sn7!0Hir!Gqe5&i)8gIjHcfJDyl?4uKak{_lHdJMcrNjJSfyq1%B6UBV zO?OY96w)7%DSuD=KDISR<}Qhu!f##dSs^f-!(+RXU@Zi6QPp%vz?bwK&FW4g%0X~Y ze^*2uVcldUMtN;9<9q)Zz`tkV!0zei^!AKNe{+u_)JQrHWpOD;gh5Vlw|F)8_@NcU z?Ae#Qfd@cz^+^6bi?=0qlM1>$2jn;QxX4SxZrFWfN0KFCP$3L~Fs;7>!0;lFf(Jz{ z(NPnvl+cD5`23|;(R(-i9=SjEJ2d_QQyJzW=5g`_;mIP5zCobK^|lnHgf2fM1;h+L5hO|J!Rr7K z2~B4I!(zQptrikqFoQp$jSqc^>;js)^K;oigPHHsy9k6>%^LtmDT+*;%VwbwbZ37H z02B$&Anmmhrh*38Ay3I*e@1OD6mz&E<{FkCbFTYaLqXnr+G=)B*Iw00qb(=#fGs@7 zr_|85{L)70CnzWA-zFr3X$K&@$ehUesMa`X*i)dX)xCi-=V=MjmMRksWg)koQzt(2 z5&yU#$*!Hd;RzZdpURcD&*t-exk;Wjs)VxjYD24bJ)JR|gGO+Vo8DgX>e1P+(Eb@q zOV$?XDFMSbh7Wb$_0QZmeSWUM!r|?8M|DyL>PXjzQk(}JoQ+8m`-WGlZNn_@%zZu} zgL|2YsiV6*2rz|LuR^mVKC@l#?B zn5NZ+zMGR>0NnLwSJ;OVItnwLvPxwRh)Zi<1r4C9t3?95piTn{kV4QvVmT3-h{fzO zAmrQbs4io=a6v=V}`d1%_)GE+@UWlIK=J{OoaoM^@CT#W@@8MyGJ_vRtoHhwW{UHIc7 zynsW?H569CI*wY~Z@i9aiYy|)EtBE4aPhJrmFfy)<(}ni#k;Ky%IVvteJv%7uWdkf zAQU_8Q}X2ylseFYq6FpwbZZ2Zn2Zk%E= zrBH51%Fp;{KrH=`a2>bR7Z|VEdY=2UCYXQOp=GN_y@A zeYxwy#fk~G4WXmf&q@wvcO1XxXpOLLtGU@XMs1O{#pk#e9tZ`4yDio2N7}7i4rxV| z9U#>YufUg!_mk(X5qs4ImFlQQA0n!+8M}Bl?a{DAIdEYURJ`D+g6XkH0;uF1ddcyN zB_M((6VjYSOMM}v=kJTYR7;NKsF)RT0YAFJ;r@lPu+?#9FI23%S=tkWf7`D1nT*T$VrSXMV4s&W|axBCAtNDsK zM6Opy2XC44ZTAd7ux~RVP53*#EE0k7|2lmBUSM3CvLp$gCEU24^r|s_FS5(`EM#_E ziS|;F*`(?1udBW&QtK#~60XUV_K01htB2QD4h&FE5V>u%XMpW5g}8SQg@K6POufcj z6Pbu6PN6H4@c#-)q{jOz;dZKS z@FU*p1g!bZzUq5d{$f>d?drO2OW#u~U0M~)i$b`)nKcWG)+{g^MNPc#(yjX0wrMDzj$D#(L#VsvEVLDYF$WMp0AGMz>2#?v8>S<@3 zngfDG*x{IxCeUs9v1L@~g28{%$T*2wS0ou3cKSD4EX1`5(lIkLBOke~@{u*dpN}G+ z6x34v)osg@IPU?fuW{DUv;C{j==@<;gvO=tcS-Y?jw_01^9RSDlX1FHP&>J~T0rw% zDaQ;bjMe&(f5|NTQ@!e5{YY5FTt&RiQhpf_XqoE#x`zxi3L(umsr!s=3U=XTpe+W= zsu#QWOP)b^AD4R}0i#Z?T3e}3t?cA1VCtQIp%3E?rtC>aHO%cq;t_sX<@~xix3h~Y zjlINcOXgg_a^yu}>&{^D$Bj>;7l4d8#QkfD$_Ge77b;SA+-Fbe($-}|x&k*&Cpn!VZ3Do<^Czqs{1nVl8mtP5;7m%wbre30oV#ir$kGA6xQhZSh@9PT~=-6%6(`2%0=cD$rT*I)aUZW=G^s zos7pRfQCqjdvCd`BBF|ds%73JNmCh#KA=Cy0TANkF*%@FUGS(f*{Uex8SYVteD*9t z!6G5lwVCNlfS0X zOH9J|AI{N|;}c-+XTV)u=%d)ac&%G-ApBZlXG2&T3)XN>{1|6RE`i}^#;)Ucf-iSb zt_#g@$nFb^M84U7-nW$fph`cmep^aJ;W^uWO7nPmnV#{)hY@Iz8lF$T$@tK<#*P{m zt934}7`cEFqZeGJdV+@o7Cn^>vfY1(q(JHVIn@HjK!?UbrG}6`D^6YXr1+iM=or9YjC8`!(jyk_L9Pg5FvvQBFT0`Ez zyEc7(Gm!3_P$SaPy8c+h@Ne8SVT@;pN5kH5&S^Sz)VQ(E=u*#p(W@V3c^93FQhb?8 zvrNw7)=<9SwVz_&SsDIy59dA%-AofW5vta}h>>d|W3|8@qXDosB^7r6MadeVjFUk@ z9YoS)^(N7)4&M(IvqS*qqR<%rI*bFba?WWiz#34a2kv$fvu@*n&oAddy=xPtLb0^ncI-P>5 zJV>@DamGCY80#vmDkX}QKurvT`r%i5*ptr7j{ds!+(>G;6u~D$>?6NmzDt5`#C!I8kHm&j5&G?J}T7K2nI7xTcUVVYo4^TVG zs7A9gF#pm#Pv6B2q7|-{Amm~sdXqpzFqF^ZbM6dxAaQ^b;xzMh3yAufXk`dMwF$fQ zrun38Z|_1h6a)s>1aLVHdWu5s_6pg8gs$R`M(~}~k@2lvK{ms3`-WrFR;HrgrsOS6 zg&Xmm5y@rDVq`p0r9RwW{U)D$#-SybNzLu6XmK30wliwo%E?S2Le78{Wcum=aF{V; zO3&iB)M<#V(SDSXcJfXIk@k}=y|Y}_1XyREh#!juknwE!%qNndCPwW}0&NsS5LmnQBWaqeP}hJpvnSNqQcBBql@qHJoCri zj7gCf%Ge&TlRxxtmo{HexoU|!kB1T_xV1TKgu(W`d8E{q8djoiNmAt=L>O(r?T@>r zt2lzyaiLU6`Y)B6b17OTjyYB$-`zkGVu)g&^e+$ZJYORH`XZ@EjB#szvgST#mq6A1 z7J&w`y>rt@wF1Uh!fk~-5cTy~kRK9=4}!XDqhu3qO_biy`#c@EgD}^bcew$8iNTd= zx0+&!9QS-F?1mi zDbOK}zeJc1O_GXN(gZAGpQ+Z_rSHk}tOuD8%HZDebmJs}X4zo4KkE>+AA?rC>URX9 zRYUlX$DxO(7`rTJn!z{-?FI50uSPNizw3BUky$a5bV=jhQjvzCUfr{*A;#?z_>1X_ zx!N42&KX zZzeO{A?CIp^~-*C#vy1gewH08&e;WBzCV^_f|~@$AG7P02-l;z+c}CNVtbZYcVd!4 z4}t?DNasI#h{SAD$e>wW&h@6MR3f?_+_&iR52UC=t%lzvVT2Zt@i=5@hf88ZY5`om zG&`#d^BUCUktj~@JW;5uvj z%6MjunSX2gV%F7gR#-lgjZTc%*ZqXxpf2E}CrD<73yc{}CHoM&V2I7|%LLGtQx!hd z4JipfjMp6Co(oMDw7GRS-4O!3*S*1R3NmlDNk)&WP^~;3J2Gq;h+yiGS<#1gLN^Ft zffu=_i}uicB|Vb~tBqVa0v1k#;UbV+L>gT1o?&C(|jFf@a&jN;-a zP^{kGguV38sh09Jzj$*!>GWi;i$DobmUkx?`P$9Av$Lb47xD&LXmL%2h{!f#@h#2K zEs``X!ebJ4DkM{fdh!pifKU)6+B;$#J86h8oLjAmlgc0d>`f6!^a&ScMZxkUy@>?J zB2kR-Hm-JjtMM`9t>K>&JU|XKnZiWN;3gdT$iQ@Ws}F(r44)OgKH^;P$!%4$w>T(8 z%6>81;$rH@Ojmus#%&J04qz5u1C~fweLLKCQOknaNDyj3^akSq54y)=vW%}R1GwT~ zL)6u=`VKpS`MK;=zLf5iG2D7yRR#oK(5ynurj-CUSeTqLH3A3{sgU`!PtzyGKxhl$ zZPfscMlCA?1j=sK6jwiu4ik|dtQtg$d^^?T*HUiSN{N4G4SS;s^fr2lJP}nxF6jdm zU;!xhgb|rW1T6bl6(C*xXZYoel_8ule39~-a3J6(hP%G!wEo+$)gz#2KU4uED0wsU z{Xk~oT(aiNcTyDDze)yu6`mgXL4eI+j?%c?XKy#(*}4ML1zDJq$##GZ<{`ox^jJWQP;f0m6Waiv_a_V={kS%6l9K3~Hu-uL|2R^icD2EN?$hQHxW^ zFV`Ldo%FG9%7u%BoQ^Cw|6U3wXG0k&3a<1e3bawDX1d+7Tv(`Dv&v?ZNb_vXjEQ|sGgrP@ zigErrr|aD9Pv|sV;t-gQ2=`le6n9UP(O29rJJWqhT`f+i+Mq?Q)bEU-P&1?E`UDwEf>N1@7Oa6mw6>;J~s3JW1uf3t#aaJejQv7q5_UI>43GZxb4M)P?m-0Cg>XQ>APEXT1CO51^14yFs(S3Q z>Ikb1qJ8&ioMtd4alRVNcD`l$qj-o3VbSB;GvLW;gfPPdQfE#`2J6%P&L`Mm=(#bS z8-IEKJLvq00ze?;Is8sK?tZec*>GCX*w*`-dyoK2q}u zD=?lg|Jze7;s7}MBc#WGnI*x~!>6XkRc^A}ED2?E@#G+JD^*$WDuV#q3c52v{+k$= z>{7&=ik{0c%IMO(v;mOLg8c~>SRw@I_S-xR?_Enj2er<{_iH-Z6?RX1IDX257H2r` z`S>R}c^SC&-Q@N6&gFO@(pPcQCM!+d$r?cudAky60UZy*wpgd! z4{YszwS;ACK3J3^J{(I9!HFwT#E&HCwScA^kwgL7*uo~y}*e_gCK`KEVyRQ3@dgOgJ z+-cB6@(iq)#%&m0x|KT71YE_~z_xdV}^M z%#dF|uuG#RX_T?Vr~a73hQ{mFxAhLz5<&-z6~YA0e`bG+H+APjl6bfY!V5wP9vCZNA{i;k2|ZZ zo@Bz&iRkKwgxQM$VwDyr&_apQR{;a?f2@C&6~%4F_gwQ=T@@f=p*i0}jx~K>|G+O` zxi{b-DyJ+bPBk-L6)UYT`08ngZ5rj=2^0mQzb6|aMpf%u<0V3iqp7pgs^csf@~ z%1w(A_vzVdiVpYvaaVYKL7Jw3&HZwsDF+9T(EU@vmKi$C1(zt0B4OFINc@ zK*q3cJzq1yEkao950GGL)dQ9={k4C24_r7D-zSxE+cLM$)8k{!qq+wm3SLDbdL5a@gr5byfRM<#na z^_{(2lI(Ui?0Bb%!u?3qrdQDSleR3u%@*O4Mi`2a+@seKPcuNFX}vQu_n zz5?`9&O|Z$i4s9W&ABgkiW!m6l6MB>_xv~g0G;<)g-NB()+YHW>ISx zlrS=obj5)ljHdpEar1%wL)8t`TNjPypBn2vvse7MQr#$qSS2Qe0` z5FIoJW-%X^%tG5eS*P!0DBB-~Aa8|fwk!oB+e2gsE;9^^o} z1p-yWTa%{g@3G~!E+7qpD;f&=!T=TSt zaEkvvdGs|Qx1(p0@1qY#Ta$ov@4r9rz5T0IBA#48t@^pib>{=#7u$&vZNxPG^E!eV znY3s5e?&%adYl`W#=jG;N%i7jhFQsUvhQ^|^d6-PKb6^DEI%g40m7oAv6s(rp3KnJaWYGA(l|C!evq2*Vs@P6b}E?ZT+ zXY$G*i$4~%R;FL4Vgk9S({bA}EkNQ6RS>cav@4d1CgXefe}*mnWQRr(Z!8*$VDX)C zTkxsHdlG#4v;J~jyr7!5WR7cdwW_PxS`(oj=w$le7hBpaQY$_li*9;Pw+TuWsN zRbvf&YlPSEa}Am zXElk?ZjAsNDC?>N1&-ei(z}m0T~pqG7j+r(c}NO zs4>e(T??oozyK?B zh??j1)pgnD5BgERsEE_{5SH$P)f-7%z>NKWe)jk@bj(y^phoN%A&Nb(CosO*V9Oy! zgqL>HBs(bn-=*(CQe1vzX=(X$cna*WJWA~wgk1_T`&=BWr*hkKC5Hd+fUreB1i0cB zpz*P~{n6Wr09w&?Uv_%&3%crXb`WbgA{R|22y_^?j_y1@VzM3T@J*Q=gbN(><4(zLr4O`i$O*NW)VBtTy{o#-r~G9 zp-@{}n|!-7s^r*540w8(F286BkecwD*G3=13IqJU)XlnHR2^^4s7F3wm#nR?Po)OZ zyok;JASrWE5WXp;&QgR$QaQDjf1u>RXG8pRu_9!JY~w!rIv(QRK?6R$(6oa8e3Qy# zbzZ*CM>?#svpiP*>iWdV3%2qV*q>CZ*v<2#JLoLoV8E!zWRyL*d{aBWR)TpE3t_!s zSfZA-*dh<8um0J9=~v{CAEf=%J}bF-iW_f#aoPWEMQDm`hL%Y#b^_j(C;AGv4;`l8 zyg;l%7!d1$kv~gf_^}2Spo=EX@O1K-j{!@75MnOUxS+mc-CF6TW-qvuJ(#QqXv+Y^Z?_B<Sb(Br z1fh!SgWV&Sf-xROG3TS~0LkCZ)W6AdikGDO#@zmGy^Y%F9Y$&TH0(@FV;wQ zyIn^R7d`!+!IV#)oeb)ZS4%%_n{Cy>mw01TiRnVBnFK>6(NB(V+*jv2k`V=kH4bBh zTJnU+0yU*PRpy!;F!Y zPiD*8u9&mbbQ#Qhkv2S+GY!NmC+Ou}XB^Gp^F}~#U{YoE-(IcKS?&Te3jG91_b~Fu z3)A-Yz>})%Yu@nrUmSRxh|dWFGyj| zGhAONo6b+Ehn45tPCp6>R{$b_w^UY$`CyA0XXTb7W{zVvl$7oF(!1#b%WCH`JRRXl zouY~JN6@L>$28v@vXS5O6;fYi3a!zWB7D=BjNGj8m>;L6Pvh?7;hF!^ukY#nlW7XK z&y{BU$l(G;OVfMfNkaaQC)vEj`?is1t+}p21BO6ED1H~v1M6@3S4X9;I`@xWV)8aE zL9bVj`JF9Zo2fz`M!t&ao{6lxcRaMx%8c1RSe#hEB=nq5tIOt#@z@1kMSva#G_=%Bp5R1~uavx5|4<2; z7YK(qN61qlAhYNPnI74!P#DCfkMs@eP=R;5Y`DzKuc)m_Nf~L?pF|rciN75g+0CEr zp)R_48y5&Uf1JSQQa!iO?&uGz>s-1n6|qCxkIqFyGP-idrKO~9-Xl$|Hrfjuhl-|T zG+C+NqwVUA4Y0`^Hhb5z)hm6nd32UG@t%$aSEpCp?K!hO7*{use}*vVlZ*15*7mV5 z+2ZK$sov#$+h0Gscs|yHr1U#ue=Mo zxJst!`F$OsZfPzy=qp)R%coc-ey2Ur&KF5P$=NRu-yO{Y#fBsJypG`T)mU?W(%hPD z!ngk9E!TTdzhPv8p1&6#K7ib~oER$A(H6vOh!7x^P9oSKXfmb}^{k#vGu_I0! zEku{2Vr$Z923Hj4LlpMQn-^qG>1=>Q%b8Eya=H#!cCPDOqkv)P#D@Ts;_+h5)EBn_ zvUD507@hfqEzhd9m|N6HD@Hm(VKi*GK=W6Gax=!GT3viD)9o@#Z1CXbTso*3@Hkzt1(pe;L z7%>3;UaQMA%%VQ7<9(}fFY?A!Xzwv!RckOj_BnDqd(%v)@x{rtn-9j&<;}co*gc)k z=*wEqy{9*!xsSWbEHV~i3p}T*-mJrJoF;Z0v#ciVT8WT+YgzE_U+4)gzJ=wSIFuc}a+azxs+plME`{tcdOa8QRNB%ET;8tfx9J}rv z@e%Cwz%$TB1wGk9I^l=jyww+8EqCbh2XKe!RGURMo+Ca8%D~m=xH1KBqz$nGL^$KQ z@SG1yt?N|}m?Ey(Mk#(k^^>)-bAtf2nW&mzq*-<55`E`Rh;uVIaiEROh!u*%M5wI- z#h}vNu|5p`ftz8Xskeu&{`ezH-5 zHvy#O3rSBbygK~v-^P}?^Zn$oehC4D^t0l3I@e{$i0Yi%RHc|&DE#z-wwRc?t*;Tn z_(V+6G3^3SfF&0rwij5^)ve9pHYhH7QKsVZa;X&!)P+4PVXKMf+hx(Lp8p?L?;S{W|Nf6x$|y5J_KH+iMh790 zQAQ|AMhMxCajdM!cI?QAjO@*^$;dH6_Bi%lhwRPo`O)%Te`}S}AM^$UFl~Vrhs$CdEy9kML?Kw{I!04p?ygP_tvWZjUAIa)n%0&h4-PhU#G+Yh1l%Ax<7sb9lq z)LVIJWfv?SUgRf=EoKOzxAL10@w!f&jEofMqmw2WaFswjq0VVh3+lSx+_OCOdb3)qTf> z8V)Ph3G5L^$#3s}G5$JS7=qO*oe(8--4M||@$ecE&)d#sAU2iw-XDVS683;9B@J-+}{J|hw}LYI5gXr0_Wz(%?|hWOJqGb<&EQ)y7D}GZ4l#JK}t4 zBG@aJ4{oxgo>`P>ikoUMKITLja}+BL9{16ZD{nwqf>m+&(sP$_NA+`c%2hz9>HqIr8C z`HE{M!TNd8tqhCmC&#U%L+P#F z)!mP`q{7AHPfpY(>)(3QoHaEuvT2oK@jgY9LWpkKuLS8bjs8;iP-gEU`7`~G@=!o* z!ikTxR-YEXwvg7Id2_%>QEM_DpN~`2@r)66Bzc$i^urIQhD5S`wU40!Wa-?$n)9{( z*p{e|$fD{!=kBl9s`_Z~Ous7)JHZNBL|}zf=WSx@zp{_ZmZK3YK~Zivj%FS_wCh!x z!Nt0*%kP2;CQ>4&MhqD9TN5etIWL`b)d=owtmMzI@7SV93Rj*UN(!h!_=d@4DO18u z#5{$DuFEgRht+90Q+COYp+CNx7gkwwknt13Nh}MMdGE~TwNu5%YT`9qnuBis6X4Zn zGr1HZeF?U-lsYol$r+qeGK8n}P6)}h*T(zaBswT~$jhl0(EC8YE|FYeSF-XV&oo=^ ztX6TDLHUS{irLYl!xdM?s6Q_2l72;2)NJ}U7TA&ae=?Ft^g1i3;5moFk2e;spk}&) zG{?)fJJ=Q8^dD*v3=i%Ye@q>$PrSu#t(2B8nPGR2DN$q4;VIIv4qcwd!<_0E+58C# zaDoW&7QRMYQ1kEHhZSk7^xSR~8WfiwjtflB5)*&3cFp}g1W!wQdwP=BQ>xag<0=73 zp@cTN?sMD1YMY;s>^EH2x>p@aC@;_JBQ$h3n?_=&Ig=85Ot5antGN>My>+{QG^ZHN+_2zv?NuT-!HhPpA*?kUQu zMzRK&g|QWiNZUZyEWI)V#&$CVg|ikK)fK0O6B9W_=a`aymmc#Z^mK?*F_l}P?a%U) zW#`P&T+PmCst@1Ow2zJnb}Jr>nHNjUNJ_*djT9CHS>&0qoD{6!l$h+vio3tpZA+H! zB7eLozf_e7kk_ZTVAO;&uh?X^F8J^f_odZm%5|i+?ZQ=hB#9PqPHu|WWeBT5a3-@E zP)pk*!|U1>W`xun4};L(&rI`{ixjC`l{O5%l3u5~8KTvBPx@t`K`vRm zwqu=RzV)tC!lr!0d?COz6ka{9Y#_8=Z3IpC?T(vajkKS&<{`AAgBDnc1<0+ONXCx}`(nh&-5FtOAZ)Xpo+!jf#}A0RX4KAfh(L3ByVPH^*e)$X?n zY|ae(k}bM5jex*cT8ee^dPO?fPXeh5SbF39$4>HTCd89McEwmUV2@Slp6)?e?>2>_ z0J#;Ba7@LWN#DYz^R_Pv;tQ@evbQ6PDAf6EDzMKy zx_Rz)cG#leN~=R2P*mOaLH(SzQ*yC=)kwCMMKxd<_rguO9KbVEpzr>Bu-<|3a3bN9 zd#$=>tJl-j_;c!C-`hh_vm_}WPrat^?&XE$?=cqK!ppF*h8a|4TVSl|N{G@+&0I!( z_AbbZ9Qwr%VFd1_+#v}qSF`#scP+6O z+mH;)C|u`39xBPcLEVaKblzF@&%z)u%Lc!o+8yFbQ{iF$-l2i}0rLk+=|-=-dezsk z){m-|%L%)?xqSskZ2R-0>o3x?U44jkJA6ISwVr$Q0Kz!`pnntdr-v|TD_mn3Zc2%B z%r-uGp8-`G>c4I;RQfPa55Girfht`q{kBOJz4Y^{U4P8Ln8<7F;g`*jcF1yp0v{%{ z8BA-qdFVFuKd9FjD^|gr9IS2sk=o`NMoI5pI$5T99iy~Dqratj{I>o55X8A|*=` z@_Bnw4if~MW2qf0Vz$i8r3Ra|MVSSt^V-qGCxO5E|Djer!j+Uj+2C^_#AceSk#ogn zz()}Fz1xzs(L10tmDY318C2re{VxY%zPZkN>h@ySz_9qgwDV8n#oyl!Ps=9UKeU6x zV(Mr8+2z6JV}ShmFe*WQMj8p_9ms$@AvmkTrs|+6Oc`F6eodK6w#DEycwj&s`ZQ7H ze;Tgs?BV7+%|Lg*yG{T&+$V`gpSn9_KmuXlxZIylnpIMB+E}~9_O#G0)Vyy!YJq(? zIOqcjoEy~3CQoM+L3J-c=$J}wMZ3fmI^O`!mcF$(>m3>;L+Z_EgRv+aiyvXZZihE} zyvuiq%#6>WJ3MP zQ(_;O()v)ax*^{w{9ep8R>t-Br&IB{ZI;g}nkQ#l7$N&L7lR!xPB*o(dXRYGv7F%M zYSQNoHj8O-Uu)Imnre}x?68F{E!7s`Z(gyaswDp`n!>S!+=`z3ihjeR=tk66AHT(^ z37Vv%S;17?LXM{;950%LsuD7A(XbKhKjq#znIi{(1-Pf>?iAnJi3G&9FgOtLJ`{B0 zqunjNt68*7;Q?*Lrq=f`>#~GMqiP<^6dhZSh`cDok4ONLI{hq?iEaI!R{3*!coP}@ z1fO)Y{@7eWZd3L`C6qS5-=ZtbkYLjiYnSnN0t@IIf(0HFdaWbcg==N z%Se}T=|Nsiv}Pykqc<7Xp5u{q4B;8RN3SI^C0<+SvtE7r!r6VdR%N{LFA~>vos6hF>0^8LmR}rUww&Q$JY0I`)yL zPom_ZzJokXe7zg_E%iVoYU}mUTn(`qi4Oep@`xer*e=v7JOB2ZUCaI1qH8B=Zt&pV z%rB9{DqZ@10(rN51?Xyvc;cIOeo0{OZ=-pl@W$iJ5}k)VYT8a{#6OgS!h4nq_U(_8 zk3riC;U_P(S_hOtJ0e_PB0AzZU97b;f%V5>C4S7st4&{)?SsC#(%~72@>nde(wXj} zo=(>Iv3ACN#aUNGRnU3ZR42VyF^JhBN!4B#ruhA}>tJjrM zGB>82$KQtS@`%TSnKVv2)J{8+MA7}!No5@0``GmfmV~tpGK|C+KI$YmH1^t?8RW^q ztm__LYUEq(qOL7d1^EH~oJI|LPt5fxUma)3)AcsxSwXE)PN?!*?!?o;iAbdzaoIkU zu7CG5536Dh2-p7fs%W*K|GE`ybs!*XObqg>jIUm!1hv=>Z|bb|6Q&eGC2gxdK9=t_ zoffc9SP^(!LNe?7t7NctZ6!zQ!@#|%5gyA%>FBBlI|JwhUcHad+oL_;cA`)E2y2-9 zK{0tR;zY}DrX8V#X+cC66Qb*j2Aezs3@^49DRaraaYH`AgsuF{9}O{ejodXAK6^A$ z+9gYRyc=OVZSQ?`Xnu@g7f_?uwN4_sXyXfYIBcG0)vUuNycjpd|11z4P6@)V9=WPl zm*;(nyyEZH%y*Zb1oPIL^g3SJ280l3C?9SP*SWik6@-YtbBCC^+!((42Tw<$qDPQH zKKz&}?O#e;o?88RA}SV*;q844iClZGfG_=inebN~DGGgZr64 zSZsYT&Fgi*Y;Vq?UV75B@kxU!58J;BXFj@Yzeq3yw$X0296gWQoZE|KgP|>wtOOpI z)~&-q!|{{f;%z6L{;S4T4pB~FB0^ES+1s^~O=Z2$C;Mp$)_irVq7GT)=;N4>05yfc(p>em-2oNhLPaX34!=6~T^N{rd&qv-x{ zBo0y=W=$3xGU9lk1D zYa}dt`n^|0XvvNDn81X#9|+2kOzw~0mow(yZb`Ac%zolnwfQWCjxy5JmC*Lovt-4Y zq=+bA=NQ!rKR)!d;Kgj*Jl`63cE$or$S>C+A{+-$V9cC;~BHH@@QR&I%k z=3Zov<>(@tBLGxmy7lMwZ6yL0-wCLRU7*;rO2O2^6@1%FhhI6Ls8 zU2MC&56I=SKERKqF;NGxS0Efy6tf1Ouza+@L-d#kCsWh4T))WB^u=cXeV*j%NY7n1mcEsHP4L-r z-qjgwprRn&n_KU6W44v!e-@Y`N0Kftv7+RwBs(QMiq)3o&gQ5Qnpa_Wy7Ayzm8WzU zb_Ji%$7su#Q?Jgb%+8jK2h)?AcQnywm-oJgd%g|Lj z9zK0#oqmFL`^Ju;Zng6f)1c;ZQtb!zf_p7TsCM&IB0xHL^*DwDMBn5g`xven>gCi? z9SFq{qJvBeSpmA=dCn#yY3ZlW_i_Q}U<&RF{(DS@4M6)hD>GAmqD*N(Z@*3IrgzgX0Y0gFtDv1k!I z2S(qY&s8n$iioyB=J=Cy#GW_SQ_efAxgjhIDe1}^%+K(phR=O=E zQTO!qlhx9vod{~w@VZ22E9n{3WKt4c%fWmF_ip`5R)^k>+=jYvV8nR0N_-Y09q$jo za+pQY_3nE6>s!kWhBx5Y*Flv3s_v4bo_V5}L_UUI*e3P7Jd`^To{Lo5KFQd#bnOFe zPK1aMK;bv1A%0`Pllk$`4cApF?S#+uPC>UVwo7}CHo%*LC0IzkE2XCoes4YOV=!bP zUHWBV91;Y$jO_w{)qi+cIxV#jFx*}*E{23o+qq_Tt(k&&4>mW9P{~lVl7>?7a2TP= z+A#8xBj;o<^u(?z#ue%TXFdQUAG`OydFtK-w6;uP0q312f_q0JKASMs052M(3AjpQ zyy5%Uqc^A-onMv`Yw^8QUqz(K0-bn)b^5=@H%ZEyfsz1^-~z*~pPZN-e$g!ZG9?7y zNk%5m%5I@q>Du!|N=J@A7t&h{h!7Z%itd%`Rbs*2e*NR)mgh>Aa5~UnUz2OJpLIam ziU>Apj&j~1&0G!0%M%O`&S5@$jr`K|?o&&&g=qTB*HQRtnDG)KlmEOP!I$?5ABT?9 zb<&5b0lfpIK(+-+G0;SykizJXANS~iHW^yXBzefbL!uk&urd%FrU(N5^(*8z_ZGXQ zCLEMR59y$~ahUVYTexWG)G8_^JB+3AB@ee(u{QEkd{3STx0f15l$nigc}Gd({;EgH zcHz<9dOpCU;17XSG%3s5LT@1RBJAykAE(j;SDkP-v^x+Y$a1>Aog!c3uetPli$~$N zp8YyUaMK3;Sug4LCOPZMo0s|s&8%hG#fA*~+3|iQGY9)_*Ts5`&=P33h9hzsaaUg| zvEBz4|3SqE8>5!v)Fc2_e$p`UOZL)+4zg)CS|ujPq$ zd#ax#kp)XX9@4XwTHC&XMm6z6rHiodE;tl_v1BqoP-wZjAAlBd#xT`Az+Hg0PnXSE zsoINuVT-UktmecE&T$Dmz_P!7!__yK+9qe~x0(X^CZrJJmjD3PEqw5PUFp{6% z?)T?)VN|R5kXsX(tett|rfrv4dfBiXec#@i7r1E1P0Q_IE@7N?9OrOS1UX7xK!Qpc zR}#hc!Q($&ql%4v<7KgX)C527Btd=CeyfWUIlO>3StB2()3^aXO=ym4rA8XGJ1;T_ z{$x#u1*eb({}-FEjHRjBLl zykI&UT;p<&EmmT9KEKxCyv2EvxRZ9I4#g|{$!@jywv(f?Dkz9f#>iCZTWjJa%sx*} zwU8|X182O+>FnRRT<;zMs*3f^4O|kTb0t+~0uVPWAGJoGx_UriJ(OINoi|5tLLk1! zt-IgasA^Y!#C!ps7Rg|J&lj6gZCqW6@+~zn9!sh;?|o8MV>9;@+OeAnyCN@Y{M0Cr z>Jm-gOlA23rH1Dea%bP)Kvz7tU#{x%2o-4XCcaq*uOwJn4`cCkq8d$AKxD*fI5cP& zwF`gZ)-LW?x^Wk({fnM1)kc9F&c*_@>RH}}bgd=-mFy6iS<@+t?cBy%`xp$r#Phjr z0!!>B!DI=e$RxS!XTD0qfu_x_3fxnm0>q_%(og*0)Y27}$ zc7jmNE#I~(KnHWvaw_gd!nX9_GRn`qAF$UovBh|Y-bb|gnZB?k#K|Q0_0l{9tcAvk zuR|4GBL*3q&Dg)&C=?T%okLSZLf;1#9iZ^fqH+J+zN2Kar)-%&@T;n2sUR403_d~n z7T}POwz?Q|^ezaIog#YJqTco}tK)7^B(mL(S^1Wk8P9FH?VhjFL3ns5^ zZzc${A=BovXoO?4qEnqXJ_JoG$V3XWKZ!(5+c`HPMfTGxwNJk&`q9?CpwVGV9_G3J znyxKe`E|zZ^Ss&jx${XfeZ^F%Q$K`aKs^*S%w(g*QirAB=qb~r>)T8>=0X~na0Gc( zstQ1j)bLyX#2P+NSyi~E-rn&kA%qf`8!A*IOA@~0ko6bQ9}Qv436bWRA$}Gb2?a)b zpF*&p6_zRe=1tr(AOmWR73f4epm2wpp+*jrsKWaiC#9QRBKHF6dh?v!=Iw1*okiBR z?0<;kt)RXT2a&o@Cfz^-v(jt$rAG6G3|O$9^>Xspn*4UXI~Eo3C^zC)&pRZ!&{1xF z5jXQuDL03d-kYe6cz)xu3LsyK+uQ%Ry7I(Ev2pSj`gB*gXiEWyGykWgMIEEC&zSO2 z4a8=@PO?*e3S|#gzw2w`HC2>!{O(Rc5X)8_!O^fph|bT>quvcWge&{J$}SxnN`|Bn zYu7l$LD4X+-x_}FP~20iNkgE^0ScUSB{s@A{jcMUizgn$|ANa%$nyEO&3m_bQ(S}B zR>qG&>7tcA&BXyam@)ONS&lDmq&ptBtpAlM^dJtAPlYpoR!1;bF88&ECLY-;imucG zZCurELxTBAEb z8DE{&a?g9OXql3S;7Q;Wv$;M!gmh+dAA#mn=8W`6HF2!p=TvH}cla*RJ)g(JM1db+FB#zp{qMMUwLAP*Rqsb~1NbP+I_FNYG-P?GQqQu!gF% zdY)D$+GQwGR|~XSeFR$ti8$=i>~6#ebgyLi)DIJKQ+Swk-srL7oY(T%8 zi#|}ctn;coZ4d>Lh60}!-4degTdsJ!w!+zWZ!R~sVoiCJq?*bUnij=QL+adZQVEE= zg+@Nkh_3C~07+mU1Sv3yFnIER82p}U4;B>qlFNkbSDI4t$}j&&!1G$ex+{=Y5v5rA}^6 z0X;k)35Lq`Kb&K`@xr$Md(lzh2b8>V6q?3Sp;XssL3lTPp6<78iUA1-F0P7_Yd8sq(9yfb;f1c}GM5^$vLqCC8 zG_p>qEYQvfs_it+)vMre8a|~Fht5lYob>QQEJ7Wqhk$NQC>fG>x#~c27a)6i*Gb8l z5XrUM!utKUZ?E!%>H~!lid6$f5+SRv!|y{49NP()Q!js|1{Y$uo5VaC37$HyU5jrb zjlgH19J|NK^;UiXsnj?bxf_`G*_I!)-|6Q{QzZ%XV^*(Y^*5g>d;}TjJYwP9qKBGc zY=&$c#-R3l2_&K*Tm-*|LZvtlxFu;JMEjyH#_EGq=9mKy&k=K{A)INZl(K*XsX`=@ zLBK3NWXpZLjW-hyq%HFS3_iX6a~UW#%~grXq+C=LVfPSBW}Kbf`&(Du7AvJ7QNZAN z_8J39>qUuMe;2`g@GW%?s&d|W07Wz6*t!}>#Lia%qq5NfjU&rWbsVpJF1o&PLt0p1 zA(4{l>s^ry?W1G`x{m1!`IJuBg(MlfvNEmsd09HWt53@heX;$>XZWoG78VvF9XQQv z{s!sLvA-E#h+r$FZfj;dqQwS96(u2Gi}t`Qjq?V7%fce2VCcd>ZqvW)gXL_G=w3YY zQq6WP?z1Wpeb+(?;hpn%;Ph9e?Dg)lG{H>wE3MdnCHW(a*8;^XRa^;E}pdf9gY{# z7L^&G5(IdF-O##ugq(c@m%}==^#ZoV02ZQcKYhQhR{cI~{O1=UW83)7Rn1ipwO3wn zF7|S!$Lj-l{x>RHMGCk=X^7DCL%X9iWwh}>s(*pmh4GoQAQdJUItQ8c6T z1rJ1M_k}akMqLPn5w{A)ju;4-zZn0D;Y-V3=YZs#ACY>8+(cIdm|E(`SvgCYyLHEJk zJtsKUkd*Y?7X!)1U0Y5MtG8DM^EcQH8U_dEs-xn&b$kojC5f7b&EvFXS&A*TY-s}d zX^cc$ur}0m7*!*KK~KIj0pE;kh zCikkA+4NdCkOl}~A;^7Q{6FsGE2qgZl-F+>E%#*}q9@a<){{U_5C}4W>tNA)Gh`p! z_mH)_i#YEM_K}NnL2}y8^Afa^1*S zK{&m;v{TPCsN758GcsEQ|CGP83E`dR0TK?GOWY|Cpnt1r-=BZ3dfdTWAF}Q(?z{6JJWqU3xsaGWZk1#-)TC=_T#eCK3gf%9F3UYJrH<+VvMSHtIii zNae3ffk`+iH&;NT}aHEZ06{p08bvC?2 zn^}*l2juOFz%4kedYp1=d}{a8xCjp2x{Y0QXBQFufu{R27u_FCQrj+c3jUjcRHdI* zNKZ{)>wmvID*W{Pm#f9b#qET&bgdOdINNT#IQLKGFcS4Iq-o^qob#&YVb39w zW!jIm4ed5druGP5-s@k18T>}XTt$4W$}dDuv+zcuw8k?GFD!HAOPz2=Ju?xyWK4s) zGZ>V7_AxvAa3DL=uE{O zv>O2Z{hJ4+2&|?p>i*?gHPmBzi(;d+PtYkp-mPewv`FdH*Dvch|R1&%C>g@wTGSN4pP}+ z0MF0=?*RY;d^Zy4n{(njvXub>e~vL$mKYA%tNtm<01iBM1S@_-*JoXQIAw#6fmS>V zRxH7B{||<;%u91*OQf+8meEbg%!UB6niq!wu8*-LGo7a6vn~n94p@g((WA)WPHk!J zs@=WVG4`Oe6hSDapFWMW#o0MG$70D+|)Nd9J_Nms1{c z-5ntktq&^n z63U+xztlL+kD?__?Qqbg<_k2`#d#Hm2Y8+#;?tcv{NJvf`DPOR*J? z$&AcXF@K%)_Kh;19x^%HkCAo+a-V;t>yK%ode*(5e0RkV$ny_nZzuZ=LfNjbqqu&< z4XE{2DQ<}Y>hyGy-8+>!mv1kBqoEEILfH>7_)_Fxm9`3D5y>U7ElH;g$;L zZ+P<_igddRJ<{ZYkmYCwu!e4vyij0Rw7G2j6IhW|WEu7a$249+X4O>rh)wcaT;%&) zul28jy8g|tSixr@`H00r!YKz5 zP_dXvMCuy#{U(Y?4=EbMCrS&RdwaoFF*hE|eZ2_=KQh?XjqaI&ci%A)+S%Ai6-+mj z=ZyM>?DNH;QR%xag*3q|5v3#Ih11iIr)kD42lKT1|8KSn&E-5nKu4#?12}C}&Kyrx zxkWR9Mc-Z|Yz75+5=HxH%6)1zXhc&QLG2N#j>#17TL5xhBz1V(lQY{PWtX4s} zu)cg<39)eok@w!cnex|+P`x*a&FY|wMW2aD1I~j@FP+{MDbC(w0C`FO&2ir4oF{JQ z&rkaGgIpm$Q3qWQ83mei5>GfIca-~z}T2qSGEPN?UTqK;aO#mI~+^bUB7-gsKQ!Z zKVIzAk3U{XQ4?z<`^aDz>G8RhSP!n0`l^E%IGkJ+j&Fv=Injc>$?+Vt#_>7tq)m{X ze`4xcC!ZN=M&F+i%C;i0W_%?ZY2sB5$Gq!c)~)9Cw?&Uq_a3>Mesk^BU^Q zG(unJsd<4&W%)?cKJEDA=D>7lJdM0jNDFg!Sz2YZR@GwTJazieJ6$ApCA`B)gi+gH@bt)vdAOu478h)N>ST zltt4N(Uyph%DnSLUM2Tp67tHCZy2>ZQ`pnD`VWILF&0%dv4Fw@TbYZ2)_v7#yMody zV&o+cL6yZwV;1OMZo@YsuYZAE*4+Z~952$7+tyH;EI+qH-Q+@at#|z< zzn9EScm#PFODKXt)xIpmXEF`UG>Rq)C8#@sj@H8muUmJ=%Hj`Mt&-MtWbemU-;UP6 zcw!skE?q7kxgv>4^%A+C$0&2`DSZbZY}G@W|C>S;HII$bcRln}r8R2G|4EoJ#>`?j z!17+5FRuqb(oGo(Zp`$AH}6ZI{T8!MtP!E>iILub?EaPRHb+Rtv6xY7&`dYVca*HU z-d$rpd|!>`66{M@Pl|C@QDd*rED|_wGj(c2q8AK{WZv%4vU3VnGnvw0w3i;OwwT1| zdY5XWUFb|EglI)FSXGwJ-zQldFzH0qKAx*?;Rf&Wb(|nvGQEURKJBm^w8_uqz(I0* zPXRrulu-}zpup9%2?}VZ%5f+O&rzIsY4jj|fMC2#lkkax@p`v*FPv|9>d%xRUb=;t zb7VqSUdwxF1qW<^_vrVex05GTEJ^b71e=X=IiDHj#;j~JH( z9Nv2nduwvxe0T(DxXC$?2qK|1YGP6i45E9Ds2%~01XXg51~s)jS-Fe;N9b<9D5@3I zpQoFxUoXKVzS%%bu(tp){1_IF zmhZ-8>$yIl{r|dk5SfIuKiT^weyI2 zGvl*^w?ODMqDQcDbWn3sO#6A9YrTFcuyU`gR0GT7c{WUyd_jbJYPiAY><-JUp$Y1S z`c^%c&c}u@0W!p`QdM;A)seUB%3$=?vl-SmMIE~PkI|bxU9L)*9dU|J9tSAXNg#p7 zv&=F<>EL&%nTFrhomQ;F?}$a_<$<|BsdH#<@sp>nif{|yPVcw@s_JmcJ|Jd$91sA8 zWcY&v+D&~wb(MEl=1C)2u#Gv%HTH+A!^NY-<^wr4!Zy~iMGoNSMVVUhM58+%)T)Sg zRy%$72(_CEVO8~q?l}TsFxn^A#%?G2$W2l4tY0e~C-SqlsMGB5;o;7`v9png$~v&o zGYL$2!3KMBy10K!t=Rimc%mf8lS( z4#x7tg!B}lt>Ds zX*rLGfRQ9Mm9({c z>aOi$QIrtY%VzKgO-68y{iV67=^Y{qL*E_9&VF9wL_~f@PQ^}+5HgC7Y6*g$^xE@0 zgQ$3hz+Ngy;QQlA)65v$B4?KIf5`B#96Vz6mD-||S@vQ1vuNaD+#AhbJ~W~4O<)5A zt-Qx@>1l{g0n>a+1XiOG`bDwj#Y%VU7nkh_7iyrOUm7#H=X(!?g%^Lr{)_X0IV6v# zrQ&;4HkCrCRV;CQ=9o&#vOC0_?N-YqSt`7kgiEGU+1X~mZ}6v04T}N3?qwAkDQ2R# z6Li+0v0xjf^G8wULq2Gwx{q7pkdW{t2nX+o{{P=dJk)`PF*jQ0{uM!+HqN;dJ-_6< zPaSdn^R=#`yJzU=I&-0Y5AmmKs|6>wQai!Z1h0hkJT@I4hl@xea-Bf0WW2qbNr^8Tel(cCGy*m*WRg zR<`VaK*>K5Xo=tO>98K*O0TS}l&t>oK5};)gLsoRkS9os-}(T2l%98UZBeF^KRii! zM-Tw-?yMwgPuuh!N*Cy^fzv*>N@Xni-v4mMQ`W4 zp0j_Y79lztwy@W3&k%^=iwR1kZivg1k zvbqMrEeyZDfSCf}c<1?v;>O<*Gmn?AxkU!{4w3izDNCt5zZnVZo5C@ z_b$q?{d4B&$x*b=h>e{+@TyL==t*onRi;3h*8r96X=zUExT8N8Nn1!Z2UndD4jw- zJSLLa?3^!mHz0p}73X{;lcbz0TsXsJr(yNY_s2FL$|v0D(W8F&7IcGac+59_!LQJ% z4@tg=gPWo3e%QMlV}M+u&~^obWO`Max$&&N5-B-W%T^DfV7(eps1oga%hm;zSZ3F& z!6dZ5L%F;{4?p6Yd^mpVrQL!=*Wvk_Yt(@D}kzx~MzUc$KD#^AGNL&SmY~?09 z%y%YagW6b)=3{$ze@pK}Yz}Qa@x;Sn$X~g>aAvh`F`1p!`QdClv-dvzh@Mf5Xi0RZ zVcxHr(VIrx{Bx+$&xl1r`WVVLhtVb`X_R+S881{+x|45b5PnomqmJ67nWayuzT!{H z`{*~5*H+t9v29_2XoF2a&vB|BLfX>wMnL07Cv$n@hv$Ywv7n%!KJayfwZn^Fjh)&iQZ=5|9W}L?U~*Urbg}d6 zqj%6D$zfVbAgNAyh*J}={HYr$v*JNks$l#{uWKfexdeb`RY+Rol6v84Q>9om-%@T` zu(px@D6OKRGTU>=d9xzo>cPQ5GGIwJ=?cEO@7ZrG4_(T>y-Ia7GU5IVY5!-ke)%PU z7X&!l^>U#JE45U4y>K+=(&?I1PQhIkf&1FjGJwAKj)zuHX3k_rs9u|zB^=bT~E*rhWU_3&pc<1wy951o7 zD}YY~jNn(1W@Kc9X7*180?l!<^gQ2qa`SLmV~|-_=Gdx zu4rICWh(`kjCBJ$Qrd2sC#BGQxVJvRqJFkSb*eS$z7nC%H*C@FV(!1c&G(?E@T;KY#-Pnm-G?0)ma{K{>Yl>%M;-JLvj-bm`(Y6vjGQ;Ez`yJ+(A``62<-Lz5v&JUdk0ihU6CG}RKf>~( zK>j1iPmU7vBKLTBqGuWe>35^uPj7MF!(3i?w>q#sajOeYdoms$0bU@uaAJum`G^@GPNMZd(ivr5xUrm+?2{MULkCpGxsHt*E241WR0|e6fuqi|quPfIOVFH)S<3B3zr;nrW977ZHu!-EeJ89UxGV!s z`Z(D`fN?(ynk&Uk+eK;LbsG2H(I9^0s)VF#jZQFan5bv~u|Ir5d!&t>*jeh>awt~a zCz5iDaiXv7DtpbKjJ1m~_U`x`xh%^~mr^dN;@WPQzI=B9@pNT~+<9GX`mAYtG*&ym~ogf~wMZdi) zxPi0ZT?39!GLTolPDsE0xIzA%+YEFjLaCG9vea_7@PQ6dwkH3zE6Z;u`^(8HaQKEf zs}DOEjs~CTw{@xezfKAG8P^reR{2>M*Lju`F`WZjZ6j*6l}<3o|E%%a&m^9;=8>7*t*P5OXGaE zg;OR_Pbcw&{nRCp7UmM~Y0fv6t>z2NbcRPBq{9 zIObfjOn+pyd$DscJA}W34hNOuKhNG;>vmFW8cvq6bA~pWH?zgzVR0bc2r6NeJM$D^ z@|%>A7VzHusT|eT$INrG%(XFXk!@HRc2svCeFtVd@~2wP{$mEVzZVsVHOp!$bWLxH zdZy8TmwCzKR_d##v1S#-8=5N77bMhyT&&ds`at?1XW4KEPynbf&92I}dmWs9x$BD` z(r%YTamIh-^5D(7((f2np>&Zt=F)=#f)b(nVa~SLp~EGE0mj24w4;&`VrjdW#{{T&OxDD?bCJ>P4&%*GGZ?UYkgGb7Bt9ewenmCI5R z=d-x_N!gMzE#Lh%QlqF`;T}`Z;~1knDF|HG1u=+ec1o&9c#%FHl?iClfnuS2 zIJ1jBi=C|H=Ylid-TfRN*di#Ym=Vk@@fo{KcWcTRp zwenSovZpGv!ucRFRQmW?OTS~)KmOgRY;&K6Hmp%@sb0$$+7$GMdTba%YTidBRuejX zeSH~}kMZHrMo~jjeK34xP7i$355c4=3EA&GMS>Rn%+%hZN}VpUI)pDYR6JAtts`Mv z1_kmB>AIild?GibG|5thBrosRV>y~ivlW+LH(m^2n$|?0KMVhaH(abhKle?UWis&Q zCKnc}lmf(ZBo{XH?EGOLwfgq&Fh3Bqc|jgd1fsTZXgy-jx(n$2WiJQfrOCE z*9YN~DE6g32^9NN{ZBv9>SiY=v-CfeGkQCVtdpb=QuVL?pb_S{zp|B+Y{%k*Z<$I| ze-J*0{UZ9)f0^I(t`li)_a>GbwZ=jMKL zPcF!YJ{!3wy?FU3;mMWWiwgnKb(&OiY`J=~O4b#QrvXD1rv>*`V@$UN1B56QoR#OR zP@apHV|!q4-k%m#37sHyBK~szb_%5=g5CuXkh8Z`ur0fTFeVhnQWy=T0j*T`v(uhJ zYCzJO65!rG^=0vJ`*^98US`cZVkXLdI#)wNPIynSX%QUA_T=DB*E(7hyXA(A^fOjd zkzp-g5vn>9V1Q9`>4iLEn;*bX(-&N8wll#GDur~w37CT3;AQYlqD;hM?uV03UkMYA zK2JbeMtvD7sxLfWVFfjaqn>S4Oa;TUp0uFfH;OAh^rU%QcylAjg3jP-OXq^5`xfJz%d(zyIJY0+K&sQjH5@1K7WuBaW zrnSC1t~Sv{Q+`yer;GVmLYZRm9c|%~`@VN3NRV9&H%_=~Nzg5L^b2%Qj=ApktMk4V zJ;C9eHKMJy(v;2{>5i{7Xys4ivY?KR@Tm-(9(!>2=d(KJ>@?kE-1;{WiHSVSYn* zCgyfy7BEBQBp@Qa=^Gpj>`V|11pRAA5nVR#&=#%cH_++3nOt7}DuD8K(&EcPJ~aU$ z$v7k(E~)+)MaIk%#yI^Vq#a^c@QNuHx9Agd@~wE9k|lUEO$67-NdCT{4ch9G{hgVO z$4RJQ{$aSePEmf;g#c-H4^Y8f&V-SqR11qL|p`j6oz>fIWgE3wpIBg*RTd}k# zV+*Icy83s`;y_AWMceDj@%C4HIxRee(y5UaC-L**aWOeZONDRiibI^lV>n-7I{k$f zU@5@_la5=*ZWK9c!J~XBc6uVJR7{#wN2R=1X^#?qny%abHu~DwM4`Dc33~DU z+wJa!dINHP=b?wVlYE^P$bNsPoZ^s!>Vl#uyuPofhJtaSM2Uf;_l*Z194%;y>3wWP zyGR1B*l36zVa!3YF!X#foAPz*j|^W<*Q$ttSTjs=&!9hT&*PiR9ayE zQHX0>toZlBkhghGk5`pj5$7= zjh#IQM}%H;ZxTf8ivno8*#ZHCQ(~q}&QyDjD*Xc6lk)4oB=|#IE$F8>mo!@B!HA+H zbB;S8-<;7##N9broI9_fI89&ZYQW%V|$i#0k_r}xF%k5d9x|s2@@q%Q6%f*^ccBpkRBR<)_jZG zX%PQ7oAdYdLHq)qCey%4vVSGJe?Xbg6cuJ3w!LN6{W=kIoGriYB-ni@n#dn_N$|1> z#T3EQJSqIzLY8E(*+b16@lC_;REE}SWSas*49&mbfbu4oZ)vCSCpz?n+$|eC{dDAJ zKT83pM>BcG4xeU0Ka1HtPnt#BA7HutAq}2; zeBbvw=Q=;V{J}gk_p|p}d#$~0$E=_RcWU!Fnu>_pwqt+v8In>iPEPA`hII*K#G)SZ zm%0b2%mY9n_l=%1g4IIBTD2VpB$DM8M51@Svz;0JdLrnk$68|JqqBrYlZULlyCzIj zADdZu-vtf7-e(BG2iH1T@XIHU+C}X!10_@vBoTLCDPbk;2-uG?dskZg zg*VLp0Dh4aH8eZ|+0t?+yK|2LL`FdW>n&22;7_~t`-A=o17O*KC2woY+jXsPSVZ1k zq#!woAA1o|EFr`UuEw2^=HOw@~Z<5;@bZTZ=&`@FQfNLE$FLj3hEfEj?YpLOzW|N1> z+?wmNU6m-WE32dA5-GkF@$YDluhmvz{g|i@3=vn77t_RxzoZp}=;X!S5hy zN{V27JwuPZq6F{cefr6oXNm#c%;Yl>OJyL@JdkPYlhb6KC3~|yf0i|5d>qBvKt=TQ zG{k1>z@2hCm#P^yT~_rheSUzp^B zzSRBh?Rt8ATERmS)%SAXZ`qeYnaDnzIGNMqgUK*;P+IcoIXBY&j_z9r>}8Bw?76pQ z@h3Y6sgj&*F&u?e0*qgSFHSafjTmH}G!a-8?a6*7Pa*|)ze&SAvZHwVZkBuvd8MY{ zndFE?{TJAf@nvMp}r%>44`;6ax_+BzG+`dMAxeQwu_{*#g zi2Jj-8Y#iR1v#@-BDUQjlyrt3|tNciN6&=l0*v5pGQ{ha zV3f#_b)MTN^IpLjpAL5>)qjmS>~5!P0&OEt%TAMT-m5Un#K#5W7ZOwOZaAI%nuzM& zR~;7gnL%+KIFTNsC&-j#pS&_>9eF3gjNiL?BbNHJWNy%Xcw|cjh_IU$0 zI-=C!{-NJmq7Q4LeRK5uC~7?i9U6A4aa!mXN7DEqnM1~e`ppVOXC5jxyd2VAhZh7T z^v(@4J+T17N%Y1{t&kP2v@~e&fs94(p#x6Ec){{%vQRky$HYbgcdgMKUiV&lwT#R^ zmkg(SQpfM;t`xCivJTg;?rCDzAq6MR0$rHD43O&%4`5HTnN=b&fg8Ls&A^O<{_eS7 zvyT3!D&h`_3~l&+=P5|z#eZS?qt}m)$2608a#iBL zGNWDg{(XuTVe5Mv8=La_`=TLRg5NQtjvdX&QVE^#J-d=7W^c=0Je<;9$U=OU^Q6bj9=1d0g4*?1aEd-{BWA}n{AL> zFlN6ax;rg0H*hA9cpROc?~Z#N$VV?HC&9dZ^+TLP&5=|>dVEKJi{)QhU zr502tq9fa69W^nxK3R8qH*3}e{`=fYgoMLT=@~d*N zOJ2V`yg|L7V$j>bg-7QR;58uZO4xU?szd60&-VVIN!It3bb7JMh%cQ!@!r`oz_Eyc z4Gj!9re`L+2p)0mov@vFzU}K`y7M zr|>T~#<>%G``gj7llBK}*Xqx>(rc|QA{JVaUpY6T_Dx|Bcb#yYW|{9E#w2Zb&^e275V=C20W6Vuo5G~E46fPv&`1Ody@8G_00Bn>)X79(02`O$blM?7{sjZl}ILf}ys zM_qOo*to2J*A7r0*ZfuGgOTfgyqBEsD@65^lI@J?lSDM&9-d{Tr9`6hFM=rn&T#1G z(ee6bG>D|B{j4XQiCFfe9YmqCZ2^B8e+Ob8;>Dy^MI_)sotTs)@j3XurLKw$an^(* z*%@jVa`LG1qd=MPQRJ{LV8fa33~S`!XYMRh47e0p!2jbctPq$1de781LUkHgP6lzQ z9ESV*_fJ2oDO@Vb2X(D}j5Q3kpRU>nVE^t<#Q1OjM~`MvPf>Xrd132Ls zxNw1icYW3tj)<1K-l?YQYMuJTYA~*ze+vS$TSs0Zw&V2kUPd+^hS*S-VUHUdOpat?8;?&~#j;of z>wt8t7x5Ib%PC9^X)Y5kxFiN-PoDXYesx)J{OF36X*`p)GSskC7yk-zpV=?)l%rTH zyWAN25Yk6`^R*|gun*T4zDw--p8r*i0`^S$9o;#~;M)r4p*{Wb-j{Rf(&QpIur zw@j8NhujD39wZj;~-wB^mMD2F&tJBwMe!fa=vCySF33DYS0~cDCf{^%p*reVJo1^(JIFHuY-=Jto&a^!U0x}lzi1(8GrD&OrQ)t zK!O8FDYsRX2~dbbh@eZ!kg#zGAGQ-84~>HC_t7z;WDAiRo}_iMx?s*{0OcnsZYmJS zWS-M4`4+V4pARnAI$k+B9;>~(J>OwTe?Y~^$yl7aU;5kGq7#Ph(BfRY^o>JI$OU(N z`Z-+z1{`!Q7V1)x~O8=b30CLi7c$w zj)^(xzgZjus`z)0y~)$vxvNi&RI2z&I^l#Zmv6y{0H9rLhOW48grDhNmWS?Yz?^N> zyOcNy3r}Pn2uVy2#NFVnBo`(O4zp6jLRpMUWx-H(E3biZ}7It=j2}DCn*d`iPJU;~UHTinx*vdv^fhU1&hO>kVs?G86Q!nR{ z*XZA?){y)`sj)sbd|j$7ws_kNq6e@40p;;T77~Uk zhoepIwp(6n8ygjmNIWQ;ND1DXG%6JD7XZteR-(}tB^egv6U>T zT`nEs_1^@Ngwe@t7Z^_lPJtn>l$^vG{AoX;nEAH~Sfe2EeqvesAb1LxX2(-#u}2zP zWkV+Cy;fo>8?sS_FCm~BI}4wQo)thZk(N)Ff(H#ls?3*ZBZ2tmGq>1JYCh$wfGca(@!QB&1z6EL_Qku{;=E&zMGKJJXYm&ts-RFT6{{f zES=!}=I=yK9#+TVfE?8=4*^9V9CXg;c^nay1lLY{(Q^qvNIb}#HJCq8cYNR=L*rp* zV!?iaJMPnFzb>A2gEH#@;Zd5?h(hiytFY!l*3If(XUBTs2NKKMupXNx?GW?Kif6nH z5P*?>aiv>LHa-6t0X~P-!aI`Otk3UanY+wj>$-ml01k0Y>#SjM+>Nx)iHc*B%ptkb z9(pQJ`TF)3LGJj&s5W*kF4EA@PyuP3{AqLtTcKJGv2B0WVfVBfVY~1C9t?&&uaT&3 zCJ1iGHxsa)zj;!N)xBXh>u`^3C7t{|sV0V8vvSGlmp=s0)PD!Q61^>Hu#61&u%6iH z-LG47<`w))5fKnESov2NAz@s;cfroi9^awW8%t~Rh8c$rd@rn*SoxrbmXZhXgHoky zYWlu`L^)~zVbZf5oNg)j0(bbC8D+ze74oZb+7KR5Xa`+drT8s`TuMh9t!x6hjbUtz z7D$3>^&w%3NYquMPHL(vfL`F|X@JJ#LK%+_y7M(BI+^aB^wFSeF}iag5pmZUJ(NS{ zLva%eOw7ILQ%o%RV9JZ2jmTcm@U0_JD97;Q&D;C37x_V;^o75=;+RX+nVay>heJIQnP)H3b{y;?%JH2WObJ2kWijGId(d~&ZU!5!a zi5N!a%7Ou2+eERG&L9Oiyftfkb#1MT-1A$9Fig3G=>AZhUA9XhuPfFy#OY6g7nGB} z>g2i-@)0qnT`9$^C0sYe74zpM=LTCB7vq%LKTp57@{6o=NTkJN{(d(W%G`x+Zv%(Z z3gxj_$wB2vWxLGDD80P#*+-o5VUedagMQMN;vNv%m(DVA?pdQ>TqA-I{lH{1Ub&gY7C*XFpdM`qlTj9x}W1tc^+|1bD2#=w`ScEBXL*#VjFw6ty2#6{)G9?j> zQK-ufF-BApb;bgjmrKY%57qXL`S&LjT%L~5%$t-K3VBLea_)#beh6E%+ZbnN)RAPW z2JcVRsJIf*b0?||*9hdwn77m4u6M{4J%1>ADG7BLXP;P>mdFmzWo$y8Cwh74VB43G zEfCkZ3FO1ls;bA8w~R)k8M>1*?J0>X+LI*QnObu#7r9~k&Nvy z1OjQ++ &6pK;lZ$lC!ZxsW=52gt7_=p~<{B2BN8gxNg$Q#V}qt;e?f`lfKxRSwe zq4nbh~AebT?{# zJ1zKd?7$_87_?{sihO)lPqYaE+7`UNJ`XJ7s_4sJV=;MNN0^4{n3%jXZpOd}#KpxO z|9h#){A+mHA6d>gYL`Yiq@TDR9fF-2p=6{WYx5Pc>g~I4&+oBrn%=Q;tC*Z$ekwnB zMhj&uM7vcUc3*B9L&@jvGN7c(lzlgGW$vhDVy237c<-t{@9uWvrPF}Sk7qf@O=uK0 z)ZeZwiW?nCONTaIcay+>H=aWQR7WYO8KK@3d*JxD9FRy*8nCHheJ$m=TO)i}A75cj; z?pue`J^Nj!R8AXOt1nkBPPV^w)N!cH&0a_UtLKq0&R;q(bt{8cckKdTpCaQ32+-gH zUenLF_)I$sH$ZXv5I)%&-kLQ!JRdIBR_Is}$ik{>XBC*@8}0Q-Y*&@*&j3^7)!m=Ej%THOA-<^rvdprB;y}?+xte-H3F5<1RfiT4JEm?6* z#QO-`aXy}dWvO-VY}ERnBE1n-C(~KeJs5nL$IW+u3Bjp1V+BhL^BL~=<_b+*E&klP zZ@~iI%_qQyUxSkI_D(lWb~k~0f`(r`1AM7D7!zNQr%N3i5^17fehw;-YVFW3Q>qnb zKu1=LEC@T`qx*t^6;m*}gM)(so-698kSW17pVDKBJqebALIyQx^T}&5k1=UizDeJV zLEngDu{h5HBCF!j{C6CCi3jxmkW^-}kjiO`@`@7UubJV8}_qT@xh zfbrnFeKeJDjA>4_p;P>M*@~zCF^@%Qs%e8z07Y+_0jl68AdD zlWOypagsdFO!q(G=aZV;tobE!Juwn`Xq9{XGObG3=tZkWjb%5kHyp-I--2?82?XZw z+qamE^%V3DpTKRJIUApmUB&I*rNz(Jc3S{ZM*-tw1$iPTk;=+FlaRh&8wT`{+!p2@ zGLsQ5fR#nSF?0z!BiT>hl^zc(b;O?af?71llog)ScWE-ZoBVBuQ!w=(C>GOX$zT|1 zd^apzzLq>bd-K-V@D&}_w{@~o&6@kuvER)Hr=Qmv^c$ep7Xvt5Eb@AZzh4FvbIiiy zFB?Cj-cU_UOdKh{{qRBHA1d=850c_v?Qr+F0IWKdlP{AW<_B6tAST4Li{(tW7Am2$ ziI1t`M$FWBs_N#Lk7SetBfobM!rs>)!5g9~@Q%|}qkNqRQw;c2S}(M)dmGrFEs}kC z89-XsOuW#pjlO{aeI90gX3j?iaS_7<(QPilrJHM#4o{BMpqH0&hq^z0%X`2v_F3}B ztrQ%ADp%$h7iBhp*UJE}UnqLM zpFpJoYzKaR7uA)VoGjo^pudT1U$?<4oP5avC$ z(<$mQq+oUCV(&f!@@7qRv`dS0l(He0#wARC5TG$3e~pRzham`0&5V-X%LG!M8HNr6w zOtj3#IAxA}ADP+Y#`BLIi7*3a3GGqimkU7Jv1_Dg9ob-%0D1>0_-CM!qJxl0*7{Z^6Yp5ABV{Zr9X ztsgvc{T`gsNH8p9=Ak7t0tbzex^{3rR8djU0pt;3Gt}fk$X%dLzzOL#Tn)@66Y@dB zO+6L=7t`CC+ROWCtxD|t2fOy0kG1MwJ~f#n{$y+@0-f9p0M3o_%7!kIQmbs`v(XX! z>IItIevmU@6M*>1C)MMwtZ*jU-gE_Gwi_&0q$bsMgos!ApS=}l3)dcxNX!oJy8h^i zICP(il4PY|mX2t;IGpNwkn@yPX|0l+bmKXh;G^fH>Y{t(+YJ!1wdCHl)y0nPoi)vY zN2|j{T#wfrI~}_mdDv%|%p`vXhnpEOEvPq(Hk@&1EVcByo|`QO1pUFkRW{WHvpETm z&G=;0Trb|$j8pyblkxJ0`6nmvzwNUT@1}aZ9|P(Hv7=Ve z_gr_;Z*Ia&KZOh7Hf-vOHN8k7#t&wRuAy1W)i&g$%Wi$N$`kOI_qZ!@#7SxBJkaE; zKjM$`T1}FG+vY^F&Czk-$m`u&l+RnEO&><`e@m{};*KhdR7aEL_JbKpDfwBuZ3~#$ zePC=cOLH@C+B6U|Fc^m*jWvHQXZ>;WMyRFr2&7J}qUIzcK1On~yWuU^VmxQuA%uqi&pG^xz4)@Ry^m60{bg(z$q*whykr2rDzM{#k(W$qNKw%EFI=Nb%0y%$E?7yAmUwuccL zX8nD(_@ocWjI+S@iNhhCMx^0*1o)(+^V=_;hvbI(796)?7eG<~pUo#7A-uYzP3kIn zey%WD**mpLNYiv+gcn5^=0QvP2;!i+lwfAe#B1iP=i5>+QjB@{aeKI|az1b6SM9R0 zO|${q9!WaH7fGtS!e!I6m}h5I8`@?O(O=w#uIty_(ic6IN9@-S9Uem6$F&R5Vnw2T zb+{^3vU%ShpDE` zxV`{?1*GL>`OJyKoihCosWh{0va8}yh5OO}_n;~p6*1Tt+ylPPeq!Etwvq@&>m4Lb zqDWQ==l`LC2}?!VX=8${Ypbcp-nmoqy>RRX1Vwbl0MttgLY8W10;zcs6i*JgdKhpFlCk`YDb)JKL&5JUhta zo$FkWO@nxEVSD3H%~B2UZecjY>zU>g zmee1#70x&6F04q@;b90OIm(Sy7=e)GT3%712>cskmrFgEAueRbFbTpTwwL(%dDd|z zDYN_SMwP8k*x5st*h{aUOI?V}Y9K$pwe0^7G`mFJ6+Vb^)y0}J;Qa!luc zeMZ=nBWw31UaG%p9X4Tzrw8?KDOhhDCX}rdF{-@ zik3xqqp1s4(%YxHM0o4cH@d8j#j{t?hn?diWh>9NtxmT2dpG?Suw8@unrD!X4IC-5 z(#+%fx93Bm0Ydr7E1@bh8nM;P!&RHj9xp7ZsdtCbnh2OYmj#hXEq#m&m!xIw?Q3nM z9Y|3z)WIIVYY*W4`eeFuElUnjM*qQm?tH)Xwic#mbh_M3HnHHnJS3bYyy~tUFn;261kjUCbwY#!+YNN%Lqt8COj>kIt2 z*%XPD9yN%#S6LXbms?m3%0>5#Cb!hwC9=P-f}Ge>!$enVLq^`Pj`n2(5;b7;+m?8W z0Cp?;Mv0+IBY2;ea}vt$`?O-Mtkf;8s7%|h+EC;CMfxvbo$JE0ys+qt8z|j;0j8i5 z;9!#gl~#eejf;Kj8vGa3723R)|kida6!#@y}C*YxIu?NrZF4bBm_JL3u^qLvK5yp6{(+K7& zpd<_M8~ekmxVBk0T3M9JjZ~*2=X<`$^`U-X+rIurSX&FI=ayg$1ZrAug0(AGbU16{ zI+v2#m83rPRX!Si)+r<7s~XKwnwWo5DR>%bvmd}n($A#{?DLFM_Wv?TFhjC?RR^Z-wB_ylip2K@rNhGskqy`|bIDvO>4)l?xKI0k@8sc$M!2)~dgdfpzd z%c^kwi*0WTD{DeuHqtCL@|0UaMzNO9vUv2~lJf;VVQy*C1sT8G*i@9SsR@JHD>^-C z0P305Kfx(+peLQP$OO49wzseAV)9@*nO#TiuXC^YR+Hgn=Z5O0TNFQKIET$FjTz)s zmSOLg{$ZN@-8R<~#i7>bq*+6)L={6;$gh64d3K)sT}|{|Z=9hZT0{9Tny@l*O*}XB z`UrBoBo3uiEkxr$H2%vr42 zOIl@4_C1i9w>M3~&);=1ny$w3`1pKzjpEkiAj0wf2Mg27dG_XD$FE_u50_*6F?gn^ zVHbmjEj-Uqz(5#>Yv!O6xv%sp8>utVqoCt;F=7*syIh*n>%*r{J2$!xuKo4i0J}~2 zedIw7|Mws>++Q}_HRAWyRjpv8HWZ0mD@bSLCLYgFO=4B8A=;vD9z@w;qip(qHzi@Y zHgH5m%JRn%ku-9$dhw&C2&*5H%i-$>J>u5pqeiduWMQ5uCbHl1bPu`pS-^tUQs_Tl z*!mm4Y)Mb8Y3Nz)NjwkaZsD(R24pOWM3oR@$<1)w*J1U9Q_!}V7SaWI8rEUkBT>8| zrTD#R(;=p{0lgEIc+mVdxXVr)D+v(!>7o^ad&R2UceK9s&J%uL`4~ez_sk4v6~JHm zPub~WAxaN6vG!p^FR{9w|82yRL)=sK%EIEU-_r<~-70GIJn@G+gfgV(PRv1Opir)f z4hj)H=i~3FS2L^CIS4171e5J$ENFB{uE|*^=z=!0g71XX$)J}OrdQ_lDUdLlu|Af{ zV>PB;AvaAd4D2sjhlY5-Y1Ius5p+ETW;5355=D#Gz3Zq{$L zW9OvWSbsV)F=xs$osuC1dMfj+l=RO;-TZ*vy*+)FTdk<$$O(+3oZ(*Ldv1Xyaq~#S z>NU-xU;;b*^O|O*F^ih^erod44LXdbR%|*h$Amt$l~f*Kc9;piZ*ATyi%&AzAA~Kh zSHmwRu+XmJ#v{#In~mlL{6CTv1xPq&8k&4C+r=jr38a!O4Nco73)S?1m`65VQtDGS z-~dIyY^T>-2=rPBRFhl<&}lMOzIYE=;T$sk3nLQI&lRuIy{U~^<@>A<%M|ebrrn!W>Z^Wy#&TZa4BBu)CBO$^KLV*9@ejCr&RJKJovKI(?k zWg0O%XiZdr?W9Ei>%H)VgQN=hG#K$05yrOlgP&kxsy(=XpK z9Kb1I)+I0SMkmRVUPAO66$8Lh3Qmg_!;DnP43uivby3`T1Kf%;eo6V=G6pSfv=`m~ z#GPbW_&*qg1zWyep0VK>MsW+bP)&j0fcQ*I?>(QBO$J))Lhn9BH-5JgB)t1Iu6nz# z->VyY^F_@NaMm#<7e%`b z4DGc^SZSl**4Kv{{8UH zks4MzAzrO4z6Y${9ti)X|4n^}UnrQ>!EFa(ZrN5SA_1!(|G7wXitUgD#A}rVDtm}q zgh}K)2QP2RAFJ!C?+kMvn|~d%!P*ZibI5=8v+h5lNuJU$kv8l6^X!h}`hCU6?O_4B7p#0zJVL$JmYS-i_hA0Ix##ll3I0t3lfjXNYR(vmkkzGFWS2Q zh&}yquSpQ_pb@SPUrp~dSFJ>B9R8C|mG?<_a6@P3N`PmA9p&gj>AYSKb}pA;$l zptxl=@<(Tz>mdDf^rP` zK{!|MnA*4$Ms0F0S#T@-q93cGyoG)b@Et{a#P{d>(v_!P3gBh#!>ZJOF6OSthU>1D zWWwl{{g)KWE3DKHSayUDzel4YQa@2vLCehF5C6sWz8&GopUGY?3p9#6WYz7^Z z4@s|9-b2cWw+{}XFQYUR_vno`Hbay0Pf4O)cB2hwW5uSkRkfe1%SFZ?$U&o5Q7uk8 zK}aW~|JGkJ@7WguS*L*PAVuPiUkW@NQqP{hCkAR-S<5X$>NOwYD^aSI1!-=A;GC2D zDUPqHbK=~;^-X>tC5`~$a;zLdQ2U%>f$Ddpm-pJ|w|^$YD40rx`{Jg+_Vbn@69}Ec zaa<*EqXiR@hsK|p2!Oyk&`EN(x4nP(RPmhtwId&+7g2w(>KJVjURRB=#8pU0f(iIB z&v7asn7UNAdUA4s4z7fvH+;}@bE3Rsbw^{EJ@$AB)%*}wHb=)|xSWtk6sf$}WZEuY ziB622gDr$dLK4H?o!UREw}=Yl-$NoyN`TVW2_oxtbXQUNbnbHH78_$n5V(9QJ&C2} zbu#$r;QDJGqls`p$Jg0UMd^3mYb8pYZ;vIdK*dsSC1g^LHQ-rdj7Gku7U0Ichf$v! z?==P66gK5p&1wz{2}OcwUcE_`nPEfd@;wF=wy7IF5_rdEc)PZ|F=63ZAG*uA1^l2r z@@%4hHJPsIKp}mMsSkaK@cZ(SI~H$w$}@VMf~RP@GaMR{u92hkU=0xXj5~lZR;$!b zm=n@RU9(lLSZ-)H=jHa1Cf*Eev&NsOO#xeDvxGR9lQ4nD4bMP;-qmA`hSgWWQ2U1=7eY zW+eJ)3~#Gaa~Sczv@+E@5dPJp9mC*;=Qx=VV41`wDXkco_vE964mv{acH=WBDZB|2 zivb0I85=&`B1z4((AKaIMRyd;PX}iDezX`d-{!;Mm9e|yVzUP=V~0mQ6}wT6F8aRj zgGG22GyGlO^*DJ(4j6mDn=Ro3D_;K2sKPzO+tYSpW=uJqlkbP5s@$9T{F@^xb48k6 zk_^nSh(8GMyA)O{msH)O;4N-w#vSO!Ow~*ol@4WVh~mW8H7oX8IPM_FbHQVg zI+Lm66hW3d4Dc{`8d#%TV&R4x`un$R&NtO=g2)UdXaOKfrkCa_Q~wg)izm?7bH*X> zqC+MF!^ifhZC4gVF`5a6$`2KqCxHk*ciBZ+T7a_}5`w}(VjCmc`iDpV&W%Akq08eH zL=?I6kcuNusYF55?+fSMXRr?(KPBX#wNKB46`!2c;A}M1Nbq<6wp*k*ytE^sg~04j z1iN=UOqF?qi}KH!8|8lrkw%QEVrazoJmQWY=&L3Z?lXAwNUfKMw8*3Y7#(r*5O-Z` zH*-=KXNfR-;^Is;82?aT#|dD-3n@W(-K-kTQ{tSCx{qn2QqbJ$Iu^}43|(NEkwqC) zDGTPiaLW8^P}A6u5wykv3Y_q?$1;X1YmS!d#Vb7dCtV$#%O+NHkgwGejQZUlZ!kfP zcf%^9_Qllmhq=7xvlXf$#je`4#jPNE=-lCuzbm5qcm?d(`7_K~N~WY+z04n>sCY0- zdav}i7d@w=Q%CKwzsA|iRmS9At;kGB0ME9l>U9vIZP~R(@;gde>rvbUDMSi8=hy5J za@H^v1{8&Hg>PH6_R&6MCdloBKaleU>mUGh`w{doEEcrZjqHU_PvIL80blBG_ZE0l zr{EfIUOn=EcM9yqI5*WN{fba-C-fhLT%h%#paK^6h-WV;60)95*Z{-;q@vHE25npg z>ZZV}w=U?97JakSK?7mF7Q*YM3z8EHwc?4+uzr#^IZ{#(p6%}(^g?2DLon3GX%4s! zXPi!BSiswzdF(3(IOVMtKz&R;iy9aY2dTiiCK+zhy~7~v zqhBv~rgbG&Rk(<)U;Mxp=zBR0&TKT;aR&(u6C2djR@%H-^m>FrSW%EmYLhFr2b>9K zsPm*L&)@4HC8QAGZ|h@$a%-T^5Dp9sB()xZLI$c<;c~e5Qt+L)wfBX_T{NgNu7) ztJv`AHI;uB&TxVX^|#$iX|(AuabU@J$#8EjYmGIr*y{PgBPuI(%Jt%%P7Iy*n3~q! z!^(D)1TqBouyr{G^!2rmp(SHTO~JI%XEhi#5{n3qc_s;;TI8W^#*&mpI z89Yq4toypL9jH$_v2iH=nFnfDM+{rYwTb9kPuZdTBx_WCGKez@$XB^AC4D4Tw?Cf| zRg+`bI}Hd~e1SI@a2-AW0PNS6Am3w5PI+99s9l)Zjy@U7jdr=klbWo2YwqK7y?jx| zJ$8+7w0R~mImWK1o8jIH@6Rpd*bs2TKesnUkg)mhE=lhoDVmVG-bH4dGLt}+yQo+0 zx=`P`XRgTWy`I!Y0N$Doxqpo6Iq`U?^@6Cz$_0W&${s;d43U_OK78U-)xXPRc@%~K zDiSC0+?_2l?&t>Vf`uwEc0coo>-uO{XS#fM8wBI9$u;T{RqqAun*;E+tfudiM7j(G zpA0#Wy$G+qvT&)bl0yiyg{HZiAb@wdtK}-AE6!6SLS`-lHl?Y#e7v361!>)db~f_0 zn(hlnwC;;WnC&`~kXD2mzLH1KZX5(h`2=#Hj#4(|9U8e^DaTpgR6AXo0}1nu?if)K z#Q!Ew%;z$HHc3Y15QV7{tW>E~|EI}|_c;SPqASFwD{rk`6+_s+N!O+iq@MytbHpYN zY1;LYURs%7Upgb$PXn;{r{l*j))io@T%gw?UpD@A^$5-PrEpSaq?;=(0H+p09;FZ? z-+U1fZ@J6!IRiH0dBY{(YZFlS{=z@7^hT|#B{0vwyU#FiL<@{SVf#N@9!5zb56l48 z)uLSsaII@cj-7wr)mg>wzZ0Doiw}N?poo7xDI>BNi~F%TOwY}M#HC-^ghtbF$rY3D z+0SIzg;jMa^WzT81ZLjIA>yM6;!DVMYIcb2*@I+t7)y1parSwBT8VxM!M?x`$EPkf zUJka))(TbN(Ac1V#%u>*>x3FMKlo;#gLw4$F4Et*WfrdGlFp;>U!hDoUmZzm=J!sr zjt2N9HTr8OQTkS^Dm~GboTc%`_pMYy;FnZUGuASsWS;&}WBoY$^XbARr8CjA>u^a$ z$oWv<`UXv7fw&%(?)Mp=A6|6L&!U%h^~;oP*uZmlVqKN)umiEUIeJUnm_Au(prX(9S-0qNz7ztfr3~i!&Ua!L5)55s|#prgMppeKh2f&(EF6grz&dFNNG` zUk>;uvjAJ_{N7b=*bARbE9JA7U$&Z886SOF0M zNmCrx`wo^m zi&S`b*#Xl@7s91n@!Nd1mYRUblnYp4G1yi4x%89YX#&cy%b2RmZ6o zb?Ndu6jSr8S58viEdtwTYP|yuyaLIspp4F ztU}z-OssR(RM*9|m&}tkLtsS9rAw_0F!Tn>wD+;xaGCZmDg&;5bi+qe?w#ySckdC) zz%9T=NIqEP3gnP2O$WLsS=kS@hfA!DvF8!sZiK!w&L89KFHS*)vX@>Cw4;Un;Ypm!6F&-qdR ztia&Yaf;l~yWZ7@ooKiF4I{xr@eON%H<~z#gSn2)oWRaj$WnE3;wkgh0rX;X^m<8v zoVv{ZnMoMG4V^cfMt8#Rdc5RVpP*ATm4z0~okgY@trQ;tVb` z$zJ8LdqtW8EU-FMpQbRNbzN)!5B=&f=|Ts$f*JIv>}3-Bp|Rui=hrCzpYQ!Rz|>Dk z=QAGiFbDqaBL(+}dg5J`)MZh&$&&CSDr`8%rN+nEwK3j!mX9jjH<=2XGcax2CVl%esDvXhym6y zBd-_;qo>d54#z^0fjcc@C~hRZrM&|;ABX(OeTEs?5``~``UY8S%qrgqfoOivsS{0P zS*uAYRQV%u#d5klTVUTKjf00LS%%F|oKi2hFmeh`saL)vT$uEXkr+CN54o#5*=Gx1 zk(_#$3;o`Dt(BDas_udkDhM`!ny3OB3Bga;%;aWv2;2%>M2{I-9RxAVV+6m7rO;>g zU0C9bQyoiPUcBJ_i0+UVYU}Jp_hX$Vv$o0`E+ul-?o=gtmqtdHt)gQk>_aW*a%lXQ zZ(h3}JYODVV?n_W}&WeKxJor&h;FM#}uN|tMo(opat+VoPcsUaD zVZ#kM%|j_7u{u11Z`xW#BaF6B``f0&WHZ%->QmvAk-AnpEG#VLEaD`Gz=6^}Y|_Zc zN>1m}&n4~a9&^5G=^g@Sycpj9F~$7rM&Gv%LrKS${L&)COJVir-x#|>#U)?JR~+J$ zwQ)0Zw@-P&Yrcq-FR(2zdMX$8HP3%7|KP*6Z-fsn$z=T#$)v0 zyC0ca`ykz>FvJ=cw!7IOt&%E>$OUT@yr7ZCYrUQFedRhLw3?|^m-cqyrrK+Ka`J1| z;K77>z*+KhMDxAq8IT(UWLq8V(XzhjC+X8fe?4*hQjAyXFMlTyyz@kKBfj_ChSY?_W zNHeK#W6u{Kx)yPKwz!L!RCJMUQ{E9KyJzI-gMC-+LDLej14wbw*%9}hPyxo#C6S3J*?k})6hRSN7n`Vs(ROK} zMc+yQJi(V7)oq_@GSj32{Hb+k?eWy(BL7UTJzwSTzdp}#hTgp;9ZN#m>Xr?!cXZz39p%<@{*sqwpK=r2z}3Z2R+Vjl0W&;89eZvu+Sg);DP z?TKwT5MIZKUuB=?^G>bF4Jeemovt;z`A5(}$f28jk`~>%fvcoj$=kjBMmLVjLKt{Z zkw2#(Ut%?cGlj1uzgPpFLdmar{q<<*-jS*3>Q?viuljg4dzL`3p5ubjei1i0gCS`M z$b_YSm`f2HxE`O-o6AysxIJ#WPNcjV)2kq&9SOVkiI!3Zu$&}PYxo(uaDEQ|d!Tbw zq;y4WgcofG%Y}qdf}OABlb)MB_?-l0T4=+x%syWsjyKP%p2p}e*uQo_SYZ4PQ4`_c z@O1W(+Akq|&t*N9Rj=k^RJDX4ZHgnLO8_t*X&G z{7r?7wkv##Hw^yi9cMVwhgJLDWZ+5nE*Ah70rx;h?if688K49ExjW#TzAF zW;y9}3-`yDCy%X-aIZeyu8NR(BD($t61D+M!7V3kx97(JjC-_y5+8bKO~zvu{@A!R z%n>z3>2^}o=^P0m48z{EMu6vA31)bTHTG(gjPCd&ocp_vHPxzS9Lpm@_7PJ9VaAz5 zEBt;s03-UP{*gE0L)!6CL^0>-Ulh=Hp%Xmd9P3>A@$$6VVdyU6g)w^8)NK&kJW zedH#337AYqTK)zP2wb2H4OL|%)a$#%q26nHe8{Al!_O9uUGC7Q3_bpyWyoNwLWC35 ztY+rP%GyyH2-#Z`f7E=?Dz)(W`J>1m)Nx-o+=4dkH@q#Lw_FAezC=usSH#ESuvUm+ zCa{ct5zxc^&Ww2Tm@f6KHIpuTK&q`va5H=jb3m&rHl_7*hp80rJNR_uJuVoiZ{YT_ z^bx;D^Ablm6@5ElEPAs1z(8+UALdH$Cat@CVNrHzj$GwP&x{2dL+pMCRD|j4k()Tr z*)|HkLM$Vr3JF{6@wckuqO5yhnjJq#(zNk6`4T6P8pQ>>k-zy#f}blv;uCt>zQV7l z{BBcs#Z}8?a!u~7JN{OU9-?x4Dhd(vR_L>8Bn2IO_%qLG+U#8KwVHW6hiH@g&<{1@9nOxUX~ON!;wI>|2)> z{jXJ?e!Qs$;lbn!xTnFnKUmzA=3q7-dB9=OP}bQtX6tXx1^R=5e|5dDRs_(S)O0Vw zZprdD)qq0JQCUQ6aut=ms{jg9X-hC@$>~gP3!quW%6>Rpb=jivs}i~hddlowon@fB z^Fj}%Cs%^jzHrS%Z7kl8KafjaLU+|$xI2gkC0m~TeJsn~lh^~22yD0?2)PL}QF$*V zWp-Qr`P9exD{PdgJ%;@`o7YIfN;PtQvksGVHE>@m{*R}8$Lky#Irdcn{Y0M4@K6d^ z$mz^8ifMBMdA*`Kn>sgikZ0_7=L@GQkf9IT`gsFqUw0|3i|k8pFvK7eye}8CX@b2n zddQ(ea=36uk~AJ9^F2Z zc~904*O~%|nnw4?YDAK2$mg5FSfK#i24$(jn9%oNGa!3jUOf|b6UXA==z5q2 zBw}{>r(M=IHs)!#@(RZH2XzkNT3Y*65j_Se?m)bM!6?EFzAIu57?=Kzpf#9og zFrA1e}{>8g5xwbEZE^dzWrC=Lilkf z{=Db9uw0cT*bEsw9z=;$1u@A*tJUmbp0L{P+iOr;n4Dxa<$hgm1brnQQA|6KN|4-! zzf*ay<<4P#D5x1QgR{n*v*GrL`_U%A_k;smAcMLOCwN>@I8z>%X&&Y)GT^3`{nulI zsr1sCK4c5%T8d?$ui;F)cVdD29tAl4%it;UC}(>Jw7mnK#|Z<B2zvRKi1Mu zn^Q!4xk8Qe73qIsue>6*QsHH~H09`p$!k*eBD#LCk`n%|B)q>XNk)1!w<0D6*&;pW zm0RJuW3H4P8O8!`e4?-n=Q=iGpHmoy$fqQH7?FY&Yxq?`do{*Syt4EeExpC_m|{br z=F_%*pvGJD<@sY?-1}nNY*d1U&;5G5GLr4?Fxq5hNqA|ja5vm9Qp(t%2@d-c5a2$^ zM@*iFJ6Y01?4|dpVkvsUs-+P_j0D{Gn5EnqK%c_&IZncO)POF_ev(at)IBy{0y@}k zyOQXsy;|QA57^)3$nBkT$)c#bH;H4irf1Yreo9Ve@c$CZb`pZ^PcN;ILEXLR;OicD zk?nu~*s$PO77BZ;ERRe+#171olO_yc2^HgLz3JIwf9rIJRQWN;p_G8*`=i^9T%Q2es{NDW93$+LVjEmi4^Ok zC4c^uU6SBQ5NhwwvBs%Rcp9nIcaU|@CFyhRkAr`Xa~~}*pnvjJLC^X4_*lcn>$kuv za-VBhwQ)%~Rz5=jf&Cz5$??-EgCqY#G6_z!{bV|VgLjW9crxl`6x@GJ&{?yUDLw?3 zBg{L*M;aF**_T6ayQ@O!wYv>wVCONBl-R8@@Y8$SPjqf+#8brjVK-!S^Y>r3-W>i9 zoYzp4Yd}6Y1ZpW@;vu%J#L_d^1pZ4Jk^LuD9vQ6PX!lrYiZYj^d_=38sZ}`X^5O`W zZxe9c!}R8XFT0D&Mg8R=C48oJhu>s>Ee@_c5qjUAcfT#7!VXp9?)mVZvn-jhTP?xk>S%7_*{6)%^1 zr#=vie1!>84x&Ax(U?BP(IiCRj$zX3htGp6B#P+btR`mAB~zwMGv6&c>P%Xj@Aa!C zl=v~+TsxD>`j7&d?l1-eLN?ZU<{wkNY-hK;ME&jc2od2q#}2*EsjQB>V3$VgZ2FJe zb^U7r7l9&=Wy3|!cj|F~&bxh)>vR0FC$NB*FZ7#TRCJ+i@DUQYd^`h}kAq;#Zv60b z<|RF9wu6zO`5YbD6f1BF5k|6o0T!vffWEgyj4XDxN=|>2o3@ffh(`?Z;F#Sql5(sN zOq*D``h2`iKIPxINq>Gl+I;D_*}dc=|-mmRg#kn|3YPGuy}PJgl0LNE0}7U z7RM;mZkE{M{xyzVj`+&BV_i8&38Q^a){+Pv`w)zS-I1M^CFWV8}K|1k7c_AA#^c`Z|kVv$KYe`w5w+(>i{t z<2(Ds*4({W|3nE6h$%0UwdZiPaCzrR!LPkrM%Uac`60{Aa8W-s_5I2uMd44MHM5l} zUW(+>;r>CW7SN1YGZS-qs^{koI+@M^nd-E~t`%K}EAxd+68YFb@m3jbAWh2FPEFl} z{VB!7lL<2xO%61HI^Op3d%wbgsI8NR6@Ivl4KxfpGrZ#347$0Fb#Qog*24+WKYx1i zj!9F=dqv-dk`2^o>4g}K(#QK%syKIaPz513ljAOvOQSy8Xdk!??npi~Ngj0~O=Nz~ zPfN7DP42GG3{jN%Wbc=*9iAw>ggpsc=z9T@$u|mF`RKP*Mu<*xOl}?Ynq}Dh!^J9j`D{n2*x*Xz>076LbQjJe;qX#&4hMBI z=)*5cUVYiZA5l3xEIJRn)6z)aFmmcR2^Uck{Xh`}10WBN%>Y0i_-k$Jj8@3;+xsq+ zntml?zWMki3eJwhb!JGb?<-e!&=_oo4~e!Qdxn1{mHBJxtt~lueGh0nWbJ={5+i4^ zZnifubShsYN4Z+)$AEz&0xSnEL=1ezW#hnS#X!H4FsMv`lw8QvDgH1Z z4ICRG;Mgc3Xwve8K3%#eqB)2|NxKMTt7ua2sjS@{yS6=qmmC~#Clu|Mft3T)V0OV) zo{Gu2g_Zht_;7e{DZB4-hG5f~=ETQv>@s^i$;IphWdU4$Wjq4RdFLMO-PSs!A)ZB@pTVs~HjP=QU2XC8lUB)u5I=3lS+5>e`yc!j z0&zSu=!}XpjgmgD%Y!C;1Ak0y=XO?|9>8c=|G@7!LCf9uk-;A%}SnBCxO2hcmXED7Al2c(E%_uBvI{>9_j!- z^w*Cwj{godro*S~X@7B;p+|{65og4+m7?LzT40$6d7EPELPDBAtrf=}L^i>r@?=+x zSgGa0Z^ycicrj~gjjU==qeO-{oox1<>cV{zKX_jGM`GAp@&PB57px|o?+ZR1iW#f} zFD!lLo#Z-QlwN8#0JW&w*a9QP)VfrD1ApP>c+sHH3~386>sdYqe&l`?|K)_1WEvEj zJR>*h~qn8%u92^v6@wu1pRu)p&Vf8l${>TMF=8r$Q6>UtXP zi1aBYt>)U=m%AqGvkyv?;z*w*f8XxjE(9-&wb=7v5%AE^@Ca2VtjQ8wpvGZeMuRnK z)pG136>^Zna-;>JTee?~Ws+LrVh41~f#yl6>!@fRb-W1Na^Ymst$2#a?B{m0@?G#N z|5m)PTc$9xTEGdbC*)&xiE6o>cykOKuAvv$pF-;OQphqge(jM zUPfG9t zbtJ|*EaK3&v3Y)|94%==5Ng-Se8o4vKv?|ef~F8j$JhSt7DlbG0f(WT{{FfTtFK53 za#gTXEM^&xfo5nEL<4&{Fy)9eo0rhzhoUQ{!?%~J-RH&l+aAZ zj~Fk>!C-W|IKF>wQ9eH{ed0QYD7D|`LM5tyXfa_D+3sVOaPhxB+xDG0i_W9dgs-vP z?YGV?8{8M-hjVMRUw2EMyjbOPdDwk_v?+>PS+2wSuLJyU+{x+kxhSuniJ0g1KDX^c z2R)F{s$oit_i{6&Nmh);1jeMb>$@waA^WQAs1OH0oo0A2#1_BRsMv2GZ`h?sXUnXR z5!C;o|3^P2vJ3_?ur`PB|r!V!qd_bd1 zE~^h*r3r6-yFH6i>@6e>g#sAw!ztuBg^o#ufH|_D9(v^Ys?*4`8y)#6OX^v|R_@_8 zfvZ^_iYP--%Co%eO9QJD{tN_eG4I^{R9z!9OjZ~%D`)$Y@DV`5ZNMv1p&Bjkv(jzb z1Q8g|EA)=mIa$J5B^%mFoTBWLR5*C5YTp6D2MgZN==+qYL9X2J+&^_Zl``~wA>ex}rVsepj#=&Z3qa=fN?)P}S-ZlTpWzPaPfq5JCj5YbJu@%k<+#Jg4o_q}=IT zEprMR-RyY^61KLv^`&l`XNT`}d%1w6@sSnkxNoR1Q;2mfb;Q#Us`%Vh!%staIBbh7 zZ9g|F|7>p`?ovjmVcoP{CrRQFFI@h*ySbu2+}dff)0CTom=m-rr89L(7;z)nyth;H zKw4|66WfInS{`bN#_|I^X11>BQ{uT3{<=O}^d2$MWTNpO99Fiya|Vf*KHtv-hBySW zBhNJ?5@?+r1~}zVCvau$OscUeA6cJhR2C%_&?xufM`ik+dcg3ueGe1GT5GmU?>b3> zO34}W#dPYA-dp$E;ZpyS&WM@$u~`i=3F`5RvYV|^nLm;c;ub9AU5KP&L!anJ z7X-*62DU_wib1(qM|bBNh-G5yS?(PobEHKi$%4YHAa3v+jJ&#Z^9 zY_G-fahNF3SZwd}+8#vwVkslc`y8U0j%$P7`<*2~C$d36b@ozd?JyiyDaTDDyN92r z$P!Z(uQ+cv_L=fHs9^a)5s%|xY9zrVVj@K-*k3PJ-n&NVJ|3PEL$v$FFnyMHYTFfm zmwWS_fT1Mkx?3b@ti%yJXht_k1~hZ8Pq)oTXGpVJ^UkytmV$kxmV$Vs;m%bApuD~@ zj|WgS3*7f1PdF@88exvUPg% zT5v4vW@Y+bs-@AkMqAsfc9P?8C@Lqb(K7NPbbpB@l1Ac0`c-UlBu=ER#ate z>+QjBS&8l-%&L1qRYG|ie?Fn*_baoAohFrye5*DADp73_O15{xc&j_OAH@PpqGd)d* z#MeKZE*?G+7OsE$G~i0-R&J73nBsEnMspv>_I_$c>gMEr>8AbqN&d|Dy1ZlEhDe|Y zQk69Tg*HGXsio^pGUf-J^(FlcN3QEMwu#C4fD4CxrmkQ4-&Wo~L&v~K9SFkBRyOd| zTh!f8uYXmCYr?SMr_Fk_#$XpxmbK66HD?EQ6QHDQiSA2}peFD8sZj>m?`|i?7>F4} z-M-H9lv-<3e5q9zljG+&=gg!i%Co|9Sa83naWgMDu5y2-BTV=T;2LchA5(NE_a#du1zq2wC9J;RxfD2a0`2%eN0T|Fii`w z(qpLgxD8?R5wDj_iO~>>2N4a}z*=@b1sv;up;=A9Bg#x%#d0gt0ZDiQPAoQ;i<)3` zMtV~L@;+awr`>9)tmp19(-kxn&G(Ho=Si=+Fy_T20953g0O+N6?9 z?!NuFEK01F@e@>PYlBmq3Il2HIzA1o?-y~p8sNg~1!uA6XCL4KUAACl{HKsuLA5Be zAUMf^ZIQdkgxKMjRww^u_Zq+tvxwzY5(#jx`OWiFeGu^ev@Y?R*rtFlMOhk$e#(dVzR2o_(ioEBJ;9n1kLzUs8)8o~tkDI>kPtBN9LBa!zX7 zZy@?&^i;7dla4lD2kecK0&(8c_PD;EhVb7tP!RcF{$c&v_qk@ty=MsD@OlOhU+R_;`y+hNW&7+768sy zMT_~KLJH>6DOTFP)&3Elblb{<(r+8%6=#aMwD}G?bQkAZ!FUO>3ESJwDfpcNZm+8- z!+}l?bSZGNolobuJsqSTdrFw#nTaxMZC2OS86iow=_GiLvE-ygfmdVX6AMAZk5o24 z$8!g0EJHiX-Qn7GH|3p*_u*-{TK9_rl=9vJQ_vP>+p4U8Tr8?P(fmN*kO5wA#PqfH z0@tT(Ob`Zd6kVtq*$7ew?Bx(vg}$9Nts=wm;s=c!o|2Lhy!+F3SN!bT^mg2A-?RDL z1E^bFC@xIP!~a?M_Yt{+3s}!o;Nvebn?W@nbdd-XtDo4oM~>XSkr}-k^k=zZNn^Py z)pbw(HaEqqZ~9QmfBB}Oi}PW`P51MwWVxZvNCTr6n48Eg?f40N|7lbcRvfLYj;PW| z5lXpA1$HKc&s)JVs%ws&SlrH6UHwz-uRkH3Q*q7Lto8xb{jGmWjO_Gv=B8HQK;-qO zLCekN!5_m<#{#GvPT>HJjYM+T29i6v2EN2X!0Xp?x!^RQ;0d@&;cZqNP6$Vc7~P3? zEr7W{J&%|k5J{M?Y^l@oG3~Q-8YdWu%vSK#!1Q-2OgY_K=IJf40S{7G`w934?s}FZ5FeEsKI+0v90KRJ!#jh4266~NnG^aEA^l^aZ@qFV=}M#sLm-nzHItAn+7luWqs30rM$v1N5zha`h6p`-7*{4rEO7~ z71BkJH;z+)vZ=gI+{n!&OATXejbrXX4-6blHe+jqb=A=;2Mf)yc4TydkVSvEN`W7{ ztTz#2rG4iD&Zf=}Yczfj0D*bq=;-KEdek^j=u=tS%n!p}8Qy~zPxv;gVRCW7bRgi5 z)t?krplBF>ze+hv70HMXz}kByjSVo0*Rssuf)?w90-h0jEuMqpxA(9h2M2sZ!+Hzx7T-xonmQ2$p7+2(X69tw!fqVk zU9(j_fN|)HJUw<$*HvJ4-e6!>m4QD zKYZ7vZ#ImKzP*{zotkgmi^fzh@J=(2Wgfv5Q2&PJc>y@!jfVp;9;yaQL!<#>==C?2 zfhQTMJdM$^zE%$NBiIqmaGqy56kdxa@nLxbbpVKJTUOHgtoAOSlp_-p3{m_FU#(Sr zpc;0e3T})gBFA`j2BO7wR=-jbsaL#2J1pu3MU3xR(g|H;zN(l?(I45DCIWatvcJ6h zXkl8WelN1pswIftOkBrtn$3N}=>{iw0b`cD04|a85XJm({Vny@aoKSAn;MG}ijq7e z;}jx`Oqz0qzR6y`5EHDcZ4q``oA_xT#c?W{Z`8_&EVAkAJ%(yIimP>q>rIKzz)TB- z*?e~@{JAZZ3=%ZrhrFKtuJ*)U=Red25Yd@o9@})&2Qv;?i3oM=VK?pnEh7QZaUky~ z)Cmk_)hWj6tm)B|SK2o`lDB#hK)TCbyWKXj^!2NGwtbghv`BlneGt1{*6VZ;ir7)& zkPW-H#Y8`@*ueW%D=OAxMKDz z-M!`pDSwlT2LUvpzZTmB?PE6O0|}`-?(TH6%mhG$mr37vw6ER`c-T;c2!A^B(Da#Kp?UeK^q9jPdx!Av}^I zx^L%Arpv$%2E+D|U2h%#cH^Z1UE1|G(0jmnR{RoXA@TB`yyO%5QK*s!LqZc8w?U^OIR85!jvQrqjpx17 zz@V-M{<2RPkjUJ{c(3o2PN|kigm`tB#-t^@@}spJ%ro{7i50IYTl;KrCloN*}M0W(jbb4GnpOnal z5m-XA;5fSreesf(uo3N6g}O&5EXe7wN`)M0%D1`#Aec`Jyo&35x623UJn>gxj2qS*tIOt!L5dNR)MshVMq8Np(6h`K?kp_9Hvq&cp5vmuK zOd8fdGezU@(ut&zT6z0;+m7p37*X-VdOH&rTqJ8pcsvgR_fF@B%~F}Gq3a)lEc*pk z>B&24!hwj+BJR)0(vrx=Q}gd$<&o5!bB}&o#Zz&1t_0yiDI4Ym*D*8iE(u_CeSX>% z)1F^pUR0-iy~qsisms}E zBsrWC;K(rwNcn2z@LCXqvAGxVdfu<-+QH#Y@qBYUbad( z(USL#VlYfnNH{0kU5h51j~NPmldr=~AOVd8xfO2eI}=G=aT`)@i4mtOqY^^pp%20h zJHi}BP{`5ssWlbz9_u${y-Nh;fQ?# z_|!1M#=S&Sq7&m&0*u1zc%`z0NFo7@R2-|N3_1;t3$t7m6QXb|h?M1Dn(*uLi1-I> z2(RKD-sHMN)wnceYfdB0o8QCyFHb1L+I@}LZ>#u*`0elS0D96GjEK;hDGQM-?HC=4 z#p5O4Q4Z0ogES%&X~V7|RND*;yQ@l`jFDN3Kn_^T+Qk*1*`4tO@f3-bUv~~o%YkaM z{cnb_jzPfu*s{+d@;TpFAWtWTkw+*x;gdK{7j0#GZtv}6tW#m z-RnaC=4jO7l7fRA5INv%rTx#_^(ZgChFqY4wk&e|C!Tl=eml7}*+~?zSg^e<12r~I z$KtM5%0#`yZk%^sbDs7tU?olYjSjsLi}y>(B#xPBZvb~TY~(PI7+;~O3v~ciy`W-@ z_-P16m(D^ov3U7)o*_-jI*4oV773dx%!%q9R;TqKx1c=sJeX#ZWe~Ja0A5E#cu|=D zSX(CoL-12t0#qENOXN3UAE{>h9og80Y*h<)7yObcO%{aWmm1edKYlB8i$X8u%M-1l zOQ(XXAB~1j|H^YxZ&)!fmWU``CMC`VAc1VLxzST=rkLDLXQkuk?0`TRfX!cY$3MNV z4`oAV6tI(3d#k@9Fj zKfmjKq7<3F8Y@2vMwkBZbt$E$UVrs(ZMm|D1E_DsOZ}u#p|Gtdnj#8y_%K8I;U&iX)JvORw};WItN=sk9RKi- z9TNLY7bRz!z+>R0N<|{1zMBg+5G8rE1v;tWl%g*+*3$fV{LAInjkmXJE6*<7FRy@A z2(RwF$;@q)C6h4nUf6xB*`qqq&j8yC2BP@#|LkPi9r>ulSAhw_rO))l!g!EOQIi$L z=WK)cZb4?|A5-PJmEeWg_U}x}d6jB$Jv>>w(~X+`su`Zkq2M)~YP5>k+GO2td&2~} za6Xs*;pWGF$1%mi_~tCx66?HQY-JT@=u3ja89#k?)AKEhI-rIsQDGtOCFLDyg3P!D z>K$-!9h@;y-&yMGa$v@%0bLUV7z|$<`LX6~)PBp-r)u+_el)r->PLOI_hPB)%xTVd zq=m+C35$1uDk3s+vMfeX`=;uuOyb0+Vb>k+15FV;TIwDkk#!lBLs6LUy~6?YPqV_{ z8+~#zEHL&@p}2HpZ&=(E-E-w_kt?!7D<@JuaEWotVw(<7_61VYFErdcAo$FD!j*oe z^{_Z9gXi9V6!VtK-mu9=0f+3Z?6E~=gV(SaqgfOh4VSQX*$`qzH zL9dub$HTAI&!FU;tD$(*d0cj#Gc4ao6v(mIeA(NHm0d{3{Hc^qS z!CF)`;O6&R_kKcp4~1XNt^^>}YHN~S1{eH(O@;BmFW{QX9yn(R_vi@!`|%(JTNhUR z9L>Oyl6xoNn7Afx_Tiv-v_v2Quh_KU{DESCjzfAbAE0i(9d_O=4Z!{9xOEq|-I3rgn1VfU|(m*w0#I43qkrw00-s~7e1P|rSS3UKhd z;r5JOc(-vCn-ttAr+vddHnitOOVq)1jL4n8 zuLJ(QfMeLj&|8rghLS~!nb3&Gdqi=^-zbS#GEp?SnO`qYDWG+W!oQaOKe-9V=wl}p zj|ZbdP3VxB?Aw!prlpqc(T-{hlZ84rX8a^Ek9@N4FXTj;)oI#g2{uV7mxjcFl9@R}EUF&OvPuuXH0XEGW$SxbqZWplHBJ;xQ$cSmC0is_C)|}o;d`Qz zI%T>uQ@!=rJk<8um`fyrRsP=NZDM1>+BEvU1C1C+$@Z#^(wTloRrD<3K79u43^?GG z0U3q;aNL?)*sRTBGA{xV6;<_nT1*s@WRh`!HpzBWiMM$xO0;f)(-1LHI62a82tpN$ zVqRfEyoLl?hTTU6puV`>LFUD+uPNdOLoY=cz(92Rw&ML}nyeeJkrcuQj z;Xx>el)$`W#E|W7t7lu}JPeN(0$2{DRyMfe`YI~aiykXjha>klBPQTpJoa{kKJ}=J zN?=Lf`2OzumF>HIK|+>5(svmi;sT0;n(E#&sAYhJ5rpea%&h(M=!y742?l_nRHN#t z7a=~Agdlt9!Mj~0vE5B4B6c7+`6CF86&<3(3z+j1>dEOatzG8-Au`MXJPV%te{C7T zqltO{$zJtPJa++fR_-agk=UR@p;n~FUo&l&o`b$sbQ6ymEPH7%kw^fb=uZ!=1lh{N})=vwo8E4J> zVK>}8(|$d`tK+j1fQS+?H>bn>_2N5aDBtbEyAe4KZvfB9LMs5`^t$8_!fd-G;+b9V zvDg%zjvM-TLP{hgB$m;$QLvc8272$YrHBt##6eI6;m*L|;2-`2kIrB;RS5LP8W_cn z?n6Fu&9E{v6M_gMmfO?At6tO_|HMn%M**Px#7)W!tgXR{9ks}nGPps)jk3$-xUv){ zwN%ljM5(23-3SFO`m*OSKmHI`v_*H7gr^@!Ra>lpMszgH2cOAGF@f)R3ZLw8o zX|K~tPrpy!Y)r9RLKx+Tk=t>N(Q%I)@(?@_`@RaduarZ--^lta%5RSs#csuWQU!M% zqy~up{6O7}iV5SnyH_iekN@zJoxL^Mm;IL^W#vfGNVZkyUZ@m7@uBBK9`QFpZY&~_ zH=fziucUKg>PLiRm;>g{1VC(L%l_XoX$$}oKDUTtdU|nSoUM|8 z2rH9|gXJ-~$oeRDT`FSNl|p{l$@tP&^a;hXl3DU%^L(fvcz00Qv7mnCHs4lbj5hcP&#f)5ZQ8A zF!obLYO-uCHPl{rBnjTYWGbK7CtUQ#)IJA!m0=Exr@1LL&s$#1z|bbd9MS_>V>qPD zfV-~MkTNf11&mzY->qq9AT){;U3$5sQ&vbeNw4~z!&$@rsmoo~yT_%2CLd;$3RYI_fE=q+rwW@{RvwLG9Ibn=D)a?|s-S!z6R#b5!Y`Rnl zL~VCz+%^z^zbeQ{VZzqKzh6?jv&Ydu*sZ77+iw|v0x$O%fo7U7nCZR*J!5g`dV z#vekYiWy1akc@D}ysg^_k|%&knWXlxef863xu6$hl2mU&=|t&*ZX(7&Yp;HFZ1N9 zK;$tu5X;k_?idH^MKHwfCkiWMy)p}(0VXGs=36Nh-@D*B$-sfA$@x{`-F1RboW2N$ z!k~6dhCr=Xzf!nY$xWD3x3c?IK`|I(Qk#`;E)D(U&Ljs=Ansn7h;wKV{`|Y|_`VQq z$sC1HQ{oUXx2exo(M=!sYMZA!lX}CLz#@uigI5z%l{9&P%J12DRJ`Cr0) zlLCzi_ZQ&Kd=osXun|<(ttoa01hues*UP7~*pgcTRQdSt9b;aiH!L_uUUcC2QE9!Q z7qq{THMtg&=E|?RoLr<&4HbR^aI_qO0>|(&M(|%5Q&GJyTfTAqUEWh|Syk;mK!Q-9 zT~AxAR*`j;m#zZ|Pq>Pr`@A2O5~k!LVz|&%_2nZx+b8M)L8k|%M z{FDOpa^RzUvk^Mm;o8M)FDqLZ<}(FvB;aawuw}z<$`0)CGJML&*;qe|xr$gFm;6_| zzyBpM-ncPBVs3?$JEuU>BXmgWq=CQ-0CKVrz@;g65 z@!1?iyomaq4V|;+6`BMkvlFfrrV5v>AK%e7oGrFiB7G>PdoYM06MV`=G#EEPo0z`> ze_ro?;t;@ocLb?MNmtkqz%$He#r}%`l$F+QxHTHA%mLgH8gas6l>$DHmde_Ftjj9M z3pWH2{pzpl6r{_TFtqxZZBCfj8JwMXy8{QnUhHk~9~sp7yz|ifgo^+=wDCg+YYYHSxCQV;D6S7COB}kl778aEb$7 zgvG&afY4jgxd#-IIeXKUhJzyMM&;)n@cG%~98pH^LS@LIB~2qmIzjCwM}i~nW%ggc z;}b-FTvrMv$nm3HVigwUbedBT^IbnT-JjkL3`R7|YgXNCl5sy(Gz@JX_&= zH!l?Ghn<4F&UbypV*TP=EM!mb3#yVchI|wp#m6eiB2=wkmmq(zaZ-1*2=!^D8v<-3 z+F9fIH^3b~nPJjFPtw_TFlBvZME6|wG@wt3&^uT;`h;Gb?h_>s2pQ%88LM?tV?aP^ zlMtT6GY{`p$OtA&M-KB5`HzYc;nt}zYk*l9?J~{Lo4*|yPV6Ju&5SUc28~k9dje2y znN$;?OEoeqb5J*lDc`cguw?fGPB8CXC4&fy{F{$+=OkrqaRKS|M)QPe)NV4bk3S<>umlUL`9UOQbmw~{JH=Q1x8d;*W=U{x3$+s4 zCte2T-NR#NwXmPKiFHO_euQ&L%rR+8=1g55kVps2DgOF{Jo_fU{pFGD<=EK)*uZYH0k91Z9*N0z_rW=lF*S5Xl9wa)#AD1D4&} zDk$iuP*9mMkUA*@h9-o!N`kjvNvwlHpK#e7sh~7z^?4Y?2*9UR-%c&N9tj4U7Z)ol z1@{^1vhH&s^4g9GxkJ3WoUNYrU&S{$wj00vX0s> zH$v;cqVjmpo++EpjmG+l{tO$O{6gkkG0)eehK$*n0%>JXop2x>zy(O3{Mn@QqfN?r zQc}US`U`3({74TGAvp|WQY-9}-RkL)=CBw_;o*0`Meo6S{Rke#fQm-??{E5a>~QZ7 zrjyuPG?sw4<3D+hGmTLnuMJK~M|XF>@iWmtY2m$@ zB}ryU^47N%)>u3lxOgyN`|ZT=Wru0O`)*m@d;Fu|Di@shu?8M@0|G&$RgtWClqcfi ze<=e($dKj`hJyUm6Y0pKrS!h0ay8*1Vr{zpQ|WyUvNK)x9>FrEL9^E zo=P97TexpkJvxXTwmwCH_csZhz;wF$gXVgtY3(z_ta-9QUyK*sg#%pH4o4FiO%rPw zrb|(GD{(cI zD^g6dGg#4lHRfwrbRcLP?G=(y zKI$ZJ55M{EDkk>c(9*T;62Kh8F^Jj9giGKil=9r1Lz4JWp5Zp1$d_1G`r64w^=S>p z#7k^(^H+N85IsaP2lT<29uoPC5dwvr9?u_s8!JM|$v{61<5ZPEz^0cT$0<)z5r#u} zdTcfg-PQhV)!CQ;fbkK>v%a15ub7 zwapx5~_73kE0YP}91 z=b3hEm)tY4esm50vRv^Qfe?#;SM)Beh5yc{Q?)4*8`l%;%!D7gc@BwhGZ5;U%E#YZ zc90sid)~P`+Oo{8n>KpF1R@|h(b}f9KL{9YtL5IkGS#H@uuD@IA9u(f^2am&h6H$&jg-;WobsGKix5FZUe*$gc}z}*r6w;;*Wia4`C*np z^ASJPsHT!dVoo7IVAk>sQe0L>fQW)kxY83%0Pkl#e*D;4>5K%R;h1+efKR^@u7i); zC1Td5qMV1CtH~;==S=z5KCqXzN?bttFU1XC7Psl$QmqC{JB$_BA9m%)ii$BgW(nhf zcJ^$PZ$5LriC)=M^<{nT<(eF7Kh|HaKw~Dallf-br$2e__ijxYRCp3MK~McioIyZvPDOX=iF+X29Qno8VK-; zA3`l_I}UDezbF7sbkvmZ`|L;7%-m1gXxSX40KR=MH~BNn>%C7=3FN@|$Q0cG>Deg5 zS}^W?Tq&jW810To3e!TTyg2{k46B#&^2>8gY@`7AZyLiNe<*=Db*o^k-O!P1d?qKI zQ!f>c0yLVSrk4xwI$G_A0ovvpyzv`cadHeWHlf#f#7#Xb(GOkx47&Z6-xVIWA8e&R zN9T(h%6ZYL1`<1GzC%%w{BS4LJWRZY%!>;fT|uiWLO1vk;g#_$buvg28D`H*ucN+2 zq4|_3R}gSBdF7!yfUBk#qmiMUcikzE5AYMxdV<+X4PD@03V(*4&ZKZ)Ft^AB3}r2` zd@?U<3P|LVwzjO{0m6r?iAn<#l-=Fk*0I-sm&lN}?haSo2O@AElK$JjKR@Et(H~le zpZ}Q}dw(hh&Doi@nv6fr(FDgq;m8o_{nQtc?#8+5o;&#@M<*tp(LMQL5=7L?fgpNn zwHXH)Z;DV=LGo3!wn<%TDF3Gm+lb{u^vg{@c7mv`g|{!{E!R>%K=oQ4^P76^M8i| z-2~iH*8&LtEtj1js>uSoobbI`kZh*JqZT#) zEoJ(#gajtwVt&T4KGBrP`g($=DN9whAuxh5@`JTLU z_z&(xI*c>=gvR^JbPk$MM64xzZ-#F`AmBaq3{hpo@?B7ll=3_{yimhG{8uK#Wjq{A z+VgY@$)Gacv|2oJ{{sz&yp>XTQw)#f_&PXgGYy3w#5SxIt$j+~U(UYF&0|)uUCQu; zB_w)x18v)zl2=No{URq_2|*&-CMhMHMv58n(Eb#b<~OEiH4i^)?ej*`r>%t3uWf-A zcZ%=WIWgA>!VSp%mq7Z#T*{7zjt6O$fD6LFeya^s2zWBcdsrYsMC)(jL+G~Ef z2!wa?1QM#<{7*XTh^7}H;UfWcR;E9`a5_&pT)>C;aO1Gq!Qdm8q*UK#lrn~`KZ?5q8VrQ@4!tsc1&;~ zzp;)nAuYyKLZuE**fV1!4TCY2l@TKKHVlN1{Wsc{)y|=u!t|}$P6=d+xS0j`JXF`h z3-)dmwZ;#>Gcbp1sdzYM7br2*cBY6FPNq_P^ZtH5W&W*L)>g8i-y1jp9Ug%z93Eh4 zD~d4ziXZCDf3-v~NlGH!%th1oyW9k)e`O*o?XzIIAwUR&CkhOnj+OT-Gdo6)O}}83 zd`9Q9noB87`Guu#5EEp=i{w3dWK{It76hgi(4?h>JT@NI8(nMD=Ice^;G?j(2fqUF z-VkuSec4>DBy{|$Pukv^TrPTJ3lwI>!quA~zrGkg5xs+p0-!7(<#)(IVH?K?s?p>S zx)X(a;t^I1{l{J)(Zo+uLN?b37IYJG)qHXA!e(xjbBI1{wc}{~{%(r>u!I*m;_L-V zBtYGmKBA$frrPl%@dZRD#L)@d(q2$sB4d-0G^FGjKKlD3{I8Y@rhD)y&16=+9p$au z+u!hp642|T?%=BfR`MV(bubj+wRE!m0!yW5e5HwRo?#sqiH}?(el2<$aRU6jEX^^rXvkgZn8Ldju7)sV{GG0lr-5vR!qku)O- z#tYO>=+g)i`U{EyA|O%fg*BU})=LoWhf}3K!TfUVPppL>LejcQKwDR-u8u-N6`d=< zOAsc3@T%Ffu8kl(33<@h0It+9f93z`VTrGppKOeoN?F|=O71~B&qY3lu#bHPJPJLD z?wb$6tE_!$VKxzMZNGH@nAz`@;Hu2P)^n--1R3zxjo{*lb3DL!ExcjBG782O6J_Rx zQzyv({r+LSIS9h^QjG6Elc&OOUz)axwGv#P;&TrkF-Qfk5;gk$)`9c+bSo$uKjmOu z%UXl31fl6!8~q&1eXM389pqBJlsQgCG&s&Nt^)r1$1Q;Ck_BAT?)Gngk?=t+9XGu! zadR=kY5ywyW!|qUsU}EnG#DqjghfI&Mcj-s*EvpCgLo|9^O$#B={J=4TqUW&9XR*;il$FPV`Xtsbl?`9|5MZ+(ldFP8F2G zO*wzA!_9NGS)0vAmTNHz@Etlh)tGs?8RXc*bhNWxp`uZQUm3wSv^#(>ZiG9Xtr=5i z1mSB`q_EK~Ich?#;b1sRk^#CZ^$hkcZ@re!l%4ObWv^Mp=)>SfM0#Gh8PGtxzCdG? zjHE3H9=iA^X(*Z4P5C>@rIpIh-VD0Wzj4s-a~{NDsaN%`g8z=i{_^if&H^&fL%7_X z?BDMM4gFHgWK$RQQcaygkO@E(8&>Oiu=uB|AW5Sl!8828SIdgljjvpzjg85V{uW#T z&&W$OTIDL#yu8{s>JC4H#YRFe@#k%+nG1dHOIJa9b-lD#vS{1cb5D;b+9POXy+&1t3`8x z;KDBsYL#^`kH_kgX1UZ~D(1@3Z*tCh$R`z?Cg- z9>%ahXaA8YnYr!fl68)HN1Y!Ex%{+{4VAbRXu>gBJ>-hp(Of5=50*}Wnm$$Y;x~EL zrR4;gXB__rT4Y<^P zaVgv0?`uRZROLyis=LXC-`DyLY$K^puQdSf>fXT!97^Eb(8aq?yovb^j{pNO%69g_ z>Kj)BO{pL6Shl+6yvXPV7Na7d8`}E);%_fw+MfAWZjS2Q`@qXaPru;S$y{qy7d5Y) zgv(qdR<%Cr%R~uO=Ev-d$_v2GZVPS z`RBYxdyhV0oh);Eli%eJ_J{xT{dfKYypCfnuzhXItaxvMa=C#e)314lIE56iPmix( zU$O^yS6k7R+4tr3FVsamH{IUNe@-@R?GfPF!Ii)xCxzTf8W?!`1r-{qxxzLnK9y2D zVheZqllfg{KQI2?BOvsph2uQ`;p8oX^$hBAmEs$7N>g9jNq%fzy5>ZGJCkm~rQFjZ z$&!5sH)=$+oDlZmD)5^l-Iltk;74MFP^agSbF2EFMkGbrBVl}O-n-YwpSbM@UM$~n>|k~8MuSalESz(19oF2J8Q2Frd)vkPm2|X1!@cKj zh8I(Sllu7&gfH+f2Btofl76l()oo2Y+p7da;m5)7`SXs5NcZWWJbUdquVM+Ol})4duaI~#>$Jc zZR3l=#7MPcU52wKn~M1Y?td-3A=w3~lLaT$rrLakXlZh_3pg*%s<9z*GOax_%{R z>4Q{x{J7Z2_~Bs51&1xa6!L&mC!jldRbUa)!WL`6`0PyhQ_!#-P@*N~_?K>lkaQtn zg#}Xh4%((x33+kSYuTbQ3q{bi${d;9d?F{FaGAkWErNE~OkSuio!N2gVM_-{^N~Kk z_0v|0=0M$R)C|o(Ld~l3xnkyfDvi}$z_vsJOGU6-(_poi4#dmADhjH36IAnrIV!;2 zq_0zeN8P^q_U-PXUw=5aP6t`mvIKOl8Yp1uVQzlDV)q>dP~&3SNq#kt$y(gEd^)o9 zuB}uC2VaLYr~m|N{m2h3afA9o`E`hK-MF9XoNfw0S<+2_3Q9S zp63j<>pQS21gp@8so>c<{oJ-FJE^l5*e}`w`#h_ZK{vrWd04@0lZV;Xc2BiGLfxU` z*})~i8(o2>fQ}6VhsQry%=!fYYpgXA@%2jsw}O>S$N?5kAl8xj8Z&2rg{Vt#%FO?D a=l+V0D-5gpUXO@geCx2`EYvx diff --git a/base_classes/NXactuator.nxdl.xml b/base_classes/NXactuator.nxdl.xml deleted file mode 100644 index 3fe0a4108f..0000000000 --- a/base_classes/NXactuator.nxdl.xml +++ /dev/null @@ -1,127 +0,0 @@ - - - - - - An actuator used to control an external condition. - - The condition itself is described in :ref:`NXenvironment`. - - - - Actuator identification code/model number - - - - - Name of the actuator - - - - - Short name of actuator used e.g. on monitor display program - - - - - Describe where the actuator is attached to. - This could be an instance of NXsample or a device on NXinstrument. - - - - - Name for the physical quantity effected by the actuation - - Examples: - temperature | pH | magnetic_field | electric_field | current | conductivity | resistance | voltage | - pressure | flow | stress | strain | shear | surface_pressure - - - - - The type of hardware used for the actuation. - - Examples (suggestions, but not restrictions): - - :Temperature: laser | gas lamp | filament | resistive - :Pressure: anvil cell - :Voltage: potentiostat - - - - - Any output that the actuator produces. - For example, a heater can have the field heater_power(NX_FLOAT). - - - - - Time history of actuator outputs. - - - - - If the actuator is PID-controlled, the settings of the PID controller can be - stored here. - - - - Nominal actuator setpoint. - Can be a scalar or a vector (of [n] actuations). - - - - - Time history of actuator setpoints. - - - - - - Refers to the last transformation specifying the position of the actuator - in the NXtransformations chain. - - - - - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the actuator within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - - diff --git a/base_classes/NXaperture.nxdl.xml b/base_classes/NXaperture.nxdl.xml index 10be4474fc..8619be18ff 100644 --- a/base_classes/NXaperture.nxdl.xml +++ b/base_classes/NXaperture.nxdl.xml @@ -45,7 +45,7 @@ The reference point of the aperture is its center in the x and y axis. The reference point on the z axis is the surface of the aperture pointing towards the source. - In complex (asymmetric) geometries an NXoff_geometry group can be used to provide an unambiguous reference. + In complex (asymmetic) geometries an NXoff_geometry group can be used to provide an unambiguous reference. .. image:: aperture/aperture.png :width: 40% @@ -59,11 +59,6 @@ other component groups. - - - Stores the raw positions of aperture motors. - - Use this group to describe the shape of the aperture @@ -92,29 +87,6 @@ Description of aperture - - - Shape of the aperture. - - - - - - - - - - - - - - - - - The relevant dimension for the aperture, i.e. slit width, pinhole and iris - diameter - - describe any additional information in a note diff --git a/base_classes/NXapm_charge_state_analysis.nxdl.xml b/base_classes/NXapm_charge_state_analysis.nxdl.xml deleted file mode 100644 index e0adb79803..0000000000 --- a/base_classes/NXapm_charge_state_analysis.nxdl.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The number of also possible but different (molecular) ions. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). - - - - - Number of entries - - - - - Base class to document an algorithm for recovering charge state and nuclide composition of a (molecular) ion. - - Currently ranging definitions in the research field of atom probe face have limitations: - - 1. A ranging definition maps all signal within a mass-to-charge-state-ratio value interval - on one iontype. Facing limited mass-resolving-power, there are mass-to-charge-state-ratio - values, though, for which not only multiple (molecular) ions are indistinguishable but - also for which the current practice of documenting classical ranging definitions is incomplete. - 2. Indeed, ranging definitions often report only (for each interval) the - mass-to-charge-state-ratio intervals surplus the composition of elements - that build the (molecular) ion. - 3. Therefore, classical ranging definitions demand a post-processing with an algorithm - which can identify nuclides from which the (molecular) ion is constructed - and a charge state possibly recovered. Combinatorial algorithms are used for this purpose. - - This base class documents the configuration and results of such an algorithm. - - - - - Input constraint, list of nuclide_hash for typically elements used for the - ranging definition of the ion whose charge state the analyses covered. - The list contains each hash as many times as its multiplicity. - Nuclides are encoded using the hashing rule that is defined in :ref:`NXion`. - - As an example, a ranging definition H:2 O:1 is configured by setting nuclides to - a list with entries :math:`1 + 0 \cdot 256`, :math:`1 + 0 \cdot 256`, :math:`8 + 0 \cdot 256`. - An empty list does not release the constraint. Instead, a list with all elements - in the periodic table (encoded as nuclide_hash values) should be used, i.e. - :math:`1 + 0 \cdot 256`, :math:`2 + 0 \cdot 256`, and so on and so forth. - - Keep in mind that with a weakly constrained parameter space the combinatorial - analysis may become very time consuming! - - - - - - - - Input constraint, interval within which (molecular) ions need to have the - mass-to-charge-state-ratio such that an ion qualifies as a candidate. - - - - - - - - - Input constraint, minimum half life for how long each nuclide of each - (molecular) ion needs to be stable such that the ion qualifies as a candidate. - - - - - Input constraint, minimum natural abundance of each nuclide of each - (molecular) ion such that the ion qualifies as a candidate. - - - - - If the value is false, it means that non-unique solutions are accepted. - These are solutions where multiple candidates have been built from - different nuclide instances but the charge_state of all the ions is the same. - - - - - - - Signed charge, i.e. integer multiple of the elementary - charge of each candidate. - - - - - - - - Table of nuclide instances of which each candidate is composed. - Each row vector is sorted in descending order. Unused values are nullified. - - - - - - - - - Accumulated mass of the nuclides in each candidate. - Not corrected for quantum effects. - - - - - - - - The product of the natural abundances of the nuclides for each candidate. - - - - - - - - For each candidate the half life of that nuclide which has the shortest half - life. - - - - - - diff --git a/base_classes/NXapm_hit_finding.nxdl.xml b/base_classes/NXapm_hit_finding.nxdl.xml deleted file mode 100644 index 534e3c7b00..0000000000 --- a/base_classes/NXapm_hit_finding.nxdl.xml +++ /dev/null @@ -1,147 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of delay-line wires of the detector. - - - - - Number of hit qualities (hit types) distinguished. - - - - - Number of pulses collected in between start_time and end_time - resolved by an instance of :ref:`NXevent_data_apm`. If this is not defined, - p is the number of ions included in the reconstructed volume if an application - definition is used to store results of already reconstructed datasets. - - - - - Base class for the configuration and results from a hit finding algorithm. - - - - - - - The number of wires in the detector. - - - - - - - - - - Alias tuple (begin, end) of each DLD wire of the detector. - Order follows arrival_time_pairs. - - - - - - - - - Raw readings from the analog-to-digital-converter - timing circuits of the detector wires. - - - - - - - - - - - Evaluated ion impact coordinates on the detector. - Use the depends_on field to spec - - - - - - - - Defines in which reference frame the positions are defined. - - - - - - Name of the hit_qualities distinguished. - AMETEK/Cameca uses e.g. golden, multiple, partial, - irrecoverable, and multi-first and multi-late. - - - - - - - - Identifier used for each hit_quality type. - Following the order of hit_quality_types. - - - - - Hit quality identifier for each pulse. - Identifier have to be within hit_quality_identifier. - - - - - - - - This processing yields for each ion with how many others it evaporated - if these were collected on the same pulse. Extraction of multiple ions - on one pulse on different or even the same pixel of the detector are possible. - - Multiplicity must not be confused with how many atoms of the same element - a molecular ion contains (which is instead encoded with the - isotope_vector field of each :ref:`NXion` instance). - - - - - - - diff --git a/base_classes/NXapm_msr.nxdl.xml b/base_classes/NXapm_msr.nxdl.xml deleted file mode 100644 index fd1a520394..0000000000 --- a/base_classes/NXapm_msr.nxdl.xml +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of pulses collected in between start_time and end_time - resolved by an instance of :ref:`NXevent_data_apm`. - - - - - Base class for collecting a session with a real atom probe or field-ion microscope. - - Ideally, we would like to describe the workflow of experiments and simulations of atom probe and - field-evaporation simulation research in more detail and contextualize better descriptions of - experiments and computer simulations for atom probe research. - - The main motivation for this is the ongoing development and tighter becoming connection between atom probe - and other material characterization techniques foremost electron microscopy (see `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_, `C. Fleischmann et al. <https://doi.org/10.1016/j.ultramic.2018.08.010>`_, and `W. Windl et al. <https://doi.org/10.1093/micmic/ozad067.294>`_ or `C. Freysoldt et al. <https://doi.org/10.1103/PhysRevLett.124.176801>`_ to mention but a few). - To arrive at a design of base classes and an application definition which can be used for both real and simulated atom probe experiments, it is worthwhile to recall concepts that are related to events and (molecular) ions: - - * Pulsing events which are used to trigger ion extraction events. - * Physical events and corresponding signal triggered by an ion hitting the detector. - Some of these events are not necessarily caused by or directly correlated with an identifiable pulsing event. - * Processed ion hits which are the result of an algorithm that took the physical and pulsing events as input - and qualified some of these events as to be of sufficiently high quality to call them (molecular) ions that are - wortwhile to be considered further and eventually included in the reconstructed volume. - * Calibration and signal filtering steps applied to these processed ion hits as input which results in actually - selected (molecular) ions based on which an instance of a reconstruction is created. - * Correlation of these ions with a statistics and theoretical model of mass-to-charge-state ratio values - and charge states of the (molecular) ions to substantiate that some of these ions are can be considered - as rangable ions and hence an iontype can be associated by running peak finding algorithms and labeling - i.e. algorithms for defining ranging definitions. - - Not only in AMETEK/Cameca's IVAS/APSuite software, which the majority of atom probers use, these concepts - are well distinguished. However, the algorithms used to transform correlations between pulses and physical events - into actual events (detector hits) ions is a proprietary one. Due to this practical inaccessibility of details, - virtually all atom probe studies currently use a reporting scheme where the course of the specimen evaporation - is documented such that quantities are a function of evaporation identifier i.e. actual event/ion, i.e. after having - the hits finding algorithm and correlations applied. That is evaporation_identifier values take the role of an implicit - time and course of the experiment given that ion extraction is a sequential physical process. - - There is a number of research groups who build own instruments and share different aspects of their technical - specifications and approaches how they apply data processing (e.g. `M. Monajem et al. <https://doi.org/10.1017/S1431927622003397>`_, `P. Stender et al. <https://doi.org/10.1017/S1431927621013982>`_ , or `I. Dimkou et al. <https://doi.org/10.1093/micmic/ozac051>`_ to name but a few). - Despite some of these activities embrace practices of open-source development, they use essentially the same - workflow that has been proposed by AMETEK/Cameca and its forerunner company Imago: A graphical user interface - software is used to explore and thus analyze reconstructed atom probe datasets. - - Specifically, software is used to correlate and interpret pulsing and physical events into processed ion hits. - Some of these ion hits are reported as (molecular) ions with ranged iontypes to yield a dataset based on which - scientific conclusions about the characterized material volume are made. - - By contrast, simulations of field-evaporation have the luxury to document the flight path and allow following the - whereabouts of each ion evaporated if needed. This level of detail is currently not characterizable in experiment. - Thus, there is a divide between schemas describing simulations of atom probe vs measurements of atom probe. - We argue that this divide can be bridged with realizing the above-mentioned context and the realization that - similar concepts are used in both research realms with many concepts not only being similar but exactly the same. - - A further argument to support this view is that computer simulations of atom probe usually are compared to reconstructed - datasets, either to the input configuration that served as the virtual specimen or to a real world atom probe experiment - and its reconstructions. In both cases, the recorded simulated physical events of simulated ions hitting a simulated detector - is not the end of the research workflow but typically the input to apply addition algorithms such as (spatial) filtering - and reconstruction algorithms. Only the practical need for making ranging definitions is (at least as of now) not as much needed - in field-evaporation simulations than it is in real world measurements because each ion has a prescribed iontype in the simulation. - Be it a specifically charged nuclid or a molecular ion whose flight path the simulation resolves. - Although, in principle simpler though, we have to consider that this is caused by many assumptions made in the simulations. - Indeed, the multi-scale (time and space) aspects of the challenge that is the simulating of field-evaporation are simplified - because of otherwise too high computing resource demands and knowledge gaps in how to deal with some complexities. - Molecular ion dissociation upon flight is one such complexity. Also the complexity of simulation setups is simpler e.g. the assumption of a straight flight path - instrument is used or details are ignored such as local electrodes or physical obstacles and electric fields (controlled or stray fields). - - To conclude, we thus propose two base classes :ref:`NXapm_msr` and :ref:`NXapm_sim` where the second one may become - obsolete in the future as people realize that a simulated atom probe is maybe equivalent in design and function to a - real atom probe if considering that the simulation is just stripped of many components. - - - - Metadata of the atom probe or field-ion microscope instrument, henceforth called - microscope or instrument, and the lab in which it stands. - - - - - Given name of the microscope as defined by the hosting lab. This is an alias. - Examples could be LEAP6000, Raptor, Oxcart, one atom at a time, etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - A counter electrode of the LEAP 6000 series atom probes. - - - - - - A local electrode guiding the ion flight path. - Also called counter or extraction electrode. - - - - - - Detector for taking raw time-of-flight and ion/hit impact positions data. - - - - - - - - - - - - - - - A statement whether the measurement was successful or failed prematurely. - - - - - - - - - - diff --git a/base_classes/NXapm_ranging.nxdl.xml b/base_classes/NXapm_ranging.nxdl.xml deleted file mode 100644 index ab3a8afafe..0000000000 --- a/base_classes/NXapm_ranging.nxdl.xml +++ /dev/null @@ -1,111 +0,0 @@ - - - - - - Base class for the configuration and results of ranging definitions. - - Ranging is a data post-processing step used in the research field of - atom probe during which elemental, isotopic, and/or molecular identities - are assigned to mass-to-charge-state-ratios within a certain interval. - The documentation of these steps is based on ideas that - have been described in the literature: - - * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ - * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - How many ion types are distinguished. If no ranging was performed, each - ion is of the special unknown type. The iontype ID of this unknown type - is 0 representing a reserve value. Consequently, - iontypes start counting from 1. - - - - - Assumed maximum value that suffices to store all relevant - molecular ions, even the most complicated ones. - Currently, a value of 32 is used (see M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_). - - - - - Specifies the mass-to-charge-state-ratio histogram. - - - - - Smallest, increment, and largest mass-to-charge-state ratio value. - - - - - - - - A default histogram aka mass spectrum of - the mass-to-charge-state ratio values. - - - - - - Details of the background model that was used to - correct the total counts per bin into counts. - - - - - To begin with we use a free-text field to learn how - atom probers define a background model. Future versions - of NXapm_ranging can then use this information to parameterize - these models. - - - - - - - How where peaks in the background-corrected in the histogram - of mass-to-charge-state ratio values identified? - - - - - - - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - - - - - diff --git a/base_classes/NXapm_reconstruction.nxdl.xml b/base_classes/NXapm_reconstruction.nxdl.xml deleted file mode 100644 index 03f5ff7091..0000000000 --- a/base_classes/NXapm_reconstruction.nxdl.xml +++ /dev/null @@ -1,123 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of ions spatially filtered from results of the hit_finding algorithm - :ref:`NXapm_hit_finding` from which an instance of a reconstructed volume - has been generated. These ions get new identifier assigned in the process - - the so-called evaporation_identifier, which must not be confused with - the pulse_identifier! - - - - - Base class for the configuration and results of a (static) reconstruction algorithm. - - Generating a tomographic reconstruction of the specimen uses selected and - calibrated ion hit positions, the evaporation sequence, and voltage curve data. - Very often scientists use own software scripts according to published procedures, - so-called reconstruction protocols. - - - - - - - - Different reconstruction protocols exist. Although these approaches - are qualitatively similar, each protocol uses different parameters - (and interprets these differently). The source code to IVAS/APSuite - is not open. For now users should store reconstruction parameter - in this free-text field to guide how to parameterize this better in the - future. For LEAP systems and reconstructions performed with IVAS/APSuite - see `T. Blum et al. <https://doi.org/10.1002/9781119227250.ch18>`_ (page 371). - - - - - Qualitative statement about which reconstruction protocol was used. - - - - - - - - - - - - Different strategies for crystallographic calibration of the - reconstruction are possible. Therefore, we collect first such - feedback before parameterizing this further. - - If no crystallographic calibration was performed, the field - should be filled with the n/a, meaning not applied. - - - - - - - The nominal diameter of the specimen ROI which is measured in the - experiment. The physical specimen cannot be measured completely - because ions may launch but hit in locations other than the detector. - - - - - Three-dimensional reconstructed positions of the ions. - - - - - - - - The instance of :ref:`NXcoordinate_system` - in which the positions are defined. - - - - - - - - - To get a first visual overview of the reconstructed dataset, - here a 3d histogram of the ion is stored. Ion counts are characterized - using one nanometer cubic bins without applying position smoothening - algorithms during the histogram computation. - - - - diff --git a/base_classes/NXapm_volt_and_bowl.nxdl.xml b/base_classes/NXapm_volt_and_bowl.nxdl.xml deleted file mode 100644 index 30bdbb0fde..0000000000 --- a/base_classes/NXapm_volt_and_bowl.nxdl.xml +++ /dev/null @@ -1,69 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of ions spatially filtered from results of the hit_finding algorithm - :ref:`NXapm_hit_finding` from which an instance of a reconstructed volume - has been generated. These ions get new identifier assigned in the process - - the so-called evaporation_identifier, which must not be confused with - the pulse_identifier! - - - - - Base class for the configuration and results from a voltage-and-bowl ToF correction algorithm. - - The voltage-and-bowl correction is a ata post-processing step to correct for ion impact position - flight path differences, detector biases, and nonlinearities. - - - - - - - Raw time-of-flight data without corrections. - - - - - - - - Calibrated time-of-flight. - - - - - - diff --git a/base_classes/NXbeam.nxdl.xml b/base_classes/NXbeam.nxdl.xml index d1dea2e477..68fd0b4147 100644 --- a/base_classes/NXbeam.nxdl.xml +++ b/base_classes/NXbeam.nxdl.xml @@ -61,45 +61,11 @@ Distance from sample. Note, it is recommended to use NXtransformations instead. - - Energy carried by each particle of the beam on entering the beamline component. - - In the case of a monochromatic beam this is the scalar energy. - Several other use cases are permitted, depending on the - presence of other incident_energy_X fields. - - * In the case of a polychromatic beam this is an array of length m of energies, with the relative weights in incident_energy_weights. - * In the case of a monochromatic beam that varies shot-to-shot, this is an array of energies, one for each recorded shot. - Here, incident_energy_weights and incident_energy_spread are not set. - * In the case of a polychromatic beam that varies shot-to-shot, - this is an array of length m with the relative weights in incident_energy_weights as a 2D array. - * In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, - this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_energy_weights as a 2D array. - - Note, variants are a good way to represent several of these use cases in a single dataset, - e.g. if a calibrated, single-value energy value is available along with the original spectrum from which it was calibrated. - + Energy carried by each particle of the beam on entering the beamline component - - - The energy spread FWHM for the corresponding energy(ies) in incident_energy. In the case of shot-to-shot variation in - the energy spread, this is a 2D array of dimension nP by m - (slow to fast) of the spreads of the corresponding - wavelength in incident_wavelength. - - - - - In the case of a polychromatic beam this is an array of length m of the relative - weights of the corresponding energies in incident_energy. In the case of a - polychromatic beam that varies shot-to-shot, this is a 2D array of dimensions np - by m (slow to fast) of the relative weights of the corresponding energies in - incident_energy. - - Energy carried by each particle of the beam on leaving the beamline component @@ -194,9 +160,7 @@ Size of the beam entering this component. Note this represents - a rectangular beam aperture, and values represent FWHM. - If applicable, the first dimension shall be the horizontal extent - and the second dimension shall be the vertical extent. + a rectangular beam aperture, and values represent FWHM @@ -215,24 +179,6 @@ - - - The units for this observable are not included in the NIAC list. - Responsibility on correct formatting and parsing is handed to the user - by using `NX_ANY`. Correct parsing can still be implemented by using - this attribute. - - | Fill with: - - * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). - * The unit unidata name if the unit has a name (Example: farad for capacitance). - * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and - does not have a name. - - Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). - Here: SI units are V2/m2. - - Polarization vector on leaving beamline component @@ -240,24 +186,6 @@ - - - The units for this observable are not included in the NIAC list. - Responsibility on correct formatting and parsing is handed to the user - by using `NX_ANY`. Correct parsing can still be implemented by using - this attribute. - - | Fill with: - - * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). - * The unit unidata name if the unit has a name (Example: farad for capacitance). - * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and - does not have a name. - - Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). - Here: SI units are V2/m2. - - @@ -317,87 +245,6 @@ - - - Energy of a single pulse at the diagnostic point - - - - - Average power at the diagnostic point - - - - - Incident fluence at the diagnostic point - - - - Here: SI units are 'J/m2', customary 'mJ/cm2'. - - - - - - FWHM duration of the pulses at the diagnostic point - - - - - Delay time between two pulses of a pulsed beam. - - - - A reference to the beam in relation to which the delay is. - - - - - - FROG trace of the pulse. - - - - - - - - - Horizontal axis of a FROG trace, i.e. delay. - - - - - - - - Vertical axis of a FROG trace, i.e. frequency. - - - - - - - - The type of chirp implemented - - - - - Group delay dispersion of the pulse for linear chirp - - - - - Indicates the beam device from which this beam originates. - This defines, whether the beam in an "input" or "output" beam. - - - - - Gives the beam device which this beam will interact with next. - - Distribution of beam with respect to relevant variable e.g. wavelength. This is mainly diff --git a/base_classes/NXbeam_device.nxdl.xml b/base_classes/NXbeam_device.nxdl.xml deleted file mode 100644 index ee798485f9..0000000000 --- a/base_classes/NXbeam_device.nxdl.xml +++ /dev/null @@ -1,67 +0,0 @@ - - - - - - Properties of generic beam device in an experimental setup. - - Any beam related devices like source, detector, filter, mirror, - beamsplitter, ... which may modifies a beam in an experimental setup - can be described here with its experimental position and relationship - to the other beam devices in the setup. - - - - Single device or list of devices pointing to the devices from which an - beam originated to reach this device. - This is used to describe a logical order of devices and for the whole setup. - In this way, a "beam path" can be described (i.e., with starting point (light source) - and end point (photo detector)). - - Example: /entry/instrument/detector. - - - - - Description of the intended purpose of this device for - the experimental setup. - - - - - Name of the group with which this device can be associated. - For example, if a group of devices is used for second harmonic generation, - all these devices have the group name "second harmonic generation". - Is used for simplified setup vizualization (or description?). - - - - - Location and orientation of the device. Note that even a - simple distance can be given as a translation. - - You can use the @depends_on to describe from which device - the transformation needs to be applied. - - - diff --git a/base_classes/NXbeam_transfer_matrix_table.nxdl.xml b/base_classes/NXbeam_transfer_matrix_table.nxdl.xml deleted file mode 100644 index d61f275566..0000000000 --- a/base_classes/NXbeam_transfer_matrix_table.nxdl.xml +++ /dev/null @@ -1,120 +0,0 @@ - - - - - - - Variables used throughout the document, e.g. dimensions or parameters. - - - - Length of the array associated to the data type. - - - - - Contains datastructures of an experimental optical setup (i.e., multiple - transfermatrix tables). These datastructures are used to relate physical - properties of two beams (NXbeam) which have one common optical element - (NXopt_element) (one specific transfermatrix). - One of these beams in an input beam and the other one is an output beam. - - The data describes the change of beam properties, e.g. the intensity of a - beam is reduced because the transmission coefficient of the beam device is - lower than 1. - - - - Select which type of data was recorded, for example aperture and - focal length. - It is possible to have multiple selections. This selection defines - how many columns (N_variables) are stored in the data array. - N in the name, is the index number in which order the given - property is listed. - - - - - - - - - - - Please list in this array the column and row names used in your actual data. - That is in the case of aperture ['diameter'] or focal length ['focal_length_value'] - and for orientation matrix ['OM1', 'OM2', 'OM3'] or for jones matrix - ['JM1','JM2'] - - - - - - - - Contains the datastructure which relates beam properties of an - input and output beam as result of the input beam interaction - with the beam device. - - Transfermatrix relationship between N input beams and M output beams. - It contains a table with the relevant matricis to be used for different - transmissitted properties (such as polarization, intensity, phase). - - Data structure for all transfermatrices of an beam device in a setup. - For each combination of N input and M output beams and for L physical - concept (i.e. beam intensity), one matrix can be defined. - - In this way, the transfermatrix table has the dimension NxM. - - For each entry, in this transfermatrix, there are L formalisms. - Each formalism has the dimension math:`dim(L_i)xdim(L_i)`, - whereby math:`L_i` is the specific physical concept (Intensity, polarization, direction). - - A beamsplitter with two input laser beams can have a total of - four transfermatrices (2 Input x 2 Output). - - The dimension of the transfermatrix depends on the parameters. - Examples are: - 1x1 for intensity/power - 2x2 for jones formalism - 3x3 for direction - - - - Square matrix with dimension N_variables x N_variables - - - - - - - Specific name of input beam which the transfermatrix table is related to. - - - - - Specific name of output beam which the transfermatrix table is related to. - - - - diff --git a/base_classes/NXcalibration.nxdl.xml b/base_classes/NXcalibration.nxdl.xml deleted file mode 100644 index 702688fc2c..0000000000 --- a/base_classes/NXcalibration.nxdl.xml +++ /dev/null @@ -1,220 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of coefficients of the calibration function - - - - - Number of points of the calibrated and uncalibrated axes - - - - - Subclass of NXprocess to describe post-processing calibrations. - - - - A description of the procedures employed. - - - - - The physical quantity of the calibration, e.g., - energy, momentum, time, etc. - - - - - A digital persistent identifier (e.g., DOI, ISO standard) referring to a detailed description of a - calibration method but no actual calibration data. - - - - - A digital persistent identifier (e.g., a DOI) referring to a publicly available calibration measurement - used for this instrument, e.g., a measurement of a known standard containing calibration information. - The axis values may be copied or linked in the appropriate NXcalibration fields for reference. - - - - - A file serialisation of a calibration which may not be publicly available (externally from the nexus file). - - This metadata can be a documentation of the source (file) or database (entry) from which pieces - of information have been extracted for consumption (e.g. in a research data management system (RDMS)). - It is also possible to include the actual file by using the `file` field. - - The axis values may be copied or linked in the appropriate NXcalibration fields for reference. - - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the calibration been applied? - - - - - Name of the software used for this calibration. - - - - Software version. - - - - - - Vector containing the data coordinates in the original uncalibrated axis - - - - - - - The symbol of the axis to be used in the fit_function, e.g., `energy`, `E`. - This should comply to the following naming rules (similar to python's naming rules): - - * A variable name must start with a letter or the underscore character - * A variable name cannot start with a number - * A variable name can only contain alpha-numeric characters and underscores (A-z, 0-9, and _ ) - * Variable names are case-sensitive (age, Age and AGE are three different variables) - - - - - The path from which this data is derived, e.g., raw detector axis. - Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. - - - - - - Additional input axis to be used in the formula. - The part after `input_` is used as the symbol to be used in the `fit_function`, i.e., - if the field name is `input_my_field` you should refer to this axis by `my_field` in the `fit_function`. - - - - - - - The path from which this data is derived, e.g., raw detector axis. - Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. - - - - - - For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit - to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the array of fit coefficients. - - - - - - - - For non-linear energy calibrations. Here we can store the formula of the - fit function. - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - - Use x0, x1, ..., xn for the nth position in the `original_axis` field. - If there is the symbol attribute specified for the `original_axis` this may be used instead of x. - If you want to use the whole axis use `x`. - Alternate axis can also be available as specified by the `input_SYMBOL` field. - The data should then be referred here by the `SYMBOL` name, e.g., for a field - name `input_my_field` it should be referred here by `my_field` or `my_field0` if - you want to read the zeroth element of the array. - - The formula should be numpy compliant. - - - - - For linear calibration. Scaling parameter. - This should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. - - - - - For linear calibration. Offset parameter. - This should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. - - - - - Mapping data for calibration. - - This can be used to map data points from uncalibrated to calibrated values, - i.e., by multiplying each point in the input axis by the corresponding point in the mapping data. - - - - - A vector representing the axis after calibration, matching the data length - - - - - - - The path to which this data is written, e.g., the calibrated energy. - Should be a valid NeXus path name, e.g., /entry/data/energy. - - - - - - Any data acquired/used during the calibration that does not fit the `NX_FLOAT` fields above. - NXdata groups can be used for multidimensional data which are relevant to the calibration - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - diff --git a/base_classes/NXcg_face_list_data_structure.nxdl.xml b/base_classes/NXcg_face_list_data_structure.nxdl.xml deleted file mode 100644 index 081b928d5d..0000000000 --- a/base_classes/NXcg_face_list_data_structure.nxdl.xml +++ /dev/null @@ -1,230 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The number of vertices. - - - - - The number of edges. - - - - - The number of faces. - - - - - The total number of vertices of all faces. Faces are polygons. - - - - - The total number of Weinberg vector values of all faces. - - - - - Computational geometry of primitives via a face-and-edge-list data structure. - - Primitives must neither be degenerated nor self-intersect but can differ in - their properties. A face-and-edge-list-based description of primitives is - frequently used for triangles and polyhedra to store them on disk for - visualization purposes (see OFF, PLY, VTK, or STL file formats). - - Although this description is storage efficient it is not well suited for - topological analyses though. In this case, scientists may need a different - view on the primitives which is better represented with e.g. a - half_edge_data_structure. - - Having an own base class for the data structure how primitives are stored is - useful to embrace both users with small or very detailed specification demands. - - - - - Number of vertices for each face. - - Each entry represents the total number of vertices for that face, - irrespectively whether vertices are shared among faces or not. - - - - - - - - Number of edges for each face. - - Each entry represents the total number of edges for that face, - irrespectively whether edges are shared across faces or not. - - - - - - - - Number of faces of the primitives. - - - - - Integer offset whereby the identifier of the first member - of the vertices differs from zero. - - Identifier can be defined explicitly or implicitly. - Inspect the definition of NXcg_primitive_set for further details. - - - - - Integer offset whereby the identifier of the first member - of the edges differs from zero. - - Identifier can be defined explicitly or implicitly. - Inspect the definition of NXcg_primitive_set for further details. - - - - - Integer offset whereby the identifier of the first member - of the faces differs from zero. - - Identifier can be defined explicitly or implicitly. - Inspect the definition of NXcg_primitive_set for further details. - - - - - Integer identifier to distinguish all vertices explicitly. - - - - - - - - Integer used to distinguish all edges explicitly. - - - - - - - - Integer used to distinguish all faces explicitly. - - - - - - - - Positions of the vertices. - - Users are encouraged to reduce the vertices to a unique set as this may - result in a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. Naively here means that each - vertex is stored even though many share the same positions. - - - - - - - - - The edges are stored as pairs of vertex identifier. - - - - - - - - - The faces are stored as a concatenated array of vertex identifier tuples. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. - - - - - - - - - If true, indicates that the vertices are all placed at different positions - and have different identifiers, i.e. no points overlap or are counted more - than once. - - - - - If true, indicates that no edge is stored more than once. - - Users are encouraged to consider using a half_edge_data_structure instead. - - - - - If true, indicates that no face is stored more than once. - - - - - Specifies for each face which winding order was used if any: - - * 0 - undefined - * 1 - counter-clockwise (CCW) - * 2 - clock-wise (CW) - - - - - - diff --git a/base_classes/NXcg_hexahedron_set.nxdl.xml b/base_classes/NXcg_hexahedron_set.nxdl.xml deleted file mode 100644 index 8ea85fb981..0000000000 --- a/base_classes/NXcg_hexahedron_set.nxdl.xml +++ /dev/null @@ -1,193 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of hexahedra. - - - - - Computational geometry description of a set of hexahedra in Euclidean space. - - This class can also be used to describe cuboids or cubes, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts an approach whereby - different specific views can be implemented using the same base class: - - * In the simplest case experimentalists may use this base class to describe - the dimensions or size of a specimen. In this case the alignment with axes - is not relevant as eventually only the volume of the specimen is of interest. - * In many cases, take for example an experiment where a specimen was cut out - from a specifically deformed piece of material, the orientation of the - specimen's edges with the experiment coordinate system is of high relevance. - Examples include knowledge about the specimen edge, whether it is - parallel to the rolling, the transverse, or the normal direction. - * While the above-mentioned use cases are sufficient to pinpoint the sample - within a known laboratory/experiment coordinate system, these descriptions - are not detailed enough to specify e.g. a CAD model of the specimen. - * Therefore, groups and fields for an additional, computational-geometry- - based view of hexahedra is offered to serve additional computational - tasks: storage-oriented simple views or detailed topological/graph-based - descriptions. - - Hexahedra are important geometrical primitives, which are among the most - frequently used elements in finite element meshing/modeling. - - As a specialization of the :ref:`NXcg_primitive_set` base class hexahedra - are assumed non-degenerated, closed, and built of polygons that are - not self-intersecting. - - The term hexahedra will be used throughout this base class but includes - the special cases cuboid, cube, box, axis-aligned bounding box (AABB), - and optimal bounding box (OBB). - - An axis-aligned bounding box is a common data object in computational science - and simulation codes to represent a cuboid whose edges are aligned with the - base vectors of a coordinate system. As a part of binary trees, these data - objects are important for making time- as well as space-efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tightly fitting box about an arbitrary object. In general, such boxes are - rotated. Exact and substantially faster in practice approximate algorithms - exist to compute optimal or near optimal bounding boxes for sets of points. - - - - - Qualifier for the shape of each hexahedron. - - - - - - - - - Qualifier that is useful in cases when one edge is longer than all other - edges of the hexahedra. Often the term length is associated with the - assumption that one edge is parallel to an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the extent of an object in the horizontal - direction assuming a specific coordinate system. - - For the sake of explicitness quantities like length, width, and height - should not be reported without specifying also the assumed reference frame. - - - - - - - - Qualifier often used to describe the extent of an object in the vertical - direction assuming a specific coordinate system. - - - - - - - - Volume of each hexahedron. - - - - - - - - Total (surface) area (of all six faces) of each hexahedron. - - - - - - - - Area of each of the six faces of each hexahedron. - - - - - - - - - Specifies if the hexahedra represent cuboids or cubes eventually rotated - ones but at least not too exotic six-faced polyhedra. - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether hexahedra are boxes whose primary edges are parallel to the - axes of the coordinate system. - - - - - - - - - - - - - Combined storage of all primitives of all hexahedra. - - - - - Individual storage of each hexahedron. - - - - - Individual storage of each hexahedron as a graph. - - - diff --git a/base_classes/NXcg_parallelogram_set.nxdl.xml b/base_classes/NXcg_parallelogram_set.nxdl.xml deleted file mode 100644 index bfb868c47d..0000000000 --- a/base_classes/NXcg_parallelogram_set.nxdl.xml +++ /dev/null @@ -1,106 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of parallelograms. - - - - - Computational geometry description of a set of parallelograms. - - This class can also be used to describe rectangles or squares, irrespective - whether these are axis-aligned or not. The class represents different - access and description levels to embrace applied scientists and computational - geometry experts with their different views: - - * The simplest case is the communication of dimensions aka the size of a - region of interest in the 2D plane. In this case, communicating the - alignment with axes is maybe not as relevant as it is to report the area - of the ROI. - * In other cases the extent of the parallelogram is relevant though. - * Finally, in CAD models it should be possible to specify the polygons - which the parallelograms represent with exact numerical details. - - Parallelograms are important geometrical primitives as their usage for - describing many scanning experiments shows where typically parallelogram-shaped - ROIs are scanned across the surface of a sample. - - The term parallelogram will be used throughout this base class thus including - the important special cases rectangle, square, 2D box, axis-aligned bounding box - (AABB), or optimal bounding box (OBB) as analogous 2D variants to their 3D - counterparts. See :ref:`NXcg_hexahedron_set` for the generalization in 3D. - - An axis-aligned bounding box is a common data object in computational science - and simulation codes to represent a rectangle whose edges are aligned with the - axes of a coordinate system. As a part of binary trees AABBs are important data - objects for executing time- as well as space-efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best, i.e. - most tightly fitting box about an arbitrary object. In general such boxes are - rotated. Other than in 3D dimensions, the rotation calipher method offers - a rigorous approach to compute an optimal bounding box to a point set in 2D. - - - - - To specify which parallelogram is a rectangle. - - - - - - - - Only to be used if is_rectangle is present. In this case, this field - describes whether parallelograms are rectangles whose primary edges - are parallel to the axes of the coordinate system. - - - - - - - - - - Combined storage of all primitives of all parallelograms. - - - - - Individual storage of each parallelogram. - - - - diff --git a/base_classes/NXcg_point_set.nxdl.xml b/base_classes/NXcg_point_set.nxdl.xml deleted file mode 100644 index c2190590d0..0000000000 --- a/base_classes/NXcg_point_set.nxdl.xml +++ /dev/null @@ -1,87 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality. - - - - - The cardinality of the set, i.e. the number of points. - - - - - Computational geometry description of a set of points. - - Points may have an associated time value. Users are advised though to store - time data of point sets rather as instances of time events, where for each - point in time there is an :ref:`NXcg_point_set` instance which specifies the - points' locations. - - This is a frequent situation in experiments and computer simulations, where - positions of points are taken at the same point in time (real time or - simulated physical time). Thereby, the storage of redundant time stamp - information per point is considered as obsolete. - - - - Coordinates of the points. - - - - - - - - - (Elapsed) time for each point. - - If the field time is needed contextualize the time_offset relative to which - time values are defined. Alternative store timestamp. - - - - - - - - ISO8601 with local time zone offset for each point. - - - - - - - - ISO8601 with local time zone offset that serves as the reference - for values in the field time. - - - diff --git a/base_classes/NXcg_polygon_set.nxdl.xml b/base_classes/NXcg_polygon_set.nxdl.xml deleted file mode 100644 index 95c157ce1e..0000000000 --- a/base_classes/NXcg_polygon_set.nxdl.xml +++ /dev/null @@ -1,131 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be either 2 or 3. - - - - - The cardinality of the set, i.e. the number of polygons. - - - - - - The total number of vertices when visiting every polygon. - - - - - - Computational geometry description of a set of polygons in Euclidean space. - - Polygons are specialized polylines: - - * A polygon is a geometric primitive that is bounded by a closed polyline - * All vertices of this polyline lay in the d-1 dimensional plane. - whereas vertices of a polyline do not necessarily lay on a plane. - * A polygon has at least three vertices. - - Each polygon is built from a sequence of vertices (points with identifiers). - The members of a set of polygons may have a different number of vertices. - Sometimes a collection/set of polygons is referred to as a soup of polygons. - - As three-dimensional objects, a set of polygons can be used to define the - hull of what is effectively a polyhedron; however users are advised to use - the specific :ref:`NXcg_polyhedron_set` base class if they wish to describe closed - polyhedra. Even more general complexes can be thought of. An example are the - so-called piecewise-linear complexes used in the TetGen library. - - As these complexes can have holes though, polyhedra without holes are one - subclass of such complexes, users should rather design an own - base class e.g. NXcg_polytope_set to describe such even more - complex primitives instead of abusing this base class for such purposes. - - - - The total number of vertices in the set. - - - - - - Combined storage of all primitives of all polygons. - - - - - Individual storage of the mesh of each polygon. - - - - - Individual storage of each polygon as a graph. - - - - - - For each polygon its accumulated length along its edges. - - - - - - - - Interior angles for each polygon. There are as many values per polygon - as the are number_of_vertices. - The angle is the angle at the specific vertex, i.e. between the adjoining - edges of the vertex according to the sequence in the polygons array. - Usually, the winding_order field is required to interpret the value. - - - - - - - - Curvature type: - - * 0 - unspecified, - * 1 - convex, - * 2 - concave - - - - - - diff --git a/base_classes/NXcg_polyhedron_set.nxdl.xml b/base_classes/NXcg_polyhedron_set.nxdl.xml deleted file mode 100644 index b087b0c790..0000000000 --- a/base_classes/NXcg_polyhedron_set.nxdl.xml +++ /dev/null @@ -1,114 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of polyhedra. - - - - - The total number of edges for all polyhedra. - - - - - The total number of faces for all polyhedra. - - - - - Computational geometry description of a set of polyhedra in Euclidean space. - - Polyhedra or so-called cells (especially in the convex of tessellations) are - constructed from polygon meshes. Polyhedra may make contact to allow a usage - of this base class for a description of tessellations. - - For the description of more complicated manifolds and especially for polyhedra - with holes, users are advised to check if their particular needs are described - by creating customized instances of an :ref:`NXcg_polygon_set`. - - - - - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. - - - - - - - - Area of each of faces. - - - - - - - - The number of edges for each polyhedron. Edges of adjoining polyhedra - are counterd for each polyhedron. - - - - - Length of each edge. - - - - - - - - - Combined storage of all primitives of all polyhedra. - - - - - Individual storage of each polyhedron. - - - - - Individual storage of each polygon as a graph. - - - diff --git a/base_classes/NXcg_primitive_set.nxdl.xml b/base_classes/NXcg_primitive_set.nxdl.xml deleted file mode 100644 index 034216a3e0..0000000000 --- a/base_classes/NXcg_primitive_set.nxdl.xml +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the space. - - - - - The cardinality of the set, i.e. the number of members. - - - - - Computational geometry description of a set of primitives in Euclidean space. - - Primitives must neither be degenerated nor self-intersect. - Individual primitives can differ in their properties (e.g. size, shape, rotation). - - - - - Reference to an instance of :ref:`NXcoordinate_system` in which these primitives - are defined. - - - - - The dimensionality of the primitive set. - - - - - - - - - - The cardinality of the primitive set. - - - - - Integer offset whereby the identifier of the first member - of the set differs from zero. - - Identifiers can be defined either implicitly or explicitly. - For implicit indexing identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. - - Therefore, implicit identifier are completely defined by the value of - identifier_offset and cardinality. For example if identifier run from - -2 to 3 the value for identifier_offset is -2. - - For explicit indexing the field identifier has to be used. - Fortran-/Matlab- and C-/Python-style indexing have specific implicit - identifier conventions where identifier_offset is 1 and 0 respectively. - - - - - Identifier of each member for explicit indexing. - - - - - - - - The center of mass position of each primitive. - - - - - - - - - - True if the center is a center of mass. - - - - - - - - A qualitative description of the shape of each primitive. - - - - - - - - - Qualifier for the length of characteristic features of the primitive. - - Often the term length is associated with the assumption that one - edge is parallel to an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of one characteristic edge - within the coordinate system. - - - - - - - - True if primitive is closed such that it has properties like area or volume. - - - - - - - - Volume of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - - - - - - - - Alias for surface_area of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - - - - - - - - Direction unit vector which points along the - longest principal axis of each primitive. - - Use the depends_on attribute to specify in which coordinate system - these direction unit vectors are defined. - - - - - - - - - - - diff --git a/base_classes/NXcg_roi_set.nxdl.xml b/base_classes/NXcg_roi_set.nxdl.xml deleted file mode 100644 index 69bc0042e5..0000000000 --- a/base_classes/NXcg_roi_set.nxdl.xml +++ /dev/null @@ -1,57 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - Use the depends_on fields of the respective specialized - :ref:`NXcg_primitive_set` base class surplus - :ref:`NXcoordinate_system_set` with at least one instance of - :ref:`NXcoordinate_system` to define explicitly the reference frame in - which the primitives are defined. Alternatively, although - disencouraged, one may use one :ref:`NXcoordinate_system_set` with - with only one :ref:`NXcoordinate_system` in the application definition - to specify implicitly in which reference frame the primitives are - defined. If none of these two possibilities is used all primitives - are assumed defined in the McStas coordinate system. - - - - Base class for a region-of-interest (ROI) bound by geometric primitives. - - So-called region-of-interest(s) (ROIs) are typically used to describe a - region in space (and time) where an observation is made or for which - a computer simulation is performed with given boundary conditions. - - - - - - - - - diff --git a/base_classes/NXcg_tetrahedron_set.nxdl.xml b/base_classes/NXcg_tetrahedron_set.nxdl.xml deleted file mode 100644 index 509347c515..0000000000 --- a/base_classes/NXcg_tetrahedron_set.nxdl.xml +++ /dev/null @@ -1,86 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of tetrahedra. - - - - - Computational geometry description of a set of tetrahedra. - - Among hexahedral elements, tetrahedral elements are one of the most - frequently used geometric primitive for meshing and describing volumetric - objects in continuum-field simulations. - - - - - Area of each of the four triangular faces of each tetrahedron. - - - - - - - - - Length of each edge of each tetrahedron. - - - - - - - - - - Combined storage of all primitives of all tetrahedra. - - - - - Individual storage of each tetrahedron. - - - - - Individual storage of each tetrahedron as a graph. - - - diff --git a/base_classes/NXcg_triangle_set.nxdl.xml b/base_classes/NXcg_triangle_set.nxdl.xml deleted file mode 100644 index 7d994eb3e9..0000000000 --- a/base_classes/NXcg_triangle_set.nxdl.xml +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of triangles. - - - - - The number of unique vertices supporting the triangles. - - - - - Computational geometry description of a set of triangles. - - - - Number of unique vertices in the triangle set. - - - - - Combined storage of all primitives of all triangles. - - This description resembles the typical representation of primitives - in file formats such as OFF, PLY, VTK, or STL. - - - - - Individual storage of each triangle. - Users are advised that using such individual storage of primitives - may be less storage efficient than creating a combined storage. - - - - - - Length of the edges of each triangle. - - For each triangle values are reported via traversing - the vertices in the sequence as these are defined. - - - - - - - - - Interior angles of each triangle. - - For each triangle values are reported for the angle opposite - to the respective edges in the sequence how vertices are defined. - - - - - - - diff --git a/base_classes/NXchemical_process.nxdl.xml b/base_classes/NXchemical_process.nxdl.xml deleted file mode 100644 index 437fcf0b6a..0000000000 --- a/base_classes/NXchemical_process.nxdl.xml +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - A planned or unplanned process which results in chemical changes (i.e., changes in the chemical bonds) in a specified material. - - Examples include any chemical reactions (addition, subtraction, replacement, ...). - - - - ISO 8601 formatted time code (with local time zone offset to UTC information - included) when this process started. - - - - - ISO 8601 formatted time code (with local time zone offset to UTC information - included) when this process ended. - - - - - Short description of the chemical process. - - - - - Method by which this process was performed. - - - - - This can be any data or other descriptor acquired during the chemical process - (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - - - diff --git a/base_classes/NXcircuit.nxdl.xml b/base_classes/NXcircuit.nxdl.xml deleted file mode 100644 index 9648ae103a..0000000000 --- a/base_classes/NXcircuit.nxdl.xml +++ /dev/null @@ -1,136 +0,0 @@ - - - - - - Base class for circuit devices. - - - - Hardware type used in circuit, includes hardware manufacturers and type - - - - - The tunneling current between tip and sample after application of bias voltage. - - - - - Calibration of the current measurement (A/V). - - - - - Offset of the current measurement. - - - - - Proportional relationship between the probe output voltage and the actual - tunneling current when measuring the tunneling current. - - - - - The scan channels are selected by users (in scan contronaller). - - - - - The bandwitdh of the Hardware and/or Software - - - - - (Signals Periods) The Signals Period is the rate at which the signals are - transferred to the host computer running the control software. This is usually - lower by a factor of 10 than the sampling rate, because an internal oversampling - of the signal is done on the real time engine. You can reduce the oversampling - down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. - - - - - Update rate for several processes like History Graph, Auto-Approach, and for - many Programming Interface functions. This is usually set to 20 ms. All - additional timings (7-9) can only be integer multiples of this value. They can - be set to different values, but the actual timing value will be coerced to a - multiple of the Acquisition Period. - - - - - Update rate of animated graphical indicators. These are e.g. some graphs & - sliders. A reasonable value is 40 ms (25 updates per second). Increase this - period to reduce the processor load for the graphical user interface, especially - on slow computers. This value is purely a user interface update rate and does - not affect measurements in any way. - - - - - Update rate of digital indicators, e.g. the numbers displayed besides each - slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a - user interface update rate and does not affect measurements in any way. - - - - - The Measurements period is the integration time for precise measurements - (averaging over specified period), mostly used in sweep modules. Examples are - recording of a force-distance curve or a resonance of a cantilever. For fast - measurements with small steps, a value of 40 ms may be reasonable. For normal - use, 300-500 ms is a good value, but for recording a resonance of a high-Q - cantilever, values of several seconds might be necessary. Usually this parameter - doesn’t need to be set from this module; the sweep modules will set this value - according to the sweep timings. - - - - - Number of output channels - - - - - The user output in each monitor mode. - - - - - The values for each output channel. - - - - - User outputs whose name can be modified in the corresponding module. - - - - - The rate at which the one of the signal changes when ramping to the starting - point. (V/s) - - - diff --git a/base_classes/NXcomponent.nxdl.xml b/base_classes/NXcomponent.nxdl.xml deleted file mode 100644 index d317db6803..0000000000 --- a/base_classes/NXcomponent.nxdl.xml +++ /dev/null @@ -1,64 +0,0 @@ - - - - - - Base class for components of an instrument - real ones or a simulated ones. - - - - Specifies the position of the component by pointing to the last - transformation in the transformation chain that is defined - via the NXtransformations group. - - - - - Was the component used? - - - - - Given name - - - - - Ideally, use instances of :ref:`NXidentifier` to point to a resource - that provides further details. - - If such a resource does not exist or should not be used, use this, though - discouraged, free-text. - - - - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the component in the instrument. - - - - diff --git a/base_classes/NXcoordinate_system.nxdl.xml b/base_classes/NXcoordinate_system.nxdl.xml deleted file mode 100644 index 80de81f407..0000000000 --- a/base_classes/NXcoordinate_system.nxdl.xml +++ /dev/null @@ -1,159 +0,0 @@ - - - - - - Base class to detail a coordinate system (CS). - - Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as - a member in an :ref:`NXcoordinate_system_set` and the name of the instance - should be this alias. This may support a process whereby jargon when talking - about coordinate systems and conventions may become cleaner for users - because it is not evident for people outside a lab that terms like e.g. - tip space or specimen space refer to the same coordinate system. - This is an example of jargon used in e.g. the field of atom - probe tomography. - - - - Human-readable field telling where the origin of this CS is. - Exemplar values could be *left corner of the lab bench*, *door-handle* - *pinhole through which the electron beam exists the pole piece*. - *barycenter of the triangle*, *center of mass of the stone*. - - - - - - An alternative name given to that coordinate system. - - - - - Coordinate system type. - - - - - - - - - Handedness of the coordinate system if it is a Cartesian. - - - - - - - - - - Possibility to define an alias for the name of the x-axis. - - - - - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - - - - - - Base unit vector along the first axis which spans the coordinate system. - This axis is frequently referred to as the x-axis in real space and - the i-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the y-axis. - - - - - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second axis which spans the coordinate system. - This axis is frequently referred to as the y-axis in real space and - the j-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the z-axis. - - - - - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the third axis which spans the coordinate system. - This axis is frequently referred to as the z-axis in real space and - the k-axis in reciprocal space. - - - - - - - - This specificies the relation to another coordinate system by pointing to the last - transformation in the transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe this coordinate system - with respect to another coordinate system. - - - diff --git a/base_classes/NXcoordinate_system_set.nxdl.xml b/base_classes/NXcoordinate_system_set.nxdl.xml deleted file mode 100644 index a842d257d2..0000000000 --- a/base_classes/NXcoordinate_system_set.nxdl.xml +++ /dev/null @@ -1,240 +0,0 @@ - - - - - - - Base class to hold different coordinate systems and representation conversions. - - How many nodes of type :ref:`NXcoordinate_system_set` should be used in an application definition? - - * 0; if there is no instance of :ref:`NXcoordinate_system_set` and therein or elsewhere across - the application definition, an instance of NXcoordinate_system is defined, - the default NeXus `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ - coordinate system is assumed. This makes :ref:`NXcoordinate_system_set` and - NXcoordinate_system base classes backwards compatible to older - NeXus conventions and classes. - * 1; if only one :ref:`NXcoordinate_system_set` is defined, it should be placed - as high up in the node hierarchy (ideally right below an instance of NXentry) - of the application definition tree as possible. - This :ref:`NXcoordinate_system_set` should define at least one NXcoordinate_system - instance. This shall be named such that it is clear how this coordinate system is - typically referred to in a community. For the NeXus `McStas coordinate system, it is - advised to call it mcstas for the sake of improved clarity. - Additional NXcoordinate_system instances should be specified if possible in that same - :ref:`NXcoordinate_system_set` instead of cluttering them across the tree. - - If this is the case, it is assumed that the NXcoordinate_system_members - overwrite the NeXus default McStas coordinate system, i.e. users can thereby - conveniently and explicitly specify the coordinate system(s) that - they wish to use. - - Users are encouraged to write also explicit and clean depends_on fields in - all groups that encode information about where the interpretation of coordinate - systems is relevant. If these depends_on hints are not provided, it is - automatically assumed that all children (to arbitrary depth) - of that branch and sub-branches below the one in which that - :ref:`NXcoordinate_system_set` is defined use either the only NXcoordinate_system_set - instance in that set or the application definition is considered - underconstrained which should at all costs be avoided and in which case - again McStas is assumed. - * 2 and more; as soon as more than one :ref:`NXcoordinate_system_set` is specified - somewhere in the tree, different interpretations are possible as to which - of these coordinate system sets and instances apply or take preference. - We realize that such ambiguities should at all costs be avoided. - However, the opportunity for multiple sets and their instances enables to - have branch-specific coordinate system conventions which could especially - be useful for deep classes where multiple scientific methods are combined or - cases where having a definition of global translation and conversion tables - how to convert between representations in different coordinate systems - is not desired or available for now. - We argue that having 2 or more :ref:`NXcoordinate_system_set` instances and respective - NXcoordinate_system instances makes the interpretation eventually unnecessary - complicated. Instead, developers of application definitions should always try - to work for clarity and thus use only one top-level coordinate system set. - - For these reasons we conclude that the option with one top-level - :ref:`NXcoordinate_system_set` instance is the preferred choice. - - McStas is used if neither an instance of :ref:`NXcoordinate_system_set` nor an instance - of NXcoordinate_system is specified. However, even in this case it is better - to be explicit like for every other coordinate system definition to support - users with interpreting the content and logic behind every instance of the tree. - - How to store coordinate systems inside :ref:`NXcoordinate_system_set`? - Individual coordinate systems should be specified as members of the - :ref:`NXcoordinate_system_set` instance using instances of NXcoordinate_system. - - How many individual instances of NXcoordinate_system to allow within one - instance of :ref:`NXcoordinate_system_set`? - - * 0; This case should be avoided for the sake of clarity but this case could - mean the authors of the definition meant that McStas is used. We conclude, - McStas is used in this case. - * 1; Like above-mentioned this case has the advantage that it is explicit - and faces no ambiguities. However, in reality typically multiple - coordinate systems have to be mastered especially for complex - multi-signal modality experiments. - * 2 or more; If this case is realized, the best practice is that in every - case where a coordinate system should be referred to the respective class - has a depends_on field which resolves the possible ambiguities which specific - coordinate systems is referred to. The benefit of this explicit and clear - specifying of the coordinate system used in every case is that especially - in combination with having coordinate systems inside deeper branches - makes up for a very versatile, backwards compatible, but powerful system - to express different types of coordinate systems using NeXus. In the case - of two or more instances of NXcoordinate_system in one :ref:`NXcoordinate_system_set`, - it is also advised to specify the relationship between the two coordinate systems by - using the (NXtransformations) group within NXcoordinate_system. - - In effect, 1 should be the preferred choice. However, if more than one coordinate - system is defined for practical purposes, explicit depends_on fields should - always guide the user for each group and field which of the coordinate system - one refers to. - - - - Convention how a positive rotation angle is defined when viewing - from the end of the rotation unit vector towards its origin, - i.e. in accordance with convention 2 of - DOI: 10.1088/0965-0393/23/8/083501. - Counter_clockwise is equivalent to a right-handed choice. - Clockwise is equivalent to a left-handed choice. - - - - - - - - - - How are rotations interpreted into an orientation - according to convention 3 of - DOI: 10.1088/0965-0393/23/8/083501. - - - - - - - - - - How are Euler angles interpreted given that there are several choices (e.g. zxz, xyz) - according to convention 4 of DOI: 10.1088/0965-0393/23/8/083501. - - The most frequently used convention is zxz, which is based on the work of H.-J. Bunge - but other conventions are possible. Apart from undefined, proper Euler angles - are distinguished from (improper) Tait-Bryan angles. - - - - - - - - - - - - - - - - - - - - To which angular range is the rotation angle argument of an - axis-angle pair parameterization constrained according to - convention 5 of DOI: 10.1088/0965-0393/23/8/083501. - - - - - - - - - Which sign convention is followed when converting orientations - between different parameterizations/representations according - to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. - - - - - - - - - - - - - Details about eventually relevant named directions that may give reasons for anisotropies. - The classical example is mechanical processing where one has to specify which directions - (e.g. rolling, transverse, and normal direction) align how with the direction of the base - vectors of the sample_reference_frame. - - It is assumed that the configuration is inspected by looking towards the sample surface. - If a detector is involved, it is assumed that the configuration is inspected from a position - that is located behind this detector. - - If any of these assumptions is not met, the user is required to explicitly state this. - - Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the - base vectors of this coordinate system as Xp, Yp, Zp. - - - - - Details about the sample_reference_frame that is typically overlaid onto the surface of the sample. - - It is assumed that the configuration is inspected by looking towards the sample surface. - If a detector is involved, it is assumed that the configuration is inspected from a position - that is located behind this detector. - - If any of these assumptions is not met, the user is required to explicitly state this. - - Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the - base vectors of this coordinate system as Xs, Ys, Zs. - - - - - Details about the detector_reference_frame for a specific detector. - - Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the - base vectors of this coordinate system as Xd, Yd, Zd. - - It is assumed that the configuration is inspected by looking towards the sample surface - from a position that is located behind the detector. - - If any of these assumptions is not met, the user is required to explicitly state this. - - - diff --git a/base_classes/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml deleted file mode 100644 index a6f57819b6..0000000000 --- a/base_classes/NXcorrector_cs.nxdl.xml +++ /dev/null @@ -1,221 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of images taken, at least one. - - - - - Base class for a corrector reducing (spherical) aberrations in electron microscopy. - - Different technology partners use different naming schemes and - models for quantifying the aberration coefficients. - - The corrector in an electron microscope is composed of multiple lenses - and multipole stigmators with details specific for the technology partner - and microscope. Many of their technical details is proprietary knowledge. - - If functionalities for correcting multiple aberrations are included in - one :ref:`NXcomponent` `like it is reported here <https://www.ceos-gmbh.de/en/research/electrostat>`_ - use multiple groups: - - * :ref:`NXcorrector_cs` for spherical aberration - * :ref:`NXmonochromator` for energy filtering or chromatic aberration - * corrector_ax in :ref:`NXem` for axial astigmatism correction - - - - - Was the corrector used? - - - - - - Specific information about the alignment procedure that is a process during which - the corrector is configured to enable calibrated usage of the instrument. - - This :ref:`NXprocess` group should also be used when one describes in a computer - simulation the specific details about the modelled or assumed aberration - corrections. - - - - Discouraged free-text field to add further details about the alignment - procedure. - - - - - The outer tilt angle of the beam in tableau acquisition. - - TODO: The relevant axes which span the tilt_angle need a - cleaner description. - - - - - - - - The exposure time of single tilt images. - - - - - - - - The factor of enlargement of the apparent size, - not the physical size, of an object. - - - - - - - - The images taken during the alignment procedure. - - - - - Place for storing measured or estimated aberrations (for each image or final). - - See `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) - for different definitions available and further details. Table 7-2 of Ibid. publication (page 305ff) documents how - to convert from the Nion to the CEOS definitions. Conversion tables are also summarized by `Y. Liao <https://www.globalsino.com/EM/page3740.html>`_. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/base_classes/NXcrystal_structure.nxdl.xml b/base_classes/NXcrystal_structure.nxdl.xml deleted file mode 100644 index e01993be3e..0000000000 --- a/base_classes/NXcrystal_structure.nxdl.xml +++ /dev/null @@ -1,274 +0,0 @@ - - - - - - - - - Number of reflectors (Miller crystallographic plane triplets). - - - - - Number of atom positions. - - - - - Dimensionality of the lattice. - - - - - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. - - - - Details in which reference frame the unit cell is defined. - - - - - Dimensionality of the lattice. - - - - - - - - - - Reference to another resource that was used for - instantiating this structure model. - - - - - Crystallography unit cell parameters a, b, and c. - - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma. - - - - - - - - Area of the unit cell considering that d = 2. - - - - - Volume of the unit cell considering that d = 3. - - - - - Crystal system - - - - - - - - - - - - - - - Laue group using International Table of Crystallography Notation. - - - - - - Point group using International Table of Crystallography Notation. - - - - - - Space group from the International Table of Crystallography Notation. - - - - - - True if space group is considered a centrosymmetric one. - False if space group is considered a non-centrosymmetric one. - Centrosymmetric has all types and combinations of symmetry elements - (translation, rotational axis, mirror planes, center of inversion) - Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). - Chiral compared to non-centrosymmetric is constrained (no mirror planes). - - - - - True if space group is considered a chiral one. - False if space group is consider a non-chiral one. - - - - - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - - - - - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - - - - - Label for each atom position. - - - - - - - - The hash value :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - Atom positions. - - - - - - - - Details the reference frame in which the positions are defined. - - - - - - - Relative occupancy of the atom position. - - - - - - - - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - - - - - - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - - - - - - - - - Spacing between crystallographic planes as defined by field miller. - - - - - - - - Relative intensity of the signal for the plane. - - - - - - - - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - - - - diff --git a/base_classes/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml deleted file mode 100644 index 6303eb3ae7..0000000000 --- a/base_classes/NXcs_computer.nxdl.xml +++ /dev/null @@ -1,146 +0,0 @@ - - - - - - Base class for reporting the description of a computer - - - - Given name/alias to the computing system, e.g. MyDesktop. - - - - - Name of the operating system, e.g. Windows, Linux, Mac, Android. - - - - Version plus build number, commit hash, or description of an ever - persistent resource where the source code of the program and build - instructions can be found so that the program can be configured in - such a manner that the result file is ideally recreatable yielding - the same results. - - - - - - - Ideally a (globally) unique persistent identifier of the computer, i.e. - the Universally Unique Identifier (UUID) of the computing node. - - - - - - Details about the system of processing units e.g. (classical) processing units (CPUs), - coprocessor, graphic cards, accelerator processing units or a system of these. - - - - Granularizing the processing units. Typical examples, a desktop computer - with a single CPU one could describe using one instance of NXcircuit. - A dual-socket server one could describe using two instances NXcircuit - A server with two dual-socket server nodes one could describe with - four instances of NXcircuit surplus a field with their level in the hierarchy. - - - - General type of the processing unit - - - - - - - - - - - Given name - - - - - - - Details about the memory system. - - - - Granularizing the components of the memory system. - - - - Qualifier for the type of random access memory. - - - - - - - - - Total amount of data which the medium can hold. - - - - - Given name - - - - - - - Details about the I/O system. - - - - Granularizing the components of the I/O system. - - - - Qualifier for the type of storage medium used. - - - - - - - - - - Total amount of data which the medium can hold. - - - - - Given name - - - - - - diff --git a/base_classes/NXdata.nxdl.xml b/base_classes/NXdata.nxdl.xml index 8b445f1e21..9562baa93f 100644 --- a/base_classes/NXdata.nxdl.xml +++ b/base_classes/NXdata.nxdl.xml @@ -309,20 +309,6 @@ - - - Points to the path of a field defining the data to which the `DATA` group refers. - - This concept allows to link the data to a respective field in the NeXus hierarchy, thereby - defining the physical quantity it represents. - - Example: - If the data corresponds to a readout of a detector, ``@reference`` links - to that detectors data: - - @reference: '/entry/instrument/detector/data' for a 2D detector - - - - - Electronic level probed in X-ray spectroscopy or resonance experiments. - - - - Symbol of the chemical element. - - For each, the atomic number, common English name, and standard atomic weight are also given. - - - - - Z=1, name="hydrogen", standard_atomic_weight=1.0078 - - - - - Z=2, name="helium", standard_atomic_weight=4.0026 - - - - - Z=3, name="lithium", standard_atomic_weight=6.94 - - - - - Z=4, name="beryllium", standard_atomic_weight=9.0122 - - - - - Z=5, name="boron", standard_atomic_weight=10.81 - - - - - Z=6, name="carbon", standard_atomic_weight=12.011 - - - - - Z=7, name="nitrogen", standard_atomic_weight=14.007 - - - - - Z=8, name="oxygen", standard_atomic_weight=15.999 - - - - - Z=9, name="fluorine", standard_atomic_weight=18.9984 - - - - - Z=10, name="neon", standard_atomic_weight=20.1797 - - - - - Z=11, name="sodium", standard_atomic_weight=22.9898 - - - - - Z=12, name="magnesium", standard_atomic_weight=24.305 - - - - - Z=13, name="aluminum", standard_atomic_weight=26.9815 - - - - - Z=14, name="silicon", standard_atomic_weight=28.085 - - - - - Z=15, name="phosphorus", standard_atomic_weight=30.9738 - - - - - Z=16, name="sulfur", standard_atomic_weight=32.06 - - - - - Z=17, name="chlorine", standard_atomic_weight=35.453 - - - - - Z=18, name="argon", standard_atomic_weight=39.948 - - - - - Z=19, name="potassium", standard_atomic_weight=39.0983 - - - - - Z=20, name="calcium", standard_atomic_weight=40.078 - - - - - Z=21, name="scandium", standard_atomic_weight=44.9559 - - - - - Z=22, name="titanium", standard_atomic_weight=47.867 - - - - - Z=23, name="vanadium", standard_atomic_weight=50.9415 - - - - - Z=24, name="chromium", standard_atomic_weight=51.996 - - - - - Z=25, name="manganese", standard_atomic_weight=54.938 - - - - - Z=26, name="iron", standard_atomic_weight=55.845 - - - - - Z=27, name="cobalt", standard_atomic_weight=58.9332 - - - - - Z=28, name="nickel", standard_atomic_weight=58.6934 - - - - - Z=29, name="copper", standard_atomic_weight=63.546 - - - - - Z=30, name="zinc", standard_atomic_weight=65.38 - - - - - Z=31, name="gallium", standard_atomic_weight=69.72 - - - - - Z=32, name="germanium", standard_atomic_weight=72.63 - - - - - Z=33, name="arsenic", standard_atomic_weight=74.9216 - - - - - Z=34, name="selenium", standard_atomic_weight=78.971 - - - - - Z=35, name="bromine", standard_atomic_weight=79.904 - - - - - Z=36, name="krypton", standard_atomic_weight=83.798 - - - - - Z=37, name="rubidium", standard_atomic_weight=85.4678 - - - - - Z=38, name="strontium", standard_atomic_weight=87.62 - - - - - Z=39, name="yttrium", standard_atomic_weight=88.9058 - - - - - Z=40, name="zirconium", standard_atomic_weight=91.224 - - - - - Z=41, name="niobium", standard_atomic_weight=92.9064 - - - - - Z=42, name="molybdenum", standard_atomic_weight=95.95 - - - - - Z=43, name="technetium", standard_atomic_weight=97.907 - - - - - Z=44, name="ruthenium", standard_atomic_weight=101.07 - - - - - Z=45, name="rhodium", standard_atomic_weight=102.906 - - - - - Z=46, name="palladium", standard_atomic_weight=106.42 - - - - - Z=47, name="silver", standard_atomic_weight=107.868 - - - - - Z=48, name="cadmium", standard_atomic_weight=112.414 - - - - - Z=49, name="indium", standard_atomic_weight=114.818 - - - - - Z=50, name="tin", standard_atomic_weight=118.71 - - - - - Z=51, name="antimony", standard_atomic_weight=121.76 - - - - - Z=52, name="tellurium", standard_atomic_weight=127.6 - - - - - Z=53, name="iodine", standard_atomic_weight=126.905 - - - - - Z=54, name="xenon", standard_atomic_weight=131.293 - - - - - Z=55, name="cesium", standard_atomic_weight=132.905 - - - - - Z=56, name="barium", standard_atomic_weight=137.327 - - - - - Z=57, name="lanthanum", standard_atomic_weight=138.905 - - - - - Z=58, name="cerium", standard_atomic_weight=140.116 - - - - - Z=59, name="praseodymium", standard_atomic_weight=140.908 - - - - - Z=60, name="neodymium", standard_atomic_weight=144.242 - - - - - Z=61, name="promethium", standard_atomic_weight=145.0 - - - - - Z=62, name="samarium", standard_atomic_weight=150.36 - - - - - Z=63, name="europium", standard_atomic_weight=151.96 - - - - - Z=64, name="gadolinium", standard_atomic_weight=157.25 - - - - - Z=65, name="terbium", standard_atomic_weight=158.925 - - - - - Z=66, name="dysprosium", standard_atomic_weight=162.5 - - - - - Z=67, name="holmium", standard_atomic_weight=164.93 - - - - - Z=68, name="erbium", standard_atomic_weight=167.259 - - - - - Z=69, name="thulium", standard_atomic_weight=168.934 - - - - - Z=70, name="ytterbium", standard_atomic_weight=173.045 - - - - - Z=71, name="lutetium", standard_atomic_weight=174.967 - - - - - Z=72, name="hafnium", standard_atomic_weight=178.49 - - - - - Z=73, name="tantalum", standard_atomic_weight=180.948 - - - - - Z=74, name="tungsten", standard_atomic_weight=183.84 - - - - - Z=75, name="rhenium", standard_atomic_weight=186.207 - - - - - Z=76, name="osmium", standard_atomic_weight=190.23 - - - - - Z=77, name="iridium", standard_atomic_weight=192.217 - - - - - Z=78, name="platinum", standard_atomic_weight=195.084 - - - - - Z=79, name="gold", standard_atomic_weight=196.967 - - - - - Z=80, name="mercury", standard_atomic_weight=200.592 - - - - - Z=81, name="thallium", standard_atomic_weight=204.383 - - - - - Z=82, name="lead", standard_atomic_weight=207.2 - - - - - Z=83, name="bismuth", standard_atomic_weight=208.98 - - - - - Z=84, name="polonium", standard_atomic_weight=209.0 - - - - - Z=85, name="astatine", standard_atomic_weight=210.0 - - - - - Z=86, name="radon", standard_atomic_weight=222.0 - - - - - Z=87, name="francium", standard_atomic_weight=223.0 - - - - - Z=88, name="radium", standard_atomic_weight=226.0 - - - - - Z=89, name="actinium", standard_atomic_weight=227.0 - - - - - Z=90, name="thorium", standard_atomic_weight=232.038 - - - - - Z=91, name="protactinium", standard_atomic_weight=231.036 - - - - - Z=92, name="uranium", standard_atomic_weight=238.029 - - - - - Z=93, name="neptunium", standard_atomic_weight=237.048 - - - - - Z=94, name="plutonium", standard_atomic_weight=239.052 - - - - - Z=95, name="americium", standard_atomic_weight=243.0 - - - - - Z=96, name="curium", standard_atomic_weight=247.0 - - - - - Z=97, name="berkelium", standard_atomic_weight=247.0 - - - - - Z=98, name="californium", standard_atomic_weight=251.0 - - - - - Z=99, name="einsteinium", standard_atomic_weight=252 - - - - - Z=100, name="fermium", standard_atomic_weight=257 - - - - - Z=101, name="mendelevium", standard_atomic_weight=258 - - - - - Z=102, name="nobelium", standard_atomic_weight=259 - - - - - Z=103, name="lawrencium", standard_atomic_weight=266 - - - - - Z=104, name="rutherfordium", standard_atomic_weight=267 - - - - - Z=105, name="dubnium", standard_atomic_weight=268 - - - - - Z=106, name="seaborgium", standard_atomic_weight=269 - - - - - Z=107, name="bohrium", standard_atomic_weight=270 - - - - - Z=108, name="hassium", standard_atomic_weight=269 - - - - - Z=109, name="meitnerium", standard_atomic_weight=278 - - - - - Z=110, name="darmstadtium", standard_atomic_weight=281 - - - - - Z=111, name="roentgenium", standard_atomic_weight=282 - - - - - Z=112, name="copernicium", standard_atomic_weight=285 - - - - - Z=113, name="nihonium", standard_atomic_weight=286 - - - - - Z=114, name="flerovium", standard_atomic_weight=289 - - - - - Z=115, name="moscovium", standard_atomic_weight=290 - - - - - Z=116, name="livermorium", standard_atomic_weight=293 - - - - - Z=117, name="tennessine", standard_atomic_weight=294 - - - - - Z=118, name="oganesson", standard_atomic_weight=294 - - - - - - - IUPAC symbol of the electronic level. - For each level, the electronic orbital configuration is also given - - For reference, see Jenkins, R., Manne, R., Robin, R., & Senemaud, C. (1991). - IUPAC—nomenclature system for x-ray spectroscopy. X-Ray Spectrometry, 20(3), 149-155. - - - - - same as 1s in level_xray - - - - - 2s - - - - - 2p_{1/2} - - - - - 2p_{3/2} - - - - - 3s - - - - - 3p_{1/2} - - - - - 3p_{3/2} - - - - - 3d_{3/2} - - - - - 3d_{5/2} - - - - - 4s - - - - - 4p_{1/2} - - - - - 4p_{3/2} - - - - - 4d_{3/2} - - - - - 4d_{5/2} - - - - - 4f_{5/2} - - - - - 4f_{7/2} - - - - - 5s - - - - - 5p_{1/2} - - - - - 5p_{3/2} - - - - - 5d_{3/2} - - - - - 5d_{5/2} - - - - - 5f_{5/2} - - - - - 5f_{7/2} - - - - - 6s - - - - - 6p_{1/2} - - - - - 6p_{3/2} - - - - - - - Electronic orbital configuration of the electronic level. - - - - - same as K in level_xray - - - - - L1 - - - - - L3 - - - - - M1 - - - - - M2 - - - - - M3 - - - - - M4 - - - - - M5 - - - - - N1 - - - - - N2 - - - - - N3 - - - - - N4 - - - - - N5 - - - - - N6 - - - - - N7 - - - - - O1 - - - - - O2 - - - - - O3 - - - - - O4 - - - - - O5 - - - - - O6 - - - - - O7 - - - - - P1 - - - - - P2 - - - - - P3 - - - - - - - description of X-ray electronic level - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - diff --git a/base_classes/NXelectronanalyser.nxdl.xml b/base_classes/NXelectronanalyser.nxdl.xml deleted file mode 100644 index 096e8351a5..0000000000 --- a/base_classes/NXelectronanalyser.nxdl.xml +++ /dev/null @@ -1,310 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of fast axes (axes acquired simultaneously, without scanning a - physical quantity) - - - - - Number of slow axes (axes acquired scanning a physical quantity) - - - - - Number of data points in the transmission function. - - - - - Basic class for describing a electron analyzer. - - This concept is related to term `12.59`_ of the ISO 18115-1:2023 standard. - - .. _12.59: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.59 - - - - Free text description of the type of the detector - - - - - Name or model of the equipment - - - - Acronym or other shorthand name - - - - - - Work function of the electron analyser. - - The work function of a uniform surface of a conductor is the minimum energy required to remove - an electron from the interior of the solid to a vacuum level immediately outside the solid surface. - - The kinetic energy :math:`E_K` of a photoelectron emitted from an energy-level with binding energy - :math:`E_B` below the Fermi level is given by :math:`E_K = h\nu - E_B - W = h\nu - E_B - e \phi_{\mathrm{sample}}`. - Here, :math:`W = e \phi_{\mathrm{sample}}` is the work function of the sample surface (with the potential difference :math:`\phi_{\mathrm{sample}}` - between the electrochemical potential of electrons in the bulk and the electrostatic potential of an electron in the vacuum just outside the surface). - - In PES measurements, the sample and the spectrometer (with work function :math:`\phi_{\mathrm{spectr.}}`) - are electrically connected and therefore their Fermi levels are aligned. Due to the difference in local - vacuum level between the sample and spectrometer, there exists an electric potential difference (contact potential) - :math:`\Delta\phi = \phi_{\mathrm{sample}} - \phi_{\mathrm{spectr.}}`. The measured kinetic energy of - a photoelectron in PES is therefore given by - :math:`E_K^{\mathrm{meas.}} = h\nu - E_B + \Delta \phi = h\nu - E_B - e \phi_{\mathrm{spectr.}}`. - As a result, the measured kinetic energy :math:`E_K^{\mathrm{meas.}}` of a photoelectron is `independent` - of the sample work function. Nonetheless, the work function :math:`\phi_s` needs to be known to - accurately determine the binding energy scale. - - - - - Energy range of the voltage supplies. This influences the noise of the supplies, - and thereby the energy resolution. - - - - - Energy resolution of the analyser with the current setting. May be linked from an - NXcalibration. - - - - - - - - - Minimum distinguishable energy separation in the energy spectra. - - This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. - - .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 - - - - - - Ratio of the energy resolution of the electron analyser at a specified energy - value to that energy value. - - This concept is related to term `10.7`_ of the ISO 18115-1:2023 standard. - - .. _10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 - - - - - - Momentum resolution of the electron analyser (FWHM) - - - - - - - - - - - - Angular resolution of the electron analyser (FWHM) - - - - - - - - - - - - Spatial resolution of the electron analyser (Airy disk radius) - - This concept is related to term `10.14`_ of the ISO 18115-1:2023 standard. - - .. _10.14: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.15 - - - - - - - - - - - - List of the axes that are acquired simultaneously by the detector. - These refer only to the experimental variables recorded by the electron analyser. - Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. - - .. csv-table:: Examples - :header: "Mode", "fast_axes", "slow_axes" - - Hemispherical in ARPES mode, "['energy', 'kx']","" - "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] - "Tof", "['energy', 'kx', 'ky']","" - "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" - - Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. - If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. - - - - - - - - List of the axes that are acquired by scanning a physical parameter, listed in - order of decreasing speed. See fast_axes for examples. - - - - - - - - Transmission function of the electron analyser. - - The transmission function (TF) specifies the detection efficiency per solid angle for electrons of - different kinetic energy passing through the electron analyser. It depends on the spectrometer - geometry as well as operation settings such as lens mode and pass energy. - The transmission function is usually given as relative intensity vs. kinetic energy. - - The TF is used for calibration of the intensity scale in quantitative XPS. Without proper - transmission correction, a comparison of results measured from the same sample using different - operating modes for an instrument would show significant variations in atomic - concentrations. - - This concept is related to term `7.15`_ of the ISO 18115-1:2023 standard. - - .. _7.15: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:7.15 - - - - - - - - - - - - - - Kinetic energy values - - - - - - - - Relative transmission efficiency for the given kinetic energies - - - - - - - - - Refers to the last transformation specifying the position of the electron analyser - in the NXtransformations chain. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the electron analyser as a component in the instrument. Conventions - from the NXtransformations base class are used. In principle, the McStas - coordinate system is used. The first transformation has to point either to - another component of the system or "." (for pointing to the reference frame) to - relate it relative to the experimental setup. Typically, the components of a - system should all be related relative to each other and only one component - should relate to the reference coordinate system. - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - - - Describes the electron collection (spatial and momentum imaging) column - - - - - Describes the energy dispersion section - - - - - Describes the spin dispersion section - - - - - Describes the electron detector - - - - - Deflectors outside the main optics ensembles described by the subclasses - - - - - Individual lenses outside the main optics ensembles described by the subclasses - - - - - - Any other resolution not explicitly named in this base class. - - - diff --git a/base_classes/NXem_correlation.nxdl.xml b/base_classes/NXem_correlation.nxdl.xml deleted file mode 100644 index 14cf17914d..0000000000 --- a/base_classes/NXem_correlation.nxdl.xml +++ /dev/null @@ -1,245 +0,0 @@ - - - - - - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. - - - - Details about processing steps. - - - - - - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXmicrostructure partner application - definition. The respective source of the data in an instance of NXmicrostructure can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - Descriptor representing the image contrast. - - - - - - Title of the default plot. - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Descriptor values. - - - - - - Calibrated coordinate along the z-axis. - - - - - - - Label for the z axis - - - - - - Calibrated coordinate along the y-axis. - - - - - - - Label for the y axis - - - - - - Calibrated coordinate along the x-axis. - - - - - - - Label for the x axis - - - - - - - diff --git a/base_classes/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml deleted file mode 100644 index a1926fef46..0000000000 --- a/base_classes/NXem_ebsd.nxdl.xml +++ /dev/null @@ -1,712 +0,0 @@ - - - - - - - - Number of arguments per orientation for given parameterization. - - - - - Number of scan points. - - - - - Number of pixel along the slowest changing dimension for a rediscretized, - i.e. standardized default plot orientation mapping. - - - - - Number of pixel along slow changing dimension for a rediscretized i.e. - standardized default plot orientation mapping. - - - - - Number of pixel along fast changing dimension for a rediscretized i.e. - standardized default plot orientation mapping. - - - - - Number of phase solutions - - - - - Base class method-specific for Electron Backscatter Diffraction (EBSD). - - The general procedure of an EBSD experiment is as follows. - Users load the specimen, collect first a coarse image of the surface. - Next, they set an approximate value for the calibrated working distance and - tilt the stage to set the desired diffraction conditions. - - Users then typically configure the microscope for collecting higher quality data - and push in the EBSD detector. Subsequently, they fine tune the illumination - and aberration corrector settings and select one or multiple ROIs for - the microscope to machine off automatically. They configure on-the-fly - indexing parameter and start the measurement queue. - - Nowadays, this is in most cases an automated process. The pattern - collection runs during the allocated microscope session until the - queue finishes or gets interrupted by errors or the next user terminates - sessions which run over time. - - Kikuchi pattern surplus eventually multi-modal detector signals are - collected and usually indexed on-the-fly. Patterns may be stored or not - so one should not assume that raw data are always stored. - - Results are stored in files, which afterwards are typically copied - automatically or manual for archival purposes to certain storage - locations or further consumption. The result of such an EBSD - measurement/experiment is a set of usually proprietary or open files - from technology partners. - - This :ref:`NXem_ebsd` base class is a proposal how to represent method-specific - data, metadata, and connections between these for the research field of - electron microscopy. - - More specifically, exemplified here for electron backscatter diffraction (EBSD) - we show how NeXus can be used to solve two key documentation issues so far - missing in the field of EBSD. - - Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted - according to NXem_ebsd) stores the connection between the microscope session and - the key datasets which are considered typically results of the various processing - steps involved when working with EBSD data. - - Different groups in NXem_ebsd make connections to data artifacts which were collected - when working with electron microscopes via the NXem application definition. - Using a file which stores information according to the NXem application definition - has the benefit that it connects the sample, references to the sample processing, - the user operating the microscope, details about the microscope session, - and details about the acquisition and eventual indexing of Kikuchi pattern, - associated overview images, like secondary electron or backscattered electron - images of the region-of-interest probed and many more pieces of information. - - Secondly, NXem_ebsd connects and stores the conventions and reference frames - which were used and which are the key to a correct mathematical interpretation - of every EBSD result. Otherwise, results would be ripped out of their context, - as it is the current situation with many traditional studies where EBSD data - were indexed on-the-fly and shared with the community only via sharing - the strongly processed results file in some technology-partner-specific file - format but without communicating all conventions or relying on the assumptions - that colleagues likely know these conventions even though multiple definitions - are possible. - - NXem_ebsd covers experiments with one-, two-dimensional, and so-called three- - dimensional EBSD datasets. The third dimension is either time (in the case of - quasi in-situ experiments) or space (in the case of serial-sectioning) methods - where a combination of mechanical or ion milling is used repetitively to measure - the same region-of-interest at different depth increments. Material removal - can be achieved with electron or ion polishing, using manual - steps or using automated equipment like a robot system. - - Three-dimensional experiments require to follow a sequence of specimen, surface - preparation, and data collection steps. By nature these methods are destructive - in that they either require the removal of the previously measured material region - or that the sample surface can degrade due to e.g. contamination or other - electron-matter interaction. - - For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are - combined into one reconstructed stack. That is serial-sectioning is mainly a - computational workflow. Users collect data for each serial sectioning step - via an experiment. This assures that data for associated microscope sessions - and steps of data processing stay connected and contextualized. - - Eventual tomography methods also use such a workflow because first diffraction - images are collected (e.g. with X-ray) and then these imagres are indexed and - computed into a 3D orientation mapping. The here proposed NXem_ebsd application - definition contains conceptual ideas how this splitting between measurement and - post-processing can be granularized also for such X-ray-based techniques, whether - it be 3DXRD or HEDM. - - This concept is related to term `Electron Backscatter Diffraction`_ of the EMglossary standard. - - .. _Electron Backscatter Diffraction: https://purls.helmholtz-metadaten.de/emg/EMG_00000019 - - - - - Details about the gnomonic (projection) reference frame. - - It is assumed that the configuration is inspected by looking towards the sample surface. - If a detector is involved, it is assumed that the configuration is inspected from a position - that is located behind this detector. - - If any of these assumptions is not met, the user is required to explicitly state this. - - Reference DOI: 10.1016/j.matchar.2016.04.008 suggests to label the - base vectors of this coordinate system as Xg, Yg, Zg. - - - - Origin of the gnomonic_projection_reference_frame. - - Reference DOI: 10.1016/j.matchar.2016.04.008 suggests to - assume that this is coordinate Xg = 0, Yg = 0, Zg = 0. - - - - - - - - - Direction of the positively pointing x-axis base vector of the - gnomonic_reference_frame. - - - - - - - - - - - - - - Direction of the positively pointing y-axis base vector of the - gnomonic_reference_frame. - - - - - - - - - - - - - - Direction of the positively pointing z-axis base vector of the - gnomonic_reference_frame. - - - - - - - - - - - - - - - Details about the definition of the pattern centre as a special point in the gnomonic_reference_frame. - - Keep in mind that the gnomonic space is in virtually all cases embedded in the detector space. - Specifically, the XgYg plane is defined such that it is laying inside the XdYd plane - (of the detector reference frame). - - When the normalization direction is the same as e.g. the detector x-axis direction one - effectively normalizes in fractions of the width of the detector. - - The issue with terms like width and height is that these degenerate if the detector - region-of-interest is square-shaped. This is why instead of referring to width and height - one should report as if one were to measure practically with a ruler and one is specific - about in which direction positive distances are measured. - - For the concepts used to specify the boundary_convention it is assumed that the - region-of-interest is defined by a rectangle, referring to the direction of outer-unit - normals to the respective edges of this rectangle. - - - - From which border of the EBSP (in the detector reference frame) is the pattern - centre's x-position (PCx) measured. - - - - - - - - - - - - In which direction are positive values for the x-axis coordinate value measured - from the specified boundary. - - - - - - - - - - - - From which border of the EBSP (in the detector reference frame) is the pattern - centre's y-position (PCy) measured. - - - - - - - - - - - - In which direction are positive values for the y-axis coordinate value measured - from the specified boundary. - - - - - - - - - - - - - - This group documents relevant details about the conditions and the tools - used for measuring a stack of Kikuchi diffraction pattern with an - electron microscope. - - The most frequently collected EBSD data are captured for rectangular - regions-of-interested which are sampled with regular square or - hexagon-shaped pixels. - - - - Physical time since the beginning of a timestamp that is required to be - same for all experiments in the set. The purpose of this marker is - to identify how all experiments in the set need to be arranged - sequentially based on the time elapsed. - The time is relevant to sort e.g. experiments of consecutive quasi - in-situ experiments where a measurement was e.g. taken after 0 minutes, - 30 minutes, 6 hours, or 24 hours of annealing. - - - - Timestamp relative to which time was counted to aid - converting between time and timestamp. - - - - - - - If available and it is stored in an instance of an application definition this field - specifies the path to an instance of :ref:`NXdata` where the measured patterns - are stored. - - - - - Reference (e.g. path and filename) to an existent data artifact which - stores either the measured pattern or input (already processed EBSD data). - - - - - - This group documents relevant details about the conditions and the tools - used for simulating a stack of Kikuchi diffraction pattern with some - physical model. - - This group should not be confused with a group named simulation that - is however an instance of NXem_sim. Instead, the simulation group here - should be used if (e.g. instead of a measurement) a stack of pattern - were simulated that one wishes to use for indexing patterns. - - In many practical cases where pattern are analyzed on-the-fly and dictionary - indexing strategies are used, so-called master pattern(s) are used to compare - measured or simulated pattern with the master pattern. In this case, - master pattern are the result of a computer simulation and thus should - be stored using an own properly documented entry within a simulation - group as an instance of :ref:`NXem_sim`. - - - - If available and it is stored in an instance of an application definition this field specifies - the path to an instance of :ref:`NXimage_set` where the simulated patterns are stored. - - - - - Reference (e.g. path and filename) to an existent digital resource which - stores either the pattern or input (already processed EBSD data) - which is now processed further as described by this NXem_ebsd instance. - - - - - - The EBSD system, including components like the electron gun, pole-piece, - stage tilting, EBSD detector, and the gnomonic projection have to be - calibrated to achieve reliable indexing results. - - Specifically, the gnomonic projection has to be calibrated. - Typically, silicon or quartz crystals are used for this purpose. - - Considering a system is well-calibrated, it is much more frequently the - case in practice that users assume the system is calibrated (and thus usable) - vs. they perform the calibration of the EBSD system. - - In the first case, the user assumes that the principle geometry of the - hardware components and the settings in the control and EBSD pattern - acquisition software has been calibrated. Consequently, users pick from - an existent library of phase candidates, i.e. - :ref:`NXcrystal_structure` instances. Examples are - reflector models as stored in CRY files (HKL/Channel 5/Flamenco). - - In the second case, users calibrate the system during the session - using standards (silicon, quartz, or other common specimens). - There is usually one person in each lab responsible for doing such - calibrations. Often this person or technician is also in charge of - configuring the graphical user interface and software with which most - users control and perform their analyses. - - For EBSD this has key implications: Taking TSL OIM/EDAX as an example, - the conventions how orientations are stored is affected by how the - reference frames are configured and this setup is made at the level - of the GUI software. - - Unfortunately, these pieces of information are not necessarily stored - in the results files. In effect, key conventions become disconnected - from the data so it remains the users' obligation to remember these - settings or write these down in a lab notebook. Otherwise, these metadata - get lost. All these issues are a motivation and problem which - :ref:`NXem_ebsd` solves in that all conventions can be specified explicitly. - - - - If available and it is stored in an instance of an application definition this field specifies - the path to an instance of :ref:`NXem_msr` where calibration is stored. - - - - - Reference to a digital resource where the calibration is stored. - - - - - - Indexing is a data processing step performed either after or while - (on-the-fly) the beam scans the specimen. The resulting method is also - known as orientation imaging microscopy (OIM). - - Different algorithms can be used to index EBSD pattern. Common to them - is the computational step where simulated reference pattern are compared - with measured or simulated patterns. These latter patterns are referred - to via the measurement or simulation groups of this base class. - - Quality descriptors are defined based on which an indexing algorithm - yields a quantitative measure of how similar measured and reference - pattern are, and thus if no, one, or multiple so-called solutions - were found. - - Assumed or simulated pattern are simulated using kinematic or dynamical - theory of electron diffraction delivering master pattern. - - The Hough transform is essentially a discretized Radon transform (for details see `M. van Ginkel et al. <https://www.semanticscholar.org/paper/A-short-introduction-to-the-Radon-and-Hough-and-how-Ginkel/fb6226f606cad489a15e38ed961c419037ccc858>`_). - Recently, dictionary-based indexing methods are increasingly becoming used - partly driven by the interest to use artificial intelligence algorithms. - - - - This group enables to establish a logical connection between previous - processing steps or on-the-fly-performed indexing of the EBSD map. - Typically these processing steps are performed with commercial software. - Therefore, in many cases a results file from this indexing is often - all that is communicated and saved. These are typically files in a format - specific to the instrument and its configuration. - - Typical file formats are CPR/CRC, ANG, OSC, HDF5, H5EBSD, EDAXH5. - - - - - Principal algorithm used for indexing. - - - - - - - - - - - - Details about the background correction applied to each Kikuchi pattern. - - - - - Binning i.e. downsampling of the pattern. - - - - - Specific parameter relevant only for certain algorithms used. - - - - - Details for each phase used as a model with which the patterns were - indexed. Instances of :ref:`NXcrystal_structure` in this group must - have the group name prefix phase. The identifier in the name is an - integer. We start counting from 1 because the value 0 is reserved for - the special phase that is the null-model, i.e. the null phase, notIndexed. - - - - - Which return value did the indexing algorithm yield for each scan point. - Practically useful is to use an uint8 mask. - - * 0 - Not analyzed - * 1 - Too high angular deviation - * 2 - No solution - * 100 - Success - * 255 - Unexpected errors - - - - - - - - How many phases i.e. crystal structure models were used to index each - scan point if any? Let's assume an example to explain how this field - should be used: In the simplest case users collected one pattern for - each scan point and have indexed using one phase, i.e. one instance - of an NXem_ebsd_crystal_structure_model. - - In another example users may have skipped some scan points (not indexed) - them at all) and/or used differing numbers of phases for different scan - points. - - The cumulated of this array decodes how phase_identifier and phase_matching - arrays have to be interpreted. In the simplest case (one pattern per scan - point, and all scan points indexed using that same single phase model), - phase_identifier has as many entries as scan points - and phase_matching has also as many entries as scan points. - - - - - - - - The array n_phases_per_scan_point details how the phase_identifier - and the phase_matching arrays have to be interpreted. - - For the example with a single phase phase_identifier has trivial - values either 0 (no solution) or 1 (solution matching - sufficiently significant with the model for phase 1). - - When there are multiple phases, it is possible (although not frequently - needed) that a pattern matches eventually (not equally well) sufficiently - significant with multiple pattern. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models e.g. (ferrite, austenite). - Having such field is especially relevant for recent machine learning - or dictionary based indexing schemes because in combination with - phase_matching these fields communicate the results in a model-agnostic - way. - - Depending on the n_phases_per_scan_point value phase_identifier and - phase_matching arrays represent a collection of concatenated tuples, - which are organized in sequence: The solutions for the 0-th scan point, - the 1-th scan point, the n_sc - 1 th scan point and omitting tuples - for those scan points with no phases according to n_phases_per_scan_point - - - - - - - - One-dimensional array, pattern by pattern labelling the solutions found. - The array n_phases_per_scan_point has to be specified because it details - how the phase_identifier and the phase_matching arrays have to be interpreted. - See documentation of phase_identifier for further details. - - - - - - - - Phase_matching is a descriptor for how well the solution matches or not. - Examples can be confidence_index, mean_angular_deviation, some AI-based - matching probability (other), i.e. the details are implementation-specific. - - - - - - - - - - - - em_lab/ebeam_deflector to retrieve the actual scan positions -although this would be cleaner, also scan_point_positions could be -an instance of NXcg_point_set with a depends_on pointing -to sample_reference_frame ---> - - Calibrated center positions of each scan point - in the sample surface reference system. - - - - - - - - - Fraction of successfully indexed pattern with a phase - not the null-phase vs the number_of_scan_points. - - - - - Number of scan points in the original mapping. - - - - - - An overview of the entire ROI. - - - - Descriptor representing the image contrast. - - - - - - - - - - - - Title of the default plot. - - - - - Descriptor values displaying the ROI. - - - - - - - - - Descriptor values. - - - - - - Calibrated coordinate along the y-axis. - - - - - - - Label for the y axis - - - - - - Calibrated coordinate along the x-axis. - - - - - - - Label for the x axis - - - - - - diff --git a/base_classes/NXem_eds.nxdl.xml b/base_classes/NXem_eds.nxdl.xml deleted file mode 100644 index 6e3d797332..0000000000 --- a/base_classes/NXem_eds.nxdl.xml +++ /dev/null @@ -1,225 +0,0 @@ - - - - - - - - - Number of X-ray photon energy (bins) - - - - - Number of identified elements - - - - - Number of peaks detected - - - - - Number of IUPAC line names - - - - - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDXS). - - `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. - - X-ray spectroscopy is a surface-sensitive technique. Therefore, three-dimensional elemental - characterzation requires typically a sequence of characterization and preparation of the - surface to expose a new surface layer that can be characterized in the next acquisition. - In effect, the resulting three-dimensional elemental information mappings are truely the - result of a correlation and post-processing of several measurements which is the field - of correlative tomographic usage of electron microscopy. - - - - - Details about computational steps how peaks were indexed as elements. - - - - The program with which the indexing was performed. - - - - - Accumulated intensity over all pixels of the region-of-interest. - - - - Accumulated counts - - - - - - - Counts - - - - - - Energy axis - - - - - - - Energy - - - - - - - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - - - - - Associated lower :math:`[e_{min}, e_{max}]` bounds of the - energy which is assumed associated with this peak. - - - - - - - - Theoretical energy of the line according to IUPAC. - - - - - IUPAC notation identifier of the line which the peak represents. - - This can be a list of IUPAC notations for (the seldom) case that - multiple lines are grouped with the same peak. - - - - - - - - - - Comma-separated list of names of elements confirmed in the sample via EDS analysis. - - All members of the list have to be valid chemical_symbols from the periodic table. - - This field can be used when creating instances of NXpeak is not desired. - However, a collection of instances of NXpeak with individual NXion specified - enables also to distinguish isotopic information. - - - - - - - - - Individual element-specific EDS/EDX/EDXS/SXES mapping - - A composition map is an image whose intensities for each pixel are the - accumulated X-ray quanta *under the curve(s)* of a set of peaks. - - These element-specific EDS maps are :ref:`NXimage_set` instances - and need to be named with the name of the element from the - atom_types field. - - We often observe that signal contributions from several peaks - are summarized and shown together, e.g. the combined signal - under the curve of carbon and oxygen. - - In this case specify the processing details using peaks and weights. - - - - Discouraged free-text field to add additional information. - - - - - Comma-separated list of chemical_symbol-IUPAC X-ray (emission) line name that - documents which elements and their specific lines are theoretically located within - the energy_range of the spectrum from which the EDS (element) map has been computed. - - - - - Associated :math:`[e_{min}, e_{max}]` bounds of the energy - range for which spectrum counts have been accumulated. - - - - - - - - - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - - - - - - - - A list of weights by how much the intensity of each peak - under peaks was factorized to display the joint intensity - of the image. - - - - - - diff --git a/base_classes/NXem_eels.nxdl.xml b/base_classes/NXem_eels.nxdl.xml deleted file mode 100644 index 4ddef01176..0000000000 --- a/base_classes/NXem_eels.nxdl.xml +++ /dev/null @@ -1,63 +0,0 @@ - - - - - - - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). - - - - - Details about computational stesp how the zero-loss peak was threaded. - - - - The program with which the zero-loss peak correction was performed. - - - - - - Details about computational steps how peaks were indexed as elements. - - - - The program with which the indexing was performed. - - - - - Name and location of each peak in the spectrum considered to be of relevance. - - - - - NXspectrum_set_em specialized for EELS. - - - - diff --git a/base_classes/NXem_img.nxdl.xml b/base_classes/NXem_img.nxdl.xml deleted file mode 100644 index 5574965371..0000000000 --- a/base_classes/NXem_img.nxdl.xml +++ /dev/null @@ -1,61 +0,0 @@ - - - - - - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). Examples can be single point aka spot - measurements, line profiles, or (rectangular) surface mappings. - The latter pattern is the most frequently used. - - For now the base class provides for scans for which the settings, - binning, and energy resolution is the same for each scan point. - - - - Which imaging mode was used? - - - - - - - - - - - - Annulus inner (first value) and outer (second value) half angle. - - - - - - - - diff --git a/base_classes/NXem_msr.nxdl.xml b/base_classes/NXem_msr.nxdl.xml deleted file mode 100644 index d7d590456f..0000000000 --- a/base_classes/NXem_msr.nxdl.xml +++ /dev/null @@ -1,98 +0,0 @@ - - - - - - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. - - - - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - - - - Given name of the microscope at the hosting institution. - This is an alias. Examples could be NionHermes, Titan, JEOL, - Gemini, etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - - Description of the type of the detector. - - Electron microscopes have typically multiple detectors. - Different technologies are in use like CCD, scintillator, - direct electron, CMOS, or image plate to name but a few. - - - - Instrument-specific alias/name - - - - - - - - - - diff --git a/base_classes/NXem_sim.nxdl.xml b/base_classes/NXem_sim.nxdl.xml deleted file mode 100644 index 610fe885c1..0000000000 --- a/base_classes/NXem_sim.nxdl.xml +++ /dev/null @@ -1,59 +0,0 @@ - - - - - - - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. - - - - Details about the simulation. - - - - - - diff --git a/base_classes/NXenergydispersion.nxdl.xml b/base_classes/NXenergydispersion.nxdl.xml deleted file mode 100644 index 9277979da3..0000000000 --- a/base_classes/NXenergydispersion.nxdl.xml +++ /dev/null @@ -1,209 +0,0 @@ - - - - - - Subclass of NXelectronanalyser to describe the energy dispersion section of a - photoelectron analyser. - - - - Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, - mirror, retarding grid, etc. - - - - - Mean kinetic energy of the electrons in the energy-dispersive portion of the analyser. - This term should be used for hemispherical analysers. - - This concept is related to term `12.63`_ of the ISO 18115-1:2023 standard. - - .. _12.63: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.63 - - - - - Kinetic energy set for the dispersive analyzer section. Can be either the set kinetic energy, - or the whole calibrated energy axis of a scan. - - - - - Drift energy for time-of-flight energy dispersive elements. - - - - - Center of the energy window - - - - - The interval of transmitted energies. It can be two different things depending - on whether the scan is fixed or swept. With a fixed scan it is a 2 vector - containing the extrema of the transmitted energy window (smaller number first). - With a swept scan of m steps it is a 2xm array of windows one for each - measurement point. - - - - - Diameter of the dispersive orbit - - - - - Radius of the dispersive orbit - - - - - Way of scanning the energy axis - - - - - constant :math:`\Delta E` mode, where the electron retardation (i.e., the fraction of pass energy to - kinetic energy, :math:`R = (E_K - W/E_p)`, is scanned, but the pass energy :math:`E_p` is kept constant. - Here, :math:`W = e \phi` is the spectrometer work function (with the potential difference :math:`\phi_{\mathrm{sample}}` - between the electrochemical potential of electrons in the bulk and the electrostatic potential of an electron in the - vacuum just outside the surface). - - This mode is often used in XPS/UPS because the energy resolution does not change with - changing energy (due to the constant pass energy). - - Synonyms: constant :math:`\Delta E` mode, constant analyser energy mode, CAE - mode, FAT mode - - This concept is related to term `12.64`_ of the ISO 18115-1:2023 standard. - - .. _12.64: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.64 - - - - - constant :math:`\Delta E/E` mode, where the pass energy is scanned such that the electron retardation - ratio is constant. In this mode, electrons of all energies are decelerated with this same - fixed factor. Thus, the pass energy is proportional to the kinetic energy. This mode is often - used in Auger electron spectroscopy (AES) to improve S/N for high-KE electrons, but this - leads to a changing energy resolution (:math:`\Delta E \sim E_p`) at different kinetic energies. - It can however also be used in XPS. - - Synonyms: constant :math:`\Delta E/E` mode, constant retardation ratio mode, CRR - mode, FRR mode - - This concept is related to term `12.66`_ of the ISO 18115-1:2023 standard. - - .. _12.66: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.66 - - - - - In the fixed energy (FE) mode, the intensity for one single kinetic energy is measured for a - specified time. This mode is particulary useful during setup or alignment of the - electron analyzer, for analysis of stability of the excitation source or for sample - alignment. - - Since the mode measures intensity as a function of time, the difference in channel signals - is not of interest. Therefore, the signals from all channels are summed. - - Synonyms: FE mode - - - - - Snapshot mode does not involve an energy scan and instead collects data from all channels of - the detector without averaging. The resulting spectrum reflects the energy distribution of - particles passing through the analyzer using the current settings. This mode is commonly used - to position the detection energy at the peak of a peak and record the signal, enabling faster - data acquisition within a limited energy range compared to FAT. Snapshot measurements are - particularly suitable for CCD and DLD detectors, which have multiple channels and can accurately - display the peak shape. While five or nine-channel detectors can also be used for snapshot - measurements, their energy resolution is relatively lower. - - - - - In dither acquisition mode, the kinetic energy of the analyzer is randomly varied by a small value - around a central value and at fixed pass energy. This allows reducing or removing inhomogeneities - of the detector efficiency, such as e.g. imposed by a mesh in front of the detector. - Mostly relevant for CCD/DLD type of detectors. - - - - - - - Length of the tof drift electrode - - - - - Size, position and shape of a slit in dispersive analyzer, e.g. entrance and - exit slits. - - - - - Deflectors in the energy dispersive section - - - - - Individual lenses in the energy dispersive section - - - - - - Specifies the position of the energy dispesive elemeent by pointing to the last - transformation in the transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the energy dispersive element as a component in the instrument. - Conventions from the NXtransformations base class are used. In principle, - the McStas coordinate system is used. The first transformation has to point - either to another component of the system or . (for pointing to the reference frame) - to relate it relative to the experimental setup. Typically, the components of a system - should all be related relative to each other and only one component should relate to - the reference coordinate system. - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - diff --git a/base_classes/NXentry.nxdl.xml b/base_classes/NXentry.nxdl.xml old mode 100644 new mode 100755 index 8f8f323ca9..7c2950340b --- a/base_classes/NXentry.nxdl.xml +++ b/base_classes/NXentry.nxdl.xml @@ -98,62 +98,32 @@ Extended title for entry - - - Unique identifier for the experiment, - defined by the facility, - possibly linked to the proposals - - + + + Unique identifier for the experiment, + defined by the facility, + possibly linked to the proposals + + Brief summary of the experiment, including key objectives. Description of the full experiment (document in pdf, latex, ...) - - User or Data Acquisition defined group of NeXus files or NXentry - + + User or Data Acquisition defined group of NeXus files or NXentry + Brief summary of the collection, including grouping criteria. - + unique identifier for the measurement, defined by the facility. - - + + UUID identifier for the measurement. Version of UUID used - - - City and country where the experiment took place - - - - Start time of experimental run that includes the current - measurement, for example a beam time. - - - - - End time of experimental run that includes the current - measurement, for example a beam time. - - - - - Name of the institution hosting the facility - - - - - Name of the experimental facility - - - - - Name of the laboratory or beamline - - + Reserved for future use by NIAC. @@ -257,4 +227,4 @@ - \ No newline at end of file + diff --git a/base_classes/NXenvironment.nxdl.xml b/base_classes/NXenvironment.nxdl.xml index 74ed194f03..4f878263b2 100644 --- a/base_classes/NXenvironment.nxdl.xml +++ b/base_classes/NXenvironment.nxdl.xml @@ -48,17 +48,6 @@ Note, it is recommended to use NXtransformations instead. - - - This is to be used if there is no actuator/sensor that controls/measures - the environment parameters, but the user would still like to give a value for - it. An example would be a room temperature experiment where the temperature is - not actively measured, but rather estimated. - - Note that this method for recording the environment parameters is not advised, - but using NXsensor and NXactuator is strongly recommended instead. - - NeXus positions components by applying a set of translations and rotations @@ -80,29 +69,6 @@ Additional information, LabView logs, digital photographs, etc - - - Any actuator used to control the environment. This can be linked to an actuator - defined in an NXinstrument instance. - - - - - Any sensor used to monitor the environment. This can be linked to a sensor - defined in an NXinstrument instance. - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - + + diff --git a/base_classes/NXevent_data_apm.nxdl.xml b/base_classes/NXevent_data_apm.nxdl.xml deleted file mode 100644 index 6c287de045..0000000000 --- a/base_classes/NXevent_data_apm.nxdl.xml +++ /dev/null @@ -1,281 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of pulses collected in between start_time and end_time. - - - - - Base class to store state and (meta)data of events over the course of an atom probe experiment. - - This base class applies the concept of the :ref:`NXevent_data_em` base class to the specific needs - of atom probe research. Against static and dynamic quantities are splitted to avoid a duplication - of information. Specifically, the time interval considered is the entire time - starting at start_time until end_time during which we assume the pulser triggered named pulses. - These pulses are identified via the pulse_identifier field. The point in time when each was issued - is specified via the combination of start_time and delta_time. - - Conceptually and technically NeXus currently stores tensorial information as arrays of values - (with each value of the same datatype). For instance, a field temperature(NX_FLOAT) stores - a set of temperature values but that field when used somewhere is a concept. However, that - concept has no information at which point in time these temperatures were taken. - An existent functional relationship between the two concepts is not defined. - - However, a correct interpretation of the temperature values demands knowledge about what is - the independent quantity on which temperature depends on or according to which frequency - temperature values were sampled. - In NeXus there are two approaches which cope with such correlations: - One is :ref:`NXdata` where the attribute signal specifies the correlation. - The other one is :ref:`NXlog` which, like NXdata, demands to granularize logged_against - (dependent signal) and independent quantities into an own group. - In many cases this additional grouping is not desired though. - - One naive solution typically employed is then to store the independent variable values via a second - vector e.g. time_stamp with the same number of entries (with dimensionality defined through symbols). - However, there is no independent logical connection between these two concepts, i.e. temperature - and time_stamp. - - In the case of atom probe though the time that one would use in NXlog is defined implicitly via pulse_identifier, - which is the independent variable vector against which eventually dozens of channels of data are logged. - Not only are these channels logged they should ideally also be self-descriptive in that these channels have - pulse_identifier as the independent variable but we do not wish to duplicate this information all the time but - reference it. - - Therefore, we here explore the use of an attribute with symbol logged_against. Maybe it is better to use the - symbol depends_on but this is easily to be confused with depends_on that is used for instances of - :ref:`NXtransformations`. Consequently, if depends_on were to be used extra logic is needed by consuming - applications to understand that the here build correlations are conceptually different ones. - - This issue should be discussed further by the NeXus community. - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval started. If the user wishes to specify an - interval of time that the snapshot should represent during which the instrument - was stable and configured using specific settings and calibrations, - the start_time is the start (left bound of the time interval) while - the end_time specifies the end (right bound) of the time interval. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval ended. - - - - - Delta time array which resolves for each pulse_identifier the time difference - between when that pulse was issued and start_time. - - In summary, using start_time, end_time, delta_time, pulse_identifier_offset, - and pulse_identifier exactly specifies the connection between when a pulse was - issued relative to start and absolute in UTC. - - - - - - - - Integer used to name the first pulse to know if there is an - offset of the identifiers to zero. - - Identifiers can be defined either implicitly or explicitly. - For implicit indexing identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. - - Therefore, implicit identifier are completely defined by the value of - identifier_offset and cardinality. For example if identifier run from - -2 to 3 the value for identifier_offset is -2. - - For explicit indexing the field identifier has to be used. - Fortran-/Matlab- and C-/Python-style indexing have specific implicit - identifier conventions where identifier_offset is 1 and 0 respectively. - - - - - Identifier that contextualizes how the detector and pulser of an atom probe - instrument follows a sequence of pulses to trigger field evaporation. - - The pulse_identifier is used to associate thus an information about time - when the quantities documented in this NXpulser_apm base class have been - collected via sampling. - - In virtually all cases the pulser is a blackbox. Depending on how the - instrument is configured during a measurement the target - values and thus also the actual values may change. - - Maybe the first part of the experiment is run at a certain pulse fraction but thereafter - the pulse_fraction is changed. In this case the field pulse_fraction is a vector which - collects all measured values of the pulse_fraction, pulse_identifier is then an equally - long vector which stores the set of events (e.g. pulsing events) when that value was - measured. - - This may cause several situations: In the case that e.g. the pulse_fraction is never changed - and also exact details not interesting, one stores the set value for the pulse_fraction - and a single value for the pulse_identifier e.g. 0 to indicate that the pulse_fraction was set - at the beginning and it was maintained constant during the measurement. - If the pulse_fraction was maybe changed after the 100000th pulse, pulse_fraction is a - vector with two values one for the first and another one for the value from the 100000-th - pulse onwards. The values of pulse_identifier are then [0, 99999] respectively. - - - - - - - - (Meta)data of the dynamics and changes of the microscope over the course of - pulsing. - - - - Relevant quantities during a measurement with a LEAP system as suggested by - `T. Blum et al. <https://doi.org/10.1002/9781119227250.ch18>`_. - - - - - - - - - - - - - - Amplitude of the signal detected on the multi-channel plate (MCP). - - This field should be used for storing the signal amplitude quantity - within ATO files. The ATO file format is used primarily by the - atom probe groups of the GPM in Rouen, France. - - - - - - - - - - - - Set point temperature to achieve during the measurement. - - - - - Average temperature (at the specimen base) during the measurement. - - - - - - The best estimate, at experiment time, for the temperature at the - sample base (furthest point along sample apex and holding assembly - that is removable from the sample stage). - - - - - - - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - - - - - - - - Average pressure in the analysis chamber during the measurement. - - - - - Pressure in the analysis chamber. - - - - - - - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - - - - - - - - Pressure in the analysis chamber. - - - - - - - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - - - - - - - - Pressure in the analysis chamber. - - - - - - - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - - - - - - - diff --git a/base_classes/NXevent_data_apm_set.nxdl.xml b/base_classes/NXevent_data_apm_set.nxdl.xml deleted file mode 100644 index 96670759b5..0000000000 --- a/base_classes/NXevent_data_apm_set.nxdl.xml +++ /dev/null @@ -1,48 +0,0 @@ - - - - - - Base class for a set of :ref:`NXevent_data_apm` instances. - - Members of the set are instances of :ref:`NXevent_data_apm`. - These have an associated time interval during which the conditions - of the instrument were considered stable and fit enough for purpose. - - Which temporal granularity is adequate depends on the situation and research - question. Using a model which enables a collection of events offers the most - flexible way to cater for both atom probe experiments or simulation. - - To monitor the course of an ion extraction experiment (or simulation) - it makes sense to track time explicitly via time stamps or implicitly - via e.g. a clock inside the instrument, such as the clock of the pulser - and respective pulsing event identifier. - - As set and measured quantities typically change over time and we do not - yet know during the measurement which of the events have associated - (molecular) ions that will end up in the reconstructed volume, we must not - document quantities as a function of the evaporated_identifier but as a - function of the (pulsing) event_identifier. - - - diff --git a/base_classes/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml deleted file mode 100644 index 336d796a74..0000000000 --- a/base_classes/NXevent_data_em.nxdl.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - Base class to store state and (meta)data of events with an electron microscopy. - - Electron microscopes are dynamic. Scientists often report that microscopes - *perform differently* across sessions, that they perform differently from - one day or another. In some cases, root causes for performance differences - are unclear. Users of the instrument may consider such conditions impractical, - or *too poor*, and thus abort their session. Alternatively, users may try to - bring the microscope into a state where conditions are considered better - or of whatever high enough quality for continuing the measurement. - - In all these use cases in practice it would be useful to have a mechanism - whereby time-dependent data of the instrument state can be stored and - documented with an interoperable representation. Indeed, how a session on an - electron microscope is spent depends strongly on the research question, - the user, and the imaging modalities used. - - :ref:`NXevent_data_em` represents an instance to describe and serialize flexibly - whatever is considered a time interval during which the instrument is - considered as stable enough for performing a task with the microscope. - Examples of such tasks are the collecting of data (images and spectra) or - the calibrating of some component of the instrument. Users may wish to take - only a single scan or image and complete their microscope session thereafter. - Alternatively, users are working for much longer time at the microscope, - perform recalibrations in between and take several scans (of different - regions-of-interest of the specimen), or they explore the state of the - microscope for service or maintenance tasks. - - :ref:`NXevent_data_em` serves the harmonization and documentation of this situation - with providing three key sections: Firstly, there is a header section whose - purpose is to contextualize and identify the event instance in time. - Secondly, there is a data and metadata section where individual data collections - can be stored using a standardized representation. - - The idea of the first, the event-based em_lab section, is to document the - state of the microscope as it was during the event. The idea of the other, - the NXem application based em_lab(NXinstrument) section is to keep all those - pieces of information which are static in the sense that they are the same - across multiple :ref:`NXevent_data_em` instance. This reduces the amount of pieces of - information that have to be stored repetitively. - - We are aware of the fact that given the variety how an electron microscope - is used, there is a need for a flexible and adaptive documentation system. - At the same time we are also convinced though that just because one has - different requirements for some specific aspect under the umbrella of settings - to an electron microscope, this does not necessarily warrant that one has to - cook up an own schema. - - Instead, the electron microscopy community should work towards reusing schema - components as frequently as possible. This will enable that there is at all - not only a value of harmonizing electron microscopy research content but also - the technical possibility to build services around such harmonized - pieces of information. - - Arguably it is oftentimes tricky to specify a clear time interval when the - microscope is *stable enough*. Take for instance the acquisition of an image - or a stack of spectra. Having to deal with instabilities is a common theme in - electron microscopy practice. Numerical protocols can be used during data - post-processing to correct for some of the instabilities. - A few exemplar references to provide an overview on the subject is - available in the literature: - - * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ - * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ - * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ - - For specific simulation purposes, mainly in an effort to digitally repeat - or simulate the experiment, it is tempting to consider dynamics of the instrument, - implemented as time-dependent functional descriptions of e.g. lens excitations, - beam shape functions, trajectories of groups of electrons and ions, - or detector noise models. This warrants to document the time-dependent - details of individual components of the microscope - as is implemented in :ref:`NXevent_data_em`. - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval started. If the user wishes to specify an - interval of time that the snapshot should represent during which the instrument - was stable and configured using specific settings and calibrations, - the start_time is the start (left bound of the time interval) while - the end_time specifies the end (right bound) of the time interval. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval ended. - - - - - Identifier of a specific state and setting of the microscope. - - - - - Which specific event/measurement type. Examples are: - - * In-lens/backscattered electron, usually has quadrants - * Secondary_electron, image, topography, fractography, overview images - * Backscattered_electron, image, Z or channeling contrast (ECCI) - * Bright_field, image, TEM - * Dark_field, image, crystal defects - * Annular dark field, image (medium- or high-angle), TEM - * Diffraction, image, TEM, or a comparable technique in the SEM - * Kikuchi, image, SEM EBSD and TEM diffraction - * X-ray spectra (point, line, surface, volume), composition EDS/EDX(S) - * Electron energy loss spectra for points, lines, surfaces, TEM - * Auger, spectrum, (low Z contrast element composition) - * Cathodoluminescence (optical spectra) - * Ronchigram, image, alignment utility specifically in TEM - * Chamber, e.g. TV camera inside the chamber, education purposes. - - This field may also be used for storing additional information - about the event. For which there is at the moment no other place. - - In the long run such free-text field description should be avoided as - they are difficult to machine-interpret. Instead, reference should be given - to refactoring these descriptions into structured metadata. - The reason why in this base class the field event_type is nonetheless kept - is to offer a place whereby practically users may enter data for - follow-up modifications to support arriving at an improved :ref:`NXevent_data_em` base class. - - - - - - - (Meta)data of the dynamics and changes of the microscope during the event. - - - - - - - - - - - - - - diff --git a/base_classes/NXevent_data_em_set.nxdl.xml b/base_classes/NXevent_data_em_set.nxdl.xml deleted file mode 100644 index f4901106ac..0000000000 --- a/base_classes/NXevent_data_em_set.nxdl.xml +++ /dev/null @@ -1,49 +0,0 @@ - - - - - - Base class for a set of :ref:`NXevent_data_em` instances. - - Members of the set are instances of :ref:`NXevent_data_em`. These have an associated - time interval during which the conditions were considered stable and - fit enough for purpose. - - Which temporal granularity is adequate depends on the situation and - research question. Using a model which enables a collection of events offers - the most flexible way to cater for both experiments with controlled electron - beams in a real microscope or the simulation of such experiments or - individual aspects of such experiments. - - - - - diff --git a/base_classes/NXfabrication.nxdl.xml b/base_classes/NXfabrication.nxdl.xml deleted file mode 100644 index 76f48e3b84..0000000000 --- a/base_classes/NXfabrication.nxdl.xml +++ /dev/null @@ -1,70 +0,0 @@ - - - - - - Details about a component as it is defined by its manufacturer. - - - - Company name of the manufacturer. - - - - - Version or model of the component named by the manufacturer. - - - - If different versions exist are possible, the value in this field should be made - specific enough to resolve the version. - - - - - - Ideally, (globally) unique persistent identifier. This may contain e.g. a hash - identifier of the component. - - - - - Serial number of the component. - - - - - Datetime of components initial construction. This refers to the date of - first measurement after new construction or to the relocation date, - if it describes a multicomponent/custom-build setup. - Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, - otherwise the local time zone is assumed per ISO8601. - - - - - Free-text list with eventually multiple terms of - functionalities which the component offers. - - - diff --git a/base_classes/NXfit.nxdl.xml b/base_classes/NXfit.nxdl.xml deleted file mode 100644 index b0d77f2cec..0000000000 --- a/base_classes/NXfit.nxdl.xml +++ /dev/null @@ -1,199 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Rank of the dependent and independent data arrays (for - multidimensional/multivariate fit.) - - - - - Description of a fit procedure. - - - - Human-readable label for this fit procedure. - - - - - Input data and results of the fit. - - - - Position values along one or more data dimensions (to hold the - values for the independent variable for this fit procedure). - - - - The ``input_dependent`` field must have the same rank (``dimRank``) - as the ``input_independent`` field. Each individual dimension of ``input_dependent`` - must have the same number of points as the corresponding dimension in - the ``input_independent`` field. - - - - - - Independent input axis for this fit procedure. - - - - The ``input_independent`` field must have the same rank (``dimRank``) - as the ``input_dependent`` field. Each individual dimension of ``input_independent`` - must have the same number of points as the corresponding dimension in - the ``input_dependent`` field. - - - - - - Resulting envelope of applying the `global_fit_function` with its parameter to the data stored - in `input_independent`. - - - - The ``envelope`` field must have the same rank (``dimRank``) - as the ``input_independent`` field. Each individual dimension of ``envelope`` - must have the same number of points as the corresponding dimension in - the ``input_independent`` field. - - - - - - Difference between the envelope and the `input_independent` data to be fitted. - - - - The ``residual`` field must have the same rank (``dimRank``) - as the ``input_independent`` field. Each individual dimension of ``residual`` - must have the same number of points as the corresponding dimension in - the ``input_independent`` field. - - - - - - - One peak of the peak model. - If there is no characteristic name for each peak component, is envisioned that peaks - are labeled as peak_0, peak_1, and so on. - - - - Total area under the curve (can also be used for the total area minus any - background values). - - - - - Relative sensitivity for this peak, to be used for quantification in - an NXprocess. - - As an example, in X-ray spectroscopy could depend on the energy scale - (see position), the ionization cross section, and the element probed. - - - - - Relative area of this peak compared to other peaks. - - The relative area can simply be derived by dividing the total_area by the - total area of all peaks or by a more complicated method (e.g., by - additionally dividing by the relative sensitivity factors). Details shall - be given in `global_fit_function`. - - - - - - One fitted background (functional form, position, and intensities) of the peak fit. - If there is no characteristic name for each peak component, it is envisioned that backgrounds are labeled - as background_0, background_1, and so on. - - - - - Function used to describe the overall fit to the data, taking into account the parameters of the - individual `NXpeak` and `NXfit_background` components. - - - - Oftentimes, if the peaks and fit backgrounds are defined independently (i.e, with their own - parameter sets), the resulting global fit is a function of the form - :math:`model = peak_1(p_1) + peak2(p_2) + backgr(p_3).`, where each :math:`p_x` describes the - set of parameters for one peak/background. - - - - - - Function used to optimize the parameters during peak fitting. - - - - Description of the method used to optimize the parameters during peak fitting. - Examples: - - least squares - - non-linear least squares - - Levenberg-Marquardt algorithm (damped least-squares) - - linear regression - - Bayesian linear regression - - - - - For the optimization, the formula is any optimization process on the `global_fit_function` given above. - As an example, for a linear least squared algorithm on independent components, the formula of the error_function - would be :math:`LLS(peak_1(p_1) + peak2(p_2) + backgr(p_3))`, where each :math:`p_x` describes the set - of parameters for one peak/background. - - It is however also possible to supply more involved formulas (e.g., in the case of constrained fits). - - - - - - Figure-of-merit to determine the goodness of fit, i.e., how well the peak model - fits the measured observations. - - This value (which is a single number) is oftenused to guide adjustments to the - fitting parameters in the peak fitting process. - - - - Metric used to determine the goodness of fit. Examples include: - - :math:`\chi^2`, the squared sum of the sigma-weighted residuals - - reduced :math:`\chi^2`:, :math:`\chi^2`: per degree of freedom - - :math:`R^2`, the coefficient of determination - - - - diff --git a/base_classes/NXfit_background.nxdl.xml b/base_classes/NXfit_background.nxdl.xml deleted file mode 100644 index 5b45fa81e4..0000000000 --- a/base_classes/NXfit_background.nxdl.xml +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Rank of the dependent and independent data arrays (for - multidimensional/multivariate fit.) - - - - - Description of the background for an NXfit model. - - - - Human-readable label which specifies which concept/entity - the background represents/identifies. - - - - - - Position values along one or more data dimensions (to hold the - values for the independent variable). - - - - The ``position`` field must have the same rank (``dimRank``) - as the ``intensity`` field. Each individual dimension of ``position`` - must have the same number of points as the corresponding dimension in - the ``intensity`` field. - - - - - - This array holds the intensity/count values of the fitted background - at each position. - - - - The ``intensity`` field must have the same rank (``dimRank``) - as the ``intensity`` field. Each individual dimension of ``position`` - must have the same number of points as the corresponding dimension in - the ``position`` field. - - - - - - - The functional form of the background. - - - diff --git a/base_classes/NXfit_function.nxdl.xml b/base_classes/NXfit_function.nxdl.xml deleted file mode 100644 index d24de7bd97..0000000000 --- a/base_classes/NXfit_function.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - This describes a fit function that is used to fit data to any functional form. - - A fit function is used to describe a set of data :math:`y_k, k = 1 ... M`, which are collected as a function - of one or more independent variables :math:`x` at the points :math:`x_k`. The fit function :math:`f` describes - these data in an approximative way as :math:`y_k \approx f(a_0, . . . a_n, x_k)`, - where :math:`a_i, i = 0 . . . n` are the *fit parameters* (which are stored the instances of ``NXfit_parameter``). - - - - Human-readable description of this fit function. - - - - - Mathematical formula of the function, taking into account the instances of ``NXfit_parameter``. - - This should be a python parsable function. Here we should provide which keywords are available - and a BNF of valid grammar. - - - - diff --git a/base_classes/NXhistory.nxdl.xml b/base_classes/NXhistory.nxdl.xml deleted file mode 100644 index 9dfa25d722..0000000000 --- a/base_classes/NXhistory.nxdl.xml +++ /dev/null @@ -1,74 +0,0 @@ - - - - - - A set of activities that occurred to a physical entity prior/during experiment. - - Ideally, a full report of the previous operations (or links to a chain of operations). - Alternatively, notes allow for additional descriptors in any format. - - - - Any activity that was performed on the physical entity prior or during the experiment. In - the future, if there is base class inheritance, this can describe any activity, - including processes and measurements. - - - - - - Any physical process that was performed on the physical entity prior or during the - experiment. - - - - - Any chemical process that was performed on the physical entity prior or during the - experiment. - - - - - An ID or reference to the location or a unique (globally - persistent) identifier of e.g. another file which gives - as many as possible details of the history event. - - - - - - A descriptor to keep track of the treatment of the physical entity before or during the - experiment (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - This should only be used in case that there is no rigorous description - using the base classes above. This field can also be used to pull in any activities - that are not well described by an existing base class definition. - - - diff --git a/base_classes/NXimage_set.nxdl.xml b/base_classes/NXimage_set.nxdl.xml deleted file mode 100644 index 9106ef84f2..0000000000 --- a/base_classes/NXimage_set.nxdl.xml +++ /dev/null @@ -1,652 +0,0 @@ - - - - - - - - - - Number of images in the stack, for stacks the slowest dimension. - - - - - Number of image points along the slow dimension (k equivalent to z). - - - - - Number of image points along the fast dimension (j equivalent to y). - - - - - Number of image points along the fastest dimension (i equivalent to x). - - - - - Base class for reporting a set of images. - - The mostly commonly used scanning methods are supported. That is one-, - two-, three-dimensional ROIs discretized using regular Euclidean tilings. - - Colloquially, an image is understood as a discretized representation of intensity distribution - that was detected or simulated for some ROI. When discretized with regular Euclidean tilings - the terms pixel and voxel identify the smallest discretization unit. Pixel and voxel are polygonal - or polyhedral unit cells respectively of the underlying tiling of the ROI within the reference space. - For all other tilings e.g. non-equispaced, the shape and size of pixel and voxel differs. Using the term - (image) point is eventually is more appropriate for such tilings. Therefore, all docstrings in this base class - refer to points (including pixel and voxel i.e. regular tilings). - - Point coordinates identify the location of the barycentre. - - For images in reciprocal space in practice, complex numbers are encoded via some - formatted pair of real values. Typically, fast algorithms for computing Fourier transformations - (FFT) are used to encode images in reciprocal (frequency) space. FFT libraries are used - for implementing the key functionalities of these mathematical operations. - - Different libraries use different representations and encoding of the images. - Details can be found in the respective sections of the typical FFT libraries documentations - - * `FFTW by M. Frigo and S. G. Johnson <https://www.fftw.org/fftw3_doc/Tutorial.html#Tutorial>`_ - * `Intel MKL by the Intel Co. <https://www.intel.com/content/www/us/en/docs/onemkl/developer-reference-c/2024-2/fourier-transform-functions.html>`_ - * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ - * `NFFT by the Chemnitz group <https://www-user.tu-chemnitz.de/~potts/nfft/>`_ for non-equispaced computations - - Users are strongly advised to inspect carefully which specific conventions their library uses - to enable storing and modifying the implementation of their code such that the serialized - representations as they are detailed here for NeXus match. - - It is often the case that several images are combined using processing. In this case, - the number of images which are combined in a collection is not necessarily the same - for each collection. The NXimage_set base class addresses this logical distinction - through the notation of image_identifier and group_identifier concepts. - That is image_identifier are always counting from offset in increments of one. - as each image is its own entity. By contrast, a group may contain no, or several images. - Consequently, group_identifier are not required to be contiguous. - - - - Details how NXdata instance were processed from detector readings/raw data. - - - - Resolvable data artifact (e.g. file) from which all values in the :ref:`NXdata` - instances in this :ref:`NXimage_set` were loaded during parsing. - - Possibility to document from which specific other serialized resource as the source - pieces of information were processed when using NeXus as a semantic file format - to serialize that information differently. - - The group in combination with an added field *absolute_path* therein adds context. - - - - Reference to a location inside the artifact that points to the specific group of values - that were processed if the artifacts contains several groups of values and thus - further resolving of ambiguities is required. - - - - - - - Link or name of an :ref:`NXdetector` instance with which the data were - collected. - - - - - Program used for processing. - - - - - - - One-dimensional image. - - - - Intensity for real-valued images as an alternative for real. - Magnitude of the image intensity for complex-valued data. - - - - - - - - Real part of the image intensity per point. - - - - - - - - Imaginary part of the image intensity per point. - - - - - - - - Image intensity as a complex number as an alternative to real and - imaginary fields if values are stored as interleaved complex numbers. - - - - - - - - Point coordinate along the fastest dimension. - - - - - - - Point coordinate along the fastest dimension. - - - - - - - Two-dimensional image. - - - - Intensity for real-valued images as an alternative for real. - Magnitude of the image intensity for complex-valued data. - - - - - - - - - Real part of the image intensity per point. - - - - - - - - - Imaginary part of the image intensity per point. - - - - - - - - - Image intensity as a complex number as an alternative to real and - imaginary fields if values are stored as interleaved complex numbers. - - - - - - - - - Point coordinate along the fast dimension. - - - - - - - Point coordinate along the fast dimension. - - - - - - Point coordinate along the fastest dimension. - - - - - - - Point coordinate along the fastest dimension. - - - - - - - Three-dimensional image. - - - - Intensity for real-valued images as an alternative for real. - Magnitude of the image intensity for complex-valued data. - - - - - - - - - - Real part of the image intensity per point. - - - - - - - - - - Imaginary part of the image intensity per point. - - - - - - - - - - Image intensity as a complex number as an alternative to real and - imaginary fields if values are stored as interleaved complex numbers. - - - - - - - - - - Point coordinate along the slow dimension. - - - - - - - Point coordinate along the slow dimension. - - - - - - Point coordinate along the fast dimension. - - - - - - - Point coordinate along the fast dimension. - - - - - - Point coordinate along the fastest dimension. - - - - - - - Point coordinate along the fastest dimension. - - - - - - - Collection of image_1d. - - - - Intensity for real-valued images as an alternative for real. - Magnitude of the image intensity for complex-valued data. - - - - - - - - - Real part of the image intensity per point. - - - - - - - - - Imaginary part of the image intensity per point. - - - - - - - - - Image intensity as a complex number as an alternative to real and - imaginary fields if values are stored as interleaved complex numbers. - - - - - - - - - Group identifier - - - - - - - Group identifier - - - - - - Image identifier - - - - - - - Image identifier - - - - - - Point coordinate along the fastest dimension. - - - - - - - Point coordinate along the fastest dimension. - - - - - - - Collection of two-dimensional images. - - - - Intensity for real-valued images as an alternative for real. - Magnitude of the image intensity for complex-valued data. - - - - - - - - - - Real part of the image intensity per point. - - - - - - - - - - Imaginary part of the image intensity per point. - - - - - - - - - - Image intensity as a complex number as an alternative to real and - imaginary fields if values are stored as interleaved complex numbers. - - - - - - - - - - Group identifier - - - - - - - Group identifier - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Point coordinate along the fast dimension. - - - - - - - Point coordinate along the fast dimension. - - - - - - Point coordinate along the fastest dimension. - - - - - - - Point coordinate along the fastest dimension. - - - - - - - Collection of three-dimensional images. - - - - Intensity for real-valued images as an alternative for real. - Magnitude of the image intensity for complex-valued data. - - - - - - - - - - - Real part of the image intensity per point. - - - - - - - - - - - Imaginary part of the image intensity per point. - - - - - - - - - - - Image intensity as a complex number as an alternative to real and - imaginary fields if values are stored as interleaved complex numbers. - - - - - - - - - - - Group identifier - - - - - - - Group identifier - - - - - - Image identifier - - - - - - - Image identifier - - - - - - Point coordinate along the slow dimension. - - - - - - - Point coordinate along the slow dimension. - - - - - - Point coordinate along the fast dimension. - - - - - - - Point coordinate along the fast dimension. - - - - - - Point coordinate along the fastest dimension. - - - - - - - Point coordinate along the fastest dimension. - - - - - diff --git a/base_classes/NXinstrument.nxdl.xml b/base_classes/NXinstrument.nxdl.xml index 197163ff38..15e7645403 100644 --- a/base_classes/NXinstrument.nxdl.xml +++ b/base_classes/NXinstrument.nxdl.xml @@ -42,7 +42,6 @@ short name for instrument, perhaps the acronym - @@ -56,20 +55,16 @@ - - - - diff --git a/base_classes/NXinteraction_vol_em.nxdl.xml b/base_classes/NXinteraction_vol_em.nxdl.xml deleted file mode 100644 index f8d8a669f2..0000000000 --- a/base_classes/NXinteraction_vol_em.nxdl.xml +++ /dev/null @@ -1,57 +0,0 @@ - - - - - - Base class for describing the interaction volume of particle-matter interaction. - - Computer models like Monte Carlo or molecular dynamics / electron- or ion-beam - interaction simulations can be used to qualify and (or) quantify the shape of - the interaction volume. Results of such simulations can be summary statistics - or single-particle resolved sets of trajectories. - - Explicit or implicit descriptions are possible. - - * An implicit description is via a set of electron/specimen interactions - represented ideally as trajectory data from the computer simulation. - * An explicit description is via an iso-contour surface using either - a simulation grid or a triangulated surface mesh of the approximated - iso-contour surface evaluated at specific threshold values. - Iso-contours could be computed from electron or particle fluxes through - an imaginary control surface (the iso-surface). - Threshold values can be defined by particles passing through a unit control - volume (electrons) or energy-levels (e.g. the case of X-rays). - Details depend on the model. - * Another explicit description is via theoretical models which may - be relevant e.g. for X-ray spectroscopy - - Further details on how the interaction volume can be quantified - is available in the literature for example: - - * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ - * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ - * `J. F. Ziegler et al. <https://doi.org/10.1007/978-3-642-68779-2_5>`_ - - - - diff --git a/base_classes/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml deleted file mode 100644 index ee278ead9e..0000000000 --- a/base_classes/NXion.nxdl.xml +++ /dev/null @@ -1,158 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). - - - - - Number of mass-to-charge-state-ratio range intervals for ion type. - - - - - Base class for documenting the set of atoms of a (molecular) ion. - - - - A unique identifier whereby such an ion can be referred to - via the service offered as described in identifier_type. - - - - - How can the identifier be resolved? - - - - - - - - Ion type (ion species) identifier. - - The identifier zero is reserved for the special unknown ion type. - - - - - Vector of nuclide hash values. - - Individual hash values :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` - encode the number of protons :math:`Z` and the number of neutrons :math:`N` - of each nuclide respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. - - The array is sorted in decreasing order. For the rationale behind this see `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - Table which decodes the entries in nuclide_hash into a human-readable matrix of instances. - The first column specifies the nuclide mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N` or 0. The value 0 documents that no - isotope-specific information about the element encoded is relevant. - The second row specifies the number of protons :math:`Z` or 0. - The value 0 in this case documents a placeholder or that no element-specific - information is relevant. - Taking a carbon-14 nuclide as an example the mass number is 14. - That is encoded as a value pair (14, 6) as one row of the table. - - Therefore, this notation is the typical superscribed nuclide mass number - and subscripted number of protons element notation e.g. :math:`^{14}C`. - The array is stored matching the order of nuclide_hash. - - - - - - - - - - Assumed volume of the ion. - - In atom probe microscopy this field can be used to store the reconstructed - volume per ion (average) which is typically stored alongside ranging - definitions. - - - - - Charge of the ion. - - - - - Signed charge state of the ion in multiples of electron charge. - - In the example of atom probe microscopy, only positive values will be measured - as the ions are accelerated by a negatively signed bias electric field. - In the case that the charge state is not explicitly recoverable, the value should - be set to zero. - - In atom probe microscopy this is for example the case when using - classical ranging definition files in formats like RNG, RRNG. - These file formats do not document the charge state explicitly - but the number of atoms of each element per molecular ion - surplus the mass-to-charge-state-ratio interval. - Details on ranging definition files can be found in the literature: - `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - - - - - Human-readable ion type name (e.g. Al +++) - The string should consists of UTF-8 characters, ideally using LaTeX - notation to specify the isotopes, ions, and charge state. - Examples are 12C + or Al +++. - - To ease automated parsing, isotope_vector should be the - preferred machine-readable information used. - - - - - Associated lower (mqmin) and upper (mqmax) bounds of the - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries inclusive). This field is primarily of interest - for documenting :ref:`NXprocess` steps of indexing a - ToF/mass-to-charge state histogram. - - - - - - - diff --git a/base_classes/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml deleted file mode 100644 index e878d25e35..0000000000 --- a/base_classes/NXlens_em.nxdl.xml +++ /dev/null @@ -1,96 +0,0 @@ - - - - - - - - Base class for an electro-magnetic lens or a compound lens. - - For :ref:`NXtransformations` the origin of the coordinate system is placed - in the center of the lens (its polepiece, pinhole, or another - point of reference). The origin should be specified in the :ref:`NXtransformations`. - - For details of electro-magnetic lenses in the literature - see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ - - - - - Descriptor for the lens excitation when the exact technical details - are unknown or not directly controllable as the control software of - the microscope does not enable or was not configured to display these - values (for end users). - - Although this value does not document the exact physical voltage or - excitation, it can still give useful context to reproduce the lens - setting, provided a properly working instrument and software sets the lens - into a similar state to the technical level possible when no more - information is available physically or accessible legally. - - - - - Descriptor for the operation mode of the lens when other details are not - directly controllable as the control software of the microscope - does not enable or is not configured to display these values. - - Like value, the mode can only be interpreted for a specific microscope - but can still be useful to guide users as to how to repeat the measurement. - - - - - - Excitation voltage of the lens. - - For dipoles it is a single number. - For higher order multipoles, it is an array. - - - - - Excitation current of the lens. - - For dipoles it is a single number. - For higher-order multipoles, it is an array. - - - - - - Qualitative type of lens with respect to the number of pole pieces. - - - - - - - - - - - diff --git a/base_classes/NXmanipulator.nxdl.xml b/base_classes/NXmanipulator.nxdl.xml deleted file mode 100644 index a057a167df..0000000000 --- a/base_classes/NXmanipulator.nxdl.xml +++ /dev/null @@ -1,257 +0,0 @@ - - - - - - Extension of NXpositioner to include fields to describe the use of manipulators - in photoemission experiments. - - - - Name of the manipulator. - - - - - A description of the manipulator. - - - - - Type of manipulator, Hexapod, Rod, etc. - - - - - Cryostat for cooling the sample. - - - - - - - - - - In case of a fixed or averaged cooling temperature, this is the scalar temperature setpoint. - It can also be a 1D array of temperature setpoints (without time stamps). - - - - - - In the case of an experiment in which the temperature is changed and the setpoints are - recorded with time stamps, this is an array of length m of temperature setpoints. - - - - - - - - Temperature sensor measuring the sample temperature. - - - - - - - - - In case of a single or averaged temperature measurement, this is the scalar temperature measured - by the sample temperature sensor. It can also be a 1D array of measured temperatures - (without time stamps). - - - - - - In the case of an experiment in which the temperature changes and is recorded with time stamps, - this is an array of length m of temperatures. - - - - - - - Device to heat the sample. - - - - - - - - - In case of a fixed or averaged heating power, this is the scalar heater power. - It can also be a 1D array of heater powers (without time stamps). - - - - - - In the case of an experiment in which the heater power is changed and recorded with time stamps, - this is an array of length m of temperature setpoints. - - - - - - - In case of a fixed or averaged temperature, this is the scalar temperature setpoint. - It can also be a 1D array of temperature setpoints (without time stamps). - - - - - - In the case of an experiment in which the temperature is changed and the setpoints are - recorded with time stamps, this is an array of length m of temperature setpoints. - - - - - - - - Amperemeter measuring the drain current of the sample and sample holder. - - - - - - - - - In case of a single or averaged drain current measurement, this is the scalar drain current measured between - the sample and sample holder. It can also be an 1D array of measured currents (without time stamps). - - - - - - In the case of an experiment in which the current changes and is recorded with - time stamps, this is an array of length m of currents. - - - - - - - Actuator applying a voltage to sample and sample holder. - - - - - - - - - - In case of a fixed or averaged applied bias, this is the scalar voltage applied between - sample and sample holder. It can also be an 1D array of voltage setpoints (without time stamps). - - - - - - In the case of an experiment in which the bias is changed and the setpoints are - recorded with time stamps, this is an array of length m of voltage setpoints. - - - - - - - - Sensor measuring the voltage applied to sample and sample holder. - - - - - - - - - In case of a single or averaged bias measurement, this is the scalar voltage measured between - sample and sample holder. It can also be an 1D array of measured voltages (without time stamps). - - - - - - In the case of an experiment in which the bias changes and is recorded with - time stamps, this is an array of length m of voltages. - - - - - - - Any additional actuator on the manipulator used to control an external - condition. - - - - - Any additional sensors on the manipulator used to monitor an external condition. - - - - - Class to describe the motors that are used in the manipulator - - - - - Refers to the last transformation specifying the positon of the manipulator in - the NXtransformations chain. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the manipulator as a component in the instrument. Conventions from - the NXtransformations base class are used. In principle, the McStas coordinate - system is used. The first transformation has to point either to another - component of the system or . (for pointing to the reference frame) to relate it - relative to the experimental setup. Typically, the components of a system should - all be related relative to each other and only one component should relate to - the reference coordinate system. - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - - diff --git a/base_classes/NXmonochromator.nxdl.xml b/base_classes/NXmonochromator.nxdl.xml index dd96e3a26c..50a83cd93d 100644 --- a/base_classes/NXmonochromator.nxdl.xml +++ b/base_classes/NXmonochromator.nxdl.xml @@ -60,26 +60,6 @@ energy standard deviation - - - Energy dispersion at the exit slit, typically given as eV/mm. - - - - - Wavelength dispersion at the exit slit. - - - - - Size, position and shape of the entrance slit of the monochromator. - - - - - Size, position and shape of the exit slit of the monochromator. - - @@ -125,3 +105,4 @@ + diff --git a/base_classes/NXopt_window.nxdl.xml b/base_classes/NXopt_window.nxdl.xml deleted file mode 100644 index f1fc90e670..0000000000 --- a/base_classes/NXopt_window.nxdl.xml +++ /dev/null @@ -1,128 +0,0 @@ - - - - - - - A window of a cryostat, heater, vacuum chamber or a simple glass slide. - - This first verion originates from NXopt to describe cryostate windows - and possible influences for ellipsometry measurements. - - For environmental measurements, the environment (liquid, vapor - etc.) is enclosed in a cell, which has windows both in the - direction of the source (entry window) and the detector (exit - window) (looking from the sample). In case that the entry and exit - windows are not the same type and do not have the same properties, - use a second 'WINDOW(NXaperture)' field. - - The windows also add a phase shift to the light altering the - measured signal. This shift has to be corrected based on measuring - a known sample (reference sample) or the actual sample of interest - in the environmental cell. State if a window correction has been - performed in 'window_effects_corrected'. Reference data should be - considered as a separate experiment, and a link to the NeXus file - should be added in reference_data_link in measured_data. - - The window is considered to be a part of the sample stage but also - beam path. Hence, its position within the beam path should be - defined by the 'depends_on' field. - - - - - Was a window correction performed? If 'True' describe the window - correction procedure in 'window_correction/procedure'. - - - - - Type of effects due to this window on the measurement. - - - - - - - - - - - Was a window correction performed? If 'True' describe the - window correction procedure in '' - - - - Describe when (before or after the main measurement + time - stamp in 'date') and how the window effects have been - corrected, i.e. either mathematically or by performing a - reference measurement. In the latter case, provide the link to - to the reference data in 'reference_data_link'. - - - - - Link to the NeXus file which describes the reference data if a - reference measurement for window correction was performed. - Ideally, the reference measurement was performed on a reference - sample and on the same sample, and using the same conditions as - for the actual measurement with and without windows. It should - have been conducted as close in time to the actual measurement - as possible. - - - - - - The material of the window. - - - - - - - - - - - - - - - If you specified 'other' as material, decsribe here what it is. - - - - - Thickness of the window. - - - - - Angle of the window normal (outer) vs. the substrate normal - (similar to the angle of incidence). - - - - diff --git a/base_classes/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml deleted file mode 100644 index b0546c8c77..0000000000 --- a/base_classes/NXoptical_system_em.nxdl.xml +++ /dev/null @@ -1,155 +0,0 @@ - - - - - - A container for qualifying an electron optical system. - - - - - Distance which is present between the specimen surface and the detector plane. - - This concept is related to term `Camera Length`_ of the EMglossary standard. - - .. _Camera Length: https://purls.helmholtz-metadaten.de/emg/EMG_00000008 - - - - - The factor of enlargement of the apparent size, - not the physical size, of an object. - - - - - The defocus aberration constant (oftentimes referred to as C_1_0). - See respective details in :ref:`NXaberration` class instances. - - - - - The angle which is given by the semi-opening angle of the cone in a convergent - beam. - - This concept is related to term `Convergence Angle`_ of the EMglossary standard. - - .. _Convergence Angle: https://purls.helmholtz-metadaten.de/emg/EMG_00000010 - - - - - The extent of the observable parts of the specimen given the current - magnification and other settings of the instrument. - - - - - Distance which is determined along the optical axis within the column from (1) the - lower end of the final optical element between the source and the specimen stage; - to (2) the point where the beam is focused. - - This concept is related to term `Working Distance`_ of the EMglossary standard. - - .. _Working Distance: https://purls.helmholtz-metadaten.de/emg/EMG_00000050 - - - - - - Geometry of the cross-section formed when the primary beam shines onto the - specimen surface. - - - - - Electrical current which arrives at the specimen. - - This concept is related to term `Probe Current`_ of the EMglossary standard. - - .. _Probe Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000041 - - - - - - - Specify further details how incipient electron or ion dose was quantified (using - beam_current, probe_current). - - - - - - Details about an imaging setting used during acquisition to correct perspective - distortion when imaging a tilted surface or cross section. - - This concept is related to term `Tilt Correction`_ of the EMglossary standard. - - .. _Tilt Correction: https://purls.helmholtz-metadaten.de/emg/EMG_00000047 - - - - - Details about a dynamic focus correction used. - - This concept is related to term `Dynamic Focus Correction`_ of the EMglossary standard. - - .. _Dynamic Focus Correction: https://purls.helmholtz-metadaten.de/emg/EMG_00000016 - - - - - Details about a workflow used to keep the specimen in focus by automatic means. - - This concept is related to term `Dynamic Refocusing`_ of the EMglossary standard. - - .. _Dynamic Refocusing: https://purls.helmholtz-metadaten.de/emg/EMG_00000017 - - - - - Distance which lies between the principal plane of the lens and the focal point - along the optical axis. - - This concept is related to term `Focal Length`_ of the EMglossary standard. - - .. _Focal Length: https://purls.helmholtz-metadaten.de/emg/EMG_00000029 - - - diff --git a/base_classes/NXpeak.nxdl.xml b/base_classes/NXpeak.nxdl.xml deleted file mode 100644 index 86809edda6..0000000000 --- a/base_classes/NXpeak.nxdl.xml +++ /dev/null @@ -1,86 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Rank of the dependent and independent data arrays (for - multidimensional/multivariate fit.) - - - - - Base class for describing a peak, its functional form, and support values - (i.e., the discretization (points) at which the function has been evaluated). - - - - Human-readable label which specifies which concept/entity - the peak represents/identifies. - - - - - - Position values along one or more data dimensions (to hold the - values for the independent variable). - - - - The ``position`` field must have the same rank (``dimRank``) - as the ``intensity`` field. Each individual dimension of ``position`` - must have the same number of points as the corresponding dimension in - the ``intensity`` field. - - - - - - This array holds the intensity/count values of the fitted peak at each position. - - - - The ``intensity`` field must have the same rank (``dimRank``) - as the ``intensity`` field. Each individual dimension of ``position`` - must have the same number of points as the corresponding dimension in - the ``position`` field. - - - - - - - The functional form of the peak. This could be a Gaussian, Lorentzian, - Voigt, etc. - - - - - Total area under the curve. - - - diff --git a/base_classes/NXphysical_process.nxdl.xml b/base_classes/NXphysical_process.nxdl.xml deleted file mode 100644 index d422e516c6..0000000000 --- a/base_classes/NXphysical_process.nxdl.xml +++ /dev/null @@ -1,61 +0,0 @@ - - - - - - A planned or unplanned process which results in physical changes in a specified material. - - A physical change involve changes only in intermolecular forces, not in the chemical bonds. - Examples include sample preparation, material transformation, or (partially) destructive measurements. - - - - ISO 8601 formatted time code (with local time zone offset to UTC information - included) when this process started. - - - - - ISO 8601 formatted time code (with local time zone offset to UTC information - included) when this process ended. - - - - - Short description of the activity. - - - - - Method by which this process was performed. - - - - - This can be any data or other descriptor acquired during the physical process - (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - - - diff --git a/base_classes/NXprocess.nxdl.xml b/base_classes/NXprocess.nxdl.xml index 7a9cecd4d5..d7d1a80f84 100644 --- a/base_classes/NXprocess.nxdl.xml +++ b/base_classes/NXprocess.nxdl.xml @@ -43,21 +43,6 @@ Date and time of processing. - - - Describes the operations of image registration - - - - - Describes the operations of image distortion correction - - - - - Describes the operations of calibration procedures, e.g. axis calibrations. - - The note will contain information about how the data was processed @@ -82,3 +67,4 @@ + diff --git a/base_classes/NXprocess_mpes.nxdl.xml b/base_classes/NXprocess_mpes.nxdl.xml deleted file mode 100644 index 337d040f96..0000000000 --- a/base_classes/NXprocess_mpes.nxdl.xml +++ /dev/null @@ -1,317 +0,0 @@ - - - - - - :ref:`NXprocess_mpes` describes events of data processing, reconstruction, - or analysis for photoemission-related data. - - It extends the NXprocess class and provides a glossary of explicitly named processes - and their metadata which are typical for photoemission data. - - For now, the extension of NXprocess is performed by simply copying all existing groups, fields, - and attibute from NXprocess. In the future, it is envisioned that this extension can be solved by - base class inheritance. - - - - Name of the program used - - - - - Sequence index of processing, - for determining the order of multiple **NXprocess** steps. - Starts with 1. - - - - - Version of the program used - - - - - Date and time of processing. - - - - - Calibration event on the energy axis. - - For XPS, the calibration should ideally be performed according to - `ISO 15472:2010`_ specification. - - .. _ISO 15472:2010: https://www.iso.org/standard/74811.html - - - - - - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - Calibration event on a k-space axis. - - It is envisioned that the individual calibrations for each coordinate are - stored as kx_calibration, ky_calibration, kz_calibration, in accordance - with the axis name definitions in NXdata_mpes. - - It is also possible to have k_parallel_calibration and k_perp_calibration if - the momentum axes are defined as k_parallel and k_perp for the parallel and - perpendicular momenta, respectively. - - - - - - - - - This is the calibrated k-space axis to be used for data plotting. - - - - - - Calibration event of an angular axis. - - It is envisioned that the individual calibrations for each angle are - stored as angular0_calibration, angular1_calibration, etc., in accordance - with the axis name definitions in NXdata_mpes. - - - - - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - Calibration event of a spatial axis. - - It is envisioned that the individual calibrations for each angle are - stored as spatial0_calibration, spatial1_calibration, etc., in accordance - with the axis name definitions in NXdata_mpes. - - - - - - - - - This is the calibrated spatial axis to be used for data plotting. - - - - - - Calibration event of the delay time. - - - - - - - - - This is the calibrated delay time axis to be used for data plotting. - - - - - - Calibration event of the beam polarization angle. - - - - - - - - - This is the calibrated polarization angle axis to be used for data plotting. - - - - - - Calibration event of the ellipticity of the incoming or outgoing beam. - - - - - - - - - This is the calibrated ellipticity axis to be used for data plotting. - - - - - - For energy referencing, the measured energies are corrected for the charging potential - (i.e., the electrical potential of the surface region of an insulating sample, caused by - irradiation) such that those energies correspond to a sample with no surface charge. - Usually, the energy axis is adjusted by shifting all energies uniformally until one - well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. - - This concept is related to term `12.74 ff.`_ of the ISO 18115-1:2023 standard. - - .. _12.74 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 - - - - - - - - - Electronic core or valence level that was used for the calibration. - - - - - Reference peak that was used for the calibration. - - For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge | vacuum level - - - - - The binding energy (in units of eV) that the specified emission line appeared at, - after adjusting the binding energy scale. - - This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. - - .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - - - - - Offset between measured binding energy and calibrated binding energy of the - emission line. - - - - - This is the calibrated energy axis to be used for data plotting. - - This should link to /entry/data/energy. - - - - - - In the transmission correction, each intensity measurement for electrons of a given - kinetic energy is multiplied by the corresponding value in the relative_intensity - field of the transmission_function. This calibration procedure is used to account for - the different tranmsission efficiencies when using different lens modes. - - - - Transmission function of the electron analyser. - - The transmission function (TF) specifies the detection efficiency for electrons of - different kinetic energy passing through the electron analyser. - This can be a link to /entry/instrument/electronanalyser/transmission_function. - - - - - - - - - - - - - - Kinetic energy values - - - - - - - - Relative transmission efficiency for the given kinetic energies - - - - - - - - - - Describes the operations of image registration - - - - - Describes the operations of image distortion correction - - - - - Describes the operations of calibration procedures, e.g. axis calibrations. - - - - - The note will contain information about how the data was processed - or anything about the data provenance. - The contents of the note can be anything that the processing code - can understand, or simple text. - - The name will be numbered to allow for ordering of steps. - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - - - diff --git a/base_classes/NXpulser_apm.nxdl.xml b/base_classes/NXpulser_apm.nxdl.xml deleted file mode 100644 index 3a856635b9..0000000000 --- a/base_classes/NXpulser_apm.nxdl.xml +++ /dev/null @@ -1,238 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of pulses collected in between start_time and end_time - resolved by an instance of :ref:`NXevent_data_apm`. - - - - - Base class for a laser- and/or voltage-pulsing device used in atom probe - microscopy. - - - - - Detail whereby ion extraction is triggered methodologically. - - - - - - - - - - - Frequency with which the pulser fire(s). - - - - - - - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - - - - - - Fraction of the pulse_voltage that is applied in addition - to the standing_voltage at peak voltage of a pulse. - - If a standing voltage is applied, this gives nominal pulse fraction - (as a function of standing voltage). Otherwise, this field should - not be present. - - - - - - - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - - - - - - - Pulsed voltage, in laser pulsing mode this field can be omitted. - - - - - - - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - - - - - - Absolute number of pulses starting from the beginning of the experiment. - - - - - - - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - - - - - - - Direct current voltage between the specimen and the (local electrode) in - the case of local electrode atom probe (LEAP) instrument. Otherwise, the - standing voltage applied to the sample, relative to system ground. - - - - - - - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - - - - - - Atom probe microscopes use controlled laser, voltage, or a combination of - pulsing strategies to trigger ion extraction via exciting and eventual field evaporation - field emission of ion at the specimen surface. - - - - Given name/alias. - - - - - - Nominal wavelength of the laser radiation. - - - - - Nominal power of the laser source while illuminating the specimen. - - - - - Average energy of the laser at peak of each pulse. - - - - - - - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - - - - - - Details about specific positions along the laser beam - which illuminates the (atom probe) specimen. - - - - Track time-dependent settings over the course of the measurement - how the laser beam shines on the specimen, i.e. the mean vector - is parallel to the laser propagation direction. - - - - - - - - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - - - - - - Track time-dependent settings over the course of the measurement - where the laser beam exits the focusing optics. - - - - - - - - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - - - - - - Track time-dependent settings over the course of the - measurement where the laser hits the specimen. - - - - - - - - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - - - - - - - Affine transformations which describe the geometry how the - laser focusing optics/pinhole-attached coordinate system is - defined, how it has to be transformed so that it aligns with - the specimen coordinate system. - - - - - diff --git a/base_classes/NXreflectron.nxdl.xml b/base_classes/NXreflectron.nxdl.xml deleted file mode 100644 index f982a6e615..0000000000 --- a/base_classes/NXreflectron.nxdl.xml +++ /dev/null @@ -1,86 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of pulses collected in between start_time and end_time - resolved by an instance of :ref:`NXevent_data_apm`. - - - - - Base class for a device which reduces ToF differences of ions in ToF experiments. - - For atom probe the reflectron can be considered an energy compensation device. - Such a device can be realized technically for example with a Poschenrieder lens. - - Consult the following U.S. patents for further details: - - * 3863068 and 6740872 for the reflectron - * 8134119 for the curved reflectron - - - - Status of eventual existence and potential usage of this reflectron. - - - - - - - - - - Given name/alias. - - - - - - Free-text field to specify further details about the reflectron. - The field can be used to inform e. g. if the reflectron is flat or curved. - - - - - The maximum voltage applied to the reflectron, relative to system ground. - - - - - - Affine transformation(s) which detail where the reflectron is located - relative to e.g. the origin of the specimen space reference coordinate - system. This group can also be used for specifying how the reflectron - is rotated relative to a given axis in the instrument. - - - - diff --git a/base_classes/NXresolution.nxdl.xml b/base_classes/NXresolution.nxdl.xml deleted file mode 100644 index 4197d55506..0000000000 --- a/base_classes/NXresolution.nxdl.xml +++ /dev/null @@ -1,125 +0,0 @@ - - - - - - Describes the resolution of a physical quantity. - - - - The physical quantity of the resolution, e.g., - energy, momentum, time, etc. - - - - - The process by which the resolution was determined. - - - - - - - - - - - Additional details of the estimate or description of the calibration procedure - - - - - The resolution of the physical quantity. - - - - - Standard deviation of the resolution of the physical quantity. - - - - - Ratio of the resolution at a specified measurand value to that measurand value, - - - - - Standard deviation of the relative resolution of the physical quantity. - - - - - The response of the instrument or part to a infinitesimally sharp input signal - along the physical quantity of this group. - This is also sometimes called instrument response function for time resolution or - point spread function for spatial response. - The resolution is typically determined by taking the full width at half maximum (FWHM) - of the response function. - - - - The input axis or grid of the response function. - The unit should match the one of the resolution field. - - - - - The magnitude of the response function corresponding to the points - in the input axis or grid. - This field should have the same dimensions as `input`. - - - - - - A symbol linking to another path in this appdef to be referred to from the - `resolution_formula` field. This should be a valid path inside this application - definition, i.e., of the form /entry/instrument/my_part/my_field. - - - - - A resolution formula to determine the resolution from a set of symbols as - entered by the `formula_...` fields. - The output unit should match the provided unit of this field. - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - - - For storing details and data of a calibration to derive a resolution from data. - - - diff --git a/base_classes/NXroot.nxdl.xml b/base_classes/NXroot.nxdl.xml index 18bca6113c..de58feba51 100644 --- a/base_classes/NXroot.nxdl.xml +++ b/base_classes/NXroot.nxdl.xml @@ -46,39 +46,15 @@ Date and time of last file change at close - - - A repository containing the application definitions - used for creating this file. - If the NeXus_version attribute contains a commit distance and hash - this should refer to this repository. - - - Version of NeXus definitions used in writing the file. - This may either be a date based version tag of the form `vYYYY.MM` - or a version tag with a commit distance and source control (e.g., git) hash of - the form `vYYYY.MM.post1.dev<commit-distance>.g<git-hash>`. - It may contain an additional `.dYYYYMMDD` timestamp appendix - for dirty repositories. - If the version contains a commit distance and hash the - NeXus_repository attribute should be written with the - repository url containing this version. + Version of NeXus API used in writing the file. - Only used when the NAPI or pynxtools has written the file. + Only used when the NAPI has written the file. Note that this is different from the version of the base class or application definition version number. - - - A list of concepts in an application definition this file describes. - This is for partially filling an application definition. - If this attribute is not present the application definition is assumed - to be valid, if not only the specified concepts/paths are assumed to be valid. - - Version of HDF (version 4) library used in writing the file @@ -125,4 +101,5 @@ for a summary of the discussion. - \ No newline at end of file + + diff --git a/base_classes/NXrotation_set.nxdl.xml b/base_classes/NXrotation_set.nxdl.xml deleted file mode 100644 index 3f47e3fb89..0000000000 --- a/base_classes/NXrotation_set.nxdl.xml +++ /dev/null @@ -1,256 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of value tuples. - - - - - How many phases with usually different crystal and symmetry are distinguished. - - - - - Base class to detail a set of rotations, orientations, and disorientations. - - For getting a more detailed insight into the discussion of the - parameterized description of orientations in materials science see: - - * `H.-J. Bunge <https://doi.org/10.1016/C2013-0-11769-2>`_ - * `T. B. Britton et al. <https://doi.org/10.1016/j.matchar.2016.04.008>`_ - * `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_ - * `A. Morawiec <https://doi.org/10.1007/978-3-662-09156-2>`_ - - Once orientations are defined, one can continue to characterize the - misorientation and specifically the disorientation. The misorientation describes - the rotation that is required to register the lattices of two oriented objects - (like crystal lattice) into a crystallographic equivalent orientation: - - * `R. Bonnet <https://doi.org/10.1107/S0567739480000186>`_ - - - - Reference to an instance of :ref:`NXcoordinate_system_set` which contextualizes - how the here reported parameterized quantities can be interpreted. - - - - - - Point group which defines the symmetry of the crystal. - - This has to be at least a single string. If crystal_symmetry is not - provided point group 1 is assumed. - - In the case that misorientation or disorientation fields are used - and the two crystal sets resolve for phases with a different - crystal symmetry, this field has to encode two string. - In this case the first string is for phase A the second one for phase B. - An example of this most complex case is the description of the - disorientation between crystals adjoining a hetero-phase boundary. - - - - - - - - Point group which defines an assumed symmetry imprinted upon processing - the material/sample which could give rise to or may justify to use a - simplified description of rotations, orientations, misorientations, - and disorientations via numerical procedures that are known as - symmetrization. - - If sample_symmetry is not provided point group 1 is assumed. - - The traditionally used symmetrization operations within the texture - community in Materials Science, though, are thanks to methodology and - software improvements no longer strictly needed. Therefore, users are - encouraged to set the sample_symmetry to 1 (triclinic) and thus assume - there is no justification to assume the imprinting of additional - symmetry because of the processing. - - In practice one often faces situations where indeed these assumed - symmetries are anyway not fully observed, and thus an accepting of - eventual inaccuracies just for the sake of reporting a simplified - symmetrized description should be avoided. - - - - - - - - The set of rotations expressed in quaternion parameterization considering - crystal_symmetry and sample_symmetry. Rotations which should be - interpreted as antipodal are not marked as such. - - - - - - - - - The set of rotations expressed in Euler angle parameterization considering - the same applied symmetries as detailed for the field rotation_quaternion. - To interpret Euler angles correctly, it is necessary to inspect the - conventions behind depends_on to resolve which of the many Euler-angle - conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. - - - - - - - - - - - True for all those value tuples which have assumed antipodal symmetry. - False for all others. - - - - - - - - The set of orientations expressed in quaternion parameterization and - obeying symmetry for equivalent cases as detailed in crystal_symmetry - and sample_symmetry. The supplementary field is_antipodal can be used - to mark orientations with the antipodal property. - - - - - - - - - The set of orientations expressed in Euler angle parameterization following - the same assumptions like for orientation_quaternion. - To interpret Euler angles correctly, it is necessary to inspect the - conventions behind depends_on to resolve which of the many Euler-angle - conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. - - - - - - - - - - - The set of misorientations expressed in quaternion parameterization - obeying symmetry operations for equivalent misorientations - as defined by crystal_symmetry and sample_symmetry. - - - - - - - - - Misorientation angular argument (eventually signed) following the same - symmetry assumptions as expressed for the field misorientation_quaternion. - - - - - - - - Misorientation axis (normalized) and signed following the same - symmetry assumptions as expressed for the field misorientation_angle. - - - - - - - - - - The set of disorientation expressed in quaternion parameterization - obeying symmetry operations for equivalent misorientations - as defined by crystal_symmetry and sample_symmetry. - - - - - - - - - Disorientation angular argument (should not be signed, see - `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_) - following the same symmetry assumptions as expressed for the field - disorientation_quaternion. - - - - - - - - Disorientation axis (normalized) following the same symmetry assumptions - as expressed for the field disorientation_angle. - - - - - - - - diff --git a/base_classes/NXsample.nxdl.xml b/base_classes/NXsample.nxdl.xml old mode 100644 new mode 100755 index 4b15f3b8fa..c101fcb56f --- a/base_classes/NXsample.nxdl.xml +++ b/base_classes/NXsample.nxdl.xml @@ -48,9 +48,6 @@ Descriptive name of sample - - Identification number or signatures of the sample used. - The chemical formula specified using CIF conventions. @@ -382,63 +379,13 @@ - Any positioner (motor, PZT, ...) used to locate the sample - - - - This group describes the shape of the sample - - - - - Physical form of the sample material. - Examples include single crystal, foil, pellet, powder, thin film, disc, foam, gas, liquid, amorphous. - - - - - If the sample is a single crystal, add description of single crystal and unit - cell. - - - - - Set of sample components and their configuration. - There can only be one NXsample_component_set in one component. - - - - - - If the sample is made from a pure substance and cannot be further divided using - NXsample_component. - - - - - - Details about the sample vendor (company or research group) - - - - - An (ideally) globally unique identifier for the sample. - - - - - - Any environmental or external stimuli/measurements. - These can include, among others: - applied pressure, surrounding gas phase and gas pressure, - external electric/magnetic/mechanical fields, temperature, ... - - - - - A set of physical processes that occurred to the sample prior/during experiment. - - + Any positioner (motor, PZT, ...) used to locate the sample + + + + This group describes the shape of the sample + + .. index:: plotting @@ -471,3 +418,4 @@ + diff --git a/base_classes/NXsample_component.nxdl.xml b/base_classes/NXsample_component.nxdl.xml index 3c4670a148..1b5a282613 100644 --- a/base_classes/NXsample_component.nxdl.xml +++ b/base_classes/NXsample_component.nxdl.xml @@ -38,16 +38,11 @@ - One group like this per component can be recorded for a sample consisting of multiple components. + One group like this per component can be recorded For a sample consisting of multiple components. Descriptive name of sample component - - - Identification number or signatures of the sample component used. - - The chemical formula specified using CIF conventions. @@ -144,48 +139,6 @@ As a function of Wavelength - - - If the component is a single crystal, add description of single crystal and unit - cell. - - - - - Set of sub-components and their configuration. - There can only be one NXsample_component_set in one component. - - - - - - If the component is made from a pure substance and cannot be further divided - using NXsample_component. - - - - - - Details about the sample component vendor (company or research group) - - - - - An (ideally) globally unique identifier for the sample component. - - - - - A set of physical processes that occurred to the sample component prior/during - experiment. - - - - - Any NXsample_component depends on the instance of NXsample_component_set, at the same level of - description granularity where the component is located. - - .. index:: plotting @@ -199,4 +152,4 @@ for a summary of the discussion. - \ No newline at end of file + diff --git a/base_classes/NXsample_component_set.nxdl.xml b/base_classes/NXsample_component_set.nxdl.xml deleted file mode 100644 index aa3a0e794f..0000000000 --- a/base_classes/NXsample_component_set.nxdl.xml +++ /dev/null @@ -1,78 +0,0 @@ - - - - - - - - number of components - - - - - Set of sample components and their configuration. - - The idea here is to have a united place for all materials descriptors that are not - part of the individual sample components, but rather their configuration. - - - - Array of strings referring to the names of the NXsample_components. - The order of these components serves as an index (starting at 1). - - - - - Concentration of each component - - - - - - - - Volume fraction of each component - - - - - - - - Scattering length density of each component - - - - - - - - Each component set can contain multiple components. - - - - - For description of a sub-component set. Can contain multiple components itself. - - - diff --git a/base_classes/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml deleted file mode 100644 index e0593714c1..0000000000 --- a/base_classes/NXscanbox_em.nxdl.xml +++ /dev/null @@ -1,111 +0,0 @@ - - - - - - Scan box and coils which deflect a beam of charged particles in a controlled manner. - - The scan box is instructed by an instance of :ref:`NXprogram`, some control software, - which is not necessarily the same program as for all components of a microscope. - - The scanbox directs the probe of charged particles (electrons, ions) - to controlled locations according to a scan scheme and plan. - - - - - Name of the typically tech-partner-specific term that specifies - an automated protocol which controls the details how the components - of the microscope work together to achieve a controlled scanning of the - beam over the sample surface. - - In most cases users do not know, have to care, or are able to disentangle the - details of the spatiotemporal dynamics of the components of the microscope. - Instead, they rely on the assumption that the microscope and control software - work as expected. Selecting then a specific scan_schema assures some level - of reproducibility in the way how the beam is scanned over the surface. - - - - - TODO discuss with the electron microscopists. - - - - - TODO discuss with the electron microscopists. - - - - - - Time period during which the beam remains at one position. - - This concept is related to term `Dwell Time`_ of the EMglossary standard. - - .. _Dwell Time: https://purls.helmholtz-metadaten.de/emg/EMG_00000015 - - - - - Time period during which the beam moves from the final position of one scan - line to the starting position of the subsequent scan line. - - This concept is related to term `Flyback Time`_ of the EMglossary standard. - - .. _Flyback Time: https://purls.helmholtz-metadaten.de/emg/EMG_00000028 - - - - - TODO discuss with the electron microscopists. - - - - - TODO discuss with the electron microscopists. - - - - - TODO discuss with the electron microscopists. - - - - - TODO discuss with the electron microscopists. - - - - - TODO discuss with the electron microscopists. - - - - - - - diff --git a/base_classes/NXsensor.nxdl.xml b/base_classes/NXsensor.nxdl.xml index 7c2e5fce39..5917c370f3 100644 --- a/base_classes/NXsensor.nxdl.xml +++ b/base_classes/NXsensor.nxdl.xml @@ -55,7 +55,6 @@ - @@ -155,7 +154,6 @@ This group describes the shape of the sensor when necessary. - .. index:: plotting @@ -192,3 +190,4 @@ + diff --git a/base_classes/NXserialized.nxdl.xml b/base_classes/NXserialized.nxdl.xml deleted file mode 100644 index fda0769482..0000000000 --- a/base_classes/NXserialized.nxdl.xml +++ /dev/null @@ -1,74 +0,0 @@ - - - - - - Metadata to a set of pieces of information of a resource that has been serialized. - - A typical use case is the documentation of the source (file) or database (entry) - from which pieces of information have been extracted for consumption in e.g. a - research data management system (RDMS). This may be for reasons of enabling - services such as providing access to normalized information for which reading - again from the resource may not be desired, possibe, or feasible. - - Possible reasons could be the extraction of specific information for caching, - performance reasons, or re-evaluate given pieces of information based on other - views and interaction patterns with the data where information has been formatted - differently by tools than how these pieces of information were originally - serialized. - - - - Answers into what resource the information was serialized. - - - - - - - - - Path to the resource. - - E.g. the name of a file or its absolute or relative path, or the - identifier to a resource in another database. - - - - - Value of the hash that is obtained when running algorithm - on the content of the resource referred to by path. - - - - - Name of the algorithm whereby the checksum was computed. - - - - - - Extracted file containing the serialized information. - - - diff --git a/base_classes/NXsingle_crystal.nxdl.xml b/base_classes/NXsingle_crystal.nxdl.xml deleted file mode 100644 index 44f6e92c30..0000000000 --- a/base_classes/NXsingle_crystal.nxdl.xml +++ /dev/null @@ -1,72 +0,0 @@ - - - - - - Description of a single crystal material or a single crystalline phase in a material. - - There is the option of using Busing-Levy convention (as orginally designed in NXsample) - or using a more detailed description with NXrotation_set. - - - - This will follow the Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - - - - - - - - Orientation matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - - - - - - - - - UB matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is - the multiplication of the orientation_matrix, given above, - with the :math:`B` matrix which can be derived from the lattice constants. - - - - - - - - - Detailed description of single crystal orientation and misorientation. - - - - - Unit cell of the single crystal. - - - diff --git a/base_classes/NXsource.nxdl.xml b/base_classes/NXsource.nxdl.xml index 815022f889..34a5c80876 100644 --- a/base_classes/NXsource.nxdl.xml +++ b/base_classes/NXsource.nxdl.xml @@ -25,13 +25,8 @@ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd" name="NXsource" - type="group" extends="NXobject"> - - Radiation source emitting a beam. - - Examples include particle sources (electrons, neutrons, protons) or sources for electromagnetic radiation (photons). - This base class can also be used to describe neutron or x-ray storage ring/facilities. - + type="group" extends="NXobject"> + The neutron or x-ray storage ring/facility. Effective distance from sample @@ -67,7 +62,6 @@ type of radiation probe (pick one from the enumerated list and spell exactly) - @@ -97,9 +91,9 @@ - Source energy. Typically, this would be the energy of - the emitted beam. For storage rings, this would be - the particle beam energy. + Source energy. + For storage rings, this would be the particle beam energy. + For X-ray tubes, this would be the excitation voltage. @@ -169,107 +163,55 @@ For storage rings, the current at the end of the most recent injection. date and time of the most recent injection. - - - The wavelength of the radiation emitted by the source. - - - - - For pulsed sources, the energy of a single pulse. - - - - - For pulsed sources, the pulse energy divided - by the pulse duration - - - - - Material of the anode (for X-ray tubes). - - - - - Filament current (for X-ray tubes). - - - - - Emission current of the generated beam. - - - - - Gas pressure inside ionization source. - - - + "Engineering" location of source. - - - The size and position of an aperture inside the source. - - - - - Deflectors inside the source. - - - - - Individual electromagnetic lenses inside the source. - - - - - - This group describes the shape of the beam line component - - + + + This group describes the shape of the beam line component + + The wavelength or energy distribution of the source - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - - - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. + + + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + + + + + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. - The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the - z axis. + The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the + z axis. - .. image:: source/source.png - :width: 40% + .. image:: source/source.png + :width: 40% - - - - - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - - - \ No newline at end of file + + + + + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. + + + diff --git a/base_classes/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml deleted file mode 100644 index 3a34762545..0000000000 --- a/base_classes/NXspectrum_set.nxdl.xml +++ /dev/null @@ -1,559 +0,0 @@ - - - - - - - - - Number of spectra in the stack, for stacks the slowest dimension. - - - - - Number of image points along the slower dimension (k equivalent to z). - - - - - Number of image points along the slow dimension (j equivalent to y). - - - - - Number of image points along the fast dimension (i equivalent to x). - - - - - Number of energy bins (always the fastest dimension). - - - - - Base class container for reporting a set of spectra. - - The mostly commonly used scanning methods are supported. That is one-, - two-, three-dimensional ROIs discretized using regular Euclidean tilings. - - Use stack for all other tilings. - - - - - Details how spectra were processed from the detector readings. - - - - Resolvable data artifact (e.g. filename) from which all values in the :ref:`NXdata` - instances in this :ref:`NXspectrum_set` were loaded during parsing. - - Possibility to document from which specific other serialized resource as the source - pieces of information were processed when using NeXus as a semantic file format - to serialize that information differently. - - The group in combination with an added field *absolute_path* therein adds context. - - - - Reference to a location inside the artifact that points to the specific group of values - that were processed if the artifacts contains several groups of values and thus - further resolving of ambiguities is required. - - - - - - Imaging (data collection) mode of the instrument during acquisition - of the data in this :ref:`NXspectrum_set` instance. - - - - - Link or name of an :ref:`NXdetector` instance with which the data were - collected. - - - - - - - - One spectrum for a point of a 0d ROI. Also known as spot measurement. - - - - Counts - - - - - - - Counts - - - - - - Energy axis - - - - - - - Energy - - - - - - - One spectrum for each point of a 1d ROI. - - - - Counts - - - - - - - - Counts - - - - - - Point coordinate along the fast dimension. - - - - - - - Point coordinate along the fast dimension - - - - - - Energy axis - - - - - - - Energy - - - - - - - One spectrum for each scan point of 2d ROI. - - - - Counts - - - - - - - - - Counts - - - - - - Point coordinate along the slow dimension. - - - - - - - Point coordinate along the slow dimension. - - - - - - Point coordinate along the fast dimension. - - - - - - - Point coordinate along the fast dimension. - - - - - - Energy axis - - - - - - - Energy - - - - - - - One spectrum for point of a 3d ROI. - - - - Counts - - - - - - - - - - Counts - - - - - - Point coordinate along the slower dimension. - - - - - - - Point coordinate along the slower dimension. - - - - - - Point coordinate along the slow dimension. - - - - - - - Point coordinate along the slow dimension. - - - - - - Point coordinate along the fast dimension. - - - - - - - Point coordinate along the fast dimension. - - - - - - Energy axis - - - - - - - Energy - - - - - - - - Multiple instances of spectrum_0d. - - - - Counts - - - - - - - - Counts - - - - - - Group identifier - - - - - - - Group identifier - - - - - - Spectrum identifier - - - - - - - Spectrum identifier - - - - - - Energy axis - - - - - - - Energy - - - - - - - Multiple instances of spectrum_2d. - - - - Counts - - - - - - - - - - Counts - - - - - - Group identifier - - - - - - - Group identifier - - - - - - Spectrum identifier - - - - - - - Spectrum identifier - - - - - - Point coordinate along the slow dimension. - - - - - - - Point coordinate along the slow dimension. - - - - - - Point coordinate along the fast dimension. - - - - - - - Point coordinate along the fast dimension. - - - - - - Energy axis - - - - - - - Energy - - - - - - - Multiple instances of spectrum_3d. - - - - Counts - - - - - - - - - - - Counts - - - - - - Group identifier - - - - - - - Group identifier - - - - - - Spectrum identifier - - - - - - - Spectrum identifier - - - - - - Point coordinate along the slower dimension. - - - - - - - Point coordinate along the slower dimension. - - - - - - Point coordinate along the slow dimension. - - - - - - - Point coordinate along the slow dimension. - - - - - - Point coordinate along the fast dimension. - - - - - - - Point coordinate along the fast dimension. - - - - - - Energy axis - - - - - - - Energy - - - - - diff --git a/base_classes/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml deleted file mode 100644 index 84f83789a8..0000000000 --- a/base_classes/NXstage_lab.nxdl.xml +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - Base class for a stage (lab) used to hold, orient, and prepare a specimen. - - Modern stages are multi-functional devices. Stages provide a controlled - environment around the specimen. Stages enable experimentalists to apply - controlled external stimuli on the specimen. A stage_lab is a multi-purpose - /-functional tool that is constructed from multiple actuators, sensors, - and other components. - - With such stages comes the need for storing various (meta)data - that are generated while working and modifying the sample. - - Modern stages realize a hierarchy of components. Two examples are given to help - clarify how :ref:`NXstage_lab` instances should be used: Take a specimen that is - mounted on a multi-axial tilt rotation holder. This holder is fixed in the - support unit which connects the holder to the rest of the instrument. - Evidently different components are all considerable as to represent instances - of stages. - - In another example, taken from atom probe microscopy, researchers may work - with wire samples which are clipped into a larger fixing unit to enable - careful specimen handling. Alternatively, a microtip is a silicon post - upon which e.g. an atom probe specimen is mounted. - Multiple microtips are grouped into a microtip array to conveniently enable - loading of multiple specimens into the instrument with fewer operations. - That microtip array is fixed on a holder. Fixture units in atom probe are known - as stubs. Stubs in turn are positioned onto pucks. Pucks are then loaded onto - carousels. A carousel is a carrier unit with which eventually entire sets of - specimens can be moved in between parts of the microscope. All of these units - can be considered stage_lab instances. - - The :ref:`NXstage_lab` base class reflects this hierarchy. To cover for an as flexible - design of complex stages as possible, users should nest multiple instances of - :ref:`NXstage_lab` according to their needs to reflect the differences between what - they consider as the holder and what they consider is the stage. - The alias field can be used to specify the community jargon if necessary. - - However, a much clearer approach to reflect the hierarchy of all :ref:`NXstage_lab` - instances is postfix each instance named stage_lab with integers starting - from 1 as the top level unit. - In the microtip example one could thus use stage_lab1 for the microtip, - stage_lab2 for the microtip array, stage_lab3 holder, etc. - The depends_on keyword should be used to additional clarify the hierarchy - especially when users decide to not follow the above-mentioned postfixing - notation or when is not obvious from the postfixes which stage_lab is at - which level of the stage_lab hierarchy. - - Some examples for stage_labs in applications: - - * A nanoparticle on a copper grid. The copper grid is the holder. - The grid itself is fixed to a stage. - * An atom probe specimen fixed in a stub. In this case the stub can be - considered the holder, while the cryostat temperature control unit is - a component of the stage. - * Samples with arrays of specimens, like a microtip on a microtip array - is an example of an at least three-layer hierarchy commonly employed for - efficient sequential processing of atom probe experiments. - * With one entry of an application definition only one microtip should be - described. Therefore, the microtip is the specimen, - the array is the holder and the remaining mounting unit - that is attached to the cryo-controller is the stage. - * For in-situ experiments with e.g. chips with read-out electronics - as actuators, the chips are again placed in a larger unit. A typical - example are in-situ experiments using e.g. the tools of `Protochips <https://www.protochips.com>`_. - * Other examples are (quasi) in-situ experiments where experimentalists - anneal or deform the specimen via e.g. in-situ tensile testing machines - which are mounted on the specimen holder. - - For specific details and inspiration about stages in electron microscopes: - - * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ - * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ - * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ - * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) - * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) - * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) - * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ - - We are looking forward to suggestions from the scientists. - - - - Principal design of the stage. - - Exemplar terms could be side_entry, top_entry, - single_tilt, quick_change, multiple_specimen, - bulk_specimen, double_tilt, tilt_rotate, - heating_chip, atmosphere_chip, - electrical_biasing_chip, liquid_cell_chip - - - - - Free-text field to give a term how that a stage_lab at this level of the - stage_lab hierarchy is commonly referred to. Examples could be stub, - puck, carousel, microtip, clip, holder, etc. - - - - - The interpretation of this tilt should be specialized - and thus detailed via the application definition. - - - - - The interpretation of this tilt should be specialized - and thus detailed via the application definition. - - - - - The interpretation of this rotation should be specialized - and thus detailed via the application definition. - - - - - The interpretation of this position should be specialized - and thus detailed via the application definition. - - - - - - - - Voltage applied to the stage to decelerate electrons. - - - - - - - diff --git a/base_classes/NXsubentry.nxdl.xml b/base_classes/NXsubentry.nxdl.xml index 726080c202..2a95f45019 100644 --- a/base_classes/NXsubentry.nxdl.xml +++ b/base_classes/NXsubentry.nxdl.xml @@ -83,7 +83,7 @@ Extended title for entry - + Unique identifier for the experiment, defined by the facility, possibly linked to the proposals @@ -95,13 +95,13 @@ Description of the full experiment (document in pdf, latex, ...) - + User or Data Acquisition defined group of NeXus files or :ref:`NXentry` Brief summary of the collection, including grouping criteria. - + unique identifier for the measurement, defined by the facility. @@ -185,4 +185,5 @@ - \ No newline at end of file + + diff --git a/base_classes/NXsubstance.nxdl.xml b/base_classes/NXsubstance.nxdl.xml deleted file mode 100644 index 6d246ca224..0000000000 --- a/base_classes/NXsubstance.nxdl.xml +++ /dev/null @@ -1,119 +0,0 @@ - - - - - - A form of matter with a constant, definite chemical composition. - - Examples can be single chemical elements, chemical compunds, or alloys. - For further information, see https://en.wikipedia.org/wiki/Chemical_substance. - - - - User-defined chemical name of the substance - - - - - Molecular mass of the substance - - - - - Unique numeric CAS REGISTRY number of the sample chemical content - For further information, see https://www.cas.org/. - - - - - CAS REGISTRY name of the sample chemical content - - - - - CAS REGISTRY URI - - - - - CAS REGISTRY image - - - - - Synonyms in the CAS system. - - - - - String InChi identifier. - The InChI identifier expresses chemical structures in terms of atomic connectivity, - tautomeric state, isotopes, stereochemistry and electronic charge in order to - produce a string of machine-readable characters unique to the respective molecule. - For further information, see https://iupac.org/who-we-are/divisions/division-details/inchi/. - - - - - Condensed, 27 character InChI key. - Hashed version of the full InChI (using the SHA-256 algorithm). - - - - - Name according to the IUPAC system (standard). - For further information, see https://iupac.org/. - - - - - Identifier in the SMILES (Simplified Molecular Input Line Entry System) system - For further information, see https://www.daylight.com/smiles/. - - - - - Canonical version of the smiles identifier - - - - - The chemical formula specified using CIF conventions. - Abbreviated version of CIF standard:107 - This is the *Hill* system used by Chemical Abstracts. - - * Only recognized element symbols may be used. - * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. - * A space or parenthesis must separate each cluster of (element symbol + count). - * Where a group of elements is enclosed in parentheses, the multiplier for the - group must follow the closing parentheses. That is, all element and group - multipliers are assumed to be printed as subscripted numbers. - * Unless the elements are ordered in a manner that corresponds to their chemical - structure, the order of the elements within any group or moiety depends on - whether or not carbon is present. - * If carbon is present, the order should be: - - C, then H, then the other elements in alphabetical order of their symbol. - - If carbon is not present, the elements are listed purely in alphabetic order of their symbol. - - - diff --git a/base_classes/NXtransformations.nxdl.xml b/base_classes/NXtransformations.nxdl.xml index fd40f89e48..c8337ce725 100644 --- a/base_classes/NXtransformations.nxdl.xml +++ b/base_classes/NXtransformations.nxdl.xml @@ -170,9 +170,8 @@ - Points to the path of a field defining the axis on which this instance of - NXtransformations depends or the string ".". It can also point to an instance of - ``NX_coordinate_system`` if this transformation depends on it. + Points to the path to a field defining the axis on which this + depends or the string ".". @@ -203,7 +202,7 @@ the corresponding axis moves during the exposure of a frame. Ideally, the value of this field added to each value of ``AXISNAME`` would agree with the corresponding values of ``AXISNAME_end``, but there is a possibility of significant - differences. Use of ``AXISNAME_end`` is recommended. + differences. Use of ``AXISNAME_end`` is recommended. @@ -219,4 +218,4 @@ for a summary of the discussion. - \ No newline at end of file + diff --git a/base_classes/NXuser.nxdl.xml b/base_classes/NXuser.nxdl.xml index e014584c2b..607d50e90a 100644 --- a/base_classes/NXuser.nxdl.xml +++ b/base_classes/NXuser.nxdl.xml @@ -66,13 +66,12 @@ address/contact database - - - Details about an author code, open researcher, or contributor - (persistent) identifier, e.g. defined by https://orcid.org and expressed - as a URI. - - + + + an author code, Open Researcher and Contributor ID, + defined by https://orcid.org and expressed as a URI + + .. index:: plotting @@ -86,4 +85,5 @@ for a summary of the discussion. - \ No newline at end of file + + diff --git a/base_classes/NXaberration.nxdl.xml b/contributed_definitions/NXaberration.nxdl.xml similarity index 62% rename from base_classes/NXaberration.nxdl.xml rename to contributed_definitions/NXaberration.nxdl.xml index 44160b54fb..3c784de1bc 100644 --- a/base_classes/NXaberration.nxdl.xml +++ b/contributed_definitions/NXaberration.nxdl.xml @@ -1,10 +1,10 @@ - + - + Quantified aberration coefficient in an aberration_model. - - - Value of the aberration coefficient. - - - + + - Uncertainty of the value of the aberration coefficient - according to uncertainty_model. + Confidence - + - How was the uncertainty quantified e.g. via the 95% confidence interval - and using which algorithm or statistical model. + How was the uncertainty quantified e.g. via the 95% confidence interval. - + Time elapsed since the last measurement. - + - For the CEOS definitions the C aberrations are radial-symmetric and have - no angle entry, while the A, B, D, S, or R aberrations are n-fold + For the CEOS definitions the C aberrations are radial-symmetric and have no + angle entry, while the A, B, D, S, or R aberrations are n-fold symmetric and have an angle entry. For the NION definitions the coordinate system differs to the one used in CEOS and instead two aberration coefficients a and b are used. - - - Given name to this aberration. - - - - - Alias also used to name and refer to this specific type of aberration. - - + + diff --git a/contributed_definitions/NXaberration_model.nxdl.xml b/contributed_definitions/NXaberration_model.nxdl.xml new file mode 100644 index 0000000000..c340fc2aed --- /dev/null +++ b/contributed_definitions/NXaberration_model.nxdl.xml @@ -0,0 +1,105 @@ + + + + + + Models for aberrations of electro-magnetic lenses in electron microscopy. + + See `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) + for different definitions available and further details. Table 7-2 of Ibid. + publication (page 305ff) documents how to convert from the NION to the + CEOS definitions. + + + + + + + + + + + Defocus + + + + + Two-fold astigmatism + + + + + Two-fold astigmatism + + + + + Second-order axial coma + + + + + Second-order axial coma + + + + + Threefold astigmatism + + + + + Threefold astigmatism + + + + + Spherical aberration + + + + + Star aberration + + + + + Star aberration + + + + + Fourfold astigmatism + + + + + Fourfold astigmatism + + + + + Fifth-order spherical aberration + + + diff --git a/contributed_definitions/NXaberration_model_ceos.nxdl.xml b/contributed_definitions/NXaberration_model_ceos.nxdl.xml new file mode 100644 index 0000000000..584ef6c551 --- /dev/null +++ b/contributed_definitions/NXaberration_model_ceos.nxdl.xml @@ -0,0 +1,91 @@ + + + + + + CEOS definitions/model for aberrations of electro-magnetic lenses. + + See `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) + for different definitions available and further details. Table 7-2 of Ibid. + publication (page 305ff) documents how to convert from the NION to the + CEOS definitions. + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXaberration_model_nion.nxdl.xml b/contributed_definitions/NXaberration_model_nion.nxdl.xml new file mode 100644 index 0000000000..cb74995ddc --- /dev/null +++ b/contributed_definitions/NXaberration_model_nion.nxdl.xml @@ -0,0 +1,63 @@ + + + + + + NION definitions/model for aberrations of electro-magnetic lenses. + + See `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) + for different definitions available and further details. Table 7-2 of Ibid. + publication (page 305ff) documents how to convert from the NION to the + CEOS definitions. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml b/contributed_definitions/NXadc.nxdl.xml similarity index 67% rename from base_classes/NXcg_triangulated_surface_mesh.nxdl.xml rename to contributed_definitions/NXadc.nxdl.xml index da55b25306..b3edd70bcc 100644 --- a/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml +++ b/contributed_definitions/NXadc.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computational geometry description of a mesh of triangles. - - The mesh may be self-intersecting and have holes but the - triangles used must not be degenerated. + Analog-to-digital converter component/integrated circuit. - + - A graph-based approach to describe the mesh when it is also desired - to perform topological processing or analyses on the mesh. + TBD. - + diff --git a/base_classes/NXactivity.nxdl.xml b/contributed_definitions/NXaperture_em.nxdl.xml similarity index 53% rename from base_classes/NXactivity.nxdl.xml rename to contributed_definitions/NXaperture_em.nxdl.xml index f354de06d2..84a36254c2 100644 --- a/base_classes/NXactivity.nxdl.xml +++ b/contributed_definitions/NXaperture_em.nxdl.xml @@ -21,36 +21,39 @@ # # For further information, see http://www.nexusformat.org --> - + + - A planned or unplanned action that has a temporal extension and for some time depends on some entity. - - This class is planned be used in the future as the super class for all other activities if inheritance - in base classes is supported in NeXus. + Details of an individual aperture for beams in electron microscopy. - + - ISO 8601 formatted time code (with local time zone offset to UTC information - included) when this activity started. + Given name/alias of the aperture. - + - ISO 8601 formatted time code (with local time zone offset to UTC information - included) when this activity ended. + Relevant value from the control software. + + This is not always just the diameter of (not even in the case) + of a circular aperture. Usually it is a mode setting value which + is selected in the control software. + Which settings are behind the value should be defined + for now in the description field, if these are known + in more detail. - Short description of the activity. + Ideally, a (globally) unique persistent identifier, link, or text to a + resource which gives further details. Alternatively a free-text field. - + + - This can be any data or other descriptor acquired during the activity - (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. + Affine transformation which detail the arrangement in the + microscope relative to the optical axis and beam path. diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml new file mode 100644 index 0000000000..6f02ae1809 --- /dev/null +++ b/contributed_definitions/NXapm.nxdl.xml @@ -0,0 +1,1696 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Total number of independent wires in the delay-line detector. + + + + + Number of support points for e.g. modeling peaks. + + + + + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. + + + + + Number of mass-to-charge-state-ratio intervals of this ion type. + + + + + Number of bins in the x direction. + + + + + Number of bins in the y direction. + + + + + Number of bins in the z direction. + + + + + Number of bins. + + + + + Total number of integers in the supplementary XDMF topology array. + + + + + Application definition for atom probe and field ion microscopy experiments. + + This application definition provides a place to document data and metadata to + an atom probe experiment. Primarily the measurement itself is documented. + However, as most atom probe experiments are controlled with commercial software + which does not allow to access the raw detector hits, this application definition + also includes two key groups of processing steps (reconstruction and ranging). + + During tomographic reconstruction measured data are processed into a point cloud + of reconstructed positions of certain ions. During ranging time-of-flight data + are identified as representing specific ions to annotate each ion with a label. + + Commercial software used in atom probe research is designed as an integrated + acquisition and instrument control software. For AMETEK/Cameca local electrode + atom probe (LEAP) instruments the least processed (rawest) numerical results + and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which + are proprietary and their file format specifications not publicly documented. + + Supplementary metadata are kept in a database (formerly known as the ISDb) + which is connected to the instrument control software and synced with the + experiment while ions are detected. In effect, RHIT and HITS files + store the (rawest) experiment data in a closed manner that is + practically useless for users unless they have access to the + commercial software. + + To arrive at a state that atom probe microscopy (APM) with LEAP instruments + delivers a dataset with which users can study reconstructed atomic + position and do e.g. composition analyses or other post-processing + analysis tasks, these raw data have to be processed. Therefore, it is + necessary that for an application definition to be useful, details about + the physical acquisition of the raw data and all its + processing steps have to be stored. + + With this a user can create derived quantities like ion hit positions + (on the detector) and calibrated time-of-flight data. These derived + quantities are also needed to obtain calibrated mass-to-charge-state + ratios, and finally the tomographic reconstruction of the ion positions. + + In most cases, an APM dataset is useful only if it gets post-processed + via so-called ranging. Ranging defines rules for mapping time-of-flight + and mass-to-charge-state ratio values on ion species. This is post-processing + even though in practice it is performed sometimes already (as preview) + already while data are still being collected. + + The ion types decode molecular identities which can very often be + mapped to elemental identities, and also be used to distinguish isotopes. + All these steps are in most cases performed using commercial software. + + Frequently, though, ranging and post-processing is also performed with + (open-source) research software. Therefore, there is strictly speaking + not a single program used throughout an atom probe analysis not even + for the early stage of data acquisition and processing stages to obtain + a useful reconstructed and ranged dataset. + + This application definition documents not only the measurement but also the + key post-processing steps which transform the proprietary data into a + tomographic reconstruction with ranging definitions. + + Future guidance by the technology partners like AMETEK/Cameca could improve + this description to cover a substantial larger number of eventually metadata + that so far are neither publicly documented nor accessible. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of the application definition behind instead of filling in these + details into the experiment_description free-text description field. + + Users are encouraged to add in this field eventual DOIs to papers + which yield further details to the experiment. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the microscope session started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + experiment was performed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the experiment. The user should be aware that + even with having both dates specified, it may not be possible + to infer how long the experiment took or for how long data + were collected. + + More detailed timing data over the course of the experiment have to be + collected to compute this event chain during the experiment. + + + + + + ISO 8601 time code with local time zone offset to UTC included + when the microscope session ended. + + + + + + + + + + + Neither the specimen_name nor the experiment_identifier but the identifier + through which the experiment is referred to in the control software. + For LEAP instruments it is recommended to use the IVAS/APSuite + run_number. For other instruments, such as the one from Stuttgart or + Oxcart from Erlangen, or the instruments at GPM in Rouen, use the + identifier which is closest in meaning to the LEAP run number. + The field does not have to be required if the information is recoverable + in the dataset which for LEAP instruments is the case when RHIT or HITS + files are also stored alongside a data artifact instance which is + generated according to this NXapm application definition. + + As a destructive microscopy technique, a run can be performed only once. + It is possible, however, to interrupt a run and restart data acquisition + while still using the same specimen. In this case, each evaporation run + needs to be distinguished with different run numbers. + We follow this habit of most atom probe groups. + + This application definition does currently not allow storing the + entire set of such interrupted runs. Not because of a technical limitation + within NeXus but because we have not seen a covering use case based + on which we could have designed and implemented this case. + Atom probers are invited to contact the respective people in the + FAIRmat team to fix this. + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + Required for operation_mode apt_fim or other to give further details. + Users should not abuse this field to provide free-text information. + Instead, these pieces of information should be mapped to + respective groups and sections. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + What type of atom probe microscopy experiment is performed. + This field is primarily meant to inform materials database systems + to qualitatively filter experiments: + + * apt are experiments where the analysis_chamber has no imaging gas. + experiment with LEAP instruments are typically performed as apt. + * fim are experiments where the analysis_chamber has an imaging gas, + which should be specified with the atmosphere in the analysis_chamber group. + * apt_fim should be used for combinations of the two imaging modes. + * other should be used in combination with the user specifying details in the + experiment_documentation field. + + + + + + + + + + + + Contact information and eventually details person(s) involved in the + microscope session. This can be the principle investigator who performed + this experiment. Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + Description of the sample from which the specimen was prepared or + site-specifically cut out using e.g. a focused-ion beam instrument. + + The sample group is currently a place for storing suggestions from + atom probers about other knowledge they have gained about the sample + from which they cut the specimen which is field-evaporated during the + experiment. Typically this is possible because the atom probe specimen + is usually not heat treated as is but one assumes that one has the sample + prepared as needed (i.e. with a specific grain diameter) and can thus + just cut out the specimen from that material. + + There are cases though where the specimen is processed further, i.e. the + specimen is machined further or exposed to external stimuli during the + experiment. In this case, these details should not be stored in the + sample group but atom probers should make suggestions how this application + definition can be improved to find a better place and compromise + how to improve this application definition. + + In the future also details like how the grain_diameter was characterized, + how the sample was prepared, how the material was heat-treated etc., + should be stored as using specific application definitions/schemas + which are then arranged and documented with a description of the workflow + so that actionable graphs become instantiatable. + + + + Qualitative information about the grain size, here specifically + described as the equivalent spherical diameter of an assumed + average grain size for the crystal ensemble. + Users of this information should be aware that although the grain + diameter or radius is often referred to as grain size and used in + e.g. Hall-Petch-type materials models this is if at all an ensemble + average whose reporting may be very informative or not if the specimen + contains a few grains only. In atom probe the latter is often the case + because grains are measured partially as their diameter can be in the + order of magnitude of the physical diameter of the specimen. + + Reporting a grain size is useful though as it allows judging if + specific features are expected to be found in the detector hit map. + + + + + Magnitude of the standard deviation of the grain_diameter. + + + + + The temperature of the last heat treatment step before quenching. + Knowledge about this value can give an idea how the sample + was heat treated, however if available a documentation of the + annealing treatment should be delivered by adding additional files + which are uploaded alongside an NXapm instance. + In the future there should better be an own schema used for the + heat treatment. + + + + + Magnitude of the standard deviation of the heat_treatment_temperature. + + + + + Rate of the last quenching step. + Knowledge about this value can give an idea how the specimen + was heat treated, however there are many situations where one + can imagine that the scalar value for just the quenching rate, + i.e. the first derivative of the measured time-temperature profile + is itself time-dependant. An example is when the specimen was + left in the furnace after the furnace was switched off. In this case + the specimen cools down with a specific rate of how this furnace + cools down in the lab. Processes which in practice are often not + documented with measuring the time-temperature profile. + + This can be problematic because when the furnace door was left open + or the ambient temperature in the lab changes, i.e. for a series of + experiments where one is conducted on a hot summer + day and the next during winter as might have an effect on the + evolution of the microstructure. There are many cases where this + has been reported to be an issue in industry, e.g. think about aging + aluminium samples left on the factory parking lot on a hot summer + day. + + + + + Magnitude of the standard deviation of the heat_treatment_quenching_rate. + + + + + + The chemical composition of the sample. Typically it is assumed that + this more macroscopic composition is representative for the material + so that the composition of the typically substantially less voluminous + specimen probes from the more voluminous sample. + + + + Reporting compositions as atom and weight percent yields both + dimensionless quantities but their conceptual interpretation + differs. A normalization based on atom_percent counts relative to the + total number of atoms are of a particular type. By contrast, weight_percent + normalization factorizes in the respective mass of the elements. + Python libraries like pint are challenged by these differences as + at.-% and wt.-% both yield fractional quantities. + + + + + + + + + + Human-readable name of the element/ion (e.g. Fe). + Name has to be a symbol of an element from the periodic table. + All symbols in the set of NXion instances inside the group + chemical_composition need to be disjoint. + + + + + Composition value for the element/ion referred to under name. + The value is normalized based on normalization, i.e. composition + is either an atom or weight percent quantity. + + + + + Magnitude of the standard deviation of the composition (value). + + + + + + + + + + Descriptive name or ideally (globally) unique persistent identifier. + The name distinguishes the specimen from all others and especially the + predecessor/origin (see the sample group) from where this specimen was cut. + In cases where the specimen was e.g. site-specifically cut from the + sample referred to in the sample group or in cases of an instrument session + during which multiple specimens are loaded, the name has to be descriptive + enough to resolve which specimen on e.g. the microtip array was taken. + + The user is advised to store the details how a specimen was cut/prepared + from a specific sample in the sample_history. The sample_history field + must not be used for writing an alias of the specimen. Instead, + use the field alias for this. As an example there may be a specimen/sample + monitoring system in a lab with bar codes. The bar code is a good + specimen/sample name. A shorter and more human readable alias like + A0 can be an example for something to write in the alias field. + + In cases where multiple specimens have been loaded into the microscope + the name has to be the specific one, whose results are stored + by this NXentry, because a single NXentry is to be used for the + characterization of a single specimen in a single continuous run. + + Details about the specimen preparation should be stored in the + sample_history or if this is not possible in the sample group. + + + + + Ideally, a reference to the location of or a (globally) unique + persistent identifier of e.g. another file which should document + ideally as many details as possible of the material, its + microstructure, and its thermo-chemo-mechanical processing/ + preparation history. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider + as being the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing + state and details of the preparation. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this + should be a part of the sample history, i.e. the sample is imagined + handed over for the analysis. At the point it enters the microscope + the session starts. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments including tracers with a + short half time. Further time stamps prior to preparation_date should + better be placed in resources which describe the sample_history. + + + + + Short_name or abbreviation of the specimen name field. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history or from other data sources. + + + + + Discouraged free-text field in case properly designed records + for the sample_history or sample section are not available. + + + + + Report if the specimen is polycrystalline, in which case it + contains a grain or phase boundary, or if the specimen is a + single crystal. + + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + Container to hold different coordinate systems conventions. + + For the specific idea and conventions to use with the + NXcoordinate_system_set inspect the description of the + NXcoordinate_system_set base class. Specific details for application + in atom probe microscopy follow. + + In this research field scientists distinguish usually several + Euclidean coordinate systems (CS): + + * World space; + a CS specifying a local coordinate system of the planet earth which + identifies into which direction gravity is pointing such that + the laboratory space CS can be rotated into this world CS. + * The laboratory space; + a CS specifying the room where the instrument is located in or + a physical landmark on the instrument, e.g. the direction of the + transfer rod where positive is the direction how the rod + has to be pushed during loading a specimen into the instrument. + In summary, this CS is defined by the chassis of the instrument. + * The specimen space; + a CS affixed to either the base or the initial apex of the specimen, + whose z axis points towards the detector. + * The detector space; + a CS affixed to the detector plane whose xy plane is usually in the + detector and whose z axis points towards the specimen. + This is a distorted space with respect to the reconstructed ion + positions. + * The reconstruction space; + a CS in which the reconstructed ion positions are defined. + The orientation depends on the analysis software used. + * Eventually further coordinate systems attached to the + flight path of individual ions might be defined. + + Coordinate systems should be right-handed ones. + Clockwise rotations should be considered positive rotations. + + In atom probe microscopy a frequently used choice for the detector + space (CS) is discussed with the so-called detector space image + (stack). This is a stack of two-dimensional histograms of detected ions + within a predefined evaporation ID interval. Typically, the set of + ion evaporation sequence IDs is grouped into chunks. + + For each chunk a histogram of the ion hit positions on the detector + is computed. This leaves the possibility for inconsistency between + the so-called detector space and the e.g. specimen space. + + The transformation here resolves this ambiguity by specifying how + the positive z-axes of either coordinate systems is oriented. + Consult the work of A. J. Breen and B. Gault and team + for further details. + + + + + + + + + + Metadata and numerical data of the atom probe and the lab in which it + stands. + + An atom probe microscope (experiment) is different compared to a large- + scale facility or electron accelerator experiments in at least two ways: + + * First, ionized atoms and molecular ion(s fragments) + (in the case of atom probe tomography) + and (primarily) imaging gas ions (in the case of field ion + microscopy) are accelerated towards a position-sensitive + and time-of-flight taking detector system. + Hence, there is no real probe/beam. + * Second, the specimen is the lens of the microscope. + + + + + Given name of the atom probe at the hosting institution. This is an + alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, + etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + The space inside the atom probe along which ions pass nominally + when they leave the specimen and travel to the detector. + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + The nominal diameter of the specimen ROI which is measured in the + experiment. It is important to mention that the physical specimen + cannot be measured completely because ions may launch but not be + detected or hit elsewhere in the analysis_chamber. + + + + + + + Is a reflectron installed and was it used? + + + + + + + + + + + + + + + + A local electrode guiding the ion flight path. Also called + counter or extraction electrode. + + + + Identifier of the local_electrode in an e.g. database. + + + + + + + + + + + + + + + + Detector for taking raw time-of-flight and + ion/hit impact positions data. + + + + Description of the detector type. Specify if the detector is + not the usual type, i.e. not a delay-line detector. + In the case the detector is a multi-channel plate/ + delay line detector, use mcp_dld. In the case the detector is + a phosphor CCD use phosphor_ccd. In other case specify + the detector type via free-text. + + + + + + Given name/alias. + + + + + + Given brand or model name by the manufacturer. + + + + + Given hardware name/serial number or hash identifier + issued by the manufacturer. + + + + + Given name of the manufacturer. + + + + + Amplitude of the signal detected on the multi-channel plate (MCP). + + This field should be used for storing the signal amplitude quantity + within ATO files. The ATO file format is used primarily by the + atom probe groups of the GPM in Rouen, France. + + + + + + + + + + + + + + + + + + + Atom probe microscopes use controlled laser, voltage, or a + combination of pulsing strategies to trigger the excitation + and eventual field evaporation/emission of an ion during + an experiment. + If pulse_mode is set to laser or laser_and_voltage (e.g. for + LEAP6000-type instruments) having the group/section laser_gun + is required and the following of its fields have to be filled: + + * name + * wavelength + * energy + + + + + + + + + + + + + + + + + + + + + + Average temperature at the specimen base, i.e. + base_temperature during the measurement. + + + + + The best estimate, at experiment time, for the temperature at the + sample base (furthest point along sample apex and holding assembly + that is removable from the sample stage). + + + + + + + + + + + + + + + + + + + + Average pressure in the analysis chamber. + + + + + + + + + + + + + + + + Average pressure in the buffer chamber. + + + + + + + + + + + + + + + + Average pressure in the load_lock_chamber. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A possible place, which has to be discussed with the atom probe + community more though, where quantitative details about the calibration + of the counter electrode could be stored. Work in this direction was + e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ + (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) + + + + + + + A place where details about the initial shape of the specimen + can be stored. Ideally, here also data about the shape evolution + of the specimen can be stored. There are currently very few + techniques which can measure the shape evolution: + + * Correlative electron microscopy coupled with modeling + but this usually takes an interrupted experiment + in which the specimen is transferred, an image taken, + and a new evaporation sequence initiated. + Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ + and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. + * Another method, which is less accurate though, is to monitor + the specimen evolution via the in-built camera system + (if available) in the instrument. + * Another method is to use correlated scanning force microscopy + methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. + * A continuous monitoring of the specimen in a + correlative electron microscopy/atom probe experiment + is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ + Nothing can be said about the outcome of this research yet but + here is where such spatio-temporally data could be stored. + + + + + Ideally measured or best elaborated guess of the + initial radius of the specimen. + + + + + Ideally measured or best elaborated guess of the shank angle. + This is a measure of the specimen taper. Define it in such a way + that the base of the specimen is modelled as a conical frustrum so + that the shank angle is the (shortest) angle between the specimen + space z-axis and a vector on the lateral surface of the cone. + + + + + Average detection rate over the course of the experiment. + + + + + + Estimated field at the apex along the evaporation sequence. + + + + + + + + + The majority of atom probe microscopes come from a + single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. + Their instruments are controlled via an(/a set) of integrated + instrument control system(s) (APSuite/IVAS/DAVis). + + By contrast, instruments which were built by individual + research groups such as of the French (GPM, Rouen, France), + the Schmitz (Inspico, Stuttgart, Germany), + the Felfer (Oxcart, Erlangen, Germany), + the Northwestern (D. Isheim, Seidman group et al.), + or the PNNL group (Pacific Northwest National Laborary, + Portland, Oregon, U.S.) have other solutions + to control the instrument. + + Some of which are modularized and open, + some of which realize also integrated control units with + portions of eventually undisclosed source code and + (so far) lacking (support of)/open APIs. + + Currently, there is no accepted/implemented + community-specific API for getting finely granularized + access to such control settings. + + These considerations motivated the design of the NXapm + application definition in that it stores quantities in NXcollection. + groups to begin with. Holding heterogeneous, not yet standardized + but relevant pieces of information is the purpose of this collection. + + + + + + + + + + Track time-dependent details over the course of the measurement about the + buffer_chamber. + + + + + Track time-dependent details over the course of the measurement about the + load_lock_chamber. + + + + + Track time-dependent details over the course of the measurement about the + analysis_chamber. + + + + + + + + A statement whether the measurement was successful or failed prematurely. + + + + + + + + + + + + + Details about where ions hit the ion_detector and data processing + steps related to analog-to-digital conversion of detector signals + into ion hit positions. For AMETEK LEAP instruments this processing + takes place partly in the control unit of the detector partly + in the software. The process is controlled by the acquisition/ + instrument control software (IVAS/APSuite/DAVis). + The exact details are not documented by AMETEK in an open manner. + For instruments built by individual research groups, + like the Oxcart instrument, individual timing data from the + delay-line detector are openly accessible. + + + + + + + + + + + Raw readings from the analog-to-digital-converter + timing circuits of the detector wires. + + + + + + + + + + Evaluated ion impact coordinates at the detector + (either as computed from the arrival time data + or as reported by the control software). + If the acquisition software enables it one can also store in this + field the hit_positions, as measured by the detector, without any + corrections. + + + + + + + + + + + This could be a place where currently the publicly undocumented + algorithmic steps are stored how detected hits are judged for their + quality. In CamecaRoot this there is something mentioned like + golden and partial hits, here is where this could be documented. + + + + + + + Data post-processing step which is, like the impact position analyses, + usually executed in the integrated control software. This processing + yields how many ions were detected with each pulse. + + It is possible that multiple ions evaporate and hit the same or + different pixels of the detector on the same pulse. + These data form the basis to analyses of the so-called + (hit) multiplicity of an ion. + + Multiplicity must not be confused with how many atoms + f the same element or isotope, respectively, a molecular + ion contains (which is instead encoded with the + isotope_vector field of each NXion instance). + + + + + + + + + + Number of pulses since the last detected ion pulse. + For multi-hit records, after the first record, this is zero. + + + + + + + + + Number of pulses since the start of the atom probe + run/evaporation sequence. + + + + + + + + + Hit multiplicity. + + + + + + + + + Like impact position and hit multiplicity computations, + ion filtering is a data post-processing step with which users + identify which of the detected ions should be included + in the voltage-and-bowl correction. + This post-processing is usually performed via GUI interaction + in the reconstruction pipeline of IVAS/APSuite. + + + + + + + + + + Bitmask which is set to true if the ion + is considered and false otherwise. + + + + + + + + + + Data post-processing step to correct for ion impact + position flight path differences, detector biases, + and nonlinearities. This step is usually performed + with commercial software. + + + + + + + + + + + Raw time-of-flight data as read out from the acquisition software + if these data are available and accessible. + + + + + + + + + Calibrated time-of-flight. + + + + + + + + The key idea and algorithm of the voltage-and-bowl correction is + qualitatively similar for instruments of different manufacturers + or research groups. + + Specific differences exists though in the form of different + calibration models. For now we do not wish to resolve or + generalize these differences. Rather the purpose of this collection + is to provide a container where model-specific parameters + and calibration models can be stored if users know these + for sure. + + For AMETEK LEAP instruments this should be the place for + storing initial calibration values. These values are + accessible normally only by AMETEK service engineers. + They use these for calibrating the detector and instrument. + + Users can also use this NXcollection for storing the + iteratively identified calibrations which scientists + will see displayed in e.g. APSuite while they execute + the voltage-and-bowl correction as a part of the + reconstruction pipeline in APSuite. + + + + + + + Data post-processing step in which calibrated time-of-flight data + (ToF) are interpreted into mass-to-charge-state ratios. + + + + + + + + + + Store vendor-specific calibration models here (if available). + + + + + Mass-to-charge-state ratio values. + + + + + + + + + + + Data post-processing step to create a tomographic reconstruction + of the specimen based on selected calibrated ion hit positions, + the evaporation sequence, and voltage curve data. + Very often scientists use own software scripts according to + published procedures, so-called reconstruction protocols, + i.e. numerical recipes how to compute x, y, z atomic positions + from the input data. + + + + + + + + + + Qualitative statement about which reconstruction protocol was used. + + + + + + + + + + + + + Different reconstruction protocols exist. Although these approaches + are qualitatively similar, each protocol uses different parameters + (and interprets these differently). The source code to IVAS/APSuite + is not open. For now users should store reconstruction parameter + in a collection. + + + + + + Different strategies for crystallographic calibration of the + reconstruction are possible. The field is required and details + should be specified in free-text at least. If the not crystallographic + calibration was performed the field should be filled with the n/a, + meaning not applied. + + + + + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + + + + + + + + + + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstructed dataset. + The XDMF primitive type is here 1, the number of primitives 1 per + triplet, the last integer in each triplet is the identifier of + each point starting from zero. + + + + + + + + + + Six equally formatted sextets chained together. For each + sextett the first entry is an XDMF primitive topology + key (here 5 for polygon), the second entry the XDMF primitive + count value (here 4 because each face is a quad). + The remaining four values are the vertex indices. + + + + + + + + To get a first overview of the reconstructed dataset, + the format conversion computes a simple 3d histogram + of the ion density using one nanometer cubic bins without + applying smoothening algorithms on this histogram. + + + + + + + + + A default three-dimensional histogram of the total + number of ions in each bin obtained via using a rectangular + transfer function. + + + + + + + + + Array of counts for each bin. + + + + + + + + + + Bin center of mass position along the z axis. + + + + + + + + + Bin center of mass position along the y axis. + + + + + + + + + Bin center of mass position along the x axis. + + + + + + + + + + + + + Data post-processing step in which elemental, isotopic, + and/or molecular identities are assigned to the ions. + The documentation of these steps is based on ideas + described in the literature: + + * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ + * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + + How many ion types are distinguished. + If no ranging was performed each ion is of the special unknown type. + The iontype ID of this unknown type is 0 which is a reserve value. + Consequently, iontypes start counting from 1. + + + + + Assumed maximum value that suffices to store all relevant + molecular ions, even the most complicated ones. + Currently a value of 32 is used. + + + + + Specifies the computation of the mass-to-charge histogram. + Usually mass-to-charge values are studied as an ensemble quantity, + specifically these values are binned. + This (NXprocess) stores the settings of this binning. + + + + + + + + + Smallest and largest mass-to-charge-state ratio value. + + + + + + + + + Binning width of the mass-to-charge-state ratio values. + + + + + + A default histogram aka mass spectrum of + the mass-to-charge-state ratio values. + + + + + + + + + Array of counts for each bin. + + + + + + + + + Right boundary of each mass-to-charge-state ratio value bin. + + + + + + + + + + + + Details of the background model which was used to + correct the total counts per bin into counts. + + + + + + + + + + + How where peaks in the background-corrected in the histogram + of mass-to-charge-state ratio values identified? + + + + + + + + + + + THIS DOCSTRING NEEDS CLARIFICATION. + + + + + + + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_composition_space_results.nxdl.xml b/contributed_definitions/NXapm_composition_space_results.nxdl.xml new file mode 100644 index 0000000000..15c107dc48 --- /dev/null +++ b/contributed_definitions/NXapm_composition_space_results.nxdl.xml @@ -0,0 +1,488 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of voxel of discretized domain for analyzed part of the dataset. + + + + + The dimensionality of the grid. + + + + + The cardinality or total number of cells/grid points. + + + + + Number of terms in the composition clustering dictionary + + + + + Number of terms in the position clustering dictionary + + + + + Results of a run with Alaukik Saxena's composition space tool. + + This is an initial draft application definition for the common NFDI-MatWerk, + FAIRmat infrastructure use case IUC09 how to improve the organization and + results storage of the composition space tool and make these data at the same + time directly understandable for NOMAD. + + This draft does no contain yet the annotations for how to also store + in the HDF5 file a default visualization whereby the composition grid + could directly be explored using H5Web. I am happy to add this ones the + data have been mapped on this schema, i.e. more discussion needed. + + Also iso-surfaces can be described, for paraprobe, this is a solved problem, + check the respective group in the NXapm_paraprobe_results_nanochem data + schema/application definition. + + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + + + + + + + TBD, maybe how to link between pyiron state tracking and app state tracking + + + + + Disencouraged place for free-text for e.g. comments. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. when composition space tool was started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and composition space tool exited as a process. + + + + + The path and name of the config file for this analysis. + TBD, this can be e.g. Alaukik's YAML file for composition space. + + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + + The path and name of the file (technology partner or community format) + from which reconstructed ion positions were loaded. + + + + + + + + The path and name of the file (technology partner or community format + from which ranging definitions, i.e. how to map mass-to- + charge-state ratios on iontypes were loaded. + + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the executable managed to process the analysis + or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + + + + The individual coordinate systems which should be used. + Some suggestions follow, e.g. that field names should be prefixed + with the following controlled terms indicating which individual + coordinate system is described: + + * world + * composition_space + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + + + + + Position of each cell in Euclidean space. + + + + + + + + + + + + + + + + For each ion, the identifier of the voxel in which the ion is located. + + + + + + + + + + + + + + + + + + In Alaukik's tool the GMM step. + + + + + + + + + The keywords of the dictionary of distinguished compositionally- + defined cluster, e.g. the phases. Examples for keywords could be + phase1, phase2, and so one and so forth. + + + + + + + + Resolves for each keyword in cluster_dict which integer is used to + label something that it belongs or is assumed to represent this + cluster. + + + + + + + + + For example if the voxel grid is used to report that there + are voxels which are assumed to represent volume of either phase1 + or phase2, the cluster_dict_keyword would be a list with two names + phase1 and phase2, respectively. The cluster_dict_value would be a + list of e.g. integers 1 and 2. These could be used to build an + array with as many entries as there are voxel and store in this array + the respective value to encode which phase is assumed for each voxel. + + + + + + + + + + In Alaukik's tool the DBScan step after the GMM step. + + + + + + + + + The keywords of the dictionary of distinguished spatially-contiguous + clusters. Examples for keywords could be precipitate1, precipitate2, + and so one and so forth. + + + + + + + + Resolves for each keyword in cluster_dict which integer is used to + label something that it belongs or is assumed to represent this + cluster. + + + + + + + + + For example if the voxel grid is used to report that there + are voxels which are assumed to represent volume of certain precipitates, + say we found ten precipitates and consider the rest as matrix. + We could make a list of say matrix, precipitate1, precipitate2, ..., + precipitate10. With cluster_dict_value then running from 0 to 10, + i.e. matrix is flagged special as 0 and the remaining particles + are indexed conveniently as 1, 2, ..., 10 like end users expect. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/NXapm_input_ranging.nxdl.xml b/contributed_definitions/NXapm_input_ranging.nxdl.xml new file mode 100644 index 0000000000..b82a78e70d --- /dev/null +++ b/contributed_definitions/NXapm_input_ranging.nxdl.xml @@ -0,0 +1,63 @@ + + + + + + + Metadata to ranging definitions made for a dataset in atom probe microscopy. + + Ranging is the process of labeling time-of-flight data with so-called iontypes + which ideally specify the most likely ion/molecular ion evaporated within a + given mass-to-charge-state-ratio value interval. + + The paraprobe-toolbox uses the convention that the so-called UNKNOWNTYPE + iontype (or unranged ions) represents the default iontype. + The ID of this special iontype is always reserved as 0. Each ion + is assigned to the UNKNOWNTYPE by default. Iontypes are assigned + by checking if the mass-to-charge-state-ratio values of an ion matches + to any of the defined mass-to-charge-state-ratio intervals. + + + + Path and name of the NeXus/HDF5 file which stores ranging definitions. + + + + Version identifier of the file (representing an at least SHA256 strong) + hash. Such hashes serve reproducibility as they can be used for tracking + provenance metadata in a workflow. + + + + + + Name of the group (prefix to the individual ranging definitions) inside + the file referred to by filename which points to the specific ranging + definition to use. + An HDF5 file can store multiple ranging definitions. Using an ID is + the mechanism to distinguish which specific ranging (version) will + be processed. Reconstruction and ranging IDs can differ. + They specify different IDs. + + + diff --git a/contributed_definitions/NXapm_input_reconstruction.nxdl.xml b/contributed_definitions/NXapm_input_reconstruction.nxdl.xml new file mode 100644 index 0000000000..8ed7b90021 --- /dev/null +++ b/contributed_definitions/NXapm_input_reconstruction.nxdl.xml @@ -0,0 +1,58 @@ + + + + + + + Metadata of a dataset (tomographic reconstruction) in atom probe microscopy. + + + + Name of the (NeXus)/HDF5 file which stores reconstructed ion position + and mass-to-charge-state ratios. Such an HDF5 file can store multiple + reconstructions. Using the information within the dataset_name fields + is the mechanism whereby paraprobe decides which reconstruction to + process. With this design it is possible that the same HDF5 + file can store multiple versions of a reconstruction. + + + + Version identifier of the file (representing an at least SHA256 strong) + hash. Such hashes serve reproducibility as they can be used for tracking + provenance metadata in a workflow. + + + + + + Name of the dataset inside the HDF5 file which refers to the + specific reconstructed ion positions to use for this analysis. + + + + + Name of the dataset inside the HDF5 file which refers to the + specific mass-to-charge-state-ratio values to use for this analysis. + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml new file mode 100644 index 0000000000..4f13739236 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml @@ -0,0 +1,477 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + + Maximum number of atoms per molecular ion. Should be 32 for paraprobe. + + + + + Number of clustering algorithms used. + + + + + Number of different iontypes to distinguish during clustering. + + + + + Configuration of a paraprobe-clusterer tool run in atom probe microscopy. + + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + How many tasks to perform? + + + + + This process maps results from cluster analyses performed with IVAS/APSuite + into an interoperable representation. Specifically in this process + paraprobe-clusterer takes results from clustering methods from other tools + of the APM community, like IVAS/APSuite. These results are usually reported + in two ways. Either as an explicit list of reconstructed ion positions. + In the case of IVAS these positions are reported through a text file + with a cluster label for each position. + + Alternatively, the list of positions is reported, as it is the case for + AMETEK (IVAS/AP Suite) but the cluster labels are specified implicitly + only in the following way: The mass-to-charge-state ratio column of a + what is effectively a file formatted like POS is used to assign a hypothetical + mass-to-charge value which resolves a floating point representation + of the cluster ID. + + Another case can occur where all disjoint floating point values, + i.e. here cluster labels, are reported and then a dictionary is created + how each value matches to a cluster ID. + + In general the cluster ID zero is reserved for marking the dataset + as to not be assigned to any cluster. Therefore, indices of disjoint + clusters start at 1. + + + + + + + + + AMETEK/Cameca results of cluster analyses, like with the maximum- + separation (MS) method clustering algorithm `J. Hyde et al. <https://doi.org/10.1557/PROC-650-R6.6>`_ + are stored as an improper POS file: This is a matrix of floating + point quadruplets, one for each ion and as many quadruplets as + ions were investigated. The first three values encode the position + of the ion. The fourth value is an improper mass-to-charge-state-ratio + value which encodes the integer identifier of the cluster as a floating + point number. + + + + + + + Specifies if the tool should try to recover for each position the closest + matching position from dataset/dataset_name_reconstruction (within + floating point accuracy). This can be useful for instance when users + wish to recover the original evaporation ID, which IVAS/AP Suite drops + for instance when writing their *.indexed.* cluster results POS files. + + + + + + + This process performs a cluster analysis on a reconstructed dataset + or a portion of the reconstruction. + + + + + + + + + + + + + + + + + The tool enables to inject precomputed distance information for each + point/ion which can be used for further post-processing and analysis. + + + + Name of an HDF5 file which contains the ion distances. + + + + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + + + + + + Absolute HDF5 path to the dataset with distance values for each ion. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + How should iontypes be interpreted/considered during the cluster analysis. + Different options exist how iontypes are interpreted (if considered at all) + given an iontype represents in general a (molecular) ion with different isotopes + that have individually different multiplicity. + + The value resolve_all will set an ion active in the analysis + regardless of which iontype it is. + The value resolve_unknown will set an ion active when it is of the + UNKNOWNTYPE. + The value resolve_ion will set an ion active if it is of the + specific iontype, irregardless of its elemental or isotopic details. + The value resolve_element will set an ion active, and most importantly, + account as many times for it, as the (molecular) ion contains + atoms of elements in the whitelist ion_query_isotope_vector. + The value resolve_isotope will set an ion active, and most importantly, + account as many times for it, as the (molecular) ion contains isotopes + in the whitelist ion_query_isotope_vector. + + In effect, ion_query_isotope_vector acts as a whitelist to filter + which ions are considered as source ions of the correlation statistics + and how the multiplicity of each ion will be factorized. + + This is relevant as in atom probe we have the situation that a ion + of a molecular ion with more than one nuclid, say Ti O for example + is counted such that although there is a single TiO molecular ion + at a position that the cluster has two members. This multiplicity + affects the size of the feature and chemical composition. + + + + + + + + + Matrix of isotope vectors, as many as rows as different candidates + for iontypes should be distinguished as possible source iontypes. + In the simplest case, the matrix contains only the proton number + of the element in the row, all other values set to zero. + Combined with ion_query_type_source set to resolve_element this will + recover usual spatial correlation statistics like the 1NN C-C + spatial statistics. + + + + + + + + + Settings for DBScan clustering algorithm. For original details about the + algorithms and (performance-relevant) details consider: + + * `M. Ester et al. <https://dx.doi.org/10.5555/3001460.3001507>`_ + * `M. Götz et al. <https://dx.doi.org/10.1145/2834892.2834894>`_ + + For details about how the DBScan algorithms is the key behind the + specific modification known as the maximum-separation method in the + atom probe community consider `E. Jägle et al. <https://dx.doi.org/10.1017/S1431927614013294>`_ + + + + Strategy how runs are performed with different parameter: + + * For tuple as many runs are performed as parameter values. + * For combinatorics individual parameter arrays are looped over. + + As an example we may define eps with ten entries and min_pts with + three entries. If high_throughput_method is tuple the analysis is + invalid as we have an insufficient number of min_pts for the ten + eps values. + By contrast, for combinatorics paraprobe-clusterer will run three + individual min_pts runs for each eps value, resulting in a total + of 30 analyses. + As an example the DBScan analysis reported in `M. Kühbach et al. <https://dx.doi.org/10.1038/s41524-020-00486-1>`_ + would have defined an array of values np.linspace(0.2, 5.0, nums=241, endpoint=True) + eps values, min_pts one, and high_throughput_method set to combinatorics. + + + + + + + + + Array of epsilon (eps) parameter values. + + + + + + + + Array of minimum points (min_pts) parameter values. + + + + + + + + + + Settings for the OPTICS clustering algorithm. + + * `M. Ankerest et al. <https://dx.doi.org/10.1145/304181.304187>`_ + + + + Strategy how runs are performed with different parameter: + + * For tuple as many runs are performed as parameter values. + * For combinatorics individual parameter arrays are looped over. + + See the explanation for the corresponding parameter for dbscan + processes above-mentioned for further details. + + + + + + + + + Array of minimum points (min_pts) parameter values. + + + + + + + + Array of maximum epsilon (eps) parameter values. + + + + + + + + + Settings for the HPDBScan clustering algorithm. + + * L. McInnes et al. <https://dx.doi.org/10.21105/joss.00205>`_ + * scikit-learn hdbscan library `<https://hdbscan.readthedocs.io/en/latest/how_hdbscan_works.html>`_ + + See also this documentation for details about the parameter. + Here we use the terminology of the hdbscan documentation. + + + + Strategy how runs are performed with different parameter: + + * For tuple as many runs are performed as parameter values. + * For combinatorics individual parameter arrays are looped over. + + See the explanation for the corresponding parameter for dbscan + processes above-mentioned for further details. + + + + + + + + + Array of min_cluster_size parameter values. + + + + + + + + Array of min_samples parameter values. + + + + + + + + Array of cluster_selection parameter values. + + + + + + + + Array of alpha parameter values. + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml new file mode 100644 index 0000000000..4a24598fe1 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml @@ -0,0 +1,257 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Configuration/settings of a paraprobe-distancer software tool run. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + How many individual analyses should the tool execute. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Compute for all filtered points, e.g. ions of the point set + the shortest Euclidean distance to the closest triangle of the + set of triangles. The triangles can formed a closed surface mesh. + Distances are not simple distances based on normal projections but + giving an exact solution. + + + + + Paraprobe-distancer enables the computation of the Euclidean shortest + distance for each member of a set of points against a set of triangles. + In contrast to comparable methods used in atom probe the here computed + distance is not simply the projected distance to one of the triangles + but the more costly but robust computation of the distance between + a point and a triangle. + + The triangles can represent for instance the facets of a triangulated + surface mesh of a model for the edge of the dataset. Such a model can + be computed with paraprobe-surfacer. Alternatively, the triangles can + be those from the set of all facets for a set of convex hulls, alpha-shapes, + or alpha wrappings about three-dimensional objects like precipitates + (computed with e.g. paraprobe-nanochem). + + Currently, the tool does not check if the respectively specified + triangle sets are consistent, what their topology is, or whether or + not they are consistently oriented. + Each dataset that is referred to in the list_of _dataset_names_vertices + should be an (Nvertices, 3) array of NX_FLOAT. Each dataset referred + to in the list_of_dataset_names_facet_indices should be an + (Nfacets, 3) array of NX_UINT. + Facet indices refer to vertex indices. These need to start at zero + and must not exceed Nvertices - 1, i.e. the identifier_offset is 0 + and vertices are indexed thus implicitly. + Facet normal vectors have to be also an array + of shape (Nfacets, 3) of NX_FLOAT. + + + + How many triangle sets to consider. + + + + + List of triangle sets. This design allows users to combine + multiple triangle sets. + + + + Name of the HDF5 file(s) which contain(s) vertex coordinates + and facet indices to describe the desired set of triangles. + + + + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional + layer of reproducibility. + + + + + + Absolute HDF5 path to the dataset which + specifies the array of vertex positions. + + + + + Absolute HDF5 path to the dataset which + specifies the array of facet indices. + + + + + Absolute HDF5 path to the dataset which + specifies the array of facet normal vectors. + + + + + + + Specifies for which ions/points the tool will compute distances. + The purpose of this setting is to avoid unnecessary computations + when the user requests to only compute distances of ions within a + threshold distance to the triangle soup. + + By default the distances are computed for all ions; however + the setting skin enables to compute distances only for those + ions which are not farther away located to a triangle + than threshold_distance. + + + + + + + + + + Maximum distance for which distances are computed when method is skin. + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml new file mode 100644 index 0000000000..615b3b76ac --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml @@ -0,0 +1,348 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Configuration of a paraprobe-intersector tool run in atom probe microscopy. + + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + ISO 8601 formatted time code with local time zone offset to + UTC information included when this configuration file was created. + + + + + For now a support field for the tool to identify how many individual + analyses the tool should execute as part of the analysis. + + + + + Tracking volume_volume_spatial_correlation is the process of building logical + relations between volumetric features based on meshes, their proximity and + eventual intersections. Volumetric overlap and proximity of volumetric + features is identified for members of sets of features to members of + other sets of volumetric features. + Specifically, for each time step k pairs of sets are compared: + Members of a so-called current_set to members of a so-called next_set. + Members can be different types of volumetric features. + In the analysis of M. Kuehbach et al. specifically features can be + so-called objects (closed non-degnerated polyhedra representing watertight + parts of an e.g. iso-surface) and/or proxies. Proxies are computed + doppelganger/replacement meshes for parts of an iso-surface which initially + were not resulting in watertight meshes because objects at the edge + of the dataset or incompletely measured or truncated objects. + + + + Specifies the method whereby to decide if two objects intersect volumetrically. + For reasons which are detailed in the supplementary material of + `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_, the tool by + default assumes that two objects intersect if they share at least one + ion with the same evaporation ID (shared_ion). + Alternatively, with specifying tetrahedra_intersections, + the tool can perform an intersection analysis which attempts to + tetrahedralize first each polyhedron. If successful, the tool then checks + for at least one pair of intersecting tetrahedra to identify if two objects + intersect or not. + + However, we found that these geometrical analyses can result in corner + cases which the currently used library (TetGen) was not unable to + tetrahedralize successfully. These cases were virtually always + associated with complicated non-convex polyhedra which had portions + of the mesh that were connected by almost point like tubes of triangles. + Finding more robust methods for computing intersections between + not necessarily convex polyhedra might improve the situation in the future. + + + + + + + + Specifies if the tool evaluates if for each pair the two objects + (and proxies if used) intersect volumetrically. + + + + + Specifies if the tool evaluates if for each pair the two objects + (and proxies if used) lie closer to one another than the + threshold_proximity. + + + + + Specifies if the tool evaluates, ones all tracking tasks were + successfully completed, how intersecting or proximity related + objects build sub-graphs. This is the feature which enabled + M. Kühbach et al. 2022 the high-throughput analyses of how many + objects are coprecipitates in the sense that they are single, + duplet, triplet, or high-order. For these analyses to work + has_object_volume needs to be activated. + + + + + The maximum Euclidean distance between two objects below which + both objects are still considered within proximity. + + + + + + Specifies if the tool stores the so-called forward relations between + nodes representing members of the current_set to nodes representing + members of the next_set. + + + + + Specifies if the tool stores the so-called backward relations between + nodes representing members of the next_set to nodes representing + members of the current_set. + + + + + Current set stores a set of members, meshes of volumetric features, + which will be checked for proximity and/or volumetric intersection, + to members of the current_set. + The meshes were generated as a result of some other meshing process. + + + + This identifier can be used to label the current set. The label + effectively represents (can be interpreted as) the time/iteration + step when the current set was taken. As it is detailed in `M. Kühbach + et al. 2022 <https://arxiv.org/abs/2205.13510>`_, this identifier + takes the role of the time variable :math:`k`. + + + + + + The total number of distinguished feature sets FEATURE. + It is assumed that the members within all these FEATURE sets + are representing a set together. As an example this set might represent + all volumetric_features. However, users might have formed + a subset of this set where individuals were regrouped. + For paraprobe-nanochem this is the case for objects and proxies. + Specifically, objects are distinguished further into those far + from and those close to the edge of the dataset. + Similarly, proxies are distinguished further into those far + from and those close to the edge of the dataset. + So while these four sub-sets contain different so-called types of + features key is that they were all generated for one set, here the + current_set. + + + + + + Descriptive category explaining what these features are. + + + + + + + + + + + Name of the (NeXus)/HDF5 file which contains triangulated + surface meshes of the members of the set as instances of + NXcg_polyhedron_set. + + + + + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + + + + + + String whereby the path to the geometry data can be interferred automatically. + Currently groupname_geometry_prefix/object<ID>/polyhedron. + + + + + Array of identifier whereby the path to the geometry data + can be interferred automatically. + + + + + + + + + + Next set stores a set of members, meshes of volumetric features, + which will be checked for proximity and/or volumetric intersection, + to members of the next_set. + The meshes were generated as a result of some other meshing process. + + + + This identifier can be used to label the next_set. The label + effectively represents (can be interpreted as) the time/iteration + step when the current set was taken. As it is detailed in `M. Kühbach + et al. 2022 <https://arxiv.org/abs/2205.13510>`_, this identifier + takes the role of the time variable :math:`k + 1`. + + + + + + The total number of distinguished feature sets FEATURE. + It is assumed that the members within all these FEATURE sets + are representing a set together. As an example this set might represent + all volumetric_features. However, users might have formed + a subset of this set where individuals were regrouped. + For paraprobe-nanochem this is the case for objects and proxies. + Specifically, objects are distinguished further into those far + from and those close to the edge of the dataset. + Similarly, proxies are distinguished further into those far + from and those close to the edge of the dataset. + So while these four sub-sets contain different so-called types of + features key is that they were all generated for one set, here the + next_set. + + + + + + Descriptive category explaining what these features are. + + + + + + + + + + + Name of the (NeXus)/HDF5 file which contains triangulated + surface meshes of the members of the set as instances of + NXcg_polyhedron_set. + + + + + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + + + + + + String whereby the path to the geometry data can be interferred automatically. + Currently groupname_geometry_prefix/object<ID>/polyhedron. + + + + + Array of identifier whereby the path to the geometry data + can be interferred automatically. + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml new file mode 100644 index 0000000000..ab98e2e98b --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml @@ -0,0 +1,1114 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + How many iontypes does the delocalization filter specify. + + + + + How many disjoint control points are defined. + + + + + How many iontypes does the interface meshing iontype filter specify. + + + + + How many DCOM iterations. + + + + + Maximum number of atoms per molecular ion. + + + + + Configuration of a paraprobe-nanochem tool run in atom probe microscopy. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + ISO 8601 formatted time code with local time zone offset to + UTC information included when this configuration file was created. + + + + + How many individual analyses should the tool execute as part of the analysis. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The tool enables to inject a previously computed triangle soup or + triangulated surface mesh representing a model (of the surface) of + the edge of the dataset. This model can be used to detect and control + various sources of bias in the analyses. + + + + + Name of the HDF5 file which contains vertex coordinates and facet + indices to describe the desired set of triangles which represents + the edge of the dataset. + + + + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + + + + + + Absolute path to the HDF5 dataset in the respectively specified HDF5 + file under filename which details the array of vertex positions. + + + + + Absolute path to the HDF5 dataset in the respective specified HDF5 + file under filename which details the array of facet indices. + + + + + + The tool enables to inject precomputed distance information for each + point/ion which can be used for further post-processing and analysis. + + + + + Name of an HDF5 file which contains the ion distances. + + + + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + + + + + + Absolute HDF5 path to the dataset with distance values for each ion. + + + + + + + + Discretization of the ion point cloud on a three-dimensional grid. + + + + Delocalization in the field of atom probe microscopy is the process + of discretizing a point cloud. By default the tool computes a full + kernel density estimation of decomposed ions to create one discretized + field for each element. + + Although, this uses an efficient multithreaded algorithm, + the computation is costly. Therefore, it can be advantageous for users + to load an already computed delocalization. This can be achieved with + the load_existent option. + When using this option the user is responsible to assure that the + settings which were used for computing this already existent delocalization + are specified in the same manner as they were. + + + + + + + + + + + Matrix of isotope vectors representing iontypes. + The filter specifies a matrix of isotope_vectors which is the most + general approach to define if and how many times an ion is counted. + Currently, paraprobe_nanochem performs a so-called atomic decomposition + of all iontypes. Specifically, the tool interprets of how many + elements/atoms a molecular ion is composed; and thus determines the + atoms multiplicity with respect to the iontype. + + Let's take the hydroxonium H3O+ molecular ion as an example: + It contains hydrogen and oxygen as atoms. The multiplicity of hydrogen + is three whereas that of oxygen is one. Therefore in an atomic + decomposition computation of the iso-surface each H3O+ ion adds + three hydrogen counts. This is a practical solution which accepts + the situation that during an atom probe experiment not each bond + of each ion/a group of neighboring atoms is broken but molecular + ions get detected. The exact ab-initio details depend on the local + field conditions and thus also the detailed spatial arrangement + of the atoms and their own electronic state and that of the neighbors + before and upon launch. + Being able to measure the information for such sites only as + molecular ions causes an inherent information loss with respect to the + detailed spatial arrangement. This information loss is more relevant + for local electrode atom probe than for field ion microscopy setting + how precisely the atomic positions can be reconstructed. + Accounting for multiplicities assures that at least the + compositional information is analyzed. + + + + + + + + + List of individual grid resolutions to analyse. + Paraprobe discretizes on a cuboidal 3D grid with cubic cells, with + an edge length of values in gridresolutions. + + + + + + Half the width of a :math:`{(2 \cdot n + 1)}^3` cubic kernel of voxel + beyond which the Gaussian Ansatz function will be truncated. + Intensity beyond the kernel is refactored into the kernel via + a normalization procedure. + + + + + Variance of the Gaussian Ansatz kernel :math:`\sigma_x = \sigma_y = 2 \cdot + \sigma_z`. + + + + + + How should the results of the kernel-density estimation be computed + into quantities. By default the tool computes the total number + (intensity) of ions or elements. Alternatively the tool can compute + the total intensity, the composition, or the concentration of the + ions/elements specified by the white list of elements in each voxel. + + + + + + + + + + + Specifies if the tool should report the delocalization 3D field values. + + + + + + + Optional computation of iso-surfaces after each computed delocalization + to identify for instance objects in the microstructure + (line features, interfaces, precipitates). + + + + As it is detailed in M. Kühbach et al. 2022 npj Comp. Mat., + the handling of triangles at the edge of the dataset requires + special attention. Especially for composition-normalized + delocalization it is possible that the composition increases + towards the edge of the dataset because the quotient of two numbers + which are both smaller than one is larger instead of smaller than + the counter. By default, the tool uses a modified marching cubes + algorithm of Lewiner et al. which detects if voxels face such a + situation. In this case, no triangles are generated for such voxels. + Alternatively, (via setting keep_edge_triangles) the user can + instruct the tool to not remove these triangles at the cost of bias. + + Specifically, in this case the user should understand that all + objects/microstructural features in contact with the edge of the + dataset get usually artificial enlarged and their surface mesh + often closed during the marching. This closure however is artificial! + It can result in biased shape analyses for those objects. + The reason why this should in general be avoided is a similar + argument as when one analyzes grain shapes in orientation microscopy + via e.g. SEM/EBSD. Namely, these grains, here the objects at the + edge of the dataset, were not fully captured during e.g. limited + field of view. + Therefore, it is questionable if one would like to make + substantiated quantitative statements about them. + + Thanks to collaboration with the V. V. Rielli and S. Primig, though, + paraprobe-nanochem implements a complete pipeline to + process even these objects at the edge of the dataset. Specifically, + the objects are replaced by so-called proxies, i.e. replacement + objects whose holes on the surface mesh have been closed if possible + via iterative mesh and hole-filling procedures with fairing operations. + In the results of each paraprobe-nanochem run, these proxy objects + are listed separately to allow users to quantify and analyze in + detail the differences when accounting for these objects or not. + Especially this is relevant in atom probe microscopy as objects + can contain a few dozen atoms only. + Users should be aware that results from fairing operations should + be compared to results from analyses where all objects at the edge + of the dataset have been removed. + + Also users should be careful with overestimating the statistical + significance of their dataset especially when using atom probe + to compare multiple descriptors: Even though a dataset may give + statistically significant results for compositions, this does not + necessarily mean it will yield also statistically significant + and unbiased results for three-dimensional object analyses. + Being able to quantify these effects and making atom probers + aware of these subtleties was one of the main reasons why the + paraprobe-nanochem tool was implemented. + + + + + + + + + The ion-to-edge-distance that is used in the analyses of objects + (and proxies) to identify whether these are inside the dataset or + close to the edge of the dataset. If an object has at least one ion + with an ion-to-edge-distance below this threshold, the object is + considered as one which lies close to the edge of the dataset. + This implements essentially a distance-based approach to solve + the in general complicated and involved treatment of computing + volumetric intersections between not-necessarily convex + closed 2-manifolds. In fact, such computational geometry analyses + can face numerical robustness issues as a consequence of which a + mesh can be detected as lying completely inside a dataset although + in reality it is epsilon-close only, i.e. almost touching only + the edge (e.g. from inside). + Practically, humans would state in such case that the object is + close to the edge of the dataset; however mathematically the object + is indeed completely inside. + In short, a distance-based approach is rigorous and more flexible. + + + + + + Array of iso-contour values. For each value the tool computes + an iso-surface and performs subsequent analyses. + The unit depends on the choice for the normalization of the + accumulated ion intensity values per voxel: + + * total, total number of ions, irrespective their iontype + * candidates, total number of ions with type in the isotope_whitelist. + * composition, candidates but normalized by composition, i.e. at.-% + * concentration, candidates but normalized by voxel volume, i.e. ions/nm^3 + + + + + + Specifies if the tool should report the triangle soup which represents + each triangle of the iso-surface complex. + Each triangle is reported with an ID specifying to which triangle + cluster (with IDs starting at zero) the triangle belongs. + The clustering is performed with a modified DBScan algorithm. + + + + + Specifies if the tool should analyze for each cluster of triangles + how they can be combinatorially processed to describe a closed + polyhedron. Such a closed polyhedron (not-necessarily convex!) + can be used to describe objects with relevance in the microstructure. + Users should be aware that the resulting mesh does not necessarily + represent the original precipitate. In fact, inaccuracies in the + reconstructed positions cause inaccuracies in all downstream + processing operations. Especially the effect on one-dimensional + spatial statistics like nearest neighbor correlation functions these + effects were discussed in the literature + `B. Gault et al. <https://doi.org/10.1017/S1431927621012952>`_ + In continuation of these thoughts this applies also to reconstructed + objects. A well-known example is the discussion of shape deviations + of Al3Sc precipitates in aluminium alloys which in reconstructions + can appear as ellipsoids although they should be almost spherical, + depending on their size. + + + + + Specifies if the tool should report a triangulated surface mesh + for each identified closed polyhedron. It is common that a + marching cubes algorithm creates iso-surfaces with a fraction of very + small sub-complexes (e.g. small isolated tetrahedra). + + These can be for instance be small tetrahedra/polyhedra about the + center of a voxel of the support grid on which marching cubes operates. + When these objects are small, it is possible that they contain no ion; + especially when considering that delocalization procedures smoothen + the positions of the ions. Although these small objects are interesting + from a numerical point of view, scientists may argue they are not worth + to be reported: + Physically a microstructural feature should contain at least a few + atoms to become relevant. Therefore, paraprobe-nanochem by default + does not report closed objects which bound not at least one ion. + + + + + Specifies if the tool should report properties of each closed + polyhedron, such as volume and other details. + + + + + Specifies if the tool should report for each closed polyhedron an + approximately optimal bounding box fitted to all triangles of the + surface mesh of the object and ion positions inside or on the + surface of the mesh. + This bounding box informs about the closed object's shape + (aspect ratios). + + + + + + Specifies if the tool should report for each closed polyhedron + all evaporation IDs of those ions which lie inside or on the + boundary of the polyhedron. This information can be used e.g. + in the paraprobe-intersector tool to infer if two objects share + common ions, which can be interpreted as an argument to assume + that the two objects intersect. + + Users should be aware that two arbitrarily closed polyhedra + in three-dimensional space can intersect but not share a common ion. + In fact, the volume bounded by the polyhedron has sharp edges. + When taking two objects, an edge of one object may for instance + pierce into the surface of another object. In this case the + objects partially overlap / intersect volumetrically; + however this piercing might be so small or happening in the volume + between two ion positions and thus sharing ions is a sufficient + but not a necessary condition for object intersections. + + Paraprobe-intersector implements a rigorous alternative to handle + such intersections using a tetrahedralization of closed objects. + However, in many practical cases, we found through examples that there + are polyhedra (especially when they are non-convex and have almost + point-like) connected channels, where tetrahedralization libraries + have challenges dealing with. In this case checking intersections + via shared_ions is a more practical alternative. + + + + + Specifies if the tool should report if a (closed) object has + contact with the edge of the dataset. For this the tool currently + inspects if the shortest distance between the set of triangles of the + surface mesh and the triangles of the edge model is larger than the + edge_threshold. If this is the case, the object is assumed to be + deeply embedded in the interior of the dataset. Otherwise, the object + is considered to have an edge contact, i.e. it is likely affected + by the fact that the dataset is finite. + + + + + + Specifies if the tool should analyze a doppelganger/proxy mesh for + each cluster of triangles whose combinatorial analysis according + to has_object showed that the object is not a closed polyhedron. + Such proxies are closed via iterative hole-filling, mesh refinement, + and fairing operations. + Users should be aware that the resulting mesh does not necessarily + represent the original precipitate. In most cases objects, + like precipitates in atom probe end up as open objects because + they have been clipped by the edge of the dataset. Using a proxy is + then a strategy to still be able to account for these objects. + Nevertheless users should make themselves familiar with the + potential consequences and biases which this can introduce + into the analysis. + + + + + Like has_object_geometry but for the proxies. + + + + + Like has_object_properties but for the proxies. + + + + + Like has_object_obb but for the proxies. + + + + + Like has_object_ions but for the proxies. + + + + + Like has_object_edge_contact but for the proxies. + + + + + Specifies if the tool should report for each closed object a + (cylindrical) region of interest placed, centered, and align + with the local normal for each triangle of the object. + + + + + Specifies if the tool should report for each ROI that was placed + at a triangle of each object if this ROI intersects the edge of + the dataset. Currently paraprobe-nanochem supports cylindrical + ROIs. A possible intersection of these with the edge of the + dataset, i.e. the triangulated surface mesh model for the edge + is performed. This test checks if the cylinder intersects with + a triangle of the surface mesh. If this is the case, the ROI is + assumed to make edge contact, else, the ROI is assumed to have + no edge contact. + + This approach does not work if the ROI would be completely + outside the dataset. Also in this case there would be + no intersection. For atom probe this case is practically + irrelevant because for such a ROI there would also be no ion + laying inside the ROI. Clearly it has thus to be assumed that + the edge model culls the entire dataset. Instead, if one would + cut a portion of the dataset, compute an edge model for this + point cloud, it might make sense to place a ROI but in this + case the edge contact detection is not expected to work properly. + + + + + + + Analyses of interfacial excess. + + + + Interfacial excess computations are performed for local regions-of-interests + (ROIs) at selected facets or interface patch. + For instance many scientist compute the interfacial excess for + selected triangle facets of a created iso-surface. In this case, + computed iso-surfaces of paraprobe could be used. An example are triangle + facet sets about closed polyhedra, for instance to compute interfacial + excess related to phase boundaries of second-phase precipitates. + + Another example are free-standing triangle patches of the iso- + surfaces which paraprobe creates. These could be characterized + for interfacial excess. The sub-routines during iso-surface + computations already include a procedure to automatically align + local triangle normals based on the gradients of e.g. composition + fields. In this case, these triangulated surface patches + could also be used as a source for computing interfacial + excess. + + Often scientists face situations, though, in which there is no + immediately evident composition gradient across the interface + (grain or phase boundary) and orientation information about the + adjoining crystal is neither available nor reliable enough. + + In this case `P. Felfer et al. <https://doi.org/10.1016/j.ultramic.2015.06.002>`_ proposed a method + to manually place control points and run an automated tessellation-based + algorithm to create a triangulated surface patch, i.e. a model of the + location of the interface. In a post-processing step this triangle + set can then be used to compute again interfacial excess in an + automated manner by placing ROIs and aligning them with + consistently precomputed triangle normals. + + A similar use case is conceptually the one proposed by `X. Zhou et al. <https://doi.org/10.1016/j.actamat.2022.117633>`_ + They used first a deep-learning method to locate planar triangulated + grain boundary patches. These are eventually processed further + with manual editing of the mesh via tools like Blender. + Once the user is satisfied with the mesh, the computations of interfacial + excess reduce again to an automated placing of ROIs, computations + of the distributing of ions to respective ROIs and + reporting the findings via plotting. + + Yet another approach for constructing an triangulated surface patch + of an interface is to use point cloud processing methods which have + been proposed in the laser-scanning, geoinformatics, and CAD community. + Different computational geometry methods are available for fitting + a parameterized surface to a set of points, using e.g. non-uniform + rational B-splines (NURBS) and triangulating these according + to prescribed mesh quality demands. + + The advantage of these methods is that they can be automated and + pick up curved interface segments. The disadvantage is their often + strong sensitivity to parameterization. As a result also such methods + can be post-processed to yield a triangulated surface patch, + and thus enable to run again automated ROI placement methods. + For example like these which were explored for the use case of + iso-surfaces with closed objects and free-standing + surface patches that delineate regions of the dataset with a + pronounced composition gradient normal to the interface. + + This summary of the situations which atom probers can face when + requesting for interfacial excess computations, substantiates there + exists a common set of settings which can describe all of these methods + and, specifically, as here exemplified, the automated placing + and alignment functionalities for ROIs that is an important + step all these workflows. + + Specifically, paraprobe-nanochem operates on an already existent + triangle set. + + + + + + + + + + The interface model is the result of a previous (set of) processing + steps as a result of which the user has created a triangulated + surface mesh (or a set of, eventually connected such meshes). + These interface models are useful, if not required, in cases when + there is no other independent approach to locate an interface. + + These are cases when insufficient crystallographic latent + information is available and also no consistent concentration + gradient detectable across the interface. It is then the users' + responsibility to deliver a triangle mesh of the interface model. + + + + Filename to HDF5 file which contain vertex coordinates, facet indices, + facet unit normals. The user is responsible for the triangle + and winding order to be consistent. + Input is expected as a matrix of the coordinates for all disjoint + vertices, a (Nvertices, 3)-shaped array of NX_FLOAT. + Input is expected to include also a matrix of facet indices + referring to these disjoint vertices. This matrix should be a + (Nfacets, 3)-shaped array of NX_UINT. Further required input + is a (Nfacets, 3)-shaped array of NX_FLOAT signed facet unit + normals and a (Nvertices, 3)-shaped array of NX_FLOAT signed + vertex unit normals. Vertex indices need to start at zero and + must not exceed Nvertices - 1, i.e. the identifier_offset is 0 + and facet indices are indexed implicitly, i.e. [0, Nvertices-1]. + + + + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional + layer of reproducibility from which file specifically + contains these data. + + + + + + Absolute HDF5 path to the dataset which specifies the + array of vertex positions. + + + + + Absolute HDF5 path to the dataset which specifies the + array of facet indices. + + + + + Absolute HDF5 path to the dataset which specifies the + array of facet signed unit normals. + + + + + Absolute HDF5 path to the dataset which specifies the + array of vertex signed unit normals. + + Users should be aware that triangulated surface meshes are + only approximations to a given complex, eventually curved shape. + Consequently, computations of normals show differences between + the vertex and facet normals. Vertex normals have to be + interpolated from normals of neighboring facets. Consequently, + these normals are affected by the underlying parameterization + and curvature estimation algorithms, irrespective of how + contributions from neighboring facets are weighted. By contrast, + facet normals are clearly defined by the associated triangle. + Their disadvantage is that they the normal field has discontinuities + at the edges. In general the coarser an object is triangulated + the more significant the difference becomes between computations + based on facet or vertex normals. + Paraprobe-nanochem works with facet normals as it can use + parts of the numerical performance gained by using cutting + edge libraries to work rather with finer meshes. + + + + + + + + Create a simple principle component analysis (PCA) to mesh a + free-standing interface patch through a point cloud of decorating solutes. + These models can be useful for quantification of Gibbsian + interfacial excess for interfaces where iso-surface based methods + may fail or closed objects from iso-surfaces are not desired or + when e.g. there are no substantial or consistently oriented + concentration gradients across the interface patch. + + The interface_meshing functionality of paraprobe-nanochem can be useful + when there is also insufficient latent crystallographic information + available that could otherwise support modelling the interface, + via e.g. ion density traces in field-desorption maps, as were used and + discussed by `Y. Wei et al. <https://doi.org/10.1371/journal.pone.0225041>`_ + or are discussed by `A. Breen et al. <https://github.com/breen-aj/detector>`_ + + It is noteworthy that the method here used is conceptually very similar + in implementation to the work by `Z. Peng et al. <https://doi.org/10.1017/S1431927618016112>`_ + Noteworthy, her team uses the DCOM approach originally proposed by P. Felfer et al. + However, both of these previous works neither discuss in detail + nor implement inspection functionalities which enable a detection of + potential geometric inconsistencies or self-interactions of the + resulting DCOM mesh. This is what paraprobe-nanochem implements + via the Computational Geometry Algorithms Library. + + + + Method how to initialize the PCA: + + * default, means based on segregated solutes in the ROI + * control_point_file, means based on reading an external list of + control points, currently coming from the Leoben APT_Analyzer. + + The control_point_file is currently expected with a specific format. + The Leoben group lead by L. Romaner has developed a GUI tool `A. Reichmann et al. <https://github.com/areichm/APT_analyzer>`_ + to create a control_point_file which can be parsed by paraprobe-parmsetup + to match the here required formatting in control_points. + + + + + + + + + The name of the control point file to use. + + + + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional + layer of reproducibility from which file specifically + contains these data. + + + + + + X, Y, Z coordinates of disjoint control point read from + an HDF5 file named according to control_point_file. + + + + + + + + + + Method used for identifying and refining the location of the + interface. Currently, paraprobe-nanochem implements a PCA followed + by an iterative loop of isotropic mesh refinement and DCOM step(s), + paired with self-intersection detection in a more robust + implementation. + + + + + + + + Specify the types of those ions which decorate the interface and + can thus be assumed as markers for locating the interface and + refining its local curvature. + + + + Array of iontypes to filter. The list is interpreted as a whitelist, + i.e. ions of these types are considered the decorating species (solutes). + + + + + + + + + How many times should the DCOM and mesh refinement be applied? + + + + + Array of decreasing positive not smaller than one nanometer real values + which specify how the initial triangles of the mesh should be iteratively + refined by edge splitting and related mesh refinement operations. + + + + + + + + + Array of decreasing positive not smaller than one nanometer real values + which specify the radius of the spherical region of interest within + which the DCOM algorithm decides for each vertex how the vertex will + be eventually relocated. The larger the DCOM radius is relative to + the target_edge_length the more likely it is that vertices will be + relocated so substantially that eventually triangle self-intersections + can occur. If the code detects these it warns and stops in a + controlled manner so that the user can repeat the analyses + with a smaller value. + + + + + + + + + Array of integers which specify for each DCOM step how many times + the mesh should be iteratively smoothened. + + Users should be aware the three array target_edge_length, + target_dcom_radius, and target_smoothing_step are interpreted in the + same sequence, i.e. the zeroth entry of each array specifies the + values to be used in the first DCOM iteration. The first entry of + each array those for the second DCOM iteration and so on and so forth. + + + + + + + + + Functionalities for placing regions-of-interest (ROIs) in the dataset + or at specific microstructural features to characterize composition + profiles and cumulated profiles for quantification of interfacial excess. + Paraprobe-nanochem currently places cylindrical ROIs. ROIs are probed + across the triangulated surface of a user-defined mesh. + ROIs are placed at the barycenter of the triangular facet. + + The tool can be instructed to orient the profile for each ROIs with + the positive normal of the triangle facet normals. Profiles are + computed for each ROI and facet triangle. The code will test which + ROIs are completely embedded in the dataset. + Specifically, in this test the tool evaluates if the ROI cuts at least + one triangle of the triangulated surface mesh of the edge of the dataset. + If this is the case the ROI will be considered close to the edge + (of the dataset) and not analyzed further; else the ROI will be + processed further. + Users should be aware that the latter intersection analysis is strictly + speaking not a volumetric intersection analysis as such one is much + more involved because the edge model can be a closed non-convex polyhedron + in which case one would have to test robustly if the cylinder pierces + or is laying completely inside the polyhedron. For this the polyhedron has + to be tessellated into convex polyhedra as otherwise tests like the + Gilbert-Johnson-Keerthi algorithm would not be applicable. + + Specifically, the tool computes atomically decomposed profiles. + This means molecular ions are split into atoms/isotopes with respective + multiplicity. As an example an H3O+ molecular ion contains three + hydrogen and one oxygen atom respectively. The tool then evaluates + how many ions are located inside the ROI or on the surface of the + ROI respectively. All atom types and the unranged ions are distinguished. + As a result, the analyses yield for each ROI a set of sorted lists of + signed distance values. Currently, the distance is the projected + distance of the ion position to the barycenter of the triangle + and triangle plane. + + This will return a one-dimensional profile. Post-processing the set + of atom-type-specific profiles into cumulated profiles enable the + classical Krakauer/Seidman-style interfacial excess analyses. + Furthermore, the tool can be instructed to compute for each + (or a selected sub-set of facet) a set of differently oriented profiles. + + + + + The feature mesh enables the injection of previously computed triangle + soup or mesh data. Such a mesh can be the model for a grain- or phase + boundary patch (from e.g. interface_meshing) jobs. + + + + Name of the HDF5 file which contains vertex coordinates and facet + indices to describe the desired set of triangles which represents + the feature. + + + + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + + + + + + Absolute path to the HDF5 dataset in the respectively specified HDF5 + file under filename which details the array of vertex positions. + + + + + Absolute path to the HDF5 dataset in the respective specified HDF5 + file under filename which details the array of facet indices. + + + + + Absolute path to the HDF5 dataset in the respective specified HDF5 + file under filename which details consistently oriented facet + normals of the facets. + + + + + + + + + + + The tool enables to inject precomputed distance information for each + point which can be used for further post-processing and analysis. + + + + + Name of an HDF5 file which contains ion distances. + + + + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional + layer of reproducibility from which file specifically contains + these data. + + + + + + Absolute HDF5 path to the dataset with distance values for each ion. + + + + + + Which type of distance should be reported for the profile. + + + + + + + + + In which directions should the tool probe for each ROI. + + + + + + + + + For each ROI, how high (projected on the cylinder axis) + should the cylindrical ROI be. + + + + + + For each ROI, how wide (radius) should the cylindrical ROI be. + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml new file mode 100644 index 0000000000..f832bf02b7 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml @@ -0,0 +1,297 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The number of isotopes to consider as building blocks for searching molecular + ions. + + + + + The number of compositions to consider for molecular ion search tasks. + + + + + Configuration of a paraprobe-ranger tool run in atom probe microscopy. + + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + How many task to perform? + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A list of pairs of number of protons and either the value 0 (per row) + or the mass number for all those isotopes which are assumed present + in a virtual specimen. + The purpose of this field is to compute also composition-weighted + products to yield a simple estimation which could potentially help + scientists to judge if certain molecular ions are to be expected. + The corresponding setting store_composition_weighted_product should be + activated. + + + + + + + + + + A list of pairs of number of protons and mass number for all isotopes + to consider that can be composed into (molecular) ions, during the + recursive molecular_ion_search. + + + + + + + + + The mass-to-charge-state ratio interval in which + all molecular ions are searched. + + + + + + + + The maximum charge that a molecular ion should have. + + + + + The maximum number of isotopes of which the molecular ion + should be composed. Currently this must not be larger than 32. + + Users should be warned that the larger the maximum_charge and + especially the larger the maximum_number_of_isotopes is chosen, + the eventually orders of magnitude more costly the search becomes. + + This is because paraprobe-ranger computes really all (at least) + theoretically possible combinations that would have likely a + mass-to-charge-state ratio in the specified mass_to_charge_interval. + It is the challenge in atom probe to judge which of these (molecular) + ions are feasible and also practically possible. This tool does not + answer this question. + + Namely, which specific molecular ion will evaporate, remain stable + during flight and becomes detected is a complicated and in many cases + not yet in detail understood phenomenon. The ab-initio conditions + before and during launch, the local environment, arrangement and field + as well as the flight phase in an evacuated but not analysis chamber + with a complex electrical field, eventual laser pulsing in place, + temperature and remaining atoms or molecules all can have an effect + which iontypes are really physically evaporating and detected. + + + + + Report the accumulated atomic mass from each isotope building the ion. + Accounts for each identified ion. + Relatistic effects are not accounted for. + + + + + Report the product of the natural abundances from each isotope building + the ion. Accounts for each identified ion. + + The value zero indicates it is not possible to build such molecular ion + from nuclids which are all observationally stable. + Very small values can give an idea/about how likely such a molecular ion + is expected to form assuming equal probabilities. + + However in atom probe experiments this product has to be modified + by the (spatially-correlated) local composition in the region from + which the ions launch because the formation of a molecular ion depends + as summarized under maximum_number_of_isotopes on the specific + quantum-mechanical configuration and field state upon launch + or/and (early state) of flight respectively. + We are aware that this modified product can have a substantially + different value than the natural_abundance_product. + + Natural abundancies folded with the estimated compositions of the + specimen can differ by orders of magnitude. + + + + + + Report the charge state of the ions. + + + + + Report if identified ions should be characterized + wrt to their number of disjoint isotopes. + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_selector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_selector.nxdl.xml new file mode 100644 index 0000000000..1293fb98d6 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_config_selector.nxdl.xml @@ -0,0 +1,142 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Configuration of a paraprobe-selector tool run in atom probe microscopy. + + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + How many roi_selection processes should the tool execute. + + + + + This process identifies which of the points/ions in the datasets are + inside or on the surface of geometric primitives and meet optionally + specific other filtering constraints. + A typical use case of a roi_selection is to restrict analyses to + specific regions of the dataset, eventually regions with a complicated + shape. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml new file mode 100644 index 0000000000..d886dc0da8 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml @@ -0,0 +1,374 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Maximum number of atoms per molecular ion. Should be 32 for paraprobe. + + + + + Number of different sources iontypes to distinguish. + + + + + Number of different target iontypes to distinguish. + + + + + Configuration of a paraprobe-spatstat tool run in atom probe microscopy. + + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + How many range_with_existent_iontypes processes should + the tool execute as part of the analysis. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The tool enables to inject precomputed distances of each ion to a + representation of the edge of the dataset which can be used to + control and substantially reduce edge effects when computing + spatial statistics. + + + + Name of an HDF5 file which contains ion-to-edge distances. + + + + + Absolute HDF5 path to the dataset with the + ion-to-edge distance values for each ion. + The shape of the distance values has to match the length + of the ion positions array in dataset/dataset_name_reconstruction + and dataset_name_mass_to_charge respectively. + + + + + Threshold to define how large an ion has to lay at least far away + from the edge of the dataset so that the ion can act as a source, + i.e. that an ROI is placed at the location of the ion and its + neighbors are analyzed how they contribute to the computed statistics. + + The ion_to_edge_distances threshold can be combined with a threshold + for the ion_to_feature_distances. + Specifically, if ion_to_feature_distances are loaded an ion only + acts as a source if both threshold criteria are met. + + The threshold is useful to process the dataset such that ROIs do + not protrude out of the dataset as this would add bias. + + + + + + In addition to spatial filtering, and considering how far ions lie + to the edge of the dataset, it is possible to restrict the analyses + to a sub-set of ions within a distance not farther away to a feature than + a threshold value. + + + + Name of an HDF5 file which contains ion-to-feature distances. + + + + + Absolute HDF5 path to the dataset with the + ion-to-feature distance values for each ion. + + + + + Threshold to define how close an ion has to lay to a feature so that + the ion can at all qualify as a source, i.e. that an ROI is placed + at the location of the ion and its neighbors are then analyzed + how they contribute to the computed statistics. + + Recall that the ion_to_feature_distances threshold is combined + with the ion_to_edge_distances threshold. + + + + + + + Specifies if the iontypes are randomized for the point cloud or not. + Internally paraprobe uses a sequentially executed deterministic MT19987 + (MersenneTwister) pseudo-random number generator to shuffle the + iontype labels randomly across the entire set of ions. + + + + + + + + + + How should the iontype be interpreted on the source-side, i.e. + all these ion positions where a regions-of-interest (ROI) around + so-called source ions will be placed. Different options exist + how iontypes are interpreted given an iontype represents + in general a (molecular) ion with different isotopes that have + individually different multiplicity. + + The value resolve_all will set an ion active in the analysis regardless + of which iontype it is. Each active ion is accounted for once. + + The value resolve_unknown will set an ion active when the ion is + of the UNKNOWNTYPE type. Each active ion is accounted for once. + + The value resolve_ion will set an ion active if it is of the specific + iontype, irregardless of its elemental or isotopic details. + Each active ion is counted once. + + The value resolve_element will set an ion active, and most importantly, + account for each as many times as the (molecular) ion contains + atoms of elements in the whitelist ion_query_isotope_vector. + + The value resolve_isotope will set an ion active, and most importantly, + account for each as many times as the (molecular) ion contains + isotopes in the whitelist ion_query_isotope_vector. + + In effect, ion_query_isotope_vector acts as a whitelist to filter + which ions are considered as source ions of the correlation statistics + and how the multiplicity of each ion will be factorized, i.e. how + often it is accounted for. + + + + + + + + + + + + Matrix of isotope vectors, as many as rows as different candidates + for iontypes should be distinguished as possible source iontypes. + In the simplest case, the matrix contains only the proton number + of the element in the row, all other values set to zero. + Combined with ion_query_type_source set to resolve_element this will + recover usual spatial correlation statistics like the 1NN C-C + spatial statistics. + + + + + + + + + Similarly as ion_query_type_source how should iontypes be interpreted + on the target-side, i.e. how many counts will be bookkept for ions + which are neighbors of source ions within or on the surface of each + inspection/ROI about each source ion. + Source ion in the center of the ROI are not accounted for during + counting the summary statistics. + For details about the resolve values consider the explanations in + ion_query_type_source. These account for ion_query_type_target as well. + + + + + + + + + + + + + Matrix of isotope vectors, as many as rows as different candidates for + iontypes to distinguish as possible targets. See additional comments + under ion_query_isotope_vector_source. + + + + + + + + + Specifies which spatial statistics to compute. + + + + Compute k-th nearest neighbour statistics. + + + + Order k. + + + + + Minimum value, increment, and maximum value of the histogram binning. + + + + + + + + + + Compute radial distribution function. + + + + Minimum value, increment, and maximum value of the histogram binning. + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml new file mode 100644 index 0000000000..5f30cc0f2f --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml @@ -0,0 +1,289 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of alpha values (and offset values) to probe. + + + + + How many different match values does the filter specify. + + + + + Configuration of a paraprobe-surfacer tool run in atom probe microscopy. + + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + For now a support field for the tool to identify how many individual + analyses the tool should executed as part of the analysis. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specifies the method that is used to preprocess the point cloud. + The main purpose of this setting is to specify whether the point + cloud should be segmented or not during the preprocessing + to identify which points are more likely lying close to the edge + of the point cloud. These points could be more relevant than the + interior points for certain alpha-shape constructions. + + By default no such filtering is used during pre-processing. + By contrast, the option kuehbach activates a preprocessing + during which a Hoshen-Kopelman percolation analysis is used + to identify which points are closer to the edge of the dataset. + This can reduce the number of points in the alpha-shape + computation and thus improve performance substantially. + Details about the methods are reported in + `M. Kühbach et al. <https://doi.org/10.1038/s41524-020-00486-1>`_. + + + + + + + + + + When using the kuehbach preprocessing, this is the width of the + kernel for identifying which ions are in voxels close to the + edge of the point cloud. + + + + + Specifies which method to use to define the alpha value. + The value convex_hull_naive is the default. This instructs the tool + to use a fast specialized algorithm for computing only the convex + hull. The resulting triangles can be skinny. + + The value convex_hull_refine computes first also a convex_hull_naive + but refines the mesh by triangle flipping and splitting to improve + the quality of the mesh. + + The value smallest_solid instructs the CGAL library to choose a + value which realizes an alpha-shape that is the smallest solid. + + The value cgal_optimal instructs the library to choose a value + which the library considers as an optimal value. Details are + define in the respective section of the CGAL library on 3D alpha + shapes. + + The value set_of_values instructs to compute a list of + alpha-shapes for the specified alpha-values. + + The value set_of_alpha_wrappings instructs the library to generate + a set of so-called alpha wrappings. These are a method + which is similar to alpha shapes but provide additional guarantees + though such as watertightness and proximity constraints on the + resulting wrapping. + + + + + + + + + + + + + + Array of alpha values to use when alpha_value_choice is set_of_values + or when alpha_value_choice is set_of_alpha_wrappings. + + + + + + + + + Array of offset values to use when alpha_value_choice is + set_of_alpha_wrappings. The array of alpha_values and offset_values + define a sequence of (alpha and offset value). + + + + + + + + + Specifies if the tool should compute the set of exterior triangle + facets for each alpha complex (for convex hull, alpha shapes, and wrappings) + + + + + Specifies if the tool should check if the alpha complex of exterior + triangular facets is a closed polyhedron. + + + + + Specifies if the tool should compute all interior tetrahedra + of the alpha complex (currently only for alpha shapes). + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml new file mode 100644 index 0000000000..ca0798c3a8 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml @@ -0,0 +1,253 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Configuration of a paraprobe-tessellator tool run in atom probe microscopy. + + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + How many individual analyses should the tool execute. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The tool enables to inject precomputed distance information for + each point which can be used for further post-processing and analysis. + + + + Name of an HDF5 file which contains the ion distances. + Users are responsible this file and referred to dataset under + dataset_name have an ion_distance value for each ion. + + + + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional layer of + reproducibility. + + + + + + Absolute HDF5 path to the dataset with distance values for each ion. + + + + + + + Specifies for which points the tool will compute the tessellation. + By default, a Voronoi tessellation is computed for all ions in the + filtered point cloud. + + + + + + + + + + Specifies if the tool should report the volume of each cell. + + + + + Specifies if the tool should report the first-order neighbors of each cell. + + + + + Specifies if the tool should report the facets and vertices of each cell. + + + + + Specifies if the tool should report if the cell makes contact with + the tight axis-aligned bounding box about the point cloud. + This can be used to identify if the shape of the cell is affected + by the edge of the dataset or if cells are deeply enough embedded + into the point cloud so that the shape of their cells are not affected + by the presence of the boundary. + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml new file mode 100644 index 0000000000..4d548e5bf7 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml @@ -0,0 +1,119 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Configurations of a paraprobe-transcoder tool run in atom probe microscopy. + + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ideally an ever persistent resource where the source code of the + program and build instructions can be found so that the program can be + configured ideally in such a manner that the result of this computational + process is recreatable deterministically. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + + + + The path and name of the file (technology partner or community format) + from which to read the reconstructed ion positions. Currently, POS, + ePOS, APT files from APSuite, and NXS, i.e. NeXus/HDF5 files + are supported. + + + + + + + + The path and name of the file (technology partner or community format + from which to read the ranging definitions, i.e. how to map mass-to- + charge-state ratios on iontypes. Currently, RRNG, RNG, and NXS, i.e. + NeXus/HDF5 files are supported. + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_results_clusterer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_clusterer.nxdl.xml new file mode 100644 index 0000000000..eb89794977 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_results_clusterer.nxdl.xml @@ -0,0 +1,503 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + The total number of entries in the restricted_identifier dictionary. + + + + + Results of a paraprobe-clusterer tool run. + + + + + + Version specifier of this application definition. + + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + + + + + The absolute path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must no longer compute analyses. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases, it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + If nothing else is specified we assume that there + has to be at least one set of NXtransformations named + paraprobe defined, which specifies the coordinate system. + In which all positions are defined. + + + + + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + + A bitmask which identifies which of the ions in the dataset were + analyzed during this process. + + + + Number of ions covered by the mask. + The mask value for most may be 0. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used, padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe-toolbox executable. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth (padding). + + + + + + + + + The result of a cluster analyses. These include typically the label for + each ion/point documenting to which feature (if any) an ion is assigned. + Typically, each analysis/run yields only a single cluster. + In cases of fuzzy clustering it can be possible that an ion is assigned + to multiple cluster (eventually with different) weight/probability. + + + + Results of a DBScan clustering analysis. + + + + The epsilon (eps) parameter. + + + + + The minimum points (min_pts) parameter. + + + + + Number of members in the set which is partitioned into features. + Specifically, this is the total number of targets filtered from the + dataset. Cardinality here is not the total number of ions in the + dataset. + + + + + + Which identifier is the first to be used to label a cluster. + + The value should be chosen in such a way that special values can be resolved: + * identifier_offset-1 indicates an object belongs to no cluster. + * identifier_offset-2 indicates an object belongs to the noise category. + Setting for instance identifier_offset to 1 recovers the commonly used + case that objects of the noise category get values to -1 and unassigned points to 0. + Numerical identifier have to be strictly increasing. + + + + + + The evaporation sequence identifier to figure out which ions + from the reconstruction were considered targets. + + + + + + + + + The raw labels from the DBScan clustering backend process. + + + + + + + + The raw array of core sample indices which specify which of the + targets are core points. + + + + + + + + + Matrix of numerical label for each member in the set. + For classical clustering algorithms this can for instance + encode the cluster_identifier. + + + + + + + + + The array of weight which specifies how surely/likely the + cluster is associated/assigned to a specific identifier as + is specified in the cluster_identifier array. + For the DBScan and atom probe tomography the multiplicity + of each ion with respect to the cluster. That is how many times + should the position of the ion be accounted for because the ion + is e.g. a molecular ion with several elements or isotope of + requested type. + + + + + + + + Optional bitmask encoding if members of the set are assigned to as noise or not. + + + + + + + + Optional bitmask encoding if member of the set are a core point. + For details to which feature/cluster an ion/point is a core point + consider numerical_label. + + + + + + + + In addition to the detailed storage which members was grouped to + which feature/group summary statistics are stored under this group. + + + + + Total number of members in the set which are categorized as noise. + + + + + + Total number of members in the set which are categorized as a core point. + + + + + + Total number of clusters (excluding noise and unassigned). + + + + + Array of numerical identifier of each feature (cluster). + + + + + + + + Array of number of members for each feature. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml new file mode 100644 index 0000000000..54ad4dccaf --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml @@ -0,0 +1,388 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + The total number of triangles in the set. + + + + + Results of a paraprobe-distancer tool run. + + + + + + Version specifier of this application definition. + + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + + + + + The absolute path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + + + + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + + The tool can be used to compute the analytical distance of each ion + to a set of triangles. + + + + A bitmask which identifies which of the ions in the dataset were + analyzed. + + + + Number of ions covered by the mask. + The mask value for most may be 0. + + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + A bitmask which identifies which of the triangles in the set + were considered. Usually these are all but sometimes users may + wish to filter certain portions of the triangles out. + If window_triangles is not provided it means that + all triangles were taken. + + + + Number of triangles covered by the mask. + The mask value for most may be 0. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + The closest analytical distance of the ions to their respectively + closest triangle from the triangle set. + + + + + + + + A bitmask which identifies which of the distance values + can be assumed to have a consistent sign because the closest + triangle had a consistent outer unit normal defined. + For points whose bit is set 0 the distance is correct but the + sign is not reliable. + + + + Number of triangles covered by the mask. + The mask value for most may be 0. + + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. + + + + + + + + + The identifier of the triangle that is closest for each ion. + + + + + + + + A support field to visualize each ion and with this the distance + informations using XDMF and e.g. Paraview. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_results_intersector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_intersector.nxdl.xml new file mode 100644 index 0000000000..1c60505c7e --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_results_intersector.nxdl.xml @@ -0,0 +1,395 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of links pointing from current to next. + + + + + The total number of links pointing from next to current. + + + + + The total number of members in the current_set. + + + + + The total number of members in the next_set. + + + + + The total number of cluster found for coprecipitation analysis. + + + + + The number of rows in the table/matrix for coprecipitation stats. + + + + + Results of a paraprobe-intersector tool run. + + + + + + Version specifier of this application definition. + + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + + + + + The absolute path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + + + + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + + The results of an overlap/intersection analysis. + + + + A matrix of feature_identifier which specifies which named features + from the current set have directed link(s) pointing to which named + feature(s) from the next set. + + + + + + + + + For each link/pair in current_to_next a characterization + whether the link is due to a volumetric overlap (0x00 == 0), + proximity (0x01 == 1), or something else unknown (0xFF == 255). + + + + + + + + A matrix of feature_identifier which specifies which named feature(s) + from the next set have directed link(s) pointing to which named + feature(s) from the current set. Only if the mapping whereby the + links is symmetric next_to_current maps the links in current_to_next + in the opposite direction. + + + + + + + + + For each link/pair in next_to_current a characterization + whether the link is due to a volumetric overlap (0x00 == 0), + proximity (0x01 == 1), or something else unknown (0xFF == 255). + + + + + + + + For each pair of links in current_to_next the volume of the + intersection, i.e. how much volume do the two features share. + If features do not intersect the volume is zero. + + + + + + + + During coprecipitation analysis the current and next set are analyzed + for links in a special way. Three set comparisons are made. Members + of the set in each comparison are analyzed for overlap and proximity: + + The first comparison is the current_set against the current_set. + The second comparison is the next_set against the next_set. + The third comparison is the current_set against the next_set. + + Once the (forward) links for these comparisons are ready the + pair relations are analyzed with respect to which feature identifier + cluster in identifier space. Thereby a logical connection (link) is + established between the features in the current_set and next_set. + Recall that these two set typically represent different features + within an observed system for otherwise the same parameterization. + Examples include two sets of e.g. precipitates with differing + chemical composition that were characterized in the same material + volume representing a snapshot of an e.g. microstructure at the same + point in time. Researchers may have performed two analyses, one to + characterize precipitates A and another one to characterize percipitates + B. Coprecipitation analysis now logically connects these independent + characterization results to establish spatial correlations of e.g. + precipitates spatial arrangement. + + + + Matrix of feature_identifier and cluster_identifier pairs which + encodes the cluster to which each feature_identifier was assigned. + Here for features of the current_set. + + + + + + + + + Matrix of feature_identifier and cluster_identifier pairs which + encodes the cluster to which each feature_identifier was assigned. + Here for features of the next_set. + + + + + + + + + The identifier (names) of the cluster. + + + + + + + + Pivot table as a matrix. The first column encodes how many + members from the current_set are in each cluster, one row per cluster. + The second column encodes how many members from the next_set are + in each cluster, in the same row per cluster respectively. + The last column encodes the total number of members in the cluster. + + + + + + + + + Pivot table as a matrix. The first column encodes the different + types of clusters based on their number of members in the sub-graph. + The second column encodes how many clusters with as many members + exist. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml new file mode 100644 index 0000000000..aae16541ee --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml @@ -0,0 +1,1965 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + The total number of atoms in the atomic_decomposition match filter. + + + + + The total number of isotopes in the isotopic_decomposition match filter. + + + + + The dimensionality of the delocalization grid. + + + + + The cardinality/total number of cells/grid points in the delocalization grid. + + + + + + The total number of XDMF values to represent all faces of triangles via XDMF. + + + + + The total number of entries in a feature dictionary. + + + + + The total number of member distinguished when reporting composition. + + + + + Results of a paraprobe-nanochem tool run. + + + + + + Version specifier of this application definition. + + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + + + + + The absolute path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must no longer compute analyses. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases, it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + If nothing else is specified we assume that there + has to be at least one set of NXtransformations named + paraprobe defined, which specifies the coordinate system. + In which all positions are defined. + + + + + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + + A bitmask which identifies which of the ions in the dataset were + analyzed during this process. + + + + Number of ions covered by the mask. + The mask value for most may be 0. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used, padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe-toolbox executable. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth (padding). + + + + + + + + + + + The weighting model specifies how mark data are mapped to a weight + per point/ion. For atom probe microscopy (APM) mark data are e.g. + which iontype an ion has. As an example, different models are used + which account differently for the multiplicity of a point/ion + during delocalization: + + * unity, all points/ions get the same weight 1. + * atomic_decomposition, points get as much weight as they + have atoms of a type in atomic_decomposition_rule, + * isotope_decomposition, points get as much weight as they have + isotopes of a type in isotopic_decomposition_rule. + + + + + + + + + + + A list of elements (via proton number) to consider for the + atomic_decomposition weighting model. + Elements must exist in the periodic table of elements and be + specified by their number of protons. + Values in match are isotope hash values using the following + hashing rule $H = Z + 256*N$ with $Z$ the number of protons + and $N$ the number of neutrons of the isotope. + In the case of elements this hashing rule has the advantage + that for elements the proton number is their hash value because + N is zero. + + + + Meaning of the filter: + Whitelist specifies which entries with said value to include. + Entries with all other values will be filtered out. + + Blacklist specifies which entries with said value to exclude. + Entries with all other values will be included. + + + + + + + + + Array of values to filter according to method. For example, + if the filter specifies [1, 5, 6] and method is whitelist, + only entries with values matching 1, 5 or 6 will be processed. + All other entries will be filtered out/not considered. + + + + + + + + + A list of isotopes (via proton and neutron number) to consider + for the isotopic_decomposition weighting model. + Isotopes must exist in the nuclid table. + Values in match are isotope hash values using the following + hashing rule $H = Z + 256*N$ with $Z$ the number of protons + and $N$ the number of neutrons of the isotope. + + + + Meaning of the filter: + Whitelist specifies which entries with said value to include. + Entries with all other values will be filtered out. + + Blacklist specifies which entries with said value to exclude. + Entries with all other values will be included. + + + + + + + + + Array of values to filter according to method. For example, + if the filter specifies [1, 5, 6] and method is whitelist, + only entries with values matching 1, 5 or 6 will be processed. + All other entries will be filtered out/not considered. + + + + + + + + + How results of the kernel-density estimation were computed + into quantities. By default the tool computes the total number + (intensity) of ions or elements. Alternatively the tool can compute + the total intensity, the composition, or the concentration of the + ions/elements specified by the white list of elements in each voxel. + + + + + + + + + + + Weighting factor, in atom probe, often termed multiplicity. + The weighting factor is the multiplier with which the integrated + intensity contribution from the point/ion gets multiplied. + The delocalization computes the integrated intensity for each + grid cell. Effectively, this is an explicitly evaluated kernel + method where each specific position of an ion is replaced by a + smoothing kernel. For atom probe weights are positive and integer + specifically the multiplicity of the ion, in accordance with the + respective rulesets as defined by weighting_model. + + + + + + + + The discretized domain/grid on which the delocalization is applied. + + + + + + + + + + + The total number of cells/voxels of the grid. + + + + + + + + + + The symmetry of the lattice defining the shape of the unit cell. + + + + + + + + The unit cell dimensions according to the coordinate system + defined under coordinate_system. + + + + + + + + Number of unit cells along each of the d unit vectors. + The total number of cells, or grid points has to be the cardinality. + If the grid has an irregular number of grid positions in each direction, + as it could be for instance the case of a grid where all grid points + outside some masking primitive are removed, this extent field should + not be used. Instead use the coordinate field. + + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + If the coordinate system is not specified the paraprobe + coordinate system is used. + + + + + + Integer which specifies the first index to be used for + distinguishing identifiers for cells. Identifiers are defined + either implicitly or explicitly. For implicit indexing the + identifiers are defined on the interval + [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + + + + A tight axis-aligned bounding box about the grid. + + + + For atom probe should be set to true. + + + + + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + + + + Positions of the vertices. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + + + + + + + + + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + + + + + + + + + Six equally formatted sextets chained together. For each + sextett the first entry is an XDMF primitive topology + key (here 5 for polygon), the second entry the XDMF primitive + count value (here 4 because each face is a quad). + The remaining four values are the vertex indices. + + + + + + + + How many distinct boundaries are distinguished? + Most grids discretize a cubic or cuboidal region. In this case + six sides can be distinguished, each making an own boundary. + + + + + + Name of the boundaries. E.g. left, right, front, back, bottom, top, + The field must have as many entries as there are number_of_boundaries. + + + + + + + + The boundary conditions for each boundary: + + 0 - undefined + 1 - open + 2 - periodic + 3 - mirror + 4 - von Neumann + 5 - Dirichlet + + + + + + + + + + The result of the delocalization based on which subsequent + iso-surfaces will be computed. In commercial software so far + there is not a possibility to export such grid. + + + + + + + + + + + + + + + + + + Cell center of mass positions along x. + + + + + + + + + Cell center of mass positions along y. + + + + + + + + Cell center of mass positions along z. + + + + + + + + Intensity of the field at given point + + + + + + + + Center of mass positions of each voxel for + rendering the scalar field via XDMF in e.g. + Paraview. + + + + + + + + + XDMF topology for rendering in combination with + xdmf_xyz the scalar field via XDFM in e.g. Paraview. + + + + + + + + + The three-dimensional gradient nabla operator applied to + scalar_field_magnitude. + + + + + + + + + + + + + + + + + + + + Cell center of mass positions along x. + + + + + + + + + Cell center of mass positions along y. + + + + + + + + Cell center of mass positions along z. + + + + + + + + The gradient vector. + + + + + + + + + Center of mass positions of each voxel for + rendering the scalar field via XDMF in e.g. + Paraview. + + + + + + + + + XDMF topology for rendering in combination with + xdmf_xyz the scalar field via XDFM in e.g. Paraview. + + + + + + + + + Halfwidth of the kernel about the central voxel. + The shape of the kernel is that of a cuboid + of extent 2*kernel_extent[i] + 1 in each dimension i. + + + + + + + + + + Sigma of the kernel in each dimension in the paraprobe + coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. + + + + + + + + Expectation value of the kernel in each dimension in the paraprobe + coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. + + + + + + + + + + An iso-surface is the boundary between two regions across which + the magnitude of a scalar field falls below/exceeds a threshold + magnitude phi. + For applications in atom probe microscopy the location and shape + of such a boundary (set) is typically approximated by + discretization. + This yields a complex of not necessarily connected geometric + primitives. Paraprobe-nanochem approximates this complex with + a soup of triangles. + + + + + The threshold or iso-contour value. + + + + + Details about the specific marching cubes algorithm + which was taken to compute the iso-surface. + The grid is the delocalization grid. + + + + Reference to the specific implementation of marching cubes used. + The value placed here should be a DOI. If there are no specific + DOI or details write not_further_specified, or give at least a + free-text description. The program and version used is the + specific paraprobe-nanochem. + + + + + + The resulting triangle soup computed via marching cubes. + + + + + + Integer which specifies the first index to be used for + distinguishing triangles. Identifiers are defined either + implicitly or explicitly. For implicit indexing the + identifiers are defined on the interval + [identifier_offset, identifier_offset+c-1]. + + + + + + Number of vertices. + + + + + Number of faces. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + + + + + Positions of the vertices. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + + + + + + + + + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + + + + + + + + A list of as many tuples of XDMF topology key, XDMF number + of vertices and a triple of vertex indices specifying each + triangle. The total number of entries is n_f_tri * (1+1+3). + + + + + + + + + Direction of each normal. + + + + + + + + + Qualifier how which specifically oriented normal to its + primitive each normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + + + + + + + + + + + Direction of each normal. + + + + + + + + + Qualifier how which specifically oriented normal to its + primitive each normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + + + + + + + + Triangle normals are oriented in the direction of the + gradient vector of the local delocalized scalar field. + :math:`\sum_{x, y, z} {\nabla{c}_i}^2`. + + + + + + + + + Triangle normals are oriented in the direction of the + gradient vector of the local delocalized scalar field. + The projection variable here describes the cosine of the + angle between the gradient direction and the normal + direction vector. + This is a descriptor of how parallel the projection is + that is especially useful to document those triangles + for whose projection is almost perpendicular. + + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length + is reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle + is reported for the angle opposite to the edges which are + traversed according to the sequence in which vertices + are indexed in triangles. + + + + + + + + + The center of mass of each triangle. + + + + + + + + + + Iso-surfaces of arbitrary scalar three-dimensional fields + can show a complicated topology. Paraprobe-nanochem can run + a DBScan-like clustering algorithm which performs a + connectivity analysis on the triangle soup. This yields a + set of connected features with their surfaces discretized + by triangles. Currently, the tool distinguishes at most + three types of features: + + 1. So-called objects, i.e. necessarily watertight features + represented polyhedra. + 2. So-called proxies, i.e. features that were replaced by a + proxy mesh and made watertight. + 3. Remaining triangle surface meshes of arbitrary shape and + cardinality. + + These features can be interpreted as microstructural features. + Some of them may be precipitates, some of them may be poles, + some of them may be segments of dislocation lines or other + crystal defects which are decorated (or not) with solutes. + + + + + The identifier which the triangle_soup connectivity analysis + returned, which constitutes the first step of the + volumetric_feature identification process. + + + + + + + + The array of keywords of feature_type dictionary. + + + + + + + + The array of values for each keyword of the + feature_type dictionary. + + + + + + + + The array of controlled keywords, need to be from + feature_type_dict_keyword, which specify which type + each feature triangle cluster belongs to. + Keep in mind that not each feature is an object or proxy. + + + + + + + + The explicit identifier of features. + + + + + + + + + Details for features which are (closed) objects. + Identifier have to exist in feature_identifier. + + + + + + + + + + + + + + + An oriented bounding box (OBB) to each object. + + + + Edge length of the oriented bounding box from largest + to smallest value. + + + + + + + + + + Oriented bounding box aspect ratio. YX versus ZY. + + + + + + + + + Position of the geometric center, which often is but + not necessarily has to be the center_of_mass of the + hexahedrally-shaped sample/sample part. + + + + + + + + + + A simple approach to describe the entire set of hexahedra + when the main intention is to store the shape of the + hexahedra for visualization. + + + + + + + + + + + + + + + + + + + + + + + + Details for all those objects close to edge, i.e. those which + have at least one ion which lays closer to a modelled edge + of the dataset than threshold. + + + + + + + + + + + + + + + Total (count) relevant for normalization. + + + + + + + + + + + + Count or weight which, when divided by total, + yields the composition of this element, isotope, + molecule or ion. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Array of evaporation_identifier / ion_identifier which + specify ions laying inside or on the surface of the feature. + + + + + + + + + + + Details for all those objects far from edge, i.e. those + whose ions lay all at least threshold distant from a + modelled edge of the dataset. + + + + + + + + + + + + + + + Total (count) relevant for normalization. + + + + + + + + + + + + Count or weight which, when divided by total + yields the composition of this element, isotope, + molecule or ion. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Array of evaporation_identifier / ion_identifier which + specify ions laying inside or on the surface of the feature. + + + + + + + + + + + + + Details for features which are so-called proxies, i.e. objects + which have been reconstructed and combinatorially closed with + processing their partial triangulated_surface_mesh + (hole filling, refinement). + Identifier have to exist in feature_identifier. + + + + + + + + + + + + + + + + Details for those proxies close to edge, i.e. those which + have at least one ion which lays closer to a modelled edge + of the dataset than threshold. + Identifier have to exist in feature_identifier. + + + + + + + + + + + + + + + + Total (count) relevant for normalization. + + + + + + + + + + Count or weight which, when divided by total + yields the composition of this element, isotope, + molecule or ion. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Array of evaporation_identifier / ion_identifier which + specify ions laying inside or on the surface of the feature. + + + + + + + + + + + Details for those proxies far from edge, i.e. those whose + ions lay all at least threshold distant from a + modelled edge of the dataset. + + + + + + + + + + + + + + + Total (count) relevant for normalization. + + + + + + + + + + Count or weight which, when divided by total + yields the composition of this element, isotope, + molecule or ion. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Array of evaporation_identifier / ion_identifier which + specify ions laying inside or on the surface of the feature. + + + + + + + + + + + + + + + + + + The multiplicity whereby the ion position is accounted for + irrespective whether the ion is considered as a decorator + of the interface or not. + As an example, with atom probe it is typically not possible + to resolve the positions of the atoms which arrive at the detector + as molecular ions. Therefore, an exemplar molecular ion of two carbon + atoms can be considered to have a multiplicity of two to account that + this molecular ion contributes two carbon atoms at the reconstructed + location considering that the spatial resolution of atom probe + experiments is limited. + + + + + + + + The multiplicity whereby the ion position is accounted for when + the ion is considered one which is a decorator of the interface. + + + + + + + + The equation of the plane that is fitted initially. + + + + The four parameter :math:`ax + by + cz + d = 0` which define the plane. + + + + + + + + + The triangle surface mesh representing the interface model. + Exported at some iteration before the next DCOM step. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Direction of each normal + + + + + + + + + Qualifier how which specifically oriented normal to its primitive each + normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + + + + + + + + + + + + Direction of each normal + + + + + + + + + Qualifier how which specifically oriented normal to its primitive each + normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + + + + + + + + + + The triangle surface mesh representing the interface model. + Exported at some iteration after the next DCOM step. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Direction of each normal + + + + + + + + + Qualifier how which specifically oriented normal to its primitive each + normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + + + + + + + + + + + + Direction of each normal + + + + + + + + + Qualifier how which specifically oriented normal to its primitive each + normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + + + + + + + + + + + + The ROIs are defined as cylinders for the computations. + To visualize these though we discretize them into regular n-gons. + Using for instance a 360-gon, i.e. a regular n-gon with 360 + edges resolves the lateral surface of each cylinder very finely + so that they are rendered smoothly in visualization software. + + + + + + Position of the geometric center, which often is but not + necessarily has to be the center_of_mass of the polyhedra. + + + + + + + + + Integer which specifies the first index to be used for distinguishing + ROI cylinder. Identifiers are defined explicitly. + + + + + + + + + + + + + + + The number of atoms in each ROI. + + + + + + + + The number of ions in each ROI. + + + + + + + + The orientation of the ROI defined via a vector which points along + the cylinder axis and whose length is the height of the cylinder. + + + + + + + + + + In the direction of the ROI. + + + + + Hashvalue + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml new file mode 100644 index 0000000000..52e41fca56 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml @@ -0,0 +1,425 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. + + + + + Results of a paraprobe-ranger tool run. + + + + + + Version specifier of this application definition. + + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + + + + + The path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + + + + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + + Paraprobe-ranger loads the iontypes and evaluates for each + ion on which iontype it matches. If it matches on none, the + ion is considered of the default unknown type with a 0 as its + respective value in the iontypes array. + + + + + The length of the isotope_vector used to describe molecular ions. + + + + + + + + + + + The iontype ID for each ion that was best matching, stored in the + order of the evaporation sequence ID. The here computed iontypes + do not take into account the charge state of the ion which is + equivalent to interpreting a RNG and RRNG range files for each + ion in such a way that only the elements of which a (molecular) ion + is build are considered. By contrast, charged_iontypes takes + into account also the charge state. + + + + + + + + A bitmask which identifies exactly all those ions ranged irrespective + the type they ended up with. + + + + Number of ions covered by the mask. + The mask value for most may be 0. + + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + + Paraprobe-ranger performs a combinatorial search over + all possible or a reduced set of nuclids to identify + into which ions these can be composed. + + + + The main result is the list of molecular ions, here formatted + according to the definitions of a set of isotope_vectors + as detailed in :ref:`NXion`. + + + + + + + + + The mass-to-charge-state ratio of each molecular ion + without considering relativistic or quantum effects. + + + + + + + + The mass of each molecular ion without + considering relativistic or quantum effects. + + + + + + + + + The charge_state of each molecular ion. + + + + + + + + The product of the natural abundance of the isotopes building + each molecular ion. Further details are available in + :ref:`NXapm_paraprobe_config_ranger`. + + + + + + + + The product of the natural abundance of the isotopes building + each molecular ion. Further details are available in + :ref:`NXapm_paraprobe_config_ranger`. + + + + + + + + The number of disjoint nuclids for each molecular ion. + + + + + + + + The number of nuclids for each molecular ion. + + + + + + + + + Paraprobe-ranger loads iontypes and evaluates for each ion on which + iontype it matches. If it matches on none, the ion is considered of + the default unknown type with a 0 as its respective value in the + iontypes array. In contrast to use_existent_ranging this process + does neither needs measured ion position nor mass-to-charge-state + ratio values. + + + + + The length of the isotope_vector used to describe molecular ions. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_results_selector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_selector.nxdl.xml new file mode 100644 index 0000000000..38fac70961 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_results_selector.nxdl.xml @@ -0,0 +1,274 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + Results of a paraprobe-selector tool run. + + + + + + Version specifier of this application definition. + + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + + + + + The absolute path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + + + + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + + A bitmask which identifies which of the ions in the dataset + were selected to become included in the region-of-interest (ROI). + + + + Number of ions covered by the mask. + The mask value for most may be 0. + + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_results_spatstat.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_spatstat.nxdl.xml new file mode 100644 index 0000000000..d87d2f50ff --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_results_spatstat.nxdl.xml @@ -0,0 +1,364 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + Results of a paraprobe-spatstat tool run. + + + + + + Version specifier of this application definition. + + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + + + + + The absolute path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + + + + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + + A bitmask which identifies which of the ions in the dataset were + analyzed. + + + + Number of ions covered by the mask. + The mask value for most may be 0. + + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + The iontype ID for each ion that was assigned to each ion during + the randomization of the ionlabels. Iontype labels are just permuted + but the total number of values for each iontype stay the same. + + The order matches the iontypes array from a given ranging results + as is specified in the configuration settings inside the specific + config_filename that was used for this spatstat analysis. + + + + + + + + K-nearest neighbor statistics. + + + + Right boundary of the binning. + + + + + + + + + + + + + Cumulated + + + + + + + + Cumulated and normalized by total counts + + + + + + + + + Radial distribution statistics. + + + + Right boundary of the binning. + + + + + + + + + + + + + Cumulated + + + + + + + + Cumulated and normalized by total counts + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml new file mode 100644 index 0000000000..dbb0bb4e44 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml @@ -0,0 +1,503 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + The number of vertices of the alpha complex. + + + + + The number of faces of the alpha complex. + + + + + The total number of XDMF values to represent all faces of triangles via XDMF. + + + + + The total number of XDMF values to represent all faces of tetrahedra via XDMF. + + + + + Results of a paraprobe-surfacer tool run. + + + + + + Version specifier of this application definition. + + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + + + + + The absolute path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + + + + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + + A bitmask which identifies which of the ions in the dataset were + analyzed. Computations of alpha complexes may have filtered this + ion set further but this process is deterministic. + + + + Number of ions covered by the mask. The mask may be 0 for most. + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + Paraprobe-surfacer can be used to load a ROI that is the entire or a + sub-set of the ion point cloud. In the point_cloud_wrapping process + the tool computes a triangulated surface mesh which encloses the + ROI/point cloud. This mesh can be seen as a model for the edge of + the dataset. + Different algorithms can be used with paraprobe-surfacer to create + this mesh such as convex hulls, alpha-shapes as their generalization, + or alpha wrappings. + Ideally, the resulting mesh should be a watertight polyhedron. + This polyhedron is not necessarily convex. For some algorithms there + is no guarantee that the resulting mesh yields a watertight mesh. + + + + + + A bitmask which identifies exactly all those ions whose positions + were considered when defining the filtered point set from which + the alpha complex was then in fact computed. This window + can be different to the entire window as irrelevant ions might + have been filtered out to reduce the computational costs of the + alpha complex analysis. + + + + + Number of ions covered by the mask. + The mask value for most may be 0. + + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The set of triangles in the coordinate system paraprobe + which discretizes the exterior surface of the alpha complex. + + + + Integer which specifies the first index to be used for distinguishing + triangles. Identifiers are defined either implicitly or explicitly. + For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + + + + + + + Number of vertices. + + + + + Number of faces. + + + + + + + + + + + + + + + + + + + A list of as many tuples of XDMF topology key, XDMF number + of vertices and a triple of vertex indices specifying each + triangle. The total number of entries is n_f_tri * (1+1+3). + + + + + + + + + Do the triangles define a triangulated surface mesh which + is watertight? + + + + + The volume which the triangulated surface mesh encloses + provided that the mesh is watertight. + + + + + + The set of tetrahedra which represent the interior volume of the + complex if that is a closed 2-manifold. + + + + Integer which specifies the first index to be used for distin- + guishing tetrahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined + on the interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + + + + The accumulated volume of all interior tetrahedra. + + + + + + Number of vertices. + + + + + Number of faces. + + + + + + + + + + + + + A list of as many tuples of XDMF topology key, XDMF number + of vertices and a triple of vertex indices specifying each + triangle. The total number of entries is n_f_tet * (1+1+4). + + + + + + + + + + + + In the future we may want to wrap other primitives + like triangles or polylines. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml new file mode 100644 index 0000000000..4d8eb2476e --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml @@ -0,0 +1,677 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + The total number of facets/polygons defining the tessellation. + + + + + Results of a paraprobe-tessellator tool run. + + + + + + Version specifier of this application definition. + + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + + + + + The absolute path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + + + + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + + The tool can be used to compute a Voronoi tessellation the entire + or a sub-set of the reconstruction. The point cloud in the ROI is + wrapped into a tight axis-aligned bounding box. The tool detects if + Voronoi cells make contact with the walls of this bounding box. + The tessellation is computed without periodic boundary conditions. + + + + A bitmask which identifies which of the ions in the dataset were + analyzed. + + + + Number of ions covered by the mask. + The mask value for most may be 0. + + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + A bitmask which identifies which of points have Voronoi cells that + are truncated by the global axis-aligned bounding box, i.e. boundaries + of the threads are ignored. + + + + Number of points covered by the mask. + The mask value for most may be 0. + + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + + A bitmask which identifies which of points have Voronoi cells that + are truncated by a specific wall of the axis-aligned bounding box. + The left wall has the negative x axis of the paraprobe coordinate + system as the outer unit normal. + + + + Number of points covered by the mask. + The mask value for most may be 0. + + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + A bitmask which identifies which of points have Voronoi cells that + are truncated by a specific wall of the axis-aligned bounding box. + The right wall has the positive x axis of the paraprobe coordinate + system as the outer unit normal. + + + + Number of points covered by the mask. + The mask value for most may be 0. + + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + A bitmask which identifies which of points have Voronoi cells that + are truncated by a specific wall of the axis-aligned bounding box. + The front wall has the negative y axis of the paraprobe coordinate + system as the outer unit normal. + + + + Number of points covered by the mask. + The mask value for most may be 0. + + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + A bitmask which identifies which of points have Voronoi cells that + are truncated by a specific wall of the axis-aligned bounding box. + The rear wall has the positive y axis of the paraprobe coordinate + system as the outer unit normal. + + + + Number of points covered by the mask. + The mask value for most may be 0. + + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + A bitmask which identifies which of points have Voronoi cells that + are truncated by a specific wall of the axis-aligned bounding box. + The left wall has the negative z axis of the paraprobe coordinate + system as the outer unit normal. + + + + Number of points covered by the mask. + The mask value for most may be 0. + + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + A bitmask which identifies which of points have Voronoi cells that + are truncated by a specific wall of the axis-aligned bounding box. + The left wall has the positive z axis of the paraprobe coordinate + system as the outer unit normal. + + + + Number of points covered by the mask. + The mask value for most may be 0. + + + + + + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + + + + + + + + Interior volume + + + + + + + + By which MPI process was the Voronoi cell computed. + + + + + + + + By which OpenMP thread was the Voronoi cell computed. + + + + + + + + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. This field can be used to interpret + the array/field with the individual area values for each face. + + + + + + + + + Integer which specifies the first index to be used for distinguishing + polyhedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + + + + Integer used to distinguish polyhedra for explicit indexing. + + + + + + + + A simple approach to describe the entire set of polyhedra when + the main intention is to store the shape of the polyhedra for + visualization. + + + + + Number of vertices. + + + + + Number of faces. + + + + + + + + + + + + + A sequence of always first an XDMF topology type key, followed + by the XDMF number of vertices of the polygon, followed by + the vertex identifier which define the facet polygon. First + we store the polygon of the first facet of the first cell, then + the second facet of the first cell, until the last facet of the + first cell, followed by the first facet of the second cell, + and so on and so forth. + + + + + + + + A sequence of cell identifier so that each facet is associated + with its cell because of which it is then possible to segment + out cells three-dimensionally based on cell i.e. evaporation_id. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml new file mode 100644 index 0000000000..f7e0f3433e --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml @@ -0,0 +1,568 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. + + + + + Number of mass-to-charge-state-ratio intervals mapped on this ion type. + + + + + Total number of integers in the supplementary XDMF topology array. + + + + + Number of ions probed in the combinatorial analysis of the charge states + + + + + Results of a paraprobe-transcoder tool run. + + + + + + Version specifier of this application definition. + + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + + + + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + + + + + The absolute path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + + + + + + + Details about the coordinate system conventions used. + + + + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + + + + + + + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstruction. The XDMF datatype + is here 1, the number of primitives 1 per triplet, the last integer + in each triplet is the identifier of each point starting from zero. + + + + + + + + + + On a mid term perspective we would like to evolve the paraprobe-toolbox + to an implementation stage where it works exclusively with completely + provenance-tracked formats for both the configuration of the workflow step + and/or analysis with each tool and also for the output of these analyses + in the form of so-called tool-specific results files. + Currently the Hierarchical Data Format 5 (HDF5) is used to store such data. + + Different file formats can be used to inject reconstructed datasets and + ranging definitions into the toolbox. Traditionally, these are the POS, + ePOS, and APT files with the tomographic reconstruction and other metadata + and RNG and RRNG file formats for the ranging definitions how mass-to-charge + state-ratio values map on (molecular) ion types. Such input should be + injected via specific NeXus/HDF5 files which are documented + in compliance with the NXapm application definition. + + So far the paraprobe-toolbox was used as a standalone tool. Therefore, it + was not relevant during the development to focus on interoperability. + Essentially paraprobe-transcoder was used as a parser to transcode data + in the above-mentioned file formats into a paraprobe-specific + representation. This transcoding should become deprecated. + Here we describe steps we have taken into this direction. + + With the work in the FAIRmat project and the desire to make the paraprobe- + toolbox also accessible as a cloud-computing capable service in the Nomad + Remote Tools Hub (NORTH) the topic of interoperability became more important + and eventually the NXapm application definition was proposed. + NORTH is a GUI and related service in a NOMAD OASIS instance which allows + to spawn preconfigured docker containers via JupyterHub. + Currently, NORTH includes the so-called apm container. A container with + tools specific for analyzing data from atom probe microscopy as well as + processing of point cloud and mesh data. + + The NXapm application definition and related implementation work within + NOMAD OASIS enabled users to parse content of POS, ePOS, APT, RNG, and + RRNG files, surplus key metadata from vendor-agnostic electronic lab notebook + solutions directly into NOMAD OASIS via the uploads section. + The process is automated and yields an NXapm-compliant NeXus/HDF5 file + inside the uploads section in return. + + With these improvements made there is no longer a need for - at least the + users of a NOMAD OASIS and NORTH instance to use the deprecated + PARAPROBE.Transcoder.Results.*.h5 files. Ideally, paraprobe should + automatically detect that the input can now be an NXapm-compliant NeXus/HDF5 + file and in response work with this file directly. + To remain compliant with users however who do not have or do not wish + to use a NOMAD OASIS or NXapm or NeXus at all right now, the solution is + as follows: + + Calling the configuration stage of paraprobe-transcoder is always mandatory. + It is always the first step of working with the toolbox. In this process + the user defines the input files. These can either be nxs i.e. the NXapm/NeXus/ + HDF5 file from e.g. the upload section, or such a file that was obtained from + a colleague with a NOMAD OASIS instance. + In all other cases, users can pass the reconstruction and ranging definitions + using the traditional POS, ePOS, or APT and RNG or RRNG file formats respectively. + + Based on which input the user delivers, the parmsetup-transcoder tool then + creates a configuration file PARAPROBE.Transcoder.Config.SimID.*.nxs and + informs the user whether the input was NeXus (and thus if all relevant + input is already available) or whether the paraprobe-transcoder tool needs + to be executed to convert the content of the vendor files first into a + format which paraprobe can provenance track and understand. + In the latter case, the PARAPROBE.Transcoder.Config.SimID.*.nxs file is + used to communicate to all subsequently used tools from which files + the tools can expect to find the reconstruction and ranging definitions. + + All subsequent analysis steps start also with a tool-specific configuration. + This configuration step reads in (among others) the + PARAPROBE.Transcoder.Config.SimID.*.nxs file from which the configuration + tool identifies automatically whether to read the reconstruction and ranging data + from PARAPROBE.Transcoder.Results.SimID.*.h5 or directly the NXapm-compliant + NeXus/HDF5 file that was created upon preparing the upload or the file shared + from a colleague. This design removes the need for unnecessary copies of the data. + Currently still though users should execute the transcoder step as it will + generate a supplementary XDMF topology field with which the data in either + the NeXus/HDF5 or the transcoded vendor files can be displayed using e.g. + Paraview. For this purpose XDMF is used. + + Of course ideally the APT community would at some point converge to use + a common data exchange file format. To this end, AMETEK/Cameca's APT file format + could be a good starting point but so far it is lacking a consistent way of + how to store generalized ranging definitions and post-processing results. + POS, ePOS, Rouen's ATO, as well as other so far used representations of data + like CSV or text files have, to the best of our current knowledge, no + concept of how to marry reconstruction and (optional) ranging data into + one self-descriptive format. + + This summarizes the rationale behind the current choices of the I/O for + paraprobe. Furthermore, this summarizes also why the fundamental design + of splitting an analysis always into steps of configuration (with parmsetup), + task execution (with the respective C/C++ or Python tool of the toolbox), + and post-processing (e.g. with autoreporter) is useful because it offers + a clear description of provenance tracking. This is a necessary step to make + atom probe microscopy data at all better aligned with the aims of the + FAIR principles. + + The internal organization of the data entries in the atom_probe group + in this application definition for paraprobe-transcoder results files + mirror the definitions of the NXapm for consistency reasons. + + + + + + Mass-to-charge-state ratio values. + + + + + + + + + + + + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + + + + + + + + + + + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + + + + + + + + + Details and results of the combinatorial analyses of this + range definition to identify the charge_state for an ion. + + + + Currently charge_state not charge! + + + + + + + + Specific isotopes building each candidate matching the range. + + + + + + + + + Accumulated mass of the isotopes in each candidate. + Not corrected for quantum effects. + + + + + + + + + Product of natural abundance of the isotopes per candidate. + + + + + + + + Filter criterion on the product of the natural abundances + computed from each isotope building the (molecular) ion. + Such a filter can be used to reduce the number of possible + molecular ions considered when trying to find a unique solution + to the question which charge_state does a molecular ion + within a given range and given combination of elements have. + + + + + Filter criterion on the minimum half life which all isotopes + building the (molecular) ion need to have to consider the + candidate. + Such a filter can be used to reduce the number of possible + molecular ions considered when trying to find a unique solution + to the question which charge_state does a molecular ion + within a given range and given combination of elements have. + + + + + + If the value is zero/false it means that non-unique solutions + are accepted. These are solutions where multiple candidates + differ in their isotopes but have the same charge. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml new file mode 100644 index 0000000000..8dd7a6da55 --- /dev/null +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of coefficients of the calibration function + + + + + Number of features used to fit the calibration function + + + + + Number of points of the calibrated and uncalibrated axes + + + + + Subclass of NXprocess to describe post-processing calibrations. + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Has the calibration been applied? + + + + + For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit + to a set of features (peaks) at well defined energy positions to determine + E(TOF). Here we can store the array of fit coefficients. + + + + + + + + For non-linear energy calibrations. Here we can store the formula of the + fit function. + + Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. + + Use x0, x1, ..., xn for the variables. + + The formula should be numpy compliant. + + + + + For linear calibration. Scaling parameter. + + + + + For linear calibration. Offset parameter. + + + + + A vector representing the axis after calibration, matching the data length + + + + + + + + Vector containing the data coordinates in the original uncalibrated axis + + + + + + + + A description of the procedures employed. + + + diff --git a/base_classes/NXcg_alpha_complex.nxdl.xml b/contributed_definitions/NXcg_alpha_complex.nxdl.xml similarity index 57% rename from base_classes/NXcg_alpha_complex.nxdl.xml rename to contributed_definitions/NXcg_alpha_complex.nxdl.xml index b6a466bc58..1b3e3446e6 100644 --- a/base_classes/NXcg_alpha_complex.nxdl.xml +++ b/contributed_definitions/NXcg_alpha_complex.nxdl.xml @@ -1,10 +1,10 @@ - + - - + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the alpha shape, for now 2 or 3. + + + + + + The number of edges. + + + + + The number of faces. + + + + + The number of cells. + + + - Computational geometry of alpha shapes or alpha wrappings about primitives. + Computational geometry description of alpha shapes or wrappings to primitives. For details see: @@ -33,17 +60,22 @@ The so-called spectrum or sets of (weighted) alpha shapes includes the convex hu * https://dx.doi.org/10.1145/174462.156635 for 3D, * https://dl.acm.org/doi/10.5555/871114 for weighted, and * https://doc.cgal.org/latest/Alpha_shapes_3 for 3D implementation - * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D wrappings + * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D wrap in CGAL, the Computational Geometry Algorithms Library. As a starting point, we follow the conventions of the CGAL library. + + + + + + - Type of alpha complex following the terminology used by CGAL for now. - - Basic means (unweighted) alpha shapes. Alpha_wrapping means meshes - created using the alpha_wrapping algorithm. + Specify which general type of alpha shape is computed. + Using for now the CGAL terminology. Basic means (unweighted) alpha shapes. + Alpha_wrapping means meshes created using alpha wrapping procedures. @@ -51,72 +83,69 @@ The so-called spectrum or sets of (weighted) alpha shapes includes the convex hu - + - Are singular faces removed, i.e. has the alpha complex - been regularized or not. + Specifically when computed with the CGAL, the mode specifies if singular + faces are removed (regularized) of the alpha complex. + + + + + - - The alpha parameter, i.e. the radius of the alpha-sphere that - is used when computing the alpha complex. + The alpha, (radius of the alpha-sphere) parameter to be used for alpha + shapes and alpha wrappings. - - The offset distance parameter used when computing alpha_wrappings. + The offset distance parameter to be used in addition to alpha + in the case of alpha_wrapping. - - + - Point cloud for which the alpha shape or wrapping has been computed. + Point cloud for which the alpha shape or wrapping should be computed. - + - Triangle soup for which the alpha wrapping has been computed. + Triangle soup for which the alpha wrapping should be computed. - + - Triangle mesh representing the alpha complex. + A meshed representation of the resulting shape. - - - - Set of tetrahedra representing the volume inside the alpha complex. - - + diff --git a/base_classes/NXcg_cylinder_set.nxdl.xml b/contributed_definitions/NXcg_cylinder_set.nxdl.xml similarity index 51% rename from base_classes/NXcg_cylinder_set.nxdl.xml rename to contributed_definitions/NXcg_cylinder_set.nxdl.xml index e5bb83807a..e5e5e88601 100644 --- a/base_classes/NXcg_cylinder_set.nxdl.xml +++ b/contributed_definitions/NXcg_cylinder_set.nxdl.xml @@ -1,10 +1,10 @@ - + - - + The symbols used in the schema to specify e.g. dimensions of arrays. - - - The dimensionality of the space in which the members are assumed embedded. - - - The cardinality of the set, i.e. the number of members. + The cardinality of the set, i.e. the number of cylinders or cones. - Computational geometry description of a set of cylinders. + Computational geometry description of a set of cylinders in Euclidean space. - The radius can either be defined in the radii field or by filling both - the upper_cap_radii or lower_cap_radii field. The latter field case can - thus be used to represent truncated cones. + The members of the set can have different size. For each member the position + of the center and the height is mandatory. The radius can either be defined + in the radius field or by filling both the upper and the lower radius field. + The latter case can be used to represent truncated cones. + + + + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for cylinders. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish members for explicit indexing. + + + + + + + + The geometric center of each member. + + + + + + - A direction vector which is parallel to the cylinder/cone axis - and whose magnitude is the height of the cylinder/cone. + A direction vector which is parallel to the cylinder/cone axis and + whose magnitude is the height of the cylinder/cone. - + - - - - Radius of the cylinder if all have the same radius. - - - - Radii of the cylinder. - - + - Radii of the upper circular cap. - - This field, combined with lower_cap_radius can be used to describe - (eventually truncated) circular cones. + The radius of the upper circular cap. + This field, combined with lower_cap_radius can be used to + describe (eventually truncated) circular cones. - + - Radii of the upper circular cap. - - This field, combined with upper_cap_radius can be used to describe - (eventually truncated) circular cones. + The radius of the upper circular cap. + This field, combined with lower_cap_radius can be used to + describe (eventually truncated) circular cones. + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + - + - Lateral surface area + Interior volume of each cylinder - + - Area of the upper cap of each cylinder. + Lateral surface area - + - Area of the lower cap of each cylinder. + Area of the upper and the lower cap of each cylinder respectively. - + + - + - Sum of upper and lower cap areas and lateral surface area - of each cylinder. + Cap and lateral surface area for each cylinder. diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml new file mode 100644 index 0000000000..38a448a0e1 --- /dev/null +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -0,0 +1,135 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of ellipses, or ellipsoids. + + + + + Computational geometry description of a set of ellipsoids in Euclidean space. + + Individual ellipsoids can have different half axes. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for ellipsoids. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish ellipsoids for explicit indexing. + + + + + + + + Geometric center of the ellipsoids. This can be the center of mass. + Dimensionality and cardinality of the point and ellipsoid set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the ellipsoids. + + + + + + + + + If all ellipsoids in the set have the same half-axes. + + + + + + + + In the case that ellipsoids have different radii use this field + instead of half_axes_radius. + + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the ellipsoids closed or hollow? + + + + + + + + + + + + + + + + + + + Direction unit vector which points along the largest half-axes. + + + + + + + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml new file mode 100644 index 0000000000..ea8faee3e4 --- /dev/null +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -0,0 +1,243 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The number of vertices. + + + + + The number of edges. + + + + + The number of faces. + + + + + The total number of vertices of all faces. Faces are polygons. + + + + + The total number of Weinberg vector values of all faces. + + + + + Computational geometry description of geometric primitives via a face and edge list. + + Primitives must not be degenerated or self-intersect. + Such descriptions of primitives are frequently used for triangles and polyhedra + to store them on disk for visualization purposes. Although storage efficient, + such a description is not well suited for topological and neighborhood queries + of especially meshes that are built from primitives. + + In this case, scientists may need a different view on the primitives which + is better represented for instance with a half_edge_data_structure instance. + The reason to split thus the geometric description of primitives, sets, and + specifically meshes of primitives is to keep the structure simple enough for + users without these computational geometry demands but also enable those more + computational geometry savy users the storing of the additionally relevant + data structure. + + This is beneficial and superior over NXoff_geometry because for instance a + half_edge_data_structure instance can be immediately use to reinstantiate + the set without having to recompute the half_edge_structure from the vertex + and face-list based representation and thus offer a more efficient route + to serve applications where topological and graph-based operations are key. + + + + Dimensionality. + + + + + + Array which specifies of how many vertices each face is built. + Each entry represent the total number of vertices for face, irrespectively + whether vertices are shared among faces/are unique or not. + + + + + + + + Number of edges. + + + + + Number of faces. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for edges. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish vertices explicitly. + + + + + + + + Integer used to distinguish edges explicitly. + + + + + + + + Integer used to distinguish faces explicitly. + + + + + + + + Positions of the vertices. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + + + + + + + + + The edges are stored as a pairs of vertex identifier values. + + + + + + + + + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + + + + + + + + + If true indicates that the vertices are all placed at different positions + and have different identifiers, i.e. no points overlap or are counted twice. + + + + + If true indicates that no edge is stored twice. Users are encouraged to + consider and use the half_edge_data_structure instead as this will work + towards achieving a cleaner graph-based description if relevant and possible. + + + + + + Specifies for each face which winding order was used if any: + + * 0 - undefined + * 1 - counter-clockwise (CCW) + * 2 - clock-wise (CW) + + + + + + diff --git a/base_classes/NXcg_geodesic_mesh.nxdl.xml b/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml similarity index 58% rename from base_classes/NXcg_geodesic_mesh.nxdl.xml rename to contributed_definitions/NXcg_geodesic_mesh.nxdl.xml index 6314db3427..1b69e9bc4f 100644 --- a/base_classes/NXcg_geodesic_mesh.nxdl.xml +++ b/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -30,26 +30,28 @@ Computational geometry description of a geodesic mesh. - A geodesic surface mesh is a triangulated surface mesh with metadata which - can be used as an approximation to describe the surface of a sphere. - Triangulation of spheres are commonly used in Materials Science - for quantifying texture of materials, i.e. the relative rotation of - crystals to sample directions. + People from geodesic/surveyors will likely have specific demands and + different views about what should be included in such a base class, given + that nested geodesic meshes are a key component of climate modelling tools. + For now we propose to use this base class as a container to organize metadata + and data related to geodesic meshes. - For additional details or an introduction into the topic of geodesic meshes - see (from which specifically the section on subdivision schemes is relevant). - - * `E. S. Popko and C. J. Kitrick <https://doi.org/10.1201/9781003134114>`_ + Specifically an instance of this base class should detail the rule set how + how the geodesic (surface) mesh was instantiated as there are many + possibilities. A geodesic surface mesh is in this sense a triangulated + surface mesh with metadata. For additional details as an introduction + into the topic see e.g.: - Earth scientists have specific demands and different views about what should - be included in such a base class, given that nested geodesic meshes are a key - component of climate modelling software. For now we propose to use this - base class as a container for organizing data related to geodesic meshes. + * `E. S. Popko and C. J. Kitrick <https://doi.org/10.1201/9781003134114>`_ - Specifically an instance of this base class should detail the rule set how - e.g. a geodesic (surface) mesh was instantiated as there are many - possibilities to do so. + Here, especially the section on subdivision schemes is relevant. + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + diff --git a/base_classes/NXcg_grid.nxdl.xml b/contributed_definitions/NXcg_grid.nxdl.xml similarity index 60% rename from base_classes/NXcg_grid.nxdl.xml rename to contributed_definitions/NXcg_grid.nxdl.xml index c83d817d83..f3cbc28539 100644 --- a/base_classes/NXcg_grid.nxdl.xml +++ b/contributed_definitions/NXcg_grid.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -33,35 +33,36 @@ - The cardinality or total number of cells aka grid points. + The cardinality or total number of cells/grid points. - Number of boundaries of the bounding box or primitive housing the grid. + Number of boundaries of the bounding box or primitive to the grid. - Computational geometry description of a grid of Wigner-Seitz cells in Euclidean space. + Computational geometry description of a Wigner-Seitz cell grid in Euclidean space. - Three-dimensional grids with cubic cells are if not the most frequently used - example of such grids. Examples of numerical methods where grids are used - are spectral-solver based crystal plasticity or other stencil methods like - phase-field or cellular automata. + Frequently convenient three-dimensional grids with cubic cells are used. + Exemplar applications are spectral-solver based crystal plasticity + and stencil methods like phase-field or cellular automata. - - - Location of the origin of the grid. - - Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` - class to specify the coordinate system in which the origin location is defined. - + + + + + + + + + - + The symmetry of the lattice defining the shape of the unit cell. @@ -77,23 +78,49 @@ - + Number of unit cells along each of the d unit vectors. - - The total number of cells or grid points has to be the cardinality. + The total number of cells, or grid points has to be the cardinality. If the grid has an irregular number of grid positions in each direction, as it could be for instance the case of a grid where all grid points outside some masking primitive are removed, this extent field should - not be used. Instead, use the coordinate field. + not be used. Instead use the coordinate field. + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + - + + + Integer which specifies the first index to be used for distinguishing + identifiers for cells. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish cells for explicit indexing. + + + + + + Position of each cell in Euclidean space. @@ -114,25 +141,24 @@ should constraints on the grid be place here or not--> - A tight bounding box about the grid. + A tight bounding box or sphere or bounding primitive about the grid. - - + - Number of boundaries distinguished - + How many distinct boundaries are distinguished? Most grids discretize a cubic or cuboidal region. In this case six sides can be distinguished, each making an own boundary. - + - Name of domain boundaries of the simulation box/ROI - e.g. left, right, front, back, bottom, top. + Name of domain boundaries of the simulation box/ROI e.g. left, right, + front, back, bottom, top. + diff --git a/base_classes/NXcg_half_edge_data_structure.nxdl.xml b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml similarity index 62% rename from base_classes/NXcg_half_edge_data_structure.nxdl.xml rename to contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml index 759e30943c..81c66fb2bf 100644 --- a/base_classes/NXcg_half_edge_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml @@ -1,10 +1,10 @@ - + - + @@ -54,63 +54,41 @@ Such a data structure can be used to efficiently circulate around faces and iterate over vertices of a planar graph. - - - - Number of vertices for each face. - - Each entry represents the total number of vertices for that face, - irrespectively whether vertices are shared among faces or not. - - - - - - - - Number of edges for each face. - - Each entry represents the total number of edges for that face, - irrespectively whether edges are shared across faces or not. - - - - - - - - Number of faces of the primitives. - - + + + + - Integer offset whereby the identifier of the first member - of the vertices differs from zero. - - Identifier can be defined explicitly or implicitly. - Inspect the definition of :ref:`NXcg_primitive_set` for further details. + In this half-edge data structure vertex identifiers start at 1. + Vertices are identified with consecutive integers up to number_of_vertices. + This field can be used to document which constant integer has to be + added to another set of vertex_identifier to assure that these other + identifiers also start at 1. - + - Integer offset whereby the identifier of the first member - of the edges differs from zero. + In this half-edge data structure face identifiers start at 1. + Faces are identified with consecutive integers up to number_of_faces. + This field can be used to document which constant integer has to be + added to another set of face_identifier to assure that these other + identifiers also start at 1. - Identifier can be defined explicitly or implicitly. - Inspect the definition of :ref:`NXcg_primitive_set` for further details. + The face identifier zero is reserved for the NULL face ! - + - Integer offset whereby the identifier of the first member - of the faces differs from zero. - - Identifier can be defined explicitly or implicitly. - Inspect the definition of :ref:`NXcg_primitive_set` for further details. + In this half-edge data structure half-edge identifiers start at 1. + Half-edges are identified with consecutive integers up to number_of_half_edges. + This field can be used to document which constant integer has to be + added to another set of half_edge_identifier to assure that these other + identifiers also start at 1. - + The position of the vertices. @@ -119,7 +97,7 @@ - + Identifier of the incident half-edge. @@ -127,7 +105,7 @@ - + Identifier of the (starting)/associated half-edge of the face. @@ -135,7 +113,7 @@ - + The identifier of the vertex from which this half-edge is outwards pointing. @@ -143,7 +121,7 @@ - + Identifier of the associated oppositely pointing half-edge. @@ -151,7 +129,7 @@ - + If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. @@ -160,7 +138,7 @@ - + Identifier of the next half-edge. @@ -168,7 +146,7 @@ - + Identifier of the previous half-edge. @@ -176,14 +154,14 @@ - + Users are referred to the literature for the background of L. Weinberg's work about topological characterization of planar graphs: - * `L. Weinberg 1966a, <https://dx.doi.org/10.1109/TCT.1964.1082216>`_ - * `L. Weinberg, 1966b, <https://dx.doi.org/10.1137/0114062>`_ - * `E. A. Lazar et al. <https://doi.org/10.1103/PhysRevLett.109.095505>`_ + * `L. Weinberg 1966a, <https://dx.doi.org/10.1109/TCT.1964.1082216>`_ + * `L. Weinberg, 1966b, <https://dx.doi.org/10.1137/0114062>`_ + * `E. A. Lazar et al. <https://doi.org/10.1103/PhysRevLett.109.095505>`_ and how this work can e.g. be applied in space-filling tessellations of microstructural objects like crystals/grains. diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml new file mode 100644 index 0000000000..96c2d7123c --- /dev/null +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -0,0 +1,239 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of hexahedra. + + + + + Computational geometry description of a set of hexahedra in Euclidean space. + + The hexahedra do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe cuboids or cubes, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of specimens. In this case the alignment with axes is not relevant as + eventually the only relevant information to convey is the volume of the + specimen. + * In many cases, take for instance an experiment where a specimen was taken + from a specifically deformed piece of material, e.g. cold-rolled, + channel-die deformed, the orientation of the specimen edges with the + experiment coordinate system can be of very high relevance. + Examples include to know which specimen edge is parallel to the rolling, + the transverse, or the normal direction. + * Sufficient to pinpoint the sample and laboratory/experiment coordinate + system, the above-mentioned descriptions are not detailed enough though + to create a CAD model of the specimen. + * Therefore, groups and fields for an additional, computational-geometry- + based view of the hexahedra is offered which serve different computational + tasks: storage-oriented simple views or detailed topological/graph-based + descriptions. + + Hexahedra are important geometrical primitives, which are among the most + frequently used elements in finite element meshing/modeling. + + Hexahedra have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term hexahedra will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding + box (OBB). + + An axis-aligned bounding box is a common data object in + computational science and codes to represent a cuboid whose edges + are aligned with a coordinate system. As a part of binary trees these + are important data objects for time as well as space efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Exact and substantially faster in practice approximate algorithms + exist for computing optimal or near optimal bounding boxes for point sets. + + + + + + + + + + + A qualitative description of each hexahedron/cuboid/cube/box. + + + + + + + + + Qualifier how one edge is longer than all other edges of the hexahedra. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the hexahedrally-shaped sample/sample part. + + + + + + + + + + + + + + Total area (of all six faces) of each hexahedron. + + + + + + + + Area of each of the six faces of each hexahedron. + + + + + + + + + Specifies if the hexahedra represent cuboids or cubes eventually rotated + ones but at least not too exotic six-faced polyhedra. + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether hexahedra are boxes whose primary edges are parallel to the + axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish hexahedra for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of hexahedra when the + main intention is to store the shape of the hexahedra for visualization. + + + + + + Disentangled representations of the mesh of specific hexahedra. + + + + + + Disentangled representation of the planar graph that each hexahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/base_classes/NXcg_marching_cubes.nxdl.xml b/contributed_definitions/NXcg_marching_cubes.nxdl.xml similarity index 54% rename from base_classes/NXcg_marching_cubes.nxdl.xml rename to contributed_definitions/NXcg_marching_cubes.nxdl.xml index b1f6310dd7..b1f8e92738 100644 --- a/base_classes/NXcg_marching_cubes.nxdl.xml +++ b/contributed_definitions/NXcg_marching_cubes.nxdl.xml @@ -1,10 +1,10 @@ - + - - + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + - Base class to detail the marching cubes (MC) algorithm. + Computational geometry description of the marching cubes algorithm. - Documenting which specific version of MC was used helps with understanding - how robust the results are with respect to the topology of the triangulation. + Documenting which specific version was used can help to understand how robust + the results are with respect to the topology of the triangulation. - Metadata of the grid on which the here specified MC is operating. + Reference/link to and/or details of the grid on which a specific + marching cubes algorithm implementation is operating. - + Reference to the specific implementation of marching cubes used. - See for example the following papers for details about specific - MC implementations: + See for example the following papers for details about how to identify a + DOI which specifies the implementation used: + + * `W. E. Lorensen <https://doi.org/10.1109/MCG.2020.2971284>`_ + * `T. S. Newman and H. Yi <https://doi.org/10.1016/j.cag.2006.07.021>`_ - * `W. E. Lorensen <https://doi.org/10.1109/MCG.2020.2971284>`_ - * `T. S. Newman and H. Yi <https://doi.org/10.1016/j.cag.2006.07.021>`_ + The value placed here should be a DOI. If there are no specific DOI or + details write not_further_specified, or give at least a free-text + description. - - + + - Free text field in case a proper identifier is not available. + Commercial or otherwise given name to the program which was used. + + + Program version plus build number, commit hash, or description of + an ever persistent resource where the source code of the program + and build instructions can be found so that the program can be + configured in such a manner that the result file is ideally + recreatable yielding the same results. + + - diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml new file mode 100644 index 0000000000..ca4a569845 --- /dev/null +++ b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml @@ -0,0 +1,183 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of parallelograms. + + + + + Computational geometry description of a set of parallelograms in Euclidean space. + + The parallelograms do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe rectangles or squares, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of e.g. a region of interest in the 2D plane. In this case the alignment + with axes is not relevant as eventually relevant is only the area of the ROI. + * In other cases the extent of the parallelogram is relevant though. + * Finally in CAD models we would like to specify the polygon + which is parallelogram represents. + + Parallelograms are important geometrical primitives. Not so much because of their + uses in nowadays, thanks to improvements in computing power, not so frequently + any longer performed 2D simulation. Many scanning experiments probe though + parallelogram-shaped ROIs on the surface of samples. + + Parallelograms have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term parallelogram will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + rectangle, square, 2D box, axis-aligned bounding box (AABB), or + optimal bounding box (OBB) but here the analogous 2D cases. + + An axis-aligned bounding box is a common data object in computational science + and codes to represent a rectangle whose edges are aligned with the axes + of a coordinate system. As a part of binary trees these are important data + objects for time- as well as space-efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Other than in 3D dimensions the rotation calipher method offers + a rigorous approach to compute optimal bounding boxes in 2D. + + + + + + + + + + + A qualitative description of each parallelogram/rectangle/square/box. + + + + + + + + + Qualifier how one edge is longer than all the other edge of the parallelogam. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of an edge within + a specific coordinate system. + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the parallelogram. + + + + + + + + + + + + + + Only to be used if is_box is present. In this case, this field describes + whether parallelograms are rectangles/squares whose primary edges + are parallel to the axes of the Cartesian coordinate system. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + parallelograms. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish parallelograms for explicit indexing. + + + + + + + + + + + + + + + A simple approach to describe the entire set of parallelograms when the + main intention is to store the shape of the parallelograms for visualization. + + + + + + Disentangled representations of the mesh of specific parallelograms. + + + + diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml new file mode 100644 index 0000000000..e5c351839c --- /dev/null +++ b/contributed_definitions/NXcg_point_set.nxdl.xml @@ -0,0 +1,98 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 1. + + + + + The cardinality of the set, i.e. the number of points. + + + + + Computational geometry description of a set of points in Euclidean space. + + The relevant coordinate system should be referred to in the NXtransformations + instance. Points may have an associated time value; however users are advised + to store time data of point sets rather as instances of time events, where + for each point in time there is an NXcg_point_set instance which specifies the + points locations. This is a frequent situation in experiments and computer + simulations, where positions of points are taken at the same point in time; + and therefore an additional time array would demand to store redundant pieces + of information for each point. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for points. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish points for explicit indexing. + + + + + + + + The array of point coordinates. + + + + + + + + + The optional array of time for each vertex. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml new file mode 100644 index 0000000000..e90dd652f4 --- /dev/null +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -0,0 +1,225 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be either 2 or 3. + + + + + The cardinality of the set, i.e. the number of polygons. + + + + + + The total number of vertices when visiting every polygon. + + + + + + Computational geometry description of a set of polygons in Euclidean space. + + Polygons are related are specialized polylines: + + * A polygon is a geometric primitive that is bounded by a closed polyline + * All vertices of this polyline lay in the d-1 dimensional plane. + whereas vertices of a polyline do not necessarily lay on a plane. + * A polygon has at least three vertices. + + Each polygon is built from a sequence of vertices (points with identifiers). + The members of a set of polygons may have a different number of vertices. + Sometimes a collection/set of polygons is referred to as a soup of polygons. + + As three-dimensional objects, a set of polygons can be used to define the + hull of what is effectively a polyhedron; however users are advised to use + the specific NXcg_polyhedron_set base class if they wish to describe closed + polyhedra. Even more general complexes can be thought, for instance + piecewise-linear complexes, as these can have holes though, polyhedra without + holes are one subclass of such complexes, users should rather design an own + base class e.g. NXcg_polytope_set to describe such even more + complex primitives. + + + + + + + + + + + + Integer which specifies the first index to be used for distinguishing + polygons. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polygons for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of polygons when the + main intention is to store the shape of the polygons for visualization. + + + + + + + + + + + + + + + The accumulated length of the polygon edge. + + + + + + + + Array of interior angles. There are many values per polygon as number_of_vertices. + The angle is the angle at the specific vertex, i.e. between the adjoining + edges of the vertex according to the sequence in the polygons array. + Usually, the winding_order field is required to interpret the value. + + + + + + + + Curvature type: + + * 0 - unspecified, + * 1 - convex, + * 2 - concave + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml new file mode 100644 index 0000000000..e3a6e99fe4 --- /dev/null +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -0,0 +1,194 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of polyhedra. + + + + + The total number of edges for all polyhedra. + + + + + The total number of faces for all polyhedra. + + + + + Computational geometry description of a polyhedra in Euclidean space. + + Polyhedra, also so-called cells (especially in the convex of tessellations), + here described have to be all non-degenerated, closed, built of and thus + built out of not-self-intersecting polygon meshes. Polyhedra may make contact, + so that this base class can be used for a future description of tessellations. + + For more complicated manifolds and especially for polyhedra with holes, users + are advised to check if their particular needs are described by creating + (eventually customized) instances of an NXcg_polygon_set, which can be + extended for the description of piecewise-linear complexes. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the polyhedra. + + + + + + + + + Total surface area as the sum of all faces. + + + + + + + + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. This field can be used to interpret + the array/field with the individual area values for each face. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + The number of edges for each polyhedron. Edges of adjoining polyhedra + are counterd for each polyhedron. This field can be used to interpret + the array/field with the individual length for each edge. + + + + + Length of each edge of each tetrahedron. + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + polyhedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polyhedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of polyhedra when the + main intention is to store the shape of the polyhedra for visualization. + + + + + + Disentangled representations of the mesh of specific polyhedron. + + + + + + Disentangled representation of the planar graph that each polyhedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + + diff --git a/base_classes/NXcg_polyline_set.nxdl.xml b/contributed_definitions/NXcg_polyline_set.nxdl.xml similarity index 51% rename from base_classes/NXcg_polyline_set.nxdl.xml rename to contributed_definitions/NXcg_polyline_set.nxdl.xml index f57d0c53f6..b64c3467d6 100644 --- a/base_classes/NXcg_polyline_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyline_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -50,29 +50,58 @@ multiple vertices possible with the same point coordinates but different names.- - Computational geometry description of a set of polylines. + Computational geometry description of a set of polylines in Euclidean space. Each polyline is built from a sequence of vertices (points with identifiers). Each polyline must have a start and an end point. - The sequence describes the positive traversal along the polyline when - walking from the first to the last vertex. + The sequence describes the positive traversal along the polyline when walking + from the start vertex to the end/last vertex. - + + + + - The total number of vertices that have different positions. + The total number of vertices, irrespective of their eventual uniqueness, + i.e. the total number of vertices that have to be visited when walking + along each polyline. - + - The total number of vertices, irrespective of their eventual uniqueness. + Array which specifies of how many vertices each polyline is built. + The number of vertices represent the total number of vertices for + each polyline, irrespectively whether vertices are shared or not. + See the docstring for polylines for further details about how + a set with different polyline members should be stored. + + + - + - The total number of vertices of each polyline, irrespectively - whether vertices are shared by vertices or not. - See the docstring for polylines for further details about how - a set with different polyline members should be stored. + Reference to or definition of a coordinate system with + which the qualifiers and polyline data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + polylines. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish polylines for explicit indexing. @@ -82,57 +111,73 @@ multiple vertices possible with the same point coordinates but different names.- Unique means not necessarily unique in position only but also unique in identifier. In fact, it is possible to distinguish two vertices as two when they share the same position in space but have different identifiers.--> - + Positions of the vertices which support the members of the polyline set. - Users are encouraged to reduce the vertices to unique positions and vertices - as this often supports with storing geometry data more efficiently. - It is also possible though to store the vertex positions naively - in which case vertices_are_unique is likely False. - Naively, here means that one stores each vertex of a triangle mesh - even though many vertices are shared between triangles and thus - storing multiple copies of their positions is redundant. + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. - If true indicates that the vertices are all placed at different positions and have different identifiers, i.e. no points overlap - or are counted several times. + or are counted twice. - Sequence of identifier for vertices how they build each polyline. + Sequence of vertex identifiers which describe each polyline. A trivial example is a set with two polylines with three vertices each. If the polylines meet in a junction, say the second vertex is shared and marking the junction between the two polylines, it is possible that - there are only five unique positions. This suggests to store five - unique vertices. + there are only five unique positions suggesting five unique vertices. - A non-trivial example is a set with several polylines. Assume that each - has a different number of vertices. The array stores the identifier of - the vertices in the sequence how the polylines are visited: + A non-trivial example is a set with several polylines, each of which with + eventually different number of vertices. The array stores the vertex + identifiers in the order how the polylines are visited: - The first entry is the identifier of the first vertex of the first polyline, + The first entry is the identifier of the start vertex of the first polyline, followed by the second vertex of the first polyline, until the last vertex - of the first polyline. - Thereafter, the first vertex of the second polyline, and so on and so forth. - Using the (cumulated) counts in number_of_vertices, the vertices of the - n-th polyline can be accessed on the following array index interval: + of the polyline. Thereafter, the start vertex of the second polyline, and + so on and so forth. Using the (cumulated) counts in number_of_vertices, + the vertices of the n-th polyline can be accessed on the following + array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. + + + + The length of each polyline. + + + + + + + + If true specifies that a polyline is closed, i.e. + its end point is connected to the start point. + + + + + + + diff --git a/contributed_definitions/NXcg_roi_set.nxdl.xml b/contributed_definitions/NXcg_roi_set.nxdl.xml new file mode 100644 index 0000000000..ab2b677754 --- /dev/null +++ b/contributed_definitions/NXcg_roi_set.nxdl.xml @@ -0,0 +1,40 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Base class to hold geometric primitives. + + + + + + + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml new file mode 100644 index 0000000000..e50192cf85 --- /dev/null +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -0,0 +1,121 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of circles or spheres. + + + + + Computational geometry description of a set of spheres in Euclidean space. + + Each sphere can have a different radius. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for spheres. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish spheres for explicit indexing. + + + + + + + + Geometric center of the spheres. This can be the center of mass. + Dimensionality and cardinality of the point and sphere set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the spheres. + + + + + + + + + In the case that all spheres have the same radius. + + + + + In the case that spheres have different radius use this + instead of the radius field. + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + Are the spheres closed or hollow? + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml new file mode 100644 index 0000000000..b3e27b0f93 --- /dev/null +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -0,0 +1,175 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of tetrahedra. + + + + + Computational geometry description of a set of tetrahedra in Euclidean space. + + The tetrahedra do not have to be connected. + As tetrahedral elements they are among hexahedral elements one of the most + frequently used geometric primitive for meshing and describing volumetric + and surface descriptions of objects at the continuum scale. + + A set of tetrahedra in 3D Euclidean space. + + The tetrahedra do not have to be connected, can have different size, + can intersect, and be rotated. + + Tetrahedra are the simplest and thus important geometrical primitive. + They are frequently used as elements in finite element meshing/modeling. + + Tetrahedra have to be non-degenerated, closed, and built of triangles + which are not self-intersecting. + + + + + + + + + + + Interior volume + + + + + + + + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the tetrahedra. + + + + + + + + + Total surface area as the sum of all four triangular faces. + + + + + + + + Area of each of the four triangular faces of each tetrahedron. + + + + + + + + + Length of each edge of each tetrahedron. + + + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + + + + + Integer which specifies the first index to be used for distinguishing + tetrahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish tetrahedra for explicit indexing. + + + + + + + + + + + + + A simple approach to describe the entire set of tetrahedra when the + main intention is to store the shape of the tetrahedra for visualization. + should take the possibility to describe + + + + + + Disentangled representations of the mesh of specific tetrahedra. + + + + + + Disentangled representation of the planar graph that each tetrahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml new file mode 100644 index 0000000000..3640f8ff30 --- /dev/null +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -0,0 +1,132 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality, which has to be at least 2. + + + + + The cardinality of the set, i.e. the number of triangles. + + + + + The number of unique vertices supporting the triangles. + + + + + Computational geometry description of a set of triangles in Euclidean space. + + + + + + + Reference to or definition of a coordinate system with + which the qualifiers and primitive data are interpretable. + + + + + Integer which specifies the first index to be used for distinguishing + triangles. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish triangles for explicit indexing. + + + + + + + + + A simple approach to describe the entire set of triangles when the + main intention is to store the shape of the triangles for visualization. + + + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + + + + + + + + + The center of mass of each polygon. + + + + + + + + + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + + diff --git a/base_classes/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml similarity index 50% rename from base_classes/NXcg_ellipsoid_set.nxdl.xml rename to contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml index e22a677c11..51ec02bfd1 100644 --- a/base_classes/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml @@ -1,10 +1,10 @@ - + - - + The symbols used in the schema to specify e.g. dimensions of arrays. - - - The dimensionality of the space in which the members are assumed embedded. - - - - - The cardinality of the set, i.e. the number of members. - - - Computational geometry description of a set of ellipsoids. + Computational geometry description of a mesh of triangles. + + The mesh may be self-intersecting and have holes but the + triangles must not be degenerated. - - - Radius of the half axes. - - Use if all ellipsoids in the set have the same half-axes. - - - - - - + + + - Half-axes radii of each ellipsoid. + A graph-based approach to describe the mesh when it is also desired + to perform topological processing or analyses on the mesh. - - - - - - + diff --git a/base_classes/NXcg_unit_normal_set.nxdl.xml b/contributed_definitions/NXcg_unit_normal_set.nxdl.xml similarity index 71% rename from base_classes/NXcg_unit_normal_set.nxdl.xml rename to contributed_definitions/NXcg_unit_normal_set.nxdl.xml index 21470b34f0..68f9c847e2 100644 --- a/base_classes/NXcg_unit_normal_set.nxdl.xml +++ b/contributed_definitions/NXcg_unit_normal_set.nxdl.xml @@ -1,10 +1,10 @@ - + - - - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -44,14 +42,12 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Computational geometry description of a set of (oriented) unit normal vectors. - - Store normal vector information as properties of primitives. - Use only only as a child of an instance of :ref:`NXcg_primitive_set` - so that this instance acts as the parent to define a context. - + + + - Direction of each normal - a unit normal. + Direction of each normal @@ -60,13 +56,12 @@ rather make this a set of vectors, irrespective whether these are unit or not--> - Qualifier which details the orientation of each normal vector - in relation to its primitive, assuming the object is viewed - from a position outside the object. + Qualifier how which specifically oriented normal to its primitive each + normal represents. * 0 - undefined - * 1 - outer unit normal vector - * 2 - inner unit normal vector + * 1 - outer + * 2 - inner diff --git a/base_classes/NXchamber.nxdl.xml b/contributed_definitions/NXchamber.nxdl.xml similarity index 76% rename from base_classes/NXchamber.nxdl.xml rename to contributed_definitions/NXchamber.nxdl.xml index f6cbac9137..edf318e2af 100644 --- a/base_classes/NXchamber.nxdl.xml +++ b/contributed_definitions/NXchamber.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Base class for a chamber in an instrument that stores real or simulated objects. + Component of an instrument to store or place objects and specimens. - + - Given name for the chamber of this component e.g. analysis chamber - or buffer chamber, load-lock chamber, microscope column, glove box. + Given name/alias. - + Free-text field for describing details about the chamber. For example out of which material was the chamber built. diff --git a/base_classes/NXchemical_composition.nxdl.xml b/contributed_definitions/NXchemical_composition.nxdl.xml similarity index 100% rename from base_classes/NXchemical_composition.nxdl.xml rename to contributed_definitions/NXchemical_composition.nxdl.xml diff --git a/contributed_definitions/NXcircuit_board.nxdl.xml b/contributed_definitions/NXcircuit_board.nxdl.xml new file mode 100644 index 0000000000..4e64e65bc6 --- /dev/null +++ b/contributed_definitions/NXcircuit_board.nxdl.xml @@ -0,0 +1,45 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Circuit board with e.g. ADC and/or DAC electronic components. + + Currently used to store the settings of the so-called magboards used in + Nion electron microscopes but likely this could be a useful base class for + substantially more use cases where details at a deep technical instrument design + level are relevant or important. + + + + TBD by Nion Co. + + + + + diff --git a/contributed_definitions/NXclustering.nxdl.xml b/contributed_definitions/NXclustering.nxdl.xml new file mode 100644 index 0000000000..76351758dd --- /dev/null +++ b/contributed_definitions/NXclustering.nxdl.xml @@ -0,0 +1,124 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of numeral labels per object. + + + + + Number of categorical labels per object. + + + + + Total number of clusters detected. + + + + + Metadata to the results of a clustering analysis. + + Clustering algorithms are routine tools to segment a set of objects/primitives + into groups, objects of different type. A plethora of algorithms have been + proposed for geometric primitives as objects, such as points, triangles, + or (abstract) objects. + + This base class considers metadata and results of one clustering + applied to a set in which objects are either categorized as noise + or belonging to a cluster, specifically here only one cluster. + + + + How many numeric labels does each object have. + + + + + How many categorical labels does each object have. + + + + + Reference to a set of objects investigated in a cluster analysis. + Objects must have clear integer identifier. + + + + + Reference to numeric attribute data for each object. + + + + + Reference to categorical attribute data for each object. + + + + + + Which identifier is the first to be used to label a cluster. + + The value should be chosen in such a way that special values can be resolved: + * identifier_offset-1 indicates an object belongs to no cluster. + * identifier_offset-2 indicates an object belongs to the noise category. + Setting for instance identifier_offset to 1 recovers the commonly used + case that objects of the noise category get values to -1 and unassigned points to 0. + + + + + Total number of objects categorized as unassigned. + + + + + Total number of objects categorized as noise. + + + + + Total number of clusters (excluding noise and unassigned). + + + + + Number of objects associated to each cluster. The labels are implicit, + meaning the zeroth/first entry in the array belongs to the first cluster, + the second entry to the second cluster and so on and so forth. + The first cluster has the value of identifier_offset as its identifier. + The second cluster has identifier_offset + 1, and so on and so forth. + + + + + + + diff --git a/base_classes/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXcollectioncolumn.nxdl.xml similarity index 73% rename from base_classes/NXcollectioncolumn.nxdl.xml rename to contributed_definitions/NXcollectioncolumn.nxdl.xml index 3f87c37c4c..5348d55b5f 100644 --- a/base_classes/NXcollectioncolumn.nxdl.xml +++ b/contributed_definitions/NXcollectioncolumn.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Subclass of NXelectronanalyser to describe the electron collection - column of a photoelectron analyser. + Subclass of NXelectronanalyser to describe the electron collection column of a + photoelectron analyser. - Scheme of the electron collection lens, i.e. angular dispersive, - spatial dispersive, momentum dispersive, non-dispersive, etc. + Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum + microscope, etc. @@ -48,7 +48,7 @@ Distance between sample and detector entrance - + Labelling of the lens setting in use. @@ -62,20 +62,6 @@ - - - Acceptance angle of the collection column. - - This concept is related to term `7.4`_ of the ISO 18115-1:2023 standard. - - .. _7.4: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:7.4 - - - - - Acceptance length or area of the collection column. - - The magnification of the electron lens assembly. @@ -99,19 +85,6 @@ the reference coordinate system. - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - The size and position of an aperture inserted in the column, e.g. field aperture @@ -128,5 +101,4 @@ Individual lenses in the collection column section - diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/contributed_definitions/NXcoordinate_system_set.nxdl.xml new file mode 100644 index 0000000000..c2276f3a93 --- /dev/null +++ b/contributed_definitions/NXcoordinate_system_set.nxdl.xml @@ -0,0 +1,137 @@ + + + + + + Container to hold different coordinate systems conventions. + + It is the purpose of this base class to define these conventions and + offer a place to store mappings between different coordinate systems + which are relevant for the interpretation of the data described + by the application definition and base class instances. + + For each Cartesian coordinate system users should use a set of + NXtransformations: + + * These should define the three base vectors. + * The location of the origin. + * The affine transformations which bring each axis of this coordinate system + into registration with the McStas coordinate system. + * Equally, affine transformations should be given for the inverse mapping. + + As an example one may take an experiment or computer simulation where + there is a laboratory (lab) coordinate system, a sample/specimen coordinate + system, a crystal coordinate system, and additional coordinate systems, + which are eventually attached to components of the instrument. + + If no additional transformation is specified in this group or if an + instance of an NXcoordinate_system_set is absent it should be assumed + the so-called McStas coordinate system is used. + + Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. + This is a Cartesian coordinate system whose z axis points along the neutron + propagation axis. The systems y axis is vertical up, while the x axis points + left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. + + Within each NXtransformations a depends_on section is required. The depends_on + field specifies if the coordinate system is the root/reference + (which is indicated by writing "." in the depends_on section.) + + + + + A group of transformations which specify: + + * Three base vectors of the coordinate system. + * Origin of the coordinate system. + * A depends_on keyword. Its value can be "." or the name of an + NXtransformations instance which needs to exist in the + NXcoordinate_system_set instance. + * If the coordinate system is the reference one it has to be named + reference. + + In case of having more than one NXtransformations there has to be for + each additional coordinate system, i.e. the one not the reference: + + * A set of translations and rotations which map each base vector to the reference. + * A set of translations and rotations which map each reference base vector + to the coordinate system. + + The NXtransformations for these mappings need to be formatted + according to the descriptions in NXtransformations. + + + + + + + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml new file mode 100644 index 0000000000..fcca05d7a1 --- /dev/null +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -0,0 +1,95 @@ + + + + + + Corrector for aberrations in an electron microscope. + + Different technology partners use different naming schemes and models + for quantifying the aberration coefficients. + + The corrector in an electron microscope is composed of multiple lenses and + multipole stigmators with vendor-specific details which are often undisclosed. + + + + Was the corrector used? + + + + + Given name/alias. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. If this does not exist + a free-text field to report further details about the corrector. + + + + + + Specific information about the concrete alignment procedure which is a + process during which the corrector is configured to enable a calibrated + usage of the microscope. + + + + Discouraged free-text field to add further details about the alignment + procedure. + + + + + The outer tilt angle of the beam in tableau aquisition. + + + + + The exposure time of the single tilt images. + + + + + The factor of enlargement of the apparent size, + not physical size, of an object. + + + + + Place for storing measured or estimated aberrations (for each image or final). + + + + + + + + + + diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/contributed_definitions/NXcs_computer.nxdl.xml new file mode 100644 index 0000000000..b6cd467a2b --- /dev/null +++ b/contributed_definitions/NXcs_computer.nxdl.xml @@ -0,0 +1,80 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a set of computing nodes. + + + + Given name/alias to the computing system, e.g. MyDesktop. + + + + + Name of the operating system, e.g. Windows, Linux, Mac, Android. + + + + Version plus build number, commit hash, or description of an ever + persistent resource where the source code of the program and build + instructions can be found so that the program can be configured in + such a manner that the result file is ideally recreatable yielding + the same results. + + + + + + + Ideally a (globally) unique persistent identifier of the computer, i.e. + the Universally Unique Identifier (UUID) of the computing node. + + + + + + A list of physical processing units (can be multi-core chips). + + + + + A list of physical coprocessor/graphic cards/accelerator units. + + + + + Details about the memory sub-system. + + + + + Details about the I/O sub-system. + + + diff --git a/contributed_definitions/NXcs_cpu.nxdl.xml b/contributed_definitions/NXcs_cpu.nxdl.xml new file mode 100644 index 0000000000..b27b87481d --- /dev/null +++ b/contributed_definitions/NXcs_cpu.nxdl.xml @@ -0,0 +1,39 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a central processing unit (CPU) of a computer. + + + + Given name of the CPU. Users should be as specific as possible. + + + + diff --git a/base_classes/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml similarity index 53% rename from base_classes/NXcs_filter_boolean_mask.nxdl.xml rename to contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index c8b1f0457e..fe1707aa14 100644 --- a/base_classes/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -1,4 +1,4 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -43,41 +43,33 @@ - Base class for packing and unpacking booleans. + Computer science base class for packing and unpacking booleans. - This base class bookkeeps metadata to inform software about necessary modulo - operations to decode e.g. set membership of objects in sets which are encoded - as a packed array of boolean values. + One use case is processing of object sets (like point cloud data). + When one applies e.g. a spatial filter to a set of points to define which + points are analyzed and which not, it is useful to document which points were + taken. One can store this information in a compact manner with an array of + boolean values. If the value is True the point is taken, else it is not. - One use case is processing of object sets (e.g. point cloud data). If e.g. a - spatial filter has been applied to a set of points we may wish to store - document efficiently which points were analyzed. Array of boolean values - is one option to achieve this. A value is true if the point is included. - The resulting boolean array will be filled with true and false values - in a manner that is often arbitrary and in general case-dependent. + If the points are identified by an array of integer identifiers and an + arbitrary spatial filtering, the boolean array will be filled with True and False + values in an arbitrary manner. Especially when the number of points is large, + for instance several thousands and more, some situations can be more efficiently + stored if one would not store the boolean array but just list the identifiers + of the points taken. For instance if within a set of 1000 points only one point is + taken, it would take (naively) 4000 bits to store the array but only 32 bits + to store e.g. the ID of that taken point. Of course the 4000 bit field is so + sparse that it could be compressed resulting also in a substantial reduction + of the storage demands. Therefore boolean masks are useful compact descriptions + to store information about set memberships in a compact manner. + In general it is true, though, that which representation is best, i.e. + most compact (especially when compressed) depends strongly on occupation of + the array. - Especially when the number of points is large, for instance several thousands - or more, some situations can be more efficiently stored if one does not store - the boolean array but just lists the identifiers of the points taken. - - For example, if within a set of 1000 points only one point is included, it would - take (naively) 4000 bits to store the array but only 32 bits to store e.g. the - ID of the single point that is taken. Of course the 4000 bit field is so - sparse that it could be compressed resulting also in a substantial reduction - of the storage demands. Therefore, boolean masks are useful in that - they store compact representation of set memberships. - - This base class can deal with the situation when the number of objects - is not an integer multiple of the bit depth used for storing the states. + This base class just bookkeeps metadata to inform software about necessary + modulo operations to decode the set membership of each object. This is useful + because the number of objects not necessarily is an integer multiple of the bit depth. - - - Possibility to refer to which set this mask applies. - - If depends_on is not provided, it is assumed that the mask - applies to its direct parent. - - Number of objects represented by the mask. @@ -91,21 +83,19 @@ - The content of the mask. If padding is used, - padding bits have to be set to 0. + The unsigned integer array representing the content of the mask. + If padding is used the padded bits have to be set to 0. - + Link to/or array of identifiers for the objects. The decoded mask is interpreted consecutively, i.e. the first bit in the mask matches to the first identifier, the second bit in the mask to the second - identifier and so on and so forth. Resolving of identifier follows - the conventions made for depends_on, so consult also the description - of th content to which depends_on refers. + identifier and so on and so forth. diff --git a/contributed_definitions/NXcs_gpu.nxdl.xml b/contributed_definitions/NXcs_gpu.nxdl.xml new file mode 100644 index 0000000000..3392e41d39 --- /dev/null +++ b/contributed_definitions/NXcs_gpu.nxdl.xml @@ -0,0 +1,39 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a graphic processing unit (GPU) of a computer. + + + + Given name of the GPU. Users should be as specific as possible. + + + + diff --git a/base_classes/NXidentifier.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml similarity index 55% rename from base_classes/NXidentifier.nxdl.xml rename to contributed_definitions/NXcs_io_obj.nxdl.xml index ce05800f9e..eb1e7e19c5 100644 --- a/base_classes/NXidentifier.nxdl.xml +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -1,10 +1,10 @@ - + - + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + - An identifier for a (persistent) resource, e.g., a DOI or orcid. + Computer science description of a storage object in an input/output system. - + - The service by which the resource can be resolved. - - Examples: doi, urn, hdl, purl, orcid, iso, url + Qualifier for the type of storage medium used. + + + + + - + + - The unique code, IRI or hash to resolve this reference. - Typically, this is stated by the service which is considered a complete - identifier, e.g., for a DOI it's something of the form `10.1107/S1600576714027575` - or `https://doi.org/10.1107/S1600576714027575`, which are both resolvable. + Total amount of data which the medium can hold. - + + - True if the identifier is persistent (i.e., unique and available indefinitely), - False otherwise. + Given name to the I/O unit. + diff --git a/base_classes/NXroi.nxdl.xml b/contributed_definitions/NXcs_io_sys.nxdl.xml similarity index 75% rename from base_classes/NXroi.nxdl.xml rename to contributed_definitions/NXcs_io_sys.nxdl.xml index 94857e74cb..5608c9f886 100644 --- a/base_classes/NXroi.nxdl.xml +++ b/contributed_definitions/NXcs_io_sys.nxdl.xml @@ -1,10 +1,10 @@ - + - - - Base class to describe a region-of-interest analyzed. - - + + - Details about processing steps. + The symbols used in the schema to specify e.g. dimensions of arrays. - - + + + Computer science description of system of a computer. + + diff --git a/base_classes/NXem_method.nxdl.xml b/contributed_definitions/NXcs_mm_sys.nxdl.xml similarity index 57% rename from base_classes/NXem_method.nxdl.xml rename to contributed_definitions/NXcs_mm_sys.nxdl.xml index e5e0dc0740..d9c6779fd8 100644 --- a/base_classes/NXem_method.nxdl.xml +++ b/contributed_definitions/NXcs_mm_sys.nxdl.xml @@ -1,4 +1,4 @@ - + - + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for - each method e.g. :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + Computer science description of a main memory system of a computer. - + - Details about processing steps. + How much physical memory does the system provide. - - - - - + + diff --git a/base_classes/NXcs_prng.nxdl.xml b/contributed_definitions/NXcs_prng.nxdl.xml similarity index 62% rename from base_classes/NXcs_prng.nxdl.xml rename to contributed_definitions/NXcs_prng.nxdl.xml index 911faf63c6..16d192c4c3 100644 --- a/base_classes/NXcs_prng.nxdl.xml +++ b/contributed_definitions/NXcs_prng.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -30,25 +30,21 @@ Computer science description of pseudo-random number generator. - The purpose of this base class is to identify if exactly the same sequence + The purpose of such metadata is to identify if exactly the same sequence can be reproduced, like for a PRNG or not (for a true physically random source). - + - Physical approach or algorithm whereby random numbers are generated. - Different approaches for generating random numbers with a computer exists. - Some use a dedicated physical device whose the state is unpredictable - (physically). Some use a strategy of mangling information from the system - clock. Also in this case the sequence is not reproducible without having - additional pieces of information. - - In most cases though so-called pseudo-random number generator (PRNG) - algorithms are used. These yield a deterministic sequence of practically - randomly appearing numbers. These algorithms differ in their quality in - how close the resulting sequences are random, i.e. sequentially - uncorrelated. Nowadays one of the most commonly used algorithm is the - MersenneTwister (mt19937). + Some use a dedicated physical device where the state is unpredictable (physically). + Some use a mangling of the system clock (system_clock), where also without + additional pieces of information the sequence is not reproducible. + Some use so-called pseudo-random number generator (PRNG) are used. + These are algorithms which yield a deterministic sequence of practically + randomly appearing numbers. These algorithms different in their quality in + how close the resulting sequences are random. + Nowadays one of the most commonly used algorithm is + the MersenneTwister (mt19937). @@ -57,24 +53,30 @@ - + Name of the PRNG implementation and version. If such information is not available or if the PRNG type was set to other the DOI to the publication or the source code should be given. - - + + + Version and build number, or commit hash. + + + + - Parameter of the PRNG controlling its initialization - and thus controlling the specific sequence generated. + Parameter of the PRNG controlling its initialization and thus the specific + sequence of numbers it generates. - + + - Number of initial draws from the PRNG after its initialized with the seed. - These initial draws are typically discarded in an effort to equilibrate the - sequence. If no warmup was performed or if warmup procedures are unclear, + Number of initial draws from the PRNG which are discarded in an effort + to equilibrate the sequence and make it thus to statistically more random. + If no warmup was performed or if warmup procedures are unclear, users should set the value to zero. diff --git a/base_classes/NXcs_profiling.nxdl.xml b/contributed_definitions/NXcs_profiling.nxdl.xml similarity index 72% rename from base_classes/NXcs_profiling.nxdl.xml rename to contributed_definitions/NXcs_profiling.nxdl.xml index d37224f9cb..97105a1b25 100644 --- a/base_classes/NXcs_profiling.nxdl.xml +++ b/contributed_definitions/NXcs_profiling.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computer science description for performance and profiling data of an application. + Computer science description for summary performance/profiling data of an application. Performance monitoring and benchmarking of software is a task where questions can be asked at various levels of detail. In general, there are three main @@ -38,29 +38,28 @@ * Software configuration and capabilities * Dynamic effects of the system in operation and the system working together with eventually multiple computers, especially when these have to exchange - information across a network and these are used usually by multiple users. + information across a network. At the most basic level users may wish to document how long e.g. a data - analysis with a scientific software (app) took. - A frequent idea is here to answer practical questions like how critical is the - effect on the workflow of the scientists, i.e. is the analysis possible in - a few seconds or would it take days if I were to run this analysis on a - comparable machine? - For this more qualitative performance monitoring, mainly the order of - magnitude is relevant, as well as how this was achieved using parallelization - (i.e. reporting the number of CPU and GPU resources used, the number of - processes and threads configured, and providing basic details about the computer). + analysis with a scientific software (app). + A frequent idea is here to judge how critical the effect is on the workflow + of the scientists, i.e. is the analysis possible in a few seconds or would it + take days if I were to run this analysis on a comparable machine. In this case, + mainly the order of magnitude is relevant, as well as how this can be achieved + with using parallelization (i.e. reporting the number of CPU and GPU resources + used, the number of processes and/or threads, and basic details about the + computing node/computer. At more advanced levels benchmarks may go as deep as detailed temporal tracking of individual processor instructions, their relation to other instructions, the - state of call stacks; in short eventually the entire app execution history + state of call stacks, in short eventually the entire app execution history and hardware state history. Such analyses are mainly used for performance - optimization, i.e. by software and hardware developers as well as for - tracking bugs. Specialized software exists which documents such performance - data in specifically-formatted event log files or databases. + optimization as well as for tracking bugs and other development purposes. + Specialized software exists which documents such performance data in + specifically-formatted event log files or databases. - This base class cannot and should not replace these specific solutions for now. - Instead, the intention of the base class is to serve scientists at the + This base class cannot and should not replace these specific solutions. + Instead, the intention of the base class is to serve scientists at the basic level to enable simple monitoring of performance data and log profiling data of key algorithmic steps or parts of computational workflows, so that these pieces of information can guide users which order of magnitude differences @@ -71,12 +70,12 @@ the metadata in this base class. - + Path to the directory from which the tool was called. - + Command line call with arguments if applicable. @@ -98,15 +97,15 @@ Wall-clock time how long the app execution took. This may be in principle end_time minus start_time; however usage of eventually more precise timers may warrant to use a finer temporal discretization, - and thus demands a more precise record of the wall-clock time. + and thus demand a more precise record of the wall-clock time. - + - Qualifier which specifies with how many nominal processes the app was - invoked. The main idea behind this field e.g. for apps which use e.g. MPI - (Message Passing Interface) parallelization is to communicate - how many processes were used. + Qualifier which specifies with how many nominal processes the app was + invoked. The main idea behind this field, for instance for app using a + Message Passing Interface parallelization is to communicate how many + processes were used. For sequentially running apps number_of_processes and number_of_threads is 1. If the app uses exclusively GPU parallelization number_of_gpus @@ -115,14 +114,14 @@ used though. - + - Qualifier how many nominal threads were used at runtime. - Specifically here the maximum number of threads used for the + Qualifier with how many nominal threads were accessible to the app at + runtime. Specifically here the maximum number of threads used for the high-level threading library used (e.g. OMP_NUM_THREADS), posix. - + Qualifier with how many nominal GPUs the app was invoked at runtime. @@ -130,7 +129,8 @@ +complicated models should be captured. +how can you have an empty list?--> A collection with one or more computing nodes each with own resources. diff --git a/base_classes/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml similarity index 82% rename from base_classes/NXcs_profiling_event.nxdl.xml rename to contributed_definitions/NXcs_profiling_event.nxdl.xml index 9da91f9c04..195dee88c6 100644 --- a/base_classes/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -47,34 +47,31 @@ included when the event tracking ended. - + Free-text description what was monitored/executed during the event. - Wall-clock time how long the event took. - - This may be in principle end_time minus start_time; however usage of - eventually more precise timers may warrant to use a finer temporal - discretization, and thus demand for a more precise record of the - wall-clock time. - + Wall-clock time how long the event took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. Elapsed time may contain time portions where resources were idling. - + Number of processes used (max) during the execution of this event. - + Number of threads used (max) during the execution of this event. - + Number of GPUs used (max) during the execution of this event. diff --git a/contributed_definitions/NXdac.nxdl.xml b/contributed_definitions/NXdac.nxdl.xml new file mode 100644 index 0000000000..44583e2516 --- /dev/null +++ b/contributed_definitions/NXdac.nxdl.xml @@ -0,0 +1,38 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Digital-to-analog converter component/integrated circuit. + + + + TBD. + + + diff --git a/base_classes/NXdeflector.nxdl.xml b/contributed_definitions/NXdeflector.nxdl.xml similarity index 77% rename from base_classes/NXdeflector.nxdl.xml rename to contributed_definitions/NXdeflector.nxdl.xml index 10e699c881..abdea5bbbf 100644 --- a/base_classes/NXdeflector.nxdl.xml +++ b/contributed_definitions/NXdeflector.nxdl.xml @@ -1,10 +1,10 @@ - + - + Deflectors as they are used e.g. in an electron analyser. - + - Qualitative type of deflector with respect to the number of pole pieces. + Qualitative type of deflector with respect to the number of pole pieces @@ -36,54 +36,52 @@ - + Colloquial or short name for the deflector. For manufacturer names and identifiers use respective manufacturer fields. - - + - Ideally an identifier, persistent link, or free text which gives - further details about the deflector. + Name of the manufacturer who built/constructed the deflector. - + - Excitation voltage of the deflector. For dipoles it is a single number. - For higher order multipoles, it is an array. + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the deflector. - + - Excitation current of the deflector. For dipoles it is a single number. For - higher orders, it is an array. + Ideally an identifier, persistent link, or free text which gives further details + about the deflector. - + - Spatial offset of the deflector in x direction (perpendicular to - ```offset_y```). + Excitation voltage of the deflector. For dipoles it is a single number. For + higher orders, it is an array. - + - Spatial offset of the deflector in y direction (perpendicular to - ```offset_x```). + Excitation current of the deflector. For dipoles it is a single number. For + higher orders, it is an array. - + Specifies the position of the deflector by pointing to the last transformation in the transformation chain in the NXtransformations group. - + Collection of axis-based translations and rotations to describe the location and geometry of the deflector as a component in the instrument. Conventions from the - :ref:`NXtransformations` base class are used. In principle, the McStas coordinate + NXtransformations base class are used. In principle, the McStas coordinate system is used. The first transformation has to point either to another component of the system or . (for pointing to the reference frame) to relate it relative to the experimental setup. Typically, the components of a system should diff --git a/base_classes/NXdistortion.nxdl.xml b/contributed_definitions/NXdistortion.nxdl.xml similarity index 100% rename from base_classes/NXdistortion.nxdl.xml rename to contributed_definitions/NXdistortion.nxdl.xml diff --git a/base_classes/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml similarity index 59% rename from base_classes/NXebeam_column.nxdl.xml rename to contributed_definitions/NXebeam_column.nxdl.xml index d4fc0f1538..03b54b7792 100644 --- a/base_classes/NXebeam_column.nxdl.xml +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -1,10 +1,10 @@ - + - - + + - Base class for a set of components providing a controllable electron beam. + Container for components to form a controlled beam in electron microscopy. - - - Typically tech-partner, microscope-, and control software-specific - name of the specific operation mode how the ebeam_column and its - components are controlled to achieve a specific illumination condition. - - In most cases users do not know, have to care, or are able to disentangle the - details of the spatiotemporal dynamics of the components of the microscope. - Instead, they rely on the assumption that the microscope and control software - work as expected. Selecting then a specific operation_mode assures some level - of reproducibility in the illumination conditions. - - - The source which creates the electron beam. - + Given name/alias. - + Voltage relevant to compute the energy of the electrons immediately after they left the gun. - + Type of radiation. @@ -67,22 +52,27 @@ part "an electron gun" reusable in other context--> - + Emitter type used to create the beam. If the emitter type is other, give further details in the description field. + + + + + + - - + Material of which the emitter is build, e.g. the filament material. - - + + Ideally, a (globally) unique persistent identifier, link, or text to a resource which gives further details. @@ -92,26 +82,28 @@ part "an electron gun" reusable in other context--> relevant from maintenance point of view--> - Collection of axis-based translations and rotations to describe the - location and geometry of the component in the instrument. + Affine transformation which detail the arrangement in the + microscope relative to the optical axis and beam path. + - - - - - + + + + + A sensor used to monitor an external or internal condition. + + - Individual characterization results for the position, shape, + Individual ocharacterization results for the position, shape, and characteristics of the electron beam. - :ref:`NXtransformations` should be used to specify the location + NXtransformations should be used to specify the location of the position at which the beam was probed. - diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml new file mode 100644 index 0000000000..db991447d2 --- /dev/null +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -0,0 +1,157 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of fast axes (axes acquired symultaneously, without scanning a pysical + quantity) + + + + + Number of slow axes (axes acquired scanning a pysical quantity) + + + + + Subclass of NXinstrument to describe a photoelectron analyser. + + + + Free text description of the type of the detector + + + + + Name or model of the equipment + + + + Acronym or other shorthand name + + + + + + Energy resolution of the electron analyser (FWHM of gaussian broadening) + + + + + Momentum resolution of the electron analyser (FWHM) + + + + + Angular resolution of the electron analyser (FWHM) + + + + + Spatial resolution of the electron analyser (Airy disk radius) + + + + + List of the axes that are acquired simultaneously by the detector. + These refer only to the experimental variables recorded by the electron analyser. + Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. + + .. csv-table:: Examples + :header: "Mode", "fast_axes", "slow_axes" + + Hemispherical in ARPES mode, "['energy', 'kx']","" + "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] + "Tof", "['energy', 'kx', 'ky']","" + "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" + + Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. + If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. + + + + + + + + List of the axes that are acquired by scanning a physical parameter, listed in + order of decreasing speed. See fast_axes for examples. + + + + + + + + Refers to the last transformation specifying the positon of the manipulator in + the NXtransformations chain. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the electron analyser as a component in the instrument. Conventions + from the NXtransformations base class are used. In principle, the McStas + coordinate system is used. The first transformation has to point either to + another component of the system or . (for pointing to the reference frame) to + relate it relative to the experimental setup. Typically, the components of a + system should all be related relative to each other and only one component + should relate to the reference coordinate system. + + + + + Describes the electron collection (spatial and momentum imaging) column + + + + + Describes the energy dispersion section + + + + + Describes the spin dispersion section + + + + + Describes the electron detector + + + + + Deflectors outside the main optics ensambles described by the subclasses + + + + + Individual lenses outside the main optics ensambles described by the subclasses + + + diff --git a/contributed_definitions/NXellipsometry.nxdl.xml b/contributed_definitions/NXellipsometry.nxdl.xml new file mode 100644 index 0000000000..b082b310c9 --- /dev/null +++ b/contributed_definitions/NXellipsometry.nxdl.xml @@ -0,0 +1,357 @@ + + + + + + + + + + + Variables used throughout the document, e.g. dimensions or parameters. + + + + Length of the spectrum array (e.g. wavelength or energy) of the measured + data. + + + + + Number of sensors used to measure parameters that influence the sample, + such as temperature or pressure. + + + + + Number of measurements (1st dimension of measured_data array). This is + equal to the number of parameters scanned. For example, if the experiment + was performed at three different temperatures and two different pressures + N_measurements = 2*3 = 6. + + + + + Number of detection angles of the beam reflected or scattered off the + sample. + + + + + Number of angles of incidence of the incident beam. + + + + + Number of observables that are saved in a measurement. e.g. one for + intensity, reflectivity or transmittance, two for Psi and Delta etc. This + is equal to the second dimension of the data array 'measured_data' and the + number of column names. + + + + + Number of time points measured, the length of NXsample/time_points + + + + + Ellipsometry, complex systems, up to variable angle spectroscopy. + + Information on ellipsometry is provided, e.g. in: + + * H. Fujiwara, Spectroscopic ellipsometry: principles and applications, + John Wiley & Sons, 2007. + * R. M. A. Azzam and N. M. Bashara, Ellipsometry and Polarized Light, + North-Holland Publishing Company, 1977. + * H. G. Tompkins and E. A. Irene, Handbook of Ellipsometry, + William Andrew, 2005. + + Open access sources: + + * https://www.angstromadvanced.com/resource.asp + * https://pypolar.readthedocs.io/en/latest/ + + Review articles: + + * T. E. Jenkins, "Multiple-angle-of-incidence ellipsometry", + J. Phys. D: Appl. Phys. 32, R45 (1999), + https://doi.org/10.1088/0022-3727/32/9/201 + * D. E. Aspnes, "Spectroscopic ellipsometry - Past, present, and future", + Thin Solid Films 571, 334-344 (2014), + https://doi.org/10.1016/j.tsf.2014.03.056 + * R. M. A. Azzam, "Mueller-matrix ellipsometry: a review", + Proc. SPIE 3121, Polarization: Measurement, Analysis, and Remote Sensing, + (3 October 1997), + https://doi.org/10.1117/12.283870 + * E. A. Irene, "Applications of spectroscopic ellipsometry to microelectronics", + Thin Solid Films 233, 96-111 (1993), + https://doi.org/10.1016/0040-6090(93)90069-2 + * S. Zollner et al., "Spectroscopic ellipsometry from 10 to 700 K", + Adv. Opt. Techn., (2022), + https://doi.org/10.1515/aot-2022-0016 + + + + This is the application definition describing ellipsometry experiments. + + Such experiments may be as simple as identifying how a reflected + beam of light with a single wavelength changes its polarization state, + to a variable angle spectroscopic ellipsometry experiment. + + The application definition defines: + + * elements of the experimental instrument + * calibration information if available + * parameters used to tune the state of the sample + * sample description + + + + An application definition for ellipsometry. + + + + Version number to identify which definition of this application + definition was used for this entry/data. + + + + + URL where to find further material (documentation, examples) relevant + to the application definition. + + + + + + + + + An optional free-text description of the experiment. + + However, details of the experiment should be defined in the specific + fields of this application definition rather than in this experiment + description. + + + + + Specify the type of ellipsometry. + + + + + + + + + + + + + + Properties of the ellipsometry equipment. + + + + Name of the company which build the instrument. + + + + + ISO8601 date when the instrument was constructed. + UTC offset should be specified. + + + + + + Commercial or otherwise defined given name of the program that was + used to generate the result file(s) with measured data and metadata. + This program converts the measured signals to ellipsometry data. If + home written, one can provide the actual steps in the NOTE subfield + here. + + + + + + What type of ellipsometry was used? See Fujiwara Table 4.2. + + + + + + + + + + + + + + + + + + + Define which element rotates, e.g. polarizer or analyzer. + + + + + + + + + + + + Specify the used light source. Multiple selection possible. + + + + + + + + + + + + + If focussing probes (lenses) were used, please state if the data + were corrected for the window effects. + + + + Were the recorded data corrected by the window effects of the + focussing probes (lenses)? + + + + + Specify the angular spread caused by the focussing probes. + + + + + + Properties of the detector used. Integration time is the count time + field, or the real time field. See their definition. + + + + + Properties of the rotating element defined in + 'instrument/rotating_element_type'. + + + + Define how many revolutions of the rotating element were averaged + for each measurement. If the number of revolutions was fixed to a + certain value use the field 'fixed_revolutions' instead. + + + + + Define how many revolutions of the rotating element were taken + into account for each measurement (if number of revolutions was + fixed to a certain value, i.e. not averaged). + + + + + Specify the maximum value of revolutions of the rotating element + for each measurement. + + + + + + The spectroscope element of the ellipsometer before the detector, + but often integrated to form one closed unit. Information on the + dispersive element can be specified in the subfield GRATING. Note + that different gratings might be used for different wavelength + ranges. The dispersion of the grating for each wavelength range can + be stored in grating_dispersion. + + + + + + + + Was the backside of the sample roughened? Relevant for infrared + ellipsometry. + + + + + + + Select which type of data was recorded, for example Psi and Delta + (see: https://en.wikipedia.org/wiki/Ellipsometry#Data_acquisition). + It is possible to have multiple selections. Data types may also be + converted to each other, e.g. a Mueller matrix contains N,C,S data + as well. This selection defines how many columns (N_observables) are + stored in the data array. + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml new file mode 100644 index 0000000000..ad33f94aab --- /dev/null +++ b/contributed_definitions/NXem.nxdl.xml @@ -0,0 +1,2034 @@ + + + + + + + Characterization of a sample during a session on an electron microscope. + + **The idea and aim of NXem**: + Electron microscopy (EM) research, whether it be performed with scanning electron + microscope (SEM) or transmission electron microscope (TEM) instruments, uses + versatile tools for preparing and characterizing samples and specimens. + The term specimen is considered a synonym for sample in this application definition. + A specimen is a physical portion of material that is studied/characterized during + the microscope session, eventually in different places on the specimen surface, + illuminating the surface layers or shining through thin specimens. + These places are named regions of interest (ROIs). + + Fundamentally, an electron microscope is an electron accelerator. + Experimentalists use it in sessions during which they characterize as well as + prepare specimens. This application definition describes data and metadata about + processes and characterization tasks applied to one specimen. + The application definition focuses on the usage of EM in materials research. + The application definition design makes it in principle applicable also in + cryo-EM on biomaterials. + + Multiple specimens have to be described with multiple :ref:`NXentry` instances. + + **Electron microscopes motivate the development of a comprehensive data schema:** + There are research groups who use an EM in a manner where it is exclusively + operated by a single, instrument-responsible scientists or a team of scientists. + These users may perform analyses for other users as a service task, especially + in large research facility settings. Oftentimes, though, and especially for + cutting-edge instruments, the scientists guide the process and maybe even control + the microscope. Instruments are usually controlled on-premises but also more + and more functionalities for remote control have become available. + Scientists oftentimes can ask technicians for support. In all cases, + these people are considered users. Users might have different + roles though. + + The rational behind a common EM schema rather than making separate schemas + for SEM or TEM are primarily the key similarities of SEM and TEM + instruments: + + Both type of instruments have electro-magnetic lenses. These may differ in + design, alignment, number, and level of corrected for aberrations. + As an obvious difference, a TEM is mainly used for measuring the transmitted + electron beam. This calls for using a different lens setup and relative + placement of the specimen in the lens setup. Also TEM specimens are + substantially thinner than specimens characterized with SEM to enable an + illumination through the specimen. This offers capabilities for probing of + additional physical mechanisms of electron-matter interaction which are + unavailable in SEMs. + + Nevertheless, both types of electron microscopes use detector systems which + measure different types of signals that originate from the same set of + radiation/specimen interactions. Often these detectors have a similar design + and technology or are even used both in SEMs and TEMs. + + **A comprehensive schema instead of specific SEM or TEM schemas**: + Given these physical and technical differences, different instruments have + been developed. This led to a coexistence of two broad interacting + communities: SEM and TEM users. From a data science perspective, we + acknowledge that the more specific a research question is and the narrower it + is the addressed circle of users which develops or uses schemas for research + data management (RDM) with EM, the more understandable it is that scientists + of either community (or sub-community) ask for designing method-specific schemas. + + Researchers who have a single (main) microscope of some vendor in their lab, + may argue they need an NXem_vendor_name schema or an NXem_microscope_name or + an NXem_sem or a NXem_tem schema. + Scientists exclusively working with one technique or type of signal probed + (X-rays, electrons) may argue they wish to be pragmatic and store only + what is immediately relevant for their particular technique and + research questions. In effect, they may advocate for method-specific + schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. + + However, the history of electron microscopy has shown that these activities led + to a zoo of schemas and vocabulary, with implementation in many data and file formats, + difficult to make interoperable. Instead of trying to maintain this, we would like + to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ + should guide all decisions how data and metadata should be stored. + + EM instruments, software, and research are moving targets. Consequently, + there is a key challenge and inconvenience with having many different schemas + with associated representations of data and metadata: Each combination of + schemas or an interoperable-made handshake between two file formats or software + packages has to be maintained by software developers. This counts especially + when data should be processed interoperably between software packages. + + This brings two problems: Many software tools and parsers for the handshaking + between tools have to be maintained. This can result in usage of different + terminology, which in turn results in representations and connections made + between different data representations and workflows that are not + machine-actionable. + `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ + + **The advantage of working towards a common vocabulary and representation**: + A common vocabulary can serve interoperability as developers of schemas and + scientists can reuse for instance these terms, thus supporting interoperability. + Ideally, scientists specialize an application definition only for the few very + specific additional quantities of their instruments and techniques. This is + better than reimplementing the wheel for descriptions of EM instruments. + This route of more standardization can support the EM community in that it + removes the necessity for having to maintain a very large number of schemas. + + Aiming for more standardization, i.e. a lower number of schemas rather than + a single standard for electron microscopy is a compromise that can serve + academia and industry as it enables a focusing of software development + efforts on those schemas, on fixing and discussing them, and on harmonizing + their common vocabulary. These activities can be specifically relevant also + for technology partners building EM hard- and software as it improves the + longevity of certain schemas; and thus can help with incentivizing them to support + the community with implementing support for such schemas into their applications. + + In effect, everybody can gain from this as it will likely reduce the cases + in which scientists have to fix bugs in making their own tools compliant and + interoperable with tools of their colleagues and the wider community. + + The here proposed NXem application definition offers modular components + (EM-research specific base classes) for defining schemas for EM research. + Thereby, NXem can be useful to extends top-level ontologies towards a domain- + and method-specific ontology for electron microscopy as it is used for + materials research. + + Working towards a common vocabulary is a community activity that profits from + everybody reflecting in detail whether certain terms they have used in the past + are not eventually conceptually similar if not the same as what this application + definition and its base classes provide. We are happy for receiving your feedback. + + **Addressing the generality versus specificity challenge**: + It is noteworthy to understand that (not only for NeXus), schemas differ + already if at least one field is required in one version of the schema, + but it is set optional in another schema. If group(s), field(s), or + attributes are removed or added, or even a docstring is changed, schemas can + become inconsistent. It is noteworthy to mention that the idea of a NeXus application + definition serves as a contract between a data provider and a data consumer. + Providers can be the software of a specific microscopes or users with specific + analysis needs. Consumers can be again specific software tools, like vendor + software for controlling the instrument or a scientific software for doing + artificial intelligence analyses on EM data). Such changes of a schema lead + to new versions. + + **Verification of constraints and conditions**: + Tools like NeXus do not avoid or protect against all such possible inconsistencies; + however NeXus offers a mechanism and toolset, through which schemas can be + documented and defined. In effect, having an openly documented + (at a case-specific level of technical detail) schema is a necessary but alone + not a sufficient step to take EM research on a route of machine-actionable + and interoperable FAIR data. + + This stresses again the fundamental and necessary role of working towards + a common vocabulary and, with a longer perspective in mind, a machine-actionable + knowledge representation and verification engine. So far many conditions and + requirements are formulated in the docstrings of the respective entries of + the application definition. + + **NXem takes a key step towards standardization of EM data schemas**. + It offers a controlled vocabulary and set of relations between concepts and + enables the description of the data which are collected for research with + electron microscopes. To be most efficient and offering reusability, the NXem + application definition should be understood as a template that one should + ideally use as is. NXem can be considered a base for designing more specialized + definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). + + **The use of NXem should be as follows:** + Offspring application definitions should not remove groups but leave these + optional or, even better, propose changes to NXem. + + A particular challenge with electron microscopes as physical instruments are + their dynamics. To make EM data understandable, repeatable, and eventually + corresponding experiments reproducible in general requires a documentation + of the spatio-temporal dynamics of the instrument in its environment. + It is questionable to which level such a reproducibility is possible with EM + at all considering beam damage, effects of the environment, and other not + exactly quantifiable influences. + While this points to the physical limitations there are also practical and + economical constraints on how completely EM research can be documented: + For most commercial systems there is a specific accessibility beyond which + detailed settings like lens excitations and low-level hardware settings + may not be retrievable as technology partners have a substantiated interest in + finding a compromise between being open to their users and securing their + business models. + + By design, EM experiments illuminate the specimen with electrons as a + consequence of which the specimen changes if not may get destroyed. + As such, repeatability of numerical processing and clear descriptions of + procedures and system setups should be addressed first. + + If especially a certain simulation package needs a detailed view of the + geometry of the lens system and its excitations during the course of the + experiment, it is difficult to fully abstract the technical details of the + hardware into a set of names for fields and groups that make for a compromise + between clarity but being system-agnostic at the same time. + Settings of apertures are an example where aperture modes are in most cases + aliases behind which there is a set of very detailed settings specific to the + software and control units used. These settings are difficult to retrieve, + are not fully documented by technology partners. This simplification for + users of microscopes makes experiments easier understandable. + On the flipside these subtilities limit the opportunities of especially open- + source developments to make data schemas covering enough for general usage and + specific enough and sufficiently detailed to remain useful for + research by electron microscopy domain experts. + + Instead, currently it is for the docstring to specify what is conceptually + eventually behind such aliases. The design rule we followed while drafting + this NXem application definition and base classes is that there are numerous + (technical) details about an EM which may warrant a very detailed technical + disentangling of settings and reflection of numerous settings as deeply + nested groups, fields and attributes. An application definition can offer a + place to hold these nested representations; however as discussed + at the cost of generality. + + Which specific details matter for answering scientific research questions is + a difficult question to answer by a single team of scientists, especially + if the application definition is to speak for a number of vendors. What makes + it especially challenging is when the application definition is expected to + hold all data that might be of relevance for future questions. + + We are skeptical if there is one such representation that can fulfill all these + aims and interest, while remaining at the same time approachable and executable + by a large number of scientists in a community. However, we are also convinced + that this is not a reason to accept the status quo of having a very large set + of oftentimes strongly overlapping and redundant schemas. + + NXem is our proposal to motivate the EM community to work towards more + standardization and discussion of what constitutes data, i.e. metadata, + numerical and categorical data in research with electron microscopes. We found + that existent terminology can be encoded into a more controlled vocabulary. + + We have concluded that despite all these details of current EM research with + SEM, TEM, and focused-ion beam instruments, there a clearly identifiable + common components and generalizable settings of EM research use cases. + Therefore, + + **This application definition has the following components at the top-level:** + + * Each signal, such as a spectrum or image taken at the microscope, should + have an associated time-zone-aware time stamp and report of the specific + settings of the microscope at that point in time when the image was taken. + This is why instances of :ref:`NXevent_data_em` have their own em_lab section. + The reason is that EMs can be highly dynamic, used to illuminate the specimen + differently or show drift during signal acquisition, to name but a few effects. + What constitutes a single EM experiment/measurement? + This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), + taking of a secondary electron image for fracture analysis, taking a set of + EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a + specimen in preparation for e.g. an atom probe experiment. + * :ref:`NXmonitor`; + instances to keep track of time-dependent quantities + pertaining to specific components of the instrument. + Alternatively, NXevent_data_em instances can be used to store + time-zone-aware dates of the components, which is + relevant for documenting as exactly as practically possible settings + when images and spectra were taken. + * :ref:`NXinstrument`; + conceptually this is a container to store an arbitrary level of detail of the + technical components of the microscope as a device and the lab in which + the microscope is operated. + * :ref:`NXuser`; + conceptually, this is a set with at least one NXuser instance which details + who operated or performed the measurement. Additional NXusers can be + referred to in an NXevent_data_em instance to store + individualized details of who executed an event of data acquisition or processing. + * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; + each NXevent_data_em instance is a container to group specific details + about the state of the microscope when a measurement was taken and + relevant data and eventual processing steps were taken (on-the-fly). + * :ref:`NXdata`; at the top-level, this is a place for documenting available + default plottable data. A default plottable can be useful for research data + management systems to show a visual representation of some + aspect of the content of the EM session. + Default plottables are not intended to serve every possible analysis and + visualization demand but are instead a preview. We made this choice + because what constitutes a useful default plot is often a matter of interpretation, + somewhat of personal taste, and community standards. In effect, default + plottables are case- and method-specific. + + Usually a session at a microscope is used to collect multiple signals. + Examples for possible default plottables could be arbitrarily taken secondary, + back-scattered, electron image, diffraction pattern, EELS spectra, composition, + or orientation mappings to name but a few. + + **There are a few design choices to consider with sub-ordinate groups:** + + * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` + instances to hold data at the earliest possible step in the computational + processing (which is usually performed with the microscope control and or + integrated analysis software). The formatting of the NXdata groups enables the + display of image and spectra with web technology visualization software. + * When two- and three-dimensional geometric primitive data are stored, it is useful + to write additional optional `XDMF <https://www.xdmf.org/index.php/XDMF_Model_and_Format>`_ + fields which support additional plotting of the data with visualization software. + * Consumable results of EM characterization tasks are usually a sub-set of + data artifacts, as there is not an infinite amount of possible + electron/ion beam-specimen interactions. + * Images based on electron counts are typically detected with specific operation modes + such as bright field or dark field imaging in TEM or secondary/back-scattered electron + imaging in SEM. + * Also spectra (X-ray quanta or Auger electron counts) typically are referred to + under the assumption of a specific operation mode of the microscope. + * These data are in virtually all cases a result of some numerical processing. + These data and processing steps are modelled as instances of :ref:`NXprocess` + which use terms from a controlled vocabulary e.g. SE (secondary electron), + BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). + + **A key question often asked with EM experiments is how the actual (meta)data + should be stored (in memory or on disk)**. + + The application definition NXem is a graph which describes how numerical data + and (meta)data for EM research are related to one another. + + Electron microscopy experiments are usually controlled/performed via + commercial integrated acquisition and instrument control software. + In many cases, an EM dataset is useful only if it gets post-processed + already during the acquisition, i.e. while the scientist is sitting + at the microscope. + Many of these processes are automated, while some demand GUI + interactions with the control software. Examples include collecting + of diffraction pattern and on-the-fly indexing of these. + + It is possible that different types of programs might be used to + perform these processing steps whether on-the-fly or not. If this is + the case the processing should be structured with individual :ref:`NXprocess` + instances. If the program and/or version used for processing referred + to in an NXprocess group is different to the program and version + mentioned in this field, the NXprocess needs + to hold an own program and version. + + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + The identifier is usually defined/issued by the facility, + laboratory, or the principle investigator. + The identifier enables to link experiments to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of this + application definition rather than write details about the experiment + into this free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval by specifying both + a start_time and an end_time to allow for more detailed bookkeeping and + interpretation of the experiment. The user should be aware that even + with having both time instances specified, it may not be possible + to infer how long the experiment took or for how long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps in NXevent_data_em instances to + provide additional pieces of information. + + + + + ISO 8601 time code with local time zone offset to UTC included when + the microscope session ended. + + + + + + + + + + Binary container for a file or a compressed collection of files which + can be used to add further descriptions and details to the experiment. + The container can hold a compressed archive. + + + + + A small image that is representative of the entry; this can be an + image taken from the dataset like a thumbnail of a spectrum. + A 640 x 480 pixel jpeg image is recommended. + Adding a scale bar to that image is recommended but not required + as the main purpose of the thumbnail is to provide e.g. thumbnail + images for displaying them in data repositories. + + + + + + Contact information and eventually details of at least one person + involved in the taking of the microscope session. This can be the + principle investigator who performed this experiment. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service + should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally (globally) unique persistent identifier. The name distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias of the sample. + Instead, use short_title for this, more convenient alias name. + + In cases where multiple specimens have been loaded into the microscope + the name has to identify the specific one, whose results are stored + by this NXentry, because a single NXentry should be used only for + the characterization of a single specimen. + + Details about the specimen preparation should be stored in the + sample history. + + + + + Ideally, a reference to a (globally) unique persistent identifier, + representing a data artifact which documents ideally as many details + of the material, its microstructure, and its thermo-chemo-mechanical + processing/preparation history as possible. + + The sample_history is the record what happened before the specimen + was placed into the microscope at the beginning of the session. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider are + the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing state, + and the details of the preparation. + + Specific details about eventual physically-connected material like + embedding resin should be documented ideally also in the sample_history. + If all fails, the description field can be used but it is strongly + discouraged because it leads to eventually non-machine-actionable + data. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this should + be a part of the sample history, i.e. the sample is imagined handed over + for analysis. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments + including tracers with a short half time. Further time stamps prior + to preparation_date should better be placed in resources which + describe the sample_history. + + + + + Possibility to give an abbreviation or alias of the specimen name field. + + + + + List of comma-separated elements from the periodic table that are + contained in the sample. If the sample substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history. + + + + + + (Measured) sample thickness. The information is recorded to qualify + if the beam used was likely able to shine through the specimen. + For scanning electron microscopy, in many cases the specimen is much + thicker than what is illuminatable by the electron beam. + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. + + + + + + (Measured) density of the specimen. For multi-layered specimens this + field should only be used to describe the density of the excited + volume. For scanning electron microscopy the usage of this field is + discouraged and instead an instance of an :ref:`NXinteraction_vol_em` + within individual :ref:`NXevent_data_em` instances can provide a much + better description of the relevant details why one may wish to store + the density of the specimen. + + + + + + Discouraged free-text field in case properly designed records + for the sample_history are not available. + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + + + + + + + + Metadata and numerical data of the microscope and the lab in which it stands. + + The em_lab section contains a description of the instrument and its components. + The component descriptions in this section differ from those inside individual + NXevent_data_em sections. These event instances take the role of time snapshot. + For an NXevent_data_em instance users should store only those settings for a + component which are relevant to understand the current state of the component. + Here, current means at the point in time, i.e. the time interval, + which the event represents. + + For example it is not relevant to store in each event's electron_source + group again the details of the gun type and manufacturer but only the + high-voltage if for that event the high-voltage was different. If for all + events the high-voltage was the same it is not even necessary to include + an electron_source section in the event. + + Individual sections of specific type should have the following names: + + * NXaperture: the name should match with the name of the lens + * NXlens_em: condenser_lens, objective_lens are commonly used names + * NXcorrector_cs: device for correcting spherical aberrations + * NXstage_lab: a collection of component for holding the specimen and + eventual additional component for applying external stimuli on the sample + * NXdetector: several possible names like secondary_electron, + backscattered_electron, direct_electron, ebsd, edx, wds, auger, + cathodoluminescence, camera, ronchigram + + + + Given name of the microscope at the hosting institution. This is an alias. + Examples could be NionHermes, Titan, JEOL, Gemini, etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Description of the type of the detector. + + Electron microscopes have typically multiple detectors. + Different technologies are in use like CCD, scintillator, + direct electron, CMOS, or image plate to name but a few. + + + + Instrument-specific alias/name + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A container for storing a set of NXevent_data_em instances. + + An event is a time interval during which the microscope was configured + in a specific way. The microscope is considered as stable enough during + this interval that a measurement with one or multiple detectors is + possible. What constitutes such time interval depends on how the + microscope is used and which measurements the user would like to perform. + + Each NXevent_data_em instance holds one acquisition task with detectors. + Each NXevent_data_em section contains an em_lab group in which specific + settings and states of the microscope during the time interval + can be stored to document the history of states of the microscope over + the course of the session. + + The NXem application definition offers maximal flexibility. + One extreme could be that the only one NXevent_data_em instance is used + and this covers the time interval of the entire session at the microscope. + The other extreme case is that each collection of an image or even + single spot measurement is defined as an NXevent_data_em instance. + In this case the em_lab group inside the NXevent_data_em also holds + the specific time-dependent state of the microscope with which in theory + all dynamics of the system (if measured) can be captured and documented. + + Nowadays microscopes exists for which hard- and software solutions + enable a tracking of the dynamics of the microscope and the actions + of the user (such as with solution like AXONSynchronicity from Protochips). + The NXem application definition can however also be used for less + complex interaction and lower demands wrt to time tracking activities. + + An NXevent_data_em instance holds specific details about how raw data from + a detector were processed. Raw data may already be post-processed as + they are accessible only by the control software with after some internal + processing happened. Nevertheless, these data have to be distinguished from + post-processed data where e.g. raw data are converted to interpreted + spectra, or orientation mappings. + + This post-processing tasks can be performed (on-the-fly, i.e. during + acquisition for sure during the microscope session) or afterwards. + Post-processing is performed with commercial software or various + types and scripts. + + Currently, several specializations of NXimage_set and Nspectrum_set + are used which store some details of this processing. However, as post- + processing tasks can be substantially more advanced and involved it + is clear that data artifacts from the measurement and data artifacts + generated during post-processing are weakly connected only, maybe + exclusively by the fact that a complex numerical post-processing workflow + just takes one raw dataset from an NXevent_data_em instance but generates + multiple derived data artifacts from this. All these should be described + as own application definitions and only weak connections should be made + to an instance of NXem. Instances of NXsubentry is one mechanism in + NeXus how this can be achieved in the future. + + + + A container holding a specific result of the measurement and + eventually metadata how that result was obtained numerically. + + NXevent_data_em instances can hold several specific NXimage_em or + NXspectrum_em instances taken and considered as one event, i.e. + a point in time when the microscope had the settings specified + either in NXinstrument or in this NXevent_data_em instance. + + The application definition is designed without an explicit need for + having an NXevent_data_em instance that contains an NXimage_em or + NXspectra_em instance. Thereby, an NXevent_data_em can also be used + for just documentation about the specific state of the microscope + irrespective whether data have been collected during this time interval. + + In other words the NXinstrument group details primarily the more + static settings and components of the microscope as they are found + by the operator during the session. The NXevent_data_em samples + the dynamics. + + It is not necessary to store data in NXebeam, NXibeam instances + of NXevent_data_em but in this case it is assumed that the settings + were constant over the entire course of the microscope session + and thus all relevant metadata inside the NXinstrument groups + are sufficient to understand the session. + + So far there exists no standard which a majority of the technology + partners and the materials science electron microscopy community + have accepted which could be used for a very generic documentation, + storage and exchange of electron microscope data. Therefore, it is + still a frequent case that specific files have many fields which cannot + safely be mapped or interpreted. + **Therefore, users are always given the advice to keep the vendor files.** + Working however with these vendor files inside specific software, + like materials databases, demands for parsers which extract pieces of + information from the vendor representation (numerical data and metadata) + and map them on a schema with which the database and its associated + software tools can work with. + + Currently, one would loose immediately track of e.g. provenance and + the origin of certain data in NXevent_data_em instances unless really + all data are safely and reliably copied over into an instance of the + schema. Currently, though, this is sadly effectively prevented in many + cases as vendors indeed implemented often sophisticated provenance + and commercial software state tracking tools but these are not yet + documented covering enough in our opinion so that it is safe to assume + all vendor field names are known, logically understood, interpretable, + and thus mappable on a common schema using a controlled common + vocabulary. + + Therefore we encourage user for now to store for each NXimage_set + or NXspectra_set instance to supply the so-called source of the data. + This can for instance be the name and hashvalue of the original + file which was acquired during the microscope session and from which then + certain details like numerical data and metadata were copied into an + instance of this schema for the purpose of working with the data in + e.g. tools offered by research data management (RDM) systems or + materials database. + + During our work on implementing file format/metadata parsers and + developing this application definition, we realized that **several + software tools currently do not consistently format critical metadata + like time-zone-aware timestamps** when events of data collection or + processing happened. + + We would like to encourage the community and especially the vendors + to work towards a standardization, or at least an open documentation + of the way how time-zone-aware time data are collected and stored how + and where during a microscope session and how they end up in files + and databases with which users interact. + This would enable to supplement instances of this schema with specific + time data and assure that these time data can be used to reliably + contextualize individual datasets and processing steps in materials + information systems. + + For the reason that these measures have not yet been fully taken, + the start_time and end_time is a recommended option. + The idea behind these time-zone-aware dates is to identify when + the data were collected at the microscope but NOT when they were + transcoded by some software tool(s) while storing the data in an + instance of this schema. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Annulus inner half angle + + + + + Annulus outer half angle + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml new file mode 100644 index 0000000000..aa3dd46be3 --- /dev/null +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -0,0 +1,1926 @@ + + + + + + + + + + Number of arguments per orientation for given parameterization. + + + + + Number of scan points. + + + + + Number of pixel along the slowest changing dimension for a rediscretized, i.e. + standardized default orientation mapping. + + + + + Number of pixel along slow changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + Number of pixel along fast changing dimension for a rediscretized i.e. + standardized default orientation mapping. + + + + + + Application definition for collecting and indexing Kikuchi pattern into orientation maps. + + This NXem_ebsd application is a proposal how to represent data, metadata, and + connections between these for the research field of electron microscopy. + More specifically, exemplified here for electron backscatter diffraction (EBSD). + The application definition solves two key documentation issues which are missing + so far to document provenance of data and metadata in the field of EBSD. + The application definition can be an example that is relevant for related + workflows in orientation microscopy. + + Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted + according to the NXem_ebsd application definition) stores the connection between + the microscope session and the key datasets which are considered typically results + of the various processing steps involved when working with EBSD data. + + Different groups in this application definition make connections to data artifacts + which were collected when working with electron microscopes via the NXem partner + application definition. Using a file which stores information according to the + NXem application definition has the benefit that it connects the sample, references + to the sample processing, the user operating the microscope, details about the + microscope session, and details about the acquistion and eventual indexing of + Kikuchi pattern, associated overview images, like secondary electron or + backscattered electron images of the region-of-interest probed and many + more pieces of information. + + Secondly, this NXem_ebsd application definition connects and stores the conventions + and reference frames which were used and are the key to mathematically correctly + interpret every EBSD result. Otherwise, results would be ripped out of their + context, as it is the situation with many traditional studies where EBSD data were + indexed on-the-fly and shared with the community only via sharing the results file + with some technology-partner-specific file but leaving important conventions out + or relying on the assumptions that colleagues know these even though multiple + definitions are possible. + + This application definition covers experiments with one-, two-dimensional, and + so-called three-dimensional EBSD datasets. The third dimension is either time + (in the case of quasi in-situ experiments) or space (in the case of serial- + sectioning) methods where a combination of mechanical or ion milling is used + repetitively to measure the same region-of-interest at different depth increments. + Material removal can be achieved with electron or ion polishing, using manual + steps or using automated equipment like a robot system. + + Three-dimensional experiments require to follow a sequence of specimen, surface + preparation, and data collection steps. By nature these methods are destructive + in that they either require the removal of the previously measured material region + or that the sample surface can degrade due to e.g. contamination or other + electron-matter interaction. + + For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are + combined into one reconstructed stack. That is serial-sectioning is mainly a + computational workflow. Users collect data for each serial sectioning step + via an experiment. This assures that data for associated microscope sessions + and steps of data processing stay connected and contextualized. + + Eventual tomography methods also use such a workflow because first diffraction + images are collected (e.g. with X-ray) and then these imagres are indexed and + computed into a 3D orientation mapping. The here proposed NXem_ebsd application + definition contains conceptual ideas how this splitting between measurement and + post-processing can be granularized also for such X-ray-based techniques, whether + it be 3DXRD or HEDM. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this workflow. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + workflows/experiments to e.g. proposals. + + + + + Free-text description about the workflow. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of the application + definition behind instead of filling in these details into the experiment_description + free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the processing of the workflow started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + workflow was executed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the workflow. + + + + + ISO 8601 time code with local time zone offset to UTC included + when the processing of the workflow ended. + + + + + Program which was used for creating the file instance which is + formatted according to the NXem_ebsd application definition. + + + + + + + + Contact information and eventually details of at least one person + involved in performing the workflow. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is + recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific + service should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user + in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Details about simulations for Kikuchi pattern using kinematic or dynamic + diffraction theory. Usually, the output of such computer simulations are + spherical Kikuchi images which only when projected or observed in some + region-of-interest will represent a set of rectangular Kikuchi pattern + with the same rectangular shape and image size. + + Therefore, these pattern should be stored. The spherical diffraction + pattern can be stored as a set of triangulated geodesic meshes. + The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. + + Do not store pattern in the simulation group if they + have been measured are not simulated. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The experiment group captures relevant details about the conditions of + and the tools used for collecting the Kikuchi diffraction pattern. + + The most frequently collected EBSD data are captured as rectangular ROIs + composed from square or hexagonally-shaped pixels. Substantially less + frequently, because such experiments are more costly and technically + demanding, correlated experiments are performed. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. Here the same or nearly the same ROI is + analyzed via a cycles of thermomechanical treatment, sample preparation, + measurement, on-the-fly-indexing. Phenomena investigated like this are + recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is repetitively measured + and polished to create a stack of orientation data which can be reconstructed + to a three-dimensional volume ROI. + + + + Physical time since the beginning of a timestamp that is required to be + same for all experiments in the set. The purpose of this marker is + to identify how all experiments in the set have have to be arranged + sequentially based on the time elapsed. + The time is relevant to sort e.g. experiments of consecutive quasi + in-situ experiments where a measurement was e.g. taken after 0 minutes + of annealing, 30 minutes, 6 hours, or 24 hours of annealing. + + + + + Transformation which details where the region-of-interest described under + indexing is located in absolute coordinates and rotation with respect + to which coordinate system. + + + + + + The EBSD system, including components like the electron gun, pole-piece, + stage tilting, EBSD detector, and the gnomonic projection have to be + calibrated to achieve reliable results. Specifically, the gnomonic projection + has to be calibrated. + + In most practical cases, especially in engineering, there is a substantially + larger number of sessions where such a calibrated system is used assuming + that somebody has properly calibrated the system rather than that the user + actively recalibrates it or is even allowed to do so. + Especially the projection geometry has to calibrated which is usually + achieved with measuring silicon, quartz or standards, and comparing + against simulated diffraction pattern. + + In the first case, the user assumes that the principle geometry of the + hardware components and the settings in the control and EBSD pattern + acquisition software are calibrated. Consequently, users pick from an + existent library of phase candidates. One example are the CRY or CIF + files of the classical HKL/Channel 5/Flamenco software products. + Each entry of the library of such phase candidates in this NeXus proposal + is represented by one NXem_ebsd_crystal_structure_model base class. + For each phase an instance of this base class is to be used to store + crystallographic and simulation-relevant data. + + Indexing is a data processing step performed after/during the beam scans + the specimen (depends on configuration). Users load the specimen, and first + collect a coarse image of the surface. Next, an approximate value for the + calibrated working distance is chosen and the stage tilted. + Users then may configure the microscope for collecting higher quality data + and push in the EBSD detector. Subsequently, they fine tune the illumination + and aberration settings and select one or multiple ROIs to machine off. + The on-the-fly indexing parameter are defined and usually the automated + measurement queue started. + + Nowadays, this is usually an automated/unsupervised process. The pattern + collection runs during the allocated session time slot which the user has + booked ends or when the queue finishes prematurely. Kikuchi pattern surplus + eventually multi-modal detector signals are collected and usually indexed + on-the-fly. The Kikuchi patterns may or not be deleted directly after a + solution was found (on-the-fly) so Kikuchi pattern are not always stored. + + Results files are in many labs afterwards copied automatically + for archival purposes to certain storage locations. The result of such an + EBSD measurement/experiment is a set of usually proprietary or open files + from technology partners (microscope and EBSD detector manufacturers). + + In the second case, the system is being calibrated during the session + using standards (silicon, quartz, or other common specimens). + There is usually one person in each lab responsible for doing such + calibrations. Important is that often this person or technician(s) are also + in charge of configuring the graphical user interface and software + with which most users control and perform their analyses. + For EBSD this has key implications because, taking TSL OIM/EDAX as an example, + the conventions how orientations are stored is affected by how reference frames + are set up and this setup is made at the level of the GUI software. + Unfortunately, these pieces of information are not necessarily stored + in the results files. In effect, key conventions become disconnected + from the data so it remains the users personal obligation to remember these + settings, write them down in the lab notebook, or these metadata get lost. + All these issues are a motivation and problem which NXem_ebsd solves. + + + + + A link/cross reference to an existent instance of NXem_ebsd with ideally + an associated instance of NXem detailed under measurement which informs + about the calibration procedures. + + + + Commit identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to the EBSD data (post)-processing workflow + when performing the calibration. + + + + + + + Relevant result of the session at the microscope for this experiment + which enables to connect the measurement of the Kikuchi pattern and + their processing into orientation microscopy maps. + + + + + Name or link to an existent instance of an EBSD raw dataset ideally + as an instance of an NXem application definition which has at least + one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. + The path to this instance in the origin has to be specified under path. + + When NXem is not used or the aim is to rather explore first how + community-specific files with EBSD data, such as ANG, CPR, or HDF5- + based formats can be parsed from, inject here the name of that file. + + The em_om parser will currently not interpret the majority of the + many system- and technique-specific metadata which come with the + files from e.g. technology partners. This is because the current + culture in the EBSD community is that many of the metadata fields + are neither in all cases fully documented nor use a standardized + vocabulary although many people understand terms from different + implementations and how these metadata can likely be compared to + one another. + + In addition, it is common practice in the research field of EBSD that + users transcode their raw data into other (often text-based or HDF5) + files with custom formatting to realize an information transfer + between specific software tools including commercial software from + technology partner, custom scripts in Matlab using tools like MTex, + or Python scripting with tools like hyperspy, pyxem, orix, diffsims, + kikuchipy, or EBSD data stack alignment tools like DREAM.3D. + We have opted that in the first iteration this implementation of a + RDMS-agnostic FAIR data schema for EBSD that we discard these metadata + because these ad hoc file formats are not designed to communicate + also specifically and most importantly the eventually different context + of the metadata. + Another reason for this choice was also to emphasize that in fact such + challenges do exist in the community and thus pointing them out may + support the discussion to arrive at eventually more complete solutions. + As developing these solutions should not be our authority and necessarily + demands feedback from the technology partners, we have opted for this + intermediate approach to stimulate discussion. + + + + Commit or e.g. at least SHA256 checksum identifying this resource. + + + + + + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow. + + + + + + + + OIM, orientation imaging microscopy. Post-processing of the Kikuchi + patterns to obtain orientation per phase model and scan point. + Fundamentally different algorithms can be used to index EBSD/EBSP pattern. + + Common is that pattern indexing is a computational step of comparing + simulated with measured diffraction pattern. Quality descriptors are defined + based on which an indexing algorithm yields a quantitative measure of + how similar measured and assumed/simulated pattern are, and thus if + no, one, or multiple so-called solutions were found. + + Assumed or simulated pattern use kinematical or dynamical electron + diffraction theory. Hough transform (which is essentially a discretized + Radon transform, for details see e.g A short introduction to the Radon + and Hough transforms and how they relate by M. van Ginkel et al.). + Recently, dictionary-based indexing methods are increasingly becoming used + partly driven by the move to use artificial intelligence algorithms. + + An inspection of publicly available EBSD datasets with an open-source + license which are available on Zenodo was performed prior to implementing + of the associated em_om parser for NXem_ebsd. This analysis revealed that + EBSD data are in most cases stored in two ways: Case one was via a file in + formats from technology partners. Examples are binary formats like OSC, + H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, + CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. + + These files contain some result and metadata to the numerical steps and the + computational workflow which was performed to index Kikuchi pattern + on-the-fly. Examples of metadata include scan point positions, indexing + solutions per scan point, some quality descriptors for the solutions, + as well as crystal structure and phase metadata. + + Case two were raw pattern in some custom format, often text-based with + some but in general no conclusive and interoperable representation of all + relevant metadata. + Often it remains unclear what individual fields and data arrays of these + fields resolve and/or mean conceptually. For some fields, publications were + referred to. However, software tools change over time and thus which specific + data end in a file and which specific conceptual information is behind + these data can change with software versions. + + Other cases were storing results of custom post-processing steps and + associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry + resolving methods, i.e. any sort of prototyping or alternative indexing + strategies so far seem to require some flexibility for implementing + rapid prototypic capabilities. The drawback of this is that such results + come formatted on a case-by-case basis and are thus not interoperable. + + Therefore, we first need to collect how these files have been generated + and which metadata in these files (or database entries) represent + which pieces of information conceptually. Ideally, one would do so by + creating a complete set of information in e.g. an NXem application definition, + such as a log of timestamped events and processing steps, metadata and data. + Eventually even interactions with the graphical user interface of commercial + software during the microscope session should be stored and become a + part of the application definition. + + Such a set of pieces of information could then be used via reading directly + for the NXem application definition. However, in most cases such a data + representation is not available yet. + + + + + Therefore, the on_the_fly_indexing group stores which source_file contains + the results of the on-the-fly indexing. For commercial systems these files + can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or + database entry which is referred to under origin is the same as the one + under a given acquisition/origin in one of the experiment groups. + This is because some commercial file formats make no clear distinction + between which metadata are acquisition and/or indexing metadata. + + + + Commercial program which was used to index the EBSD data + incrementally after they have been captured and while the + microscope was capturing (on-the-fly). This is the usual + production workflow how EBSD data are collected in + materials engineering, in industry, and academia. + + + + + + + + Name of the file from which data relevant for creating default plots + were taken in the case that the data in the experiment group were + indexed on-the-fly. + + + + Hash of that file. + + + + + + TBD, path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow + when performing the calibration. + + + + + + Principal algorithm used for indexing. + + + + + + + + + + + + Details about the background correction applied to each Kikuchi pattern. + + + + + + + Binning i.e. downsampling of the pattern. + + + + + + + Specific parameter relevant only for certain algorithms used + + + + + + + + + + + + + + + + + + + + + + + + + + + Which return value did the indexing algorithm yield for each scan point. + Practically useful is to use an uint8 mask. + + * 0 - Not analyzed + * 1 - Too high angular deviation + * 2 - No solution + * 100 - Success + * 255 - Unexpected errors + + + + + + + + + How many phases i.e. crystal structure models were used to index each + scan point if any? Let's assume an example to explain how this field + should be used: In the simplest case users collected one pattern for + each scan point and have indexed using one phase, i.e. one instance + of an NXem_ebsd_crystal_structure_model. + + In another example users may have skipped some scan points (not indexed) + them at all) and/or used differing numbers of phases for different scan + points. + + The cumulated of this array decodes how phase_identifier and phase_matching + arrays have to be interpreted. In the simplest case (one pattern per scan + point, and all scan points indexed using that same single phase model), + phase_identifier has as many entries as scan points + and phase_matching has also as many entries as scan points. + + + + + + + + The array n_phases_per_scan_point details how the phase_identifier + and the phase_matching arrays have to be interpreted. + + For the example with a single phase phase_identifier has trivial + values either 0 (no solution) or 1 (solution matching + sufficiently significant with the model for phase 1). + + When there are multiple phases, it is possible (although not frequently + needed) that a pattern matches eventually (not equally well) sufficiently + significant with multiple pattern. This can especially happen in cases of + pseudosymmetry and more frequently with an improperly calibrated system + or false or inaccurate phase models e.g. (ferrite, austenite). + Having such field is especially relevant for recent machine learning + or dictionary based indexing schemes because in combination with + phase_matching these fields communicate the results in a model-agnostic + way. + + Depending on the n_phases_per_scan_point value phase_identifier and + phase_matching arrays represent a collection of concatenated tuples, + which are organized in sequence: The solutions for the 0-th scan point, + the 1-th scan point, the n_sc - 1 th scan point and omitting tuples + for those scan points with no phases according to n_phases_per_scan_point + + + + + + + + One-dimensional array, pattern by pattern labelling the solutions found. + The array n_phases_per_scan_point has to be specified because it details + how the phase_identifier and the phase_matching arrays have to be interpreted. + See documentation of phase_identifier for further details. + + + + + + + + Phase_matching is a descriptor for how well the solution matches or not. + Examples can be confidence index (ci), mean angular deviation (mad), + some AI-based matching probability (other), i.e. the details are implementation-specific. + + + + + + + + + + + How are orientations parameterized? Inspect euler_angle_convention + in case of using euler to clarify the sequence of rotations assumed. + + + + + + + + + + + + Matrix of parameterized orientations identified. The slow dimension + iterates of the individual solutions as defined by n_phases_per_scan_point. + Values for phases without a solution should be correctly identified as + IEEE NaN. + + + + + + + + + + Matrix of calibrated centre positions of each scan point + in the sample surface reference system. + + + + + + + + + + + Fraction of successfully indexed pattern + of the set averaged over entire set. + + + + + + An overview of the entire area which was scanned. + For details about what defines the image contrast + inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + + + + + Container holding a default plot of the region on the sample + investigated with EBSD. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + + The IPF mapping is interpolated from the scan point data mapping + onto a rectangular domain with square pixels and the + orientations colored according to the coloring scheme used in the + respective ipf_color_modelID/program. + + The main purpose of the ipf_mapID group is not to keep raw data or + scan point related data but offer a default way how a research data + management system can display a preview of the dataset so that users + working with the RDMS can get an overview of the dataset. + + This matches the first aim of NXem_ebsd which is foremost to bring + colleagues and users of EBSD together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging + data from EBSD between different tools and research data management + systems (RDMS). + + With this design the individual RDMS solutions and tools can still continue + to support specific custom data analyses workflow and routes but at least + there is then one common notation of understanding whereby also users + not necessarily expert in all the details of the EBSD story can understand + better these data and thus eventually this can motivate data reuse and + repurposing. + + It is important to mention that we cannot assume, at least for now, + that the parser which writes to an NXem_ebsd-compliant file is also + responsible or capable at all of computing the inverse pole figure + color keys and maps itself. This cannot be assumed working because + this mapping of orientation data uses involved mathematical algorithms + and functions which not every tools used in the EBSD community is capable + of using or is for sure not using in exactly the same way. + + Currently, we assume it is the responsibilty of the tool used which + generated the data under on_the_fly_indexing to compute these + plots and deliver these to the parser. + + Specific case studies have been explored by the experiment team of + Area B of the FAIRmat project to realize and implement such mapping. + + The first case study uses the H5OINA format and the pyxem/orix library. + As orix is a Python library, the coloring is performed by the em_om parser. + + The second case study uses MTex and its EBSD color coding model. + As MTex is a Matlab tool, an intermediate format is written from MTex + first which stores these pieces of information. The parser then pulls + these data from the intermediate Matlab-agnostic representation and + supplements the file with missing pieces of information as it is + required by NXem_ebsd. + + The third case study shows how a generic set of Kikuchi pattern + can be loaded with the em_om parser. The pattern are loaded directly + from a ZIP file and mapped to an simulation image section for now. + + The fourth case study uses the DREAM.3D package which provides an own + set of EBSD data post-processing procedures. DREAM.3D documents the + processing steps with a pipeline file which is stored inside DREAM.3D + output files. In this case study, the parser reads the DREAM.3D file + and maps data relevant from the perspective of NXem_ebsd plus adds + relevant IPF color maps as they were computed by DREAM.3D. + Given that in this case the origin of the data is the DREAM.3D file + again provenance is kept and more details can be followed upon when + resolving origin. + + These examples offer a first set of suggestions on how to make EBSD + data injectable into research data management system using schemes + which themselves are agnostic to the specific RDMS and interoperable. + Steps of collecting the raw data and post-processing these with custom + scripts like MTex or commercial tools so far are mainly undocumented. + The limitation is that a program which consumes results or dump files + from these tools may not have necessarily all the sufficient information + available to check if the injected orientation data and color models + are matching the conventions which a user or automated system has + injected into an electronic lab notebook from which currently the em_om + parser collects the conventions and stores them into this NXem_ebsd instance. + The immediate benefit of the here presented NXem_ebsd concept though + is that the conventions and reference frame definitions are expected + in an ELN-agnostic representation to make NXem_ebsd a generally useful + data scheme for EBSD. + + Ideally, the em_om parser would load convention-compliant EBSD data + and use subsequently a community library to transcode/convert orientation + conventions and parameterized orientation values. Thereafter, convention- + compliant default plot(s) could be created that would be truely interoperable. + + However, given the variety of post-processing tools available surplus + the fact that these are not usually executed along standardized + post-processing workflows which perform exactly the same algorithmic steps, + this is currently not a practically implementable option. Indeed, first + developers who wish to implement this would first have to create a library + for performing such tasks, mapping generally between conventions, + i.e. map and rotate coordinate systems at the parser level. + + The unfortunate situation in EBSD is that due to historical reasons + and competitive strategies, different players in the field have + implemented (slightly) different approaches each of which misses + some part of a complete workflow description which is behind EBSD analyses: + Sample preparation, measurement, indexing, post-processing, paper... + + The here exemplified default plot do not so far apply relevant rotations + but takes the orientation values as they come from the origin and using + coloring them as they come. It is thus the scientists responsibility to + enter and check if the respective dataset is rotation-conventions-wise + consistent and fit for a particular task. + + Ideally, with all conventions defined it can be possible to develop + a converter which rotates the input data. This application definition + does not assume this and users should be aware of this limitation. + + The key point is that the conventions however are captured and this is + the most important step to the development of such a generic transcoder + for creating interoperable EBSD datasets. + + Currently the conventions remain in the mind or manual lab book of the + respective scientists or technicians instead of getting stored and + communicated with research papers that are written based on + specific dataset, i.e. database entries. + + The default gridded representation of the data should not be + misinterpreted as the only possible way how EBSD data and OIM + maps can be created! + + Indeed, the most general case is that patterns are collected for + scan points. The scan generator of an electron microscope is instructed + to steer the beam in such a way across the specimen surface that the + beam illuminates certain positions for a certain amount time (usually + equally-spaced and spending about the same amount of time at each + position). + + Therefore, scan positions can be due to such regular flight plans and + represent sampling on lines, line stacks, rectangular regions-of- + interests, but also could instruct spiral, random, or adaptive scans + instead of tessellations with square or hexagonal pixels. + + The majority of EBSD maps is though is reporting results for a regular + grid (square, hexagon). What matters though in terms of damage induced + by the electron beam and signal quality is the real electron dose + history, i.e. for how long the beam exposed which location of the + specimen. Especially when electron charging occurs (i.e. an excess + amount of charge accumulates due to e.g. poor conducting away of this + charge or an improper mounting, too high dose, etc. such details are + relevant. + + Specifically, the default visualization is an inverse pole-figure (IPF) + map with the usual RGB color coding. Different strategies and + normalization schemes are in use to define such color coding. + + Finally, we should mention that each ipf_map represents data for + scan points indexed as one phase. The alias/name of this phase should + be stored in phase_name, the phase_identifier give an ID which must + not be zero as this value is reserved for non-indexed / null model scan + points. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the x axis + + + + + + + For each stereographic standard triangle (SST), i.e. a rendering of + the fundamental zone of the crystal-symmetry-reduced orientation space SO3, + it is possible to define a color model which assigns each point in + the fundamental zone a color. + Different mapping models are in use and implement (slightly) different + scaling relations. Differences are which base colors of the RGB + color model are placed in which extremal position of the SST + and where the white point is located. For further details see: + + * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the em_om + parsers takes a rasterized image which is rendered by the backend + tool. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + This application definition also enables to describe a workflow where several + EBSD datasets are not only documented but also correlated based on time, + position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + + + + + + + + + + + An overview of the entire reconstructed volume. For details about + what defines the image contrast inspect descriptor. + + + + Descriptor representing the image contrast. + + + + + + Container holding a default plot of the reconstructed volume. + + + + + + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Signal + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + Calibrated center of mass of the pixel along the fast axis. + + + + + + + Label for the y axis + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + The same comments apply as to the two-dimensional representation. + + + + Specifying which phase this IPF mapping visualizes. + + + + + Alias/name for the phase whose indexed scan points are displayed. + + + + + Which IPF definition computation according to backend. + + + + + + Along which axis to project? Typically [0, 0, 1] is chosen. + + + + + + + + Bitdepth used for the RGB color model. Usually 8 bit. + + + + + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + + + + + + + + + The RGB image which represents the IPF map. + + + + + + + + + + RGB array, with resolution per fastest changing value + defined by bitdepth. + + + + + + + + + + + IPF color-coded orientation mapping + + + + + + Calibrated center of mass of the pixel along the slow axis. + + + + + + + Label for the z axis + + + + + + + Calibrated center of mass of the pixel along the faster axis. + + + + + + + Label for the y axis + + + + + + + Calibrated center of mass of the pixel along the fastest axis. + + + + + + + Label for the x axis + + + + + + + Same comments as for the two-dimensional case apply. + + + + + + + + + + RGB array, with resolution per fastest changing value defined by bitdepth. + + + + + + + + + + IPF color key in stereographic standard triangle (SST) + + + + + + Pixel coordinate along the slow axis. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the fast axis. + + + + + + + Label for the x axis + + + + + + + + + + diff --git a/contributed_definitions/NXem_ebsd_conventions.nxdl.xml b/contributed_definitions/NXem_ebsd_conventions.nxdl.xml new file mode 100644 index 0000000000..7ef85f8716 --- /dev/null +++ b/contributed_definitions/NXem_ebsd_conventions.nxdl.xml @@ -0,0 +1,610 @@ + + + + + + + Conventions for rotations and coordinate systems to interpret EBSD data. + + This is the main issue which currently is not in all cases documented + and thus limits the interoperability and value of collected EBSD data. + Not communicating EBSD data with such contextual pieces of information + and the use of file formats which do not store this information is the + key unsolved problem. + + + + + Mathematical conventions and materials-science-specific conventions + required for interpreting every collection of orientation data. + + + + Convention how a positive rotation angle is defined when viewing + from the end of the rotation unit vector towards its origin, + i.e. in accordance with convention 2 of + DOI: 10.1088/0965-0393/23/8/083501. + Counter_clockwise is equivalent to a right-handed choice. + Clockwise is equivalent to a left-handed choice. + + + + + + + + + + How are rotations interpreted into an orientation + according to convention 3 of + DOI: 10.1088/0965-0393/23/8/083501. + + + + + + + + + + How are Euler angles interpreted given that there are several + choices (e.g. ZXZ, XYZ, etc.) according to convention 4 of + DOI: 10.1088/0965-0393/23/8/083501. + The most frequently used convention is ZXZ which is based on + the work of H.-J. Bunge but other conventions are possible. + + + + + + + + + To which angular range is the rotation angle argument of an + axis-angle pair parameterization constrained according to + convention 5 of DOI: 10.1088/0965-0393/23/8/083501. + + + + + + + + + Which sign convention is followed when converting orientations + between different parameterizations/representations according + to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. + + + + + + + + + + + Details about eventually relevant named directions that may + give reasons for anisotropies. The classical example is cold-rolling + where one has to specify which directions (rolling, transverse, and normal) + align how with the direction of the base vectors of the sample_reference_frame. + + + + Type of coordinate system and reference frame according to + convention 1 of DOI: 10.1088/0965-0393/23/8/083501. + + + + + + + + + + Direction of the positively pointing x-axis base vector of + the processing_reference_frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. + + + + + + + + + + + + + + Name or alias assigned to the x-axis base vector, e.g. rolling direction. + + + + + Direction of the positively pointing y-axis base vector of + the processing_reference_frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + + + + + + + + + + + + + + Name or alias assigned to the y-axis base vector, e.g. transverse direction. + + + + + Direction of the positively pointing z-axis base vector of + the processing_reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + + + + + + + + + + + + + + Name or alias assigned to the z-axis base vector, e.g. normal direction. + + + + + Location of the origin of the processing_reference_frame. + This specifies the location Xp = 0, Yp = 0, Zp = 0. + Assume regions-of-interest in this reference frame form a + rectangle or cuboid. + Edges are interpreted by inspecting the direction of their + outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + + + + + + + + + + + + + + + + + Details about the sample/specimen reference frame. + + + + Type of coordinate system and reference frame according to + convention 1 of DOI: 10.1088/0965-0393/23/8/083501. + The reference frame for the sample surface reference is used for + identifying positions on a (virtual) image which is formed by + information collected from an electron beam scanning the + sample surface. We assume the configuration is inspected by + looking towards the sample surface from a position that is + located behind the detector. + Reference DOI: 10.1016/j.matchar.2016.04.008 + The sample surface reference frame has coordinates Xs, Ys, Zs. + In three dimensions these coordinates are not necessarily + located on the surface of the sample as there are multiple + faces/sides of the sample. Most frequently though the coordinate + system here is used to define the surface which the electron + beam scans. + + + + + + + + + + Direction of the positively pointing x-axis base vector of + the sample surface reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + + + + + + + + + + + + + + Direction of the positively pointing y-axis base vector of + the sample surface reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + + + + + + + + + + + + + + Direction of the positively pointing z-axis base vector of + the sample surface reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + + + + + + + + + + + + + + Location of the origin of the sample surface reference frame. + This specifies the location Xs = 0, Ys = 0, Zs = 0. + Assume regions-of-interest in this reference frame form a + rectangle or cuboid. + Edges are interpreted by inspecting the direction of their + outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + + + + + + + + + + + + + + + + + Details about the detector reference frame. + + + + Type of coordinate system/reference frame used for + identifying positions in detector space Xd, Yd, Zd, + according to DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + + Direction of the positively pointing x-axis base vector of + the detector space reference frame. We assume the configuration + is inspected by looking towards the sample surface from a + position that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + + + + + + + + + + + + + + Direction of the positively pointing y-axis base vector of + the detector space reference frame. We assume the configuration + is inspected by looking towards the sample surface from a + position that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + Direction of the positively pointing z-axis base vector of + the detector space reference frame. We assume the configuration + is inspected by looking towards the sample surface from a + position that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + Where is the origin of the detector space reference + frame located. This is the location of Xd = 0, Yd = 0, Zd = 0. + Assume regions-of-interest in this reference frame form a + rectangle or cuboid. + Edges are interpreted by inspecting the direction of their + outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + + + + + + + + + + + + + + + + + Details about the gnomonic projection reference frame. + + + + Type of coordinate system/reference frame used for identifying + positions in the gnomonic projection space Xg, Yg, Zg + according to DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + + Direction of the positively pointing "gnomomic" x-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + + + + + + + + + + + + + + Direction of the positively pointing "gnomomic" y-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + Direction of the positively pointing "gnomomic" z-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + Is the origin of the gnomonic coordinate system located + where we assume the location of the pattern centre. + This is the location Xg = 0, Yg = 0, Zg = 0 according to + reference DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + + Details about the definition of the pattern centre + as a special point in the gnomonic projection reference frame. + + + + From which border of the EBSP (in the detector reference frame) + is the pattern centre's x-position (PCx) measured? + Keywords assume the region-of-interest is defined by + a rectangle. We observe this rectangle and inspect the + direction of the outer-unit normals to the edges of + this rectangle. + + + + + + + + + + + + In which direction are positive values for PCx measured from + the specified boundary. Keep in mind that the gnomonic space + is in virtually all cases embedded in the detector space. + Specifically, the XgYg plane is defined such that it is + embedded/laying inside the XdYd plane (of the detector + reference frame). + When the normalization direction is the same as e.g. the + detector x-axis direction, we state that we effectively + normalize in fractions of the width of the detector. + + The issue with terms like width and height is that these + degenerate if the detector region-of-interest is square-shaped. + This is why we should better avoid talking about width and height but + state how we would measure distances practically with a ruler and + how we then measure positive distances. + + + + + + + + + + + + From which border of the EBSP (in the detector reference + frame) is the pattern centre's y-position (PCy) measured? + For further details inspect the help button of + xaxis_boundary_convention. + + + + + + + + + + + + In which direction are positive values for PCy measured from + the specified boundary. + For further details inspect the help button of + xaxis_normalization_direction. + + + + + + + + + + + + diff --git a/base_classes/NXunit_cell.nxdl.xml b/contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml similarity index 54% rename from base_classes/NXunit_cell.nxdl.xml rename to contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml index b20c22cbc1..5b0b1ff499 100644 --- a/base_classes/NXunit_cell.nxdl.xml +++ b/contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml @@ -1,4 +1,4 @@ - + - + + + + Number of reflectors (Miller crystallographic plane triplets). + + Number of atom positions. @@ -30,123 +35,65 @@ - Description of a unit cell, i.e., the crystal structure of a single - thermodynamic phase. + Crystal structure phase models used for indexing Kikuchi pattern. + + This base class contains key metadata relevant to every physical + kinematic or dynamic diffraction model to be used for simulating + Kikuchi diffraction pattern. + The actual indexing of Kikuchi pattern however maybe use different + algorithms which build on these simulation results but evaluate different + workflows of comparing simulated and measured Kikuchi pattern to make + suggestions which orientation is the most likely (if any) for each + scan point investigated. + + Traditionally Hough transform based indexing has been the most frequently + used algorithm. More and more dictionary based alternatives are used. + Either way both algorithm need a crystal structure model. + - Identifier of an entry resolvable via crystallographic_database - which was used for creating this structure model. + Identifier of an entry from crystallographic_database which was used + for creating this structure model. Name of the crystallographic database to resolve - crystallographic_database_identifier e.g. COD, ICSD, or others. - - - - - A lattice system is a group of lattices with the same set of lattice point groups. - For further information, see https://en.wikipedia.org/wiki/Crystal_system. - - - - - - - - - - - - - - Crystallographic space group. - A space group is the symmetry group of a repeating pattern in space. - For further information, see International Table for Crystallography (https://it.iucr.org/). - - - - - Crystallographic point group. - A crystallographic point group is a set of symmetry operations, corresponding to one of the point groups in three dimensions, - such that each operation (perhaps followed by a translation) would leave the structure of a crystal unchanged. - This field should use Schoenflies notation (see Schoenflies, A., Krystallsysteme und Krystallstructur, 1891). - For further information, see https://dictionary.iucr.org/Point_group. - - - - - Laue group (also called Laue class). - The Laue classes are eleven geometric crystal classes containing centrosymmetric crystallographic types of point groups and their subgroups. - When absorption is negligible and Friedel's law applies, it is impossible to distinguish by diffraction between a centrosymmetric point group - and one of its non-centrosymmetric subgroups; only point groups belonging to different Laue classes can then be distinguished. - For further information, see https://dictionary.iucr.org/Laue_class. + crystallographic_database_identifier e.g. COD or others. - - - Crystallography unit cell parameters a, b, and c - - - - - - - - Crystallography unit cell vector a - - - - - - - For definining which coordinate system the unit cell vector a is defined in. - - - - + - Crystallography unit cell vector b + Crystallography unit cell parameters a, b, and c. - - - For definining which coordinate system the unit cell vector b is defined in. - - - + + - Crystallography unit cell vector c + Crystallography unit cell parameters alpha, beta, and gamma. - - - For definining which coordinate system the unit cell vector c is defined in. - - - + - Crystallography unit cell angles alpha, beta, and gamma + Volume of the unit cell - - - - + - Volume of the unit cell + Crystallographic space group - + True if space group is considered a centrosymmetric one. @@ -163,16 +110,43 @@ False if space group is consider a non-chiral one. + + + Laue group + + + + + + Point group using International Notation. + + + + + + Crystal system + + + + + + + + + + + - Identifier for the phase. - The value 0 is reserved for the unknown phase which represents the null-model - that no phase model was sufficiently significantly confirmed. + Numeric identifier for each phase. + The value 0 is reserved for the unknown phase essentially representing the + null-model that no phase model was sufficiently significantly confirmed. + Consequently, the value 0 must not be used as a phase_identifier. - Trivial name of the phase/alias. + Name of the phase/alias. @@ -185,9 +159,9 @@ - The hash value :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` the number of protons and :math:`N` the number of neutrons - of each isotope respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. + of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ @@ -202,13 +176,9 @@ - - - Reference to an instance of NXcoordinate_system whereby the positions can be - resolved. - - + Relative occupancy of the atom position. @@ -217,9 +187,38 @@ - + + + How many reflectors are distinguished. Value has to be n_hkl. + + + + + + Miller indices :math:`(hkl)`. + + + + + + + - For definining which coordinate system the unit cell parameters are defined in. + D-spacing. + + + + + + + Relative intensity of the signal for the plane. + + + + + diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml new file mode 100644 index 0000000000..3207888517 --- /dev/null +++ b/contributed_definitions/NXenergydispersion.nxdl.xml @@ -0,0 +1,90 @@ + + + + + + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. + + + + Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, + mirror, retarding grid, etc. + + + + + Energy of the electrons on the mean path of the analyser. Pass energy for + hemispherics, drift energy for tofs. + + + + + Center of the energy window + + + + + The interval of transmitted energies. It can be two different things depending + on whether the scan is fixed or swept. With a fixed scan it is a 2 vector + containing the extrema of the transmitted energy window (smaller number first). + With a swept scan of m steps it is a 2xm array of windows one for each + measurement point. + + + + + Size, position and shape of a slit in dispersive analyzer, e.g. entrance and + exit slits. + + + + + Diameter of the dispersive orbit + + + + + Way of scanning the energy axis (fixed or sweep). + + + + + + + + + Length of the tof drift electrode + + + + + Deflectors in the energy dispersive section + + + + + Individual lenses in the energy dispersive section + + + diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml new file mode 100644 index 0000000000..4192c48798 --- /dev/null +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -0,0 +1,226 @@ + + + + + + Metadata and settings of an electron microscope for scans and images. + + The need for such a structuring of data is evident from the fact that + electron microscopes are dynamic. Oftentimes it suffices to calibrate the + instrument at the start of the session. Subsequently, data (images, spectra, etc.) + can be collected. Users may wish to take only a single scan or image and + complete their microscope session; however + + frequently users are working much longer at the microscope, recalibrate and take + multiple data items (scans, images, spectra). Each item comes with own detector + and eventually on-the-fly processing settings and calibrations. + + For the single data item use case one may argue that the need for an additional + grouping is redundant. Instead, the metadata could equally be stored inside + the respective groups of the top-level mandatory NXinstrument group. + On the flip side, even for a session with a single image, it would also not + harm to nest the data. + + In fact, oftentimes scientists feel that there is a need to store details + about eventual drift of the specimen in its holder (if such data is available) + or record changes to the lens excitations or apertures used and/or changed. + Although current microscopes are usually equipped with stabilization + systems for many of the individual components, it can still be useful + to store time-dependent data in detail. + + Another reason if not a need for having more finely granularizable options for + storing time-dependent data, is that over the course of a session one may + reconfigure the microscope. What is a reconfiguration? This could be the + change of an aperture mode because a scientist may first collect an image + with some aperture and then pick a different value and continue. + As the aperture affects the electron beam, it will affect the system. + + Let aside for a moment the technology and business models, an EM could be + monitored (and will likely become so more in the future) for streaming out + spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied + and the specimen repositioned. + + Some snapshot or integrated data from this stream are relevant for understanding + signal genesis and electron/ion-beam-sample interaction (paths). In such a generic + case it might be necessary to sync these streaming data with those intervals + in time when specific measurements are taken (spectra collected, + images taken, diffraction images indexed on-the-fly). + + Therefore, both the instrument and specimen should always be considered as dynamic. + Scientists often report or feel (difficult to quantify) observations that + microscopes *perform differently* across sessions, without sometimes being + able to identify clear root causes. Users of the instrument may consider + such conditions impractical, or *too poor* and thus either abort their session + or try to bring the microscope first into a state where conditions are considered + more stable, better, or of some whatever high enough quality to reuse + data collection. + + In all these cases it is practical to have a mechanism how time-dependent data + of the instrument state can be stored and documented in a interoperable way. + Where should these data be stored? With NeXus these data should not only be + stored in the respective instrument component groups of the top-level NXinstrument. + The reason is that this group should be reserved for as stable as possible + quantities which do not change over the session. Thereby we can avoid to store + repetitively that there is a certain gun or detector available but just store + the changes. This is exactly what the em_lab group is for inside NXevent_data_em. + + Ideally, NXevent_data_em are equipped with a start_time and end_time + to represent a time interval (remind the idea of the instrument state stream) + during which the scientist considered (or practically has to consider) + the microscope (especially ebeam and specimen) as stable enough. + + Arguably it is oftentimes tricky to specify a clear time interval when the + microscope is stable enough. Take for instance the acquisition of an image + or spectra stack. It is not fully possible (technically) to avoid that even + within a single image instabilities of the beam are faced and drift occurs. + Maybe in many cases this these instabilities are irrelevant but does this + warrant to create a data schema where either the microscope state can only + be stored very coarsely or one is forced to store it very finely? + + This is a question of how one wishes to granularize pieces of information. + A possible solution is to consider each probed position, i.e. point in time + when the beam was not blanked and thus when the beam illuminates a portion of + the material, i.e. the interaction volume, whose signal contributions are then + counted by the one or multiple detector(s) as per pixel- or per voxel signal + in the region-of-interest. + NXevent_data_em in combination with the NXem application definition + allows researchers to document this. Noteworty to mention is that we understand + that in many cases realizing such a fine temporal and logical granularization + and data collection is hard to achieve in practice. + + A frequently made choice, mainly for convenience, is that drift and scan distortions + are considered a feature or inaccuracy of the image and/or spectrum and thus + one de facto accepts that the microscope was not as stable as expected during + the acquisition of the image. We learn that the idea of a time interval + during the microscope session may be interpreted differently by different + users. Here we consider the choice to focus on images and spectra, and eventually + single position measurements as the smallest granularization level. + Which eventually may require to add optional NXprocess instances for respectively + collected data to describe the relevant distortions. Nevertheless, the distortions + are typically corrected for by numerical protocols. This fact warrants to + consider the distortion correction a computational workflow which can be + modelled as a chain of NXprocess instances each with own parameters. an own + A more detailed overview of such computational steps to cope with scan distortions + is available in the literature: + + * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ + * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ + * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ + + For specific simulation purposes, mainly in an effort to digitally repeat + or simulate the experiment, it is tempting to consider dynamics of the + instrument, implemented as time-dependent functional descriptions of + e.g. lens excitations, beam shape functions, trajectories of groups of + electrons, or detector noise models. + + For now the preferred strategy to handle these cases is through + customizations of the specific fields within NXevent_data_em instances. + + Another alternative could be to sample finer, eventually dissimilarly along + the time axi; however this may cause situations where an NXevent_data_em + instance does not contain specific measurements (i.e. images, spectra of + scientific relevance). + + In this case one should better go for a customized application definition + with a functional property description inside members (fields or groups) + in NXevent_data_em instances; or resort to a specific offspring application + definition of NXem which documents metadata for tracking explicitly electrons + (with ray-tracing based descriptors/computational geometry descriptors) + or tracking of wave bundles. + + This perspective on much more subtle time-dependent considerations of electron + microscopy can be advantageous also for storing details of time-dependent + additional components that are coupled to and/or synced with a microscope. + + Examples include cutting-edge experiments where the electron beam gets + coupled/excited by e.g. lasers. In this case, the laser unit should be + registered under the top-level NXinstrument section. Its spatio-temporal + details could be stored inside respective additional groups of the NXinstrument + though inside instances of here detailed NXevent_data_em. + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval started. If the user wishes to specify an + interval of time that the snapshot should represent during which the instrument + was stable and configured using specific settings and calibrations, + the start_time is the start (left bound of the time interval) while + the end_time specifies the end (right bound) of the time interval. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval ended. + + + + + Reference to a specific state and setting of the microscope. + + + + + Which specific event/measurement type. Examples are: + + * In-lens/backscattered electron, usually has quadrants + * Secondary_electron, image, topography, fractography, overview images + * Backscattered_electron, image, Z or channeling contrast (ECCI) + * Bright_field, image, TEM + * Dark_field, image, crystal defects + * Annular dark field, image (medium- or high-angle), TEM + * Diffraction, image, TEM, or a comparable technique in the SEM + * Kikuchi, image, SEM EBSD and TEM diffraction + * X-ray spectra (point, line, surface, volume), composition EDS/EDX(S) + * Electron energy loss spectra for points, lines, surfaces, TEM + * Auger, spectrum, (low Z contrast element composition) + * Cathodoluminescence (optical spectra) + * Ronchigram, image, alignment utility specifically in TEM + * Chamber, e.g. TV camera inside the chamber, education purposes. + + This field may also be used for storing additional information about the event. + + + + + + + + + diff --git a/base_classes/NXapm_sim.nxdl.xml b/contributed_definitions/NXevent_data_em_set.nxdl.xml similarity index 71% rename from base_classes/NXapm_sim.nxdl.xml rename to contributed_definitions/NXevent_data_em_set.nxdl.xml index 90ac529f2f..7ec26670c2 100644 --- a/base_classes/NXapm_sim.nxdl.xml +++ b/contributed_definitions/NXevent_data_em_set.nxdl.xml @@ -1,10 +1,10 @@ - + - - + - Base class for simulating ion extraction from matter via laser and/or voltage - pulsing. + Container to hold NXevent_data_em instances of an electron microscope session. + + An event is a time interval during which the microscope was configured, + considered stable, and used for characterization. - + diff --git a/base_classes/NXfit_parameter.nxdl.xml b/contributed_definitions/NXfabrication.nxdl.xml similarity index 56% rename from base_classes/NXfit_parameter.nxdl.xml rename to contributed_definitions/NXfabrication.nxdl.xml index f8762232f5..1f940f0795 100644 --- a/base_classes/NXfit_parameter.nxdl.xml +++ b/contributed_definitions/NXfabrication.nxdl.xml @@ -1,10 +1,10 @@ - + - + - A parameter for a fit function. - This would typically be a variable that - is optimized in a fit. + Details about a component as defined by its manufacturer. - - - The name of the parameter. - - - + - A description of what this parameter represents. + Company name of the manufacturer. - + - The value of the parameter. After fitting, this would store the - optimized value. + Version or model of the component named by the manufacturer. - + - The minimal value of the parameter, to be used as a constraint during fitting. + Ideally, (globally) unique persistent identifier, i.e. + a serial number or hash identifier of the component. - + - The maximal value of the parameter, to be used as a constraint during fitting. + Free-text list with eventually multiple terms of + functionalities which the component offers. + diff --git a/base_classes/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml similarity index 57% rename from base_classes/NXibeam_column.nxdl.xml rename to contributed_definitions/NXibeam_column.nxdl.xml index 9600764bbd..0377b93f40 100644 --- a/base_classes/NXibeam_column.nxdl.xml +++ b/contributed_definitions/NXibeam_column.nxdl.xml @@ -1,4 +1,4 @@ - + - + + - Base class for a set of components equipping an instrument with FIB capabilities. + Container for components of a focused-ion-beam (FIB) system. - Focused-ion-beam (FIB) capabilities turn especially scanning electron microscopes - into specimen preparation labs. FIB is a material preparation technique whereby - portions of the sample are illuminated with a focused ion beam with controlled - intensity. The beam is intense enough and with sufficient ion momentum to - remove material in a controlled manner. + FIB capabilities turn especially scanning electron microscopes + into specimen preparation labs. FIB is a material preparation + technique whereby portions of the sample are illuminated with a + focused ion beam with controlled intensity intense enough and with + sufficient ion momentum to remove material in a controllable manner. The fact that an electron microscope with FIB capabilities has needs a - second gun with own relevant control circuits, focusing lenses, and other - components, warrants the definition of an own base class to group these - components and distinguish them from the lenses and components for creating - and shaping the electron beam. + second gun with own relevant control circuits, focusing lenses, and + other components, warrants an own base class to group these components + and distinguish them from the lenses and components for creating and + shaping the electron beam. For more details about the relevant physics and application examples consult the literature, for example: - * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ - * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ - * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ + * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ + * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ + * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ - + The source which creates the ion beam. - + Given name/alias for the ion gun. - + Emitter type used to create the ion beam. @@ -69,7 +71,7 @@ - + Ideally, a (globally) unique persistent identifier, link, or text to a resource which gives further details. @@ -78,56 +80,65 @@ Which ionized elements or molecular ions form the beam. - Examples are gallium, helium, neon, argon, krypton, + Examples are gallium, helium, neon, argon, krypton, or xenon, O2+. - - - Average/nominal flux - - - + + Average/nominal brightness - + Charge current - + - Ion acceleration voltage upon source exit and - entering the vacuum flight path. + Ion acceleration voltage upon source exit and entering the vacuum flight path. - + + - To be defined more specifically. Community suggestions are welcome. + Affine transformation which detail the arrangement in the microscope relative to + the optical axis and beam path. - + - + + - - - + - Individual characterization results for the position, shape, and characteristics of the ion beam. - :ref:`NXtransformations` should be used to specify the location or position + NXtransformations should be used to specify the location or position at which details about the ion beam are probed. - - + diff --git a/contributed_definitions/NXimage_set.nxdl.xml b/contributed_definitions/NXimage_set.nxdl.xml new file mode 100644 index 0000000000..a482480c85 --- /dev/null +++ b/contributed_definitions/NXimage_set.nxdl.xml @@ -0,0 +1,128 @@ + + + + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Container for reporting a set of images taken. + + + + Details how images were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXimage_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXimage_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + Image (stack). + + + + Image intensity values. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center of mass along y direction. + + + + + + + Coordinate along y direction. + + + + + + Pixel coordinate center of mass along x direction. + + + + + + + Coordinate along x direction. + + + + + diff --git a/contributed_definitions/NXimage_set_em_adf.nxdl.xml b/contributed_definitions/NXimage_set_em_adf.nxdl.xml new file mode 100644 index 0000000000..21616ca476 --- /dev/null +++ b/contributed_definitions/NXimage_set_em_adf.nxdl.xml @@ -0,0 +1,156 @@ + + + + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Container for reporting a set of annular dark field images. + + Virtually the most important case is that spectra are collected in + a scanning microscope (SEM or STEM) for a collection of points. + The majority of cases use simple d-dimensional regular scan pattern, + such as single point, line profiles, or (rectangular) surface mappings. + The latter pattern is the most frequently used. + + For now the base class provides for scans for which the settings, + binning, and energy resolution is the same for each scan point. + + + + Details how (HA)ADF images were processed from the detector readings. + + + + Typically the name of the input, (vendor) file from which all + the NXdata instances in this NXimage_set_em_adf were loaded during + parsing to represent them in e.g. databases. + + + + An at least as strong as SHA256 hashvalue of the dataset/file + which represents the source digitally to support provenance tracking. + + + + + + Commercial or otherwise given name to the program which was used + to process detector data into the adf image(s). + + + + Program version plus build number, commit hash, or description + of an ever persistent resource where the source code of the program + and build instructions can be found so that the program + can be configured in such a manner that the result file + is ideally recreatable yielding the same results. + + + + + + Annulus inner half angle + + + + + Annulus outer half angle + + + + + + Annular dark field image stack. + + + + + Image intensity values. + + + + + + + + + + Image identifier + + + + + + + Image ID. + + + + + + Pixel center of mass along y direction. + + + + + + + Coordinate along y direction. + + + + + + Pixel center of mass along x direction. + + + + + + + Coordinate along x direction. + + + + + diff --git a/contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml b/contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml new file mode 100644 index 0000000000..776b539304 --- /dev/null +++ b/contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml @@ -0,0 +1,205 @@ + + + + + + + + Number of scanned points. Scan point may have none, one, or more pattern. + + + + + Number of diffraction pattern. + + + + + Number of pixel per Kikuchi pattern in the slow direction. + + + + + Number of pixel per Kikuchi pattern in the fast direction. + + + + + Measured set of electron backscatter diffraction data, aka Kikuchi pattern. + Kikuchi pattern are the raw data for computational workflows in the field + of orientation (imaging) microscopy. The technique is especially used in + materials science and materials engineering. + + Based on a fuse of the `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ + of the DREAM.3D community and the open H5OINA format of Oxford Instruments + `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ + + EBSD can be used, usually with FIB/SEM microscopes, for three-dimensional + orientation microscopy. So-called serial section analyses. For a detailed + overview of these techniques see e.g. + + * `M. A. Groeber et al. <https://doi.org/10.1186/2193-9772-3-5>`_ + * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ + * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ + + With serial-sectioning this involves however always a sequence of measuring, + milling. In this regard, each serial section (measuring) and milling + is an own NXevent_data_em instance and thus there such a three-dimensional + characterization should be stored as a set of two-dimensional data, + with as many NXevent_data_em instances as sections were measured. + + These measured serial sectioning images need virtually always post-processing + to arrive at the aligned and cleaned image stack before a respective digital + model of the inspected microstructure can be analyzed. The resulting volume + is often termed a so-called (representative) volume element (RVE). + Several software packages are available for performing this post-processing. + For now we do not consider metadata of these post-processing steps + as a part of this base class because the connection between the large variety + of such post-processing steps and the measured electron microscopy data + is usually very small. + + If we envision a (knowledge) graph for EBSD it consists of individual + sub-graphs which convey information about the specimen preparation, + the measurement of the specimen in the electron microscope, + the indexing of the collected Kikuchi pattern stack, + eventual post-processing of the indexed orientation image + via similarity grouping algorithms to yield (grains, texture). + Conceptually these post-processing steps are most frequently + serving the idea to reconstruct quantitatively so-called + microstructural features (grains, phases, interfaces). Materials scientists + use these features according to the multi-scale materials modeling paradigm + to infer material properties. They do so by quantifying correlations between + the spatial arrangement of the features, their individual properties, + and (macroscopic) properties of materials. + + + + + Details how Kikuchi pattern were processed from the detector readings. + Scientists interested in EBSD should inspect the respective NXem_ebsd + application definition which can be used as a partner application definition + to detail substantially more details to this processing. + + + + + Collected Kikuchi pattern as an image stack. As raw and closest to the + first retrievable measured data as possible, i.e. do not use this + container to store already averaged, filtered or whatever post-processed + pattern unless these are generated unmodifiably by the instrument + given the way how the instrument and control software was configured + for your microscope session. + + + + Array which resolves the scan point to which each pattern belongs. + Scan points are evaluated in sequence starting from scan point zero + until scan point n_sc - 1. Evaluating the cumulated of this array + decodes which pattern in intensity belong to which scan point. + In an example we may assume we collected three scan points. For the first + we measure one pattern, for the second we measure three pattern, + for the last we measure no pattern. + The values of scan_point_identifier will be 0, 1, 1, 1, as we have + measured four pattern in total. + + In most cases usually one pattern is averaged by the detector for + some amount of time and then reported as one pattern. Use compressed + arrays allows to store the scan_point_identifier efficiently. + + + + + + + + Signal intensity. For so-called three-dimensional or serial sectioning + EBSD it is necessary to follow a sequence of specimen surface preparation + and data collection. In this case users should collect the data for each + serial sectioning step in an own instance of NXimage_set_em_kikuchi. + All eventual post-processing of these measured data should be documented + via NXebsd, resulting microstructure representations should be stored + as NXms. + + + + + + + + + + Kikuchi pattern intensity + + + + + + + Pattern are enumerated starting from 0 to n_p - 1. + + + + + + + Kikuchi pattern identifier + + + + + + Pixel coordinate along the y direction. + + + + + + + Label for the y axis + + + + + + Pixel coordinate along the x direction. + + + + + + + Label for the x axis + + + + + + diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml new file mode 100644 index 0000000000..a6beeb6482 --- /dev/null +++ b/contributed_definitions/NXinteraction_vol_em.nxdl.xml @@ -0,0 +1,37 @@ + + + + + Base class for storing details about a modelled shape of interaction volume. + + The interaction volume is mainly relevant in scanning electron microscopy + when the sample is thick enough so that the beam is unable to illuminate + through the specimen. + Computer models like Monte Carlo or molecular dynamics / electron beam + interaction simulations can be used to qualify and/or quantify the shape of + the interaction volume. + + Explicit or implicit descriptions are possible. + + * An implicit description is via a set of electron/specimen interactions + represented ideally as trajectory data from the computer simulation. + * An explicit description is via an iso-contour surface using either + a simulation grid or a triangulated surface mesh of the approximated + iso-contour surface evaluated at specific threshold values. + Iso-contours could be computed from electron or particle fluxes through + an imaginary control surface (the iso-surface). + Threshold values can be defined by particles passing through a unit control + volume (electrons) or energy-levels (e.g. the case of X-rays). + Details depend on the model. + * Another explicit description is via theoretical models which may + be relevant e.g. for X-ray spectroscopy + + Further details on how the interaction volume can be quantified + is available in the literature for example: + + * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ + * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ + + + + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml new file mode 100644 index 0000000000..99a19f2e3c --- /dev/null +++ b/contributed_definitions/NXion.nxdl.xml @@ -0,0 +1,168 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). + + + + + Number of mass-to-charge-state-ratio range intervals for ion type. + + + + + Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. + + + + A unique identifier whereby such an ion can be referred to + via the service offered as described in identifier_type. + + + + + How can the identifier be resolved? + + + + + + + + Ion type (ion species) identifier. The identifier zero + is reserved for the special unknown ion type. + + + + + A vector of isotope hash values. + These values have to be stored in an array, sorted in decreasing order. + The array is filled with zero hash values indicating unused places. + The individual hash values are built with the following hash function: + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. + + Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + A supplementary row vector which decodes the isotope_vector into + a human-readable matrix of nuclids with the following formatting: + + The first row specifies the isotope mass number, i.e. using the hashvalues + from the isotope_vector this is :math:`Z + N`. As an example for a + carbon-14 isotope the number is 14. + The second row specifies the number of protons :math:`Z`, e.g. 6 for the + carbon-14 example. This row matrix is thus a mapping the notation of + using superscribed isotope mass and subscripted number of protons to + identify isotopes. + Unused places filling up to n_ivecmax need to be filled with zero. + + + + + + + + + Color code used for visualizing such ions. + + + + + Assumed volume of the ion. + + In atom probe microscopy this field can be used to store the reconstructed + volume per ion (average) which is typically stored in range files and will + be used when building a tomographic reconstruction of an atom probe + dataset. + + + + + Charge of the ion. + + + + + Signed charge state of the ion in multiples of electron charge. + + Only positive values will be measured in atom probe microscopy as the + ions are accelerated by a negatively signed bias electric field. + In the case that the charge state is not explicitly recoverable, + the value should be set to zero. + + In atom probe microscopy this is for example the case when using + classical range file formats like RNG, RRNG for atom probe data. + These file formats do not document the charge state explicitly. + They report the number of atoms of each element per molecular ion + surplus the mass-to-charge-state-ratio interval. + With this it is possible to recover the charge state only for + specific molecular ions as the accumulated mass of the molecular ion + is defined by the isotopes, which without knowing the charge leads + to an underconstrained problem. + Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + + + + + Human-readable ion type name (e.g. Al +++) + The string should consists of ASCII UTF-8 characters, + ideally using LaTeX notation to specify the isotopes, ions, and charge + state. Examples are 12C + or Al +++. + Although this name may be human-readable and intuitive, parsing such + names becomes impractical for more complicated cases. Therefore, for the + field of atom probe microscopy the isotope_vector should be the + preferred machine-readable format to use. + + + + + Associated lower (mqmin) and upper (mqmax) bounds of + mass-to-charge-state ratio interval(s) [mqmin, mqmax] + (boundaries included) for which the respective ion is one to be labelled + with ion_identifier. The field is primarily of interest to document the + result of indexing a ToF/mass spectrum. + + + + + + + + diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml new file mode 100644 index 0000000000..92be5ae595 --- /dev/null +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -0,0 +1,109 @@ + + + + + + Description of an electro-magnetic lens or a compound lens. + + For NXtransformations the origin of the coordinate system is placed + in the center of the lens + (its polepiece, pinhole, or another point of reference). + The origin should be specified in the NXtransformations. + + For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ + + + + Qualitative type of lens with respect to the number of pole pieces. + + + + + + + + + + + + Given name, alias, colloquial, or short name for the lens. + For manufacturer names and identifiers use respective manufacturer fields. + + + + + Name of the manufacturer who built/constructed the lens. + + + + + + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the lens. + + + + + Ideally an identifier, persistent link, or free text which gives further details + about the lens. + + + + + Excitation voltage of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + Excitation current of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + This field should be used when the exact voltage or current of the lens is not directly controllable + as the control software of the microscope does not enable users/or is was not configured to enable + the user to retrieve these values. In this case this field should be used to specify the value as + read from the control software. Although consumers of the application definition should not expect + this value to represent the exact physical voltage or excitation, it is still useful to know though + as it allows other users to reuse this lens setting, which, provided a properly working instrument + and software should bring the lenses into a similar state. + + + + + Specifies the position of the lens by pointing to the last transformation in the + transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the lens as a component in the instrument. + Typically, the components of a system should all be related relative to + each other and only one component should relate to the reference + coordinate system. + + + diff --git a/base_classes/NXlens_opt.nxdl.xml b/contributed_definitions/NXlens_opt.nxdl.xml similarity index 92% rename from base_classes/NXlens_opt.nxdl.xml rename to contributed_definitions/NXlens_opt.nxdl.xml index f413dc19f0..753a58e550 100644 --- a/base_classes/NXlens_opt.nxdl.xml +++ b/contributed_definitions/NXlens_opt.nxdl.xml @@ -1,4 +1,4 @@ - + - - + @@ -105,10 +104,8 @@ A draft of a new base class describing an optical lens - + If the lens has a coating describe the material and its properties. Some basic information can be found e.g. [here] @@ -185,14 +182,4 @@ the lens has different coatings on the front and back side. Abbe number (or V-number) of the lens. - - - The numerical aperture of the used incident light optics. - - - - - - - diff --git a/contributed_definitions/NXmanipulator.nxdl.xml b/contributed_definitions/NXmanipulator.nxdl.xml new file mode 100644 index 0000000000..dff2584fcf --- /dev/null +++ b/contributed_definitions/NXmanipulator.nxdl.xml @@ -0,0 +1,100 @@ + + + + + + Extension of NXpositioner to include fields to describe the use of manipulators + in photoemission experiments. + + + + Name of the manipulator. + + + + + A description of the manipulator. + + + + + Type of manipulator, Hexapod, Rod, etc. + + + + + Is cryocoolant flowing through the manipulator? + + + + + Temperature of the cryostat (coldest point) + + + + + Power in the heater for temperature control. + + + + + Temperature at the closest point to the sample. This field may also be found in + NXsample if present. + + + + + Current to neutralize the photoemission current. This field may also be found in + NXsample if present. + + + + + Possible bias of the sample with trespect to analyser ground. This field may + also be found in NXsample if present. + + + + + Class to describe the motors that are used in the manipulator + + + + + Refers to the last transformation specifying the positon of the manipulator in + the NXtransformations chain. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the manipulator as a component in the instrument. Conventions from + the NXtransformations base class are used. In principle, the McStas coordinate + system is used. The first transformation has to point either to another + component of the system or . (for pointing to the reference frame) to relate it + relative to the experimental setup. Typically, the components of a system should + all be related relative to each other and only one component should relate to + the reference coordinate system. + + + diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml new file mode 100644 index 0000000000..c2bfe957c6 --- /dev/null +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -0,0 +1,371 @@ + + + + + + + This is the most general application definition for multidimensional + photoelectron spectroscopy. + + + + + + Datetime of the start of the measurement. + + + + + + + + + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + + Full address (street, street number, ZIP, city, country) of the user's + affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + + + + + + The source used to generate the primary photons. Properties refer strictly to + parameters of the source, not of the output beam. For example, the energy of the + source is not the optical power of the beam, but the energy of the electron beam + in a synchrotron and so on. + + + + + + + + + + + + + + + + + + Type of probe. In photoemission it's always photons, so the full NIAC list is + restricted. + + + + + + + + + + + + Distance of the point of evaluation of the beam from the sample surface. + + + + + + + + + + + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. + + + + + + + + Scheme of the electron collection column. + + + + + + + + + + + + + + + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + + + + + + + + + + + + + + + Size, position and shape of the entrance slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + Size, position and shape of the exit slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + + + + + + + Type of electron amplifier in the first amplification step. + + + + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + + + + Raw data before calibration. + + + + + + + + Manipulator for positioning of the sample. + + + + + + + + + Document an event of data processing, reconstruction, or analysis for this data. + Describe the appropriate axis calibrations for your experiment using one or more + of the following NXcalibrations + + + + + Has an energy calibration been applied? + + + + + This is the calibrated energy axis to be used for data plotting. + + + + + + + Has an angular calibration been applied? + + + + + This is the calibrated angular axis to be used for data plotting. + + + + + + + Has an spatial calibration been applied? + + + + + This is the calibrated spatial axis to be used for data plotting. + + + + + + + Has an momentum calibration been applied? + + + + + This is the momentum axis to be used for data plotting. + + + + + + + + + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + + + + + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + + + + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). + + + + + Description of the surface preparation technique for the XPS experiment, i.e. + UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report + of the previous operations, in any format(NXnote allows to add pictures, audio, + movies). Alternatively, a reference to the location or a unique identifier or + other metadata file. In the case these are not available, free-text description. + + + + + + In the case of a fixed temperature measurement this is the scalar temperature of + the sample. In the case of an experiment in which the temperature is changed and + recoded, this is an array of length m of temperatures. This should be a link to + /entry/instrument/manipulator/sample_temperature. + + + + + + + + + + + + + + + + + + + + + + Represents a measure of one- or more-dimensional photoemission counts, where the + varied axis may be for example energy, momentum, spatial coordinate, pump-probe + delay, spin index, temperature, etc. The axes traces should be linked to the + actual encoder position in NXinstrument or calibrated axes in NXprocess. + + + + + diff --git a/contributed_definitions/NXms.nxdl.xml b/contributed_definitions/NXms.nxdl.xml new file mode 100644 index 0000000000..75a010f88c --- /dev/null +++ b/contributed_definitions/NXms.nxdl.xml @@ -0,0 +1,529 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of boundaries of the bounding box or primitive to domain. + + + + + Number of parameter required for the chosen orientation parameterization. + + + + + Number of texture components identified. + + + + + Application definition, spatiotemporal characterization of a microstructure. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment or computer simulation. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + + + + + Free-text description about the workflow (experiment/analysis/simulation). + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of this application definition rather than write details about the + experiment into this free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the characterization started. + + + + + ISO 8601 time code with local time zone offset to UTC included + when the characterization ended. + + + + + + + + + + Specify if the (characterization) results/data of this instance of an + application definition are based on the results of a simulation or the + results of a post-processing of measured data to describe + a microstructure. + + The term microstructure is used to describe the spatial arrangement of + crystal defects inside a sample/specimen without demanding necessarily + that this structure is mainly at the micron length scale. + Nanostructure and macrostructure are close synonyms. + Material architecture is a narrow synonym. + + Given that microstructure simulations nowadays more and more consider + the atomic arrangement, this application definition can also be used + to describe features at the scale of atoms. + + + + + + + + + Contact information and eventually details of at least one person + involved in creating this result. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service + should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + + Descriptive name or ideally (globally) unique persistent identifier. + + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + Container to hold different coordinate systems conventions. + A least a right-handed Cartesian coordinate system with base vectors + named x, y, and z has to be specified. Each base vector of the + coordinate system should be described with an NXtransformations instance. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The simulated or characterized material volume element aka domain. + At least one instance of geometry required either NXcg_grid, + NXcg_polyhedron_set, or NXcg_point_set. This geometry group needs + to contain details about the boundary conditions. + + + + + + + + A boundary to the volume element. + Either an instance of NXcg_hexahedron_set or of NXcg_ellipsoid_set. + + + + + How many distinct boundaries are distinguished. Value required equal to n_b. + + + + + Name of the boundaries. E.g. left, right, front, back, bottom, top, + + + + + + + + The boundary conditions for each boundary: + + 0 - undefined + 1 - open + 2 - periodic + 3 - mirror + 4 - von Neumann + 5 - Dirichlet + + + + + + + + + Collection of microstructural data observed/simulated. + + + + Integer which specifies the first index to be used for distinguishing + snapshots. Identifiers are defined either implicitly or explicitly. + For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate + if the identifiers are expected to start from 1 (referred to as + Fortran-/Matlab-) or from 0 (referred to as C-, Python-style index + notation) respectively. + + + + + + Summary quantities which are the result of some post-processing of + the snapshot data (averaging, integrating, interpolating). + Frequently used descriptors from continuum mechanics and thermodynamics + can be used here. A few examples are given. Each descriptor is currently + modelled as an instance of an NXprocess because it is relevant to + understand how the descriptors are computed. + + + + + + + + + + + + + + Measured or simulated physical time stamp for this snapshot. + Not to be confused with wall-clock timing or profiling data. + + + + + Iteration or increment counter. + + + + + + + + + + Conceptually distinguished object/feature in the ROI/ + system with some relevance. Instances of NXms_feature_set can + be nested to build a hierarchy of logically-related objects. + + A typical example for MD simulations is to have one + ms_feature_set for the atoms which is the parent to another + ms_feature_set for monomers/molecules/proteins which is then the + parent to another ms_feature_set for the secondary, another feature_set + for the tertiary, and the parent for another feature_set for the + quaternary structure. + + Another typical example from materials engineering is to have + one ms_feature_set for crystals (grains/phases) which serves as + the parent to another ms_feature_set for interfaces between these + crystals which then is the parent for another ms_feature_set to + describe the triple junctions which is then the parent for the + quadruple/higher-order junctions between which connect the + triple lines. + + Another example from discrete dislocation dynamics could be to + have one ms_feature_set for the dislocations (maybe separate + sets for each dislocation type or family) which are then + parents to other ms_feature_set which describe junctions between + dislocations or features along the dislocation line network. + + + + + + Details about the orientation distribution function + within the entire domain. + + + + With which method was the ODF approximated? + + + + + + TO BE DEFINED + + + + + TO BE DEFINED + + + + + Collection of texture components commonly referred to. + + + + Reference to or definition of a coordinate system with + which the definitions are interpretable. + + + + + + + + + + + Parameterized orientations. + + + + + + + + + Name of each texture component, e.g. Cube, Dillamore, Y. + + + + + + + + The portion of orientation space integrated over + to compute the volume fraction. + + + + + + + + The volume fraction of each texture component. + + + + + + + + + + + Details about the disorientation distribution function + within the entire domain. + + + + + Details about the grain boundary character distribution + within the entire domain. + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXms_feature_set.nxdl.xml b/contributed_definitions/NXms_feature_set.nxdl.xml new file mode 100644 index 0000000000..326d8cc54b --- /dev/null +++ b/contributed_definitions/NXms_feature_set.nxdl.xml @@ -0,0 +1,300 @@ + + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Dimensionality + + + + + Cardinality/number of members/features in the feature set. + + + + + Number of types in the dictionary of human-readable types of features. + + + + + Total number of parent identifier. + + + + + Set of topological/spatial features in materials build from other features. + + + + + + Name (or link?) to another NXms_feature_set which defines features what are + assumed as the parents/super_features of all members in this feature set. + If depends_on is set to "." or this attribute is not defined in an instance + of this application definition, assume that this feature_set instance + represents the root feature_set of the feature tree/graph. + + + + + + + What is the best matching description how dimensional the feature is. + + + + + + + + + + + + How many features/members are in this set? + + + + + + The keywords of the dictionary of human-readable types of features. + Using terms from a community-agreed upon controlled vocabulary, e.g. + atom, solute, vacancy, monomer, molecule, anti-site, crowd_ion, + quadruple junction, triple line, disconnection, dislocation, + kink, jog, stacking_fault, homo_phase_boundary, hetero_phase_boundary, + surface, thermal_groove_root, precipitate, dispersoid, pore, crack + is recommended. + + + + + + + + + The integer identifier used to resolve of which type each feature is, + i.e. the values of the dictionary of human-readable types of features. + + + + + + + + For each feature in the set specify the associated number of identifier + to parent features as are resolvable via depends_on. + This array enables to compute the array interval from which details for + specific features can be extracted as if they would be stored in an own + group. + + + + + + + + Concatenated array of parent identifier for each feature (in the sequence) + according to identifier and how the identifier of features in the here + described feature set are defined (implicitly from 0, to c-1 or via explicit + identifier. + + + + + + + + + Integer which specifies the first index to be used for distinguishing + features. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish features for explicit indexing. + + + + + + + + + Assumptions and parameter to arrive at geometric primitives + to locate zero-dimensional/point-(like) features which are + discretized/represented by points. + + + + + Assumptions, parameters, and details how positional uncertainty + of the geometry is quantified. + + + + + + + Assumptions and parameters to arrive at geometric primitives + to locate one-dimensional/line-like features which are + discretized by polylines. + + + + + + Assumptions, parameters, and details how positional uncertainty + of the geometry is quantified. + + + + + + Assumptions and parameters to arrive at geometric primitives + to locate two-dimensional/interface features which are + discretized by triangulated surface meshes. + + + + + + Assumptions, parameters, and details how positional uncertainty + of the geometry is quantified. + + + + + + Assumptions and parameters to arrive at geometric primitives + to locate three-dimensional/volumetric features which are + discretized by triangulated surface meshes of polyhedra. + + + + + + Assumptions, parameters, and details how positional uncertainty + of the geometry is quantified. + + + + + + + + + + diff --git a/contributed_definitions/NXms_score_config.nxdl.xml b/contributed_definitions/NXms_score_config.nxdl.xml new file mode 100644 index 0000000000..7aab8367c9 --- /dev/null +++ b/contributed_definitions/NXms_score_config.nxdl.xml @@ -0,0 +1,452 @@ + + + + + + + + Number of Bunge-Euler angle triplets for deformed grains. + + + + + Number of Bunge-Euler angle triplets for recrystallization nuclei. + + + + + Number of solitary unit domains to export. + + + + + Application definition to control a simulation with the SCORE model. + + + + + Version specifier of this application definition. + + + + + Official NeXus NXDL schema with which this file was written. + + + + + + + + + + + + + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + + + + + Relevant data to instantiate a starting configuration that is typically + a microstructure in deformed conditions where stored (elastic) energy + is stored in the form of crystal defects, which in the SCORE model are + is considered as mean-field dislocation content. + + + + Which model should be used to generate a starting microstructure. + + + + + + + + + + + Edge length of the cubic cells of each CA domain. + + + + + Extend of each CA domain in voxel along the x, y, and z direction. + Deformation of sheet material is assumed. + The x axis is assumed pointing along the rolling direction. + The y axis is assumed pointing along the transverse direction. + The z axis is assumed pointing along the normal direction. + + + + + + + + Extent of each deformed grain along the x, y, and z direction when type is + cuboidal. + + + + + + + + Average spherical diameter when type is poisson_voronoi. + + + + + Set of Bunge-Euler angles to sample orientations randomly from. + + + + + + + + + The EBSD dataset from which the initial microstructure is instantiated + if initial_microstructure/type has value ebsd. + + + + Path and name of the EBSD dataset from which to generate the starting + microstructure. + + + + SHA256 checksum of the file which contains the EBSD dataset. + + + + + + Size of the EBSD. The EBSD orientation mapping has to be on a + regular grid of square-shaped pixels. + + + + + + + + + + Phenomenological model according to which it nuclei are placed + into the domain and assumed growing. + + + + According to which model will the nuclei become distributed spatially. + CSR means complete spatial randomness. + Custom is implementation specific. + GB places nuclei at grain boundaries. + + + + + + + + + + According to which model will the nuclei start to grow. + + + + + + + + According to which model will the nuclei get their orientation assigned. + + + + + + + + Set of Bunge-Euler angles to sample orientations of nuclei randomly from. + + + + + + + + + + (Mechanical) properties of the material which scale the amount + of stored (elastic) energy in the ROI/system. + + + + Shear modulus at zero Kelvin. + + + + + Magnitude at the Burgers vector at zero Kelvin. + + + + + + Melting temperature in degrees Celsius. + + + + + + Model for the assumed mobility of grain boundaries with different + disorientation. + + + + Which type of fundamental model for the grain boundary mobility: + For the Sebald-Gottstein model the following equation is used. + For the Rollett-Holm model the following equation is used. + + + + + + + + + + + + + + + + + + + + + + + + + Simulated evolution of the dislocation density as the stored + (elastic) energy assumed stored in each grain. + + + + Which type of recovery model. + + + + + + + + + Simulated reduction of the grain boundary speed due to + the presence of dispersoids through which the total grain boundary + area of the recrystallization front can be reduced. + + + + Which type of drag model. + + + + + + + + + + + + Support point of the linearized curve of simulated time matching + a specific support point of the average dispersoid radius. + + + + + + + + Support point of the linearized curve of the average dispersoid radius. + + + + + + + + + + Simulated time temperature profile + + + + Support point of the linearized curve of simulated time matching + a specific support point of the temperature. + + + + + + + + Support point of the linearized curve of the temperature. + + + + + + + + + Criteria which enable to stop the simulation in a controlled manner. + Whichever criterion is fulfilled first stops the simulation. + + + + Maximum recrystallized volume fraction. + + + + + Maximum simulated physical time. + + + + + Maximum number of iteration steps. + + + + + + Settings relevant for stable numerical integration. + + + + Maximum fraction equivalent to the migration of the + fastest grain boundary in the system how much a cell + may be consumed in a single iteration. + + + + + Fraction of the total number of cells in the CA which + should initially be allocated for offering cells in the + recrystallization front. + + + + + By how much more times should the already allocated memory + be is increased to offer space for storing states of cells + in the recrystallization front. + + + + + Should the cache for cells in the recrystallization front + be defragmented on-the-fly. + + + + + Heuristic recrystallized volume target values at which + the cache for cells in the recrystallization front + will be defragmented on-the-fly. + + + + + + + + List of recrystallized volume target values at which a + snapshot of the CA state should be exported for. + + + + + + + + + + Perform a statistical analyses of the results as it was + proposed by M. Kühbach (solitary unit model ensemble approach). + + + + + How many independent cellular automaton domains + should be instantiated. + + + + + Into how many time steps should the real time interval be discretized upon + during post-processing the results with the solitary unit modeling approach. + + + + + List of identifier for those domain which should be rendered. + Identifier start from 0. + + + + + + + + + + + diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml new file mode 100644 index 0000000000..0e957612e5 --- /dev/null +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -0,0 +1,720 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of boundaries of the bounding box or primitive to domain. + + + + + Number of parameter required for chosen orientation parameterization. + + + + + Number of texture components identified. + + + + + Dimensionality. + + + + + Cardinality. + + + + + Number of active cells in the (recrystallization) front. + + + + + Number of grains in the computer simulation. + + + + + Application definition for storing results of the SCORE cellular automaton. + + The SCORE cellular automaton model for primary recrystallization is an + example of typical materials engineering applications used within the field + of so-called Integral Computational Materials Engineering (ICME) whereby + one can simulate the evolution of microstructures. + + Specifically the SCORE model can be used to simulate the growth of static + recrystallization nuclei. The model is described in the literature: + + * `M. Kühbach et al. <https://doi.org/10.1016/j.actamat.2016.01.068>`_ + * `C. Haase et al. <https://doi.org/10.1016/j.actamat.2015.08.057>`_ + * `M. Diehl et al. <https://doi.org/10.1088/1361-651X/ab51bd>`_ + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this computer simulation. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + + + + + Free-text description about the workflow (analysis/simulation). + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of this application definition rather than write details about the + experiment into this free-text description field. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the characterization started. + + + + + ISO 8601 time code with local time zone offset to UTC included + when the characterization ended. + + + + + + + + + + Specify if the (characterization) results/data of this instance of an + application definition are based on the results of a simulation or the + results of a post-processing of measured data to describe a microstructure. + The term microstructure is used to describe the spatial arrangement of + crystal defects inside a sample/specimen without demanding necessarily + that this structure is mainly at the micron length scale. + Nanostructure and macrostructure are close synonyms. + Material architecture is a narrow synonym. + + + + + + + + + + The path and name of the config file for this analysis. + + + + At least SHA256 strong hash of the specific config_file for + tracking provenance. + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the SCORE executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + Contact information and eventually details of at least one person + involved in creating this result. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services + like ORCID or ResearcherID. If this field is field the specific service + should also be written in orcid_platform + + + + + Name of the OrcID or ResearcherID where the account + under orcid is registered. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user in social media platforms. + + + + + Name of the social media platform where the account + under social_media_name is registered. + + + + + + + + Descriptive name or ideally (globally) unique persistent identifier. + + + + + + + Hard link to a location in the hierarchy of the NeXus file + where the data for default plotting are stored. + + + + + Container to hold different coordinate systems conventions. + A least a right-handed Cartesian coordinate system with base vectors + named x, y, and z has to be specified. Each base vector of the + coordinate system should be described with an NXtransformations instance. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The simulated or characterized material volume element aka domain. + At least one instance of geometry required either NXcg_grid, + NXcg_polyhedron_set, or NXcg_point_set. This geometry group needs + to contain details about the boundary conditions. + + + + + + + + + + + + + A tight bounding box or sphere or bounding primitive about the grid. + + + + + How many distinct boundaries are distinguished? + Most grids discretize a cubic or cuboidal region. In this case + six sides can be distinguished, each making an own boundary. + + + + + Name of the boundaries. E.g. left, right, front, back, bottom, top, + The field must have as many entries as there are number_of_boundaries. + + + + + The boundary conditions for each boundary: + + 0 - undefined + 1 - open + 2 - periodic + 3 - mirror + 4 - von Neumann + 5 - Dirichlet + + + + + + + + + Collection of microstructural data observed/simulated. + + + + Integer which specifies the first index to be used for distinguishing + snapshots. Identifiers are defined either implicitly or explicitly. + For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate + if the identifiers are expected to start from 1 (referred to as + Fortran-/Matlab-) or from 0 (referred to as C-, Python-style index + notation) respectively. + + + + + + Summary quantities which are the result of some post-processing of + the snapshot data (averaging, integrating, interpolating). + Frequently used descriptors from continuum mechanics and thermodynamics + can be used here. A few examples are given. Each descriptor is currently + modelled as an instance of an NXprocess because it is relevant to + understand how the descriptors are computed. + + + + Evolution of the physical time. + + + + + Evolution of the simulated temperature over time. + + + + + + Evolution of the recrystallized volume fraction over time. + + + + + + + + Measured or simulated physical time stamp for this snapshot. + Not to be confused with wall-clock timing or profiling data. + + + + + Simulated temperature. + + + + + Iteration or increment counter. + + + + + + + Grain identifier for each cell. + + + + + + + + + + Identifier of the OpenMP thread which processed this part of the grid. + + + + + + + + + + + + Details about those cells which in this time step represent + the discretized recrystallization front. + + + + Which cells are currently in a halo region of threads. + + + + + + + + So-called mobility weight which is a scaling factor to + control the mobility of the grain boundary which is assumed + to sweep currently this volume. + + + + + + + + Grid coordinates of each cell in the recrystallization front. + + + + + + + + + Grain identifier assigned to each cell in the recrystallization front. + + + + + + + + Grain identifier assigned to each nucleus which affected that cell in the + recrystallization front. + + + + + + + + Relative volume transformed as a measure of infection progress. + + + + + + + + Identifier of the OpenMP thread processing each cell in the recrystallization + front. + + + + + + + + Hint about the direction from which the cell was infected. + + + + + + + + + Current grain-related quantities. + + + + Bunge-Euler angle triplets for each grain. + + + + + + + + + Discrete volume of each grain accounting also for partially + transformed cells. + + + + + + + + Current value for the dislocation density as a measure of + the remaining stored energy in assumed crystal defects inside + each grain. The difference between these values scales the + driving force of grain boundary migration. + + + + + + + + Is the grain deformed. + + + + + + + + Is the grain recrystallized. + + + + + + + + + Current recrystallized volume fraction. + + + + Currently evaluated actual recrystallized volume fraction. + This takes into account partially recrystallized cells. + + + + + Currently desired target recrystallized volume fraction at + which the user requested to log a snapshot. + + + + + + + + Currently assumed globally applied Cauchy stress tensor on the ROI. + + + + + + + + + + + Currently assumed globally applied Cauchy strain tensor on the ROI. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/base_classes/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXms_snapshot.nxdl.xml similarity index 54% rename from base_classes/NXcg_sphere_set.nxdl.xml rename to contributed_definitions/NXms_snapshot.nxdl.xml index 8b12834749..1f922e281b 100644 --- a/base_classes/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXms_snapshot.nxdl.xml @@ -1,10 +1,10 @@ - + - - + The symbols used in the schema to specify e.g. dimensions of arrays. - - - The dimensionality, which has to be at least 2. - - - - - The cardinality of the set, i.e. the number of circles or spheres. - - - Computational geometry description of a set of spheres. - - Each sphere can have a different radius but all need to have finite volume. + Base class for data on the state of the microstructure at a given + time/iteration. - + + + Is this time for a measurement or a simulation. + + + + + + + - In the case that all spheres have the same radius. + Measured or simulated physical time stamp for this snapshot. + Not to be confused with wall-clock timing or profiling data. - + - In the case that spheres have different radius use this - instead of the radius field. + Iteration or increment counter. - - - diff --git a/contributed_definitions/NXms_snapshot_set.nxdl.xml b/contributed_definitions/NXms_snapshot_set.nxdl.xml new file mode 100644 index 0000000000..6cff36cc33 --- /dev/null +++ b/contributed_definitions/NXms_snapshot_set.nxdl.xml @@ -0,0 +1,62 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + A collection of spatiotemporal microstructure data. + + + + Is this set describing a measurement or a simulation? + + + + + + + + + Integer which specifies the first index to be used for distinguishing + snapshots. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + + diff --git a/contributed_definitions/NXopt.nxdl.xml b/contributed_definitions/NXopt.nxdl.xml new file mode 100644 index 0000000000..be636590ff --- /dev/null +++ b/contributed_definitions/NXopt.nxdl.xml @@ -0,0 +1,868 @@ + + + + + + + + + Variables used throughout the document, e.g. dimensions or parameters. + + + + Length of the spectrum array (e.g. wavelength or energy) of the measured + data. + + + + + Number of sensors used to measure parameters that influence the sample, + such as temperature or pressure. + + + + + Number of measurements (1st dimension of measured_data array). This is + equal to the number of parameters scanned. For example, if the experiment + was performed at three different temperatures and two different pressures + N_measurements = 2*3 = 6. + + + + + Number of detection angles of the beam reflected or scattered off the + sample. + + + + + Number of angles of incidence of the incident beam. + + + + + Number of observables that are saved in a measurement. e.g. one for + intensity, reflectivity or transmittance, two for Psi and Delta etc. This + is equal to the second dimension of the data array 'measured_data' and the + number of column names. + + + + + An application definition for optical spectroscopy experiments. + + + + An application definition template for optical spectroscopy experiments. + + A general optical experiment consists of a light or excitation source, a + beam path, a sample + its stage + its environment, and a detection unit. + Examples are reflection or transmission measurements, photoluminescence, + Raman spectroscopy, ellipsometry etc. + + + + An application definition describing a general optical experiment. + + + + Version number to identify which definition of this application + definition was used for this entry/data. + + + + + URL where to find further material (documentation, examples) relevant + to the application definition. + + + + + + + + + A (globally persistent) unique identifier of the experiment. + (i) The identifier is usually defined by the facility or principle + investigator. + (ii) The identifier enables to link experiments to e.g. proposals. + + + + + An optional free-text description of the experiment. + + However, details of the experiment should be defined in the specific + fields of this application definition rather than in this experiment + description. + + + + + Specify the type of the optical experiment. + + + + + Start time of the experiment. UTC offset should be specified. + + + + + Contact information of at least the user of the instrument or the + investigator who performed this experiment. + Adding multiple users, if relevant, is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the + experiment was performed. + + + + + Street address of the user's affiliation. + + + + + Email address of the user. + + + + + Author ID defined by https://orcid.org/. + + + + + Telephone number of the user. + + + + + + Properties of the experimental setup. This includes general information + about the instrument (such as model, company etc.), information about + the calibration of the instrument, elements of the beam path including + the excitation or light source and the detector unit, the sample stage + (plus the sample environment, which also includes sensors used to + monitor external conditions) and elements of the beam path. + + Meta data describing the sample should be specified in ENTRY/SAMPLE + outside of ENTRY/INSTRUMENT. + + + + The name of the instrument. + + + + The used version of the hardware if available. If not a commercial + instrument use date of completion of the hardware. + + + + + + Name of the company which build the instrument. + + + + + ISO8601 date when the instrument was constructed. + UTC offset should be specified. + + + + + + Commercial or otherwise defined given name of the program that was + used to measure the data, i.e. the software used to start and + record the measured data and/or metadata. + If home written, one can provide the actual steps in the NOTE + subfield here. + + + + + Either version with build number, commit hash, or description of a + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + + + + + Website of the software. + + + + + + Commercial or otherwise defined name of the firmware that was used + for the measurement - if available. + + + + Version and build number or commit hash of the software source code. + + + + + Website of the software. + + + + + + Was a calibration performed? If yes, when was it done? If the + calibration time is provided, it should be specified in + ENTRY/INSTRUMENT/calibration/calibration_time. + + + + + + + + + + + + The calibration data and metadata should be described in a separate NeXus file + with the link provided in 'calibration_link'. + + + + If calibtration status is 'calibration time provided', specify the + ISO8601 date when calibration was last performed before this + measurement. UTC offset should be specified. + + + + + Link to the NeXus file containing the calibration data and metadata. + + + + + + Describes an arrangement of optical or other elements, e.g. the beam + path between the light source and the sample, or between the sample + and the detector unit (including the sources and detectors + themselves). + + If a beam splitter (i.e. a device that splits the incoming beam into + two or more beams) is part of the beam path, two or more NXbeam_path + fields may be needed to fully describe the beam paths and the correct + sequence of the beam path elements. + Use as many beam paths as needed to describe the setup. + + + + + Angle(s) of the incident beam vs. the normal of the bottom reflective + (substrate) surface in the sample. + + + + + + + + + Detection angle(s) of the beam reflected or scattered off the sample + vs. the normal of the bottom reflective (substrate) surface in the + sample if not equal to the angle(s) of incidence. + + + + + + + + Sample stage, holding the sample at a specific position in X,Y,Z + (Cartesian) coordinate system and at an orientation defined + by three Euler angles (alpha, beta, gamma). + + + + Specify the type of the sample stage. + + + + + + + + + + + + If there is no motorized stage, we should at least qualify where + the beam hits the sample and in what direction the sample stands + in a free-text description, e.g. 'center of sample, long edge + parallel to the plane of incidence'. + + + + + Specify external parameters that have influenced the sample, such + as the surrounding medium, and varied parameters e.g. temperature, + pressure, pH value, optical excitation etc. + + + + Describe what was the medium above or around the sample. The + common model is built up from the substrate to the medium on the + other side. Both boundaries are assumed infinite in the model. + Here, define the name of the medium (e.g. water, air, UHV, etc.). + + + + + Array of pairs of complex refractive indices n + ik of the medium + for every measured spectral point/wavelength/energy. + Only necessary if the measurement was performed not in air, or + something very well known, e.g. high purity water. + + + + + + + + + A sensor used to monitor an external condition influencing the + sample, such as temperature or pressure. It is suggested to + replace 'PARAMETER' by the type of the varied parameter defined + in 'parameter_type'. + The measured parameter values should be provided in 'values'. + For each parameter, a 'PARAMETER(NXsensor)' field needs to exist. + In other words, there are N_sensors 'PARAMETER(NXsensor)' fields. + + + + Indicates which parameter was changed. Its definition must exist + below. The specified variable has to be N_measurements long, + providing the parameters for each data set. If you vary more than + one parameter simultaneously. + If the measured parameter is not contained in the list `other` + should be specified and the `parameter_type_name` should be provided. + + + + + + + + + + + + + + + + + + + + + + + + + If the parameter_type is `other` a name should be specified here. + + + + + Number of different parameter values at which the measurement + was performed. For example, if the measurement was performed at + temperatures of 4, 77 and 300 K, then number_of_parameters = 3. + + + + + Vector containing the values of the varied parameter. Its + length is equal to N_measurements. The order of the values + should be as follows: + + * Order the sensors according to number_of_parameters starting + with the lowest number. If number_of_parameters is equal for + two sensors order them alphabetically (sensor/parameter name). + * The first sensor's j parameters should be ordered in the + following way. The first N_measurements/number_of_parameters + entries of the vector contain the first parameter (a1), the + second N_measurements/number_of_parameters contain the second + parameter (a2) etc., so the vector looks like: + [ + a1,a1,...,a1, + a2,a2,...,a2, + ... + aj,aj,...aj + ] + * The kth sensor's m parameters should be ordered in the + following way: + [ + p1,...p1,p2,...,p2,...pm,...,pm, + p1,...p1,p2,...,p2,...pm,...,pm, + ... + p1,...p1,p2,...,p2,...pm,...,pm + ] + * The last sensor's n parameters should be ordered in the + following way: + [ + z1,z2,...,zn, + z1,z2,...,zn, + ... + z1,z2,...,zn] + + For example, if the experiment was performed at three different + temperatures (T1, T2, T3), two different pressures (p1, p2) and + two different angles of incidence (a1, a2), then + N_measurements = 12 and the order of the values for the various + parameter vectors is: + + * angle_of_incidence: [a1,a1,a1,a1,a1,a1,a2,a2,a2,a2,a2,a2] + * pressure: [p1,p1,p1,p2,p2,p2,p1,p1,p1,p2,p2,p2] + * temperature: [T1,T2,T3,T1,T2,T3,T1,T2,T3,T1,T2,T3] + + + + + + + + + + For environmental measurements, the environment (liquid, vapor + etc.) is enclosed in a cell, which has windows both in the + direction of the source (entry window) and the detector (exit + window) (looking from the sample). In case that the entry and exit + windows are not the same type and do not have the same properties, + use a second 'WINDOW(MXaperture)' field. + + The windows also add a phase shift to the light altering the + measured signal. This shift has to be corrected based on measuring + a known sample (reference sample) or the actual sample of interest + in the environmental cell. State if a window correction has been + performed in 'window_effects_corrected'. Reference data should be + considered as a separate experiment, and a link to the NeXus file + should be added in reference_data_link in measured_data. + + The window is considered to be a part of the sample stage but also + beam path. Hence, its position within the beam path should be + defined by the 'depends_on' field. + + + + Specify the position of the window in the beam path by pointing + to the preceding element in the sequence of beam path elements. + + + + + Was a window correction performed? If 'True' describe the window + correction procedure in 'window_correction/procedure'. + + + + + Was a window correction performed? If 'True' describe the + window correction procedure in '' + + + + Describe when (before or after the main measurement + time + stamp in 'date') and how the window effects have been + corrected, i.e. either mathematically or by performing a + reference measurement. In the latter case, provide the link to + to the reference data in 'reference_data_link'. + + + + + Link to the NeXus file which describes the reference data if a + reference measurement for window correction was performed. + Ideally, the reference measurement was performed on a reference + sample and on the same sample, and using the same conditions as + for the actual measurement with and without windows. It should + have been conducted as close in time to the actual measurement + as possible. + + + + + + The material of the window. + + + + + + + + + + + + + + + If you specified 'other' as material, decsribe here what it is. + + + + + Thickness of the window. + + + + + Angle of the window normal (outer) vs. the substrate normal + (similar to the angle of incidence). + + + + + + + + Properties of the sample, such as sample type, layer structure, + chemical formula, atom types, its history etc. + Information about the sample stage and sample environment should be + described in ENTRY/INSTRUMENT/sample_stage. + + + + Descriptive name of the sample + + + + + Specify the type of sample, e.g. thin film, single crystal etc. + + + + + + + + + + + + Qualitative description of the layer structure for the sample, + starting with the top layer (i.e. the one on the front surface, on + which the light incident), e.g. native oxide/bulk substrate, or + Si/native oxide/thermal oxide/polymer/peptide. + + + + + Chemical formula of the sample. Use the Hill system (explained here: + https://en.wikipedia.org/wiki/Chemical_formula#Hill_system) to write + the chemical formula. In case the sample consists of several layers, + this should be a list of the chemical formulas of the individual + layers, where the first entry is the chemical formula of the top + layer (the one on the front surface, on which the light incident). + The order must be consistent with layer_structure + + + + + List of comma-separated elements from the periodic table that are + contained in the sample. If the sample substance has multiple + components, all elements from each component must be included in + 'atom_types'. + + + + + Ideally, a reference to the location or a unique (globally + persistent) identifier (e.g.) of e.g. another file which gives + as many as possible details of the material, its microstructure, + and its thermo-chemo-mechanical processing/preparation history. + In the case that such a detailed history of the sample is not + available, use this field as a free-text description to specify + details of the sample and its preparation. + + + + + ISO8601 date with time zone (UTC offset) specified. + + + + + Description of the substrate. + + + + + Specify the sample orientation. + + + + + + Measured data, data errors, and varied parameters. If reference data + were measured they should be considered a separate experiment and a + link to its NeXus file should be added in reference_data_link. + + + + An identifier to correlate data to the experimental conditions, + if several were used in this measurement; typically an index of 0-N. + + + + + Select which type of data was recorded, for example intensity, + reflectivity, transmittance, Psi and Delta etc. + It is possible to have multiple selections. The enumeration list + depends on the type of experiment and may differ for different + application definitions. + + + + + + + + + + + + + + + + + Spectral values (e.g. wavelength or energy) used for the measurement. + An array of 1 or more elements. Length defines N_spectrum. Replace + 'SPECTRUM' by the physical quantity that is used, e.g. wavelength. + + + + + + + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. + + + + + + Resulting data from the measurement, described by 'data_type'. + + The first dimension is defined by the number of measurements taken, + (N_measurements). The instructions on how to order the values + contained in the parameter vectors given in the doc string of + INSTRUMENT/sample_stage/environment_conditions/PARAMETER/values, + define the N_measurements parameter sets. For example, if the + experiment was performed at three different temperatures + (T1, T2, T3), two different pressures (p1, p2) and two different + angles of incidence (a1, a2), the first measurement was taken at the + parameters {a1,p1,T1}, the second measurement at {a1,p1,T2} etc. + + + + + + + + + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. + + + + + + Specified uncertainties (errors) of the data described by 'data_type' + and provided in 'measured_data'. + + + + + + + + + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. + + + + + + List of links to the values of the sensors. Add a link for each + varied parameter (i.e. for each sensor). + + + + + + + + Link to the NeXus file which describes the reference data if a + reference measurement was performed. Ideally, the reference + measurement was performed using the same conditions as the actual + measurement and should be as close in time to the actual measurement + as possible. + + + + + + Commercial or otherwise defined given name of the program that was + used to generate the result file(s) with measured data and/or + metadata (in most cases, this is the same as INSTRUMENT/software). + If home written, one can provide the actual steps in the NOTE + subfield here. + + + + + Either version with build number, commit hash, or description of a + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + + + + + Website of the software. + + + + + + A plot of the multi-dimensional data array provided in + ENTRY/data/measured_data. + + + + Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) + + + + + + + Parameters that are derived from the measured data. + + + + Light loss due to depolarization as a value in [0-1]. + + + + + + + + + + Jones quality factor. + + + + + + + + + + Reflectivity. + + + + + + + + + + Transmittance. + + + + + + + + + + + Commercial or otherwise defined given name of the program that was + used to generate or calculate the derived parameters. + If home written, one can provide the actual steps in the NOTE + subfield here. + + + + + Either version with build number, commit hash, or description of a + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + + + + + + + A default view of the data provided in ENTRY/data_collection/measured_data. This + should be the part of the data set which provides the most suitable + representation of the data. + + + + Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) + + + + + diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/contributed_definitions/NXoptical_system_em.nxdl.xml new file mode 100644 index 0000000000..0f753001ed --- /dev/null +++ b/contributed_definitions/NXoptical_system_em.nxdl.xml @@ -0,0 +1,83 @@ + + + + + + A container for qualifying an electron optical system. + + + + + Citing the JEOL TEM glossary this is *an effective distance from a specimen + to a plane where an observed diffraction pattern is formed*. + + + + + The factor of enlargement of the apparent size, not physical size, of an object. + + + + + The defocus aberration constant oftentimes taken as the C_1_0 which + is described in more details in NXaberration. + + + + + Citing the JEOL TEM glosssary this is the value *when a cone shaped, + convergent electron beam illuminates a specimen, the semi-angle of the cone + is termed convergence angle.* + + + + + The extent of the observable parts of the specimen given the current + magnification and other settings of the instrument. + + + + + Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is + *a distance between the specimen and the lower pole piece in SEM system*. + + + + + Beam current as measured relevant for the illumination of the specimen. + Users should specify further details like how the beam current was measured + using the beam_current_description field. + + + + + Specify further details how the beam current was measured or estimated. + + + + diff --git a/contributed_definitions/NXorientation_set.nxdl.xml b/contributed_definitions/NXorientation_set.nxdl.xml new file mode 100644 index 0000000000..73f5e3ca0c --- /dev/null +++ b/contributed_definitions/NXorientation_set.nxdl.xml @@ -0,0 +1,133 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the reference space/coordinate system. + + + + + The cardinality of the set, i.e. the number of orientations. + + + + + Number of parameters for the chosen parameterization. + + + + + Details about individual orientations of a set of objects. + + For a more detailed insight into the discussion of parameterizing + orientations in materials science see: + + * https://doi.org/10.1016/j.matchar.2016.04.008 + * https://doi.org/10.1088/0965-0393/23/8/083501 + * https://doi.org/10.1007/978-3-662-09156-2 group-theory of rotations + * https://doi.org/10.1016/C2013-0-11769-2 the classical book of H.-J. Bunge + + + + + Reference to or definition of a coordinate system with + which the definitions are interpretable. + + + + + + + + + + + + A link or reference to the objects whose identifier are referred to in + identifier to resolve which row tuple is the orientation of each object + by reading orientations. + + + + + Integer which specifies which orientation (row of array orientation) matches + to which object.e first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + + + + Integer used to distinguish how a row in orientation describes a specific + object with an explicit identifier that can be queried via inspecting the + list of available objects in objects. + + The rational behind having such a more complicated pattern is that not + all objects referred when following the link in objects may still exists + or are still tracked when the orientation set was characterized. + + This design enables to also use NXorientation_set in situations where + the orientation of objects change as a function in time. + + + + + + + + Parameterized orientations. + + + + + + + + + diff --git a/contributed_definitions/NXpeak.nxdl.xml b/contributed_definitions/NXpeak.nxdl.xml new file mode 100644 index 0000000000..4a030c6844 --- /dev/null +++ b/contributed_definitions/NXpeak.nxdl.xml @@ -0,0 +1,87 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of support points + + + + + Description of peaks, their functional form or measured support. + + + + Human-readable identifier to specify which concept/entity + the peak represents/identifies. + + + + + Is the peak described analytically via a functional form + or is it empirically defined via measured/reported + intensity/counts as a function of an independent variable. + + If the functional form is not empirical or gaussian, users + should enter other for the peak_model and add relevant details + in the NXcollection. + + + + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the position values for the independent variable. + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the intensity/count values at each position. + + + + + + + + In the case of an analytical description (or if peak_model is other) this + collection holds parameter of (and eventually) the functional form. + For example in the case of Gaussians mu, sigma, cut-off values, + and background intensity are relevant parameter. + + + diff --git a/base_classes/NXpid.nxdl.xml b/contributed_definitions/NXpid.nxdl.xml similarity index 70% rename from base_classes/NXpid.nxdl.xml rename to contributed_definitions/NXpid.nxdl.xml index 4941cac937..62fad3f835 100644 --- a/base_classes/NXpid.nxdl.xml +++ b/contributed_definitions/NXpid.nxdl.xml @@ -1,10 +1,10 @@ - + - + Contains the settings of a PID controller. @@ -53,18 +53,12 @@ It can also be a link to an NXsensor.value field. - - - Time log of the setpoint(s) used as an input for the PID controller. - - Proportional term. The proportional term produces an output value that is proportional to the current error value. The proportional response can be adjusted by multiplying the error by a constant Kp, called the proportional gain constant. - The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows I = P/T. @@ -87,25 +81,4 @@ action is termed the derivative gain, K_d - - - The Type switches controller parameters between P/I (proportional gain/integral - gain) and P/T (proportional gain/time constant). The formula for the controller - in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and - time constant are related as follows I = P/T. - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - diff --git a/base_classes/NXprogram.nxdl.xml b/contributed_definitions/NXprogram.nxdl.xml similarity index 100% rename from base_classes/NXprogram.nxdl.xml rename to contributed_definitions/NXprogram.nxdl.xml diff --git a/contributed_definitions/NXpulser_apm.nxdl.xml b/contributed_definitions/NXpulser_apm.nxdl.xml new file mode 100644 index 0000000000..a57b1af0d5 --- /dev/null +++ b/contributed_definitions/NXpulser_apm.nxdl.xml @@ -0,0 +1,166 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Total number of ions collected. + + + + + Metadata for laser- and/or voltage-pulsing in atom probe microscopy. + + + + + How is field evaporation physically triggered. + + + + + + + + + + Frequency with which the high voltage or laser pulser fires. + + + + + + + + + Fraction of the pulse_voltage that is applied in addition + to the standing_voltage at peak voltage of a pulse. + + If a standing voltage is applied, this gives nominal pulse fraction + (as a function of standing voltage). Otherwise this field should not be + present. + + + + + + + + In laser pulsing mode the values will be zero so the this field is recommended. + However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. + + + + + + + + Absolute number of pulses starting from the beginning of the experiment. + + + + + + + + Direct current voltage between the specimen and the (local electrode) in + the case of local electrode atom probe (LEAP) instrument. + The standing voltage applied to the sample, relative to system ground. + + + + + + + + Atom probe microscopes use controlled laser, voltage, + or a combination of pulsing strategies to trigger the + excitation and eventual field evaporation/emission of + an ion during an experiment. + + + + Given name/alias. + + + + + + Nominal wavelength of the laser radiation. + + + + + Nominal power of the laser source while illuminating the specimen. + + + + + + Average energy of the laser at peak of each pulse. + + + + + Details about specific positions along the focused laser beam + which illuminates the (atom probe) specimen. + + + + Track time-dependent settings over the course of the + measurement how the laser beam in tip space/reconstruction space + laser impinges on the sample, i.e. the mean vector is parallel to + the laser propagation direction. + + + + + Track time-dependent settings over the course of the + measurement where the laser beam exits the + focusing optics. + + + + + Track time-dependent settings over the course of the + measurement where the laser hits the specimen. + + + + + + Affine transformations which describe the geometry how the + laser focusing optics/pinhole-attached coordinate system is + defined, how it has to be transformed so that it aligns with + the specimen coordinate system. + A right-handed Cartesian coordinate system, the so-called laser space, + should be assumed, whose positive z-axis points + into the direction of the propagating laser beam. + + + + diff --git a/base_classes/NXpump.nxdl.xml b/contributed_definitions/NXpump.nxdl.xml similarity index 88% rename from base_classes/NXpump.nxdl.xml rename to contributed_definitions/NXpump.nxdl.xml index 45a86edada..9f38b2d7b7 100644 --- a/base_classes/NXpump.nxdl.xml +++ b/contributed_definitions/NXpump.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Device to reduce an atmosphere (real or simulated) to a controlled pressure. + Device to reduce an atmosphere to a controlled remaining pressure level. - + Principle type of the pump. diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml new file mode 100644 index 0000000000..e2220a1bed --- /dev/null +++ b/contributed_definitions/NXreflectron.nxdl.xml @@ -0,0 +1,56 @@ + + + + + + Device for reducing flight time differences of ions in ToF experiments. + For atom probe the reflectron can be considered an energy_compensation + device, which can e.g. be realized technically as via a Poschenrieder lens + (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). + + + + Given name/alias. + + + + + + Free-text field to specify further details about the reflectron. + The field can be used to inform e. g. if the reflectron is flat or curved. + + + + + + Affine transformation(s) which detail where the reflectron + is located relative to e.g. the origin of the specimen space + reference coordinate system. + This group can also be used for specifying how the reflectron + is rotated relative to the specimen axis. + The purpose of these more detailed instrument descriptions + is to support the creation of a digital twin of the instrument + for computational science. + + + diff --git a/base_classes/NXregistration.nxdl.xml b/contributed_definitions/NXregistration.nxdl.xml similarity index 100% rename from base_classes/NXregistration.nxdl.xml rename to contributed_definitions/NXregistration.nxdl.xml diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/contributed_definitions/NXscanbox_em.nxdl.xml new file mode 100644 index 0000000000..c95f62357d --- /dev/null +++ b/contributed_definitions/NXscanbox_em.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + Scan box and coils which deflect an electron beam in a controlled manner. + + In electron microscopy, the scan box is instructed by the microscope + control software. This component directs the probe to controlled + locations according to a scan scheme and plan. + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXslip_system_set.nxdl.xml b/contributed_definitions/NXslip_system_set.nxdl.xml new file mode 100644 index 0000000000..8fafee2e41 --- /dev/null +++ b/contributed_definitions/NXslip_system_set.nxdl.xml @@ -0,0 +1,85 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of slip systems. + + + + + Base class for describing a set of crystallographic slip systems. + + + + + + + + + + + + + + + + + + Array of Miller indices which describe the crystallographic plane. + + + + + + + + + + Array of Miller indices which describe the crystallographic direction. + + + + + + + + + For each slip system a marker whether the specified Miller indices + refer to the specific slip system or the set of crystallographic equivalent + slip systems of the respective family of slip systems. + + + + + + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml new file mode 100644 index 0000000000..9ca3aab349 --- /dev/null +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -0,0 +1,162 @@ + + + + + + + + + Number of pixel in the slow direction. + + + + + Number of pixel in the fast direction. + + + + + Number of energy bins. + + + + + Container for reporting a set of spectra. + + + + Details how spectra were processed from the detector readings. + + + + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXspectrum_set were loaded during parsing. + + + + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + + + + + + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXspectrum_set instance. + + + + + Link or name of an NXdetector instance with which the data were collected. + + + + + + + + Collected spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + + + Counts + + + + + + + + + + + Coordinate along y direction + + + + + + + + + + Coordinate along x direction + + + + + + + + + + Energy + + + + + + + + Accumulated counts over all pixels of the region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + Counts + + + + + + + + + + + Energy + + + + + diff --git a/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml b/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml new file mode 100644 index 0000000000..4e58d9202a --- /dev/null +++ b/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml @@ -0,0 +1,188 @@ + + + + + + + + + Number of pixel per EELS mapping in the slow direction. + + + + + Number of pixel per EELS mapping in the fast direction. + + + + + Number of electron energy loss bins. + + + + + Container for reporting a set of electron energy loss (EELS) spectra. + + Virtually the most important case is that spectra are collected in + a scanning microscope (SEM or STEM) for a collection of points. + The majority of cases use simple d-dimensional regular scan pattern, + such as single point, line profiles, or (rectangular) surface mappings. + + The latter pattern is the most frequently used. + For now the base class provides for scans for which the settings, + binning, and energy resolution is the same for each scan point. + + + + Details how EELS spectra were processed from the detector readings. + + + + Typically the name of the input, (vendor) file from which all + the NXdata instances in this NXspectrum_set_em_eels were loaded during + parsing to represent them in e.g. databases. + + + + An at least as strong as SHA256 hashvalue of the dataset/file + which represents the source digitally to support provenance tracking. + + + + + + Commercial or otherwise given name to the program which was used + to process detector data into the EELS spectra stack and summary. + + + + Program version plus build number, commit hash, or description + of an ever persistent resource where the source code of the program + and build instructions can be found so that the program + can be configured in such a manner that the result file + is ideally recreatable yielding the same results. + + + + + + + Collected EELS spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + Counts for one spectrum per each pixel. + + + + + + + + + EELS counts + + + + + + + Pixel center of mass position y-coordinates. + + + + + + + Coordinate along y direction. + + + + + + Pixel center of mass position x-coordinates. + + + + + + + Coordinate along x direction. + + + + + + Pixel center of mass energy loss bins. + + + + + + + Coordinate along energy loss axis. + + + + + + + Accumulated EELS spectrum over all pixels of a rectangular + region-of-interest. This representation supports rectangular scan pattern. + + + + Counts for specific energy losses. + + + + + + + Counts electrons with an energy loss within binned range. + + + + + + + Pixel center of mass energy loss bins. + + + + + + + Coordinate along energy loss axis. + + + + + diff --git a/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml b/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml new file mode 100644 index 0000000000..53916bbfe9 --- /dev/null +++ b/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml @@ -0,0 +1,311 @@ + + + + + + + + + + Number of pixel per X-ray mapping in the slow direction + + + + + Number of pixel per X-ray mapping in the fast direction + + + + + Number of X-ray photon energy (bins) + + + + + Number of identified elements + + + + + Number of peaks + + + + + Container for reporting a set of energy-dispersive X-ray spectra. + + Virtually the most important case is that spectra are collected in + a scanning microscope (SEM or STEM) for a collection of points. + The majority of cases use simple d-dimensional regular scan pattern, + such as single point, line profiles, or (rectangular) surface mappings. + The latter pattern is the most frequently used. + + For now the base class provides for scans for which the settings, + binning, and energy resolution is the same for each scan point. + + `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ + should be used. + + + + Details how X-ray spectra were processed from the detector readings. + + + + Typically the name of the input, (vendor) file from which all + the NXdata instances in this NXspectrum_set_em_xray were loaded during + parsing to represent them in e.g. databases. + + + + An at least as strong as SHA256 hashvalue of the dataset/file + which represents the source digitally to support provenance tracking. + + + + + + Commercial or otherwise given name to the program which was used + to process detector data into the X-ray spectra stack and summary. + + + + Program version plus build number, commit hash, or description + of an ever persistent resource where the source code of the program + and build instructions can be found so that the program + can be configured in such a manner that the result file + is ideally recreatable yielding the same results. + + + + + + + + Collected X-ray spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + + + + + + + + + + X-ray photon counts + + + + + + + + + + + Coordinate along y direction. + + + + + + + + + + Coordinate along x direction. + + + + + + + + + + Photon energy. + + + + + + + Accumulated X-ray spectrum over all pixels of a rectangular + region-of-interest. This representation supports rectangular scan pattern. + + + + + + + + X-ray photon counts + + + + + + + + + + + Photon energy + + + + + + + + Details about computational steps how peaks were indexed as elements. + + + + Given name of the program that was used to perform this computation. + + + + Program version plus build number, commit hash, or description of an + ever persistent resource where the source code of the program and + build instructions can be found so that the program can be configured + in such a manner that the result file is ideally recreatable yielding + the same results. + + + + + + Name and location of each X-ray line which was indexed as a known ion. + For each ion an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + + + + + IUPAC notation identifier of the line which the peak represents. + + This can be a list of IUPAC notations for (the seldom) case that + multiple lines are group with the same peak. + + + + + + + List of the names of identified elements. + + + + + + + + Individual element-specific EDX/EDS/EDXS/SXES mapping + + A composition map is an image whose intensities for each pixel are the + accumulated X-ray quanta *under the curve(s)* of a set of peaks. + + + + Given name of the program that was used to perform this computation. + + + + Program version plus build number, commit hash, or description of an + ever persistent resource where the source code of the program and + build instructions can be found so that the program can be configured + in such a manner that the result file is ideally recreatable yielding + the same results. + + + + + + A list of strings of named instances of NXpeak from indexing + whose X-ray quanta where accumulated for each pixel. + + + + + + + + Human-readable, given name to the image. + + + + + + Individual element-specific maps. Individual maps should + each be a group and be named according to element_names. + + + + + + + + + Accumulated photon counts for observed element. + + + + + + + + + + + Coordinate along y direction. + + + + + + + + + + Coordinate along x direction. + + + + + + + diff --git a/base_classes/NXspindispersion.nxdl.xml b/contributed_definitions/NXspindispersion.nxdl.xml similarity index 100% rename from base_classes/NXspindispersion.nxdl.xml rename to contributed_definitions/NXspindispersion.nxdl.xml diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml new file mode 100644 index 0000000000..7b916d2728 --- /dev/null +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -0,0 +1,173 @@ + + + + + + A stage lab can be used to hold, align, orient, and prepare a specimen. + + Modern stages are multi-functional devices. Many of which offer a controlled + environment around (a part) of the specimen. Stages enable experimentalists + to apply stimuli. A stage_lab is a multi-purpose/-functional tools which + can have multiple actuators, sensors, and other components. + + With such stages comes the need for storing various (meta)data + that are generated while manipulating the sample. + + Modern stages realize a hierarchy of components: For example the specimen + might be mounted on a multi-axial tilt rotation holder. This holder is + fixed in the support unit which connects the holder to the rest of the + microscope. + + In other examples, taken from atom probe microscopy, researchers may work + with wire samples which are clipped into a larger fixing unit for + convenience and enable for a more careful specimen handling. + This fixture unit is known in atom probe jargon as a stub. + Stubs in turn are positioned onto pucks. + Pucks are then loaded onto carousels. + A carousel is a carrier unit with which eventually entire sets of specimens + can be moved in between parts of the microscope. + + An NXstage_lab instance reflects this hierarchical design. The stage is the + root of the hierarchy. A stage carries the holder. + In the case that it is not practical to distinguish these two layers, + the holder should be given preference. + + Some examples for stage_labs in applications: + + * A nanoparticle on a copper grid. The copper grid is the holder. + The grid itself is fixed to the stage. + * An atom probe specimen fixed in a stub. In this case the stub can be + considered the holder, while the cryostat temperature control unit is + a component of the stage. + * Samples with arrays of specimens, like a microtip on a microtip array + is an example of a three-layer hierarchy commonly employed for + efficient sequential processing of atom probe experiments. + * With one entry of an application definition only one microtip should be + described. Therefore, the microtip is the specimen, + the array is the holder and the remaining mounting unit + that is attached to the cryo-controller is the stage. + * For in-situ experiments with e.g. chips with read-out electronics + as actuators, the chips are again placed in a larger unit. + * Other examples are (quasi) in-situ experiments where experimentalists + anneal or deform the specimen via e.g. in-situ tensile testing machines + which are mounted on the specimen holder. + + To cover for an as flexible design of complex stages, users should nest + multiple instances of NXstage_lab objects according to their needs to reflect + the differences between what they consider as the holder and what + they consider is the stage. + + Instances should be named with integers starting from 1 as the top level unit. + In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder + (microtip array), stage_lab_3 for the microtip specimen, respectively. + The depends_on keyword should be used with relative or absolute naming inside + the file to specify how different stage_lab instances build a hierarchy + if this is not obvious from numbered identifiers like the stage_lab_1 to + stage_lab 3 example. The lower it is the number the higher it is the + rank in the hierarchy. + + For specific details and inspiration about stages in electron microscopes: + + * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ + * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ + * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ + * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) + * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) + * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) + * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ + + + + Principal design of the stage. + + Exemplar terms could be side_entry, top_entry, + single_tilt, quick_change, multiple_specimen, + bulk_specimen, double_tilt, tilt_rotate, + heating_chip, atmosphere_chip, + electrical_biasing_chip, liquid_cell_chip + + + + + Given name/alias for the components making the stage. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + + + + Voltage applied to the stage to decelerate electrons. + + + + + + The rotation, tilt and position of stage components can be specified + either via NXtransformations or via the tilt_1, tilt_2, rotation, + and position fields. + + + + + diff --git a/base_classes/NXwaveplate.nxdl.xml b/contributed_definitions/NXwaveplate.nxdl.xml similarity index 95% rename from base_classes/NXwaveplate.nxdl.xml rename to contributed_definitions/NXwaveplate.nxdl.xml index 02178ac9fa..52abcb0baa 100644 --- a/base_classes/NXwaveplate.nxdl.xml +++ b/contributed_definitions/NXwaveplate.nxdl.xml @@ -1,4 +1,4 @@ - + - - + + @@ -84,11 +83,6 @@ A draft of a new base class to describe a waveplate--> - - - Wavelength resolved retardence of the waveplate. - - Diameter of the waveplate. diff --git a/dev_tools/docs/anchor_list.py b/dev_tools/docs/anchor_list.py index 1b411041df..df668ead01 100644 --- a/dev_tools/docs/anchor_list.py +++ b/dev_tools/docs/anchor_list.py @@ -114,10 +114,6 @@ def write(self): return contents = dict( _metadata=dict( - # datetime=datetime.datetime.now(datetime.UTC).isoformat(), - # the next line is the py3.9 supported way of getting the datetime - # this will become deprecated however in py3.12 for which the - # line above-mentioned is a fix, which however does not work in py3.9 datetime=datetime.datetime.utcnow().isoformat(), title="NeXus NXDL vocabulary.", subtitle="Anchors for all NeXus fields, groups, " diff --git a/dev_tools/docs/nxdl.py b/dev_tools/docs/nxdl.py old mode 100755 new mode 100644 index ed3db94cca..157acce335 --- a/dev_tools/docs/nxdl.py +++ b/dev_tools/docs/nxdl.py @@ -303,34 +303,12 @@ def _get_doc_blocks(ns, node): out_blocks.append("\n".join(out_lines)) return out_blocks - def _handle_multiline_docstring(self, blocks): - links = [] - docstring = "" - expanded_blocks = [] - for block in blocks: - expanded_blocks += block.split("\n") - - for block in expanded_blocks: - if not block: - continue - - link_match = re.search(r"\.\. _([^:]+):(.*)", block) - if link_match is not None: - links.append((link_match.group(1), link_match.group(2).strip())) - else: - docstring += " " + re.sub(r"\n", " ", block.strip()) - - for name, target in links: - docstring = docstring.replace(f"`{name}`_", f"`{name} <{target}>`_") - - return docstring - def _get_doc_line(self, ns, node): blocks = self._get_doc_blocks(ns, node) if len(blocks) == 0: return "" if len(blocks) > 1: - return self._handle_multiline_docstring(blocks) + raise Exception(f"Unexpected multi-paragraph doc [{'|'.join(blocks)}]") return re.sub(r"\n", " ", blocks[0]) def _get_minOccurs(self, node): diff --git a/dev_tools/docs/nxdl_index.py b/dev_tools/docs/nxdl_index.py index 9f0fc779f9..bcb8ac666b 100644 --- a/dev_tools/docs/nxdl_index.py +++ b/dev_tools/docs/nxdl_index.py @@ -66,22 +66,13 @@ def nxdl_indices() -> Dict[str, dict]: else: file = "" print("---------++++++++-", section) - if file.endswith(("applications/index.rst", "base_classes/index.rst")): - rst_lines.append(f"{indentation}em-structure\n") - rst_lines.append(f"{indentation}optical-spectroscopy-structure\n") - rst_lines.append(f"{indentation}mpes-structure\n") - rst_lines.append(f"{indentation}apm-structure\n") - if file.endswith("contributed_definitions/index.rst"): rst_lines.append(f"{indentation}em-structure\n") - rst_lines.append(f"{indentation}optical-spectroscopy-structure\n") + rst_lines.append(f"{indentation}ellipsometry-structure\n") rst_lines.append(f"{indentation}mpes-structure\n") rst_lines.append(f"{indentation}apm-structure\n") rst_lines.append(f"{indentation}transport-structure\n") - rst_lines.append(f"{indentation}sts-structure\n") rst_lines.append(f"{indentation}cgms-structure\n") - rst_lines.append(f"{indentation}icme-structure\n") - rst_lines.append(f"{indentation}sample-prep-structure\n") for cname in sorted(classes): rst_lines.append(f"{indentation}{cname}\n") @@ -119,18 +110,6 @@ def get_nxclass_description(nxdl_file: Path, namespaces) -> str: *might* be used in an instance of that class. Consider the base classes as a set of *components* that are used to construct a data file. - -Some contributions are grouped together: - :ref:`Optical Spectroscopy ` - - :ref:`Multi-dimensional Photoemission Spectroscopy ` - - :ref:`Atomprobe Microscopy ` - - :ref:`Electron Microscopy ` - -and others are simply listed here: - """, # - - - - - - - - - - - - - - - - - - - - - - - - - - - - "applications": """ @@ -159,19 +138,6 @@ def get_nxclass_description(nxdl_file: Path, namespaces) -> str: In application definitions involving raw data, write the raw data in the :ref:`NXinstrument` tree and then link to it from the location(s) defined in the relevant application definition. - -Some contributions are grouped together: - :ref:`Optical Spectroscopy ` - - :ref:`Multi-dimensional Photoemission Spectroscopy ` - - :ref:`Atomprobe Microscopy ` - - :ref:`Electron Microscopy ` - - -and others are simply listed here: - """, # - - - - - - - - - - - - - - - - - - - - - - - - - - - - "contributed_definitions": """ @@ -194,11 +160,11 @@ def get_nxclass_description(nxdl_file: Path, namespaces) -> str: and acceptance as either a base class or application definition. Some contributions are grouped together: - :ref:`Optical Spectroscopy ` + :ref:`Optical Spectroscopy ` :ref:`Multi-dimensional Photoemission Spectroscopy ` - :ref:`Atomprobe Microscopy ` + :ref:`Atom Probe Microscopy ` :ref:`Electron Microscopy ` diff --git a/dev_tools/tests/test_nxdl_utils.py b/dev_tools/tests/test_nxdl_utils.py index ba6b14f252..7b10494bf3 100644 --- a/dev_tools/tests/test_nxdl_utils.py +++ b/dev_tools/tests/test_nxdl_utils.py @@ -5,7 +5,6 @@ import os import lxml.etree as ET -import pytest from ..utils import nxdl_utils as nexus @@ -49,175 +48,11 @@ def test_get_node_at_nxdl_path(): ) assert node.attrib["name"] == "long_name" - nxdl_file_path = os.path.join(local_dir, "../../applications/NXem.nxdl.xml") - elem = ET.parse(nxdl_file_path).getroot() - node = nexus.get_node_at_nxdl_path( - "/ENTRY/measurement/EVENT_DATA_EM_SET/EVENT_DATA_EM/end_time", elem=elem - ) - assert node.attrib["name"] == "end_time" - - node = nexus.get_node_at_nxdl_path("/ENTRY/measurement", elem=elem) - assert node.attrib["type"] == "NXem_msr" - - node = nexus.get_node_at_nxdl_path( - "/ENTRY/measurement/EVENT_DATA_EM_SET/EVENT_DATA_EM/IMAGE_SET/image_3d", - elem=elem, - ) - assert node.attrib["type"] == "NXdata" - - node = nexus.get_node_at_nxdl_path( - "/ENTRY/measurement/EVENT_DATA_EM_SET/EVENT_DATA_EM/IMAGE_SET/image_3d/AXISNAME_indices", - elem=elem, - ) - assert node.attrib["name"] == "AXISNAME_indices" - - node = nexus.get_node_at_nxdl_path( - "/ENTRY/measurement/EVENT_DATA_EM_SET/EVENT_DATA_EM/IMAGE_SET/image_3d/axis_j", - elem=elem, - ) - assert node.attrib["type"] == "NX_NUMBER" - - node = nexus.get_node_at_nxdl_path("/ENTRY/coordinate_system_set", elem=elem) - assert node.attrib["type"] == "NXcoordinate_system_set" - - nxdl_file_path = os.path.join( - local_dir, "../../contributed_definitions/NXiv_temp.nxdl.xml" - ) - elem = ET.parse(nxdl_file_path).getroot() - node = nexus.get_node_at_nxdl_path( - "/ENTRY/INSTRUMENT/ENVIRONMENT/voltage_controller", elem=elem - ) - assert node.attrib["name"] == "voltage_controller" - - node = nexus.get_node_at_nxdl_path( - "/ENTRY/INSTRUMENT/ENVIRONMENT/voltage_controller/calibration_time", elem=elem - ) - assert node.attrib["name"] == "calibration_time" - def test_get_inherited_nodes(): """Test to verify if we receive the right XML element list for a given NXDL path.""" local_dir = os.path.abspath(os.path.dirname(__file__)) - nxdl_file_path = os.path.join(local_dir, "./NXtest.nxdl.xml") elem = ET.parse(nxdl_file_path).getroot() (_, _, elist) = nexus.get_inherited_nodes(nxdl_path="/ENTRY/NXODD_name", elem=elem) assert len(elist) == 3 - - nxdl_file_path = os.path.join( - local_dir, "../../contributed_definitions/NXiv_temp.nxdl.xml" - ) - - elem = ET.parse(nxdl_file_path).getroot() - (_, _, elist) = nexus.get_inherited_nodes( - nxdl_path="/ENTRY/INSTRUMENT/ENVIRONMENT", elem=elem - ) - assert len(elist) == 3 - - (_, _, elist) = nexus.get_inherited_nodes( - nxdl_path="/ENTRY/INSTRUMENT/ENVIRONMENT/voltage_controller", elem=elem - ) - assert len(elist) == 4 - - (_, _, elist) = nexus.get_inherited_nodes( - nxdl_path="/ENTRY/INSTRUMENT/ENVIRONMENT/voltage_controller", - nx_name="NXiv_temp", - ) - assert len(elist) == 4 - - -@pytest.mark.parametrize( - "hdf_name,concept_name,should_fit", - [ - ("source_pump", "sourceType", False), - ("source_pump", "sourceTYPE", True), - ("source pump", "sourceTYPE", False), - ("source", "sourceTYPE", False), - ("source123", "SOURCE", True), - ("1source", "SOURCE", True), - ("_source", "SOURCE", True), - ("same_name", "same_name", True), - ("angular_energy_resolution", "angularNresolution", True), - ("angularresolution", "angularNresolution", False), - ("Name with some whitespaces in it", "ENTRY", False), - ("simple_name", "TEST", True), - (".test", "TEST", False), - ], -) -def test_namefitting(hdf_name, concept_name, should_fit): - """Test namefitting of nexus concept names""" - if should_fit: - assert nexus.get_nx_namefit(hdf_name, concept_name) > -1 - else: - assert nexus.get_nx_namefit(hdf_name, concept_name) == -1 - - -@pytest.mark.parametrize( - "hdf_name,concept_name, score", - [ - ("test_name", "TEST_name", 9), - ("te_name", "TEST_name", 7), - ("my_other_name", "TEST_name", 5), - ("test_name", "test_name", 18), - ("test_other", "test_name", -1), - ("my_fancy_yet_long_name", "my_SOME_name", 8), - ("something", "XXXX", 0), - ("something", "OTHER", 1), - ], -) -def test_namefitting_scores(hdf_name, concept_name, score): - """Test namefitting of nexus concept names""" - assert nexus.get_nx_namefit(hdf_name, concept_name) == score - - -@pytest.mark.parametrize( - "better_fit,better_ref,worse_fit,worse_ref", - [ - ("sourcetype", "sourceTYPE", "source_pump", "sourceTYPE"), - ("source_pump", "sourceTYPE", "source_pump", "TEST"), - ], -) -def test_namefitting_precedence(better_fit, better_ref, worse_fit, worse_ref): - """Test if namefitting follows proper precedence rules""" - - assert nexus.get_nx_namefit(better_fit, better_ref) > nexus.get_nx_namefit( - worse_fit, worse_ref - ) - - -@pytest.mark.parametrize( - "string_obj, decode, expected", - [ - # Test with lists of bytes and strings - ([b"bytes", "string"], True, ["bytes", "string"]), - ([b"bytes", "string"], False, [b"bytes", "string"]), - ([b"bytes", b"more_bytes", "string"], True, ["bytes", "more_bytes", "string"]), - ( - [b"bytes", b"more_bytes", "string"], - False, - [b"bytes", b"more_bytes", "string"], - ), - ([b"fixed", b"length", b"strings"], True, ["fixed", "length", "strings"]), - ([b"fixed", b"length", b"strings"], False, [b"fixed", b"length", b"strings"]), - # Test with nested lists - ([[b"nested1"], [b"nested2"]], True, [["nested1"], ["nested2"]]), - ([[b"nested1"], [b"nested2"]], False, [[b"nested1"], [b"nested2"]]), - # Test with bytes - (b"single", True, "single"), - (b"single", False, b"single"), - # Test with str - ("single", True, "single"), - ("single", False, "single"), - # Test with int - (123, True, 123), - (123, False, 123), - ], -) -def test_decode_or_not(string_obj, decode, expected): - # Handle normal cases - result = nexus.decode_or_not(elem=string_obj, decode=decode) - if isinstance(expected, list): - assert isinstance(result, list), f"Expected list, but got {type(result)}" - # Handle all other cases - else: - assert result == expected, f"Failed for {string_obj} with decode={decode}" diff --git a/dev_tools/utils/nxdl_utils.py b/dev_tools/utils/nxdl_utils.py index 3abf139c38..ebb7ce62a3 100644 --- a/dev_tools/utils/nxdl_utils.py +++ b/dev_tools/utils/nxdl_utils.py @@ -1,56 +1,17 @@ # pylint: disable=too-many-lines -"""Parse NeXus definition files""" +"""Parse NeXus definition files +""" import os -import re import textwrap from functools import lru_cache from glob import glob from pathlib import Path -from typing import List -from typing import Optional import lxml.etree as ET from lxml.etree import ParseError as xmlER -def decode_or_not(elem, encoding: str = "utf-8", decode: bool = True): - """ - Decodes a byte array to a string if necessary. All other types are returned untouched. - If `decode` is False, the initial value is returned without decoding, including for byte arrays. - - Args: - elem: Any Python object that may need decoding. - encoding: The encoding scheme to use. Default is "utf-8". - decode: A boolean flag indicating whether to perform decoding. - - Returns: - A decoded string (in case of a byte string) or the initial value. - If `decode` is False, always returns the initial value. - - Raises: - ValueError: If a byte string cannot be decoded using the provided encoding. - """ - if not decode: - return elem - - # Handle lists of bytes or strings - elif isinstance(elem, list): - if not elem: - return elem # Return an empty list unchanged - - decoded_list = [decode_or_not(x, encoding, decode) for x in elem] - return decoded_list - - if isinstance(elem, bytes): - try: - return elem.decode(encoding) - except UnicodeDecodeError as e: - raise ValueError(f"Error decoding bytes: {e}") - - return elem - - def remove_namespace_from_tag(tag): """Helper function to remove the namespace from an XML tag.""" @@ -84,8 +45,8 @@ def get_app_defs_names(): Path(nexus_def_path) / "contributed_definitions" / "*.nxdl.xml" ) - files = sorted(glob(str(app_def_path_glob))) - for nexus_file in sorted(glob(str(contrib_def_path_glob))): + files = sorted(glob(app_def_path_glob)) + for nexus_file in sorted(contrib_def_path_glob): root = get_xml_root(nexus_file) if root.attrib["category"] == "application": files.append(nexus_file) @@ -131,13 +92,7 @@ def get_hdf_info_parent(hdf_info): """Get the hdf_info for the parent of an hdf_node in an hdf_info""" if "hdf_path" not in hdf_info: return {"hdf_node": hdf_info["hdf_node"].parent} - node = ( - get_hdf_root(hdf_info["hdf_node"]) - if "hdf_root" not in hdf_info - else hdf_info["hdf_root"] - ) - for child_name in hdf_info["hdf_path"].split("/")[1:-1]: - node = node[child_name] + node = get_hdf_parent(hdf_info) return {"hdf_node": node, "hdf_path": get_parent_path(hdf_info["hdf_path"])} @@ -148,71 +103,33 @@ def get_nx_class(nxdl_elem): return nxdl_elem.attrib.get("type", "NX_CHAR") -def get_nx_namefit(hdf_name: str, name: str, name_any: bool = False) -> int: - """ - Checks if an HDF5 node name corresponds to a child of the NXDL element. - A group of uppercase letters anywhere in the name is treated as freely choosable - part of this name. - If a match is found this function returns twice the length for an exact match, - otherwise the number of matching characters (case insensitive) or zero, if - `name_any` is set to True, is returned. - All uppercase groups are considered independently. - Lowercase matches are independent of uppercase group lengths, e.g., - an hdf_name `get_nx_namefit("my_fancy_yet_long_name", "my_SOME_name")` would - return a score of 8 for the lowercase matches `my_..._name`. - All characters in `[a-zA-Z0-9_.]` are considered for matching to an uppercase letter. - If you use any other letter in the name, it will not match and return -1. - Periods at the beginning or end of the hdf_name are not allowed, only exact - matches will be considered. - - Examples: - - * `get_nx_namefit("test_name", "TEST_name")` returns 9 - * `get_nx_namefit("te_name", "TEST_name")` returns 7 - * `get_nx_namefit("my_other_name", "TEST_name")` returns 5 - * `get_nx_namefit("test_name", "test_name")` returns 18 - * `get_nx_namefit("test_other", "test_name")` returns -1 - * `get_nx_namefit("something", "XXXX")` returns 0 - * `get_nx_namefit("something", "OTHER")` returns 1 - - Args: - hdf_name (str): The hdf_name, containing the name of the HDF5 node. - name (str): The concept name to match against. - name_any (bool, optional): - Accept any name and return either 0 (match) or -1 (no match). - Defaults to False. - - Returns: - int: -1 if no match is found or the number of matching - characters (case insensitive). - """ - path_regex = r"([a-zA-Z0-9_.]+)" - +def get_nx_namefit(hdf_name, name, name_any=False): + """Checks if an HDF5 node name corresponds to a child of the NXDL element + uppercase letters in front can be replaced by arbitrary name, but + uppercase to lowercase match is preferred, + so such match is counted as a measure of the fit""" if name == hdf_name: return len(name) * 2 - if hdf_name.startswith(".") or hdf_name.endswith("."): - # Don't match anything with a dot at the beginning or end - return -1 - - uppercase_parts = re.findall(r"[A-Z]+(?:_[A-Z]+)*", name) - - regex_name = name - uppercase_count = 0 - for up in uppercase_parts: - uppercase_count += len(up) - regex_name = regex_name.replace(up, path_regex) - - name_match = re.search(rf"^{regex_name}$", hdf_name) - if name_match is None: - return 0 if name_any else -1 - - match_count = 0 - for uppercase, match in zip(uppercase_parts, name_match.groups()): - for s1, s2 in zip(uppercase.upper(), match.upper()): - if s1 == s2: - match_count += 1 - - return len(name) + match_count - uppercase_count + # count leading capitals + counting = 0 + while counting < len(name) and name[counting].isupper(): + counting += 1 + if ( + name_any + or counting == len(name) + or (counting > 0 and hdf_name.endswith(name[counting:])) + ): # if potential fit + # count the matching chars + fit = 0 + for i in range(min(counting, len(hdf_name))): + if hdf_name[i].upper() == name[i]: + fit += 1 + else: + break + if fit == min(counting, len(hdf_name)): # accept only full fits as better fits + return fit + return 0 + return -1 # no fit def get_nx_classes(): @@ -383,6 +300,18 @@ def get_own_nxdl_child( name - nxdl name class_type - nxdl type or hdf classname (for groups, it is obligatory) hdf_name - hdf name""" + for child in nxdl_elem: + if not isinstance(child.tag, str): + continue + if child.attrib.get("name") == name: + return set_nxdlpath(child, nxdl_elem) + for child in nxdl_elem: + if not isinstance(child.tag, str): + continue + if child.attrib.get("name") == name: + child.set("nxdlbase", nxdl_elem.get("nxdlbase")) + return child + for child in nxdl_elem: if not isinstance(child.tag, str): continue @@ -472,7 +401,7 @@ def get_required_string(nxdl_elem): def write_doc_string(logger, doc, attr): """Simple function that prints a line in the logger if doc exists""" if doc: - logger.debug(f"@{attr} [NX_CHAR]") + logger.debug("@%s [NX_CHAR]", attr) return logger, doc, attr @@ -624,15 +553,13 @@ def get_doc(node, ntype, nxhtml, nxpath): doc_field = node.find("doc") if doc_field is not None: doc = doc_field.text - enums = get_enums(node) # enums - if enums is not None: + (index, enums) = get_enums(node) # enums + if index: enum_str = ( "\n " - + ("Possible values:" if len(enums) > 1 else "Obligatory value:") + + ("Possible values:" if enums.count(",") else "Obligatory value:") + "\n " - + "[" - + ",".join(enums) - + "]" + + enums + "\n" ) else: @@ -662,26 +589,20 @@ def get_namespace(element): return element.tag[element.tag.index("{") : element.tag.rindex("}") + 1] -def get_enums(node: ET._Element) -> Optional[List[str]]: - """ - Makes list of enumerations, if node contains any. - - Args: - node (ET._Element): The node to check for enumerations. - - Returns: - Optional[List[str]]: - Returns a list of the enumeration values if an enumeration was found. - If no enumeration was found it returns None. - """ +def get_enums(node): + """Makes list of enumerations, if node contains any. + Returns comma separated STRING of enumeration values, if there are enum tag, + otherwise empty string.""" + # collect item values from enumeration tag, if any namespace = get_namespace(node) enums = [] for enumeration in node.findall(f"{namespace}enumeration"): for item in enumeration.findall(f"{namespace}item"): enums.append(item.attrib["value"]) - if enums: - return enums - return None + enums = ",".join(enums) + if enums != "": + return (True, "[" + enums + "]") + return (False, "") # if there is no enumeration tag, returns empty string def add_base_classes(elist, nx_name=None, elem: ET.Element = None): @@ -809,7 +730,7 @@ def get_best_child(nxdl_elem, hdf_node, hdf_name, hdf_class_name, nexus_type): and nxdl_elem.attrib["name"] == "NXdata" and hdf_node is not None and hdf_node.parent is not None - and decode_or_not(hdf_node.parent.attrs.get("NX_class")) == "NXdata" + and hdf_node.parent.attrs.get("NX_class") == "NXdata" ): (fnd_child, fit) = get_best_nxdata_child(nxdl_elem, hdf_node, hdf_name) if fnd_child is not None: @@ -900,9 +821,6 @@ def get_node_at_nxdl_path( we are looking for or the root elem from a previously loaded NXDL file and finds the corresponding XML element with the needed attributes.""" try: - if nxdl_path.count("/") == 1 and not nxdl_path.upper().startswith("/ENTRY"): - elem = None - nx_name = "NXroot" (class_path, nxdlpath, elist) = get_inherited_nodes(nxdl_path, nx_name, elem) except ValueError as value_error: if exc: diff --git a/manual/source/classes/applications/apm-structure.rst b/manual/source/classes/applications/apm-structure.rst deleted file mode 100644 index dd6c456628..0000000000 --- a/manual/source/classes/applications/apm-structure.rst +++ /dev/null @@ -1,284 +0,0 @@ -.. _Apm-Structure-APP: - -===================== -Atom-probe tomography -===================== - -.. index:: - IntroductionApm - ApmAppDef - ApmBC - StatusQuoApm - ApmParaprobeAppDef - ApmGermanNfdi - -.. _IntroductionApm-APP: - -Introduction -############ - -Set of data schemas to describe the acquisition, i.e. measurement side, the extraction of hits from detector raw data, -steps to compute mass-to-charge state ratios from uncorrected time of flight data, the reconstruction, and the ranging, i.e. identification of peaks in the mass-to-charge-state ratio histogram to detect (molecular) ions. -The data schemas can be useful to generate data artifacts also for field-ion microscopy experiments. - -.. _ApmAppDef-APP: - -Application Definition -###################### - - :ref:`NXapm`: - A general application definition with many detailed places for leaving metadata and computational steps described which are commonly used when reporting the measurement of atom probe data including also detector hit data, as well as how to proceed with reconstructing atom positions from these data, and how to store details about definitions made, which describe how mass-to-charge-state ratio values are mapped to iontypes in a process called ranging. The structure of the schema has been designed to also document a simulation of an atom probe - experiment. Having a combined schema for the measurement and the simulation is beneficial to document that - there are many similarities between the measurement and a computer simulation of it. - -.. _ApmBC-APP: - -Base Classes -############ - -The following base classes are proposed to support modularizing the storage of pieces of information: - - :ref:`NXchamber`: - A base class to describe a component of the instrument which houses other components. - A chamber may offer a controlled atmosphere to execute an experiment and/or offer functionalities - for storing and loading specimens. - - :ref:`NXcoordinate_system_set`, :ref:`NXcoordinate_system`: - Base classes to describe different coordinate systems used and/or to be harmonized - or transformed into one another when interpreting the dataset. - - :ref:`NXion`: (about to become replaced by :ref:`NXatom_set`) - A base class to describe molecular ions with an adjustable number of atoms/isotopes building each ion. - For the usage in atom probe research the maximum number of atoms supported building a molecular ion - is currently set to a maximum of 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with - which all possible nuclides (stable, radioactive, or synthetically generated ones) can be described. - - :ref:`NXfabrication`: - A base class to bundle manufacturer/technology-partner-specific details about - a component or device of an instrument. - - :ref:`NXpeak`: (about to become complemented by NXpeak_fitting) - A base class to describe peaks mathematically to detail how peaks in - mass-to-charge-state ratio histograms (aka mass spectra) are defined and - labelled as iontypes. - - :ref:`NXpump`: - A base class to describe details about pump(s) used as components of an instrument. - - :ref:`NXpulser_apm`: - A base class to describe the high-voltage and/or laser pulsing capabilities. - - :ref:`NXreflectron`: - A base class to describe a kinetic-energy-sensitive filtering device - for time-of-flight (ToF) mass spectrometry. - - :ref:`NXstage_lab`: - A base class to describe the specimen fixture including the cryo-head. - Nowadays, stages of microscopes represent small-scale laboratory platforms. - Therefore, there is a need to define the characteristics of such stages in more detail, - especially in light of in-situ experiments. Many similarities exists between a stage - in an electron microscope and one in an atom probe instrument. Both offer fixture - functionalities and additional components for applying e.g. stimuli on the specimen. - -Microscopy experiments, not only taking into account those performed on commercial instruments, offer users to apply a set of -data processing steps. Some of them are frequently applied on-the-fly. For now we represent these steps with specifically named -instances of the :ref:`NXprocess` base class. - -Several base classes were defined to document processing of atom probe data with established algorithms: - - :ref:`NXapm_hit_finding`: - A base class to describe hit finding algorithm. - - :ref:`NXapm_volt_and_bowl`: - A base class to describe the voltage-and-bowl correction. - - :ref:`NXapm_charge_state_analysis`: - A base class to document the resolving of the charge_state. - - :ref:`NXapm_reconstruction`: - A base class to document the tomographic reconstruction algorithm. - - :ref:`NXapm_ranging`: - A base class to document the ranging process. - - :ref:`NXapm_msr`, :ref:`NXapm_sim`: - Respective base classes that serve as templates to compose the :ref:`NXapm` application definition from. - -These base classes are examples that substantiate that data processing steps are essential to transform atom probe measurements or simulations into knowledge. Therefore, these steps should be documented -to enable reproducible research, if possible even numerical reproducibility of the results, -and learn how pieces of information are connected. In what follows, an example is presented how an -open-source community software can be modified to use descriptions of these computational steps. - -A detailed inspection of spatial and other type of filters frequently used in analysis of atom probe -data revealed that it is better to define atom-probe-agnostic reusable concepts for filters: - - :ref:`NXspatial_filter`: - A base class proposing how a point cloud can be spatially filtered in a specific yet general manner. - This base class takes advantage of :ref:`NXcg_ellipsoid_set`, :ref:`NXcg_cylinder_set`, - and :ref:`NXcg_hexahedron_set` to cater for commonly used geometric primitives in atom probe. - The primitives are used for defining the shape and extent of a region of interest (ROI). - - :ref:`NXsubsampling_filter`: - A base class for a filter that can also be used for specifying how entries - like ions can be filtered via sub-sampling. - - :ref:`NXmatch_filter`: - A base class for a filter that can also be used for specifying how entries - like ions can be filtered based on their type or other descriptors like hit multiplicity. - -The respective research software here is the `paraprobe-toolbox `_ -The software is developed by `M. Kühbach et al. `_. -For atom probe research the proposal can also serve as a blue print how computational steps of other software -tool including commercial ones could be developed further to benefit from NeXus. - -.. _IntroductionApmParaprobe-APP: - -apmtools -######## - -The paraprobe-toolbox is an example of an open-source parallelized software for analyzing -point cloud data, for assessing meshes in 3D continuum space, and for studying the effects of -parameterization on descriptors of micro- and nanoscale structural features (crystal defects) -within materials when characterized and studied with atom probe. - -The need for a thorough documentation of the tools in not only the paraprobe-toolbox -was motivated by several needs: - -First, users of software would like to better understand and also be able to study for themselves -which individual parameters and settings for each tool exist and how configuring these -affects analyses quantitatively. This stresses the aspect how to improve documentation. - -Second, scientific software like paraprobe-toolbox implement numerical/algorithmical -(computational) workflows whereby data coming from multiple input sources -(like previous analysis results) are processed and carried through more involved analyses -within several steps inside the tool. The tool then creates output as files. This -provenance and workflow should be documented. - -Individual tools of paraprobe-toolbox are developed in C/C++ and/or Python. -Provenance tracking is useful as it is one component and requirement for making -workflows exactly numerically reproducible and thus to enable reproducibility (the "R" -of the FAIR principles of data stewardship). - -For tools of the paraprobe-toolbox each workflow step is a pair or triple of sub-steps: -1. The creation of a configuration file. -2. The actual analysis using the Python/or C/C++ tools. -3. The optional analyses/visualization of the results based on data in NeXus/HDF5 files generated by each tool. - -.. _StatusQuoApm-APP: - -What has been achieved so far? -############################## - -This proposal summarizes work of members of the FAIRmat project, which is part of the `German -National Research Data Infrastructure `_. The here detailed -proposal documents how all tools of the paraprobe-toolbox were modified to generate -only well-defined configuration files as accepted input and yield specifically formatted output -files according to the following NeXus application definitions. - -Data and metadata between the tools are exchanged with NeXus/HDF5 files. This means that data -inside HDF5 binary containers are named, formatted, and hierarchically structured according -to application definitions. - -For example the application definition NXapm_paraprobe_config_surfacer specifies -how a configuration file for the paraprobe-surfacer tool should be formatted -and which parameters it contains including optionality and cardinality constraints. - -Thereby, each config file uses a controlled vocabulary of terms. Furthermore, -the config files store a SHA256 checksum for each input file. This implements a full -provenance tracking on the input files along the workflow. - -As an example, a user may first range their reconstruction and then compute spatial -correlation functions. The config file for the ranging tool stores the files -which hold the reconstructed ion position and ranging definitions. -The ranging tool generates a results file with the labels of each molecular ion. -This results file is formatted according to the tool-specific `results` -application definition. The generated results file and the reconstruction is -imported by the spatial statistics tool which again keeps track of all files -and reports its results in a spatial statistics tool results file. - -This design makes it possible to rigorously trace which numerical results were achieved -with specific inputs and settings using specifically-versioned tools. Noteworthy -this includes Y-junction on a graph which is where multiple input sources are -combined to generate new results. - -We are convinced that defining, documenting, using, and sharing application definitions -is useful and future-proof strategy for software development and data analyses as it enables -automated provenance tracking which happens silently in the background. - -Base classes have been defined to group common pieces of information for each tool of the -toolbox. For each tool we define a pair of base classes. One for the configuration (input) side -and one for the results (output) side: - - :ref:`NXapm_paraprobe_tool_config`, :ref:`NXapm_paraprobe_tool_results`, :ref:`NXapm_paraprobe_tool_common`: - Configuration, results, and common parts respectively useful for the application definitions for tools of the paraprobe-toolbox. - -.. _ApmParaprobeAppDef-APP: - -Application Definitions -####################### - -NXapm_paraprobe application definitions are in fact pairs of application definitions. -One for the configuration (input) side and one for the results (output) side. For each -tool one such pair is proposed: - - :ref:`NXapm_paraprobe_transcoder_config`, :ref:`NXapm_paraprobe_transcoder_results`: - Configuration and the results respectively of the paraprobe-transcoder tool. - Load POS, ePOS, APSuite APT, RRNG, RNG, and NeXus NXapm files. - Store reconstructed positions, ions, and charge states. - - :ref:`NXapm_paraprobe_ranger_config`, :ref:`NXapm_paraprobe_ranger_results`: - Configuration and results respectively of the paraprobe-ranger tool. - Apply ranging definitions and explore possible molecular ions. - Store applied ranging definitions and combinatorial analyses of possible iontypes. - - :ref:`NXapm_paraprobe_selector_config`, :ref:`NXapm_paraprobe_selector_results`: - Configuration and results respectively of the paraprobe-selector tool. - Defining complex spatial regions-of-interest to filter reconstructed datasets. - Store which points are inside or on the boundary of complex spatial regions-of-interest. - - :ref:`NXapm_paraprobe_surfacer_config`, :ref:`NXapm_paraprobe_surfacer_results`: - Configuration and results respectively of the paraprobe-surfacer tool. - Create a model for the edge of a point cloud via convex hulls, alpha shapes, or alpha-wrappings. - Store triangulated surface meshes of models for the edge of a dataset. - - :ref:`NXapm_paraprobe_distancer_config`, :ref:`NXapm_paraprobe_distancer_results`: - Configuration and results respectively of the paraprobe-distancer tool. - Compute and store analytical distances between ions to a set of triangles. - - :ref:`NXapm_paraprobe_tessellator_config`, :ref:`NXapm_paraprobe_tessellator_results`: - Configuration and results respectively of the paraprobe-tessellator tool. - Compute and store Voronoi cells and properties of these for all ions in a dataset. - - :ref:`NXapm_paraprobe_spatstat_config`, :ref:`NXapm_paraprobe_spatstat_results`: - Configuration and results respectively of the paraprobe-spatstat tool. - Compute spatial statistics on the entire or selected regions of the reconstructed dataset. - - :ref:`NXapm_paraprobe_clusterer_config`, :ref:`NXapm_paraprobe_clusterer_results`: - Configuration and results resepctively of the paraprobe-clusterer tool. - Compute cluster analyses with established machine learning algorithms using CPU or GPUs. - - :ref:`NXapm_paraprobe_nanochem_config`, :ref:`NXapm_paraprobe_nanochem_results`: - Configuration and results resepctively of the paraprobe-nanochem tool. - Compute delocalization, iso-surfaces, analyze 3D objects, composition profiles, and mesh interfaces. - - :ref:`NXapm_paraprobe_intersector_config`, :ref:`NXapm_paraprobe_intersector_results`: - Configuration and results resepctively of the paraprobe-intersector tool. - Analyze volumetric intersections and proximity of 3D objects discretized as triangulated surface meshes - in continuum space to study the effect the parameterization of surface extraction algorithms on the resulting shape, - spatial arrangement, and colocation of 3D objects via graph-based techniques. - -.. _ApmGermanNfdi-APP: - -Joint work German NFDI consortia NFDI-MatWerk and FAIRmat -####################################################################### - -Members of the NFDI-MatWerk and the FAIRmat consortium of the German National Research Data Infrastructure -are working together within the Infrastructure Use Case IUC09 of the NFDI-MatWerk project to work on examples -how software tools in both consortia become better documented and interoperable to use. Within this project, -we have also added the `CompositionSpace tool that has been developed at the Max-Planck-Institut für Eisenforschung -GmbH in Düsseldorf `_ by A. Saxena et al. - -Specifically, within the IUC09 we refactored the code base behind the publication `A. Saxena et al. `_ to better document its configuration, here as an example implemented like for the above-mentioned paraprobe-toolbox using NeXus: - - :ref:`NXapm_compositionspace_config`, :ref:`NXapm_compositionspace_results`: - Configuration and the results respectively of the CompositionSpace tool. diff --git a/manual/source/classes/applications/container/ComplexContainerBeampath.png b/manual/source/classes/applications/container/ComplexContainerBeampath.png deleted file mode 100644 index 597cee834c0426bd0e60b1afbf6554a5f3b04a99..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 7089 zcmbVxgT!j8lW(I7CP9R3l4E<2>J5 z)AI_IpP{<#g$8#av2ACx&qHz?7*6{wc9+~vb1nw=8zsvCGZ@1U!ma35{YCTeb^go#}G;SGXdmMbu z&k(dLz+>M0rk*>Sf)`6r0rqXS-WdWA6B8%4ZJE%EdqQPyjwzkRB;aOHTl>4)o5x|d zk^nCj4;eIl%(n^F+aGp�Z2d70QK#NZGhGGt4!*DVv+aK@%#_`tEYYN5riu(%l4#$J*D7^Wj?wMl{e?}qh~ zY>s%K&(C)zD>TXgDhM0}O&=C2r+yy#K3pp3G_SZgw*E;r78oa{=-eoZRr2X4M1X%T zpwKhuUnefLT1P?+p*cUDbF;27;urNXIdV3GP9r`-Tm1Iz!5axr2q&_2aKHv)6R*sV zoC86Z4ZQcMBBg7vGph*EBH-3c92|H`VKT=wJcAF`QUTL~RppiMF@&7l+%|jh=q_Yl zl(4Ai%5;s*CbbwAZH2$YiG@Y5cQ^ujWfjnl_}!#bRb1n>F}OTlrVE!&9&uFk^!!4^ z;FHzbDye5^Xk#UxwXh=zxB3+h)q$p^rRmjVynV~|G~Rjyp=(MM0mu_vg>= zxp&taB#b47RTc~^Sn`WBaGB9RJ~<@SMf)iaypK+F>MgC7zsG<%r}Pqabh%S?=ZlnO z^3i`NU#PHfxzukcD5suN`yh?Xm0-C9poTO!`bZon&_&qD+`{Bx!n8>beH987Qkx%6 zRNOt{;*|T%y-h7HKpqjqJ|6|a$DY4jlDeCYdZAn2&+t{t*H<)>RWW_m=_B!yXoyoi~j%|VXyXk z04CaDLB0Woc^Km9>6tgSGvc<^MsnrPilHHjLv>{cIk;b)x=dF3^O!*;WI(#z7`=S_P(B*fsh&^#>LCqbFwo<4%S1-m5+rtCdO_86H82|ZC-J$ z^0QbYQ`^F#vI*`-R!K??acY7!^%XsR4*+eK%Hj)EVh@1o1ZacHTr3XZeXE%-cJZ^~ z?igTnbhO%Wgc-Tl^we?eguId(P0owu>bd@t3XpYIWGuOgQ3;QMy?OJ-3M_sY35mfq zuL>o*x~!TS!N0WzGR3%G{DKF@zLYPS60_t>W-)`#e=IG9h1bEVcPafZw@P#@ERv6p zy`y8B4KrpKCaWw_2M6wwSG%=MfhV6$c;?N^>W7f6Z-J zDZ9VEuFcES$qeV@;ra2!?iU#qRgB+afU-yn!0$B5%45;`0FQ+Jpvg1>NBLMTz?jA| z)(osl*JpZq(Vf!EzRs{Z#ZpRbFK?ztkBILl;4p?=3tZpa=+|-|^w7C6v9sgywH;Fs z5D@4!^2MZlIShqt{M-5$5}9@b3BTNuH88kO!XO#foj}bZFw%z41MhYee!kk11Oklz z`dh>Fa}3e4#Q&K^U0w$2y?M`4s?}sm*A~AeYh%N5dpXtdeQ1dE*Lyz0`5f+^M4G6z zHCqtGR@VAntA~)o{%h9k?(R;MI#dUbIHEcyL@Z3EPxQq*VzL9^&^mv_@!);Obxb`s0N9NAtehd-L8uV}6C42C7z=Ib>PI6$H_DA_up%NN{Fh^> z@6}Hj#FD_{!Tfx_zu5NJ|A5Ka53{$5E!*l!AM|fiPAus(m+^;m79F8dyynf(?=1rH zL1Z)>HwZHN>dAH-*ru$A9m`(xn;An7#+IpHMW`trs;7o`dodKo%*qNKlD;Z0@SS}M zHU)v8)BotDgVO^R+R17TGolBVnK8I7s(9m@l)VE3NI5x(eSbQnP-m9fpg%(h52&{L zb-y_Dz`Ik#*O}nHg zNlM)8!9#x}(&v1I@WQ?csp#Kj<(@;5C9WOi9N+_lr(szFV>MwNGCcRs0*lZ|JIVP9 zA=!WCs+T1Mg;0=m61V*fl8wT){%kq|Mn?2fwDZ(fo$MHgwK`?lUyM`_1(0Ukfxp`(RR^z-IUr-0Hi-PWow{Cu;JB3(UcuYs*w zS4*6aR_LvhhkwGVo|nTL3j)wU85OH)F@&*_VhEf6T494$f9%^o{wW)R-E2MjvGeza zFSC{4jJ5&0C5fpaM@X8+x{0vKT$s9P6dx_!2}!7${-?<)v7eVYfycvLXmo&twy8~2 zSzgxcRWV?%+mDKmCxGJOHY}zf zBEzVtsQQD4x4pr}DhW>kTOQr`_F+|Id_uJWpE4krDs1n$j^ z4~#^#*Vo<6%_-@S^o6&xx9o;ptbyqcres_rlnA$?e4mR+7B4CynP7Ygfwge$eLz}V zGHzyvt(_DOG`TG4bC_tSFx*_?tgdwH@@G^c9{#)#bZ|j__6fymYZZ3A(t^oZFRLDJ z<|7pqNdZ|D!)U?g&d%b-{%;MSR7p(6^ymT)h)QkekSh-{N&J1hTjn*>H)-(^OFEn3 zfYf#FlAvDXSZH;}`L!fzojkUZ-u6h1~<|ldl38{cs(Tz z^yf0hlCvn;jF)zoekSZnWBb{^yuUDabL6)Zuf3|k>+R2D zMvZ^Gh-lu&y-J9rKP7y=AV`reWqLvN9_W;5A}8f@GEIFJ>MP(|aY1j>ljymVg<{x4 zjTFww#AKCVyAHqe?wr(PU0Yvgn<*~*(cO)Zkf1efbUo?C5fXKog#!N9hvflQ_Ei@1S=cn*o&~0NkFVWeV!*?(Mf@_YaIXRWBoSN8N{9R{?_E)?I0Pl)- zSk3-lc6VCwGx2l6)(wj|_KY$|AtH*hpC?w_!mj9Eym)c1V@Ac9UMldOv9Ym=hDLYW znZ#o0TO2BlDK1H~Tb&O}SYUmu{fUFUp;BFPRH*QlWfB*sA(cD;7K8SsKm<0T%Jh2< zl25-sW)G5-%1!FyUy%-yRq84#LT$7pDM1{kASaKA|J*&W{>_j1Bet3!Q3ERr3${`r zxt8<=t9tQd$(x@834HBwAge03Xrmn&8TmB#UY;zXJtTXHv-mT3HX4_wdxXvk*q_u~ zB^KOt1>j_xQ&o(Mfjf`PTK&m~q|UNl_(H6f+C%*J+s^o{zeB+URn(uW&@u3)lKb|J z;p;&>2N*w%=;1HNUykTZO0!8|{kbxXs;a8Jy}g~u@F#jT#yUC?U%fU8K$QTFg)4oE z%_J{+UxjhaAyD}a+Cs@wwyCv08}-sKhMprLBO|M=zF~n3htt&!q@|o7$!ghePmm7z z=+^r^QYn-8Z8ux1OeYQ)J;h$WBE@i|1QQu8Z9J*;IbdgJ7r&Ia))|34-QYs^?AbGZ z=Sd!<%U1ubM*O7q$3I697l{b1@r}c zb#YGrIZ^e>4+;7>IyR=G?@1{o-#w>byhE2awIfv-SjnB5>qWm1bS$f`p7=skW1XFT zab*!&nTEAa*pl^45h`few>x}ywmtEbT}whUI9L)~CN=kUf=-|A2g^ng;RDWaM3N{S zftMEMw&v9*0uNO={Kbrmkq%3Z5NXTI?3koyUB@P}H98^f}=x3TKl?q2}O2mR_|A|nL zG%`hFHXWWohRc4KLB~t}UJ|dtfA+lL(mfBsorQsVS4B-NvMQG`*|mrnY;qfg*hFN{ zAVt)=7mvOnW!V#zSZ;&1_0}9V3d%PhmV*IWUO1bT7+5{`@uWt=L$Aen^UF!p7wjLOt42~RsEI<~v438pG3D_0z4+^UFEz|`) zvuD@Lii^O;!@>~8S9gxNMoiLx4hhjF6<`Q53Q7mdctdkR2MJQ(Hb3194@9I}(Z6jDB zJ-!i-Y^d~bBcC&hzN{R&7{>TGfa3hb5Hl;n^pGGf31?*`JccmBb>U5|n<%zhE5z0o zFs#D*K1$Z!-dX3=Ia(A>%e}X|NL+4)pCwH^KJlswMT6a+iTAMxVxlBhGDD=E4w!Xl zR`oTwY|rFK!#R0fgRZJNaIvu794Qm5yb=~B`#Y=?lD|D9mB+$H zGGJ}T z>oxbA*&q6uHWjLhk7x@@K%-tEY!@WtNf=nyYKLH|PiyahN^|b2kcg7p`!3!)O1;1M zD8B@WA@E4Zz66RO5QvrA8XNqw&$>ONTwlKIRz-bacHh*#f`TAOsjnZcp1tkwDX9tt zZ{qN8LFksZFmv_H?%aH{-5m}-3H#ct$VIS<=6#fu9l;H<{q^2lw`hBNw4T9Fhg>pw z-#_9?|jjKcL2)~hIOYm38(_cRw(@DuF$S@N9u3V*z!Az)-2&b_hHdUq^ z3xAG=x_$BS|6XF^xpYf4D&8f*`ZGCZZ*GH5cAFtri0_{bBW7wN&i!X;U;vBKFoUaB z6dC4ff2%rVim5w%$osJCH6|G^oQf{XGA&-h3Vz9;(IbvVh*_!@a$6 zyTloD+(iBw#EpzJ3i{pq)k`)&d?7g=D>&G!kx|lUUOLEtfpK)Sl+m;S2)lf}(;y}2HdDyC+iQAu1*gEi}#v~#)tauKr>f77x zt6>sJhdB3RN6g7o#Nn!O5c2@$o2<(txGSh4PEM)$;^+L99-&Aj;AE5vj1>sQN8#5B zF>QemN{)ubKP~$|T#CZT>1e}^Yd5Ps9XV5SNamaJ%QYO<)?X+s!HDn+>w zgkDCoQRbQqMq)6TbMKLEM=HzKk<4|35{?o}k|!F4XAzn)`Jp=2rzD#7Y<@KZ9_6xr z9pG^flGkOg=6S@9K%*$XI8h=F4-3p?WM;QM;o1v@ECrnoCksU7yJVMox*z0C<2SkI zpI;8id|nc0`Y*%L>%eNNE3z$!^6!M<_Bk7b8p6h(>7>O`A0 z<+Zv*G%oobe{*ED{dM1NZ?PGvV#``j4cAc7NNPgGz!Dkv{TaS@;b(}yo^=0#PGFJz zZnL536YPaW4f$FI*7aZ8k+WfKpLp58WA|%}Q@wZTZb|N&MlBd(NM`?fsxmB0elg5a zyhTfzYtn^Y>O}{*Xk9rgF>z5nn_pVy(}ezLUu)}VJ-yP^B{+!VuV+ohkm{K0X1(jcKbDH?b&>a_(vxDPrweFG!4ZAQaM@IzzoNjj}rA zDd{kJNtN8Ib6~C!yRUCI`0r^kQiz=V_+lWl4sGU=mKMH|Lz&xg`au%S7JWZM-(ZyC zY#>w0b+bZ4{R69Ou8h`8GW{N}ZKwn{hbDlMWY(nFn;@L7Cww3hUttM6+E&%TSqy$H zO&vQlZoeprsc76h-5UFw_||P67JNj!psA8~0(<040j;#8ZhWd1PAZ)@XY#1pN)8>I z64k46S?F;kD#aHQ)0rptsTt&LEW5MFr}iV=DwtlH#MuJc^?~}{NW{(*GKiKKp`5JJSn=tL zWw`ym#rh3c5D}+>zU7-!QKX}9Q^r3wOy16eEhKnz|J>v1gl6sbZ`IcmKef_PdcMtKNSG<9Xx4}|=|E$9hEynSWZfFpV5_G*B%drKT zf{p37pZB$gbas&@46(47YZbb@8iCPEJw!2f+^TU{;OoX*ofcVd4Ci}K&W{udOOZ=t z#S%e0z1B4hVGwq$;tgot*W3B8oi}G=XMrnFctcBY#-FJdPMc3$vx24TVrm__`JV{r zWa$;L>gx-iP}rwlo)7P^BtBUGJ-T&NRCFAm0y}ZW$gYQY;R;z9O3Hq_ZqLg}D}5gC-$dChBeP#=_&Wpc z6)^{U=SlU}^T*LAGHTrz*Ap~tFkB5b#KBBH*19n!!Q|!N93nX5?j!e>NF|R`ZpIhF zfmx@Ej=QHU&3KG@J$PDno7xgmx2veFAUE;jl8Mo>b>~UIVQ`vsRSAk>_BorqYgesWGUr@`D=W&OA`>A)AQ05o^3v}i5Lh$_1g0Db0lX8X^R58= zdf_PfS`7(&c_EpEf#a8U@*f-_5PbCK9~ip&QWWqep_7c3ld7$mldF+~Da6&)mG!fY zrK7QtohhrW!>5!(VIl~G0`gi~Ld`98f5FvDO??sJ_>&oD^1wR}x|gq!KA*>kW5EVw zuUbm{adpZ^)|#v<)Y9k-VZzhDP{*;_)>cuIo~8+KLbAq6P{#TvKm7Nd=TnVILXyxI zl%HESKB7158}lhreFI-Shi*ud+gI%T>QLF(*pdb}OAZlKLK#?DW!>D|G+hJ3hT`Qk zUH!BpqoSlOEG)n~d3pyk6^H@?0(uLmRDw!Sw1tuBKgK6BpE8`C`NC!=5?;L}APMt; zaR+}E78d4#hJZ*#MU@cM>JN@+jO{4EQ73XtfufD`t#80g8K5T(wmmSFzPQ|niIO#% zUOgN34?|k1wVv~&`)qK;1#&U|SUpzI;H)JFc+BQ?Po4OrOMFz>WFf8o z9?c@2ej~~&m*e?<85w(3)Uwse+1)OJ5mUdcTO9zA|L5vGqJP89V4Q zLZPB^_-L2eM9r>zZP#fA*Ywo1dUUg(N4JSGKmb1D~NPY=dncQ+j0(tM>i z71eHtTc`hR$-q0qBmFFo^&dP6g{;}xe&oJ58oC&mDk$LbTt#kZ%08?1cO#%9_&ha! z=6r>TS=o|>yj!oBigB55F8cCxgpz^-)9q%XWDg%xg|BN_+0eZBF}=T!_U223F&dv=VeyWm~`2Y7bj>l_ksTBB;}*4 z>ovbvbPPNMuVab10~F*RHt0m-_7C7u{h#Nam|r;$`Vz9_J>_!8qVvNhmTZCJc^C9eHBn(jF{TXU6 z?l($^k2k|5du(8~I>BrOzJGatj(yyL-BO_5hBy24PUxp~61hoX@4Ez(1+<<+#b!p43p z8BdoPDYKhnsF1fTi;HMzYZKAFOY%b{=1pDjr_WytMKR6p?dJ8bS?k)$j!QJG(4eesX z6PgCmwT@dZ*IPU0OI~NFi|$)#Xivgd3$Em>_50=ErSy0;2miqUYVn7Zd;qA)nY?!`;cw*oY5aGy9sqo=jkm9DvOR~@huRbmO4pY=SL?N zwlDEmw1Z?K@tmh`_-q%W@>PGkOy7iu{a7RU|6maK?^q;UR|f|S^2I<3A38CgjnzfX zf=y_ziKMr;NV?DMXXX#(KT$lUf}Z179x*)wgM_|*`W)}X#6;RS@f5$B#Q(fyCqIW^ z5HS5JEvMQ({`u=MzhXxrBt*Qkv!gdsIQgGoS_f0Cv3Dw9V6ddPAMQy~@P8o84&)RH zJ@4z52KTcv`?W5O*tr82g6J;R?Rfs@$ewMJ`Sa%scXxNag=k*;ynz1$@jtfY5CR+y zjOA2GaOcO*7d7oG;w~<{|Hj7ZGc`d}2mZ$yPP=$=!?CHUDQz12>VIba##{F9%&VUPR2&MNw#8UcrRPQcZL zn4j+>uW%t_Q9vFL@KtZ2QV~QJX=(4-d{xxvo65?fel%`8Zh=$DKA0>fjtWD<9p7zg zEb)8Z8@H(wg>V0SR>kGyvW&~HbrAJA>4aeoY;W=39op5e{!a+-9@4SJHM+YLq@gX~ z_@v1H@85m=kKKMd3Yh0OaY4kxqhYn69a&VQ9TY@wzvLaCeX!`s_R`2G9SQY7=L~xm z?my?5XZY&Ju;>I$pdq4dr>PUM)wE2R+7a-+n+q4&*L&U$d2*gN8(*etE70QO8Ff9a zk>0<*k4spMjHhm_ud{5#dcKVFTeAvMA=gPtt_nP&Xp*Z%CZ7w#i2~^t@a`0}U4>sf zr}>@@My2|spG|$bp_Yh{kZ1Z&4w_j7`ysnk(j>T}$PZ0CLG1rrj95w39XeMv(Kb8` zr~3Prnr8z2^JgCdvBlqo^|GJXpDz?@+0-2P`#02ek&t!va3gVT`JlL^%xE#;(lv9a z`+25GKX%6mS}p2E4-62QnDHJQu{-5~`^djO*&AT}CtwK7DI3lH>A@YWhW~qp_U%zo z`L~v{Oa30L&l^tAGC0`G#B`#~%yBt4MN(#tSqBd#`CZ=c%u&1ftctH*$1p`aJfto@ z&nH``x>S)pJ=mg_mj}gS(+xoUI;1Q6m+e-9AJb+!$!rg1E6cQ)i^*L1NqUBcWIa6U zex8x|ZW1OTBhS`*Dn8rJc<#-aWBfODxLVz$oMW*kY$r3z&uBt_@rx&&dEWlFD|$ZB zTUY%X?uQRNBYOumkGB}3yh_5DsG)F4+`afdK3;p&yLh{eL$JmfQqYMpE^umQ&lKc}o?D z5U>_18IE(-a%HA(c_0*wZ-R+!kT%NT{*!`?M{*w?DeGBx4kSxtTOT%yAz#gpq37o} z%`f>65e33kzE@R+%NgB1y(uVQ{8XQifR%Wl#)u0G3p?BB>#bmI%>qRT?B8NyVoE!h z_ZAZt5y2$r=^t!VP>9C$y;s>IahYz?n_i+6)j#0m*R>D6UUNFM;zh(k{-Eiaqsq>& z%oK^w*0noPIA>LD(u)NmOUK3;m)Sr|hzpUyUjO6cRkQI#fx2~-=k-eH$#FY+y_cwn z2x$tRtxb2jimTm0WoVgw4#uXpH*S*P1o`LBZI5W&HQqNH z5^hfqKT8fj{sz;Sn7iQ3w2s^U9sEdX1l`W5Y;)P>w)ym zTNYMJs)4jQbWL5%pugN=Q1YP%(xJq57%gTrH;)Jd5dtwEzIU|sXFggr z(!igi(JX|4xbSH*4r{E{;)seu(bi}6Y?(v(XXemt4+ovr0_nkyWZ-1D{Zl{viL z?0&xEi=5GzgE>oJJ7BXDJ@5GfMy8J+8|?O{;j_DSJ&UgyksOAts*Im}L>wHVMs}c| zM5B5Jd6sXs*6fzNi>r^n_xj-*L`jMJAtoen%fET=+W#xRphunnjWnR$B3Pj`v`xVq zDZl8`_m7N$frP*%)I~Ct@Gq0NC>L&kU76@9l!{n50h0{Pc0@ltQveTFeb)32;rysn z@=XMJTf2x}x+=4>6JJ43uIP``(@av)`-Y)Ue949kY={tgDamIqBiR4Pm^PK)sB67< zRbsiMzRe!EJm5gvlQ=|K*%DRXR#x)vFBzbxDb{$5xZzT=4TnV&%Z2$gBBH6SC4c%j ztSc}=K`DV+S?3ycmY1EKT3uLeC2+K?Ty2a<^68C{CnsGvw} zgqWD=^o&2~JqDurB93mv+eQN3yn5_v^6`eZsoN<#YYGj8!XdaBbw!EisjaT`kEw>x zrHAdrHM#ISeIB#BpZNp>p-cBfTXCI-3632W$T*r-RT8lEj3w;{E@&LnY)~-Fwpj#K zyap-?ypKTms0|_=N1d{UnS_hW*aTdfqE@Bdea*{n-x#tTk!cmrJ5M+4hujhE?JelP zd0$yXKYe8wfs#Snv!u-FS!5n_VyTQa`WywPdhrdUFLD)z?y~siK`9~a#9B~L#P2c? zq>|Ghlaay0L=cGZIqt`9$|g!s`&as#L@-_tp3Cdr^Tz&1Zql&=noZ=nNxEs zbew(I#CyS^WV=f$3kUI3_$-o#0q_t%RokZU5Y^upPq%x@7m1h7!ayxGy_DtaiyK3pK{5MSHP;e``f}&!@^S6bfvVUuxnfjPS4Ba&~A=A)Wu$#y2{XoQ~yZyM@aaa-T z^yvqmEg7%P{PeDU{la0@k5c+%=KucbPnr_OuYRp0u9Ukk8a zM-c`Zi9NiC<@)9ac17Os*q${#J-gAi^2x>F&d%fUX@U?F=Vj*uDH=KNau23dVIAUH z_uXA`1aSm`2f9HB!KG~3-OafJfK=f&_0$1{lPe{J^m0F6&aMorvvakO^stVJ z#B~98vA1#G3l+75iB{jC*9UAamqm2s_f!n8qvNSNx7;9YWpK_MwInN!n-u5Yb(BvY zuIQic9mj3v5FCxN%pHR@P@2!3Ug&#qwAnP`l2P5wfzYdx;c&Ge*zn{tW@gyh`eq=N zp~$67oAmg2d!gc_SOc-V;(|qknftNc&WI-6*T-+${^|Y`GY&EZ!|T8fX`X<9q2hZ1 zXVls^!Eu(QGCh@3un=ZbQ()b}m32gDg}7w?{>ljOtz67d&R=&&EFcD5FuDlYtp>gP z^JlgFAobUcUW@F*^s!HT8P*%DP)WP_e9gJ#y}aNZ|LsM>(; zs@#|WdWnaNOF1Glb|FI|UAD`~t^pl=@5RY2~Z}&w5Kh5F1E4t;aq(r#7Hc_)* zF8%_s-pAdboThKXas2MtxHoPu@`ifErR+JZDl3)UJf#SUkdNZ2SHw(_8|0!ByhIT~ z6~87Xh8{IPEm{+&42Co`2p92J=udw0JZi*`aGXE=kw@KdcUV8Ncfp#mRPiacA}u!M zv>H@61QYu*McHku4#Fb58uU!5-#0_Y)x@Gm=NzwG>6t1FuMX?X3h{z`BO?a*oy=3W zP~wVGT{_gi8M!c5&#=#9Z*k4TOsZoshU888hF%Iu6@;IT&Wcaym`)d>=Nd3E^O ziaq>=zWq+(yf|fnEB{XIIZ1S=bt6E6o-a?pVNEFOMtS4wBelmU}{rukC-1=+%M|t zy5tFclG@v^hk(w6LZaY;0o&~)8RBS)5n?5XZ)l|rt^L>GsXI z0?dYj+NSU)nxA4q60m@`S!dRQ4EM;t(DSM7KjY$e^6y!fhbD8br^YPYuWVi(KvjhP z-C8a@S`qJ=DBtl*XUsij5J9@xt+kQ9v!+cRT)Eo0UKq}luU#Lv=f2AD_a_@#c@fx( zP+WCkABbql?q+wSvm%jJy55ei0)ix@g-e*^Z(6o`KQ+QrC(~$bIdYii2j6g`b;B<43G;rQVb`dh7~OOKOg=H{$6Hx6IDZyAcz)$?X+;-7Do z*tzQWoKy6^nFk)0?QLY)XVI;x)} zJVV|dQoCroQn#m#uR^t3V&&{SG`AZRR3W;^rJILg;aKta2Y8Hm?aBfICJmg`p7>k} z44j|RZz9+V3X74T`}c{MUwUImg?6aSOblE@#}-w}qCnaF^9V)s_KWUI6V92H z6-w*{+m&m3Y+9woy@sO|N-5n`eAZeTjM34O>V`v>U%BDBDl&3XxoT}je=_&ahB4h{ zOcP>@m#Wbb($FBwTsEowF2H|#$Mu?YXZV7e&hEO53?3d^I+PTTEvD_?FH%htd4pF{ zkF2j;9xz@mixz3~V3amL(t+Yu*u-d{m4&QJWz5Ff>$b!!he7 z@MeR^{?*mj($c@)hai&gv)z)YDE*qS&=cL-+he*B=6JeB1S5dmcOhw7K^R|jCBJ=o zI2yV^QFIZCs;$ktz0f4_Jrv*uxHbf-`N73J6wTQk)TP;?KeO8c+Cx!mwzI{5=H61V zC`>O&{IbaS<5M_8UO(lz`gI8Iw-a*eKle<2Isbx>0-|}0p_9$dZt|(-t!Ymsft{(b zJm?Q7Y)#j|rRe=*eW2Wpy#M`9VjGn&bH8GExok%Hde*WmRWy2?>+U^w-`(9({MB+G z3)vYVAKD3%W}S#wAe;*NrwT#kvbiwoWDk;F?&WJAYW=BK60GGjqas)5?QOyFTRdW| zdYv78syl8gr@2}1&B{Vl304FmW6;Rg2${}yNHJ9_|2(7lYihB?KZg#dQS7216zib` zXOKr|7Q;f^Iy?T_nAp}z3!dku#MM~f;@FgU0oF)bWU`9Q^0p*Imluf*33P;FLW^5qfw zMikkK6p7R)X|5QYp1ctnMShyPspeb?@3HRxjbU=QvNp)Yes{6}Q%+WpI}kB%jX?8m zghD_)QsT2Vc-7Lcqs?D7Ly}iqNl77oZ)$k5nloLNh2>ZFl>=1O9L8SH$>;-4LxU34 z1MkU!XL#Nj{JWG8zt3Z-GFcEqD;HiI3!bm7t#R&E=~Lr);665++bTJZZ+GQxS?dT)ki5#8Nobsb()G(Bi|VF7opQgb$BNAoH_ zJ}%Q=w*3d9w1`FphxkQ{|CTf3^M#kUGMG*lJzqV8RIgtLo}JY2vu$6j`mQiF{?JEa zHbX2zMa%QeBn@zLcUsPZXd~u1N+NKOLx{g=02hvFc{&HuHyl?hNPvSd*`y>=O1Ecqy?6;HI zmYjVIp=mdf-5|D6jm?Lo?VCm~(Kf$4Wv`o!LIQr}1Bcj`RJ(J`8ynBLc0 zqD514`%v1&bd7zDc~&-XLhZ%XA+6nVFpY}{wYs!*O95G3A-{ib2puu0a|Y4nu|Haf zNuz4i?uY)?#0v;Sq!gIBxPL*lE3)fyD7~R1)~c%&7LrY+#mJ~V;Ar>j&-eD;jeeCn zkIFN9Q#|r?6Cm)1*4hRfnN{;k6`&}4J9@UF}Hh#bglo3a7d7+K{ zF)nuL5x(hT3iDaV1nYC@vK+T&6uIPJ%`vT=&q;VG>4eDYaH&AKVi6xDS#dFp3q1R?VKN0#KEW~hhW*O z4FA>qp+LfyZ@yHcuD{dA@MPrsI|3^bx#cQLJ!&27CeSgVX18f>8`Y!n)-)7 z9?s$0U$AMfKeoL%A*}`VB+j>Q#nn$xsM>1PTt{M%^_)he^_+!FM*YL3-6*n4W2LW- z=&7W)>7H$YYvzLKM&rEo8yvD9NE9!aG{3jB=j4kWEQlE*@D>#X%;#(fG{WJ^H!FB~ z`yTSbIaIy;0>iS&WOwhztWiY2ANS~euEIb>R3a{rT}JjhE%vSr?z4F#Di?*WNRLGS zD_ITxICSa~X(TiWbV5I7wKek!mqld?1Pf{L;7AN4+#gN0!SV=pEW9>F!P>=Lmj{*8 zO^tYe{^&o$)}uaFvue=~cY87!DPm%6G9R|t?@wJ=geQu9b3+x*WY5{zM$aBjUEslX z9|%dNXNEfZh|SjfcE_d|vJXg`X5sB={%xQUw9=k+o3777+xz}4z1Ed4hQ$BO(Y51h z$|OBd6{4~B_3VVetrm*rsS@f;Z+%fi!ud6|wvS>{HfW71Oi6yA(;R|*JZ=12TUgXs zHnSf;ovn$!y+FM)dw9WKt|oFBBT$LF5LS6&H`#MB#)*(b)cx;^5F%o~xp>W~^9S>z zM^aHMaqoqLyizy~wg=0nT>#K3kzIsj<(~8@2>Z!gZxXkdGuvD}*4_$ug3Xv{>lG`i z?f2uyr1w!+Df!(L$HUz+9C~8witg=IFWoP##=46=d7TH(eJDtiEPf`AJ3WMUbZxpT@!m~ZEM z;unukEgsuykQP>T~owx~fV!b^JNW%yzAE|Uy=)0eW9*8`B z<^x%Ds#+>OM4w#V-!9m9lWH{zV)s|wBgZz6b6lzQV{%E}D->jp1oTO+u&sV#t0QU; zg|4!+Sp@^+?$M$(VMxS^5 zY8Z}VPr4Uu7akHHXO{72Z(UWkGZ6PRR=jTN&rTlOuKoZxdLYfyvHq&`=HK+@>gqTW zDlWP9EFe%cEcYspNKY<|p9FJ#;SdWjvHtly^!IaRH#A&)Yp%NeJw^zkdF-}*^yXkn zXf!cjmB+kIb-OutHX#3it<$7?>@rkueQsS5?~D~&Jx?^qrlp44T>UtWiqO;8kO@T% zzUqlT&ftUx*)Cdai}>r`=KzJOzbPE!(X?$ktns9_`&E58tj=#oN8g9G6ekG@W%p^| zYiQ_LqL|C^6(?KmF3dVlc)UQ0cuz(D<{JJRlhg4Py49Iu#_*M9)`$e0EsglB)d~f@ zPU8(<9dcF;au$0_2uohqBbOtwg;8fHe=xc|@)R|6Ds#tTLWw^*tp=yXyx~~#WeD^{ z=6yn$WZS~~!h+8Q-8hxh^7VSOXqKtKThcHfGm>BelkqC!XH8G07Ahuy@cQ$AU6rFUC>*&%v? zb1QaDF*`e#{)IaH$EdjfTg;%h!%zjamH_GzDMS&3EK`DQbhaRB^3F2DJq;0`yW*jn z`I9wl4AKQbr{qDGq(QXn+Xw?%8Y&C)N}cMDOXoXf^$es7sSAeUk4sN6x88T`+iS54 zA&7u6;tR->M!t`y;k z&S~UOfAsS;!Fey;aYXp%i6JIlyobk2zVo}eCA(X(r`Gs6n?Qxq?vqa$GS{T8Efof0 zqX5;wNUJ7d{(yz->+8!;(gH@X)umzF^_OJvnL<5kOnf0uuRuz67(TCS6dS=|+|ez* zxBC~;)X|WK9VUM&2@)sFa7JmG{5XD1znI3xrpy@tc8PzK?L ze+1V6Q()Cas&Dl>WowpRZ@h}A+PLJGK9Hw{3qhOsxY&SH^nnX$XJ_@TRDT~c0jCM# z>gwZj6j4z#2~qrnp{L6FMF8RzS;N6N{{2Jz#b=&L7N*WUzO)uV&=o8B$ePB(qn&g@ zrN`eUqo5cu(nBE9Ec(n0+}sgKV&tG$hJo-960**nM8K)w+wqgQt;d_2m`xgvDXgjlf{qbgvQ`Y)No@ax{p!dt{0Lu)$< zt4!qET|^aS!>&;B?}q2*_F;`_}& z!ly?8%xGAQ%__l^ckYk3C+Rc89Ip}>^kT{=v%DvuMgA2+)cbl=RJ;l}{Gpdl2+&A( zX2sOFwILzrnw?zbB0VAb^O}GE5MI2XU)kC55x~QARzkBJ!}>IQd<0c$h|0}OJLB${wn6#oF_w;K!>iw(sgHj&7 z?0cPQWtxt6Z8@<`2jyDmkb!h>B;R|=uLFv2-e=^$&1zk4CHncRmQ~`d^g{Qh9t*%F%shk7>e6!|=2irsw`A zNoS|A-Q9s41oCj}zIrjW#^LGGxH>_`P zF|gPm@A#6$;5uY_SU0UqA}b0Z4mKx#qb7VPR8W)*&cG8@4xbHy1a16iG5VCP$sCtN zvGK;N(3pC282_@+F0j=<4<9A=sv|r0*7%7HpVGYrUaNfF+r&f-kl~Zo?v`JAS?f~r zas1<5UdToq*-X=O55=6%DbNq8WNw$i)-k{G^M|BMxz{S56GV3UM26FKoVxyf0M(B`hqW$p#;KOk%{^d?Y|PM7M0e#ZeGld`kJHqk+1By z$D0#_(Bpna1#nt%n-a`=mkEKyAI*0*A0x9r4C3Pbz$DDKu(TmiDP3RL3e7_#Ge4QW zo}WJx+HxmVkZx3TC`VZG75m%SL=3bBp|Wc>*V)EP$sjR*t{%6%0b4zY1R_B309P{^1j~K@PNm}_Mzm10xVT=i5R{wj+t5B@; z-9y#F)^@3opcj>M58@D`@Es6Tx1A8~A3ZB80yh7ChIz(DwmE()@`x9HYafnfD;&Q7 z^n;V*W~SA_EbrWp(=+?iPJERrGt>l)QrVWjpKa#O=u*RGqu<%c{G&lhpyi1ktD9xo z`l{&vJNE^Jz(l~h8jA3QC}ha`rMai)X>aZ?OQ5eh{aJQUTR+&0$0i!V*32yDRzrt{ ztuyqy=KeHuXqz{F%s?t|z8_`x+AS|TCo3W%pty-_^9vmaoPM=s7!X5N#B+&_qh(&PI-e^iw0Di!?s-9+zAXg1b84Z=$j)K>vHGi=Ee^(97y6AnzJd^f-$LV;KWBYd^DJwfa8a5pR&P@ zR0OmeJVRIaZqEps$J7|m^#SJ6ZZh|JHPT~iWC&Q8vjFDVwhA=@^cYK$@It%l)?>@M zbb7i%RG-Tn1K^H9zlsJ-i4j6$%y{AW<{@9dyErR>-j7f?J1&8@QH8I*gT-=P%$EY% zn)mO$I6fyB#HL5_TYTlyD6uNY{LDTbpJM5!_^Bi4<*MZ|pmOEqr_q#@j0(>;J-vVa zye=WHRsTixYzCs8?J{H)6g{z|lrb zE$dcqMV;7h_w=CB(~DX1zR1A9-?kZ-RaN-x9do)HDEqU4?+!y!%2Qh~PG+tg1e||g zCIx_6mG7IMBIEW-zIYWqE=z!P17c1n{ut4km9xHyoMm*h_@BXz-CvpQsx2qH9lB8) z`;D0S(}e0-xYd(qf7p1k68b7hY{{G9U@_Z3OsV1YjjFpfh~Evul+rYG^-Z(vKKC|i z8rm4ddlT8Lozs6r34|su?2w&{M|5l?M)yi{cB_}-u3F&2JRjYAgcpXr^Ox%J5ld?k zfJ7m#7sKJ8l68)g|8I2&g5k!S6}F#U%}K(-kiyEh^)ll*+~{b=-BtYz#7we_&WY^J z**~SHV0;UU+Bld9}?N!X~Lgn4Kw9RZ#^!!|0szBmseUE33w9)mo`O295qReeACQcT5zqN zO>7$-@q6Gh%k=2S`&3y4W-t)I0srw@=?;$mgj{|B0lD2aweSQy$k+W4(RMp^@dp?;$~aOHRIzXnXDkPWNuA=Eqm~CBpMwT*r%^dUI^q z>A5EnQpy;1Xk6{XQ|g-VIdy`#o|of7p?u}#7G=hAq&78_f5+~|NP9L~{(~#DcrQey z*dWV%%%1%q;RwnrNSk8e%*?80Y+oPq@o^j_dz|g-gHGQ*oG8$IRabu~InfpEw}4g( z11CLak&s|0=mG`sNzAlq|18PmvTJ_h%^lp^?~q7*l7AMstFjgC5Vw z4g2vx-;>d{Z3mL!y1d~eb7nMtt>Z7XzSOtWV-Kr25Y|EGud3%a&x};s%KY`e6`;BhXMEKeT>Ysec z|2K6KTF$83^J&yo<(QAv7XGpS1+cti4hTUeNE49 zpUw7O^}%i{Z6z#XH$`R+gw7=X(TCHi&ttHL6)#(v>AJ&;n2j>fgC!9HDHYC>faVZ* z< z*$rxPvO=}DmtP*eQGV{mz#}>$8d5)x*rQfn;=f>!%j&ng-w2(mfqA-}hpYm)dY-eB2xWN}H>B zZBo7b<#0MfMtbo!9b2GDRzW|RdNts>06*^-TUM8CAN(%_wdMXs+$hV=w-uH`gmimK z={_~BV@lH>C}lfdB_f&rBqk!6t}H}r4~?9P;CJZo)6{1G6uO-$m1xtIQr*|KIUWDe zoJJ0hzk9PdQX%Gl-0Xi=@OJVorG`8VnD-2&<;VmE®w_`d`gV3yjY{|b6NDG+(F z+Dfp*;kmaQ( zgpwxhnx_R<$?z+(zcBOG)xj(O-onKv&u}*Y!5QxL?cP`t?_fsj3Ui*C1C%hkGmf%^ z$sYlM5zvGrsp|LslzMZq9neG{PhO9SWE6y`=nDqj z1!%~VaeKI+f{24Yh5YfiTrykv1_s2|_N4heH8s^wYtsen8*a~)!^|IO3%vpGm`S1{nVrYa5Y=)!`dfCh0Rn_j zm(8`DmU7cSLw9JQWpjCopTxDauI}8wxVyF3n_>Ml8_BFdMt#r0e~v37)8hNY#B3_$ zfiq(6_mhS~fUxGc4Uesct@)l)-)3G`xg!LX*ly=n;_61Ce%o{7)XTJ^xpdD%0pY88 zN1%RdaOcWZOpDk`_r^Qh929y|N=iX#IE}EoixKkU;>s85%vWuxvKDu*Wq)CRHfT+r zGsd%^_-41J$(cGl94Iq+59(F4XZ=7A0hE}QjKol{eFad^uSSB(p%@Qe|YfeXzUdkFO8W_f}7`qNU|fp^x<*l}Vf9 z+x02ZF!KF&Fc*A>P3K}`N6!dbQY%|?u*bB|Ug&g&f1a-@{yN-FhZW!F`(0)kyOOSB z^qwFm@QUH4{V{Onv#wIpE&b^DdN^PK5W*Kt=Ch=>ysY-QhX2llv}W;fB?rB-yu0EP z!NZ`?HO(u*do2H}?Vn1ryc+5MDIF%=Eqm|wt=`ej?-WTXO#&|2>5S}b*t}wRpL@)j z(>GHG35bU|Ug1ztpIgzuFOQy>l zZ<11~->-5khf1P!O3D!^VSpbBTM(z(Eg3Tut#Kydl|mLJ6|7d}8?C3syj)qg74JK1 zqvgZ=-$6!^ufNp&tRL@uyoS4;YObq7cMxFrU zy=`(ee)9{8O^Y-aD0ZEByyvqX2J_rCP`)Xl7=tPHpceiW#~_Mi2NgY5RGB@$`p=xo z`J@hit(U+6ol>0*-51L12quiX^RW>$^2N>1gd`q?-giNn5G1yO6h63@FIncUZ(wYj z7@}UW8L%>c(y1vk?KRjX-rWT%GF%^oy4kmEFwIY_1A6?<$ONJ!0QNE5Rij{6){+33 zr$QDC2C|Hdoa=`~Pa*)daLWfu1nRPl>NGdOUM;chr({kr0@elnxsL`&wEuEHk*SVl zmI8e>KffhjfzQpagDx~gMc+FXMm{U?)7eU-&m^o){;gTn7ESH5|9%xqNjVOSGU+*JN?!^@FQXL%yo@TU$)hH`Q zs~s^1%AqYXb{luqdc%Pp&49gR9VTAk=PqFSe)*uNT8qN@>`>y z!!$xH_uUC11dA9x~48ZFS z`0DB)!=iXv2~`1*Gp=>N3>n~XA=J4u7)Bd1ePBJn+b-COB zOAF9)ePUf*n*X_O@THk|H`sJ*F7-P*Ee}^Hnt63_l|*j$_C{nwCu@>%^eniSe+YP? zVNv_LWS0!c!9|17zndPaV9~`=(IH4^8iIv7xw*)=cmhh?(Uu*gdWqHR$=mxmU+WEDh<=CA(S=MtUcBI}$q(dspoKg__2F0wzUgL@8?t=7 zV&8x~8uHxV_^-y)iwhKvpify|Ny+w%Wby~mv%DL~#P&*fr2@aa3t5j9>zWKh0(w*M z0cb3<0bS0_{V)9N*Mb%h^RGM~E^=$xfhrUOd#v&yi;Rt5%WElG?5RlVeS(`g5V;s# z9SR=S!_*XYpg@|MN?bo!52-0bx|3fI!KnUDpV-n233?7ayH|(7E6Wmz2iIt$Q`U0` z4Hw^mV?#{$ZL++RN~0F4|17yu^r7t=Vz$d<%~42wBVW^XHWYB%5b*yd7QK&zPet9%Octy%~{j4aaLGWQ&Ab33uzBsp*D@t z;ff|UalgK+w`yM=(cIX8;W9&7n}e{MgeeOocrEV#+^YpCrV8YQVoCY_GEp`1ki--x){S~laCA$%ViX;?S7!J_$ zZDQ9+65(mndK-T12*LRn(zb8GZIUZK4(05V#b)J47ohds?SNMv&TO6y_p>{i@dgBxvwK}DGV3NqJ_`|hzicY*f4-toWyBP=#DhG`^_1(( zqJOUK(_*6yrn4~jA_53Gx4#NZ+#tFbL^T&;YTEW-)E>lh*XZ28fkq_<&+Uc+rxKJ| zau}ud?OPj=B1q9AZJHsfWgl8y?qf8Z$O@Ycqe+1J#kSEInQy^~V03g&S=n%R_t3dE z?B*=3+VQZ7*c|{W{X1i}#`Omz8CfPMe>Y#vg5&nY>nl zTYMj>zosAhn{X0B{%-kVyaGuHB5i zmo!D14NAFtI2+ zxFf<(WH5s2{ny15IOxE`BS8(j5di{x$m#u1@>(O;QR7vxV^C-{?DsU+Th&s15f!xr zhy*{NQ&_CR|dJ2w--ev$C&PANTG!2#n;bM z%myW%Fm)x-gDEk?A)YQVh`NJrOoNE!IBYwj1Me7*-lflkHB1B>e=d? zJOY?+_uk87q6Aq-RU;(ZOe5%VgwPVj!ik3junQg=P5YgMUcM1@ z-6dnUgT%b*f@q&jto)@R?|eX9&FGYg{sCKQ!SiM)L#}tG;==aLuQEbmf+`=M3pUX0 zgL?2NFI{Xl$*lMLqm>oMP%4AOyC|C_)O;NIx5S~M-cYvg`46v6IH55S0b}PoH5DK& zQ=xCQLn$7gC9*LxI@Ybl(l|UETuf=rVj8pXhez3!3JiuXv!@=(d@AJHTWS_VGe@UD zcU=x>8Z;Q`D^T{={n=_ZP0q2K6Klso^TM^%V2bVM1g~IoN}ON)R0-u)BwI%{i{}NF z4(;xvI+S3fZsqV-q7!j4&(^leavS`@NfcpA7-rp?{hD?utMtLZ@Gzc_Pu)iO-sM7A zBvV&sq^UwkNK_Q#*RN`>ySQw6TSLKn^R;;mj)=duhNZrI2`oq@5ibmW_bXtq%*ZZ@ zJxhiq3yP*UlVZF39TUNcixz;wNj&`x&K5G1l#~F=r(QkrO^WV3c)YK;CYuOA@V#y) zH{3WxYrb~V{lSY0u1efIBEDPNHy|ycfrpGnhO<;rRvCQI6JN)QW?(???Pa)kguc^w z_^SM4@aGLYwi0wS$1MkY`dx>2Gp=xuD%)Yu0mHD`MC=@?Dst>+{d>-}y};I>k%#OM zF;Gg=c{A#<4w}N}nm+=8jO8i>7QRLASoigxk-S3;UAu;AeAjSW4X1-_-y+J9iN!F* zibk}xhwAvWFTqFrDCflK?v_gX`a--KGx{%f>}$$hD>4uH;I_7==h?binmVe_Qq!h* z^$Nnu>cBNMBK&_9_MPEyebKu|?>)LO(Sm5vJHsfE5TZtn7NSQ&ln~t@TBIYo45B4O zH%b_Sh~7IfdWjbGzvuow-RHUG>zO(G?0xpyYrU(zhlQiAXw;@SQ+a*?|7~eV{7v}qdubVtvZOoa?Bd{ndDwe!0eQ!ch@8{y2L#knCEQ_T850aAfExCG-WWT~ z+(g!$3XPCeBS^iJcDiLhonQ^wo?s%8%1xPl2yyu~#L46lRtB7{KfM>jT7+J=0H zV7AeTEZZiMQ^fG7qIchpXV6)4)a6t-99VK#xE}9}6yH`fZ}7jFjcnkx^8zC;s&p3emI!it_H1c;GA3Lj=C|9ty1%gP zjBCXEt*&@6{3MkkMNWmG=LfL0NdCK~c6*M~#D+vf!^k8tEua)Y8=<$Kj0!)XLc-Tx z`(EdzRy?d;Vwz?}(jJP}n;26hctgWUE84~lh2W2{^p_KM_sHHq@Yu5eyM}t^HC>zr zx(SZ|OnQln!e}pr$S`c1N!WWxbVitt8-y}<; zqSr=h-B~z!={v2hZ@Ns%Ubp)c5Uxib079D)RV z$s&lUTB|S5iPBf5Qa5w3iE zIjFxzh?mbSsy4q#b$RT6d~wXPp_Qc7@uyc#(Hlk&8a$nhZfh{m0f3i4^}4Can}VY4 zefK-N^%atX1omTjSTnZLhnQqd0)zxAcw9;Lyh(24(eU6oTP!!N>ii&IZL8rsi>n58 zyXhh0_Y$vNV+lBubEKwD=ulePn!fS2kb?Hmp+j7a*08?3yjr_&A|DHM{8#o;nKMPe zV3gmJsme9GeaUH|$#)_6kAa$pyfxT8(wAx0A%EZQiVmoG#!yFm6R>FY+%P}RR3Ivz zXXZY3Oev>EH+&sxm; z0wE+?jpdZrX;(bvI-{5`_bG4A#%lPVtbVr450TM`Zocec9i!y@5|sPBK8Kqx-|#+w z|Ew@1%K8e20x#!{wGb6n&|Yi(Dl?O-)TTbp%qD=SIuAW((xu@~V<(psfeM=!G{mp0 ziDY?>T&Y0NBW-zOcJ~MGE}kT;zn5^*EgtCus`9wKy#*{~x3O-ET;n4pZJ#R5(tEEM z1MW2i<5d1w)zm3mwX@%!$21m{j9 zLtr*bZ6{o4AkWMot2Z3M4L2~L9VxYrk7c<2{r>sVuU{+y8!V+gA0k>ovTf^=vbSyB z5LP$$F~YbTLR> z2JB1S>^JQR54UHNdV20`%rvqG9c{HAMA~{6N@)q_RvOwjH{TF2^qKXujh zoYGEn7ii1`KCM$`(^&p=^2pDQRi(U-u-=4kx|L8v}joqoNh) zL0(k#k|WqAkW5}=YPR+9&nu){&qMj3q4Se#4&6-Y2ZvgK7%W#pq{Kt$4q_Tm5%^jr zCML3|JeRYwvg)yBRO4=Grec5K=2#`;5JH@Mve&(%>_d2nhet_^7?yIt$%+Zc$otyiZk_-)*WoonH$6EB z2-`3y6Fw`R661ix@XjDt<1efi2MJwVGWvL5@fTQSTfSI7~7u`w~-#dQ%Qt5Hd<4~PjH=i9KQCC5XJf+LHr6qyjM;06mHjV6= zV$AxrelTi_Io(EkeP01VHU_{0_M`)JF`d09k9lLQVu2An+hfP0feJF%~7!Fw*k!a&gP6 zfF}<|iXRsj*TcjCH4hFl`1$#5URX6kyB+KYc-%@HoHtCtzWBm{Ua@a!Y0+7QdIyBw zkS}&5XgqydIlcy1YQjn^s}~m9;|&Up!Qi!p;St#&#nXQME;pY9{fEhF9=8>JV$vK@ zqyu;f!*WW;FfC3+V)T0!IpD4IY)<+*z(Dv=hL7)0DJNYO{&$cxC@!X;rLu&n=iM_V z_&wD`wZHLbONhQ-**>0tu8OsSXkqEr($Q)JEA;C6o#q5k@~G+awYFFrafG9HnMeou ztc5>4Ew`a7czAW9FIyrW2hXd6Dd+>TIpjpICbSiF)VjTNOOBA}+WKPBW6$3(+^@Ke zpU40=1Cb<0r(Vw{r+x@F4*@o>)14zcd@g8-^vvD?2&DqqFTh&#?a6yNx+d+!EICo? z!jzQGlVbd(C?dKhoA+7>L+4Hw?8kbBAPK*20L$6SE|gC7^=J zq3*U@KpbYiGBPZ>|T|wp#rD>obwtk6v(N$q76)(%3n5U)9eFa_NmxRV{5^u zuWyZ7ROL+kXUGLBM4SAYaQ))E*NR7iv0ey?>aO5YDnJr|L*r zDrOEHC<~XTesyIGVUr~OM?x*d$_A+c#J^9Y`a|B!Yw5-1`T27)#8oCsAcx&wX(%JN zX;ib8_8*;#zPz3piTU}4ze+97Yb`a+IWho*48ZSEZ5t{K)9u0SX`yl>rcw@ z4Z)`nT+P>zuJl(1MJ88BsE}NZ2pW;&hwCe~w#kJ+2U6!uWBoW}Xl;&MGAaJ?cP5_6 z4nzx+C&pNWK@A^0upa~my=lKqO}Te#SH%BJNGAqmiAGs7B8EJMh)BW0aC#jaX2fU| zuy(}t;yz8s_|p0Lb#9oXn4^vay=Y>{;NW-CDqXle-lGeSv5$6r#2bxkzl>j12+j&aMaf?fBHny;`_#^Z3^0p zOBZz1J82OYQBYhn5r94Oi{3;TVt3!6o9$W&BSuY~oELwc96-%Q1hvI(#h~%D4VUh-X@d;?mq@>W+5+fjwnn?ecxFgklNg$^ z_S=(hN9(|32lixoRo=mEx0rcogBM!*xK`mN9e7PJfJXN%YG}_#OCow&;AJoQWtppI zgPEZRt7~x|2k!AkM!{1v%gjp82KWGKqex=BF<14FN@#Gvd$|H*5O~oLQX9{la(Xb@ zIaAA^LPDc%|ETct-*WfD-wjNn=IXz{H5K01B0sWK+|l%rh|^D3J0am}J|8xluktJD z-;TIx0)mdDRGRbiZNz9*O-$mo&CTkYJF}Nsea@e1S5^$VaYRnTU%6zd!QRHMD1Y+D zuYM~M@jVCs&FX5++#*5Ja(6%INoP7dJUZj>aN-L|lOl6MpA$pLosQm=WMTHrkPaic zab7_V&~GNJtf4U2lSvtHiE^quyDNwZgIOGLD_bpy2SEicNn+q#y-rso0b2~gJT@)H z64;`amb)Jxo%rf_xIb9grumS|6SufvU~NnY8bt%IJd<$`Jsrr`QxS7mH=P!H3J(od zgE+WCSnj#GUBPtZz!ccj^{57B0x5StFNW^Y*}L|=OkP(H#3v)&XZ!boeLuF{7qc2Zsi zXC#Lo=UMEWA3f&b#)k~ve27gGYmCg}yZt~lL@6Ek*$z6S?&oI~m3#9UFV1gMQjOTy zumtQ2d}(ah|LJl=C>bakPxKKd1OpbNUrd5tLR&lH=!;t|w)O$u3Hr3O1~SpRMJC$! zDItg9Is}36oUvRN80dX;+&dz%5GhsOjbvd1en&^Lb^QZLN2E;!P;`ia zSA4WmY`kSwWT(x|Zdd6cuJ;zu78M&l-{XDt z4p1rPYA?S2CMgOE`S)p5)Rr?8duJqp>Dl$iZcQhs6J(uIOs;1<`_bq6v)eG_ps4>; z;Z8b=f`H1jq_Vs^W^~ePl$o9oVEvbNL5Ij}JcyTxiKWuFc` zq@d8r)Vr;c68Dtu+I;W928W1w&8mRy1~etpQ*%$S2Du>20gkaOfc7{h z<(Mtd+Dd0A8K{kT(6ii)Jv~Be{8<{p{#{$JUji69EuMMtWeka^URrcL85!|*ehDfR z_@aTJ?F1ZPn$z9IwCANiTJb^PYau}I{)hg+K(BH9SgRRqaD9L7!NbTJ^obDf*AA** zK==gMC|#t!8@@Nr7N6kmUukDk$x;>f|KE__{5c_3RFJYRlJ_9)e{go!$&)V$evbwA8w- zmG<5Ew}f9T6(GVowBxNA)lC>nRZoS1NHz!j>3O(q8L&dV#m}pj z@tzb|DFO6Tvi9BG-!qLj-qKZ0@RwC@j1OYT-%weyQ2HherA$o7SeikAM@81Mz>d@~ zt)@2s=qp!Of>#Jp%;t;B`f)d4o@`!BA#T%DapDf%DeQ?)_1E^^E$O zrPu01S(mDss;7eK&OI(?x2*yBxO#YaySHuMTJrHPwV{f+ zmAYfOiM;@FA|U^a8u%slwZMQ_QIf&CK1e2P+u7l@gYKTI(&WDeKl1?L1j^fO;M-)X z;GiK99Hn~GZdgxEmKf21$o@^iRp8<}LiWFw#ZBOOxqZ1XvbP*+8V^j!OT4N&?}AgZpye1q&=$Khe-I|zw;0~CUjzpDwdFz&^RwIs~~Tw ziD@!t1bD{?1o0RNA+mQJgf_5DN)m>80kty{T{00Q@fgkPcjGVsHn37r0dWC-EOJF; zTr9VQkyFLJk_b_3I@*_)tg|n3A))mLYmR;x0n2J`_8COKYj`e?Q-R=svTs~ukF*1; z>lo^LdEuQQsjY;Td7<)C%+~Wz0iFxr`|7kH77$e}yP=gpuL|O+SCT~19yRsNR8gq= zR{7fuhK09H7n`+Hl~Hz$eI+uve;BM0j(C!_gQk90vM`igJ}NE z2FL6tu*-L3U&UEM>Fin6OEL;YMJSYCj7Ak$C!p&oMJ4h~iVb~Eq(aCj5hpQRaoa(q zR)wH{ z^n3uin$*Mu1lEZ-MwpGTi>Q$7STl6{Fz;ksr-nXgL@e1QN>a?~JcU;l8x){uaN|=aZsOKA!Xr=&M_~-3G|(=@>c$fuUlB0Nx#_L)dBV2K(LV8W_blN@@fVJ_p&b)x3flVFDI~)w`FB1 z$7>nP{`7mA$@uC<&uGJ-w&lji+FnSF(r3LgSdqoD=#%w(LUi-1&ZtpGAn ztD`_Kup2SDYuiG9eOVs;g833>)skAV!tA)$k z6K()EIg{BY)Tzt{f<{#@?^n;iMuZpj+}RDL$iK&7Rp|bk$Q~K|AgiY4RYiu<8;zK_ zqu1=LVlbmZ@uk$e-a*p}IP*3@!JGvw8ow_KInV)G!m$uMjq}tCN@{^Z7NrGdbn2S4L7i+}z$vohe#9SBJ;J zrw3ec-w4=ttFk~1yE-~K*&VD6Bi+mYqU3k3Ta$eAS=N1G7KXgTYg7mpzjdl|@5T+C zk}nq7T7P&_x+j&6b%aF{JiiQ&J2^RB6BO*48g^lFHo`_ are used to map isotope to hash values with which all possible isotopes can be described. - - :ref:`NXoptical_system_em`: - A base class to store for now qualitative and quantitative values of frequent interest - which are affected by the interplay of the components and state of an electron microscope. - Examples are the semiconvergence angle or the depth of field and depth of focus, the magnification, or the camera length. - - :ref:`NXpeak`: - A base class to describe peaks mathematically. - - :ref:`NXcircuit`: - A base class to describe a logical unit of at least one integrated circuit. - - -.. _EmAnalysisClasses-APP: - -We provide specific base classes which granularize frequently collected or analyzed quantities in specific application fields of electron microscopy to deal -with the situation that there are cases were logical connections between generated data artifacts mainly exist for the fact that the data artifacts were -collected during a workflow of electron microscopy research (e.g. taking measurements and then performing method-specific analyses generating new data and conclusions). -We see a value in granularizing out these pieces of information into own classes. In fact, one limitation of application definitions in NeXus, exactly as it applies for serialization -of information also more generally, is currently that they define a set of constraints on their graph of controlled concepts and terms. - -If we take for example diffraction experiments performed with an electron microscope, it is usually the case that (diffraction) patterns are collected in the session at the microscope. -However, all scientifically relevant conclusions are typically drawn later, i.e. through post-processing the collected diffraction (raw) data. These numerical and algorithmic steps -define computational workflows were data from an instance of an application definition such as NXem are used as input but many additional concepts, constraints, and assumptions -are applied without that these demand necessarily changes in the constraints on fields or groups of NXem. If we were to modify NXem for these cases, -NXem would combinatorially diverge as every different combination of required constraints demands having an own but almost similar application definition. -For this reason, method-specific base classes are used which granularize out how specific pieces of information are processed further to eventually enable their -storage (i.e. serialization) using NeXus. - -More consolidation through the use of NXsubentry classes should be considered in the future. For now we use an approach whereby base classes are combined to reuse vocabulary and a hierarchical organization of pieces of information with specific constraints which are relevant only for specific usage of such data by specific tools used by an eventually smaller circle of users. - - :ref:`NXem_method`, :ref:`NXem_ebsd`, :ref:`NXem_eds`, :ref:`NXem_eels`, :ref:`NXem_img`, :ref:`NXem_correlation`: - Base classes with method-specific details especially when it comes to reporting post-processed data within electron microscopy. - - :ref:`NXcrystal_structure`: - A base class to store crystalline phase/structure used for a simulation of diffraction pattern and comparison of these pattern against patterns to support indexing. - - :ref:`NXroi`: - A base class to granularize information collected and relevant for the characterization of a region-of-interest. diff --git a/manual/source/classes/applications/mpes-structure.rst b/manual/source/classes/applications/mpes-structure.rst deleted file mode 100644 index 9bc056b1f7..0000000000 --- a/manual/source/classes/applications/mpes-structure.rst +++ /dev/null @@ -1,42 +0,0 @@ -.. _Mpes-Structure-APP: - -======================================= -Photoemission & core-level spectroscopy -======================================= - -.. index:: - IntroductionMpes - MpesAppDef - MpesBC - MpesCommonBC - MpesExtendedBC - - -.. _IntroductionMpes-APP: - -Introduction -############ - -Set of data storage objects to describe multidimensional photoemission (MPES) experiments including x-ray photoelectron spectroscopy (XPS), ultraviolet photoelectron spectroscopy (UPS), -hard x-ray photoelectron spectroscopy (HAXPES), angle-resolved photoemission spectroscopy (ARPES), two-photon photoemission (2PPE) -and photoemission electron microscopy (PEEM). Also includes descriptors for advanced specializations, such as spin-resolution, time resolution, -near-ambient pressure conditions, dichroism etc. - -.. _MpesAppDef-APP: - -Application Definitions -####################### - -:ref:`NXmpes`: - A general application definition with minimalistic metadata requirements, apt to describe all photoemission experiments. - -:ref:`NXmpes_arpes`: - An application definition for angle-resolved photoemission spectroscopy (ARPES) experiments. - -:ref:`NXxps`: - An application definition for X-ray/ultraviolet photoelectron spectroscopy (XPS/UPS) measurements. - -:ref:`NXarpes`: - An application definition for angle-resolved photoemission spectroscopy (ARPES) experiments. This definition is a legacy - support for older NXarpes experiments. For newer experiments, the user is advised to use :ref:`NXmpes_arpes`:.” - diff --git a/manual/source/classes/applications/optical-spectroscopy-structure.rst b/manual/source/classes/applications/optical-spectroscopy-structure.rst deleted file mode 100644 index b9f5e11c1f..0000000000 --- a/manual/source/classes/applications/optical-spectroscopy-structure.rst +++ /dev/null @@ -1,199 +0,0 @@ -.. _Optical-Spectroscopy-Structure-APP: - -==================== -Optical Spectroscopy -==================== - -.. index:: - Ellipsometry - Raman - DispersiveMaterial - - -.. _Ellipsometry-APP: - -Ellipsometry -############ - -Ellipsometry is an optical characterization method to describe optical properties of interfaces and thickness of films. -The measurements are based on determining how the polarization state of light changes upon transmission and reflection. -Interpretation is based on Fresnel equations and numerical models of the optical properties of the materials. - -In the application definition, we provide a minimum set of description elements allowing for a reproducible recording of ellipsometry measurements. - -.. _Raman-APP: - -Raman -############ - -Raman spectroscopy is a characterization method to analyze vibrational properties for liquids, gases, or solids. -The measurements is based on the inelastic light scattering due to the material's vibrations. -Interpretation can be done based on peaks, which represent the phonon properties (intensity, center, width). - -The application definition contains a minimum of descriptive elements required to understand Raman spectroscopy measurements. - - -Application Definitions ------------------------ - - :ref:`NXoptical_spectroscopy`: - A generic application definition for spectroscopy measurements. This includes in particular ellipsometry and Raman spectroscopy measurements, but also other techniques such as photoluminescence, transmission, and reflection measurements. The requirements are: (i) an incident photon beam, (ii) a detector to measure scattered/emitted photons, and (iii) a sample. - - :ref:`NXellipsometry`: - An application definition for ellipsometry measurements, including complex systems up to variable angle spectroscopic ellipsometry. - - :ref:`NXraman`: - An application definition for Raman spectroscopy measurements. - - -Base Classes ------------- - -This is the set of base classes for describing an optical experiment. - - :ref:`NXbeam_device` - Beam devices are used to relate a beam, which has always at least one origin - and at least one destination. - - By referencing the beam devices with each other, a beam path can be - constructed. This can be used for vizualization or beam propery modeling - along the beam path. - - :ref:`NXbeam` - Beam properties such as intensity, polarization, wavelength or direction. - - :ref:`NXdetector` - A detector for signal detection. - - :ref:`NXsource` - A light source such as laser, lamp or LED. - - :ref:`NXmonochromator` - A monochromator is often used to energetically disperse the scattered or emitted light. - - :ref:`NXlens_opt` - Description of an optical lens. - - :ref:`NXwaveplate` - A waveplate or retarder. - - :ref:`NXsensor` - Specify external parameters that have influenced the sample such as - varied parameters e.g. temperature, pressure, pH value, beam intensity, etc. - - - -.. _DispersiveMaterial-APP: - -Dispersive Material -################### - -A dispersive material is a description for the optical dispersion of materials. -This description may be used to store optical model data from an ellipsometric analysis -(or any other technique) or to build a database of optical constants for optical properties of materials. - -Application Definition ----------------------- - - :ref:`NXdispersive_material`: - An application definition to describe the dispersive properties of a material. - The material may be isotropic, uniaxial or biaxial. Hence, it may contain up - to three dispersive functions or tables. - - - -Base Classes ------------- - -There is a set of base classes for describing a dispersion. - - :ref:`NXdispersion` - This is an umbrella base class for a group of dispersion functions to describe the material. - For a simple dispersion it may contain only on NXdispersion_function or NXdispersion_table entry. - If it contains multiple entries the actual dispersion is the sum of all dispersion functions and tables. - This allows for, e.g. splitting real and imaginary parts and describing them seperately or - adding a dielectric background (e.g. Sellmeier model) to an oscillator model (e.g. Lorentz). - - :ref:`NXdispersion_function` - This dispersion is described by a function and its single and repeated parameter values. - It follows a formula of the form ``eps = eps_inf + sum[A * lambda ** 2 / (lambda ** 2 - B ** 2)]`` - (Sellmeier formula). See the formula grammar below for an ebnf grammar for this form. - - :ref:`NXdispersion_single_parameter` - This denotes a parameter which is used outside the summed part of a dispersion function, - e.g. ``eps_inf`` in the formula example above. - - :ref:`NXdispersion_repeated_parameter` - This denotes arrays of repeated parameters which are used to build a sum of parameter values, e.g. - ``A`` and ``B`` are repeated parameters in the formula above. - - :ref:`NXdispersion_table` - This describes a tabular dispersion where the dielectric function is an array versus wavelength or energy. - -Formula Grammar ---------------- - -Below you find a grammar to which the formula should adhere and which can be used to parse and -evaluate the dispersion function. The terms ``single_param_name`` and ``param_name`` should be -filled with the respective single and repeated params from the stored data. -The grammer is written in the `EBNF `_ dialect -of `Lark `_, which is a parsing toolkit for python. -It is easily translatable to general EBNF and other parser generator dialects. -`Here `_ is a reference implementation in Rust/Python with a -`grammar `_ -written in `lalrpop `_. - -.. code-block:: - - ?assignment: "eps" "=" kkr_expression -> eps - | "n" "=" kkr_expression -> n - - ?kkr_expression: expression - | "" "+" "1j" "*" term -> kkr_term - - ?expression: term - | expression "+" term -> add - | expression "-" term -> sub - - ?term: factor - | term "*" factor -> mul - | term "/" factor -> div - - ?factor: power - | power "**" power -> power - - - ?power: "(" expression ")" - | FUNC "(" expression ")" -> func - | "sum" "[" repeated_expression "]" -> sum_expr - | NAME -> single_param_name - | SIGNED_NUMBER -> number - | BUILTIN -> builtin - - ?repeated_expression: repeated_term - | repeated_expression "+" repeated_term -> add - | repeated_expression "-" repeated_term -> sub - - - ?repeated_term: repeated_factor - | repeated_term "*" repeated_factor -> mul - | repeated_term "/" repeated_factor -> div - - ?repeated_factor: repeated_power - | repeated_power "**" repeated_power -> power - - ?repeated_power: "(" repeated_expression ")" - | FUNC "(" repeated_expression ")" -> func - | SIGNED_NUMBER -> number - | NAME -> param_name - | BUILTIN -> builtin - - FUNC.1: "sin" | "cos" | "tan" | "sqrt" | "dawsn" | "ln" | "log" | "heaviside" - BUILTIN.1: "1j" | "pi" | "eps_0" | "hbar" | "h" | "c" - - %import common.CNAME -> NAME - %import common.SIGNED_NUMBER - %import common.WS_INLINE - - %ignore WS_INLINE - diff --git a/manual/source/classes/base_classes/apm-structure.rst b/manual/source/classes/base_classes/apm-structure.rst deleted file mode 100644 index 79f90e42ba..0000000000 --- a/manual/source/classes/base_classes/apm-structure.rst +++ /dev/null @@ -1,284 +0,0 @@ -.. _Apm-Structure-BC: - -===================== -Atom-probe tomography -===================== - -.. index:: - IntroductionApm - ApmAppDef - ApmBC - StatusQuoApm - ApmParaprobeAppDef - ApmGermanNfdi - -.. _IntroductionApm-BC: - -Introduction -############ - -Set of data schemas to describe the acquisition, i.e. measurement side, the extraction of hits from detector raw data, -steps to compute mass-to-charge state ratios from uncorrected time of flight data, the reconstruction, and the ranging, i.e. identification of peaks in the mass-to-charge-state ratio histogram to detect (molecular) ions. -The data schemas can be useful to generate data artifacts also for field-ion microscopy experiments. - -.. _ApmAppDef-BC: - -Application Definition -###################### - - :ref:`NXapm`: - A general application definition with many detailed places for leaving metadata and computational steps described which are commonly used when reporting the measurement of atom probe data including also detector hit data, as well as how to proceed with reconstructing atom positions from these data, and how to store details about definitions made, which describe how mass-to-charge-state ratio values are mapped to iontypes in a process called ranging. The structure of the schema has been designed to also document a simulation of an atom probe - experiment. Having a combined schema for the measurement and the simulation is beneficial to document that - there are many similarities between the measurement and a computer simulation of it. - -.. _ApmBC-BC: - -Base Classes -############ - -The following base classes are proposed to support modularizing the storage of pieces of information: - - :ref:`NXchamber`: - A base class to describe a component of the instrument which houses other components. - A chamber may offer a controlled atmosphere to execute an experiment and/or offer functionalities - for storing and loading specimens. - - :ref:`NXcoordinate_system_set`, :ref:`NXcoordinate_system`: - Base classes to describe different coordinate systems used and/or to be harmonized - or transformed into one another when interpreting the dataset. - - :ref:`NXion`: (about to become replaced by :ref:`NXatom_set`) - A base class to describe molecular ions with an adjustable number of atoms/isotopes building each ion. - For the usage in atom probe research the maximum number of atoms supported building a molecular ion - is currently set to a maximum of 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with - which all possible nuclides (stable, radioactive, or synthetically generated ones) can be described. - - :ref:`NXfabrication`: - A base class to bundle manufacturer/technology-partner-specific details about - a component or device of an instrument. - - :ref:`NXpeak`: (about to become complemented by NXpeak_fitting) - A base class to describe peaks mathematically to detail how peaks in - mass-to-charge-state ratio histograms (aka mass spectra) are defined and - labelled as iontypes. - - :ref:`NXpump`: - A base class to describe details about pump(s) used as components of an instrument. - - :ref:`NXpulser_apm`: - A base class to describe the high-voltage and/or laser pulsing capabilities. - - :ref:`NXreflectron`: - A base class to describe a kinetic-energy-sensitive filtering device - for time-of-flight (ToF) mass spectrometry. - - :ref:`NXstage_lab`: - A base class to describe the specimen fixture including the cryo-head. - Nowadays, stages of microscopes represent small-scale laboratory platforms. - Therefore, there is a need to define the characteristics of such stages in more detail, - especially in light of in-situ experiments. Many similarities exists between a stage - in an electron microscope and one in an atom probe instrument. Both offer fixture - functionalities and additional components for applying e.g. stimuli on the specimen. - -Microscopy experiments, not only taking into account those performed on commercial instruments, offer users to apply a set of -data processing steps. Some of them are frequently applied on-the-fly. For now we represent these steps with specifically named -instances of the :ref:`NXprocess` base class. - -Several base classes were defined to document processing of atom probe data with established algorithms: - - :ref:`NXapm_hit_finding`: - A base class to describe hit finding algorithm. - - :ref:`NXapm_volt_and_bowl`: - A base class to describe the voltage-and-bowl correction. - - :ref:`NXapm_charge_state_analysis`: - A base class to document the resolving of the charge_state. - - :ref:`NXapm_reconstruction`: - A base class to document the tomographic reconstruction algorithm. - - :ref:`NXapm_ranging`: - A base class to document the ranging process. - - :ref:`NXapm_msr`, :ref:`NXapm_sim`: - Respective base classes that serve as templates to compose the :ref:`NXapm` application definition from. - -These base classes are examples that substantiate that data processing steps are essential to transform atom probe measurements or simulations into knowledge. Therefore, these steps should be documented -to enable reproducible research, if possible even numerical reproducibility of the results, -and learn how pieces of information are connected. In what follows, an example is presented how an -open-source community software can be modified to use descriptions of these computational steps. - -A detailed inspection of spatial and other type of filters frequently used in analysis of atom probe -data revealed that it is better to define atom-probe-agnostic reusable concepts for filters: - - :ref:`NXspatial_filter`: - A base class proposing how a point cloud can be spatially filtered in a specific yet general manner. - This base class takes advantage of :ref:`NXcg_ellipsoid_set`, :ref:`NXcg_cylinder_set`, - and :ref:`NXcg_hexahedron_set` to cater for commonly used geometric primitives in atom probe. - The primitives are used for defining the shape and extent of a region of interest (ROI). - - :ref:`NXsubsampling_filter`: - A base class for a filter that can also be used for specifying how entries - like ions can be filtered via sub-sampling. - - :ref:`NXmatch_filter`: - A base class for a filter that can also be used for specifying how entries - like ions can be filtered based on their type or other descriptors like hit multiplicity. - -The respective research software here is the `paraprobe-toolbox `_ -The software is developed by `M. Kühbach et al. `_. -For atom probe research the proposal can also serve as a blue print how computational steps of other software -tool including commercial ones could be developed further to benefit from NeXus. - -.. _IntroductionApmParaprobe-BC: - -apmtools -######## - -The paraprobe-toolbox is an example of an open-source parallelized software for analyzing -point cloud data, for assessing meshes in 3D continuum space, and for studying the effects of -parameterization on descriptors of micro- and nanoscale structural features (crystal defects) -within materials when characterized and studied with atom probe. - -The need for a thorough documentation of the tools in not only the paraprobe-toolbox -was motivated by several needs: - -First, users of software would like to better understand and also be able to study for themselves -which individual parameters and settings for each tool exist and how configuring these -affects analyses quantitatively. This stresses the aspect how to improve documentation. - -Second, scientific software like paraprobe-toolbox implement numerical/algorithmical -(computational) workflows whereby data coming from multiple input sources -(like previous analysis results) are processed and carried through more involved analyses -within several steps inside the tool. The tool then creates output as files. This -provenance and workflow should be documented. - -Individual tools of paraprobe-toolbox are developed in C/C++ and/or Python. -Provenance tracking is useful as it is one component and requirement for making -workflows exactly numerically reproducible and thus to enable reproducibility (the "R" -of the FAIR principles of data stewardship). - -For tools of the paraprobe-toolbox each workflow step is a pair or triple of sub-steps: -1. The creation of a configuration file. -2. The actual analysis using the Python/or C/C++ tools. -3. The optional analyses/visualization of the results based on data in NeXus/HDF5 files generated by each tool. - -.. _StatusQuoApm-BC: - -What has been achieved so far? -############################## - -This proposal summarizes work of members of the FAIRmat project, which is part of the `German -National Research Data Infrastructure `_. The here detailed -proposal documents how all tools of the paraprobe-toolbox were modified to generate -only well-defined configuration files as accepted input and yield specifically formatted output -files according to the following NeXus application definitions. - -Data and metadata between the tools are exchanged with NeXus/HDF5 files. This means that data -inside HDF5 binary containers are named, formatted, and hierarchically structured according -to application definitions. - -For example the application definition NXapm_paraprobe_config_surfacer specifies -how a configuration file for the paraprobe-surfacer tool should be formatted -and which parameters it contains including optionality and cardinality constraints. - -Thereby, each config file uses a controlled vocabulary of terms. Furthermore, -the config files store a SHA256 checksum for each input file. This implements a full -provenance tracking on the input files along the workflow. - -As an example, a user may first range their reconstruction and then compute spatial -correlation functions. The config file for the ranging tool stores the files -which hold the reconstructed ion position and ranging definitions. -The ranging tool generates a results file with the labels of each molecular ion. -This results file is formatted according to the tool-specific `results` -application definition. The generated results file and the reconstruction is -imported by the spatial statistics tool which again keeps track of all files -and reports its results in a spatial statistics tool results file. - -This design makes it possible to rigorously trace which numerical results were achieved -with specific inputs and settings using specifically-versioned tools. Noteworthy -this includes Y-junction on a graph which is where multiple input sources are -combined to generate new results. - -We are convinced that defining, documenting, using, and sharing application definitions -is useful and future-proof strategy for software development and data analyses as it enables -automated provenance tracking which happens silently in the background. - -Base classes have been defined to group common pieces of information for each tool of the -toolbox. For each tool we define a pair of base classes. One for the configuration (input) side -and one for the results (output) side: - - :ref:`NXapm_paraprobe_tool_config`, :ref:`NXapm_paraprobe_tool_results`, :ref:`NXapm_paraprobe_tool_common`: - Configuration, results, and common parts respectively useful for the application definitions for tools of the paraprobe-toolbox. - -.. _ApmParaprobeAppDef-BC: - -Application Definitions -####################### - -NXapm_paraprobe application definitions are in fact pairs of application definitions. -One for the configuration (input) side and one for the results (output) side. For each -tool one such pair is proposed: - - :ref:`NXapm_paraprobe_transcoder_config`, :ref:`NXapm_paraprobe_transcoder_results`: - Configuration and the results respectively of the paraprobe-transcoder tool. - Load POS, ePOS, APSuite APT, RRNG, RNG, and NeXus NXapm files. - Store reconstructed positions, ions, and charge states. - - :ref:`NXapm_paraprobe_ranger_config`, :ref:`NXapm_paraprobe_ranger_results`: - Configuration and results respectively of the paraprobe-ranger tool. - Apply ranging definitions and explore possible molecular ions. - Store applied ranging definitions and combinatorial analyses of possible iontypes. - - :ref:`NXapm_paraprobe_selector_config`, :ref:`NXapm_paraprobe_selector_results`: - Configuration and results respectively of the paraprobe-selector tool. - Defining complex spatial regions-of-interest to filter reconstructed datasets. - Store which points are inside or on the boundary of complex spatial regions-of-interest. - - :ref:`NXapm_paraprobe_surfacer_config`, :ref:`NXapm_paraprobe_surfacer_results`: - Configuration and results respectively of the paraprobe-surfacer tool. - Create a model for the edge of a point cloud via convex hulls, alpha shapes, or alpha-wrappings. - Store triangulated surface meshes of models for the edge of a dataset. - - :ref:`NXapm_paraprobe_distancer_config`, :ref:`NXapm_paraprobe_distancer_results`: - Configuration and results respectively of the paraprobe-distancer tool. - Compute and store analytical distances between ions to a set of triangles. - - :ref:`NXapm_paraprobe_tessellator_config`, :ref:`NXapm_paraprobe_tessellator_results`: - Configuration and results respectively of the paraprobe-tessellator tool. - Compute and store Voronoi cells and properties of these for all ions in a dataset. - - :ref:`NXapm_paraprobe_spatstat_config`, :ref:`NXapm_paraprobe_spatstat_results`: - Configuration and results respectively of the paraprobe-spatstat tool. - Compute spatial statistics on the entire or selected regions of the reconstructed dataset. - - :ref:`NXapm_paraprobe_clusterer_config`, :ref:`NXapm_paraprobe_clusterer_results`: - Configuration and results resepctively of the paraprobe-clusterer tool. - Compute cluster analyses with established machine learning algorithms using CPU or GPUs. - - :ref:`NXapm_paraprobe_nanochem_config`, :ref:`NXapm_paraprobe_nanochem_results`: - Configuration and results resepctively of the paraprobe-nanochem tool. - Compute delocalization, iso-surfaces, analyze 3D objects, composition profiles, and mesh interfaces. - - :ref:`NXapm_paraprobe_intersector_config`, :ref:`NXapm_paraprobe_intersector_results`: - Configuration and results resepctively of the paraprobe-intersector tool. - Analyze volumetric intersections and proximity of 3D objects discretized as triangulated surface meshes - in continuum space to study the effect the parameterization of surface extraction algorithms on the resulting shape, - spatial arrangement, and colocation of 3D objects via graph-based techniques. - -.. _ApmGermanNfdi-BC: - -Joint work German NFDI consortia NFDI-MatWerk and FAIRmat -####################################################################### - -Members of the NFDI-MatWerk and the FAIRmat consortium of the German National Research Data Infrastructure -are working together within the Infrastructure Use Case IUC09 of the NFDI-MatWerk project to work on examples -how software tools in both consortia become better documented and interoperable to use. Within this project, -we have also added the `CompositionSpace tool that has been developed at the Max-Planck-Institut für Eisenforschung -GmbH in Düsseldorf `_ by A. Saxena et al. - -Specifically, within the IUC09 we refactored the code base behind the publication `A. Saxena et al. `_ to better document its configuration, here as an example implemented like for the above-mentioned paraprobe-toolbox using NeXus: - - :ref:`NXapm_compositionspace_config`, :ref:`NXapm_compositionspace_results`: - Configuration and the results respectively of the CompositionSpace tool. diff --git a/manual/source/classes/base_classes/container/ComplexContainerBeampath.png b/manual/source/classes/base_classes/container/ComplexContainerBeampath.png deleted file mode 100644 index 597cee834c0426bd0e60b1afbf6554a5f3b04a99..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 7089 zcmbVxgT!j8lW(I7CP9R3l4E<2>J5 z)AI_IpP{<#g$8#av2ACx&qHz?7*6{wc9+~vb1nw=8zsvCGZ@1U!ma35{YCTeb^go#}G;SGXdmMbu z&k(dLz+>M0rk*>Sf)`6r0rqXS-WdWA6B8%4ZJE%EdqQPyjwzkRB;aOHTl>4)o5x|d zk^nCj4;eIl%(n^F+aGp�Z2d70QK#NZGhGGt4!*DVv+aK@%#_`tEYYN5riu(%l4#$J*D7^Wj?wMl{e?}qh~ zY>s%K&(C)zD>TXgDhM0}O&=C2r+yy#K3pp3G_SZgw*E;r78oa{=-eoZRr2X4M1X%T zpwKhuUnefLT1P?+p*cUDbF;27;urNXIdV3GP9r`-Tm1Iz!5axr2q&_2aKHv)6R*sV zoC86Z4ZQcMBBg7vGph*EBH-3c92|H`VKT=wJcAF`QUTL~RppiMF@&7l+%|jh=q_Yl zl(4Ai%5;s*CbbwAZH2$YiG@Y5cQ^ujWfjnl_}!#bRb1n>F}OTlrVE!&9&uFk^!!4^ z;FHzbDye5^Xk#UxwXh=zxB3+h)q$p^rRmjVynV~|G~Rjyp=(MM0mu_vg>= zxp&taB#b47RTc~^Sn`WBaGB9RJ~<@SMf)iaypK+F>MgC7zsG<%r}Pqabh%S?=ZlnO z^3i`NU#PHfxzukcD5suN`yh?Xm0-C9poTO!`bZon&_&qD+`{Bx!n8>beH987Qkx%6 zRNOt{;*|T%y-h7HKpqjqJ|6|a$DY4jlDeCYdZAn2&+t{t*H<)>RWW_m=_B!yXoyoi~j%|VXyXk z04CaDLB0Woc^Km9>6tgSGvc<^MsnrPilHHjLv>{cIk;b)x=dF3^O!*;WI(#z7`=S_P(B*fsh&^#>LCqbFwo<4%S1-m5+rtCdO_86H82|ZC-J$ z^0QbYQ`^F#vI*`-R!K??acY7!^%XsR4*+eK%Hj)EVh@1o1ZacHTr3XZeXE%-cJZ^~ z?igTnbhO%Wgc-Tl^we?eguId(P0owu>bd@t3XpYIWGuOgQ3;QMy?OJ-3M_sY35mfq zuL>o*x~!TS!N0WzGR3%G{DKF@zLYPS60_t>W-)`#e=IG9h1bEVcPafZw@P#@ERv6p zy`y8B4KrpKCaWw_2M6wwSG%=MfhV6$c;?N^>W7f6Z-J zDZ9VEuFcES$qeV@;ra2!?iU#qRgB+afU-yn!0$B5%45;`0FQ+Jpvg1>NBLMTz?jA| z)(osl*JpZq(Vf!EzRs{Z#ZpRbFK?ztkBILl;4p?=3tZpa=+|-|^w7C6v9sgywH;Fs z5D@4!^2MZlIShqt{M-5$5}9@b3BTNuH88kO!XO#foj}bZFw%z41MhYee!kk11Oklz z`dh>Fa}3e4#Q&K^U0w$2y?M`4s?}sm*A~AeYh%N5dpXtdeQ1dE*Lyz0`5f+^M4G6z zHCqtGR@VAntA~)o{%h9k?(R;MI#dUbIHEcyL@Z3EPxQq*VzL9^&^mv_@!);Obxb`s0N9NAtehd-L8uV}6C42C7z=Ib>PI6$H_DA_up%NN{Fh^> z@6}Hj#FD_{!Tfx_zu5NJ|A5Ka53{$5E!*l!AM|fiPAus(m+^;m79F8dyynf(?=1rH zL1Z)>HwZHN>dAH-*ru$A9m`(xn;An7#+IpHMW`trs;7o`dodKo%*qNKlD;Z0@SS}M zHU)v8)BotDgVO^R+R17TGolBVnK8I7s(9m@l)VE3NI5x(eSbQnP-m9fpg%(h52&{L zb-y_Dz`Ik#*O}nHg zNlM)8!9#x}(&v1I@WQ?csp#Kj<(@;5C9WOi9N+_lr(szFV>MwNGCcRs0*lZ|JIVP9 zA=!WCs+T1Mg;0=m61V*fl8wT){%kq|Mn?2fwDZ(fo$MHgwK`?lUyM`_1(0Ukfxp`(RR^z-IUr-0Hi-PWow{Cu;JB3(UcuYs*w zS4*6aR_LvhhkwGVo|nTL3j)wU85OH)F@&*_VhEf6T494$f9%^o{wW)R-E2MjvGeza zFSC{4jJ5&0C5fpaM@X8+x{0vKT$s9P6dx_!2}!7${-?<)v7eVYfycvLXmo&twy8~2 zSzgxcRWV?%+mDKmCxGJOHY}zf zBEzVtsQQD4x4pr}DhW>kTOQr`_F+|Id_uJWpE4krDs1n$j^ z4~#^#*Vo<6%_-@S^o6&xx9o;ptbyqcres_rlnA$?e4mR+7B4CynP7Ygfwge$eLz}V zGHzyvt(_DOG`TG4bC_tSFx*_?tgdwH@@G^c9{#)#bZ|j__6fymYZZ3A(t^oZFRLDJ z<|7pqNdZ|D!)U?g&d%b-{%;MSR7p(6^ymT)h)QkekSh-{N&J1hTjn*>H)-(^OFEn3 zfYf#FlAvDXSZH;}`L!fzojkUZ-u6h1~<|ldl38{cs(Tz z^yf0hlCvn;jF)zoekSZnWBb{^yuUDabL6)Zuf3|k>+R2D zMvZ^Gh-lu&y-J9rKP7y=AV`reWqLvN9_W;5A}8f@GEIFJ>MP(|aY1j>ljymVg<{x4 zjTFww#AKCVyAHqe?wr(PU0Yvgn<*~*(cO)Zkf1efbUo?C5fXKog#!N9hvflQ_Ei@1S=cn*o&~0NkFVWeV!*?(Mf@_YaIXRWBoSN8N{9R{?_E)?I0Pl)- zSk3-lc6VCwGx2l6)(wj|_KY$|AtH*hpC?w_!mj9Eym)c1V@Ac9UMldOv9Ym=hDLYW znZ#o0TO2BlDK1H~Tb&O}SYUmu{fUFUp;BFPRH*QlWfB*sA(cD;7K8SsKm<0T%Jh2< zl25-sW)G5-%1!FyUy%-yRq84#LT$7pDM1{kASaKA|J*&W{>_j1Bet3!Q3ERr3${`r zxt8<=t9tQd$(x@834HBwAge03Xrmn&8TmB#UY;zXJtTXHv-mT3HX4_wdxXvk*q_u~ zB^KOt1>j_xQ&o(Mfjf`PTK&m~q|UNl_(H6f+C%*J+s^o{zeB+URn(uW&@u3)lKb|J z;p;&>2N*w%=;1HNUykTZO0!8|{kbxXs;a8Jy}g~u@F#jT#yUC?U%fU8K$QTFg)4oE z%_J{+UxjhaAyD}a+Cs@wwyCv08}-sKhMprLBO|M=zF~n3htt&!q@|o7$!ghePmm7z z=+^r^QYn-8Z8ux1OeYQ)J;h$WBE@i|1QQu8Z9J*;IbdgJ7r&Ia))|34-QYs^?AbGZ z=Sd!<%U1ubM*O7q$3I697l{b1@r}c zb#YGrIZ^e>4+;7>IyR=G?@1{o-#w>byhE2awIfv-SjnB5>qWm1bS$f`p7=skW1XFT zab*!&nTEAa*pl^45h`few>x}ywmtEbT}whUI9L)~CN=kUf=-|A2g^ng;RDWaM3N{S zftMEMw&v9*0uNO={Kbrmkq%3Z5NXTI?3koyUB@P}H98^f}=x3TKl?q2}O2mR_|A|nL zG%`hFHXWWohRc4KLB~t}UJ|dtfA+lL(mfBsorQsVS4B-NvMQG`*|mrnY;qfg*hFN{ zAVt)=7mvOnW!V#zSZ;&1_0}9V3d%PhmV*IWUO1bT7+5{`@uWt=L$Aen^UF!p7wjLOt42~RsEI<~v438pG3D_0z4+^UFEz|`) zvuD@Lii^O;!@>~8S9gxNMoiLx4hhjF6<`Q53Q7mdctdkR2MJQ(Hb3194@9I}(Z6jDB zJ-!i-Y^d~bBcC&hzN{R&7{>TGfa3hb5Hl;n^pGGf31?*`JccmBb>U5|n<%zhE5z0o zFs#D*K1$Z!-dX3=Ia(A>%e}X|NL+4)pCwH^KJlswMT6a+iTAMxVxlBhGDD=E4w!Xl zR`oTwY|rFK!#R0fgRZJNaIvu794Qm5yb=~B`#Y=?lD|D9mB+$H zGGJ}T z>oxbA*&q6uHWjLhk7x@@K%-tEY!@WtNf=nyYKLH|PiyahN^|b2kcg7p`!3!)O1;1M zD8B@WA@E4Zz66RO5QvrA8XNqw&$>ONTwlKIRz-bacHh*#f`TAOsjnZcp1tkwDX9tt zZ{qN8LFksZFmv_H?%aH{-5m}-3H#ct$VIS<=6#fu9l;H<{q^2lw`hBNw4T9Fhg>pw z-#_9?|jjKcL2)~hIOYm38(_cRw(@DuF$S@N9u3V*z!Az)-2&b_hHdUq^ z3xAG=x_$BS|6XF^xpYf4D&8f*`ZGCZZ*GH5cAFtri0_{bBW7wN&i!X;U;vBKFoUaB z6dC4ff2%rVim5w%$osJCH6|G^oQf{XGA&-h3Vz9;(IbvVh*_!@a$6 zyTloD+(iBw#EpzJ3i{pq)k`)&d?7g=D>&G!kx|lUUOLEtfpK)Sl+m;S2)lf}(;y}2HdDyC+iQAu1*gEi}#v~#)tauKr>f77x zt6>sJhdB3RN6g7o#Nn!O5c2@$o2<(txGSh4PEM)$;^+L99-&Aj;AE5vj1>sQN8#5B zF>QemN{)ubKP~$|T#CZT>1e}^Yd5Ps9XV5SNamaJ%QYO<)?X+s!HDn+>w zgkDCoQRbQqMq)6TbMKLEM=HzKk<4|35{?o}k|!F4XAzn)`Jp=2rzD#7Y<@KZ9_6xr z9pG^flGkOg=6S@9K%*$XI8h=F4-3p?WM;QM;o1v@ECrnoCksU7yJVMox*z0C<2SkI zpI;8id|nc0`Y*%L>%eNNE3z$!^6!M<_Bk7b8p6h(>7>O`A0 z<+Zv*G%oobe{*ED{dM1NZ?PGvV#``j4cAc7NNPgGz!Dkv{TaS@;b(}yo^=0#PGFJz zZnL536YPaW4f$FI*7aZ8k+WfKpLp58WA|%}Q@wZTZb|N&MlBd(NM`?fsxmB0elg5a zyhTfzYtn^Y>O}{*Xk9rgF>z5nn_pVy(}ezLUu)}VJ-yP^B{+!VuV+ohkm{K0X1(jcKbDH?b&>a_(vxDPrweFG!4ZAQaM@IzzoNjj}rA zDd{kJNtN8Ib6~C!yRUCI`0r^kQiz=V_+lWl4sGU=mKMH|Lz&xg`au%S7JWZM-(ZyC zY#>w0b+bZ4{R69Ou8h`8GW{N}ZKwn{hbDlMWY(nFn;@L7Cww3hUttM6+E&%TSqy$H zO&vQlZoeprsc76h-5UFw_||P67JNj!psA8~0(<040j;#8ZhWd1PAZ)@XY#1pN)8>I z64k46S?F;kD#aHQ)0rptsTt&LEW5MFr}iV=DwtlH#MuJc^?~}{NW{(*GKiKKp`5JJSn=tL zWw`ym#rh3c5D}+>zU7-!QKX}9Q^r3wOy16eEhKnz|J>v1gl6sbZ`IcmKef_PdcMtKNSG<9Xx4}|=|E$9hEynSWZfFpV5_G*B%drKT zf{p37pZB$gbas&@46(47YZbb@8iCPEJw!2f+^TU{;OoX*ofcVd4Ci}K&W{udOOZ=t z#S%e0z1B4hVGwq$;tgot*W3B8oi}G=XMrnFctcBY#-FJdPMc3$vx24TVrm__`JV{r zWa$;L>gx-iP}rwlo)7P^BtBUGJ-T&NRCFAm0y}ZW$gYQY;R;z9O3Hq_ZqLg}D}5gC-$dChBeP#=_&Wpc z6)^{U=SlU}^T*LAGHTrz*Ap~tFkB5b#KBBH*19n!!Q|!N93nX5?j!e>NF|R`ZpIhF zfmx@Ej=QHU&3KG@J$PDno7xgmx2veFAUE;jl8Mo>b>~UIVQ`vsRSAk>_BorqYgesWGUr@`D=W&OA`>A)AQ05o^3v}i5Lh$_1g0Db0lX8X^R58= zdf_PfS`7(&c_EpEf#a8U@*f-_5PbCK9~ip&QWWqep_7c3ld7$mldF+~Da6&)mG!fY zrK7QtohhrW!>5!(VIl~G0`gi~Ld`98f5FvDO??sJ_>&oD^1wR}x|gq!KA*>kW5EVw zuUbm{adpZ^)|#v<)Y9k-VZzhDP{*;_)>cuIo~8+KLbAq6P{#TvKm7Nd=TnVILXyxI zl%HESKB7158}lhreFI-Shi*ud+gI%T>QLF(*pdb}OAZlKLK#?DW!>D|G+hJ3hT`Qk zUH!BpqoSlOEG)n~d3pyk6^H@?0(uLmRDw!Sw1tuBKgK6BpE8`C`NC!=5?;L}APMt; zaR+}E78d4#hJZ*#MU@cM>JN@+jO{4EQ73XtfufD`t#80g8K5T(wmmSFzPQ|niIO#% zUOgN34?|k1wVv~&`)qK;1#&U|SUpzI;H)JFc+BQ?Po4OrOMFz>WFf8o z9?c@2ej~~&m*e?<85w(3)Uwse+1)OJ5mUdcTO9zA|L5vGqJP89V4Q zLZPB^_-L2eM9r>zZP#fA*Ywo1dUUg(N4JSGKmb1D~NPY=dncQ+j0(tM>i z71eHtTc`hR$-q0qBmFFo^&dP6g{;}xe&oJ58oC&mDk$LbTt#kZ%08?1cO#%9_&ha! z=6r>TS=o|>yj!oBigB55F8cCxgpz^-)9q%XWDg%xg|BN_+0eZBF}=T!_U223F&dv=VeyWm~`2Y7bj>l_ksTBB;}*4 z>ovbvbPPNMuVab10~F*RHt0m-_7C7u{h#Nam|r;$`Vz9_J>_!8qVvNhmTZCJc^C9eHBn(jF{TXU6 z?l($^k2k|5du(8~I>BrOzJGatj(yyL-BO_5hBy24PUxp~61hoX@4Ez(1+<<+#b!p43p z8BdoPDYKhnsF1fTi;HMzYZKAFOY%b{=1pDjr_WytMKR6p?dJ8bS?k)$j!QJG(4eesX z6PgCmwT@dZ*IPU0OI~NFi|$)#Xivgd3$Em>_50=ErSy0;2miqUYVn7Zd;qA)nY?!`;cw*oY5aGy9sqo=jkm9DvOR~@huRbmO4pY=SL?N zwlDEmw1Z?K@tmh`_-q%W@>PGkOy7iu{a7RU|6maK?^q;UR|f|S^2I<3A38CgjnzfX zf=y_ziKMr;NV?DMXXX#(KT$lUf}Z179x*)wgM_|*`W)}X#6;RS@f5$B#Q(fyCqIW^ z5HS5JEvMQ({`u=MzhXxrBt*Qkv!gdsIQgGoS_f0Cv3Dw9V6ddPAMQy~@P8o84&)RH zJ@4z52KTcv`?W5O*tr82g6J;R?Rfs@$ewMJ`Sa%scXxNag=k*;ynz1$@jtfY5CR+y zjOA2GaOcO*7d7oG;w~<{|Hj7ZGc`d}2mZ$yPP=$=!?CHUDQz12>VIba##{F9%&VUPR2&MNw#8UcrRPQcZL zn4j+>uW%t_Q9vFL@KtZ2QV~QJX=(4-d{xxvo65?fel%`8Zh=$DKA0>fjtWD<9p7zg zEb)8Z8@H(wg>V0SR>kGyvW&~HbrAJA>4aeoY;W=39op5e{!a+-9@4SJHM+YLq@gX~ z_@v1H@85m=kKKMd3Yh0OaY4kxqhYn69a&VQ9TY@wzvLaCeX!`s_R`2G9SQY7=L~xm z?my?5XZY&Ju;>I$pdq4dr>PUM)wE2R+7a-+n+q4&*L&U$d2*gN8(*etE70QO8Ff9a zk>0<*k4spMjHhm_ud{5#dcKVFTeAvMA=gPtt_nP&Xp*Z%CZ7w#i2~^t@a`0}U4>sf zr}>@@My2|spG|$bp_Yh{kZ1Z&4w_j7`ysnk(j>T}$PZ0CLG1rrj95w39XeMv(Kb8` zr~3Prnr8z2^JgCdvBlqo^|GJXpDz?@+0-2P`#02ek&t!va3gVT`JlL^%xE#;(lv9a z`+25GKX%6mS}p2E4-62QnDHJQu{-5~`^djO*&AT}CtwK7DI3lH>A@YWhW~qp_U%zo z`L~v{Oa30L&l^tAGC0`G#B`#~%yBt4MN(#tSqBd#`CZ=c%u&1ftctH*$1p`aJfto@ z&nH``x>S)pJ=mg_mj}gS(+xoUI;1Q6m+e-9AJb+!$!rg1E6cQ)i^*L1NqUBcWIa6U zex8x|ZW1OTBhS`*Dn8rJc<#-aWBfODxLVz$oMW*kY$r3z&uBt_@rx&&dEWlFD|$ZB zTUY%X?uQRNBYOumkGB}3yh_5DsG)F4+`afdK3;p&yLh{eL$JmfQqYMpE^umQ&lKc}o?D z5U>_18IE(-a%HA(c_0*wZ-R+!kT%NT{*!`?M{*w?DeGBx4kSxtTOT%yAz#gpq37o} z%`f>65e33kzE@R+%NgB1y(uVQ{8XQifR%Wl#)u0G3p?BB>#bmI%>qRT?B8NyVoE!h z_ZAZt5y2$r=^t!VP>9C$y;s>IahYz?n_i+6)j#0m*R>D6UUNFM;zh(k{-Eiaqsq>& z%oK^w*0noPIA>LD(u)NmOUK3;m)Sr|hzpUyUjO6cRkQI#fx2~-=k-eH$#FY+y_cwn z2x$tRtxb2jimTm0WoVgw4#uXpH*S*P1o`LBZI5W&HQqNH z5^hfqKT8fj{sz;Sn7iQ3w2s^U9sEdX1l`W5Y;)P>w)ym zTNYMJs)4jQbWL5%pugN=Q1YP%(xJq57%gTrH;)Jd5dtwEzIU|sXFggr z(!igi(JX|4xbSH*4r{E{;)seu(bi}6Y?(v(XXemt4+ovr0_nkyWZ-1D{Zl{viL z?0&xEi=5GzgE>oJJ7BXDJ@5GfMy8J+8|?O{;j_DSJ&UgyksOAts*Im}L>wHVMs}c| zM5B5Jd6sXs*6fzNi>r^n_xj-*L`jMJAtoen%fET=+W#xRphunnjWnR$B3Pj`v`xVq zDZl8`_m7N$frP*%)I~Ct@Gq0NC>L&kU76@9l!{n50h0{Pc0@ltQveTFeb)32;rysn z@=XMJTf2x}x+=4>6JJ43uIP``(@av)`-Y)Ue949kY={tgDamIqBiR4Pm^PK)sB67< zRbsiMzRe!EJm5gvlQ=|K*%DRXR#x)vFBzbxDb{$5xZzT=4TnV&%Z2$gBBH6SC4c%j ztSc}=K`DV+S?3ycmY1EKT3uLeC2+K?Ty2a<^68C{CnsGvw} zgqWD=^o&2~JqDurB93mv+eQN3yn5_v^6`eZsoN<#YYGj8!XdaBbw!EisjaT`kEw>x zrHAdrHM#ISeIB#BpZNp>p-cBfTXCI-3632W$T*r-RT8lEj3w;{E@&LnY)~-Fwpj#K zyap-?ypKTms0|_=N1d{UnS_hW*aTdfqE@Bdea*{n-x#tTk!cmrJ5M+4hujhE?JelP zd0$yXKYe8wfs#Snv!u-FS!5n_VyTQa`WywPdhrdUFLD)z?y~siK`9~a#9B~L#P2c? zq>|Ghlaay0L=cGZIqt`9$|g!s`&as#L@-_tp3Cdr^Tz&1Zql&=noZ=nNxEs zbew(I#CyS^WV=f$3kUI3_$-o#0q_t%RokZU5Y^upPq%x@7m1h7!ayxGy_DtaiyK3pK{5MSHP;e``f}&!@^S6bfvVUuxnfjPS4Ba&~A=A)Wu$#y2{XoQ~yZyM@aaa-T z^yvqmEg7%P{PeDU{la0@k5c+%=KucbPnr_OuYRp0u9Ukk8a zM-c`Zi9NiC<@)9ac17Os*q${#J-gAi^2x>F&d%fUX@U?F=Vj*uDH=KNau23dVIAUH z_uXA`1aSm`2f9HB!KG~3-OafJfK=f&_0$1{lPe{J^m0F6&aMorvvakO^stVJ z#B~98vA1#G3l+75iB{jC*9UAamqm2s_f!n8qvNSNx7;9YWpK_MwInN!n-u5Yb(BvY zuIQic9mj3v5FCxN%pHR@P@2!3Ug&#qwAnP`l2P5wfzYdx;c&Ge*zn{tW@gyh`eq=N zp~$67oAmg2d!gc_SOc-V;(|qknftNc&WI-6*T-+${^|Y`GY&EZ!|T8fX`X<9q2hZ1 zXVls^!Eu(QGCh@3un=ZbQ()b}m32gDg}7w?{>ljOtz67d&R=&&EFcD5FuDlYtp>gP z^JlgFAobUcUW@F*^s!HT8P*%DP)WP_e9gJ#y}aNZ|LsM>(; zs@#|WdWnaNOF1Glb|FI|UAD`~t^pl=@5RY2~Z}&w5Kh5F1E4t;aq(r#7Hc_)* zF8%_s-pAdboThKXas2MtxHoPu@`ifErR+JZDl3)UJf#SUkdNZ2SHw(_8|0!ByhIT~ z6~87Xh8{IPEm{+&42Co`2p92J=udw0JZi*`aGXE=kw@KdcUV8Ncfp#mRPiacA}u!M zv>H@61QYu*McHku4#Fb58uU!5-#0_Y)x@Gm=NzwG>6t1FuMX?X3h{z`BO?a*oy=3W zP~wVGT{_gi8M!c5&#=#9Z*k4TOsZoshU888hF%Iu6@;IT&Wcaym`)d>=Nd3E^O ziaq>=zWq+(yf|fnEB{XIIZ1S=bt6E6o-a?pVNEFOMtS4wBelmU}{rukC-1=+%M|t zy5tFclG@v^hk(w6LZaY;0o&~)8RBS)5n?5XZ)l|rt^L>GsXI z0?dYj+NSU)nxA4q60m@`S!dRQ4EM;t(DSM7KjY$e^6y!fhbD8br^YPYuWVi(KvjhP z-C8a@S`qJ=DBtl*XUsij5J9@xt+kQ9v!+cRT)Eo0UKq}luU#Lv=f2AD_a_@#c@fx( zP+WCkABbql?q+wSvm%jJy55ei0)ix@g-e*^Z(6o`KQ+QrC(~$bIdYii2j6g`b;B<43G;rQVb`dh7~OOKOg=H{$6Hx6IDZyAcz)$?X+;-7Do z*tzQWoKy6^nFk)0?QLY)XVI;x)} zJVV|dQoCroQn#m#uR^t3V&&{SG`AZRR3W;^rJILg;aKta2Y8Hm?aBfICJmg`p7>k} z44j|RZz9+V3X74T`}c{MUwUImg?6aSOblE@#}-w}qCnaF^9V)s_KWUI6V92H z6-w*{+m&m3Y+9woy@sO|N-5n`eAZeTjM34O>V`v>U%BDBDl&3XxoT}je=_&ahB4h{ zOcP>@m#Wbb($FBwTsEowF2H|#$Mu?YXZV7e&hEO53?3d^I+PTTEvD_?FH%htd4pF{ zkF2j;9xz@mixz3~V3amL(t+Yu*u-d{m4&QJWz5Ff>$b!!he7 z@MeR^{?*mj($c@)hai&gv)z)YDE*qS&=cL-+he*B=6JeB1S5dmcOhw7K^R|jCBJ=o zI2yV^QFIZCs;$ktz0f4_Jrv*uxHbf-`N73J6wTQk)TP;?KeO8c+Cx!mwzI{5=H61V zC`>O&{IbaS<5M_8UO(lz`gI8Iw-a*eKle<2Isbx>0-|}0p_9$dZt|(-t!Ymsft{(b zJm?Q7Y)#j|rRe=*eW2Wpy#M`9VjGn&bH8GExok%Hde*WmRWy2?>+U^w-`(9({MB+G z3)vYVAKD3%W}S#wAe;*NrwT#kvbiwoWDk;F?&WJAYW=BK60GGjqas)5?QOyFTRdW| zdYv78syl8gr@2}1&B{Vl304FmW6;Rg2${}yNHJ9_|2(7lYihB?KZg#dQS7216zib` zXOKr|7Q;f^Iy?T_nAp}z3!dku#MM~f;@FgU0oF)bWU`9Q^0p*Imluf*33P;FLW^5qfw zMikkK6p7R)X|5QYp1ctnMShyPspeb?@3HRxjbU=QvNp)Yes{6}Q%+WpI}kB%jX?8m zghD_)QsT2Vc-7Lcqs?D7Ly}iqNl77oZ)$k5nloLNh2>ZFl>=1O9L8SH$>;-4LxU34 z1MkU!XL#Nj{JWG8zt3Z-GFcEqD;HiI3!bm7t#R&E=~Lr);665++bTJZZ+GQxS?dT)ki5#8Nobsb()G(Bi|VF7opQgb$BNAoH_ zJ}%Q=w*3d9w1`FphxkQ{|CTf3^M#kUGMG*lJzqV8RIgtLo}JY2vu$6j`mQiF{?JEa zHbX2zMa%QeBn@zLcUsPZXd~u1N+NKOLx{g=02hvFc{&HuHyl?hNPvSd*`y>=O1Ecqy?6;HI zmYjVIp=mdf-5|D6jm?Lo?VCm~(Kf$4Wv`o!LIQr}1Bcj`RJ(J`8ynBLc0 zqD514`%v1&bd7zDc~&-XLhZ%XA+6nVFpY}{wYs!*O95G3A-{ib2puu0a|Y4nu|Haf zNuz4i?uY)?#0v;Sq!gIBxPL*lE3)fyD7~R1)~c%&7LrY+#mJ~V;Ar>j&-eD;jeeCn zkIFN9Q#|r?6Cm)1*4hRfnN{;k6`&}4J9@UF}Hh#bglo3a7d7+K{ zF)nuL5x(hT3iDaV1nYC@vK+T&6uIPJ%`vT=&q;VG>4eDYaH&AKVi6xDS#dFp3q1R?VKN0#KEW~hhW*O z4FA>qp+LfyZ@yHcuD{dA@MPrsI|3^bx#cQLJ!&27CeSgVX18f>8`Y!n)-)7 z9?s$0U$AMfKeoL%A*}`VB+j>Q#nn$xsM>1PTt{M%^_)he^_+!FM*YL3-6*n4W2LW- z=&7W)>7H$YYvzLKM&rEo8yvD9NE9!aG{3jB=j4kWEQlE*@D>#X%;#(fG{WJ^H!FB~ z`yTSbIaIy;0>iS&WOwhztWiY2ANS~euEIb>R3a{rT}JjhE%vSr?z4F#Di?*WNRLGS zD_ITxICSa~X(TiWbV5I7wKek!mqld?1Pf{L;7AN4+#gN0!SV=pEW9>F!P>=Lmj{*8 zO^tYe{^&o$)}uaFvue=~cY87!DPm%6G9R|t?@wJ=geQu9b3+x*WY5{zM$aBjUEslX z9|%dNXNEfZh|SjfcE_d|vJXg`X5sB={%xQUw9=k+o3777+xz}4z1Ed4hQ$BO(Y51h z$|OBd6{4~B_3VVetrm*rsS@f;Z+%fi!ud6|wvS>{HfW71Oi6yA(;R|*JZ=12TUgXs zHnSf;ovn$!y+FM)dw9WKt|oFBBT$LF5LS6&H`#MB#)*(b)cx;^5F%o~xp>W~^9S>z zM^aHMaqoqLyizy~wg=0nT>#K3kzIsj<(~8@2>Z!gZxXkdGuvD}*4_$ug3Xv{>lG`i z?f2uyr1w!+Df!(L$HUz+9C~8witg=IFWoP##=46=d7TH(eJDtiEPf`AJ3WMUbZxpT@!m~ZEM z;unukEgsuykQP>T~owx~fV!b^JNW%yzAE|Uy=)0eW9*8`B z<^x%Ds#+>OM4w#V-!9m9lWH{zV)s|wBgZz6b6lzQV{%E}D->jp1oTO+u&sV#t0QU; zg|4!+Sp@^+?$M$(VMxS^5 zY8Z}VPr4Uu7akHHXO{72Z(UWkGZ6PRR=jTN&rTlOuKoZxdLYfyvHq&`=HK+@>gqTW zDlWP9EFe%cEcYspNKY<|p9FJ#;SdWjvHtly^!IaRH#A&)Yp%NeJw^zkdF-}*^yXkn zXf!cjmB+kIb-OutHX#3it<$7?>@rkueQsS5?~D~&Jx?^qrlp44T>UtWiqO;8kO@T% zzUqlT&ftUx*)Cdai}>r`=KzJOzbPE!(X?$ktns9_`&E58tj=#oN8g9G6ekG@W%p^| zYiQ_LqL|C^6(?KmF3dVlc)UQ0cuz(D<{JJRlhg4Py49Iu#_*M9)`$e0EsglB)d~f@ zPU8(<9dcF;au$0_2uohqBbOtwg;8fHe=xc|@)R|6Ds#tTLWw^*tp=yXyx~~#WeD^{ z=6yn$WZS~~!h+8Q-8hxh^7VSOXqKtKThcHfGm>BelkqC!XH8G07Ahuy@cQ$AU6rFUC>*&%v? zb1QaDF*`e#{)IaH$EdjfTg;%h!%zjamH_GzDMS&3EK`DQbhaRB^3F2DJq;0`yW*jn z`I9wl4AKQbr{qDGq(QXn+Xw?%8Y&C)N}cMDOXoXf^$es7sSAeUk4sN6x88T`+iS54 zA&7u6;tR->M!t`y;k z&S~UOfAsS;!Fey;aYXp%i6JIlyobk2zVo}eCA(X(r`Gs6n?Qxq?vqa$GS{T8Efof0 zqX5;wNUJ7d{(yz->+8!;(gH@X)umzF^_OJvnL<5kOnf0uuRuz67(TCS6dS=|+|ez* zxBC~;)X|WK9VUM&2@)sFa7JmG{5XD1znI3xrpy@tc8PzK?L ze+1V6Q()Cas&Dl>WowpRZ@h}A+PLJGK9Hw{3qhOsxY&SH^nnX$XJ_@TRDT~c0jCM# z>gwZj6j4z#2~qrnp{L6FMF8RzS;N6N{{2Jz#b=&L7N*WUzO)uV&=o8B$ePB(qn&g@ zrN`eUqo5cu(nBE9Ec(n0+}sgKV&tG$hJo-960**nM8K)w+wqgQt;d_2m`xgvDXgjlf{qbgvQ`Y)No@ax{p!dt{0Lu)$< zt4!qET|^aS!>&;B?}q2*_F;`_}& z!ly?8%xGAQ%__l^ckYk3C+Rc89Ip}>^kT{=v%DvuMgA2+)cbl=RJ;l}{Gpdl2+&A( zX2sOFwILzrnw?zbB0VAb^O}GE5MI2XU)kC55x~QARzkBJ!}>IQd<0c$h|0}OJLB${wn6#oF_w;K!>iw(sgHj&7 z?0cPQWtxt6Z8@<`2jyDmkb!h>B;R|=uLFv2-e=^$&1zk4CHncRmQ~`d^g{Qh9t*%F%shk7>e6!|=2irsw`A zNoS|A-Q9s41oCj}zIrjW#^LGGxH>_`P zF|gPm@A#6$;5uY_SU0UqA}b0Z4mKx#qb7VPR8W)*&cG8@4xbHy1a16iG5VCP$sCtN zvGK;N(3pC282_@+F0j=<4<9A=sv|r0*7%7HpVGYrUaNfF+r&f-kl~Zo?v`JAS?f~r zas1<5UdToq*-X=O55=6%DbNq8WNw$i)-k{G^M|BMxz{S56GV3UM26FKoVxyf0M(B`hqW$p#;KOk%{^d?Y|PM7M0e#ZeGld`kJHqk+1By z$D0#_(Bpna1#nt%n-a`=mkEKyAI*0*A0x9r4C3Pbz$DDKu(TmiDP3RL3e7_#Ge4QW zo}WJx+HxmVkZx3TC`VZG75m%SL=3bBp|Wc>*V)EP$sjR*t{%6%0b4zY1R_B309P{^1j~K@PNm}_Mzm10xVT=i5R{wj+t5B@; z-9y#F)^@3opcj>M58@D`@Es6Tx1A8~A3ZB80yh7ChIz(DwmE()@`x9HYafnfD;&Q7 z^n;V*W~SA_EbrWp(=+?iPJERrGt>l)QrVWjpKa#O=u*RGqu<%c{G&lhpyi1ktD9xo z`l{&vJNE^Jz(l~h8jA3QC}ha`rMai)X>aZ?OQ5eh{aJQUTR+&0$0i!V*32yDRzrt{ ztuyqy=KeHuXqz{F%s?t|z8_`x+AS|TCo3W%pty-_^9vmaoPM=s7!X5N#B+&_qh(&PI-e^iw0Di!?s-9+zAXg1b84Z=$j)K>vHGi=Ee^(97y6AnzJd^f-$LV;KWBYd^DJwfa8a5pR&P@ zR0OmeJVRIaZqEps$J7|m^#SJ6ZZh|JHPT~iWC&Q8vjFDVwhA=@^cYK$@It%l)?>@M zbb7i%RG-Tn1K^H9zlsJ-i4j6$%y{AW<{@9dyErR>-j7f?J1&8@QH8I*gT-=P%$EY% zn)mO$I6fyB#HL5_TYTlyD6uNY{LDTbpJM5!_^Bi4<*MZ|pmOEqr_q#@j0(>;J-vVa zye=WHRsTixYzCs8?J{H)6g{z|lrb zE$dcqMV;7h_w=CB(~DX1zR1A9-?kZ-RaN-x9do)HDEqU4?+!y!%2Qh~PG+tg1e||g zCIx_6mG7IMBIEW-zIYWqE=z!P17c1n{ut4km9xHyoMm*h_@BXz-CvpQsx2qH9lB8) z`;D0S(}e0-xYd(qf7p1k68b7hY{{G9U@_Z3OsV1YjjFpfh~Evul+rYG^-Z(vKKC|i z8rm4ddlT8Lozs6r34|su?2w&{M|5l?M)yi{cB_}-u3F&2JRjYAgcpXr^Ox%J5ld?k zfJ7m#7sKJ8l68)g|8I2&g5k!S6}F#U%}K(-kiyEh^)ll*+~{b=-BtYz#7we_&WY^J z**~SHV0;UU+Bld9}?N!X~Lgn4Kw9RZ#^!!|0szBmseUE33w9)mo`O295qReeACQcT5zqN zO>7$-@q6Gh%k=2S`&3y4W-t)I0srw@=?;$mgj{|B0lD2aweSQy$k+W4(RMp^@dp?;$~aOHRIzXnXDkPWNuA=Eqm~CBpMwT*r%^dUI^q z>A5EnQpy;1Xk6{XQ|g-VIdy`#o|of7p?u}#7G=hAq&78_f5+~|NP9L~{(~#DcrQey z*dWV%%%1%q;RwnrNSk8e%*?80Y+oPq@o^j_dz|g-gHGQ*oG8$IRabu~InfpEw}4g( z11CLak&s|0=mG`sNzAlq|18PmvTJ_h%^lp^?~q7*l7AMstFjgC5Vw z4g2vx-;>d{Z3mL!y1d~eb7nMtt>Z7XzSOtWV-Kr25Y|EGud3%a&x};s%KY`e6`;BhXMEKeT>Ysec z|2K6KTF$83^J&yo<(QAv7XGpS1+cti4hTUeNE49 zpUw7O^}%i{Z6z#XH$`R+gw7=X(TCHi&ttHL6)#(v>AJ&;n2j>fgC!9HDHYC>faVZ* z< z*$rxPvO=}DmtP*eQGV{mz#}>$8d5)x*rQfn;=f>!%j&ng-w2(mfqA-}hpYm)dY-eB2xWN}H>B zZBo7b<#0MfMtbo!9b2GDRzW|RdNts>06*^-TUM8CAN(%_wdMXs+$hV=w-uH`gmimK z={_~BV@lH>C}lfdB_f&rBqk!6t}H}r4~?9P;CJZo)6{1G6uO-$m1xtIQr*|KIUWDe zoJJ0hzk9PdQX%Gl-0Xi=@OJVorG`8VnD-2&<;VmE®w_`d`gV3yjY{|b6NDG+(F z+Dfp*;kmaQ( zgpwxhnx_R<$?z+(zcBOG)xj(O-onKv&u}*Y!5QxL?cP`t?_fsj3Ui*C1C%hkGmf%^ z$sYlM5zvGrsp|LslzMZq9neG{PhO9SWE6y`=nDqj z1!%~VaeKI+f{24Yh5YfiTrykv1_s2|_N4heH8s^wYtsen8*a~)!^|IO3%vpGm`S1{nVrYa5Y=)!`dfCh0Rn_j zm(8`DmU7cSLw9JQWpjCopTxDauI}8wxVyF3n_>Ml8_BFdMt#r0e~v37)8hNY#B3_$ zfiq(6_mhS~fUxGc4Uesct@)l)-)3G`xg!LX*ly=n;_61Ce%o{7)XTJ^xpdD%0pY88 zN1%RdaOcWZOpDk`_r^Qh929y|N=iX#IE}EoixKkU;>s85%vWuxvKDu*Wq)CRHfT+r zGsd%^_-41J$(cGl94Iq+59(F4XZ=7A0hE}QjKol{eFad^uSSB(p%@Qe|YfeXzUdkFO8W_f}7`qNU|fp^x<*l}Vf9 z+x02ZF!KF&Fc*A>P3K}`N6!dbQY%|?u*bB|Ug&g&f1a-@{yN-FhZW!F`(0)kyOOSB z^qwFm@QUH4{V{Onv#wIpE&b^DdN^PK5W*Kt=Ch=>ysY-QhX2llv}W;fB?rB-yu0EP z!NZ`?HO(u*do2H}?Vn1ryc+5MDIF%=Eqm|wt=`ej?-WTXO#&|2>5S}b*t}wRpL@)j z(>GHG35bU|Ug1ztpIgzuFOQy>l zZ<11~->-5khf1P!O3D!^VSpbBTM(z(Eg3Tut#Kydl|mLJ6|7d}8?C3syj)qg74JK1 zqvgZ=-$6!^ufNp&tRL@uyoS4;YObq7cMxFrU zy=`(ee)9{8O^Y-aD0ZEByyvqX2J_rCP`)Xl7=tPHpceiW#~_Mi2NgY5RGB@$`p=xo z`J@hit(U+6ol>0*-51L12quiX^RW>$^2N>1gd`q?-giNn5G1yO6h63@FIncUZ(wYj z7@}UW8L%>c(y1vk?KRjX-rWT%GF%^oy4kmEFwIY_1A6?<$ONJ!0QNE5Rij{6){+33 zr$QDC2C|Hdoa=`~Pa*)daLWfu1nRPl>NGdOUM;chr({kr0@elnxsL`&wEuEHk*SVl zmI8e>KffhjfzQpagDx~gMc+FXMm{U?)7eU-&m^o){;gTn7ESH5|9%xqNjVOSGU+*JN?!^@FQXL%yo@TU$)hH`Q zs~s^1%AqYXb{luqdc%Pp&49gR9VTAk=PqFSe)*uNT8qN@>`>y z!!$xH_uUC11dA9x~48ZFS z`0DB)!=iXv2~`1*Gp=>N3>n~XA=J4u7)Bd1ePBJn+b-COB zOAF9)ePUf*n*X_O@THk|H`sJ*F7-P*Ee}^Hnt63_l|*j$_C{nwCu@>%^eniSe+YP? zVNv_LWS0!c!9|17zndPaV9~`=(IH4^8iIv7xw*)=cmhh?(Uu*gdWqHR$=mxmU+WEDh<=CA(S=MtUcBI}$q(dspoKg__2F0wzUgL@8?t=7 zV&8x~8uHxV_^-y)iwhKvpify|Ny+w%Wby~mv%DL~#P&*fr2@aa3t5j9>zWKh0(w*M z0cb3<0bS0_{V)9N*Mb%h^RGM~E^=$xfhrUOd#v&yi;Rt5%WElG?5RlVeS(`g5V;s# z9SR=S!_*XYpg@|MN?bo!52-0bx|3fI!KnUDpV-n233?7ayH|(7E6Wmz2iIt$Q`U0` z4Hw^mV?#{$ZL++RN~0F4|17yu^r7t=Vz$d<%~42wBVW^XHWYB%5b*yd7QK&zPet9%Octy%~{j4aaLGWQ&Ab33uzBsp*D@t z;ff|UalgK+w`yM=(cIX8;W9&7n}e{MgeeOocrEV#+^YpCrV8YQVoCY_GEp`1ki--x){S~laCA$%ViX;?S7!J_$ zZDQ9+65(mndK-T12*LRn(zb8GZIUZK4(05V#b)J47ohds?SNMv&TO6y_p>{i@dgBxvwK}DGV3NqJ_`|hzicY*f4-toWyBP=#DhG`^_1(( zqJOUK(_*6yrn4~jA_53Gx4#NZ+#tFbL^T&;YTEW-)E>lh*XZ28fkq_<&+Uc+rxKJ| zau}ud?OPj=B1q9AZJHsfWgl8y?qf8Z$O@Ycqe+1J#kSEInQy^~V03g&S=n%R_t3dE z?B*=3+VQZ7*c|{W{X1i}#`Omz8CfPMe>Y#vg5&nY>nl zTYMj>zosAhn{X0B{%-kVyaGuHB5i zmo!D14NAFtI2+ zxFf<(WH5s2{ny15IOxE`BS8(j5di{x$m#u1@>(O;QR7vxV^C-{?DsU+Th&s15f!xr zhy*{NQ&_CR|dJ2w--ev$C&PANTG!2#n;bM z%myW%Fm)x-gDEk?A)YQVh`NJrOoNE!IBYwj1Me7*-lflkHB1B>e=d? zJOY?+_uk87q6Aq-RU;(ZOe5%VgwPVj!ik3junQg=P5YgMUcM1@ z-6dnUgT%b*f@q&jto)@R?|eX9&FGYg{sCKQ!SiM)L#}tG;==aLuQEbmf+`=M3pUX0 zgL?2NFI{Xl$*lMLqm>oMP%4AOyC|C_)O;NIx5S~M-cYvg`46v6IH55S0b}PoH5DK& zQ=xCQLn$7gC9*LxI@Ybl(l|UETuf=rVj8pXhez3!3JiuXv!@=(d@AJHTWS_VGe@UD zcU=x>8Z;Q`D^T{={n=_ZP0q2K6Klso^TM^%V2bVM1g~IoN}ON)R0-u)BwI%{i{}NF z4(;xvI+S3fZsqV-q7!j4&(^leavS`@NfcpA7-rp?{hD?utMtLZ@Gzc_Pu)iO-sM7A zBvV&sq^UwkNK_Q#*RN`>ySQw6TSLKn^R;;mj)=duhNZrI2`oq@5ibmW_bXtq%*ZZ@ zJxhiq3yP*UlVZF39TUNcixz;wNj&`x&K5G1l#~F=r(QkrO^WV3c)YK;CYuOA@V#y) zH{3WxYrb~V{lSY0u1efIBEDPNHy|ycfrpGnhO<;rRvCQI6JN)QW?(???Pa)kguc^w z_^SM4@aGLYwi0wS$1MkY`dx>2Gp=xuD%)Yu0mHD`MC=@?Dst>+{d>-}y};I>k%#OM zF;Gg=c{A#<4w}N}nm+=8jO8i>7QRLASoigxk-S3;UAu;AeAjSW4X1-_-y+J9iN!F* zibk}xhwAvWFTqFrDCflK?v_gX`a--KGx{%f>}$$hD>4uH;I_7==h?binmVe_Qq!h* z^$Nnu>cBNMBK&_9_MPEyebKu|?>)LO(Sm5vJHsfE5TZtn7NSQ&ln~t@TBIYo45B4O zH%b_Sh~7IfdWjbGzvuow-RHUG>zO(G?0xpyYrU(zhlQiAXw;@SQ+a*?|7~eV{7v}qdubVtvZOoa?Bd{ndDwe!0eQ!ch@8{y2L#knCEQ_T850aAfExCG-WWT~ z+(g!$3XPCeBS^iJcDiLhonQ^wo?s%8%1xPl2yyu~#L46lRtB7{KfM>jT7+J=0H zV7AeTEZZiMQ^fG7qIchpXV6)4)a6t-99VK#xE}9}6yH`fZ}7jFjcnkx^8zC;s&p3emI!it_H1c;GA3Lj=C|9ty1%gP zjBCXEt*&@6{3MkkMNWmG=LfL0NdCK~c6*M~#D+vf!^k8tEua)Y8=<$Kj0!)XLc-Tx z`(EdzRy?d;Vwz?}(jJP}n;26hctgWUE84~lh2W2{^p_KM_sHHq@Yu5eyM}t^HC>zr zx(SZ|OnQln!e}pr$S`c1N!WWxbVitt8-y}<; zqSr=h-B~z!={v2hZ@Ns%Ubp)c5Uxib079D)RV z$s&lUTB|S5iPBf5Qa5w3iE zIjFxzh?mbSsy4q#b$RT6d~wXPp_Qc7@uyc#(Hlk&8a$nhZfh{m0f3i4^}4Can}VY4 zefK-N^%atX1omTjSTnZLhnQqd0)zxAcw9;Lyh(24(eU6oTP!!N>ii&IZL8rsi>n58 zyXhh0_Y$vNV+lBubEKwD=ulePn!fS2kb?Hmp+j7a*08?3yjr_&A|DHM{8#o;nKMPe zV3gmJsme9GeaUH|$#)_6kAa$pyfxT8(wAx0A%EZQiVmoG#!yFm6R>FY+%P}RR3Ivz zXXZY3Oev>EH+&sxm; z0wE+?jpdZrX;(bvI-{5`_bG4A#%lPVtbVr450TM`Zocec9i!y@5|sPBK8Kqx-|#+w z|Ew@1%K8e20x#!{wGb6n&|Yi(Dl?O-)TTbp%qD=SIuAW((xu@~V<(psfeM=!G{mp0 ziDY?>T&Y0NBW-zOcJ~MGE}kT;zn5^*EgtCus`9wKy#*{~x3O-ET;n4pZJ#R5(tEEM z1MW2i<5d1w)zm3mwX@%!$21m{j9 zLtr*bZ6{o4AkWMot2Z3M4L2~L9VxYrk7c<2{r>sVuU{+y8!V+gA0k>ovTf^=vbSyB z5LP$$F~YbTLR> z2JB1S>^JQR54UHNdV20`%rvqG9c{HAMA~{6N@)q_RvOwjH{TF2^qKXujh zoYGEn7ii1`KCM$`(^&p=^2pDQRi(U-u-=4kx|L8v}joqoNh) zL0(k#k|WqAkW5}=YPR+9&nu){&qMj3q4Se#4&6-Y2ZvgK7%W#pq{Kt$4q_Tm5%^jr zCML3|JeRYwvg)yBRO4=Grec5K=2#`;5JH@Mve&(%>_d2nhet_^7?yIt$%+Zc$otyiZk_-)*WoonH$6EB z2-`3y6Fw`R661ix@XjDt<1efi2MJwVGWvL5@fTQSTfSI7~7u`w~-#dQ%Qt5Hd<4~PjH=i9KQCC5XJf+LHr6qyjM;06mHjV6= zV$AxrelTi_Io(EkeP01VHU_{0_M`)JF`d09k9lLQVu2An+hfP0feJF%~7!Fw*k!a&gP6 zfF}<|iXRsj*TcjCH4hFl`1$#5URX6kyB+KYc-%@HoHtCtzWBm{Ua@a!Y0+7QdIyBw zkS}&5XgqydIlcy1YQjn^s}~m9;|&Up!Qi!p;St#&#nXQME;pY9{fEhF9=8>JV$vK@ zqyu;f!*WW;FfC3+V)T0!IpD4IY)<+*z(Dv=hL7)0DJNYO{&$cxC@!X;rLu&n=iM_V z_&wD`wZHLbONhQ-**>0tu8OsSXkqEr($Q)JEA;C6o#q5k@~G+awYFFrafG9HnMeou ztc5>4Ew`a7czAW9FIyrW2hXd6Dd+>TIpjpICbSiF)VjTNOOBA}+WKPBW6$3(+^@Ke zpU40=1Cb<0r(Vw{r+x@F4*@o>)14zcd@g8-^vvD?2&DqqFTh&#?a6yNx+d+!EICo? z!jzQGlVbd(C?dKhoA+7>L+4Hw?8kbBAPK*20L$6SE|gC7^=J zq3*U@KpbYiGBPZ>|T|wp#rD>obwtk6v(N$q76)(%3n5U)9eFa_NmxRV{5^u zuWyZ7ROL+kXUGLBM4SAYaQ))E*NR7iv0ey?>aO5YDnJr|L*r zDrOEHC<~XTesyIGVUr~OM?x*d$_A+c#J^9Y`a|B!Yw5-1`T27)#8oCsAcx&wX(%JN zX;ib8_8*;#zPz3piTU}4ze+97Yb`a+IWho*48ZSEZ5t{K)9u0SX`yl>rcw@ z4Z)`nT+P>zuJl(1MJ88BsE}NZ2pW;&hwCe~w#kJ+2U6!uWBoW}Xl;&MGAaJ?cP5_6 z4nzx+C&pNWK@A^0upa~my=lKqO}Te#SH%BJNGAqmiAGs7B8EJMh)BW0aC#jaX2fU| zuy(}t;yz8s_|p0Lb#9oXn4^vay=Y>{;NW-CDqXle-lGeSv5$6r#2bxkzl>j12+j&aMaf?fBHny;`_#^Z3^0p zOBZz1J82OYQBYhn5r94Oi{3;TVt3!6o9$W&BSuY~oELwc96-%Q1hvI(#h~%D4VUh-X@d;?mq@>W+5+fjwnn?ecxFgklNg$^ z_S=(hN9(|32lixoRo=mEx0rcogBM!*xK`mN9e7PJfJXN%YG}_#OCow&;AJoQWtppI zgPEZRt7~x|2k!AkM!{1v%gjp82KWGKqex=BF<14FN@#Gvd$|H*5O~oLQX9{la(Xb@ zIaAA^LPDc%|ETct-*WfD-wjNn=IXz{H5K01B0sWK+|l%rh|^D3J0am}J|8xluktJD z-;TIx0)mdDRGRbiZNz9*O-$mo&CTkYJF}Nsea@e1S5^$VaYRnTU%6zd!QRHMD1Y+D zuYM~M@jVCs&FX5++#*5Ja(6%INoP7dJUZj>aN-L|lOl6MpA$pLosQm=WMTHrkPaic zab7_V&~GNJtf4U2lSvtHiE^quyDNwZgIOGLD_bpy2SEicNn+q#y-rso0b2~gJT@)H z64;`amb)Jxo%rf_xIb9grumS|6SufvU~NnY8bt%IJd<$`Jsrr`QxS7mH=P!H3J(od zgE+WCSnj#GUBPtZz!ccj^{57B0x5StFNW^Y*}L|=OkP(H#3v)&XZ!boeLuF{7qc2Zsi zXC#Lo=UMEWA3f&b#)k~ve27gGYmCg}yZt~lL@6Ek*$z6S?&oI~m3#9UFV1gMQjOTy zumtQ2d}(ah|LJl=C>bakPxKKd1OpbNUrd5tLR&lH=!;t|w)O$u3Hr3O1~SpRMJC$! zDItg9Is}36oUvRN80dX;+&dz%5GhsOjbvd1en&^Lb^QZLN2E;!P;`ia zSA4WmY`kSwWT(x|Zdd6cuJ;zu78M&l-{XDt z4p1rPYA?S2CMgOE`S)p5)Rr?8duJqp>Dl$iZcQhs6J(uIOs;1<`_bq6v)eG_ps4>; z;Z8b=f`H1jq_Vs^W^~ePl$o9oVEvbNL5Ij}JcyTxiKWuFc` zq@d8r)Vr;c68Dtu+I;W928W1w&8mRy1~etpQ*%$S2Du>20gkaOfc7{h z<(Mtd+Dd0A8K{kT(6ii)Jv~Be{8<{p{#{$JUji69EuMMtWeka^URrcL85!|*ehDfR z_@aTJ?F1ZPn$z9IwCANiTJb^PYau}I{)hg+K(BH9SgRRqaD9L7!NbTJ^obDf*AA** zK==gMC|#t!8@@Nr7N6kmUukDk$x;>f|KE__{5c_3RFJYRlJ_9)e{go!$&)V$evbwA8w- zmG<5Ew}f9T6(GVowBxNA)lC>nRZoS1NHz!j>3O(q8L&dV#m}pj z@tzb|DFO6Tvi9BG-!qLj-qKZ0@RwC@j1OYT-%weyQ2HherA$o7SeikAM@81Mz>d@~ zt)@2s=qp!Of>#Jp%;t;B`f)d4o@`!BA#T%DapDf%DeQ?)_1E^^E$O zrPu01S(mDss;7eK&OI(?x2*yBxO#YaySHuMTJrHPwV{f+ zmAYfOiM;@FA|U^a8u%slwZMQ_QIf&CK1e2P+u7l@gYKTI(&WDeKl1?L1j^fO;M-)X z;GiK99Hn~GZdgxEmKf21$o@^iRp8<}LiWFw#ZBOOxqZ1XvbP*+8V^j!OT4N&?}AgZpye1q&=$Khe-I|zw;0~CUjzpDwdFz&^RwIs~~Tw ziD@!t1bD{?1o0RNA+mQJgf_5DN)m>80kty{T{00Q@fgkPcjGVsHn37r0dWC-EOJF; zTr9VQkyFLJk_b_3I@*_)tg|n3A))mLYmR;x0n2J`_8COKYj`e?Q-R=svTs~ukF*1; z>lo^LdEuQQsjY;Td7<)C%+~Wz0iFxr`|7kH77$e}yP=gpuL|O+SCT~19yRsNR8gq= zR{7fuhK09H7n`+Hl~Hz$eI+uve;BM0j(C!_gQk90vM`igJ}NE z2FL6tu*-L3U&UEM>Fin6OEL;YMJSYCj7Ak$C!p&oMJ4h~iVb~Eq(aCj5hpQRaoa(q zR)wH{ z^n3uin$*Mu1lEZ-MwpGTi>Q$7STl6{Fz;ksr-nXgL@e1QN>a?~JcU;l8x){uaN|=aZsOKA!Xr=&M_~-3G|(=@>c$fuUlB0Nx#_L)dBV2K(LV8W_blN@@fVJ_p&b)x3flVFDI~)w`FB1 z$7>nP{`7mA$@uC<&uGJ-w&lji+FnSF(r3LgSdqoD=#%w(LUi-1&ZtpGAn ztD`_Kup2SDYuiG9eOVs;g833>)skAV!tA)$k z6K()EIg{BY)Tzt{f<{#@?^n;iMuZpj+}RDL$iK&7Rp|bk$Q~K|AgiY4RYiu<8;zK_ zqu1=LVlbmZ@uk$e-a*p}IP*3@!JGvw8ow_KInV)G!m$uMjq}tCN@{^Z7NrGdbn2S4L7i+}z$vohe#9SBJ;J zrw3ec-w4=ttFk~1yE-~K*&VD6Bi+mYqU3k3Ta$eAS=N1G7KXgTYg7mpzjdl|@5T+C zk}nq7T7P&_x+j&6b%aF{JiiQ&J2^RB6BO*48g^lFHo`_ are used to map isotope to hash values with which all possible isotopes can be described. - - :ref:`NXoptical_system_em`: - A base class to store for now qualitative and quantitative values of frequent interest - which are affected by the interplay of the components and state of an electron microscope. - Examples are the semiconvergence angle or the depth of field and depth of focus, the magnification, or the camera length. - - :ref:`NXpeak`: - A base class to describe peaks mathematically. - - :ref:`NXcircuit`: - A base class to describe a logical unit of at least one integrated circuit. - - -.. _EmAnalysisClasses-BC: - -We provide specific base classes which granularize frequently collected or analyzed quantities in specific application fields of electron microscopy to deal -with the situation that there are cases were logical connections between generated data artifacts mainly exist for the fact that the data artifacts were -collected during a workflow of electron microscopy research (e.g. taking measurements and then performing method-specific analyses generating new data and conclusions). -We see a value in granularizing out these pieces of information into own classes. In fact, one limitation of application definitions in NeXus, exactly as it applies for serialization -of information also more generally, is currently that they define a set of constraints on their graph of controlled concepts and terms. - -If we take for example diffraction experiments performed with an electron microscope, it is usually the case that (diffraction) patterns are collected in the session at the microscope. -However, all scientifically relevant conclusions are typically drawn later, i.e. through post-processing the collected diffraction (raw) data. These numerical and algorithmic steps -define computational workflows were data from an instance of an application definition such as NXem are used as input but many additional concepts, constraints, and assumptions -are applied without that these demand necessarily changes in the constraints on fields or groups of NXem. If we were to modify NXem for these cases, -NXem would combinatorially diverge as every different combination of required constraints demands having an own but almost similar application definition. -For this reason, method-specific base classes are used which granularize out how specific pieces of information are processed further to eventually enable their -storage (i.e. serialization) using NeXus. - -More consolidation through the use of NXsubentry classes should be considered in the future. For now we use an approach whereby base classes are combined to reuse vocabulary and a hierarchical organization of pieces of information with specific constraints which are relevant only for specific usage of such data by specific tools used by an eventually smaller circle of users. - - :ref:`NXem_method`, :ref:`NXem_ebsd`, :ref:`NXem_eds`, :ref:`NXem_eels`, :ref:`NXem_img`, :ref:`NXem_correlation`: - Base classes with method-specific details especially when it comes to reporting post-processed data within electron microscopy. - - :ref:`NXcrystal_structure`: - A base class to store crystalline phase/structure used for a simulation of diffraction pattern and comparison of these pattern against patterns to support indexing. - - :ref:`NXroi`: - A base class to granularize information collected and relevant for the characterization of a region-of-interest. diff --git a/manual/source/classes/base_classes/mpes-structure.rst b/manual/source/classes/base_classes/mpes-structure.rst deleted file mode 100644 index 4610b5f90b..0000000000 --- a/manual/source/classes/base_classes/mpes-structure.rst +++ /dev/null @@ -1,77 +0,0 @@ -.. _Mpes-Structure-BC: - -======================================= -Photoemission & core-level spectroscopy -======================================= - -.. index:: - IntroductionMpes - MpesAppDef - MpesBC - MpesCommonBC - MpesExtendedBC - - -.. _IntroductionMpes-BC: - -Introduction -############ - -Set of data storage objects to describe multidimensional photoemission (MPES) experiments including x-ray photoelectron spectroscopy (XPS), ultraviolet photoelectron spectroscopy (UPS), -hard x-ray photoelectron spectroscopy (HAXPES), angle-resolved photoemission spectroscopy (ARPES), two-photon photoemission (2PPE) -and photoemission electron microscopy (PEEM). Also includes descriptors for advanced specializations, such as spin-resolution, time resolution, -near-ambient pressure conditions, dichroism etc. - -.. _MpesBC-BC: - -Base Classes -############ - -:ref:`NXelectronanalyser`: - A base class to describe electron kinetic energy analizers. Contains the collective characteristics of the instrument such as energy resolution, and includes the following subclasses: - - :ref:`NXcollectioncolumn`: - Base class to describe the set of electronic lenses in the electron collection column (standard, PEEM, momentum-microscope, etc.). - - :ref:`NXenergydispersion`: - Base class to describe the energy dispersion sytem (hemispherical, time-of-flight, etc.). - - :ref:`NXspindispersion`: - Base class to describe the set of electronic lenses in the electron collection column. - -:ref:`NXmanipulator`: - A base class to describe the complex manipulators used in photoemission experiments, often with > 4 degrees of freedom, - cryogenic cooling and other advanced features. - -Four base classes to describe data processing, which can be used as subclasses of :ref:`NXprocess` if describing post-processing or as subclasses of :ref:`NXdetector` if describing live, electronics level processing: - - :ref:`NXcalibration`: - A base class to describe the 1D calibration of an axis, with a function mapping a raw data scale to a calibrated scale with the same number of points. - - :ref:`NXdistortion`: - A base class to describe the 2D distortion correction of an axis, with a matrix mapping a raw data image to a undistorted image. - - :ref:`NXregistration`: - A base class to describe the rigid transformations that are applied to an image. May be redundant as they can be described with :ref:`NXtransformations`. - - :ref:`NXprocess_mpes`: - A base class specializing :ref:`NXprocess`, describing events of data processing, reconstruction, or analysis for photoemission-related data. - -.. _MpesCommonBC-BC: - -Common Base Classes -################### - -There are related base classes that are common to other techniques: - - :ref:`NXlens_em`: - A class to describe all types of lenses. Includes electrostatic lenses for electron energy analysers. - - :ref:`NXdeflector` - A class to describe all kinds of deflectors, including electrostatic and magnetostatic deflectors for electron energy analysers. - - :ref:`NXresolution`: - Describes the resolution of a physical quantity, e.g. the resolution of the MPES spectrometer. - - :ref:`NXfit`, :ref:`NXpeak`, :ref:`NXfit_background`, :ref:`NXfit_function`, :ref:`NXfit_parameter`: - Base classes for describing a fit procedure, e.g. a peak fitting in energy space in XPS. \ No newline at end of file diff --git a/manual/source/classes/base_classes/optical-spectroscopy-structure.rst b/manual/source/classes/base_classes/optical-spectroscopy-structure.rst deleted file mode 100644 index cf610fc213..0000000000 --- a/manual/source/classes/base_classes/optical-spectroscopy-structure.rst +++ /dev/null @@ -1,199 +0,0 @@ -.. _Optical-Spectroscopy-Structure-BC: - -==================== -Optical Spectroscopy -==================== - -.. index:: - Ellipsometry - Raman - DispersiveMaterial - - -.. _Ellipsometry-BC: - -Ellipsometry -############ - -Ellipsometry is an optical characterization method to describe optical properties of interfaces and thickness of films. -The measurements are based on determining how the polarization state of light changes upon transmission and reflection. -Interpretation is based on Fresnel equations and numerical models of the optical properties of the materials. - -In the application definition, we provide a minimum set of description elements allowing for a reproducible recording of ellipsometry measurements. - -.. _Raman-BC: - -Raman -############ - -Raman spectroscopy is a characterization method to analyze vibrational properties for liquids, gases, or solids. -The measurements is based on the inelastic light scattering due to the material's vibrations. -Interpretation can be done based on peaks, which represent the phonon properties (intensity, center, width). - -The application definition contains a minimum of descriptive elements required to understand Raman spectroscopy measurements. - - -Application Definitions ------------------------ - - :ref:`NXoptical_spectroscopy`: - A generic application definition for spectroscopy measurements. This includes in particular ellipsometry and Raman spectroscopy measurements, but also other techniques such as photoluminescence, transmission, and reflection measurements. The requirements are: (i) an incident photon beam, (ii) a detector to measure scattered/emitted photons, and (iii) a sample. - - :ref:`NXellipsometry`: - An application definition for ellipsometry measurements, including complex systems up to variable angle spectroscopic ellipsometry. - - :ref:`NXraman`: - An application definition for Raman spectroscopy measurements. - - -Base Classes ------------- - -This is the set of base classes for describing an optical experiment. - - :ref:`NXbeam_device` - Beam devices are used to relate a beam, which has always at least one origin - and at least one destination. - - By referencing the beam devices with each other, a beam path can be - constructed. This can be used for vizualization or beam propery modeling - along the beam path. - - :ref:`NXbeam` - Beam properties such as intensity, polarization, wavelength or direction. - - :ref:`NXdetector` - A detector for signal detection. - - :ref:`NXsource` - A light source such as laser, lamp or LED. - - :ref:`NXmonochromator` - A monochromator is often used to energetically disperse the scattered or emitted light. - - :ref:`NXlens_opt` - Description of an optical lens. - - :ref:`NXwaveplate` - A waveplate or retarder. - - :ref:`NXsensor` - Specify external parameters that have influenced the sample such as - varied parameters e.g. temperature, pressure, pH value, beam intensity, etc. - - - -.. _DispersiveMaterial-BC: - -Dispersive Material -################### - -A dispersive material is a description for the optical dispersion of materials. -This description may be used to store optical model data from an ellipsometric analysis -(or any other technique) or to build a database of optical constants for optical properties of materials. - -Application Definition ----------------------- - - :ref:`NXdispersive_material`: - An application definition to describe the dispersive properties of a material. - The material may be isotropic, uniaxial or biaxial. Hence, it may contain up - to three dispersive functions or tables. - - - -Base Classes ------------- - -There is a set of base classes for describing a dispersion. - - :ref:`NXdispersion` - This is an umbrella base class for a group of dispersion functions to describe the material. - For a simple dispersion it may contain only on NXdispersion_function or NXdispersion_table entry. - If it contains multiple entries the actual dispersion is the sum of all dispersion functions and tables. - This allows for, e.g. splitting real and imaginary parts and describing them seperately or - adding a dielectric background (e.g. Sellmeier model) to an oscillator model (e.g. Lorentz). - - :ref:`NXdispersion_function` - This dispersion is described by a function and its single and repeated parameter values. - It follows a formula of the form ``eps = eps_inf + sum[A * lambda ** 2 / (lambda ** 2 - B ** 2)]`` - (Sellmeier formula). See the formula grammar below for an ebnf grammar for this form. - - :ref:`NXdispersion_single_parameter` - This denotes a parameter which is used outside the summed part of a dispersion function, - e.g. ``eps_inf`` in the formula example above. - - :ref:`NXdispersion_repeated_parameter` - This denotes arrays of repeated parameters which are used to build a sum of parameter values, e.g. - ``A`` and ``B`` are repeated parameters in the formula above. - - :ref:`NXdispersion_table` - This describes a tabular dispersion where the dielectric function is an array versus wavelength or energy. - -Formula Grammar ---------------- - -Below you find a grammar to which the formula should adhere and which can be used to parse and -evaluate the dispersion function. The terms ``single_param_name`` and ``param_name`` should be -filled with the respective single and repeated params from the stored data. -The grammer is written in the `EBNF `_ dialect -of `Lark `_, which is a parsing toolkit for python. -It is easily translatable to general EBNF and other parser generator dialects. -`Here `_ is a reference implementation in Rust/Python with a -`grammar `_ -written in `lalrpop `_. - -.. code-block:: - - ?assignment: "eps" "=" kkr_expression -> eps - | "n" "=" kkr_expression -> n - - ?kkr_expression: expression - | "" "+" "1j" "*" term -> kkr_term - - ?expression: term - | expression "+" term -> add - | expression "-" term -> sub - - ?term: factor - | term "*" factor -> mul - | term "/" factor -> div - - ?factor: power - | power "**" power -> power - - - ?power: "(" expression ")" - | FUNC "(" expression ")" -> func - | "sum" "[" repeated_expression "]" -> sum_expr - | NAME -> single_param_name - | SIGNED_NUMBER -> number - | BUILTIN -> builtin - - ?repeated_expression: repeated_term - | repeated_expression "+" repeated_term -> add - | repeated_expression "-" repeated_term -> sub - - - ?repeated_term: repeated_factor - | repeated_term "*" repeated_factor -> mul - | repeated_term "/" repeated_factor -> div - - ?repeated_factor: repeated_power - | repeated_power "**" repeated_power -> power - - ?repeated_power: "(" repeated_expression ")" - | FUNC "(" repeated_expression ")" -> func - | SIGNED_NUMBER -> number - | NAME -> param_name - | BUILTIN -> builtin - - FUNC.1: "sin" | "cos" | "tan" | "sqrt" | "dawsn" | "ln" | "log" | "heaviside" - BUILTIN.1: "1j" | "pi" | "eps_0" | "hbar" | "h" | "c" - - %import common.CNAME -> NAME - %import common.SIGNED_NUMBER - %import common.WS_INLINE - - %ignore WS_INLINE - diff --git a/manual/source/classes/contributed_definitions/apm-structure.rst b/manual/source/classes/contributed_definitions/apm-structure.rst index 2cbeaae4a3..10e2c77c36 100644 --- a/manual/source/classes/contributed_definitions/apm-structure.rst +++ b/manual/source/classes/contributed_definitions/apm-structure.rst @@ -1,35 +1,38 @@ .. _Apm-Structure: -===================== +========================= Atom-probe tomography -===================== +========================= .. index:: IntroductionApm ApmAppDef ApmBC - StatusQuoApm + WhatHasBeenAchieved ApmParaprobeAppDef - ApmGermanNfdi + ApmParaprobeNewBC + NextStep + + + .. _IntroductionApm: Introduction -############ +############## -Set of data schemas to describe the acquisition, i.e. measurement side, the extraction of hits from detector raw data, -steps to compute mass-to-charge state ratios from uncorrected time of flight data, the reconstruction, and the ranging, i.e. identification of peaks in the mass-to-charge-state ratio histogram to detect (molecular) ions. -The data schemas can be useful to generate data artifacts also for field-ion microscopy experiments. +Set of data storage objects to describe the acquisition/measurement side, the reconstruction, and the ranging for atom probe microscopy experiments. The data storage objects can be useful as well for field-ion microscopy experiments. .. _ApmAppDef: Application Definition ###################### +It is proposed to use one application definition to serve atom probe tomography +and field-ion microscopy measurements, i.e. the data collection with the instrument: + :ref:`NXapm`: - A general application definition with many detailed places for leaving metadata and computational steps described which are commonly used when reporting the measurement of atom probe data including also detector hit data, as well as how to proceed with reconstructing atom positions from these data, and how to store details about definitions made, which describe how mass-to-charge-state ratio values are mapped to iontypes in a process called ranging. The structure of the schema has been designed to also document a simulation of an atom probe - experiment. Having a combined schema for the measurement and the simulation is beneficial to document that - there are many similarities between the measurement and a computer simulation of it. + A general application definition with many detailed places for leaving metadata and computational steps described which are commonly used when reporting the measurement of atom probe data including also detector hit data, as well as how to proceed with reconstructing atom positions from these data, and how to store details about definitions made, which describe how mass-to-charge-state ratio values are mapped to iontypes in a process called ranging. .. _ApmBC: @@ -40,245 +43,284 @@ The following base classes are proposed to support modularizing the storage of p :ref:`NXchamber`: A base class to describe a component of the instrument which houses other components. - A chamber may offer a controlled atmosphere to execute an experiment and/or offer functionalities - for storing and loading specimens. + A chamber may offer a controlled atmosphere to execute an experiment and/or offer functionalities for storing and loading specimens. - :ref:`NXcoordinate_system_set`, :ref:`NXcoordinate_system`: - Base classes to describe different coordinate systems used and/or to be harmonized + :ref:`NXcoordinate_system_set` + A base class to describe different coordinate systems used and/or to be harmonized or transformed into one another when interpreting the dataset. - :ref:`NXion`: (about to become replaced by :ref:`NXatom_set`) - A base class to describe molecular ions with an adjustable number of atoms/isotopes building each ion. - For the usage in atom probe research the maximum number of atoms supported building a molecular ion - is currently set to a maximum of 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with - which all possible nuclides (stable, radioactive, or synthetically generated ones) can be described. + :ref:`NXion`: + A base class to describe charged molecular ions with an adjustable number of atoms/isotopes building each ion. Right now the maximum number of atoms supported building a molecular ion + is 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with + which all possible isotopes can be described. :ref:`NXfabrication`: - A base class to bundle manufacturer/technology-partner-specific details about - a component or device of an instrument. + A base class to bundle manufacturer/technology-partner-specific details about a + component or device of an instrument. - :ref:`NXpeak`: (about to become complemented by NXpeak_fitting) + :ref:`NXpeak`: A base class to describe peaks mathematically to detail how peaks in - mass-to-charge-state ratio histograms (aka mass spectra) are defined and - labelled as iontypes. + mass-to-charge-state ratio histograms (aka mass spectra) are + defined and labelled as iontypes. :ref:`NXpump`: - A base class to describe details about pump(s) used as components of an instrument. + A base class to describe details about pump(s) of an instrument. :ref:`NXpulser_apm`: - A base class to describe the high-voltage and/or laser pulsing capabilities. + A base class to describe the high-voltage and/or laser pulsing capabilities of + an atom probe microscope. :ref:`NXreflectron`: A base class to describe a kinetic-energy-sensitive filtering device - for time-of-flight (ToF) mass spectrometry. + for time of flight (ToF) mass spectrometry. :ref:`NXstage_lab`: A base class to describe the specimen fixture including the cryo-head. - Nowadays, stages of microscopes represent small-scale laboratory platforms. + Nowadays, these stages represent small-scale laboratory platforms. Therefore, there is a need to define the characteristics of such stages in more detail, especially in light of in-situ experiments. Many similarities exists between a stage - in an electron microscope and one in an atom probe instrument. Both offer fixture - functionalities and additional components for applying e.g. stimuli on the specimen. - -Microscopy experiments, not only taking into account those performed on commercial instruments, offer users to apply a set of -data processing steps. Some of them are frequently applied on-the-fly. For now we represent these steps with specifically named -instances of the :ref:`NXprocess` base class. - -Several base classes were defined to document processing of atom probe data with established algorithms: - - :ref:`NXapm_hit_finding`: - A base class to describe hit finding algorithm. + in an electron microscope and one in an atom probe instrument. Both offer fixture functionalities and additional components for applying e.g. stimuli on the specimen. - :ref:`NXapm_volt_and_bowl`: - A base class to describe the voltage-and-bowl correction. +Microscopy experiments, not only taking into account those performed on commercial instruments, offer the user usually to apply a set of data processing steps. Some of them are frequently applied on-the-fly. For now we represent these steps with specifically named instances of the :ref:`NXprocess` base class. - :ref:`NXapm_charge_state_analysis`: - A base class to document the resolving of the charge_state. - :ref:`NXapm_reconstruction`: - A base class to document the tomographic reconstruction algorithm. - - :ref:`NXapm_ranging`: - A base class to document the ranging process. - - :ref:`NXapm_msr`, :ref:`NXapm_sim`: - Respective base classes that serve as templates to compose the :ref:`NXapm` application definition from. - -These base classes are examples that substantiate that data processing steps are essential to transform atom probe measurements or simulations into knowledge. Therefore, these steps should be documented -to enable reproducible research, if possible even numerical reproducibility of the results, -and learn how pieces of information are connected. In what follows, an example is presented how an -open-source community software can be modified to use descriptions of these computational steps. - -A detailed inspection of spatial and other type of filters frequently used in analysis of atom probe -data revealed that it is better to define atom-probe-agnostic reusable concepts for filters: - - :ref:`NXspatial_filter`: - A base class proposing how a point cloud can be spatially filtered in a specific yet general manner. - This base class takes advantage of :ref:`NXcg_ellipsoid_set`, :ref:`NXcg_cylinder_set`, - and :ref:`NXcg_hexahedron_set` to cater for commonly used geometric primitives in atom probe. - The primitives are used for defining the shape and extent of a region of interest (ROI). - - :ref:`NXsubsampling_filter`: - A base class for a filter that can also be used for specifying how entries - like ions can be filtered via sub-sampling. - - :ref:`NXmatch_filter`: - A base class for a filter that can also be used for specifying how entries - like ions can be filtered based on their type or other descriptors like hit multiplicity. - -The respective research software here is the `paraprobe-toolbox `_ -The software is developed by `M. Kühbach et al. `_. -For atom probe research the proposal can also serve as a blue print how computational steps of other software -tool including commercial ones could be developed further to benefit from NeXus. +Like every research community data processing steps are essential to transform measurements +into knowledge. These processing steps should be documented to enable reproducible research +and learn how pieces of information were connected. In what follows, an example is presented +how an open-source community software can be modified to use descriptions of these computational +steps. The respective research software here is the `paraprobe-toolbox `_ .. _IntroductionApmParaprobe: apmtools ######## -The paraprobe-toolbox is an example of an open-source parallelized software for analyzing -point cloud data, for assessing meshes in 3D continuum space, and for studying the effects of -parameterization on descriptors of micro- and nanoscale structural features (crystal defects) -within materials when characterized and studied with atom probe. +One tool is the paraprobe-toolbox software package in the the apmtools container. +The software is developed by `M. Kühbach et al. `_. + +Here we show how NeXus is used to consistently define application definitions for scientific software +in the field of atom probe. In this community the paraprobe-toolbox is an example of an +open-source parallelized software for analyzing point cloud data, for assessing meshes in +3D continuum space, and for studying the effects of parameterization on descriptors +which describe the micro- and nanostructure of materials that are studied with +atom probe microscopy. The need for a thorough documentation of the tools in not only the paraprobe-toolbox was motivated by several needs: -First, users of software would like to better understand and also be able to study for themselves -which individual parameters and settings for each tool exist and how configuring these -affects analyses quantitatively. This stresses the aspect how to improve documentation. +First, users of software would like to better understand and also be able to +study for themselves which individual parameters and settings for each tool exist +and how configuring these affects their analyses quantitatively. -Second, scientific software like paraprobe-toolbox implement numerical/algorithmical -(computational) workflows whereby data coming from multiple input sources -(like previous analysis results) are processed and carried through more involved analyses -within several steps inside the tool. The tool then creates output as files. This -provenance and workflow should be documented. +Second, scientific software like the tools in the paraprobe-toolbox implement a +numerical/algorithmical (computational) workflow whereby data from multiple input sources +(like previous analysis results) are processed and carried through more involved analysis +within several steps inside the tool. The tool then creates output as files. Individual tools of paraprobe-toolbox are developed in C/C++ and/or Python. Provenance tracking is useful as it is one component and requirement for making -workflows exactly numerically reproducible and thus to enable reproducibility (the "R" -of the FAIR principles of data stewardship). +workflows exactly numerically reproducible and thereby empower scientists +to fulfill better the "R", i.e. reproducibility of their daily FAIR research practices. -For tools of the paraprobe-toolbox each workflow step is a pair or triple of sub-steps: -1. The creation of a configuration file. -2. The actual analysis using the Python/or C/C++ tools. -3. The optional analyses/visualization of the results based on data in NeXus/HDF5 files generated by each tool. +The paraprobe-toolbox is one example of a software which implements a workflow +via a sequence of operations executed within a jupyter notebook +(or Python script respectively). Specifically, individual tools are chained. +Convenience functions are available to create well-defined input/configuration +files for each tool. These config files instruct the tool upon processing. -.. _StatusQuoApm: +In this design, each workflow step (with a tool) is in fact a pair (or triple) of +at least two sub-steps: i) the creation of a configuration file, +ii) the actual analysis using the Python/or C/C++ tools, +iii) the optional post-processing/visualizing of the results inside the NeXus/HDF5 +files generated from each tool run using other software. -What has been achieved so far? -############################## -This proposal summarizes work of members of the FAIRmat project, which is part of the `German -National Research Data Infrastructure `_. The here detailed -proposal documents how all tools of the paraprobe-toolbox were modified to generate -only well-defined configuration files as accepted input and yield specifically formatted output -files according to the following NeXus application definitions. +.. _WhatHasBeenAchieved: -Data and metadata between the tools are exchanged with NeXus/HDF5 files. This means that data -inside HDF5 binary containers are named, formatted, and hierarchically structured according -to application definitions. +What has been achieved so far? +############################## -For example the application definition NXapm_paraprobe_config_surfacer specifies +This proposal summarizes work of members of the FAIRmat project, which is part +of the German National Research Data Infrastructure aimed at a change of the paraprobe-toolbox +and its interaction with files for all tools so that only well-defined configuration files +are accepted as input and results end up as specifically formatted output. For this +NeXus application definitions are used. + +Data and metadata between the tools are exchanged with NeXus/HDF5 files. +Specifically, we created for each tool an application definition (see below) +which details all possible settings and options for the configuration as to +guide users. The config(uration) files are currently implemented as HDF5 files, +whose content matches to the naming conventions of the respective `config` application +definition for each tool. As an example NXapm_paraprobe_config_surfacer specifies how a configuration file for the paraprobe-surfacer tool should be formatted -and which parameters it contains including optionality and cardinality constraints. +and which parameter it should and/or may contain. -Thereby, each config file uses a controlled vocabulary of terms. Furthermore, -the config files store a SHA256 checksum for each input file. This implements a full -provenance tracking on the input files along the workflow. +That is each config file uses a controlled vocabulary of terms. Furthermore, +the config files store a SHA256 checksum for each input file. +This implements a full provenance tracking on the input files along the +processing chain/workflow. -As an example, a user may first range their reconstruction and then compute spatial +As an example, a user may first range their reconstruction and then compute correlation functions. The config file for the ranging tool stores the files which hold the reconstructed ion position and ranging definitions. -The ranging tool generates a results file with the labels of each molecular ion. +The ranging tool generates a results file with the ion type labels stored. This results file is formatted according to the tool-specific `results` -application definition. The generated results file and the reconstruction is -imported by the spatial statistics tool which again keeps track of all files -and reports its results in a spatial statistics tool results file. - -This design makes it possible to rigorously trace which numerical results were achieved -with specific inputs and settings using specifically-versioned tools. Noteworthy -this includes Y-junction on a graph which is where multiple input sources are -combined to generate new results. +application definition. This results file and the reconstruction is +imported by the spatial statistics tool which again keeps track of all files. -We are convinced that defining, documenting, using, and sharing application definitions -is useful and future-proof strategy for software development and data analyses as it enables -automated provenance tracking which happens silently in the background. +This design makes it possible to rigorously trace which numerical results +were achieved with a specific input and settings using specifically-versioned tools. -Base classes have been defined to group common pieces of information for each tool of the -toolbox. For each tool we define a pair of base classes. One for the configuration (input) side -and one for the results (output) side: +We understand that this additional handling of metadata and provenance tracking +may not be at first glance super relevant for scientists or appears to be an +unnecessarily complex feature. There is indeed an additional layer of work which +came with the development and maintenance of this functionality. - :ref:`NXapm_paraprobe_tool_config`, :ref:`NXapm_paraprobe_tool_results`, :ref:`NXapm_paraprobe_tool_common`: - Configuration, results, and common parts respectively useful for the application definitions for tools of the paraprobe-toolbox. +However, we are convinced that this is the preferred way of performing software +development and data analyses as it enables users to take advantage of a completely +automated provenance tracking which happens silently in the background. .. _ApmParaprobeAppDef: Application Definitions ####################### -NXapm_paraprobe application definitions are in fact pairs of application definitions. -One for the configuration (input) side and one for the results (output) side. For each -tool one such pair is proposed: +Application definitions for the input side (configuration) of each tool were defined. - :ref:`NXapm_paraprobe_transcoder_config`, :ref:`NXapm_paraprobe_transcoder_results`: - Configuration and the results respectively of the paraprobe-transcoder tool. - Load POS, ePOS, APSuite APT, RRNG, RNG, and NeXus NXapm files. - Store reconstructed positions, ions, and charge states. + :ref:`NXapm_paraprobe_config_transcoder`: + Configuration of paraprobe-transcoder + Load POS, ePOS, APSuite APT, RRNG, RNG, and NXapm HDF5 files. - :ref:`NXapm_paraprobe_ranger_config`, :ref:`NXapm_paraprobe_ranger_results`: - Configuration and results respectively of the paraprobe-ranger tool. + :ref:`NXapm_paraprobe_config_ranger`: + Configuration of paraprobe-ranger Apply ranging definitions and explore possible molecular ions. - Store applied ranging definitions and combinatorial analyses of possible iontypes. - :ref:`NXapm_paraprobe_selector_config`, :ref:`NXapm_paraprobe_selector_results`: - Configuration and results respectively of the paraprobe-selector tool. + :ref:`NXapm_paraprobe_config_selector`: + Configuration of paraprobe-selector Defining complex spatial regions-of-interest to filter reconstructed datasets. + + :ref:`NXapm_paraprobe_config_surfacer`: + Configuration of paraprobe-surfacer + Create a model for the edge of a point cloud via convex hulls, alpha shapes. + + :ref:`NXapm_paraprobe_config_distancer`: + Configuration of paraprobe-distancer + Compute analytical distances between ions to a set of triangles. + + :ref:`NXapm_paraprobe_config_tessellator`: + Configuration of paraprobe-tessellator + Compute Voronoi cells for if desired all ions in a dataset. + + :ref:`NXapm_paraprobe_config_nanochem`: + Configuration of paraprobe-nanochem + Compute delocalization, iso-surfaces, analyze 3D objects, and composition profiles. + + :ref:`NXapm_paraprobe_config_intersector`: + Configuration of paraprobe-intersector + Assess intersections and proximity of 3D triangulated surface meshes in + continuum space to study the effect the parameterization of surface + extraction algorithms on the resulting shape, spatial arrangement, + and colocation of 3D objects via graph-based techniques. + + :ref:`NXapm_paraprobe_config_spatstat`: + Configuration of paraprobe-spatstat + Spatial statistics on the entire or selected regions of the reconstructed dataset. + + :ref:`NXapm_paraprobe_config_clusterer`: + Configuration of paraprobe-clusterer + Import cluster analysis results of IVAS/APSuite and perform clustering + analyses in a Python ecosystem. + +Application definitions for the output side (results) of each tool were defined. + + :ref:`NXapm_paraprobe_results_transcoder`: + Results of paraprobe-transcoder + Store reconstructed positions, ions, and charge states. + + :ref:`NXapm_paraprobe_results_ranger`: + Results of paraprobe-ranger + Store applied ranging definitions and combinatorial analyses of all possible iontypes. + + :ref:`NXapm_paraprobe_results_selector`: + Results of paraprobe-selector Store which points are inside or on the boundary of complex spatial regions-of-interest. - :ref:`NXapm_paraprobe_surfacer_config`, :ref:`NXapm_paraprobe_surfacer_results`: - Configuration and results respectively of the paraprobe-surfacer tool. - Create a model for the edge of a point cloud via convex hulls, alpha shapes, or alpha-wrappings. + :ref:`NXapm_paraprobe_results_surfacer`: + Results of paraprobe-surfacer Store triangulated surface meshes of models for the edge of a dataset. - :ref:`NXapm_paraprobe_distancer_config`, :ref:`NXapm_paraprobe_distancer_results`: - Configuration and results respectively of the paraprobe-distancer tool. - Compute and store analytical distances between ions to a set of triangles. + :ref:`NXapm_paraprobe_results_distancer`: + Results of paraprobe-distancer + Store analytical distances between ions to a set of triangles. - :ref:`NXapm_paraprobe_tessellator_config`, :ref:`NXapm_paraprobe_tessellator_results`: - Configuration and results respectively of the paraprobe-tessellator tool. - Compute and store Voronoi cells and properties of these for all ions in a dataset. + :ref:`NXapm_paraprobe_results_tessellator`: + Results of paraprobe-tessellator + Store volume of all Voronoi cells about each ion in the dataset. - :ref:`NXapm_paraprobe_spatstat_config`, :ref:`NXapm_paraprobe_spatstat_results`: - Configuration and results respectively of the paraprobe-spatstat tool. - Compute spatial statistics on the entire or selected regions of the reconstructed dataset. + :ref:`NXapm_paraprobe_results_nanochem`: + Results of paraprobe-nanochem + Store all results of delocalization, isosurface, and interface detection algorithms, + store all extracted triangulated surface meshes of found microstructural features, + store composition profiles and corresponding geometric primitives (ROIs). - :ref:`NXapm_paraprobe_clusterer_config`, :ref:`NXapm_paraprobe_clusterer_results`: - Configuration and results resepctively of the paraprobe-clusterer tool. - Compute cluster analyses with established machine learning algorithms using CPU or GPUs. + :ref:`NXapm_paraprobe_results_intersector`: + Results of paraprobe-intersector + Store graph of microstructural features and relations/link identified between them. - :ref:`NXapm_paraprobe_nanochem_config`, :ref:`NXapm_paraprobe_nanochem_results`: - Configuration and results resepctively of the paraprobe-nanochem tool. - Compute delocalization, iso-surfaces, analyze 3D objects, composition profiles, and mesh interfaces. + :ref:`NXapm_paraprobe_results_spatstat`: + Results of paraprobe-spatstat + Store spatial correlation functions. - :ref:`NXapm_paraprobe_intersector_config`, :ref:`NXapm_paraprobe_intersector_results`: - Configuration and results resepctively of the paraprobe-intersector tool. - Analyze volumetric intersections and proximity of 3D objects discretized as triangulated surface meshes - in continuum space to study the effect the parameterization of surface extraction algorithms on the resulting shape, - spatial arrangement, and colocation of 3D objects via graph-based techniques. + :ref:`NXapm_paraprobe_results_clusterer`: + Results of paraprobe-clusterer + Store results of cluster analyses. -.. _ApmGermanNfdi: +.. _ApmParaprobeNewBC: -Joint work German NFDI consortia NFDI-MatWerk and FAIRmat -####################################################################### +Base Classes +############ + +We envision that the above-mentioned definitions can be useful not only to take +inspiration for other software tools in the field of atom probe but also to support +a discussion towards a stronger standardization of the vocabulary used. +Therefore, we are happy for comments and suggestions. + +The majority of data analyses in atom probe use a common set of operations and +conditions on the input data even though this might not be immediately evident +or might not have been so explicitly communicated in the literature. +Some tools have a specific scope because of which algorithms are hardcoded +to work for specific material systems. A typical example is a ranging tool +which exploits that all the examples it is used for apply to a specific material +and thus specific iontypes can be hardcoded. + +Instead, we are convinced it is better to follow a more generalized approach. +The following base classes and the above application definitions present examples +how one can use NeXus for this. + + :ref:`NXapm_input_reconstruction`: + A description from which file the reconstructed ion positions are imported. + + :ref:`NXapm_input_ranging`: + A description from which file the ranging definitions are imported. + The design of the ranging definitions is, thanks to :ref:`NXion`, so + general that all possible nuclids can be considered, be they observationally + stable, be they radioactive or transuranium nuclids. -Members of the NFDI-MatWerk and the FAIRmat consortium of the German National Research Data Infrastructure -are working together within the Infrastructure Use Case IUC09 of the NFDI-MatWerk project to work on examples -how software tools in both consortia become better documented and interoperable to use. Within this project, -we have also added the `CompositionSpace tool that has been developed at the Max-Planck-Institut für Eisenforschung -GmbH in Düsseldorf `_ by A. Saxena et al. +A detailed inspection of spatial and other type of filters frequently used in +analysis of atom probe data revealed that it is better to define atom-probe-agnostic, +i.e. more general filters: -Specifically, within the IUC09 we refactored the code base behind the publication `A. Saxena et al. `_ to better document its configuration, here as an example implemented like for the above-mentioned paraprobe-toolbox using NeXus: - - :ref:`NXapm_compositionspace_config`, :ref:`NXapm_compositionspace_results`: - Configuration and the results respectively of the CompositionSpace tool. + :ref:`NXspatial_filter`: + A proposal how a point cloud can be spatially filtered in a specific yet general manner. + This base class takes advantage of :ref:`NXcg_ellipsoid_set`, :ref:`NXcg_cylinder_set`, + and :ref:`NXcg_hexahedron_set` to cater for all of the most commonly used + geometric primitives in atom probe. + + :ref:`NXsubsampling_filter`: + A proposal for a filter that can also be used for specifying how entries + like ions can be filtered via sub-sampling. + + :ref:`NXmatch_filter`: + A proposal for a filter that can also be used for specifying how entries + like ions can be filtered based on their type (ion species) + or hit multiplicity. diff --git a/manual/source/classes/contributed_definitions/cgms-structure.rst b/manual/source/classes/contributed_definitions/cgms-structure.rst index 53f57dc8c9..6190f0a30d 100644 --- a/manual/source/classes/contributed_definitions/cgms-structure.rst +++ b/manual/source/classes/contributed_definitions/cgms-structure.rst @@ -1,14 +1,15 @@ .. _CgmsFeatures-Structure: -============================ -Geometry and microstructures -============================ +========================= +Geometry & Microstructure +========================= .. index:: IntroductionCgms PhysicsCgms CgmsAppDef CgmsBC + IcmeMsModels .. _IntroductionCgms: @@ -19,23 +20,30 @@ Introduction The computational-geometry/microstructure-modeling-based part of the proposal has the following aims: -First, to contribute to efforts on standardizing a controlled vocabulary, definitions for terms, -and relations between terms, for computational-geometry-based descriptions of the structure of -materials and atomic configurations used when characterizing materials in experiments +First, we would like to contribute to efforts on standardizing a controlled +vocabulary, definitions for these terms, and relations between the terms, for +computational-geometry-based descriptions of the structure of materials and +atomic configurations used when characterizing materials in experiments and computer simulations. -As far as NeXus is concerned, this proposed set of geometric primitives offer -a complementary alternative to the current set of base classes in NeXus for -constructive solid geometry (CSG) such as :ref:`NXcsg`, :ref:`NXoff_geometry`, or :ref:`NXquadric`. +As far as NeXus is concerned, this proposed set of simple geometric primitives +and shapes offer a complementary alternative to the current set of base classes in +NeXus for constructive solid geometry such as :ref:`NXcsg`, :ref:`NXoff_geometry`, +or :ref:`NXquadric` to name but a few. -Second, to explore how terms which are frequently used by materials scientists in the field of -condensed-matter physics can be harmonized with definitions and terms offer by the NOMAD MetaInfo -description. NOMAD MetaInfo is the data schema of the NOMAD research data management system. +Second, we would like to explore with this proposal how we can harmonize terms +frequently used by materials scientists in the field of condensed-matter physics +with definitions and terms offer by the NOMAD MetaInfo description. -Third, to yield a substantiated set of arguments and suggestions how descriptors for the structure -and the atomic architecture of materials can be harmonized. Especially this proposal reaches out to -other materials-science-related projects and consortia including the activities in the German NFDI -FAIRmat, NFDI-MatWerk, NFDI4Ing, NFDI4Chem, NFDI4Cat, MaRDI, and DAPHNE. +Third, the proposal should yield a substantiated set of arguments and suggestions +how descriptors for the structure and atomic architecture of materials can be +harmonized. With this we especially would like to reach out and intensify the +cooperation between the materials-science-related consortia of the German +National Research Infrastructure, specifically, FAIRmat, NFDI-MatWerk, NFDI4Ing, +NFDI4Chem, NFDI4Cat, MaRDi, and DAPHNE. + +.. The proposal reaches out to our colleagues in the materials engineering-based +.. consortia to document that there is value in discussing about controlled vocabulary. .. _PhysicsCgms: @@ -43,37 +51,47 @@ Physics background ################## Microstructural features or crystal defects are spatial arrangements of atoms. Given their specific atomic arrangement and composition, such features have -specific constraints on the degrees of freedom. This causes these defects to have specific -properties (thermodynamic observables/descriptors). Provided well-defined coarse-graining procedures -are used and regions-of-interest and/or regions-of-applicability are defined, microstructural -features are often characterized and modelled to have associated thermodynamic descriptors. +specific constraints on the degrees of freedom how atoms can arrange. This causes +these defects to have specific properties. +Provided well-defined coarse-graining procedures are used and regions-of-interest +and/or regions-of-applicability are defined, microstructural features are often +characterized and modelled to have associated thermodynamic descriptors. Another motivation for the proposal was the observation that frequently the design of file formats for simulation software in the computational materials science especially -at the interface between condensed-matter physics and materials engineering are frequently -reimplementing the wheel when it comes to making decision how to store e.g. atom and feature positions -or how to document the shape of regions-of-interest, grids, crystals, grains, precipitates, and dislocations. -This generates a diversity of file formats and data schemas which hampers semantic interpretation -and interoperability. - -Maybe this is a historical burden given the large set of technical terms in place which then -motivated pragmatic solutions that have resulted in many research groups having developed -similar formats using similar descriptions. - -Defining crystal defects is a question of how to coarse-grain a given spatiotemporal set of atoms, -each having a nuclide type and position/trajectory. Different mathematical/geometrical methods exists -to determine how a point, a line, a surface, or a volumetric defect can be described and be spatiotemporally constrained through a geometrical model -with defined primitives and associated observables. - -The key motivation to such coarse-graining is to reduce the complexity of the description. -On the one hand to support visualization and scientific analyses - not only of crystal defect arrangements. -On the other hand it is the hope that using descriptors at a coarser level, i.e. nanometer, micrometer, and larger, -are still sufficiently accurate and precise to yield descriptors which avoid that one has -to account for the dynamics of each atom to predict or understand the properties -of defects and their dynamics. - -Experience has shown that computational-geometry-based descriptions -when combined with hierarchical clustering/labeling methods, applied on sets of +those tools at the interface between condensed-matter physics and materials engineering +are frequently reimplementing the wheel (at least partly) when it comes to decide how to store +e.g. atom and feature positions or shape of regions-of-interest, grids, crystals, +grains, precipitates, and dislocations. + +Maybe this is a historical burden given the large set of technical terms and jargon +in place, which then motivated pragmatic solutions that resulted in many research groups +have developed similar formats using similar descriptions. + +We see this work on base classes and application definitions not primarily an +effort to improve and extend NeXus for now. Rather this part of the proposal +is an effort to support activities in materials science to work towards +common terminology and using controlled vocabularies more frequently. +These are the foundation for more sophisticated thoughts about practically +useful ontologies. + +Defining crystal defects is a question of how to coarse-grain a given spatiotemporal +set of atoms, each having a nuclide type and position/trajectory. Different mathematical/geometrical +methods exists to coarse-grain and thus determine how a point, a line, a surface, or +a volumetric defect can be described and be spatiotemporally constrained through +a geometrical model with defined geometric primitives and associated (materials) +properties at a coarser-scale. + +The key motivation to such coarse-graining is to reduce the complexity of the +description. On the one hand to support visualization and scientific analyses - not only +of crystal defect arrangements. On the other hand it is the hope that using descriptors +at a coarser level, i.e. nanometre, micrometre, and larger, it is still possible +to find sufficiently accurate and precise descriptors that avoid one having to account +for the dynamics of each atom to predict or understand the properties of defects +and their dynamics. + +Nevertheless, experience has shown that computational-geometry-based descriptions +when combined with hierarchical clustering/labeling methods, applied on set of atoms and features turn out to yield useful descriptors. Examples include point, line, surface defects, such as vacancies, solute cluster, dislocations, disconnections, interfaces to name but a few. @@ -83,125 +101,184 @@ disconnections, interfaces to name but a few. Base Classes ############ -The following base classes are defined to incentivize the use of NeXus for using -computational-geometry-based descriptions. In what follows, base classes +The following base classes are defined to incentivize the use of NeXus for +using computational-geometry-based descriptions. In what follows, base classes for frequently used shapes and geometric primitives are proposed: - :ref:`NXcg_primitive_set`: - A base class to inherit from when defining base classes for specific primitives such as these: - :ref:`NXcg_sphere_set`: - A base class for a set of possibly dissimilar spheres. + A description for a set of possibly dissimilar spheres. :ref:`NXcg_ellipsoid_set`: - A base class for a set of possibly dissimilar rotated ellipsoids. + A description for a set of possibly dissimilar oriented ellipsoids. :ref:`NXcg_cylinder_set`: - A base class for a set of possibly dissimilar rotated cylinders. + A description for a set of possibly dissimilar oriented cylinders. :ref:`NXcg_point_set`: - A base class for a collection of points with labels or mark data. + A collection of points with labels. :ref:`NXcg_polyline_set`: - A base class for a collection of lines and linearized segments. + A collection of lines and linear segments. :ref:`NXcg_triangle_set`: - A base class for a collection (or soup) of triangles. + A collection of triangles. :ref:`NXcg_parallelogram_set`: - A base class for a collection of possibly dissimilar parallelograms. + A collection of possibly dissimilar parallelograms. :ref:`NXcg_triangulated_surface_mesh`: - A base class for a collection and/or mesh of triangles. + A mesh of triangles. :ref:`NXcg_polygon_set`: - A base class for a collection (or soup) of polygons. + A collection of polygons. :ref:`NXcg_polyhedron_set`: - A base class for a collection (or soup) of polyhedra. + A collection of polyhedra. :ref:`NXcg_roi_set`: A container to host a number of different types of primitives. :ref:`NXcg_tetrahedron_set`: - A base class for a collection (or soup) of tetrahedra. + A collection of tetrahedra. :ref:`NXcg_hexahedron_set`: - A base class for a collection (or soup) of hexahedra to represent - e.g. simpler (bounding) boxes for e.g. binary trees. + A collection of hexahedra with capabilities to represent + also simpler (bounding) boxes for e.g. binary trees. -These base classes make use of base classes which describe data structures: +These base classes describe data structures used for more complex geometries: :ref:`NXcg_face_list_data_structure`: - A base class to store the usual way how polygon/polyhedra data are reported: - Via a list of vertices and faces with identifiers and properties. + In essence, the usual way how polygon/polyhedra data are reported: + A list of vertices and faces with identifier and properties. :ref:`NXcg_half_edge_data_structure`: - A base class for more advanced but more efficiently traversable data structure: - A half-edge data structure is a useful complementary descriptor for - polygon/polyhedra which enables topological analyses and traversal of half-edges - about a topology of primitives. + A half-edge data structure (also known as a doubly connected edge list) + is a useful complementary descriptor for polygon/polyhedra which enables + topological analyses and traversal of the graph of how polygons and + polyhedra are connected. :ref:`NXcg_unit_normal_set`: - A base class for storing primitive unit normal vectors. + As an additional structuring element especially for meshes, well-documented + normal information is crucial for distance computations. :ref:`NXcg_geodesic_mesh`: - Geodesic meshes are useful for all applications when meshing the surface of a sphere - with many applications in the analyses of diffraction data. + Geodesic meshes are useful for all applications when meshing the surface + of a sphere. :ref:`NXcg_alpha_complex`: Alpha shapes and alpha wrappings, specifically the special case of the convex hull, are frequently used geometrical models for describing a boundary or edge to a set of geometric primitives. -Furthermore, a few base classes are defined for documenting the working with -discretized representations of material (area or volume) which can be useful -not only for stencil-based methods: +Next, a few base classes are defined for documenting discretized representations +of material (area or volume) which can be useful not only for stencil-based methods: :ref:`NXcg_grid`: - A base class for a grid of cells discretizing e.g. a computational domain - or computation with models using representative volume elements (RVEs). + A grid of cells. :ref:`NXisocontour`: - A base class for isocontour descriptions. + A description for isocontour descriptions. :ref:`NXcg_marching_cubes`: - A base class to store metadata of a specific implementation of + An approach to store metadata of a specific implementation of the Marching Cubes algorithm, whose sensitivity to specific topological - configurations is known to result in different triangle soups. - This is relevant e.g. for computations of isocontours. + configurations is known to result in different triangle collections. :ref:`NXdelocalization`: - A base class to document procedures whereby a scalar field - is smoothened in a controlled manner (typically using kernel methods). + An approach to document procedures whereby a scalar field + is smoothed in a controlled manner. :ref:`NXsimilarity_grouping`: - A base class to describe clustering of objects (such as atoms or features). + An alternative for NXclustering. + + :ref:`NXclustering`: + A description for clustering of objects (such as atoms or features). + + :ref:`NXorientation_set`: + A set of parameters to describe the relative orientation of members of a set of features/objects. + + :ref:`NXslip_system_set`: + Metadata for a set of slip systems in a given crystal structure. - :ref:`NXrotation_set`: - A base class to describe the relative orientation or rotation members - of a set of features/objects. + :ref:`NXms_feature_set`: + Generic base class to describe any nested set of features + of a microstructure at the continuum-, micron-, nano-scale, or + to represent a topology of molecules and atoms. + + :ref:`NXms_snapshot`: + A container to describe the state of microstructural features + at a given point in time. + + :ref:`NXms_snapshot_set`: + The corresponding class to hold a set of :ref:`NXms_snapshot` objects. :ref:`NXchemical_composition`: - A base class to document (chemical) composition of a sample or a set of things. + (Chemical) composition of a sample or a set of things. -Finally, the following base classes allow data processing software to document its -input parameters and to summarize its performance statistics: +Finally, the following base classes allow data processing software to document its input +parameters and to summarize its performance statistics: :ref:`NXprogram`: - A base class for a specifically named and versioned program or library/component. + A named and version of a program of library/component. :ref:`NXcs_filter_boolean_mask`: - A base class for a boolean mask. + A boolean mask. :ref:`NXcs_prng`: - A base class for settings of a pseudo-random number generator (PRNG) algorithm. + Metadata of a pseudo-random number generator (PRNG) algorithm. :ref:`NXcs_profiling`: - A base class for holding a set of :ref:`NXcs_profiling_event` instances. + A structuring group holding a set of :ref:`NXcs_profiling_event` instances. :ref:`NXcs_profiling_event`: - A base class for documenting profiling/benchmark for an algorithm or computational step. + Profiling/benchmark data to an event of + tracking an algorithm/computational step. :ref:`NXcs_computer`: - Base class for describing a computer and its components. \ No newline at end of file + Metadata of a computer. + + :ref:`NXcs_cpu`: + Metadata of a central processing unit. + + :ref:`NXcs_gpu`: + Metadata of a graphical processing unit / accelerator. + + :ref:`NXcs_mm_sys`: + Metadata of the (main) memory (sub-)system. + + :ref:`NXcs_io_sys`: + Metadata of the input/output system. + + :ref:`NXcs_io_obj`: + Metadata of a component storing data of an :ref:`NXcs_io_sys` instance. + +.. _IcmeMsModels: + +Application definitions for ICME models +####################################### + +It is important to embrace the large research community of materials engineers +as they are frequent users of electron microscopy and atom probe microscopy. +In this community frequently ICME (Integrated Computational Materials Engineering) +microstructure models are used. These models are derived from a design strategy +and workflow whereby physics-based modelling of microstructure evolution, typically +at the mesoscopic scale, is used to understand the relations between +the microstructure and technological relevant descriptors for the properties +of materials. + +The following application definitions are proposed to support discussion on +how materials engineering-specific data models connect to or can be mapped on +concepts which are equally modellable with NeXus: + + :ref:`NXms`: + An application definition for arbitrary spatiotemporally resolved simulations. + + :ref:`NXms_score_config`: + A specific example of how :ref:`NXapm_paraprobe_config_ranger` can be + specialized for documenting the configuration of a computer simulation + with the static recrystallization cellular automata model SCORE. + + :ref:`NXms_score_results`: + A specific example of how :ref:`NXms` can be specialized for documenting + results of computer simulations with the static recrystallization + cellular automata model SCORE. diff --git a/manual/source/classes/contributed_definitions/container/ComplexContainerBeampath.png b/manual/source/classes/contributed_definitions/container/ComplexContainerBeampath.png deleted file mode 100644 index 597cee834c0426bd0e60b1afbf6554a5f3b04a99..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 7089 zcmbVxgT!j8lW(I7CP9R3l4E<2>J5 z)AI_IpP{<#g$8#av2ACx&qHz?7*6{wc9+~vb1nw=8zsvCGZ@1U!ma35{YCTeb^go#}G;SGXdmMbu z&k(dLz+>M0rk*>Sf)`6r0rqXS-WdWA6B8%4ZJE%EdqQPyjwzkRB;aOHTl>4)o5x|d zk^nCj4;eIl%(n^F+aGp�Z2d70QK#NZGhGGt4!*DVv+aK@%#_`tEYYN5riu(%l4#$J*D7^Wj?wMl{e?}qh~ zY>s%K&(C)zD>TXgDhM0}O&=C2r+yy#K3pp3G_SZgw*E;r78oa{=-eoZRr2X4M1X%T zpwKhuUnefLT1P?+p*cUDbF;27;urNXIdV3GP9r`-Tm1Iz!5axr2q&_2aKHv)6R*sV zoC86Z4ZQcMBBg7vGph*EBH-3c92|H`VKT=wJcAF`QUTL~RppiMF@&7l+%|jh=q_Yl zl(4Ai%5;s*CbbwAZH2$YiG@Y5cQ^ujWfjnl_}!#bRb1n>F}OTlrVE!&9&uFk^!!4^ z;FHzbDye5^Xk#UxwXh=zxB3+h)q$p^rRmjVynV~|G~Rjyp=(MM0mu_vg>= zxp&taB#b47RTc~^Sn`WBaGB9RJ~<@SMf)iaypK+F>MgC7zsG<%r}Pqabh%S?=ZlnO z^3i`NU#PHfxzukcD5suN`yh?Xm0-C9poTO!`bZon&_&qD+`{Bx!n8>beH987Qkx%6 zRNOt{;*|T%y-h7HKpqjqJ|6|a$DY4jlDeCYdZAn2&+t{t*H<)>RWW_m=_B!yXoyoi~j%|VXyXk z04CaDLB0Woc^Km9>6tgSGvc<^MsnrPilHHjLv>{cIk;b)x=dF3^O!*;WI(#z7`=S_P(B*fsh&^#>LCqbFwo<4%S1-m5+rtCdO_86H82|ZC-J$ z^0QbYQ`^F#vI*`-R!K??acY7!^%XsR4*+eK%Hj)EVh@1o1ZacHTr3XZeXE%-cJZ^~ z?igTnbhO%Wgc-Tl^we?eguId(P0owu>bd@t3XpYIWGuOgQ3;QMy?OJ-3M_sY35mfq zuL>o*x~!TS!N0WzGR3%G{DKF@zLYPS60_t>W-)`#e=IG9h1bEVcPafZw@P#@ERv6p zy`y8B4KrpKCaWw_2M6wwSG%=MfhV6$c;?N^>W7f6Z-J zDZ9VEuFcES$qeV@;ra2!?iU#qRgB+afU-yn!0$B5%45;`0FQ+Jpvg1>NBLMTz?jA| z)(osl*JpZq(Vf!EzRs{Z#ZpRbFK?ztkBILl;4p?=3tZpa=+|-|^w7C6v9sgywH;Fs z5D@4!^2MZlIShqt{M-5$5}9@b3BTNuH88kO!XO#foj}bZFw%z41MhYee!kk11Oklz z`dh>Fa}3e4#Q&K^U0w$2y?M`4s?}sm*A~AeYh%N5dpXtdeQ1dE*Lyz0`5f+^M4G6z zHCqtGR@VAntA~)o{%h9k?(R;MI#dUbIHEcyL@Z3EPxQq*VzL9^&^mv_@!);Obxb`s0N9NAtehd-L8uV}6C42C7z=Ib>PI6$H_DA_up%NN{Fh^> z@6}Hj#FD_{!Tfx_zu5NJ|A5Ka53{$5E!*l!AM|fiPAus(m+^;m79F8dyynf(?=1rH zL1Z)>HwZHN>dAH-*ru$A9m`(xn;An7#+IpHMW`trs;7o`dodKo%*qNKlD;Z0@SS}M zHU)v8)BotDgVO^R+R17TGolBVnK8I7s(9m@l)VE3NI5x(eSbQnP-m9fpg%(h52&{L zb-y_Dz`Ik#*O}nHg zNlM)8!9#x}(&v1I@WQ?csp#Kj<(@;5C9WOi9N+_lr(szFV>MwNGCcRs0*lZ|JIVP9 zA=!WCs+T1Mg;0=m61V*fl8wT){%kq|Mn?2fwDZ(fo$MHgwK`?lUyM`_1(0Ukfxp`(RR^z-IUr-0Hi-PWow{Cu;JB3(UcuYs*w zS4*6aR_LvhhkwGVo|nTL3j)wU85OH)F@&*_VhEf6T494$f9%^o{wW)R-E2MjvGeza zFSC{4jJ5&0C5fpaM@X8+x{0vKT$s9P6dx_!2}!7${-?<)v7eVYfycvLXmo&twy8~2 zSzgxcRWV?%+mDKmCxGJOHY}zf zBEzVtsQQD4x4pr}DhW>kTOQr`_F+|Id_uJWpE4krDs1n$j^ z4~#^#*Vo<6%_-@S^o6&xx9o;ptbyqcres_rlnA$?e4mR+7B4CynP7Ygfwge$eLz}V zGHzyvt(_DOG`TG4bC_tSFx*_?tgdwH@@G^c9{#)#bZ|j__6fymYZZ3A(t^oZFRLDJ z<|7pqNdZ|D!)U?g&d%b-{%;MSR7p(6^ymT)h)QkekSh-{N&J1hTjn*>H)-(^OFEn3 zfYf#FlAvDXSZH;}`L!fzojkUZ-u6h1~<|ldl38{cs(Tz z^yf0hlCvn;jF)zoekSZnWBb{^yuUDabL6)Zuf3|k>+R2D zMvZ^Gh-lu&y-J9rKP7y=AV`reWqLvN9_W;5A}8f@GEIFJ>MP(|aY1j>ljymVg<{x4 zjTFww#AKCVyAHqe?wr(PU0Yvgn<*~*(cO)Zkf1efbUo?C5fXKog#!N9hvflQ_Ei@1S=cn*o&~0NkFVWeV!*?(Mf@_YaIXRWBoSN8N{9R{?_E)?I0Pl)- zSk3-lc6VCwGx2l6)(wj|_KY$|AtH*hpC?w_!mj9Eym)c1V@Ac9UMldOv9Ym=hDLYW znZ#o0TO2BlDK1H~Tb&O}SYUmu{fUFUp;BFPRH*QlWfB*sA(cD;7K8SsKm<0T%Jh2< zl25-sW)G5-%1!FyUy%-yRq84#LT$7pDM1{kASaKA|J*&W{>_j1Bet3!Q3ERr3${`r zxt8<=t9tQd$(x@834HBwAge03Xrmn&8TmB#UY;zXJtTXHv-mT3HX4_wdxXvk*q_u~ zB^KOt1>j_xQ&o(Mfjf`PTK&m~q|UNl_(H6f+C%*J+s^o{zeB+URn(uW&@u3)lKb|J z;p;&>2N*w%=;1HNUykTZO0!8|{kbxXs;a8Jy}g~u@F#jT#yUC?U%fU8K$QTFg)4oE z%_J{+UxjhaAyD}a+Cs@wwyCv08}-sKhMprLBO|M=zF~n3htt&!q@|o7$!ghePmm7z z=+^r^QYn-8Z8ux1OeYQ)J;h$WBE@i|1QQu8Z9J*;IbdgJ7r&Ia))|34-QYs^?AbGZ z=Sd!<%U1ubM*O7q$3I697l{b1@r}c zb#YGrIZ^e>4+;7>IyR=G?@1{o-#w>byhE2awIfv-SjnB5>qWm1bS$f`p7=skW1XFT zab*!&nTEAa*pl^45h`few>x}ywmtEbT}whUI9L)~CN=kUf=-|A2g^ng;RDWaM3N{S zftMEMw&v9*0uNO={Kbrmkq%3Z5NXTI?3koyUB@P}H98^f}=x3TKl?q2}O2mR_|A|nL zG%`hFHXWWohRc4KLB~t}UJ|dtfA+lL(mfBsorQsVS4B-NvMQG`*|mrnY;qfg*hFN{ zAVt)=7mvOnW!V#zSZ;&1_0}9V3d%PhmV*IWUO1bT7+5{`@uWt=L$Aen^UF!p7wjLOt42~RsEI<~v438pG3D_0z4+^UFEz|`) zvuD@Lii^O;!@>~8S9gxNMoiLx4hhjF6<`Q53Q7mdctdkR2MJQ(Hb3194@9I}(Z6jDB zJ-!i-Y^d~bBcC&hzN{R&7{>TGfa3hb5Hl;n^pGGf31?*`JccmBb>U5|n<%zhE5z0o zFs#D*K1$Z!-dX3=Ia(A>%e}X|NL+4)pCwH^KJlswMT6a+iTAMxVxlBhGDD=E4w!Xl zR`oTwY|rFK!#R0fgRZJNaIvu794Qm5yb=~B`#Y=?lD|D9mB+$H zGGJ}T z>oxbA*&q6uHWjLhk7x@@K%-tEY!@WtNf=nyYKLH|PiyahN^|b2kcg7p`!3!)O1;1M zD8B@WA@E4Zz66RO5QvrA8XNqw&$>ONTwlKIRz-bacHh*#f`TAOsjnZcp1tkwDX9tt zZ{qN8LFksZFmv_H?%aH{-5m}-3H#ct$VIS<=6#fu9l;H<{q^2lw`hBNw4T9Fhg>pw z-#_9?|jjKcL2)~hIOYm38(_cRw(@DuF$S@N9u3V*z!Az)-2&b_hHdUq^ z3xAG=x_$BS|6XF^xpYf4D&8f*`ZGCZZ*GH5cAFtri0_{bBW7wN&i!X;U;vBKFoUaB z6dC4ff2%rVim5w%$osJCH6|G^oQf{XGA&-h3Vz9;(IbvVh*_!@a$6 zyTloD+(iBw#EpzJ3i{pq)k`)&d?7g=D>&G!kx|lUUOLEtfpK)Sl+m;S2)lf}(;y}2HdDyC+iQAu1*gEi}#v~#)tauKr>f77x zt6>sJhdB3RN6g7o#Nn!O5c2@$o2<(txGSh4PEM)$;^+L99-&Aj;AE5vj1>sQN8#5B zF>QemN{)ubKP~$|T#CZT>1e}^Yd5Ps9XV5SNamaJ%QYO<)?X+s!HDn+>w zgkDCoQRbQqMq)6TbMKLEM=HzKk<4|35{?o}k|!F4XAzn)`Jp=2rzD#7Y<@KZ9_6xr z9pG^flGkOg=6S@9K%*$XI8h=F4-3p?WM;QM;o1v@ECrnoCksU7yJVMox*z0C<2SkI zpI;8id|nc0`Y*%L>%eNNE3z$!^6!M<_Bk7b8p6h(>7>O`A0 z<+Zv*G%oobe{*ED{dM1NZ?PGvV#``j4cAc7NNPgGz!Dkv{TaS@;b(}yo^=0#PGFJz zZnL536YPaW4f$FI*7aZ8k+WfKpLp58WA|%}Q@wZTZb|N&MlBd(NM`?fsxmB0elg5a zyhTfzYtn^Y>O}{*Xk9rgF>z5nn_pVy(}ezLUu)}VJ-yP^B{+!VuV+ohkm{K0X1(jcKbDH?b&>a_(vxDPrweFG!4ZAQaM@IzzoNjj}rA zDd{kJNtN8Ib6~C!yRUCI`0r^kQiz=V_+lWl4sGU=mKMH|Lz&xg`au%S7JWZM-(ZyC zY#>w0b+bZ4{R69Ou8h`8GW{N}ZKwn{hbDlMWY(nFn;@L7Cww3hUttM6+E&%TSqy$H zO&vQlZoeprsc76h-5UFw_||P67JNj!psA8~0(<040j;#8ZhWd1PAZ)@XY#1pN)8>I z64k46S?F;kD#aHQ)0rptsTt&LEW5MFr}iV=DwtlH#MuJc^?~}{NW{(*GKiKKp`5JJSn=tL zWw`ym#rh3c5D}+>zU7-!QKX}9Q^r3wOy16eEhKnz|J>v1gl6sbZ`IcmKef_PdcMtKNSG<9Xx4}|=|E$9hEynSWZfFpV5_G*B%drKT zf{p37pZB$gbas&@46(47YZbb@8iCPEJw!2f+^TU{;OoX*ofcVd4Ci}K&W{udOOZ=t z#S%e0z1B4hVGwq$;tgot*W3B8oi}G=XMrnFctcBY#-FJdPMc3$vx24TVrm__`JV{r zWa$;L>gx-iP}rwlo)7P^BtBUGJ-T&NRCFAm0y}ZW$gYQY;R;z9O3Hq_ZqLg}D}5gC-$dChBeP#=_&Wpc z6)^{U=SlU}^T*LAGHTrz*Ap~tFkB5b#KBBH*19n!!Q|!N93nX5?j!e>NF|R`ZpIhF zfmx@Ej=QHU&3KG@J$PDno7xgmx2veFAUE;jl8Mo>b>~UIVQ`vsRSAk>_BorqYgesWGUr@`D=W&OA`>A)AQ05o^3v}i5Lh$_1g0Db0lX8X^R58= zdf_PfS`7(&c_EpEf#a8U@*f-_5PbCK9~ip&QWWqep_7c3ld7$mldF+~Da6&)mG!fY zrK7QtohhrW!>5!(VIl~G0`gi~Ld`98f5FvDO??sJ_>&oD^1wR}x|gq!KA*>kW5EVw zuUbm{adpZ^)|#v<)Y9k-VZzhDP{*;_)>cuIo~8+KLbAq6P{#TvKm7Nd=TnVILXyxI zl%HESKB7158}lhreFI-Shi*ud+gI%T>QLF(*pdb}OAZlKLK#?DW!>D|G+hJ3hT`Qk zUH!BpqoSlOEG)n~d3pyk6^H@?0(uLmRDw!Sw1tuBKgK6BpE8`C`NC!=5?;L}APMt; zaR+}E78d4#hJZ*#MU@cM>JN@+jO{4EQ73XtfufD`t#80g8K5T(wmmSFzPQ|niIO#% zUOgN34?|k1wVv~&`)qK;1#&U|SUpzI;H)JFc+BQ?Po4OrOMFz>WFf8o z9?c@2ej~~&m*e?<85w(3)Uwse+1)OJ5mUdcTO9zA|L5vGqJP89V4Q zLZPB^_-L2eM9r>zZP#fA*Ywo1dUUg(N4JSGKmb1D~NPY=dncQ+j0(tM>i z71eHtTc`hR$-q0qBmFFo^&dP6g{;}xe&oJ58oC&mDk$LbTt#kZ%08?1cO#%9_&ha! z=6r>TS=o|>yj!oBigB55F8cCxgpz^-)9q%XWDg%xg|BN_+0eZBF}=T!_U223F&dv=VeyWm~`2Y7bj>l_ksTBB;}*4 z>ovbvbPPNMuVab10~F*RHt0m-_7C7u{h#Nam|r;$`Vz9_J>_!8qVvNhmTZCJc^C9eHBn(jF{TXU6 z?l($^k2k|5du(8~I>BrOzJGatj(yyL-BO_5hBy24PUxp~61hoX@4Ez(1+<<+#b!p43p z8BdoPDYKhnsF1fTi;HMzYZKAFOY%b{=1pDjr_WytMKR6p?dJ8bS?k)$j!QJG(4eesX z6PgCmwT@dZ*IPU0OI~NFi|$)#Xivgd3$Em>_50=ErSy0;2miqUYVn7Zd;qA)nY?!`;cw*oY5aGy9sqo=jkm9DvOR~@huRbmO4pY=SL?N zwlDEmw1Z?K@tmh`_-q%W@>PGkOy7iu{a7RU|6maK?^q;UR|f|S^2I<3A38CgjnzfX zf=y_ziKMr;NV?DMXXX#(KT$lUf}Z179x*)wgM_|*`W)}X#6;RS@f5$B#Q(fyCqIW^ z5HS5JEvMQ({`u=MzhXxrBt*Qkv!gdsIQgGoS_f0Cv3Dw9V6ddPAMQy~@P8o84&)RH zJ@4z52KTcv`?W5O*tr82g6J;R?Rfs@$ewMJ`Sa%scXxNag=k*;ynz1$@jtfY5CR+y zjOA2GaOcO*7d7oG;w~<{|Hj7ZGc`d}2mZ$yPP=$=!?CHUDQz12>VIba##{F9%&VUPR2&MNw#8UcrRPQcZL zn4j+>uW%t_Q9vFL@KtZ2QV~QJX=(4-d{xxvo65?fel%`8Zh=$DKA0>fjtWD<9p7zg zEb)8Z8@H(wg>V0SR>kGyvW&~HbrAJA>4aeoY;W=39op5e{!a+-9@4SJHM+YLq@gX~ z_@v1H@85m=kKKMd3Yh0OaY4kxqhYn69a&VQ9TY@wzvLaCeX!`s_R`2G9SQY7=L~xm z?my?5XZY&Ju;>I$pdq4dr>PUM)wE2R+7a-+n+q4&*L&U$d2*gN8(*etE70QO8Ff9a zk>0<*k4spMjHhm_ud{5#dcKVFTeAvMA=gPtt_nP&Xp*Z%CZ7w#i2~^t@a`0}U4>sf zr}>@@My2|spG|$bp_Yh{kZ1Z&4w_j7`ysnk(j>T}$PZ0CLG1rrj95w39XeMv(Kb8` zr~3Prnr8z2^JgCdvBlqo^|GJXpDz?@+0-2P`#02ek&t!va3gVT`JlL^%xE#;(lv9a z`+25GKX%6mS}p2E4-62QnDHJQu{-5~`^djO*&AT}CtwK7DI3lH>A@YWhW~qp_U%zo z`L~v{Oa30L&l^tAGC0`G#B`#~%yBt4MN(#tSqBd#`CZ=c%u&1ftctH*$1p`aJfto@ z&nH``x>S)pJ=mg_mj}gS(+xoUI;1Q6m+e-9AJb+!$!rg1E6cQ)i^*L1NqUBcWIa6U zex8x|ZW1OTBhS`*Dn8rJc<#-aWBfODxLVz$oMW*kY$r3z&uBt_@rx&&dEWlFD|$ZB zTUY%X?uQRNBYOumkGB}3yh_5DsG)F4+`afdK3;p&yLh{eL$JmfQqYMpE^umQ&lKc}o?D z5U>_18IE(-a%HA(c_0*wZ-R+!kT%NT{*!`?M{*w?DeGBx4kSxtTOT%yAz#gpq37o} z%`f>65e33kzE@R+%NgB1y(uVQ{8XQifR%Wl#)u0G3p?BB>#bmI%>qRT?B8NyVoE!h z_ZAZt5y2$r=^t!VP>9C$y;s>IahYz?n_i+6)j#0m*R>D6UUNFM;zh(k{-Eiaqsq>& z%oK^w*0noPIA>LD(u)NmOUK3;m)Sr|hzpUyUjO6cRkQI#fx2~-=k-eH$#FY+y_cwn z2x$tRtxb2jimTm0WoVgw4#uXpH*S*P1o`LBZI5W&HQqNH z5^hfqKT8fj{sz;Sn7iQ3w2s^U9sEdX1l`W5Y;)P>w)ym zTNYMJs)4jQbWL5%pugN=Q1YP%(xJq57%gTrH;)Jd5dtwEzIU|sXFggr z(!igi(JX|4xbSH*4r{E{;)seu(bi}6Y?(v(XXemt4+ovr0_nkyWZ-1D{Zl{viL z?0&xEi=5GzgE>oJJ7BXDJ@5GfMy8J+8|?O{;j_DSJ&UgyksOAts*Im}L>wHVMs}c| zM5B5Jd6sXs*6fzNi>r^n_xj-*L`jMJAtoen%fET=+W#xRphunnjWnR$B3Pj`v`xVq zDZl8`_m7N$frP*%)I~Ct@Gq0NC>L&kU76@9l!{n50h0{Pc0@ltQveTFeb)32;rysn z@=XMJTf2x}x+=4>6JJ43uIP``(@av)`-Y)Ue949kY={tgDamIqBiR4Pm^PK)sB67< zRbsiMzRe!EJm5gvlQ=|K*%DRXR#x)vFBzbxDb{$5xZzT=4TnV&%Z2$gBBH6SC4c%j ztSc}=K`DV+S?3ycmY1EKT3uLeC2+K?Ty2a<^68C{CnsGvw} zgqWD=^o&2~JqDurB93mv+eQN3yn5_v^6`eZsoN<#YYGj8!XdaBbw!EisjaT`kEw>x zrHAdrHM#ISeIB#BpZNp>p-cBfTXCI-3632W$T*r-RT8lEj3w;{E@&LnY)~-Fwpj#K zyap-?ypKTms0|_=N1d{UnS_hW*aTdfqE@Bdea*{n-x#tTk!cmrJ5M+4hujhE?JelP zd0$yXKYe8wfs#Snv!u-FS!5n_VyTQa`WywPdhrdUFLD)z?y~siK`9~a#9B~L#P2c? zq>|Ghlaay0L=cGZIqt`9$|g!s`&as#L@-_tp3Cdr^Tz&1Zql&=noZ=nNxEs zbew(I#CyS^WV=f$3kUI3_$-o#0q_t%RokZU5Y^upPq%x@7m1h7!ayxGy_DtaiyK3pK{5MSHP;e``f}&!@^S6bfvVUuxnfjPS4Ba&~A=A)Wu$#y2{XoQ~yZyM@aaa-T z^yvqmEg7%P{PeDU{la0@k5c+%=KucbPnr_OuYRp0u9Ukk8a zM-c`Zi9NiC<@)9ac17Os*q${#J-gAi^2x>F&d%fUX@U?F=Vj*uDH=KNau23dVIAUH z_uXA`1aSm`2f9HB!KG~3-OafJfK=f&_0$1{lPe{J^m0F6&aMorvvakO^stVJ z#B~98vA1#G3l+75iB{jC*9UAamqm2s_f!n8qvNSNx7;9YWpK_MwInN!n-u5Yb(BvY zuIQic9mj3v5FCxN%pHR@P@2!3Ug&#qwAnP`l2P5wfzYdx;c&Ge*zn{tW@gyh`eq=N zp~$67oAmg2d!gc_SOc-V;(|qknftNc&WI-6*T-+${^|Y`GY&EZ!|T8fX`X<9q2hZ1 zXVls^!Eu(QGCh@3un=ZbQ()b}m32gDg}7w?{>ljOtz67d&R=&&EFcD5FuDlYtp>gP z^JlgFAobUcUW@F*^s!HT8P*%DP)WP_e9gJ#y}aNZ|LsM>(; zs@#|WdWnaNOF1Glb|FI|UAD`~t^pl=@5RY2~Z}&w5Kh5F1E4t;aq(r#7Hc_)* zF8%_s-pAdboThKXas2MtxHoPu@`ifErR+JZDl3)UJf#SUkdNZ2SHw(_8|0!ByhIT~ z6~87Xh8{IPEm{+&42Co`2p92J=udw0JZi*`aGXE=kw@KdcUV8Ncfp#mRPiacA}u!M zv>H@61QYu*McHku4#Fb58uU!5-#0_Y)x@Gm=NzwG>6t1FuMX?X3h{z`BO?a*oy=3W zP~wVGT{_gi8M!c5&#=#9Z*k4TOsZoshU888hF%Iu6@;IT&Wcaym`)d>=Nd3E^O ziaq>=zWq+(yf|fnEB{XIIZ1S=bt6E6o-a?pVNEFOMtS4wBelmU}{rukC-1=+%M|t zy5tFclG@v^hk(w6LZaY;0o&~)8RBS)5n?5XZ)l|rt^L>GsXI z0?dYj+NSU)nxA4q60m@`S!dRQ4EM;t(DSM7KjY$e^6y!fhbD8br^YPYuWVi(KvjhP z-C8a@S`qJ=DBtl*XUsij5J9@xt+kQ9v!+cRT)Eo0UKq}luU#Lv=f2AD_a_@#c@fx( zP+WCkABbql?q+wSvm%jJy55ei0)ix@g-e*^Z(6o`KQ+QrC(~$bIdYii2j6g`b;B<43G;rQVb`dh7~OOKOg=H{$6Hx6IDZyAcz)$?X+;-7Do z*tzQWoKy6^nFk)0?QLY)XVI;x)} zJVV|dQoCroQn#m#uR^t3V&&{SG`AZRR3W;^rJILg;aKta2Y8Hm?aBfICJmg`p7>k} z44j|RZz9+V3X74T`}c{MUwUImg?6aSOblE@#}-w}qCnaF^9V)s_KWUI6V92H z6-w*{+m&m3Y+9woy@sO|N-5n`eAZeTjM34O>V`v>U%BDBDl&3XxoT}je=_&ahB4h{ zOcP>@m#Wbb($FBwTsEowF2H|#$Mu?YXZV7e&hEO53?3d^I+PTTEvD_?FH%htd4pF{ zkF2j;9xz@mixz3~V3amL(t+Yu*u-d{m4&QJWz5Ff>$b!!he7 z@MeR^{?*mj($c@)hai&gv)z)YDE*qS&=cL-+he*B=6JeB1S5dmcOhw7K^R|jCBJ=o zI2yV^QFIZCs;$ktz0f4_Jrv*uxHbf-`N73J6wTQk)TP;?KeO8c+Cx!mwzI{5=H61V zC`>O&{IbaS<5M_8UO(lz`gI8Iw-a*eKle<2Isbx>0-|}0p_9$dZt|(-t!Ymsft{(b zJm?Q7Y)#j|rRe=*eW2Wpy#M`9VjGn&bH8GExok%Hde*WmRWy2?>+U^w-`(9({MB+G z3)vYVAKD3%W}S#wAe;*NrwT#kvbiwoWDk;F?&WJAYW=BK60GGjqas)5?QOyFTRdW| zdYv78syl8gr@2}1&B{Vl304FmW6;Rg2${}yNHJ9_|2(7lYihB?KZg#dQS7216zib` zXOKr|7Q;f^Iy?T_nAp}z3!dku#MM~f;@FgU0oF)bWU`9Q^0p*Imluf*33P;FLW^5qfw zMikkK6p7R)X|5QYp1ctnMShyPspeb?@3HRxjbU=QvNp)Yes{6}Q%+WpI}kB%jX?8m zghD_)QsT2Vc-7Lcqs?D7Ly}iqNl77oZ)$k5nloLNh2>ZFl>=1O9L8SH$>;-4LxU34 z1MkU!XL#Nj{JWG8zt3Z-GFcEqD;HiI3!bm7t#R&E=~Lr);665++bTJZZ+GQxS?dT)ki5#8Nobsb()G(Bi|VF7opQgb$BNAoH_ zJ}%Q=w*3d9w1`FphxkQ{|CTf3^M#kUGMG*lJzqV8RIgtLo}JY2vu$6j`mQiF{?JEa zHbX2zMa%QeBn@zLcUsPZXd~u1N+NKOLx{g=02hvFc{&HuHyl?hNPvSd*`y>=O1Ecqy?6;HI zmYjVIp=mdf-5|D6jm?Lo?VCm~(Kf$4Wv`o!LIQr}1Bcj`RJ(J`8ynBLc0 zqD514`%v1&bd7zDc~&-XLhZ%XA+6nVFpY}{wYs!*O95G3A-{ib2puu0a|Y4nu|Haf zNuz4i?uY)?#0v;Sq!gIBxPL*lE3)fyD7~R1)~c%&7LrY+#mJ~V;Ar>j&-eD;jeeCn zkIFN9Q#|r?6Cm)1*4hRfnN{;k6`&}4J9@UF}Hh#bglo3a7d7+K{ zF)nuL5x(hT3iDaV1nYC@vK+T&6uIPJ%`vT=&q;VG>4eDYaH&AKVi6xDS#dFp3q1R?VKN0#KEW~hhW*O z4FA>qp+LfyZ@yHcuD{dA@MPrsI|3^bx#cQLJ!&27CeSgVX18f>8`Y!n)-)7 z9?s$0U$AMfKeoL%A*}`VB+j>Q#nn$xsM>1PTt{M%^_)he^_+!FM*YL3-6*n4W2LW- z=&7W)>7H$YYvzLKM&rEo8yvD9NE9!aG{3jB=j4kWEQlE*@D>#X%;#(fG{WJ^H!FB~ z`yTSbIaIy;0>iS&WOwhztWiY2ANS~euEIb>R3a{rT}JjhE%vSr?z4F#Di?*WNRLGS zD_ITxICSa~X(TiWbV5I7wKek!mqld?1Pf{L;7AN4+#gN0!SV=pEW9>F!P>=Lmj{*8 zO^tYe{^&o$)}uaFvue=~cY87!DPm%6G9R|t?@wJ=geQu9b3+x*WY5{zM$aBjUEslX z9|%dNXNEfZh|SjfcE_d|vJXg`X5sB={%xQUw9=k+o3777+xz}4z1Ed4hQ$BO(Y51h z$|OBd6{4~B_3VVetrm*rsS@f;Z+%fi!ud6|wvS>{HfW71Oi6yA(;R|*JZ=12TUgXs zHnSf;ovn$!y+FM)dw9WKt|oFBBT$LF5LS6&H`#MB#)*(b)cx;^5F%o~xp>W~^9S>z zM^aHMaqoqLyizy~wg=0nT>#K3kzIsj<(~8@2>Z!gZxXkdGuvD}*4_$ug3Xv{>lG`i z?f2uyr1w!+Df!(L$HUz+9C~8witg=IFWoP##=46=d7TH(eJDtiEPf`AJ3WMUbZxpT@!m~ZEM z;unukEgsuykQP>T~owx~fV!b^JNW%yzAE|Uy=)0eW9*8`B z<^x%Ds#+>OM4w#V-!9m9lWH{zV)s|wBgZz6b6lzQV{%E}D->jp1oTO+u&sV#t0QU; zg|4!+Sp@^+?$M$(VMxS^5 zY8Z}VPr4Uu7akHHXO{72Z(UWkGZ6PRR=jTN&rTlOuKoZxdLYfyvHq&`=HK+@>gqTW zDlWP9EFe%cEcYspNKY<|p9FJ#;SdWjvHtly^!IaRH#A&)Yp%NeJw^zkdF-}*^yXkn zXf!cjmB+kIb-OutHX#3it<$7?>@rkueQsS5?~D~&Jx?^qrlp44T>UtWiqO;8kO@T% zzUqlT&ftUx*)Cdai}>r`=KzJOzbPE!(X?$ktns9_`&E58tj=#oN8g9G6ekG@W%p^| zYiQ_LqL|C^6(?KmF3dVlc)UQ0cuz(D<{JJRlhg4Py49Iu#_*M9)`$e0EsglB)d~f@ zPU8(<9dcF;au$0_2uohqBbOtwg;8fHe=xc|@)R|6Ds#tTLWw^*tp=yXyx~~#WeD^{ z=6yn$WZS~~!h+8Q-8hxh^7VSOXqKtKThcHfGm>BelkqC!XH8G07Ahuy@cQ$AU6rFUC>*&%v? zb1QaDF*`e#{)IaH$EdjfTg;%h!%zjamH_GzDMS&3EK`DQbhaRB^3F2DJq;0`yW*jn z`I9wl4AKQbr{qDGq(QXn+Xw?%8Y&C)N}cMDOXoXf^$es7sSAeUk4sN6x88T`+iS54 zA&7u6;tR->M!t`y;k z&S~UOfAsS;!Fey;aYXp%i6JIlyobk2zVo}eCA(X(r`Gs6n?Qxq?vqa$GS{T8Efof0 zqX5;wNUJ7d{(yz->+8!;(gH@X)umzF^_OJvnL<5kOnf0uuRuz67(TCS6dS=|+|ez* zxBC~;)X|WK9VUM&2@)sFa7JmG{5XD1znI3xrpy@tc8PzK?L ze+1V6Q()Cas&Dl>WowpRZ@h}A+PLJGK9Hw{3qhOsxY&SH^nnX$XJ_@TRDT~c0jCM# z>gwZj6j4z#2~qrnp{L6FMF8RzS;N6N{{2Jz#b=&L7N*WUzO)uV&=o8B$ePB(qn&g@ zrN`eUqo5cu(nBE9Ec(n0+}sgKV&tG$hJo-960**nM8K)w+wqgQt;d_2m`xgvDXgjlf{qbgvQ`Y)No@ax{p!dt{0Lu)$< zt4!qET|^aS!>&;B?}q2*_F;`_}& z!ly?8%xGAQ%__l^ckYk3C+Rc89Ip}>^kT{=v%DvuMgA2+)cbl=RJ;l}{Gpdl2+&A( zX2sOFwILzrnw?zbB0VAb^O}GE5MI2XU)kC55x~QARzkBJ!}>IQd<0c$h|0}OJLB${wn6#oF_w;K!>iw(sgHj&7 z?0cPQWtxt6Z8@<`2jyDmkb!h>B;R|=uLFv2-e=^$&1zk4CHncRmQ~`d^g{Qh9t*%F%shk7>e6!|=2irsw`A zNoS|A-Q9s41oCj}zIrjW#^LGGxH>_`P zF|gPm@A#6$;5uY_SU0UqA}b0Z4mKx#qb7VPR8W)*&cG8@4xbHy1a16iG5VCP$sCtN zvGK;N(3pC282_@+F0j=<4<9A=sv|r0*7%7HpVGYrUaNfF+r&f-kl~Zo?v`JAS?f~r zas1<5UdToq*-X=O55=6%DbNq8WNw$i)-k{G^M|BMxz{S56GV3UM26FKoVxyf0M(B`hqW$p#;KOk%{^d?Y|PM7M0e#ZeGld`kJHqk+1By z$D0#_(Bpna1#nt%n-a`=mkEKyAI*0*A0x9r4C3Pbz$DDKu(TmiDP3RL3e7_#Ge4QW zo}WJx+HxmVkZx3TC`VZG75m%SL=3bBp|Wc>*V)EP$sjR*t{%6%0b4zY1R_B309P{^1j~K@PNm}_Mzm10xVT=i5R{wj+t5B@; z-9y#F)^@3opcj>M58@D`@Es6Tx1A8~A3ZB80yh7ChIz(DwmE()@`x9HYafnfD;&Q7 z^n;V*W~SA_EbrWp(=+?iPJERrGt>l)QrVWjpKa#O=u*RGqu<%c{G&lhpyi1ktD9xo z`l{&vJNE^Jz(l~h8jA3QC}ha`rMai)X>aZ?OQ5eh{aJQUTR+&0$0i!V*32yDRzrt{ ztuyqy=KeHuXqz{F%s?t|z8_`x+AS|TCo3W%pty-_^9vmaoPM=s7!X5N#B+&_qh(&PI-e^iw0Di!?s-9+zAXg1b84Z=$j)K>vHGi=Ee^(97y6AnzJd^f-$LV;KWBYd^DJwfa8a5pR&P@ zR0OmeJVRIaZqEps$J7|m^#SJ6ZZh|JHPT~iWC&Q8vjFDVwhA=@^cYK$@It%l)?>@M zbb7i%RG-Tn1K^H9zlsJ-i4j6$%y{AW<{@9dyErR>-j7f?J1&8@QH8I*gT-=P%$EY% zn)mO$I6fyB#HL5_TYTlyD6uNY{LDTbpJM5!_^Bi4<*MZ|pmOEqr_q#@j0(>;J-vVa zye=WHRsTixYzCs8?J{H)6g{z|lrb zE$dcqMV;7h_w=CB(~DX1zR1A9-?kZ-RaN-x9do)HDEqU4?+!y!%2Qh~PG+tg1e||g zCIx_6mG7IMBIEW-zIYWqE=z!P17c1n{ut4km9xHyoMm*h_@BXz-CvpQsx2qH9lB8) z`;D0S(}e0-xYd(qf7p1k68b7hY{{G9U@_Z3OsV1YjjFpfh~Evul+rYG^-Z(vKKC|i z8rm4ddlT8Lozs6r34|su?2w&{M|5l?M)yi{cB_}-u3F&2JRjYAgcpXr^Ox%J5ld?k zfJ7m#7sKJ8l68)g|8I2&g5k!S6}F#U%}K(-kiyEh^)ll*+~{b=-BtYz#7we_&WY^J z**~SHV0;UU+Bld9}?N!X~Lgn4Kw9RZ#^!!|0szBmseUE33w9)mo`O295qReeACQcT5zqN zO>7$-@q6Gh%k=2S`&3y4W-t)I0srw@=?;$mgj{|B0lD2aweSQy$k+W4(RMp^@dp?;$~aOHRIzXnXDkPWNuA=Eqm~CBpMwT*r%^dUI^q z>A5EnQpy;1Xk6{XQ|g-VIdy`#o|of7p?u}#7G=hAq&78_f5+~|NP9L~{(~#DcrQey z*dWV%%%1%q;RwnrNSk8e%*?80Y+oPq@o^j_dz|g-gHGQ*oG8$IRabu~InfpEw}4g( z11CLak&s|0=mG`sNzAlq|18PmvTJ_h%^lp^?~q7*l7AMstFjgC5Vw z4g2vx-;>d{Z3mL!y1d~eb7nMtt>Z7XzSOtWV-Kr25Y|EGud3%a&x};s%KY`e6`;BhXMEKeT>Ysec z|2K6KTF$83^J&yo<(QAv7XGpS1+cti4hTUeNE49 zpUw7O^}%i{Z6z#XH$`R+gw7=X(TCHi&ttHL6)#(v>AJ&;n2j>fgC!9HDHYC>faVZ* z< z*$rxPvO=}DmtP*eQGV{mz#}>$8d5)x*rQfn;=f>!%j&ng-w2(mfqA-}hpYm)dY-eB2xWN}H>B zZBo7b<#0MfMtbo!9b2GDRzW|RdNts>06*^-TUM8CAN(%_wdMXs+$hV=w-uH`gmimK z={_~BV@lH>C}lfdB_f&rBqk!6t}H}r4~?9P;CJZo)6{1G6uO-$m1xtIQr*|KIUWDe zoJJ0hzk9PdQX%Gl-0Xi=@OJVorG`8VnD-2&<;VmE®w_`d`gV3yjY{|b6NDG+(F z+Dfp*;kmaQ( zgpwxhnx_R<$?z+(zcBOG)xj(O-onKv&u}*Y!5QxL?cP`t?_fsj3Ui*C1C%hkGmf%^ z$sYlM5zvGrsp|LslzMZq9neG{PhO9SWE6y`=nDqj z1!%~VaeKI+f{24Yh5YfiTrykv1_s2|_N4heH8s^wYtsen8*a~)!^|IO3%vpGm`S1{nVrYa5Y=)!`dfCh0Rn_j zm(8`DmU7cSLw9JQWpjCopTxDauI}8wxVyF3n_>Ml8_BFdMt#r0e~v37)8hNY#B3_$ zfiq(6_mhS~fUxGc4Uesct@)l)-)3G`xg!LX*ly=n;_61Ce%o{7)XTJ^xpdD%0pY88 zN1%RdaOcWZOpDk`_r^Qh929y|N=iX#IE}EoixKkU;>s85%vWuxvKDu*Wq)CRHfT+r zGsd%^_-41J$(cGl94Iq+59(F4XZ=7A0hE}QjKol{eFad^uSSB(p%@Qe|YfeXzUdkFO8W_f}7`qNU|fp^x<*l}Vf9 z+x02ZF!KF&Fc*A>P3K}`N6!dbQY%|?u*bB|Ug&g&f1a-@{yN-FhZW!F`(0)kyOOSB z^qwFm@QUH4{V{Onv#wIpE&b^DdN^PK5W*Kt=Ch=>ysY-QhX2llv}W;fB?rB-yu0EP z!NZ`?HO(u*do2H}?Vn1ryc+5MDIF%=Eqm|wt=`ej?-WTXO#&|2>5S}b*t}wRpL@)j z(>GHG35bU|Ug1ztpIgzuFOQy>l zZ<11~->-5khf1P!O3D!^VSpbBTM(z(Eg3Tut#Kydl|mLJ6|7d}8?C3syj)qg74JK1 zqvgZ=-$6!^ufNp&tRL@uyoS4;YObq7cMxFrU zy=`(ee)9{8O^Y-aD0ZEByyvqX2J_rCP`)Xl7=tPHpceiW#~_Mi2NgY5RGB@$`p=xo z`J@hit(U+6ol>0*-51L12quiX^RW>$^2N>1gd`q?-giNn5G1yO6h63@FIncUZ(wYj z7@}UW8L%>c(y1vk?KRjX-rWT%GF%^oy4kmEFwIY_1A6?<$ONJ!0QNE5Rij{6){+33 zr$QDC2C|Hdoa=`~Pa*)daLWfu1nRPl>NGdOUM;chr({kr0@elnxsL`&wEuEHk*SVl zmI8e>KffhjfzQpagDx~gMc+FXMm{U?)7eU-&m^o){;gTn7ESH5|9%xqNjVOSGU+*JN?!^@FQXL%yo@TU$)hH`Q zs~s^1%AqYXb{luqdc%Pp&49gR9VTAk=PqFSe)*uNT8qN@>`>y z!!$xH_uUC11dA9x~48ZFS z`0DB)!=iXv2~`1*Gp=>N3>n~XA=J4u7)Bd1ePBJn+b-COB zOAF9)ePUf*n*X_O@THk|H`sJ*F7-P*Ee}^Hnt63_l|*j$_C{nwCu@>%^eniSe+YP? zVNv_LWS0!c!9|17zndPaV9~`=(IH4^8iIv7xw*)=cmhh?(Uu*gdWqHR$=mxmU+WEDh<=CA(S=MtUcBI}$q(dspoKg__2F0wzUgL@8?t=7 zV&8x~8uHxV_^-y)iwhKvpify|Ny+w%Wby~mv%DL~#P&*fr2@aa3t5j9>zWKh0(w*M z0cb3<0bS0_{V)9N*Mb%h^RGM~E^=$xfhrUOd#v&yi;Rt5%WElG?5RlVeS(`g5V;s# z9SR=S!_*XYpg@|MN?bo!52-0bx|3fI!KnUDpV-n233?7ayH|(7E6Wmz2iIt$Q`U0` z4Hw^mV?#{$ZL++RN~0F4|17yu^r7t=Vz$d<%~42wBVW^XHWYB%5b*yd7QK&zPet9%Octy%~{j4aaLGWQ&Ab33uzBsp*D@t z;ff|UalgK+w`yM=(cIX8;W9&7n}e{MgeeOocrEV#+^YpCrV8YQVoCY_GEp`1ki--x){S~laCA$%ViX;?S7!J_$ zZDQ9+65(mndK-T12*LRn(zb8GZIUZK4(05V#b)J47ohds?SNMv&TO6y_p>{i@dgBxvwK}DGV3NqJ_`|hzicY*f4-toWyBP=#DhG`^_1(( zqJOUK(_*6yrn4~jA_53Gx4#NZ+#tFbL^T&;YTEW-)E>lh*XZ28fkq_<&+Uc+rxKJ| zau}ud?OPj=B1q9AZJHsfWgl8y?qf8Z$O@Ycqe+1J#kSEInQy^~V03g&S=n%R_t3dE z?B*=3+VQZ7*c|{W{X1i}#`Omz8CfPMe>Y#vg5&nY>nl zTYMj>zosAhn{X0B{%-kVyaGuHB5i zmo!D14NAFtI2+ zxFf<(WH5s2{ny15IOxE`BS8(j5di{x$m#u1@>(O;QR7vxV^C-{?DsU+Th&s15f!xr zhy*{NQ&_CR|dJ2w--ev$C&PANTG!2#n;bM z%myW%Fm)x-gDEk?A)YQVh`NJrOoNE!IBYwj1Me7*-lflkHB1B>e=d? zJOY?+_uk87q6Aq-RU;(ZOe5%VgwPVj!ik3junQg=P5YgMUcM1@ z-6dnUgT%b*f@q&jto)@R?|eX9&FGYg{sCKQ!SiM)L#}tG;==aLuQEbmf+`=M3pUX0 zgL?2NFI{Xl$*lMLqm>oMP%4AOyC|C_)O;NIx5S~M-cYvg`46v6IH55S0b}PoH5DK& zQ=xCQLn$7gC9*LxI@Ybl(l|UETuf=rVj8pXhez3!3JiuXv!@=(d@AJHTWS_VGe@UD zcU=x>8Z;Q`D^T{={n=_ZP0q2K6Klso^TM^%V2bVM1g~IoN}ON)R0-u)BwI%{i{}NF z4(;xvI+S3fZsqV-q7!j4&(^leavS`@NfcpA7-rp?{hD?utMtLZ@Gzc_Pu)iO-sM7A zBvV&sq^UwkNK_Q#*RN`>ySQw6TSLKn^R;;mj)=duhNZrI2`oq@5ibmW_bXtq%*ZZ@ zJxhiq3yP*UlVZF39TUNcixz;wNj&`x&K5G1l#~F=r(QkrO^WV3c)YK;CYuOA@V#y) zH{3WxYrb~V{lSY0u1efIBEDPNHy|ycfrpGnhO<;rRvCQI6JN)QW?(???Pa)kguc^w z_^SM4@aGLYwi0wS$1MkY`dx>2Gp=xuD%)Yu0mHD`MC=@?Dst>+{d>-}y};I>k%#OM zF;Gg=c{A#<4w}N}nm+=8jO8i>7QRLASoigxk-S3;UAu;AeAjSW4X1-_-y+J9iN!F* zibk}xhwAvWFTqFrDCflK?v_gX`a--KGx{%f>}$$hD>4uH;I_7==h?binmVe_Qq!h* z^$Nnu>cBNMBK&_9_MPEyebKu|?>)LO(Sm5vJHsfE5TZtn7NSQ&ln~t@TBIYo45B4O zH%b_Sh~7IfdWjbGzvuow-RHUG>zO(G?0xpyYrU(zhlQiAXw;@SQ+a*?|7~eV{7v}qdubVtvZOoa?Bd{ndDwe!0eQ!ch@8{y2L#knCEQ_T850aAfExCG-WWT~ z+(g!$3XPCeBS^iJcDiLhonQ^wo?s%8%1xPl2yyu~#L46lRtB7{KfM>jT7+J=0H zV7AeTEZZiMQ^fG7qIchpXV6)4)a6t-99VK#xE}9}6yH`fZ}7jFjcnkx^8zC;s&p3emI!it_H1c;GA3Lj=C|9ty1%gP zjBCXEt*&@6{3MkkMNWmG=LfL0NdCK~c6*M~#D+vf!^k8tEua)Y8=<$Kj0!)XLc-Tx z`(EdzRy?d;Vwz?}(jJP}n;26hctgWUE84~lh2W2{^p_KM_sHHq@Yu5eyM}t^HC>zr zx(SZ|OnQln!e}pr$S`c1N!WWxbVitt8-y}<; zqSr=h-B~z!={v2hZ@Ns%Ubp)c5Uxib079D)RV z$s&lUTB|S5iPBf5Qa5w3iE zIjFxzh?mbSsy4q#b$RT6d~wXPp_Qc7@uyc#(Hlk&8a$nhZfh{m0f3i4^}4Can}VY4 zefK-N^%atX1omTjSTnZLhnQqd0)zxAcw9;Lyh(24(eU6oTP!!N>ii&IZL8rsi>n58 zyXhh0_Y$vNV+lBubEKwD=ulePn!fS2kb?Hmp+j7a*08?3yjr_&A|DHM{8#o;nKMPe zV3gmJsme9GeaUH|$#)_6kAa$pyfxT8(wAx0A%EZQiVmoG#!yFm6R>FY+%P}RR3Ivz zXXZY3Oev>EH+&sxm; z0wE+?jpdZrX;(bvI-{5`_bG4A#%lPVtbVr450TM`Zocec9i!y@5|sPBK8Kqx-|#+w z|Ew@1%K8e20x#!{wGb6n&|Yi(Dl?O-)TTbp%qD=SIuAW((xu@~V<(psfeM=!G{mp0 ziDY?>T&Y0NBW-zOcJ~MGE}kT;zn5^*EgtCus`9wKy#*{~x3O-ET;n4pZJ#R5(tEEM z1MW2i<5d1w)zm3mwX@%!$21m{j9 zLtr*bZ6{o4AkWMot2Z3M4L2~L9VxYrk7c<2{r>sVuU{+y8!V+gA0k>ovTf^=vbSyB z5LP$$F~YbTLR> z2JB1S>^JQR54UHNdV20`%rvqG9c{HAMA~{6N@)q_RvOwjH{TF2^qKXujh zoYGEn7ii1`KCM$`(^&p=^2pDQRi(U-u-=4kx|L8v}joqoNh) zL0(k#k|WqAkW5}=YPR+9&nu){&qMj3q4Se#4&6-Y2ZvgK7%W#pq{Kt$4q_Tm5%^jr zCML3|JeRYwvg)yBRO4=Grec5K=2#`;5JH@Mve&(%>_d2nhet_^7?yIt$%+Zc$otyiZk_-)*WoonH$6EB z2-`3y6Fw`R661ix@XjDt<1efi2MJwVGWvL5@fTQSTfSI7~7u`w~-#dQ%Qt5Hd<4~PjH=i9KQCC5XJf+LHr6qyjM;06mHjV6= zV$AxrelTi_Io(EkeP01VHU_{0_M`)JF`d09k9lLQVu2An+hfP0feJF%~7!Fw*k!a&gP6 zfF}<|iXRsj*TcjCH4hFl`1$#5URX6kyB+KYc-%@HoHtCtzWBm{Ua@a!Y0+7QdIyBw zkS}&5XgqydIlcy1YQjn^s}~m9;|&Up!Qi!p;St#&#nXQME;pY9{fEhF9=8>JV$vK@ zqyu;f!*WW;FfC3+V)T0!IpD4IY)<+*z(Dv=hL7)0DJNYO{&$cxC@!X;rLu&n=iM_V z_&wD`wZHLbONhQ-**>0tu8OsSXkqEr($Q)JEA;C6o#q5k@~G+awYFFrafG9HnMeou ztc5>4Ew`a7czAW9FIyrW2hXd6Dd+>TIpjpICbSiF)VjTNOOBA}+WKPBW6$3(+^@Ke zpU40=1Cb<0r(Vw{r+x@F4*@o>)14zcd@g8-^vvD?2&DqqFTh&#?a6yNx+d+!EICo? z!jzQGlVbd(C?dKhoA+7>L+4Hw?8kbBAPK*20L$6SE|gC7^=J zq3*U@KpbYiGBPZ>|T|wp#rD>obwtk6v(N$q76)(%3n5U)9eFa_NmxRV{5^u zuWyZ7ROL+kXUGLBM4SAYaQ))E*NR7iv0ey?>aO5YDnJr|L*r zDrOEHC<~XTesyIGVUr~OM?x*d$_A+c#J^9Y`a|B!Yw5-1`T27)#8oCsAcx&wX(%JN zX;ib8_8*;#zPz3piTU}4ze+97Yb`a+IWho*48ZSEZ5t{K)9u0SX`yl>rcw@ z4Z)`nT+P>zuJl(1MJ88BsE}NZ2pW;&hwCe~w#kJ+2U6!uWBoW}Xl;&MGAaJ?cP5_6 z4nzx+C&pNWK@A^0upa~my=lKqO}Te#SH%BJNGAqmiAGs7B8EJMh)BW0aC#jaX2fU| zuy(}t;yz8s_|p0Lb#9oXn4^vay=Y>{;NW-CDqXle-lGeSv5$6r#2bxkzl>j12+j&aMaf?fBHny;`_#^Z3^0p zOBZz1J82OYQBYhn5r94Oi{3;TVt3!6o9$W&BSuY~oELwc96-%Q1hvI(#h~%D4VUh-X@d;?mq@>W+5+fjwnn?ecxFgklNg$^ z_S=(hN9(|32lixoRo=mEx0rcogBM!*xK`mN9e7PJfJXN%YG}_#OCow&;AJoQWtppI zgPEZRt7~x|2k!AkM!{1v%gjp82KWGKqex=BF<14FN@#Gvd$|H*5O~oLQX9{la(Xb@ zIaAA^LPDc%|ETct-*WfD-wjNn=IXz{H5K01B0sWK+|l%rh|^D3J0am}J|8xluktJD z-;TIx0)mdDRGRbiZNz9*O-$mo&CTkYJF}Nsea@e1S5^$VaYRnTU%6zd!QRHMD1Y+D zuYM~M@jVCs&FX5++#*5Ja(6%INoP7dJUZj>aN-L|lOl6MpA$pLosQm=WMTHrkPaic zab7_V&~GNJtf4U2lSvtHiE^quyDNwZgIOGLD_bpy2SEicNn+q#y-rso0b2~gJT@)H z64;`amb)Jxo%rf_xIb9grumS|6SufvU~NnY8bt%IJd<$`Jsrr`QxS7mH=P!H3J(od zgE+WCSnj#GUBPtZz!ccj^{57B0x5StFNW^Y*}L|=OkP(H#3v)&XZ!boeLuF{7qc2Zsi zXC#Lo=UMEWA3f&b#)k~ve27gGYmCg}yZt~lL@6Ek*$z6S?&oI~m3#9UFV1gMQjOTy zumtQ2d}(ah|LJl=C>bakPxKKd1OpbNUrd5tLR&lH=!;t|w)O$u3Hr3O1~SpRMJC$! zDItg9Is}36oUvRN80dX;+&dz%5GhsOjbvd1en&^Lb^QZLN2E;!P;`ia zSA4WmY`kSwWT(x|Zdd6cuJ;zu78M&l-{XDt z4p1rPYA?S2CMgOE`S)p5)Rr?8duJqp>Dl$iZcQhs6J(uIOs;1<`_bq6v)eG_ps4>; z;Z8b=f`H1jq_Vs^W^~ePl$o9oVEvbNL5Ij}JcyTxiKWuFc` zq@d8r)Vr;c68Dtu+I;W928W1w&8mRy1~etpQ*%$S2Du>20gkaOfc7{h z<(Mtd+Dd0A8K{kT(6ii)Jv~Be{8<{p{#{$JUji69EuMMtWeka^URrcL85!|*ehDfR z_@aTJ?F1ZPn$z9IwCANiTJb^PYau}I{)hg+K(BH9SgRRqaD9L7!NbTJ^obDf*AA** zK==gMC|#t!8@@Nr7N6kmUukDk$x;>f|KE__{5c_3RFJYRlJ_9)e{go!$&)V$evbwA8w- zmG<5Ew}f9T6(GVowBxNA)lC>nRZoS1NHz!j>3O(q8L&dV#m}pj z@tzb|DFO6Tvi9BG-!qLj-qKZ0@RwC@j1OYT-%weyQ2HherA$o7SeikAM@81Mz>d@~ zt)@2s=qp!Of>#Jp%;t;B`f)d4o@`!BA#T%DapDf%DeQ?)_1E^^E$O zrPu01S(mDss;7eK&OI(?x2*yBxO#YaySHuMTJrHPwV{f+ zmAYfOiM;@FA|U^a8u%slwZMQ_QIf&CK1e2P+u7l@gYKTI(&WDeKl1?L1j^fO;M-)X z;GiK99Hn~GZdgxEmKf21$o@^iRp8<}LiWFw#ZBOOxqZ1XvbP*+8V^j!OT4N&?}AgZpye1q&=$Khe-I|zw;0~CUjzpDwdFz&^RwIs~~Tw ziD@!t1bD{?1o0RNA+mQJgf_5DN)m>80kty{T{00Q@fgkPcjGVsHn37r0dWC-EOJF; zTr9VQkyFLJk_b_3I@*_)tg|n3A))mLYmR;x0n2J`_8COKYj`e?Q-R=svTs~ukF*1; z>lo^LdEuQQsjY;Td7<)C%+~Wz0iFxr`|7kH77$e}yP=gpuL|O+SCT~19yRsNR8gq= zR{7fuhK09H7n`+Hl~Hz$eI+uve;BM0j(C!_gQk90vM`igJ}NE z2FL6tu*-L3U&UEM>Fin6OEL;YMJSYCj7Ak$C!p&oMJ4h~iVb~Eq(aCj5hpQRaoa(q zR)wH{ z^n3uin$*Mu1lEZ-MwpGTi>Q$7STl6{Fz;ksr-nXgL@e1QN>a?~JcU;l8x){uaN|=aZsOKA!Xr=&M_~-3G|(=@>c$fuUlB0Nx#_L)dBV2K(LV8W_blN@@fVJ_p&b)x3flVFDI~)w`FB1 z$7>nP{`7mA$@uC<&uGJ-w&lji+FnSF(r3LgSdqoD=#%w(LUi-1&ZtpGAn ztD`_Kup2SDYuiG9eOVs;g833>)skAV!tA)$k z6K()EIg{BY)Tzt{f<{#@?^n;iMuZpj+}RDL$iK&7Rp|bk$Q~K|AgiY4RYiu<8;zK_ zqu1=LVlbmZ@uk$e-a*p}IP*3@!JGvw8ow_KInV)G!m$uMjq}tCN@{^Z7NrGdbn2S4L7i+}z$vohe#9SBJ;J zrw3ec-w4=ttFk~1yE-~K*&VD6Bi+mYqU3k3Ta$eAS=N1G7KXgTYg7mpzjdl|@5T+C zk}nq7T7P&_x+j&6b%aF{JiiQ&J2^RB6BO*48g^lFHo`_ are used to map isotope to hash values with which all possible isotopes can be described. + A base class to describe charged molecular ions with an adjustable number of atoms/isotopes building each ion. Right now the maximum number of atoms supported building a molecular ion is 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with which all possible isotopes can be described. + + :ref:`NXlens_em`: + A base class to detail an electro-magnetic lens. In practice, an electron microscope has many such lenses. It is possible to specify as many lenses as necessary to represent eventually each single lens of the microscope and thus describe how the lenses are affecting the electron beam. This can offer opportunities for developers of software tools which strive to model the instrument e.g. to create digital twins of the instrument. We understand there is still a way to go with this to arrive there though. Consequently, we suggest to focus first on which details should be collected for a lens as a component so that developers of application definitions can take immediate advantage of this work. + + :ref:`NXfabrication`: + A base class to bundle manufacturer/technology-partner-specific details about + a component or device of an instrument. :ref:`NXoptical_system_em`: A base class to store for now qualitative and quantitative values of frequent interest @@ -130,35 +98,34 @@ The following base classes are proposed to support modularizing the storage of p Examples are the semiconvergence angle or the depth of field and depth of focus, the magnification, or the camera length. :ref:`NXpeak`: - A base class to describe peaks mathematically. + A base class to describe peaks mathematically so that it can be used to detail how peaks in mass-to-charge-state ratio histograms (aka mass spectra) are defined and labelled as iontypes. + + :ref:`NXpump`: + A base class to describe details about a pump in an instrument. - :ref:`NXcircuit`: - A base class to describe a logical unit of at least one integrated circuit. + :ref:`NXscanbox_em`: + A base class to represent the component of an electron microscope which realizes a controlled deflection (and eventually shift, blanking, and/or descanning) of the electron beam to illuminate the specimen in a controlled manner. This can be used to document the scan pattern. + :ref:`NXspectrum_set`: + Base class and specializations comparable to NXimage_set but for storing spectra. Specialized base classes should use controlled vocabulary items as prefixes such as **eels** electron energy loss spectroscopy, **xray** X-ray spectroscopy (EDS/STEM, EDX, SEM/EDX, SEM/EDS), **auger** Auger spectroscopy, or **cathodolum** for cathodoluminescence spectra. + + :ref:`NXstage_lab`: + As it was mentioned for atom probe microscopy, this is a base class to describe the stage/specimen holder which offers place for the documentation of the small-scale laboratory functionalities which modern stages of electron microscopes frequently offer. -.. _EmAnalysisClasses: +Method-specific concepts and their usage in application definitions +################################################################### -We provide specific base classes which granularize frequently collected or analyzed quantities in specific application fields of electron microscopy to deal -with the situation that there are cases were logical connections between generated data artifacts mainly exist for the fact that the data artifacts were -collected during a workflow of electron microscopy research (e.g. taking measurements and then performing method-specific analyses generating new data and conclusions). -We see a value in granularizing out these pieces of information into own classes. In fact, one limitation of application definitions in NeXus, exactly as it applies for serialization -of information also more generally, is currently that they define a set of constraints on their graph of controlled concepts and terms. +It became clear during the design of the electron-microscopy-specific additions to NeXus that there are sets of pieces of information (data and metadata) which are relevant for a given experiment but have usually only few connections to the detailed description of the workflow of processing these data into knowledge, motivating the granularization of these pieces of information in their own application definition. In fact, one limitation of application definitions in NeXus is that they define a set of constraints on their graph of controlled concepts and terms. If we take for example diffraction experiments with an electron microscope it is usually the case that (diffraction) patterns are collected in the session at the microscope but all scientifically relevant conclusions are drawn later, i.e. through post-processing these data. These numerical and algorithmic steps define computational workflows where data from the application definitions such as NXem are used as input but many additional concepts and constraints may apply without any need for changing constraints on fields or groups of NXem. If we were to modify NXem for these cases, NXem would likely combinatorially diverge as every different combination of required constraints would demand having their own but almost similar application definition. For this reason, we propose to define the following base classes: -If we take for example diffraction experiments performed with an electron microscope, it is usually the case that (diffraction) patterns are collected in the session at the microscope. -However, all scientifically relevant conclusions are typically drawn later, i.e. through post-processing the collected diffraction (raw) data. These numerical and algorithmic steps -define computational workflows were data from an instance of an application definition such as NXem are used as input but many additional concepts, constraints, and assumptions -are applied without that these demand necessarily changes in the constraints on fields or groups of NXem. If we were to modify NXem for these cases, -NXem would combinatorially diverge as every different combination of required constraints demands having an own but almost similar application definition. -For this reason, method-specific base classes are used which granularize out how specific pieces of information are processed further to eventually enable their -storage (i.e. serialization) using NeXus. +More consolidation through the use of NXsubentry classes should be considered in the future. -More consolidation through the use of NXsubentry classes should be considered in the future. For now we use an approach whereby base classes are combined to reuse vocabulary and a hierarchical organization of pieces of information with specific constraints which are relevant only for specific usage of such data by specific tools used by an eventually smaller circle of users. + :ref:`NXem_ebsd`: + Application definition for collecting and indexing Kikuchi pattern into orientation maps for the two-dimensional, three- and four-dimensional case. - :ref:`NXem_method`, :ref:`NXem_ebsd`, :ref:`NXem_eds`, :ref:`NXem_eels`, :ref:`NXem_img`, :ref:`NXem_correlation`: - Base classes with method-specific details especially when it comes to reporting post-processed data within electron microscopy. +Several new base classes are used by this application definition. - :ref:`NXcrystal_structure`: - A base class to store crystalline phase/structure used for a simulation of diffraction pattern and comparison of these pattern against patterns to support indexing. + :ref:`NXem_ebsd_conventions`: + A collection of reference frames and rotation conventions necessary to interpret the alignment and orientation data. - :ref:`NXroi`: - A base class to granularize information collected and relevant for the characterization of a region-of-interest. + :ref:`NXem_ebsd_crystal_structure_model`: + A description of a crystalline phase/structure used for a forward simulation using kinetic or dynamic diffraction theory to generate simulated diffraction pattern against which measured pattern can be indexed. diff --git a/manual/source/classes/contributed_definitions/icme-structure.rst b/manual/source/classes/contributed_definitions/icme-structure.rst deleted file mode 100644 index 68c6f9859e..0000000000 --- a/manual/source/classes/contributed_definitions/icme-structure.rst +++ /dev/null @@ -1,48 +0,0 @@ -.. _Icme-Structure: - -============================================== -Integrated Computational Materials Engineering -============================================== - -.. index:: - IcmeMsModels - -.. _IcmeMsModels: - -Application definitions for ICME models -####################################### - -It is important to embrace the large research community of materials engineers -as they are frequent users of electron microscopy and atom probe microscopy. -ICME is an abbreviation for Integrated Computational Materials Engineering, which is -a design strategy and workflow whereby physics-based modelling of microstructure -evolution is used to understand the relations between the microstructure and -its technologically relevant descriptors to understand and tailor properties of materials. - -The following application definitions are proposed to support the discussion on how -materials-engineering-specific data schemas can connect to or be mapped on -concepts which are equally modellable with NeXus: - - :ref:`NXmicrostructure`: - A base class for documenting a snapshot of a reconstructed microstructure. - - :ref:`NXmicrostructure_imm_config`, :ref:`NXmicrostructure_imm_results`: - A specific example of an application definition for documenting the - configuration and results respectively of a computer simulation with - the legacy microstructure synthesizer developed at the Institut für - Metallkunde und Metallphysik in Aachen. - - :ref:`NXmicrostructure_kanapy_results`: - A specific example of an application definition for documenting the results - of a computer simulation with the kanapy microstructure synthesizer - developed at the ICAMS in Bochum. - - :ref:`NXmicrostructure_score_config`, :ref:`NXmicrostructure_score_results`: - A specific example of an application definition for documenting the - configuration and results respectively of a computer simulation with - the static recrystallization cellular automata model SCORE. - - :ref:`NXmicrostructure_gragles_config`, :ref:`NXmicrostructure_gragles_results`: - A specific example of an application definition for documenting the - configuration and results respectively of a computer simulation with - the grain growth level-set-based model GraGLeS. diff --git a/manual/source/classes/contributed_definitions/mpes-structure.rst b/manual/source/classes/contributed_definitions/mpes-structure.rst index ab05f3a79a..1d37fdba67 100644 --- a/manual/source/classes/contributed_definitions/mpes-structure.rst +++ b/manual/source/classes/contributed_definitions/mpes-structure.rst @@ -1,8 +1,8 @@ .. _Mpes-Structure: -======================================= +============================================== Photoemission & core-level spectroscopy -======================================= +============================================== .. index:: IntroductionMpes @@ -17,7 +17,7 @@ Photoemission & core-level spectroscopy Introduction ############ -Set of data storage objects to describe multidimensional photoemission (MPES) experiments including x-ray photoelectron spectroscopy (XPS), ultraviolet photoelectron spectroscopy (UPS), +Set of data storage objects to describe photoemission experiments including x-ray photoelectron spectroscopy (XPS), ultraviolet photoelectron spectroscopy (UPS), hard x-ray photoelectron spectroscopy (HAXPES), angle-resolved photoemission spectroscopy (ARPES), two-photon photoemission (2PPE) and photoemission electron microscopy (PEEM). Also includes descriptors for advanced specializations, such as spin-resolution, time resolution, near-ambient pressure conditions, dichroism etc. @@ -28,13 +28,7 @@ Application Definitions ####################### :ref:`NXmpes`: - A general application definition with minimalistic metadata requirements, apt to describe all photoemission experiments. - - :ref:`NXmpes_arpes`: - An application definition for angle-resolved photoemission spectroscopy (ARPES) experiments. - - :ref:`NXxps`: - An application definition for X-ray/ultraviolet photoelectron spectroscopy (XPS/UPS) measurements. + A general appdef with minimalistic metadata requirements, apt to describe all photemission experiments. .. _MpesBC: @@ -67,25 +61,16 @@ Three base classes to describe data processing, which can be used as subclasses :ref:`NXregistration`: A base class to describe the rigid transformations that are applied to an image. May be redundant as they can be described with :ref:`NXtransformations`. - - :ref:`NXprocess_mpes`: - A base class specializing :ref:`NXprocess`, describing events of data processing, reconstruction, or analysis for photoemission-related data. .. _MpesCommonBC: Common Base Classes ################### -There are related base classes that are common to other techniques: +There are two related base classes that are common to other techniques: :ref:`NXlens_em`: A class to describe all types of lenses. Includes electrostatic lenses for electron energy analysers. :ref:`NXdeflector` - A class to describe all kinds of deflectors, including electrostatic and magnetostatic deflectors for electron energy analysers. - - :ref:`NXresolution`: - Describes the resolution of a physical quantity, e.g. the resolution of the MPES spectrometer. - - :ref:`NXfit`, :ref:`NXpeak`, :ref:`NXfit_background`, :ref:`NXfit_function`, :ref:`NXfit_parameter`: - Base classes for describing a fit procedure, e.g. a peak fitting in energy space in XPS. \ No newline at end of file + A class to describe all kinds of deflectors, including electrostatic and magnetostatic deflectors for electron energy analysers. \ No newline at end of file diff --git a/manual/source/classes/contributed_definitions/sample-prep-structure.rst b/manual/source/classes/contributed_definitions/sample-prep-structure.rst deleted file mode 100644 index 39f8249e9e..0000000000 --- a/manual/source/classes/contributed_definitions/sample-prep-structure.rst +++ /dev/null @@ -1,20 +0,0 @@ -.. _Synthesis-Structure: - -================== -Sample preparation -================== - -.. index:: - SamplePreparation - -.. _SamplePreparation: - -Document steps of wet-lab sample preparation -############################################ - -Virtually all experiments require a preparation of the sample. As most techniques are surface-sensitive or probe exclusively the surface, the use of careful preparation -techniques is the key to successful experiments. Unfortunately, the quality of such processes is often difficult to reproduce. Nevertheless, documenting how samples -are prepared is relevant. This part of the proposal provides prototypes how descriptions of steps performed by human or robots in a lab could be described using NeXus. - - :ref:`NXlab_electro_chemo_mechanical_preparation`, :ref:`NXlab_sample_mounting`: - Prototype application definitions for documenting steps during sample preparation. diff --git a/manual/source/classes/contributed_definitions/sts-structure.rst b/manual/source/classes/contributed_definitions/sts-structure.rst deleted file mode 100644 index 42aef5e6e6..0000000000 --- a/manual/source/classes/contributed_definitions/sts-structure.rst +++ /dev/null @@ -1,47 +0,0 @@ -.. _Stm-Structure: - -=============================== -Scanning Tunneling Spectroscopy -=============================== - -.. index:: - StsAppDef - StsBC - -.. _StsAppDef: - -Application Definition -###################### - - :ref:`NXsts`: - An application definition for scanning tunneling spectroscopy experiments. - -.. _StsNewBC: - -Base Classes -############ - - :ref:`NXamplifier`: - A base class - - :ref:`NXbias_spectroscopy`: - A base class - - :ref:`NXcircuit`: - A base class - - :ref:`NXiv_bias`: - A base class - - :ref:`NXlockin`: - A base class - - :ref:`NXpid`: - A base class - - :ref:`NXpositioner_sts`: - A base class - - :ref:`NXsensor_scan`: - A base class - diff --git a/manual/source/classes/contributed_definitions/transport-structure.rst b/manual/source/classes/contributed_definitions/transport-structure.rst index be41f0f785..6aaf6844e5 100644 --- a/manual/source/classes/contributed_definitions/transport-structure.rst +++ b/manual/source/classes/contributed_definitions/transport-structure.rst @@ -12,7 +12,7 @@ Transport Phenomena .. _IntroductionTransport: Introduction -############ +############## .. _TransportAppDef: @@ -20,5 +20,13 @@ Introduction Application Definitions ####################### +We realize that many experiments in condensed-matter physics and materials engineering belong to the category +of measurements of transparent phenomena. A possible example of such experiments are temperature-dependent +current-voltage (IV) curve measurements (or JV for engineers) measurements. In this case, electrical charge is transported +and the temperature-dependent current response as a function of applied voltage is recorded. + +Below is an example for such an application definition for an experiment. This application definition has exemplar parts +which show how such an experiment can be controlled with the `EPICS system `_: + :ref:`NXiv_temp`: Application definition for temperature-dependent current-voltage (IV) curve measurements. From c61e6af3706c1901ebac22920575c3ba7002a5db Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 24 Sep 2024 13:14:15 +0200 Subject: [PATCH 0979/1012] bring in multi line doc handling in dev_tools --- dev_tools/docs/nxdl.py | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/dev_tools/docs/nxdl.py b/dev_tools/docs/nxdl.py index 157acce335..ed3db94cca 100644 --- a/dev_tools/docs/nxdl.py +++ b/dev_tools/docs/nxdl.py @@ -303,12 +303,34 @@ def _get_doc_blocks(ns, node): out_blocks.append("\n".join(out_lines)) return out_blocks + def _handle_multiline_docstring(self, blocks): + links = [] + docstring = "" + expanded_blocks = [] + for block in blocks: + expanded_blocks += block.split("\n") + + for block in expanded_blocks: + if not block: + continue + + link_match = re.search(r"\.\. _([^:]+):(.*)", block) + if link_match is not None: + links.append((link_match.group(1), link_match.group(2).strip())) + else: + docstring += " " + re.sub(r"\n", " ", block.strip()) + + for name, target in links: + docstring = docstring.replace(f"`{name}`_", f"`{name} <{target}>`_") + + return docstring + def _get_doc_line(self, ns, node): blocks = self._get_doc_blocks(ns, node) if len(blocks) == 0: return "" if len(blocks) > 1: - raise Exception(f"Unexpected multi-paragraph doc [{'|'.join(blocks)}]") + return self._handle_multiline_docstring(blocks) return re.sub(r"\n", " ", blocks[0]) def _get_minOccurs(self, node): From 5680ff24d3abf295624419ae171dbbddf6103613 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 28 Aug 2025 08:45:06 +0200 Subject: [PATCH 0980/1012] remove renamed classes --- .../NXapm_paraprobe_config_clusterer.nxdl.xml | 477 ---- .../NXapm_paraprobe_config_distancer.nxdl.xml | 257 --- ...Xapm_paraprobe_config_intersector.nxdl.xml | 348 --- .../NXapm_paraprobe_config_nanochem.nxdl.xml | 1114 ---------- .../NXapm_paraprobe_config_ranger.nxdl.xml | 297 --- .../NXapm_paraprobe_config_selector.nxdl.xml | 142 -- .../NXapm_paraprobe_config_spatstat.nxdl.xml | 374 ---- .../NXapm_paraprobe_config_surfacer.nxdl.xml | 289 --- ...Xapm_paraprobe_config_tessellator.nxdl.xml | 253 --- ...NXapm_paraprobe_config_transcoder.nxdl.xml | 119 - ...NXapm_paraprobe_results_clusterer.nxdl.xml | 503 ----- ...NXapm_paraprobe_results_distancer.nxdl.xml | 388 ---- ...apm_paraprobe_results_intersector.nxdl.xml | 395 ---- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 1965 ----------------- .../NXapm_paraprobe_results_ranger.nxdl.xml | 425 ---- .../NXapm_paraprobe_results_selector.nxdl.xml | 274 --- .../NXapm_paraprobe_results_spatstat.nxdl.xml | 364 --- .../NXapm_paraprobe_results_surfacer.nxdl.xml | 503 ----- ...apm_paraprobe_results_tessellator.nxdl.xml | 677 ------ ...Xapm_paraprobe_results_transcoder.nxdl.xml | 568 ----- contributed_definitions/NXatom_set.nxdl.xml | 158 -- .../NXbias_spectroscopy.nxdl.xml | 168 -- .../NXcoordinate_system_set.nxdl.xml | 235 -- contributed_definitions/NXdata_mpes.nxdl.xml | 134 -- .../NXdata_mpes_detector.nxdl.xml | 147 -- .../NXgraph_edge_set.nxdl.xml | 121 - .../NXgraph_node_set.nxdl.xml | 118 - contributed_definitions/NXgraph_root.nxdl.xml | 35 - contributed_definitions/NXiv_bias.nxdl.xml | 192 -- contributed_definitions/NXlockin.nxdl.xml | 151 -- .../NXms_feature_set.nxdl.xml | 300 --- .../NXms_score_config.nxdl.xml | 452 ---- .../NXms_score_results.nxdl.xml | 720 ------ .../NXms_snapshot.nxdl.xml | 54 - .../NXms_snapshot_set.nxdl.xml | 62 - ....nxdl.xml => NXoptical_polarizer.nxdl.xml} | 125 +- .../NXorientation_set.nxdl.xml | 133 -- .../NXpositioner_sts.nxdl.xml | 310 --- contributed_definitions/NXsensor_sts.nxdl.xml | 233 -- .../NXslip_system_set.nxdl.xml | 85 - .../NXsolid_geometry.nxdl.xml | 56 - contributed_definitions/NXsts.nxdl.xml | 995 --------- 42 files changed, 59 insertions(+), 14657 deletions(-) delete mode 100644 contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_config_selector.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_results_clusterer.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_results_intersector.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_results_selector.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_results_spatstat.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml delete mode 100644 contributed_definitions/NXatom_set.nxdl.xml delete mode 100644 contributed_definitions/NXbias_spectroscopy.nxdl.xml delete mode 100644 contributed_definitions/NXcoordinate_system_set.nxdl.xml delete mode 100644 contributed_definitions/NXdata_mpes.nxdl.xml delete mode 100644 contributed_definitions/NXdata_mpes_detector.nxdl.xml delete mode 100644 contributed_definitions/NXgraph_edge_set.nxdl.xml delete mode 100644 contributed_definitions/NXgraph_node_set.nxdl.xml delete mode 100644 contributed_definitions/NXgraph_root.nxdl.xml delete mode 100644 contributed_definitions/NXiv_bias.nxdl.xml delete mode 100644 contributed_definitions/NXlockin.nxdl.xml delete mode 100644 contributed_definitions/NXms_feature_set.nxdl.xml delete mode 100644 contributed_definitions/NXms_score_config.nxdl.xml delete mode 100644 contributed_definitions/NXms_score_results.nxdl.xml delete mode 100644 contributed_definitions/NXms_snapshot.nxdl.xml delete mode 100644 contributed_definitions/NXms_snapshot_set.nxdl.xml rename contributed_definitions/{NXpolarizer_opt.nxdl.xml => NXoptical_polarizer.nxdl.xml} (57%) delete mode 100644 contributed_definitions/NXorientation_set.nxdl.xml delete mode 100644 contributed_definitions/NXpositioner_sts.nxdl.xml delete mode 100644 contributed_definitions/NXsensor_sts.nxdl.xml delete mode 100644 contributed_definitions/NXslip_system_set.nxdl.xml delete mode 100644 contributed_definitions/NXsolid_geometry.nxdl.xml delete mode 100644 contributed_definitions/NXsts.nxdl.xml diff --git a/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml deleted file mode 100644 index b740203e4f..0000000000 --- a/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml +++ /dev/null @@ -1,477 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - - Maximum number of atoms per molecular ion. Should be 32 for paraprobe. - - - - - Number of clustering algorithms used. - - - - - Number of different iontypes to distinguish during clustering. - - - - - Configuration of a paraprobe-clusterer tool run in atom probe microscopy. - - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - How many tasks to perform? - - - - - This process maps results from cluster analyses performed with IVAS/APSuite - into an interoperable representation. Specifically in this process - paraprobe-clusterer takes results from clustering methods from other tools - of the APM community, like IVAS/APSuite. These results are usually reported - in two ways. Either as an explicit list of reconstructed ion positions. - In the case of IVAS these positions are reported through a text file - with a cluster label for each position. - - Alternatively, the list of positions is reported, as it is the case for - AMETEK (IVAS/AP Suite) but the cluster labels are specified implicitly - only in the following way: The mass-to-charge-state ratio column of a - what is effectively a file formatted like POS is used to assign a hypothetical - mass-to-charge value which resolves a floating point representation - of the cluster ID. - - Another case can occur where all disjoint floating point values, - i.e. here cluster labels, are reported and then a dictionary is created - how each value matches to a cluster ID. - - In general the cluster ID zero is reserved for marking the dataset - as to not be assigned to any cluster. Therefore, indices of disjoint - clusters start at 1. - - - - - - - - - AMETEK/Cameca results of cluster analyses, like with the maximum- - separation (MS) method clustering algorithm `J. Hyde et al. <https://doi.org/10.1557/PROC-650-R6.6>`_ - are stored as an improper POS file: This is a matrix of floating - point quadruplets, one for each ion and as many quadruplets as - ions were investigated. The first three values encode the position - of the ion. The fourth value is an improper mass-to-charge-state-ratio - value which encodes the integer identifier of the cluster as a floating - point number. - - - - - - - Specifies if the tool should try to recover for each position the closest - matching position from dataset/dataset_name_reconstruction (within - floating point accuracy). This can be useful for instance when users - wish to recover the original evaporation ID, which IVAS/AP Suite drops - for instance when writing their *.indexed.* cluster results POS files. - - - - - - - This process performs a cluster analysis on a reconstructed dataset - or a portion of the reconstruction. - - - - - - - - - - - - - - - - - The tool enables to inject precomputed distance information for each - point/ion which can be used for further post-processing and analysis. - - - - Name of an HDF5 file which contains the ion distances. - - - - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - - - - - - Absolute HDF5 path to the dataset with distance values for each ion. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - How should iontypes be interpreted/considered during the cluster analysis. - Different options exist how iontypes are interpreted (if considered at all) - given an iontype represents in general a (molecular) ion with different isotopes - that have individually different multiplicity. - - The value resolve_all will set an ion active in the analysis - regardless of which iontype it is. - The value resolve_unknown will set an ion active when it is of the - UNKNOWNTYPE. - The value resolve_ion will set an ion active if it is of the - specific iontype, irregardless of its elemental or isotopic details. - The value resolve_element will set an ion active, and most importantly, - account as many times for it, as the (molecular) ion contains - atoms of elements in the whitelist ion_query_isotope_vector. - The value resolve_isotope will set an ion active, and most importantly, - account as many times for it, as the (molecular) ion contains isotopes - in the whitelist ion_query_isotope_vector. - - In effect, ion_query_isotope_vector acts as a whitelist to filter - which ions are considered as source ions of the correlation statistics - and how the multiplicity of each ion will be factorized. - - This is relevant as in atom probe we have the situation that a ion - of a molecular ion with more than one nuclid, say Ti O for example - is counted such that although there is a single TiO molecular ion - at a position that the cluster has two members. This multiplicity - affects the size of the feature and chemical composition. - - - - - - - - - Matrix of isotope vectors, as many as rows as different candidates - for iontypes should be distinguished as possible source iontypes. - In the simplest case, the matrix contains only the proton number - of the element in the row, all other values set to zero. - Combined with ion_query_type_source set to resolve_element this will - recover usual spatial correlation statistics like the 1NN C-C - spatial statistics. - - - - - - - - - Settings for DBScan clustering algorithm. For original details about the - algorithms and (performance-relevant) details consider: - - * `M. Ester et al. <https://dx.doi.org/10.5555/3001460.3001507>`_ - * `M. Götz et al. <https://dx.doi.org/10.1145/2834892.2834894>`_ - - For details about how the DBScan algorithms is the key behind the - specific modification known as the maximum-separation method in the - atom probe community consider `E. Jägle et al. <https://dx.doi.org/10.1017/S1431927614013294>`_ - - - - Strategy how runs are performed with different parameter: - - * For tuple as many runs are performed as parameter values. - * For combinatorics individual parameter arrays are looped over. - - As an example we may define eps with ten entries and min_pts with - three entries. If high_throughput_method is tuple the analysis is - invalid as we have an insufficient number of min_pts for the ten - eps values. - By contrast, for combinatorics paraprobe-clusterer will run three - individual min_pts runs for each eps value, resulting in a total - of 30 analyses. - As an example the DBScan analysis reported in `M. Kühbach et al. <https://dx.doi.org/10.1038/s41524-020-00486-1>`_ - would have defined an array of values np.linspace(0.2, 5.0, nums=241, endpoint=True) - eps values, min_pts one, and high_throughput_method set to combinatorics. - - - - - - - - - Array of epsilon (eps) parameter values. - - - - - - - - Array of minimum points (min_pts) parameter values. - - - - - - - - - - Settings for the OPTICS clustering algorithm. - - * `M. Ankerest et al. <https://dx.doi.org/10.1145/304181.304187>`_ - - - - Strategy how runs are performed with different parameter: - - * For tuple as many runs are performed as parameter values. - * For combinatorics individual parameter arrays are looped over. - - See the explanation for the corresponding parameter for dbscan - processes above-mentioned for further details. - - - - - - - - - Array of minimum points (min_pts) parameter values. - - - - - - - - Array of maximum epsilon (eps) parameter values. - - - - - - - - - Settings for the HPDBScan clustering algorithm. - - * L. McInnes et al. <https://dx.doi.org/10.21105/joss.00205>`_ - * scikit-learn hdbscan library `<https://hdbscan.readthedocs.io/en/latest/how_hdbscan_works.html>`_ - - See also this documentation for details about the parameter. - Here we use the terminology of the hdbscan documentation. - - - - Strategy how runs are performed with different parameter: - - * For tuple as many runs are performed as parameter values. - * For combinatorics individual parameter arrays are looped over. - - See the explanation for the corresponding parameter for dbscan - processes above-mentioned for further details. - - - - - - - - - Array of min_cluster_size parameter values. - - - - - - - - Array of min_samples parameter values. - - - - - - - - Array of cluster_selection parameter values. - - - - - - - - Array of alpha parameter values. - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml deleted file mode 100644 index 14db557bd6..0000000000 --- a/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml +++ /dev/null @@ -1,257 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Configuration/settings of a paraprobe-distancer software tool run. - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - How many individual analyses should the tool execute. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Compute for all filtered points, e.g. ions of the point set - the shortest Euclidean distance to the closest triangle of the - set of triangles. The triangles can formed a closed surface mesh. - Distances are not simple distances based on normal projections but - giving an exact solution. - - - - - Paraprobe-distancer enables the computation of the Euclidean shortest - distance for each member of a set of points against a set of triangles. - In contrast to comparable methods used in atom probe the here computed - distance is not simply the projected distance to one of the triangles - but the more costly but robust computation of the distance between - a point and a triangle. - - The triangles can represent for instance the facets of a triangulated - surface mesh of a model for the edge of the dataset. Such a model can - be computed with paraprobe-surfacer. Alternatively, the triangles can - be those from the set of all facets for a set of convex hulls, alpha-shapes, - or alpha wrappings about three-dimensional objects like precipitates - (computed with e.g. paraprobe-nanochem). - - Currently, the tool does not check if the respectively specified - triangle sets are consistent, what their topology is, or whether or - not they are consistently oriented. - Each dataset that is referred to in the list_of _dataset_names_vertices - should be an (Nvertices, 3) array of NX_FLOAT. Each dataset referred - to in the list_of_dataset_names_facet_indices should be an - (Nfacets, 3) array of NX_UINT. - Facet indices refer to vertex indices. These need to start at zero - and must not exceed Nvertices - 1, i.e. the identifier_offset is 0 - and vertices are indexed thus implicitly. - Facet normal vectors have to be also an array - of shape (Nfacets, 3) of NX_FLOAT. - - - - How many triangle sets to consider. - - - - - List of triangle sets. This design allows users to combine - multiple triangle sets. - - - - Name of the HDF5 file(s) which contain(s) vertex coordinates - and facet indices to describe the desired set of triangles. - - - - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional - layer of reproducibility. - - - - - - Absolute HDF5 path to the dataset which - specifies the array of vertex positions. - - - - - Absolute HDF5 path to the dataset which - specifies the array of facet indices. - - - - - Absolute HDF5 path to the dataset which - specifies the array of facet normal vectors. - - - - - - - Specifies for which ions/points the tool will compute distances. - The purpose of this setting is to avoid unnecessary computations - when the user requests to only compute distances of ions within a - threshold distance to the triangle soup. - - By default the distances are computed for all ions; however - the setting skin enables to compute distances only for those - ions which are not farther away located to a triangle - than threshold_distance. - - - - - - - - - - Maximum distance for which distances are computed when method is skin. - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml deleted file mode 100644 index 615b3b76ac..0000000000 --- a/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml +++ /dev/null @@ -1,348 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Configuration of a paraprobe-intersector tool run in atom probe microscopy. - - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - ISO 8601 formatted time code with local time zone offset to - UTC information included when this configuration file was created. - - - - - For now a support field for the tool to identify how many individual - analyses the tool should execute as part of the analysis. - - - - - Tracking volume_volume_spatial_correlation is the process of building logical - relations between volumetric features based on meshes, their proximity and - eventual intersections. Volumetric overlap and proximity of volumetric - features is identified for members of sets of features to members of - other sets of volumetric features. - Specifically, for each time step k pairs of sets are compared: - Members of a so-called current_set to members of a so-called next_set. - Members can be different types of volumetric features. - In the analysis of M. Kuehbach et al. specifically features can be - so-called objects (closed non-degnerated polyhedra representing watertight - parts of an e.g. iso-surface) and/or proxies. Proxies are computed - doppelganger/replacement meshes for parts of an iso-surface which initially - were not resulting in watertight meshes because objects at the edge - of the dataset or incompletely measured or truncated objects. - - - - Specifies the method whereby to decide if two objects intersect volumetrically. - For reasons which are detailed in the supplementary material of - `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_, the tool by - default assumes that two objects intersect if they share at least one - ion with the same evaporation ID (shared_ion). - Alternatively, with specifying tetrahedra_intersections, - the tool can perform an intersection analysis which attempts to - tetrahedralize first each polyhedron. If successful, the tool then checks - for at least one pair of intersecting tetrahedra to identify if two objects - intersect or not. - - However, we found that these geometrical analyses can result in corner - cases which the currently used library (TetGen) was not unable to - tetrahedralize successfully. These cases were virtually always - associated with complicated non-convex polyhedra which had portions - of the mesh that were connected by almost point like tubes of triangles. - Finding more robust methods for computing intersections between - not necessarily convex polyhedra might improve the situation in the future. - - - - - - - - Specifies if the tool evaluates if for each pair the two objects - (and proxies if used) intersect volumetrically. - - - - - Specifies if the tool evaluates if for each pair the two objects - (and proxies if used) lie closer to one another than the - threshold_proximity. - - - - - Specifies if the tool evaluates, ones all tracking tasks were - successfully completed, how intersecting or proximity related - objects build sub-graphs. This is the feature which enabled - M. Kühbach et al. 2022 the high-throughput analyses of how many - objects are coprecipitates in the sense that they are single, - duplet, triplet, or high-order. For these analyses to work - has_object_volume needs to be activated. - - - - - The maximum Euclidean distance between two objects below which - both objects are still considered within proximity. - - - - - - Specifies if the tool stores the so-called forward relations between - nodes representing members of the current_set to nodes representing - members of the next_set. - - - - - Specifies if the tool stores the so-called backward relations between - nodes representing members of the next_set to nodes representing - members of the current_set. - - - - - Current set stores a set of members, meshes of volumetric features, - which will be checked for proximity and/or volumetric intersection, - to members of the current_set. - The meshes were generated as a result of some other meshing process. - - - - This identifier can be used to label the current set. The label - effectively represents (can be interpreted as) the time/iteration - step when the current set was taken. As it is detailed in `M. Kühbach - et al. 2022 <https://arxiv.org/abs/2205.13510>`_, this identifier - takes the role of the time variable :math:`k`. - - - - - - The total number of distinguished feature sets FEATURE. - It is assumed that the members within all these FEATURE sets - are representing a set together. As an example this set might represent - all volumetric_features. However, users might have formed - a subset of this set where individuals were regrouped. - For paraprobe-nanochem this is the case for objects and proxies. - Specifically, objects are distinguished further into those far - from and those close to the edge of the dataset. - Similarly, proxies are distinguished further into those far - from and those close to the edge of the dataset. - So while these four sub-sets contain different so-called types of - features key is that they were all generated for one set, here the - current_set. - - - - - - Descriptive category explaining what these features are. - - - - - - - - - - - Name of the (NeXus)/HDF5 file which contains triangulated - surface meshes of the members of the set as instances of - NXcg_polyhedron_set. - - - - - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - - - - - - String whereby the path to the geometry data can be interferred automatically. - Currently groupname_geometry_prefix/object<ID>/polyhedron. - - - - - Array of identifier whereby the path to the geometry data - can be interferred automatically. - - - - - - - - - - Next set stores a set of members, meshes of volumetric features, - which will be checked for proximity and/or volumetric intersection, - to members of the next_set. - The meshes were generated as a result of some other meshing process. - - - - This identifier can be used to label the next_set. The label - effectively represents (can be interpreted as) the time/iteration - step when the current set was taken. As it is detailed in `M. Kühbach - et al. 2022 <https://arxiv.org/abs/2205.13510>`_, this identifier - takes the role of the time variable :math:`k + 1`. - - - - - - The total number of distinguished feature sets FEATURE. - It is assumed that the members within all these FEATURE sets - are representing a set together. As an example this set might represent - all volumetric_features. However, users might have formed - a subset of this set where individuals were regrouped. - For paraprobe-nanochem this is the case for objects and proxies. - Specifically, objects are distinguished further into those far - from and those close to the edge of the dataset. - Similarly, proxies are distinguished further into those far - from and those close to the edge of the dataset. - So while these four sub-sets contain different so-called types of - features key is that they were all generated for one set, here the - next_set. - - - - - - Descriptive category explaining what these features are. - - - - - - - - - - - Name of the (NeXus)/HDF5 file which contains triangulated - surface meshes of the members of the set as instances of - NXcg_polyhedron_set. - - - - - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - - - - - - String whereby the path to the geometry data can be interferred automatically. - Currently groupname_geometry_prefix/object<ID>/polyhedron. - - - - - Array of identifier whereby the path to the geometry data - can be interferred automatically. - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml deleted file mode 100644 index 340c30e093..0000000000 --- a/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml +++ /dev/null @@ -1,1114 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - How many iontypes does the delocalization filter specify. - - - - - How many disjoint control points are defined. - - - - - How many iontypes does the interface meshing iontype filter specify. - - - - - How many DCOM iterations. - - - - - Maximum number of atoms per molecular ion. - - - - - Configuration of a paraprobe-nanochem tool run in atom probe microscopy. - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - ISO 8601 formatted time code with local time zone offset to - UTC information included when this configuration file was created. - - - - - How many individual analyses should the tool execute as part of the analysis. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The tool enables to inject a previously computed triangle soup or - triangulated surface mesh representing a model (of the surface) of - the edge of the dataset. This model can be used to detect and control - various sources of bias in the analyses. - - - - - Name of the HDF5 file which contains vertex coordinates and facet - indices to describe the desired set of triangles which represents - the edge of the dataset. - - - - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - - - - - - Absolute path to the HDF5 dataset in the respectively specified HDF5 - file under filename which details the array of vertex positions. - - - - - Absolute path to the HDF5 dataset in the respective specified HDF5 - file under filename which details the array of facet indices. - - - - - - The tool enables to inject precomputed distance information for each - point/ion which can be used for further post-processing and analysis. - - - - - Name of an HDF5 file which contains the ion distances. - - - - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - - - - - - Absolute HDF5 path to the dataset with distance values for each ion. - - - - - - - - Discretization of the ion point cloud on a three-dimensional grid. - - - - Delocalization in the field of atom probe microscopy is the process - of discretizing a point cloud. By default the tool computes a full - kernel density estimation of decomposed ions to create one discretized - field for each element. - - Although, this uses an efficient multithreaded algorithm, - the computation is costly. Therefore, it can be advantageous for users - to load an already computed delocalization. This can be achieved with - the load_existent option. - When using this option the user is responsible to assure that the - settings which were used for computing this already existent delocalization - are specified in the same manner as they were. - - - - - - - - - - - Matrix of isotope vectors representing iontypes. - The filter specifies a matrix of isotope_vectors which is the most - general approach to define if and how many times an ion is counted. - Currently, paraprobe_nanochem performs a so-called atomic decomposition - of all iontypes. Specifically, the tool interprets of how many - elements/atoms a molecular ion is composed; and thus determines the - atoms multiplicity with respect to the iontype. - - Let's take the hydroxonium H3O+ molecular ion as an example: - It contains hydrogen and oxygen as atoms. The multiplicity of hydrogen - is three whereas that of oxygen is one. Therefore in an atomic - decomposition computation of the iso-surface each H3O+ ion adds - three hydrogen counts. This is a practical solution which accepts - the situation that during an atom probe experiment not each bond - of each ion/a group of neighboring atoms is broken but molecular - ions get detected. The exact ab-initio details depend on the local - field conditions and thus also the detailed spatial arrangement - of the atoms and their own electronic state and that of the neighbors - before and upon launch. - Being able to measure the information for such sites only as - molecular ions causes an inherent information loss with respect to the - detailed spatial arrangement. This information loss is more relevant - for local electrode atom probe than for field ion microscopy setting - how precisely the atomic positions can be reconstructed. - Accounting for multiplicities assures that at least the - compositional information is analyzed. - - - - - - - - - List of individual grid resolutions to analyse. - Paraprobe discretizes on a cuboidal 3D grid with cubic cells, with - an edge length of values in gridresolutions. - - - - - - Half the width of a :math:`{(2 \cdot n + 1)}^3` cubic kernel of voxel - beyond which the Gaussian Ansatz function will be truncated. - Intensity beyond the kernel is refactored into the kernel via - a normalization procedure. - - - - - Variance of the Gaussian Ansatz kernel :math:`\sigma_x = \sigma_y = 2 \cdot - \sigma_z`. - - - - - - How should the results of the kernel-density estimation be computed - into quantities. By default the tool computes the total number - (intensity) of ions or elements. Alternatively the tool can compute - the total intensity, the composition, or the concentration of the - ions/elements specified by the white list of elements in each voxel. - - - - - - - - - - - Specifies if the tool should report the delocalization 3D field values. - - - - - - - Optional computation of iso-surfaces after each computed delocalization - to identify for instance objects in the microstructure - (line features, interfaces, precipitates). - - - - As it is detailed in M. Kühbach et al. 2022 npj Comp. Mat., - the handling of triangles at the edge of the dataset requires - special attention. Especially for composition-normalized - delocalization it is possible that the composition increases - towards the edge of the dataset because the quotient of two numbers - which are both smaller than one is larger instead of smaller than - the counter. By default, the tool uses a modified marching cubes - algorithm of Lewiner et al. which detects if voxels face such a - situation. In this case, no triangles are generated for such voxels. - Alternatively, (via setting keep_edge_triangles) the user can - instruct the tool to not remove these triangles at the cost of bias. - - Specifically, in this case the user should understand that all - objects/microstructural features in contact with the edge of the - dataset get usually artificial enlarged and their surface mesh - often closed during the marching. This closure however is artificial! - It can result in biased shape analyses for those objects. - The reason why this should in general be avoided is a similar - argument as when one analyzes grain shapes in orientation microscopy - via e.g. SEM/EBSD. Namely, these grains, here the objects at the - edge of the dataset, were not fully captured during e.g. limited - field of view. - Therefore, it is questionable if one would like to make - substantiated quantitative statements about them. - - Thanks to collaboration with the V. V. Rielli and S. Primig, though, - paraprobe-nanochem implements a complete pipeline to - process even these objects at the edge of the dataset. Specifically, - the objects are replaced by so-called proxies, i.e. replacement - objects whose holes on the surface mesh have been closed if possible - via iterative mesh and hole-filling procedures with fairing operations. - In the results of each paraprobe-nanochem run, these proxy objects - are listed separately to allow users to quantify and analyze in - detail the differences when accounting for these objects or not. - Especially this is relevant in atom probe microscopy as objects - can contain a few dozen atoms only. - Users should be aware that results from fairing operations should - be compared to results from analyses where all objects at the edge - of the dataset have been removed. - - Also users should be careful with overestimating the statistical - significance of their dataset especially when using atom probe - to compare multiple descriptors: Even though a dataset may give - statistically significant results for compositions, this does not - necessarily mean it will yield also statistically significant - and unbiased results for three-dimensional object analyses. - Being able to quantify these effects and making atom probers - aware of these subtleties was one of the main reasons why the - paraprobe-nanochem tool was implemented. - - - - - - - - - The ion-to-edge-distance that is used in the analyses of objects - (and proxies) to identify whether these are inside the dataset or - close to the edge of the dataset. If an object has at least one ion - with an ion-to-edge-distance below this threshold, the object is - considered as one which lies close to the edge of the dataset. - This implements essentially a distance-based approach to solve - the in general complicated and involved treatment of computing - volumetric intersections between not-necessarily convex - closed 2-manifolds. In fact, such computational geometry analyses - can face numerical robustness issues as a consequence of which a - mesh can be detected as lying completely inside a dataset although - in reality it is epsilon-close only, i.e. almost touching only - the edge (e.g. from inside). - Practically, humans would state in such case that the object is - close to the edge of the dataset; however mathematically the object - is indeed completely inside. - In short, a distance-based approach is rigorous and more flexible. - - - - - - Array of iso-contour values. For each value the tool computes - an iso-surface and performs subsequent analyses. - The unit depends on the choice for the normalization of the - accumulated ion intensity values per voxel: - - * total, total number of ions, irrespective their iontype - * candidates, total number of ions with type in the isotope_whitelist. - * composition, candidates but normalized by composition, i.e. at.-% - * concentration, candidates but normalized by voxel volume, i.e. ions/nm^3 - - - - - - Specifies if the tool should report the triangle soup which represents - each triangle of the iso-surface complex. - Each triangle is reported with an ID specifying to which triangle - cluster (with IDs starting at zero) the triangle belongs. - The clustering is performed with a modified DBScan algorithm. - - - - - Specifies if the tool should analyze for each cluster of triangles - how they can be combinatorially processed to describe a closed - polyhedron. Such a closed polyhedron (not-necessarily convex!) - can be used to describe objects with relevance in the microstructure. - Users should be aware that the resulting mesh does not necessarily - represent the original precipitate. In fact, inaccuracies in the - reconstructed positions cause inaccuracies in all downstream - processing operations. Especially the effect on one-dimensional - spatial statistics like nearest neighbor correlation functions these - effects were discussed in the literature - `B. Gault et al. <https://doi.org/10.1017/S1431927621012952>`_ - In continuation of these thoughts this applies also to reconstructed - objects. A well-known example is the discussion of shape deviations - of Al3Sc precipitates in aluminium alloys which in reconstructions - can appear as ellipsoids although they should be almost spherical, - depending on their size. - - - - - Specifies if the tool should report a triangulated surface mesh - for each identified closed polyhedron. It is common that a - marching cubes algorithm creates iso-surfaces with a fraction of very - small sub-complexes (e.g. small isolated tetrahedra). - - These can be for instance be small tetrahedra/polyhedra about the - center of a voxel of the support grid on which marching cubes operates. - When these objects are small, it is possible that they contain no ion; - especially when considering that delocalization procedures smoothen - the positions of the ions. Although these small objects are interesting - from a numerical point of view, scientists may argue they are not worth - to be reported: - Physically a microstructural feature should contain at least a few - atoms to become relevant. Therefore, paraprobe-nanochem by default - does not report closed objects which bound not at least one ion. - - - - - Specifies if the tool should report properties of each closed - polyhedron, such as volume and other details. - - - - - Specifies if the tool should report for each closed polyhedron an - approximately optimal bounding box fitted to all triangles of the - surface mesh of the object and ion positions inside or on the - surface of the mesh. - This bounding box informs about the closed object's shape - (aspect ratios). - - - - - - Specifies if the tool should report for each closed polyhedron - all evaporation IDs of those ions which lie inside or on the - boundary of the polyhedron. This information can be used e.g. - in the paraprobe-intersector tool to infer if two objects share - common ions, which can be interpreted as an argument to assume - that the two objects intersect. - - Users should be aware that two arbitrarily closed polyhedra - in three-dimensional space can intersect but not share a common ion. - In fact, the volume bounded by the polyhedron has sharp edges. - When taking two objects, an edge of one object may for instance - pierce into the surface of another object. In this case the - objects partially overlap / intersect volumetrically; - however this piercing might be so small or happening in the volume - between two ion positions and thus sharing ions is a sufficient - but not a necessary condition for object intersections. - - Paraprobe-intersector implements a rigorous alternative to handle - such intersections using a tetrahedralization of closed objects. - However, in many practical cases, we found through examples that there - are polyhedra (especially when they are non-convex and have almost - point-like) connected channels, where tetrahedralization libraries - have challenges dealing with. In this case checking intersections - via shared_ions is a more practical alternative. - - - - - Specifies if the tool should report if a (closed) object has - contact with the edge of the dataset. For this the tool currently - inspects if the shortest distance between the set of triangles of the - surface mesh and the triangles of the edge model is larger than the - edge_threshold. If this is the case, the object is assumed to be - deeply embedded in the interior of the dataset. Otherwise, the object - is considered to have an edge contact, i.e. it is likely affected - by the fact that the dataset is finite. - - - - - - Specifies if the tool should analyze a doppelganger/proxy mesh for - each cluster of triangles whose combinatorial analysis according - to has_object showed that the object is not a closed polyhedron. - Such proxies are closed via iterative hole-filling, mesh refinement, - and fairing operations. - Users should be aware that the resulting mesh does not necessarily - represent the original precipitate. In most cases objects, - like precipitates in atom probe end up as open objects because - they have been clipped by the edge of the dataset. Using a proxy is - then a strategy to still be able to account for these objects. - Nevertheless users should make themselves familiar with the - potential consequences and biases which this can introduce - into the analysis. - - - - - Like has_object_geometry but for the proxies. - - - - - Like has_object_properties but for the proxies. - - - - - Like has_object_obb but for the proxies. - - - - - Like has_object_ions but for the proxies. - - - - - Like has_object_edge_contact but for the proxies. - - - - - Specifies if the tool should report for each closed object a - (cylindrical) region of interest placed, centered, and align - with the local normal for each triangle of the object. - - - - - Specifies if the tool should report for each ROI that was placed - at a triangle of each object if this ROI intersects the edge of - the dataset. Currently paraprobe-nanochem supports cylindrical - ROIs. A possible intersection of these with the edge of the - dataset, i.e. the triangulated surface mesh model for the edge - is performed. This test checks if the cylinder intersects with - a triangle of the surface mesh. If this is the case, the ROI is - assumed to make edge contact, else, the ROI is assumed to have - no edge contact. - - This approach does not work if the ROI would be completely - outside the dataset. Also in this case there would be - no intersection. For atom probe this case is practically - irrelevant because for such a ROI there would also be no ion - laying inside the ROI. Clearly it has thus to be assumed that - the edge model culls the entire dataset. Instead, if one would - cut a portion of the dataset, compute an edge model for this - point cloud, it might make sense to place a ROI but in this - case the edge contact detection is not expected to work properly. - - - - - - - Analyses of interfacial excess. - - - - Interfacial excess computations are performed for local regions-of-interests - (ROIs) at selected facets or interface patch. - For instance many scientist compute the interfacial excess for - selected triangle facets of a created iso-surface. In this case, - computed iso-surfaces of paraprobe could be used. An example are triangle - facet sets about closed polyhedra, for instance to compute interfacial - excess related to phase boundaries of second-phase precipitates. - - Another example are free-standing triangle patches of the iso- - surfaces which paraprobe creates. These could be characterized - for interfacial excess. The sub-routines during iso-surface - computations already include a procedure to automatically align - local triangle normals based on the gradients of e.g. composition - fields. In this case, these triangulated surface patches - could also be used as a source for computing interfacial - excess. - - Often scientists face situations, though, in which there is no - immediately evident composition gradient across the interface - (grain or phase boundary) and orientation information about the - adjoining crystal is neither available nor reliable enough. - - In this case `P. Felfer et al. <https://doi.org/10.1016/j.ultramic.2015.06.002>`_ proposed a method - to manually place control points and run an automated tessellation-based - algorithm to create a triangulated surface patch, i.e. a model of the - location of the interface. In a post-processing step this triangle - set can then be used to compute again interfacial excess in an - automated manner by placing ROIs and aligning them with - consistently precomputed triangle normals. - - A similar use case is conceptually the one proposed by `X. Zhou et al. <https://doi.org/10.1016/j.actamat.2022.117633>`_ - They used first a deep-learning method to locate planar triangulated - grain boundary patches. These are eventually processed further - with manual editing of the mesh via tools like Blender. - Once the user is satisfied with the mesh, the computations of interfacial - excess reduce again to an automated placing of ROIs, computations - of the distributing of ions to respective ROIs and - reporting the findings via plotting. - - Yet another approach for constructing an triangulated surface patch - of an interface is to use point cloud processing methods which have - been proposed in the laser-scanning, geoinformatics, and CAD community. - Different computational geometry methods are available for fitting - a parameterized surface to a set of points, using e.g. non-uniform - rational B-splines (NURBS) and triangulating these according - to prescribed mesh quality demands. - - The advantage of these methods is that they can be automated and - pick up curved interface segments. The disadvantage is their often - strong sensitivity to parameterization. As a result also such methods - can be post-processed to yield a triangulated surface patch, - and thus enable to run again automated ROI placement methods. - For example like these which were explored for the use case of - iso-surfaces with closed objects and free-standing - surface patches that delineate regions of the dataset with a - pronounced composition gradient normal to the interface. - - This summary of the situations which atom probers can face when - requesting for interfacial excess computations, substantiates there - exists a common set of settings which can describe all of these methods - and, specifically, as here exemplified, the automated placing - and alignment functionalities for ROIs that is an important - step all these workflows. - - Specifically, paraprobe-nanochem operates on an already existent - triangle set. - - - - - - - - - - The interface model is the result of a previous (set of) processing - steps as a result of which the user has created a triangulated - surface mesh (or a set of, eventually connected such meshes). - These interface models are useful, if not required, in cases when - there is no other independent approach to locate an interface. - - These are cases when insufficient crystallographic latent - information is available and also no consistent concentration - gradient detectable across the interface. It is then the users' - responsibility to deliver a triangle mesh of the interface model. - - - - Filename to HDF5 file which contain vertex coordinates, facet indices, - facet unit normals. The user is responsible for the triangle - and winding order to be consistent. - Input is expected as a matrix of the coordinates for all disjoint - vertices, a (Nvertices, 3)-shaped array of NX_FLOAT. - Input is expected to include also a matrix of facet indices - referring to these disjoint vertices. This matrix should be a - (Nfacets, 3)-shaped array of NX_UINT. Further required input - is a (Nfacets, 3)-shaped array of NX_FLOAT signed facet unit - normals and a (Nvertices, 3)-shaped array of NX_FLOAT signed - vertex unit normals. Vertex indices need to start at zero and - must not exceed Nvertices - 1, i.e. the identifier_offset is 0 - and facet indices are indexed implicitly, i.e. [0, Nvertices-1]. - - - - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional - layer of reproducibility from which file specifically - contains these data. - - - - - - Absolute HDF5 path to the dataset which specifies the - array of vertex positions. - - - - - Absolute HDF5 path to the dataset which specifies the - array of facet indices. - - - - - Absolute HDF5 path to the dataset which specifies the - array of facet signed unit normals. - - - - - Absolute HDF5 path to the dataset which specifies the - array of vertex signed unit normals. - - Users should be aware that triangulated surface meshes are - only approximations to a given complex, eventually curved shape. - Consequently, computations of normals show differences between - the vertex and facet normals. Vertex normals have to be - interpolated from normals of neighboring facets. Consequently, - these normals are affected by the underlying parameterization - and curvature estimation algorithms, irrespective of how - contributions from neighboring facets are weighted. By contrast, - facet normals are clearly defined by the associated triangle. - Their disadvantage is that they the normal field has discontinuities - at the edges. In general the coarser an object is triangulated - the more significant the difference becomes between computations - based on facet or vertex normals. - Paraprobe-nanochem works with facet normals as it can use - parts of the numerical performance gained by using cutting - edge libraries to work rather with finer meshes. - - - - - - - - Create a simple principle component analysis (PCA) to mesh a - free-standing interface patch through a point cloud of decorating solutes. - These models can be useful for quantification of Gibbsian - interfacial excess for interfaces where iso-surface based methods - may fail or closed objects from iso-surfaces are not desired or - when e.g. there are no substantial or consistently oriented - concentration gradients across the interface patch. - - The interface_meshing functionality of paraprobe-nanochem can be useful - when there is also insufficient latent crystallographic information - available that could otherwise support modelling the interface, - via e.g. ion density traces in field-desorption maps, as were used and - discussed by `Y. Wei et al. <https://doi.org/10.1371/journal.pone.0225041>`_ - or are discussed by `A. Breen et al. <https://github.com/breen-aj/detector>`_ - - It is noteworthy that the method here used is conceptually very similar - in implementation to the work by `Z. Peng et al. <https://doi.org/10.1017/S1431927618016112>`_ - Noteworthy, her team uses the DCOM approach originally proposed by P. Felfer et al. - However, both of these previous works neither discuss in detail - nor implement inspection functionalities which enable a detection of - potential geometric inconsistencies or self-interactions of the - resulting DCOM mesh. This is what paraprobe-nanochem implements - via the Computational Geometry Algorithms Library. - - - - Method how to initialize the PCA: - - * default, means based on segregated solutes in the ROI - * control_point_file, means based on reading an external list of - control points, currently coming from the Leoben APT_Analyzer. - - The control_point_file is currently expected with a specific format. - The Leoben group lead by L. Romaner has developed a GUI tool `A. Reichmann et al. <https://github.com/areichm/APT_analyzer>`_ - to create a control_point_file which can be parsed by paraprobe-parmsetup - to match the here required formatting in control_points. - - - - - - - - - The name of the control point file to use. - - - - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional - layer of reproducibility from which file specifically - contains these data. - - - - - - X, Y, Z coordinates of disjoint control point read from - an HDF5 file named according to control_point_file. - - - - - - - - - - Method used for identifying and refining the location of the - interface. Currently, paraprobe-nanochem implements a PCA followed - by an iterative loop of isotropic mesh refinement and DCOM step(s), - paired with self-intersection detection in a more robust - implementation. - - - - - - - - Specify the types of those ions which decorate the interface and - can thus be assumed as markers for locating the interface and - refining its local curvature. - - - - Array of iontypes to filter. The list is interpreted as a whitelist, - i.e. ions of these types are considered the decorating species (solutes). - - - - - - - - - How many times should the DCOM and mesh refinement be applied? - - - - - Array of decreasing positive not smaller than one nanometer real values - which specify how the initial triangles of the mesh should be iteratively - refined by edge splitting and related mesh refinement operations. - - - - - - - - - Array of decreasing positive not smaller than one nanometer real values - which specify the radius of the spherical region of interest within - which the DCOM algorithm decides for each vertex how the vertex will - be eventually relocated. The larger the DCOM radius is relative to - the target_edge_length the more likely it is that vertices will be - relocated so substantially that eventually triangle self-intersections - can occur. If the code detects these it warns and stops in a - controlled manner so that the user can repeat the analyses - with a smaller value. - - - - - - - - - Array of integers which specify for each DCOM step how many times - the mesh should be iteratively smoothened. - - Users should be aware the three array target_edge_length, - target_dcom_radius, and target_smoothing_step are interpreted in the - same sequence, i.e. the zeroth entry of each array specifies the - values to be used in the first DCOM iteration. The first entry of - each array those for the second DCOM iteration and so on and so forth. - - - - - - - - - Functionalities for placing regions-of-interest (ROIs) in the dataset - or at specific microstructural features to characterize composition - profiles and cumulated profiles for quantification of interfacial excess. - Paraprobe-nanochem currently places cylindrical ROIs. ROIs are probed - across the triangulated surface of a user-defined mesh. - ROIs are placed at the barycenter of the triangular facet. - - The tool can be instructed to orient the profile for each ROIs with - the positive normal of the triangle facet normals. Profiles are - computed for each ROI and facet triangle. The code will test which - ROIs are completely embedded in the dataset. - Specifically, in this test the tool evaluates if the ROI cuts at least - one triangle of the triangulated surface mesh of the edge of the dataset. - If this is the case the ROI will be considered close to the edge - (of the dataset) and not analyzed further; else the ROI will be - processed further. - Users should be aware that the latter intersection analysis is strictly - speaking not a volumetric intersection analysis as such one is much - more involved because the edge model can be a closed non-convex polyhedron - in which case one would have to test robustly if the cylinder pierces - or is laying completely inside the polyhedron. For this the polyhedron has - to be tessellated into convex polyhedra as otherwise tests like the - Gilbert-Johnson-Keerthi algorithm would not be applicable. - - Specifically, the tool computes atomically decomposed profiles. - This means molecular ions are split into atoms/isotopes with respective - multiplicity. As an example an H3O+ molecular ion contains three - hydrogen and one oxygen atom respectively. The tool then evaluates - how many ions are located inside the ROI or on the surface of the - ROI respectively. All atom types and the unranged ions are distinguished. - As a result, the analyses yield for each ROI a set of sorted lists of - signed distance values. Currently, the distance is the projected - distance of the ion position to the barycenter of the triangle - and triangle plane. - - This will return a one-dimensional profile. Post-processing the set - of atom-type-specific profiles into cumulated profiles enable the - classical Krakauer/Seidman-style interfacial excess analyses. - Furthermore, the tool can be instructed to compute for each - (or a selected sub-set of facet) a set of differently oriented profiles. - - - - - The feature mesh enables the injection of previously computed triangle - soup or mesh data. Such a mesh can be the model for a grain- or phase - boundary patch (from e.g. interface_meshing) jobs. - - - - Name of the HDF5 file which contains vertex coordinates and facet - indices to describe the desired set of triangles which represents - the feature. - - - - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - - - - - - Absolute path to the HDF5 dataset in the respectively specified HDF5 - file under filename which details the array of vertex positions. - - - - - Absolute path to the HDF5 dataset in the respective specified HDF5 - file under filename which details the array of facet indices. - - - - - Absolute path to the HDF5 dataset in the respective specified HDF5 - file under filename which details consistently oriented facet - normals of the facets. - - - - - - - - - - - The tool enables to inject precomputed distance information for each - point which can be used for further post-processing and analysis. - - - - - Name of an HDF5 file which contains ion distances. - - - - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional - layer of reproducibility from which file specifically contains - these data. - - - - - - Absolute HDF5 path to the dataset with distance values for each ion. - - - - - - Which type of distance should be reported for the profile. - - - - - - - - - In which directions should the tool probe for each ROI. - - - - - - - - - For each ROI, how high (projected on the cylinder axis) - should the cylindrical ROI be. - - - - - - For each ROI, how wide (radius) should the cylindrical ROI be. - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml deleted file mode 100644 index 7fd4937625..0000000000 --- a/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml +++ /dev/null @@ -1,297 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The number of isotopes to consider as building blocks for searching molecular - ions. - - - - - The number of compositions to consider for molecular ion search tasks. - - - - - Configuration of a paraprobe-ranger tool run in atom probe microscopy. - - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - How many task to perform? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A list of pairs of number of protons and either the value 0 (per row) - or the mass number for all those isotopes which are assumed present - in a virtual specimen. - The purpose of this field is to compute also composition-weighted - products to yield a simple estimation which could potentially help - scientists to judge if certain molecular ions are to be expected. - The corresponding setting store_composition_weighted_product should be - activated. - - - - - - - - - - A list of pairs of number of protons and mass number for all isotopes - to consider that can be composed into (molecular) ions, during the - recursive molecular_ion_search. - - - - - - - - - The mass-to-charge-state ratio interval in which - all molecular ions are searched. - - - - - - - - The maximum charge that a molecular ion should have. - - - - - The maximum number of isotopes of which the molecular ion - should be composed. Currently this must not be larger than 32. - - Users should be warned that the larger the maximum_charge and - especially the larger the maximum_number_of_isotopes is chosen, - the eventually orders of magnitude more costly the search becomes. - - This is because paraprobe-ranger computes really all (at least) - theoretically possible combinations that would have likely a - mass-to-charge-state ratio in the specified mass_to_charge_interval. - It is the challenge in atom probe to judge which of these (molecular) - ions are feasible and also practically possible. This tool does not - answer this question. - - Namely, which specific molecular ion will evaporate, remain stable - during flight and becomes detected is a complicated and in many cases - not yet in detail understood phenomenon. The ab-initio conditions - before and during launch, the local environment, arrangement and field - as well as the flight phase in an evacuated but not analysis chamber - with a complex electrical field, eventual laser pulsing in place, - temperature and remaining atoms or molecules all can have an effect - which iontypes are really physically evaporating and detected. - - - - - Report the accumulated atomic mass from each isotope building the ion. - Accounts for each identified ion. - Relatistic effects are not accounted for. - - - - - Report the product of the natural abundances from each isotope building - the ion. Accounts for each identified ion. - - The value zero indicates it is not possible to build such molecular ion - from nuclids which are all observationally stable. - Very small values can give an idea/about how likely such a molecular ion - is expected to form assuming equal probabilities. - - However in atom probe experiments this product has to be modified - by the (spatially-correlated) local composition in the region from - which the ions launch because the formation of a molecular ion depends - as summarized under maximum_number_of_isotopes on the specific - quantum-mechanical configuration and field state upon launch - or/and (early state) of flight respectively. - We are aware that this modified product can have a substantially - different value than the natural_abundance_product. - - Natural abundancies folded with the estimated compositions of the - specimen can differ by orders of magnitude. - - - - - - Report the charge state of the ions. - - - - - Report if identified ions should be characterized - wrt to their number of disjoint isotopes. - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_config_selector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_selector.nxdl.xml deleted file mode 100644 index cdaa32bb64..0000000000 --- a/contributed_definitions/NXapm_paraprobe_config_selector.nxdl.xml +++ /dev/null @@ -1,142 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Configuration of a paraprobe-selector tool run in atom probe microscopy. - - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - How many roi_selection processes should the tool execute. - - - - - This process identifies which of the points/ions in the datasets are - inside or on the surface of geometric primitives and meet optionally - specific other filtering constraints. - A typical use case of a roi_selection is to restrict analyses to - specific regions of the dataset, eventually regions with a complicated - shape. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml deleted file mode 100644 index 81c175e434..0000000000 --- a/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml +++ /dev/null @@ -1,374 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Maximum number of atoms per molecular ion. Should be 32 for paraprobe. - - - - - Number of different sources iontypes to distinguish. - - - - - Number of different target iontypes to distinguish. - - - - - Configuration of a paraprobe-spatstat tool run in atom probe microscopy. - - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - How many range_with_existent_iontypes processes should - the tool execute as part of the analysis. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The tool enables to inject precomputed distances of each ion to a - representation of the edge of the dataset which can be used to - control and substantially reduce edge effects when computing - spatial statistics. - - - - Name of an HDF5 file which contains ion-to-edge distances. - - - - - Absolute HDF5 path to the dataset with the - ion-to-edge distance values for each ion. - The shape of the distance values has to match the length - of the ion positions array in dataset/dataset_name_reconstruction - and dataset_name_mass_to_charge respectively. - - - - - Threshold to define how large an ion has to lay at least far away - from the edge of the dataset so that the ion can act as a source, - i.e. that an ROI is placed at the location of the ion and its - neighbors are analyzed how they contribute to the computed statistics. - - The ion_to_edge_distances threshold can be combined with a threshold - for the ion_to_feature_distances. - Specifically, if ion_to_feature_distances are loaded an ion only - acts as a source if both threshold criteria are met. - - The threshold is useful to process the dataset such that ROIs do - not protrude out of the dataset as this would add bias. - - - - - - In addition to spatial filtering, and considering how far ions lie - to the edge of the dataset, it is possible to restrict the analyses - to a sub-set of ions within a distance not farther away to a feature than - a threshold value. - - - - Name of an HDF5 file which contains ion-to-feature distances. - - - - - Absolute HDF5 path to the dataset with the - ion-to-feature distance values for each ion. - - - - - Threshold to define how close an ion has to lay to a feature so that - the ion can at all qualify as a source, i.e. that an ROI is placed - at the location of the ion and its neighbors are then analyzed - how they contribute to the computed statistics. - - Recall that the ion_to_feature_distances threshold is combined - with the ion_to_edge_distances threshold. - - - - - - - Specifies if the iontypes are randomized for the point cloud or not. - Internally paraprobe uses a sequentially executed deterministic MT19987 - (MersenneTwister) pseudo-random number generator to shuffle the - iontype labels randomly across the entire set of ions. - - - - - - - - - - How should the iontype be interpreted on the source-side, i.e. - all these ion positions where a regions-of-interest (ROI) around - so-called source ions will be placed. Different options exist - how iontypes are interpreted given an iontype represents - in general a (molecular) ion with different isotopes that have - individually different multiplicity. - - The value resolve_all will set an ion active in the analysis regardless - of which iontype it is. Each active ion is accounted for once. - - The value resolve_unknown will set an ion active when the ion is - of the UNKNOWNTYPE type. Each active ion is accounted for once. - - The value resolve_ion will set an ion active if it is of the specific - iontype, irregardless of its elemental or isotopic details. - Each active ion is counted once. - - The value resolve_element will set an ion active, and most importantly, - account for each as many times as the (molecular) ion contains - atoms of elements in the whitelist ion_query_isotope_vector. - - The value resolve_isotope will set an ion active, and most importantly, - account for each as many times as the (molecular) ion contains - isotopes in the whitelist ion_query_isotope_vector. - - In effect, ion_query_isotope_vector acts as a whitelist to filter - which ions are considered as source ions of the correlation statistics - and how the multiplicity of each ion will be factorized, i.e. how - often it is accounted for. - - - - - - - - - - - - Matrix of isotope vectors, as many as rows as different candidates - for iontypes should be distinguished as possible source iontypes. - In the simplest case, the matrix contains only the proton number - of the element in the row, all other values set to zero. - Combined with ion_query_type_source set to resolve_element this will - recover usual spatial correlation statistics like the 1NN C-C - spatial statistics. - - - - - - - - - Similarly as ion_query_type_source how should iontypes be interpreted - on the target-side, i.e. how many counts will be bookkept for ions - which are neighbors of source ions within or on the surface of each - inspection/ROI about each source ion. - Source ion in the center of the ROI are not accounted for during - counting the summary statistics. - For details about the resolve values consider the explanations in - ion_query_type_source. These account for ion_query_type_target as well. - - - - - - - - - - - - - Matrix of isotope vectors, as many as rows as different candidates for - iontypes to distinguish as possible targets. See additional comments - under ion_query_isotope_vector_source. - - - - - - - - - Specifies which spatial statistics to compute. - - - - Compute k-th nearest neighbour statistics. - - - - Order k. - - - - - Minimum value, increment, and maximum value of the histogram binning. - - - - - - - - - - Compute radial distribution function. - - - - Minimum value, increment, and maximum value of the histogram binning. - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml deleted file mode 100644 index 8427d9bb1a..0000000000 --- a/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml +++ /dev/null @@ -1,289 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of alpha values (and offset values) to probe. - - - - - How many different match values does the filter specify. - - - - - Configuration of a paraprobe-surfacer tool run in atom probe microscopy. - - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - For now a support field for the tool to identify how many individual - analyses the tool should executed as part of the analysis. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specifies the method that is used to preprocess the point cloud. - The main purpose of this setting is to specify whether the point - cloud should be segmented or not during the preprocessing - to identify which points are more likely lying close to the edge - of the point cloud. These points could be more relevant than the - interior points for certain alpha-shape constructions. - - By default no such filtering is used during pre-processing. - By contrast, the option kuehbach activates a preprocessing - during which a Hoshen-Kopelman percolation analysis is used - to identify which points are closer to the edge of the dataset. - This can reduce the number of points in the alpha-shape - computation and thus improve performance substantially. - Details about the methods are reported in - `M. Kühbach et al. <https://doi.org/10.1038/s41524-020-00486-1>`_. - - - - - - - - - - When using the kuehbach preprocessing, this is the width of the - kernel for identifying which ions are in voxels close to the - edge of the point cloud. - - - - - Specifies which method to use to define the alpha value. - The value convex_hull_naive is the default. This instructs the tool - to use a fast specialized algorithm for computing only the convex - hull. The resulting triangles can be skinny. - - The value convex_hull_refine computes first also a convex_hull_naive - but refines the mesh by triangle flipping and splitting to improve - the quality of the mesh. - - The value smallest_solid instructs the CGAL library to choose a - value which realizes an alpha-shape that is the smallest solid. - - The value cgal_optimal instructs the library to choose a value - which the library considers as an optimal value. Details are - define in the respective section of the CGAL library on 3D alpha - shapes. - - The value set_of_values instructs to compute a list of - alpha-shapes for the specified alpha-values. - - The value set_of_alpha_wrappings instructs the library to generate - a set of so-called alpha wrappings. These are a method - which is similar to alpha shapes but provide additional guarantees - though such as watertightness and proximity constraints on the - resulting wrapping. - - - - - - - - - - - - - - Array of alpha values to use when alpha_value_choice is set_of_values - or when alpha_value_choice is set_of_alpha_wrappings. - - - - - - - - - Array of offset values to use when alpha_value_choice is - set_of_alpha_wrappings. The array of alpha_values and offset_values - define a sequence of (alpha and offset value). - - - - - - - - - Specifies if the tool should compute the set of exterior triangle - facets for each alpha complex (for convex hull, alpha shapes, and wrappings) - - - - - Specifies if the tool should check if the alpha complex of exterior - triangular facets is a closed polyhedron. - - - - - Specifies if the tool should compute all interior tetrahedra - of the alpha complex (currently only for alpha shapes). - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml deleted file mode 100644 index e963465431..0000000000 --- a/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml +++ /dev/null @@ -1,253 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Configuration of a paraprobe-tessellator tool run in atom probe microscopy. - - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - How many individual analyses should the tool execute. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The tool enables to inject precomputed distance information for - each point which can be used for further post-processing and analysis. - - - - Name of an HDF5 file which contains the ion distances. - Users are responsible this file and referred to dataset under - dataset_name have an ion_distance value for each ion. - - - - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional layer of - reproducibility. - - - - - - Absolute HDF5 path to the dataset with distance values for each ion. - - - - - - - Specifies for which points the tool will compute the tessellation. - By default, a Voronoi tessellation is computed for all ions in the - filtered point cloud. - - - - - - - - - - Specifies if the tool should report the volume of each cell. - - - - - Specifies if the tool should report the first-order neighbors of each cell. - - - - - Specifies if the tool should report the facets and vertices of each cell. - - - - - Specifies if the tool should report if the cell makes contact with - the tight axis-aligned bounding box about the point cloud. - This can be used to identify if the shape of the cell is affected - by the edge of the dataset or if cells are deeply enough embedded - into the point cloud so that the shape of their cells are not affected - by the presence of the boundary. - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml deleted file mode 100644 index 4d548e5bf7..0000000000 --- a/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml +++ /dev/null @@ -1,119 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Configurations of a paraprobe-transcoder tool run in atom probe microscopy. - - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ideally an ever persistent resource where the source code of the - program and build instructions can be found so that the program can be - configured ideally in such a manner that the result of this computational - process is recreatable deterministically. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - - - - The path and name of the file (technology partner or community format) - from which to read the reconstructed ion positions. Currently, POS, - ePOS, APT files from APSuite, and NXS, i.e. NeXus/HDF5 files - are supported. - - - - - - - - The path and name of the file (technology partner or community format - from which to read the ranging definitions, i.e. how to map mass-to- - charge-state ratios on iontypes. Currently, RRNG, RNG, and NXS, i.e. - NeXus/HDF5 files are supported. - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_results_clusterer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_clusterer.nxdl.xml deleted file mode 100644 index eb89794977..0000000000 --- a/contributed_definitions/NXapm_paraprobe_results_clusterer.nxdl.xml +++ /dev/null @@ -1,503 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of ions in the reconstruction. - - - - - The total number of entries in the restricted_identifier dictionary. - - - - - Results of a paraprobe-clusterer tool run. - - - - - - Version specifier of this application definition. - - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - - - - - The absolute path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must no longer compute analyses. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases, it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - If nothing else is specified we assume that there - has to be at least one set of NXtransformations named - paraprobe defined, which specifies the coordinate system. - In which all positions are defined. - - - - - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - - A bitmask which identifies which of the ions in the dataset were - analyzed during this process. - - - - Number of ions covered by the mask. - The mask value for most may be 0. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used, padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe-toolbox executable. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth (padding). - - - - - - - - - The result of a cluster analyses. These include typically the label for - each ion/point documenting to which feature (if any) an ion is assigned. - Typically, each analysis/run yields only a single cluster. - In cases of fuzzy clustering it can be possible that an ion is assigned - to multiple cluster (eventually with different) weight/probability. - - - - Results of a DBScan clustering analysis. - - - - The epsilon (eps) parameter. - - - - - The minimum points (min_pts) parameter. - - - - - Number of members in the set which is partitioned into features. - Specifically, this is the total number of targets filtered from the - dataset. Cardinality here is not the total number of ions in the - dataset. - - - - - - Which identifier is the first to be used to label a cluster. - - The value should be chosen in such a way that special values can be resolved: - * identifier_offset-1 indicates an object belongs to no cluster. - * identifier_offset-2 indicates an object belongs to the noise category. - Setting for instance identifier_offset to 1 recovers the commonly used - case that objects of the noise category get values to -1 and unassigned points to 0. - Numerical identifier have to be strictly increasing. - - - - - - The evaporation sequence identifier to figure out which ions - from the reconstruction were considered targets. - - - - - - - - - The raw labels from the DBScan clustering backend process. - - - - - - - - The raw array of core sample indices which specify which of the - targets are core points. - - - - - - - - - Matrix of numerical label for each member in the set. - For classical clustering algorithms this can for instance - encode the cluster_identifier. - - - - - - - - - The array of weight which specifies how surely/likely the - cluster is associated/assigned to a specific identifier as - is specified in the cluster_identifier array. - For the DBScan and atom probe tomography the multiplicity - of each ion with respect to the cluster. That is how many times - should the position of the ion be accounted for because the ion - is e.g. a molecular ion with several elements or isotope of - requested type. - - - - - - - - Optional bitmask encoding if members of the set are assigned to as noise or not. - - - - - - - - Optional bitmask encoding if member of the set are a core point. - For details to which feature/cluster an ion/point is a core point - consider numerical_label. - - - - - - - - In addition to the detailed storage which members was grouped to - which feature/group summary statistics are stored under this group. - - - - - Total number of members in the set which are categorized as noise. - - - - - - Total number of members in the set which are categorized as a core point. - - - - - - Total number of clusters (excluding noise and unassigned). - - - - - Array of numerical identifier of each feature (cluster). - - - - - - - - Array of number of members for each feature. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml deleted file mode 100644 index 54ad4dccaf..0000000000 --- a/contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml +++ /dev/null @@ -1,388 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of ions in the reconstruction. - - - - - The total number of triangles in the set. - - - - - Results of a paraprobe-distancer tool run. - - - - - - Version specifier of this application definition. - - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - - - - - The absolute path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - - - - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - - The tool can be used to compute the analytical distance of each ion - to a set of triangles. - - - - A bitmask which identifies which of the ions in the dataset were - analyzed. - - - - Number of ions covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - A bitmask which identifies which of the triangles in the set - were considered. Usually these are all but sometimes users may - wish to filter certain portions of the triangles out. - If window_triangles is not provided it means that - all triangles were taken. - - - - Number of triangles covered by the mask. - The mask value for most may be 0. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - The closest analytical distance of the ions to their respectively - closest triangle from the triangle set. - - - - - - - - A bitmask which identifies which of the distance values - can be assumed to have a consistent sign because the closest - triangle had a consistent outer unit normal defined. - For points whose bit is set 0 the distance is correct but the - sign is not reliable. - - - - Number of triangles covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. - - - - - - - - - The identifier of the triangle that is closest for each ion. - - - - - - - - A support field to visualize each ion and with this the distance - informations using XDMF and e.g. Paraview. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_results_intersector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_intersector.nxdl.xml deleted file mode 100644 index 1c60505c7e..0000000000 --- a/contributed_definitions/NXapm_paraprobe_results_intersector.nxdl.xml +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of links pointing from current to next. - - - - - The total number of links pointing from next to current. - - - - - The total number of members in the current_set. - - - - - The total number of members in the next_set. - - - - - The total number of cluster found for coprecipitation analysis. - - - - - The number of rows in the table/matrix for coprecipitation stats. - - - - - Results of a paraprobe-intersector tool run. - - - - - - Version specifier of this application definition. - - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - - - - - The absolute path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - - - - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - - The results of an overlap/intersection analysis. - - - - A matrix of feature_identifier which specifies which named features - from the current set have directed link(s) pointing to which named - feature(s) from the next set. - - - - - - - - - For each link/pair in current_to_next a characterization - whether the link is due to a volumetric overlap (0x00 == 0), - proximity (0x01 == 1), or something else unknown (0xFF == 255). - - - - - - - - A matrix of feature_identifier which specifies which named feature(s) - from the next set have directed link(s) pointing to which named - feature(s) from the current set. Only if the mapping whereby the - links is symmetric next_to_current maps the links in current_to_next - in the opposite direction. - - - - - - - - - For each link/pair in next_to_current a characterization - whether the link is due to a volumetric overlap (0x00 == 0), - proximity (0x01 == 1), or something else unknown (0xFF == 255). - - - - - - - - For each pair of links in current_to_next the volume of the - intersection, i.e. how much volume do the two features share. - If features do not intersect the volume is zero. - - - - - - - - During coprecipitation analysis the current and next set are analyzed - for links in a special way. Three set comparisons are made. Members - of the set in each comparison are analyzed for overlap and proximity: - - The first comparison is the current_set against the current_set. - The second comparison is the next_set against the next_set. - The third comparison is the current_set against the next_set. - - Once the (forward) links for these comparisons are ready the - pair relations are analyzed with respect to which feature identifier - cluster in identifier space. Thereby a logical connection (link) is - established between the features in the current_set and next_set. - Recall that these two set typically represent different features - within an observed system for otherwise the same parameterization. - Examples include two sets of e.g. precipitates with differing - chemical composition that were characterized in the same material - volume representing a snapshot of an e.g. microstructure at the same - point in time. Researchers may have performed two analyses, one to - characterize precipitates A and another one to characterize percipitates - B. Coprecipitation analysis now logically connects these independent - characterization results to establish spatial correlations of e.g. - precipitates spatial arrangement. - - - - Matrix of feature_identifier and cluster_identifier pairs which - encodes the cluster to which each feature_identifier was assigned. - Here for features of the current_set. - - - - - - - - - Matrix of feature_identifier and cluster_identifier pairs which - encodes the cluster to which each feature_identifier was assigned. - Here for features of the next_set. - - - - - - - - - The identifier (names) of the cluster. - - - - - - - - Pivot table as a matrix. The first column encodes how many - members from the current_set are in each cluster, one row per cluster. - The second column encodes how many members from the next_set are - in each cluster, in the same row per cluster respectively. - The last column encodes the total number of members in the cluster. - - - - - - - - - Pivot table as a matrix. The first column encodes the different - types of clusters based on their number of members in the sub-graph. - The second column encodes how many clusters with as many members - exist. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml deleted file mode 100644 index ea636969ae..0000000000 --- a/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml +++ /dev/null @@ -1,1965 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of ions in the reconstruction. - - - - - The total number of atoms in the atomic_decomposition match filter. - - - - - The total number of isotopes in the isotopic_decomposition match filter. - - - - - The dimensionality of the delocalization grid. - - - - - The cardinality/total number of cells/grid points in the delocalization grid. - - - - - - The total number of XDMF values to represent all faces of triangles via XDMF. - - - - - The total number of entries in a feature dictionary. - - - - - The total number of member distinguished when reporting composition. - - - - - Results of a paraprobe-nanochem tool run. - - - - - - Version specifier of this application definition. - - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - - - - - The absolute path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must no longer compute analyses. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases, it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - If nothing else is specified we assume that there - has to be at least one set of NXtransformations named - paraprobe defined, which specifies the coordinate system. - In which all positions are defined. - - - - - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - - A bitmask which identifies which of the ions in the dataset were - analyzed during this process. - - - - Number of ions covered by the mask. - The mask value for most may be 0. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used, padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe-toolbox executable. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth (padding). - - - - - - - - - - - The weighting model specifies how mark data are mapped to a weight - per point/ion. For atom probe microscopy (APM) mark data are e.g. - which iontype an ion has. As an example, different models are used - which account differently for the multiplicity of a point/ion - during delocalization: - - * unity, all points/ions get the same weight 1. - * atomic_decomposition, points get as much weight as they - have atoms of a type in atomic_decomposition_rule, - * isotope_decomposition, points get as much weight as they have - isotopes of a type in isotopic_decomposition_rule. - - - - - - - - - - - A list of elements (via proton number) to consider for the - atomic_decomposition weighting model. - Elements must exist in the periodic table of elements and be - specified by their number of protons. - Values in match are isotope hash values using the following - hashing rule $H = Z + 256*N$ with $Z$ the number of protons - and $N$ the number of neutrons of the isotope. - In the case of elements this hashing rule has the advantage - that for elements the proton number is their hash value because - N is zero. - - - - Meaning of the filter: - Whitelist specifies which entries with said value to include. - Entries with all other values will be filtered out. - - Blacklist specifies which entries with said value to exclude. - Entries with all other values will be included. - - - - - - - - - Array of values to filter according to method. For example, - if the filter specifies [1, 5, 6] and method is whitelist, - only entries with values matching 1, 5 or 6 will be processed. - All other entries will be filtered out/not considered. - - - - - - - - - A list of isotopes (via proton and neutron number) to consider - for the isotopic_decomposition weighting model. - Isotopes must exist in the nuclid table. - Values in match are isotope hash values using the following - hashing rule $H = Z + 256*N$ with $Z$ the number of protons - and $N$ the number of neutrons of the isotope. - - - - Meaning of the filter: - Whitelist specifies which entries with said value to include. - Entries with all other values will be filtered out. - - Blacklist specifies which entries with said value to exclude. - Entries with all other values will be included. - - - - - - - - - Array of values to filter according to method. For example, - if the filter specifies [1, 5, 6] and method is whitelist, - only entries with values matching 1, 5 or 6 will be processed. - All other entries will be filtered out/not considered. - - - - - - - - - How results of the kernel-density estimation were computed - into quantities. By default the tool computes the total number - (intensity) of ions or elements. Alternatively the tool can compute - the total intensity, the composition, or the concentration of the - ions/elements specified by the white list of elements in each voxel. - - - - - - - - - - - Weighting factor, in atom probe, often termed multiplicity. - The weighting factor is the multiplier with which the integrated - intensity contribution from the point/ion gets multiplied. - The delocalization computes the integrated intensity for each - grid cell. Effectively, this is an explicitly evaluated kernel - method where each specific position of an ion is replaced by a - smoothing kernel. For atom probe weights are positive and integer - specifically the multiplicity of the ion, in accordance with the - respective rulesets as defined by weighting_model. - - - - - - - - The discretized domain/grid on which the delocalization is applied. - - - - - - - - - - - The total number of cells/voxels of the grid. - - - - - - - - - - The symmetry of the lattice defining the shape of the unit cell. - - - - - - - - The unit cell dimensions according to the coordinate system - defined under coordinate_system. - - - - - - - - Number of unit cells along each of the d unit vectors. - The total number of cells, or grid points has to be the cardinality. - If the grid has an irregular number of grid positions in each direction, - as it could be for instance the case of a grid where all grid points - outside some masking primitive are removed, this extent field should - not be used. Instead use the coordinate field. - - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - If the coordinate system is not specified the paraprobe - coordinate system is used. - - - - - - Integer which specifies the first index to be used for - distinguishing identifiers for cells. Identifiers are defined - either implicitly or explicitly. For implicit indexing the - identifiers are defined on the interval - [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - - - - A tight axis-aligned bounding box about the grid. - - - - For atom probe should be set to true. - - - - - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - - - - Positions of the vertices. - - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - - - - - - - - - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. - - - - - - - - - Six equally formatted sextets chained together. For each - sextett the first entry is an XDMF primitive topology - key (here 5 for polygon), the second entry the XDMF primitive - count value (here 4 because each face is a quad). - The remaining four values are the vertex indices. - - - - - - - - How many distinct boundaries are distinguished? - Most grids discretize a cubic or cuboidal region. In this case - six sides can be distinguished, each making an own boundary. - - - - - - Name of the boundaries. E.g. left, right, front, back, bottom, top, - The field must have as many entries as there are number_of_boundaries. - - - - - - - - The boundary conditions for each boundary: - - 0 - undefined - 1 - open - 2 - periodic - 3 - mirror - 4 - von Neumann - 5 - Dirichlet - - - - - - - - - - The result of the delocalization based on which subsequent - iso-surfaces will be computed. In commercial software so far - there is not a possibility to export such grid. - - - - - - - - - - - - - - - - - - Cell center of mass positions along x. - - - - - - - - - Cell center of mass positions along y. - - - - - - - - Cell center of mass positions along z. - - - - - - - - Intensity of the field at given point - - - - - - - - Center of mass positions of each voxel for - rendering the scalar field via XDMF in e.g. - Paraview. - - - - - - - - - XDMF topology for rendering in combination with - xdmf_xyz the scalar field via XDFM in e.g. Paraview. - - - - - - - - - The three-dimensional gradient nabla operator applied to - scalar_field_magnitude. - - - - - - - - - - - - - - - - - - - - Cell center of mass positions along x. - - - - - - - - - Cell center of mass positions along y. - - - - - - - - Cell center of mass positions along z. - - - - - - - - The gradient vector. - - - - - - - - - Center of mass positions of each voxel for - rendering the scalar field via XDMF in e.g. - Paraview. - - - - - - - - - XDMF topology for rendering in combination with - xdmf_xyz the scalar field via XDFM in e.g. Paraview. - - - - - - - - - Halfwidth of the kernel about the central voxel. - The shape of the kernel is that of a cuboid - of extent 2*kernel_extent[i] + 1 in each dimension i. - - - - - - - - - - Sigma of the kernel in each dimension in the paraprobe - coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. - - - - - - - - Expectation value of the kernel in each dimension in the paraprobe - coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. - - - - - - - - - - An iso-surface is the boundary between two regions across which - the magnitude of a scalar field falls below/exceeds a threshold - magnitude phi. - For applications in atom probe microscopy the location and shape - of such a boundary (set) is typically approximated by - discretization. - This yields a complex of not necessarily connected geometric - primitives. Paraprobe-nanochem approximates this complex with - a soup of triangles. - - - - - The threshold or iso-contour value. - - - - - Details about the specific marching cubes algorithm - which was taken to compute the iso-surface. - The grid is the delocalization grid. - - - - Reference to the specific implementation of marching cubes used. - The value placed here should be a DOI. If there are no specific - DOI or details write not_further_specified, or give at least a - free-text description. The program and version used is the - specific paraprobe-nanochem. - - - - - - The resulting triangle soup computed via marching cubes. - - - - - - Integer which specifies the first index to be used for - distinguishing triangles. Identifiers are defined either - implicitly or explicitly. For implicit indexing the - identifiers are defined on the interval - [identifier_offset, identifier_offset+c-1]. - - - - - - Number of vertices. - - - - - Number of faces. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - - - - - Positions of the vertices. - - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - - - - - - - - - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. - - - - - - - - A list of as many tuples of XDMF topology key, XDMF number - of vertices and a triple of vertex indices specifying each - triangle. The total number of entries is n_f_tri * (1+1+3). - - - - - - - - - Direction of each normal. - - - - - - - - - Qualifier how which specifically oriented normal to its - primitive each normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner - - - - - - - - - - - Direction of each normal. - - - - - - - - - Qualifier how which specifically oriented normal to its - primitive each normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner - - - - - - - - Triangle normals are oriented in the direction of the - gradient vector of the local delocalized scalar field. - :math:`\sum_{x, y, z} {\nabla{c}_i}^2`. - - - - - - - - - Triangle normals are oriented in the direction of the - gradient vector of the local delocalized scalar field. - The projection variable here describes the cosine of the - angle between the gradient direction and the normal - direction vector. - This is a descriptor of how parallel the projection is - that is especially useful to document those triangles - for whose projection is almost perpendicular. - - - - - - - - - - - - - - Array of edge length values. For each triangle the edge length - is reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - - - - - - - - - Array of interior angle values. For each triangle the angle - is reported for the angle opposite to the edges which are - traversed according to the sequence in which vertices - are indexed in triangles. - - - - - - - - - The center of mass of each triangle. - - - - - - - - - - Iso-surfaces of arbitrary scalar three-dimensional fields - can show a complicated topology. Paraprobe-nanochem can run - a DBScan-like clustering algorithm which performs a - connectivity analysis on the triangle soup. This yields a - set of connected features with their surfaces discretized - by triangles. Currently, the tool distinguishes at most - three types of features: - - 1. So-called objects, i.e. necessarily watertight features - represented polyhedra. - 2. So-called proxies, i.e. features that were replaced by a - proxy mesh and made watertight. - 3. Remaining triangle surface meshes of arbitrary shape and - cardinality. - - These features can be interpreted as microstructural features. - Some of them may be precipitates, some of them may be poles, - some of them may be segments of dislocation lines or other - crystal defects which are decorated (or not) with solutes. - - - - - The identifier which the triangle_soup connectivity analysis - returned, which constitutes the first step of the - volumetric_feature identification process. - - - - - - - - The array of keywords of feature_type dictionary. - - - - - - - - The array of values for each keyword of the - feature_type dictionary. - - - - - - - - The array of controlled keywords, need to be from - feature_type_dict_keyword, which specify which type - each feature triangle cluster belongs to. - Keep in mind that not each feature is an object or proxy. - - - - - - - - The explicit identifier of features. - - - - - - - - - Details for features which are (closed) objects. - Identifier have to exist in feature_identifier. - - - - - - - - - - - - - - - An oriented bounding box (OBB) to each object. - - - - Edge length of the oriented bounding box from largest - to smallest value. - - - - - - - - - - Oriented bounding box aspect ratio. YX versus ZY. - - - - - - - - - Position of the geometric center, which often is but - not necessarily has to be the center_of_mass of the - hexahedrally-shaped sample/sample part. - - - - - - - - - - A simple approach to describe the entire set of hexahedra - when the main intention is to store the shape of the - hexahedra for visualization. - - - - - - - - - - - - - - - - - - - - - - - - Details for all those objects close to edge, i.e. those which - have at least one ion which lays closer to a modelled edge - of the dataset than threshold. - - - - - - - - - - - - - - - Total (count) relevant for normalization. - - - - - - - - - - - - Count or weight which, when divided by total, - yields the composition of this element, isotope, - molecule or ion. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Array of evaporation_identifier / ion_identifier which - specify ions laying inside or on the surface of the feature. - - - - - - - - - - - Details for all those objects far from edge, i.e. those - whose ions lay all at least threshold distant from a - modelled edge of the dataset. - - - - - - - - - - - - - - - Total (count) relevant for normalization. - - - - - - - - - - - - Count or weight which, when divided by total - yields the composition of this element, isotope, - molecule or ion. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Array of evaporation_identifier / ion_identifier which - specify ions laying inside or on the surface of the feature. - - - - - - - - - - - - - Details for features which are so-called proxies, i.e. objects - which have been reconstructed and combinatorially closed with - processing their partial triangulated_surface_mesh - (hole filling, refinement). - Identifier have to exist in feature_identifier. - - - - - - - - - - - - - - - - Details for those proxies close to edge, i.e. those which - have at least one ion which lays closer to a modelled edge - of the dataset than threshold. - Identifier have to exist in feature_identifier. - - - - - - - - - - - - - - - - Total (count) relevant for normalization. - - - - - - - - - - Count or weight which, when divided by total - yields the composition of this element, isotope, - molecule or ion. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Array of evaporation_identifier / ion_identifier which - specify ions laying inside or on the surface of the feature. - - - - - - - - - - - Details for those proxies far from edge, i.e. those whose - ions lay all at least threshold distant from a - modelled edge of the dataset. - - - - - - - - - - - - - - - Total (count) relevant for normalization. - - - - - - - - - - Count or weight which, when divided by total - yields the composition of this element, isotope, - molecule or ion. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Array of evaporation_identifier / ion_identifier which - specify ions laying inside or on the surface of the feature. - - - - - - - - - - - - - - - - - - The multiplicity whereby the ion position is accounted for - irrespective whether the ion is considered as a decorator - of the interface or not. - As an example, with atom probe it is typically not possible - to resolve the positions of the atoms which arrive at the detector - as molecular ions. Therefore, an exemplar molecular ion of two carbon - atoms can be considered to have a multiplicity of two to account that - this molecular ion contributes two carbon atoms at the reconstructed - location considering that the spatial resolution of atom probe - experiments is limited. - - - - - - - - The multiplicity whereby the ion position is accounted for when - the ion is considered one which is a decorator of the interface. - - - - - - - - The equation of the plane that is fitted initially. - - - - The four parameter :math:`ax + by + cz + d = 0` which define the plane. - - - - - - - - - The triangle surface mesh representing the interface model. - Exported at some iteration before the next DCOM step. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Direction of each normal - - - - - - - - - Qualifier how which specifically oriented normal to its primitive each - normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner - - - - - - - - - - - - Direction of each normal - - - - - - - - - Qualifier how which specifically oriented normal to its primitive each - normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner - - - - - - - - - - - - - - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - - - - - - - - - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. - - - - - - - - - - The triangle surface mesh representing the interface model. - Exported at some iteration after the next DCOM step. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Direction of each normal - - - - - - - - - Qualifier how which specifically oriented normal to its primitive each - normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner - - - - - - - - - - - - Direction of each normal - - - - - - - - - Qualifier how which specifically oriented normal to its primitive each - normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner - - - - - - - - - - - - - - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - - - - - - - - - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. - - - - - - - - - - - - The ROIs are defined as cylinders for the computations. - To visualize these though we discretize them into regular n-gons. - Using for instance a 360-gon, i.e. a regular n-gon with 360 - edges resolves the lateral surface of each cylinder very finely - so that they are rendered smoothly in visualization software. - - - - - - Position of the geometric center, which often is but not - necessarily has to be the center_of_mass of the polyhedra. - - - - - - - - - Integer which specifies the first index to be used for distinguishing - ROI cylinder. Identifiers are defined explicitly. - - - - - - - - - - - - - - - The number of atoms in each ROI. - - - - - - - - The number of ions in each ROI. - - - - - - - - The orientation of the ROI defined via a vector which points along - the cylinder axis and whose length is the height of the cylinder. - - - - - - - - - - In the direction of the ROI. - - - - - Hashvalue - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml deleted file mode 100644 index 52e41fca56..0000000000 --- a/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml +++ /dev/null @@ -1,425 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of ions in the reconstruction. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. - - - - - Results of a paraprobe-ranger tool run. - - - - - - Version specifier of this application definition. - - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - - - - - The path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - - - - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - - Paraprobe-ranger loads the iontypes and evaluates for each - ion on which iontype it matches. If it matches on none, the - ion is considered of the default unknown type with a 0 as its - respective value in the iontypes array. - - - - - The length of the isotope_vector used to describe molecular ions. - - - - - - - - - - - The iontype ID for each ion that was best matching, stored in the - order of the evaporation sequence ID. The here computed iontypes - do not take into account the charge state of the ion which is - equivalent to interpreting a RNG and RRNG range files for each - ion in such a way that only the elements of which a (molecular) ion - is build are considered. By contrast, charged_iontypes takes - into account also the charge state. - - - - - - - - A bitmask which identifies exactly all those ions ranged irrespective - the type they ended up with. - - - - Number of ions covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - - Paraprobe-ranger performs a combinatorial search over - all possible or a reduced set of nuclids to identify - into which ions these can be composed. - - - - The main result is the list of molecular ions, here formatted - according to the definitions of a set of isotope_vectors - as detailed in :ref:`NXion`. - - - - - - - - - The mass-to-charge-state ratio of each molecular ion - without considering relativistic or quantum effects. - - - - - - - - The mass of each molecular ion without - considering relativistic or quantum effects. - - - - - - - - - The charge_state of each molecular ion. - - - - - - - - The product of the natural abundance of the isotopes building - each molecular ion. Further details are available in - :ref:`NXapm_paraprobe_config_ranger`. - - - - - - - - The product of the natural abundance of the isotopes building - each molecular ion. Further details are available in - :ref:`NXapm_paraprobe_config_ranger`. - - - - - - - - The number of disjoint nuclids for each molecular ion. - - - - - - - - The number of nuclids for each molecular ion. - - - - - - - - - Paraprobe-ranger loads iontypes and evaluates for each ion on which - iontype it matches. If it matches on none, the ion is considered of - the default unknown type with a 0 as its respective value in the - iontypes array. In contrast to use_existent_ranging this process - does neither needs measured ion position nor mass-to-charge-state - ratio values. - - - - - The length of the isotope_vector used to describe molecular ions. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_results_selector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_selector.nxdl.xml deleted file mode 100644 index 38fac70961..0000000000 --- a/contributed_definitions/NXapm_paraprobe_results_selector.nxdl.xml +++ /dev/null @@ -1,274 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of ions in the reconstruction. - - - - - Results of a paraprobe-selector tool run. - - - - - - Version specifier of this application definition. - - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - - - - - The absolute path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - - - - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - - A bitmask which identifies which of the ions in the dataset - were selected to become included in the region-of-interest (ROI). - - - - Number of ions covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_results_spatstat.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_spatstat.nxdl.xml deleted file mode 100644 index d87d2f50ff..0000000000 --- a/contributed_definitions/NXapm_paraprobe_results_spatstat.nxdl.xml +++ /dev/null @@ -1,364 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of ions in the reconstruction. - - - - - Results of a paraprobe-spatstat tool run. - - - - - - Version specifier of this application definition. - - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - - - - - The absolute path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - - - - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - - A bitmask which identifies which of the ions in the dataset were - analyzed. - - - - Number of ions covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - The iontype ID for each ion that was assigned to each ion during - the randomization of the ionlabels. Iontype labels are just permuted - but the total number of values for each iontype stay the same. - - The order matches the iontypes array from a given ranging results - as is specified in the configuration settings inside the specific - config_filename that was used for this spatstat analysis. - - - - - - - - K-nearest neighbor statistics. - - - - Right boundary of the binning. - - - - - - - - - - - - - Cumulated - - - - - - - - Cumulated and normalized by total counts - - - - - - - - - Radial distribution statistics. - - - - Right boundary of the binning. - - - - - - - - - - - - - Cumulated - - - - - - - - Cumulated and normalized by total counts - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml deleted file mode 100644 index 5c5220f2a8..0000000000 --- a/contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml +++ /dev/null @@ -1,503 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of ions in the reconstruction. - - - - - The number of vertices of the alpha complex. - - - - - The number of faces of the alpha complex. - - - - - The total number of XDMF values to represent all faces of triangles via XDMF. - - - - - The total number of XDMF values to represent all faces of tetrahedra via XDMF. - - - - - Results of a paraprobe-surfacer tool run. - - - - - - Version specifier of this application definition. - - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - - - - - The absolute path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - - - - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - - A bitmask which identifies which of the ions in the dataset were - analyzed. Computations of alpha complexes may have filtered this - ion set further but this process is deterministic. - - - - Number of ions covered by the mask. The mask may be 0 for most. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - Paraprobe-surfacer can be used to load a ROI that is the entire or a - sub-set of the ion point cloud. In the point_cloud_wrapping process - the tool computes a triangulated surface mesh which encloses the - ROI/point cloud. This mesh can be seen as a model for the edge of - the dataset. - Different algorithms can be used with paraprobe-surfacer to create - this mesh such as convex hulls, alpha-shapes as their generalization, - or alpha wrappings. - Ideally, the resulting mesh should be a watertight polyhedron. - This polyhedron is not necessarily convex. For some algorithms there - is no guarantee that the resulting mesh yields a watertight mesh. - - - - - - A bitmask which identifies exactly all those ions whose positions - were considered when defining the filtered point set from which - the alpha complex was then in fact computed. This window - can be different to the entire window as irrelevant ions might - have been filtered out to reduce the computational costs of the - alpha complex analysis. - - - - - Number of ions covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The set of triangles in the coordinate system paraprobe - which discretizes the exterior surface of the alpha complex. - - - - Integer which specifies the first index to be used for distinguishing - triangles. Identifiers are defined either implicitly or explicitly. - For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - - - - - - - Number of vertices. - - - - - Number of faces. - - - - - - - - - - - - - - - - - - - A list of as many tuples of XDMF topology key, XDMF number - of vertices and a triple of vertex indices specifying each - triangle. The total number of entries is n_f_tri * (1+1+3). - - - - - - - - - Do the triangles define a triangulated surface mesh which - is watertight? - - - - - The volume which the triangulated surface mesh encloses - provided that the mesh is watertight. - - - - - - The set of tetrahedra which represent the interior volume of the - complex if that is a closed 2-manifold. - - - - Integer which specifies the first index to be used for distin- - guishing tetrahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined - on the interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - - - - The accumulated volume of all interior tetrahedra. - - - - - - Number of vertices. - - - - - Number of faces. - - - - - - - - - - - - - A list of as many tuples of XDMF topology key, XDMF number - of vertices and a triple of vertex indices specifying each - triangle. The total number of entries is n_f_tet * (1+1+4). - - - - - - - - - - - - In the future we may want to wrap other primitives - like triangles or polylines. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml deleted file mode 100644 index c6081efe77..0000000000 --- a/contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml +++ /dev/null @@ -1,677 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of ions in the reconstruction. - - - - - The total number of facets/polygons defining the tessellation. - - - - - Results of a paraprobe-tessellator tool run. - - - - - - Version specifier of this application definition. - - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - - - - - The absolute path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - - - - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - - The tool can be used to compute a Voronoi tessellation the entire - or a sub-set of the reconstruction. The point cloud in the ROI is - wrapped into a tight axis-aligned bounding box. The tool detects if - Voronoi cells make contact with the walls of this bounding box. - The tessellation is computed without periodic boundary conditions. - - - - A bitmask which identifies which of the ions in the dataset were - analyzed. - - - - Number of ions covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - A bitmask which identifies which of points have Voronoi cells that - are truncated by the global axis-aligned bounding box, i.e. boundaries - of the threads are ignored. - - - - Number of points covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - - A bitmask which identifies which of points have Voronoi cells that - are truncated by a specific wall of the axis-aligned bounding box. - The left wall has the negative x axis of the paraprobe coordinate - system as the outer unit normal. - - - - Number of points covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - A bitmask which identifies which of points have Voronoi cells that - are truncated by a specific wall of the axis-aligned bounding box. - The right wall has the positive x axis of the paraprobe coordinate - system as the outer unit normal. - - - - Number of points covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - A bitmask which identifies which of points have Voronoi cells that - are truncated by a specific wall of the axis-aligned bounding box. - The front wall has the negative y axis of the paraprobe coordinate - system as the outer unit normal. - - - - Number of points covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - A bitmask which identifies which of points have Voronoi cells that - are truncated by a specific wall of the axis-aligned bounding box. - The rear wall has the positive y axis of the paraprobe coordinate - system as the outer unit normal. - - - - Number of points covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - A bitmask which identifies which of points have Voronoi cells that - are truncated by a specific wall of the axis-aligned bounding box. - The left wall has the negative z axis of the paraprobe coordinate - system as the outer unit normal. - - - - Number of points covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - A bitmask which identifies which of points have Voronoi cells that - are truncated by a specific wall of the axis-aligned bounding box. - The left wall has the positive z axis of the paraprobe coordinate - system as the outer unit normal. - - - - Number of points covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - - - - - - - - Interior volume - - - - - - - - By which MPI process was the Voronoi cell computed. - - - - - - - - By which OpenMP thread was the Voronoi cell computed. - - - - - - - - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. This field can be used to interpret - the array/field with the individual area values for each face. - - - - - - - - - Integer which specifies the first index to be used for distinguishing - polyhedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - - - - Integer used to distinguish polyhedra for explicit indexing. - - - - - - - - A simple approach to describe the entire set of polyhedra when - the main intention is to store the shape of the polyhedra for - visualization. - - - - - Number of vertices. - - - - - Number of faces. - - - - - - - - - - - - - A sequence of always first an XDMF topology type key, followed - by the XDMF number of vertices of the polygon, followed by - the vertex identifier which define the facet polygon. First - we store the polygon of the first facet of the first cell, then - the second facet of the first cell, until the last facet of the - first cell, followed by the first facet of the second cell, - and so on and so forth. - - - - - - - - A sequence of cell identifier so that each facet is associated - with its cell because of which it is then possible to segment - out cells three-dimensionally based on cell i.e. evaporation_id. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml deleted file mode 100644 index f7e0f3433e..0000000000 --- a/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml +++ /dev/null @@ -1,568 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of ions in the reconstruction. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. - - - - - Number of mass-to-charge-state-ratio intervals mapped on this ion type. - - - - - Total number of integers in the supplementary XDMF topology array. - - - - - Number of ions probed in the combinatorial analysis of the charge states - - - - - Results of a paraprobe-transcoder tool run. - - - - - - Version specifier of this application definition. - - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - - - - - The absolute path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - - - - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstruction. The XDMF datatype - is here 1, the number of primitives 1 per triplet, the last integer - in each triplet is the identifier of each point starting from zero. - - - - - - - - - - On a mid term perspective we would like to evolve the paraprobe-toolbox - to an implementation stage where it works exclusively with completely - provenance-tracked formats for both the configuration of the workflow step - and/or analysis with each tool and also for the output of these analyses - in the form of so-called tool-specific results files. - Currently the Hierarchical Data Format 5 (HDF5) is used to store such data. - - Different file formats can be used to inject reconstructed datasets and - ranging definitions into the toolbox. Traditionally, these are the POS, - ePOS, and APT files with the tomographic reconstruction and other metadata - and RNG and RRNG file formats for the ranging definitions how mass-to-charge - state-ratio values map on (molecular) ion types. Such input should be - injected via specific NeXus/HDF5 files which are documented - in compliance with the NXapm application definition. - - So far the paraprobe-toolbox was used as a standalone tool. Therefore, it - was not relevant during the development to focus on interoperability. - Essentially paraprobe-transcoder was used as a parser to transcode data - in the above-mentioned file formats into a paraprobe-specific - representation. This transcoding should become deprecated. - Here we describe steps we have taken into this direction. - - With the work in the FAIRmat project and the desire to make the paraprobe- - toolbox also accessible as a cloud-computing capable service in the Nomad - Remote Tools Hub (NORTH) the topic of interoperability became more important - and eventually the NXapm application definition was proposed. - NORTH is a GUI and related service in a NOMAD OASIS instance which allows - to spawn preconfigured docker containers via JupyterHub. - Currently, NORTH includes the so-called apm container. A container with - tools specific for analyzing data from atom probe microscopy as well as - processing of point cloud and mesh data. - - The NXapm application definition and related implementation work within - NOMAD OASIS enabled users to parse content of POS, ePOS, APT, RNG, and - RRNG files, surplus key metadata from vendor-agnostic electronic lab notebook - solutions directly into NOMAD OASIS via the uploads section. - The process is automated and yields an NXapm-compliant NeXus/HDF5 file - inside the uploads section in return. - - With these improvements made there is no longer a need for - at least the - users of a NOMAD OASIS and NORTH instance to use the deprecated - PARAPROBE.Transcoder.Results.*.h5 files. Ideally, paraprobe should - automatically detect that the input can now be an NXapm-compliant NeXus/HDF5 - file and in response work with this file directly. - To remain compliant with users however who do not have or do not wish - to use a NOMAD OASIS or NXapm or NeXus at all right now, the solution is - as follows: - - Calling the configuration stage of paraprobe-transcoder is always mandatory. - It is always the first step of working with the toolbox. In this process - the user defines the input files. These can either be nxs i.e. the NXapm/NeXus/ - HDF5 file from e.g. the upload section, or such a file that was obtained from - a colleague with a NOMAD OASIS instance. - In all other cases, users can pass the reconstruction and ranging definitions - using the traditional POS, ePOS, or APT and RNG or RRNG file formats respectively. - - Based on which input the user delivers, the parmsetup-transcoder tool then - creates a configuration file PARAPROBE.Transcoder.Config.SimID.*.nxs and - informs the user whether the input was NeXus (and thus if all relevant - input is already available) or whether the paraprobe-transcoder tool needs - to be executed to convert the content of the vendor files first into a - format which paraprobe can provenance track and understand. - In the latter case, the PARAPROBE.Transcoder.Config.SimID.*.nxs file is - used to communicate to all subsequently used tools from which files - the tools can expect to find the reconstruction and ranging definitions. - - All subsequent analysis steps start also with a tool-specific configuration. - This configuration step reads in (among others) the - PARAPROBE.Transcoder.Config.SimID.*.nxs file from which the configuration - tool identifies automatically whether to read the reconstruction and ranging data - from PARAPROBE.Transcoder.Results.SimID.*.h5 or directly the NXapm-compliant - NeXus/HDF5 file that was created upon preparing the upload or the file shared - from a colleague. This design removes the need for unnecessary copies of the data. - Currently still though users should execute the transcoder step as it will - generate a supplementary XDMF topology field with which the data in either - the NeXus/HDF5 or the transcoded vendor files can be displayed using e.g. - Paraview. For this purpose XDMF is used. - - Of course ideally the APT community would at some point converge to use - a common data exchange file format. To this end, AMETEK/Cameca's APT file format - could be a good starting point but so far it is lacking a consistent way of - how to store generalized ranging definitions and post-processing results. - POS, ePOS, Rouen's ATO, as well as other so far used representations of data - like CSV or text files have, to the best of our current knowledge, no - concept of how to marry reconstruction and (optional) ranging data into - one self-descriptive format. - - This summarizes the rationale behind the current choices of the I/O for - paraprobe. Furthermore, this summarizes also why the fundamental design - of splitting an analysis always into steps of configuration (with parmsetup), - task execution (with the respective C/C++ or Python tool of the toolbox), - and post-processing (e.g. with autoreporter) is useful because it offers - a clear description of provenance tracking. This is a necessary step to make - atom probe microscopy data at all better aligned with the aims of the - FAIR principles. - - The internal organization of the data entries in the atom_probe group - in this application definition for paraprobe-transcoder results files - mirror the definitions of the NXapm for consistency reasons. - - - - - - Mass-to-charge-state ratio values. - - - - - - - - - - - - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - - - - - - - - - - - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - - - - - - - - - Details and results of the combinatorial analyses of this - range definition to identify the charge_state for an ion. - - - - Currently charge_state not charge! - - - - - - - - Specific isotopes building each candidate matching the range. - - - - - - - - - Accumulated mass of the isotopes in each candidate. - Not corrected for quantum effects. - - - - - - - - - Product of natural abundance of the isotopes per candidate. - - - - - - - - Filter criterion on the product of the natural abundances - computed from each isotope building the (molecular) ion. - Such a filter can be used to reduce the number of possible - molecular ions considered when trying to find a unique solution - to the question which charge_state does a molecular ion - within a given range and given combination of elements have. - - - - - Filter criterion on the minimum half life which all isotopes - building the (molecular) ion need to have to consider the - candidate. - Such a filter can be used to reduce the number of possible - molecular ions considered when trying to find a unique solution - to the question which charge_state does a molecular ion - within a given range and given combination of elements have. - - - - - - If the value is zero/false it means that non-unique solutions - are accepted. These are solutions where multiple candidates - differ in their isotopes but have the same charge. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/NXatom_set.nxdl.xml b/contributed_definitions/NXatom_set.nxdl.xml deleted file mode 100644 index 0a1e208560..0000000000 --- a/contributed_definitions/NXatom_set.nxdl.xml +++ /dev/null @@ -1,158 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). - - - - - Number of mass-to-charge-state-ratio range intervals for ion type. - - - - - Base class for documenting a set of atoms. - - - - A unique identifier whereby such an ion can be referred to - via the service offered as described in identifier_type. - - - - - How can the identifier be resolved? - - - - - - - - Ion type (ion species) identifier. - - The identifier zero is reserved for the special unknown ion type. - - - - - Vector of nuclide hash values. - - Individual hash values :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` - encode the number of protons :math:`Z` and the number of neutrons :math:`N` - of each nuclide respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. - - The array is sorted in decreasing order. For the rationale behind this see `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - Table which decodes the entries in nuclide_hash into a human-readable matrix of instances. - The first column specifies the nuclide mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N` or 0. The value 0 documents that no - isotope-specific information about the element encoded is relevant. - The second row specifies the number of protons :math:`Z` or 0. - The value 0 in this case documents a placeholder or that no element-specific - information is relevant. - Taking a carbon-14 nuclide as an example the mass number is 14. - That is encoded as a value pair (14, 6) as one row of the table. - - Therefore, this notation is the typical superscribed nuclide mass number - and subscripted number of protons element notation e.g. :math:`^{14}C`. - The array is stored matching the order of nuclide_hash. - - - - - - - - - - Assumed volume of the ion. - - In atom probe microscopy this field can be used to store the reconstructed - volume per ion (average) which is typically stored alongside ranging - definitions. - - - - - Charge of the ion. - - - - - Signed charge state if the atoms form an ion reported in multiples of electron charge. - - In the example of atom probe microscopy, only positive values will be measured - as the ions are accelerated by a negatively signed bias electric field. - In the case that the charge state is not explicitly recoverable, the value should - be set to zero. - - In atom probe microscopy this is for example the case when using - classical ranging definition files in formats like RNG, RRNG. - These file formats do not document the charge state explicitly - but the number of atoms of each element per molecular ion - surplus the mass-to-charge-state-ratio interval. - Details on ranging definition files can be found in the literature: - `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - - - - - Human-readable name (e.g. Al +++) of the atom set, the atom group, or ion type. - The string should consists of UTF-8 characters, ideally using LaTeX - notation to specify the isotopes, ions, and charge state. - Examples are 12C + or Al +++. - - To ease automated parsing, isotope_vector should be the - preferred machine-readable information used. - - - - - Associated lower (mqmin) and upper (mqmax) bounds of the - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries inclusive). This field is primarily of interest - for documenting :ref:`NXprocess` steps of indexing a - ToF/mass-to-charge state histogram. - - - - - - - diff --git a/contributed_definitions/NXbias_spectroscopy.nxdl.xml b/contributed_definitions/NXbias_spectroscopy.nxdl.xml deleted file mode 100644 index ad484c806f..0000000000 --- a/contributed_definitions/NXbias_spectroscopy.nxdl.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - Base classes definition for bias spectroscopy. - - Bias sweeps while measuring arbitrary channels with I(V) curves. - - - - Select the channels to record. - - - - - If chosen, the Bias voltage resets to its initial value (before the sweep initiation) at - the conclusion of the spectroscopy measurement. When this option is not selected, the Bias - voltage maintains the last value acquired during the sweep. This functionality proves - beneficial, especially when combining multiple sweep segments. As an illustration of an - automated measurement: turn off the z-Controller, commence spectroscopy sweep segments ( - forward sweep only, without resetting the bias), restore the bias to its initial value, - and then turn on the z-Controller. - - - - - Select whether to record the Z position during Z averaging time at the end of - the sweep (after Z control time) and store the average value in the header of - the file when saving. Using this option increases the sweep time by Z averaging - time. - - - - - Select whether to set the Lock-In to run during the measurement. When using this - feature, make sure the Lock-In is configured correctly and settling times are - set to twice the Lock-In period at least. This option is ignored when Lock-In is - already running. This option is disabled if the Sweep Mode is MLS and the flag - to configure the Lock-In per segment in the Multiline segment editor is set. - - - - - Time during which the spectroscopy data are acquired and averaged. - - - - - Number of sweeps to measure and average. - - - - - The first bias values of the sweep. - - - - - The last bias values of the sweep. - - - - - Define the sweep number of points, that is, the maximum spectrum resolution eq. - Bias window divide by Num Pixel. - - - - - Duration over which the Z position is recorded and averaged before and after the - sweep (the latter only if Record final Z position is selected in the Advanced - section). After the initial z averaging time, if Z-Controller to Hold is - selected in the Advanced section, the z-Controller is set to hold and the tip is - placed at the previously averaged z position (plus z offset). - - - - - Select a filter to smooth the displayed data. When saving, if any filter is selected, - filtered data are saved to file along with the unfiltered data. - - - - - Filter order of a dynamic filter or width (in number of points) for the Gaussian - filter. - - - - - Cutoff frequency for dynamic filters. - - - - - Offset added to the initial averaged position Zaver before starting to sweep. - This parameter is disabled when Z-Controller to Hold is deselected in the - Advanced section. The LED “Alt” next to the Z offset indicates if an alternate - Z-controller setpoint is enabled. - - - - - Time to wait after changing the bias to the next level and before - starting to acquire data. - - - - - No doc yet. - - - - - Time to wait after the sweep has finished and the bias is ramped to - the initial value. - - - - - Time during which the Z-Controller is enabled once a sweep has finished. - When averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled - for this duration between each sweep. After the last sweep, it will wait the - specified time before continuing a running scan. This ensures each sweep - reliably starts from the same position. This parameter is disabled when - Z-Controller to Hold is deselected in the Advanced section. - - - - - Maximum rate at which the bias changes (before, during and after sweeping). - (V/s) - - - - - Select whether to measure the backward (return) sweep or the forward only. - - - - - Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. - It is selected by default. When deselected, Z-offset and Z control time parameters - are disabled. - - - diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/contributed_definitions/NXcoordinate_system_set.nxdl.xml deleted file mode 100644 index 120caa7390..0000000000 --- a/contributed_definitions/NXcoordinate_system_set.nxdl.xml +++ /dev/null @@ -1,235 +0,0 @@ - - - - - - - Base class to hold different coordinate systems and representation conversions. - - How many nodes of type :ref:`NXcoordinate_system_set` should be used in an application definition? - - * 0; if there is no instance of :ref:`NXcoordinate_system_set` and therein or elsewhere across - the application definition, an instance of NXcoordinate_system is defined, - the default NeXus `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ - coordinate system is assumed. This makes :ref:`NXcoordinate_system_set` and - NXcoordinate_system base classes backwards compatible to older - NeXus conventions and classes. - * 1; if only one :ref:`NXcoordinate_system_set` is defined, it should be placed - as high up in the node hierarchy (ideally right below an instance of NXentry) - of the application definition tree as possible. - This :ref:`NXcoordinate_system_set` should define at least one NXcoordinate_system - instance. This shall be named such that it is clear how this coordinate system is - typically referred to in a community. For the NeXus `McStas coordinate system, it is - advised to call it mcstas for the sake of improved clarity. - Additional NXcoordinate_system instances should be specified if possible in that same - :ref:`NXcoordinate_system_set` instead of cluttering them across the tree. - - If this is the case, it is assumed that the NXcoordinate_system_members - overwrite the NeXus default McStas coordinate system, i.e. users can thereby - conveniently and explicitly specify the coordinate system(s) that - they wish to use. - - Users are encouraged to write also explicit and clean depends_on fields in - all groups that encode information about where the interpretation of coordinate - systems is relevant. If these depends_on hints are not provided, it is - automatically assumed that all children (to arbitrary depth) - of that branch and sub-branches below the one in which that - :ref:`NXcoordinate_system_set` is defined use either the only NXcoordinate_system_set - instance in that set or the application definition is considered - underconstrained which should at all costs be avoided and in which case - again McStas is assumed. - * 2 and more; as soon as more than one :ref:`NXcoordinate_system_set` is specified - somewhere in the tree, different interpretations are possible as to which - of these coordinate system sets and instances apply or take preference. - We realize that such ambiguities should at all costs be avoided. - However, the opportunity for multiple sets and their instances enables to - have branch-specific coordinate system conventions which could especially - be useful for deep classes where multiple scientific methods are combined or - cases where having a definition of global translation and conversion tables - how to convert between representations in different coordinate systems - is not desired or available for now. - We argue that having 2 or more :ref:`NXcoordinate_system_set` instances and respective - NXcoordinate_system instances makes the interpretation eventually unnecessary - complicated. Instead, developers of application definitions should always try - to work for clarity and thus use only one top-level coordinate system set. - - For these reasons we conclude that the option with one top-level - :ref:`NXcoordinate_system_set` instance is the preferred choice. - - McStas is used if neither an instance of :ref:`NXcoordinate_system_set` nor an instance - of NXcoordinate_system is specified. However, even in this case it is better - to be explicit like for every other coordinate system definition to support - users with interpreting the content and logic behind every instance of the tree. - - How to store coordinate systems inside :ref:`NXcoordinate_system_set`? - Individual coordinate systems should be specified as members of the - :ref:`NXcoordinate_system_set` instance using instances of NXcoordinate_system. - - How many individual instances of NXcoordinate_system to allow within one - instance of :ref:`NXcoordinate_system_set`? - - * 0; This case should be avoided for the sake of clarity but this case could - mean the authors of the definition meant that McStas is used. We conclude, - McStas is used in this case. - * 1; Like above-mentioned this case has the advantage that it is explicit - and faces no ambiguities. However, in reality typically multiple - coordinate systems have to be mastered especially for complex - multi-signal modality experiments. - * 2 or more; If this case is realized, the best practice is that in every - case where a coordinate system should be referred to the respective class - has a depends_on field which resolves the possible ambiguities which specific - coordinate systems is referred to. The benefit of this explicit and clear - specifying of the coordinate system used in every case is that especially - in combination with having coordinate systems inside deeper branches - makes up for a very versatile, backwards compatible, but powerful system - to express different types of coordinate systems using NeXus. In the case - of two or more instances of NXcoordinate_system in one :ref:`NXcoordinate_system_set`, - it is also advised to specify the relationship between the two coordinate systems by - using the (NXtransformations) group within NXcoordinate_system. - - In effect, 1 should be the preferred choice. However, if more than one coordinate - system is defined for practical purposes, explicit depends_on fields should - always guide the user for each group and field which of the coordinate system - one refers to. - - - - Convention how a positive rotation angle is defined when viewing - from the end of the rotation unit vector towards its origin, - i.e. in accordance with convention 2 of - DOI: 10.1088/0965-0393/23/8/083501. - Counter_clockwise is equivalent to a right-handed choice. - Clockwise is equivalent to a left-handed choice. - - - - - - - - - How are rotations interpreted into an orientation - according to convention 3 of - DOI: 10.1088/0965-0393/23/8/083501. - - - - - - - - - How are Euler angles interpreted given that there are several choices (e.g. zxz, xyz) - according to convention 4 of DOI: 10.1088/0965-0393/23/8/083501. - - The most frequently used convention is zxz, which is based on the work of H.-J. Bunge - but other conventions are possible. Apart from undefined, proper Euler angles - are distinguished from (improper) Tait-Bryan angles. - - - - - - - - - - - - - - - - - - - To which angular range is the rotation angle argument of an - axis-angle pair parameterization constrained according to - convention 5 of DOI: 10.1088/0965-0393/23/8/083501. - - - - - - - - Which sign convention is followed when converting orientations - between different parameterizations/representations according - to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. - - - - - - - - - - - - Details about eventually relevant named directions that may give reasons for anisotropies. - The classical example is mechanical processing where one has to specify which directions - (e.g. rolling, transverse, and normal direction) align how with the direction of the base - vectors of the sample_reference_frame. - - It is assumed that the configuration is inspected by looking towards the sample surface. - If a detector is involved, it is assumed that the configuration is inspected from a position - that is located behind this detector. - - If any of these assumptions is not met, the user is required to explicitly state this. - - Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the - base vectors of this coordinate system as Xp, Yp, Zp. - - - - - Details about the sample_reference_frame that is typically overlaid onto the surface of the sample. - - It is assumed that the configuration is inspected by looking towards the sample surface. - If a detector is involved, it is assumed that the configuration is inspected from a position - that is located behind this detector. - - If any of these assumptions is not met, the user is required to explicitly state this. - - Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the - base vectors of this coordinate system as Xs, Ys, Zs. - - - - - Details about the detector_reference_frame for a specific detector. - - Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the - base vectors of this coordinate system as Xd, Yd, Zd. - - It is assumed that the configuration is inspected by looking towards the sample surface - from a position that is located behind the detector. - - If any of these assumptions is not met, the user is required to explicitly state this. - - - diff --git a/contributed_definitions/NXdata_mpes.nxdl.xml b/contributed_definitions/NXdata_mpes.nxdl.xml deleted file mode 100644 index 8fe879134b..0000000000 --- a/contributed_definitions/NXdata_mpes.nxdl.xml +++ /dev/null @@ -1,134 +0,0 @@ - - - - - - :ref:`NXdata_mpes` describes the plottable data and related dimension scales in photoemission - experiments. - - It extends the NXdata class and provides a glossary of explicitly named axis names - which are typical for photoemission data. - - - - Calibrated energy axis. - - Could be linked from the respective '@reference' field. - - - - The energy can be either stored as kinetic or as binding energy. - - - - - Calibrated kinetic energy axis. - - This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. - - .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 - - - - - Calibrated binding energy axis. - - This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. - - .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - - - - - - - The energy can be dispersed according to different strategies. ``@reference`` points to - the path of a field defining the calibrated axis which the ``energy`` axis refers. - - For example: - @reference: 'entry/process/energy_calibration/calibrated_axis' - @reference: 'entry/process/energy_referencing/calibrated_axis' - - - - - - One calibrated k-space coordinate. It is envisioned that the axes are named kx, ky, and kz, - in accordance with the calibrations defined in NXprocess_mpes. - - Typically, the vectors in momentum space are defined such that kx and ky comprise the parallel component, - while kz is taken as the perpendicular component. - - It is also possible to define k_parallel and k_perp for the parallel and perpendicular momenta, respectively. - Units are 1/Angström. - - - - - One calibrated angular coordinate. It is envisioned that the axes are name angular0, angular1, etc., - in accordance with the calibrations defined in NXprocess_mpes. - - The angular axes should be named in order of decreasing speed, i.e., angular0 should be - the fastest scan axis and angular1 should be the slow-axis angular coordinate. However, - angular0 may also be second slow axis if the measurement is angularly integrated and angular1 - could also be the second fast axis in the case of simultaneous dispersion in two angular - dimensions. - - - - - One calibrated spatial coordinate. It is envisioned that the axes are name spatial0, spatial1, etc., - in accordance with the calibrations defined in NXprocess_mpes. - - The spatial axes should be named in order of decreasing speed, i.e., spatial0 should be - the fastest scan axis and spatial1 should be the slow-axis spatial coordinate. However, - spatial0 may also be second slow axis if the measurement is spatially integrated and spatial1 - could also be the second fast axis in the case of simultaneous dispersion in two spatial - dimensions. - - - - - Calibrated delay time. - - - - - Linear polarization angle of the incoming or outgoing beam. - - In an application definition, this could be a link to - /entry/instrument/beam/incident_polarization_angle or - /entry/instrument/beam/final_polarization_angle if they exist. - - - - - Ellipticity of the incoming or outgoing beam. - - Can be any of linear polarization angle (degrees), ellipticity (arb. units). - In an application definition, this could be a link to - /entry/instrument/beam/incident_ellipticity or - /entry/instrument/beam/final_ellipticity if they exist. - - - diff --git a/contributed_definitions/NXdata_mpes_detector.nxdl.xml b/contributed_definitions/NXdata_mpes_detector.nxdl.xml deleted file mode 100644 index 3faebab2f6..0000000000 --- a/contributed_definitions/NXdata_mpes_detector.nxdl.xml +++ /dev/null @@ -1,147 +0,0 @@ - - - - - - :ref:`NXdata_mpes_detector` describes the plottable data and related - dimension scales for raw detector data in photoemission experiments. - - It extends the NXdata class and provides a glossary of explicitly named axis names - which are typical for raw photoemission data. - - - - Raw data before calibration. - - - - - Detector pixel in x direction. - - - - - Detector pixel in y direction. - - - - - (Un)calibrated energy axis. - - - - The energy can be either stored as kinetic or as binding energy. - - - - - (Un)calibrated kinetic energy axis. - - This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. - - .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 - - - - - (Un)calibrated binding energy axis. - - This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. - - .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - - - - - - - - One (un)calibrated k-space coordinate. It is envisioned that the axes are named kx, ky, and kz. - - Typically, the vectors in momentum space are defined such that kx and ky comprise the parallel component, - while kz is taken as the perpendicular component. - - It is also possible to define k_parallel and k_perp for the parallel and perpendicular momenta, respectively. - Units are 1/Angström. - - - - - One (un)calibrated angular coordinate. It is envisioned that the axes are name angular0, angular1, etc. - - The angular axes should be named in order of decreasing speed, i.e., angular0 should be - the fastest scan axis and angular1 should be the slow-axis angular coordinate. However, - angular0 may also be second slow axis if the measurement is angularly integrated and angular1 - could also be the second fast axis in the case of simultaneous dispersion in two angular - dimensions. - - - - - One (un)calibrated spatial coordinate. It is envisioned that the axes are name spatial0, spatial1, etc. - - The spatial axes should be named in order of decreasing speed, i.e., spatial0 should be - the fastest scan axis and spatial1 should be the slow-axis spatial coordinate. However, - spatial0 may also be second slow axis if the measurement is spatially integrated and spatial1 - could also be the second fast axis in the case of simultaneous dispersion in two spatial - dimensions. - - - - - - Total time of flight. - - - - - Time-of-flight values, analog-to-digital converted. - - - - - (Un)calibrated delay time. - - - - - Linear polarization angle of the incoming or outgoing beam. - - - - - Ellipticity of the incoming or outgoing beam. - - - - - Describes an axis which is coming from outside the detectors scope. - - Think of a detector just being triggered for readout by the rest of the experimental - setup - it would just know that it collected N images, which would flatten the external - parameters to one axis, too. - This can then be linked, e.g. with NXcalibration, to the appropriate fields in the instrument - and write it to the top-level NXdata_mpes. - - - diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml deleted file mode 100644 index 99adeb4d8b..0000000000 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ /dev/null @@ -1,121 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The number of edges. - - - - - A set of (eventually directed) edges which connect nodes of a graph. - - Use as a direct child of an instance of :ref:`NXgraph_root`. - Alternatively, use depends_on to specify which instance - of :ref:`NXgraph_root` is defined by this instance. - - - - Specify which instance of :ref:`NXgraph_root` this :ref:`NXgraph_edge_set` - refers to. - - - - - Total number of edges, counting eventual bidirectional edges only once. - - - - - Integer which specifies the first index to be used for distinguishing - edges. Identifiers are defined either implicitly or explicitly. - - For implicit indexing the identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. - - For explicit indexing use the field identifier. For implicit indexing, - consult :ref:`NXcg_primitive_set` to get guidance how to set identifier_offset. - - - - - Integer used to distinguish edges for explicit indexing. - - - - - - - - Specifier whether each edge is non-directional, one-directional, - or bidirectional. Use the smallest available binary representation - which can store three different states: - - * 0 / state 0x00 is non-directional - * 1 / state 0x01 is one-directional - * 2 / state 0x02 is bi-directional - - - - - - - - Pairs of node/vertex identifier. Each pair represents the connection - between two nodes. The order in the pair encodes eventual directionality. - - In the case that an edge is non- or bi-directional, storing - node identifier in ascending order is preferred. - - In the case that an edge is one-directional, node identifier should be - stored such that the identifier of the source node is the first entry - and the identifier of the target is the second entry in the pair. - - - - - - - - - A human-readable qualifier which type or e.g. class instance the - edge is an instance of. - - - - - - - - A human-readable label/caption/tag of each edge. - - - - - - diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml deleted file mode 100644 index 744f8ae9be..0000000000 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ /dev/null @@ -1,118 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The cardinality of the set, i.e. the number of nodes of the graph. - - - - - The dimensionality of the graph. Eventually use one for categorical. - - - - - A set of nodes representing members of a graph. - - Use as a direct child of an instance of :ref:`NXgraph_root`. - Alternatively, use depends_on to specify which instance - of NXgraph_root is defined by this instance. - - - - Specify which instance of :ref:`NXgraph_root` this :ref:`NXgraph_node_set` - refers to. - - - - - About which space does the graph make statements. - - - - - - - - - Dimensionality of the space about which the graph makes statements. - Use only when value of the field space is euclidean. - - - - - - - - - - Number of nodes of the graph. - - - - - Integer which specifies the first index to be used for distinguishing - nodes. Identifiers are defined either implicitly or explicitly. - - For implicit indexing the identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. - - For explicit indexing use the field identifier. For implicit indexing, - consult :ref:`NXcg_primitive_set` to get guidance how to set identifier_offset. - - - - - Integer used to distinguish nodes for explicit indexing. - - - - - - - - A human-readable qualifier which type or e.g. class instance the - node is an instance of. An example: a NeXus application definition is a - graph, more specifically a hierarchical directed labelled property graph. - Instances which are groups like :ref:`NXgraph_node_set` could have an is_a - qualifier reading :ref:`NXgraph_node_set`. - - - - - - - - A human-readable label/caption/tag of each node. - - - - - - diff --git a/contributed_definitions/NXgraph_root.nxdl.xml b/contributed_definitions/NXgraph_root.nxdl.xml deleted file mode 100644 index 6fc5f054ce..0000000000 --- a/contributed_definitions/NXgraph_root.nxdl.xml +++ /dev/null @@ -1,35 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - An instance of a graph. - - - - diff --git a/contributed_definitions/NXiv_bias.nxdl.xml b/contributed_definitions/NXiv_bias.nxdl.xml deleted file mode 100644 index a23dd89762..0000000000 --- a/contributed_definitions/NXiv_bias.nxdl.xml +++ /dev/null @@ -1,192 +0,0 @@ - - - - - - Application definition for bias devices. - - - - Applied a voltage between tip and sample. - - - - - The ratio between the tunneling current at the sample surface and the bias voltage - applied between the sample and the tip. - - - - - Calibration of the Bias output (V/V). - - - - - Allows compensating for an offset in Bias. Hardware parameter offset. - - - - - Sets the amplitude (in physical units of the modulated signal) of the sine - modulation. - - - - - Bias sweeps while measuring arbitrary channels with I(V) curves. - - - - - Select the channels to record. - - - - - When selected, the Bias voltage returns to the initial value (before starting the sweep) at - the end of the spectroscopy measurement (default). When not selected, Bias remains at the - last value of the sweep. This is useful e.g. when combining several sweep segments. Example - for an automated measurement (using Programming Interface): switch off Z-Controller, start - spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, - switch on Z-Controller. - - - - - Select whether to record the Z position during Z averaging time at the end of - the sweep (after Z control time) and store the average value in the header of - the file when saving. Using this option increases the sweep time by Z averaging - time. - - - - - Select whether to set the Lock-In to run during the measurement. When using this - feature, make sure the Lock-In is configured correctly and settling times are - set to twice the Lock-In period at least. This option is ignored when Lock-In is - already running. This option is disabled if the Sweep Mode is MLS and the flag - to configure the Lock-In per segment in the Multiline segment editor is set. - - - - - Time during which the spectroscopy data are acquired and averaged. - - - - - Number of sweeps to measure and average. - - - - - The first bias values of the sweep. - - - - - The last bias values of the sweep. - - - - - Define the sweep number of points, that is, the maximum spectrum resolution eq. - Bias window divide by Num Pixel. - - - - - Duration over which the Z position is recorded and averaged before and after the - sweep (the latter only if Record final Z position is selected in the Advanced - section). After the initial Z averaging time, if Z-Controller to Hold is - selected in the Advanced section, the Z-Controller is set to hold and the tip is - placed at the previously averaged Z position (plus Z offset). - - - - - Select a filter to smooth the displayed data. When saving, if any filter - selected, filtered data are saved to file along with the unfiltered data. - - - - - Filter order of a dynamic filter or width (in number of points) for the gaussian - filter. - - - - - Cutoff frequency for dynamic filters. - - - - - Offset added to the initial averaged position Zaver before starting to sweep. - This parameter is disabled when Z-Controller to Hold is deselected in the - Advanced section. The LED “Alt” next to the Z offset indicates if an alternate - Z-controller setpoint is enabled. - - - - - time to wait after changing the bias to the next level and before starting to - acquire data. - - - - - Time to wait after the sweep has finished and the bias is ramped to the initial - value. - - - - - Time during which the Z-Controller is enabled once a sweep has finished. When - averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled for this - duration between each sweep. After the last sweep, it will wait the specified - time before continuing a running scan. This ensures each sweep reliably starts - from the same position. This parameter is disabled when Z-Controller to Hold is - deselected in the Advanced section. - - - - - Maximum rate at which the bias changes (before, during and after sweeping). - (V/s) - - - - - Select whether to measure the backward (return) sweep or the forward only. - - - - - Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. - It is selected by default. When deselected, Z-offset and Z-control time - parameters are disabled. - - - diff --git a/contributed_definitions/NXlockin.nxdl.xml b/contributed_definitions/NXlockin.nxdl.xml deleted file mode 100644 index f72a279d4c..0000000000 --- a/contributed_definitions/NXlockin.nxdl.xml +++ /dev/null @@ -1,151 +0,0 @@ - - - - - - Base classes definition for lock in devices. - - - - Hardware manufacturers and type of lockin amplifier. - - - - - By mixing the input signal (STS signal) with the modulated signal (such as Bias) - and comparing it with the reference signal, they are enhanced and the effects of - noise interference are reduced, resulting in more accurate measurements. - - - - - if Lock-in -- Bias Divider 1/10 or 1/100, Bias divider = - V(ref)/[V(ref)+V(input)] - - - - - Switch the lock-in moulation on or off. - - - - - A modulation signal (such as bias, current et.al.) is a periodic voltage signal, - usually applied to the surface of a sample, which serves to modify the physical - properties of the sample surface and generate weak AC current signals that can - be detected and analysed by instruments such as lock-in amplifiers. - - - - - - Sets the amplitude (in physical units of the modulated signal) of the sine - modulation. - - - - - Sets the frequency of the sine modulation added to the signal to modulate. - - - - - The input signal (STS signal) will be demodulated, in order to determine the amplitude - and phase at the frequency set in the Frequency field or harmonics, such as current, - bias, et.al. - - - - - - The number of signals which will be demodulated. - - - - - Order and cut-off frequency of the low-pass filter applied on the demodulated - signals (X,Y). Cut-off frq (low pass filter) (foreach DemodulatorChannels) - - - - - Order and cut-off frequency of the high-pass filter applied on the demodulation - signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) - - - - - Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) - value) for D1. The filter is applied to the demodulated signals (X,Y). - - - - - Order and cut-off frequency of the low-pass filter applied on the demodulated - signals (X,Y). Reducing the bandwidth or increasing the order reduces noise on - the demodulated signals, but will require longer settling and measurement times. - - - - - Sets the cut-off frequency of the high-pass filter (affects the displayed TC (s) - value) for D1. The filter is applied to the demodulated signals (X,Y). - - - - - Order and cut-off frequency of the high-pass filter applied on the demodulation - signal of D!. This is used mainly to suppress a DC component of the demodulation - signal, which would lead to a component at modulation frequency in the - demodulated signals. - - - - - Switch on/off the Sync filter on the demodulated signals (X,Y) on or off. - (foreach DemodulatorChannels) - - - - - Reference phase for the sine on the demodulated signal with respect to the - modulation signal. (foreach DemodulatorChannels) - - - - - Time during which the data are acquired and averaged. (for the input filter) - - - - - The order of the harmonic oscillation to detect on the demodulated signals. - (with respect to the modulation frequency) - - - - - Ratio of output signal amplitude to input signal amplitue (V/V). (input gain) - - - diff --git a/contributed_definitions/NXms_feature_set.nxdl.xml b/contributed_definitions/NXms_feature_set.nxdl.xml deleted file mode 100644 index f8a8c90ff0..0000000000 --- a/contributed_definitions/NXms_feature_set.nxdl.xml +++ /dev/null @@ -1,300 +0,0 @@ - - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Dimensionality - - - - - Cardinality/number of members/features in the feature set. - - - - - Number of types in the dictionary of human-readable types of features. - - - - - Total number of parent identifier. - - - - - Set of topological/spatial features in materials build from other features. - - - - - - Name (or link?) to another NXms_feature_set which defines features what are - assumed as the parents/super_features of all members in this feature set. - If depends_on is set to "." or this attribute is not defined in an instance - of this application definition, assume that this feature_set instance - represents the root feature_set of the feature tree/graph. - - - - - - - What is the best matching description how dimensional the feature is. - - - - - - - - - - - - How many features/members are in this set? - - - - - - The keywords of the dictionary of human-readable types of features. - Using terms from a community-agreed upon controlled vocabulary, e.g. - atom, solute, vacancy, monomer, molecule, anti-site, crowd_ion, - quadruple junction, triple line, disconnection, dislocation, - kink, jog, stacking_fault, homo_phase_boundary, hetero_phase_boundary, - surface, thermal_groove_root, precipitate, dispersoid, pore, crack - is recommended. - - - - - - - - - The integer identifier used to resolve of which type each feature is, - i.e. the values of the dictionary of human-readable types of features. - - - - - - - - For each feature in the set specify the associated number of identifier - to parent features as are resolvable via depends_on. - This array enables to compute the array interval from which details for - specific features can be extracted as if they would be stored in an own - group. - - - - - - - - Concatenated array of parent identifier for each feature (in the sequence) - according to identifier and how the identifier of features in the here - described feature set are defined (implicitly from 0, to c-1 or via explicit - identifier. - - - - - - - - - Integer which specifies the first index to be used for distinguishing - features. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish features for explicit indexing. - - - - - - - - - Assumptions and parameter to arrive at geometric primitives - to locate zero-dimensional/point-(like) features which are - discretized/represented by points. - - - - - Assumptions, parameters, and details how positional uncertainty - of the geometry is quantified. - - - - - - - Assumptions and parameters to arrive at geometric primitives - to locate one-dimensional/line-like features which are - discretized by polylines. - - - - - - Assumptions, parameters, and details how positional uncertainty - of the geometry is quantified. - - - - - - Assumptions and parameters to arrive at geometric primitives - to locate two-dimensional/interface features which are - discretized by triangulated surface meshes. - - - - - - Assumptions, parameters, and details how positional uncertainty - of the geometry is quantified. - - - - - - Assumptions and parameters to arrive at geometric primitives - to locate three-dimensional/volumetric features which are - discretized by triangulated surface meshes of polyhedra. - - - - - - Assumptions, parameters, and details how positional uncertainty - of the geometry is quantified. - - - - - - - - - - diff --git a/contributed_definitions/NXms_score_config.nxdl.xml b/contributed_definitions/NXms_score_config.nxdl.xml deleted file mode 100644 index 7aab8367c9..0000000000 --- a/contributed_definitions/NXms_score_config.nxdl.xml +++ /dev/null @@ -1,452 +0,0 @@ - - - - - - - - Number of Bunge-Euler angle triplets for deformed grains. - - - - - Number of Bunge-Euler angle triplets for recrystallization nuclei. - - - - - Number of solitary unit domains to export. - - - - - Application definition to control a simulation with the SCORE model. - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - Relevant data to instantiate a starting configuration that is typically - a microstructure in deformed conditions where stored (elastic) energy - is stored in the form of crystal defects, which in the SCORE model are - is considered as mean-field dislocation content. - - - - Which model should be used to generate a starting microstructure. - - - - - - - - - - - Edge length of the cubic cells of each CA domain. - - - - - Extend of each CA domain in voxel along the x, y, and z direction. - Deformation of sheet material is assumed. - The x axis is assumed pointing along the rolling direction. - The y axis is assumed pointing along the transverse direction. - The z axis is assumed pointing along the normal direction. - - - - - - - - Extent of each deformed grain along the x, y, and z direction when type is - cuboidal. - - - - - - - - Average spherical diameter when type is poisson_voronoi. - - - - - Set of Bunge-Euler angles to sample orientations randomly from. - - - - - - - - - The EBSD dataset from which the initial microstructure is instantiated - if initial_microstructure/type has value ebsd. - - - - Path and name of the EBSD dataset from which to generate the starting - microstructure. - - - - SHA256 checksum of the file which contains the EBSD dataset. - - - - - - Size of the EBSD. The EBSD orientation mapping has to be on a - regular grid of square-shaped pixels. - - - - - - - - - - Phenomenological model according to which it nuclei are placed - into the domain and assumed growing. - - - - According to which model will the nuclei become distributed spatially. - CSR means complete spatial randomness. - Custom is implementation specific. - GB places nuclei at grain boundaries. - - - - - - - - - - According to which model will the nuclei start to grow. - - - - - - - - According to which model will the nuclei get their orientation assigned. - - - - - - - - Set of Bunge-Euler angles to sample orientations of nuclei randomly from. - - - - - - - - - - (Mechanical) properties of the material which scale the amount - of stored (elastic) energy in the ROI/system. - - - - Shear modulus at zero Kelvin. - - - - - Magnitude at the Burgers vector at zero Kelvin. - - - - - - Melting temperature in degrees Celsius. - - - - - - Model for the assumed mobility of grain boundaries with different - disorientation. - - - - Which type of fundamental model for the grain boundary mobility: - For the Sebald-Gottstein model the following equation is used. - For the Rollett-Holm model the following equation is used. - - - - - - - - - - - - - - - - - - - - - - - - - Simulated evolution of the dislocation density as the stored - (elastic) energy assumed stored in each grain. - - - - Which type of recovery model. - - - - - - - - - Simulated reduction of the grain boundary speed due to - the presence of dispersoids through which the total grain boundary - area of the recrystallization front can be reduced. - - - - Which type of drag model. - - - - - - - - - - - - Support point of the linearized curve of simulated time matching - a specific support point of the average dispersoid radius. - - - - - - - - Support point of the linearized curve of the average dispersoid radius. - - - - - - - - - - Simulated time temperature profile - - - - Support point of the linearized curve of simulated time matching - a specific support point of the temperature. - - - - - - - - Support point of the linearized curve of the temperature. - - - - - - - - - Criteria which enable to stop the simulation in a controlled manner. - Whichever criterion is fulfilled first stops the simulation. - - - - Maximum recrystallized volume fraction. - - - - - Maximum simulated physical time. - - - - - Maximum number of iteration steps. - - - - - - Settings relevant for stable numerical integration. - - - - Maximum fraction equivalent to the migration of the - fastest grain boundary in the system how much a cell - may be consumed in a single iteration. - - - - - Fraction of the total number of cells in the CA which - should initially be allocated for offering cells in the - recrystallization front. - - - - - By how much more times should the already allocated memory - be is increased to offer space for storing states of cells - in the recrystallization front. - - - - - Should the cache for cells in the recrystallization front - be defragmented on-the-fly. - - - - - Heuristic recrystallized volume target values at which - the cache for cells in the recrystallization front - will be defragmented on-the-fly. - - - - - - - - List of recrystallized volume target values at which a - snapshot of the CA state should be exported for. - - - - - - - - - - Perform a statistical analyses of the results as it was - proposed by M. Kühbach (solitary unit model ensemble approach). - - - - - How many independent cellular automaton domains - should be instantiated. - - - - - Into how many time steps should the real time interval be discretized upon - during post-processing the results with the solitary unit modeling approach. - - - - - List of identifier for those domain which should be rendered. - Identifier start from 0. - - - - - - - - - - - diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml deleted file mode 100644 index 5d749ebc95..0000000000 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ /dev/null @@ -1,720 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of boundaries of the bounding box or primitive to domain. - - - - - Number of parameter required for chosen orientation parameterization. - - - - - Number of texture components identified. - - - - - Dimensionality. - - - - - Cardinality. - - - - - Number of active cells in the (recrystallization) front. - - - - - Number of grains in the computer simulation. - - - - - Application definition for storing results of the SCORE cellular automaton. - - The SCORE cellular automaton model for primary recrystallization is an - example of typical materials engineering applications used within the field - of so-called Integral Computational Materials Engineering (ICME) whereby - one can simulate the evolution of microstructures. - - Specifically the SCORE model can be used to simulate the growth of static - recrystallization nuclei. The model is described in the literature: - - * `M. Kühbach et al. <https://doi.org/10.1016/j.actamat.2016.01.068>`_ - * `C. Haase et al. <https://doi.org/10.1016/j.actamat.2015.08.057>`_ - * `M. Diehl et al. <https://doi.org/10.1088/1361-651X/ab51bd>`_ - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this computer simulation. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - - - - - Free-text description about the workflow (analysis/simulation). - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of this application definition rather than write details about the - experiment into this free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the characterization started. - - - - - ISO 8601 time code with local time zone offset to UTC included - when the characterization ended. - - - - - - - - - - Specify if the (characterization) results/data of this instance of an - application definition are based on the results of a simulation or the - results of a post-processing of measured data to describe a microstructure. - The term microstructure is used to describe the spatial arrangement of - crystal defects inside a sample/specimen without demanding necessarily - that this structure is mainly at the micron length scale. - Nanostructure and macrostructure are close synonyms. - Material architecture is a narrow synonym. - - - - - - - - - - The path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the SCORE executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - Contact information and eventually details of at least one person - involved in creating this result. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service - should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - - Descriptive name or ideally (globally) unique persistent identifier. - - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - Container to hold different coordinate systems conventions. - A least a right-handed Cartesian coordinate system with base vectors - named x, y, and z has to be specified. Each base vector of the - coordinate system should be described with an NXtransformations instance. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The simulated or characterized material volume element aka domain. - At least one instance of geometry required either NXcg_grid, - NXcg_polyhedron, or NXcg_point. This geometry group needs - to contain details about the boundary conditions. - - - - - - - - - - - - - A tight bounding box or sphere or bounding primitive about the grid. - - - - - How many distinct boundaries are distinguished? - Most grids discretize a cubic or cuboidal region. In this case - six sides can be distinguished, each making an own boundary. - - - - - Name of the boundaries. E.g. left, right, front, back, bottom, top, - The field must have as many entries as there are number_of_boundaries. - - - - - The boundary conditions for each boundary: - - 0 - undefined - 1 - open - 2 - periodic - 3 - mirror - 4 - von Neumann - 5 - Dirichlet - - - - - - - - - Collection of microstructural data observed/simulated. - - - - Integer which specifies the first index to be used for distinguishing - snapshots. Identifiers are defined either implicitly or explicitly. - For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate - if the identifiers are expected to start from 1 (referred to as - Fortran-/Matlab-) or from 0 (referred to as C-, Python-style index - notation) respectively. - - - - - - Summary quantities which are the result of some post-processing of - the snapshot data (averaging, integrating, interpolating). - Frequently used descriptors from continuum mechanics and thermodynamics - can be used here. A few examples are given. Each descriptor is currently - modelled as an instance of an NXprocess because it is relevant to - understand how the descriptors are computed. - - - - Evolution of the physical time. - - - - - Evolution of the simulated temperature over time. - - - - - - Evolution of the recrystallized volume fraction over time. - - - - - - - - Measured or simulated physical time stamp for this snapshot. - Not to be confused with wall-clock timing or profiling data. - - - - - Simulated temperature. - - - - - Iteration or increment counter. - - - - - - - Grain identifier for each cell. - - - - - - - - - - Identifier of the OpenMP thread which processed this part of the grid. - - - - - - - - - - - - Details about those cells which in this time step represent - the discretized recrystallization front. - - - - Which cells are currently in a halo region of threads. - - - - - - - - So-called mobility weight which is a scaling factor to - control the mobility of the grain boundary which is assumed - to sweep currently this volume. - - - - - - - - Grid coordinates of each cell in the recrystallization front. - - - - - - - - - Grain identifier assigned to each cell in the recrystallization front. - - - - - - - - Grain identifier assigned to each nucleus which affected that cell in the - recrystallization front. - - - - - - - - Relative volume transformed as a measure of infection progress. - - - - - - - - Identifier of the OpenMP thread processing each cell in the recrystallization - front. - - - - - - - - Hint about the direction from which the cell was infected. - - - - - - - - - Current grain-related quantities. - - - - Bunge-Euler angle triplets for each grain. - - - - - - - - - Discrete volume of each grain accounting also for partially - transformed cells. - - - - - - - - Current value for the dislocation density as a measure of - the remaining stored energy in assumed crystal defects inside - each grain. The difference between these values scales the - driving force of grain boundary migration. - - - - - - - - Is the grain deformed. - - - - - - - - Is the grain recrystallized. - - - - - - - - - Current recrystallized volume fraction. - - - - Currently evaluated actual recrystallized volume fraction. - This takes into account partially recrystallized cells. - - - - - Currently desired target recrystallized volume fraction at - which the user requested to log a snapshot. - - - - - - - - Currently assumed globally applied Cauchy stress tensor on the ROI. - - - - - - - - - - - Currently assumed globally applied Cauchy strain tensor on the ROI. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/NXms_snapshot.nxdl.xml b/contributed_definitions/NXms_snapshot.nxdl.xml deleted file mode 100644 index 1f922e281b..0000000000 --- a/contributed_definitions/NXms_snapshot.nxdl.xml +++ /dev/null @@ -1,54 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Base class for data on the state of the microstructure at a given - time/iteration. - - - - Is this time for a measurement or a simulation. - - - - - - - - - Measured or simulated physical time stamp for this snapshot. - Not to be confused with wall-clock timing or profiling data. - - - - - Iteration or increment counter. - - - diff --git a/contributed_definitions/NXms_snapshot_set.nxdl.xml b/contributed_definitions/NXms_snapshot_set.nxdl.xml deleted file mode 100644 index 6cff36cc33..0000000000 --- a/contributed_definitions/NXms_snapshot_set.nxdl.xml +++ /dev/null @@ -1,62 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - A collection of spatiotemporal microstructure data. - - - - Is this set describing a measurement or a simulation? - - - - - - - - - Integer which specifies the first index to be used for distinguishing - snapshots. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - - diff --git a/contributed_definitions/NXpolarizer_opt.nxdl.xml b/contributed_definitions/NXoptical_polarizer.nxdl.xml similarity index 57% rename from contributed_definitions/NXpolarizer_opt.nxdl.xml rename to contributed_definitions/NXoptical_polarizer.nxdl.xml index 9142ae4817..5d4b59f88c 100644 --- a/contributed_definitions/NXpolarizer_opt.nxdl.xml +++ b/contributed_definitions/NXoptical_polarizer.nxdl.xml @@ -23,30 +23,30 @@ --> - + - Size of the wavelength array for which the refractive index of the material - and/or coating is given. + Size of the wavelength array for which the refractive index of the material + and/or coating is given. - Size of the wavelength array for which the reflectance or transmission of - the polarizer is given. + Size of the wavelength array for which the reflectance or transmission of + the polarizer is given. - An optical polarizer. - - Information on the properties of polarizer is provided e.g. - [here](https://www.rp-photonics.com/polarizers.html). + An optical polarizer. + + Information on the properties of polarizer is provided e.g. + [here](https://www.rp-photonics.com/polarizers.html). - Type of the polarizer (e.g. dichroic, linear, circular etc.) + Type of the polarizer (e.g. dichroic, linear, circular etc.) @@ -67,17 +67,17 @@ - If you selected 'other' in type specify what it is. + If you selected 'other' in type specify what it is. - Angle of the polarizer. + Angle of the polarizer. - Acceptance angle of the polarizer (range). + Acceptance angle of the polarizer (range). @@ -85,53 +85,47 @@ - Describe the geometry (shape, dimension etc.) of the device. - Specify the dimensions in 'SHAPE/size'. A sketch of the device should be - provided in the 'sketch(NXdata)' field to clarify (i) the shape and - dimensions of the device, and (ii) the input and outputs (i.e. the - direction of the incoming and outcoming (split) beams). + Describe the geometry (shape, dimension etc.) of the device. + Specify the dimensions in 'SHAPE/size'. A sketch of the device should be + provided in the 'sketch(NXdata)' field to clarify (i) the shape and + dimensions of the device, and (ii) the input and outputs (i.e. the + direction of the incoming and outcoming (split) beams). - Describe the shape (plate, cube, wedged, prism etc.). + Describe the shape (plate, cube, wedged, prism etc.). - + - - - - If you chose 'other' in 'shape' describe what it is. - - - Sketch of thedevice showing its geometry. The paths of the - incoming and outgoing beam should be illustrated and labelled (0 for - the incoming beam, and 1, 2,..., N_outputs for the outputs). + Sketch of thedevice showing its geometry. The paths of the + incoming and outgoing beam should be illustrated and labelled (0 for + the incoming beam, and 1, 2,..., N_outputs for the outputs). - Physical extent of the device. The device might be made up of one or - more objects (NX_objects). The meaning and location of the axes used - will vary according to the value of the 'shape' variable. 'N_shapepar' - defines how many parameters: - - * For 'cube' the parameters are (width, length). - * For 'cylinder' the parameters are (diameter, length). - * For 'plate' the parameters are (width, height, length). - * For 'prism' the parameters are (width, height, length). - * For 'wedged' the parameters are (width, height, shortest length). - The wedge angle should be provided in 'SHAPE/wedge_angle'. - * For 'other' the parameters may be (A, B, C, ...) with the labels - defined in the sketch plotted in 'SHAPE/sketch'. + Physical extent of the device. The device might be made up of one or + more objects (NX_objects). The meaning and location of the axes used + will vary according to the value of the 'shape' variable. 'N_shapepar' + defines how many parameters: + + * For 'cube' the parameters are (width, length). + * For 'cylinder' the parameters are (diameter, length). + * For 'plate' the parameters are (width, height, length). + * For 'prism' the parameters are (width, height, length). + * For 'wedged' the parameters are (width, height, shortest length). + The wedge angle should be provided in 'SHAPE/wedge_angle'. + * For 'other' the parameters may be (A, B, C, ...) with the labels + defined in the sketch plotted in 'SHAPE/sketch'. @@ -140,14 +134,14 @@ - Wedge angle if 'shape' is 'wedged'. + Wedge angle if 'shape' is 'wedged'. - Wavelength range for which the polarizer is designed. Enter the minimum - and maximum wavelength (lower and upper limit) of the range. + Wavelength range for which the polarizer is designed. Enter the minimum + and maximum wavelength (lower and upper limit) of the range. @@ -155,23 +149,23 @@ - Properties of the substrate material of the polarizer. If the device has - a coating specify the coating material and its properties in 'coating'. + Properties of the substrate material of the polarizer. If the device has + a coating specify the coating material and its properties in 'coating'. - Specify the substrate material of the polarizer. + Specify the substrate material of the polarizer. - Thickness of the polarizer substrate. + Thickness of the polarizer substrate. - Complex index of refraction of the polarizer material. Specify at given - spectral values (wavelength, energy, wavenumber etc.). + Complex index of refraction of the polarizer material. Specify at given + spectral values (wavelength, energy, wavenumber etc.). @@ -183,32 +177,32 @@ - If the device has a coating describe the material and its properties. - Some basic information can be found e.g. [here] - (https://www.opto-e.com/basics/reflection-transmission-and-coatings). - If the back and front side of the polarizer are coated with different - materials, you may define two coatings (e.g. COATING1 and COATING2). + If the device has a coating describe the material and its properties. + Some basic information can be found e.g. [here] + (https://www.opto-e.com/basics/reflection-transmission-and-coatings). + If the back and front side of the polarizer are coated with different + materials, you may define two coatings (e.g. COATING1 and COATING2). - Specify the coating type (e.g. dielectric, anti-reflection (AR), - multilayer coating etc.). + Specify the coating type (e.g. dielectric, anti-reflection (AR), + multilayer coating etc.). - Describe the coating material (e.g. MgF2). + Describe the coating material (e.g. MgF2). - Thickness of the coating. + Thickness of the coating. - Complex index of refraction of the coating. Specify at given spectral - values (wavelength, energy, wavenumber etc.). + Complex index of refraction of the coating. Specify at given spectral + values (wavelength, energy, wavenumber etc.). @@ -218,7 +212,7 @@ the device has different coatings on the front and back side.--> - Extinction ratio (maximum to minimum transmission). + Extinction ratio (maximum to minimum transmission). @@ -226,7 +220,7 @@ the device has different coatings on the front and back side.--> - Reflection of the polarizer at given wavelength values. + Reflection of the polarizer at given wavelength values. @@ -234,11 +228,10 @@ the device has different coatings on the front and back side.--> - Transmission of the polarizer at given wavelength values. + Transmission of the polarizer at given wavelength values. - diff --git a/contributed_definitions/NXorientation_set.nxdl.xml b/contributed_definitions/NXorientation_set.nxdl.xml deleted file mode 100644 index 73f5e3ca0c..0000000000 --- a/contributed_definitions/NXorientation_set.nxdl.xml +++ /dev/null @@ -1,133 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the reference space/coordinate system. - - - - - The cardinality of the set, i.e. the number of orientations. - - - - - Number of parameters for the chosen parameterization. - - - - - Details about individual orientations of a set of objects. - - For a more detailed insight into the discussion of parameterizing - orientations in materials science see: - - * https://doi.org/10.1016/j.matchar.2016.04.008 - * https://doi.org/10.1088/0965-0393/23/8/083501 - * https://doi.org/10.1007/978-3-662-09156-2 group-theory of rotations - * https://doi.org/10.1016/C2013-0-11769-2 the classical book of H.-J. Bunge - - - - - Reference to or definition of a coordinate system with - which the definitions are interpretable. - - - - - - - - - - - - A link or reference to the objects whose identifier are referred to in - identifier to resolve which row tuple is the orientation of each object - by reading orientations. - - - - - Integer which specifies which orientation (row of array orientation) matches - to which object.e first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish how a row in orientation describes a specific - object with an explicit identifier that can be queried via inspecting the - list of available objects in objects. - - The rational behind having such a more complicated pattern is that not - all objects referred when following the link in objects may still exists - or are still tracked when the orientation set was characterized. - - This design enables to also use NXorientation_set in situations where - the orientation of objects change as a function in time. - - - - - - - - Parameterized orientations. - - - - - - - - - diff --git a/contributed_definitions/NXpositioner_sts.nxdl.xml b/contributed_definitions/NXpositioner_sts.nxdl.xml deleted file mode 100644 index 7d13592b97..0000000000 --- a/contributed_definitions/NXpositioner_sts.nxdl.xml +++ /dev/null @@ -1,310 +0,0 @@ - - - - - - A generic positioner such as a motor or piezo-electric transducer. - - - - symbolic or mnemonic name (one word) - - - - - description of positioner - - - - - best known value of positioner - need [n] as may be scanned - - - - - - - - raw value of positioner - need [n] as may be scanned - - - - - - - - targeted (commanded) value of positioner - need [n] as may be scanned - - - - - - - - maximum allowable difference between target_value and value - - - - - - - - minimum allowed limit to set value - - - - - maximum allowed limit to set value - - - - - velocity of the positioner (distance moved per unit time) - - - - - time to ramp the velocity up to full speed - - - - - Hardware device record, e.g. EPICS process variable, taco/tango ... - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - - - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a positioner. - - - - - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - - - - - To clarify the frame laboratory frame. The scanning area in x, y, and z position in the - frame. - - - - - This controllers task is to continuously adjust the Z position of the stm tip in order - to keep the selected control signal as close as possible to the Set Point. Different control - signals lead to different contronller beahvior. - - - - - Offset added to the initial averaged position Zaver before starting to swepp. - - - - - Indicate the tip position Z between tip and sample. The tip position can also be varied when - the controller is not running. - - - - - Controller name. This name which will be displayed at places where you can select a - controller. - - - - - Set Point is the desired value of the control signal. It can be set by editing the number - or using the slider bar. Click the "Set" button above the input field to use the actual - value as Set Point. The slider shows the Set Point as well as the current value. - - - - - Lifts the tip by the specified amount when then controller is switched off. This can be - a positive or a negative number, i.e. the tip can also be moved towards the sample. Be - careful with sign and value when using this feature. - - - - - Use this parameter for a reproducible position when switching off the Z-controller. - When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues - to run for the specified time and averages the Z position. - - - - - (In bias spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) during - the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters - are disabled. - - - - - The final z-position during the bias spectroscopy scan. The availability of values is - related to the mode of scanning. - - - - - - Configure the scan frame like x position; y position; width; height. - - - - - Scan resolution by setting the Lines equal to Pixels. - - - - - Define the image resolution. - - - - - Define the scan forward speed in the forward direction. - - - - - Define the scan backward speed in the forward direction. - - - - - Piezo calibration module is used to define the X Y Z piezos calibration. - - - - - The name of caliberation type. - - - - - - - The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and :math:`P/T` - (proportional gain/time constant). The formula for the controller in the frequency domain is: - :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. - The integral gain and time constant are related as follows: :math:`I = P/T`. - - - - - The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and - P/T (proportional gain/time constant). The formula for the controller in the frequency - domain is: :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. The integral gain and time constant are related - as follows: `:math:I = P/T`. - - - - - The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and - :math:`P/T` (proportional gain/time constant). The formula for the controller in the frequency - domain is: :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. The integral gain and time constant are related - as follows: :math:`I = P/T`. - - - - - - There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order - piezo characteristics to compensate for it. The following equation shows the interpretation - of the 2nd order correction parameter: For the X-piezo: - :math:`Ux = 1/cx · X + cxx · X2`; with units: :math:`[V] = [V/m] · [m] + [V/m2] · [m2]` - where cx is the calibration of the piezo X and cxx is the 2nd order correction. :math:`(V/m^2)` - - - - - There are 2 parameters in X and Y directions. Define the drift speed for all three axes. - When the compensation is on, the piezos will start to move at that speed. - - - - - Use the button to turn on/off the drift compensation. - - - diff --git a/contributed_definitions/NXsensor_sts.nxdl.xml b/contributed_definitions/NXsensor_sts.nxdl.xml deleted file mode 100644 index 31094bd4e1..0000000000 --- a/contributed_definitions/NXsensor_sts.nxdl.xml +++ /dev/null @@ -1,233 +0,0 @@ - - - - - - A sensor used to monitor an external condition - - The condition itself is described in :ref:`NXenvironment`. - - - - Sensor identification code/model number - - - - - Name for the sensor - - - - - Short name of sensor used e.g. on monitor display program - - - - - where sensor is attached to ("sample" | "can") - - - - - Defines the axes for logged vector quantities if they are not the global - instrument axes. - - - - - name for measured signal - - - - - - - - - - - - - - - - - - - - - The type of hardware used for the measurement. - Examples (suggestions but not restrictions): - - :Temperature: - J | K | T | E | R | S | Pt100 | Pt1000 | Rh/Fe - :pH: - Hg/Hg2Cl2 | Ag/AgCl | ISFET - :Ion selective electrode: - specify species; e.g. Ca2+ - :Magnetic field: - Hall - :Surface pressure: - wilhelmy plate - - - - - - link to second amplifer circuit with 1MOhm - - - - - Is data collection controlled or synchronised to this quantity: - 1=no, 0=to "value", 1=to "value_deriv1", etc. - - - - - Upper control bound of sensor reading if using run_control - - - - - Lower control bound of sensor reading if using run_control - - - - - nominal setpoint or average value - - need [n] as may be a vector - - - - - - - - Nominal/average first derivative of value - e.g. strain rate - - same dimensions as "value" (may be a vector) - - - - - - - - Nominal/average second derivative of value - - same dimensions as "value" (may be a vector) - - - - - - - - Time history of sensor readings - - - - - Time history of first derivative of sensor readings - - - - - Time history of second derivative of sensor readings - - - - - - - - - - - - - - - For complex external fields not satisfied by External_field_brief - - - - - This group describes the shape of the sensor when necessary. - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - - - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a sensor. - - - - - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - - - - - External sensors connected to the device. For example, T1, temperature of STM - head. T2, temperature of bottom of LHe helium cryostat. T3, temperature of LN2 - nitrogen shield. - - - - - External sensors connected to the device. Pressure of each chamber or ion pump, - such as prepare chamber and analysis chamber - - - - - The power present in the signal as a function of frequency. Used to characterise - the vibration and noise of scanning probes to detect and reduce the impact on - resolution during STM imaging - - - diff --git a/contributed_definitions/NXslip_system_set.nxdl.xml b/contributed_definitions/NXslip_system_set.nxdl.xml deleted file mode 100644 index 8fafee2e41..0000000000 --- a/contributed_definitions/NXslip_system_set.nxdl.xml +++ /dev/null @@ -1,85 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of slip systems. - - - - - Base class for describing a set of crystallographic slip systems. - - - - - - - - - - - - - - - - - - Array of Miller indices which describe the crystallographic plane. - - - - - - - - - - Array of Miller indices which describe the crystallographic direction. - - - - - - - - - For each slip system a marker whether the specified Miller indices - refer to the specific slip system or the set of crystallographic equivalent - slip systems of the respective family of slip systems. - - - - - - diff --git a/contributed_definitions/NXsolid_geometry.nxdl.xml b/contributed_definitions/NXsolid_geometry.nxdl.xml deleted file mode 100644 index fb5751f268..0000000000 --- a/contributed_definitions/NXsolid_geometry.nxdl.xml +++ /dev/null @@ -1,56 +0,0 @@ - - - - - - the head node for constructively defined geometry - - - - Instances of :ref:`NXquadric` making up elements of the geometry. - - - - - Instances of :ref:`NXoff_geometry` making up elements of the geometry. - - - - - The geometries defined, made up of instances of :ref:`NXquadric` and :ref:`NXoff_geometry`. - - - diff --git a/contributed_definitions/NXsts.nxdl.xml b/contributed_definitions/NXsts.nxdl.xml deleted file mode 100644 index f13d5a90cb..0000000000 --- a/contributed_definitions/NXsts.nxdl.xml +++ /dev/null @@ -1,995 +0,0 @@ - - - - - - - - - - Application definition for temperature-dependent IV curve measurements - #2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the - STM image mode in the future with a focus on bias spectroscopy in Scanning Tunneling Microscopy. - - In this application definition, times should be specified always together with a UTC offset. - - This is the application definition describing temperature (T) dependent current voltage (IV) curve - measurements. For this, a temperature is set. After reaching the temperature, a voltage sweep - is performed. For each voltage, a current is measured. - Then, the next desired temperature is set and an IV measurement is performed. - The data can be visualized in a tensor with: - I (NXsensor_C, NXsoftware_Read_offset, NXcircuit) - parameters: - V has (NXsource+offset, NXsoftware_Scan_offset, NXsensor_V, NXcircuit) - T has (NXsource, NXsoftware_Scan_offset, NXsensor_T) - x has (NXsoftware_Scan_offset) - y has (NXsoftware_Scan_offset) - z has (NXsoftware_Scan_offset) - - - - - - - - - - Name of the experiment where the application is applicable. - - - - - - - - - The equipments and techniques as well as the parameter settings and reference signals - are used during the experiments used in Scanning Tunneling Microscopy (STM). - - - - - - - - - - - The name of the output file, with the number of scans at the end. (e.g. - 221122_Au_5K00014) - - - - - The name of the series output file, which represents only the public part of the - output file. (e.g. 221122_Au_5K) - - - - - Path to storage of output files. - (e.g. Path C:\Users\SPM-PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis-Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711) - - - - - Descriptive comments for this experiment, added by the experimenter, coming from the - output file. (e.g. Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, locked Au(111), - 50pA, 100 mV set point, 1mV DCA, 973Hz,138 1st H, -84 2nd H) - - - - - - Hardware type used in SPM experiment, includes hardware manufacturers and type. - (e.g. Nanonis BP5e) - - - - - - Type of software used in SPM experiments, such as software version serial number, UI and - RT probe release method. (e.g. SW Version Generic 5e -- RT Release 10771) - - - - - - The Amplifier description that improves or helps to determine tunnel current (current - between tip and bias). - - - - - - - Status of Lock-in device whether while performing the experiment - - - - - - This is the signal on which the modulation (sine) will be added. - - - - - - - The signal is modulated by adding the frequency of the sine modulation. The - modulation frequency spans can be from 10 mHz to 40 kHz, corresponding to the output filter - cut-off range. When dealing with harmonics, it's essential to ensure that the - harmonic frequencies remain below ~100 kHz, which aligns with the input filter cut-off. - Be mindful that hardware filters might impact the amplitude as the signal approaches - their cut-off frequencies." (e.g. 973E+0) - - - - - - The amplitude (in physical units of modulated signal) of the sine modulation. - - - - - - The input signal (STS signal) will be demodulated, in order to determine the amplitude - and phase at the frequency set in the Frequency field or harmonics, such as current, - bias, et.al. - - - - - - N denotes 1 or 2. The order of the harmonic oscillation to be detected in the demodulated - signal should be considered relative to the modulation frequency. When dealing with - higher harmonics, it's essential to ensure that their frequencies do not surpass - the analogue signal bandwidth (e.g. harmonic_order_1). - - - - - - Reference phase for the sine on the demodulated signal with respect to the - modulation signal. The determined phase is displayed with respect to the - reference phase. - - - - - - - - Bias voltage applied to the sample. - - - - Applied a voltage between tip and sample. - - - - - - - - - Temperature of STM head. Note: At least one field from stm_head_temperature, - cryo_bottom_temp and cryo_sheild_temp must be provided. - - - - - Temperature of liquid helium cryostat. Note: At least one field from - stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp must be provided. - - - - - Temperature of liquid nitrogen shield. Temperature 3 (K) (e.g 78.00000E+0). Note: At - least one field from stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp - must be provided. - - - - - - - Configuration for piezoelectric scanner used to move tip along X and Y direction. The - material of the Piezoelectric scanner composed of polycrystalline solids and sensitive to - applied voltage. - - - - The name of calibration type. (e.g. LHe) - - - - - N denotes X or Y or Z. There are three parameters in the X, Y, and Z directions, - along with three available controls: Calibration (m/V), Range (m), and HV gain. Only - two of these parameters are required to define the calibration. Consequently, when any - value is changed, one of the other values will be automatically updated. (e.g. calib_X = 3.8E-9) - - - - - N denotes X or Y or Z. In some systems, there is an HV gain readout feature. For - these systems, the HV gain should be automatically adjusted whenever the gain is - changed at the high voltage amplifier. (e.g. 14.5) - - - - - - N denotes X or Y. There are 2 parameters in X and Y directions, and tilt needs to be - adjusted according to the actual surface. (in degrees, first order correction). - - - - - - N denotes X or Y. There are 2 parameters in X and Y directions. (can be set - approximately to the length of the piezotube). - - - - - N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, - you can enter the 2nd order piezo characteristics to compensate for it. The - following equation shows the interpretation of the 2nd order correction parameter: - For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: - [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx - is the 2nd order correction. (V/m^2). (e.g. 0E+0) - - - - - N denotes X, Y or Z. There are 3 parameters in X, Y and Z directions. Define the - drift speed for all three axes. When the compensation is on, the piezos will start to - move at that speed. (e.g. 0E+0) - - - - - Use the button to enable or disable the drift compensation. (e.g. FALSE) - - - - - - An environmental setup to measure the tunneling current due to different tip- - sample biases. - - - - - This is set-point of tip current (in the constant current mode should be equal to set-point, - in the constant height mode means the real tunnelling current between tip and sample). - - - - - Value of calibration that comes as A/V. The value for this concept can be read - as current per unit voltage. - - - - - - - - - - Clarify the frame laboratory frame. - - - - The scanning area in x position in the frame. (e.g. -890.53E-12) - - - - - The scanning area in y position in the frame. (e.g. 29.6968E-9) - - - - - The scanning area in z position in the frame. (e.g. 130.5E-9) - - - - - - Indicate the relative tip position z between tip and sample. The tip position can also - be varied when the z_controller is not running. (e.g. 130.5E-9) - - - - - - - - - - Time during which the spectroscopy data are acquired and averaged. (e.g. 150E-6) - - - - - Number of sweeps to measure and average. (e.g. 100) - - - - - The start bias values of the sweep. (e.g. -300E-3) - - - - - The end bias values of the sweep. (e.g. 300E-3) - - - - - The sweep number of points is defined as the maximum spectrum resolution, which - is equal to the bias sweep window divided by the number of pixels. (e.g. 4096) - - - - - The Z position is recorded and averaged for a certain duration both before and - after the sweep. After the initial Z averaging time, if "Z-Controller to Hold" - is selected, the Z-Controller is set to hold mode, and the tip is positioned at - the previously averaged Z position (adjusted by the Z offset). (e.g. 100E-3) - - - - - - - The bandwidth of the Hardware and/or Software is instrument specific. - For example, Nanonis Generic 5 has 'RT Frequency' (e.g. 20E+3). - - - - - The Signals Period represents the rate at which signals are transferred to - the host computer, which operates the control software. This rate may - be 10 times lower than the sampling rate, as the real-time engine internally - oversamples the signal. If desired, you may have the option to reduce the oversampling - to 1, enabling higher frequency resolution in the Spectrum Analyzer. (e.g. 10) - - - - - The update rate is utilized in various processes, including the History Graph, - Auto-Approach, and multiple Programming Interface functions. It may be - configured to a 20 ms interval. Any additional timings must strictly be integer - multiples of this base value. While it is possible to set these additional - timings to different values, the actual timing value will automatically be - adjusted to become a multiple of the Acquisition Period. (e.g. 20E-3) - - - - - The update rate of animated graphical indicators, such as graphs and sliders, - can be adjusted. A normal value may be 40 ms, which corresponds to 25 updates - per second. Increasing this period can help reduce the processor load on the - graphical user interface, particularly on slower computers. It is important to - note that this update rate solely impacts the user interface and does not affect - measurements in any manner. (e.g. 20E-3) - - - - - The update rate of digital indicators, such as the numbers displayed, can be set - to 3 updates per second, equivalent to 300 ms. This interval is sufficient for - the user interface and does not impact measurements in any manner. (e.g. 300E-3) - - - - - The Measurements period determines the integration time required for precise - measurements, primarily utilized in sweep modules. It is particularly useful for - tasks such as recording force-distance curves or cantilever resonances. For - swift measurements with small steps, a value of 40 ms is often adequate. For - regular use, a range of 300-500 ms may be recommended, but when capturing the - resonance of a high-Q cantilever, longer values in the range of several seconds - might be necessary. Usually, this parameter does not require manual adjustment - within this module, as the sweep modules automatically set this value according - to the sweep timings. (e.g. 500E-3) - - - - - - - - - In STM experiment, the scan range is the coordinate (x,y) along the X and Y axis from the origin (scan_offset) of - the scan area (e.g. 5.000000E-9 5.000000E-9). - - - - - In STM experiment, the scan offset is the position of the tip at the starting point of scan area. - (e.g. -2.354637E-7 1.267476E-) - - - - - In STM experiment, the scan direction is the direction from which side of the - sample the tip starts scanning. - - - - - - - - - - - The angle of scan with the bottom or top side (depends on the scan_direction - field) of the sample. (e.g. 0.000E+0). - - - - - - Also clarify the frame for the ROI of the scan in lab frame, the middle of the lab - frame is (0, 0), and positive in x means right and in y means up. - - - - - - - The scan channels are selected by users. (e.g. (A);Bias (V);Z (m);LI Demod 2 X - (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A)) - - - - - - - Configure the scan frame like x position; y position; width; height. (e.g. - 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0). If the 'scanfield' is not considered, use - the 'scan_range' and 'scan_offset' from 'scan_control' group - - - - - Scan resolution by setting the Lines equal to Pixels. (e.g. 512) - - - - - Define the image resolution. (e.g. 512) - - - - - Define the scan forward speed in the forward direction. (m/s) (e.g. 11.7187E-9) - - - - - Define the scan backward speed in the forward direction. (m/s) (e.g. 11.7187E-9) - - - - - - - - - - - - Link to target: /NXentry/NXinstrument/stm_head_temp - - - - - - Link to target: /NXentry/NXinstrument/cryo_bottom_temp - - - - - - Link to target: /NXentry/NXinstrument/temp_cryo_shield - - - - - - Link to target: /NXentry/NXinstrument/NXlock_in/modulation_signal - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/NXintegration_time - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/number_of_sweeps - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/sweep_start - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/sweep_end - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/num_pixel - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_avg_time - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/rt_frequency - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/signals_oversampling - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/acquisition_period - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/animations_period - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/indicators_period - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/measurements_period - - - - - - - - - Link to target: /NXentry/NXinstrument/NXsample_bias/bias - - - - - - Link to target: /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current - - - - - - Link to target: /NXentry/NXnstrument/NXsample_bias/bias_calibration - - - - - Link to target: /NXentry/NXinstrument/NXsample_bias/bias_offset - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_calibration - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_offset - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_gain - - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_offset - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/settling_time - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_ccontroller_hold - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/record_final_z - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/first_settling_time - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/end_settling_time - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_control_time - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/max_slew_rate - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/backward_sweep - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/controller_name - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/controller_status - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/set_point - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/p_gain - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/i_gain - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/time_const - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/tip_lift - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/switchoff_delay - - - - - - This describes the sample and its properties, as well as constraints that are - applied to the sample before scanning. - - - - At this moment no base class available that can track entire sample preparation. - - - - - - - This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. - There should also be two more fields called temperature and voltage containing the setpoint values. - There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension - equal to the number of voltage setpoints. - axes: bias_calc - signals: - li_demod_[1;2]_[X/Y]_[-;bwd;filt;bwd_filt] - current_[-;bwd;filt;bwd_filt] - temperature - - - - - - Plot for a single point (x,y) with I vs. V curve. - - - - - - Line scan with multiple I vs. V curves for different single (x,y) co-ordinates. - - - - - - Plot for current(I) curve in the 2D space of (position(x), bias(V)) which can be - derived from the `line_scan` plot. - - - - - - Mesh scan with 2D slices of the above alternative plot for other y co-ordinates. - - - - From e8e9d9425e1f4ab429a9e8ca7f44a9c14f2804ab Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 28 Aug 2025 09:22:52 +0200 Subject: [PATCH 0981/1012] bring in latest NXxrd from fairmat repo --- contributed_definitions/NXxrd.nxdl.xml | 38 +++--- contributed_definitions/NXxrd_pan.nxdl.xml | 144 ++++++++++----------- 2 files changed, 91 insertions(+), 91 deletions(-) diff --git a/contributed_definitions/NXxrd.nxdl.xml b/contributed_definitions/NXxrd.nxdl.xml index c534d8194e..626a13840d 100644 --- a/contributed_definitions/NXxrd.nxdl.xml +++ b/contributed_definitions/NXxrd.nxdl.xml @@ -1,9 +1,9 @@ - + - NXxrd on top of NXmonopd + NXxrd on top of NXmonopd - Official NeXus NXDL schema to which this file conforms + Official NeXus NXDL schema to which this file conforms @@ -44,15 +44,15 @@ - raw detector signal (usually counts) as colected - it can be a multi-dimensional dataset depending on - the detector type (faster axes) and - the scanning method (slower axes) + raw detector signal (usually counts) as collected + it can be a multi-dimensional dataset depending on + the detector type (faster axes) and + the scanning method (slower axes) - The 2-theta range of the difractogram + The 2-theta range of the diffractogram @@ -68,8 +68,8 @@ - link (suggested target:/NXentry/NXinstrument/NXdetector/polar_angle) - Link to ponglar ale in /NXentry/NXinstrument/NXdetector + link (suggested target:/NXentry/NXinstrument/NXdetector/polar_angle) + Link to polar ale in /NXentry/NXinstrument/NXdetector @@ -77,8 +77,8 @@ - link (suggested target:/NXentry/NXinstrument/NXdetector/data) - Link to data in /Nxentry/Nxinstrument/Nxdetector + link (suggested target:/NXentry/NXinstrument/NXdetector/data) + Link to data in /Nxentry/Nxinstrument/Nxdetector @@ -87,12 +87,12 @@ - Description of a processing or analysis step, such as the - baseline extraction or azimuth integration. - Add additional fields as needed to describe value(s) of - any variable, parameter, or term related to - the NXprocess step. Be sure to include units attributes - for all numerical fields. + Description of a processing or analysis step, such as the + baseline extraction or azimuth integration. + Add additional fields as needed to describe value(s) of + any variable, parameter, or term related to + the NXprocess step. Be sure to include units attributes + for all numerical fields. diff --git a/contributed_definitions/NXxrd_pan.nxdl.xml b/contributed_definitions/NXxrd_pan.nxdl.xml index 4918e4ef4f..a406ba60a5 100644 --- a/contributed_definitions/NXxrd_pan.nxdl.xml +++ b/contributed_definitions/NXxrd_pan.nxdl.xml @@ -1,9 +1,9 @@ - + - NXxrd_pan is a specialisation of NXxrd with extra properties - for the PANalytical XRD data format. + NXxrd_pan is a specialization of NXxrd with extra properties + for the PANalytical XRD data format. - Name of the data file. + Name of the data file. - Type of measurement. + Type of measurement. - Official NeXus NXDL schema to which this file conforms. + Official NeXus NXDL schema to which this file conforms. @@ -47,10 +47,10 @@ - Method used to collect the data - default='X-Ray Diffraction (XRD)' + Method used to collect the data + default='X-Ray Diffraction (XRD)' - + @@ -59,9 +59,9 @@ - Type of the X-ray tube. + Type of the X-ray tube. - + @@ -73,70 +73,70 @@ - Current of the X-ray tube. + Current of the X-ray tube. - Voltage of the X-ray tube. + Voltage of the X-ray tube. - Wavelength of the K\u03b1 1 line. + Wavelength of the K\u03b1 1 line. - + - Wavelength of the K\u03b1 2 line. + Wavelength of the K\u03b1 2 line. - + - K\u03b1 2/K\u03b1 1 intensity ratio. + K\u03b1 2/K\u03b1 1 intensity ratio. - Wavelength of the K\u00df line. + Wavelength of the K\u00df line. - + - Wavelength of the X-ray source. Used to convert from 2-theta to Q. + Wavelength of the X-ray source. Used to convert from 2-theta to Q. - Axis scanned. + Axis scanned. - Mode of scan. + Mode of scan. - Integration time per channel. + Integration time per channel. @@ -147,76 +147,76 @@ incident_beam(NXbeam): defracted_beam(NXbeam):--> - Collect user inputs e.g. name or path of the input file. + Collect user inputs e.g. name or path of the input file. - Starting value of the diffraction angle. + Starting value of the diffraction angle. - Ending value of the diffraction angle. + Ending value of the diffraction angle. - Minimum step size in-between two diffraction angles. + Minimum step size in-between two diffraction angles. - Starting value of the incident angle. + Starting value of the incident angle. - Ending value of the incident angle. + Ending value of the incident angle. - Minimum step size in the between two incident angles. + Minimum step size in the between two incident angles. - Beam attenuation factors over the path. + Beam attenuation factors over the path. - Goniometer position X. + Goniometer position X. - Goniometer position Y. + Goniometer position Y. - Goniometer position Z + Goniometer position Z - Total time of count. + Total time of count. - All experiment results data such as scattering angle (2theta), - intensity, incident angle, scattering vector, etc will be stored here. + All experiment results data such as scattering angle (2theta), + intensity, incident angle, scattering vector, etc will be stored here. - Number of scattered electrons per unit time. + Number of scattered electrons per unit time. @@ -224,7 +224,7 @@ defracted_beam(NXbeam):--> - Two-theta (scattering angle) of the diffractogram. + Two-theta (scattering angle) of the diffractogram. @@ -232,7 +232,7 @@ defracted_beam(NXbeam):--> - Incident angle of the diffractogram. + Incident angle of the diffractogram. @@ -240,7 +240,7 @@ defracted_beam(NXbeam):--> - The phi range of the diffractogram. + The phi range of the diffractogram. @@ -248,7 +248,7 @@ defracted_beam(NXbeam):--> - The chi range of the diffractogram + The chi range of the diffractogram @@ -256,78 +256,78 @@ defracted_beam(NXbeam):--> - The scattering vector component, which is parallel to the sample surface. + The scattering vector component, which is parallel to the sample surface. - The scattering vector component, which is perpendicular to the sample surface. + The scattering vector component, which is perpendicular to the sample surface. - The norm value of the scattering vector, q. The scattering vector is defined as a - difference between the incident and scattered wave vectors. - For details: https://en.wikipedia.org/wiki/Powder_diffraction - and https://theory.labster.com/scattering-vector/ + The norm value of the scattering vector, q. The scattering vector is defined as a + difference between the incident and scattered wave vectors. + For details: https://en.wikipedia.org/wiki/Powder_diffraction + and https://theory.labster.com/scattering-vector/ - The desired view for scattering vectors. + The desired view for scattering vectors. - This concept corresponds to the norm value of the scattering vector(q). - The concept is the same as 'q_norm' of 'experiment_result' - and should be linked to /entry[ENTRY]/experiment_result/q_norm. + This concept corresponds to the norm value of the scattering vector(q). + The concept is the same as 'q_norm' of 'experiment_result' + and should be linked to /entry[ENTRY]/experiment_result/q_norm. - Number of scattered electrons per unit time at each scattering vector (q) value. - The concept is the same as the 'intensity' of experiment_result - and should be linked to /entry[ENTRY]/experiment_result/intensity. + Number of scattered electrons per unit time at each scattering vector (q) value. + The concept is the same as the 'intensity' of experiment_result + and should be linked to /entry[ENTRY]/experiment_result/intensity. - The scattering vector (q) component, which is parallel to the sample surface. - This component is used in the Reciprocal Space Mapping (RSM) technique of - X-ray diffraction method. - - The concept is the same as 'q_parallel' of experiment_result, - and should be linked to /entry[ENTRY]/experiment_result/q_parallel. + The scattering vector (q) component, which is parallel to the sample surface. + This component is used in the Reciprocal Space Mapping (RSM) technique of + X-ray diffraction method. + + The concept is the same as 'q_parallel' of experiment_result, + and should be linked to /entry[ENTRY]/experiment_result/q_parallel. - The scattering vector component, which is perpendicular to the sample surface. - - The concept is the same as 'q_perpendicular' of experiment_result, - and should be linked to /entry[ENTRY]/experiment_result/q_perpendicular. + The scattering vector component, which is perpendicular to the sample surface. + + The concept is the same as 'q_perpendicular' of experiment_result, + and should be linked to /entry[ENTRY]/experiment_result/q_perpendicular. - Description on sample. + Description on sample. - Mode of sample. + Mode of sample. - Id of sample. + Id of sample. - Usually in xrd sample are being analysed, but sample might be identified by - assumed name or given name. + Usually in xrd sample are being analyzed, but sample might be identified by + assumed name or given name. From 9e0b5daaf5f5ba4c78df98c52a53b454e754156c Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 28 Aug 2025 09:26:06 +0200 Subject: [PATCH 0982/1012] bring in changes from fairmat repo --- .../NXsensor_scan.nxdl.xml | 172 +++++++++++------- 1 file changed, 102 insertions(+), 70 deletions(-) diff --git a/contributed_definitions/NXsensor_scan.nxdl.xml b/contributed_definitions/NXsensor_scan.nxdl.xml index 90d4b4fa8b..0a0384363c 100644 --- a/contributed_definitions/NXsensor_scan.nxdl.xml +++ b/contributed_definitions/NXsensor_scan.nxdl.xml @@ -1,9 +1,9 @@ - + - - + + - Length of the spectrum vector (e.g. wavelength or energy) for which the - refractive index of the beam splitter material and/or coating is defined. + Length of the spectrum vector (e.g. wavelength or energy) for which the + refractive index of the beam splitter material and/or coating is defined. - Length of the spectrum vector (e.g. wavelength or energy) for which the - reflectance or transmission of the beam splitter is given. + Length of the spectrum vector (e.g. wavelength or energy) for which the + reflectance or transmission of the beam splitter is given. - Number of parameters needed do descripe the shape of the beam splitter. + Number of parameters needed do describe the shape of the beam splitter. - Number of objects the beam splitter is made up of. + Number of objects the beam splitter is made up of. - Number of outputs, i.e. number of paths the beam takes after being split by - the beam splitter. + Number of outputs, i.e. number of paths the beam takes after being split by + the beam splitter. - A beam splitter, i.e. a device splitting the light into two or more beams. - - Information about types and properties of beam splitters is provided e.g. - [here](https://www.rp-photonics.com/beam_splitters.html). - - Use two or more NXbeam_paths to describe the beam paths after the beam - splitter. In the dependency chain of the new beam paths, the first elements - each point to this beam splitter, as this is the previous element. + A beam splitter, i.e. a device splitting the light into two or more beams. + + Information about types and properties of beam splitters is provided e.g. + [here](https://www.rp-photonics.com/beam_splitters.html). + + Use two or more instances of NXbeam to describe the beam paths after the beam + splitter. In the dependency chain of the new beam paths, the first elements + each point to this beam splitter, as this is the previous element. - Specify the beam splitter type (e.g. dielectric mirror, pellicle, - dichroic mirror etc.). Shape (e.g. prism, plate, cube) and dimension - should be described in 'geometry'. Define if the beam splitter is - polarizing or not in the field 'polarizing(NX_BOOLEAN)'. + Specify the beam splitter type (e.g. dielectric mirror, pellicle, + dichroic mirror etc.). Shape (e.g. prism, plate, cube) and dimension + should be described in 'geometry'. Define if the beam splitter is + polarizing or not in the field 'polarizing(NX_BOOLEAN)'. - + @@ -79,47 +80,40 @@ - + - - - - If you selected 'other' in 'type' use this field to specify which type of - beam splitter was used. - - - Is the beam splitter polarizing? + Is the beam splitter polarizing? - Does the beam splitter have multiple outputs (diffractive optical - element), i.e. more than two outputs? + Does the beam splitter have multiple outputs (diffractive optical + element), i.e. more than two outputs? - Describe the geometry (shape, dimension etc.) of the beam splitter. - Specify the dimensions in 'SHAPE/size'. A sketch of the device should be - provided in the 'sketch(NXdata)' field to clarify (i) the shape and - dimensions of the device, and (ii) the input and outputs (i.e. the - direction of the incoming and outcoming (split) beams). + Describe the geometry (shape, dimension etc.) of the beam splitter. + Specify the dimensions in 'SHAPE/size'. A sketch of the device should be + provided in the 'sketch(NXdata)' field to clarify (i) the shape and + dimensions of the device, and (ii) the input and outputs (i.e. the + direction of the incoming and outcoming (split) beams). - Describe the shape (plate, cube, wedged, prism etc.). + Describe the shape (plate, cube, wedged, prism etc.). - + @@ -128,34 +122,29 @@ in 'substrate/substrate_thickness' and 'coating/coating_thickness'.--> - - - If you chose 'other' in 'shape' describe what it is. - - - Sketch of the beam splitter showing its geometry. The paths of the - incoming and split beam should be illustrated and labelled (0 for the - incoming beam, and 1, 2,..., N_outputs for the outputs (i.e. the split - beam paths)). + Sketch of the beam splitter showing its geometry. The paths of the + incoming and split beam should be illustrated and labelled (0 for the + incoming beam, and 1, 2,..., N_outputs for the outputs (i.e. the split + beam paths)). - Physical extent of the beam splitter device. The beam splitter might be - made up of one or more objects (NX_objects). The meaning and location - of the axes used will vary according to the value of the 'shape' - variable. 'N_shapepar' defines how many parameters: - - * For 'cube' the parameters are (width, length). - * For 'cylinder' the parameters are (diameter, length). - * For 'plate' the parameters are (width, height, length). - * For 'prism' the parameters are (width, height, length). - * For 'wedged' the parameters are (width, height, shortest length). - The wedge angle should be provided in 'SHAPE/wedge_angle'. - * For 'other' the parameters may be (A, B, C, ...) with the labels - defined in the sketch plotted in 'SHAPE/sketch'. + Physical extent of the beam splitter device. The beam splitter might be + made up of one or more objects (NX_objects). The meaning and location + of the axes used will vary according to the value of the 'shape' + variable. 'N_shapepar' defines how many parameters: + + * For 'cube' the parameters are (width, length). + * For 'cylinder' the parameters are (diameter, length). + * For 'plate' the parameters are (width, height, length). + * For 'prism' the parameters are (width, height, length). + * For 'wedged' the parameters are (width, height, shortest length). + The wedge angle should be provided in 'SHAPE/wedge_angle'. + * For 'other' the parameters may be (A, B, C, ...) with the labels + defined in the sketch plotted in 'SHAPE/sketch'. @@ -164,41 +153,41 @@ in 'substrate/substrate_thickness' and 'coating/coating_thickness'.--> - Wedge angle if 'shape' is 'wedged'. + Wedge angle if 'shape' is 'wedged'. +doc: | +Specify the length of the beam splitter. If the device has a wedged +shape provide the minimum and maximum length of the device. +Otherwise, if the beam splitter has a homogeneous thickness, the two +values are equal. +dimensions: +rank: 1 +dim: [[1,2]]--> - Beam splitting ratio(s) for the various outputs (i.e. the - paths of the beam after being split by the beam splitter). - The order of the ratios must be consistent with the labels - 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting with 1. + Beam splitting ratio(s) for the various outputs (i.e. the + paths of the beam after being split by the beam splitter). + The order of the ratios must be consistent with the labels + 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting with 1. @@ -206,39 +195,39 @@ length(NX_FLOAT): - Clear aperture of the device (e.g. 90% of diameter for a disc, or 90% of - length and height for square geometry). + Clear aperture of the device (e.g. 90% of diameter for a disc, or 90% of + length and height for square geometry). - Substrate of the beam splitter. Describe the material of the substrate in - substrate/substrate_material and provide its index of refraction in - substrate/index_of_refraction_substrate, if known. + Substrate of the beam splitter. Describe the material of the substrate in + substrate/substrate_material and provide its index of refraction in + substrate/index_of_refraction_substrate, if known. - Specify the material of the beam splitter. If the device has a coating - it should be described in coating/coating_material. Is the material - birefringent? + Specify the material of the beam splitter. If the device has a coating + it should be described in coating/coating_material. Is the material + birefringent? - Thickness of the beam splitter substrate. Define the minimum and - maximum thickness (for a wedged geomtry). For a homogeneous thickness - (e.g. as in plate beam splitters) the minimum and maximum values are - equal. + Thickness of the beam splitter substrate. Define the minimum and + maximum thickness (for a wedged geometry). For a homogeneous thickness + (e.g. as in plate beam splitters) the minimum and maximum values are + equal. - + - Complex index of refraction of the beam splitter substrate. Specify at - given spectral values (e.g. wavelength, energy, wavenumber etc.). + Complex index of refraction of the beam splitter substrate. Specify at + given spectral values (e.g. wavelength, energy, wavenumber etc.). @@ -248,32 +237,32 @@ length(NX_FLOAT): - Is the beam splitter coated? If yes, specify the type and material of the - coating and the spectral range for which it is designed. If known, you - may also provide its index of refraction. For a beam splitter cube - consisting of two prisms which are glued together, you may want to - specify the the glue and the coatings of each prism. + Is the beam splitter coated? If yes, specify the type and material of the + coating and the spectral range for which it is designed. If known, you + may also provide its index of refraction. For a beam splitter cube + consisting of two prisms which are glued together, you may want to + specify the the glue and the coatings of each prism. - Specify the coating type (e.g. dielectric, anti-reflection (AR), - multilayer coating etc.). + Specify the coating type (e.g. dielectric, anti-reflection (AR), + multilayer coating etc.). - Specify the coating material. + Specify the coating material. - Thickness of the coating. + Thickness of the coating. - Wavelength range for which the coating is designed. Enter the minimum - and maximum values of the wavelength range. + Wavelength range for which the coating is designed. Enter the minimum + and maximum values of the wavelength range. @@ -281,8 +270,8 @@ length(NX_FLOAT): - Complex index of refraction of the coating. Specify at given spectral - values (e.g. wavelength, energy, wavenumber etc.). + Complex index of refraction of the coating. Specify at given spectral + values (e.g. wavelength, energy, wavenumber etc.). @@ -292,10 +281,10 @@ length(NX_FLOAT): - Wavelength range for which the beam splitter is designed. Enter the - minimum and maximum values of the wavelength range. Alternatively, or - additionally, you may define the wavelength range for the coating in - coating/wavelength_range_coating. + Wavelength range for which the beam splitter is designed. Enter the + minimum and maximum values of the wavelength range. Alternatively, or + additionally, you may define the wavelength range for the coating in + coating/wavelength_range_coating. @@ -303,11 +292,11 @@ length(NX_FLOAT): - Optical loss of the beam splitter for the various outputs (i.e. the paths - of the beam after being split by the beam splitter). - The order of the ratios must be consistent with the labels - 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting - with 1. + Optical loss of the beam splitter for the various outputs (i.e. the paths + of the beam after being split by the beam splitter). + The order of the ratios must be consistent with the labels + 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting + with 1. @@ -315,20 +304,20 @@ length(NX_FLOAT): - Optimized angle of incidence for the desired splitting ratio. + Optimized angle of incidence for the desired splitting ratio. - Angle of deflection corresponding to the optimized angle of incidence - defined in incident_angle. + Angle of deflection corresponding to the optimized angle of incidence + defined in incident_angle. - + - Range of the angles of incidence (AOI) for which the beam splitter can be - operated. Specify the minimum and maximum angles of the range. + Range of the angles of incidence (AOI) for which the beam splitter can be + operated. Specify the minimum and maximum angles of the range. @@ -338,10 +327,10 @@ length(NX_FLOAT): use dim: [[1,N_angles]], N_angles being the number of angles for which the beam splitter can be operated? If this is the case for some devices, we might also have to define a field -for the corresponding defelction angles...--> +for the corresponding deflection angles...--> - Reflectance of the beam splitter at given spectral values. + Reflectance of the beam splitter at given spectral values. @@ -349,11 +338,11 @@ for the corresponding defelction angles...--> - Transmission at given spectral values for the various outputs (i.e. the - paths of the beam after being split by the beam splitter). - The order of the ratios must be consistent with the labels - 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting - with 1. + Transmission at given spectral values for the various outputs (i.e. the + paths of the beam after being split by the beam splitter). + The order of the ratios must be consistent with the labels + 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting + with 1. diff --git a/contributed_definitions/NXfiber.nxdl.xml b/contributed_definitions/NXoptical_fiber.nxdl.xml similarity index 53% rename from contributed_definitions/NXfiber.nxdl.xml rename to contributed_definitions/NXoptical_fiber.nxdl.xml index f4a32db3c3..15358ba2a2 100644 --- a/contributed_definitions/NXfiber.nxdl.xml +++ b/contributed_definitions/NXoptical_fiber.nxdl.xml @@ -3,7 +3,7 @@ - + - Length of the spectrum vector (e.g. wavelength or energy) for which the - refractive index of the core material is given. + Length of the spectrum vector (e.g. wavelength or energy) for which the + refractive index of the core material is given. - Length of the spectrum vector (e.g. wavelength or energy) for which the - refractive index of the cladding material is given. + Length of the spectrum vector (e.g. wavelength or energy) for which the + refractive index of the cladding material is given. - Length of the spectrum vector (e.g. wavelength or energy) for which the - attenuation curve is given. + Length of the spectrum vector (e.g. wavelength or energy) for which the + attenuation curve is given. - An optical fiber, e.g. glass fiber. - - Specify the quantities that define the fiber. Fiber optics are described in - detail [here](https://www.photonics.com/Article.aspx?AID=25151&PID=4), for - example. + An optical fiber, e.g. glass fiber. + + Specify the quantities that define the fiber. Fiber optics are described in + detail [here](https://www.photonics.com/Article.aspx?AID=25151&PID=4), for + example. - Descriptive name or brief description of the fiber, e.g. by stating its - dimension. The dimension of a fiber can be given as 60/100/200 which - refers to a core diameter of 60 micron, a clad diameter of 100 micron, - and a coating diameter of 200 micron. + Descriptive name or brief description of the fiber, e.g. by stating its + dimension. The dimension of a fiber can be given as 60/100/200 which + refers to a core diameter of 60 micron, a clad diameter of 100 micron, + and a coating diameter of 200 micron. - Type/mode of the fiber. Modes of fiber transmission are shown in - Fig. 5 [here](https://www.photonics.com/Article.aspx?AID=25151&PID=4). + Type/mode of the fiber. Modes of fiber transmission are shown in + Fig. 5 [here](https://www.photonics.com/Article.aspx?AID=25151&PID=4). @@ -71,9 +71,9 @@ - Type of dispersion. + Type of dispersion. - + @@ -81,8 +81,8 @@ - Spectrum-dependent (or refractive index-dependent) dispersion of the - fiber. Specify in ps/nm*km. + Spectrum-dependent (or refractive index-dependent) dispersion of the + fiber. Specify in ps/nm*km. @@ -90,22 +90,22 @@ - Core of the fiber, i.e. the part of the fiber which transmits the light. + Core of the fiber, i.e. the part of the fiber which transmits the light. - + - Specify the material of the core of the fiber. + Specify the material of the core of the fiber. - + - Core diameter of the fiber (e.g. given in micrometer). + Core diameter of the fiber (e.g. given in micrometer). - + - Complex index of refraction of the fiber. Specify at given wavelength - (or energy, wavenumber etc.) values. + Complex index of refraction of the fiber. Specify at given wavelength + (or energy, wavenumber etc.) values. @@ -115,22 +115,22 @@ - Core of the fiber, i.e. the part of the fiber which transmits the light. + Core of the fiber, i.e. the part of the fiber which transmits the light. - + - Specify the material of the core of the fiber. + Specify the material of the core of the fiber. - + - Clad diameter of the fiber (e.g. given in micrometer). + Clad diameter of the fiber (e.g. given in micrometer). - + - Complex index of refraction of the fiber. Specify at given wavelength - (or energy, wavenumber etc.) values. + Complex index of refraction of the fiber. Specify at given wavelength + (or energy, wavenumber etc.) values. @@ -140,64 +140,59 @@ - Coating of the fiber. + Coating of the fiber. - + - Specify the material of the coating of the fiber. + Specify the material of the coating of the fiber. - + - Outer diameter of the fiber (e.g. given in micrometer). + Outer diameter of the fiber (e.g. given in micrometer). - Length of the fiber. + Length of the fiber. - Spectral range for which the fiber is designed. Enter the minimum and - maximum values (lower and upper limit) of the wavelength range. + Spectral range for which the fiber is designed. Enter the minimum and + maximum values (lower and upper limit) of the wavelength range. - Unit of spectral array (e.g. nanometer or angstrom for wavelength, or - electronvolt for energy etc.). + Unit of spectral array (e.g. nanometer or angstrom for wavelength, or + electronvolt for energy etc.). - + - Transfer rate of the fiber (in GB per second). + Transfer rate of the fiber (in GB per second). - - - GB/s - - - Numerical aperture (NA) of the fiber. + Numerical aperture (NA) of the fiber. - + - Wavelength-dependent attenuation of the fiber (specify in dB/km). + Wavelength-dependent attenuation of the fiber (specify in dB/km). - Use dB/km. + Use dB/km. @@ -206,12 +201,12 @@ - Power loss of the fiber in percentage. + Power loss of the fiber in percentage. - Acceptance angle of the fiber. + Acceptance angle of the fiber. diff --git a/contributed_definitions/NXoptical_polarizer.nxdl.xml b/contributed_definitions/NXoptical_polarizer.nxdl.xml index 5d4b59f88c..9536b3896c 100644 --- a/contributed_definitions/NXoptical_polarizer.nxdl.xml +++ b/contributed_definitions/NXoptical_polarizer.nxdl.xml @@ -3,7 +3,7 @@ - - + @@ -46,9 +47,9 @@ - Type of the polarizer (e.g. dichroic, linear, circular etc.) + Type of the polarizer - + @@ -61,15 +62,8 @@ - - - - - If you selected 'other' in type specify what it is. - - Angle of the polarizer. @@ -91,22 +85,22 @@ dimensions of the device, and (ii) the input and outputs (i.e. the direction of the incoming and outcoming (split) beams). - Describe the shape (plate, cube, wedged, prism etc.). - + + - Sketch of thedevice showing its geometry. The paths of the + Sketch of the device showing its geometry. The paths of the incoming and outgoing beam should be illustrated and labelled (0 for the incoming beam, and 1, 2,..., N_outputs for the outputs). @@ -123,9 +117,9 @@ * For 'plate' the parameters are (width, height, length). * For 'prism' the parameters are (width, height, length). * For 'wedged' the parameters are (width, height, shortest length). - The wedge angle should be provided in 'SHAPE/wedge_angle'. + The wedge angle should be provided in 'SHAPE/wedge_angle'. * For 'other' the parameters may be (A, B, C, ...) with the labels - defined in the sketch plotted in 'SHAPE/sketch'. + defined in the sketch plotted in 'SHAPE/sketch'. @@ -150,7 +144,7 @@ Properties of the substrate material of the polarizer. If the device has - a coating specify the coating material and its properties in 'coating'. + a coating specify the coating material and its properties in ``COATING``. @@ -173,28 +167,29 @@ - - If the device has a coating describe the material and its properties. Some basic information can be found e.g. [here] (https://www.opto-e.com/basics/reflection-transmission-and-coatings). If the back and front side of the polarizer are coated with different - materials, you may define two coatings (e.g. COATING1 and COATING2). + materials, you may define two coatings (e.g. coating_front and + coating_back). - + Specify the coating type (e.g. dielectric, anti-reflection (AR), multilayer coating etc.). - + Describe the coating material (e.g. MgF2). - + Thickness of the coating. From 0ee421fe7629e18105b2bc61b96011c35b3e29a9 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 28 Aug 2025 10:49:20 +0200 Subject: [PATCH 0984/1012] modify dispersion models --- contributed_definitions/NXdispersion.nxdl.xml | 8 +- .../NXdispersion_repeated_parameter.nxdl.xml | 20 ++--- .../NXdispersion_single_parameter.nxdl.xml | 8 +- .../NXdispersion_table.nxdl.xml | 26 +++---- .../NXdispersive_material.nxdl.xml | 76 +++++++++---------- 5 files changed, 67 insertions(+), 71 deletions(-) diff --git a/contributed_definitions/NXdispersion.nxdl.xml b/contributed_definitions/NXdispersion.nxdl.xml index b581fb87c9..06d8152f6a 100644 --- a/contributed_definitions/NXdispersion.nxdl.xml +++ b/contributed_definitions/NXdispersion.nxdl.xml @@ -23,13 +23,13 @@ --> - A dispersion denoting a sum of different dispersions. - All NXdispersion_table and NXdispersion_function groups will be added together - to form a single dispersion. + A dispersion denoting a sum of different dispersions. + All NXdispersion_table and NXdispersion_function groups will be added together + to form a single dispersion. - The name of the composite model. + The name of the composite model. diff --git a/contributed_definitions/NXdispersion_repeated_parameter.nxdl.xml b/contributed_definitions/NXdispersion_repeated_parameter.nxdl.xml index 871ff09f36..f4913ca7dd 100644 --- a/contributed_definitions/NXdispersion_repeated_parameter.nxdl.xml +++ b/contributed_definitions/NXdispersion_repeated_parameter.nxdl.xml @@ -25,30 +25,30 @@ - The number of parameter repetitions + The number of parameter repetitions - A repeated parameter for a dispersion function + A repeated parameter for a dispersion function - The name of the parameter + The name of the parameter - A description of what this parameter represents + A description of what this parameter represents - A unit array associating a unit with each parameter. - The first element should be equal to values/@unit. - The values should be SI interpretable standard units - with common prefixes (e.g. mikro, nano etc.) or their - short-hand notation (e.g. nm, mm, kHz etc.). + A unit array associating a unit with each parameter. + The first element should be equal to values/@unit. + The values should be SI interpretable standard units + with common prefixes (e.g. mikro, nano etc.) or their + short-hand notation (e.g. nm, mm, kHz etc.). @@ -56,7 +56,7 @@ - The value of the parameter + The value of the parameter diff --git a/contributed_definitions/NXdispersion_single_parameter.nxdl.xml b/contributed_definitions/NXdispersion_single_parameter.nxdl.xml index 59b38788a8..d5d6b4c40f 100644 --- a/contributed_definitions/NXdispersion_single_parameter.nxdl.xml +++ b/contributed_definitions/NXdispersion_single_parameter.nxdl.xml @@ -23,21 +23,21 @@ --> - A single parameter for a dispersion function + A single parameter for a dispersion function - The name of the parameter + The name of the parameter - A description of what this parameter represents + A description of what this parameter represents - The value of the parameter + The value of the parameter diff --git a/contributed_definitions/NXdispersion_table.nxdl.xml b/contributed_definitions/NXdispersion_table.nxdl.xml index f0a0851531..48897dc426 100644 --- a/contributed_definitions/NXdispersion_table.nxdl.xml +++ b/contributed_definitions/NXdispersion_table.nxdl.xml @@ -24,25 +24,25 @@ - The symbols in this schema to denote the dimensions + The symbols in this schema to denote the dimensions - The number of energy and dielectric function points + The number of energy and dielectric function points - A dispersion table denoting energy, dielectric function tabulated values. + A dispersion table denoting energy, dielectric function tabulated values. - The name of this dispersion model. + The name of this dispersion model. - The sign convention being used (n + or - ik) + The sign convention being used (n + or - ik) @@ -51,9 +51,9 @@ - The wavelength array of the tabulated dataset. - This is essentially a duplicate of the energy field. - There should be one or both of them present. + The wavelength array of the tabulated dataset. + This is essentially a duplicate of the energy field. + There should be one or both of them present. @@ -61,9 +61,9 @@ - The energy array of the tabulated dataset. - This is essentially a duplicate of the wavelength field. - There should be one or both of them present. + The energy array of the tabulated dataset. + This is essentially a duplicate of the wavelength field. + There should be one or both of them present. @@ -71,7 +71,7 @@ - The refractive index array of the tabulated dataset. + The refractive index array of the tabulated dataset. @@ -79,7 +79,7 @@ - The dielectric function of the tabulated dataset. + The dielectric function of the tabulated dataset. diff --git a/contributed_definitions/NXdispersive_material.nxdl.xml b/contributed_definitions/NXdispersive_material.nxdl.xml index bc70d81a86..dadf223035 100644 --- a/contributed_definitions/NXdispersive_material.nxdl.xml +++ b/contributed_definitions/NXdispersive_material.nxdl.xml @@ -23,23 +23,20 @@ --> - NXdispersion + An application definition for describing a dispersive material. - - An application definition for a dispersive material. - - Version number to identify which definition of this application definition was - used for this entry/data. + Version number to identify which definition of this application definition was + used for this entry/data. - + - URL where to find further material (documentation, examples) relevant to the - application definition + URL where to find further material (documentation, examples) relevant to the + application definition @@ -50,67 +47,66 @@ - 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`. + 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 colloquial name of the material, e.g. graphite or diamond for carbon. + The colloquial name of the material, e.g. graphite or diamond for carbon. - The phase of the material + The phase of the material - + - - Additional information about the phase if the - material phase is other. + Additional information about the phase if the + material phase is not from the enumerated list. - This field may be used to denote additional phase information, - such as crystalin phase of a crystal (e.g. 4H or 6H for SiC) or - if a measurement was done on a thin film or bulk material. + This field may be used to denote additional phase information, + such as crystalline phase of a crystal (e.g. 4H or 6H for SiC) or + if a measurement was done on a thin film or bulk material. - Denotes whether the dispersion is calculated or derived from an experiment + Denotes whether the dispersion is calculated or derived from an experiment - + - A text description of this reference, e.g. - `E. Example et al, The mighty example, An example journal 50 (2023), 100` + A text description of this reference, e.g. + `E. Example et al, The mighty example, An example journal 50 (2023), 100` - The dispersion along the optical axis of the material. - This should be the only dispersion available for isotropic materials. - For uniaxial materials this denotes the ordinary axis. - For biaxial materials this denotes the x axis or epsilon 11 tensor element - of the diagionalized permittivity tensor. + The dispersion along the optical axis of the material. + This should be the only dispersion available for isotropic materials. + For uniaxial materials this denotes the ordinary axis. + For biaxial materials this denotes the x axis or epsilon 11 tensor element + of the diagionalized permittivity tensor. @@ -146,13 +142,13 @@ - This should only be filled for biaxial materials. - It denotes the epsilon 22 direction of the diagionalized - permittivity tensor. + This should only be filled for biaxial materials. + It denotes the epsilon 22 direction of the diagionalized + permittivity tensor. - The name of this dispersion model. + The name of this dispersion model. @@ -184,14 +180,14 @@ - This should only be filled for uniaxial or biaxial materials. - For uniaxial materials this denotes the extraordinary axis. - For biaxial materials this denotes the epsilon 33 tensor element - of the diagionalized perimittivty tensor. + This should only be filled for uniaxial or biaxial materials. + For uniaxial materials this denotes the extraordinary axis. + For biaxial materials this denotes the epsilon 33 tensor element + of the diagionalized perimittivty tensor. - The name of this dispersion model. + The name of this dispersion model. From 85af62e3abc34bb0aea68d162eccdee55f596358 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 28 Aug 2025 10:51:50 +0200 Subject: [PATCH 0985/1012] bring in NXmicrostructure from fairmat repo --- .../NXmicrostructure.nxdl.xml | 798 ++++++++++-------- .../NXmicrostructure_feature.nxdl.xml | 37 + .../NXmicrostructure_gragles_config.nxdl.xml | 369 -------- .../NXmicrostructure_gragles_results.nxdl.xml | 295 ------- .../NXmicrostructure_imm_config.nxdl.xml | 244 ------ .../NXmicrostructure_imm_results.nxdl.xml | 189 ----- .../NXmicrostructure_ipf.nxdl.xml | 244 +++--- .../NXmicrostructure_kanapy_results.nxdl.xml | 64 +- .../NXmicrostructure_mtex_config.nxdl.xml | 136 +-- .../NXmicrostructure_odf.nxdl.xml | 134 +-- .../NXmicrostructure_pf.nxdl.xml | 49 +- .../NXmicrostructure_score_config.nxdl.xml | 721 ++++++++++------ .../NXmicrostructure_score_results.nxdl.xml | 461 +++++----- .../NXmicrostructure_slip_system.nxdl.xml | 29 +- contributed_definitions/NXms.nxdl.xml | 529 ------------ 15 files changed, 1518 insertions(+), 2781 deletions(-) create mode 100644 contributed_definitions/NXmicrostructure_feature.nxdl.xml delete mode 100644 contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml delete mode 100644 contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml delete mode 100644 contributed_definitions/NXmicrostructure_imm_config.nxdl.xml delete mode 100644 contributed_definitions/NXmicrostructure_imm_results.nxdl.xml delete mode 100644 contributed_definitions/NXms.nxdl.xml diff --git a/contributed_definitions/NXmicrostructure.nxdl.xml b/contributed_definitions/NXmicrostructure.nxdl.xml index 44d462c045..e5059f1926 100644 --- a/contributed_definitions/NXmicrostructure.nxdl.xml +++ b/contributed_definitions/NXmicrostructure.nxdl.xml @@ -1,9 +1,9 @@ - + - The symbols used in the schema to specify e.g. dimensions of arrays. + The symbols used in the schema to specify e.g. dimensions of arrays. + + + The number of crystals or their projections + + + + + The number of interfaces or their projections + + + + + The number of triple junctions or their projections + + + + + The number of quadruple junctions or their projections + + - The number of one-dimensional crystal projections + The number of one-dimensional crystal projections - The number of one-dimensional interface projections + The number of one-dimensional interface projections - The number of two-dimensional crystal projections + The number of two-dimensional crystal projections - The number of two-dimensional interface projections + The number of two-dimensional interface projections - The number of two-dimensional triple line projections + The number of two-dimensional triple line projections - The number of two-dimensional line defect projections + The number of two-dimensional line defect projections - The number of crystals (grain and sub-grain are exact synonyms for crystal). + The number of crystals (grain and sub-grain are exact synonyms for crystal). - The number of interfaces (grain boundary and phase boundary are subclasses of - interfaces). + The number of interfaces (grain boundary and phase boundary are subclasses of + interfaces). - The number of triple junctions (triple line is a exact synonym for triple - junction, triple point is projection of a triple junction). + The number of triple junctions (triple line is a exact synonym for triple + junction, triple point is projection of a triple junction). - The number of quadruple junctions. + The number of quadruple junctions. - + - The dimensionality of the representation that needs to match the value for - configuration/dimensionality + The dimensionality of the representation that needs to match the value for + configuration/dimensionality - Base class to describe a microstructure, its structural aspects, associated descriptors, properties. - - Whether one uses a continuum or atomic scale description of materials, these are always a model only of - the true internal structure of a material. Such models are useful as they enable a coarse-graining and - categorizing of properties and representational aspects from which measured or simulated descriptions - can be correlated with properties, i.e. descriptor values. - - Keep in mind that most specimens are thermo-chemo-mechanically processed prior characterization. - Therefore, the characterized microstructure may not have probed the same structure as of the untreated - sample from which the region-of-interests on the specimen were sampled. - - Fields such as time and increment enable a quantification of the spatiotemporal evolution of a materials' - structure by using multiple instances of NXmicrostructure. Both measurements and simulation virtually - always sample this evolution. Most microscopy techniques support to generate only a two-dimensional - representation (projection) of the characterized material. Often materials are characterized only for - specific states or via sampling coarsely in time relative to the timescale at which the - physical phenomena take place. This is typically a compromise between the research questions at hand and technical surplus practical limitations. - - The term microstructural feature covers here crystals and all sorts of crystal defects within the material. - A key challenge with the description of representations and properties of microstructural features is that - features with different dimensionality exist and combinations of features of different dimensionality are - frequently expected to be documented with intuitive naming conventions using flat property lists. - For these key-value dictionaries often folksonomies are used. These can be based on ad hoc documentation - of such dictionaries in the literature and the metadata section of public data repositories. - - NXmicrostructure is an attempt to standardize these descriptions stronger. - - The descriptive variety is large especially for junctions. Like crystals and interfaces, junctions are features in - three-dimensional Euclidean space even if they are formed maybe only through a monolayer or pearl chain of atoms. - Either way the local atomic and electronic environment is different compared to the situation of an ideal crystal, - which gives typically rise to a plethora of configurations of which some yield useful properties. - - Like crystals and interfaces, junctions are assumed to represent groups of atoms that have specific descriptor values - which are different to other features. Taking an example, a triple junction is practically a three-dimensional defect as its atoms - are arranged in three-dimensional space but the characteristics of that defect can often be reduced to a lower-dimensional - description such as a triple point or a triple line. Therefore, different representations can be used to describe the location, - shape, and structure of the defect. As different types of crystal defects can interact, there is a substantial number of - in principle characterizable and representable objects. Take again a triple line as an example. It is a tubular feature built from three - adjoining interfaces. However, dislocations as line defects can interact with triple lines. Therefore, one can also argue that - along a triple line there can be dislocation-line-triple-line junctions, likewise dislocations form own junctions. - - It is not the aim of this base class to cover all these cases, rather this base class currently provides examples how the - typically most relevant types of features can be represented using a combination of base classes in NeXus. Currently, - these are crystals, interfaces, triple lines, quadruple junctions. - - The description attempt here took inspiration from `E. E. Underwood <https://doi.org/10.1111/j.1365-2818.1972.tb03709.x>`_ - and E. E. Underwood's book on Quantitative Stereology published 1970 to categorize features based on their dimensionality. - - Identifiers can be defined either implicitly or explicitly. Identifiers for implicit indexing are defined - on the interval :math:`[identifier\_offset, identifier\_offset + cardinality - 1]`. + Base class to describe a microstructure, its structural aspects, associated descriptors, properties. + + Whether one uses a continuum or atomic scale description of materials, these are always a model only of + the true internal structure of a material. Such models are useful as they enable a coarse-graining and + categorizing of properties and representational aspects from which measured or simulated descriptions + can be correlated with properties, i.e. descriptor values. The base class here can be used to describe + the structural aspect of a region-of-interest for a specimen that was investigated or a computer + simulation that was performed for a virtual specimen. + + Specimens experience thermo-chemo-mechanical processing (steps) before characterization. Therefore, + the characterized microstructure may not turn out to be the same structure as of the untreated + sample from which the region-of-interests on the specimen were sampled. + + Fields such as time and increment enable a quantification of the spatiotemporal evolution of a materials' + structure by using multiple instances of NXmicrostructure. Both measurements and simulation virtually + always sample this evolution. Most microscopy techniques characterize only a two-dimensional representation + (projection) of the characterized material volume. Often materials are characterized only for specific states + or via sampling coarsely in time relative to the timescale at which the physical phenomena take place. + This is typically a compromise between the research questions and technical surplus practical limitations. + + The term microstructural feature covers here crystals and all sorts of crystal defects within the material + (interfaces, triple junctions, dislocations, pores, etc.). + A key challenge with the description of representations and properties of such microstructural features is that + they can be represented and view as features with different dimensionality. Furthermore, combinations of features of + different dimensionality are frequently expected to be documented with intuitive naming conventions when + flat property lists are used. For these key-value dictionaries often folksonomies are used. These can be based + on ad hoc documentation of such dictionaries in the literature and the metadata section of public data repositories. + + NXmicrostructure is an attempt to standardize these descriptions stronger. + + For crystals the number of typically used technical terms are smaller than for interfaces or line like defects and + junctions of different types of crystal defects. The term grain describes a contiguous region of material that is + delineated by interfaces (phase or grain boundaries). With its origin motivated by light optical microscopy though + a grain is not necessarily a single crystal but can have an internal structure of defect such as dislocations. + In this base class we use the term and respective group crystals though for single crystals and grains. + The reason why this is possible is that when e.g. materials engineers talk about grains they inherently assume + that the internal structure of these grains can be described with homogenized effective properties. + If alternatively the individual structural crystalline or features of this grain should be distinguished + it is useful to instantiate these as individual instances of crystals. + + Grain boundaries and phase boundaries are two main categories of interfaces. + A grain boundary delineates two regions with similar crystal structure and phase but different orientation. + A grain boundary is thus a homophase interface. By contrast, a heterophase boundary delineates two regions with typically + but not necessarily dissimilar crystal structure but a different atomic occupation that justifies to distinguish two + phases. There is a substantial variety of interfaces whose distinction was classically based on geometrical arguments + but considers that atomic segregation is an equally important structural aspect to consider when classifying grain + boundaries. A concise overview on theoretical aspect of and the semantics for characterizing interfaces and their properties + is provided in e.g. `W. Bollmann <https://doi.org/10.1007/978-3-642-49173-3>`_ and A. Sutton and R. W. Baluffi, + Interfaces in Crystalline Materials, Clarendon Press, ISBN 9780198500612. + + Also for junctions between crystal defects there is a considerable variety of terms. Junctions are features in + three-dimensional Euclidean space even if they are formed maybe only through a monolayer or a pearl chain of atoms. + Either way their local atomic and electronic environment is different compared to the situation of an ideal crystal, + or the adjoining defects, which gives typically rise to a plethora of configurations of which some yield useful material + properties or affect material properties. + + Like crystals and interfaces, junctions are assumed to represent groups of atoms that have specific descriptor values + which are different to other features. Taking an example, a triple junction is practically a three-dimensional defect as its atoms + are arranged in three-dimensional space but the characteristics of that defect can often be reduced to a lower-dimensional + description such as a triple line or a triple point as the projection of a line. Therefore, different representations can + be used to describe the location, shape, and structure of such defect. + + This base class provides definitions for crystals, grains, interfaces, triple junctions, and quadruple junctions thus covering, + volumetric, patch, line, and point like features that can serve as examples for future extension. + + As different types of crystal defects can interact, there is a substantial number of in principle characterizable and representable + objects. Take again a triple line as an example. It is a tubular feature built from three adjoining interfaces. However, dislocations + as line defects can interact with triple lines. Therefore, one can also argue that along a triple line there exist dislocation-line- + triple-line junctions, likewise dislocations form own junctions. + + The description took inspiration from `E. E. Underwood <https://doi.org/10.1111/j.1365-2818.1972.tb03709.x>`_ + and E. E. Underwood's book on Quantitative Stereology published in 1970 to categorize features based on their dimensionality. + + Indices can be defined either implicitly or explicitly. Indices for implicit indexing are defined + on the interval :math:`[index\_offset, index\_offset + cardinality - 1]`. Indices can be used as identifiers + for distinguishing instances, i.e. indices are equivalent to instance names of individual crystals. - Discouraged free-text field for leaving comments. + Discouraged free-text field for leaving comments - ISO8601 with offset to local time zone included when a timestamp is required. + ISO8601 with offset to local time zone included when a timestamp is required. - Measured or simulated physical time stamp for this microstructure snapshot. - Not to be confused with wall-clock timing or profiling data. + Measured or simulated physical time stamp for this microstructure snapshot. + Not to be confused with wall-clock timing or profiling data. - Iteration or increment counter. + Iteration or increment counter. - Group where to store details about the configuration and parameterization of algorithms - used whereby microstructural features were identified. + Group where to store details about the configuration and parameterization of algorithms + used whereby microstructural features were identified. - Dimensionality of Euclidean space in which the analysis is performed. - - This field can be used e.g. by a research data management system to identify - if the description specifies one-, two-, or three-dimensional microstructural representations. + Dimensionality of Euclidean space in which the analysis is performed. + + This field can be used e.g. by a research data management system to identify + if the description specifies one-, two-, or three-dimensional microstructural representations. @@ -190,11 +236,11 @@ the idea is we may wish to run as many grain reconstructions as we want and add - Algorithm whereby interfaces between crystals were reconstructed. - - * Disorientation clustering groups nearby material points based on their crystallographic disorientation - * Fast multiscale clustering based on `D. Kushnir et al. <https://doi.org/10.1016/j.patcog.2006.04.007>`_ - * Markov chain clustering `F. Niessen et al. <https://doi.org/10.1107/S1600576721011560>`_ + Algorithm whereby interfaces between crystals were reconstructed. + + * Disorientation clustering groups nearby material points based on their crystallographic disorientation + * Fast multiscale clustering based on `D. Kushnir et al. <https://doi.org/10.1016/j.patcog.2006.04.007>`_ + * Markov chain clustering `F. Niessen et al. <https://doi.org/10.1107/S1600576721011560>`_ @@ -206,570 +252,634 @@ the idea is we may wish to run as many grain reconstructions as we want and add - Threshold to define at which disorientation angle to assume two crystalline regions have a significant - orientation difference that warrants to assume that there exists an interface between the two regions. + Threshold to define at which disorientation angle to assume two crystalline regions have a significant + orientation difference that warrants to assume that there exists an interface between the two regions. - The program with which the microstructure was reconstructed. + The program with which the microstructure was reconstructed. - - - - - + + + + + + - + - One- or two-dimensional projections, or three-dimensional representations of crystals. - - An example for a volume bounded by other crystal defects. Crystals can be grains of - different phases, precipitates, dispersoids; there are many terms used specifically in - the materials engineering community. - - Typically, crystals are measured on the surface of a sample via optical or electron microscopy. - Using X-ray diffraction methods crystals can be observed in bulk specimens. - - Crystals are represented by a set of pixel, voxel, or polygons and their polyline boundaries. - In rare cases the volume bounded gets represented using constructive solid geometry approaches. + The chemical composition of this microstructure (region). + + + + + Different (thermodynamic) phases can be distinguished for the region-of- + interest. + + + + First identifier whereby to identify phases implicitly. + + + + + + + One- or two-dimensional projections, or three-dimensional representations of crystals. + + An example for a volume bounded by other crystal defects. Crystals can be grains of + different phases, precipitates, dispersoids; there are many terms used specifically in + the materials engineering community. + + Typically, crystals are measured on the surface of a sample via optical or electron microscopy. + Using X-ray diffraction methods crystals can be observed in bulk specimens. + + Crystals are represented by a set of pixel, voxel, or polygons and their polyline boundaries. + In rare cases the volume bounded gets represented using constructive solid geometry approaches. - Reference to an instance of: - - * :ref:`NXcg_polyline_set` for a one-dimensional representation as only a projection is available (like in linear intercept analysis) - * :ref:`NXcg_polygon_set` for a two-dimensional representation as only a projection is available (like in most experiments) - * :ref:`NXcg_polyhedron_set` or :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions - (like in computer simulations or 3D experiments) - - which represent the geometrical entities of the discretization. + Reference to an instance of: + + * :ref:`NXcg_polyline` for a one- or two-dimensional representation as only a projection is available (like in linear intercept analysis) + * :ref:`NXcg_polygon`, :ref:`NXcg_triangle`, or :ref:`NXcg_polyhedron` for a two- or three-dimensional representation as only a projection is available (like in most experiments) + * :ref:`NXcg_grid` for regularly pixelated (in 1D, 2D) or voxelated representations (in 3D) + + which represent the geometrical entities of the discretization. - How many crystals are distinguished. - - Crystals are listed irrespective of the phase to which these are assigned. + How many crystals are distinguished. + + Crystals are listed irrespective of the phase to which these are assigned. - How many phases are distinguished. - - Phases are typically distinguished based on statistical thermodynamics argument and crystal structure. + How many phases are distinguished. + + Phases are typically distinguished based on statistical thermodynamics argument and crystal structure. - + - First identifier whereby to identify crystals implicitly. + First identifier whereby to identify crystals implicitly. - + - Identifier whereby to identify each crystal explicitly. + Identifier whereby to identify each crystal explicitly. - - + + - + - First identifier whereby to identify phases implicitly. + Identifier whereby to identify phase for each crystal explicitly. - - - - Identifier whereby to identify phase for each crystal explicitly. - - - + + - - + + - True or false value, one for each crystal, to communicate whether that feature - makes contact with the edge of the ROI. + True, if the feature makes contact with the edge of the ROI. + False, if the feature does not make contact with the edge of the ROI. - - + + - Average disorientation angle for each crystal between individual orientations - of that crystal evaluated as a summary statistic for all probed positions vs the - average disorientation of that crystal. + Average disorientation angle for each crystal between individual orientations + of that crystal evaluated as a summary statistic for all probed positions vs the + average disorientation of that crystal. - - + + - Length of each crystal + Length of each crystal - - + + - Area of each crystal. + Area of each crystal. - - + + - Volume of each crystal + Volume of each crystal - - + + + + + Possibility to store the mean orientation of the grain. + + - + - One- or two-dimensional projections or three-dimensional representation of interfaces - between crystals as topological entities equivalent to dual_junctions. - - An example for a surface defect. Most important are interfaces such as grain and phase boundaries - but factually interfaces also exist between the environment and crystals exposed at the - surface of the specimen or internal surfaces like between crystals, cracks, or pores. + One- or two-dimensional projections or three-dimensional representation of interfaces + between crystals as topological entities equivalent to dual_junctions. + + An example for a surface defect. Most important are interfaces such as grain and phase boundaries + but factually interfaces also exist between the environment and crystals exposed at the + surface of the specimen or internal surfaces like between crystals, cracks, or pores. + + Interfaces are typically reported as discretized features. For interface projections on the 2D plane + these are most frequently polyline segments. For interface patches in 3D these are most frequently + triangulations. Descriptions with continuous functions are seldom used unless simplified configurations + are studied in modeling and theoretical studies. + + When using discretizations the individual interface segments need to be distinguished from the interfaces + themselves. Consequently, there are two sets of indices. - Reference to an instance of: - - * :ref:`NXcg_point_set` for a one-dimensional representation as only a projection is available (as in linear intercept analyses) - * :ref:`NXcg_polyline_set` or :ref:`NXcg_polygon_set` for a two-dimensional representation as only a projection is available (like in most experiments) - * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks - (like in computer simulations or 3D experiments) - - which represent the geometrical entities of the discretization. + Reference to an instance of: + + * :ref:`NXcg_point` for a one-dimensional representation as only a projection is available (as in linear intercept analyses) + * :ref:`NXcg_polyline` or :ref:`NXcg_polygon` for a two-dimensional representation as only a projection is available (like in most experiments) + * :ref:`NXcg_grid` for regularly pixelated (in 1D, 2D) or voxelated representations (in 3D) using (boolean) masks + (like in computer simulations or 3D experiments) + + which represent the geometrical entities of the discretization. - How many interfaces are distinguished. + How many interfaces are distinguished. - + - First identifier whereby to identify interfaces implicitly. + First identifier whereby to identify interfaces implicitly. - + - Identifier whereby to identify each interface explicitly. + Identifier whereby to identify each interface explicitly. + + An array with as many entries as interfaces or their projections. - - + + - + - Set of pairs of crystal_identifier for each interface. + Set of pairs of indices_crystal values, for each interface one value pair. + + An array with as many pairs as interfaces or their projections. - - + + - The specific identifiers whereby to resolve ambiguities. + The specific identifiers whereby to resolve ambiguities. - + - Set of pairs of phase_identifier for each interface. + Set of pairs of indices_phase values, for each interface one value pair. + + An array with as many pairs as interfaces or their projections. - - + + - The specific identifiers whereby to resolve ambiguities. + The specific identifiers whereby to resolve ambiguities. - + - Set of pairs of triple_junction_identifier for each interface. + Interfaces can be the physical three-dimensional surfaces or two- or one-dimensional + projections. The latter situation applies typically for characterization with electron + microscopy. + + In the case of a two-dimensional projection interfaces are interface traces. These have + two terminating junctions. In three dimensions though the interface is a surface patch + that is bounded by multiple triple lines. + + Number of triple_junctions adjoining each interface. This array resolves the number of + values along the second dimension for the field indices_triple_junctions. - + + + + + + + Set of pairs of indices_triple_junction for each interface. + + An array with as many tuples of pairs to describe + all junctions about all interfaces. + + - - The specific identifiers whereby to resolve ambiguities. + The specific identifiers whereby to resolve ambiguities. - + - True or false value, one for each crystal, to communicate whether that feature - makes contact with the edge of the ROI. + True, if the interface makes contact with the edge of the ROI. + False, if the interface does not make contact with the edge of the ROI. - - + + - Gibbs free surface energy for each interface. + Gibbs free surface energy for each interface. - - + + - Non-intrinsic mobility of each interface. + Non-intrinsic mobility of each interface. - - + + - The length of each interface if only projections are available. - - This is not necessarily the same as the length of the individual - polyline segments whereby the interface is discretized. + The length of each interface if only projections are available. + + This is not necessarily the same as the length of the individual + polyline segments whereby the interface is discretized. - - + + - The surface area of all interfaces. + The surface area of all interfaces. - - + + - + - Projections or representations of junctions at which three interfaces meet. - - An example for a line defect. Triple junctions are characterized as triple lines or triple points as their projections, - or junctions observed between crystals (at the specimen surface exposed to an environment) - (including wetting phenomena) or inside the specimen (crack, pores). + Projections or representations of junctions at which three interfaces meet. + + An example for a line defect. Triple junctions are characterized as triple lines or triple points as their projections, + or junctions observed between crystals (at the specimen surface exposed to an environment) + (including wetting phenomena) or inside the specimen (crack, pores). - Reference to an instance of: - - * :ref:`NXcg_point_set` for a one-dimensional representation as only a projection is available (like in most experiments) - * :ref:`NXcg_polyline_set` for a two-dimensional representation as only a projection is available - * :ref:`NXcg_polygon_set` for a two-dimensional representation in the (seldom) case of sufficient spatial resolution - and the line in the projection plane or cases where triple junction locations are approximated e.g. using a set of triangles - * :ref:`NXcg_polyhedron_set` for a three-dimensional representation via e.g. a representation of Voronoi cells about atoms - * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks - - which represent the geometrical entities of the discretization. + Reference to an instance of: + + * :ref:`NXcg_point` for a one-dimensional representation as only a projection is available (like in most experiments) + * :ref:`NXcg_polyline` for a two-dimensional representation as only a projection is available + * :ref:`NXcg_polygon` for a two-dimensional representation in the (seldom) case of sufficient spatial resolution + and the line in the projection plane or cases where triple junction locations are approximated e.g. using a set of triangles + * :ref:`NXcg_polyhedron` for a three-dimensional representation via e.g. a representation of Voronoi cells about atoms + * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks + + which represent the geometrical entities of the discretization. - Number of triple junctions. + Number of triple junctions. - + - First identifier to identify triple junctions implicitly. + First identifier to identify triple junctions implicitly. - + - Identifier to identify each triple junction explicitly. + Identifier to identify each triple junction explicitly. - - + + - Set of identifier for positions whereby to identify the location of each - junction. + Set of identifier for positions whereby to identify the location of each + junction. - - + + - The specific identifiers whereby to resolve ambiguities. + The specific identifiers whereby to resolve ambiguities. - + - Explicit positions. + Explicit positions. - - + + - + - Set of tuples of identifier of crystals connected to the junction for each - triple junction. + Set of tuples of identifier of crystals connected to the junction for each + triple junction. - - + + - + - Set of tuples of identifier of interfaces connected to the junction for each - triple junction. + Set of tuples of identifier of interfaces connected to the junction for each + triple junction. - - + + - The specific interface identifiers whereby to resolve ambiguities. + The specific interface identifiers whereby to resolve ambiguities. - + - Set of tuples of identifier for polyline segments connected to the junction for - each triple junction. + Set of tuples of identifier for polyline segments connected to the junction for + each triple junction. - - + + - The specific polyline identifiers whereby to resolve ambiguities. + The specific indices_polyline whereby to resolve ambiguities. - + - True or false value, one for each crystal, to communicate whether that feature - makes contact with the edge of the ROI. + True, if the triple line makes contact with the edge of the ROI. + False, if the triple line does not make contact with the edge of the ROI. - - + + - Specific line energy of each triple junction + Specific line energy of each triple junction - - + + - Non-intrinsic mobility of each triple junction. + Non-intrinsic mobility of each triple junction. - - + + - The length of each triple junction. - - This is not necessarily the same as the length of the individual - polyline segments whereby the junction is discretized. + The length of each triple junction. + + This is not necessarily the same as the length of the individual + polyline segments whereby the junction is discretized. - - + + - The volume of the each triple junction + The volume about each triple junction. + + Respective cut-off criteria need to be specified. - - + + - + - Quadruple junctions as a region where four crystals meet. - - An example for a point defect. + Quadruple junctions as a region where four crystals meet. + + An example for a point (like) defect. + + Thermodynamically such junctions can be unstable. + Specifically when discretizations are used in simulations + that do not address the thermodynamics of and splitting characteristics + of junctions in cases when more than four crystals meet, it is possible + that so-called higher-order junctions are observed. - Reference to an instance of: - - * :ref:`NXcg_point_set` - * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks + Reference to an instance of: + + * :ref:`NXcg_point` + * :ref:`NXcg_grid` for regularly pixelated (in 1D, 2D) or voxelated representations (in 3D) using (boolean) masks + + which represent the geometrical entities of the discretization. - Number of quadruple junctions. + Number of quadruple junctions. - + - First identifier to identify quadruple junctions implicitly. + First identifier to identify quadruple junctions implicitly. - + - Identifier to identify each quadruple junction explicitly. + Identifier to identify each quadruple junction explicitly. - + - - Set of identifier for positions whereby to identify the location of each - junction. + Set of identifier for positions whereby to identify the location of each + junction. - - + + - The specific point identifier whereby to resolve ambiguities. + The specific point identifier whereby to resolve ambiguities. - + - Explicit positions. + Explicit positions. - - - + + + - + - Set of tuples of identifier of crystals connected to the junction for each - junction. + Set of tuples of identifier of crystals connected to the junction for each + junction. - - + + - The specific identifier to instances of crystal identifiers whereby to resolve - ambiguities. + The specific identifier to instances of crystal identifiers whereby to resolve + ambiguities. - + - Set of tuples of identifier of interfaces connected to the junction for each - junction. + Set of tuples of identifier of interfaces connected to the junction for each + junction. - - + + - The specific identifier to instances of interface identifiers whereby to resolve - ambiguities. + The specific identifier to instances of interface identifiers whereby to resolve + ambiguities. - + - Set of tuples of identifier for triple junctions connected to the junction for - each quadruple junction. + Set of tuples of identifier for triple junctions connected to the junction for + each quadruple junction. - - + + - The specific identifier to instances of triple junction identifiers whereby to - resolve ambiguities. + The specific identifier to instances of triple junction identifiers whereby to + resolve ambiguities. - + - Set of tuples of identifier for phases of crystals connected to the junction for - each quadruple junction. + Set of tuples of identifier for phases of crystals connected to the junction for + each quadruple junction. - - + + - The specific identifier to instances of phase identifier whereby to resolve - ambiguities. + The specific identifier to instances of phase identifier whereby to resolve + ambiguities. - + - True or false value, one for each crystal, to communicate whether that feature - makes contact with the edge of the ROI. + True, if the junction makes contact with the edge of the ROI. + True, if the junction does not make contact with the edge of the ROI. - - + + - Energy of the quadruple_junction as a defect. + Energy of the quadruple_junction as a defect. - - + + - Non-intrinsic mobility of each quadruple_junction. + Non-intrinsic mobility of each quadruple_junction. - - + + diff --git a/contributed_definitions/NXmicrostructure_feature.nxdl.xml b/contributed_definitions/NXmicrostructure_feature.nxdl.xml new file mode 100644 index 0000000000..0a341174c2 --- /dev/null +++ b/contributed_definitions/NXmicrostructure_feature.nxdl.xml @@ -0,0 +1,37 @@ + + + + + + Base class for documenting structuring features of a microstructure. + + Instances of the class enable sub-grouping of microstructural features + as the abstract base class NXobject should not be used for this purpose. + + + + The chemical composition of this microstructural feature + or set of such features. + + + diff --git a/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml b/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml deleted file mode 100644 index e078938cfa..0000000000 --- a/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml +++ /dev/null @@ -1,369 +0,0 @@ - - - - - - - Application definition for configuring GraGLeS. - - GraGLeS is a continuum-scale model for shared-memory-parallelized simulations - of the isothermal evolution of 2D and 3D grain boundary networks with a level-set approach. - CPU parallelization is achieved with OpenMP. - - The code has been implemented by C. Mießen in the group of G. Gottstein - at the Institute für Metallkunde und Metallphysik, RWTH Aachen University. - - Details of the model are summarized in `C. Mießen <https://publications.rwth-aachen.de/record/709678>`_. - - - - - - - - - - Simulation ID as an alias to refer to this simulation. - - - - - Discouraged free-text field to add further details to the computation. - - - - - - - - - - - - - - - Programs and libraries representing the computational environment - - - - - - - - - - - - From which file should the microstructure be instantiated. - - - - - - - - - The formulation of mean curvature flow in the GraGLeS model is scale invariant. - Therefore, the discretization has to be scaled to the actual physical length - of the simulation domain (ve, ROI). - For GraGLeS the discretization is always a square or cubic axis-aligned - bounding box with a regular tiling into material points - (either squares or cubes respectively). - - Edge_length is the length of the entire domain along its edge not - the length of the Wigner-Seitz cell about each material point! - - - - - - Configuration when snapshots of the system should be taken. - - Keep in mind that essentially geometry snapshot data store the - polylines and polyhedra of all grains which can take substantial disk - space. - - - - Generate a snapshot of the properties of the grains to follow - the evolution of the microstructure every :math:`n`-th iteration. - Setting zero causes that no property snapshots are taken. - - - - - Generate a snapshot of the geometry of the entire grain boundary network - every :math:`n`-th iteration. Setting zero instructs to store no geometry data. - - - - - - - Configuration when the simulation should be stopped in a controlled manner. - Whichever criterion is fulfilled first triggers the controlled stop of - and termination of GraGLeS. - - - - The simulation stops if the total number of grains - becomes smaller than this criterion. - - - - - The simulation stops if more iterations than this criterion have been computed. - - - - - - Configuration of numerical details of the solver. - - - - - Which type of convolution kernel and model is used. - - - - - - - - - - Constant to calibrate the real time scaling of the simulation. - - - - - - - Configuration of the grid coarsement algorithm whereby the representation - of the system is continuously rediscretized such that on average grains - are discretized with discretization many material points along each - direction. - - Grid coarsement can reduce the computational costs substantially although - it cannot be ruled out completely that the rediscretizing may have an effect - on the system evolution. Without grid coarsement the total number of material - points to consider stays the same throughout the simulation. - - - - Number of material points along each direction to discretize the - average grain. The larger this value is chosen the finer the curvature - details are that can be resolved but also the longer the simulation - takes. - - - - - If true grid coarsement is active, otherwise it is not. - - - - - Fraction how strongly the number of grains has to reduce - to trigger a grid coarsement step in an iteration. - - - - - - - Physically-based model of the assumed mobility of the grain boundaries. - - Grain boundary mobility is not an intrinsic property of a grain boundary but system-dependent - especially as grain boundaries in reality are decorated with defects as a consequence of which - the actual mobility is a combination of the mobility of the individual defects and the attached - boundary patches. Grain boundaries have different degrees of microscopic freedom. - Therefore, their mobility follows a distribution. - - - - - Fundamental model how :math:`m` is assumed a function of the disorientation - angle :math:`\Theta`. - - - - - - - - - The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed - temperature. GraGLeS was developed for modelling isothermal annealing. - - - - - Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not one. - - - - - - Mobility scaling factor :math:`c_2`. Typically 5. - - - - - Mobility scaling factor :math:`c_3`. Typically 9. - - - - - - Physically-based model of the assumed grain boundary surface energy. - - Like for the grain boundary mobility, defects cause a distribution of energies for the - patches of which the boundary is composed. In practice a too complicated dependency - of the energy and mobility model is observed as a function of the type and chemical - decoration of the defects. Therefore, simplifying assumptions are typically made. - - - - Fundamental type of assumption if energies are considered isotropic or not. - - - - - - - - - Fundamental model how :math:`\gamma` is assumed a function of the disorientation - angle :math:`\Theta`. - - - - - - - - Mean grain boundary surface energy that is assumed a function of the - disorientation angle :math:`\Theta` of the adjoining grains :math:`\gamma(\Theta)`. - This value factorizes the curvature_driving_force model. - - - - - - - A continuum-scale curvature of an interface causes the interface to - migrate towards the center of the curvature radius. - - - - If true the curvature_driving_force is considered, otherwise it is not. - - - - - - A continuum-scale difference of the stored elastic energy in dislocation - configurations across a grain boundary can exert a driving force on the - grain boundary such that the boundary migrates into the volume with the - higher stored elastic energy. - - - - If true the dislocation_driving_force is considered, otherwise it is not. - - - - - Prefactor :math:`0.5Gb^2` that factorizes the average - stored elastic energy per length dislocation line. - - - - - - In case of an applied magnetic field, a difference of the magnetic - susceptibility can exert a driving force on the grain boundary such that - the boundary migrates into the volume with the higher magnetic energy. - - - - If true the magnetic_driving_force is considered, otherwise it is not. - - - - - - - A triple line mediates the atomic arrangement differences between three - interface patches. Therefore, the triple line is a defect that may not - have the same mobility as adjoining grain boundaries and thus it may - exert what can be conceptualized as a drag (resistance) to the motion - of the adjoining interface patches. - - - - Assumed triple junction drag. - - - - - - diff --git a/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml b/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml deleted file mode 100644 index 2f25c33a61..0000000000 --- a/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml +++ /dev/null @@ -1,295 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of summary statistic log entries. - - - - - Number of grains in the computer simulation. - - - - - Number of interfaces in the computer simulation. - - - - - Application definition for documenting results with GraGLeS. - - - - - - - - - - - Simulation ID as an alias to refer to this simulation. - - - - - Discouraged free-text field to add further details to the computation. - - - - - - - - - - - - - - Programs and libraries representing the computational environment - - - - - - - - - - - - - - - - - - - - - - - - - - - - Documentation of the spatiotemporal evolution - - - - - Summary quantities which are the result of some post-processing of the snapshot data - (averaging, integrating, interpolating) happening in for practical reasons though in while - running the simulation. Place used for storing descriptors from continuum mechanics - and thermodynamics at the scale of the entire ROI. - - - - Evolution of the recrystallized volume fraction over time. - - - - Evolution of the physical time not to be confused with wall-clock time or - profiling data. - - - - - - - - Iteration or increment counter. - - - - - How many crystals are distinguished. - Crystals are listed irrespective of the phase to which these are assigned. - - - - - - - - - - Which type of stress. - - - - - - - - Applied external stress tensor on the ROI. - - - - - - - - - - - - Which type of strain. - - - - - Applied external strain tensor on the ROI. - - - - - - - - - - - - Which type of deformation gradient. - - - - - - - - Applied deformation gradient tensor on the ROI. - - - - - - - - - - - - Applied external magnetic field on the ROI. - - - - - - - - - - - - - Applied external electrical field on the ROI. - - - - - - - - - - - - - - - - Simulated temperature for this snapshot. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Set of pairs of crystal_identifier for each interface. - - - - - - - - - - Mobility times surface energy density of the interface normalized - to the maximum such product of the interface set. - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml b/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml deleted file mode 100644 index a98be4dd41..0000000000 --- a/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml +++ /dev/null @@ -1,244 +0,0 @@ - - - - - - - - How many texture components are distinguished, minimum is 1. - - - - - How many special texture components are distinguished if any. - - - - - Number of discrete orientations that are distributed across the grains. - - - - - Application definition for the configuration of the legacy (micro)structure generator - developed by the Institut für Metallkunde und Metallphysik at RWTH Aachen University. - - * `N. Leuning et al. <https://doi.org/10.3390/ma14216588>`_ - * `C. Mießen <https://doi.org/10.18154/RWTH-2017-10148>`_ - * `M. Kühbach <https://doi.org/10.18154/RWTH-2018-00294>`_ - * `M. Kühbach et al. <https://github.com/mkuehbach/GraGLeS>`_ - - The tool can be used to instantiate specific configurations for two- and three-dimensional discretized microstructures. - Specifically, single-phase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. - Grains are modelled as elongated crystals to mimic fundamental geometrical constraints of the interface network in deformed material. - - - - - - - - - - The computational domain will be synthesized either as a square (for dimensionality = 2) - or a cube (for dimensionality = 3) with axis-aligned cuboidal parent grains. The domain is - discretized into material points using either square pixel or cubic voxel as the tessellating - unit cells. - - - - Two-dimensional or three-dimensional simulation. - - - - - - - - - Target value for the number of material points per equivalent - discrete diameter of the arithmetic average sub-grain. - - - - - Assumed space group of the material. - - - - - - - - - - - Target value for the number of grains. The actual domain size and grid will be configured - based on the choices for discretization, number_of_grains, and shape of these grains. - - - - - Target value for the average number of sub-grains per grain. - - - - - - If available used to define the sequence of relative extent of grains along the y (first value) - and z-axis (second value) assuming the relative shape along the x-axis is 1. If not provided, - the relative extent of the grains will be 1 one average along each axis (globulitic structure). - - - - - - - - - - In texture research component analyses set on the idea that properties - of grains different based on orientation with certain regions in orientation - space show similar trends like a different average dislocation density - or orientation_spread. - - - - The first entry is always the null model None which measn that an orientation - is not categorized as a special component. Examples for special components are - Dillamore, Copper, Cube, Y, P and Q. - - - - - - - - Bunge-Euler angle parameterization of the texture components - location in orientation space for which specifically different settings - should be configured. - - - - - - - - - Disorientation angle below which an orientation is categorized as one of the - components. - - - - - - - - - Dislocations are modelled as Rayleigh-distributed mean-field density that - can differ between but is constant within grains and sub-grains. - - - - The minimum and the maximum dislocation density to distribute across grains. - - - - - - - - - The minimum and the maximum dislocation density to distribute across sub-grains. - - - - - - - - - - - The variance of the dislocation density distribution across the grains. - - - - - - - - The variance of the dislocation density distribution across the sub-grains. - - - - - - - - - Orientations of the grains are sampled from a set of Bunge-Euler angle triplets. - Orientations of the sub-grains are sampled by scattering the orientation - of the (parent) grain and with optional Rayleigh-distributed scatter. - - - - Bunge-Euler angle parameterization of the texture components - location in orientation space for which specifically different settings - should be configured. - - - - - - - - - The variance of the disorientation of the sub-grain to their parent grain. - - - - - - - - - diff --git a/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml b/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml deleted file mode 100644 index 7d0dabed31..0000000000 --- a/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml +++ /dev/null @@ -1,189 +0,0 @@ - - - - - - - - Number of material points along the edge of the square- or cube-shaped domain. - - - - - Number of crystals. - - - - - Application definition for the results of the legacy (micro)structure generator developed - by the Institut für Metallkunde und Metallphysik at RWTH Aachen University. - - * `N. Leuning et al. <https://doi.org/10.3390/ma14216588>`_ - * `C. Mießen <https://doi.org/10.18154/RWTH-2017-10148>`_ - * `M. Kühbach <https://doi.org/10.18154/RWTH-2018-00294>`_ - * `M. Kühbach et al. <https://github.com/mkuehbach/GraGLeS>`_ - - The tool can be used to instantiate specific configurations for two- and three-dimensional discretized microstructures. - Specifically, single-phase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. - Grains are modelled as elongated crystals to mimic fundamental geometrical constraints of the interface network in deformed material. - - - - - - - - - - Discouraged free-text field to add further details to the computation. - - - - - - - - - - - - - - - Programs and libraries representing the computational environment - - - - - - - - - - - - - - Default plot showing the grid. - - - - - - - - Crystal identifier that was assigned to each material point. - - - - - - Material point barycentre coordinate along z direction. - - - - - - - Coordinate along z direction. - - - - - - Material point barycentre coordinate along y direction. - - - - - - - Coordinate along y direction. - - - - - - Material point barycentre coordinate along x direction. - - - - - - - Coordinate along x direction. - - - - - - - - - - - - - - - - - - - - - - - - - - True if the crystal is considered a sub-grain. - False if the crystal is considered a grain. - - - - - - - - Bunge-Euler angle orientation of each crystal. - - - - - - - - - Mean-field dislocation density as a measure of the stored elastic energy - content that is stored in the dislocation network of this grain and related - defects within each crystal. - - - - - - - - - diff --git a/contributed_definitions/NXmicrostructure_ipf.nxdl.xml b/contributed_definitions/NXmicrostructure_ipf.nxdl.xml index 38256637b9..59ae193e3d 100644 --- a/contributed_definitions/NXmicrostructure_ipf.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_ipf.nxdl.xml @@ -1,9 +1,9 @@ - + + + + Number of pixel along the slow direction used for the IPF color key. + + + + + Number of pixel along the fast direction used for the IPF color key. + + - Number of pixel along the z slowest direction. + Number of pixel along the slowest direction, typically labeled z or k. - Number of pixel along the y slow direction. + Number of pixel along the slow direction, typically labeled y or j. - Number of pixel along the x fast direction. + Number of pixel along the fast direction, typically labeled x or i. - Number of RGB values along the fastest direction, always three. + Number of RGB values along the fastest direction, always three. - Base class to store an inverse pole figure (IPF) mapping (IPF map). + Base class to store an inverse pole figure (IPF) mapping (IPF map). - Reference to an :ref:`NXcoordinate_system` in which the projection_direction is defined. - - If the field depends_on is not provided but parents of the instance of this base class or its - specializations define an instance of :ref:`NXcoordinate_system`, projection_direction - is defined in this coordinate system. - - If nothing is provided it is assumed that projection_direction is defined in the McStas coordinate system. + Reference to an instance of :ref:`NXcoordinate_system` in which the axes axis_z, + axis_y, and axis_x are defined. + + + The algorithm whereby orientations are colored. + + + + + + - The direction along which orientations are projected. + The direction normal vector along which orientations are projected. + + + Reference to an instance of :ref:`NXcoordinate_system` in which the projection_direction is defined. + + If the field depends_on is not provided but parents of the instance of this base class or its + specializations define an instance of :ref:`NXcoordinate_system`, projection_direction + is defined in this coordinate system. + + If nothing is provided, it is assumed that projection_direction is defined in the McStas coordinate system. + + - Details about the original grid. - - Here original grid means the grid for which the IPF map was computed when that - IPF map was exported from the tech partner's file format representation. + Details about the original grid, i.e. the grid for which the IPF map was computed + when that IPF map was exported from the tech partner's file format representation. - Details about the grid onto which the IPF is recomputed. - - Rescaling the visualization of the IPF map may be needed to enable - visualization in specific software tools like H5Web. + Details about the grid onto which the IPF is recomputed. + + Rescaling the visualization of the IPF map may be needed to enable + visualization in specific software tools like H5Web. - How where orientation values at positions of input_grid computed to values on output_grid. - - Nearest neighbour means the orientation of the closed (Euclidean distance) grid point of the input_grid was taken. + How where orientation values at positions of input_grid computed to values on output_grid. + + Nearest neighbour means the orientation of the closed (Euclidean distance) grid point of the input_grid was taken. @@ -94,150 +117,129 @@ - Inverse pole figure mapping. - - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - Inspect the definition of :ref:`NXcrystal_structure` and its field - phase_identifier for further details. - - Details about possible regridding and associated interpolation - during the computation of the IPF map visualization can be stored - using the input_grid, output_grid, and interpolation fields. - - The main purpose of this map is to offer a normalized default representation - of the IPF map for consumption by a research data management system (RDMS). - This is aligned with the first aim of :ref:`NXmicrostructure_ipf`, to bring colleagues - and users of IPF maps together to discuss which pieces of information need storage. - - We are convinced a step-by-step design and community-driven discussion is a practical - strategy to work towards an interoperable description and data model for exchanging - IPF maps as a specific community-accepted method to convey orientation maps. - - With this design the individual RDMS solutions and tools can still continue - to support specific custom data analyses workflow and routes but at least - there is one common understanding which enables also those users who are - not necessarily experts in all the details of the underlying techniques an - understanding if the dataset is worth to become reused or repurposed. + Inverse pole figure mapping. + + Instances named phase0 should by definition refer to the null phase notIndexed. + Inspect the definition of :ref:`NXphase` and its field phase_id + for further details. + + Details about possible regridding and associated interpolation + during the computation of the IPF map visualization can be stored + using the input_grid, output_grid, and interpolation fields. + + The main purpose of this map is to offer a normalized default representation + of the IPF map for consumption by a research data management system (RDMS). - - - Inverse pole figure color code for each map coordinate. + Inverse pole figure color code for each map coordinate. + + Different types of AXISNAME dimensional scale axes are found in practice. A few examples: + + * No scaling, e.g. pixel position values like 0, 1, 2, 3 pixel. + Pixels on the map can be distinguished but that map is disconnected from + any sample surface context and eventually physical scaling + * Scaling but no offset, e.g. calibrated pixel position 0., 0.5, 1.0, 1.5 micron. + Pixels on the map can be compared for their distance to obtain e.g. size of features + but the position of the map relative to the e.g. the sample surface is unclear. + For IPF maps this is the most frequently reported situation. + * Scaling and offset, which resolves also the absolute position of the map in + relation to the sample surface. This is useful information for stitching multiple + mappings together and other processing where precise and accurate + position data are relevant e.g. for correlative materials characterization. + + Three types of dimensional constraints for maps are possible: + + * (n_x, 3), a one-dimensional map, + typically used for coarse sampling and crystal size statistics. + * (n_y, n_x, 3), a two-dimensional map, + the most frequently found reported + * (n_z, n_y, n_x, 3), a three-dimensional map, + these are commonly generated using computational methods, + or in cases multiple EBSD maps have been stitched/reconstructed + into a three-dimensional map. - - - - - + - Pixel center coordinate calibrated for step size along the z axis of the map. + Pixel center coordinate calibrated for step size along the z axis of the map. - - Pixel center coordinate calibrated for step size along the y axis of the map. + Pixel center coordinate calibrated for step size along the y axis of the map. - - Pixel center coordinate calibrated for step size along the x axis of the map. + Pixel center coordinate calibrated for step size along the x axis of the map. - - The color code which maps colors to orientation in the fundamental zone. - - For each stereographic standard triangle (SST), i.e. a rendering of the - fundamental zone of the crystal-symmetry-reduced orientation space - SO3, it is possible to define a color model which assigns a color to each - point in the fundamental zone. - - Different mapping models are used. These implement (slightly) different - scaling relations. Differences exist across representations of tech partners. - - Differences are which base colors of the RGB color model are placed in - which extremal position of the SST and where the white point is located. - - For further details see: - - * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - * [S. Patala et al.](https://doi.org/10.1016/j.pmatsci.2012.04.002). - - Details are implementation-specific and not standardized yet. - - Given that the SST has a complicated geometry, it can not yet be - visualized using tools like H5Web, which is why for now the matrix - of a rasterized image which is rendered by the backend tool gets - copied into an RGB matrix to offer a default plot. + The color code which maps color to orientation in the fundamental zone. + + For each stereographic standard triangle (SST), i.e. a rendering of the + fundamental zone of the crystal-symmetry-reduced orientation space + SO3, it is possible to define a color model which assigns a color to each + point in the fundamental zone. + + Different mapping models are used. These implement (slightly) different + scaling relations. Differences exist across representations of tech partners. + + Differences are which base colors of the RGB color model are placed in + which extremal position of the SST and where the white point is located. + + For further details see: + + * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + * [S. Patala et al.](https://doi.org/10.1016/j.pmatsci.2012.04.002). + + Details are implementation-specific and not standardized yet. - - - + + + - Inverse pole figure color code for each map coordinate. + Inverse pole figure color code for each map coordinate. - - + + - Pixel along the y-axis. + Pixel along the y-axis. - + - - Pixel along the x-axis. + Pixel along the x-axis. - + - diff --git a/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml b/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml index 5b85f6473d..40dc06c9f8 100644 --- a/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml @@ -1,9 +1,9 @@ - + - + @@ -100,70 +100,70 @@ - Default plot showing the grid. + Default plot showing the grid. - + - + - Crystal identifier that was assigned to each material point. + Crystal identifier that was assigned to each material point. - Material point barycentre coordinate along z direction. + Material point barycenter coordinate along z direction. - Coordinate along z direction. + Coordinate along z direction. - Material point barycentre coordinate along y direction. + Material point barycenter coordinate along y direction. - Coordinate along y direction. + Coordinate along y direction. - Material point barycentre coordinate along x direction. + Material point barycenter coordinate along x direction. - Coordinate along x direction. + Coordinate along x direction. - + - + - + @@ -180,7 +180,7 @@ - Bunge-Euler angle orientation of each crystal. + Bunge-Euler angle orientation of each crystal. diff --git a/contributed_definitions/NXmicrostructure_mtex_config.nxdl.xml b/contributed_definitions/NXmicrostructure_mtex_config.nxdl.xml index 2dae22c987..a9c13a13b3 100644 --- a/contributed_definitions/NXmicrostructure_mtex_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_mtex_config.nxdl.xml @@ -1,9 +1,9 @@ - + - + - Number of entries in the default color map + Number of entries in the default color map - Number of entries in color map + Number of entries in color map - Base class to store the configuration when using the MTex/Matlab software. - - MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. - See `R. Hielscher et al. <https://mtex-toolbox.github.io/publications>`_ and - the `MTex source code <https://github.com/mtex-toolbox>`_ for details. + Base class to store the configuration when using the MTex/Matlab software. + + MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. + See `R. Hielscher et al. <https://mtex-toolbox.github.io/publications>`_ and + the `MTex source code <https://github.com/mtex-toolbox>`_ for details. - Reference frame and orientation conventions. - Consult the `MTex docs <https://mtex-toolbox.github.io/EBSDReferenceFrame.html>`_ for details. + MTex reference frame and orientation conventions. + Consult the `MTex docs <https://mtex-toolbox.github.io/EBSDReferenceFrame.html>`_ for details. - TODO with MTex developers + TODO with MTex developers - TODO with MTex developers + TODO with MTex developers - TODO with MTex developers + TODO with MTex developers - TODO with MTex developers + TODO with MTex developers - TODO with MTex developers + TODO with MTex developers @@ -84,51 +84,51 @@ check against v5.12--> - Settings relevant for generating plots. + Settings relevant for generating plots. - TODO with MTex developers + TODO with MTex developers - TODO with MTex developers + TODO with MTex developers - TODO with MTex developers + TODO with MTex developers - TODO with MTex developers + TODO with MTex developers - TODO with MTex developers + TODO with MTex developers - True if MTex renders a scale bar with figures. + True, if MTex renders a scale bar with figures. - True if MTex renders a grid with figures. + True, if MTex renders a grid with figures. - Code for the function handle used for annotating pole figure plots. + Code for the function handle used for annotating pole figure plots. - TODO with MTex developers + TODO with MTex developers @@ -137,7 +137,7 @@ check against v5.12--> - TODO with MTex developers + TODO with MTex developers @@ -145,175 +145,179 @@ check against v5.12--> +doc: | +TODO with MTex developers +unit: NX_UNITLESS--> - TODO with MTex developers + TODO with MTex developers - TODO with MTex developers + TODO with MTex developers - TODO with MTex developers + TODO with MTex developers - TODO with MTex developers + TODO with MTex developers - TODO with MTex developers + TODO with MTex developers - TODO with MTex developers + TODO with MTex developers - Miscellaneous other settings of MTex. + Miscellaneous other settings of MTex. - TODO with MTex developers + TODO with MTex developers - TODO with MTex developers + TODO with MTex developers - TODO with MTex developers + TODO with MTex developers - TODO with MTex developers + TODO with MTex developers - TODO with MTex developers + TODO with MTex developers + + + + + TODO with MTex developers - - Miscellaneous settings relevant for numerics. + Miscellaneous settings relevant for numerics. - Return value of the Matlab eps command. + Return value of the Matlab eps command. - TODO with MTex developers + TODO with MTex developers - TODO with MTex developers + TODO with MTex developers - TODO with MTex developers + TODO with MTex developers - Miscellaneous settings relevant of the system where MTex runs. + Miscellaneous settings relevant of the system where MTex runs. - TODO with MTex developers + TODO with MTex developers - TODO with MTex developers + TODO with MTex developers - TODO with MTex developers + TODO with MTex developers - Collection of paths from where MTex reads information and code. + Collection of paths from where MTex reads information and code. - Absolute path to specific component of MTex source code. + Absolute path to specific component of MTex source code. - Absolute path to specific component of MTex source code. + Absolute path to specific component of MTex source code. - Absolute path to specific component of MTex source code. + Absolute path to specific component of MTex source code. - Absolute path to specific component of MTex source code. + Absolute path to specific component of MTex source code. - Absolute path to specific component of MTex source code. + Absolute path to specific component of MTex source code. - Absolute path to specific component of MTex source code. + Absolute path to specific component of MTex source code. - Absolute path to specific component of MTex source code. + Absolute path to specific component of MTex source code. - Absolute path to specific component of MTex source code. + Absolute path to specific component of MTex source code. - Absolute path to specific component of MTex source code. + Absolute path to specific component of MTex source code. - List of file type suffixes for which MTex assumes - texture/pole figure information. + List of file type suffixes for which MTex assumes + texture/pole figure information. - List of file type suffixes for which MTex assumes EBSD content. + List of file type suffixes for which MTex assumes EBSD content. diff --git a/contributed_definitions/NXmicrostructure_odf.nxdl.xml b/contributed_definitions/NXmicrostructure_odf.nxdl.xml index 764e0ab77d..0d795855b6 100644 --- a/contributed_definitions/NXmicrostructure_odf.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_odf.nxdl.xml @@ -1,9 +1,9 @@ - + - + - Number of pixel per varphi section plot along the :math:`\varphi_1` fastest - direction. + Number of pixel per varphi section plot along the :math:`\varphi_2` slow + direction. - Number of pixel per varphi section plot along the :math:`\Phi` fast direction. + Number of pixel per varphi section plot along the :math:`\Phi` fast direction. - + - Number of pixel per varphi section plot along the :math:`\varphi_2` slow - direction. + Number of pixel per varphi section plot along the :math:`\varphi_1` fastest + direction. - Number of local maxima evaluated in the component analysis. + Number of local maxima evaluated in the component analysis. - Number of sampled positions in orientation space. + Number of sampled positions in orientation space. - Base class to store an orientation distribution function (ODF). - - An orientation distribution function is a probability distribution that details how - much volume of material has a specific orientation. An ODF is computed from - pole figure data in a computational process called `pole figure inversion <https://doi.org/10.1107/S0021889808030112>`_. + Base class to store an orientation distribution function (ODF). + + An orientation distribution function is a probability distribution that details how + much volume of material has a specific orientation. An ODF is computed from + pole figure data in a computational process called `pole figure inversion <https://doi.org/10.1107/S0021889808030112>`_. - + - Details about the algorithm used for computing the ODF. + Details about the algorithm used for computing the ODF. - Point group of the crystal structure of the phase for which the here documented phase- - dependent ODF was computed.(following the notation of the International Table of Crystallography). + Point group of the crystal structure of the phase for which the here documented + phase-dependent ODF was computed following the notation of the + International Table of Crystallography. - Point group assumed for additionally considered sample symmetries - following the notation of the International Table of Crystallography). + Point group assumed for additionally considered sample symmetries + following the notation of the International Table of Crystallography. - Halfwidth of the kernel. + Halfwidth of the kernel. - Name of the kernel. + Name of the kernel. - Resolution of the kernel. + Resolution of the kernel. + + + + + + Group to store descriptors for a rough classification of an ODF. + + + + The texture index :math:`t = \int_{\mathcal{SO(3)}} f(R)^{2}dR` with :math:`f(R)`, denoting the ODF + is evaluated in orientation space :math:`\mathcal{SO(3)}`. + + The higher it is the texture index the sharper it is the ODF. - + - Group to store descriptors and summary statistics for extrema of the ODF. + Group to store descriptors and summary statistics for extrema of the ODF. - Minima or maxima, if extrema is set to minima values for location and volume_fraction - are sorted in increasing order. If extrema is set to maxima values for location and - volume_fraction are sorted in descreasing order. Therefore, the global extremum is - always the first entry in location and volume_fraction. + Minima or maxima, if extrema is set to minima values for location and volume_fraction + are sorted in increasing order. If extrema is set to maxima values for location and + volume_fraction are sorted in decreasing order. Therefore, the global extremum is + always the first entry in location and volume_fraction. @@ -109,20 +123,20 @@ - Number of local extrema evaluated + Number of local extrema evaluated - Disorientation threshold within which intensity of the ODF - is integrated for the component analysis. + Disorientation threshold within which intensity of the ODF + is integrated for the component analysis. - Euler angle representation :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` of the kth-most - maxima in decreasing order of the intensity maximum. + Euler angle representation :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` of the + kth-most maxima in decreasing order of the intensity maximum. @@ -131,27 +145,27 @@ - Integrated ODF intensity within a theta angular region of the orientation space (SO3) - about each location (obeying symmetries) as specified for each location. + Integrated ODF intensity within a theta angular region of the orientation space :math:`SO3` + about each location (obeying symmetries) as specified for each location. - + - The ODF intensity values (weights) as sampled with a software + The ODF intensity values (weights) as sampled with a software. - Sampling resolution + Sampling resolution - Bunge-Euler (i.e. ZXZ convention) locations of each position - in orientation space for which a weight was sampled. + Bunge-Euler (i.e. ZXZ convention) locations of each position + in orientation space for which a weight was sampled. @@ -160,7 +174,7 @@ - Weight at each sampled position following the order in euler. + Weight at each sampled position following the order in euler. @@ -169,23 +183,18 @@ - Visualization of the ODF intensity as discretized orthogonal sections through - orientation space parameterized using Bunge-Euler angles. - - This is one example of typical default plots used in the texture community in materials engineering. - - Mind that when parameterized using Euler angles the orientation space is a distorted space. - Therefore, equivalent orientations show intensity contributions in eventually multiple locations. + Visualization of the ODF intensity as discretized orthogonal sections through + orientation space parameterized using Bunge-Euler angles. + + This is one example of typical default plots used in the texture community in materials engineering. + + Mind that the orientation space is a distorted space when it using an Euler angle parameterization. + Therefore, equivalent orientations show intensity contributions in eventually multiple locations. - - ODF intensity at probed locations relative to the intensity of the null model of - a random texture. + ODF intensity at probed locations relative to the intensity of the null model of + a random texture. @@ -195,30 +204,27 @@ - Pixel center angular position along the :math:`\varphi_1` direction. + Pixel center angular position along the :math:`\varphi_1` direction. - - Pixel center angular position along the :math:`\Phi` direction. + Pixel center angular position along the :math:`\Phi` direction. - - Pixel center angular position along the :math:`\varphi_2` direction. + Pixel center angular position along the :math:`\varphi_2` direction. - diff --git a/contributed_definitions/NXmicrostructure_pf.nxdl.xml b/contributed_definitions/NXmicrostructure_pf.nxdl.xml index 01804b54bf..3c8285419c 100644 --- a/contributed_definitions/NXmicrostructure_pf.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_pf.nxdl.xml @@ -1,9 +1,9 @@ - + - Halfwidth of the kernel. + Halfwidth of the kernel. - Miller indices (:math:`(hkl)[uvw]`) to specify the pole figure. + Miller (:math:`(hkl)[uvw]`) or Miller-Bravais indices used to specify the pole + figure. - Resolution of the kernel. + Resolution of the kernel. - Pole figure. + Pole figure. - Pole figure intensity. + Pole figure intensity. @@ -92,23 +93,21 @@ - Pixel center along y direction in the equatorial plane of - a stereographic projection of the unit sphere. + Pixel center along y direction in the equatorial plane of + a stereographic projection of the unit sphere. - - Pixel center along x direction in the equatorial plane of - a stereographic projection of the unit sphere. + Pixel center along x direction in the equatorial plane of + a stereographic projection of the unit sphere. - diff --git a/contributed_definitions/NXmicrostructure_score_config.nxdl.xml b/contributed_definitions/NXmicrostructure_score_config.nxdl.xml index 082293a3e6..12ccf6dfb9 100644 --- a/contributed_definitions/NXmicrostructure_score_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_score_config.nxdl.xml @@ -1,9 +1,9 @@ - + - - - - + + + + Dimensionality of the simulation. + + + + + + + + A qualifier whether the sample is a real one or a virtual one. + + + + + + + + + List of comma-separated elements from the periodic table that are + contained in the specimen. If the specimen substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer research data management systems an + opportunity to parse the relevant elements without having to interpret + these from other sources. + - + - Programs and libraries representing the computational environment + Name of the program whereby this config file was created. - + + + + + + + Programs and libraries representing the computational environment + + - + - Relevant data to instantiate a starting configuration that is typically - a microstructure in deformed conditions where stored (elastic) energy - is stored in the form of crystal defects, which in the SCORE model are - is considered as mean-field dislocation content. + (Mechanical) properties of the material which scale the + amount of stored (elastic) energy in the system and + thus mainly affect recrystallization kinetics. - - - - Extend of each CA domain in voxel along the x, y, and z direction. - Deformation of sheet material is assumed. - The x axis is assumed pointing along the rolling direction. - The y axis is assumed pointing along the transverse direction. - The z axis is assumed pointing along the normal direction. - - - - + + + Reference shear modulus at zero Kelvin. + + + + + Magnitude of the Burgers vector at zero Kelvin. + + + + + + Melting temperature + + - + - Details how the deformed grains should be modelled. + Details about the geometry and properties of the polycrystal that represents the + starting configuration (typically a deformed microstructure) for the simulation. - + - Which model should be used to generate a starting microstructure. + Which model should be used to generate a starting microstructure. + + * cuboidal, a regular array of equally shaped cuboidal grains + * poisson_voronoi, a discretized poisson voronoi + * ebsd, a microstructure synthesized based on a simulated or measured EBSD orientation map + * damask, the result of a simulation from `DAMASK <https://damask-multiphysics.org>`_. @@ -138,9 +199,10 @@ + - Extent of each deformed grain in voxel along the - x, y, and z direction when type is cuboidal. + Extent of each deformed grain in voxel along the + x, y, and z direction when model is cuboidal. @@ -148,123 +210,154 @@ - Average spherical diameter when type is poisson_voronoi. + Average spherical diameter when model is poisson_voronoi. - + - Set of Bunge-Euler angles ( :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` ) - to sample orientations of deformed grains randomly from. + Settings for instantiating properties of deformed grains when model is cuboidal + or poisson. - - - - - - + + + Set of Bunge-Euler orientations (:math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` ) + out of which the orientations of deformed grains are sampled. + + + + + + + + + Set of stored elastic energy quantified as a dislocation density which is assigned + to deformed grains with orientations from bunge_euler with index queries matching + for the bunge_euler and stored_energy fields. + + + + + + + - The EBSD dataset from which the initial microstructure is - instantiated if model is ebsd. + Settings for instantiating properties of deformed grains from an + EBSD orientation map when model is cuboidal or poisson. - - - - + + + + + + + - Extent of the pixel of the EBSD orientation mapping assuming square-shaped - pixels. + Extent of the pixel of the EBSD orientation mapping assuming square-shaped pixels + or cube-shaped voxels respectively. - + + + + Settings for instantiating properties of deformed grains and nuclei when model + is damask. + + + + Name of the DREAM.3D HDF5 file that was instantiated from the + a previously performed DAMASK simulation. + + + + + + + + + - + - Phenomenological model according to which recrystallization nuclei - are placed into the domain and assumed growing. + Phenomenological model according to which recrystallization nuclei + are placed into the domain whose growth is studied with the simulation. - + - According to which model will the nuclei become distributed spatially: - - * csr, complete spatial randomness. - * custom, implementation specific. - * gb, nuclei placed at grain boundaries + According to which model will the nuclei become distributed spatially: + + * csr, complete spatial randomness + * custom, implementation-specific + * gb, nuclei placed at grain boundaries - - + - + - According to which model will the nuclei start to grow. + According to which model will the nuclei start to grow. - + - According to which model will the nuclei get their orientation assigned. + According to which model will the nuclei get their orientation assigned: + + * ensemble, picking randomly one from ensemble/bunge_euler + * random, picking randomly on the SO3 + * damask, picking based on information provided in deformation/damask - + + + - + + - Set of Bunge-Euler angles ( :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` ) - to sample orientations of nuclei randomly from. + Settings for instantiating properties of nuclei for recrystallizing grains. - - - - - - - - - (Mechanical) properties of the material which scale - the amount of stored (elastic) energy in the system and - thus mainly affect recrystallization kinetics. - - - - Shear modulus at zero Kelvin. - - - - - Magnitude at the Burgers vector at zero Kelvin. - - - - - - Melting temperature in degrees Celsius. - - + + + Set of Bunge-Euler orientations (:math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` ) + out of which the orientations of nuclei/recrystallized grains are sampled. + + + + + + + + + Incubation time which is assigned to deformed grains with orientations from bunge_euler + with index queries matching for the bunge_euler and stored_energy fields. + + + + + + - + - Model for the assumed mobility of grain boundaries with different disorientation - essentially implementing variations of Turnbull's model for - thermally-activated migration. + Model for the assumed mobility of grain boundaries with different disorientation + implemented as parameterized Turnbull's model for thermally-activated + grain boundary migration. - + - Which type of fundamental model for the grain boundary mobility. - - Grain boundaries with disorientation angle smaller than 15 degree are considered - as low-angle grain boundaries. Other grain boundaries are high-angle boundaries. + Which type of fundamental model for the grain boundary mobility. + + Grain boundaries with disorientation angle smaller than 15 degree are considered + as low-angle grain boundaries. Other grain boundaries are high-angle boundaries. @@ -273,270 +366,362 @@ TODO: add equation for the Rollett-Holm model the following equation--> - - - Parameter of the Sebald-Gottstein migration model. - - - - At which disorientation angle are grain boundary considered as high-angle grain - boundaries. - - + + + Parameter of the Sebald-Gottstein migration model. + + - Pre-exponential factor for low-angle grain boundaries. + Pre-exponential factor for low-angle grain boundaries. - Migration activation enthalpy for low-angle grain boundaries. + Migration activation enthalpy for low-angle grain boundaries. - Pre-exponential factor for high-angle grain boundaries. + Pre-exponential factor for high-angle grain boundaries. - Migration activation enthalpy for high-angle grain boundaries. + Migration activation enthalpy for high-angle grain boundaries. - Pre-exponential factor for particularly mobile boundaries. + Pre-exponential factor for high-angle grain boundaries which in + bicrystal or other tailored experiments showed a particular high + mobility. - Migration activation enthalpy for particularly mobile boundaries. + Migration activation enthalpy for high-angle grain boundaries which in + bicrystal or other tailored experiments showed a particular high + mobility. - + - Parameter of the Rollett-Holm migration model. + Parameter of the Rollett-Holm migration model. - + + + Pre-exponential factor for the fastest grain boundary in the system. + + + - The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed - temperature. GraGLeS was developed for modelling isothermal annealing. + Migration activation enthalpy for the fastest grain boundary in the system. - + - Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not one. + Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not 1. - + - Mobility scaling factor :math:`c_2`. Typically 5. + Mobility scaling factor :math:`c_2`. Typically 5. - + - Mobility scaling factor :math:`c_3`. Typically 9. + Mobility scaling factor :math:`c_3`. Typically 9. - + - Time-dependent reduction of the stored (elastic) energy to account for recovery. + Time-dependent reduction of the stored energy to account for recovery effects. - + - Which type of recovery model. + Which type of recovery model. - + - Reduction of the grain boundary migration speed due to the presence of dispersoids - through which the total grain boundary area of the recrystallization front can be reduced. + Reduction of the grain boundary migration speed due to the presence of dispersoids + through which the total grain boundary area of the recrystallization front can be reduced + while the boundary is arrested at the dispersoids. - + - Which type of drag model. + Which type of drag model. - + + - Parameter of the Zener-Smith drag model. + Parameter of the Zener-Smith drag model when model is zener_smith. - - - Configuration-dependent constant which factorizes the drag pressure. - - - + - Average surface energy of the grain-boundary-dispersoid-surface configuration - which factorizes the drag pressure. + Configuration-dependent constant which factorizes the drag pressure. - + - Support point of the linearized curve of simulated time matching - a specific support point of the average dispersoid radius. + Average surface energy of the grain-boundary-dispersoid-surface configuration + which factorizes the drag pressure. - - - - + + - Support point of the linearized curve of the average dispersoid radius. + Assumed dispersoid mean radius-time profile - - - - + + + + + + + + Support point of the linearized curve of simulated time matching + a specific support point of the average dispersoid radius. + + + + + + + + + Support point of the linearized curve of the average dispersoid radius. + + + + + + + - - - Desired simulated time-temperature profile - - + + - Support point of the linearized curve of simulated time matching - a specific support point of the temperature. + Given name of a texture component. - + - + + + Bunge-Euler angle representation :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` of the + of texture components in sequence of the name field. + + + + + + + - Support point of the linearized curve of the temperature. + Integration radius that constraints the theta angular region of the orientation space (SO3) + about each central location (obeying symmetries) as specified by bunge_euler indexed in + the same sequence as the bunge_euler and name fields. - + - + - Criteria which enable to stop the simulation in a controlled manner. - Whichever criterion is fulfilled first stops the simulation. + Desired simulated time-temperature profile - - - Maximum recrystallized volume fraction. - - - + + + + + + - Maximum simulated physical time. + Support point of the linearized curve of simulated time matching + a specific support point of the temperature. + + + + - + - Maximum number of iteration steps. + Support point of the linearized curve of the temperature. + + + + - + - Settings relevant for stable numerical integration. + Relevant data to instantiate a starting configuration that is typically + a microstructure in deformed conditions where (elastic) energy is stored + in the form of crystal defects (mostly dislocations). The SCORE model + does not resolve individual dislocations but works with one + homogenized mean-field density per grain. For simulations that are + instantiated from EBSD datasets or crystal plasticity simulations + individual values are available for each voxel that may be used as is + for each voxel or may need a pre-processing of the data to coarse-grain + material point-specific values to values averaged per deformed grain. - - - Maximum fraction equivalent to the migration of the - fastest grain boundary in the system how much a cell - may be consumed in a single iteration. - - - + + + + Extend of each CA domain in voxel along the x, y, and z direction. + Deformation of sheet material is assumed. + The x axis is assumed pointing along the rolling direction. + The y axis is assumed pointing along the transverse direction. + The z axis is assumed pointing along the normal direction. + + + + + + + + Edge length of the material point that in SCORE + is discretized via equisized cubic voxels. + + + + + + + + Criteria which enable to stop the simulation in a controlled manner. + Whichever criterion is fulfilled first stops the simulation. + Furthermore, numerical configuration required to achieve + a stable numerical integration. + + - Fraction of the total number of cells in the CA which - should initially be allocated for offering cells in the - recrystallization front. + Maximum recrystallized volume fraction. - + - By how much more times should the already allocated memory - be increased to offer space for storing states of cells - in the recrystallization front. + Maximum simulated physical time. - + - Should the cache for cells in the recrystallization front - be defragmented on-the-fly. + Maximum number of iteration steps. - + - Heuristic recrystallized volume target values at which - the cache for cells in the recrystallization front - will be defragmented on-the-fly. + Maximum fraction equivalent to the migration of the + fastest grain boundary in the system how much a cell + may be consumed in a single iteration. - - - - - - - - List of recrystallized volume target values at which a - snapshot of the CA state should be stored. - - The code documents summary statistics like recrystallized volume fraction - for each iteration. However, snapshots of the microstructure can take much - space as SCORE is able to evolve automata with up to :math:`1600^3` cells. - Snapshot data document the current microstructure which includes the grain - assigned to each of these cells plus the state of the recrystallization front. - - Despite these front data make up for approximately one order of magnitude - less cells than represented in the domain, more numerical data have to be - collected each cell in the front than just a grain identifier. + + + List of target values at which recrystallized volume fractions the state + of the CA is evaluated and stored. The code documents summary statistics + like recrystallized volume fraction for each iteration and the volume of each + grain. Furthermore, snapshots of the microstructure are stored. + These can take much disk space though because SCORE is able to evolve CA + with up to :math:`1600^3` cells. Snapshot data document the current microstructure + including the assignment of grains and cells surplus the state of the + recrystallization front. + + Despite these front data make up for approximately one order of magnitude + less cells than represented in the domain, more numerical data have to be + collected for each cell in the front than just a grain identifier. + + + Parameter which control the memory management + of cells in the recrystallization front. + + + + Fraction of the total number of cells in the CA which + should initially be allocated for offering storage for + cells making up the recrystallization front. + + + + + By how much more times should the already allocated memory + be increased to offer space for storing states of cells + in the recrystallization front. + + + + + Should the cache for cells in the recrystallization front + be defragmented on-the-fly or not. + + + + + Target values at which recrystallized volume fraction the cache + for cells in the recrystallization front will be defragmented + on-the-fly. Defragmentation packs active cells closer into + main memory to reduce cache misses in subsequent evaluations + of the recrystallization front. + + + + + + - + - Perform a statistical analyses of the results as it was - proposed by M. Kühbach (solitary unit model ensemble approach). + Perform a statistical analyses of the results as it was proposed + by M. Kühbach (solitary unit model ensemble approach). - How many independent cellular automaton domains - should be instantiated. + How many independent cellular automaton domains + should be instantiated. - Into how many time steps should the real time interval be discretized upon - during post-processing the results with the solitary unit modeling approach. + Into how many time steps should the real time interval be discretized upon + during post-processing the results with the solitary unit modeling approach. - - - List of identifier for those domain which should be rendered. - Identifier start from 0. - - - - - diff --git a/contributed_definitions/NXmicrostructure_score_results.nxdl.xml b/contributed_definitions/NXmicrostructure_score_results.nxdl.xml index 1e9283c976..b456748e3f 100644 --- a/contributed_definitions/NXmicrostructure_score_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_score_results.nxdl.xml @@ -1,9 +1,9 @@ - + - The symbols used in the schema to specify e.g. dimensions of arrays. + The symbols used in the schema to specify e.g. dimensions of arrays - The total number of summary statistic log entries. + The total number of summary statistic log entries - Number of boundaries of the bounding box or primitive to domain. + Number of boundaries of the bounding box or primitive about the computational + domain - Number of parameter required for chosen orientation parameterization. + Number of parameter required for chosen orientation parameterization - Number of texture components identified. + Number of texture components identified - Dimensionality. + Dimensionality - Cardinality. + Cardinality - Number of active cells in the (recrystallization) front. + Number of active cells in the (recrystallization) front - Number of grains in the computer simulation. + Number of grains in the computer simulation - Application definition for storing results of the SCORE cellular automaton. - - The SCORE cellular automaton model for primary recrystallization is an - example of typical materials engineering applications used within the field - of so-called Integral Computational Materials Engineering (ICME) whereby - one can simulate the evolution of microstructures. - - Specifically the SCORE model can be used to simulate the growth of static - recrystallization nuclei. The model is described in the literature: - - * `M. Kühbach et al. <https://doi.org/10.1016/j.actamat.2016.01.068>`_ - * `C. Haase et al. <https://doi.org/10.1016/j.actamat.2015.08.057>`_ - * `M. Diehl et al. <https://doi.org/10.1088/1361-651X/ab51bd>`_ + Application definition for storing results of the SCORE cellular automata model. + + The SCORE cellular automata model for primary recrystallization is an example + of a typical materials engineering application used within the field of so-called + Integral Computational Materials Engineering (ICME) whereby one can simulate + the evolution of microstructures. + + Specifically the SCORE model can be used to simulate the growth of nuclei during + static recrystallization. The model is described in the literature: + + * `M. Kühbach et al. <https://doi.org/10.1016/j.actamat.2016.01.068>`_ + * `C. Haase et al. <https://doi.org/10.1016/j.actamat.2015.08.057>`_ + * `M. Diehl et al. <https://doi.org/10.1088/1361-651X/ab51bd>`_ @@ -90,122 +91,143 @@ inspect comments behind NXmicrostructure--> - + - Simulation ID as an alias to refer to this simulation. + Simulation ID as an alias to refer to this simulation. - + - Discouraged free-text field to add further details to the computation. + Configuration file with the parameterization of the + SCORE model that was used for this simulation. + + + + + + + + Discouraged free-text field to add further details to the computation. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the simulation was started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the simulation ended. - - - + + - + + Name of the program with which the simulation was performed. + + - - + - Programs and libraries representing the computational environment + Programs and libraries representing the computational environment - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + - + - + - A tight bounding box or sphere or bounding primitive about the grid. + A tight bounding box or sphere or bounding primitive about the grid. - + - How many distinct boundaries are distinguished? - Most grids discretize a cubic or cuboidal region. In this case - six sides can be distinguished, each making an own boundary. + How many distinct boundaries are distinguished? + Most grids discretize a cubic or cuboidal region. In this case + six sides can be distinguished, each making an own boundary. - The boundary conditions for each boundary: - - 0 - undefined - 1 - open - 2 - periodic - 3 - mirror - 4 - von Neumann - 5 - Dirichlet + The boundary conditions for each boundary: + + * 0 - undefined + * 1 - open + * 2 - periodic + * 3 - mirror + * 4 - von Neumann + * 5 - Dirichlet @@ -213,8 +235,8 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele - Name of the boundaries. Left, right, front, back, bottom, top, - The field must have as many entries as there are number_of_boundaries. + Name of the boundaries. Left, right, front, back, bottom, top, + The field must have as many entries as there are number_of_boundaries. @@ -222,27 +244,37 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele - + - Documentation of the spatiotemporal evolution + Documentation of the spatiotemporal evolution for each CA domain. + + SCORE is a hybrid parallelized code that can evolve multiple replicas + in parallel. The set of replicas is distributed across MPI processes. + Each such replica is then evolved via OpenMP multi-threading. - - + + - Summary quantities which are the result of some post-processing of the snapshot data - (averaging, integrating, interpolating) happening in for practical reasons though in while - running the simulation. Place used for storing descriptors from continuum mechanics - and thermodynamics at the scale of the entire ROI. + Summary quantities which are the result of some post-processing of the snapshot data + (averaging, integrating, interpolating) happening for practical and performance reasons + during the simulation. Place used for storing descriptors from continuum mechanics + and thermodynamics at the scale of the entire ROI. - + - Evolution of the recrystallized volume fraction over time. + Evolution of the recrystallized volume fraction over time. - + + + + + + + + - Evolution of the physical time not to be confused with wall-clock time or - profiling data. + Evolution of the physical time not to be confused with wall-clock time or + profiling data. @@ -250,38 +282,41 @@ the typical lean summary statistics flattened--> - Iteration or increment counter. + Iteration or increment counter. + + + - Evolution of the simulated temperature over time. + Evolution of the simulated temperature over time. - + - Recrystallized volume fraction. + Recrystallized volume fraction. - - + + - Which type of stress. + Which type of stress. - + - Applied external stress tensor on the ROI. + Applied external stress tensor on the ROI. @@ -290,15 +325,15 @@ the typical lean summary statistics flattened--> - - + + - Which type of strain. + Which type of strain. - + - Applied external strain tensor on the ROI. + Applied external strain tensor on the ROI. @@ -310,40 +345,15 @@ the typical lean summary statistics flattened--> - Which type of deformation gradient. + Which type of deformation gradient. - - - Applied deformation gradient tensor on the ROI. - - - - - - - - - - - - Applied external magnetic field on the ROI. - - - - - - - - - - - + - Applied external electrical field on the ROI. + Applied deformation gradient tensor on the ROI. @@ -353,32 +363,50 @@ the typical lean summary statistics flattened--> - - - - + + + + + + Iteration or increment counter. + + - Simulated temperature for this snapshot. + Simulated temperature for this snapshot. - + - Current recrystallized volume fraction (taking fractional infections into - account). + Current recrystallized volume fraction (taking fractional infections into + account). - + - Target value for which a snapshot was requested for the recrystallized volume - fraction. + Target value for which a snapshot was requested for the recrystallized volume + fraction. - + - Grain identifier for each cell. + Index for each crystal whereby its metadata can be retrieved. @@ -386,9 +414,9 @@ the typical lean summary statistics flattened--> - + - Identifier of the OpenMP thread which processed this part of the grid. + Identifier of the OpenMP thread that processed this part of the grid. @@ -397,25 +425,25 @@ the typical lean summary statistics flattened--> - - - - - - + + + + + + - - + + - + - Volume of each grain accounting also for partially transformed cells. + Volume of each grain accounting also for partially transformed cells. @@ -424,7 +452,7 @@ the typical lean summary statistics flattened--> - Bunge-Euler angle triplets for each grain. + Bunge-Euler angle triplets for each grain. @@ -433,8 +461,8 @@ the typical lean summary statistics flattened--> - Current value for the dislocation density as a measure of the remaining stored energy - in assumed crystal defects inside each grain. + Current value for the dislocation density as a measure of the remaining + stored energy in assumed crystal defects inside each grain. @@ -442,7 +470,7 @@ the typical lean summary statistics flattened--> - Is the grain deformed. + Is the grain deformed. @@ -450,21 +478,21 @@ the typical lean summary statistics flattened--> - Is the grain recrystallized. + Is the grain recrystallized. - + - Details about those cells which in this time step represent the discrete - recrystallization front. + Details about those cells which in this time step represent the discrete + recrystallization front. - Which cells are currently in a halo region of threads. + Which cells are currently in a halo region of threads. @@ -472,9 +500,9 @@ the typical lean summary statistics flattened--> - So-called mobility weight which is a scaling factor to - control the mobility of the grain boundary which is assumed - to sweep currently this volume. + So-called mobility weight which is a scaling factor to control the + mobility of the grain boundary that is modelled sweeping cells that + make the discrete recrystallization front. @@ -482,34 +510,34 @@ the typical lean summary statistics flattened--> - The x, y, z grid coordinates of each cell in the recrystallization front. + The x, y, z grid coordinates of each cell in the recrystallization front. - + - Grain identifier assigned to each cell in the recrystallization front. + Grain identifier assigned to each cell in the recrystallization front. - + - Grain identifier assigned to each nucleus which affected that cell in the - recrystallization front. + Grain identifier assigned to each nucleus which affected that cell in the + recrystallization front. - + - Identifier of the OpenMP thread processing each cell in the recrystallization - front. + Identifier of the OpenMP thread processing each cell in the recrystallization + front. @@ -517,7 +545,7 @@ the typical lean summary statistics flattened--> - Hint about the direction from which the cell was infected. + Hint about the direction from which the cell was infected. @@ -527,17 +555,4 @@ the typical lean summary statistics flattened--> - diff --git a/contributed_definitions/NXmicrostructure_slip_system.nxdl.xml b/contributed_definitions/NXmicrostructure_slip_system.nxdl.xml index ec660d6de6..f9387095c3 100644 --- a/contributed_definitions/NXmicrostructure_slip_system.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_slip_system.nxdl.xml @@ -1,9 +1,9 @@ - + - Array of Miller indices which describe the crystallographic direction. + Array of Miller or Miller-Bravais indices that describe the crystallographic + direction. - + - For each slip system a marker whether the specified Miller indices refer to - a specific or a crystallographic equivalent set of the slip system. + For each slip system a marker whether the Miller indices refer to a specific slip system + or to a set of equivalent crystallographic slip systems. diff --git a/contributed_definitions/NXms.nxdl.xml b/contributed_definitions/NXms.nxdl.xml deleted file mode 100644 index 08a9f790a5..0000000000 --- a/contributed_definitions/NXms.nxdl.xml +++ /dev/null @@ -1,529 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of boundaries of the bounding box or primitive to domain. - - - - - Number of parameter required for the chosen orientation parameterization. - - - - - Number of texture components identified. - - - - - Application definition, spatiotemporal characterization of a microstructure. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment or computer simulation. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - - - - - Free-text description about the workflow (experiment/analysis/simulation). - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of this application definition rather than write details about the - experiment into this free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the characterization started. - - - - - ISO 8601 time code with local time zone offset to UTC included - when the characterization ended. - - - - - - - - - - Specify if the (characterization) results/data of this instance of an - application definition are based on the results of a simulation or the - results of a post-processing of measured data to describe - a microstructure. - - The term microstructure is used to describe the spatial arrangement of - crystal defects inside a sample/specimen without demanding necessarily - that this structure is mainly at the micron length scale. - Nanostructure and macrostructure are close synonyms. - Material architecture is a narrow synonym. - - Given that microstructure simulations nowadays more and more consider - the atomic arrangement, this application definition can also be used - to describe features at the scale of atoms. - - - - - - - - - Contact information and eventually details of at least one person - involved in creating this result. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service - should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - - Descriptive name or ideally (globally) unique persistent identifier. - - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - Container to hold different coordinate systems conventions. - A least a right-handed Cartesian coordinate system with base vectors - named x, y, and z has to be specified. Each base vector of the - coordinate system should be described with an NXtransformations instance. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The simulated or characterized material volume element aka domain. - At least one instance of geometry required either NXcg_grid, - NXcg_polyhedron, or NXcg_point. This geometry group needs - to contain details about the boundary conditions. - - - - - - - - A boundary to the volume element. - Either an instance of NXcg_hexahedron or of NXcg_ellipsoid. - - - - - How many distinct boundaries are distinguished. Value required equal to n_b. - - - - - Name of the boundaries. E.g. left, right, front, back, bottom, top, - - - - - - - - The boundary conditions for each boundary: - - 0 - undefined - 1 - open - 2 - periodic - 3 - mirror - 4 - von Neumann - 5 - Dirichlet - - - - - - - - - Collection of microstructural data observed/simulated. - - - - Integer which specifies the first index to be used for distinguishing - snapshots. Identifiers are defined either implicitly or explicitly. - For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate - if the identifiers are expected to start from 1 (referred to as - Fortran-/Matlab-) or from 0 (referred to as C-, Python-style index - notation) respectively. - - - - - - Summary quantities which are the result of some post-processing of - the snapshot data (averaging, integrating, interpolating). - Frequently used descriptors from continuum mechanics and thermodynamics - can be used here. A few examples are given. Each descriptor is currently - modelled as an instance of an NXprocess because it is relevant to - understand how the descriptors are computed. - - - - - - - - - - - - - - Measured or simulated physical time stamp for this snapshot. - Not to be confused with wall-clock timing or profiling data. - - - - - Iteration or increment counter. - - - - - - - - - - Conceptually distinguished object/feature in the ROI/ - system with some relevance. Instances of NXms_feature_set can - be nested to build a hierarchy of logically-related objects. - - A typical example for MD simulations is to have one - ms_feature_set for the atoms which is the parent to another - ms_feature_set for monomers/molecules/proteins which is then the - parent to another ms_feature_set for the secondary, another feature_set - for the tertiary, and the parent for another feature_set for the - quaternary structure. - - Another typical example from materials engineering is to have - one ms_feature_set for crystals (grains/phases) which serves as - the parent to another ms_feature_set for interfaces between these - crystals which then is the parent for another ms_feature_set to - describe the triple junctions which is then the parent for the - quadruple/higher-order junctions between which connect the - triple lines. - - Another example from discrete dislocation dynamics could be to - have one ms_feature_set for the dislocations (maybe separate - sets for each dislocation type or family) which are then - parents to other ms_feature_set which describe junctions between - dislocations or features along the dislocation line network. - - - - - - Details about the orientation distribution function - within the entire domain. - - - - With which method was the ODF approximated? - - - - - - TO BE DEFINED - - - - - TO BE DEFINED - - - - - Collection of texture components commonly referred to. - - - - Reference to or definition of a coordinate system with - which the definitions are interpretable. - - - - - - - - - - - Parameterized orientations. - - - - - - - - - Name of each texture component, e.g. Cube, Dillamore, Y. - - - - - - - - The portion of orientation space integrated over - to compute the volume fraction. - - - - - - - - The volume fraction of each texture component. - - - - - - - - - - - Details about the disorientation distribution function - within the entire domain. - - - - - Details about the grain boundary character distribution - within the entire domain. - - - - - - - - - - - - - - - - - - From e44f2cd2ae3f9b64648548d74507eea5c0d274d8 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 28 Aug 2025 11:01:15 +0200 Subject: [PATCH 0986/1012] small changes to NXtransmission --- .../NXtransmission.nxdl.xml | 176 +++++++----------- 1 file changed, 72 insertions(+), 104 deletions(-) diff --git a/contributed_definitions/NXtransmission.nxdl.xml b/contributed_definitions/NXtransmission.nxdl.xml index 15ed29e3b3..a8828674a5 100644 --- a/contributed_definitions/NXtransmission.nxdl.xml +++ b/contributed_definitions/NXtransmission.nxdl.xml @@ -27,37 +27,31 @@ Draft NeXus application definition for transmission experiments--> - Variables used throughout the experiment + Variables used throughout the experiment - Number of wavelength points + Number of wavelength points - Number of scans + Number of scans - Application definition for transmission experiments + Application definition for transmission experiments - - This application definition - - - An application definition for transmission. - Version number to identify which definition of this application definition was used for this entry/data. - + URL where to find further material (documentation, examples) relevant to the application definition. @@ -69,115 +63,91 @@ Draft NeXus application definition for transmission experiments--> - Start time of the experiment. + Start time of the experiment. - Unique identifier of the experiment, such as a (globally persistent) - unique identifier. - - * The identifier is usually defined by the facility or principle - investigator. - * The identifier enables to link experiments to e.g. proposals. + Unique identifier of the experiment, such as a (globally persistent) + unique identifier. + + * The identifier is usually defined by the facility or principle + investigator. + * The identifier enables to link experiments to e.g. proposals. - An optional free-text description of the experiment. However, details of the - experiment should be defined in the specific fields of this application - definition rather than in this experiment description. + An optional free-text description of the experiment. However, details of the + experiment should be defined in the specific fields of this application + definition rather than in this experiment description. - - Commercial or otherwise defined given name to the program that was - used to generate the result file(s) with measured data and metadata. + Commercial or otherwise defined given name to the program that was + used to generate the result file(s) with measured data and metadata. - Version number of the program that was used to generate the result - file(s) with measured data and metadata. + Version number of the program that was used to generate the result + file(s) with measured data and metadata. - Website of the software + Website of the software - + - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. - Name of the user. + Name of the user. - + - Name of the affiliation of the user at the point in time when the experiment was - performed. - - - - - Street address of the user's affiliation. - - - - - Email address of the user. - - - - - Author ID defined by reasearch id services, e.g. orcid (https://orcid.org/). - - - - - Telephone number of the user. + Name of the affiliation of the user at the point in time when the experiment was + performed. - Manufacturer of the instrument. + Manufacturer of the instrument. - Common beam mask to shape the incident beam + Common beam mask to shape the incident beam - The height of the common beam in percentage of the beam + The height of the common beam in percentage of the beam - If true, the incident beam is depolarized. + If true, the incident beam is depolarized. - Polarizer value inside the beam path + Polarizer value inside the beam path - Attenuator in the reference beam + Attenuator in the reference beam @@ -190,21 +160,22 @@ of instrument.--> - Wavelength value(s) used for the measurement. - An array of 1 or more elements. Length defines N_wavelenghts + Wavelength value(s) used for the measurement. + An array of 1 or more elements. Length defines N_wavelenghts - + - Overall spectral resolution of this spectrometer. - If several gratings are employed the spectral resoultion - should rather be specified for each grating inside the - NXgrating group of this spectrometer. + Overall spectral resolution of this spectrometer. + If several gratings are employed the spectral resoultion + should rather be specified for each grating inside the + NXgrating group of this spectrometer. - + + Diffraction grating, as could be used in a monochromator. @@ -214,25 +185,26 @@ of instrument.--> do not overlap. The dispersion should be defined for the entire wavelength range of the experiment. - + - Dispersion of the grating in nm/mm used. + Dispersion of the grating in nm/mm used. - The blaze wavelength of the grating used. + The blaze wavelength of the grating used. - + - Overall spectral resolution of the instrument - when this grating is used. + Overall spectral resolution of the instrument + when this grating is used. - + + - Wavelength range in which this grating was used + Wavelength range in which this grating was used @@ -243,7 +215,7 @@ of instrument.--> - Wavelength range in which this detector was used + Wavelength range in which this detector was used @@ -251,7 +223,7 @@ of instrument.--> - Detector type + Detector type @@ -261,17 +233,17 @@ of instrument.--> - Response time of the detector + Response time of the detector - Detector gain + Detector gain - Slit setting used for measurement with this detector + Slit setting used for measurement with this detector @@ -283,7 +255,7 @@ of instrument.--> - An array of relative scan start time points. + An array of relative scan start time points. @@ -291,11 +263,11 @@ of instrument.--> - Resulting data from the measurement. - The length of the 2nd dimension is - the number of time points. - If it has length one the time_points - may be empty. + Resulting data from the measurement. + The length of the 2nd dimension is + the number of time points. + If it has length one the time_points + may be empty. @@ -304,20 +276,20 @@ of instrument.--> - The lamp used for illumination + The lamp used for illumination - The type of lamp, e.g. halogen, D2 etc. + The type of lamp, e.g. halogen, D2 etc. - + - The spectrum of the lamp used + The spectrum of the lamp used @@ -325,7 +297,7 @@ of instrument.--> - Wavelength range in which the lamp was used + Wavelength range in which the lamp was used @@ -334,24 +306,20 @@ of instrument.--> - - Properties of the sample measured + Properties of the sample measured - A default view of the data emitted intensity vs. wavelength. - From measured_data plot intensity and wavelength. + A default view of the data emitted intensity vs. wavelength. + From measured_data plot intensity and wavelength. - We recommend to use wavelength as a default attribute, but it can be - replaced by any suitable parameter along the X-axis. + We recommend to use wavelength as a default attribute, but it can be + replaced by any suitable parameter along the X-axis. From 85833f2924b6bf53a21950c5d418555ef7c3f599 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 28 Aug 2025 11:03:50 +0200 Subject: [PATCH 0987/1012] bring in NXspatial_filter from fairmat repo --- .../NXspatial_filter.nxdl.xml | 47 ++++++++++--------- 1 file changed, 24 insertions(+), 23 deletions(-) diff --git a/contributed_definitions/NXspatial_filter.nxdl.xml b/contributed_definitions/NXspatial_filter.nxdl.xml index c131323976..32f9f8a8f5 100644 --- a/contributed_definitions/NXspatial_filter.nxdl.xml +++ b/contributed_definitions/NXspatial_filter.nxdl.xml @@ -1,9 +1,9 @@ - + - The symbols used in the schema to specify e.g. dimensions of arrays. + The symbols used in the schema to specify e.g. dimensions of arrays. - Number of hexahedra. + Number of hexahedra. - Number of cylinders. + Number of cylinders. - Number of ellipsoids. + Number of ellipsoids. - Number of polyhedra. + Number of polyhedra. - Base class for a spatial filter for objects within a region-of-interest (ROI). - - Objects can be points or objects composed from other geometric primitives. + Base class for a spatial filter for objects within a region-of-interest (ROI). + + Objects can be points or objects composed from other geometric primitives. - Qualitative statement which describes the logical operations - that define which objects will be included and which excluded: - - * entire_dataset, no filter is applied, all objects are included. - * union_of_primitives, a filter with (possibly non-axis-aligned) geometric - primitives. Objects in or on the surface of the primitives are included. - All other objects are excluded. - * bitmask, a boolean array whose bits encode with 1 which objects - are included. Bits set to zero encode which objects are excluded. - Users of python can use the bitfield operations - of the numpy package to work with bitfields. + Qualitative statement which describes the logical operations + that define which objects will be included and which excluded: + + * entire_dataset, no filter is applied, all objects are included. + * union_of_primitives, a filter with (possibly non-axis-aligned) geometric + primitives. Objects in or on the surface of the primitives are included. + All other objects are excluded. + * bitmask, a boolean array whose bits encode with 1 which objects + are included. Bits set to zero encode which objects are excluded. + Users of python can use the bitfield operations + of the numpy package to work with bitfields. - - + + + From 3018393e4280feeb9cb475117d5fa7065d4fc8f8 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 28 Aug 2025 11:07:14 +0200 Subject: [PATCH 0988/1012] bring in NXmatch_filter from fairmat repo --- .../NXmatch_filter.nxdl.xml | 28 +++++++++---------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/contributed_definitions/NXmatch_filter.nxdl.xml b/contributed_definitions/NXmatch_filter.nxdl.xml index fde6b345ab..5f6d3e81e7 100644 --- a/contributed_definitions/NXmatch_filter.nxdl.xml +++ b/contributed_definitions/NXmatch_filter.nxdl.xml @@ -1,9 +1,9 @@ - + - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). - - - - - Number of mass-to-charge-state-ratio range intervals for ion type. - - - - - Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. - - - - A unique identifier whereby such an ion can be referred to - via the service offered as described in identifier_type. - - - - - How can the identifier be resolved? - - - - - - - - Ion type (ion species) identifier. The identifier zero - is reserved for the special unknown ion type. - - - - - A vector of isotope hash values. - These values have to be stored in an array, sorted in decreasing order. - The array is filled with zero hash values indicating unused places. - The individual hash values are built with the following hash function: - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. - - Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - A supplementary row vector which decodes the isotope_vector into - a human-readable matrix of nuclids with the following formatting: - - The first row specifies the isotope mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N`. As an example for a - carbon-14 isotope the number is 14. - The second row specifies the number of protons :math:`Z`, e.g. 6 for the - carbon-14 example. This row matrix is thus a mapping the notation of - using superscribed isotope mass and subscripted number of protons to - identify isotopes. - Unused places filling up to n_ivecmax need to be filled with zero. - - - - - - - - - Color code used for visualizing such ions. - - - - - Assumed volume of the ion. - - In atom probe microscopy this field can be used to store the reconstructed - volume per ion (average) which is typically stored in range files and will - be used when building a tomographic reconstruction of an atom probe - dataset. - - - - - Charge of the ion. - - - - - Signed charge state of the ion in multiples of electron charge. - - Only positive values will be measured in atom probe microscopy as the - ions are accelerated by a negatively signed bias electric field. - In the case that the charge state is not explicitly recoverable, - the value should be set to zero. - - In atom probe microscopy this is for example the case when using - classical range file formats like RNG, RRNG for atom probe data. - These file formats do not document the charge state explicitly. - They report the number of atoms of each element per molecular ion - surplus the mass-to-charge-state-ratio interval. - With this it is possible to recover the charge state only for - specific molecular ions as the accumulated mass of the molecular ion - is defined by the isotopes, which without knowing the charge leads - to an underconstrained problem. - Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - - - - - Human-readable ion type name (e.g. Al +++) - The string should consists of ASCII UTF-8 characters, - ideally using LaTeX notation to specify the isotopes, ions, and charge - state. Examples are 12C + or Al +++. - Although this name may be human-readable and intuitive, parsing such - names becomes impractical for more complicated cases. Therefore, for the - field of atom probe microscopy the isotope_vector should be the - preferred machine-readable format to use. - - - - - Associated lower (mqmin) and upper (mqmax) bounds of - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries included) for which the respective ion is one to be labelled - with ion_identifier. The field is primarily of interest to document the - result of indexing a ToF/mass spectrum. - - - - - - - - diff --git a/contributed_definitions/NXisocontour.nxdl.xml b/contributed_definitions/NXisocontour.nxdl.xml index 182fe98106..7e8434bc72 100644 --- a/contributed_definitions/NXisocontour.nxdl.xml +++ b/contributed_definitions/NXisocontour.nxdl.xml @@ -1,10 +1,10 @@ - + - The weighting model specifies how mark data are mapped to a weight per - point/object. + The weighting model specifies how mark data are mapped to a weight per + point/object. - As an example from the research field of atom probe points/objects are (molecular) ions. - Different methods are used for weighting ions: - - * default, points get all the same weight 1., which for atom probe is equivalent - to (molecular) iontype-based delocalization. - * element, points get as much weight as they have atoms representing a nuclide - with a proton number that is matching to a respective entry in whitelist. - In atom probe jargon, this means atomic_decomposition. - * isotope, points get as much weight as they have atoms representing a nuclides - from a respective entry in whitelist. - In atom probe jargon, this means isotope_decomposition. + As an example from the research field of atom probe points/objects are (molecular) ions. + Different methods are used for weighting ions: + + * default, points get all the same weight 1., which for atom probe is equivalent + to (molecular) iontype-based delocalization. + * element, points get as much weight as they have atoms representing a nuclide + with a proton number that is matching to a respective entry in whitelist. + In atom probe jargon, this means atomic_decomposition. + * isotope, points get as much weight as they have atoms representing a nuclides + from a respective entry in whitelist. + In atom probe jargon, this means isotope_decomposition. @@ -109,10 +109,10 @@ and the interpretation model that to consider carbon atoms or carbon ions--> - A list of nuclides based on which to evaluate the weight. Nuclides need to exist in the nuclide table. - Values are nuclide (isotope) hash values using the following hashing rule :math:`H = Z + N \cdot 256` - with :math:`Z` the number of protons and :math:`N` the number of neutrons of the nuclide. - For elements set :math:`N` to zero. + A list of nuclides based on which to evaluate the weight. Nuclides need to exist in the nuclide table. + Values are nuclide (isotope) hash values using the following hashing rule :math:`H = Z + N \cdot 256` + with :math:`Z` the number of protons and :math:`N` the number of neutrons of the nuclide. + For elements set :math:`N` to zero. @@ -120,9 +120,9 @@ and the interpretation model that to consider carbon atoms or carbon ions--> - Attribute data for each member of the point cloud. For APM these are the - iontypes generated via ranging. The number of mark data per point is 1 - in the case for atom probe. + Attribute data for each member of the point cloud. For APM these are the + iontypes generated via ranging. The number of mark data per point is 1 + in the case for atom probe. @@ -131,10 +131,10 @@ and the interpretation model that to consider carbon atoms or carbon ions--> - Weighting factor with which the integrated intensity per grid cell is - multiplied specifically for each point/object. For APM the weight are - positive integer values, specifically the multiplicity of the ion, - according to the details of the weighting_method. + Weighting factor with which the integrated intensity per grid cell is + multiplied specifically for each point/object. For APM the weight are + positive integer values, specifically the multiplicity of the ion, + according to the details of the weighting_method. From 52e6aaee603536aff799bda23f53cebf212a0614 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 28 Aug 2025 11:17:19 +0200 Subject: [PATCH 0991/1012] bring in NXem_calorimetry from fairmat --- .../NXem_calorimetry.nxdl.xml | 342 +++++++++--------- 1 file changed, 170 insertions(+), 172 deletions(-) diff --git a/contributed_definitions/NXem_calorimetry.nxdl.xml b/contributed_definitions/NXem_calorimetry.nxdl.xml index 632722293e..a095cc0780 100644 --- a/contributed_definitions/NXem_calorimetry.nxdl.xml +++ b/contributed_definitions/NXem_calorimetry.nxdl.xml @@ -1,9 +1,9 @@ - + - + - The symbols used in the schema to specify e.g. dimensions of arrays. + The symbols used in the schema to specify e.g. dimensions of arrays. - - Number of pattern + Number of diffraction pattern. - Number of azimuthal integration bins + Number of radial integration bins. - Number of coordinates along i axis. + Number of coordinates along i axis. - Number of coordinates along j axis. + Number of coordinates along j axis. - Application definition for minimal example in-situ calorimetry. - - What is the technique about. - - General context. - - Literature references. + Application definition for minimal example in-situ calorimetry. + + TODO: + + * What is the technique about. + * General context. + * Literature references. - - - - - - - - - + + + + Details about performance, profiling, etc. + + + + + + + + Name of the program whereby this config file was created. + + + + + + + + Programs and libraries representing the computational environment + + + + + + + + + + + + Qualifier whether the sample is a real (in which case is_simulation should be set to false) + or a virtual one (in which case is_simulation should be set to true). + + + + + List of comma-separated elements from the periodic table that are + contained in the specimen. If the specimen substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer research data management systems an + opportunity to parse the relevant elements without having to interpret + these from the resources. + + + - - - + + + + Reference to the resource which stores acquired pattern from the + experiment or simulation that are analyzed in this workflow. + + Can refer to the original EMD or MRC files or the parsed NXem + in RDM e.g. NOMAD OASIS. + + + + - - + - Reference to the resource which stores acquired pattern from the experiment. - - Can refer to the original EMD or MRC files or the parsed NXem in RDM e.g. NOMAD OASIS. + Reference to the resource which stores actuator log file from the experiment. - - + - + - Reference to the resource which stores actuator log file from the experiment. + Configuration file that was used for parametrizing this analysis workflow. - - + - + - Assumptions and computations whereby timestamp data from the - detector used for collecting diffraction pattern and the actuator - (heating chip) were synchronized. + Assumptions and computations whereby timestamping data from + the detector and actuator (e.g. heating chip) were synchronized. - - - - - - Timestamp when pattern acquisition started. + ISO8601 with local time zone reference timestamp that tells + with which delta_time can be converted in timestamp. + The reference timestamp is defined as the time when the + actuator started acting on the sample. + + Time differences to this timestamp when correlated signals such + as diffraction pattern matching with a specific state of the sample + (e.g. obtained temperature via the actuator) are reported through + delta_time. + + - + - Timestamp when pattern acquisition ended. + Time difference to start_time. + + Collecting diffraction pattern also takes some time. + It is assumed that the acquisition time for each pattern is + substantial shorter than the time it takes the actuator to + cause a change in stimulus (e.g. temperature). - + + + Computation of the center for each pattern using e.g. a Circular Hough + Transformation. + - - - - - - - - - - + + + + Computed center for each pattern. + + + + + + + + Elliptical distortion correction as a step when computing the center for + patterns. + - - - - - - - - - - - - - - - + + + + Computed center for each pattern. + + + + + + - - + - Acquired diffraction pattern azimuthally integrated as a function of time. + Integrated diffraction pattern intensity as a function of radial distance from the center + azimuthally integrated as a function of time. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Time since start of the in-situ experiment - - - - - - - - - - - - - - - - - - - - + + - Azimuthally integrated diffraction intensities corrected for background as a - function of time. + The integrated intensities: + + * result_with_background + * result_without_background - + + + Integrated intensity as a function of time and the radial distance from the + pattern center. + - + + + Identifier for each pattern. + - + + + Positions in reciprocal space. + - + - Time since start of the in-situ experiment + Time since start of the in-situ experiment @@ -280,20 +288,10 @@ no exists, i.e. assuming required - - - - - - + + - From bc0090d401adf417da676806291e6b845834af6e Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 28 Aug 2025 11:23:24 +0200 Subject: [PATCH 0992/1012] remove NXlab* classes --- ...ctro_chemo_mechanical_preparation.nxdl.xml | 188 ------------------ .../NXlab_sample_mounting.nxdl.xml | 93 --------- 2 files changed, 281 deletions(-) delete mode 100644 contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml delete mode 100644 contributed_definitions/NXlab_sample_mounting.nxdl.xml diff --git a/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml b/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml deleted file mode 100644 index e9a3ae64da..0000000000 --- a/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml +++ /dev/null @@ -1,188 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Grinding and polishing of a sample using abrasives in a wet lab. - Manual procedures, electro-chemical, vibropolishing. - - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - - - - - - - - - - A preparation step performed by a human or a robot/automated system. - - - - - - - - Carrier/plate used on which the abrasive/(lubricant) mixture was applied. - - - - - - Medium on the abrasive_medium_carrier (cloth or grinding plate) - whereby material is abrasively weared. - - - - - - Lubricant - - - - - - Qualitative statement how the revelation of the machine was configured. - If the rotation was controlled manually, e.g. by turning knobs - choose manual and estimate the nominal average rotation. - If the rotation was controlled via choosing from a fixed set - of options offered by the machine choose fixed and - specify the nominal rotation. - If programmed use rotation_history (e.g. for automated/robot systems). - - - - - - - - - - - Qualitative statement how the (piston) force with which the sample - was pressed into/against the abrasive medium was controlled if at all. - If the force was controlled manually e.g. by turning knobs - choose manual and estimate nominal average force. - If the force was controlled via choosing from a fixed set - of options offered by the machine choose fixed and - specify the nominal force. - If programmed use force_history (e.g. for automated/robot systems). - - - - - - - - - - - Qualitative statement for how long (assuming regular uninterrupted) - preparation at the specified conditions the preparation step was - applied. - - - - - - - - - - - Turns per unit time. - - - - - - Force exerted on the sample to press it into the abrasive. - - - - - - Seconds - - - - - Qualitative statement how the material removal was characterized. - - - - - - - - - - How thick a layer was removed. - - - - - - - A preparation step performed by a human or a robot/automated system - with the aim to remove residual abrasive medium from the specimen surface. - - - - - diff --git a/contributed_definitions/NXlab_sample_mounting.nxdl.xml b/contributed_definitions/NXlab_sample_mounting.nxdl.xml deleted file mode 100644 index 4113ea123e..0000000000 --- a/contributed_definitions/NXlab_sample_mounting.nxdl.xml +++ /dev/null @@ -1,93 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Embedding of a sample in a medium for easing processability. - - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - - - - - - - - - - Qualitative statement how the sample was mounted. - - - - - - - - - Type of material. - - - - - - - - - Electrical conductivity of the embedding medium. - - - - - From d53281b59551a7f6d4a0cb86267691365c45aa6d Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 28 Aug 2025 11:25:21 +0200 Subject: [PATCH 0993/1012] bring in NXsubsampling_filter from fairmat branch --- .../NXsubsampling_filter.nxdl.xml | 30 +++++++++---------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml index 2ecb9877a0..509eb2f9d6 100644 --- a/contributed_definitions/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -1,10 +1,10 @@ - + - Base class of a filter to sample members in a set based on their identifier. + Base class of a filter to sample members in a set based on their identifier. - Triplet of the minimum, the increment, and the maximum identifier to - include of a sequence :math:`[i_0, i_0 + 1, i_0 + 2, \ldots, i_0 + \mathcal{N}] with i_0 \in \mathcal{Z}` - of identifier. The increment controls which n-th identifier (value) to take. - - Take as an example a dataset with 100 identifier (aka entries). Assume that - the identifier start at zero, i.e. identifier_offset is 0). Assume further - that min_incr_max is set to [0, 1, 99]. In this case the filter will - yield all identifier. Setting min_incr_max to [0, 2, 99] will take each - second identifier. Setting min_incr_max to [90, 3, 99] will take each - third identifier beginning from identifier 90 up to 99. + Triplet of the minimum, the increment, and the maximum identifier to + include of a sequence :math:`[i_0, i_0 + 1, i_0 + 2, \ldots, i_0 + \mathcal{N}] with i_0 \in \mathcal{Z}` + of identifier. The increment controls which n-th identifier (value) to take. + + Take as an example a dataset with 100 identifier (aka entries). Assume that + the identifier start at zero, i.e. identifier_offset is 0). Assume further + that min_incr_max is set to [0, 1, 99]. In this case the filter will + yield all identifier. Setting min_incr_max to [0, 2, 99] will take each + second identifier. Setting min_incr_max to [90, 3, 99] will take each + third identifier beginning from identifier 90 up to 99. From ee1040d430a657e3d3e18eb0bd98c78f49168abc Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 28 Aug 2025 11:27:18 +0200 Subject: [PATCH 0994/1012] bring in NXsimilarity_grouping from fairmat branch --- .../NXsimilarity_grouping.nxdl.xml | 86 +++++++++---------- 1 file changed, 43 insertions(+), 43 deletions(-) diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index e9d893e285..4d032e2d58 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -1,9 +1,9 @@ - + - + - Which numerical identifier is the first to be used to label a feature. - - The value should be chosen in such a way that special values can be resolved: - * identifier_offset - 1 indicates that an object belongs to no cluster. - * identifier_offset - 2 indicates that an object belongs to the noise category. - Setting for instance identifier_offset to 1 recovers the commonly used - case that objects of the noise category get values to -1 and unassigned - points to 0. Numerical identifier have to be strictly increasing. + Which numerical index is the first to be used to label a feature. + + The value should be chosen in such a way that special values can be resolved: + * index_offset - 1 indicates that an object belongs to no cluster. + * index_offset - 2 indicates that an object belongs to the noise category. + Setting for instance index_offset to 1 recovers the commonly used + case that objects of the noise category get values to -1 and unassigned + points to 0. Numerical identifier have to be strictly increasing. - Matrix of numerical label for each member in the set. - For classical clustering algorithms this can for instance - encode the cluster_identifier. + Matrix of numerical label for each member in the set. + For classical clustering algorithms this can for instance + encode the indices_cluster. @@ -106,7 +106,7 @@ results for the object set--> - Matrix of categorical attribute data for each member in the set. + Matrix of categorical attribute data for each member in the set. @@ -115,31 +115,31 @@ results for the object set--> - In addition to the detailed storage which objects were grouped to which - feature/group summary statistics are stored under this group. + In addition to the detailed storage which objects were grouped to which + feature/group summary statistics are stored under this group. - Total number of features categorized as unassigned. + Total number of features categorized as unassigned. - Total number of features categorized as noise. + Total number of features categorized as noise. - Total number of features. + Total number of features. - + - Array of numerical identifier of each feature. + Array of numerical identifier of each feature. @@ -147,7 +147,7 @@ when knowing total, noise, and unassigned.--> - Array of number of objects for each feature. + Array of number of objects for each feature. From 3c09a4535614ec47b567913d357e508d4f8923db Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 28 Aug 2025 11:33:44 +0200 Subject: [PATCH 0995/1012] bring in NXapm_paraprobe classes --- .../NXapm_paraprobe_clusterer_config.nxdl.xml | 291 +++--- ...NXapm_paraprobe_clusterer_results.nxdl.xml | 208 ++-- .../NXapm_paraprobe_distancer_config.nxdl.xml | 101 +- ...NXapm_paraprobe_distancer_results.nxdl.xml | 141 ++- ...Xapm_paraprobe_intersector_config.nxdl.xml | 211 ++-- ...apm_paraprobe_intersector_results.nxdl.xml | 210 ++-- .../NXapm_paraprobe_nanochem_config.nxdl.xml | 918 +++++++++--------- .../NXapm_paraprobe_nanochem_results.nxdl.xml | 842 ++++++++-------- .../NXapm_paraprobe_ranger_config.nxdl.xml | 157 +-- .../NXapm_paraprobe_ranger_results.nxdl.xml | 100 +- .../NXapm_paraprobe_selector_config.nxdl.xml | 32 +- .../NXapm_paraprobe_selector_results.nxdl.xml | 76 +- .../NXapm_paraprobe_spatstat_config.nxdl.xml | 227 +++-- .../NXapm_paraprobe_spatstat_results.nxdl.xml | 106 +- .../NXapm_paraprobe_surfacer_config.nxdl.xml | 39 +- .../NXapm_paraprobe_surfacer_results.nxdl.xml | 192 ++-- ...Xapm_paraprobe_tessellator_config.nxdl.xml | 35 +- ...apm_paraprobe_tessellator_results.nxdl.xml | 212 ++-- .../NXapm_paraprobe_tool_common.nxdl.xml | 134 ++- .../NXapm_paraprobe_tool_config.nxdl.xml | 137 ++- .../NXapm_paraprobe_tool_results.nxdl.xml | 62 +- ...NXapm_paraprobe_transcoder_config.nxdl.xml | 33 +- ...Xapm_paraprobe_transcoder_results.nxdl.xml | 152 ++- 23 files changed, 2232 insertions(+), 2384 deletions(-) diff --git a/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml index 21897a43b9..76bdb6a531 100644 --- a/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml @@ -1,9 +1,9 @@ - + + - Maximum number of atoms per molecular ion. Should be 32 for paraprobe. + Maximum number of atoms per molecular ion. Should be 32 for paraprobe. - Number of clustering algorithms used. + Number of clustering algorithms used. - Number of different iontypes to distinguish during clustering. + Number of different iontypes to distinguish during clustering. - Application definition for a configuration file of the paraprobe-clusterer tool. - - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + Application definition for a configuration file of the paraprobe-clusterer tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. @@ -58,114 +57,114 @@ n_disjoint_clusters: Number of disjoint cluster.--> - How many cluster_analysis tasks should the tool execute. + How many cluster_analysis tasks should the tool execute. - This process maps results from a cluster analysis made with IVAS / AP Suite - into an interoperable representation. IVAS / AP Suite usually exports such results - as a list of reconstructed ion positions with one cluster label per position. - These labels are reported via the mass-to-charge-state-ratio column of what is effectively - a binary file that is formatted like a POS file but cluster labels written out using floating - point numbers. + This process maps results from a cluster analysis made with IVAS / AP Suite + into an interoperable representation. IVAS / AP Suite usually exports such results + as a list of reconstructed ion positions with one cluster label per position. + These labels are reported via the mass-to-charge-state-ratio column of what is effectively + a binary file that is formatted like a POS file but cluster labels written out using floating + point numbers. - + - + - + - File with the results of the cluster analyses that was computed with IVAS / AP suite - (e.g. maximum-separation method clustering algorithm `J. Hyde et al. <https://doi.org/10.1557/PROC-650-R6.6>`_). - The information is stored in an improper (.indexed.) POS file as a matrix of floating - point quadruplets, one quadruplet for each ion. The first three values of each - quadruplet encode the position of the ion. The fourth value is the integer identifier - of the cluster encoded as a floating point number. + File with the results of the cluster analyses that was computed with IVAS / AP suite + (e.g. maximum-separation method clustering algorithm `J. Hyde et al. <https://doi.org/10.1557/PROC-650-R6.6>`_). + The information is stored in an improper (.indexed.) POS file as a matrix of floating + point quadruplets, one quadruplet for each ion. The first three values of each + quadruplet encode the position of the ion. The fourth value is the integer identifier + of the cluster encoded as a floating point number. - + - Specifies if paraprobe-clusterer should use the evaporation_ids from reconstruction - for recovering for each position in the :ref:`NXserialized` results the closest matching position - (within floating point accuracy). This can be useful when users wish to recover the - original evaporation_id, which IVAS /AP Suite drops when writing their *.indexed.* cluster - results POS files that is referred to results. + Specifies if paraprobe-clusterer should use the evaporation_ids from reconstruction + for recovering for each position in the :ref:`NXnote` results the closest matching position + (within floating point accuracy). This can be useful when users wish to recover the + original evaporation_id, which IVAS /AP Suite drops when writing their *.indexed.* cluster + results POS files that is referred to results. - +Specifies if the tool should try to recover, after a recovery of the +evaporation_id a bitmask which identifies which of the positions +in dataset/dataset/dataset_name_reconstruction where covered +by the IVAS/APSuite cluster analysis. This can be useful to recover +the region of interest.--> + - This process performs a cluster analysis on a - reconstructed dataset or a ROI within it. + This process performs a cluster analysis on a + reconstructed dataset or a ROI within it. - + - + - + - + - + - Distance between each ion and triangulated surface mesh. + Distance between each ion and triangulated surface mesh. - + - + - + - + - + - + - + - + @@ -173,9 +172,6 @@ doc: | - @@ -190,34 +186,34 @@ identifier(NX_UINT):--> - How should iontypes be considered during the cluster analysis. - - The value resolve_all will set an ion active - in the analysis regardless of which iontype it is. - - The value resolve_unknown will set an ion active - when it is of the UNKNOWNTYPE. - - The value resolve_ion will set an ion active - if it is of the specific iontype, irregardless of its nuclide structure. - - The value resolve_element will set an ion active and account as many times - for it, as the (molecular) ion contains atoms of elements in the whitelist - ion_query_nuclide_vector. - - The value resolve_isotope will set an ion active and account as many times - for it, as the (molecular) ion contains nuclides in the whitelist - ion_query_nuclide_vector. - - In effect, ion_query_nuclide_vector acts as a whitelist to filter which ions are - considered as source ions of the correlation statistics and how the multiplicity - of each ion will be factorized. - - This is relevant as in atom probe we have the situation that an ion of a molecular - ion with more than one nuclide, say Ti O for example is counted potentially several - times because at that position (reconstructed) position it has been assumed that - there was a Ti and an O atom. This multiplicity affects the size of the feature and its - chemical composition. + How should iontypes be considered during the cluster analysis. + + The value resolve_all will set an ion active + in the analysis regardless of which iontype it is. + + The value resolve_unknown will set an ion active + when it is of the UNKNOWNTYPE. + + The value resolve_ion will set an ion active + if it is of the specific iontype, irregardless of its nuclide structure. + + The value resolve_element will set an ion active and account as many times + for it, as the (molecular) ion contains atoms of elements in the whitelist + ion_query_nuclide_vector. + + The value resolve_isotope will set an ion active and account as many times + for it, as the (molecular) ion contains nuclides in the whitelist + ion_query_nuclide_vector. + + In effect, ion_query_nuclide_vector acts as a whitelist to filter which ions are + considered as source ions of the correlation statistics and how the multiplicity + of each ion will be factorized. + + This is relevant as in atom probe we have the situation that an ion of a molecular + ion with more than one nuclide, say Ti O for example is counted potentially several + times because at that position (reconstructed) position it has been assumed that + there was a Ti and an O atom. This multiplicity affects the size of the feature and its + chemical composition. @@ -226,10 +222,10 @@ identifier(NX_UINT):--> - Matrix of nuclide vectors, as many as rows as different candidates - for iontypes should be distinguished as possible source iontypes. - In the simplest case, the matrix contains only the proton number - of the element in the row, all other values set to zero. + Matrix of nuclide vectors, as many as rows as different candidates + for iontypes should be distinguished as possible source iontypes. + In the simplest case, the matrix contains only the proton number + of the element in the row, all other values set to zero. @@ -239,32 +235,32 @@ identifier(NX_UINT):--> - Settings for DBScan clustering algorithm. For original details about the - algorithm and (performance-relevant) details consider: - - * `M. Ester et al. <https://dx.doi.org/10.5555/3001460.3001507>`_ - * `M. Götz et al. <https://dx.doi.org/10.1145/2834892.2834894>`_ - - For details about how the DBScan algorithms is the key behind the - specific modification known as the maximum-separation method in the - atom probe community consider `E. Jägle et al. <https://dx.doi.org/10.1017/S1431927614013294>`_ + Settings for DBScan clustering algorithm. For original details about the + algorithm and (performance-relevant) details consider: + + * `M. Ester et al. <https://dx.doi.org/10.5555/3001460.3001507>`_ + * `M. Götz et al. <https://dx.doi.org/10.1145/2834892.2834894>`_ + + For details about how the DBScan algorithms is the key behind the + specific modification known as the maximum-separation method in the + atom probe community consider `E. Jägle et al. <https://dx.doi.org/10.1017/S1431927614013294>`_ - Strategy how a set of cluster analyses with different parameter is executed: - - * For tuple as many runs are performed as parameter values have been defined. - * For combinatorics individual parameter arrays are looped over. - - As an example we may provide ten entries for eps and three entries for min_pts. - If high_throughput_method is set to tuple, the analysis is invalid because we have - an insufficient number of min_pts values to pair them with our ten eps values. - By contrast, if high_throughput_method is set to combinatorics, the tool will run three - individual min_pts runs for each eps value, resulting in a total of 30 analyses. - - A typical example from the literature `M. Kühbach et al. <https://dx.doi.org/10.1038/s41524-020-00486-1>`_ - can be instructed via setting eps to an array of values np.linspace(0.2, 5.0, nums=241, endpoint=True), - one min_pts value that is equal to 1, and high_throughput_method set to combinatorics. + Strategy how a set of cluster analyses with different parameter is executed: + + * For tuple as many runs are performed as parameter values have been defined. + * For combinatorics individual parameter arrays are looped over. + + As an example we may provide ten entries for eps and three entries for min_pts. + If high_throughput_method is set to tuple, the analysis is invalid because we have + an insufficient number of min_pts values to pair them with our ten eps values. + By contrast, if high_throughput_method is set to combinatorics, the tool will run three + individual min_pts runs for each eps value, resulting in a total of 30 analyses. + + A typical example from the literature `M. Kühbach et al. <https://dx.doi.org/10.1038/s41524-020-00486-1>`_ + can be instructed via setting eps to an array of values np.linspace(0.2, 5.0, nums=241, endpoint=True), + one min_pts value that is equal to 1, and high_throughput_method set to combinatorics. @@ -273,7 +269,7 @@ identifier(NX_UINT):--> - Array of epsilon (eps) parameter values. + Array of epsilon (eps) parameter values. @@ -281,7 +277,7 @@ identifier(NX_UINT):--> - Array of minimum points (min_pts) parameter values. + Array of minimum points (min_pts) parameter values. @@ -291,39 +287,38 @@ identifier(NX_UINT):--> +doc: | +Settings for the OPTICS clustering algorithm. +* `M. Ankerest et al. `_ +high_throughput_method(NX_CHAR): +doc: | +Strategy how runs with different parameter values are composed, +following the explanation for high_throughput_method of dbscan. +enumeration: [tuple, combinatorics] +min_pts(NX_UINT): +doc: | +Array of minimum points (min_pts) parameter values. +unit: NX_UNITLESS +dim: (i,) +max_eps(NX_FLOAT): +doc: | +Array of maximum epsilon (eps) parameter values. +unit: NX_LENGTH +dim: (j,)--> - Settings for the HPDBScan clustering algorithm. - - * L. McInnes et al. <https://dx.doi.org/10.21105/joss.00205>`_ - * scikit-learn hdbscan library `<https://hdbscan.readthedocs.io/en/latest/how_hdbscan_works.html>`_ - - See also this documentation for details about the parameter. - Here we use the terminology of the hdbscan documentation. + Settings for the HPDBScan clustering algorithm. + + * L. McInnes et al. <https://dx.doi.org/10.21105/joss.00205>`_ + * scikit-learn hdbscan library `<https://hdbscan.readthedocs.io/en/latest/how_hdbscan_works.html>`_ + + See also this documentation for details about the parameter. + Here we use the terminology of the hdbscan documentation. - Strategy how runs with different parameter values are composed, - following the explanation for higih_throughput_method of dbscan. + Strategy how runs with different parameter values are composed, + following the explanation for high_throughput_method of dbscan. @@ -332,7 +327,7 @@ optics(NXprocess): - Array of min_cluster_size parameter values. + Array of min_cluster_size parameter values. @@ -340,7 +335,7 @@ optics(NXprocess): - Array of min_samples parameter values. + Array of min_samples parameter values. @@ -348,7 +343,7 @@ optics(NXprocess): - Array of cluster_selection parameter values. + Array of cluster_selection parameter values. @@ -356,7 +351,7 @@ optics(NXprocess): - Array of alpha parameter values. + Array of alpha parameter values. @@ -368,7 +363,7 @@ optics(NXprocess): e.g. https://doi.org/10.1017/S1431927607070900--> - + diff --git a/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml index 763a37b1c9..bff207f5e1 100644 --- a/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml @@ -1,9 +1,9 @@ - + - - - + + + - + @@ -65,47 +65,47 @@ - + - Results of a DBScan clustering analysis. + Results of a DBScan clustering analysis. - The epsilon (eps) parameter used. + The epsilon (eps) parameter used. - The minimum points (min_pts) parameter used. + The minimum points (min_pts) parameter used. - + - Number of members in the set which is partitioned into features. - Specifically, this is the total number of targets filtered from the - dataset, i.e. typically the number of clusters which is usually not and - for sure not necessarily the total number of ions in the dataset. + Number of members in the set which is partitioned into features. + Specifically, this is the total number of targets filtered from the + dataset, i.e. typically the number of clusters which is usually not and + for sure not necessarily the total number of ions in the dataset. - + - Which identifier is the first to be used to label a cluster. - - The value should be chosen in such a way that special values can be resolved: - * identifier_offset - 1 indicates an object belongs to no cluster. - * identifier_offset - 2 indicates an object belongs to the noise category. - - Setting for instance identifier_offset to 1 recovers the commonly used - case that objects of the noise category get the value of -1 and points of the - unassigned category get the value 0. + Which identifier is the first to be used to label a cluster. + + The value should be chosen in such a way that special values can be resolved: + * index_offset - 1 indicates an object belongs to no cluster. + * index_offset - 2 indicates an object belongs to the noise category. + + Setting for instance index_offset to 1 recovers the commonly used + case that objects of the noise category get the value of -1 and points of the + unassigned category get the value 0. - The evaporation (sequence) identifier (aka evaporation_id) to figure out - which ions from the reconstruction were considered targets. The length - of this array is not necessarily n_ions. - Instead, it is the value of cardinality. + The evaporation (sequence) id (aka evaporation_id) to figure out + which ions from the reconstruction were considered targets. The length + of this array is not necessarily n_ions. + Instead, it is the value of cardinality. @@ -114,11 +114,11 @@ - The number of solutions found for each target. Typically, - this value is 1 in which case the field can be omitted. - Otherwise, this array is the concatenated set of values of solution - tuples for each target that can be used to decode model_labels, - core_sample_indices, and weight. + The number of solutions found for each target. Typically, + this value is 1 in which case the field can be omitted. + Otherwise, this array is the concatenated set of values of solution + tuples for each target that can be used to decode model_labels, + core_sample_indices, and weight. @@ -126,12 +126,12 @@ - The raw labels from the DBScan clustering backend process. - The length of this array is not necessarily n_ions. - Instead, it is typically the value of cardinality provided that each - target has only one associated cluster. If targets are assigned to - multiple cluster this array is as long as the total number of solutions - found and + The raw labels from the DBScan clustering backend process. + The length of this array is not necessarily n_ions. + Instead, it is typically the value of cardinality provided that each + target has only one associated cluster. If targets are assigned to + multiple cluster this array is as long as the total number of solutions + found and @@ -139,8 +139,8 @@ - The raw array of core sample indices which specify which of the - targets are core points. + The raw array of core sample indices which specify which of the + targets are core points. @@ -148,7 +148,7 @@ - Numerical label for each target (member in the set) aka cluster identifier. + Numerical label for each target (member in the set) aka cluster identifier. @@ -156,7 +156,7 @@ - Categorical label(s) for each target (member in the set) aka cluster name(s). + Categorical label(s) for each target (member in the set) aka cluster name(s). @@ -164,39 +164,29 @@ - Weights for each target that specifies how probable the target is assigned to - a specific cluster. - - For the DBScan algorithm and atom probe tomography this value is the - multiplicity of each ion with respect to the cluster. That is how many times - should the position of the ion be accounted for because the ion is e.g. a - molecular ion with several elements or nuclides of requested type. + Weights for each target that specifies how probable the target is assigned to + a specific cluster. + + For the DBScan algorithm and atom probe tomography this value is the + multiplicity of each ion with respect to the cluster. That is how many times + should the position of the ion be accounted for because the ion is e.g. a + molecular ion with several elements or nuclides of requested type. - - Are targets assigned to the noise category or not. + Are targets assigned to the noise category or not. - - Are targets assumed a core point. + Are targets assumed a core point. @@ -204,44 +194,44 @@ number_of_objects(NX_UINT): - In addition to the detailed storage which members were grouped to which - feature here summary statistics are stored that communicate e.g. how many - cluster were found. + In addition to the detailed storage which members were grouped to which + feature here summary statistics are stored that communicate e.g. how many + cluster were found. - + - Total number of targets in the set, i.e. ions that were filtered - and considered in this cluster analysis. + Total number of targets in the set, i.e. ions that were filtered + and considered in this cluster analysis. - + - Total number of members in the set which are categorized as noise. + Total number of members in the set which are categorized as noise. - + - Total number of members in the set which are categorized as a core point. + Total number of members in the set which are categorized as a core point. - Total number of clusters (excluding noise and unassigned). + Total number of clusters (excluding noise and unassigned). - + - Numerical identifier of each feature aka cluster_identifier. + Numerical identifier of each feature aka cluster_id. - + - Number of members for each feature. + Number of members for each feature. @@ -253,7 +243,7 @@ number_of_objects(NX_UINT): - + @@ -263,36 +253,34 @@ number_of_objects(NX_UINT): - - - + + + - + - If used, metadata of at least the person who performed this analysis. + If used, metadata of at least the person who performed this analysis. - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml index e7d6d7917b..4b7127d3d8 100644 --- a/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml @@ -1,9 +1,9 @@ - + - + - + - + - + - + - + - + - - + @@ -109,12 +106,12 @@ - Specifies for which point the tool will compute distances. - - The value *default* configures that distances are computed for all points. - The value *skin* configures that distances are computed only for those - points which are not farther away located to a triangle than - threshold_distance. + Specifies for which point the tool will compute distances. + + The value *default* configures that distances are computed for all points. + The value *skin* configures that distances are computed only for those + points which are not farther away located to a triangle than + threshold_distance. @@ -123,58 +120,58 @@ - Maximum distance for which distances are - computed when *method* is *skin*. + Maximum distance for which distances are + computed when *method* is *skin*. - How many triangle sets to consider. - Multiple triangle sets can be defined which are - composed into one joint triangle set for the analysis. + How many triangle sets to consider. + Multiple triangle sets can be defined which are + composed into one joint triangle set for the analysis. - + - Each triangle_set that is referred to here should be a face_list_data_structure, - i.e. an array of (n_vertices, 3) of NX_FLOAT for vertex coordinates, an (n_facets, 3) - array of NX_UINT incident vertices of each facet. Vertex indices are assumed to - start at zero and must not exceed n_vertices - 1, i.e. the identifier_offset is 0. - Facet normal have to be provided as an array of (n_facets, 3) of NX_FLOAT. + Each triangle_set that is referred to here should be a face_list_data_structure, + i.e. an array of (n_vertices, 3) of NX_FLOAT for vertex coordinates, an (n_facets, 3) + array of NX_UINT incident vertices of each facet. Vertex indices are assumed to + start at zero and must not exceed n_vertices - 1, i.e. the index_offset is 0. + Facet normal have to be provided as an array of (n_facets, 3) of NX_FLOAT. - + - Absolute path in the (HDF5) file that points to the array - of vertex positions for the triangles in that triangle_set. + Absolute path in the (HDF5) file that points to the array + of vertex positions for the triangles in that triangle_set. - Absolute path in the (HDF5) file that points to the array - of vertex indices for the triangles in that triangle_set. + Absolute path in the (HDF5) file that points to the array + of vertex indices for the triangles in that triangle_set. - Absolute path in the (HDF5) file that points to the array - of vertex normal vectors for the triangles in that triangle_set. + Absolute path in the (HDF5) file that points to the array + of vertex normal vectors for the triangles in that triangle_set. - Absolute path in the (HDF5) file that points to the array - of facet normal vectors for the triangles in that triangle_set. + Absolute path in the (HDF5) file that points to the array + of facet normal vectors for the triangles in that triangle_set. - + - Absolute path in the (HDF5) file that points to the array - of identifier for the triangles in that triangle_set. + Absolute path in the (HDF5) file that points to the array + of identifier for the triangles in that triangle_set. @@ -186,7 +183,7 @@ - + diff --git a/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml index 011214db13..931f0a115e 100644 --- a/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml @@ -1,9 +1,9 @@ - + - - + - + @@ -77,28 +76,28 @@ - The shortest analytical distance of each point to their - respectively closest triangle from the joint triangle set. + The shortest analytical distance of each point to their + respectively closest triangle from the joint triangle set. - + - For each point the identifier of the triangle for which the - shortest distance was found + For each point the identifier of the triangle for which the + shortest distance was found. - + - A support field to enable the visualization of each point - by an explicit identifier on the interval [0, n_ions - 1]. - The field can be used to visualize the points as a function - of their distance to the triangle set (e.g. via XDMF/Paraview). + A support field to enable the visualization of each point + by an explicit identifier on the interval [0, n_ions - 1]. + The field can be used to visualize the points as a function + of their distance to the triangle set (e.g. via XDMF/Paraview). @@ -106,30 +105,30 @@ - A bitmask that identifies which of the distance values is - assumed to have a consistent sign because the closest - triangle had a consistent outer unit normal defined. - - For points whose bit is set to 0 the distance is correct - but the sign is not reliable. + A bitmask that identifies which of the distance values is + assumed to have a consistent sign because the closest + triangle had a consistent outer unit normal defined. + + For points whose bit is set to 0 the distance is correct + but the sign is not reliable. - Number of triangles covered by the mask. + Number of triangles covered by the mask. - Bitdepth of the elementary datatype that is used to store - the information content of the mask (typically 8 bit, uint8). + Bitdepth of the elementary datatype that is used to store + the information content of the mask (typically 8 bit, uint8). - The content of the mask. Like for all masks used in the tools - of the paraprobe-toolbox, padding is used when number_of_objects - is not an integer multiple of bitdepth. If padding is used, - padded bits are set to 0. + The content of the mask. Like for all masks used in the tools + of the paraprobe-toolbox, padding is used when number_of_objects + is not an integer multiple of bitdepth. If padding is used, + padded bits are set to 0. @@ -138,8 +137,8 @@ - A bitmask that identifies which of the triangles in the set were - considered when certain triangles have been filtered out. + A bitmask that identifies which of the triangles in the set were + considered when certain triangles have been filtered out. @@ -156,7 +155,7 @@ triangles in this case--> - + @@ -166,36 +165,34 @@ triangles in this case--> - - - + + + - + - If used, metadata of at least the person who performed this analysis. + If used, metadata of at least the person who performed this analysis. - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml index efdbdf9aeb..e66e2acf32 100644 --- a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml @@ -1,9 +1,9 @@ - + - Specifies the method whereby to decide if two objects intersect volumetrically. - For reasons which are detailed in the supplementary material of `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_, - it is assumed by default that two objects intersect if they share at least one ion with the same evaporation ID (shared_ion). - - Alternatively, with specifying tetrahedra_intersections, the tool can perform an intersection analysis which attempts to - tetrahedralize first each polyhedron. If successful, the tool then checks for at least one pair of intersecting tetrahedra - to identify if two objects intersect or not. However, we found that these geometrical analyses can result in corner - cases which the tetrahedralization library used in the tests (TetGen) was not unable to tetrahedralize successfully. - These cases were virtually always associated with complicated non-convex polyhedra which had portions - of the mesh that were connected by almost point like tubes of triangles. - - Finding more robust methods for computing intersections between not necessarily convex polyhedra might improve - the situation in the future. For practical reasons we have thus deactivated the functionality of tetrahedra-tetrahedron - intersections in paraprobe-intersector. + Specifies the method whereby to decide if two objects intersect volumetrically. + For reasons which are detailed in the supplementary material of `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_, + it is assumed by default that two objects intersect if they share at least one ion with the same evaporation ID (shared_ion). + + Alternatively, with specifying tetrahedra_intersections, the tool can perform an intersection analysis which attempts to + tetrahedralize first each polyhedron. If successful, the tool then checks for at least one pair of intersecting tetrahedra + to identify if two objects intersect or not. However, we found that these geometrical analyses can result in corner + cases which the tetrahedralization library used in the tests (TetGen) was not unable to tetrahedralize successfully. + These cases were virtually always associated with complicated non-convex polyhedra which had portions + of the mesh that were connected by almost point like tubes of triangles. + + Finding more robust methods for computing intersections between not necessarily convex polyhedra might improve + the situation in the future. For practical reasons we have thus deactivated the functionality of tetrahedra-tetrahedron + intersections in paraprobe-intersector. @@ -85,81 +85,81 @@ - Specifies if the tool evaluates if objects intersect volumetrically. + Specifies if the tool evaluates if objects intersect volumetrically. - Specifies if the tool evaluates if objects lay closer to one another than - threshold_proximity. + Specifies if the tool evaluates if objects lay closer to one another than + threshold_proximity. - Specifies if the tool evaluates, provided that all (preprocessing tasks were successful), how intersecting - or proximity related objects build sub-graphs. This is the feature that was used in `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_ - for the high-throughput analyses of how many objects are coprecipitates in the sense that they are single, - duplet, triplet, or high-order local groups. + Specifies if the tool evaluates, provided that all (preprocessing tasks were successful), how intersecting + or proximity related objects build sub-graphs. This is the feature that was used in `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_ + for the high-throughput analyses of how many objects are coprecipitates in the sense that they are single, + duplet, triplet, or high-order local groups. - The maximum Euclidean distance between two objects below which they are - considered within proximity. + The maximum Euclidean distance between two objects below which they are + considered within proximity. - Specifies if the tool stores the so-called forward relations between nodes representing members of the - current_set to nodes representing members of the next_set. + Specifies if the tool stores the so-called forward relations between nodes representing members of the + current_set to nodes representing members of the next_set. - Specifies if the tool stores the so-called backward relations between nodes representing members of the - next_set to nodes representing members of the current_set. + Specifies if the tool stores the so-called backward relations between nodes representing members of the + next_set to nodes representing members of the current_set. - + - Current set stores a set of members, meshes of volumetric features, - which will be checked for proximity and/or volumetric intersection, - to members of the current_set. - The meshes were generated as a result of some other meshing process. + Current set stores a set of members, meshes of volumetric features, + which will be checked for proximity and/or volumetric intersection, + to members of the current_set. + The meshes were generated as a result of some other meshing process. - This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`k`) - step when the current set was taken (see `M. Kühbach et al. 2022 <https://arxiv.org/abs/2205.13510>`_). + This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`k`) + step when the current set was taken (see `M. Kühbach et al. 2022 <https://arxiv.org/abs/2205.13510>`_). - The total number of distinguished feature sets featureID. - It is assumed that the members within all these featureID sets - are representing a set together. As an example this set might represent - all volumetric_features. However, users might have formed - a subset of this set where individuals were regrouped. - For paraprobe-nanochem this is the case for objects and proxies. - Specifically, objects are distinguished further into those far - from and those close to the edge of the dataset. - Similarly, proxies are distinguished further into those far - from and those close to the edge of the dataset. - So while these four sub-sets contain different so-called types of - features, key is that they were all generated for one set, here the - current_set. + The total number of distinguished feature sets featureID. + It is assumed that the members within all these featureID sets + are representing a set together. As an example this set might represent + all volumetric_features. However, users might have formed + a subset of this set where individuals were regrouped. + For paraprobe-nanochem this is the case for objects and proxies. + Specifically, objects are distinguished further into those far + from and those close to the edge of the dataset. + Similarly, proxies are distinguished further into those far + from and those close to the edge of the dataset. + So while these four sub-sets contain different so-called types of + features, key is that they were all generated for one set, here the + current_set. - + - Name of the (NeXus)/HDF5 file which contains triangulated surface meshes of the - members of the set as instances of NXcg_polyhedron_set. + Name of the (NeXus)/HDF5 file which contains triangulated surface meshes of the + members of the set as instances of NXcg_polyhedron. - Descriptive category explaining what these features are. + Descriptive category explaining what these features are. @@ -170,20 +170,20 @@ - + - Absolute path to the group with geometry data in the HDF5 file referred to by - path. + Absolute path to the group with geometry data in the HDF5 file referred to by + path. - + - Array of identifier whereby the path to the geometry data can be interferred - automatically. + Array of identifier whereby the path to the geometry data can be inferred + automatically. @@ -191,41 +191,41 @@ - + - Next set stores a set of members, meshes of volumetric features, - which will be checked for proximity and/or volumetric intersection, - to members of the next_set. - The meshes were generated as a result of some other meshing process. + Next set stores a set of members, meshes of volumetric features, + which will be checked for proximity and/or volumetric intersection, + to members of the next_set. + The meshes were generated as a result of some other meshing process. - This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`k + 1`) - step when the current set was taken (see `M. Kühbach et al. 2022 <https://arxiv.org/abs/2205.13510>`_). + This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`k + 1`) + step when the current set was taken (see `M. Kühbach et al. 2022 <https://arxiv.org/abs/2205.13510>`_). - The total number of distinguished feature sets featureID. - It is assumed that the members within all these featureID sets - are representing a set together. As an example this set might represent - all volumetric_features. However, users might have formed - a subset of this set where individuals were regrouped. - For paraprobe-nanochem this is the case for objects and proxies. - Specifically, objects are distinguished further into those far - from and those close to the edge of the dataset. - Similarly, proxies are distinguished further into those far - from and those close to the edge of the dataset. - So while these four sub-sets contain different so-called types of - features key is that they were all generated for one set, here the - next_set. + The total number of distinguished feature sets featureID. + It is assumed that the members within all these featureID sets + are representing a set together. As an example this set might represent + all volumetric_features. However, users might have formed + a subset of this set where individuals were regrouped. + For paraprobe-nanochem this is the case for objects and proxies. + Specifically, objects are distinguished further into those far + from and those close to the edge of the dataset. + Similarly, proxies are distinguished further into those far + from and those close to the edge of the dataset. + So while these four sub-sets contain different so-called types of + features key is that they were all generated for one set, here the + next_set. - + - Descriptive category explaining what these features are. + Descriptive category explaining what these features are. @@ -235,20 +235,20 @@ - + - Absolute path to the group with geometry data in the HDF5 file referred to by - path. + Absolute path to the group with geometry data in the HDF5 file referred to by + path. - + - Array of identifier whereby the path to the geometry data can be interferred - automatically. + Array of identifier whereby the path to the geometry data can be inferred + automatically. @@ -257,12 +257,11 @@ - - + diff --git a/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml index 55b2aeea3c..50883f97e8 100644 --- a/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml @@ -1,9 +1,9 @@ - + - The results of an overlap/intersection analysis. + The results of an overlap/intersection analysis. - A matrix of feature_identifier that specifies which named features - from the current_set have directed link(s) pointing to which named - feature(s) from the next_set. + A matrix of indices_feature that specifies which named features + from the current_set have directed link(s) pointing to which named + feature(s) from the next_set. @@ -88,9 +88,9 @@ - For each link/pair in current_to_next a characterization whether the - link is due to volumetric overlap (0x00 == 0), proximity (0x01 == 1), - or something else unknown (0xFF == 255). + For each link/pair in current_to_next a characterization whether the + link is due to volumetric overlap (0x00 == 0), proximity (0x01 == 1), + or something else unknown (0xFF == 255). @@ -98,11 +98,11 @@ - A matrix of feature_identifier which specifies which named feature(s) - from the next_set have directed link(s) pointing to which named - feature(s) from the current_set. Only if the mapping whereby the - links are defined is symmetric it holds that next_to_current maps - the links for current_to_next in just the opposite direction. + A matrix of indices_feature which specifies which named feature(s) + from the next_set have directed link(s) pointing to which named + feature(s) from the current_set. Only if the mapping whereby the + links are defined is symmetric it holds that next_to_current maps + the links for current_to_next in just the opposite direction. @@ -111,9 +111,9 @@ - For each link/pair in next_to_current a characterization whether the - link is due to a volumetric overlap (0x00 == 0), proximity (0x01 == 1), - or something else unknown (0xFF == 255). + For each link/pair in next_to_current a characterization whether the + link is due to a volumetric overlap (0x00 == 0), proximity (0x01 == 1), + or something else unknown (0xFF == 255). @@ -121,9 +121,9 @@ - For each pair of links in current_to_next the volume of the - intersection, i.e. how much volume do the two features share. - If features do not intersect the volume is zero. + For each pair of links in current_to_next the volume of the + intersection, i.e. how much volume do the two features share. + If features do not intersect the volume is zero. @@ -131,36 +131,36 @@ - During coprecipitation analysis the current and next set are analyzed - for links in a special way. Three set comparisons are made. Members - of the set in each comparison are analyzed for overlap and proximity: - - The first comparison is the current_set against the current_set. - The second comparison is the next_set against the next_set. - The third comparison is the current_set against the next_set. - - Once the (forward) links for these comparisons are ready, pair relations - are analyzed with respect to which objects with feature_identifier(s) - cluster in identifier space. Thereby, a logical connection (link) is - established between the features in the current_set and the next_set. - Recall that these two sets typically represent different features - within an observed system for otherwise the same parameterization. - - Examples include two sets of e.g. precipitates with differing - chemical composition that were characterized in the same material - volume representing a snapshot of an e.g. microstructure at the same - point in time. Researchers may have performed two analyses, one to - characterize precipitates A and another one for percipitates B. - - Coprecipitation analysis now logically connects these independent - characterization results to establish spatial correlations of e.g. - the precipitates' spatial arrangement. + During coprecipitation analysis the current and next set are analyzed + for links in a special way. Three set comparisons are made. Members + of the set in each comparison are analyzed for overlap and proximity: + + The first comparison is the current_set against the current_set. + The second comparison is the next_set against the next_set. + The third comparison is the current_set against the next_set. + + Once the (forward) links for these comparisons are ready, pair relations + are analyzed with respect to which objects with indices_feature + cluster in identifier space. Thereby, a logical connection (link) is + established between the features in the current_set and the next_set. + Recall that these two sets typically represent different features + within an observed system for otherwise the same parameterization. + + Examples include two sets of e.g. precipitates with differing + chemical composition that were characterized in the same material + volume representing a snapshot of an e.g. microstructure at the same + point in time. Researchers may have performed two analyses, one to + characterize precipitates A and another one for precipitates B. + + Coprecipitation analysis now logically connects these independent + characterization results to establish spatial correlations of e.g. + the precipitates' spatial arrangement. - Matrix of feature_identifier and cluster_identifier pairs which - encodes the cluster to which each feature_identifier was assigned. - Here for features of the current_set. + Matrix of indices_feature and cluster_id pairs which + encodes the cluster to which each indices_feature was assigned. + Here for features of the current_set. @@ -169,18 +169,18 @@ - Matrix of feature_identifier and cluster_identifier pairs which - encodes the cluster to which each feature_identifier was assigned. - Here for features of the next_set. + Matrix of indices_feature and cluster_id pairs which + encodes the cluster to which each indices_feature was assigned. + Here for features of the next_set. - + - The identifier (names) of the cluster. + The identifier (names) of the cluster. @@ -188,14 +188,14 @@ - Pivot table as a matrix. - The first column encodes how many members from the current_set - are in each cluster, one row per cluster. - - The second column encodes how many members from the next_set - are in each cluster, in the same row per cluster respectively. - - The third column encodes the total number of members in the cluster. + Pivot table as a matrix. + The first column encodes how many members from the current_set + are in each cluster, one row per cluster. + + The second column encodes how many members from the next_set + are in each cluster, in the same row per cluster respectively. + + The third column encodes the total number of members in the cluster. @@ -204,13 +204,13 @@ - Pivot table as a matrix. - - The first column encodes the different types of - clusters based on their number of members in the sub-graph. - - The second column encodes how many clusters with - as many members exist. + Pivot table as a matrix. + + The first column encodes the different types of + clusters based on their number of members in the sub-graph. + + The second column encodes how many clusters with + as many members exist. @@ -221,14 +221,14 @@ - - + + - + - + @@ -238,36 +238,34 @@ - - - + + + - + - If used, metadata of at least the person who performed this analysis. + If used, metadata of at least the person who performed this analysis. - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml index 08a2b878ba..4392766bdd 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml @@ -1,9 +1,9 @@ - + - - - + + + - + - + - + - + - A precomputed triangulated surface mesh representing a model (of the surface) - of the edge of the dataset. This model can be used to detect and control - various sources of bias in the analyses. + A precomputed triangulated surface mesh representing a model (of the surface) + of the edge of the dataset. This model can be used to detect and control + various sources of bias in the analyses. - + - Absolute path in the (HDF5) file that points to the array - of vertex positions for the triangles in that triangle_set. + Absolute path in the (HDF5) file that points to the array + of vertex positions for the triangles in that triangle_set. - Absolute path in the (HDF5) file that points to the array - of vertex indices for the triangles in that triangle_set. + Absolute path in the (HDF5) file that points to the array + of vertex indices for the triangles in that triangle_set. - + - Distance between each ion and triangulated surface mesh. + Distance between each ion and triangulated surface mesh. - + - + - + - + - + - + - + - + @@ -181,11 +180,43 @@ + + + Configuration for the algorithm that defines how the multiplicity of all + those ions are computed that are considered in the delocalization. + + + + TODO + + + + + + + + + + + + + + TODO + + + + + + TODO + + + + @@ -197,98 +228,98 @@ identifier(NX_UINT):--> - Compute delocalization or load an existent one from input. + Compute delocalization or load an existent one from input. - + - Serialized result of an already computed delocalization which is for performance - reasons here just loaded and not computed again. + Serialized result of an already computed delocalization which is for performance + reasons here just loaded and not computed again. - + - Absolute path in the (HDF5) file that points to the group within which - individual delocalization results are stored. + Absolute path in the (HDF5) file that points to the group within which + individual delocalization results are stored. - Matrix of nuclides representing how iontypes should be accounted for during - the delocalization. This is the most general approach to define if and how many - times an ion is to be counted. The tool performs a so-called atomic decomposition - of all iontypes, i.e. the tool analyses from how many atoms of each nuclide - or element respectively an (molecular) ion is built from. - - Taking the hydroxonium H3O+ molecular ion as an example: - It contains hydrogen and oxygen atoms. The multiplicity of hydrogen - is three whereas that of oxygen is one. Therefore, the respective atomic decomposition - analysis prior to the iso-surface computation adds three hydrogen counts for each - H3O+ ion. - - This is a practical solution which accepts that on the one hand not every bond is - broken during an atom probe experiment but also that ions may react further during - their flight to the detector. The exact details depend on the local field conditions, - quantum mechanics of possible electron transfer and thus the detailed trajectory - of the system and its electronic state. - - The detection of molecular ions instead of always single atom ions only is the - reason that an atom probe experiment tells much about field evaporation physics - but also faces an inherent loss of information with respect to the detailed spatial - arrangement that is independent of other imprecisions such as effect of limited - accuracy of reconstruction protocols and their parameterization. - - Unused values in each row of the matrix are nullified. - Nuclides are identified as hashed nuclide (see :ref:`NXion`) for further details. + Matrix of nuclides representing how iontypes should be accounted for during + the delocalization. This is the most general approach to define if and how many + times an ion is to be counted. The tool performs a so-called atomic decomposition + of all iontypes, i.e. the tool analyses from how many atoms of each nuclide + or element respectively an (molecular) ion is built from. + + Taking the hydroxonium H3O+ molecular ion as an example: + It contains hydrogen and oxygen atoms. The multiplicity of hydrogen + is three whereas that of oxygen is one. Therefore, the respective atomic decomposition + analysis prior to the iso-surface computation adds three hydrogen counts for each + H3O+ ion. + + This is a practical solution which accepts that on the one hand not every bond is + broken during an atom probe experiment but also that ions may react further during + their flight to the detector. The exact details depend on the local field conditions, + quantum mechanics of possible electron transfer and thus the detailed trajectory + of the system and its electronic state. + + The detection of molecular ions instead of always single atom ions only is the + reason that an atom probe experiment tells much about field evaporation physics + but also faces an inherent loss of information with respect to the detailed spatial + arrangement that is independent of other imprecisions such as effect of limited + accuracy of reconstruction protocols and their parameterization. + + Unused values in each row of the matrix are nullified. + Nuclides are identified as hashed nuclide (see :ref:`NXatom`) for further details. - + - Array of edge lengths of the cubic cells used for discretizing the reconstructed dataset - on a cuboidal 3D grid (:ref:`NXcg_grid`). The tool performs as many delocalization - computations as values are specified in grid_resolution. + Array of edge lengths of the cubic cells used for discretizing the reconstructed dataset + on a cuboidal 3D grid (:ref:`NXcg_grid`). The tool performs as many delocalization + computations as values are specified in grid_resolution. - + - Half the width of a :math:`{(2 \cdot n + 1)}^3` cubic kernel of cubic voxel - beyond which the Gaussian Ansatz function will be truncated. Intensity outside - the kernel is factorized into the kernel via a normalization procedure. + Half the width of a :math:`{(2 \cdot n + 1)}^3` cubic kernel of cubic voxel + beyond which the Gaussian Ansatz function will be truncated. Intensity outside + the kernel is factorized into the kernel via a normalization procedure. - Array of variance values :math:`\sigma` of the Gaussian Ansatz kernel - (:math:`\sigma_x := \sigma`, :math:`\sigma_x = \sigma_y = 2 \cdot \sigma_z`). - The tool performs as many delocalization computations as values are specified - in kernel_variance. + Array of variance values :math:`\sigma` of the Gaussian Ansatz kernel + (:math:`\sigma_x := \sigma`, :math:`\sigma_x = \sigma_y = 2 \cdot \sigma_z`). + The tool performs as many delocalization computations as values are specified + in kernel_variance. - + - How should the results of the kernel-density estimation be normalized into quantities. - By default, the tool computes the total number (intensity) of ions or elements. - Alternatively, the tool can compute the total intensity, the composition, - or the concentration of the ions/elements specified by the nuclide_whitelist. + How should the results of the kernel-density estimation be normalized into quantities. + By default, the tool computes the total number (intensity) of ions or elements. + Alternatively, the tool can compute the total intensity, the composition, + or the concentration of the ions/elements specified by the nuclide_whitelist. @@ -298,59 +329,59 @@ identifier(NX_UINT):--> - Specifies if the tool should report the delocalization 3D field values. + Specifies if the tool should report the delocalization 3D field values. - Configuration of the set of iso-surfaces to compute using that delocalization. - Such iso-surfaces are the starting point for a reconstruction of so-called objects or - (microstructual) features. Examples of scientific relevant are (line features e.g. dislocations - poles, surface features such as interfaces, i.e. phase and grain boundaries, or volumetric - features such as precipitates. - Users should be aware that reconstructed datasets in atom probe are a model and may face - inaccuracies and artifacts that can be mistaken incorrectly as microstructural features. + Configuration of the set of iso-surfaces to compute using that delocalization. + Such iso-surfaces are the starting point for a reconstruction of so-called objects or + (microstructural) features. Examples of scientific relevant are (line features e.g. dislocations + poles, surface features such as interfaces, i.e. phase and grain boundaries, or volumetric + features such as precipitates. + Users should be aware that reconstructed datasets in atom probe are a model and may face + inaccuracies and artifacts that can be mistaken incorrectly as microstructural features. - As it is detailed in `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_, the handling of - triangles at the surface (edge) of the dataset requires special attention especially for - composition-normalized delocalization. Here, it is possible that the composition - increases towards the edge of the dataset because the quotient of two numbers - that are both smaller than one is larger instead of smaller than the counter. - - By default, the tool uses a modified marching cubes algorithm of Lewiner et al. - which detects if voxels face such a situation. In this case, no triangles are generated - for such voxels. - - Alternatively, keep_edge_triangles instructs the tool to not remove triangles at the - edge of the dataset at the cost of bias. When using this keep_edge_triangles users - should understand that all features in contact with the edge of the dataset get usually - artificial enlarged. Consequently, triangulated surface meshes of these objects are - closed during the marching. However, this closure is artificial and can biased shape - analyses for those objects. This also holds for such practices that are offered in - proprietary software like IVAS / AP Suite. The situation is comparable to analyses - of grain shapes via orientation microscopy from electron microscopy or X-ray - diffraction tomography. Features at the edge of the dataset may have not been - captured fully. - - Thanks to collaboration with V. V. Rielli and S. Primig from the Sydney atom probe group, - paraprobe-nanochem implements a complete pipeline to process features at the edge of the - dataset. Specifically, these are modelled and replaced with closed polyhedral objects using - an iterative mesh and hole-filling procedures with fairing operations. - - The tool bookkeeps such objects separately to lead the decision whether or not to - consider these objects to the user. Users should be aware that results from fairing operations - should be compared to results from analyses where all objects at the edge - of the dataset have been removed. Furthermore, users should be careful with overestimating - the statistical significance of their dataset especially when using atom probe when they - use their atom probe result to compare different descriptors. Even though a dataset may - deliver statistically significant results for compositions, this does not necessarily mean that - same dataset will also yield statistically significant and insignificantly biased results for - 3D object analyses! - - Being able to quantify these effects and making atom probers aware of these subtleties - was one of the main reasons why the paraprobe-nanochem tool was implemented. + As it is detailed in `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_, the handling of + triangles at the surface (edge) of the dataset requires special attention especially for + composition-normalized delocalization. Here, it is possible that the composition + increases towards the edge of the dataset because the quotient of two numbers + that are both smaller than one is larger instead of smaller than the counter. + + By default, the tool uses a modified marching cubes algorithm of Lewiner et al. + which detects if voxels face such a situation. In this case, no triangles are generated + for such voxels. + + Alternatively, keep_edge_triangles instructs the tool to not remove triangles at the + edge of the dataset at the cost of bias. When using this keep_edge_triangles users + should understand that all features in contact with the edge of the dataset get usually + artificial enlarged. Consequently, triangulated surface meshes of these objects are + closed during the marching. However, this closure is artificial and can bias shape + analyses for those objects. This also holds for such practices that are offered in + proprietary software like IVAS / AP Suite. The situation is comparable to analyses + of grain shapes via orientation microscopy from electron microscopy or X-ray + diffraction tomography. Features at the edge of the dataset may have not been + captured fully. + + Thanks to collaboration with V. V. Rielli and S. Primig from the Sydney atom probe group, + paraprobe-nanochem implements a complete pipeline to process features at the edge of the + dataset. Specifically, these are modelled and replaced with closed polyhedral objects using + an iterative mesh and hole-filling procedures with fairing operations. + + The tool bookkeeps such objects separately to lead the decision whether or not to + consider these objects to the user. Users should be aware that results from fairing operations + should be compared to results from analyses where all objects at the edge + of the dataset have been removed. Furthermore, users should be careful with overestimating + the statistical significance of their dataset especially when using atom probe when they + use their atom probe result to compare different descriptors. Even though a dataset may + deliver statistically significant results for compositions, this does not necessarily mean that + same dataset will also yield statistically significant and insignificantly biased results for + 3D object analyses! + + Being able to quantify these effects and making atom probers aware of these subtleties + was one of the main reasons why the paraprobe-nanochem tool was implemented. @@ -359,274 +390,274 @@ identifier(NX_UINT):--> - The ion-to-surface distance that is used in the analyses of features to identify whether - these are laying inside the dataset or close to the surface (edge) of the dataset. - - If an object has at least one ion with an ion-to-surface-distance below this threshold, - the object is considered close to the edge of the dataset. The tool uses a distance-based - approach to solve the in general complicated and involved treatment of computing - volumetric intersections between closed 2-manifolds that are not necessarily convex. - The main practical reason is that such computational geometry analyses face numerical - robustness issues as a consequence of which a mesh can be detected as being completely - inside another mesh although in reality it is only :math:`\epsilon`-close only, i.e. almost - touching only the edge (e.g. from inside). - - Practically, humans would likely still state in such case that the object is close to the - edge of the dataset; however mathematically the object is indeed completely inside. - In short, a distance-based approach is rigorous and flexible. + The ion-to-surface distance that is used in the analyses of features to identify whether + these are laying inside the dataset or close to the surface (edge) of the dataset. + + If an object has at least one ion with an ion-to-surface-distance below this threshold, + the object is considered close to the edge of the dataset. The tool uses a distance-based + approach to solve the in general complicated and involved treatment of computing + volumetric intersections between closed 2-manifolds that are not necessarily convex. + The main practical reason is that such computational geometry analyses face numerical + robustness issues as a consequence of which a mesh can be detected as being completely + inside another mesh although in reality it is only :math:`\epsilon`-close only, i.e. almost + touching only the edge (e.g. from inside). + + Practically, humans would likely still state in such case that the object is close to the + edge of the dataset; however mathematically the object is indeed completely inside. + In short, a distance-based approach is rigorous and flexible. - Iso-contour values. For each value, the tool computes an iso-surface and performs - subsequent analyses for each iso-surface. The unit depends on the choice for the - normalization of the accumulated ion intensity values per voxel: - - * total, total number of ions, irrespective their iontype - * candidates, total number of ions with type in the isotope_whitelist. - * composition, candidates but normalized by composition, i.e. at.-% - * concentration, candidates but normalized by voxel volume, i.e. ions/nm^3 + Iso-contour values. For each value, the tool computes an iso-surface and performs + subsequent analyses for each iso-surface. The unit depends on the choice for the + normalization of the accumulated ion intensity values per voxel: + + * total, total number of ions, irrespective their iontype + * candidates, total number of ions with type in the isotope_whitelist. + * composition, candidates but normalized by composition, i.e. at.-% + * concentration, candidates but normalized by voxel volume, i.e. ions/nm^3 + - Specifies if the tool should report the triangle soup which represents each triangle of the - iso-surface complex. The resulting set of triangles is colloquially referred to as a soup - because different sub-set may not be connected. - - Each triangle is reported with an ID specifying to which triangle cluster (with IDs starting at zero) - the triangle belongs. The clustering of triangles within the soup is performed with a - modified DBScan algorithm. + Specifies if the tool should report the triangle soup which represents each triangle of the + iso-surface complex. The resulting set of triangles is colloquially referred to as a soup + because different sub-set may not be connected. + + Each triangle is reported with an ID specifying to which triangle cluster (with IDs starting at zero) + the triangle belongs. The clustering of triangles within the soup is performed with a + modified DBScan algorithm. - Specifies if the tool should analyze for each cluster of triangles how they can be combinatorially - processed to describe a closed polyhedron. Such a closed polyhedron (not-necessarily convex!) - can be used to describe objects with relevance in the microstructure. - - Users should be aware that the resulting mesh does not necessarily represent the original precipitate. - In fact, inaccuracies in the reconstructed positions cause inaccuracies in all downstream processing - operations. Especially the effect on one-dimensional spatial statistics like nearest neighbor correlation - functions were discussed in the literature `B. Gault et al. <https://doi.org/10.1017/S1431927621012952>`_. - - In continuation of these thoughts, this applies also to reconstructed objects. - A well-known example is the discussion of shape deviations of scandium-rich precipitates in aluminium alloys - which in reconstructions may appear as ellipsoids although they should be indeed almost spherical - provided their size is larger than the atomic length scale. + Specifies if the tool should analyze for each cluster of triangles how they can be combinatorially + processed to describe a closed polyhedron. Such a closed polyhedron (not-necessarily convex!) + can be used to describe objects with relevance in the microstructure. + + Users should be aware that the resulting mesh does not necessarily represent the original precipitate. + In fact, inaccuracies in the reconstructed positions cause inaccuracies in all downstream processing + operations. Especially the effect on one-dimensional spatial statistics like nearest neighbor correlation + functions were discussed in the literature `B. Gault et al. <https://doi.org/10.1017/S1431927621012952>`_. + + In continuation of these thoughts, this applies also to reconstructed objects. + A well-known example is the discussion of shape deviations of scandium-rich precipitates in aluminum alloys + which in reconstructions may appear as ellipsoids although they should be indeed almost spherical + provided their size is larger than the atomic length scale. - Specifies if the tool should report a triangulated surface mesh for each identified closed polyhedron. - It is common that a marching cubes algorithm creates iso-surfaces with a fraction of tiny sub-complexes - (e.g. small isolated tetrahedra). - - These can be small tetrahedra/polyhedra about the center of a voxel of the support grid - on which marching cubes operates. Such objects may not contain an ion; especially when considering - that delocalization procedures smoothen the positions of the ions. Although these small objects are - interesting from a numerical point of view, scientists may argue they are not worth to be reported because - a microstructural feature should contain at least a few atoms to become relevant. - Therefore, paraprobe-nanochem by default does not report closed objects which bound a volume - that contains no ion. + Specifies if the tool should report a triangulated surface mesh for each identified closed polyhedron. + It is common that a marching cubes algorithm creates iso-surfaces with a fraction of tiny sub-complexes + (e.g. small isolated tetrahedra). + + These can be small tetrahedra/polyhedra about the center of a voxel of the support grid + on which marching cubes operates. Such objects may not contain an ion; especially when considering + that delocalization procedures smoothen the positions of the ions. Although these small objects are + interesting from a numerical point of view, scientists may argue they are not worth to be reported because + a microstructural feature should contain at least a few atoms to become relevant. + Therefore, paraprobe-nanochem by default does not report closed objects which bound a volume + that contains no ion. - Specifies if the tool should report properties of each closed polyhedron, such - as volume and other details. + Specifies if the tool should report properties of each closed polyhedron, such + as volume and other details. - Specifies if the tool should report for each closed polyhedron an approximately optimal bounding box - fitted to all triangles of the surface mesh of the object and ion positions inside or on the surface of the mesh. - This bounding box informs about the closed object's shape (aspect ratios). - - Users should be aware that the choice of the algorithm to compute the bounding box can have an - effect on aspect ratio statistics. It is known that computing the true optimal bounding box of in 3D - is an :math:`\mathcal{O}^3`-time-complex task. The tool uses well-established approximate algorithms - of the Computational Geometry Algorithms Library (CGAL). + Specifies if the tool should report for each closed polyhedron an approximately optimal bounding box + fitted to all triangles of the surface mesh of the object and ion positions inside or on the surface of the mesh. + This bounding box informs about the closed object's shape (aspect ratios). + + Users should be aware that the choice of the algorithm to compute the bounding box can have an + effect on aspect ratio statistics. It is known that computing the true optimal bounding box of in 3D + is an :math:`\mathcal{O}^3`-time-complex task. The tool uses well-established approximate algorithms + of the Computational Geometry Algorithms Library (CGAL). - Specifies if the tool should report for each closed polyhedron all evaporation IDs of those ions which - lay inside or on the boundary of the polyhedron. This information is used by the paraprobe-intersector - tool to infer if two objects share common ions, which is then understood as that the two objects intersect. - - Users should be aware that two arbitrarily closed polyhedra in three-dimensional space can intersect - but not share a common ion. In fact, the volume bounded by the polyhedron has sharp edges and flat - face(t)s. When taking two objects, an edge of one object may for instance pierce into the surface of - another object. In this case the objects partially overlap / intersect volumetrically; however this piercing - might be so small or happening in the volume between two reconstructed ion positions. Consequently, - sharing ions is a sufficient but not a necessary condition for interpreting (volumetric) intersections - between objects. - - Paraprobe-intersector implements a rigorous alternative to handle such intersections using a tetrahedralization - of closed objects. However, in many practical cases, we found through examples that there are polyhedra (especially when they are non-convex and have almost point-like) connected channels, where - tetrahedralization libraries have challenges dealing with. In this case, checking intersections - via shared_ions is a more practical alternative. + Specifies if the tool should report for each closed polyhedron all evaporation IDs of those ions which + lay inside or on the boundary of the polyhedron. This information is used by the paraprobe-intersector + tool to infer if two objects share common ions, which is then understood as that the two objects intersect. + + Users should be aware that two arbitrarily closed polyhedra in three-dimensional space can intersect + but not share a common ion. In fact, the volume bounded by the polyhedron has sharp edges and flat + face(t)s. When taking two objects, an edge of one object may for instance pierce into the surface of + another object. In this case the objects partially overlap / intersect volumetrically; however this piercing + might be so small or happening in the volume between two reconstructed ion positions. Consequently, + sharing ions is a sufficient but not a necessary condition for interpreting (volumetric) intersections + between objects. + + Paraprobe-intersector implements a rigorous alternative to handle such intersections using a tetrahedralization + of closed objects. However, in many practical cases, we found through examples that there are polyhedra (especially when they are non-convex and have almost point-like) connected channels, where + tetrahedralization libraries have challenges dealing with. In this case, checking intersections + via shared_ions is a more practical alternative. - Specifies if the tool should report if a (closed) object has contact with the surface aka edge of the dataset. - For this the tool currently inspects if the shortest distance between the set of triangles of the triangulated - surface mesh and the triangles of the edge model is larger than edge_threshold. - If this is the case, the object is assumed to be deeply embedded in the interior of the dataset. - Otherwise, the object is considered to have an edge contact, i.e. it shape is likely affected by the edge. + Specifies if the tool should report if a (closed) object has contact with the surface aka edge of the dataset. + For this the tool currently inspects if the shortest distance between the set of triangles of the triangulated + surface mesh and the triangles of the edge model is larger than edge_threshold. + If this is the case, the object is assumed to be deeply embedded in the interior of the dataset. + Otherwise, the object is considered to have an edge contact, i.e. it shape is likely affected by the edge. - Specifies if the tool should analyze a closed polyhedron (aka proxy) for each cluster of triangles whose - combinatorial analysis according to has_object returned that the object is not a closed polyhedron. - Such proxies are closed via iterative hole-filling, mesh refinement, and fairing operations. - - Users should be aware that the resulting mesh does not necessarily represent the original feature. - In most cases objects, precipitates in atom probe end up as open objects because they have been - clipped by the edge of the dataset. Using a proxy is in this case a strategy to still be able to account - for these objects. However, users should make themselves familiar with the consequences and - potential biases which this can introduce into the analysis. + Specifies if the tool should analyze a closed polyhedron (aka proxy) for each cluster of triangles whose + combinatorial analysis according to has_object returned that the object is not a closed polyhedron. + Such proxies are closed via iterative hole-filling, mesh refinement, and fairing operations. + + Users should be aware that the resulting mesh does not necessarily represent the original feature. + In most cases objects, precipitates in atom probe end up as open objects because they have been + clipped by the edge of the dataset. Using a proxy is in this case a strategy to still be able to account + for these objects. However, users should make themselves familiar with the consequences and + potential bias which this can introduce into the analysis. - Like has_object_geometry but for the proxies. + Like has_object_geometry but for the proxies. - Like has_object_properties but for the proxies. + Like has_object_properties but for the proxies. - Like has_object_obb but for the proxies. + Like has_object_obb but for the proxies. - Like has_object_ions but for the proxies. + Like has_object_ions but for the proxies. - Like has_object_edge_contact but for the proxies. + Like has_object_edge_contact but for the proxies. - Specifies if the tool should report for each closed object a (cylindrical) region-of-interest (ROI) that gets - placed, centered, and aligned with the local normal for each triangle of the object. + Specifies if the tool should report for each closed object a (cylindrical) region-of-interest (ROI) that gets + placed, centered, and aligned with the local normal for each triangle of the object. - Specifies if the tool should report for each ROI that was placed at a triangle of each object if this ROI intersects - with the edge the dataset. Currently, the tool supports cylindrical ROIs. A computational geometry test is - performed to check for a possible intersection of each ROI with the triangulated surface mesh that is defined - via surface. Results of this cylinder-set-of-triangles intersection are interpreted as follows: - If the cylinder intersects with at least one triangle of the surface (mesh) the ROI is assumed to make edge contact. - Otherwise, the ROI is assumed to make no edge contact. - - Users should note that this approach does not work if the ROI is laying completely outside the dataset as also - in this case the cylinder intersects with any triangle. However, for atom probe this case is practically irrelevant - provided constructions such as alpha shapes or alpha wrappings (such as paraproeb-surfacer does) about the - ions of the entire reconstructed volume are used. + Specifies if the tool should report for each ROI that was placed at a triangle of each object if this ROI intersects + with the edge the dataset. Currently, the tool supports cylindrical ROIs. A computational geometry test is + performed to check for a possible intersection of each ROI with the triangulated surface mesh that is defined + via surface. Results of this cylinder-set-of-triangles intersection are interpreted as follows: + If the cylinder intersects with at least one triangle of the surface (mesh) the ROI is assumed to make edge contact. + Otherwise, the ROI is assumed to make no edge contact. + + Users should note that this approach does not work if the ROI is laying completely outside the dataset as also + in this case the cylinder intersects with any triangle. However, for atom probe this case is practically irrelevant + provided constructions such as alpha shapes or alpha wrappings (such as paraprobe-surfacer does) about the + ions of the entire reconstructed volume are used. - Use a principle component analysis (PCA) to mesh a single free-standing interface patch within - the reconstructed volume that is decorated by ions of specific iontypes (e.g. solute atoms). - - Interface_meshing is a typical starting point for the quantification of Gibbsian interfacial excess - in cases when closed objects constructed from patches e.g. iso-surfaces are not available or - when there is no substantial or consistently oriented concentration gradients across an interface - patch. The functionality can also be useful when the amount of latent crystallographic information - within the point cloud is insufficient or when combined with interface_meshing based on ion density - traces in field-desorption maps (see `Y. Wei et al. <https://doi.org/10.1371/journal.pone.0225041>`_ - and `A. Breen et al. <https://github.com/breen-aj/detector>`_ for details). - - Noteworthy to mention is that the method used is conceptually similar to the work of `Z. Peng et al. <https://doi.org/10.1017/S1431927618016112>`_ and related work (DCOM algorithm) by `P. Felfer et al. <https://doi.org/10.1016/j.ultramic.2015.06.002>`_. Compared to these implementations - paraprobe-nanochem uses inspection functionalities which detect potential geometric - inconsistencies or self-interactions of the evolved DCOM mesh. + Use a principle component analysis (PCA) to mesh a single free-standing interface patch within + the reconstructed volume that is decorated by ions of specific iontypes (e.g. solute atoms). + + Interface_meshing is a typical starting point for the quantification of Gibbsian interfacial excess + in cases when closed objects constructed from patches e.g. iso-surfaces are not available or + when there is no substantial or consistently oriented concentration gradients across an interface + patch. The functionality can also be useful when the amount of latent crystallographic information + within the point cloud is insufficient or when combined with interface_meshing based on ion density + traces in field-desorption maps (see `Y. Wei et al. <https://doi.org/10.1371/journal.pone.0225041>`_ + and `A. Breen et al. <https://github.com/breen-aj/detector>`_ for details). + + Noteworthy to mention is that the method used is conceptually similar to the work of `Z. Peng et al. <https://doi.org/10.1017/S1431927618016112>`_ and related work (DCOM algorithm) by `P. Felfer et al. <https://doi.org/10.1016/j.ultramic.2015.06.002>`_. Compared to these implementations + paraprobe-nanochem uses inspection functionalities which detect potential geometric + inconsistencies or self-interactions of the evolved DCOM mesh. - - - + + - + - + - + - + - A precomputed triangulated surface mesh representing a model (of the surface) - of the edge of the dataset. This model can be used to detect and control - various sources of bias in the analyses. + A precomputed triangulated surface mesh representing a model (of the surface) + of the edge of the dataset. This model can be used to detect and control + various sources of bias in the analyses. - + - Absolute path in the (HDF5) file that points to the array - of vertex positions for the triangles in that triangle_set. + Absolute path in the (HDF5) file that points to the array + of vertex positions for the triangles in that triangle_set. - Absolute path in the (HDF5) file that points to the array - of vertex indices for the triangles in that triangle_set. + Absolute path in the (HDF5) file that points to the array + of vertex indices for the triangles in that triangle_set. - + - + - + - + - + - + - + @@ -635,7 +666,7 @@ NEW ISSUE: here we need to specify how the meshes were smoothened--> @@ -651,41 +682,41 @@ identifier(NX_UINT):--> - How is the PCA initialized: - - * default, means based on segregated solutes in the ROI - * control_point_file, means based on reading an external list of - control points, currently coming from the Leoben APT_Analyzer. - - The control_point_file is currently expected with a specific format. - The Leoben group lead by L. Romaner has developed a GUI tool `A. Reichmann et al. <https://github.com/areichm/APT_analyzer>`_ creates a control_point_file that - can be parsed by paraprobe-parmsetup-nanochem to match the here required - formatting in control_points. + How is the PCA initialized: + + * default, means based on segregated solutes in the ROI + * control_point_file, means based on reading an external list of + control points, currently coming from the Leoben APT_Analyzer. + + The control_point_file is currently expected with a specific format. + The Leoben group lead by L. Romaner has developed a GUI tool `A. Reichmann et al. <https://github.com/areichm/APT_analyzer>`_ creates a control_point_file that + can be parsed by paraprobe-parmsetup-nanochem to match the here required + formatting in control_points. - + - Details about the control point file used. + Details about the control point file used. - + - X, Y, Z position matrix of disjoint control points. + X, Y, Z position matrix of disjoint control points. - Method used for identifying and refining the location of the interface. Currently, - paraprobe-nanochem implements a PCA followed by an iterative loop of isotropic - mesh refinement and DCOM step(s), paired with self-intersection detection. + Method used for identifying and refining the location of the interface. Currently, + paraprobe-nanochem implements a PCA followed by an iterative loop of isotropic + mesh refinement and DCOM step(s), paired with self-intersection detection. @@ -693,10 +724,10 @@ identifier(NX_UINT):--> - Specify those nuclides which the tool should inspect iontypes for if they contain such nuclides. - If this is the case ions of such type are taken with the number of nuclides of this multiplicity found. - The atoms of these ions are assumed to serve as useful markers for locating the interface and - refining the interface mesh. + Specify those nuclides which the tool should inspect iontypes for if they contain such nuclides. + If this is the case ions of such type are taken with the number of nuclides of this multiplicity found. + The atoms of these ions are assumed to serve as useful markers for locating the interface and + refining the interface mesh. @@ -705,9 +736,9 @@ identifier(NX_UINT):--> - Array of nuclide iontypes to filter. + Array of nuclide iontypes to filter. - + @@ -715,168 +746,167 @@ identifier(NX_UINT):--> - How many times should the DCOM and mesh refinement be applied? + How many times should the DCOM and mesh refinement be applied? - Array of decreasing positive not smaller than one nanometer real values - which specify how the initial triangles of the mesh should be iteratively - refined by edge splitting and related mesh refinement operations. + Array of decreasing positive not smaller than one nanometer real values + which specify how the initial triangles of the mesh should be iteratively + refined by edge splitting and related mesh refinement operations. - + - Array of decreasing positive not smaller than one nanometer real values - which specify the radius of the spherical region of interest within which the - DCOM algorithm decides for each vertex how the vertex might be relocated. - - The larger it is the DCOM radius in relation to the target_edge_length the more - likely it becomes that vertices will be relocated so substantially that triangle - self-intersections may occur. The tool detects these and stops in a controlled - manner so that the user can repeat the analyses with using a different parameterization. + Array of decreasing positive not smaller than one nanometer real values + which specify the radius of the spherical region of interest within which the + DCOM algorithm decides for each vertex how the vertex might be relocated. + + The larger it is the DCOM radius in relation to the target_edge_length the more + likely it becomes that vertices will be relocated so substantially that triangle + self-intersections may occur. The tool detects these and stops in a controlled + manner so that the user can repeat the analyses with using a different parameterization. - + - Array of integers which specify for each DCOM step how many times the mesh - should be iteratively smoothened. Users should be aware that all three arrays - target_edge_length, target_dcom_radius, and target_smoothing_step are interpreted - in the same sequence, i.e. the zeroth entry of each array specifies the respective - parameter values to be used in the first DCOM iteration. The first entry of each array - those for the second DCOM iteration and so on and so forth. + Array of integers which specify for each DCOM step how many times the mesh + should be iteratively smoothened. Users should be aware that all three arrays + target_edge_length, target_dcom_radius, and target_smoothing_step are interpreted + in the same sequence, i.e. the zeroth entry of each array specifies the respective + parameter values to be used in the first DCOM iteration. The first entry of each array + those for the second DCOM iteration and so on and so forth. - + - Analysis of one-dimensional profiles in ROIs placed in the dataset. - Such analyses are useful for quantifying interfacial excess or for - performing classical composition analyses. - - The tool will test for each ROIs if it is completely embedded in the dataset. - Specifically, each such test evaluates if the ROI cuts at least one triangle - of the triangulated surface mesh that is referred to by surface. - If this is the case the ROI is marked as one close to the surface - and not analyzed further. Otherwise, the ROI is marked as one far - from the surface and processed further. - - For each ROI the tool computes atomically decomposed profiles. - This means, molecular ions are splitted into nuclides as many times as - their respective multiplicity. For each processed ROI the tool stores - a sorted list of signed distance values to enable post-processing with - other software like e.g. reporter to perform classical - Krakauer/Seidman-style interfacial excess analyses. - - Users should be aware that the latter intersection analysis is not - a volumetric intersection analysis. Given that the triangulated mesh - referred to in surface is not required to mesh neither a watertight - nor convex polyhedron a rigorous testing of volumetric intersection - is much more involved. If the mesh is watertight one could use split - the task in first tessellating the mesh into convex polyhedra (e.g. - tetrahedra and apply a volumetric intersection method like the - Gilbert-Johnson-Keerthi algorithm (GJK). In cases when the mesh is not - even watertight distance-based segmentation in combination with again - intersection of triangles and convex polyhedra is a robust but currently - not implemented method to quantify intersections. + Analysis of one-dimensional profiles in ROIs placed in the dataset. + Such analyses are useful for quantifying interfacial excess or for + performing classical composition analyses. + + The tool will test for each ROIs if it is completely embedded in the dataset. + Specifically, each such test evaluates if the ROI cuts at least one triangle + of the triangulated surface mesh that is referred to by surface. + If this is the case the ROI is marked as one close to the surface + and not analyzed further. Otherwise, the ROI is marked as one far + from the surface and processed further. + + For each ROI the tool computes atomically decomposed profiles. + This means, molecular ions are split into nuclides as many times as + their respective multiplicity. For each processed ROI the tool stores + a sorted list of signed distance values to enable post-processing with + other software like e.g. reporter to perform classical + Krakauer/Seidman-style interfacial excess analyses. + + Users should be aware that the latter intersection analysis is not + a volumetric intersection analysis. Given that the triangulated mesh + referred to in surface is not required to mesh neither a watertight + nor convex polyhedron a rigorous testing of volumetric intersection + is much more involved. If the mesh is watertight one could use split + the task in first tessellating the mesh into convex polyhedra (e.g. + tetrahedra and apply a volumetric intersection method like the + Gilbert-Johnson-Keerthi algorithm (GJK). In cases when the mesh is not + even watertight distance-based segmentation in combination with again + intersection of triangles and convex polyhedra is a robust but currently + not implemented method to quantify intersections. - - - + + - + - + - + - + - A precomputed triangulated surface mesh representing a model (of the surface) - of the edge of the dataset. This model can be used to detect and control - various sources of bias in the analyses. + A precomputed triangulated surface mesh representing a model (of the surface) + of the edge of the dataset. This model can be used to detect and control + various sources of bias in the analyses. - + - Absolute path in the (HDF5) file that points to the array - of vertex positions for the triangles in that triangle_set. + Absolute path in the (HDF5) file that points to the array + of vertex positions for the triangles in that triangle_set. - Absolute path in the (HDF5) file that points to the array - of vertex indices for the triangles in that triangle_set. + Absolute path in the (HDF5) file that points to the array + of vertex indices for the triangles in that triangle_set. - + - Distance between each ion and triangulated surface mesh. + Distance between each ion and triangulated surface mesh. - + - Absolute path in the (HDF5) file that points to the distance values. - The tool assumes that the values are stored in the same order as - points (ions). + Absolute path in the (HDF5) file that points to the distance values. + The tool assumes that the values are stored in the same order as + points (ions). - + - A precomputed triangulated mesh of the feature representing a model of the - interface at which to place ROIs to profile. This can be the mesh of an - interface as returned e.g. by a previous interface_meshing task or the - mesh of an iso-surface from a previous delocalization task. + A precomputed triangulated mesh of the feature representing a model of the + interface at which to place ROIs to profile. This can be the mesh of an + interface as returned e.g. by a previous interface_meshing task or the + mesh of an iso-surface from a previous delocalization task. - + - Absolute HDF5 path to the dataset that specifies the array of vertex positions. + Absolute HDF5 path to the dataset that specifies the array of vertex positions. - Absolute HDF5 path to the dataset that specifies the array of facet indices - which refer to vertices. + Absolute HDF5 path to the dataset that specifies the array of facet indices + which refer to vertices. - Absolute HDF5 path to the dataset that specifies the array of facet signed unit - normals. + Absolute HDF5 path to the dataset that specifies the array of facet signed unit + normals. - Absolute HDF5 path to the dataset that specifies the array of vertex signed unit - normals. + Absolute HDF5 path to the dataset that specifies the array of vertex signed unit + normals. - If interface_model is isosurface this filter can be used to restrict the analysis to specific - patches of an iso-surface. + If interface_model is isosurface this filter can be used to restrict the analysis to specific + patches of an iso-surface. - + - To enable an additional filtration of specific parts of the feature - mesh it is recommended to feed precomputed distances of each ion to - the triangles of the feature mesh. + To enable an additional filtration of specific parts of the feature + mesh it is recommended to feed precomputed distances of each ion to + the triangles of the feature mesh. - + - Absolute path in the (HDF5) file that points to the distance values. - The tool assumes that the values are stored in the same order as - points (ions). + Absolute path in the (HDF5) file that points to the distance values. + The tool assumes that the values are stored in the same order as + points (ions). - + - + - + - + - + - + - + @@ -944,7 +974,7 @@ from normals of neighboring facets, type of weighting schemes can affect results @@ -960,30 +990,30 @@ identifier(NX_UINT):--> - As an alternative mode the tool can be instructed to place ROIs - at specific locations into the dataset. This is the programmatic - equivalent to the classical approach in atom probe to place ROIs - for composition analyses via positioning and rotating them via - a graphical user interface (such as in IVAS / AP Suite). + As an alternative mode the tool can be instructed to place ROIs + at specific locations into the dataset. This is the programmatic + equivalent to the classical approach in atom probe to place ROIs + for composition analyses via positioning and rotating them via + a graphical user interface (such as in IVAS / AP Suite). - + - + - + - + - + @@ -993,7 +1023,7 @@ cardinality(NX_POSINT):--> but cylinders are most frequently used--> - Which type of distance should be reported for the profile. + Which type of distance should be reported for the profile. @@ -1001,8 +1031,8 @@ but cylinders are most frequently used--> - For each ROI, along which direction should the cylindrical ROI - be oriented if ROIs are placed at triangles of the feature mesh. + For each ROI, along which direction should the cylindrical ROI + be oriented if ROIs are placed at triangles of the feature mesh. @@ -1010,21 +1040,21 @@ but cylinders are most frequently used--> - For each ROI, how high (projected onto the cylinder axis) should - the cylindrical ROI be if ROIs are placed at triangles - of the feature mesh. + For each ROI, how high (projected onto the cylinder axis) should + the cylindrical ROI be if ROIs are placed at triangles + of the feature mesh. - For each ROI, how wide (in radius) should the cylindrical ROI - be if ROIs are placed at triangles of the feature mesh. + For each ROI, how wide (in radius) should the cylindrical ROI + be if ROIs are placed at triangles of the feature mesh. - + diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml index 4b8e2d3a55..c1c1b20621 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml @@ -1,9 +1,9 @@ - + - The total number of faces of triangles. + The total number of faces of triangles. - The total number of XDMF values to represent all faces of triangles via XDMF. + The total number of XDMF values to represent all faces of triangles via XDMF. - The total number of entries in a feature dictionary. + The total number of entries in a feature dictionary. - The total number of volumetric features. + The total number of volumetric features. - The total number of member distinguished when reporting composition. + The total number of member distinguished when reporting composition. - The total number of ROIs placed in an oned_profile task. + The total number of ROIs placed in an oned_profile task. - Application definition for results files of the paraprobe-nanochem tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + Application definition for results files of the paraprobe-nanochem tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. @@ -97,7 +97,7 @@ The cardinality/total number of triangles in the triangle soup.--> - + @@ -111,11 +111,11 @@ The cardinality/total number of triangles in the triangle soup.--> - How were results of the kernel-density estimation normalized: - * total, the total number (intensity) of ions or elements. - * candidates, the total number (intensity) of ions matching weighting_model - * composition, the value for candidates divided by the value for total, - * concentration, the value for candidates divided by the volume of the cell. + How were results of the kernel-density estimation normalized: + * total, the total number (intensity) of ions or elements. + * candidates, the total number (intensity) of ions matching weighting_model + * composition, the value for candidates divided by the value for total, + * concentration, the value for candidates divided by the volume of the cell. @@ -126,18 +126,18 @@ The cardinality/total number of triangles in the triangle soup.--> - The discretized domain/grid on which the delocalization is applied. + The discretized domain/grid on which the delocalization is applied. - + - + - The total number of cells/voxels of the grid. + The total number of cells/voxels of the grid. @@ -147,7 +147,7 @@ The cardinality/total number of triangles in the triangle soup.--> - The symmetry of the lattice defining the shape of the unit cell. + The symmetry of the lattice defining the shape of the unit cell. @@ -155,8 +155,8 @@ The cardinality/total number of triangles in the triangle soup.--> - The unit cell dimensions according to the coordinate system defined under - coordinate_system. + The unit cell dimensions according to the coordinate system defined under + coordinate_system. @@ -164,31 +164,31 @@ The cardinality/total number of triangles in the triangle soup.--> - Number of unit cells along each of the d-dimensional base vectors. - The total number of cells, or grid points has to be the cardinality. - If the grid has an irregular number of grid positions in each direction, - as it could be for instance the case of a grid where all grid points - outside some masking primitive are removed, this extent field should - not be used. Instead use the coordinate field. + Number of unit cells along each of the d-dimensional base vectors. + The total number of cells, or grid points has to be the cardinality. + If the grid has an irregular number of grid positions in each direction, + as it could be for instance the case of a grid where all grid points + outside some masking primitive are removed, this extent field should + not be used. Instead use the coordinate field. - + - Integer which specifies the first index to be used for distinguishing identifiers for cells. - Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are - defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. - For explicit indexing the identifier array has to be defined. + Integer which specifies the first index to be used for distinguishing identifiers for cells. + Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are + defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. + For explicit indexing the identifier array has to be defined. - Halfwidth of the kernel about the central voxel. - The shape of the kernel is that of a cuboid - of extent 2*kernel_extent[i] + 1 in each dimension i. + Halfwidth of the kernel about the central voxel. + The shape of the kernel is that of a cuboid + of extent 2*kernel_extent[i] + 1 in each dimension i. @@ -196,7 +196,7 @@ The cardinality/total number of triangles in the triangle soup.--> - Functional form of the kernel (Ansatz function). + Functional form of the kernel (Ansatz function). @@ -204,8 +204,8 @@ The cardinality/total number of triangles in the triangle soup.--> - Standard deviation :math:`\sigma_i` of the kernel in each dimension - in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. + Standard deviation :math:`\sigma_i` of the kernel in each dimension + in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. @@ -213,60 +213,60 @@ The cardinality/total number of triangles in the triangle soup.--> - Expectation value :math:`\mu_i` of the kernel in each dimension - in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. + Expectation value :math:`\mu_i` of the kernel in each dimension + in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. - + - A tight axis-aligned bounding box about the grid. + A tight axis-aligned bounding box about the grid. - For atom probe should be set to true. + For atom probe should be set to true. - + - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly or explicitly. - For implicit indexing the identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. - For explicit indexing the identifier array has to be defined. + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly or explicitly. + For implicit indexing the identifiers are defined on the interval + :math:`[identifier\_offset, identifier\_offset + c - 1]`. + For explicit indexing the identifier array has to be defined. - + - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly or explicitly. - For implicit indexing the identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array - has to be defined. + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly or explicitly. + For implicit indexing the identifiers are defined on the interval + :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array + has to be defined. - + - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly or explicitly. - For implicit indexing the identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array - has to be defined. + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly or explicitly. + For implicit indexing the identifiers are defined on the interval + :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array + has to be defined. - Positions of the vertices. - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. + Positions of the vertices. + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. @@ -275,16 +275,16 @@ The cardinality/total number of triangles in the triangle soup.--> - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. @@ -293,10 +293,10 @@ The cardinality/total number of triangles in the triangle soup.--> - 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. + 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. @@ -304,15 +304,15 @@ The cardinality/total number of triangles in the triangle soup.--> - How many distinct boundaries are distinguished? - Most grids discretize a cubic or cuboidal region. In this case - six sides can be distinguished, each making an own boundary. + How many distinct boundaries are distinguished? + Most grids discretize a cubic or cuboidal region. In this case + six sides can be distinguished, each making an own boundary. - Name of the boundaries. E.g. left, right, front, back, bottom, top, - The field must have as many entries as there are number_of_boundaries. + Name of the boundaries. E.g. left, right, front, back, bottom, top, + The field must have as many entries as there are number_of_boundaries. @@ -320,14 +320,14 @@ The cardinality/total number of triangles in the triangle soup.--> - The boundary conditions for each boundary: - - 0 - undefined - 1 - open - 2 - periodic - 3 - mirror - 4 - von Neumann - 5 - Dirichlet + The boundary conditions for each boundary: + + 0 - undefined + 1 - open + 2 - periodic + 3 - mirror + 4 - von Neumann + 5 - Dirichlet @@ -335,20 +335,20 @@ The cardinality/total number of triangles in the triangle soup.--> - - + + - The result of the delocalization :math:`\Phi = f(x, y, z)` based on which subsequent iso-surfaces - will be computed. In commercial software so far there is no possibility to export this information. - - If the intensity for all matches of the weighting_model are summarized name this NXdata instance - scalar_field_magn_total. - - If the intensity is reported for each iontype one can avoid many subsequent - computations as individual intensities can be reinterpreted using a different weighting_model in - down-stream usage of the here reported values (e.g. with Python scripting). - In this case name the individual NXdata instances scalar_field_magn_ionID using the ID of the ion as - per the configuration of the ranging definitions used. + The result of the delocalization :math:`\Phi = f(x, y, z)` based on which subsequent iso-surfaces + will be computed. In commercial software so far there is no possibility to export this information. + + If the intensity for all matches of the weighting_model are summarized name this NXdata instance + scalar_field_magn_total. + + If the intensity is reported for each iontype one can avoid many subsequent + computations as individual intensities can be reinterpreted using a different weighting_model in + down-stream usage of the here reported values (e.g. with Python scripting). + In this case name the individual NXdata instances scalar_field_magn_ionID using the ID of the ion as + per the configuration of the ranging definitions used. @@ -358,7 +358,7 @@ The cardinality/total number of triangles in the triangle soup.--> - The actual delocalized intensity values. + The actual delocalized intensity values. @@ -368,7 +368,7 @@ The cardinality/total number of triangles in the triangle soup.--> - Cell center of mass positions along x. + Cell center of mass positions along x. @@ -376,7 +376,7 @@ The cardinality/total number of triangles in the triangle soup.--> - Cell center of mass positions along y. + Cell center of mass positions along y. @@ -384,7 +384,7 @@ The cardinality/total number of triangles in the triangle soup.--> - Cell center of mass positions along z. + Cell center of mass positions along z. @@ -392,7 +392,7 @@ The cardinality/total number of triangles in the triangle soup.--> - Intensity of the field at given point + Intensity of the field at given point @@ -400,8 +400,8 @@ The cardinality/total number of triangles in the triangle soup.--> - Center of mass positions of each voxel for rendering the scalar field - via XDMF in e.g. Paraview. + Center of mass positions of each voxel for rendering the scalar field + via XDMF in e.g. Paraview. @@ -410,18 +410,18 @@ The cardinality/total number of triangles in the triangle soup.--> - XDMF topology for rendering in combination with xdmf_xyz the scalar field - via XDMF in e.g. Paraview. + XDMF topology for rendering in combination with xdmf_xyz the scalar field + via XDMF in e.g. Paraview. - + - The three-dimensional gradient :math:`\nabla \Phi`. - Follow the naming convention of scalar_field_magn_SUFFIX to report parallel structures. + The three-dimensional gradient :math:`\nabla \Phi`. + Follow the naming convention of scalar_field_magn_SUFFIX to report parallel structures. @@ -431,7 +431,7 @@ The cardinality/total number of triangles in the triangle soup.--> - The actual point-wise component values. + The actual point-wise component values. @@ -442,7 +442,7 @@ The cardinality/total number of triangles in the triangle soup.--> - Cell center of mass positions along x. + Cell center of mass positions along x. @@ -450,7 +450,7 @@ The cardinality/total number of triangles in the triangle soup.--> - Cell center of mass positions along y. + Cell center of mass positions along y. @@ -458,7 +458,7 @@ The cardinality/total number of triangles in the triangle soup.--> - Cell center of mass positions along z. + Cell center of mass positions along z. @@ -466,8 +466,8 @@ The cardinality/total number of triangles in the triangle soup.--> - The gradient vector formatted for direct visualization via XDMF in e.g. - Paraview. + The gradient vector formatted for direct visualization via XDMF in e.g. + Paraview. @@ -476,8 +476,8 @@ The cardinality/total number of triangles in the triangle soup.--> - Center of mass positions of each voxel for rendering the scalar field gradient - via XDMF in e.g. Paraview. + Center of mass positions of each voxel for rendering the scalar field gradient + via XDMF in e.g. Paraview. @@ -486,74 +486,62 @@ The cardinality/total number of triangles in the triangle soup.--> - XDMF topology for rendering in combination with xdmf_xyz the scalar field - via XDFM in e.g. Paraview. + XDMF topology for rendering in combination with xdmf_xyz the scalar field + via XDMF in e.g. Paraview. - - + + - An iso-surface is the boundary between two regions across which the magnitude of a - scalar field falls below/exceeds a threshold magnitude :math:`\varphi`. - - For applications in atom probe microscopy, the location and shape of such a boundary (set) - is typically approximated by discretization - triangulation to be specific. - - This yields a complex of not necessarily connected geometric primitives. - Paraprobe-nanochem approximates this complex with a soup of triangles. + An iso-surface is the boundary between two regions across which the magnitude of a + scalar field falls below/exceeds a threshold magnitude :math:`\varphi`. + + For applications in atom probe microscopy, the location and shape of such a boundary (set) + is typically approximated by discretization - triangulation to be specific. + + This yields a complex of not necessarily connected geometric primitives. + Paraprobe-nanochem approximates this complex with a soup of triangles. - The threshold or iso-contour value :math:`\varphi`. + The threshold or iso-contour value :math:`\varphi`. - + - Details about the specific marching cubes algorithm that was used for computing - the iso-surface. + Reference to the specific implementation of marching cubes used. + The value placed here should be a DOI. If there are no specific + DOI or details write not_further_specified, or give at least a + free-text description. The program and version used is the + specific paraprobe-nanochem. - - - Reference to the specific implementation of marching cubes used. - The value placed here should be a DOI. If there are no specific - DOI or details write not_further_specified, or give at least a - free-text description. The program and version used is the - specific paraprobe-nanochem. - - - - + + - The resulting triangle soup computed via marching cubes. + The resulting triangle soup computed via marching cubes. - - - - - Integer which specifies the first index to be used for distinguishing triangles. - Identifiers are defined either implicitly or explicitly. For implicit indexing the - identifiers are defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. - - + + + - - + + - Positions of the vertices. - - Users are encouraged to reduce the vertices to a unique set as this may - result in a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. Naively here means that each - vertex is stored even though many share the same positions. + Positions of the vertices. + + Users are encouraged to reduce the vertices to a unique set as this may + result in a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. Naively here means that each + vertex is stored even though many share the same positions. @@ -562,16 +550,16 @@ The cardinality/total number of triangles in the triangle soup.--> - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. @@ -579,18 +567,18 @@ The cardinality/total number of triangles in the triangle soup.--> - A list of as many tuples of XDMF topology key, XDMF number - of vertices and a triple of vertex indices specifying each - triangle. The total number of entries is n_f_tri * (1+1+3). + A list of as many tuples of XDMF topology key, XDMF number + of vertices and a triple of vertex indices specifying each + triangle. The total number of entries is n_f_tri * (1+1+3). - + - Direction of each normal. + Direction of each normal. @@ -599,24 +587,24 @@ The cardinality/total number of triangles in the triangle soup.--> - Qualifier how which specifically oriented normal to its - primitive each normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner + Qualifier how which specifically oriented normal to its + primitive each normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner - - + + - Direction of each normal. + Direction of each normal. @@ -625,12 +613,12 @@ The cardinality/total number of triangles in the triangle soup.--> - Qualifier how which specifically oriented normal to its - primitive each normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner + Qualifier how which specifically oriented normal to its + primitive each normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner @@ -638,32 +626,32 @@ The cardinality/total number of triangles in the triangle soup.--> - Triangle normals are oriented in the direction of the - gradient vector of the local delocalized scalar field. - :math:`\sum_{x, y, z} {\nabla{c}_i}^2`. + Triangle normals are oriented in the direction of the + gradient vector of the local delocalized scalar field. + :math:`\sum_{x, y, z} {\nabla{c}_i}^2`. +doc: | +Triangle normals are oriented in the direction of the +gradient vector of the local delocalized scalar field. +Sum of squared values of cross product of triangle normal +construction. +unit: NX_ANY +dim: (k,)--> - Triangle normals are oriented in the direction of the - gradient vector of the local delocalized scalar field. - The projection variable here describes the cosine of the - angle between the gradient direction and the normal - direction vector. - This is a descriptor of how parallel the projection is - that is especially useful to document those triangles - for whose the projection is almost perpendicular. + Triangle normals are oriented in the direction of the + gradient vector of the local delocalized scalar field. + The projection variable here describes the cosine of the + angle between the gradient direction and the normal + direction vector. + This is a descriptor of how parallel the projection is + that is especially useful to document those triangles + for whose the projection is almost perpendicular. @@ -677,9 +665,9 @@ The cardinality/total number of triangles in the triangle soup.--> - Array of edge length values. For each triangle the edge length - is reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. + Array of edge length values. For each triangle the edge length + is reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. @@ -688,10 +676,10 @@ The cardinality/total number of triangles in the triangle soup.--> - Array of interior angle values. For each triangle the angle - is reported for the angle opposite to the edges which are - traversed according to the sequence in which vertices - are indexed in triangles. + Array of interior angle values. For each triangle the angle + is reported for the angle opposite to the edges which are + traversed according to the sequence in which vertices + are indexed in triangles. @@ -700,7 +688,7 @@ The cardinality/total number of triangles in the triangle soup.--> - The center of mass of each triangle. + The center of mass of each triangle. @@ -709,36 +697,36 @@ The cardinality/total number of triangles in the triangle soup.--> - Iso-surfaces of arbitrary scalar three-dimensional fields can show a complicated topology. - Paraprobe-nanochem can run a DBScan-like clustering algorithm which performs a - connectivity analysis on the triangle soup representation of such iso-surface. - This may yield a set of connected features whose individual surfaces are discretized - by a triangulated mesh each. Such volumetric features can be processed further using - paraprobe-nanochem using a workflow with at most two steps. - - In the first step, the tool distinguishes three types of (v) i.e. volumetric features: - - 1. So-called objects, i.e. necessarily watertight features represented by polyhedra. - These objects were already watertight within the triangulated iso-surface. - 2. So-called proxies, i.e. features that were not necessarily watertight within the triangulated - iso-surface but were subsequently replaced by a watertight mesh using polyhedral mesh - processing operations (hole filling, refinement, fairing operations). - 3. Remaining triangle surface meshes or parts of these of arbitrary shape and cardinality - that are not transformable into proxies or for which no transformation into proxies was - instructed. - - These features can be interpreted as microstructural features. Some of them may be precipitates, - some of them may be poles, some of them may be segments of dislocation lines or other - crystal defects which are decorated (or not) with solutes. - - In the second step, the tool can be used to analyze the proximity of these objects to a - model of the surface (edge) of the dataset. + Iso-surfaces of arbitrary scalar three-dimensional fields can show a complicated topology. + Paraprobe-nanochem can run a DBScan-like clustering algorithm which performs a + connectivity analysis on the triangle soup representation of such iso-surface. + This may yield a set of connected features whose individual surfaces are discretized + by a triangulated mesh each. Such volumetric features can be processed further using + paraprobe-nanochem using a workflow with at most two steps. + + In the first step, the tool distinguishes three types of (v) i.e. volumetric features: + + 1. So-called objects, i.e. necessarily watertight features represented by polyhedra. + These objects were already watertight within the triangulated iso-surface. + 2. So-called proxies, i.e. features that were not necessarily watertight within the triangulated + iso-surface but were subsequently replaced by a watertight mesh using polyhedral mesh + processing operations (hole filling, refinement, fairing operations). + 3. Remaining triangle surface meshes or parts of these of arbitrary shape and cardinality + that are not transformable into proxies or for which no transformation into proxies was + instructed. + + These features can be interpreted as microstructural features. Some of them may be precipitates, + some of them may be poles, some of them may be segments of dislocation lines or other + crystal defects which are decorated (or not) with solutes. + + In the second step, the tool can be used to analyze the proximity of these objects to a + model of the surface (edge) of the dataset. - + - The identifier which the triangle_soup connectivity analysis - returned, which constitutes the first step of the - volumetric_feature identification process. + The identifier which the triangle_soup connectivity analysis + returned, which constitutes the first step of the + volumetric_feature identification process. @@ -746,7 +734,7 @@ The cardinality/total number of triangles in the triangle soup.--> - The array of keywords of feature_type dictionary. + The array of keywords of feature_type dictionary. @@ -754,8 +742,8 @@ The cardinality/total number of triangles in the triangle soup.--> - The array of values for each keyword of the - feature_type dictionary. + The array of values for each keyword of the + feature_type dictionary. @@ -763,18 +751,18 @@ The cardinality/total number of triangles in the triangle soup.--> - The array of controlled keywords, need to be from - feature_type_dict_keyword, which specify which type - each feature triangle cluster belongs to. - Keep in mind that not each feature is an object or proxy. + The array of controlled keywords, need to be from + feature_type_dict_keyword, which specify which type + each feature triangle cluster belongs to. + Keep in mind that not each feature is an object or proxy. - + - The explicit identifier of features. + The explicit identifier of features. @@ -782,21 +770,21 @@ The cardinality/total number of triangles in the triangle soup.--> - In all situations instances of the parent NXprocess group are returned with a very similar - information structuring and thus we here replace the template name FEATURE - with one of the following types feature-specific group names: - - * objects, objects, irrespective their distance to the surface - * objects_close_to_edge, sub-set of v_feature_object close surface - * objects_far_from_edge, sub-set of v_feature_object not close to the surface - * proxies, proxies, irrespective their distance to the surface - * proxies_close_to_edge, sub-set of v_feature_proxies, close to surface - * proxies_far_from_edge, sub-set of v_feature_proxies, not close to surface + In all situations instances of the parent NXprocess group are returned with a very similar + information structuring and thus we here replace the template name FEATURE + with one of the following types feature-specific group names: + + * objects, objects, irrespective their distance to the surface + * objects_close_to_edge, sub-set of v_feature_object close surface + * objects_far_from_edge, sub-set of v_feature_object not close to the surface + * proxies, proxies, irrespective their distance to the surface + * proxies_close_to_edge, sub-set of v_feature_proxies, close to surface + * proxies_far_from_edge, sub-set of v_feature_proxies, not close to surface - + - Explicit identifier of the feature a sub-set of the feature_identifier in the - parent group. + Explicit identifier of the feature a sub-set of the indices_feature in the + parent group. @@ -804,19 +792,19 @@ The cardinality/total number of triangles in the triangle soup.--> - Volume of the feature. NaN for non-watertight objects. + Volume of the feature. NaN for non-watertight objects. - + - An oriented bounding box (OBB) to each object. + An oriented bounding box (OBB) to each object. - Edge length of the oriented bounding box from largest to smallest value. + Edge length of the oriented bounding box from largest to smallest value. @@ -825,8 +813,8 @@ The cardinality/total number of triangles in the triangle soup.--> - Oriented bounding box aspect ratio. - YX versus ZY or second-largest over largest and smallest over second largest. + Oriented bounding box aspect ratio. + YX versus ZY or second-largest over largest and smallest over second largest. @@ -835,9 +823,9 @@ The cardinality/total number of triangles in the triangle soup.--> - Position of the geometric center, which often is but - not necessarily has to be the center_of_mass of the - hexahedrally-shaped sample/sample part. + Position of the geometric center, which often is but + not necessarily has to be the center_of_mass of the + hexahedrally-shaped sample/sample part. @@ -846,8 +834,8 @@ The cardinality/total number of triangles in the triangle soup.--> - A simple approach to describe the entire set of hexahedra when the main intention - is to store the shape of the hexahedra for visualization. + A simple approach to describe the entire set of hexahedra when the main intention + is to store the shape of the hexahedra for visualization. @@ -855,33 +843,29 @@ The cardinality/total number of triangles in the triangle soup.--> - - + + - + - + - - + @@ -893,20 +877,20 @@ face_identifier_offset(NX_UINT):--> - + - + - + - Array of evaporation_identifier / ion_identifier which details which ions - lie inside or on the surface of the feature. + Array of evaporation_id / identifier_ion which details which ions + lie inside or on the surface of the feature. @@ -917,22 +901,22 @@ face_identifier_offset(NX_UINT):--> - Total (count) of ions inside or on the surface of the feature relevant for normalization. - NaN for non watertight objects. + Total (count) of ions inside or on the surface of the feature relevant for normalization. + NaN for non watertight objects. - + - Count or weight which, when divided by total, yields the composition of this element, - nuclide, or (molecular) ion within the volume of the feature/object. + Count or weight which, when divided by total, yields the composition of this element, + nuclide, or (molecular) ion within the volume of the feature/object. @@ -956,16 +940,16 @@ face_identifier_offset(NX_UINT):--> - The multiplicity whereby the ion position is accounted for - irrespective whether the ion is considered as a decorator - of the interface or not. - As an example, with atom probe it is typically not possible - to resolve the positions of the atoms which arrive at the detector - as molecular ions. Therefore, an exemplar molecular ion of two carbon - atoms can be considered to have a multiplicity of two to account that - this molecular ion contributes two carbon atoms at the reconstructed - location considering that the spatial resolution of atom probe - experiments is limited. + The multiplicity whereby the ion position is accounted for + irrespective whether the ion is considered as a decorator + of the interface or not. + As an example, with atom probe it is typically not possible + to resolve the positions of the atoms which arrive at the detector + as molecular ions. Therefore, an exemplar molecular ion of two carbon + atoms can be considered to have a multiplicity of two to account that + this molecular ion contributes two carbon atoms at the reconstructed + location considering that the spatial resolution of atom probe + experiments is limited. @@ -973,8 +957,8 @@ face_identifier_offset(NX_UINT):--> - The multiplicity whereby the ion position is accounted for when - the ion is considered one which is a decorator of the interface. + The multiplicity whereby the ion position is accounted for when + the ion is considered one which is a decorator of the interface. @@ -982,42 +966,42 @@ face_identifier_offset(NX_UINT):--> - The equation of the plane that is fitted initially. + The equation of the plane that is fitted initially. - The four parameter :math:`ax + by + cz + d = 0` which define the plane. + The four parameter :math:`ax + by + cz + d = 0` which define the plane. - + - The triangle surface mesh representing the interface model. - Exported at state before or after the next DCOM step. + The triangle surface mesh representing the interface model. + Exported at state before or after the next DCOM step. - Was this state exported before or after the next DCOM step. + Was this state exported before or after the next DCOM step. - - - + + + - - - - - - - + + + + + + + @@ -1030,7 +1014,7 @@ face_identifier_offset(NX_UINT):--> - Direction of each vertex normal. + Direction of each vertex normal. @@ -1039,18 +1023,18 @@ face_identifier_offset(NX_UINT):--> - Qualifier which details how specifically oriented the - face normal is with respect to its primitive (triangle): - - * 0 - undefined - * 1 - outer - * 2 - inner + Qualifier which details how specifically oriented the + face normal is with respect to its primitive (triangle): + + * 0 - undefined + * 1 - outer + * 2 - inner - + @@ -1058,7 +1042,7 @@ face_identifier_offset(NX_UINT):--> - Direction of each face normal. + Direction of each face normal. @@ -1067,12 +1051,12 @@ face_identifier_offset(NX_UINT):--> - Qualifier which details how specifically oriented the - face normal is with respect to its primitive (triangle): - - * 0 - undefined - * 1 - outer - * 2 - inner + Qualifier which details how specifically oriented the + face normal is with respect to its primitive (triangle): + + * 0 - undefined + * 1 - outer + * 2 - inner @@ -1091,9 +1075,9 @@ face_identifier_offset(NX_UINT):--> - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. @@ -1102,9 +1086,9 @@ face_identifier_offset(NX_UINT):--> - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. @@ -1120,19 +1104,19 @@ face_identifier_offset(NX_UINT):--> - + - The ROIs are defined as cylinders for the computations. To visualize these we discretize - them into regular n-gons. Using for instance 360-gons, i.e. a regular n-gon with 360 edges, - resolves the lateral surface of each cylinder such that their renditions are smooth in - visualization software like Paraview. + The ROIs are defined as cylinders for the computations. To visualize these we discretize + them into regular n-gons. Using for instance 360-gons, i.e. a regular n-gon with 360 edges, + resolves the lateral surface of each cylinder such that their renditions are smooth in + visualization software like Paraview. - - + + - Position of the geometric center, which often is but not - necessarily has to be the center_of_mass of the polyhedra. + Position of the geometric center, which often is but not + necessarily has to be the center_of_mass of the polyhedra. @@ -1141,8 +1125,8 @@ face_identifier_offset(NX_UINT):--> - The orientation of the ROI defined via a vector which points along - the cylinder axis and whose length is the height of the cylinder. + The orientation of the ROI defined via a vector which points along + the cylinder axis and whose length is the height of the cylinder. @@ -1150,9 +1134,9 @@ face_identifier_offset(NX_UINT):--> - + - XDMF support to enable colouring each ROI by its identifier. + XDMF support to enable coloring each ROI by its identifier. @@ -1160,7 +1144,7 @@ face_identifier_offset(NX_UINT):--> - XDMF support to enable colouring each ROI whether it has edge contact or not. + XDMF support to enable coloring each ROI whether it has edge contact or not. @@ -1168,7 +1152,7 @@ face_identifier_offset(NX_UINT):--> - XDMF support to enable colouring each ROI by its number of atoms. + XDMF support to enable coloring each ROI by its number of atoms. @@ -1176,7 +1160,7 @@ face_identifier_offset(NX_UINT):--> - XDMF support to enable colouring each ROI by its number of ions. + XDMF support to enable coloring each ROI by its number of ions. @@ -1184,22 +1168,22 @@ face_identifier_offset(NX_UINT):--> - Distance and iontype-specific processed data for each ROI. - Arrays signed_distance and nuclide_hash are sorted by increasing - distance. - Array nuclide_hash reports one hash for each atom of each isotope. - Effectively, this can yield to groups of values on signed_distance - with the same distance value as molecular ions are reported decomposed - into their atoms. - Therefore, the XDMF support fields number_of_atoms and number_of_ions - are only expected to display pairwise the same values respectively, - if all ions are built from a single atom only. + Distance and iontype-specific processed data for each ROI. + Arrays signed_distance and nuclide_hash are sorted by increasing + distance. + Array nuclide_hash reports one hash for each atom of each isotope. + Effectively, this can yield to groups of values on signed_distance + with the same distance value as molecular ions are reported decomposed + into their atoms. + Therefore, the XDMF support fields number_of_atoms and number_of_ions + are only expected to display pairwise the same values respectively, + if all ions are built from a single atom only. - + - Sorted in increasing order projected along the positive direction - of the ROI as defined by orientation in the parent group. + Sorted in increasing order projected along the positive direction + of the ROI as defined by orientation in the parent group. @@ -1207,7 +1191,7 @@ face_identifier_offset(NX_UINT):--> - Hashvalue as defined in :ref:`NXion`. + Hashvalue as defined in :ref:`NXatom`. @@ -1219,14 +1203,14 @@ face_identifier_offset(NX_UINT):--> - - + + - + - + @@ -1236,36 +1220,34 @@ face_identifier_offset(NX_UINT):--> - - - + + + - + - If used, metadata of at least the person who performed this analysis. + If used, metadata of at least the person who performed this analysis. - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml index 3282c203db..5e3f50c4d3 100644 --- a/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml @@ -1,9 +1,9 @@ - + - - - + + - + - + - + @@ -72,38 +71,38 @@ - + - + - + - + - + - + - + +dim: (i,)--> @@ -119,117 +118,9 @@ - - - - - - - - - - + diff --git a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml index de5680a967..3b7e7b2a0f 100644 --- a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml @@ -1,9 +1,9 @@ - + - Paraprobe-ranger loads the iontypes and evaluates for each - ion on which iontype it matches. If it matches on None, the - ion is considered of the default *unknown_type*. This iontype - is marked with a 0 in the iontypes array. + Paraprobe-ranger loads the iontypes and evaluates for each + ion on which iontype it matches. If it matches on None, the + ion is considered of the default *unknown_type*. This iontype + is marked with a 0 in the iontypes array. - - + @@ -72,12 +70,12 @@ config--> - The iontype (identifier) for each ion that was best matching, stored - in the order of the evaporation sequence ID. The here computed iontypes - do not take into account the charge state of the ion which is - equivalent to interpreting a RNG and RRNG range files for each - ion in such a way that only the those elements are considered of which - a (molecular) ion is assumed composed according to the NXion instances. + The iontype (identifier) for each ion that was best matching, stored + in the order of the evaporation sequence ID. The here computed iontypes + do not take into account the charge state of the ion which is + equivalent to interpreting a RNG and RRNG range files for each + ion in such a way that only the those elements are considered of which + a (molecular) ion is assumed composed according to the NXatom instances. @@ -86,14 +84,14 @@ config--> - - + + - + - + @@ -103,36 +101,34 @@ config--> - - - + + + - + - If used, metadata of at least the person who performed this analysis. + If used, metadata of at least the person who performed this analysis. - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml index 89484faa9f..d3ffabb4d6 100644 --- a/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml @@ -1,9 +1,9 @@ - + - + - + - + - + - + - + - + @@ -96,7 +95,6 @@ - @@ -109,7 +107,7 @@ - + diff --git a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml index 5630291783..35838e69c3 100644 --- a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml @@ -1,9 +1,9 @@ - + @@ -166,7 +165,7 @@ @@ -182,12 +181,12 @@ identifier(NX_UINT):--> - Specifies, if the iontypes are randomized for the point cloud or not. - Internally, paraprobe uses a sequentially executed deterministic MT19987 - (MersenneTwister) pseudo-random number generator to shuffle the - iontypes randomly across the entire set of ions. That is the total - number of ions of either type remain the same but the information about - their location is randomized. + Specifies, if the iontypes are randomized for the point cloud or not. + Internally, paraprobe uses a sequentially executed deterministic MT19987 + (MersenneTwister) pseudo-random number generator to shuffle the + iontypes randomly across the entire set of ions. That is the total + number of ions of either type remain the same but the information about + their location is randomized. @@ -197,35 +196,35 @@ identifier(NX_UINT):--> - How should the iontype be interpreted on the source-side, i.e. - all these ion positions where a regions-of-interest (ROI) around - so-called source ions will be placed. Different options exist - how iontypes are interpreted given an iontype represents - in general a (molecular) ion with different isotopes that have - individually different multiplicity. - - The value resolve_all will set an ion active in the analysis regardless - of which iontype it is. Each active ion is accounted for once. - - The value resolve_unknown will set an ion active when the ion is - of the UNKNOWNTYPE type. Each active ion is accounted for once. - - The value resolve_ion will set an ion active if it is of the specific - iontype, irregardless of its elemental or isotopic details. - Each active ion is counted once. - - The value resolve_element will set an ion active, and most importantly, - account for each as many times as the (molecular) ion contains - atoms of elements in the whitelist ion_query_isotope_vector. - - The value resolve_isotope will set an ion active, and most importantly, - account for each as many times as the (molecular) ion contains - isotopes in the whitelist ion_query_isotope_vector. - - In effect, ion_query_isotope_vector acts as a whitelist to filter - which ions are considered as source ions of the correlation statistics - and how the multiplicity of each ion will be factorized, i.e. how - often it is accounted for. + How should the iontype be interpreted on the source-side, i.e. + all these ion positions where a regions-of-interest (ROI) around + so-called source ions will be placed. Different options exist + how iontypes are interpreted given an iontype represents + in general a (molecular) ion with different isotopes that have + individually different multiplicity. + + The value resolve_all will set an ion active in the analysis regardless + of which iontype it is. Each active ion is accounted for once. + + The value resolve_unknown will set an ion active when the ion is + of the UNKNOWNTYPE type. Each active ion is accounted for once. + + The value resolve_ion will set an ion active if it is of the specific + iontype, irregardless of its elemental or isotopic details. + Each active ion is counted once. + + The value resolve_element will set an ion active, and most importantly, + account for each as many times as the (molecular) ion contains + atoms of elements in the whitelist ion_query_isotope_vector. + + The value resolve_isotope will set an ion active, and most importantly, + account for each as many times as the (molecular) ion contains + isotopes in the whitelist ion_query_isotope_vector. + + In effect, ion_query_isotope_vector acts as a whitelist to filter + which ions are considered as source ions of the correlation statistics + and how the multiplicity of each ion will be factorized, i.e. how + often it is accounted for. @@ -237,13 +236,13 @@ identifier(NX_UINT):--> - Matrix of isotope vectors, as many as rows as different candidates - for iontypes should be distinguished as possible source iontypes. - In the simplest case, the matrix contains only the proton number - of the element in the row, all other values set to zero. - Combined with ion_query_type_source set to resolve_element this will - recover usual spatial correlation statistics like the 1NN C-C - spatial statistics. + Matrix of isotope vectors, as many as rows as different candidates + for iontypes should be distinguished as possible source iontypes. + In the simplest case, the matrix contains only the proton number + of the element in the row, all other values set to zero. + Combined with ion_query_type_source set to resolve_element this will + recover usual spatial correlation statistics like the 1NN C-C + spatial statistics. @@ -252,14 +251,14 @@ identifier(NX_UINT):--> - Similarly as ion_query_type_source how should iontypes be interpreted - on the target-side, i.e. how many counts will be bookkept for ions - which are neighbors of source ions within or on the surface of each - inspection/ROI about each source ion. - Source ion in the center of the ROI are not accounted for during - counting the summary statistics. - For details about the resolve values consider the explanations in - ion_query_type_source. These account for ion_query_type_target as well. + Similarly as ion_query_type_source how should iontypes be interpreted + on the target-side, i.e. how many counts will be bookkept for ions + which are neighbors of source ions within or on the surface of each + inspection/ROI about each source ion. + Source ion in the center of the ROI are not accounted for during + counting the summary statistics. + For details about the resolve values consider the explanations in + ion_query_type_source. These account for ion_query_type_target as well. @@ -272,9 +271,9 @@ identifier(NX_UINT):--> - Matrix of isotope vectors, as many as rows as different candidates for - iontypes to distinguish as possible targets. See additional comments - under ion_query_isotope_vector_source. + Matrix of isotope vectors, as many as rows as different candidates for + iontypes to distinguish as possible targets. See additional comments + under ion_query_isotope_vector_source. @@ -283,20 +282,20 @@ identifier(NX_UINT):--> - Specifies which spatial statistics to compute. + Specifies which spatial statistics to compute. - Compute k-th nearest neighbour statistics. + Compute k-th nearest neighbour statistics. - Order k. + Order k. - Minimum value, increment, and maximum value of the histogram binning. + Minimum value, increment, and maximum value of the histogram binning. @@ -305,11 +304,11 @@ identifier(NX_UINT):--> - Compute radial distribution function. + Compute radial distribution function. - Minimum value, increment, and maximum value of the histogram binning. + Minimum value, increment, and maximum value of the histogram binning. @@ -322,7 +321,7 @@ identifier(NX_UINT):--> NEW ISSUE: two_point(NXcollection):--> - + diff --git a/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml index 52187c9518..b12422c928 100644 --- a/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml @@ -1,9 +1,9 @@ - + - + @@ -64,13 +64,13 @@ - The iontype ID for each ion that was assigned to each ion during - the randomization of the ionlabels. Iontype labels are just permuted - but the total number of values for each iontype remain the same. - - The order matches the iontypes array from a given ranging results - as it is specified in the configuration settings inside the specific - config_filename that was used for this paraprobe-spatstat analysis. + The iontype ID for each ion that was assigned to each ion during + the randomization of the ionlabels. Iontype labels are just permuted + but the total number of values for each iontype remain the same. + + The order matches the iontypes array from a given ranging results + as it is specified in the configuration settings inside the specific + config_filename that was used for this paraprobe-spatstat analysis. @@ -78,11 +78,11 @@ - K-nearest neighbor statistics. + K-nearest neighbor statistics. - Right boundary of the binning. + Right boundary of the binning. @@ -95,7 +95,7 @@ - Cumulated not normalized by total counts. + Cumulated not normalized by total counts. @@ -103,7 +103,7 @@ - Cumulated and normalized by total counts. + Cumulated and normalized by total counts. @@ -112,11 +112,11 @@ - Radial distribution statistics. + Radial distribution statistics. - Right boundary of the binning. + Right boundary of the binning. @@ -129,7 +129,7 @@ - Cumulated not normalized by total counts. + Cumulated not normalized by total counts. @@ -137,7 +137,7 @@ - Cumulated and normalized by total counts. + Cumulated and normalized by total counts. @@ -147,14 +147,14 @@ - - + + - + - + @@ -164,36 +164,34 @@ - - - + + + - + - If used, metadata of at least the person who performed this analysis. + If used, metadata of at least the person who performed this analysis. - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml index 3cb04dac60..e769564090 100644 --- a/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml @@ -1,9 +1,9 @@ - + - + - + - + - + - + - + - + @@ -121,7 +120,7 @@ Specifies the method that is used to preprocess the point cloud - prior to the alpha-shape computation. + prior to the alpha-shape computation. The option *default* specifies that no such filtering is applied. The option *kuehbach* specifies that a Hoshen-Kopelman @@ -161,10 +160,10 @@ value which the library considers as to be an optimal value. Details are defined in the respective section of the CGAL library on 3D alpha shapes. - + The value *set_of_values* instructs the tool to compute a list collection of alpha-shapes for the specified alpha-values. - + The value *set_of_alpha_wrappings* instructs the tool to generate a set of so-called alpha wrappings. These are similar to alpha-shapes but provide additional guarantees (such as watertightness and @@ -181,7 +180,7 @@ - Array of alpha values to use when alpha_value_choice is + Array of alpha values to use when alpha_value_choice is set_of_values or when alpha_value_choice is set_of_alpha_wrappings. @@ -219,7 +218,7 @@ - + diff --git a/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml index fa2bbd8825..2792a2ab6b 100644 --- a/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml @@ -1,9 +1,9 @@ - + - Paraprobe-surfacer can be used to load a ROI that is the entire or a - sub-set of the ion point cloud. In the point_cloud_wrapping process - the tool computes a triangulated surface mesh which encloses the - ROI/point cloud. This mesh can be seen as a model for the edge of - the dataset. - - Different algorithms can be used with paraprobe-surfacer to create - this mesh such as convex hulls, alpha-shapes as their generalization, - or alpha wrappings. - - Ideally, the resulting mesh should be a watertight polyhedron. - This polyhedron is not necessarily convex. For some algorithms there - is no guarantee that the resulting mesh yields a watertight mesh. + Paraprobe-surfacer can be used to load a ROI that is the entire or a + sub-set of the ion point cloud. In the point_cloud_wrapping process + the tool computes a triangulated surface mesh which encloses the + ROI/point cloud. This mesh can be seen as a model for the edge of + the dataset. + + Different algorithms can be used with paraprobe-surfacer to create + this mesh such as convex hulls, alpha-shapes as their generalization, + or alpha wrappings. + + Ideally, the resulting mesh should be a watertight polyhedron. + This polyhedron is not necessarily convex. For some algorithms there + is no guarantee that the resulting mesh yields a watertight mesh. @@ -91,42 +91,42 @@ - + - A bitmask which identifies exactly all those ions whose positions - were considered when defining the filtered point set from which - that alpha_complex instance was computed. - - This window can be different to the window of the *point_set_wrapping* - parent group because irrelevant ions might have been filtered out in addition - to the window defined in *point_set_wrapping* to reduce e.g. computational - costs of the alpha complex computation. + A bitmask which identifies exactly all those ions whose positions + were considered when defining the filtered point set from which + that alpha_complex instance was computed. + + This window can be different to the window of the *point_set_wrapping* + parent group because irrelevant ions might have been filtered out in addition + to the window defined in *point_set_wrapping* to reduce e.g. computational + costs of the alpha complex computation. - Number of ions covered by the mask. + Number of ions covered by the mask. - Number of bits assumed matching on a default datatype. + Number of bits assumed matching on a default datatype. - The bitfield of the mask. See :ref:`NXcs_filter_boolean_mask` for - how this bitfield is to be interpreted. + The bitfield of the mask. See :ref:`NXcs_filter_boolean_mask` for + how this bitfield is to be interpreted. - + @@ -149,25 +149,25 @@ for eventually performed preprocessing--> - + - The set of triangles in the coordinate system paraprobe - which discretizes the exterior surface of the alpha complex. + The set of triangles in the coordinate system paraprobe + which discretizes the exterior surface of the alpha complex. - + - - - - + + + + - + @@ -175,9 +175,9 @@ for eventually performed preprocessing--> - A list of as many tuples of XDMF topology key, XDMF number - of vertices and a triple of vertex indices specifying each - triangle. The total number of entries is n_f_tri * (1+1+3). + A list of as many tuples of XDMF topology key, XDMF number + of vertices and a triple of vertex indices specifying each + triangle. The total number of entries is n_f_tri * (1+1+3). @@ -185,33 +185,33 @@ for eventually performed preprocessing--> - Do the triangles define a triangulated surface mesh that is watertight? + Do the triangles define a triangulated surface mesh that is watertight? - The volume which the triangulated surface mesh - encloses if that mesh is watertight. + The volume which the triangulated surface mesh + encloses if that mesh is watertight. - + - The set of tetrahedra which represent the interior volume - of the complex if that is a closed two-manifold. + The set of tetrahedra which represent the interior volume + of the complex if that is a closed two-manifold. - + - The accumulated volume of all interior tetrahedra. + The accumulated volume of all interior tetrahedra. - - - - + + + + @@ -220,9 +220,9 @@ for eventually performed preprocessing--> - A list of as many tuples of XDMF topology key, XDMF number - of vertices and a triple of vertex indices specifying each - triangle. The total number of entries is n_f_tet * (1+1+4). + A list of as many tuples of XDMF topology key, XDMF number + of vertices and a triple of vertex indices specifying each + triangle. The total number of entries is n_f_tet * (1+1+4). @@ -236,14 +236,14 @@ for eventually performed preprocessing--> For the future as we may wish to wrap primitives other like triangles or polylines.--> - - + + - + - + @@ -253,36 +253,34 @@ For the future as we may wish to wrap primitives other like triangles or polylin - - - + + + - + - If used, metadata of at least the person who performed this analysis. + If used, metadata of at least the person who performed this analysis. - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml index bf91256517..c576765007 100644 --- a/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml @@ -1,9 +1,9 @@ - + @@ -159,7 +158,7 @@ if windowing_method is bitmasked_points: sum cardinality of NXcg := 0 and cardin minValue: EPSILON--> - + diff --git a/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml index dbfa7dc94c..0dd825c0fa 100644 --- a/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml @@ -1,9 +1,9 @@ - + - The tool can be used to compute a Voronoi tessellation the entire - or of a sub-set of the reconstructed volume. Each point (ion) is wrapped - in one (Voronoi) cell. The point cloud in the ROI is wrapped into an - axis-aligned bounding box (AABB) that is tight. This means points at - the edge of the point cloud can lay on the surface of the bounding box. - The tool detects if cells make contact with the walls of this bounding box. - The tessellation is computed without periodic boundary conditions. + The tool can be used to compute a Voronoi tessellation the entire + or of a sub-set of the reconstructed volume. Each point (ion) is wrapped + in one (Voronoi) cell. The point cloud in the ROI is wrapped into an + axis-aligned bounding box (AABB) that is tight. This means points at + the edge of the point cloud can lay on the surface of the bounding box. + The tool detects if cells make contact with the walls of this bounding box. + The tessellation is computed without periodic boundary conditions. @@ -73,14 +73,14 @@ - + - The (tight) axis-aligned bounding box about the point cloud. + The (tight) axis-aligned bounding box about the point cloud. - Coordinate triplet of the corner that lays closests - to the origin of the *paraprobe* coordinate system. + Coordinate triplet of the corner that lays closest + to the origin of the *paraprobe* coordinate system. @@ -88,92 +88,92 @@ - Coordinate triplet of the corner that lays farthest away - from the origin of the *paraprobe* coordinate system. + Coordinate triplet of the corner that lays farthest away + from the origin of the *paraprobe* coordinate system. - - + + - + - The number of points (and thus cells). + The number of points (and thus cells). - Volume of each Voronoi cell. + Volume of each Voronoi cell. - + - Which MPI process computed which Voronoi cell. + Which MPI process computed which Voronoi cell. - + - Which OpenMP thread computed which Voronoi cell. + Which OpenMP thread computed which Voronoi cell. - + - The number of faces for each cell. Faces of adjoining polyhedra are counted - for each polyhedron. This field can be used to interpret the concatenated vector - with the individual values for the area of each face. + The number of faces for each cell. Faces of adjoining polyhedra are counted + for each polyhedron. This field can be used to interpret the concatenated vector + with the individual values for the area of each face. - + - A simple approach to describe the entire set of polyhedra when the main - intention is to store the shape of the polyhedra for visualization purposes. + A simple approach to describe the entire set of polyhedra when the main + intention is to store the shape of the polyhedra for visualization purposes. - - - - + + + + - Sequence of tuples, concatenated in the order of the Voronoi cells. - Each tuple contains encodes information to visualize using XDMF: - Firstly, an XDMF geometric primitive type key. - Secondly, the number of vertices of the polygon. - Third, the sequence of vertex identifier which define the facet. - Tuples encode faces faster than cells. + Sequence of tuples, concatenated in the order of the Voronoi cells. + Each tuple contains encodes information to visualize using XDMF: + Firstly, an XDMF geometric primitive type key. + Secondly, the number of vertices of the polygon. + Third, the sequence of indices_vertex which define the facet. + Tuples encode faces faster than cells. - + - Sequence of cell identifier, concatenated such that each face is - associated with its cell. Given that paraprobe-tessellator assigns - each cell the evaporation_id of the ion that the cell wraps this - information enables the segmentation of the tessellation and - thus correlate per-ion properties with the volume that each cell - represents. + Sequence of cell identifier, concatenated such that each face is + associated with its cell. Given that paraprobe-tessellator assigns + each cell the evaporation_id of the ion that the cell wraps this + information enables the segmentation of the tessellation and + thus correlate per-ion properties with the volume that each cell + represents. @@ -182,10 +182,10 @@ - A bitmask that documents which of the cells are likely truncated because they - share at least one face with the *aabb* of the point cloud. This field encodes the - result of the boolean or operator applied to the value of all six wall_contact groups - that document contact in specific outer unit normal directions of the *aabb*. + A bitmask that documents which of the cells are likely truncated because they + share at least one face with the *aabb* of the point cloud. This field encodes the + result of the boolean or operator applied to the value of all six wall_contact groups + that document contact in specific outer unit normal directions of the *aabb*. @@ -199,9 +199,9 @@ dim: (i,) # one would not need to constrain this but doing so communicates that all six bitfields have the same length--> - In the spirit of wall_contact_global, the left face of *aabb*. - Its outer unit normal points in the opposite direction of the - x-axis of the *paraprobe* coordinate system. + In the spirit of wall_contact_global, the left face of *aabb*. + Its outer unit normal points in the opposite direction of the + x-axis of the *paraprobe* coordinate system. @@ -213,9 +213,9 @@ dim: (i,) # one would not need to constrain this but doing so communicates that - In the spirit of wall_contact_global, the right face of *aabb*. - Its outer unit normal points in the direction of the x-axis - of the *paraprobe* coordinate system. + In the spirit of wall_contact_global, the right face of *aabb*. + Its outer unit normal points in the direction of the x-axis + of the *paraprobe* coordinate system. @@ -227,9 +227,9 @@ dim: (i,) # one would not need to constrain this but doing so communicates that - In the spirit of wall_contact_global, the front face of *aabb*. - Its outer unit normal points in the opposite direction of the - y-axis of the *paraprobe* coordinate system. + In the spirit of wall_contact_global, the front face of *aabb*. + Its outer unit normal points in the opposite direction of the + y-axis of the *paraprobe* coordinate system. @@ -241,9 +241,9 @@ dim: (i,) # one would not need to constrain this but doing so communicates that - In the spirit of wall_contact_global, the rear face of *aabb*. - Its outer unit normal points in the direction of the y-axis - of the *paraprobe* coordinate system. + In the spirit of wall_contact_global, the rear face of *aabb*. + Its outer unit normal points in the direction of the y-axis + of the *paraprobe* coordinate system. @@ -255,9 +255,9 @@ dim: (i,) # one would not need to constrain this but doing so communicates that - In the spirit of wall_contact_global, the front face of *aabb*. - Its outer unit normal points in the opposite direction of the - z-axis of the *paraprobe* coordinate system. + In the spirit of wall_contact_global, the front face of *aabb*. + Its outer unit normal points in the opposite direction of the + z-axis of the *paraprobe* coordinate system. @@ -269,9 +269,9 @@ dim: (i,) # one would not need to constrain this but doing so communicates that - In the spirit of wall_contact_global, the front face of *aabb*. - Its outer unit normal points in the direction of the z-axis of the - *paraprobe* coordinate system. + In the spirit of wall_contact_global, the front face of *aabb*. + Its outer unit normal points in the direction of the z-axis of the + *paraprobe* coordinate system. @@ -284,14 +284,14 @@ dim: (i,) # one would not need to constrain this but doing so communicates that - - + + - + - + @@ -301,36 +301,34 @@ dim: (i,) # one would not need to constrain this but doing so communicates that - - - + + + - + - If used, metadata of at least the person who performed this analysis. + If used, metadata of at least the person who performed this analysis. - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml index 541a059a7d..7413a376a1 100644 --- a/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml @@ -1,9 +1,9 @@ - + - Base class documenting the information common to tools of the paraprobe-toolbox. - - The paraprobe-toolbox is a collection of open-source tools for performing - efficient analyses of point cloud data where each point can represent atoms or - (molecular) ions. A key application of the toolbox has been for research in the - field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): - - * `paraprobe-toolbox <https://www.gitlab.com/paraprobe/paraprobe-toolbox>`_ - * `M. Kühbach et al. <https://paraprobe-toolbox.readthedocs.io/en/main/>`_ - - The toolbox does not replace but complements existent software tools in this - research field. Given its capabilities of handling points as objects with - properties and enabling analyses of the spatial arrangement of and inter- - sections between geometric primitives, the software can equally be used - for analyzing data in Materials Science and Materials Engineering. - - The common section can be used as a place to store e.g. organizational - metadata and contextualization of that analysis in a research data - management system. + Base class documenting the information common to tools of the paraprobe-toolbox. + + The paraprobe-toolbox is a collection of open-source tools for performing + efficient analyses of point cloud data where each point can represent atoms or + (molecular) ions. A key application of the toolbox has been for research in the + field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): + + * `paraprobe-toolbox <https://www.gitlab.com/paraprobe/paraprobe-toolbox>`_ + * `M. Kühbach et al. <https://paraprobe-toolbox.readthedocs.io/en/main/>`_ + + The toolbox does not replace but complements existent software tools in this + research field. Given its capabilities of handling points as objects with + properties and enabling analyses of the spatial arrangement of and inter- + sections between geometric primitives, the software can equally be used + for analyzing data in Materials Science and Materials Engineering. + + The common section can be used as a place to store e.g. organizational + metadata and contextualization of that analysis in a research data + management system. - A statement whether the tool executable managed to process the analysis - or whether this failed. Status is written to the results file after the - end_time beyond which point in time the tool must no longer compute - any further analysis results but exit. - - Only when this status message is present and its value is `success`, - one should consider the results of the tool. In all other cases it might - be that the tool has terminated prematurely or another error occurred. + A statement whether the tool executable managed to process the analysis + or whether this failed. Status is written to the results file after the + end_time beyond which point in time the tool must no longer compute + any further analysis results but exit. + + Only when this status message is present and its value is `success`, + one should consider the results of the tool. In all other cases it might + be that the tool has terminated prematurely or another error occurred. @@ -60,70 +60,64 @@ - - + - Internal identifier used by the tool to refer to an analysis (aka simulation - id). + Internal identifier used by the tool to refer to an analysis (aka simulation + id). - + - The configuration file that was used to parameterize - the algorithms that this tool has executed. + The configuration file that was used to parameterize + the algorithms that this tool has executed. +doc: | +Path where the tool stores tool-specific results. If not specified, +results will be stored in the current working directory.--> - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis in this results file was started, - i.e. when the respective executable/tool was started as a process. + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis in this results file was started, + i.e. when the respective executable/tool was started as a process. - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis in this results file were - completed and the respective process of the tool exited. + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis in this results file were + completed and the respective process of the tool exited. - Wall-clock time. + Wall-clock time. - + - Details about coordinate systems (reference frames) used. In atom probe several coordinate - systems have to be distinguished. Names of instances of such :ref:`NXcoordinate_system` - should be documented explicitly and doing so by picking from the - following controlled set of names: - - * paraprobe - * lab - * specimen - * laser - * instrument - * detector - * recon - - The aim of this convention is to support users with contextualizing which reference frame - each instance (coordinate system) is. If needed, instances of :ref:`NXtransformations` - are used to detail the explicit affine transformations whereby one can convert - representations between different reference frames. - Inspect :ref:`NXtransformations` for further details. + Details about coordinate systems (reference frames) used. In atom probe several coordinate + systems have to be distinguished. Names of instances of such :ref:`NXcoordinate_system` + should be documented explicitly and doing so by picking from the + following controlled set of names: + + * paraprobe + * lab + * specimen + * laser + * instrument + * detector + * recon + + The aim of this convention is to support users with contextualizing which reference frame + each instance (coordinate system) is. If needed, instances of :ref:`NXtransformations` + are used to detail the explicit affine transformations whereby one can convert + representations between different reference frames. + Inspect :ref:`NXtransformations` for further details. - - - - diff --git a/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml index c2169cc139..88b2cd8b87 100644 --- a/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml @@ -1,9 +1,9 @@ - + - Base class documenting the configuration used for a tool of the paraprobe-toolbox. + Base class documenting the configuration used for a tool of the paraprobe-toolbox. + + The paraprobe-toolbox is a collection of open-source software tools for performing + efficient analyses of point cloud data where each point can represent atoms or + (molecular) ions. A key application of the toolbox has been for research in the + field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): + + * `paraprobe-toolbox <https://www.gitlab.com/paraprobe/paraprobe-toolbox>`_ + * `M. Kühbach et al. <https://paraprobe-toolbox.readthedocs.io/en/main/>`_ + + The toolbox does not replace but complements existent software tools in this + research field. Given its capabilities of handling points as objects with + properties and enabling analyses of the spatial arrangement of and inter- + sections between geometric primitives, the software can equally be used + for analyzing data in Materials Science and Materials Engineering. - The paraprobe-toolbox is a collection of open-source software tools for performing - efficient analyses of point cloud data where each point can represent atoms or - (molecular) ions. A key application of the toolbox has been for research in the - field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): - - * `paraprobe-toolbox <https://www.gitlab.com/paraprobe/paraprobe-toolbox>`_ - * `M. Kühbach et al. <https://paraprobe-toolbox.readthedocs.io/en/main/>`_ - - The toolbox does not replace but complements existent software tools in this - research field. Given its capabilities of handling points as objects with - properties and enabling analyses of the spatial arrangement of and inter- - sections between geometric primitives, the software can equally be used - for analyzing data in Materials Science and Materials Engineering. - - The configuration and results of a run of a tool from the toolbox is documented - using binary container formats. Currently, paraprobe-toolbox uses the - Hierarchical Data Format 5 (HDF5). + The configuration and results of a run of a tool from the toolbox is documented + using binary container formats. Currently, paraprobe-toolbox uses the + Hierarchical Data Format 5 (HDF5). - - + - Internal identifier used by the tool to refer to an analysis (aka simulation - id). + Internal identifier used by the tool to refer to an analysis (aka simulation + id). - Possibility for leaving a free-text description about this analysis. - - Although offered here for convenience we strongly encourage to - parameterize such descriptions as much as possible to support - reusage and clearer communication. + Possibility for leaving a free-text description about this analysis. + + Although offered here for convenience we strongly encourage to + parameterize such descriptions as much as possible to support + reusage and clearer communication. - +base class from which tool-specific application definitions inherit--> + - Specification of the tomographic reconstruction to use for this analysis. - - Typically, reconstructions in the field of atom probe tomography are communicated - via files which store at least reconstructed ion positions and mass-to-charge-state-ratio - values. Container files like HDF5 though can store multiple reconstructions. - Therefore, the position and mass_to_charge concepts point to specific instances - to use for this analysis. + Specification of the tomographic reconstruction to use for this analysis. + + Typically, reconstructions in the field of atom probe tomography are communicated + via files which store at least reconstructed ion positions and mass-to-charge-state-ratio + values. Container files like HDF5 though can store multiple reconstructions. + Therefore, the position and mass_to_charge concepts point to specific instances + to use for this analysis. - Name of the node which resolves the reconstructed ion position - values to use for this analysis. + Name of the node which resolves the reconstructed ion position + values to use for this analysis. - Name of the node which resolves the mass-to-charge-state-ratio - values to use for this analysis. + Name of the node which resolves the mass-to-charge-state-ratio + values to use for this analysis. - + - Specification of the ranging definitions to use for this analysis. - - Ranging is the process of labeling time-of-flight data with so-called iontypes - (aka ion species). Ideally, iontypes specify the most likely (molecular) ion - that is assumed to have been evaporated given that its mass-to-charge-state ratio - lies within the specific mass-to-charge-state-ratio value interval of the iontype. - - The so-called UNKNOWNTYPE iontype represents the null model of an ion - that has not been ranged (for whatever reasons). - The identifier of this special iontype is always the reserved value 0. + Specification of the ranging definitions to use for this analysis. + + Ranging is the process of labeling time-of-flight data with so-called iontypes + (aka ion species). Ideally, iontypes specify the most likely (molecular) ion + that is assumed to have been evaporated given that its mass-to-charge-state ratio + lies within the specific mass-to-charge-state-ratio value interval of the iontype. + + The so-called UNKNOWNTYPE iontype represents the null model of an ion + that has not been ranged (for whatever reasons). + The identifier of this special iontype is always the reserved value 0. - Name of the (parent) node directly below which (in the hierarchy) - the ranging definition for (molecular) ions are stored. + Name of the (parent) node directly below which (in the hierarchy) + the ranging definition for (molecular) ions are stored. - + - Specification of the triangulated surface mesh to use for this analysis. - - Such a surface mesh can be used to define the edge of the reconstructed - volume to account for finite size effects. + Specification of the triangulated surface mesh to use for this analysis. + + Such a surface mesh can be used to define the edge of the reconstructed + volume to account for finite size effects. - +doc: | +Name of the (parent) node directly below which (in the hierarchy) +an instance of :ref:`NXcg_triangle_set` is stored.--> + - Specification of the point-to-triangulated-surface-mesh distances to - use for this analysis. + Specification of the point-to-triangulated-surface-mesh distances to + use for this analysis. - Absolute path in the (HDF5) file that points to the distance values. - The tool assumes that the values are stored in the same order as - points (ions). + Absolute path in the (HDF5) file that points to the distance values. + The tool assumes that the values are stored in the same order as + points (ions). diff --git a/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml index 2ac82f751a..97d18942f8 100644 --- a/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml @@ -1,9 +1,9 @@ - + - Base class documenting the results obtained with a tool of the paraprobe-toolbox. - - The paraprobe-toolbox is a collection of open-source tools for performing - efficient analyses of point cloud data where each point can represent atoms or - (molecular) ions. A key application of the toolbox has been for research in the - field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): - - * `paraprobe-toolbox <https://www.gitlab.com/paraprobe/paraprobe-toolbox>`_ - * `M. Kühbach et al. <https://paraprobe-toolbox.readthedocs.io/en/main/>`_ - - The toolbox does not replace but complements existent software tools in this - research field. Given its capabilities of handling points as objects with - properties and enabling analyses of the spatial arrangement of and inter- - sections between geometric primitives, the software can equally be used - for analyzing data in Materials Science and Materials Engineering. - - The configuration and results of a run of a tool from the toolbox is documented - using binary container formats. Currently, paraprobe-toolbox uses the - Hierarchical Data Format 5 (HDF5). - - The paraprobe coordinate system is the reference *NXcoordinate_system* - for each geometric primitive. + Base class documenting the results obtained with a tool of the paraprobe-toolbox. + + The paraprobe-toolbox is a collection of open-source tools for performing + efficient analyses of point cloud data where each point can represent atoms or + (molecular) ions. A key application of the toolbox has been for research in the + field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): + + * `paraprobe-toolbox <https://www.gitlab.com/paraprobe/paraprobe-toolbox>`_ + * `M. Kühbach et al. <https://paraprobe-toolbox.readthedocs.io/en/main/>`_ + + The toolbox does not replace but complements existent software tools in this + research field. Given its capabilities of handling points as objects with + properties and enabling analyses of the spatial arrangement of and inter- + sections between geometric primitives, the software can equally be used + for analyzing data in Materials Science and Materials Engineering. + + The configuration and results of a run of a tool from the toolbox is documented + using binary container formats. Currently, paraprobe-toolbox uses the + Hierarchical Data Format 5 (HDF5). + + The paraprobe coordinate system is the reference *NXcoordinate_system* + for each geometric primitive. - Possibility for leaving a free-text description about this analysis. + Possibility for leaving a free-text description about this analysis. - A bitmask which identifies all ions considered in the analysis. + A bitmask which identifies all ions considered in the analysis. - Number of ions covered by the mask. - By default, the total number of ions in the dataset. + Number of ions covered by the mask. + By default, the total number of ions in the dataset. - Number of bits assumed matching on a default datatype. + Number of bits assumed matching on a default datatype. - The mask. The length of the mask is an integer multiple of bitdepth. - In such case, padded bits are set to 0. + The mask. The length of the mask is an integer multiple of bitdepth. + In such case, padded bits are set to 0. diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml index 21b882cc6c..fd3654dc43 100644 --- a/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml @@ -1,9 +1,9 @@ - + - +doc: | +The symbols used in the schema to specify e.g. dimensions of arrays.--> - Application definition for a configuration file of the paraprobe-transcoder tool. - - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + Application definition for a configuration file of the paraprobe-transcoder tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. - + @@ -43,22 +41,21 @@ official NeXus appdef headers--> - - - + + - + - + - Specification of the ranging definition file to use for this analysis. + Specification of the ranging definition file to use for this analysis. - + @@ -67,7 +64,7 @@ official NeXus appdef headers--> filter--> - + diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml index 3153d95581..806d27f650 100644 --- a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml @@ -1,9 +1,9 @@ - + +i be careful n_comb can vary for every instance of (NXatom) !--> - The symbols used in the schema to specify e.g. dimensions of arrays. + The symbols used in the schema to specify e.g. dimensions of arrays. - The total number of ions in the reconstruction. + The total number of ions in the reconstruction. - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. - Total number of integers in the supplementary XDMF topology array. + Total number of integers in the supplementary XDMF topology array. - Number of entries + Number of entries - Application definition for results files of the paraprobe-transcoder tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. - The purpose and need of the paraprobe-transcoder tool is to create a standardized representation - of reconstructed position and mass-to-charge-state-ratio values surplus other pieces of information - to enable working with atom probe data in reconstruction space in the paraprobe-toolbox. - This includes ranging definitions which map mass-to-charge-state ratio values onto iontypes. - - So far the atom probe community has not yet agreed upon a comprehensive standardization on how to - exchange information especially when it comes to the communication of configurations and results - from analyses of atom probe data. Instead, different simplistic file formats are used, such as POS, ePOS, - APT, or RNG and RRNG. None of these formats, though, are self-descriptive, standardize, or document - their origin and thus the sequence in which the file was generated during an analysis. - - Paraprobe-transcoder solves this limitation by interpreting the information content in such files - and standardize the representation prior injection into the scientific data analysis tools of the toolbox. - Therefore, the here proposed set of NeXus base classes and application definitions can be a useful - starting point for the atom probe community to take advantage of standardized information - exchange and improve the here proposed classes and concepts to become more inclusive. - - Paraprobe-transcoder uses a Python library developed based on efforts by members of the - global atom probe community `International Field Emission Society (IFES) Atom Probe Technical Committee (APT TC) <https://www.github.com/atomprobe-tc/ifes_apt_tc_data_modeling>`_. This library offers the - actual low-level I/O operations and respective information interpretation of above-mentioned file formats. + Application definition for results files of the paraprobe-transcoder tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + The purpose and need of the paraprobe-transcoder tool is to create a standardized representation + of reconstructed position and mass-to-charge-state-ratio values surplus other pieces of information + to enable working with atom probe data in reconstruction space in the paraprobe-toolbox. + This includes ranging definitions which map mass-to-charge-state ratio values onto iontypes. + + So far the atom probe community has not yet agreed upon a comprehensive standardization on how to + exchange information especially when it comes to the communication of configurations and results + from analyses of atom probe data. Instead, different simplistic file formats are used, such as POS, ePOS, + APT, or RNG and RRNG. None of these formats, though, are self-descriptive, standardize, or document + their origin and thus the sequence in which the file was generated during an analysis. + + Paraprobe-transcoder solves this limitation by interpreting the information content in such files + and standardize the representation prior injection into the scientific data analysis tools of the toolbox. + Therefore, the here proposed set of NeXus base classes and application definitions can be a useful + starting point for the atom probe community to take advantage of standardized information + exchange and improve the here proposed classes and concepts to become more inclusive. + + Paraprobe-transcoder uses a Python library developed based on efforts by members of the + global atom probe community `International Field Emission Society (IFES) Atom Probe Technical Committee (APT TC) <https://www.github.com/atomprobe-tc/ifes_apt_tc_data_modeling>`_. This library offers the + actual low-level I/O operations and respective information interpretation of above-mentioned file formats. @@ -86,18 +86,18 @@ i be careful n_comb can vary for every instance of (NXion) !--> - - + + - + - By default the entire reconstructed volume is processed. - In this case, using window is also equivalent to an - NXspatial_filter that specified a window *entire_dataset*. + By default the entire reconstructed volume is processed. + In this case, using window is also equivalent to an + NXspatial_filter that specified a window *entire_dataset*. @@ -107,7 +107,7 @@ config--> - Mass-to-charge-state-ratio values. + Mass-to-charge-state-ratio values. @@ -117,8 +117,8 @@ config--> - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. @@ -126,17 +126,17 @@ config--> - Defines in which reference frame the positions are defined. + Defines in which reference frame the positions are defined. - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstruction. The XDMF datatype - is here 1, the number of primitives 1 per triplet, the last integer - in each triplet is the identifier of each point starting from zero. + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstruction. The XDMF datatype + is here 1, the number of primitives 1 per triplet, the last integer + in each triplet is the identifier of each point starting from zero. @@ -147,9 +147,9 @@ config--> - Details about how peaks are interpreted as ion types or not. + Details about how peaks are interpreted as ion types or not. - + @@ -166,14 +166,14 @@ config--> - - + + - + - + @@ -183,36 +183,34 @@ config--> - - - + + + - + - If used, metadata of at least the person who performed this analysis. + If used, metadata of at least the person who performed this analysis. - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + From 387320513bdada005cec4ff29c2ac6203edbc827 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 28 Aug 2025 11:36:23 +0200 Subject: [PATCH 0996/1012] bring in NXapm_compositonspace* classes from fairmat --- .../NXapm_composition_space_results.nxdl.xml | 488 ------------------ .../NXapm_compositionspace_config.nxdl.xml | 243 ++++----- .../NXapm_compositionspace_results.nxdl.xml | 260 +++++----- .../NXapm_input_ranging.nxdl.xml | 63 --- .../NXapm_input_reconstruction.nxdl.xml | 58 --- 5 files changed, 270 insertions(+), 842 deletions(-) delete mode 100644 contributed_definitions/NXapm_composition_space_results.nxdl.xml delete mode 100644 contributed_definitions/NXapm_input_ranging.nxdl.xml delete mode 100644 contributed_definitions/NXapm_input_reconstruction.nxdl.xml diff --git a/contributed_definitions/NXapm_composition_space_results.nxdl.xml b/contributed_definitions/NXapm_composition_space_results.nxdl.xml deleted file mode 100644 index 15c107dc48..0000000000 --- a/contributed_definitions/NXapm_composition_space_results.nxdl.xml +++ /dev/null @@ -1,488 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of voxel of discretized domain for analyzed part of the dataset. - - - - - The dimensionality of the grid. - - - - - The cardinality or total number of cells/grid points. - - - - - Number of terms in the composition clustering dictionary - - - - - Number of terms in the position clustering dictionary - - - - - Results of a run with Alaukik Saxena's composition space tool. - - This is an initial draft application definition for the common NFDI-MatWerk, - FAIRmat infrastructure use case IUC09 how to improve the organization and - results storage of the composition space tool and make these data at the same - time directly understandable for NOMAD. - - This draft does no contain yet the annotations for how to also store - in the HDF5 file a default visualization whereby the composition grid - could directly be explored using H5Web. I am happy to add this ones the - data have been mapped on this schema, i.e. more discussion needed. - - Also iso-surfaces can be described, for paraprobe, this is a solved problem, - check the respective group in the NXapm_paraprobe_results_nanochem data - schema/application definition. - - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - - - - - - TBD, maybe how to link between pyiron state tracking and app state tracking - - - - - Disencouraged place for free-text for e.g. comments. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. when composition space tool was started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and composition space tool exited as a process. - - - - - The path and name of the config file for this analysis. - TBD, this can be e.g. Alaukik's YAML file for composition space. - - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - - The path and name of the file (technology partner or community format) - from which reconstructed ion positions were loaded. - - - - - - - - The path and name of the file (technology partner or community format - from which ranging definitions, i.e. how to map mass-to- - charge-state ratios on iontypes were loaded. - - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the executable managed to process the analysis - or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - - - - The individual coordinate systems which should be used. - Some suggestions follow, e.g. that field names should be prefixed - with the following controlled terms indicating which individual - coordinate system is described: - - * world - * composition_space - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - - - - - Position of each cell in Euclidean space. - - - - - - - - - - - - - - - - For each ion, the identifier of the voxel in which the ion is located. - - - - - - - - - - - - - - - - - - In Alaukik's tool the GMM step. - - - - - - - - - The keywords of the dictionary of distinguished compositionally- - defined cluster, e.g. the phases. Examples for keywords could be - phase1, phase2, and so one and so forth. - - - - - - - - Resolves for each keyword in cluster_dict which integer is used to - label something that it belongs or is assumed to represent this - cluster. - - - - - - - - - For example if the voxel grid is used to report that there - are voxels which are assumed to represent volume of either phase1 - or phase2, the cluster_dict_keyword would be a list with two names - phase1 and phase2, respectively. The cluster_dict_value would be a - list of e.g. integers 1 and 2. These could be used to build an - array with as many entries as there are voxel and store in this array - the respective value to encode which phase is assumed for each voxel. - - - - - - - - - - In Alaukik's tool the DBScan step after the GMM step. - - - - - - - - - The keywords of the dictionary of distinguished spatially-contiguous - clusters. Examples for keywords could be precipitate1, precipitate2, - and so one and so forth. - - - - - - - - Resolves for each keyword in cluster_dict which integer is used to - label something that it belongs or is assumed to represent this - cluster. - - - - - - - - - For example if the voxel grid is used to report that there - are voxels which are assumed to represent volume of certain precipitates, - say we found ten precipitates and consider the rest as matrix. - We could make a list of say matrix, precipitate1, precipitate2, ..., - precipitate10. With cluster_dict_value then running from 0 to 10, - i.e. matrix is flagged special as 0 and the remaining particles - are indexed conveniently as 1, 2, ..., 10 like end users expect. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/NXapm_compositionspace_config.nxdl.xml b/contributed_definitions/NXapm_compositionspace_config.nxdl.xml index 923e1a1373..dd02255eb9 100644 --- a/contributed_definitions/NXapm_compositionspace_config.nxdl.xml +++ b/contributed_definitions/NXapm_compositionspace_config.nxdl.xml @@ -1,9 +1,9 @@ - + - Application definition for a configuration of the CompositionSpace tool used in atom probe. - - * `A. Saxena et al. <https://www.github.com/eisenforschung/CompositionSpace.git>`_ - - This is an application definition for the common NFDI-MatWerk/FAIRmat infrastructure - use case IUC09 that explores how to improve the organization and results storage of the - CompositionSpace software using NeXus. + Application definition for a configuration of the CompositionSpace tool used in atom probe. + + * `A. Saxena et al. <https://www.github.com/eisenforschung/CompositionSpace.git>`_ + + This is an application definition for the common NFDI-MatWerk/FAIRmat infrastructure + use case IUC09 that explores how to improve the organization and results storage of the + CompositionSpace tool by using the NeXus data model and semantics. - @@ -39,153 +38,161 @@ - - - - + + + + Specification of the tomographic reconstruction used for this analysis. + Typically, reconstructions in the field of atom probe tomography are communicated via + files which store at least reconstructed ion positions and mass-to-charge-state-ratio + values. Container files like HDF5 though can store multiple reconstructions. + Therefore, the position and mass_to_charge concepts point to specific instances + to use for this analysis. + + + + + + - Specification of the tomographic reconstruction used for this analysis. - Typically, reconstructions in the field of atom probe tomography are communicated via - files which store at least reconstructed ion positions and mass-to-charge-state-ratio - values. Container files like HDF5 though can store multiple reconstructions. - Therefore, the position and mass_to_charge concepts point to specific instances - to use for this analysis. + Name of the node which resolves the reconstructed + ion position values to use for this analysis. - - - - - - - Name of the node which resolves the reconstructed - ion position values to use for this analysis. - - - - - Name of the node which resolves the mass-to-charge-state ratio - values for each reconstructed ion to use for this analysis. - - - - + + - Specification of the ranging definitions used for this analysis. - - Indices start from 1. The value 0 is reserved for the null model of unranged positions whose - iontype is unknown_type. The value 0 is also reserved for voxels that lie outside the dataset. + Name of the node which resolves the mass-to-charge-state ratio + values for each reconstructed ion to use for this analysis. - - - - - - - Name of the (parent) node directly below which the ranging definitions for - (molecular) ions are stored. - - - - + + + + + Specification of the ranging definitions used for this analysis. + + Indices start from 1. The value 0 is reserved for the null model of unranged positions whose + iontype is unknown_type. The value 0 is also reserved for voxels that lie outside the dataset. + + + + + + - Step during which the point cloud is discretized to compute element-specific composition fields. - Iontypes are atomically decomposed to correctly account for the multiplicity of each element that - was ranged for each ion. + Name of the (parent) node directly below which the ranging definitions for + (molecular) ions are stored. - - - Edge length of cubic voxels building the 3D grid that is used for discretizing - the point cloud. - - - + + + + + Step during which the point cloud is discretized to compute element-specific composition fields. + Iontypes are atomically decomposed to correctly account for the multiplicity of each element that + was ranged for each ion. + + + + Edge length of cubic voxels building the 3D grid that is used for discretizing + the point cloud. + + - Optional step during which the subsequent segmentation step is prepared with the aim to eventually - reduce the dimensionality of the chemical space in which the machine learning model works. - - In this step a supervised reduction of the dimensionality of the chemical space is quantified using - the (Gini) feature importance of each element to suggest which columns of the composition matrix - should be taken for the subsequent segmentation step. + Optional step during which the subsequent segmentation step is prepared with the aim to eventually + reduce the dimensionality of the chemical space in which the machine learning model works. + + In this step a supervised reduction of the dimensionality of the chemical space is quantified using + the (Gini) feature importance of each element to suggest which columns of the composition matrix + should be taken for the subsequent segmentation step. - Was the automated phase assignment used? + Was the automated phase assignment used? - Estimated guess for which a Gaussian mixture model is evaluted to preprocess a result that - is subsequenty post-processed with a random_forest_classifier to lower the number of - dimensions in the chemical space to the subset of trunc_species many elements with the - highest feature importance. + Estimated guess for which a Gaussian mixture model is evaluated to preprocess a result that + is subsequently post-processed with a random_forest_classifier to lower the number of + dimensions in the chemical space to the subset of trunc_species many elements with the + highest feature importance. - The number of elements to use for reducing the dimensionality. + The number of elements to use for reducing the dimensionality. - Configuration for the random forest classification model. + Configuration for the random forest classification model. - + + + + Step during which the voxel set is segmented into voxel sets with different + chemical composition. + + + + A principal component analysis of the chemical space to guide a decision into how many sets of voxels + with different chemical composition the machine learning algorithm suggests to split the voxel set. + + + - Step during which the voxel set is segmented into voxel sets with different - chemical composition. + The decision is guided through the evaluation of the information criterion + minimization. - + - A principal component analysis of the chemical space to guide a decision into how many sets of voxels - with different chemical composition the machine learning algorithm suggests to split the voxel set. + The maximum number of chemical classes to probe with the Gaussian mixture model + with which the voxel set is segmented into a mixture of voxels with that many different + chemical compositions. - - + + - The decision is guided through the evalution of the information criterion - minimization. + Configuration for the Gaussian mixture model that is used in the segmentation + step. - - - The maximum number of chemical classes to probe with the Gaussian mixture model - with which the voxel set is segmented into a mixture of voxels with that many different - chemical compositions. - - - - - Configuration for the Gaussian mixture model that is used in the segmentation - step. - - - + + + + Step during which the chemically segmented voxel sets are analyzed for their + spatial organization. + + - Step during which the chemically segmented voxel sets are analyzed for their - spatial organization. + Configuration for the DBScan algorithm that is used in the clustering step. - + - Configuration for the DBScan algorithm that is used in the clustering step. + The maximum distance between voxel pairs in a neighborhood to be considered + connected. - - - The maximum distance between voxel pairs in a neighborhood to be considered - connected. - - - - - The number of voxels in a neighborhood for a voxel to be considered as a core - point. - - - + + + + The number of voxels in a neighborhood for a voxel to be considered as a core + point. + + + diff --git a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml index 7bf1c7912e..e1bcb394f8 100644 --- a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml +++ b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml @@ -1,9 +1,9 @@ - + @@ -59,37 +58,77 @@ - - + + + + + + + + - - - + + + Programs and libraries representing the computational environment + + + + + + + - + - Configuration file that was used in this analysis. + Configuration file that was used in this analysis. - + + + + Contextualize back to the specimen from which the + dataset was collected that was here analyzed with + CompositionSpace tool. + + + + True, if the specimen that the reconstructed dataset + describes is a simulated one. + False, if the specimen that the reconstructed dataset + describes is a real one. + + + + + List of comma-separated elements from the periodic table that are + contained in the specimen. If the specimen substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer research data management systems an + opportunity to parse the relevant elements without having to interpret + these from the resources pointed to by identifier_parent or walk through + eventually deeply nested groups in data instances. + + + - Step during which the point cloud is discretized to compute element-specific composition fields. - Iontypes are atomically decomposed to correctly account for the multiplicity of each element that - was ranged for each ion. - - Using a discretization grid that is larger than the average distance between reconstructed ion positions - reduces computational costs. This is the key idea of the CompositionSpace tool compared to other methods - used in atom probe for characterizing microstructural features using the ion position data directly. + Step during which the point cloud is discretized to compute element-specific composition fields. + Iontypes are atomically decomposed to correctly account for the multiplicity of each element that + was ranged for each ion. + + Using a discretization grid that is larger than the average distance between reconstructed ion positions + reduces computational costs. This is the key idea of the CompositionSpace tool compared to other methods + used in atom probe for characterizing microstructural features that use the ion position data directly. @@ -97,14 +136,14 @@ for if desired all the dependencies and libraries--> - + - - - + + + @@ -113,66 +152,66 @@ for if desired all the dependencies and libraries--> - - + + - - + + - + - Position of each cell in Euclidean space. + Position of each cell in Euclidean space. - + - Discrete coordinate of each voxel. + Discrete coordinate of each voxel. - + - + - For each ion, the identifier of the voxel into which the ion binned. + For each ion, the identifier of the voxel into which the ion binned. - + - Total number of weight (counts for discretization with a rectangular transfer function) - for the occupancy of each voxel with atoms. + Total number of weight (counts for discretization with a rectangular transfer function) + for the occupancy of each voxel with atoms. - + - + - Chemical symbol of the element from the periodic table. + Chemical symbol of the element from the periodic table. - Element-specific weight (counts for discretization with a rectangular transfer function) - for the occupancy of each voxel with atoms of this element. + Element-specific weight (counts for discretization with a rectangular transfer function) + for the occupancy of each voxel with atoms of this element. - + @@ -180,8 +219,8 @@ for if desired all the dependencies and libraries--> - Optional step during which the subsequent segmentation step is prepared to - improve the segmentation. + Optional step during which the subsequent segmentation step is prepared to + improve the segmentation. @@ -191,32 +230,32 @@ for if desired all the dependencies and libraries--> - + - + - Element identifier stored sorted in descending order of feature importance. + Element identifier stored sorted in descending order of feature importance. - + - Axis caption + Axis caption - Element relative feature importance stored sorted in descending order of feature - importance. + Element relative feature importance stored sorted in descending order of feature + importance. - + - Axis caption + Axis caption @@ -224,12 +263,12 @@ for if desired all the dependencies and libraries--> - Step during which the voxel set is segmented into voxel sets with different - chemical composition. + Step during which the voxel set is segmented into voxel sets with different + chemical composition. - PCA in the chemical space (essentially composition correlation analyses). + PCA in the chemical space (essentially composition correlation analyses). @@ -240,22 +279,22 @@ for if desired all the dependencies and libraries--> - + - Explained variance values + Explained variance values - + - Elements identifier matching those from ENTRY/voxelization/elementID as the - principal component analysis. + Elements identifier matching those from ENTRY/voxelization/ION + as the principal component analysis. - + @@ -263,7 +302,7 @@ for if desired all the dependencies and libraries--> - Information criterion minimization. + Information criterion minimization. @@ -271,53 +310,53 @@ for if desired all the dependencies and libraries--> - + - Results of the Gaussian mixture analysis for n_components equal to n_ic_cluster. + Results of the Gaussian mixture analysis for n_components equal to n_ic_cluster. - n_components argument of the Gaussian mixture model. + n_components argument of the Gaussian mixture model. - y_pred return values of the computation. + y_pred return values of the computation. - + - Information criterion as a function of number of n_ic_cluster aka dimensions. + Information criterion as a function of number of n_ic_cluster aka dimensions. - + - Akaike information criterion values + Akaike information criterion values - + - Bayes information criterion values + Bayes information criterion values - + - Actual n_ic_cluster values used + Actual n_ic_cluster values used - + @@ -326,9 +365,9 @@ for if desired all the dependencies and libraries--> - Step during which the chemically segmented voxel sets are analyzed for their spatial organization - into different spatial clusters of voxels in the same chemical set but representing individual object - not-necessarily watertight or topologically closed objects built from individual voxels. + Step during which the chemically segmented voxel sets are analyzed for their spatial organization + into different spatial clusters of voxels in the same chemical set but representing individual object + not-necessarily watertight or topologically closed objects built from individual voxels. @@ -336,40 +375,40 @@ for if desired all the dependencies and libraries--> - + - Respective DBScan clustering result for each segmentation/ic_opt case. + Respective DBScan clustering result for each segmentation/ic_opt case. - - + + - The maximum distance between voxel pairs in a neighborhood to be considered - connected. + The maximum distance between voxel pairs in a neighborhood + to be considered connected. - The number of voxels in a neighborhood for a voxel to be considered as a core - point. + The number of voxels in a neighborhood for a voxel to be considered as a core + point. - Raw label return values + Raw label return values - + - Voxel identifier - - Using these identifiers correlated element-wise with the values in the label array - specifies for which voxel in the grid clusters from this process were found. + Voxel identifier + + Using these identifiers correlated element-wise with the values in the label array + specifies for which voxel in the grid clusters from this process were found. - + @@ -377,14 +416,5 @@ for if desired all the dependencies and libraries--> - - - - - - - diff --git a/contributed_definitions/NXapm_input_ranging.nxdl.xml b/contributed_definitions/NXapm_input_ranging.nxdl.xml deleted file mode 100644 index b82a78e70d..0000000000 --- a/contributed_definitions/NXapm_input_ranging.nxdl.xml +++ /dev/null @@ -1,63 +0,0 @@ - - - - - - - Metadata to ranging definitions made for a dataset in atom probe microscopy. - - Ranging is the process of labeling time-of-flight data with so-called iontypes - which ideally specify the most likely ion/molecular ion evaporated within a - given mass-to-charge-state-ratio value interval. - - The paraprobe-toolbox uses the convention that the so-called UNKNOWNTYPE - iontype (or unranged ions) represents the default iontype. - The ID of this special iontype is always reserved as 0. Each ion - is assigned to the UNKNOWNTYPE by default. Iontypes are assigned - by checking if the mass-to-charge-state-ratio values of an ion matches - to any of the defined mass-to-charge-state-ratio intervals. - - - - Path and name of the NeXus/HDF5 file which stores ranging definitions. - - - - Version identifier of the file (representing an at least SHA256 strong) - hash. Such hashes serve reproducibility as they can be used for tracking - provenance metadata in a workflow. - - - - - - Name of the group (prefix to the individual ranging definitions) inside - the file referred to by filename which points to the specific ranging - definition to use. - An HDF5 file can store multiple ranging definitions. Using an ID is - the mechanism to distinguish which specific ranging (version) will - be processed. Reconstruction and ranging IDs can differ. - They specify different IDs. - - - diff --git a/contributed_definitions/NXapm_input_reconstruction.nxdl.xml b/contributed_definitions/NXapm_input_reconstruction.nxdl.xml deleted file mode 100644 index 8ed7b90021..0000000000 --- a/contributed_definitions/NXapm_input_reconstruction.nxdl.xml +++ /dev/null @@ -1,58 +0,0 @@ - - - - - - - Metadata of a dataset (tomographic reconstruction) in atom probe microscopy. - - - - Name of the (NeXus)/HDF5 file which stores reconstructed ion position - and mass-to-charge-state ratios. Such an HDF5 file can store multiple - reconstructions. Using the information within the dataset_name fields - is the mechanism whereby paraprobe decides which reconstruction to - process. With this design it is possible that the same HDF5 - file can store multiple versions of a reconstruction. - - - - Version identifier of the file (representing an at least SHA256 strong) - hash. Such hashes serve reproducibility as they can be used for tracking - provenance metadata in a workflow. - - - - - - Name of the dataset inside the HDF5 file which refers to the - specific reconstructed ion positions to use for this analysis. - - - - - Name of the dataset inside the HDF5 file which refers to the - specific mass-to-charge-state-ratio values to use for this analysis. - - - From 845c8747c9a461576027d5b1685a6b4604b01151 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 28 Aug 2025 11:42:56 +0200 Subject: [PATCH 0997/1012] remove NXamplifier (part of SPM proposal) --- contributed_definitions/NXamplifier.nxdl.xml | 91 -------------------- 1 file changed, 91 deletions(-) delete mode 100644 contributed_definitions/NXamplifier.nxdl.xml diff --git a/contributed_definitions/NXamplifier.nxdl.xml b/contributed_definitions/NXamplifier.nxdl.xml deleted file mode 100644 index c9b719a7b1..0000000000 --- a/contributed_definitions/NXamplifier.nxdl.xml +++ /dev/null @@ -1,91 +0,0 @@ - - - - - - Base classed definition for amplifier devices. - - - - (IC, device) (NXmanufacturer?) - - - - - The number of preamplifier channels are assgined. - - - - - The number of preamplifier channels are ready tp to be used. (array for active - channels) - - - - - The output signal does not go through a feedback loop to adjust the - amplification of the amplifier. (array for active channels) - - - - - - The ratio of the amplitue of the useful signal to the amplitude of the noise in - the output signal of the amplifier. S/N=V_signal/V_noise. (array for active - channels) - - - - - (if active >1) - - - - - for reducing interferences between different signalling pathways - - - - - The spectrum of frequency it can amplify, from its lowest to highest frequency - limits. - - - - - Order and cut-off frequency of the low-pass filter applied on the demodulated - signals (X,Y). Cut-off frq (low pass filter) (foreach DemodulatorChannels) - - - - - Order and cut-off frequency of the high-pass filter applied on the demodulation - signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) - - - - From e56c583753ae04bcad0eb8c4d6e519078f2c924e Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 28 Aug 2025 12:01:26 +0200 Subject: [PATCH 0998/1012] fix various issues with the documentation build --- .../NXdelocalization.nxdl.xml | 10 +++---- .../NXspatial_filter.nxdl.xml | 10 +++---- .../NXtransmission.nxdl.xml | 30 +++++++++---------- .../ellipsometry-structure.rst | 4 +-- 4 files changed, 27 insertions(+), 27 deletions(-) diff --git a/contributed_definitions/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index 0d20da474e..96238c7342 100644 --- a/contributed_definitions/NXdelocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -87,13 +87,13 @@ and the interpretation model that to consider carbon atoms or carbon ions--> Different methods are used for weighting ions: * default, points get all the same weight 1., which for atom probe is equivalent - to (molecular) iontype-based delocalization. + to (molecular) iontype-based delocalization. * element, points get as much weight as they have atoms representing a nuclide - with a proton number that is matching to a respective entry in whitelist. - In atom probe jargon, this means atomic_decomposition. + with a proton number that is matching to a respective entry in whitelist. + In atom probe jargon, this means atomic_decomposition. * isotope, points get as much weight as they have atoms representing a nuclides - from a respective entry in whitelist. - In atom probe jargon, this means isotope_decomposition. + from a respective entry in whitelist. + In atom probe jargon, this means isotope_decomposition. diff --git a/contributed_definitions/NXspatial_filter.nxdl.xml b/contributed_definitions/NXspatial_filter.nxdl.xml index 32f9f8a8f5..0460ad9efd 100644 --- a/contributed_definitions/NXspatial_filter.nxdl.xml +++ b/contributed_definitions/NXspatial_filter.nxdl.xml @@ -62,12 +62,12 @@ n_facets: Number of facets for polyhedra.--> * entire_dataset, no filter is applied, all objects are included. * union_of_primitives, a filter with (possibly non-axis-aligned) geometric - primitives. Objects in or on the surface of the primitives are included. - All other objects are excluded. + primitives. Objects in or on the surface of the primitives are included. + All other objects are excluded. * bitmask, a boolean array whose bits encode with 1 which objects - are included. Bits set to zero encode which objects are excluded. - Users of python can use the bitfield operations - of the numpy package to work with bitfields. + are included. Bits set to zero encode which objects are excluded. + Users of python can use the bitfield operations + of the numpy package to work with bitfields. - Version number to identify which definition of this application definition was - used for this entry/data. + Version number to identify which definition of this application definition was + used for this entry/data. - URL where to find further material (documentation, examples) relevant to the - application definition. + URL where to find further material (documentation, examples) relevant to the + application definition. @@ -66,16 +66,16 @@ Draft NeXus application definition for transmission experiments--> Start time of the experiment. - + Unique identifier of the experiment, such as a (globally persistent) unique identifier. * The identifier is usually defined by the facility or principle - investigator. + investigator. * The identifier enables to link experiments to e.g. proposals. - + An optional free-text description of the experiment. However, details of the @@ -90,12 +90,12 @@ Draft NeXus application definition for transmission experiments--> used to generate the result file(s) with measured data and metadata. - + Version number of the program that was used to generate the result file(s) with measured data and metadata. - + Website of the software @@ -178,12 +178,12 @@ Draft NeXus application definition for transmission experiments--> - Diffraction grating, as could be used in a monochromator. - If two or more gratings were used, define the angular - dispersion and the wavelength range (min/max wavelength) - for each grating and make sure that the wavelength ranges - do not overlap. The dispersion should be defined for the - entire wavelength range of the experiment. + Diffraction grating, as could be used in a monochromator. + If two or more gratings were used, define the angular + dispersion and the wavelength range (min/max wavelength) + for each grating and make sure that the wavelength ranges + do not overlap. The dispersion should be defined for the + entire wavelength range of the experiment. diff --git a/manual/source/classes/contributed_definitions/ellipsometry-structure.rst b/manual/source/classes/contributed_definitions/ellipsometry-structure.rst index 134e245698..285e33775e 100644 --- a/manual/source/classes/contributed_definitions/ellipsometry-structure.rst +++ b/manual/source/classes/contributed_definitions/ellipsometry-structure.rst @@ -43,13 +43,13 @@ This is the set of base classes for describing an optical experiment. splitter. In the dependency chain of the new beam paths, the first elements each point to this beam splitter, as this is the previous element. - :ref:`NXfiber` + :ref:`NXoptical_fiber` An optical fiber, e.g. glass fiber. :ref:`NXoptical_lens` Description of an optical lens. - :ref:`NXpolarizer_opt` + :ref:`NXoptical_polarizer` An optical polarizer. :ref:`NXwaveplate` From fdda78603064b28408b5507b97f409fcf20959a2 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 28 Aug 2025 12:05:55 +0200 Subject: [PATCH 0999/1012] typo fixes --- contributed_definitions/NXtransmission.nxdl.xml | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/contributed_definitions/NXtransmission.nxdl.xml b/contributed_definitions/NXtransmission.nxdl.xml index 38c7c68e19..03d5e58ee8 100644 --- a/contributed_definitions/NXtransmission.nxdl.xml +++ b/contributed_definitions/NXtransmission.nxdl.xml @@ -1,9 +1,9 @@ - + - Attenuator in the sample beam + Attenuator in the sample beam @@ -170,7 +170,7 @@ Draft NeXus application definition for transmission experiments--> Overall spectral resolution of this spectrometer. - If several gratings are employed the spectral resoultion + If several gratings are employed the spectral resolution should rather be specified for each grating inside the NXgrating group of this spectrometer. @@ -185,7 +185,7 @@ Draft NeXus application definition for transmission experiments--> do not overlap. The dispersion should be defined for the entire wavelength range of the experiment. - + Dispersion of the grating in nm/mm used. From 265fbd097987e41825c298ce819ba25eb476b03d Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 26 Sep 2025 12:31:55 +0200 Subject: [PATCH 1000/1012] Clarify situation wrt to NXclustering --- contributed_definitions/NXclustering.nxdl.xml | 124 ------------------ 1 file changed, 124 deletions(-) delete mode 100644 contributed_definitions/NXclustering.nxdl.xml diff --git a/contributed_definitions/NXclustering.nxdl.xml b/contributed_definitions/NXclustering.nxdl.xml deleted file mode 100644 index 76351758dd..0000000000 --- a/contributed_definitions/NXclustering.nxdl.xml +++ /dev/null @@ -1,124 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of numeral labels per object. - - - - - Number of categorical labels per object. - - - - - Total number of clusters detected. - - - - - Metadata to the results of a clustering analysis. - - Clustering algorithms are routine tools to segment a set of objects/primitives - into groups, objects of different type. A plethora of algorithms have been - proposed for geometric primitives as objects, such as points, triangles, - or (abstract) objects. - - This base class considers metadata and results of one clustering - applied to a set in which objects are either categorized as noise - or belonging to a cluster, specifically here only one cluster. - - - - How many numeric labels does each object have. - - - - - How many categorical labels does each object have. - - - - - Reference to a set of objects investigated in a cluster analysis. - Objects must have clear integer identifier. - - - - - Reference to numeric attribute data for each object. - - - - - Reference to categorical attribute data for each object. - - - - - - Which identifier is the first to be used to label a cluster. - - The value should be chosen in such a way that special values can be resolved: - * identifier_offset-1 indicates an object belongs to no cluster. - * identifier_offset-2 indicates an object belongs to the noise category. - Setting for instance identifier_offset to 1 recovers the commonly used - case that objects of the noise category get values to -1 and unassigned points to 0. - - - - - Total number of objects categorized as unassigned. - - - - - Total number of objects categorized as noise. - - - - - Total number of clusters (excluding noise and unassigned). - - - - - Number of objects associated to each cluster. The labels are implicit, - meaning the zeroth/first entry in the array belongs to the first cluster, - the second entry to the second cluster and so on and so forth. - The first cluster has the value of identifier_offset as its identifier. - The second cluster has identifier_offset + 1, and so on and so forth. - - - - - - - From 60e0c39917afc642ea1aee2402c84eff0f235942 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 26 Sep 2025 13:08:58 +0200 Subject: [PATCH 1001/1012] Fix error in cgms docs --- .../source/classes/contributed_definitions/cgms-structure.rst | 3 --- 1 file changed, 3 deletions(-) diff --git a/manual/source/classes/contributed_definitions/cgms-structure.rst b/manual/source/classes/contributed_definitions/cgms-structure.rst index 323d356494..ac18d3cebb 100644 --- a/manual/source/classes/contributed_definitions/cgms-structure.rst +++ b/manual/source/classes/contributed_definitions/cgms-structure.rst @@ -93,8 +93,5 @@ of material (area or volume) which can be useful not only for stencil-based meth is smoothed in a controlled manner. :ref:`NXsimilarity_grouping`: - An alternative for NXclustering. - - :ref:`NXclustering`: A description for clustering of objects (such as atoms or features). From befb2e5284837ea1b2e453a038f45ca6bff15311 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 26 Sep 2025 13:16:04 +0200 Subject: [PATCH 1002/1012] Removed NXcs_ classes that in the process of the acceptance of NXapm have were refactored as base classes, e.g. NXcs_computer --- contributed_definitions/NXcs_cpu.nxdl.xml | 39 -------------- contributed_definitions/NXcs_gpu.nxdl.xml | 39 -------------- contributed_definitions/NXcs_io_obj.nxdl.xml | 56 -------------------- contributed_definitions/NXcs_io_sys.nxdl.xml | 34 ------------ contributed_definitions/NXcs_mm_sys.nxdl.xml | 39 -------------- 5 files changed, 207 deletions(-) delete mode 100644 contributed_definitions/NXcs_cpu.nxdl.xml delete mode 100644 contributed_definitions/NXcs_gpu.nxdl.xml delete mode 100644 contributed_definitions/NXcs_io_obj.nxdl.xml delete mode 100644 contributed_definitions/NXcs_io_sys.nxdl.xml delete mode 100644 contributed_definitions/NXcs_mm_sys.nxdl.xml diff --git a/contributed_definitions/NXcs_cpu.nxdl.xml b/contributed_definitions/NXcs_cpu.nxdl.xml deleted file mode 100644 index b27b87481d..0000000000 --- a/contributed_definitions/NXcs_cpu.nxdl.xml +++ /dev/null @@ -1,39 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a central processing unit (CPU) of a computer. - - - - Given name of the CPU. Users should be as specific as possible. - - - - diff --git a/contributed_definitions/NXcs_gpu.nxdl.xml b/contributed_definitions/NXcs_gpu.nxdl.xml deleted file mode 100644 index 3392e41d39..0000000000 --- a/contributed_definitions/NXcs_gpu.nxdl.xml +++ /dev/null @@ -1,39 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a graphic processing unit (GPU) of a computer. - - - - Given name of the GPU. Users should be as specific as possible. - - - - diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml deleted file mode 100644 index eb1e7e19c5..0000000000 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ /dev/null @@ -1,56 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a storage object in an input/output system. - - - - Qualifier for the type of storage medium used. - - - - - - - - - - - Total amount of data which the medium can hold. - - - - - - Given name to the I/O unit. - - - - diff --git a/contributed_definitions/NXcs_io_sys.nxdl.xml b/contributed_definitions/NXcs_io_sys.nxdl.xml deleted file mode 100644 index 5608c9f886..0000000000 --- a/contributed_definitions/NXcs_io_sys.nxdl.xml +++ /dev/null @@ -1,34 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of system of a computer. - - - diff --git a/contributed_definitions/NXcs_mm_sys.nxdl.xml b/contributed_definitions/NXcs_mm_sys.nxdl.xml deleted file mode 100644 index d9c6779fd8..0000000000 --- a/contributed_definitions/NXcs_mm_sys.nxdl.xml +++ /dev/null @@ -1,39 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a main memory system of a computer. - - - - How much physical memory does the system provide. - - - - From 153864d45cc96ba48f640c439f298b4e8b9279d0 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 26 Sep 2025 13:21:44 +0200 Subject: [PATCH 1003/1012] Capitalization, typos and header docstring for electrostatic kicker --- .../NXelectrostatic_kicker.nxdl.xml | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/contributed_definitions/NXelectrostatic_kicker.nxdl.xml b/contributed_definitions/NXelectrostatic_kicker.nxdl.xml index 16d9bfeab8..c36c4a2c21 100644 --- a/contributed_definitions/NXelectrostatic_kicker.nxdl.xml +++ b/contributed_definitions/NXelectrostatic_kicker.nxdl.xml @@ -26,35 +26,35 @@ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd" > -definition for a electrostatic kicker. +Base class for an electrostatic kicker. -extended description of the kicker. +Extended description of the kicker. -define position of beamline element relative to production target +Define position of beamline element relative to production target -kicker timing as defined by ``description`` attribute +Kicker timing as defined by ``description`` attribute -current set on supply. +Current set on supply. -current read from supply. +Current read from supply. -volage set on supply. +Voltage set on supply. -voltage read from supply. +Voltage read from supply. From 8b1cdc232bb369aff87e4f704405a52ae07cb3a2 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 26 Sep 2025 13:24:05 +0200 Subject: [PATCH 1004/1012] Capitalization, typos and header docstring for magnetic kicker --- .../NXmagnetic_kicker.nxdl.xml | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/contributed_definitions/NXmagnetic_kicker.nxdl.xml b/contributed_definitions/NXmagnetic_kicker.nxdl.xml index 1ce3aec0bf..89a610d08b 100644 --- a/contributed_definitions/NXmagnetic_kicker.nxdl.xml +++ b/contributed_definitions/NXmagnetic_kicker.nxdl.xml @@ -26,32 +26,32 @@ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd" > - definition for a magnetic kicker. + Base class for a magnetic kicker. - extended description of the kicker. + Extended description of the kicker. - define position of beamline element relative to production target + Define position of beamline element relative to production target - kicker timing as defined by ``description`` attribute + Kicker timing as defined by ``description`` attribute - current set on supply. + Current set on supply. - current read from supply. + Current read from supply. - voltage set on supply. + Voltage set on supply. - voltage read from supply. + Voltage read from supply. From 5feadbb74cb93f767465bbdb994592b95086a186 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 26 Sep 2025 13:26:05 +0200 Subject: [PATCH 1005/1012] Capitalization, typos and header docstring for quadrupole magnet --- contributed_definitions/NXquadrupole_magnet.nxdl.xml | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/contributed_definitions/NXquadrupole_magnet.nxdl.xml b/contributed_definitions/NXquadrupole_magnet.nxdl.xml index 84442c7a17..27c43f1258 100644 --- a/contributed_definitions/NXquadrupole_magnet.nxdl.xml +++ b/contributed_definitions/NXquadrupole_magnet.nxdl.xml @@ -26,26 +26,26 @@ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd" > - definition for a quadrupole magnet. + Base class for a quadrupole magnet. -extended description of the magnet. +Extended description of the magnet. -define position of beamline element relative to production target +Define position of beamline element relative to production target -current set on supply. +Current set on supply. -current read from supply. +Current read from supply. -voltage read from supply. +Voltage read from supply. From 4890b8c0e30df3fea57e0c770d266c4e7cad6031 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 26 Sep 2025 13:29:44 +0200 Subject: [PATCH 1006/1012] Capitalization, typos and header docstring for separator --- contributed_definitions/NXseparator.nxdl.xml | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/contributed_definitions/NXseparator.nxdl.xml b/contributed_definitions/NXseparator.nxdl.xml index 81ba465340..a946eac1c5 100644 --- a/contributed_definitions/NXseparator.nxdl.xml +++ b/contributed_definitions/NXseparator.nxdl.xml @@ -26,33 +26,33 @@ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd" > - definition for an electrostatic separator. + Base class for an electrostatic separator. - extended description of the separator. + Extended description of the separator. - define position of beamline element relative to production target + Define position of beamline element relative to production target - current set on magnet supply. + Current set on magnet supply. - current read from magnet supply. + Current read from magnet supply. - voltage read from magnet supply. + Voltage read from magnet supply. - current set on HT supply. + Current set on HT supply. - current read from HT supply. + Current read from HT supply. - voltage read from HT supply. + Voltage read from HT supply. From ef88e03effcec183a736b8d7eb1e0187c5e2fd30 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 26 Sep 2025 13:40:13 +0200 Subject: [PATCH 1007/1012] Capitalization, typos and header docstring for spin_rotator, substance, and xpcs --- .../NXspin_rotator.nxdl.xml | 18 +++++++++--------- contributed_definitions/NXsubstance.nxdl.xml | 8 ++++---- contributed_definitions/NXxpcs.nxdl.xml | 8 ++++---- 3 files changed, 17 insertions(+), 17 deletions(-) diff --git a/contributed_definitions/NXspin_rotator.nxdl.xml b/contributed_definitions/NXspin_rotator.nxdl.xml index 8c0b93ad1f..876af4e5db 100644 --- a/contributed_definitions/NXspin_rotator.nxdl.xml +++ b/contributed_definitions/NXspin_rotator.nxdl.xml @@ -26,33 +26,33 @@ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd" > - definition for a spin rotator. + Base class for a spin rotator. - extended description of the spin rotator. + Extended description of the spin rotator. - define position of beamline element relative to production target + Define position of beamline element relative to production target - current set on magnet supply. + Current set on magnet supply. - current read from magnet supply. + Current read from magnet supply. - voltage read from magnet supply. + Voltage read from magnet supply. - current set on HT supply. + Current set on HT supply. - current read from HT supply. + Current read from HT supply. - voltage read from HT supply. + Voltage read from HT supply. diff --git a/contributed_definitions/NXsubstance.nxdl.xml b/contributed_definitions/NXsubstance.nxdl.xml index 6c18182fc3..7e4b19f390 100644 --- a/contributed_definitions/NXsubstance.nxdl.xml +++ b/contributed_definitions/NXsubstance.nxdl.xml @@ -3,7 +3,7 @@ @@ -523,7 +523,7 @@ The only requirement for the list is that it may be iterable. Some expected formats are: * iterable list of floats (i.e., :math:`Q(r)`) - * iterable list of tuples (i.e., :math:`Q(r)`, :math:`\varphi`), but preferable use the seperate :math:`\varphi` field below + * iterable list of tuples (i.e., :math:`Q(r)`, :math:`\varphi`), but preferable use the separate :math:`\varphi` field below * iterable list of tuples (e.g., (H, K, L); (qx, qy, qz); (horizontal_pixel, vertical_pixel)) * iterable list of integers (for Nth roi_map value) or strings @@ -565,7 +565,7 @@ dynamics from XPCS analysis). For non-equilibrium sample conditions (i.e., changing sample or process conditions - during the XPCS measurement) will require either a new entry or an additional atttribute. + during the XPCS measurement) will require either a new entry or an additional attribute. --> From 86d83a63436b1bfca53059d4d6d3a9c3f8c72182 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 26 Sep 2025 15:32:54 +0200 Subject: [PATCH 1008/1012] review comments --- .../NXbeam_splitter.nxdl.xml | 5 ++-- .../NXmatch_filter.nxdl.xml | 2 +- contributed_definitions/NXseparator.nxdl.xml | 20 ++++++++-------- .../NXspin_rotator.nxdl.xml | 24 +++++++++---------- .../NXsubsampling_filter.nxdl.xml | 2 +- 5 files changed, 26 insertions(+), 27 deletions(-) diff --git a/contributed_definitions/NXbeam_splitter.nxdl.xml b/contributed_definitions/NXbeam_splitter.nxdl.xml index 7475539ee8..636a33dc64 100644 --- a/contributed_definitions/NXbeam_splitter.nxdl.xml +++ b/contributed_definitions/NXbeam_splitter.nxdl.xml @@ -71,7 +71,7 @@ A draft of a new base class to describe a beam splitting device.--> should be described in 'geometry'. Define if the beam splitter is polarizing or not in the field 'polarizing(NX_BOOLEAN)'. - + @@ -80,7 +80,6 @@ A draft of a new base class to describe a beam splitting device.--> - @@ -113,7 +112,7 @@ in 'substrate/substrate_thickness' and 'coating/coating_thickness'.--> Describe the shape (plate, cube, wedged, prism etc.). - + diff --git a/contributed_definitions/NXmatch_filter.nxdl.xml b/contributed_definitions/NXmatch_filter.nxdl.xml index 5f6d3e81e7..22abd59174 100644 --- a/contributed_definitions/NXmatch_filter.nxdl.xml +++ b/contributed_definitions/NXmatch_filter.nxdl.xml @@ -33,7 +33,7 @@ - Base class of a filter to select members of a set based on their identifier. + Base class of a filter to select members of a set based on their index, identifier, or value. diff --git a/contributed_definitions/NXseparator.nxdl.xml b/contributed_definitions/NXseparator.nxdl.xml index a946eac1c5..1b90017b30 100644 --- a/contributed_definitions/NXseparator.nxdl.xml +++ b/contributed_definitions/NXseparator.nxdl.xml @@ -36,23 +36,23 @@ Current set on magnet supply. - - Current read from magnet supply. + + current read from magnet supply. - - Voltage read from magnet supply. + + voltage read from magnet supply. - - Current set on HT supply. + + current set on HT supply. - - Current read from HT supply. + + current read from HT supply. - - Voltage read from HT supply. + + voltage read from HT supply. diff --git a/contributed_definitions/NXspin_rotator.nxdl.xml b/contributed_definitions/NXspin_rotator.nxdl.xml index 876af4e5db..e0e4046537 100644 --- a/contributed_definitions/NXspin_rotator.nxdl.xml +++ b/contributed_definitions/NXspin_rotator.nxdl.xml @@ -33,26 +33,26 @@ Define position of beamline element relative to production target - - Current set on magnet supply. + + current set on magnet supply. - - Current read from magnet supply. + + current read from magnet supply. - - Voltage read from magnet supply. + + voltage read from magnet supply. - - Current set on HT supply. + + current set on HT supply. - - Current read from HT supply. + + current read from HT supply. - - Voltage read from HT supply. + + voltage read from HT supply. diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml index 509eb2f9d6..ef64b4843b 100644 --- a/contributed_definitions/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -25,7 +25,7 @@ symbols:--> - Base class of a filter to sample members in a set based on their identifier. + Base class of a filter to sample members in a set based on their indices, identifier, or value. From 8b4bb193f27ad7388595a4f5b321d4928f8b6b91 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Mon, 20 Oct 2025 21:37:48 +0200 Subject: [PATCH 1009/1012] Latest development stage of FAIRmat for the contributed definitions for atom probe and microstructure --- .../NXapm_compositionspace_config.nxdl.xml | 58 ++-- .../NXapm_compositionspace_results.nxdl.xml | 18 +- .../NXapm_paraprobe_clusterer_config.nxdl.xml | 98 +------ ...NXapm_paraprobe_clusterer_results.nxdl.xml | 80 +---- .../NXapm_paraprobe_distancer_config.nxdl.xml | 102 +------ ...NXapm_paraprobe_distancer_results.nxdl.xml | 72 +---- ...Xapm_paraprobe_intersector_config.nxdl.xml | 42 +-- ...apm_paraprobe_intersector_results.nxdl.xml | 59 +--- .../NXapm_paraprobe_nanochem_config.nxdl.xml | 258 ++-------------- .../NXapm_paraprobe_nanochem_results.nxdl.xml | 277 +++++++----------- .../NXapm_paraprobe_ranger_config.nxdl.xml | 91 +----- .../NXapm_paraprobe_ranger_results.nxdl.xml | 93 +----- .../NXapm_paraprobe_selector_config.nxdl.xml | 95 +----- .../NXapm_paraprobe_selector_results.nxdl.xml | 71 +---- .../NXapm_paraprobe_spatstat_config.nxdl.xml | 134 ++------- .../NXapm_paraprobe_spatstat_results.nxdl.xml | 67 +---- .../NXapm_paraprobe_surfacer_config.nxdl.xml | 195 ++++-------- .../NXapm_paraprobe_surfacer_results.nxdl.xml | 73 +---- ...Xapm_paraprobe_tessellator_config.nxdl.xml | 129 ++------ ...apm_paraprobe_tessellator_results.nxdl.xml | 74 +---- .../NXapm_paraprobe_tool_common.nxdl.xml | 53 +--- .../NXapm_paraprobe_tool_config.nxdl.xml | 177 ++++++----- .../NXapm_paraprobe_tool_parameters.nxdl.xml | 114 +++++++ .../NXapm_paraprobe_tool_process.nxdl.xml | 68 +++++ .../NXapm_paraprobe_tool_results.nxdl.xml | 107 ++++--- ...NXapm_paraprobe_transcoder_config.nxdl.xml | 80 ----- ...Xapm_paraprobe_transcoder_results.nxdl.xml | 217 -------------- .../NXdelocalization.nxdl.xml | 70 ++--- .../NXem_calorimetry.nxdl.xml | 6 +- contributed_definitions/NXisocontour.nxdl.xml | 46 +-- .../NXmatch_filter.nxdl.xml | 12 +- .../NXmicrostructure_score_config.nxdl.xml | 47 ++- .../NXmicrostructure_score_results.nxdl.xml | 21 +- .../NXsimilarity_grouping.nxdl.xml | 76 ++--- .../NXspatial_filter.nxdl.xml | 16 +- .../NXsubsampling_filter.nxdl.xml | 42 +-- 36 files changed, 882 insertions(+), 2356 deletions(-) create mode 100644 contributed_definitions/NXapm_paraprobe_tool_parameters.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_tool_process.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml diff --git a/contributed_definitions/NXapm_compositionspace_config.nxdl.xml b/contributed_definitions/NXapm_compositionspace_config.nxdl.xml index dd02255eb9..157a362d9a 100644 --- a/contributed_definitions/NXapm_compositionspace_config.nxdl.xml +++ b/contributed_definitions/NXapm_compositionspace_config.nxdl.xml @@ -42,13 +42,16 @@ Specification of the tomographic reconstruction used for this analysis. - Typically, reconstructions in the field of atom probe tomography are communicated via - files which store at least reconstructed ion positions and mass-to-charge-state-ratio - values. Container files like HDF5 though can store multiple reconstructions. - Therefore, the position and mass_to_charge concepts point to specific instances - to use for this analysis. + + Reconstructions in the field of atom probe tomography are communicated via + a file which stores the reconstructed position and mass-to-charge-state-ratio + value for each ion. + + Container file formats like HDF5, such as NeXus/HDF5 files using :ref:`NXapm`, + can store multiple reconstructions. In this case, the position and mass_to_charge + concepts point to specific instances in the file referred to by file_name for the + analysis with CompositionSpace. - @@ -60,7 +63,7 @@ - Name of the node which resolves the mass-to-charge-state ratio + Name of the node which resolves the mass-to-charge-state-ratio values for each reconstructed ion to use for this analysis. @@ -69,17 +72,24 @@ Specification of the ranging definitions used for this analysis. - Indices start from 1. The value 0 is reserved for the null model of unranged positions whose - iontype is unknown_type. The value 0 is also reserved for voxels that lie outside the dataset. + Ranging definitions in the field of atom probe tomography are communicated via + a file which stores the mass-to-charge-state-ratio interval and the number of elements + of which each (molecular) ion is composed. These values are stored for each ion. + + Container file formats like HDF5, such as NeXus/HDF5 files using :ref:`NXapm`, + can store multiple ranging definitions. + + Indices of ions start from 1. The value 0 is reserved for the null model of unranged positions + whose iontype is referred to as the unknown_type. The value 0 is also reserved for voxels + that lie outside the dataset. - - Name of the (parent) node directly below which the ranging definitions for - (molecular) ions are stored. + Name of that (parent) node whose child stores the ranging definitions that + are applied in this analysis with CompositionSpace. @@ -131,8 +141,8 @@ - Step during which the voxel set is segmented into voxel sets with different - chemical composition. + Step during which the voxel set is segmented into voxel sets + with different chemical composition. @@ -185,14 +195,14 @@ +doc: | +TODO +distance_cut(NX_NUMBER): +doc: | +TODO +units: NX_ANY +normal_end_length(NX_NUMBER): +doc: | +TODO +units: NX_ANY--> diff --git a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml index e1bcb394f8..92a2f356d0 100644 --- a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml +++ b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml @@ -85,13 +85,12 @@ Configuration file that was used in this analysis. - - + Contextualize back to the specimen from which the @@ -135,7 +134,7 @@ - + @@ -147,7 +146,7 @@ - + @@ -200,7 +199,7 @@ - + Chemical symbol of the element from the periodic table. @@ -291,8 +290,8 @@ - Elements identifier matching those from ENTRY/voxelization/ION - as the principal component analysis. + Elements identifier matching those from ENTRY/voxelization/ionID + used during the principal component analysis. @@ -366,8 +365,9 @@ Step during which the chemically segmented voxel sets are analyzed for their spatial organization - into different spatial clusters of voxels in the same chemical set but representing individual object - not-necessarily watertight or topologically closed objects built from individual voxels. + into different spatial clusters of voxels in the same chemical set but representing individual objects. + The objects are constructed from blobs of neighboring voxels. + The objects are not necessarily watertight or topologically closed. diff --git a/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml index 76bdb6a531..e0fe10b8b1 100644 --- a/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml @@ -3,7 +3,7 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -46,21 +46,15 @@ Application definition for a configuration file of the paraprobe-clusterer tool. - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + The tool paraprobe-clusterer evaluates how points cluster in space. - - - - How many cluster_analysis tasks should the tool execute. - - - + This process maps results from a cluster analysis made with IVAS / AP Suite into an interoperable representation. IVAS / AP Suite usually exports such results @@ -70,7 +64,6 @@ point numbers. - @@ -86,7 +79,6 @@ quadruplet encode the position of the ion. The fourth value is the integer identifier of the cluster encoded as a floating point number. - @@ -108,82 +100,20 @@ evaporation_id a bitmask which identifies which of the positions in dataset/dataset/dataset_name_reconstruction where covered by the IVAS/APSuite cluster analysis. This can be useful to recover the region of interest.--> - + This process performs a cluster analysis on a reconstructed dataset or a ROI within it. - - - - - - - - - - - - - - - Distance between each ion and triangulated surface mesh. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - How should iontypes be considered during the cluster analysis. @@ -359,21 +289,7 @@ dim: (j,)--> - - - - - - - - - - - - - - - + diff --git a/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml index bff207f5e1..031010b79c 100644 --- a/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml @@ -3,7 +3,7 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -38,34 +38,19 @@ - Application definition for results files of the paraprobe-spatstat tool. + Application definition for a results file of the paraprobe-clusterer tool. - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + The tool paraprobe-clusterer evaluates how points cluster in space. - - - - - - - - - - - - - - - - - - + + + Results of a DBScan clustering analysis. @@ -124,7 +109,7 @@ - + The raw labels from the DBScan clustering backend process. The length of this array is not necessarily n_ions. @@ -146,7 +131,7 @@ - + Numerical label for each target (member in the set) aka cluster identifier. @@ -154,7 +139,7 @@ - + Categorical label(s) for each target (member in the set) aka cluster name(s). @@ -162,7 +147,7 @@ - + Weights for each target that specifies how probable the target is assigned to a specific cluster. @@ -240,48 +225,5 @@ - - - - - - - - - - - - - - - - - - - - If used, metadata of at least the person who performed this analysis. - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml index 4b7127d3d8..d7d0f13191 100644 --- a/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml @@ -3,7 +3,7 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - + Application definition for a configuration file of the paraprobe-distancer tool. - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + The tool paraprobe-distancer tool evaluates exactly the shortest Euclidean distance for each + member of a set of points against a set of triangles. + + Triangles can represent for instance the facets of a triangulated surface mesh like those returned by + paraprobe-surfacer or any other set of triangles. Triangles do not have to be connected. + + Currently, paraprobe-distancer does not check if the respectively specified triangle sets are consistent, + what their topology is, or whether or not these triangles are consistently oriented. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + Specifies for which point the tool will compute distances. @@ -124,7 +61,6 @@ computed when *method* is *skin*. - How many triangle sets to consider. @@ -140,7 +76,6 @@ start at zero and must not exceed n_vertices - 1, i.e. the index_offset is 0. Facet normal have to be provided as an array of (n_facets, 3) of NX_FLOAT. - @@ -180,20 +115,5 @@ - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml index 931f0a115e..1cffc8eab2 100644 --- a/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml @@ -3,7 +3,7 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -38,13 +38,10 @@ - Application definition for results files of the paraprobe-distancer tool. + Application definition for a results file of the paraprobe-distancer tool. - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. - The paraprobe-distancer tool can be used for the computing of the shortest Euclidean distance for each - member of a set of points against a set of triangles. In contrast to most approaches in atom probe where the - distance is computed as the projected distance, this tool evaluates robustly the exact distance between - a point and a triangle. + The tool paraprobe-distancer tool evaluates exactly the shortest Euclidean distance for each + member of a set of points against a set of triangles. Triangles can represent for instance the facets of a triangulated surface mesh like those returned by paraprobe-surfacer or any other set of triangles. Triangles do not have to be connected. @@ -54,26 +51,11 @@ - - - - - - - - - - - - - - - - + The shortest analytical distance of each point to their @@ -153,47 +135,5 @@ triangles in this case--> - - - - - - - - - - - - - - - - - - - If used, metadata of at least the person who performed this analysis. - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml index e66e2acf32..76a3c27c00 100644 --- a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml @@ -3,7 +3,7 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -33,23 +33,16 @@ - Application definition for a configuration file of the paraprobe-intersector tool. - - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + Application definition for a configuration file of the paraprobe-intersector + tool. - - - - How many v_v_spatial_correlation tasks should the tool execute. - - - + Tracking volume_volume_spatial_correlations (v_v) is the process of building logical relations between objects, their proximity and eventual volumetric intersections. @@ -61,7 +54,6 @@ Members of a so-called current_set to members of a so-called next_set. Members can be different types of volumetric features. - Specifies the method whereby to decide if two objects intersect volumetrically. @@ -152,7 +144,7 @@ current_set. - + Name of the (NeXus)/HDF5 file which contains triangulated surface meshes of the members of the set as instances of NXcg_polyhedron. @@ -169,7 +161,6 @@ - @@ -222,7 +213,7 @@ next_set. - + Descriptive category explaining what these features are. @@ -234,7 +225,6 @@ - @@ -257,21 +247,7 @@ - - - - - - - - - - - - - - - + diff --git a/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml index 50883f97e8..dff4a65f9f 100644 --- a/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml @@ -3,7 +3,7 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -59,18 +59,14 @@ Application definition for results files of the paraprobe-intersector tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. - - - + The results of an overlap/intersection analysis. @@ -219,54 +215,5 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - If used, metadata of at least the person who performed this analysis. - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml index 4392766bdd..98b61e358a 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml @@ -3,7 +3,7 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -69,20 +69,17 @@ Application definition for a configuration file of the paraprobe-nanochem tool. - - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. - - + Discretization and distributing of the ion point cloud on a 3D grid - to enable continuum-scale analyses. + to enable analyses at the continuum scale. By default, the tool computes a full kernel density estimation of decomposed ions to create one discretized field for each element. @@ -93,32 +90,15 @@ and three kernel_variance will compute six runs. Two sets of three with the first set using the first grid_resolutions and in sequence the kernel_variance respectively. - - - - - - - - - - - - - - - - - A precomputed triangulated surface mesh representing a model (of the surface) of the edge of the dataset. This model can be used to detect and control various sources of bias in the analyses. - @@ -139,60 +119,34 @@ This can be achieved with the load_existent option.--> Distance between each ion and triangulated surface mesh. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Configuration for the algorithm that defines how the multiplicity of all - those ions are computed that are considered in the delocalization. + Configuration for the algorithm that defines the multiplicity of + each reconstructed position during the delocalization. - TODO + The multiplicity of an ion at a reconstructed position is defined as follows: + + * resolve_unknown, multiplicity equals 1 for all ions of the unknown_type + This mode is useful for segmenting regions with poor ranging. + * resolve_point, multiplicity equals 1 for all ions + This mode is useful for segmenting point density. + * resolve_atom, multiplicity equals the number of atoms per ion + This mode is useful for segmenting atomic density. + * resolve_element, multiplicity equals the number of elements in the whitelist per ion + This mode is useful for segmenting regions of specific elemental composition (ignoring nuclids) + * resolve_element_charge, ???multiplicity like resolve_element when charge is met + * resolve_isotope, multiplicity equals the number of nuclides in the whitelist per ion + This mode is useful for segmenting regions of specific isotopic composition + * resolve_isotope_charge, ??? + + Other multiplicities are 0. @@ -209,22 +163,12 @@ identifier(NX_UINT):--> TODO - TODO - - - - - - - - - @@ -240,7 +184,6 @@ identifier(NX_UINT):--> Serialized result of an already computed delocalization which is for performance reasons here just loaded and not computed again. - @@ -417,7 +360,6 @@ identifier(NX_UINT):--> * candidates, total number of ions with type in the isotope_whitelist. * composition, candidates but normalized by composition, i.e. at.-% * concentration, candidates but normalized by voxel volume, i.e. ions/nm^3 - @@ -575,7 +517,7 @@ identifier(NX_UINT):--> doc: Specifies if the tool should post-process each mesh to improve the mesh quality. mesh_smoothing(NXprocess): NEW ISSUE: here we need to specify how the meshes were smoothened--> - + Use a principle component analysis (PCA) to mesh a single free-standing interface patch within the reconstructed volume that is decorated by ions of specific iontypes (e.g. solute atoms). @@ -592,29 +534,12 @@ NEW ISSUE: here we need to specify how the meshes were smoothened--> paraprobe-nanochem uses inspection functionalities which detect potential geometric inconsistencies or self-interactions of the evolved DCOM mesh. - - - - - - - - - - - - - - - - A precomputed triangulated surface mesh representing a model (of the surface) of the edge of the dataset. This model can be used to detect and control various sources of bias in the analyses. - @@ -631,54 +556,6 @@ NEW ISSUE: here we need to specify how the meshes were smoothened--> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @@ -702,7 +579,6 @@ identifier(NX_UINT):--> Details about the control point file used. - @@ -788,7 +664,7 @@ identifier(NX_UINT):--> - + Analysis of one-dimensional profiles in ROIs placed in the dataset. Such analyses are useful for quantifying interfacial excess or for @@ -820,29 +696,12 @@ identifier(NX_UINT):--> intersection of triangles and convex polyhedra is a robust but currently not implemented method to quantify intersections. - - - - - - - - - - - - - - - - A precomputed triangulated surface mesh representing a model (of the surface) of the edge of the dataset. This model can be used to detect and control various sources of bias in the analyses. - @@ -863,7 +722,6 @@ identifier(NX_UINT):--> Distance between each ion and triangulated surface mesh. - @@ -882,7 +740,6 @@ identifier(NX_UINT):--> interface as returned e.g. by a previous interface_meshing task or the mesh of an iso-surface from a previous delocalization task. - @@ -927,7 +784,6 @@ from normals of neighboring facets, type of weighting schemes can affect results mesh it is recommended to feed precomputed distances of each ion to the triangles of the feature mesh. - @@ -939,56 +795,8 @@ from normals of neighboring facets, type of weighting schemes can affect results - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + As an alternative mode the tool can be instructed to place ROIs at specific locations into the dataset. This is the programmatic @@ -1052,19 +860,5 @@ but cylinders are most frequently used--> - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml index c1c1b20621..431f2360e7 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml @@ -3,7 +3,7 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -80,18 +80,15 @@ The cardinality/total number of triangles in the triangle soup.--> - The total number of ROIs placed in an oned_profile task. + The total number of ROIs placed in a oned_profile task. - Application definition for results files of the paraprobe-nanochem tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + Application definition for a results file of the paraprobe-nanochem tool. - @@ -104,26 +101,6 @@ The cardinality/total number of triangles in the triangle soup.--> - - - - - - - - How were results of the kernel-density estimation normalized: - * total, the total number (intensity) of ions or elements. - * candidates, the total number (intensity) of ions matching weighting_model - * composition, the value for candidates divided by the value for total, - * concentration, the value for candidates divided by the volume of the cell. - - - - - - - - The discretized domain/grid on which the delocalization is applied. @@ -220,6 +197,22 @@ The cardinality/total number of triangles in the triangle soup.--> + + + How were results of the kernel-density estimation normalized: + + * total, the total number (intensity) of ions or elements. + * candidates, the total number (intensity) of ions matching weighting_model + * composition, the value for candidates divided by the value for total, + * concentration, the value for candidates divided by the volume of the cell. + + + + + + + + A tight axis-aligned bounding box about the grid. @@ -341,55 +334,50 @@ The cardinality/total number of triangles in the triangle soup.--> The result of the delocalization :math:`\Phi = f(x, y, z)` based on which subsequent iso-surfaces will be computed. In commercial software so far there is no possibility to export this information. - If the intensity for all matches of the weighting_model are summarized name this NXdata instance + If the intensity for all matches of the weighting_model are summarized, name this NXdata instance scalar_field_magn_total. - If the intensity is reported for each iontype one can avoid many subsequent + If the intensity is reported for each iontype, one can avoid many subsequent computations as individual intensities can be reinterpreted using a different weighting_model in down-stream usage of the here reported values (e.g. with Python scripting). In this case name the individual NXdata instances scalar_field_magn_ionID using the ID of the ion as per the configuration of the ranging definitions used. - - - - - - - - - The actual delocalized intensity values. - - - - - - - - - - Cell center of mass positions along x. - - - - - - - - Cell center of mass positions along y. - - - - - - - - Cell center of mass positions along z. - - - - - + Intensity of the field at given point @@ -398,7 +386,7 @@ The cardinality/total number of triangles in the triangle soup.--> - + Center of mass positions of each voxel for rendering the scalar field via XDMF in e.g. Paraview. @@ -423,47 +411,41 @@ The cardinality/total number of triangles in the triangle soup.--> The three-dimensional gradient :math:`\nabla \Phi`. Follow the naming convention of scalar_field_magn_SUFFIX to report parallel structures. - - - - - - - - - The actual point-wise component values. - - - - - - - - - - - Cell center of mass positions along x. - - - - - - - - Cell center of mass positions along y. - - - - - - - - Cell center of mass positions along z. - - - - - + The gradient vector formatted for direct visualization via XDMF in e.g. @@ -512,7 +494,7 @@ The cardinality/total number of triangles in the triangle soup.--> The threshold or iso-contour value :math:`\varphi`. - + Reference to the specific implementation of marching cubes used. The value placed here should be a DOI. If there are no specific @@ -531,8 +513,8 @@ The cardinality/total number of triangles in the triangle soup.--> - - + + Positions of the vertices. @@ -722,7 +704,7 @@ dim: (k,)--> In the second step, the tool can be used to analyze the proximity of these objects to a model of the surface (edge) of the dataset. - + The identifier which the triangle_soup connectivity analysis returned, which constitutes the first step of the @@ -882,7 +864,7 @@ MK::namely k != i each OBB has eight vertices--> - + @@ -931,12 +913,7 @@ MK::namely k != i each OBB has eight vertices--> - - - - - - + @@ -1097,12 +1074,7 @@ MK::namely k != i each OBB has eight vertices--> - - - - - - + @@ -1201,54 +1173,5 @@ MK::namely k != i each OBB has eight vertices--> - - - - - - - - - - - - - - - - - - - - - - - - - - If used, metadata of at least the person who performed this analysis. - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml index 5e3f50c4d3..2852414f13 100644 --- a/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml @@ -3,7 +3,7 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -41,96 +41,15 @@ Application definition for a configuration file of the paraprobe-ranger tool. - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + The tool paraprobe-ranger evaluates how mass-to-charge-state-ratio + values map on (molecular) ion types. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + diff --git a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml index 3b7e7b2a0f..2d42fa8948 100644 --- a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml @@ -3,7 +3,7 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -35,101 +35,32 @@ Application definition for results files of the paraprobe-ranger tool. - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. - The purpose and need of the paraprobe-ranger tool is to apply a given set of ranging definitions within - a certain (possibly complicated) selection of ions (based on their properties or location in the - reconstructed volume. + The tool paraprobe-ranger evaluates how mass-to-charge-state-ratio + values map on (molecular) ion types. - - - + - Paraprobe-ranger loads the iontypes and evaluates for each - ion on which iontype it matches. If it matches on None, the - ion is considered of the default *unknown_type*. This iontype - is marked with a 0 in the iontypes array. + The tool loads ranging definitions from the configuration file and + evaluates for each ion to which iontype it matches. + If an ion matches on no type, the ion is assume of the default + *unknown_type*. In this case, the value *iontypes* is 0. + In other cases the value is larger than 0. - - - - - - - - - - - - - - The iontype (identifier) for each ion that was best matching, stored - in the order of the evaporation sequence ID. The here computed iontypes - do not take into account the charge state of the ion which is - equivalent to interpreting a RNG and RRNG range files for each - ion in such a way that only the those elements are considered of which - a (molecular) ion is assumed composed according to the NXatom instances. + The iontype (identifier) for each ion that was best matching, + stored in the order of the evaporation sequence ID. - - - - - - - - - - - - - - - - - - - - - - - - - - If used, metadata of at least the person who performed this analysis. - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml index d3ffabb4d6..d57fa80c9f 100644 --- a/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml @@ -3,7 +3,7 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - + - Application definition for a configuration file of the paraprobe-selector tool. - - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + Application definition for a configuration file of the paraprobe-selector tool. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + diff --git a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml index 35838e69c3..760d26b8b2 100644 --- a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml @@ -3,7 +3,7 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -33,77 +33,14 @@ - Application definition for results files of the paraprobe-selector tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. - The purpose and need of the paraprobe-selector tool is to identify which reconstructed positions - are located inside or on the surface of a (possibly complicated) region-of-interest (ROI). - In addition, the tool allows to filter ions for properties. + Application definition for a results file of the paraprobe-selector tool. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If used, metadata of at least the person who performed this analysis. - - - - - - - - - - - - - - - - - - - - - - - + diff --git a/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml index 8947a57ef2..34d3efc6f5 100644 --- a/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml @@ -3,7 +3,7 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -45,42 +45,16 @@ Application definition for a configuration file of the paraprobe-spatstat tool. - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + The tool paraprobe-spatstat evaluates spatial distribution functions. - - - - How many spatial_statistics tasks should the tool execute. - - - - - - - - - - - - - - - - - - - + - - Distance between each ion and triangulated surface mesh. - - @@ -108,7 +82,6 @@ ions within a distance not farther away to a feature than the feature_distance threshold value. - @@ -130,55 +103,6 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specifies, if the iontypes are randomized for the point cloud or not. @@ -293,45 +217,43 @@ identifier(NX_UINT):--> Order k. - + + + Minimum value of the histogram binning. + + + + + Increment of the histogram binning. + + + - Minimum value, increment, and maximum value of the histogram binning. + Maximum value of the histogram binning. - - - Compute radial distribution function. - + - Minimum value, increment, and maximum value of the histogram binning. + Minimum value of the histogram binning. + + + + + Increment value of the histogram binning. + + + + + Maximum value of the histogram binning. - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml index b12422c928..094a3f9a82 100644 --- a/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml @@ -3,7 +3,7 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -43,25 +43,17 @@ - Application definition for results files of the paraprobe-spatstat tool. + Application definition for a results file of the paraprobe-spatstat tool. - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + The tool paraprobe-spatstat evaluates spatial distribution functions. - - - - - - - - - + The iontype ID for each ion that was assigned to each ion during @@ -145,54 +137,5 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - If used, metadata of at least the person who performed this analysis. - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml index e769564090..cf9b4f66ef 100644 --- a/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml @@ -3,7 +3,7 @@ - + - The symbols used in the schema to specify e.g. dimensions of arrays. + The symbols used in the schema to specify e.g. dimensions of arrays. - Number of alpha values (and offset values) to probe. + Number of alpha values (and offset values) to probe. - How many different match values does the filter specify. + How many different match values does the filter specify. - Application definition for a configuration file of the paraprobe-surfacer tool. - - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + Application definition for a configuration file of the paraprobe-surfacer tool. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + - Specifies the method that is used to preprocess the point cloud - prior to the alpha-shape computation. - - The option *default* specifies that no such filtering is applied. - The option *kuehbach* specifies that a Hoshen-Kopelman - percolation analysis is used to identify points that lie closer - to the edge of the dataset. Details about the methods are reported - in `M. Kühbach et al. <https://doi.org/10.1038/s41524-020-00486-1>`_. + Specifies the method that is used to preprocess the point cloud + prior to the alpha-shape computation. + + The option *default* specifies that no such filtering is applied. + The option *percolation* specifies that a Hoshen-Kopelman + percolation analysis is used to identify points that lie closer + to the edge of the dataset. Details about the methods are reported + in `M. Kühbach et al. <https://doi.org/10.1038/s41524-020-00486-1>`_. - + - When using the kuehbach preprocessing, this is the width of the - kernel for identifying which ions are in voxels close to the - edge of the point cloud. + When using the *percolation* preprocessing, this is the width of the + kernel for identifying which ions are in voxels close to the + edge of the point cloud. - Specifies which method to use to define the alpha value. - - The value *convex_hull_naive* is the default. The setting instructs - the tool to use a fast specialized algorithm for computing only - the convex hull. The resulting triangles can be skinny. - - The value *convex_hull_refine* instructs to tool to refine the - quality of the mesh resulting from *convex_hull_naive* - via triangle flipping and splitting. - - The value *smallest_solid* instructs the CGAL library to choose a - value which realizes an alpha-shape that is the smallest solid. - - The value *cgal_optimal* instructs the CGAL library to choose a - value which the library considers as to be an optimal value. - Details are defined in the respective section of the CGAL library - on 3D alpha shapes. - - The value *set_of_values* instructs the tool to compute a list - collection of alpha-shapes for the specified alpha-values. - - The value *set_of_alpha_wrappings* instructs the tool to generate - a set of so-called alpha wrappings. These are similar to alpha-shapes - but provide additional guarantees (such as watertightness and - proximity constraints) on the resulting wrapping. + Specifies which method to use to define the alpha value. + + The value *convex_hull_naive* is the default. The setting instructs + the tool to use a fast specialized algorithm for computing only + the convex hull. The resulting triangles can be skinny. + + The value *convex_hull_refine* instructs to tool to refine the + quality of the mesh resulting from *convex_hull_naive* + via triangle flipping and splitting. + + The value *smallest_solid* instructs the CGAL library to choose a + value which realizes an alpha-shape that is the smallest solid. + + The value *cgal_optimal* instructs the CGAL library to choose a + value which the library considers as to be an optimal value. + Details are defined in the respective section of the CGAL library + on 3D alpha shapes. + + The value *set_of_values* instructs the tool to compute a list + collection of alpha-shapes for the specified alpha-values. + + The value *set_of_alpha_wrappings* instructs the tool to generate + a set of so-called alpha wrappings. These are similar to alpha-shapes + but provide additional guarantees (such as watertightness and + proximity constraints) on the resulting wrapping. @@ -180,8 +111,8 @@ - Array of alpha values to use when alpha_value_choice is - set_of_values or when alpha_value_choice is set_of_alpha_wrappings. + Array of alpha values to use when alpha_value_choice is + set_of_values or when alpha_value_choice is set_of_alpha_wrappings. @@ -189,8 +120,8 @@ - Array of offset values to use when alpha_value_choice is set_of_alpha_wrappings. - The array of alpha_values and offset_values define a sequence of (alpha and offset value). + Array of offset values to use when alpha_value_choice is set_of_alpha_wrappings. + The array of alpha_values and offset_values define a sequence of (alpha and offset value). @@ -198,37 +129,23 @@ - Specifies if the tool should compute the set of exterior triangle facets - for each alpha complex (for convex hull, alpha shapes, and wrappings). + Specifies if the tool should compute the set of exterior triangle facets + for each alpha complex (for convex hull, alpha shapes, and wrappings). - Specifies if the tool should check if the alpha complex of - exterior triangular facets is a closed polyhedron. + Specifies if the tool should check if the alpha complex of + exterior triangular facets is a closed polyhedron. - Specifies if the tool should compute all interior tetrahedra - of the alpha complex (currently only for alpha shapes). + Specifies if the tool should compute all interior tetrahedra + of the alpha complex (currently only for alpha shapes). - - - - - - - - - - - - - - - + diff --git a/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml index 2792a2ab6b..42c1143938 100644 --- a/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml @@ -3,7 +3,7 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -53,22 +53,15 @@ - Application definition for results files of the paraprobe-surfacer tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. - The purpose and need of the paraprobe-surfacer tool is the generation of meshed - representation of the surface of the the reconstructed volume (or a portion) of it - using different algorithms from the computational geometry community. + Application definition for a results file of the paraprobe-surfacer tool. - - - + Paraprobe-surfacer can be used to load a ROI that is the entire or a sub-set of the ion point cloud. In the point_cloud_wrapping process @@ -84,13 +77,6 @@ This polyhedron is not necessarily convex. For some algorithms there is no guarantee that the resulting mesh yields a watertight mesh. - - - - - - - @@ -232,56 +218,5 @@ for eventually performed preprocessing--> - - - - - - - - - - - - - - - - - - - - - - - - - - - If used, metadata of at least the person who performed this analysis. - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml index c576765007..c6aa0c5549 100644 --- a/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml @@ -3,7 +3,7 @@ - + - Application definition for a configuration file of the paraprobe-tessellator tool. - - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + Application definition for a configuration file of the paraprobe-tessellator tool. + + The tool paraprobe-tessellator computes a tessellation of the reconstructed positions. - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The method used to compute the tessellation. - The value *default* configures the computation of the Voronoi tessellation. + The method used to compute the tessellation. + The value *default* configures the computation of the Voronoi tessellation. @@ -125,50 +58,36 @@ if windowing_method is bitmasked_points: sum cardinality of NXcg := 0 and cardin - Specifies if the tool should report the volume of each cell. + Specifies if the tool should report the volume of each cell. - Specifies if the tool should report the first-order neighbors of each cell. + Specifies if the tool should report the first-order neighbors of each cell. - Specifies if the tool should report the facets and vertices of each cell. + Specifies if the tool should report the facets and vertices of each cell. - Specifies if the tool should report for each cell if it makes contact with - the tight axis-aligned bounding box about the point cloud. - This can be used to identify if the shape of the cell is likely affected - by the edge of the dataset or if cells are deeply enough embedded - into the point cloud so that the shape of their cells are not affected - anymore by the boundary. This is valuable information to judge - about the significance of finite size effects. + Specifies if the tool should report for each cell if it makes contact with + the tight axis-aligned bounding box about the point cloud. + This can be used to identify if the shape of the cell is likely affected + by the edge of the dataset or if cells are deeply enough embedded + into the point cloud so that the shape of their cells are not affected + anymore by the boundary. This is valuable information to judge + about the significance of finite size effects. - - - - - - - - - - - - - - - + diff --git a/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml index 0dd825c0fa..04604c08bb 100644 --- a/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml @@ -1,9 +1,9 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -44,19 +44,17 @@ - Application definition for results files of the paraprobe-tessellator tool. + Application definition for a results file of the paraprobe-tessellator tool. - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + The tool paraprobe-tessellator computes a tessellation of the reconstructed positions. - - - + The tool can be used to compute a Voronoi tessellation the entire or of a sub-set of the reconstructed volume. Each point (ion) is wrapped @@ -66,13 +64,6 @@ The tool detects if cells make contact with the walls of this bounding box. The tessellation is computed without periodic boundary conditions. - - - - - - - The (tight) axis-aligned bounding box about the point cloud. @@ -267,13 +258,13 @@ dim: (i,) # one would not need to constrain this but doing so communicates that - + In the spirit of wall_contact_global, the front face of *aabb*. Its outer unit normal points in the direction of the z-axis of the *paraprobe* coordinate system. - + @@ -282,54 +273,5 @@ dim: (i,) # one would not need to constrain this but doing so communicates that - - - - - - - - - - - - - - - - - - - - - - - - - - If used, metadata of at least the person who performed this analysis. - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml index 7413a376a1..eead897424 100644 --- a/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml @@ -3,7 +3,7 @@ - Base class documenting the information common to tools of the paraprobe-toolbox. - - The paraprobe-toolbox is a collection of open-source tools for performing - efficient analyses of point cloud data where each point can represent atoms or - (molecular) ions. A key application of the toolbox has been for research in the - field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): - - * `paraprobe-toolbox <https://www.gitlab.com/paraprobe/paraprobe-toolbox>`_ - * `M. Kühbach et al. <https://paraprobe-toolbox.readthedocs.io/en/main/>`_ - - The toolbox does not replace but complements existent software tools in this - research field. Given its capabilities of handling points as objects with - properties and enabling analyses of the spatial arrangement of and inter- - sections between geometric primitives, the software can equally be used - for analyzing data in Materials Science and Materials Engineering. - - The common section can be used as a place to store e.g. organizational - metadata and contextualization of that analysis in a research data - management system. + Base class documenting organizational metadata used by all tools of the + paraprobe-toolbox. @@ -59,11 +42,10 @@ - - + - Internal identifier used by the tool to refer to an analysis (aka simulation - id). + Internal identifier used by the tool to refer to an analysis. + Simulation ID is an alias. @@ -72,11 +54,8 @@ the algorithms that this tool has executed. + - ISO 8601 formatted time code with local time zone offset to UTC @@ -97,21 +76,21 @@ results will be stored in the current working directory.--> - - + + Details about coordinate systems (reference frames) used. In atom probe several coordinate systems have to be distinguished. Names of instances of such :ref:`NXcoordinate_system` should be documented explicitly and doing so by picking from the following controlled set of names: - * paraprobe - * lab - * specimen - * laser - * instrument - * detector - * recon + * paraprobe_reference_frame + * lab_reference_frame + * specimen_reference_frame + * laser_reference_frame + * instrument_reference_frame + * detector_reference_frame + * reconstruction_reference_frame The aim of this convention is to support users with contextualizing which reference frame each instance (coordinate system) is. If needed, instances of :ref:`NXtransformations` diff --git a/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml index 88b2cd8b87..edd9849446 100644 --- a/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml @@ -3,7 +3,7 @@ - + - Base class documenting the configuration used for a tool of the paraprobe-toolbox. + Application definition for a (configuration) file of a tool from the paraprobe-toolbox. - The paraprobe-toolbox is a collection of open-source software tools for performing + The paraprobe-toolbox is a collection of open-source tools for performing efficient analyses of point cloud data where each point can represent atoms or (molecular) ions. A key application of the toolbox has been for research in the field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): @@ -38,99 +38,88 @@ properties and enabling analyses of the spatial arrangement of and inter- sections between geometric primitives, the software can equally be used for analyzing data in Materials Science and Materials Engineering. - - The configuration and results of a run of a tool from the toolbox is documented - using binary container formats. Currently, paraprobe-toolbox uses the - Hierarchical Data Format 5 (HDF5). - - - - Internal identifier used by the tool to refer to an analysis (aka simulation - id). - - - - - Possibility for leaving a free-text description about this analysis. - - Although offered here for convenience we strongly encourage to - parameterize such descriptions as much as possible to support - reusage and clearer communication. - - - - - - Specification of the tomographic reconstruction to use for this analysis. - - Typically, reconstructions in the field of atom probe tomography are communicated - via files which store at least reconstructed ion positions and mass-to-charge-state-ratio - values. Container files like HDF5 though can store multiple reconstructions. - Therefore, the position and mass_to_charge concepts point to specific instances - to use for this analysis. - - - - Name of the node which resolves the reconstructed ion position - values to use for this analysis. - - - - - Name of the node which resolves the mass-to-charge-state-ratio - values to use for this analysis. - - - - - - Specification of the ranging definitions to use for this analysis. - - Ranging is the process of labeling time-of-flight data with so-called iontypes - (aka ion species). Ideally, iontypes specify the most likely (molecular) ion - that is assumed to have been evaporated given that its mass-to-charge-state ratio - lies within the specific mass-to-charge-state-ratio value interval of the iontype. - - The so-called UNKNOWNTYPE iontype represents the null model of an ion - that has not been ranged (for whatever reasons). - The identifier of this special iontype is always the reserved value 0. - - - - Name of the (parent) node directly below which (in the hierarchy) - the ranging definition for (molecular) ions are stored. - + + + - - - - Specification of the triangulated surface mesh to use for this analysis. - - Such a surface mesh can be used to define the edge of the reconstructed - volume to account for finite size effects. - - - - - - Specification of the point-to-triangulated-surface-mesh distances to - use for this analysis. - - + - Absolute path in the (HDF5) file that points to the distance values. - The tool assumes that the values are stored in the same order as - points (ions). + A specific configuration to achieve a processing result - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - - diff --git a/contributed_definitions/NXapm_paraprobe_tool_parameters.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_parameters.nxdl.xml new file mode 100644 index 0000000000..7305242e88 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_tool_parameters.nxdl.xml @@ -0,0 +1,114 @@ + + + + + + Base class documenting parameters for processing used by all tools of the + paraprobe-toolbox. + + + + Internal identifier used by the tool to refer to an analysis. + Simulation ID an alias. + + + + + Possibility for leaving a free-text description about this analysis. + + Although offered here for convenience, we strongly encourage to + parameterize such descriptions as much as possible to support + reusage and clearer communication. + + + + + + Specification of the tomographic reconstruction to use for this analysis. + + Typically, reconstructions in the field of atom probe tomography are communicated + via files which store at least reconstructed ion positions and mass-to-charge-state-ratio + values. Container files like HDF5 though can store multiple reconstructions. + Therefore, the position and mass_to_charge concepts point to specific instances + to use for this analysis. + + + + Name of the node which resolves the reconstructed ion position + values to use for this analysis. + + + + + Name of the node which resolves the mass-to-charge-state-ratio + values to use for this analysis. + + + + + + Specification of the ranging definitions to use for this analysis. + + Ranging is the process of labeling time-of-flight data with so-called iontypes + (aka ion species). Ideally, iontypes specify the most likely (molecular) ion + that is assumed to have been evaporated given that its mass-to-charge-state ratio + lies within the specific mass-to-charge-state-ratio value interval of the iontype. + + The so-called unknown_type iontype represents the null model of an ion + that has not been ranged (for whatever reasons) or is not rangeable. + The identifier of this special iontype is always the reserved value 0. + + + + Name of the (parent) node directly below which (in the hierarchy) + the ranging definition for (molecular) ions are stored. + + + + + + Specification of the triangulated surface mesh to use for this analysis. + + Such a surface mesh can be used to define the edge of the reconstructed + volume to account for finite size effects. + + + + + Specification of the point-to-triangulated-surface-mesh distances to + use for this analysis. + + + + Absolute path in the (HDF5) file that points to the distance values. + The tool assumes that the values are stored in the same order as + points (ions). + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_tool_process.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_process.nxdl.xml new file mode 100644 index 0000000000..a42c6f31fb --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_tool_process.nxdl.xml @@ -0,0 +1,68 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The number of entries in the mask. + + + + + Base class documenting a processing step within a tool of the paraprobe-toolbox. + + + + Possibility for leaving a free-text description about this analysis. + + + + + A bitmask which identifies all ions considered in the analysis. + + + + Number of ions covered by the mask. + By default, the total number of ions in the dataset. + + + + + Number of bits assumed matching on a default datatype. + + + + + The mask. The length of the mask is an integer multiple of bitdepth. + In such case, padded bits are set to 0. + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml index 97d18942f8..485397ea00 100644 --- a/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml @@ -3,7 +3,7 @@ - - + - Base class documenting the results obtained with a tool of the paraprobe-toolbox. + Application definition for storing processing results of a tool from the paraprobe-toolbox. The paraprobe-toolbox is a collection of open-source tools for performing efficient analyses of point cloud data where each point can represent atoms or @@ -44,44 +38,69 @@ symbols: properties and enabling analyses of the spatial arrangement of and inter- sections between geometric primitives, the software can equally be used for analyzing data in Materials Science and Materials Engineering. - - The configuration and results of a run of a tool from the toolbox is documented - using binary container formats. Currently, paraprobe-toolbox uses the - Hierarchical Data Format 5 (HDF5). - - The paraprobe coordinate system is the reference *NXcoordinate_system* - for each geometric primitive. - - - - Possibility for leaving a free-text description about this analysis. - - - - - A bitmask which identifies all ions considered in the analysis. - - - - Number of ions covered by the mask. - By default, the total number of ions in the dataset. - + + + - + - Number of bits assumed matching on a default datatype. + A specific processing result - - - - The mask. The length of the mask is an integer multiple of bitdepth. - In such case, padded bits are set to 0. - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If used, metadata of at least the person who performed this analysis. + + + + + + + + + + + + + + + + + + + + + + + + + - diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml deleted file mode 100644 index fd3654dc43..0000000000 --- a/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml +++ /dev/null @@ -1,80 +0,0 @@ - - - - - - - Application definition for a configuration file of the paraprobe-transcoder tool. - - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. - - - - - - - - - - - - - - - - - - - - - - - Specification of the ranging definition file to use for this analysis. - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml deleted file mode 100644 index 806d27f650..0000000000 --- a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml +++ /dev/null @@ -1,217 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of ions in the reconstruction. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. - - - - - Total number of integers in the supplementary XDMF topology array. - - - - - Number of entries - - - - - Application definition for results files of the paraprobe-transcoder tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. - The purpose and need of the paraprobe-transcoder tool is to create a standardized representation - of reconstructed position and mass-to-charge-state-ratio values surplus other pieces of information - to enable working with atom probe data in reconstruction space in the paraprobe-toolbox. - This includes ranging definitions which map mass-to-charge-state ratio values onto iontypes. - - So far the atom probe community has not yet agreed upon a comprehensive standardization on how to - exchange information especially when it comes to the communication of configurations and results - from analyses of atom probe data. Instead, different simplistic file formats are used, such as POS, ePOS, - APT, or RNG and RRNG. None of these formats, though, are self-descriptive, standardize, or document - their origin and thus the sequence in which the file was generated during an analysis. - - Paraprobe-transcoder solves this limitation by interpreting the information content in such files - and standardize the representation prior injection into the scientific data analysis tools of the toolbox. - Therefore, the here proposed set of NeXus base classes and application definitions can be a useful - starting point for the atom probe community to take advantage of standardized information - exchange and improve the here proposed classes and concepts to become more inclusive. - - Paraprobe-transcoder uses a Python library developed based on efforts by members of the - global atom probe community `International Field Emission Society (IFES) Atom Probe Technical Committee (APT TC) <https://www.github.com/atomprobe-tc/ifes_apt_tc_data_modeling>`_. This library offers the - actual low-level I/O operations and respective information interpretation of above-mentioned file formats. - - - - - - - - - - - - - - - - - - - - - By default the entire reconstructed volume is processed. - In this case, using window is also equivalent to an - NXspatial_filter that specified a window *entire_dataset*. - - - - - - - - - - Mass-to-charge-state-ratio values. - - - - - - - - - - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - - - - - - - - Defines in which reference frame the positions are defined. - - - - - - - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstruction. The XDMF datatype - is here 1, the number of primitives 1 per triplet, the last integer - in each triplet is the identifier of each point starting from zero. - - - - - - - - - - - Details about how peaks are interpreted as ion types or not. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If used, metadata of at least the person who performed this analysis. - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index 96238c7342..9b3cfb7ce1 100644 --- a/contributed_definitions/NXdelocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -24,39 +24,39 @@ - The symbols used in the schema to specify e.g. dimensions of arrays. + The symbols used in the schema to specify e.g. dimensions of arrays. - Number of points/objects. + Number of points/objects. - Number of mark data per point/object. + Number of mark data per point/object. - Number of atoms in the whitelist. + Number of atoms in the whitelist. - Number of isotopes in the whitelist. + Number of isotopes in the whitelist. - Base class of the configuration and results of a delocalization algorithm. - - Delocalization is used to distribute point-like objects on a grid to obtain - e.g. smoother count, composition, or concentration values of scalar fields - and compute gradients of these fields. + Base class of the configuration and results of a delocalization algorithm. + + Delocalization is used to distribute point-like objects on a grid to obtain + e.g. smoother count, composition, or concentration values of scalar fields + and compute gradients of these fields. - Details about the grid on which the delocalization is applied. + Details about the grid on which the delocalization is applied. - The weighting model specifies how mark data are mapped to a weight per - point/object. + The weighting model specifies how mark data are mapped to a weight per + point/object. - As an example from the research field of atom probe points/objects are (molecular) ions. - Different methods are used for weighting ions: - - * default, points get all the same weight 1., which for atom probe is equivalent - to (molecular) iontype-based delocalization. - * element, points get as much weight as they have atoms representing a nuclide - with a proton number that is matching to a respective entry in whitelist. - In atom probe jargon, this means atomic_decomposition. - * isotope, points get as much weight as they have atoms representing a nuclides - from a respective entry in whitelist. - In atom probe jargon, this means isotope_decomposition. + As an example from the research field of atom probe points/objects are (molecular) ions. + Different methods are used for weighting ions: + + * default, points get all the same weight 1., which for atom probe is equivalent + to (molecular) iontype-based delocalization. + * element, points get as much weight as they have atoms representing a nuclide + with a proton number that is matching to a respective entry in whitelist. + In atom probe jargon, this means atomic_decomposition. + * isotope, points get as much weight as they have atoms representing a nuclides + from a respective entry in whitelist. + In atom probe jargon, this means isotope_decomposition. @@ -109,10 +109,10 @@ and the interpretation model that to consider carbon atoms or carbon ions--> - A list of nuclides based on which to evaluate the weight. Nuclides need to exist in the nuclide table. - Values are nuclide (isotope) hash values using the following hashing rule :math:`H = Z + N \cdot 256` - with :math:`Z` the number of protons and :math:`N` the number of neutrons of the nuclide. - For elements set :math:`N` to zero. + A list of nuclides based on which to evaluate the weight. Nuclides need to exist in the nuclide table. + Values are nuclide (isotope) hash values using the following hashing rule :math:`H = Z + N \cdot 256` + with :math:`Z` the number of protons and :math:`N` the number of neutrons of the nuclide. + For elements set :math:`N` to zero. @@ -120,9 +120,9 @@ and the interpretation model that to consider carbon atoms or carbon ions--> - Attribute data for each member of the point cloud. For APM these are the - iontypes generated via ranging. The number of mark data per point is 1 - in the case for atom probe. + Attribute data for each member of the point cloud. For APM these are the + iontypes generated via ranging. The number of mark data per point is 1 + in the case for atom probe. @@ -131,10 +131,10 @@ and the interpretation model that to consider carbon atoms or carbon ions--> - Weighting factor with which the integrated intensity per grid cell is - multiplied specifically for each point/object. For APM the weight are - positive integer values, specifically the multiplicity of the ion, - according to the details of the weighting_method. + Weighting factor with which the integrated intensity per grid cell is + multiplied specifically for each point/object. For APM the weight are + positive integer values, specifically the multiplicity of the ion, + according to the details of the weighting_method. diff --git a/contributed_definitions/NXem_calorimetry.nxdl.xml b/contributed_definitions/NXem_calorimetry.nxdl.xml index a095cc0780..ad838cb623 100644 --- a/contributed_definitions/NXem_calorimetry.nxdl.xml +++ b/contributed_definitions/NXem_calorimetry.nxdl.xml @@ -87,13 +87,13 @@ are aligned with what and how to name things--> Programs and libraries representing the computational environment - + - + @@ -114,7 +114,7 @@ are aligned with what and how to name things--> - + diff --git a/contributed_definitions/NXisocontour.nxdl.xml b/contributed_definitions/NXisocontour.nxdl.xml index 7e8434bc72..eace731923 100644 --- a/contributed_definitions/NXisocontour.nxdl.xml +++ b/contributed_definitions/NXisocontour.nxdl.xml @@ -24,37 +24,37 @@ - The symbols used in the schema to specify e.g. dimensions of arrays. + The symbols used in the schema to specify e.g. dimensions of arrays. - The dimensionality of the description. + The dimensionality of the description. - Base class for describing isocontouring/phase-fields in Euclidean space. - - Iso-contouring algorithms such as Marching Cubes and others are frequently - used to segment d-dimensional regions at crossings of a threshold value, - the so-called isovalue. - - In Computational Materials Science phase-field methods are frequently used. - Phase-field variables are discretized frequently using regular grids. - - Isocontour algorithms are often used in such context to pinpoint the - locations of microstructural features from this implicit phase-field- - variable-value-based description. - - One of the key intentions of this base class is to provide a starting point - for scientists from the phase-field community (condensed-matter physicists, - and materials engineers) to incentivize that also phase-field (and other) - simulation data can take advantage of NeXus base class to improve - interoperability. + Base class for describing isocontouring/phase-fields in Euclidean space. + + Iso-contouring algorithms such as Marching Cubes and others are frequently + used to segment d-dimensional regions at crossings of a threshold value, + the so-called isovalue. + + In Computational Materials Science phase-field methods are frequently used. + Phase-field variables are discretized frequently using regular grids. + + Isocontour algorithms are often used in such context to pinpoint the + locations of microstructural features from this implicit phase-field- + variable-value-based description. + + One of the key intentions of this base class is to provide a starting point + for scientists from the phase-field community (condensed-matter physicists, + and materials engineers) to incentivize that also phase-field (and other) + simulation data can take advantage of NeXus base class to improve + interoperability. - The dimensionality of the space in which the isocontour is embedded. + The dimensionality of the space in which the isocontour is embedded. @@ -64,12 +64,12 @@ - The discretized grid on which the iso-contour algorithm operates. + The discretized grid on which the iso-contour algorithm operates. - The threshold or iso-contour value. + The threshold or iso-contour value. diff --git a/contributed_definitions/NXmatch_filter.nxdl.xml b/contributed_definitions/NXmatch_filter.nxdl.xml index 22abd59174..757e61c02d 100644 --- a/contributed_definitions/NXmatch_filter.nxdl.xml +++ b/contributed_definitions/NXmatch_filter.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -33,16 +33,16 @@ - Base class of a filter to select members of a set based on their index, identifier, or value. + Base class of a filter to select members of a set based on their identifier. Definition of the logic what the filter yields: - Whitelist specifies which entries with said value to include. - Entries with all other values will be excluded. - Blacklist specifies which entries with said value to exclude. - Entries with all other values will be included. + * Whitelist specifies which entries with said value to include. + Entries with all other values will be excluded. + * Blacklist specifies which entries with said value to exclude. + Entries with all other values will be included. diff --git a/contributed_definitions/NXmicrostructure_score_config.nxdl.xml b/contributed_definitions/NXmicrostructure_score_config.nxdl.xml index 12ccf6dfb9..32a66a1f79 100644 --- a/contributed_definitions/NXmicrostructure_score_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_score_config.nxdl.xml @@ -101,17 +101,19 @@ - + Dimensionality of the simulation. + + - + A qualifier whether the sample is a real one or a virtual one. @@ -145,7 +147,7 @@ exists: optional--> Programs and libraries representing the computational environment - + @@ -186,9 +188,9 @@ SecondOrderThermalExpCoeff--> Which model should be used to generate a starting microstructure. - * cuboidal, a regular array of equally shaped cuboidal grains - * poisson_voronoi, a discretized poisson voronoi - * ebsd, a microstructure synthesized based on a simulated or measured EBSD orientation map + * cuboidal, a regular array of equally-shaped cuboidal grains + * poisson_voronoi, a discretized Poisson Voronoi tessellation + * ebsd, a microstructure synthesized based on a simulated or a measured EBSD orientation map * damask, the result of a simulation from `DAMASK <https://damask-multiphysics.org>`_. @@ -245,11 +247,7 @@ SecondOrderThermalExpCoeff--> EBSD orientation map when model is cuboidal or poisson. - - - - - + @@ -272,18 +270,15 @@ SecondOrderThermalExpCoeff--> a previously performed DAMASK simulation. - - - - - + Phenomenological model according to which recrystallization nuclei - are placed into the domain whose growth is studied with the simulation. + are placed into the domain. Studying the growth of these nuclei + is the main purpose of a SCORE simulation. @@ -300,7 +295,9 @@ SecondOrderThermalExpCoeff--> - According to which model will the nuclei start to grow. + According to which model will the nuclei start to grow: + + * site_saturation, instantaneously @@ -349,7 +346,7 @@ SecondOrderThermalExpCoeff--> Model for the assumed mobility of grain boundaries with different disorientation - implemented as parameterized Turnbull's model for thermally-activated + implemented as a parameterized Turnbull's model for thermally-activated grain boundary migration. @@ -618,10 +615,9 @@ like showing a r(t) plot--> - Criteria which enable to stop the simulation in a controlled manner. + Criteria which enable to stop the simulation in a controlled manner + and assure a stable numerical integration. Whichever criterion is fulfilled first stops the simulation. - Furthermore, numerical configuration required to achieve - a stable numerical integration. @@ -656,9 +652,10 @@ like showing a r(t) plot--> including the assignment of grains and cells surplus the state of the recrystallization front. - Despite these front data make up for approximately one order of magnitude - less cells than represented in the domain, more numerical data have to be - collected for each cell in the front than just a grain identifier. + Despite these, data about the cells that define the recrystallization front make up + for approximately one order of magnitude less cells than present in the domain. + For the cells in this front, though, more data have to be collected + than just a grain identifier. diff --git a/contributed_definitions/NXmicrostructure_score_results.nxdl.xml b/contributed_definitions/NXmicrostructure_score_results.nxdl.xml index b456748e3f..f9f6c8b864 100644 --- a/contributed_definitions/NXmicrostructure_score_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_score_results.nxdl.xml @@ -136,7 +136,7 @@ inspect comments behind NXmicrostructure--> Programs and libraries representing the computational environment - + @@ -379,10 +379,14 @@ unit: NX_ANY dim: (n_summary_stats, 3, 3) the typically storage-costlier snapshot data--> - + + + Simulated physical time for this snapshot. + + - Iteration or increment counter. + Iteration or increment counter of this snapshot. @@ -443,7 +447,7 @@ the typically storage-costlier snapshot data--> - Volume of each grain accounting also for partially transformed cells. + Volume of each grain (partially transformed cells are accounted for). @@ -487,12 +491,17 @@ the typically storage-costlier snapshot data--> - Details about those cells which in this time step represent the discrete - recrystallization front. + Details about those cells which in this time step + represent the discrete recrystallization front. + + Each CA is processed by a team of OpenMP threads. Which cells are currently in a halo region of threads. + + The halo region is a layer of cells about the sub-domain + of the simulation grid evolved by a thread. diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index 4d032e2d58..0a0878f449 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -24,55 +24,55 @@ - The symbols used in the schema to specify e.g. dimensions of arrays. + The symbols used in the schema to specify e.g. dimensions of arrays. - Cardinality of the set. + Cardinality of the set. - Number of numerical labels per object. + Number of numerical labels per object. - Number of categorical labels per object. + Number of categorical labels per object. - Total number of similarity groups aka features/clusters. + Total number of similarity groups aka features/clusters. - Base class to store results obtained from applying a similarity grouping (clustering) algorithm. - - Similarity grouping algorithms are segmentation or machine learning algorithms for - partitioning the members of a set of objects (e.g. geometric primitives) into - (sub-)groups aka features of different kind/type. A plethora of algorithms exists. - - This base class considers metadata and results of having a similarity grouping - algorithm applied to a set in which objects are either categorized as noise - or belonging to a cluster, i.e. members of a cluster. - The algorithm assigns each similarity group (feature/cluster) at least one - identifier (numerical or categorical labels) to distinguish different cluster. + Base class to store results obtained from applying a similarity grouping (clustering) algorithm. + + Similarity grouping algorithms are segmentation or machine learning algorithms for + partitioning the members of a set of objects (e.g. geometric primitives) into + (sub-)groups aka features of different kind/type. A plethora of algorithms exists. + + This base class considers metadata and results of having a similarity grouping + algorithm applied to a set in which objects are either categorized as noise + or belonging to a cluster, i.e. members of a cluster. + The algorithm assigns each similarity group (feature/cluster) at least one + identifier (numerical or categorical labels) to distinguish different cluster. - Number of members in the set which gets partitioned into features. + Number of members in the set which gets partitioned into features. - How many numerical labels does each feature have. + How many numerical labels does each feature have. - How many categorical labels does each feature have. + How many categorical labels does each feature have. - Which numerical index is the first to be used to label a feature. - - The value should be chosen in such a way that special values can be resolved: - * index_offset - 1 indicates that an object belongs to no cluster. - * index_offset - 2 indicates that an object belongs to the noise category. - Setting for instance index_offset to 1 recovers the commonly used - case that objects of the noise category get values to -1 and unassigned - points to 0. Numerical identifier have to be strictly increasing. + Which numerical index is the first to be used to label a feature. + + The value should be chosen in such a way that special values can be resolved: + * index_offset - 1 indicates that an object belongs to no cluster. + * index_offset - 2 indicates that an object belongs to the noise category. + Setting for instance index_offset to 1 recovers the commonly used + case that objects of the noise category get values to -1 and unassigned + points to 0. Numerical identifier have to be strictly increasing. - Matrix of numerical label for each member in the set. - For classical clustering algorithms this can for instance - encode the indices_cluster. + Matrix of numerical label for each member in the set. + For classical clustering algorithms this can for instance + encode the indices_cluster. @@ -106,7 +106,7 @@ results for the object set--> - Matrix of categorical attribute data for each member in the set. + Matrix of categorical attribute data for each member in the set. @@ -115,31 +115,31 @@ results for the object set--> - In addition to the detailed storage which objects were grouped to which - feature/group summary statistics are stored under this group. + In addition to the detailed storage which objects were grouped to which + feature/group summary statistics are stored under this group. - Total number of features categorized as unassigned. + Total number of features categorized as unassigned. - Total number of features categorized as noise. + Total number of features categorized as noise. - Total number of features. + Total number of features. - Array of numerical identifier of each feature. + Array of numerical identifier of each feature. @@ -147,7 +147,7 @@ when knowing total, noise, and unassigned.--> - Array of number of objects for each feature. + Array of number of objects for each feature. diff --git a/contributed_definitions/NXspatial_filter.nxdl.xml b/contributed_definitions/NXspatial_filter.nxdl.xml index 0460ad9efd..68367062a7 100644 --- a/contributed_definitions/NXspatial_filter.nxdl.xml +++ b/contributed_definitions/NXspatial_filter.nxdl.xml @@ -24,7 +24,7 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -53,7 +53,8 @@ n_facets: Number of facets for polyhedra.--> Base class for a spatial filter for objects within a region-of-interest (ROI). - Objects can be points or objects composed from other geometric primitives. + Objects can be points, objects composed from other geometric primitives, + or objects. @@ -66,15 +67,10 @@ n_facets: Number of facets for polyhedra.--> All other objects are excluded. * bitmask, a boolean array whose bits encode with 1 which objects are included. Bits set to zero encode which objects are excluded. - Users of python can use the bitfield operations - of the numpy package to work with bitfields. + + Users of python can use the bitfield operations of the numpy package to work with bitfields. + Multiple instances of NXcg base classes are used to compose a union_of_primitives. - diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml index ef64b4843b..29d2399beb 100644 --- a/contributed_definitions/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -21,27 +21,33 @@ # # For further information, see http://www.nexusformat.org --> - - + - Base class of a filter to sample members in a set based on their indices, identifier, or value. + Base class of a filter to sample members in a set based on their indices. + + The filter defines three parameters: The minimum, the increment, and the maximum + index of values to include of a sequence :math:`[i_0, i_0 + 1, i_0 + 2, \ldots, i_0 + \mathcal{N}] with i_0 \in \mathcal{Z}` + of indices. The increment controls which n-th index (value) to take. + + Take as an example a dataset with 100 indices (aka entries). Assume that the indices start at zero, + i.e., index_offset is 0. Assume further that min, increment, max are set to 0, 1, and 99, respectively. + In this case the filter will yield all indices. Setting min, increment, max to 0, 2, and 99, respectively + will yield each second index value. Setting min, increment, max to 90, 3, and 99 respectively will yield + each third index value beginning from index values 90 up to 99. - + + + Minimum index. + + + + + Increment. + + + - Triplet of the minimum, the increment, and the maximum identifier to - include of a sequence :math:`[i_0, i_0 + 1, i_0 + 2, \ldots, i_0 + \mathcal{N}] with i_0 \in \mathcal{Z}` - of identifier. The increment controls which n-th identifier (value) to take. - - Take as an example a dataset with 100 identifier (aka entries). Assume that - the identifier start at zero, i.e. identifier_offset is 0). Assume further - that min_incr_max is set to [0, 1, 99]. In this case the filter will - yield all identifier. Setting min_incr_max to [0, 2, 99] will take each - second identifier. Setting min_incr_max to [90, 3, 99] will take each - third identifier beginning from identifier 90 up to 99. + Maximum index. - - - From 5ae979a6146e21f8d601457af172a1af99d1c087 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Mon, 20 Oct 2025 22:00:01 +0200 Subject: [PATCH 1010/1012] Reset NXtransmission and NXoptical_polarizer to commits before today --- .../NXoptical_polarizer.nxdl.xml | 5 --- .../NXtransmission.nxdl.xml | 31 ------------------- 2 files changed, 36 deletions(-) diff --git a/contributed_definitions/NXoptical_polarizer.nxdl.xml b/contributed_definitions/NXoptical_polarizer.nxdl.xml index c200c96bf4..9536b3896c 100644 --- a/contributed_definitions/NXoptical_polarizer.nxdl.xml +++ b/contributed_definitions/NXoptical_polarizer.nxdl.xml @@ -167,13 +167,8 @@ A draft of a new base class to describe an optical polarizer -<<<<<<< HEAD:contributed_definitions/NXoptical_polarizer.nxdl.xml If the device has a coating describe the material and its properties. diff --git a/contributed_definitions/NXtransmission.nxdl.xml b/contributed_definitions/NXtransmission.nxdl.xml index ce204d5916..03d5e58ee8 100644 --- a/contributed_definitions/NXtransmission.nxdl.xml +++ b/contributed_definitions/NXtransmission.nxdl.xml @@ -69,11 +69,7 @@ Draft NeXus application definition for transmission experiments--> Unique identifier of the experiment, such as a (globally persistent) -<<<<<<< HEAD unique identifier. -======= - unique identifier. ->>>>>>> upstream/main * The identifier is usually defined by the facility or principle investigator. @@ -120,29 +116,6 @@ Draft NeXus application definition for transmission experiments--> Name of the affiliation of the user at the point in time when the experiment was performed. -<<<<<<< HEAD -======= - - - - - Street address of the user's affiliation. - - - - - Email address of the user. - - - - - Author ID defined by research ID services, e.g. orcid (https://orcid.org/). - - - - - Telephone number of the user. ->>>>>>> upstream/main @@ -188,11 +161,7 @@ Draft NeXus application definition for transmission experiments--> Wavelength value(s) used for the measurement. -<<<<<<< HEAD An array of 1 or more elements. Length defines N_wavelenghts -======= - An array of 1 or more elements. Length defines N_wavelengths ->>>>>>> upstream/main From 8cdcdc3afda9a914506b94c936555e09d4c2a81e Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Mon, 20 Oct 2025 22:57:57 +0200 Subject: [PATCH 1011/1012] Sync up that the hash rule for nuclid_hash defined in NXdelocalization and NXatom match up --- contributed_definitions/NXdelocalization.nxdl.xml | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/contributed_definitions/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index 9b3cfb7ce1..a555db20f2 100644 --- a/contributed_definitions/NXdelocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -110,9 +110,7 @@ and the interpretation model that to consider carbon atoms or carbon ions--> A list of nuclides based on which to evaluate the weight. Nuclides need to exist in the nuclide table. - Values are nuclide (isotope) hash values using the following hashing rule :math:`H = Z + N \cdot 256` - with :math:`Z` the number of protons and :math:`N` the number of neutrons of the nuclide. - For elements set :math:`N` to zero. + Values are nuclide (isotope) hash values using the hashing rule defined in :ref:`NXatom`. From 4edc90fae5b34c783a8723d9ca63f48449081d97 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Mon, 20 Oct 2025 23:00:10 +0200 Subject: [PATCH 1012/1012] Fix typos in dispersive material --- contributed_definitions/NXdispersive_material.nxdl.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/NXdispersive_material.nxdl.xml b/contributed_definitions/NXdispersive_material.nxdl.xml index 3b9cca4d56..1726fc1449 100644 --- a/contributed_definitions/NXdispersive_material.nxdl.xml +++ b/contributed_definitions/NXdispersive_material.nxdl.xml @@ -106,7 +106,7 @@ This should be the only dispersion available for isotropic materials. For uniaxial materials this denotes the ordinary axis. For biaxial materials this denotes the x axis or epsilon 11 tensor element - of the diagionalized permittivity tensor. + of the diagonalized permittivity tensor. @@ -143,7 +143,7 @@ This should only be filled for biaxial materials. - It denotes the epsilon 22 direction of the diagionalized + It denotes the epsilon 22 direction of the diagonalized permittivity tensor. @@ -183,7 +183,7 @@ This should only be filled for uniaxial or biaxial materials. For uniaxial materials this denotes the extraordinary axis. For biaxial materials this denotes the epsilon 33 tensor element - of the diagonalized perimittivity tensor. + of the diagonalized permittivity tensor.

=^=bkL$gpupv?0e)PMJA}-dMGe$vcV6I})KxOQN%Ku~OxyezNAAR46O`oXeLPJ3 zX1i3C$dHT8L{4Y3yyspq2{d}juLY8fczvdFt??5!Fu9ka>2sq*f=qhyvxm2s(c<}g zcmMoe>C3vNwPi7#Q`h053bi)v`J*#C5zlA8(X*m25y`P(=8sTG@q;czWgg-3gps^C zc-77)`AqmiZ}tCMh}aPXp#zp-^?=DD5 zND2ZXARPT{bKl;}oBgog z+3(buIcLtC^E?!WC;J0UiD=Py$N7${uYkGxr6xXaN>0_>aox&lLlb$NUD z12yt75}hFW7aiXWiG@(=4=R!_bd3PMA*~bh$M1n(KltC)wmJ25tli^gDjDNl^AH z5+AnT8PJt;0C+Joibqi`K`iJf&iI7I!aMYcSo6LLaZ`f3m~!!ScRz|v7u<7h+0D(R zGGy42p#~Ifp{pl5mCe5|OE;cgvW{PEn(49Kp3BgkyFs(cum4WAk7mWe_(S9EHW)4- zdU|?(+8qx7DgfX~IideA-I@$o{YoUOW71?i)0ADGBn&05d#T2V)z7{+*KMYZ_hZNT zxnH~9?*dnO5ydH*%=$2XN7=CrfA;}+8Ywr$aHHqk@Sx zT_w_F8*D2&u>y_aS1-KRSJxo^!(qiY_e`Y$;xVbXGj z$Ni?gx_6(%HcI&Oz$Ruh?Cak4{OAGHyyzJ-mpXUcCQL3f2EY|s*y@Yh8S<0arH!uL z+U|g7#w^niAjfmnS$0Tz3ObC&(CLhJ-E(pghzfieC=ywL@sVx*>WhfTqi_@UJJ*$> z!>vrkKWd0_*ZfU}UlJNb3xA`0B)&;zGK6?2_{^l`s(|$3uv#M`!%AiV>y}oo$`Edg zT)f2yxleI5q2c?4JoJ5xYB=R%Ed%u*{*oA$DbaoY?j~ippWSw9pob4M3g+h`N*%>! z%tNo6g5P=h8?E@Ibsp@5GXvPBM6CPnrF8<0L3$hfb3G9haCVBRhF7Y2pB7hqcY5bb zez7zZcNGR@-*ZB}63V=az38Q0UCWS~o08UW0+j7Wd3=`(ufDEj93OseFM7)mbdp*5 zP1RxspcLXfCh!8c*e5H!k&Xn`QaVjqSOR?S#gFJ^pZV0b_FeHA`Y;Z;^sC_ZZQ{S? zPFzwKMw(w$h8CP-=sX-0OcF?&BH6MIRe&?7$&o}&Zvw`m6KewK!_UD^*)PMXK3NLG z^o3;xx);0(-oJ%rRd+iuh67MLFf-@rr=UY1_W;0n2nQw+Ad`WfP86Q|z7#?D7=PW* zCq1@si3E#8jYLC8NXY(l=OTkfKk~+di`bcNj*qdvTVmdQkF`Ip-SlZ~2qF}kbz3hY zB4MS)E{mnt{)XQD_i!(81D5tJ$prEEKYDDe$amFGuKz8`1}uh{U-h3_%@up*9rbjms<2R)K4JxpbMMCO(s`ZG;zgcXKcAik&{IMZV zmQI#&tRc58EibxRp$5iL))AW&Pw%_X$$Bes^7o8*Y#z~(IV5*P`%*x5sy-ek9=k`x z@XCtFX6OUpUE38;^!69-JMIp9(y!}mJL3{7sIs9oyn9kFy1fm1v6-(Rzx|2DrT z`!Hhm2>L(gOnL7La=9Q@?HDmmOV$aoh|U_;m3jhcM4(|HxW+;Pdwo`tcYlR-^wcVsWhwmgova$c!#UDh^gIv~^9(CEM*>W9{#vJ=m}Rt}VBf0i;_IhxmVFJm+wZ zkCU4>M$K9lndWX#OPUYv3`2XHwUthSUMa8GEkW4tLLm>`7F^nZ=a+DE7p>E=TUq+ufs|_6U(^8=X5$to;!>Xfp5v!7(SlE8$u5FP0=ErW-nfI^oFos)Ft|L^togWlh!D`2BznU!G63N)TowCzBA{gAR+ zX2%S7mh^5G5ebYo7MDHt+2?`Q^K&G|tBb96qDpxi&eLmM6!>K|iH=Y(aQGp_s%t$s_%cpTmlXRcgkJ^K_O4cN*PSearbqXIv16VmTgdH z?(4NKm_6*tc6Z_k!njP+SHAQ>0jt%8hdiOX*LW?9X)kVH;gzkq=U!tTi znUPq*{MyjVdyft35zRX-#6?59f)8m6HKdrCRY(c(M}DLWm(zddR7P70oQzmhocEho zE??EiP#;S8$a@;N01D^wx&4Ysnt-iaY;JlaH=@b?4IL>9Qifj!q|bx+(bclr-y^K% zWeQhuAf$Jr&I*mtRMBvsa%$r5ug|T;ex0Iv3AAW`rQ1K0jcp|9q-!0%G#@^6kw%}Z zoTBs2r7rNa$8=BZyy^2LVD8gBpnL5g`*H~%3X%-4xVUpo*}H@(ey`26>Mtt8sDU#L~{4({Hd781M^FelyQSsUFF?O>g(my+Q_y{R1jInlNOmYC>3wRL`S0U3qy z%zwRGLDA`fVp6OECz#cho(3)Kt4YuWQuGa&RXca$(j{6J^fAv;pH+ z4f`px6b){wN+KyMJb5f>lbuGsN%*DMbF<@>ON^hc+3JrMq_}(i9?kj05e9Nbk(eB( zu8$tEP}d{KG@1U$g~vhVs$$>MNq2uNb08?!nXQiN>7A=L$A>=CBMrr@=Y6aZi+p}h zpZ350j4-5Q_l2zK@iBDv32Gmi(+s4h4t(Q+?=4stEPf=Ykd7WLmud7qCWr~Abi6H~ z0oNVefk!V_&%^NsaNnC+XFPt8_>`i*iior#JO1hWnmogINsF~21?KaT**)D>J{*qXfpxC^E#`=6BO&Z4N`)48~*oqZIBfwO$B@`b9# zm+(`z(0;7VpROQ;sA5>Q1`yyRK2LBr1^%%~GIirSq_TV8Kn|<)CzB}|g4qUK(O3bC z=f6;i7!adJ7r^+UEdp~ZroI@E)I@iLI zI9%BiEoRYo8GQ~Z5igE5|J*b%=e{a8YS06ySBDaI7mJtdW@0bKx8|}VzCRP^wTpn2 z@Y@0;4-csz?z5k-=>)j6bI@p}-2dS;F*_l!1_p$UX9ZILJb4Sz=nCJ@{Q+SP_yJ(a zVf6et+6-cyH|n~{@mQMp`uvTa=7{Uc4Ny9yCgXty@ao8iMC^o zj0Fip5kuMFA*W4Bc#xa%6O1=u89s7V8cJ0pm;=l_Fn;5c){51VLw~b!bU?z|@{7cZ z+}zGft0l}F-TmLAqUG*K>1;B$3&!iU=UXY(q3%lf#E%Vn5|88G0#DU9kHw^Dk~q|Y zkcn7gq3H?nCY4yDYXdByw0z2S-le&l@&g@1tKIrYz9ILb-6B9G^`!qMUisVoL%F(X z;GB_|&>_7~T}YAJbg(uTS$swIq5_?z#eGBbwC-|^UZ+!i5ET&%nB7=6RwZwJ7nq(X z3dl(lB_?Dw@wK>Oto>NqFDlp6?-!2QTkFG#{5tR1BBun*rKj%9s9GbnUpGNDwg zK3Y1)hfk&7gowfe-gur_(wBTa+|=&2x3@vV8`9wT&N787(?toWiTL96(mhp8APUSN?&F(-%kU zhe5;mlOA9Fm*{eNZ0MD z_m1(YfVM+mK%3jY{_MOw%e4zH|7%sxpbP300+f7?$b+G{bDL1fJsf!Gl5g|m$I0HtHpHOi*P6rHW#eA zqX$JR>SfWxv{YU(S~ec58&J&x!?)ZuZajGkzv0|v3AGz9)r=6uu|F9U#VNtkaM-QM zomMNqZ$CzuqTWumYv%v#>~sDp_O8i|&tBX3+a}byLJ9#5_G8$rGW%XpOj{=2?4F9R z!^@E06HfN*sdj7L2C|Gp6E5~e-8x+olh!m|0WGcbS@S{VQxV;Md75vZ{t@*gI1)R* zk0H%Pe|8sgm!iH+qIR@(&%?Q5SVF;;8^)TsxNfDeYk28FMnhzjv{TEXZ;BG-wo0Pe zy_anE#(jUzx?y;N_|{Ho&zoS^o3V77{mWR1W^X3y>(WHndYjN?wa5C%Ug<=Hjgk)K zbP@K!Ot{#E|J6;Me%OmkFKkOaH4m18n0sq>Z{P`Qy9S%}6bK=KamU;cwYPX@A!_ZG z_>P7uC6LL51yf;!C-)Y()f zc4q>wFASUKLgOPmImfKM2HVxegVs`~{?RlOlT*R3Dsz^CvWkd8DK&bJ3MX2sj<4BD zP{g?BLjEU?-Um76y3X~C&RI|xH1oUO-+4)#)vsrMj*SPAHjVvArE0aL;<_L8q`#$A+47m@Qs&4QpqUO>HvmNBnudpnKmrB$6%#!^2aZMB`7kbq&) zLKlHZ)8tbp_dlbDIj!qDoCuDe>t;fcNYolYqL~LI@=#r`;qzk3| zBr`b?umfBBNGu_%B;T?ASDMY$FP^ulf-^)-d09Mx2*PeGHUeF_krIWc^Cb##u&s*!xkiPG~_LGDSV}T-8!|( zxqouUgyoM-05gqMKQ`2|VYF(mfMFTsB`7^$Q})w16-XCQW?94wI+7sD7jR&t z-dKH#h}vWSAjSJbv|3HTAt|CWSxswM&3M@cS8fQ(b3IAk@gpxQhDb+gc}`oq)4x$6 zrv%Sw#sT^=FS;+qk?3ZlvNGwRz3SKJO-sAkY{efRoDYchw`_KrW-^ON?x?Nd)$f5-o13}eXV)#vCwN~gPVkK>MF8$GE@lfG${ z*{%wk@H(GJIaG~=S90N+y0O6xgYt(WTw`RE;F`VP$NfW%Zf>-9QhS{m=JkqVUGPJl zoSb%C#uC)m4sp$&6dqroP;=~3gST6PX+hJ&y3^Tk`r23_{-J%b_# zZO41l4pWR9M;uZ*DL;J7)_sTt%~r-YsBhY@-Sm!pp{XuPt^LegU0rzhTb#nk3^eGQ z2{}_>)MC;hTi9(Y!qDUgXMW9t%xn=RPZ?D)F{8LwWpH@hY^K<13?@GjWxrZPJDGk6 zr7vj}b~aATDz*C`r}ij2TuN1P2|R4@QhwsX(nJ6xe#Zb zHO`Ok()SIxUDbb}jL(O!5XjCiT0p{V7p8Y4dgAFh|I{^3$zrI@*)$($l-R~;Y;5lG z_Kj!$sbtcL-)a~gh_c{nRSDCh3W(jte!@EMNv77W+nsUE3hLALl7{nAQwz#crDDfV z_dtZIGd9W+b+f7K`xz99os%UV)I9qYn z>(_%wBfhciop8bY02R95^>Ql?jtdOOHXBO~uT%luHiqZ8NdWuY>b?+QnJ z475Nf6^<%$lgK6D=9WNftL1E*=!=HFAa0ZYAyYt6(;Iht8?3dbK*kw0W&>9UVxz;= zZz`a9!Sj{7sjXDE*lNCngPpuAT1HXO;Jl9;E+=-yQDhKYoqeB3lCt1kGs<>P^Ji29 zhuINdZvd3s+YH%PIFQ%Dx${6FE*pC+RX7YD!$|dZhWwE{*T@A|(hJfm4F_PK;RDlj zm8Op(Mwn_+@wIh?_w6ZfSQwQWR?33Yd>ZX0YtdwCOv^=QUXh#@qNa+BD!Q9k^CmjE zG9lZVvCnxKrOzVGwa$Mlkr1jkcN&ERE8p|=W`mEkBNSgZ5ieI0UTEy^fBByL$8&AP zF~!o$qnpK1UWql#R0(HnKcZ@pJ$NNk2^A4vt|cX0F6*+R+oox2mvbOHf8cs{&2{Y% zF3rVLbbiW=q%vi zFiNd?r|oh_rfi85L?M2-*;#pHNT-UrHLf~T%_1-x>Lxbu-E|=d&c+rb3@L?wi=go> zBo|K-5cl;l;dxWl*7ElUBI>-gecRK5`FCi_f}4fvZ9&fGcP*$F`t5v2`?3SXuu1k| zVyfoMfHI^z{J`^BVCoUQc6xUHZQ;|4+kSx3?S>n5TaXT3tcEKd{f~$w`r*kghDhHsDm$BMPjmT5G$?^C74ha7A zX|2&{03I3f;=oc+!0?~#=-)!r)B|quHgSVPuN##eJOim}Qh4we1PzbBbbuq0ay7)(c7-tH3Q$Yl(b!UpPy)tF>%gvnA&D>e#=8w8_<-{)`ksj4|w+|EF}p~ zZAwDmd4d@y^^y7wlp-d=CVlIMq9QuTm}w|l$N0g)n_T6j-t(*JCj`E(r*yhXjZrup z0XqZ!2>!6JFm%{K*mUiimbgQP0qSzCqlQxFh>h1pty>2=HdDyDp;k)U=PiNWJ`_?& zuz7sZOz9k+zfJTH84olr{B1(W`zr#QN|I1%&Nbi>k>Sm1b4BcV$IFz>RG?d#x1;sG z+BA726ddb|J{#C1)O#3|{8KVM4hIImI(Ux#EK73pvyB2L2jTjD4_(~yaK*XxN2Sy4 z!%A(QxigF>KwB$=aa>Xxst27mC*k=^XabGL*%B*_ zn(};u61g)4>-DZu9G7#ZQL;4GkmBK?vP!LzJyGScaZI*29G;?=$Ki2oCb20>Q}Mi- z>3Mo^_XE*N9L@Sg}0f?g2*ZG-MRe*`8(Ks$u;(( zGik+?^PIlI%@|?ZS5FVxze=387tHsjG-O+|gvt{eD0$@W3_qM!w6}@(y4Hb*KjC0j zDt6tLDV!8e8!(Kder}d5UHVAC&{apvXE{bB*7lW&LrgkY2|V9c#Z8~atg!=*5 z6BHUp^N3x^YSste9|RqI*kCtbm)i&l7#93TsP`;i?dW=>$zDOrMUgz>%1z!Ob_uuX z8+EPVsmX?ag^mC=)O~MJT3@RXT$S!AIu+5rE^k+u(0N@X1V~UCz2(w!CQOUTI=)sO zSI08aa}pT}XXw0KtG+}i9`?d+pHd)l1&n_JYeK^%pid3gENgn*^v8Ie%hJqM1NU!% zj1K!=GU*{qyG)&t=mcbRvZU-^Z?>a5QpE`!MQhv!#(iCa7K%rn+kQ98+@2YNr`u+c z*-5JNci*-iPnaM4{UtOF@$C%1>r7c*bo4!kufRcTkE;DU+u2k=9In|7(p`ENiA`wnA#pm%m}JDJs|H`T@QBe)f5MDJ6lhi)`=?+2=AV-b zOTMOOi&!BIhZdp%l56-O`nACE@l!zM9^KBP^bx3Vu_vy0ui0(V?6hoR&!!Wzyba^-Cpw9ZO-e@+g)MgPuyn$IFq@D}jsXG#x?Pk}x>Z7Ve(h5Aw@a|#02!p@z=+lzxnYV zuXB#|)gPJmDdA`^w6?Z7(@nMoOd8H@S_!E5{l4&h)8JoG^&k~Z_7%s!ZAtNsP?dglll?ZBC&^H4V!r%@Powr6qt zaI1SVu{g?hMR`~{=BxFvfTw^?+EVmn3f3L{-;pnjwCAEJKivLan zT#?G3TwDS=vN@S=F4zUI6ws5uGm@W`rySMrlL=uBoK zV4UJ?wyjBDnGg>+1;!35l?g?TPQzbde3M3Cep10V5b+LVJ6mIlBNSWLVwj!w=l)I^ z{8-EK131c4*C%TW%!-}>y|q;LNyM+#VJBz2BUhvW$6;aNpG`Z2naLL8=l#}C4l%(K z7V>YZ#$tVMO7!P&`n}u=e!o5)Hlh38c={w?PU`pCTdg6^v9z(Q>WQ*(-V~=o3*fD3 z@&l*u9W$Yc>_L(TvDw%RA|)K8&)sjd_O>qOo#!JmyX|a=QYQlTcb;m{+n3%PZDdvq z6x}wQB~gEz7v=I~mUka5_{GVq<4!c>gHaCNkex$OLQ%oGyMY%M{k568?fdP^hWHxE z%lsTImhIxao+Era$jB&aa3jTkzL}$aOI%ciPio&Cc~?y6VP1N(ZF;ob6y zArcZW&k=}^Rn2%OU&M`(gcG*KAE#?}CPR0xUXNF4u@coq>)p9mj*&-5TCO_8rZZDG z&3^kbRTaQyc+=@NTXGnB6 zy9Bkp_UST8QM<57o-BsYOW&d zc#c!%ro)rp+AcVof6Rt&dZSdFnOee>EBsn7!#+FyNUZ3ZMJ-2J>~waC4QA%|E$j>Rbfq zr9FCE-mya3RM|5Q{i=?LRS(=cU(CU#H7OJx`o`$cE zd;}uarf`y^e7o7Vt2L22R|C9=KcA{QHyLjw1T)QWq;yNg!3zGuV2&`2C@HwOuJwdN zOYG89?51zX9C2LkD(FAvy#?p`rCl{KtRR`!n4nENqp$3cuhURhIMf?+7LJ5^e zBe~{3p_+R`ELd7}OMZ=F9^zpkx+XlTMGVWG7H5&Z)CrzRoo{%K_OEpuT@P#8yf+40 z=Y#v$+(~#Px?%zbJ>Rl(4&(@EIL)-BsIWJgtDj%?3V$<7Yq06kAiY; z$ze~@D%cu0>eqvB^itw4&VpH?B;gYNrpT8Vb~D%=AF^Y|E>7yLij%k0YR#P-+UmG zhDg&Ofmdf`U{67G8;P>)B`CQ z3py_YTbLygj7Ruo1Q;G@zcN-`10DqOv-c##RNtmZ{QFc(X&pHDQRW5bAM4}telf=( zfCSTwY;J9}{d0Cov1#)grYGQ)<^mmu%57G%lVU-#`N{_OXj@jWc75BRjTX~b4Zi&U zB8L7mQ@BW(%`qUKi0!FwCn^wTEs3?e?^gul|d@ zHdIic!J3wSS5u^3yW>n)_wjw4p-C*OU^33?Pu~FG6p3@q5cN`MEvp=1xY4rv;m0!Sml7 zIzS}sEAOJqkZtJrtp0YOWxkZ%Ud{@%wDf_FVM-JH}Z&&%g6L#{|MiFG`%Yf001C zy*zF%8zVgC!W1h?&sk={42Ip@@Ac?KDUguV4p6iS5#ZPEaDO+FhX}hA=(bRmUDLb0 zZBOjh8Zl||BfG%xzp@UK=W3DhEEojX`BBwjH16|J6!p z*m9q$>Z;?}Zy_+GYG_k=V-ZFU)G{QvGYu?HVS}ES480&GR}=kGAVHql$NGtQn2_LH zEnDEFd^&|dE!SruGy3pNXEp(A=(#hc%Bm=^e;>`&xTX^ric~aqnY8PICec)*O;`v- zY7>YtwRX`+i>TiuE(A;+5IZY543*7Fpo!4J3(4*Q)8x=rz=Fxi{t${F?k|-z0ehD+ z7J3#T$NQzS4#wHd7SrL2KhBqTrqKRm%dG9MI}*cyr0%OXK@zT@ z0(w=G{BZLTzVSsP9-g7C@Bf|fV1<1Zoa1VwV=|q7SM+x#+Z^lvdRBJF1U>o?25l@T zoO%3G>oHhr!G?^sIqRNT3zB2cG=PkOL4p*qgi@v_i{cv6RrU_i?pUKo4&o_|kQt4_ z;RY8a;6JHW5;#H-58dgX1fi7pyfjr3jaOdiX@Jmt$cA-(z$xS7V#B$_iHk@9orT26 zB4n0Gz>Wm@ z$4d%H3P+GQ&DuocX(EG#oVODf&&2NR@Pl7xE8-azwSYZ>7*^aU{eKE;=mTYVFQe|m zy?(G&LlA_ZP^r3e0E4i(JZ{K;^(!D`<_C9-9?_Nv3J&Cx6x7HJ`GKMkdGNsGVUy1Y zb_uaZK!;GL&qYiO7AJTj2n|K|5n>gc4TJ;&p#~EMKBRiV#tZ&F@%_I(hG|}o=LmK9 ze|<|J0pBQHijQ|T5biKp1#+`Q3f`3MOA7xKHSDGCEsd6jrTERQnqu+8P9}71?o76f z0_jMt>=DA0wCT(5VkZr>ZPbs@ElH=BCP6A2o|<|Z&kzqgdpmeE}$*0bf4ZV3S+y2v0Xl2|@Eg6Km( p=K^*z`t$$0xBow5RS>#(3&|iVWoWjS^Z~U&l;qXqDrC$<{};xwv2p+a From 27b03374d38cb5628362378ae6e9caf1a904854a Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 28 Jun 2024 11:30:54 +0200 Subject: [PATCH 0739/1012] fix component transformations --- contributed_definitions/NXxps.nxdl.xml | 56 +++++------ contributed_definitions/nyaml/NXxps.yaml | 114 +++++++++++------------ contributed_definitions/xps/xps_cs.png | Bin 140487 -> 149037 bytes 3 files changed, 85 insertions(+), 85 deletions(-) diff --git a/contributed_definitions/NXxps.nxdl.xml b/contributed_definitions/NXxps.nxdl.xml index 8c083212f5..d1dc686bc7 100644 --- a/contributed_definitions/NXxps.nxdl.xml +++ b/contributed_definitions/NXxps.nxdl.xml @@ -125,10 +125,10 @@ - + - Azimuthal tilt of the beam from the y-direction towards the operator, defined - by the sample stage. + Incidence angle of the beam with respect to the upward z-direction, defined by + the sample stage. @@ -137,19 +137,19 @@ - + - + - + - Incidence angle of the beam with respect to the upward z-direction, defined by - the sample stage. + Azimuthal rotation of the beam from the y-direction towards the operator, defined + by the sample stage. @@ -158,7 +158,7 @@ - + @@ -187,10 +187,10 @@ - + - Azimuthal tilt of the analyser from the y-direction towards the operator, - defined by the sample stage. + Polar tilt of the analyser with respect to the upward z-direction, defined by + the sample stage. @@ -199,19 +199,19 @@ - + - + - + - Polar tilt of the analyser with respect to the upward z-direction, defined by - the sample stage. + Azimuthal rotation of the analyser from the y-direction towards the operator, + defined by the sample stage. @@ -220,7 +220,7 @@ - + @@ -261,14 +261,14 @@ - + - + - Azimuthal tilt of the sample from the y-direction towards the operator, defined - by the sample stage. + Polar tilt of the sample with respect to the upward z-direction, defined by + the sample stage. @@ -277,19 +277,19 @@ - + - + - + - Polar tilt of the sample with respect to the upward z-direction, defined by the - sample stage. + Azimuthal rotation of the sample from the y-direction towards the operator, + defined by the sample stage. @@ -298,7 +298,7 @@ - + diff --git a/contributed_definitions/nyaml/NXxps.yaml b/contributed_definitions/nyaml/NXxps.yaml index 5fa3c20e38..9e0ef9e452 100644 --- a/contributed_definitions/nyaml/NXxps.yaml +++ b/contributed_definitions/nyaml/NXxps.yaml @@ -76,26 +76,26 @@ NXxps(NXmpes): relative to a defined coordinate system. transformations(NXtransformations): exists: recommended - beam_azimuth_angle(NX_NUMBER): + beam_polar_angle_of_incidence(NX_NUMBER): unit: NX_ANGLE doc: | - Azimuthal tilt of the beam from the y-direction towards the operator, defined - by the sample stage. + Incidence angle of the beam with respect to the upward z-direction, defined by + the sample stage. \@transformation_type: enumeration: [rotation] \@vector: - enumeration: [[0, 0, -1]] + enumeration: [[0, 1, 0]] \@depends_on: - enumeration: [beam_polar_angle_of_incidence] - beam_polar_angle_of_incidence(NX_NUMBER): + enumeration: [beam_azimuth_angle] + beam_azimuth_angle(NX_NUMBER): unit: NX_ANGLE doc: | - Incidence angle of the beam with respect to the upward z-direction, defined by - the sample stage. + Azimuthal rotation of the beam from the y-direction towards the operator, defined + by the sample stage. \@transformation_type: enumeration: [rotation] \@vector: - enumeration: [[1, 0, 0]] + enumeration: [[0, 0, -1]] \@depends_on: doc: | This should point to the last element of the coordinate system transformations defined in @@ -120,26 +120,26 @@ NXxps(NXmpes): relative to a defined coordinate system. transformations(NXtransformations): exists: recommended - analyser_take_off_azimuth_angle(NX_NUMBER): + analyser_take_off_polar_angle(NX_NUMBER): unit: NX_ANGLE doc: | - Azimuthal tilt of the analyser from the y-direction towards the operator, - defined by the sample stage. + Polar tilt of the analyser with respect to the upward z-direction, defined by + the sample stage. \@transformation_type: enumeration: [rotation] \@vector: - enumeration: [[0, 0, -1]] + enumeration: [[0, 1, 0]] \@depends_on: - enumeration: [analyser_take_off_polar_angle] - analyser_take_off_polar_angle(NX_NUMBER): + enumeration: [analyser_take_off_azimuth_angle] + analyser_take_off_azimuth_angle(NX_NUMBER): unit: NX_ANGLE doc: | - Polar tilt of the analyser with respect to the upward z-direction, defined by - the sample stage. + Azimuthal rotation of the analyser from the y-direction towards the operator, + defined by the sample stage. \@transformation_type: enumeration: [rotation] \@vector: - enumeration: [[1, 0, 0]] + enumeration: [[0, 0, -1]] \@depends_on: doc: | This should point to the last element of the coordinate system transformations defined in @@ -166,27 +166,27 @@ NXxps(NXmpes): \@vector: enumeration: [[0, 0, -1]] \@depends_on: - enumeration: [sample_normal_tilt_azimuth_angle] - sample_normal_tilt_azimuth_angle(NX_NUMBER): + enumeration: [sample_normal_polar_angle_of_tilt] + sample_normal_polar_angle_of_tilt(NX_NUMBER): unit: NX_ANGLE doc: | - Azimuthal tilt of the sample from the y-direction towards the operator, defined - by the sample stage. + Polar tilt of the sample with respect to the upward z-direction, defined by + the sample stage. \@transformation_type: enumeration: [rotation] \@vector: - enumeration: [[0, 0, -1]] + enumeration: [[0, 1, 0]] \@depends_on: - enumeration: [sample_normal_polar_angle_of_tilt] - sample_normal_polar_angle_of_tilt(NX_NUMBER): + enumeration: [sample_normal_tilt_azimuth_angle] + sample_normal_tilt_azimuth_angle(NX_NUMBER): unit: NX_ANGLE doc: | - Polar tilt of the sample with respect to the upward z-direction, defined by the - sample stage. + Azimuthal rotation of the sample from the y-direction towards the operator, + defined by the sample stage. \@transformation_type: enumeration: [rotation] \@vector: - enumeration: [[1, 0, 0]] + enumeration: [[0, 0, -1]] \@depends_on: doc: | This should point to the last element of the coordinate system transformations defined in @@ -198,7 +198,7 @@ NXxps(NXmpes): exists: recommended # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 1d639383e35ece0a8c26abbb69e42a98d5cec75c79365ed55a268bfe85d68d81 +# 13f8cf4cba94b1851b1d8996d7e76a95cf8f7cd6adc0884190e51e58089395bc # # # d(H;^c6PXBo!!0k;>e+ZH zRowBZs;a*c%BaeFc(eZ+OV+^grseMHOl4(q)@8mT(G~Bb%Bh%L5h{A%B&6bTgUTO* zl#MBb`WQe-t@5XE@oktLsdOSCnmZM&AFzG;O+q}GaQr8iRYt6vx61m- zrPpYRu>);PLv++?(o}AEQJIG?bL5Q9y!GBNBe=14&Fq)=RYSITD+xK3jL|aD zXSK8?#YB5aOrlTXvgjLqE^cy_caA#sN&7?{Z1KgjXAO1_lU*(%Ui16YoxEE;qb5&J z%9g+F+Vjzac9;ae-nD;INQ}w$K?tp;$Pr@!P<1@ZX+Q35aK*g}0VL@=UlJeN21^VL z+>-pgxaVp>)J!KxbMYM8)67_kNz7ChGH(tDT4uF@>!`Le=0)9=q?&b;mN+UWgM zZ+Pik>>E=a&au3X-cNd3Fse1K-_8-u!^Q_>_nyp8Yr(gXsnwOMsg7Zk2%rXjCxj#O zdV_K{M=!Lbvht%~p8DV-lLiS*Lo7|VvlRY`HxiXX{(%xl8y&JW>Nw6fl(q|7CE#gO za0dfY_Jhi*&#uMBtY{oyT!g0KHM25F&#vK&SsSntG81kAVvp_jCU4qVt2mJ$)y=%^6S+Qtb&IP?U`SUcIQbL`denpPEbVv-$YBssA z(8WB7fj+z(2#@M5;IX58%wDetmK!P(r zJq5^Aq-~os2JN_0&$aXu{WkIHJAE^vqwxpm$-}+{=(SbvP`^ z&RIJ@9&3*FwLKTSDt;PXDHuc|=?LnI$cZEs3ztde6N%?%Qa9_CP zHJ7;|odu77QgXVkdFBwoad+`~Wtk!k*sHujYtVF%Z(~(OdJeZ$?9%0M2iDP9hI-R- zzsQ6>Y3SgH=c1?&S8I~RN3}hcvg*QKdc8^|CMoY^@xq(rcV0{sKl_Twqm|Eu?kY}i zRwv#E-|2-k+}LpG=Ob&JzUU%WeyoQ+LVw;|vpgcT6N)(w9$|agSILzkjLYcbhOKt> zbMu6E&`zJtiwibFA@TvZsy$6J8wNK&6;{Hkr%pj~wyNQ`Xe+`Zr_5g~XGHCX$g@}` zLOMq>;OT|42bT1qVkV{5)V-E?<6}^WGF_@9IIuw1MyVvgl)Gp=aN%{G`VZD6 z4sZXHLC58C+MDiF z>iIkf!DdM$ouMf$Mp*M#)a4EXDQ9=o`k3L>!Wv8qop577b* z88ZbG=Yu)SyphB=ru$PpD;ymQvV?+lH+~jBSdZ$nMXB#sLn~JrQd@c_Ft>;dWsbf* zO#O9O+X)_#zkS?3eeQAB!J%mDFVzadOsEGRm%?4f3b8KZ`7VF^TJF1_PvVh*w<%B| zVh=cX$q)lI5pic14qUMU_)^$}`teeMaYw_+{-pViT`k+|PdIpo${Cm^mrjW<77N)9 zN*gpOpYy%Jj*_rL9KAYc>mbOFEQ(lG_SLw(Uh-M%MLs|1@uw3azi}$Ak39Y9OMr!@L9B9b}e?`if7$6T=u6Q5J4~H z_xh$8R0*m+P`HY)lbb!3g{njAD<$q`^QMr0MTi5-h=Q}sz9`)J=}czOWI`us>m)){ z-Dj0TYS1z_A(x@L-iBE&VW**~NqfHo-Juh^;fGR--Rw5X{)yOwV@RqF?_c5tW+(kV z>WisFX3-@dN3pa*_y--^I>y=_{t zaA3&n;cH2Z#M=ue*J2FZeRpU|titro-YJXZ-#)*gcXh6df8TFlZb`&9dRtF2tDg>H zIh_Uxhccs4?{^j!(y4pQI)(qM>TqHNLgeUff?MH=2kAxR^mnnu`Ks3X*S=;0 zmQLgNBT?BZe%csNr=paz{XcyDg*L1?o1(hUOrX=kpOwY4U(u}8E}|fOW->-0D4xzj z3ly^SCyrcSz41T%eFotMxXb)HS0*N=gpF@5OXYLM@&|!-up7+8mA|^l!jpKqRIbkCWu+cFCfi(^u=8Py|2dQW2=H~NH=5L_Ut6w}$P%}D$IG`mq2JH_wfcs;=35^Dk#6tD0KO|HhlBB7I}MO{9I zGnhd?Ti>1=Hz5u5z7};TZ)@)VfH*Y%o$IYZi&D{Jc&CU^oeuDT z7Brn4`b0m)>%!M)6{~@;!q}2_>9_miK9uDpy7qQU?{2{&q7M}K@M2*x4ekDt)~-uGrT{= zzA4_u(5s~zvlba+I@5v$oa~?dE#OzdrnX8} zGrY<}h)-q{^|L`DroSivtB&z=pG!s$MYtv@82UfNfT4dpnZ(n3mNct7f(xbzgmOBhrV?EqeKTsERU<8X8ip=a?}1;C8)!vs?@V@m?niIPp| ze^tIf(vZKdTJsoPZ#H2g!RK?qsse^LbRQ8Sh1lftaK|HvWww{3DR4VTPV|o^q6xkX z4fZ`i|D&o**Xh2xLU6v)|7d+IoCqUuzoK8t-L zjO5*{y6LR0lr=mNR0)RdhDl)7QQ2jY!jYE=(^$JM3`)O%{t4MSU{yJHS}YkjGZfyp zVIIzig!`$Az$v1(a2OsjoJ&w3vByF4zya^K3dRnPxSp(5m45o28%1axd|2VcTvU9) z;Z;=kQ6k2jc+PDZ9PhJVUNxF@$Yn3fG)kuMjTEX-#`SMTZTz}PB&bNxK^z@|`)w>K z09?v-SU#GVdLHO$-U)|T34a$P0NEsMV8`Y!?U+j!i^{gX@mIM%a<1q1%^5IhY&?if zHxo*tLPpK%c=*JSiWP#BOniK5>gDjx&;&1z^U|bwpm)1rWfIgsvU@0aY&n;QUw^I` zeHxBUGn>Oq*Y=h0y(`9!YWdbdbANdPrTNxgSEoW*@JKSD@8RI*bF^YalgE8OTyC^1dp_f{&x_(TyLyZ5_2@sp z#T@CyP8h-|O7QP_Wh?>)w|xU|U-bUkhqJY*F(3u~NCT1U*}UFb3_TVi zKM0ucZ?h{R9Yx^nY)B#|mkA^>5d2abBZ1jcZSr+HLF~l;M0Lo=YHt1cjaJ<6fDEt+ zhrfT`?@C|VF~<09*H7h?-Am>}#zMIs8a2K5o2_=*;pSVk8niEzpLR}X=5z+Wwgl1C zX9r-Pr$TQNAx@fXIhze^jH2}I&=I<$)$pQ7F+_jXB36HfTqib0VRpIJdQ}WYU8*A6 zx%shSgvk9Pc;A2Pem=cp93Ul4>bxKQ>(c#4>`8!+|GcO z8?Wz+!N>pjjyIO(jCMJLLshGhed&+9D|1|qj4~Mbu;ew-=9MR4t!;)Tf%{qW5CFvt z`fLH@NfAh+!T^Zmf}=DXAi%54;f*25-Ix*6Wk!b7nvAgdyuu*nQa^n-+T$jfV=W;b zQZv9sroeq0<4TpZH1h)?((22Xsa(#LYkKvn?FeiN5#0};uEpaSlhIlzi_odMGoI34 z<3>-i4k+9zu05>5{mlxl1XtlkZ$Ok+#0Xq|bb9Gfhg&-Glj5^?!N^CY*L@%*(;ZS) zd~5r$$#V(XXTr&p=H{6>_nlnr6gOc-8AZzZBg6Zuq>HgaQV$S)ga?FGj)IO|f<}Ar zfk~pa>6LK=q1tIT#jrk;X21gfpNqV4aNC4WC(Sx^!@A?3=g|Beu^-TCDZ^;OFYWU;P2xKNCG;kH-~m2}M75IS2=C&E3!!`JtTC;!y)0KC z=Xy3taxvyaWqMr$eY?h}B@S{3GlZX|QhQ^_yph2V=Q0&~15O2?DE$<%p|(i;8bJ?evIz$r?@ zmT}$3{Z`_r!}l7yce$N2#b1|foy_C@UaF4I1gX9Q?JH#wvZWoPV~J#fvC= zVMUTlQT=p_Prg1)GO}UOirZsi-(%NkTcG}=hMCS=Ca}6C&dIb5Jd<-Y5kZ^Q%JH1) z-^v)_LdNR?>rs^9z9H|}{5G^}Q98^aw}gt@0opto^IUY{Qw$n*$g z;ix#0U0aWmZdAwdX1{nANMc6Duny_7Qdui#ag0!!><)<+@_t;7yj zS?v%ir(B7}wChmp27*%BFyBd#Em>~3A22~N>a1mx{%}b@s^+0io*-6&YUJ%LuIbf; zw4{`YWe&y}Wgp{zAHsbkJ{EtusC)< zlxMBD{p@JVRC0@p>vwSno*xR9qORJA{*gb}2b$Nz$)l9ffQWw2JxBLUM#X3 ze9`=|w&FjPh~U#nH~gDO7J2uwto@q&O|>5-)-wf^97H#b6tCs!`h(1#SAto>Me~@e zw%iF-nT75Z&*V!OG!=jwTP@bB+%Ee06I%cSZ%7t2`w2RYv7rN&+gby4*zXC|LN0gc zPOrPD)UYW;RcE zBz{2YG4Hu#u&Q^b=(HY6DfD!*`kRW2)+-OMi=Qu#2KYCI9+X(qFVa0^_7WIvt{_4k zChw%JyZIE!m1TeoV0BynT?jU{KY|spV-?xQMm=z8$1(xEwa~^_Xh-rpbCD*niG}GL zp@bCkd6W~E$FlSL-tK{y`)~1Oz>q)mvZczmrzXzsLi8lk*AE_&z{t+7Qzay1a@4b3 z^>p-Pv0+)3I5LAC0enrMx^&2uApd{3v4Hd09B*?ggvghbACp^8L@uO`UOiCnVswL3 zC2G8rumogI8hu90z1|&a6o{Otc5ylQq&}T$3}m+4&U3d9vM)}9oBaNcX@e>LM@GTs z*As8oS;sgaeqW^7rOB($m_VP9KSRhv^3>0`=yHEk5ct@J%0A+Fpe9kug+vd#;(fE9 z?X%pr^xO)*Y75A-Q+NmznQUBmp>um>|G6)KoL&H!mF9@c}@?UZ;~u zp7!MZO_O7$K%I{0Mzw|l@i@*!{Qr`d@jk+#SG}7>@*9!Y=v^vlC<)KH^W}=S736Ya zKQ1B8Ak;7M$vR~W`3`6N1yTk7zfhsb2~Nlx+lAw_?On0y&wLS>C+9GrCRHzgD70FI zRx1lF59)+4%pwC9G^HL3ZMj+|#e9f4;@Xq;tE1^PQRk7|9dRAJ6?(Ah3NKoALZdU> z@xD{cyvo%>l$_%bOIb!|oZ}ON1{0r8kX>CqoV6+5?sQVGyvV+)@Wsp&a>HZMY0{S% zKJeGAbEVLotY!_>=YI})0OMvHkN+4Jy)v(RW&b>uIay=IVY7QoYU;vXwCk7zM14cu z5vo$WyQd)zQA0ON>TNF&k#;~PZzDvn^(1|~uf~Pdl~AS{gWw9UrK&?-HIY#_N%<(s zB6-kf6;MFIjP(a#9Q#tC)F)X!8G4sXQYvz*yFrVJ3{jDO8Yh0eIx@rsJ+I9s0CAPL zfTq1YX-?R2X+o+hTs##RBbsvUfx#rEfm|vXFIHsMAA1aa0UF8m;Xu>Ic_5i9T??Z{ zD(nB~1ln7@pay04*L@ewhiZ zq8;1-cX#-JiKc@BjmY~M^HUb`woXcNm@w4{^?n4vV}XH-IU!IhBZ2s(fG0!GbA?d< zt#+(Wy+qM@=ViRUH%Perf=W|iF_N`1Do+XGf8lYThU)GE4U~MV`J3IRaUOgTELQ%N zhxhady&!HteyGGv6y*zB!tHYJvul(400g%tm_hRYwA(3d>waFe#*Y#3&;`031Dqnb zDuL_@jfkMx{oD*5ktv@rR|o2gsB+$$3H8!Ig*X6zxnkD~Z^F*=1ketTL0ac4&W8;; z0@puZmkBuE;t#?Vl1i+(*BdQKLkXmGL7Tx>r2#8zS37-1i=K-c6d)p_q^jyQtsN#! z2@5lGFR4Q-_5D@$!y9-)%JuFnohCSlH-LP-L%dpSe&Gg7HY(>E8G~Vbtley+H8!cq zS&y0}j_E-VGP<4^Eu(~`*?#ye0$0OXb2TLmcjqd|WcO0_V;wHMuoCt>%&{E@=}q(z zs1xT$#KBMEM#I2aH)BRMOMSfb4e`P+z^}-4shnMuwaK3(fsL%d+KB4GI<+BVguC4y+(T$yQEX zMnoC-J9j!I<$5Eh=NN-Mn=nshPd~z3OOyYdk@C1 zFiLD@7M4Qe*T8)_64(#WGVwGt>#yN~4i6j!8C~u`aWXJ8WV2NjH!Uvr`yu^@1ubgG zEOu~-EjkF0qR9U#6V-Z&PDLyn@oh67*(yiY#ELee&!HaHbo1Qf^dBT z=z%T6dtmVeof;$y#7#dwJVG6H3^L}^o#V3_qpSammF)f*geUqgzbR5cK%4l%>*SJ~p@A&b~i^lGao2pLH4Fz4zoF^*o#tE8v+Nw5a$MfG^vX0bdA6q*w| zA*+FReiXTt*8DEup}UDi06+Z~6Hd8&Q_av15+4ZQs25eex_2S72+bv={6BGvv+qCU zOW5hF{M?sdqkX;<$VegMY4YU*)Ex2T^@acrg42lEXXzE9&G5fZc#}gm&$4Q9P3Rim(IP8s3rNJI> zG9!3IM4HioQZ3FleESp;R}^Hs5+1;fRoJXHLH~2vnkFUC&Vut5w-xD+4*+?h zq5lb{^po{H`ApQ8q5bD=7r@Ft@t%jcIz=jIg^APfW^Br^sXxE45Lpq>IJ?b(+vKRrN7{grKv&i%+l@nh*Ig z0)D2ibGK!IF+w9|pb9{!oV$BnshYb|!{oRee~5ThnSJzJ0U(pVg!tw8@-f}Fj5^8L zrHQ!XCfHa3j2m*GGhu>#bwF>{pF;9EbC}>JxK~Y8ve{fZYb;VCCwePwNd#bvF=xJ!%VQ zj4ko>eSOMz9G)&EK<)ou7ehhM*lKIB<1M=b6(DVc5W8OzbFmD#;*0poT0m5U z{mJujAD1Rkr1--S$DqH$Rlufdm5ao@#0TkZY}QfvHBO{CR{?i*7>B*>%`-Ra+RBX< z6;q=Rp)|9{J@M-}`8?1kp0RD4ia{J z33PLwm}0>xWSA`3^Z?{%Dir@HP%(a(U)1Ry1T-sf0w(r69gR-US3CPeS>nYIF`>Zy69rM65G@3p;RLxqpY-hkqp%Bmjd{qtKZa5Ur4VG&$PR%8)rilq?4o>JW2N5AoWfJ-orlO;y40Z*m z%(=V6FYz-+h%Pu;S)S9ufY$WU=$Jx&z@`<$(FhN0j#RZAF$sJy+v*>bn)c&Qz_~E~ z9tjt9lJPj42PKM#gAiD8qe<5^eBKOvc%hmtI#2bI<64(|lg9qvCjti1j4rnxR(l17 zBAD;gzqG~IT^!lqTzl@o38eYuIxEPq*nK#yEDE;88K|f}ohSS(6IcfGeprK!JJ^_C zki+5tOe>+)g4#MV{W#!=4`eCkjMhQMEgRQ9yr)5M5t-oX8CAbd4Nz$x!GDktR{#xm}f zbYj7TD@{TIQU38{@Dlup?!aLD^Y;y+*Dz1rW05e4#VVtYPkyRF^-Cx%0H3REqwh%J z(n0twKjOEyEuZDM8QmYMWAQWihR^-PnQB`^1GbLV4NL_TH}Xy+LrmUBf^ z;UMr7LLdv}90`9M+vlo2)pVjn-5MM2)ElN_ zQQO)4tJPDa4p91sf<676y*7qW$Ly!w> zsQf(?z4$OmSVMk3z*Aw;)ST6D;`~hj_FniXUep8jh^r$xr@&(T-mSsK!2};7*+Oz}u9b0r8oZ zy}W1?FX_**!1F5d7}>{FJ!F~SLzzxuITc=@U=f-koZ&clfb%IgPf8S*1`zUF`+pnO z)^3}DNP7_c0}B%)9^`>#$@RVm_eWxW`wY0FuH^G)9iQOGG+id608R(5QyzD_(j-jL zH8G~n2*a_*A25Z>Qi!<1y9!Wa$*6lpagg~deA5iVBGEKIn=HN7`LqvK9ftuN@9d{t zFd}$>l$-`XA73P(E7T1(@4V);*QNP|oewtuUuxVn9`J}fbilkcTIzLt(W4R*Ldr@R z+VkyQL5O))Vv^5a?tfMZWN3G!AhoFsBlVyp@CWB$%iTWGcn{~MDyQ?QfVA=M3&FBg zS+)KkAgSm*`2P<}(3I*F1Th4+c$mGz@=rxvY6_>qt+HDR(`Vb8qAuDt)qg@@IKb>m zXt)`S+c5@mcaIiaMj`;g^f_5!hFxMrPAsq-B{D122Ihr@m?J#L_X&rG2=$KO)4gTI zMaFKU(#e$t3~^Ft4H;O6L;@x25tiw_x+)CB*g(p95dApukgTn(dm{;0dK>KK&7a~x zUZ3J`$^84IiV(14CjI}1<$a;!ki;)a{FH5tMAg(a9%&o7|D`!a11E=gAo3j?mu#b1O{9imp$FFVc6FAG3h}}@f zM`L55)kj}ea+QlFKND^k9^={c0Q>Ho^-|bd-wp};9hWW~CrrmyCRQ_2GtQc9hBS$o zleD{E{bI?`xzS(RUd1(IKuD3D0T{t_Y2vEe0YQ{}` z%l#)j;Rg;OB?dwfo3E5(X2X37kA8KSaXO=F5c6DOmk41{xqn8aLd@CpUA~_#|&I^j#rcz6@)+*>8D)*Oq|+ zvQ`K{CcK9JEKsuVKf--xS{p%FUT;js5i}Q~XS2es3%BBd~Du=j7~Vvue$Pui4K$#J7Ri|`19)&_YwX# z8bqUmEi^mKm3=aDBC1?2J*SIhW0qFtLpEpQPWR(+Z)wZ4LExpAHDgJ0$O?&Hkbq+b z;^w{ZL6DEl8!_(-hvXqNJnCNYra$4h9;oHmpU_6}S1QC9Labt*)n{zFY~6D{!hP$& zfFEP`bWKlWY99VoR$^u$Ihiy+fndspYJva)fq@{gs9190_q+swM7R@2U<06VCBf1( z4r{V~`lIMKhWfL+de6$fbs)eBu+t~$<(j><$A#itk^LJ61QvsWP!`O|CrK`@QDCam&22s?>V^N^V_LX3+c^c-C7hTGK2;V>bUTR!C%E=XK z<733*3QhS&=0dX?N?dW1-d$}UEZei26fLm_c}@Wd)YH_`qC?&uOk#)vZR7W{$|urD zZmd9!ln(gGAldc5?JM^&zxHi+xkDM_Zwc<; V(r{Lg=;as>gG;iy@#oFhrFr`* z0WMu_frc*U9~f{gnA$Du*W@NG-mI z{XWPk%U$;7T|?VD86eZ zrVa@J#+F`S`<4N{jHm~}Ev}@vy`tZxniWMz3~l05$8U zc)OzO07-?|u-TDss?SWt7%0-En#Mg(#dLXoh&BAV#mS`p((jF#mQ#2Mlk@XyBj&M; z2dRh2R^m8k(R}=rR|g6b@u#W;E6i8v8U+OGqY%Kp;6C*YS8%?iW0^P?I%CJ z#nP#M%g9UTeJ{>Hb-I1`epJRqWVF|yjS~I{e9d#z1=paw;&6a0%P&p1NAxPQ0nMTz;bOYZpmCM-lckc2Hp2;v;nZK3=P+a4>&Kq%RjC^#e0?A#`I_)#C{5`Sx%Ta} zG?ID-!61mF3TRI!vi|prIa8=6ehxPJsjiIp@ec?CP#??0kVRA%dFS>q@AsvSpt_Lv zACN|kiUy3NX}Q?$!;H=8A)BL=qq&e={II3k&APA5lbYs z4*&lDYH%Ipfacxt5C@!x9s#QEdIm0>m_3WYH27mf{y}+{989Nh5M2_HNX0$;RJFK2 z1NZc`ElCf!`^1L`j{jn$=U}#KHvG!_EE4&%`n7l8yONNQIDl{746aA^N~Km#@3!Cx zeq@V2@E%u6mpQNWjV|u{jYz(WzHSQi-rt@ncljpgPMSHYy}OpK#bQT4Sg1*xOWo*r z^U6VgEbqLx2vDT+KwOR86(X<(;xzvEq)6qdxs(|aCjR2T1H5-uSMAN3=nuflNgWXs zfqhK0y|V((EJzySOs7gj8G7|_qulPh$TMKwT^tJc}J1)JTnm9S^`;UwAD&#Tuj{@ z%ON;;=&aA)g6Ol>^*?jrh51#VS@DV3uWeQWeIpj9muVT~i_Vsh=}wyP@DRG!!bed6 z{VbYXSZBfSV)5T$41XzDzgVt*l=%14WB#}5@et3(m6GVS!2CxoX3l{iRPFQmHId8~ zRX8y@vXlZ3POc|7X&Mcd;g|dmyV02(xtPJh7N1xDMX(^hS(q+~*FFoct-3C(qD|C#gUw{FDd?bKc+y&@;%<_~W|{O?sz zAb@|^^-r-0h6EZFa#_{|h=T>b!0n5(!uylCCLA8!ZcubQqj0pij;l7HU-`tSo6;dpn9D z1rzVoP_O-!k}RHfg{GAyk9>_)Zg0h_*qt~r>a(t)MMFntK98M`Er-elh@*fAEp;3G z|4+udY6Em7b+;OHVrK@z_KRHBkOVBCar%qLyv|QY=OLLTWuSR_hCEHeN^qt*M=h?Q z^P0&!S!B#Q5oxFXh`Kor2M>$;FZ`hhd30@33ZJ+g{Qna!@`PZMi%IG+#@+zD_WA-U zV1l%oXht^_!9Ns7g&)7L${$<_4$ZCmmhge7tez$Gsu-A!5g9sq6fP% zXl`&m1}~I-jmN_HxD>3lC<=q$@z)c185FA@>t`pbCxyg2Ccr4=D5K*Sg8WlF;0ET} z|8`93$B%GDfSn!oXQYFgJQwQ!Tl?s>CM8Z|dy_;11BsOiD%z7vRoc9RETY$S$^pi@ z+?pIFhMQ^Wbe+R5bh|$|ApN2N4k!d${4o_ZRjFu(SaA z;r~Ck5&&b}#6=r~0szsQT;#>@3o3Y5gT01P(NI&?SONR$7LY$H+lOFFJ!>!}nLA8+ z=@dw65*_5SYb`={3>6K#2>S_~8Hxor0K>h=asRCp-Xl&XsXv+DY-(s-t4}e8G=LcN zvv$4rnud&1Y!5>kgLVjxLy4d^N0iIm<{&cL@+(&SKIc(3AFSfHj2}JGKc$*BmkKHd zNltVhYe^{_Domgt!aI2UU_JvUFKb8-_Acdu2#zBzaBVOzQ2iR}0Y7lS{))RyE?V68 zEVxThS{Ov#U{Upwb2iU5JkTC>e_^YPT<<(2&j6Er#wzpn*6Lscv4K}nL1OE4Xvk2t zOBCdQ3<+c(<YdOQA8Vo~JrW#oT6NhDoQ>h;@={$t4M;o9k$koHZpPA~aHRNqWv< zE)(M*w@RtdPA*41aU7&hJMYVOp6C33_Q#&z-hJQO_kG{*`~B|u?(+%h=S8Y9n7SYA zIRK%%r^BSc6B)d=GXYN@1xUCezKNdE1fQ1X9>or1R!BmIok4>~Fuc7upe~ zMN8X!a^5QOS4Cf6x9mivJ4Es&0RZBpJl%*LpebDRi3gWd7uayw@ZsLSlTjejl-eG3 z6g$Ok^r%7BVk=MrmAj{nMSpG^6^Oc4C@Cc{@^hgT3*N3x2fn;m&2V3lNp zsIMEu$(=pxQ<+2gbcvDZsFqSBuY!lQ5J|v)pReO^%tSO=FPO#tBbScV9G;J9JwM0?VXw+DN4e4!$XkuO zcIOZ5YA=r2^iv`j(7xmXeOi*~87eJ|IZPCx@{QMAYc3l9Y?326`egHz@`o3~QwL4R zbb?7#Q8&Qte>VGE%~U)TJ^x^fC?)q%wR%Mct{8w5iUhB#18cf(E#zH8vU=2ROGE;g zgAqq{nvzs4Z#r|Jwkm{2Wzz!nM0^ec3771-e95X*h%|sDb*q+xvwR78RB3N!PeY!{ z+S0}_7KmY-$4`Ukc*hcw!MdBCpE-_iLUit~6yX>aGeVJcjr8ChDM@vo1*fiw{}kfU z9Ziu&@-e2^z6_(RgA5no5hmMu`hg%}4_G5%VSiZ@Zz)M*%vR=QAul(0(Y~0tk5`=R zz~4}Far=0!S=lK1y}=N#y4Nxr#Xw|aJ2j0krNDUj0l(QRO3A$ei%8@cZMjTiqp#}_ z)icrWY+BA;+eqmW;-wNcF#6Tm7MT&r>xHwRcagC$==+Jpi^$H3T5VPQ>q zfPKdAmeWeZq~Eg{D!7F`Y!AkLo>Xt7=EY3 z8Y!~cx<4(@LbCX+EIbr!^r!_inbx&!& zVTPT}wlu7NYu5JpsKaEU`BL<|dfHC)Hz8@sS9TGcCI$>@7fWa)04ZB>*P489Qc9hOjtpWc!8cP>_HD;Fui&;dD{@iWTSm;6tAbuzHBz=m6+s zRm8Mutq|`bz-tbLH28Y*I4L1dl_GeCD-I%IUyJfIqGbf9^{^6tl#W(zME6q^d#94> zK#~(EV)N!?x3;EU)F>+JW<^Js1>OjXKTe<2rU<$TFw6m;hbb$k(Mj+$`+I&k=^vhg~pW}dI{8vgXY zD^~+jDzgK0p|1>{vSkgaM8xBa;5QoK^2y4*dkF!+!CAPSn#Sw{Ip}K#$M*_W=1DjN z4H~Gks3^N&NpwhH3%v{1SX0Ukrq|OWRAywQn?41$OdW=Y8V)l~9?nJ1y|%6mLqtB)?A{Bi0(d#o+#K#xeG>lxRwsZk literal 140487 zcmXt91yodBy9SXEK|*>^8tLwoE&=K8l7^vMiJ@yqNtKfB?(R@}=m2fzO=7Hct_ zGdtd0PrN(yvw{>lDiJCi92~lgw74=H9AXR{90COj5*!@-ryq!Pzyo+EWhqg(k`dw^ z;KNG`5qS|fxbo=N_eO}o=T{EWT263q_*l=s@B`Fm!fbg0+_ zbTpJGz(44y>2`DcMfGV{bH4sKwP?9Z@o6pH+t;;l1%AveTn$Eh*B)k^M$*2grwiVt zTxIZX`3S9GLLG(RDfQyh`Q7;Dk`_bWWe3KbWBw)+zT8r>qfn=yw8gRQn=$1wtY&r< z_-KU*eN%*9?{>5}g=9lSX4wIY`Br@585vWxJQu_7y8p$tDOWyINYCo6*-HFmNv!FK zZC~4zd$XkW_C&sllNjXPV|AA4>(JC+=!7#wrIu8#rSwCRHbkXL_whD;ZcmTg&*eHY zXIEpT)_^x;^W}f#nu;OS^n@>P2v!*|=WDgj5S3)cZois{8J4upl`pi|RPgSD8HQ^$ z`dq~|%iz4U>T9#9f+c%BUHwGdxR5q6$*TT|#EFgm4RrcLBmkADIEBkfGgHVX+x5Ya zYhcG@3x8cst4&Vv1!f%?LM43RyUPS-y!E|Tx_tI)Hnm5O#RK;d;!?jMXhV{(I}aDV zn+>^Sz3tcy22xT|)@dkF$D+ilo7#IXs<>7o-So!ON|4|19WQT6hVH?QS0&!f4xPvW zuhD_01$D)cV21XDf?d1^*GF7ilZj6!-uYUMGep0Ov7SypSnw|iobw}^QF;zo_04qK z)TMBHv9e&csU+W&rJ-}%~QhF?`bb4Od{zFS;Z2vo8xfE zR>pb`*Q9re&7ymZr11`;;~gTt38-r6fYsR2S6d_7cXn-EB*G!{h~vZ7Cu=r+28g1 zWSd{If^vw2N(~l2#ku$E?F|r}ZavyQZA$K0RJXnAO`D&mX_nO)7!kZt2C4}U1F@BH z>W|kjw1`-l<5wE3Lce>Yem_JC&6Fl$dt+qXmRqc!zQ8X|4&;pfNYQ0F31m!%o2OL=^c5)mse&~;Fy!^vy zYG~b*>$7F8mz^6-5k1tpyVExOHJsJWPEH7>!WcSBV^nj}^JV6?H_Gq0Kx!SGFu0P_ zkaKVD=a5bbI^lMWb?I;`_19UNVaYI&kLLCD^2NOxtrSvZGFTqK1V-BDCqHaDql{%5 zg6vq-IddgY_rH}BJDjg~5}~;4zMFEOnCKpRkB0d`i`PBJ@_@Er8z(i)L=(OO?&)d3 zScIxxhUSnVa4fqXz+{+&w@L|HYgMO33?{4F3TMlFuDkReDAj}x=4zS0B@)G;x-qf4pODJ(Vir#Ad%O2Xq$a(!|CT8 z*$i)4N$F3V8>vZTZr|!@F}_yPiAlH_m5{ zr!e*#M`ZIXBu@_o;Roj{weOtPcp$H^-=1PfATFC2RgQV#3lgZ6(MSUQYog!%$tI85 zWusxZ^pukwg{3WYz*Z`s$^|WWpZ}##WK7u2>PXM4sj~1yVpeuHeS*VO5S`=ig3gkq zU72)Jc*CpDIy4m(R_*k|C0$ici4CQ`#Na-%Lwem;Z)rGcJoKVGO?D^pp<%)Oa@>63 z8FTw+X}3*Ib0$yFzf;+{z#?o?`i2C8(5h%RJV;;Et%cU6@hU<<^yvkVi0=7u$gqKW zl;EYNOe~ED_yJD_@q-$AeMl1^umR5nflP{WZL-WDPfn?;k@D4-Z+w_CY_Pe3#IYJ1fEib z*lQI-77FpFCz&M6gEhXybl+PsYfn3~D(GH(8((R;N>`k}$Z#5_Cy}*$AAjM=bHpAX zMl!RS_^p6ry(*?hAFBN$xg*Npx*_`%r*O}ZgCqiNW&eyy%L#XV^0!T^L<354~UfWIKP=*xHYk7eB2hIscBi^ z0jkIEbS0|0Ub7G)2xkswF2oC6b28F~G4~9+EZSM!WF>GZkH;j0I=xR+6-Zvo+`(Ekh-Dc=xGMnFP~iBHeIg>)L)_9>~9_;DL`yp%~8g;h`9;J@SM zcdeaYz-j%s)|@#YY!r}w+w>qam&sKl5IUacsL8-if6Zn3`yggAj%xZ>2YzY#Y#O9H za_I{_Lo6nQ1|ei0)~utvvvHq9?GO1!x-ea}Iv4YeOVvk$0`i^mPx7FI zur_f4@ia+WT+bp|{;B(Z^D4za+tch3JCv@=p4j#7&Q1M13y$OHm33!Y~ z<0CBC=QPayA`(PwDrZ`?`=QlY>S&1(TnnFSZgN&LJ5n{t$Yhu zjR^dCEau|e|FM0IAZj%kop9=?$|+^sXw3uoJ78=0xocqQ}!QRzsyq5o&RRbKnLDR#>zMhLC_jqJOZ31(o*N03Cvq=Te5%Ur2W_pu( z$Yd!Q7O;IZDUoo=s3o7pGJ6P4n=4?=WIe>Y;_OoqzW+L)#nyQgjG-Z#*+KrUMyqEk zCj1*GKMwmr@NDwa``1rw?wquq2xOu~2wGToEBg|1SVV%t$vZ?X|DQ%#Pi#ayke-*~L~-$)FA5mn zgeA=j?b!7>Dq9N@XXHZ`s&E|~>%Sjy?y$VXE)lF1EE4Kk<4Gc$B$Ri|XA9dqrjfss znOZ}P{0lXT$t-ZY(&hYrBT;nAq`dg0QBAfsntFrGbU^p67TYV7&pX-HaIBC2Os;N+ zYp&2%7;~czk3-D4F-XZM4ww|>$wro@Q$6=2(6>x23qJBGG=2gW^Ow*&D=r0wp6%}W z!|4!_@;~+;^tBuE+Ot)Q_LV6YV?>l|w`lUsF{I+-^r~Z1&?ib+Q%k8~e*4ogdGlv= zm9Be|{ZwLVL>1T^$~0A;>K}kgZ?vopz3>d0!+L+buvrP3&>4DKTiYP(-ua+VAM2j9Rc2z4Ocy`gUn4$7Lo-zEvOU3;Whu z#te*osxTp)-}0P#Z@MC+Wpj@FD%w4~ZLix!sU39-Rk=)=mFO_0a6+vhwKqYkm1JHb zF-fwZRR6X(B|Sg(I>ia$#{%wk*VkdlL-aifwTy1e6`9?Hn3Ul|`nN?FeEC0X$qIoE zBNsJjD<^QSdXmY@W}0K$_rbmKOKnt)Atp;uNr0dw?9@4wtxMB-3bR25bo~oBOhte7 z*!BfZy!`w7RX@Ww5L*FR6+M|{wyBt;fH8+*_1A-p7;#!y%!&KUa{EoCYBjqt8@%Zq;So z>VQgzWp(Y8si{D0$6UJm#+yqmSA6+enKMK-v~nsj``VDy|apoMB4A&cK(r*4n1+X+ruD_&`zbG8UdWt`Tin!JnpM1VJ zeNUWzThkM2ZAgCwD>Lf+kGLV!w)A*W<8kOF*RoE(UPQXPLEy(-mm>^K{ESYR964nk z?7KsnuQit(iJjzdJ99I#u2lJY;2}a>aT^k`3;S}Cr+BvcF-v=EpwiyPF8&{Vi&Q<> z1<-~;`GU>z(t(oxjH+_l7&_sXfFQaD1wA%VLK-DZTlyf&I--D-XnhLGCv^DP@E^XD+t(~{We%33!cbic3 z0Wl2KM0QEdK9}E3HiTr8IE`(d)s@N5UJ4ntX(^DX$HBLhKlDsmg4vOr6>drvh6&iu zmu<3X7MES=dvSBiK2U7g7IjB-$w@qy(R{D*q;g!qwTthQV_s9vsgU~cOvBV9SMydO z5evf*>&l|DT48~|1&$p|{7%qnU0l$V-O>XPP6axsNwX(!Wir6u5VgzpyVrgAO1M=8C(n+Yb9G8p|U8ROX&}<^7t+hI*z8Lv#=u`A# zX+3j(YwbY$1eE75w6)&%&lV3DcH^l~{&{OD_PFy$un2vIgI-ZEh`m1#L#U3bxD-HD zE7mUzqtdwsmhQb(0kk+gh3j^0#7z>6XUs z#(fgAn^VW;HQ#tNG_^tVFFq-ta=ekYgj)9Lvz>3)FEmX0yc6`SswRsQEx70`Q4kwp zsndmp^hSa{$?;ax&(ueVVI%i#{%?=A;!HUCiL<(oF@nq;#Eo@D9!|JIX zC!NX^e2{bwS!MC|nFA}OY6$U5V5egRIS>pX=|>3p+)9U;egi06>kK~s^oK34MeZBR zS|x+WHU6AH(^%kv@Q)fDJANH7qg{~lr~E;Y$(vyaHTMD_PH;!dWhHG*Y8be@;a$h% z_PO23Orq%g?71Zb}@={*zG#?M`WgS4E(!WR;de5<=} zasiP2NbKwlO5c(uw`TU!5skEODw%F}Ui${huoQsur6CcOR(d7HcfDQ+J@=Qirg)29 z51X-zUF(f@ixRA%%3yt5Ujgq>jSKrx@{NU%*tsi$+hx?mN~RNj7WCh~i>kcW>)ko+ zdvB3R6$Clu8C#Q*DIfw@m${G}%-4_maN^eM*KZ6b_MkVo>}|FrhQF6Gu=l){zpBQb zi3$G-v~NgGwJ)E!ild|K^Z?%pzDZJ48)51uI`3`N z=3f3G{M8uv`X84dNJMQXy|-c=Zkbig@=-1I*efIvku~w?kP45vUVzee5rI>FhGSuT z87hm*+jxA}^XV7*tT#Ok>*;5!<*UAF8`IL($#w6ev{s(CTQ5O0Pp;!!TiNAqJkLlc ze!acQ&+KHi8(JXm&^&VADF~$>mf&V|y<(-s-Ksz7q?S>O76-(MCVUP$JfV{cr^ie@ znG)CQKYcp$BwoaU4@^w=Iu%SNztDO6bRModbf_jp3tx~-%PAJTi`@XcSfSZ_zdnU5ljExxk%(8RXxa|dxAeW}15ElE;s()Bv1 zwiA=Yw43W~@rVtq9ELlxEwm#&sn+3cC~b5-ay2NF2gq42*&K(8l^3j^rsj|QJ2r$8?nDag5(9T zGEUSn<1h{YXnKm`+%vV&g$gFHN zF)p!)H(G+T_3j5lo96~o_^xVXB-E6am?TxIVrQuydT8(Zkp|EU*o+5!pt4a`3s^(c zD_5lJ5p(*`_;;y>-%BKn(X~JaTlnd#i9gA_KnITWy$z*CM3wy`f|s+Tj*K6pguN1C zOgjrM(+5q*r8XWcG#`hop<$Wo==DTs2JG_6?Y}o^vr4(_em%BtzvY@S5qc^d;u|F- zx4G@gTWnHSZl~Qa7nk@0LCaC&RR44_dC*P3cfur-kUMYCLL%sO8LwJp^Tg8Ph+ve_ zQS9;LB2!&vIZl0ri+(ze5id-z)xdq)`+2HW#n;UM+l_4r64B!|Q{j|4?!fw$YhD?h z;8Wv~j7$)K=2jxUwFe-}6$It02&7ao*@EH)V}3b z{n|bruJ5#_-e$-9Bw}%w7@cM-Pr}EYQC?Tyq`!SNlrc|Y(SQ8|UDNicSqJ0g?tFb^ z_I-Xf>!^;A-xqAeZ=j0l1oz|gWyK9T#7Ipqo{@)5M#RYT5Q?Z6RWg}#e5o4~^t1T! z!71{eACE75AC9xMIZZWHR2C6;X3DefQ1Q*oV`s2ri4u4n#7gi|d#j4{f{}`>J8u|8 zUy+mnnmn}7$De~vheBOtETos&=3(m(WVSFCuLxc1X~xn%XfpsiLHYY(;Itac6K3vx zEdj_4ugCb@Z0v`~NTzy=m2F=qQ+>;}iG}ch+6Mko-&KLQd?5raseLL&>HRr;9~HMS zDXpJux8Ccp8>(&hup-B&xQ*e@uf~%V?kDXRAYQ{^TWPIAC+1FKJtPg_L&MueciCX6 z5$eqtc{HLI?%m@}bq%Z9oa;0wZ0_Qq3PRnnXlq{~1La2>=`U)NJZ%h#V3fizn7a|O z^CQ%0&jgfuX5?YkNGS@aI6DjCU4XrPAExLUcHz>&i^(*6ZL zf;`(kN?#XoZWLd@)OUrcmEkT zmz6uiOe_jX9_uMp*J<|7{FUTBYr_lD-Lyh{MX{3jA6Zoe62wm1bPp7!)<{=>)=OA~G9?5rrC!e)|s@BZ*?WM5oWfT7rIoAZ{zcR&zWFF~+CN84Q7o zvn;tJCWYu;ov0*pWBWc|ij1;HjyAeH2STXs!GvV-g~LnBE|KlU=EiJjC$qOUEASF& zNlPbBay4tljlT@G8ijgK)G&s8nNmTp$tKi-5|=rY!_-hAcS6{1lZ2;yl1Z|b*MqKu6 zaHse~)UViI-%PApi?O_3v1OR8pB0;2QHcO2M0j>P<860cJ@oX$cGp6yU^>Z(IT6cv zHw`X+wo#S^rlcr}T}anVzqc4WV^6SPTRsYxTRHFNiqU-LP`FBSmhq|Tr9!77k5 z=0bMmxF->JtQtW2ziehuu<*J`>NIMquP3ifh%PQh?F8efClx_z z)_pczD~1$I3Ti}bt?>@Wo(Z{h=-*?0JA&BAIKOf1_O&4p*EVYkJSS)m6O&dd4kvFD$IK{3&$YknD$b;#8nB+SFkx36qI}y zT~;J0M%SOEduHG%D{(-KvG>EEU|NuhI{r)qJw7jBfFuzGPT-OEuIQ=n8^49IAlav4 zg2tH|^AZT=iXw95q^%sg34r#^3{zJbMfypF`cJ;H=>T<=04HvqPOTl7QnW(qUl%w4 zWw|WOMzfQMF1tkp%`tT>(HfV-TD0I_vs)NgdS<9A^gHL0OZBbCb0djkCqTAyHPvBO zs;-wm!qedqkop?2pbF1TE=3s{I16KVV=H&3C7vhB_Oit(HKfPV#)2|(9cK2vUt=gi zOtB2Lm}qe~@sHU2xgW8!Vc|j9Xw{rXl%!R<>)oLR?oi#q;T}m6J1M2$zZg;cT*wnP z!-Wm{T?iKs98WE>&7g1Hlv2uB1&sT-wx}@}Q7Aq%&vDtz(N%xzeb65H8soeY#v0>o zx*Ve)yWl>}X?J5}aP#Y~;6?Gq;w_7E>P+BiYOrswEizZC5HNO`We^$a!0ZHFol%M# z>GlAk)V>Y{{>R2cjNzJLYZPN~D+B?!npZi~V_eT%&_$;nPlf#hCEJf~CTKJX;0~(}M8=vr~1wMksDH zJ;1PT_1MW4)9jPm#&5#Tw|=8SE0jM~sIdHxhN$CdxNF}5Yf0lVI z9rsz8wVzvI8a&x7*>ua9v=G*@E7#9-=aG-oO&e!D=+7{$EG z5(-5eEDV~P)Oat?!q|(>M7$S2R=ld3kvI+gR(l@CFf^t1EtJytA{DTcLns+ZHRClX zjodYZr{R4RTv`>6T!qE-I4g&WOcLKh)xZbb(d%zF0LV}l#(`K?SrfI&&@PTr09p>=9|HDWMr*#o|xJpIBoffX}3oK0H z0qS^^a7+5yi-!Uu5@(ZSpTX`1&fAN<4;CWQuKm?#0?<;Tnl^DGMnsY#bIQoz$xn#1-LlxOAD6rPc>fZG+|{q?^19 zC>p#ky#G)Mk}z|9{7=h{s;5~FBoy*$2z}4TQ? ztI_<4XfiYE`0`6Xzk$}KAW&Sg#0Th30RgvNnwn{+c5l?XjS!)k+dwskXo0_uZ=S^l zLlQ>hxruBoJD3JZ969{*a$9F;pD%B))nUyGD6=hJ^Hm+;10;5 z55F;=Lux#=5lW5>=cs1>>;F77`FRuhBbmYm%Dj@%BjM&fZP60)ynrF3c7rus2aZ)^ z$l}n+JP|=AdN`w0wmGow+wHdlQA|>m_V7{~fbOULcooC~Oe;b)yyNgpUfQ09nJTMW z53@$P&y62*j#Ek$$o$)Bb(X7|^P-IGbZS>Ef1EAWwlW4GZAypY#8tuJXGulBx4Zf# zFOXGJ#MNCCn|mpt-B;-Nrr+ZAk>;{|DvPu_o4;?Bkk4r;A=$7n0SA6+vbq%@}!}tJTT*t?+d0$Tm$ZX7l=VqaFFYopo9qtb>K3NL2 zcx33?5AKS%NtgB8ANMxs z&FIM{b2Pa%iz&dmtxqHY-Z#6m1>CO{335G}3bu+CFgLm8thHy)dlJ=+(JQ~1n^^Oe zw%itEqw+qSk5fs6qyunLxCqjAJ92%pw&42__X`T!ZUL6@ z>U5;0;<_)s2c4<%r_xV1##h`p%{d+Lx>j2s!$1y+-lED&P6<<&GN5f;%rOE%h z?^)PRmt7W}p~FxO?L4>1%GMnJij1aMmzKBUsq1Po!L7^MgsBnnZ9Vjx#+Rk$bB9@F zpD{Jo&E(bwB+|a^+>iCe)(F=LcYkW_4P+z`UZ!E@_&vc0f_-~znR%_b?3@gw7H`6= zmuq?-H(DSfK+XGz8JQJcd;HJ>lI{8!p8k~eXaC;XF-~KR82SN7@L+tCGE5dsyh`k~ zU#_f-GGGL28Y)3QgGfOEt;fr|c#y&?O~t?=4KU6(LUyK#Q?sFnnY3u7wy;A6kDu2P zUoC8YWt=8lmDpD^qLdII^uNWpaJKx*5gwbJbiq%YcctR0)Ve<@s641pZP&%ajkxt? zv-v-ZSn+usWoZ5m9%Q$fVUa;ZUSw|4zlb^csxa9Od8ANP)wM?(ohgT~&%QGz$V-NakN-W8+;YPeS32Ok8z-Si`#y7XDkOE!1Oq zH`_~SFJ5X%5N~ov6yiPob=w{jQGT2_9S-Rl1Tws+)QHBjm?kfjn1Y2X20alz5;hn? ze@u5i`V2mIC=Sl18(WF9Ey9>J+v&I+lpo0Q2ks$6_QyZBdZV3n`0%yi+ui4^0Nt~J z;E@l9o})VsOLxP@VHL({5BqPXZC1Tj3oz0o><^r4SL&qc$$P6m^j-58zpr?#hO{Lw z5GI^E{k5j-%H(S6SHq{B_}Sp;~Ga(N>JWD-lM?9IL)-tA*^_i1&ip$|pvy z_Q_~1v{dQsX5?VqJAd7g^F>ls&mDE{rk$ZWziM{h&43YrZn`KCc?F*}J3X!v{k6~& zUaH^D?H+l~CP)-MOR03Zld7YGU`^&YCS2O9)Xbmi+@`LUGBpVb3dBDm|t{=gTRt+NLl`@S#xu6pF$!hGiR^< zjOdL3+^j+Q3F z?QOuqqtBE|#<~Nw{POi)0Lz&XNM9)`*b?>hw+X_=?>(Q7TN=WzPOZ|!PC4NP3`2PK2ca|R7HXEp5B|r!9`t(ltaKfLClPT#3Qm0~T^|6h zT>!IrE4Q<3b@t+LNm*IQ_o=Aj6K}jRybciP)6TT4a#c7MRm7a~83_R}b$sWi7ZfTO@QF4u7jFz*sJ5(dcM?c>`w07@Fi~S>Q zF-=Qp44PbX?+W}QZhMP~_gXs6ua&-*#~;s!v6|b~Irb+MWyE&LHuxGCRW~U3a-8DH zOj73r8eOMYLJQDc4{fk&jB(x?J4^l0AxC9O^K8ww3V-g6_v~-dUCxfiYO-gfT{GiUuo*T)Z$NlCWV4Z0r3s0wi=>Um8u@i7sLH)<3}Lqg6_ z@ZDX99CYVNTA!6>#<}H514?IlCb2|ASSH1M z=Y(PBz;yd)<3{Kw+<57C_y}@?DlSf_y><{L3Q(EiIdoyRu7%|FJspR5bL47%PiTB zJhB|#QTdP@v#VZ)v1Y?C^zzqC;!NZgiecvZ9b5sfFE)I9tr_g4NK4iM8- zQS>O%V=fwB8Z2NWW$`?d9m)i$Af5qVBkvIjFb0!Fwlc42@g4ayIL)*=^kdUw^;&9m zG+d;(JYGTO*TY&oRaohZepJ+@%6G`3IL7D5M@r+cylba?(7-3JW+&fr9JtR*>yK`k zXQ&hDz8N%ltZ00KRo`qJH4na%cqL@NH0f1<&CUBdgcu*+^uUr&JT za-I0wJ3l>`H*C*z2Ahr+9=G&sdvdw*0@D9@Wt*0ryrig%Hq#jUq6rONuFv7c5mgS0+_zw*yNC+^#uTRDC#(jhq=otlVb#*O2wckz8}C)`L>Id$@Eu|A)hJ`! z)0vI;K4!ktXKT_P2XV2QsJx_#AQeM(aWs9~O11neQQ;Z1smNC+m57k&jAjTf7z)z$ z0m)+y1_?ATXL|x6w-LV+DK+ORr^B;&;b)}0IL`q*r)7G`4&eT=?kc>WyM^%#bS+1>Vysr#nqtVzNBAHtr6E-68P!FsO-|>%R7CXH--=|`XYxdVm61W(KzJQY*V;-mY zme(BAC;9dUIqNFEStSj(71@_7mE-CAX4Orb{cLUr>!66cxttNcyt02>+xc+2O!g#N{35y~yAqjrj{SKb#jUw;A zg-8f}wBE_lG_4lo7q+@gc@WsLQrhi}d#TuRt|*g}WHmz0Ae9_|S{{1!Efbau+T?pq zV$^0NEeUdy%tRMh+rBV;WKU-0{nYdxOz_J8?Mp=xjA=)Ov&~`aYWJg8_)ARr4%=dU zM>lOdqTgG7MWI$qp*Pl5M9!C=N(-sPgBY50Wf5NwkdGTEUjEenyQGyP(7Gt4ge}@# zZ)ve&;G08Cb_sq+kLIZ@)x_s1L4E0Xyxb18hWA*n*(>~sZaOJbcT z)xRk4l|t$J!kzj<-B#GMb#6zr0XW=qH^=$6Aae*Zw=aBe*7C2^Q`WLd$?B&_cwBSM zR*Oq<@-8K~(lOVpW3fzo@p8JbB!h@l`ux*Z6hWKEwZH#kyounaUzmQmMd8#xyop{i zqLwt-)@O$#mHAC`Qhrp;;w~%jhIUbX{|76F-cClh?i7$nhtXsipty|>YF~+eE+~)E z(H2-$)^*i-%rvL9VbvbM+7ce27rqx^T_uL8qs6YluuO9%mhgR+A&00SOw)rN(qh`F zY9;#jjXE3Vcww_+fk@S7e#;h$>L-s-nS?hG@2%h8iV(m2K zS>YXW&kUu7I$uqZQQo;}YhnT^Ejkr&;T}E2aNe_aRh%??-{a$s z&>!g?wY(_pgXvG=u%kD5Fr#o9W~H@hN$I+$XItR|?ZY$O$VzV{-?{$av7G;@e#@~R zm#wwD!BMI}B8U6wci_zEIART02i8dPkuVB<{C+(Lq(_g`G(s)MEkS$#Xd84OG>A&x zdqLKxzq?WD62F`h^e!u0b6PMlI!5=Q%y1+8yPhS#g6H`*S^kvG{JHOT3F*1uhiYS` z`4HmiJW{W3Gi~A2jLRwFgqO}eph4@+-nWVM7(!cU4Zm2%)U+*>sk=Kq=tp@6;=q#J zP9lm(!JkBG{?vI`YrQv87fFlB7E4?0bvmHGk}mNbD+zteoW7yUbK%RawGkYTBE^|J?GBZcFtjR-de|0Wt&yd51%ggsc(y2IF8TH+?)FqcIvk^iq~xLohKpLFl<#LB=xU7Mmch zHjW>+6EQM;(*Cf^b-4;konPj?Zt?S&OfQdi_*O^mT3xf_^}e4uBt^Xf)*>Edt@50U z*08;RX#fjz(+3jJRy@pfPLk2IZW})pME5z`qMoMP!z@ldhD_Tr3VjNWAvL^k2H_Yh zzX3?vlG#rmDMx2T%okOWSjtSme;E5fHLYuJYRM^?V2fueGFZw&z^FWYj>Z)I``r2O zn4$%deU9h;5n`_UGfLnqL5|dkoP9MJ_TI< zG?SJKHH{GY@Z~YUP{98umJhyY^a`4(0vl&yi%K{DD+UA6wenTj^nic>S>OcjGps^> zaq>8bX|eXR2EM z%9h}t{2vLto%9deGygVzJIgZVJ}S;jL>7q2{BJ$}ni1zJLiDB=Mak#?$4VqbI8*x| z)#xCuKCD+K$b~qg>DMviHMTmmWZ54RV{=fa!?P<=T-&GA$osvo_Fc;oQS8L zN#VB|0peDu!BkESAx6euhex2pH`RQ4eAoyHtTG3-s9|FpqLf{L^5o!=RZIMn*)TIL zYfAw|lR&^$^#1xnQA!h0i_tWWit_Eh7$N+bnfZb{TZVUPE0g}!)#$BJseJvHsPTFy zi`np){k3QBz_2V_-n4Tjv75W^4~nHx`}&9C7yA|l2dC&3kM}nf++?%=PEiun2>Kcz zF!X1|GLin5hHn>0duqfh-aPA@KieEApF56Auil3xBM4}+M1Yr5&6dheruO0aNFYfe z6BZhvt1v=4VMXEHZVM=Wp%WF!XX`&+sKLz3MmGC#z0Obokl$^m*y>D| z=xu~#zvo>Ip(yIm&Ud-q-%5i(kUa23{{oZ9?CGSeQQlOZAGmnM2Rdr#k)IRyXb-I1 z_>%pekl&_4?Q>QIYAO#|=<;(XwG4l>Xc#t6-L+!aDy$t0*_!j_3m-SniE~(WZll+* zLe0Sk?9uCkNWo>H`)evvjipIXyMEfXm4x}iHmihr>E8E*BhN{O3$J7_{tbSZrq3Bw z@k_j52*H}#U`!^rou-Ijb%;Wc=}Ye=u0NkTco0*wBj=CEqSxtv0SBCVteSP}QVU{- zO|E<@n^_p(EwKTCsz5cv##4&>K&kxfv6LofHTccaRcwp3n4QP?v-$LGRXtcyOjKrQF+jIOcXrZeJr_D(YzE!!;}Rm47n=7QA(3gOvs-lbgS6Rt+=IuBqQAlc`+ zis*mlQePXHExC1y+j-D%Sp-J@J7B#V;mXdOm!DDK8kBaA4ZRAD*98p&E>t~Wp%jz9 z?$p^O*f5?lKWbk8l8raxRoYx^YzgDWcu-*I_#_Sc=kO_GX0}mR_?|G_Q%9q{<5P{2 zu0UJOmw6a7zd z?x3rm?_mDlYo9L|y6x%tEXq$E`oRIlZV&pf)`M(CL^4_ zu~lYhN90Lk{{W;5_42MOD|%+?s!btS^T}Xln%?JLK(2Nd`!Gv7od|eHcnt{zH8Z**>>Pv7lEFf%z2saE3pr1zs7#FfZI|9q>2SA`+SIxNz7izwrT+_V5)x%h{^@SXw%g;4@_|$lJ z+Y1D#AK3rZ{lU8LONeRmJBB#LhI1~3|!%_NsekR(`z>^8~!YH;XX(GGBPe{XXDE_5G3NB=j3mE!14)zf4?#&#WEdaPQc>Hl1Ug zXnA<@Rs@#5P29h}@$kDHR)sMr^s66QsNJJbBA2wvGZ9vBaB=s)BNnSh3L4zG?eTwdh^h9EEn3VTfa z-kaghvLyOPD*F@7Zc_1IFE`+Bcec9517>=|5Oj87d5bga%`WWy<*fOM5fTa6{|rpTIDzL%S$49? zN&D&mAtlxCLjV0j$rqSTX;1rS_ENy>8EjUMwG0FVUq1JX_mX>pNhAp*rw!#iCnl3WbP|0wY{3YUx=mz2+s}5N{FTxrt+S zF6fjD%9jEk@B{WCf_i36s11P_%Y9#ajwne5i93Pj8fjOKJcBL9`dF3WBDi!%Oc2+& z)dwZt416F2d_@eP<;6gUkeBWZ>0{e#OX($3upYyG9>h6w=X}1E zS1cMzZ7PS)9ufa}obA*1%Q@ko;rQnXeF98q+|0Y$2cW2)vN9`~5q{>Uf+YCP8CApP z9}4A04w$Bb`sm=*@;uFMWho{1;NP=N=A08(i8sT`o#4-b6MWC8Ef1C9#{TW>57#YR z3%=(hbK+u@V^iCX-DZZq&L)2}_$ju9-bQ=$uR&tA#+F1WP{NSK#szB;NN4+thjB8> zwSNXNpMw=wIinfvqx5$~xxKlrzvgw1zJqMDXcrGnJ3#)$2aAu=wsCjw)?>ZtJly_J z7H-2BCZzILN`ij3yHtmo@j^`6ZRjQEBC^b+n`7?up5JTVneCdcI`S?KXSbeWn9X`= z-?YMG@IZ&iONx$;uKtr@`q;-xn`HI7S#C~~B{nwge}=Z%`VSJVAoq*mBp%>iE80~j zI(ZjQMpW`g?KK_J$cI>|*7DhD;!R?r_QhEd9bYm2*u0$dt~mxNG?A1wmMCt=Xa zU1dU{8gX2pCSj#(qBW&YoiQ39l)?6!H7YUZ61_+S+{?1jQc|?LoDQ^U(Y|?DvJfkL z2qH!Q86^`lPCl@e;hhgS!YrR&lrw6g^0(kisdY)D!0>4)|5Myjz^i-!tnQx`xsqVN z))Wig94}PgFzAFH=lmfFze08bk~-4?S)8HX^kZdNs9F4G?XEMWW3deVGNJVyTeE2u zvwbQ>|3ABJQ~=X9Pp`2nh(p#!IKt{)(?;}rppg}qOrl1OBc&V>Chtfcsh6Vg9?1v9 z4AhiBd4@QalE`F%;~1HXf7sdrS>-Ia)la*c<7$Vep_ z4T|-by3Y{6H^YS^sS66udkt%C!(;3)PqeUtajmfFHCf*=?i&B#guUML+sy0;_dX*)5`ozsKDEr&P&% zUJSgpPvue`>&Wr*d%WG!a6z1|VCv6y2*3%>3d3{6GoF5qW=wS&CY~-aw*))0VlDS9~YH?I>32H_RQ$-?E_DhPE{dw*})gPa|DTmb7kfv|u(n!Vxuglq8 zTi9|Wa%6Z7vqyq`9~j2iFK8aZ`+qvCT~XnTZgsM z_5&tA^#_TQk>4a757t{i?4)C-O?m`S=fsb}wxQ~&m}qGgj0h%u;a%qcyieD zd3sLcSXr2Xom*)){b^sdGRdl)c4YDHM~g`Qk2vYXsZem;pkxqE^*b8=kJ)D~ z)Z-&H$#blc(-2n<+oNAk!;j{1wlfW@9g+z}cFY*K`zkD9B^u1oLD54nZRSp_hd+}* zzkj)bkR2tPdh)jxOZVUrmTNO(QwP;g+NbQ-KQBLpoa|03L(94eD{85;hv1%7dz?Z) zU2^zhF1#4+0Qp=dG_P~X_1SuF+B`vuyXtiiWz$qh?k3bb5%Gx?ClX;V>e^{2ED|Z( z0-jjSp3*%U`q`Jd&dH0AC9qF~s5+cs2`6am4Sqb_o1juhISBT%u&Ve>T<}N_(MQ*O z*w5{1K~_)gedy=X+i%~#h2l~ketNBNKv}0n(e)ll^*G}JVvHb(Z$F{OUMgM0TS@{c`i>!P@G? zeU&jd?=ndRINoeRgZwo+zy0PngAu{}n4 zmGURe*KKK<>^er>ZMAkgzPs0!0ZzB1d#d^`0tfmQTkF|NQ37349HRmsJg%=R9bq8j zmQax793y_zSbQ^4<{V;k>3JIdIyg9U;I|oL$9o?FVHu&|?}2asNkC79CM?s_1w1U{ zmq-*h{?fEPTF=_JoFZ@&x9(1v#D-*2OoQaM^z2QUR*geZx|Bjl&f|!shHhVqoQdql zW2L{Nn!mZQk2Owiq&*!9|Bohut^Wz@<4YvXA>(FWjPNeK_!W;j-AJ1*TUR|hoQ45X zC`OMBix3%C82;SM8sAmdHB?O#Zfcy0q1CpVOLb$6LW0@@kCq(%AhTvt;2@EeG6ZG( z<4S$HZ?t_b<`{_`bOsw#W5EE{TFB-6;%N~nn{xqvtSn_bJa zPCnh|;Rx&f{djn>Y_t8HHmlMYx`UoBs&%Zu*qi4oIflus3^CAI*UWX2it*h2!}bi~ z1T29mnvBaMV_23$=Pen?*RM5*du`5t`~FUpXcb%ELh#R;jL=gKmtW8PeOMF@KF8`< zE!yu`&mZI1*U|wQ4I^o?&ha;^E}{h#<3w;x09?vJ1#_V@1+9rZo_N$0Ks+H+(B<8**=H%HbIW zT*^g%DAd-)2IAV|rWXhkOMP*+m?ZNjjp8AAal8>jaJcqAq`-oeX%p%h)?QzsSntm< zd2E+RWH%fGl3Fw_<>q5gLdAFFF4>)qMMW1~{Byq@ghEK^fKy$k6bXfSBef94fJ%5T zHPZN=hLd#YQiA6`o;%T_^ZyhtM4wEnaoD+~#@7=|o@VCvyX}65D4g40N`Anu6 zlfb|b{?bxJ5a@O6+0S3s#3uk<4Z9?5?K!7F&N=g`HPo_z3qW+)%XQ#XNmwYLM8?gilflr=j>*{OCs6nSy4Z*qVjTJ(b1ajB3$SoFIZw`~I;NyX z=Ql4k&yV3%;E|=7%S~VIu_fLG#abs{C+h!f#uC(k`lRq8X)?I=SfHO<9Kp3H@JWz( zwq>;O5>KBB`B22Oudt-ac1zoik(O%%7L|FNXM!+A$Aw4Dh1jOs-#qmSDMn3O0I5Tn znx{3?rLdh%4EZ-}*p)uM7p2HjgSDrq zSi1yhFn^x>U|y1F_>RiPa?XyV`qPu-`5dwh?Z3Q{_Ezn;H?>$(e!1zpY)My8nu|LdHx<~Q<%@PYWeBwkm%E5;t75#jzh=f?j zEU3-AUBZnaE45}!SXE7^Y!bsN+WS9nTzZY&dYq40C07gD0k4NfoDqo%w|ED`d63~k z2N4ttM$aRQS*EBrhZr++t6}`#6DP5rh5WQetWr$)k-jmS6O*n6%Ba24cP=o@nootu zc^EajqW(<%`ilJDx&^4|^i;JfeHGJ81YeBl9)mf? zsZ!Oky#OC)B}I1!;}zD{VO#P;@`Nzh;lMt;OQA1D-Je1^kSds47@EOKUKshY)~P#Z z-dP6fXj#%fL>+8h1Z%%UIfCm^toCDcbH04Tz4i6lk9>Uer}j#v9skO4a&_xZDtXK( zRO_J_*kY3psDF$sVqkGW!^+U0u)%04b~ zKqL6;0QD$%_HxqJt%0fydZW`waLJ-qaafp7i=;|e>||ZSEqKvq)2Gwj2kU;+rISfP zUcpxXHolHAS=%iBRMl39R^0Kjd(+ zlF_YuO>nLo=|mrG*Y?xINFjqyZ})Y6i+m&QF?7L$jBMeTXKu;Kdo{8p$LEl@OdX7= znH5275rN}4bPflcwNw=P2}tVn>)HBWJ6R!hVdRnJ2><;2j64 znrKfChSa%UOED(KDjdj2i+{P=ZuPtPrHLDLXCrD^peDM)trFui9>{^D+Nx4PvLK2?+Z*ee2clE}jQj-J9oqb51Ng4#1R zNj&^zac#$W$Hm^Jd@tBGV=|^@pr-zV-)!+0_Kvc?e`~Mq6rCOTg!;5*?KjLajXZt-5V6YoC=m@0@H*UPSCO#{$85!x?KtngliDc3IibE?M zs%S*kml!9bB6z<*wk}7xhlIW8)?X@snY(X%?F4IeV{g@!7p3V)iT=kd8k~l&?@%Xy zhK5hIRjnUtltj^COiU}UZ7>}&cH>Ogb{v9}YaIql4eA-QX+;WWlm)3Vn$fs!EhgNa zzSm3Y3&&?|W1d(ye9PVVxy)4y^r0KVyai|{vyJM*sYp%CV zsv>#YDsdkuAgw6VKCJMI?B`&6)SSywUbDv4lACesjh1R^Jf?U7Mp7I5X5XeoolJV) zLpQ*-L9-O@v8mj{n4~}?RVOK<&~q@!M$S`xh%K~nT`vp-yoV{xu=S3G5*a!gUe_EX z$&;@}{ji={q-?J{QI@NYV#DB9Z1Lw$ zwF1caog^4T?0hEwG2ESJmi4ZqgkcJkc%m2Ih03jPFZJ~zZg5?30^urL_F_iYl*RL9 zsT@Po@C@=E1UbKuJWU23zQLUej?HoAnflJ!bMxi=56EbYo^$3Lx5|dqI9A%=eF%VQ zB_d+J66^glIVSGg4=(OEWg9%q92S3L<7;1E^{2P~t)R>}iRy2JN0)5NX$LD zorGJZH(l-vs7HzR^qD(co?zeb*E}Wxj#qw!(qk3Ex2iaPFGYqZ{pd&73NUXa%+7 z3ZOrJ4ftV6npaL9DQ*`+TDiTyjWa%Z2yTxY&yK%=DL7=0v45vPRF$DM4)8DXH%rA5 zn^>ST#nFz(s9tfJEWuWIYAJ1#eP?4hU3*BeU^7eT@<>eoovAdZ#(P}&rI(yYA+k0$ zjV|@Yigi{&Tj#Yqq!n*@cK^P+H-4_?jETJJ$<6+?>nPq=W-9UENJXm}ZTX=hhAp3> zinmdU)`)m|twCWPRtNJJeS=DiOa^mj`gidnCy?XERoCEk|YsVixM3Ygxet?GK z-U;x}I<;G9vX)z&=?rVK)>#}4o6qeR=uS{ds-6YO3|)9hIuY%ax<@lB@i=a#4~ui6 z?IO8X=Dl|a1o)R5D2?9R20>n2H3QKcpy@la#tmZgEBjP$iVBsH-^6%zSaBjk%mf#J z3g980-fr9@1M-reP%Q2qWG1V2cG>XUv*QmaqJP5&aTo9_G!!XHhxgp`DfSJA$vfI< z$IRKEm9}O68F^jq(a&QkQ=FPm_DC5pu&`H3`4jyJ+;6({!c7`+^>A!RISVRw&ha)F zDF|ZcT_+*taV^caa?$g0YM8aj0evQ-*Muzh`36N8TMT*$Z2$NNzWz=+%;r*lnNvw1 z>D;NhT@Hr_<^uBERSZ{s62B_vx>d2C{cQvy80M$J1v^~*jBNoB=|0}osh9W&+bcQ_ z3VF5)4nW23sOeXm(2$_kkKy2F_n+N=AG`m1#d}&bu7*;OOnN40SgmPL!kKTGDR3fZ z*d6R(sIbH?hgsx=6TMg9Eu9d<>KJaS zeV5kDqwzWh@gL;3GuR3RKjJ)t-XTt&gx7lJ#(D;|%9t%BAc+Py+pD&Ca5;oYPTVcC zw%?RhG1~(P%EareyJpq01w7?YAZS8SMq*Day^Z`>_ht?z7^Z9eq&Ugh@SoK`!%l7kcMS&{{A16A@u{H5j6}(49#2}(mh)pDj=Q?vHc?g$?cqh6f7s-h; zYQB1yOwVgQ+s!&pK zK23*RHbGC>dwzS>FHnhu6f-BJ^NNpT=CW9|M@m`a37bgMI#%665Kr{R(`{lgRYgy9 zE!We}_BzTM$ThF_@m7cBEJ)S$fq>>1l1_7|b3e#QF|qFznCc8dbvJkG3R&%TRJb_b zEPdV(;kTJ(uW2WZ5qMQ~Z~;?LbpAcWEg3;^?CLg566fn#5Suze>`Dikm3!?UBJcCziv&z7~GK|JrbqyD4E84Msh zJQ6k%Sn;}WLQ<)C+~VbPafK8vZtsIyjFMWi$=XzWG#f*`DmT_-`jk?}GhwBQ?<`3( zHuWhLjG}PL-n7Ib(IM%YXFa#))cnI@ z@TlFfQEXBa$vbmS}52(kL+7Ebi*w*)HTjsdq_ZoFg!X@kugV z*5HAof=t}q+>>X;W_-nVnt$l8f6DCLw|ox&i_R`479Cr)LMS=PY=s(0s4>SI*x$dv z5JDiBmtuOM$JHgzh=5i`%hUmcJL$76zazq&^2+kHL8 zu?~Bg+{efilipgXF<=N7#v&gG(-SYaCGoQOwI8wIgj?pPeN(?lQ&p@ zh_S>&)0%iu(==E_WtH81>6_o}emxjIE9+UJ&J$T}lJ$`bH@3}4IESvLW;CvTlsA2u zJWhcDG^DiXpbV!;$(l-6Hm4xD-+&O}DV}UmtD*K1e&Pt=q-XCBI&aQZpIsQ}aN_gj zm9qr9E!s(bPA+8@Q2qHq)+6Ak4J(5JQHW0ur&K-uQBES?%?rRLi^kKGCe?Tj#Vz`WS4HE+_nHfn_;XV$jxwsef3L8;PWSWY&wTvAZ+0p^hNoMjV{V7WRMrXnLQne(LJkIPQ7pwVKgRLt5s&@| zJKQn34_Ca}1Pr9`znD|^0pnyL`&P=+EGW}5ItYTdx>`j)X+G|-%b(KfzWvB?d#Z2P z_4%4N2N#~>V*dceL6gcuHKW?}RY8$FwaCie7o;~*(UtPS%oK&#Leubk8-c;DkJ*>i zi`U!8)tH=mNcpzJDH0Xsy#OqBc(Nnpra9|K>+O}DeZKZ?ow@s$0A7rLfMZ?31&hc@|vYz4Y=7tb?$y;zNeCYM2(v#Lir z9wdK_$k~R7Ix#jYpJ1*ACyF2aqV9Qg0CI7&H^!*Nsi~T8jrKF236CfgX}iCkwn`j+ zC-Tm0c!ibi)f+3@s1KL>Xk={EgOMMel`u3#`A(iR!*f18;l4r(WiKnZ|B}0pArYqQ z=u4>a=`j;fdiWXW_!}QVUsgBWfFyAph1Y7oV!!hrr2Yx93|2N{hVP#^+%Jsq^pN^h zyKafK_X_z#PyHOU0RL4aRER?q66oRD1P!i8u;uQi{^Lt;NF#vKwx-9eTIHQsqiCWF z0&NrV(8d-B*2lj{CxmJ4D&!lF`8p6f^sYf=ujyPq)|r$%h$qN}s=pdAyD9;>m~i1w z!G?U6TgSbbH(y)hksKF#5lW;(toleX%-sONy0Rd^Tp592db-3=j!W~ckoleD9KoP_ z(0k!nAN&f%2UltGbl;MO^n;E-0|Mg^W5?WX>&EH9H_1_QH<48q&YG83K_A0f{)AmeeB!% zIiSKFf;PPOT4<#bq^}a}U|;QxiBHF5o_kZht&xSEijQa#$Oj2j9?hNhdS+{4HoQ({ z9QlLQvn$b@Uv-bcMXnSol$|0fwCT{FosA`hhXe-ly5mvfkJPKcPS_4=V~Bnie@OMF zlSAdExMC{FD!Lq=G@cR%Gtge2oj#QhrtnfX&wlf%=2DI;Z&5!DBudMXRI^XSMfxkT z>)-x<=W`_;9%8rmccYEGb)Xz*a{m*C6Wck^GM(xJoLW)0_-8_~o+?U(j^3S}Oq*-g zB&)GDJzag`K=zxh)^ZQk+46h_g#M9mkdB)^^B#{5=WullS>k}t=rh(}zhg3J=-flqf|e{?;0)sCy* zx<jXkJKQGb}l%%;P&>16-Q%8=J326Y*QxBI&H^%XqJ(q8M5mEL4CG{Fm9G;(UhKp;cyW0Dz`C3jhe z0FAQEwDWkRs+S+C!s~m_`HIJGG5dcd)cJj{G+LNha#_QES(@A&o%p)yW$^%@&u^=T zrn!ChOJQdms;}AVn`p(Jd+WQuc>Cqzan`S8rQj$%qu@yPXbFmL%fVKyQKLlHH#5Zr=A*uUF12q`&;l2%h@uT z1o=b@X_MIKtQ*QVYPfCzJpq+)HTC#=&>Zw2m*xxs_1OO#R$=-!jY`PjNsSYu0l~LsR4GS z0RBy%`ayyt{7e$#)j)O@z$U|A0W$tGN@|`KCUc=K1#uA(1lh66nfl#*Q*Ea-la90m z_>a9q|5zsK;xNb|sZf(-+1^3~E$jkn&wklm^F+{&?z4sc_Yk!sts;*|WuLY-v2jY@ z;p(r47)pK<27)(d;|X)M&fW6hN#Jn|$u-KR6s!KMwi}`O7>z-uvpL(|?#ULxdh)xAkb8fivtVV4}(G)cums`rn}7Pf_tL$ z-!oqLJ`CyWaK0w*IuH@cl{Fc9itGwtd254*Z}W~6n^}69Uh@iDekolKvw|m2avCUy z?8qWg|M%_BmR?p+tm1i1w5+9)jh2Raxvkjl&8YSTVGF1J2Fgf#mib>n4+s=6mueLI zc*GKp)Eis&oLL-3>UZtOvo_%W>EFLgf(zu7SaunYzlALGDC@y{L}Y{Spw4Nadkel1 z0q4w8C4M-rw6^-&i$r~4iPrbxdv$k*2I~_B$-D~`6?33)Q=b{kiz;Q-ypM$A%EEx< zC$nIaAzvGhW!YzxIv#ElBulz>dz~@=u1^80A{f5;Nbcb3DT!n080*D$ zyJ`@2uvmS7f74|hTwDI-C_)ynxNSnp;KDULV8HLfhBt)M`8fZ9)Oyg>2kjg%Fr62R zl~&6uJtwkqoJUmy&ndkXv8)2sLysm@0c)T-)UVe_ zW~#7Ia=P4X6}*xfO9}CImmx+yagutcMNiHOa1}zxm<&b1k5C?rlkSO=#6k4Kv~!&^ zo@+d#M0}5B5Ui~W)5y^&p?hOq?nbhgLx_V(x3LNh1fbk*}3(DkPSI~x4;V~7m+>zpTT*D}=$xH-c_ZBC#E zPaesVty|R3Y@OVhFJR@Z{@G`GZ7|Ps^05ze^MNl?Sr;IgCf?sH{Z=w$ z-{y22ASM;Z(`~rQuQ46R@pJS8nQneQ_*An#!6mG`khv z&2Q_>VtOfHl$ae)fiju_N!oPZhJ8Xbn~4O80vR%nX|*Jd<`?56G1AW{GdgFfP{WQC zJ%*j&l+$Hn_7SYDi`2bzo2P0OfSL;Vm=J2}HDA>0aZ&;r8C735Ozl?Jm&s0Htj|qM z&?|q(7M5VOj#K>+nT5%RstI;!o@~ze0c*f1NsiGo?&)$}Ust6(H5x;)XPu}#w%u#* zeTyu};zC|LuHNa99OE%!OP~YuxUgbdg3TaD6D!TWlrEr@HEMD}U#_M9(`B)O|Bvfp zLqCsRTTmD<`t(G}2wF(;?ERx01fvq|yA{(Mc)diPG{-9F>0`{VRQ8~ya|}H8i{J#i zm#DVfr>d~M_w7V?0%lb_EGaem{eP+r1+GTnZC?_Wn0{2hhvSRN{ zVgh?*b_R61IZU4TDo<>s&*t-8i)DeVh&2*$mfn>=Bbl(38Q}a?$tnDb| zE#Qveq7;UrzoZ}n%F}tW`q<5NfANjBDbGrlgSYwx_kk0B4C!SS?NSJNi(+DH!hAXe}G93TlS3RD0kygz>fw9KiF05NV3&BXWU>jaEvfsewq-D`zBb&3ki-RPPk{+C%K%ZCbN2DQU z5PQvHjSzehfnJ%71+DQ0%^c8z%iH?hle<2M6Fy8y&{!*h-0j*#DU0LJ?{k8f z$G%!$nUoDD*CeKQ{_JV5S?7CGcL2)A?A(`l9M!H9F6}p&th5`ygU!@G4eR|O#d}rk z+ncFr7vf9;w%=g*@EF)WCDOmxS}&!mEyEZFyn;e7n=kYP4OO;dzqaml{ifrFv(td} zwIJ!HCj&yM65UY$0M5?tAP4@VLp7Ckb>;cv_zuJTKIPn`WQ@yXn*^Y@-UXlB7c>yf zw_w!0;DDGR4(>HNjnfWcIpZQVlo_=>!}N}@!;CN+eV)`Lug zojhuDMZm(bNYc@=&nu~Yynd#c@ZGmijmKcn@)5%a!s#`%4edpcybSc~sOo}VppMwc zPew_tc2M0!pb?L=$sw49*G$&qBQ&zW7lR|HnrO~lV^C!lPWHyM|1e9itN`vQA6&>1 zMbE7=lC!jV+seRPs-fFde zR2Rc4GWT1o{G&H*z&@f`Wt{=vdT&6Y9Of?0i9BTR$Anlgw~wJ`dRjd=``Aof1JU5E zu&0&*>Aq=>3Ht~zg>ZC8FE9m@U;xwdG|Ta|ft`&W^Tc3!jbj82hxZcHQEmj0K%gM5 zcoB($L(BcY{(}96(<^wJ!#T!mI*{<}Q1*hompACiWyBZibZnYaLbW1- z2w0mgyXx&rdGfTbXB)`>anVed)0=jLgjj=>qy_Gb;R7g9NKC7TC5-x?#9>;nIQyrm zg*KZI{cPHSaHi>`tWWS^*~~-jItj-i@RaK7_uznKuy)e?5jp8jEBZ7OY6a^Ta34wah{BN^(2w{Or z&oYHCipyF$?@y~Bw)#1JQ|7T@(}$|fI|g8Q;e3!Qt!D;bXq@XDJ{9X%d+v+B|;EbKb3mf{(4IjRcLW!e) zWSnykji-Z?wsa3eYJK(cR7=G2AAxx`4joC{$850yx!wX%_Q!eXR3We@8*^WJ%_Fbpno`bT$8r_ftNf~N^{)=DF2#tLuaMAl=$Q=YmkJxQ;5E7Z^AWC?0 zGtjH)gj`;*=gOv!+YS+H-Ih;Bhn(eTciBEe&K+Sv9T8IDn&vD>9NK@AWwYM*;OEnQ z5~AUsh}QOKnQbCrEZwX(sA#VW8@ip6m_|3cChCL{G52X+J^%HnWA`$PdL=h(%1f-} z!Z^l)Tf`SV?7{G4R!(ZbZgjR}0AT{h8xHO6F!7}(39*A{QWr}B_c_N)zVi4l@o`JN z{fY7Y_dABr_r`>!7D0_=kT6bm{KbLKM;GX;prDSkBV0 z;S=HXgq4O>2l(X!{=qhr|6n-@s!^W|mE-;Ab1+Q3mUE1V)$(OIvyHIx9`8=Ay?@Ga zGPXp(vR}E(62>GglB>Iuh30-i=#+aaT#d)R6G%@A;+vt5vN>pB)~~)~@a8%g+Necv z=02))IMjudFs5J@pB*s9xou@f^H^FJ)N*P+H9hsn98}LW+ClDdO3!?spxyDa*CV&3 zXKqz0B;?jC;`UR11j3*Qscj7_`ZWk$B?TY0iN8>V`E0`PTPIZz*YCc*pBp6PG>rw0 zX;KfIwz7WxZhc$tr_hTL(TLcXq=w0iPiRf1lnNqsXx?|dru5eLOE3T{)Y9A$MwKX1 zXPE*w8sB7xpkcTuDZ6lS^K)^MMUvy)We^uIu>0{{Fr9grxlzsq5T3n$nJA3^guzg9 zOFm1+a;nUP?jfjp*(&U^-dVo%p$qBzE8Q?G!H&j;y2i^FpP7TUvs0WLbHJ`#{a9iTM1hcUEPN^7?N zw#%9iWY>Wg+yd4V#sI7-Skh{ajf1;fo_S5DP2g?&VH-=h35<^) zY+mWG;XAO}k&j}GyO)S_gW;Fwz(D(B(C$e;nSBdeM$gj)4v5x$~n>$nG@e^kr zCBMU1zMu0;G74RnLP9x*pS{rX!)>ND6`{Lviv9Qt^Vc&Ip?NGAF%i)UD!AHq5rlixeknNq+QcIc8P2*&RuR|4nfXR54KFdZn*qP>zF#vbJ? z6UA`Mu@7Qg`m!eC@wR%mG~}w590lsAkaSo}D|dSRj!|t#o!*Mp%M<~w%-SilXaePo z4md+sYbUKAkrCMN8dJzs{QXy$L0a*1x>GBQIx4ZCP#eA{?YPcy|SE8FFmYgLR&0P0Q^qi~XG_HHxVD z*mAH<`+T@aPkcSn%}_P5!(M25x78fq3T)$Yy?Kcm=_V7 zHL{1LXtGunNUD4kC*!Q{0(Ok0l`J6`eq(1^Y6j*dqwHx47a2L|BziL%Uu?tG2Pzjh zk=b^AkKdlp6lp6cL}(xh4~1;u1605>Z1@t)k?12QkA2XXXolvmm60;2aa8wIIC{M~ z#S?ikMMR1E?W$$QQPTounEFcSAH|p1Dc%;FRrk_I zP@6cMqJh9bR(2b#XZWjyZ(LZ7-y?n&p!ibaQL}o^sc21(sT^~quaPJPO9xUyxSki=;bYLh|Yic!l1?crpBG=nbe zmB}be5f*DdN++8TiT+4qvWxH*Dg4@R9sUkp1qd3Ww0ZJ$+ywj;V?e%av`;e0M<6cT zGM&Iw)s+fK2{HOi?Sw9dADHhGI>nJNA2 zRdRHwsmSdsYVQ9&X2#_-=Tb`#!)Oh;F1*}~Cc^L>%Po{y{2LduWu=Z~0HG%%bb|sP zS)R1;=5o$?cee+qRg5n7gbQIlw+;(c^SJsTVflbhL{QVis-B}w7GOG+6`GwIGq5a- z6QJ3KHp9WPXF==-mD=j01Mi44LPuVWFbjJw^R&`JW&g_fVP=qOik5ebPO=(D;;u9Z z7&EBpr@c(^(hvYSvMO5t)ueM9fD~EfD8xN&u9AN$nI{Y%f4+k0tJQR(la0Zp8Q)7r zYgqh0yC`&jG@gz@R&Wjf5yHNcF0UkBMr3!}G2LA7MN+~y#qIfvgog=CC;9^8hXs!k zA^1*rj@~-#*V2eAeaE!sqiEwwN5)w)4K{gUH-sf;^Y2KGHrwitwl^Xj9QuM}KlMUh zPh6U-&7dHuKA(DBUr*$Z%hPd~dNj;CeitUTqZ7|gTy`s-Rlp5=jpclNsG9E;9yx%~ zV8IgBNa`vJv}rSR#EuC>Tq$zR+WJlJX-msYBstRo)1;l^!SwKQi|o;T$P& zPyuKWJ0K%;hN)3LjG&V(k!MgS_%Zm-63{Lq3%P9$88PQVD6=h@eRS&psG}Q#^Tb+T z*qD4v`2?Mqvq#k|koE&x$Tn^~82{q~nC>dO@K8qr#D;MTrV6?jO}ACMZJH<{SH{Y3 zJ)?|**C)>DnGnF?BS`jhme=mPQ)S^))THQSeB4J`aNcZnFwiCdHzQqw==RK>=faFW zJkaY0)I}0wFi)M!u*n-Gyc=_R@1HbuP+_l#yuP}TaPD?(z-}^RjmMp&xZ@Y-A=DQh zp9BM>vwz11A`vB^LJeYl3zCId6V95T)@g690S*!M_8nTtRn5TR)e#Es(4&+bMe<77 zBLBz;B0aG7vdrFLXdVBF=bF}S5QiH}=6Froj$+Lymjp*Y9)8ZT4cF8)1bVwzsnPNK z{t5l?AN{>id@q{0CYMs zU)0n8oo%1B5M%v`X}b)N@Lj7a9OoDYSTfeZ#K) zGmC6_785}X?UG5a1VjhsVWIr5EG|@k*j<+i0~3ETn@966d(^)54t>LJG(>F=WzA;( zZ_^U_X~SH-epBGPx|fd{Da9X@I48(hn1=Cp>Gj5O?7%=6_418|w`FAd-2R6r}c1Q#dDZMtLHm@XB&BJ z02!!pM7MmXNrX3N>V6k;0@QhjG=RX6=_e|Qd<+9L|JFq)_+7o_c$r@uL zt0o%3zF48l#82Ol=vY+kE%W2gCUMdNLRNOy0dL=}!aZg7!3OJXu*U`oCo-Yk+PFoe z+MPp2TTc!<8fefvVSqeYjaB|D){#Uc(c-)EO0QmnBY;<#-9FAoT)ncdrw5@^A~PLO2PfbLbh28_RXYfXAHSj>b}g0GmXStQ-PYCSt}t+& zeOi)8K48m$JQ>1GE$SQvz#UnZ6>PcsXOI8$<)lLs69j=?5lVJkx5JkgWuN=}P<=Jm9={MYO zk8Te;fEq*goe@SG(fQ7#g7vDGowB3_Yuig4VF?v@<*(QbWlIYzKnCmz$Tw6gW@PlU zotuuy!vUE-=Lk1rm{g!DD2?26SOyBuJ3Eu|s@!Z)GRtq>o3KW=Z+blD1V#ln4&Aoo zq`bMy;im*!6x##_Bj>Vn2nJ*@ow>sv@6fA9B4`nn<6%2t)pB5^y}8Y%N*OK-oTmAe zCAu(uS-!-2_BNhQRWH}AyA*Dy8IG%C6x-iEx9hPWNEJ8(;Bwa%Y!Jl;l|(fbW$O=B zZePyY=yRp2Bc2YYH#Wt|W2a|q@vvuHp49872DBD!#ot`dx!d@i>ql_tkx2n&?$yxR+N`_>r3TfKx6heFnP7k$s zUQUuk1RZw$ORkb5C}h)$bJnE)>K&^4iRy1Z=;I9UNEVZ@oT;<56I{dYUO%GD;@U3BTcK>Ks95LOOSy#gKU>Ak%D%2NrG5g}iNzrk!>(&C>J zRhY(6?12?ya%^pQ^YB0Ygsj@g8Go#a8Hpk+q0~rz4U|G8gB5XL-xg1vz)ZckJ3!-V zjRnMQfeCZ6k{1uo0|(jw+SJX^Bazo%gdR6~&Q~wH%d8XNtV`@F$oMaC>j+EGE?N`RTQIE0LD!?t7N5&({yo9@+`_GYSrlS6;`-X7MyyaZ4Uf;rkW)zZ3xe4w)6W{Qh2A_7PF)>|ALpt6by>V}lpt8~ zm0Og$nX=f%DM7=>aKmAo2GHi_2Xqt=k#1boB4QGd=yJDlBIiYBE7aa-LcWNO#D84ARak<> zS|xVtOa{v2H%}gn*)jM(jrTGYOMN6nsz2M_qbxP|nlsc|Sjuya4MaYMKm`mcZ0y7B zr1?-`J65P16MBV!NkXE>ZJtTBZm5&6;iPe;RS?np{EVkNW1?nPZ@e?Xi2Ki}*#AB# zwfAdV5TUsRTQ){&voTQ&reKG zUHq>J))w}*H-E1Q@sI>==5kQ!_#kkb=u8{8k@W}|>w_dtpG+2xodwzRk?&Y8Jj~S2 zH?HSkvPoy2B_{TpNvlpz1gsu|wUadM^^u{EU%-+r(5j_YhP3)BJQ_Zv@eY-0{3O@{ zIn(9w)DkJM&C|J)r*CWGxb)#H%{NmKtNkw$h5B-h;Ax$14^0%7YjH)!Yv-)>iqC8` z4!4i0Wjg+3M?2PijX*DV%+`{QebS``I>d$Npu6ms$Kz502wJHP&8B~_sDFzjP6xmDSie2sR&+9^S%US41M z7%RT&rvMIo>CpE#8sX+FoyET?;|>jmv*cpH8>mGh%>%V9Y>IxP8nu#`xJ=AcB%<9b zx%By7`gyE$mgRw4lRm-l;LiwXFOp6Zws=fBj&yENYF09T8ywj4?$#xqPVmt(cr)Pv zHkD&cDv|6FkXe_5E^eM4a7vbChA%Tdgr?q+)Dkv?KxJ*4KEn2StDNiXKN!fhhpzl^ z+Pr3&aQZbo)XcZuSusP2YhiJzB6SoSaUu1S15>Tv_B}7?s~11cw&Jnb@X8f5eCG+A z>$2}60X^`}Kc5fYaujS7^|*rTv7-w~|I9pJpMQ>kr3~bH@+L?o&uiJ}m;XbI+WBbo z?w@DfJ#a2tY_wn1vP)+vf?l-8;t2n31WDponpbsDQ@vjiL9s=5iKO`oF89ZmNL&Fr zXTH~vhG*GXuz<(wP*O#h^yuQ7HHzj>a*3L=$e4^nYXa{>kP0zi(uT_C?KwmP%a8L4 zg8BL$Z`kp45Q@`v>(sEI8|{z#)c7_INjmV@P38u&krw2xI*gV^Z*%Jl_UJ`F!TcP1 zMePKX0~T#T5r*|@<03AYUJpuVH2k-b8dnEx1ir0<)j^h~mI2J#1I5J}1U0n_nI)!Y zoa4NZxo39P|{7*@k+Yn~a~+e}DiJ&gDtLcL!C9;b{FE zgK0D$o>6vs#cnw`MbRuc#0CEuSH-L@Jv-plvXiZaOv$27hdw6&XE9^S%$nydwtWmW zLYoJ(R*j1FVl0r5O9w~+&qxzCzo2+&WQ5Bx)lYMaL+5EoE|ZZ))`Vym3WFp~FVb_| zN=CJtFP{1UcvB&B0-Ao|AeX)M$;4a|o9@zwtD;KwFs-08sGg?tzujW|y|TVfDn#(x z00kE&v%epw*^~q$2{09a4tOhu{E4ZP!3m)B@$PGN)bBzQnheL{8iAd~&PaXsOXo!nNo+9?UH z!mnEV3FQe~A5{ zOyI2E{kIjSv2%gNrRhYtF8=)a9UXDP&-m0`2Kx1CogQQ1zgQe^t}^zAdw^8KN`hT? zU^tc0D|>Q~(vS=&lo=W>Kn*VB>1`k>U&zyopU6tdcO*etbsKz>YWx;kq+YM~PAP)j zrjtF-`~}_5+UCpUny9|x?fLMyvevO(@+z(zw5&PpgDU4_`v@CA;^OX3c9bzL&vd;$ z3rBsLsxFF`sN1848Bf{bP4rT>*%B+BMaOd`e055BFHEuK#%l9vMa6|zh@B*gBo(AS z9oSJz>-P6}(Ls&1Jcl{R;gD*+<&wij5xk;#Qp)o?8Qsa1%RSdPZ}RQA$gGJ!@u%iC z`*dGHc_yq`Sm&?sSLt;u9Oz;gXd%WE_;pvL>j&BzWKzwkkAkh1{SL)C;5{ev6@td; z2Yfig+k!r7Y(HGOaG>E7yN!Sf~=!vX!8@ur1 z$)lDG1dj8szkd9hJNr)_>ODfM!x0oIo}IB@OLVsK@jjAiwZwEdP6cFJv6~s{bX2wI zV2!An=py*Jg?WsAKCeG%;}@}1Jf0Sybvw1<4s;n_4mBb@&0ok$1Sis*EQ$NoO8zK zn;z=+PPM=}Qf6HSrD6K*77c@uJVi4OeGr$$vVWx5he>ST<+m`;u*D0f2(A{iE1-RgnMg4!pD9Bz zL#X$w#_E{vvI6ygF77@5Ez2Kh>Pu1l**&aWsd_8AQ}xGz_YJ|)gb4_Msoo|%{M{l} zYaIDmO1q7QAurv1Ki0o37*aPy$jkr!aO?K_)dk|THPCZ>Zh7tlgmy=3sejBg9dsM- zg^TgOiXivwe_jxLniRR2LJ@RC9T)W3Ak+1wN5oBjJgYNz9c$6n4`O~Z3)Hl$W!$pz zSP6_$`3fL`&iFDuXJ#!Bewlrt@3LuM6yhQ7zWYg`=em2xBh{W>W2)zl3JD}`0AFaS zy(-_iX_`(~?oidh^-8G+>h7Oxf?Csc0Lie0H|#aR&cHE0Ug*6fFS4>A(W$@RHi&sgo7sDB;;{C`Bua|K5XF9EFv#L&0%*WXqJ>B+Q^w6 z9a)(riIU!%>pO3HkMn5sMGOW1fYE!cDhR+Fn#)hyUp1wV*@4R#gdIKwU&gG|I}TsD4`UKbB++ z^1MYv8po!?R5kMYOfSrR+f1gVi=(y2Ws)9c@|m+a&5#i;ix-8{{)U-?<2sYb?xoyobJnARP2m(QGkG6-m*!C4$_jO(ej&+oEfEokdPla91@U!U^HVKxE>1W}J0tLqlc+jUGE@OSstu4NqnDzvcJ#zc6xh&g zD^6LxfYL)47KY!|yr9F&l8HbH^%{e_Q$UW3ku1!JLVazi#zV=@Fei77(;%XB_7Sok(>6ZzgZ-T@%VC&8V8Q?@aCyrJj1gZJ2D#&2UVYq zPg+xjqZfC zp;okl&F+o+>y?~hjepQ`Ni`(;I%IjGd`cgSI!Rz^iF zw;+`~5GjkgN9#1Jn`Fm=8DhWM)-H!=GTIgqNOpn>*xuvdANcE67RK9dhxv=S9Q(fF zu;WH0ROc3#n44<=&q=z0Z+xM$48`}Lw10J=sUQC=+#9~ZLfH5d6G!*t&WDJvfUD3% z4tGpl8c_Nj5>)x)q~#sWSvRrFFd1x;tm4+ICJDS8HQ^j^hl?=4Zf2m z+Izh-HS2@qD?J({|oRr`eKJwZ}72F{V97NZQ&#~Tu3ci z`)67K$L-gaptr_k->B80j z6Z)j5l6hbm{|r`c|5w5l>%q|m*^!{ItK4$fyC2p7g%qtzcfx8PW|K^EEp2fXTQMwXty)>6AOK44yA^Ou{+NcO$VYIRVC%o0 zm#qoF1*7?2C9FHO;^6$9>S<@yo<9$Ki2m^Eb&8kACg3}kA)@;i_ZkNKa~Gm9)$7ky zTl}u*GBs~7TGHE2n3fo|e2iL5v8ijFA!(Dgun+L?@h*)Rk)azZ6oCbAxSaepMmiV# zjii$RlCmdGZ!B5MHBf|o6LybZ4l1@K3I3_`iGK^jihmeSl4&^n2%Q)RNzlG_`ydsM zy4qd+NMlMr<`whZ1M3sq5@4F1WK_;z5E;A1}4?i@pLrrAqll)Bs9mgtTBP%U1c zCBbB$?|&zn{K7x7!rR|bsEeX66*BUW>g|+%oaZfp1ji)NyV~(54K459Nx9^5ejjb& z$bV|)f{>tbc>L1YdZsujf`uXV8{Z}mfi=7R6sN1;T@_1M!^xYe{PU}e(R{VdvK(`E zmkKGFqD2orTouWW3iao6DSG*87XVC^+Dsexlc&IAl_VD4rR5Zf!IvxaFB5?aw78ak z%H@m@rM#(}roJX44WpghS267}rC0VE8(x3fSTK4=fVe=j0P;{7E!_jMke)+@!A?Hk z*1o&=vhIBU@2BDN_pWu{!$c|VB%{P1VoWR=A7=-S_3;v`udaTE@BSv|5Hg=Sidt$4 zu(Icb?DA!w{}MOSOm=m0rLE z=(mpOt)9`U^DG;>+orQIPZ3E-hp zxdzEmDc45CgPfE(>UmGI4C770o{hoy4V~Tvj1l;{TC&t(-}_R(Gnf&vbdM`Si&b~B z`Fz$M5$fheHT}+7uyw`FX_~T_?uM2tcxS9|^aevDo}`x)Z=U!%gXr9uK3S_xms`6_ zCEa2(<$RuGGP`j-NFa%by{@NL2lJXHLiS|G_t^*-)wG|D{VjEF|Pqoae(ZnlKU`#rnO-*(ckG2@oB zKsLjg5-PyBEYztLMDYa|9bhE7)tf6+N)g-S?2oZWVbe6Vl7}UqG0u_1SmU~5W{lr> zw5*1MTp%FT+c@wzP&J2Cz3_a^l&)%=7JT(J=OUYIMU0C|5OLR^*w@V>^vPJMZ5EP{ z8XR&jGCo%%mcyS>c!VxVKUsf?s;!Gsc_4`@y!p8F?Ln%RIE>W$Ps}PhqexOw6s}`WtDJZ6Wdo~l|xcp9^ zY^NJE$gC)Tbhcl%=}H=xOOB;_@=EkAjL9d<={;AQ!@_W(RYBc|Ma|B&#d5dLsnx7A z!l!OIRyzyZt9-XL+pvp2&tllvYrV%RY2K}twQAiFVH}zg#)&AyJUz24HrGQ~Bf2iwc6lzN!cX>U4;Y{n&NVU*v-ZQr6zcY@L(M?4SSK2+#_ zzoPQa6Am1wy8&*)A{;`zO%bZ+!Hv3E1;n0;u>CMY@@2=7!~LY?z8D$-ors6>i9)SA z3TIg{q;1Y&T&L`J6U97dy&3-`X@%>X;x_&@o~m@%PEGj!rw`LGo_AyoXl>ZPk*S_f z*7UX1Lk)SX@48oeigN{He7%X~+Db%;v{DyYovL3?z7x*o8OwDW#mX{jCU*9U1rOzJ z;mliGw+!xB^@}0a`735Y?{7IYKNoZO&(u(g1!G46FO&e?9H14in3r%Qg!(E)4bonI z+Yyd~jV~v3Fx#eFaoKn_))}9du($Fs5M+$83Je+=rj(VKw|y~Nbw7_9=<>4ja&Rg! z7MV9s(=dICY4k<$Z9H?82#A9@+ezyKy1b6#@Z;|;o(Js&1cng~1@D+Gz7AAjT$y5UG0Ns!AyP;!9nyA6qUg6eEbvcdxU}Mm& z&8;3FuY7qZdO-5Wb?|f0k0}KEijSEPZoJ`yowK1JN0e03B3ngl_`=`T{T*K6wi&@D zmBQ_S3MBm6t63pMV|>yI)PE-5R&PNq{+>q#*PPOHEox1~HWOTTm#2T>v+h_S&3LkP zqA;hHcr+$tzPXn%#p@aS>-Xt1o#EY*AHRN0SFQ9iPYs{gdMx0r9!$P*4yW7~c+=Cx zedZm3tWuWUYZ%u(P*+@SS$l1+L9OxKB5%<}*@d=bs#$~-X&_kVt^_iWD*1mLdVR`G zm;bYt((~pJJbu0p3>V!H#ep-JHO#9&{Q1A&l6bZ3F)EYIVBQ9?7ErY!;XT9^VOk&e zs_QrR5Kl$o8mByRzmUhSWj`uMtUz@CONpiUA>!7|^?pYWz9Zof{8j45%0|vGeS!$r zH+2{nb==J53nXWkw+YKyz>c52-d)dNCqcdI_j{Q#8L%zJi5zpVu-!-QEz15zG&%HO;tF@l) zw;jqoE!DN6TQ%VQ>7Gltn~1h&qn`)Sx5t8Usp5~*fdt%eEi0=J#Rr^^*j~?08VLkr zeg@6;r13deY4WK^t!y%!^;Mp0CoLIQy6OS|7IyQoN26phv{%23ksMdY z5lFcm@3ikzR}-id2;iE>yeshC&X6+U-5-@Qc4-xIB09 z<-uEUjCA{T&GBS+b;@pLVBIUbHB z*j|QPzkE+wR-e`H6RidXk7!p+<|0W>24o-M7vq~sKcIef|F)&3$iI?_dx8K0skpe( zNtTq!HzYoDsNUrcYFQ8!+C|v9<97PlR3>&24(A9gAssifzxZ<6jfrwrmRhJG70+VR zG4qu|g*g_pUwV6m!o4ui`|8z`@OLz}*H7x$*(~o~Iibw?tt&gNd5*y*r>b>0^E)u{tY=vLN7q!XDh^^I!w07v-ce|LV0f)(oBXp?*e(}jja*19A$g)_{H1iLbHNF9@acbyjA;9$>bf#Ax83C zD{Dy?r*cuNQ2XD%EwTrJy(xPPLBei3UQZ{2a}4N)^(Zsnp=fI(`P-N!wYU>s2Lfu$dJ0BM@yhtB;|ZqVx>myME@@=aByF%2S-0ulCId z)8Dn@%QPKrrZ=Mx9F8BdqzB*@>TP5O;C4G2blnoALB5U2+Ly z6tgPK)hv{K*`Z7lEW_ku75jI+eSZOh^tP=1mG4k@+sN=ax}E9e;O#eDRFsbUjo%4U zoBZBneB%%kL%bSgyuXTVr8)dKt$(3H#AQg{_tLL0$72gp2DE$yo zzpT)<28wj8v#5ceF^{fOdup0$T{o^j z&MCXJMwrhPsx40s2CPwSI4+c}KV-hsde8XrORCiV%Wia9n*N4BT#wFAhb7C;$4mro zU8CGYT!UjsAz;{3`}!CB*ztW)932scU@;oA)K zEfwte;2cTv{eH_g$vX)RWUcu%=N79Y!TL^$aJyWW8pS!e&>)-X;RUK=MEdeKWfq5| z*h)V6HsV`hMCI`I^vO))kTUrwl8gq_OsM!r`QO)7g(w;L0vS~>_`s6=Tg**tGJck5<8Co(A^<7zE zKYL#%XADj!hS3>>^aH8n)6PX;4o1gNk@OOus_V(&ShP?3NFSk;Ayvo{>pdwXzqn45lq69qrU=3=? z?*$FW_zdI79*0&-A=fI3&6zVrzZB>KVECoCLwTmf3WuiRGIE)G~?om=e4ozx!1@mO*K>6e2hMsiLn$0M6(eUa0Vt7}|H{Q+KIBhC+&4Dqd z*_Yz4iB7gP6Wl6+!0uD2UJG0HI?!!vzS_IjrdKw}u;j(nBpcs=h~?W2$qHb8M>Cc(XnS(+%z6 zYPyuwG|^i4^*VrJji67SX}?vz9Vv|y62;=C-IaYrbaK__lk5Q1I~zjR){9=ryU!Y$l-dQYjV}-vA4cE4b}R&w*|iF)ws!p zzkVTVITo%v$d$yc8M7O`xX#6nX?rZr^w)5naOizdFa}GmzQ=Mb5S5B8&^LdTri@4n zn|mtW`Y=TUjyLCn%}m+LkKDdKYkbnnN5ovMD5#$MY4E;AEk5^i9ZtQLhxpw3D(P)S zhYu6m(gJkbruN&lSDWPqpY>*`{+0{#op2Zc{J1E3@kYi3*)IdV5AJ>^SdEvIt9u*& zse@8m*y_`(3>v1;J04R6vhS@zDSu&meNe@4yV0wWHV5-PLD3?CA1f!rN$A>#NOJLV zsG|7NBG~R=1-m-=Uh(YXGw!l~)guphK=QVd$!-e9|M_-6a=pH4s_L1TYgG-SYaZ9~ zx3-Ou5IKMC;X=+ar0F34siaA$<(?k#pWF4(inMF>t-}HLq&6!T!<~YMPy5faMn(w@ zPh{`EMis9-R6}Klq6-9MKG42#&*4F=l|*&X0G9aU4+wIBGQxbeo;jufE2K*>dHCdp z-J|pNYWmRwLTc4!0Fh?(>!{8fo?Oph{S(J0>4sX4k%Qk2 z)8#Tz%UFH`9NXEe24YZ83dm~R-i^UZJx*_c zn(+7Yue`YC>eT7KuHI4B@Ul$R{&})0#bEcDN(T5gta9Iv_lH*ZgC4`;>b_QhTRxKK zoA0>A*wL3E#(T)6>($&juAQ#Np~A+1!P&+rCOjU!7dt0Lwb>pTwSz)1t1#YH8pLtm z%_=7-A5HR{^Qt62VtaSw%Ve+Xn|Z=S{6e8$D>Qb;?p5N6n!tIBo`D|OMd_tH^ zbB*FCV_#L#pCg62YM(mXv~J&j*ekS=`LQc4WjGstKYq!VOjp#JW$xUj2u@ z<0S!=1Cb@{Nl;}An>1VozMY+_lD`0S1)6sQ8dx8VG|a+9s}-cy>?6 z8D#O~7(fiFs7(-ajxpI|C877j{eEX;jALY-GU{Fth%uV}`>1=3)(&C2I3L$=6Bj@A zXoQK5V7qIl8^^iS7WIhpcRe+P4(*Ra+?uaQef>MVW3uR4Xx=2s!^9sD81k`h$$M_; zSJ<@mG-UM&|3d1+)F3pEbT;8o9RS#DZ+!i9G@Gc^76FM7)adoxK7H9|^98whv9(q) zUF@{|7JEKue}CKDNI0L?K4yOEXk%1Kw(}N_b&Q;-Wjs6a&EJW3;0i!CY|7i^@w;Nuds=G+x#%gU2tUL|g3{+otq9Ge52!kUG69qbevDvd;}27M}r*?I>ONfH*&t zj<#A>4hh&yqv6HvWuJQC5;J^1s3go0pxVszhC)2!<)i*ZQ89mO6_8DrYRV2MQAOlP zA3^?T4^LNF#xfv?)p)4Zm?)qKKmXL0crr8}=z)m#6Ds?(Q^vZnx*GV^R60@g*A3J4 z8icS5=TWk%o9#@{RFmV_7XIN0}Zzml&~lKm-8YwWX-@1qEKEz-jb_74ca zU3VaQN7~Dvy#<>YImgRe8dktQ3Ox<;zo)^6J=+&QmWm)>j%`Z3r^0VHzI~Mc-G3_aw{Zf)|&|dJQ(pF~s@cHu@F3$n~{pvb>-CeGLDWhOZ-m(uSekPHx~9tRaJuTZJK0Hegq9;4RNaeo54V0 z<<0v9W^oel4A7#wGGE?~orIrjQq0an$@#XqVVn>Bc>!DGH8j+Lb%ln1)F&?7{2<2+2i*c!mM|GCwO9o$IQH~ z<`B++D->hbD}^nyl38k=eGeiDrXZ#MHvzpNPO1%vN!Q9~3qoDJ_xL6KZ+t^b+F4A& zmRVEB?5TIZnTGD;dcwR_Ivj9%WS!0mO;@YejGT2m)%QQWwDDPdIxah)I2FAE?l%;5Emv1W!o~Qe|$GiKbStwB;q#Apq@%+OmNj$xN3-3-O z?sR_ZcsIi&^0npDF0|=HSlX;&*VwOLZo_S_{~C`czWylGcEct~(eZG1T_NpE0xuN2 zGM7eC-}dzmTcNHk5vzZX6O-~RDil!K!*$>z3c)Y!obvK0a-#&uTB-B=$1$ts{ z^Mw&cssA%>ydPcv?WKd3N%|qq7t#a&zCX-=`7xhl;>_y-?wmv*Yb=fj*cllAK1H06 zkXC@GOwgDdl*$h&qwdmKpc9@*6T(wQ(LKqn>mdH(`*{rx6%cCZEt|9sD;Igmg>$=U1;|B%IGd7d?B{0G0qNP!M+ zWkB*+)#1BJ^@#WlSR$m;ifjoblT-NjMNiQ!R35`x6}CwmFxtNfuDyVSQtB9P2(dOc zpbr9U1`>3Y;D2erL(gBV0W5~x@FI&~pS6ePpq8N+a7m!wi$$lUYoCIaq%oJU0xD1c zVe+Grr^)>2A7|11ORAUxFm`@4;`K3y4)vTWKY*Ah#r7@a?rm5iDY3e|lukQao>9s%P zmU>tNyupBri4^|X=i&am<_RB1T60iFy{Gu^w*vn?{u0zY>=Jh0rDiN*NsHf=DK>dChd+$4pTR>JAJs#{}$iMPnL|>x%>&}mV z6$zC%kk5e5^dz9Ii++u_+n^qcT6*Y;Ba{^ou>o3J7Wtc1w!y)V#QXOS8#|!bfXsq3}IiNim$qefeXKEGza z?GVSAHq@g1uCLUINk0A|05L#+Ep35b3oJK-i{QC3lVGk3$r8}R3vBu~Jg6gt>L`{2 z{nyO1qTNu~1vGdEO11(0N~rQR^$U8(D1cEt4XJDs$6fVz?}m)z?jvj)sNW(6d|nm_ zIv7k+Vn6@FZOuFp^|cft5kUn<5CcmU4r+DWd=Q<>y}NaomEn7!sMZt*bWG=>+p|O- zpjjC4_MrbsVd8H;T2d1{z;X&58=0ckv^CV1r&A83z_Y-3{x8nzM^;uxogws2Y^JAj zrXUEGtlyVzs$Z!M;z2*Gcj}H@5pnR`P|z@g16{vGxH-k_-u}`Dd=v}eB^)dv2y+hc zqW&7B{qCc-S7uoqEB%~tHRJLVG?TI+0BNe@0Xmb(a3{D7o;zF^FGf$7s`xHw3~7`| zeVMm7br#K}5LE|k!o&~h3L4!%bDMR;Dvn213Ylyqe7s@?K_ebCk=Tk569eFG>|BCE z$IXwQHMqo7U4WKxlK`|~e-4l^rYeMRRQBvJT7|oG;*Ie}Z-aX<@Qnu9YucuNfnEql zNnj8bk1|FfFqeUu0KT1*W^{Rt?=_`B6DD2Y?KE(a?;SIY&g-><316D8)@TcY%3vVc z4fZOu4bkAlkAI49hVWHZCCB=`7pMCW_NqA<$bnb(Ke5KQt2+9WA6yf@2b#Q>K(kmN zP^p4gYenB99^2r9X7>NCjIJsJBPlSnx!e{c)TJsOKsv)ouIJmUV*QrZ)-i4jV6JV@ zrcmTpDD_OVIvAQ!h|-k=(YpXEMcV3B7;OFmbZ2T(Pi1Zb5yl!tcW6t{1F!LQ^uI6k zuNW^r!Gwrlj}E{VKz@h9(8+SK(68-s!uuDv19#OB0h_~wvjO6U@f|MlXUBHuI@G`r zz%md@5^{-xrj@kXb!#1YfEvv0wMIfR*+VWdP+6Zjc#n)S=-sjnf5s9pBOr@FRiRay z0db8Aic#eAk5P>=;u?SB;v($lDYu<|Y7Utm_P=Kfcz5b93>mqo$ns5y111TuqhWaE z@B$f%7hU4X5P1!~fE{i@DN?1|x4V;}etPgg-s#iz5ZerT^@rV{0~D#`YxyPzrOk%A z=M(t{giAWn=&(@qn+Wl%CfO>CbYs@xmStN&xY4!G4m1clmVd^GEfHtcY z=#K%78zAKXrfgP^w`0BZixniQKDF3nOD@{1-DZ~AM~P2&h{M~k5|iE!E#mFdy$E2u zl5&bV00|=5sG5Ur&qry8A71TvePA5(rE>m$epci648pY>u3k)S#nJ)TNIaRtSzm93 zP>MzQ&XM5AFuXSf^pgT%GD|wuZ-VX{%f2GB>!m?_R5_PE=lrX2x&log1xm~_w0t7= zVjU;Yv)OJIaLXD=<$VUmf9WBPc{r^f0jqhXCXKv%gv-bR9F(MvazS+3p^UT zs)R4HZ}{v(t7zTJtm7~FU#-d;4?w4nlA;v&o9y2pDrF9-z9y+B{)ih}Ian|Tc{toU z&aRK->SxA+k6x??06nIEq#RVjf0TRARx7IoK-c1F4759=Q{V*@Ktvt|pf6?cy7E0v zqQfCod-z>C?02(5L666%dU7WrO3|ekfUU$S$$=e}7(NY3U2|H2yaBSn4L-JB=$UtY zyw|kDCZ!cWWAsdTEgn_nNkYe`2%t_=GPeAy#p<|RNkxCL)v>HCEu)lx-_cBfMiXZH z555J^8i?+)-b*Qv3;(s7Z#7l?U4=!KJiH9V<$xVZv-w4apMdVQPVG{N5qR!V16Vx} zPUFKTq&g^N{?8PMrYa`Z9TyAb>I-k3>{R>v0ulMKsTAD(5fmZL!Bb;vZsgk?*Jm}} z-33U%+2{mI*%CX@S&|iWTWjUGdKF+O9&b-CLyU?d49MsUgzRM@fIu$bo-rly6pnKR zCEypfiXTx>S? zz{S&c^n}oDn8>IeLpHN9=60V<ideYnnbW|&lUgSjR^ zAE1dME$tR&z?vz35AL^wV`);WC$70KJtW%YG$e4bnY8A=Xf~c|0d$M;J4)%CDm^Qb zXXHrZw|A_8;(Nu2OvyZwi|#Wxw>cd>-+%$!L#m@T9Ux?wAyPj~9A8@l@34rKpNFsu|6nZKIYl(=tIOo``7}1w+iEjeOZ|V}8ZXDy+ zcoh+Cu~3x01jjCiuVeXezSvIsO`bO9$?*Ra&Nr{H1fgRWP49UOSAf8AX!hCvkcE8I zZ*WofJii8w2mP0+M$Nl9=~h3|0wKb{KFHVub>pA*anM)-n4Q`BOJx+0QZLFjg*FIL z2z@!Z4(Y6ci*}t^t3;4tBVoa<+|Zzgrf{iNvB1cKfZ1%w0ycBv1gu_Y z2P@v@Li$Qb1fVUzu-)P<^a%jis}7 zD)*@Zz`o(?a(r7c=<6z07DD*q>BEdm@ZPfp%qC?KAuua&o~>G0W(1jF!bf{{OiJFKWWMAp| z5EK$$Hwi=btS?UtlXyz8EIhTObu%j zRO-(pyyd4#Y)Z)K4aYj`f@A{7Yn%gzL{1dw@e6xCA5gTyQtEp+Nyl}r6N7!)rU5>3 zQ++bqBKc~lKCB;XaQ7nzPr&04&2iB;<&7iN6XzGlJL}BCRmyED#v>4}tCs%-rUqi% z!mO0Qvj*5GUd#6aMt6e#i(icBv00{g(X+PuQz)GxD9S!o39vYWkgtG;mVl8F_Ffn~ z#Y>!NXP)JezD%9|U4hO|38Z@#G9EtVR{Vs!+w_d}cT% zlLEL_J%4LBNRn)84kPIf03I@>ladj?WlU zy9-Cpk1^djHG{kzcX$bKfuS8M>TMupB9TQ2r(!mKMWGFg=~!QR6m2Kh6?t20 zrI}vmgib-sydZS6Gi2m|2}y@&If#HlcrHKcqi1Hp3K`C++b!QQUFOW_DL}&o$g?Ps zlP$v#Q^3bFAHxbSwn?EX{oHP+B;5OmN3xr9<9yuL`RpUKbD{}(KObhG zz~`_0nJCNoN2uh>^@vOM@mhZ?V3T820$pjyfl>jq^sw`R4%%wTIjw;UeQ3hfh|Q$@ zU^_{OWSb*;wC;o*7q3VS$>EJGtNxtQbMWV z^N7J0Q7uFc=p?Yt&*O(oM z9XgT#4_s14(HLyw-TrN#Y>sBSfS+J9Q)#%Z&?@Zw0uibtd{tvRL*;2W!eZ)neIlIjR39ktw4C zGLlB)w(&T;GC=l2-4@XyXMaE1#HyBuY5qTwapYqy03{U0A6=20koWESgEunP%BeFg zi`!P(B7fwxgld(1r3bd5-Oq#LVBHSR6)}i?1T$werg1DKiPJ21G=gmj+g4$Si;W!e zn;q%il|$3sHVZ1I)YU^8xyq^47_{8GP!p^8g6-tOuDR&#)FEnBC8r0=HsofYstE7`^3dz7T%kdtN~plH`mNM&I)d~yu5NEW z|MxajPVw)>|C--u16Sh*9Pm7dm3Y&ODiO7A4twF}Z5`_WhrbL}zt^Jf0sv&-?PK|< z@q;a|x*eoS_F#ehbX{SWYn z{TH@}gXJ@_UO0hEOKbKeAv9>Ln?GpWi~;MieQm0$1Xx?@13*n&IS}^z4q%BqJhfki za-`#k#OXgID8jqdv6jn=I{AfE?Ds}th~(XLK0;M7Uzm5gd?G^_D!v>KWfl)`0{j5!irLdn;+ zr>fNQZ-T8yu)_l4JMzpqFp7PFe4hCD;7i%OZ^1(1!8)whi>J2UFQiW&Ixn0!rE4ci z7m!dk83bwI@ZgV`rO_Mxftm1q(w_g+vS}_#u(1URZll*-We2qG^ws8ymhe{biiPrg zg5)qtYH4Ysr(2x6(0A7X^Ma&v5!+>#^Y3LKQ?1RU2HgsSwc;)Y8Lv|umk|6-Jrf0^t?S-a;^g?KsXd= zquS3afY$Q7>TT@9pdT>J&wb@Rec@LtzCcjqFdCfRw=sS^Ktp?gft=u>J{~?qu*vK3 z)dsV9A>DFI*gn2|a=st$v0V?g;iyL$bzp@l_(xPgSaaacWu8N~Biqm>doRUGI!3{h z9snUuw9qx?sdtE9&P2u2yxAA3hXox=5fpz5?)l7aHU=fe(S8}@OGRI>DSW*h@#NWH z{z2S-j9cR3sa_v+a@!8>; zCK12=LQ+C^?G!!;QnBcLAc_$kT8-VddWjKr7iL!_Pa*;xmazQfVa3)0{S6Gx?vk5%z-BXv+ZcG5g^Pl?=(KuVw8-4 z9&QNl!P?EEVfI;jOadBK^n4AV!Q%xMf5-L~-q6^&Xv>j%Mmr=7efxE}=f4$S80=V* z8}Ge6d*lXUaLizn;1ZW^2Eht*U}Ne1kNqWoasr>SJdT^X`hN4;aLWtp$y(Rr!-yIe zC=?Na#0UNYAAwjlv>b#2Z(>S~**y}CNvP{g!#%{N%WJf|PuoI$xlfydvIJ)K~m4zQKu)iqc0a_;=a zj`3h#`4I>I!-+Gd6tO)IqKaz3b+}1*uc%GqmocCjrW?OQwQ`0xy{5FDG=L#=yZ!j_ zRwH6>LgS1>=7Vv%V2Eu`9_yO}hc&2Lldn&Q#`TftGZfI!g1j1O@08GUXr|Weu_wzJ zad-4O+|Br?GP1H{(5v6_^WY+wANF`q3^#ZbeGaZI1#77yljWSKCl|PFb|B0Q*61PL zi--8a7BR!XJMu{sXKsk4BpByFQp!^w$a)qki5wAU0LT{FL|;cE)1gt_qA_Rx>YfkX zPT7@+dkd4x#t|ImfUO0=N15+>f0+H+12(=P0*Y$3&7xt>AlPD}Aq)}rgJ?za8DAK@ zeCthTAqTJ^=g7e&FhX0jBV$|)&($BiOWLwPuVJ*YqTiCpn1%RDS$VpL0Q-OP`;Z6s zOZDODD!c~v-)&s1M^3-9_W}YX`f{4Zj|M1id_*&H6;JBH*uK6hF0=`4!ar^D11W3< za4F5=AlxfNnLh)jB1i5M$2rMgRv79MV`WHn1i2?05FwKQO)%cT_i|1|Y2)QA7We_4 z&N*~m%oH`lZu(ssmOHdoi*CY9a5D;HrA!e!WdgzKAOhCe4p9U5s&7RI^dqdGC>{W8 zR@F@e4iVjTaR*@d3II_J(Dh($Nstpm{f-VbB%lbbMD8|v<_c0R%k@@_%X(EBCl zU%;T`{_YBN*G#N~;$A_run4A9n&%%RNAYlQzS3E|1M5p@CxE?)r(55rSEh0G za)7&zCqz#j`zQQZc7_FORm7t=2InY91fbToU#gBj7zE*-`evQV+S8Of!A}f8Po7AJ z`}5PX(Urk!j?R_do(${`KYlSp6L$`vI8zJFQzMYCo$n16a$?UArLTRLlVwnC3&bWu zgED0((O1I_3Xvlb5KTdg1msElS_0Tf>E7Ir-z^%({|hE-fCrUW3AJZt^t4YRzjjl>mcJfMXMgmaj+B+ff>+SmrtcNJ?}7`)hw#UyL?* zl>+c22>wf>dk?Y&xt7tNs|Me22GRpIMU|{2$f=B53b4q-xf@(d#Ih`Ym)ii^>3L6| zRMmO*I8x0eJ>Y0PdrcV|HgM|irs*vO)qg>z2V<-djv z6(-oPmUk5aV{W-SJCGl*fB`&%8Al;@r;G11tkZUeN1t!GT!z22#0=yXnU9YK7fj{B zA0(W(zc?#?uy$LzT8wKbyByS`X@~;P!B^C0n@w zuq;vz+-;FsB%FzuNUfek{NlAG&;GOYfG~~ewi*uPj!_#!!mBv<3i#*c`0r6%*R>Vl<}S9 zd1i>hOSIbh@UJISAi-huT9@IeLOciMhk?L*5*|(7cl!SVut1jptnv<~yL$g~I#LQ{ zJtGtb=}3jbZWb)lxHT>@PkTdw{Qxw4Hv~X9;+xSQbD_7tdWD;pq$7( zUdSa|7;_BDPzWFe+NmiOq`y4RY*IT*0`Ee+rv(?Q~?67}`bBm0a zzvJr-8xms&aHSdL?1dfLOxBtmT}*f)ySQA+A>LSg>guP6O>>x)D4<;a8<*rZ4XAY_ zq7`!6-u%DXBL7bsfrrMYYuj!pn48# zeT?*0e`)=C@oSMi&sXpx;-2^xdm&-u+s6L43x__X^-mYcXms|#Hp-x`W(4X4lGxqz-+Ug!r7pw z!CvW0-YEsge-7$vYF;8D79o)@xS6a!}JpTq0BKVRo;y zqXbLO8XUn1a20&BoPa%9^)VjilX1_Ct|Fpv_&9WBN3SuhM{afy+V93+m`h_|Ngjj_ zZ70Kbw%h*v9)TJqP|G00&-s$@HbJPqVZ$Kt{QZ_Ve?;h3HErQAU6%3TdhIP>sHk|j zN-r`s_ydUw)$C>wKIP(=nIJxx|IO&ZeK7yGZ$zj#bXfOVA^A(+a2$K1#bI7ZS3f_m zMLQlQnuA;bKwS27sCdvYSMzPfcUSwi-nEFQP%MM6>RcSy_{{+b%?W7v#X`j@l%6@e zB)j+7Wq3e(&qc`V$Vr{K_yG?BVOTB{`*qxy+H7if6T5558w3J|Fww`E%w79&YkZs6 zM@Mx4o)1)Agi`~eeWfQFcYqncGKINO4aXZMCWwxR&zge-=t?J0hf$SS+QtAo5OyQ* zfu?sG_*ctSB?RGKY(>qlmq!)oG3l_*sZNP+qkK<|eOCS2G3sD2+k-|YHjUlf z)OOb4eE2nw!7GlOV93}3BYSd7#H{5}DZHU&Gv3a7c-juI@_Rp$uq;saeJH3HIB66N z;wSRH^T9MMzNJB@t^1aaev(_W!3eLuT5~nQOce31|B*11A7$oN2-@e33wuR_V(%6b z-vXhpIr*==GU)wSo8HYAGT8*EhTwFqUogqOLH9+hayU`p-8vl5&e6X=9 zm?X4JEjKt()@2u5vZm+Ez-piGqC#-PT%C+$SLY)|j5c|nI;M47Hhpp>i`yp|7C^UN zaTd!A9S)ICw20tprDO=_9w_%rvz{GPY z+C{>ZAD))6w2mF&Pd|UaCc(IQd%T|29{2N(I_I(%`X>r8G?Q_r3J+y?+s@^jdSJjxNq3XJc z{GQA}Jq5*wqlt3$0`UwQ-*WKve7@jsMw|2`5Evo0sw%+S(wXz^9^U@c!ZY&6J7l4G z(oLpP`g+)D_c5RA7Ve;IjADC;Q@rcPyJ7#mikilbeOoL4!6WzPYqfd-5{}xcsf+(Z z)LX|j`F{W7z7$l-DJ>$Q!041#5CLU$gVY?Qv~&&>2?+s5mnhv`BZe?K6_|9F#Ars0 z_}$?9^ZWh_kKNaGU-xzDd7kH-ZqABW<-eTvjZRfUUzM%*Cs)i8{lw1)G@c%_wwttV zzKSs)D;zZ)=Xk+C(RRXkdaXoPo*;a~*kezdUGIf5S>9i5T#Iw0F;4hmI z#2j&>Nk~D^N z-nRsQ5t~YsV-r>tTh8&4kW3fjVw2%@d8Uz+aJ8QGp7$D9xzi+4A2so;eZ{j219`WY2SjO`M+M!x_ zX$QktPZq5Rx8y^5ox)$qN=a{+AGpx0L?*8(b4HUVaCu&r`cB@K!h(|1PO;Us6~I!m z;jMW0V|oVr5=Lmvn1teIq?Rb1E$(fYr*O82#vAFAKNKo-naD^s;6IRh>wkac=T$0{=t%Oq2y^XQ4ZeCt|v(jKe{8;B=7aVUn5qfYukW8Y@fkM_686h>n zh+88Eu53w;WW9S0DY8lI%n3{sv24jyhRTwGWNNNI)`|;bR-SoF4OL@*-slSoPTA;) z7kuyIydw&&EVhHH+{CE$1dJp5%rTLcpfv%71>~9GOSW%Fz zbI#`7JN|ffqJNi?M**>JEM7vJ!1vldaQc(sa2u(TkM7?#GQo>CVL7 zn-6Jk^w~!aejswHU0Yl0WmP2pcU&(9zAe89dH*7frJbBhFNuqT9oRu+&3d!8&ASJ< z*ex-NiSMRO@WYWVag9L%nLBEL&7m{i5SOKVAi+_c=oT7%yjKA!d)U{vtVm2eW7P6- zj?CkeV{@q6-#FjB3a%6)dsYE_%fxM)j*h6m;&mn z)}T@W+-buvEl3y&d}S^R>#C)m`1Q={Et!Mb8d>^qBB1z7i)jI;-q@^{!Z_v4=(-+TkV;hca5Q*| zK8p%pI{SX9Z*l1AR$i~Hu6FX#{&4xLUw-ib);bcxmya%P)xRFH|0sM2tjLUmHNUg6 z`YqeYKKAcgytuSxJg>`JZQGRa78iEBge56v6({7R%2U*TYM+H$y%ZI}`Snloh_|bg z`o770V#Y{Knyt9{{mPgJ{1nTpMHOl&MQOkj`Dc?53n_fi65qp5@@pr~6riLkc@n;ee654Qh;}|h0I|4m(rt^hFlEU29x$|DueXh<}8(Z69p*8hgW^g}j zoI~bi1btq6#6z3v(7h8+sJ6q5(+^a5+UT^~*?q4GRo*P@)GO*W_%-RJ-Qq7c2TL{Q zF8N!-Ko76IW+w$qH$p}u};NTPdXP>OFqkFHV^At z1DVCI1r#5Aj32Jw+7LYaMw&2CYfyT0yRH)MjnkZwJYm5!`T04MX-Jg$8zHT6Fm1zs zRu!h`X~nuqrSJ%F!_@Trxrwq5s}Z!1HDU>9STqPH|DaMuL#PJrXa10Mw44DVkMCaC zW-w%M7a%IvhN>US+rk}_iwPd9Q@wo3e_@q6IqlJWL*jSiwjoJM$a|#YYNz4;4%8|P z%IdPz9cvAYFR(1|;{PgLFY-t?ic9$Y?DNL=_p&}+scdpffL5FjxXG3U{CS1rAw?|T ziV0pL-Z^BACi9a>cC|_21eRzA=Ms9GJ4IS%^=n@!Pj)K#ZN9B+mE>Ms zU&Pb#uB8~b`*4w#;ePM^VwSNx8x`{>;65Jo zCrq}OePk|9UxpW?mEqED*+vZrW_vvHsbdl9&FA(Fp)E(YE;plnY%(T8X(ZW@@W$T5 z%Y8p7^*5>m#-Qc7uK!8oQH;LwDPrCn1$PWPXeVWAL-}uXRIN;|D^=EgT%B19h{08h!FgWbeDClHQ{N*Z2@>*nTge`L7|>v#XnjCPwQMEbFqO!nG%2v4 zQQ;nMEIBi>kha&nJ3wFait=G0Q~b>^y1-*8$nUs+pXpAIn%VueQjZ)pE|J%`hQ`c@64UQ(c`@ z)ZGbrkF$`3#1Y&lDy^vtw}S+*%CuKc-ElIC;#f9+@XOL+0)LD73x=WOoZe3NrSA<$U-+zu^d^g{LE|PCyvE`tn8d52?X75>q{XN; z#(^)Dvb<~w0I%G@3&(nvbXtsaumVc^ds0$Tude3?fj0SwBDpzBodQCJ++33AmZVI( z#nu_&YjJ8BT_}Hn+-Ou~+(Q3rWAMt7WKb&Y#K+hCfX(#jz>X0WYs0hpRKI1Bb59}M z86C3pBUp*br&7BtAmL*e4Laa<)8jw{iA|r3vQsrP2jh(q8s7IJOexGEK3L55b6m6; zjbaowO)M_8aw2v~k>E9)h*Jh9d58Ru(`ZMpJEkoV40P-cIRzFN&DF>l2BP0y>a5qx@JB%GLTUBxo%*L+AQ8iuNa%rle({%AXF3;h z>9@;yq;tNN>R-gLXyc+Mdfa;ESB6iObXR-U87I<9UUfPKr1o~7JCUBYIxdbn%{Vn~ zOD(@35~O~F+|88S-yJD%u+uUWX|O8h;N95=tbtD4`jY;1+VpxBf;*(_w36Z-l8nM! zQAjuHY%aM3fO->n6zhBOazNb6@hKjak%6}T8U{Tegs>qX5O&tpm`tjTbygx*)+)DM z?vIPQmrk3;>NdW$)K?*oUyw7Bb;UoGrnj zj8{HORxi-8TRRd6E2)u-1t_LGIVU27x)+7HRlJ=fQJaPLgHo)DDhX?+Q{&_vX-B`^ zqeX%74Yv`qJ*k`0Fc(I#Z1;DB_hN&o7Ek#zC@g1~$*(*a#UJ0Ed9PKR4$XeTmgE`p zNfo-i=R0I#WI*$d;m`ncYjTf}0_eP{Yg50s%TSX2U4?)x4 zqbEg6jv}O*`8sbGoM_sT)9G9aKd6wYUL{dbzT^~Q-gBj_ID`ROt}qZOR8aA3HJzug zdHj7@g*_RngYIh zu9}{o*v0CExV~xX(KwDt^T4Oxj9Ye5OcPpycb1obON6?C6GCFjkr|SU`dV@PTkiJb^Y+8t;{!X+|hcqpF;9le7)ts!*A1kYpdX)dmp=3!*=z$>QIH^teb}Rmo=pn@=sV33aOkCM^tXa6gb_ zs^>{lQpzoSBdC!-I`q0Ufv|qFQa&Hjf7lVxh!aPc$;F6 zqNmaU(a=5MgME>09j$}=S?};8O_0i1{3aQlHcpgObCnQc-e??Y+oR^-AHJxsJGIBw ziBl&y`>QBntTW@ zz6FU|0^2*E$zBY{bA3I2&}A_mvcGR!EFEI}V8o5B&goG~>S^6P){vLm$T6Z;v49Ve zaDAEKkyA7%2`e(=$9tc}&_j41vIc?C;^4<${M9UDT`*TO# zogi^ixXz9Dh&Bd5u^ADlzwOqIL3{A>(&v-Vu#NW5lln6K^Z8}J{R#9CCJ?tUNK}@l zEx1$WpLrjKoO4fmZ!*6X41bp<$SvtB*6g3lq;z|v`n0m7M^ENuc`~0&+=NHL5bZbS z8XnBOQ$~?@|fGv@#0vq8wsD_fvA3})Pn+jexO5+-nd>$Iqka2Lzs~O zAHACfXG%O zYP@=5lt)I@|4RSJ)#sIz=v7$u2^y|OFRzi9;F&tGKMKm~A1MD00#xYBs_|*ii05Hh z2~Bxw$-@L&ExIfuXb*Rbl78z~sCOEqeQ+wVDG@Mnog96BkF1JNvlE|yM~vyfj=d29 z7)ide0{@NF9$NF?cYj(0xQl(BoUVFvTZ1mM3iJS=ycqz6d1L9{8!noI*ILKa^4bkY z*0H(Tk)IN7+>fGI;m69UF0_BqLI;CH4ObC=)|7rN;5O`E^2SFqO^kRht#@Z?s>Hms z!lD5dqXn;q`g=_V#9WSv=R~Es+8@IT$KvQasM^b1u zMdAlxz<9F!sw#{v>y3Ib#R?zzXnREQbJH*anpg!EJ%zfcBQJ^)r|TWfWscIAsP+r@ zk-doAeQ^hqs@LG}B~54FtnyMsWvXdz9giIh{7q|P=`81qKm)53H#R}>Qt z6p8=LPSo-j9p%Bi8f!itn?e=JA4Kq`J*%>>E&#+N;?r4{_SQCjVbR6_6YwBS*sysA zkZ=)64qi5yn;XGB%26ETH}BBrvZ;Nutw!*vP%YNg)oDivffdUQ_F^|AdZ;RmD%xDvznAsw(g6<5x*VvqwcO zVDRic4UhEUV8{}3G{1s$fc<9sL$g!Iq*2D_MjJ4}HkK|Lp6T3ZGv%c?-K*FmBor89 zl?!N6^J)YS57i=n-G4q4v%vtOb2R@enAwpxdpv~?)-DQ7Kt8f-7>Eo@Wm)(XLXvGQ zYwEL#pix%x0=nylS%Ep}&TXq5X6&mGTx3*>i9&Dl#hsTEir&2Waqj^Frp)-(T@=BT z(P!^oRJt-1{5h1OLrR&m&uw>w_&(z6AMr@zfnea#-oa**$BXL{;?qY4%MftGz@i{l zPTt1KN&|pH_zk;agNU7e89&$38nQP_Z0zFo;OZ27m|WRYeRd?4CZJ)37!0OTO!!I= z=l#NfeyN~#l27+dk;B~uT>0}sF$I;f?aZ1j)qY_$4&ss3@Kp(0fdMeYX{cd zFaPz%Gnwt&g?ItlGbHy3WCI-v>~G&(d}eFI9g)$zj5+oVmM@k~8xQJAC8xnht_^tK%)T|SKX+mYTz zh_9ph#dP58r@#&T)?rT0xJl?gwZtk*=yVwpb9o|+WbQakG9c`Fqf;YU8s)T&fk%{j z#L^&s`gA#=qEF{leWkTAXDMQM4%fx`5y`_6bH&C?K`Td^A=P`2_()K`xMWVHQJrd^ z_w;!`36IOc$7<|(7@BbA%b{Xp`IARG3w^Aj0QOh)by&(4P|qmF?*F>V;r>Yv->HSZ z&{_1e9WM^nE*z^>ahMpmvGhVU1zo8XFv>@QAYtkLJm9k|R7W;4fmiSkUvI35wL^Y! z7x~ZXmQk?WI0_X7bYL$yIq|B9<%SfYVs=lc{a^EcW=}$l2E)Yk0Om%YuA@3n6@{!M zLR}|rrY-sC;>2NKy}RsLP1&>Ibajllo#56Nz%h~k+`z5y9!rt<)3<9;kleg}Fx+kO z4pGT_oha71o0IX4O>pVJH#5NGq@0_mTKkD?H1qHAI(%6M*C0-RjX)zO<}vFG!0C#?IFsbg+xc zv@6;c@4Ru0Z(UPTFVRADe4}8MA3Wi2h*U{>(q*gDUYt38Z)A=JxAkH1D9r);WTdtW zb-b*mnxQ-$4Y+Or9#Cq@MgSeIj!{IWX6&zks<;CEmE~7i>4mLh z=m38ISZEWA4%A=&_-?EjX%2I`#~Vi7Z$4Pv409(#OIdy7^y-4cl5%AT066LYuxwx zn8?8|E5A^*uA)SP-#K}v>+J@TR$#{lP)#7r$07MFrHGXA5O#Y$NZ}*{Gu|K0jjwik z9RYIkhExK;5fh&Ib(~%NKPmk9Q_MX4m8w4gYWN?Cf=o9A@9F4~pYW$_eejI5;ee(a zae<@`pa^a}rPjk&2(GRymP{biG&+#n>P3~z)FVPZ?L$-!_nwR( za`KTv3vv%>rTx#C143))2ya*WOv5Fj|_P6iL%53RtVcv`)e&;^I7TuH;R1b@zk6WaE+Zn!c zvtKCK@@uQ4TvkCCM`{$4nAO$zguK(f((pN-o0T5(MH*E{n{VZN;?9}0iXq8Hk$Kba zQ;n)iNXT_Z!tk6njwPsB;au~{X`oq{jo@bFXa9SLQrv$Jv%WLWRZ{#a4KnV9|4ow+ z_dUZNDl1uSbbKxi)>1I6vMm2x-aBImI12Yno45sQ%4+;=)v%UZeDTIa<)seETVgV| zPdqTxD{CbAN3o<|qCjeLlu*Y_H2-7r?AY)d-pilANB2dSSm{vM`~0zu9l+Bz%1FEg zJa~>5EF3rQyKm5$GV`UK33gjF5xg$`#NQ!oc50K-QPPe)F>RV&niU+B+o4&JDg+AR zmNlQ&wu2`WAGZ9ewg@h!g>Z>mYm0u_Nu*O?~i3yiyu|U24 zSZI8$E|l}Q#srupi)Wo5^*!IHyN?B4`YU7NuR>k+C;I>8 z4d%65Ge=-(3N7_FDZOQbNChrEnfcLRRt}z>Z>_w(gYWvCp%<8c7#r|Y z^G6YW){X_JS*|W88mndqTrP&&aUIRS_Zui^?$teAk`(A)UvW;ufEP6E{`msLn4ceS z=$M&hjD-f*>Oi|yB6jLpT^kthEz#6SaYHyl3cR?Pbr$t%8gmLR%_-}|bK!qcx#=D7 zL>CcUgQ`ZlMob6FUw9qOr5M;P5N(!j9;(GC0?@`fy2Lp8r9L|Rf%B~|(vo~o zfAYV41|pvS4$6 zli0A~ooI)R@RHPHnuD|^yJ2ap+eX+=yAp%R^rS7Lg2-UArc&10RS!j-{wBd7)GUkQ zqfivfA?zq>8W{6Y5$mJRd6GgnkjNAIFOeiqYC`Af$#UFQol0QlB|0`x1sX54Q=17| zH}4iRdK-PVvAX0RgqJg=j)|{EWo`QIdkW(tgsta$C5IhXX1>qdZP+P-jI4)! zngnM12px#I7z|5hXzwONXQuBnVQA`&acy=x?f#;)^q>v~_zpDn@XOJTh3NVj^&~z3 z^=x{>-=AY@16dUIQ8W`fQPBjxhq;62rZV>79v*mmFXwhvNf15mxZxf(ijd3#MvqhKGzj}BUCN7>T!ucro z`)uEQGZ^~U$L#itsD;CCzK#XHvPlvbzQ(Kfy>J-urVfsHK5geMufjrNRq+9^ZXR(< z<%+#l@=THOQVKioXfSf_84PH{Z3*}YQ?5x!%Hp8FbxcS_n&y_@PkHfl&S?DA_NHU^ zyH%o$!@{nSTaG9(F8ec!Xp`*1tJ1bq2y~(+7~YXpT5Bi>cWlk|y!p04RrY>ew)e6q@TD!Mfc=OsH}4{^cB0qW|equ(LhteXkfdvrt!IsnL=dVJ#i6uJK_OT^*7`BCEpMK!1f{Nj8bYB*lskjo0X6lbfMeIvpW-=n$=Vu! z`uPgYlDJ%%;2hv39$5IedLFBAIZsz&SMK{ua73ax*;R-SU>Y<_Qlvt3T|^UY`!JdN zwWjGv$_N#QhJu3jT!veLL{6?(vI!<8=(mp(`a$CAq%WK|%zPa~iCH5#I$QUe86H4w zSXWuB+boao^32pl#F{BKXr7ejhFLQPwR-&g@SmlP`?S;s(4Lyqyi;)$-I6_hoUR%n zuu1DRvlDmeNfh_@q}6*HuBfr3HFFNS(OrjW-9R z*fy1TZ`gzJb5ifUnGf55WczgzJ*hFzmwS;()VUoa7ehu`wC4mF65>AE1$<;=WUPJA z$)jLos>72b1BxNVSnJ=*)Dhy@t@)Xtu<~3S>@qNk5B=mg9gBmxDzzslHKThe6MkG5 z(ix5VJWj+`ja}64lyXWvB`^XLl}|FjW~RNzRKIrIxPS+35-^b5(4~eeQokZu&Dj&Q^N<&u$x)M#j3)hqRB;nKLb8BRB8Ev z(ne7$jX@M4n7-=)8TGaIiKufo%uchnWf=Q(%NjbJGZd~LW%Wt`KAJE3O(5R?Fzk3> zRcB{c=8-ixled#&2E}-3&l!pxG^C@_o#jUkFe;#2}G#-2~#6Kt8KGK`u zOEf;?oop7taWDUOu)M}FAa42%086=oid&CSWbu5L3*%eu+E7x^t~YZLYDE+$`d{{1 zXG8Gv|J0z|h#`;!sT{*PCHoYt#1cczepJZ3am_4+S=4A`yi6>5_u1f}&7tjSq9L6C zkV+adkVv8b6mquCcTsiHl}0UR%Bz>|q+JgROV2%kJ@dvriEnufAC+=e`?V1JX%lVl z;}NDB0rg9sDP&byJ`)167Prfw)ZTek5Z^QMMa3MeXrW*={F$9~M?D66ZCjG*cUUMp zUN!nW6=Gu(pn8+g(b1SQX7}} z!@!D^O*Olf;8yBo2zA?pnxzR)rRGG|uYJd3nR*5^xjOY~pT?YD+Cl`%} zX&z+#YT{I#L`%87v31Ym&usC2!Jul=qBnGeuXR>Qwqgy9W8a5qP{c}+uDl|>FW71u zXfwwJN>noD#G?N=04k*2{h7{D!1K_OUcBX{L#J63PY8Vm$@!=go_-B|8_2&=%4MAh z+E0pA0o`mXmV%n@hoIp2{31i8v`pXSpe&SGL|J!iFUWi7S!A+q`gn*bBQ>kWDmwq* zo9?^72B(wK|MQZhpYY68sMV1eBy>d7_s&>dE=P{***&R#xHi#*QgtWiVw`zrknvxL zvGzH4h9>;7;}LQ(sDx)H#WTl+3n(F<&1^7**)pE{o|p2cP}qMyl|zEU5Wp)QS-uBw zeM_#VS-gzKxggmW;g`g+Dgl{dvc*<$04=}PKONV#o$>UZRC~TohAa;YF@{F_6UmpJ zVizOEX}OwB?yX+m`&%Jta=ZZgyrATEtqJTnk`Ct5YNy>Sa zYDG88c_4)aQ_d2AwiLIxCVV3Eo!Mz8^_^xG5i%bA?Tp@xB zn&@v3&~$NA-zcNd?p5K26c&D1QSq`n9TvM}_BR5AXyTFYzz)oC=e zs1|Mh!-$YaUnAsA~&`+lBMmrL@5#@S^lGM66m7j0bxtch6Q z&%xSy;Vhl=ob&CB11ZTpD2381J+r_D;em$23u-XbJ<^JqlN$op zFT&)5(50dLG`>kkt-{NiOQqUR;=z962rd0HuH@G!78cUPA!hsh zO%D1>(bSp+Ydrux8*`bw)GbvPzhm0#$g#+hP#xbb{WWNiIRviH13aHZs4CY`u-z!X zw=RDAkIn*So#djZ45So%6`xYdM1O1OH`+aHiE}#}2#Y2~SmJTmA8ysY)*A3;Jp}w@ z9{_q^IEAk{^1P83I{jiQa7z({gH`E-N!bFSh}UO*T7L=V64;!V>-p`{{18ST_Hb=mJ`waocOpYZ^&w0)_zq@B>n2e0&uQ;% zTc8>t+Ng1y(p0s9K2^<+rq~vmNyQT1)ztM`|)8kHi^9PAen6W70u; z{pNE?V=u_fU%v?mjlK$}Os_{TMINbCa0i+PtTVUe|n|gl$`$VRt%3~UnFy0yLPb;k(1G` z66)2BW9d6Y;pA2M*P!ZnsNt)Pq;@L)#W)CZ@%Te5RB3nBf@Qn^Ic4_ie z(V5qu)RQk+v}ndUg{I#DWEG0T#Mv@jdjr+xK&tf3q)C(SS+B0+C4G$-d#B4WWy)n> z;biL}xLIAW6jYFEy$?%(y&EgHuq+Vsh3m7Nx**Y%|FF)YG!FJ3qi8hV4 zIB6zcrRPyZPEw<{sO*ro=xPF{|Kb9qX6(|hum4N~6nljZLkbTAn>LyHe?@`U&Rs}a zCYxa`wT+Nyw#1^AZOd<4T(a7s^G}v*?TiU5akl~!$JL5z-H z_zVWMYL6R31UfD9n7kvG8pBH+_!??%*eb=2dK=!iA;n=E@EA?~G%*br{qeR1U~ynP z0PD^V1>~m$4Vy_SPW&Ccx%8+-|Bypp&8tijmT>8EDhZ}M>=#Wqdc#Ql5D?@n(xUBk zvyLnx&@DhKw1 zdYYKJ?PCz8OU*Yo0^bpA{r53r{t3R~_gTN+TG~5VpNpLh-_eVpKE-F%WLnt78*$f! zh=fH%l8Rb(4`63o;!{SP(k-;t=m+V=JV;_D;;%=bai!I*5oBEP#8>DFx@6&8y^iO z-1?&zD*>AdUNbxN$;CAkc>Q)?3SO)H1H#M~Z4%VQ3^PL+b^8+*{?Drm>siatl%d{0 zr}JC|MHqFS3#*gqotnuM=` zt5kgTuG)_u(-rG!t;{%7Ti-C#cO+N-1@;Prlc&-GQw!(>9vzvBgcCcJE#Q8Y)n~s5 zognsv{d~|n#1~ZK!W|m~*Y~7L<0}#jXC|km`ffY@ZMoCp}dhy->{~sjRetf6lkTjnw0>tgBykSocV9tb}13 zkhBDlyjZSKDs$jEt6Zt($2@D!)bR@-61`aAkG{fBnra_yE0X3nz*C0__ZZB(8RJ%Av+Dl=9<^d!X3+vX#F?P{ARy?{g6Fa z0#|dv%hT2mztYy8$e!WDG*vsj0bJMx4(88wpWL~ zEt3vf)H=s#)>1cSy<~&rqR_eSOcP9mrt#mn`{{I|x!X_dI45dnp(9zzxU`OvtE0Xi zh+7!&ikJ?m-WlWoGWsO}xn;_!E}0At=DXT5I1*FLQ11(Eb-&O!HRZkx3{@k_t|?@- z@b+p0@oeRl#DW62rR~6#qc2Cb^1FO-(j}9s%a7VEkkf`TamV2R@pGYDU|S2<9Dbi^ zqAIEF1SLC%M;WOvJH=S^4eXEZ}!QMRs}mWhD({kI?Gv`52SN4v^Jj|uVmN2`iaOJ2$p z;I5L=E%X8H^N81W9%ip6aG_(NG!4yf!l79J?RA+xjhevaS6lcVPtaM77E#Jyt#>|8 zI_TrK{z7|y$I|BC!NHL5QD@1RlfP5-;7{*lEvn-D*U+I5DkHf5OntV5^pjbn=U#Z~rx8E7LSDSnHzs>2jSk*B9kbks(7949=KjqDRNir@?RVIDA$$@(hsBa5DPBsjBZa0i}?yTd3oX-mkJE4|K?&qrIM_b!M`Zz;hnLg`Z`S*!{% z4Zf6@%fxnuXGivpvZFS^@8B==;^njR9GBr1+E%}{^}r_;^)6b%5vP@SF*BQ10~FpT zDgEw{D#TrRk9xhaOcPXwEJX?mK+?#3!k$mtq8~`$9{3VD6&3m|k)45}D38Yd6b+Z4 zBumM1C~^w0Dz{fLOj_o&k@AEFJ!;OUywu+9XvN^OOBk_40uZ^lN$8zsa*U@pafWSk>*VQ`}2?X~iaK6O^_wik310H3NIdt9^|oF9I8`110^diEB2>~$}lcYuOY2GX+rg+_)voFCU~ zSw)||IT74oDt5OX_V6`g|qXgRAKcM zTZQtG59=jD*rzK9Gn&Z+mk1eVp`X|VqT0FIfcj6JOQs?~I|b=2ZQ~DHlDh#uNUtt6 z!YrS(DVy}wIG$fSxUp-p?OWR~|4sDnWxi^yY@jJOnbA|H4~e&$@y$j^k%DW#FgzQ# z#r9)@k98v228#V&ezEZ#x8-QetU5#*?*t*sUpVG7kpO|tzsiy*+nF*U4X6@z`CKZG z^|aDbB{wh&0}=%5uN%-5~C)FTb=cyi~(x3}7d>t+voO z!*9tAFo_BuU{|*KKtq5rucaXFr$_Jn^c!K}m&Ri%~o*?q!n zQ+%^j^ZVITGl>SpwjzJh4Yc*EE5-nG^Mjt{5p?1o?r#2otjUTt{QjyLug*aonJM6@Kl4Twe$BcvXpEXand}ZODwjxm6vqGzn}1H zK%pi0@&|f$-H-@Ypq8hYYt&>32TLI8oKPEU7@;y?-U1!k4tDKGN}k=KGb6IwazBm*2!`(t3pA0%6lhCJoGHYI8Qj@0sXKX%Km7pv_O7&0j6D!0RrwS57 z(K?e{$S>xCi&)vGmH=ZhjXqQCBd29&nBh{_&&V%_q=rW+Wh)2lV|&AG(-^`y?ju0y`SvJjjpvqHGIp?t0W z$2?^^JijC}df3b)3kUmff!DOGeGdKTyEv4F-BJ!XGrhP08XPhT1>iZ_xS%-CFX)A>N8jv?(Zctr2$LQvpo1*G7PghY@|B%Zv zZ)5;(s;aF?nw=aD>lh4HrVi+zq=Hl zEoH06wpC71#%yy+QT76!pd_7l`5{KRS?gMh6aTb}RWV8`wB4(lG5 zJPMz!o@`dyg!4XMcqr8h@ns~%dwGQ3EN#Lv?TD`l15u}B-rLt3_ib`O(|RSMcX}b= z6MpXDNX@*UprG_WfBX(pje)|NEoZipX|Z*sk$f(-I@u|SD*6A_+5DlhEG^)B=e_(x z&!zlqBuqC?=_R)d!@z?>KDc?!VnTi}qjpbpwp4F2ecF!84$-JRT>n2`IBm8AK0XpY znYbTE9zW3d3f!fxNO)i9Je*N_+SavM%(@=bbJ#rF9$fQx@d#r#*BcA8Kgm>aXYNyGyYkLp0K`^9*P4v~W~BD6y&&iAeh@A-QsK5eM&uZn5<@dGOUa?0bk zqHBMA$yP(t(1lHPl89Z>ScXlAVLn63n;?q5+$UCR=#9+vp!ruX7N0ZfZgf>oODShN zNUm;l0R>(uM+5%_7yOV7jvEd}4*o})SBfvqemljOq>98@9RSRyq@wMZBo;k^HXB#{MhxqMRygfrvf!jwd$W`djp74hswo%$81h&Nf)g}MCUW_WK6*E7Sm_7MpnDCq}7MS149SRtw}2or%Xa#e*^a5IF99Ev0@mwUoQ z6z6tXy)d%->lk5*cM^W+eokh6#`Pc1jhO3hrr{nNRc}M30PFRU!Zr3!GOctq_eG9f z%6*d!x%0MjG9(a2&^_ri>b_GjdcfSIkxS*9p_Np*55w6~NyGDxU{ryHaA$b)<(cCr ze|&lYiMSW2J61uphCZ2bu0swl4YKk9x2N$@(^nEiDhr-xQu7lfm~sQ1e?#2y&X9=? z;_gC@F%|VY*%uo{O!ee(xvZV1nR+Q8cT{vVZIifJ43do`>}@!Z5ghBTdf$ys?b_Bm zKd3(e=Xc73QrUM0Pzjg84$SCBUvcXjSB^UcxkaoX>4N^_JY$wOo@LBTH~ z&n3W-_sns4aJCmTg#d~cw;iR~J<{nckD5uTMCw5kl?%eo93;*U9t)t}IodVhYSbpt znzOu+T&5eq<@j}3Yo|wu&~=!%c2GJPEoS$2SQw`UE=JG1j#>eblpeCxkeUW=g>k)~ z5EGr@iYr^b*s&_PS%`GFalRT8hlS_J>k3P%szDtAKiO%&A3)l~RW&f6qi<1+?x?v+ z%<3-J>KSJa&*!6-$yHCiu^ZvR3}WxU zk9C*h`L}GT4yA_vFH*AWTL1jM$Vq>R608j%YQZUD!B!9@x9 zCk>9J8)idOT0MYjIP3VgW13A=8x7kz(08!~FR0AJCn{FPDrW-t3;oR^GCs+sg+>QS z^{VFcf0C~v_51ti*|0Ux9=`6vk+o8$*A&*Vr7QK-J@(mlal+d}*t9?gKsC`#^--C7 z9gyE8c_W18+j=GtGf7=$2fS5Ag@Jl;PKw7#3wZa=I zH-;k{AjcfqGVPVhB9o%;dmZ;@xwnPhPTE(qr)3_(z|v!}%6)g-@~6`e8u!3!_0mVE z6Z4si1!e1j`g>%GpU<6FkOs4f?9PQbjB}70sC*!uaMa>jx-WuDeRnMEC~? z51qoPQ{JDkQ^ef6UK>ZW3wLK%5$|Nsif=nUeD+WNOHc=S*!^rCame zoArY*S*rVcVbt@7d{HI-;bx%AY}Ar&L?Znwni->0)<)2S69qkT%+5!vLgqxb^3~~$ zF0bk5RL6QvP1BynWz1COM3amsd?^)WZgwNvBCF^Pfey1`U&T~ct>m##5pN^U3ms#K z6XMd#!+GX*$ z#k?f&GS!W)wVfQ*L81+{xKm?epRMtfOlrs0Uk>YuybajE7DJhr8~7%Cu7l6QgA-I1 z$nbbv>*Os!%ey3Z3~C|UzBaU%8`YkvK-IlwG?GDgYN0sT+!fW&M35y8u}!ULkCl52 zePpmsfJERsy0vD`4_qz7Y=L^6$wYdGrX8AWVQFv9n#-z4D;^cJmZ%uT5!&{EIIfQyFPl{fvgPzD93;V2!Qnly{3Yi%7qRgMt}BH&HL zHED@8MSo=Ky%+q^_4yt0QH!)18!e2-h2HCgn89h`pgYlXD-YtsVHCK8r`zXKvt)!^ zZ(yX15+J{#R3z z$P}!08QPc#N_s|_(-LK~q#SWTN*hZ=SMLVmzKY-_kWgNS(G^I)Ly>cXV;)uKFUZ_Q#Ti@Iv$312rpr z%iOEwjcC3N;$37#Tt4*d_>SvRA1Ifk#2^IjgT?1Nr^!MgA}HM zGBNT9Rfr`vlNwT(daCHpRr7Vdp(D;rp?>ntVmUzN5cDXaDDNW>_xYE-SXR_7yUsAq z$}(4ZSj9K7(Tb^xtQ;HZ3iWnlrQLvIqeSK!QycxE97ng-tARqbo??buWEgYru@Ru0 z76^O(H2Gbmc*`{sqZndjlUg}c? zZV_l?TVu_B8IGmSdJcMl$~nDg@?(R`HK9iBa!_&L86FGMa=VcseF~HS0H=L+yy=Z2 zeOJl!q^*PZ>^yD>%>S1KV^^$NMAq@jLn&YF`!ZpW;cnH9b3i8NaM5z{hlP~b!ABtG zmIMnZ&pk9ZzLtB5O2WEhd^Y;c58ctfA))>vCw8M6J+q2b3;)X_@g^FyR+~$W$>^4d zkn1|NMJ0m_fg zD8b^&Z0ND5>^&;>t$uLpamDrP3G_~!9*;rMABogNcf!%R_ew2>RVWf>?><)k{Y5Bo z1N)kg|1%DOSy83yLJ;G|UI)1buD8v!!MsE9eVJDgWa)zpvVr{HWLn$PLix6@az{{E z$JVTVE8$kdB~Z^wcTn! z{Y?N(jLy^+F1cbL`X!?}&*F=IVwBVMM=fRQAK%(ll!>A5Mw_JaS)7z{dN5mODyxmL z|D72pIc|gW{8`rd8GLZ8R~ioBWHi+dYj6|2BiA?WEFDsyQpgf0VUMK!*%ISoB6Tl| zM~T@}!_eAg_{Oy9pb}rn)X3zqKZ)wd=Q#oW)Iafzj>pcZJA)nuQhMDs2G{ZGIrIX6 z&PYB{Ah>(bFUisn0b1Z-X1ZQ9Byk0gUkXjcKUza^pB~MPiKT8nJlxF5K6ingHcjnv z&MD)0!@?9I#3oOSj(XcQ9jb#-=7BU)!87x4U$2c+Ki2Dh)0A-CMacU*IAkO+`f<>H ztL_Lcqkhpx{XM?brrFw}Glf(-MxTb2YcE6jj?oyP%x^BDDr$kUxD)}uA!ueKjHmC8 zb&2S$#pa;h`k-BcBPi~bwQgfh-xWImBaeBDfT_X0Okbk&Q*f{EAi1>K$)pL(3z_VKb+hV56#$aHRgRxaT`NT|23>eYI z$nJcW2g_m_^|$q3Ei-f}@3mHV6;OIETJf4VM_YZSbG!D#IbB(Z7+L)i^@5q@&r@4? zx#pWg3il$?^I@z}X^-9A22sP`S7XJ~FoGfe$nl1^?dUo5Vu{M%h2$ieF<86a;ANLa z@0sj!7J-l~*4`9RGGSbjXxjUY{1p`^bFW;`$H3CUH}k9UC>PH~EO9-++a5>Q!CyLC&V8-$?_#nltBl z=VsTOdG<@*_iD`bAMj8ASol^?XQ>s6dF znA)~l*s6;j`q*1eMJ?X3{5;4(3pN1;YK|NXiorS2&(5ikt^S8dB#->t@)52zupRAs zfIETSmY&iEKxzAU^)dEANa(GOb*mib zt-1wGSNK%1?dhr9(d|dq2jg`cKM|C3+wbi>4-ky2^4=tT`$<$MYaW1zAY+MV*8E~L zjdM~VZ#&&VucfR3gQu3I>$prG6yND#l&8|jqE2|EUR?B9ibfx(9>=4c{gmU}zFkXNKxd&KdOh6KEz+apB=k;Z|QsSP51hVhxzp*JyneP zlL)#xLRtMsIFEG?zh0tLNZJp1uIlg}RF7JOyimbg3gB^nsq%2?dEpl9EJu65Md+>D zZ%OBi(}R&%KCz6quidpNTo%()5RVqV_84@c>%-3;!x1=||Ja$Z$P}jjz8$5D^6^zy z)3K;ONb=`ynKHJ54H+L9yP#@Ms2k1~pTCdR*`2$Gw-ggHog8Ar5Nh(M&eqm;ba8aa=L^C797=# z8f}I#x>Va+(=%IEGgGOn+mtZV@cfnTpA74Z#oLV{z@8b6ICFHF#=-4WKel+Y@xFhx zFVR#dnzl%^k5e4&OUT__u6qJ?g9>lAZS|zoC!N{8p$L5Yvr_J;>2|>WHOEfEH>736 z?q5u{+uiW3)k|ha8o*I{)vI!7bl=(8+27L(pj=^asb%7W@Z6SsRESR}jWYYocYeei zLl+B}X_eA%b#Qw%B^5ybW zYOFdoMAsl_mx(Y%HD6UdaboDA+F`lC`88IqEk@b4p*t;a<97IP_*OXm+c&A2Kb5cx zO6W9YS#e#cG~`;xUFhXyjNs*#gBr@#eN71Mqlz4x(PhWoZma9Fxm{&%gCkD`vK>y2 z!mVx_k$28KtX)9z{RQuvsmplI z0%MNbJQtrsMvnD|bUVeifjlIH-fc6xA)A!;@})Q~qk!vXnXAG>U4@y-a{}I-sLc^v ziRQ*>XIi^@?S30~Ny9Lpt&VLjf7VYrnnr=N@n6C3|NSCM(l_*j@PRl4XlglB zQkk-QSuNF-AzTlaY{yf_)Fr)g-=UgxR;QkGKN>jyS(U@9^_Y*XxMzPTfgo#ePEmtw zcAfO=^C~|${n<*CVN^PqOcF?9gtG87Wfz#miU_ULT&VWz?SD82VZ&XoU$nX-zniZl z`@LREuxU&p#yu+Fk8i&#k&i0H!HSm&sZVeLKJV*;XcQ9DsE{%!I3=_1Kc{1)Ty9-jH(ykuY=mJOXma@Aq~JiNxhVRyMS+bN7LyOdWWu?03_`;#onq_ z?0SB8r?6-sc0_ESUu8D*q&0Miy{AD4G8X&lZHuz?;o~x*N?{}WG+93I#eYd#Qpu+{ zxyXMkvs2q#TkwaTme7Tvd)SM(FC~1IV7~xcohk+YWfgbk{QINB5Z!)4cgWjYvg%4Y zW$3=#5$xCNVX=%AX(r}b5w5!SK^K5aT)gd0Qi{%zHR>yC=%BG8SOO^nv$A`B}`nyK>Drz?1$RmT* z$9m43)YNRLH9k?UPFC9-p3riS=z6~_TnH{<6x%op+n^Z@*zQ?s+n>4*`vR&EF+RyW zw4nOL)vnT%TP!F5lKS`a;MPE(Gd@ zF+cBr=lgxZ72=;tN3;nLspb;trcI-$npgcZS$m169<(RYb1kBFNT{B=G$7K_D1-Lp zB&Zlc~yO;5TMLI%3hA*zS=ebyW>YJ9gzSf z$pE6`6`+&}0I%6@xagC(daNvO=Tt2ZL38b9fwVqF>jA%7ZORP5gd6jw5~9naYdG>5%s^ zQPjQWGg2kt!F`JZ&_Z%Aud2HS=!4C8Fst<+mpqp7GTqmdw=q5r@|f*HZ)Fh_bsKym zIhR8Lw_lTddAhA&pE(nNDjCI$(v%clZW3kcqkepKB91PEH|4O%82_YDe2#dhVW6tV zfc=~cadarFf?7ukBUX7X#D16)Sb|x8uZAgxn)Y+GUC8u5Q(MP6J;GtYc)9&&Wtw7R z&G3U5cU_-xDDyOzI@!xit&Kq)H^+{=@~EX^&bPzi(_|&-M@&Z`W;Gi zYvE7s0;ta`r0)ygj8~JC6u2bPm=s!d9Tx;E%Cefh+_+A4OLF{(HO}Gzst8406vsDf zN0qT;WKjinUr9KD6s6FeUG^&`+w50Fo7laX{F6he5&0!MZLj_wEMw@6vVfKd z$1C3RQl?VNsutmHW#zXHY^6O0;jk-u#z<@$ucK9=5k)dDIH#$*^%tDQ&TzhyBtv4@ zMBSisql>-Jd^tIYy3<0wlMreisdwMYyJh7DO(@zLzbZ86?r4i}vIIGFO7N}Fb!)i~ z9)CL?@1xIl+4eMSyxMo6AfxhD2Z(M1K{>j1PdylLI#d)rGpp6F`Ja!XE?Vb5v2vG) zqhn=};ZbnGx~(xuCU9KzD{6*%A*1Q~bMzvpUr!F_%MCg#-f=N3JW>o`wsAhfwG2C zpms%?!h`)@>|WxCa_OoSfx`4r6Gq)C`KV6e_t|y$_Zk|}LHKt8M1#*0u8$0_vn~5y zTU+y-s3pmsm+Bf~GYCkjgwCPj9-#tLFDQyK=`^mqu^LB`=2(T}>Ihe+5H~k0-LTNKTz|39T1MM(OpuA!x^R zh;6(+X-!`@t*SI5ikfV2uMk9RRX`o?hb{uL+pQd)O`E*WonjImn|L1onQwKR4R`=7 zB#ZDh8Cj|hlthQ$;qPseugM#&9$WM!3@9+CpQJT$GRjmhHXhZ(_x+dL#sk*%7wS(a z7#%u7gd=`8HrWPDW~yWt<5Wb$#c?!2<2|Utt;27S)tqeg>;%Dul9B=PGOULKi(x_v z;qE0bxM2yf=aeQMxcW`5XjpXL_peORS-L>Y><|F()34Xqg`jR73#STzEM}ghi)a8(r-AQU;b>YMpYS{^<(K?qIp7+_hs# zY-4&LiMN;B%Jt=Q<bPy6-3)D2PT6y_Y!I*6r7gp9Q(c528&a*u!JzGqitL4w-80u zeT$H+M#7uDY+7S^(AP za${r=yI||Co|G=PjB^!&%g*=S&yQaSg5H6s(-s!!s&AsQiZ|sJSHQhjq-aCn4qyk& z!?(}hjVoB1unj#u(v=T`$$PE9t$#+Z7pKhvtBlb_t*-LeSgU+OVL-u)XTsW{D#}!O zi^U^bes0A-@p15(ODVA*rFF0S6?zHB1%{Zx+$$l^*~3CxAnR z)zG8oO}4a-SjoKxqE6iC)sE_d))M>eS zDKl56AIued59#TW%Fh#Og6=rC)QI1-?j3wp3F;_?q+oofhM^Q$iEfp(x+L5x37KZj zeV~pgjM8Zt*EYV!TX=ClOn`%;KwayK7u##3@>zf5CU=FTxQql<+@M#lBi>UxUJ|UZ zEtc{Y0i!ce(|GhbyhFE%k2}rrWcVxWM~1k?V9#$@M#?;)#MqMPpq7+Q%y7Wx1yX6K z++0l>W?ipy1Nj=rrQZ9a0{&FDdw60(>rku8A={p%hI+nL5zjbwIAInZb*YovkYdAa*) z=Rrx2rBbgnI)>flEXl|3|8kc$Umd|6XE_@R=VgR77o3{?&r567BeF&UvUzz&kg%i# zzdzCM7^bT^j($!gi*x9+?*ci|cCXKopf6Q@F3G8QGLwt`GY(b{#-@wn{sTqbYXxMN z;JW|lF+jG=S0r>4G32`(-qOnPglU0#D$pgQSE2mn)lHHvN^W(wP>lJbc#b&U@o`wa z@nD{ENZOib7*`w3%UMx2mcn_0hq0o4yy@J8=#lvoW~BUyU$Ng&Of?SIex|7L z=g&?=!od|}E)Fz{UmDMY9=cEfgH_;4rTw}(#=3c{xj*~O{w63XWPH2%mGa%Rbt?@u z+3ciAb)HVC8DGb7G00~OKZLoNehXq((>Fdews&yM@gQw_DwKtKn{n&WJD#~JI1?{c zp`OxxI=$xW%iU4hZOI}$eTI6R){AfU4`M~xKx-fd*NV7Q@&{~;3cA7LqkYwf%luu! zE5On!xOa`u|5*5S)XY>6J4<^BidNKXy0Mp0{;AZOWC|@t%eB>9gNHHI{*hGgec*J- zyIbe=*&CRJI3e{+eHystxhW38NnFOhlbGn|r6E_im-D8|8?6@)%>Zmw1a-ZNj9Tor zdG_KnWZ9NF1FIS;Z%rOuOBAtO6ylhjXe0gQzxE{ErF`OOb)nPK-BtRr_sIg(Utkq* zxrr#n1|@+^Zi$ztwu1ssXjTTIl+MUOkNBhLo7o0!P?Y$y^1~ehGf*ooE*lsOPbK|Y z(E9wNZkG}kyf!-_u`?NjX|Uf7v~qwz^VfHTS5fTYNySsGnh0TLPSS}0=WpF6YUF+4 z7o%`5bqL?K5@paJ3aX6wOv+BMUdx39fZ^RgJ@?MJ!bVHq0hLFG#9iR0|_JA3SJznL5T z++2R|;EjD#S(|iHl-YeOEW)_Pj!YWyy+Z2giGbzR)H(k3n|HoIIYV1aovYR2$&%E< z;Axr#K;Y%S-|TS}SjmSiGGfc{5Z%H+@1Vtj%Ei@l5-`g@!6tS9EZvfkFxAy(u1_l5 zT(-#~&dH7J80GT2A8iru`y$!iO*S>U>eNz$+=b5u7w=5~WDTp&!>iaWZ zv(3eR1<1VB3tS&X85i^EWNJT<=(LSZ0A08uK0@?VP1PxfOU@RBPPvA4fgsPSmk-k- zFM7X7;>au<8KrK&$-KZVF}^;E| zL%n#yghu$#%Fb@Q+o7%_G{2}Py;`&{ty4=yLgVC5Dbhwr|q=*tv^Ib2agWj9c&^^#?oxmPk zVFCmyXhia>!{^X^o-_#6b21isdmN57)I=_(x|{0G!Xj#WoM&N6#|Ez}@Jx2AiAp%1 zihr~k&dHy<+;No*r$1(?@!g7z1H!^LG?y} zDrvXP9fi3Hh>EN)j0KFEaATB4n|;_s5w26{;=-bXKlKnJ?`*>E!tnX-(FpU1gcmFM zZeiEo-nIm#4PS%xdiwBF$yl%H8&~(w(*M>{#NiUUh(p(X>L#Hcb5OE;eVSzp^-C z!sxh9@MP9mC-vTjR0B8n`Q8Hu1fATE79W3Qn5#Rh+ka z;PJSU4%ERrwLe5m^@cH>UG&+f2(6M}htJciez5QI5$&4I=cAb`viB>X z>fESKWXnbS4_-N{q3aCAw=*U>)^?x(x3E}fjz{-Jz0mT$|NBQ6yX19HUzw&ElSt-7 zfbG;CfUTf-$+k_W9yR7^%$WI;;R_49YFi!4z|-CBgKwgvFC&aW4N(DrDYEEg?}L0~ zvm1CW?kdM|#5ol&rfN@R<0WP%xvGIJXJbzEBl)ylfd4FnsTp%#D(WpZsaHTTUaRL3 z{B#_{;i;ZwdSHNUU2z2L&oHmWl4jv}`7zk%ks!Zr%FnDZn3h@;smx1m{O<AwmdId zoyqNVn=Ttl!-Xw`P)a%{EJ^Ou%)j~}r>v=&i??iTL>1?W)Dz6N{y5`k?1;NHpJU+V zI%Iji^~g|X6sg$NGS!jwbC*UhNyr-{T}3ZlDpaTX*iM~^V(ORuJ%nypfo5ohg3ve` zv!c&6bg_%P^XV3?Bh&Pcx2?ANs;%zxE+r32HXoF@C(4z*n}2Q@H3QIA0J_Ci>(5r? zLD6?@jJ-Oi`bvs-V7mVLYB+j4+0J#XS-cNM_5nr+Q-m$W;R>j-Dm$oG;3PvWx)0k& z1952&@!vs%XV_y+sp3R$cHjfm&|Ts*EzMiLk}Iu!PFZKvLwoV7v6OxSMEu+OBIFllnUHThnUKktigpD0`Ejrw^$ZzC(8{lVL%PmC1*ejzn{PS3IC zN=Uc1{Eu6^>^+0C!U4WSb-S&rQEqxUEzlr+oMQ%|6+<@2Bnt(i)afx&Wn-Lx&h>K? zzbtQV>Bh>ca;phQ85$Fetb^v8b-q|@PYMpM%G^%dxlubVeq6Lg1k)sFs5$M|bf~JT zT7OX&bNCTPERM7tWijMc{rE_n&}#JxB$IU$$fKX0ef2n;8*P`}n1Ql2$Bb$4{E<>&s&-tsDqz=l`2W4I9V!4uYqw2JIb`-TSoLZ zvitPY(PTAFVe2UX&Ssd@+i&O6d^K5K&f|)pi^=^8F^e@BkbM`yRqz41WPn;4+*v|y zSaFE^YyJ1u9(uaxw@Q_nc^j)l1fHRUh9FEs%{bvfu9_@SU#%%%J^8IxCMG2N1qsgI zoALyB2Nx^hob}qSQpCF_PzakBpRwPyWEB30riZZz#kM<6T8NdKR)a5bj3e14M%0#A zGJNh00gzihFk(b$#?1zPa;@ZFHrDjVHA4;S z820y6cM}$6^{Z;L4?dwqmuIO+%s=NvH56L-gfb|!a-j#Bkm}<0%W~DCn2vSvgTt;) zQr>c)`T>g;0QP`3Vxt@3kB{ZyFI?o{Jhf}L=~*G3yUO=jj9}HDef!)-%H6f>0}{JBHw8JEj~hw;P6t-E->2xv@X@xpT(-DUgB_^=n2aj9=D3J5#Pvx z>tjT|%`8#GltNWtBK znTm&AcdA?91efPn+5uP{(8Sx8WLVx; zW(EG@_dc*re#9nMetRMb)CuqL(lRvW?!QD`o*hr)VvnI)Yt3vz;Y4s98!sn;YCu7U<+_UqL-QMgeBbhZ z7+PGkly0$XqqsheqsKi|*#<^FQ3!E~J}~rNFvCgFIsoEoWo*=k4_jEOK|I66L^F1a z-)sNVdjYk9R#G-kkuxx8$;qLQFJbB+EQ@^9p)L#{Fkw-F4&o@ULa)jEA{xy|Byobd z8tPus-%DrVewt6d-=Wf%an0WvM71_EWS`}D4OG6P%Z@SX?988076y1H$%K`dRY_7q zH}R~I(x=Z;90A}NN?1jaeU3M%t8~T9WgnbS*<{( z_kYACMJFn7Xfv7qVr2&Kq1}Tst@ex0f-ZMfT;;0nA6)l}nQ}7+MMDF>|8-FA6A+W= zYGb;aVtAw}(a?yk1w6<$p^|zrYINhkl%(K=opwBbq3q+HKN*0ltacNP2y8uVl!#9^ zuf|*?!@`x6$)EcdI9i$3e_yRByX_ z^y?+PV-WORP_7Zkgn9E_`T2enJFfkXheykrL4j}nzyI9ppK{Cfl8F2bUfYg=;Gzk} zyrG8#xUU?m{q0u;QGrYw6VOs`?iX?SoYpCt#0&dYur$ZWCC5ixXLkq4YF@!JphToQ{qvk7DNqY6C^bP!G|gKMlj=oPj(dYoN2%(Q|)H! zFTf{8mVuoC`s4ri$$XgbnFv1vg7cJvzH{>#GVf_SOT5gx%|skd#;4%CJ4>Nh8wR1w z+5|x_Lw+)4h=MK?F7sZ12(L1j-oD93Om$qRSV-W_FWp$?^!2=t5$A_(G{Y+%4?Jj9 z$d4qBbz4)Pm)bKAkNPBjdy`eBMM{tDe1=a~aqo|gSx3S=t}1msFXgWDPsl_)YXxrq z_d{Ie$~BrYstPIrHp3=8Y+|lwM83G`h(mGf^^uAcR8!5+%j3v%mrKNnCS-O<)BkUi z!Du6au*6HIEPxiq`{YR;nD)8$-R|VAN8Vm1Ov1LwwxHsfp1iyWEJjoVZqRthWbwbB zX6F5nG!e6C9g(s>bA}L9ip!XSm7#9YbJVoD%J^`LP^6n-(AJ z+(~4Y%S*CtPnx1+>aDc{p-Uk}fY-6=Irk@$#~s2Z|F^XbiBA*plbpv>Q&S@#Um%3l zLA;JwHN5K5Zu#^)BjZzN&{_Qd9k%r?UK2x$X00S%o4A6)!c8_(@72P9jk=HesMAax zbz(h)4WPR&Yt`ca7_5K+Np};-D7PNTQ%*%)1Tz9v_1#x+Myk!dod{nqK1c{5X_f=s zipc2_cC!DYAigN_w=_1OGXDJs4oa4VyjD^8n85*=CHK>ky&vkU1v|fve>Bel==6R& zh5!2<$Ib6d4_5lEw>s2=#KjH7^DdlKlQhKc+Xx(;6KC zxfC!}2xd8S+I8#tv-I*;%wn1Q_}yX$-FFThx$GBS9Be)K-$D7`K@ubhG^@*lUtCa8 z70zl2{?gWZrE8RQUziapOCQAl-`AD@AP=c9F(-#XpY2lZ*A*MJF85Wf-P&q4a9FIz zOY~PJ|93bvm|+|b5!{H;k&Ckf=d#L91CN604sLfx1JwxdM~l%<#6k)8Wc%eF1jc3*`>KxLzK$20w^5?0Hmxxi8n;m9{Ezq6yzc$ z(L~LRW(|cagF0~>3Dt&);j>=;f`9N38>{93AM$2f!EwNG-t;t|OKWuc&0_-C!5UD= zf)lyr;9!sx7~CQf0Ql?UR8O1S+a3-0TI(#94#ITAIJ2a~pCT!#`~)WZmzE<-qF1$Xz~o z89*r9Y0TiunNy^o@_9h9$!mgJpxxAtEv-x{^~r)0G`em564$gNR2j^Qd@7B6Zl-n5 z($ZC*SEPU4!5=QMSx2g>v+8`XR?);JUA9YP>>3{+_eB8Y|sPn2% z`^j+#E90*WQNwFVmzp3osf^k)Mdaqu{;i`jAhl_z`_4jzx{cvPjn7CxtSlQ zc$W_y5oN8;17Ctc=$03J&d!!xrGloQ zS)}pJX+J1=!XbvRKJpel5`c*XUR@#{&pm<`i>bvhehk)%nnDvKsrjdrQ`r1NMMhG` zMCBg`k#_X7cz{Qqgj^>Rxz;~8?&vGrO;$Y)mV10_T42uMQDc_k26<|z4=PX$3u|W3 zBQr70_iem^a3K+PE4}*tZ~KxSV01J>l8de8(e+hS)(l90_H8vsE)s(d!9)Xn6yxWx;tie^8)`!k@MNq&C5jQ7ja zrCW%6zBmO}h{N&1sdCbZicAJ@Akm|iuV3$yf9np~+QmX`mVy(ZeHMQ6*(AY6#-00P z;Y2SOzPEXbbZa0rt?$iLyBQn= zapavr)HFO44OvF;S{6w#ZNxInc|8%R%Bk9RPKB>8k7jpU2FR_zph5`B|Dpr=sP*XX z5NOXhS*Bc>D9sP0=DuPUScL-FbGY_Km=j3V$4H42*-S4Nw{~F+7dg=w*K?|`ASOF$ z**zNdk=~rc8v=o9UdI*rFa<~%WU6&9eFt|Y=wCBXcYk$$r{%*g#WEyixWt~U1a%zv zqMAc|dLf_ulwDWp*X}dqWV-h8FYOB?Hi!5Wi0%63t6#XZ(qSW6rAUnw#TJb?e~h5- z0eZ{%=XF2reS2^!q=uqj48%CK#8bi3y37IEsi5K7$+|>}|5#<)7M7iA0F}cRFOCNZ z=wIvVCWUXzo$knPSFquSmOsD92u@xDhRe6@y;_5o*FpYRON9q>%}18Ua$i7e-a5+lqR5GI zGNHi^^h6GDSG)|kqRa3}oCs@z?p^KK!f^SZ+{sSLbU3gA+qr_PEeF#C zIr$;+;LA+wZ4~wz|CiX;6VcQ_&Q9!eeoK(Ce78QYx zVd~h>#@;AlW!OkB*<}4xHGUyQG`81Zl&WkNx|Kn zhB=jAb>BHwg>-2}hK`kyEGE7u+?IH=VfKFgzn(*iSDkg?AGQLfYfIpCko7G3R0D4n zofzD=rHLw=_>H;dX0P;U9P%8M4x6Nt~4?j@!SgH2WG=;|K%GPr@M zz9PNaO6+`Q111+v`gZ8S9TP;j9bF45rtMS%>z=||pP>u9&^_P`X&}pQQMlU>GjFt9 zR&1)T>DjL-RlWTscz}s?D%2UGO#u^UlS(ZcnW3kJu?}AN0D37Hec%cUB0j6~8GzBf zYuqC9zs-}mox?DCkTt2^TBafdn6$kYz+xOCP7MIOZ%N&ni=}-OE<6DM2yJWzPz)#X z(FCLlIOe2fet<}oN1oX56YSz>%l#Ik=Pr|_cvXtl#FHl0Z`Tu|@28uty2&_HAVWJ9 zLEV5D;Q_XwKCIxa_hoIV3G!vFG0dum2-n@q`)V}?byM1*W^G~$mtN!ArqEOzxG3`0 z?D5on5v!mg0eSZy7^lhsuvv&ur3sW_n?y`p@U+q24I)yHJ+S&`Tei6g&f|lh_WMt@R|6s`vxZ{6jeW4{ zG06>S@|0VT@rfb3yH2sLti-*XqiAs=gpi#FsW#PLwrC| zf6UCtwXYRMcBn=e*kAKX9o>rt;q#ES5xSzz-7&f%Cua%B`O-t&T`hObLSMvPJYSGY zNAO591`q>A)B$F|vr9eTrY35pLyXQuoG1*gYj`kq$WLluGt^1!|7Ml!Zm7n}+S2dLv#4xq zU?+?XvJaj^$CSxs=J3kfLX72M@E5nK`-qubVEs7U#+oz!EKE-1V>|BEjwZ$3TlT;> zRP?yRwOLeYj%am}7MPxMP+9@8Gao>{&L%iU!*%=25N9nq+K-w`(7mIMPr$DA4^E;t z>81j(h6euf`?sE@6mU#xx8=wG&AmU&*YF-e0QQtWpNdWrvQc;3OGIpZv5QU-;dl=} zTTVoQp4;lM=J3+wD^AH>VBFz1K(-w)e>YF2q3QG$YsCI7Ym3UQ3IpA84|oJ8oynx$ zrT_!&G6ldh%2n0WBsc$q+~sfceFbQjxC)QjhR1=OcjW6(;%hBnzh)^mdiDql)hLwG z<nm`-FGb(~zCzE}h3jpz z34g>TUf!Y*32nK%kRko-@mK+>>aHquX}rRqh7SW6a&H@5OP|5s@c)HWdE51-;klxv zIB!u)m)Q)QkL#SjPr0KVEe%IFZN4=i*)kZM7bXb+vGcmVKnmhcYyVJ%YR7vhL~U3M zz`Zhb22+*MGdWdrd6R8=Q zJ*6}S)>SR>J#evafytX=yUDFh`xKT#+<7ev?!?M^J$WWu2srv-cenTh;?&Ty82uXK z+Qk{woVC@k5FAKZDzlqAr~sD4e4rrGrWzvfFE>$XA+Rkb9LciYk^4t>_?v93XO)Ko zj8zfWC*TLm8*6JyuyeDJ3Z#JwBo;&J#q_TgfdQg+c}<_8?yQfg4b!&vRC;WKVt>vT z>Ncip;9kFw)}=LlbUaYZ$}JkjI@x0QPP^3sU%gl0z$}x!-5Gbc+-)mWg2dl?+-tdG zfq7EZs4PlYBL;}^%py<~zZRM2mVN=$$U8!cUTl2F~wVa8?+Cy5+W~8FW%TC##qwUr_kUv!;^)OxJgO5T1+GCHUZJJ=s*aRVTd7UDr~Nnqo}(1W zbmzCbX5+TLVgJeXc^uY0aE{rdMcNgI2xG|efF_n}19`C3zRRUEUZu$GQ}<~*lbvJS zJYM@BLsDuArMg~P7d-(=J?1GCUfK17;S^|w zSQgn6QnF&WH%lvzI>YjPXe!C^=GlLLBsqS$@qE~7f;LxwTvG_Lv#Q3^JS?dOqv-$A zB>1Cz8blNIe^m+gVzORuu;j#%F_ACUwxbZvu$l{EONrHOEH0oaUX|p7+fLj3wDh1gnj+!+yTQvrgLgRNlb!ib zlxjQd%WjKkWCDJZO#*TK0)xi)>nHUU3JopVPWO1Y+CRANnDpUoP1PjawNY~{^Z5=q zc$(79fYyF`yw1p4@Q^6-up*MJ9c_48k(O;Et&UI^?DbrJ>Rw){{x3_?YLR&6Eh z$4W*0H4z4%huV)ld(Kw$Iru2QZs?6RPE(#wK$uRDC|AA!YbZHr^q%5`I}%c~VtR~} zqDXDT@dR*VmOJR;+ZPI4m$CkF+kd6*GuQ8&Y~9{6Xh}5=K)d^I3`czZ#FA62c$#R-Oljoy_Pm?!-f@)TdcG0TN}VM5naYG`bhaji5rgUKcM9)5+s zqyq{irx(unw(otm4{q=D4Pnh-K*fLTQZ0W4u?w%SDk(ac@+|fmN$yLkxb(7LFjrvuNAqjKuOCjU9kmWwf(+5v7Fsp5YG5( z?F_|t8v~Cnuj5@Xtw9*vdtD5&t?pp0&(|{DH7zk67j-c*6jGw@STp-zV=RK7uiuHm z5+=BHaP9>l(k-BfXyz#~m^|i1g}6~&vfry}Q&?pa-`@7u#Mk0ZA`)Xw%>DXzZ#qFlD0`QPb<7c$6qq?7;(loBCvaoKv#^RaEtv^g=YvmqRakw- zibBdV87-`|c_GX$(~jJWu1?#FMB+s4gCgd#$7Ls5`A_X;-~3hCr(H`Gkjlp8U&iIc zTKQ+T^fwRC*=sEqT`r%Afynl%3Wc0SuQytCl&lj#5=xGODYEMN`l()XqzExfz$d^Z zDm;Gq>v`5|^CkATezy3A%1-TfP4%SQ>{R;3&CjVWf)8nug z9G3QtwCI$@Cpe}k$KyCcQdAxg#O00d3C@)_*aTdQ>!(U>&q8OAIoT}O4MH+>N~cw; zPde@{J#ROZx0z4+Nn>aqW-()qnL<(`K%iI@%#Lif zdzM7u%6a{KyeMHIku4MGlBW2&y@{lmKU;Qxv$$pTUp0nM@Y+(bu0@VPp?lGtTKmPm zzn9xEab^r$ZkoHf&lh4|HpoXyc_V`ZTMK(o&I>`!MWcOOai`rl)Sx5J)We%?Bw%sU z-(p5H!hcEAuK77^|KH2Qva)g!AZd#GQv_6-Il&mF`2Sp=!q3fujn1nh-$2O4DvsArTYc$VwlATg~VS0lu#W0-}!kwg3(h8gC%zI*C=$1TX zGuU`k7SE<_@*hX{F4aODZOSTuxXSItE3reStvx_5Jhr7pR7`> z+iNwJUR%6R&i_ML708;=#{dfTQuN8`kI%rfrB~j;zo+sgc6!R^m|A*?kgQg*{-4mf z;u$OYcWm{g9L7{)YXae%B93vQ9An0>ZEXG{43C+EK17&XDJ((pTP=!Pg&=S@3RvjL zN1&hu(3DS|w^gm#-jL3@_o)!Avob&dPY{@Du(PwfQ3h@<+f$^UJP0XsMT{=5d{%6{$&S*E)A0CDnm zLY0f!m*Y<+v2D0Q2mXVSOJ7X<*5xLy+%g*~&5X4zeXa+nyVi=G+zXqGYY1qx<9}K( zh(`bp{+c00MA0-cAgI;aJZ~G>Sk-7P$LmoVwM0$Sm78?Rpp6RgXWF zh6bx_g21RD?DZ&R#bl=>YHxW$uz!k05Yb2*bV;-IozLX=YQ?ZwC@F8xUrF8_)9nEy zIg`aZO!M8@#v}CPUIj!6GPD(DLXPKC7a^zp1U}Ki%^i!nb0_4e?wFa6tE#ip!(#Pa zNAM}wx;T`*^YT7hn?>Z^=sh6MTKBJP6u(8l^MdoKdr~E8r;GWxBU-GK$LO@9@FyL!o#V8;@a!St%2znGA*+|71tWM;UZoaZpi#ttQ|-Wp2L<~ zE^$NDp`lWEbt2dF-njRGYA$eFAKO5^V zDwY%eYi8y@ac|bU)C^q?Q~s)loXe4Su7G{Q&ZorRVNb85#^Hi1Ok)0qD3iWai7I$x zLb?RUwDN#2oS)9a8x+Sw4qKiRNHdP@G8&$S`#@L3M5a01AK1L1G^^1X^R)Y};bM`l3npMOfH=P zIc^BuL+ILM%PO&B8vPHe^uYu34kBB2>sx)ybCnxhaANMl; z=qlbK8{9~o{Ymm*NlTnC8<&y%KozFvHHoZ>u!`*tfSCEwyB>N2jkaL1ltt*`5zPRVc$+qA`Tb0XXc()~>$pqq1xSJ!ixH;9fr0=pP@e#0Ck{P2Knxog`QV;!Wj@d; z%x5UTW!hhGjhQ2IB!_hAEX@-sD)dWF*k!5dVVS@$0_66!85oh<|Hd>8>M%BNUQ~EH zM?u%fjc8m#nb==@yy;=>r!A^O6ZdSX=~u4`K(2kG^Si%2ltThJ?{nB~$9aR%+8>a( zQhFA9(xwuUZ+{(!qcS@7rbOnEy~)ZxMr6-~?2#=i+o2&s zLUwlc-ee_v&yXz~;~4LC>v?{^_x%ITxv%@Wuj@NMpU*d1I>yZBB=&`qFX+6lB!Vc9 zx0OY!j_b@jbs(?(;iw=!68Q40KMfQX7!;j9cdWFj2VZc#(Xlq+T(gN$_~g4_cU8kX ziXQx1{cOYJv5W%HAb<5!>GS6QO2}=joqpx}SSCMQNOhR5`e!K67R>>9(N*jEr(DAe z8lN?FP_zh>jMJKZNF){A^xm3$ktdI$QGgV`O^Xz@A0Vlp!1R_&Xi4qVkGqj?rTPj{ zlKxfs(WTWV3Il`L}Gix=@7!duNE25dtWWWWP;aYdW^=J46Vt@gXsq z%RWtTWazO%G(87oOb!Zc8_imcEI12Y9+=zUkA*$^R*m8kP(8m8I<4|)yvoog4ViVI z0|Sc<3Al1H^(zA4wg{Dg+d&EX2_?zjF`YmQ-7@vV_KXl?co@sQ;`tWJn^5(lf8%?!d1%znfg#Ya{x`posZef!-i$Q> zlNB%1a6LUeSAS#zs%Hbb1&>yQ<>JO2gs-#b zt#aID0`+quK4U40v5Cr77%Ak`qTW>Ou=TPsw}f3a6j6g2@=1S7ykT`bLS?{_W#XvL zw6P|8oWMhZ@p)zfd1Mz`iBAKz&*gX*G`SdlmVwuf$jet#qZF%iOx%iXAni%w$)G-UZ2_D3Ea?(5(>|l4{6#Zu0WL3Q_Fqq#T3#=`f)f7Sk_y6wj znT7Ln=qAD`;tnDF7L`&q1Ve~=oY9z>`TzFFJbm);fObMB1NN9OS>h{iogZcA1fuo<6pC&DQG!L)+L>I1@eX`pD;Zf)+8ybxKttBDbDAV4v z{1f;@8KL~2MaQi|;6?#}LWn3Aq(?sRBqD7}5@W)9;B{4fD%9wjr~~bY!zD z#N>!*Eo>>nN40L2$~(@hq0CTlkw6PJ>0=v*gbiBc+|XrHH#?8|I}5D;4Q9?BrC;QpJP5WRo!RulaY zP2|?%(tLocFNKF1o^-vl&24jq; zll4aoM_V_>y#3`FBkF);qveIKMEXVjfYsremd-*+e1Mr<15qQ(PsIRIiAaiEYKzZJ zwi2JrRt!7DOC=)O$m62ox@QB0{8H)VS4^T9u$60Zl4V-$bWTH<7P$cth^lmR9sOGTf14XVN=Bv z5sRo&Qs3;2<`ZPNnH9*i6aD9qYbTC|vYjl~BPwRi*eVRsPuMmw1!$ETq$|X-;hdl# z$;6$?w_PTWq=gW0|K{fDiWbf7KJ{82@AJ}8Qzy=uFt4+1^>oYs%Z zA}2>jMsl~N{%cP$=4mkx06)j{r~JhP&v{w_)GnR0^#gHP7Tg}VpfU(k0wIH-Oh)UL z?r}LV6g6}g?T^WXKp+}yTZ0RG5=7|~neM6;(NVaoY8znZ9nfeajxvv-&fReVjQIcF z?X!im9rSL2Ae1{`%{VTr2ACDl2;l9gS?R7Rj#;$?_yeefn$BIISFU(e8wPN4^X$Uc zDOf0{GMw+Jt8-+>MhGE)k+W!l{d>TzNRB*Tl@J{B^iA6({ps}8rho9P-7j=d z|5<#6M4u^O^>SDe@-VVv7S&c;H01;#+?(>2)BOF?kPy%cfP| z*tNRJyrX22f417({_c7q$aqYVc!d_Gf-qf#)_e2EpA~G$5?g8O^_4$A-=s{5lHJD> z6R#zVHm?GCX4d&1VNmhlDu!?vf13yhU7nLl5K|zYQc_VJhSsUk7N`DAdibK9wvn$l zRx?4PJ})DqRa9S#R0pG4ui^51(^uk8m^FR6-hYUdZJm;YkNHr|Pj;A|?DgBhZs!-* zBDzMBC91|Ho5@4W(It$#)5}yTQF9s7p6~auNguVHqd?!)Zl-4B4EqY5i%8%Rs)ANB zvC@~6EwOnxZmTxpuK5-MOC^A&DgaA?s|U(GD-#ifXXq)o-N)({=iTONw8^rAc>89g z?~jo?pT>bwm(akG~GT202r%_dhv89 zg1ickFms~tIJ1gv)#eCY7kF&~(o4k5^e~x_t(0QE;LZ*n4Hg+ooM&P{;X0AF{1xnz zDNg}Fa>Peq{u=+`b+1~nbTvAK2G*YnC?83c|7aA)%bYc1t%|75+}^Oeb0UXU^oC%M9ZnK{BWxj&n*qeJU=4TS>Y zh6)26G6Q}K8Vng+GnBl{qc|7!Id=T-OO{(WJ3-eq!Vd7~Q=KCu@+CfrO+u&mzecUJ zb1CnJ zt|Jj*#9%!8(>EtCPs5;kF(0~R3ToW6h?ECkBmKF5Rl*cYyp8F?R$EBGvzxHI_jum# zo`DO`2Pzf~9Ul2_0;B`F8CTArlquTp3{4raYI2) zz)6~fc4ecV5wpri3$T~5m^^qHCslYA{4n{Bxp5Dm~vWUK+Sf2 z@Rx@{T;k$YV91im<5>;el=%)MU6BO2A8Ky>FHHLBTThl%yWahWcs&6v|Y?%)W|A{WX?II=Gm>}x+y1}2F zr`ELf`hQ2Oz~YY!bhOk#z@X``(8e+idYf*fhD+2eQO1B5;4DXhq~wdB3kwfZ{4qF~ zc8c1{NB_7JbCL_;E+k7xT=10qxlG9t^5Lsa_u?Fa`S5y2$Wug7{{6#8p$nz4i>Tp^cA_8ortkcjC0Ghh(B z?mjpj%26&-e{ptpV|4|Fgr|>{8^2?k!?8W%^c!+}cc+tDNP~`wsqgRh3G;Z?K--rC z{F*TSH38m>wxugq^+4zFw9*bpQYj|7Dszm}V$B{#46yJ|x$x_-+1ERl3p-v09V}S`QLBGFi|k`& zV*pKO%KI3ARhAL!C%B1YwO8@P$*xrwN^C?VJeFWnP~sy`!(^3OFx-HCa0qgmfG`$4 zaO1w9C!pFP8A##e<#bFQ;IdEN-%*?OjE6fPw+v-%AX-`YYe{?AnAM+GAoZ&_-6285XUZv`sMR#z*?0~zcF!Mjl3?V)}%dp@(FmY$IW^XnVciF>--?Q-Vk=HJK; z<8oO6@!}Q*3wZ`d_mKAd5&FAM?{%W~2>=~(O+|w!K_oIJ>MY>*gUyo&_>D4K36Wyt zCK3}a$B=Q$g?dWX8kQ22yzc?Jl|!9dv-P!lmG&wBIrj*j>RRZ7k3chS{j1LYA0*r} zC`R8O?Q)o?M*HI=fFdI;Ga;Jwff)uD%gJZWsW*)7d~z<^xi zqsq?P6u;Poc_Q#@S)u}+8$4qXcjM2wp#na+(`Y!^8oKR3ZEI_5h3l#d8)vz}-^68+(ClSnn*N4VtoZd&kf2^h_ zg!!R{cT$(Yn<)}_UxRZ_F@;&eMP*{~w@4zO#(0C8&r`xAH>|KQvp^wofb75bw)N`0 zZmv+snUeX(C}n^8#eVGrv0w-2a%`W?PXnh}{xz(9ncEi|)j8dn_ED%TKjEpea;m+3 z!ro%!g!FwmAT$M&8+^TG^G3SZP!iR0SSZbj*M~WUBQd*#b2eM(&T6j&pK@zdw-NbG zz+P`JAqDZ)Pwz`KsWT)rNS+=;Yyxm2StRO)^h}0JdIO?R^x2s#upk1OydAQkcZ5WU z;)Ea&FDCGK)&rBA04|2V?sw@AdkxWbp39f$}4qZ3`7)xy%xy=9s zFAqTRPW_zX35bZWBd@lX<89B?_EM|56%-Bl{gbj=pOM^d77h{hxSB$JiK=D*&8RQ# z!O+j2>Bw-|Lw>tS3q7o#lX=5G(k2$a7~iCPmomv{zdK$ZVgxfC@f$vB| z79qxr-$ml$>$q@({Lj$v@VgU%)38a0x$}|0+#?};WYm1?ry9%v*?j{vHi?Jb(N^L) zrpN6pV-W01!f!A!rUTg6K2#WpgQoSJOC127*W6R?4o2_Q%VS*t*Y$qs$I`L*65`-g z;*rL%F{MLMkzUU$M((VyYcnGHvEQ&<$jmKI#eJQpmP!-oz)mt~%6XU$!wX-kyfj6M z$}Ll+z1Uf*rxR+R;U|q{TRdu(4Wu*a;s-i-y^ZSbMn*b=aYXjLiFGVidXdFhrB!)O zX;;l`I+A)FVxqV^F5Fj0Gu0g^!eE73d~^zydU!I1hKAbm0;YKQ6hwwU&&}XPqTf+L6q3`bwB&+EGBRnuOymni$2@Pg1-q5?89~^a#OYa( z-mo~Uf1?p{{$le;s^azQ+kKpP%OXWgc)f0J)!61hZ?KyKj|@M=T$GG_L@C_F{|C(Ua3;tw=}Xc#j#fn!VBAB;%`+?_C&vxOD;5C{V|45&zMeax@-c* zLI+=%(FOE?2diGO<%r^tKwD^opeKc`$9z3%FrzF4A>wtQZu7@NOQRG`bWi;UosnF* zK_N0E6{beT|KbM|Vo=R&I6r@_OF`~0k~RuL(rOt>t(u%+0_^FvD`u#SRuhNBWwnYU*RpPbcx6D^05`It02?P9!M#C4ftOlblTEY+Ikr>+)vnIJ;dxgHWER!|8- zOGRqs@Bh81QP}LK@GT_TUFNL*_g00ZIQ%lsy43nddWB<`I5 z{brBPc9h*vee-|$$UWp$0dxA2{#;Kjd`P-TMh5qe%kwzkXVMv|bH`87)tr5u38Z_rXbM_iHJ`&E zc8cJsVA`Nhw+4iY+5l9szp$uuy&T>fLH>qbZyLlRx@M`PGUCF+e&R!vLy2@(LG+7E z)J)|8_DqF+U%x|?f1>i{>86zkmjik@``u)D&!)mVA1NP?v}GWsUiRtdXMibE5FVC4 znw94&eT~R33b*;~cK(NS(6mpS~ zwr$LacvH6}3r)E9VpvbQpY=4djLd$rBbWr~WPK_&zA_fVZm$*p1Zq11AfQ9m)b|+G z3$w=75x{B@!G9OE)f~baP^2>4UKGLqyo|LP$ip^$;^3AeSl&#B(s4 z7cOfy`p4*rnn#yC?+%mm*;#vgurUHyN4-<@1H}x0ll^}mmx0{7A1xHKa9^U^{)6yX ziCxpHO*rALTUmqVgXy3@*WORWiX0=UQY~EVGLInl^GI_x9jvdZsZkz_=U}1p>x#2M zg;WYfCPYnMGrCj94=75!MU((Zf(=;=Jp8{0y8BgJ&2d?L$e#xk)grFXQRHEJODg8H z1qJJ^Ab&oZ8yU7JWC@7kms?0;X#p=4_yd$RUlY)M`i&}WUp`087^@{U4R)8~itYeh z!B~;(qXsTz@V&DBey=NDDU;%DR$3jNoxL2yggL!qHTl+-4Tu9%DyNv4(jpmL1T(^v zVNPee(o(IwxI@`$I`urhEE;#(bO2c7BiGY)c6Xk@Xi)we8j76vbg;MQFTw+_aqIuQ zMt~=BFZ+BkGAm8y4zq;=vWaC`V{k zYLt&ec!#2&MRwO8iKwdxpH%iQ-p?p)!VHDFrm3q}a3K)hq=#L(D(t@}+#=Q!*^?qr zRRZ_+zP2L4ITYGSGv=9Whu$gDk`Jx!V059*@bE!RR5yDfS)o14%Viq!=jY@56{Sjx zdcTtcTExHD!+0W)`<*Hy1E6vxHUg>veGdVm8_`Z31*k89lqFncbVMpi@f>T6>l=s9 z7bBEE4tv(UJet6AhJt;KEy?&EC_P0%0##=P4RuLy?qxCZa zD((KE@$f(&1iUE&f9KTvzxDu8b4(Ju)%1LsKI>B#^-@qhYF%_2z$GjT=_BaCnHPNS z;GhGLo?0`tF9%#}=@3x-aSE74neMKC3UmrbBZ(HP6J9@b02|=`e{6_hN7Qfj6=CzU zMWRT}QYAtI<9P$T(U6;mkAR0RHy!WO#M> zmzD7rdj&HG1R6Dz?A(c74FJ5La3S*cnZnN!=64V#|DJs^P)|~$``T~ejx&Ikrylf7 zor1Se9N9|TP7hlOC5vG5c}@Xl+npYFN))OJ|NfFZ*nOWC{ZLGCO#4-|%V&j{Iif~e z{n#Op2qH${H!=j1K#9Nq@$TEO^c(-0+-4l}vlAxn^-8_DVEftR6my|{sfPWF`hd7D z86t2{VDbq+(*Zpi1or-wgIu6Cr*n9Cn8+z8B22M=Z9woy&Ps}3^$Ov+6EsKFC;|9K zR4&{R`H$Z+|4z0bA$xy6;%o0^4is3{%k5Z!ok7`2xbFiPsn16 zHbzy*Si{ouO5BXB2xUjWNq1%7`&y0S&U?1fo0#`coOT8L{V+kLYDK#SSr+#jM$)Dg!8vwReK zTU*TQAZOjc`?#3*#dvYQ*&jdjc2U3Z9;Q`^z*>Umtj~xY(*D#>Ur(TG3zZ}MGGQUC~F@fA~;tcr??@O`LJY|W4^*nM^haQ8%r zwl0MVK#=@Mn!YyQMHWE`Q!8nC30s}iuXQi*GguoUy0Psa%XwCV*OJ)=`02`Y1hOui zs*hye(e}2o*mT6u%0fi7Hp+W7DO2%ih8Z^L4}4f zf<@Upz<&fnO%J8B`Z&xvr(NltKJn4ocQRk@G4J8e!*497zt2hI8F|_|o+$)J_j(Uc z@9zwRhiKBy7SOxT)jcUc9pxW6ZBoiBuq^XB|FvZ^Wh>GvMqF*$EO-#-lwwN|c?PDA zDqP+U3)(o%>t3?jL|vN7H>%O4AJIto)d>M-mx(J+uL+x1+Jlq?0BB*?ZrDNpe5@w-Aym+>R&?_4*y^ILF-N+8!-qRy}{vC80Th;G%zW5Z*= zz3wsHWYt$tonL_2valZ1Y&Pa_@&8#oYFS%eiV;R|BzUEAQeSQz5v&1<-OR!7p}qoO zL+u1H6K!tclQ0=mfWRJn(yAVxj$KfLNe=^c-64mc3Ho^Z*4O*=eWu;dDQw0%HqYn( zY^?esj7i7kYMbnwZcITYt^OuA3cl$+4ohq{ls0X^GmG@OEk)1jj7 zqRigA+1c(Dml54|)8}6Ti!yfmGeK{HSC>*i(6SSDd!%NOueED5hF`v`1=&F*Vys zZ-A~p zyQ=S%r+@)4gmZ~EC<90Bx`bnq_Z}jB52PnZM}@tSy^_ZXW0A9HP-bs~k-{htu?M8^ zkjeyB^wf_hIj^EXJ%#tY(4|{PQZ7l99~MDmgfcI~FDYy(%#YPyb6R}4H_K(ugv?LC zrxT#iD#wn;l=rlVd2F)i$#1w0{F zaK*r#B%JM5R8B|Ov#6@sb|JB%7oHDmo4ClC*cGcHjoI=I+#yC3A`P+3SYXP zg!?7{v-z4Elj5?2JWlyUp8kGF{y)?fh$2(%zSx*}+Ot$o} z53X`jK&}XP;OU8cWe&mY<&SAw9+NoH1Gi*bz?u*9B-bYBKVAo-@IbFahlYkG>wVZ8 zg@3=C3atK{-&YbwMD62~<+g{pGr)_?V=8HpfQ9Sps_&Lq zQXMV^kolsYSq)abYg)5ZMiP}T{(*eiUIMfyL~f?Ea;8A{CFQ~=+#o9KCxiYylqs+b z32z<3_8jU#D|bi{c00x=oIlE}LyN-ybb<#OcKwnxIubYPRmV4SL8IL5np3B8%hn{I zT}!^za)r$!6-%5P=()cUqdNF3*{t7u@dF&F$yhljIpON-4H#D}j|uYZ*xXu_r4( zmAFPay)RByRg`wc_Y()Mp*(=6KLOu`yd#PtBfDV!U6{=8cPG6|P@IDM5Gec@9!SEg zN8RlV@*`UzUu2Cq<(YI$VbPM5V;G}_N7+qxaPE5T+(1uNHoG~CO>Rw@P0=ny+3oDr zV_Tkx1%u=M$nPcks6`ydRDzj$%J1fmc&YjvtwaX!m_IYmQ+L*c-oSNAE4dA9OqR>= zSA^tJwfhacHI~aCBZPWe9E8+a#1Drx`yl4bZ?MuIK&a-6*I!ByC^%%QtdzY4F(T1D z!mN^}Mj=(~&I8i&K(ky!SCZ#t__?#v`5#{T@9>Xf>r(e{ZhK82mGH{lrKmOoOJI?P z49Ka&+H@7#>^bu{o%47*a9fT%CS&NHd<4S{%ShCqVTYXGo=|-fVEt3*&o08(ex~%q ztzyB+vwr5HP|w#k>2yi$a<Ct@n)1f`JaC ztcrF0X3p^?if!a8fO{H`oyy&lSEY;JC`X7sI?I^C&cBL&O*p+QqYZDVn1{e<-Yu#jOhdq z$mL{C(KrD+e^B1aiH9}0na;UPbt{TLQKLmap?s(HHY_~t2hNf-wgoKMNz{Qs7jH;| zyTfv4Cy0M%M+Hbmv=Vi}f&o_%(h~!buv{W3qhi^AYvz7@n>$+@v~{fuI9X#R7qoLc z);Y+%D>3Y5&G;&QiEnKfv>Q#R(c%{#ZJW~(n3BCS?3775a$50Lel<1Ki8Pa{o{r-} zvFHRxxnf7Tw;yU$$?(!1>bTgEeVgbko(NGlK+Vz~g-&%n*V|<3Y_?1iI~{GfHO~`c zC-H;}T>-|!p=H0Z`}G@?c`rPv*g_w9(;C(th0dvrZ{bi+dHV#@^`>mj%#qw7upPzU zH5FgB9jMlcrumt3`*O@7zj1E<(`dS`h9oLzqaIraW|z5Z`zQ%!R*!9Au&P7f|56!| z^NKyhY{&e4CxZd{b2PRE(4BxB;JceVHqW1Pb3kZV@n%q<3?sgseSc(RL@4sMOeUV$ za%81?M0!@`{Dw`LXOVoG7GBq@jZHJw!ne{Tb0vfJWG|YhxHp*pGpQ@d%&2%jMlwsW_amRu>P^T|D_ERjUmY}D_Sjec z=N%n#L(*C`&T#-Geq{j5u+ALZB2|D7RmCiAgY(Muz5@z&6yDy&~$f`GD@^rxo z-4W#IiK!|hS}@QL@9Qh`9$zwj1GjV4@s5&UQGN%EryltIvvy4t=el;Y=k)_jTKTW0 z!LXFrzJAydAhgdMO5s86 zM0FANPSrXsQ<;=KQZa%=`h#oJrl! z@l;^lI3F|C+7Uy)TK8C!JM5>?9In_<({V7`qdDwomlwt_b;5_mF7bj$&bB_oHn#@S zK|)jZmjeM6Eg|p}Gtia!>vCy?hrbaLRsZ*l;TpG%1J+-_<*I|ZI9c!KTT^y&3_7&RvSXcQxEiMiWe)u_u>_oAEbd|^CyDi2u=Xlp2P6J(eHxwR+${Zs<>$<{zzR_)(- zqJ25Z+7-7ap5tLbcW^F)d;P%|ua|vu!y=LX`Lm}zkF{wi&N{F|HyDdJcQ4%DaBjO# zzjUkkT-zXvG?H5oUKjim5&;L0)tO2e)53bs{gvP1g`?2HPFDmGlk~Fk5G0~Q%E;*d zw;F}`-aW0mM!NX%xli#qU-^Enw<`iwkgs~v?TaHi6G#kFxDaRjQ@0;(xelg9b*3Lv z1>cSG!8MPovI%Ql>NxZAMWYHP4ZK;p(sx=|%mbvi2IcAODk9kEYh#?&bF)7dZ1SU; zOa947EaAxbX!)+})|7kmI46D2QpLi>veQzw?XA zVq16(A;KPG?Yw~M0LKt!sYDSMIhE#7yHztZO!c;Lk^LZ^(m_?^iJh@y;d<32P}3MX z+T#Df^*%eE$#_(vLY7Q@uWT=;alI!D%;V+pc8%M(>qxcmpsing|5Nh0KBJ5~-rMRo@8Qb9&dR2aYTe)gU%fiD z+`SE=)>`+E-s#07&dZUo*sVp*&-82|nlKYXY$NYfX(rE17B*Qc*7bP2qwpy_>Q;U3 ziYWsm%~;RQhVS&TZyolMbfZ2wsN!Uxqx4h)mT2DFlG&xHV^Gv}Ho3E6TQpf#*Be+F z?+CvZt?)rUZ4voS*;!gtiT_=Y6u%32YLIeTOf~q{a#9me3#zLrDZG2aa-cX^N$6lY z=BEE5W9Au|&)%IWepcol@mX}Ur9*SoyH1*{-qox4BYg%E93{Jl#}WAJ0rd?c^7bf9 zUebitvkn*yf;?c8gFYiHf~e(H>TLRhakNL|*XNb^m4%q4`7CyC%_orsk% zzM?xzDB4C+fX;O_Zmvds4>IG5Xa>P>`#g>XaY9}?ga`%fjI5BbFU66PQe=)3oY!?U zBs=VywI#1p>!3<@IE4IXK4DTt#^dgr7NKQ1)U)xFp^2S$O+j|s1uWIlcVI~z`xdwNIJf^oicE+p7t3~D0EhKa$mQ9p)x&f_FEE&Gq+?8YIB1|g z)85A;@}t*k_*P7R2Mrj2%Cj(cJv}1X;NplZCB(dKU{yRnyX^DimE5NUWBQw3K!_)MBY0^o z?6juBS_G4p0oGw@M0EP#aX zDV3A!eSp=67rb)?yG#qpl`&@q-fRAK*jf&8 zkwrhkEJ1}c=JbZRmiO#o+QskaG-OV);0fzXgX6PMA*U_23EjQdKTF~s-jxYlhJp5* z0Ef(AP<7;`&rVMbPDBDY#y0w)mu4O;yrCEwpZ3U?v)jP<7y)nBk|OzeeoR@z-X8XL z!)peRoqo9OnOo-jvu`3~W{}gaYWCR7`k^465i$mEm`5_M1H%E)|q#gx;`wo zUb*iPm#ucwLKoH+#j1$9Ow!oQ&$e_$<4d1&0B+s~+j7iq3%$>DgitI2N?VJ!+Lv-d zVc#-M?8tI*1$7-TclMxQh2tIU*tzr2KPZ+faB;V>^muRVfW;gpG4OOZdGes6cID$_ zTuX@|H>x5nA#$;pY*PK&b=LJsS<9wF4Q|r$_$l1!QBLBiI%Fs~s*0IFDQ82*3V>v? zLf+W)X6SrWdM5*XxCV&Nez5s!@}@nHx~NDP{0>T1)GVBb)kpWvH9;y{6`|pTe`06> zbDPBb0r_iB@@yPs<};ewi*3VzORVI3gd~^a-wet05W8(Y9k%@T565JJ0ILA6rZA9e zynVq(c18oQ>(bwQ2a~SdZT5WC&U*3gm$X~HN*X^uG`Q=}##ek>u=BX{=1u(Qa5KkA z67yYV{tBl+u9A{yyG;}GAiIcW=IiDY%m$V&_jz`6MsTV4hOVh1V5Km`=|BA_2zd zh1$&3Q-GOXb9QBAWsMu#1*0Oh@EL*$r2}Ou&bYr+ypsAS$l8<)^Fs{(>oxqcJFP#h zpEL`7HFK%7pV9pyx;Q`G<`%pmXRIk`<+MGSGBsIxkJ;Y~^`=+nX51a3&dADtjQ#1h72x7h zD<_o3VYvHTrk&s+wl&9RYa&Xs#FVg=52lw=#7PX~j|5-8QcjN~4R?yE4cKVeqHOZ} z*?pp<)4pLFqhNaH_1JT!LAi)F`y9Vu!bPgCiACq zGe(Z+3=?Or4uXZxsGs97v5$8t+cu*1J1`u)QD2zS19C4X&-V)P_uWB4ajhN{*DXNB+MIL8Aa5(Wy- zsJH?0bofs;`T=;i%4ee5^iv|~Fo%TOgc`c8o8t&!xs#I2SuF5B3tdqp=46e-^Z-7Gweb~w4;;C(*M7RFT_uZ)pmx5+qt|_e0}fxcyqOX0A8T6rh*{sP z-o2aA$H{nM(5k(+{=JpMGkQ+%DExVqk4nM4VDOrE@dZ_yDM2O)(*d&Z*?J1PrproI zQg~qiSawZ#jP{y6>~No$;?}|#%sGJ6C+-iXF1AJeEUydQ=*2&FHAvFPE#=65un+~| z&vc{)-NA2&7+DmGe5#Vi~gBq1RoJm=9mo7XIC zd5c+bHr$v;L4}#``H-(`nmUL29dIlY1O0RbC%jkE*LH_G+ds^XTd*CsKjdKdR&kRo zMXCb3L(|Lo9((fqICYX_3jHTSX|du&zHQt5FprF(pEug>-{mZl1hBBM#I`5_$so&j z47hY)J@-#Wwaa1TrBQ4E5pfku}#akZuYG3Lp$S+<~w>M zl?e8wCXJ3%Tzvo|x7F)#JyTB)3xf#LBt5Q&kggJzyBFgwg*uc zrC}R>XC&*!T~Y2o_Y6LV-7Dn7DVM_h%}W^9nur6ALfFf-(2&rxGasSR?w%e^j*HJB zmSKTU(tdP*%SpER!nSwgjBfKneow}KneS8i?;+B`)bh^c zUwsItre9_xv3>kvG?SFrHv%TSa!n^-pGu;uQ?wIC(W53br_TvZzoMsbyGHp9MZcek zo{G8B(UiYvKpqOFG`Sl|wV8h4G+gEf@O$loyK7*<)bvQl&KMfm)&3N$_b$|(A?E3h z&?eozeO~Oy4Y(CT9Z$<`-rGFpBD{NtV_qI1R68Et#eJss_3M;A+jgQ6r|c4g3o1Nf ziENnCDjB6llsG=<3QFmROu=m!A0kJT>6<>9u{lOuAH^(GWi`bs)9WgK7*?~#7*&tc z<-w)-dGxaiU8rFk>&(i*EM*Z<7ju_ygs=HWF!Z)Nk~ZY?umS1eDJpS)n%OKcigZx!bk?nN1~jQZ#{OgWi1xp z541h{cS#f_w(Y8tqtftTojdu0ws>88GJ4s*Hgz~%qd3oQO&(Z%qh$(v`GRu8-G~Bs zxM@h0I4|THiCn`qD&IZ=8ey$+3%Zm-MuoT^&_yQ)2ijnM)pcu9+jZ@S)G#2cjhe*e zNWY`yx7CW8E#xCac}6!7irG$E&>M!!c@U=< z$H6hei|ZJmT6hx+T>9W+tn*@%z+nTzm|8HIMz7@&V>-{ZU*7Hl4v)?j{*1`MeIJz{ zHy`*`%n3E@XqDWF+iQ%Pyo4uVIu9HkE*3pW)l`~o-dn6v`GIQvxo^YzkT;rP2C_>} z+oH~*F>`12zRgEl8z;P03%tQ(92g$6$o1fX2FC<8wmBXi-Y_xb{Lfzb>F!GAMF7JY z1~KX5cd<+dZQt=+Q_Yf5NG5PkCB@3#j%R&9o1)L~z?QShZ-?+i6XTL;LwwID_n$$S z+5MYED)d?FZp9>>MFTRyf)R&$yCLPqeifD}_79IvzF$O^-da24*7PaA6We$6sv5WK zwCVu9W{$by)ZA>+d;S`RsN>iaR3YK~*_z}W7zzV4ssaS~up zqM>8#jg~N4n1jvo|FO1;Qg?rLRN}Q4`E+cb(qY=)@H21ok=4;m7A4<{4-c3olE(-I zRRTtC%l_Y+Z@;CHNT_5KEX|7QE z!1+h7+kKMEAR7dkPn5u?z-%zgDy!=Kma56M>~idR z@6z{ZG~FYGl91m0wwnhu*^GCmWCgPs6>S5CU~CL8KAPD)z$}gV?nbOp61{EiOIKGB zQD#3*^I-_Bhpkt;)LB|BQR_QF!&EVdSvmv9*e{z5Z?EawSPhlij93R-*RUXet@JTa z!}wzU`uE9Qa$tJM>Bo$~z!MpeU}`I&$a$Z~0=FNk#|T}j8sI%|0&!mUp(pR&zt4@I zW+svnBKv8`YtX>V?0*~%i#9DP6lL${GtjoZ)4ElwBBxL>rNi?ZP9O6z@LroDhu6oV z@>txV@$hsbY>Na^lM*_Y#wSn+*%@wkQ1Y}yg!7d-_Yr>ai|tN({rzK%ihx8+o>N_9 z=j3b4{o28~kP8D?EG{kui;)$_>kpA%mPRq1@X%YJ&uYUk5gf-gal?$`ItQRiYH=jq z7-^5o3v7XdWB*2IEz~j<$aQ?D+sn_-*TyfwL_9RQ{fkBJKH0Y5y^JUZN{MQdMnMlA zDYr4~${pUg9b$Be{f>NEgKLJYrl!xm3kF#;0WAsXFantZa--5?nt-p(!yeNW+=g^R zsK+RiWhHkhQ(*)A31u=kpl7YzzYq4S^q=$M%>Y+Zff?7gyfN~1OQce^dJn8AO1mA9 z!{O+;2{zd!Z>vor{o55W>4!-kbN3tME5ksYvF-N1Cu;Fk4>nN;<#M&OzLQglO*j|5 zKGVB`qLTU*p!eW>xpGnbqOZsjH8|C@tCxY)u3RYcDo%6sfCABrpBK(SN#8%Tt>Q^v@@$D(Lh33uc?o-x|y}Axo-ERtUEL1!_ ztCMR8T5aEWlApYxi7muj_2t)))6&-Nrn6I2QqsQ4T1qj_i+h8f>X6fc*0)SKVPhDX z3jRJLv$@3Y>z>iZ#x7s(6~T>C8{ZiinK$nJ5fi3pH^=+DKvy}7vl}rG~!M!;&zRPYRbUHgHi-P;R(KW&4>(Ls3&}{%!3a=1_Tk0pE3QR z9eT)M@Nh8|>=y3zgH|3TKfeZQm*ro-a!KEC)>;n1cAiW$0VKnsEmkR30`NAkPzb ze&40XIw-NvFQL`R3v{kwisd7$h$W!tOztx%uEqfix}hNpr3kLu(?UztD0S^RK!ddj zze;w1ZC@b=_y%fQ7zqhj+2gvf?os|m8H;5&ZE~Z0M8|QYXlJlYVwQJ`NFE(E&j67Kfg1R`R- z8*~OQQ)=9Ghhhc7xvtRy%gJxnf9l~gbVC=9Pr>E$N(7W?(GPn9nqZ=fIGe-;v>$ij zYoVD0!#>aF8tT^o^U8)nN_tfoWuwZ-^M`U^&bjVh(cW&LqSNBEWqEw;^fk&7w!gc= zFUw-cKrz%8LoJl97d{7!qAxur`D(Et=f3N!9P?#;tKeH;Q;2Va|G)8N8*qQ4$$_jF z_Nn>4l+>Un%4-^ayq6=ixYC&&z9aT$ zBZ{2Scysc+!U(DIKJ`}WUSe+kvQ>wbv0kaXA6e~f+7F-!91u2D?Xnt`X)J|E01)il zdr-hrB_+W=={FAi$FBs_i?frwkl+-TTRQCtEssEomt82)QP&aNmiAkGEe1HFa4gOb z=faFhY+e`DK6d{TR?-!w$*cbPY=jQ$2aoE_{$UsxVH2xvp2{GuDiV*&!Tdn*q zc{V>D>;s{H8eP0-^?WFV8O$nRVPn(esD3o;!wqE?xk5k5`JErX7t|gAyW#Qc;T}|X z;1mqcCe$l0&X+ZO=sd2v#2T<7kj@d15|B;-2`TA@_u#$H|NX`{=A7R-d+)XO z+UvCFzoEP1vk#&cUo!k2_LN?Hp>#o==~--sy_2#^tnq!er>tG3lxIXkL*uG2h>MV& z)GsG}H3cD^Ag$rEWB>&)HA^EN8Cv1=csWxl|_B`R^-LD%QA+fg}OA95;K2 zsV4&?M>8XSO5Pi{Se$r_bei}X$QZ;o;oPOSyMsl}q-!sN3n|i7!qTfUZ5D2Q`~^v~ zyiUq$({0GeKI1R-gcE`?tTQ`A!VmmTzRnuF5y^8ccV6wRNRCUR#n061a)PiOowFF? z_PO;l@eN=o2NPcFY9t}1#@%`<$qt)NfYY_-YU{Sm7EYSSW^QjI49bKGJ~;)Q4va)l zf8rVwuznt`_!mbopkwyx!#|dpUQPz~A=`WKjVZD3c~N;eo}BoDd?^Ki z+SHvUwUaP0pJ{?Zz#TuzHdZv$U{SC?}5Q?lPLjj|>owifU(d3dSK$7@TNj*mr# zQnHOf3RJMa8cEsnP!Cb)+UbY4FnsH#PrZBV{FyRRBO)TAh*pkX>rY^hUIbx0r6d%U z7XLE+GssL&l1AH5P4?CRMCi)D;J?-XQrS)-O-oEvl7k}nf z9Bx;UM)O8|xQx-!Le%Yx`m_URG7MtxYvbTpxeKHF?DF_4ka6UW7^te|YA5vm4o#Vo zuD_|QyfS?1d-fMWvVtbr=3W3u*!#MK>88>cBiNE?MXU*XD16pa z%ZO^6t&Dg}=`A|KqF%$d*z*b}Uz)1%t+HwctXvyJU(}D;=SBiYT=a_Rz)>s{bw$`tOHal1{pp2d^<5X zcAi-Zy@tf0L#vYvbTr%huN_SG20WvP;&QN_8*AL>+lWnL*8}YFU&!laXwYX*-xy`w zo~$Z4uhmwvdcpcVsagQHI$$E{iL~+ntOzBZjlTi^Vr3(isLxsOz91r^)-~x<439WL z(NCZHt=;o{5b^Mv#6pN{@jGMHAJl}8mf9H!h+DB}8LWdlA@t$ks0w-3)0+DmJ<;S1 zk{J6H8Zv=l16WfzJ-~4UCvPmP zi1RrS>i%Y|r^q{y8~ITZA32f9p1m*M&G!f^hR$lK7%SO=Oi@i+^&N6xu^v&A`_bY- z`Hm&`L6AY>DGlESj+oM>9{Ee`k24;9()BY0=Ot!1U(m&9#QIte8*Dt_Ad z5Yu;d*(VW@G@Kz2d3fkFF-8$KnwOVn&BXIo-nf{H&TP2#R1bU2`$88Ko41~=dyw($yJ)_}!cXOA zqx(pei}Mck_tgf`K6d6X*bSy#J)oSsXf6KMcJ^S(Xmj?4O} zgcyDAo6IfXwu5gsTN{4R+?7y1JOsJ=xgxVtRIOEP!9VR-t3Q7?tj|QTBw!MIUU=w9 zWJi|mFXt4Ve^Br@38Aslq=~Zm$9WwM@eNF=Bas`vnw1;Bs@$%abD<7Htk>t8C44g} z`1M?hNO4pFmok;JW^!iz;4lH@MIq%2C-GVU_k4RV?}Uww)*`v_{T=as>T(@8E&TpK z>c(sNJ^KUBpS-TgV#S^_-y`^WlEspJBP6?HtmJ44qaOPOU|j;lZ#W2iHbZA>O#2D8 zxTEjuQeBK)qr9K9W{y)|`Ff6U)W3=Ph@5o`z4DU5WiR}X&IqB-!q-2fAQY{Z9rqc# zXK+^n6a8%^QFPFZO2vq(zcxW^{Ic&CF|M6G%+MDax)rld^Q$i8;je$b;+*3ep);|( zbp6c$!x+Pl(*%tQoF2X0%#KErBy@!Ank-PF{qoo_@7u5-8J6X1f;Z^-wu<%ImuLg?}r@l0*ilTa@eJS&l!&XX@E>3>ln**N#h6_3nPhZX^Or6(3 zV#1D+l6gbpI7VF{uJ^>?7sH75^AdTS)(!=H-YZc#-i9i$=R2n*Lk=S3)xAjT=Kop=o!bX$}yP zZKw;+xa#{A`t9aR=;jsH9&4fW@O&Dmw`5;l|J~_2^qShZdgLwUbbo4Ml7xd!VczRX z#GJM12Tt+T0zYSA$`?LLW#M>k5_?_3nz3o7vH4fI{~i{b1_NsC%25!5FYu~ij)z_yvn3~ z3DH>$vt{EF&1-W|H4fUON^*r9B_3P=4y|53aMV?Wl#?2jo%z196 zll_N1e?1jLN?F5}Use2zPQ+hmJF7>f>C6{nqU1{$gUQ9P*QnLzpktssDCQYxyPo}k zAj;bceVoD3ewi{nbdH{Mw0EJ&HE}9N?=n)ZGPmhDJ#p*6vzTzkCGAlsnCK|u+Ck5A zIZ@1TikUy%(#M~vC)1tE0jZvOb3`LcopRVIT%7tyR8H_^p3nUfV>7n^}^6X>d4i{@^}=7j{WzsS`7 z!CM6~v0mgb#kOPG)l|=wEklFK5Ys>6|IZt>M$`toA4<{4U5diUl{28!0cwK*Q1lZ&_D5I9t5!hkm(()00pO(^S*q<;?n8 zQ^gWvjuAP%$Hj^hMO1(q^a$Jwjo(Zx@tt1lPt1eFw1*R*!dUu*rlmewAX>Rok0_Qv z7_M5i^x3@O2y0O{B8C?;o&FZeuZ+0O|HqcGM>|B{Im_ISv9veftah#vB8<_Lwp+r7MZDSsyO z_Xc)!u(w6>eHeJ%=q^m3MD=W4A3)v{OtwZRn=L@8UYAN+#M!KAuSJ5uaOY8N%6y0x zL?YfS{$QT|NaIu88ablX31H`_e;9(#MU(H7fzuE~tlZ?>=udCLl{8 zM0S*n*Y&0<_mCpA6B1eNkLw~{ZDmQ%pp`4V^B#bItbg2>hxKY&e~Da!ib?$7G|1Y{ zJCCea3Xt^PaC+o__sEh+nni&gmYbbcv`c|Qa7N9y=9xp@Jl zf6OlNdNhxKZ?n6({$f1S=f1$aFu z?co0$qfxkAybX|n{dcUly+sK{eMwfK>K3i=clAsq{9i?IX`%0Z$@*QLIw2)RMNm+_ z9I;B%6Z&d?_pUr4w&-~^J^(IAq}DxX-VRwB!vdB)UH_{ov56*j@E0cWh;Mk?OSM;m zn1qxbm98nHR_6oggdLr%uc4&$SvyCTO}s6;iSM@HeCbl8iMsJ+I~8_q+_okLXR>`i z_ywbZ;1}?~_d<6;Llz7bebpG{%kb5V^RE1sinB7>NUZ$)z58|N-ng~ATb~&W_ae;I z8q22KxPqgAv!CI=0~4nBTo?2u_H~}lvbT##A`G>H=upUVmysd_m6S3_Qc4;={r+t| zT5qRwaS?w?^G*EKVIG*1J@gB|D>BFhr)QK+iY=XpCrNXVi7Hut=H0o#Ayrg6Q50r4 z)p55p8@?IL7SKdvNkE8DYkd&v0s!Gb=dkVT*4wt~JGiwKIx^QR557-XR~2!IChk0{DR}iSLE-PU zO@d~!W|=W}!R;3MGpw1CO~r)2Ufqa|=2(XZ2Y}KO;ZM5JAG*ZaZQhgdDah)h2{X2M zmOOi3k)l#K0}C@Vp_-Z+7XdjmqwyOsfdjYP1yc#-tl(*YGf5E1^~jh+ajY(`HV123 zE=0~@N`;wo$Yf9CL2o31ce_z z5@$LzJKdQ%^m`5l#Q;5Z-&6<65;fUyqyUr6;Vn6}c#*ddzpacq*0YlqMEaqEblhiZ zbI48QCIK<56qp12uMtqTVOi~~$?LsZe=Z;%*jo&R=;L9 zZuk_DMp<^&O!-wR{MqF+)|^|fHG-%;qeE!rWYqnY&?7W^-?Jj`7+rJ~TI$qFaiJeA z;*AU_=p6LlEC#HUldZ|kpFMk)yZSyru3Sk|^C{YEarJYp53Fg+i}+}g(bi2PJU0%1 zV6REfp+>;t)w*Ax3C=g_F`kM zL5c@95@$RiieZ^YUY<5}eI$mNxuKQvduisuO9)vSB=ZkQE!K8_CQePKZ5xbw~1 zlV>fsWE{e`us`iG7@!FK2;~VYmqFFt04QEc|A>KqS^uu10zBXWL+6@fhN;;ASx~UA z=5LVGNqD;ULV!MTvXjnKSDtR31pT6G;oA=<2#siFlj==Jsv#KAoJb0?gggKh$xQ_pBn7R-sw zsxlU?Y>wTYOot}%X3w3xL$AcG!R~8Xc)oq`z=y`Y3-Q%qwwvESk72N}v8l7(CKOVCvig^0au>-Xir!DI z))`!K(%o$N8V)QW`rN=*>oNE@kS0!tcPWYZ@v5LsSq97#Wy`Rv`i6@#zKP&B%25A*v^((;JkBdy zM7$}^=Dg0`jt44{>(5$`-9%0XWSm5V>m~8GE$#D5-#!^cAz{Ra26f7Ucphw>Y6gm- z!O;ejUObSDfYlJ2gsFJ<`{+uEHkuLoHkkmgTOolK{A`p4 zXG78Osov<7jpm1lZn9wi3K@R$yX5S>UK7E9Zih{X6=t$|q?@!C%xEYF;^z_Qe zp3)ZIcod5k@ni1Y^9XxtG!4|@Pd>h`M`y^R7iCY*&;yT%>FH61GXRwpen0I=;wSwB zGVlR%I!Etn{PvcLiDGsCQ;@uYG=(8*wZL&Vrp$kW0PxUA;5NvoeHep)HdVFR`zN$` z?{(0o()9=TKMf8TzAs;itBZ4-GohQOjg2WYy*1XR9%Bg(s1&Ek;m2>&@$U8YN5VPW zzHda;^Sy7VN(1N-&hm|&Ihl5U*ncs4ZruC!$SmhSskhLO?`#m z^wTDLYogW$-Uu%@o(L!gg<0)kF8xsaK;^rV5KXVkCfaIp<9e&R3U}R-Um31t4WsBt zlvmzW%3%h34!$F8bE)*vP|(>Ni9YMJ_{!=1_Sr?@y7*0{+__=a5B(3&uP-YOR_u6W ze(@-vO44`*`I6Cw|0la}ic#5M3j^U-Lr4|$C|_<*v;-leb3VOAw!l%)cvCP#4@Xj& zd=tioJ<4&8Yd2T_(U@_J6*YrHoQ8gi3a)?s62>7xfWz)OF)Lpp5Kbnn_*-spZIixG60$vykJVP-1#ra-Ifb1)%s zJ`uhf4LfE2>d(ojS{#uleb7EnZTi7jT`y2A#4|~@NOEfYpiWe4)uN0|Ue-GL9{l)l zhWmWttS66oFhJgk@X`p-#Df{E7HQ6S^dAE=__rqTAI}w(zPMu-|EcPHm!C*;WfU8e z#^Afrd?Vi8g`IMD0g2dYcc_@O+BG})Wzh1B#5Th3wqP7XOx3Y-@?PA~jq?mqVDae3 z-t%tEwVux)!+NKx8I!8Q66nr}D*)MQ0T*2Q$1aE>J!@eN--oo`VTdd?ATHr2UW z{E$#nilD&Sf-TKJ7~gX}lB4=pg=1Vn1{A9ZcDnW&wk4XnZS(Hum8EfPTsb z|J?G+9RGAmaP1uP|HeLgCLr(RMgt@1hN)|itSnY)A`|m6m9iel`<-Mu3@(v0^YG{R zVHAiT-#ED3{}?jSVW{CkjMrqfv{EQ*&uLpoK`!_H5oR8PG3+D9BdNq7+LF+4PJbcy z8#Hy4e4bqeDTxBuS9uIogW-<0JHv>%)B-d7H_gMuCGCyY_+y@l9CtUp+h_CZQRE?b z#Ke-RStI5B&c~+;wZsW@|7RaIAxS z#!3mAvoF!`!m1_>)JM&+^9=MHlXhzM)=s{q-q*l$pq9_mP8CU8xc!a}RnMUht#S}h zn!L<(r*3sn5uV&#cic3osW&0N;;CwbEsm6DrTN=7C{QQq-4!0rc10il^iP)pG=&a^8+}LzkOzUQ;@>%2q%iad5u_R{1S^AK2u{cu>Wl02ld;p zN|cyZ%qszwq~c8+E6EH4DVOL6_pK9d?28M`a5^BlkxIU)ydh0>-hM(59YOb2TF>zq zJ}ZL<1!Qgf#(C90cP8wxmgb-9p|lWgU$Tz7g+1>|?%c;7whlQ3VMq5gLsWlhvoE*ok%=Z$&;> zC&LqdO0TN#T5$5iFqPMEZnMr~l$nIWM1{#J-Dfb+H}xh3#eXKBzb_|=|zjSHDS|8PP!G6J_JewN1LFiQ?B*6cT^H!;#B4=Db zEPcVi9r}n9sF1ggJ;R?5@$xI=ns>0y+0Zt)1YODE3zxsb)&2A6G0HI7+LqY22zNtI z4rj_l7m=!HaV((Jq@VL8b6TXktIWu@sH-TqiD4<1XHDk$o=Z{m5EX`N%TeY_GxoBBwpS3ly+$8Cb=AR1AC2n`)6DeD#iJpZeU@}B$jh*jiYDxu4FFfPAY z7cp=^7b@>KW7n=ATCw<*9cf19x=w(1fpoj{i-f)uv8qbzJKcbm180iYm0GUGX`9-| zVViAxST73uN#1J5)4}f{Ju2Z^V)wD|e0_X5?HnrYVIHtZITVoLouX0>&X%Ui*KZ0C z!GSkm_M>_>!SYq%#{9HKK-2Hu7fk)$*cCr$H&|fYKG{zWSG!(s{Z$OtkFWE`z%9Vz(T&tMzSBtt$XwsMDtTLC?Q5vg z>M9!jT6m{AcZA*%@w>FBtDk&*;OAwQm?SJJ)?GI+CL*pn*z?V-n5Sm5&{Qrf2#7)6 zM&ZjlZc_oEYCVMaCCL%Az=Un3u zapFB7vnD-EQz>d>PWV_mO~$-m`i{DLg~#neYfpel3ec@dmU+p zS=cX5Z!r!Lt1_nax>q%V){t+qfzWgcjz-Ua(jbRI5=J&&sV`pr4L5%>C6!3iXFsrl z;hxs}&3HZD3N|A)?v2V9k1Wbc!&#XHv?o$H0?C>0Em3eyV|4k8w7D@TJ&2G4g3_Z@ zvg|L<_Sql3yB;E$iSQn6JdJCjQ^Nll*!j98-7#D)k%2*v=C=f?o5;(5L<4beDlOx~ zsNcIFE%41nI^@$XRZSVc11+o-rTfkea<@j%%?V!{>)|JF77|}?_{RrX{8Hsosnz0$ z4%-VO;3=2jtI5T*+;VQ@dv4fglWw5AKu6JDd7RC!wofS&;e1}dG@I3szfi->Z>2^S zknXz~8n2tXm9hpTP|}vE;*94of5&6xXLsBd!m7ksm$W^RdK~!s zd!c(&dq4m177Yw$fXA=gkCM)k5_A8(2!`$iftApUWk^1@P^>oX6P>x{9su7tp1yz1ppdK6~}X)hxw9u<6LJ~;5_pC72EzqvZbm+ z{b`H^iZ7?`UJhVeGT~m_TcNbpWW5tPQjm$240m76Vj(hdEpO@Za5N{pT7#dp8&xk29`?bF%Mtl%O}iBDAtIp;_6$_c@i0$ z3o3D`(8N;O{~~LlX%)-wGhM^UuUt8Lyz*4+P4C%HUU>qj8mPg!dO5Ms5Oa`k7K?Tx zZOk|yp$YO}Id}jSv9OpkW_He&H$L&S*G^LLC0lF<_3hZ*1XlL$#kJoTz2>uQd1eb0mn3H=5{IG$qQuxGy%p ziv~!`);>gCjw88;H*D}N@;Cz%Wg>^Nx}%)X70`G+IT}nT1p-4pP51d%v*!U$S1ZP# zIL9xFRMnS`jzdKuCKV z@UJc9eh){I zmTnL*&lrxbf9_xIv}Pg!jHp_|ix`DW@55BC^Njf7{4+bHWnD2a){J0WM6>xHBCy=Efu6ue=3F4 zJ5BvhN%68llv0p9>i97QCc^$AA^!C7BM^PP?w6mx)po!91Vh029{#+!N$A0O8Q;_C zBJ=2=O9V#-J!22q?+8+Hveu*jqD3#=V;6%nuxets%_npRhn7_36bO5g>RWm=*z`V* zwm4@l(PUmEHP(yTe%Q@xLxUUcm|r}iNhM!;;k5HHDXGMvkcX_}^v1IGx}A^!?RXhY zl&U}}K@NQPCK`D428kCE?t4qwX3JG^pwyE6pnAh$JJ;%UMl$-PcL;{hJ*7S!(Xz$c zfb6vuB`oQ}9Bjkb{w)HmHVRUIrP+FpC|z&)dNw>w&$|aJnM5VcEf>bdY2LTe-Zwny#JZk^Syp`QX;FB{{uP_AIq8S*bngP9;lDAXC^P!2z})@2IKvrUl2RXjCrH5B z43$Xqa+|@?ujI7Cd+T!8ece?;tqwBVxS^pX?$w-wuSQF&cUoCt+JhSA%A{iIbyVd* z8nsZ;gGW|k>DQIwK9z(UY?08&XL*+1y&o2ghu2rh`)$(k=Hcfz1PSyktHJ0X;72@P z&;fCg4y{L1P?dIg_VbiZh-O$T{`&x?otHmJ0-|mV{nWot3G%i=Yz$Z_1nQa}X%Kms z|9<8XlzGz0J0Tj@uFJ2(THk(QP;XpSU*oXIhWI5O5ELEI59Fz8k*~rEGp@g5tc*Gg zRuao);I8~hJF6g|mRn$x&=P;zozlxnrNRy+U*X#dyH6l*(j}dDt#gQ)V6_e_` z`SjWj6<0>RGL>4jgG6Mf;8I{ZYBVp~J;|F_h|4O)nwH_!cSs}^e)SG2+uAG1+f}(B zX*I$2SY3Xm_q(Y~&wj@i@f4YCgnqUIR?cJl{x>rQZqU^YA4}$C^v+VW)9cf28nSm_ z?#yLt459LygJ{B;Ag1-w@Ig{Vc*CU67!a1+Q*Dj!H^rUvRiyWTA)%*4HE8@1@T6vP zf|-T*?x<^50{1Ef6JoajlGHjaM}j!l<}|B=my1Fz^-?KQIIq{D$^Ebn(gwVQhzg{9 z=F~afKk~?HNLIT1FAI>7gPf3-iC=lUp`_up~j`Kg{3hRz8- z3%PnV^x%vZ2DWJD@H)ltO;FoQz^76`HD$mZzF9HSa`6Ve!2%i#-RhdXJMd+lsS@Ni;#ig5D zE;?P5>NX-SDCii-!MzG)juv%UvSl}2IGvMh6za3(K^bQm7*_q( z;)Bwl@HWG|(N)51Ui2O0W`XFS^=@2I@a1`uHM8I7IDzB9$jFFBSy8}M95u}pRm=kw znO)(_2mJkR7dWoIt*Nq|?B#&*|9O;wTB5n|s@e4qlu(EepNO31 z7m-xGtn6vO7Cw#JI_Am^w2Zr%vX1NwYLXEQ0l%$c_y2K-ykn`MXVV5r$q(=$xzMd2 zMTy#UA^|| z+dpb2ax{a}OW*Fjp)QPXw z;;thvt8XIyi2gG9i}NuY-$0MlE81=G`%{YYA_ZQW3{12&Ly(w*AN{MVL47Z)Q68c5 zekhL5Kmm!iAK8(Nt}5fLw^e~3jN(zn%T)?H!F8!f@rgx>EfFK_JPasx-i@XpPJ53L&zAfoy#0x1s%gu$XYks~WYO@gM2?mx z_g6h6%Wh*wMV*G?#gy=Kt{p$pdDdCqT}U3}a39uG@R4lWJWRW-aVbMtF7tR%s@|vC z=q2*Zb3Mb6{`PJ;zVk$U>Vw&c4C?iDKs<6Dl5e+s?Q@nRDA@QkZF3@PL-8wC*iHC+ ze>4XSU5WtN29|*Q2>!iZ2U%=!C3Y$Qf(a2Z9T1V8t(&GXw=#>T&@gNq~R%g`wOaLEB3X z{CJKfgy!}JRz5GWkRHK=sOWoMl8(cb5rUPk>82x~s!(%`ExrUw zpaE6V{y@6}vJM*h(am*n`Z%aW^w~^R&WVM%63nI;Z*AgXs{<{4436g%Wkq7EoNyXKQ9=VDj{PSIpFz<1`BAHfE^?88pv6)u*oQQsQrWJDjEKAX_Xe(QMWbi9{WH_F+$y zbiVta4*QqJg81=)UCi#3L?k4|ljjTs0a3bM?hqA*ubetZ9Q1U}Vn2n~`JXUIte4NQ zW#vWr(uRYnycXM+ChS5({P{2A$ab)IqV*f(uUFIg5dL|Qh!65=oGYahE}gBRQmwQh zI?X~`90i!B<1PWOlI#4dCm=PKfcy~j8#n;VrYBL0Al%@83|rv8!L02q)C%i!Dv)*} zzy;Jt<=An{Td9))ethau(Z@Zqn$?C`cW;ghwVPs8njaNWi8XZ`Fw#xCcb114)`$3H zIPY5yX-$Yqd$W0S^s5WD>85zQl=uJCV?^XEB}3^c>DADjXbNz08#?MRL#b4-Rs&kP zfXTlMe{0Bac&Jp@efd}-pidWf;tOT6qZ$XAKQk)x2SN{pa#SQ7M5T>?=zU?x%IoXw zeX5**dEDKFg>8Q`I;%NqwO3G#;@DHxK{cj>t6MMUZL?>3aE`I9Q&v+$y~HPXe9=F` zov_%&imWvkw7MQK+`5OK)%^45koz~XSN=Uu3m^vbUdAYBbCcGbhChl)$kwqZ&r%ck_q>afM)GX4hG;l1K|COs?2b+X_z-N|MhC0v&zQoG1 zEbym{%<#uezlCj?gI2Le&ZE=@-8y`NtV;y@SIpjmth@X#>Q~{v<0+2xpN50;a*wl5 z`X~j4sS=9VJc(eBzYVJvPin@++|%=1NqTgf(v-PrVNxwu@iDf0_s$MbV_-D{2izxk ziK4L&8(zj~SX5}?PDJZ_G=DsCn4*2(g~49|rWAji<{We)7r$bs{Dv!b+HzX03e5>|5Y1hUKNN`EUzlBTYo#V(N4{WG+z2oC@uOYz^lQ+a zL_2N!6T;p%VsmMTp~xH7yTP}?L&fjfpxHR^y;KOUB1Yp{kN|q07{oacHi!d_A);8VtiqX*%KMMVi;l33XXEVD zU46SF0=Y6AYF2hST?{d6ip*lsTGNc$w@{2GHn>==2!}ebRO)4wzL209VZTwmo*R)2 z-@BnE-M8mwnbS|M7N-hjt2~4Gp1td79w3S23<=dfq)^oJlhbYccJxI0n90URuUnGJ zvNl?{KBDf`)KnyKZ<^Sr(Ocl*aL99BGO>|s_5F-{KO^1`slJ;_F7h)l$%q^9gn5$Z zk6w*x#$pYud)^35Cq0^6Mb@0`MJ?UODxF&GPx8+GJ`Iv!6T*W z?%*`ZI6V?P`@}{rG54*U^!l>%M+W4Pq(1>nyXpa0=IgSL!;MI$gEp;+Ei-Jtu6M7* zn8`|zr0Q^>tTr>sLt4 zBSus?C#~nYkBxG+W|r@FoB$d}Yd9O;=w>P_ENM`y!%B`cBmcebbfT9K(y;$n8u{?_ zo8kpd2F}O17+Itmmo49kggKfnen~<5Y5+1-Un!gX^mB-S#u|Ka{mha}N`n7uu5J^W zveyNkb1rg_b`EIqQ=l;>j|~HMToLqA#sdv=5;XK#RP`b~oOJZ}16|J4V*JA;+Mhk4 zqFiXo(B+vX$0=HX_FsWO+s`bYRIg^(FLEqQ-7K6Z0h`jUmZv{u(8vex>ScDm-*?j&3h~Ru^~Qg8MA2VakW@ zh-dYPb|E<2K=; zi$0kyg|kUZ3cG3VKcN{1=Qd}n@qQPT(!sfP-zJH-c?=X*LcAsCsbFY9rMB|c*4&_B z#0Ig&z2&0~6QjF2jntyHP2|&1zo`#JcCs0+NXG|ZgtVI4R!@l>{AGtg9F_Sk;1NEU zVjFNF4O19~fpbl{v7V6l6aQXS>f=%4(X3yp!~`)raN*t)t^OI#~7L)AOuZ-|qhhm6Gc0 zSj=;Bzq>L&5<(JteCO9OwX;t$K?!2AZcpTQMGfhLd*J8ASFa4g#a2#>=5m3O^8Dk+ zp)D4<0iDCDFF$b%K4dA8PSbaGv0-1}l$3{MEjm~H9*yGRnk3?^`(stk9ik`jc@kXi z5KX%$lV?bl+*fJ6R*1bXav~Z*ybV6u5_)mAsMQMx%~*Xv^*jAn-Jhg15BFH;(HSQo zel=vbfV$=0Ye-c?5??2RKWW#G*+;RxfoOB7tt4KsPhHrkp<@1Y^3ME*EdwM!@r?zX z?FwgnH~CIzqce~8^@LxY7Gn8hqTihL&2>^aj$6KesX<{Ff#VSC zOP5XjL}v03_3tsg2q2_ZWu`1%$27%6fL_8!k56}p?03qb%;Hi*qec1*2Fktb|0R@q zGApl)8vEdcRb9#rv1C3weBkq>T`iE)cRewYe#iNChHKPhu>!F(X2K^c4Z((mcZMP@5JMGE+uc*4v*=gW=V8!$2VtJ&qg1!^E2D^0Xl67^X zux_SP!S-?0eR4#(mqZ(U4FKZK;)EUKQL?)>h10-m1Na+ww?)mb#h(FC+y|nJ>S%Y$09fCG-9)-_*#N z+G4xcgBL4i;NMRSsqjHRmu^j#rBUkQQZKSlt_pod{93xZSxVZ)k6DP=2KRmd4CWus zcy4T>0gFB__1 z;)}F!xd)^`FdScrbnh+1zG^C4$goFqNdfIkS?|qR?@O~eVLDsU7ZHza%qQCc;~U7F zm&P+h{zE5jSN?rhzjtMS*|cQsm2|#r)i<$U4ffa($+hofH$h#C)FCaZD?0c(vXrz` zV}<|G87sG$tnOXr7pn;$_<9%lfd${~{wF$j@CHF#5Y8I!?RxqZV*h%0KP>BdjnR0Z z9~+F+umco=MdqHrG819JLTev90~t{B^qJRw6Ik}DOg*7C&NiS`9CwS2O21M4I2|TG zIPW5TeJ~}^Pv<`Ad-u{i^?Y41i}3Db_KD-vk4MHUvp;Z-K7U!ta=CQAxL7`lH}v10 z^(?!qxM<`N!eaiv8z&{L-gvT=a=5Pj?q`BE76jZI;ar3h9WqxvCw&m@Ve0noDbjcJ znusoYI*!ZLo9ELF7mFgKaU(6KL1ai5zYnnMczGljtFwOzOt}3{oTri#BWkl)t?2o# zme|AIE6DD9@JGza5b5en1V;34i;EWN*Y7%;!t5ldIzItOK(gb1C-7`6?v2u(wF%^!Nv z#Bs2OV%Gp$0=fI|JL!G)b#(+I$nv`If&&)wUQw=k?)_MQ*@Hl+t*IRRq!P2s*{GiyVCQYWeal$E@tfAK zy}8T^Puox+^_y*s9L%tt;!`sTXf-ryoiy6|M`C$CqAQQEhQoljl9_T7!@Dhk<3H_M zHFkl*6Fhi4?OW}fgdBxk=A~F@T*ZVhd{Un=g^p(AdSIRmsqu7tkYC=&uqzY6HT&h% zsm3|Pg|shCu*xY#6NnV}ojS8b-vc9w+?0xps4#vYBB0CB5Bdn+&Ma;0>|KgpX6tqd3)|;^(M-%SQ z&@vyI%2Z@$&8n-NE&RCd_0Z3SFU!wRFv<(0?=2ql@?L`;{XE}dH{^b3))5SwmgJd# zU+=A2=aRppzvm^Yu?YrN*R?&O`scy~Hu4uA($g4}v#8lraNBAg9Shjq+aHl}nTBZs z$2v>P%B-Uj?eX;3cAbL^x{O7@tK7=Xo3wYo44O}lWMRZURFw4gewPmpHvG=~BpQ%lAL+PJ zH!i5D8y21@-7nWT38nD}-feAn=nhp%gaRg@W##;Y`e7x6(TK$76X~rF))nMdDQ7~fP!0y~E9vuXE2$w`q3t@o#(^s zGZXASZPiJ1r0Ix8MOHFkfQrIT0+Jsrk+){ZhF-(+@*2?k!KTFOcTe<- z46co%{Jo9roa6ca0eqFCmX_9lScf$Tp->*4s+`hR7>E0S z&EgL)ECNe&=NW2>&fwo>ph;WSloKI0T=Km0Z12bJQ~x|S|Bfqo2vS2BS7jSfj&E6p zT(UTfT|Yjjjb^&jZ3lDfH4d~ZGpv*X{J3g$mq z9Lgip(jO*h(Iosf_7Ood<`53aw@~pu~Ay-sqx^yZDK*c$iuPXzI6&e|^Hfu=TOOwEnNq z>;*X(uDoPN6jvi(jCM*xd1i2!x%;x>v?l2gk?0|d7_1{+sc1j2I`4QY|3B_$6LD~C*)!zWBikXex9q($Bgvk}UYVsNA$yNx z6S9&W2`OY{kBs|smGAGqA9sKBXdKtMKG*db@A-Tg_E>Q3VA`Aq+QDl-ND#84&1~&0 zqpN+3hZ=P6D||D#J7n_O$TNyFv6Ptk!uy5MJ$lFz=Nr!!pn8x+o>Wp?Y%|~3pUOVa z>2iL0kjlizME!AK!1&8%UU)~A^0_r~S*6)}kQMKwe+$EVY|yNV(VHD}$fv$WC`#0t5WvKLji#>#gTIf4I@l$oUThDxSfe7{WZoIc25}@Fu<|_ z#+Z)G;qFX`_qS*gVQKFBpq>4W4ytZz;1 z&yKY`DHve>Z(-%ouh!dt)8ko`r>Gmlwlu^DnKZF4e|f2`%!Nj^iKty~t(b4E1(?Dv zzxesKXxA`zmo1fN^K=!X6x*++SZ{GKKfufj!pFyd1CwwX=U9`FK3)i`<^k0x_41N(f?V;x`P67o!GdyF=QF8-#R#!85Zi==Tl2WP(fyhuYA2#^ulEhZO4-uFW^Us zek%SuD(2+O^MGvyopPLOR3liFY z2;mg(hgiSmdu!OOPVkVHI?EF>MM6Ec`&D2WBPIqb5r%n+xv=%OjIK1xa4bRoh#{$;$1tLUh+48NzYWRxnCahIZ#@3RUf9<2t{5^2*5 z=W}1jENEt6!BZcf9I*dYrZJ++6W&NFB+X6X9wRrO?%z(kLj}w@)MaAM4m56S;p_PcKkJG!FpLa2qk%(np5o`3)wEELOu8IpizOq&s*F+KXY)9 zmGx2yQdgLe6y6QuRYWR2tTqRL)V2*V8vPFL+SA-DXGGU zlr#y*Xs@m{+GWs@61BD&?Q>@Ge5m;L_46?LlZ&0{`Dy2ON0UFD-vPHM?vM}-SeBH@ zP@@$+W5~iQJeB46dcfZTo9-QhL<1B^K=q*dRx&OcekF^Oy_u+I+68+!Yl1=D?JXGc zVR1|)l9nAkX8YAKeO_wv)>2(L1y6MZ}$)2-m zbq$E?({pEmlBY@oa#wQ567aiRrK3`FA)oUSfPa%mlR>gGf9;t*60U4Fi{UP-;(Xpv zpfZ|wZf5d|x22ho1NEoh2eLw}5D4)v48>~$jFU_KNK(15lSOmtJMv;GGCB67JU zud=OtQORGkd`!C_?*jb9CeO9vO!p~IV@9Z?AUbv>%s>J&EFCodmb{rmQ$Qnj9C}E> zV(=K8J15+xm9B*#%0~nI^MMQe!xL?3(Kq5raZ5kL9s{fQ#uI+Gx2hgHeXHiNgyxq5 ze3pyYvw^OWoxwrJL6>HMt!(hW&fKc3VX2?V!nmDbKR3^Dq-^`GZVA;iBnzB8XL^xY_JU+ZYdyV!Z4iULfv6Y zg(^UOh_~wY$Yc1b0LmbcN8TE!yzHCBX#kP_HpMq`{&1riq)oe_D$flj3d?P~!g&w% z6cmvi`Sc$3&NEJ$v^M>H%HL0Yy|<#4A~;p@XAZmsfFl=lwzZ9F^DC1+uM`~=wF^3z z(-j6V`bxZJ`T{Jg2OPnLvcwWzHwV>~>bJVO5#y(R7b=9Zw1WmJ-4<#iMC>3$#hLb1CUC2TgDuCu>Mw4jD2&Mv8bi zuH2d!pq~r3nFf_}OPx(B#SJj)pxQ>;uPIYf`XDPWt1@!XH9@j-Juj6nxI>1mB4(^k z`FOOGes`KA$PmerArMNIIGFVG z7^xYO+ciy$uijj-@qq>^w72)QYU-BDtk^_{96-hz<|A^$zY=u`ImLg*Dv$w3i*Sd} zYKem5M%TNtlNZsreGX&OfUQ{wjgmG|NG?loY+v$k9Vkb_14Cy#@v8mMVlu@`Bm^=qA8IOf-Sn{z6QaugByILO2> zO7GqrQ74DCIw|Rsrqzi@!S)?@-1>XVu?_*f;Lexjiy&{)4WUyUh4@_{1qya;6VQ$6 zI647$XROV(a+W}&`h$3#IizIatcy5|4LD(Bu)ZJL2g2fQ?XEKt>MquF#^s;)TNP#PescN?_*F~FaN-VR5WSh&>7N(3GpzS$Kjn)5L!?=`m| zOB$WJMQKg7{mj{<*Wi$oN;{kM!o%ddEoN~-7@-8x+ z7_-nZ6jWLZ`|L!$gqz!-lFGmy{KsJF%SAaTOUw**r(#wKQdLIMxzA~XHsK zNniuyQbpOH0dEGDmjQb|#>7-Uu0JvOoo0y2P2Szo(apT%U$-DOt%$n4${dl96wsG!sUsdZ7<9p><26TDa@l{fu1}f<{yHi*% z$SLtb!|2m;^cr+>ww=|2a8g=eRu%mX?t!9#*Ie05e3E&Vo@BVO`XN+S?zao_f2XQ6 zPxW>B`N;8a?5}P|L+OkbW3Rvy!r6A+Gv{v{s-H}T%j`Ee1mR(;hz3>lG z`^DqCvot+va9%F|HnU(u3BaDAIwj9RMNVDK6PzmMv($9E9rDDuy zp&f0efbUP2Dx^-Z=|MpKUXf;gY{ObI5=1s?nxUPadVk?Zvhn~xc}&Tg35ia+=YgKB zv0WGd5kJ{g|5aC#XE{deaoV%}<@yI7{W}F2+|w(HAo!J45igeDML}SK?KVIP$~kQH zJbzmCijyCQ|E=^;8r{U$~2Fd_Nc@sGV$^9s& z-b+G-6NW7VU0o&FveHu3EsP4FA;+U26<5Kg@q+u(T&*TuFOfVhg#5vQk4)^CI)J#V$@qN9c!XKuBy3GPA?4tCDrZKO5t~3)UoH$FjrHY50(Evm{*`C*oiO)0+KG8^4cu{&2;V zdwiOovU7}+4+<1>F2e^pzZ>guF%HR8cGVD}(*gcFXmQE%P(|^URZ;X(_4_cQZ7g|<$f^4Qt}@}>r5(x4cR%{S&q`3LU+N+1dVFd1#w+`J?Q3^4 z@!(Ihpc$lY`9@sg{$nd6&}pWZxR3FQI?@XpyMrncPK`i~9A75VOPf)De%`*%KiTmx zsHJ88<$Tb)Xs|c2Fnsq%^9ilM-ZY|(6fJq3pf)Jgt|l|N#AEjC&pjkaD%x*#smav; zc@CNhy#7uX@#`YnsUp8Yz`$BIgBHS~63|H)ifgHlEq|8HTdER9-Zq!?HvDNOpD&+T zpq#Q1!a<2tvP7f?`SR?suZY5a{T{R~mn4CMt`Y2sjPTXg88ePB?^~{L6?vEir7b(%5&89oo46y+D_J4Ao(>Ush$E;{3!;d$lTyCc!kM$SPu+b?oC&WTT9 zDmt8bQ68kB&PlJSle@LLZs~sa7m9E);ezE6n_yb{9sgc@5%KFnqm8xI>k^aC`u;=v z;2zSX5Hn#c0~hO<_knnQel7Eg_|1T*5q$Bp$`H$`MPqMowVq)vieGJP#Rm!lK6RP- z6HWUbI+Hx|>dop>I6gyY1I%d!D*I4pducLI@#I-IkoKm&{z+v)N$an7t7;jgQB^TlNR8dXD-bdOKD^h;qk@Ay0oH5Z=oQAd?O+ZcKDKx1pb zL@;|ziP_&rR%xWhldm6C&)_f{xv<3fSi`y6yr-F6K4Th8CG9t`m~nGNd%>y+CtVjUx6M#aq> zcCVx4RV}E^W!4omcN9tWgka*a0Yfe^?1tR_>9m>Z*iSuGvxj+NA7|V=Cva5i+vmeZ z)LuDJZ1@0tTOU7bdv@#nc_k`T=B=TY-{`ykBP?b&=s|oC6Jg_Fr;d zQy?U-;YomTQ1Dvudvd-OeW}M`Hoaf;Ie>2dy9O?M0Ad^KFjC_=bL(!edFpx6=WCN6IWIFQY~ zrj^4?BpBQ2)A{__!Tc}DLhb;>BSid7`M@!tO2#!N7fy`Z&w(E0c((U*h!nsQ_u%27 zx}1{tHb+Fp+*=bI#NBB82}KVEh(IMd2&~x=ZPD26+#xZ|zL&&&$9?(vc9z^Ux%ZhMl0(s52EtXg4T1G+{!!ckR28&KcLclxC-;VKDgbu6n zG$`OKWeDgQdDN>xYC)}SA}UKicn38eu}UcfnWfFGSZ+&Nt0gmh<7x@9+;2IM8K^*^P>fknH|nN@H_V80jDkdi=nvpS4%4&mBlMw5HxOoEh17X#e*b?hdl%?+lk zgL(w%x`%?EW_gPVuU|R+umgqMQZUL!wQ8gKCu2dgJK6{(f$s0Yrp=j03I}h+>mrlp zSXROP(t-OGmx1p-0Lf5Dw(u9z!@ZReH?j~_=|K>U%)!g-=#BVCvTlt!>^rMBIW7h z@@bIt%u7{3fhmqwOdCj(+z09{Z|fGXC66Q6SEG7BHLZp zKd(7qm@Gamj~pt9A;v{>h6NxaFtSa${L8s{W?mcNF#<-?faz*jvI`>c%$F*9?$aj* zKo_D*-4iNWXtXo~tuO%Dh}7b*5&#ZIJ|tt2PDCZ)^7|9xDE1ihqNYbS3*%bh@v^Jf zKYE^QW|0-4A*GhGk`=h}O>kv~;HR+7*#?SKHZ>AJys}vEV(E>Q@qyqoEOhtSd=vrj zmvX_f3r+Q5e~D2?%zU^_GFQC84{wxXdY8|TZrNfa2I!6gk?Du8h!jKbfoNJcSH*iK zP$#q?_EBUE6kBg#gN>hCi8&m2?!3aeW`0f}@p!MLYWMJ?>n`T6TDC zV`UH0@F;wpbhl(8R!Wkc6>1+Vk4((vnY*#Jbd?+$Q%o%PO2w zb1f_S{H#R!-JiNBK&~AB(*0J-i_`8UGr8EMul1(05G_%CkiE{?lI^kUfzNR{Db}`a z>m!NgCq_+Y?|mS)DWDypqUZw+V?L6yt3Q1(^PvKF*%!PDHAvH=$8s4nO1Eee?Eb}3 zEx~b}K6XK*`%#wP{91CZ#Y_E^>P*Rya1snSf>t+-Xn{iAl;;enk#tAIW=v!+iyaMj zmF1y!sFQnqo`Z;tBlUiBrML!<5O3G*Kof?HgH{WaA@=kL{+o_+qQ z_g#gHwogII7z-Yr7-gfXRHL?H576%5qAq_E_)RSxY7o#8nCi2?hRwr$sGwx097V7A zSzZ?qALH~bNkUiih3>w&k7bKnY*s}oF`AD1vmS;#Shqpi`0KY2d6^^F2c?d0?;oLu z6}g_rO;?OnWmyTME~+oB;X4jz;z9lOKez$BftjC4CtPOr>~|NvL4lR0 z7#TyS)2pdl$4(pF_xAw^?Ps;R*DEaB;DetRI>bpi$R93Yjw$d2ylA$@a=xMJkpc?j z*R;quTN>>b5u(~dx?TYP2z_yuBO96XjEb8#6O0JMC6oQa|`b?-TJWoK0rm~ zuvRtEf59O3$2CyyLwokS3nh&N)^ijG-j41zX=l}kxYL7Evv<-2GRu<#(MW-3==J1} z4)_Q0YBb(k3u9R|D{bcD_fg|I0$mgIO~1Al7QMJ4wRx%ih;Y%vqQ$cfBTKV14)m(Nn=6*o?WLg zrc!d>A@47>N-nL~leWC*{K1BC!j$v$q1BuW7^t3iM7Sxzac_0Q8h%8SuVOHEo9_#% z%n>EI31s1l5~!=n7UxbsUH}kj!hR6(1Gv|)tj=45aR1bfY_`sBczW6T^H1lN)O(pN zw7lI$U%$a!y=kEFf!b@+r{0E`HbcdFCHcV;u5+Ru%YDglC{tM!w9gnedc?>8QQVa1 z9B^(iN`*wx1u{+$NwOTXugMzh7XWR_Dhvz?c(AOl>f%mW`53p_&Kf|b!e8RzaRPRa z{OuD9r5l!tIL`8Z_{cN1lw0U0sRxHXoP4S~Q)Rw6iboMyzG^L&irmKEG#a{|BmOi- z*V}z0^w045mIZW$Tkmdk^>1i9u&C(irL9g^z4pC0S+RAB&C6q|`v63VH?k(r|A6p_ zyDVDP)drh_{hMLD$1G67DPh`d&3voY1UoDplo}NSWuhHLKsD!cnNqz!hli0B^P2rH zsPu^-HV-@-H=2CE>x_LW0D;Oc_~b~ft=JgdZ%1b#;xP>``A!BhhZbz2gkCwOi{b(! ze36&<>8UITZdGFmMWHuNK@0CRe*a2vP7wlJTRd+VQE}r z%<7vESLgQC321|>+WXj{lSC}IWBlX$9{T=}8ybU*D`y&aH$`l#Yg(0{mmFAFxx5W*u4{I>w zO3mEJCj=6Em0c#*q0K{^?7?d$24`3Rq*6~6AGc55mujM;^Lmo)t|4>M8hCbuSI@2= z9Y|170EM7-**J_r4^>=c@^uTWBcnO5mQaT~@L;M&?@+iVF5_qz5M0>rAOV3Fb-@a- z+F>80Ha>wbTaX+&&m3?)N%p4CB(NMivkZi3S*Fy~M#+d+UoC7IL^~eQ8loQpk-hpu{;4kkgXPQ-Lt--+pFT zWAlOjU=29kw_?!V(W$C=214}V;m-hz;$z=;^YdQ@t=B=lKiKxH-u$ELg@cL@cE%hX zp2C|(Jh9Z{CLhhTu;i2w?Yc@eFg@X*@#`c-vA6Pz~H&{vUfRurp5<$`JgtfFU#37O=lh>>K)^IYb{5Br!6q3@DK2pu(nQc+LMJm^cR_=)GmK3y99=L`T z$(fAR)7%Xxd=sfQ)Vc)py26}xurS00Kmk1JIM617RC2nSY)mjD&)~NHg=zV)m18`~rQ; zFF(A-3>u1s6HEd*=G|9)_j03PDK~+-L;sQ*5Ww;oIEZ#k$|P*^n0oaT-!Ww))bVMi zx+9^L1uO?~o&vP&-k(|ogE4dfjrv+JhR&G(#*hpOVfa6@PIPiZCk((~#DXq!2aj|M z_ZOcMItYVI*}Lfx$J5nEq&t9rSQb;UysTsDMa`L03-g%>O=6v06d zhR)}ci!O#O9iFtYltBdg5r`pGT4FH7aJ>Ib0Fdx8R!dc-fMC;SX|_B~X=?Jrys8~G zwFHcZv}Iykg%VaVukWj3MbbV7-X8H2!l|NpmMKoL7K4Z8M@TS{2{6*2K=(Uht%P?s zG3eA=SXlOKKH^}2(;VVJvJit@DZ`b=i0jyqZO&_)>yBBB_nqRjwd>`(p11ULCOneZNDcylUvUeo}Zd~{P*b%fj6`U9wQ$0 zmBj!PbKn%MS5~jX6L)Ppw5Do1ZZp$l0unMdXjCM=nxa@3q|a+WJlSJV?1nYm(DgGo z1jO7a4R&5QH4UqkY^AP~({X9>^oKq7|0&ZmjP06}3rvkOHdQG~2!Mfkj?_~{bTYWCA? zR8+VUr%&a~an5R6g1&lv47kX8?XG>o36R2xCKaM50M7wx+E>OpHv1j45bIcL{+9}r zLJbz9=6~l14&G;=>){1b9qK~zmiWki!<)*KU$k_w!)SDoiaj=Rs_t~JR$F5Rxb@D&j-vH98O^}?@?sE0tStku1A3vI1NXJoU;!)s5FcCB%UR@olgrI=vTcTnK zt5sBjK7?(B6c<5U(N-19b_{Y@9;$;XWo8h|x2@Toc5I?2p+oQx>rnD35MQdCY3#Js z{dw61>j_1XsXjIVT9YpX&R(WI3=WB*t8G8a=2ylAY1|H|!CnNcw9puJ8fuUuVibV%!3>E|<9RgbXm`DBF@NYcW6qMo9YQ};$E(OlEe@k~?l3b3x z!_OGM12&0=%lO#5GSWJL-MoCdzqFkZr_EC)o8Z28+K>H(XuWZXZfDjjN|$Q~P;_Ua z0B3{g6vv;^>^qLXgbsp~fU^fTn&fJ_=U>~U7rUXp|IUSA{~#D^8^{^gCRY7W&9K_LfW30+JV2x^0!SlNLWt2DT|kSy%tcxZgpOGz>{9#o<>MJ2~qX zw^-8@)qFa2Q_mR>`l-Cci$yxA%nPk=Z>1t$f|UndY5MBK>t=sw6_6=pp7PDT9TKC3 zdEOl34NZEk{`Wo@S#DjO>`Tmkh~)Aj3PMBZLvmK5(#wTj*p$H327gEXcQ*UWX=JJ1 z9mmJv2A{!YJY3zkT+2oS(MRZSS_=P;rle~EfQOVflsEftRJi?!tMPbWjR%hb#Py&H z+d$}9@TY#V|G6>1Tlzw%Sc;K8OfSLkw|n95AR)#IG%#F8#j9^2(0S5iHdlGvW`xa7 z*$&JK6ji0Jd8wZ9-z&qQ1^#cmSGyp;YQ+s^BWw=+@4*q!M_53Lw8$lp7vx-#XUfBgGD z;5Sc#t8x6_f5PqOyLxQ@`xLlHuO>ev_Wu9;=>PK*|NnoiEegCmxkPiP<#=Nm=v;ga O{8Cm>N0!T3g#I7By|btQ From aca165140ede1b087971d8d27f82af82c8b4a733 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 28 Jun 2024 11:49:06 +0200 Subject: [PATCH 0740/1012] add dispersion to NXmonochromator --- base_classes/NXmonochromator.nxdl.xml | 145 ++++++++++++---------- base_classes/nyaml/NXmonochromator.yaml | 153 ++++++++++++++---------- 2 files changed, 168 insertions(+), 130 deletions(-) diff --git a/base_classes/NXmonochromator.nxdl.xml b/base_classes/NXmonochromator.nxdl.xml index 91e5ec7b30..0d8386f916 100644 --- a/base_classes/NXmonochromator.nxdl.xml +++ b/base_classes/NXmonochromator.nxdl.xml @@ -1,10 +1,10 @@ - - + + - + - A wavelength defining device. - - This is a base class for everything which - selects a wavelength or energy, be it a - monochromator crystal, a velocity selector, - an undulator or whatever. - - The expected units are: - - * wavelength: angstrom - * energy: eV - + A wavelength defining device. + + This is a base class for everything which + selects a wavelength or energy, be it a + monochromator crystal, a velocity selector, + an undulator or whatever. + + The expected units are: + + * wavelength: angstrom + * energy: eV - wavelength selected - - - wavelength standard deviation + + wavelength selected + + + + + wavelength standard deviation + - wavelength standard deviation + + wavelength standard deviation + - energy selected - - - energy standard deviation - + + energy selected + + + + + energy standard deviation + + - energy standard deviation + + energy standard deviation + - + + + Energy dispersion at the exit slit, given as eV/mm. + + + - - This group describes the shape of the beam line component + + This group describes the shape of the beam line component + + + + + Use as many crystals as necessary to describe + + + + + + For diffraction grating based monochromators - Use as many crystals as necessary to describe - - For diffraction grating based monochromators - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a monochromator. + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a monochromator. - 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. - diff --git a/base_classes/nyaml/NXmonochromator.yaml b/base_classes/nyaml/NXmonochromator.yaml index 83a26bf0a6..1d6254d836 100644 --- a/base_classes/nyaml/NXmonochromator.yaml +++ b/base_classes/nyaml/NXmonochromator.yaml @@ -10,7 +10,7 @@ doc: | The expected units are: * wavelength: angstrom - * energy: eV + * energy: eV type: group NXmonochromator(NXobject): wavelength(NX_FLOAT): @@ -41,6 +41,10 @@ NXmonochromator(NXobject): unit: NX_ENERGY doc: | energy standard deviation + dispersion(NX_FLOAT): + unit: NX_ANY + doc: | + Energy dispersion at the exit slit, given as eV/mm. (NXdata)distribution: (NXgeometry)geometry: deprecated: | @@ -86,14 +90,14 @@ NXmonochromator(NXobject): other component groups. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 7c8e15a2e9b17a3867e3f0c2b0b16c8a8c70c7b512f1f20340e7a2398b21ab7b -# -# +# ecba3d69bdadb42a3876ad43dc553e850899523dfcef3a3eecb923f71eb0f032 +# +# # -# +# # -# A wavelength defining device. -# -# This is a base class for everything which -# selects a wavelength or energy, be it a -# monochromator crystal, a velocity selector, -# an undulator or whatever. -# -# The expected units are: -# -# * wavelength: angstrom -# * energy: eV -# +# A wavelength defining device. +# +# This is a base class for everything which +# selects a wavelength or energy, be it a +# monochromator crystal, a velocity selector, +# an undulator or whatever. +# +# The expected units are: +# +# * wavelength: angstrom +# * energy: eV # # -# wavelength selected -# -# -# wavelength standard deviation +# +# wavelength selected +# +# +# +# +# wavelength standard deviation +# # # -# wavelength standard deviation +# +# wavelength standard deviation +# # # -# energy selected -# -# -# energy standard deviation -# +# +# energy selected +# +# +# +# +# energy standard deviation +# +# # -# energy standard deviation +# +# energy standard deviation +# +# +# +# +# Energy dispersion at the exit slit, given as eV/mm. +# # -# +# # # -# -# This group describes the shape of the beam line component +# +# This group describes the shape of the beam line component +# +# +# +# +# Use as many crystals as necessary to describe +# +# +# +# +# +# For diffraction grating based monochromators # # -# Use as many crystals as necessary to describe -# -# For diffraction grating based monochromators # # -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. # # # # -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a monochromator. +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a monochromator. # # # # -# 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. # # # -# From 06da11aeeff8b49b2debff1f7b874ddf58b35988 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 28 Jun 2024 12:45:32 +0200 Subject: [PATCH 0741/1012] update coordinate transformations --- contributed_definitions/NXxps.nxdl.xml | 29 +++++++++++ contributed_definitions/nyaml/NXxps.yaml | 60 ++++++++++++++++++++++- contributed_definitions/xps/xps_cs.png | Bin 149037 -> 148952 bytes 3 files changed, 88 insertions(+), 1 deletion(-) diff --git a/contributed_definitions/NXxps.nxdl.xml b/contributed_definitions/NXxps.nxdl.xml index d1dc686bc7..8af6bfd58d 100644 --- a/contributed_definitions/NXxps.nxdl.xml +++ b/contributed_definitions/NXxps.nxdl.xml @@ -102,6 +102,29 @@ Set of transformations, describing the orientation of the XPS coordinate system with respect to the beam coordinate system (.). + + The transformations in `coordinate_system_transformations` depend on the actual instrument geometry. + If the z-axis is pointing in the direction of gravity (i.e., if the sample is mounted horizontally), + the following transformations can be used: + + xps_coordinate_system:NXcoordinate_system + depends_on=entry/geometries/xps_coordinate_system/coordinate_transformations/z_rotation + coordinate_system_transformations:NXtransformations + z_rotation=beam_azimuth_angle + @depends_on=y_flip + @transformation_type=rotation + @vector=[0, 0, 1] + @units=degree + y_flip=180 + @depends_on=y_rotation + @transformation_type=rotation + @vector=[0, 1, 0] + @units=degree + y_rotation=beam_polar_angle_of_incidence + @depends_on=. + @transformation_type=rotation + @vector=[0, -1, 0] + @units=degree @@ -191,6 +214,12 @@ Polar tilt of the analyser with respect to the upward z-direction, defined by the sample stage. + + The angle between the incoming beam and the analyser is given by + beam_analyzer_angle = beam_polar_angle_of_incidence + analyser_take_off_polar_angle. + In practice, the analyser axis is often set as the z axis (analyser_take_off_polar_angle = 0), + so that beam_analyzer_angle = beam_polar_angle_of_incidence. For magic angle configurations, + this angle is 54.5°. diff --git a/contributed_definitions/nyaml/NXxps.yaml b/contributed_definitions/nyaml/NXxps.yaml index 9e0ef9e452..fd8ee614a8 100644 --- a/contributed_definitions/nyaml/NXxps.yaml +++ b/contributed_definitions/nyaml/NXxps.yaml @@ -55,6 +55,29 @@ NXxps(NXmpes): doc: | Set of transformations, describing the orientation of the XPS coordinate system with respect to the beam coordinate system (.). + + The transformations in `coordinate_system_transformations` depend on the actual instrument geometry. + If the z-axis is pointing in the direction of gravity (i.e., if the sample is mounted horizontally), + the following transformations can be used: + + xps_coordinate_system:NXcoordinate_system + depends_on=entry/geometries/xps_coordinate_system/coordinate_transformations/z_rotation + coordinate_system_transformations:NXtransformations + z_rotation=beam_azimuth_angle + @depends_on=y_flip + @transformation_type=rotation + @vector=[0, 0, 1] + @units=degree + y_flip=180 + @depends_on=y_rotation + @transformation_type=rotation + @vector=[0, 1, 0] + @units=degree + y_rotation=beam_polar_angle_of_incidence + @depends_on=. + @transformation_type=rotation + @vector=[0, -1, 0] + @units=degree (NXinstrument): doc: - | @@ -125,6 +148,12 @@ NXxps(NXmpes): doc: | Polar tilt of the analyser with respect to the upward z-direction, defined by the sample stage. + + The angle between the incoming beam and the analyser is given by + beam_analyzer_angle = beam_polar_angle_of_incidence + analyser_take_off_polar_angle. + In practice, the analyser axis is often set as the z axis (analyser_take_off_polar_angle = 0), + so that beam_analyzer_angle = beam_polar_angle_of_incidence. For magic angle configurations, + this angle is 54.5°. \@transformation_type: enumeration: [rotation] \@vector: @@ -198,7 +227,7 @@ NXxps(NXmpes): exists: recommended # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 13f8cf4cba94b1851b1d8996d7e76a95cf8f7cd6adc0884190e51e58089395bc +# 685dcf74e0bf54a1e86183a6dc49a739e9102eb790b870ec52ff3d6c7cfe5b3d # # # - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of voxel of discretized domain for analyzed part of the dataset. - - - - - The dimensionality of the grid. - - - - - The cardinality or total number of cells/grid points. - - - - - Number of terms in the composition clustering dictionary - - - - - Number of terms in the position clustering dictionary - - - - - Results of a run with Alaukik Saxena's composition space tool. - - This is an initial draft application definition for the common NFDI-MatWerk, - FAIRmat infrastructure use case IUC09 how to improve the organization and - results storage of the composition space tool and make these data at the - same time directly understandable for research data management systems - like NOMAD Oasis. - - - - - - - - - - - - - - - - - - TBD, maybe how to link between pyiron state tracking and app state tracking. - - - - - Disencouraged place for free-text for e.g. comments. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. when composition space tool was started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and composition space tool exited as a process. - - - - - - The path and name of the config file that was used for this analysis. - TBD, this can be e.g. Alaukik's YAML file for composition space. - - - - - - - - - Details about the file (technology partner or community format) - from which reconstructed ion positions were loaded. - - - - - - - - - Details about the file (technology partner or community format) - from which ranging definitions were loaded which detail how to - map mass-to-charge-state ratios on iontypes. - - - - - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the executable managed to process the analysis - or failed prematurely. This status is written to the results file after the - end_time at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - Details about coordinate systems (reference frames) used. In atom probe several coordinate - systems have to be distinguished. Names of instances of such :ref:`NXcoordinate_system` - should be documented explicitly and doing so by picking from the - following controlled set of names: - - * composition_space - * lab - * specimen - * laser - * instrument - * detector - * recon - - The aim of this convention is to support users with contextualizing which reference - frame each instance (coordinate system) is. If needed, instances of :ref:`NXtransformations` - are used to detail the explicit affine transformations whereby one can convert - representations between different reference frames. - Inspect :ref:`NXtransformations` for further details. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - - - - - Position of each cell in Euclidean space. - - - - - - - - - - - - - - - - For each ion, the identifier of the voxel in which the ion is located. - - - - - - - - - - - - - - - - - - In Alaukik's tool the GMM step. - - - - - - - - - The keywords of the dictionary of distinguished compositionally- - defined cluster, e.g. the phases. Examples for keywords could be - phase1, phase2, and so one and so forth. - - - - - - - - Resolves for each keyword in cluster_dict which integer is used to - label something that it belongs or is assumed to represent this - cluster. - - - - - - - - - For example if the voxel grid is used to report that there - are voxels which are assumed to represent volume of either phase1 - or phase2, the cluster_dict_keyword would be a list with two names - phase1 and phase2, respectively. The cluster_dict_value would be a - list of e.g. integers 1 and 2. These could be used to build an - array with as many entries as there are voxel and store in this array - the respective value to encode which phase is assumed for each voxel. - - - - - - - - - - In Alaukik's tool the DBScan step after the GMM step. - - - - - - - - - The keywords of the dictionary of distinguished spatially-contiguous - clusters. Examples for keywords could be precipitate1, precipitate2, - and so one and so forth. - - - - - - - - Resolves for each keyword in cluster_dict which integer is used to - label something that it belongs or is assumed to represent this - cluster. - - - - - - - - - For example if the voxel grid is used to report that there - are voxels which are assumed to represent volume of certain precipitates, - say we found ten precipitates and consider the rest as matrix. - We could make a list of say matrix, precipitate1, precipitate2, ..., - precipitate10. With cluster_dict_value then running from 0 to 10, - i.e. matrix is flagged special as 0 and the remaining particles - are indexed conveniently as 1, 2, ..., 10 like end users expect. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/NXapm_compositionspace_config.nxdl.xml b/contributed_definitions/NXapm_compositionspace_config.nxdl.xml index ef78b66862..60cd32e060 100644 --- a/contributed_definitions/NXapm_compositionspace_config.nxdl.xml +++ b/contributed_definitions/NXapm_compositionspace_config.nxdl.xml @@ -22,44 +22,12 @@ # For further information, see http://www.nexusformat.org --> - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of voxel of discretized domain for analyzed part of the dataset. - - - - - The dimensionality of the grid. - - - - - The cardinality or total number of cells/grid points. - - - - - Number of terms in the composition clustering dictionary - - - - - Number of terms in the position clustering dictionary - - - - Config for a run with Alaukik Saxena's composition space tool. + Application definition for a configuration file of CompositionSpace tool. - This is an initial draft application definition for the common NFDI-MatWerk, - FAIRmat infrastructure use case IUC09 how to improve the organization and - results storage of the composition space tool and make these data at the - same time directly understandable for research data management systems - like NOMAD Oasis. + This is a draft application definition for the common NFDI-MatWerk/FAIRmat infrastructure + use case IUC09 that explores how to improve the organization and results storage of the + CompositionSpace tool. @@ -73,80 +41,144 @@ + + Specification of the tomographic reconstruction used for this analysis. + Typically, reconstructions in the field of atom probe tomography are communicated + via files which store at least reconstructed ion positions and mass-to-charge-state-ratio + values. Container files like HDF5 though can store multiple reconstructions. + Therefore, the position and mass_to_charge concepts point to specific instances + to use for this analysis. + - - + + + Name of the node which resolves the reconstructed ion position values to use for + this analysis. + + + + + Specification of the ranging definitions used for this analysis. + + Indices start from 1. The value 0 is reserved for the null model of unranged positions + whose iontype is unknown_type. The value 0 is alsoreserved for voxel outside the dataset. + - + + + Name of the (parent) node directly below which the ranging definitions for + (molecular) ions are stored. + + - + - Edge length of the cubic voxels that is used for discretizing the point cloud in - the voxelization step. + Step during which the point cloud is discretized using a rectangular transfer function to compute + scalar element-specific composition fields. During processing, iontypes are atomically decomposed + to correctly account for the multiplicity of each element contributed by each ion. - - + + + Edge length of cubic voxels for 3D grid that is used for discretizing the point + cloud. + + + + - The maximum number of components configured for the segmentation of the voxel - set into a mixture of voxels with that many different chemical compositions. + Optional step during which the subsequent segmentation step is prepared to + improve the segmentation. - - + + + Was the automated phase assignment used? + This algorithm achieves a supervised reduction of the dimensionality of the chemical space + through an analysis of the (Gini) feature importance of each element for the subsequent + segmentation step. + + + + + Estimated guess for which a Gaussian mixture model is evaluted to preprocess a result that + is subsequenty post-processed with a random_forest_classifier to lower the number of + dimensions in the chemical space to the subset of trunc_species many elements with the + highest feature importance. + + + + + The number of elements to use for reducing the dimensionality. + + + + + Configuration for the random forest classification model. + + + + - The configuration of the machine learning model used in the segmentation step. + Step during which the voxel set is segmented into voxel sets with different + chemical composition. - - + - Configuration for the Gaussian mixture model that is used in the segmentation - step. + A principal component analysis of the chemical space to guide a decision into how many + sets of voxels with different chemical composition the machine learning algorithm suggests + that the dataset should be analyzed as. - + + + The decision is guided through the evalution of the information criterion + minimization. + + + + The maximum number of chemical classes to probe with the Gaussian mixture model + with which the voxel set is segmented into a mixture of voxels with that many different + chemical compositions. + + + + + Configuration for the Gaussian mixture model that is used in the segmentation + step. + + + + + + + Step during which the chemically segmented voxel sets are analyzed for their + spatial organization. + Configuration for the DBScan algorithm that is used in the clustering step. - The maximum distance between two samples for one to - be considered as in the neighborhood of the other. + The maximum distance between voxel pairs in a neighborhood to be considered + connected. - The number of samples (or total weight) in a neighborhood - for a point to be considered as a core point. + The number of voxels in a neighborhood for a voxel to be considered as a core + point. - - - - - - - - - - - - - - diff --git a/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml b/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml index 5603330eea..dfd53baeba 100644 --- a/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml +++ b/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml @@ -1,25 +1,10 @@ category: application doc: | - Config for a run with Alaukik Saxena's composition space tool. + Application definition for a configuration file of CompositionSpace tool. - This is an initial draft application definition for the common NFDI-MatWerk, - FAIRmat infrastructure use case IUC09 how to improve the organization and - results storage of the composition space tool and make these data at the - same time directly understandable for research data management systems - like NOMAD Oasis. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_voxel: | - Number of voxel of discretized domain for analyzed part of the dataset. - d: | - The dimensionality of the grid. - c: | - The cardinality or total number of cells/grid points. - n_clst_dict: | - Number of terms in the composition clustering dictionary - n_spat_dict: | - Number of terms in the position clustering dictionary + This is a draft application definition for the common NFDI-MatWerk/FAIRmat infrastructure + use case IUC09 that explores how to improve the organization and results storage of the + CompositionSpace tool. type: group NXapm_compositionspace_config(NXobject): # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently @@ -34,61 +19,97 @@ NXapm_compositionspace_config(NXobject): analysis_identifier(NX_UINT): exists: recommended reconstruction(NXserialized): + doc: | + Specification of the tomographic reconstruction used for this analysis. + Typically, reconstructions in the field of atom probe tomography are communicated + via files which store at least reconstructed ion positions and mass-to-charge-state-ratio + values. Container files like HDF5 though can store multiple reconstructions. + Therefore, the position and mass_to_charge concepts point to specific instances + to use for this analysis. type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): position(NX_CHAR): - mass_to_charge(NX_CHAR): + doc: | + Name of the node which resolves the reconstructed ion position values to use for this analysis. + # mass_to_charge(NX_CHAR): ranging(NXserialized): + doc: | + Specification of the ranging definitions used for this analysis. + + Indices start from 1. The value 0 is reserved for the null model of unranged positions + whose iontype is unknown_type. The value 0 is alsoreserved for voxel outside the dataset. type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): ranging_definitions(NX_CHAR): - edge_length(NX_FLOAT): + doc: | + Name of the (parent) node directly below which the ranging definitions for (molecular) ions are stored. + voxelization(NXprocess): doc: | - Edge length of the cubic voxels that is used for discretizing the point cloud in the voxelization step. - unit: NX_LENGTH - bics_clusters(NX_UINT): + Step during which the point cloud is discretized using a rectangular transfer function to compute + scalar element-specific composition fields. During processing, iontypes are atomically decomposed + to correctly account for the multiplicity of each element contributed by each ion. + edge_length(NX_NUMBER): + doc: | + Edge length of cubic voxels for 3D grid that is used for discretizing the point cloud. + unit: NX_LENGTH + autophase(NXprocess): doc: | - The maximum number of components configured for the segmentation of the voxel - set into a mixture of voxels with that many different chemical compositions. - unit: NX_UNITLESS - ml_models(NXobject): + Optional step during which the subsequent segmentation step is prepared to improve the segmentation. + use(NX_BOOLEAN): + doc: | + Was the automated phase assignment used? + This algorithm achieves a supervised reduction of the dimensionality of the chemical space + through an analysis of the (Gini) feature importance of each element for the subsequent + segmentation step. + initial_guess(NX_POSINT): + doc: | + Estimated guess for which a Gaussian mixture model is evaluted to preprocess a result that + is subsequenty post-processed with a random_forest_classifier to lower the number of + dimensions in the chemical space to the subset of trunc_species many elements with the + highest feature importance. + unit: NX_UNITLESS + trunc_species(NX_POSINT): + doc: | + The number of elements to use for reducing the dimensionality. + unit: NX_UNITLESS + random_forest_classifier(NXprocess): + doc: | + Configuration for the random forest classification model. + segmentation(NXprocess): doc: | - The configuration of the machine learning model used in the segmentation step. - # name(NX_CHAR): - # doc: | - # Name of the model to be used. - gaussian_mixture(NXobject): + Step during which the voxel set is segmented into voxel sets with different chemical composition. + pca(NXprocess): + doc: | + A principal component analysis of the chemical space to guide a decision into how many + sets of voxels with different chemical composition the machine learning algorithm suggests + that the dataset should be analyzed as. + ic_opt(NXprocess): doc: | - Configuration for the Gaussian mixture model that is used in the segmentation step. - # random_forest(NXobject): - # doc: | - # Configuration for the random forest model. + The decision is guided through the evalution of the information criterion minimization. + n_max_ic_cluster(NX_POSINT): + doc: | + The maximum number of chemical classes to probe with the Gaussian mixture model + with which the voxel set is segmented into a mixture of voxels with that many different + chemical compositions. + unit: NX_UNITLESS + gaussian_mixture(NXprocess): + doc: | + Configuration for the Gaussian mixture model that is used in the segmentation step. + clustering(NXprocess): + doc: | + Step during which the chemically segmented voxel sets are analyzed for their spatial organization. dbscan(NXobject): doc: | Configuration for the DBScan algorithm that is used in the clustering step. eps(NX_FLOAT): doc: | - The maximum distance between two samples for one to - be considered as in the neighborhood of the other. + The maximum distance between voxel pairs in a neighborhood to be considered connected. unit: NX_LENGTH min_samples(NX_UINT): doc: | - The number of samples (or total weight) in a neighborhood - for a point to be considered as a core point. + The number of voxels in a neighborhood for a voxel to be considered as a core point. unit: NX_UNITLESS - common(NXobject): - status(NX_CHAR): - programID(NXprogram): - exists: [min, 1, max, infty] - program(NX_CHAR): - \@version(NX_CHAR): - profiling(NXcs_profiling): - exists: recommended - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - total_elapsed_time(NX_FLOAT): - current_working_directory(NX_CHAR): From 6bc6a12fd88a49db66d1103f034ee616f4821b49 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 28 Jun 2024 18:59:15 +0200 Subject: [PATCH 0747/1012] Edited NXapm_compositionspace_config to match implementation state of www.github.com/eisenforschung/CompositionSpace nexus-io branch 8febbce --- .../NXapm_compositionspace_config.nxdl.xml | 10 +- .../NXapm_compositionspace_results.nxdl.xml | 342 +++++++++--------- .../nyaml/NXapm_compositionspace_config.yaml | 10 +- .../nyaml/NXapm_compositionspace_results.yaml | 296 +++++++-------- 4 files changed, 319 insertions(+), 339 deletions(-) diff --git a/contributed_definitions/NXapm_compositionspace_config.nxdl.xml b/contributed_definitions/NXapm_compositionspace_config.nxdl.xml index 60cd32e060..974c5a6a43 100644 --- a/contributed_definitions/NXapm_compositionspace_config.nxdl.xml +++ b/contributed_definitions/NXapm_compositionspace_config.nxdl.xml @@ -23,7 +23,9 @@ --> - Application definition for a configuration file of CompositionSpace tool. + Application definition for a configuration of the CompositionSpace tool used in atom probe. + + * `A. Saxena et al. <https://www.github.com/eisenforschung/CompositionSpacetool.git>`_ This is a draft application definition for the common NFDI-MatWerk/FAIRmat infrastructure use case IUC09 that explores how to improve the organization and results storage of the @@ -81,9 +83,9 @@ - Step during which the point cloud is discretized using a rectangular transfer function to compute - scalar element-specific composition fields. During processing, iontypes are atomically decomposed - to correctly account for the multiplicity of each element contributed by each ion. + Step during which the point cloud is discretized to compute element-specific composition fields. + Iontypes are atomically decomposed to correctly account for the multiplicity of each element that + was ranged for each ion. diff --git a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml index b6536254d0..44a31e5838 100644 --- a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml +++ b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml @@ -33,18 +33,23 @@ - The cardinality or total number of cells/grid points. + Total number of voxels. + + + + + Total number of ions in the reconstructed dataset. - Results of a run with Alaukik Saxena's composition space tool. + Application definition for results of the CompositionSpace tool used in atom probe. + + * `A. Saxena et al. <https://www.github.com/eisenforschung/CompositionSpacetool.git>`_ - This is an initial draft application definition for the common NFDI-MatWerk, - FAIRmat infrastructure use case IUC09 how to improve the organization and - results storage of the composition space tool and make these data at the - same time directly understandable for research data management systems - like NOMAD Oasis. + This is a draft application definition for the common NFDI-MatWerk/FAIRmat infrastructure + use case IUC09 that explores how to improve the organization and results storage of the + CompositionSpace tool. @@ -59,37 +64,15 @@ for if desired all the dependencies and libraries--> + - - - TBD, maybe how to link between pyiron state tracking and app state tracking. - - - - - Disencouraged place for free-text for e.g. comments. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. when composition space tool was started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and composition space tool exited as a process. - - + + - The path and name of the config file that was used for this analysis. - TBD, this can be e.g. Alaukik's YAML file for composition space. + Configuration file that was used in this analysis. @@ -98,78 +81,28 @@ for if desired all the dependencies and libraries--> - + - Details about coordinate systems (reference frames) used. In atom probe several coordinate - systems have to be distinguished. Names of instances of such :ref:`NXcoordinate_system` - should be documented explicitly and doing so by picking from the - following controlled set of names: - - * composition_space - * lab - * specimen - * laser - * instrument - * detector - * recon + Step during which the point cloud is discretized to compute element-specific composition fields. + Iontypes are atomically decomposed to correctly account for the multiplicity of each element that + was ranged for each ion. - The aim of this convention is to support users with contextualizing which reference - frame each instance (coordinate system) is. If needed, instances of :ref:`NXtransformations` - are used to detail the explicit affine transformations whereby one can convert - representations between different reference frames. - Inspect :ref:`NXtransformations` for further details. - - - - - - - - - - - - - - - - - - - - - - - - Voxelization is the first step of the algorithmic chain that the - CompositionSpace tool implements. In this step all ion positions are - discretized using a rectangular transfer function to identify the number - of ions/atoms in the dataset of each iontype. - - Using a discretization grid that is larger than the average distance - between reconstructed ion position reduces the computational costs. - This is the key idea of the CompositionSpace tool over other methods - traditionally used in atom probe (e.g. isosurfaces). + Using a discretization grid that is larger than the average distance between reconstructed ion positions + reduces computational costs. This is the key idea of the CompositionSpace tool compared to other + methods for characterizing microstructural features. - - + - @@ -190,17 +123,7 @@ if one coordinate system is defined the origin is defined in this cs--> - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - - + Position of each cell in Euclidean space. @@ -210,7 +133,10 @@ if one coordinate system is defined the origin is defined in this cs--> - + + + Discrete coordinate of each voxel. + @@ -219,56 +145,105 @@ if one coordinate system is defined the origin is defined in this cs--> - For each ion, the identifier of the voxel in which the ion is located. + For each ion, the identifier of the voxel into which the ion binned. - - - + + + Total number of weight (counts for discretization with a rectangular transfer + function) in each voxel. + + + + + + + - TODO + Chemical symbol of the element from the periodic table. + + + + + Element-specific weight (counts for discretization with a rectangular transfer + function) in each voxel. - - - TODO - - - - + + + + Optional step during which the subsequent segmentation step is prepared to + improve the segmentation. + + + + + + + + + + + + Element identifier stored sorted in descending order of feature importance. + + + + + + + Axis caption + + + + + + Element relative feature importance stored sorted in descending order of feature + importance. + + + + + + + Axis caption + + + + - Segmentation is the second step of the algorithmic chain that the - CompositionSpace tool implements. In this step a machine learning model - is used to identify how voxels cluster in composition space to identify - which chemically disjoint phases exists in the atom probe dataset. + Step during which the voxel set is segmented into voxel sets with different + chemical composition. - PCA in the parameter space of iontypes/phases of different chemical nature. + PCA in the chemical space (essentially composition correlation analyses). + - + + - TODO + Explained variance values @@ -276,7 +251,7 @@ if one coordinate system is defined the origin is defined in this cs--> - TODO + Elements as the principal component analysis @@ -291,77 +266,110 @@ if one coordinate system is defined the origin is defined in this cs--> + - + - TODO + Results of the Gaussian mixture analysis for n_components equal to n_ic_cluster. - TODO + n_components argument of the Gaussian mixture model. - TODO + y_pred return values of the computation. + + + Information criterion as a function of number of n_ic_cluster aka dimensions. + + + + + + + Akaike information criterion values + + + + + + + + Bayes information criterion values + + + + + + + + Actual n_ic_cluster values used + + + + + + - Clustering is the third step of the algorithmic chain that the CompositionSpace - tool implements. In this step the different voxelized regions in the dataset with - eventually different chemical nature are analyzed if they are distributed in - connected groups of voxels with the same chemical nature. - Using the discretization grid from the first step as the support, this enables - to prepare for the fourth step. In the fourth step the interfaces between - identified groups of different chemical nature are triangulated. - - These triangulated network of interfaces between regions of different chemical - nature is the final data structure that the CompositionSpace tool yields. - Subsequently, this mesh can be post-processed, similarly like meshes that are - obtained from isosurface-based approaches, to perform line profile analyses. + Step during which the chemically segmented voxel sets are analyzed for their + spatial organization. - + + - - - - TODO - - - - - TODO - - - - - TODO total number of (phases) distinguished. - - - - - TODO raw labels output of the DBScan clustering algorithm. Length of array varies depending on how - many voxels of the grid were identified of the targetted - phase/chemical nature. - - - - - + + + Respective DBScan clustering result for each segmentation/ic_opt case. + + + + + + The maximum distance between voxel pairs in a neighborhood to be considered + connected. + + + + + The number of voxels in a neighborhood for a voxel to be considered as a core + point. + + + + + Raw labels return values + + + + + + + + Identified DBScan cluster identifier for each voxel. + + + + + + + - diff --git a/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml b/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml index dfd53baeba..21cc2c6c6d 100644 --- a/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml +++ b/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml @@ -1,6 +1,8 @@ category: application doc: | - Application definition for a configuration file of CompositionSpace tool. + Application definition for a configuration of the CompositionSpace tool used in atom probe. + + * `A. Saxena et al. `_ This is a draft application definition for the common NFDI-MatWerk/FAIRmat infrastructure use case IUC09 that explores how to improve the organization and results storage of the @@ -49,9 +51,9 @@ NXapm_compositionspace_config(NXobject): Name of the (parent) node directly below which the ranging definitions for (molecular) ions are stored. voxelization(NXprocess): doc: | - Step during which the point cloud is discretized using a rectangular transfer function to compute - scalar element-specific composition fields. During processing, iontypes are atomically decomposed - to correctly account for the multiplicity of each element contributed by each ion. + Step during which the point cloud is discretized to compute element-specific composition fields. + Iontypes are atomically decomposed to correctly account for the multiplicity of each element that + was ranged for each ion. edge_length(NX_NUMBER): doc: | Edge length of cubic voxels for 3D grid that is used for discretizing the point cloud. diff --git a/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml b/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml index 4212aff41b..3b5e492245 100644 --- a/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml +++ b/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml @@ -1,19 +1,21 @@ category: application doc: | - Results of a run with Alaukik Saxena's composition space tool. + Application definition for results of the CompositionSpace tool used in atom probe. - This is an initial draft application definition for the common NFDI-MatWerk, - FAIRmat infrastructure use case IUC09 how to improve the organization and - results storage of the composition space tool and make these data at the - same time directly understandable for research data management systems - like NOMAD Oasis. + * `A. Saxena et al. `_ + + This is a draft application definition for the common NFDI-MatWerk/FAIRmat infrastructure + use case IUC09 that explores how to improve the organization and results storage of the + CompositionSpace tool. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. d: | The dimensionality of the grid. c: | - The cardinality or total number of cells/grid points. + Total number of voxels. + n_ions: | + Total number of ions in the reconstructed dataset. type: group NXapm_compositionspace_results(NXobject): # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently @@ -28,31 +30,15 @@ NXapm_compositionspace_results(NXobject): exists: [min, 1, max, 1] program(NX_CHAR): \@version(NX_CHAR): - job_pyiron_identifier(NX_CHAR): - exists: recommended - doc: | - TBD, maybe how to link between pyiron state tracking and app state tracking. - description(NX_CHAR): + \@url(NX_CHAR): + (NXidentifier): exists: optional - doc: | - Disencouraged place for free-text for e.g. comments. - start_time(NX_DATE_TIME): + analysis_identifier(NX_UINT): exists: recommended - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. when composition space tool was started as a process. - end_time(NX_DATE_TIME): - exists: recommended - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and composition space tool exited as a process. # config config(NXserialized): doc: | - The path and name of the config file that was used for this analysis. - TBD, this can be e.g. Alaukik's YAML file for composition space. + Configuration file that was used in this analysis. type(NX_CHAR): path(NX_CHAR): algorithm(NX_CHAR): @@ -60,207 +46,189 @@ NXapm_compositionspace_results(NXobject): # results (NXuser): exists: optional - coordinate_system_set(NXcoordinate_system_set): - exists: [min, 1, max, 1] - doc: | - Details about coordinate systems (reference frames) used. In atom probe several coordinate - systems have to be distinguished. Names of instances of such :ref:`NXcoordinate_system` - should be documented explicitly and doing so by picking from the - following controlled set of names: - - * composition_space - * lab - * specimen - * laser - * instrument - * detector - * recon - - The aim of this convention is to support users with contextualizing which reference - frame each instance (coordinate system) is. If needed, instances of :ref:`NXtransformations` - are used to detail the explicit affine transformations whereby one can convert - representations between different reference frames. - Inspect :ref:`NXtransformations` for further details. - compositionspace(NXcoordinate_system): - type(NX_CHAR): - handedness(NX_CHAR): - x(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) - y(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) - z(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) voxelization(NXprocess): + exists: [min, 1, max, 1] doc: | - Voxelization is the first step of the algorithmic chain that the - CompositionSpace tool implements. In this step all ion positions are - discretized using a rectangular transfer function to identify the number - of ions/atoms in the dataset of each iontype. + Step during which the point cloud is discretized to compute element-specific composition fields. + Iontypes are atomically decomposed to correctly account for the multiplicity of each element that + was ranged for each ion. - Using a discretization grid that is larger than the average distance - between reconstructed ion position reduces the computational costs. - This is the key idea of the CompositionSpace tool over other methods - traditionally used in atom probe (e.g. isosurfaces). + Using a discretization grid that is larger than the average distance between reconstructed ion positions + reduces computational costs. This is the key idea of the CompositionSpace tool compared to other + methods for characterizing microstructural features. sequence_index(NX_POSINT): enumeration: [1] - # specify the grid your using and for each ion in which cell i.e. voxel it is - # one could also have a more sophisticated data model where there is some - # fuzziness i.e. if an ML/AI model returns multiple values or a probability - # how likely an ion is in which voxel, for this - # inspect the example of the NXem_ebsd application definition - (NXcg_grid): + cg_grid(NXcg_grid): dimensionality(NX_POSINT): unit: NX_UNITLESS enumeration: [3] cardinality(NX_POSINT): unit: NX_UNITLESS - # default behaviour, if no coordinate system defined, unclear - # if one coordinate system is defined the origin is defined in this cs origin(NX_NUMBER): unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, d]] + dim: (d,) symmetry: enumeration: [cubic] cell_dimensions(NX_NUMBER): unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, d]] + dim: (d,) extent(NX_POSINT): unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, d]] - (NXtransformations): - exists: recommended - doc: | - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. + dim: (d,) identifier_offset(NX_INT): unit: NX_UNITLESS - doc: | - position(NX_NUMBER): - unit: NX_LENGTH doc: | Position of each cell in Euclidean space. - dimensions: - rank: 2 - dim: [[1, c], [2, d]] + unit: NX_LENGTH + dim: (c, d) coordinate(NX_INT): - exists: optional + doc: | + Discrete coordinate of each voxel. unit: NX_DIMENSIONLESS - dimensions: - rank: 2 - dim: [[1, c], [2, d]] + dim: (c, d) # bounding box if needed voxel_identifier(NX_UINT): - unit: NX_UNITLESS - doc: | - For each ion, the identifier of the voxel in which the ion is located. - dimensions: - rank: 1 - dim: [[1, n_ions]] - ionID(NXion): - exists: [min, 0, max, infty] - name(NX_CHAR): - weight(NX_FLOAT): doc: | - TODO - dim: (c,) + For each ion, the identifier of the voxel into which the ion binned. unit: NX_UNITLESS - total(NX_FLOAT): + dim: (n_ions) + weight(NX_NUMBER): doc: | - TODO - dim: (c,) + Total number of weight (counts for discretization with a rectangular transfer function) in each voxel. unit: NX_UNITLESS + dim: (c,) + elementID(NXion): + exists: [min, 1, max, infty] + name(NX_CHAR): + doc: | + Chemical symbol of the element from the periodic table. + weight(NX_NUMBER): + doc: | + Element-specific weight (counts for discretization with a rectangular transfer function) in each voxel. + unit: NX_UNITLESS + dim: (c,) + + autophase(NXprocess): + exists: [min, 1, max, 1] + doc: | + Optional step during which the subsequent segmentation step is prepared to improve the segmentation. + sequence_index(NX_POSINT): + enumeration: [2] + result(NXdata): + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME(NX_CHAR): + axis_feature_identifier(NX_UINT): + doc: | + Element identifier stored sorted in descending order of feature importance. + unit: NX_DIMENSIONLESS + dim: (i,) + \@long_name(NX_CHAR): + doc: | + Axis caption + axis_feature_importance(NX_FLOAT): + doc: | + Element relative feature importance stored sorted in descending order of feature importance. + unit: NX_DIMENSIONLESS + dim: (i,) + \@long_name(NX_CHAR): + doc: | + Axis caption segmentation(NXprocess): exists: [min, 1, max, 1] doc: | - Segmentation is the second step of the algorithmic chain that the - CompositionSpace tool implements. In this step a machine learning model - is used to identify how voxels cluster in composition space to identify - which chemically disjoint phases exists in the atom probe dataset. + Step during which the voxel set is segmented into voxel sets with different chemical composition. pca(NXprocess): doc: | - PCA in the parameter space of iontypes/phases of different chemical nature. + PCA in the chemical space (essentially composition correlation analyses). sequence_index(NX_POSINT): - enumeration: [2] - results(NXdata): + enumeration: [2, 3] + result(NXdata): \@signal(NX_CHAR): \@axes(NX_CHAR): \@AXISNAME(NX_CHAR): + # title(NX_CHAR) inherited from NXdata axis_explained_variance(NX_FLOAT): doc: | - TODO + Explained variance values unit: NX_DIMENSIONLESS dim: (i,) axis_pca_dimension(NX_UINT): doc: | - TODO + Elements as the principal component analysis unit: NX_UNITLESS dim: (i,) ic_opt(NXprocess): doc: | Information criterion minimization. sequence_index(NX_POSINT): - enumeration: [3] - cluster_analysisID(NXobject): + enumeration: [3, 4] + cluster_analysisID(NXprocess): doc: | - TODO + Results of the Gaussian mixture analysis for n_components equal to n_ic_cluster. n_ic_cluster(NX_UINT): doc: | - TODO + n_components argument of the Gaussian mixture model. unit: NX_UNITLESS y_pred(NX_UINT): doc: | - TODO + y_pred return values of the computation. unit: NX_UNITLESS dim: (c,) + result(NXdata): + doc: | + Information criterion as a function of number of n_ic_cluster aka dimensions. + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME(NX_CHAR): + axis_aic(NX_FLOAT): + doc: | + Akaike information criterion values + unit: NX_ANY + dim: (i,) + axis_bic(NX_FLOAT): + doc: | + Bayes information criterion values + unit: NX_UNITLESS + dim: (i,) + axis_dimension(NX_UINT): + doc: | + Actual n_ic_cluster values used + unit: NX_UNITLESS + dim: (i,) clustering(NXprocess): exists: [min, 1, max, 1] doc: | - Clustering is the third step of the algorithmic chain that the CompositionSpace - tool implements. In this step the different voxelized regions in the dataset with - eventually different chemical nature are analyzed if they are distributed in - connected groups of voxels with the same chemical nature. - Using the discretization grid from the first step as the support, this enables - to prepare for the fourth step. In the fourth step the interfaces between - identified groups of different chemical nature are triangulated. - - These triangulated network of interfaces between regions of different chemical - nature is the final data structure that the CompositionSpace tool yields. - Subsequently, this mesh can be post-processed, similarly like meshes that are - obtained from isosurface-based approaches, to perform line profile analyses. + Step during which the chemically segmented voxel sets are analyzed for their spatial organization. sequence_index(NX_POSINT): - enumeration: [3] - cluster_analysisID(NXobject): - exists: [min, 0, max, infty] - epsilon(NX_FLOAT): - doc: | - TODO - unit: NX_LENGTH - min_samples(NX_UINT): - doc: | - TODO - unit: NX_UNITLESS - target(NX_UINT): - doc: | - TODO total number of (phases) distinguished. - unit: NX_UNITLESS - labels(NX_UINT): - doc: | - TODO raw labels output of the DBScan clustering algorithm. Length of array varies depending on how - many voxels of the grid were identified of the targetted - phase/chemical nature. - dim: (k,) - unit: NX_UNITLESS - # the section above needs refactoring by MatWerk colleagues + enumeration: [4, 5] + ic_opt(NXobject): + doc: | + Respective DBScan clustering result for each segmentation/ic_opt case. + exists: recommended + cluster_analysisID(NXprocess): + exists: [min, 0, max, infty] + dbscanID(NXprocess): + exists: [min, 1, max, infty] # max as many as n_ic_cluster + epsilon(NX_FLOAT): + doc: | + The maximum distance between voxel pairs in a neighborhood to be considered connected. + unit: NX_LENGTH + min_samples(NX_UINT): + doc: | + The number of voxels in a neighborhood for a voxel to be considered as a core point. + unit: NX_UNITLESS + label(NX_INT): + doc: | + Raw labels return values + unit: NX_UNITLESS + dim: (k,) + voxel(NX_UINT): + doc: | + Identified DBScan cluster identifier for each voxel. + unit: NX_UNITLESS + dim: (c,) profiling(NXcs_profiling): exists: optional current_working_directory(NX_CHAR): From 6fe7594b8214b143b55da20e8ec4f1c6b53c7fbd Mon Sep 17 00:00:00 2001 From: Ron Hildebrandt Date: Mon, 1 Jul 2024 12:43:30 +0200 Subject: [PATCH 0748/1012] Response to review comment --- contributed_definitions/nyaml/NXoptical_spectroscopy.yaml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml b/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml index ee534e8289..a59640c172 100644 --- a/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml +++ b/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml @@ -229,7 +229,7 @@ NXoptical_spectroscopy(NXobject): Angle of the linear polarized light, with respect to a fixed arbitrary defined 0° position. This can be used if no definition of respective cooridnate systems for beam and sample normal is done. If coordinate systems - are + are defined, refer to beam "incident_polarization". unit: NX_ANGLE detector_TYPE(NXdetector): exists: [min, 1, max, infty] @@ -287,7 +287,7 @@ NXoptical_spectroscopy(NXobject): additional_detector_hardware: exists: optional doc: | - Specify respective hardware which was used to for the detector. For + Specify respective hardware which was used for the detector. For example special electronics required for time-correlated single photon counting (TCSPC). device_information(NXfabrication): @@ -442,7 +442,7 @@ NXoptical_spectroscopy(NXobject): polar(NX_NUMBER): unit: NX_ANGLE doc: | - R + Rotation about the y axis (polar rotation within the sample plane). \@transformation_type: enumeration: [rotation] \@vector: From 0052a999d322206c959ca7d9e49ff004acb62692 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 1 Jul 2024 15:28:19 +0200 Subject: [PATCH 0749/1012] add wavelength dispersion --- base_classes/NXmonochromator.nxdl.xml | 9 +++++++-- base_classes/nyaml/NXmonochromator.yaml | 19 ++++++++++++++----- 2 files changed, 21 insertions(+), 7 deletions(-) diff --git a/base_classes/NXmonochromator.nxdl.xml b/base_classes/NXmonochromator.nxdl.xml index 7c01c58cca..e52cc3c3cd 100644 --- a/base_classes/NXmonochromator.nxdl.xml +++ b/base_classes/NXmonochromator.nxdl.xml @@ -65,9 +65,14 @@ energy standard deviation - + - Energy dispersion at the exit slit, given as eV/mm. + Energy dispersion at the exit slit, typically given as eV/mm. + + + + + Wavelength dispersion at the exit slit. diff --git a/base_classes/nyaml/NXmonochromator.yaml b/base_classes/nyaml/NXmonochromator.yaml index f312d2b70e..6c90145d9d 100644 --- a/base_classes/nyaml/NXmonochromator.yaml +++ b/base_classes/nyaml/NXmonochromator.yaml @@ -41,10 +41,14 @@ NXmonochromator(NXobject): unit: NX_ENERGY doc: | energy standard deviation - dispersion(NX_FLOAT): + energy_dispersion(NX_FLOAT): unit: NX_ANY doc: | - Energy dispersion at the exit slit, given as eV/mm. + Energy dispersion at the exit slit, typically given as eV/mm. + wavelength_dispersion(NX_FLOAT): + unit: NX_ANY + doc: | + Wavelength dispersion at the exit slit. (NXdata)distribution: (NXgeometry)geometry: deprecated: | @@ -90,7 +94,7 @@ NXmonochromator(NXobject): other component groups. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 419e9fa82e46acb5e3bd84e38d276bc4f374c0144a4c995ecec779751d0fbd6d +# fe6c6a017740aea1c711cae70ed8054cf1bc7e3c97aed9c075202cc7c77921db # # # +# +# +# Base class to detail a coordinate system (CS). +# +# Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as +# a member in an :ref:`NXcoordinate_system_set` and the name of the instance +# should be this alias. This may support a process whereby jargon when talking +# about coordinate systems and conventions may become cleaner for users +# because it is not evident for people outside a lab that terms like e.g. +# tip space or specimen space refer to the same coordinate system. +# This is an example of jargon used in e.g. the field of atom +# probe tomography. +# +# +# +# Human-readable field telling where the origin of this CS is. +# Exemplar values could be *left corner of the lab bench*, *door-handle* +# *pinhole through which the electron beam exists the pole piece*. +# *barycenter of the triangle*, *center of mass of the stone*. +# +# +# +# +# +# An alternative name given to that coordinate system. +# +# +# +# +# Coordinate system type. +# +# +# +# +# +# +# +# Handedness of the coordinate system if it is a Cartesian. +# +# +# +# +# +# +# +# +# Possibility to define an alias for the name of the x-axis. +# +# +# +# +# Human-readable field telling in which direction the x-axis points if that +# instance of :ref:`NXcoordinate_system` has no reference to any parent and as such +# is the mighty world reference frame. +# +# Exemplar values could be direction of gravity. +# +# +# +# +# Base unit vector along the first axis which spans the coordinate system. +# This axis is frequently referred to as the x-axis in real space and +# the i-axis in reciprocal space. +# +# +# +# +# +# +# +# Possibility to define an alias for the name of the y-axis. +# +# +# +# +# Human-readable field telling in which direction the y-axis points if that +# instance of :ref:`NXcoordinate_system` has no reference to any parent and as such +# is the mighty world reference frame. +# +# See docstring of x_alias for further details. +# +# +# +# +# Base unit vector along the second axis which spans the coordinate system. +# This axis is frequently referred to as the y-axis in real space and +# the j-axis in reciprocal space. +# +# +# +# +# +# +# +# Possibility to define an alias for the name of the z-axis. +# +# +# +# +# Human-readable field telling in which direction the z-axis points if that +# instance of :ref:`NXcoordinate_system` has no reference to any parent and as such +# is the mighty world reference frame. +# +# See docstring of x_alias for further details. +# +# +# +# +# Base unit vector along the third axis which spans the coordinate system. +# This axis is frequently referred to as the z-axis in real space and +# the k-axis in reciprocal space. +# +# +# +# +# +# +# +# Translational shift during a passive transformation from the coordinate system +# defined in the the `depends_on` attribute. +# +# +# +# +# This defines which coordinate system the base transformation defined by the +# `x`, `y`, and `z` fields refers to. +# By default, it is (.) and points to the McStas coordinate system. +# +# +# From e41fd3c74fdb2173e359106e884fd376ae379103 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 1 Jul 2024 15:09:49 +0200 Subject: [PATCH 0754/1012] readd NXtransformations to NXcoordinate_system --- .../NXcoordinate_system.nxdl.xml | 15 +- .../NXcoordinate_system_set.nxdl.xml | 24 +-- .../nyaml/NXcoordinate_system.yaml | 31 ++-- .../nyaml/NXcoordinate_system_set.yaml | 155 ++++++++++++++++-- 4 files changed, 175 insertions(+), 50 deletions(-) diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 8376a54071..a514fc4b70 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -140,17 +140,16 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d - + - Translational shift during a passive transformation from the coordinate system - defined in the the `depends_on` attribute. + This specificies the relation to another coordinate system by pointing to the last + transformation in the transformation chain in the NXtransformations group. - + - This defines which coordinate system the base transformation defined by the - `x`, `y`, and `z` fields refers to. - By default, it is (.) and points to the McStas coordinate system. + Collection of axis-based translations and rotations to describe this coordinate system + with respect to another coordinate system. - + diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/contributed_definitions/NXcoordinate_system_set.nxdl.xml index 11b22f28fa..280fd83902 100644 --- a/contributed_definitions/NXcoordinate_system_set.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system_set.nxdl.xml @@ -25,10 +25,10 @@ Base class to hold different coordinate systems and representation conversions. - How many nodes of type :ref:`NXcoordinate_system_set` should be used in an appdef? + How many nodes of type :ref:`NXcoordinate_system_set` should be used in an application definition? - * 0; if no instance of :ref:`NXcoordinate_system_set` and therein or elsewhere across - the appdef an instance of NXcoordinate_system is defined, + * 0; if there is no instance of :ref:`NXcoordinate_system_set` and therein or elsewhere across + the application definition, an instance of NXcoordinate_system is defined, the default NeXus `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system is assumed. This makes :ref:`NXcoordinate_system_set` and NXcoordinate_system base classes backwards compatible to older @@ -36,13 +36,12 @@ * 1; if only one :ref:`NXcoordinate_system_set` is defined, it should be placed as high up in the node hierarchy (ideally right below an instance of NXentry) of the application definition tree as possible. - This :ref:`NXcoordinate_system_set` should at least define one NXcoordinate_system - instance which should be called mcstas for the sake of improved clarity. - Alternatively, at least one NXcoordinate_system member of the set should be - defined and named such that it is clear how this coordinate system is - typically referred to in a community. Additional NXcoordinate_system instances - should be specified if possible in that same :ref:`NXcoordinate_system_set` instead - of cluttering them across the tree. + This :ref:`NXcoordinate_system_set` should define at least one NXcoordinate_system + instance. This shall be named such that it is clear how this coordinate system is + typically referred to in a community. For the NeXus `McStas coordinate system, it is + adviused to call it mcstas for the sake of improved clarity. + Additional NXcoordinate_system instances should be specified if possible in that same + :ref:`NXcoordinate_system_set` instead of cluttering them across the tree. If this is the case, it is assumed that the NXcoordinate_system_members overwrite the NeXus default McStas coordinate system, i.e. users can thereby @@ -102,7 +101,10 @@ specifying of the coordinate system used in every case is that especially in combination with having coordinate systems inside deeper branches makes up for a very versatile, backwards compatible, but powerful system - to express different types of coordinate systems using NeXus. + to express different types of coordinate systems using NeXus. In the case + of two or more instances of NXcoordinate_system in one :ref:`NXcoordinate_system_set`, + it is also advised to specify the relationship between the two coordinate systems by + using the (NXtransformations) group within NXcoordinate_system. In effect, 1 should be the preferred choice. However, if more than one coordinate system is defined for practical purposes, explicit depends_on fields should diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml index f73c68824d..f0c60573ab 100644 --- a/contributed_definitions/nyaml/NXcoordinate_system.yaml +++ b/contributed_definitions/nyaml/NXcoordinate_system.yaml @@ -91,19 +91,17 @@ NXcoordinate_system(NXobject): dimensions: rank: 1 dim: [[1, 3]] - offset(NX_NUMBER): + depends_on(NX_CHAR): doc: | - Translational shift during a passive transformation from the coordinate system - defined in the the `depends_on` attribute. - \@depends_on: - type: NX_CHAR + This specificies the relation to another coordinate system by pointing to the last + transformation in the transformation chain in the NXtransformations group. + (NXtransformations): doc: | - This defines which coordinate system the base transformation defined by the - `x`, `y`, and `z` fields refers to. - By default, it is (.) and points to the McStas coordinate system. + Collection of axis-based translations and rotations to describe this coordinate system + with respect to another coordinate system. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8f206af983210d7f46437cc8940974e32cc2966d997126c290089ef355f6fb59 +# 76304029bbb3a1882d9855d8b170be0cfb2a18eebd5f0b60c752ae35c441f906 # # # +# +# +# Base class to hold different coordinate systems and representation conversions. +# +# How many nodes of type :ref:`NXcoordinate_system_set` should be used in an application definition? +# +# * 0; if there is no instance of :ref:`NXcoordinate_system_set` and therein or elsewhere across +# the application definition, an instance of NXcoordinate_system is defined, +# the default NeXus `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ +# coordinate system is assumed. This makes :ref:`NXcoordinate_system_set` and +# NXcoordinate_system base classes backwards compatible to older +# NeXus conventions and classes. +# * 1; if only one :ref:`NXcoordinate_system_set` is defined, it should be placed +# as high up in the node hierarchy (ideally right below an instance of NXentry) +# of the application definition tree as possible. +# This :ref:`NXcoordinate_system_set` should define at least one NXcoordinate_system +# instance. This shall be named such that it is clear how this coordinate system is +# typically referred to in a community. For the NeXus `McStas coordinate system, it is +# adviused to call it mcstas for the sake of improved clarity. +# Additional NXcoordinate_system instances should be specified if possible in that same +# :ref:`NXcoordinate_system_set` instead of cluttering them across the tree. +# +# If this is the case, it is assumed that the NXcoordinate_system_members +# overwrite the NeXus default McStas coordinate system, i.e. users can thereby +# conveniently and explicitly specify the coordinate system(s) that +# they wish to use. +# +# Users are encouraged to write also explicit and clean depends_on fields in +# all groups that encode information about where the interpretation of coordinate +# systems is relevant. If these depends_on hints are not provided, it is +# automatically assumed that all children (to arbitrary depth) +# of that branch and sub-branches below the one in which that +# :ref:`NXcoordinate_system_set` is defined use either the only NXcoordinate_system_set +# instance in that set or the application definition is considered +# underconstrained which should at all costs be avoided and in which case +# again McStas is assumed. +# * 2 and more; as soon as more than one :ref:`NXcoordinate_system_set` is specified +# somewhere in the tree, different interpretations are possible as to which +# of these coordinate system sets and instances apply or take preference. +# We realize that such ambiguities should at all costs be avoided. +# However, the opportunity for multiple sets and their instances enables to +# have branch-specific coordinate system conventions which could especially +# be useful for deep classes where multiple scientific methods are combined or +# cases where having a definition of global translation and conversion tables +# how to convert between representations in different coordinate systems +# is not desired or available for now. +# We argue that having 2 or more :ref:`NXcoordinate_system_set` instances and respective +# NXcoordinate_system instances makes the interpretation eventually unnecessary +# complicated. Instead, developers of application definitions should always try +# to work for clarity and thus use only one top-level coordinate system set. +# +# For these reasons we conclude that the option with one top-level +# :ref:`NXcoordinate_system_set` instance is the preferred choice. +# +# McStas is used if neither an instance of :ref:`NXcoordinate_system_set` nor an instance +# of NXcoordinate_system is specified. However, even in this case it is better +# to be explicit like for every other coordinate system definition to support +# users with interpreting the content and logic behind every instance of the tree. +# +# How to store coordinate systems inside :ref:`NXcoordinate_system_set`? +# Individual coordinate systems should be specified as members of the +# :ref:`NXcoordinate_system_set` instance using instances of NXcoordinate_system. +# +# How many individual instances of NXcoordinate_system to allow within one +# instance of :ref:`NXcoordinate_system_set`? +# +# * 0; This case should be avoided for the sake of clarity but this case could +# mean the authors of the definition meant that McStas is used. We conclude, +# McStas is used in this case. +# * 1; Like above-mentioned this case has the advantage that it is explicit +# and faces no ambiguities. However, in reality typically multiple +# coordinate systems have to be mastered especially for complex +# multi-signal modality experiments. +# * 2 or more; If this case is realized, the best practice is that in every +# case where a coordinate system should be referred to the respective class +# has a depends_on field which resolves the possible ambiguities which specific +# coordinate systems is referred to. The benefit of this explicit and clear +# specifying of the coordinate system used in every case is that especially +# in combination with having coordinate systems inside deeper branches +# makes up for a very versatile, backwards compatible, but powerful system +# to express different types of coordinate systems using NeXus. In the case +# of two or more instances of NXcoordinate_system in one :ref:`NXcoordinate_system_set`, +# it is also advised to specify the relationship between the two coordinate systems by +# using the (NXtransformations) group within NXcoordinate_system. +# +# In effect, 1 should be the preferred choice. However, if more than one coordinate +# system is defined for practical purposes, explicit depends_on fields should +# always guide the user for each group and field which of the coordinate system +# one refers to. +# +# +# +# From 1e4929e08fe25f3f2630749b99efc6b9871cca73 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 1 Jul 2024 15:11:32 +0200 Subject: [PATCH 0755/1012] typo fix --- contributed_definitions/NXcoordinate_system_set.nxdl.xml | 4 ++-- .../nyaml/NXcoordinate_system_set.yaml | 8 ++++---- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/contributed_definitions/NXcoordinate_system_set.nxdl.xml index 280fd83902..ba943e667e 100644 --- a/contributed_definitions/NXcoordinate_system_set.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system_set.nxdl.xml @@ -39,7 +39,7 @@ This :ref:`NXcoordinate_system_set` should define at least one NXcoordinate_system instance. This shall be named such that it is clear how this coordinate system is typically referred to in a community. For the NeXus `McStas coordinate system, it is - adviused to call it mcstas for the sake of improved clarity. + advised to call it mcstas for the sake of improved clarity. Additional NXcoordinate_system instances should be specified if possible in that same :ref:`NXcoordinate_system_set` instead of cluttering them across the tree. @@ -118,5 +118,5 @@ Depends on cardinality of NXcoordinate_system_set, i.e. how many NXcoordinate_sy - 0, the root of an NXtransformation chain i.e. "." means McStas - 1, the root of an NXtransformation chain i.e. "." means "that specific CS" i.e. the one defined by the single instance of NXcoordinate_system in the set - > 1, "." becomes ambiguous. My suggestion, spell out the name of the specific NXcoordinate_system instance to be used, using "." - despite all these, a warning should be raised, like a logic warning (and McStas kick in) or an error (i.e. be forbidden) be raised--> +despite all these, a warning should be raised, like a logic warning (and McStas kick in) or an error (i.e. be forbidden) be raised--> diff --git a/contributed_definitions/nyaml/NXcoordinate_system_set.yaml b/contributed_definitions/nyaml/NXcoordinate_system_set.yaml index dc442b4c19..ab166bc193 100644 --- a/contributed_definitions/nyaml/NXcoordinate_system_set.yaml +++ b/contributed_definitions/nyaml/NXcoordinate_system_set.yaml @@ -16,7 +16,7 @@ doc: | This :ref:`NXcoordinate_system_set` should define at least one NXcoordinate_system instance. This shall be named such that it is clear how this coordinate system is typically referred to in a community. For the NeXus `McStas coordinate system, it is - adviused to call it mcstas for the sake of improved clarity. + advised to call it mcstas for the sake of improved clarity. Additional NXcoordinate_system instances should be specified if possible in that same :ref:`NXcoordinate_system_set` instead of cluttering them across the tree. @@ -100,7 +100,7 @@ NXcoordinate_system_set(NXobject): # despite all these, a warning should be raised, like a logic warning (and McStas kick in) or an error (i.e. be forbidden) be raised # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 19dcdaa81b00c7163aed10d5e3a9fd6393f681c1df3bf0b79af8db1e9f8e746e +# 2c012af7dc8e09a7f7df9408a0d04886f58bc74feff6fc207658954ad8682422 # # # +# despite all these, a warning should be raised, like a logic warning (and McStas kick in) or an error (i.e. be forbidden) be raised--> # From 99f552227d7439e15f882d586bbeed592add5502 Mon Sep 17 00:00:00 2001 From: Ron Hildebrandt Date: Tue, 2 Jul 2024 08:53:48 +0200 Subject: [PATCH 0756/1012] add missing nxdl --- contributed_definitions/NXoptical_spectroscopy.nxdl.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/NXoptical_spectroscopy.nxdl.xml b/contributed_definitions/NXoptical_spectroscopy.nxdl.xml index 4fedcab033..4f27940cc4 100644 --- a/contributed_definitions/NXoptical_spectroscopy.nxdl.xml +++ b/contributed_definitions/NXoptical_spectroscopy.nxdl.xml @@ -301,7 +301,7 @@ TODO: Angle of the linear polarized light, with respect to a fixed arbitrary defined 0° position. This can be used if no definition of respective cooridnate systems for beam and sample normal is done. If coordinate systems - are + are defined, refer to beam "incident_polarization". @@ -381,7 +381,7 @@ TODO: - Specify respective hardware which was used to for the detector. For + Specify respective hardware which was used for the detector. For example special electronics required for time-correlated single photon counting (TCSPC). @@ -553,7 +553,7 @@ TODO: - R + Rotation about the y axis (polar rotation within the sample plane). From 7e827d65045c5acc51ae1a879b6e9e65915b6379 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 2 Jul 2024 20:31:08 +0200 Subject: [PATCH 0757/1012] Cleaned obsolete and circuit contributed base classes which are not meaty enough --- contributed_definitions/NXadc.nxdl.xml | 38 ----------- .../NXcircuit_board.nxdl.xml | 45 ------------- contributed_definitions/NXdac.nxdl.xml | 38 ----------- contributed_definitions/nyaml/NXadc.yaml | 53 --------------- .../nyaml/NXcircuit_board.yaml | 67 ------------------- .../nyaml/NXcs_gpu_obj.yaml | 2 +- contributed_definitions/nyaml/NXdac.yaml | 53 --------------- .../contributed_definitions/em-structure.rst | 4 +- 8 files changed, 3 insertions(+), 297 deletions(-) delete mode 100644 contributed_definitions/NXadc.nxdl.xml delete mode 100644 contributed_definitions/NXcircuit_board.nxdl.xml delete mode 100644 contributed_definitions/NXdac.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXadc.yaml delete mode 100644 contributed_definitions/nyaml/NXcircuit_board.yaml delete mode 100644 contributed_definitions/nyaml/NXdac.yaml diff --git a/contributed_definitions/NXadc.nxdl.xml b/contributed_definitions/NXadc.nxdl.xml deleted file mode 100644 index 498c27dbaf..0000000000 --- a/contributed_definitions/NXadc.nxdl.xml +++ /dev/null @@ -1,38 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Analog-to-digital converter component/integrated circuit. - - - - TBD. - - - diff --git a/contributed_definitions/NXcircuit_board.nxdl.xml b/contributed_definitions/NXcircuit_board.nxdl.xml deleted file mode 100644 index 9610f8f43f..0000000000 --- a/contributed_definitions/NXcircuit_board.nxdl.xml +++ /dev/null @@ -1,45 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Circuit board with e.g. ADC and/or DAC electronic components. - - Currently used to store the settings of the so-called magboards used in - Nion electron microscopes but likely this could be a useful base class for - substantially more use cases where details at a deep technical instrument design - level are relevant or important. - - - - TBD by Nion Co. - - - - - diff --git a/contributed_definitions/NXdac.nxdl.xml b/contributed_definitions/NXdac.nxdl.xml deleted file mode 100644 index b73dc7abee..0000000000 --- a/contributed_definitions/NXdac.nxdl.xml +++ /dev/null @@ -1,38 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Digital-to-analog converter component/integrated circuit. - - - - TBD. - - - diff --git a/contributed_definitions/nyaml/NXadc.yaml b/contributed_definitions/nyaml/NXadc.yaml deleted file mode 100644 index d86bd8d566..0000000000 --- a/contributed_definitions/nyaml/NXadc.yaml +++ /dev/null @@ -1,53 +0,0 @@ -category: base -doc: | - Analog-to-digital converter component/integrated circuit. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXadc(NXobject): - value(NX_NUMBER): - unit: NX_UNITLESS - doc: | - TBD. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4804d0b6bf4c31429d0e602b482093871010cb40a4e62da03804396faa54d158 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Analog-to-digital converter component/integrated circuit. -# -# -# -# TBD. -# -# -# diff --git a/contributed_definitions/nyaml/NXcircuit_board.yaml b/contributed_definitions/nyaml/NXcircuit_board.yaml deleted file mode 100644 index c3c3d044e7..0000000000 --- a/contributed_definitions/nyaml/NXcircuit_board.yaml +++ /dev/null @@ -1,67 +0,0 @@ -category: base -doc: | - Circuit board with e.g. ADC and/or DAC electronic components. - - Currently used to store the settings of the so-called magboards used in - Nion electron microscopes but likely this could be a useful base class for - substantially more use cases where details at a deep technical instrument design - level are relevant or important. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXcircuit_board(NXobject): - relay(NX_NUMBER): - unit: NX_UNITLESS - doc: | - TBD by Nion Co. - (NXdac): - (NXadc): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# b720e7a4089ff6b669d026c44b1d610485fe501d8ebc34ca5f367e65bf99066a -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Circuit board with e.g. ADC and/or DAC electronic components. -# -# Currently used to store the settings of the so-called magboards used in -# Nion electron microscopes but likely this could be a useful base class for -# substantially more use cases where details at a deep technical instrument design -# level are relevant or important. -# -# -# -# TBD by Nion Co. -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcs_gpu_obj.yaml b/contributed_definitions/nyaml/NXcs_gpu_obj.yaml index 04468b7b2b..0984d318cf 100644 --- a/contributed_definitions/nyaml/NXcs_gpu_obj.yaml +++ b/contributed_definitions/nyaml/NXcs_gpu_obj.yaml @@ -5,7 +5,7 @@ symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. type: group -NXcs_gpu_obj(NXobject): # NXcircuit_board ? +NXcs_gpu_obj(NXobject): name(NX_CHAR): doc: | Given name of the GPU. Users should be as specific as possible. diff --git a/contributed_definitions/nyaml/NXdac.yaml b/contributed_definitions/nyaml/NXdac.yaml deleted file mode 100644 index f0b09372b2..0000000000 --- a/contributed_definitions/nyaml/NXdac.yaml +++ /dev/null @@ -1,53 +0,0 @@ -category: base -doc: | - Digital-to-analog converter component/integrated circuit. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXdac(NXobject): - value(NX_NUMBER): - unit: NX_UNITLESS - doc: | - TBD. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 3126ae3b0a957ca0a5ab3d91942ccee0c849665d53ec3cf085dee4f2fc420899 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Digital-to-analog converter component/integrated circuit. -# -# -# -# TBD. -# -# -# diff --git a/manual/source/classes/contributed_definitions/em-structure.rst b/manual/source/classes/contributed_definitions/em-structure.rst index 86647eccd9..02005fe9ce 100644 --- a/manual/source/classes/contributed_definitions/em-structure.rst +++ b/manual/source/classes/contributed_definitions/em-structure.rst @@ -130,8 +130,8 @@ The following base classes are proposed to support modularizing the storage of p is a component in a microscope which controls eventually multiple other components such as beam deflectors to achieve deflection and thus a controlled scanning of the beam over the sample/specimen surface. - :ref:`NXcircuit`, :ref:`NXcircuit_board`, :ref:`NXadc`, :ref: `NXdac`: - Base classes to describe integrated circuits (ICs). Further consolidation of these base classes is planned. + :ref:`NXcircuit`: + Base class to describe logical unit of at least one integrated circuit. :ref:`NXspectrum_set`: A base class and specializations comparable to :ref:`NXimage_set` but for storing spectra. From 149a51ae085499a2f271f0bc1134f6dfa9b3fd4b Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 2 Jul 2024 22:15:17 +0200 Subject: [PATCH 0758/1012] Implemented suggestion to have technical components of a computer inherit from the NXcircuit base class --- contributed_definitions/NXcs_cpu_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_gpu_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_io_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 2 +- contributed_definitions/nyaml/NXcs_cpu_obj.yaml | 2 +- contributed_definitions/nyaml/NXcs_gpu_obj.yaml | 2 +- contributed_definitions/nyaml/NXcs_io_obj.yaml | 2 +- contributed_definitions/nyaml/NXcs_mm_obj.yaml | 2 +- 8 files changed, 8 insertions(+), 8 deletions(-) diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml index 8a23293212..043fbeafaa 100644 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcs_gpu_obj.nxdl.xml b/contributed_definitions/NXcs_gpu_obj.nxdl.xml index 8353ca814c..d04ed9159a 100644 --- a/contributed_definitions/NXcs_gpu_obj.nxdl.xml +++ b/contributed_definitions/NXcs_gpu_obj.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml index de28eb64ca..372a84b4e5 100644 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXcs_mm_obj.nxdl.xml b/contributed_definitions/NXcs_mm_obj.nxdl.xml index 4e69e64e1d..dd4c69b4c5 100644 --- a/contributed_definitions/NXcs_mm_obj.nxdl.xml +++ b/contributed_definitions/NXcs_mm_obj.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXcs_cpu_obj.yaml b/contributed_definitions/nyaml/NXcs_cpu_obj.yaml index 73097d5ca5..dfa4c4dbdb 100644 --- a/contributed_definitions/nyaml/NXcs_cpu_obj.yaml +++ b/contributed_definitions/nyaml/NXcs_cpu_obj.yaml @@ -5,7 +5,7 @@ symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. type: group -NXcs_cpu_obj(NXobject): +NXcs_cpu_obj(NXcircuit): name(NX_CHAR): doc: | Given name of the CPU. Users should be as specific as possible. diff --git a/contributed_definitions/nyaml/NXcs_gpu_obj.yaml b/contributed_definitions/nyaml/NXcs_gpu_obj.yaml index 0984d318cf..64af7ee846 100644 --- a/contributed_definitions/nyaml/NXcs_gpu_obj.yaml +++ b/contributed_definitions/nyaml/NXcs_gpu_obj.yaml @@ -5,7 +5,7 @@ symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. type: group -NXcs_gpu_obj(NXobject): +NXcs_gpu_obj(NXcircuit): name(NX_CHAR): doc: | Given name of the GPU. Users should be as specific as possible. diff --git a/contributed_definitions/nyaml/NXcs_io_obj.yaml b/contributed_definitions/nyaml/NXcs_io_obj.yaml index 100f0cae41..24b557c3db 100644 --- a/contributed_definitions/nyaml/NXcs_io_obj.yaml +++ b/contributed_definitions/nyaml/NXcs_io_obj.yaml @@ -5,7 +5,7 @@ symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. type: group -NXcs_io_obj(NXobject): +NXcs_io_obj(NXcircuit): technology(NX_CHAR): doc: | Qualifier for the type of storage medium used. diff --git a/contributed_definitions/nyaml/NXcs_mm_obj.yaml b/contributed_definitions/nyaml/NXcs_mm_obj.yaml index d1fead8c8b..f28c2ab95f 100644 --- a/contributed_definitions/nyaml/NXcs_mm_obj.yaml +++ b/contributed_definitions/nyaml/NXcs_mm_obj.yaml @@ -5,7 +5,7 @@ symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. type: group -NXcs_mm_obj(NXobject): +NXcs_mm_obj(NXcircuit): technology(NX_CHAR): doc: | Qualifier for the type of random access memory. From 1a83e46bcc47610a9cd633333dcab597e280e788 Mon Sep 17 00:00:00 2001 From: Ron Hildebrandt Date: Wed, 3 Jul 2024 10:10:11 +0200 Subject: [PATCH 0759/1012] added Raman documentation --- .../NXoptical_spectroscopy.nxdl.xml | 8 ++- contributed_definitions/NXwaveplate.nxdl.xml | 2 +- .../nyaml/NXoptical_spectroscopy.yaml | 6 ++ .../nyaml/NXwaveplate.yaml | 1 - .../ellipsometry-structure.rst | 61 ++++++++++++------- 5 files changed, 52 insertions(+), 26 deletions(-) diff --git a/contributed_definitions/NXoptical_spectroscopy.nxdl.xml b/contributed_definitions/NXoptical_spectroscopy.nxdl.xml index 4f27940cc4..4213c2359a 100644 --- a/contributed_definitions/NXoptical_spectroscopy.nxdl.xml +++ b/contributed_definitions/NXoptical_spectroscopy.nxdl.xml @@ -31,7 +31,8 @@ TODO: - Make polfilter_TYPE(NXbeam_device) own base class -\-> rework NXpolarizer_opt. and add them to NXinstrument. - Make spectralfilter_TYPE(NXbeam_device) own base class -\-> extend NXfilter? and add them to NXinstrument. - Make offset angles for polar and azimutal? -- Can angle_reference_frame be replaced later by only using reference_frames and generic angle description?--> +- Can angle_reference_frame be replaced later by only using reference_frames and generic angle description? +- Add optical elements and rework them: NXfiber, NXbeam_splitter,--> @@ -729,6 +730,11 @@ TODO: + Allows description of beam properties via matrices, which relate ingoing with diff --git a/contributed_definitions/NXwaveplate.nxdl.xml b/contributed_definitions/NXwaveplate.nxdl.xml index 2d04aa9412..60902082ee 100644 --- a/contributed_definitions/NXwaveplate.nxdl.xml +++ b/contributed_definitions/NXwaveplate.nxdl.xml @@ -84,7 +84,7 @@ A draft of a new base class to describe a waveplate--> - + Wavelength resolved retardence of the waveplate. diff --git a/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml b/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml index a59640c172..836db39862 100644 --- a/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml +++ b/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml @@ -33,6 +33,7 @@ symbols: # - Make spectralfilter_TYPE(NXbeam_device) own base class --> extend NXfilter? and add them to NXinstrument. # - Make offset angles for polar and azimutal? # - Can angle_reference_frame be replaced later by only using reference_frames and generic angle description? +# - Add optical elements and rework them: NXfiber, NXbeam_splitter, type: group NXoptical_spectroscopy(NXobject): (NXentry): @@ -564,6 +565,11 @@ NXoptical_spectroscopy(NXobject): enumeration: [transmission, reflection] device_information(NXfabrication): exists: optional + # Later for rework of specific optical elements + #(NXbeam_splitter): + # exists: optional + # doc: | + # Can be used to describe a beam splitter as optical element. (NXbeam_transfer_matrix_table): exists: optional diff --git a/contributed_definitions/nyaml/NXwaveplate.yaml b/contributed_definitions/nyaml/NXwaveplate.yaml index 253c7dd7e5..8efdf1e3a0 100644 --- a/contributed_definitions/nyaml/NXwaveplate.yaml +++ b/contributed_definitions/nyaml/NXwaveplate.yaml @@ -41,7 +41,6 @@ NXwaveplate(NXobject): rank: 1 dim: [[1, N_wavelengths]] retardance_distribution(NXdata): - exists: optional doc: | Wavelength resolved retardence of the waveplate. diameter(NX_FLOAT): diff --git a/manual/source/classes/contributed_definitions/ellipsometry-structure.rst b/manual/source/classes/contributed_definitions/ellipsometry-structure.rst index cfe93e1f1f..f3b66a547d 100644 --- a/manual/source/classes/contributed_definitions/ellipsometry-structure.rst +++ b/manual/source/classes/contributed_definitions/ellipsometry-structure.rst @@ -6,6 +6,7 @@ Optical Spectroscopy .. index:: Ellipsometry + Raman DispersiveMaterial @@ -20,15 +21,30 @@ Interpretation is based on Fresnel equations and numerical models of the optical In the application definition we provide a minimum set of description elements allowing for a reproducible recording of ellipsometry measurements. +.. _Raman: + +Raman +############ + +Raman spectroscopy is a characterization method to analyze vibrational properties for liquids, gases or solids. +The measurements is based on the inelastic light scattering due to the materials vibrations. +Interpretation can be done based on peaks, which represent the phonon properties (intensity, center, width). + +The application provides a minimum set of description elements, which are necessary to understand for Raman spectroscopy measurements. + + Application Definitions ----------------------- :ref:`NXoptical_spectroscopy`: - A generic application definition for optial spectorscopy measurements, including complex systems up to variable angle spectroscopic ellipsometry. + A generic application definition for optial spectorscopy measurements. This including specifically ellipsometry and Raman spectroscopy measurements, but as well other techniques such as photoluminescence, transmission, reflection measurements. The requirements are: (i) an incident photon beam, (ii) a detector to measure scattered/emitted photons and (iii) a sample. :ref:`NXellipsometry`: - An application definition for ellipsometry measurements, including complex systems up to variable angle spectroscopic ellipsometry. + An application definition for ellipsometry measurements, including complex systems up to variable angle spectroscopic ellipsometry. + + :ref:`NXraman`: + An application definition for Raman spectroscopy measurements. Base Classes @@ -36,36 +52,35 @@ Base Classes There is a set of base classes for describing an optical experiment. - :ref:`NXbeam_path` - A beam path consisting of one or more optical elements. + :ref:`NXbeam_device` + Beam devices are used to relate a beam, which has always at least one origin + and at least one destination. - NXbeam_path is used in NXopt to describe the beam path, i.e. the arrangement - of optical elements between the excitation source and the sample, or between - the sample and the detector unit. - - :ref:`NXbeam_splitter` - A beam splitter, i.e. a device splitting the light into two or more beams. - - Use two or more NXbeam_paths to describe the beam paths after the beam - splitter. In the dependency chain of the new beam paths, the first elements - each point to this beam splitter, as this is the previous element. + By referencing the beam devices with each other, a beam path can be + constructed. This can be used for vizualization or beam propery modeling + along the beam path. + + :ref:`NXbeam` + Beam properties such as intensity, polarization, wavelength or direction. - :ref:`NXfiber` - An optical fiber, e.g. glass fiber. + :ref:`NXdetector` + A detector for signal detection. + + :ref:`NXsource` + A light source such as laser, lamp or LED. + + :ref:`NXmonochromator` + A monochromator is often used to energetically disperse the scattered or emitted light. :ref:`NXlens_opt` Description of an optical lens. - :ref:`NXpolarizer_opt` - A spin polarizer. - :ref:`NXwaveplate` A waveplate or retarder. - :ref:`NXenvironment` - Specify external parameters that have influenced the sample, - such as the surrounding medium, and varied parameters e.g. - temperature, pressure, pH value, optical excitation etc. + :ref:`NXsensor` + Specify external parameters that have influenced the sample such as + varied parameters e.g. temperature, pressure, pH value, beam intensity, etc. From a4a31dfaac1c153d0ba49be7ba388404d13d9eea Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Wed, 3 Jul 2024 11:05:23 +0200 Subject: [PATCH 0760/1012] Fix typo in `NXmpes_arpes` (#261) * Fixes typo in NXmpes_arpes * Fix NX_ANGLE typoe --- contributed_definitions/NXmpes_arpes.nxdl.xml | 4 ++-- contributed_definitions/nyaml/NXmpes_arpes.yaml | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/contributed_definitions/NXmpes_arpes.nxdl.xml b/contributed_definitions/NXmpes_arpes.nxdl.xml index 93748a0860..c830b7aa84 100644 --- a/contributed_definitions/NXmpes_arpes.nxdl.xml +++ b/contributed_definitions/NXmpes_arpes.nxdl.xml @@ -384,7 +384,7 @@ with higher granularity in the data description. @energy_depends: '/entry/process/calibration/energy_calibration/calibrated_axis' for a preprocessed axis. - + Trace of the energy axis. Could be linked from the respective 'AXISNAME_depends' field. @@ -396,7 +396,7 @@ with higher granularity in the data description. 'AXISNAME_depends' field. - + Trace of the second axis. Could be linked from the respective 'AXISNAME_depends' field. diff --git a/contributed_definitions/nyaml/NXmpes_arpes.yaml b/contributed_definitions/nyaml/NXmpes_arpes.yaml index 3f58d472e2..cfed920f57 100644 --- a/contributed_definitions/nyaml/NXmpes_arpes.yaml +++ b/contributed_definitions/nyaml/NXmpes_arpes.yaml @@ -226,7 +226,7 @@ NXmpes_arpes(NXmpes): @energy_depends: '/entry/instrument/energydispersion/center_kinetic_energy' for a swept scan @energy_depends: '/entry/process/calibration/energy_calibration/calibrated_axis' for a preprocessed axis. energy(NX_NUMBER): - unit: NY_ENERGY + unit: NX_ENERGY doc: | Trace of the energy axis. Could be linked from the respective 'AXISNAME_depends' field. @@ -236,7 +236,7 @@ NXmpes_arpes(NXmpes): Trace of the first angular axis. Could be linked from the respective 'AXISNAME_depends' field. angular1(NX_NUMBER): - unit: ANX_ANGLE + unit: NX_ANGLE doc: | Trace of the second axis. Could be linked from the respective 'AXISNAME_depends' field. From 1a979c8939728a86bc7ca4c28c607a1f9c0a902e Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 3 Jul 2024 11:21:45 +0200 Subject: [PATCH 0761/1012] regenerate nyaml files --- base_classes/nyaml/NXtransformations.yaml | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/base_classes/nyaml/NXtransformations.yaml b/base_classes/nyaml/NXtransformations.yaml index ea8cdbcfcb..77e94b9f1a 100644 --- a/base_classes/nyaml/NXtransformations.yaml +++ b/base_classes/nyaml/NXtransformations.yaml @@ -338,7 +338,7 @@ NXtransformations(NXobject): for a summary of the discussion. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 6a1dc796e67a81292ff555a4e73fd6d2e67769d83ddb0686e193f8f7b1ccfef0 +# 5d52fcf7efc8ead93b3d310d183e880eee52434b88d148020efff95b32119d93 # # # - - - - 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 :ref:`McSTAS coordinate frame<Design-CoordinateSystem>` - is assumed, but additional useful coordinate axes may be defined by using axes for which - no transformation type has been specified. - - **Transformation chain** - - The entry point of a chain of transformations is a field called ``depends_on`` - will be outside of this class and points 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` - which in turn depends on :math:`T_3`, the final *active* transformation - matrix :math:`T_f` is - - .. math:: T_f = T_3 . T_2 . T_1 - - For example when positioning a flat detector, its pixel positions in the laboratory - reference frame (:ref:`McSTAS coordinate frame<Design-CoordinateSystem>` by default) - can be calculated by - - .. math:: X_\text{lab} = T_f . X_\text{pixel} = T_3 . T_2 . T_1 . X_\text{pixel} - - Note that :math:`T_1` comes first in the *depends-on* chain and is also applied first - to the pixel coordinates. - - When we say transformation :math:`A` *depends on* transformation :math:`B` we mean that - the physical motor that realizes :math:`A` is *stacked on top of* the motor that realizes :math:`B`. - So the activate coordinate transformation :math:`A` needs to be applied to a coordinate - before applying :math:`B`. In other words :math:`X' = B . A . X`. - - **Transformation matrix** - - In explicit terms, the transformations are a subset of affine transformations expressed as - 4x4 active transformation matrices that act on homogeneous coordinates, :math:`X=[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. - - **Usage** - - 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 description 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. - - **Example 1: goniometer** - - Position a sample mounted on a goniometer in the :ref:`McSTAS coordinate frame<Design-CoordinateSystem>`. - - The sample is oriented as follows - - .. math:: X_\text{lab} = R(\vec{v}_\omega, \omega) . - T(\vec{v}_z, \text{sam}_z) . - T(\vec{v}_y, \text{sam}_y) . - T(\vec{v}_x, \text{sam}_x) . - R(\vec{v}_\chi, \chi) . - R(\vec{v}_\varphi, \varphi) . X_s - - where - - * :math:`R(\vec{v},a)` is a rotation around vector :math:`\vec{v}` with angle :math:`a` - * :math:`T(\vec{u},t)` is a translation along vector :math:`\vec{u}` over a distance :math:`t` - * :math:`X_s` a coordinate in the sample reference frame. - - .. code-block:: - - entry:NXentry - sample:NXsample - depends_on=transformations/phi - transformations:NXtransformations - phi=0 - @depends_on=chi - @transformation_type=rotation - @vector=[-1 -0.0037 -0.002] - @units=degrees - chi=0 - @depends_on=sam_x - @transformation_type=rotation - @vector=[0.0046 0.0372 0.9993] - @units=degrees - sam_x=0 - @depends_on=sam_y - @transformation_type=translation - @vector=[1 0 0] - @units=mm - sam_y=0 - @depends_on=sam_z - @transformation_type=translation - @vector=[0 1 0] - @units=mm - sam_z=0 - @depends_on=omega - @transformation_type=translation - @vector=[0 0 1] - @units=mm - omega=174 - @depends_on=. - @transformation_type=rotation - @vector=[-1 0 0] - @units=degrees - - **Example 2: different coordinate system** - - Define a laboratory reference frame with the X-axis along the beam and the Z-axis opposite to the direction of gravity. - Three point detectors are positioned in this reference: - - * *transmission*: - * point detector in the beam - * 20 cm downstream from the sample (the origin of the reference frame) - * *vertical*: - * point detector 10 cm downstream from the sample - * making an angle of 5 degrees with the beam w.r.t. the sample - * positioned in the XZ-plane above the XY-plane - * *horizontal*: - * point detector 11 cm downstream from the sample - * making an angle of 6 degrees with the beam w.r.t. the sample - * positioned in the XY-plane above the XZ-plane - - The coordinates of the point detectors in the laboratory reference frame are - - * *transmission*: :math:`X_\text{lab} = T_x(20) . X_d` - * *vertical*: :math:`X_\text{lab} = R_y(-5) . T_x(10) . X_d` - * *horizontal*: :math:`X_\text{lab} = R_x(-90) . R_y(-6) . T_x(11) . X_d` - - where - - * :math:`T_x`, :math:`T_y`, :math:`T_z`: active transformation matrices for translation along the X, Y and Z axes - * :math:`R_x`, :math:`R_y`, :math:`R_z`: active transformation matrices for rotation around the X, Y and Z axes - * :math:`X_d` is a coordinate in the detector reference frame. - - Note that as these are point detectors, we only have one coordinate :math:`X_d=[0,0,0,1]^T`. - - .. code-block:: - - entry:NXentry - instrument:NXinstrument - vertical:NXdetector - depends_on=position/distance - position:NXtransformations - distance=10 # move downstream from the sample - @depends_on=polar - @units=cm - @vector=[1 0 0] - polar=5 # title above the horizontal plane - @depends_on=azimuth - @units=degrees - @vector=[0 -1 0] - azimuth=0 # stay in the vertical plane - @depends_on=/entry/coordinate_system/beam - @units=degrees - @vector=[-1 0 0] - horizontal:NXdetector - depends_on=position/distance - position:NXtransformations - distance=11 # move downstream from the sample - @depends_on=polar - @units=cm - @vector=[1 0 0] - polar=6 # title above the horizontal plane - @depends_on=azimuth - @units=degrees - @vector=[0 -1 0] - azimuth=90 # rotate to the horizontal plane - @depends_on=/entry/coordinate_system/beam - @units=degrees - @vector=[-1 0 0] - transmission:NXdetector - depends_on=position/distance - position:NXtransformations - distance=20 # move downstream from the sample - @depends_on=/entry/coordinate_system/beam - @units=cm - @vector=[1 0 0] - coordinate_system:NXtransformations - beam=NaN # value is never used - @depends_on=gravity - @vector=[1 0 0] # X-axis points in the beam direction - gravity=NaN # value is never used - @depends_on=. # end of the chain - @vector=[0 0 -1] # Z-axis points up - - - - - 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``. - - - - 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. - - - - - - - - - - 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. - - - - - - - - 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. - - - - - - - - Units of the offset. Values should be consistent with NX_LENGTH. - - - - - Points to the path of a field defining the axis on which this instance of - NXtransformations depends or the string ".". It can also point to an instance of - ``NX_coordinate_system`` if this transformation depends on it. - - - - - An arbitrary identifier of a component of the equipment to which - the transformation belongs, such as 'detector_arm' or 'detector_module'. - NXtransformations with the same equipment_component label form a logical - grouping which can be combined together into a single change-of-basis - operation. - - - - - - ``AXISNAME_end`` is a placeholder for a name constructed from the actual - name of an axis to which ``_end`` has been appended. - - The values in this field are the end points of the motions that start - at the corresponding positions given in the ``AXISNAME`` field. - - - - - ``AXISNAME_increment_set`` is a placeholder for a name constructed from the actual - name of an axis to which ``_increment_set`` has been appended. - - The value of this optional field is the intended average range through which - the corresponding axis moves during the exposure of a frame. Ideally, the - value of this field added to each value of ``AXISNAME`` would agree with the - corresponding values of ``AXISNAME_end``, but there is a possibility of significant - differences. Use of ``AXISNAME_end`` is recommended. - - + + + 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 :ref:`McSTAS coordinate frame<Design-CoordinateSystem>` + is assumed, but additional useful coordinate axes may be defined by using axes for which + no transformation type has been specified. + + **Transformation chain** + + The entry point of a chain of transformations is a field called ``depends_on`` + will be outside of this class and points 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` + which in turn depends on :math:`T_3`, the final *active* transformation + matrix :math:`T_f` is + + .. math:: T_f = T_3 . T_2 . T_1 + + For example when positioning a flat detector, its pixel positions in the laboratory + reference frame (:ref:`McSTAS coordinate frame<Design-CoordinateSystem>` by default) + can be calculated by + + .. math:: X_\text{lab} = T_f . X_\text{pixel} = T_3 . T_2 . T_1 . X_\text{pixel} + + Note that :math:`T_1` comes first in the *depends-on* chain and is also applied first + to the pixel coordinates. + + When we say transformation :math:`A` *depends on* transformation :math:`B` we mean that + the physical motor that realizes :math:`A` is *stacked on top of* the motor that realizes :math:`B`. + So the activate coordinate transformation :math:`A` needs to be applied to a coordinate + before applying :math:`B`. In other words :math:`X' = B . A . X`. + + **Transformation matrix** + + In explicit terms, the transformations are a subset of affine transformations expressed as + 4x4 active transformation matrices that act on homogeneous coordinates, :math:`X=[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. + + **Usage** + + 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 description 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. + + **Example 1: goniometer** + + Position a sample mounted on a goniometer in the :ref:`McSTAS coordinate frame<Design-CoordinateSystem>`. + + The sample is oriented as follows + + .. math:: X_\text{lab} = R(\vec{v}_\omega, \omega) . + T(\vec{v}_z, \text{sam}_z) . + T(\vec{v}_y, \text{sam}_y) . + T(\vec{v}_x, \text{sam}_x) . + R(\vec{v}_\chi, \chi) . + R(\vec{v}_\varphi, \varphi) . X_s + + where + + * :math:`R(\vec{v},a)` is a rotation around vector :math:`\vec{v}` with angle :math:`a` + * :math:`T(\vec{u},t)` is a translation along vector :math:`\vec{u}` over a distance :math:`t` + * :math:`X_s` a coordinate in the sample reference frame. + + .. code-block:: + + entry:NXentry + sample:NXsample + depends_on=transformations/phi + transformations:NXtransformations + phi=0 + @depends_on=chi + @transformation_type=rotation + @vector=[-1 -0.0037 -0.002] + @units=degrees + chi=0 + @depends_on=sam_x + @transformation_type=rotation + @vector=[0.0046 0.0372 0.9993] + @units=degrees + sam_x=0 + @depends_on=sam_y + @transformation_type=translation + @vector=[1 0 0] + @units=mm + sam_y=0 + @depends_on=sam_z + @transformation_type=translation + @vector=[0 1 0] + @units=mm + sam_z=0 + @depends_on=omega + @transformation_type=translation + @vector=[0 0 1] + @units=mm + omega=174 + @depends_on=. + @transformation_type=rotation + @vector=[-1 0 0] + @units=degrees + + **Example 2: different coordinate system** + + Define a laboratory reference frame with the X-axis along the beam and the Z-axis opposite to the direction of gravity. + Three point detectors are positioned in this reference: + + * *transmission*: + * point detector in the beam + * 20 cm downstream from the sample (the origin of the reference frame) + * *vertical*: + * point detector 10 cm downstream from the sample + * making an angle of 5 degrees with the beam w.r.t. the sample + * positioned in the XZ-plane above the XY-plane + * *horizontal*: + * point detector 11 cm downstream from the sample + * making an angle of 6 degrees with the beam w.r.t. the sample + * positioned in the XY-plane above the XZ-plane + + The coordinates of the point detectors in the laboratory reference frame are + + * *transmission*: :math:`X_\text{lab} = T_x(20) . X_d` + * *vertical*: :math:`X_\text{lab} = R_y(-5) . T_x(10) . X_d` + * *horizontal*: :math:`X_\text{lab} = R_x(-90) . R_y(-6) . T_x(11) . X_d` + + where + + * :math:`T_x`, :math:`T_y`, :math:`T_z`: active transformation matrices for translation along the X, Y and Z axes + * :math:`R_x`, :math:`R_y`, :math:`R_z`: active transformation matrices for rotation around the X, Y and Z axes + * :math:`X_d` is a coordinate in the detector reference frame. + + Note that as these are point detectors, we only have one coordinate :math:`X_d=[0,0,0,1]^T`. + + .. code-block:: + + entry:NXentry + instrument:NXinstrument + vertical:NXdetector + depends_on=position/distance + position:NXtransformations + distance=10 # move downstream from the sample + @depends_on=polar + @units=cm + @vector=[1 0 0] + polar=5 # title above the horizontal plane + @depends_on=azimuth + @units=degrees + @vector=[0 -1 0] + azimuth=0 # stay in the vertical plane + @depends_on=/entry/coordinate_system/beam + @units=degrees + @vector=[-1 0 0] + horizontal:NXdetector + depends_on=position/distance + position:NXtransformations + distance=11 # move downstream from the sample + @depends_on=polar + @units=cm + @vector=[1 0 0] + polar=6 # title above the horizontal plane + @depends_on=azimuth + @units=degrees + @vector=[0 -1 0] + azimuth=90 # rotate to the horizontal plane + @depends_on=/entry/coordinate_system/beam + @units=degrees + @vector=[-1 0 0] + transmission:NXdetector + depends_on=position/distance + position:NXtransformations + distance=20 # move downstream from the sample + @depends_on=/entry/coordinate_system/beam + @units=cm + @vector=[1 0 0] + coordinate_system:NXtransformations + beam=NaN # value is never used + @depends_on=gravity + @vector=[1 0 0] # X-axis points in the beam direction + gravity=NaN # value is never used + @depends_on=. # end of the chain + @vector=[0 0 -1] # Z-axis points up + + + + 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``. + + + + 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. + + + + + + + + + + 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. + + + + + + + + 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. + + + + + + + + Units of the offset. Values should be consistent with NX_LENGTH. + + + + + Points to the path of a field defining the axis on which this instance of + NXtransformations depends or the string ".". It can also point to an instance of + ``NX_coordinate_system`` if this transformation depends on it. + + + + + An arbitrary identifier of a component of the equipment to which + the transformation belongs, such as 'detector_arm' or 'detector_module'. + NXtransformations with the same equipment_component label form a logical + grouping which can be combined together into a single change-of-basis + operation. + + + + + + ``AXISNAME_end`` is a placeholder for a name constructed from the actual + name of an axis to which ``_end`` has been appended. + + The values in this field are the end points of the motions that start + at the corresponding positions given in the ``AXISNAME`` field. + + + + + ``AXISNAME_increment_set`` is a placeholder for a name constructed from the actual + name of an axis to which ``_increment_set`` has been appended. + + The value of this optional field is the intended average range through which + the corresponding axis moves during the exposure of a frame. Ideally, the + value of this field added to each value of ``AXISNAME`` would agree with the + corresponding values of ``AXISNAME_end``, but there is a possibility of significant + differences. Use of ``AXISNAME_end`` is recommended. + + - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. - \ No newline at end of file + diff --git a/base_classes/nyaml/NXtransformations.yaml b/base_classes/nyaml/NXtransformations.yaml index 77e94b9f1a..3a9b5f501c 100644 --- a/base_classes/nyaml/NXtransformations.yaml +++ b/base_classes/nyaml/NXtransformations.yaml @@ -187,26 +187,26 @@ doc: | vertical:NXdetector depends_on=position/distance position:NXtransformations - distance=10 # move downstream from the sample + distance=10 # move downstream from the sample @depends_on=polar @units=cm @vector=[1 0 0] - polar=5 # title above the horizontal plane + polar=5 # title above the horizontal plane @depends_on=azimuth @units=degrees @vector=[0 -1 0] - azimuth=0 # stay in the vertical plane + azimuth=0 # stay in the vertical plane @depends_on=/entry/coordinate_system/beam @units=degrees @vector=[-1 0 0] horizontal:NXdetector depends_on=position/distance position:NXtransformations - distance=11 # move downstream from the sample + distance=11 # move downstream from the sample @depends_on=polar @units=cm @vector=[1 0 0] - polar=6 # title above the horizontal plane + polar=6 # title above the horizontal plane @depends_on=azimuth @units=degrees @vector=[0 -1 0] @@ -217,16 +217,16 @@ doc: | transmission:NXdetector depends_on=position/distance position:NXtransformations - distance=20 # move downstream from the sample + distance=20 # move downstream from the sample @depends_on=/entry/coordinate_system/beam @units=cm @vector=[1 0 0] coordinate_system:NXtransformations - beam=NaN # value is never used + beam=NaN # value is never used @depends_on=gravity - @vector=[1 0 0] # X-axis points in the beam direction - gravity=NaN # value is never used - @depends_on=. # end of the chain + @vector=[1 0 0] # X-axis points in the beam direction + gravity=NaN # value is never used + @depends_on=. # end of the chain @vector=[0 0 -1] # Z-axis points up type: group ignoreExtraGroups: true @@ -338,14 +338,14 @@ NXtransformations(NXobject): for a summary of the discussion. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 5d52fcf7efc8ead93b3d310d183e880eee52434b88d148020efff95b32119d93 -# -# +# 9fe265099bd7f15a00e1f244948ae17ceb523ee01b164cc947ac5f14e9f68917 +# +# # -# -# -# -# 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 :ref:`McSTAS coordinate frame<Design-CoordinateSystem>` -# is assumed, but additional useful coordinate axes may be defined by using axes for which -# no transformation type has been specified. -# -# **Transformation chain** -# -# The entry point of a chain of transformations is a field called ``depends_on`` -# will be outside of this class and points 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` -# which in turn depends on :math:`T_3`, the final *active* transformation -# matrix :math:`T_f` is -# -# .. math:: T_f = T_3 . T_2 . T_1 -# -# For example when positioning a flat detector, its pixel positions in the laboratory -# reference frame (:ref:`McSTAS coordinate frame<Design-CoordinateSystem>` by default) -# can be calculated by -# -# .. math:: X_\text{lab} = T_f . X_\text{pixel} = T_3 . T_2 . T_1 . X_\text{pixel} -# -# Note that :math:`T_1` comes first in the *depends-on* chain and is also applied first -# to the pixel coordinates. -# -# When we say transformation :math:`A` *depends on* transformation :math:`B` we mean that -# the physical motor that realizes :math:`A` is *stacked on top of* the motor that realizes :math:`B`. -# So the activate coordinate transformation :math:`A` needs to be applied to a coordinate -# before applying :math:`B`. In other words :math:`X' = B . A . X`. -# -# **Transformation matrix** -# -# In explicit terms, the transformations are a subset of affine transformations expressed as -# 4x4 active transformation matrices that act on homogeneous coordinates, :math:`X=[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. -# -# **Usage** -# -# 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 description 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. -# -# **Example 1: goniometer** -# -# Position a sample mounted on a goniometer in the :ref:`McSTAS coordinate frame<Design-CoordinateSystem>`. -# -# The sample is oriented as follows -# -# .. math:: X_\text{lab} = R(\vec{v}_\omega, \omega) . -# T(\vec{v}_z, \text{sam}_z) . -# T(\vec{v}_y, \text{sam}_y) . -# T(\vec{v}_x, \text{sam}_x) . -# R(\vec{v}_\chi, \chi) . -# R(\vec{v}_\varphi, \varphi) . X_s -# -# where -# -# * :math:`R(\vec{v},a)` is a rotation around vector :math:`\vec{v}` with angle :math:`a` -# * :math:`T(\vec{u},t)` is a translation along vector :math:`\vec{u}` over a distance :math:`t` -# * :math:`X_s` a coordinate in the sample reference frame. -# -# .. code-block:: -# -# entry:NXentry -# sample:NXsample -# depends_on=transformations/phi -# transformations:NXtransformations -# phi=0 -# @depends_on=chi -# @transformation_type=rotation -# @vector=[-1 -0.0037 -0.002] -# @units=degrees -# chi=0 -# @depends_on=sam_x -# @transformation_type=rotation -# @vector=[0.0046 0.0372 0.9993] -# @units=degrees -# sam_x=0 -# @depends_on=sam_y -# @transformation_type=translation -# @vector=[1 0 0] -# @units=mm -# sam_y=0 -# @depends_on=sam_z -# @transformation_type=translation -# @vector=[0 1 0] -# @units=mm -# sam_z=0 -# @depends_on=omega -# @transformation_type=translation -# @vector=[0 0 1] -# @units=mm -# omega=174 -# @depends_on=. -# @transformation_type=rotation -# @vector=[-1 0 0] -# @units=degrees -# -# **Example 2: different coordinate system** -# -# Define a laboratory reference frame with the X-axis along the beam and the Z-axis opposite to the direction of gravity. -# Three point detectors are positioned in this reference: -# -# * *transmission*: -# * point detector in the beam -# * 20 cm downstream from the sample (the origin of the reference frame) -# * *vertical*: -# * point detector 10 cm downstream from the sample -# * making an angle of 5 degrees with the beam w.r.t. the sample -# * positioned in the XZ-plane above the XY-plane -# * *horizontal*: -# * point detector 11 cm downstream from the sample -# * making an angle of 6 degrees with the beam w.r.t. the sample -# * positioned in the XY-plane above the XZ-plane -# -# The coordinates of the point detectors in the laboratory reference frame are -# -# * *transmission*: :math:`X_\text{lab} = T_x(20) . X_d` -# * *vertical*: :math:`X_\text{lab} = R_y(-5) . T_x(10) . X_d` -# * *horizontal*: :math:`X_\text{lab} = R_x(-90) . R_y(-6) . T_x(11) . X_d` -# -# where -# -# * :math:`T_x`, :math:`T_y`, :math:`T_z`: active transformation matrices for translation along the X, Y and Z axes -# * :math:`R_x`, :math:`R_y`, :math:`R_z`: active transformation matrices for rotation around the X, Y and Z axes -# * :math:`X_d` is a coordinate in the detector reference frame. -# -# Note that as these are point detectors, we only have one coordinate :math:`X_d=[0,0,0,1]^T`. -# -# .. code-block:: -# -# entry:NXentry -# instrument:NXinstrument -# vertical:NXdetector -# depends_on=position/distance -# position:NXtransformations -# distance=10 # move downstream from the sample -# @depends_on=polar -# @units=cm -# @vector=[1 0 0] -# polar=5 # title above the horizontal plane -# @depends_on=azimuth -# @units=degrees -# @vector=[0 -1 0] -# azimuth=0 # stay in the vertical plane -# @depends_on=/entry/coordinate_system/beam -# @units=degrees -# @vector=[-1 0 0] -# horizontal:NXdetector -# depends_on=position/distance -# position:NXtransformations -# distance=11 # move downstream from the sample -# @depends_on=polar -# @units=cm -# @vector=[1 0 0] -# polar=6 # title above the horizontal plane -# @depends_on=azimuth -# @units=degrees -# @vector=[0 -1 0] -# azimuth=90 # rotate to the horizontal plane -# @depends_on=/entry/coordinate_system/beam -# @units=degrees -# @vector=[-1 0 0] -# transmission:NXdetector -# depends_on=position/distance -# position:NXtransformations -# distance=20 # move downstream from the sample -# @depends_on=/entry/coordinate_system/beam -# @units=cm -# @vector=[1 0 0] -# coordinate_system:NXtransformations -# beam=NaN # value is never used -# @depends_on=gravity -# @vector=[1 0 0] # X-axis points in the beam direction -# gravity=NaN # value is never used -# @depends_on=. # end of the chain -# @vector=[0 0 -1] # Z-axis points up -# -# -# -# -# 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``. -# -# -# -# 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. -# -# -# -# -# -# -# -# -# -# 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. -# -# -# -# -# -# -# -# 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. -# -# -# -# -# -# -# -# Units of the offset. Values should be consistent with NX_LENGTH. -# -# -# -# -# Points to the path of a field defining the axis on which this instance of -# NXtransformations depends or the string ".". It can also point to an instance of -# ``NX_coordinate_system`` if this transformation depends on it. -# -# -# -# -# An arbitrary identifier of a component of the equipment to which -# the transformation belongs, such as 'detector_arm' or 'detector_module'. -# NXtransformations with the same equipment_component label form a logical -# grouping which can be combined together into a single change-of-basis -# operation. -# -# -# -# -# -# ``AXISNAME_end`` is a placeholder for a name constructed from the actual -# name of an axis to which ``_end`` has been appended. -# -# The values in this field are the end points of the motions that start -# at the corresponding positions given in the ``AXISNAME`` field. -# -# -# -# -# ``AXISNAME_increment_set`` is a placeholder for a name constructed from the actual -# name of an axis to which ``_increment_set`` has been appended. -# -# The value of this optional field is the intended average range through which -# the corresponding axis moves during the exposure of a frame. Ideally, the -# value of this field added to each value of ``AXISNAME`` would agree with the -# corresponding values of ``AXISNAME_end``, but there is a possibility of significant -# differences. Use of ``AXISNAME_end`` is recommended. -# -# +# +# +# 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 :ref:`McSTAS coordinate frame<Design-CoordinateSystem>` +# is assumed, but additional useful coordinate axes may be defined by using axes for which +# no transformation type has been specified. +# +# **Transformation chain** +# +# The entry point of a chain of transformations is a field called ``depends_on`` +# will be outside of this class and points 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` +# which in turn depends on :math:`T_3`, the final *active* transformation +# matrix :math:`T_f` is +# +# .. math:: T_f = T_3 . T_2 . T_1 +# +# For example when positioning a flat detector, its pixel positions in the laboratory +# reference frame (:ref:`McSTAS coordinate frame<Design-CoordinateSystem>` by default) +# can be calculated by +# +# .. math:: X_\text{lab} = T_f . X_\text{pixel} = T_3 . T_2 . T_1 . X_\text{pixel} +# +# Note that :math:`T_1` comes first in the *depends-on* chain and is also applied first +# to the pixel coordinates. +# +# When we say transformation :math:`A` *depends on* transformation :math:`B` we mean that +# the physical motor that realizes :math:`A` is *stacked on top of* the motor that realizes :math:`B`. +# So the activate coordinate transformation :math:`A` needs to be applied to a coordinate +# before applying :math:`B`. In other words :math:`X' = B . A . X`. +# +# **Transformation matrix** +# +# In explicit terms, the transformations are a subset of affine transformations expressed as +# 4x4 active transformation matrices that act on homogeneous coordinates, :math:`X=[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. +# +# **Usage** +# +# 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 description 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. +# +# **Example 1: goniometer** +# +# Position a sample mounted on a goniometer in the :ref:`McSTAS coordinate frame<Design-CoordinateSystem>`. +# +# The sample is oriented as follows +# +# .. math:: X_\text{lab} = R(\vec{v}_\omega, \omega) . +# T(\vec{v}_z, \text{sam}_z) . +# T(\vec{v}_y, \text{sam}_y) . +# T(\vec{v}_x, \text{sam}_x) . +# R(\vec{v}_\chi, \chi) . +# R(\vec{v}_\varphi, \varphi) . X_s +# +# where +# +# * :math:`R(\vec{v},a)` is a rotation around vector :math:`\vec{v}` with angle :math:`a` +# * :math:`T(\vec{u},t)` is a translation along vector :math:`\vec{u}` over a distance :math:`t` +# * :math:`X_s` a coordinate in the sample reference frame. +# +# .. code-block:: +# +# entry:NXentry +# sample:NXsample +# depends_on=transformations/phi +# transformations:NXtransformations +# phi=0 +# @depends_on=chi +# @transformation_type=rotation +# @vector=[-1 -0.0037 -0.002] +# @units=degrees +# chi=0 +# @depends_on=sam_x +# @transformation_type=rotation +# @vector=[0.0046 0.0372 0.9993] +# @units=degrees +# sam_x=0 +# @depends_on=sam_y +# @transformation_type=translation +# @vector=[1 0 0] +# @units=mm +# sam_y=0 +# @depends_on=sam_z +# @transformation_type=translation +# @vector=[0 1 0] +# @units=mm +# sam_z=0 +# @depends_on=omega +# @transformation_type=translation +# @vector=[0 0 1] +# @units=mm +# omega=174 +# @depends_on=. +# @transformation_type=rotation +# @vector=[-1 0 0] +# @units=degrees +# +# **Example 2: different coordinate system** +# +# Define a laboratory reference frame with the X-axis along the beam and the Z-axis opposite to the direction of gravity. +# Three point detectors are positioned in this reference: +# +# * *transmission*: +# * point detector in the beam +# * 20 cm downstream from the sample (the origin of the reference frame) +# * *vertical*: +# * point detector 10 cm downstream from the sample +# * making an angle of 5 degrees with the beam w.r.t. the sample +# * positioned in the XZ-plane above the XY-plane +# * *horizontal*: +# * point detector 11 cm downstream from the sample +# * making an angle of 6 degrees with the beam w.r.t. the sample +# * positioned in the XY-plane above the XZ-plane +# +# The coordinates of the point detectors in the laboratory reference frame are +# +# * *transmission*: :math:`X_\text{lab} = T_x(20) . X_d` +# * *vertical*: :math:`X_\text{lab} = R_y(-5) . T_x(10) . X_d` +# * *horizontal*: :math:`X_\text{lab} = R_x(-90) . R_y(-6) . T_x(11) . X_d` +# +# where +# +# * :math:`T_x`, :math:`T_y`, :math:`T_z`: active transformation matrices for translation along the X, Y and Z axes +# * :math:`R_x`, :math:`R_y`, :math:`R_z`: active transformation matrices for rotation around the X, Y and Z axes +# * :math:`X_d` is a coordinate in the detector reference frame. +# +# Note that as these are point detectors, we only have one coordinate :math:`X_d=[0,0,0,1]^T`. +# +# .. code-block:: +# +# entry:NXentry +# instrument:NXinstrument +# vertical:NXdetector +# depends_on=position/distance +# position:NXtransformations +# distance=10 # move downstream from the sample +# @depends_on=polar +# @units=cm +# @vector=[1 0 0] +# polar=5 # title above the horizontal plane +# @depends_on=azimuth +# @units=degrees +# @vector=[0 -1 0] +# azimuth=0 # stay in the vertical plane +# @depends_on=/entry/coordinate_system/beam +# @units=degrees +# @vector=[-1 0 0] +# horizontal:NXdetector +# depends_on=position/distance +# position:NXtransformations +# distance=11 # move downstream from the sample +# @depends_on=polar +# @units=cm +# @vector=[1 0 0] +# polar=6 # title above the horizontal plane +# @depends_on=azimuth +# @units=degrees +# @vector=[0 -1 0] +# azimuth=90 # rotate to the horizontal plane +# @depends_on=/entry/coordinate_system/beam +# @units=degrees +# @vector=[-1 0 0] +# transmission:NXdetector +# depends_on=position/distance +# position:NXtransformations +# distance=20 # move downstream from the sample +# @depends_on=/entry/coordinate_system/beam +# @units=cm +# @vector=[1 0 0] +# coordinate_system:NXtransformations +# beam=NaN # value is never used +# @depends_on=gravity +# @vector=[1 0 0] # X-axis points in the beam direction +# gravity=NaN # value is never used +# @depends_on=. # end of the chain +# @vector=[0 0 -1] # Z-axis points up +# +# +# +# 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``. +# +# +# +# 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. +# +# +# +# +# +# +# +# +# +# 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. +# +# +# +# +# +# +# +# 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. +# +# +# +# +# +# +# +# Units of the offset. Values should be consistent with NX_LENGTH. +# +# +# +# +# Points to the path of a field defining the axis on which this instance of +# NXtransformations depends or the string ".". It can also point to an instance of +# ``NX_coordinate_system`` if this transformation depends on it. +# +# +# +# +# An arbitrary identifier of a component of the equipment to which +# the transformation belongs, such as 'detector_arm' or 'detector_module'. +# NXtransformations with the same equipment_component label form a logical +# grouping which can be combined together into a single change-of-basis +# operation. +# +# +# +# +# +# ``AXISNAME_end`` is a placeholder for a name constructed from the actual +# name of an axis to which ``_end`` has been appended. +# +# The values in this field are the end points of the motions that start +# at the corresponding positions given in the ``AXISNAME`` field. +# +# +# +# +# ``AXISNAME_increment_set`` is a placeholder for a name constructed from the actual +# name of an axis to which ``_increment_set`` has been appended. +# +# The value of this optional field is the intended average range through which +# the corresponding axis moves during the exposure of a frame. Ideally, the +# value of this field added to each value of ``AXISNAME`` would agree with the +# corresponding values of ``AXISNAME_end``, but there is a possibility of significant +# differences. Use of ``AXISNAME_end`` is recommended. +# +# # # -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. # # -# \ No newline at end of file +# From 8755e84b66fa23838403a754600c0c9476194116 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 3 Jul 2024 14:56:48 +0200 Subject: [PATCH 0764/1012] ci/cd fix --- base_classes/NXtransformations.nxdl.xml | 24 +++++++++++------------ base_classes/nyaml/NXtransformations.yaml | 22 ++++++++++----------- 2 files changed, 23 insertions(+), 23 deletions(-) diff --git a/base_classes/NXtransformations.nxdl.xml b/base_classes/NXtransformations.nxdl.xml index bfbed37436..41d2d5d7da 100644 --- a/base_classes/NXtransformations.nxdl.xml +++ b/base_classes/NXtransformations.nxdl.xml @@ -210,47 +210,47 @@ vertical:NXdetector depends_on=position/distance position:NXtransformations - distance=10 # move downstream from the sample + distance=10 # move downstream from the sample @depends_on=polar @units=cm @vector=[1 0 0] - polar=5 # title above the horizontal plane + polar=5 # title above the horizontal plane @depends_on=azimuth @units=degrees @vector=[0 -1 0] - azimuth=0 # stay in the vertical plane + azimuth=0 # stay in the vertical plane @depends_on=/entry/coordinate_system/beam @units=degrees @vector=[-1 0 0] horizontal:NXdetector depends_on=position/distance position:NXtransformations - distance=11 # move downstream from the sample + distance=11 # move downstream from the sample @depends_on=polar @units=cm @vector=[1 0 0] - polar=6 # title above the horizontal plane + polar=6 # title above the horizontal plane @depends_on=azimuth @units=degrees @vector=[0 -1 0] - azimuth=90 # rotate to the horizontal plane + azimuth=90 # rotate to the horizontal plane @depends_on=/entry/coordinate_system/beam @units=degrees @vector=[-1 0 0] transmission:NXdetector depends_on=position/distance position:NXtransformations - distance=20 # move downstream from the sample + distance=20 # move downstream from the sample @depends_on=/entry/coordinate_system/beam @units=cm @vector=[1 0 0] coordinate_system:NXtransformations - beam=NaN # value is never used + beam=NaN # value is never used @depends_on=gravity - @vector=[1 0 0] # X-axis points in the beam direction - gravity=NaN # value is never used - @depends_on=. # end of the chain - @vector=[0 0 -1] # Z-axis points up + @vector=[1 0 0] # X-axis points in the beam direction + gravity=NaN # value is never used + @depends_on=. # end of the chain + @vector=[0 0 -1] # Z-axis points up diff --git a/base_classes/nyaml/NXtransformations.yaml b/base_classes/nyaml/NXtransformations.yaml index 3a9b5f501c..1d57a9386a 100644 --- a/base_classes/nyaml/NXtransformations.yaml +++ b/base_classes/nyaml/NXtransformations.yaml @@ -187,47 +187,47 @@ doc: | vertical:NXdetector depends_on=position/distance position:NXtransformations - distance=10 # move downstream from the sample + distance=10 # move downstream from the sample @depends_on=polar @units=cm @vector=[1 0 0] - polar=5 # title above the horizontal plane + polar=5 # title above the horizontal plane @depends_on=azimuth @units=degrees @vector=[0 -1 0] - azimuth=0 # stay in the vertical plane + azimuth=0 # stay in the vertical plane @depends_on=/entry/coordinate_system/beam @units=degrees @vector=[-1 0 0] horizontal:NXdetector depends_on=position/distance position:NXtransformations - distance=11 # move downstream from the sample + distance=11 # move downstream from the sample @depends_on=polar @units=cm @vector=[1 0 0] - polar=6 # title above the horizontal plane + polar=6 # title above the horizontal plane @depends_on=azimuth @units=degrees @vector=[0 -1 0] - azimuth=90 # rotate to the horizontal plane + azimuth=90 # rotate to the horizontal plane @depends_on=/entry/coordinate_system/beam @units=degrees @vector=[-1 0 0] transmission:NXdetector depends_on=position/distance position:NXtransformations - distance=20 # move downstream from the sample + distance=20 # move downstream from the sample @depends_on=/entry/coordinate_system/beam @units=cm @vector=[1 0 0] coordinate_system:NXtransformations beam=NaN # value is never used @depends_on=gravity - @vector=[1 0 0] # X-axis points in the beam direction - gravity=NaN # value is never used - @depends_on=. # end of the chain - @vector=[0 0 -1] # Z-axis points up + @vector=[1 0 0] # X-axis points in the beam direction + gravity=NaN # value is never used + @depends_on=. # end of the chain + @vector=[0 0 -1] # Z-axis points up type: group ignoreExtraGroups: true ignoreExtraFields: true From 664deb8317b23b1cd1fc0b4dc46d94b65ef1ca2a Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 3 Jul 2024 15:04:19 +0200 Subject: [PATCH 0765/1012] regenerate NXcoordinate system files --- contributed_definitions/NXcoordinate_system.nxdl.xml | 2 +- contributed_definitions/nyaml/NXcoordinate_system.yaml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index a514fc4b70..89857ca599 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -142,7 +142,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d - This specificies the relation to another coordinate system by pointing to the last + This specificies the relation to another coordinate system by pointing to the last transformation in the transformation chain in the NXtransformations group. diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml index f0c60573ab..9ebc18667f 100644 --- a/contributed_definitions/nyaml/NXcoordinate_system.yaml +++ b/contributed_definitions/nyaml/NXcoordinate_system.yaml @@ -246,7 +246,7 @@ NXcoordinate_system(NXobject): # # # -# This specificies the relation to another coordinate system by pointing to the last +# This specificies the relation to another coordinate system by pointing to the last # transformation in the transformation chain in the NXtransformations group. # # From 30eaca0d496136bdff81c8e7b891b629c23d9624 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 3 Jul 2024 15:50:17 +0200 Subject: [PATCH 0766/1012] rename depends_on attr in NXem_conventions --- .../NXem_conventions.nxdl.xml | 2 +- .../nyaml/NXem_conventions.yaml | 547 +++++++++++++++++- 2 files changed, 546 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/NXem_conventions.nxdl.xml b/contributed_definitions/NXem_conventions.nxdl.xml index 1c948affc4..4ba9fd30e1 100644 --- a/contributed_definitions/NXem_conventions.nxdl.xml +++ b/contributed_definitions/NXem_conventions.nxdl.xml @@ -398,7 +398,7 @@ assumed reference frame and rotation conventions--> Details about the detector reference frame for a specific detector. - + Reference to the specifically named :ref:`NXdetector` instance for which these conventions in this :ref:`NXprocess` group apply diff --git a/contributed_definitions/nyaml/NXem_conventions.yaml b/contributed_definitions/nyaml/NXem_conventions.yaml index 7835d9a654..aa9763d510 100644 --- a/contributed_definitions/nyaml/NXem_conventions.yaml +++ b/contributed_definitions/nyaml/NXem_conventions.yaml @@ -1,4 +1,5 @@ category: base + # symbols: doc: | Conventions for rotations and coordinate systems to interpret crystal orientation @@ -42,6 +43,7 @@ doc: | # definition. type: group NXem_conventions(NXobject): + # mandatory information about used or # assumed reference frame and rotation conventions rotation_conventions(NXobject): @@ -223,7 +225,8 @@ NXem_conventions(NXobject): detector_reference_frameID(NXcoordinate_system): doc: | Details about the detector reference frame for a specific detector. - \@depends_on(NX_CHAR): + \@detector: + type: NX_CHAR doc: | Reference to the specifically named :ref:`NXdetector` instance for which these conventions in this :ref:`NXprocess` group apply @@ -292,5 +295,545 @@ NXem_conventions(NXobject): For further information consult also the help info for the xaxis_direction field. enumeration: [undefined, north, east, south, west, in, out] + + # conventions specific for EBSD + (NXem_conventions_ebsd): + # conventions specific for EBSD - (NXem_conventions_ebsd): \ No newline at end of file + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# b4e33f4b52cd8aad5fa72fb4796c5ca1cd43482b7394ca7af917b8d321024659 +# +# +# +# +# +# +# +# +# +# +# Conventions for rotations and coordinate systems to interpret crystal orientation +# and other data and results collected with electron microscopy research. +# +# Documenting explicitly all used conventions and coordinate systems is +# the decisive context whereby many results from electron microscopy are +# at all interpretable. +# +# +# +# +# Mathematical conventions and materials-science-specific conventions +# required for interpreting every collection of orientation data. +# +# +# +# Convention how a positive rotation angle is defined when viewing +# from the end of the rotation unit vector towards its origin, +# i.e. in accordance with convention 2 of +# DOI: 10.1088/0965-0393/23/8/083501. +# Counter_clockwise is equivalent to a right-handed choice. +# Clockwise is equivalent to a left-handed choice. +# +# +# +# +# +# +# +# +# +# How are rotations interpreted into an orientation +# according to convention 3 of +# DOI: 10.1088/0965-0393/23/8/083501. +# +# +# +# +# +# +# +# +# +# How are Euler angles interpreted given that there are several +# choices (e.g. ZXZ, XYZ, etc.) according to convention 4 of +# DOI: 10.1088/0965-0393/23/8/083501. +# The most frequently used convention is ZXZ which is based on +# the work of H.-J. Bunge but other conventions are possible. +# +# +# +# +# +# +# +# +# To which angular range is the rotation angle argument of an +# axis-angle pair parameterization constrained according to +# convention 5 of DOI: 10.1088/0965-0393/23/8/083501. +# +# +# +# +# +# +# +# +# Which sign convention is followed when converting orientations +# between different parameterizations/representations according +# to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. +# +# +# +# +# +# +# +# +# +# +# Details about eventually relevant named directions that may +# give reasons for anisotropies. The classical example is cold-rolling +# where one has to specify which directions (rolling, transverse, and normal) +# align how with the direction of the base vectors of the sample_reference_frame. +# +# +# +# Type of coordinate system and reference frame according to +# convention 1 of DOI: 10.1088/0965-0393/23/8/083501. +# +# +# +# +# +# +# +# +# Handedness of coordinate system. +# +# +# +# +# +# +# +# +# Location of the origin of the processing_reference_frame. +# This specifies the location Xp = 0, Yp = 0, Zp = 0. +# Assume regions-of-interest in this reference frame form a +# rectangle or cuboid. +# Edges are interpreted by inspecting the direction of their +# outer unit normals (which point either parallel or antiparallel) +# along respective base vector direction of the reference frame. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Name or alias assigned to the x-axis base vector, +# e.g. rolling direction. +# +# +# +# +# Direction of the positively pointing x-axis base vector of +# the processing_reference_frame. We assume the configuration +# is inspected by looking towards the sample surface from a position +# that is located behind the detector. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Name or alias assigned to the y-axis base vector, +# e.g. transverse direction. +# +# +# +# +# Direction of the positively pointing y-axis base vector of +# the processing_reference_frame. We assume the configuration +# is inspected by looking towards the sample surface from a position +# that is located behind the detector. For further information consult +# also the help info for the xaxis_direction field. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Name or alias assigned to the z-axis base vector, +# e.g. normal direction. +# +# +# +# +# Direction of the positively pointing z-axis base vector of +# the processing_reference frame. We assume the configuration +# is inspected by looking towards the sample surface from a position +# that is located behind the detector. For further information consult +# also the help info for the xaxis_direction field. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Details about the sample/specimen reference frame. +# +# +# +# Type of coordinate system and reference frame according to +# convention 1 of DOI: 10.1088/0965-0393/23/8/083501. +# The reference frame for the sample surface reference is used for +# identifying positions on a (virtual) image which is formed by +# information collected from an electron beam scanning the +# sample surface. We assume the configuration is inspected by +# looking towards the sample surface from a position that is +# located behind the detector. +# Reference DOI: 10.1016/j.matchar.2016.04.008 +# The sample surface reference frame has coordinates Xs, Ys, Zs. +# In three dimensions these coordinates are not necessarily +# located on the surface of the sample as there are multiple +# faces/sides of the sample. Most frequently though the coordinate +# system here is used to define the surface which the electron +# beam scans. +# +# +# +# +# +# +# +# +# Handedness of the coordinate system if it is a Cartesian. +# +# +# +# +# +# +# +# +# Location of the origin of the sample surface reference frame. +# This specifies the location Xs = 0, Ys = 0, Zs = 0. +# Assume regions-of-interest in this reference frame form a +# rectangle or cuboid. +# Edges are interpreted by inspecting the direction of their +# outer unit normals (which point either parallel or antiparallel) +# along respective base vector direction of the reference frame. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Name or alias assigned to the x-axis base vector, +# e.g. longest edge. +# +# +# +# +# Direction of the positively pointing x-axis base vector of +# the sample surface reference frame. We assume the configuration +# is inspected by looking towards the sample surface from a position +# that is located behind the detector. +# Different tools assume that different strategies can be used +# and are perceived as differently convenient to enter +# details about coordinate system definitions. In this ELN users +# have to possibility to fill in what they assume is sufficient to +# define the coordinate system directions unambiguously. +# Software which works with this user input needs to offer parsing +# capabilities which detect conflicting input and warn accordingly. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Name or alias assigned to the y-axis base vector, +# e.g. long edge. +# +# +# +# +# Direction of the positively pointing y-axis base vector of +# the sample surface reference frame. We assume the configuration +# is inspected by looking towards the sample surface from a position +# that is located behind the detector. For further information consult +# also the help info for the xaxis_direction field. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Name or alias assigned to the z-axis base vector, +# e.g. shortest edge. +# +# +# +# +# Direction of the positively pointing z-axis base vector of +# the sample surface reference frame. We assume the configuration +# is inspected by looking towards the sample surface from a position +# that is located behind the detector. For further information consult +# also the help info for the xaxis_direction field. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Details about the detector reference frame for a specific detector. +# +# +# +# Reference to the specifically named :ref:`NXdetector` instance +# for which these conventions in this :ref:`NXprocess` group apply +# (e.g. /entry1/instrument/detector1). +# +# +# +# +# Type of coordinate system/reference frame used for +# identifying positions in detector space Xd, Yd, Zd, +# according to DOI: 10.1016/j.matchar.2016.04.008. +# +# +# +# +# +# +# +# +# Handedness of the coordinate system if it is a Cartesian. +# +# +# +# +# +# +# +# +# Where is the origin of the detector space reference +# frame located. This is the location of Xd = 0, Yd = 0, Zd = 0. +# Assume regions-of-interest in this reference frame form a +# rectangle or cuboid. +# Edges are interpreted by inspecting the direction of their +# outer unit normals (which point either parallel or antiparallel) +# along respective base vector direction of the reference frame. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Name or alias assigned to the x-axis base vector, +# e.g. longest edge as some landmark on the detector. +# +# +# +# +# Direction of the positively pointing x-axis base vector of +# the detector space reference frame. We assume the configuration +# is inspected by looking towards the sample surface from a +# position that is located behind the detector. +# Different tools assume that different strategies can be used +# and are perceived as differently convenient to enter +# details about coordinate system definitions. In this ELN users +# have to possibility to fill in what they assume is sufficient to +# define the coordinate system directions unambiguously. +# Software which works with this user input needs to offer parsing +# capabilities which detect conflicting input and warn accordingly. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Name or alias assigned to the x-axis base vector, +# e.g. long edge as some landmark on the detector. +# +# +# +# +# Direction of the positively pointing y-axis base vector of +# the detector space reference frame. We assume the configuration +# is inspected by looking towards the sample surface from a +# position that is located behind the detector. +# For further information consult also the help info for the +# xaxis_direction field. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Name or alias assigned to the x-axis base vector, +# e.g. short edge as some landmark on the detector. +# +# +# +# +# Direction of the positively pointing z-axis base vector of +# the detector space reference frame. We assume the configuration +# is inspected by looking towards the sample surface from a +# position that is located behind the detector. +# For further information consult also the help info for the +# xaxis_direction field. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# From 275da1d9e75b0c4454e060e9c57e8eeaf01db88d Mon Sep 17 00:00:00 2001 From: Ron Hildebrandt Date: Thu, 4 Jul 2024 08:57:04 +0200 Subject: [PATCH 0767/1012] add url fix for pynxtools validation --- contributed_definitions/NXellipsometry.nxdl.xml | 4 ++-- contributed_definitions/NXoptical_spectroscopy.nxdl.xml | 4 ++-- contributed_definitions/NXraman.nxdl.xml | 2 +- contributed_definitions/nyaml/NXellipsometry.yaml | 4 ++-- contributed_definitions/nyaml/NXoptical_spectroscopy.yaml | 4 ++-- contributed_definitions/nyaml/NXraman.yaml | 2 +- 6 files changed, 10 insertions(+), 10 deletions(-) diff --git a/contributed_definitions/NXellipsometry.nxdl.xml b/contributed_definitions/NXellipsometry.nxdl.xml index 87e6f6d06f..e7ae037cf0 100644 --- a/contributed_definitions/NXellipsometry.nxdl.xml +++ b/contributed_definitions/NXellipsometry.nxdl.xml @@ -109,7 +109,7 @@ A rework of the draft version(06/2022) of a NeXus application definition for ell definition was used for this entry/data. - + URL where to find further material (documentation, examples) relevant to the application definition. @@ -381,7 +381,7 @@ NXellipsometry.--> deterministic manner. - + Website of the software. diff --git a/contributed_definitions/NXoptical_spectroscopy.nxdl.xml b/contributed_definitions/NXoptical_spectroscopy.nxdl.xml index 4213c2359a..b053470b10 100644 --- a/contributed_definitions/NXoptical_spectroscopy.nxdl.xml +++ b/contributed_definitions/NXoptical_spectroscopy.nxdl.xml @@ -77,7 +77,7 @@ TODO: definition was used for this entry/data. - + URL where to find further material (documentation, examples) relevant to the application definition. @@ -851,7 +851,7 @@ TODO: deterministic manner. - + Description of the software by persistent resource, where the program, code, script etc. can be found. diff --git a/contributed_definitions/NXraman.nxdl.xml b/contributed_definitions/NXraman.nxdl.xml index 18d9caa6f1..8f133ac117 100644 --- a/contributed_definitions/NXraman.nxdl.xml +++ b/contributed_definitions/NXraman.nxdl.xml @@ -143,7 +143,7 @@ A draft version of a NeXus application definition for Raman spectroscopy.--> definition was used for this entry/data. - + URL where to find further material (documentation, examples) relevant to the application definition. diff --git a/contributed_definitions/nyaml/NXellipsometry.yaml b/contributed_definitions/nyaml/NXellipsometry.yaml index 84093ac00c..c9d50faf96 100644 --- a/contributed_definitions/nyaml/NXellipsometry.yaml +++ b/contributed_definitions/nyaml/NXellipsometry.yaml @@ -73,7 +73,7 @@ NXellipsometry(NXoptical_spectroscopy): doc: | Version number to identify which definition of this application definition was used for this entry/data. - \@url: + \@URL: doc: | URL where to find further material (documentation, examples) relevant to the application definition. @@ -275,7 +275,7 @@ NXellipsometry(NXoptical_spectroscopy): instructions can be found so that the program can be configured in such a way that result files can be created ideally in a deterministic manner. - \@url: + \@URL: exists: optional doc: | Website of the software. diff --git a/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml b/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml index 836db39862..0862a5f410 100644 --- a/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml +++ b/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml @@ -44,7 +44,7 @@ NXoptical_spectroscopy(NXobject): doc: | Version number to identify which definition of this application definition was used for this entry/data. - \@url: + \@URL: doc: | URL where to find further material (documentation, examples) relevant to the application definition. @@ -672,7 +672,7 @@ NXoptical_spectroscopy(NXobject): instructions can be found so that the program can be configured in such a way that result files can be created ideally in a deterministic manner. - \@url: + \@URL: exists: optional doc: | Description of the software by persistent resource, where the program, diff --git a/contributed_definitions/nyaml/NXraman.yaml b/contributed_definitions/nyaml/NXraman.yaml index a9672b0e7b..8d68d1fee0 100644 --- a/contributed_definitions/nyaml/NXraman.yaml +++ b/contributed_definitions/nyaml/NXraman.yaml @@ -101,7 +101,7 @@ NXraman(NXoptical_spectroscopy): doc: | Version number to identify which definition of this application definition was used for this entry/data. - \@url: + \@URL: doc: | URL where to find further material (documentation, examples) relevant to the application definition. From 259efd8545a099a2a68af20dcec89387aff98fcc Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 4 Jul 2024 11:24:12 +0200 Subject: [PATCH 0768/1012] Implemented suggestions from @lukaspie --- .../NXapm_compositionspace_config.nxdl.xml | 65 +++++++------ .../NXapm_compositionspace_results.nxdl.xml | 95 ++++++++++--------- .../nyaml/NXapm_compositionspace_config.yaml | 50 ++++++---- .../nyaml/NXapm_compositionspace_results.yaml | 85 ++++++++++------- 4 files changed, 170 insertions(+), 125 deletions(-) diff --git a/contributed_definitions/NXapm_compositionspace_config.nxdl.xml b/contributed_definitions/NXapm_compositionspace_config.nxdl.xml index 974c5a6a43..923e1a1373 100644 --- a/contributed_definitions/NXapm_compositionspace_config.nxdl.xml +++ b/contributed_definitions/NXapm_compositionspace_config.nxdl.xml @@ -25,16 +25,16 @@ Application definition for a configuration of the CompositionSpace tool used in atom probe. - * `A. Saxena et al. <https://www.github.com/eisenforschung/CompositionSpacetool.git>`_ + * `A. Saxena et al. <https://www.github.com/eisenforschung/CompositionSpace.git>`_ - This is a draft application definition for the common NFDI-MatWerk/FAIRmat infrastructure + This is an application definition for the common NFDI-MatWerk/FAIRmat infrastructure use case IUC09 that explores how to improve the organization and results storage of the - CompositionSpace tool. + CompositionSpace software using NeXus. - + @@ -45,35 +45,40 @@ Specification of the tomographic reconstruction used for this analysis. - Typically, reconstructions in the field of atom probe tomography are communicated - via files which store at least reconstructed ion positions and mass-to-charge-state-ratio + Typically, reconstructions in the field of atom probe tomography are communicated via + files which store at least reconstructed ion positions and mass-to-charge-state-ratio values. Container files like HDF5 though can store multiple reconstructions. Therefore, the position and mass_to_charge concepts point to specific instances to use for this analysis. - + - - + + - Name of the node which resolves the reconstructed ion position values to use for - this analysis. + Name of the node which resolves the reconstructed + ion position values to use for this analysis. + + + + + Name of the node which resolves the mass-to-charge-state ratio + values for each reconstructed ion to use for this analysis. - Specification of the ranging definitions used for this analysis. - Indices start from 1. The value 0 is reserved for the null model of unranged positions - whose iontype is unknown_type. The value 0 is alsoreserved for voxel outside the dataset. + Indices start from 1. The value 0 is reserved for the null model of unranged positions whose + iontype is unknown_type. The value 0 is also reserved for voxels that lie outside the dataset. - + - - + + Name of the (parent) node directly below which the ranging definitions for @@ -89,22 +94,23 @@ - Edge length of cubic voxels for 3D grid that is used for discretizing the point - cloud. + Edge length of cubic voxels building the 3D grid that is used for discretizing + the point cloud. - Optional step during which the subsequent segmentation step is prepared to - improve the segmentation. + Optional step during which the subsequent segmentation step is prepared with the aim to eventually + reduce the dimensionality of the chemical space in which the machine learning model works. + + In this step a supervised reduction of the dimensionality of the chemical space is quantified using + the (Gini) feature importance of each element to suggest which columns of the composition matrix + should be taken for the subsequent segmentation step. Was the automated phase assignment used? - This algorithm achieves a supervised reduction of the dimensionality of the chemical space - through an analysis of the (Gini) feature importance of each element for the subsequent - segmentation step. @@ -120,7 +126,7 @@ The number of elements to use for reducing the dimensionality. - + Configuration for the random forest classification model. @@ -131,11 +137,10 @@ Step during which the voxel set is segmented into voxel sets with different chemical composition. - + - A principal component analysis of the chemical space to guide a decision into how many - sets of voxels with different chemical composition the machine learning algorithm suggests - that the dataset should be analyzed as. + A principal component analysis of the chemical space to guide a decision into how many sets of voxels + with different chemical composition the machine learning algorithm suggests to split the voxel set. @@ -150,7 +155,7 @@ chemical compositions. - + Configuration for the Gaussian mixture model that is used in the segmentation step. diff --git a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml index 44a31e5838..7bf1c7912e 100644 --- a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml +++ b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml @@ -26,12 +26,12 @@ The symbols used in the schema to specify e.g. dimensions of arrays. - + The dimensionality of the grid. - + Total number of voxels. @@ -45,26 +45,26 @@ Application definition for results of the CompositionSpace tool used in atom probe. - * `A. Saxena et al. <https://www.github.com/eisenforschung/CompositionSpacetool.git>`_ + * `A. Saxena et al. <https://www.github.com/eisenforschung/CompositionSpace.git>`_ - This is a draft application definition for the common NFDI-MatWerk/FAIRmat infrastructure + This is an application definition for the common NFDI-MatWerk/FAIRmat infrastructure use case IUC09 that explores how to improve the organization and results storage of the - CompositionSpace tool. + CompositionSpace software using NeXus. - + - + - + @@ -74,22 +74,22 @@ for if desired all the dependencies and libraries--> Configuration file that was used in this analysis. - + - - + + - + Step during which the point cloud is discretized to compute element-specific composition fields. Iontypes are atomically decomposed to correctly account for the multiplicity of each element that was ranged for each ion. Using a discretization grid that is larger than the average distance between reconstructed ion positions - reduces computational costs. This is the key idea of the CompositionSpace tool compared to other - methods for characterizing microstructural features. + reduces computational costs. This is the key idea of the CompositionSpace tool compared to other methods + used in atom probe for characterizing microstructural features using the ion position data directly. @@ -105,7 +105,7 @@ for if desired all the dependencies and libraries--> - + @@ -115,12 +115,12 @@ for if desired all the dependencies and libraries--> - + - + @@ -129,8 +129,8 @@ for if desired all the dependencies and libraries--> Position of each cell in Euclidean space. - - + + @@ -138,8 +138,8 @@ for if desired all the dependencies and libraries--> Discrete coordinate of each voxel. - - + + @@ -154,11 +154,11 @@ for if desired all the dependencies and libraries--> - Total number of weight (counts for discretization with a rectangular transfer - function) in each voxel. + Total number of weight (counts for discretization with a rectangular transfer function) + for the occupancy of each voxel with atoms. - + @@ -169,16 +169,16 @@ for if desired all the dependencies and libraries--> - Element-specific weight (counts for discretization with a rectangular transfer - function) in each voxel. + Element-specific weight (counts for discretization with a rectangular transfer function) + for the occupancy of each voxel with atoms of this element. - + - + Optional step during which the subsequent segmentation step is prepared to improve the segmentation. @@ -191,7 +191,8 @@ for if desired all the dependencies and libraries--> - + + Element identifier stored sorted in descending order of feature importance. @@ -221,12 +222,12 @@ for if desired all the dependencies and libraries--> - + Step during which the voxel set is segmented into voxel sets with different chemical composition. - + PCA in the chemical space (essentially composition correlation analyses). @@ -239,8 +240,8 @@ for if desired all the dependencies and libraries--> - - + + Explained variance values @@ -251,7 +252,8 @@ for if desired all the dependencies and libraries--> - Elements as the principal component analysis + Elements identifier matching those from ENTRY/voxelization/elementID as the + principal component analysis. @@ -283,7 +285,7 @@ for if desired all the dependencies and libraries--> y_pred return values of the computation. - + @@ -293,8 +295,9 @@ for if desired all the dependencies and libraries--> - - + + + Akaike information criterion values @@ -321,10 +324,11 @@ for if desired all the dependencies and libraries--> - + - Step during which the chemically segmented voxel sets are analyzed for their - spatial organization. + Step during which the chemically segmented voxel sets are analyzed for their spatial organization + into different spatial clusters of voxels in the same chemical set but representing individual object + not-necessarily watertight or topologically closed objects built from individual voxels. @@ -332,7 +336,7 @@ for if desired all the dependencies and libraries--> - + Respective DBScan clustering result for each segmentation/ic_opt case. @@ -352,7 +356,7 @@ for if desired all the dependencies and libraries--> - Raw labels return values + Raw label return values @@ -360,10 +364,13 @@ for if desired all the dependencies and libraries--> - Identified DBScan cluster identifier for each voxel. + Voxel identifier + + Using these identifiers correlated element-wise with the values in the label array + specifies for which voxel in the grid clusters from this process were found. - + diff --git a/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml b/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml index 21cc2c6c6d..843c1803fe 100644 --- a/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml +++ b/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml @@ -2,11 +2,11 @@ category: application doc: | Application definition for a configuration of the CompositionSpace tool used in atom probe. - * `A. Saxena et al. `_ + * `A. Saxena et al. `_ - This is a draft application definition for the common NFDI-MatWerk/FAIRmat infrastructure + This is an application definition for the common NFDI-MatWerk/FAIRmat infrastructure use case IUC09 that explores how to improve the organization and results storage of the - CompositionSpace tool. + CompositionSpace software using NeXus. type: group NXapm_compositionspace_config(NXobject): # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently @@ -14,6 +14,7 @@ NXapm_compositionspace_config(NXobject): exists: [min, 1, max, 1] definition(NX_CHAR): \@version(NX_CHAR): + exists: optional # because NXroot should already have the correct NeXus version used enumeration: [NXapm_compositionspace_config] config(NXobject): (NXidentifier): @@ -23,29 +24,40 @@ NXapm_compositionspace_config(NXobject): reconstruction(NXserialized): doc: | Specification of the tomographic reconstruction used for this analysis. - Typically, reconstructions in the field of atom probe tomography are communicated - via files which store at least reconstructed ion positions and mass-to-charge-state-ratio + Typically, reconstructions in the field of atom probe tomography are communicated via + files which store at least reconstructed ion positions and mass-to-charge-state-ratio values. Container files like HDF5 though can store multiple reconstructions. Therefore, the position and mass_to_charge concepts point to specific instances to use for this analysis. type(NX_CHAR): + exists: optional path(NX_CHAR): checksum(NX_CHAR): + exists: recommended algorithm(NX_CHAR): + exists: recommended position(NX_CHAR): doc: | - Name of the node which resolves the reconstructed ion position values to use for this analysis. - # mass_to_charge(NX_CHAR): + Name of the node which resolves the reconstructed + ion position values to use for this analysis. + mass_to_charge(NX_CHAR): + exists: optional + doc: | + Name of the node which resolves the mass-to-charge-state ratio + values for each reconstructed ion to use for this analysis. ranging(NXserialized): doc: | Specification of the ranging definitions used for this analysis. - Indices start from 1. The value 0 is reserved for the null model of unranged positions - whose iontype is unknown_type. The value 0 is alsoreserved for voxel outside the dataset. + Indices start from 1. The value 0 is reserved for the null model of unranged positions whose + iontype is unknown_type. The value 0 is also reserved for voxels that lie outside the dataset. type(NX_CHAR): + exists: optional path(NX_CHAR): checksum(NX_CHAR): + exists: recommended algorithm(NX_CHAR): + exists: recommended ranging_definitions(NX_CHAR): doc: | Name of the (parent) node directly below which the ranging definitions for (molecular) ions are stored. @@ -56,17 +68,19 @@ NXapm_compositionspace_config(NXobject): was ranged for each ion. edge_length(NX_NUMBER): doc: | - Edge length of cubic voxels for 3D grid that is used for discretizing the point cloud. + Edge length of cubic voxels building the 3D grid that is used for discretizing the point cloud. unit: NX_LENGTH autophase(NXprocess): doc: | - Optional step during which the subsequent segmentation step is prepared to improve the segmentation. + Optional step during which the subsequent segmentation step is prepared with the aim to eventually + reduce the dimensionality of the chemical space in which the machine learning model works. + + In this step a supervised reduction of the dimensionality of the chemical space is quantified using + the (Gini) feature importance of each element to suggest which columns of the composition matrix + should be taken for the subsequent segmentation step. use(NX_BOOLEAN): doc: | Was the automated phase assignment used? - This algorithm achieves a supervised reduction of the dimensionality of the chemical space - through an analysis of the (Gini) feature importance of each element for the subsequent - segmentation step. initial_guess(NX_POSINT): doc: | Estimated guess for which a Gaussian mixture model is evaluted to preprocess a result that @@ -79,16 +93,17 @@ NXapm_compositionspace_config(NXobject): The number of elements to use for reducing the dimensionality. unit: NX_UNITLESS random_forest_classifier(NXprocess): + exists: optional doc: | Configuration for the random forest classification model. segmentation(NXprocess): doc: | Step during which the voxel set is segmented into voxel sets with different chemical composition. pca(NXprocess): + exists: optional doc: | - A principal component analysis of the chemical space to guide a decision into how many - sets of voxels with different chemical composition the machine learning algorithm suggests - that the dataset should be analyzed as. + A principal component analysis of the chemical space to guide a decision into how many sets of voxels + with different chemical composition the machine learning algorithm suggests to split the voxel set. ic_opt(NXprocess): doc: | The decision is guided through the evalution of the information criterion minimization. @@ -99,6 +114,7 @@ NXapm_compositionspace_config(NXobject): chemical compositions. unit: NX_UNITLESS gaussian_mixture(NXprocess): + exists: optional doc: | Configuration for the Gaussian mixture model that is used in the segmentation step. clustering(NXprocess): diff --git a/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml b/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml index 3b5e492245..145fc6bfbf 100644 --- a/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml +++ b/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml @@ -2,17 +2,17 @@ category: application doc: | Application definition for results of the CompositionSpace tool used in atom probe. - * `A. Saxena et al. `_ + * `A. Saxena et al. `_ - This is a draft application definition for the common NFDI-MatWerk/FAIRmat infrastructure + This is an application definition for the common NFDI-MatWerk/FAIRmat infrastructure use case IUC09 that explores how to improve the organization and results storage of the - CompositionSpace tool. + CompositionSpace software using NeXus. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. - d: | + grid_dim: | The dimensionality of the grid. - c: | + n_voxels: | Total number of voxels. n_ions: | Total number of ions in the reconstructed dataset. @@ -23,14 +23,16 @@ NXapm_compositionspace_results(NXobject): exists: [min, 1, max, 1] definition(NX_CHAR): \@version(NX_CHAR): + exists: optional enumeration: [NXapm_compositionspace_results] # can be used for the name of the tool and version but also # for if desired all the dependencies and libraries - program(NXprogram): - exists: [min, 1, max, 1] + programID(NXprogram): + exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): \@url(NX_CHAR): + exists: optional (NXidentifier): exists: optional analysis_identifier(NX_UINT): @@ -40,22 +42,25 @@ NXapm_compositionspace_results(NXobject): doc: | Configuration file that was used in this analysis. type(NX_CHAR): + exists: optional path(NX_CHAR): algorithm(NX_CHAR): + exists: recommended checksum(NX_CHAR): + exists: recommended # results (NXuser): exists: optional voxelization(NXprocess): - exists: [min, 1, max, 1] + exists: [min, 0, max, 1] doc: | Step during which the point cloud is discretized to compute element-specific composition fields. Iontypes are atomically decomposed to correctly account for the multiplicity of each element that was ranged for each ion. Using a discretization grid that is larger than the average distance between reconstructed ion positions - reduces computational costs. This is the key idea of the CompositionSpace tool compared to other - methods for characterizing microstructural features. + reduces computational costs. This is the key idea of the CompositionSpace tool compared to other methods + used in atom probe for characterizing microstructural features using the ion position data directly. sequence_index(NX_POSINT): enumeration: [1] cg_grid(NXcg_grid): @@ -66,27 +71,27 @@ NXapm_compositionspace_results(NXobject): unit: NX_UNITLESS origin(NX_NUMBER): unit: NX_LENGTH - dim: (d,) + dim: (grid_dim,) symmetry: enumeration: [cubic] cell_dimensions(NX_NUMBER): unit: NX_LENGTH - dim: (d,) + dim: (grid_dim,) extent(NX_POSINT): unit: NX_UNITLESS - dim: (d,) + dim: (grid_dim,) identifier_offset(NX_INT): unit: NX_UNITLESS position(NX_NUMBER): doc: | Position of each cell in Euclidean space. unit: NX_LENGTH - dim: (c, d) + dim: (n_voxels, grid_dim) coordinate(NX_INT): doc: | Discrete coordinate of each voxel. unit: NX_DIMENSIONLESS - dim: (c, d) + dim: (n_voxels, grid_dim) # bounding box if needed voxel_identifier(NX_UINT): doc: | @@ -95,9 +100,10 @@ NXapm_compositionspace_results(NXobject): dim: (n_ions) weight(NX_NUMBER): doc: | - Total number of weight (counts for discretization with a rectangular transfer function) in each voxel. + Total number of weight (counts for discretization with a rectangular transfer function) + for the occupancy of each voxel with atoms. unit: NX_UNITLESS - dim: (c,) + dim: (n_voxels,) elementID(NXion): exists: [min, 1, max, infty] name(NX_CHAR): @@ -105,12 +111,12 @@ NXapm_compositionspace_results(NXobject): Chemical symbol of the element from the periodic table. weight(NX_NUMBER): doc: | - Element-specific weight (counts for discretization with a rectangular transfer function) in each voxel. + Element-specific weight (counts for discretization with a rectangular transfer function) + for the occupancy of each voxel with atoms of this element. unit: NX_UNITLESS - dim: (c,) - + dim: (n_voxels,) autophase(NXprocess): - exists: [min, 1, max, 1] + exists: [min, 0, max, 1] doc: | Optional step during which the subsequent segmentation step is prepared to improve the segmentation. sequence_index(NX_POSINT): @@ -118,7 +124,9 @@ NXapm_compositionspace_results(NXobject): result(NXdata): \@signal(NX_CHAR): \@axes(NX_CHAR): - \@AXISNAME(NX_CHAR): + \@AXISNAME_indices(NX_CHAR): + title(NX_CHAR): + exists: recommended axis_feature_identifier(NX_UINT): doc: | Element identifier stored sorted in descending order of feature importance. @@ -136,10 +144,11 @@ NXapm_compositionspace_results(NXobject): doc: | Axis caption segmentation(NXprocess): - exists: [min, 1, max, 1] + exists: [min, 0, max, 1] doc: | Step during which the voxel set is segmented into voxel sets with different chemical composition. pca(NXprocess): + exists: [min, 1, max, 1] doc: | PCA in the chemical space (essentially composition correlation analyses). sequence_index(NX_POSINT): @@ -147,8 +156,9 @@ NXapm_compositionspace_results(NXobject): result(NXdata): \@signal(NX_CHAR): \@axes(NX_CHAR): - \@AXISNAME(NX_CHAR): - # title(NX_CHAR) inherited from NXdata + \@AXISNAME_indices(NX_CHAR): + title(NX_CHAR): + exists: recommended axis_explained_variance(NX_FLOAT): doc: | Explained variance values @@ -156,7 +166,7 @@ NXapm_compositionspace_results(NXobject): dim: (i,) axis_pca_dimension(NX_UINT): doc: | - Elements as the principal component analysis + Elements identifier matching those from ENTRY/voxelization/elementID as the principal component analysis. unit: NX_UNITLESS dim: (i,) ic_opt(NXprocess): @@ -175,14 +185,17 @@ NXapm_compositionspace_results(NXobject): doc: | y_pred return values of the computation. unit: NX_UNITLESS - dim: (c,) + dim: (n_voxels,) result(NXdata): doc: | Information criterion as a function of number of n_ic_cluster aka dimensions. \@signal(NX_CHAR): \@axes(NX_CHAR): - \@AXISNAME(NX_CHAR): + \@AXISNAME_indices(NX_CHAR): + title(NX_CHAR): + exists: recommended axis_aic(NX_FLOAT): + exists: recommended doc: | Akaike information criterion values unit: NX_ANY @@ -198,15 +211,16 @@ NXapm_compositionspace_results(NXobject): unit: NX_UNITLESS dim: (i,) clustering(NXprocess): - exists: [min, 1, max, 1] + exists: [min, 0, max, 1] doc: | - Step during which the chemically segmented voxel sets are analyzed for their spatial organization. + Step during which the chemically segmented voxel sets are analyzed for their spatial organization + into different spatial clusters of voxels in the same chemical set but representing individual object + not-necessarily watertight or topologically closed objects built from individual voxels. sequence_index(NX_POSINT): enumeration: [4, 5] ic_opt(NXobject): doc: | Respective DBScan clustering result for each segmentation/ic_opt case. - exists: recommended cluster_analysisID(NXprocess): exists: [min, 0, max, infty] dbscanID(NXprocess): @@ -221,14 +235,17 @@ NXapm_compositionspace_results(NXobject): unit: NX_UNITLESS label(NX_INT): doc: | - Raw labels return values + Raw label return values unit: NX_UNITLESS dim: (k,) voxel(NX_UINT): doc: | - Identified DBScan cluster identifier for each voxel. + Voxel identifier + + Using these identifiers correlated element-wise with the values in the label array + specifies for which voxel in the grid clusters from this process were found. unit: NX_UNITLESS - dim: (c,) + dim: (n_voxels,) profiling(NXcs_profiling): exists: optional current_working_directory(NX_CHAR): From f40319cfe677a7c4cd318f0f1eb181ad6c025124 Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Thu, 4 Jul 2024 11:44:47 +0200 Subject: [PATCH 0769/1012] Add a reference to NXmpes from NXarpes (#153) * Add a reference to NXmpes to NXarpes * Make reference an actual rst link * Refer to `NXmpes_arpes` * modify reference to NXmpes_arpes --------- Co-authored-by: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> --- applications/NXarpes.nxdl.xml | 246 +++++++++++++++++-------------- applications/nyaml/NXarpes.yaml | 253 ++++++++++++++++++-------------- 2 files changed, 272 insertions(+), 227 deletions(-) diff --git a/applications/NXarpes.nxdl.xml b/applications/NXarpes.nxdl.xml index f9b17a1599..8d17472ad3 100644 --- a/applications/NXarpes.nxdl.xml +++ b/applications/NXarpes.nxdl.xml @@ -1,10 +1,10 @@ - - + + - - - This is an application definition for angular resolved photo electron spectroscopy. - - It has been drawn up with hemispherical electron analysers in mind. - - - - - NeXus convention is to use "entry1", "entry2", ... - for analysis software to locate each entry. - - - - - - Official NeXus NXDL schema to which this file conforms. - - - - - - - - - - - - - - - - - - - - - setting for the electron analyser lens - - - - - - - - - - - - - - - dial setting of the entrance slit - - - size of the entrance slit - - - energy of the electrons on the mean path of the analyser + + + This is an application definition for angular resolved photo electron spectroscopy. + + It has been drawn up with hemispherical electron analysers in mind. + + This definition is a legacy support for older NXarpes experiments. + There is, however, a newer definition to collect data & metadata + for general photoemission experiments, called :ref:NXmpes, + as well as a specialization for ARPES experiments, called :ref:NXmpes_arpes." + + + + + NeXus convention is to use "entry1", "entry2", ... + for analysis software to locate each entry. + + + + + + + Official NeXus NXDL schema to which this file conforms. + + + + - - todo: define more clearly - - - - Angular axis of the analyser data - which dimension the axis applies to is defined - using the normal NXdata methods. - - - - - Energy axis of the analyser data - which dimension the axis applies to is defined - using the normal NXdata methods. - - - - number of raw active elements in each dimension - - - - - - origin of rectangular region selected for readout - - - - - - size of rectangular region selected for readout - - - - - - - - - Descriptive name of sample - - + + + + + + + + + + + + + + + + + + setting for the electron analyser lens + + + + + + + + + + + + + + + + + dial setting of the entrance slit + + + + + size of the entrance slit + + + + + energy of the electrons on the mean path of the analyser + + + + + todo: define more clearly + + + + + Angular axis of the analyser data + which dimension the axis applies to is defined + using the normal NXdata methods. + + + + + Energy axis of the analyser data + which dimension the axis applies to is defined + using the normal NXdata methods. + + + + + number of raw active elements in each dimension + + + + + + + + origin of rectangular region selected for readout + + + + + + + + size of rectangular region selected for readout + + + + + + + + + + + Descriptive name of sample + + + + + - - diff --git a/applications/nyaml/NXarpes.yaml b/applications/nyaml/NXarpes.yaml index 746d91696f..fe211e13bf 100644 --- a/applications/nyaml/NXarpes.yaml +++ b/applications/nyaml/NXarpes.yaml @@ -3,6 +3,11 @@ doc: | This is an application definition for angular resolved photo electron spectroscopy. It has been drawn up with hemispherical electron analysers in mind. + + This definition is a legacy support for older NXarpes experiments. + There is, however, a newer definition to collect data & metadata + for general photoemission experiments, called :ref:NXmpes, + as well as a specialization for ARPES experiments, called :ref:NXmpes_arpes." type: group NXarpes(NXobject): (NXentry): @@ -89,14 +94,14 @@ NXarpes(NXobject): (NXdata): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 31232b8eac61f1e491926e74795efc8930591197ca40ea19d78788a866e7c6bf -# -# +# e784cdaecf56854c79a01b60711ee9c499ac4c8d12e5d7f72651309e8663baa3 +# +# # -# -# -# This is an application definition for angular resolved photo electron spectroscopy. -# -# It has been drawn up with hemispherical electron analysers in mind. -# -# -# -# -# NeXus convention is to use "entry1", "entry2", ... -# for analysis software to locate each entry. -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# setting for the electron analyser lens -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# dial setting of the entrance slit -# -# -# size of the entrance slit +# +# +# This is an application definition for angular resolved photo electron spectroscopy. +# +# It has been drawn up with hemispherical electron analysers in mind. +# +# This definition is a legacy support for older NXarpes experiments. +# There is, however, a newer definition to collect data & metadata +# for general photoemission experiments, called :ref:NXmpes, +# as well as a specialization for ARPES experiments, called :ref:NXmpes_arpes." +# +# +# +# +# NeXus convention is to use "entry1", "entry2", ... +# for analysis software to locate each entry. +# +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms. +# +# +# +# # -# -# energy of the electrons on the mean path of the analyser -# -# -# todo: define more clearly -# -# -# -# Angular axis of the analyser data -# which dimension the axis applies to is defined -# using the normal NXdata methods. -# -# -# -# -# Energy axis of the analyser data -# which dimension the axis applies to is defined -# using the normal NXdata methods. -# -# -# -# number of raw active elements in each dimension -# -# -# -# -# -# origin of rectangular region selected for readout -# -# -# -# -# -# size of rectangular region selected for readout -# -# -# -# -# -# -# -# -# Descriptive name of sample -# -# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# setting for the electron analyser lens +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# dial setting of the entrance slit +# +# +# +# +# size of the entrance slit +# +# +# +# +# energy of the electrons on the mean path of the analyser +# +# +# +# +# todo: define more clearly +# +# +# +# +# Angular axis of the analyser data +# which dimension the axis applies to is defined +# using the normal NXdata methods. +# +# +# +# +# Energy axis of the analyser data +# which dimension the axis applies to is defined +# using the normal NXdata methods. +# +# +# +# +# number of raw active elements in each dimension +# +# +# +# +# +# +# +# origin of rectangular region selected for readout +# +# +# +# +# +# +# +# size of rectangular region selected for readout +# +# +# +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# +# # -# -# # From f0ca58a085e12e1396133010454835c613980822 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 4 Jul 2024 12:24:47 +0200 Subject: [PATCH 0770/1012] Implemented @lukaspie suggestions --- contributed_definitions/NXimage_set.nxdl.xml | 240 ++++++++++-------- .../nyaml/NXimage_set.yaml | 234 +++++++++-------- 2 files changed, 262 insertions(+), 212 deletions(-) diff --git a/contributed_definitions/NXimage_set.nxdl.xml b/contributed_definitions/NXimage_set.nxdl.xml index c3f33bd683..4c24730417 100644 --- a/contributed_definitions/NXimage_set.nxdl.xml +++ b/contributed_definitions/NXimage_set.nxdl.xml @@ -33,46 +33,59 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> - Number of pixels per image in the slow direction (k equivalent to z). + Number of image points along the slow direction (k equivalent to z). - Number of pixels per image in the fast direction (j equivalent to y). + Number of image points along the fast direction (j equivalent to y). - Number of pixels per image in the fastest direction (i equivalent to x). + Number of image points along the fastest direction (i equivalent to x). Base class for reporting a set of images in real or reciprocal space. + Typically an image is understood as a discretized representation of intensity distribution that was + detected or simulated for which most often equidistantly spaced sampling is used. + The terms pixel and voxel identify the smallest discretization unit of such a representation. + Under these conditions pixel and voxel are polygonal or polyhedral unit cells of the underlying + tessellation of the region of interest within the reference space. + + If the sampling is not equispaced, the shape and size of pixel and voxel change but still their + reference space is tessellated. In this case the term (image) point is eventually a more appropriate + term to use. Therefore, all docstrings in this base class refer to points. + + This base class represents images generated from equispaced or non-equispaced sampling. + For images in reciprocal space in practice, complex numbers are encoded via some - formatted pair of real values. Typically, fast Algorithms for computing Fourier Transformations + formatted pair of real values. Typically, fast algorithms for computing Fourier transformations (FFT) are used to encode images in reciprocal (frequency) space. FFT libraries are used for implementing the key functionalities of these mathematical operations. - Different libraries use different representations and encoding of the image computed. - Details can be found in the respective sections of the typical FFT libraries + Different libraries use different representations and encoding of the images. + Details can be found in the respective sections of the typical FFT libraries documentations * `FFTW by M. Frigo and S. G. Johnson <https://www.fftw.org/fftw3_doc/Tutorial.html#Tutorial>`_ - * `Intel MKL by the Intel Co. <https://www.intel.com/content/www/us/en/docs/onemkl/developer-reference-c/2023-0/fourier-transform-functions.html>`_ + * `Intel MKL by the Intel Co. <https://www.intel.com/content/www/us/en/docs/onemkl/developer-reference-c/2024-2/fourier-transform-functions.html>`_ * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ + * `NFFT by the Chemnitz group <https://www-user.tu-chemnitz.de/~potts/nfft/>`_ for non-equispaced computations - Users are strongly advised to inspect carefully which specific conventions - their library uses to be able to store and modify the implementation of their - code such that the serialized representations, as it is detailed here for NeXus, - matches. + Users are strongly advised to inspect carefully which specific conventions their library uses + to enable storing and modifying the implementation of their code such that the serialized + representations as they are detailed here for NeXus match. - It is frequently the case that several images are combined using processing. In this case, + It is often the case that several images are combined using processing. In this case, the number of images which are combined in a collection is not necessarily the same - for each collection. The NXimage_set base class addresses this logical distinction through - the notation of image_identifier and group_identifier. - That is image identifier are always counting from offset in increments of one. Each image - is an own entity. A group may contain no, or several such images. + for each collection. The NXimage_set base class addresses this logical distinction + through the notation of image_identifier and group_identifier concepts. + That is image_identifier are always counting from offset in increments of one. + as each image is its own entity. By contrast, a group may contain no, or several images. + Consequently, group_identifier are not required to be contiguous. @@ -80,7 +93,7 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> - Resolvable data artifact (e.g. filename) from which all values in the :ref:`NXdata` + Resolvable data artifact (e.g. file) from which all values in the :ref:`NXdata` instances in this :ref:`NXimage_set` were loaded during parsing. Possibility to document from which specific other serialized resource as the source @@ -125,35 +138,35 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> One-dimensional image. - + - Real part of the image intensity per pixel. + Intensity for real-valued images as an alternative for real. + Magnitude of the image intensity for complex-valued data. - + - Imaginary part of the image intensity per pixel. + Real part of the image intensity per point. - + - Image intensity as a complex number as an alternative - to real and imag fields if values are stored as interleaved - complex numbers. + Imaginary part of the image intensity per point. - + - Magnitude of the image intensity. + Image intensity as a complex number as an alternative to real and + imaginary fields if values are stored as interleaved complex numbers. @@ -161,14 +174,14 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> - Pixel coordinate center along fastest direction. + Point coordinate along the fastest direction. - Coordinate along fastest direction. + Point coordinate along the fastest direction. @@ -177,38 +190,38 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> Two-dimensional image. - + - Real part of the image intensity per pixel. + Intensity for real-valued images as an alternative for real. + Magnitude of the image intensity for complex-valued data. - + - Imaginary part of the image intensity per pixel. + Real part of the image intensity per point. - + - Magnitude of the image intensity. + Imaginary part of the image intensity per point. - + - Image intensity as a complex number as an alternative - to real and imag fields if values are stored as interleaved - complex numbers. + Image intensity as a complex number as an alternative to real and + imaginary fields if values are stored as interleaved complex numbers. @@ -217,27 +230,27 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> - Pixel coordinate center along fast direction. + Point coordinate along the fast direction. - Coordinate along fast direction. + Point coordinate along the fast direction. - Pixel coordinate center along fastest direction. + Point coordinate along the fastest direction. - Coordinate along fastest direction. + Point coordinate along the fastest direction. @@ -246,9 +259,10 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> Three-dimensional image. - + - Real part of the image intensity per pixel. + Intensity for real-valued images as an alternative for real. + Magnitude of the image intensity for complex-valued data. @@ -256,9 +270,9 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> - + - Imaginary part of the image intensity per pixel. + Real part of the image intensity per point. @@ -266,9 +280,9 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> - + - Magnitude of the image intensity. + Imaginary part of the image intensity per point. @@ -276,11 +290,10 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> - + - Image intensity as a complex number as an alternative - to real and imag fields if values are stored as interleaved - complex numbers. + Image intensity as a complex number as an alternative to real and + imaginary fields if values are stored as interleaved complex numbers. @@ -290,40 +303,40 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> - Pixel coordinate center along slow direction. + Point coordinate along the slow direction. - Coordinate along slow direction. + Point coordinate along the slow direction. - Pixel coordinate center along fast direction. + Point coordinate along the fast direction. - Coordinate along fast direction. + Point coordinate along the fast direction. - Pixel coordinate center along fastest direction. + Point coordinate along the fastest direction. - Coordinate along fastest direction. + Point coordinate along the fastest direction. @@ -332,38 +345,38 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> Collection of one-dimensional images. - + - Real part of the image intensity per pixel. + Intensity for real-valued images as an alternative for real. + Magnitude of the image intensity for complex-valued data. - + - Imaginary part of the image intensity per pixel. + Real part of the image intensity per point. - + - Magnitude of the image intensity. + Imaginary part of the image intensity per point. - + - Image intensity as a complex number as an alternative - to real and imag fields if values are stored as interleaved - complex numbers. + Image intensity as a complex number as an alternative to real and + imaginary fields if values are stored as interleaved complex numbers. @@ -372,11 +385,16 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> - Group identifier for each image. + Group identifier + + + Group identifier + + @@ -387,20 +405,20 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> - Image identifier. + Image identifier - Pixel coordinate center along fastest direction. + Point coordinate along the fastest direction. - Coordinate along fastest direction. + Point coordinate along the fastest direction. @@ -409,9 +427,10 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> Collection of two-dimensional images. - + - Real part of the image intensity per pixel. + Intensity for real-valued images as an alternative for real. + Magnitude of the image intensity for complex-valued data. @@ -419,9 +438,9 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> - + - Imaginary part of the image intensity per pixel. + Real part of the image intensity per point. @@ -429,9 +448,9 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> - + - Magnitude of the image intensity. + Imaginary part of the image intensity per point. @@ -439,11 +458,10 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> - + - Image intensity as a complex number as an alternative - to real and imag fields if values are stored as interleaved - complex numbers. + Image intensity as a complex number as an alternative to real and + imaginary fields if values are stored as interleaved complex numbers. @@ -453,11 +471,16 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> - Group identifier for each image. + Group identifier + + + Group identifier + + @@ -474,27 +497,27 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> - Pixel coordinate center along fast direction. + Point coordinate along the fast direction. - Coordinate along fast direction. + Point coordinate along the fast direction. - Pixel coordinate center along fastest direction. + Point coordinate along the fastest direction. - Coordinate along fastest direction. + Point coordinate along the fastest direction. @@ -503,9 +526,10 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> Collection of three-dimensional images. - + - Real part of the image intensity per pixel. + Intensity for real-valued images as an alternative for real. + Magnitude of the image intensity for complex-valued data. @@ -514,9 +538,9 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> - + - Imaginary part of the image intensity per pixel. + Real part of the image intensity per point. @@ -525,9 +549,9 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> - + - Magnitude of the image intensity. + Imaginary part of the image intensity per point. @@ -536,11 +560,10 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> - + - Image intensity as a complex number as an alternative - to real and imag fields if values are stored as interleaved - complex numbers. + Image intensity as a complex number as an alternative to real and + imaginary fields if values are stored as interleaved complex numbers. @@ -551,11 +574,16 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> - Group identifier for each image. + Group identifier + + + Group identifier + + @@ -566,46 +594,46 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> - Image identifier. + Image identifier - Pixel coordinate center along slow direction. + Point coordinate along the slow direction. - Coordinate along slow direction. + Point coordinate along the slow direction. - Pixel coordinate center along fast direction. + Point coordinate along the fast direction. - Coordinate along fast direction. + Point coordinate along the fast direction. - Pixel coordinate center along fastest direction. + Point coordinate along the fastest direction. - Coordinate along fastest direction. + Point coordinate along the fastest direction. diff --git a/contributed_definitions/nyaml/NXimage_set.yaml b/contributed_definitions/nyaml/NXimage_set.yaml index dbaaf04da1..ccfa0b34d5 100644 --- a/contributed_definitions/nyaml/NXimage_set.yaml +++ b/contributed_definitions/nyaml/NXimage_set.yaml @@ -3,29 +3,42 @@ doc: - | Base class for reporting a set of images in real or reciprocal space. - | + Typically an image is understood as a discretized representation of intensity distribution that was + detected or simulated for which most often equidistantly spaced sampling is used. + The terms pixel and voxel identify the smallest discretization unit of such a representation. + Under these conditions pixel and voxel are polygonal or polyhedral unit cells of the underlying + tessellation of the region of interest within the reference space. + + If the sampling is not equispaced, the shape and size of pixel and voxel change but still their + reference space is tessellated. In this case the term (image) point is eventually a more appropriate + term to use. Therefore, all docstrings in this base class refer to points. + + This base class represents images generated from equispaced or non-equispaced sampling. + For images in reciprocal space in practice, complex numbers are encoded via some - formatted pair of real values. Typically, fast Algorithms for computing Fourier Transformations + formatted pair of real values. Typically, fast algorithms for computing Fourier transformations (FFT) are used to encode images in reciprocal (frequency) space. FFT libraries are used for implementing the key functionalities of these mathematical operations. - Different libraries use different representations and encoding of the image computed. - Details can be found in the respective sections of the typical FFT libraries + Different libraries use different representations and encoding of the images. + Details can be found in the respective sections of the typical FFT libraries documentations * `FFTW by M. Frigo and S. G. Johnson `_ - * `Intel MKL by the Intel Co. `_ + * `Intel MKL by the Intel Co. `_ * `cuFFT by the NVidia Co. `_ + * `NFFT by the Chemnitz group `_ for non-equispaced computations - Users are strongly advised to inspect carefully which specific conventions - their library uses to be able to store and modify the implementation of their - code such that the serialized representations, as it is detailed here for NeXus, - matches. + Users are strongly advised to inspect carefully which specific conventions their library uses + to enable storing and modifying the implementation of their code such that the serialized + representations as they are detailed here for NeXus match. - It is frequently the case that several images are combined using processing. In this case, + It is often the case that several images are combined using processing. In this case, the number of images which are combined in a collection is not necessarily the same - for each collection. The NXimage_set base class addresses this logical distinction through - the notation of image_identifier and group_identifier. - That is image identifier are always counting from offset in increments of one. Each image - is an own entity. A group may contain no, or several such images. + for each collection. The NXimage_set base class addresses this logical distinction + through the notation of image_identifier and group_identifier concepts. + That is image_identifier are always counting from offset in increments of one. + as each image is its own entity. By contrast, a group may contain no, or several images. + Consequently, group_identifier are not required to be contiguous. # for details about NXimage_r_set_diff see # https://github.com/FAIRmat-NFDI/nexus_definitions/commit/0682943baaef54d4a6386b5433f9721af6d3d81b # and here contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -33,11 +46,11 @@ symbols: n_img: | Number of images in the stack, for stacks the slowest direction. n_k: | - Number of pixels per image in the slow direction (k equivalent to z). + Number of image points along the slow direction (k equivalent to z). n_j: | - Number of pixels per image in the fast direction (j equivalent to y). + Number of image points along the fast direction (j equivalent to y). n_i: | - Number of pixels per image in the fastest direction (i equivalent to x). + Number of image points along the fastest direction (i equivalent to x). type: group NXimage_set(NXobject): (NXprocess): @@ -46,7 +59,7 @@ NXimage_set(NXobject): source(NXserialized): doc: - | - Resolvable data artifact (e.g. filename) from which all values in the :ref:`NXdata` + Resolvable data artifact (e.g. file) from which all values in the :ref:`NXdata` instances in this :ref:`NXimage_set` were loaded during parsing. - | Possibility to document from which specific other serialized resource as the source @@ -78,159 +91,162 @@ NXimage_set(NXobject): image_oned(NXdata): doc: | One-dimensional image. - real(NX_NUMBER): + intensity(NX_NUMBER): doc: | - Real part of the image intensity per pixel. + Intensity for real-valued images as an alternative for real. + Magnitude of the image intensity for complex-valued data. unit: NX_UNITLESS dim: (n_i,) - imag(NX_NUMBER): + real(NX_NUMBER): doc: | - Imaginary part of the image intensity per pixel. + Real part of the image intensity per point. unit: NX_UNITLESS dim: (n_i,) - intensity(NX_COMPLEX): + imag(NX_NUMBER): doc: | - Image intensity as a complex number as an alternative - to real and imag fields if values are stored as interleaved - complex numbers. + Imaginary part of the image intensity per point. unit: NX_UNITLESS dim: (n_i,) - magnitude(NX_NUMBER): + complex(NX_COMPLEX): doc: | - Magnitude of the image intensity. + Image intensity as a complex number as an alternative to real and + imaginary fields if values are stored as interleaved complex numbers. unit: NX_UNITLESS dim: (n_i,) axis_i(NX_NUMBER): doc: | - Pixel coordinate center along fastest direction. + Point coordinate along the fastest direction. unit: NX_LENGTH dim: (n_i,) \@long_name(NX_CHAR): doc: | - Coordinate along fastest direction. + Point coordinate along the fastest direction. image_twod(NXdata): doc: | Two-dimensional image. - real(NX_NUMBER): + intensity(NX_NUMBER): doc: | - Real part of the image intensity per pixel. + Intensity for real-valued images as an alternative for real. + Magnitude of the image intensity for complex-valued data. unit: NX_UNITLESS dim: (n_j, n_i) - imag(NX_NUMBER): + real(NX_NUMBER): doc: | - Imaginary part of the image intensity per pixel. + Real part of the image intensity per point. unit: NX_UNITLESS dim: (n_j, n_i) - magnitude(NX_NUMBER): + imag(NX_NUMBER): doc: | - Magnitude of the image intensity. + Imaginary part of the image intensity per point. unit: NX_UNITLESS dim: (n_j, n_i) - intensity(NX_COMPLEX): + complex(NX_COMPLEX): doc: | - Image intensity as a complex number as an alternative - to real and imag fields if values are stored as interleaved - complex numbers. + Image intensity as a complex number as an alternative to real and + imaginary fields if values are stored as interleaved complex numbers. unit: NX_UNITLESS dim: (n_j, n_i) axis_j(NX_NUMBER): doc: | - Pixel coordinate center along fast direction. + Point coordinate along the fast direction. unit: NX_LENGTH dim: (n_j,) \@long_name(NX_CHAR): doc: | - Coordinate along fast direction. + Point coordinate along the fast direction. axis_i(NX_NUMBER): doc: | - Pixel coordinate center along fastest direction. + Point coordinate along the fastest direction. unit: NX_LENGTH dim: (n_i,) \@long_name(NX_CHAR): doc: | - Coordinate along fastest direction. + Point coordinate along the fastest direction. image_threed(NXdata): doc: | Three-dimensional image. - real(NX_NUMBER): + intensity(NX_NUMBER): doc: | - Real part of the image intensity per pixel. + Intensity for real-valued images as an alternative for real. + Magnitude of the image intensity for complex-valued data. unit: NX_UNITLESS dim: (n_k, n_j, n_i) - imag(NX_NUMBER): + real(NX_NUMBER): doc: | - Imaginary part of the image intensity per pixel. + Real part of the image intensity per point. unit: NX_UNITLESS dim: (n_k, n_j, n_i) - magnitude(NX_NUMBER): + imag(NX_NUMBER): doc: | - Magnitude of the image intensity. + Imaginary part of the image intensity per point. unit: NX_UNITLESS dim: (n_k, n_j, n_i) - intensity(NX_COMPLEX): + complex(NX_COMPLEX): doc: | - Image intensity as a complex number as an alternative - to real and imag fields if values are stored as interleaved - complex numbers. + Image intensity as a complex number as an alternative to real and + imaginary fields if values are stored as interleaved complex numbers. unit: NX_UNITLESS dim: (n_k, n_j, n_i) axis_k(NX_NUMBER): doc: | - Pixel coordinate center along slow direction. + Point coordinate along the slow direction. unit: NX_LENGTH dim: (n_k,) \@long_name(NX_CHAR): doc: | - Coordinate along slow direction. + Point coordinate along the slow direction. axis_j(NX_NUMBER): doc: | - Pixel coordinate center along fast direction. + Point coordinate along the fast direction. unit: NX_LENGTH dim: (n_j,) \@long_name(NX_CHAR): doc: | - Coordinate along fast direction. + Point coordinate along the fast direction. axis_i(NX_NUMBER): doc: | - Pixel coordinate center along fastest direction. + Point coordinate along the fastest direction. unit: NX_LENGTH dim: (n_i,) \@long_name(NX_CHAR): doc: | - Coordinate along fastest direction. + Point coordinate along the fastest direction. stack_oned(NXdata): doc: | Collection of one-dimensional images. - real(NX_NUMBER): + intensity(NX_NUMBER): doc: | - Real part of the image intensity per pixel. + Intensity for real-valued images as an alternative for real. + Magnitude of the image intensity for complex-valued data. unit: NX_UNITLESS dim: (n_img, n_i) - imag(NX_NUMBER): + real(NX_NUMBER): doc: | - Imaginary part of the image intensity per pixel. + Real part of the image intensity per point. unit: NX_UNITLESS dim: (n_img, n_i) - magnitude(NX_NUMBER): + imag(NX_NUMBER): doc: | - Magnitude of the image intensity. + Imaginary part of the image intensity per point. unit: NX_UNITLESS dim: (n_img, n_i) - intensity(NX_COMPLEX): + complex(NX_COMPLEX): doc: | - Image intensity as a complex number as an alternative - to real and imag fields if values are stored as interleaved - complex numbers. + Image intensity as a complex number as an alternative to real and + imaginary fields if values are stored as interleaved complex numbers. unit: NX_UNITLESS dim: (n_img, n_i) group_identifier(NX_INT): doc: | - Group identifier for each image. + Group identifier unit: NX_UNITLESS dim: (n_img,) + \@long_name(NX_CHAR): + doc: | + Group identifier image_identifier(NX_INT): doc: | Image identifier @@ -238,46 +254,49 @@ NXimage_set(NXobject): dim: (n_img,) \@long_name(NX_CHAR): doc: | - Image identifier. + Image identifier axis_i(NX_NUMBER): doc: | - Pixel coordinate center along fastest direction. + Point coordinate along the fastest direction. unit: NX_LENGTH dim: (n_i,) \@long_name(NX_CHAR): doc: | - Coordinate along fastest direction. + Point coordinate along the fastest direction. stack_twod(NXdata): doc: | Collection of two-dimensional images. - real(NX_NUMBER): + intensity(NX_NUMBER): doc: | - Real part of the image intensity per pixel. + Intensity for real-valued images as an alternative for real. + Magnitude of the image intensity for complex-valued data. unit: NX_UNITLESS dim: (n_img, n_j, n_i) - imag(NX_NUMBER): + real(NX_NUMBER): doc: | - Imaginary part of the image intensity per pixel. + Real part of the image intensity per point. unit: NX_UNITLESS dim: (n_img, n_j, n_i) - magnitude(NX_NUMBER): + imag(NX_NUMBER): doc: | - Magnitude of the image intensity. + Imaginary part of the image intensity per point. unit: NX_UNITLESS dim: (n_img, n_j, n_i) - intensity(NX_COMPLEX): + complex(NX_COMPLEX): doc: | - Image intensity as a complex number as an alternative - to real and imag fields if values are stored as interleaved - complex numbers. + Image intensity as a complex number as an alternative to real and + imaginary fields if values are stored as interleaved complex numbers. unit: NX_UNITLESS dim: (n_img, n_j, n_i) group_identifier(NX_INT): doc: | - Group identifier for each image. + Group identifier unit: NX_UNITLESS dim: (n_img,) + \@long_name(NX_CHAR): + doc: | + Group identifier image_identifier(NX_INT): doc: | Image identifier @@ -288,51 +307,54 @@ NXimage_set(NXobject): Image identifier. axis_y(NX_NUMBER): doc: | - Pixel coordinate center along fast direction. + Point coordinate along the fast direction. unit: NX_LENGTH dim: (n_j,) \@long_name(NX_CHAR): doc: | - Coordinate along fast direction. + Point coordinate along the fast direction. axis_i(NX_NUMBER): doc: | - Pixel coordinate center along fastest direction. + Point coordinate along the fastest direction. unit: NX_LENGTH dim: (n_i,) \@long_name(NX_CHAR): doc: | - Coordinate along fastest direction. + Point coordinate along the fastest direction. stack_threed(NXdata): doc: | Collection of three-dimensional images. - real(NX_NUMBER): + intensity(NX_NUMBER): doc: | - Real part of the image intensity per pixel. + Intensity for real-valued images as an alternative for real. + Magnitude of the image intensity for complex-valued data. unit: NX_UNITLESS dim: (n_img, n_k, n_j, n_i) - imag(NX_NUMBER): + real(NX_NUMBER): doc: | - Imaginary part of the image intensity per pixel. + Real part of the image intensity per point. unit: NX_UNITLESS dim: (n_img, n_k, n_j, n_i) - magnitude(NX_NUMBER): + imag(NX_NUMBER): doc: | - Magnitude of the image intensity. + Imaginary part of the image intensity per point. unit: NX_UNITLESS dim: (n_img, n_k, n_j, n_i) - intensity(NX_COMPLEX): + complex(NX_COMPLEX): doc: | - Image intensity as a complex number as an alternative - to real and imag fields if values are stored as interleaved - complex numbers. + Image intensity as a complex number as an alternative to real and + imaginary fields if values are stored as interleaved complex numbers. unit: NX_UNITLESS dim: (n_img, n_k, n_j, n_i) group_identifier(NX_INT): doc: | - Group identifier for each image. + Group identifier unit: NX_UNITLESS dim: (n_img,) + \@long_name(NX_CHAR): + doc: | + Group identifier image_identifier(NX_INT): doc: | Image identifier @@ -340,28 +362,28 @@ NXimage_set(NXobject): dim: (n_img,) \@long_name(NX_CHAR): doc: | - Image identifier. + Image identifier axis_k(NX_NUMBER): doc: | - Pixel coordinate center along slow direction. + Point coordinate along the slow direction. unit: NX_LENGTH dim: (n_k,) \@long_name(NX_CHAR): doc: | - Coordinate along slow direction. + Point coordinate along the slow direction. axis_j(NX_NUMBER): doc: | - Pixel coordinate center along fast direction. + Point coordinate along the fast direction. unit: NX_LENGTH dim: (n_j,) \@long_name(NX_CHAR): doc: | - Coordinate along fast direction. + Point coordinate along the fast direction. axis_i(NX_NUMBER): doc: | - Pixel coordinate center along fastest direction. + Point coordinate along the fastest direction. unit: NX_LENGTH dim: (n_i,) \@long_name(NX_CHAR): doc: | - Coordinate along fastest direction. + Point coordinate along the fastest direction. From 8633744c763bd0a38b62890b9012cacbdc8cb124 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 4 Jul 2024 16:10:04 +0200 Subject: [PATCH 0771/1012] Refactoring of base class umbrella for description of a computer based on feedback from @RubelMozumder, @lukaspie, as well as @sanbrock --- .../NXcs_computer.nxdl.xml | 88 +++++++++++++++---- contributed_definitions/NXcs_cpu.nxdl.xml | 39 -------- contributed_definitions/NXcs_cpu_obj.nxdl.xml | 39 -------- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 48 ---------- contributed_definitions/NXcs_gpu.nxdl.xml | 39 -------- contributed_definitions/NXcs_gpu_obj.nxdl.xml | 39 -------- contributed_definitions/NXcs_gpu_sys.nxdl.xml | 47 ---------- contributed_definitions/NXcs_io_obj.nxdl.xml | 55 ------------ contributed_definitions/NXcs_io_sys.nxdl.xml | 38 -------- contributed_definitions/NXcs_mm_obj.nxdl.xml | 51 ----------- contributed_definitions/NXcs_mm_sys.nxdl.xml | 43 --------- .../NXms_score_results.nxdl.xml | 33 ------- .../nyaml/NXcs_computer.yaml | 56 +++++++++--- contributed_definitions/nyaml/NXcs_cpu.yaml | 54 ------------ .../nyaml/NXcs_cpu_obj.yaml | 12 --- .../nyaml/NXcs_cpu_sys.yaml | 21 ----- contributed_definitions/nyaml/NXcs_gpu.yaml | 54 ------------ .../nyaml/NXcs_gpu_obj.yaml | 12 --- .../nyaml/NXcs_gpu_sys.yaml | 20 ----- .../nyaml/NXcs_io_obj.yaml | 21 ----- .../nyaml/NXcs_io_sys.yaml | 13 --- .../nyaml/NXcs_mm_obj.yaml | 21 ----- .../nyaml/NXcs_mm_sys.yaml | 17 ---- .../nyaml/NXms_score_results.yaml | 43 --------- .../cgms-structure.rst | 14 +-- 25 files changed, 119 insertions(+), 798 deletions(-) delete mode 100644 contributed_definitions/NXcs_cpu.nxdl.xml delete mode 100644 contributed_definitions/NXcs_cpu_obj.nxdl.xml delete mode 100644 contributed_definitions/NXcs_cpu_sys.nxdl.xml delete mode 100644 contributed_definitions/NXcs_gpu.nxdl.xml delete mode 100644 contributed_definitions/NXcs_gpu_obj.nxdl.xml delete mode 100644 contributed_definitions/NXcs_gpu_sys.nxdl.xml delete mode 100644 contributed_definitions/NXcs_io_obj.nxdl.xml delete mode 100644 contributed_definitions/NXcs_io_sys.nxdl.xml delete mode 100644 contributed_definitions/NXcs_mm_obj.nxdl.xml delete mode 100644 contributed_definitions/NXcs_mm_sys.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcs_cpu.yaml delete mode 100644 contributed_definitions/nyaml/NXcs_cpu_obj.yaml delete mode 100644 contributed_definitions/nyaml/NXcs_cpu_sys.yaml delete mode 100644 contributed_definitions/nyaml/NXcs_gpu.yaml delete mode 100644 contributed_definitions/nyaml/NXcs_gpu_obj.yaml delete mode 100644 contributed_definitions/nyaml/NXcs_gpu_sys.yaml delete mode 100644 contributed_definitions/nyaml/NXcs_io_obj.yaml delete mode 100644 contributed_definitions/nyaml/NXcs_io_sys.yaml delete mode 100644 contributed_definitions/nyaml/NXcs_mm_obj.yaml delete mode 100644 contributed_definitions/nyaml/NXcs_mm_sys.yaml diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/contributed_definitions/NXcs_computer.nxdl.xml index 79a8accf15..c1e17114a3 100644 --- a/contributed_definitions/NXcs_computer.nxdl.xml +++ b/contributed_definitions/NXcs_computer.nxdl.xml @@ -22,13 +22,8 @@ # For further information, see http://www.nexusformat.org --> - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - Computer science description of a set of computing nodes. + Base class for reporting the description of a computer @@ -57,24 +52,87 @@ - - - Details about (classical) processing units (CPUs) or a system thereof. - - - + - Details about coprocessor/graphic cards/accelerator units or a system thereof. + Details about the system of processing units e.g. (classical) processing units (CPUs), + coprocessor, graphic cards, accelerator processing units or a system of these. + + + Granularizing the processing units. Typical examples, a desktop computer + with a single CPU one could describe using one instance of NXcircuit. + A dual-socket server one could describe using two instances NXcircuit + A server with two dual-socket server nodes one could describe with + four instances of NXcircuit surplus a field with their level in the hierarchy. + + + + General type of the processing unit + + + + + + + + + + + Given name + + + - + Details about the memory sub-system. + + + Granularizing the components of the memory system. + + + + Qualifier for the type of random access memory. + + + + + Total amount of data which the medium can hold. + + + + + Given name + + + - + Details about the I/O sub-system. + + + + Qualifier for the type of storage medium used. + + + + + + + + + + Total amount of data which the medium can hold. + + + + + Given name + + + diff --git a/contributed_definitions/NXcs_cpu.nxdl.xml b/contributed_definitions/NXcs_cpu.nxdl.xml deleted file mode 100644 index 13357448b3..0000000000 --- a/contributed_definitions/NXcs_cpu.nxdl.xml +++ /dev/null @@ -1,39 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a central processing unit (CPU) of a computer. - - - - Given name of the CPU. Users should be as specific as possible. - - - - diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml deleted file mode 100644 index 043fbeafaa..0000000000 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ /dev/null @@ -1,39 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a (central) processing unit (C)PU of a computer. - - - - Given name of the CPU. Users should be as specific as possible. - - - - diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml deleted file mode 100644 index 7a05ae8403..0000000000 --- a/contributed_definitions/NXcs_cpu_sys.nxdl.xml +++ /dev/null @@ -1,48 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a system of classical central processing units. - - For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - - - - Granularizing at the socket level. - - Typical examples follow: A desktop computer with a single CPU one - could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of - :ref:`NXcs_cpu_sys`. - A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` - inside one instance of :ref:`NXcs_cpu_sys`. - A server with two dual-socket server nodes one could describe - with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. - - - diff --git a/contributed_definitions/NXcs_gpu.nxdl.xml b/contributed_definitions/NXcs_gpu.nxdl.xml deleted file mode 100644 index 94adaf58ef..0000000000 --- a/contributed_definitions/NXcs_gpu.nxdl.xml +++ /dev/null @@ -1,39 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a graphic processing unit (GPU) of a computer. - - - - Given name of the GPU. Users should be as specific as possible. - - - - diff --git a/contributed_definitions/NXcs_gpu_obj.nxdl.xml b/contributed_definitions/NXcs_gpu_obj.nxdl.xml deleted file mode 100644 index d04ed9159a..0000000000 --- a/contributed_definitions/NXcs_gpu_obj.nxdl.xml +++ /dev/null @@ -1,39 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a graphic processing unit (GPU) of a computer. - - - - Given name of the GPU. Users should be as specific as possible. - - - - diff --git a/contributed_definitions/NXcs_gpu_sys.nxdl.xml b/contributed_definitions/NXcs_gpu_sys.nxdl.xml deleted file mode 100644 index e7fedabd41..0000000000 --- a/contributed_definitions/NXcs_gpu_sys.nxdl.xml +++ /dev/null @@ -1,47 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a system of coprocessor or graphics processors. - - - - Granularizing at the socket level. - - Typical examples follow: A desktop computer with a single GPU one - could describe using one instance of :ref:`NXcs_gpu_obj` inside one instance of - :ref:`NXcs_gpu_sys`. - A desktop computer with two GPUs one could describe using two instances - of :ref:`NXcs_gpu_obj` inside one instance of :ref:`NXcs_gpu_sys`. - A GPU server like nowadays used for artificial intelligence - one could describe as a system with n instances of :ref:`NXcs_gpu_obj` - in one :ref:`NXcs_gpu_sys` or :ref:`NXcs_cpu_sys`. - - - diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml deleted file mode 100644 index 372a84b4e5..0000000000 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a storage object in an input/output system. - - - - Qualifier for the type of storage medium used. - - - - - - - - - - Total amount of data which the medium can hold. - - - - - - Given name to the I/O unit. - - - - diff --git a/contributed_definitions/NXcs_io_sys.nxdl.xml b/contributed_definitions/NXcs_io_sys.nxdl.xml deleted file mode 100644 index 0caf528f04..0000000000 --- a/contributed_definitions/NXcs_io_sys.nxdl.xml +++ /dev/null @@ -1,38 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of system of a computer. - - In the same way how a hierarchy of instances of :ref:`NXcs_cpu_obj` or :ref:`NXcs_gpu_obj` - can be defined one can also define a hierarchy of :ref:`NXcs_mm_obj` and :ref:`NXcs_io_obj` - instances. - - - diff --git a/contributed_definitions/NXcs_mm_obj.nxdl.xml b/contributed_definitions/NXcs_mm_obj.nxdl.xml deleted file mode 100644 index dd4c69b4c5..0000000000 --- a/contributed_definitions/NXcs_mm_obj.nxdl.xml +++ /dev/null @@ -1,51 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a memory in a memory system. - - - - Qualifier for the type of random access memory. - - - - - - Total amount of data which the medium can hold. - - - - - - Given name to the I/O unit. - - - - diff --git a/contributed_definitions/NXcs_mm_sys.nxdl.xml b/contributed_definitions/NXcs_mm_sys.nxdl.xml deleted file mode 100644 index 70037fbeaa..0000000000 --- a/contributed_definitions/NXcs_mm_sys.nxdl.xml +++ /dev/null @@ -1,43 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a memory system of a computer. - - In the same way how a hierarchy of instances of :ref:`NXcs_cpu_obj` or :ref:`NXcs_gpu_obj` - can be defined one can also define a hierarchy of :ref:`NXcs_mm_obj` and :ref:`NXcs_io_obj` - instances. - - - - How much physical memory does the system provide. - - - - diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index fa7e9c20e9..40b2e54356 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -646,39 +646,6 @@ exists: optional--> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/nyaml/NXcs_computer.yaml b/contributed_definitions/nyaml/NXcs_computer.yaml index 01cf37da32..b2030f9235 100644 --- a/contributed_definitions/nyaml/NXcs_computer.yaml +++ b/contributed_definitions/nyaml/NXcs_computer.yaml @@ -1,9 +1,6 @@ category: base doc: | - Computer science description of a set of computing nodes. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. + Base class for reporting the description of a computer type: group NXcs_computer(NXobject): name(NX_CHAR): @@ -25,15 +22,52 @@ NXcs_computer(NXobject): Ideally a (globally) unique persistent identifier of the computer, i.e. the Universally Unique Identifier (UUID) of the computing node. # when it comes to performance monitoring - (NXcs_cpu_sys): + processing(NXobject): doc: | - Details about (classical) processing units (CPUs) or a system thereof. - (NXcs_gpu_sys): - doc: | - Details about coprocessor/graphic cards/accelerator units or a system thereof. - (NXcs_mm_sys): + Details about the system of processing units e.g. (classical) processing units (CPUs), + coprocessor, graphic cards, accelerator processing units or a system of these. + (NXcircuit): + doc: | + Granularizing the processing units. Typical examples, a desktop computer + with a single CPU one could describe using one instance of NXcircuit. + A dual-socket server one could describe using two instances NXcircuit + A server with two dual-socket server nodes one could describe with + four instances of NXcircuit surplus a field with their level in the hierarchy. + type(NX_CHAR): + doc: | + General type of the processing unit + enumeration: [cpu, gpu, fpga, other] + name(NX_CHAR): + doc: | + Given name + memory(NXobject): doc: | Details about the memory sub-system. - (NXcs_io_sys): + (NXcircuit): + doc: | + Granularizing the components of the memory system. + technology(NX_CHAR): + doc: | + Qualifier for the type of random access memory. + max_physical_capacity(NX_NUMBER): + doc: | + Total amount of data which the medium can hold. + unit: NX_ANY + name(NX_CHAR): + doc: | + Given name + storage(NXobject): doc: | Details about the I/O sub-system. + ioID(NXcircuit): + technology(NX_CHAR): + doc: | + Qualifier for the type of storage medium used. + enumeration: [solid_state_disk, hard_disk, tape] + max_physical_capacity(NX_NUMBER): + doc: | + Total amount of data which the medium can hold. + unit: NX_ANY # NX_BIT + name(NX_CHAR): + doc: | + Given name diff --git a/contributed_definitions/nyaml/NXcs_cpu.yaml b/contributed_definitions/nyaml/NXcs_cpu.yaml deleted file mode 100644 index 2160aa3dd4..0000000000 --- a/contributed_definitions/nyaml/NXcs_cpu.yaml +++ /dev/null @@ -1,54 +0,0 @@ -category: base -doc: | - Computer science description of a central processing unit (CPU) of a computer. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXcs_cpu(NXobject): - name: - doc: | - Given name of the CPU. Users should be as specific as possible. - (NXfabrication): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 7acc57d7e709c31f39bfe27c48566ae19f040f70c491c764259dab65ee1a36b2 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Computer science description of a central processing unit (CPU) of a computer. -# -# -# -# Given name of the CPU. Users should be as specific as possible. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcs_cpu_obj.yaml b/contributed_definitions/nyaml/NXcs_cpu_obj.yaml deleted file mode 100644 index dfa4c4dbdb..0000000000 --- a/contributed_definitions/nyaml/NXcs_cpu_obj.yaml +++ /dev/null @@ -1,12 +0,0 @@ -category: base -doc: | - Computer science description of a (central) processing unit (C)PU of a computer. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXcs_cpu_obj(NXcircuit): - name(NX_CHAR): - doc: | - Given name of the CPU. Users should be as specific as possible. - (NXfabrication): diff --git a/contributed_definitions/nyaml/NXcs_cpu_sys.yaml b/contributed_definitions/nyaml/NXcs_cpu_sys.yaml deleted file mode 100644 index 5eaf8f0eab..0000000000 --- a/contributed_definitions/nyaml/NXcs_cpu_sys.yaml +++ /dev/null @@ -1,21 +0,0 @@ -category: base -doc: | - Computer science description of a system of classical central processing units. - - For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXcs_cpu_sys(NXobject): - cpuID(NXcs_cpu_obj): - doc: | - Granularizing at the socket level. - - Typical examples follow: A desktop computer with a single CPU one - could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of - :ref:`NXcs_cpu_sys`. - A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` - inside one instance of :ref:`NXcs_cpu_sys`. - A server with two dual-socket server nodes one could describe - with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. diff --git a/contributed_definitions/nyaml/NXcs_gpu.yaml b/contributed_definitions/nyaml/NXcs_gpu.yaml deleted file mode 100644 index 573f14f29c..0000000000 --- a/contributed_definitions/nyaml/NXcs_gpu.yaml +++ /dev/null @@ -1,54 +0,0 @@ -category: base -doc: | - Computer science description of a graphic processing unit (GPU) of a computer. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXcs_gpu(NXobject): - name: - doc: | - Given name of the GPU. Users should be as specific as possible. - (NXfabrication): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 739989c53a5e4fe43a63035920aab39528e8933c2ec9e35465e04e40d69d9a7c -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Computer science description of a graphic processing unit (GPU) of a computer. -# -# -# -# Given name of the GPU. Users should be as specific as possible. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcs_gpu_obj.yaml b/contributed_definitions/nyaml/NXcs_gpu_obj.yaml deleted file mode 100644 index 64af7ee846..0000000000 --- a/contributed_definitions/nyaml/NXcs_gpu_obj.yaml +++ /dev/null @@ -1,12 +0,0 @@ -category: base -doc: | - Computer science description of a graphic processing unit (GPU) of a computer. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXcs_gpu_obj(NXcircuit): - name(NX_CHAR): - doc: | - Given name of the GPU. Users should be as specific as possible. - (NXfabrication): diff --git a/contributed_definitions/nyaml/NXcs_gpu_sys.yaml b/contributed_definitions/nyaml/NXcs_gpu_sys.yaml deleted file mode 100644 index dee199330c..0000000000 --- a/contributed_definitions/nyaml/NXcs_gpu_sys.yaml +++ /dev/null @@ -1,20 +0,0 @@ -category: base -doc: | - Computer science description of a system of coprocessor or graphics processors. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXcs_gpu_sys(NXobject): - gpuID(NXcs_gpu_obj): - doc: | - Granularizing at the socket level. - - Typical examples follow: A desktop computer with a single GPU one - could describe using one instance of :ref:`NXcs_gpu_obj` inside one instance of - :ref:`NXcs_gpu_sys`. - A desktop computer with two GPUs one could describe using two instances - of :ref:`NXcs_gpu_obj` inside one instance of :ref:`NXcs_gpu_sys`. - A GPU server like nowadays used for artificial intelligence - one could describe as a system with n instances of :ref:`NXcs_gpu_obj` - in one :ref:`NXcs_gpu_sys` or :ref:`NXcs_cpu_sys`. diff --git a/contributed_definitions/nyaml/NXcs_io_obj.yaml b/contributed_definitions/nyaml/NXcs_io_obj.yaml deleted file mode 100644 index 24b557c3db..0000000000 --- a/contributed_definitions/nyaml/NXcs_io_obj.yaml +++ /dev/null @@ -1,21 +0,0 @@ -category: base -doc: | - Computer science description of a storage object in an input/output system. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXcs_io_obj(NXcircuit): - technology(NX_CHAR): - doc: | - Qualifier for the type of storage medium used. - enumeration: [solid_state_disk, hard_disk, tape] - max_physical_capacity(NX_NUMBER): - doc: | - Total amount of data which the medium can hold. - unit: NX_ANY - # NX_BIT - name(NX_CHAR): - doc: | - Given name to the I/O unit. - (NXfabrication): diff --git a/contributed_definitions/nyaml/NXcs_io_sys.yaml b/contributed_definitions/nyaml/NXcs_io_sys.yaml deleted file mode 100644 index b62768a234..0000000000 --- a/contributed_definitions/nyaml/NXcs_io_sys.yaml +++ /dev/null @@ -1,13 +0,0 @@ -category: base -doc: | - Computer science description of system of a computer. - - In the same way how a hierarchy of instances of :ref:`NXcs_cpu_obj` or :ref:`NXcs_gpu_obj` - can be defined one can also define a hierarchy of :ref:`NXcs_mm_obj` and :ref:`NXcs_io_obj` - instances. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXcs_io_sys(NXobject): - ioID(NXcs_io_obj): diff --git a/contributed_definitions/nyaml/NXcs_mm_obj.yaml b/contributed_definitions/nyaml/NXcs_mm_obj.yaml deleted file mode 100644 index f28c2ab95f..0000000000 --- a/contributed_definitions/nyaml/NXcs_mm_obj.yaml +++ /dev/null @@ -1,21 +0,0 @@ -category: base -doc: | - Computer science description of a memory in a memory system. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXcs_mm_obj(NXcircuit): - technology(NX_CHAR): - doc: | - Qualifier for the type of random access memory. - # make an enumeration - max_physical_capacity(NX_NUMBER): - doc: | - Total amount of data which the medium can hold. - unit: NX_ANY - # NX_BIT - name(NX_CHAR): - doc: | - Given name to the I/O unit. - (NXfabrication): diff --git a/contributed_definitions/nyaml/NXcs_mm_sys.yaml b/contributed_definitions/nyaml/NXcs_mm_sys.yaml deleted file mode 100644 index 60293e362b..0000000000 --- a/contributed_definitions/nyaml/NXcs_mm_sys.yaml +++ /dev/null @@ -1,17 +0,0 @@ -category: base -doc: | - Computer science description of a memory system of a computer. - - In the same way how a hierarchy of instances of :ref:`NXcs_cpu_obj` or :ref:`NXcs_gpu_obj` - can be defined one can also define a hierarchy of :ref:`NXcs_mm_obj` and :ref:`NXcs_io_obj` - instances. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXcs_mm_sys(NXobject): - total_physical_memory(NX_NUMBER): - doc: | - How much physical memory does the system provide. - unit: NX_ANY - # NX_BIT diff --git a/contributed_definitions/nyaml/NXms_score_results.yaml b/contributed_definitions/nyaml/NXms_score_results.yaml index 56b70c7a79..acc6f3dff2 100644 --- a/contributed_definitions/nyaml/NXms_score_results.yaml +++ b/contributed_definitions/nyaml/NXms_score_results.yaml @@ -531,49 +531,6 @@ NXms_score_results(NXobject): number_of_gpus(NX_POSINT): (NXcs_computer): exists: recommended - name: - exists: recommended - operating_system: - \@version: - uuid: - exists: optional - (NXcs_cpu): - exists: ['min', '0', 'max', 'unbounded'] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_gpu): - exists: ['min', '0', 'max', 'unbounded'] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_mm_sys): - exists: ['min', '0', 'max', '1'] - total_physical_memory(NX_NUMBER): - (NXcs_io_sys): - exists: ['min', '0', 'max', '1'] - (NXcs_io_obj): - exists: ['min', '1', 'max', 'unbounded'] - technology: - max_physical_capacity(NX_NUMBER): - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional (NXcs_profiling_event): start_time(NX_DATE_TIME): exists: optional diff --git a/manual/source/classes/contributed_definitions/cgms-structure.rst b/manual/source/classes/contributed_definitions/cgms-structure.rst index f7a4629fe0..a802096997 100644 --- a/manual/source/classes/contributed_definitions/cgms-structure.rst +++ b/manual/source/classes/contributed_definitions/cgms-structure.rst @@ -220,16 +220,4 @@ input parameters and to summarize its performance statistics: A base class for documenting profiling/benchmark for an algorithm or computational step. :ref:`NXcs_computer`: - A base class for documenting a computer. - - :ref:`NXcs_cpu_sys`, :ref:`NXcs_cpu_obj`, :ref:`NXcs_cpu`: - Base classes for documenting a central processing unit. - - :ref:`NXcs_gpu_sys`, :ref:`NXcs_gpu_obj`, :ref:`NXcs_gpu`: - Base classes for documenting a graphical processing unit / accelerator. - - :ref:`NXcs_mm_sys`, :ref:`NXcs_mm_obj`: - Base classes for documenting the (main) memory (sub-)system. - - :ref:`NXcs_io_sys`, :ref:`NXcs_io_obj`: - Base classes for documenting the input/output system. + Base class for describing a computer and its components. From 232cc40551d78905f3f63dd3cd04067d02ec604a Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 4 Jul 2024 16:40:31 +0200 Subject: [PATCH 0772/1012] Final minor fixes --- contributed_definitions/NXcs_computer.nxdl.xml | 18 +++++++++++++----- .../nyaml/NXcs_computer.yaml | 14 +++++++++----- 2 files changed, 22 insertions(+), 10 deletions(-) diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/contributed_definitions/NXcs_computer.nxdl.xml index c1e17114a3..f5b0d3fbae 100644 --- a/contributed_definitions/NXcs_computer.nxdl.xml +++ b/contributed_definitions/NXcs_computer.nxdl.xml @@ -85,7 +85,7 @@ - Details about the memory sub-system. + Details about the memory system. @@ -95,8 +95,12 @@ Qualifier for the type of random access memory. + + + + - + Total amount of data which the medium can hold. @@ -110,9 +114,12 @@ - Details about the I/O sub-system. + Details about the I/O system. - + + + Granularizing the components of the I/O system. + Qualifier for the type of storage medium used. @@ -123,7 +130,7 @@ - + Total amount of data which the medium can hold. @@ -135,4 +142,5 @@ + diff --git a/contributed_definitions/nyaml/NXcs_computer.yaml b/contributed_definitions/nyaml/NXcs_computer.yaml index b2030f9235..23cc23cc51 100644 --- a/contributed_definitions/nyaml/NXcs_computer.yaml +++ b/contributed_definitions/nyaml/NXcs_computer.yaml @@ -42,14 +42,15 @@ NXcs_computer(NXobject): Given name memory(NXobject): doc: | - Details about the memory sub-system. + Details about the memory system. (NXcircuit): doc: | Granularizing the components of the memory system. technology(NX_CHAR): doc: | Qualifier for the type of random access memory. - max_physical_capacity(NX_NUMBER): + enumeration: [ddr4, ddr5] + max_physical_capacity(NX_POSINT): doc: | Total amount of data which the medium can hold. unit: NX_ANY @@ -58,16 +59,19 @@ NXcs_computer(NXobject): Given name storage(NXobject): doc: | - Details about the I/O sub-system. - ioID(NXcircuit): + Details about the I/O system. + (NXcircuit): + doc: | + Granularizing the components of the I/O system. technology(NX_CHAR): doc: | Qualifier for the type of storage medium used. enumeration: [solid_state_disk, hard_disk, tape] - max_physical_capacity(NX_NUMBER): + max_physical_capacity(NX_POSINT): doc: | Total amount of data which the medium can hold. unit: NX_ANY # NX_BIT name(NX_CHAR): doc: | Given name + # NXcircuit inherits fabrication from NXcomponent From fa24bbfe87f8fa00cd715513bf93654298ce3e3b Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 4 Jul 2024 16:42:48 +0200 Subject: [PATCH 0773/1012] done --- contributed_definitions/NXcs_computer.nxdl.xml | 4 ++-- contributed_definitions/nyaml/NXcs_computer.yaml | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/contributed_definitions/NXcs_computer.nxdl.xml index f5b0d3fbae..6303eb3ae7 100644 --- a/contributed_definitions/NXcs_computer.nxdl.xml +++ b/contributed_definitions/NXcs_computer.nxdl.xml @@ -91,7 +91,7 @@ Granularizing the components of the memory system. - + Qualifier for the type of random access memory. @@ -120,7 +120,7 @@ Granularizing the components of the I/O system. - + Qualifier for the type of storage medium used. diff --git a/contributed_definitions/nyaml/NXcs_computer.yaml b/contributed_definitions/nyaml/NXcs_computer.yaml index 23cc23cc51..1517407fea 100644 --- a/contributed_definitions/nyaml/NXcs_computer.yaml +++ b/contributed_definitions/nyaml/NXcs_computer.yaml @@ -46,7 +46,7 @@ NXcs_computer(NXobject): (NXcircuit): doc: | Granularizing the components of the memory system. - technology(NX_CHAR): + type(NX_CHAR): doc: | Qualifier for the type of random access memory. enumeration: [ddr4, ddr5] @@ -63,7 +63,7 @@ NXcs_computer(NXobject): (NXcircuit): doc: | Granularizing the components of the I/O system. - technology(NX_CHAR): + type(NX_CHAR): doc: | Qualifier for the type of storage medium used. enumeration: [solid_state_disk, hard_disk, tape] From 2f06550f262fec49e9b6d9d261a26dc1fedb7472 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 4 Jul 2024 16:44:18 +0200 Subject: [PATCH 0774/1012] fix mpes-structure.rst --- manual/source/mpes-structure.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/manual/source/mpes-structure.rst b/manual/source/mpes-structure.rst index afeb2fb061..e0091995cb 100644 --- a/manual/source/mpes-structure.rst +++ b/manual/source/mpes-structure.rst @@ -32,5 +32,5 @@ Here's a list of application definitions related to photoemission spectroscopy: :ref:`NXmpes_arpes`: An appdef for angle-resolved photoemission spectroscopy (ARPES) experiments. - :ref:`NXxps`: + :ref:`NXxps`: An application definition for XPS/UPS measurements. \ No newline at end of file From fe64f3d747a6d2ff0ef91967111ef8d9d8ff293a Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 4 Jul 2024 18:17:59 +0200 Subject: [PATCH 0775/1012] Remove previous deleted file --- .../NXapm_composition_space_results.yaml | 872 ------------------ 1 file changed, 872 deletions(-) delete mode 100644 contributed_definitions/nyaml/NXapm_composition_space_results.yaml diff --git a/contributed_definitions/nyaml/NXapm_composition_space_results.yaml b/contributed_definitions/nyaml/NXapm_composition_space_results.yaml deleted file mode 100644 index 472d88f33b..0000000000 --- a/contributed_definitions/nyaml/NXapm_composition_space_results.yaml +++ /dev/null @@ -1,872 +0,0 @@ -category: application -doc: | - Results of a run with Alaukik Saxena's composition space tool. - - This is an initial draft application definition for the common NFDI-MatWerk, - FAIRmat infrastructure use case IUC09 how to improve the organization and - results storage of the composition space tool and make these data at the - same time directly understandable for research data management systems - like NOMAD Oasis. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_voxel: | - Number of voxel of discretized domain for analyzed part of the dataset. - d: | - The dimensionality of the grid. - c: | - The cardinality or total number of cells/grid points. - n_clst_dict: | - Number of terms in the composition clustering dictionary - n_spat_dict: | - Number of terms in the position clustering dictionary -type: group -NXapm_composition_space_results(NXobject): - - # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently - (NXentry): - exists: ['min', '1', 'max', '1'] - definition(NX_CHAR): - \@version: - type: NX_CHAR - enumeration: [NXapm_composition_space_results] - - # can be used for the name of the tool and version but also - # for if desired all the dependencies and libraries - (NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - job_pyiron_identifier(NX_CHAR): - exists: recommended - doc: | - TBD, maybe how to link between pyiron state tracking and app state tracking. - description(NX_CHAR): - exists: optional - doc: | - Disencouraged place for free-text for e.g. comments. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. when composition space tool was started as a process. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and composition space tool exited as a process. - - # config - config(NXserialized): - doc: | - The path and name of the config file that was used for this analysis. - TBD, this can be e.g. Alaukik's YAML file for composition space. - type(NX_CHAR): - path(NX_CHAR): - algorithm(NX_CHAR): - checksum(NX_CHAR): - reconstruction(NXserialized): - doc: | - Details about the file (technology partner or community format) - from which reconstructed ion positions were loaded. - type(NX_CHAR): - path(NX_CHAR): - algorithm(NX_CHAR): - checksum(NX_CHAR): - ranging(NXserialized): - doc: | - Details about the file (technology partner or community format) - from which ranging definitions were loaded which detail how to - map mass-to-charge-state ratios on iontypes. - type(NX_CHAR): - path(NX_CHAR): - algorithm(NX_CHAR): - checksum(NX_CHAR): - - # results - results_path(NX_CHAR): - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - status(NX_CHAR): - doc: | - A statement whether the executable managed to process the analysis - or failed prematurely. This status is written to the results file after the - end_time at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - enumeration: [success, failure] - (NXuser): - exists: recommended - doc: | - If used, contact information and eventually details - of at least the person who performed this analysis. - name(NX_CHAR): - exists: recommended - affiliation(NX_CHAR): - exists: optional - (NXidentifier): - exists: optional - role(NX_CHAR): - exists: optional - (NXcoordinate_system_set): - doc: | - Details about coordinate systems (reference frames) used. In atom probe several coordinate - systems have to be distinguished. Names of instances of such :ref:`NXcoordinate_system` - should be documented explicitly and doing so by picking from the - following controlled set of names: - - * composition_space - * lab - * specimen - * laser - * instrument - * detector - * recon - - The aim of this convention is to support users with contextualizing which reference - frame each instance (coordinate system) is. If needed, instances of :ref:`NXtransformations` - are used to detail the explicit affine transformations whereby one can convert - representations between different reference frames. - Inspect :ref:`NXtransformations` for further details. - (NXcoordinate_system): - (NXtransformations): - - # add further fields coming from using the charge state recovery - # workflow from the ifes_apt_tc_data_modeling library - voxelization(NXprocess): - sequence_index(NX_POSINT): - enumeration: [1] - - # specify the grid your using and for each ion in which cell i.e. voxel it is - # one could also have a more sophisticated data model where there is some - # fuzziness i.e. if an ML/AI model returns multiple values or a probability - # how likely an ion is in which voxel, for this - # inspect the example of the NXem_ebsd application definition - (NXcg_grid): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - enumeration: [1, 2, 3] - cardinality(NX_POSINT): - unit: NX_UNITLESS - - # default behaviour, if no coordinate system defined, unclear - # if one coordinate system is defined the origin is defined in this cs - origin(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, d]] - symmetry: - enumeration: [cubic] - cell_dimensions(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, d]] - extent(NX_POSINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, d]] - (NXtransformations): - exists: recommended - doc: | - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - - position(NX_NUMBER): - unit: NX_LENGTH - doc: | - Position of each cell in Euclidean space. - dimensions: - rank: 2 - dim: [[1, c], [2, d]] - coordinate(NX_INT): - exists: optional - unit: NX_DIMENSIONLESS - dimensions: - rank: 2 - dim: [[1, c], [2, d]] - - # bounding box if needed - voxel_identifier(NX_UINT): - unit: NX_UNITLESS - doc: | - For each ion, the identifier of the voxel in which the ion is located. - dimensions: - rank: 1 - dim: [[1, n_ions]] - (NXion): - exists: ['min', '0', 'max', 'unbounded'] - name: - composition(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, n_voxel]] - clustering_composition_space(NXprocess): - doc: | - In Alaukik's tool the GMM step. - sequence_index(NX_POSINT): - enumeration: [2] - cluster_dict_keyword: - doc: | - The keywords of the dictionary of distinguished compositionally- - defined cluster, e.g. the phases. Examples for keywords could be - phase1, phase2, and so one and so forth. - dimensions: - rank: 1 - dim: [[1, n_clst_dict]] - cluster_dict_value(NX_UINT): - unit: NX_UNITLESS - doc: | - Resolves for each keyword in cluster_dict which integer is used to - label something that it belongs or is assumed to represent this - cluster. - dimensions: - rank: 1 - dim: [[1, n_clst_dict]] - - # again for fuzzy or probabilistic multi solution approaches see NXem_ebsd - cluster_identifier(NX_UINT): - unit: NX_UNITLESS - doc: | - For example if the voxel grid is used to report that there - are voxels which are assumed to represent volume of either phase1 - or phase2, the cluster_dict_keyword would be a list with two names - phase1 and phase2, respectively. The cluster_dict_value would be a - list of e.g. integers 1 and 2. These could be used to build an - array with as many entries as there are voxel and store in this array - the respective value to encode which phase is assumed for each voxel. - dimensions: - rank: 1 - dim: [[1, n_voxel]] - - # use the fact that with e.g. XDMF one can on-the-fly reinterpret - # a 1d array to represent an explicit 3d grid - # default plots would be nice could directly be integrated in the results file - clustering_real_space(NXprocess): - doc: | - In Alaukik's tool the DBScan step after the GMM step. - sequence_index(NX_POSINT): - enumeration: [3] - cluster_dict_keyword: - doc: | - The keywords of the dictionary of distinguished spatially-contiguous - clusters. Examples for keywords could be precipitate1, precipitate2, - and so one and so forth. - dimensions: - rank: 1 - dim: [[1, n_spat_dict]] - cluster_dict_value(NX_UINT): - unit: NX_UNITLESS - doc: | - Resolves for each keyword in cluster_dict which integer is used to - label something that it belongs or is assumed to represent this - cluster. - dimensions: - rank: 1 - dim: [[1, n_spat_dict]] - - # again for fuzzy or probabilistic multi solution approaches see NXem_ebsd - cluster_identifier(NX_UINT): - unit: NX_UNITLESS - doc: | - For example if the voxel grid is used to report that there - are voxels which are assumed to represent volume of certain precipitates, - say we found ten precipitates and consider the rest as matrix. - We could make a list of say matrix, precipitate1, precipitate2, ..., - precipitate10. With cluster_dict_value then running from 0 to 10, - i.e. matrix is flagged special as 0 and the remaining particles - are indexed conveniently as 1, 2, ..., 10 like end users expect. - dimensions: - rank: 1 - dim: [[1, n_voxel]] - - # use the fact that with e.g. XDMF one can on-the-fly reinterpret - # a 1d array to represent an explicit 3d grid - # then the entire visualization just needs a smart XDMF file with - # one section with the coordinates of the voxel center of masses - # one section with the voxel identifier - # one section with the "phase" identifier referring to the clustering_composition_space NXprocess group - # one section with the "precipitate" identifier referring to the clustering_real_space NXprocess group - # technically one should get rid of the unnecessary chunks - # instead define an (nx, ny, nz) C-style array which whose data space - # is reserved by the h5py library upon first call and then (if desired) - # filled incrementally - # the array should be chunked not with an auto-chunking but with a nx, ny, >=1 chunking - # which will make visualization of nx, ny slices naturally fast, making the z-dimension - # chunking as fast as large as possible (needs compromise to remain within chunk cache size) - # will also make the orthogonal section a good compromise fast - # data should be gzip, level 1 compressed and all the redundant parts of the current - # output will collapse substantially - performance(NXcs_profiling): - current_working_directory: - command_line_call: - exists: optional - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - total_elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - (NXcs_computer): - exists: recommended - name: - exists: recommended - operating_system: - \@version: - uuid: - exists: optional - (NXcs_cpu): - exists: ['min', '0', 'max', 'unbounded'] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_gpu): - exists: ['min', '0', 'max', 'unbounded'] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_mm_sys): - exists: ['min', '0', 'max', '1'] - total_physical_memory(NX_NUMBER): - (NXcs_io_sys): - exists: ['min', '0', 'max', '1'] - (NXcs_io_obj): - exists: ['min', '1', 'max', 'unbounded'] - technology: - max_physical_capacity(NX_NUMBER): - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_profiling_event): - start_time(NX_DATE_TIME): - exists: optional - end_time(NX_DATE_TIME): - exists: optional - description: - elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - number_of_threads(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - number_of_gpus(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - max_virtual_memory_snapshot(NX_NUMBER): - exists: recommended - max_resident_memory_snapshot(NX_NUMBER): - exists: recommended - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 0c29376ce1705f690d1267a0cbe4f35e05d3f307951e01669ca735b5b822dccc -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of voxel of discretized domain for analyzed part of the dataset. -# -# -# -# -# The dimensionality of the grid. -# -# -# -# -# The cardinality or total number of cells/grid points. -# -# -# -# -# Number of terms in the composition clustering dictionary -# -# -# -# -# Number of terms in the position clustering dictionary -# -# -# -# -# Results of a run with Alaukik Saxena's composition space tool. -# -# This is an initial draft application definition for the common NFDI-MatWerk, -# FAIRmat infrastructure use case IUC09 how to improve the organization and -# results storage of the composition space tool and make these data at the -# same time directly understandable for research data management systems -# like NOMAD Oasis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# TBD, maybe how to link between pyiron state tracking and app state tracking. -# -# -# -# -# Disencouraged place for free-text for e.g. comments. -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when the analysis behind this results file -# was started, i.e. when composition space tool was started as a process. -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when the analysis behind this results file -# were completed and composition space tool exited as a process. -# -# -# -# -# -# The path and name of the config file that was used for this analysis. -# TBD, this can be e.g. Alaukik's YAML file for composition space. -# -# -# -# -# -# -# -# -# Details about the file (technology partner or community format) -# from which reconstructed ion positions were loaded. -# -# -# -# -# -# -# -# -# Details about the file (technology partner or community format) -# from which ranging definitions were loaded which detail how to -# map mass-to-charge-state ratios on iontypes. -# -# -# -# -# -# -# -# -# -# Path to the directory where the tool should store NeXus/HDF5 results -# of this analysis. If not specified results will be stored in the -# current working directory. -# -# -# -# -# A statement whether the executable managed to process the analysis -# or failed prematurely. This status is written to the results file after the -# end_time at which point the executable must not compute any analysis. -# Only when this status message is present and shows `success`, the -# user should consider the results. In all other cases it might be -# that the executable has terminated prematurely or another error -# occurred. -# -# -# -# -# -# -# -# -# If used, contact information and eventually details -# of at least the person who performed this analysis. -# -# -# -# -# -# -# -# -# Details about coordinate systems (reference frames) used. In atom probe several coordinate -# systems have to be distinguished. Names of instances of such :ref:`NXcoordinate_system` -# should be documented explicitly and doing so by picking from the -# following controlled set of names: -# -# * composition_space -# * lab -# * specimen -# * laser -# * instrument -# * detector -# * recon -# -# The aim of this convention is to support users with contextualizing which reference -# frame each instance (coordinate system) is. If needed, instances of :ref:`NXtransformations` -# are used to detail the explicit affine transformations whereby one can convert -# representations between different reference frames. -# Inspect :ref:`NXtransformations` for further details. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Reference to or definition of a coordinate system with -# which the positions and directions are interpretable. -# -# -# -# -# -# -# -# -# -# Position of each cell in Euclidean space. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# For each ion, the identifier of the voxel in which the ion is located. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# In Alaukik's tool the GMM step. -# -# -# -# -# -# -# -# -# The keywords of the dictionary of distinguished compositionally- -# defined cluster, e.g. the phases. Examples for keywords could be -# phase1, phase2, and so one and so forth. -# -# -# -# -# -# -# -# Resolves for each keyword in cluster_dict which integer is used to -# label something that it belongs or is assumed to represent this -# cluster. -# -# -# -# -# -# -# -# -# For example if the voxel grid is used to report that there -# are voxels which are assumed to represent volume of either phase1 -# or phase2, the cluster_dict_keyword would be a list with two names -# phase1 and phase2, respectively. The cluster_dict_value would be a -# list of e.g. integers 1 and 2. These could be used to build an -# array with as many entries as there are voxel and store in this array -# the respective value to encode which phase is assumed for each voxel. -# -# -# -# -# -# -# -# -# -# In Alaukik's tool the DBScan step after the GMM step. -# -# -# -# -# -# -# -# -# The keywords of the dictionary of distinguished spatially-contiguous -# clusters. Examples for keywords could be precipitate1, precipitate2, -# and so one and so forth. -# -# -# -# -# -# -# -# Resolves for each keyword in cluster_dict which integer is used to -# label something that it belongs or is assumed to represent this -# cluster. -# -# -# -# -# -# -# -# -# For example if the voxel grid is used to report that there -# are voxels which are assumed to represent volume of certain precipitates, -# say we found ten precipitates and consider the rest as matrix. -# We could make a list of say matrix, precipitate1, precipitate2, ..., -# precipitate10. With cluster_dict_value then running from 0 to 10, -# i.e. matrix is flagged special as 0 and the remaining particles -# are indexed conveniently as 1, 2, ..., 10 like end users expect. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Specify if it was different from the number_of_processes -# in the NXcs_profiling super class. -# -# -# -# -# -# Specify if it was different from the number_of_threads -# in the NXcs_profiling super class. -# -# -# -# -# -# Specify if it was different from the number_of_threads -# in the NXcs_profiling super class. -# -# -# -# -# -# -# -# -# From 0e96bf4f0fc5e73a8d743fc4c00acc3b8331a9e3 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 8 Jul 2024 11:37:57 +0200 Subject: [PATCH 0776/1012] make geometries and source recommended in xps --- contributed_definitions/NXxps.nxdl.xml | 4 ++-- contributed_definitions/nyaml/NXxps.yaml | 8 +++++--- 2 files changed, 7 insertions(+), 5 deletions(-) diff --git a/contributed_definitions/NXxps.nxdl.xml b/contributed_definitions/NXxps.nxdl.xml index 3aa82e8861..89ab1904ef 100644 --- a/contributed_definitions/NXxps.nxdl.xml +++ b/contributed_definitions/NXxps.nxdl.xml @@ -48,7 +48,7 @@ .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 - + In traditional surface science, a left-handed coordinate system is used such that the positive z-axis @@ -140,7 +140,7 @@ .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 - + diff --git a/contributed_definitions/nyaml/NXxps.yaml b/contributed_definitions/nyaml/NXxps.yaml index 8add5adc7e..4ae3263c39 100644 --- a/contributed_definitions/nyaml/NXxps.yaml +++ b/contributed_definitions/nyaml/NXxps.yaml @@ -22,6 +22,7 @@ NXxps(NXmpes): .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 geometries(NXcoordinate_system_set): + exists: recommended xps_coordinate_system(NXcoordinate_system): exists: optional doc: | @@ -91,6 +92,7 @@ NXxps(NXmpes): term: 12.58 url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 sourceTYPE(NXsource): + exists: recommended power(NX_FLOAT): unit: NX_POWER exists: recommended @@ -230,7 +232,7 @@ NXxps(NXmpes): \@energy_indices: # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4e74c48e0373e4962f15d12f44b67a01cf518c750a3dcaa545701e4da36663cf +# 59c4a524be2f9db0fc2398d905fa42f69a76b59cdc5a4177539f30010f8f5271 # # # diff --git a/contributed_definitions/NXms_gragles_config.nxdl.xml b/contributed_definitions/NXms_gragles_config.nxdl.xml new file mode 100644 index 0000000000..3e3f9ae888 --- /dev/null +++ b/contributed_definitions/NXms_gragles_config.nxdl.xml @@ -0,0 +1,344 @@ + + + + + + + Application definition for configuring GraGLeS. + + GraGLeS is a continuum-scale model for shared-memory-parallelized simulations + of the isothermal evolution of 2D and 3D grain boundary networks via a + level-set approach. CPU parallelization is achieved with OpenMP. + + The code has been implemented by C. Mießen in the group of G. Gottstein + at the Institute für Metallkunde und Metallphysik, RWTH Aachen University. + + Details of the model are summarized in C. Mießen `<https://publications.rwth-aachen.de/record/709678>`_. + + + + + + + + + + + Which starting configuration to take. + + + + + + + + + Scaling the (representative) volume element to the research question. + + + + + + + The formulation of mean curvature flow whereby GraGLeS models grain growth + is scale invariant. This parameter configures the assumed physical length + of the simulation domain (ve, ROI). + For GraGLeS the discretization is always a square or cubic axis-aligned + bounding box with a regular tiling into material points + (either squares or cubes respectively). + + Edge_length is the length of the entire domain along its edge not + the length of the Wigner-Seitz cell about each material point! + + + + + + Configuration when snapshots of the system should be taken. + + + + Generate a snapshot of the properties of the grains to follow + the evolution of the microstructure every :math:`n`-th iteration. + Setting zero causes that no property snapshots are taken. + + + + + Generate a snapshot of the geometry of the entire + grain boundary network every :math:`n`-th iteration. + Setting zero causes that no geometry snapshots are taken. + + + + + + + Configuration when the simulation should stopped in a controlled manner. + Whichever criterion is fulfilled first triggers the controlled stop of + and termination of GraGLeS. + + + + The simulation stops if the total number of grains + becomes smaller than this criterion. + + + + + The simulation stops if more iterations than this criterion + have been computed. + + + + + + Configuration of fundamental numerical details of the solver. + + + + + Which type of convolution kernel and model is used. + + + + + + + + + + Constant to calibrate the real time scaling of the simulation. + + + + + + + Configuration of the grid coarsement algorithm whereby the representation + of the system is continuously rediscretized such that on average grains + are discretized with discretization many material points along each + direction. + + Grid coarsement can reduce the computational costs substantially although + it cannot be ruled out completely that the rediscretizing may have an effect + on the system evolution. Without grid coarsement the total number of material + points to consider stays the same throughout the simulation. + + + + Number of material points along each direction to discretize the + average grain. The larger this value is chosen the finer the curvature + details are that can be resolved but also the longer the simulation + takes. + + + + + If true grid coarsement is active, otherwise it is not. + + + + + Fraction how strongly the number of grains has to reduce + to trigger a grid coarsement step in an iteration. + + + + + + + Physically-based model of the assumed mobility of the grain boundaries. + + Grain boundary mobility is not an intrinsic property of a grain boundary + but system-dependent especially as grain boundaries in reality are decorated + with defects as a consequence of which the actual mobility is a combination + of the mobility of the individual defects and the attached boundary + patches. Grain boundaries have different degrees of microscopic freedom. + Therefore, their mobility follows a distribution. + + + + + Fundamental model how :math:`m` is assumed a function of the disorientation angle :math:`\Theta`. + + For rollett_holm :math:`m(\Theta) = m_0 \cdot (1 - c_1 * exp(-c_2 \cdot \frac{\Theta}{15}^{c_3}))`. + + + + + + + + The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed + temperature. GraGLeS was developed for modelling isothermal annealing. + + + + + Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not one. + + + + + + Mobility scaling factor :math:`c_2`. Typically 5. + + + + + Mobility scaling factor :math:`c_3`. Typically 9. + + + + + + Grain boundary surface energy. Like for the grain boundary mobility, + defects cause a distribution of energies for the patches of which + the boundary is composed resulting in currently in practical cases + a too complicated dependency of the energy and mobility model as a function + of the type and chemical decoration of the defects. + + + + Fundamental type of assumption if energies are considered isotropic or not. + + + + + + + + + Fundamental model how :math:`\gamma` is assumed a function of the disorientation + angle :math:`\Theta`. + + + + + + + + Mean grain boundary surface energy that is assumed a function of the + disorientation angle :math:`\Theta` of the adjoining grains :math:`\gamma(\Theta)`. + + For GraGLeS :math:`\gamma(\Theta) = \{\begin{array}1 \text{for} \Theta > 1. \\ 0.01 \text{for} \Theta \leq 1.\end{array}`. + + This value factorizes the curvature_driving_force model. + + + + + + + A continuum-scale curvature of an interface causes the interface to + migrate towards the center of the curvature radius. + + + + If true the curvature_driving_force is considered, otherwise it is not. + + + + + + A continuum-scale difference of the stored elastic energy in dislocation + configurations across a grain boundary can exert a driving force on the + grain boundary such that it migrates into the volume with the higher + stored elastic energy. + + + + If true the dislocation_driving_force is considered, otherwise it is not. + + + + + Prefactor :math:`0.5Gb^2` that factorizes the average + tored elastic energy per length dislocation line. + + + + + + In case of an applied magnetic field, a difference of the magnetic + susceptibility can exert a driving force on the grain boundary such that + it migrates into the volume with the higher magnetic energy. + + + + If true the magnetic_driving_force is considered, otherwise it is not. + + + + + + + A triple line mediates the atomic arrangement differences between three + interface patches. Therefore, the triple line is a defect that may not + have the same mobility as adjoining grain boundaries and thus it may + exert what can be conceptualized as a drag (resistance) to the motion + of the adjoining interface patches. + + + + Assumed triple junction drag. + + + + + + diff --git a/contributed_definitions/NXms_imm_config.nxdl.xml b/contributed_definitions/NXms_imm_config.nxdl.xml new file mode 100644 index 0000000000..5055b707be --- /dev/null +++ b/contributed_definitions/NXms_imm_config.nxdl.xml @@ -0,0 +1,155 @@ + + + + + + + Application definition for the IMM structure generator. + + The tool can be used to instantiate specific configurations for computer simulations modelling the evolution of the a microstructure upon annealing. The structure is assumed + to be a homophase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. Grains can be modelled as elongated objects to mimic fundamental geometrical constraints of the interface network in deformed material. + + + + + + + + + + + + Two-dimensional or three-dimensional simulation. + + + + + + + + + + Assumed space group of the material. + + + + + + + + + + + Domain will be square or cubic respectively ROI (axis-aligned) regularly tessellated with either squares or cubes about so-called material points. + + Actual domain size and grid depends on discretization, number_of_grains, and shape of these grains + + + + + + + If available used to define the sequence of relative extent of grains along the y (first value) and z-axis (second value) assuming the relative shape along the x-axis is 1. + + If absent, structure will be globulitic i.e. the extent of the grains on average is 1 along each axis. + + + + + + + + + + The model according to which dislocation density is distributed across the + grains and sub-grains. + + + + Distribution type according to which values are distributed. + + + + + + + + The minimum and the maximum value to distribute across sub-grains. + + + + + + + + + + + + + + + + + + + + + Orientations of the grains are sampled from a set of Bunge-Euler angle triplets. + Orientations of the sub-grains are sampled by scattering the orientation of the (parent) grain. + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXms_ipf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml deleted file mode 100644 index 7f490dd84b..0000000000 --- a/contributed_definitions/NXms_ipf_set.nxdl.xml +++ /dev/null @@ -1,33 +0,0 @@ - - - - - - - Base class to group multiple :ref:`NXms_ipf` instances. - - A collection of inverse pole figure approximations. - - - diff --git a/contributed_definitions/NXms_kanapy_results.nxdl.xml b/contributed_definitions/NXms_kanapy_results.nxdl.xml new file mode 100644 index 0000000000..e69de29bb2 diff --git a/contributed_definitions/NXms_odf_set.nxdl.xml b/contributed_definitions/NXms_odf_set.nxdl.xml deleted file mode 100644 index c21aa36985..0000000000 --- a/contributed_definitions/NXms_odf_set.nxdl.xml +++ /dev/null @@ -1,33 +0,0 @@ - - - - - - - Base class to group multiple :ref:`NXms_odf` instances. - - A collection of orientation distribution function approximations. - - - diff --git a/contributed_definitions/NXms_pf_set.nxdl.xml b/contributed_definitions/NXms_pf_set.nxdl.xml deleted file mode 100644 index 14a4061d64..0000000000 --- a/contributed_definitions/NXms_pf_set.nxdl.xml +++ /dev/null @@ -1,33 +0,0 @@ - - - - - - - Base class to group multiple :ref:`NXms_pf` instances. - - A collection of pole figure approximations. - - - diff --git a/contributed_definitions/NXms_snapshot.nxdl.xml b/contributed_definitions/NXms_snapshot.nxdl.xml index b2b0e26f18..8d6c65caa2 100644 --- a/contributed_definitions/NXms_snapshot.nxdl.xml +++ b/contributed_definitions/NXms_snapshot.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXxrd_pan.nxdl.xml b/contributed_definitions/NXxrd_pan.nxdl.xml index 191cf8feb3..1b5316e410 100644 --- a/contributed_definitions/NXxrd_pan.nxdl.xml +++ b/contributed_definitions/NXxrd_pan.nxdl.xml @@ -27,7 +27,7 @@ n_values - symbols ? : could or should be modified?--> - NXxrd_pan is a specialisation of NXxrd with exptra properties + NXxrd_pan is a specialisation of NXxrd with extra properties. @@ -294,7 +294,7 @@ defracted_beam(NXbeam):--> - + Person or agent that prepared the sample. diff --git a/contributed_definitions/nyaml/NXem_ebsd.yaml b/contributed_definitions/nyaml/NXem_ebsd.yaml index 7811a8845d..a53728fffb 100644 --- a/contributed_definitions/nyaml/NXem_ebsd.yaml +++ b/contributed_definitions/nyaml/NXem_ebsd.yaml @@ -363,8 +363,9 @@ NXem_ebsd(NXem_method): doc: | Number of scan points in the original mapping. unit: NX_UNITLESS - odf(NXms_odf_set): - pf(NXms_pf_set): + odfID(NXms_odf): + pID(NXms_pf): + ipfID(NXms_ipf): microstructureID(NXms_recon): # overview over the entire map, rediscretized on a tight aabb roi(NXdata): diff --git a/contributed_definitions/nyaml/NXms_gragles_config.yaml b/contributed_definitions/nyaml/NXms_gragles_config.yaml new file mode 100644 index 0000000000..cda806d3c4 --- /dev/null +++ b/contributed_definitions/nyaml/NXms_gragles_config.yaml @@ -0,0 +1,258 @@ +category: application +doc: | + Application definition for configuring GraGLeS. + + GraGLeS is a continuum-scale model for shared-memory-parallelized simulations + of the isothermal evolution of 2D and 3D grain boundary networks via a + level-set approach. CPU parallelization is achieved with OpenMP. + + The code has been implemented by C. Mießen in the group of G. Gottstein + at the Institute für Metallkunde und Metallphysik, RWTH Aachen University. + + Details of the model are summarized in C. Mießen ``_. +# symbols: +# type: group +NXms_gragles_config(NXobject): + (NXentry): + definition(NX_CHAR): + enumeration: [NXms_gragles_config] + \@version(NX_CHAR): + + starting_configuration(NX_CHAR): + doc: | + Which starting configuration to take. + enumeration: [read_from_file] # poisson_voronoi_tessellation + # 0, E_READ_FROM_FILE, 1, E_GENERATE_WITH_VORONOY, 2, E_READ_VERTEX, // The edges need to be ordered 3, E_GENERATE_TESTCASE, 4, E_READ_VOXELIZED_MICROSTRUCTURE + # read the next three from input file + # Microstructure.SimID.10.GrainIDs.2D.1188.raw all in config file + # Microstructure.SimID.10.uds + # 0 0, E_CUBIC, 1, E_HEXAGONAL fish from config file + + roi(NXroi): + doc: | + Scaling the (representative) volume element to the research question. + # either or + (NXcg_polygon_set): + # (NXcg_hexahedron_set): + edge_length(NX_FLOAT): # 4.2037e-3 + doc: | + The formulation of mean curvature flow whereby GraGLeS models grain growth + is scale invariant. This parameter configures the assumed physical length + of the simulation domain (ve, ROI). + For GraGLeS the discretization is always a square or cubic axis-aligned + bounding box with a regular tiling into material points + (either squares or cubes respectively). + + Edge_length is the length of the entire domain along its edge not + the length of the Wigner-Seitz cell about each material point! + unit: NX_LENGTH + + snapshot_sampling(NXprocess): + doc: | + Configuration when snapshots of the system should be taken. + system(NX_UINT): # 1 + doc: | + Generate a snapshot of the properties of the grains to follow + the evolution of the microstructure every :math:`n`-th iteration. + Setting zero causes that no property snapshots are taken. + unit: NX_UNITLESS + geometry(NX_UINT): # 100 + doc: | + Generate a snapshot of the geometry of the entire + grain boundary network every :math:`n`-th iteration. + Setting zero causes that no geometry snapshots are taken. + unit: NX_UNITLESS + # 31 no more sampling + # 1 + + simulation_control(NXprocess): + doc: | + Configuration when the simulation should stopped in a controlled manner. + Whichever criterion is fulfilled first triggers the controlled stop of + and termination of GraGLeS. + number_of_grains(NX_UINT): # 1000 + doc: | + The simulation stops if the total number of grains + becomes smaller than this criterion. + unit: NX_UNITLESS + number_of_iterations(NX_UINT): # 1000000 + doc: | + The simulation stops if more iterations than this criterion + have been computed. + unit: NX_UNITLESS + + numerics(NXprocess): + doc: | + Configuration of fundamental numerical details of the solver. + # use proper environment variable number_of_threads(NX_UINT): # obsolete set 01 16 + convolution_mode(NX_CHAR): + doc: | + Which type of convolution kernel and model is used. + enumeration: [gaussian, laplace, laplace_ritchardson] # 2 + time_slope(NX_FLOAT): # 0.7930 + doc: | + Constant to calibrate the real time scaling of the simulation. + unit: NX_ANY # or NX_DIMENSIONLESS ?? + # when taking the E_GAUSSIAN convolution mode set the TimeSlopeFactor explicitly here, default Miessen, Liesenjohann was 0.8359--> + # 0 + # 12991 # read from file + # discretization(NX_UINT) # 15 + # 15 + # domain_border_size(NX_UINT): # 7 + # + + grid_coarsement(NXprocess): + doc: | + Configuration of the grid coarsement algorithm whereby the representation + of the system is continuously rediscretized such that on average grains + are discretized with discretization many material points along each + direction. + + Grid coarsement can reduce the computational costs substantially although + it cannot be ruled out completely that the rediscretizing may have an effect + on the system evolution. Without grid coarsement the total number of material + points to consider stays the same throughout the simulation. + discretization(NX_UINT): + doc: | + Number of material points along each direction to discretize the + average grain. The larger this value is chosen the finer the curvature + details are that can be resolved but also the longer the simulation + takes. + unit: NX_UNITLESS + is_active(NX_BOOLEAN): # 1 + doc: | + If true grid coarsement is active, otherwise it is not. + gradient(NX_FLOAT): # 0.98 + doc: | + Fraction how strongly the number of grains has to reduce + to trigger a grid coarsement step in an iteration. + unit: NX_DIMENSIONLESS + # the next only guru i.e. in C++ code configurable options + # 3 + # 2 + # 0 # 0, DEFAULT, 1 skips comparison and let grains shring isolated + + grain_boundary_mobility_model(NXprocess): + doc: | + Physically-based model of the assumed mobility of the grain boundaries. + + Grain boundary mobility is not an intrinsic property of a grain boundary + but system-dependent especially as grain boundaries in reality are decorated + with defects as a consequence of which the actual mobility is a combination + of the mobility of the individual defects and the attached boundary + patches. Grain boundaries have different degrees of microscopic freedom. + Therefore, their mobility follows a distribution. + # 0 + # 0 # + model(NX_CHAR): + doc: | + Fundamental model how :math:`m` is assumed a function of the disorientation angle :math:`\Theta`. + + For rollett_holm :math:`m(\Theta) = m_0 \cdot (1 - c_1 * exp(-c_2 \cdot \frac{\Theta}{15}^{c_3}))`. + enumeration: [rollett_holm] + m_null(NX_FLOAT): + doc: | + The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed + temperature. GraGLeS was developed for modelling isothermal annealing. + unit: NX_ANY # m^4/Js + c_one(NX_FLOAT): + doc: | + Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not one. + unit: NX_DIMENSIONLESS + # 7.5e-14 + c_two(NX_FLOAT): + doc: | + Mobility scaling factor :math:`c_2`. Typically 5. + unit: NX_UNITLESS + c_three(NX_FLOAT): + doc: | + Mobility scaling factor :math:`c_3`. Typically 9. + unit: NX_UNITLESS + + grain_boundary_energy_model(NXprocess): + doc: | + Grain boundary surface energy. Like for the grain boundary mobility, + defects cause a distribution of energies for the patches of which + the boundary is composed resulting in currently in practical cases + a too complicated dependency of the energy and mobility model as a function + of the type and chemical decoration of the defects. + type(NX_CHAR): + doc: | + Fundamental type of assumption if energies are considered isotropic or not. + enumeration: [isotropic, anisotropic] + model(NX_CHAR): + doc: | + Fundamental model how :math:`\gamma` is assumed a function of the disorientation angle :math:`\Theta`. + enumeration: [read_shockley] + gamma(NX_FLOAT): # HAGBEnergy + doc: | + Mean grain boundary surface energy that is assumed a function of the + disorientation angle :math:`\Theta` of the adjoining grains :math:`\gamma(\Theta)`. + + For GraGLeS :math:`\gamma(\Theta) = \{\begin{array}1 \text{for} \Theta > 1. \\ 0.01 \text{for} \Theta \leq 1.\end{array}`. + + This value factorizes the curvature_driving_force model. + unit: NX_ANY # J/m^2 + # 1.0 + # 0.01 + # + + curvature_driving_force_model(NXprocess): + doc: | + A continuum-scale curvature of an interface causes the interface to + migrate towards the center of the curvature radius. + is_active(NX_BOOLEAN): + doc: | + If true the curvature_driving_force is considered, otherwise it is not. + + dislocation_driving_force_model(NXprocess): + doc: | + A continuum-scale difference of the stored elastic energy in dislocation + configurations across a grain boundary can exert a driving force on the + grain boundary such that it migrates into the volume with the higher + stored elastic energy. + is_active(NX_BOOLEAN): # 1 + doc: | + If true the dislocation_driving_force is considered, otherwise it is not. + line_energy(NX_FLOAT): # 1.44e-9 + doc: | + Prefactor :math:`0.5Gb^2` that factorizes the average + tored elastic energy per length dislocation line. + unit: NX_ANY # J/m + + magnetic_driving_force_model(NXprocess): + doc: | + In case of an applied magnetic field, a difference of the magnetic + susceptibility can exert a driving force on the grain boundary such that + it migrates into the volume with the higher magnetic energy. + is_active(NX_BOOLEAN): # 0 + doc: | + If true the magnetic_driving_force is considered, otherwise it is not. + # MagneticField.xml + # https://github.com/GraGLeS/GraGLeS2D/blob/master/params/MagneticField.xml + + triple_line_mobility_model(NXprocess): + doc: | + A triple line mediates the atomic arrangement differences between three + interface patches. Therefore, the triple line is a defect that may not + have the same mobility as adjoining grain boundaries and thus it may + exert what can be conceptualized as a drag (resistance) to the motion + of the adjoining interface patches. + drag(NX_FLOAT): + doc: | + Assumed triple junction drag. + unit: NX_ANY # or reciprocal check Gottstein, Shvindlerman but is this really a drag. + # 1.0e10 + # isotropic, anisotropic + # 1 + # 1 diff --git a/contributed_definitions/nyaml/NXms_imm_config.yaml b/contributed_definitions/nyaml/NXms_imm_config.yaml new file mode 100644 index 0000000000..6bf9a6ef7e --- /dev/null +++ b/contributed_definitions/nyaml/NXms_imm_config.yaml @@ -0,0 +1,92 @@ +category: application +doc: | + Application definition for the IMM structure generator. + + The tool can be used to instantiate specific configurations for computer simulations modelling the evolution of the a microstructure upon annealing. The structure is assumed + to be a homophase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. Grains can be modelled as elongated objects to mimic fundamental geometrical constraints of the interface network in deformed material. +# symbols: +# type: group +NXms_imm_config(NXobject): + (NXentry): + definition(NX_CHAR): + enumeration: [NXms_imm_config] + \@version(NX_CHAR): + + roi(NXroi): + dimensionality(NX_UINT): + doc: | + Two-dimensional or three-dimensional simulation. + enumeration: [2, 3] + discretization(NX_UINT): # 15# simulation ID via command line 10 + crystal_symmetry(NX_CHAR): + doc: | + Assumed space group of the material. + enumeration: [fcc, bcc, hcp] + # PreferenceOrientations.txt + # 1 # 0, E_HCP, 1 E_FCC, 2 E_BCC, 3 E_DEFAULT_STRUCTURE + number_of_grains(NX_UINT): # 8 + doc: | + Domain will be square or cubic respectively ROI (axis-aligned) regularly tessellated with either squares or cubes about so-called material points. + + Actual domain size and grid depends on discretization, number_of_grains, and shape of these grains + number_of_subgrains(NX_UINT): # 1000 + # 0 is there another one if not remove + # 1 always one + # + # 1 + grain_shape(NX_FLOAT): + exists: optional + doc: | + If available used to define the sequence of relative extent of grains along the y (first value) and z-axis (second value) assuming the relative shape along the x-axis is 1. + + If absent, structure will be globulitic i.e. the extent of the grains on average is 1 along each axis. + unit: NX_DIMENSIONLESS + dim: (2,) + # + + dislocation_density_distribution_model(NXprocess): + doc: | + The model according to which dislocation density is distributed across the grains and sub-grains. + type(NX_CHAR): + doc: | + Distribution type according to which values are distributed. + enumeration: [rayleigh] + min_max(NX_FLOAT): + doc: | + The minimum and the maximum value to distribute across sub-grains. + unit: NX_ANY # 1/m^2 + dim: (2,) + # 10.8e14# 10.8e144.0e14 + # + doc: | + unit: NX_ANY # 1/m^2 + variance??_subgrain(NX_FLOAT): # 0.8e14 + doc: | + unit: NX_ANY # 1/m^2 + orientation_distribution_model(NXprocess): # CR70FeSi.Rogge.MTEX.vpsc.odf.5000.txt + doc: | + Orientations of the grains are sampled from a set of Bunge-Euler angle triplets. + Orientations of the sub-grains are sampled by scattering the orientation of the (parent) grain. + input(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + variance_subgrain(NX_FLOAT): # 5.0 + doc: | + unit: NX_ANGLE + # what is with preference orientations? + +# 1 # via OpenMP +# 1 +# 0.00 +# 1.00 +# 0.00 +# 1.00 +# of the map were identified as that phase. - - - + + + diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index 95a644b519..14cf17914d 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -152,8 +152,8 @@ The result of orientation microscopy methods are maps of local orientation and thermodynamic phase (crystal structure) pieces of information. Virtually all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can + a workflow of steps which are covered though by the NXmicrostructure partner application + definition. The respective source of the data in an instance of NXmicrostructure can again be a link or reference to an instance of NXem_ebsd to complete the chain of provenance. diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index 3be2f2f1af..e29246f637 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -471,10 +471,10 @@ to sample_reference_frame Number of scan points in the original mapping. - - - - + + + + diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml index d0602017a7..e1c2b45b85 100644 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -53,7 +53,7 @@ Steps of post-processing the diffraction patterns should be documented using method-specific specialized base classes. All eventual post-processing of - resulting orientation maps (2D or 3D) should be documented via :ref:`NXms_recon`. + resulting orientation maps (2D or 3D) should be documented via :ref:`NXmicrostructure_recon`. To implement an example how this base class can be used we focused in FAIRmat on Kikuchi diffraction pattern here specifically the research community @@ -174,6 +174,6 @@ axis_x(R):--> the spatial arrangement of the microstructural features, the individual (thermodynamic, chemo-mechanical) properties of the features with the properties of materials at a coarser scale. - With NXem and related NXms base classes we propose a covering + With NXem and related NXmicrostructure base classes we propose a covering and general solution how to handle such (meta)data with NeXus.--> diff --git a/contributed_definitions/NXms_feature_set.nxdl.xml b/contributed_definitions/NXmicrostructure_feature_set.nxdl.xml similarity index 84% rename from contributed_definitions/NXms_feature_set.nxdl.xml rename to contributed_definitions/NXmicrostructure_feature_set.nxdl.xml index 13cba91083..de78c4f64c 100644 --- a/contributed_definitions/NXms_feature_set.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_feature_set.nxdl.xml @@ -22,12 +22,12 @@ # For further information, see http://www.nexusformat.org --> - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -57,10 +57,10 @@ Thea, Joseph, Lauri, Dinga (TJLD) just for comparison for each group and field t Set of topological/spatial features in materials build from other features. - Name (or link?) to another NXms_feature_set which defines features what are + Name (or link?) to another NXmicrostructure_feature_set which defines features what are assumed as the parents/super_features of all members in this feature set. If depends_on is set to "." or this attribute is not defined in an instance of this application definition, assume that this feature_set instance @@ -82,11 +82,11 @@ arrays to make the eventual storage of this for instances with millions of featu more efficient as in the current design each molecule would again be a group and having millions of groups comes with e.g. HDF5 with substantial overlap I faced this when storing grains from micro-scale continuum crystal growth simulations -TJLD: is_molecule(NX_BOOLEAN): not used, could however be added in an appdef which uses instances of NXms_feature_set -TJLD: the key point we can use NXms_feature_set in the same way as currently TJLD use atoms and atoms/atom_groups/molecule0, */molecule1, ... +TJLD: is_molecule(NX_BOOLEAN): not used, could however be added in an appdef which uses instances of NXmicrostructure_feature_set +TJLD: the key point we can use NXmicrostructure_feature_set in the same way as currently TJLD use atoms and atoms/atom_groups/molecule0, */molecule1, ... but with the additional benefit of a much richer geometrical description and the details about the uncertainty of these descriptions -I can also imagine that materials engineers e.g. can reuse NXms_feature_set in an application definition by just then naming -their group e.g. grains(NXms_feature_set) and use in the application definition either only the (material point), interface network, or volumetric description--> +I can also imagine that materials engineers e.g. can reuse NXmicrostructure_feature_set in an application definition by just then naming +their group e.g. grains(NXmicrostructure_feature_set) and use in the application definition either only the (material point), interface network, or volumetric description--> The keywords of the dictionary of human-readable types of features. @@ -194,9 +194,9 @@ end up as links--> TJLD: this design here is different, TJLD give atom positions only (at least as of now) for the root of an object TJLD: while all higher-order features that are connected through their assumed topology just refer to the atoms in the root TJLD: via their IDs, TJLD design is ideal for systems build from atoms but would create unnecessary copies for higher-dimensional-type features -TJLD: in fact initially I also thought it is useful to create an NXms_dislocation_set, and an NXms_atom_set but overall these are just -specializations of NXms_feature_set. Instead I like the key approach in TJLD which is to nest instances of the same class in TJLD's case AtomGroups -but here NXms_feature_set instances +TJLD: in fact initially I also thought it is useful to create an NXmicrostructure_dislocation_set, and an NXmicrostructure_atom_set but overall these are just +specializations of NXmicrostructure_feature_set. Instead I like the key approach in TJLD which is to nest instances of the same class in TJLD's case AtomGroups +but here NXmicrostructure_feature_set instances --> Assumptions and parameter to arrive at geometric primitives @@ -264,29 +264,29 @@ NeXus would be Sandor suggested it can be useful to also describe how one could transform system-specific atom positions from the system-focused coordinate system to a molecule- or atom-focused local coordinate system--> - - +grains(NXmicrostructure_feature_set): +boundaries(NXmicrostructure_feature_set): +alternatively one NXmicrostructure_feature_set for homophase boundaries--> diff --git a/contributed_definitions/NXms_gragles_config.nxdl.xml b/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml similarity index 98% rename from contributed_definitions/NXms_gragles_config.nxdl.xml rename to contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml index 3e3f9ae888..742d1a238a 100644 --- a/contributed_definitions/NXms_gragles_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml @@ -24,7 +24,7 @@ - + Application definition for configuring GraGLeS. @@ -40,7 +40,7 @@ type: group--> - + diff --git a/contributed_definitions/NXms_imm_config.nxdl.xml b/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml similarity index 97% rename from contributed_definitions/NXms_imm_config.nxdl.xml rename to contributed_definitions/NXmicrostructure_imm_config.nxdl.xml index 5055b707be..bcf60eec02 100644 --- a/contributed_definitions/NXms_imm_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml @@ -24,7 +24,7 @@ - + Application definition for the IMM structure generator. @@ -34,7 +34,7 @@ type: group--> - + diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXmicrostructure_ipf.nxdl.xml similarity index 98% rename from contributed_definitions/NXms_ipf.nxdl.xml rename to contributed_definitions/NXmicrostructure_ipf.nxdl.xml index 0be3dc81e4..fee309b054 100644 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_ipf.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + @@ -119,7 +119,7 @@ The main purpose of this map is to offer a normalized default representation of the IPF map for consumption by a research data management system (RDMS). - This is aligned with the first aim of :ref:`NXms_ipf`, to bring colleagues and + This is aligned with the first aim of :ref:`NXmicrostructure_ipf`, to bring colleagues and users of IPF maps together to discuss which pieces of information need to be stored together. We are convinced a step-by-step design and community-driven discussion about which pieces of information should diff --git a/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml b/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml new file mode 100644 index 0000000000..72a018a872 --- /dev/null +++ b/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml @@ -0,0 +1,86 @@ + + + + + + Application definition for the microstructure generator kanapy from ICAMS Bochum. + + * `A. Hartmeier et al. <https://joss.theoj.org/papers/10.21105/joss.01732>`_ + + A draft application definition to support discussion within the infrastructure use case IUC07 of the + NFDI-MatWerk consortium of the German NFDI working on a data model for documenting simulations + of spatiotemporal microstructure evolution with scientific software from this community. + + + + + + + Discouraged free-text field to add further details to the computation. + + + + + + + + + + + + + + + + + + + + + + Programs and libraries representing the computational environment + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXmicrostructure_mtex_config.nxdl.xml similarity index 98% rename from contributed_definitions/NXms_mtex_config.nxdl.xml rename to contributed_definitions/NXmicrostructure_mtex_config.nxdl.xml index 90e4132bee..32cc902d72 100644 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_mtex_config.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + Base class to store the configuration when using the MTex/Matlab software. diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXmicrostructure_odf.nxdl.xml similarity index 97% rename from contributed_definitions/NXms_odf.nxdl.xml rename to contributed_definitions/NXmicrostructure_odf.nxdl.xml index 3e9d11dd70..696ff58cd4 100644 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_odf.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXmicrostructure_pf.nxdl.xml similarity index 96% rename from contributed_definitions/NXms_pf.nxdl.xml rename to contributed_definitions/NXmicrostructure_pf.nxdl.xml index 44db61d7b3..fd16df61db 100644 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_pf.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXmicrostructure_recon.nxdl.xml similarity index 95% rename from contributed_definitions/NXms_recon.nxdl.xml rename to contributed_definitions/NXmicrostructure_recon.nxdl.xml index ae4014c48b..558b53763c 100644 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_recon.nxdl.xml @@ -24,7 +24,7 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -86,8 +86,8 @@ crystals are delineated by interfaces that are delineated by triple lines that m the base class does not include time-dependent descriptions for the sake of clarity and because of the fact that virtually all simulations or experiments probe time by sampling. Therefore, time-dependent state descriptions should - be realized with creating a set of :ref:`NXms_snapshot_set` with instances of - :ref:`NXms_snapshot` using e.g. :ref:`NXms_recon` base class instances. + be realized with creating a set of :ref:`NXmicrostructure_snapshot_set` with instances of + :ref:`NXmicrostructure_snapshot` using e.g. :ref:`NXmicrostructure_recon` base class instances. ms_feature_set1 we could also enumerate instances ms_feature_setID here because configuration may specify a range of different parameter resulting in multiple ms_feature_sets -dimensionality(N) composed from NXms_feature_set base: +dimensionality(N) composed from NXmicrostructure_feature_set base: controlled vocabulary of base class instances to be used to inform about the discretization of these features instances to discretize the features wherever possible the computational geometry specific instances whose @@ -155,7 +155,7 @@ interface at the required here coarse-grained continuum picture--> - + Projections of crystals on the sample surface as typically characterized with optical or electron microscopy. @@ -169,7 +169,7 @@ ONE DIMENSIONAL FEATURES--> representation (projection) of the characterized material. For true volumetric techniques use the specifically - specialized crystals :ref:`NXms_feature_set` instead. + specialized crystals :ref:`NXmicrostructure_feature_set` instead. See stereology literature for more details e.g. E.E. Underwood's book entitled Quantitative Stereology @@ -249,7 +249,7 @@ ONE DIMENSIONAL FEATURES--> - + - The specific crystal_projections(NXms_feature_set) instance + The specific crystal_projections(NXmicrostructure_feature_set) instance to resolve crystal identifier. @@ -298,7 +298,7 @@ i) Set of pair of crystals sharing an interface--> - The specific triple_line_projections(NXms_feature_set) instance + The specific triple_line_projections(NXmicrostructure_feature_set) instance whereby to resolve triple_point identifier. @@ -343,7 +343,7 @@ properties, descriptors--> - + - The specific interface_projections(NXms_feature_set) + The specific interface_projections(NXmicrostructure_feature_set) instance whereby to resolve interface identifiers. diff --git a/contributed_definitions/NXms_score_config.nxdl.xml b/contributed_definitions/NXmicrostructure_score_config.nxdl.xml similarity index 98% rename from contributed_definitions/NXms_score_config.nxdl.xml rename to contributed_definitions/NXmicrostructure_score_config.nxdl.xml index 93b914d28d..b5d49c1241 100644 --- a/contributed_definitions/NXms_score_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_score_config.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + @@ -46,7 +46,7 @@ - + diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXmicrostructure_score_results.nxdl.xml similarity index 98% rename from contributed_definitions/NXms_score_results.nxdl.xml rename to contributed_definitions/NXmicrostructure_score_results.nxdl.xml index 40b2e54356..b0cc16db74 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_score_results.nxdl.xml @@ -22,8 +22,8 @@ # For further information, see http://www.nexusformat.org --> - +inspect comments behind NXmicrostructure--> + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -83,7 +83,7 @@ inspect comments behind NXms--> - + @@ -359,7 +359,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele - + Collection of microstructural data observed/simulated. @@ -420,7 +420,7 @@ exists: optional time-resolved results for individual snapshots virtually all computer simulations and all experiments always probe snapshots--> - + Measured or simulated physical time stamp for this snapshot. @@ -460,7 +460,7 @@ snapshots--> - + Details about those cells which in this time step represent diff --git a/contributed_definitions/NXms_snapshot.nxdl.xml b/contributed_definitions/NXmicrostructure_snapshot.nxdl.xml similarity index 93% rename from contributed_definitions/NXms_snapshot.nxdl.xml rename to contributed_definitions/NXmicrostructure_snapshot.nxdl.xml index 8d6c65caa2..0fe7ddadf8 100644 --- a/contributed_definitions/NXms_snapshot.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_snapshot.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXms_snapshot_set.nxdl.xml b/contributed_definitions/NXmicrostructure_snapshot_set.nxdl.xml similarity index 93% rename from contributed_definitions/NXms_snapshot_set.nxdl.xml rename to contributed_definitions/NXmicrostructure_snapshot_set.nxdl.xml index 03395113ca..42fe513867 100644 --- a/contributed_definitions/NXms_snapshot_set.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_snapshot_set.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -57,6 +57,6 @@ in which case identifier fields are not required, on the other hand if we give the names of the snapshots free via making them all capital how can we assure that snapshots are numbered consecutively? MS_SNAPSHOT--> - + diff --git a/contributed_definitions/NXms.nxdl.xml b/contributed_definitions/NXms.nxdl.xml deleted file mode 100644 index c529de418e..0000000000 --- a/contributed_definitions/NXms.nxdl.xml +++ /dev/null @@ -1,532 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of boundaries of the bounding box or primitive to domain. - - - - - Number of parameter required for the chosen orientation parameterization. - - - - - Number of texture components identified. - - - - - Application definition, spatiotemporal characterization of a microstructure. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment or computer simulation. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - - - - - Free-text description about the workflow (experiment/analysis/simulation). - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of this application definition rather than write details about the - experiment into this free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the characterization started. - - - - - ISO 8601 time code with local time zone offset to UTC included - when the characterization ended. - - - - - - - - - - Specify if the (characterization) results/data of this instance of an - application definition are based on the results of a simulation or the - results of a post-processing of measured data to describe - a microstructure. - - The term microstructure is used to describe the spatial arrangement of - crystal defects inside a sample/specimen without demanding necessarily - that this structure is mainly at the micron length scale. - Nanostructure and macrostructure are close synonyms. - Material architecture is a narrow synonym. - - Given that microstructure simulations nowadays more and more consider - the atomic arrangement, this application definition can also be used - to describe features at the scale of atoms. - - - - - - - - - Contact information and eventually details of at least one person - involved in creating this result. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service - should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - - Descriptive name or ideally (globally) unique persistent identifier. - - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - Container to hold different coordinate systems conventions. - A least a right-handed Cartesian coordinate system with base vectors - named x, y, and z has to be specified. Each base vector of the - coordinate system should be described with an NXtransformations instance. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The simulated or characterized material volume element aka domain. - At least one instance of geometry required either NXcg_grid, - NXcg_polyhedron_set, or NXcg_point_set. This geometry group needs - to contain details about the boundary conditions. - - - - - - - - A boundary to the volume element. - Either an instance of NXcg_hexahedron_set or of NXcg_ellipsoid_set. - - - - - How many distinct boundaries are distinguished. Value required equal to n_b. - - - - - Name of the boundaries. E.g. left, right, front, back, bottom, top, - - - - - - - - The boundary conditions for each boundary: - - 0 - undefined - 1 - open - 2 - periodic - 3 - mirror - 4 - von Neumann - 5 - Dirichlet - - - - - - - - - Collection of microstructural data observed/simulated. - - - - Integer which specifies the first index to be used for distinguishing - snapshots. Identifiers are defined either implicitly or explicitly. - For implicit indexing the identifiers are defined on the - interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate - if the identifiers are expected to start from 1 (referred to as - Fortran-/Matlab-) or from 0 (referred to as C-, Python-style index - notation) respectively. - - - - - - Summary quantities which are the result of some post-processing of - the snapshot data (averaging, integrating, interpolating). - Frequently used descriptors from continuum mechanics and thermodynamics - can be used here. A few examples are given. Each descriptor is currently - modelled as an instance of an NXprocess because it is relevant to - understand how the descriptors are computed. - - - - - - - - - - - - - - Measured or simulated physical time stamp for this snapshot. - Not to be confused with wall-clock timing or profiling data. - - - - - Iteration or increment counter. - - - - - - - - - - Conceptually distinguished object/feature in the ROI/ - system with some relevance. Instances of NXms_feature_set can - be nested to build a hierarchy of logically-related objects. - - A typical example for MD simulations is to have one - ms_feature_set for the atoms which is the parent to another - ms_feature_set for monomers/molecules/proteins which is then the - parent to another ms_feature_set for the secondary, another feature_set - for the tertiary, and the parent for another feature_set for the - quaternary structure. - - Another typical example from materials engineering is to have - one ms_feature_set for crystals (grains/phases) which serves as - the parent to another ms_feature_set for interfaces between these - crystals which then is the parent for another ms_feature_set to - describe the triple junctions which is then the parent for the - quadruple/higher-order junctions between which connect the - triple lines. - - Another example from discrete dislocation dynamics could be to - have one ms_feature_set for the dislocations (maybe separate - sets for each dislocation type or family) which are then - parents to other ms_feature_set which describe junctions between - dislocations or features along the dislocation line network. - - - - - - Details about the orientation distribution function - within the entire domain. - - - - With which method was the ODF approximated? - - - - - - TO BE DEFINED - - - - - TO BE DEFINED - - - - - Collection of texture components commonly referred to. - - - - Reference to or definition of a coordinate system with - which the definitions are interpretable. - - - - - - - - - - - Parameterized orientations. - - - - - - - - - Name of each texture component, e.g. Cube, Dillamore, Y. - - - - - - - - The portion of orientation space integrated over - to compute the volume fraction. - - - - - - - - The volume fraction of each texture component. - - - - - - - - - - - Details about the disorientation distribution function - within the entire domain. - - - - - Details about the grain boundary character distribution - within the entire domain. - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXms_kanapy_results.nxdl.xml b/contributed_definitions/NXms_kanapy_results.nxdl.xml deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml index 421d336baf..940e46503c 100644 --- a/contributed_definitions/nyaml/NXcrystal_structure.yaml +++ b/contributed_definitions/nyaml/NXcrystal_structure.yaml @@ -170,9 +170,9 @@ NXcrystal_structure(NXobject): with analyzed orientation maps this field stores how many scan points of the map were identified as that phase. unit: NX_UNITLESS - ipfID(NXms_ipf): - pfID(NXms_pf): - odfID(NXms_odf): + ipfID(NXmicrostructure_ipf): + pfID(NXmicrostructure_pf): + odfID(NXmicrostructure_odf): # here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) # can give some good suggestions on how to improve and ideally make even # more general this section diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml index 2acf65ec86..d5d6e1dd5b 100644 --- a/contributed_definitions/nyaml/NXem_correlation.yaml +++ b/contributed_definitions/nyaml/NXem_correlation.yaml @@ -128,8 +128,8 @@ NXem_correlation(NXem_method): The result of orientation microscopy methods are maps of local orientation and thermodynamic phase (crystal structure) pieces of information. Virtually all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can + a workflow of steps which are covered though by the NXmicrostructure partner application + definition. The respective source of the data in an instance of NXmicrostructure can again be a link or reference to an instance of NXem_ebsd to complete the chain of provenance. (NXcrystal_structure): diff --git a/contributed_definitions/nyaml/NXem_ebsd.yaml b/contributed_definitions/nyaml/NXem_ebsd.yaml index a53728fffb..a1915830a4 100644 --- a/contributed_definitions/nyaml/NXem_ebsd.yaml +++ b/contributed_definitions/nyaml/NXem_ebsd.yaml @@ -363,10 +363,10 @@ NXem_ebsd(NXem_method): doc: | Number of scan points in the original mapping. unit: NX_UNITLESS - odfID(NXms_odf): - pID(NXms_pf): - ipfID(NXms_ipf): - microstructureID(NXms_recon): + odfID(NXmicrostructure_odf): + pID(NXmicrostructure_pf): + ipfID(NXmicrostructure_ipf): + microstructureID(NXmicrostructure_recon): # overview over the entire map, rediscretized on a tight aabb roi(NXdata): doc: | diff --git a/contributed_definitions/nyaml/NXimage_r_set_diff.yaml b/contributed_definitions/nyaml/NXimage_r_set_diff.yaml index 5a0e27e283..9b79d249d3 100644 --- a/contributed_definitions/nyaml/NXimage_r_set_diff.yaml +++ b/contributed_definitions/nyaml/NXimage_r_set_diff.yaml @@ -8,7 +8,7 @@ doc: | Steps of post-processing the diffraction patterns should be documented using method-specific specialized base classes. All eventual post-processing of - resulting orientation maps (2D or 3D) should be documented via :ref:`NXms_recon`. + resulting orientation maps (2D or 3D) should be documented via :ref:`NXmicrostructure_recon`. To implement an example how this base class can be used we focused in FAIRmat on Kikuchi diffraction pattern here specifically the research community @@ -119,5 +119,5 @@ NXimage_r_set_diff(NXimage_r_set): # the spatial arrangement of the microstructural features, the individual # (thermodynamic, chemo-mechanical) properties of the features with the # properties of materials at a coarser scale. -# With NXem and related NXms base classes we propose a covering +# With NXem and related NXmicrostructure base classes we propose a covering # and general solution how to handle such (meta)data with NeXus. diff --git a/contributed_definitions/nyaml/NXms.yaml b/contributed_definitions/nyaml/NXmicrostructure_blueprint.txt similarity index 98% rename from contributed_definitions/nyaml/NXms.yaml rename to contributed_definitions/nyaml/NXmicrostructure_blueprint.txt index f0ea0e3e27..fc1873e27b 100644 --- a/contributed_definitions/nyaml/NXms.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_blueprint.txt @@ -40,7 +40,7 @@ symbols: # Some simulations are cross-scale (classical MD at the cutting edge with micrometer crystal plasticity microsecond and/or annealing at # ns time scale) MD with classical vs abinitio-informed potential for studying evolution of mechanisms and phenomena at different length scales type: group -NXms(NXobject): +NXmicrostructure(NXobject): (NXentry): \@version: doc: | @@ -51,7 +51,7 @@ NXms(NXobject): definition: doc: | NeXus NXDL schema to which this file conforms. - enumeration: [NXms] + enumeration: [NXmicrostructure] workflow_identifier: doc: | Ideally, a (globally) unique persistent identifier @@ -260,7 +260,7 @@ NXms(NXobject): dimensions: rank: 1 dim: [[1, n_b]] - snapshot_set(NXms_snapshot_set): + snapshot_set(NXmicrostructure_snapshot_set): doc: | Collection of microstructural data observed/simulated. identifier_offset(NX_UINT): @@ -305,7 +305,7 @@ NXms(NXobject): # time-resolved results for individual snapshots # virtually all computer simulations and all experiments always probe # snapshots - MS_SNAPSHOT(NXms_snapshot): + MS_SNAPSHOT(NXmicrostructure_snapshot): time(NX_NUMBER): unit: NX_TIME doc: | @@ -335,11 +335,11 @@ NXms(NXobject): # damage # thermal # composition - MS_FEATURE_SET(NXms_feature_set): + MS_FEATURE_SET(NXmicrostructure_feature_set): exists: ['min', '0', 'max', 'unbounded'] doc: | Conceptually distinguished object/feature in the ROI/ - system with some relevance. Instances of NXms_feature_set can + system with some relevance. Instances of NXmicrostructure_feature_set can be nested to build a hierarchy of logically-related objects. A typical example for MD simulations is to have one @@ -363,7 +363,7 @@ NXms(NXobject): parents to other ms_feature_set which describe junctions between dislocations or features along the dislocation line network. - # respective application definitions based on NXms should add and + # respective application definitions based on NXmicrostructure should add and # specialize odf(NXprocess): exists: optional diff --git a/contributed_definitions/nyaml/NXms_feature_set.yaml b/contributed_definitions/nyaml/NXmicrostructure_feature_set.yaml similarity index 83% rename from contributed_definitions/nyaml/NXms_feature_set.yaml rename to contributed_definitions/nyaml/NXmicrostructure_feature_set.yaml index 30079d3b52..eb9c45048c 100644 --- a/contributed_definitions/nyaml/NXms_feature_set.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_feature_set.yaml @@ -12,23 +12,23 @@ symbols: Number of types in the dictionary of human-readable types of features. n_parent_ids: | Total number of parent identifier. -# NXms_feature_set can be used e.g. as groups inside instances of NXms_snapshot +# NXmicrostructure_feature_set can be used e.g. as groups inside instances of NXmicrostructure_snapshot # for an MD simulation each timestep is such snapshot all snapshot for a set -# which is the parent group that has all these NXms_snapshot instances as childs +# which is the parent group that has all these NXmicrostructure_snapshot instances as childs # time_stamp: # simulated, physical # Thea, Joseph, Lauri, Dinga (TJLD) just for comparison for each group and field to what this would map in their model for the MDTutorial 2 type: group -NXms_feature_set(NXobject): +NXmicrostructure_feature_set(NXobject): # TJLD: this class represents a generalization of AtomGroups - # TJLD: one such for atoms(NXms_feature_set) - # TJLD: one such for atom_groups(NXms_feature_set) + # TJLD: one such for atoms(NXmicrostructure_feature_set) + # TJLD: one such for atom_groups(NXmicrostructure_feature_set) # TJLD: but not one for every molecule, i.e. all molecules and how their atoms with ids are related to atoms ids is concatenated - # TJLD: clearly there are two possibilities: either concatenate or make one NXms_feature_set for each molecule or component in the topology hierarchy + # TJLD: clearly there are two possibilities: either concatenate or make one NXmicrostructure_feature_set for each molecule or component in the topology hierarchy # TJLD: however the here proposed design generalizes the arbitrary (microstructural) features and computational geometry based coarse-grained representations \@depends_on(NX_CHAR): # TJLD: not required it is currently assumed that features are always build from atoms and this relation is shown using their ids, integers on [0, n_atoms-1] doc: | - Name (or link?) to another NXms_feature_set which defines features what are + Name (or link?) to another NXmicrostructure_feature_set which defines features what are assumed as the parents/super_features of all members in this feature set. If depends_on is set to "." or this attribute is not defined in an instance of this application definition, assume that this feature_set instance @@ -40,11 +40,11 @@ NXms_feature_set(NXobject): # more efficient as in the current design each molecule would again be a group # and having millions of groups comes with e.g. HDF5 with substantial overlap # I faced this when storing grains from micro-scale continuum crystal growth simulations - # TJLD: is_molecule(NX_BOOLEAN): not used, could however be added in an appdef which uses instances of NXms_feature_set - # TJLD: the key point we can use NXms_feature_set in the same way as currently TJLD use atoms and atoms/atom_groups/molecule0, */molecule1, ... + # TJLD: is_molecule(NX_BOOLEAN): not used, could however be added in an appdef which uses instances of NXmicrostructure_feature_set + # TJLD: the key point we can use NXmicrostructure_feature_set in the same way as currently TJLD use atoms and atoms/atom_groups/molecule0, */molecule1, ... # but with the additional benefit of a much richer geometrical description and the details about the uncertainty of these descriptions - # I can also imagine that materials engineers e.g. can reuse NXms_feature_set in an application definition by just then naming - # their group e.g. grains(NXms_feature_set) and use in the application definition either only the (material point), interface network, or volumetric description + # I can also imagine that materials engineers e.g. can reuse NXmicrostructure_feature_set in an application definition by just then naming + # their group e.g. grains(NXmicrostructure_feature_set) and use in the application definition either only the (material point), interface network, or volumetric description dimensionality(NX_POSINT): # TJLD: not needed because they assume everything is 3d doc: | @@ -58,8 +58,8 @@ NXms_feature_set(NXobject): type_dict_keyword(NX_CHAR): # TJLD: equivalent to the controlled vocabulary term monomer or molecule, i.e. label # TJLD: but with the difference that in this NeXus design here different features can take different roles - # TJLD: and do not conceptually have to be atoms, alternatively one could also create an NXms_interface_set which - # TJLD: inherits from NXms_feature_set but would need to have no dimensionality + # TJLD: and do not conceptually have to be atoms, alternatively one could also create an NXmicrostructure_interface_set which + # TJLD: inherits from NXmicrostructure_feature_set but would need to have no dimensionality doc: | The keywords of the dictionary of human-readable types of features. Using terms from a community-agreed upon controlled vocabulary, e.g. @@ -119,9 +119,9 @@ NXms_feature_set(NXobject): # TJLD: this design here is different, TJLD give atom positions only (at least as of now) for the root of an object # TJLD: while all higher-order features that are connected through their assumed topology just refer to the atoms in the root # TJLD: via their IDs, TJLD design is ideal for systems build from atoms but would create unnecessary copies for higher-dimensional-type features - # TJLD: in fact initially I also thought it is useful to create an NXms_dislocation_set, and an NXms_atom_set but overall these are just - # specializations of NXms_feature_set. Instead I like the key approach in TJLD which is to nest instances of the same class in TJLD's case AtomGroups - # but here NXms_feature_set instances + # TJLD: in fact initially I also thought it is useful to create an NXmicrostructure_dislocation_set, and an NXmicrostructure_atom_set but overall these are just + # specializations of NXmicrostructure_feature_set. Instead I like the key approach in TJLD which is to nest instances of the same class in TJLD's case AtomGroups + # but here NXmicrostructure_feature_set instances doc: | Assumptions and parameter to arrive at geometric primitives to locate zero-dimensional/point-(like) features which are @@ -170,32 +170,32 @@ NXms_feature_set(NXobject): # how to map results from MD simulations was already sketched by the comments from TJLD # but ones more here stating it explicitly - # atoms(NXms_feature_set): + # atoms(NXmicrostructure_feature_set): # no \@depends_on: as everything is build spatiotemporally coarse-grained from the sampled atom positions and/or their trajectories - # dislocations(NXms_feature_set): + # dislocations(NXmicrostructure_feature_set): # \@depends_on: <>/atoms # is trivially the same case as was described already for the DDD simulation - # how to map from DREAM.3D to NXms_feature_set - # material_points(NXms_feature_set): # material points can be voxels of a grid (which should be specified with an instance of NXcg_grid) or real material points + # how to map from DREAM.3D to NXmicrostructure_feature_set + # material_points(NXmicrostructure_feature_set): # material points can be voxels of a grid (which should be specified with an instance of NXcg_grid) or real material points # no \@depends_on: "." required or value can be "." as material_points are considered the root - # grains(NXms_feature_set): + # grains(NXmicrostructure_feature_set): # \@depends_on: <>/material_points - # boundaries(NXms_feature_set): + # boundaries(NXmicrostructure_feature_set): # \@depends_on: <>/grains - # triple_lines(NXms_feature_set): + # triple_lines(NXmicrostructure_feature_set): # \@depends_on: <>/boundaries - # quadruple_junctions(NXms_feature_set): + # quadruple_junctions(NXmicrostructure_feature_set): # \@depends_on: <>/triple_lines - # how to map from e.g. DDD codes like ParaDis to NXms_feature_set - # dislocations(NXms_feature_set): - # either all types of dislocations are specified via the type_dict dictionary or by making several named instances of NXms_feature_set classes, i.e. groups - # multi_junctions(NXms_feature_set): + # how to map from e.g. DDD codes like ParaDis to NXmicrostructure_feature_set + # dislocations(NXmicrostructure_feature_set): + # either all types of dislocations are specified via the type_dict dictionary or by making several named instances of NXmicrostructure_feature_set classes, i.e. groups + # multi_junctions(NXmicrostructure_feature_set): # \@depends_on: <>/dislocations # how to describe e.g. 3D cracks - # cracks(NXms_feature_set): + # cracks(NXmicrostructure_feature_set): # you can use volumes and interfaces to describe explicitly the 3D geometry # alternatively you can @@ -220,9 +220,9 @@ NXms_feature_set(NXobject): # phaseId, is it a triple point between homophases or heterophases # V, list of x, y coordinates for the triple points # angles, trivial nextVertexId to triplePoint vertex angles - # grains(NXms_feature_set): - # boundaries(NXms_feature_set): - # alternatively one NXms_feature_set for homophase boundaries + # grains(NXmicrostructure_feature_set): + # boundaries(NXmicrostructure_feature_set): + # alternatively one NXmicrostructure_feature_set for homophase boundaries # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ # 15f205ec24e25536f17046f9540798e889bf21046d3e1e2a63ab9434e3f6ffa9 @@ -249,12 +249,12 @@ NXms_feature_set(NXobject): # # # # For further information, see http://www.nexusformat.org # --> -# # -# +# # # # The symbols used in the schema to specify e.g. dimensions of arrays. @@ -284,15 +284,15 @@ NXms_feature_set(NXobject): # Set of topological/spatial features in materials build from other features. # # # # # -# Name (or link?) to another NXms_feature_set which defines features what are +# Name (or link?) to another NXmicrostructure_feature_set which defines features what are # assumed as the parents/super_features of all members in this feature set. # If depends_on is set to "." or this attribute is not defined in an instance # of this application definition, assume that this feature_set instance @@ -306,11 +306,11 @@ NXms_feature_set(NXobject): # more efficient as in the current design each molecule would again be a group # and having millions of groups comes with e.g. HDF5 with substantial overlap # I faced this when storing grains from micro-scale continuum crystal growth simulations -# TJLD: is_molecule(NX_BOOLEAN): not used, could however be added in an appdef which uses instances of NXms_feature_set -# TJLD: the key point we can use NXms_feature_set in the same way as currently TJLD use atoms and atoms/atom_groups/molecule0, */molecule1, ... +# TJLD: is_molecule(NX_BOOLEAN): not used, could however be added in an appdef which uses instances of NXmicrostructure_feature_set +# TJLD: the key point we can use NXmicrostructure_feature_set in the same way as currently TJLD use atoms and atoms/atom_groups/molecule0, */molecule1, ... # but with the additional benefit of a much richer geometrical description and the details about the uncertainty of these descriptions -# I can also imagine that materials engineers e.g. can reuse NXms_feature_set in an application definition by just then naming -# their group e.g. grains(NXms_feature_set) and use in the application definition either only the (material point), interface network, or volumetric description--> +# I can also imagine that materials engineers e.g. can reuse NXmicrostructure_feature_set in an application definition by just then naming +# their group e.g. grains(NXmicrostructure_feature_set) and use in the application definition either only the (material point), interface network, or volumetric description--> # # # @@ -332,8 +332,8 @@ NXms_feature_set(NXobject): # # +# TJLD: and do not conceptually have to be atoms, alternatively one could also create an NXmicrostructure_interface_set which +# TJLD: inherits from NXmicrostructure_feature_set but would need to have no dimensionality--> # # The keywords of the dictionary of human-readable types of features. # Using terms from a community-agreed upon controlled vocabulary, e.g. @@ -410,9 +410,9 @@ NXms_feature_set(NXobject): # +# TJLD: in fact initially I also thought it is useful to create an NXmicrostructure_dislocation_set, and an NXmicrostructure_atom_set but overall these are just +# specializations of NXmicrostructure_feature_set. Instead I like the key approach in TJLD which is to nest instances of the same class in TJLD's case AtomGroups +# but here NXmicrostructure_feature_set instances--> # # Assumptions and parameter to arrive at geometric primitives # to locate zero-dimensional/point-(like) features which are @@ -476,29 +476,29 @@ NXms_feature_set(NXobject): # Sandor suggested it can be useful to also describe how one could transform system-specific atom positions from the system-focused coordinate system to a molecule- or atom-focused local coordinate system--> # -# -# # # +# grains(NXmicrostructure_feature_set): +# boundaries(NXmicrostructure_feature_set): +# # alternatively one NXmicrostructure_feature_set for homophase boundaries--> # diff --git a/contributed_definitions/nyaml/NXms_gragles_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml similarity index 99% rename from contributed_definitions/nyaml/NXms_gragles_config.yaml rename to contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml index cda806d3c4..798fdb9113 100644 --- a/contributed_definitions/nyaml/NXms_gragles_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml @@ -12,10 +12,10 @@ doc: | Details of the model are summarized in C. Mießen ``_. # symbols: # type: group -NXms_gragles_config(NXobject): +NXmicrostructure_gragles_config(NXobject): (NXentry): definition(NX_CHAR): - enumeration: [NXms_gragles_config] + enumeration: [NXmicrostructure_gragles_config] \@version(NX_CHAR): starting_configuration(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXms_imm_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml similarity index 98% rename from contributed_definitions/nyaml/NXms_imm_config.yaml rename to contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml index 6bf9a6ef7e..5031445500 100644 --- a/contributed_definitions/nyaml/NXms_imm_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml @@ -6,10 +6,10 @@ doc: | to be a homophase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. Grains can be modelled as elongated objects to mimic fundamental geometrical constraints of the interface network in deformed material. # symbols: # type: group -NXms_imm_config(NXobject): +NXmicrostructure_imm_config(NXobject): (NXentry): definition(NX_CHAR): - enumeration: [NXms_imm_config] + enumeration: [NXmicrostructure_imm_config] \@version(NX_CHAR): roi(NXroi): diff --git a/contributed_definitions/nyaml/NXms_ipf.yaml b/contributed_definitions/nyaml/NXmicrostructure_ipf.yaml similarity index 99% rename from contributed_definitions/nyaml/NXms_ipf.yaml rename to contributed_definitions/nyaml/NXmicrostructure_ipf.yaml index 11bfc59831..811d884472 100644 --- a/contributed_definitions/nyaml/NXms_ipf.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_ipf.yaml @@ -14,7 +14,7 @@ symbols: d: | Dimensionality of the mapping (either 2 or 3). type: group -NXms_ipf(NXprocess): +NXmicrostructure_ipf(NXprocess): \@depends_on(NX_CHAR): doc: | Reference to the coordinate system whereby the projection_direction is defined. @@ -68,7 +68,7 @@ NXms_ipf(NXprocess): The main purpose of this map is to offer a normalized default representation of the IPF map for consumption by a research data management system (RDMS). - This is aligned with the first aim of :ref:`NXms_ipf`, to bring colleagues and + This is aligned with the first aim of :ref:`NXmicrostructure_ipf`, to bring colleagues and users of IPF maps together to discuss which pieces of information need to be stored together. We are convinced a step-by-step design and community-driven discussion about which pieces of information should diff --git a/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml new file mode 100644 index 0000000000..4b02dc1a32 --- /dev/null +++ b/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml @@ -0,0 +1,65 @@ +category: application +doc: | + Application definition for the microstructure generator kanapy from ICAMS Bochum. + + * `A. Hartmeier et al. `_ + + A draft application definition to support discussion within the infrastructure use case IUC07 of the + NFDI-MatWerk consortium of the German NFDI working on a data model for documenting simulations + of spatiotemporal microstructure evolution with scientific software from this community. +type: group +NXmicrostructure_kanapy_results(NXobject): + (NXentry): + definition(NX_CHAR): + # \@version: [NXmicrostructure_kanapy_results] + description(NX_CHAR): + doc: | + Discouraged free-text field to add further details to the computation. + start_time(NX_DATETIME): # better with UTC + end_time(NX_DATETIME): # better to get elapsed time + exists: recommended + profiling(NXcs_profiling): + exists: optional + (NXuser): # could use owner(NXuser) meaning a special type of user + exists: [min, 0, max, infty] + # kanapy, the script because this is also a program /Users/alexander/Codes/kanapy/examples/RVE_generation/create_rve.py + program1(NXprogram): + program(NX_CHAR): + \@version(NX_CHAR): + \@url(NX_CHAR): # https://github.com/ICAMS/Kanapy.git + exists: recommended + program2(NXprogram): + program(NX_CHAR): + \@version(NX_CHAR): + \@url(NX_CHAR): + exists: recommended + environment(NXobject): + exists: optional + doc: | + Programs and libraries representing the computational environment + programID(NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + # no units instead labelled-property graph concepts with units + microstructureID(NXmicrostructure_recon): + exists: [min, 1, max, infty] + (NXcg_grid): # size but much more capable + exists: optional + cell_dimensions(NX_NUMBER): + extent(NX_INT): + origin(NX_NUMBER): + symmetry(NX_CHAR): + position(NX_NUMBER): + exists: recommended + coordinate(NX_INT): + exists: recommended + bounding_box(NXcg_polyhedron_set): + exists: recommended + number_of_boundaries(NX_INT): + exists: recommended + boundaries(NX_CHAR): + exists: recommended + boundary_conditions(NX_INT): + exists: recommended + # populate further based on appdefs NXmicrostructure_score_results and NXmicrostructure_gragles_results diff --git a/contributed_definitions/nyaml/NXms_mtex_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_mtex_config.yaml similarity index 99% rename from contributed_definitions/nyaml/NXms_mtex_config.yaml rename to contributed_definitions/nyaml/NXmicrostructure_mtex_config.yaml index b8fee982d5..041c57987d 100644 --- a/contributed_definitions/nyaml/NXms_mtex_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_mtex_config.yaml @@ -6,7 +6,7 @@ doc: | See `R. Hielscher et al. `_ and the `MTex source code `_ for details. type: group -NXms_mtex_config(NXobject): +NXmicrostructure_mtex_config(NXobject): conventions(NXcollection): doc: | Reference frame and orientation conventions. diff --git a/contributed_definitions/nyaml/NXms_odf.yaml b/contributed_definitions/nyaml/NXmicrostructure_odf.yaml similarity index 99% rename from contributed_definitions/nyaml/NXms_odf.yaml rename to contributed_definitions/nyaml/NXmicrostructure_odf.yaml index 92ad96589a..3313d17f36 100644 --- a/contributed_definitions/nyaml/NXms_odf.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_odf.yaml @@ -11,7 +11,7 @@ symbols: k: | Number of local maxima evaluated in the component analysis. type: group -NXms_odf(NXprocess): +NXmicrostructure_odf(NXprocess): configuration(NXobject): doc: | Details about the algorithm used for computing the ODF. diff --git a/contributed_definitions/nyaml/NXms_pf.yaml b/contributed_definitions/nyaml/NXmicrostructure_pf.yaml similarity index 98% rename from contributed_definitions/nyaml/NXms_pf.yaml rename to contributed_definitions/nyaml/NXmicrostructure_pf.yaml index 09ab12f785..609d1ef6c1 100644 --- a/contributed_definitions/nyaml/NXms_pf.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_pf.yaml @@ -7,7 +7,7 @@ symbols: n_x: | Number of pixel per pole figure in the fast direction. type: group -NXms_pf(NXprocess): +NXmicrostructure_pf(NXprocess): configuration(NXobject): doc: | Details about the algorithm that was used to compute the pole figure. diff --git a/contributed_definitions/nyaml/NXms_recon.yaml b/contributed_definitions/nyaml/NXmicrostructure_recon.yaml similarity index 94% rename from contributed_definitions/nyaml/NXms_recon.yaml rename to contributed_definitions/nyaml/NXmicrostructure_recon.yaml index 050ae08d03..609b0b17a9 100644 --- a/contributed_definitions/nyaml/NXms_recon.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_recon.yaml @@ -8,8 +8,8 @@ doc: | the base class does not include time-dependent descriptions for the sake of clarity and because of the fact that virtually all simulations or experiments probe time by sampling. Therefore, time-dependent state descriptions should - be realized with creating a set of :ref:`NXms_snapshot_set` with instances of - :ref:`NXms_snapshot` using e.g. :ref:`NXms_recon` base class instances. + be realized with creating a set of :ref:`NXmicrostructure_snapshot_set` with instances of + :ref:`NXmicrostructure_snapshot` using e.g. :ref:`NXmicrostructure_recon` base class instances. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -42,7 +42,7 @@ symbols: n_q: | The number of quadruple junctions. type: group -NXms_recon(NXobject): +NXmicrostructure_recon(NXobject): # as e.g. a result of one grain reconstruction with MTex or othe # grain reconstruction software in commercial tools # the idea is we may wish to run as many grain reconstructions as we want... @@ -77,7 +77,7 @@ NXms_recon(NXobject): # ms_feature_set1 # we could also enumerate instances ms_feature_setID here because configuration # may specify a range of different parameter resulting in multiple ms_feature_sets - # dimensionality(N) composed from NXms_feature_set base: + # dimensionality(N) composed from NXmicrostructure_feature_set base: # controlled vocabulary of base class instances to be used to inform about the # discretization of these features instances to discretize the features # wherever possible the computational geometry specific instances whose @@ -96,7 +96,7 @@ NXms_recon(NXobject): # ONE DIMENSIONAL FEATURES # TWO DIMENSIONAL FEATURES - crystal_projections(NXms_feature_set): + crystal_projections(NXmicrostructure_feature_set): doc: | Projections of crystals on the sample surface as typically characterized with optical or electron microscopy. @@ -109,7 +109,7 @@ NXms_recon(NXobject): representation (projection) of the characterized material. For true volumetric techniques use the specifically - specialized crystals :ref:`NXms_feature_set` instead. + specialized crystals :ref:`NXmicrostructure_feature_set` instead. See stereology literature for more details e.g. E.E. Underwood's book entitled Quantitative Stereology number_of_crystals(NX_UINT): @@ -164,7 +164,7 @@ NXms_recon(NXobject): Calibrated area of surrounded by the polyline about each crystal. unit: NX_AREA dim: (n_c_two,) - interface_projections(NXms_feature_set): + interface_projections(NXmicrostructure_feature_set): # grain boundaries have a network of line-like defects, its explicit description # often generates unnecessary information duplication and cluttering, # therefore here a compact and suggestion how to store such data @@ -187,7 +187,7 @@ NXms_recon(NXobject): dim: (n_i_two, 2) \@depends_on(NX_CHAR): doc: | - The specific crystal_projections(NXms_feature_set) instance + The specific crystal_projections(NXmicrostructure_feature_set) instance to resolve crystal identifier. # ii) Set of pair of topologically connected triple points triple_points(NX_INT): @@ -199,7 +199,7 @@ NXms_recon(NXobject): dim: (n_i_two, 2) \@depends_on(NX_CHAR): doc: | - The specific triple_line_projections(NXms_feature_set) instance + The specific triple_line_projections(NXmicrostructure_feature_set) instance whereby to resolve triple_point identifier. # alternatively which polyline of adjoining interfaces # properties, descriptors @@ -233,7 +233,7 @@ NXms_recon(NXobject): Identifier for each interface using explicit indexing. unit: NX_UNITLESS dim: (n_i_two,) - triple_line_projections(NXms_feature_set): + triple_line_projections(NXmicrostructure_feature_set): # only for 2D, quad junction is the equivalent for 3D is not a triple_line # four alternative descriptors with different strength to specify spatial # or logical information about the triple junction feature set. @@ -293,7 +293,7 @@ NXms_recon(NXobject): dim: (n_t_two, 3) \@depends_on(NX_CHAR): doc: | - The specific interface_projections(NXms_feature_set) + The specific interface_projections(NXmicrostructure_feature_set) instance whereby to resolve interface identifiers. # ii) a triplet of line segment identifier whereby the point-like features # is assumed discretized via three polylines representing interfaces diff --git a/contributed_definitions/nyaml/NXms_score_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml similarity index 99% rename from contributed_definitions/nyaml/NXms_score_config.yaml rename to contributed_definitions/nyaml/NXmicrostructure_score_config.yaml index 4e58e95872..b441159710 100644 --- a/contributed_definitions/nyaml/NXms_score_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml @@ -9,11 +9,11 @@ symbols: n_su: | Number of solitary unit domains to export. type: group -NXms_score_config(NXobject): +NXmicrostructure_score_config(NXobject): (NXentry): definition(NX_CHAR): \@version(NX_CHAR): - enumeration: [NXms_score_config] + enumeration: [NXmicrostructure_score_config] PROGRAM(NXprogram): program_name: \@version: @@ -342,7 +342,7 @@ NXms_score_config(NXobject): # # # # For further information, see http://www.nexusformat.org # --> -# +# # # # @@ -374,7 +374,7 @@ NXms_score_config(NXobject): # Official NeXus NXDL schema with which this file was written. # # -# +# # # # diff --git a/contributed_definitions/nyaml/NXms_score_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml similarity index 98% rename from contributed_definitions/nyaml/NXms_score_results.yaml rename to contributed_definitions/nyaml/NXmicrostructure_score_results.yaml index acc6f3dff2..c00acc8264 100644 --- a/contributed_definitions/nyaml/NXms_score_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml @@ -31,13 +31,13 @@ symbols: n_grains: | Number of grains in the computer simulation. -# inspect comments behind NXms +# inspect comments behind NXmicrostructure type: group -NXms_score_results(NXobject): +NXmicrostructure_score_results(NXobject): (NXentry): definition(NX_CHAR): \@version(NX_CHAR): - enumeration: [NXms_score_results] + enumeration: [NXmicrostructure_score_results] analysis_identifier: doc: | Ideally, a (globally) unique persistent identifier @@ -264,7 +264,7 @@ NXms_score_results(NXobject): dimensions: rank: 1 dim: [[1, n_b]] - snapshot_set(NXms_snapshot_set): + snapshot_set(NXmicrostructure_snapshot_set): doc: | Collection of microstructural data observed/simulated. identifier_offset(NX_UINT): @@ -322,7 +322,7 @@ NXms_score_results(NXobject): # time-resolved results for individual snapshots # virtually all computer simulations and all experiments always probe # snapshots - MS_SNAPSHOT(NXms_snapshot): + MS_SNAPSHOT(NXmicrostructure_snapshot): time(NX_NUMBER): unit: NX_TIME doc: | @@ -357,7 +357,7 @@ NXms_score_results(NXobject): rank: 3 dim: [[1, n_x], [2, n_y], [3, n_z]] - # check comments behind NXms + # check comments behind NXmicrostructure recrystallization_front(NXprocess): exists: recommended doc: | diff --git a/contributed_definitions/nyaml/NXms_snapshot.yaml b/contributed_definitions/nyaml/NXmicrostructure_snapshot.yaml similarity index 94% rename from contributed_definitions/nyaml/NXms_snapshot.yaml rename to contributed_definitions/nyaml/NXmicrostructure_snapshot.yaml index 8be2a1f7ac..5be07fe67d 100644 --- a/contributed_definitions/nyaml/NXms_snapshot.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_snapshot.yaml @@ -5,7 +5,7 @@ symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. type: group -NXms_snapshot(NXobject): +NXmicrostructure_snapshot(NXobject): comment: doc: | Is this time for a measurement or a simulation. @@ -45,7 +45,7 @@ NXms_snapshot(NXobject): # # # # For further information, see http://www.nexusformat.org # --> -# +# # # # The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXms_snapshot_set.yaml b/contributed_definitions/nyaml/NXmicrostructure_snapshot_set.yaml similarity index 94% rename from contributed_definitions/nyaml/NXms_snapshot_set.yaml rename to contributed_definitions/nyaml/NXmicrostructure_snapshot_set.yaml index 01ce5374a2..a6b2da67b1 100644 --- a/contributed_definitions/nyaml/NXms_snapshot_set.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_snapshot_set.yaml @@ -5,7 +5,7 @@ symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. type: group -NXms_snapshot_set(NXobject): +NXmicrostructure_snapshot_set(NXobject): comment: doc: | Is this set describing a measurement or a simulation? @@ -28,7 +28,7 @@ NXms_snapshot_set(NXobject): # if we give the names of the snapshots free via making them all capital # how can we assure that snapshots are numbered consecutively? # MS_SNAPSHOT - (NXms_snapshot): + (NXmicrostructure_snapshot): # exists: [min, 0, max, infty] @@ -57,7 +57,7 @@ NXms_snapshot_set(NXobject): # # # # For further information, see http://www.nexusformat.org # --> -# +# # # # The symbols used in the schema to specify e.g. dimensions of arrays. @@ -93,6 +93,6 @@ NXms_snapshot_set(NXobject): # if we give the names of the snapshots free via making them all capital # how can we assure that snapshots are numbered consecutively? # MS_SNAPSHOT--> -# +# # # diff --git a/contributed_definitions/nyaml/NXms_kanapy_results.yaml b/contributed_definitions/nyaml/NXms_kanapy_results.yaml deleted file mode 100644 index 73c10f7451..0000000000 --- a/contributed_definitions/nyaml/NXms_kanapy_results.yaml +++ /dev/null @@ -1,41 +0,0 @@ -(NXentry): - definition(NX_CHAR): - \@version: [NXms_kanapy_results] - experiment_free_text(NX_CHAR): # description - start_time(NX_DATETIME): # better with UTC - end_time(NX_DATETIME): # better to get elapsed time - exists: recommended - profiling(NXcs_profiling): - (NXuser): # could use owner(NXuser) meaning a special type of user - name(NX_CHAR): # alexander - affiliation(NX_CHAR): # ICAMS... - program1(NXprogram): - program(NX_CHAR): # kanapy - \@version(NX_CHAR): # 6.1.3 - \@url(NX_CHAR): # https://github.com/ICAMS/Kanapy.git - program2(NXprogram): - program(NX_CHAR): # the script because this is also a program /Users/alexander/Codes/kanapy/examples/RVE_generation/create_rve.py - \@version(NX_CHAR): # version and execution environment in which this script is executed not documented! - # could be documented e.g. as follows: - environment(NXobject): - (NXprogram): - exists: [min, 1, max, infty] - program(NX_CHAR): - \@version(NX_CHAR): - # no units instead labelled-property graph concepts with units - (NXms_recon): - (NXcg_grid): # size but much more capable - ve(NXcg_polyhedron_set): # the volume element - aabb(NXcg_hexahedron_set): # the bounding box - boundary_conditions(NX_CHAR): - doc: | - Boundary condition for each boundary of the VE discretized by (NXcg_grid) - enumeration: [open, mirror, periodic] - dim: (6,) - grains(NXobject): - orientation(NXrotation_set): # much more explicit - phase_identifier(NX_UINT): # and efficient - phase(NXobject): - exists: [min, 0, max, infty] - # identifier_offset(NX_UINT): - # crystal_structure etc. \ No newline at end of file diff --git a/contributed_definitions/temp_NXms_kanapy_results.nxdl.xml b/contributed_definitions/temp_NXms_kanapy_results.nxdl.xml deleted file mode 100644 index e69de29bb2..0000000000 From a56552bddd7aa9917dcb8e12ccf0d048d3ef6083 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 9 Jul 2024 13:11:25 +0200 Subject: [PATCH 0782/1012] remove changes to polarization in NXbeam --- base_classes/NXbeam.nxdl.xml | 41 +------------ base_classes/nyaml/NXbeam.yaml | 106 +++++++-------------------------- 2 files changed, 25 insertions(+), 122 deletions(-) diff --git a/base_classes/NXbeam.nxdl.xml b/base_classes/NXbeam.nxdl.xml index 67c6dc4b26..e8e44d15f9 100644 --- a/base_classes/NXbeam.nxdl.xml +++ b/base_classes/NXbeam.nxdl.xml @@ -219,31 +219,12 @@ - Incident polarization as a Stokes vector - on entering beamline component + Polarization vector on entering beamline component - - - The units for this observable are not included in the NIAC list. - Responsibility on correct formatting and parsing is handed to the user - by using `NX_ANY`. Correct parsing can still be implemented by using - this attribute. - - | Fill with: - - * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). - * The unit unidata name if the unit has a name (Example: farad for capacitance). - * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and - does not have a name. - - Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). - Here: SI units are V2/m2. - - @@ -253,24 +234,6 @@ - - - The units for this observable are not included in the NIAC list. - Responsibility on correct formatting and parsing is handed to the user - by using `NX_ANY`. Correct parsing can still be implemented by using - this attribute. - - | Fill with: - - * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). - * The unit unidata name if the unit has a name (Example: farad for capacitance). - * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and - does not have a name. - - Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). - Here: SI units are V2/m2. - - @@ -495,7 +458,7 @@ - + Gives the beam device which this beam will interact with next. diff --git a/base_classes/nyaml/NXbeam.yaml b/base_classes/nyaml/NXbeam.yaml index 527da97db2..f2ec379f86 100644 --- a/base_classes/nyaml/NXbeam.yaml +++ b/base_classes/nyaml/NXbeam.yaml @@ -172,28 +172,10 @@ NXbeam(NXobject): incident_polarization(NX_NUMBER): unit: NX_ANY doc: | - Incident polarization as a Stokes vector - on entering beamline component + Polarization vector on entering beamline component dimensions: rank: 2 dim: [[1, nP], [2, 2]] - \@units: - type: NX_CHAR - doc: | - The units for this observable are not included in the NIAC list. - Responsibility on correct formatting and parsing is handed to the user - by using `NX_ANY`. Correct parsing can still be implemented by using - this attribute. - - | Fill with: - - * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). - * The unit unidata name if the unit has a name (Example: farad for capacitance). - * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and - does not have a name. - - Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). - Here: SI units are V2/m2. final_polarization(NX_NUMBER): unit: NX_ANY doc: | @@ -201,23 +183,6 @@ NXbeam(NXobject): dimensions: rank: 2 dim: [[1, nP], [2, 2]] - \@units: - type: NX_CHAR - doc: | - The units for this observable are not included in the NIAC list. - Responsibility on correct formatting and parsing is handed to the user - by using `NX_ANY`. Correct parsing can still be implemented by using - this attribute. - - | Fill with: - - * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). - * The unit unidata name if the unit has a name (Example: farad for capacitance). - * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and - does not have a name. - - Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). - Here: SI units are V2/m2. incident_polarization_stokes(NX_NUMBER): unit: NX_ANY doc: | @@ -394,22 +359,23 @@ NXbeam(NXobject): doc: | Points to the path to a field defining the location on which this depends or the string "." for origin. - previous_device: + previous_device: doc: | Indicates the beam device from which this beam originates. This defines, whether the beam in an "input" or "output" beam. - next_device: + next_device: doc: | Gives the beam device which this beam will interact with next. + # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# dbe7fba854b6a29c068ef96a3c8fbe28c8217579d5d8a990ffa730ecd269bf21 -# +# 99ae6b0983bbcf045b173aa2b48b0be9a1c93f34369e5ee59ddc12bdb3177db7 +# # # + + + + Application definition for documenting results with GraGLeS. + + + + + + + + + + diff --git a/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml b/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml new file mode 100644 index 0000000000..8d0f83356c --- /dev/null +++ b/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml @@ -0,0 +1,39 @@ + + + + + + + Application definition for documenting results obtained with the IMM structure + generator. + + + + + + + + + + diff --git a/contributed_definitions/NXslip_system_set.nxdl.xml b/contributed_definitions/NXmicrostructure_slip_system.nxdl.xml similarity index 91% rename from contributed_definitions/NXslip_system_set.nxdl.xml rename to contributed_definitions/NXmicrostructure_slip_system.nxdl.xml index 4e7d65b5c0..2138781ee3 100644 --- a/contributed_definitions/NXslip_system_set.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_slip_system.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -51,8 +51,8 @@ identifier(NX_UINT):--> +rank: 1 +dim: [[1, n]]--> Array of Miller indices which describe the crystallographic plane. diff --git a/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml new file mode 100644 index 0000000000..d254cf51b6 --- /dev/null +++ b/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml @@ -0,0 +1,10 @@ +category: application +doc: | + Application definition for documenting results with GraGLeS. +# symbols: +type: group +NXmicrostructure_gragles_results(NXobject): + (NXentry): + definition(NX_CHAR): + enumeration: [NXmicrostructure_gragles_results] + \@version(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml new file mode 100644 index 0000000000..d35f2fda42 --- /dev/null +++ b/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml @@ -0,0 +1,10 @@ +category: application +doc: | + Application definition for documenting results obtained with the IMM structure generator. +# symbols: +type: group +NXmicrostructure_imm_results(NXobject): + (NXentry): + definition(NX_CHAR): + enumeration: [NXmicrostructure_imm_results] + \@version(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXmicrostructure_slip_system.yaml b/contributed_definitions/nyaml/NXmicrostructure_slip_system.yaml new file mode 100644 index 0000000000..b39f082f95 --- /dev/null +++ b/contributed_definitions/nyaml/NXmicrostructure_slip_system.yaml @@ -0,0 +1,46 @@ +category: base +doc: | + Base class for describing a set of crystallographic slip systems. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n: | + Number of slip systems. +type: group +NXmicrostructure_slip_system(NXobject): + # number_of_objects(NX_UINT): + # identifier_offset(NX_UINT): + # identifier(NX_UINT): + lattice_type: + + # doc: Array of lattice types. + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, trigonal, hexagonal, cubic] + + # dimensions: + # rank: 1 + # dim: [[1, n]] + miller_plane(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Array of Miller indices which describe the crystallographic plane. + dimensions: + rank: 2 + dim: [[1, n], [2, i]] + + # fastest changing dimension needs to be i because for instance for hexagonal hkil is needed + miller_direction(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Array of Miller indices which describe the crystallographic direction. + dimensions: + rank: 2 + dim: [[1, n], [2, i]] + is_specific(NX_BOOLEAN): + unit: NX_UNITLESS + doc: | + For each slip system a marker whether the specified Miller indices + refer to the specific slip system or the set of crystallographic equivalent + slip systems of the respective family of slip systems. + dimensions: + rank: 1 + dim: [[1, n]] diff --git a/contributed_definitions/nyaml/NXslip_system_set.yaml b/contributed_definitions/nyaml/NXslip_system_set.yaml deleted file mode 100644 index 6eb2bdf13e..0000000000 --- a/contributed_definitions/nyaml/NXslip_system_set.yaml +++ /dev/null @@ -1,135 +0,0 @@ -category: base -doc: | - Base class for describing a set of crystallographic slip systems. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n: | - Number of slip systems. -type: group -NXslip_system_set(NXobject): - - # number_of_objects(NX_UINT): - # identifier_offset(NX_UINT): - # identifier(NX_UINT): - lattice_type: - - # doc: Array of lattice types. - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, trigonal, hexagonal, cubic] - - # dimensions: - # rank: 1 - # dim: [[1, n]] - miller_plane(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Array of Miller indices which describe the crystallographic plane. - dimensions: - rank: 2 - dim: [[1, n], [2, i]] - - # fastest changing dimension needs to be i because for instance for hexagonal hkil is needed - miller_direction(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Array of Miller indices which describe the crystallographic direction. - dimensions: - rank: 2 - dim: [[1, n], [2, i]] - is_specific(NX_BOOLEAN): - unit: NX_UNITLESS - doc: | - For each slip system a marker whether the specified Miller indices - refer to the specific slip system or the set of crystallographic equivalent - slip systems of the respective family of slip systems. - dimensions: - rank: 1 - dim: [[1, n]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e8cb089ac11808b81d9b8ee99ffc53037c3b26e4ded58f03a4053e327d5e68af -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of slip systems. -# -# -# -# -# Base class for describing a set of crystallographic slip systems. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Array of Miller indices which describe the crystallographic plane. -# -# -# -# -# -# -# -# -# -# Array of Miller indices which describe the crystallographic direction. -# -# -# -# -# -# -# -# -# For each slip system a marker whether the specified Miller indices -# refer to the specific slip system or the set of crystallographic equivalent -# slip systems of the respective family of slip systems. -# -# -# -# -# -# diff --git a/manual/source/classes/contributed_definitions/cgms-structure.rst b/manual/source/classes/contributed_definitions/cgms-structure.rst index a802096997..4fe1232c9a 100644 --- a/manual/source/classes/contributed_definitions/cgms-structure.rst +++ b/manual/source/classes/contributed_definitions/cgms-structure.rst @@ -182,22 +182,6 @@ not only for stencil-based methods: A base class to describe the relative orientation or rotation members of a set of features/objects. - :ref:`NXslip_system_set`: - A base class to describe a set of slip system/slip system family for - a given crystal structure. - - :ref:`NXms_feature_set`: - A base class to describe any nested set of features of a material at the - continuum-, micron-, or nano-scale, including representation of a topology - of molecules and atoms. - - :ref:`NXms_snapshot`: - A base class to describe the state of microstructural features - at a given point in time. - - :ref:`NXms_snapshot_set`: - A base class to store a set of :ref:`NXms_snapshot` objects. - :ref:`NXchemical_composition`: A base class to document (chemical) composition of a sample or a set of things. diff --git a/manual/source/classes/contributed_definitions/icme-structure.rst b/manual/source/classes/contributed_definitions/icme-structure.rst index 8c067978db..be103b4032 100644 --- a/manual/source/classes/contributed_definitions/icme-structure.rst +++ b/manual/source/classes/contributed_definitions/icme-structure.rst @@ -23,13 +23,25 @@ The following application definitions are proposed to support the discussion on materials-engineering-specific data schemas can connect to or be mapped on concepts which are equally modellable with NeXus: - :ref:`NXms`: + :ref:`NXmicrostructure`: An application definition for arbitrary spatiotemporally resolved simulations. - :ref:`NXms_recon`: + :ref:`NXmicrostructure_recon`: A base class for documenting results of reconstructed microstructures. - :ref:`NXms_score_config`, :ref:`NXms_score_results`: + :ref:`NXmicrostructure_score_config`, :ref:`NXmicrostructure_score_results`: A specific example of an application definition for documenting the configuration and results respectively of a computer simulation with the static recrystallization cellular automata model SCORE. + + :ref:`NXmicrostructure_gragles_config`, :ref:`NXmicrostructure_gragles_results`: + A specific example of an application definition for documenting the + configuration and results respectively of a computer simulation with + the grain growth level-set-based model GraGLeS. + + :ref:`NXmicrostructure_imm_config`, :ref:`NXmicrostructure_imm_results`: + A specific example of an application definition for documenting the + configuration and results respectively of a computer simulation with + the legacy microstructure synthesizer developed at the Institut für + Metallkunde und Metallphysik in Aachen. + From 0beac138b9672d4e16ce3f397d9eb7c8068ec3f9 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 9 Jul 2024 14:36:40 +0200 Subject: [PATCH 0785/1012] Removed the two tiny base classes NXmicrostructure_snapshot and *_set --- .../NXmicrostructure_gragles_results.nxdl.xml | 3 +- .../NXmicrostructure_imm_results.nxdl.xml | 3 +- .../NXmicrostructure_kanapy_results.nxdl.xml | 9 +- .../NXmicrostructure_pf.nxdl.xml | 2 +- .../NXmicrostructure_slip_system.nxdl.xml | 16 ++- .../NXmicrostructure_snapshot.nxdl.xml | 54 ---------- .../NXmicrostructure_snapshot_set.nxdl.xml | 62 ------------ .../NXmicrostructure_gragles_results.yaml | 3 +- .../nyaml/NXmicrostructure_imm_results.yaml | 3 +- .../NXmicrostructure_kanapy_results.yaml | 4 +- .../nyaml/NXmicrostructure_pf.yaml | 2 +- .../nyaml/NXmicrostructure_slip_system.yaml | 34 ++----- .../nyaml/NXmicrostructure_snapshot.yaml | 78 --------------- .../nyaml/NXmicrostructure_snapshot_set.yaml | 98 ------------------- 14 files changed, 34 insertions(+), 337 deletions(-) delete mode 100644 contributed_definitions/NXmicrostructure_snapshot.nxdl.xml delete mode 100644 contributed_definitions/NXmicrostructure_snapshot_set.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXmicrostructure_snapshot.yaml delete mode 100644 contributed_definitions/nyaml/NXmicrostructure_snapshot_set.yaml diff --git a/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml b/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml index 7b6fb51803..325798bc54 100644 --- a/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml @@ -32,7 +32,8 @@ symbols:--> - + diff --git a/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml b/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml index 8d0f83356c..236d2c871c 100644 --- a/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml @@ -33,7 +33,8 @@ symbols:--> - + diff --git a/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml b/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml index 72a018a872..aaa3c9d361 100644 --- a/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml @@ -32,8 +32,11 @@ of spatiotemporal microstructure evolution with scientific software from this community. - - + + + + + Discouraged free-text field to add further details to the computation. @@ -82,5 +85,5 @@ - + diff --git a/contributed_definitions/NXmicrostructure_pf.nxdl.xml b/contributed_definitions/NXmicrostructure_pf.nxdl.xml index fd16df61db..9892676578 100644 --- a/contributed_definitions/NXmicrostructure_pf.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_pf.nxdl.xml @@ -50,7 +50,7 @@ - Point group assumed for processing induced *sample symmetries* + Point group assumed for processing induced sample symmetries (according to International Table of Crystallography). diff --git a/contributed_definitions/NXmicrostructure_slip_system.nxdl.xml b/contributed_definitions/NXmicrostructure_slip_system.nxdl.xml index 2138781ee3..e037ee7484 100644 --- a/contributed_definitions/NXmicrostructure_slip_system.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_slip_system.nxdl.xml @@ -35,11 +35,10 @@ Base class for describing a set of crystallographic slip systems. - - - + + + Bravais lattice type + @@ -50,9 +49,6 @@ identifier(NX_UINT):--> - Array of Miller indices which describe the crystallographic plane. @@ -74,8 +70,8 @@ dim: [[1, n]]--> - For each slip system a marker whether the specified Miller indices - refer to the specific slip system or the set of crystallographic equivalent + For each slip system a marker whether the specified Miller indices refer to + the specific slip system or the set of crystallographic equivalent slip systems of the respective family of slip systems. diff --git a/contributed_definitions/NXmicrostructure_snapshot.nxdl.xml b/contributed_definitions/NXmicrostructure_snapshot.nxdl.xml deleted file mode 100644 index 0fe7ddadf8..0000000000 --- a/contributed_definitions/NXmicrostructure_snapshot.nxdl.xml +++ /dev/null @@ -1,54 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Base class for data on the state of the microstructure at a given - time/iteration. - - - - Is this time for a measurement or a simulation. - - - - - - - - - Measured or simulated physical time stamp for this snapshot. - Not to be confused with wall-clock timing or profiling data. - - - - - Iteration or increment counter. - - - diff --git a/contributed_definitions/NXmicrostructure_snapshot_set.nxdl.xml b/contributed_definitions/NXmicrostructure_snapshot_set.nxdl.xml deleted file mode 100644 index 42fe513867..0000000000 --- a/contributed_definitions/NXmicrostructure_snapshot_set.nxdl.xml +++ /dev/null @@ -1,62 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - A collection of spatiotemporal microstructure data. - - - - Is this set describing a measurement or a simulation? - - - - - - - - - Integer which specifies the first index to be used for distinguishing - snapshots. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - - diff --git a/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml index d254cf51b6..934ad4c99a 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml @@ -7,4 +7,5 @@ NXmicrostructure_gragles_results(NXobject): (NXentry): definition(NX_CHAR): enumeration: [NXmicrostructure_gragles_results] - \@version(NX_CHAR): + # \@version(NX_CHAR): + # TODO: populate further based on appdefs NXmicrostructure_score_results \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml index d35f2fda42..6c56dae7ef 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml @@ -7,4 +7,5 @@ NXmicrostructure_imm_results(NXobject): (NXentry): definition(NX_CHAR): enumeration: [NXmicrostructure_imm_results] - \@version(NX_CHAR): + # \@version(NX_CHAR): + # TODO: populate further based on appdefs NXmicrostructure_score_results and NXmicrostructure_gragles_results \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml index 4b02dc1a32..81e7aadea6 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml @@ -11,7 +11,7 @@ type: group NXmicrostructure_kanapy_results(NXobject): (NXentry): definition(NX_CHAR): - # \@version: [NXmicrostructure_kanapy_results] + enumeration: [NXmicrostructure_kanapy_results] description(NX_CHAR): doc: | Discouraged free-text field to add further details to the computation. @@ -62,4 +62,4 @@ NXmicrostructure_kanapy_results(NXobject): exists: recommended boundary_conditions(NX_INT): exists: recommended - # populate further based on appdefs NXmicrostructure_score_results and NXmicrostructure_gragles_results + # TODO: populate further based on appdefs NXmicrostructure_score_results diff --git a/contributed_definitions/nyaml/NXmicrostructure_pf.yaml b/contributed_definitions/nyaml/NXmicrostructure_pf.yaml index 609d1ef6c1..7885b23f8c 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_pf.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_pf.yaml @@ -18,7 +18,7 @@ NXmicrostructure_pf(NXprocess): (according to International Table of Crystallography). specimen_symmetry_point_group(NX_CHAR): doc: | - Point group assumed for processing induced *sample symmetries* + Point group assumed for processing induced sample symmetries (according to International Table of Crystallography). halfwidth(NX_NUMBER): doc: | diff --git a/contributed_definitions/nyaml/NXmicrostructure_slip_system.yaml b/contributed_definitions/nyaml/NXmicrostructure_slip_system.yaml index b39f082f95..36d437edac 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_slip_system.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_slip_system.yaml @@ -8,39 +8,25 @@ symbols: Number of slip systems. type: group NXmicrostructure_slip_system(NXobject): - # number_of_objects(NX_UINT): - # identifier_offset(NX_UINT): - # identifier(NX_UINT): - lattice_type: - - # doc: Array of lattice types. + lattice_type(NX_CHAR): + doc: | + Bravais lattice type enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, trigonal, hexagonal, cubic] - - # dimensions: - # rank: 1 - # dim: [[1, n]] miller_plane(NX_NUMBER): - unit: NX_UNITLESS doc: | Array of Miller indices which describe the crystallographic plane. - dimensions: - rank: 2 - dim: [[1, n], [2, i]] - + unit: NX_UNITLESS + dim: (n, i) # fastest changing dimension needs to be i because for instance for hexagonal hkil is needed miller_direction(NX_NUMBER): - unit: NX_UNITLESS doc: | Array of Miller indices which describe the crystallographic direction. - dimensions: - rank: 2 - dim: [[1, n], [2, i]] + unit: NX_UNITLESS + dim: (n, i) is_specific(NX_BOOLEAN): unit: NX_UNITLESS doc: | - For each slip system a marker whether the specified Miller indices - refer to the specific slip system or the set of crystallographic equivalent + For each slip system a marker whether the specified Miller indices refer to + the specific slip system or the set of crystallographic equivalent slip systems of the respective family of slip systems. - dimensions: - rank: 1 - dim: [[1, n]] + dim: (n,) diff --git a/contributed_definitions/nyaml/NXmicrostructure_snapshot.yaml b/contributed_definitions/nyaml/NXmicrostructure_snapshot.yaml deleted file mode 100644 index 5be07fe67d..0000000000 --- a/contributed_definitions/nyaml/NXmicrostructure_snapshot.yaml +++ /dev/null @@ -1,78 +0,0 @@ -category: base -doc: | - Base class for data on the state of the microstructure at a given time/iteration. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXmicrostructure_snapshot(NXobject): - comment: - doc: | - Is this time for a measurement or a simulation. - enumeration: [measurement, simulation] - time(NX_NUMBER): - unit: NX_TIME - doc: | - Measured or simulated physical time stamp for this snapshot. - Not to be confused with wall-clock timing or profiling data. - iteration(NX_INT): - unit: NX_UNITLESS - doc: | - Iteration or increment counter. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 727c20950297820e1d9da8230bb0ccaaeb162693eb09c7c72f831029a038bf23 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Base class for data on the state of the microstructure at a given -# time/iteration. -# -# -# -# Is this time for a measurement or a simulation. -# -# -# -# -# -# -# -# -# Measured or simulated physical time stamp for this snapshot. -# Not to be confused with wall-clock timing or profiling data. -# -# -# -# -# Iteration or increment counter. -# -# -# diff --git a/contributed_definitions/nyaml/NXmicrostructure_snapshot_set.yaml b/contributed_definitions/nyaml/NXmicrostructure_snapshot_set.yaml deleted file mode 100644 index a6b2da67b1..0000000000 --- a/contributed_definitions/nyaml/NXmicrostructure_snapshot_set.yaml +++ /dev/null @@ -1,98 +0,0 @@ -category: base -doc: | - A collection of spatiotemporal microstructure data. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXmicrostructure_snapshot_set(NXobject): - comment: - doc: | - Is this set describing a measurement or a simulation? - enumeration: [measurement, simulation] - identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer which specifies the first index to be used for distinguishing - snapshots. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - # should we rather name snapshots explicitly always snapshot_1, snapshot_2 - # in which case identifier fields are not required, on the other hand - # if we give the names of the snapshots free via making them all capital - # how can we assure that snapshots are numbered consecutively? - # MS_SNAPSHOT - (NXmicrostructure_snapshot): - - # exists: [min, 0, max, infty] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e9c6e090a782d50af20f1b70f91cd7299a386e1ad829ab70fea2cc1fbadff262 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# A collection of spatiotemporal microstructure data. -# -# -# -# Is this set describing a measurement or a simulation? -# -# -# -# -# -# -# -# -# Integer which specifies the first index to be used for distinguishing -# snapshots. Identifiers are defined either implicitly -# or explicitly. For implicit indexing the identifiers are defined on the -# interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. -# For explicit indexing the identifier array has to be defined. -# -# The identifier_offset field can for example be used to communicate if the -# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) -# or from 0 (referred to as C-, Python-style index notation) respectively. -# -# -# -# -# -# From 171e23a68ddbbb9355bfb0e39a992deed18ef867 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 9 Jul 2024 16:47:03 +0200 Subject: [PATCH 0786/1012] Refactored NXmicrostructure_feature_set to map to NXmicrostructure_recon and eventually make this NXmicrostructure --- .../NXimage_r_set_diff.nxdl.xml | 2 +- .../NXmicrostructure_feature_set.nxdl.xml | 316 ----------- .../NXmicrostructure_ipf.nxdl.xml | 187 +------ .../NXmicrostructure_odf.nxdl.xml | 51 +- .../NXmicrostructure_pf.nxdl.xml | 9 +- .../NXmicrostructure_recon.nxdl.xml | 435 +++++++-------- .../nyaml/NXimage_r_set_diff.yaml | 2 +- .../nyaml/NXmicrostructure_feature_set.yaml | 528 ------------------ .../nyaml/NXmicrostructure_ipf.yaml | 188 +------ .../nyaml/NXmicrostructure_odf.yaml | 47 +- .../nyaml/NXmicrostructure_pf.yaml | 26 +- .../nyaml/NXmicrostructure_recon.yaml | 375 ++++++------- 12 files changed, 497 insertions(+), 1669 deletions(-) delete mode 100644 contributed_definitions/NXmicrostructure_feature_set.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXmicrostructure_feature_set.yaml diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml index e1c2b45b85..a61f9a4b2e 100644 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -53,7 +53,7 @@ Steps of post-processing the diffraction patterns should be documented using method-specific specialized base classes. All eventual post-processing of - resulting orientation maps (2D or 3D) should be documented via :ref:`NXmicrostructure_recon`. + resulting orientation maps (2D or 3D) should be documented via NXmicrostructure. To implement an example how this base class can be used we focused in FAIRmat on Kikuchi diffraction pattern here specifically the research community diff --git a/contributed_definitions/NXmicrostructure_feature_set.nxdl.xml b/contributed_definitions/NXmicrostructure_feature_set.nxdl.xml deleted file mode 100644 index de78c4f64c..0000000000 --- a/contributed_definitions/NXmicrostructure_feature_set.nxdl.xml +++ /dev/null @@ -1,316 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Dimensionality - - - - - Cardinality/number of members/features in the feature set. - - - - - Number of types in the dictionary of human-readable types of features. - - - - - Total number of parent identifier. - - - - - Set of topological/spatial features in materials build from other features. - - - - - - Name (or link?) to another NXmicrostructure_feature_set which defines features what are - assumed as the parents/super_features of all members in this feature set. - If depends_on is set to "." or this attribute is not defined in an instance - of this application definition, assume that this feature_set instance - represents the root feature_set of the feature tree/graph. - - - - - - - What is the best matching description how dimensional the feature is. - - - - - - - - - - - How many features/members are in this set? - - - - - - The keywords of the dictionary of human-readable types of features. - Using terms from a community-agreed upon controlled vocabulary, e.g. - atom, solute, vacancy, monomer, molecule, anti-site, crowd_ion, - quadruple junction, triple line, disconnection, dislocation, - kink, jog, stacking_fault, homo_phase_boundary, hetero_phase_boundary, - surface, thermal_groove_root, precipitate, dispersoid, pore, crack - is recommended. - - - - - - - - - The integer identifier used to resolve of which type each feature is, - i.e. the values of the dictionary of human-readable types of features. - - - - - - - - For each feature in the set specify the associated number of identifier - to parent features as are resolvable via depends_on. - This array enables to compute the array interval from which details for - specific features can be extracted as if they would be stored in an own - group. - - - - - - - - Concatenated array of parent identifier for each feature (in the sequence) - according to identifier and how the identifier of features in the here - described feature set are defined (implicitly from 0, to c-1 or via explicit - identifier. - - - - - - - - - Integer which specifies the first index to be used for distinguishing - features. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish features for explicit indexing. - - - - - - - - - Assumptions and parameter to arrive at geometric primitives - to locate zero-dimensional/point-(like) features which are - discretized/represented by points. - - - - - Assumptions, parameters, and details how positional uncertainty - of the geometry is quantified. - - - - - - - Assumptions and parameters to arrive at geometric primitives - to locate one-dimensional/line-like features which are - discretized by polylines. - - - - - - Assumptions, parameters, and details how positional uncertainty - of the geometry is quantified. - - - - - - Assumptions and parameters to arrive at geometric primitives - to locate two-dimensional/interface features which are - discretized by triangulated surface meshes. - - - - - - Assumptions, parameters, and details how positional uncertainty - of the geometry is quantified. - - - - - - Assumptions and parameters to arrive at geometric primitives - to locate three-dimensional/volumetric features which are - discretized by triangulated surface meshes of polyhedra. - - - - - - Assumptions, parameters, and details how positional uncertainty - of the geometry is quantified. - - - - - - - - - - diff --git a/contributed_definitions/NXmicrostructure_ipf.nxdl.xml b/contributed_definitions/NXmicrostructure_ipf.nxdl.xml index fee309b054..d9ba1383f6 100644 --- a/contributed_definitions/NXmicrostructure_ipf.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_ipf.nxdl.xml @@ -23,7 +23,6 @@ --> - Number of pixel along the z slowest direction. @@ -53,18 +52,17 @@ Base class to store an inverse pole figure (IPF) mapping (IPF map). - + - Reference to the coordinate system whereby the projection_direction is defined. + Reference to an :ref:`NXcoordinate_system` in which the projection_direction is defined. - If the field depends_on is not provided but a parent of the instance - of this base class or its specialization defines an :ref:`NXcoordinate_system_set` - and exactly one :ref:`NXcoordinate_system`, the reference points to this system. + If the field depends_on is not provided but parents of the instance of this base class or its + specializations define an instance of :ref:`NXcoordinate_system`, projection_direction + is defined in this coordinate system. - If nothing is provided and none of the above-mentioned references pointing - in a parent, McStas is assumed. + If nothing is provided it is assumed that projection_direction is defined in the McStas coordinate system. - + The direction along which orientations are projected. @@ -77,8 +75,8 @@ Details about the original grid. - Here original grid means the one onto which the IPF map was computed - when exported from the tech partner's file format representation. + Here original grid means the grid for which the IPF map was computed when that + IPF map was exported from the tech partner's file format representation. @@ -87,17 +85,13 @@ Rescaling the visualization of the IPF map may be needed to enable visualization in specific software tools like H5Web. - The value specifies the fractional change of the spacing between - the original mapping and the scaled one. - How where orientation values at the location of the output grid - positions computed. + How where orientation values at positions of input_grid computed to values on output_grid. - Nearest neighbour means the orientation of the closed (Euclidean distance) - grid point of the input_grid was taken. + Nearest neighbour means the orientation of the closed (Euclidean distance) grid point of the input_grid was taken. @@ -107,7 +101,6 @@ Inverse pole figure mapping. - Default inverse pole figure (IPF) plot of the data specific for each phase. No ipf_mapID instances for non-indexed scan points as these are by definition assigned the null phase with phase_identifier 0. Inspect the definition of :ref:`NXcrystal_structure` and its field @@ -119,20 +112,18 @@ The main purpose of this map is to offer a normalized default representation of the IPF map for consumption by a research data management system (RDMS). - This is aligned with the first aim of :ref:`NXmicrostructure_ipf`, to bring colleagues and - users of IPF maps together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging IPF maps as specific - community-accepted tools to convey orientation maps. + This is aligned with the first aim of :ref:`NXmicrostructure_ipf`, to bring colleagues + and users of IPF maps together to discuss which pieces of information need storage. + + We are convinced a step-by-step design and community-driven discussion is a practical + strategy to work towards an interoperable description and data model for exchanging + IPF maps as a specific community-accepted method to convey orientation maps. With this design the individual RDMS solutions and tools can still continue to support specific custom data analyses workflow and routes but at least there is one common understanding which enables also those users who are - not necessarily experts in all the details of the underlying techniques - can understand and thus eventually judge if the dataset is worth to be - reused or repurposed. + not necessarily experts in all the details of the underlying techniques an + understanding if the dataset is worth to become reused or repurposed. - The color code which maps colors into orientation into the fundamental zone. + The color code which maps colors to orientation in the fundamental zone. For each stereographic standard triangle (SST), i.e. a rendering of the fundamental zone of the crystal-symmetry-reduced orientation space - SO3, it is possible to define a color model which assigns each point in - the fundamental zone a color. + SO3, it is possible to define a color model which assigns a color to each + point in the fundamental zone. Different mapping models are used. These implement (slightly) different scaling relations. Differences exist across representations of tech partners. @@ -206,11 +197,11 @@ title:--> For further details see: * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - * Srikanth Patala and coworkers"'" work and of others. + * [S. Patala et al.](https://doi.org/10.1016/j.pmatsci.2012.04.002). Details are implementation-specific and not standardized yet. - Given that the SST has a complicated geometry, it cannot yet be + Given that the SST has a complicated geometry, it can not yet be visualized using tools like H5Web, which is why for now the matrix of a rasterized image which is rendered by the backend tool gets copied into an RGB matrix to offer a default plot. @@ -252,132 +243,6 @@ hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! - + diff --git a/contributed_definitions/NXmicrostructure_odf.nxdl.xml b/contributed_definitions/NXmicrostructure_odf.nxdl.xml index 696ff58cd4..710a6c0ebb 100644 --- a/contributed_definitions/NXmicrostructure_odf.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_odf.nxdl.xml @@ -25,17 +25,19 @@ - Number of pixel per varphi section plot along the varphi_one fastest direction. + Number of pixel per varphi section plot along the :math:`\varphi_1` fastest + direction. - Number of pixel per varphi section plot along the capital_phi slow direction. + Number of pixel per varphi section plot along the :math:`\Phi` slow direction. - Number of pixel per varphi section plot along the varphi_two slowest direction. + Number of pixel per varphi section plot along the :math:`\varphi_2` slowest + direction. @@ -45,7 +47,7 @@ - Base class to store an orientation distribution function (ODF) computation. + Base class to store an orientation distribution function (ODF). @@ -80,16 +82,19 @@ + + Group to store descriptors and summary statistics + - Number of local maxima evaluated for the ODF. + Number of local maxima evaluated - Euler angle representation of the kth-most maxima of the ODF - in decreasing order of the intensity maximum. + Euler angle representation :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` of the kth-most + maxima in decreasing order of the intensity maximum. @@ -104,9 +109,9 @@ - Integrated ODF intensity within a theta-ball of SO3 about - each location as specified for each location in the order - and reported in the order of these locations. + Integrated ODF intensity within a theta angular region of SO3 about + each location (obeying symmetries) as specified for each location + in the order and stored in the order of location. @@ -115,14 +120,14 @@ - Visualization of the ODF intensity as orthogonal sections through Euler space. + Visualization of the ODF intensity as discretized orthogonal sections + through Euler space. This is one example of typical default plots used in the texture - community in Materials Engineering. + community in materials engineering. - Mind that the Euler space is a distorted space. Therefore, equivalent - orientations show intensity contributions in eventually multiple - locations. + Mind that the Euler space is a distorted space. Therefore, equivalent orientations + show intensity contributions in eventually multiple locations. - ODF intensity at probed locations relative to - null model of a completely random texture. + ODF intensity at probed locations relative to the intensity of the null model of + a completely random texture. @@ -149,21 +154,21 @@ - + - Pixel center angular position along the :math:`\varphi_2` direction. + Pixel center angular position along the :math:`\Phi` direction. - + - + - Pixel center angular position along the :math:`\Phi` direction. + Pixel center angular position along the :math:`\varphi_2` direction. - + diff --git a/contributed_definitions/NXmicrostructure_pf.nxdl.xml b/contributed_definitions/NXmicrostructure_pf.nxdl.xml index 9892676578..d91349426f 100644 --- a/contributed_definitions/NXmicrostructure_pf.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_pf.nxdl.xml @@ -43,15 +43,14 @@ - Point group of the crystal structure of the phase for which the - here documented phase-dependent pole figure was computed - (according to International Table of Crystallography). + Point group of the crystal structure of the phase for which pole figure + was computed (according to International Table of Crystallography). - Point group assumed for processing induced sample symmetries - (according to International Table of Crystallography). + Point group of assumed sample symmetries (according to International Table of + Crystallography). diff --git a/contributed_definitions/NXmicrostructure_recon.nxdl.xml b/contributed_definitions/NXmicrostructure_recon.nxdl.xml index 558b53763c..f661721857 100644 --- a/contributed_definitions/NXmicrostructure_recon.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_recon.nxdl.xml @@ -21,26 +21,31 @@ # # For further information, see http://www.nexusformat.org --> - The symbols used in the schema to specify e.g. dimensions of arrays. - + + + + The number of linear intercepts defined. + + + + + The number of crystal projections segmented by crossing (projected or real) + interfaces. + + + + + The number of crossings + + + The number of crystal projections. @@ -53,24 +58,25 @@ crystals/grains are projections that are delineated by projections of interface, - The number of assumed triple junction projections aka triple points. + The number of assumed triple line projections aka triple points. - The number of crystals. + The number of crystals. Grain and sub-grain are synonyms for crystal. - The number of interfaces + The number of interfaces. Grain boundary and phase boundary are subclasses of + interface. - The number of triple lines + The number of triple lines. @@ -80,33 +86,54 @@ crystals are delineated by interfaces that are delineated by triple lines that m - Base class to describe discretized (micro)structural features of a material. + Base class to describe structural aspects and associated descriptors of (micro)structural features. + + The continuum or atomic scale description of materials is inherently a model of reality. Such models + are useful as they enable a coarse graining and categorization of measured or simulated materials + specifically how their structural features lead to properties i.e. descriptor values. + Mind that most specimens are thermo-chemo-mechanically treated before they are characterized. + Therefore, the characterized microstructure may not have probed the same structure as of + the untreated sample or often bulk material from which the region-of-interest or specimen was probed. - One instance of this base class can be used to describe the current configuration - the base class does not include time-dependent descriptions for the sake of - clarity and because of the fact that virtually all simulations or experiments - probe time by sampling. Therefore, time-dependent state descriptions should - be realized with creating a set of :ref:`NXmicrostructure_snapshot_set` with instances of - :ref:`NXmicrostructure_snapshot` using e.g. :ref:`NXmicrostructure_recon` base class instances. + A simulation or experiment can only sample the true structure of the material. + Fields time and increment enable a quantification of the temporal evolution of a material + when using multiple instances of NXmicrostructure_recon. + + Taking inspiration from `E. E. Underwood <https://doi.org/10.1111/j.1365-2818.1972.tb03709.x>`_ + and E. E. Underwood's book on Quantitative stereology that was published in 1970. + + Identifiers can be defined either implicitly or explicitly. For implicit indexing identifiers are defined + on the interval :math:`[identifier\_offset, identifier\_offset + cardinality - 1]`. - + + + + Discouraged free text field for leaving comments. + + + + + Measured or simulated physical time stamp for this snapshot. + Not to be confused with wall-clock timing or profiling data. + + + + + Iteration or increment counter. + + The configuration and parameterization of the reconstruction algorithm whereby the microstructural features were identified. - - Dimensionality of the analysis. + Dimensionality of Euclidean space in which the analysis is conducted. - This field can be used e.g. by a research data management system - to identify if the described feature set specifies a - one-, two-, or three-dimensional feature set. + This field can be used e.g. by a research data management system to identify + if the description specifies one-, two-, or three-dimensional representations. @@ -116,7 +143,7 @@ in an roi1/ebsd instance isnt this information implicit?--> - Which algorithm is used to reconstruct the features. + Algorithm is used to reconstruct the features. @@ -134,74 +161,58 @@ in an roi1/ebsd instance isnt this information implicit?--> - - - - - - - - + + + + + + + + - Projections of crystals on the sample surface as typically - characterized with optical or electron microscopy. + One- or two-dimensional projections, or three-dimensional representation of crystals. + + Crystals can be grains of different phases, precipitates, dispersoids, there are many + terms used in specifically the materials engineering community. + + Typically, as observed e.g. on the surface of a sample using with optical or electron microscopy + or as simulated as a set of pixel or evolving polygons and their polyline boundaries. - + + - Reference to lines(NXcg_polyline_set) which supports the - discretized shape of each cross-sectioned crystal. + Reference to an instance of: + + * :ref:`NXcg_point_set` for a one-dimensional representation as only a projection is available + * :ref:`NXcg_polyline_set` or :ref`NXcg_polygon_set` for a two-dimensional representation as only a projection is available + * :ref:`NXcg_polyhedron_set` for a three-dimensional representation + * :ref:`NXcg_grid` for regularly pixelated or voxelated representation Most microscopy techniques support to generate only a two-dimensional representation (projection) of the characterized material. - - For true volumetric techniques use the specifically - specialized crystals :ref:`NXmicrostructure_feature_set` instead. - See stereology literature for more details e.g. - E.E. Underwood's book entitled Quantitative Stereology - + Number of crystals. - + - Integer offset whereby the identifier of the first member - of the set differs from zero. - - Identifiers can be defined either implicitly or explicitly. - For implicit indexing identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. + How many phases are distinguished - + - Identifier used for crystals for explicit indexing. + Integer offset whereby to distinguish crystals. - - - - + - How many phases are distinguished + Identifier used for crystals for explicit indexing. + Integer offset whereby the identifier of the first member @@ -209,246 +220,198 @@ ONE DIMENSIONAL FEATURES--> - Identifier used for phase for explicit indexing. - - - - + - True, if the crystal makes contact with the edge of the ROI, - false otherwise. + True, if the crystal makes contact with the edge of the ROI false otherwise. - - - + Average disorientation angle between individual orientation of the crystal at probed positions (weighted by area of that position) versus the average disorientation of the crystal. - - - + + + + Length of each crystal + + - Calibrated area of surrounded by the polyline about each crystal. + Area of each crystal. + + + + + Volume of each crystal - - - - - + - Projections of grain or phase boundaries as typically sectioned - with optical or electron microscopy characterization. + One- or two-dimensional projections, or three-dimensional representation of interfaces between crystals + as topological entities to dual_junctions. + + Most relevant interfaces are grain and phase boundaries but factually interfaces can also be between + the environment and crystals exposed at the surface of the specimen. - + - Reference to lines(NXcg_polyline_set) which supports the - discretized shape of each cross-sectioned crystal. + Reference to an instance of: + + * :ref:`NXcg_point_set` for a one-dimensional representation as only a projection is available + * :ref:`NXcg_polyline_set` for a two-dimensional representation as only a projection is available + * :ref:`NXcg_grid` for regularly pixelated or voxelated representation using (boolean) masks - Set of tuples of polyline segments which build the interface. + Most microscopy techniques support to generate only a two-dimensional + representation (projection) of the characterized material. - - - + + + + Number of interfaces. + + + - Set of pairs of crystal_identifier resolved via depends_on which - are adjacent to each interface. + Integer which specifies the first index to be used for distinguishing + interfaces. + + + + + Integer used to distinguish features for explicit indexing. + + + + + + Set of pairs of crystal_identifier. - + - + - The specific crystal_projections(NXmicrostructure_feature_set) instance - to resolve crystal identifier. + The specific identifier instance to resolve ambiguities. - - + + - Set of pairs of triple_point_identifier which the interface connects. - For 2D projections of 3D microstructural features a triple point is - physically only the projection of a triple line. + Set of pairs of triple_junction_identifier. - + - + - The specific triple_line_projections(NXmicrostructure_feature_set) instance - whereby to resolve triple_point identifier. + The specific identifier instance to resolve ambiguities. - + - The length of the interface. + The length of the interface. This is not necessarily the same as the length of the individual polyline segments whereby the interface is discretized. - - The actual coordinate system whereby the geometry is calibrated - with real physical dimensions is typically documented by the - depends_on attribute of the respective NXcg_primitive_set. - This depends_on attribute should point explicitly to an - instance of a :ref:`NXcoordinate_system` to support users as - much as possible with interpreting how and where the lines are - located in the reference frame. - - - - - - - - Integer offset whereby the identifier of the first member - of the set differs from zero. - - Identifiers can be defined either implicitly or explicitly. - For implicit indexing identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. - + + - Identifier for each interface using explicit indexing. + Surface area - - - - - + - Projections of triple lines as typically characterized with optical - or electron microscopy. + Projections of or representations of junctions at which interfaces between. - Mind that most specimens are thermo-chemo-mechanically treated before - they are characterized. Therefore, the projected crystal defects are - have physically no longer the same structure as in the bulk. - - Examples are manifest as effects such as thermal grooving, or relaxation - effects of an intersection between a triple line that is cut - by the specimen surface as these defects are then exposed typically - to a different atmosphere and hence have different thermodynamic boundary - conditions than of their true volumetric defects in the bulk. + Junctions can be triple lines, triple points as their projections, junctions observed + between crystals at the specimen and its surface (including wetting phenomena) - + - Reference to points(NXcg_point_set) which supports the - locations of these triple points. + Reference to an instance of: + + * :ref:`NXcg_point_set` for a one-dimensional representation as only a projection is available + * :ref:`NXcg_polyline_set` for a two-dimensional representation as only a projection is available + * :ref:`NXcg_grid` for regularly pixelated or voxelated representation using (boolean) masks - + - + - Number of triple points. + Number of triple junctions. - + - Integer offset whereby the identifier of the first member - of the set differs from zero. - - Identifiers can be defined either implicitly or explicitly. - For implicit indexing identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. + Integer offset where to start counting instances of the set of junctions. - + - Identifier for each triple point using explicit indexing. + Identifier used for specifiying all members of the set of junctions. - - - - + + - Set of triple point identifiers. + Set of identifier for positions whereby to identify the location of each + junction. - - - - + - The relevant points(NXcg_point_set) instance whereby to - resolve interface identifiers. + The specific identifier whereby to resolve ambiguities. - + + - Set of triplets of identifier of line-like features. - Each triplet resolves which three interface projections - the triple point connects. + Set of tuples of identifier of features connected to the junction. - - - - - + - The specific interface_projections(NXmicrostructure_feature_set) - instance whereby to resolve interface identifiers. + The specific identifier to instances of interface identifiers whereby to resolve + ambiguities. - - + + - Triplet of identifier of polyline segments. Each triplet resolves - which three segments of polyline segments the triple junction connects. + Set of tuples of identifier for representation of discretized features connected + to the junction. - - - - - + - The specific lines(NXcg_polyline_set) instance to resolve - polyline segments. + The specific identifier to instances of NXcg primitives whereby to resolve + ambiguities. - + diff --git a/contributed_definitions/nyaml/NXimage_r_set_diff.yaml b/contributed_definitions/nyaml/NXimage_r_set_diff.yaml index 9b79d249d3..6b35ad6c11 100644 --- a/contributed_definitions/nyaml/NXimage_r_set_diff.yaml +++ b/contributed_definitions/nyaml/NXimage_r_set_diff.yaml @@ -8,7 +8,7 @@ doc: | Steps of post-processing the diffraction patterns should be documented using method-specific specialized base classes. All eventual post-processing of - resulting orientation maps (2D or 3D) should be documented via :ref:`NXmicrostructure_recon`. + resulting orientation maps (2D or 3D) should be documented via NXmicrostructure. To implement an example how this base class can be used we focused in FAIRmat on Kikuchi diffraction pattern here specifically the research community diff --git a/contributed_definitions/nyaml/NXmicrostructure_feature_set.yaml b/contributed_definitions/nyaml/NXmicrostructure_feature_set.yaml deleted file mode 100644 index eb9c45048c..0000000000 --- a/contributed_definitions/nyaml/NXmicrostructure_feature_set.yaml +++ /dev/null @@ -1,528 +0,0 @@ -category: base -doc: | - Set of topological/spatial features in materials build from other features. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - Dimensionality - c: | - Cardinality/number of members/features in the feature set. - n_type_dict: | - Number of types in the dictionary of human-readable types of features. - n_parent_ids: | - Total number of parent identifier. -# NXmicrostructure_feature_set can be used e.g. as groups inside instances of NXmicrostructure_snapshot -# for an MD simulation each timestep is such snapshot all snapshot for a set -# which is the parent group that has all these NXmicrostructure_snapshot instances as childs -# time_stamp: # simulated, physical -# Thea, Joseph, Lauri, Dinga (TJLD) just for comparison for each group and field to what this would map in their model for the MDTutorial 2 -type: group -NXmicrostructure_feature_set(NXobject): - # TJLD: this class represents a generalization of AtomGroups - # TJLD: one such for atoms(NXmicrostructure_feature_set) - # TJLD: one such for atom_groups(NXmicrostructure_feature_set) - # TJLD: but not one for every molecule, i.e. all molecules and how their atoms with ids are related to atoms ids is concatenated - # TJLD: clearly there are two possibilities: either concatenate or make one NXmicrostructure_feature_set for each molecule or component in the topology hierarchy - # TJLD: however the here proposed design generalizes the arbitrary (microstructural) features and computational geometry based coarse-grained representations - \@depends_on(NX_CHAR): - # TJLD: not required it is currently assumed that features are always build from atoms and this relation is shown using their ids, integers on [0, n_atoms-1] - doc: | - Name (or link?) to another NXmicrostructure_feature_set which defines features what are - assumed as the parents/super_features of all members in this feature set. - If depends_on is set to "." or this attribute is not defined in an instance - of this application definition, assume that this feature_set instance - represents the root feature_set of the feature tree/graph. - # the design of this base class makes it possible to have Joseph's suggestion - # but it has the additional benefit that as it defines the set one also - # bundle the description for all features at this hierarchy level into combined - # arrays to make the eventual storage of this for instances with millions of features - # more efficient as in the current design each molecule would again be a group - # and having millions of groups comes with e.g. HDF5 with substantial overlap - # I faced this when storing grains from micro-scale continuum crystal growth simulations - # TJLD: is_molecule(NX_BOOLEAN): not used, could however be added in an appdef which uses instances of NXmicrostructure_feature_set - # TJLD: the key point we can use NXmicrostructure_feature_set in the same way as currently TJLD use atoms and atoms/atom_groups/molecule0, */molecule1, ... - # but with the additional benefit of a much richer geometrical description and the details about the uncertainty of these descriptions - # I can also imagine that materials engineers e.g. can reuse NXmicrostructure_feature_set in an application definition by just then naming - # their group e.g. grains(NXmicrostructure_feature_set) and use in the application definition either only the (material point), interface network, or volumetric description - dimensionality(NX_POSINT): - # TJLD: not needed because they assume everything is 3d - doc: | - What is the best matching description how dimensional the feature is. - enumeration: [1, 2, 3] - cardinality(NX_UINT): - # TJLD: equivalent to the number of AtomGroups class instance childs - doc: | - How many features/members are in this set? - unit: NX_UNITLESS - type_dict_keyword(NX_CHAR): - # TJLD: equivalent to the controlled vocabulary term monomer or molecule, i.e. label - # TJLD: but with the difference that in this NeXus design here different features can take different roles - # TJLD: and do not conceptually have to be atoms, alternatively one could also create an NXmicrostructure_interface_set which - # TJLD: inherits from NXmicrostructure_feature_set but would need to have no dimensionality - doc: | - The keywords of the dictionary of human-readable types of features. - Using terms from a community-agreed upon controlled vocabulary, e.g. - atom, solute, vacancy, monomer, molecule, anti-site, crowd_ion, - quadruple junction, triple line, disconnection, dislocation, - kink, jog, stacking_fault, homo_phase_boundary, hetero_phase_boundary, - surface, thermal_groove_root, precipitate, dispersoid, pore, crack - is recommended. - dim: (n_type_dict,) - type_dict_value(NX_INT): - # TJLD: equivalent to the AtomGroups index - doc: | - The integer identifier used to resolve of which type each feature is, - i.e. the values of the dictionary of human-readable types of features. - unit: NX_UNITLESS - dim: (n_type_dict,) - number_of_parent_identifier(NX_INT): - doc: | - For each feature in the set specify the associated number of identifier - to parent features as are resolvable via depends_on. - This array enables to compute the array interval from which details for - specific features can be extracted as if they would be stored in an own - group. - unit: NX_UNITLESS - dim: (c,) - parent_identifier(NX_INT): - doc: | - Concatenated array of parent identifier for each feature (in the sequence) - according to identifier and how the identifier of features in the here - described feature set are defined (implicitly from 0, to c-1 or via explicit - identifier. - unit: NX_UNITLESS - dim: (n_parent_ids,) - # description of the geometry of the features - # MK::how can be define that inside lines(NXobject) we assure that there is either no geometry or only one geometry but then this geometry can be either an NXcg_polyline_set or NXcg_spline_set? - # the key problem is that at least for an implementation in HDF5 we are not allowed to have two groups named geometry even if their attributes are different because - # HDF5 implements no conceptual understanding of the relations between elements in the underlying graph which holds the data, these elements are either attributes, fields, groups, all of which - # end up as links - identifier_offset(NX_INT): - doc: | - Integer which specifies the first index to be used for distinguishing - features. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - unit: NX_UNITLESS - identifier(NX_INT): - doc: | - Integer used to distinguish features for explicit indexing. - unit: NX_UNITLESS - dim: (c,) - points(NXprocess): - # TJLD: this design here is different, TJLD give atom positions only (at least as of now) for the root of an object - # TJLD: while all higher-order features that are connected through their assumed topology just refer to the atoms in the root - # TJLD: via their IDs, TJLD design is ideal for systems build from atoms but would create unnecessary copies for higher-dimensional-type features - # TJLD: in fact initially I also thought it is useful to create an NXmicrostructure_dislocation_set, and an NXmicrostructure_atom_set but overall these are just - # specializations of NXmicrostructure_feature_set. Instead I like the key approach in TJLD which is to nest instances of the same class in TJLD's case AtomGroups - # but here NXmicrostructure_feature_set instances - doc: | - Assumptions and parameter to arrive at geometric primitives - to locate zero-dimensional/point-(like) features which are - discretized/represented by points. - geometry(NXcg_point_set): - uncertainty(NXprocess): - doc: | - Assumptions, parameters, and details how positional uncertainty - of the geometry is quantified. - lines(NXprocess): - # TJLD: not conceptualized, see comments for points and what the benefit of using NeXus would be - doc: | - Assumptions and parameters to arrive at geometric primitives - to locate one-dimensional/line-like features which are - discretized by polylines. - # MK::geometry(NXcg_spline_set) - geometry(NXcg_polyline_set): - uncertainty(NXprocess): - doc: | - Assumptions, parameters, and details how positional uncertainty - of the geometry is quantified. - interfaces(NXprocess): - doc: | - Assumptions and parameters to arrive at geometric primitives - to locate two-dimensional/interface features which are - discretized by triangulated surface meshes. - # MK::geometry(NXcg_nurbs_set): - geometry(NXcg_triangle_set): - uncertainty(NXprocess): - doc: | - Assumptions, parameters, and details how positional uncertainty - of the geometry is quantified. - volumes(NXprocess): - doc: | - Assumptions and parameters to arrive at geometric primitives - to locate three-dimensional/volumetric features which are - discretized by triangulated surface meshes of polyhedra. - # MK::geometry(NXcg_nurbs_set): - geometry(NXcg_polyhedron_set): - uncertainty(NXprocess): - doc: | - Assumptions, parameters, and details how positional uncertainty - of the geometry is quantified. - # Sandor and Markus agree that how trajectories are extracted should be stored in instances of NXprocess at respective places - # Sandor suggested it can be useful to also describe how one could transform system-specific atom positions from the system-focused coordinate system to a molecule- or atom-focused local coordinate system - - # how to map results from MD simulations was already sketched by the comments from TJLD - # but ones more here stating it explicitly - # atoms(NXmicrostructure_feature_set): - # no \@depends_on: as everything is build spatiotemporally coarse-grained from the sampled atom positions and/or their trajectories - # dislocations(NXmicrostructure_feature_set): - # \@depends_on: <>/atoms - # is trivially the same case as was described already for the DDD simulation - - # how to map from DREAM.3D to NXmicrostructure_feature_set - # material_points(NXmicrostructure_feature_set): # material points can be voxels of a grid (which should be specified with an instance of NXcg_grid) or real material points - # no \@depends_on: "." required or value can be "." as material_points are considered the root - # grains(NXmicrostructure_feature_set): - # \@depends_on: <>/material_points - # boundaries(NXmicrostructure_feature_set): - # \@depends_on: <>/grains - # triple_lines(NXmicrostructure_feature_set): - # \@depends_on: <>/boundaries - # quadruple_junctions(NXmicrostructure_feature_set): - # \@depends_on: <>/triple_lines - - # how to map from e.g. DDD codes like ParaDis to NXmicrostructure_feature_set - # dislocations(NXmicrostructure_feature_set): - # either all types of dislocations are specified via the type_dict dictionary or by making several named instances of NXmicrostructure_feature_set classes, i.e. groups - # multi_junctions(NXmicrostructure_feature_set): - # \@depends_on: <>/dislocations - - # how to describe e.g. 3D cracks - # cracks(NXmicrostructure_feature_set): - # you can use volumes and interfaces to describe explicitly the 3D geometry - # alternatively you can - - # how to map from an MTex v5.8.2 @grain2d object - # grains.poly is a cell of list of vertex indices referring to grains.V - # grains.id - # grains.phaseId to which phase does each grain belong why is it different to phase? - # grains.prop (mean and gos) - # grains.boundary - # F, list of minmax-hashed vertex indices building the facet - # grainId, list of pairs of grains incident at facet special value 0 marks grains with boundary contact - # ebsdId, list of interpolated scan points incident - # phaseId, homo/heterophase information list of pairs of phases incident at facet - # V, list of facet support vertices, the support of the polyline - # midPoint, list of facet midPoint coordinates - # direction 3d vector (V(F(i, 1),:) - V(F(i, 2), :)) and with z = 0 and then normalized, so not respecting winding order - # grains.triplePoints - # id, list of vertex id for the location of the triple point referring to grains.V or grains.boundary.V as these lists are equivalent - # grainid, triplet of adjoining grain ids - # boundaryId, triplet of adjoining boundary facets from grains.boundary.F - # nextVertexId, next vertex hit when walking from the triple point - # phaseId, is it a triple point between homophases or heterophases - # V, list of x, y coordinates for the triple points - # angles, trivial nextVertexId to triplePoint vertex angles - # grains(NXmicrostructure_feature_set): - # boundaries(NXmicrostructure_feature_set): - # alternatively one NXmicrostructure_feature_set for homophase boundaries - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 15f205ec24e25536f17046f9540798e889bf21046d3e1e2a63ab9434e3f6ffa9 -# -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Dimensionality -# -# -# -# -# Cardinality/number of members/features in the feature set. -# -# -# -# -# Number of types in the dictionary of human-readable types of features. -# -# -# -# -# Total number of parent identifier. -# -# -# -# -# Set of topological/spatial features in materials build from other features. -# -# -# -# -# -# Name (or link?) to another NXmicrostructure_feature_set which defines features what are -# assumed as the parents/super_features of all members in this feature set. -# If depends_on is set to "." or this attribute is not defined in an instance -# of this application definition, assume that this feature_set instance -# represents the root feature_set of the feature tree/graph. -# -# -# -# -# -# -# What is the best matching description how dimensional the feature is. -# -# -# -# -# -# -# -# -# -# -# -# How many features/members are in this set? -# -# -# -# -# -# The keywords of the dictionary of human-readable types of features. -# Using terms from a community-agreed upon controlled vocabulary, e.g. -# atom, solute, vacancy, monomer, molecule, anti-site, crowd_ion, -# quadruple junction, triple line, disconnection, dislocation, -# kink, jog, stacking_fault, homo_phase_boundary, hetero_phase_boundary, -# surface, thermal_groove_root, precipitate, dispersoid, pore, crack -# is recommended. -# -# -# -# -# -# -# -# -# The integer identifier used to resolve of which type each feature is, -# i.e. the values of the dictionary of human-readable types of features. -# -# -# -# -# -# -# -# For each feature in the set specify the associated number of identifier -# to parent features as are resolvable via depends_on. -# This array enables to compute the array interval from which details for -# specific features can be extracted as if they would be stored in an own -# group. -# -# -# -# -# -# -# -# Concatenated array of parent identifier for each feature (in the sequence) -# according to identifier and how the identifier of features in the here -# described feature set are defined (implicitly from 0, to c-1 or via explicit -# identifier. -# -# -# -# -# -# -# -# -# Integer which specifies the first index to be used for distinguishing -# features. Identifiers are defined either implicitly -# or explicitly. For implicit indexing the identifiers are defined on the -# interval :math:`[identifier\_offset, identifier\_offset + c - 1]. -# For explicit indexing the identifier array has to be defined. -# -# The identifier_offset field can for example be used to communicate if the -# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) -# or from 0 (referred to as C-, Python-style index notation) respectively. -# -# -# -# -# Integer used to distinguish features for explicit indexing. -# -# -# -# -# -# -# -# -# Assumptions and parameter to arrive at geometric primitives -# to locate zero-dimensional/point-(like) features which are -# discretized/represented by points. -# -# -# -# -# Assumptions, parameters, and details how positional uncertainty -# of the geometry is quantified. -# -# -# -# -# -# -# Assumptions and parameters to arrive at geometric primitives -# to locate one-dimensional/line-like features which are -# discretized by polylines. -# -# -# -# -# -# Assumptions, parameters, and details how positional uncertainty -# of the geometry is quantified. -# -# -# -# -# -# Assumptions and parameters to arrive at geometric primitives -# to locate two-dimensional/interface features which are -# discretized by triangulated surface meshes. -# -# -# -# -# -# Assumptions, parameters, and details how positional uncertainty -# of the geometry is quantified. -# -# -# -# -# -# Assumptions and parameters to arrive at geometric primitives -# to locate three-dimensional/volumetric features which are -# discretized by triangulated surface meshes of polyhedra. -# -# -# -# -# -# Assumptions, parameters, and details how positional uncertainty -# of the geometry is quantified. -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXmicrostructure_ipf.yaml b/contributed_definitions/nyaml/NXmicrostructure_ipf.yaml index 811d884472..40a508837f 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_ipf.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_ipf.yaml @@ -2,7 +2,6 @@ category: base doc: | Base class to store an inverse pole figure (IPF) mapping (IPF map). symbols: - # how to make this optional n_z: | Number of pixel along the z slowest direction. n_y: | @@ -15,16 +14,16 @@ symbols: Dimensionality of the mapping (either 2 or 3). type: group NXmicrostructure_ipf(NXprocess): - \@depends_on(NX_CHAR): - doc: | - Reference to the coordinate system whereby the projection_direction is defined. + depends_on(NX_CHAR): + doc: + - | + Reference to an :ref:`NXcoordinate_system` in which the projection_direction is defined. - If the field depends_on is not provided but a parent of the instance - of this base class or its specialization defines an :ref:`NXcoordinate_system_set` - and exactly one :ref:`NXcoordinate_system`, the reference points to this system. + If the field depends_on is not provided but parents of the instance of this base class or its + specializations define an instance of :ref:`NXcoordinate_system`, projection_direction + is defined in this coordinate system. - If nothing is provided and none of the above-mentioned references pointing - in a parent, McStas is assumed. + If nothing is provided it is assumed that projection_direction is defined in the McStas coordinate system. projection_direction(NX_NUMBER): doc: | The direction along which orientations are projected. @@ -34,29 +33,24 @@ NXmicrostructure_ipf(NXprocess): doc: | Details about the original grid. - Here original grid means the one onto which the IPF map was computed - when exported from the tech partner's file format representation. + Here original grid means the grid for which the IPF map was computed when that + IPF map was exported from the tech partner's file format representation. output_grid(NXcg_grid): doc: | Details about the grid onto which the IPF is recomputed. Rescaling the visualization of the IPF map may be needed to enable visualization in specific software tools like H5Web. - The value specifies the fractional change of the spacing between - the original mapping and the scaled one. interpolation(NX_CHAR): doc: | - How where orientation values at the location of the output grid - positions computed. + How where orientation values at positions of input_grid computed to values on output_grid. - Nearest neighbour means the orientation of the closed (Euclidean distance) - grid point of the input_grid was taken. + Nearest neighbour means the orientation of the closed (Euclidean distance) grid point of the input_grid was taken. enumeration: [nearest_neighbour] map(NXdata): doc: | Inverse pole figure mapping. - Default inverse pole figure (IPF) plot of the data specific for each phase. No ipf_mapID instances for non-indexed scan points as these are by definition assigned the null phase with phase_identifier 0. Inspect the definition of :ref:`NXcrystal_structure` and its field @@ -68,20 +62,18 @@ NXmicrostructure_ipf(NXprocess): The main purpose of this map is to offer a normalized default representation of the IPF map for consumption by a research data management system (RDMS). - This is aligned with the first aim of :ref:`NXmicrostructure_ipf`, to bring colleagues and - users of IPF maps together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging IPF maps as specific - community-accepted tools to convey orientation maps. + This is aligned with the first aim of :ref:`NXmicrostructure_ipf`, to bring colleagues + and users of IPF maps together to discuss which pieces of information need storage. + + We are convinced a step-by-step design and community-driven discussion is a practical + strategy to work towards an interoperable description and data model for exchanging + IPF maps as a specific community-accepted method to convey orientation maps. With this design the individual RDMS solutions and tools can still continue to support specific custom data analyses workflow and routes but at least there is one common understanding which enables also those users who are - not necessarily experts in all the details of the underlying techniques - can understand and thus eventually judge if the dataset is worth to be - reused or repurposed. + not necessarily experts in all the details of the underlying techniques an + understanding if the dataset is worth to become reused or repurposed. # \@signal: data # \@axes: [axis_y, axis_x] # \@axis_x_indices: 0 @@ -121,12 +113,12 @@ NXmicrostructure_ipf(NXprocess): # title: legend(NXdata): doc: | - The color code which maps colors into orientation into the fundamental zone. + The color code which maps colors to orientation in the fundamental zone. For each stereographic standard triangle (SST), i.e. a rendering of the fundamental zone of the crystal-symmetry-reduced orientation space - SO3, it is possible to define a color model which assigns each point in - the fundamental zone a color. + SO3, it is possible to define a color model which assigns a color to each + point in the fundamental zone. Different mapping models are used. These implement (slightly) different scaling relations. Differences exist across representations of tech partners. @@ -137,11 +129,11 @@ NXmicrostructure_ipf(NXprocess): For further details see: * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - * Srikanth Patala and coworkers"'" work and of others. + * [S. Patala et al.](https://doi.org/10.1016/j.pmatsci.2012.04.002). Details are implementation-specific and not standardized yet. - Given that the SST has a complicated geometry, it cannot yet be + Given that the SST has a complicated geometry, it can not yet be visualized using tools like H5Web, which is why for now the matrix of a rasterized image which is rendered by the backend tool gets copied into an RGB matrix to offer a default plot. @@ -169,131 +161,5 @@ NXmicrostructure_ipf(NXprocess): # \@long_name(NX_CHAR): # title: -# keep this for now for FAIRmat internal documentation -# It is important to mention that we cannot assume, at least for now, -# that the parser which writes to an NXem_ebsd-compliant file is also -# responsible or capable at all of computing the inverse pole figure -# color keys and maps itself. This cannot be assumed working because -# this mapping of orientation data uses involved mathematical algorithms -# and functions which not every tools used in the EBSD community is capable -# of using or is for sure not using in exactly the same way. -# -# Currently, we assume it is the responsibilty of the tool used which -# generated the data under on_the_fly_indexing to compute these -# plots and deliver these to the parser. -# -# Specific case studies have been explored by the experiment team of -# Area B of the FAIRmat project to realize and implement such mapping. -# -# The first case study uses the H5OINA format and the pyxem/orix library. -# As orix is a Python library, the coloring is performed by the em_om parser. -# -# The second case study uses MTex and its EBSD color coding model. -# As MTex is a Matlab tool, an intermediate format is written from MTex -# first which stores these pieces of information. The parser then pulls -# these data from the intermediate Matlab-agnostic representation and -# supplements the file with missing pieces of information as it is -# required by NXem_ebsd. -# -# The third case study shows how a generic set of Kikuchi pattern -# can be loaded with the em_om parser. The pattern are loaded directly -# from a ZIP file and mapped to an simulation image section for now. -# -# The fourth case study uses the DREAM.3D package which provides an own -# set of EBSD data post-processing procedures. DREAM.3D documents the -# processing steps with a pipeline file which is stored inside DREAM.3D -# output files. In this case study, the parser reads the DREAM.3D file -# and maps data relevant from the perspective of NXem_ebsd plus adds -# relevant IPF color maps as they were computed by DREAM.3D. -# Given that in this case the origin of the data is the DREAM.3D file -# again provenance is kept and more details can be followed upon when -# resolving origin. -# -# These examples offer a first set of suggestions on how to make EBSD -# data injectable into research data management system using schemes -# which themselves are agnostic to the specific RDMS and interoperable. -# Steps of collecting the raw data and post-processing these with custom -# scripts like MTex or commercial tools so far are mainly undocumented. -# The limitation is that a program which consumes results or dump files -# from these tools may not have necessarily all the sufficient information -# available to check if the injected orientation data and color models -# are matching the conventions which a user or automated system has -# injected into an electronic lab notebook from which currently the em_om -# parser collects the conventions and stores them into this NXem_ebsd instance. -# The immediate benefit of the here presented NXem_ebsd concept though -# is that the conventions and reference frame definitions are expected -# in an ELN-agnostic representation to make NXem_ebsd a generally useful -# data scheme for EBSD. -# -# Ideally, the em_om parser would load convention-compliant EBSD data -# and use subsequently a community library to transcode/convert orientation -# conventions and parameterized orientation values. Thereafter, convention- -# compliant default plot(s) could be created that would be truely interoperable. -# -# However, given the variety of post-processing tools available surplus -# the fact that these are not usually executed along standardized -# post-processing workflows which perform exactly the same algorithmic steps, -# this is currently not a practically implementable option. Indeed, first -# developers who wish to implement this would first have to create a library -# for performing such tasks, mapping generally between conventions, -# i.e. map and rotate coordinate systems at the parser level. -# -# The unfortunate situation in EBSD is that due to historical reasons -# and competitive strategies, different players in the field have -# implemented (slightly) different approaches each of which misses -# some part of a complete workflow description which is behind EBSD analyses: -# Sample preparation, measurement, indexing, post-processing, paper... -# -# The here exemplified default plot do not so far apply relevant rotations -# but takes the orientation values as they come from the origin and using -# coloring them as they come. It is thus the scientists responsibility to -# enter and check if the respective dataset is rotation-conventions-wise -# consistent and fit for a particular task. -# -# Ideally, with all conventions defined it can be possible to develop -# a converter which rotates the input data. This application definition -# does not assume this and users should be aware of this limitation. -# -# The key point is that the conventions however are captured and this is -# the most important step to the development of such a generic transcoder -# for creating interoperable EBSD datasets. -# -# Currently the conventions remain in the mind or manual lab book of the -# respective scientists or technicians instead of getting stored and -# communicated with research papers that are written based on -# specific dataset, i.e. database entries. -# -# The default gridded representation of the data should not be -# misinterpreted as the only possible way how EBSD data and OIM -# maps can be created! -# -# Indeed, the most general case is that patterns are collected for -# scan points. The scan generator of an electron microscope is instructed -# to steer the beam in such a way across the specimen surface that the -# beam illuminates certain positions for a certain amount time (usually -# equally-spaced and spending about the same amount of time at each -# position). -# -# Therefore, scan positions can be due to such regular flight plans and -# represent sampling on lines, line stacks, rectangular regions-of- -# interests, but also could instruct spiral, random, or adaptive scans -# instead of tessellations with square or hexagonal pixels. -# -# The majority of EBSD maps is though is reporting results for a regular -# grid (square, hexagon). What matters though in terms of damage induced -# by the electron beam and signal quality is the real electron dose -# history, i.e. for how long the beam exposed which location of the -# specimen. Especially when electron charging occurs (i.e. an excess -# amount of charge accumulates due to e.g. poor conducting away of this -# charge or an improper mounting, too high dose, etc. such details are -# relevant. -# -# Specifically, the default visualization is an inverse pole-figure (IPF) -# map with the usual RGB color coding. Different strategies and -# normalization schemes are in use to define such color coding. -# -# Finally, we should mention that each ipf_map represents data for -# scan points indexed as one phase. The alias/name of this phase should -# be stored in phase_name, the phase_identifier give an ID which must -# not be zero as this value is reserved for non-indexed / null model scan -# points. \ No newline at end of file +# for further contextualization see comments in NXms_ipf.yaml +# https://github.com/FAIRmat-NFDI/nexus_definitions/commit/26d4faa5c6950161e48f0672f3fdfd8c9bc907e2 diff --git a/contributed_definitions/nyaml/NXmicrostructure_odf.yaml b/contributed_definitions/nyaml/NXmicrostructure_odf.yaml index 3313d17f36..79f20c5c00 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_odf.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_odf.yaml @@ -1,13 +1,13 @@ category: base doc: | - Base class to store an orientation distribution function (ODF) computation. + Base class to store an orientation distribution function (ODF). symbols: n_varphi_one: | - Number of pixel per varphi section plot along the varphi_one fastest direction. + Number of pixel per varphi section plot along the :math:`\varphi_1` fastest direction. n_capital_phi: | - Number of pixel per varphi section plot along the capital_phi slow direction. + Number of pixel per varphi section plot along the :math:`\Phi` slow direction. n_varphi_two: | - Number of pixel per varphi section plot along the varphi_two slowest direction. + Number of pixel per varphi section plot along the :math:`\varphi_2` slowest direction. k: | Number of local maxima evaluated in the component analysis. type: group @@ -35,15 +35,17 @@ NXmicrostructure_odf(NXprocess): Resolution of the kernel. unit: NX_ANGLE kth_extrema(NXobject): + doc: | + Group to store descriptors and summary statistics kth(NX_UINT): doc: | - Number of local maxima evaluated for the ODF. + Number of local maxima evaluated unit: NX_UNITLESS # value of kth should be k location(NX_NUMBER): doc: | - Euler angle representation of the kth-most maxima of the ODF - in decreasing order of the intensity maximum. + Euler angle representation :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` of the kth-most + maxima in decreasing order of the intensity maximum. unit: NX_ANGLE dim: (k, 3) theta(NX_NUMBER): @@ -53,21 +55,21 @@ NXmicrostructure_odf(NXprocess): unit: NX_ANGLE volume_fraction(NX_NUMBER): doc: | - Integrated ODF intensity within a theta-ball of SO3 about - each location as specified for each location in the order - and reported in the order of these locations. + Integrated ODF intensity within a theta angular region of SO3 about + each location (obeying symmetries) as specified for each location + in the order and stored in the order of location. unit: NX_ANY dim: (k,) phi_two_plot(NXdata): doc: | - Visualization of the ODF intensity as orthogonal sections through Euler space. + Visualization of the ODF intensity as discretized orthogonal sections + through Euler space. This is one example of typical default plots used in the texture - community in Materials Engineering. + community in materials engineering. - Mind that the Euler space is a distorted space. Therefore, equivalent - orientations show intensity contributions in eventually multiple - locations. + Mind that the Euler space is a distorted space. Therefore, equivalent orientations + show intensity contributions in eventually multiple locations. # \@signal: intensity # \@axes: [varphi_two, capital_phi, varphi_one] # \@varphi_one_indices: 0 @@ -75,8 +77,7 @@ NXmicrostructure_odf(NXprocess): # \@varphi_two_indices: 2 intensity(NX_NUMBER): doc: | - ODF intensity at probed locations relative to - null model of a completely random texture. + ODF intensity at probed locations relative to the intensity of the null model of a completely random texture. unit: NX_DIMENSIONLESS dim: (n_varphi_two, n_capital_phi, n_varphi_one) varphi_one(NX_NUMBER): @@ -85,15 +86,15 @@ NXmicrostructure_odf(NXprocess): unit: NX_ANGLE dim: (n_varphi_one,) # \@long_name(NX_CHAR): - varphi_two(NX_NUMBER): - doc: | - Pixel center angular position along the :math:`\varphi_2` direction. - unit: NX_ANGLE - dim: (n_varphi_two,) - # \@long_name(NX_CHAR): capital_phi(NX_NUMBER): doc: | Pixel center angular position along the :math:`\Phi` direction. unit: NX_ANGLE dim: (n_capital_phi,) # \@long_name(NX_CHAR): + varphi_two(NX_NUMBER): + doc: | + Pixel center angular position along the :math:`\varphi_2` direction. + unit: NX_ANGLE + dim: (n_varphi_two,) + # \@long_name(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXmicrostructure_pf.yaml b/contributed_definitions/nyaml/NXmicrostructure_pf.yaml index 7885b23f8c..500c249ed5 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_pf.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_pf.yaml @@ -9,26 +9,30 @@ symbols: type: group NXmicrostructure_pf(NXprocess): configuration(NXobject): - doc: | + doc: + - | Details about the algorithm that was used to compute the pole figure. crystal_symmetry_point_group(NX_CHAR): - doc: | - Point group of the crystal structure of the phase for which the - here documented phase-dependent pole figure was computed - (according to International Table of Crystallography). + doc: + - | + Point group of the crystal structure of the phase for which pole figure + was computed (according to International Table of Crystallography). specimen_symmetry_point_group(NX_CHAR): - doc: | - Point group assumed for processing induced sample symmetries - (according to International Table of Crystallography). + doc: + - | + Point group of assumed sample symmetries (according to International Table of Crystallography). halfwidth(NX_NUMBER): - doc: | + doc: + - | Halfwidth of the kernel. unit: NX_ANGLE miller_indices(NX_CHAR): - doc: | + doc: + - | Miller indices (:math:`(hkl)[uvw]`) to specify the pole figure. resolution(NX_NUMBER): - doc: | + doc: + - | Resolution of the kernel. unit: NX_ANGLE pf(NXdata): diff --git a/contributed_definitions/nyaml/NXmicrostructure_recon.yaml b/contributed_definitions/nyaml/NXmicrostructure_recon.yaml index 609b0b17a9..a4d4bf65d1 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_recon.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_recon.yaml @@ -1,70 +1,83 @@ -# position would need another depends_on the specific coordinate system used, currently we assume McStas -# roi1/ebsd/microstructure1 category: base doc: | - Base class to describe discretized (micro)structural features of a material. + Base class to describe structural aspects and associated descriptors of (micro)structural features. - One instance of this base class can be used to describe the current configuration - the base class does not include time-dependent descriptions for the sake of - clarity and because of the fact that virtually all simulations or experiments - probe time by sampling. Therefore, time-dependent state descriptions should - be realized with creating a set of :ref:`NXmicrostructure_snapshot_set` with instances of - :ref:`NXmicrostructure_snapshot` using e.g. :ref:`NXmicrostructure_recon` base class instances. + The continuum or atomic scale description of materials is inherently a model of reality. Such models + are useful as they enable a coarse graining and categorization of measured or simulated materials + specifically how their structural features lead to properties i.e. descriptor values. + Mind that most specimens are thermo-chemo-mechanically treated before they are characterized. + Therefore, the characterized microstructure may not have probed the same structure as of + the untreated sample or often bulk material from which the region-of-interest or specimen was probed. + + A simulation or experiment can only sample the true structure of the material. + Fields time and increment enable a quantification of the temporal evolution of a material + when using multiple instances of NXmicrostructure_recon. + + Taking inspiration from `E. E. Underwood `_ + and E. E. Underwood's book on Quantitative stereology that was published in 1970. + + Identifiers can be defined either implicitly or explicitly. For implicit indexing identifiers are defined + on the interval :math:`[identifier\_offset, identifier\_offset + cardinality - 1]`. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. - # in so-called linear intercept analysis we observe - # one-dimensional sections of either projections (see below) - # or true one-dimensional cuts across a volume of material - # n_icept: | - # The number of linear intercepts defined. - # n_c_one: | - # The number of crystal projections segmented by crossing (projected or real) interfaces - # n_i_one: | - # The number of crossings - # two-dimensional projections of characterized in reality three-dimensional objects - # using E. E. Underwood notation - # crystals/grains are projections that are delineated by projections of interface, i.e. interface lines which meet at projections of triple lines i.e. triple "points" + # one-dimensional observations and so-called linear intercept analysis we observe + # one-dimensional sections of either projections (see below) or true one-dimensional cuts across a volume of material + n_icept: | + The number of linear intercepts defined. + n_c_one: | + The number of crystal projections segmented by crossing (projected or real) interfaces. + n_i_one: | + The number of crossings + # two-dimensional projections of three-dimensional objects using E. E. Underwood notation + # crystals/grains are projections that are delineated by projections of interface, i.e. interface lines which meet at projections of triple lines aka triple points n_c_two: | The number of crystal projections. n_i_two: | The number of interface projections. n_t_two: | - The number of assumed triple junction projections aka triple points. + The number of assumed triple line projections aka triple points. # three-dimensional real objects, volumetrically characterized # crystals are delineated by interfaces that are delineated by triple lines that meet at quad junctions n_c: | - The number of crystals. + The number of crystals. Grain and sub-grain are synonyms for crystal. n_i: | - The number of interfaces + The number of interfaces. Grain boundary and phase boundary are subclasses of interface. n_t: | - The number of triple lines + The number of triple lines. n_q: | The number of quadruple junctions. type: group NXmicrostructure_recon(NXobject): - # as e.g. a result of one grain reconstruction with MTex or othe - # grain reconstruction software in commercial tools - # the idea is we may wish to run as many grain reconstructions as we want... - # add details about the processing + # as e.g. a result of one grain reconstruction with an algorithm with MTex or the grain/phase i.e. interface network reconstruction software in commercial tools + # the idea is we may wish to run as many grain reconstructions as we want and add details about the processing used for each of them if needed + comment(NX_CHAR): + doc: | + Discouraged free text field for leaving comments. + time(NX_NUMBER): + doc: | + Measured or simulated physical time stamp for this snapshot. + Not to be confused with wall-clock timing or profiling data. + unit: NX_TIME + iteration(NX_INT): + doc: | + Iteration or increment counter. + unit: NX_UNITLESS configuration(NXprocess): doc: | The configuration and parameterization of the reconstruction algorithm whereby the microstructural features were identified. - # maybe a depends_on what was the input however if the group is injected - # in an roi1/ebsd instance isnt this information implicit? dimensionality(NX_POSINT): doc: | - Dimensionality of the analysis. + Dimensionality of Euclidean space in which the analysis is conducted. - This field can be used e.g. by a research data management system - to identify if the described feature set specifies a - one-, two-, or three-dimensional feature set. + This field can be used e.g. by a research data management system to identify + if the description specifies one-, two-, or three-dimensional representations. unit: NX_UNITLESS enumeration: [1, 2, 3] algorithm(NX_CHAR): doc: | - Which algorithm is used to reconstruct the features. + Algorithm is used to reconstruct the features. enumeration: [unknown, disorientation_clustering, fast_multiscale_clustering, markov_chain_clustering] disorientation_threshold(NX_NUMBER): doc: | @@ -73,243 +86,199 @@ NXmicrostructure_recon(NXobject): which warrants to argue that there is an interface between the two regions. unit: NX_ANGLE - # the result of running one grain reconstruction - # ms_feature_set1 - # we could also enumerate instances ms_feature_setID here because configuration - # may specify a range of different parameter resulting in multiple ms_feature_sets - # dimensionality(N) composed from NXmicrostructure_feature_set base: - # controlled vocabulary of base class instances to be used to inform about the - # discretization of these features instances to discretize the features - # wherever possible the computational geometry specific instances whose - # purpose is only to support/represent the discretization of the features should - # be separated out from the materials engineering interpretation of what these - # features are, i.e. a grain that is measured with a 2d section ends up - # modelled as an projection of that real 3d grain object - # the model is discretized usign a polyline which models the location of the - # interface at the required here coarse-grained continuum picture - points(NXcg_point_set): - lines(NXcg_polyline_set): - surfaces(NXcg_triangle_set): - volumes(NXcg_polyhedron_set): - + # use controlled vocabulary terms point, line, surface, volume, use singular term + (NXcg_point_set): + (NXcg_polyline_set): + (NXcg_triangle_set): + (NXcg_polyhedron_set): + (NXcsg): # domain-specific, i.e. microstructural features - # ONE DIMENSIONAL FEATURES - - # TWO DIMENSIONAL FEATURES - crystal_projections(NXmicrostructure_feature_set): + crystal(NXobject): doc: | - Projections of crystals on the sample surface as typically - characterized with optical or electron microscopy. - \@discretization(NX_CHAR): + One- or two-dimensional projections, or three-dimensional representation of crystals. + + Crystals can be grains of different phases, precipitates, dispersoids, there are many + terms used in specifically the materials engineering community. + + Typically, as observed e.g. on the surface of a sample using with optical or electron microscopy + or as simulated as a set of pixel or evolving polygons and their polyline boundaries. + # maybe some enum what this is + representation(NX_CHAR): doc: | - Reference to lines(NXcg_polyline_set) which supports the - discretized shape of each cross-sectioned crystal. + Reference to an instance of: + + * :ref:`NXcg_point_set` for a one-dimensional representation as only a projection is available + * :ref:`NXcg_polyline_set` or :ref`NXcg_polygon_set` for a two-dimensional representation as only a projection is available + * :ref:`NXcg_polyhedron_set` for a three-dimensional representation + * :ref:`NXcg_grid` for regularly pixelated or voxelated representation Most microscopy techniques support to generate only a two-dimensional representation (projection) of the characterized material. - - For true volumetric techniques use the specifically - specialized crystals :ref:`NXmicrostructure_feature_set` instead. - See stereology literature for more details e.g. - E.E. Underwood's book entitled Quantitative Stereology number_of_crystals(NX_UINT): doc: | Number of crystals. unit: NX_UNITLESS + number_of_phases(NX_UINT): + doc: | + How many phases are distinguished + unit: NX_UNITLESS crystal_identifier_offset(NX_INT): doc: | - Integer offset whereby the identifier of the first member - of the set differs from zero. - - Identifiers can be defined either implicitly or explicitly. - For implicit indexing identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. + Integer offset whereby to distinguish crystals. unit: NX_UNITLESS crystal_identifier(NX_INT): doc: | Identifier used for crystals for explicit indexing. unit: NX_UNITLESS - dim: (n_c_two,) - number_of_phases(NX_UINT): - doc: | - How many phases are distinguished - unit: NX_UNITLESS + # n_c_one, n_c_two, n_c phase_identifier_offset(NX_INT): doc: | Integer offset whereby the identifier of the first member of the set differs from zero. unit: NX_UNITLESS phase_identifier(NX_INT): - # \@depends_on(NX_CHAR): doc: | Identifier used for phase for explicit indexing. unit: NX_UNITLESS - dim: (n_c_two,) - # properties of crystal_projections aka grain properties + # n_c_one, n_c_two, n_c + # properties + # DESCRIPTOR VALUES, SUMMARY STATISTICS boundary_contact(NX_BOOLEAN): doc: | - True, if the crystal makes contact with the edge of the ROI, - false otherwise. - dim: (n_c_two,) + True, if the crystal makes contact with the edge of the ROI false otherwise. + # n_c_one, n_c_two, n_c orientation_spread(NX_NUMBER): doc: | Average disorientation angle between individual orientation of the crystal at probed positions (weighted by area of that position) versus the average disorientation of the crystal. unit: NX_ANGLE - dim: (n_c_two,) + # n_c_one, n_c_two, n_c (NXrotation_set): + length(NX_NUMBER): + doc: | + Length of each crystal + unit: NX_LENGTH # m area(NX_NUMBER): doc: | - Calibrated area of surrounded by the polyline about each crystal. - unit: NX_AREA - dim: (n_c_two,) - interface_projections(NXmicrostructure_feature_set): - # grain boundaries have a network of line-like defects, its explicit description - # often generates unnecessary information duplication and cluttering, - # therefore here a compact and suggestion how to store such data + Area of each crystal. + unit: NX_AREA # m^2 + volume(NX_NUMBER): + doc: | + Volume of each crystal + unit: NX_VOLUME # m^3 + interface(NXobject): doc: | - Projections of grain or phase boundaries as typically sectioned - with optical or electron microscopy characterization. - \@discretization(NX_CHAR): + One- or two-dimensional projections, or three-dimensional representation of interfaces between crystals + as topological entities to dual_junctions. + + Most relevant interfaces are grain and phase boundaries but factually interfaces can also be between + the environment and crystals exposed at the surface of the specimen. + representation(NX_CHAR): doc: | - Reference to lines(NXcg_polyline_set) which supports the - discretized shape of each cross-sectioned crystal. + Reference to an instance of: + + * :ref:`NXcg_point_set` for a one-dimensional representation as only a projection is available + * :ref:`NXcg_polyline_set` for a two-dimensional representation as only a projection is available + * :ref:`NXcg_grid` for regularly pixelated or voxelated representation using (boolean) masks - Set of tuples of polyline segments which build the interface. - # topology - # i) Set of pair of crystals sharing an interface - crystals(NX_INT): + Most microscopy techniques support to generate only a two-dimensional + representation (projection) of the characterized material. + number_of_interfaces(NX_UINT): doc: | - Set of pairs of crystal_identifier resolved via depends_on which - are adjacent to each interface. + Number of interfaces. unit: NX_UNITLESS - dim: (n_i_two, 2) - \@depends_on(NX_CHAR): + identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for distinguishing interfaces. + unit: NX_UNITLESS + identifier(NX_INT): + doc: | + Integer used to distinguish features for explicit indexing. + unit: NX_UNITLESS + # n_i_one, n_i_two, n_i + # topological view, interface specification through the the pair of crystals sharing an interface + crystal(NX_INT): + doc: | + Set of pairs of crystal_identifier. + unit: NX_UNITLESS + dim: (i, 2) # with i == n_i_one, n_i_two + \@use_these(NX_CHAR): doc: | - The specific crystal_projections(NXmicrostructure_feature_set) instance - to resolve crystal identifier. - # ii) Set of pair of topologically connected triple points - triple_points(NX_INT): + The specific identifier instance to resolve ambiguities. + # topological view, interface specification through the pair of triple line projections (i.e. triple points) adjoining the interface + triple_junction(NX_INT): doc: | - Set of pairs of triple_point_identifier which the interface connects. - For 2D projections of 3D microstructural features a triple point is - physically only the projection of a triple line. + Set of pairs of triple_junction_identifier. unit: NX_UNITLESS - dim: (n_i_two, 2) - \@depends_on(NX_CHAR): + dim: (j, 2) # with j == n_i_two + \@use_these(NX_CHAR): doc: | - The specific triple_line_projections(NXmicrostructure_feature_set) instance - whereby to resolve triple_point identifier. - # alternatively which polyline of adjoining interfaces - # properties, descriptors + The specific identifier instance to resolve ambiguities. + # DESCRIPTOR VALUES length(NX_NUMBER): doc: | - The length of the interface. + The length of the interface. This is not necessarily the same as the length of the individual polyline segments whereby the interface is discretized. - - The actual coordinate system whereby the geometry is calibrated - with real physical dimensions is typically documented by the - depends_on attribute of the respective NXcg_primitive_set. - This depends_on attribute should point explicitly to an - instance of a :ref:`NXcoordinate_system` to support users as - much as possible with interpreting how and where the lines are - located in the reference frame. unit: NX_LENGTH - dim: (n_i_two,) - interface_identifier_offset(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the set differs from zero. - - Identifiers can be defined either implicitly or explicitly. - For implicit indexing identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. - unit: NX_UNITLESS - interface_identifier(NX_INT): + # n_i_one, n_i_two, n_i + area(NX_NUMBER): doc: | - Identifier for each interface using explicit indexing. - unit: NX_UNITLESS - dim: (n_i_two,) - triple_line_projections(NXmicrostructure_feature_set): - # only for 2D, quad junction is the equivalent for 3D is not a triple_line - # four alternative descriptors with different strength to specify spatial - # or logical information about the triple junction feature set. - # the explicit description often generating unnecessary information duplication + Surface area + unit: NX_AREA + triple_junction(NXobject): doc: | - Projections of triple lines as typically characterized with optical - or electron microscopy. + Projections of or representations of junctions at which interfaces between. - Mind that most specimens are thermo-chemo-mechanically treated before - they are characterized. Therefore, the projected crystal defects are - have physically no longer the same structure as in the bulk. - - Examples are manifest as effects such as thermal grooving, or relaxation - effects of an intersection between a triple line that is cut - by the specimen surface as these defects are then exposed typically - to a different atmosphere and hence have different thermodynamic boundary - conditions than of their true volumetric defects in the bulk. - \@discretization(NX_CHAR): + Junctions can be triple lines, triple points as their projections, junctions observed + between crystals at the specimen and its surface (including wetting phenomena) + representation(NX_CHAR): doc: | - Reference to points(NXcg_point_set) which supports the - locations of these triple points. + Reference to an instance of: + + * :ref:`NXcg_point_set` for a one-dimensional representation as only a projection is available + * :ref:`NXcg_polyline_set` for a two-dimensional representation as only a projection is available + * :ref:`NXcg_grid` for regularly pixelated or voxelated representation using (boolean) masks + # another view to describe a triple junction is via its topology/connection expressed either via # i) triplet of interface identifier - number_of_triple_points(NX_UINT): + number_of_junctions(NX_UINT): doc: | - Number of triple points. + Number of triple junctions. unit: NX_UNITLESS - triple_point_identifier_offset(NX_INT): + identifier_offset(NX_INT): doc: | - Integer offset whereby the identifier of the first member - of the set differs from zero. - - Identifiers can be defined either implicitly or explicitly. - For implicit indexing identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. + Integer offset where to start counting instances of the set of junctions. unit: NX_UNITLESS - triple_point_identifier(NX_INT): + identifier(NX_INT): doc: | - Identifier for each triple point using explicit indexing. + Identifier used for specifiying all members of the set of junctions. unit: NX_UNITLESS - dim: (n_t_two,) - location(NX_INT): + # n_t_one, n_t_two, n_t + # example i) triple point locations explicitly + position(NX_INT): doc: | - Set of triple point identifiers. + Set of identifier for positions whereby to identify the location of each junction. unit: NX_UNITLESS - dim: (n_t_two,) - \@depends_on(NX_CHAR): + \@use_these(NX_CHAR): doc: | - The relevant points(NXcg_point_set) instance whereby to - resolve interface identifiers. - interfaces(NX_INT): # aka topology or interfaces + The specific identifier whereby to resolve ambiguities. + # example ii) three interface projections or interface segments adjoin a triple line and point + interface(NX_INT): doc: | - Set of triplets of identifier of line-like features. - Each triplet resolves which three interface projections - the triple point connects. + Set of tuples of identifier of features connected to the junction. unit: NX_UNITLESS - dim: (n_t_two, 3) - \@depends_on(NX_CHAR): + \@use_these(NX_CHAR): doc: | - The specific interface_projections(NXmicrostructure_feature_set) - instance whereby to resolve interface identifiers. - # ii) a triplet of line segment identifier whereby the point-like features - # is assumed discretized via three polylines representing interfaces - polylines(NX_INT): + The specific identifier to instances of interface identifiers whereby to resolve ambiguities. + # example iii) e.g. three polyline segments enter a triple point + polyline(NX_INT): doc: | - Triplet of identifier of polyline segments. Each triplet resolves - which three segments of polyline segments the triple junction connects. + Set of tuples of identifier for representation of discretized features connected to the junction. unit: NX_UNITLESS - dim: (n_t_two, 3) - \@depends_on(NX_CHAR): + \@use_these(NX_CHAR): doc: | - The specific lines(NXcg_polyline_set) instance to resolve - polyline segments. - # the difference in the interpretation of interfaces and polylines - # is that the interface resolves interface (e.g. phase boundary names) - # while polylines resolves segments within the set of named geometric primitive - # instances! - # add all sort of other qualitative or quantitive descriptors (triple junction - # energy, volume etc), i.e properties of that triple point + The specific identifier to instances of NXcg primitives whereby to resolve ambiguities. + # DESCRIPTOR VALUES From 612c550062bcb507276559c024bc256cab0bc04f Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 9 Jul 2024 16:53:53 +0200 Subject: [PATCH 0787/1012] Removed NXmicrostructure_recon --- contributed_definitions/NXem_ebsd.nxdl.xml | 2 +- ...con.nxdl.xml => NXmicrostructure.nxdl.xml} | 4 +- .../NXmicrostructure_kanapy_results.nxdl.xml | 2 +- contributed_definitions/nyaml/NXem_ebsd.yaml | 2 +- ...cture_recon.yaml => NXmicrostructure.yaml} | 4 +- .../nyaml/NXmicrostructure_blueprint.txt | 461 ------------------ .../NXmicrostructure_kanapy_results.yaml | 2 +- .../icme-structure.rst | 5 +- 8 files changed, 9 insertions(+), 473 deletions(-) rename contributed_definitions/{NXmicrostructure_recon.nxdl.xml => NXmicrostructure.nxdl.xml} (98%) rename contributed_definitions/nyaml/{NXmicrostructure_recon.yaml => NXmicrostructure.yaml} (99%) delete mode 100644 contributed_definitions/nyaml/NXmicrostructure_blueprint.txt diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index e29246f637..3545c952c9 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -474,7 +474,7 @@ to sample_reference_frame - + diff --git a/contributed_definitions/NXmicrostructure_recon.nxdl.xml b/contributed_definitions/NXmicrostructure.nxdl.xml similarity index 98% rename from contributed_definitions/NXmicrostructure_recon.nxdl.xml rename to contributed_definitions/NXmicrostructure.nxdl.xml index f661721857..ef7fa83eac 100644 --- a/contributed_definitions/NXmicrostructure_recon.nxdl.xml +++ b/contributed_definitions/NXmicrostructure.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -97,7 +97,7 @@ crystals are delineated by interfaces that are delineated by triple lines that m A simulation or experiment can only sample the true structure of the material. Fields time and increment enable a quantification of the temporal evolution of a material - when using multiple instances of NXmicrostructure_recon. + when using multiple instances of NXmicrostructure. Taking inspiration from `E. E. Underwood <https://doi.org/10.1111/j.1365-2818.1972.tb03709.x>`_ and E. E. Underwood's book on Quantitative stereology that was published in 1970. diff --git a/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml b/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml index aaa3c9d361..a8d9939cca 100644 --- a/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml @@ -70,7 +70,7 @@ - + diff --git a/contributed_definitions/nyaml/NXem_ebsd.yaml b/contributed_definitions/nyaml/NXem_ebsd.yaml index a1915830a4..229cddf68b 100644 --- a/contributed_definitions/nyaml/NXem_ebsd.yaml +++ b/contributed_definitions/nyaml/NXem_ebsd.yaml @@ -366,7 +366,7 @@ NXem_ebsd(NXem_method): odfID(NXmicrostructure_odf): pID(NXmicrostructure_pf): ipfID(NXmicrostructure_ipf): - microstructureID(NXmicrostructure_recon): + microstructureID(NXmicrostructure): # overview over the entire map, rediscretized on a tight aabb roi(NXdata): doc: | diff --git a/contributed_definitions/nyaml/NXmicrostructure_recon.yaml b/contributed_definitions/nyaml/NXmicrostructure.yaml similarity index 99% rename from contributed_definitions/nyaml/NXmicrostructure_recon.yaml rename to contributed_definitions/nyaml/NXmicrostructure.yaml index a4d4bf65d1..93c04c8df9 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_recon.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure.yaml @@ -11,7 +11,7 @@ doc: | A simulation or experiment can only sample the true structure of the material. Fields time and increment enable a quantification of the temporal evolution of a material - when using multiple instances of NXmicrostructure_recon. + when using multiple instances of NXmicrostructure. Taking inspiration from `E. E. Underwood `_ and E. E. Underwood's book on Quantitative stereology that was published in 1970. @@ -48,7 +48,7 @@ symbols: n_q: | The number of quadruple junctions. type: group -NXmicrostructure_recon(NXobject): +NXmicrostructure(NXobject): # as e.g. a result of one grain reconstruction with an algorithm with MTex or the grain/phase i.e. interface network reconstruction software in commercial tools # the idea is we may wish to run as many grain reconstructions as we want and add details about the processing used for each of them if needed comment(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXmicrostructure_blueprint.txt b/contributed_definitions/nyaml/NXmicrostructure_blueprint.txt deleted file mode 100644 index fc1873e27b..0000000000 --- a/contributed_definitions/nyaml/NXmicrostructure_blueprint.txt +++ /dev/null @@ -1,461 +0,0 @@ -category: application -doc: | - Application definition, spatiotemporal characterization of a microstructure. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_b: | - Number of boundaries of the bounding box or primitive to domain. - n_p: | - Number of parameter required for the chosen orientation parameterization. - c: | - Number of texture components identified. - -# key points to keep in mind when thinking about a general enough description for coarse-graining systems of atoms into -# so-called microstructural features of interest for which we may store also thermodynamic properties or other feature-specific descriptors -# several viewpoints how to coarse-grain are equally justified: grains are useful when there are crystallites with adjoining interfaces and # none, or only some statistical populations of defects and/or some spatially-well defined defects inside these -# however, if grains are build almost only from defects like dislocation walls, it might no longer be useful to define the grains -# as a well identifiable region whose majority volume shows long-range atomic periodicity (so that defining an orientation makes) sense. -# one could then rather describe the set of defects. Alternatively one could describe a material volume by sampling individual so-called -# material points (e.g. in continuum-scale plasticity models) or describe the material volume really from the atoms up -# but there are many terms used in materials engineering which people may want to distinguish which stand however between the scales e.g. -# lattice curvature, this is jargon with some truth in it but curvature has to be build from atoms and defects need to build the curvature -# dislocations are another good example where different research questions demand differently granularized descriptions e.g. -# average density, total line length, per character, per family, line length, curvature, jog, kink density, -# coarse-grainable structural motifs in the dislocation core, atomic structure -# also different scales one would like to distinguish as this is relevant when defects couple/show spatiotemporal correlations -# to specific mechanisms (e.g. phonons) or when defect affect the properties of other defects -# ambiguous choices: is the grain boundary part of the grain or is it an own defect? -# i.e. can/should we store grains as childs of their grain boundary set vs the interface the childs of the grains? -# Depending on the use case we need to have a flexible description which can address a continuum of descriptors: -# important is that one can logically map different features -# Length scale of homogeneity: With the reality of a multi-parameter space of all possible methods and effects and -# different external stimuli applied for real materials, simulations in computational materials science typically focus -# their analysis on a few individual, spatiotemporally constrained effects and boundary conditions for which the simulation -# is formulated, useful, interpretable, and comparable to experiment. -# Data structures for multi-scale materials modeling IMM/ICME are currently diverse because they reflect the above-mentioned needs -# and different views which researchers have on their simulations e.g. DFT (time, length-scale, which electronic effects) -# RVE annealing phenomena at the micrometer scale (pressure, temperature, length scale, interactions considered or not) -# Some regions are well separated spatially (although it can be non-trivial to quantify the distance in a multi-dim parameter space) -# Some simulations are cross-scale (classical MD at the cutting edge with micrometer crystal plasticity microsecond and/or annealing at -# ns time scale) MD with classical vs abinitio-informed potential for studying evolution of mechanisms and phenomena at different length scales -type: group -NXmicrostructure(NXobject): - (NXentry): - \@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: [NXmicrostructure] - workflow_identifier: - doc: | - Ideally, a (globally) unique persistent identifier - for referring to this experiment or computer simulation. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - workflow_description: - exists: optional - doc: | - Free-text description about the workflow (experiment/analysis/simulation). - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of this application definition rather than write details about the - experiment into this free-text description field. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 time code with local time zone offset to UTC information - included when the characterization started. - end_time(NX_DATE_TIME): - exists: recommended - doc: | - ISO 8601 time code with local time zone offset to UTC included - when the characterization ended. - PROGRAM(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program_name: - \@version: - experiment_or_simulation: - doc: | - Specify if the (characterization) results/data of this instance of an - application definition are based on the results of a simulation or the - results of a post-processing of measured data to describe - a microstructure. - - The term microstructure is used to describe the spatial arrangement of - crystal defects inside a sample/specimen without demanding necessarily - that this structure is mainly at the micron length scale. - Nanostructure and macrostructure are close synonyms. - Material architecture is a narrow synonym. - - Given that microstructure simulations nowadays more and more consider - the atomic arrangement, this application definition can also be used - to describe features at the scale of atoms. - enumeration: [experiment, simulation] - USER(NXuser): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - Contact information and eventually details of at least one person - involved in creating this result. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is recommended. - 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. - specimen(NXsample): - - # NEW ISSUE: inject the conclusion from the discussion with Andrea - # according to SAMPLE.yaml 0f8df14 2022/06/15 - name: - doc: | - Descriptive name or ideally (globally) unique persistent identifier. - - # sample_history: - # 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. - # preparation_date(NX_DATE_TIME): - # doc: | - # ISO 8601 time code with local time zone offset to UTC information - # when the specimen was prepared. - (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): - doc: | - Container to hold different coordinate systems conventions. - A least a right-handed Cartesian coordinate system with base vectors - named x, y, and z has to be specified. Each base vector of the - coordinate system should be described with an NXtransformations instance. - TRANSFORMATIONS(NXtransformations): - exists: ['min', '3', 'max', 'unbounded'] - conventions(NXem_conventions_ebsd): - rotation_conventions(NXprocess): - three_dimensional_rotation_handedness: - rotation_convention: - euler_angle_convention: - axis_angle_convention: - orientation_parameterization_sign_convention: - processing_reference_frame(NXprocess): - reference_frame_type: - xaxis_direction: - xaxis_alias: - yaxis_direction: - yaxis_alias: - zaxis_direction: - zaxis_alias: - origin: - sample_reference_frame(NXprocess): - reference_frame_type: - xaxis_direction: - yaxis_direction: - zaxis_direction: - origin: - ROI_SET(NXcg_roi_set): - exists: ['min', '1', 'max', 'unbounded'] - - # however for solitary unit models (i.e. ensembles of volume elements/simulation domains) and for replica methods - # we may need more than one domain - # the volume element is not called representative because for what a volume element is representative is a matter of - # interpretation (fundamentally this is an assumption) and can differ for different descriptors - doc: | - The simulated or characterized material volume element aka domain. - At least one instance of geometry required either NXcg_grid, - NXcg_polyhedron_set, or NXcg_point_set. This geometry group needs - to contain details about the boundary conditions. - grid(NXcg_grid): - exists: optional - - # specific application definitions can use these fields to specialize - point_set(NXcg_point_set): - exists: optional - polyhedron_set(NXcg_polyhedron_set): - exists: optional - boundary(NXcg_polyhedron_set): - exists: optional - doc: | - A boundary to the volume element. - Either an instance of NXcg_hexahedron_set or of NXcg_ellipsoid_set. - - # a good example for a general bounding box description for such a grids of triclinic cells - # https://docs.lammps.org/Howto_triclinic.html NXcg_hexahedron_set because can be a parallelepiped - number_of_boundaries(NX_POSINT): - unit: NX_UNITLESS - doc: | - How many distinct boundaries are distinguished. Value required equal to n_b. - boundaries: - doc: | - Name of the boundaries. E.g. left, right, front, back, bottom, top, - dimensions: - rank: 1 - dim: [[1, n_b]] - boundary_conditions(NX_UINT): - unit: NX_UNITLESS - doc: | - The boundary conditions for each boundary: - - 0 - undefined - 1 - open - 2 - periodic - 3 - mirror - 4 - von Neumann - 5 - Dirichlet - dimensions: - rank: 1 - dim: [[1, n_b]] - snapshot_set(NXmicrostructure_snapshot_set): - doc: | - Collection of microstructural data observed/simulated. - identifier_offset(NX_UINT): - unit: NX_UNITLESS - doc: | - Integer which specifies the first index to be used for distinguishing - snapshots. Identifiers are defined either implicitly or explicitly. - For implicit indexing the identifiers are defined on the - interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate - if the identifiers are expected to start from 1 (referred to as - Fortran-/Matlab-) or from 0 (referred to as C-, Python-style index - notation) respectively. - - # essentially NXmonitor instances for evolution of ensemble summary statistics - evolution(NXprocess): - exists: optional - doc: | - Summary quantities which are the result of some post-processing of - the snapshot data (averaging, integrating, interpolating). - Frequently used descriptors from continuum mechanics and thermodynamics - can be used here. A few examples are given. Each descriptor is currently - modelled as an instance of an NXprocess because it is relevant to - understand how the descriptors are computed. - temperature(NXprocess): - exists: optional - pressure(NXprocess): - exists: optional - stress(NXprocess): - exists: optional - strain(NXprocess): - exists: optional - deformation_gradient(NXprocess): - exists: optional - magnetic_field(NXprocess): - exists: optional - electric_field(NXprocess): - exists: optional - - # time-resolved results for individual snapshots - # virtually all computer simulations and all experiments always probe - # snapshots - MS_SNAPSHOT(NXmicrostructure_snapshot): - time(NX_NUMBER): - unit: NX_TIME - doc: | - Measured or simulated physical time stamp for this snapshot. - Not to be confused with wall-clock timing or profiling data. - iteration(NX_UINT): - unit: NX_UNITLESS - doc: | - Iteration or increment counter. - - # optional places to store the grid for instance if it changes - grid(NXcg_grid): - exists: optional - polyhedron_set(NXcg_polyhedron_set): - exists: optional - point_set(NXcg_point_set): - exists: optional - - # homogenization: - # constituent: - # constitutive: - # ROI(NXcg_roi_set): #multiple rois, for each geometry, connectivity/topology, cellType... - # see that the materialpoint that is tracked conceptually in tools like DAMASK is a ROI (which is currently scale-invariant), isnt a coarse-graining of atom configurations a homogenization - # several "results" homogenized quantities at (eventually different length scales - # continuum-scale view thermodynamic(NXview) - # mechanical - # damage - # thermal - # composition - MS_FEATURE_SET(NXmicrostructure_feature_set): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - Conceptually distinguished object/feature in the ROI/ - system with some relevance. Instances of NXmicrostructure_feature_set can - be nested to build a hierarchy of logically-related objects. - - A typical example for MD simulations is to have one - ms_feature_set for the atoms which is the parent to another - ms_feature_set for monomers/molecules/proteins which is then the - parent to another ms_feature_set for the secondary, another feature_set - for the tertiary, and the parent for another feature_set for the - quaternary structure. - - Another typical example from materials engineering is to have - one ms_feature_set for crystals (grains/phases) which serves as - the parent to another ms_feature_set for interfaces between these - crystals which then is the parent for another ms_feature_set to - describe the triple junctions which is then the parent for the - quadruple/higher-order junctions between which connect the - triple lines. - - Another example from discrete dislocation dynamics could be to - have one ms_feature_set for the dislocations (maybe separate - sets for each dislocation type or family) which are then - parents to other ms_feature_set which describe junctions between - dislocations or features along the dislocation line network. - - # respective application definitions based on NXmicrostructure should add and - # specialize - odf(NXprocess): - exists: optional - doc: | - Details about the orientation distribution function - within the entire domain. - computation_method: - doc: | - With which method was the ODF approximated? - - # add approximation parameter - texture_index(NX_NUMBER): - exists: optional - unit: NX_ANY - doc: | - TO BE DEFINED - texture_strength(NX_NUMBER): - exists: optional - unit: NX_ANY - doc: | - TO BE DEFINED - volume_statistics(NXcollection): - exists: optional - doc: | - Collection of texture components commonly referred to. - TRANSFORMATIONS(NXtransformations): - doc: | - Reference to or definition of a coordinate system with - which the definitions are interpretable. - parameterization: - enumeration: [bunge-euler (ZXZ), quaternion] - orientation(NX_NUMBER): - unit: NX_ANY - doc: | - Parameterized orientations. - dimensions: - rank: 2 - dim: [[1, c], [2, n_p]] - name: - doc: | - Name of each texture component, e.g. Cube, Dillamore, Y. - dimensions: - rank: 1 - dim: [[1, c]] - integration_radius(NX_NUMBER): - unit: NX_ANGLE - doc: | - The portion of orientation space integrated over - to compute the volume fraction. - dimensions: - rank: 1 - dim: [[1, c]] - volume_fraction(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - The volume fraction of each texture component. - dimensions: - rank: 1 - dim: [[1, c]] - - # a grain-boundary character distribution - # is again a spatial correlation statistics, GBCD can be understood like an ODF in that the entire surface Of a grain boundary (interface) network is partitioned into regions between grains in specific disorientation relationships, and boundary plane inclination so that one can again ask for the "texture" i.e. which fraction of the area network is of specific disorientation and nominal plane inclination relationship - modf(NXprocess): - exists: optional - doc: | - Details about the disorientation distribution function - within the entire domain. - gbcd(NXprocess): - exists: optional - doc: | - Details about the grain boundary character distribution - within the entire domain. - - # add descriptions for the state of each cell - # e.g. values of phase field variables if desired - temperature(NXprocess): - exists: optional - pressure(NXprocess): - exists: optional - stress(NXprocess): - exists: optional - strain(NXprocess): - exists: optional - deformation_gradient(NXprocess): - exists: optional - magnetic_field(NXprocess): - exists: optional - electric_field(NXprocess): - exists: optional - recrystallization_kinetics(NXprocess): - exists: optional - grain_size_distribution(NXprocess): - exists: optional - recrystallization_front(NXprocess): - exists: optional diff --git a/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml index 81e7aadea6..d94927168c 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml @@ -42,7 +42,7 @@ NXmicrostructure_kanapy_results(NXobject): program(NX_CHAR): \@version(NX_CHAR): # no units instead labelled-property graph concepts with units - microstructureID(NXmicrostructure_recon): + microstructureID(NXmicrostructure): exists: [min, 1, max, infty] (NXcg_grid): # size but much more capable exists: optional diff --git a/manual/source/classes/contributed_definitions/icme-structure.rst b/manual/source/classes/contributed_definitions/icme-structure.rst index be103b4032..1946b02c8e 100644 --- a/manual/source/classes/contributed_definitions/icme-structure.rst +++ b/manual/source/classes/contributed_definitions/icme-structure.rst @@ -24,10 +24,7 @@ materials-engineering-specific data schemas can connect to or be mapped on concepts which are equally modellable with NeXus: :ref:`NXmicrostructure`: - An application definition for arbitrary spatiotemporally resolved simulations. - - :ref:`NXmicrostructure_recon`: - A base class for documenting results of reconstructed microstructures. + A base class for documenting a snapshot of a reconstructed microstructures. :ref:`NXmicrostructure_score_config`, :ref:`NXmicrostructure_score_results`: A specific example of an application definition for documenting the From f88f38d55ad28ed0d88b905c343b66113df04801 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 9 Jul 2024 17:19:21 +0200 Subject: [PATCH 0788/1012] Fix documentation generation --- .../NXmicrostructure_gragles_config.nxdl.xml | 1 - .../NXmicrostructure_gragles_results.nxdl.xml | 3 +-- .../NXmicrostructure_imm_config.nxdl.xml | 5 ++--- .../NXmicrostructure_kanapy_results.nxdl.xml | 4 ++-- .../NXmicrostructure_score_config.nxdl.xml | 6 ++++-- .../NXmicrostructure_score_results.nxdl.xml | 7 +++---- .../nyaml/NXmicrostructure_gragles_config.yaml | 2 -- .../nyaml/NXmicrostructure_gragles_results.yaml | 1 - .../nyaml/NXmicrostructure_imm_config.yaml | 6 ++---- .../nyaml/NXmicrostructure_kanapy_results.yaml | 4 ++-- .../nyaml/NXmicrostructure_score_config.yaml | 7 +++++-- .../nyaml/NXmicrostructure_score_results.yaml | 13 ++++--------- 12 files changed, 25 insertions(+), 34 deletions(-) diff --git a/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml b/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml index 742d1a238a..25d9428b5e 100644 --- a/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml @@ -42,7 +42,6 @@ type: group--> - diff --git a/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml b/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml index 325798bc54..df73e88b4b 100644 --- a/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml @@ -34,6 +34,5 @@ symbols:--> - + diff --git a/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml b/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml index bcf60eec02..5e9db5c1c1 100644 --- a/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml @@ -36,7 +36,6 @@ type: group--> - @@ -112,7 +111,7 @@ remove 0 all the time 0.00 - + @@ -120,7 +119,7 @@ remove 0 all the time 0.00 - + diff --git a/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml b/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml index a8d9939cca..51e69d74b3 100644 --- a/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml @@ -42,8 +42,8 @@ Discouraged free-text field to add further details to the computation. - - + + diff --git a/contributed_definitions/NXmicrostructure_score_config.nxdl.xml b/contributed_definitions/NXmicrostructure_score_config.nxdl.xml index b5d49c1241..0fde2ec03c 100644 --- a/contributed_definitions/NXmicrostructure_score_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_score_config.nxdl.xml @@ -40,11 +40,13 @@ - Application definition to control a simulation with the SCORE model. + Application definition to configure a simulation with the SCORE model. + + * `M. Kühbach et al. <https://doi.org/10.1016/j.actamat.2016.01.068>`_ + * `M. Diehl et al. <https://doi.org/10.1088/1361-651X/ab51bd>`_ - diff --git a/contributed_definitions/NXmicrostructure_score_results.nxdl.xml b/contributed_definitions/NXmicrostructure_score_results.nxdl.xml index b0cc16db74..fbf590001f 100644 --- a/contributed_definitions/NXmicrostructure_score_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_score_results.nxdl.xml @@ -81,7 +81,6 @@ inspect comments behind NXmicrostructure--> - @@ -303,7 +302,7 @@ when the specimen was prepared.--> - + - + Measured or simulated physical time stamp for this snapshot. diff --git a/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml index 798fdb9113..970405e06a 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml @@ -16,8 +16,6 @@ NXmicrostructure_gragles_config(NXobject): (NXentry): definition(NX_CHAR): enumeration: [NXmicrostructure_gragles_config] - \@version(NX_CHAR): - starting_configuration(NX_CHAR): doc: | Which starting configuration to take. diff --git a/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml index 934ad4c99a..70b6cd6175 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml @@ -7,5 +7,4 @@ NXmicrostructure_gragles_results(NXobject): (NXentry): definition(NX_CHAR): enumeration: [NXmicrostructure_gragles_results] - # \@version(NX_CHAR): # TODO: populate further based on appdefs NXmicrostructure_score_results \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml index 5031445500..ecf5117a30 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml @@ -10,8 +10,6 @@ NXmicrostructure_imm_config(NXobject): (NXentry): definition(NX_CHAR): enumeration: [NXmicrostructure_imm_config] - \@version(NX_CHAR): - roi(NXroi): dimensionality(NX_UINT): doc: | @@ -62,11 +60,11 @@ NXmicrostructure_imm_config(NXobject): unit: NX_ANY # 1/m^2 dim: (2,) # 10.8e14# 10.8e144.0e14 + variance_grain(NX_FLOAT): # 4.0e14 # doc: | unit: NX_ANY # 1/m^2 - variance??_subgrain(NX_FLOAT): # 0.8e14 + variance_subgrain(NX_FLOAT): # 0.8e14 doc: | unit: NX_ANY # 1/m^2 orientation_distribution_model(NXprocess): # CR70FeSi.Rogge.MTEX.vpsc.odf.5000.txt diff --git a/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml index d94927168c..20a549db27 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml @@ -15,8 +15,8 @@ NXmicrostructure_kanapy_results(NXobject): description(NX_CHAR): doc: | Discouraged free-text field to add further details to the computation. - start_time(NX_DATETIME): # better with UTC - end_time(NX_DATETIME): # better to get elapsed time + start_time(NX_DATE_TIME): # better with UTC + end_time(NX_DATE_TIME): # better to get elapsed time exists: recommended profiling(NXcs_profiling): exists: optional diff --git a/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml index b441159710..f8ce0264d7 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml @@ -1,6 +1,10 @@ category: application doc: | - Application definition to control a simulation with the SCORE model. + Application definition to configure a simulation with the SCORE model. + + * `M. Kühbach et al. `_ + * `M. Diehl et al. `_ + symbols: n_dg_ori: | Number of Bunge-Euler angle triplets for deformed grains. @@ -12,7 +16,6 @@ type: group NXmicrostructure_score_config(NXobject): (NXentry): definition(NX_CHAR): - \@version(NX_CHAR): enumeration: [NXmicrostructure_score_config] PROGRAM(NXprogram): program_name: diff --git a/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml index c00acc8264..3c4851b3fa 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml @@ -36,7 +36,6 @@ type: group NXmicrostructure_score_results(NXobject): (NXentry): definition(NX_CHAR): - \@version(NX_CHAR): enumeration: [NXmicrostructure_score_results] analysis_identifier: doc: | @@ -78,7 +77,6 @@ NXmicrostructure_score_results(NXobject): Nanostructure and macrostructure are close synonyms. Material architecture is a narrow synonym. enumeration: [experiment, simulation] - # always a simulation! config_filename: doc: | @@ -161,13 +159,11 @@ NXmicrostructure_score_results(NXobject): Name of the social media platform where the account under social_media_name is registered. specimen(NXsample): - # NEW ISSUE: inject the conclusion from the discussion with Andrea # according to SAMPLE.yaml 0f8df14 2022/06/15 name: doc: | Descriptive name or ideally (globally) unique persistent identifier. - # sample_history: # doc: | # Ideally, a reference to the location of or a (globally) unique @@ -214,9 +210,8 @@ NXmicrostructure_score_results(NXobject): yaxis_direction: zaxis_direction: origin: - ROI_SET(NXcg_roi_set): - exists: ['min', '1', 'max', 'unbounded'] - + roiID(NXroi): + exists: [min, 1, max, infty] # however for solitary unit models aka volume element ensemble, replica methods we may need more than one domain # the volume element is not called representative because for what we consider the volume element to be representative # for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors @@ -264,7 +259,7 @@ NXmicrostructure_score_results(NXobject): dimensions: rank: 1 dim: [[1, n_b]] - snapshot_set(NXmicrostructure_snapshot_set): + spatiotemporal(NXobject): doc: | Collection of microstructural data observed/simulated. identifier_offset(NX_UINT): @@ -322,7 +317,7 @@ NXmicrostructure_score_results(NXobject): # time-resolved results for individual snapshots # virtually all computer simulations and all experiments always probe # snapshots - MS_SNAPSHOT(NXmicrostructure_snapshot): + microstructureID(NXmicrostructure): time(NX_NUMBER): unit: NX_TIME doc: | From 9b23f4ec57c870a43bbf4a78611f27a08cffc5a6 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 9 Jul 2024 20:10:17 +0200 Subject: [PATCH 0789/1012] Continuing on NXmicrostructure --- .../nyaml/NXmicrostructure.yaml | 337 +++++++++++++----- 1 file changed, 240 insertions(+), 97 deletions(-) diff --git a/contributed_definitions/nyaml/NXmicrostructure.yaml b/contributed_definitions/nyaml/NXmicrostructure.yaml index 93c04c8df9..d3b24fd19a 100644 --- a/contributed_definitions/nyaml/NXmicrostructure.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure.yaml @@ -1,51 +1,83 @@ category: base doc: | - Base class to describe structural aspects and associated descriptors of (micro)structural features. + Base class to describe a structural aspects, associated descriptors of a set of (micro)structural features. - The continuum or atomic scale description of materials is inherently a model of reality. Such models - are useful as they enable a coarse graining and categorization of measured or simulated materials - specifically how their structural features lead to properties i.e. descriptor values. - Mind that most specimens are thermo-chemo-mechanically treated before they are characterized. - Therefore, the characterized microstructure may not have probed the same structure as of - the untreated sample or often bulk material from which the region-of-interest or specimen was probed. + The continuum or atomic scale description of materials is a model of reality. Such models are useful as + they enable a coarse graining and categorizing of properties and aspects of the representation of + measured or simulated materials specifically in regards to how their structural features lead to properties + i.e. descriptor values. - A simulation or experiment can only sample the true structure of the material. - Fields time and increment enable a quantification of the temporal evolution of a material - when using multiple instances of NXmicrostructure. + Keep in mind that most specimens are thermo-chemo-mechanically processed prior characterization. + Therefore, the characterized microstructure may not have probed the same structure as of the untreated + sample or the bulk material from which region-of-interests on the specimen were probed. - Taking inspiration from `E. E. Underwood `_ - and E. E. Underwood's book on Quantitative stereology that was published in 1970. + A simulation or experiment cannot sample the true structure of the material. Fields such as time and increment + enable a quantification of the spatiotemporal evolution of a materials structure by using multiple instances + of NXmicrostructure. - Identifiers can be defined either implicitly or explicitly. For implicit indexing identifiers are defined + A key challenge with the description the representation and properties of microstructural features is that + features with different dimensionality exist and combinations of features of different dimensionality are + frequently expected to be documented with a low barrier and intuitive naming convention matching terms + used in the community. + + Most microscopy techniques support to generate only a two-dimensional representation (projection) + of the characterized material. + + A crystal, an interface, a junction is an object in three-dimensional Euclidean space although that crystal may + be formed just by a monolayer of atoms. Despite being a three-dimensional object, though, a crystal can often + not be observed technically three-dimensionally but using projections only. Likewise, interfaces bounding the + volume of a crystal can often be characterized only as projections of the surface patches. + The descriptive variety is large especially for junctions. Junctions are assumed, like crystals and interfaces + to represent groups of atoms that have specific descriptor values which are different to other features. + As an example a triple junction is thus a three-dimensional defect as the atoms arrange in three-dimensional + spaced but the characteristics of that defect can often be reduced to a lower-dimensional description such as + a triple point or a triple line. While this affects which base classes can be used to represent a discretization of + their structure topologically it holds for the example of a triple junction at least three lower dimensional features meet. + Most importantly these are the adjoining interfaces. However, assuming that dislocation lines in practice interact + with triple junctions not only more than three two-dimensional features meet but also one-dimensional features. + + The description attempt here took inspiration from `E. E. Underwood `_ + and E. E. Underwood's book on Quantitative Stereology published 1970 to categorize features based on their dimensionality. + + Identifiers can be defined either implicitly or explicitly. Identifiers for implicit indexing are defined on the interval :math:`[identifier\_offset, identifier\_offset + cardinality - 1]`. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. - # one-dimensional observations and so-called linear intercept analysis we observe + n_c: | + The number of crystals. + n_i: | + The number of interfaces. + n_t: | + The number of triple junctions. + n_q: | + The number of quadruple_junctions. # one-dimensional sections of either projections (see below) or true one-dimensional cuts across a volume of material - n_icept: | - The number of linear intercepts defined. n_c_one: | - The number of crystal projections segmented by crossing (projected or real) interfaces. + The number of one-dimensional crystal projections n_i_one: | - The number of crossings + The number of one-dimensional interface projections + # n_t_one: | + # The number of one-dimensional triple line projections # two-dimensional projections of three-dimensional objects using E. E. Underwood notation # crystals/grains are projections that are delineated by projections of interface, i.e. interface lines which meet at projections of triple lines aka triple points n_c_two: | - The number of crystal projections. + The number of two-dimensional crystal projections n_i_two: | - The number of interface projections. - n_t_two: | - The number of assumed triple line projections aka triple points. + The number of two-dimensional interface projections + n_t_two: | + The number of two-dimensional triple line projections + # n_q_two: | + # The number of two-dimensional quadruple junction projections # three-dimensional real objects, volumetrically characterized # crystals are delineated by interfaces that are delineated by triple lines that meet at quad junctions - n_c: | - The number of crystals. Grain and sub-grain are synonyms for crystal. - n_i: | - The number of interfaces. Grain boundary and phase boundary are subclasses of interface. - n_t: | - The number of triple lines. - n_q: | + n_c_three: | + The number of crystals (grain and sub-grain are exact synonyms for crystal). + n_i_three: | + The number of interfaces (grain boundary and phase boundary are subclasses of interfaces). + n_t_three: | + The number of triple junctions (triple line is a exact synonym for triple junction, triple point is projection of a triple junction). + n_q_three: | The number of quadruple junctions. type: group NXmicrostructure(NXobject): @@ -53,10 +85,10 @@ NXmicrostructure(NXobject): # the idea is we may wish to run as many grain reconstructions as we want and add details about the processing used for each of them if needed comment(NX_CHAR): doc: | - Discouraged free text field for leaving comments. + Discouraged free-text field for leaving comments. time(NX_NUMBER): doc: | - Measured or simulated physical time stamp for this snapshot. + Measured or simulated physical time stamp for this microstructure snapshot. Not to be confused with wall-clock timing or profiling data. unit: NX_TIME iteration(NX_INT): @@ -65,11 +97,11 @@ NXmicrostructure(NXobject): unit: NX_UNITLESS configuration(NXprocess): doc: | - The configuration and parameterization of the reconstruction algorithm - whereby the microstructural features were identified. + Group where to store details about the configuration and parameterization of eventually used algorithms + whereby microstructural features were identified. dimensionality(NX_POSINT): doc: | - Dimensionality of Euclidean space in which the analysis is conducted. + Dimensionality of Euclidean space in which the analysis is performed. This field can be used e.g. by a research data management system to identify if the description specifies one-, two-, or three-dimensional representations. @@ -77,22 +109,27 @@ NXmicrostructure(NXobject): enumeration: [1, 2, 3] algorithm(NX_CHAR): doc: | - Algorithm is used to reconstruct the features. + Algorithm whereby microstructural features were reconstructed. + + * Disorientation clustering groups nearby material points based on their crystallographic disorientation + * Fast multiscale clustering based on `D. Kushnir et al. `_ + * Markov chain clustering `F. Niessen et al. `_ + enumeration: [unknown, disorientation_clustering, fast_multiscale_clustering, markov_chain_clustering] disorientation_threshold(NX_NUMBER): doc: | - Threshold to define at which disorientation angle to assume - two crystalline regions have a significant orientation difference - which warrants to argue that there is an interface between the - two regions. + Threshold to define at which disorientation angle to assume two crystalline regions have a significant + orientation difference that warrants to argue that there is an interface between the two regions. unit: NX_ANGLE - # use controlled vocabulary terms point, line, surface, volume, use singular term + # use controlled vocabulary terms point, line, surface, volume, use singular term when instantiating (NXcg_point_set): (NXcg_polyline_set): (NXcg_triangle_set): (NXcg_polyhedron_set): + # constructive solid geometry to describe curved features (NXcsg): - # domain-specific, i.e. microstructural features + # (NXcontinuous_function): + # examples for specific frequently discussed microstructural features crystal(NXobject): doc: | One- or two-dimensional projections, or three-dimensional representation of crystals. @@ -110,50 +147,49 @@ NXmicrostructure(NXobject): * :ref:`NXcg_point_set` for a one-dimensional representation as only a projection is available * :ref:`NXcg_polyline_set` or :ref`NXcg_polygon_set` for a two-dimensional representation as only a projection is available * :ref:`NXcg_polyhedron_set` for a three-dimensional representation - * :ref:`NXcg_grid` for regularly pixelated or voxelated representation - - Most microscopy techniques support to generate only a two-dimensional - representation (projection) of the characterized material. + * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions number_of_crystals(NX_UINT): doc: | - Number of crystals. + How many crystals are distinguished. + + Crystals are listed irrespective of the (thermodynamic) + phase to which these crystals are assigned. unit: NX_UNITLESS number_of_phases(NX_UINT): doc: | - How many phases are distinguished + How many phases are distinguished. unit: NX_UNITLESS crystal_identifier_offset(NX_INT): doc: | - Integer offset whereby to distinguish crystals. + First identifier whereby to identify crystals implicitly. unit: NX_UNITLESS crystal_identifier(NX_INT): doc: | - Identifier used for crystals for explicit indexing. + Identifier whereby to identify each crystal explicitly. unit: NX_UNITLESS - # n_c_one, n_c_two, n_c + # dim: n_c_one, n_c_two, n_c phase_identifier_offset(NX_INT): doc: | - Integer offset whereby the identifier of the first member - of the set differs from zero. + First identifier whereby to identify phases implicitly. unit: NX_UNITLESS phase_identifier(NX_INT): doc: | - Identifier used for phase for explicit indexing. + Identifier whereby to identify phase for each crystal explicitly. unit: NX_UNITLESS - # n_c_one, n_c_two, n_c - # properties + # dim: n_c_one, n_c_two, n_c_three # DESCRIPTOR VALUES, SUMMARY STATISTICS boundary_contact(NX_BOOLEAN): doc: | - True, if the crystal makes contact with the edge of the ROI false otherwise. - # n_c_one, n_c_two, n_c + True, for each crystal that makes contact with the edge of the ROI false for all others. + # n_c_one, n_c_two, n_c_three + # DESCRIPTOR VALUES orientation_spread(NX_NUMBER): doc: | - Average disorientation angle between individual orientation of the - crystal at probed positions (weighted by area of that position) versus - the average disorientation of the crystal. + Average disorientation angle for each crystal between individual orientations + of that crystal evaluated as a summary statistic for all probed positions vs the + average disorientation of that crystal. unit: NX_ANGLE - # n_c_one, n_c_two, n_c + # n_c_one, n_c_two, n_c_three (NXrotation_set): length(NX_NUMBER): doc: | @@ -169,95 +205,102 @@ NXmicrostructure(NXobject): unit: NX_VOLUME # m^3 interface(NXobject): doc: | - One- or two-dimensional projections, or three-dimensional representation of interfaces between crystals - as topological entities to dual_junctions. + One- or two-dimensional projections or three-dimensional representation of interfaces + between crystals as topological entities equivalent to dual_junctions. - Most relevant interfaces are grain and phase boundaries but factually interfaces can also be between - the environment and crystals exposed at the surface of the specimen. + Most important are interfaces such as grain and phase boundaries but factually + interfaces can also exist between the environment and crystals exposed at the + surface of the specimen. representation(NX_CHAR): doc: | Reference to an instance of: * :ref:`NXcg_point_set` for a one-dimensional representation as only a projection is available - * :ref:`NXcg_polyline_set` for a two-dimensional representation as only a projection is available - * :ref:`NXcg_grid` for regularly pixelated or voxelated representation using (boolean) masks + * :ref:`NXcg_polyline_set` or :ref:`NXcg_polygon_set` for a two-dimensional representation as only a projection is available + * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks - Most microscopy techniques support to generate only a two-dimensional - representation (projection) of the characterized material. number_of_interfaces(NX_UINT): doc: | - Number of interfaces. + How many interfaces are distinguished. unit: NX_UNITLESS identifier_offset(NX_INT): doc: | - Integer which specifies the first index to be used for distinguishing interfaces. + First identifier whereby to identify interfaces implicitly. unit: NX_UNITLESS identifier(NX_INT): doc: | - Integer used to distinguish features for explicit indexing. + Identifier whereby to identify each interface explicitly. unit: NX_UNITLESS # n_i_one, n_i_two, n_i # topological view, interface specification through the the pair of crystals sharing an interface - crystal(NX_INT): + crystal_identifier(NX_INT): doc: | - Set of pairs of crystal_identifier. + Set of pairs of crystal_identifier for each interface. unit: NX_UNITLESS - dim: (i, 2) # with i == n_i_one, n_i_two + dim: (i, 2) # with i == n_i_one, n_i_two, n_i_three + \@use_these(NX_CHAR): + doc: | + The specific identifier instance to resolve ambiguities. + phase_identifier(NX_INT): + doc: | + Set of pairs of phase_identifier for each interface. + unit: NX_UNITLESS + dim: (i, 2) # with i == n_i_one, n_i_two, n_i_three \@use_these(NX_CHAR): doc: | The specific identifier instance to resolve ambiguities. # topological view, interface specification through the pair of triple line projections (i.e. triple points) adjoining the interface - triple_junction(NX_INT): + triple_junction_identifier(NX_INT): doc: | - Set of pairs of triple_junction_identifier. + Set of pairs of triple_junction_identifier for each interface. unit: NX_UNITLESS - dim: (j, 2) # with j == n_i_two + dim: (j, 2) # with j == n_i_two but junctions can be points or lines! \@use_these(NX_CHAR): doc: | The specific identifier instance to resolve ambiguities. # DESCRIPTOR VALUES length(NX_NUMBER): doc: | - The length of the interface. + The length of each interface. This is not necessarily the same as the length of the individual polyline segments whereby the interface is discretized. unit: NX_LENGTH - # n_i_one, n_i_two, n_i + # dim: n_i_one, n_i_two, n_i_three area(NX_NUMBER): doc: | - Surface area + The surface area of each interface. unit: NX_AREA triple_junction(NXobject): doc: | - Projections of or representations of junctions at which interfaces between. + Projections of or representations of junctions at which three interfaces meet. - Junctions can be triple lines, triple points as their projections, junctions observed - between crystals at the specimen and its surface (including wetting phenomena) + Triple junctions can be junctions such as triple lines, triple points as their projections, + or junctions observed between crystals (at the specimen surface exposed to an environment) + (including wetting phenomena) or inside the specimen (crack, pores). representation(NX_CHAR): doc: | Reference to an instance of: * :ref:`NXcg_point_set` for a one-dimensional representation as only a projection is available * :ref:`NXcg_polyline_set` for a two-dimensional representation as only a projection is available - * :ref:`NXcg_grid` for regularly pixelated or voxelated representation using (boolean) masks + * :ref:`NXcg_polygon_set` for a two-dimensional representation in the (seldom) case of sufficient spatial resolution + * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks - # another view to describe a triple junction is via its topology/connection expressed either via - # i) triplet of interface identifier number_of_junctions(NX_UINT): doc: | Number of triple junctions. unit: NX_UNITLESS identifier_offset(NX_INT): doc: | - Integer offset where to start counting instances of the set of junctions. + First identifier to identify triple junctions implicitly. unit: NX_UNITLESS identifier(NX_INT): doc: | - Identifier used for specifiying all members of the set of junctions. + Identifier to identify each triple junction explicitly. unit: NX_UNITLESS - # n_t_one, n_t_two, n_t - # example i) triple point locations explicitly + # dim: n_t_one, n_t_two, n_t_three + # example i) triple point have locations position(NX_INT): doc: | Set of identifier for positions whereby to identify the location of each junction. @@ -265,20 +308,120 @@ NXmicrostructure(NXobject): \@use_these(NX_CHAR): doc: | The specific identifier whereby to resolve ambiguities. - # example ii) three interface projections or interface segments adjoin a triple line and point - interface(NX_INT): + crystal_identifier(NX_INT): doc: | - Set of tuples of identifier of features connected to the junction. + Set of tuples of identifier of crystals connected to the junction for each triple junction. unit: NX_UNITLESS + dim: (n_t, 3) + # example ii) three interfaces (maybe projections of them) meet at a triple junction + interface_identifier(NX_INT): + doc: | + Set of tuples of identifier of interfaces connected to the junction for each triple junction. + unit: NX_UNITLESS + dim: (n_t, 3) \@use_these(NX_CHAR): doc: | The specific identifier to instances of interface identifiers whereby to resolve ambiguities. - # example iii) e.g. three polyline segments enter a triple point - polyline(NX_INT): + # example iii) three polyline segments meet at a triple junction, polyline segments of discretized interface segments + polyline_identifier(NX_INT): doc: | - Set of tuples of identifier for representation of discretized features connected to the junction. + Set of tuples of identifier for polyline segments connected to the junction for each triple junction. unit: NX_UNITLESS \@use_these(NX_CHAR): doc: | The specific identifier to instances of NXcg primitives whereby to resolve ambiguities. + # example iv) e.g. crystals of three different phases meet at a triple junction + # DESCRIPTOR VALUES + specific_line_energy(NX_NUMBER): + doc: | + Specific line energy of each triple junction + unit: NX_ANY + dim: (n_t,) + mobility(NX_NUMBER): + doc: | + Non-intrinsic mobility of each triple junction. + unit: NX_ANY + dim: (n_t,) + length(NX_NUMBER): + doc: | + The length of each triple junction. + + This is not necessarily the same as the length of the individual + polyline segments whereby the junction is discretized. + unit: NX_LENGTH + volume(NX_NUMBER): + doc: | + The volume of the each triple junction + unit: NX_VOLUME + dim: (n_t,) + + quadruple_junction(NXobject): + doc: | + Quadruple junctions as a region where four crystals meet. + representation(NX_CHAR): + doc: | + Reference to an instance of: + + * :ref:`NXcg_point_set` + * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks + + number_of_junctions(NX_UINT): + doc: | + Number of quadruple junctions. + unit: NX_UNITLESS + identifier_offset(NX_INT): + doc: | + First identifier to identify quadruple junctions implicitly. + unit: NX_UNITLESS + identifier(NX_INT): + doc: | + Identifier to identify each quadruple junction explicitly. + unit: NX_UNITLESS + dim: (n_q,) + # example i) quadruple point locations explicitly + position(NX_INT): + doc: | + Set of identifier for positions whereby to identify the location of each junction. + unit: NX_UNITLESS + dim: (n_q,) + \@use_these(NX_CHAR): + doc: | + The specific identifier whereby to resolve ambiguities. + # example ii) four crystals meet at a quadruple junction + crystal_identifier(NX_INT): + doc: | + Set of tuples of identifier of crystals connected to the junction for each junction. + unit: NX_UNITLESS + dim: (n_q, 4) + \@use_these(NX_CHAR): + doc: | + The specific identifier to instances of interface identifiers whereby to resolve ambiguities. + # example iii) e.g. three triple lines meet at a quadruple junction + triple_junction_identifier(NX_INT): + doc: | + Set of tuples of identifier for triple junctions connected to the junction for each quadruple junction. + unit: NX_UNITLESS + dim: (n_q, 3) + \@use_these(NX_CHAR): + doc: | + The specific identifier to instances of triple junction identifiers whereby to resolve ambiguities. + # example iv) crystals of eventually four different phases meet at a quadruple junction + phase_identifier(NX_INT): + doc: | + Set of tuples of identifier for phases of crystals connected to the junction for each quadruple junction. + unit: NX_UNITLESS + dim: (n_q, 4) + \@use_these(NX_CHAR): + doc: | + The specific identifier to instances of phase identifier whereby to resolve ambiguities. # DESCRIPTOR VALUES + energy(NX_NUMBER): + doc: | + Energy of the quadruple_junction as a defect. + unit: NX_ANY + dim: (n_q,) + mobility(NX_NUMBER): + doc: | + Non-intrinsic mobility of each quadruple_junction. + unit: NX_ANY + dim: (n_q,) From e92255bdc0d35921aa516b1d661d0cd1616afeaf Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 10 Jul 2024 11:22:46 +0200 Subject: [PATCH 0790/1012] Finished NXmicrostructure --- .../NXmicrostructure.nxdl.xml | 606 ++++++++++++++---- .../NXmicrostructure_ipf.nxdl.xml | 5 - .../NXmicrostructure_odf.nxdl.xml | 89 ++- .../NXmicrostructure_pf.nxdl.xml | 6 +- .../NXmicrostructure_slip_system.nxdl.xml | 7 +- .../nyaml/NXmicrostructure.yaml | 290 +++++---- .../nyaml/NXmicrostructure_ipf.yaml | 5 +- .../nyaml/NXmicrostructure_odf.yaml | 74 ++- .../nyaml/NXmicrostructure_pf.yaml | 24 +- .../nyaml/NXmicrostructure_slip_system.yaml | 7 +- 10 files changed, 797 insertions(+), 316 deletions(-) diff --git a/contributed_definitions/NXmicrostructure.nxdl.xml b/contributed_definitions/NXmicrostructure.nxdl.xml index ef7fa83eac..cec35dd556 100644 --- a/contributed_definitions/NXmicrostructure.nxdl.xml +++ b/contributed_definitions/NXmicrostructure.nxdl.xml @@ -22,99 +22,146 @@ # For further information, see http://www.nexusformat.org --> + The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The number of linear intercepts defined. - - + - The number of crystal projections segmented by crossing (projected or real) - interfaces. + The number of one-dimensional crystal projections - The number of crossings + The number of one-dimensional interface projections - - The number of crystal projections. + The number of two-dimensional crystal projections - The number of interface projections. + The number of two-dimensional interface projections + + + + + The number of two-dimensional triple line projections - + - The number of assumed triple line projections aka triple points. + The number of two-dimensional line defect projections - - + - The number of crystals. Grain and sub-grain are synonyms for crystal. + The number of crystals (grain and sub-grain are exact synonyms for crystal). - + - The number of interfaces. Grain boundary and phase boundary are subclasses of - interface. + The number of interfaces (grain boundary and phase boundary are subclasses of + interfaces). - + - The number of triple lines. + The number of triple junctions (triple line is a exact synonym for triple + junction, triple point is projection of a triple junction). - + The number of quadruple junctions. + + + + The dimensionality of the representation that needs to match the value for + configuration/dimensionality + + - Base class to describe structural aspects and associated descriptors of (micro)structural features. + Base class to describe a microstructure, its structural aspects, associated descriptors, properties. + + Whether one uses a continuum or atomic scale description of materials, these are always a model + the true internal structure of a material. Such models are useful as they enable a coarse graining and + categorizing of properties and representational aspects from which measured or simulated descriptions + can be correlated with properties i.e. descriptor values. + + Keep in mind that most specimens are thermo-chemo-mechanically processed prior their characterization. + Therefore, the characterized microstructure may not have probe the same structure as of the untreated + sample from which the region-of-interests on the specimen were probed. + + Fields such as time and increment enable a quantification of the spatiotemporal evolution of a materials + structure by using multiple instances of NXmicrostructure. Both measurements and simulation virtually + always sample this evolution. Most microscopy techniques support to generate only a two-dimensional + representation (projection) of the characterized material, often materials are characterized only for + specific states with much history or via sampling coarsely in time relative to the timescale at which the + physical phenomena take place because of technical and practical limitations. + + The term microstructural feature covers here crystals and all sorts of crystal defects within the material. + A key challenge with the description representations and properties of microstructural features is that + features with different dimensionality exist and combinations of features of different dimensionality are + frequently expected to be documented with intuitive naming conventions using flat property lists. + For these key-value dictionaries often folksonomies are used often relying on ad hoc documentation + of such dictionaries in the literature and the metadata section of public data repositories. + + NXmicrostructure is an attempt to standardize these descriptions stronger. + + The descriptive variety is large especially for junctions. Like crystals and interfaces junctions are features in + three-dimensional Euclidean space even if they are formed maybe only through a monolayer or pearl chain of atoms. + Either way the local atomic and electronic environment is different compared to the situation of an ideal crystal + which gives rise to a plethora of useful configurations of which some cause that materials have useful properties. - The continuum or atomic scale description of materials is inherently a model of reality. Such models - are useful as they enable a coarse graining and categorization of measured or simulated materials - specifically how their structural features lead to properties i.e. descriptor values. - Mind that most specimens are thermo-chemo-mechanically treated before they are characterized. - Therefore, the characterized microstructure may not have probed the same structure as of - the untreated sample or often bulk material from which the region-of-interest or specimen was probed. + Junctions are assumed, like crystals and interfaces to represent groups of atoms that have specific descriptor values + which are different to other features. As an example a triple junction is practically a three-dimensional defect as its atoms + are arrange in three-dimensional space but the characteristics of that defect can often be reduced to a lower-dimensional + description such as a triple point or a triple line. Therefore, different representations can be used to describe the location, + shape, and structure of the defect. As different types of crystal defects can interact there is a substantial number of + in principle characterizable and representable objects. Take a triple line as an example. It is a tubular feature built from three + adjoining interfaces. However, dislocations as line defects can interact with triple lines. Therefore, one can also argue that + along a triple line there can be dislocation-line-triple-line junctions, likewise dislocations form own junctions. - A simulation or experiment can only sample the true structure of the material. - Fields time and increment enable a quantification of the temporal evolution of a material - when using multiple instances of NXmicrostructure. + It is not the aim of this base class to cover all these cases, rather this base class currently provides examples how the + typically most relevant types of features can be represented using a combination of base classes in NeXus. Currently, + these are crystals, interfaces, triple lines, quadruple junctions. - Taking inspiration from `E. E. Underwood <https://doi.org/10.1111/j.1365-2818.1972.tb03709.x>`_ - and E. E. Underwood's book on Quantitative stereology that was published in 1970. + The description attempt here took inspiration from `E. E. Underwood <https://doi.org/10.1111/j.1365-2818.1972.tb03709.x>`_ + and E. E. Underwood's book on Quantitative Stereology published 1970 to categorize features based on their dimensionality. - Identifiers can be defined either implicitly or explicitly. For implicit indexing identifiers are defined + Identifiers can be defined either implicitly or explicitly. Identifiers for implicit indexing are defined on the interval :math:`[identifier\_offset, identifier\_offset + cardinality - 1]`. - Discouraged free text field for leaving comments. + Discouraged free-text field for leaving comments. + + + + + ISO8601 with offset to local time zone included when a timestamp is required. - Measured or simulated physical time stamp for this snapshot. + Measured or simulated physical time stamp for this microstructure snapshot. Not to be confused with wall-clock timing or profiling data. @@ -125,15 +172,15 @@ the idea is we may wish to run as many grain reconstructions as we want and add - The configuration and parameterization of the reconstruction algorithm - whereby the microstructural features were identified. + Group where to store details about the configuration and parameterization of algorithms + used whereby microstructural features were identified. - Dimensionality of Euclidean space in which the analysis is conducted. + Dimensionality of Euclidean space in which the analysis is performed. This field can be used e.g. by a research data management system to identify - if the description specifies one-, two-, or three-dimensional representations. + if the description specifies one-, two-, or three-dimensional microstructural representations. @@ -143,8 +190,13 @@ the idea is we may wish to run as many grain reconstructions as we want and add - Algorithm is used to reconstruct the features. + Algorithm whereby interfaces between crystals were reconstructed. + + * Disorientation clustering groups nearby material points based on their crystallographic disorientation + * Fast multiscale clustering based on `D. Kushnir et al. <https://doi.org/10.1016/j.patcog.2006.04.007>`_ + * Markov chain clustering `F. Niessen et al. <https://doi.org/10.1107/S1600576721011560>`_ + @@ -154,151 +206,187 @@ the idea is we may wish to run as many grain reconstructions as we want and add - Threshold to define at which disorientation angle to assume - two crystalline regions have a significant orientation difference - which warrants to argue that there is an interface between the - two regions. + Threshold to define at which disorientation angle to assume two crystalline regions have a significant + orientation difference that warrants to assume that there exists an interface between the two regions. - + - - + - One- or two-dimensional projections, or three-dimensional representation of crystals. + One- or two-dimensional projections, or three-dimensional representations of crystals. - Crystals can be grains of different phases, precipitates, dispersoids, there are many - terms used in specifically the materials engineering community. + An example for a volume bounded by other crystal defects. Crystals can be grains of + different phases, precipitates, dispersoids; there are many terms used specifically in + the materials engineering community. - Typically, as observed e.g. on the surface of a sample using with optical or electron microscopy - or as simulated as a set of pixel or evolving polygons and their polyline boundaries. + Typically, crystals are measured on the surface of a sample using with optical or electron microscopy + represented or simulated as a set of pixel, voxel, or polygons and their polyline boundaries. + Using X-ray diffraction methods crystals can be observed in bulk specimens. Reference to an instance of: - * :ref:`NXcg_point_set` for a one-dimensional representation as only a projection is available - * :ref:`NXcg_polyline_set` or :ref`NXcg_polygon_set` for a two-dimensional representation as only a projection is available - * :ref:`NXcg_polyhedron_set` for a three-dimensional representation - * :ref:`NXcg_grid` for regularly pixelated or voxelated representation + * :ref:`NXcg_polyline_set` for a one-dimensional representation as only a projection is available (like in linear intercept analysis) + * :ref`NXcg_polygon_set` for a two-dimensional representation as only a projection is available (like in most experiments) + * :ref:`NXcg_polyhedron_set` or :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions + (like in computer simulations or 3D experiments) - Most microscopy techniques support to generate only a two-dimensional - representation (projection) of the characterized material. + which represent the geometrical entities of the discretization. - Number of crystals. + How many crystals are distinguished. + + Crystals are listed irrespective of the phase to which these are assigned. - How many phases are distinguished + How many phases are distinguished. + + Phases are typically distinguished based on statistical thermodynamics argument and crystal structure. - Integer offset whereby to distinguish crystals. + First identifier whereby to identify crystals implicitly. - Identifier used for crystals for explicit indexing. + Identifier whereby to identify each crystal explicitly. + + + - - Integer offset whereby the identifier of the first member - of the set differs from zero. + First identifier whereby to identify phases implicitly. - Identifier used for phase for explicit indexing. + Identifier whereby to identify phase for each crystal explicitly. + + + - + - True, if the crystal makes contact with the edge of the ROI false otherwise. + True or false value, one for each crystal, to communicate whether that feature + makes contact with the edge of the ROI. + + + - - Average disorientation angle between individual orientation of the - crystal at probed positions (weighted by area of that position) versus - the average disorientation of the crystal. + Average disorientation angle for each crystal between individual orientations + of that crystal evaluated as a summary statistic for all probed positions vs the + average disorientation of that crystal. + + + - - Length of each crystal + + + Area of each crystal. + + + Volume of each crystal + + + - One- or two-dimensional projections, or three-dimensional representation of interfaces between crystals - as topological entities to dual_junctions. + One- or two-dimensional projections or three-dimensional representation of interfaces + between crystals as topological entities equivalent to dual_junctions. - Most relevant interfaces are grain and phase boundaries but factually interfaces can also be between - the environment and crystals exposed at the surface of the specimen. + An example for a surface defect. Most important are interfaces such as grain and phase boundaries + but factually interfaces also exist between the environment and crystals exposed at the + surface of the specimen or internal surfaces like between crystals, cracks and pores. Reference to an instance of: - * :ref:`NXcg_point_set` for a one-dimensional representation as only a projection is available - * :ref:`NXcg_polyline_set` for a two-dimensional representation as only a projection is available - * :ref:`NXcg_grid` for regularly pixelated or voxelated representation using (boolean) masks + * :ref:`NXcg_point_set` for a one-dimensional representation as only a projection is available (as in linear intercept analyses) + * :ref:`NXcg_polyline_set` or :ref:`NXcg_polygon_set` for a two-dimensional representation as only a projection is available (like in most experiments) + * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks + (like in computer simulations or 3D experiments) - Most microscopy techniques support to generate only a two-dimensional - representation (projection) of the characterized material. + which represent the geometrical entities of the discretization. - Number of interfaces. + How many interfaces are distinguished. - Integer which specifies the first index to be used for distinguishing - interfaces. + First identifier whereby to identify interfaces implicitly. - Integer used to distinguish features for explicit indexing. + Identifier whereby to identify each interface explicitly. + + + + + + + + Set of pairs of crystal_identifier for each interface. + + + + + + + + The specific identifiers whereby to resolve ambiguities. + + - - + - Set of pairs of crystal_identifier. + Set of pairs of phase_identifier for each interface. @@ -306,59 +394,93 @@ topological view, interface specification through the the pair of crystals shari - The specific identifier instance to resolve ambiguities. + The specific identifiers whereby to resolve ambiguities. - + - Set of pairs of triple_junction_identifier. + Set of pairs of triple_junction_identifier for each interface. - + - The specific identifier instance to resolve ambiguities. + The specific identifiers whereby to resolve ambiguities. - + + + + True or false value, one for each crystal, to communicate whether that feature + makes contact with the edge of the ROI. + + + + + + + + Gibbs free surface energy for each interface. + + + + + + + + Non-intrinsic mobility of each interface. + + + + + - The length of the interface. + The length of each interface if only projections are available. This is not necessarily the same as the length of the individual polyline segments whereby the interface is discretized. + + + - - Surface area + The surface area of all interfaces. + + + - Projections of or representations of junctions at which interfaces between. + Projections of or representations of junctions at which three interfaces meet. - Junctions can be triple lines, triple points as their projections, junctions observed - between crystals at the specimen and its surface (including wetting phenomena) + An example for a line defect. Triple junctions are characterized as triple lines or triple points as their projections, + or junctions observed between crystals (at the specimen surface exposed to an environment) + (including wetting phenomena) or inside the specimen (crack, pores). Reference to an instance of: - * :ref:`NXcg_point_set` for a one-dimensional representation as only a projection is available + * :ref:`NXcg_point_set` for a one-dimensional representation as only a projection is available (like in most experiments) * :ref:`NXcg_polyline_set` for a two-dimensional representation as only a projection is available - * :ref:`NXcg_grid` for regularly pixelated or voxelated representation using (boolean) masks + * :ref:`NXcg_polygon_set` for a two-dimensional representation in the (seldom) case of sufficient spatial resolution + and the line in the projection plane or cases where triple junction locations are approximated e.g. using a set of triangles + * :ref:`NXcg_polyhedron_set` for a three-dimensional representation via e.g. a representation of Voronoi cells about atoms + * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks + + which represent the geometrical entities of the discretization. - Number of triple junctions. @@ -366,32 +488,214 @@ i) triplet of interface identifier--> - Integer offset where to start counting instances of the set of junctions. + First identifier to identify triple junctions implicitly. + + + + + Identifier to identify each triple junction explicitly. + + + + + + + + + Set of identifier for positions whereby to identify the location of each + junction. + + + + + + + The specific identifiers whereby to resolve ambiguities. + + + + + + Explicit positions. + + + + + + + + + Set of tuples of identifier of crystals connected to the junction for each + triple junction. + + + + + + + + + + Set of tuples of identifier of interfaces connected to the junction for each + triple junction. + + + + + + + + The specific interface identifiers whereby to resolve ambiguities. + + + + + + + Set of tuples of identifier for polyline segments connected to the junction for + each triple junction. + + + + + + + + The specific polyline identifiers whereby to resolve ambiguities. + + + + + + + True or false value, one for each crystal, to communicate whether that feature + makes contact with the edge of the ROI. + + + + + + + + Specific line energy of each triple junction + + + + + + + + Non-intrinsic mobility of each triple junction. + + + + + + + + The length of each triple junction. + + This is not necessarily the same as the length of the individual + polyline segments whereby the junction is discretized. + + + + + + + + The volume of the each triple junction + + + + + + + + + Quadruple junctions as a region where four crystals meet. + + An example for a point defect. + + + + Reference to an instance of: + + * :ref:`NXcg_point_set` + * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks + + + + + Number of quadruple junctions. + + + + + First identifier to identify quadruple junctions implicitly. - Identifier used for specifiying all members of the set of junctions. + Identifier to identify each quadruple junction explicitly. + + + - - + + Set of identifier for positions whereby to identify the location of each junction. + + + - The specific identifier whereby to resolve ambiguities. + The specific point identifier whereby to resolve ambiguities. - - + - Set of tuples of identifier of features connected to the junction. + Explicit positions. + + + + + + + + + Set of tuples of identifier of crystals connected to the junction for each + junction. + + + + + + + + The specific identifier to instances of crystal identifiers whereby to resolve + ambiguities. + + + + + + Set of tuples of identifier of interfaces connected to the junction for each + junction. + + + + + The specific identifier to instances of interface identifiers whereby to resolve @@ -399,19 +703,65 @@ example i) triple point locations explicitly--> - - + + - Set of tuples of identifier for representation of discretized features connected - to the junction. + Set of tuples of identifier for triple junctions connected to the junction for + each quadruple junction. + + + + + + + The specific identifier to instances of triple junction identifiers whereby to + resolve ambiguities. + + + + + + + Set of tuples of identifier for phases of crystals connected to the junction for + each quadruple junction. + + + + + - The specific identifier to instances of NXcg primitives whereby to resolve + The specific identifier to instances of phase identifier whereby to resolve ambiguities. + + + + True or false value, one for each crystal, to communicate whether that feature + makes contact with the edge of the ROI. + + + + + + + + Energy of the quadruple_junction as a defect. + + + + + + + + Non-intrinsic mobility of each quadruple_junction. + + + + + - diff --git a/contributed_definitions/NXmicrostructure_ipf.nxdl.xml b/contributed_definitions/NXmicrostructure_ipf.nxdl.xml index d9ba1383f6..38256637b9 100644 --- a/contributed_definitions/NXmicrostructure_ipf.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_ipf.nxdl.xml @@ -43,11 +43,6 @@ Number of RGB values along the fastest direction, always three. - - - Dimensionality of the mapping (either 2 or 3). - - Base class to store an inverse pole figure (IPF) mapping (IPF map). diff --git a/contributed_definitions/NXmicrostructure_odf.nxdl.xml b/contributed_definitions/NXmicrostructure_odf.nxdl.xml index 710a6c0ebb..b0e3311de9 100644 --- a/contributed_definitions/NXmicrostructure_odf.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_odf.nxdl.xml @@ -31,12 +31,12 @@ - Number of pixel per varphi section plot along the :math:`\Phi` slow direction. + Number of pixel per varphi section plot along the :math:`\Phi` fast direction. - Number of pixel per varphi section plot along the :math:`\varphi_2` slowest + Number of pixel per varphi section plot along the :math:`\varphi_2` slow direction. @@ -48,6 +48,10 @@ Base class to store an orientation distribution function (ODF). + + An orientation distribution function is a probability distribution that details how + much volume of material has a specific orientation. An ODF is computed from + pole figure data in a computational process called `pole figure inversion <https://doi.org/10.1107/S0021889808030112>`_. @@ -55,14 +59,14 @@ - Point group of the crystal structure (International Table of Crystallography) - of the phase for which the here documented phase-dependent ODF was computed. + Point group of the crystal structure of the phase for which the here documented phase- + dependent ODF was computed.(following the notation of the International Table of Crystallography). - Point group assumed for processing-induced *sample symmetries*. - (according to International Table of Crystallography). + Point group assumed for additionally considered sample symmetries + following the notation of the International Table of Crystallography). @@ -81,16 +85,35 @@ + - Group to store descriptors and summary statistics + Group to store descriptors and summary statistics for extrema of the ODF. + + + Minima or maxima, if extrema is set to minima values for location and volume_fraction + are sorted in increasing order. If extrema is set to maxima values for location and + volume_fraction are sorted in descreasing order. Therefore, the global extremum is + always the first entry in location and volume_fraction. + + + + + + - Number of local maxima evaluated + Number of local extrema evaluated + + + Disorientation threshold within which intensity of the ODF + is integrated for the component analysis. + + Euler angle representation :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` of the kth-most @@ -101,33 +124,53 @@ - + - Disorientation threshold within which intensity of the ODF - is integrated for the component analysis. + Integrated ODF intensity within a theta angular region of the orientation space (SO3) + about each location (obeying symmetries) as specified for each location. + + + - + + + + The ODF intensity values (weights) as sampled with a software + + + + Sampling resolution + + + - Integrated ODF intensity within a theta angular region of SO3 about - each location (obeying symmetries) as specified for each location - in the order and stored in the order of location. + Bunge-Euler (i.e. ZXZ convention) locations of each position + in orientation space for which a weight was sampled. + + + + + + + + + Weight at each sampled position following the order in euler. - + - Visualization of the ODF intensity as discretized orthogonal sections - through Euler space. + Visualization of the ODF intensity as discretized orthogonal sections through + orientation space parameterized using Bunge-Euler angles. - This is one example of typical default plots used in the texture - community in materials engineering. + This is one example of typical default plots used in the texture community in materials engineering. - Mind that the Euler space is a distorted space. Therefore, equivalent orientations - show intensity contributions in eventually multiple locations. + Mind that when parameterized using Euler angles the orientation space is a distorted space. + Therefore, equivalent orientations show intensity contributions in eventually multiple locations. Halfwidth of the kernel. diff --git a/contributed_definitions/NXmicrostructure_slip_system.nxdl.xml b/contributed_definitions/NXmicrostructure_slip_system.nxdl.xml index e037ee7484..ec660d6de6 100644 --- a/contributed_definitions/NXmicrostructure_slip_system.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_slip_system.nxdl.xml @@ -51,14 +51,14 @@ - Array of Miller indices which describe the crystallographic plane. + Array of Miller indices which describe the crystallographic planes. - + Array of Miller indices which describe the crystallographic direction. @@ -71,8 +71,7 @@ For each slip system a marker whether the specified Miller indices refer to - the specific slip system or the set of crystallographic equivalent - slip systems of the respective family of slip systems. + a specific or a crystallographic equivalent set of the slip system. diff --git a/contributed_definitions/nyaml/NXmicrostructure.yaml b/contributed_definitions/nyaml/NXmicrostructure.yaml index d3b24fd19a..0330343592 100644 --- a/contributed_definitions/nyaml/NXmicrostructure.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure.yaml @@ -1,84 +1,90 @@ category: base doc: | - Base class to describe a structural aspects, associated descriptors of a set of (micro)structural features. + Base class to describe a microstructure, its structural aspects, associated descriptors, properties. - The continuum or atomic scale description of materials is a model of reality. Such models are useful as - they enable a coarse graining and categorizing of properties and aspects of the representation of - measured or simulated materials specifically in regards to how their structural features lead to properties - i.e. descriptor values. + Whether one uses a continuum or atomic scale description of materials, these are always a model + the true internal structure of a material. Such models are useful as they enable a coarse graining and + categorizing of properties and representational aspects from which measured or simulated descriptions + can be correlated with properties i.e. descriptor values. - Keep in mind that most specimens are thermo-chemo-mechanically processed prior characterization. - Therefore, the characterized microstructure may not have probed the same structure as of the untreated - sample or the bulk material from which region-of-interests on the specimen were probed. + Keep in mind that most specimens are thermo-chemo-mechanically processed prior their characterization. + Therefore, the characterized microstructure may not have probe the same structure as of the untreated + sample from which the region-of-interests on the specimen were probed. - A simulation or experiment cannot sample the true structure of the material. Fields such as time and increment - enable a quantification of the spatiotemporal evolution of a materials structure by using multiple instances - of NXmicrostructure. + Fields such as time and increment enable a quantification of the spatiotemporal evolution of a materials + structure by using multiple instances of NXmicrostructure. Both measurements and simulation virtually + always sample this evolution. Most microscopy techniques support to generate only a two-dimensional + representation (projection) of the characterized material, often materials are characterized only for + specific states with much history or via sampling coarsely in time relative to the timescale at which the + physical phenomena take place because of technical and practical limitations. - A key challenge with the description the representation and properties of microstructural features is that + The term microstructural feature covers here crystals and all sorts of crystal defects within the material. + A key challenge with the description representations and properties of microstructural features is that features with different dimensionality exist and combinations of features of different dimensionality are - frequently expected to be documented with a low barrier and intuitive naming convention matching terms - used in the community. + frequently expected to be documented with intuitive naming conventions using flat property lists. + For these key-value dictionaries often folksonomies are used often relying on ad hoc documentation + of such dictionaries in the literature and the metadata section of public data repositories. - Most microscopy techniques support to generate only a two-dimensional representation (projection) - of the characterized material. + NXmicrostructure is an attempt to standardize these descriptions stronger. - A crystal, an interface, a junction is an object in three-dimensional Euclidean space although that crystal may - be formed just by a monolayer of atoms. Despite being a three-dimensional object, though, a crystal can often - not be observed technically three-dimensionally but using projections only. Likewise, interfaces bounding the - volume of a crystal can often be characterized only as projections of the surface patches. - The descriptive variety is large especially for junctions. Junctions are assumed, like crystals and interfaces - to represent groups of atoms that have specific descriptor values which are different to other features. - As an example a triple junction is thus a three-dimensional defect as the atoms arrange in three-dimensional - spaced but the characteristics of that defect can often be reduced to a lower-dimensional description such as - a triple point or a triple line. While this affects which base classes can be used to represent a discretization of - their structure topologically it holds for the example of a triple junction at least three lower dimensional features meet. - Most importantly these are the adjoining interfaces. However, assuming that dislocation lines in practice interact - with triple junctions not only more than three two-dimensional features meet but also one-dimensional features. + The descriptive variety is large especially for junctions. Like crystals and interfaces junctions are features in + three-dimensional Euclidean space even if they are formed maybe only through a monolayer or pearl chain of atoms. + Either way the local atomic and electronic environment is different compared to the situation of an ideal crystal + which gives rise to a plethora of useful configurations of which some cause that materials have useful properties. + + Junctions are assumed, like crystals and interfaces to represent groups of atoms that have specific descriptor values + which are different to other features. As an example a triple junction is practically a three-dimensional defect as its atoms + are arrange in three-dimensional space but the characteristics of that defect can often be reduced to a lower-dimensional + description such as a triple point or a triple line. Therefore, different representations can be used to describe the location, + shape, and structure of the defect. As different types of crystal defects can interact there is a substantial number of + in principle characterizable and representable objects. Take a triple line as an example. It is a tubular feature built from three + adjoining interfaces. However, dislocations as line defects can interact with triple lines. Therefore, one can also argue that + along a triple line there can be dislocation-line-triple-line junctions, likewise dislocations form own junctions. + + It is not the aim of this base class to cover all these cases, rather this base class currently provides examples how the + typically most relevant types of features can be represented using a combination of base classes in NeXus. Currently, + these are crystals, interfaces, triple lines, quadruple junctions. The description attempt here took inspiration from `E. E. Underwood `_ and E. E. Underwood's book on Quantitative Stereology published 1970 to categorize features based on their dimensionality. Identifiers can be defined either implicitly or explicitly. Identifiers for implicit indexing are defined on the interval :math:`[identifier\_offset, identifier\_offset + cardinality - 1]`. +# , and Volterra line defects (dislocation, disconnection, disclination). symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. - n_c: | - The number of crystals. - n_i: | - The number of interfaces. - n_t: | - The number of triple junctions. - n_q: | - The number of quadruple_junctions. # one-dimensional sections of either projections (see below) or true one-dimensional cuts across a volume of material n_c_one: | The number of one-dimensional crystal projections n_i_one: | The number of one-dimensional interface projections - # n_t_one: | - # The number of one-dimensional triple line projections + # n__one, n__one are hypothetical scenarios such as line defect hitting right into a point # two-dimensional projections of three-dimensional objects using E. E. Underwood notation # crystals/grains are projections that are delineated by projections of interface, i.e. interface lines which meet at projections of triple lines aka triple points n_c_two: | The number of two-dimensional crystal projections n_i_two: | The number of two-dimensional interface projections - n_t_two: | + n_tj_two: | The number of two-dimensional triple line projections - # n_q_two: | - # The number of two-dimensional quadruple junction projections + n_ld_two: | + The number of two-dimensional line defect projections + # n__two is the hypothetical scenario when a point defect lies right in the projection plane # three-dimensional real objects, volumetrically characterized # crystals are delineated by interfaces that are delineated by triple lines that meet at quad junctions n_c_three: | The number of crystals (grain and sub-grain are exact synonyms for crystal). n_i_three: | The number of interfaces (grain boundary and phase boundary are subclasses of interfaces). - n_t_three: | + n_tj_three: | The number of triple junctions (triple line is a exact synonym for triple junction, triple point is projection of a triple junction). - n_q_three: | + n_qj_three: | The number of quadruple junctions. +# n_ld_three: +# The number of line defects. + d: | + The dimensionality of the representation that needs to match the value for configuration/dimensionality type: group NXmicrostructure(NXobject): # as e.g. a result of one grain reconstruction with an algorithm with MTex or the grain/phase i.e. interface network reconstruction software in commercial tools @@ -86,6 +92,9 @@ NXmicrostructure(NXobject): comment(NX_CHAR): doc: | Discouraged free-text field for leaving comments. + date(NX_DATE_TIME): + doc: | + ISO8601 with offset to local time zone included when a timestamp is required. time(NX_NUMBER): doc: | Measured or simulated physical time stamp for this microstructure snapshot. @@ -97,29 +106,30 @@ NXmicrostructure(NXobject): unit: NX_UNITLESS configuration(NXprocess): doc: | - Group where to store details about the configuration and parameterization of eventually used algorithms - whereby microstructural features were identified. + Group where to store details about the configuration and parameterization of algorithms + used whereby microstructural features were identified. dimensionality(NX_POSINT): doc: | Dimensionality of Euclidean space in which the analysis is performed. This field can be used e.g. by a research data management system to identify - if the description specifies one-, two-, or three-dimensional representations. + if the description specifies one-, two-, or three-dimensional microstructural representations. unit: NX_UNITLESS enumeration: [1, 2, 3] algorithm(NX_CHAR): doc: | - Algorithm whereby microstructural features were reconstructed. + Algorithm whereby interfaces between crystals were reconstructed. * Disorientation clustering groups nearby material points based on their crystallographic disorientation * Fast multiscale clustering based on `D. Kushnir et al. `_ * Markov chain clustering `F. Niessen et al. `_ + # could also be used to specify algorithms for precipitate detection enumeration: [unknown, disorientation_clustering, fast_multiscale_clustering, markov_chain_clustering] disorientation_threshold(NX_NUMBER): doc: | Threshold to define at which disorientation angle to assume two crystalline regions have a significant - orientation difference that warrants to argue that there is an interface between the two regions. + orientation difference that warrants to assume that there exists an interface between the two regions. unit: NX_ANGLE # use controlled vocabulary terms point, line, surface, volume, use singular term when instantiating (NXcg_point_set): @@ -127,37 +137,42 @@ NXmicrostructure(NXobject): (NXcg_triangle_set): (NXcg_polyhedron_set): # constructive solid geometry to describe curved features - (NXcsg): + # (NXcsg): # (NXcontinuous_function): # examples for specific frequently discussed microstructural features crystal(NXobject): doc: | - One- or two-dimensional projections, or three-dimensional representation of crystals. + One- or two-dimensional projections, or three-dimensional representations of crystals. - Crystals can be grains of different phases, precipitates, dispersoids, there are many - terms used in specifically the materials engineering community. + An example for a volume bounded by other crystal defects. Crystals can be grains of + different phases, precipitates, dispersoids; there are many terms used specifically in + the materials engineering community. - Typically, as observed e.g. on the surface of a sample using with optical or electron microscopy - or as simulated as a set of pixel or evolving polygons and their polyline boundaries. + Typically, crystals are measured on the surface of a sample using with optical or electron microscopy + represented or simulated as a set of pixel, voxel, or polygons and their polyline boundaries. + Using X-ray diffraction methods crystals can be observed in bulk specimens. # maybe some enum what this is representation(NX_CHAR): doc: | Reference to an instance of: - * :ref:`NXcg_point_set` for a one-dimensional representation as only a projection is available - * :ref:`NXcg_polyline_set` or :ref`NXcg_polygon_set` for a two-dimensional representation as only a projection is available - * :ref:`NXcg_polyhedron_set` for a three-dimensional representation - * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions + * :ref:`NXcg_polyline_set` for a one-dimensional representation as only a projection is available (like in linear intercept analysis) + * :ref`NXcg_polygon_set` for a two-dimensional representation as only a projection is available (like in most experiments) + * :ref:`NXcg_polyhedron_set` or :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions + (like in computer simulations or 3D experiments) + + which represent the geometrical entities of the discretization. number_of_crystals(NX_UINT): doc: | How many crystals are distinguished. - Crystals are listed irrespective of the (thermodynamic) - phase to which these crystals are assigned. + Crystals are listed irrespective of the phase to which these are assigned. unit: NX_UNITLESS number_of_phases(NX_UINT): doc: | How many phases are distinguished. + + Phases are typically distinguished based on statistical thermodynamics argument and crystal structure. unit: NX_UNITLESS crystal_identifier_offset(NX_INT): doc: | @@ -167,7 +182,7 @@ NXmicrostructure(NXobject): doc: | Identifier whereby to identify each crystal explicitly. unit: NX_UNITLESS - # dim: n_c_one, n_c_two, n_c + dim: (i,) # with i = n_c_one or n_c_two or n_c_three phase_identifier_offset(NX_INT): doc: | First identifier whereby to identify phases implicitly. @@ -176,49 +191,52 @@ NXmicrostructure(NXobject): doc: | Identifier whereby to identify phase for each crystal explicitly. unit: NX_UNITLESS - # dim: n_c_one, n_c_two, n_c_three - # DESCRIPTOR VALUES, SUMMARY STATISTICS + dim: (i,) # with i = n_c_one or n_c_two or n_c_three for all use of i in of fields of group crystal + # EXAMPLES FOR DESCRIPTOR VALUES, SUMMARY STATISTICS boundary_contact(NX_BOOLEAN): doc: | - True, for each crystal that makes contact with the edge of the ROI false for all others. - # n_c_one, n_c_two, n_c_three - # DESCRIPTOR VALUES + True or false value, one for each crystal, to communicate whether that feature makes contact with the edge of the ROI. + dim: (i,) orientation_spread(NX_NUMBER): doc: | Average disorientation angle for each crystal between individual orientations of that crystal evaluated as a summary statistic for all probed positions vs the average disorientation of that crystal. unit: NX_ANGLE - # n_c_one, n_c_two, n_c_three - (NXrotation_set): + dim: (i,) length(NX_NUMBER): doc: | Length of each crystal unit: NX_LENGTH # m + dim: (i,) area(NX_NUMBER): doc: | Area of each crystal. unit: NX_AREA # m^2 + dim: (i,) volume(NX_NUMBER): doc: | Volume of each crystal unit: NX_VOLUME # m^3 + dim: (i,) interface(NXobject): doc: | One- or two-dimensional projections or three-dimensional representation of interfaces between crystals as topological entities equivalent to dual_junctions. - Most important are interfaces such as grain and phase boundaries but factually - interfaces can also exist between the environment and crystals exposed at the - surface of the specimen. + An example for a surface defect. Most important are interfaces such as grain and phase boundaries + but factually interfaces also exist between the environment and crystals exposed at the + surface of the specimen or internal surfaces like between crystals, cracks and pores. representation(NX_CHAR): doc: | Reference to an instance of: - * :ref:`NXcg_point_set` for a one-dimensional representation as only a projection is available - * :ref:`NXcg_polyline_set` or :ref:`NXcg_polygon_set` for a two-dimensional representation as only a projection is available + * :ref:`NXcg_point_set` for a one-dimensional representation as only a projection is available (as in linear intercept analyses) + * :ref:`NXcg_polyline_set` or :ref:`NXcg_polygon_set` for a two-dimensional representation as only a projection is available (like in most experiments) * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks + (like in computer simulations or 3D experiments) + which represent the geometrical entities of the discretization. number_of_interfaces(NX_UINT): doc: | How many interfaces are distinguished. @@ -231,62 +249,80 @@ NXmicrostructure(NXobject): doc: | Identifier whereby to identify each interface explicitly. unit: NX_UNITLESS - # n_i_one, n_i_two, n_i + dim: (i,) # with i == n_i_one or n_i_two or n_i_three for all fields of group interface # topological view, interface specification through the the pair of crystals sharing an interface crystal_identifier(NX_INT): doc: | Set of pairs of crystal_identifier for each interface. unit: NX_UNITLESS - dim: (i, 2) # with i == n_i_one, n_i_two, n_i_three + dim: (i, 2) \@use_these(NX_CHAR): doc: | - The specific identifier instance to resolve ambiguities. + The specific identifiers whereby to resolve ambiguities. phase_identifier(NX_INT): doc: | Set of pairs of phase_identifier for each interface. unit: NX_UNITLESS - dim: (i, 2) # with i == n_i_one, n_i_two, n_i_three + dim: (i, 2) \@use_these(NX_CHAR): doc: | - The specific identifier instance to resolve ambiguities. + The specific identifiers whereby to resolve ambiguities. # topological view, interface specification through the pair of triple line projections (i.e. triple points) adjoining the interface triple_junction_identifier(NX_INT): doc: | Set of pairs of triple_junction_identifier for each interface. unit: NX_UNITLESS - dim: (j, 2) # with j == n_i_two but junctions can be points or lines! + dim: (i, 2) # with i == n_i_two but junctions can be points or lines! \@use_these(NX_CHAR): doc: | - The specific identifier instance to resolve ambiguities. - # DESCRIPTOR VALUES + The specific identifiers whereby to resolve ambiguities. + # EXAMPLES FOR DESCRIPTOR VALUES + boundary_contact(NX_BOOLEAN): + doc: | + True or false value, one for each crystal, to communicate whether that feature makes contact with the edge of the ROI. + dim: (i,) + surface_energy(NX_NUMBER): + doc: | + Gibbs free surface energy for each interface. + unit: NX_ANY # J/m^2 + dim: (i,) + mobility(NX_NUMBER): + doc: | + Non-intrinsic mobility of each interface. + unit: NX_ANY # m^4/Js + dim: (i,) length(NX_NUMBER): doc: | - The length of each interface. + The length of each interface if only projections are available. This is not necessarily the same as the length of the individual polyline segments whereby the interface is discretized. unit: NX_LENGTH - # dim: n_i_one, n_i_two, n_i_three + dim: (i,) area(NX_NUMBER): doc: | - The surface area of each interface. + The surface area of all interfaces. unit: NX_AREA + dim: (i,) triple_junction(NXobject): doc: | Projections of or representations of junctions at which three interfaces meet. - Triple junctions can be junctions such as triple lines, triple points as their projections, + An example for a line defect. Triple junctions are characterized as triple lines or triple points as their projections, or junctions observed between crystals (at the specimen surface exposed to an environment) (including wetting phenomena) or inside the specimen (crack, pores). representation(NX_CHAR): doc: | Reference to an instance of: - * :ref:`NXcg_point_set` for a one-dimensional representation as only a projection is available + * :ref:`NXcg_point_set` for a one-dimensional representation as only a projection is available (like in most experiments) * :ref:`NXcg_polyline_set` for a two-dimensional representation as only a projection is available * :ref:`NXcg_polygon_set` for a two-dimensional representation in the (seldom) case of sufficient spatial resolution + and the line in the projection plane or cases where triple junction locations are approximated e.g. using a set of triangles + * :ref:`NXcg_polyhedron_set` for a three-dimensional representation via e.g. a representation of Voronoi cells about atoms * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks + which represent the geometrical entities of the discretization. number_of_junctions(NX_UINT): doc: | Number of triple junctions. @@ -299,49 +335,61 @@ NXmicrostructure(NXobject): doc: | Identifier to identify each triple junction explicitly. unit: NX_UNITLESS - # dim: n_t_one, n_t_two, n_t_three - # example i) triple point have locations - position(NX_INT): + dim: (i,) # with i == n_tj_one, n_tj_two, n_tj_three for all fields in group triple_junction + # various strategies are used to talk about aspects of triple junctions, some examples follow + # example i) triple points as projections of triple lines have locations + location(NX_INT): doc: | Set of identifier for positions whereby to identify the location of each junction. unit: NX_UNITLESS + dim: (i,) \@use_these(NX_CHAR): doc: | - The specific identifier whereby to resolve ambiguities. + The specific identifiers whereby to resolve ambiguities. + position(NX_INT): + doc: | + Explicit positions. + unit: NX_LENGTH + dim: (i, d) crystal_identifier(NX_INT): doc: | Set of tuples of identifier of crystals connected to the junction for each triple junction. unit: NX_UNITLESS - dim: (n_t, 3) + dim: (i, 3) # example ii) three interfaces (maybe projections of them) meet at a triple junction interface_identifier(NX_INT): doc: | Set of tuples of identifier of interfaces connected to the junction for each triple junction. unit: NX_UNITLESS - dim: (n_t, 3) + dim: (i, 3) \@use_these(NX_CHAR): doc: | - The specific identifier to instances of interface identifiers whereby to resolve ambiguities. + The specific interface identifiers whereby to resolve ambiguities. # example iii) three polyline segments meet at a triple junction, polyline segments of discretized interface segments polyline_identifier(NX_INT): doc: | Set of tuples of identifier for polyline segments connected to the junction for each triple junction. unit: NX_UNITLESS + dim: (i, 3) \@use_these(NX_CHAR): doc: | - The specific identifier to instances of NXcg primitives whereby to resolve ambiguities. + The specific polyline identifiers whereby to resolve ambiguities. # example iv) e.g. crystals of three different phases meet at a triple junction - # DESCRIPTOR VALUES - specific_line_energy(NX_NUMBER): + # EXAMPLES FOR DESCRIPTOR VALUES + boundary_contact(NX_BOOLEAN): + doc: | + True or false value, one for each crystal, to communicate whether that feature makes contact with the edge of the ROI. + dim: (i,) + line_energy(NX_NUMBER): doc: | Specific line energy of each triple junction unit: NX_ANY - dim: (n_t,) + dim: (i,) mobility(NX_NUMBER): doc: | Non-intrinsic mobility of each triple junction. unit: NX_ANY - dim: (n_t,) + dim: (i,) length(NX_NUMBER): doc: | The length of each triple junction. @@ -349,15 +397,17 @@ NXmicrostructure(NXobject): This is not necessarily the same as the length of the individual polyline segments whereby the junction is discretized. unit: NX_LENGTH + dim: (i,) volume(NX_NUMBER): doc: | The volume of the each triple junction unit: NX_VOLUME - dim: (n_t,) - + dim: (i,) quadruple_junction(NXobject): doc: | - Quadruple junctions as a region where four crystals meet. + Quadruple junctions as a region where four crystals meet. + + An example for a point defect. representation(NX_CHAR): doc: | Reference to an instance of: @@ -377,22 +427,36 @@ NXmicrostructure(NXobject): doc: | Identifier to identify each quadruple junction explicitly. unit: NX_UNITLESS - dim: (n_q,) + dim: (i,) # with i == n_qj_three or n_qj_two + # different scenarios can be envised how quadruple_junctions are discussed # example i) quadruple point locations explicitly - position(NX_INT): + location(NX_INT): doc: | Set of identifier for positions whereby to identify the location of each junction. unit: NX_UNITLESS - dim: (n_q,) + dim: (i,) \@use_these(NX_CHAR): doc: | - The specific identifier whereby to resolve ambiguities. + The specific point identifier whereby to resolve ambiguities. + position(NX_INT): + doc: | + Explicit positions. + unit: NX_LENGTH + dim: (i, 3) # example ii) four crystals meet at a quadruple junction crystal_identifier(NX_INT): doc: | Set of tuples of identifier of crystals connected to the junction for each junction. unit: NX_UNITLESS - dim: (n_q, 4) + dim: (i, 4) + \@use_these(NX_CHAR): + doc: | + The specific identifier to instances of crystal identifiers whereby to resolve ambiguities. + interface_identifier(NX_INT): + doc: | + Set of tuples of identifier of interfaces connected to the junction for each junction. + unit: NX_UNITLESS + dim: (i, 4) \@use_these(NX_CHAR): doc: | The specific identifier to instances of interface identifiers whereby to resolve ambiguities. @@ -401,7 +465,7 @@ NXmicrostructure(NXobject): doc: | Set of tuples of identifier for triple junctions connected to the junction for each quadruple junction. unit: NX_UNITLESS - dim: (n_q, 3) + dim: (i, 3) \@use_these(NX_CHAR): doc: | The specific identifier to instances of triple junction identifiers whereby to resolve ambiguities. @@ -410,18 +474,22 @@ NXmicrostructure(NXobject): doc: | Set of tuples of identifier for phases of crystals connected to the junction for each quadruple junction. unit: NX_UNITLESS - dim: (n_q, 4) + dim: (i, 4) \@use_these(NX_CHAR): doc: | The specific identifier to instances of phase identifier whereby to resolve ambiguities. - # DESCRIPTOR VALUES + # EXAMPLES FOR DESCRIPTOR VALUES + boundary_contact(NX_BOOLEAN): + doc: | + True or false value, one for each crystal, to communicate whether that feature makes contact with the edge of the ROI. + dim: (i,) energy(NX_NUMBER): doc: | Energy of the quadruple_junction as a defect. unit: NX_ANY - dim: (n_q,) + dim: (i,) mobility(NX_NUMBER): doc: | Non-intrinsic mobility of each quadruple_junction. unit: NX_ANY - dim: (n_q,) + dim: (i,) diff --git a/contributed_definitions/nyaml/NXmicrostructure_ipf.yaml b/contributed_definitions/nyaml/NXmicrostructure_ipf.yaml index 40a508837f..105ca5f690 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_ipf.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_ipf.yaml @@ -10,13 +10,10 @@ symbols: Number of pixel along the x fast direction. n_rgb: | Number of RGB values along the fastest direction, always three. - d: | - Dimensionality of the mapping (either 2 or 3). type: group NXmicrostructure_ipf(NXprocess): depends_on(NX_CHAR): - doc: - - | + doc: | Reference to an :ref:`NXcoordinate_system` in which the projection_direction is defined. If the field depends_on is not provided but parents of the instance of this base class or its diff --git a/contributed_definitions/nyaml/NXmicrostructure_odf.yaml b/contributed_definitions/nyaml/NXmicrostructure_odf.yaml index 79f20c5c00..596fbb994b 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_odf.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_odf.yaml @@ -1,13 +1,17 @@ category: base doc: | Base class to store an orientation distribution function (ODF). + + An orientation distribution function is a probability distribution that details how + much volume of material has a specific orientation. An ODF is computed from + pole figure data in a computational process called `pole figure inversion `_. symbols: n_varphi_one: | Number of pixel per varphi section plot along the :math:`\varphi_1` fastest direction. n_capital_phi: | - Number of pixel per varphi section plot along the :math:`\Phi` slow direction. + Number of pixel per varphi section plot along the :math:`\Phi` fast direction. n_varphi_two: | - Number of pixel per varphi section plot along the :math:`\varphi_2` slowest direction. + Number of pixel per varphi section plot along the :math:`\varphi_2` slow direction. k: | Number of local maxima evaluated in the component analysis. type: group @@ -17,12 +21,12 @@ NXmicrostructure_odf(NXprocess): Details about the algorithm used for computing the ODF. crystal_symmetry_point_group(NX_CHAR): doc: | - Point group of the crystal structure (International Table of Crystallography) - of the phase for which the here documented phase-dependent ODF was computed. + Point group of the crystal structure of the phase for which the here documented phase- + dependent ODF was computed.(following the notation of the International Table of Crystallography). specimen_symmetry_point_group(NX_CHAR): doc: | - Point group assumed for processing-induced *sample symmetries*. - (according to International Table of Crystallography). + Point group assumed for additionally considered sample symmetries + following the notation of the International Table of Crystallography). kernel_halfwidth(NX_NUMBER): doc: | Halfwidth of the kernel. @@ -34,42 +38,66 @@ NXmicrostructure_odf(NXprocess): doc: | Resolution of the kernel. unit: NX_ANGLE + # specific values and typical results kth_extrema(NXobject): doc: | - Group to store descriptors and summary statistics + Group to store descriptors and summary statistics for extrema of the ODF. + extrema(NX_CHAR): + doc: | + Minima or maxima, if extrema is set to minima values for location and volume_fraction + are sorted in increasing order. If extrema is set to maxima values for location and + volume_fraction are sorted in descreasing order. Therefore, the global extremum is + always the first entry in location and volume_fraction. + enumeration: [minima, maxima] kth(NX_UINT): doc: | - Number of local maxima evaluated + Number of local extrema evaluated unit: NX_UNITLESS # value of kth should be k + theta(NX_NUMBER): + doc: | + Disorientation threshold within which intensity of the ODF + is integrated for the component analysis. + unit: NX_ANGLE location(NX_NUMBER): doc: | Euler angle representation :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` of the kth-most maxima in decreasing order of the intensity maximum. unit: NX_ANGLE dim: (k, 3) - theta(NX_NUMBER): - doc: | - Disorientation threshold within which intensity of the ODF - is integrated for the component analysis. - unit: NX_ANGLE volume_fraction(NX_NUMBER): doc: | - Integrated ODF intensity within a theta angular region of SO3 about - each location (obeying symmetries) as specified for each location - in the order and stored in the order of location. + Integrated ODF intensity within a theta angular region of the orientation space (SO3) + about each location (obeying symmetries) as specified for each location. unit: NX_ANY dim: (k,) + sampling(NXobject): + doc: | + The ODF intensity values (weights) as sampled with a software + resolution(NX_NUMBER): + doc: | + Sampling resolution + unit: NX_ANGLE + euler(NX_NUMBER): + doc: | + Bunge-Euler (i.e. ZXZ convention) locations of each position + in orientation space for which a weight was sampled. + unit: NX_ANGLE + dim: (i, 3) + weight(NX_NUMBER): + doc: | + Weight at each sampled position following the order in euler. + unit: NX_DIMENSIONLESS # intensity of ODF at euler / intensity of random ODF at euler + dim: (i,) phi_two_plot(NXdata): doc: | - Visualization of the ODF intensity as discretized orthogonal sections - through Euler space. + Visualization of the ODF intensity as discretized orthogonal sections through + orientation space parameterized using Bunge-Euler angles. - This is one example of typical default plots used in the texture - community in materials engineering. + This is one example of typical default plots used in the texture community in materials engineering. - Mind that the Euler space is a distorted space. Therefore, equivalent orientations - show intensity contributions in eventually multiple locations. + Mind that when parameterized using Euler angles the orientation space is a distorted space. + Therefore, equivalent orientations show intensity contributions in eventually multiple locations. # \@signal: intensity # \@axes: [varphi_two, capital_phi, varphi_one] # \@varphi_one_indices: 0 @@ -77,7 +105,7 @@ NXmicrostructure_odf(NXprocess): # \@varphi_two_indices: 2 intensity(NX_NUMBER): doc: | - ODF intensity at probed locations relative to the intensity of the null model of a completely random texture. + ODF intensity at probed locations relative to the intensity of the null model of a random texture. unit: NX_DIMENSIONLESS dim: (n_varphi_two, n_capital_phi, n_varphi_one) varphi_one(NX_NUMBER): diff --git a/contributed_definitions/nyaml/NXmicrostructure_pf.yaml b/contributed_definitions/nyaml/NXmicrostructure_pf.yaml index 500c249ed5..cd746406ee 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_pf.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_pf.yaml @@ -1,6 +1,9 @@ category: base doc: | Base class to store a pole figure (PF) computation. + + A pole figure is the X-ray diffraction intensity for specific integrated + peaks for a hemispherical illumination of a real or virtual specimen. symbols: n_y: | Number of pixel per pole figure in the slow direction. @@ -9,30 +12,25 @@ symbols: type: group NXmicrostructure_pf(NXprocess): configuration(NXobject): - doc: - - | + doc: | Details about the algorithm that was used to compute the pole figure. crystal_symmetry_point_group(NX_CHAR): - doc: - - | - Point group of the crystal structure of the phase for which pole figure + doc: | + Point group of the crystal structure of the phase for which the pole figure was computed (according to International Table of Crystallography). specimen_symmetry_point_group(NX_CHAR): - doc: - - | + doc: | Point group of assumed sample symmetries (according to International Table of Crystallography). + # integration windows halfwidth(NX_NUMBER): - doc: - - | + doc: | Halfwidth of the kernel. unit: NX_ANGLE miller_indices(NX_CHAR): - doc: - - | + doc: | Miller indices (:math:`(hkl)[uvw]`) to specify the pole figure. resolution(NX_NUMBER): - doc: - - | + doc: | Resolution of the kernel. unit: NX_ANGLE pf(NXdata): diff --git a/contributed_definitions/nyaml/NXmicrostructure_slip_system.yaml b/contributed_definitions/nyaml/NXmicrostructure_slip_system.yaml index 36d437edac..f72d937f60 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_slip_system.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_slip_system.yaml @@ -14,10 +14,10 @@ NXmicrostructure_slip_system(NXobject): enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, trigonal, hexagonal, cubic] miller_plane(NX_NUMBER): doc: | - Array of Miller indices which describe the crystallographic plane. + Array of Miller indices which describe the crystallographic planes. unit: NX_UNITLESS dim: (n, i) - # fastest changing dimension needs to be i because for instance for hexagonal hkil is needed + # fastest changing dimension needs to be i and not 3 because for instance for hexagonal hkil notation is used miller_direction(NX_NUMBER): doc: | Array of Miller indices which describe the crystallographic direction. @@ -27,6 +27,5 @@ NXmicrostructure_slip_system(NXobject): unit: NX_UNITLESS doc: | For each slip system a marker whether the specified Miller indices refer to - the specific slip system or the set of crystallographic equivalent - slip systems of the respective family of slip systems. + a specific or a crystallographic equivalent set of the slip system. dim: (n,) From 78ddc2a972cc372dd7aca1a57243e194fef4eeb9 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 10 Jul 2024 15:37:50 +0200 Subject: [PATCH 0791/1012] Fix docs CI to only keep orphan branch --- .github/workflows/fairmat-build-pages.yaml | 31 ++++++++++++---------- 1 file changed, 17 insertions(+), 14 deletions(-) diff --git a/.github/workflows/fairmat-build-pages.yaml b/.github/workflows/fairmat-build-pages.yaml index 3335017b1c..fae76f0cdd 100644 --- a/.github/workflows/fairmat-build-pages.yaml +++ b/.github/workflows/fairmat-build-pages.yaml @@ -3,8 +3,8 @@ name: GH pages fairmat proposal on: push: branches: [fairmat] - pull_request: - branches: [fairmat] + # pull_request: + # branches: [fairmat] jobs: pages: @@ -31,19 +31,22 @@ jobs: run: make html - name: Deploy if: steps.branch-name.outputs.is_default == 'true' - uses: JamesIves/github-pages-deploy-action@v4 + uses: peaceiris/actions-gh-pages@v3 with: - token: ${{ secrets.GITHUB_TOKEN }} - folder: build/manual/build/html - branch: fairmat-docs - target-folder: docs - clean: false + github_token: ${{ secrets.GITHUB_TOKEN }} + publish_dir: build/manual/build/html + publish_branch: fairmat-docs + destination_dir: docs + force_orphan: true - name: Deploy PR if: steps.branch-name.outputs.is_default == 'false' - uses: JamesIves/github-pages-deploy-action@v4 + uses: peaceiris/actions-gh-pages@v3 with: - token: ${{ secrets.GITHUB_TOKEN }} - folder: build/manual/build/html - branch: fairmat-docs - target-folder: docs/${{ steps.branch-name.outputs.current_branch }} - clean: false \ No newline at end of file + github_token: ${{ secrets.GITHUB_TOKEN }} + publish_dir: build/manual/build/html + publish_branch: fairmat-docs + destination_dir: docs/${{ steps.branch-name.outputs.current_branch }} + force_orphan: true + + + \ No newline at end of file From d1442c39ec389f7c7fb3654a7039e63182982134 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 10 Jul 2024 16:06:24 +0200 Subject: [PATCH 0792/1012] Finalized data model for NXmicrostructure_imm --- contributed_definitions/NXcg_grid.nxdl.xml | 2 +- .../NXmicrostructure.nxdl.xml | 3 +- .../NXmicrostructure_imm_config.nxdl.xml | 172 +++++++++++++----- .../NXmicrostructure_imm_results.nxdl.xml | 131 ++++++++++++- .../NXrotation_set.nxdl.xml | 2 +- contributed_definitions/nyaml/NXcg_grid.yaml | 6 +- .../nyaml/NXmicrostructure.yaml | 3 +- .../nyaml/NXmicrostructure_imm_config.yaml | 116 +++++++++--- .../nyaml/NXmicrostructure_imm_results.yaml | 89 ++++++++- .../icme-structure.rst | 13 +- 10 files changed, 444 insertions(+), 93 deletions(-) diff --git a/contributed_definitions/NXcg_grid.nxdl.xml b/contributed_definitions/NXcg_grid.nxdl.xml index 4d5aced5fe..c83d817d83 100644 --- a/contributed_definitions/NXcg_grid.nxdl.xml +++ b/contributed_definitions/NXcg_grid.nxdl.xml @@ -77,7 +77,7 @@ - + Number of unit cells along each of the d unit vectors. diff --git a/contributed_definitions/NXmicrostructure.nxdl.xml b/contributed_definitions/NXmicrostructure.nxdl.xml index cec35dd556..cceb923138 100644 --- a/contributed_definitions/NXmicrostructure.nxdl.xml +++ b/contributed_definitions/NXmicrostructure.nxdl.xml @@ -211,7 +211,8 @@ the idea is we may wish to run as many grain reconstructions as we want and add - + + diff --git a/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml b/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml index 5e9db5c1c1..58d95f5abe 100644 --- a/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml @@ -21,15 +21,36 @@ # # For further information, see http://www.nexusformat.org --> - - + + + + + How many texture components are distinguished, minimum is 1. + + + + + How many special texture components are distinguished if any. + + + + + Number of discrete orientations that are distributed across the grains. + + + - Application definition for the IMM structure generator. + Application definition for the configuration of the legacy (micro)structure generator + developed by the Institut für Metallkunde und Metallphysik at RWTH Aachen University. + + * `N. Leuning et al. <https://doi.org/10.3390/ma14216588>`_ + * `C. Mießen <https://doi.org/10.18154/RWTH-2017-10148>`_ + * `M. Kühbach <https://doi.org/10.18154/RWTH-2018-00294>`_ + * `M. Kühbach et al. <https://github.com/mkuehbach/GraGLeS>`_ - The tool can be used to instantiate specific configurations for computer simulations modelling the evolution of the a microstructure upon annealing. The structure is assumed - to be a homophase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. Grains can be modelled as elongated objects to mimic fundamental geometrical constraints of the interface network in deformed material. + The tool can be used to instantiate specific configurations for two- and three-dimensional discretized microstructures. + Specifically, single-phase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. + Grains are modelled as elongated crystals to mimic fundamental geometrical constraints of the interface network in deformed material. @@ -37,7 +58,13 @@ type: group--> - + + + The computational domain will be synthesized either as a square (for dimensionality = 2) + or a cube (for dimensionality = 3) with axis-aligned cuboidal parent grains. The domain is + discretized into material points using either square pixel or cubic voxel as the tessellating + unit cells. + Two-dimensional or three-dimensional simulation. @@ -47,7 +74,12 @@ type: group--> - + + + Target value for the number of material points per equivalent + discrete diameter of the arithmetic average sub-grain. + + Assumed space group of the material. @@ -60,23 +92,26 @@ type: group--> - + + + Target value for the number of grains. The actual domain size and grid will be configured + based on the choices for discretization, number_of_grains, and shape of these grains. + + + - Domain will be square or cubic respectively ROI (axis-aligned) regularly tessellated with either squares or cubes about so-called material points. - - Actual domain size and grid depends on discretization, number_of_grains, and shape of these grains + Target value for the average number of sub-grains per grain. - - If available used to define the sequence of relative extent of grains along the y (first value) and z-axis (second value) assuming the relative shape along the x-axis is 1. - - If absent, structure will be globulitic i.e. the extent of the grains on average is 1 along each axis. + If available used to define the sequence of relative extent of grains along the y (first value) + and z-axis (second value) assuming the relative shape along the x-axis is 1. If not provided, + the relative extent of the grains will be 1 one average along each axis (globulitic structure). @@ -89,25 +124,65 @@ type: group--> remove 0 all the time 0.00 remove 0 all the time 0.00 --> - + - The model according to which dislocation density is distributed across the - grains and sub-grains. + In texture research a component analyses set on the idea that properties + of grains different based on orientation with certain regions in orientation + space show similar trends like a different average dislocation density + or orientation_spread. - + - Distribution type according to which values are distributed. + The first entry is always the null model None which measn that an orientation + is not categorized as a special component. Examples for special components are + Dillamore, Copper, Cube, Y, P and Q. - - - + + + + + + + Bunge-Euler angle parameterization of the texture components + location in orientation space for which specifically different settings + should be configured. + + + + + - + - The minimum and the maximum value to distribute across sub-grains. + Disorientation angle below which an orientation is categorized as one of the + components. - + + + + + + + Dislocations are modelled as Rayleigh-distributed mean-field density that + can differ between but is constant within grains and sub-grains. + + + + The minimum and the maximum dislocation density to distribute across grains. + + + + + + + + + The minimum and the maximum dislocation density to distribute across sub-grains. + + + + @@ -116,35 +191,50 @@ remove 0 all the time 0.00 --> - + The variance of the dislocation density distribution across the grains. + + + - + The variance of the dislocation density distribution across the sub-grains. + + + - + Orientations of the grains are sampled from a set of Bunge-Euler angle triplets. - Orientations of the sub-grains are sampled by scattering the orientation of the (parent) grain. + Orientations of the sub-grains are sampled by scattering the orientation + of the (parent) grain and with optional Rayleigh-distributed scatter. - - - - - - + + + Bunge-Euler angle parameterization of the texture components + location in orientation space for which specifically different settings + should be configured. + + + + + + - + The variance of the disorientation of the sub-grain to their parent grain. + + + - - - + + + + Number of material points along the edge of the square- or cube-shaped domain. + + + - Application definition for documenting results obtained with the IMM structure - generator. + Application definition for the results of the legacy (micro)structure generator developed + by the Institut für Metallkunde und Metallphysik at RWTH Aachen University. + + * `N. Leuning et al. <https://doi.org/10.3390/ma14216588>`_ + * `C. Mießen <https://doi.org/10.18154/RWTH-2017-10148>`_ + * `M. Kühbach <https://doi.org/10.18154/RWTH-2018-00294>`_ + * `M. Kühbach et al. <https://github.com/mkuehbach/GraGLeS>`_ + + The tool can be used to instantiate specific configurations for two- and three-dimensional discretized microstructures. + Specifically, single-phase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. + Grains are modelled as elongated crystals to mimic fundamental geometrical constraints of the interface network in deformed material. @@ -34,7 +48,112 @@ symbols:--> + + + + + + + Default plot showing the grid. + + + + + + + + Crystal identifier that was assigned to each material point. + + + + + + Material point barycentre coordinate along z direction. + + + + + + + Coordinate along z direction. + + + + + + Material point barycentre coordinate along y direction. + + + + + + + Coordinate along y direction. + + + + + + Material point barycentre coordinate along x direction. + + + + + + + Coordinate along x direction. + + + + + + + + + + + + + + + + + + + + + + + + + + True if the crystal is considered a sub-grain. + False if the crystal is considered a grain. + + + + + + + + Bunge-Euler angle orientation of each crystal. + + + + + + + + + Mean-field dislocation density as a measure of the stored elastic energy + content that is stored in the dislocation network of this grain and related + defects within each crystal. + + + + + + + - diff --git a/contributed_definitions/NXrotation_set.nxdl.xml b/contributed_definitions/NXrotation_set.nxdl.xml index dd55e97e76..0c2ec652a9 100644 --- a/contributed_definitions/NXrotation_set.nxdl.xml +++ b/contributed_definitions/NXrotation_set.nxdl.xml @@ -26,7 +26,7 @@ how each object is oriented/rotated with respect to a reference coordinate system. we should offer here support for d==2, d==3 several well accepted parameterizations for rotations exists in Materials Science -thus not using NXtransformations, different Materials Science groups follow +thus not using NXtransformations, differentr Materials Science groups follow different conventions not every reporting of rotations is consistent and correct having a base class like the one proposed here offers a suggestion to start discussing at all about how to convert between groups who report using diff --git a/contributed_definitions/nyaml/NXcg_grid.yaml b/contributed_definitions/nyaml/NXcg_grid.yaml index de8cf9c8f3..c8714998b2 100644 --- a/contributed_definitions/nyaml/NXcg_grid.yaml +++ b/contributed_definitions/nyaml/NXcg_grid.yaml @@ -34,7 +34,7 @@ NXcg_grid(NXcg_primitive_set): The unit cell dimensions using crystallographic notation. unit: NX_LENGTH dim: (d,) - extent(NX_INT): + extent(NX_UINT): doc: | Number of unit cells along each of the d unit vectors. @@ -44,7 +44,7 @@ NXcg_grid(NXcg_primitive_set): outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. unit: NX_UNITLESS - dim: (d,) + dim: (d,) # number_of_cells(NX_UINT): maybe already too trivial quantities # should constraints on the grid be place here or not position(NX_NUMBER): @@ -56,7 +56,7 @@ NXcg_grid(NXcg_primitive_set): doc: | Coordinate of each cell with respect to the discrete grid. unit: NX_DIMENSIONLESS - dim: (c, d) + dim: (c, d) # this should be a ROI bounding_box(NXcg_polyhedron_set): doc: | diff --git a/contributed_definitions/nyaml/NXmicrostructure.yaml b/contributed_definitions/nyaml/NXmicrostructure.yaml index 0330343592..969c471cf7 100644 --- a/contributed_definitions/nyaml/NXmicrostructure.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure.yaml @@ -131,7 +131,8 @@ NXmicrostructure(NXobject): Threshold to define at which disorientation angle to assume two crystalline regions have a significant orientation difference that warrants to assume that there exists an interface between the two regions. unit: NX_ANGLE - # use controlled vocabulary terms point, line, surface, volume, use singular term when instantiating + # use controlled vocabulary terms grid, point, line, surface, volume, use singular term when instantiating + (NXcg_grid): (NXcg_point_set): (NXcg_polyline_set): (NXcg_triangle_set): diff --git a/contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml index ecf5117a30..f515080354 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml @@ -1,21 +1,43 @@ category: application doc: | - Application definition for the IMM structure generator. + Application definition for the configuration of the legacy (micro)structure generator + developed by the Institut für Metallkunde und Metallphysik at RWTH Aachen University. - The tool can be used to instantiate specific configurations for computer simulations modelling the evolution of the a microstructure upon annealing. The structure is assumed - to be a homophase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. Grains can be modelled as elongated objects to mimic fundamental geometrical constraints of the interface network in deformed material. -# symbols: -# type: group + * `N. Leuning et al. `_ + * `C. Mießen `_ + * `M. Kühbach `_ + * `M. Kühbach et al. `_ + + The tool can be used to instantiate specific configurations for two- and three-dimensional discretized microstructures. + Specifically, single-phase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. + Grains are modelled as elongated crystals to mimic fundamental geometrical constraints of the interface network in deformed material. +symbols: + n_categories: | + How many texture components are distinguished, minimum is 1. + n_components: | + How many special texture components are distinguished if any. + n_ori: | + Number of discrete orientations that are distributed across the grains. +type: group NXmicrostructure_imm_config(NXobject): (NXentry): definition(NX_CHAR): enumeration: [NXmicrostructure_imm_config] - roi(NXroi): + roi(NXobject): + doc: | + The computational domain will be synthesized either as a square (for dimensionality = 2) + or a cube (for dimensionality = 3) with axis-aligned cuboidal parent grains. The domain is + discretized into material points using either square pixel or cubic voxel as the tessellating + unit cells. dimensionality(NX_UINT): doc: | Two-dimensional or three-dimensional simulation. enumeration: [2, 3] discretization(NX_UINT): # 15# simulation ID via command line 10 + doc: | + Target value for the number of material points per equivalent + discrete diameter of the arithmetic average sub-grain. + unit: NX_UNITLESS crystal_symmetry(NX_CHAR): doc: | Assumed space group of the material. @@ -24,10 +46,13 @@ NXmicrostructure_imm_config(NXobject): # 1 # 0, E_HCP, 1 E_FCC, 2 E_BCC, 3 E_DEFAULT_STRUCTURE number_of_grains(NX_UINT): # 8 doc: | - Domain will be square or cubic respectively ROI (axis-aligned) regularly tessellated with either squares or cubes about so-called material points. - - Actual domain size and grid depends on discretization, number_of_grains, and shape of these grains + Target value for the number of grains. The actual domain size and grid will be configured + based on the choices for discretization, number_of_grains, and shape of these grains. + unit: NX_UNITLESS number_of_subgrains(NX_UINT): # 1000 + doc: | + Target value for the average number of sub-grains per grain. + unit: NX_UNITLESS # 0 is there another one if not remove # 1 always one # @@ -35,9 +60,9 @@ NXmicrostructure_imm_config(NXobject): grain_shape(NX_FLOAT): exists: optional doc: | - If available used to define the sequence of relative extent of grains along the y (first value) and z-axis (second value) assuming the relative shape along the x-axis is 1. - - If absent, structure will be globulitic i.e. the extent of the grains on average is 1 along each axis. + If available used to define the sequence of relative extent of grains along the y (first value) + and z-axis (second value) assuming the relative shape along the x-axis is 1. If not provided, + the relative extent of the grains will be 1 one average along each axis (globulitic structure). unit: NX_DIMENSIONLESS dim: (2,) # - dislocation_density_distribution_model(NXprocess): + component_analysis(NXobject): + exists: optional doc: | - The model according to which dislocation density is distributed across the grains and sub-grains. - type(NX_CHAR): + In texture research component analyses set on the idea that properties + of grains different based on orientation with certain regions in orientation + space show similar trends like a different average dislocation density + or orientation_spread. + component_name(NX_CHAR): doc: | - Distribution type according to which values are distributed. - enumeration: [rayleigh] - min_max(NX_FLOAT): + The first entry is always the null model None which measn that an orientation + is not categorized as a special component. Examples for special components are + Dillamore, Copper, Cube, Y, P and Q. + dim: (n_categories,) + bunge_euler(NX_FLOAT): doc: | - The minimum and the maximum value to distribute across sub-grains. + Bunge-Euler angle parameterization of the texture components + location in orientation space for which specifically different settings + should be configured. + unit: NX_ANGLE + dim: (n_components, 3) + theta(NX_FLOAT): + doc: | + Disorientation angle below which an orientation is categorized as one of the components. + unit: NX_ANGLE + dim: (n_components,) + dislocation_distribution(NXobject): + doc: | + Dislocations are modelled as Rayleigh-distributed mean-field density that + can differ between but is constant within grains and sub-grains. + min_max_grain(NX_FLOAT): + doc: | + The minimum and the maximum dislocation density to distribute across grains. + unit: NX_ANY # 1/m^2 + dim: (n_categories, 2) + min_max_subgrain(NX_FLOAT): + doc: | + The minimum and the maximum dislocation density to distribute across sub-grains. unit: NX_ANY # 1/m^2 - dim: (2,) + dim: (n_categories, 2) # 10.8e14# 10.8e144.0e14 # doc: | + The variance of the dislocation density distribution across the grains. unit: NX_ANY # 1/m^2 + dim: (n_categories,) variance_subgrain(NX_FLOAT): # 0.8e14 doc: | + The variance of the dislocation density distribution across the sub-grains. unit: NX_ANY # 1/m^2 - orientation_distribution_model(NXprocess): # CR70FeSi.Rogge.MTEX.vpsc.odf.5000.txt + dim: (n_categories,) + orientation_distribution(NXprocess): # CR70FeSi.Rogge.MTEX.vpsc.odf.5000.txt doc: | Orientations of the grains are sampled from a set of Bunge-Euler angle triplets. - Orientations of the sub-grains are sampled by scattering the orientation of the (parent) grain. - input(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): + Orientations of the sub-grains are sampled by scattering the orientation + of the (parent) grain and with optional Rayleigh-distributed scatter. + bunge_euler(NX_FLOAT): + doc: | + Bunge-Euler angle parameterization of the texture components + location in orientation space for which specifically different settings + should be configured. + unit: NX_ANGLE + dim: (n_ori, 3) variance_subgrain(NX_FLOAT): # 5.0 doc: | + The variance of the disorientation of the sub-grain to their parent grain. unit: NX_ANGLE + dim: (n_categories,) # what is with preference orientations? - # 1 # via OpenMP # 1 # 0.00 diff --git a/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml index 6c56dae7ef..1ec50cddf3 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml @@ -1,11 +1,92 @@ category: application doc: | - Application definition for documenting results obtained with the IMM structure generator. -# symbols: + Application definition for the results of the legacy (micro)structure generator developed + by the Institut für Metallkunde und Metallphysik at RWTH Aachen University. + + * `N. Leuning et al. `_ + * `C. Mießen `_ + * `M. Kühbach `_ + * `M. Kühbach et al. `_ + + The tool can be used to instantiate specific configurations for two- and three-dimensional discretized microstructures. + Specifically, single-phase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. + Grains are modelled as elongated crystals to mimic fundamental geometrical constraints of the interface network in deformed material. + +symbols: + n_edge: | + Number of material points along the edge of the square- or cube-shaped domain. type: group NXmicrostructure_imm_results(NXobject): (NXentry): definition(NX_CHAR): enumeration: [NXmicrostructure_imm_results] - # \@version(NX_CHAR): - # TODO: populate further based on appdefs NXmicrostructure_score_results and NXmicrostructure_gragles_results \ No newline at end of file + microstructureID(NXmicrostructure): + grid(NXcg_grid): + extent(NX_UINT): + cell_dimensions(NX_NUMBER): + structure(NXdata): + doc: | + Default plot showing the grid. + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_CHAR): + title(NX_CHAR): + crystal_identifier(NX_NUMBER): + doc: | + Crystal identifier that was assigned to each material point. + unit: NX_UNITLESS + # either (n_edge, n_edge) or (n_edge, n_edge, n_edge) + z(NX_NUMBER): + exists: optional # to cater for the 2D case + doc: | + Material point barycentre coordinate along z direction. + unit: NX_LENGTH + dim: (n_edge,) + \@long_name(NX_CHAR): + doc: | + Coordinate along z direction. + y(NX_NUMBER): + doc: | + Material point barycentre coordinate along y direction. + unit: NX_LENGTH + dim: (n_edge,) + \@long_name(NX_CHAR): + doc: | + Coordinate along y direction. + x(NX_NUMBER): + doc: | + Material point barycentre coordinate along x direction. + unit: NX_LENGTH + dim: (n_edge,) + \@long_name(NX_CHAR): + doc: | + Coordinate along x direction. + crystal(NXobject): + reference(NX_CHAR): # e.g. /entry1/microstructure1/grid/structure + number_of_crystals(NX_UINT): # sub-grains + crystal_identifier(NX_INT): + dim: (c,) + area(NX_NUMBER): + exists: recommended + dim: (c,) + volume(NX_NUMBER): + exists: recommended + dim: (c,) + is_subgrain(NX_BOOLEAN): + exists: recommended + doc: | + True if the crystal is considered a sub-grain. + False if the crystal is considered a grain. + dim: (c,) + bunge_euler(NX_FLOAT): + doc: | + Bunge-Euler angle orientation of each crystal. + unit: NX_ANGLE + dim: (c, 3) + dislocation_density(NX_FLOAT): + doc: | + Mean-field dislocation density as a measure of the stored elastic energy + content that is stored in the dislocation network of this grain and related + defects within each crystal. + unit: NX_ANY # 1/m^2 + dim: (c,) diff --git a/manual/source/classes/contributed_definitions/icme-structure.rst b/manual/source/classes/contributed_definitions/icme-structure.rst index 1946b02c8e..1f408c18b6 100644 --- a/manual/source/classes/contributed_definitions/icme-structure.rst +++ b/manual/source/classes/contributed_definitions/icme-structure.rst @@ -26,6 +26,12 @@ concepts which are equally modellable with NeXus: :ref:`NXmicrostructure`: A base class for documenting a snapshot of a reconstructed microstructures. + :ref:`NXmicrostructure_imm_config`, :ref:`NXmicrostructure_imm_results`: + A specific example of an application definition for documenting the + configuration and results respectively of a computer simulation with + the legacy microstructure synthesizer developed at the Institut für + Metallkunde und Metallphysik in Aachen. + :ref:`NXmicrostructure_score_config`, :ref:`NXmicrostructure_score_results`: A specific example of an application definition for documenting the configuration and results respectively of a computer simulation with @@ -35,10 +41,3 @@ concepts which are equally modellable with NeXus: A specific example of an application definition for documenting the configuration and results respectively of a computer simulation with the grain growth level-set-based model GraGLeS. - - :ref:`NXmicrostructure_imm_config`, :ref:`NXmicrostructure_imm_results`: - A specific example of an application definition for documenting the - configuration and results respectively of a computer simulation with - the legacy microstructure synthesizer developed at the Institut für - Metallkunde und Metallphysik in Aachen. - From 19172d248bb26c422bbffba06d7afe6b82654672 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 10 Jul 2024 16:18:19 +0200 Subject: [PATCH 0793/1012] Finished data model example for NXmicrostructure_kanapy --- .../NXmicrostructure_imm_config.nxdl.xml | 2 +- .../NXmicrostructure_imm_results.nxdl.xml | 30 +++++ .../NXmicrostructure_kanapy_results.nxdl.xml | 122 ++++++++++++++++-- .../NXrotation_set.nxdl.xml | 2 +- .../nyaml/NXmicrostructure_imm_results.yaml | 26 +++- .../NXmicrostructure_kanapy_results.yaml | 80 ++++++++++-- .../icme-structure.rst | 5 + 7 files changed, 241 insertions(+), 26 deletions(-) diff --git a/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml b/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml index 58d95f5abe..a98be4dd41 100644 --- a/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml @@ -126,7 +126,7 @@ remove 0 all the time 0.00 --> - In texture research a component analyses set on the idea that properties + In texture research component analyses set on the idea that properties of grains different based on orientation with certain regions in orientation space show similar trends like a different average dislocation density or orientation_spread. diff --git a/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml b/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml index f737c93c3a..7d0dabed31 100644 --- a/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml @@ -28,6 +28,11 @@ Number of material points along the edge of the square- or cube-shaped domain. + + + Number of crystals. + + Application definition for the results of the legacy (micro)structure generator developed @@ -48,6 +53,31 @@ + + + Discouraged free-text field to add further details to the computation. + + + + + + + + + + + + + + + Programs and libraries representing the computational environment + + + + + + + diff --git a/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml b/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml index 51e69d74b3..5b85f6473d 100644 --- a/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml @@ -22,6 +22,28 @@ # For further information, see http://www.nexusformat.org --> + + + + Number of material points along the z axis of the domain. + + + + + Number of material points along the y axis of the domain. + + + + + Number of material points along the x axis of the domain. + + + + + Number of crystals. + + + Application definition for the microstructure generator kanapy from ICAMS Bochum. @@ -71,19 +93,101 @@ - + + - - - - - - - + + + Default plot showing the grid. + + + + + + + + Crystal identifier that was assigned to each material point. + + + + + + Material point barycentre coordinate along z direction. + + + + + + + Coordinate along z direction. + + + + + + Material point barycentre coordinate along y direction. + + + + + + + Coordinate along y direction. + + + + + + Material point barycentre coordinate along x direction. + + + + + + + Coordinate along x direction. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Bunge-Euler angle orientation of each crystal. + + + + + + - diff --git a/contributed_definitions/NXrotation_set.nxdl.xml b/contributed_definitions/NXrotation_set.nxdl.xml index 0c2ec652a9..dd55e97e76 100644 --- a/contributed_definitions/NXrotation_set.nxdl.xml +++ b/contributed_definitions/NXrotation_set.nxdl.xml @@ -26,7 +26,7 @@ how each object is oriented/rotated with respect to a reference coordinate system. we should offer here support for d==2, d==3 several well accepted parameterizations for rotations exists in Materials Science -thus not using NXtransformations, differentr Materials Science groups follow +thus not using NXtransformations, different Materials Science groups follow different conventions not every reporting of rotations is consistent and correct having a base class like the one proposed here offers a suggestion to start discussing at all about how to convert between groups who report using diff --git a/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml index 1ec50cddf3..a5c03a6189 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml @@ -11,15 +11,39 @@ doc: | The tool can be used to instantiate specific configurations for two- and three-dimensional discretized microstructures. Specifically, single-phase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. Grains are modelled as elongated crystals to mimic fundamental geometrical constraints of the interface network in deformed material. - symbols: n_edge: | Number of material points along the edge of the square- or cube-shaped domain. + c: | + Number of crystals. type: group NXmicrostructure_imm_results(NXobject): (NXentry): definition(NX_CHAR): enumeration: [NXmicrostructure_imm_results] + description(NX_CHAR): + doc: | + Discouraged free-text field to add further details to the computation. + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + exists: recommended + profiling(NXcs_profiling): + exists: optional + (NXuser): + exists: [min, 0, max, infty] + program1(NXprogram): + program(NX_CHAR): + \@version(NX_CHAR): + \@url(NX_CHAR): + exists: recommended + environment(NXobject): + exists: optional + doc: | + Programs and libraries representing the computational environment + programID(NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): microstructureID(NXmicrostructure): grid(NXcg_grid): extent(NX_UINT): diff --git a/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml index 20a549db27..46fa21363a 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml @@ -7,6 +7,15 @@ doc: | A draft application definition to support discussion within the infrastructure use case IUC07 of the NFDI-MatWerk consortium of the German NFDI working on a data model for documenting simulations of spatiotemporal microstructure evolution with scientific software from this community. +symbols: + n_z: | + Number of material points along the z axis of the domain. + n_y: | + Number of material points along the y axis of the domain. + n_x: | + Number of material points along the x axis of the domain. + c: | + Number of crystals. type: group NXmicrostructure_kanapy_results(NXobject): (NXentry): @@ -44,22 +53,65 @@ NXmicrostructure_kanapy_results(NXobject): # no units instead labelled-property graph concepts with units microstructureID(NXmicrostructure): exists: [min, 1, max, infty] - (NXcg_grid): # size but much more capable - exists: optional + grid(NXcg_grid): # size but much more capable + extent(NX_UINT): cell_dimensions(NX_NUMBER): - extent(NX_INT): origin(NX_NUMBER): symmetry(NX_CHAR): - position(NX_NUMBER): + structure(NXdata): + doc: | + Default plot showing the grid. + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_CHAR): + title(NX_CHAR): + crystal_identifier(NX_NUMBER): + doc: | + Crystal identifier that was assigned to each material point. + unit: NX_UNITLESS + # either (n_y, n_x) or (n_z, n_y, n_x) + z(NX_NUMBER): + exists: optional # to cater for the 2D case + doc: | + Material point barycentre coordinate along z direction. + unit: NX_LENGTH + dim: (n_y,) + \@long_name(NX_CHAR): + doc: | + Coordinate along z direction. + y(NX_NUMBER): + doc: | + Material point barycentre coordinate along y direction. + unit: NX_LENGTH + dim: (n_y,) + \@long_name(NX_CHAR): + doc: | + Coordinate along y direction. + x(NX_NUMBER): + doc: | + Material point barycentre coordinate along x direction. + unit: NX_LENGTH + dim: (n_x,) + \@long_name(NX_CHAR): + doc: | + Coordinate along x direction. + # add nodal positions as suggested in NXmicrostructure + crystal(NXobject): + reference(NX_CHAR): # e.g. /entry1/microstructure1/grid/structure + number_of_crystals(NX_UINT): + number_of_phases(NX_UINT): + crystal_identifier(NX_INT): + dim: (c,) + phase_identifier(NX_INT): + dim: (c,) + area(NX_NUMBER): exists: recommended - coordinate(NX_INT): + dim: (c,) + volume(NX_NUMBER): exists: recommended - bounding_box(NXcg_polyhedron_set): - exists: recommended - number_of_boundaries(NX_INT): - exists: recommended - boundaries(NX_CHAR): - exists: recommended - boundary_conditions(NX_INT): - exists: recommended - # TODO: populate further based on appdefs NXmicrostructure_score_results + dim: (c,) + bunge_euler(NX_FLOAT): + doc: | + Bunge-Euler angle orientation of each crystal. + unit: NX_ANGLE + dim: (c, 3) diff --git a/manual/source/classes/contributed_definitions/icme-structure.rst b/manual/source/classes/contributed_definitions/icme-structure.rst index 1f408c18b6..eb58606f65 100644 --- a/manual/source/classes/contributed_definitions/icme-structure.rst +++ b/manual/source/classes/contributed_definitions/icme-structure.rst @@ -32,6 +32,11 @@ concepts which are equally modellable with NeXus: the legacy microstructure synthesizer developed at the Institut für Metallkunde und Metallphysik in Aachen. + :ref:`NXmicrostructure_kanapy_results`: + A specific example of an application definition for documenting the results + of a computer simulation with the kanapy microstructure synthesizer + developed at the ICAMS in Bochum. + :ref:`NXmicrostructure_score_config`, :ref:`NXmicrostructure_score_results`: A specific example of an application definition for documenting the configuration and results respectively of a computer simulation with From d1e8958791e251478a499247695dfe9dbe482fbf Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 10 Jul 2024 16:23:37 +0200 Subject: [PATCH 0794/1012] add step to remove build artifacts --- .github/workflows/fairmat-build-pages.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.github/workflows/fairmat-build-pages.yaml b/.github/workflows/fairmat-build-pages.yaml index fae76f0cdd..20291dc361 100644 --- a/.github/workflows/fairmat-build-pages.yaml +++ b/.github/workflows/fairmat-build-pages.yaml @@ -29,6 +29,8 @@ jobs: run: make prepare - name: html run: make html + - name: Remove build artifacts + run: rm -rf build/manual/build/html/.doctrees - name: Deploy if: steps.branch-name.outputs.is_default == 'true' uses: peaceiris/actions-gh-pages@v3 From 2af174c4ee31ca0b35a8bee89f08e7e019eedf75 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 10 Jul 2024 17:09:52 +0200 Subject: [PATCH 0795/1012] Activate .github/workflows/fairmat-build-pages.yaml Co-authored-by: Florian Dobener --- .github/workflows/fairmat-build-pages.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.github/workflows/fairmat-build-pages.yaml b/.github/workflows/fairmat-build-pages.yaml index 20291dc361..75d0d090f7 100644 --- a/.github/workflows/fairmat-build-pages.yaml +++ b/.github/workflows/fairmat-build-pages.yaml @@ -3,8 +3,8 @@ name: GH pages fairmat proposal on: push: branches: [fairmat] - # pull_request: - # branches: [fairmat] + pull_request: + branches: [fairmat] jobs: pages: From 32afbb1bf97248711c7db4e95daa989f701592ff Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 10 Jul 2024 17:41:28 +0200 Subject: [PATCH 0796/1012] readd units to NXbeam polarization --- base_classes/NXbeam.nxdl.xml | 36 +++++++++++++++++ base_classes/nyaml/NXbeam.yaml | 72 +++++++++++++++++++++++++++++++++- 2 files changed, 107 insertions(+), 1 deletion(-) diff --git a/base_classes/NXbeam.nxdl.xml b/base_classes/NXbeam.nxdl.xml index d568c4b3d6..fc0b4d377b 100644 --- a/base_classes/NXbeam.nxdl.xml +++ b/base_classes/NXbeam.nxdl.xml @@ -225,6 +225,24 @@ + + + The units for this observable are not included in the NIAC list. + Responsibility on correct formatting and parsing is handed to the user + by using `NX_ANY`. Correct parsing can still be implemented by using + this attribute. + + | Fill with: + + * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). + * The unit unidata name if the unit has a name (Example: farad for capacitance). + * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and + does not have a name. + + Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). + Here: SI units are V2/m2. + + @@ -234,6 +252,24 @@ + + + The units for this observable are not included in the NIAC list. + Responsibility on correct formatting and parsing is handed to the user + by using `NX_ANY`. Correct parsing can still be implemented by using + this attribute. + + | Fill with: + + * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). + * The unit unidata name if the unit has a name (Example: farad for capacitance). + * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and + does not have a name. + + Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). + Here: SI units are V2/m2. + + diff --git a/base_classes/nyaml/NXbeam.yaml b/base_classes/nyaml/NXbeam.yaml index 6466c8e58d..8dddb78d70 100644 --- a/base_classes/nyaml/NXbeam.yaml +++ b/base_classes/nyaml/NXbeam.yaml @@ -176,6 +176,23 @@ NXbeam(NXobject): dimensions: rank: 2 dim: [[1, nP], [2, 2]] + \@units: + type: NX_CHAR + doc: | + The units for this observable are not included in the NIAC list. + Responsibility on correct formatting and parsing is handed to the user + by using `NX_ANY`. Correct parsing can still be implemented by using + this attribute. + + | Fill with: + + * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). + * The unit unidata name if the unit has a name (Example: farad for capacitance). + * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and + does not have a name. + + Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). + Here: SI units are V2/m2. final_polarization(NX_NUMBER): unit: NX_ANY doc: | @@ -183,6 +200,23 @@ NXbeam(NXobject): dimensions: rank: 2 dim: [[1, nP], [2, 2]] + \@units: + type: NX_CHAR + doc: | + The units for this observable are not included in the NIAC list. + Responsibility on correct formatting and parsing is handed to the user + by using `NX_ANY`. Correct parsing can still be implemented by using + this attribute. + + | Fill with: + + * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). + * The unit unidata name if the unit has a name (Example: farad for capacitance). + * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and + does not have a name. + + Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). + Here: SI units are V2/m2. incident_polarization_stokes(NX_NUMBER): unit: NX_ANY doc: | @@ -368,7 +402,7 @@ NXbeam(NXobject): Gives the beam device which this beam will interact with next. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8f2a9f6acd2587ac3b957f5d70a5058e48c7c1fec45dde083733436fc8bddab0 +# 0f4d4d5bf996841b80a3b24691b91622899dedd9e07a1944f462d2df2f478f09 # # # +symbols:--> - - - - +express conventions explicitly and understandable +appdefs each instance of NXentry should have its own set of conventions +method-specific additional conventions on top of the ones formulated here +should go to method-specific base classes like NXem_conventions_ebsd +use depends_on field - not attribute - to point to conventions which in specific cases--> + - Conventions for rotations and coordinate systems to interpret crystal orientation - and other data and results collected with electron microscopy research. - - Documenting explicitly all used conventions and coordinate systems is - the decisive context whereby many results from electron microscopy are - at all interpretable. + Base class with mathematical conventions and materials-science-specific + conventions required for interpreting collection of crystal orientation data. - - + - Mathematical conventions and materials-science-specific conventions - required for interpreting every collection of orientation data. + Convention how a positive rotation angle is defined when viewing + from the end of the rotation unit vector towards its origin, + i.e. in accordance with convention 2 of + DOI: 10.1088/0965-0393/23/8/083501. + Counter_clockwise is equivalent to a right-handed choice. + Clockwise is equivalent to a left-handed choice. - - - Convention how a positive rotation angle is defined when viewing - from the end of the rotation unit vector towards its origin, - i.e. in accordance with convention 2 of - DOI: 10.1088/0965-0393/23/8/083501. - Counter_clockwise is equivalent to a right-handed choice. - Clockwise is equivalent to a left-handed choice. - - - - - - - - - - How are rotations interpreted into an orientation - according to convention 3 of - DOI: 10.1088/0965-0393/23/8/083501. - - - - - - - - - - How are Euler angles interpreted given that there are several - choices (e.g. ZXZ, XYZ, etc.) according to convention 4 of - DOI: 10.1088/0965-0393/23/8/083501. - The most frequently used convention is ZXZ which is based on - the work of H.-J. Bunge but other conventions are possible. - - - - - - - - - To which angular range is the rotation angle argument of an - axis-angle pair parameterization constrained according to - convention 5 of DOI: 10.1088/0965-0393/23/8/083501. - - - - - - - - - Which sign convention is followed when converting orientations - between different parameterizations/representations according - to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. - - - - - - - - + + + + + + + + + How are rotations interpreted into an orientation + according to convention 3 of + DOI: 10.1088/0965-0393/23/8/083501. + + + + + + + + + + How are Euler angles interpreted given that there are several + choices (e.g. ZXZ, XYZ, etc.) according to convention 4 of + DOI: 10.1088/0965-0393/23/8/083501. + The most frequently used convention is ZXZ which is based on + the work of H.-J. Bunge but other conventions are possible. + + + + + + + + + To which angular range is the rotation angle argument of an + axis-angle pair parameterization constrained according to + convention 5 of DOI: 10.1088/0965-0393/23/8/083501. + + + + + + + + + Which sign convention is followed when converting orientations + between different parameterizations/representations according + to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. + + + + + + + Details about eventually relevant named directions that may diff --git a/contributed_definitions/nyaml/NXem_conventions.yaml b/contributed_definitions/nyaml/NXem_conventions.yaml index aa9763d510..51da689177 100644 --- a/contributed_definitions/nyaml/NXem_conventions.yaml +++ b/contributed_definitions/nyaml/NXem_conventions.yaml @@ -1,90 +1,51 @@ category: base - -# symbols: doc: | - Conventions for rotations and coordinate systems to interpret crystal orientation - and other data and results collected with electron microscopy research. - - Documenting explicitly all used conventions and coordinate systems is - the decisive context whereby many results from electron microscopy are - at all interpretable. - -# This base class provides several sets of such assumptions and conventions. -# Further base classes should be defined when specific techniques and methods -# demand further specifications or have specialized demands. NXem_conventions_ebsd -# is an example for such method-specific base class to summarize key conventions -# for Electron Backscatter Diffraction (EBSD). - -# What is could be a best practice for application definition developers -# who would like to describe an electron microscopy case where multiple -# methods and/or detectors are used. In this case one should define a -# method-specific base class like the template NXem_conventions_ebsd. -# Even though this may come at a cost of some duplicated information where -# the same physical detector is used in different ways, i.e. the signal collect -# from the detector is interpreted in a different way. -# As in most cases established types of signal and thus detectors are used -# (secondary electron, backscattered electron, etc.) one could equally use -# just one NXem_conventions base class instance in an application definition -# and use detector_reference_frame as a template. For each method and detector -# one then creates one NXprocess group named detector_reference_frame1, -# detector_reference_frame2, detector_reference_frame3, and so on and so forth -# and adds inside that NXprocess and use the depends_on field. - -# What is considered best practice in an application definition with multiple -# NXentry instances? In this case each NXentry instance should have an own -# NXspecimen instance and thus the NXem_conventions instance should be place -# inside that NXentry. This enables to group multiple experiments on multiple -# samples together without setting a constraint that in all these instances -# the conventions have to be the same. - -# However, best practice is the conventions should be expressed explicitly -# and they should whenever possible be as simple as possible and as few -# as possible to support users with understanding the content of the application -# definition. + Base class with mathematical conventions and materials-science-specific + conventions required for interpreting collection of crystal orientation data. +# symbols: type: group -NXem_conventions(NXobject): - - # mandatory information about used or - # assumed reference frame and rotation conventions - rotation_conventions(NXobject): +# express conventions explicitly and understandable +# appdefs each instance of NXentry should have its own set of conventions +# method-specific additional conventions on top of the ones formulated here +# should go to method-specific base classes like NXem_conventions_ebsd +# use depends_on field - not attribute - to point to conventions which in specific cases +NXem_conventions(NXcoordinate_system_set): + rotation_handedness(NX_CHAR): doc: | - Mathematical conventions and materials-science-specific conventions - required for interpreting every collection of orientation data. - rotation_handedness(NX_CHAR): - doc: | - Convention how a positive rotation angle is defined when viewing - from the end of the rotation unit vector towards its origin, - i.e. in accordance with convention 2 of - DOI: 10.1088/0965-0393/23/8/083501. - Counter_clockwise is equivalent to a right-handed choice. - Clockwise is equivalent to a left-handed choice. - enumeration: [undefined, counter_clockwise, clockwise] - rotation_convention(NX_CHAR): - doc: | - How are rotations interpreted into an orientation - according to convention 3 of - DOI: 10.1088/0965-0393/23/8/083501. - enumeration: [undefined, passive, active] - euler_angle_convention(NX_CHAR): - doc: | - How are Euler angles interpreted given that there are several - choices (e.g. ZXZ, XYZ, etc.) according to convention 4 of - DOI: 10.1088/0965-0393/23/8/083501. - The most frequently used convention is ZXZ which is based on - the work of H.-J. Bunge but other conventions are possible. - enumeration: [undefined, zxz] - axis_angle_convention(NX_CHAR): - doc: | - To which angular range is the rotation angle argument of an - axis-angle pair parameterization constrained according to - convention 5 of DOI: 10.1088/0965-0393/23/8/083501. - enumeration: [undefined, rotation_angle_on_interval_zero_to_pi] - sign_convention(NX_CHAR): - doc: | - Which sign convention is followed when converting orientations - between different parameterizations/representations according - to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. - enumeration: [undefined, p_plus_one, p_minus_one] + Convention how a positive rotation angle is defined when viewing + from the end of the rotation unit vector towards its origin, + i.e. in accordance with convention 2 of + DOI: 10.1088/0965-0393/23/8/083501. + Counter_clockwise is equivalent to a right-handed choice. + Clockwise is equivalent to a left-handed choice. + enumeration: [undefined, counter_clockwise, clockwise] + rotation_convention(NX_CHAR): + doc: | + How are rotations interpreted into an orientation + according to convention 3 of + DOI: 10.1088/0965-0393/23/8/083501. + enumeration: [undefined, passive, active] + euler_angle_convention(NX_CHAR): + doc: | + How are Euler angles interpreted given that there are several + choices (e.g. ZXZ, XYZ, etc.) according to convention 4 of + DOI: 10.1088/0965-0393/23/8/083501. + The most frequently used convention is ZXZ which is based on + the work of H.-J. Bunge but other conventions are possible. + enumeration: [undefined, zxz] + axis_angle_convention(NX_CHAR): + doc: | + To which angular range is the rotation angle argument of an + axis-angle pair parameterization constrained according to + convention 5 of DOI: 10.1088/0965-0393/23/8/083501. + enumeration: [undefined, rotation_angle_on_interval_zero_to_pi] + sign_convention(NX_CHAR): + doc: | + Which sign convention is followed when converting orientations + between different parameterizations/representations according + to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. + enumeration: [undefined, p_plus_one, p_minus_one] + processing_reference_frame(NXcoordinate_system): doc: | Details about eventually relevant named directions that may @@ -295,545 +256,5 @@ NXem_conventions(NXobject): For further information consult also the help info for the xaxis_direction field. enumeration: [undefined, north, east, south, west, in, out] - # conventions specific for EBSD (NXem_conventions_ebsd): - - # conventions specific for EBSD - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# b4e33f4b52cd8aad5fa72fb4796c5ca1cd43482b7394ca7af917b8d321024659 -# -# -# -# -# -# -# -# -# -# -# Conventions for rotations and coordinate systems to interpret crystal orientation -# and other data and results collected with electron microscopy research. -# -# Documenting explicitly all used conventions and coordinate systems is -# the decisive context whereby many results from electron microscopy are -# at all interpretable. -# -# -# -# -# Mathematical conventions and materials-science-specific conventions -# required for interpreting every collection of orientation data. -# -# -# -# Convention how a positive rotation angle is defined when viewing -# from the end of the rotation unit vector towards its origin, -# i.e. in accordance with convention 2 of -# DOI: 10.1088/0965-0393/23/8/083501. -# Counter_clockwise is equivalent to a right-handed choice. -# Clockwise is equivalent to a left-handed choice. -# -# -# -# -# -# -# -# -# -# How are rotations interpreted into an orientation -# according to convention 3 of -# DOI: 10.1088/0965-0393/23/8/083501. -# -# -# -# -# -# -# -# -# -# How are Euler angles interpreted given that there are several -# choices (e.g. ZXZ, XYZ, etc.) according to convention 4 of -# DOI: 10.1088/0965-0393/23/8/083501. -# The most frequently used convention is ZXZ which is based on -# the work of H.-J. Bunge but other conventions are possible. -# -# -# -# -# -# -# -# -# To which angular range is the rotation angle argument of an -# axis-angle pair parameterization constrained according to -# convention 5 of DOI: 10.1088/0965-0393/23/8/083501. -# -# -# -# -# -# -# -# -# Which sign convention is followed when converting orientations -# between different parameterizations/representations according -# to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. -# -# -# -# -# -# -# -# -# -# -# Details about eventually relevant named directions that may -# give reasons for anisotropies. The classical example is cold-rolling -# where one has to specify which directions (rolling, transverse, and normal) -# align how with the direction of the base vectors of the sample_reference_frame. -# -# -# -# Type of coordinate system and reference frame according to -# convention 1 of DOI: 10.1088/0965-0393/23/8/083501. -# -# -# -# -# -# -# -# -# Handedness of coordinate system. -# -# -# -# -# -# -# -# -# Location of the origin of the processing_reference_frame. -# This specifies the location Xp = 0, Yp = 0, Zp = 0. -# Assume regions-of-interest in this reference frame form a -# rectangle or cuboid. -# Edges are interpreted by inspecting the direction of their -# outer unit normals (which point either parallel or antiparallel) -# along respective base vector direction of the reference frame. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Name or alias assigned to the x-axis base vector, -# e.g. rolling direction. -# -# -# -# -# Direction of the positively pointing x-axis base vector of -# the processing_reference_frame. We assume the configuration -# is inspected by looking towards the sample surface from a position -# that is located behind the detector. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Name or alias assigned to the y-axis base vector, -# e.g. transverse direction. -# -# -# -# -# Direction of the positively pointing y-axis base vector of -# the processing_reference_frame. We assume the configuration -# is inspected by looking towards the sample surface from a position -# that is located behind the detector. For further information consult -# also the help info for the xaxis_direction field. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Name or alias assigned to the z-axis base vector, -# e.g. normal direction. -# -# -# -# -# Direction of the positively pointing z-axis base vector of -# the processing_reference frame. We assume the configuration -# is inspected by looking towards the sample surface from a position -# that is located behind the detector. For further information consult -# also the help info for the xaxis_direction field. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Details about the sample/specimen reference frame. -# -# -# -# Type of coordinate system and reference frame according to -# convention 1 of DOI: 10.1088/0965-0393/23/8/083501. -# The reference frame for the sample surface reference is used for -# identifying positions on a (virtual) image which is formed by -# information collected from an electron beam scanning the -# sample surface. We assume the configuration is inspected by -# looking towards the sample surface from a position that is -# located behind the detector. -# Reference DOI: 10.1016/j.matchar.2016.04.008 -# The sample surface reference frame has coordinates Xs, Ys, Zs. -# In three dimensions these coordinates are not necessarily -# located on the surface of the sample as there are multiple -# faces/sides of the sample. Most frequently though the coordinate -# system here is used to define the surface which the electron -# beam scans. -# -# -# -# -# -# -# -# -# Handedness of the coordinate system if it is a Cartesian. -# -# -# -# -# -# -# -# -# Location of the origin of the sample surface reference frame. -# This specifies the location Xs = 0, Ys = 0, Zs = 0. -# Assume regions-of-interest in this reference frame form a -# rectangle or cuboid. -# Edges are interpreted by inspecting the direction of their -# outer unit normals (which point either parallel or antiparallel) -# along respective base vector direction of the reference frame. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Name or alias assigned to the x-axis base vector, -# e.g. longest edge. -# -# -# -# -# Direction of the positively pointing x-axis base vector of -# the sample surface reference frame. We assume the configuration -# is inspected by looking towards the sample surface from a position -# that is located behind the detector. -# Different tools assume that different strategies can be used -# and are perceived as differently convenient to enter -# details about coordinate system definitions. In this ELN users -# have to possibility to fill in what they assume is sufficient to -# define the coordinate system directions unambiguously. -# Software which works with this user input needs to offer parsing -# capabilities which detect conflicting input and warn accordingly. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Name or alias assigned to the y-axis base vector, -# e.g. long edge. -# -# -# -# -# Direction of the positively pointing y-axis base vector of -# the sample surface reference frame. We assume the configuration -# is inspected by looking towards the sample surface from a position -# that is located behind the detector. For further information consult -# also the help info for the xaxis_direction field. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Name or alias assigned to the z-axis base vector, -# e.g. shortest edge. -# -# -# -# -# Direction of the positively pointing z-axis base vector of -# the sample surface reference frame. We assume the configuration -# is inspected by looking towards the sample surface from a position -# that is located behind the detector. For further information consult -# also the help info for the xaxis_direction field. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Details about the detector reference frame for a specific detector. -# -# -# -# Reference to the specifically named :ref:`NXdetector` instance -# for which these conventions in this :ref:`NXprocess` group apply -# (e.g. /entry1/instrument/detector1). -# -# -# -# -# Type of coordinate system/reference frame used for -# identifying positions in detector space Xd, Yd, Zd, -# according to DOI: 10.1016/j.matchar.2016.04.008. -# -# -# -# -# -# -# -# -# Handedness of the coordinate system if it is a Cartesian. -# -# -# -# -# -# -# -# -# Where is the origin of the detector space reference -# frame located. This is the location of Xd = 0, Yd = 0, Zd = 0. -# Assume regions-of-interest in this reference frame form a -# rectangle or cuboid. -# Edges are interpreted by inspecting the direction of their -# outer unit normals (which point either parallel or antiparallel) -# along respective base vector direction of the reference frame. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Name or alias assigned to the x-axis base vector, -# e.g. longest edge as some landmark on the detector. -# -# -# -# -# Direction of the positively pointing x-axis base vector of -# the detector space reference frame. We assume the configuration -# is inspected by looking towards the sample surface from a -# position that is located behind the detector. -# Different tools assume that different strategies can be used -# and are perceived as differently convenient to enter -# details about coordinate system definitions. In this ELN users -# have to possibility to fill in what they assume is sufficient to -# define the coordinate system directions unambiguously. -# Software which works with this user input needs to offer parsing -# capabilities which detect conflicting input and warn accordingly. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Name or alias assigned to the x-axis base vector, -# e.g. long edge as some landmark on the detector. -# -# -# -# -# Direction of the positively pointing y-axis base vector of -# the detector space reference frame. We assume the configuration -# is inspected by looking towards the sample surface from a -# position that is located behind the detector. -# For further information consult also the help info for the -# xaxis_direction field. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Name or alias assigned to the x-axis base vector, -# e.g. short edge as some landmark on the detector. -# -# -# -# -# Direction of the positively pointing z-axis base vector of -# the detector space reference frame. We assume the configuration -# is inspected by looking towards the sample surface from a -# position that is located behind the detector. -# For further information consult also the help info for the -# xaxis_direction field. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# From 293161a53442de5b1c943dc54069f7db782b7ca4 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 11 Jul 2024 10:26:31 +0200 Subject: [PATCH 0802/1012] Consolidated based classes related to NXem_conventions into NXcoordinate_system_set because that is what these conventions only talk about --- ...l => NXcoordinate_system_em_ebsd.nxdl.xml} | 17 +- .../NXcoordinate_system_set.nxdl.xml | 472 ++++++++++++++++- contributed_definitions/NXem.nxdl.xml | 3 +- .../NXem_conventions.nxdl.xml | 494 ------------------ contributed_definitions/NXem_ebsd.nxdl.xml | 3 +- .../NXmicrostructure_score_results.nxdl.xml | 19 +- .../NXrotation_set.nxdl.xml | 6 +- ....yaml => NXcoordinate_system_em_ebsd.yaml} | 15 +- .../nyaml/NXcoordinate_system_set.yaml | 387 +++++++++----- contributed_definitions/nyaml/NXem.yaml | 1 - .../nyaml/NXem_conventions.yaml | 260 --------- contributed_definitions/nyaml/NXem_ebsd.yaml | 3 +- .../nyaml/NXmicrostructure_score_results.yaml | 17 +- .../nyaml/NXrotation_set.yaml | 4 +- .../contributed_definitions/em-structure.rst | 4 +- 15 files changed, 759 insertions(+), 946 deletions(-) rename contributed_definitions/{NXem_conventions_ebsd.nxdl.xml => NXcoordinate_system_em_ebsd.nxdl.xml} (94%) delete mode 100644 contributed_definitions/NXem_conventions.nxdl.xml rename contributed_definitions/nyaml/{NXem_conventions_ebsd.yaml => NXcoordinate_system_em_ebsd.yaml} (92%) delete mode 100644 contributed_definitions/nyaml/NXem_conventions.yaml diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXcoordinate_system_em_ebsd.nxdl.xml similarity index 94% rename from contributed_definitions/NXem_conventions_ebsd.nxdl.xml rename to contributed_definitions/NXcoordinate_system_em_ebsd.nxdl.xml index d2d7456aaa..fbbc8c4aea 100644 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system_em_ebsd.nxdl.xml @@ -21,20 +21,15 @@ # # For further information, see http://www.nexusformat.org --> - - + + Base class for method-specific conventions EBSD. - This base class is expected to be used with :ref:`NXem_conventions`. - - This is the main issue which currently is not in all cases documented - and thus limits the interoperability and value of collected EBSD data. - Not communicating EBSD data with such contextual pieces of information - and the use of file formats which do not store this information is the - key unsolved problem. + Solves the key issue that currently conventions used for collecting and interpreting + EBSD data are not always explicitly communicating which limits interoperability and + reusability of EBSD data. diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/contributed_definitions/NXcoordinate_system_set.nxdl.xml index ba943e667e..c609e4ddc1 100644 --- a/contributed_definitions/NXcoordinate_system_set.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system_set.nxdl.xml @@ -21,6 +21,12 @@ # # For further information, see http://www.nexusformat.org --> + Base class to hold different coordinate systems and representation conversions. @@ -111,12 +117,464 @@ always guide the user for each group and field which of the coordinate system one refers to. + + + Convention how a positive rotation angle is defined when viewing + from the end of the rotation unit vector towards its origin, + i.e. in accordance with convention 2 of + DOI: 10.1088/0965-0393/23/8/083501. + Counter_clockwise is equivalent to a right-handed choice. + Clockwise is equivalent to a left-handed choice. + + + + + + + + + + How are rotations interpreted into an orientation + according to convention 3 of + DOI: 10.1088/0965-0393/23/8/083501. + + + + + + + + + + How are Euler angles interpreted given that there are several + choices (e.g. ZXZ, XYZ, etc.) according to convention 4 of + DOI: 10.1088/0965-0393/23/8/083501. + The most frequently used convention is ZXZ which is based on + the work of H.-J. Bunge but other conventions are possible. + + + + + + + + + To which angular range is the rotation angle argument of an + axis-angle pair parameterization constrained according to + convention 5 of DOI: 10.1088/0965-0393/23/8/083501. + + + + + + + + + Which sign convention is followed when converting orientations + between different parameterizations/representations according + to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. + + + + + + + + - + + + + Details about eventually relevant named directions that may + give reasons for anisotropies. The classical example is cold-rolling + where one has to specify which directions (rolling, transverse, and normal) + align how with the direction of the base vectors of the sample_reference_frame. + + + + Type of coordinate system and reference frame according to + convention 1 of DOI: 10.1088/0965-0393/23/8/083501. + + + + + + + + + Handedness of coordinate system. + + + + + + + + + Location of the origin of the processing_reference_frame. + This specifies the location Xp = 0, Yp = 0, Zp = 0. + Assume regions-of-interest in this reference frame form a + rectangle or cuboid. + Edges are interpreted by inspecting the direction of their + outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + + + + + + + + + + + + + + + + Name or alias assigned to the x-axis base vector, + e.g. rolling direction. + + + + + Direction of the positively pointing x-axis base vector of + the processing_reference_frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. + + + + + + + + + + + + + + Name or alias assigned to the y-axis base vector, + e.g. transverse direction. + + + + + Direction of the positively pointing y-axis base vector of + the processing_reference_frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + + + + + + + + + + + + + + Name or alias assigned to the z-axis base vector, + e.g. normal direction. + + + + + Direction of the positively pointing z-axis base vector of + the processing_reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + + + + + + + + + + + + + + + Details about the sample/specimen reference frame. + + + + Type of coordinate system and reference frame according to + convention 1 of DOI: 10.1088/0965-0393/23/8/083501. + The reference frame for the sample surface reference is used for + identifying positions on a (virtual) image which is formed by + information collected from an electron beam scanning the + sample surface. We assume the configuration is inspected by + looking towards the sample surface from a position that is + located behind the detector. + Reference DOI: 10.1016/j.matchar.2016.04.008 + The sample surface reference frame has coordinates Xs, Ys, Zs. + In three dimensions these coordinates are not necessarily + located on the surface of the sample as there are multiple + faces/sides of the sample. Most frequently though the coordinate + system here is used to define the surface which the electron + beam scans. + + + + + + + + + Handedness of the coordinate system if it is a Cartesian. + + + + + + + + + Location of the origin of the sample surface reference frame. + This specifies the location Xs = 0, Ys = 0, Zs = 0. + Assume regions-of-interest in this reference frame form a + rectangle or cuboid. + Edges are interpreted by inspecting the direction of their + outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + + + + + + + + + + + + + + + + Name or alias assigned to the x-axis base vector, + e.g. longest edge. + + + + + Direction of the positively pointing x-axis base vector of + the sample surface reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + + + + + + + + + + + + + + Name or alias assigned to the y-axis base vector, + e.g. long edge. + + + + + Direction of the positively pointing y-axis base vector of + the sample surface reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + + + + + + + + + + + + + + Name or alias assigned to the z-axis base vector, + e.g. shortest edge. + + + + + Direction of the positively pointing z-axis base vector of + the sample surface reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + + + + + + + + + + + + + + + Details about the detector reference frame for a specific detector. + + + + Reference to the specifically named :ref:`NXdetector` instance + for which these conventions in this :ref:`NXprocess` group apply + (e.g. /entry1/instrument/detector1). + + + + + Type of coordinate system/reference frame used for + identifying positions in detector space Xd, Yd, Zd, + according to DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + Handedness of the coordinate system if it is a Cartesian. + + + + + + + + + Where is the origin of the detector space reference + frame located. This is the location of Xd = 0, Yd = 0, Zd = 0. + Assume regions-of-interest in this reference frame form a + rectangle or cuboid. + Edges are interpreted by inspecting the direction of their + outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + + + + + + + + + + + + + + + + Name or alias assigned to the x-axis base vector, + e.g. longest edge as some landmark on the detector. + + + + + Direction of the positively pointing x-axis base vector of + the detector space reference frame. We assume the configuration + is inspected by looking towards the sample surface from a + position that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + + + + + + + + + + + + + + Name or alias assigned to the x-axis base vector, + e.g. long edge as some landmark on the detector. + + + + + Direction of the positively pointing y-axis base vector of + the detector space reference frame. We assume the configuration + is inspected by looking towards the sample surface from a + position that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + Name or alias assigned to the x-axis base vector, + e.g. short edge as some landmark on the detector. + + + + + Direction of the positively pointing z-axis base vector of + the detector space reference frame. We assume the configuration + is inspected by looking towards the sample surface from a + position that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 63dbd6f626..4e41ab42de 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -856,6 +856,5 @@ Acquisition mode (too vague) -> map on more expressive fields of NXem Storage tilt (what is this) for tilt see NXstage_lab Measurement date (how is it different from Date? Comments -> any of the description fields, in both cases not fair -the respective TEM group has pixel coordinates, which is all much cleaner -described using NXem_conventions, NXcoordinate_system, etc...--> +the respective TEM group has pixel coordinates, which is all much cleaner--> diff --git a/contributed_definitions/NXem_conventions.nxdl.xml b/contributed_definitions/NXem_conventions.nxdl.xml deleted file mode 100644 index d1b4354639..0000000000 --- a/contributed_definitions/NXem_conventions.nxdl.xml +++ /dev/null @@ -1,494 +0,0 @@ - - - - - - - - Base class with mathematical conventions and materials-science-specific - conventions required for interpreting collection of crystal orientation data. - - - - Convention how a positive rotation angle is defined when viewing - from the end of the rotation unit vector towards its origin, - i.e. in accordance with convention 2 of - DOI: 10.1088/0965-0393/23/8/083501. - Counter_clockwise is equivalent to a right-handed choice. - Clockwise is equivalent to a left-handed choice. - - - - - - - - - - How are rotations interpreted into an orientation - according to convention 3 of - DOI: 10.1088/0965-0393/23/8/083501. - - - - - - - - - - How are Euler angles interpreted given that there are several - choices (e.g. ZXZ, XYZ, etc.) according to convention 4 of - DOI: 10.1088/0965-0393/23/8/083501. - The most frequently used convention is ZXZ which is based on - the work of H.-J. Bunge but other conventions are possible. - - - - - - - - - To which angular range is the rotation angle argument of an - axis-angle pair parameterization constrained according to - convention 5 of DOI: 10.1088/0965-0393/23/8/083501. - - - - - - - - - Which sign convention is followed when converting orientations - between different parameterizations/representations according - to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. - - - - - - - - - - Details about eventually relevant named directions that may - give reasons for anisotropies. The classical example is cold-rolling - where one has to specify which directions (rolling, transverse, and normal) - align how with the direction of the base vectors of the sample_reference_frame. - - - - Type of coordinate system and reference frame according to - convention 1 of DOI: 10.1088/0965-0393/23/8/083501. - - - - - - - - - Handedness of coordinate system. - - - - - - - - - Location of the origin of the processing_reference_frame. - This specifies the location Xp = 0, Yp = 0, Zp = 0. - Assume regions-of-interest in this reference frame form a - rectangle or cuboid. - Edges are interpreted by inspecting the direction of their - outer unit normals (which point either parallel or antiparallel) - along respective base vector direction of the reference frame. - - - - - - - - - - - - - - - - Name or alias assigned to the x-axis base vector, - e.g. rolling direction. - - - - - Direction of the positively pointing x-axis base vector of - the processing_reference_frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. - - - - - - - - - - - - - - Name or alias assigned to the y-axis base vector, - e.g. transverse direction. - - - - - Direction of the positively pointing y-axis base vector of - the processing_reference_frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. - - - - - - - - - - - - - - Name or alias assigned to the z-axis base vector, - e.g. normal direction. - - - - - Direction of the positively pointing z-axis base vector of - the processing_reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. - - - - - - - - - - - - - - - Details about the sample/specimen reference frame. - - - - Type of coordinate system and reference frame according to - convention 1 of DOI: 10.1088/0965-0393/23/8/083501. - The reference frame for the sample surface reference is used for - identifying positions on a (virtual) image which is formed by - information collected from an electron beam scanning the - sample surface. We assume the configuration is inspected by - looking towards the sample surface from a position that is - located behind the detector. - Reference DOI: 10.1016/j.matchar.2016.04.008 - The sample surface reference frame has coordinates Xs, Ys, Zs. - In three dimensions these coordinates are not necessarily - located on the surface of the sample as there are multiple - faces/sides of the sample. Most frequently though the coordinate - system here is used to define the surface which the electron - beam scans. - - - - - - - - - Handedness of the coordinate system if it is a Cartesian. - - - - - - - - - Location of the origin of the sample surface reference frame. - This specifies the location Xs = 0, Ys = 0, Zs = 0. - Assume regions-of-interest in this reference frame form a - rectangle or cuboid. - Edges are interpreted by inspecting the direction of their - outer unit normals (which point either parallel or antiparallel) - along respective base vector direction of the reference frame. - - - - - - - - - - - - - - - - Name or alias assigned to the x-axis base vector, - e.g. longest edge. - - - - - Direction of the positively pointing x-axis base vector of - the sample surface reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. - - - - - - - - - - - - - - Name or alias assigned to the y-axis base vector, - e.g. long edge. - - - - - Direction of the positively pointing y-axis base vector of - the sample surface reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. - - - - - - - - - - - - - - Name or alias assigned to the z-axis base vector, - e.g. shortest edge. - - - - - Direction of the positively pointing z-axis base vector of - the sample surface reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. - - - - - - - - - - - - - - - Details about the detector reference frame for a specific detector. - - - - Reference to the specifically named :ref:`NXdetector` instance - for which these conventions in this :ref:`NXprocess` group apply - (e.g. /entry1/instrument/detector1). - - - - - Type of coordinate system/reference frame used for - identifying positions in detector space Xd, Yd, Zd, - according to DOI: 10.1016/j.matchar.2016.04.008. - - - - - - - - - Handedness of the coordinate system if it is a Cartesian. - - - - - - - - - Where is the origin of the detector space reference - frame located. This is the location of Xd = 0, Yd = 0, Zd = 0. - Assume regions-of-interest in this reference frame form a - rectangle or cuboid. - Edges are interpreted by inspecting the direction of their - outer unit normals (which point either parallel or antiparallel) - along respective base vector direction of the reference frame. - - - - - - - - - - - - - - - - Name or alias assigned to the x-axis base vector, - e.g. longest edge as some landmark on the detector. - - - - - Direction of the positively pointing x-axis base vector of - the detector space reference frame. We assume the configuration - is inspected by looking towards the sample surface from a - position that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. - - - - - - - - - - - - - - Name or alias assigned to the x-axis base vector, - e.g. long edge as some landmark on the detector. - - - - - Direction of the positively pointing y-axis base vector of - the detector space reference frame. We assume the configuration - is inspected by looking towards the sample surface from a - position that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - - - - - - - - - - - - - - Name or alias assigned to the x-axis base vector, - e.g. short edge as some landmark on the detector. - - - - - Direction of the positively pointing z-axis base vector of - the detector space reference frame. We assume the configuration - is inspected by looking towards the sample surface from a - position that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index 3545c952c9..cedad5c4f1 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -140,7 +140,8 @@ post-processing can be granularized also for such X-ray-based techniques, whether it be 3DXRD or HEDM. - + + diff --git a/contributed_definitions/NXmicrostructure_score_results.nxdl.xml b/contributed_definitions/NXmicrostructure_score_results.nxdl.xml index fbf590001f..b40aa7c01a 100644 --- a/contributed_definitions/NXmicrostructure_score_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_score_results.nxdl.xml @@ -268,22 +268,20 @@ when the specimen was prepared.--> + Container to hold different coordinate systems conventions. A least a right-handed Cartesian coordinate system with base vectors named x, y, and z has to be specified. Each base vector of the coordinate system should be described with an NXtransformations instance. - - - - - - - - - - + + + + + @@ -301,6 +299,7 @@ when the specimen was prepared.--> + * `R. Bonnet <https://doi.org/10.1107/S0567739480000186>`_ - + - Reference to an instance of :ref:`NXem_conventions` which contextualizes + Reference to an instance of :ref:`NXcoordinate_system_set` which contextualizes how the here reported parameterized quantities can be interpreted. - + diff --git a/contributed_definitions/nyaml/NXem_conventions_ebsd.yaml b/contributed_definitions/nyaml/NXcoordinate_system_em_ebsd.yaml similarity index 92% rename from contributed_definitions/nyaml/NXem_conventions_ebsd.yaml rename to contributed_definitions/nyaml/NXcoordinate_system_em_ebsd.yaml index 1ec180e23f..37826128ce 100644 --- a/contributed_definitions/nyaml/NXem_conventions_ebsd.yaml +++ b/contributed_definitions/nyaml/NXcoordinate_system_em_ebsd.yaml @@ -1,17 +1,13 @@ category: base -# symbols: doc: | Base class for method-specific conventions EBSD. - This base class is expected to be used with :ref:`NXem_conventions`. - - This is the main issue which currently is not in all cases documented - and thus limits the interoperability and value of collected EBSD data. - Not communicating EBSD data with such contextual pieces of information - and the use of file formats which do not store this information is the - key unsolved problem. + Solves the key issue that currently conventions used for collecting and interpreting + EBSD data are not always explicitly communicating which limits interoperability and + reusability of EBSD data. +# symbols: type: group -NXem_conventions_ebsd(NXem_conventions): +NXcoordinate_system_em_ebsd(NXobject): # move to the NXem_ebsd part of the NXem application definition gnomonic_projection_reference_frame(NXcoordinate_system): doc: | Details about the gnomonic projection reference frame. @@ -112,7 +108,6 @@ NXem_conventions_ebsd(NXem_conventions): For further details inspect the help button of xaxis_normalization_direction. enumeration: [undefined, north, east, south, west] - # distance_convention: # doc: | # How is the third of the three pattern centre parameter values, diff --git a/contributed_definitions/nyaml/NXcoordinate_system_set.yaml b/contributed_definitions/nyaml/NXcoordinate_system_set.yaml index ab166bc193..4ce364874f 100644 --- a/contributed_definitions/nyaml/NXcoordinate_system_set.yaml +++ b/contributed_definitions/nyaml/NXcoordinate_system_set.yaml @@ -88,138 +88,259 @@ doc: | always guide the user for each group and field which of the coordinate system one refers to. type: group +# express conventions explicitly and understandable +# appdefs each instance of NXentry should have its own set of conventions +# method-specific additional conventions on top of the ones formulated here +# should go to method-specific base classes like NXcoordinate_system_em_ebsd +# use depends_on field - not attribute - to point to conventions which in specific cases NXcoordinate_system_set(NXobject): + rotation_handedness(NX_CHAR): + doc: | + Convention how a positive rotation angle is defined when viewing + from the end of the rotation unit vector towards its origin, + i.e. in accordance with convention 2 of + DOI: 10.1088/0965-0393/23/8/083501. + Counter_clockwise is equivalent to a right-handed choice. + Clockwise is equivalent to a left-handed choice. + enumeration: [undefined, counter_clockwise, clockwise] + rotation_convention(NX_CHAR): + doc: | + How are rotations interpreted into an orientation + according to convention 3 of + DOI: 10.1088/0965-0393/23/8/083501. + enumeration: [undefined, passive, active] + euler_angle_convention(NX_CHAR): + doc: | + How are Euler angles interpreted given that there are several + choices (e.g. ZXZ, XYZ, etc.) according to convention 4 of + DOI: 10.1088/0965-0393/23/8/083501. + The most frequently used convention is ZXZ which is based on + the work of H.-J. Bunge but other conventions are possible. + enumeration: [undefined, zxz] + axis_angle_convention(NX_CHAR): + doc: | + To which angular range is the rotation angle argument of an + axis-angle pair parameterization constrained according to + convention 5 of DOI: 10.1088/0965-0393/23/8/083501. + enumeration: [undefined, rotation_angle_on_interval_zero_to_pi] + sign_convention(NX_CHAR): + doc: | + Which sign convention is followed when converting orientations + between different parameterizations/representations according + to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. + enumeration: [undefined, p_plus_one, p_minus_one] + # possibility to add further coordinate systems (NXcoordinate_system): - - # How to interpret "depends_on" calls for NXtransformations instances which live - # within an instance of NXcoordinate_system(_set)? - # Depends on cardinality of NXcoordinate_system_set, i.e. how many NXcoordinate_system are defined? - # - 0, the root of an NXtransformation chain i.e. "." means McStas - # - 1, the root of an NXtransformation chain i.e. "." means "that specific CS" i.e. the one defined by the single instance of NXcoordinate_system in the set - # - > 1, "." becomes ambiguous. My suggestion, spell out the name of the specific NXcoordinate_system instance to be used, using "." - # despite all these, a warning should be raised, like a logic warning (and McStas kick in) or an error (i.e. be forbidden) be raised - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2c012af7dc8e09a7f7df9408a0d04886f58bc74feff6fc207658954ad8682422 -# -# -# -# -# -# Base class to hold different coordinate systems and representation conversions. -# -# How many nodes of type :ref:`NXcoordinate_system_set` should be used in an application definition? -# -# * 0; if there is no instance of :ref:`NXcoordinate_system_set` and therein or elsewhere across -# the application definition, an instance of NXcoordinate_system is defined, -# the default NeXus `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ -# coordinate system is assumed. This makes :ref:`NXcoordinate_system_set` and -# NXcoordinate_system base classes backwards compatible to older -# NeXus conventions and classes. -# * 1; if only one :ref:`NXcoordinate_system_set` is defined, it should be placed -# as high up in the node hierarchy (ideally right below an instance of NXentry) -# of the application definition tree as possible. -# This :ref:`NXcoordinate_system_set` should define at least one NXcoordinate_system -# instance. This shall be named such that it is clear how this coordinate system is -# typically referred to in a community. For the NeXus `McStas coordinate system, it is -# advised to call it mcstas for the sake of improved clarity. -# Additional NXcoordinate_system instances should be specified if possible in that same -# :ref:`NXcoordinate_system_set` instead of cluttering them across the tree. -# -# If this is the case, it is assumed that the NXcoordinate_system_members -# overwrite the NeXus default McStas coordinate system, i.e. users can thereby -# conveniently and explicitly specify the coordinate system(s) that -# they wish to use. -# -# Users are encouraged to write also explicit and clean depends_on fields in -# all groups that encode information about where the interpretation of coordinate -# systems is relevant. If these depends_on hints are not provided, it is -# automatically assumed that all children (to arbitrary depth) -# of that branch and sub-branches below the one in which that -# :ref:`NXcoordinate_system_set` is defined use either the only NXcoordinate_system_set -# instance in that set or the application definition is considered -# underconstrained which should at all costs be avoided and in which case -# again McStas is assumed. -# * 2 and more; as soon as more than one :ref:`NXcoordinate_system_set` is specified -# somewhere in the tree, different interpretations are possible as to which -# of these coordinate system sets and instances apply or take preference. -# We realize that such ambiguities should at all costs be avoided. -# However, the opportunity for multiple sets and their instances enables to -# have branch-specific coordinate system conventions which could especially -# be useful for deep classes where multiple scientific methods are combined or -# cases where having a definition of global translation and conversion tables -# how to convert between representations in different coordinate systems -# is not desired or available for now. -# We argue that having 2 or more :ref:`NXcoordinate_system_set` instances and respective -# NXcoordinate_system instances makes the interpretation eventually unnecessary -# complicated. Instead, developers of application definitions should always try -# to work for clarity and thus use only one top-level coordinate system set. -# -# For these reasons we conclude that the option with one top-level -# :ref:`NXcoordinate_system_set` instance is the preferred choice. -# -# McStas is used if neither an instance of :ref:`NXcoordinate_system_set` nor an instance -# of NXcoordinate_system is specified. However, even in this case it is better -# to be explicit like for every other coordinate system definition to support -# users with interpreting the content and logic behind every instance of the tree. -# -# How to store coordinate systems inside :ref:`NXcoordinate_system_set`? -# Individual coordinate systems should be specified as members of the -# :ref:`NXcoordinate_system_set` instance using instances of NXcoordinate_system. -# -# How many individual instances of NXcoordinate_system to allow within one -# instance of :ref:`NXcoordinate_system_set`? -# -# * 0; This case should be avoided for the sake of clarity but this case could -# mean the authors of the definition meant that McStas is used. We conclude, -# McStas is used in this case. -# * 1; Like above-mentioned this case has the advantage that it is explicit -# and faces no ambiguities. However, in reality typically multiple -# coordinate systems have to be mastered especially for complex -# multi-signal modality experiments. -# * 2 or more; If this case is realized, the best practice is that in every -# case where a coordinate system should be referred to the respective class -# has a depends_on field which resolves the possible ambiguities which specific -# coordinate systems is referred to. The benefit of this explicit and clear -# specifying of the coordinate system used in every case is that especially -# in combination with having coordinate systems inside deeper branches -# makes up for a very versatile, backwards compatible, but powerful system -# to express different types of coordinate systems using NeXus. In the case -# of two or more instances of NXcoordinate_system in one :ref:`NXcoordinate_system_set`, -# it is also advised to specify the relationship between the two coordinate systems by -# using the (NXtransformations) group within NXcoordinate_system. -# -# In effect, 1 should be the preferred choice. However, if more than one coordinate -# system is defined for practical purposes, explicit depends_on fields should -# always guide the user for each group and field which of the coordinate system -# one refers to. -# -# -# -# + # frequently used coordinate systems with frequently relevant specializations + processing_reference_frame(NXcoordinate_system): + doc: | + Details about eventually relevant named directions that may + give reasons for anisotropies. The classical example is cold-rolling + where one has to specify which directions (rolling, transverse, and normal) + align how with the direction of the base vectors of the sample_reference_frame. + type(NX_CHAR): + doc: | + Type of coordinate system and reference frame according to + convention 1 of DOI: 10.1088/0965-0393/23/8/083501. + enumeration: [undefined, cartesian] + handedness(NX_CHAR): + doc: | + Handedness of coordinate system. + enumeration: [right_handed, left_handed] + origin(NX_CHAR): + doc: | + Location of the origin of the processing_reference_frame. + This specifies the location Xp = 0, Yp = 0, Zp = 0. + Assume regions-of-interest in this reference frame form a + rectangle or cuboid. + Edges are interpreted by inspecting the direction of their + outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] + x_alias(NX_CHAR): + doc: | + Name or alias assigned to the x-axis base vector, + e.g. rolling direction. + x_direction(NX_CHAR): + doc: | + Direction of the positively pointing x-axis base vector of + the processing_reference_frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. + enumeration: [undefined, north, east, south, west, in, out] + y_alias(NX_CHAR): + doc: | + Name or alias assigned to the y-axis base vector, + e.g. transverse direction. + y_direction(NX_CHAR): + doc: | + Direction of the positively pointing y-axis base vector of + the processing_reference_frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + z_alias(NX_CHAR): + doc: | + Name or alias assigned to the z-axis base vector, + e.g. normal direction. + z_direction(NX_CHAR): + doc: | + Direction of the positively pointing z-axis base vector of + the processing_reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + sample_reference_frame(NXcoordinate_system): + doc: | + Details about the sample/specimen reference frame. + type(NX_CHAR): + doc: | + Type of coordinate system and reference frame according to + convention 1 of DOI: 10.1088/0965-0393/23/8/083501. + The reference frame for the sample surface reference is used for + identifying positions on a (virtual) image which is formed by + information collected from an electron beam scanning the + sample surface. We assume the configuration is inspected by + looking towards the sample surface from a position that is + located behind the detector. + Reference DOI: 10.1016/j.matchar.2016.04.008 + The sample surface reference frame has coordinates Xs, Ys, Zs. + In three dimensions these coordinates are not necessarily + located on the surface of the sample as there are multiple + faces/sides of the sample. Most frequently though the coordinate + system here is used to define the surface which the electron + beam scans. + enumeration: [undefined, cartesian] + handedness(NX_CHAR): + doc: | + Handedness of the coordinate system if it is a Cartesian. + enumeration: [right_handed, left_handed] + origin(NX_CHAR): + doc: | + Location of the origin of the sample surface reference frame. + This specifies the location Xs = 0, Ys = 0, Zs = 0. + Assume regions-of-interest in this reference frame form a + rectangle or cuboid. + Edges are interpreted by inspecting the direction of their + outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] + x_alias(NX_CHAR): + doc: | + Name or alias assigned to the x-axis base vector, + e.g. longest edge. + x_direction(NX_CHAR): + doc: | + Direction of the positively pointing x-axis base vector of + the sample surface reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + enumeration: [undefined, north, east, south, west, in, out] + y_alias(NX_CHAR): + doc: | + Name or alias assigned to the y-axis base vector, + e.g. long edge. + y_direction(NX_CHAR): + doc: | + Direction of the positively pointing y-axis base vector of + the sample surface reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + z_alias(NX_CHAR): + doc: | + Name or alias assigned to the z-axis base vector, + e.g. shortest edge. + z_direction(NX_CHAR): + doc: | + Direction of the positively pointing z-axis base vector of + the sample surface reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + detector_reference_frameID(NXcoordinate_system): + doc: | + Details about the detector reference frame for a specific detector. + \@detector: + type: NX_CHAR + doc: | + Reference to the specifically named :ref:`NXdetector` instance + for which these conventions in this :ref:`NXprocess` group apply + (e.g. /entry1/instrument/detector1). + type(NX_CHAR): + doc: | + Type of coordinate system/reference frame used for + identifying positions in detector space Xd, Yd, Zd, + according to DOI: 10.1016/j.matchar.2016.04.008. + enumeration: [undefined, cartesian] + handedness(NX_CHAR): + doc: | + Handedness of the coordinate system if it is a Cartesian. + enumeration: [right_handed, left_handed] + origin(NX_CHAR): + doc: | + Where is the origin of the detector space reference + frame located. This is the location of Xd = 0, Yd = 0, Zd = 0. + Assume regions-of-interest in this reference frame form a + rectangle or cuboid. + Edges are interpreted by inspecting the direction of their + outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] + x_alias(NX_CHAR): + doc: | + Name or alias assigned to the x-axis base vector, + e.g. longest edge as some landmark on the detector. + x_direction(NX_CHAR): + doc: | + Direction of the positively pointing x-axis base vector of + the detector space reference frame. We assume the configuration + is inspected by looking towards the sample surface from a + position that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + enumeration: [undefined, north, east, south, west, in, out] + y_alias(NX_CHAR): + doc: | + Name or alias assigned to the x-axis base vector, + e.g. long edge as some landmark on the detector. + y_direction(NX_CHAR): + doc: | + Direction of the positively pointing y-axis base vector of + the detector space reference frame. We assume the configuration + is inspected by looking towards the sample surface from a + position that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + z_alias(NX_CHAR): + doc: | + Name or alias assigned to the x-axis base vector, + e.g. short edge as some landmark on the detector. + z_direction(NX_CHAR): + doc: | + Direction of the positively pointing z-axis base vector of + the detector space reference frame. We assume the configuration + is inspected by looking towards the sample surface from a + position that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + # conventions specific for certain methods + (NXcoordinate_system_em_ebsd): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index b71dcbe06d..07d6949647 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -729,4 +729,3 @@ NXem(NXobject): # Measurement date (how is it different from Date? # Comments -> any of the description fields, in both cases not fair # the respective TEM group has pixel coordinates, which is all much cleaner -# described using NXem_conventions, NXcoordinate_system, etc... \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXem_conventions.yaml b/contributed_definitions/nyaml/NXem_conventions.yaml deleted file mode 100644 index 51da689177..0000000000 --- a/contributed_definitions/nyaml/NXem_conventions.yaml +++ /dev/null @@ -1,260 +0,0 @@ -category: base -doc: | - Base class with mathematical conventions and materials-science-specific - conventions required for interpreting collection of crystal orientation data. -# symbols: -type: group -# express conventions explicitly and understandable -# appdefs each instance of NXentry should have its own set of conventions -# method-specific additional conventions on top of the ones formulated here -# should go to method-specific base classes like NXem_conventions_ebsd -# use depends_on field - not attribute - to point to conventions which in specific cases -NXem_conventions(NXcoordinate_system_set): - rotation_handedness(NX_CHAR): - doc: | - Convention how a positive rotation angle is defined when viewing - from the end of the rotation unit vector towards its origin, - i.e. in accordance with convention 2 of - DOI: 10.1088/0965-0393/23/8/083501. - Counter_clockwise is equivalent to a right-handed choice. - Clockwise is equivalent to a left-handed choice. - enumeration: [undefined, counter_clockwise, clockwise] - rotation_convention(NX_CHAR): - doc: | - How are rotations interpreted into an orientation - according to convention 3 of - DOI: 10.1088/0965-0393/23/8/083501. - enumeration: [undefined, passive, active] - euler_angle_convention(NX_CHAR): - doc: | - How are Euler angles interpreted given that there are several - choices (e.g. ZXZ, XYZ, etc.) according to convention 4 of - DOI: 10.1088/0965-0393/23/8/083501. - The most frequently used convention is ZXZ which is based on - the work of H.-J. Bunge but other conventions are possible. - enumeration: [undefined, zxz] - axis_angle_convention(NX_CHAR): - doc: | - To which angular range is the rotation angle argument of an - axis-angle pair parameterization constrained according to - convention 5 of DOI: 10.1088/0965-0393/23/8/083501. - enumeration: [undefined, rotation_angle_on_interval_zero_to_pi] - sign_convention(NX_CHAR): - doc: | - Which sign convention is followed when converting orientations - between different parameterizations/representations according - to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. - enumeration: [undefined, p_plus_one, p_minus_one] - - processing_reference_frame(NXcoordinate_system): - doc: | - Details about eventually relevant named directions that may - give reasons for anisotropies. The classical example is cold-rolling - where one has to specify which directions (rolling, transverse, and normal) - align how with the direction of the base vectors of the sample_reference_frame. - type(NX_CHAR): - doc: | - Type of coordinate system and reference frame according to - convention 1 of DOI: 10.1088/0965-0393/23/8/083501. - enumeration: [undefined, cartesian] - handedness(NX_CHAR): - doc: | - Handedness of coordinate system. - enumeration: [right_handed, left_handed] - origin(NX_CHAR): - doc: | - Location of the origin of the processing_reference_frame. - This specifies the location Xp = 0, Yp = 0, Zp = 0. - Assume regions-of-interest in this reference frame form a - rectangle or cuboid. - Edges are interpreted by inspecting the direction of their - outer unit normals (which point either parallel or antiparallel) - along respective base vector direction of the reference frame. - enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] - x_alias(NX_CHAR): - doc: | - Name or alias assigned to the x-axis base vector, - e.g. rolling direction. - x_direction(NX_CHAR): - doc: | - Direction of the positively pointing x-axis base vector of - the processing_reference_frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. - enumeration: [undefined, north, east, south, west, in, out] - y_alias(NX_CHAR): - doc: | - Name or alias assigned to the y-axis base vector, - e.g. transverse direction. - y_direction(NX_CHAR): - doc: | - Direction of the positively pointing y-axis base vector of - the processing_reference_frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. - enumeration: [undefined, north, east, south, west, in, out] - z_alias(NX_CHAR): - doc: | - Name or alias assigned to the z-axis base vector, - e.g. normal direction. - z_direction(NX_CHAR): - doc: | - Direction of the positively pointing z-axis base vector of - the processing_reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. - enumeration: [undefined, north, east, south, west, in, out] - sample_reference_frame(NXcoordinate_system): - doc: | - Details about the sample/specimen reference frame. - type(NX_CHAR): - doc: | - Type of coordinate system and reference frame according to - convention 1 of DOI: 10.1088/0965-0393/23/8/083501. - The reference frame for the sample surface reference is used for - identifying positions on a (virtual) image which is formed by - information collected from an electron beam scanning the - sample surface. We assume the configuration is inspected by - looking towards the sample surface from a position that is - located behind the detector. - Reference DOI: 10.1016/j.matchar.2016.04.008 - The sample surface reference frame has coordinates Xs, Ys, Zs. - In three dimensions these coordinates are not necessarily - located on the surface of the sample as there are multiple - faces/sides of the sample. Most frequently though the coordinate - system here is used to define the surface which the electron - beam scans. - enumeration: [undefined, cartesian] - handedness(NX_CHAR): - doc: | - Handedness of the coordinate system if it is a Cartesian. - enumeration: [right_handed, left_handed] - origin(NX_CHAR): - doc: | - Location of the origin of the sample surface reference frame. - This specifies the location Xs = 0, Ys = 0, Zs = 0. - Assume regions-of-interest in this reference frame form a - rectangle or cuboid. - Edges are interpreted by inspecting the direction of their - outer unit normals (which point either parallel or antiparallel) - along respective base vector direction of the reference frame. - enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] - x_alias(NX_CHAR): - doc: | - Name or alias assigned to the x-axis base vector, - e.g. longest edge. - x_direction(NX_CHAR): - doc: | - Direction of the positively pointing x-axis base vector of - the sample surface reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. - enumeration: [undefined, north, east, south, west, in, out] - y_alias(NX_CHAR): - doc: | - Name or alias assigned to the y-axis base vector, - e.g. long edge. - y_direction(NX_CHAR): - doc: | - Direction of the positively pointing y-axis base vector of - the sample surface reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. - enumeration: [undefined, north, east, south, west, in, out] - z_alias(NX_CHAR): - doc: | - Name or alias assigned to the z-axis base vector, - e.g. shortest edge. - z_direction(NX_CHAR): - doc: | - Direction of the positively pointing z-axis base vector of - the sample surface reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. - enumeration: [undefined, north, east, south, west, in, out] - detector_reference_frameID(NXcoordinate_system): - doc: | - Details about the detector reference frame for a specific detector. - \@detector: - type: NX_CHAR - doc: | - Reference to the specifically named :ref:`NXdetector` instance - for which these conventions in this :ref:`NXprocess` group apply - (e.g. /entry1/instrument/detector1). - type(NX_CHAR): - doc: | - Type of coordinate system/reference frame used for - identifying positions in detector space Xd, Yd, Zd, - according to DOI: 10.1016/j.matchar.2016.04.008. - enumeration: [undefined, cartesian] - handedness(NX_CHAR): - doc: | - Handedness of the coordinate system if it is a Cartesian. - enumeration: [right_handed, left_handed] - origin(NX_CHAR): - doc: | - Where is the origin of the detector space reference - frame located. This is the location of Xd = 0, Yd = 0, Zd = 0. - Assume regions-of-interest in this reference frame form a - rectangle or cuboid. - Edges are interpreted by inspecting the direction of their - outer unit normals (which point either parallel or antiparallel) - along respective base vector direction of the reference frame. - enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] - x_alias(NX_CHAR): - doc: | - Name or alias assigned to the x-axis base vector, - e.g. longest edge as some landmark on the detector. - x_direction(NX_CHAR): - doc: | - Direction of the positively pointing x-axis base vector of - the detector space reference frame. We assume the configuration - is inspected by looking towards the sample surface from a - position that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. - enumeration: [undefined, north, east, south, west, in, out] - y_alias(NX_CHAR): - doc: | - Name or alias assigned to the x-axis base vector, - e.g. long edge as some landmark on the detector. - y_direction(NX_CHAR): - doc: | - Direction of the positively pointing y-axis base vector of - the detector space reference frame. We assume the configuration - is inspected by looking towards the sample surface from a - position that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - enumeration: [undefined, north, east, south, west, in, out] - z_alias(NX_CHAR): - doc: | - Name or alias assigned to the x-axis base vector, - e.g. short edge as some landmark on the detector. - z_direction(NX_CHAR): - doc: | - Direction of the positively pointing z-axis base vector of - the detector space reference frame. We assume the configuration - is inspected by looking towards the sample surface from a - position that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - enumeration: [undefined, north, east, south, west, in, out] - # conventions specific for EBSD - (NXem_conventions_ebsd): diff --git a/contributed_definitions/nyaml/NXem_ebsd.yaml b/contributed_definitions/nyaml/NXem_ebsd.yaml index 229cddf68b..d3a8f51e12 100644 --- a/contributed_definitions/nyaml/NXem_ebsd.yaml +++ b/contributed_definitions/nyaml/NXem_ebsd.yaml @@ -102,7 +102,8 @@ symbols: standardized default plot orientation mapping. type: group NXem_ebsd(NXem_method): - conventions(NXem_conventions): + (NXcoordinate_system_set): + (NXcoordinate_system_em_ebsd): # either we have simulated data or we have a set of measured data # in every case data are Kikuchi diffraction pattern and their metadata measurement(NXprocess): diff --git a/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml index 3c4851b3fa..f5b207fd12 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml @@ -181,20 +181,17 @@ NXmicrostructure_score_results(NXobject): Hard link to a location in the hierarchy of the NeXus file where the data for default plotting are stored. (NXcoordinate_system_set): + # refactor doc: | Container to hold different coordinate systems conventions. A least a right-handed Cartesian coordinate system with base vectors named x, y, and z has to be specified. Each base vector of the coordinate system should be described with an NXtransformations instance. - TRANSFORMATIONS(NXtransformations): - exists: ['min', '3', 'max', 'unbounded'] - conventions(NXem_conventions): - rotation_conventions(NXprocess): - three_dimensional_rotation_handedness: - rotation_convention: - euler_angle_convention: - axis_angle_convention: - orientation_parameterization_sign_convention: + rotation_handedness: + rotation_convention: + euler_angle_convention: + axis_angle_convention: + sign_convention: processing_reference_frame(NXprocess): reference_frame_type: xaxis_direction: @@ -210,6 +207,8 @@ NXmicrostructure_score_results(NXobject): yaxis_direction: zaxis_direction: origin: + (NXtransformations): + exists: ['min', '3', 'max', 'unbounded'] roiID(NXroi): exists: [min, 1, max, infty] # however for solitary unit models aka volume element ensemble, replica methods we may need more than one domain diff --git a/contributed_definitions/nyaml/NXrotation_set.yaml b/contributed_definitions/nyaml/NXrotation_set.yaml index a83f889344..c0a98a7356 100644 --- a/contributed_definitions/nyaml/NXrotation_set.yaml +++ b/contributed_definitions/nyaml/NXrotation_set.yaml @@ -35,9 +35,9 @@ symbols: How many phases with usually different crystal and symmetry are distinguished. type: group NXrotation_set(NXobject): - \@depends_on(NX_CHAR): + depends_on(NX_CHAR): doc: | - Reference to an instance of :ref:`NXem_conventions` which contextualizes + Reference to an instance of :ref:`NXcoordinate_system_set` which contextualizes how the here reported parameterized quantities can be interpreted. # 2D rotations are a special type of 3D rotations and thus treated in 3D # just how to rotate the object into the reference frame defined by depends_on diff --git a/manual/source/classes/contributed_definitions/em-structure.rst b/manual/source/classes/contributed_definitions/em-structure.rst index 02005fe9ce..6f1c237c11 100644 --- a/manual/source/classes/contributed_definitions/em-structure.rst +++ b/manual/source/classes/contributed_definitions/em-structure.rst @@ -162,8 +162,8 @@ More consolidation through the use of NXsubentry classes should be considered in :ref:`NXem_method`, :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eds`, :ref:`NXem_eels`, :ref:`NXem_img`, :ref:`NXem_correlation`: Base classes with method-specific details especially when it comes to reporting post-processed data within electron microscopy. - :ref:`NXem_conventions`, :ref:`NXem_conventions_ebsd`: - A base class to store all reference frames and rotation conventions which are necessary to interpret the alignment and conventions used when working with orientation data. + :ref:`NXcoordinate_system_em_ebsd`: + Base class to store technique-specific reference frames and rotation conventions which are necessary to interpret the alignment and conventions used when working with EBSD data. :ref:`NXcrystal_structure`: A base class to store crystalline phase/structure used for a simulation of diffraction pattern and comparison of these pattern against patterns to support indexing. From bf5c6d5ed31e41154ebc2e8e1f296aa9b210b784 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 11 Jul 2024 11:15:59 +0200 Subject: [PATCH 0803/1012] Refactored NXmicrostructure_score_config --- .../NXmicrostructure_score_config.nxdl.xml | 304 ++++++++++------- .../nyaml/NXmicrostructure_score_config.yaml | 321 +++++++++--------- 2 files changed, 354 insertions(+), 271 deletions(-) diff --git a/contributed_definitions/NXmicrostructure_score_config.nxdl.xml b/contributed_definitions/NXmicrostructure_score_config.nxdl.xml index 0fde2ec03c..e8c7fd11a7 100644 --- a/contributed_definitions/NXmicrostructure_score_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_score_config.nxdl.xml @@ -33,6 +33,27 @@ Number of Bunge-Euler angle triplets for recrystallization nuclei. + + + Number of support points for the linearized drag profile. + + + + + Number of suport points for the desired time-temperature profile. + + + + + Number of entries when to defragment i.e. garbage collect the memory holding + state information for recrystallized cells. + + + + + Number of entries when to collect snapshots of the evolving microstructure. + + Number of solitary unit domains to export. @@ -51,43 +72,61 @@ - - - - - - + - Ideally, a (globally persistent) unique identifier for referring - to this analysis. + Simulation ID as an alias to refer to this simulation. - + - Possibility for leaving a free-text description about this analysis. + Discouraged free-text field to add further details to the computation. - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - + + + + + + + + + + + - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. + Programs and libraries representing the computational environment - - + + + + + + + Relevant data to instantiate a starting configuration that is typically a microstructure in deformed conditions where stored (elastic) energy is stored in the form of crystal defects, which in the SCORE model are is considered as mean-field dislocation content. - + + + + Extend of each CA domain in voxel along the x, y, and z direction. + Deformation of sheet material is assumed. + The x axis is assumed pointing along the rolling direction. + The y axis is assumed pointing along the transverse direction. + The z axis is assumed pointing along the normal direction. + + + + + + + + Details how the deformed grains should be modelled. + + Which model should be used to generate a starting microstructure. @@ -98,66 +137,43 @@ - - - Edge length of the cubic cells of each CA domain. - - - - - Extend of each CA domain in voxel along the x, y, and z direction. - Deformation of sheet material is assumed. - The x axis is assumed pointing along the rolling direction. - The y axis is assumed pointing along the transverse direction. - The z axis is assumed pointing along the normal direction. - - - - - - + - Extent of each deformed grain along the x, y, and z direction when type is - cuboidal. + Extent of each deformed grain in voxel along the + x, y, and z direction when type is cuboidal. - + Average spherical diameter when type is poisson_voronoi. - + - Set of Bunge-Euler angles to sample orientations randomly from. + Set of Bunge-Euler angles (:math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2`) + to sample orientations of deformed grains randomly from. - + - The EBSD dataset from which the initial microstructure is instantiated - if initial_microstructure/type has value ebsd. + The EBSD dataset from which the initial microstructure is + instantiated if model is ebsd. - - - Path and name of the EBSD dataset from which to generate the starting - microstructure. - - - - SHA256 checksum of the file which contains the EBSD dataset. - - - + + + + - Size of the EBSD. The EBSD orientation mapping has to be on a - regular grid of square-shaped pixels. + Extent of the pixel of the EBSD orientation mapping assuming square-shaped + pixels. @@ -165,17 +181,18 @@ - + - Phenomenological model according to which it nuclei are placed - into the domain and assumed growing. + Phenomenological model according to which recrystallization nuclei + are placed into the domain and assumed growing. - + - According to which model will the nuclei become distributed spatially. - CSR means complete spatial randomness. - Custom is implementation specific. - GB places nuclei at grain boundaries. + According to which model will the nuclei become distributed spatially: + + * csr, complete spatial randomness. + * custom, implementation specific. + * gb, nuclei placed at grain boundaries @@ -183,7 +200,7 @@ - + According to which model will the nuclei start to grow. @@ -191,7 +208,7 @@ - + According to which model will the nuclei get their orientation assigned. @@ -199,9 +216,10 @@ - + - Set of Bunge-Euler angles to sample orientations of nuclei randomly from. + Set of Bunge-Euler angles (:math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2`) + to sample orientations of nuclei randomly from. @@ -209,10 +227,11 @@ - + - (Mechanical) properties of the material which scale the amount - of stored (elastic) energy in the ROI/system. + (Mechanical) properties of the material which scale + the amount of stored (elastic) energy in the system and + thus mainly affect recrystallization kinetics. @@ -234,42 +253,81 @@ SecondOrderThermalExpCoeff--> - + - Model for the assumed mobility of grain boundaries with different - disorientation. + Model for the assumed mobility of grain boundaries with different disorientation + essentially implementing variations of Turnbull's model for + thermally-activated migration. - Which type of fundamental model for the grain boundary mobility: - For the Sebald-Gottstein model the following equation is used. - For the Rollett-Holm model the following equation is used. + Which type of fundamental model for the grain boundary mobility. + + Grain boundaries with disorientation angle smaller than 15 degree are considered + as low-angle grain boundaries. Other grain boundaries are high-angle boundaries. + - - - - - - - + + + Parameter of the Sebald-Gottstein migration model. + + + + At which disorientation angle are grain boundary considered as high-angle grain + boundaries. + + + + + Pre-exponential factor for low-angle grain boundaries. + + + + + Migration activation enthalpy for low-angle grain boundaries. + + + + + Pre-exponential factor for high-angle grain boundaries. + + + + + Migration activation enthalpy for high-angle grain boundaries. + + + + + Pre-exponential factor for particularly mobile boundaries. + + + + + Migration activation enthalpy for particularly mobile boundaries. + + - - - + + + Parameter of the Rollett-Holm migration model. + + + - + - Simulated evolution of the dislocation density as the stored - (elastic) energy assumed stored in each grain. + Time-dependent reduction of the stored (elastic) energy to account for recovery. @@ -280,11 +338,10 @@ SecondOrderThermalExpCoeff--> - + - Simulated reduction of the grain boundary speed due to - the presence of dispersoids through which the total grain boundary - area of the recrystallization front can be reduced. + Reduction of the grain boundary migration speed due to the presence of dispersoids + through which the total grain boundary area of the recrystallization front can be reduced. @@ -295,16 +352,28 @@ SecondOrderThermalExpCoeff--> - - - + + + Parameter of the Zener-Smith drag model. + + + + Configuration-dependent constant which factorizes the drag pressure. + + + + + Average surface energy of the grain-boundary-dispersoid-surface configuration + which factorizes the drag pressure. + + Support point of the linearized curve of simulated time matching a specific support point of the average dispersoid radius. - + @@ -312,14 +381,14 @@ SecondOrderThermalExpCoeff--> Support point of the linearized curve of the average dispersoid radius. - + - + - Simulated time temperature profile + Desired simulated time-temperature profile @@ -327,19 +396,19 @@ SecondOrderThermalExpCoeff--> a specific support point of the temperature. - + - + Support point of the linearized curve of the temperature. - + - + Criteria which enable to stop the simulation in a controlled manner. Whichever criterion is fulfilled first stops the simulation. @@ -360,7 +429,7 @@ SecondOrderThermalExpCoeff--> - + Settings relevant for stable numerical integration. @@ -381,7 +450,7 @@ SecondOrderThermalExpCoeff--> By how much more times should the already allocated memory - be is increased to offer space for storing states of cells + be increased to offer space for storing states of cells in the recrystallization front. @@ -398,7 +467,7 @@ SecondOrderThermalExpCoeff--> will be defragmented on-the-fly. - + @@ -407,11 +476,11 @@ SecondOrderThermalExpCoeff--> snapshot of the CA state should be exported for. - + - + Perform a statistical analyses of the results as it was @@ -440,8 +509,5 @@ SecondOrderThermalExpCoeff--> - - - diff --git a/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml index f8ce0264d7..2e3a5f6846 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml @@ -10,6 +10,14 @@ symbols: Number of Bunge-Euler angle triplets for deformed grains. n_rx_ori: | Number of Bunge-Euler angle triplets for recrystallization nuclei. + n_drag: | + Number of support points for the linearized drag profile. + n_temp: | + Number of suport points for the desired time-temperature profile. + n_defrag: | + Number of entries when to defragment i.e. garbage collect the memory holding state information for recrystallized cells. + n_snapshot: | + Number of entries when to collect snapshots of the evolving microstructure. n_su: | Number of solitary unit domains to export. type: group @@ -17,308 +25,317 @@ NXmicrostructure_score_config(NXobject): (NXentry): definition(NX_CHAR): enumeration: [NXmicrostructure_score_config] - PROGRAM(NXprogram): - program_name: - \@version: - analysis_identifier: + simulation_identifier(NX_UINT): doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional + Simulation ID as an alias to refer to this simulation. + description(NX_CHAR): doc: | - Possibility for leaving a free-text description about this analysis. - results_path: + Discouraged free-text field to add further details to the computation. + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + exists: recommended + profiling(NXcs_profiling): + exists: optional + (NXuser): + exists: [min, 0, max, infty] + program1(NXprogram): + program_name: + \@version: + \@url: + exists: recommended + environment(NXobject): exists: optional doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - time_stamp(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - initial_microstructure(NXprocess): + Programs and libraries representing the computational environment + programID(NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + + discretization(NXmicrostructure): doc: | Relevant data to instantiate a starting configuration that is typically a microstructure in deformed conditions where stored (elastic) energy is stored in the form of crystal defects, which in the SCORE model are is considered as mean-field dislocation content. - type: + grid(NXcg_grid): + extent(NX_UINT): + doc: | + Extend of each CA domain in voxel along the x, y, and z direction. + Deformation of sheet material is assumed. + The x axis is assumed pointing along the rolling direction. + The y axis is assumed pointing along the transverse direction. + The z axis is assumed pointing along the normal direction. + cell_dimensions(NX_NUMBER): + deformation(NXobject): + doc: | + Details how the deformed grains should be modelled. + model: doc: | Which model should be used to generate a starting microstructure. enumeration: [cuboidal, poisson_voronoi, ebsd, damask] - cell_size(NX_FLOAT): - unit: NX_LENGTH - doc: | - Edge length of the cubic cells of each CA domain. - domain_size(NX_UINT): - unit: NX_UNITLESS + extent(NX_FLOAT): doc: | - Extend of each CA domain in voxel along the x, y, and z direction. - Deformation of sheet material is assumed. - The x axis is assumed pointing along the rolling direction. - The y axis is assumed pointing along the transverse direction. - The z axis is assumed pointing along the normal direction. - dimensions: - rank: 1 - dim: [[1, 3]] - grain_size(NX_FLOAT): + Extent of each deformed grain in voxel along the + x, y, and z direction when type is cuboidal. unit: NX_LENGTH + dim: (3,) + diameter(NX_FLOAT): doc: | - Extent of each deformed grain along the x, y, and z direction when type is - cuboidal. - dimensions: - rank: 1 - dim: [[1, 3]] - grain_diameter(NX_FLOAT): + Average spherical diameter when type is poisson_voronoi. unit: NX_LENGTH + bunge_euler(NX_FLOAT): + exists: optional doc: | - Average spherical diameter when type is poisson_voronoi. - grain_euler(NX_FLOAT): + Set of Bunge-Euler angles (:math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2`) to sample orientations of deformed grains randomly from. unit: NX_ANGLE - doc: | - Set of Bunge-Euler angles to sample orientations randomly from. - dimensions: - rank: 2 - dim: [[1, n_dg_ori], [2, 3]] - ebsd(NXprocess): + dim: (n_dg_ori, 3) + ebsd(NXserialized): exists: optional doc: | - The EBSD dataset from which the initial microstructure is instantiated - if initial_microstructure/type has value ebsd. - filename: - doc: | - Path and name of the EBSD dataset from which to generate the starting - microstructure. - \@version: - doc: | - SHA256 checksum of the file which contains the EBSD dataset. + The EBSD dataset from which the initial microstructure is + instantiated if model is ebsd. + type: + path: + algorithm: + checksum: stepsize(NX_FLOAT): - unit: NX_LENGTH doc: | - Size of the EBSD. The EBSD orientation mapping has to be on a - regular grid of square-shaped pixels. - dimensions: - rank: 1 - dim: [[1, 2]] - nucleation_model(NXprocess): + Extent of the pixel of the EBSD orientation mapping assuming square-shaped pixels. + unit: NX_LENGTH + dim: (2,) + nucleation(NXobject): doc: | - Phenomenological model according to which it nuclei are placed - into the domain and assumed growing. - spatial_distribution_model: - doc: | - According to which model will the nuclei become distributed spatially. - CSR means complete spatial randomness. - Custom is implementation specific. - GB places nuclei at grain boundaries. + Phenomenological model according to which recrystallization nuclei + are placed into the domain and assumed growing. + spatial_distribution: + doc: | + According to which model will the nuclei become distributed spatially: + + * csr, complete spatial randomness. + * custom, implementation specific. + * gb, nuclei placed at grain boundaries + enumeration: [csr, custom, gb] - incubation_time_model: + incubation_time: doc: | According to which model will the nuclei start to grow. enumeration: [site_saturation] - orientation_model: + orientation: doc: | According to which model will the nuclei get their orientation assigned. enumeration: [sample_from_nucleus_euler] - nucleus_euler(NX_FLOAT): - unit: NX_ANGLE + bunge_euler(NX_FLOAT): doc: | - Set of Bunge-Euler angles to sample orientations of nuclei randomly from. - dimensions: - rank: 2 - dim: [[1, n_rx_ori], [2, 3]] - material_properties(NXprocess): + Set of Bunge-Euler angles (:math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2`) to sample orientations of nuclei randomly from. + unit: NX_ANGLE + dim: (n_rx_ori, 3) + material_properties(NXobject): doc: | - (Mechanical) properties of the material which scale the amount - of stored (elastic) energy in the ROI/system. + (Mechanical) properties of the material which scale + the amount of stored (elastic) energy in the system and + thus mainly affect recrystallization kinetics. reference_shear_modulus(NX_FLOAT): - unit: NX_PRESSURE doc: | Shear modulus at zero Kelvin. + unit: NX_PRESSURE reference_burgers_magnitude(NX_FLOAT): - unit: NX_LENGTH doc: | Magnitude at the Burgers vector at zero Kelvin. - + unit: NX_LENGTH # firstOrderdG0dT # alloyConstantThermalExpCoeff # FirstOrderThermalExpCoeff # SecondOrderThermalExpCoeff melting_temperature(NX_FLOAT): - unit: NX_TEMPERATURE doc: | Melting temperature in degrees Celsius. - grain_boundary_mobility_model(NXprocess): + unit: NX_TEMPERATURE + grain_boundary_mobility(NXobject): doc: | - Model for the assumed mobility of grain boundaries with different - disorientation. + Model for the assumed mobility of grain boundaries with different disorientation + essentially implementing variations of Turnbull's model for + thermally-activated migration. model: doc: | - Which type of fundamental model for the grain boundary mobility: - For the Sebald-Gottstein model the following equation is used. - For the Rollett-Holm model the following equation is used. + Which type of fundamental model for the grain boundary mobility. + + Grain boundaries with disorientation angle smaller than 15 degree are considered + as low-angle grain boundaries. Other grain boundaries are high-angle boundaries. + # TODO: add equation for the Sebald-Gottstein model the following equation + # TODO: add equation for the Rollett-Holm model the following equation enumeration: [sebald_gottstein, rollett_holm] - sebald_gottstein_parameters(NXcollection): + sebald_gottstein(NXobject): + exists: optional + doc: | + Parameter of the Sebald-Gottstein migration model. + lagb_to_hagb_cut(NX_FLOAT): + doc: | + At which disorientation angle are grain boundary considered as high-angle grain boundaries. + unit: NX_ANGLE lagb_pre_factor(NX_FLOAT): + doc: | + Pre-exponential factor for low-angle grain boundaries. unit: NX_ANY lagb_enthalpy(NX_FLOAT): + doc: | + Migration activation enthalpy for low-angle grain boundaries. unit: NX_ANY hagb_pre_factor(NX_FLOAT): + doc: | + Pre-exponential factor for high-angle grain boundaries. unit: NX_ANY hagb_enthalpy(NX_FLOAT): + doc: | + Migration activation enthalpy for high-angle grain boundaries. unit: NX_ANY special_pre_factor(NX_FLOAT): + doc: | + Pre-exponential factor for particularly mobile boundaries. unit: NX_ANY special_enthalpy(NX_FLOAT): + doc: | + Migration activation enthalpy for particularly mobile boundaries. unit: NX_ANY - rollett_holm_parameters(NXcollection): - hagb_pre_factor(NX_FLOAT): - unit: NX_ANY - hagb_enthalpy(NX_FLOAT): - unit: NX_ANY + rollett_holm(NXobject): + doc: | + Parameter of the Rollett-Holm migration model. lagb_to_hagb_cut(NX_FLOAT): unit: NX_ANY lagb_to_hagb_transition(NX_FLOAT): unit: NX_ANY lagb_to_hagb_exponent(NX_FLOAT): unit: NX_ANY - stored_energy_recovery_model(NXprocess): + hagb_pre_factor(NX_FLOAT): + unit: NX_ANY + hagb_enthalpy(NX_FLOAT): + unit: NX_ANY + stored_energy_recovery(NXobject): doc: | - Simulated evolution of the dislocation density as the stored - (elastic) energy assumed stored in each grain. + Time-dependent reduction of the stored (elastic) energy to account for recovery. model: doc: | Which type of recovery model. enumeration: [none] - dispersoid_drag_model(NXprocess): + dispersoid_drag(NXobject): doc: | - Simulated reduction of the grain boundary speed due to - the presence of dispersoids through which the total grain boundary - area of the recrystallization front can be reduced. + Reduction of the grain boundary migration speed due to the presence of dispersoids + through which the total grain boundary area of the recrystallization front can be reduced. model: doc: | Which type of drag model. enumeration: [none, zener_smith] - zener_smith_parameter(NXcollection): + zener_smith(NXobject): + exists: optional + doc: | + Parameter of the Zener-Smith drag model. pre_factor(NX_FLOAT): - surface_energy_density(NX_FLOAT): + doc: | + Configuration-dependent constant which factorizes the drag pressure. + surface_energy(NX_FLOAT): + doc: | + Average surface energy of the grain-boundary-dispersoid-surface configuration + which factorizes the drag pressure. time(NX_FLOAT): - unit: NX_TIME doc: | Support point of the linearized curve of simulated time matching a specific support point of the average dispersoid radius. - dimensions: - rank: 1 - dim: [[1, i]] + unit: NX_TIME + dim: (n_drag,) radius(NX_FLOAT): - unit: NX_LENGTH doc: | Support point of the linearized curve of the average dispersoid radius. - dimensions: - rank: 1 - dim: [[1, i]] - time_temperature_history(NXprocess): + unit: NX_LENGTH + dim: (n_drag,) + time_temperature(NXobject): doc: | - Simulated time temperature profile + Desired simulated time-temperature profile time(NX_FLOAT): - unit: NX_TIME doc: | Support point of the linearized curve of simulated time matching a specific support point of the temperature. - dimensions: - rank: 1 - dim: [[1, j]] + unit: NX_TIME + dim: (n_temp,) temperature(NX_FLOAT): - unit: NX_LENGTH doc: | Support point of the linearized curve of the temperature. - dimensions: - rank: 1 - dim: [[1, j]] - stop_criteria(NXprocess): + unit: NX_TEMPERATURE + dim: (n_temp,) + stop_criteria(NXobject): doc: | Criteria which enable to stop the simulation in a controlled manner. Whichever criterion is fulfilled first stops the simulation. max_x(NX_FLOAT): - unit: NX_DIMENSIONLESS doc: | Maximum recrystallized volume fraction. + unit: NX_DIMENSIONLESS max_time(NX_NUMBER): - unit: NX_TIME doc: | Maximum simulated physical time. + unit: NX_TIME max_iteration(NX_UINT): - unit: NX_UNITLESS doc: | Maximum number of iteration steps. - numerics(NXprocess): + unit: NX_UNITLESS + numerics(NXobject): doc: | Settings relevant for stable numerical integration. max_delta_x(NX_FLOAT): - unit: NX_DIMENSIONLESS doc: | Maximum fraction equivalent to the migration of the fastest grain boundary in the system how much a cell may be consumed in a single iteration. + unit: NX_DIMENSIONLESS initial_cell_cache(NX_FLOAT): - unit: NX_UNITLESS doc: | Fraction of the total number of cells in the CA which should initially be allocated for offering cells in the recrystallization front. - realloc_cell_cache(NX_FLOAT): unit: NX_UNITLESS + realloc_cell_cache(NX_FLOAT): doc: | By how much more times should the already allocated memory - be is increased to offer space for storing states of cells + be increased to offer space for storing states of cells in the recrystallization front. + unit: NX_UNITLESS defragment_cell_cache(NX_BOOLEAN): doc: | Should the cache for cells in the recrystallization front be defragmented on-the-fly. defragment_x(NX_FLOAT): - unit: NX_DIMENSIONLESS doc: | Heuristic recrystallized volume target values at which the cache for cells in the recrystallization front will be defragmented on-the-fly. - dimensions: - rank: 1 - dim: [[1, i]] - snapshot_x(NX_FLOAT): unit: NX_DIMENSIONLESS + dim: (n_defrag,) + snapshot_x(NX_FLOAT): doc: | List of recrystallized volume target values at which a snapshot of the CA state should be exported for. - dimensions: - rank: 1 - dim: [[1, j]] - solitary_unit_model(NXprocess): + unit: NX_DIMENSIONLESS + dim: (n_snapshot,) + solitary_unit(NXobject): apply(NX_BOOLEAN): doc: | Perform a statistical analyses of the results as it was proposed by M. Kühbach (solitary unit model ensemble approach). number_of_domains(NX_UINT): - unit: NX_UNITLESS doc: | How many independent cellular automaton domains should be instantiated. - rediscretization(NX_UINT): unit: NX_UNITLESS + rediscretization(NX_UINT): doc: | Into how many time steps should the real time interval be discretized upon during post-processing the results with the solitary unit modeling approach. - domain_identifier(NX_UINT): unit: NX_UNITLESS + domain_identifier(NX_UINT): doc: | List of identifier for those domain which should be rendered. Identifier start from 0. - dimensions: - rank: 1 - dim: [[1, n_su]] - performance(NXcs_profiling): - current_working_directory: + unit: NX_UNITLESS + dim: (n_su,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ # 6142d3475f379790762453cd32f9330b04fd40950389a8c7322331e405008183 From 87ef8eda1c97c11593cb29b1b02ed2e1af9719ea Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 11 Jul 2024 11:43:01 +0200 Subject: [PATCH 0804/1012] Refactored NXmicrostructure_gragles_config --- .../NXmicrostructure_gragles_config.nxdl.xml | 115 +++++++++------- .../NXmicrostructure_score_config.nxdl.xml | 46 +++++-- .../NXmicrostructure_gragles_config.yaml | 126 ++++++++++-------- .../nyaml/NXmicrostructure_score_config.yaml | 46 +++++-- 4 files changed, 206 insertions(+), 127 deletions(-) diff --git a/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml b/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml index 25d9428b5e..dc0bfbebcd 100644 --- a/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml @@ -29,13 +29,13 @@ type: group--> Application definition for configuring GraGLeS. GraGLeS is a continuum-scale model for shared-memory-parallelized simulations - of the isothermal evolution of 2D and 3D grain boundary networks via a - level-set approach. CPU parallelization is achieved with OpenMP. + of the isothermal evolution of 2D and 3D grain boundary networks with a level-set approach. + CPU parallelization is achieved with OpenMP. The code has been implemented by C. Mießen in the group of G. Gottstein at the Institute für Metallkunde und Metallphysik, RWTH Aachen University. - Details of the model are summarized in C. Mießen `<https://publications.rwth-aachen.de/record/709678>`_. + Details of the model are summarized in `C. Mießen <https://publications.rwth-aachen.de/record/709678>`_. @@ -43,30 +43,47 @@ type: group--> - + - Which starting configuration to take. + Simulation ID as an alias to refer to this simulation. - - - - - - - Scaling the (representative) volume element to the research question. - - - - + + + From which file should the microstructure be instantiated. + + + + + + - The formulation of mean curvature flow whereby GraGLeS models grain growth - is scale invariant. This parameter configures the assumed physical length + The formulation of mean curvature flow in the GraGLeS model is scale invariant. + Therefore, the discretization has to be scaled to the actual physical length of the simulation domain (ve, ROI). For GraGLeS the discretization is always a square or cubic axis-aligned bounding box with a regular tiling into material points @@ -77,9 +94,13 @@ read the next three from input file - + Configuration when snapshots of the system should be taken. + + Keep in mind that essentially geometry snapshot data store the + polylines and polyhedra of all grains which can take substantial disk + space. @@ -90,17 +111,16 @@ read the next three from input file - Generate a snapshot of the geometry of the entire - grain boundary network every :math:`n`-th iteration. - Setting zero causes that no geometry snapshots are taken. + Generate a snapshot of the geometry of the entire grain boundary network + every :math:`n`-th iteration. Setting zero instructs to store no geometry data. - + - Configuration when the simulation should stopped in a controlled manner. + Configuration when the simulation should be stopped in a controlled manner. Whichever criterion is fulfilled first triggers the controlled stop of and termination of GraGLeS. @@ -112,14 +132,13 @@ read the next three from input file - The simulation stops if more iterations than this criterion - have been computed. + The simulation stops if more iterations than this criterion have been computed. - + - Configuration of fundamental numerical details of the solver. + Configuration of numerical details of the solver. @@ -153,7 +172,7 @@ only guru i.e. in C++ code configurable options 1 # 0, E_ITERATIVE, 1, E_SQUARES 0.0 --> - + Configuration of the grid coarsement algorithm whereby the representation of the system is continuously rediscretized such that on average grains @@ -189,15 +208,14 @@ only guru i.e. in C++ code configurable options 3 2 0 # 0, DEFAULT, 1 skips comparison and let grains shring isolated--> - + Physically-based model of the assumed mobility of the grain boundaries. - Grain boundary mobility is not an intrinsic property of a grain boundary - but system-dependent especially as grain boundaries in reality are decorated - with defects as a consequence of which the actual mobility is a combination - of the mobility of the individual defects and the attached boundary - patches. Grain boundaries have different degrees of microscopic freedom. + Grain boundary mobility is not an intrinsic property of a grain boundary but system-dependent + especially as grain boundaries in reality are decorated with defects as a consequence of which + the actual mobility is a combination of the mobility of the individual defects and the attached + boundary patches. Grain boundaries have different degrees of microscopic freedom. Therefore, their mobility follows a distribution. - + A continuum-scale curvature of an interface causes the interface to migrate towards the center of the curvature radius. @@ -287,12 +306,12 @@ these Scaling parameter are not read as well but utilized in the ReadShockley en - + A continuum-scale difference of the stored elastic energy in dislocation configurations across a grain boundary can exert a driving force on the - grain boundary such that it migrates into the volume with the higher - stored elastic energy. + grain boundary such that the boundary migrates into the volume with the + higher stored elastic energy. @@ -306,11 +325,11 @@ these Scaling parameter are not read as well but utilized in the ReadShockley en - + In case of an applied magnetic field, a difference of the magnetic susceptibility can exert a driving force on the grain boundary such that - it migrates into the volume with the higher magnetic energy. + the boundary migrates into the volume with the higher magnetic energy. @@ -320,7 +339,7 @@ these Scaling parameter are not read as well but utilized in the ReadShockley en - + A triple line mediates the atomic arrangement differences between three interface patches. Therefore, the triple line is a defect that may not diff --git a/contributed_definitions/NXmicrostructure_score_config.nxdl.xml b/contributed_definitions/NXmicrostructure_score_config.nxdl.xml index e8c7fd11a7..d16ef60e83 100644 --- a/contributed_definitions/NXmicrostructure_score_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_score_config.nxdl.xml @@ -317,12 +317,30 @@ TODO: add equation for the Rollett-Holm model the following equation--> Parameter of the Rollett-Holm migration model. + + For rollett_holm :math:`m(\Theta) = m_0 \cdot (1 - c_1 * exp(-c_2 \cdot \frac{\Theta}{15}^{c_3}))`. - - - - - + + + The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed + temperature. GraGLeS was developed for modelling isothermal annealing. + + + + + Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not one. + + + + + Mobility scaling factor :math:`c_2`. Typically 5. + + + + + Mobility scaling factor :math:`c_3`. Typically 9. + + @@ -408,7 +426,7 @@ TODO: add equation for the Rollett-Holm model the following equation--> - + Criteria which enable to stop the simulation in a controlled manner. Whichever criterion is fulfilled first stops the simulation. @@ -470,10 +488,22 @@ TODO: add equation for the Rollett-Holm model the following equation--> - + + + List of recrystallized volume target values at which a - snapshot of the CA state should be exported for. + snapshot of the CA state should be stored. + + The code documents summary statistics like recrystallized volume fraction + for each iteration. However, snapshots of the microstructure can take much + space as SCORE is able to evolve automata with up to :math:`1600^3` cells. + Snapshot data document the current microstructure which includes the grain + assigned to each of these cells plus the state of the recrystallization front. + + Despite these front data make up for approximately one order of magnitude + less cells than represented in the domain, more numerical data have to be + collected each cell in the front than just a grain identifier. diff --git a/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml index 970405e06a..d01f472f80 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml @@ -3,39 +3,56 @@ doc: | Application definition for configuring GraGLeS. GraGLeS is a continuum-scale model for shared-memory-parallelized simulations - of the isothermal evolution of 2D and 3D grain boundary networks via a - level-set approach. CPU parallelization is achieved with OpenMP. + of the isothermal evolution of 2D and 3D grain boundary networks with a level-set approach. + CPU parallelization is achieved with OpenMP. The code has been implemented by C. Mießen in the group of G. Gottstein at the Institute für Metallkunde und Metallphysik, RWTH Aachen University. - Details of the model are summarized in C. Mießen ``_. + Details of the model are summarized in `C. Mießen `_. # symbols: # type: group NXmicrostructure_gragles_config(NXobject): (NXentry): definition(NX_CHAR): enumeration: [NXmicrostructure_gragles_config] - starting_configuration(NX_CHAR): + simulation_identifier(NX_UINT): doc: | - Which starting configuration to take. - enumeration: [read_from_file] # poisson_voronoi_tessellation - # 0, E_READ_FROM_FILE, 1, E_GENERATE_WITH_VORONOY, 2, E_READ_VERTEX, // The edges need to be ordered 3, E_GENERATE_TESTCASE, 4, E_READ_VOXELIZED_MICROSTRUCTURE - # read the next three from input file - # Microstructure.SimID.10.GrainIDs.2D.1188.raw all in config file - # Microstructure.SimID.10.uds - # 0 0, E_CUBIC, 1, E_HEXAGONAL fish from config file - - roi(NXroi): + Simulation ID as an alias to refer to this simulation. + description(NX_CHAR): doc: | - Scaling the (representative) volume element to the research question. - # either or - (NXcg_polygon_set): - # (NXcg_hexahedron_set): + Discouraged free-text field to add further details to the computation. + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + exists: recommended + profiling(NXcs_profiling): + exists: optional + (NXuser): + exists: [min, 0, max, infty] + program1(NXprogram): + program_name: + \@version: + \@url: + exists: recommended + environment(NXobject): + discretization(NXmicrostructure): + # [read_from_file] # poisson_voronoi_tessellation + # 0, E_READ_FROM_FILE, 1, E_GENERATE_WITH_VORONOY, 2, E_READ_VERTEX, // The edges need to be ordered 3, E_GENERATE_TESTCASE, 4, E_READ_VOXELIZED_MICROSTRUCTURE + # read the next three from input file + # Microstructure.SimID.10.GrainIDs.2D.1188.raw all in config file + # Microstructure.SimID.10.uds + # 0 0, E_CUBIC, 1, E_HEXAGONAL fish from config file + grid(NXserialized): # take generated structure as input as code refactoring removed microstructure synthesis related parts + doc: | + From which file should the microstructure be instantiated. + type: + path: + algorithm: + checksum: edge_length(NX_FLOAT): # 4.2037e-3 doc: | - The formulation of mean curvature flow whereby GraGLeS models grain growth - is scale invariant. This parameter configures the assumed physical length + The formulation of mean curvature flow in the GraGLeS model is scale invariant. + Therefore, the discretization has to be scaled to the actual physical length of the simulation domain (ve, ROI). For GraGLeS the discretization is always a square or cubic axis-aligned bounding box with a regular tiling into material points @@ -44,10 +61,13 @@ NXmicrostructure_gragles_config(NXobject): Edge_length is the length of the entire domain along its edge not the length of the Wigner-Seitz cell about each material point! unit: NX_LENGTH - - snapshot_sampling(NXprocess): + sampling(NXobject): doc: | Configuration when snapshots of the system should be taken. + + Keep in mind that essentially geometry snapshot data store the + polylines and polyhedra of all grains which can take substantial disk + space. system(NX_UINT): # 1 doc: | Generate a snapshot of the properties of the grains to follow @@ -56,16 +76,15 @@ NXmicrostructure_gragles_config(NXobject): unit: NX_UNITLESS geometry(NX_UINT): # 100 doc: | - Generate a snapshot of the geometry of the entire - grain boundary network every :math:`n`-th iteration. - Setting zero causes that no geometry snapshots are taken. + Generate a snapshot of the geometry of the entire grain boundary network + every :math:`n`-th iteration. Setting zero instructs to store no geometry data. unit: NX_UNITLESS # 31 no more sampling # 1 - simulation_control(NXprocess): + simulation_control(NXobject): doc: | - Configuration when the simulation should stopped in a controlled manner. + Configuration when the simulation should be stopped in a controlled manner. Whichever criterion is fulfilled first triggers the controlled stop of and termination of GraGLeS. number_of_grains(NX_UINT): # 1000 @@ -75,13 +94,11 @@ NXmicrostructure_gragles_config(NXobject): unit: NX_UNITLESS number_of_iterations(NX_UINT): # 1000000 doc: | - The simulation stops if more iterations than this criterion - have been computed. + The simulation stops if more iterations than this criterion have been computed. unit: NX_UNITLESS - - numerics(NXprocess): + numerics(NXobject): doc: | - Configuration of fundamental numerical details of the solver. + Configuration of numerical details of the solver. # use proper environment variable number_of_threads(NX_UINT): # obsolete set 01 16 convolution_mode(NX_CHAR): doc: | @@ -106,8 +123,7 @@ NXmicrostructure_gragles_config(NXobject): # 1 # 0, E_ITERATIVE, 1, E_SQUARES # 0.0 # - - grid_coarsement(NXprocess): + grid_coarsement(NXobject): doc: | Configuration of the grid coarsement algorithm whereby the representation of the system is continuously rediscretized such that on average grains @@ -137,16 +153,14 @@ NXmicrostructure_gragles_config(NXobject): # 3 # 2 # 0 # 0, DEFAULT, 1 skips comparison and let grains shring isolated - - grain_boundary_mobility_model(NXprocess): + grain_boundary_mobility(NXobject): doc: | Physically-based model of the assumed mobility of the grain boundaries. - Grain boundary mobility is not an intrinsic property of a grain boundary - but system-dependent especially as grain boundaries in reality are decorated - with defects as a consequence of which the actual mobility is a combination - of the mobility of the individual defects and the attached boundary - patches. Grain boundaries have different degrees of microscopic freedom. + Grain boundary mobility is not an intrinsic property of a grain boundary but system-dependent + especially as grain boundaries in reality are decorated with defects as a consequence of which + the actual mobility is a combination of the mobility of the individual defects and the attached + boundary patches. Grain boundaries have different degrees of microscopic freedom. Therefore, their mobility follows a distribution. # 0 # 0 # @@ -174,14 +188,14 @@ NXmicrostructure_gragles_config(NXobject): doc: | Mobility scaling factor :math:`c_3`. Typically 9. unit: NX_UNITLESS - - grain_boundary_energy_model(NXprocess): + grain_boundary_energy(NXobject): doc: | - Grain boundary surface energy. Like for the grain boundary mobility, - defects cause a distribution of energies for the patches of which - the boundary is composed resulting in currently in practical cases - a too complicated dependency of the energy and mobility model as a function - of the type and chemical decoration of the defects. + Physically-based model of the assumed grain boundary surface energy. + + Like for the grain boundary mobility, defects cause a distribution of energies for the + patches of which the boundary is composed. In practice a too complicated dependency + of the energy and mobility model is observed as a function of the type and chemical + decoration of the defects. Therefore, simplifying assumptions are typically made. type(NX_CHAR): doc: | Fundamental type of assumption if energies are considered isotropic or not. @@ -203,21 +217,19 @@ NXmicrostructure_gragles_config(NXobject): # 0.01 # - - curvature_driving_force_model(NXprocess): + curvature_driving_force(NXobject): doc: | A continuum-scale curvature of an interface causes the interface to migrate towards the center of the curvature radius. is_active(NX_BOOLEAN): doc: | If true the curvature_driving_force is considered, otherwise it is not. - - dislocation_driving_force_model(NXprocess): + stored_elastic_energy(NXobject): doc: | A continuum-scale difference of the stored elastic energy in dislocation configurations across a grain boundary can exert a driving force on the - grain boundary such that it migrates into the volume with the higher - stored elastic energy. + grain boundary such that the boundary migrates into the volume with the + higher stored elastic energy. is_active(NX_BOOLEAN): # 1 doc: | If true the dislocation_driving_force is considered, otherwise it is not. @@ -226,19 +238,17 @@ NXmicrostructure_gragles_config(NXobject): Prefactor :math:`0.5Gb^2` that factorizes the average tored elastic energy per length dislocation line. unit: NX_ANY # J/m - - magnetic_driving_force_model(NXprocess): + magnetic_field(NXobject): doc: | In case of an applied magnetic field, a difference of the magnetic susceptibility can exert a driving force on the grain boundary such that - it migrates into the volume with the higher magnetic energy. + the boundary migrates into the volume with the higher magnetic energy. is_active(NX_BOOLEAN): # 0 doc: | If true the magnetic_driving_force is considered, otherwise it is not. # MagneticField.xml # https://github.com/GraGLeS/GraGLeS2D/blob/master/params/MagneticField.xml - - triple_line_mobility_model(NXprocess): + triple_line_mobility(NXobject): doc: | A triple line mediates the atomic arrangement differences between three interface patches. Therefore, the triple line is a defect that may not diff --git a/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml index 2e3a5f6846..bca935d34e 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml @@ -200,16 +200,25 @@ NXmicrostructure_score_config(NXobject): rollett_holm(NXobject): doc: | Parameter of the Rollett-Holm migration model. - lagb_to_hagb_cut(NX_FLOAT): - unit: NX_ANY - lagb_to_hagb_transition(NX_FLOAT): - unit: NX_ANY - lagb_to_hagb_exponent(NX_FLOAT): - unit: NX_ANY - hagb_pre_factor(NX_FLOAT): - unit: NX_ANY - hagb_enthalpy(NX_FLOAT): - unit: NX_ANY + + For rollett_holm :math:`m(\Theta) = m_0 \cdot (1 - c_1 * exp(-c_2 \cdot \frac{\Theta}{15}^{c_3}))`. + m_null(NX_FLOAT): + doc: | + The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed + temperature. GraGLeS was developed for modelling isothermal annealing. + unit: NX_ANY # m^4/Js + c_one(NX_FLOAT): + doc: | + Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not one. + unit: NX_DIMENSIONLESS + c_two(NX_FLOAT): + doc: | + Mobility scaling factor :math:`c_2`. Typically 5. + unit: NX_UNITLESS + c_three(NX_FLOAT): + doc: | + Mobility scaling factor :math:`c_3`. Typically 9. + unit: NX_UNITLESS stored_energy_recovery(NXobject): doc: | Time-dependent reduction of the stored (elastic) energy to account for recovery. @@ -261,7 +270,7 @@ NXmicrostructure_score_config(NXobject): Support point of the linearized curve of the temperature. unit: NX_TEMPERATURE dim: (n_temp,) - stop_criteria(NXobject): + simulation_control(NXobject): doc: | Criteria which enable to stop the simulation in a controlled manner. Whichever criterion is fulfilled first stops the simulation. @@ -309,10 +318,21 @@ NXmicrostructure_score_config(NXobject): will be defragmented on-the-fly. unit: NX_DIMENSIONLESS dim: (n_defrag,) - snapshot_x(NX_FLOAT): + sampling(NXobject): + x(NX_FLOAT): doc: | List of recrystallized volume target values at which a - snapshot of the CA state should be exported for. + snapshot of the CA state should be stored. + + The code documents summary statistics like recrystallized volume fraction + for each iteration. However, snapshots of the microstructure can take much + space as SCORE is able to evolve automata with up to :math:`1600^3` cells. + Snapshot data document the current microstructure which includes the grain + assigned to each of these cells plus the state of the recrystallization front. + + Despite these front data make up for approximately one order of magnitude + less cells than represented in the domain, more numerical data have to be + collected each cell in the front than just a grain identifier. unit: NX_DIMENSIONLESS dim: (n_snapshot,) solitary_unit(NXobject): From 028bce9d02765e29f98b59a2bcd8f43accd09b9d Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 11 Jul 2024 11:48:34 +0200 Subject: [PATCH 0805/1012] Even make html runs through locally --- .../NXmicrostructure_gragles_config.nxdl.xml | 2 +- .../nyaml/NXmicrostructure_gragles_config.yaml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml b/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml index dc0bfbebcd..48def5ed66 100644 --- a/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml @@ -321,7 +321,7 @@ these Scaling parameter are not read as well but utilized in the ReadShockley en Prefactor :math:`0.5Gb^2` that factorizes the average - tored elastic energy per length dislocation line. + stored elastic energy per length dislocation line. diff --git a/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml index d01f472f80..f1f03971f3 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml @@ -236,7 +236,7 @@ NXmicrostructure_gragles_config(NXobject): line_energy(NX_FLOAT): # 1.44e-9 doc: | Prefactor :math:`0.5Gb^2` that factorizes the average - tored elastic energy per length dislocation line. + stored elastic energy per length dislocation line. unit: NX_ANY # J/m magnetic_field(NXobject): doc: | From b19701c17fc979cf3b868c17aadcd24cfb0148b4 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 11 Jul 2024 12:22:54 +0200 Subject: [PATCH 0806/1012] remove _source build artifacts before docs deployment --- .github/workflows/fairmat-build-pages.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/fairmat-build-pages.yaml b/.github/workflows/fairmat-build-pages.yaml index 2457f7c017..0321208c0e 100644 --- a/.github/workflows/fairmat-build-pages.yaml +++ b/.github/workflows/fairmat-build-pages.yaml @@ -30,7 +30,7 @@ jobs: - name: html run: make html - name: Remove build artifacts - run: rm -rf build/manual/build/html/.doctrees + run: rm -rf build/manual/build/html/.doctrees build/manual/build/html/_sources - name: Checkout fairmat-docs branch run: | git fetch origin fairmat-docs From f9c55a9530a963ee6043d41f2939bb590e56fd64 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 11 Jul 2024 15:39:57 +0200 Subject: [PATCH 0807/1012] Finished NXmicrostructure_score_results and hope that commenting out the rollett-holm formula fixes the build error with latex, locally at least it does --- .../NXmicrostructure_gragles_config.nxdl.xml | 23 +- .../NXmicrostructure_score_config.nxdl.xml | 3 +- .../NXmicrostructure_score_results.nxdl.xml | 856 ++++++++---------- .../NXmicrostructure_gragles_config.yaml | 14 +- .../nyaml/NXmicrostructure_score_config.yaml | 4 +- .../nyaml/NXmicrostructure_score_results.yaml | 689 +++++--------- 6 files changed, 621 insertions(+), 968 deletions(-) diff --git a/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml b/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml index 48def5ed66..e078938cfa 100644 --- a/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml @@ -63,7 +63,16 @@ type: group--> - + + + Programs and libraries representing the computational environment + + + + + + + - Fundamental model how :math:`m` is assumed a function of the disorientation angle :math:`\Theta`. - - For rollett_holm :math:`m(\Theta) = m_0 \cdot (1 - c_1 * exp(-c_2 \cdot \frac{\Theta}{15}^{c_3}))`. + Fundamental model how :math:`m` is assumed a function of the disorientation + angle :math:`\Theta`. + The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed @@ -284,14 +293,12 @@ only guru i.e. in C++ code configurable options Mean grain boundary surface energy that is assumed a function of the disorientation angle :math:`\Theta` of the adjoining grains :math:`\gamma(\Theta)`. - - For GraGLeS :math:`\gamma(\Theta) = \{\begin{array}1 \text{for} \Theta > 1. \\ 0.01 \text{for} \Theta \leq 1.\end{array}`. - This value factorizes the curvature_driving_force model. - diff --git a/contributed_definitions/NXmicrostructure_score_config.nxdl.xml b/contributed_definitions/NXmicrostructure_score_config.nxdl.xml index d16ef60e83..5d76d8a7c0 100644 --- a/contributed_definitions/NXmicrostructure_score_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_score_config.nxdl.xml @@ -317,9 +317,8 @@ TODO: add equation for the Rollett-Holm model the following equation--> Parameter of the Rollett-Holm migration model. - - For rollett_holm :math:`m(\Theta) = m_0 \cdot (1 - c_1 * exp(-c_2 \cdot \frac{\Theta}{15}^{c_3}))`. + The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed diff --git a/contributed_definitions/NXmicrostructure_score_results.nxdl.xml b/contributed_definitions/NXmicrostructure_score_results.nxdl.xml index b40aa7c01a..37bf51bfaa 100644 --- a/contributed_definitions/NXmicrostructure_score_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_score_results.nxdl.xml @@ -28,6 +28,11 @@ inspect comments behind NXmicrostructure--> The symbols used in the schema to specify e.g. dimensions of arrays. + + + The total number of summary statistic log entries. + + Number of boundaries of the bounding box or primitive to domain. @@ -85,241 +90,97 @@ inspect comments behind NXmicrostructure--> - - - Ideally, a (globally) unique persistent identifier - for referring to this computer simulation. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - - - + - Free-text description about the workflow (analysis/simulation). - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of this application definition rather than write details about the - experiment into this free-text description field. + Simulation ID as an alias to refer to this simulation. - + - ISO 8601 time code with local time zone offset to UTC information - included when the characterization started. + Discouraged free-text field to add further details to the computation. - - - ISO 8601 time code with local time zone offset to UTC included - when the characterization ended. - - - + + + + + - - - Specify if the (characterization) results/data of this instance of an - application definition are based on the results of a simulation or the - results of a post-processing of measured data to describe a microstructure. - The term microstructure is used to describe the spatial arrangement of - crystal defects inside a sample/specimen without demanding necessarily - that this structure is mainly at the micron length scale. - Nanostructure and macrostructure are close synonyms. - Material architecture is a narrow synonym. - - - - - - - - - - The path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the SCORE executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - Contact information and eventually details of at least one person - involved in creating this result. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service - should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - - Descriptive name or ideally (globally) unique persistent identifier. - - - - - + - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. + Programs and libraries representing the computational environment + + + + + - - - - Container to hold different coordinate systems conventions. - A least a right-handed Cartesian coordinate system with base vectors - named x, y, and z has to be specified. Each base vector of the - coordinate system should be described with an NXtransformations instance. - + - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - - - The simulated or characterized material volume element aka domain. - At least one instance of geometry required either NXcg_grid, - NXcg_polyhedron_set, or NXcg_point_set. This geometry group needs - to contain details about the boundary conditions. - + - + @@ -335,12 +196,6 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele six sides can be distinguished, each making an own boundary. - - - Name of the boundaries. E.g. left, right, front, back, bottom, top, - The field must have as many entries as there are number_of_boundaries. - - The boundary conditions for each boundary: @@ -353,333 +208,336 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 5 - Dirichlet - + - - - - Collection of microstructural data observed/simulated. - - + - Integer which specifies the first index to be used for distinguishing - snapshots. Identifiers are defined either implicitly or explicitly. - For implicit indexing the identifiers are defined on the - interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate - if the identifiers are expected to start from 1 (referred to as - Fortran-/Matlab-) or from 0 (referred to as C-, Python-style index - notation) respectively. + Name of the boundaries. Left, right, front, back, bottom, top, + The field must have as many entries as there are number_of_boundaries. + + + - - + + + + + Documentation of the spatiotemporal evolution + + + + + Summary quantities which are the result of some post-processing of the snapshot data + (averaging, integrating, interpolating) happening in for practical reasons though in while + running the simulation. Place used for storing descriptors from continuum mechanics + and thermodynamics at the scale of the entire ROI. + + - Summary quantities which are the result of some post-processing of - the snapshot data (averaging, integrating, interpolating). - Frequently used descriptors from continuum mechanics and thermodynamics - can be used here. A few examples are given. Each descriptor is currently - modelled as an instance of an NXprocess because it is relevant to - understand how the descriptors are computed. + Evolution of the recrystallized volume fraction over time. - + - Evolution of the physical time. + Evolution of the physical time not to be confused with wall-clock time or + profiling data. - - + + + + + + + Iteration or increment counter. + + + Evolution of the simulated temperature over time. - - - + + + + + - Evolution of the recrystallized volume fraction over time. + Recrystallized volume fraction. - + + + + - - - + + - Measured or simulated physical time stamp for this snapshot. - Not to be confused with wall-clock timing or profiling data. + Which type of stress. + + + - + - Simulated temperature. + Applied external stress tensor on the ROI. + + + + + - + + + - Iteration or increment counter. + Which type of strain. - - - - - Grain identifier for each cell. - - - - - - - - - - Identifier of the OpenMP thread which processed this part of the grid. - - - - - - - - - - + - Details about those cells which in this time step represent - the discretized recrystallization front. + Applied external strain tensor on the ROI. - - - Which cells are currently in a halo region of threads. - - - - - - - - So-called mobility weight which is a scaling factor to - control the mobility of the grain boundary which is assumed - to sweep currently this volume. - - - - - - - - Grid coordinates of each cell in the recrystallization front. - - - - - - - - - Grain identifier assigned to each cell in the recrystallization front. - - - - - - - - Grain identifier assigned to each nucleus which affected that cell in the - recrystallization front. - - - - - - - - Relative volume transformed as a measure of infection progress. - - - - - - - - Identifier of the OpenMP thread processing each cell in the recrystallization - front. - - - - - - - - Hint about the direction from which the cell was infected. - - - - - - - + + + + + + + + + - Current grain-related quantities. + Which type of deformation gradient. - - - Bunge-Euler angle triplets for each grain. - - - - - - - - - Discrete volume of each grain accounting also for partially - transformed cells. - - - - - - - - Current value for the dislocation density as a measure of - the remaining stored energy in assumed crystal defects inside - each grain. The difference between these values scales the - driving force of grain boundary migration. - - - - - - - - Is the grain deformed. - - - - - - - - Is the grain recrystallized. - - - - - - - + + + + + - Current recrystallized volume fraction. + Applied deformation gradient tensor on the ROI. - - - Currently evaluated actual recrystallized volume fraction. - This takes into account partially recrystallized cells. - - - - - Currently desired target recrystallized volume fraction at - which the user requested to log a snapshot. - - - - - - - - Currently assumed globally applied Cauchy stress tensor on the ROI. - - - - - - - - - - - Currently assumed globally applied Cauchy strain tensor on the ROI. - - - - - - - + + + + + + + + + + + Applied external magnetic field on the ROI. + + + + + + + + + + + + + Applied external electrical field on the ROI. + + + + + + + - - - - - - - - - - - - - - - - - - - + + + + + + + Simulated temperature for this snapshot. + + + + + Current recrystallized volume fraction (taking fractional infections into + account). + + + + + Target value for which a snapshot was requested for the recrystallized volume + fraction. + + + + + - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. + Grain identifier for each cell. + + + + + - - + - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. + Identifier of the OpenMP thread which processed this part of the grid. + + + + + - - + + + + + + + + + + + + + + + + + + + + Volume of each grain accounting also for partially transformed cells. + + + + + + + + + Bunge-Euler angle triplets for each grain. + + + + + + + + + Current value for the dislocation density as a measure of the remaining stored energy + in assumed crystal defects inside each grain. + + + + + + + + Is the grain deformed. + + + + + + + + Is the grain recrystallized. + + + + + + + + + Details about those cells which in this time step represent the discrete + recrystallization front. + + + + Which cells are currently in a halo region of threads. + + + + + + + + So-called mobility weight which is a scaling factor to + control the mobility of the grain boundary which is assumed + to sweep currently this volume. + + + + + + + + The x, y, z grid coordinates of each cell in the recrystallization front. + + + + + + + + + Grain identifier assigned to each cell in the recrystallization front. + + + + + + + + Grain identifier assigned to each nucleus which affected that cell in the + recrystallization front. + + + + + + + + Identifier of the OpenMP thread processing each cell in the recrystallization + front. + + + + + + - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. + Hint about the direction from which the cell was infected. + + + - - + diff --git a/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml index f1f03971f3..befbff7893 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml @@ -35,6 +35,13 @@ NXmicrostructure_gragles_config(NXobject): \@url: exists: recommended environment(NXobject): + exists: optional + doc: | + Programs and libraries representing the computational environment + programID(NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): discretization(NXmicrostructure): # [read_from_file] # poisson_voronoi_tessellation # 0, E_READ_FROM_FILE, 1, E_GENERATE_WITH_VORONOY, 2, E_READ_VERTEX, // The edges need to be ordered 3, E_GENERATE_TESTCASE, 4, E_READ_VOXELIZED_MICROSTRUCTURE @@ -167,9 +174,8 @@ NXmicrostructure_gragles_config(NXobject): model(NX_CHAR): doc: | Fundamental model how :math:`m` is assumed a function of the disorientation angle :math:`\Theta`. - - For rollett_holm :math:`m(\Theta) = m_0 \cdot (1 - c_1 * exp(-c_2 \cdot \frac{\Theta}{15}^{c_3}))`. enumeration: [rollett_holm] + # For rollett_holm :math:`m(\Theta) = m_0 \cdot (1 - c_1 * exp(-c_2 \cdot \frac{\Theta}{15}^{c_3}))`. m_null(NX_FLOAT): doc: | The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed @@ -208,11 +214,9 @@ NXmicrostructure_gragles_config(NXobject): doc: | Mean grain boundary surface energy that is assumed a function of the disorientation angle :math:`\Theta` of the adjoining grains :math:`\gamma(\Theta)`. - - For GraGLeS :math:`\gamma(\Theta) = \{\begin{array}1 \text{for} \Theta > 1. \\ 0.01 \text{for} \Theta \leq 1.\end{array}`. - This value factorizes the curvature_driving_force model. unit: NX_ANY # J/m^2 + # For GraGLeS :math:`\gamma(\Theta) = \{\begin{array}1 \text{for} \Theta > 1. \\ 0.01 \text{for} \Theta \leq 1.\end{array}`. # 1.0 # 0.01 # - + diff --git a/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml index 1d14e3039c..ecd390127f 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml @@ -210,7 +210,7 @@ NXmicrostructure_score_results(NXobject): unit: NX_ANY dim: (n_summary_stats, 3, 3) # the typically storage-costlier snapshot data - microstructure1(NXmicrostructure): + microstructureID(NXmicrostructure): exists: [min, 1, max, infty] # always storing starting configuration time(NX_TIME): iteration(NX_INT): From e36bd855bd94ce370decd59b755c25cd8a783d54 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 11 Jul 2024 15:54:42 +0200 Subject: [PATCH 0809/1012] Initial version of NXmicrostructure_gragles_results --- .../NXmicrostructure_gragles_results.nxdl.xml | 229 +++++++++++++++++- .../NXmicrostructure_gragles_results.yaml | 153 +++++++++++- .../nyaml/NXmicrostructure_score_results.yaml | 1 - 3 files changed, 377 insertions(+), 6 deletions(-) diff --git a/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml b/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml index df73e88b4b..2b291c8dd8 100644 --- a/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml @@ -21,9 +21,22 @@ # # For further information, see http://www.nexusformat.org --> - + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of summary statistic log entries. + + + + + Number of grains in the computer simulation. + + + Application definition for documenting results with GraGLeS. @@ -33,6 +46,216 @@ symbols:--> + + + + Simulation ID as an alias to refer to this simulation. + + + + + Discouraged free-text field to add further details to the computation. + + + + + + + + + + + + + + Programs and libraries representing the computational environment + + + + + + + + + + + + + + + + + + + + + + + + + + + + Documentation of the spatiotemporal evolution + + + + + Summary quantities which are the result of some post-processing of the snapshot data + (averaging, integrating, interpolating) happening in for practical reasons though in while + running the simulation. Place used for storing descriptors from continuum mechanics + and thermodynamics at the scale of the entire ROI. + + + + Evolution of the recrystallized volume fraction over time. + + + + Evolution of the physical time not to be confused with wall-clock time or + profiling data. + + + + + + + + Iteration or increment counter. + + + + + How many crystals are distinguished. + Crystals are listed irrespective of the phase to which these are assigned. + + + + + + + + + + Which type of stress. + + + + + + + + Applied external stress tensor on the ROI. + + + + + + + + + + + + Which type of strain. + + + + + Applied external strain tensor on the ROI. + + + + + + + + + + + + Which type of deformation gradient. + + + + + + + + Applied deformation gradient tensor on the ROI. + + + + + + + + + + + + Applied external magnetic field on the ROI. + + + + + + + + + + + + + Applied external electrical field on the ROI. + + + + + + + + + + + + + + + + Simulated temperature for this snapshot. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - diff --git a/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml index 70b6cd6175..8049e31601 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml @@ -1,10 +1,159 @@ category: application doc: | Application definition for documenting results with GraGLeS. -# symbols: +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_summary_stats: | + The total number of summary statistic log entries. + n_grains: | + Number of grains in the computer simulation. type: group NXmicrostructure_gragles_results(NXobject): (NXentry): definition(NX_CHAR): enumeration: [NXmicrostructure_gragles_results] - # TODO: populate further based on appdefs NXmicrostructure_score_results \ No newline at end of file + # For rollett_holm :math:`m(\Theta) = m_0 \cdot (1 - c_1 * exp(-c_2 \cdot \frac{\Theta}{15}^{c_3}))`. + simulation_identifier(NX_UINT): + doc: | + Simulation ID as an alias to refer to this simulation. + description(NX_CHAR): + doc: | + Discouraged free-text field to add further details to the computation. + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + exists: recommended + (NXuser): + exists: [min, 0, max, infty] + program1(NXprogram): + program_name: + \@version: + \@url: + exists: recommended + environment(NXobject): + exists: optional + doc: | + Programs and libraries representing the computational environment + programID(NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + coordinate_system_set(NXcoordinate_system_set): + rotation_handedness: + rotation_convention: + euler_angle_convention: + axis_angle_convention: + sign_convention: + sample_reference_frame(NXcoordinate_system): + type: + handedness: + origin: + x_alias: + x_direction: + y_alias: + y_direction: + z_alias: + z_direction: + spatiotemporalID(NXobject): + doc: | + Documentation of the spatiotemporal evolution + # static quantities for which no change is modelled + # the typical lean summary statistics flattened + summary_statistics(NXobject): + doc: | + Summary quantities which are the result of some post-processing of the snapshot data + (averaging, integrating, interpolating) happening in for practical reasons though in while + running the simulation. Place used for storing descriptors from continuum mechanics + and thermodynamics at the scale of the entire ROI. + kinetics(NXprocess): + exists: optional + doc: | + Evolution of the recrystallized volume fraction over time. + time(NX_TIME): + doc: | + Evolution of the physical time not to be confused with wall-clock time or profiling data. + unit: NX_TIME + dim: (n_summary_stats,) + iteration(NX_INT): + doc: | + Iteration or increment counter. + unit: NX_UNITLESS + number_of_crystals(NX_UINT): + doc: | + How many crystals are distinguished. + Crystals are listed irrespective of the phase to which these are assigned. + unit: NX_UNITLESS + dim: (n_summary_stats,) + stress(NXprocess): + exists: optional + type: + doc: | + Which type of stress. + enumeration: [cauchy] + stress(NX_FLOAT): + doc: | + Applied external stress tensor on the ROI. + unit: NX_ANY + dim: (n_summary_stats, 3, 3) + strain(NXprocess): + exists: optional + type: + doc: | + Which type of strain. + strain(NX_FLOAT): + doc: | + Applied external strain tensor on the ROI. + unit: NX_ANY + dim: (n_summary_stats, 3, 3) + deformation_gradient(NXprocess): + exists: optional + type: + doc: | + Which type of deformation gradient. + enumeration: [piola] + value(NX_FLOAT): + doc: | + Applied deformation gradient tensor on the ROI. + unit: NX_ANY + dim: (n_summary_stats, 3, 3) + magnetic_field(NXprocess): + exists: optional + strength(NX_FLOAT): + doc: | + Applied external magnetic field on the ROI. + unit: NX_ANY + dim: (n_summary_stats, 3, 3) + electrical_field(NXprocess): + exists: optional + # specify type of field + strength(NX_FLOAT): + doc: | + Applied external electrical field on the ROI. + unit: NX_ANY + dim: (n_summary_stats, 3, 3) + # the typically storage-costlier snapshot data + microstructureID(NXmicrostructure): + exists: [min, 1, max, infty] # always storing starting configuration + time(NX_TIME): + iteration(NX_INT): + temperature(NX_FLOAT): + doc: | + Simulated temperature for this snapshot. + unit: NX_TEMPERATURE + grid(NXcg_grid): + exists: optional + crystal(NXobject): + representation: + exists: recommended + number_of_crystals(NX_UINT): + number_of_phases(NX_UINT): + crystal_identifier_offset(NX_INT): + crystal_identifier(NX_INT): + dim: (n_grains,) + phase_identifier_offset(NX_INT): + phase_identifier(NX_INT): + dim: (n_grains,) + area(NX_NUMBER): + dim: (n_grains,) + volume(NX_NUMBER): + dim: (n_grains,) diff --git a/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml index ecd390127f..33930925e0 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml @@ -33,7 +33,6 @@ symbols: Number of active cells in the (recrystallization) front. n_grains: | Number of grains in the computer simulation. - # inspect comments behind NXmicrostructure type: group NXmicrostructure_score_results(NXobject): From 5dba9e30c6c49e1106088508c6c2d559f55e4a70 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 11 Jul 2024 15:56:23 +0200 Subject: [PATCH 0810/1012] Fixed grammar issue --- .../source/classes/contributed_definitions/icme-structure.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/manual/source/classes/contributed_definitions/icme-structure.rst b/manual/source/classes/contributed_definitions/icme-structure.rst index eb58606f65..68c6f9859e 100644 --- a/manual/source/classes/contributed_definitions/icme-structure.rst +++ b/manual/source/classes/contributed_definitions/icme-structure.rst @@ -24,7 +24,7 @@ materials-engineering-specific data schemas can connect to or be mapped on concepts which are equally modellable with NeXus: :ref:`NXmicrostructure`: - A base class for documenting a snapshot of a reconstructed microstructures. + A base class for documenting a snapshot of a reconstructed microstructure. :ref:`NXmicrostructure_imm_config`, :ref:`NXmicrostructure_imm_results`: A specific example of an application definition for documenting the From 9510a0c61b47958394de6082181342a2accce8b5 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 11 Jul 2024 23:54:33 +0200 Subject: [PATCH 0811/1012] Finished NXmicrostructure_gragles_results --- .../NXmicrostructure.nxdl.xml | 1 + .../NXmicrostructure_gragles_results.nxdl.xml | 34 +++++++++++++++++++ .../nyaml/NXmicrostructure.yaml | 1 + .../NXmicrostructure_gragles_results.yaml | 22 ++++++++++++ 4 files changed, 58 insertions(+) diff --git a/contributed_definitions/NXmicrostructure.nxdl.xml b/contributed_definitions/NXmicrostructure.nxdl.xml index cceb923138..160247c02e 100644 --- a/contributed_definitions/NXmicrostructure.nxdl.xml +++ b/contributed_definitions/NXmicrostructure.nxdl.xml @@ -216,6 +216,7 @@ the idea is we may wish to run as many grain reconstructions as we want and add + + + + + + + + Set of pairs of crystal_identifier for each interface. + + + + + + + + + + Mobility times surface energy density of the interface normalized + to the maximum such product of the interface set. + + + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXmicrostructure.yaml b/contributed_definitions/nyaml/NXmicrostructure.yaml index 969c471cf7..2864729bed 100644 --- a/contributed_definitions/nyaml/NXmicrostructure.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure.yaml @@ -136,6 +136,7 @@ NXmicrostructure(NXobject): (NXcg_point_set): (NXcg_polyline_set): (NXcg_triangle_set): + (NXcg_polygon_set): (NXcg_polyhedron_set): # constructive solid geometry to describe curved features # (NXcsg): diff --git a/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml index 8049e31601..5bc4e986d5 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml @@ -8,6 +8,8 @@ symbols: The total number of summary statistic log entries. n_grains: | Number of grains in the computer simulation. + n_interfaces: | + Number of interfaces in the computer simulation. type: group NXmicrostructure_gragles_results(NXobject): (NXentry): @@ -157,3 +159,23 @@ NXmicrostructure_gragles_results(NXobject): dim: (n_grains,) volume(NX_NUMBER): dim: (n_grains,) + interface(NXobject): + exists: optional + representation(NX_CHAR): + exists: recommended + number_of_interfaces(NX_UINT): + identifier_offset(NX_INT): + crystal_identifier(NX_INT): + doc: | + Set of pairs of crystal_identifier for each interface. + unit: NX_UNITLESS + dim: (n_interfaces, 2) + \@use_these(NX_CHAR): # point to e.g /NXentry/OBJECT[spatiotemporalID]/MICROSTRUCTURE[microstructureID]/crystal/crystal_identifier + relative_mobility(NX_FLOAT): + doc: | + Mobility times surface energy density of the interface normalized + to the maximum such product of the interface set. + unit: NX_DIMENSIONLESS + dim: (n_interfaces,) + area(NX_NUMBER): + dim: (n_interfaces,) From 9fba7287a86bd9a175936a7213e8706db47d2b25 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 12 Jul 2024 14:07:22 +0200 Subject: [PATCH 0812/1012] Implemented suggestions from @lukaspie --- .../nyaml/NXcoordinate_system.yaml | 4 +- .../nyaml/NXcoordinate_system_set.yaml | 247 ++++++------------ 2 files changed, 83 insertions(+), 168 deletions(-) diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml index 9ebc18667f..c5f797ebc8 100644 --- a/contributed_definitions/nyaml/NXcoordinate_system.yaml +++ b/contributed_definitions/nyaml/NXcoordinate_system.yaml @@ -29,11 +29,11 @@ NXcoordinate_system(NXobject): type(NX_CHAR): doc: | Coordinate system type. - enumeration: [cartesian] + enumeration: [undefined, cartesian] handedness(NX_CHAR): doc: | Handedness of the coordinate system if it is a Cartesian. - enumeration: [right_handed, left_handed] + enumeration: [undefined, right_handed, left_handed] x_alias(NX_CHAR): doc: | Possibility to define an alias for the name of the x-axis. diff --git a/contributed_definitions/nyaml/NXcoordinate_system_set.yaml b/contributed_definitions/nyaml/NXcoordinate_system_set.yaml index 4ce364874f..1ba5337938 100644 --- a/contributed_definitions/nyaml/NXcoordinate_system_set.yaml +++ b/contributed_definitions/nyaml/NXcoordinate_system_set.yaml @@ -116,7 +116,9 @@ NXcoordinate_system_set(NXobject): DOI: 10.1088/0965-0393/23/8/083501. The most frequently used convention is ZXZ which is based on the work of H.-J. Bunge but other conventions are possible. - enumeration: [undefined, zxz] + Excluding undefined two groups are distinguished, proper Euler angles + and Tait-Bryan angles. + enumeration: [undefined, zxz, xyx, yzy, zyz, xzx, yxy, xyz, yzx, zxy, xzy,zyx, yxz] axis_angle_convention(NX_CHAR): doc: | To which angular range is the rotation angle argument of an @@ -131,216 +133,129 @@ NXcoordinate_system_set(NXobject): enumeration: [undefined, p_plus_one, p_minus_one] # possibility to add further coordinate systems (NXcoordinate_system): - # frequently used coordinate systems with frequently relevant specializations + # frequently used coordinate systems with frequently relevant specializations follow + # convention 1 of DOI: 10.1088/0965-0393/23/8/083501 is implemented by inheriting type from NXcoordinate_system processing_reference_frame(NXcoordinate_system): doc: | - Details about eventually relevant named directions that may - give reasons for anisotropies. The classical example is cold-rolling - where one has to specify which directions (rolling, transverse, and normal) - align how with the direction of the base vectors of the sample_reference_frame. - type(NX_CHAR): - doc: | - Type of coordinate system and reference frame according to - convention 1 of DOI: 10.1088/0965-0393/23/8/083501. - enumeration: [undefined, cartesian] - handedness(NX_CHAR): - doc: | - Handedness of coordinate system. - enumeration: [right_handed, left_handed] - origin(NX_CHAR): + Details about eventually relevant named directions that may give reasons for anisotropies. + The classical example is mechanical processing where one has to specify which directions + (e.g. rolling, transverse, and normal direction) align how with the direction of the base + vectors of the sample_reference_frame. + + Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the + base vectors of this coordinate system as Xp, Yp, Zp. + origin(NX_CHAR): # specialized the inherited concept origin from NXcoordinate_system doc: | Location of the origin of the processing_reference_frame. - This specifies the location Xp = 0, Yp = 0, Zp = 0. - Assume regions-of-interest in this reference frame form a - rectangle or cuboid. - Edges are interpreted by inspecting the direction of their - outer unit normals (which point either parallel or antiparallel) - along respective base vector direction of the reference frame. + + We assume regions-of-interest in this reference frame form a + rectangle or cuboid. Edges are interpreted by inspecting the + direction of their outer unit normals (which point either parallel + or antiparallel) along respective base vector direction of the + reference frame. enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] - x_alias(NX_CHAR): - doc: | - Name or alias assigned to the x-axis base vector, - e.g. rolling direction. x_direction(NX_CHAR): doc: | - Direction of the positively pointing x-axis base vector of - the processing_reference_frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. + Direction of the positively pointing x-axis base vector of the processing_reference_frame. + We assume the configuration is inspected by looking towards the sample surface. + If a detector is involved, we assume the configuration is inspected from a position + that is located behind that detector. enumeration: [undefined, north, east, south, west, in, out] - y_alias(NX_CHAR): - doc: | - Name or alias assigned to the y-axis base vector, - e.g. transverse direction. y_direction(NX_CHAR): doc: | - Direction of the positively pointing y-axis base vector of - the processing_reference_frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. + Direction of the positively pointing y-axis base vector of the processing_reference_frame. + We assume the configuration is inspected by looking towards the sample surface. + If a detector is involved, we assume the configuration is inspected from a position + that is located behind that detector. enumeration: [undefined, north, east, south, west, in, out] - z_alias(NX_CHAR): - doc: | - Name or alias assigned to the z-axis base vector, - e.g. normal direction. z_direction(NX_CHAR): doc: | - Direction of the positively pointing z-axis base vector of - the processing_reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. + Direction of the positively pointing z-axis base vector of the processing_reference_frame. + We assume the configuration is inspected by looking towards the sample surface. + If a detector is involved, we assume the configuration is inspected from a position + that is located behind that detector. enumeration: [undefined, north, east, south, west, in, out] sample_reference_frame(NXcoordinate_system): doc: | - Details about the sample/specimen reference frame. - type(NX_CHAR): + Details about the sample_reference_frame that is typically overlaid onto the surface of the sample. + We assume the configuration is inspected by looking towards the sample surface. If a detector + is involved, we assume the configuration is inspected from a position + that is located behind that detector. + + Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the + base vectors of this coordinate system as Xs, Ys, Zs. + depends_on: doc: | - Type of coordinate system and reference frame according to - convention 1 of DOI: 10.1088/0965-0393/23/8/083501. - The reference frame for the sample surface reference is used for - identifying positions on a (virtual) image which is formed by - information collected from an electron beam scanning the - sample surface. We assume the configuration is inspected by - looking towards the sample surface from a position that is - located behind the detector. - Reference DOI: 10.1016/j.matchar.2016.04.008 - The sample surface reference frame has coordinates Xs, Ys, Zs. - In three dimensions these coordinates are not necessarily - located on the surface of the sample as there are multiple - faces/sides of the sample. Most frequently though the coordinate - system here is used to define the surface which the electron - beam scans. - enumeration: [undefined, cartesian] - handedness(NX_CHAR): - doc: | - Handedness of the coordinate system if it is a Cartesian. - enumeration: [right_handed, left_handed] + Reference to the specifically named :ref:`NXsample` instance for + which these conventions apply (e.g. /entry1/sample1). origin(NX_CHAR): doc: | - Location of the origin of the sample surface reference frame. - This specifies the location Xs = 0, Ys = 0, Zs = 0. - Assume regions-of-interest in this reference frame form a - rectangle or cuboid. - Edges are interpreted by inspecting the direction of their - outer unit normals (which point either parallel or antiparallel) - along respective base vector direction of the reference frame. + Location of the origin of the sample_reference_frame. + + We assume regions-of-interest in this reference frame form a + rectangle or cuboid. Edges are interpreted by inspecting the + direction of their outer unit normals (which point either parallel + or antiparallel) along respective base vector direction of the + reference frame. enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] - x_alias(NX_CHAR): - doc: | - Name or alias assigned to the x-axis base vector, - e.g. longest edge. x_direction(NX_CHAR): doc: | - Direction of the positively pointing x-axis base vector of - the sample surface reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. + Direction of the positively pointing x-axis base vector of the sample_reference_frame. + We assume the configuration is inspected by looking towards the sample surface. + If a detector is involved, we assume the configuration is inspected from a position + that is located behind that detector. enumeration: [undefined, north, east, south, west, in, out] - y_alias(NX_CHAR): - doc: | - Name or alias assigned to the y-axis base vector, - e.g. long edge. y_direction(NX_CHAR): doc: | - Direction of the positively pointing y-axis base vector of - the sample surface reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. + Direction of the positively pointing y-axis base vector of the sample_reference_frame. + We assume the configuration is inspected by looking towards the sample surface. + If a detector is involved, we assume the configuration is inspected from a position + that is located behind that detector. enumeration: [undefined, north, east, south, west, in, out] - z_alias(NX_CHAR): - doc: | - Name or alias assigned to the z-axis base vector, - e.g. shortest edge. z_direction(NX_CHAR): doc: | - Direction of the positively pointing z-axis base vector of - the sample surface reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. + Direction of the positively pointing z-axis base vector of the sample_reference_frame. + We assume the configuration is inspected by looking towards the sample surface. + If a detector is involved, we assume the configuration is inspected from a position + that is located behind that detector. enumeration: [undefined, north, east, south, west, in, out] detector_reference_frameID(NXcoordinate_system): doc: | - Details about the detector reference frame for a specific detector. - \@detector: - type: NX_CHAR - doc: | - Reference to the specifically named :ref:`NXdetector` instance - for which these conventions in this :ref:`NXprocess` group apply - (e.g. /entry1/instrument/detector1). - type(NX_CHAR): - doc: | - Type of coordinate system/reference frame used for - identifying positions in detector space Xd, Yd, Zd, - according to DOI: 10.1016/j.matchar.2016.04.008. - enumeration: [undefined, cartesian] - handedness(NX_CHAR): + Details about the detector_reference_frame for a specific detector. + + Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the + base vectors of this coordinate system as Xd, Yd, Zd. + depends_on: doc: | - Handedness of the coordinate system if it is a Cartesian. - enumeration: [right_handed, left_handed] + Reference to the specifically named :ref:`NXdetector` instance for + which these conventions apply (e.g. /entry1/instrument/detector1). origin(NX_CHAR): doc: | - Where is the origin of the detector space reference - frame located. This is the location of Xd = 0, Yd = 0, Zd = 0. - Assume regions-of-interest in this reference frame form a - rectangle or cuboid. - Edges are interpreted by inspecting the direction of their - outer unit normals (which point either parallel or antiparallel) - along respective base vector direction of the reference frame. + Location of the origin of the detector_reference_frame. + + We assume regions-of-interest in this reference frame form a + rectangle or cuboid. Edges are interpreted by inspecting the + direction of their outer unit normals (which point either parallel + or antiparallel) along respective base vector direction of the + reference frame. enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] - x_alias(NX_CHAR): - doc: | - Name or alias assigned to the x-axis base vector, - e.g. longest edge as some landmark on the detector. x_direction(NX_CHAR): doc: | - Direction of the positively pointing x-axis base vector of - the detector space reference frame. We assume the configuration - is inspected by looking towards the sample surface from a + Direction of the positively pointing x-axis base vector of the detector_reference_frame. + We assume the configuration is inspected by looking towards the sample surface from a position that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. enumeration: [undefined, north, east, south, west, in, out] - y_alias(NX_CHAR): - doc: | - Name or alias assigned to the x-axis base vector, - e.g. long edge as some landmark on the detector. y_direction(NX_CHAR): doc: | - Direction of the positively pointing y-axis base vector of - the detector space reference frame. We assume the configuration - is inspected by looking towards the sample surface from a + Direction of the positively pointing y-axis base vector of the detector_reference_frame. + We assume the configuration is inspected by looking towards the sample surface from a position that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. enumeration: [undefined, north, east, south, west, in, out] - z_alias(NX_CHAR): - doc: | - Name or alias assigned to the x-axis base vector, - e.g. short edge as some landmark on the detector. z_direction(NX_CHAR): doc: | - Direction of the positively pointing z-axis base vector of - the detector space reference frame. We assume the configuration - is inspected by looking towards the sample surface from a + Direction of the positively pointing z-axis base vector of the detector_reference_frame. + We assume the configuration is inspected by looking towards the sample surface from a position that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. enumeration: [undefined, north, east, south, west, in, out] # conventions specific for certain methods - (NXcoordinate_system_em_ebsd): \ No newline at end of file + # (NXcoordinate_system_em_ebsd): \ No newline at end of file From cc18a27b3f3772e432e122269c1bf515aaf285ab Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 12 Jul 2024 14:09:41 +0200 Subject: [PATCH 0813/1012] nxdl --- .../NXcoordinate_system.nxdl.xml | 2 + .../NXcoordinate_system_set.nxdl.xml | 302 ++++++------------ 2 files changed, 93 insertions(+), 211 deletions(-) diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 89857ca599..1f8b4efeb5 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -56,6 +56,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d Coordinate system type. + @@ -64,6 +65,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d Handedness of the coordinate system if it is a Cartesian. + diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/contributed_definitions/NXcoordinate_system_set.nxdl.xml index c609e4ddc1..dc6d1c786e 100644 --- a/contributed_definitions/NXcoordinate_system_set.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system_set.nxdl.xml @@ -151,10 +151,23 @@ use depends_on field - not attribute - to point to conventions which in specific DOI: 10.1088/0965-0393/23/8/083501. The most frequently used convention is ZXZ which is based on the work of H.-J. Bunge but other conventions are possible. + Excluding undefined two groups are distinguished, proper Euler angles + and Tait-Bryan angles. + + + + + + + + + + + @@ -182,42 +195,27 @@ use depends_on field - not attribute - to point to conventions which in specific - + - Details about eventually relevant named directions that may - give reasons for anisotropies. The classical example is cold-rolling - where one has to specify which directions (rolling, transverse, and normal) - align how with the direction of the base vectors of the sample_reference_frame. + Details about eventually relevant named directions that may give reasons for anisotropies. + The classical example is mechanical processing where one has to specify which directions + (e.g. rolling, transverse, and normal direction) align how with the direction of the base + vectors of the sample_reference_frame. + + Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the + base vectors of this coordinate system as Xp, Yp, Zp. - - - Type of coordinate system and reference frame according to - convention 1 of DOI: 10.1088/0965-0393/23/8/083501. - - - - - - - - - Handedness of coordinate system. - - - - - - Location of the origin of the processing_reference_frame. - This specifies the location Xp = 0, Yp = 0, Zp = 0. - Assume regions-of-interest in this reference frame form a - rectangle or cuboid. - Edges are interpreted by inspecting the direction of their - outer unit normals (which point either parallel or antiparallel) - along respective base vector direction of the reference frame. + + We assume regions-of-interest in this reference frame form a + rectangle or cuboid. Edges are interpreted by inspecting the + direction of their outer unit normals (which point either parallel + or antiparallel) along respective base vector direction of the + reference frame. @@ -231,18 +229,12 @@ use depends_on field - not attribute - to point to conventions which in specific - - - Name or alias assigned to the x-axis base vector, - e.g. rolling direction. - - - Direction of the positively pointing x-axis base vector of - the processing_reference_frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. + Direction of the positively pointing x-axis base vector of the processing_reference_frame. + We assume the configuration is inspected by looking towards the sample surface. + If a detector is involved, we assume the configuration is inspected from a position + that is located behind that detector. @@ -254,19 +246,12 @@ use depends_on field - not attribute - to point to conventions which in specific - - - Name or alias assigned to the y-axis base vector, - e.g. transverse direction. - - - Direction of the positively pointing y-axis base vector of - the processing_reference_frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. + Direction of the positively pointing y-axis base vector of the processing_reference_frame. + We assume the configuration is inspected by looking towards the sample surface. + If a detector is involved, we assume the configuration is inspected from a position + that is located behind that detector. @@ -278,19 +263,12 @@ use depends_on field - not attribute - to point to conventions which in specific - - - Name or alias assigned to the z-axis base vector, - e.g. normal direction. - - - Direction of the positively pointing z-axis base vector of - the processing_reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. + Direction of the positively pointing z-axis base vector of the processing_reference_frame. + We assume the configuration is inspected by looking towards the sample surface. + If a detector is involved, we assume the configuration is inspected from a position + that is located behind that detector. @@ -305,49 +283,29 @@ use depends_on field - not attribute - to point to conventions which in specific - Details about the sample/specimen reference frame. + Details about the sample_reference_frame that is typically overlaid onto the surface of the sample. + We assume the configuration is inspected by looking towards the sample surface. If a detector + is involved, we assume the configuration is inspected from a position + that is located behind that detector. + + Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the + base vectors of this coordinate system as Xs, Ys, Zs. - - - Type of coordinate system and reference frame according to - convention 1 of DOI: 10.1088/0965-0393/23/8/083501. - The reference frame for the sample surface reference is used for - identifying positions on a (virtual) image which is formed by - information collected from an electron beam scanning the - sample surface. We assume the configuration is inspected by - looking towards the sample surface from a position that is - located behind the detector. - Reference DOI: 10.1016/j.matchar.2016.04.008 - The sample surface reference frame has coordinates Xs, Ys, Zs. - In three dimensions these coordinates are not necessarily - located on the surface of the sample as there are multiple - faces/sides of the sample. Most frequently though the coordinate - system here is used to define the surface which the electron - beam scans. - - - - - - - + - Handedness of the coordinate system if it is a Cartesian. + Reference to the specifically named :ref:`NXsample` instance for + which these conventions apply (e.g. /entry1/sample1). - - - - - Location of the origin of the sample surface reference frame. - This specifies the location Xs = 0, Ys = 0, Zs = 0. - Assume regions-of-interest in this reference frame form a - rectangle or cuboid. - Edges are interpreted by inspecting the direction of their - outer unit normals (which point either parallel or antiparallel) - along respective base vector direction of the reference frame. + Location of the origin of the sample_reference_frame. + + We assume regions-of-interest in this reference frame form a + rectangle or cuboid. Edges are interpreted by inspecting the + direction of their outer unit normals (which point either parallel + or antiparallel) along respective base vector direction of the + reference frame. @@ -361,25 +319,12 @@ use depends_on field - not attribute - to point to conventions which in specific - - - Name or alias assigned to the x-axis base vector, - e.g. longest edge. - - - Direction of the positively pointing x-axis base vector of - the sample surface reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. + Direction of the positively pointing x-axis base vector of the sample_reference_frame. + We assume the configuration is inspected by looking towards the sample surface. + If a detector is involved, we assume the configuration is inspected from a position + that is located behind that detector. @@ -391,19 +336,12 @@ use depends_on field - not attribute - to point to conventions which in specific - - - Name or alias assigned to the y-axis base vector, - e.g. long edge. - - - Direction of the positively pointing y-axis base vector of - the sample surface reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. + Direction of the positively pointing y-axis base vector of the sample_reference_frame. + We assume the configuration is inspected by looking towards the sample surface. + If a detector is involved, we assume the configuration is inspected from a position + that is located behind that detector. @@ -415,19 +353,12 @@ use depends_on field - not attribute - to point to conventions which in specific - - - Name or alias assigned to the z-axis base vector, - e.g. shortest edge. - - - Direction of the positively pointing z-axis base vector of - the sample surface reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. + Direction of the positively pointing z-axis base vector of the sample_reference_frame. + We assume the configuration is inspected by looking towards the sample surface. + If a detector is involved, we assume the configuration is inspected from a position + that is located behind that detector. @@ -442,44 +373,26 @@ use depends_on field - not attribute - to point to conventions which in specific - Details about the detector reference frame for a specific detector. + Details about the detector_reference_frame for a specific detector. + + Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the + base vectors of this coordinate system as Xd, Yd, Zd. - - - Reference to the specifically named :ref:`NXdetector` instance - for which these conventions in this :ref:`NXprocess` group apply - (e.g. /entry1/instrument/detector1). - - - - - Type of coordinate system/reference frame used for - identifying positions in detector space Xd, Yd, Zd, - according to DOI: 10.1016/j.matchar.2016.04.008. - - - - - - - + - Handedness of the coordinate system if it is a Cartesian. + Reference to the specifically named :ref:`NXdetector` instance for + which these conventions apply (e.g. /entry1/instrument/detector1). - - - - - Where is the origin of the detector space reference - frame located. This is the location of Xd = 0, Yd = 0, Zd = 0. - Assume regions-of-interest in this reference frame form a - rectangle or cuboid. - Edges are interpreted by inspecting the direction of their - outer unit normals (which point either parallel or antiparallel) - along respective base vector direction of the reference frame. + Location of the origin of the detector_reference_frame. + + We assume regions-of-interest in this reference frame form a + rectangle or cuboid. Edges are interpreted by inspecting the + direction of their outer unit normals (which point either parallel + or antiparallel) along respective base vector direction of the + reference frame. @@ -493,25 +406,11 @@ use depends_on field - not attribute - to point to conventions which in specific - - - Name or alias assigned to the x-axis base vector, - e.g. longest edge as some landmark on the detector. - - - Direction of the positively pointing x-axis base vector of - the detector space reference frame. We assume the configuration - is inspected by looking towards the sample surface from a + Direction of the positively pointing x-axis base vector of the detector_reference_frame. + We assume the configuration is inspected by looking towards the sample surface from a position that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. @@ -523,20 +422,11 @@ use depends_on field - not attribute - to point to conventions which in specific - - - Name or alias assigned to the x-axis base vector, - e.g. long edge as some landmark on the detector. - - - Direction of the positively pointing y-axis base vector of - the detector space reference frame. We assume the configuration - is inspected by looking towards the sample surface from a + Direction of the positively pointing y-axis base vector of the detector_reference_frame. + We assume the configuration is inspected by looking towards the sample surface from a position that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. @@ -548,20 +438,11 @@ use depends_on field - not attribute - to point to conventions which in specific - - - Name or alias assigned to the x-axis base vector, - e.g. short edge as some landmark on the detector. - - - Direction of the positively pointing z-axis base vector of - the detector space reference frame. We assume the configuration - is inspected by looking towards the sample surface from a + Direction of the positively pointing z-axis base vector of the detector_reference_frame. + We assume the configuration is inspected by looking towards the sample surface from a position that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. @@ -574,7 +455,6 @@ use depends_on field - not attribute - to point to conventions which in specific - - - + From a60bac2438f68cd485166907ff9a801f80969596 Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Mon, 15 Jul 2024 17:49:43 +0200 Subject: [PATCH 0814/1012] NXdata linking of signal (#205) * Add depends for data field * Use `@reference` * use reference attribute in NXmpes and NXmpes_arpes * change text style * fix duplicated in reference attribute --------- Co-authored-by: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> --- base_classes/NXdata.nxdl.xml | 82 +++++++---- base_classes/nyaml/NXdata.yaml | 74 ++++++---- contributed_definitions/NXdata_mpes.nxdl.xml | 14 +- contributed_definitions/NXmpes.nxdl.xml | 53 +++++-- contributed_definitions/NXmpes_arpes.nxdl.xml | 67 ++++----- .../nyaml/NXdata_mpes.yaml | 28 +++- contributed_definitions/nyaml/NXmpes.yaml | 104 ++++++++++---- .../nyaml/NXmpes_arpes.yaml | 131 ++++++++++-------- 8 files changed, 359 insertions(+), 194 deletions(-) diff --git a/base_classes/NXdata.nxdl.xml b/base_classes/NXdata.nxdl.xml index 408eb3a2e5..aaf7e2476b 100644 --- a/base_classes/NXdata.nxdl.xml +++ b/base_classes/NXdata.nxdl.xml @@ -235,6 +235,20 @@ without this attribute being set to "true".--> the axes attribute can be omitted. + + + Points to the path of a field defining the data to which the `DATA` group refers. + + This concept allows to link the data to a respective field in the NeXus hierarchy, thereby + defining the physical quantity it represents. + + Example: + If the data corresponds to a readout of a detector, ``@reference`` links + to that detectors data: + + @reference: '/entry/instrument/detector/data' for a 2D detector + + - - NXxrd_pan is a specialisation of NXxrd with exptra properties + NXxrd_pan is a specialisation of NXxrd with extra properties + for the PANalytical XRD data format. + + + Name of the data file. + + + + + Type of measurement. + + Official NeXus NXDL schema to which this file conforms. @@ -138,11 +145,11 @@ n_values - symbols beams information about the beam and the object encountered by beam through the path incident_beam(NXbeam): defracted_beam(NXbeam):--> - + Collect user inputs e.g. name or path of the input file. - + Starting value of the diffraction angle. @@ -176,16 +183,6 @@ defracted_beam(NXbeam):--> - - - Name of the data file. - - - - - Type of measurement. - - Beam attenuation factors over the path. @@ -212,7 +209,7 @@ defracted_beam(NXbeam):--> - + Desired plot would be two_theta vs intensity. @@ -292,11 +289,6 @@ defracted_beam(NXbeam):--> assumed name or given name. - - - - - diff --git a/contributed_definitions/nyaml/NXxrd_pan.yaml b/contributed_definitions/nyaml/NXxrd_pan.yaml index 8314a7f160..30aef1bf6c 100644 --- a/contributed_definitions/nyaml/NXxrd_pan.yaml +++ b/contributed_definitions/nyaml/NXxrd_pan.yaml @@ -1,12 +1,18 @@ category: application doc: | - NXxrd_pan is a specialisation of NXxrd with exptra properties -# n_values - symbols -# ! : additions -# ? : could or should be modified? + NXxrd_pan is a specialisation of NXxrd with extra properties + for the PANalytical XRD data format. + type: "group" NXxrd_pan(NXxrd): (NXentry): + data_file: + exists: optional + doc: | + Name of the data file. + measurement_type: + doc: | + Type of measurement. definition: doc: | Official NeXus NXDL schema to which this file conforms. @@ -76,11 +82,11 @@ NXxrd_pan(NXxrd): # beams information about the beam and the object encountered by beam through the path # incident_beam(NXbeam): # defracted_beam(NXbeam): - (NXcollection): + experiment_config(NXobject): exists: optional - doc: | + doc: | Collect user inputs e.g. name or path of the input file. - 2theta(NXcollection): + two_theta(NXobject): start(NX_FLOAT): unit: NX_ANGLE doc: | @@ -93,7 +99,7 @@ NXxrd_pan(NXxrd): unit: NX_ANGLE doc: | Minimum step size in-between two diffraction angles. - omega(NXcollection): + omega(NXobject): start(NX_FLOAT): unit: NX_ANGLE doc: | @@ -106,13 +112,6 @@ NXxrd_pan(NXxrd): unit: NX_ANGLE doc: | Minimum step size in the between two incident angles. - data_file: - exists: optional - doc: | - Name of the data file. - measurement_type: - doc: | - Type of measurement. beam_attenuation_factors: doc: | Beam attenuation factors over the path. @@ -135,7 +134,7 @@ NXxrd_pan(NXxrd): unit: NX_TIME doc: | Total time of count. - 2theta_plot(NXdata): + two_theta_plot(NXdata): doc: | Desired plot would be two_theta vs intensity. intensity(NX_FLOAT): @@ -194,5 +193,3 @@ NXxrd_pan(NXxrd): sample_name: doc: | Usually in xrd sample are being analysed, but sample might be identified by assumed name or given name. - prepared_by: - doc: | From 3e63e695089768db2383c3152a6e058c7081bdc3 Mon Sep 17 00:00:00 2001 From: Rubel Date: Mon, 22 Jul 2024 12:04:01 +0200 Subject: [PATCH 0817/1012] reproducibity check. --- contributed_definitions/NXxrd_pan.nxdl.xml | 2 +- contributed_definitions/nyaml/NXxrd_pan.yaml | 362 +++++++++++++++++-- 2 files changed, 332 insertions(+), 32 deletions(-) diff --git a/contributed_definitions/NXxrd_pan.nxdl.xml b/contributed_definitions/NXxrd_pan.nxdl.xml index 1b66bc0b11..5da5f97831 100644 --- a/contributed_definitions/NXxrd_pan.nxdl.xml +++ b/contributed_definitions/NXxrd_pan.nxdl.xml @@ -166,7 +166,7 @@ defracted_beam(NXbeam):--> - + Starting value of the incident angle. diff --git a/contributed_definitions/nyaml/NXxrd_pan.yaml b/contributed_definitions/nyaml/NXxrd_pan.yaml index 30aef1bf6c..16c71aa21a 100644 --- a/contributed_definitions/nyaml/NXxrd_pan.yaml +++ b/contributed_definitions/nyaml/NXxrd_pan.yaml @@ -1,9 +1,8 @@ category: application doc: | - NXxrd_pan is a specialisation of NXxrd with extra properties + NXxrd_pan is a specialisation of NXxrd with extra properties for the PANalytical XRD data format. - -type: "group" +type: group NXxrd_pan(NXxrd): (NXentry): data_file: @@ -18,12 +17,13 @@ NXxrd_pan(NXxrd): Official NeXus NXDL schema to which this file conforms. enumeration: [NXxrd_pan] method: - enumeration: [X-Ray Diffraction (XRD)] doc: | Method used to collect the data default='X-Ray Diffraction (XRD)' + enumeration: [X-Ray Diffraction (XRD)] (NXinstrument): - # Need a group that explain + + # Need a group that explain (NXsource): xray_tube_material: doc: | @@ -37,6 +37,7 @@ NXxrd_pan(NXxrd): unit: NX_VOLTAGE doc: | Voltage of the X-ray tube. + # Unicode for alpha : \u03b1 k_alpha_one(NX_FLOAT): unit: NX_WAVELENGTH @@ -57,7 +58,7 @@ NXxrd_pan(NXxrd): kbeta(NX_FLOAT): exists: optional unit: NX_WAVELENGTH - doc: | + doc: | Wavelength of the K\u00df line. \@units: enumeration: [angstrom] @@ -68,8 +69,8 @@ NXxrd_pan(NXxrd): Wavelength of the X-ray source. Used to convert from 2-theta to Q. (NXdetector): scan_axis: - doc: | - Axis scanned. + doc: | + Axis scanned. scan_mode: doc: | Mode of scan. @@ -78,6 +79,7 @@ NXxrd_pan(NXxrd): unit: NX_TIME doc: | Integration time per channel. + # Note: We should need to think about incident and deflected beam (NXbeam). As the data also contains # beams information about the beam and the object encountered by beam through the path # incident_beam(NXbeam): @@ -90,7 +92,7 @@ NXxrd_pan(NXxrd): start(NX_FLOAT): unit: NX_ANGLE doc: | - Starting value of the diffraction angle. + Starting value of the diffraction angle. end(NX_FLOAT): unit: NX_ANGLE doc: | @@ -103,7 +105,7 @@ NXxrd_pan(NXxrd): start(NX_FLOAT): unit: NX_ANGLE doc: | - Starting value of the incident angle. + Starting value of the incident angle. end(NX_FLOAT): unit: NX_ANGLE doc: | @@ -113,7 +115,7 @@ NXxrd_pan(NXxrd): doc: | Minimum step size in the between two incident angles. beam_attenuation_factors: - doc: | + doc: | Beam attenuation factors over the path. goniometer_x(NX_FLOAT): exists: optional @@ -131,55 +133,55 @@ NXxrd_pan(NXxrd): doc: | Goniometer position Z count_time(NX_FLOAT): - unit: NX_TIME + unit: NX_TIME doc: | Total time of count. two_theta_plot(NXdata): - doc: | - Desired plot would be two_theta vs intensity. + doc: | + Desired plot would be two_theta vs intensity. intensity(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, nDet]] doc: | Number of scattered electrons per unit time. - two_theta(NX_FLOAT): dimensions: rank: 1 - dim: [[1, nDet]] + dim: (nDet,) + two_theta(NX_FLOAT): doc: | - Axis scale represeting the 2-theta range of the difractogram. - omega(NX_FLOAT): + Axis scale represeting the 2-theta range of the difractogram. dimensions: rank: 1 - dim: [[1, nDet]] + dim: (nDet,) + omega(NX_FLOAT): exists: optional doc: | The omega range of the difractogram. - phi(NX_FLOAT): dimensions: rank: 1 - dim: [[1, nDet]] + dim: (nDet,) + phi(NX_FLOAT): exists: optional doc: | The phi range of the difractogram - chi(NX_FLOAT): dimensions: rank: 1 - dim: [[1, nDet]] + dim: (nDet,) + chi(NX_FLOAT): exists: optional doc: | The chi range of the difractogram + dimensions: + rank: 1 + dim: (nDet,) q_plot(NXdata): exists: optional doc: | Desired plot would be q_vector vs intensity. q(NX_FLOAT): - doc: | + doc: | Axis scale representing wavevector for scatter energy. intensity(NX_FLOAT): - doc: | - Number of scattered electrons per unit time. + doc: | + Number of scattered electrons per unit time. (NXsample): exists: optional doc: | @@ -190,6 +192,304 @@ NXxrd_pan(NXxrd): sample_id: doc: | Id of sample. - sample_name: + sample_name: doc: | - Usually in xrd sample are being analysed, but sample might be identified by assumed name or given name. + Usually in xrd sample are being analysed, but sample might be identified by + assumed name or given name. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 26a7372651ba3ec8be938e09c1b54c9af5c6d031dc2cca78a9f4a39d3231f7ea +# +# +# +# +# +# NXxrd_pan is a specialisation of NXxrd with extra properties +# for the PANalytical XRD data format. +# +# +# +# +# Name of the data file. +# +# +# +# +# Type of measurement. +# +# +# +# +# Official NeXus NXDL schema to which this file conforms. +# +# +# +# +# +# +# +# Method used to collect the data +# default='X-Ray Diffraction (XRD)' +# +# +# +# +# +# +# +# +# +# +# Type of the X-ray tube. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Current of the X-ray tube. +# +# +# +# +# Voltage of the X-ray tube. +# +# +# +# +# +# Wavelength of the K\u03b1 1 line. +# +# +# +# +# +# +# +# +# +# Wavelength of the K\u03b1 2 line. +# +# +# +# +# +# +# +# +# +# K\u03b1 2/K\u03b1 1 intensity ratio. +# +# +# +# +# Wavelength of the K\u00df line. +# +# +# +# +# +# +# +# +# +# Wavelength of the X-ray source. Used to convert from 2-theta to Q. +# +# +# +# +# +# +# Axis scanned. +# +# +# +# +# Mode of scan. +# +# +# +# +# Integration time per channel. +# +# +# +# +# +# +# +# Collect user inputs e.g. name or path of the input file. +# +# +# +# +# Starting value of the diffraction angle. +# +# +# +# +# Ending value of the diffraction angle. +# +# +# +# +# Minimum step size in-between two diffraction angles. +# +# +# +# +# +# +# Starting value of the incident angle. +# +# +# +# +# Ending value of the incident angle. +# +# +# +# +# Minimum step size in the between two incident angles. +# +# +# +# +# +# Beam attenuation factors over the path. +# +# +# +# +# Goniometer position X. +# +# +# +# +# Goniometer position Y. +# +# +# +# +# Goniometer position Z +# +# +# +# +# Total time of count. +# +# +# +# +# +# Desired plot would be two_theta vs intensity. +# +# +# +# Number of scattered electrons per unit time. +# +# +# +# +# +# +# +# Axis scale represeting the 2-theta range of the difractogram. +# +# +# +# +# +# +# +# The omega range of the difractogram. +# +# +# +# +# +# +# +# The phi range of the difractogram +# +# +# +# +# +# +# +# The chi range of the difractogram +# +# +# +# +# +# +# +# +# Desired plot would be q_vector vs intensity. +# +# +# +# Axis scale representing wavevector for scatter energy. +# +# +# +# +# Number of scattered electrons per unit time. +# +# +# +# +# +# Description on sample. +# +# +# +# Mode of sample. +# +# +# +# +# Id of sample. +# +# +# +# +# Usually in xrd sample are being analysed, but sample might be identified by +# assumed name or given name. +# +# +# +# +# From 9a9c00604a2582df150b6d97bfb2460c98ccd7ab Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 23 Jul 2024 19:30:38 +0200 Subject: [PATCH 0818/1012] add radius to NXenergydispersion --- .../NXenergydispersion.nxdl.xml | 5 ++ contributed_definitions/NXxps.nxdl.xml | 2 +- .../nyaml/NXenergydispersion.yaml | 56 ++++++++++--------- contributed_definitions/nyaml/NXxps.yaml | 6 +- 4 files changed, 38 insertions(+), 31 deletions(-) diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml index 45c62f4ac6..8728f730ca 100644 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ b/contributed_definitions/NXenergydispersion.nxdl.xml @@ -72,6 +72,11 @@ Diameter of the dispersive orbit + + + Radius of the dispersive orbit + + Way of scanning the energy axis diff --git a/contributed_definitions/NXxps.nxdl.xml b/contributed_definitions/NXxps.nxdl.xml index 89ab1904ef..de4e591852 100644 --- a/contributed_definitions/NXxps.nxdl.xml +++ b/contributed_definitions/NXxps.nxdl.xml @@ -203,7 +203,7 @@ - + diff --git a/contributed_definitions/nyaml/NXenergydispersion.yaml b/contributed_definitions/nyaml/NXenergydispersion.yaml index 647f243e6e..a614ecc1a1 100644 --- a/contributed_definitions/nyaml/NXenergydispersion.yaml +++ b/contributed_definitions/nyaml/NXenergydispersion.yaml @@ -44,6 +44,10 @@ NXenergydispersion(NXobject): unit: NX_LENGTH doc: | Diameter of the dispersive orbit + radius(NX_FLOAT): + unit: NX_LENGTH + doc: | + Radius of the dispersive orbit energy_scan_mode(NX_CHAR): doc: | Way of scanning the energy axis @@ -90,10 +94,10 @@ NXenergydispersion(NXobject): specified time. This mode is particulary useful during setup or alignment of the electron analyzer, for analysis of stability of the excitation source or for sample alignment. - + Since the mode measures intensity as a function of time, the difference in channel signals is not of interest. Therefore, the signals from all channels are summed. - + Synonyms: FE mode snapshot: doc: | @@ -153,13 +157,13 @@ NXenergydispersion(NXobject): for a summary of the discussion. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e89833fc28b832f73564da2bfcea931ca31dbf1e6723fdadc68eeb38eb667ec8 +# 452a3427a6f6f009c7bab95daa4446fc74167c9d4ef6aad50811eee8e5c41ea5 # # # - NXxrd_pan is a specialisation of NXxrd with extra properties + NXxrd_pan is a specialisation of NXxrd with extra properties for the PANalytical XRD data format. @@ -209,9 +209,10 @@ defracted_beam(NXbeam):--> - + - Desired plot would be two_theta vs intensity. + All experiment results data such as scattering angle (2theta), + intensity, incident angle, scattering vector, etc will be stored here. @@ -221,51 +222,91 @@ defracted_beam(NXbeam):--> - + - Axis scale represeting the 2-theta range of the difractogram. + Two-theta (scattering angle) of the diffractogram. - + - The omega range of the difractogram. + Incident angle of the diffractogram. - + - The phi range of the difractogram + The phi range of the diffractogram. - + - The chi range of the difractogram + The chi range of the diffractogram + + + The scattering vector component, which is parallel to the sample surface. + + + + + The scattering vector component, which is perpendicular to the sample surface. + + + + + The norm value of the scattering vector, q. The scattering vector is defined as a + difference between the incident and scattered wave vectors. + For details: https://en.wikipedia.org/wiki/Powder_diffraction + and https://theory.labster.com/scattering-vector/ + + - + - Desired plot would be q_vector vs intensity. + The desired view for scattering vectors. - + - Axis scale representing wavevector for scatter energy. + This concept corresponds to the norm value of the scattering vector(q). + The concept is the same as 'q_norm' of 'experiment_result' + and should be linked to /entry[ENTRY]/experiment_result/q_norm. - + - Number of scattered electrons per unit time. + Number of scattered electrons per unit time at each scattering vector (q) value. + The concept is the same as the 'intensity' of experiment_result + and should be linked to /entry[ENTRY]/experiment_result/intensity. + + + + + The scattering vector (q) component, which is parallel to the sample surface. + This component is used in the Reciprocal Space Mapping (RSM) technique of + X-ray diffraction method. + + The concept is the same as 'q_parallel' of experiment_result, + and should be linked to /entry[ENTRY]/experiment_result/q_parallel. + + + + + The scattering vector component, which is perpendicular to the sample surface. + + The concept is the same as 'q_perpendicular' of experiment_result, + and should be linked to /entry[ENTRY]/experiment_result/q_perpendicular. diff --git a/contributed_definitions/nyaml/NXxrd_pan.yaml b/contributed_definitions/nyaml/NXxrd_pan.yaml index 16c71aa21a..5f0394d9fa 100644 --- a/contributed_definitions/nyaml/NXxrd_pan.yaml +++ b/contributed_definitions/nyaml/NXxrd_pan.yaml @@ -136,9 +136,10 @@ NXxrd_pan(NXxrd): unit: NX_TIME doc: | Total time of count. - two_theta_plot(NXdata): + experiment_result(NXdata): doc: | - Desired plot would be two_theta vs intensity. + All experiment results data such as scattering angle (2theta), + intensity, incident angle, scattering vector, etc will be stored here. intensity(NX_FLOAT): doc: | Number of scattered electrons per unit time. @@ -146,42 +147,86 @@ NXxrd_pan(NXxrd): rank: 1 dim: (nDet,) two_theta(NX_FLOAT): + unit: NX_ANGLE doc: | - Axis scale represeting the 2-theta range of the difractogram. + Two-theta (scattering angle) of the diffractogram. dimensions: rank: 1 dim: (nDet,) omega(NX_FLOAT): exists: optional + unit: NX_ANGLE doc: | - The omega range of the difractogram. + Incident angle of the diffractogram. dimensions: rank: 1 dim: (nDet,) phi(NX_FLOAT): exists: optional + unit: NX_ANGLE doc: | - The phi range of the difractogram + The phi range of the diffractogram. dimensions: rank: 1 dim: (nDet,) chi(NX_FLOAT): exists: optional + unit: NX_ANGLE doc: | - The chi range of the difractogram + The chi range of the diffractogram dimensions: rank: 1 dim: (nDet,) - q_plot(NXdata): + q_parallel(NX_FLOAT): + exists: optional + unit: NX_ANY + doc: | + The scattering vector component, which is parallel to the sample surface. + q_perpendicular(NX_FLOAT): + exists: optional + unit: NX_ANY + doc: | + The scattering vector component, which is perpendicular to the sample surface. + q_norm(NX_FLOAT): + exists: optional + unit: NX_ANY + doc: | + The norm value of the scattering vector, q. The scattering vector is defined as a + difference between the incident and scattered wave vectors. + For details: https://en.wikipedia.org/wiki/Powder_diffraction + and https://theory.labster.com/scattering-vector/ + q_data(NXdata): exists: optional doc: | - Desired plot would be q_vector vs intensity. + The desired view for scattering vectors. q(NX_FLOAT): + exists: optional doc: | - Axis scale representing wavevector for scatter energy. + This concept corresponds to the norm value of the scattering vector(q). + The concept is the same as 'q_norm' of 'experiment_result' + and should be linked to /entry[ENTRY]/experiment_result/q_norm. intensity(NX_FLOAT): + exists: optional doc: | - Number of scattered electrons per unit time. + Number of scattered electrons per unit time at each scattering vector (q) value. + The concept is the same as the 'intensity' of experiment_result + and should be linked to /entry[ENTRY]/experiment_result/intensity. + q_parallel(NX_FLOAT): + exists: optional + doc: | + The scattering vector (q) component, which is parallel to the sample surface. + This component is used in the Reciprocal Space Mapping (RSM) technique of + X-ray diffraction method. + + The concept is the same as 'q_parallel' of experiment_result, + and should be linked to /entry[ENTRY]/experiment_result/q_parallel. + q_perpendicular(NX_FLOAT): + exists: optional + doc: | + The scattering vector component, which is perpendicular to the sample surface. + + The concept is the same as 'q_perpendicular' of experiment_result, + and should be linked to /entry[ENTRY]/experiment_result/q_perpendicular. (NXsample): exists: optional doc: | @@ -198,7 +243,7 @@ NXxrd_pan(NXxrd): assumed name or given name. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 26a7372651ba3ec8be938e09c1b54c9af5c6d031dc2cca78a9f4a39d3231f7ea +# ea24fb9f19ac04432bece15f366c44f2c370632bdcbea76b916920013d4e6c11 # # # # # -# NXxrd_pan is a specialisation of NXxrd with extra properties +# NXxrd_pan is a specialisation of NXxrd with extra properties # for the PANalytical XRD data format. # # @@ -410,9 +455,10 @@ NXxrd_pan(NXxrd): # # # -# +# # -# Desired plot would be two_theta vs intensity. +# All experiment results data such as scattering angle (2theta), +# intensity, incident angle, scattering vector, etc will be stored here. # # # @@ -422,51 +468,91 @@ NXxrd_pan(NXxrd): # # # -# +# # -# Axis scale represeting the 2-theta range of the difractogram. +# Two-theta (scattering angle) of the diffractogram. # # # # # -# +# # -# The omega range of the difractogram. +# Incident angle of the diffractogram. # # # # # -# +# # -# The phi range of the difractogram +# The phi range of the diffractogram. # # # # # -# +# # -# The chi range of the difractogram +# The chi range of the diffractogram # # # # # +# +# +# The scattering vector component, which is parallel to the sample surface. +# +# +# +# +# The scattering vector component, which is perpendicular to the sample surface. +# +# +# +# +# The norm value of the scattering vector, q. The scattering vector is defined as a +# difference between the incident and scattered wave vectors. +# For details: https://en.wikipedia.org/wiki/Powder_diffraction +# and https://theory.labster.com/scattering-vector/ +# +# # -# +# # -# Desired plot would be q_vector vs intensity. +# The desired view for scattering vectors. # -# +# # -# Axis scale representing wavevector for scatter energy. +# This concept corresponds to the norm value of the scattering vector(q). +# The concept is the same as 'q_norm' of 'experiment_result' +# and should be linked to /entry[ENTRY]/experiment_result/q_norm. # # -# +# # -# Number of scattered electrons per unit time. +# Number of scattered electrons per unit time at each scattering vector (q) value. +# The concept is the same as the 'intensity' of experiment_result +# and should be linked to /entry[ENTRY]/experiment_result/intensity. +# +# +# +# +# The scattering vector (q) component, which is parallel to the sample surface. +# This component is used in the Reciprocal Space Mapping (RSM) technique of +# X-ray diffraction method. +# +# The concept is the same as 'q_parallel' of experiment_result, +# and should be linked to /entry[ENTRY]/experiment_result/q_parallel. +# +# +# +# +# The scattering vector component, which is perpendicular to the sample surface. +# +# The concept is the same as 'q_perpendicular' of experiment_result, +# and should be linked to /entry[ENTRY]/experiment_result/q_perpendicular. # # # From be26bdf42d9c4a0ca5f5180a269dc22140626a7b Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 30 Jul 2024 11:23:57 +0200 Subject: [PATCH 0820/1012] Implementing suggestions from lukaspie --- .../NXcoordinate_system_set.nxdl.xml | 123 +++++++++--------- .../nyaml/NXcoordinate_system_set.yaml | 96 ++++++-------- .../contributed_definitions/em-structure.rst | 3 - 3 files changed, 100 insertions(+), 122 deletions(-) diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/contributed_definitions/NXcoordinate_system_set.nxdl.xml index dc6d1c786e..d75bebe7d0 100644 --- a/contributed_definitions/NXcoordinate_system_set.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system_set.nxdl.xml @@ -23,10 +23,7 @@ --> +use depends_on field - not attribute - to point to conventions used--> Base class to hold different coordinate systems and representation conversions. @@ -146,13 +143,12 @@ use depends_on field - not attribute - to point to conventions which in specific - How are Euler angles interpreted given that there are several - choices (e.g. ZXZ, XYZ, etc.) according to convention 4 of - DOI: 10.1088/0965-0393/23/8/083501. - The most frequently used convention is ZXZ which is based on - the work of H.-J. Bunge but other conventions are possible. - Excluding undefined two groups are distinguished, proper Euler angles - and Tait-Bryan angles. + How are Euler angles interpreted given that there are several choices (e.g. zxz, xyz) + according to convention 4 of DOI: 10.1088/0965-0393/23/8/083501. + + The most frequently used convention is zxz, which is based on the work of H.-J. Bunge + but other conventions are possible. Apart from undefined, proper Euler angles + are distinguished from (improper) Tait-Bryan angles. @@ -204,6 +200,12 @@ convention 1 of DOI: 10.1088/0965-0393/23/8/083501 is implemented by inheriting (e.g. rolling, transverse, and normal direction) align how with the direction of the base vectors of the sample_reference_frame. + It is assumed that the configuration is inspected by looking towards the sample surface. + If a detector is involved, it is assumed that the configuration is inspected from a position + that is located behind this detector. + + If any of these assumptions is not met, the user is required to explicitly state this. + Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the base vectors of this coordinate system as Xp, Yp, Zp. @@ -211,11 +213,12 @@ convention 1 of DOI: 10.1088/0965-0393/23/8/083501 is implemented by inheriting Location of the origin of the processing_reference_frame. - We assume regions-of-interest in this reference frame form a - rectangle or cuboid. Edges are interpreted by inspecting the - direction of their outer unit normals (which point either parallel - or antiparallel) along respective base vector direction of the - reference frame. + It is assumed that regions-of-interest in this reference frame form a rectangle or cuboid. + Edges are interpreted by inspecting the direction of their outer unit normals + (which point either parallel or antiparallel) along respective base vector direction + of the reference frame. + + If any of these assumptions is not met, the user is required to explicitly state this. @@ -231,10 +234,8 @@ convention 1 of DOI: 10.1088/0965-0393/23/8/083501 is implemented by inheriting - Direction of the positively pointing x-axis base vector of the processing_reference_frame. - We assume the configuration is inspected by looking towards the sample surface. - If a detector is involved, we assume the configuration is inspected from a position - that is located behind that detector. + Direction of the positively pointing x-axis base vector of the + processing_reference_frame. @@ -248,10 +249,8 @@ convention 1 of DOI: 10.1088/0965-0393/23/8/083501 is implemented by inheriting - Direction of the positively pointing y-axis base vector of the processing_reference_frame. - We assume the configuration is inspected by looking towards the sample surface. - If a detector is involved, we assume the configuration is inspected from a position - that is located behind that detector. + Direction of the positively pointing y-axis base vector of the + processing_reference_frame. @@ -265,10 +264,8 @@ convention 1 of DOI: 10.1088/0965-0393/23/8/083501 is implemented by inheriting - Direction of the positively pointing z-axis base vector of the processing_reference_frame. - We assume the configuration is inspected by looking towards the sample surface. - If a detector is involved, we assume the configuration is inspected from a position - that is located behind that detector. + Direction of the positively pointing z-axis base vector of the + processing_reference_frame. @@ -284,9 +281,12 @@ convention 1 of DOI: 10.1088/0965-0393/23/8/083501 is implemented by inheriting Details about the sample_reference_frame that is typically overlaid onto the surface of the sample. - We assume the configuration is inspected by looking towards the sample surface. If a detector - is involved, we assume the configuration is inspected from a position - that is located behind that detector. + + It is assumed that the configuration is inspected by looking towards the sample surface. + If a detector is involved, it is assumed that the configuration is inspected from a position + that is located behind this detector. + + If any of these assumptions is not met, the user is required to explicitly state this. Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the base vectors of this coordinate system as Xs, Ys, Zs. @@ -301,11 +301,12 @@ convention 1 of DOI: 10.1088/0965-0393/23/8/083501 is implemented by inheriting Location of the origin of the sample_reference_frame. - We assume regions-of-interest in this reference frame form a - rectangle or cuboid. Edges are interpreted by inspecting the - direction of their outer unit normals (which point either parallel - or antiparallel) along respective base vector direction of the - reference frame. + It is assumed that regions-of-interest in this reference frame form a rectangle or cuboid. + Edges are interpreted by inspecting the direction of their outer unit normals + (which point either parallel or antiparallel) along respective base vector direction + of the reference frame. + + If any of these assumptions is not met, the user is required to explicitly state this. @@ -321,10 +322,8 @@ convention 1 of DOI: 10.1088/0965-0393/23/8/083501 is implemented by inheriting - Direction of the positively pointing x-axis base vector of the sample_reference_frame. - We assume the configuration is inspected by looking towards the sample surface. - If a detector is involved, we assume the configuration is inspected from a position - that is located behind that detector. + Direction of the positively pointing x-axis base vector of the + sample_reference_frame. @@ -338,10 +337,8 @@ convention 1 of DOI: 10.1088/0965-0393/23/8/083501 is implemented by inheriting - Direction of the positively pointing y-axis base vector of the sample_reference_frame. - We assume the configuration is inspected by looking towards the sample surface. - If a detector is involved, we assume the configuration is inspected from a position - that is located behind that detector. + Direction of the positively pointing y-axis base vector of the + sample_reference_frame. @@ -355,10 +352,8 @@ convention 1 of DOI: 10.1088/0965-0393/23/8/083501 is implemented by inheriting - Direction of the positively pointing z-axis base vector of the sample_reference_frame. - We assume the configuration is inspected by looking towards the sample surface. - If a detector is involved, we assume the configuration is inspected from a position - that is located behind that detector. + Direction of the positively pointing z-axis base vector of the + sample_reference_frame. @@ -377,6 +372,11 @@ convention 1 of DOI: 10.1088/0965-0393/23/8/083501 is implemented by inheriting Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the base vectors of this coordinate system as Xd, Yd, Zd. + + It is assumed that the configuration is inspected by looking towards the sample surface + from a position that is located behind the detector. + + If any of these assumptions is not met, the user is required to explicitly state this. @@ -388,11 +388,11 @@ convention 1 of DOI: 10.1088/0965-0393/23/8/083501 is implemented by inheriting Location of the origin of the detector_reference_frame. - We assume regions-of-interest in this reference frame form a - rectangle or cuboid. Edges are interpreted by inspecting the - direction of their outer unit normals (which point either parallel - or antiparallel) along respective base vector direction of the - reference frame. + If the regions-of-interest forms a rectangle or cuboid, it is assumed that edges are interpreted + by inspecting the direction of their outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + + If any of these assumptions is not met, the user is required to explicitly state this. @@ -408,9 +408,8 @@ convention 1 of DOI: 10.1088/0965-0393/23/8/083501 is implemented by inheriting - Direction of the positively pointing x-axis base vector of the detector_reference_frame. - We assume the configuration is inspected by looking towards the sample surface from a - position that is located behind the detector. + Direction of the positively pointing x-axis base vector of the + detector_reference_frame. @@ -424,9 +423,8 @@ convention 1 of DOI: 10.1088/0965-0393/23/8/083501 is implemented by inheriting - Direction of the positively pointing y-axis base vector of the detector_reference_frame. - We assume the configuration is inspected by looking towards the sample surface from a - position that is located behind the detector. + Direction of the positively pointing y-axis base vector of the + detector_reference_frame. @@ -440,9 +438,8 @@ convention 1 of DOI: 10.1088/0965-0393/23/8/083501 is implemented by inheriting - Direction of the positively pointing z-axis base vector of the detector_reference_frame. - We assume the configuration is inspected by looking towards the sample surface from a - position that is located behind the detector. + Direction of the positively pointing z-axis base vector of the + detector_reference_frame. @@ -455,6 +452,4 @@ convention 1 of DOI: 10.1088/0965-0393/23/8/083501 is implemented by inheriting - diff --git a/contributed_definitions/nyaml/NXcoordinate_system_set.yaml b/contributed_definitions/nyaml/NXcoordinate_system_set.yaml index 1ba5337938..7fd822e5f5 100644 --- a/contributed_definitions/nyaml/NXcoordinate_system_set.yaml +++ b/contributed_definitions/nyaml/NXcoordinate_system_set.yaml @@ -89,10 +89,7 @@ doc: | one refers to. type: group # express conventions explicitly and understandable -# appdefs each instance of NXentry should have its own set of conventions -# method-specific additional conventions on top of the ones formulated here -# should go to method-specific base classes like NXcoordinate_system_em_ebsd -# use depends_on field - not attribute - to point to conventions which in specific cases +# use depends_on field - not attribute - to point to conventions used NXcoordinate_system_set(NXobject): rotation_handedness(NX_CHAR): doc: | @@ -111,13 +108,12 @@ NXcoordinate_system_set(NXobject): enumeration: [undefined, passive, active] euler_angle_convention(NX_CHAR): doc: | - How are Euler angles interpreted given that there are several - choices (e.g. ZXZ, XYZ, etc.) according to convention 4 of - DOI: 10.1088/0965-0393/23/8/083501. - The most frequently used convention is ZXZ which is based on - the work of H.-J. Bunge but other conventions are possible. - Excluding undefined two groups are distinguished, proper Euler angles - and Tait-Bryan angles. + How are Euler angles interpreted given that there are several choices (e.g. zxz, xyz) + according to convention 4 of DOI: 10.1088/0965-0393/23/8/083501. + + The most frequently used convention is zxz, which is based on the work of H.-J. Bunge + but other conventions are possible. Apart from undefined, proper Euler angles + are distinguished from (improper) Tait-Bryan angles. enumeration: [undefined, zxz, xyx, yzy, zyz, xzx, yxy, xyz, yzx, zxy, xzy,zyx, yxz] axis_angle_convention(NX_CHAR): doc: | @@ -142,45 +138,46 @@ NXcoordinate_system_set(NXobject): (e.g. rolling, transverse, and normal direction) align how with the direction of the base vectors of the sample_reference_frame. + It is assumed that the configuration is inspected by looking towards the sample surface. + If a detector is involved, it is assumed that the configuration is inspected from a position + that is located behind this detector. + + If any of these assumptions is not met, the user is required to explicitly state this. + Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the base vectors of this coordinate system as Xp, Yp, Zp. origin(NX_CHAR): # specialized the inherited concept origin from NXcoordinate_system doc: | Location of the origin of the processing_reference_frame. - We assume regions-of-interest in this reference frame form a - rectangle or cuboid. Edges are interpreted by inspecting the - direction of their outer unit normals (which point either parallel - or antiparallel) along respective base vector direction of the - reference frame. + It is assumed that regions-of-interest in this reference frame form a rectangle or cuboid. + Edges are interpreted by inspecting the direction of their outer unit normals + (which point either parallel or antiparallel) along respective base vector direction + of the reference frame. + + If any of these assumptions is not met, the user is required to explicitly state this. enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] x_direction(NX_CHAR): doc: | Direction of the positively pointing x-axis base vector of the processing_reference_frame. - We assume the configuration is inspected by looking towards the sample surface. - If a detector is involved, we assume the configuration is inspected from a position - that is located behind that detector. enumeration: [undefined, north, east, south, west, in, out] y_direction(NX_CHAR): doc: | Direction of the positively pointing y-axis base vector of the processing_reference_frame. - We assume the configuration is inspected by looking towards the sample surface. - If a detector is involved, we assume the configuration is inspected from a position - that is located behind that detector. enumeration: [undefined, north, east, south, west, in, out] z_direction(NX_CHAR): doc: | Direction of the positively pointing z-axis base vector of the processing_reference_frame. - We assume the configuration is inspected by looking towards the sample surface. - If a detector is involved, we assume the configuration is inspected from a position - that is located behind that detector. enumeration: [undefined, north, east, south, west, in, out] sample_reference_frame(NXcoordinate_system): doc: | Details about the sample_reference_frame that is typically overlaid onto the surface of the sample. - We assume the configuration is inspected by looking towards the sample surface. If a detector - is involved, we assume the configuration is inspected from a position - that is located behind that detector. + + It is assumed that the configuration is inspected by looking towards the sample surface. + If a detector is involved, it is assumed that the configuration is inspected from a position + that is located behind this detector. + + If any of these assumptions is not met, the user is required to explicitly state this. Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the base vectors of this coordinate system as Xs, Ys, Zs. @@ -192,32 +189,24 @@ NXcoordinate_system_set(NXobject): doc: | Location of the origin of the sample_reference_frame. - We assume regions-of-interest in this reference frame form a - rectangle or cuboid. Edges are interpreted by inspecting the - direction of their outer unit normals (which point either parallel - or antiparallel) along respective base vector direction of the - reference frame. + It is assumed that regions-of-interest in this reference frame form a rectangle or cuboid. + Edges are interpreted by inspecting the direction of their outer unit normals + (which point either parallel or antiparallel) along respective base vector direction + of the reference frame. + + If any of these assumptions is not met, the user is required to explicitly state this. enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] x_direction(NX_CHAR): doc: | Direction of the positively pointing x-axis base vector of the sample_reference_frame. - We assume the configuration is inspected by looking towards the sample surface. - If a detector is involved, we assume the configuration is inspected from a position - that is located behind that detector. enumeration: [undefined, north, east, south, west, in, out] y_direction(NX_CHAR): doc: | Direction of the positively pointing y-axis base vector of the sample_reference_frame. - We assume the configuration is inspected by looking towards the sample surface. - If a detector is involved, we assume the configuration is inspected from a position - that is located behind that detector. enumeration: [undefined, north, east, south, west, in, out] z_direction(NX_CHAR): doc: | Direction of the positively pointing z-axis base vector of the sample_reference_frame. - We assume the configuration is inspected by looking towards the sample surface. - If a detector is involved, we assume the configuration is inspected from a position - that is located behind that detector. enumeration: [undefined, north, east, south, west, in, out] detector_reference_frameID(NXcoordinate_system): doc: | @@ -225,6 +214,11 @@ NXcoordinate_system_set(NXobject): Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the base vectors of this coordinate system as Xd, Yd, Zd. + + It is assumed that the configuration is inspected by looking towards the sample surface + from a position that is located behind the detector. + + If any of these assumptions is not met, the user is required to explicitly state this. depends_on: doc: | Reference to the specifically named :ref:`NXdetector` instance for @@ -233,29 +227,21 @@ NXcoordinate_system_set(NXobject): doc: | Location of the origin of the detector_reference_frame. - We assume regions-of-interest in this reference frame form a - rectangle or cuboid. Edges are interpreted by inspecting the - direction of their outer unit normals (which point either parallel - or antiparallel) along respective base vector direction of the - reference frame. + If the regions-of-interest forms a rectangle or cuboid, it is assumed that edges are interpreted + by inspecting the direction of their outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + + If any of these assumptions is not met, the user is required to explicitly state this. enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] x_direction(NX_CHAR): doc: | Direction of the positively pointing x-axis base vector of the detector_reference_frame. - We assume the configuration is inspected by looking towards the sample surface from a - position that is located behind the detector. enumeration: [undefined, north, east, south, west, in, out] y_direction(NX_CHAR): doc: | Direction of the positively pointing y-axis base vector of the detector_reference_frame. - We assume the configuration is inspected by looking towards the sample surface from a - position that is located behind the detector. enumeration: [undefined, north, east, south, west, in, out] z_direction(NX_CHAR): doc: | Direction of the positively pointing z-axis base vector of the detector_reference_frame. - We assume the configuration is inspected by looking towards the sample surface from a - position that is located behind the detector. enumeration: [undefined, north, east, south, west, in, out] - # conventions specific for certain methods - # (NXcoordinate_system_em_ebsd): \ No newline at end of file diff --git a/manual/source/classes/contributed_definitions/em-structure.rst b/manual/source/classes/contributed_definitions/em-structure.rst index 6f1c237c11..9f96197682 100644 --- a/manual/source/classes/contributed_definitions/em-structure.rst +++ b/manual/source/classes/contributed_definitions/em-structure.rst @@ -162,9 +162,6 @@ More consolidation through the use of NXsubentry classes should be considered in :ref:`NXem_method`, :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eds`, :ref:`NXem_eels`, :ref:`NXem_img`, :ref:`NXem_correlation`: Base classes with method-specific details especially when it comes to reporting post-processed data within electron microscopy. - :ref:`NXcoordinate_system_em_ebsd`: - Base class to store technique-specific reference frames and rotation conventions which are necessary to interpret the alignment and conventions used when working with EBSD data. - :ref:`NXcrystal_structure`: A base class to store crystalline phase/structure used for a simulation of diffraction pattern and comparison of these pattern against patterns to support indexing. From e907edb9cd452d40c9d37426eb2e2132361b9db9 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 30 Jul 2024 11:44:23 +0200 Subject: [PATCH 0821/1012] Refactored NXcoordinate_system_em_ebsd into NXem_ebsd --- .../NXcoordinate_system_em_ebsd.nxdl.xml | 225 ------------------ contributed_definitions/NXem_ebsd.nxdl.xml | 159 ++++++++++++- .../nyaml/NXcoordinate_system_em_ebsd.yaml | 120 ---------- contributed_definitions/nyaml/NXem_ebsd.yaml | 81 ++++++- 4 files changed, 232 insertions(+), 353 deletions(-) delete mode 100644 contributed_definitions/NXcoordinate_system_em_ebsd.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcoordinate_system_em_ebsd.yaml diff --git a/contributed_definitions/NXcoordinate_system_em_ebsd.nxdl.xml b/contributed_definitions/NXcoordinate_system_em_ebsd.nxdl.xml deleted file mode 100644 index fbbc8c4aea..0000000000 --- a/contributed_definitions/NXcoordinate_system_em_ebsd.nxdl.xml +++ /dev/null @@ -1,225 +0,0 @@ - - - - - - - Base class for method-specific conventions EBSD. - - Solves the key issue that currently conventions used for collecting and interpreting - EBSD data are not always explicitly communicating which limits interoperability and - reusability of EBSD data. - - - - Details about the gnomonic projection reference frame. - - - - Type of coordinate system/reference frame used for identifying - positions in the gnomonic projection space Xg, Yg, Zg - according to DOI: 10.1016/j.matchar.2016.04.008. - - - - - - - - - Handedness of coordinate system. - - - - - - - - - Is the origin of the gnomonic coordinate system located - where we assume the location of the pattern centre. - This is the location Xg = 0, Yg = 0, Zg = 0 according to - reference DOI: 10.1016/j.matchar.2016.04.008. - - - - - - - - - Direction of the positively pointing "gnomomic" x-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. - - - - - - - - - - - - - - Direction of the positively pointing "gnomomic" y-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - - - - - - - - - - - - - - Direction of the positively pointing "gnomomic" z-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - - - - - - - - - - - - - - - Details about the definition of the pattern centre - as a special point in the gnomonic projection reference frame. - - - - From which border of the EBSP (in the detector reference frame) - is the pattern centre's x-position (PCx) measured? - Keywords assume the region-of-interest is defined by - a rectangle. We observe this rectangle and inspect the - direction of the outer-unit normals to the edges of - this rectangle. - - - - - - - - - - - - In which direction are positive values for PCx measured from - the specified boundary. Keep in mind that the gnomonic space - is in virtually all cases embedded in the detector space. - Specifically, the XgYg plane is defined such that it is - embedded/laying inside the XdYd plane (of the detector - reference frame). - When the normalization direction is the same as e.g. the - detector x-axis direction, we state that we effectively - normalize in fractions of the width of the detector. - - The issue with terms like width and height is that these - degenerate if the detector region-of-interest is square-shaped. - This is why we should better avoid talking about width and height but - state how we would measure distances practically with a ruler and - how we then measure positive distances. - - - - - - - - - - - - From which border of the EBSP (in the detector reference - frame) is the pattern centre's y-position (PCy) measured? - For further details inspect the help button of - xaxis_boundary_convention. - - - - - - - - - - - - In which direction are positive values for PCy measured from - the specified boundary. - For further details inspect the help button of - xaxis_normalization_direction. - - - - - - - - - - - - diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index cedad5c4f1..673d883a39 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -140,10 +140,161 @@ post-processing can be granularized also for such X-ray-based techniques, whether it be 3DXRD or HEDM. - - - + + + + Details about the gnomonic (projection) reference frame. + + It is assumed that the configuration is inspected by looking towards the sample surface. + If a detector is involved, it is assumed that the configuration is inspected from a position + that is located behind this detector. + + If any of these assumptions is not met, the user is required to explicitly state this. + + Reference DOI: 10.1016/j.matchar.2016.04.008 suggests to label the + base vectors of this coordinate system as Xg, Yg, Zg. + + + + Origin of the gnomonic_projection_reference_frame. + + Reference DOI: 10.1016/j.matchar.2016.04.008 suggests to + assume that this is coordinate Xg = 0, Yg = 0, Zg = 0. + + + + + + + + + Direction of the positively pointing x-axis base vector of the + gnomonic_reference_frame. + + + + + + + + + + + + + + Direction of the positively pointing y-axis base vector of the + gnomonic_reference_frame. + + + + + + + + + + + + + + Direction of the positively pointing z-axis base vector of the + gnomonic_reference_frame. + + + + + + + + + + + + + + + Details about the definition of the pattern centre as a special point in the gnomonic_reference_frame. + + Keep in mind that the gnomonic space is in virtually all cases embedded in the detector space. + Specifically, the XgYg plane is defined such that it is laying inside the XdYd plane + (of the detector reference frame). + + When the normalization direction is the same as e.g. the detector x-axis direction one + effectively normalizes in fractions of the width of the detector. + + The issue with terms like width and height is that these degenerate if the detector + region-of-interest is square-shaped. This is why instead of referring to width and height + one should report as if one were to measure practically with a ruler and one is specific + about in which direction positive distances are measured. + + For the concepts used to specify the boundary_convention it is assumed that the + region-of-interest is defined by a rectangle, referring to the direction of outer-unit + normals to the respective edges of this rectangle. + + + + From which border of the EBSP (in the detector reference frame) is the pattern + centre's x-position (PCx) measured. + + + + + + + + + + + + In which direction are positive values for the x-axis coordinate value measured + from the specified boundary. + + + + + + + + + + + + From which border of the EBSP (in the detector reference frame) is the pattern + centre's y-position (PCy) measured. + + + + + + + + + + + + In which direction are positive values for the y-axis coordinate value measured + from the specified boundary. + + + + + + + + + + + This group documents relevant details about the conditions and the tools diff --git a/contributed_definitions/nyaml/NXcoordinate_system_em_ebsd.yaml b/contributed_definitions/nyaml/NXcoordinate_system_em_ebsd.yaml deleted file mode 100644 index 37826128ce..0000000000 --- a/contributed_definitions/nyaml/NXcoordinate_system_em_ebsd.yaml +++ /dev/null @@ -1,120 +0,0 @@ -category: base -doc: | - Base class for method-specific conventions EBSD. - - Solves the key issue that currently conventions used for collecting and interpreting - EBSD data are not always explicitly communicating which limits interoperability and - reusability of EBSD data. -# symbols: -type: group -NXcoordinate_system_em_ebsd(NXobject): # move to the NXem_ebsd part of the NXem application definition - gnomonic_projection_reference_frame(NXcoordinate_system): - doc: | - Details about the gnomonic projection reference frame. - type(NX_CHAR): - doc: | - Type of coordinate system/reference frame used for identifying - positions in the gnomonic projection space Xg, Yg, Zg - according to DOI: 10.1016/j.matchar.2016.04.008. - enumeration: [undefined, cartesian] - handedness(NX_CHAR): - doc: | - Handedness of coordinate system. - enumeration: [right_handed, left_handed] - origin(NX_CHAR): - doc: | - Is the origin of the gnomonic coordinate system located - where we assume the location of the pattern centre. - This is the location Xg = 0, Yg = 0, Zg = 0 according to - reference DOI: 10.1016/j.matchar.2016.04.008. - enumeration: [undefined, in_the_pattern_centre] - x_direction(NX_CHAR): - doc: | - Direction of the positively pointing "gnomomic" x-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. - enumeration: [undefined, north, east, south, west, in, out] - y_direction(NX_CHAR): - doc: | - Direction of the positively pointing "gnomomic" y-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - enumeration: [undefined, north, east, south, west, in, out] - z_direction(NX_CHAR): - doc: | - Direction of the positively pointing "gnomomic" z-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - enumeration: [undefined, north, east, south, west, in, out] - pattern_centre(NXprocess): - doc: | - Details about the definition of the pattern centre - as a special point in the gnomonic projection reference frame. - x_boundary_convention(NX_CHAR): - doc: | - From which border of the EBSP (in the detector reference frame) - is the pattern centre's x-position (PCx) measured? - Keywords assume the region-of-interest is defined by - a rectangle. We observe this rectangle and inspect the - direction of the outer-unit normals to the edges of - this rectangle. - enumeration: [undefined, top, right, bottom, left] - x_normalization_direction(NX_CHAR): - doc: | - In which direction are positive values for PCx measured from - the specified boundary. Keep in mind that the gnomonic space - is in virtually all cases embedded in the detector space. - Specifically, the XgYg plane is defined such that it is - embedded/laying inside the XdYd plane (of the detector - reference frame). - When the normalization direction is the same as e.g. the - detector x-axis direction, we state that we effectively - normalize in fractions of the width of the detector. - - The issue with terms like width and height is that these - degenerate if the detector region-of-interest is square-shaped. - This is why we should better avoid talking about width and height but - state how we would measure distances practically with a ruler and - how we then measure positive distances. - enumeration: [undefined, north, east, south, west] - y_boundary_convention(NX_CHAR): - doc: | - From which border of the EBSP (in the detector reference - frame) is the pattern centre's y-position (PCy) measured? - For further details inspect the help button of - xaxis_boundary_convention. - enumeration: [undefined, top, right, bottom, left] - y_normalization_direction(NX_CHAR): - doc: | - In which direction are positive values for PCy measured from - the specified boundary. - For further details inspect the help button of - xaxis_normalization_direction. - enumeration: [undefined, north, east, south, west] - # distance_convention: - # doc: | - # How is the third of the three pattern centre parameter values, - # the (distance) parameter DD, normalized. Which convention - # is followed. We are aware that specifying one of the options here - # also implicitly comes with conventions for some of the parameter - # requested in this ELN. For now we would rather like to ask - # the users though to be specific also to learn how such an ELN - # will be used in practice. - # enumeration: [undefined, Bruker, JEOL, FEI, Oxford] diff --git a/contributed_definitions/nyaml/NXem_ebsd.yaml b/contributed_definitions/nyaml/NXem_ebsd.yaml index d3a8f51e12..5c03ec28d6 100644 --- a/contributed_definitions/nyaml/NXem_ebsd.yaml +++ b/contributed_definitions/nyaml/NXem_ebsd.yaml @@ -102,10 +102,83 @@ symbols: standardized default plot orientation mapping. type: group NXem_ebsd(NXem_method): - (NXcoordinate_system_set): - (NXcoordinate_system_em_ebsd): - # either we have simulated data or we have a set of measured data - # in every case data are Kikuchi diffraction pattern and their metadata + # (NXcoordinate_system): + gnomonic_reference_frame(NXcoordinate_system): + doc: | + Details about the gnomonic (projection) reference frame. + + It is assumed that the configuration is inspected by looking towards the sample surface. + If a detector is involved, it is assumed that the configuration is inspected from a position + that is located behind this detector. + + If any of these assumptions is not met, the user is required to explicitly state this. + + Reference DOI: 10.1016/j.matchar.2016.04.008 suggests to label the + base vectors of this coordinate system as Xg, Yg, Zg. + origin(NX_CHAR): + doc: | + Origin of the gnomonic_projection_reference_frame. + + Reference DOI: 10.1016/j.matchar.2016.04.008 suggests to + assume that this is coordinate Xg = 0, Yg = 0, Zg = 0. + enumeration: [undefined, in_the_pattern_centre] + x_direction(NX_CHAR): + doc: | + Direction of the positively pointing x-axis base vector of the gnomonic_reference_frame. + enumeration: [undefined, north, east, south, west, in, out] + y_direction(NX_CHAR): + doc: | + Direction of the positively pointing y-axis base vector of the gnomonic_reference_frame. + enumeration: [undefined, north, east, south, west, in, out] + z_direction(NX_CHAR): + doc: | + Direction of the positively pointing z-axis base vector of the gnomonic_reference_frame. + enumeration: [undefined, north, east, south, west, in, out] + pattern_centre(NXprocess): + doc: | + Details about the definition of the pattern centre as a special point in the gnomonic_reference_frame. + + Keep in mind that the gnomonic space is in virtually all cases embedded in the detector space. + Specifically, the XgYg plane is defined such that it is laying inside the XdYd plane + (of the detector reference frame). + + When the normalization direction is the same as e.g. the detector x-axis direction one + effectively normalizes in fractions of the width of the detector. + + The issue with terms like width and height is that these degenerate if the detector + region-of-interest is square-shaped. This is why instead of referring to width and height + one should report as if one were to measure practically with a ruler and one is specific + about in which direction positive distances are measured. + + For the concepts used to specify the boundary_convention it is assumed that the + region-of-interest is defined by a rectangle, referring to the direction of outer-unit + normals to the respective edges of this rectangle. + x_boundary_convention(NX_CHAR): + doc: | + From which border of the EBSP (in the detector reference frame) is the pattern centre's x-position (PCx) measured. + enumeration: [undefined, top, right, bottom, left] + x_normalization_direction(NX_CHAR): + doc: | + In which direction are positive values for the x-axis coordinate value measured from the specified boundary. + enumeration: [undefined, north, east, south, west] + y_boundary_convention(NX_CHAR): + doc: | + From which border of the EBSP (in the detector reference frame) is the pattern centre's y-position (PCy) measured. + enumeration: [undefined, top, right, bottom, left] + y_normalization_direction(NX_CHAR): + doc: | + In which direction are positive values for the y-axis coordinate value measured from the specified boundary. + enumeration: [undefined, north, east, south, west] + # distance_convention: + # doc: | + # How is the third of the three pattern centre parameter values, + # the (distance) parameter DD, normalized. Which convention + # is followed. We are aware that specifying one of the options here + # also implicitly comes with conventions for some of the parameter + # requested in this ELN. For now we would rather like to ask + # the users though to be specific also to learn how such an ELN + # will be used in practice. + # enumeration: [undefined, Bruker, JEOL, FEI, Oxford] measurement(NXprocess): doc: | This group documents relevant details about the conditions and the tools From f773a9559eb314f125a9fe5a7ed1fa8de80c3038 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 6 Aug 2024 17:59:28 +0200 Subject: [PATCH 0822/1012] Fix naming bug for monochromator_em --- contributed_definitions/NXem.nxdl.xml | 2 +- contributed_definitions/NXem_msr.nxdl.xml | 1 + contributed_definitions/nyaml/NXem.yaml | 2 +- contributed_definitions/nyaml/NXem_msr.yaml | 1 + 4 files changed, 4 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index cc039a7f06..884a47ee53 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -1033,7 +1033,7 @@ basically optional use of NXaberration therein at least some value required--> - + diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml index 7e9d834b80..d7d590456f 100644 --- a/contributed_definitions/NXem_msr.nxdl.xml +++ b/contributed_definitions/NXem_msr.nxdl.xml @@ -70,6 +70,7 @@ + diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index f4e7bde4e8..e433ff5534 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -973,7 +973,7 @@ NXem(NXobject): However, if more details are known or should be documented one should use the description field for this. unit: NX_ANY - monochromator_emID(NXmonochromator): + monochromatorID(NXmonochromator): exists: [min, 0, max, infty] applied(NX_BOOLEAN): sensorID(NXsensor): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml index 3304728d37..fc509a6213 100644 --- a/contributed_definitions/nyaml/NXem_msr.yaml +++ b/contributed_definitions/nyaml/NXem_msr.yaml @@ -43,6 +43,7 @@ NXem_msr(NXem_method): (NXebeam_column): (NXibeam_column): (NXoptical_system_em): + # storing these data should happen in event_data, i.e. dynamic quantities (NXscanbox_em): (NXdetector): doc: | From 5d93521b23e0773f51bff28f238d2141e73a506f Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 9 Aug 2024 15:05:46 +0200 Subject: [PATCH 0823/1012] Bug fixes in images and spectrum and renaming of groups, refining precision of concept image and how this is connected to tilings --- contributed_definitions/NXapm.nxdl.xml | 6 +- contributed_definitions/NXem.nxdl.xml | 118 +++++-- contributed_definitions/NXimage_set.nxdl.xml | 125 ++++--- .../NXspectrum_set.nxdl.xml | 326 ++++++++++++++---- contributed_definitions/nyaml/NXapm.yaml | 6 +- contributed_definitions/nyaml/NXem.yaml | 98 +++++- .../nyaml/NXimage_set.yaml | 121 ++++--- .../nyaml/NXspectrum_set.yaml | 239 +++++++++---- dev_tools/tests/test_nxdl_utils.py | 6 +- 9 files changed, 759 insertions(+), 286 deletions(-) diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index d6a03e3419..0c2f9b9fb9 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -669,7 +669,7 @@ NEW ISSUE: make this rather an own subentry NXapm_ranging--> SEM or TEM image of the initial specimen i.e. ideally taken prior to the data acquisition. - + @@ -680,7 +680,7 @@ NEW ISSUE: make this rather an own subentry NXapm_ranging--> - + @@ -688,7 +688,7 @@ NEW ISSUE: make this rather an own subentry NXapm_ranging--> - diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 884a47ee53..88689abffa 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -621,8 +621,7 @@ lenses i.e. devices which can affect the pathes of beams - - + @@ -643,7 +642,7 @@ lenses i.e. devices which can affect the pathes of beams - + @@ -667,7 +666,7 @@ lenses i.e. devices which can affect the pathes of beams - + @@ -694,7 +693,7 @@ lenses i.e. devices which can affect the pathes of beams - + @@ -721,7 +720,7 @@ lenses i.e. devices which can affect the pathes of beams - + @@ -751,7 +750,7 @@ lenses i.e. devices which can affect the pathes of beams - + @@ -796,7 +795,7 @@ lenses i.e. devices which can affect the pathes of beams - + @@ -808,7 +807,7 @@ lenses i.e. devices which can affect the pathes of beams - + @@ -816,14 +815,53 @@ lenses i.e. devices which can affect the pathes of beams - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + @@ -831,17 +869,53 @@ lenses i.e. devices which can affect the pathes of beams - + - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + @@ -849,13 +923,16 @@ lenses i.e. devices which can affect the pathes of beams - + - + - + + + + @@ -863,7 +940,6 @@ lenses i.e. devices which can affect the pathes of beams - @@ -933,7 +1009,7 @@ lenses i.e. devices which can affect the pathes of beams - Device for improving energy resolution or reducing chromatic aberration. + Device to improve energy resolution or chromatic aberration. Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ @@ -961,7 +1037,9 @@ technical components of the corrector--> - + + + diff --git a/contributed_definitions/NXimage_set.nxdl.xml b/contributed_definitions/NXimage_set.nxdl.xml index 4c24730417..c92a12d3ca 100644 --- a/contributed_definitions/NXimage_set.nxdl.xml +++ b/contributed_definitions/NXimage_set.nxdl.xml @@ -21,46 +21,61 @@ # # For further information, see http://www.nexusformat.org --> + - +https://en.wikipedia.org/wiki/Euclidean_tilings_by_convex_regular_polygons--> - Number of images in the stack, for stacks the slowest direction. + Number of images in the stack, for stacks the slowest dimension. - Number of image points along the slow direction (k equivalent to z). + Number of image points along the slow dimension (k equivalent to z). - Number of image points along the fast direction (j equivalent to y). + Number of image points along the fast dimension (j equivalent to y). - Number of image points along the fastest direction (i equivalent to x). + Number of image points along the fastest dimension (i equivalent to x). - Base class for reporting a set of images in real or reciprocal space. + Base class for reporting a set of images. - Typically an image is understood as a discretized representation of intensity distribution that was - detected or simulated for which most often equidistantly spaced sampling is used. - The terms pixel and voxel identify the smallest discretization unit of such a representation. - Under these conditions pixel and voxel are polygonal or polyhedral unit cells of the underlying - tessellation of the region of interest within the reference space. + The mostly commonly used scanning methods are supported. That is one-, + two-, three-dimensional ROIs discretized using regular Euclidean tilings. - If the sampling is not equispaced, the shape and size of pixel and voxel change but still their - reference space is tessellated. In this case the term (image) point is eventually a more appropriate - term to use. Therefore, all docstrings in this base class refer to points. + Colloquially, an image is understood as a discretized representation of intensity distribution + that was detected or simulated for some ROI. When discretized with regular Euclidean tilings + the terms pixel and voxel identify the smallest discretization unit. Pixel and voxel are polygonal + or polyhedral unit cells respectively of the underlying tiling of the ROI within the reference space. + For all other tilings e.g. non-equispaced, the shape and size of pixel and voxel differs. Using the term + (image) point is eventually is more appropriate for such tilings. Therefore, all docstrings in this base class + refer to points (including pixel and voxel i.e. regular tilings). - This base class represents images generated from equispaced or non-equispaced sampling. + Point coordinates identify the location of the barycentre. For images in reciprocal space in practice, complex numbers are encoded via some formatted pair of real values. Typically, fast algorithms for computing Fourier transformations @@ -125,16 +140,12 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> - - - The reference space in which the image set is defined. - - - - - - - + + One-dimensional image. @@ -174,19 +185,19 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> - Point coordinate along the fastest direction. + Point coordinate along the fastest dimension. - Point coordinate along the fastest direction. + Point coordinate along the fastest dimension. - + Two-dimensional image. @@ -230,32 +241,32 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> - Point coordinate along the fast direction. + Point coordinate along the fast dimension. - Point coordinate along the fast direction. + Point coordinate along the fast dimension. - Point coordinate along the fastest direction. + Point coordinate along the fastest dimension. - Point coordinate along the fastest direction. + Point coordinate along the fastest dimension. - + Three-dimensional image. @@ -303,47 +314,47 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> - Point coordinate along the slow direction. + Point coordinate along the slow dimension. - Point coordinate along the slow direction. + Point coordinate along the slow dimension. - Point coordinate along the fast direction. + Point coordinate along the fast dimension. - Point coordinate along the fast direction. + Point coordinate along the fast dimension. - Point coordinate along the fastest direction. + Point coordinate along the fastest dimension. - Point coordinate along the fastest direction. + Point coordinate along the fastest dimension. - + - Collection of one-dimensional images. + Collection of image_1d. @@ -411,19 +422,19 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> - Point coordinate along the fastest direction. + Point coordinate along the fastest dimension. - Point coordinate along the fastest direction. + Point coordinate along the fastest dimension. - + Collection of two-dimensional images. @@ -495,34 +506,34 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> - + - Point coordinate along the fast direction. + Point coordinate along the fast dimension. - Point coordinate along the fast direction. + Point coordinate along the fast dimension. - Point coordinate along the fastest direction. + Point coordinate along the fastest dimension. - Point coordinate along the fastest direction. + Point coordinate along the fastest dimension. - + Collection of three-dimensional images. @@ -600,40 +611,40 @@ and here contributed_definitions/NXimage_r_set_diff.nxdl.xml--> - Point coordinate along the slow direction. + Point coordinate along the slow dimension. - Point coordinate along the slow direction. + Point coordinate along the slow dimension. - Point coordinate along the fast direction. + Point coordinate along the fast dimension. - Point coordinate along the fast direction. + Point coordinate along the fast dimension. - Point coordinate along the fastest direction. + Point coordinate along the fastest dimension. - Point coordinate along the fastest direction. + Point coordinate along the fastest dimension. diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml index 9863b67b44..3a34762545 100644 --- a/contributed_definitions/NXspectrum_set.nxdl.xml +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -22,40 +22,41 @@ # For further information, see http://www.nexusformat.org --> + - + - Number of scan points (slowest dimension). + Number of spectra in the stack, for stacks the slowest dimension. - + - Number of pixel in the slow direction. + Number of image points along the slower dimension (k equivalent to z). - + - Number of pixel in the fast direction. + Number of image points along the slow dimension (j equivalent to y). - + - Number of pixel in the fastest direction. + Number of image points along the fast dimension (i equivalent to x). - Number of energy bins. + Number of energy bins (always the fastest dimension). Base class container for reporting a set of spectra. - The mostly commonly used scanning methods are supported. - That is one-, two-, three-dimensional regularly sampled ROIs. + The mostly commonly used scanning methods are supported. That is one-, + two-, three-dimensional ROIs discretized using regular Euclidean tilings. - For randomly or dissimilarly spaced scan points use collection instead. + Use stack for all other tilings. - +like omega/q mapping more complicated scan pattern than rectangular ones.--> + - One spectrum for one pixel in a ROI aka spot measurement. + One spectrum for a point of a 0d ROI. Also known as spot measurement. Counts - - - + + @@ -131,17 +131,16 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> - + - One spectrum for each pixel of an equidistantly - sampled one-dimensional ROI. + One spectrum for each point of a 1d ROI. Counts - + @@ -150,16 +149,16 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> - + - Coordinate along x direction. + Point coordinate along the fast dimension. - + - Pixel coordinate along x direction + Point coordinate along the fast dimension @@ -177,18 +176,17 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> - + - One spectrum for each pixel of an equidistantly - sampled two-dimensional ROI. + One spectrum for each scan point of 2d ROI. Counts - - + + @@ -197,29 +195,29 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> - + - Coordinate along y direction. + Point coordinate along the slow dimension. - + - Pixel coordinate along y direction + Point coordinate along the slow dimension. - + - Coordinate along x direction. + Point coordinate along the fast dimension. - + - Pixel coordinate along x direction + Point coordinate along the fast dimension. @@ -237,19 +235,18 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> - + - One spectrum for each voxel of an equidistantly - sampled three-dimensional ROI. + One spectrum for point of a 3d ROI. Counts - - - + + + @@ -258,42 +255,42 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> - + - Coordinate along z direction. + Point coordinate along the slower dimension. - + - Pixel coordinate along z direction + Point coordinate along the slower dimension. - + - Coordinate along y direction. + Point coordinate along the slow dimension. - + - Pixel coordinate along y direction + Point coordinate along the slow dimension. - + - Coordinate along x direction. + Point coordinate along the fast dimension. - + - Pixel coordinate along x direction + Point coordinate along the fast dimension. @@ -315,18 +312,16 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> if there is interest to support arbitrary scan pattern one should use scan points and contact us to generalize this base class and related base classes--> - + - One spectrum for each scan point. This representation supports - equidistant energy bins. For rectangular sampling use respective - one-, two-, and three-dimensional variants instead. + Multiple instances of spectrum_0d. Counts - + @@ -335,16 +330,215 @@ base classes--> - + + + Group identifier + + + + + + + Group identifier + + + + + + Spectrum identifier + + + + + + + Spectrum identifier + + + + + + Energy axis + + + + + + + Energy + + + + + + + Multiple instances of spectrum_2d. + + + + Counts + + + + + + + + + + Counts + + + + + + Group identifier + + + + + + + Group identifier + + + + + + Spectrum identifier + + + + + + + Spectrum identifier + + + + + + Point coordinate along the slow dimension. + + + + + + + Point coordinate along the slow dimension. + + + + + + Point coordinate along the fast dimension. + + + + + + + Point coordinate along the fast dimension. + + + + + + Energy axis + + + + + + + Energy + + + + + + + Multiple instances of spectrum_3d. + + + + Counts + + + + + + + + + + + Counts + + + + + + Group identifier + + + + + + + Group identifier + + + + + + Spectrum identifier + + + + + + + Spectrum identifier + + + + + + Point coordinate along the slower dimension. + + + + + + + Point coordinate along the slower dimension. + + + + + + Point coordinate along the slow dimension. + + + + + + + Point coordinate along the slow dimension. + + + + - Scan point identifier + Point coordinate along the fast dimension. - + - Scan point identifier + Point coordinate along the fast dimension. diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml index 7963f1520c..61588cfcc5 100644 --- a/contributed_definitions/nyaml/NXapm.yaml +++ b/contributed_definitions/nyaml/NXapm.yaml @@ -579,7 +579,7 @@ NXapm(NXobject): doc: | SEM or TEM image of the initial specimen i.e. ideally taken prior to the data acquisition. - image_twod(NXdata): + image_2d(NXdata): \@signal(NX_CHAR): \@axes(NX_CHAR): \@AXISNAME_indices(NX_CHAR): @@ -587,10 +587,10 @@ NXapm(NXobject): axis_j(NX_NUMBER): dim: (n_j,) \@long_name(NX_CHAR): - axis_x(NX_NUMBER): + axis_i(NX_NUMBER): dim: (n_i,) \@long_name(NX_CHAR): - # one could use a stack_threed(NXdata) to record + # one could use a stack_3d(NXdata) to record # a time series of the specimen shape evolution raw_data(NXprocess): diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index e433ff5534..d073e497a1 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -585,8 +585,7 @@ NXem(NXobject): absolute_path(NX_CHAR): exists: recommended detector_identifier(NX_CHAR): - space(NX_CHAR): - image_oned(NXdata): + image_1d(NXdata): exists: optional \@signal(NX_CHAR): \@axes(NX_CHAR): @@ -605,7 +604,7 @@ NXem(NXobject): \@long_name(NX_CHAR): axis_i(NX_NUMBER): \@long_name(NX_CHAR): - image_twod(NXdata): + image_2d(NXdata): exists: optional \@signal(NX_CHAR): \@axes(NX_CHAR): @@ -626,7 +625,7 @@ NXem(NXobject): \@long_name(NX_CHAR): axis_i(NX_NUMBER): \@long_name(NX_CHAR): - image_threed(NXdata): + image_3d(NXdata): exists: optional \@signal(NX_CHAR): \@axes(NX_CHAR): @@ -649,7 +648,7 @@ NXem(NXobject): \@long_name(NX_CHAR): axis_i(NX_NUMBER): \@long_name(NX_CHAR): - stack_oned(NXdata): + stack_1d(NXdata): exists: optional \@signal(NX_CHAR): \@axes(NX_CHAR): @@ -673,7 +672,7 @@ NXem(NXobject): \@long_name(NX_CHAR): axis_i(NX_NUMBER): \@long_name(NX_CHAR): - stack_twod(NXdata): + stack_2d(NXdata): exists: optional \@signal(NX_CHAR): \@axes(NX_CHAR): @@ -699,7 +698,7 @@ NXem(NXobject): \@long_name(NX_CHAR): axis_i(NX_NUMBER): \@long_name(NX_CHAR): - stack_threed(NXdata): + stack_3d(NXdata): exists: optional \@signal(NX_CHAR): \@axes(NX_CHAR): @@ -739,7 +738,7 @@ NXem(NXobject): absolute_path(NX_CHAR): exists: recommended detector_identifier(NX_CHAR): - spectrum_zerod(NXdata): + spectrum_0d(NXdata): exists: optional \@signal(NX_CHAR): \@axes(NX_CHAR): @@ -749,7 +748,7 @@ NXem(NXobject): \@long_name(NX_CHAR): axis_energy(NX_NUMBER): \@long_name(NX_CHAR): - spectrum_oned(NXdata): + spectrum_1d(NXdata): exists: optional \@signal(NX_CHAR): \@axes(NX_CHAR): @@ -757,11 +756,11 @@ NXem(NXobject): title(NX_CHAR): intensity(NX_NUMBER): \@long_name(NX_CHAR): - axis_x(NX_NUMBER): + axis_i(NX_NUMBER): \@long_name(NX_CHAR): axis_energy(NX_NUMBER): \@long_name(NX_CHAR): - spectrum_twod(NXdata): + spectrum_2d(NXdata): exists: optional \@signal(NX_CHAR): \@axes(NX_CHAR): @@ -769,13 +768,29 @@ NXem(NXobject): title(NX_CHAR): intensity(NX_NUMBER): \@long_name(NX_CHAR): - axis_y(NX_NUMBER): + axis_j(NX_NUMBER): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + axis_energy(NX_NUMBER): + \@long_name(NX_CHAR): + spectrum_3d(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_INT): + title(NX_CHAR): + intensity(NX_NUMBER): + \@long_name(NX_CHAR): + axis_k(NX_NUMBER): + \@long_name(NX_CHAR): + axis_j(NX_NUMBER): \@long_name(NX_CHAR): - axis_x(NX_NUMBER): + axis_i(NX_NUMBER): \@long_name(NX_CHAR): axis_energy(NX_NUMBER): \@long_name(NX_CHAR): - spectrum_threed(NXdata): + stack_0d(NXdata): exists: optional \@signal(NX_CHAR): \@axes(NX_CHAR): @@ -783,15 +798,59 @@ NXem(NXobject): title(NX_CHAR): intensity(NX_NUMBER): \@long_name(NX_CHAR): - axis_z(NX_NUMBER): + spectrum_identifier(NX_INT): \@long_name(NX_CHAR): - axis_y(NX_NUMBER): + axis_energy(NX_NUMBER): \@long_name(NX_CHAR): - axis_x(NX_NUMBER): + stack_1d(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_INT): + title(NX_CHAR): + intensity(NX_NUMBER): + \@long_name(NX_CHAR): + spectrum_identifier(NX_INT): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): \@long_name(NX_CHAR): axis_energy(NX_NUMBER): \@long_name(NX_CHAR): - # collection(NXdata): + stack_2d(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_INT): + title(NX_CHAR): + intensity(NX_NUMBER): + \@long_name(NX_CHAR): + spectrum_identifier(NX_INT): + \@long_name(NX_CHAR): + axis_j(NX_NUMBER): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + axis_energy(NX_NUMBER): + \@long_name(NX_CHAR): + stack_3d(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_INT): + title(NX_CHAR): + intensity(NX_NUMBER): + \@long_name(NX_CHAR): + spectrum_identifier(NX_INT): + \@long_name(NX_CHAR): + axis_k(NX_NUMBER): + \@long_name(NX_CHAR): + axis_j(NX_NUMBER): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + axis_energy(NX_NUMBER): + \@long_name(NX_CHAR): + em_lab(NXinstrument): exists: recommended ebeam_column(NXebeam_column): @@ -870,7 +929,7 @@ NXem(NXobject): exists: [min, 0, max, infty] doc: - | - Device for improving energy resolution or reducing chromatic aberration. + Device to improve energy resolution or chromatic aberration. - | Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector like `_ # user perspective @@ -900,6 +959,7 @@ NXem(NXobject): (NXprocess): (NXaberration_model): exists: optional + model(NX_CHAR): # we could write down how to store the aberrations but we should not force to add aberrations # basically optional use of NXaberration therein at least some value required corrector_ax(NXcomponent): diff --git a/contributed_definitions/nyaml/NXimage_set.yaml b/contributed_definitions/nyaml/NXimage_set.yaml index ccfa0b34d5..af3e9e52bb 100644 --- a/contributed_definitions/nyaml/NXimage_set.yaml +++ b/contributed_definitions/nyaml/NXimage_set.yaml @@ -1,19 +1,20 @@ category: base doc: - | - Base class for reporting a set of images in real or reciprocal space. + Base class for reporting a set of images. - | - Typically an image is understood as a discretized representation of intensity distribution that was - detected or simulated for which most often equidistantly spaced sampling is used. - The terms pixel and voxel identify the smallest discretization unit of such a representation. - Under these conditions pixel and voxel are polygonal or polyhedral unit cells of the underlying - tessellation of the region of interest within the reference space. + The mostly commonly used scanning methods are supported. That is one-, + two-, three-dimensional ROIs discretized using regular Euclidean tilings. - If the sampling is not equispaced, the shape and size of pixel and voxel change but still their - reference space is tessellated. In this case the term (image) point is eventually a more appropriate - term to use. Therefore, all docstrings in this base class refer to points. + Colloquially, an image is understood as a discretized representation of intensity distribution + that was detected or simulated for some ROI. When discretized with regular Euclidean tilings + the terms pixel and voxel identify the smallest discretization unit. Pixel and voxel are polygonal + or polyhedral unit cells respectively of the underlying tiling of the ROI within the reference space. + For all other tilings e.g. non-equispaced, the shape and size of pixel and voxel differs. Using the term + (image) point is eventually is more appropriate for such tilings. Therefore, all docstrings in this base class + refer to points (including pixel and voxel i.e. regular tilings). - This base class represents images generated from equispaced or non-equispaced sampling. + Point coordinates identify the location of the barycentre. For images in reciprocal space in practice, complex numbers are encoded via some formatted pair of real values. Typically, fast algorithms for computing Fourier transformations @@ -39,19 +40,32 @@ doc: That is image_identifier are always counting from offset in increments of one. as each image is its own entity. By contrast, a group may contain no, or several images. Consequently, group_identifier are not required to be contiguous. -# for details about NXimage_r_set_diff see +# for earlier variants see here # https://github.com/FAIRmat-NFDI/nexus_definitions/commit/0682943baaef54d4a6386b5433f9721af6d3d81b -# and here contributed_definitions/NXimage_r_set_diff.nxdl.xml +# https://en.wikipedia.org/wiki/Euclidean_tilings_by_convex_regular_polygons symbols: n_img: | - Number of images in the stack, for stacks the slowest direction. + Number of images in the stack, for stacks the slowest dimension. n_k: | - Number of image points along the slow direction (k equivalent to z). + Number of image points along the slow dimension (k equivalent to z). n_j: | - Number of image points along the fast direction (j equivalent to y). + Number of image points along the fast dimension (j equivalent to y). n_i: | - Number of image points along the fastest direction (i equivalent to x). + Number of image points along the fastest dimension (i equivalent to x). type: group +# a key challenge is setting constraints, lets explain with contrasting two use cases: +# case 1 assuming an image is nothing but a collection of point-wise information without making explicit tiling and discretization information +# case 2 assuming that like most frequently assumed we understand an image probing Euclidean space +# assuming that we expect that the image is represented using a pixel grid because it was captured +# using sensors that are arranged on generator points of a regular tiling. +# in the first case, one should not constrain the dimensions for images beyond 1d +# because beyond 1d the question of offset and stride comes up i.e. the question which +# tiling is used to construct the sensor array +# in the second case, one should constrain the dimensions for all dimensions as otherwise +# there are no instructions how to arrange the sensors or the pixels for visualizing the image +# because the image is not just a bunch of point wise intensities +# but if the dimensions are not constrained again images in application definitions will be represented +# using different conventions. NXimage_set(NXobject): (NXprocess): doc: | @@ -82,13 +96,12 @@ NXimage_set(NXobject): (NXprogram): doc: | Program used for processing. - space(NX_CHAR): - doc: - - | - The reference space in which the image set is defined. - enumeration: [real, reciprocal] - - image_oned(NXdata): + # space(NX_CHAR): + # doc: + # - | + # The reference space in which the image set is defined. + # enumeration: [real, reciprocal] + image_1d(NXdata): doc: | One-dimensional image. intensity(NX_NUMBER): @@ -115,14 +128,14 @@ NXimage_set(NXobject): dim: (n_i,) axis_i(NX_NUMBER): doc: | - Point coordinate along the fastest direction. + Point coordinate along the fastest dimension. unit: NX_LENGTH dim: (n_i,) \@long_name(NX_CHAR): doc: | - Point coordinate along the fastest direction. + Point coordinate along the fastest dimension. - image_twod(NXdata): + image_2d(NXdata): doc: | Two-dimensional image. intensity(NX_NUMBER): @@ -149,22 +162,22 @@ NXimage_set(NXobject): dim: (n_j, n_i) axis_j(NX_NUMBER): doc: | - Point coordinate along the fast direction. + Point coordinate along the fast dimension. unit: NX_LENGTH dim: (n_j,) \@long_name(NX_CHAR): doc: | - Point coordinate along the fast direction. + Point coordinate along the fast dimension. axis_i(NX_NUMBER): doc: | - Point coordinate along the fastest direction. + Point coordinate along the fastest dimension. unit: NX_LENGTH dim: (n_i,) \@long_name(NX_CHAR): doc: | - Point coordinate along the fastest direction. + Point coordinate along the fastest dimension. - image_threed(NXdata): + image_3d(NXdata): doc: | Three-dimensional image. intensity(NX_NUMBER): @@ -191,32 +204,32 @@ NXimage_set(NXobject): dim: (n_k, n_j, n_i) axis_k(NX_NUMBER): doc: | - Point coordinate along the slow direction. + Point coordinate along the slow dimension. unit: NX_LENGTH dim: (n_k,) \@long_name(NX_CHAR): doc: | - Point coordinate along the slow direction. + Point coordinate along the slow dimension. axis_j(NX_NUMBER): doc: | - Point coordinate along the fast direction. + Point coordinate along the fast dimension. unit: NX_LENGTH dim: (n_j,) \@long_name(NX_CHAR): doc: | - Point coordinate along the fast direction. + Point coordinate along the fast dimension. axis_i(NX_NUMBER): doc: | - Point coordinate along the fastest direction. + Point coordinate along the fastest dimension. unit: NX_LENGTH dim: (n_i,) \@long_name(NX_CHAR): doc: | - Point coordinate along the fastest direction. + Point coordinate along the fastest dimension. - stack_oned(NXdata): + stack_1d(NXdata): doc: | - Collection of one-dimensional images. + Collection of image_1d. intensity(NX_NUMBER): doc: | Intensity for real-valued images as an alternative for real. @@ -257,14 +270,14 @@ NXimage_set(NXobject): Image identifier axis_i(NX_NUMBER): doc: | - Point coordinate along the fastest direction. + Point coordinate along the fastest dimension. unit: NX_LENGTH dim: (n_i,) \@long_name(NX_CHAR): doc: | - Point coordinate along the fastest direction. + Point coordinate along the fastest dimension. - stack_twod(NXdata): + stack_2d(NXdata): doc: | Collection of two-dimensional images. intensity(NX_NUMBER): @@ -305,24 +318,24 @@ NXimage_set(NXobject): \@long_name(NX_CHAR): doc: | Image identifier. - axis_y(NX_NUMBER): + axis_j(NX_NUMBER): doc: | - Point coordinate along the fast direction. + Point coordinate along the fast dimension. unit: NX_LENGTH dim: (n_j,) \@long_name(NX_CHAR): doc: | - Point coordinate along the fast direction. + Point coordinate along the fast dimension. axis_i(NX_NUMBER): doc: | - Point coordinate along the fastest direction. + Point coordinate along the fastest dimension. unit: NX_LENGTH dim: (n_i,) \@long_name(NX_CHAR): doc: | - Point coordinate along the fastest direction. + Point coordinate along the fastest dimension. - stack_threed(NXdata): + stack_3d(NXdata): doc: | Collection of three-dimensional images. intensity(NX_NUMBER): @@ -365,25 +378,25 @@ NXimage_set(NXobject): Image identifier axis_k(NX_NUMBER): doc: | - Point coordinate along the slow direction. + Point coordinate along the slow dimension. unit: NX_LENGTH dim: (n_k,) \@long_name(NX_CHAR): doc: | - Point coordinate along the slow direction. + Point coordinate along the slow dimension. axis_j(NX_NUMBER): doc: | - Point coordinate along the fast direction. + Point coordinate along the fast dimension. unit: NX_LENGTH dim: (n_j,) \@long_name(NX_CHAR): doc: | - Point coordinate along the fast direction. + Point coordinate along the fast dimension. axis_i(NX_NUMBER): doc: | - Point coordinate along the fastest direction. + Point coordinate along the fastest dimension. unit: NX_LENGTH dim: (n_i,) \@long_name(NX_CHAR): doc: | - Point coordinate along the fastest direction. + Point coordinate along the fastest dimension. diff --git a/contributed_definitions/nyaml/NXspectrum_set.yaml b/contributed_definitions/nyaml/NXspectrum_set.yaml index 1f5284889b..ebddc9b338 100644 --- a/contributed_definitions/nyaml/NXspectrum_set.yaml +++ b/contributed_definitions/nyaml/NXspectrum_set.yaml @@ -2,21 +2,22 @@ category: base doc: | Base class container for reporting a set of spectra. - The mostly commonly used scanning methods are supported. - That is one-, two-, three-dimensional regularly sampled ROIs. + The mostly commonly used scanning methods are supported. That is one-, + two-, three-dimensional ROIs discretized using regular Euclidean tilings. - For randomly or dissimilarly spaced scan points use collection instead. + Use stack for all other tilings. +# https://en.wikipedia.org/wiki/Euclidean_tilings_by_convex_regular_polygons symbols: - n_p: | - Number of scan points (slowest dimension). - n_z: | - Number of pixel in the slow direction. - n_y: | - Number of pixel in the fast direction. - n_x: | - Number of pixel in the fastest direction. + n_spc: | + Number of spectra in the stack, for stacks the slowest dimension. + n_k: | + Number of image points along the slower dimension (k equivalent to z). + n_j: | + Number of image points along the slow dimension (j equivalent to y). + n_i: | + Number of image points along the fast dimension (i equivalent to x). n_energy: | - Number of energy bins. + Number of energy bins (always the fastest dimension). type: group NXspectrum_set(NXobject): # for EELS we likely need a complex-valued NXspectrum_c_set to this @@ -51,15 +52,16 @@ NXspectrum_set(NXobject): Link or name of an :ref:`NXdetector` instance with which the data were collected. (NXprogram): ##MK::feel free to contact us when you would like to include - # lik omega/q mapping more complicated scan pattern than rectangular ones. - spectrum_zerod(NXdata): + # like omega/q mapping more complicated scan pattern than rectangular ones. + + spectrum_0d(NXdata): doc: | - One spectrum for one pixel in a ROI aka spot measurement. + One spectrum for a point of a 0d ROI. Also known as spot measurement. intensity(NX_NUMBER): doc: | Counts unit: NX_UNITLESS - dim: (n_x, n_energy) + dim: (n_energy,) \@long_name(NX_CHAR): doc: | Counts @@ -72,26 +74,25 @@ NXspectrum_set(NXobject): doc: | Energy - spectrum_oned(NXdata): + spectrum_1d(NXdata): doc: | - One spectrum for each pixel of an equidistantly - sampled one-dimensional ROI. + One spectrum for each point of a 1d ROI. intensity(NX_NUMBER): doc: | Counts unit: NX_UNITLESS - dim: (n_x, n_energy) + dim: (n_i, n_energy) \@long_name(NX_CHAR): doc: | Counts - axis_x(NX_NUMBER): + axis_i(NX_NUMBER): doc: | - Coordinate along x direction. + Point coordinate along the fast dimension. unit: NX_LENGTH - dim: (n_x,) + dim: (n_i,) \@long_name(NX_CHAR): doc: | - Pixel coordinate along x direction + Point coordinate along the fast dimension axis_energy(NX_NUMBER): doc: | Energy axis @@ -101,34 +102,33 @@ NXspectrum_set(NXobject): doc: | Energy - spectrum_twod(NXdata): + spectrum_2d(NXdata): doc: | - One spectrum for each pixel of an equidistantly - sampled two-dimensional ROI. + One spectrum for each scan point of 2d ROI. intensity(NX_NUMBER): doc: | Counts unit: NX_UNITLESS - dim: (n_y, n_x, n_energy) + dim: (n_j, n_i, n_energy) \@long_name(NX_CHAR): doc: | Counts - axis_y(NX_NUMBER): + axis_j(NX_NUMBER): doc: | - Coordinate along y direction. + Point coordinate along the slow dimension. unit: NX_LENGTH - dim: (n_y,) + dim: (n_j,) \@long_name(NX_CHAR): doc: | - Pixel coordinate along y direction - axis_x(NX_NUMBER): + Point coordinate along the slow dimension. + axis_i(NX_NUMBER): doc: | - Coordinate along x direction. + Point coordinate along the fast dimension. unit: NX_LENGTH - dim: (n_x,) + dim: (n_i,) \@long_name(NX_CHAR): doc: | - Pixel coordinate along x direction + Point coordinate along the fast dimension. axis_energy(NX_NUMBER): doc: | Energy axis @@ -138,42 +138,41 @@ NXspectrum_set(NXobject): doc: | Energy - spectrum_threed(NXdata): + spectrum_3d(NXdata): doc: | - One spectrum for each voxel of an equidistantly - sampled three-dimensional ROI. + One spectrum for point of a 3d ROI. intensity(NX_NUMBER): doc: | Counts unit: NX_UNITLESS - dim: (n_z, n_y, n_x, n_energy) + dim: (n_k, n_j, n_i, n_energy) \@long_name(NX_CHAR): doc: | Counts - axis_z(NX_NUMBER): + axis_k(NX_NUMBER): doc: | - Coordinate along z direction. + Point coordinate along the slower dimension. unit: NX_LENGTH - dim: (n_z,) + dim: (n_k,) \@long_name(NX_CHAR): doc: | - Pixel coordinate along z direction - axis_y(NX_NUMBER): + Point coordinate along the slower dimension. + axis_j(NX_NUMBER): doc: | - Coordinate along y direction. + Point coordinate along the slow dimension. unit: NX_LENGTH - dim: (n_y,) + dim: (n_j,) \@long_name(NX_CHAR): doc: | - Pixel coordinate along y direction - axis_x(NX_NUMBER): + Point coordinate along the slow dimension. + axis_i(NX_NUMBER): doc: | - Coordinate along x direction. + Point coordinate along the fast dimension. unit: NX_LENGTH - dim: (n_x,) + dim: (n_i,) \@long_name(NX_CHAR): doc: | - Pixel coordinate along x direction + Point coordinate along the fast dimension. axis_energy(NX_NUMBER): doc: | Energy axis @@ -186,27 +185,145 @@ NXspectrum_set(NXobject): # if there is interest to support arbitrary scan pattern one should use # scan points and contact us to generalize this base class and related # base classes - collection(NXdata): + stack_0d(NXdata): + doc: | + Multiple instances of spectrum_0d. + intensity(NX_NUMBER): + doc: | + Counts + unit: NX_UNITLESS + dim: (n_spc, n_energy) + \@long_name(NX_CHAR): + doc: | + Counts + group_identifier(NX_INT): + doc: | + Group identifier + unit: NX_UNITLESS + dim: (n_spc,) + \@long_name(NX_CHAR): + doc: | + Group identifier + spectrum_identifier(NX_INT): + doc: | + Spectrum identifier + unit: NX_UNITLESS + dim: (n_spc,) + \@long_name(NX_CHAR): + doc: | + Spectrum identifier + axis_energy(NX_NUMBER): + doc: | + Energy axis + unit: NX_ENERGY + dim: (n_energy,) + \@long_name(NX_CHAR): + doc: | + Energy + + stack_2d(NXdata): + doc: | + Multiple instances of spectrum_2d. + intensity(NX_NUMBER): + doc: | + Counts + unit: NX_UNITLESS + dim: (n_spc, n_j, n_i, n_energy) + \@long_name(NX_CHAR): + doc: | + Counts + group_identifier(NX_INT): + doc: | + Group identifier + unit: NX_UNITLESS + dim: (n_spc,) + \@long_name(NX_CHAR): + doc: | + Group identifier + spectrum_identifier(NX_INT): + doc: | + Spectrum identifier + unit: NX_UNITLESS + dim: (n_spc,) + \@long_name(NX_CHAR): + doc: | + Spectrum identifier + axis_j(NX_NUMBER): + doc: | + Point coordinate along the slow dimension. + unit: NX_LENGTH + dim: (n_j,) + \@long_name(NX_CHAR): + doc: | + Point coordinate along the slow dimension. + axis_i(NX_NUMBER): + doc: | + Point coordinate along the fast dimension. + unit: NX_LENGTH + dim: (n_i,) + \@long_name(NX_CHAR): + doc: | + Point coordinate along the fast dimension. + axis_energy(NX_NUMBER): + doc: | + Energy axis + unit: NX_ENERGY + dim: (n_energy,) + \@long_name(NX_CHAR): + doc: | + Energy + + stack_3d(NXdata): doc: | - One spectrum for each scan point. This representation supports - equidistant energy bins. For rectangular sampling use respective - one-, two-, and three-dimensional variants instead. + Multiple instances of spectrum_3d. intensity(NX_NUMBER): doc: | Counts unit: NX_UNITLESS - dim: (n_p, n_energy) + dim: (n_spc, n_k, n_j, n_i, n_energy) \@long_name(NX_CHAR): doc: | Counts - axis_scan_point_id(NX_INT): + group_identifier(NX_INT): + doc: | + Group identifier + unit: NX_UNITLESS + dim: (n_spc,) + \@long_name(NX_CHAR): + doc: | + Group identifier + spectrum_identifier(NX_INT): doc: | - Scan point identifier + Spectrum identifier unit: NX_UNITLESS - dim: (n_p,) + dim: (n_spc,) + \@long_name(NX_CHAR): + doc: | + Spectrum identifier + axis_k(NX_NUMBER): + doc: | + Point coordinate along the slower dimension. + unit: NX_LENGTH + dim: (n_k,) + \@long_name(NX_CHAR): + doc: | + Point coordinate along the slower dimension. + axis_j(NX_NUMBER): + doc: | + Point coordinate along the slow dimension. + unit: NX_LENGTH + dim: (n_j,) + \@long_name(NX_CHAR): + doc: | + Point coordinate along the slow dimension. + axis_i(NX_NUMBER): + doc: | + Point coordinate along the fast dimension. + unit: NX_LENGTH + dim: (n_i,) \@long_name(NX_CHAR): doc: | - Scan point identifier + Point coordinate along the fast dimension. axis_energy(NX_NUMBER): doc: | Energy axis diff --git a/dev_tools/tests/test_nxdl_utils.py b/dev_tools/tests/test_nxdl_utils.py index 19eccd7e85..59fec29433 100644 --- a/dev_tools/tests/test_nxdl_utils.py +++ b/dev_tools/tests/test_nxdl_utils.py @@ -78,19 +78,19 @@ def test_get_node_at_nxdl_path(): assert node.attrib["type"] == "NXem_msr" node = nexus.get_node_at_nxdl_path( - "/ENTRY/measurement/EVENT_DATA_EM_SET/EVENT_DATA_EM/IMAGE_SET/image_threed", + "/ENTRY/measurement/EVENT_DATA_EM_SET/EVENT_DATA_EM/IMAGE_SET/image_3d", elem=elem, ) assert node.attrib["type"] == "NXdata" node = nexus.get_node_at_nxdl_path( - "/ENTRY/measurement/EVENT_DATA_EM_SET/EVENT_DATA_EM/IMAGE_SET/image_threed/AXISNAME_indices", + "/ENTRY/measurement/EVENT_DATA_EM_SET/EVENT_DATA_EM/IMAGE_SET/image_3d/AXISNAME_indices", elem=elem, ) assert node.attrib["name"] == "AXISNAME_indices" node = nexus.get_node_at_nxdl_path( - "/ENTRY/measurement/EVENT_DATA_EM_SET/EVENT_DATA_EM/IMAGE_SET/image_threed/axis_j", + "/ENTRY/measurement/EVENT_DATA_EM_SET/EVENT_DATA_EM/IMAGE_SET/image_3d/axis_j", elem=elem, ) assert node.attrib["type"] == "NX_NUMBER" From 20b920794121776d5aa8ab1985431f29b57a3dfd Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 13 Aug 2024 11:55:24 +0200 Subject: [PATCH 0824/1012] Add circuit to component --- contributed_definitions/NXcomponent.nxdl.xml | 1 + contributed_definitions/nyaml/NXcomponent.yaml | 2 ++ 2 files changed, 3 insertions(+) diff --git a/contributed_definitions/NXcomponent.nxdl.xml b/contributed_definitions/NXcomponent.nxdl.xml index 603f8d3c1e..d317db6803 100644 --- a/contributed_definitions/NXcomponent.nxdl.xml +++ b/contributed_definitions/NXcomponent.nxdl.xml @@ -60,4 +60,5 @@ location and geometry of the component in the instrument. + diff --git a/contributed_definitions/nyaml/NXcomponent.yaml b/contributed_definitions/nyaml/NXcomponent.yaml index 61fd4205ae..a40ba48308 100644 --- a/contributed_definitions/nyaml/NXcomponent.yaml +++ b/contributed_definitions/nyaml/NXcomponent.yaml @@ -28,3 +28,5 @@ NXcomponent(NXobject): doc: | Collection of axis-based translations and rotations to describe the location and geometry of the component in the instrument. + (NXcircuit): + From 7a42b65666424fe7a8049533ee9e0d18e68104b3 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 13 Aug 2024 12:01:59 +0200 Subject: [PATCH 0825/1012] Adding routine tests for py3.12 --- .github/workflows/ci.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/ci.yaml b/.github/workflows/ci.yaml index 09bc967f55..fbf4bb3d3c 100755 --- a/.github/workflows/ci.yaml +++ b/.github/workflows/ci.yaml @@ -32,7 +32,7 @@ jobs: runs-on: ubuntu-latest strategy: matrix: - python-version: ['3.8', '3.9', '3.10', '3.11'] + python-version: ['3.8', '3.9', '3.10', '3.11', '3.12'] max-parallel: 5 env: python_version: ${{ matrix.python-version }} From 0e1e39f0923be11a44127c35f03e4c1ec684c46b Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 13 Aug 2024 15:21:25 +0200 Subject: [PATCH 0826/1012] Added circuit and corrected laziness error --- contributed_definitions/NXscanbox_em.nxdl.xml | 1 + contributed_definitions/NXstage_lab.nxdl.xml | 4 ++-- contributed_definitions/nyaml/NXscanbox_em.yaml | 1 + contributed_definitions/nyaml/NXstage_lab.yaml | 4 ++-- 4 files changed, 6 insertions(+), 4 deletions(-) diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/contributed_definitions/NXscanbox_em.nxdl.xml index eae75cd135..e0593714c1 100644 --- a/contributed_definitions/NXscanbox_em.nxdl.xml +++ b/contributed_definitions/NXscanbox_em.nxdl.xml @@ -104,6 +104,7 @@ + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index 9e225177df..296db4ca7b 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -134,13 +134,13 @@ - The interpretation of this tilt should be specialized + The interpretation of this rotation should be specialized and thus detailed via the application definition. - The interpretation of this tilt should be specialized + The interpretation of this position should be specialized and thus detailed via the application definition. diff --git a/contributed_definitions/nyaml/NXscanbox_em.yaml b/contributed_definitions/nyaml/NXscanbox_em.yaml index 10597ef5be..3176454f4f 100644 --- a/contributed_definitions/nyaml/NXscanbox_em.yaml +++ b/contributed_definitions/nyaml/NXscanbox_em.yaml @@ -73,6 +73,7 @@ NXscanbox_em(NXcomponent): # await discussion on base class NXscan_control # technical design perspective # (NXlens_em): (NXdeflector): + (NXcircuit): # (NXcg_point_set): # NEW ISSUE: build on work of EMglossary with HMC and use duty cycle instead # NEW ISSUE: make use of and define duty cycle diff --git a/contributed_definitions/nyaml/NXstage_lab.yaml b/contributed_definitions/nyaml/NXstage_lab.yaml index 326824c563..c649b77890 100644 --- a/contributed_definitions/nyaml/NXstage_lab.yaml +++ b/contributed_definitions/nyaml/NXstage_lab.yaml @@ -106,12 +106,12 @@ NXstage_lab(NXcomponent): unit: NX_ANGLE rotation(NX_NUMBER): doc: | - The interpretation of this tilt should be specialized + The interpretation of this rotation should be specialized and thus detailed via the application definition. unit: NX_ANGLE position(NX_NUMBER): doc: | - The interpretation of this tilt should be specialized + The interpretation of this position should be specialized and thus detailed via the application definition. unit: NX_LENGTH dim: (3,) From 44a21aea0ecc7308e3410e6f625a1284ea7b4fc8 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 13 Aug 2024 15:54:40 +0200 Subject: [PATCH 0827/1012] Editing NXem for aberrations in event data --- contributed_definitions/NXem.nxdl.xml | 123 +++++++++++++++++++++++- contributed_definitions/nyaml/NXem.yaml | 123 +++++++++++++++++++++++- 2 files changed, 239 insertions(+), 7 deletions(-) diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 88689abffa..1cfbe551e7 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -1034,11 +1034,126 @@ technical components of the corrector--> - + - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index d073e497a1..ead8c2f5ff 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -954,12 +954,129 @@ NXem(NXobject): corrector_cs(NXcorrector_cs): exists: [min, 0, max, infty] applied(NX_BOOLEAN): + exists: recommended zemlin_tableauID(NXprocess): exists: [min, 1, max, infty] - (NXprocess): - (NXaberration_model): + (NXaberration_model): + exists: optional + model(NX_CHAR): + c_1(NXaberration): + exists: optional + magnitude(NX_NUMBER): + a_1(NXaberration): + exists: optional + magnitude(NX_NUMBER): + b_2(NXaberration): + exists: optional + magnitude(NX_NUMBER): + a_2(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_3(NXaberration): + exists: optional + magnitude(NX_NUMBER): + s_3(NXaberration): + exists: optional + magnitude(NX_NUMBER): + a_3(NXaberration): + exists: optional + magnitude(NX_NUMBER): + b_4(NXaberration): + exists: optional + magnitude(NX_NUMBER): + d_4(NXaberration): + exists: optional + magnitude(NX_NUMBER): + a_4(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_5(NXaberration): + exists: optional + magnitude(NX_NUMBER): + s_5(NXaberration): + exists: optional + magnitude(NX_NUMBER): + r_5(NXaberration): + exists: optional + magnitude(NX_NUMBER): + a_6(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_1_0(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_1_2_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_1_2_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_2_1_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_2_1_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_2_3_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_2_3_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_3_0(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_3_2_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_3_2_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_3_4_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_3_4_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_4_1_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_4_1_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_4_3_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_4_3_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_4_5_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_4_5_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_5_0(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_5_2_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_5_2_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_5_4_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_5_4_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_5_6_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_5_6_b(NXaberration): exists: optional - model(NX_CHAR): + magnitude(NX_NUMBER): # we could write down how to store the aberrations but we should not force to add aberrations # basically optional use of NXaberration therein at least some value required corrector_ax(NXcomponent): From 03499a75ed1d651d69f590ed32635c010c6bd65b Mon Sep 17 00:00:00 2001 From: Ron Hildebrandt Date: Tue, 13 Aug 2024 16:03:39 +0200 Subject: [PATCH 0828/1012] Extension of Doc for Optical spectroscopy and Raman --- manual/source/ellipsometry-structure.rst | 50 +++++++++++++++++++++++- 1 file changed, 49 insertions(+), 1 deletion(-) diff --git a/manual/source/ellipsometry-structure.rst b/manual/source/ellipsometry-structure.rst index 255c3c5825..96d9e14717 100644 --- a/manual/source/ellipsometry-structure.rst +++ b/manual/source/ellipsometry-structure.rst @@ -5,9 +5,36 @@ Optical spectroscopy ==================== .. index:: + OpticalSpec1 Ellipsometry1 + Raman1 DispersiveMaterial1 +.. _OpticalSpec1: + +Optical Spectroscopy +############## + + + + +Application Definitions +----------------------- + +We created one application definition: + + :ref:`NXoptical_spectroscopy`: + A general application definition for optical spectroscopy measurements. This includes specifically: + photoluminescence + transmission spectroscopy + reflection spectroscopy + and general spectroscopy experiments + + General spectroscopy experiments refer to experiments of the type photon-in photon-out. A detector is required to measure the "photon-out"-signal. + For Ellipsomertry and Raman spectroscopy are specific application definitions listed below. + + + .. _Ellipsometry1: @@ -16,7 +43,7 @@ Ellipsometry Ellipsometry is an optical characterization method to describe optical properties of interfaces and thickness of films. The measurements are based on determining how the polarization state of light changes upon transmission and reflection. Interpretation is based on Fresnel equations and numerical models of the optical properties of the materials. -In the application definition we provide a minimum set of description elements allowing for a reproducible recording of ellipsometry measurements. +This application definition is an extension of :ref:`NXoptical_spectroscopy`. It provide a minimum set of description elements allowing for a reproducible recording of ellipsometry measurements. Application Definitions @@ -28,6 +55,27 @@ We created one application definition: A general application definition for ellipsometry measurements, including complex systems up to variable angle spectroscopic ellipsometry. +.. _Raman1: + +Raman NXoptical_spectroscopy +############## + +Raman spectroscopy is an optical characterization method by measuring elastic light scattering. In this way phonon characteristics are measured for a extreme broad range of samples: gasses, liquids, solids, glasses, crystals. + +The application definition provides an extension of :ref:`NXoptical_spectroscopy` to cover required or relevant data from Raman scattering experiments. + + +Application Definitions +----------------------- + +We created one application definition: + + :ref:`NXraman`: + A general application definition for Raman measurements. + + + + Dispersive Material ################### From bcbe7089ca5cf52dd0d19bbccedfc1a858f60463 Mon Sep 17 00:00:00 2001 From: Ron Hildebrandt Date: Tue, 13 Aug 2024 16:30:18 +0200 Subject: [PATCH 0829/1012] Update webpage for optical spectroscopy --- dev_tools/docs/nxdl_index.py | 2 +- manual/source/index.rst | 2 +- ...sometry-structure.rst => optical-spectroscopy-structure.rst} | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) rename manual/source/{ellipsometry-structure.rst => optical-spectroscopy-structure.rst} (99%) diff --git a/dev_tools/docs/nxdl_index.py b/dev_tools/docs/nxdl_index.py index 61725ced4e..3fe3ab554c 100644 --- a/dev_tools/docs/nxdl_index.py +++ b/dev_tools/docs/nxdl_index.py @@ -68,7 +68,7 @@ def nxdl_indices() -> Dict[str, dict]: print("---------++++++++-", section) if file.endswith("contributed_definitions/index.rst"): rst_lines.append(f"{indentation}em-structure\n") - rst_lines.append(f"{indentation}ellipsometry-structure\n") + rst_lines.append(f"{indentation}optical-spectroscopy\n") rst_lines.append(f"{indentation}mpes-structure\n") rst_lines.append(f"{indentation}apm-structure\n") rst_lines.append(f"{indentation}transport-structure\n") diff --git a/manual/source/index.rst b/manual/source/index.rst index d2d0ee59b8..a91669d024 100644 --- a/manual/source/index.rst +++ b/manual/source/index.rst @@ -14,7 +14,7 @@ https://www.nexusformat.org/ nexus-index em-structure mpes-structure - ellipsometry-structure + optical-spectroscopy apm-structure transport-structure sts-structure diff --git a/manual/source/ellipsometry-structure.rst b/manual/source/optical-spectroscopy-structure.rst similarity index 99% rename from manual/source/ellipsometry-structure.rst rename to manual/source/optical-spectroscopy-structure.rst index 96d9e14717..954c2a9ceb 100644 --- a/manual/source/ellipsometry-structure.rst +++ b/manual/source/optical-spectroscopy-structure.rst @@ -57,7 +57,7 @@ We created one application definition: .. _Raman1: -Raman NXoptical_spectroscopy +Raman spectroscopy ############## Raman spectroscopy is an optical characterization method by measuring elastic light scattering. In this way phonon characteristics are measured for a extreme broad range of samples: gasses, liquids, solids, glasses, crystals. From 58d752389daac24a69756d780a9f171658b9a839 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 14 Aug 2024 10:22:16 +0200 Subject: [PATCH 0830/1012] Further simplification of where and how to store aberrations --- .../NXaberration_model.nxdl.xml | 121 --------- .../NXcorrector_cs.nxdl.xml | 100 ++++++- contributed_definitions/NXem.nxdl.xml | 248 ++++++++--------- .../nyaml/NXaberration_model.yaml | 101 ------- .../nyaml/NXcorrector_cs.yaml | 93 ++++++- contributed_definitions/nyaml/NXem.yaml | 252 +++++++++--------- .../contributed_definitions/em-structure.rst | 10 +- 7 files changed, 437 insertions(+), 488 deletions(-) delete mode 100644 contributed_definitions/NXaberration_model.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXaberration_model.yaml diff --git a/contributed_definitions/NXaberration_model.nxdl.xml b/contributed_definitions/NXaberration_model.nxdl.xml deleted file mode 100644 index 92a81762d0..0000000000 --- a/contributed_definitions/NXaberration_model.nxdl.xml +++ /dev/null @@ -1,121 +0,0 @@ - - - - - - Models for aberrations of electro-magnetic lenses in electron microscopy. - - See `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) - for different definitions available and further details. Table 7-2 of Ibid. - publication (page 305ff) documents how to convert from the Nion to the - CEOS definitions. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 78c03a2c54..1b43799bae 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -56,8 +56,8 @@ Was the corrector used? - - + + Specific information about the alignment procedure that is a process during which the corrector is configured to enable calibrated usage of the instrument. @@ -105,14 +105,102 @@ The images taken during the alignment procedure. - + Place for storing measured or estimated aberrations (for each image or final). + + See `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) + for different definitions available and further details. Table 7-2 of Ibid. publication (page 305ff) documents how + to convert from the Nion to the CEOS definitions. Conversion tables are also summarized by `Y. Liao <https://www.globalsino.com/EM/page3740.html>`_. - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 1cfbe551e7..4ade175603 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -415,7 +415,7 @@ inherited objects from NXebeam_column have to be specified that is when one wish e.g. a combination of cardinality constraints or concept symbol constraints i.e. use NXfabrication from NXsource but demand it to be labelled with the symbol fabrication likewise if you provide fabrication details you need to provide vendor and model but not necessarily identifier--> - + @@ -534,7 +534,7 @@ lenses i.e. devices which can affect the pathes of beams - + @@ -987,7 +987,7 @@ lenses i.e. devices which can affect the pathes of beams - + @@ -1035,126 +1035,126 @@ technical components of the corrector--> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -1206,7 +1206,7 @@ basically optional use of NXaberration therein at least some value required--> - + diff --git a/contributed_definitions/nyaml/NXaberration_model.yaml b/contributed_definitions/nyaml/NXaberration_model.yaml deleted file mode 100644 index bb53dff370..0000000000 --- a/contributed_definitions/nyaml/NXaberration_model.yaml +++ /dev/null @@ -1,101 +0,0 @@ -category: base -doc: | - Models for aberrations of electro-magnetic lenses in electron microscopy. - - See `S. J. Pennycock and P. D. Nellist `_ (page 44ff, and page 118ff) - for different definitions available and further details. Table 7-2 of Ibid. - publication (page 305ff) documents how to convert from the Nion to the - CEOS definitions. -type: group -NXaberration_model(NXobject): - model: - enumeration: [ceos, nion] - # (NXaberration): - - # specifically-named aberrations following the CEOS convention - c_1(NXaberration): - a_1(NXaberration): - b_2(NXaberration): - a_2(NXaberration): - c_3(NXaberration): - s_3(NXaberration): - a_3(NXaberration): - # based on feedback from Thilo Remmele the following aberrations could be measured - # (enhanced mode, tilt angle > 30 mrad) but are not corrected - b_4(NXaberration): - d_4(NXaberration): - a_4(NXaberration): - c_5(NXaberration): - s_5(NXaberration): - r_5(NXaberration): - a_6(NXaberration): - - # further comments from Thilo Remmele (Leibniz-Institut für Kristallzüchtung) - # ThermoFisher uses CEOS correctors but makes customizations to these in their microscopes - # Aberration naming schema: C_order_multiplicity (similar to NXem, but with - # another coordinate system and in addition with a confidence entry. - # Aberrations with multiplicity 0 have no angle entry (C1,C3,C5,.., CEOS notation) - # contrast transferfuntion: ctf = e^(-i*Xi(g)) in Fourier space - # aberration function: - # Xi(g) = 2*pi/lamda{ 1/2 * (lamda*g)^2 (C20 + C22 cos[2(phi-phi_22)] - # +1/3 * (lamda*g)^3 (C31 cos[(phi-phi_31) + C33 cos[3(phi-phi_33) - # +1/4 * (lamda*g)^4 (C40 + C42 cos[2(phi-phi_42)] + C44 cos[4(phi-phi_42)] - # +1/f * (lamda*g)^f Sum (Cfm cos[m(phi-phi_fm)] where m=[0,2,..f] for even f and m=[1,3,..,f] for odd f - - # Thilo Remmele also mentions that there is a mapping of aberration coefficient names: - # C_2_0 -> C1 Defocus - # C_2_2 -> A1 2-fold astigmatism - # C_3_3 -> A2 3-fold astigmatism - # C_3_1 -> B2 axial coma - # C_4_0 -> C3 spherical aberration - # C_4_4 -> A3 4-fold astigmatism - # C_4_2 -> S3 star aberration - # C_5_5 -> A4 5-fold astigmatism - - # C_5_1 -> B4 axial coma - # C_5_3 -> D4 three lobe aberration - # C_6_0 -> C5 spherical aberration - # C_6_2 -> S5 star aberration - # C_6_4 -> R5 rosette aberration - # C_6_6 -> A5 6-fold astigmatism - - # In a session with HRTEM images the corrector is commonly aligned. - # The final measurement with the estimated residual aberrations - # should be saved in a corrector.html file (an example is appended - # at the end of this file. Unfortunately the datetime is not included - # in that html output, nor is the used outer tilt angle and exposure time. - # The datetime may be estimated from the file datetime and the Delta t entry, - # but caution if that datetime is not preserved on file transfers! - # More than one detector entry could occure but is not common. - # A seperate corrector schema, so it can be easily exchanged to other correctors if necessary. - # It might be useful to collect all the corrector entries in one table, for example to analyse the performance of the corrector. - # The corrector entry of the nexus em definition lacks the confidence information and the - # parameter settings for the estimation oft the aberrations. - - # specifically-named aberrations following the Nion convention - c_1_0(NXaberration): - c_1_2_a(NXaberration): - c_1_2_b(NXaberration): - c_2_1_a(NXaberration): - c_2_1_b(NXaberration): - c_2_3_a(NXaberration): - c_2_3_b(NXaberration): - c_3_0(NXaberration): - c_3_2_a(NXaberration): - c_3_2_b(NXaberration): - c_3_4_a(NXaberration): - c_3_4_b(NXaberration): - c_4_1_a(NXaberration): - c_4_1_b(NXaberration): - c_4_3_a(NXaberration): - c_4_3_b(NXaberration): - c_4_5_a(NXaberration): - c_4_5_b(NXaberration): - c_5_0(NXaberration): - c_5_2_a(NXaberration): - c_5_2_b(NXaberration): - c_5_4_a(NXaberration): - c_5_4_b(NXaberration): - c_5_6_a(NXaberration): - c_5_6_b(NXaberration): - diff --git a/contributed_definitions/nyaml/NXcorrector_cs.yaml b/contributed_definitions/nyaml/NXcorrector_cs.yaml index 615598af2c..941885b1f5 100644 --- a/contributed_definitions/nyaml/NXcorrector_cs.yaml +++ b/contributed_definitions/nyaml/NXcorrector_cs.yaml @@ -28,8 +28,8 @@ NXcorrector_cs(NXcomponent): applied(NX_BOOLEAN): doc: | Was the corrector used? - # NEW ISSUE: clarify the mathematical details behind the - zemlin_tableauID(NXprocess): + # NEW ISSUE: clarify further mathematical details + tableauID(NXprocess): doc: | Specific information about the alignment procedure that is a process during which the corrector is configured to enable calibrated usage of the instrument. @@ -62,10 +62,95 @@ NXcorrector_cs(NXcomponent): (NXimage_set): doc: | The images taken during the alignment procedure. - (NXprocess): + model(NX_CHAR): doc: | Place for storing measured or estimated aberrations (for each image or final). - (NXaberration_model): + + See `S. J. Pennycock and P. D. Nellist `_ (page 44ff, and page 118ff) + for different definitions available and further details. Table 7-2 of Ibid. publication (page 305ff) documents how + to convert from the Nion to the CEOS definitions. Conversion tables are also summarized by `Y. Liao `_. + enumeration: [ceos, nion] + # specifically-named aberrations following the CEOS convention + c_1(NXaberration): + a_1(NXaberration): + b_2(NXaberration): + a_2(NXaberration): + c_3(NXaberration): + s_3(NXaberration): + a_3(NXaberration): + # based on feedback from Thilo Remmele the following aberrations could be measured + # (enhanced mode, tilt angle > 30 mrad) but are not corrected for with + b_4(NXaberration): + d_4(NXaberration): + a_4(NXaberration): + c_5(NXaberration): + s_5(NXaberration): + r_5(NXaberration): + a_6(NXaberration): + # specifically-named aberrations following the Nion convention + c_1_0(NXaberration): + c_1_2_a(NXaberration): + c_1_2_b(NXaberration): + c_2_1_a(NXaberration): + c_2_1_b(NXaberration): + c_2_3_a(NXaberration): + c_2_3_b(NXaberration): + c_3_0(NXaberration): + c_3_2_a(NXaberration): + c_3_2_b(NXaberration): + c_3_4_a(NXaberration): + c_3_4_b(NXaberration): + c_4_1_a(NXaberration): + c_4_1_b(NXaberration): + c_4_3_a(NXaberration): + c_4_3_b(NXaberration): + c_4_5_a(NXaberration): + c_4_5_b(NXaberration): + c_5_0(NXaberration): + c_5_2_a(NXaberration): + c_5_2_b(NXaberration): + c_5_4_a(NXaberration): + c_5_4_b(NXaberration): + c_5_6_a(NXaberration): + c_5_6_b(NXaberration): + # further comments from Thilo Remmele (Leibniz-Institut für Kristallzüchtung) + # ThermoFisher uses CEOS correctors but makes customizations to these in their microscopes + # Aberration naming schema: C_order_multiplicity (similar to NXem, but with + # another coordinate system and in addition with a confidence entry. + # Aberrations with multiplicity 0 have no angle entry (C1,C3,C5,.., CEOS notation) + # contrast transferfuntion: ctf = e^(-i*Xi(g)) in Fourier space + # aberration function: + # Xi(g) = 2*pi/lamda{ 1/2 * (lamda*g)^2 (C20 + C22 cos[2(phi-phi_22)] + # +1/3 * (lamda*g)^3 (C31 cos[(phi-phi_31) + C33 cos[3(phi-phi_33) + # +1/4 * (lamda*g)^4 (C40 + C42 cos[2(phi-phi_42)] + C44 cos[4(phi-phi_42)] + # +1/f * (lamda*g)^f Sum (Cfm cos[m(phi-phi_fm)] where m=[0,2,..f] for even f and m=[1,3,..,f] for odd f + # Thilo Remmele also mentions that there is a mapping of aberration coefficient names: + # C_2_0 -> C1 Defocus + # C_2_2 -> A1 2-fold astigmatism + # C_3_3 -> A2 3-fold astigmatism + # C_3_1 -> B2 axial coma + # C_4_0 -> C3 spherical aberration + # C_4_4 -> A3 4-fold astigmatism + # C_4_2 -> S3 star aberration + # C_5_5 -> A4 5-fold astigmatism + # C_5_1 -> B4 axial coma + # C_5_3 -> D4 three lobe aberration + # C_6_0 -> C5 spherical aberration + # C_6_2 -> S5 star aberration + # C_6_4 -> R5 rosette aberration + # C_6_6 -> A5 6-fold astigmatism + # In a session with HRTEM images the corrector is commonly aligned. + # The final measurement with the estimated residual aberrations + # should be saved in a corrector.html file (an example is appended + # at the end of this file. Unfortunately the datetime is not included + # in that html output, nor is the used outer tilt angle and exposure time. + # The datetime may be estimated from the file datetime and the Delta t entry, + # but caution if that datetime is not preserved on file transfers! + # More than one detector entry could occure but is not common. + # A seperate corrector schema, so it can be easily exchanged to other correctors if necessary. + # It might be useful to collect all the corrector entries in one table, for example to analyse the performance of the corrector. + # The corrector entry of the nexus em definition lacks the confidence information and the + # parameter settings for the estimation oft the aberrations. # technical design perspective (NXlens_em): (NXaperture): diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index ead8c2f5ff..1fae42206a 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -379,7 +379,7 @@ NXem(NXobject): # e.g. a combination of cardinality constraints or concept symbol constraints # i.e. use NXfabrication from NXsource but demand it to be labelled with the symbol fabrication # likewise if you provide fabrication details you need to provide vendor and model but not necessarily identifier - lens_emID(NXlens_em): + lensID(NXlens_em): exists: [min, 0, max, infty] fabrication(NXfabrication): exists: optional @@ -494,7 +494,7 @@ NXem(NXobject): exists: recommended ion_source(NXsource): probe(NXion): - lens_emID(NXlens_em): + lensID(NXlens_em): exists: [min, 0, max, infty] fabrication(NXfabrication): exists: optional @@ -904,7 +904,7 @@ NXem(NXobject): term: Filament Current url: https://purls.helmholtz-metadaten.de/emg/EMG_00000027 unit: NX_CURRENT - lens_emID(NXlens_em): + lensID(NXlens_em): exists: [min, 0, max, infty] apertureID(NXaperture): exists: [min, 0, max, infty] @@ -955,130 +955,130 @@ NXem(NXobject): exists: [min, 0, max, infty] applied(NX_BOOLEAN): exists: recommended - zemlin_tableauID(NXprocess): + tableauID(NXprocess): exists: [min, 1, max, infty] - (NXaberration_model): + model(NX_CHAR): + # ceos + c_1(NXaberration): exists: optional - model(NX_CHAR): - c_1(NXaberration): - exists: optional - magnitude(NX_NUMBER): - a_1(NXaberration): - exists: optional - magnitude(NX_NUMBER): - b_2(NXaberration): - exists: optional - magnitude(NX_NUMBER): - a_2(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_3(NXaberration): - exists: optional - magnitude(NX_NUMBER): - s_3(NXaberration): - exists: optional - magnitude(NX_NUMBER): - a_3(NXaberration): - exists: optional - magnitude(NX_NUMBER): - b_4(NXaberration): - exists: optional - magnitude(NX_NUMBER): - d_4(NXaberration): - exists: optional - magnitude(NX_NUMBER): - a_4(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_5(NXaberration): - exists: optional - magnitude(NX_NUMBER): - s_5(NXaberration): - exists: optional - magnitude(NX_NUMBER): - r_5(NXaberration): - exists: optional - magnitude(NX_NUMBER): - a_6(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_1_0(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_1_2_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_1_2_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_2_1_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_2_1_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_2_3_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_2_3_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_3_0(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_3_2_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_3_2_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_3_4_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_3_4_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_4_1_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_4_1_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_4_3_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_4_3_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_4_5_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_4_5_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_5_0(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_5_2_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_5_2_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_5_4_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_5_4_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_5_6_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_5_6_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - # we could write down how to store the aberrations but we should not force to add aberrations - # basically optional use of NXaberration therein at least some value required + magnitude(NX_NUMBER): + a_1(NXaberration): + exists: optional + magnitude(NX_NUMBER): + b_2(NXaberration): + exists: optional + magnitude(NX_NUMBER): + a_2(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_3(NXaberration): + exists: optional + magnitude(NX_NUMBER): + s_3(NXaberration): + exists: optional + magnitude(NX_NUMBER): + a_3(NXaberration): + exists: optional + magnitude(NX_NUMBER): + b_4(NXaberration): + exists: optional + magnitude(NX_NUMBER): + d_4(NXaberration): + exists: optional + magnitude(NX_NUMBER): + a_4(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_5(NXaberration): + exists: optional + magnitude(NX_NUMBER): + s_5(NXaberration): + exists: optional + magnitude(NX_NUMBER): + r_5(NXaberration): + exists: optional + magnitude(NX_NUMBER): + a_6(NXaberration): + exists: optional + magnitude(NX_NUMBER): + # nion + c_1_0(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_1_2_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_1_2_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_2_1_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_2_1_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_2_3_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_2_3_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_3_0(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_3_2_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_3_2_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_3_4_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_3_4_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_4_1_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_4_1_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_4_3_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_4_3_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_4_5_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_4_5_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_5_0(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_5_2_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_5_2_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_5_4_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_5_4_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_5_6_a(NXaberration): + exists: optional + magnitude(NX_NUMBER): + c_5_6_b(NXaberration): + exists: optional + magnitude(NX_NUMBER): + # we could write down how to store the aberrations but we should not force to add aberrations + # basically optional use of NXaberration therein at least some value required corrector_ax(NXcomponent): exists: [min, 0, max, 1] doc: @@ -1129,7 +1129,7 @@ NXem(NXobject): ion_source(NXsource): probe(NXion): voltage(NX_NUMBER): - lens_emID(NXlens_em): + lensID(NXlens_em): exists: [min, 0, max, infty] apertureID(NXaperture): exists: [min, 0, max, infty] diff --git a/manual/source/classes/contributed_definitions/em-structure.rst b/manual/source/classes/contributed_definitions/em-structure.rst index fbfc984515..4e586e21a3 100644 --- a/manual/source/classes/contributed_definitions/em-structure.rst +++ b/manual/source/classes/contributed_definitions/em-structure.rst @@ -88,13 +88,11 @@ The following base classes are proposed to support modularizing the storage of p Base classes to describe different coordinate systems used and/or to be harmonized or transformed into one another and respective transformations. - :ref:`NXaberration_model`, :ref:`NXaberration`: + :ref:`NXcorrector_cs`, :ref:`NXaberration`: Base classes to describe procedures and values for the calibration of aberrations based on - conventions of different companies active in the field of aberration correction. - - :ref:`NXcorrector_cs`: - A base class to describe details about corrective lens or compound lens devices - which reduce the (spherical) aberrations of an electron beam. + conventions of different companies active in the field of aberration correction including a base class + to describe details about corrective lens or compound lens devices which reduce + (spherical) aberrations of an electron beam. :ref:`NXscanbox_em`: A base class to represent the component of an electron microscope which realizes a controlled deflection From 8b0520045c6a1740d839af3b5286ac2601837f08 Mon Sep 17 00:00:00 2001 From: Ron Hildebrandt Date: Wed, 14 Aug 2024 10:26:25 +0200 Subject: [PATCH 0831/1012] change ellips name to optical spec --- dev_tools/docs/nxdl_index.py | 2 +- ...sometry-structure.rst => optical-spectroscopy-structure.rst} | 2 +- manual/source/index.rst | 2 +- manual/source/optical-spectroscopy-structure.rst | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) rename manual/source/classes/contributed_definitions/{ellipsometry-structure.rst => optical-spectroscopy-structure.rst} (99%) diff --git a/dev_tools/docs/nxdl_index.py b/dev_tools/docs/nxdl_index.py index 3fe3ab554c..b690be552a 100644 --- a/dev_tools/docs/nxdl_index.py +++ b/dev_tools/docs/nxdl_index.py @@ -68,7 +68,7 @@ def nxdl_indices() -> Dict[str, dict]: print("---------++++++++-", section) if file.endswith("contributed_definitions/index.rst"): rst_lines.append(f"{indentation}em-structure\n") - rst_lines.append(f"{indentation}optical-spectroscopy\n") + rst_lines.append(f"{indentation}optical-spectroscopy-structure\n") rst_lines.append(f"{indentation}mpes-structure\n") rst_lines.append(f"{indentation}apm-structure\n") rst_lines.append(f"{indentation}transport-structure\n") diff --git a/manual/source/classes/contributed_definitions/ellipsometry-structure.rst b/manual/source/classes/contributed_definitions/optical-spectroscopy-structure.rst similarity index 99% rename from manual/source/classes/contributed_definitions/ellipsometry-structure.rst rename to manual/source/classes/contributed_definitions/optical-spectroscopy-structure.rst index f3b66a547d..183cc0e5bf 100644 --- a/manual/source/classes/contributed_definitions/ellipsometry-structure.rst +++ b/manual/source/classes/contributed_definitions/optical-spectroscopy-structure.rst @@ -1,4 +1,4 @@ -.. _Ellipsometry-Structure: +.. _Optical-Spectroscopy-Structure: ==================== Optical Spectroscopy diff --git a/manual/source/index.rst b/manual/source/index.rst index a91669d024..962b7f6915 100644 --- a/manual/source/index.rst +++ b/manual/source/index.rst @@ -14,7 +14,7 @@ https://www.nexusformat.org/ nexus-index em-structure mpes-structure - optical-spectroscopy + optical-spectroscopy-structure apm-structure transport-structure sts-structure diff --git a/manual/source/optical-spectroscopy-structure.rst b/manual/source/optical-spectroscopy-structure.rst index 954c2a9ceb..c5ad40f4a2 100644 --- a/manual/source/optical-spectroscopy-structure.rst +++ b/manual/source/optical-spectroscopy-structure.rst @@ -1,4 +1,4 @@ -.. _Ellipsometry-Structure-Fairmat: +.. _Optical-Spectroscopy-Structure-Fairmat: ==================== Optical spectroscopy From 765626ecdfc3163490db4b71aaec12a177cc9fa9 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 14 Aug 2024 10:54:28 +0200 Subject: [PATCH 0832/1012] Use something from lensID --- contributed_definitions/NXem.nxdl.xml | 12 ++++++++---- contributed_definitions/nyaml/NXem.yaml | 6 ++++-- 2 files changed, 12 insertions(+), 6 deletions(-) diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 4ade175603..9c4c1c01ff 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -498,7 +498,7 @@ like it is an glass lens (i.e. optical) NXlens but both concepts have in common that they can be assumed to be specialization of a super class lenses i.e. devices which can affect the pathes of beams --> - + Device that causes a change in the phase of an electron wave. @@ -987,7 +987,9 @@ lenses i.e. devices which can affect the pathes of beams - + + + @@ -1190,7 +1192,7 @@ basically optional use of NXaberration therein at least some value required--> - + @@ -1206,7 +1208,9 @@ basically optional use of NXaberration therein at least some value required--> - + + + diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index 1fae42206a..908523f267 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -452,7 +452,7 @@ NXem(NXobject): model(NX_CHAR): identifier(NX_CHAR): exists: recommended - phase_plateID(NXcomponent): + phaseplateID(NXcomponent): # contributed definition NXwaveplate is a closely related concept but may fit even better but waveplate # has been defined from the perspective of classical optics # same challenge like with NXlens and NXlens_em, an electrostatic lens is not the same concept @@ -906,6 +906,7 @@ NXem(NXobject): unit: NX_CURRENT lensID(NXlens_em): exists: [min, 0, max, infty] + value(NX_NUMBER): apertureID(NXaperture): exists: [min, 0, max, infty] value(NX_NUMBER): @@ -1110,7 +1111,7 @@ NXem(NXobject): unit: NX_ANY biprism(NXcomponent): exists: [min, 0, max, 1] - phase_plateID(NXcomponent): + phaseplateID(NXcomponent): exists: [min, 0, max, infty] sensorID(NXsensor): exists: [min, 0, max, infty] @@ -1131,6 +1132,7 @@ NXem(NXobject): voltage(NX_NUMBER): lensID(NXlens_em): exists: [min, 0, max, infty] + value(NX_NUMBER): apertureID(NXaperture): exists: [min, 0, max, infty] value(NX_NUMBER): From 9186ed2d3684063c215b65fb419c4559d316e180 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 14 Aug 2024 12:22:41 +0200 Subject: [PATCH 0833/1012] Correcting units for complex aberrations --- contributed_definitions/NXaberration.nxdl.xml | 4 ++-- contributed_definitions/NXcorrector_cs.nxdl.xml | 14 +++++++++++++- contributed_definitions/NXem.nxdl.xml | 2 +- contributed_definitions/nyaml/NXaberration.yaml | 4 ++-- contributed_definitions/nyaml/NXcorrector_cs.yaml | 14 +++++++++++++- contributed_definitions/nyaml/NXem.yaml | 2 +- 6 files changed, 32 insertions(+), 8 deletions(-) diff --git a/contributed_definitions/NXaberration.nxdl.xml b/contributed_definitions/NXaberration.nxdl.xml index da4ea10dee..44160b54fb 100644 --- a/contributed_definitions/NXaberration.nxdl.xml +++ b/contributed_definitions/NXaberration.nxdl.xml @@ -25,12 +25,12 @@ Quantified aberration coefficient in an aberration_model. - + Value of the aberration coefficient. - + Uncertainty of the value of the aberration coefficient according to uncertainty_model. diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 1b43799bae..81a2e13d5d 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -118,12 +118,16 @@ - + + + + @@ -144,6 +152,8 @@ + @@ -155,6 +165,8 @@ + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 9c4c1c01ff..7a2ed3bbc7 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -1035,7 +1035,7 @@ technical components of the corrector--> - + diff --git a/contributed_definitions/nyaml/NXaberration.yaml b/contributed_definitions/nyaml/NXaberration.yaml index 9bbc1f462f..1185e6e5d2 100644 --- a/contributed_definitions/nyaml/NXaberration.yaml +++ b/contributed_definitions/nyaml/NXaberration.yaml @@ -6,12 +6,12 @@ NXaberration(NXobject): magnitude(NX_NUMBER): doc: | Value of the aberration coefficient. - unit: NX_LENGTH + unit: NX_ANY uncertainty(NX_NUMBER): doc: | Uncertainty of the value of the aberration coefficient according to uncertainty_model. - unit: NX_LENGTH + unit: NX_ANY uncertainty_model(NX_CHAR): doc: | How was the uncertainty quantified e.g. via the 95% confidence interval diff --git a/contributed_definitions/nyaml/NXcorrector_cs.yaml b/contributed_definitions/nyaml/NXcorrector_cs.yaml index 941885b1f5..e89a74d3c8 100644 --- a/contributed_definitions/nyaml/NXcorrector_cs.yaml +++ b/contributed_definitions/nyaml/NXcorrector_cs.yaml @@ -70,12 +70,16 @@ NXcorrector_cs(NXcomponent): for different definitions available and further details. Table 7-2 of Ibid. publication (page 305ff) documents how to convert from the Nion to the CEOS definitions. Conversion tables are also summarized by `Y. Liao `_. enumeration: [ceos, nion] - # specifically-named aberrations following the CEOS convention + # specifically-named aberrations following the CEOS / Typke and Dierksen convention c_1(NXaberration): + # magnitude(NX_NUMBER): + # unit: NX_LENGTH a_1(NXaberration): b_2(NXaberration): a_2(NXaberration): c_3(NXaberration): + # magnitude(NX_NUMBER): + # unit: NX_LENGTH s_3(NXaberration): a_3(NXaberration): # based on feedback from Thilo Remmele the following aberrations could be measured @@ -84,11 +88,15 @@ NXcorrector_cs(NXcomponent): d_4(NXaberration): a_4(NXaberration): c_5(NXaberration): + # magnitude(NX_NUMBER): + # unit: NX_LENGTH s_5(NXaberration): r_5(NXaberration): a_6(NXaberration): # specifically-named aberrations following the Nion convention c_1_0(NXaberration): + # magnitude(NX_NUMBER): + # unit: NX_LENGTH c_1_2_a(NXaberration): c_1_2_b(NXaberration): c_2_1_a(NXaberration): @@ -96,6 +104,8 @@ NXcorrector_cs(NXcomponent): c_2_3_a(NXaberration): c_2_3_b(NXaberration): c_3_0(NXaberration): + # magnitude(NX_NUMBER): + # unit: NX_LENGTH c_3_2_a(NXaberration): c_3_2_b(NXaberration): c_3_4_a(NXaberration): @@ -107,6 +117,8 @@ NXcorrector_cs(NXcomponent): c_4_5_a(NXaberration): c_4_5_b(NXaberration): c_5_0(NXaberration): + # magnitude(NX_NUMBER): + # unit: NX_LENGTH c_5_2_a(NXaberration): c_5_2_b(NXaberration): c_5_4_a(NXaberration): diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index 908523f267..60a7abe129 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -953,7 +953,7 @@ NXem(NXobject): Corresponding voltage for that energy dispersion. unit: NX_VOLTAGE corrector_cs(NXcorrector_cs): - exists: [min, 0, max, infty] + exists: [min, 0, max, 1] # but there are systems with several ones https://www.globalsino.com/EM/page4263.html applied(NX_BOOLEAN): exists: recommended tableauID(NXprocess): From 1debcc98be36b6870549e9ddae6a95ca1c9c6aab Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 14 Aug 2024 12:35:03 +0200 Subject: [PATCH 0834/1012] Removed mandatory model for aberrations as clear for naming conventions used --- contributed_definitions/NXem.nxdl.xml | 5 +++-- contributed_definitions/nyaml/NXem.yaml | 3 ++- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 7a2ed3bbc7..47725ab7f4 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -1038,8 +1038,9 @@ technical components of the corrector--> - - + diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index 60a7abe129..2326f0878e 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -958,7 +958,8 @@ NXem(NXobject): exists: recommended tableauID(NXprocess): exists: [min, 1, max, infty] - model(NX_CHAR): + # model(NX_CHAR): + # exists: optional # ceos c_1(NXaberration): exists: optional From 7300b1cbec710eb58090886de4da8399ffcd6899 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 16 Aug 2024 21:07:12 +0200 Subject: [PATCH 0835/1012] Reference Rafal for aberration function --- contributed_definitions/NXcorrector_cs.nxdl.xml | 2 ++ contributed_definitions/nyaml/NXcorrector_cs.yaml | 1 + 2 files changed, 3 insertions(+) diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 81a2e13d5d..a6f57819b6 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -21,6 +21,8 @@ # # For further information, see http://www.nexusformat.org --> + diff --git a/contributed_definitions/nyaml/NXcorrector_cs.yaml b/contributed_definitions/nyaml/NXcorrector_cs.yaml index e89a74d3c8..f23f7e07a6 100644 --- a/contributed_definitions/nyaml/NXcorrector_cs.yaml +++ b/contributed_definitions/nyaml/NXcorrector_cs.yaml @@ -17,6 +17,7 @@ doc: | * :ref:`NXmonochromator` for energy filtering or chromatic aberration * corrector_ax in :ref:`NXem` for axial astigmatism correction +# https://doi.org/10.1017/9781316337455.022 type: group symbols: doc: | From 24d78d6dfda38ca5de3ce350245ea6772cf18b4b Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 20 Aug 2024 16:58:12 +0200 Subject: [PATCH 0836/1012] Fixed time(NX_TIME) bug --- .../NXmicrostructure_gragles_results.nxdl.xml | 4 ++-- .../NXmicrostructure_score_results.nxdl.xml | 6 +++--- .../nyaml/NXmicrostructure_gragles_results.yaml | 4 ++-- .../nyaml/NXmicrostructure_score_results.yaml | 6 +++--- 4 files changed, 10 insertions(+), 10 deletions(-) diff --git a/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml b/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml index 12b5e5e7c1..2f25c33a61 100644 --- a/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml @@ -116,7 +116,7 @@ the typical lean summary statistics flattened--> Evolution of the recrystallized volume fraction over time. - + Evolution of the physical time not to be confused with wall-clock time or profiling data. @@ -225,7 +225,7 @@ the typical lean summary statistics flattened--> - + diff --git a/contributed_definitions/NXmicrostructure_score_results.nxdl.xml b/contributed_definitions/NXmicrostructure_score_results.nxdl.xml index ae7fa72aea..1e9283c976 100644 --- a/contributed_definitions/NXmicrostructure_score_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_score_results.nxdl.xml @@ -239,7 +239,7 @@ the typical lean summary statistics flattened--> Evolution of the recrystallized volume fraction over time. - + Evolution of the physical time not to be confused with wall-clock time or profiling data. @@ -355,7 +355,7 @@ the typical lean summary statistics flattened--> - + @@ -536,7 +536,7 @@ the typical lean summary statistics flattened--> exists: recommended end_time(NX_DATE_TIME): exists: recommended - total_elapsed_time(NX_TIME): + total_elapsed_time(NX_NUMBER): number_of_processes(NX_POSINT): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT):--> diff --git a/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml index 5bc4e986d5..aea83c2235 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml @@ -71,7 +71,7 @@ NXmicrostructure_gragles_results(NXobject): exists: optional doc: | Evolution of the recrystallized volume fraction over time. - time(NX_TIME): + time(NX_NUMBER): doc: | Evolution of the physical time not to be confused with wall-clock time or profiling data. unit: NX_TIME @@ -136,7 +136,7 @@ NXmicrostructure_gragles_results(NXobject): # the typically storage-costlier snapshot data microstructureID(NXmicrostructure): exists: [min, 1, max, infty] # always storing starting configuration - time(NX_TIME): + time(NX_NUMBER): iteration(NX_INT): temperature(NX_FLOAT): doc: | diff --git a/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml index 33930925e0..0013926e25 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml @@ -142,7 +142,7 @@ NXmicrostructure_score_results(NXobject): exists: optional doc: | Evolution of the recrystallized volume fraction over time. - time(NX_TIME): + time(NX_NUMBER): doc: | Evolution of the physical time not to be confused with wall-clock time or profiling data. unit: NX_TIME @@ -211,7 +211,7 @@ NXmicrostructure_score_results(NXobject): # the typically storage-costlier snapshot data microstructureID(NXmicrostructure): exists: [min, 1, max, infty] # always storing starting configuration - time(NX_TIME): + time(NX_NUMBER): iteration(NX_INT): temperature(NX_FLOAT): doc: | @@ -336,7 +336,7 @@ NXmicrostructure_score_results(NXobject): # exists: recommended # end_time(NX_DATE_TIME): # exists: recommended - # total_elapsed_time(NX_TIME): + # total_elapsed_time(NX_NUMBER): # number_of_processes(NX_POSINT): # number_of_threads(NX_POSINT): # number_of_gpus(NX_POSINT): From c12d7c512fada687ff9faabb9298b5ad2cfa115c Mon Sep 17 00:00:00 2001 From: Ron Hildebrandt Date: Mon, 26 Aug 2024 10:52:55 +0200 Subject: [PATCH 0837/1012] fix_renaming_of_ellipsometry_to_optical_spec --- dev_tools/docs/nxdl_index.py | 2 +- .../source/optical-spectroscopy-structure.rst | 23 +++---------------- 2 files changed, 4 insertions(+), 21 deletions(-) diff --git a/dev_tools/docs/nxdl_index.py b/dev_tools/docs/nxdl_index.py index b690be552a..21cd999a96 100644 --- a/dev_tools/docs/nxdl_index.py +++ b/dev_tools/docs/nxdl_index.py @@ -163,7 +163,7 @@ def get_nxclass_description(nxdl_file: Path, namespaces) -> str: and acceptance as either a base class or application definition. Some contributions are grouped together: - :ref:`Optical Spectroscopy ` + :ref:`Optical Spectroscopy ` :ref:`Multi-dimensional Photoemission Spectroscopy ` diff --git a/manual/source/optical-spectroscopy-structure.rst b/manual/source/optical-spectroscopy-structure.rst index c5ad40f4a2..5549890c44 100644 --- a/manual/source/optical-spectroscopy-structure.rst +++ b/manual/source/optical-spectroscopy-structure.rst @@ -4,18 +4,6 @@ Optical spectroscopy ==================== -.. index:: - OpticalSpec1 - Ellipsometry1 - Raman1 - DispersiveMaterial1 - -.. _OpticalSpec1: - -Optical Spectroscopy -############## - - Application Definitions @@ -35,11 +23,8 @@ We created one application definition: - -.. _Ellipsometry1: - Ellipsometry -############## +############ Ellipsometry is an optical characterization method to describe optical properties of interfaces and thickness of films. The measurements are based on determining how the polarization state of light changes upon transmission and reflection. Interpretation is based on Fresnel equations and numerical models of the optical properties of the materials. @@ -51,14 +36,12 @@ Application Definitions We created one application definition: - :ref:`NXellipsometry`: - A general application definition for ellipsometry measurements, including complex systems up to variable angle spectroscopic ellipsometry. + A general application definition for ellipsometry measurements, including complex systems up to variable angle spectroscopic ellipsometry. -.. _Raman1: Raman spectroscopy -############## +################## Raman spectroscopy is an optical characterization method by measuring elastic light scattering. In this way phonon characteristics are measured for a extreme broad range of samples: gasses, liquids, solids, glasses, crystals. From 08b7a86e6b1ff6f23e492044f02a2a9e1d0bf147 Mon Sep 17 00:00:00 2001 From: Ron Hildebrandt Date: Mon, 26 Aug 2024 11:10:13 +0200 Subject: [PATCH 0838/1012] add missed links --- .../source/optical-spectroscopy-structure.rst | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/manual/source/optical-spectroscopy-structure.rst b/manual/source/optical-spectroscopy-structure.rst index 5549890c44..3551f29bcc 100644 --- a/manual/source/optical-spectroscopy-structure.rst +++ b/manual/source/optical-spectroscopy-structure.rst @@ -4,6 +4,18 @@ Optical spectroscopy ==================== +.. index:: + OpticalSpec1 + Ellipsometry1 + Raman1 + DispersiveMaterial1 + +.. _OpticalSpec1: + +Optical Spectroscopy +############## + + Application Definitions @@ -23,6 +35,9 @@ We created one application definition: + +.. _Ellipsometry1: + Ellipsometry ############ @@ -36,10 +51,12 @@ Application Definitions We created one application definition: - + :ref:`NXellipsometry`: A general application definition for ellipsometry measurements, including complex systems up to variable angle spectroscopic ellipsometry. +.. _Raman1: + Raman spectroscopy ################## From 24b0d20a5dfa49c5d3d8b1ee76daf4d3e54c8f9d Mon Sep 17 00:00:00 2001 From: Ron Hildebrandt Date: Mon, 26 Aug 2024 11:14:07 +0200 Subject: [PATCH 0839/1012] add missing #### in title... --- manual/source/optical-spectroscopy-structure.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/manual/source/optical-spectroscopy-structure.rst b/manual/source/optical-spectroscopy-structure.rst index 3551f29bcc..c5d881d99c 100644 --- a/manual/source/optical-spectroscopy-structure.rst +++ b/manual/source/optical-spectroscopy-structure.rst @@ -13,7 +13,7 @@ Optical spectroscopy .. _OpticalSpec1: Optical Spectroscopy -############## +#################### From a8cf2afa99bab81594d357bb67002007719e9ff2 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 30 Aug 2024 11:06:46 +0200 Subject: [PATCH 0840/1012] Clarified issues with depends_on, fixed typo pID for pfID in NXem_ebsd --- .../NXapm_hit_finding.nxdl.xml | 3 +- ...Xapm_paraprobe_transcoder_results.nxdl.xml | 3 +- .../NXcg_face_list_data_structure.nxdl.xml | 13 +-------- .../NXcg_half_edge_data_structure.nxdl.xml | 15 ++-------- .../NXcg_polyline_set.nxdl.xml | 7 ----- .../NXcg_primitive_set.nxdl.xml | 8 +++--- contributed_definitions/NXem_ebsd.nxdl.xml | 28 +++++++++---------- contributed_definitions/NXem_eds.nxdl.xml | 5 ++-- .../nyaml/NXapm_hit_finding.yaml | 2 +- .../NXapm_paraprobe_transcoder_results.yaml | 2 +- .../nyaml/NXcg_face_list_data_structure.yaml | 10 +------ .../nyaml/NXcg_half_edge_data_structure.yaml | 12 ++------ .../nyaml/NXcg_polyline_set.yaml | 5 ---- .../nyaml/NXcg_primitive_set.yaml | 5 ++-- contributed_definitions/nyaml/NXem_ebsd.yaml | 22 +++++++-------- contributed_definitions/nyaml/NXem_eds.yaml | 3 +- 16 files changed, 48 insertions(+), 95 deletions(-) diff --git a/contributed_definitions/NXapm_hit_finding.nxdl.xml b/contributed_definitions/NXapm_hit_finding.nxdl.xml index 7ea1adbfee..e05baf1ead 100644 --- a/contributed_definitions/NXapm_hit_finding.nxdl.xml +++ b/contributed_definitions/NXapm_hit_finding.nxdl.xml @@ -94,7 +94,8 @@ - The instance of :ref:`NXcoordinate_system` in which the positions are defined. + Reference to an instance of :ref:`NXcoordinate_system` in which the positions + are defined. diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml index 10609e371d..145a813467 100644 --- a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml @@ -121,7 +121,8 @@ config--> - Point to the coordinate system in which these positions are defined. + Reference to an instance of :ref:`NXcoordinate_system` in which the positions + are defined. diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml index 48610a31d2..081b928d5d 100644 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -23,7 +23,7 @@ --> - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -75,17 +75,6 @@ duplicate of an NXoff_geometry ?--> Having an own base class for the data structure how primitives are stored is useful to embrace both users with small or very detailed specification demands. - - - Hint to help resolve in which Euclidean coordinate system - field values vertices are defined. - - - - - Dimensionality of the primitives described. - - diff --git a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml index 40213352e3..759e30943c 100644 --- a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + @@ -54,17 +54,6 @@ Such a data structure can be used to efficiently circulate around faces and iterate over vertices of a planar graph. - - - Hint to help resolve in which Euclidean coordinate system - field values vertices are defined. - - - - - Dimensionality of the primitives described. - - @@ -187,7 +176,7 @@ - + Users are referred to the literature for the background of L. Weinberg's work about topological characterization of planar graphs: diff --git a/contributed_definitions/NXcg_polyline_set.nxdl.xml b/contributed_definitions/NXcg_polyline_set.nxdl.xml index 64a002f86c..f57d0c53f6 100644 --- a/contributed_definitions/NXcg_polyline_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyline_set.nxdl.xml @@ -57,13 +57,6 @@ multiple vertices possible with the same point coordinates but different names.- The sequence describes the positive traversal along the polyline when walking from the first to the last vertex. - - - Reference to an instance of :ref:`NXcg_point_set` which defines - the location of the vertices that are referred to in the - NXcg_polyline_set instance. - - The total number of vertices that have different positions. diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index bcdbab8a67..034216a3e0 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -66,12 +66,12 @@ on your data...--> - + - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. + Reference to an instance of :ref:`NXcoordinate_system` in which these primitives + are defined. - + The dimensionality of the primitive set. diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index 3a39c8d53e..7bdbb5bca6 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -334,12 +334,13 @@ enumeration: [undefined, Bruker, JEOL, FEI, Oxford]--> pattern_available(NX_BOOLEAN): doc: | True if pattern were stored and are retrieveable via depends_on or source.--> - + - If available and it is stored in an instance of an application definition - this field gives the path of an :ref:`NXdata` where the pattern are stored. + If available and it is stored in an instance of an application definition this field + specifies the path to an instance of :ref:`NXdata` where the measured patterns + are stored. - + Reference (e.g. path and filename) to an existent data artifact which @@ -365,12 +366,12 @@ pattern_available(NX_BOOLEAN): be stored using an own properly documented entry within a simulation group as an instance of :ref:`NXem_sim`. - + - If available and it is stored in an instance of an application definition this field gives - the path of an :ref:`NXimage_set` where the simulated pattern are stored. + If available and it is stored in an instance of an application definition this field specifies + the path to an instance of :ref:`NXimage_set` where the simulated patterns are stored. - + Reference (e.g. path and filename) to an existent digital resource which @@ -418,13 +419,12 @@ pattern_available(NX_BOOLEAN): get lost. All these issues are a motivation and problem which :ref:`NXem_ebsd` solves in that all conventions can be specified explicitly. - + - If available and it is stored in an instance of an application definition - this field gives the path of an :ref:`NXem_msr` where the calibration is - stored. + If available and it is stored in an instance of an application definition this field specifies + the path to an instance of :ref:`NXem_msr` where calibration is stored. - + Reference to a digital resource where the calibration is stored. @@ -627,7 +627,7 @@ to sample_reference_frame - + diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml index 6397ac4868..464adf1287 100644 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -23,11 +23,12 @@ --> +NEW ISSUE: make the binning flexible per scan point +energy typically the fastest direction--> - Number of X-ray photon energy (bins), the fastest direction. + Number of X-ray photon energy (bins) diff --git a/contributed_definitions/nyaml/NXapm_hit_finding.yaml b/contributed_definitions/nyaml/NXapm_hit_finding.yaml index 5db1dab96f..ec9efe5637 100644 --- a/contributed_definitions/nyaml/NXapm_hit_finding.yaml +++ b/contributed_definitions/nyaml/NXapm_hit_finding.yaml @@ -43,7 +43,7 @@ NXapm_hit_finding(NXprocess): # when evolving these ideas further inherit from dim: (p, 2) \@depends_on(NX_CHAR): doc: | - The instance of :ref:`NXcoordinate_system` in which the positions are defined. + Reference to an instance of :ref:`NXcoordinate_system` in which the positions are defined. hit_quality_types(NX_CHAR): doc: | Name of the hit_qualities distinguished. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml index e9cd9b04f2..c1938189ba 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml @@ -76,7 +76,7 @@ NXapm_paraprobe_transcoder_results(NXobject): dim: (n_ions, 3) \@depends_on(NX_CHAR): doc: | - Point to the coordinate system in which these positions are defined. + Reference to an instance of :ref:`NXcoordinate_system` in which the positions are defined. visualization(NXprocess): exists: recommended xdmf_topology(NX_UINT): diff --git a/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml b/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml index 4f33188c79..839b63e143 100644 --- a/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml +++ b/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml @@ -31,15 +31,7 @@ symbols: The total number of Weinberg vector values of all faces. # duplicate of an NXoff_geometry ? type: group -NXcg_face_list_data_structure(NXobject): - \@depends_on(NX_CHAR): - doc: | - Hint to help resolve in which Euclidean coordinate system - field values vertices are defined. - dimensionality(NX_POSINT): - doc: | - Dimensionality of the primitives described. - unit: NX_UNITLESS +NXcg_face_list_data_structure(NXcg_primitive_set): # resulting in a design similar to that of NXoff_geometry and the XDMF mixed primitive topology number_of_vertices(NX_INT): doc: | diff --git a/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml b/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml index de58e12e70..6e22cb5624 100644 --- a/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml +++ b/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml @@ -17,15 +17,7 @@ symbols: n_he: | The number of half-edges. type: group -NXcg_half_edge_data_structure(NXobject): - \@depends_on(NX_CHAR): - doc: | - Hint to help resolve in which Euclidean coordinate system - field values vertices are defined. - dimensionality(NX_POSINT): - doc: | - Dimensionality of the primitives described. - unit: NX_UNITLESS +NXcg_half_edge_data_structure(NXcg_primitive_set): # resulting in a design similar to that of NXoff_geometry and the XDMF mixed primitive topology number_of_vertices(NX_INT): doc: | @@ -112,7 +104,7 @@ NXcg_half_edge_data_structure(NXobject): Identifier of the previous half-edge. unit: NX_UNITLESS dim: (n_he,) - weinberg_vector: + weinberg_vector(NX_CHAR): doc: | Users are referred to the literature for the background of L. Weinberg's work about topological characterization of planar graphs: diff --git a/contributed_definitions/nyaml/NXcg_polyline_set.yaml b/contributed_definitions/nyaml/NXcg_polyline_set.yaml index bef7167078..3312c4393a 100644 --- a/contributed_definitions/nyaml/NXcg_polyline_set.yaml +++ b/contributed_definitions/nyaml/NXcg_polyline_set.yaml @@ -21,11 +21,6 @@ symbols: The total number of vertices traversed when visiting every polyline. type: group NXcg_polyline_set(NXcg_primitive_set): - \@depends_on(NX_CHAR): - doc: | - Reference to an instance of :ref:`NXcg_point_set` which defines - the location of the vertices that are referred to in the - NXcg_polyline_set instance. number_of_unique_vertices(NX_POSINT): doc: | The total number of vertices that have different positions. diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml index 8f7eeb9119..7a8466b067 100644 --- a/contributed_definitions/nyaml/NXcg_primitive_set.yaml +++ b/contributed_definitions/nyaml/NXcg_primitive_set.yaml @@ -36,10 +36,9 @@ NXcg_primitive_set(NXobject): # individual specializations like NXcg_polyline_set typically overwrite # the meaning of the depends_on concept to build consistent inference chains # to enable an instantiation of the actual geometric primitives - \@depends_on(NX_CHAR): + depends_on(NX_CHAR): doc: | - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. + Reference to an instance of :ref:`NXcoordinate_system` in which these primitives are defined. dimensionality(NX_POSINT): doc: | The dimensionality of the primitive set. diff --git a/contributed_definitions/nyaml/NXem_ebsd.yaml b/contributed_definitions/nyaml/NXem_ebsd.yaml index aaf9204fcb..b69ef7951b 100644 --- a/contributed_definitions/nyaml/NXem_ebsd.yaml +++ b/contributed_definitions/nyaml/NXem_ebsd.yaml @@ -216,10 +216,11 @@ NXem_ebsd(NXem_method): # pattern_available(NX_BOOLEAN): # doc: | # True if pattern were stored and are retrieveable via depends_on or source. - \@depends_on(NX_CHAR): + depends_on(NX_CHAR): doc: | - If available and it is stored in an instance of an application definition - this field gives the path of an :ref:`NXdata` where the pattern are stored. + If available and it is stored in an instance of an application definition this field + specifies the path to an instance of :ref:`NXdata` where the measured patterns + are stored. source(NXserialized): doc: | Reference (e.g. path and filename) to an existent data artifact which @@ -241,10 +242,10 @@ NXem_ebsd(NXem_method): master pattern are the result of a computer simulation and thus should be stored using an own properly documented entry within a simulation group as an instance of :ref:`NXem_sim`. - \@depends_on(NX_CHAR): + depends_on(NX_CHAR): doc: | - If available and it is stored in an instance of an application definition this field gives - the path of an :ref:`NXimage_set` where the simulated pattern are stored. + If available and it is stored in an instance of an application definition this field specifies + the path to an instance of :ref:`NXimage_set` where the simulated patterns are stored. source(NXserialized): doc: | Reference (e.g. path and filename) to an existent digital resource which @@ -288,11 +289,10 @@ NXem_ebsd(NXem_method): settings or write these down in a lab notebook. Otherwise, these metadata get lost. All these issues are a motivation and problem which :ref:`NXem_ebsd` solves in that all conventions can be specified explicitly. - \@depends_on(NX_CHAR): + depends_on(NX_CHAR): doc: | - If available and it is stored in an instance of an application definition - this field gives the path of an :ref:`NXem_msr` where the calibration is - stored. + If available and it is stored in an instance of an application definition this field specifies + the path to an instance of :ref:`NXem_msr` where calibration is stored. source(NXserialized): doc: | Reference to a digital resource where the calibration is stored. @@ -443,7 +443,7 @@ NXem_ebsd(NXem_method): Number of scan points in the original mapping. unit: NX_UNITLESS odfID(NXmicrostructure_odf): - pID(NXmicrostructure_pf): + pfID(NXmicrostructure_pf): ipfID(NXmicrostructure_ipf): microstructureID(NXmicrostructure): # overview over the entire map, rediscretized on a tight aabb diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml index 047b07e866..02491faad2 100644 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -12,9 +12,10 @@ doc: | of correlative tomographic usage of electron microscopy. # NEW ISSUE: use computational geometry to offer arbitrary scan pattern # NEW ISSUE: make the binning flexible per scan point +# energy typically the fastest direction symbols: n_photon_energy: | - Number of X-ray photon energy (bins), the fastest direction. + Number of X-ray photon energy (bins) n_elements: | Number of identified elements n_peaks: | From 132fc2a092137bd1ba3f0fc1d6a007f3a2bc831d Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 30 Aug 2024 12:02:12 +0200 Subject: [PATCH 0841/1012] Hooked in examples for usage of NXem_ebsd and NXem_eds into NXem --- contributed_definitions/NXem.nxdl.xml | 144 ++++++++++++++++++- contributed_definitions/NXem_ebsd.nxdl.xml | 8 +- contributed_definitions/NXem_eds.nxdl.xml | 9 +- contributed_definitions/nyaml/NXem.yaml | 121 +++++++++++++++- contributed_definitions/nyaml/NXem_ebsd.yaml | 4 +- contributed_definitions/nyaml/NXem_eds.yaml | 9 +- 6 files changed, 275 insertions(+), 20 deletions(-) diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 47725ab7f4..b2dfbdc798 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -1278,7 +1278,7 @@ basically optional use of NXaberration therein at least some value required--> - + A region-of-interest analyzed either during or after the session for which specific processed data are available. @@ -1295,10 +1295,144 @@ is required to provide such information in this way!--> - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index 7bdbb5bca6..6ffde91e04 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -635,15 +635,15 @@ to sample_reference_frame An overview of the entire ROI. - + Descriptor representing the image contrast. - - - + + + - + - Comma-separated list of names of identified elements. All members of - the list have to be valid chemical_symbols from the periodic table. + Comma-separated list of names of elements confirmed in the sample via EDS analysis. + + All members of the list have to be valid chemical_symbols from the periodic table. This field can be used when creating instances of NXpeak is not desired. However, a collection of instances of NXpeak with individual NXion specified @@ -166,7 +167,7 @@ therefore we use for now the--> These element-specific EDS maps are :ref:`NXimage_set` instances and need to be named with the name of the element from the - element_names field. + atom_types field. We often observe that signal contributions from several peaks are summarized and shown together, e.g. the combined signal diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index 2326f0878e..a0cffc956f 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -1207,7 +1207,7 @@ NXem(NXobject): # relevant research result post-processed for specific community methods # but normalized in its representation ready to be consumed for a # research data management system - (NXroi): + roiID(NXroi): exists: [min, 0, max, infty] doc: - | @@ -1231,9 +1231,128 @@ NXem(NXobject): ebsd(NXem_ebsd): exists: optional # remains to be discussed based on examples + gnomonic_reference_frame(NXcoordinate_system): + exists: optional + origin(NX_CHAR): + x_direction(NX_CHAR): + y_direction(NX_CHAR): + z_direction(NX_CHAR): + pattern_centre(NXprocess): + exists: recommended + x_boundary_convention(NX_CHAR): + x_normalization_direction(NX_CHAR): + y_boundary_convention(NX_CHAR): + y_normalization_direction(NX_CHAR): + measurement(NXprocess): + exists: optional + depends_on(NX_CHAR): + source(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + simulation(NXprocess): + exists: optional + depends_on(NX_CHAR): + source(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + indexing(NXprocess): + exists: optional + number_of_scan_points(NX_UINT): + indexing_rate(NX_NUMBER): + exists: recommended + source(NXserialized): + exists: optional + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + phaseID(NXcrystal_structure): + exists: [min, 0, max, infty] + number_of_scan_points(NX_UINT): + a_b_c(NX_NUMBER): + alpha_beta_gamma(NX_NUMBER): + space_group(NX_CHAR): + phase_identifier(NX_INT): + phase_name(NX_CHAR): + ipfID(NXmicrostructure_ipf): + exists: recommended + projection_direction(NX_NUMBER): + map(NXdata): + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_INT): + title(NX_CHAR): + data(NX_NUMBER): + \@long_name(NX_CHAR): + axis_x(NX_NUMBER): + \@long_name(NX_CHAR): + axis_y(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + axis_z(NX_NUMBER): + exists: optional + \@long_name(NX_CHAR): + legend(NXdata): + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_INT): + title(NX_CHAR): + data(NX_NUMBER): + \@long_name(NX_CHAR): + axis_x(NX_NUMBER): + \@long_name(NX_CHAR): + axis_y(NX_NUMBER): + \@long_name(NX_CHAR): + roi(NXdata): + exists: recommended + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_CHAR): + title(NX_CHAR): + descriptor(NX_CHAR): + data(NX_NUMBER): + axis_y(NX_NUMBER): + \@long_name(NX_CHAR): + axis_x(NX_NUMBER): + \@long_name(NX_CHAR): eds(NXem_eds): exists: optional # remains to be discussed based on examples + indexing(NXprocess): + summary(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_CHAR): + title(NX_CHAR): + intensity(NX_NUMBER): + axis_energy(NX_CHAR): + \@long_name(NX_CHAR): + atom_types(NX_CHAR): + (NXimage_set): + exists: [min, 0, max, 118] # given that image_set instances should be named with the chemical_symbol of the elements + iupac_line_candidates(NX_CHAR): + exists: recommended + energy_range(NX_NUMBER): + image_2d(NXdata): + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_CHAR): + title(NX_CHAR): + exists: optional + intensity(NX_NUMBER): + \@units(NX_CHAR): + exists: recommended + axis_i(NX_NUMBER): # x + \@long_name(NX_CHAR): + \@units(NX_CHAR): + axis_j(NX_NUMBER): # y + \@long_name(NX_CHAR): + \@units(NX_CHAR): # exemplar test to enforce that units are added adf(NXem_adf): exists: optional # remains to be discussed based on examples diff --git a/contributed_definitions/nyaml/NXem_ebsd.yaml b/contributed_definitions/nyaml/NXem_ebsd.yaml index b69ef7951b..180cdf0350 100644 --- a/contributed_definitions/nyaml/NXem_ebsd.yaml +++ b/contributed_definitions/nyaml/NXem_ebsd.yaml @@ -450,11 +450,11 @@ NXem_ebsd(NXem_method): roi(NXdata): doc: | An overview of the entire ROI. - descriptor: + descriptor(NX_CHAR): doc: | Descriptor representing the image contrast. # taking two examples (CTF and H5OINA choked completely of possibility to find s.th. conceptually common to plot - enumeration: [normalized_band_contrast, normalized_confidence_index, normalized_mean_angular_deviation] + enumeration: [band_contrast, confidence_index, mean_angular_deviation] # \@signal: # data # \@axes: # [axis_y, axis_x] # \@axis_x_indices: 0 diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml index 02491faad2..a89e5c06f3 100644 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -77,10 +77,11 @@ NXem_eds(NXem_method): This can be a list of IUPAC notations for (the seldom) case that multiple lines are grouped with the same peak. dim: (i,) - element_names(NX_CHAR): + atom_types(NX_CHAR): doc: | - Comma-separated list of names of identified elements. All members of - the list have to be valid chemical_symbols from the periodic table. + Comma-separated list of names of elements confirmed in the sample via EDS analysis. + + All members of the list have to be valid chemical_symbols from the periodic table. This field can be used when creating instances of NXpeak is not desired. However, a collection of instances of NXpeak with individual NXion specified @@ -104,7 +105,7 @@ NXem_eds(NXem_method): These element-specific EDS maps are :ref:`NXimage_set` instances and need to be named with the name of the element from the - element_names field. + atom_types field. We often observe that signal contributions from several peaks are summarized and shown together, e.g. the combined signal From 41c61cb6e65c6ac424f1f99d9e049810ed9672b9 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 30 Aug 2024 12:41:51 +0200 Subject: [PATCH 0842/1012] Last cleaning for depends_on on this feature branch --- contributed_definitions/NXapm_hit_finding.nxdl.xml | 3 +-- .../NXapm_paraprobe_transcoder_results.nxdl.xml | 3 +-- .../NXcrystal_structure.nxdl.xml | 14 ++++---------- .../NXcs_filter_boolean_mask.nxdl.xml | 4 ++-- contributed_definitions/NXem_ebsd.nxdl.xml | 8 ++++---- contributed_definitions/NXgraph_edge_set.nxdl.xml | 4 ++-- contributed_definitions/NXgraph_node_set.nxdl.xml | 4 ++-- .../nyaml/NXapm_hit_finding.yaml | 2 +- .../nyaml/NXapm_paraprobe_transcoder_results.yaml | 2 +- .../nyaml/NXcrystal_structure.yaml | 12 +++--------- .../nyaml/NXcs_filter_boolean_mask.yaml | 2 +- contributed_definitions/nyaml/NXdeflector.yaml | 2 +- contributed_definitions/nyaml/NXem_ebsd.yaml | 8 ++++---- .../nyaml/NXgraph_edge_set.yaml | 2 +- .../nyaml/NXgraph_node_set.yaml | 2 +- 15 files changed, 29 insertions(+), 43 deletions(-) diff --git a/contributed_definitions/NXapm_hit_finding.nxdl.xml b/contributed_definitions/NXapm_hit_finding.nxdl.xml index e05baf1ead..534e3c7b00 100644 --- a/contributed_definitions/NXapm_hit_finding.nxdl.xml +++ b/contributed_definitions/NXapm_hit_finding.nxdl.xml @@ -94,8 +94,7 @@ - Reference to an instance of :ref:`NXcoordinate_system` in which the positions - are defined. + Defines in which reference frame the positions are defined. diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml index 145a813467..a5519759a2 100644 --- a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml @@ -121,8 +121,7 @@ config--> - Reference to an instance of :ref:`NXcoordinate_system` in which the positions - are defined. + Defines in which reference frame the positions are defined. diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index c7ef086e3c..2e0a9c4146 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -56,11 +56,11 @@ used algorithm. Dictionary-based alternatives are emerging.--> Examples where such base class is useful are kinematic or dynamic diffraction simulations of e.g. (Kikuchi or other type of) patterns. - + - Detail in which reference frame the unit cell is defined. + Details in which reference frame the unit cell is defined. - + Dimensionality of the lattice. @@ -169,11 +169,6 @@ used algorithm. Dictionary-based alternatives are emerging.--> should be stored in the HDF5 file. - Name of the phase/alias. @@ -212,8 +207,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. + Details the reference frame in which the positions are defined. diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 46f8774235..28c9933123 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -70,14 +70,14 @@ This base class can deal with the situation when the number of objects is not an integer multiple of the bit depth used for storing the states. - + Possibility to refer to which set this mask applies. If depends_on is not provided, it is assumed that the mask applies to its direct parent. - + Number of objects represented by the mask. diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index 6ffde91e04..43ff69a43a 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -313,13 +313,13 @@ enumeration: [undefined, Bruker, JEOL, FEI, Oxford]--> Physical time since the beginning of a timestamp that is required to be same for all experiments in the set. The purpose of this marker is - to identify how all experiments in the set have have to be arranged + to identify how all experiments in the set need to be arranged sequentially based on the time elapsed. The time is relevant to sort e.g. experiments of consecutive quasi - in-situ experiments where a measurement was e.g. taken after 0 minutes - of annealing, 30 minutes, 6 hours, or 24 hours of annealing. + in-situ experiments where a measurement was e.g. taken after 0 minutes, + 30 minutes, 6 hours, or 24 hours of annealing. - + Timestamp relative to which time was counted to aid converting between time and timestamp. diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 899da7a1a4..da83632506 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -39,12 +39,12 @@ Alternatively, use depends_on to specify which instance of :ref:`NXgraph_root` is defined by this instance. - + Specify which instance of :ref:`NXgraph_root` this :ref:`NXgraph_edge_set` refers to. - + Total number of edges, counting eventual bidirectional edges only once. diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index 8b6be77af8..977f3d1120 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -44,12 +44,12 @@ Alternatively, use depends_on to specify which instance of NXgraph_root is defined by this instance. - + Specify which instance of :ref:`NXgraph_root` this :ref:`NXgraph_node_set` refers to. - + About which space does the graph make statements. diff --git a/contributed_definitions/nyaml/NXapm_hit_finding.yaml b/contributed_definitions/nyaml/NXapm_hit_finding.yaml index ec9efe5637..d71e671939 100644 --- a/contributed_definitions/nyaml/NXapm_hit_finding.yaml +++ b/contributed_definitions/nyaml/NXapm_hit_finding.yaml @@ -43,7 +43,7 @@ NXapm_hit_finding(NXprocess): # when evolving these ideas further inherit from dim: (p, 2) \@depends_on(NX_CHAR): doc: | - Reference to an instance of :ref:`NXcoordinate_system` in which the positions are defined. + Defines in which reference frame the positions are defined. hit_quality_types(NX_CHAR): doc: | Name of the hit_qualities distinguished. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml index c1938189ba..c4f73ef8e0 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml @@ -76,7 +76,7 @@ NXapm_paraprobe_transcoder_results(NXobject): dim: (n_ions, 3) \@depends_on(NX_CHAR): doc: | - Reference to an instance of :ref:`NXcoordinate_system` in which the positions are defined. + Defines in which reference frame the positions are defined. visualization(NXprocess): exists: recommended xdmf_topology(NX_UINT): diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml index 940e46503c..d3d659c55f 100644 --- a/contributed_definitions/nyaml/NXcrystal_structure.yaml +++ b/contributed_definitions/nyaml/NXcrystal_structure.yaml @@ -24,9 +24,9 @@ symbols: Dimensionality of the lattice. type: group NXcrystal_structure(NXobject): - \@depends_on(NX_CHAR): + depends_on(NX_CHAR): doc: | - Detail in which reference frame the unit cell is defined. + Details in which reference frame the unit cell is defined. dimensionality(NX_POSINT): doc: | Dimensionality of the lattice. @@ -98,11 +98,6 @@ NXcrystal_structure(NXobject): :ref:`NXcrystal_structure` named phase0 and phase1 should be stored in the HDF5 file. unit: NX_UNITLESS - # \@depends_on(NX_CHAR): - # doc: | - # Refers to the specific identifier_offset to consider. - # - # If not provided assume identifier_offset is 0. phase_name(NX_CHAR): doc: | Name of the phase/alias. @@ -129,8 +124,7 @@ NXcrystal_structure(NXobject): unit: NX_ANY \@depends_on(NX_CHAR): doc: | - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. + Details the reference frame in which the positions are defined. # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory # to describe the simulated Kikuchi pattern generated from such a model atom_occupancy(NX_NUMBER): diff --git a/contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml b/contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml index 135f3c7282..807d983593 100644 --- a/contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml +++ b/contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml @@ -37,7 +37,7 @@ symbols: Length of mask considering the eventual need for padding. type: group NXcs_filter_boolean_mask(NXobject): - \@depends_on(NX_CHAR): + depends_on(NX_CHAR): doc: | Possibility to refer to which set this mask applies. diff --git a/contributed_definitions/nyaml/NXdeflector.yaml b/contributed_definitions/nyaml/NXdeflector.yaml index 2f32bc8caa..e8bb438d43 100644 --- a/contributed_definitions/nyaml/NXdeflector.yaml +++ b/contributed_definitions/nyaml/NXdeflector.yaml @@ -2,7 +2,7 @@ category: base doc: | Deflectors as they are used e.g. in an electron analyser. type: group -NXdeflector(NXobject): +NXdeflector(NXobject): # should inherit from NXcomponent type(NX_CHAR): doc: | Qualitative type of deflector with respect to the number of pole pieces. diff --git a/contributed_definitions/nyaml/NXem_ebsd.yaml b/contributed_definitions/nyaml/NXem_ebsd.yaml index 180cdf0350..67d10fa851 100644 --- a/contributed_definitions/nyaml/NXem_ebsd.yaml +++ b/contributed_definitions/nyaml/NXem_ebsd.yaml @@ -198,13 +198,13 @@ NXem_ebsd(NXem_method): doc: | Physical time since the beginning of a timestamp that is required to be same for all experiments in the set. The purpose of this marker is - to identify how all experiments in the set have have to be arranged + to identify how all experiments in the set need to be arranged sequentially based on the time elapsed. The time is relevant to sort e.g. experiments of consecutive quasi - in-situ experiments where a measurement was e.g. taken after 0 minutes - of annealing, 30 minutes, 6 hours, or 24 hours of annealing. + in-situ experiments where a measurement was e.g. taken after 0 minutes, + 30 minutes, 6 hours, or 24 hours of annealing. unit: NX_TIME - \@depends_on(NX_CHAR): + \@epoch_start(NX_CHAR): doc: | Timestamp relative to which time was counted to aid converting between time and timestamp. diff --git a/contributed_definitions/nyaml/NXgraph_edge_set.yaml b/contributed_definitions/nyaml/NXgraph_edge_set.yaml index e611cb54e1..87939ab859 100644 --- a/contributed_definitions/nyaml/NXgraph_edge_set.yaml +++ b/contributed_definitions/nyaml/NXgraph_edge_set.yaml @@ -12,7 +12,7 @@ symbols: The number of edges. type: group NXgraph_edge_set(NXobject): - \@depends_on(NX_CHAR): + depends_on(NX_CHAR): doc: | Specify which instance of :ref:`NXgraph_root` this :ref:`NXgraph_edge_set` refers to. number_of_edges(NX_UINT): diff --git a/contributed_definitions/nyaml/NXgraph_node_set.yaml b/contributed_definitions/nyaml/NXgraph_node_set.yaml index 1f4bf7cc40..93ef93f0ba 100644 --- a/contributed_definitions/nyaml/NXgraph_node_set.yaml +++ b/contributed_definitions/nyaml/NXgraph_node_set.yaml @@ -14,7 +14,7 @@ symbols: The dimensionality of the graph. Eventually use one for categorical. type: group NXgraph_node_set(NXobject): - \@depends_on(NX_CHAR): + depends_on(NX_CHAR): doc: | Specify which instance of :ref:`NXgraph_root` this :ref:`NXgraph_node_set` refers to. space(NX_CHAR): From 53f21ac6863d4075f45edac6277912879c9d3639 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 25 Apr 2023 08:44:52 +0200 Subject: [PATCH 0843/1012] Initial draft of NXmpes_xps sub app-def --- contributed_definitions/nyaml/NXmpes_xps.yaml | 359 ++++++++++++++++++ 1 file changed, 359 insertions(+) create mode 100644 contributed_definitions/nyaml/NXmpes_xps.yaml diff --git a/contributed_definitions/nyaml/NXmpes_xps.yaml b/contributed_definitions/nyaml/NXmpes_xps.yaml new file mode 100644 index 0000000000..1679ffbfdb --- /dev/null +++ b/contributed_definitions/nyaml/NXmpes_xps.yaml @@ -0,0 +1,359 @@ +#lukas.pielsticker at cec.mpg.de, 04/2023 +#Draft version of a NeXus application definition for XPS. + +doc: This is the application definition for X-ray photoelectron spectroscopy. +category: application +NXmpes: + (NXentry): + title: + start_time(NX_DATE_TIME): + doc: "ISO8601 formatted Datetime of the start of the measurement." + end_time(NX_DATE_TIME): + doc: "ISO8601 formatted Datetime of the end of the measurement." + definition: + \@version: + enumeration: ["NXmpes_xps"] + (NXuser): + doc: "Contact information of at least the user of the instrument or the + investigator who performed this experiment. + Adding multiple users if relevant is recommended." + name(NX_CHAR): + exists: recommended + doc: "Name of the user." + affiliation(NX_CHAR): + exists: recommended + doc: "Name of the affiliation of the user at the point in time when the + experiment was performed." + address(NX_CHAR): + exists: recommended + doc: "Full address (street, street number, ZIP, city, country) of the + user's affiliation." + email(NX_CHAR): + doc: "Email address of the user." + orcid(NX_CHAR): + exists: recommended + doc: "Author ID defined by https://orcid.org/." + (NXinstrument): + energy_resolution(NX_FLOAT): + exists: recommended + unit: NX_ENERGY + (NXsource): + doc: "The source used to generate the primary photons. Properties refer strictly to parameters of the source, not of the output beam. For example, the energy of the source is not the optical power of the beam, but the energy of the electron beam in a synchrotron and so on." + type(NX_CHAR): + enumeration: [ + "Synchrotron X-ray Source", + "Rotating Anode X-ray", + "Fixed Tube X-ray", + "UV Laser", + "Free-Electron Laser", + "Optical Laser", + "UV Plasma Source", + "Metal Jet X-ray", + "HHG laser" + ] + name(NX_CHAR): + doc: "Free text description of the analyzer name used in the laboratory." + probe(NX_CHAR): + doc: "Type of probe. In XPS it's always X-ray photons, so the full NIAC list is restricted." + enumeration: ["x-ray","ultraviolet"] + beam_probe(NXbeam): + distance(NX_NUMBER): + doc: "Distance of the point of evaluation of the beam from the sample surface." + exists: recommended + unit: NX_LENGTH + incident_energy(NX_FLOAT): + unit: NX_ENERGY + doc: "In the case of a monchromatic 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." + incident_energy_spread(NX_NUMBER): + exists: recommended + unit: NX_ENERGY + doc: "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 energy in incident_energy." + incident_polarization(NX_NUMBER): + exists: recommended + doc: "Incident polarization specified as a Stokes vector." + \@units(NX_CHAR): + doc: "The units for this observable are not included in the NIAC list. Responsibility on correct formatting and parsing is handed to the user by using ‘NX_ANY’. Correct parsing can still be implemented by using this attribute. Fill with: The unit unidata symbol if the unit has one (Example: ‘T’ for the unit of magnetic flux density tesla). The unit unidata name if the unit has a name (Example: ‘farad’ for capacitance). A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and does not have a name. Example: for lightsource brilliance (SI) ‘1/(s.mm2.mrad2)’. Here: SI units are ‘V2/m2’." + (NXelectronanalyser): + description(NX_CHAR): + doc: "Free text description of the type of detector." + energy_resolution(NX_FLOAT): + exists: recommended + doc: "Energy resolution of the analyser with the current setting. May be linked from a NXcalibration." + unit: NX_ENERGY + fast_axes(NX_CHAR): + exists: optional + doc: "List of the axes that are acquired symultaneously 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. Examples: Hemispherical in XPS mode: fast_axes: [energy] Hemispherical with channeltron, sweeping energy mode: slow_axes: [energy] axes can be less abstract than this, i.e. [detector_x, detector_y]." + slow_axes(NX_CHAR): + exists: optional + doc: "List of the axes that are acquired by scanning a physical parameter, listed in order of decreasing speed. See fast_axes for examples." + COLLECTIONCOLUMN(NXcollectioncolumn): + scheme(NX_CHAR): + doc: "Scheme of the electron collection column." + enumeration: [ + "Standard", + "Angular dispersive", + "Selective area", + "Deflector", + ] + mode(NX_CHAR): + exists: recommended + doc: "Labelling of the lens setting in use. Names are typically presets provided by the instrument vendor." + tranmission_function(NX_FLOAT): + doc: "Transmission function in dependance of the electron kinetic energy. To be used in intensity calibration." + (NXenergydispersion): + scheme(NX_CHAR): + enumeration: + [ + "hemispherical", + "double hemispherical", + "cylindrical mirror", + "display mirror", + "retarding grid", + ] + pass_energy(NX_FLOAT): + doc: "Pass energy of energy dispersive element. Determines measurement resolution." + unit: NX_ENERGY + energy_scan_mode(NX_CHAR): + doc: "Way of scanning the energy axis." + enumeration: [ + "fixed analyzer transmission", + "fixed retarding ratio", + "fixed energies", + "snapshot", + "detector voltage scan", + "constant final state", + "constant initial state", + ] + entrance_slit(NXaperture): + exists: optional + doc: "Size, position, and shape of the entrance slit in dispersive analyzers (aperture generating the energy filtering)." + description(NX_CHAR): + doc: "Type of aperture inserted in the beam." + enumeration: ["slit", "pinhole", "iris"] + shape(NX_CHAR): + doc: "Description of the shape of the active part of the aperture, curved or straight for horizontal slits, square or round for pinhole etc." + enumeration: + [ + "curved", + "straight", + "circle", + "square", + "hexagon", + "octagon", + "bladed", + ] + exit_slit(NXaperture): + exists: optional + doc: "Size, position and shape of the exit slit in dispersive analyzers." + description(NX_CHAR): + doc: "Type of aperture inserted in the beam." + enumeration: ["slit", "pinhole", "iris"] + shape(NX_CHAR): + doc: "Description of the shape of the active part of the aperture, curved or straight for horizontal slits, square or round for pinhole etc." + enumeration: + [ + "curved", + "straight", + "circle", + "square", + "hexagon", + "octagon", + "bladed", + ] + iris(NXaperture): + exists: optional + doc: "Size, position, and shape of the iris in dispersive analyzers." + description(NX_CHAR): + doc: "Type of aperture inserted in the beam." + shape(NX_CHAR): + doc: "Description of the shape of the active part of the aperture, curved or straight for horizontal slits, square or round for pinhole etc." + enumeration: + [ + "curved", + "straight", + "circle", + "square", + "hexagon", + "octagon", + "bladed", + ] + + electron_detector(NXdetector): + amplifier_type(NX_CHAR): + exists: recommended + doc: "Type of electron amplifier in the first amplification step." + enumeration: ["MCP", "channeltron"] + # ToDo: Representation of count rate calibration + detector_type(NX_CHAR): + exists: recommended + doc: "Description of the detector type." + enumeration: + [ + "DLD", + "Phosphor+CCD", + "Phosphor+CMOS", + "ECMOS", + "Anode", + "Multi-anode"] + (NXdata): # Raw signal without calibrated axes. + exists: recommended + \@signal: + enumeration: ['raw'] + raw(NX_NUMBER): # There is a block of numbers named raw. + doc: "Raw data before calibration." + GEOMETRY(NXtransformations): + exists: optional + doc: "Transformations describing the transformation chain of all relevant vectors in the experiment." + gravity_axis(NX_NUMBER): + doc: "Direction of gravity." + \@vector(NX_NUMBER): + doc: "The vector in the direction of gravity." + \@depends_on(NX_CHAR): + doc: "Set to '.' to specify the normal vector to which all other vectors are related." + beam_axis(NX_NUMBER): + doc: "Direction of the photon beam." + \@vector(NX_NUMBER): + doc: "The vector of the photon-beam direction into the chamber after the last optical element (or directly from the source if there are no optical elements)." + \@depends_on(NX_CHAR): + doc: "This should be a link to /entry/instrument/geometry/gravity_axis." + analyzer_lens_axis(NX_NUMBER): + doc: "Direction of lens axis of analyzer." + \@vector(NX_NUMBER): + doc: "The vector pointing along the central axis of the analyzer lens system in from the sample." + \@depends_on(NX_CHAR): + doc: "This should be a link to /entry/instrument/geometry/beam_axis." + hemisphere_orientation(NX_NUMBER): + exists: optional + doc: "Orientation of the hemisphere with respect to the lens system in case of a hemispherical electron analyzer." + \@vector(NX_NUMBER): + doc: "The vector pointing towards the detector from the entrance slit of the hemisphere, and should be perpendicular to the analyzer lens system." + \@depends_on(NX_CHAR): + doc: "This should be a link to /entry/instrument/geometry/analyzer_lens_axis." + (NXmanipulator): + exists: optional + doc: "Manipulator for positioning of the sample." + sample_temperature(NX_FLOAT): + exists: recommended + doc: "Sample temperature during the experiment. Can be a single float or an array for temperature-programmed XPS." + unit: NX_TEMPERATURE + sample_heater(NX_CHAR): + exists: optional + doc: "Method of heating the sample. Can be e.g. electron beam heating, laser, halogen lamp" + drain_current(NX_FLOAT): + exists: recommended + doc: "Measured drain current of the sample." + unit: NX_CURRENT + sample_bias(NX_FLOAT): + exists: recommended + doc: "External sample bias." + unit: NX_CURRENT + calibration(NXprocess): + doc: "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" + energy_calibration(NXcalibration): + exists: recommended + applied(NX_BOOLEAN): + doc: "Has an energy calibration been applied?" + calibration_file(NX_CHAR): + exists: recommended + doc: "Name of the calibration file containing the calibration data." + calibrated_axis(NX_FLOAT): + exists: recommended + doc: "This is the calibrated energy axis to be used for data plotting." + intensity_calibration(NXcalibration): + exists: recommended + applied(NX_BOOLEAN): + doc: "Has an intensity calibration been applied? I.e., has the transmission function of the analyzer been taken into account?" + transmission_function(NX_FLOAT): + exists: recommended + doc: "Transmission function of the electron collection column. This should be a link to /entry/instrument/collectioncolumn/tranmission_function." + calibrated_axis(NX_FLOAT): + exists: recommended + doc: "This is the calibrated intensity axis to be used for data plotting." + spatial_calibration(NXcalibration): + exists: optional + applied(NX_BOOLEAN): + doc: "Has an spatial calibration been applied?" + calibrated_axis(NX_FLOAT): + exists: recommended + doc: "This is the calibrated spatial axis to be used for data plotting." + (NXsample): + name: + doc: "The user-assigned name of the sample." + chemical_formula: + exists: recommended + doc: "The chemical formula of the sample. For mixtures use the NXsample_component group in NXsample instead." + sample_history(NXnote): + exists: recommended + doc: "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." + atom_types: + exists: recommended + doc: "List of comma-separated elements from the periodic table that are contained in the sample. + If the sample substance has multiple components, all elements from each component must be included in `atom_types`." + preparation_date(NX_DATE_TIME): + exists: recommended + doc: "Date of preparation of the sample for the XPS experiment (i.e. cleaving, last annealing)." + preparation_description(NXnote): + doc: "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." + temperature(NX_FLOAT): + doc: "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." + unit: NX_TEMPERATURE + situation(NX_CHAR): + enumeration: + [ + "vacuum", + "inert atmosphere", + "oxidising atmosphere", + "reducing atmosphere"] + # Can be a single number or a log. + gas_pressure(NX_FLOAT): + unit: NX_PRESSURE + doc: "In the case of a fixed pressure measurement this is the scalar pressure. In the case of an experiment in which pressure changes, or anyway it is recorded, this is an array of length m of pressures." + gas_phase(NX_CHAR): + unit: NX_PRESSURE + doc: "In the case of a fixed pressure measurement this is the scalar pressure. In the case of an experiment in which pressure changes, or anyway it is recorded, this is an array of length m of pressures." + electric_field(NX_FLOAT): + exists: recommended + unit: NX_VOLTAGE + doc: "Electric field applied to the sample with respect to ground / the system, e.g., via biasing." + type(NX_CHAR): + exists: optional + enumeration: + [ + "foil", + "single crystal", + "pellet", + "powder", + "calibration sample", + ] + (NXdata): + doc: "There is an object named data that contains the signal." + \@signal: + enumeration: ["data"] + \@axes(NX_CHAR): + doc: "The energy axis. Can be either scanned or derived from scanning of other energy axis." + energy(NX_NUMBER): + \@units(NX_CHAR): + exists: recommended + \@long_name(NX_CHAR): + exists: optional + type(NX_CHAR): + exists: recommended + doc: "The energy axis can be either in binding or kinetic energy." + enumeration: + [ + "kinetic", + "energy" + ] + step_size(NX_CHAR): + exists: recommended + doc: "The step size between two consecutive energy values." + data(NX_NUMBER): # There is a block of numbers named data. + doc: "Processed plottable data. Represents a measure of one- or more-dimensional photoemission counts, where + the varied axis may be for example energy, spatial coordinate, pump-probe delay, temperature, etc. + The axes traces should be linked to the actual encoder position in NXinstrument or calibrated axes in NXprocess." + \@units(NX_ANY): + exists: recommended + \@long_name(NX_CHAR): + exists: optional \ No newline at end of file From 16e94a4b16dc3a093e41963397305969aa760f2f Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 4 May 2023 13:50:23 +0200 Subject: [PATCH 0844/1012] Prepare NXmpes_xps for extending NXmpes --- contributed_definitions/nyaml/NXmpes_xps.yaml | 496 ++++++++++-------- 1 file changed, 286 insertions(+), 210 deletions(-) diff --git a/contributed_definitions/nyaml/NXmpes_xps.yaml b/contributed_definitions/nyaml/NXmpes_xps.yaml index 1679ffbfdb..e0d17ff779 100644 --- a/contributed_definitions/nyaml/NXmpes_xps.yaml +++ b/contributed_definitions/nyaml/NXmpes_xps.yaml @@ -3,63 +3,89 @@ doc: This is the application definition for X-ray photoelectron spectroscopy. category: application -NXmpes: +NXmpes_xps(NXmpes): (NXentry): - title: - start_time(NX_DATE_TIME): - doc: "ISO8601 formatted Datetime of the start of the measurement." end_time(NX_DATE_TIME): - doc: "ISO8601 formatted Datetime of the end of the measurement." - definition: - \@version: + exists: recommended + doc: "Datetime of the end of the measurement." + definition(NX_CHAR): + \@version(NX_CHAR): enumeration: ["NXmpes_xps"] - (NXuser): - doc: "Contact information of at least the user of the instrument or the - investigator who performed this experiment. - Adding multiple users if relevant is recommended." - name(NX_CHAR): - exists: recommended - doc: "Name of the user." - affiliation(NX_CHAR): - exists: recommended - doc: "Name of the affiliation of the user at the point in time when the - experiment was performed." - address(NX_CHAR): - exists: recommended - doc: "Full address (street, street number, ZIP, city, country) of the - user's affiliation." - email(NX_CHAR): - doc: "Email address of the user." - orcid(NX_CHAR): - exists: recommended - doc: "Author ID defined by https://orcid.org/." + # (NXuser): #### nothing changed, can be removed from here? + # doc: "Contact information of at least the user of the instrument or the + # investigator who performed this experiment. + # Adding multiple users if relevant is recommended." + # name(NX_CHAR): + # exists: recommended + # doc: "Name of the user." + # affiliation(NX_CHAR): + # exists: recommended + # doc: "Name of the affiliation of the user at the point in time when the + # experiment was performed." + # address(NX_CHAR): + # exists: recommended + # doc: "Full address (street, street number, ZIP, city, country) of the + # user's affiliation." + # email(NX_CHAR): + # doc: "Email address of the user." + # orcid(NX_CHAR): + # exists: recommended + # doc: "Author ID defined by https://orcid.org/." (NXinstrument): energy_resolution(NX_FLOAT): - exists: recommended + exists: recommended ###### cannot be required. measured value (typically from Ag 3d5/2 FWHM of sputter-cleaned Ag foil), not known every time and cann update over time (detector degradation). unit: NX_ENERGY + manufacturer(NX_CHAR): + exists: recommended + doc: "The name of the company that manufactured the spectrometer." + enumeration: [ + "SPECS GmbH", + "Kratos", + "Physical Electronics", + "Scienta", + "Thermo Fischer Scientific", + ] (NXsource): - doc: "The source used to generate the primary photons. Properties refer strictly to parameters of the source, not of the output beam. For example, the energy of the source is not the optical power of the beam, but the energy of the electron beam in a synchrotron and so on." type(NX_CHAR): - enumeration: [ + enumeration: [ ### removed some options from NXmpes "Synchrotron X-ray Source", "Rotating Anode X-ray", "Fixed Tube X-ray", "UV Laser", "Free-Electron Laser", - "Optical Laser", "UV Plasma Source", "Metal Jet X-ray", - "HHG laser" ] - name(NX_CHAR): - doc: "Free text description of the analyzer name used in the laboratory." probe(NX_CHAR): - doc: "Type of probe. In XPS it's always X-ray photons, so the full NIAC list is restricted." - enumeration: ["x-ray","ultraviolet"] - beam_probe(NXbeam): + doc: "Type of probe. In XPS it's always X-ray photons (or UV light in UPS), so the full NIAC list is restricted." + enumeration: ["x-ray", "ultraviolet"] + (NXmonochromator): + exists: optional + applied(NX_BOOLEAN): + doc: "Has the incident beam been monochromatized? " + type(NX_CHAR): + enumeration: [ + "Crystal", + "Grating", + ] + crystal(NXcrystal): + exists: optional + doc: "For crystal based monochromators. Use as many crystals as necessary." + grating(NXgrating): + exists: optional + doc: "For diffraction grating based monochromators. Use as many crystals as necessary." + energy(NX_FLOAT): + doc: "The scalar energy of the monchromatic beam. This should link to /entry/instrument/beam/incident_energy." ######how to do links? + unit: NX_ENERGY + energy_error(NX_FLOAT): + doc: "The energy spread FWHM for the corresponding energy in energy. This should link to /entry/instrument/beam/incident_energy_spread." + unit: NX_ENERGY + transformations(NXtransformations) ###### should we describe the beam rotation by the mono? + exists: optional + (NXbeam): distance(NX_NUMBER): - doc: "Distance of the point of evaluation of the beam from the sample surface." - exists: recommended + exists: recommended ### cannot be required, hard to know??? + doc: "Distance of the point of evaluation of the beam from the sample surface." unit: NX_LENGTH incident_energy(NX_FLOAT): unit: NX_ENERGY @@ -68,28 +94,24 @@ NXmpes: exists: recommended unit: NX_ENERGY doc: "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 energy in incident_energy." - incident_polarization(NX_NUMBER): - exists: recommended - doc: "Incident polarization specified as a Stokes vector." - \@units(NX_CHAR): - doc: "The units for this observable are not included in the NIAC list. Responsibility on correct formatting and parsing is handed to the user by using ‘NX_ANY’. Correct parsing can still be implemented by using this attribute. Fill with: The unit unidata symbol if the unit has one (Example: ‘T’ for the unit of magnetic flux density tesla). The unit unidata name if the unit has a name (Example: ‘farad’ for capacitance). A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and does not have a name. Example: for lightsource brilliance (SI) ‘1/(s.mm2.mrad2)’. Here: SI units are ‘V2/m2’." + #incident_polarization(NX_NUMBER): + # exists: recommended + # doc: "Incident polarization specified as a Stokes vector." + # \@units(NX_CHAR): + # doc: "The units for this observable are not included in the NIAC list. Responsibility on correct formatting and parsing is handed to the user by using ‘NX_ANY’. Correct parsing can still be implemented by using this attribute. Fill with: The unit unidata symbol if the unit has one (Example: ‘T’ for the unit of magnetic flux density tesla). The unit unidata name if the unit has a name (Example: ‘farad’ for capacitance). A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and does not have a name. Example: for lightsource brilliance (SI) ‘1/(s.mm2.mrad2)’. Here: SI units are ‘V2/m2’." (NXelectronanalyser): description(NX_CHAR): doc: "Free text description of the type of detector." - energy_resolution(NX_FLOAT): - exists: recommended - doc: "Energy resolution of the analyser with the current setting. May be linked from a NXcalibration." - unit: NX_ENERGY - fast_axes(NX_CHAR): - exists: optional - doc: "List of the axes that are acquired symultaneously 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. Examples: Hemispherical in XPS mode: fast_axes: [energy] Hemispherical with channeltron, sweeping energy mode: slow_axes: [energy] axes can be less abstract than this, i.e. [detector_x, detector_y]." - slow_axes(NX_CHAR): - exists: optional - doc: "List of the axes that are acquired by scanning a physical parameter, listed in order of decreasing speed. See fast_axes for examples." - COLLECTIONCOLUMN(NXcollectioncolumn): + # fast_axes(NX_CHAR): ### how to use these? + # exists: optional + # doc: "List of the axes that are acquired symultaneously 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. Hemispherical in XPS mode: fast_axes: [energy] Hemispherical with channeltron, sweeping energy mode: slow_axes: [energy] axes can be less abstract than this, i.e. [detector_x, detector_y]." + # slow_axes(NX_CHAR): + # exists: optional + # doc: "List of the axes that are acquired by scanning a physical parameter, listed in order of decreasing speed. See fast_axes for examples." + (NXcollectioncolumn): scheme(NX_CHAR): doc: "Scheme of the electron collection column." - enumeration: [ + enumeration: [ ### removed some options from NXmpes "Standard", "Angular dispersive", "Selective area", @@ -98,11 +120,14 @@ NXmpes: mode(NX_CHAR): exists: recommended doc: "Labelling of the lens setting in use. Names are typically presets provided by the instrument vendor." + # projection(NX_CHAR): #### what does this mean? + # exists: recommended tranmission_function(NX_FLOAT): - doc: "Transmission function in dependance of the electron kinetic energy. To be used in intensity calibration." + exists: recommended + doc: "Transmission function in dependance of the electron kinetic energy. To be used in intensity calibration." ### does NX_FLOAT make sense? (NXenergydispersion): scheme(NX_CHAR): - enumeration: + enumeration: ### removed some options from NXmpes [ "hemispherical", "double hemispherical", @@ -115,93 +140,122 @@ NXmpes: unit: NX_ENERGY energy_scan_mode(NX_CHAR): doc: "Way of scanning the energy axis." - enumeration: [ + enumeration: [ ### could potentially add some more here. "fixed analyzer transmission", "fixed retarding ratio", "fixed energies", "snapshot", + "imaging", "detector voltage scan", "constant final state", "constant initial state", ] - entrance_slit(NXaperture): - exists: optional - doc: "Size, position, and shape of the entrance slit in dispersive analyzers (aperture generating the energy filtering)." - description(NX_CHAR): - doc: "Type of aperture inserted in the beam." - enumeration: ["slit", "pinhole", "iris"] - shape(NX_CHAR): - doc: "Description of the shape of the active part of the aperture, curved or straight for horizontal slits, square or round for pinhole etc." - enumeration: - [ - "curved", - "straight", - "circle", - "square", - "hexagon", - "octagon", - "bladed", - ] - exit_slit(NXaperture): - exists: optional - doc: "Size, position and shape of the exit slit in dispersive analyzers." - description(NX_CHAR): - doc: "Type of aperture inserted in the beam." - enumeration: ["slit", "pinhole", "iris"] - shape(NX_CHAR): - doc: "Description of the shape of the active part of the aperture, curved or straight for horizontal slits, square or round for pinhole etc." - enumeration: - [ - "curved", - "straight", - "circle", - "square", - "hexagon", - "octagon", - "bladed", - ] - iris(NXaperture): + # entrance_slit(NXaperture): ### is this level of description necessary -> most items exist in NXaperture already + # exists: optional + # doc: "Size, position, and shape of the entrance slit in dispersive analyzers (aperture generating the energy filtering)." + # description(NX_CHAR): + # exists: optional + # doc: "Type of aperture inserted in the beam." + # enumeration: ["slit", "pinhole", "iris"] + # shape(NX_CHAR): + # exists: optional + # doc: "Description of the shape of the active part of the aperture, curved or straight for horizontal slits, square or round for pinhole etc." + # enumeration: + # [ + # "straight slit", + # "curved slit", + # "pinhole", + # "circle", + # "square", + # "hexagon", + # "octagon", + # "bladed", + # "open", + # "grid" + # ] + # size(NX_NUMBER): + # exists: optional + # doc: "The relevant dimension for the entrance_slit, i.e. slit width, pinhole and iris diameter." + # exit_slit(NXaperture): + # exists: optional + # doc: "Size, position and shape of the exit slit in dispersive analyzers." + # description(NX_CHAR): + # exists: optional + # doc: "Type of aperture inserted in the beam." + # enumeration: ["slit", "pinhole", "iris"] + # shape(NX_CHAR): + # exists: optional + # doc: "Description of the shape of the active part of the aperture, curved or straight for horizontal slits, square or round for pinhole etc." + # enumeration: + # [ + # "straight slit", + # "curved slit", + # "pinhole", + # "circle", + # "square", + # "hexagon", + # "octagon", + # "bladed", + # "open", + # "grid" + # ] + # size(NX_NUMBER): + # exists: optional + # doc: "The relevant dimension for the entrance_slit, i.e. slit width, pinhole and iris diameter." + # iris(NXaperture): + # exists: optional + # doc: "Size, position, and shape of the iris in dispersive analyzers." + # description(NX_CHAR): + # exists: optional + # doc: "Type of aperture inserted in the beam." + # enumeration: ["slit", "pinhole", "iris"] + # shape(NX_CHAR): + # exists: optional + # doc: "Description of the shape of the active part of the aperture, curved or straight for horizontal slits, square or round for pinhole etc." + # enumeration: + # [ + # "straight slit", + # "curved slit", + # "pinhole", + # "circle", + # "square", + # "hexagon", + # "octagon", + # "bladed", + # "open", + # "grid" + # ] + # size(NX_NUMBER): + # exists: optional + # doc: "The relevant dimension for the entrance_slit, i.e. slit width, pinhole and iris diameter." + analyzer_radius(NX_FLOAT): exists: optional - doc: "Size, position, and shape of the iris in dispersive analyzers." - description(NX_CHAR): - doc: "Type of aperture inserted in the beam." - shape(NX_CHAR): - doc: "Description of the shape of the active part of the aperture, curved or straight for horizontal slits, square or round for pinhole etc." - enumeration: - [ - "curved", - "straight", - "circle", - "square", - "hexagon", - "octagon", - "bladed", - ] - - electron_detector(NXdetector): - amplifier_type(NX_CHAR): - exists: recommended - doc: "Type of electron amplifier in the first amplification step." - enumeration: ["MCP", "channeltron"] - # ToDo: Representation of count rate calibration - detector_type(NX_CHAR): - exists: recommended - doc: "Description of the detector type." - enumeration: - [ - "DLD", - "Phosphor+CCD", - "Phosphor+CMOS", - "ECMOS", - "Anode", - "Multi-anode"] - (NXdata): # Raw signal without calibrated axes. - exists: recommended - \@signal: - enumeration: ['raw'] - raw(NX_NUMBER): # There is a block of numbers named raw. - doc: "Raw data before calibration." - GEOMETRY(NXtransformations): + description: The radius of the hemispherical analyzer in mm (only if hemispherical analyzer is used.) + (NXdetector): + # amplifier:type(NX_CHAR): + # exists: recommended + # doc: "Description of the detector type." + # enumeration: + # ["MCP", "channeltron"] + # detector_type(NX_CHAR): + # exists: recommended + # doc: "Description of the detector type." + # enumeration: + # [ + # "DLD", + # "Phosphor+CCD", + # "Phosphor+CMOS", + # "ECMOS", + # "Anode", + # "Multi-anode" + # ] + # (NXdata): # Raw signal without calibrated axes. + # exists: recommended + # \@signal: + # enumeration: ['raw'] + # raw(NX_NUMBER): # There is a block of numbers named raw. + # doc: "Raw data before calibration." + GEOMETRY(NXtransformations): ### took this from NXmpes_liqudidjet, how to describe geometry? on indicidual classes? would like to describe angles between different instrument parts here? exists: optional doc: "Transformations describing the transformation chain of all relevant vectors in the experiment." gravity_axis(NX_NUMBER): @@ -230,110 +284,132 @@ NXmpes: \@depends_on(NX_CHAR): doc: "This should be a link to /entry/instrument/geometry/analyzer_lens_axis." (NXmanipulator): - exists: optional - doc: "Manipulator for positioning of the sample." - sample_temperature(NX_FLOAT): - exists: recommended - doc: "Sample temperature during the experiment. Can be a single float or an array for temperature-programmed XPS." - unit: NX_TEMPERATURE + # exists: optional + # doc: "Manipulator for positioning of the sample." + # sample_temperature(NX_FLOAT): + # exists: recommended + # doc: "Sample temperature during the experiment. Can be a single float or an array for temperature-programmed XPS." + # unit: NX_TEMPERATURE sample_heater(NX_CHAR): exists: optional doc: "Method of heating the sample. Can be e.g. electron beam heating, laser, halogen lamp" - drain_current(NX_FLOAT): - exists: recommended - doc: "Measured drain current of the sample." - unit: NX_CURRENT - sample_bias(NX_FLOAT): - exists: recommended - doc: "External sample bias." - unit: NX_CURRENT - calibration(NXprocess): - doc: "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" + # heater_power(NX_FLOAT): + # exists: optional + # doc: "Power in the heater for temperature control." + # sample_temperature(NX_FLOAT): + # exists: optional + # doc: "Temperature at the closest point to the sample. This field may also be found in NXsample if present." + # drain_current(NX_FLOAT): + # exists: recommended + # doc: "Measured drain current of the sample. This field may also be found in NXsample if present." + # unit: NX_CURRENT + # sample_bias(NX_FLOAT): + # exists: recommended + # doc: "Possible bias of the sample with respect to analyser ground. This field may also be found in NXsample if present." + # unit: NX_CURRENT + (NXprocess): + # doc: "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." energy_calibration(NXcalibration): - exists: recommended - applied(NX_BOOLEAN): - doc: "Has an energy calibration been applied?" + # exists: recommended + # applied(NX_BOOLEAN): + # doc: "Has an energy calibration been applied?" calibration_file(NX_CHAR): exists: recommended doc: "Name of the calibration file containing the calibration data." - calibrated_axis(NX_FLOAT): - exists: recommended - doc: "This is the calibrated energy axis to be used for data plotting." + # calibrated_axis(NX_FLOAT): + # exists: recommended + # doc: "This is the calibrated energy axis to be used for data plotting." + # spatial_calibration(NXcalibration): + # exists: optional + # applied(NX_BOOLEAN): + # doc: "Has a spatial calibration been applied?" + # calibrated_axis(NX_FLOAT): + # exists: recommended + # doc: "This is the calibrated spatial axis to be used for data plotting." intensity_calibration(NXcalibration): exists: recommended applied(NX_BOOLEAN): - doc: "Has an intensity calibration been applied? I.e., has the transmission function of the analyzer been taken into account?" + doc: "Has an intensity calibration been applied? That is, has the transmission function of the analyzer been taken into account?" transmission_function(NX_FLOAT): exists: recommended - doc: "Transmission function of the electron collection column. This should be a link to /entry/instrument/collectioncolumn/tranmission_function." - calibrated_axis(NX_FLOAT): - exists: recommended - doc: "This is the calibrated intensity axis to be used for data plotting." - spatial_calibration(NXcalibration): - exists: optional + doc: "Transmission function of the electron collection column. This should be a link to /entry/instrument/collectioncolumn/tranmission_function." + energy_reference(NXcalibration): + exists: recommended applied(NX_BOOLEAN): - doc: "Has an spatial calibration been applied?" + doc: "Have the energy axes been adjusted (e.g., in cases where samples are not conductive)?" + emission_line(NX_CHAR): + exists: recommended + doc: "Emission line which was used for the calibration." + offset(NXfloat): + exists: recommended + doc: "Offset between measured binding energy and calibrated binding energy of the emission line." + binding_energy(NX_float): + exists: recommended + doc: "The binding energy that the specified emission line appeared at, after adjusting the binding energy scale, in units of eV" calibrated_axis(NX_FLOAT): exists: recommended - doc: "This is the calibrated spatial axis to be used for data plotting." + doc: "This is the calibrated energy axis to be used for data plotting. This should be a link to /entry/data/energy." ######???? (NXsample): - name: + name(NX_CHAR): doc: "The user-assigned name of the sample." - chemical_formula: - exists: recommended - doc: "The chemical formula of the sample. For mixtures use the NXsample_component group in NXsample instead." - sample_history(NXnote): - exists: recommended - doc: "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." - atom_types: - exists: recommended - doc: "List of comma-separated elements from the periodic table that are contained in the sample. - If the sample substance has multiple components, all elements from each component must be included in `atom_types`." - preparation_date(NX_DATE_TIME): - exists: recommended - doc: "Date of preparation of the sample for the XPS experiment (i.e. cleaving, last annealing)." - preparation_description(NXnote): - doc: "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." - temperature(NX_FLOAT): - doc: "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." - unit: NX_TEMPERATURE - situation(NX_CHAR): + description(NX_CHAR): + exists: optional + doc: "Full description of the sample." + # chemical_formula: + # exists: recommended + # doc: "The chemical formula of the sample. For mixtures use the NXsample_component group in NXsample instead." + # atom_types: + # exists: recommended + # 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`." + form(NX_CHAR): + exists: optional + enumeration: + [ + "foil", + "single crystal", + "pellet", + "powder", + "calibration sample", + ] + # preparation_date(NX_DATE_TIME): + # exists: recommended + # doc: "Date of preparation of the sample for the XPS experiment (i.e. cleaving, last annealing)." + # temperature(NX_FLOAT): + # doc: "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." + # unit: NX_TEMPERATURE + situation(NX_CHAR): ### missing some enumerations here enumeration: [ "vacuum", "inert atmosphere", "oxidising atmosphere", - "reducing atmosphere"] - # Can be a single number or a log. - gas_pressure(NX_FLOAT): + "reducing atmosphere", + "other" + ] + gas_pressure(NX_FLOAT): ######## Can be a single number or a log. unit: NX_PRESSURE doc: "In the case of a fixed pressure measurement this is the scalar pressure. In the case of an experiment in which pressure changes, or anyway it is recorded, this is an array of length m of pressures." + # sample_history(NXnote): + # exists: recommended + # doc: "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." + # preparation_description(NXnote): + # doc: "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." gas_phase(NX_CHAR): - unit: NX_PRESSURE - doc: "In the case of a fixed pressure measurement this is the scalar pressure. In the case of an experiment in which pressure changes, or anyway it is recorded, this is an array of length m of pressures." + exists: optional + doc: "Description of the constitutent gases of the gas phase." electric_field(NX_FLOAT): - exists: recommended + exists: optional unit: NX_VOLTAGE doc: "Electric field applied to the sample with respect to ground / the system, e.g., via biasing." - type(NX_CHAR): - exists: optional - enumeration: - [ - "foil", - "single crystal", - "pellet", - "powder", - "calibration sample", - ] (NXdata): - doc: "There is an object named data that contains the signal." - \@signal: - enumeration: ["data"] + # \@signal: + # enumeration: ["data"] \@axes(NX_CHAR): doc: "The energy axis. Can be either scanned or derived from scanning of other energy axis." - energy(NX_NUMBER): + energy(NX_NUMBER): #### how to represent this here? \@units(NX_CHAR): exists: recommended \@long_name(NX_CHAR): @@ -347,7 +423,7 @@ NXmpes: "energy" ] step_size(NX_CHAR): - exists: recommended + exists: optional doc: "The step size between two consecutive energy values." data(NX_NUMBER): # There is a block of numbers named data. doc: "Processed plottable data. Represents a measure of one- or more-dimensional photoemission counts, where From 65bfb910b0979ff0b08ab099057eecce110cf493 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 4 May 2023 18:42:57 +0200 Subject: [PATCH 0845/1012] Removed information already given in base classes --- contributed_definitions/nyaml/NXmpes_xps.yaml | 358 +++--------------- 1 file changed, 43 insertions(+), 315 deletions(-) diff --git a/contributed_definitions/nyaml/NXmpes_xps.yaml b/contributed_definitions/nyaml/NXmpes_xps.yaml index e0d17ff779..e256f273f0 100644 --- a/contributed_definitions/nyaml/NXmpes_xps.yaml +++ b/contributed_definitions/nyaml/NXmpes_xps.yaml @@ -7,47 +7,32 @@ NXmpes_xps(NXmpes): (NXentry): end_time(NX_DATE_TIME): exists: recommended - doc: "Datetime of the end of the measurement." definition(NX_CHAR): - \@version(NX_CHAR): enumeration: ["NXmpes_xps"] - # (NXuser): #### nothing changed, can be removed from here? - # doc: "Contact information of at least the user of the instrument or the - # investigator who performed this experiment. - # Adding multiple users if relevant is recommended." - # name(NX_CHAR): - # exists: recommended - # doc: "Name of the user." - # affiliation(NX_CHAR): - # exists: recommended - # doc: "Name of the affiliation of the user at the point in time when the - # experiment was performed." - # address(NX_CHAR): - # exists: recommended - # doc: "Full address (street, street number, ZIP, city, country) of the - # user's affiliation." - # email(NX_CHAR): - # doc: "Email address of the user." - # orcid(NX_CHAR): - # exists: recommended - # doc: "Author ID defined by https://orcid.org/." (NXinstrument): energy_resolution(NX_FLOAT): exists: recommended ###### cannot be required. measured value (typically from Ag 3d5/2 FWHM of sputter-cleaned Ag foil), not known every time and cann update over time (detector degradation). unit: NX_ENERGY - manufacturer(NX_CHAR): + manufacturer(NXfabrication): #### should go to NXmpes at some point. exists: recommended - doc: "The name of the company that manufactured the spectrometer." - enumeration: [ + vendor: + exists: recommended + enumeration: [ "SPECS GmbH", "Kratos", "Physical Electronics", "Scienta", "Thermo Fischer Scientific", ] + model: + exists: recommended + work_function(NX_FLOAT): + exists: recommended ###### new + doc: "Work function of the spectrometer." + unit: NX_ENERGY (NXsource): type(NX_CHAR): - enumeration: [ ### removed some options from NXmpes + enumeration: [ "Synchrotron X-ray Source", "Rotating Anode X-ray", "Fixed Tube X-ray", @@ -59,75 +44,21 @@ NXmpes_xps(NXmpes): probe(NX_CHAR): doc: "Type of probe. In XPS it's always X-ray photons (or UV light in UPS), so the full NIAC list is restricted." enumeration: ["x-ray", "ultraviolet"] - (NXmonochromator): - exists: optional - applied(NX_BOOLEAN): - doc: "Has the incident beam been monochromatized? " - type(NX_CHAR): - enumeration: [ - "Crystal", - "Grating", - ] - crystal(NXcrystal): - exists: optional - doc: "For crystal based monochromators. Use as many crystals as necessary." - grating(NXgrating): - exists: optional - doc: "For diffraction grating based monochromators. Use as many crystals as necessary." - energy(NX_FLOAT): - doc: "The scalar energy of the monchromatic beam. This should link to /entry/instrument/beam/incident_energy." ######how to do links? - unit: NX_ENERGY - energy_error(NX_FLOAT): - doc: "The energy spread FWHM for the corresponding energy in energy. This should link to /entry/instrument/beam/incident_energy_spread." - unit: NX_ENERGY - transformations(NXtransformations) ###### should we describe the beam rotation by the mono? - exists: optional - (NXbeam): - distance(NX_NUMBER): - exists: recommended ### cannot be required, hard to know??? - doc: "Distance of the point of evaluation of the beam from the sample surface." - unit: NX_LENGTH - incident_energy(NX_FLOAT): - unit: NX_ENERGY - doc: "In the case of a monchromatic 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." - incident_energy_spread(NX_NUMBER): - exists: recommended - unit: NX_ENERGY - doc: "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 energy in incident_energy." - #incident_polarization(NX_NUMBER): - # exists: recommended - # doc: "Incident polarization specified as a Stokes vector." - # \@units(NX_CHAR): - # doc: "The units for this observable are not included in the NIAC list. Responsibility on correct formatting and parsing is handed to the user by using ‘NX_ANY’. Correct parsing can still be implemented by using this attribute. Fill with: The unit unidata symbol if the unit has one (Example: ‘T’ for the unit of magnetic flux density tesla). The unit unidata name if the unit has a name (Example: ‘farad’ for capacitance). A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and does not have a name. Example: for lightsource brilliance (SI) ‘1/(s.mm2.mrad2)’. Here: SI units are ‘V2/m2’." (NXelectronanalyser): - description(NX_CHAR): - doc: "Free text description of the type of detector." - # fast_axes(NX_CHAR): ### how to use these? - # exists: optional - # doc: "List of the axes that are acquired symultaneously 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. Hemispherical in XPS mode: fast_axes: [energy] Hemispherical with channeltron, sweeping energy mode: slow_axes: [energy] axes can be less abstract than this, i.e. [detector_x, detector_y]." - # slow_axes(NX_CHAR): - # exists: optional - # doc: "List of the axes that are acquired by scanning a physical parameter, listed in order of decreasing speed. See fast_axes for examples." (NXcollectioncolumn): scheme(NX_CHAR): - doc: "Scheme of the electron collection column." - enumeration: [ ### removed some options from NXmpes + enumeration: [ ### removed some options from NXmpes "Standard", "Angular dispersive", "Selective area", "Deflector", ] - mode(NX_CHAR): - exists: recommended - doc: "Labelling of the lens setting in use. Names are typically presets provided by the instrument vendor." - # projection(NX_CHAR): #### what does this mean? - # exists: recommended - tranmission_function(NX_FLOAT): + transmission_function(NX_FLOAT): exists: recommended doc: "Transmission function in dependance of the electron kinetic energy. To be used in intensity calibration." ### does NX_FLOAT make sense? (NXenergydispersion): scheme(NX_CHAR): - enumeration: ### removed some options from NXmpes + enumeration: ### removed some options from NXmpes [ "hemispherical", "double hemispherical", @@ -135,12 +66,9 @@ NXmpes_xps(NXmpes): "display mirror", "retarding grid", ] - pass_energy(NX_FLOAT): - doc: "Pass energy of energy dispersive element. Determines measurement resolution." - unit: NX_ENERGY energy_scan_mode(NX_CHAR): doc: "Way of scanning the energy axis." - enumeration: [ ### could potentially add some more here. + enumeration: [ ### could potentially add some more here. "fixed analyzer transmission", "fixed retarding ratio", "fixed energies", @@ -150,220 +78,51 @@ NXmpes_xps(NXmpes): "constant final state", "constant initial state", ] - # entrance_slit(NXaperture): ### is this level of description necessary -> most items exist in NXaperture already - # exists: optional - # doc: "Size, position, and shape of the entrance slit in dispersive analyzers (aperture generating the energy filtering)." - # description(NX_CHAR): - # exists: optional - # doc: "Type of aperture inserted in the beam." - # enumeration: ["slit", "pinhole", "iris"] - # shape(NX_CHAR): - # exists: optional - # doc: "Description of the shape of the active part of the aperture, curved or straight for horizontal slits, square or round for pinhole etc." - # enumeration: - # [ - # "straight slit", - # "curved slit", - # "pinhole", - # "circle", - # "square", - # "hexagon", - # "octagon", - # "bladed", - # "open", - # "grid" - # ] - # size(NX_NUMBER): - # exists: optional - # doc: "The relevant dimension for the entrance_slit, i.e. slit width, pinhole and iris diameter." - # exit_slit(NXaperture): - # exists: optional - # doc: "Size, position and shape of the exit slit in dispersive analyzers." - # description(NX_CHAR): - # exists: optional - # doc: "Type of aperture inserted in the beam." - # enumeration: ["slit", "pinhole", "iris"] - # shape(NX_CHAR): - # exists: optional - # doc: "Description of the shape of the active part of the aperture, curved or straight for horizontal slits, square or round for pinhole etc." - # enumeration: - # [ - # "straight slit", - # "curved slit", - # "pinhole", - # "circle", - # "square", - # "hexagon", - # "octagon", - # "bladed", - # "open", - # "grid" - # ] - # size(NX_NUMBER): - # exists: optional - # doc: "The relevant dimension for the entrance_slit, i.e. slit width, pinhole and iris diameter." - # iris(NXaperture): - # exists: optional - # doc: "Size, position, and shape of the iris in dispersive analyzers." - # description(NX_CHAR): - # exists: optional - # doc: "Type of aperture inserted in the beam." - # enumeration: ["slit", "pinhole", "iris"] - # shape(NX_CHAR): - # exists: optional - # doc: "Description of the shape of the active part of the aperture, curved or straight for horizontal slits, square or round for pinhole etc." - # enumeration: - # [ - # "straight slit", - # "curved slit", - # "pinhole", - # "circle", - # "square", - # "hexagon", - # "octagon", - # "bladed", - # "open", - # "grid" - # ] - # size(NX_NUMBER): - # exists: optional - # doc: "The relevant dimension for the entrance_slit, i.e. slit width, pinhole and iris diameter." + iris(NXaperture): + exists: optional analyzer_radius(NX_FLOAT): exists: optional description: The radius of the hemispherical analyzer in mm (only if hemispherical analyzer is used.) - (NXdetector): - # amplifier:type(NX_CHAR): - # exists: recommended - # doc: "Description of the detector type." - # enumeration: - # ["MCP", "channeltron"] - # detector_type(NX_CHAR): - # exists: recommended - # doc: "Description of the detector type." - # enumeration: - # [ - # "DLD", - # "Phosphor+CCD", - # "Phosphor+CMOS", - # "ECMOS", - # "Anode", - # "Multi-anode" - # ] - # (NXdata): # Raw signal without calibrated axes. - # exists: recommended - # \@signal: - # enumeration: ['raw'] - # raw(NX_NUMBER): # There is a block of numbers named raw. - # doc: "Raw data before calibration." - GEOMETRY(NXtransformations): ### took this from NXmpes_liqudidjet, how to describe geometry? on indicidual classes? would like to describe angles between different instrument parts here? - exists: optional - doc: "Transformations describing the transformation chain of all relevant vectors in the experiment." - gravity_axis(NX_NUMBER): - doc: "Direction of gravity." - \@vector(NX_NUMBER): - doc: "The vector in the direction of gravity." - \@depends_on(NX_CHAR): - doc: "Set to '.' to specify the normal vector to which all other vectors are related." - beam_axis(NX_NUMBER): - doc: "Direction of the photon beam." - \@vector(NX_NUMBER): - doc: "The vector of the photon-beam direction into the chamber after the last optical element (or directly from the source if there are no optical elements)." - \@depends_on(NX_CHAR): - doc: "This should be a link to /entry/instrument/geometry/gravity_axis." - analyzer_lens_axis(NX_NUMBER): - doc: "Direction of lens axis of analyzer." - \@vector(NX_NUMBER): - doc: "The vector pointing along the central axis of the analyzer lens system in from the sample." - \@depends_on(NX_CHAR): - doc: "This should be a link to /entry/instrument/geometry/beam_axis." - hemisphere_orientation(NX_NUMBER): - exists: optional - doc: "Orientation of the hemisphere with respect to the lens system in case of a hemispherical electron analyzer." - \@vector(NX_NUMBER): - doc: "The vector pointing towards the detector from the entrance slit of the hemisphere, and should be perpendicular to the analyzer lens system." - \@depends_on(NX_CHAR): - doc: "This should be a link to /entry/instrument/geometry/analyzer_lens_axis." + unit: NX_LENGTH (NXmanipulator): - # exists: optional - # doc: "Manipulator for positioning of the sample." - # sample_temperature(NX_FLOAT): - # exists: recommended - # doc: "Sample temperature during the experiment. Can be a single float or an array for temperature-programmed XPS." - # unit: NX_TEMPERATURE - sample_heater(NX_CHAR): + heater_type(NX_CHAR): exists: optional - doc: "Method of heating the sample. Can be e.g. electron beam heating, laser, halogen lamp" - # heater_power(NX_FLOAT): - # exists: optional - # doc: "Power in the heater for temperature control." - # sample_temperature(NX_FLOAT): - # exists: optional - # doc: "Temperature at the closest point to the sample. This field may also be found in NXsample if present." - # drain_current(NX_FLOAT): - # exists: recommended - # doc: "Measured drain current of the sample. This field may also be found in NXsample if present." - # unit: NX_CURRENT - # sample_bias(NX_FLOAT): - # exists: recommended - # doc: "Possible bias of the sample with respect to analyser ground. This field may also be found in NXsample if present." - # unit: NX_CURRENT + doc: "Method of heating the sample. Can be e.g. electron beam heating, laser, halogen lamp." + enumeration: [ ### could potentially add some more here. + "electron beam heating", + "laser", + "halogen lamp", + ] (NXprocess): - # doc: "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." energy_calibration(NXcalibration): - # exists: recommended - # applied(NX_BOOLEAN): - # doc: "Has an energy calibration been applied?" - calibration_file(NX_CHAR): - exists: recommended - doc: "Name of the calibration file containing the calibration data." - # calibrated_axis(NX_FLOAT): - # exists: recommended - # doc: "This is the calibrated energy axis to be used for data plotting." - # spatial_calibration(NXcalibration): - # exists: optional - # applied(NX_BOOLEAN): - # doc: "Has a spatial calibration been applied?" - # calibrated_axis(NX_FLOAT): - # exists: recommended - # doc: "This is the calibrated spatial axis to be used for data plotting." + exists: optional + calibration_file(NXnote): + exists: optional + doc: "Name of the calibration file containing the calibration data." intensity_calibration(NXcalibration): - exists: recommended + exists: optional applied(NX_BOOLEAN): doc: "Has an intensity calibration been applied? That is, has the transmission function of the analyzer been taken into account?" transmission_function(NX_FLOAT): exists: recommended doc: "Transmission function of the electron collection column. This should be a link to /entry/instrument/collectioncolumn/tranmission_function." energy_reference(NXcalibration): - exists: recommended + exists: optional applied(NX_BOOLEAN): doc: "Have the energy axes been adjusted (e.g., in cases where samples are not conductive)?" emission_line(NX_CHAR): exists: recommended doc: "Emission line which was used for the calibration." - offset(NXfloat): + offset(NX_FLOAT): exists: recommended doc: "Offset between measured binding energy and calibrated binding energy of the emission line." - binding_energy(NX_float): + binding_energy(NX_FLOAT): exists: recommended doc: "The binding energy that the specified emission line appeared at, after adjusting the binding energy scale, in units of eV" calibrated_axis(NX_FLOAT): exists: recommended doc: "This is the calibrated energy axis to be used for data plotting. This should be a link to /entry/data/energy." ######???? - (NXsample): - name(NX_CHAR): - doc: "The user-assigned name of the sample." - description(NX_CHAR): - exists: optional - doc: "Full description of the sample." - # chemical_formula: - # exists: recommended - # doc: "The chemical formula of the sample. For mixtures use the NXsample_component group in NXsample instead." - # atom_types: - # exists: recommended - # 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`." + (NXsample): form(NX_CHAR): exists: optional enumeration: @@ -372,59 +131,28 @@ NXmpes_xps(NXmpes): "single crystal", "pellet", "powder", - "calibration sample", ] - # preparation_date(NX_DATE_TIME): - # exists: recommended - # doc: "Date of preparation of the sample for the XPS experiment (i.e. cleaving, last annealing)." - # temperature(NX_FLOAT): - # doc: "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." - # unit: NX_TEMPERATURE - situation(NX_CHAR): ### missing some enumerations here - enumeration: - [ - "vacuum", - "inert atmosphere", - "oxidising atmosphere", - "reducing atmosphere", - "other" - ] gas_pressure(NX_FLOAT): ######## Can be a single number or a log. unit: NX_PRESSURE doc: "In the case of a fixed pressure measurement this is the scalar pressure. In the case of an experiment in which pressure changes, or anyway it is recorded, this is an array of length m of pressures." - # sample_history(NXnote): - # exists: recommended - # doc: "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." - # preparation_description(NXnote): - # doc: "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." gas_phase(NX_CHAR): exists: optional - doc: "Description of the constitutent gases of the gas phase." - electric_field(NX_FLOAT): - exists: optional - unit: NX_VOLTAGE - doc: "Electric field applied to the sample with respect to ground / the system, e.g., via biasing." + doc: "Description of the constituent gases of the gas phase." (NXdata): - # \@signal: - # enumeration: ["data"] \@axes(NX_CHAR): - doc: "The energy axis. Can be either scanned or derived from scanning of other energy axis." - energy(NX_NUMBER): #### how to represent this here? - \@units(NX_CHAR): - exists: recommended - \@long_name(NX_CHAR): - exists: optional - type(NX_CHAR): + doc: "It should contain at least one axis called 'energy'." + energy(NX_NUMBER): #### how to represent this here? + \@type(NX_CHAR): exists: recommended - doc: "The energy axis can be either in binding or kinetic energy." + doc: "The calibrated energy axis can be either in binding or kinetic energy. " enumeration: [ "kinetic", - "energy" - ] - step_size(NX_CHAR): + "binding" + ] + \@step_size(NX_FLOAT): exists: optional - doc: "The step size between two consecutive energy values." + doc: "The step size between two consecutive energy values if the energy axis is evenly spaced." data(NX_NUMBER): # There is a block of numbers named data. doc: "Processed plottable data. Represents a measure of one- or more-dimensional photoemission counts, where the varied axis may be for example energy, spatial coordinate, pump-probe delay, temperature, etc. From d2d22f8fc31f33fb3dac6f579ad19eb41c43a416 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 5 May 2023 09:27:34 +0200 Subject: [PATCH 0846/1012] Removed some unneeded comments --- contributed_definitions/nyaml/NXmpes_xps.yaml | 26 ++++++++++--------- 1 file changed, 14 insertions(+), 12 deletions(-) diff --git a/contributed_definitions/nyaml/NXmpes_xps.yaml b/contributed_definitions/nyaml/NXmpes_xps.yaml index e256f273f0..2852868e97 100644 --- a/contributed_definitions/nyaml/NXmpes_xps.yaml +++ b/contributed_definitions/nyaml/NXmpes_xps.yaml @@ -11,9 +11,9 @@ NXmpes_xps(NXmpes): enumeration: ["NXmpes_xps"] (NXinstrument): energy_resolution(NX_FLOAT): - exists: recommended ###### cannot be required. measured value (typically from Ag 3d5/2 FWHM of sputter-cleaned Ag foil), not known every time and cann update over time (detector degradation). + exists: recommended # cannot be required. measured value (typically from Ag 3d5/2 FWHM of sputter-cleaned Ag foil), not known every time and cann update over time (detector degradation). unit: NX_ENERGY - manufacturer(NXfabrication): #### should go to NXmpes at some point. + manufacturer(NXfabrication): # Should go to NXmpes at some point. exists: recommended vendor: exists: recommended @@ -27,7 +27,7 @@ NXmpes_xps(NXmpes): model: exists: recommended work_function(NX_FLOAT): - exists: recommended ###### new + exists: recommended doc: "Work function of the spectrometer." unit: NX_ENERGY (NXsource): @@ -47,7 +47,7 @@ NXmpes_xps(NXmpes): (NXelectronanalyser): (NXcollectioncolumn): scheme(NX_CHAR): - enumeration: [ ### removed some options from NXmpes + enumeration: [ "Standard", "Angular dispersive", "Selective area", @@ -55,10 +55,10 @@ NXmpes_xps(NXmpes): ] transmission_function(NX_FLOAT): exists: recommended - doc: "Transmission function in dependance of the electron kinetic energy. To be used in intensity calibration." ### does NX_FLOAT make sense? + doc: "Transmission function in dependance of the electron kinetic energy. To be used in intensity calibration." (NXenergydispersion): scheme(NX_CHAR): - enumeration: ### removed some options from NXmpes + enumeration: [ "hemispherical", "double hemispherical", @@ -68,7 +68,8 @@ NXmpes_xps(NXmpes): ] energy_scan_mode(NX_CHAR): doc: "Way of scanning the energy axis." - enumeration: [ ### could potentially add some more here. + # Could potentially add some more options here. + enumeration: [ "fixed analyzer transmission", "fixed retarding ratio", "fixed energies", @@ -88,7 +89,8 @@ NXmpes_xps(NXmpes): heater_type(NX_CHAR): exists: optional doc: "Method of heating the sample. Can be e.g. electron beam heating, laser, halogen lamp." - enumeration: [ ### could potentially add some more here. + # Could potentially add some more options here. + enumeration: [ "electron beam heating", "laser", "halogen lamp", @@ -121,7 +123,7 @@ NXmpes_xps(NXmpes): doc: "The binding energy that the specified emission line appeared at, after adjusting the binding energy scale, in units of eV" calibrated_axis(NX_FLOAT): exists: recommended - doc: "This is the calibrated energy axis to be used for data plotting. This should be a link to /entry/data/energy." ######???? + doc: "This is the calibrated energy axis to be used for data plotting. This should be a link to /entry/data/energy." (NXsample): form(NX_CHAR): exists: optional @@ -132,7 +134,7 @@ NXmpes_xps(NXmpes): "pellet", "powder", ] - gas_pressure(NX_FLOAT): ######## Can be a single number or a log. + gas_pressure(NX_FLOAT): unit: NX_PRESSURE doc: "In the case of a fixed pressure measurement this is the scalar pressure. In the case of an experiment in which pressure changes, or anyway it is recorded, this is an array of length m of pressures." gas_phase(NX_CHAR): @@ -141,7 +143,7 @@ NXmpes_xps(NXmpes): (NXdata): \@axes(NX_CHAR): doc: "It should contain at least one axis called 'energy'." - energy(NX_NUMBER): #### how to represent this here? + energy(NX_NUMBER): \@type(NX_CHAR): exists: recommended doc: "The calibrated energy axis can be either in binding or kinetic energy. " @@ -153,7 +155,7 @@ NXmpes_xps(NXmpes): \@step_size(NX_FLOAT): exists: optional doc: "The step size between two consecutive energy values if the energy axis is evenly spaced." - data(NX_NUMBER): # There is a block of numbers named data. + data(NX_NUMBER): doc: "Processed plottable data. Represents a measure of one- or more-dimensional photoemission counts, where the varied axis may be for example energy, spatial coordinate, pump-probe delay, temperature, etc. The axes traces should be linked to the actual encoder position in NXinstrument or calibrated axes in NXprocess." From 33492b83e602c04bf3778707b0e9997e1fad2910 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 5 May 2023 11:33:40 +0200 Subject: [PATCH 0847/1012] Add description of instrument orientation - Angle between beam and sample normal-> needed for determination of probing depth - Angle between beam and analyzer axes -> needed for data analysis --- contributed_definitions/nyaml/NXmpes_xps.yaml | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/contributed_definitions/nyaml/NXmpes_xps.yaml b/contributed_definitions/nyaml/NXmpes_xps.yaml index 2852868e97..dee2ac6f0e 100644 --- a/contributed_definitions/nyaml/NXmpes_xps.yaml +++ b/contributed_definitions/nyaml/NXmpes_xps.yaml @@ -30,6 +30,15 @@ NXmpes_xps(NXmpes): exists: recommended doc: "Work function of the spectrometer." unit: NX_ENERGY + # These angles could also be described by NXtransformations on the analyzer and beam. + angle_beam_sample(NX_NUMBER): + exists: recommended + doc: "Orientation of the beam with respect to the sample normal." + units: NX_ANGLE + angle_beam_analyser(NX_NUMBER): + exists: recommended + doc: "Orientation of the beam with respect to the central axis of the analyzer." + units: NX_ANGLE (NXsource): type(NX_CHAR): enumeration: [ @@ -83,7 +92,7 @@ NXmpes_xps(NXmpes): exists: optional analyzer_radius(NX_FLOAT): exists: optional - description: The radius of the hemispherical analyzer in mm (only if hemispherical analyzer is used.) + description: "The radius of the hemispherical analyzer in mm (only if hemispherical analyzer is used." unit: NX_LENGTH (NXmanipulator): heater_type(NX_CHAR): From b1e10392dd4d7c8e4cf1bf9ce8397c8f0778ab0a Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 9 May 2023 14:20:10 +0200 Subject: [PATCH 0848/1012] Move orientation of instrument parts Instead of having two fields on the instrument for the angle between beam and sample and the angle between beam and analyser, this information is stored in depends_on and NXtransformations in NXinstrument and NXsample, respectively. --- contributed_definitions/nyaml/NXmpes_xps.yaml | 23 +++++++++++-------- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/contributed_definitions/nyaml/NXmpes_xps.yaml b/contributed_definitions/nyaml/NXmpes_xps.yaml index dee2ac6f0e..df68169d40 100644 --- a/contributed_definitions/nyaml/NXmpes_xps.yaml +++ b/contributed_definitions/nyaml/NXmpes_xps.yaml @@ -30,15 +30,6 @@ NXmpes_xps(NXmpes): exists: recommended doc: "Work function of the spectrometer." unit: NX_ENERGY - # These angles could also be described by NXtransformations on the analyzer and beam. - angle_beam_sample(NX_NUMBER): - exists: recommended - doc: "Orientation of the beam with respect to the sample normal." - units: NX_ANGLE - angle_beam_analyser(NX_NUMBER): - exists: recommended - doc: "Orientation of the beam with respect to the central axis of the analyzer." - units: NX_ANGLE (NXsource): type(NX_CHAR): enumeration: [ @@ -104,6 +95,12 @@ NXmpes_xps(NXmpes): "laser", "halogen lamp", ] + depends_on(NX_CHAR): + exists: recommended + doc: "Reference to the transformation describing the orientation of the analyzer relative to the beam." + (NXtransformations): + exists: recommended + doc: "Set of transformations, describing the relative orientation of the analyzer with respect to the beam coordinate system." (NXprocess): energy_calibration(NXcalibration): exists: optional @@ -148,7 +145,13 @@ NXmpes_xps(NXmpes): doc: "In the case of a fixed pressure measurement this is the scalar pressure. In the case of an experiment in which pressure changes, or anyway it is recorded, this is an array of length m of pressures." gas_phase(NX_CHAR): exists: optional - doc: "Description of the constituent gases of the gas phase." + doc: "Description of the constituent gases of the gas phase." + depends_on(NX_CHAR): + exists: recommended + doc: "Reference to a transformation describing the orientation of the sample relative to the beam coordinate system." + (NXtransformations): + exists: recommended + doc: "Set of transformations, describing the relative orientation of the sample with respect to the beam coordinate system." (NXdata): \@axes(NX_CHAR): doc: "It should contain at least one axis called 'energy'." From 53fca26bc31d65e1aa75cf423d3940f18cfc4fd8 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 9 May 2023 14:24:20 +0200 Subject: [PATCH 0849/1012] Update transmission function information - The transmission function contains an additional NXnote field "file" describing the file in which the TF data is stored. --- contributed_definitions/nyaml/NXmpes_xps.yaml | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/nyaml/NXmpes_xps.yaml b/contributed_definitions/nyaml/NXmpes_xps.yaml index df68169d40..4957dc868a 100644 --- a/contributed_definitions/nyaml/NXmpes_xps.yaml +++ b/contributed_definitions/nyaml/NXmpes_xps.yaml @@ -55,7 +55,13 @@ NXmpes_xps(NXmpes): ] transmission_function(NX_FLOAT): exists: recommended - doc: "Transmission function in dependance of the electron kinetic energy. To be used in intensity calibration." + doc: "Transmission function of the electron collection column. + This should be a link to /entry/process/intensity_calibration/tranmission_function." + units: NX_ANY + file(NXnote): + exists: recommended + doc: "File containing the transmission function data of the electron collection column. + This should be a link to /entry/instrument/collectioncolumn/transmission_function/file." (NXenergydispersion): scheme(NX_CHAR): enumeration: @@ -113,7 +119,12 @@ NXmpes_xps(NXmpes): doc: "Has an intensity calibration been applied? That is, has the transmission function of the analyzer been taken into account?" transmission_function(NX_FLOAT): exists: recommended - doc: "Transmission function of the electron collection column. This should be a link to /entry/instrument/collectioncolumn/tranmission_function." + doc: "Transmission function of the electron collection column. + This should be a link to /entry/instrument/collectioncolumn/transmission_function." + units: NX_ANY + file(NXnote): + exists: recommended + doc: "File containing the transmission function data. energy_reference(NXcalibration): exists: optional applied(NX_BOOLEAN): From 75a71e4259085639989dad5b5856236dfb4d9f28 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 9 May 2023 14:32:44 +0200 Subject: [PATCH 0850/1012] Update documentation, add comments for discussion --- contributed_definitions/nyaml/NXmpes_xps.yaml | 44 ++++++++++--------- 1 file changed, 24 insertions(+), 20 deletions(-) diff --git a/contributed_definitions/nyaml/NXmpes_xps.yaml b/contributed_definitions/nyaml/NXmpes_xps.yaml index 4957dc868a..78d5466861 100644 --- a/contributed_definitions/nyaml/NXmpes_xps.yaml +++ b/contributed_definitions/nyaml/NXmpes_xps.yaml @@ -60,7 +60,7 @@ NXmpes_xps(NXmpes): units: NX_ANY file(NXnote): exists: recommended - doc: "File containing the transmission function data of the electron collection column. + doc: "Name of the file containing the transmission function data of the electron collection column. This should be a link to /entry/instrument/collectioncolumn/transmission_function/file." (NXenergydispersion): scheme(NX_CHAR): @@ -84,18 +84,19 @@ NXmpes_xps(NXmpes): "detector voltage scan", "constant final state", "constant initial state", - ] + ] + # Not strictly neccessary to have. iris(NXaperture): exists: optional analyzer_radius(NX_FLOAT): exists: optional - description: "The radius of the hemispherical analyzer in mm (only if hemispherical analyzer is used." + description: "The radius of the hemispherical analyzer in mm (only if hemispherical analyzer is used)." unit: NX_LENGTH (NXmanipulator): heater_type(NX_CHAR): exists: optional doc: "Method of heating the sample. Can be e.g. electron beam heating, laser, halogen lamp." - # Could potentially add some more options here. + # Could add some more options here. enumeration: [ "electron beam heating", "laser", @@ -116,7 +117,8 @@ NXmpes_xps(NXmpes): intensity_calibration(NXcalibration): exists: optional applied(NX_BOOLEAN): - doc: "Has an intensity calibration been applied? That is, has the transmission function of the analyzer been taken into account?" + doc: "Has an intensity calibration been applied? + That is, has the transmission function of the analyzer been taken into account?" transmission_function(NX_FLOAT): exists: recommended doc: "Transmission function of the electron collection column. @@ -124,7 +126,7 @@ NXmpes_xps(NXmpes): units: NX_ANY file(NXnote): exists: recommended - doc: "File containing the transmission function data. + doc: "Name of the file containing the transmission function data." energy_reference(NXcalibration): exists: optional applied(NX_BOOLEAN): @@ -137,14 +139,17 @@ NXmpes_xps(NXmpes): doc: "Offset between measured binding energy and calibrated binding energy of the emission line." binding_energy(NX_FLOAT): exists: recommended - doc: "The binding energy that the specified emission line appeared at, after adjusting the binding energy scale, in units of eV" + doc: "The binding energy that the specified emission line appeared at, + after adjusting the binding energy scale, in units of eV" calibrated_axis(NX_FLOAT): exists: recommended - doc: "This is the calibrated energy axis to be used for data plotting. This should be a link to /entry/data/energy." + doc: "This is the calibrated energy axis to be used for data plotting. + This should be a link to /entry/data/energy." (NXsample): form(NX_CHAR): exists: optional enumeration: + # There should be more options here. [ "foil", "single crystal", @@ -153,7 +158,10 @@ NXmpes_xps(NXmpes): ] gas_pressure(NX_FLOAT): unit: NX_PRESSURE - doc: "In the case of a fixed pressure measurement this is the scalar pressure. In the case of an experiment in which pressure changes, or anyway it is recorded, this is an array of length m of pressures." + doc: | + In the case of a fixed pressure measurement this is the scalar pressure. + In the case of an experiment in which pressure changes, or anyway it is recorded, + this is an array of length m of pressures. gas_phase(NX_CHAR): exists: optional doc: "Description of the constituent gases of the gas phase." @@ -165,11 +173,15 @@ NXmpes_xps(NXmpes): doc: "Set of transformations, describing the relative orientation of the sample with respect to the beam coordinate system." (NXdata): \@axes(NX_CHAR): - doc: "It should contain at least one axis called 'energy'." + doc: "The data should contain at least one axis called 'energy'." energy(NX_NUMBER): + doc: | + The calibrated energy axis can be either in binding or kinetic energy. + This should be a link to either + /entry/process/energy calibration/calibrated_axis or + /entry/process/energy_reference/calibrated_axis. \@type(NX_CHAR): exists: recommended - doc: "The calibrated energy axis can be either in binding or kinetic energy. " enumeration: [ "kinetic", @@ -177,12 +189,4 @@ NXmpes_xps(NXmpes): ] \@step_size(NX_FLOAT): exists: optional - doc: "The step size between two consecutive energy values if the energy axis is evenly spaced." - data(NX_NUMBER): - doc: "Processed plottable data. Represents a measure of one- or more-dimensional photoemission counts, where - the varied axis may be for example energy, spatial coordinate, pump-probe delay, temperature, etc. - The axes traces should be linked to the actual encoder position in NXinstrument or calibrated axes in NXprocess." - \@units(NX_ANY): - exists: recommended - \@long_name(NX_CHAR): - exists: optional \ No newline at end of file + doc: "The step size between two consecutive energy values if the energy axis is evenly spaced." \ No newline at end of file From 11ff4da87a98ee8edf79588c5e0411cfe41293b2 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 25 Apr 2023 08:44:52 +0200 Subject: [PATCH 0851/1012] Initial draft of NXmpes_xps sub app-def --- contributed_definitions/nyaml/NXmpes_xps.yaml | 192 ------------------ 1 file changed, 192 deletions(-) delete mode 100644 contributed_definitions/nyaml/NXmpes_xps.yaml diff --git a/contributed_definitions/nyaml/NXmpes_xps.yaml b/contributed_definitions/nyaml/NXmpes_xps.yaml deleted file mode 100644 index 78d5466861..0000000000 --- a/contributed_definitions/nyaml/NXmpes_xps.yaml +++ /dev/null @@ -1,192 +0,0 @@ -#lukas.pielsticker at cec.mpg.de, 04/2023 -#Draft version of a NeXus application definition for XPS. - -doc: This is the application definition for X-ray photoelectron spectroscopy. -category: application -NXmpes_xps(NXmpes): - (NXentry): - end_time(NX_DATE_TIME): - exists: recommended - definition(NX_CHAR): - enumeration: ["NXmpes_xps"] - (NXinstrument): - energy_resolution(NX_FLOAT): - exists: recommended # cannot be required. measured value (typically from Ag 3d5/2 FWHM of sputter-cleaned Ag foil), not known every time and cann update over time (detector degradation). - unit: NX_ENERGY - manufacturer(NXfabrication): # Should go to NXmpes at some point. - exists: recommended - vendor: - exists: recommended - enumeration: [ - "SPECS GmbH", - "Kratos", - "Physical Electronics", - "Scienta", - "Thermo Fischer Scientific", - ] - model: - exists: recommended - work_function(NX_FLOAT): - exists: recommended - doc: "Work function of the spectrometer." - unit: NX_ENERGY - (NXsource): - type(NX_CHAR): - enumeration: [ - "Synchrotron X-ray Source", - "Rotating Anode X-ray", - "Fixed Tube X-ray", - "UV Laser", - "Free-Electron Laser", - "UV Plasma Source", - "Metal Jet X-ray", - ] - probe(NX_CHAR): - doc: "Type of probe. In XPS it's always X-ray photons (or UV light in UPS), so the full NIAC list is restricted." - enumeration: ["x-ray", "ultraviolet"] - (NXelectronanalyser): - (NXcollectioncolumn): - scheme(NX_CHAR): - enumeration: [ - "Standard", - "Angular dispersive", - "Selective area", - "Deflector", - ] - transmission_function(NX_FLOAT): - exists: recommended - doc: "Transmission function of the electron collection column. - This should be a link to /entry/process/intensity_calibration/tranmission_function." - units: NX_ANY - file(NXnote): - exists: recommended - doc: "Name of the file containing the transmission function data of the electron collection column. - This should be a link to /entry/instrument/collectioncolumn/transmission_function/file." - (NXenergydispersion): - scheme(NX_CHAR): - enumeration: - [ - "hemispherical", - "double hemispherical", - "cylindrical mirror", - "display mirror", - "retarding grid", - ] - energy_scan_mode(NX_CHAR): - doc: "Way of scanning the energy axis." - # Could potentially add some more options here. - enumeration: [ - "fixed analyzer transmission", - "fixed retarding ratio", - "fixed energies", - "snapshot", - "imaging", - "detector voltage scan", - "constant final state", - "constant initial state", - ] - # Not strictly neccessary to have. - iris(NXaperture): - exists: optional - analyzer_radius(NX_FLOAT): - exists: optional - description: "The radius of the hemispherical analyzer in mm (only if hemispherical analyzer is used)." - unit: NX_LENGTH - (NXmanipulator): - heater_type(NX_CHAR): - exists: optional - doc: "Method of heating the sample. Can be e.g. electron beam heating, laser, halogen lamp." - # Could add some more options here. - enumeration: [ - "electron beam heating", - "laser", - "halogen lamp", - ] - depends_on(NX_CHAR): - exists: recommended - doc: "Reference to the transformation describing the orientation of the analyzer relative to the beam." - (NXtransformations): - exists: recommended - doc: "Set of transformations, describing the relative orientation of the analyzer with respect to the beam coordinate system." - (NXprocess): - energy_calibration(NXcalibration): - exists: optional - calibration_file(NXnote): - exists: optional - doc: "Name of the calibration file containing the calibration data." - intensity_calibration(NXcalibration): - exists: optional - applied(NX_BOOLEAN): - doc: "Has an intensity calibration been applied? - That is, has the transmission function of the analyzer been taken into account?" - transmission_function(NX_FLOAT): - exists: recommended - doc: "Transmission function of the electron collection column. - This should be a link to /entry/instrument/collectioncolumn/transmission_function." - units: NX_ANY - file(NXnote): - exists: recommended - doc: "Name of the file containing the transmission function data." - energy_reference(NXcalibration): - exists: optional - applied(NX_BOOLEAN): - doc: "Have the energy axes been adjusted (e.g., in cases where samples are not conductive)?" - emission_line(NX_CHAR): - exists: recommended - doc: "Emission line which was used for the calibration." - offset(NX_FLOAT): - exists: recommended - doc: "Offset between measured binding energy and calibrated binding energy of the emission line." - binding_energy(NX_FLOAT): - exists: recommended - doc: "The binding energy that the specified emission line appeared at, - after adjusting the binding energy scale, in units of eV" - calibrated_axis(NX_FLOAT): - exists: recommended - doc: "This is the calibrated energy axis to be used for data plotting. - This should be a link to /entry/data/energy." - (NXsample): - form(NX_CHAR): - exists: optional - enumeration: - # There should be more options here. - [ - "foil", - "single crystal", - "pellet", - "powder", - ] - gas_pressure(NX_FLOAT): - unit: NX_PRESSURE - doc: | - In the case of a fixed pressure measurement this is the scalar pressure. - In the case of an experiment in which pressure changes, or anyway it is recorded, - this is an array of length m of pressures. - gas_phase(NX_CHAR): - exists: optional - doc: "Description of the constituent gases of the gas phase." - depends_on(NX_CHAR): - exists: recommended - doc: "Reference to a transformation describing the orientation of the sample relative to the beam coordinate system." - (NXtransformations): - exists: recommended - doc: "Set of transformations, describing the relative orientation of the sample with respect to the beam coordinate system." - (NXdata): - \@axes(NX_CHAR): - doc: "The data should contain at least one axis called 'energy'." - energy(NX_NUMBER): - doc: | - The calibrated energy axis can be either in binding or kinetic energy. - This should be a link to either - /entry/process/energy calibration/calibrated_axis or - /entry/process/energy_reference/calibrated_axis. - \@type(NX_CHAR): - exists: recommended - enumeration: - [ - "kinetic", - "binding" - ] - \@step_size(NX_FLOAT): - exists: optional - doc: "The step size between two consecutive energy values if the energy axis is evenly spaced." \ No newline at end of file From 5cd71d7908ff8d3ae346428d506bdc904ac1257b Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 4 May 2023 13:50:23 +0200 Subject: [PATCH 0852/1012] Prepare NXmpes_xps for extending NXmpes --- contributed_definitions/nyaml/NXmpes_xps.yaml | 435 ++++++++++++++++++ 1 file changed, 435 insertions(+) create mode 100644 contributed_definitions/nyaml/NXmpes_xps.yaml diff --git a/contributed_definitions/nyaml/NXmpes_xps.yaml b/contributed_definitions/nyaml/NXmpes_xps.yaml new file mode 100644 index 0000000000..e0d17ff779 --- /dev/null +++ b/contributed_definitions/nyaml/NXmpes_xps.yaml @@ -0,0 +1,435 @@ +#lukas.pielsticker at cec.mpg.de, 04/2023 +#Draft version of a NeXus application definition for XPS. + +doc: This is the application definition for X-ray photoelectron spectroscopy. +category: application +NXmpes_xps(NXmpes): + (NXentry): + end_time(NX_DATE_TIME): + exists: recommended + doc: "Datetime of the end of the measurement." + definition(NX_CHAR): + \@version(NX_CHAR): + enumeration: ["NXmpes_xps"] + # (NXuser): #### nothing changed, can be removed from here? + # doc: "Contact information of at least the user of the instrument or the + # investigator who performed this experiment. + # Adding multiple users if relevant is recommended." + # name(NX_CHAR): + # exists: recommended + # doc: "Name of the user." + # affiliation(NX_CHAR): + # exists: recommended + # doc: "Name of the affiliation of the user at the point in time when the + # experiment was performed." + # address(NX_CHAR): + # exists: recommended + # doc: "Full address (street, street number, ZIP, city, country) of the + # user's affiliation." + # email(NX_CHAR): + # doc: "Email address of the user." + # orcid(NX_CHAR): + # exists: recommended + # doc: "Author ID defined by https://orcid.org/." + (NXinstrument): + energy_resolution(NX_FLOAT): + exists: recommended ###### cannot be required. measured value (typically from Ag 3d5/2 FWHM of sputter-cleaned Ag foil), not known every time and cann update over time (detector degradation). + unit: NX_ENERGY + manufacturer(NX_CHAR): + exists: recommended + doc: "The name of the company that manufactured the spectrometer." + enumeration: [ + "SPECS GmbH", + "Kratos", + "Physical Electronics", + "Scienta", + "Thermo Fischer Scientific", + ] + (NXsource): + type(NX_CHAR): + enumeration: [ ### removed some options from NXmpes + "Synchrotron X-ray Source", + "Rotating Anode X-ray", + "Fixed Tube X-ray", + "UV Laser", + "Free-Electron Laser", + "UV Plasma Source", + "Metal Jet X-ray", + ] + probe(NX_CHAR): + doc: "Type of probe. In XPS it's always X-ray photons (or UV light in UPS), so the full NIAC list is restricted." + enumeration: ["x-ray", "ultraviolet"] + (NXmonochromator): + exists: optional + applied(NX_BOOLEAN): + doc: "Has the incident beam been monochromatized? " + type(NX_CHAR): + enumeration: [ + "Crystal", + "Grating", + ] + crystal(NXcrystal): + exists: optional + doc: "For crystal based monochromators. Use as many crystals as necessary." + grating(NXgrating): + exists: optional + doc: "For diffraction grating based monochromators. Use as many crystals as necessary." + energy(NX_FLOAT): + doc: "The scalar energy of the monchromatic beam. This should link to /entry/instrument/beam/incident_energy." ######how to do links? + unit: NX_ENERGY + energy_error(NX_FLOAT): + doc: "The energy spread FWHM for the corresponding energy in energy. This should link to /entry/instrument/beam/incident_energy_spread." + unit: NX_ENERGY + transformations(NXtransformations) ###### should we describe the beam rotation by the mono? + exists: optional + (NXbeam): + distance(NX_NUMBER): + exists: recommended ### cannot be required, hard to know??? + doc: "Distance of the point of evaluation of the beam from the sample surface." + unit: NX_LENGTH + incident_energy(NX_FLOAT): + unit: NX_ENERGY + doc: "In the case of a monchromatic 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." + incident_energy_spread(NX_NUMBER): + exists: recommended + unit: NX_ENERGY + doc: "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 energy in incident_energy." + #incident_polarization(NX_NUMBER): + # exists: recommended + # doc: "Incident polarization specified as a Stokes vector." + # \@units(NX_CHAR): + # doc: "The units for this observable are not included in the NIAC list. Responsibility on correct formatting and parsing is handed to the user by using ‘NX_ANY’. Correct parsing can still be implemented by using this attribute. Fill with: The unit unidata symbol if the unit has one (Example: ‘T’ for the unit of magnetic flux density tesla). The unit unidata name if the unit has a name (Example: ‘farad’ for capacitance). A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and does not have a name. Example: for lightsource brilliance (SI) ‘1/(s.mm2.mrad2)’. Here: SI units are ‘V2/m2’." + (NXelectronanalyser): + description(NX_CHAR): + doc: "Free text description of the type of detector." + # fast_axes(NX_CHAR): ### how to use these? + # exists: optional + # doc: "List of the axes that are acquired symultaneously 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. Hemispherical in XPS mode: fast_axes: [energy] Hemispherical with channeltron, sweeping energy mode: slow_axes: [energy] axes can be less abstract than this, i.e. [detector_x, detector_y]." + # slow_axes(NX_CHAR): + # exists: optional + # doc: "List of the axes that are acquired by scanning a physical parameter, listed in order of decreasing speed. See fast_axes for examples." + (NXcollectioncolumn): + scheme(NX_CHAR): + doc: "Scheme of the electron collection column." + enumeration: [ ### removed some options from NXmpes + "Standard", + "Angular dispersive", + "Selective area", + "Deflector", + ] + mode(NX_CHAR): + exists: recommended + doc: "Labelling of the lens setting in use. Names are typically presets provided by the instrument vendor." + # projection(NX_CHAR): #### what does this mean? + # exists: recommended + tranmission_function(NX_FLOAT): + exists: recommended + doc: "Transmission function in dependance of the electron kinetic energy. To be used in intensity calibration." ### does NX_FLOAT make sense? + (NXenergydispersion): + scheme(NX_CHAR): + enumeration: ### removed some options from NXmpes + [ + "hemispherical", + "double hemispherical", + "cylindrical mirror", + "display mirror", + "retarding grid", + ] + pass_energy(NX_FLOAT): + doc: "Pass energy of energy dispersive element. Determines measurement resolution." + unit: NX_ENERGY + energy_scan_mode(NX_CHAR): + doc: "Way of scanning the energy axis." + enumeration: [ ### could potentially add some more here. + "fixed analyzer transmission", + "fixed retarding ratio", + "fixed energies", + "snapshot", + "imaging", + "detector voltage scan", + "constant final state", + "constant initial state", + ] + # entrance_slit(NXaperture): ### is this level of description necessary -> most items exist in NXaperture already + # exists: optional + # doc: "Size, position, and shape of the entrance slit in dispersive analyzers (aperture generating the energy filtering)." + # description(NX_CHAR): + # exists: optional + # doc: "Type of aperture inserted in the beam." + # enumeration: ["slit", "pinhole", "iris"] + # shape(NX_CHAR): + # exists: optional + # doc: "Description of the shape of the active part of the aperture, curved or straight for horizontal slits, square or round for pinhole etc." + # enumeration: + # [ + # "straight slit", + # "curved slit", + # "pinhole", + # "circle", + # "square", + # "hexagon", + # "octagon", + # "bladed", + # "open", + # "grid" + # ] + # size(NX_NUMBER): + # exists: optional + # doc: "The relevant dimension for the entrance_slit, i.e. slit width, pinhole and iris diameter." + # exit_slit(NXaperture): + # exists: optional + # doc: "Size, position and shape of the exit slit in dispersive analyzers." + # description(NX_CHAR): + # exists: optional + # doc: "Type of aperture inserted in the beam." + # enumeration: ["slit", "pinhole", "iris"] + # shape(NX_CHAR): + # exists: optional + # doc: "Description of the shape of the active part of the aperture, curved or straight for horizontal slits, square or round for pinhole etc." + # enumeration: + # [ + # "straight slit", + # "curved slit", + # "pinhole", + # "circle", + # "square", + # "hexagon", + # "octagon", + # "bladed", + # "open", + # "grid" + # ] + # size(NX_NUMBER): + # exists: optional + # doc: "The relevant dimension for the entrance_slit, i.e. slit width, pinhole and iris diameter." + # iris(NXaperture): + # exists: optional + # doc: "Size, position, and shape of the iris in dispersive analyzers." + # description(NX_CHAR): + # exists: optional + # doc: "Type of aperture inserted in the beam." + # enumeration: ["slit", "pinhole", "iris"] + # shape(NX_CHAR): + # exists: optional + # doc: "Description of the shape of the active part of the aperture, curved or straight for horizontal slits, square or round for pinhole etc." + # enumeration: + # [ + # "straight slit", + # "curved slit", + # "pinhole", + # "circle", + # "square", + # "hexagon", + # "octagon", + # "bladed", + # "open", + # "grid" + # ] + # size(NX_NUMBER): + # exists: optional + # doc: "The relevant dimension for the entrance_slit, i.e. slit width, pinhole and iris diameter." + analyzer_radius(NX_FLOAT): + exists: optional + description: The radius of the hemispherical analyzer in mm (only if hemispherical analyzer is used.) + (NXdetector): + # amplifier:type(NX_CHAR): + # exists: recommended + # doc: "Description of the detector type." + # enumeration: + # ["MCP", "channeltron"] + # detector_type(NX_CHAR): + # exists: recommended + # doc: "Description of the detector type." + # enumeration: + # [ + # "DLD", + # "Phosphor+CCD", + # "Phosphor+CMOS", + # "ECMOS", + # "Anode", + # "Multi-anode" + # ] + # (NXdata): # Raw signal without calibrated axes. + # exists: recommended + # \@signal: + # enumeration: ['raw'] + # raw(NX_NUMBER): # There is a block of numbers named raw. + # doc: "Raw data before calibration." + GEOMETRY(NXtransformations): ### took this from NXmpes_liqudidjet, how to describe geometry? on indicidual classes? would like to describe angles between different instrument parts here? + exists: optional + doc: "Transformations describing the transformation chain of all relevant vectors in the experiment." + gravity_axis(NX_NUMBER): + doc: "Direction of gravity." + \@vector(NX_NUMBER): + doc: "The vector in the direction of gravity." + \@depends_on(NX_CHAR): + doc: "Set to '.' to specify the normal vector to which all other vectors are related." + beam_axis(NX_NUMBER): + doc: "Direction of the photon beam." + \@vector(NX_NUMBER): + doc: "The vector of the photon-beam direction into the chamber after the last optical element (or directly from the source if there are no optical elements)." + \@depends_on(NX_CHAR): + doc: "This should be a link to /entry/instrument/geometry/gravity_axis." + analyzer_lens_axis(NX_NUMBER): + doc: "Direction of lens axis of analyzer." + \@vector(NX_NUMBER): + doc: "The vector pointing along the central axis of the analyzer lens system in from the sample." + \@depends_on(NX_CHAR): + doc: "This should be a link to /entry/instrument/geometry/beam_axis." + hemisphere_orientation(NX_NUMBER): + exists: optional + doc: "Orientation of the hemisphere with respect to the lens system in case of a hemispherical electron analyzer." + \@vector(NX_NUMBER): + doc: "The vector pointing towards the detector from the entrance slit of the hemisphere, and should be perpendicular to the analyzer lens system." + \@depends_on(NX_CHAR): + doc: "This should be a link to /entry/instrument/geometry/analyzer_lens_axis." + (NXmanipulator): + # exists: optional + # doc: "Manipulator for positioning of the sample." + # sample_temperature(NX_FLOAT): + # exists: recommended + # doc: "Sample temperature during the experiment. Can be a single float or an array for temperature-programmed XPS." + # unit: NX_TEMPERATURE + sample_heater(NX_CHAR): + exists: optional + doc: "Method of heating the sample. Can be e.g. electron beam heating, laser, halogen lamp" + # heater_power(NX_FLOAT): + # exists: optional + # doc: "Power in the heater for temperature control." + # sample_temperature(NX_FLOAT): + # exists: optional + # doc: "Temperature at the closest point to the sample. This field may also be found in NXsample if present." + # drain_current(NX_FLOAT): + # exists: recommended + # doc: "Measured drain current of the sample. This field may also be found in NXsample if present." + # unit: NX_CURRENT + # sample_bias(NX_FLOAT): + # exists: recommended + # doc: "Possible bias of the sample with respect to analyser ground. This field may also be found in NXsample if present." + # unit: NX_CURRENT + (NXprocess): + # doc: "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." + energy_calibration(NXcalibration): + # exists: recommended + # applied(NX_BOOLEAN): + # doc: "Has an energy calibration been applied?" + calibration_file(NX_CHAR): + exists: recommended + doc: "Name of the calibration file containing the calibration data." + # calibrated_axis(NX_FLOAT): + # exists: recommended + # doc: "This is the calibrated energy axis to be used for data plotting." + # spatial_calibration(NXcalibration): + # exists: optional + # applied(NX_BOOLEAN): + # doc: "Has a spatial calibration been applied?" + # calibrated_axis(NX_FLOAT): + # exists: recommended + # doc: "This is the calibrated spatial axis to be used for data plotting." + intensity_calibration(NXcalibration): + exists: recommended + applied(NX_BOOLEAN): + doc: "Has an intensity calibration been applied? That is, has the transmission function of the analyzer been taken into account?" + transmission_function(NX_FLOAT): + exists: recommended + doc: "Transmission function of the electron collection column. This should be a link to /entry/instrument/collectioncolumn/tranmission_function." + energy_reference(NXcalibration): + exists: recommended + applied(NX_BOOLEAN): + doc: "Have the energy axes been adjusted (e.g., in cases where samples are not conductive)?" + emission_line(NX_CHAR): + exists: recommended + doc: "Emission line which was used for the calibration." + offset(NXfloat): + exists: recommended + doc: "Offset between measured binding energy and calibrated binding energy of the emission line." + binding_energy(NX_float): + exists: recommended + doc: "The binding energy that the specified emission line appeared at, after adjusting the binding energy scale, in units of eV" + calibrated_axis(NX_FLOAT): + exists: recommended + doc: "This is the calibrated energy axis to be used for data plotting. This should be a link to /entry/data/energy." ######???? + (NXsample): + name(NX_CHAR): + doc: "The user-assigned name of the sample." + description(NX_CHAR): + exists: optional + doc: "Full description of the sample." + # chemical_formula: + # exists: recommended + # doc: "The chemical formula of the sample. For mixtures use the NXsample_component group in NXsample instead." + # atom_types: + # exists: recommended + # 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`." + form(NX_CHAR): + exists: optional + enumeration: + [ + "foil", + "single crystal", + "pellet", + "powder", + "calibration sample", + ] + # preparation_date(NX_DATE_TIME): + # exists: recommended + # doc: "Date of preparation of the sample for the XPS experiment (i.e. cleaving, last annealing)." + # temperature(NX_FLOAT): + # doc: "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." + # unit: NX_TEMPERATURE + situation(NX_CHAR): ### missing some enumerations here + enumeration: + [ + "vacuum", + "inert atmosphere", + "oxidising atmosphere", + "reducing atmosphere", + "other" + ] + gas_pressure(NX_FLOAT): ######## Can be a single number or a log. + unit: NX_PRESSURE + doc: "In the case of a fixed pressure measurement this is the scalar pressure. In the case of an experiment in which pressure changes, or anyway it is recorded, this is an array of length m of pressures." + # sample_history(NXnote): + # exists: recommended + # doc: "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." + # preparation_description(NXnote): + # doc: "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." + gas_phase(NX_CHAR): + exists: optional + doc: "Description of the constitutent gases of the gas phase." + electric_field(NX_FLOAT): + exists: optional + unit: NX_VOLTAGE + doc: "Electric field applied to the sample with respect to ground / the system, e.g., via biasing." + (NXdata): + # \@signal: + # enumeration: ["data"] + \@axes(NX_CHAR): + doc: "The energy axis. Can be either scanned or derived from scanning of other energy axis." + energy(NX_NUMBER): #### how to represent this here? + \@units(NX_CHAR): + exists: recommended + \@long_name(NX_CHAR): + exists: optional + type(NX_CHAR): + exists: recommended + doc: "The energy axis can be either in binding or kinetic energy." + enumeration: + [ + "kinetic", + "energy" + ] + step_size(NX_CHAR): + exists: optional + doc: "The step size between two consecutive energy values." + data(NX_NUMBER): # There is a block of numbers named data. + doc: "Processed plottable data. Represents a measure of one- or more-dimensional photoemission counts, where + the varied axis may be for example energy, spatial coordinate, pump-probe delay, temperature, etc. + The axes traces should be linked to the actual encoder position in NXinstrument or calibrated axes in NXprocess." + \@units(NX_ANY): + exists: recommended + \@long_name(NX_CHAR): + exists: optional \ No newline at end of file From 5b76d234855e49e6d7a86b65289344ad45ea2de7 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 4 May 2023 18:42:57 +0200 Subject: [PATCH 0853/1012] Removed information already given in base classes --- contributed_definitions/nyaml/NXmpes_xps.yaml | 358 +++--------------- 1 file changed, 43 insertions(+), 315 deletions(-) diff --git a/contributed_definitions/nyaml/NXmpes_xps.yaml b/contributed_definitions/nyaml/NXmpes_xps.yaml index e0d17ff779..e256f273f0 100644 --- a/contributed_definitions/nyaml/NXmpes_xps.yaml +++ b/contributed_definitions/nyaml/NXmpes_xps.yaml @@ -7,47 +7,32 @@ NXmpes_xps(NXmpes): (NXentry): end_time(NX_DATE_TIME): exists: recommended - doc: "Datetime of the end of the measurement." definition(NX_CHAR): - \@version(NX_CHAR): enumeration: ["NXmpes_xps"] - # (NXuser): #### nothing changed, can be removed from here? - # doc: "Contact information of at least the user of the instrument or the - # investigator who performed this experiment. - # Adding multiple users if relevant is recommended." - # name(NX_CHAR): - # exists: recommended - # doc: "Name of the user." - # affiliation(NX_CHAR): - # exists: recommended - # doc: "Name of the affiliation of the user at the point in time when the - # experiment was performed." - # address(NX_CHAR): - # exists: recommended - # doc: "Full address (street, street number, ZIP, city, country) of the - # user's affiliation." - # email(NX_CHAR): - # doc: "Email address of the user." - # orcid(NX_CHAR): - # exists: recommended - # doc: "Author ID defined by https://orcid.org/." (NXinstrument): energy_resolution(NX_FLOAT): exists: recommended ###### cannot be required. measured value (typically from Ag 3d5/2 FWHM of sputter-cleaned Ag foil), not known every time and cann update over time (detector degradation). unit: NX_ENERGY - manufacturer(NX_CHAR): + manufacturer(NXfabrication): #### should go to NXmpes at some point. exists: recommended - doc: "The name of the company that manufactured the spectrometer." - enumeration: [ + vendor: + exists: recommended + enumeration: [ "SPECS GmbH", "Kratos", "Physical Electronics", "Scienta", "Thermo Fischer Scientific", ] + model: + exists: recommended + work_function(NX_FLOAT): + exists: recommended ###### new + doc: "Work function of the spectrometer." + unit: NX_ENERGY (NXsource): type(NX_CHAR): - enumeration: [ ### removed some options from NXmpes + enumeration: [ "Synchrotron X-ray Source", "Rotating Anode X-ray", "Fixed Tube X-ray", @@ -59,75 +44,21 @@ NXmpes_xps(NXmpes): probe(NX_CHAR): doc: "Type of probe. In XPS it's always X-ray photons (or UV light in UPS), so the full NIAC list is restricted." enumeration: ["x-ray", "ultraviolet"] - (NXmonochromator): - exists: optional - applied(NX_BOOLEAN): - doc: "Has the incident beam been monochromatized? " - type(NX_CHAR): - enumeration: [ - "Crystal", - "Grating", - ] - crystal(NXcrystal): - exists: optional - doc: "For crystal based monochromators. Use as many crystals as necessary." - grating(NXgrating): - exists: optional - doc: "For diffraction grating based monochromators. Use as many crystals as necessary." - energy(NX_FLOAT): - doc: "The scalar energy of the monchromatic beam. This should link to /entry/instrument/beam/incident_energy." ######how to do links? - unit: NX_ENERGY - energy_error(NX_FLOAT): - doc: "The energy spread FWHM for the corresponding energy in energy. This should link to /entry/instrument/beam/incident_energy_spread." - unit: NX_ENERGY - transformations(NXtransformations) ###### should we describe the beam rotation by the mono? - exists: optional - (NXbeam): - distance(NX_NUMBER): - exists: recommended ### cannot be required, hard to know??? - doc: "Distance of the point of evaluation of the beam from the sample surface." - unit: NX_LENGTH - incident_energy(NX_FLOAT): - unit: NX_ENERGY - doc: "In the case of a monchromatic 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." - incident_energy_spread(NX_NUMBER): - exists: recommended - unit: NX_ENERGY - doc: "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 energy in incident_energy." - #incident_polarization(NX_NUMBER): - # exists: recommended - # doc: "Incident polarization specified as a Stokes vector." - # \@units(NX_CHAR): - # doc: "The units for this observable are not included in the NIAC list. Responsibility on correct formatting and parsing is handed to the user by using ‘NX_ANY’. Correct parsing can still be implemented by using this attribute. Fill with: The unit unidata symbol if the unit has one (Example: ‘T’ for the unit of magnetic flux density tesla). The unit unidata name if the unit has a name (Example: ‘farad’ for capacitance). A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and does not have a name. Example: for lightsource brilliance (SI) ‘1/(s.mm2.mrad2)’. Here: SI units are ‘V2/m2’." (NXelectronanalyser): - description(NX_CHAR): - doc: "Free text description of the type of detector." - # fast_axes(NX_CHAR): ### how to use these? - # exists: optional - # doc: "List of the axes that are acquired symultaneously 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. Hemispherical in XPS mode: fast_axes: [energy] Hemispherical with channeltron, sweeping energy mode: slow_axes: [energy] axes can be less abstract than this, i.e. [detector_x, detector_y]." - # slow_axes(NX_CHAR): - # exists: optional - # doc: "List of the axes that are acquired by scanning a physical parameter, listed in order of decreasing speed. See fast_axes for examples." (NXcollectioncolumn): scheme(NX_CHAR): - doc: "Scheme of the electron collection column." - enumeration: [ ### removed some options from NXmpes + enumeration: [ ### removed some options from NXmpes "Standard", "Angular dispersive", "Selective area", "Deflector", ] - mode(NX_CHAR): - exists: recommended - doc: "Labelling of the lens setting in use. Names are typically presets provided by the instrument vendor." - # projection(NX_CHAR): #### what does this mean? - # exists: recommended - tranmission_function(NX_FLOAT): + transmission_function(NX_FLOAT): exists: recommended doc: "Transmission function in dependance of the electron kinetic energy. To be used in intensity calibration." ### does NX_FLOAT make sense? (NXenergydispersion): scheme(NX_CHAR): - enumeration: ### removed some options from NXmpes + enumeration: ### removed some options from NXmpes [ "hemispherical", "double hemispherical", @@ -135,12 +66,9 @@ NXmpes_xps(NXmpes): "display mirror", "retarding grid", ] - pass_energy(NX_FLOAT): - doc: "Pass energy of energy dispersive element. Determines measurement resolution." - unit: NX_ENERGY energy_scan_mode(NX_CHAR): doc: "Way of scanning the energy axis." - enumeration: [ ### could potentially add some more here. + enumeration: [ ### could potentially add some more here. "fixed analyzer transmission", "fixed retarding ratio", "fixed energies", @@ -150,220 +78,51 @@ NXmpes_xps(NXmpes): "constant final state", "constant initial state", ] - # entrance_slit(NXaperture): ### is this level of description necessary -> most items exist in NXaperture already - # exists: optional - # doc: "Size, position, and shape of the entrance slit in dispersive analyzers (aperture generating the energy filtering)." - # description(NX_CHAR): - # exists: optional - # doc: "Type of aperture inserted in the beam." - # enumeration: ["slit", "pinhole", "iris"] - # shape(NX_CHAR): - # exists: optional - # doc: "Description of the shape of the active part of the aperture, curved or straight for horizontal slits, square or round for pinhole etc." - # enumeration: - # [ - # "straight slit", - # "curved slit", - # "pinhole", - # "circle", - # "square", - # "hexagon", - # "octagon", - # "bladed", - # "open", - # "grid" - # ] - # size(NX_NUMBER): - # exists: optional - # doc: "The relevant dimension for the entrance_slit, i.e. slit width, pinhole and iris diameter." - # exit_slit(NXaperture): - # exists: optional - # doc: "Size, position and shape of the exit slit in dispersive analyzers." - # description(NX_CHAR): - # exists: optional - # doc: "Type of aperture inserted in the beam." - # enumeration: ["slit", "pinhole", "iris"] - # shape(NX_CHAR): - # exists: optional - # doc: "Description of the shape of the active part of the aperture, curved or straight for horizontal slits, square or round for pinhole etc." - # enumeration: - # [ - # "straight slit", - # "curved slit", - # "pinhole", - # "circle", - # "square", - # "hexagon", - # "octagon", - # "bladed", - # "open", - # "grid" - # ] - # size(NX_NUMBER): - # exists: optional - # doc: "The relevant dimension for the entrance_slit, i.e. slit width, pinhole and iris diameter." - # iris(NXaperture): - # exists: optional - # doc: "Size, position, and shape of the iris in dispersive analyzers." - # description(NX_CHAR): - # exists: optional - # doc: "Type of aperture inserted in the beam." - # enumeration: ["slit", "pinhole", "iris"] - # shape(NX_CHAR): - # exists: optional - # doc: "Description of the shape of the active part of the aperture, curved or straight for horizontal slits, square or round for pinhole etc." - # enumeration: - # [ - # "straight slit", - # "curved slit", - # "pinhole", - # "circle", - # "square", - # "hexagon", - # "octagon", - # "bladed", - # "open", - # "grid" - # ] - # size(NX_NUMBER): - # exists: optional - # doc: "The relevant dimension for the entrance_slit, i.e. slit width, pinhole and iris diameter." + iris(NXaperture): + exists: optional analyzer_radius(NX_FLOAT): exists: optional description: The radius of the hemispherical analyzer in mm (only if hemispherical analyzer is used.) - (NXdetector): - # amplifier:type(NX_CHAR): - # exists: recommended - # doc: "Description of the detector type." - # enumeration: - # ["MCP", "channeltron"] - # detector_type(NX_CHAR): - # exists: recommended - # doc: "Description of the detector type." - # enumeration: - # [ - # "DLD", - # "Phosphor+CCD", - # "Phosphor+CMOS", - # "ECMOS", - # "Anode", - # "Multi-anode" - # ] - # (NXdata): # Raw signal without calibrated axes. - # exists: recommended - # \@signal: - # enumeration: ['raw'] - # raw(NX_NUMBER): # There is a block of numbers named raw. - # doc: "Raw data before calibration." - GEOMETRY(NXtransformations): ### took this from NXmpes_liqudidjet, how to describe geometry? on indicidual classes? would like to describe angles between different instrument parts here? - exists: optional - doc: "Transformations describing the transformation chain of all relevant vectors in the experiment." - gravity_axis(NX_NUMBER): - doc: "Direction of gravity." - \@vector(NX_NUMBER): - doc: "The vector in the direction of gravity." - \@depends_on(NX_CHAR): - doc: "Set to '.' to specify the normal vector to which all other vectors are related." - beam_axis(NX_NUMBER): - doc: "Direction of the photon beam." - \@vector(NX_NUMBER): - doc: "The vector of the photon-beam direction into the chamber after the last optical element (or directly from the source if there are no optical elements)." - \@depends_on(NX_CHAR): - doc: "This should be a link to /entry/instrument/geometry/gravity_axis." - analyzer_lens_axis(NX_NUMBER): - doc: "Direction of lens axis of analyzer." - \@vector(NX_NUMBER): - doc: "The vector pointing along the central axis of the analyzer lens system in from the sample." - \@depends_on(NX_CHAR): - doc: "This should be a link to /entry/instrument/geometry/beam_axis." - hemisphere_orientation(NX_NUMBER): - exists: optional - doc: "Orientation of the hemisphere with respect to the lens system in case of a hemispherical electron analyzer." - \@vector(NX_NUMBER): - doc: "The vector pointing towards the detector from the entrance slit of the hemisphere, and should be perpendicular to the analyzer lens system." - \@depends_on(NX_CHAR): - doc: "This should be a link to /entry/instrument/geometry/analyzer_lens_axis." + unit: NX_LENGTH (NXmanipulator): - # exists: optional - # doc: "Manipulator for positioning of the sample." - # sample_temperature(NX_FLOAT): - # exists: recommended - # doc: "Sample temperature during the experiment. Can be a single float or an array for temperature-programmed XPS." - # unit: NX_TEMPERATURE - sample_heater(NX_CHAR): + heater_type(NX_CHAR): exists: optional - doc: "Method of heating the sample. Can be e.g. electron beam heating, laser, halogen lamp" - # heater_power(NX_FLOAT): - # exists: optional - # doc: "Power in the heater for temperature control." - # sample_temperature(NX_FLOAT): - # exists: optional - # doc: "Temperature at the closest point to the sample. This field may also be found in NXsample if present." - # drain_current(NX_FLOAT): - # exists: recommended - # doc: "Measured drain current of the sample. This field may also be found in NXsample if present." - # unit: NX_CURRENT - # sample_bias(NX_FLOAT): - # exists: recommended - # doc: "Possible bias of the sample with respect to analyser ground. This field may also be found in NXsample if present." - # unit: NX_CURRENT + doc: "Method of heating the sample. Can be e.g. electron beam heating, laser, halogen lamp." + enumeration: [ ### could potentially add some more here. + "electron beam heating", + "laser", + "halogen lamp", + ] (NXprocess): - # doc: "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." energy_calibration(NXcalibration): - # exists: recommended - # applied(NX_BOOLEAN): - # doc: "Has an energy calibration been applied?" - calibration_file(NX_CHAR): - exists: recommended - doc: "Name of the calibration file containing the calibration data." - # calibrated_axis(NX_FLOAT): - # exists: recommended - # doc: "This is the calibrated energy axis to be used for data plotting." - # spatial_calibration(NXcalibration): - # exists: optional - # applied(NX_BOOLEAN): - # doc: "Has a spatial calibration been applied?" - # calibrated_axis(NX_FLOAT): - # exists: recommended - # doc: "This is the calibrated spatial axis to be used for data plotting." + exists: optional + calibration_file(NXnote): + exists: optional + doc: "Name of the calibration file containing the calibration data." intensity_calibration(NXcalibration): - exists: recommended + exists: optional applied(NX_BOOLEAN): doc: "Has an intensity calibration been applied? That is, has the transmission function of the analyzer been taken into account?" transmission_function(NX_FLOAT): exists: recommended doc: "Transmission function of the electron collection column. This should be a link to /entry/instrument/collectioncolumn/tranmission_function." energy_reference(NXcalibration): - exists: recommended + exists: optional applied(NX_BOOLEAN): doc: "Have the energy axes been adjusted (e.g., in cases where samples are not conductive)?" emission_line(NX_CHAR): exists: recommended doc: "Emission line which was used for the calibration." - offset(NXfloat): + offset(NX_FLOAT): exists: recommended doc: "Offset between measured binding energy and calibrated binding energy of the emission line." - binding_energy(NX_float): + binding_energy(NX_FLOAT): exists: recommended doc: "The binding energy that the specified emission line appeared at, after adjusting the binding energy scale, in units of eV" calibrated_axis(NX_FLOAT): exists: recommended doc: "This is the calibrated energy axis to be used for data plotting. This should be a link to /entry/data/energy." ######???? - (NXsample): - name(NX_CHAR): - doc: "The user-assigned name of the sample." - description(NX_CHAR): - exists: optional - doc: "Full description of the sample." - # chemical_formula: - # exists: recommended - # doc: "The chemical formula of the sample. For mixtures use the NXsample_component group in NXsample instead." - # atom_types: - # exists: recommended - # 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`." + (NXsample): form(NX_CHAR): exists: optional enumeration: @@ -372,59 +131,28 @@ NXmpes_xps(NXmpes): "single crystal", "pellet", "powder", - "calibration sample", ] - # preparation_date(NX_DATE_TIME): - # exists: recommended - # doc: "Date of preparation of the sample for the XPS experiment (i.e. cleaving, last annealing)." - # temperature(NX_FLOAT): - # doc: "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." - # unit: NX_TEMPERATURE - situation(NX_CHAR): ### missing some enumerations here - enumeration: - [ - "vacuum", - "inert atmosphere", - "oxidising atmosphere", - "reducing atmosphere", - "other" - ] gas_pressure(NX_FLOAT): ######## Can be a single number or a log. unit: NX_PRESSURE doc: "In the case of a fixed pressure measurement this is the scalar pressure. In the case of an experiment in which pressure changes, or anyway it is recorded, this is an array of length m of pressures." - # sample_history(NXnote): - # exists: recommended - # doc: "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." - # preparation_description(NXnote): - # doc: "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." gas_phase(NX_CHAR): exists: optional - doc: "Description of the constitutent gases of the gas phase." - electric_field(NX_FLOAT): - exists: optional - unit: NX_VOLTAGE - doc: "Electric field applied to the sample with respect to ground / the system, e.g., via biasing." + doc: "Description of the constituent gases of the gas phase." (NXdata): - # \@signal: - # enumeration: ["data"] \@axes(NX_CHAR): - doc: "The energy axis. Can be either scanned or derived from scanning of other energy axis." - energy(NX_NUMBER): #### how to represent this here? - \@units(NX_CHAR): - exists: recommended - \@long_name(NX_CHAR): - exists: optional - type(NX_CHAR): + doc: "It should contain at least one axis called 'energy'." + energy(NX_NUMBER): #### how to represent this here? + \@type(NX_CHAR): exists: recommended - doc: "The energy axis can be either in binding or kinetic energy." + doc: "The calibrated energy axis can be either in binding or kinetic energy. " enumeration: [ "kinetic", - "energy" - ] - step_size(NX_CHAR): + "binding" + ] + \@step_size(NX_FLOAT): exists: optional - doc: "The step size between two consecutive energy values." + doc: "The step size between two consecutive energy values if the energy axis is evenly spaced." data(NX_NUMBER): # There is a block of numbers named data. doc: "Processed plottable data. Represents a measure of one- or more-dimensional photoemission counts, where the varied axis may be for example energy, spatial coordinate, pump-probe delay, temperature, etc. From 27bf92706b677651002e314a7ed51c27432e037d Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 5 May 2023 09:27:34 +0200 Subject: [PATCH 0854/1012] Removed some unneeded comments --- contributed_definitions/nyaml/NXmpes_xps.yaml | 26 ++++++++++--------- 1 file changed, 14 insertions(+), 12 deletions(-) diff --git a/contributed_definitions/nyaml/NXmpes_xps.yaml b/contributed_definitions/nyaml/NXmpes_xps.yaml index e256f273f0..2852868e97 100644 --- a/contributed_definitions/nyaml/NXmpes_xps.yaml +++ b/contributed_definitions/nyaml/NXmpes_xps.yaml @@ -11,9 +11,9 @@ NXmpes_xps(NXmpes): enumeration: ["NXmpes_xps"] (NXinstrument): energy_resolution(NX_FLOAT): - exists: recommended ###### cannot be required. measured value (typically from Ag 3d5/2 FWHM of sputter-cleaned Ag foil), not known every time and cann update over time (detector degradation). + exists: recommended # cannot be required. measured value (typically from Ag 3d5/2 FWHM of sputter-cleaned Ag foil), not known every time and cann update over time (detector degradation). unit: NX_ENERGY - manufacturer(NXfabrication): #### should go to NXmpes at some point. + manufacturer(NXfabrication): # Should go to NXmpes at some point. exists: recommended vendor: exists: recommended @@ -27,7 +27,7 @@ NXmpes_xps(NXmpes): model: exists: recommended work_function(NX_FLOAT): - exists: recommended ###### new + exists: recommended doc: "Work function of the spectrometer." unit: NX_ENERGY (NXsource): @@ -47,7 +47,7 @@ NXmpes_xps(NXmpes): (NXelectronanalyser): (NXcollectioncolumn): scheme(NX_CHAR): - enumeration: [ ### removed some options from NXmpes + enumeration: [ "Standard", "Angular dispersive", "Selective area", @@ -55,10 +55,10 @@ NXmpes_xps(NXmpes): ] transmission_function(NX_FLOAT): exists: recommended - doc: "Transmission function in dependance of the electron kinetic energy. To be used in intensity calibration." ### does NX_FLOAT make sense? + doc: "Transmission function in dependance of the electron kinetic energy. To be used in intensity calibration." (NXenergydispersion): scheme(NX_CHAR): - enumeration: ### removed some options from NXmpes + enumeration: [ "hemispherical", "double hemispherical", @@ -68,7 +68,8 @@ NXmpes_xps(NXmpes): ] energy_scan_mode(NX_CHAR): doc: "Way of scanning the energy axis." - enumeration: [ ### could potentially add some more here. + # Could potentially add some more options here. + enumeration: [ "fixed analyzer transmission", "fixed retarding ratio", "fixed energies", @@ -88,7 +89,8 @@ NXmpes_xps(NXmpes): heater_type(NX_CHAR): exists: optional doc: "Method of heating the sample. Can be e.g. electron beam heating, laser, halogen lamp." - enumeration: [ ### could potentially add some more here. + # Could potentially add some more options here. + enumeration: [ "electron beam heating", "laser", "halogen lamp", @@ -121,7 +123,7 @@ NXmpes_xps(NXmpes): doc: "The binding energy that the specified emission line appeared at, after adjusting the binding energy scale, in units of eV" calibrated_axis(NX_FLOAT): exists: recommended - doc: "This is the calibrated energy axis to be used for data plotting. This should be a link to /entry/data/energy." ######???? + doc: "This is the calibrated energy axis to be used for data plotting. This should be a link to /entry/data/energy." (NXsample): form(NX_CHAR): exists: optional @@ -132,7 +134,7 @@ NXmpes_xps(NXmpes): "pellet", "powder", ] - gas_pressure(NX_FLOAT): ######## Can be a single number or a log. + gas_pressure(NX_FLOAT): unit: NX_PRESSURE doc: "In the case of a fixed pressure measurement this is the scalar pressure. In the case of an experiment in which pressure changes, or anyway it is recorded, this is an array of length m of pressures." gas_phase(NX_CHAR): @@ -141,7 +143,7 @@ NXmpes_xps(NXmpes): (NXdata): \@axes(NX_CHAR): doc: "It should contain at least one axis called 'energy'." - energy(NX_NUMBER): #### how to represent this here? + energy(NX_NUMBER): \@type(NX_CHAR): exists: recommended doc: "The calibrated energy axis can be either in binding or kinetic energy. " @@ -153,7 +155,7 @@ NXmpes_xps(NXmpes): \@step_size(NX_FLOAT): exists: optional doc: "The step size between two consecutive energy values if the energy axis is evenly spaced." - data(NX_NUMBER): # There is a block of numbers named data. + data(NX_NUMBER): doc: "Processed plottable data. Represents a measure of one- or more-dimensional photoemission counts, where the varied axis may be for example energy, spatial coordinate, pump-probe delay, temperature, etc. The axes traces should be linked to the actual encoder position in NXinstrument or calibrated axes in NXprocess." From 42f7f721c53da85388eda6d291f4b110dbd662ce Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 5 May 2023 11:33:40 +0200 Subject: [PATCH 0855/1012] Add description of instrument orientation - Angle between beam and sample normal-> needed for determination of probing depth - Angle between beam and analyzer axes -> needed for data analysis --- contributed_definitions/nyaml/NXmpes_xps.yaml | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/contributed_definitions/nyaml/NXmpes_xps.yaml b/contributed_definitions/nyaml/NXmpes_xps.yaml index 2852868e97..dee2ac6f0e 100644 --- a/contributed_definitions/nyaml/NXmpes_xps.yaml +++ b/contributed_definitions/nyaml/NXmpes_xps.yaml @@ -30,6 +30,15 @@ NXmpes_xps(NXmpes): exists: recommended doc: "Work function of the spectrometer." unit: NX_ENERGY + # These angles could also be described by NXtransformations on the analyzer and beam. + angle_beam_sample(NX_NUMBER): + exists: recommended + doc: "Orientation of the beam with respect to the sample normal." + units: NX_ANGLE + angle_beam_analyser(NX_NUMBER): + exists: recommended + doc: "Orientation of the beam with respect to the central axis of the analyzer." + units: NX_ANGLE (NXsource): type(NX_CHAR): enumeration: [ @@ -83,7 +92,7 @@ NXmpes_xps(NXmpes): exists: optional analyzer_radius(NX_FLOAT): exists: optional - description: The radius of the hemispherical analyzer in mm (only if hemispherical analyzer is used.) + description: "The radius of the hemispherical analyzer in mm (only if hemispherical analyzer is used." unit: NX_LENGTH (NXmanipulator): heater_type(NX_CHAR): From 34e9046f9d6fa60396d3369666aa48bfc570a04e Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 9 May 2023 14:20:10 +0200 Subject: [PATCH 0856/1012] Move orientation of instrument parts Instead of having two fields on the instrument for the angle between beam and sample and the angle between beam and analyser, this information is stored in depends_on and NXtransformations in NXinstrument and NXsample, respectively. --- contributed_definitions/nyaml/NXmpes_xps.yaml | 23 +++++++++++-------- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/contributed_definitions/nyaml/NXmpes_xps.yaml b/contributed_definitions/nyaml/NXmpes_xps.yaml index dee2ac6f0e..df68169d40 100644 --- a/contributed_definitions/nyaml/NXmpes_xps.yaml +++ b/contributed_definitions/nyaml/NXmpes_xps.yaml @@ -30,15 +30,6 @@ NXmpes_xps(NXmpes): exists: recommended doc: "Work function of the spectrometer." unit: NX_ENERGY - # These angles could also be described by NXtransformations on the analyzer and beam. - angle_beam_sample(NX_NUMBER): - exists: recommended - doc: "Orientation of the beam with respect to the sample normal." - units: NX_ANGLE - angle_beam_analyser(NX_NUMBER): - exists: recommended - doc: "Orientation of the beam with respect to the central axis of the analyzer." - units: NX_ANGLE (NXsource): type(NX_CHAR): enumeration: [ @@ -104,6 +95,12 @@ NXmpes_xps(NXmpes): "laser", "halogen lamp", ] + depends_on(NX_CHAR): + exists: recommended + doc: "Reference to the transformation describing the orientation of the analyzer relative to the beam." + (NXtransformations): + exists: recommended + doc: "Set of transformations, describing the relative orientation of the analyzer with respect to the beam coordinate system." (NXprocess): energy_calibration(NXcalibration): exists: optional @@ -148,7 +145,13 @@ NXmpes_xps(NXmpes): doc: "In the case of a fixed pressure measurement this is the scalar pressure. In the case of an experiment in which pressure changes, or anyway it is recorded, this is an array of length m of pressures." gas_phase(NX_CHAR): exists: optional - doc: "Description of the constituent gases of the gas phase." + doc: "Description of the constituent gases of the gas phase." + depends_on(NX_CHAR): + exists: recommended + doc: "Reference to a transformation describing the orientation of the sample relative to the beam coordinate system." + (NXtransformations): + exists: recommended + doc: "Set of transformations, describing the relative orientation of the sample with respect to the beam coordinate system." (NXdata): \@axes(NX_CHAR): doc: "It should contain at least one axis called 'energy'." From d60f8601f3fd0b5c258fd9a417c6aa33b37580f4 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 9 May 2023 14:24:20 +0200 Subject: [PATCH 0857/1012] Update transmission function information - The transmission function contains an additional NXnote field "file" describing the file in which the TF data is stored. --- contributed_definitions/nyaml/NXmpes_xps.yaml | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/nyaml/NXmpes_xps.yaml b/contributed_definitions/nyaml/NXmpes_xps.yaml index df68169d40..4957dc868a 100644 --- a/contributed_definitions/nyaml/NXmpes_xps.yaml +++ b/contributed_definitions/nyaml/NXmpes_xps.yaml @@ -55,7 +55,13 @@ NXmpes_xps(NXmpes): ] transmission_function(NX_FLOAT): exists: recommended - doc: "Transmission function in dependance of the electron kinetic energy. To be used in intensity calibration." + doc: "Transmission function of the electron collection column. + This should be a link to /entry/process/intensity_calibration/tranmission_function." + units: NX_ANY + file(NXnote): + exists: recommended + doc: "File containing the transmission function data of the electron collection column. + This should be a link to /entry/instrument/collectioncolumn/transmission_function/file." (NXenergydispersion): scheme(NX_CHAR): enumeration: @@ -113,7 +119,12 @@ NXmpes_xps(NXmpes): doc: "Has an intensity calibration been applied? That is, has the transmission function of the analyzer been taken into account?" transmission_function(NX_FLOAT): exists: recommended - doc: "Transmission function of the electron collection column. This should be a link to /entry/instrument/collectioncolumn/tranmission_function." + doc: "Transmission function of the electron collection column. + This should be a link to /entry/instrument/collectioncolumn/transmission_function." + units: NX_ANY + file(NXnote): + exists: recommended + doc: "File containing the transmission function data. energy_reference(NXcalibration): exists: optional applied(NX_BOOLEAN): From ffeb32c3b63ef04289cba794b141900eec6cd757 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 9 May 2023 14:32:44 +0200 Subject: [PATCH 0858/1012] Update documentation, add comments for discussion --- contributed_definitions/nyaml/NXmpes_xps.yaml | 44 ++++++++++--------- 1 file changed, 24 insertions(+), 20 deletions(-) diff --git a/contributed_definitions/nyaml/NXmpes_xps.yaml b/contributed_definitions/nyaml/NXmpes_xps.yaml index 4957dc868a..78d5466861 100644 --- a/contributed_definitions/nyaml/NXmpes_xps.yaml +++ b/contributed_definitions/nyaml/NXmpes_xps.yaml @@ -60,7 +60,7 @@ NXmpes_xps(NXmpes): units: NX_ANY file(NXnote): exists: recommended - doc: "File containing the transmission function data of the electron collection column. + doc: "Name of the file containing the transmission function data of the electron collection column. This should be a link to /entry/instrument/collectioncolumn/transmission_function/file." (NXenergydispersion): scheme(NX_CHAR): @@ -84,18 +84,19 @@ NXmpes_xps(NXmpes): "detector voltage scan", "constant final state", "constant initial state", - ] + ] + # Not strictly neccessary to have. iris(NXaperture): exists: optional analyzer_radius(NX_FLOAT): exists: optional - description: "The radius of the hemispherical analyzer in mm (only if hemispherical analyzer is used." + description: "The radius of the hemispherical analyzer in mm (only if hemispherical analyzer is used)." unit: NX_LENGTH (NXmanipulator): heater_type(NX_CHAR): exists: optional doc: "Method of heating the sample. Can be e.g. electron beam heating, laser, halogen lamp." - # Could potentially add some more options here. + # Could add some more options here. enumeration: [ "electron beam heating", "laser", @@ -116,7 +117,8 @@ NXmpes_xps(NXmpes): intensity_calibration(NXcalibration): exists: optional applied(NX_BOOLEAN): - doc: "Has an intensity calibration been applied? That is, has the transmission function of the analyzer been taken into account?" + doc: "Has an intensity calibration been applied? + That is, has the transmission function of the analyzer been taken into account?" transmission_function(NX_FLOAT): exists: recommended doc: "Transmission function of the electron collection column. @@ -124,7 +126,7 @@ NXmpes_xps(NXmpes): units: NX_ANY file(NXnote): exists: recommended - doc: "File containing the transmission function data. + doc: "Name of the file containing the transmission function data." energy_reference(NXcalibration): exists: optional applied(NX_BOOLEAN): @@ -137,14 +139,17 @@ NXmpes_xps(NXmpes): doc: "Offset between measured binding energy and calibrated binding energy of the emission line." binding_energy(NX_FLOAT): exists: recommended - doc: "The binding energy that the specified emission line appeared at, after adjusting the binding energy scale, in units of eV" + doc: "The binding energy that the specified emission line appeared at, + after adjusting the binding energy scale, in units of eV" calibrated_axis(NX_FLOAT): exists: recommended - doc: "This is the calibrated energy axis to be used for data plotting. This should be a link to /entry/data/energy." + doc: "This is the calibrated energy axis to be used for data plotting. + This should be a link to /entry/data/energy." (NXsample): form(NX_CHAR): exists: optional enumeration: + # There should be more options here. [ "foil", "single crystal", @@ -153,7 +158,10 @@ NXmpes_xps(NXmpes): ] gas_pressure(NX_FLOAT): unit: NX_PRESSURE - doc: "In the case of a fixed pressure measurement this is the scalar pressure. In the case of an experiment in which pressure changes, or anyway it is recorded, this is an array of length m of pressures." + doc: | + In the case of a fixed pressure measurement this is the scalar pressure. + In the case of an experiment in which pressure changes, or anyway it is recorded, + this is an array of length m of pressures. gas_phase(NX_CHAR): exists: optional doc: "Description of the constituent gases of the gas phase." @@ -165,11 +173,15 @@ NXmpes_xps(NXmpes): doc: "Set of transformations, describing the relative orientation of the sample with respect to the beam coordinate system." (NXdata): \@axes(NX_CHAR): - doc: "It should contain at least one axis called 'energy'." + doc: "The data should contain at least one axis called 'energy'." energy(NX_NUMBER): + doc: | + The calibrated energy axis can be either in binding or kinetic energy. + This should be a link to either + /entry/process/energy calibration/calibrated_axis or + /entry/process/energy_reference/calibrated_axis. \@type(NX_CHAR): exists: recommended - doc: "The calibrated energy axis can be either in binding or kinetic energy. " enumeration: [ "kinetic", @@ -177,12 +189,4 @@ NXmpes_xps(NXmpes): ] \@step_size(NX_FLOAT): exists: optional - doc: "The step size between two consecutive energy values if the energy axis is evenly spaced." - data(NX_NUMBER): - doc: "Processed plottable data. Represents a measure of one- or more-dimensional photoemission counts, where - the varied axis may be for example energy, spatial coordinate, pump-probe delay, temperature, etc. - The axes traces should be linked to the actual encoder position in NXinstrument or calibrated axes in NXprocess." - \@units(NX_ANY): - exists: recommended - \@long_name(NX_CHAR): - exists: optional \ No newline at end of file + doc: "The step size between two consecutive energy values if the energy axis is evenly spaced." \ No newline at end of file From 8880b42a8277e3321bb25077ba01227f945bb659 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 4 Jan 2024 15:24:40 +0100 Subject: [PATCH 0859/1012] fix NXmpes yaml --- contributed_definitions/NXmpes.nxdl.xml | 4 ++-- contributed_definitions/nyaml/NXmpes.yaml | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index f2eb36fab0..8a07c0a25d 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -33,8 +33,8 @@ - This is the most general application definition for - photoemission experiments. + This is the most general application definition for multidimensional + photoelectron spectroscopy. Groups and fields are named according to the `ISO 18115-1:2023`_ specification as well as the `IUPAC Recommendations 2020`_. diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 8965b8cb50..51b1ad3616 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -1736,4 +1736,4 @@ NXmpes(NXobject): # # # -# +# \ No newline at end of file From 0e2201c91e96d67afbb59a0d2e39c27fdebf1319 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 9 Jan 2024 09:56:55 +0100 Subject: [PATCH 0860/1012] update to current NXmpes status --- contributed_definitions/Nxmpes_xps.nxdl.xml | 108 +++++++++ contributed_definitions/nyaml/NXmpes_xps.yaml | 225 ++++-------------- 2 files changed, 152 insertions(+), 181 deletions(-) create mode 100644 contributed_definitions/Nxmpes_xps.nxdl.xml diff --git a/contributed_definitions/Nxmpes_xps.nxdl.xml b/contributed_definitions/Nxmpes_xps.nxdl.xml new file mode 100644 index 0000000000..57f77d1d91 --- /dev/null +++ b/contributed_definitions/Nxmpes_xps.nxdl.xml @@ -0,0 +1,108 @@ + + + + + + This is the application definition for X-ray photoelectron spectroscopy. + + + + + + + + + + A name of the experimental method according to `Clause 11`_ of + the `ISO 18115-1:2023`_ specification. + + Examples for XPS-related experiments include: + * X-ray photoelectron spectroscopy (XPS) + * angle-resolved X-ray photoelectron spectroscopy (ARXPS) + * ultraviolet photoelectron spectroscopy (UPS) + * hard X-ray photoemission spectroscopy (HAXPES) + * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) + * electron spectroscopy for chemical analysis (ESCA) + + .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 + + + + + XPS spectrometer + + + + + + + Angle between incoming beam and the center analyser axis. + + + + + + + + + + + + + + + + + + + + + + + + + + + Angle between incoming beam and the sample. + + + + + + + + + + + + + Represents a measure of one- or more-dimensional photoemission counts, where the + varied axis may be for example energy, pump-probe delay, temperature, etc. + The axes traces should be linked to the actual encoder position in NXinstrument + or calibrated axes in NXprocess. + + + + + diff --git a/contributed_definitions/nyaml/NXmpes_xps.yaml b/contributed_definitions/nyaml/NXmpes_xps.yaml index 78d5466861..753509b044 100644 --- a/contributed_definitions/nyaml/NXmpes_xps.yaml +++ b/contributed_definitions/nyaml/NXmpes_xps.yaml @@ -1,192 +1,55 @@ -#lukas.pielsticker at cec.mpg.de, 04/2023 -#Draft version of a NeXus application definition for XPS. - doc: This is the application definition for X-ray photoelectron spectroscopy. category: application NXmpes_xps(NXmpes): (NXentry): - end_time(NX_DATE_TIME): - exists: recommended definition(NX_CHAR): - enumeration: ["NXmpes_xps"] + enumeration: [NXmpes_xps] + method: + exists: recommended + doc: | + A name of the experimental method according to `Clause 11`_ of + the `ISO 18115-1:2023`_ specification. + + Examples for XPS-related experiments include: + * X-ray photoelectron spectroscopy (XPS) + * angle-resolved X-ray photoelectron spectroscopy (ARXPS) + * ultraviolet photoelectron spectroscopy (UPS) + * hard X-ray photoemission spectroscopy (HAXPES) + * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) + * electron spectroscopy for chemical analysis (ESCA) + + .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 (NXinstrument): - energy_resolution(NX_FLOAT): - exists: recommended # cannot be required. measured value (typically from Ag 3d5/2 FWHM of sputter-cleaned Ag foil), not known every time and cann update over time (detector degradation). - unit: NX_ENERGY - manufacturer(NXfabrication): # Should go to NXmpes at some point. - exists: recommended - vendor: - exists: recommended - enumeration: [ - "SPECS GmbH", - "Kratos", - "Physical Electronics", - "Scienta", - "Thermo Fischer Scientific", - ] - model: - exists: recommended - work_function(NX_FLOAT): - exists: recommended - doc: "Work function of the spectrometer." - unit: NX_ENERGY - (NXsource): - type(NX_CHAR): - enumeration: [ - "Synchrotron X-ray Source", - "Rotating Anode X-ray", - "Fixed Tube X-ray", - "UV Laser", - "Free-Electron Laser", - "UV Plasma Source", - "Metal Jet X-ray", - ] - probe(NX_CHAR): - doc: "Type of probe. In XPS it's always X-ray photons (or UV light in UPS), so the full NIAC list is restricted." - enumeration: ["x-ray", "ultraviolet"] + doc: XPS spectrometer (NXelectronanalyser): - (NXcollectioncolumn): - scheme(NX_CHAR): - enumeration: [ - "Standard", - "Angular dispersive", - "Selective area", - "Deflector", - ] - transmission_function(NX_FLOAT): - exists: recommended - doc: "Transmission function of the electron collection column. - This should be a link to /entry/process/intensity_calibration/tranmission_function." - units: NX_ANY - file(NXnote): - exists: recommended - doc: "Name of the file containing the transmission function data of the electron collection column. - This should be a link to /entry/instrument/collectioncolumn/transmission_function/file." - (NXenergydispersion): - scheme(NX_CHAR): - enumeration: - [ - "hemispherical", - "double hemispherical", - "cylindrical mirror", - "display mirror", - "retarding grid", - ] - energy_scan_mode(NX_CHAR): - doc: "Way of scanning the energy axis." - # Could potentially add some more options here. - enumeration: [ - "fixed analyzer transmission", - "fixed retarding ratio", - "fixed energies", - "snapshot", - "imaging", - "detector voltage scan", - "constant final state", - "constant initial state", - ] - # Not strictly neccessary to have. - iris(NXaperture): - exists: optional - analyzer_radius(NX_FLOAT): - exists: optional - description: "The radius of the hemispherical analyzer in mm (only if hemispherical analyzer is used)." - unit: NX_LENGTH - (NXmanipulator): - heater_type(NX_CHAR): - exists: optional - doc: "Method of heating the sample. Can be e.g. electron beam heating, laser, halogen lamp." - # Could add some more options here. - enumeration: [ - "electron beam heating", - "laser", - "halogen lamp", - ] - depends_on(NX_CHAR): - exists: recommended - doc: "Reference to the transformation describing the orientation of the analyzer relative to the beam." - (NXtransformations): - exists: recommended - doc: "Set of transformations, describing the relative orientation of the analyzer with respect to the beam coordinate system." - (NXprocess): - energy_calibration(NXcalibration): - exists: optional - calibration_file(NXnote): - exists: optional - doc: "Name of the calibration file containing the calibration data." - intensity_calibration(NXcalibration): - exists: optional - applied(NX_BOOLEAN): - doc: "Has an intensity calibration been applied? - That is, has the transmission function of the analyzer been taken into account?" - transmission_function(NX_FLOAT): - exists: recommended - doc: "Transmission function of the electron collection column. - This should be a link to /entry/instrument/collectioncolumn/transmission_function." - units: NX_ANY - file(NXnote): - exists: recommended - doc: "Name of the file containing the transmission function data." - energy_reference(NXcalibration): - exists: optional - applied(NX_BOOLEAN): - doc: "Have the energy axes been adjusted (e.g., in cases where samples are not conductive)?" - emission_line(NX_CHAR): - exists: recommended - doc: "Emission line which was used for the calibration." - offset(NX_FLOAT): - exists: recommended - doc: "Offset between measured binding energy and calibrated binding energy of the emission line." - binding_energy(NX_FLOAT): - exists: recommended - doc: "The binding energy that the specified emission line appeared at, - after adjusting the binding energy scale, in units of eV" - calibrated_axis(NX_FLOAT): + work_function(NX_FLOAT): + exists: recommended + (NXtransformations): + angle_beam_analyser(NX_NUMBER): exists: recommended - doc: "This is the calibrated energy axis to be used for data plotting. - This should be a link to /entry/data/energy." - (NXsample): - form(NX_CHAR): - exists: optional - enumeration: - # There should be more options here. - [ - "foil", - "single crystal", - "pellet", - "powder", - ] - gas_pressure(NX_FLOAT): - unit: NX_PRESSURE - doc: | - In the case of a fixed pressure measurement this is the scalar pressure. - In the case of an experiment in which pressure changes, or anyway it is recorded, - this is an array of length m of pressures. - gas_phase(NX_CHAR): - exists: optional - doc: "Description of the constituent gases of the gas phase." - depends_on(NX_CHAR): - exists: recommended - doc: "Reference to a transformation describing the orientation of the sample relative to the beam coordinate system." + doc: Angle between incoming beam and the center analyser axis. + unit: NX_ANGLE + (NXenergydispersion): + scheme: + enumeration: [hemispherical, double hemispherical, cylindrical mirror] + energy_scan_mode: + enumeration: [fixed_analyser_transmission, fixed_energy, snapshot] + diameter(NX_FLOAT): + exists: recommended + (NXsample): (NXtransformations): - exists: recommended - doc: "Set of transformations, describing the relative orientation of the sample with respect to the beam coordinate system." + angle_beam_sample(NX_NUMBER): + exists: recommended + doc: Angle between incoming beam and the sample. + unit: NX_ANGLE (NXdata): - \@axes(NX_CHAR): - doc: "The data should contain at least one axis called 'energy'." - energy(NX_NUMBER): + \@signal: + enumeration: [data] + data(NX_NUMBER): + unit: NX_ANY doc: | - The calibrated energy axis can be either in binding or kinetic energy. - This should be a link to either - /entry/process/energy calibration/calibrated_axis or - /entry/process/energy_reference/calibrated_axis. - \@type(NX_CHAR): - exists: recommended - enumeration: - [ - "kinetic", - "binding" - ] - \@step_size(NX_FLOAT): - exists: optional - doc: "The step size between two consecutive energy values if the energy axis is evenly spaced." \ No newline at end of file + Represents a measure of one- or more-dimensional photoemission counts, where the + varied axis may be for example energy, pump-probe delay, temperature, etc. + The axes traces should be linked to the actual encoder position in NXinstrument + or calibrated axes in NXprocess. \ No newline at end of file From 7600d2775d0da16d28aa60aed13022793da51e04 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 9 Jan 2024 12:00:58 +0100 Subject: [PATCH 0861/1012] refine NXtransformations --- contributed_definitions/Nxmpes_xps.nxdl.xml | 22 +++++++++++++++++++ contributed_definitions/nyaml/NXmpes_xps.yaml | 14 ++++++++++++ 2 files changed, 36 insertions(+) diff --git a/contributed_definitions/Nxmpes_xps.nxdl.xml b/contributed_definitions/Nxmpes_xps.nxdl.xml index 57f77d1d91..e36f294e2b 100644 --- a/contributed_definitions/Nxmpes_xps.nxdl.xml +++ b/contributed_definitions/Nxmpes_xps.nxdl.xml @@ -54,11 +54,22 @@ + + + Reference to the transformation describing the orientation of the analyzer + relative to the beam. + + Angle between incoming beam and the center analyser axis. + + + + + @@ -81,11 +92,22 @@ + + + Reference to the transformation describing the orientation of the sample + relative to the beam. + + Angle between incoming beam and the sample. + + + + + diff --git a/contributed_definitions/nyaml/NXmpes_xps.yaml b/contributed_definitions/nyaml/NXmpes_xps.yaml index 753509b044..fb3d54c34d 100644 --- a/contributed_definitions/nyaml/NXmpes_xps.yaml +++ b/contributed_definitions/nyaml/NXmpes_xps.yaml @@ -25,11 +25,18 @@ NXmpes_xps(NXmpes): (NXelectronanalyser): work_function(NX_FLOAT): exists: recommended + depends_on(NX_CHAR): + exists: recommended + doc: | + Reference to the transformation describing the orientation of the analyzer + relative to the beam. (NXtransformations): angle_beam_analyser(NX_NUMBER): exists: recommended doc: Angle between incoming beam and the center analyser axis. unit: NX_ANGLE + \@transformation_type: + enumeration: [rotation] (NXenergydispersion): scheme: enumeration: [hemispherical, double hemispherical, cylindrical mirror] @@ -38,11 +45,18 @@ NXmpes_xps(NXmpes): diameter(NX_FLOAT): exists: recommended (NXsample): + depends_on(NX_CHAR): + exists: recommended + doc: | + Reference to the transformation describing the orientation of the sample + relative to the beam. (NXtransformations): angle_beam_sample(NX_NUMBER): exists: recommended doc: Angle between incoming beam and the sample. unit: NX_ANGLE + \@transformation_type: + enumeration: [rotation] (NXdata): \@signal: enumeration: [data] From 563d4e923e4db708b0b7c298ea127dda54333744 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 12 Jan 2024 16:45:52 +0100 Subject: [PATCH 0862/1012] add coordinate system and coordinate_system_set --- contributed_definitions/Nxmpes_xps.nxdl.xml | 56 ++++- contributed_definitions/nyaml/NXmpes_xps.yaml | 218 +++++++++++++++++- 2 files changed, 257 insertions(+), 17 deletions(-) diff --git a/contributed_definitions/Nxmpes_xps.nxdl.xml b/contributed_definitions/Nxmpes_xps.nxdl.xml index e36f294e2b..7b9694dbcc 100644 --- a/contributed_definitions/Nxmpes_xps.nxdl.xml +++ b/contributed_definitions/Nxmpes_xps.nxdl.xml @@ -37,24 +37,53 @@ the `ISO 18115-1:2023`_ specification. Examples for XPS-related experiments include: - * X-ray photoelectron spectroscopy (XPS) - * angle-resolved X-ray photoelectron spectroscopy (ARXPS) - * ultraviolet photoelectron spectroscopy (UPS) - * hard X-ray photoemission spectroscopy (HAXPES) - * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) - * electron spectroscopy for chemical analysis (ESCA) + * X-ray photoelectron spectroscopy (XPS) + * angle-resolved X-ray photoelectron spectroscopy (ARXPS) + * ultraviolet photoelectron spectroscopy (UPS) + * hard X-ray photoemission spectroscopy (HAXPES) + * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) + * electron spectroscopy for chemical analysis (ESCA) .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 + + + + Description of the XPS base coordinate system, which is defined such that the positive z-axis + points towards the analyzer entry, and the x-axis lies within the beam/analyzer plane. + + + + + + + + + + + + + + + + + + + + + Set of transformations, describing the orientation of the XPS coordinate system with respect to + the beam coordinate system (.). These should be links towards the NXtransformations instances + defined on the individual parts of NXinstrument. + + XPS spectrometer - - + Reference to the transformation describing the orientation of the analyzer relative to the beam. @@ -70,6 +99,11 @@ + + + Link to the XPS base coordinate system. + + @@ -84,6 +118,7 @@ + @@ -108,6 +143,11 @@ + + + Link to the XPS base coordinate system. + + diff --git a/contributed_definitions/nyaml/NXmpes_xps.yaml b/contributed_definitions/nyaml/NXmpes_xps.yaml index fb3d54c34d..87dbe0e0c2 100644 --- a/contributed_definitions/nyaml/NXmpes_xps.yaml +++ b/contributed_definitions/nyaml/NXmpes_xps.yaml @@ -1,5 +1,7 @@ -doc: This is the application definition for X-ray photoelectron spectroscopy. category: application +doc: | + This is the application definition for X-ray photoelectron spectroscopy. +type: group NXmpes_xps(NXmpes): (NXentry): definition(NX_CHAR): @@ -20,12 +22,27 @@ NXmpes_xps(NXmpes): .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 + geometries(NXcoordinate_system_set): + coordinate_system(NX_coordinate_system): + doc: | + Description of the XPS base coordinate system, which is defined such that the positive z-axis + points towards the analyzer entry, and the x-axis lies within the beam/analyzer plane. + origin: + enumeration: [beam/analyzer plane] + handedness: + enumeration: [right_handed] + z_direction: + enumeration: [analyzer entry axis] + (NXtransformations): + doc: | + Set of transformations, describing the orientation of the XPS coordinate system with respect to + the beam coordinate system (.). These should be links towards the NXtransformations instances + defined on the individual parts of NXinstrument. (NXinstrument): - doc: XPS spectrometer + doc: | + XPS spectrometer (NXelectronanalyser): - work_function(NX_FLOAT): - exists: recommended - depends_on(NX_CHAR): + depends_on: exists: recommended doc: | Reference to the transformation describing the orientation of the analyzer @@ -33,15 +50,20 @@ NXmpes_xps(NXmpes): (NXtransformations): angle_beam_analyser(NX_NUMBER): exists: recommended - doc: Angle between incoming beam and the center analyser axis. unit: NX_ANGLE + doc: | + Angle between incoming beam and the center analyser axis. \@transformation_type: enumeration: [rotation] + depends_on(link): + target: /entry/instrument/geometries/coordinate_system + doc: | + Link to the XPS base coordinate system. (NXenergydispersion): scheme: enumeration: [hemispherical, double hemispherical, cylindrical mirror] energy_scan_mode: - enumeration: [fixed_analyser_transmission, fixed_energy, snapshot] + enumeration: [fixed_analyser_transmission, fixed_retardation_ratio, fixed_energy, snapshot] diameter(NX_FLOAT): exists: recommended (NXsample): @@ -53,10 +75,15 @@ NXmpes_xps(NXmpes): (NXtransformations): angle_beam_sample(NX_NUMBER): exists: recommended - doc: Angle between incoming beam and the sample. unit: NX_ANGLE + doc: | + Angle between incoming beam and the sample. \@transformation_type: enumeration: [rotation] + depends_on(link): + target: /entry/instrument/geometries/coordinate_system + doc: | + Link to the XPS base coordinate system. (NXdata): \@signal: enumeration: [data] @@ -66,4 +93,177 @@ NXmpes_xps(NXmpes): Represents a measure of one- or more-dimensional photoemission counts, where the varied axis may be for example energy, pump-probe delay, temperature, etc. The axes traces should be linked to the actual encoder position in NXinstrument - or calibrated axes in NXprocess. \ No newline at end of file + or calibrated axes in NXprocess. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 8c2a1186258f8c27b18b84b536f85709d4751a79f87594f9cb8136dac70016a9 +# +# +# +# +# +# This is the application definition for X-ray photoelectron spectroscopy. +# +# +# +# +# +# +# +# +# +# A name of the experimental method according to `Clause 11`_ of +# the `ISO 18115-1:2023`_ specification. +# +# Examples for XPS-related experiments include: +# * X-ray photoelectron spectroscopy (XPS) +# * angle-resolved X-ray photoelectron spectroscopy (ARXPS) +# * ultraviolet photoelectron spectroscopy (UPS) +# * hard X-ray photoemission spectroscopy (HAXPES) +# * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) +# * electron spectroscopy for chemical analysis (ESCA) +# +# .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html +# .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 +# +# +# +# +# +# Description of the XPS base coordinate system, which is defined such that the positive z-axis +# points towards the analyzer entry, and the x-axis lies within the beam/analyzer plane. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Set of transformations, describing the orientation of the XPS coordinate system with respect to +# the beam coordinate system (.). These should be links towards the NXtransformations instances +# defined on the individual parts of NXinstrument. +# +# +# +# +# XPS spectrometer +# +# +# +# +# Reference to the transformation describing the orientation of the analyzer +# relative to the beam. +# +# +# +# +# +# Angle between incoming beam and the center analyser axis. +# +# +# +# +# +# +# +# +# Link to the XPS base coordinate system. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Reference to the transformation describing the orientation of the sample +# relative to the beam. +# +# +# +# +# +# Angle between incoming beam and the sample. +# +# +# +# +# +# +# +# +# Link to the XPS base coordinate system. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Represents a measure of one- or more-dimensional photoemission counts, where the +# varied axis may be for example energy, pump-probe delay, temperature, etc. +# The axes traces should be linked to the actual encoder position in NXinstrument +# or calibrated axes in NXprocess. +# +# +# +# +# From 51b28b25ca444b8f1cfe5952f71a1b71ed90b2f3 Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 29 Jan 2024 12:30:30 +0100 Subject: [PATCH 0863/1012] Adds mpes_xps to mpes structure --- manual/source/mpes-structure.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/manual/source/mpes-structure.rst b/manual/source/mpes-structure.rst index e0091995cb..af9821caee 100644 --- a/manual/source/mpes-structure.rst +++ b/manual/source/mpes-structure.rst @@ -33,4 +33,4 @@ Here's a list of application definitions related to photoemission spectroscopy: An appdef for angle-resolved photoemission spectroscopy (ARPES) experiments. :ref:`NXxps`: - An application definition for XPS/UPS measurements. \ No newline at end of file + An application definition for XPS/UPS measurements. From 8029e66546a42ad6bd85d1ffa63cc4f006968465 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 9 Feb 2024 12:33:19 +0100 Subject: [PATCH 0864/1012] rename to NXxps --- contributed_definitions/NXxps.nxdl.xml | 15 - contributed_definitions/Nxmpes_xps.nxdl.xml | 170 ----------- contributed_definitions/nyaml/NXmpes_xps.yaml | 269 ------------------ contributed_definitions/nyaml/NXxps.yaml | 1 + 4 files changed, 1 insertion(+), 454 deletions(-) delete mode 100644 contributed_definitions/Nxmpes_xps.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXmpes_xps.yaml diff --git a/contributed_definitions/NXxps.nxdl.xml b/contributed_definitions/NXxps.nxdl.xml index de4e591852..b27a136475 100644 --- a/contributed_definitions/NXxps.nxdl.xml +++ b/contributed_definitions/NXxps.nxdl.xml @@ -49,21 +49,6 @@ - - - In traditional surface science, a left-handed coordinate system is used such that the positive z-axis - points along the normal of the sample stage, and the x- and y-axes lie in the plane of the sample stage. - However, in NeXus, a coordinate system that is the same as `McStas`_ is used. `xps_coordinate_system` - gives the user the opportunity to work in the traditional base coordinate system. - - .. _McStas: http://mcstas.org/ - - .. image:: xps/xps_cs.png - :width: 40% - - - - diff --git a/contributed_definitions/Nxmpes_xps.nxdl.xml b/contributed_definitions/Nxmpes_xps.nxdl.xml deleted file mode 100644 index 7b9694dbcc..0000000000 --- a/contributed_definitions/Nxmpes_xps.nxdl.xml +++ /dev/null @@ -1,170 +0,0 @@ - - - - - - This is the application definition for X-ray photoelectron spectroscopy. - - - - - - - - - - A name of the experimental method according to `Clause 11`_ of - the `ISO 18115-1:2023`_ specification. - - Examples for XPS-related experiments include: - * X-ray photoelectron spectroscopy (XPS) - * angle-resolved X-ray photoelectron spectroscopy (ARXPS) - * ultraviolet photoelectron spectroscopy (UPS) - * hard X-ray photoemission spectroscopy (HAXPES) - * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) - * electron spectroscopy for chemical analysis (ESCA) - - .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html - .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 - - - - - - Description of the XPS base coordinate system, which is defined such that the positive z-axis - points towards the analyzer entry, and the x-axis lies within the beam/analyzer plane. - - - - - - - - - - - - - - - - - - - - - Set of transformations, describing the orientation of the XPS coordinate system with respect to - the beam coordinate system (.). These should be links towards the NXtransformations instances - defined on the individual parts of NXinstrument. - - - - - XPS spectrometer - - - - - Reference to the transformation describing the orientation of the analyzer - relative to the beam. - - - - - - Angle between incoming beam and the center analyser axis. - - - - - - - - - Link to the XPS base coordinate system. - - - - - - - - - - - - - - - - - - - - - - - - - - - - Reference to the transformation describing the orientation of the sample - relative to the beam. - - - - - - Angle between incoming beam and the sample. - - - - - - - - - Link to the XPS base coordinate system. - - - - - - - - - - - - - - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, pump-probe delay, temperature, etc. - The axes traces should be linked to the actual encoder position in NXinstrument - or calibrated axes in NXprocess. - - - - - diff --git a/contributed_definitions/nyaml/NXmpes_xps.yaml b/contributed_definitions/nyaml/NXmpes_xps.yaml deleted file mode 100644 index 87dbe0e0c2..0000000000 --- a/contributed_definitions/nyaml/NXmpes_xps.yaml +++ /dev/null @@ -1,269 +0,0 @@ -category: application -doc: | - This is the application definition for X-ray photoelectron spectroscopy. -type: group -NXmpes_xps(NXmpes): - (NXentry): - definition(NX_CHAR): - enumeration: [NXmpes_xps] - method: - exists: recommended - doc: | - A name of the experimental method according to `Clause 11`_ of - the `ISO 18115-1:2023`_ specification. - - Examples for XPS-related experiments include: - * X-ray photoelectron spectroscopy (XPS) - * angle-resolved X-ray photoelectron spectroscopy (ARXPS) - * ultraviolet photoelectron spectroscopy (UPS) - * hard X-ray photoemission spectroscopy (HAXPES) - * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) - * electron spectroscopy for chemical analysis (ESCA) - - .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html - .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 - geometries(NXcoordinate_system_set): - coordinate_system(NX_coordinate_system): - doc: | - Description of the XPS base coordinate system, which is defined such that the positive z-axis - points towards the analyzer entry, and the x-axis lies within the beam/analyzer plane. - origin: - enumeration: [beam/analyzer plane] - handedness: - enumeration: [right_handed] - z_direction: - enumeration: [analyzer entry axis] - (NXtransformations): - doc: | - Set of transformations, describing the orientation of the XPS coordinate system with respect to - the beam coordinate system (.). These should be links towards the NXtransformations instances - defined on the individual parts of NXinstrument. - (NXinstrument): - doc: | - XPS spectrometer - (NXelectronanalyser): - depends_on: - exists: recommended - doc: | - Reference to the transformation describing the orientation of the analyzer - relative to the beam. - (NXtransformations): - angle_beam_analyser(NX_NUMBER): - exists: recommended - unit: NX_ANGLE - doc: | - Angle between incoming beam and the center analyser axis. - \@transformation_type: - enumeration: [rotation] - depends_on(link): - target: /entry/instrument/geometries/coordinate_system - doc: | - Link to the XPS base coordinate system. - (NXenergydispersion): - scheme: - enumeration: [hemispherical, double hemispherical, cylindrical mirror] - energy_scan_mode: - enumeration: [fixed_analyser_transmission, fixed_retardation_ratio, fixed_energy, snapshot] - diameter(NX_FLOAT): - exists: recommended - (NXsample): - depends_on(NX_CHAR): - exists: recommended - doc: | - Reference to the transformation describing the orientation of the sample - relative to the beam. - (NXtransformations): - angle_beam_sample(NX_NUMBER): - exists: recommended - unit: NX_ANGLE - doc: | - Angle between incoming beam and the sample. - \@transformation_type: - enumeration: [rotation] - depends_on(link): - target: /entry/instrument/geometries/coordinate_system - doc: | - Link to the XPS base coordinate system. - (NXdata): - \@signal: - enumeration: [data] - data(NX_NUMBER): - unit: NX_ANY - doc: | - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, pump-probe delay, temperature, etc. - The axes traces should be linked to the actual encoder position in NXinstrument - or calibrated axes in NXprocess. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8c2a1186258f8c27b18b84b536f85709d4751a79f87594f9cb8136dac70016a9 -# -# -# -# -# -# This is the application definition for X-ray photoelectron spectroscopy. -# -# -# -# -# -# -# -# -# -# A name of the experimental method according to `Clause 11`_ of -# the `ISO 18115-1:2023`_ specification. -# -# Examples for XPS-related experiments include: -# * X-ray photoelectron spectroscopy (XPS) -# * angle-resolved X-ray photoelectron spectroscopy (ARXPS) -# * ultraviolet photoelectron spectroscopy (UPS) -# * hard X-ray photoemission spectroscopy (HAXPES) -# * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) -# * electron spectroscopy for chemical analysis (ESCA) -# -# .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html -# .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 -# -# -# -# -# -# Description of the XPS base coordinate system, which is defined such that the positive z-axis -# points towards the analyzer entry, and the x-axis lies within the beam/analyzer plane. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Set of transformations, describing the orientation of the XPS coordinate system with respect to -# the beam coordinate system (.). These should be links towards the NXtransformations instances -# defined on the individual parts of NXinstrument. -# -# -# -# -# XPS spectrometer -# -# -# -# -# Reference to the transformation describing the orientation of the analyzer -# relative to the beam. -# -# -# -# -# -# Angle between incoming beam and the center analyser axis. -# -# -# -# -# -# -# -# -# Link to the XPS base coordinate system. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Reference to the transformation describing the orientation of the sample -# relative to the beam. -# -# -# -# -# -# Angle between incoming beam and the sample. -# -# -# -# -# -# -# -# -# Link to the XPS base coordinate system. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Represents a measure of one- or more-dimensional photoemission counts, where the -# varied axis may be for example energy, pump-probe delay, temperature, etc. -# The axes traces should be linked to the actual encoder position in NXinstrument -# or calibrated axes in NXprocess. -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXxps.yaml b/contributed_definitions/nyaml/NXxps.yaml index dfb2cd7622..18515ad8f7 100644 --- a/contributed_definitions/nyaml/NXxps.yaml +++ b/contributed_definitions/nyaml/NXxps.yaml @@ -7,6 +7,7 @@ NXxps(NXmpes): definition(NX_CHAR): enumeration: [NXxps] method: + exists: recommended doc: | A name of the experimental method according to `Clause 11`_ of the `ISO 18115-1:2023`_ specification. From c0ee5a7b808157007b8ce84b04c689a0626a879a Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 13 Feb 2024 13:15:03 +0100 Subject: [PATCH 0865/1012] initial attempt at modeling XPS peak fitting --- contributed_definitions/NXbackground.nxdl.xml | 80 +++++ contributed_definitions/NXfit_region.nxdl.xml | 55 +++ contributed_definitions/NXmpes.nxdl.xml | 6 +- contributed_definitions/NXpeak.nxdl.xml | 8 +- contributed_definitions/NXpeak_model.nxdl.xml | 77 +++++ contributed_definitions/NXxps.nxdl.xml | 173 ++++++++++ .../nyaml/NXbackground.yaml | 127 +++++++ .../nyaml/NXfit_region.yaml | 84 +++++ contributed_definitions/nyaml/NXpeak.yaml | 2 +- .../nyaml/NXpeak_model.yaml | 120 +++++++ contributed_definitions/nyaml/NXxps.yaml | 312 +++++++++++++++++- 11 files changed, 1037 insertions(+), 7 deletions(-) create mode 100644 contributed_definitions/NXbackground.nxdl.xml create mode 100644 contributed_definitions/NXfit_region.nxdl.xml create mode 100644 contributed_definitions/NXpeak_model.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXbackground.yaml create mode 100644 contributed_definitions/nyaml/NXfit_region.yaml create mode 100644 contributed_definitions/nyaml/NXpeak_model.yaml diff --git a/contributed_definitions/NXbackground.nxdl.xml b/contributed_definitions/NXbackground.nxdl.xml new file mode 100644 index 0000000000..9247e5cd05 --- /dev/null +++ b/contributed_definitions/NXbackground.nxdl.xml @@ -0,0 +1,80 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of support points + + + + + Description of background for an NXpeak_model. + + + + Human-readable label which specifies which concept/entity + the background represents/identifies. + + + + + Is the background described analytically via a functional form + or is it empirically defined via measured/reported + intensity/counts as a function of an independent variable. + + Relevant details of the functional form shall be described through + NXcollection. + + + + + In the case of an empirical description of the background, + this array holds the position values for the independent variable. + + + + + + + + In the case of an empirical description of the background, + this array holds the intensity/count values at each position. + + + + + + + + In the case of an analytical description (or if description is other) this + collection holds parameter of (and eventually) the functional form. + For example in the case of Gaussians mu, sigma, cut-off values, + and background intensity are relevant parameter. + + + diff --git a/contributed_definitions/NXfit_region.nxdl.xml b/contributed_definitions/NXfit_region.nxdl.xml new file mode 100644 index 0000000000..89ad83fcc5 --- /dev/null +++ b/contributed_definitions/NXfit_region.nxdl.xml @@ -0,0 +1,55 @@ + + + + + + Description of region for peak fitting (i.e., in an NXpeak_model). + + Used for descibring a subpart of the abscissa (in 2D spectra) that is + used for fitting. + + + + Human-readable label which specifies which concept/entity + the region represents/identifies. + + + + + Minimal value of the defined region. + + + + + Minimal value of the defined region. + + + + + In the case of an analytical description (or if peak_model is other) this + collection holds parameter of (and eventually) the functional form. + For example in the case of Gaussians mu, sigma, cut-off values, + and background intensity are relevant parameter. + + + diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 8a07c0a25d..3df8510c50 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -33,8 +33,8 @@ - This is the most general application definition for multidimensional - photoelectron spectroscopy. + This is the most general application definition for + photoemission experiments. Groups and fields are named according to the `ISO 18115-1:2023`_ specification as well as the `IUPAC Recommendations 2020`_. @@ -914,4 +914,4 @@ - + \ No newline at end of file diff --git a/contributed_definitions/NXpeak.nxdl.xml b/contributed_definitions/NXpeak.nxdl.xml index 0eea9cbe3f..ea3fc17c3d 100644 --- a/contributed_definitions/NXpeak.nxdl.xml +++ b/contributed_definitions/NXpeak.nxdl.xml @@ -59,6 +59,12 @@ + + + Index of the peak, for determining the numbering of multiple + NXpeak instances. Starts with 1. + + In the case of an empirical description of the peak and its shoulders, @@ -79,7 +85,7 @@ - In the case of an analytical description (or if peak_model is other) this + In the case of an analytical description (or if description is other) this collection holds parameter of (and eventually) the functional form. For example in the case of Gaussians mu, sigma, cut-off values, and background intensity are relevant parameter. diff --git a/contributed_definitions/NXpeak_model.nxdl.xml b/contributed_definitions/NXpeak_model.nxdl.xml new file mode 100644 index 0000000000..8351adbdb5 --- /dev/null +++ b/contributed_definitions/NXpeak_model.nxdl.xml @@ -0,0 +1,77 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of peaks. + + + + + Peak fitting of a one-dimensional spectrum. + + + + Subset of the abscisssa that is used for fitting. + It is envisioned that regions are labeled as regions_0, regions_1, and so on. + + + + + One spectral peak of the peak model. + It is envisioned that peaks are labeled as peak_0, peak_1, and so on. + + + + + Description of the function used for background subtraction. + + + + + Resulting envelope of all NXpeak instances. + + Should have the same dimension as the `position` axes of the individual peaks. + + + + + Figure-of-merit, e.g., :math:`\Chi^2`, or the standard deviation of the residuals, + to determine the goodness of fit, i.e., how well the peak model fits the measured + observations. + + This value (which is a single number) is oftenused to guide adjustments to the + fitting parameters in the peak fitting process. + + + + + Atomic concentration of each species defined by one peak in the peak model. + + + diff --git a/contributed_definitions/NXxps.nxdl.xml b/contributed_definitions/NXxps.nxdl.xml index b27a136475..89a4065fce 100644 --- a/contributed_definitions/NXxps.nxdl.xml +++ b/contributed_definitions/NXxps.nxdl.xml @@ -49,6 +49,21 @@ + + + In traditional surface science, a left-handed coordinate system is used such that the positive z-axis + points along the normal of the sample stage, and the x- and y-axes lie in the plane of the sample stage. + However, in NeXus, a coordinate system that is the same as `McStas`_ is used. `xps_coordinate_system` + gives the user the opportunity to work in the traditional base coordinate system. + + .. _McStas: http://mcstas.org/ + + .. image:: xps/xps_cs.png + :width: 40% + + + + @@ -333,5 +348,163 @@ + + + Peak model for XPS fitting. Each `NXfit` instance shall be used for the description of + _one_ peak fit in _one_ XPS region. As an example, this could be used to describe the + fitting of one measured C 1s spectrum. + + This concept is related to term `3.29`_ of the ISO 18115-1:2023 standard. + + .. _3.29: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.29 + + + + + Input data and results of the fit. + + + + Dependent variable for this fit procedure. + + This could be a link to entry/data/data. + + + + + Independent variable for this fit procedure. + + This could be a link to entry/data/energy. + + + + + + + + + + + This could be a link to entry/data/energy. + + + + + Intensity values of the fitted function at each energy in the position field. + + This concept is related to term `3.15`_ of the ISO 18115-1:2023 standard. + + .. _3.15: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.15 + + + + + + + + + Area of the peak. + + + + + Width of a peak at a defined fraction of the peak height. + + Usually, this will be the Full Width at Half Maximum of the peak (FWHM). + For asymmetric peaks, convenient measures of peak width are the half-widths of + each side of the peak at half maximum intensity. + + This concept is related to term `3.28`_ of the ISO 18115-1:2023 standard. + + .. _3.28: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.28 + + + + + + Position of the peak on the energy axis. + + + + + + + Total area under the peak after background removal. + + This concept is related to term `3.16`_ of the ISO 18115-1:2023 standard. + + .. _3.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.16 + + + + + + Functional form of the fitted XPS background. + + This concept is related to term `3.21`_ of the ISO 18115-1:2023 standard. + + .. _3.21: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.21 + + + + + + + + + + + + Linear background, i.e., a simple straight line from the minimal to + the maximal abscissa value. + + + + + Shirley background. In the Shirley background, the background intensity at any + given binding energy is proportional to the intensity of the total peak area + above the background in the lower binding energy peak range (i.e., the + background goes up in proportion to the total number of photoelectrons below its + binding energy position). + + + + + Tougaard background (or Tougaard universal cross-section approach) which is a + methodology for integrating the intensity of the background at a given binding + energy from the spectral intensities to higher kinetic energies + + + + + In case none of the enumeration items apply, description should be _other_ + and the functional form of the background should be given by the `formula` + field. + + + + + + + + + + + + + + + + + + + + + Atomic concentration of each species defined by one peak in the peak model. + This should be an array with the indices pointing to the individual peaks + (i.e, peak_0, peak_1, etc.) + + + diff --git a/contributed_definitions/nyaml/NXbackground.yaml b/contributed_definitions/nyaml/NXbackground.yaml new file mode 100644 index 0000000000..13b9004293 --- /dev/null +++ b/contributed_definitions/nyaml/NXbackground.yaml @@ -0,0 +1,127 @@ +category: base +doc: | + Description of background for an NXpeak_model. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_support: | + Number of support points +type: group +NXbackground(NXobject): + label(NX_CHAR): + doc: | + Human-readable label which specifies which concept/entity + the background represents/identifies. + description(NX_CHAR): + doc: | + Is the background described analytically via a functional form + or is it empirically defined via measured/reported + intensity/counts as a function of an independent variable. + + Relevant details of the functional form shall be described through + NXcollection. + position(NX_NUMBER): + unit: NX_ANY + doc: | + In the case of an empirical description of the background, + this array holds the position values for the independent variable. + dimensions: + rank: 1 + dim: [[1, n_support]] + intensity(NX_NUMBER): + unit: NX_ANY + doc: | + In the case of an empirical description of the background, + this array holds the intensity/count values at each position. + dimensions: + rank: 1 + dim: [[1, n_support]] + (NXcollection): + doc: | + In the case of an analytical description (or if description is other) this + collection holds parameter of (and eventually) the functional form. + For example in the case of Gaussians mu, sigma, cut-off values, + and background intensity are relevant parameter. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# b830bece7ddf1d02e6d3a4e72574540c6c75a1ccd34aaec9cec2a6a0d7e1215e +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of support points +# +# +# +# +# Description of background for an NXpeak_model. +# +# +# +# Human-readable label which specifies which concept/entity +# the background represents/identifies. +# +# +# +# +# Is the background described analytically via a functional form +# or is it empirically defined via measured/reported +# intensity/counts as a function of an independent variable. +# +# Relevant details of the functional form shall be described through +# NXcollection. +# +# +# +# +# In the case of an empirical description of the background, +# this array holds the position values for the independent variable. +# +# +# +# +# +# +# +# In the case of an empirical description of the background, +# this array holds the intensity/count values at each position. +# +# +# +# +# +# +# +# In the case of an analytical description (or if description is other) this +# collection holds parameter of (and eventually) the functional form. +# For example in the case of Gaussians mu, sigma, cut-off values, +# and background intensity are relevant parameter. +# +# +# diff --git a/contributed_definitions/nyaml/NXfit_region.yaml b/contributed_definitions/nyaml/NXfit_region.yaml new file mode 100644 index 0000000000..d3c9d50171 --- /dev/null +++ b/contributed_definitions/nyaml/NXfit_region.yaml @@ -0,0 +1,84 @@ +category: base +doc: | + Description of region for peak fitting (i.e., in an NXpeak_model). + + Used for descibring a subpart of the abscissa (in 2D spectra) that is + used for fitting. +type: group +NXfit_region(NXobject): + label(NX_CHAR): + doc: | + Human-readable label which specifies which concept/entity + the region represents/identifies. + start(NX_NUMBER): + unit: NX_ANY + doc: | + Minimal value of the defined region. + stop(NX_NUMBER): + unit: NX_ANY + doc: | + Minimal value of the defined region. + (NXcollection): + doc: | + In the case of an analytical description (or if peak_model is other) this + collection holds parameter of (and eventually) the functional form. + For example in the case of Gaussians mu, sigma, cut-off values, + and background intensity are relevant parameter. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 977612f25d062246a5d813884920b21014f9e8fdf5194cd374c6a38845aede50 +# +# +# +# +# +# Description of region for peak fitting (i.e., in an NXpeak_model). +# +# Used for descibring a subpart of the abscissa (in 2D spectra) that is +# used for fitting. +# +# +# +# Human-readable label which specifies which concept/entity +# the region represents/identifies. +# +# +# +# +# Minimal value of the defined region. +# +# +# +# +# Minimal value of the defined region. +# +# +# +# +# In the case of an analytical description (or if peak_model is other) this +# collection holds parameter of (and eventually) the functional form. +# For example in the case of Gaussians mu, sigma, cut-off values, +# and background intensity are relevant parameter. +# +# +# diff --git a/contributed_definitions/nyaml/NXpeak.yaml b/contributed_definitions/nyaml/NXpeak.yaml index 46f05f9200..dcf73e6dad 100644 --- a/contributed_definitions/nyaml/NXpeak.yaml +++ b/contributed_definitions/nyaml/NXpeak.yaml @@ -36,7 +36,7 @@ NXpeak(NXobject): dim: (n_support,) (NXparameters): doc: | - In the case of an analytical description (or if peak_model is other) this + In the case of an analytical description (or if description is other) this collection holds parameter of (and eventually) the functional form. For example in the case of Gaussians mu, sigma, cut-off values, and background intensity are relevant parameter. diff --git a/contributed_definitions/nyaml/NXpeak_model.yaml b/contributed_definitions/nyaml/NXpeak_model.yaml new file mode 100644 index 0000000000..dbdf6a206b --- /dev/null +++ b/contributed_definitions/nyaml/NXpeak_model.yaml @@ -0,0 +1,120 @@ +category: base +doc: | + Peak fitting of a one-dimensional spectrum. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_peaks: | + Number of peaks. +type: group +NXpeak_model(NXprocess): + region_REGION(NXfit_region): + doc: | + Subset of the abscisssa that is used for fitting. + It is envisioned that regions are labeled as regions_0, regions_1, and so on. + peak_PEAK(NXpeak): + doc: | + One spectral peak of the peak model. + It is envisioned that peaks are labeled as peak_0, peak_1, and so on. + background(NX_background): + doc: | + Description of the function used for background subtraction. + envelope(NX_NUMBER): + unit: NX_ANY + doc: | + Resulting envelope of all NXpeak instances. + + Should have the same dimension as the `position` axes of the individual peaks. + figure_of_merit(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Figure-of-merit, e.g., :math:`\Chi^2`, or the standard deviation of the residuals, + to determine the goodness of fit, i.e., how well the peak model fits the measured + observations. + + This value (which is a single number) is oftenused to guide adjustments to the + fitting parameters in the peak fitting process. + relative_concentration(NX_FLOAT): + unit: NX_ANY + doc: | + Atomic concentration of each species defined by one peak in the peak model. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 13bb218f2c25c0e41f54dd416852f694d0fbb2cfff457aabd85f691839a4ab72 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of peaks. +# +# +# +# +# Peak fitting of a one-dimensional spectrum. +# +# +# +# Subset of the abscisssa that is used for fitting. +# It is envisioned that regions are labeled as regions_0, regions_1, and so on. +# +# +# +# +# One spectral peak of the peak model. +# It is envisioned that peaks are labeled as peak_0, peak_1, and so on. +# +# +# +# +# Description of the function used for background subtraction. +# +# +# +# +# Resulting envelope of all NXpeak instances. +# +# Should have the same dimension as the `position` axes of the individual peaks. +# +# +# +# +# Figure-of-merit, e.g., :math:`\Chi^2`, or the standard deviation of the residuals, +# to determine the goodness of fit, i.e., how well the peak model fits the measured +# observations. +# +# This value (which is a single number) is oftenused to guide adjustments to the +# fitting parameters in the peak fitting process. +# +# +# +# +# Atomic concentration of each species defined by one peak in the peak model. +# +# +# diff --git a/contributed_definitions/nyaml/NXxps.yaml b/contributed_definitions/nyaml/NXxps.yaml index 18515ad8f7..c15d457deb 100644 --- a/contributed_definitions/nyaml/NXxps.yaml +++ b/contributed_definitions/nyaml/NXxps.yaml @@ -7,7 +7,6 @@ NXxps(NXmpes): definition(NX_CHAR): enumeration: [NXxps] method: - exists: recommended doc: | A name of the experimental method according to `Clause 11`_ of the `ISO 18115-1:2023`_ specification. @@ -231,9 +230,160 @@ NXxps(NXmpes): \@reference: exists: recommended \@energy_indices: + (NXfit): + exists: recommended + doc: + - | + Peak model for XPS fitting. Each `NXfit` instance shall be used for the description of + _one_ peak fit in _one_ XPS region. As an example, this could be used to describe the + fitting of one measured C 1s spectrum. + - | + xref: + spec: ISO 18115-1:2023 + term: 3.29 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.29 + label: + data(NXdata): + doc: | + Input data and results of the fit. + input_dependent(NX_NUMBER): + unit: NX_ANY + doc: | + Dependent variable for this fit procedure. + + This could be a link to entry/data/data. + input_independent(NX_NUMBER): + unit: NX_ANY + doc: | + Independent variable for this fit procedure. + + This could be a link to entry/data/energy. + envelope(NX_NUMBER): + residual(NX_NUMBER): + exists: recommended + peakPEAK(NXpeak): + label: + data(NXdata): + position(NX_NUMBER): + unit: NX_ENERGY + doc: | + This could be a link to entry/data/energy. + intensity(NX_NUMBER): + doc: + - | + Intensity values of the fitted function at each energy in the position field. + - | + xref: + spec: ISO 18115-1:2023 + term: 3.15 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.15 + function(NXfit_function): + exists: recommended + description: + formula: + exists: recommended + area(NXfit_parameter): + exists: optional + doc: | + Area of the peak. + width(NXfit_parameter): + exists: optional + doc: + - | + Width of a peak at a defined fraction of the peak height. + - | + Usually, this will be the Full Width at Half Maximum of the peak (FWHM). + For asymmetric peaks, convenient measures of peak width are the half-widths of + each side of the peak at half maximum intensity. + - | + xref: + spec: ISO 18115-1:2023 + term: 3.28 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.28 + value: + unit: NX_ENERGY + position(NXfit_parameter): + exists: optional + doc: | + Position of the peak on the energy axis. + value: + unit: NX_ENERGY + total_area: + exists: recommended + doc: + - | + Total area under the peak after background removal. + - | + xref: + spec: ISO 18115-1:2023 + term: 3.16 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.16 + backgroundBACKGROUND(NXfit_background): + doc: + - | + Functional form of the fitted XPS background. + - | + xref: + spec: ISO 18115-1:2023 + term: 3.21 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.21 + label: + exists: recommended + data(NXdata): + position(NX_NUMBER): + unit: NX_ENERGY + intensity(NX_NUMBER): + function(NXfit_function): + exists: recommended + description: + enumeration: + linear: + doc: | + Linear background, i.e., a simple straight line from the minimal to + the maximal abscissa value. + Shirley: + doc: | + Shirley background. In the Shirley background, the background intensity at any + given binding energy is proportional to the intensity of the total peak area + above the background in the lower binding energy peak range (i.e., the + background goes up in proportion to the total number of photoelectrons below its + binding energy position). + Tougaard: + doc: | + Tougaard background (or Tougaard universal cross-section approach) which is a + methodology for integrating the intensity of the background at a given binding + energy from the spectral intensities to higher kinetic energies + other: + doc: | + In case none of the enumeration items apply, description should be _other_ + and the functional form of the background should be given by the `formula` + field. + formula: + exists: recommended + global_fit_function(NXfit_function): + exists: recommended + description: + exists: recommended + formula: + exists: recommended + error_function(NXfit_function): + exists: recommended + description: + exists: recommended + formula: + exists: recommended + figure_of_meritMETRIC(NX_NUMBER): + exists: recommended + \@metric: + relative_concentration(NX_FLOAT): + unit: NX_ANY + doc: | + Atomic concentration of each species defined by one peak in the peak model. + This should be an array with the indices pointing to the individual peaks + (i.e, peak_0, peak_1, etc.) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 804ce774ddb827110dd20f43f5edf1748376d129a0b4f6416c94980c77270e55 +# 04421486bc5dffb01865fb8e056d77e5f5157304a3bc3ab9024c8ad160fe21e6 # # # + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of discretization points inside the fitting region. + + + + + Description of a fit procedure. + + + + Human-readable label for this fit procedure. + + + + + Subset of the independent axis for this fit procedure. + + + + + + + + One spectral peak of the peak model. + It is envisioned that peaks are labeled as peak_0, peak_1, and so on. + + + + Total area under the curve. (can also be used for the total area minus any + background values.) + + + + + Relative sensitivity for this peak, to be used for quantification in + an NXprocess. + + As an example, in X-ray spectroscopy could depend on the energy scale3 + (see position), the ionization cross section, and the element probed. + + + + + Relative area of this peak compared to other peaks. + + The relative area can simply be derived by dividing the total_area by the + total area of all peaks or by a more complicated method (e.g., by + additionally dividing by the relative sensitivity factors). Details shall + be given in fitting_method + + + + + Constraint on the minimum and maximum area of this peak. + + + + + + Link to a peak the area constraint depends on. + + + + + + Constraint on the minimum and maximum width of this peak. + + + + + + Link to a peak the width constraint depends on. + + + + + + Constraint on the minimum and maximum position of this peak on the abscissa. + + + + + + Link to a peak the position constraint depends on. + + + + + + + One fitted background (functional, position, and intensities) of the peak fit. + It is envisioned that peaks are labeled as background_0, background_1, and + so on. + + + + + Description of the method used to optimize the parameters during peak fitting. + Examples: + - least squares + - non-linear least squares + - Levenberg-Marquardt algorithm (damped least-squares) + - linear regression + - Bayesian linear regression + + + + + Resulting envelope of all NXpeak instances. + + Should have the same dimension as the `position` axes of the individual peaks. + + + + + + + + Figure-of-merit to determine the goodness of fit, i.e., how well the peak model + fits the measured observations. + + This value (which is a single number) is oftenused to guide adjustments to the + fitting parameters in the peak fitting process. + + + + Metric used to determine the goodness of fit. Examples include: + - :math:`\Chi^2`, the standard deviation of the residuals + - reduced :math:`\Chi^2`:, :math:`\Chi^2`: per degree of freedom + - :math:`R^2`, the coefficient of determination + + + + + + Difference between the envelope and the data to be fitted. + + + + + + diff --git a/contributed_definitions/NXbackground.nxdl.xml b/contributed_definitions/NXfit_background.nxdl.xml similarity index 83% rename from contributed_definitions/NXbackground.nxdl.xml rename to contributed_definitions/NXfit_background.nxdl.xml index 9247e5cd05..0b2e73f5cb 100644 --- a/contributed_definitions/NXbackground.nxdl.xml +++ b/contributed_definitions/NXfit_background.nxdl.xml @@ -21,14 +21,15 @@ # # For further information, see http://www.nexusformat.org --> - + The symbols used in the schema to specify e.g. dimensions of arrays. - Number of support points + Number of discretization points at which the functional form of the + background has been evaluated. @@ -48,7 +49,7 @@ intensity/counts as a function of an independent variable. Relevant details of the functional form shall be described through - NXcollection. + background_parameters. @@ -69,12 +70,12 @@ - + - In the case of an analytical description (or if description is other) this - collection holds parameter of (and eventually) the functional form. - For example in the case of Gaussians mu, sigma, cut-off values, - and background intensity are relevant parameter. + In the case of an analytical description (or if description is other), + this holds parameter of the functional form. + For example in the case of Gaussians mu, sigma, and cut-off values are + relevant parameters. diff --git a/contributed_definitions/NXfit_region.nxdl.xml b/contributed_definitions/NXfit_region.nxdl.xml deleted file mode 100644 index ae018ff988..0000000000 --- a/contributed_definitions/NXfit_region.nxdl.xml +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - Description of region for peak fitting (i.e., in an NXpeak_model). - - Used for descibring a subpart of the abscissa (in 2D spectra) that is - used for fitting. - - - - Human-readable label which specifies which concept/entity - the region represents/identifies. - - - - - Minimal value of the defined region. - - - - - Minimal value of the defined region. - - - - - Fitted background (functional, position, and intensities). - - - - - In the case of an analytical description (or if peak_model is other) this - collection holds parameter of (and eventually) the functional form. - For example in the case of Gaussians mu, sigma, cut-off values, - and background intensity are relevant parameter. - - - diff --git a/contributed_definitions/NXpeak.nxdl.xml b/contributed_definitions/NXpeak.nxdl.xml index 5685e12599..996c7e9113 100644 --- a/contributed_definitions/NXpeak.nxdl.xml +++ b/contributed_definitions/NXpeak.nxdl.xml @@ -28,12 +28,13 @@ - Number of support points. + Number of discretization points at which the functional form of the peak + has been evaluated. - Base class for describing spectral peaks, their functional form, and support values + Base class for describing a spectral peak, its functional form, and support values (i.e., the discretization (points) at which the function has been evaluated). @@ -68,7 +69,7 @@ - In the case of an empirical description of the peak and its shoulders, + In the case of an empirical description of the peak, this array holds the position values for the independent variable. @@ -77,66 +78,19 @@ - In the case of an empirical description of the peak and its shoulders, + In the case of an empirical description of the peak, this array holds the intensity/count values at each position. -<<<<<<< HEAD -======= - - - Width of a peak at a defined fraction of the peak height. - - Usually, this will be the Full Width at Half Maximum of the peak (FWHM). - For asymmetric peaks, convenient measures of peak width are the half-widths of - each side of the peak at half maximum intensity. - - - - Specification of the definition of `width`. - - - - - Full Width at Half Maximum of the peak. - - - - - Half Width at Half Maximum of the peak. - - - - - For asymmetrical peaks, the half-widths of each side of the peak at - half maximum intensity is given. - - - - - For other peak width definitions. - - - - - - - - A formula to describe the line shape using set of parameters as entered - by the `peak_parameters` fields. - - - ->>>>>>> ef396415d (update lineshape in NXpeak) In the case of an analytical description (or if description is other) this - collection holds parameter of (and eventually) the functional form. - For example in the case of Gaussians mu, sigma, cut-off values, - and background intensity are relevant parameter. + collection holds parameter of the functional form. + For example in the case of Gaussians mu, sigma, and cut-off values are + relevant parameters. diff --git a/contributed_definitions/NXpeak_model.nxdl.xml b/contributed_definitions/NXpeak_model.nxdl.xml deleted file mode 100644 index 13e6828ad2..0000000000 --- a/contributed_definitions/NXpeak_model.nxdl.xml +++ /dev/null @@ -1,88 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of peaks. - - - - - Peak fitting of a one-dimensional spectrum. - - - - Subset of the abscisssa that is used for fitting. - It is envisioned that regions are labeled as regions_0, regions_1, and so on. - - - - - One spectral peak of the peak model. - It is envisioned that peaks are labeled as peak_0, peak_1, and so on. - - - - - Description of the function used for background subtraction. - - - - - Resulting envelope of all NXpeak instances. - - Should have the same dimension as the `position` axes of the individual peaks. - - - - - Figure-of-merit, e.g., :math:`\Chi^2`, or the standard deviation of the residuals, - to determine the goodness of fit, i.e., how well the peak model fits the measured - observations. - - This value (which is a single number) is oftenused to guide adjustments to the - fitting parameters in the peak fitting process. - - - - - Description of the method used to optimize the parameters during peak fitting. - Examples: - - least squares - - non-linear least squares - - Levenberg-Marquardt algorithm (damped least-squares) - - linear regression - - Bayesian linear regression - - - - - Atomic concentration of each species defined by one peak in the peak model. - - - diff --git a/contributed_definitions/nyaml/NXfit.yaml b/contributed_definitions/nyaml/NXfit.yaml new file mode 100644 index 0000000000..e0b3ddbdac --- /dev/null +++ b/contributed_definitions/nyaml/NXfit.yaml @@ -0,0 +1,288 @@ +category: base +doc: | + Description of a fit procedure. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_points: | + Number of discretization points inside the fitting region. +type: group +NXfit(NXobject): + label: + doc: | + Human-readable label for this fit procedure. + region(NX_NUMBER): + unit: NX_ANY + doc: | + Subset of the independent axis for this fit procedure. + dim: (n_points,) + peak_PEAK(NXpeak): + doc: | + One spectral peak of the peak model. + It is envisioned that peaks are labeled as peak_0, peak_1, and so on. + total_area(NX_NUMBER): + unit: NX_ANY + doc: | + Total area under the curve. (can also be used for the total area minus any + background values.) + relative_sensitivity_factor(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Relative sensitivity for this peak, to be used for quantification in + an NXprocess. + + As an example, in X-ray spectroscopy could depend on the energy scale3 + (see position), the ionization cross section, and the element probed. + relative_area(NX_NUMBER): + unit: NX_ANY + doc: | + Relative area of this peak compared to other peaks. + + The relative area can simply be derived by dividing the total_area by the + total area of all peaks or by a more complicated method (e.g., by + additionally dividing by the relative sensitivity factors). Details shall + be given in fitting_method + area_constraint(NXparameters): + doc: | + Constraint on the minimum and maximum area of this peak. + minimal_value(NX_NUMBER): + unit: NX_ANY + maximal_value(NX_NUMBER): + unit: NX_ANY + depends_on: + doc: | + Link to a peak the area constraint depends on. + width_constraint(NXparameters): + doc: | + Constraint on the minimum and maximum width of this peak. + minimal_value(NX_NUMBER): + unit: NX_ANY + maximal_value(NX_NUMBER): + unit: NX_ANY + depends_on: + doc: | + Link to a peak the width constraint depends on. + position_constraint(NXparameters): + doc: | + Constraint on the minimum and maximum position of this peak on the abscissa. + minimal_value(NX_NUMBER): + unit: NX_ANY + maximal_value(NX_NUMBER): + unit: NX_ANY + depends_on: + doc: | + Link to a peak the position constraint depends on. + background_BACKGROUND(NXfit_background): + doc: | + One fitted background (functional, position, and intensities) of the peak fit. + It is envisioned that peaks are labeled as background_0, background_1, and + so on. + fitting_method: + doc: | + Description of the method used to optimize the parameters during peak fitting. + Examples: + - least squares + - non-linear least squares + - Levenberg-Marquardt algorithm (damped least-squares) + - linear regression + - Bayesian linear regression + envelope(NX_NUMBER): + unit: NX_ANY + doc: | + Resulting envelope of all NXpeak instances. + + Should have the same dimension as the `position` axes of the individual peaks. + dim: (n_points,) + figure_of_merit_METRIC(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Figure-of-merit to determine the goodness of fit, i.e., how well the peak model + fits the measured observations. + + This value (which is a single number) is oftenused to guide adjustments to the + fitting parameters in the peak fitting process. + \@metric: + doc: | + Metric used to determine the goodness of fit. Examples include: + - :math:`\Chi^2`, the standard deviation of the residuals + - reduced :math:`\Chi^2`:, :math:`\Chi^2`: per degree of freedom + - :math:`R^2`, the coefficient of determination + residual(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Difference between the envelope and the data to be fitted. + dim: (n_points,) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 332a87f3d66a159e0249e86266ae53783011b8e4384bb6bcd21ebb8bdcdb09cb +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of discretization points inside the fitting region. +# +# +# +# +# Description of a fit procedure. +# +# +# +# Human-readable label for this fit procedure. +# +# +# +# +# Subset of the independent axis for this fit procedure. +# +# +# +# +# +# +# +# One spectral peak of the peak model. +# It is envisioned that peaks are labeled as peak_0, peak_1, and so on. +# +# +# +# Total area under the curve. (can also be used for the total area minus any +# background values.) +# +# +# +# +# Relative sensitivity for this peak, to be used for quantification in +# an NXprocess. +# +# As an example, in X-ray spectroscopy could depend on the energy scale3 +# (see position), the ionization cross section, and the element probed. +# +# +# +# +# Relative area of this peak compared to other peaks. +# +# The relative area can simply be derived by dividing the total_area by the +# total area of all peaks or by a more complicated method (e.g., by +# additionally dividing by the relative sensitivity factors). Details shall +# be given in fitting_method +# +# +# +# +# Constraint on the minimum and maximum area of this peak. +# +# +# +# +# +# Link to a peak the area constraint depends on. +# +# +# +# +# +# Constraint on the minimum and maximum width of this peak. +# +# +# +# +# +# Link to a peak the width constraint depends on. +# +# +# +# +# +# Constraint on the minimum and maximum position of this peak on the abscissa. +# +# +# +# +# +# Link to a peak the position constraint depends on. +# +# +# +# +# +# +# One fitted background (functional, position, and intensities) of the peak fit. +# It is envisioned that peaks are labeled as background_0, background_1, and +# so on. +# +# +# +# +# Description of the method used to optimize the parameters during peak fitting. +# Examples: +# - least squares +# - non-linear least squares +# - Levenberg-Marquardt algorithm (damped least-squares) +# - linear regression +# - Bayesian linear regression +# +# +# +# +# Resulting envelope of all NXpeak instances. +# +# Should have the same dimension as the `position` axes of the individual peaks. +# +# +# +# +# +# +# +# Figure-of-merit to determine the goodness of fit, i.e., how well the peak model +# fits the measured observations. +# +# This value (which is a single number) is oftenused to guide adjustments to the +# fitting parameters in the peak fitting process. +# +# +# +# Metric used to determine the goodness of fit. Examples include: +# - :math:`\Chi^2`, the standard deviation of the residuals +# - reduced :math:`\Chi^2`:, :math:`\Chi^2`: per degree of freedom +# - :math:`R^2`, the coefficient of determination +# +# +# +# +# +# Difference between the envelope and the data to be fitted. +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXbackground.yaml b/contributed_definitions/nyaml/NXfit_background.yaml similarity index 80% rename from contributed_definitions/nyaml/NXbackground.yaml rename to contributed_definitions/nyaml/NXfit_background.yaml index d9edb4c285..1967cce4c2 100644 --- a/contributed_definitions/nyaml/NXbackground.yaml +++ b/contributed_definitions/nyaml/NXfit_background.yaml @@ -5,9 +5,10 @@ symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. n_support: | - Number of support points + Number of discretization points at which the functional form of the + background has been evaluated. type: group -NXbackground(NXobject): +NXfit_background(NXobject): label(NX_CHAR): doc: | Human-readable label which specifies which concept/entity @@ -19,7 +20,7 @@ NXbackground(NXobject): intensity/counts as a function of an independent variable. Relevant details of the functional form shall be described through - NXcollection. + background_parameters. position(NX_NUMBER): unit: NX_ANY doc: | @@ -32,15 +33,15 @@ NXbackground(NXobject): In the case of an empirical description of the background, this array holds the intensity/count values at each position. dim: (n_support,) - (NXcollection): + background_parameters(NXparameters): doc: | - In the case of an analytical description (or if description is other) this - collection holds parameter of (and eventually) the functional form. - For example in the case of Gaussians mu, sigma, cut-off values, - and background intensity are relevant parameter. + In the case of an analytical description (or if description is other), + this holds parameter of the functional form. + For example in the case of Gaussians mu, sigma, and cut-off values are + relevant parameters. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# b830bece7ddf1d02e6d3a4e72574540c6c75a1ccd34aaec9cec2a6a0d7e1215e +# ab225b7c9634039e078d5ba44500c59f05958c63b16b4e3beb5c171d47fe65b1 # # # -# +# # # # The symbols used in the schema to specify e.g. dimensions of arrays. # # # -# Number of support points +# Number of discretization points at which the functional form of the +# background has been evaluated. # # # @@ -91,7 +93,7 @@ NXbackground(NXobject): # intensity/counts as a function of an independent variable. # # Relevant details of the functional form shall be described through -# NXcollection. +# background_parameters. # # # @@ -112,12 +114,12 @@ NXbackground(NXobject): # # # -# +# # -# In the case of an analytical description (or if description is other) this -# collection holds parameter of (and eventually) the functional form. -# For example in the case of Gaussians mu, sigma, cut-off values, -# and background intensity are relevant parameter. +# In the case of an analytical description (or if description is other), +# this holds parameter of the functional form. +# For example in the case of Gaussians mu, sigma, and cut-off values are +# relevant parameters. # # # diff --git a/contributed_definitions/nyaml/NXfit_region.yaml b/contributed_definitions/nyaml/NXfit_region.yaml deleted file mode 100644 index 303854e3e6..0000000000 --- a/contributed_definitions/nyaml/NXfit_region.yaml +++ /dev/null @@ -1,92 +0,0 @@ -category: base -doc: | - Description of region for peak fitting (i.e., in an NXpeak_model). - - Used for descibring a subpart of the abscissa (in 2D spectra) that is - used for fitting. -type: group -NXfit_region(NXobject): - label(NX_CHAR): - doc: | - Human-readable label which specifies which concept/entity - the region represents/identifies. - start(NX_NUMBER): - unit: NX_ANY - doc: | - Minimal value of the defined region. - stop(NX_NUMBER): - unit: NX_ANY - doc: | - Minimal value of the defined region. - (NXbackground): - doc: | - Fitted background (functional, position, and intensities). - (NXcollection): - doc: | - In the case of an analytical description (or if peak_model is other) this - collection holds parameter of (and eventually) the functional form. - For example in the case of Gaussians mu, sigma, cut-off values, - and background intensity are relevant parameter. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 40645fad714a7390543883c71b1c2d27ef4cf350cb98f2011197d9135249715c -# -# -# -# -# -# Description of region for peak fitting (i.e., in an NXpeak_model). -# -# Used for descibring a subpart of the abscissa (in 2D spectra) that is -# used for fitting. -# -# -# -# Human-readable label which specifies which concept/entity -# the region represents/identifies. -# -# -# -# -# Minimal value of the defined region. -# -# -# -# -# Minimal value of the defined region. -# -# -# -# -# Fitted background (functional, position, and intensities). -# -# -# -# -# In the case of an analytical description (or if peak_model is other) this -# collection holds parameter of (and eventually) the functional form. -# For example in the case of Gaussians mu, sigma, cut-off values, -# and background intensity are relevant parameter. -# -# -# diff --git a/contributed_definitions/nyaml/NXpeak.yaml b/contributed_definitions/nyaml/NXpeak.yaml index 7d13999811..b9f76bc5e2 100644 --- a/contributed_definitions/nyaml/NXpeak.yaml +++ b/contributed_definitions/nyaml/NXpeak.yaml @@ -1,12 +1,13 @@ category: base doc: | - Base class for describing spectral peaks, their functional form, and support values + Base class for describing a spectral peak, its functional form, and support values (i.e., the discretization (points) at which the function has been evaluated). symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. n_support: | - Number of support points. + Number of discretization points at which the functional form of the peak + has been evaluated. type: group NXpeak(NXobject): label: @@ -25,13 +26,13 @@ NXpeak(NXobject): enumeration: [empirical, gaussian, lorentzian, voigt, other] position(NX_NUMBER): doc: | - In the case of an empirical description of the peak and its shoulders, + In the case of an empirical description of the peak, this array holds the position values for the independent variable. unit: NX_ANY dim: (n_support,) intensity(NX_NUMBER): doc: | - In the case of an empirical description of the peak and its shoulders, + In the case of an empirical description of the peak, this array holds the intensity/count values at each position. unit: NX_ANY dim: (n_support,) diff --git a/contributed_definitions/nyaml/NXpeak_model.yaml b/contributed_definitions/nyaml/NXpeak_model.yaml deleted file mode 100644 index 1ffaa60e76..0000000000 --- a/contributed_definitions/nyaml/NXpeak_model.yaml +++ /dev/null @@ -1,140 +0,0 @@ -category: base -doc: | - Peak fitting of a one-dimensional spectrum. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_peaks: | - Number of peaks. -type: group -NXpeak_model(NXprocess): - region_REGION(NXfit_region): - doc: | - Subset of the abscisssa that is used for fitting. - It is envisioned that regions are labeled as regions_0, regions_1, and so on. - peak_PEAK(NXpeak): - doc: | - One spectral peak of the peak model. - It is envisioned that peaks are labeled as peak_0, peak_1, and so on. - background(NX_background): - doc: | - Description of the function used for background subtraction. - envelope(NX_NUMBER): - unit: NX_ANY - doc: | - Resulting envelope of all NXpeak instances. - - Should have the same dimension as the `position` axes of the individual peaks. - figure_of_merit(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Figure-of-merit, e.g., :math:`\Chi^2`, or the standard deviation of the residuals, - to determine the goodness of fit, i.e., how well the peak model fits the measured - observations. - - This value (which is a single number) is oftenused to guide adjustments to the - fitting parameters in the peak fitting process. - fitting_method: - doc: | - Description of the method used to optimize the parameters during peak fitting. - Examples: - - least squares - - non-linear least squares - - Levenberg-Marquardt algorithm (damped least-squares) - - linear regression - - Bayesian linear regression - relative_concentration(NX_FLOAT): - unit: NX_ANY - doc: | - Atomic concentration of each species defined by one peak in the peak model. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# ac6b6234e775a297a41f680a8ed708950292beff8778e4db26602578ecae71f0 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of peaks. -# -# -# -# -# Peak fitting of a one-dimensional spectrum. -# -# -# -# Subset of the abscisssa that is used for fitting. -# It is envisioned that regions are labeled as regions_0, regions_1, and so on. -# -# -# -# -# One spectral peak of the peak model. -# It is envisioned that peaks are labeled as peak_0, peak_1, and so on. -# -# -# -# -# Description of the function used for background subtraction. -# -# -# -# -# Resulting envelope of all NXpeak instances. -# -# Should have the same dimension as the `position` axes of the individual peaks. -# -# -# -# -# Figure-of-merit, e.g., :math:`\Chi^2`, or the standard deviation of the residuals, -# to determine the goodness of fit, i.e., how well the peak model fits the measured -# observations. -# -# This value (which is a single number) is oftenused to guide adjustments to the -# fitting parameters in the peak fitting process. -# -# -# -# -# Description of the method used to optimize the parameters during peak fitting. -# Examples: -# - least squares -# - non-linear least squares -# - Levenberg-Marquardt algorithm (damped least-squares) -# - linear regression -# - Bayesian linear regression -# -# -# -# -# Atomic concentration of each species defined by one peak in the peak model. -# -# -# From ebae306155c175b56e0621394b64ef7e83e4150e Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 15 Feb 2024 15:05:37 +0100 Subject: [PATCH 0872/1012] change to NXcoordinate_system_set, use NXfit in NXxps --- contributed_definitions/NXxps.nxdl.xml | 74 +++++++ contributed_definitions/nyaml/NXmpes.yaml | 40 ++++ contributed_definitions/nyaml/NXxps.yaml | 258 ++++++++-------------- 3 files changed, 202 insertions(+), 170 deletions(-) diff --git a/contributed_definitions/NXxps.nxdl.xml b/contributed_definitions/NXxps.nxdl.xml index 0360ff5934..c159a60fa2 100644 --- a/contributed_definitions/NXxps.nxdl.xml +++ b/contributed_definitions/NXxps.nxdl.xml @@ -404,7 +404,11 @@ >>>>>>> 7178a95ca (remove NXtransformations from NXcoordinate_system) +<<<<<<< HEAD +======= + +>>>>>>> 5e7c2dec7 (change to NXcoordinate_system_set, use NXfit in NXxps) Peak model for XPS fitting. Each `NXfit` instance shall be used for the description of _one_ peak fit in _one_ XPS region. As an example, this could be used to describe the @@ -414,17 +418,66 @@ .. _3.29: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.29 +<<<<<<< HEAD Input data and results of the fit. +======= + + + Description of one peak fit. This is meant to be used for a peak fit in + _one_ XPS region. As an eexample, this could be used to describe the + fitting of one measured C 1s spectrum. + + + + + + + + + + Intensity/count values at each energy in the position field. + + This concept is related to term `3.15`_ of the ISO 18115-1:2023 standard. + + .. _3.15: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.15 + + + + + Width of a peak at a defined fraction of the peak height. + + Usually, this will be the Full Width at Half Maximum of the peak (FWHM). + For asymmetric peaks, convenient measures of peak width are the half-widths of + each side of the peak at half maximum intensity. + + This concept is related to term `3.28`_ of the ISO 18115-1:2023 standard. + + .. _3.28: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.28 + + + + + Total area under the peak after background removal. + + This concept is related to term `3.16`_ of the ISO 18115-1:2023 standard. + + .. _3.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.16 + + + + +>>>>>>> 5e7c2dec7 (change to NXcoordinate_system_set, use NXfit in NXxps) Dependent variable for this fit procedure. This could be a link to entry/data/data. +<<<<<<< HEAD @@ -507,6 +560,9 @@ +======= + +>>>>>>> 5e7c2dec7 (change to NXcoordinate_system_set, use NXfit in NXxps) @@ -539,9 +595,27 @@ + + +<<<<<<< HEAD +======= + + + + + + + + + Atomic concentration of each species defined by one peak in the peak model. + This should be an array with the indices pointing to the individual peaks + (i.e, peak_0, peak_1, etc.) + + +>>>>>>> 5e7c2dec7 (change to NXcoordinate_system_set, use NXfit in NXxps) diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 7caa8b1460..9f8366f444 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -791,6 +791,15 @@ NXmpes(NXobject): For example: @energy_depends: 'entry/process/energy_calibration' +<<<<<<< HEAD +======= + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +<<<<<<< HEAD +<<<<<<< HEAD +# 7f45ab08c78a105a15e2c6f5ddbcdcab4002929bf8d19e8ec2987bd507525680 +======= +>>>>>>> 5e7c2dec7 (change to NXcoordinate_system_set, use NXfit in NXxps) doc: | The energy can be either stored as kinetic or as binding energy. enumeration: @@ -833,7 +842,13 @@ NXmpes(NXobject): ======= # 7227f59755bd6f9d2f94518a5c47562f5f21dc4a1ba1c47a1633acb2a08e0b91 >>>>>>> 8c42628fe (remove NXtransformations from NXcoordinate_system) +<<<<<<< HEAD >>>>>>> 7178a95ca (remove NXtransformations from NXcoordinate_system) +======= +======= +# e3d5958221798a09e18e91f457264204729d056cde70504cb02ea4b50b32ac1b +>>>>>>> 05529f919 (change to NXcoordinate_system_set, use NXfit in NXxps) +>>>>>>> 5e7c2dec7 (change to NXcoordinate_system_set, use NXfit in NXxps) # # # +# +<<<<<<< HEAD +# Description of coordinate system specific to the setup and the measurement +# geometry. +>>>>>>> 8c42628fe (remove NXtransformations from NXcoordinate_system) +======= +# Description of one or more coordinate systems that are specific to the setup +# and the measurement geometry. +>>>>>>> 05529f919 (change to NXcoordinate_system_set, use NXfit in NXxps) +>>>>>>> 5e7c2dec7 (change to NXcoordinate_system_set, use NXfit in NXxps) # # # diff --git a/contributed_definitions/nyaml/NXxps.yaml b/contributed_definitions/nyaml/NXxps.yaml index c15d457deb..fc6619c16a 100644 --- a/contributed_definitions/nyaml/NXxps.yaml +++ b/contributed_definitions/nyaml/NXxps.yaml @@ -242,52 +242,30 @@ NXxps(NXmpes): spec: ISO 18115-1:2023 term: 3.29 url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.29 - label: - data(NXdata): + (NXfit): doc: | - Input data and results of the fit. - input_dependent(NX_NUMBER): - unit: NX_ANY - doc: | - Dependent variable for this fit procedure. - - This could be a link to entry/data/data. - input_independent(NX_NUMBER): - unit: NX_ANY - doc: | - Independent variable for this fit procedure. - - This could be a link to entry/data/energy. - envelope(NX_NUMBER): - residual(NX_NUMBER): - exists: recommended - peakPEAK(NXpeak): + Description of one peak fit. This is meant to be used for a peak fit in + _one_ XPS region. As an eexample, this could be used to describe the + fitting of one measured C 1s spectrum. label: - data(NXdata): - position(NX_NUMBER): + region(NX_NUMBER): + unit: NX_ENERGY + peak_PEAK(NXpeak): + label: + lineshape: + position: unit: NX_ENERGY - doc: | - This could be a link to entry/data/energy. - intensity(NX_NUMBER): + intensity: doc: - | - Intensity values of the fitted function at each energy in the position field. + Intensity/count values at each energy in the position field. - | xref: spec: ISO 18115-1:2023 term: 3.15 url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.15 - function(NXfit_function): - exists: recommended - description: - formula: + width(NX_NUMBER): exists: recommended - area(NXfit_parameter): - exists: optional - doc: | - Area of the peak. - width(NXfit_parameter): - exists: optional doc: - | Width of a peak at a defined fraction of the peak height. @@ -300,41 +278,27 @@ NXxps(NXmpes): spec: ISO 18115-1:2023 term: 3.28 url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.28 - value: - unit: NX_ENERGY - position(NXfit_parameter): - exists: optional - doc: | - Position of the peak on the energy axis. - value: - unit: NX_ENERGY - total_area: - exists: recommended + total_area: + exists: recommended + doc: + - | + Total area under the peak after background removal. + - | + xref: + spec: ISO 18115-1:2023 + term: 3.16 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.16 + background_BACKGROUND(NXfit_background): doc: - | Total area under the peak after background removal. - | xref: spec: ISO 18115-1:2023 - term: 3.16 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.16 - backgroundBACKGROUND(NXfit_background): - doc: - - | - Functional form of the fitted XPS background. - - | - xref: - spec: ISO 18115-1:2023 - term: 3.21 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.21 - label: - exists: recommended - data(NXdata): - position(NX_NUMBER): - unit: NX_ENERGY - intensity(NX_NUMBER): - function(NXfit_function): - exists: recommended + term: 3.21 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.21 + label: + exists: recommended description: enumeration: linear: @@ -356,34 +320,26 @@ NXxps(NXmpes): other: doc: | In case none of the enumeration items apply, description should be _other_ - and the functional form of the background should be given by the `formula` - field. - formula: - exists: recommended - global_fit_function(NXfit_function): - exists: recommended - description: - exists: recommended - formula: + and the functional form of the background should be given by NXcollection. + position: + unit: NX_ENERGY + intensity: + fitting_method: exists: recommended - error_function(NXfit_function): - exists: recommended - description: + envelope(NX_NUMBER): exists: recommended - formula: + figure_of_merit_METRIC(NX_NUMBER): exists: recommended - figure_of_meritMETRIC(NX_NUMBER): - exists: recommended - \@metric: - relative_concentration(NX_FLOAT): - unit: NX_ANY - doc: | - Atomic concentration of each species defined by one peak in the peak model. - This should be an array with the indices pointing to the individual peaks - (i.e, peak_0, peak_1, etc.) + \@metric: + relative_concentration(NX_FLOAT): + unit: NX_ANY + doc: | + Atomic concentration of each species defined by one peak in the peak model. + This should be an array with the indices pointing to the individual peaks + (i.e, peak_0, peak_1, etc.) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 04421486bc5dffb01865fb8e056d77e5f5157304a3bc3ab9024c8ad160fe21e6 +# 2014f7027d3a4cee74004585b9831056092d2b06fbfb85b4d46641c5d7cf6390 # # # + + + + + The number of repetitions for the repeated parameters. + + + + + This describes a fit function to be used inside an NXfit instance. + + + + This should be a python parsable function. + Here we should provide which keywords are available + and a BNF of valid grammar. + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXfit_repeated_parameter.nxdl.xml b/contributed_definitions/NXfit_repeated_parameter.nxdl.xml new file mode 100644 index 0000000000..8debfa37ae --- /dev/null +++ b/contributed_definitions/NXfit_repeated_parameter.nxdl.xml @@ -0,0 +1,66 @@ + + + + + + + + The number of parameter repetitions. + + + + + A repeated parameter for a fit function. + This would typically be the independent variable in a fit. + + + + The name of the parameter. + + + + + A description of what this parameter represents. + + + + + A unit array associating a unit with each parameter. + The first element should be equal to values/@unit. + The values should be SI interpretable standard units + with common prefixes (e.g. mikro, nano etc.) or their + short-hand notation (e.g. nm, mm, kHz etc.). + + + + + + + + The value of the parameter. + + + + + + diff --git a/contributed_definitions/NXfit_single_parameter.nxdl.xml b/contributed_definitions/NXfit_single_parameter.nxdl.xml new file mode 100644 index 0000000000..3d247ccdc1 --- /dev/null +++ b/contributed_definitions/NXfit_single_parameter.nxdl.xml @@ -0,0 +1,55 @@ + + + + + + A single parameter for a fit function. + This would typically be a variable that + is optimized in a fit. + + + + The name of the parameter. + + + + + A description of what this parameter represents. + + + + + The value of the parameter. + + + + + The minimal value of the parameter. + + + + + The maximal value of the parameter. + + + diff --git a/contributed_definitions/nyaml/NXfit_function.yaml b/contributed_definitions/nyaml/NXfit_function.yaml new file mode 100644 index 0000000000..a7d2454ca2 --- /dev/null +++ b/contributed_definitions/nyaml/NXfit_function.yaml @@ -0,0 +1,81 @@ +category: base +doc: | + This describes a fit function to be used inside an NXfit instance. +symbols: + n_repetitions: | + The number of repetitions for the repeated parameters. +type: group +NXfitfunction(NXobject): + formula(NX_CHAR): + doc: | + This should be a python parsable function. + Here we should provide which keywords are available + and a BNF of valid grammar. + (NXfit_single_parameter): + (NXfit_repeated_parameter): + parameter_units: + dimensions: + rank: 1 + dim: [[1, n_repetitions]] + values(NX_NUMBER): + dimensions: + rank: 1 + dim: [[1, n_repetitions]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# d83f7d658d8a45d2dc6c4c5cab91a69ab29f7b64eabebefed739a0bc5ffe4570 +# +# +# +# +# +# +# +# The number of repetitions for the repeated parameters. +# +# +# +# +# This describes a fit function to be used inside an NXfit instance. +# +# +# +# This should be a python parsable function. +# Here we should provide which keywords are available +# and a BNF of valid grammar. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXfit_repeated_parameter.yaml b/contributed_definitions/nyaml/NXfit_repeated_parameter.yaml new file mode 100644 index 0000000000..2a931756b5 --- /dev/null +++ b/contributed_definitions/nyaml/NXfit_repeated_parameter.yaml @@ -0,0 +1,101 @@ +category: base +doc: | + A repeated parameter for a fit function. + This would typically be the independent variable in a fit. +symbols: + n_repetitions: | + The number of parameter repetitions. +type: group +NXfit_repeated_parameter(NXobject): + name(NX_CHAR): + doc: | + The name of the parameter. + description(NX_CHAR): + doc: | + A description of what this parameter represents. + parameter_units(NX_CHAR): + doc: | + A unit array associating a unit with each parameter. + The first element should be equal to values/@unit. + The values should be SI interpretable standard units + with common prefixes (e.g. mikro, nano etc.) or their + short-hand notation (e.g. nm, mm, kHz etc.). + dimensions: + rank: 1 + dim: [[1, n_repetitions]] + values(NX_NUMBER): + unit: NX_ANY + doc: | + The value of the parameter. + dimensions: + rank: 1 + dim: [[1, n_repetitions]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 31c7e1de12aaeb0badc37be7cd26889bdd924167c58e591c8fd9aea2d6419dd3 +# +# +# +# +# +# +# +# The number of parameter repetitions. +# +# +# +# +# A repeated parameter for a fit function. +# This would typically be the independent variable in a fit. +# +# +# +# The name of the parameter. +# +# +# +# +# A description of what this parameter represents. +# +# +# +# +# A unit array associating a unit with each parameter. +# The first element should be equal to values/@unit. +# The values should be SI interpretable standard units +# with common prefixes (e.g. mikro, nano etc.) or their +# short-hand notation (e.g. nm, mm, kHz etc.). +# +# +# +# +# +# +# +# The value of the parameter. +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXfit_single_parameter.yaml b/contributed_definitions/nyaml/NXfit_single_parameter.yaml new file mode 100644 index 0000000000..d7370eaf68 --- /dev/null +++ b/contributed_definitions/nyaml/NXfit_single_parameter.yaml @@ -0,0 +1,83 @@ +category: base +doc: | + A single parameter for a fit function. + This would typically be a variable that + is optimized in a fit. +type: group +NXfit_single_parameter(NXobject): + name(NX_CHAR): + doc: | + The name of the parameter. + description(NX_CHAR): + doc: | + A description of what this parameter represents. + value(NX_NUMBER): + unit: NX_ANY + doc: | + The value of the parameter. + min_value(NX_NUMBER): + unit: NX_ANY + doc: | + The minimal value of the parameter. + max_value(NX_NUMBER): + unit: NX_ANY + doc: | + The maximal value of the parameter. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 8b3465bf8c95d77f2873598fbfb127a3d896568739ac89c8e84934bd851f1b81 +# +# +# +# +# +# A single parameter for a fit function. +# This would typically be a variable that +# is optimized in a fit. +# +# +# +# The name of the parameter. +# +# +# +# +# A description of what this parameter represents. +# +# +# +# +# The value of the parameter. +# +# +# +# +# The minimal value of the parameter. +# +# +# +# +# The maximal value of the parameter. +# +# +# From 9bc7da83516778fdd2526fdd23e1481db14f8f8c Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 15 Feb 2024 17:23:21 +0100 Subject: [PATCH 0874/1012] use NXfit_function for peaks and backgrounds --- .../NXfit_background.nxdl.xml | 59 +++----- .../NXfit_function.nxdl.xml | 7 +- contributed_definitions/NXpeak.nxdl.xml | 82 +++++------ .../nyaml/NXfit_background.yaml | 103 +++++-------- .../nyaml/NXfit_function.yaml | 22 +-- contributed_definitions/nyaml/NXpeak.yaml | 138 ++++++++++++++---- 6 files changed, 227 insertions(+), 184 deletions(-) diff --git a/contributed_definitions/NXfit_background.nxdl.xml b/contributed_definitions/NXfit_background.nxdl.xml index 0b2e73f5cb..edc1dc6475 100644 --- a/contributed_definitions/NXfit_background.nxdl.xml +++ b/contributed_definitions/NXfit_background.nxdl.xml @@ -26,15 +26,15 @@ The symbols used in the schema to specify e.g. dimensions of arrays. - + - Number of discretization points at which the functional form of the + Number of discretization points at which the functional form of the background has been evaluated. - Description of background for an NXpeak_model. + Description of the background for an NXfit model. @@ -42,40 +42,27 @@ the background represents/identifies. - - - Is the background described analytically via a functional form - or is it empirically defined via measured/reported - intensity/counts as a function of an independent variable. - - Relevant details of the functional form shall be described through - background_parameters. - - - - - In the case of an empirical description of the background, - this array holds the position values for the independent variable. - - - - - - - - In the case of an empirical description of the background, - this array holds the intensity/count values at each position. - - - - - - + + + + This axis holds the position values for the independent variable. + + + + + + + + This array holds the intensity/count values at each position. + + + + + + + - In the case of an analytical description (or if description is other), - this holds parameter of the functional form. - For example in the case of Gaussians mu, sigma, and cut-off values are - relevant parameters. + The functional form of the background. diff --git a/contributed_definitions/NXfit_function.nxdl.xml b/contributed_definitions/NXfit_function.nxdl.xml index 66b357c437..b91bef7119 100644 --- a/contributed_definitions/NXfit_function.nxdl.xml +++ b/contributed_definitions/NXfit_function.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + @@ -32,6 +32,11 @@ This describes a fit function to be used inside an NXfit instance. + + + Description of this fit function. + + This should be a python parsable function. diff --git a/contributed_definitions/NXpeak.nxdl.xml b/contributed_definitions/NXpeak.nxdl.xml index 996c7e9113..9b905d834a 100644 --- a/contributed_definitions/NXpeak.nxdl.xml +++ b/contributed_definitions/NXpeak.nxdl.xml @@ -26,7 +26,7 @@ The symbols used in the schema to specify e.g. dimensions of arrays. - + Number of discretization points at which the functional form of the peak has been evaluated. @@ -43,54 +43,40 @@ the peak represents/identifies. - - - Is the peak described analytically via a functional form - or is it empirically defined via measured/reported - intensity/counts as a function of an independent variable? - - If the functional form is not empirical or Gaussians, users - should enter other for the description and add relevant details - in the NXcollection. - - - - - - - - - - - - Human-readable descritpion of the lineshape used for the peak if it does - not fit into the enumeration given in `lineshape`. - - - - - In the case of an empirical description of the peak, - this array holds the position values for the independent variable. - - - - - - - - In the case of an empirical description of the peak, - this array holds the intensity/count values at each position. - - - - - - + + + + This axis holds the position values for the independent variable. + + + + + + + + This array holds the intensity/count values at each position. + + + + + + + - In the case of an analytical description (or if description is other) this - collection holds parameter of the functional form. - For example in the case of Gaussians mu, sigma, and cut-off values are - relevant parameters. + The functional form of the peak. This could be a Gaussian, Lorentzian, + Voigt, etc. + + + + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXfit_background.yaml b/contributed_definitions/nyaml/NXfit_background.yaml index 1967cce4c2..e0d1695984 100644 --- a/contributed_definitions/nyaml/NXfit_background.yaml +++ b/contributed_definitions/nyaml/NXfit_background.yaml @@ -1,10 +1,10 @@ category: base doc: | - Description of background for an NXpeak_model. + Description of the background for an NXfit model. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. - n_support: | + n_values: | Number of discretization points at which the functional form of the background has been evaluated. type: group @@ -13,35 +13,23 @@ NXfit_background(NXobject): doc: | Human-readable label which specifies which concept/entity the background represents/identifies. - description(NX_CHAR): + data(NXdata): + position(NX_NUMBER): + unit: NX_ANY + doc: | + This axis holds the position values for the independent variable. + dim: (n_values,) + intensity(NX_NUMBER): + unit: NX_ANY + doc: | + This array holds the intensity/count values at each position. + dim: (n_values,) + function(NXfit_function): doc: | - Is the background described analytically via a functional form - or is it empirically defined via measured/reported - intensity/counts as a function of an independent variable. - - Relevant details of the functional form shall be described through - background_parameters. - position(NX_NUMBER): - unit: NX_ANY - doc: | - In the case of an empirical description of the background, - this array holds the position values for the independent variable. - dim: (n_support,) - intensity(NX_NUMBER): - unit: NX_ANY - doc: | - In the case of an empirical description of the background, - this array holds the intensity/count values at each position. - dim: (n_support,) - background_parameters(NXparameters): - doc: | - In the case of an analytical description (or if description is other), - this holds parameter of the functional form. - For example in the case of Gaussians mu, sigma, and cut-off values are - relevant parameters. + The functional form of the background. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# ab225b7c9634039e078d5ba44500c59f05958c63b16b4e3beb5c171d47fe65b1 +# b6f5a3c03e35dc263bed1eb13cee68861fe4c157834158d86fe6dc3921cfd442 # # # -# +# # # # @@ -58,6 +57,11 @@ NXfitfunction(NXobject): # # This describes a fit function to be used inside an NXfit instance. # +# +# +# Description of this fit function. +# +# # # # This should be a python parsable function. diff --git a/contributed_definitions/nyaml/NXpeak.yaml b/contributed_definitions/nyaml/NXpeak.yaml index b9f76bc5e2..e7d8fc8493 100644 --- a/contributed_definitions/nyaml/NXpeak.yaml +++ b/contributed_definitions/nyaml/NXpeak.yaml @@ -5,7 +5,7 @@ doc: | symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. - n_support: | + n_values: | Number of discretization points at which the functional form of the peak has been evaluated. type: group @@ -14,31 +14,117 @@ NXpeak(NXobject): doc: | Human-readable label which specifies which concept/entity the peak represents/identifies. - lineshape: + data(NXdata): + position(NX_NUMBER): + unit: NX_ANY + doc: | + This axis holds the position values for the independent variable. + dim: (n_values,) + intensity(NX_NUMBER): + unit: NX_ANY + doc: | + This array holds the intensity/count values at each position. + dim: (n_values,) + function(NXfit_function): doc: | - Is the peak described analytically via a functional form - or is it empirically defined via measured/reported - intensity/counts as a function of an independent variable? - - If the functional form is not empirical or Gaussians, users - should enter other for the description and add relevant details - in the NXcollection. - enumeration: [empirical, gaussian, lorentzian, voigt, other] - position(NX_NUMBER): - doc: | - In the case of an empirical description of the peak, - this array holds the position values for the independent variable. - unit: NX_ANY - dim: (n_support,) - intensity(NX_NUMBER): - doc: | - In the case of an empirical description of the peak, - this array holds the intensity/count values at each position. + The functional form of the peak. This could be a Gaussian, Lorentzian, + Voigt, etc. + (NXfit_repeated_parameter): + parameter_units: + dim: (n_values,) + values(NX_NUMBER): + dim: (n_values,) + total_area(NX_NUMBER): unit: NX_ANY - dim: (n_support,) - (NXparameters): doc: | - In the case of an analytical description (or if description is other) this - collection holds parameter of (and eventually) the functional form. - For example in the case of Gaussians mu, sigma, cut-off values, - and background intensity are relevant parameter. + Total area under the curve. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 815ff4497ec5dba04051269bb6adfbe6dd2bec94c55ee972ffe058bedf4053ce +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of discretization points at which the functional form of the peak +# has been evaluated. +# +# +# +# +# Base class for describing a spectral peak, its functional form, and support values +# (i.e., the discretization (points) at which the function has been evaluated). +# +# +# +# Human-readable label which specifies which concept/entity +# the peak represents/identifies. +# +# +# +# +# +# This axis holds the position values for the independent variable. +# +# +# +# +# +# +# +# This array holds the intensity/count values at each position. +# +# +# +# +# +# +# +# +# The functional form of the peak. This could be a Gaussian, Lorentzian, +# Voigt, etc. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Total area under the curve. +# +# +# From 8f3856a3fd62aa5c2988a0f4ec0cab3973d70473 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 15 Feb 2024 17:25:05 +0100 Subject: [PATCH 0875/1012] use NXdata in NXfit --- contributed_definitions/NXfit.nxdl.xml | 127 ++++++------- contributed_definitions/nyaml/NXfit.yaml | 225 ++++++++++------------- 2 files changed, 147 insertions(+), 205 deletions(-) diff --git a/contributed_definitions/NXfit.nxdl.xml b/contributed_definitions/NXfit.nxdl.xml index 1f1839d4b7..495f5f25a2 100644 --- a/contributed_definitions/NXfit.nxdl.xml +++ b/contributed_definitions/NXfit.nxdl.xml @@ -40,14 +40,44 @@ Human-readable label for this fit procedure. - + - Subset of the independent axis for this fit procedure. + Input data and results of the fit. - - - - + + + Independent axis for this fit procedure. + + + + + + + + Dependent axis for this fit procedure. + + + + + + + + Resulting envelope of all NXpeak instances. + Should have the same dimension as the `position` axes of the individual peaks. + + + + + + + + Difference between the envelope and the data to be fitted. + + + + + + One spectral peak of the peak model. @@ -55,8 +85,8 @@ - Total area under the curve. (can also be used for the total area minus any - background values.) + Total area under the curve (can also be used for the total area minus any + background values). @@ -64,7 +94,7 @@ Relative sensitivity for this peak, to be used for quantification in an NXprocess. - As an example, in X-ray spectroscopy could depend on the energy scale3 + As an example, in X-ray spectroscopy could depend on the energy scale (see position), the ionization cross section, and the element probed. @@ -75,45 +105,9 @@ The relative area can simply be derived by dividing the total_area by the total area of all peaks or by a more complicated method (e.g., by additionally dividing by the relative sensitivity factors). Details shall - be given in fitting_method + be given in fitting_method. - - - Constraint on the minimum and maximum area of this peak. - - - - - - Link to a peak the area constraint depends on. - - - - - - Constraint on the minimum and maximum width of this peak. - - - - - - Link to a peak the width constraint depends on. - - - - - - Constraint on the minimum and maximum position of this peak on the abscissa. - - - - - - Link to a peak the position constraint depends on. - - - @@ -122,27 +116,22 @@ so on. - + - Description of the method used to optimize the parameters during peak fitting. - Examples: - - least squares - - non-linear least squares - - Levenberg-Marquardt algorithm (damped least-squares) - - linear regression - - Bayesian linear regression - - - - - Resulting envelope of all NXpeak instances. - - Should have the same dimension as the `position` axes of the individual peaks. + Function used to optimize the parameters during peak fitting. - - - - + + + Description of the method used to optimize the parameters during peak fitting. + Examples: + - least squares + - non-linear least squares + - Levenberg-Marquardt algorithm (damped least-squares) + - linear regression + - Bayesian linear regression + + + Figure-of-merit to determine the goodness of fit, i.e., how well the peak model @@ -160,12 +149,4 @@ - - - Difference between the envelope and the data to be fitted. - - - - - diff --git a/contributed_definitions/nyaml/NXfit.yaml b/contributed_definitions/nyaml/NXfit.yaml index e0b3ddbdac..e5e7a0d19e 100644 --- a/contributed_definitions/nyaml/NXfit.yaml +++ b/contributed_definitions/nyaml/NXfit.yaml @@ -11,11 +11,30 @@ NXfit(NXobject): label: doc: | Human-readable label for this fit procedure. - region(NX_NUMBER): - unit: NX_ANY + data(NXdata): doc: | - Subset of the independent axis for this fit procedure. - dim: (n_points,) + Input data and results of the fit. + input_dependent(NX_NUMBER): + unit: NX_ANY + doc: | + Independent axis for this fit procedure. + dim: (n_points,) + input_independent(NX_NUMBER): + unit: NX_ANY + doc: | + Dependent axis for this fit procedure. + dim: (n_points,) + envelope(NX_NUMBER): + unit: NX_ANY + doc: | + Resulting envelope of all NXpeak instances. + Should have the same dimension as the `position` axes of the individual peaks. + dim: (n_points,) + residual(NX_NUMBER): + unit: NX_ANY + doc: | + Difference between the envelope and the data to be fitted. + dim: (n_points,) peak_PEAK(NXpeak): doc: | One spectral peak of the peak model. @@ -23,15 +42,15 @@ NXfit(NXobject): total_area(NX_NUMBER): unit: NX_ANY doc: | - Total area under the curve. (can also be used for the total area minus any - background values.) + Total area under the curve (can also be used for the total area minus any + background values). relative_sensitivity_factor(NX_NUMBER): unit: NX_UNITLESS doc: | Relative sensitivity for this peak, to be used for quantification in an NXprocess. - As an example, in X-ray spectroscopy could depend on the energy scale3 + As an example, in X-ray spectroscopy could depend on the energy scale (see position), the ionization cross section, and the element probed. relative_area(NX_NUMBER): unit: NX_ANY @@ -41,58 +60,24 @@ NXfit(NXobject): The relative area can simply be derived by dividing the total_area by the total area of all peaks or by a more complicated method (e.g., by additionally dividing by the relative sensitivity factors). Details shall - be given in fitting_method - area_constraint(NXparameters): - doc: | - Constraint on the minimum and maximum area of this peak. - minimal_value(NX_NUMBER): - unit: NX_ANY - maximal_value(NX_NUMBER): - unit: NX_ANY - depends_on: - doc: | - Link to a peak the area constraint depends on. - width_constraint(NXparameters): - doc: | - Constraint on the minimum and maximum width of this peak. - minimal_value(NX_NUMBER): - unit: NX_ANY - maximal_value(NX_NUMBER): - unit: NX_ANY - depends_on: - doc: | - Link to a peak the width constraint depends on. - position_constraint(NXparameters): - doc: | - Constraint on the minimum and maximum position of this peak on the abscissa. - minimal_value(NX_NUMBER): - unit: NX_ANY - maximal_value(NX_NUMBER): - unit: NX_ANY - depends_on: - doc: | - Link to a peak the position constraint depends on. + be given in fitting_method. background_BACKGROUND(NXfit_background): doc: | One fitted background (functional, position, and intensities) of the peak fit. It is envisioned that peaks are labeled as background_0, background_1, and so on. - fitting_method: - doc: | - Description of the method used to optimize the parameters during peak fitting. - Examples: - - least squares - - non-linear least squares - - Levenberg-Marquardt algorithm (damped least-squares) - - linear regression - - Bayesian linear regression - envelope(NX_NUMBER): - unit: NX_ANY + fit_function(NXfit_function): doc: | - Resulting envelope of all NXpeak instances. - - Should have the same dimension as the `position` axes of the individual peaks. - dim: (n_points,) + Function used to optimize the parameters during peak fitting. + description: + doc: | + Description of the method used to optimize the parameters during peak fitting. + Examples: + - least squares + - non-linear least squares + - Levenberg-Marquardt algorithm (damped least-squares) + - linear regression + - Bayesian linear regression figure_of_merit_METRIC(NX_NUMBER): unit: NX_UNITLESS doc: | @@ -107,14 +92,9 @@ NXfit(NXobject): - :math:`\Chi^2`, the standard deviation of the residuals - reduced :math:`\Chi^2`:, :math:`\Chi^2`: per degree of freedom - :math:`R^2`, the coefficient of determination - residual(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Difference between the envelope and the data to be fitted. - dim: (n_points,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 332a87f3d66a159e0249e86266ae53783011b8e4384bb6bcd21ebb8bdcdb09cb +# 288fe77153aab723ed39dd80b316c61aa6cfcc3355255a81614dcbda6bd5733e # # # + + + Number of independent data axes to be fitted (for multidimensional fit.) + + The number of parameter repetitions. @@ -52,7 +57,7 @@ short-hand notation (e.g. nm, mm, kHz etc.). - + @@ -60,7 +65,7 @@ The value of the parameter. - + diff --git a/contributed_definitions/NXpeak.nxdl.xml b/contributed_definitions/NXpeak.nxdl.xml index 9b905d834a..95427e31b3 100644 --- a/contributed_definitions/NXpeak.nxdl.xml +++ b/contributed_definitions/NXpeak.nxdl.xml @@ -32,6 +32,11 @@ has been evaluated. + + + Number of independent data axes to be fitted (for multidimensional fit.) + + Base class for describing a spectral peak, its functional form, and support values @@ -48,16 +53,16 @@ This axis holds the position values for the independent variable. - - + + This array holds the intensity/count values at each position. - - + + @@ -68,6 +73,7 @@ +<<<<<<< HEAD @@ -75,6 +81,15 @@ +======= + + + + + + + +>>>>>>> 3dc34dd60 (make NXfit, NXpeak multi-dimensional) diff --git a/contributed_definitions/nyaml/NXfit.yaml b/contributed_definitions/nyaml/NXfit.yaml index 9bb2080223..fd7ccf7c12 100644 --- a/contributed_definitions/nyaml/NXfit.yaml +++ b/contributed_definitions/nyaml/NXfit.yaml @@ -6,6 +6,8 @@ symbols: The symbols used in the schema to specify e.g. dimensions of arrays. n_points: | Number of discretization points inside the fitting region. + n_independent: | + Number of independent axes for this fit procedure. type: group NXfit(NXobject): label: @@ -25,20 +27,20 @@ NXfit(NXobject): doc: | Independent axis for this fit procedure. dimensions: - dim: [[1, n_points]] + dim: [[n_independent, n_points]] envelope(NX_NUMBER): unit: NX_ANY doc: | Resulting envelope of all NXpeak instances. Should have the same dimension as the `position` axes of the individual peaks. dimensions: - dim: [[1, n_points]] + dim: [[n_independent, n_points]] residual(NX_NUMBER): unit: NX_ANY doc: | Difference between the envelope and the data to be fitted. dimensions: - dim: [[1, n_points]] + dim: [[n_independent, n_points]] peakPEAK(NXpeak): doc: | One spectral peak of the peak model. @@ -98,7 +100,7 @@ NXfit(NXobject): - :math:`R^2`, the coefficient of determination # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 3d809910323b73fa6031b25ffa9ea14a685ca61427cb99e400b526f6eef86465 +# 7d9a2379ad4bcb14ba507b3b4583cc47597dc181f585e241f288a5a8c25f4079 # # # # # +# +# +# Number of independent data axes to be fitted (for multidimensional fit.) +# +# # # # The number of parameter repetitions. @@ -87,7 +94,7 @@ NXfit_repeated_parameter(NXobject): # short-hand notation (e.g. nm, mm, kHz etc.). # # -# +# # # # @@ -95,7 +102,7 @@ NXfit_repeated_parameter(NXobject): # The value of the parameter. # # -# +# # # # diff --git a/contributed_definitions/nyaml/NXpeak.yaml b/contributed_definitions/nyaml/NXpeak.yaml index 08d8c71507..5867cd8f42 100644 --- a/contributed_definitions/nyaml/NXpeak.yaml +++ b/contributed_definitions/nyaml/NXpeak.yaml @@ -8,6 +8,8 @@ symbols: n_values: | Number of discretization points at which the functional form of the peak has been evaluated. + n_features: | + Number of independent data axes to be fitted (for multidimensional fit.) type: group NXpeak(NXobject): label: @@ -20,13 +22,13 @@ NXpeak(NXobject): doc: | This axis holds the position values for the independent variable. dimensions: - dim: [[1, n_values]] + dim: [[n_features, n_values]] intensity(NX_NUMBER): unit: NX_ANY doc: | This array holds the intensity/count values at each position. dimensions: - dim: [[1, n_values]] + dim: [[n_features, n_values]] function(NXfit_function): doc: | The functional form of the peak. This could be a Gaussian, Lorentzian, @@ -34,10 +36,10 @@ NXpeak(NXobject): (NXfit_repeated_parameter): parameter_units: dimensions: - dim: [[1, n_values]] + dim: [[n_features, n_values]] values(NX_NUMBER): dimensions: - dim: [[1, n_values]] + dim: [[n_features, n_values]] total_area(NX_NUMBER): unit: NX_ANY doc: | @@ -79,6 +81,11 @@ NXpeak(NXobject): # has been evaluated. # # +# +# +# Number of independent data axes to be fitted (for multidimensional fit.) +# +# # # # Base class for describing a spectral peak, its functional form, and support values @@ -95,16 +102,16 @@ NXpeak(NXobject): # # This axis holds the position values for the independent variable. # -# -# +# +# # # # # # This array holds the intensity/count values at each position. # -# -# +# +# # # # @@ -115,13 +122,13 @@ NXpeak(NXobject): # # # -# -# +# +# # # # -# -# +# +# # # # From 15d4c513b71934fa7685b9de657acf48c6937204 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 10 Apr 2024 14:22:11 +0200 Subject: [PATCH 0886/1012] redefine XPS coordinate system, small changes to XPS peak fitting --- contributed_definitions/NXfit.nxdl.xml | 2 +- contributed_definitions/NXxps.nxdl.xml | 26 ++++++++++---- contributed_definitions/nyaml/NXfit.yaml | 6 ++-- contributed_definitions/nyaml/NXxps.yaml | 44 ++++++++++++++++++------ 4 files changed, 57 insertions(+), 21 deletions(-) diff --git a/contributed_definitions/NXfit.nxdl.xml b/contributed_definitions/NXfit.nxdl.xml index 5906d49353..072e074407 100644 --- a/contributed_definitions/NXfit.nxdl.xml +++ b/contributed_definitions/NXfit.nxdl.xml @@ -137,7 +137,7 @@ - + Figure-of-merit to determine the goodness of fit, i.e., how well the peak model fits the measured observations. diff --git a/contributed_definitions/NXxps.nxdl.xml b/contributed_definitions/NXxps.nxdl.xml index 13d70c7d3e..77d30cedd0 100644 --- a/contributed_definitions/NXxps.nxdl.xml +++ b/contributed_definitions/NXxps.nxdl.xml @@ -396,7 +396,8 @@ ======= - Should be a link to the XPS base coordinate system, e.g. + This could either point to the beam coordinate system (.) or to another transformation + that transforms from the beam coordinate system to the XPS base coordinate system at /entry/instrument/xps_coordinate_system. @@ -456,7 +457,6 @@ - @@ -475,8 +475,13 @@ - - + + + + Area of the peak. + + + Width of a peak at a defined fraction of the peak height. @@ -488,7 +493,14 @@ .. _3.28: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.28 - + + + + + Position of the peak on the energy axis. + + + @@ -676,14 +688,14 @@ - + >>>>>>> c47edfd66 (use new peak fitting in NXxps) - + diff --git a/contributed_definitions/nyaml/NXfit.yaml b/contributed_definitions/nyaml/NXfit.yaml index fd7ccf7c12..628a13a546 100644 --- a/contributed_definitions/nyaml/NXfit.yaml +++ b/contributed_definitions/nyaml/NXfit.yaml @@ -84,7 +84,7 @@ NXfit(NXobject): - Levenberg-Marquardt algorithm (damped least-squares) - linear regression - Bayesian linear regression - figure_of_merit_METRIC(NX_NUMBER): + figure_of_meritMETRIC(NX_NUMBER): unit: NX_UNITLESS doc: | Figure-of-merit to determine the goodness of fit, i.e., how well the peak model @@ -100,7 +100,7 @@ NXfit(NXobject): - :math:`R^2`, the coefficient of determination # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 7d9a2379ad4bcb14ba507b3b4583cc47597dc181f585e241f288a5a8c25f4079 +# cf6ee20338952c6682c954044c19c61bbb845dc7a200722d6ba5285c7d5b39fd # # # - A single parameter for a fit function. + A parameter for a fit function. This would typically be a variable that is optimized in a fit. diff --git a/contributed_definitions/NXfit_repeated_parameter.nxdl.xml b/contributed_definitions/NXfit_repeated_parameter.nxdl.xml deleted file mode 100644 index 30a94ca2fa..0000000000 --- a/contributed_definitions/NXfit_repeated_parameter.nxdl.xml +++ /dev/null @@ -1,73 +0,0 @@ - - - - - - - - Number of independent data axes to be fitted (for multidimensional fit.) - - - - - The number of parameter repetitions. - - - - - A repeated parameter for a fit function. - This would typically be the independent variable in a fit. - - - - The name of the parameter. - - - - - A description of what this parameter represents. - - - - - A unit array associating a unit with each parameter. - The first element should be equal to values/@unit. - The values should be SI interpretable standard units - with common prefixes (e.g. micro, nano etc.) or their - short-hand notation (e.g. nm, mm, kHz etc.). - - - - - - - - - The value of the parameter. - - - - - - - diff --git a/contributed_definitions/nyaml/NXfit_function.yaml b/contributed_definitions/nyaml/NXfit_function.yaml index bafd6c4c4a..af78bdef96 100644 --- a/contributed_definitions/nyaml/NXfit_function.yaml +++ b/contributed_definitions/nyaml/NXfit_function.yaml @@ -14,15 +14,10 @@ NXfit_function(NXobject): This should be a python parsable function. Here we should provide which keywords are available and a BNF of valid grammar. - (NXfit_single_parameter): - (NXfit_repeated_parameter): - parameter_units: - dim: (n_repetitions,) - values(NX_NUMBER): - dim: (n_repetitions,) + (NXfit_parameter): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4ec712368140064f42f1a4a85f2a0f78c0bcf426f66bd79bc7489a25ba1feb96 +# 591fe709aafff712c070d9763389795e7aa7e7672eb2dd4cf9f0dac453c73b01 # # # # # -# A single parameter for a fit function. +# A parameter for a fit function. # This would typically be a variable that # is optimized in a fit. # diff --git a/contributed_definitions/nyaml/NXfit_repeated_parameter.yaml b/contributed_definitions/nyaml/NXfit_repeated_parameter.yaml deleted file mode 100644 index ef0162b1c3..0000000000 --- a/contributed_definitions/nyaml/NXfit_repeated_parameter.yaml +++ /dev/null @@ -1,110 +0,0 @@ -category: base -doc: | - A repeated parameter for a fit function. - This would typically be the independent variable in a fit. -symbols: - n_features: | - Number of independent data axes to be fitted (for multidimensional fit.) - n_repetitions: | - The number of parameter repetitions. -type: group -NXfit_repeated_parameter(NXobject): - name(NX_CHAR): - doc: | - The name of the parameter. - description(NX_CHAR): - doc: | - A description of what this parameter represents. - parameter_units(NX_CHAR): - doc: | - A unit array associating a unit with each parameter. - The first element should be equal to values/@unit. - The values should be SI interpretable standard units - with common prefixes (e.g. micro, nano etc.) or their - short-hand notation (e.g. nm, mm, kHz etc.). - dimensions: - rank: 2 - dim: [[1, n_features], [2, n_repetitions]] - values(NX_NUMBER): - unit: NX_ANY - doc: | - The value of the parameter. - dimensions: - rank: 2 - dim: [[1, n_features], [2, n_repetitions]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# c76fa7187e3daac2e28e64715cba39c85e2274da7ac40bdedbbb8f518c27bfc1 -# -# -# -# -# -# -# -# Number of independent data axes to be fitted (for multidimensional fit.) -# -# -# -# -# The number of parameter repetitions. -# -# -# -# -# A repeated parameter for a fit function. -# This would typically be the independent variable in a fit. -# -# -# -# The name of the parameter. -# -# -# -# -# A description of what this parameter represents. -# -# -# -# -# A unit array associating a unit with each parameter. -# The first element should be equal to values/@unit. -# The values should be SI interpretable standard units -# with common prefixes (e.g. micro, nano etc.) or their -# short-hand notation (e.g. nm, mm, kHz etc.). -# -# -# -# -# -# -# -# -# The value of the parameter. -# -# -# -# -# -# -# From 4eab35186709b8e097536ae4932ca7044b855f04 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 22 May 2024 11:21:33 +0200 Subject: [PATCH 0894/1012] fix dimensions in NXpeak and NXfit_background --- .../NXfit_background.nxdl.xml | 38 +++++----- .../NXfit_function.nxdl.xml | 23 +++--- .../NXfit_parameter.nxdl.xml | 9 ++- contributed_definitions/NXpeak.nxdl.xml | 34 +++++---- .../nyaml/NXfit_background.yaml | 74 +++++++++++-------- .../nyaml/NXfit_function.yaml | 44 +++++------ .../nyaml/NXfit_parameter.yaml | 20 ++--- contributed_definitions/nyaml/NXpeak.yaml | 64 +++++++++------- 8 files changed, 171 insertions(+), 135 deletions(-) diff --git a/contributed_definitions/NXfit_background.nxdl.xml b/contributed_definitions/NXfit_background.nxdl.xml index 124ca83194..5b45fa81e4 100644 --- a/contributed_definitions/NXfit_background.nxdl.xml +++ b/contributed_definitions/NXfit_background.nxdl.xml @@ -26,16 +26,10 @@ The symbols used in the schema to specify e.g. dimensions of arrays. - + - Number of discretization points at which the functional form of the - background has been evaluated. - - - - - Number of dependent variables to be fitted (for multidimensional/multivariate - fit.) + Rank of the dependent and independent data arrays (for + multidimensional/multivariate fit.) @@ -51,20 +45,30 @@ - This axis holds the position values for the independent variable. + Position values along one or more data dimensions (to hold the + values for the independent variable). - - + + + The ``position`` field must have the same rank (``dimRank``) + as the ``intensity`` field. Each individual dimension of ``position`` + must have the same number of points as the corresponding dimension in + the ``intensity`` field. + - This array holds the intensity/count values of the fitted background at each - position. + This array holds the intensity/count values of the fitted background + at each position. - - - + + + The ``intensity`` field must have the same rank (``dimRank``) + as the ``intensity`` field. Each individual dimension of ``position`` + must have the same number of points as the corresponding dimension in + the ``position`` field. + diff --git a/contributed_definitions/NXfit_function.nxdl.xml b/contributed_definitions/NXfit_function.nxdl.xml index f955349922..8e257ebf80 100644 --- a/contributed_definitions/NXfit_function.nxdl.xml +++ b/contributed_definitions/NXfit_function.nxdl.xml @@ -22,25 +22,24 @@ # For further information, see http://www.nexusformat.org --> - - - - The number of repetitions for the repeated parameters. - - - - This describes a fit function to be used inside an NXfit instance. + This describes a fit function that is used to fit data to any functional form. + + A fit function is used to describe a set of data :math:`y_k, k = 1 ... M`, which are collected as a function + of one or more independent variables :math:`x` at the points :math:`x_k`. The fit function :math:`f` describes + these data in an approximative way as :math:`y_k ≈ f(a_0, . . . a_n, x_k)`, where math:`a_i, i = 0 . . . n` are + the _fit parameters_ (which are stored in ``NXfit_parameters``). - Description of this fit function. + Human-readable description of this fit function. - + - This should be a python parsable function. - Here we should provide which keywords are available + Mathematical formula of the function, taking into account the ``NXfit_parameters``. + + This should be a python parsable function. Here we should provide which keywords are available and a BNF of valid grammar. diff --git a/contributed_definitions/NXfit_parameter.nxdl.xml b/contributed_definitions/NXfit_parameter.nxdl.xml index 6356532bc3..f8762232f5 100644 --- a/contributed_definitions/NXfit_parameter.nxdl.xml +++ b/contributed_definitions/NXfit_parameter.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + A parameter for a fit function. This would typically be a variable that @@ -39,17 +39,18 @@ - The value of the parameter. + The value of the parameter. After fitting, this would store the + optimized value. - The minimal value of the parameter. + The minimal value of the parameter, to be used as a constraint during fitting. - The maximal value of the parameter. + The maximal value of the parameter, to be used as a constraint during fitting. diff --git a/contributed_definitions/NXpeak.nxdl.xml b/contributed_definitions/NXpeak.nxdl.xml index 76c0096803..cbb2adcf6b 100644 --- a/contributed_definitions/NXpeak.nxdl.xml +++ b/contributed_definitions/NXpeak.nxdl.xml @@ -26,16 +26,10 @@ The symbols used in the schema to specify e.g. dimensions of arrays. - + - Number of discretization points at which the functional form of the peak - has been evaluated. - - - - - Number of dependent variables to be fitted (for multidimensional/multivariate - fit.) + Rank of the dependent and independent data arrays (for + multidimensional/multivariate fit.) @@ -52,19 +46,29 @@ - This axis holds the position values for the independent variable. + Position values along one or more data dimensions (to hold the + values for the independent variable). - - + + + The ``position`` field must have the same rank (``dimRank``) + as the ``intensity`` field. Each individual dimension of ``position`` + must have the same number of points as the corresponding dimension in + the ``intensity`` field. + This array holds the intensity/count values of the fitted peak at each position. - - - + + + The ``intensity`` field must have the same rank (``dimRank``) + as the ``intensity`` field. Each individual dimension of ``position`` + must have the same number of points as the corresponding dimension in + the ``position`` field. + diff --git a/contributed_definitions/nyaml/NXfit_background.yaml b/contributed_definitions/nyaml/NXfit_background.yaml index 280644795c..f988a8bfc6 100644 --- a/contributed_definitions/nyaml/NXfit_background.yaml +++ b/contributed_definitions/nyaml/NXfit_background.yaml @@ -4,12 +4,9 @@ doc: | symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. - n_points: | - Number of discretization points at which the functional form of the - background has been evaluated. - n_dependent: | - Number of dependent variables to be fitted (for multidimensional/multivariate - fit.) + dimRank: | + Rank of the dependent and independent data arrays (for + multidimensional/multivariate fit.) type: group NXfit_background(NXobject): label(NX_CHAR): @@ -20,24 +17,35 @@ NXfit_background(NXobject): position(NX_NUMBER): unit: NX_ANY doc: | - This axis holds the position values for the independent variable. + Position values along one or more data dimensions (to hold the + values for the independent variable). dimensions: - rank: 1 - dim: [[1, n_points]] + rank: dimRank + doc: | + The ``position`` field must have the same rank (``dimRank``) + as the ``intensity`` field. Each individual dimension of ``position`` + must have the same number of points as the corresponding dimension in + the ``intensity`` field. + dim: [] intensity(NX_NUMBER): unit: NX_ANY doc: | - This array holds the intensity/count values of the fitted background at each - position. + This array holds the intensity/count values of the fitted background + at each position. dimensions: - rank: 2 - dim: [[1, n_points], [2, n_dependent]] + rank: dimRank + doc: | + The ``intensity`` field must have the same rank (``dimRank``) + as the ``intensity`` field. Each individual dimension of ``position`` + must have the same number of points as the corresponding dimension in + the ``position`` field. + dim: [] function(NXfit_function): doc: | The functional form of the background. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 40a4baea832789983182312a5fa9e93729d6d09a5b424b65a4277a932dcc8a0d +# f2aa053cf2efec41fdae311ac6df33ac71072aeb03ff3d640b641c1e8b1f2be6 # # # # -# -# -# -# The number of repetitions for the repeated parameters. -# -# -# # -# This describes a fit function to be used inside an NXfit instance. +# This describes a fit function that is used to fit data to any functional form. +# +# A fit function is used to describe a set of data :math:`y_k, k = 1 ... M`, which are collected as a function +# of one or more independent variables :math:`x` at the points :math:`x_k`. The fit function :math:`f` describes +# these data in an approximative way as :math:`y_k ≈ f(a_0, . . . a_n, x_k)`, where math:`a_i, i = 0 . . . n` are +# the _fit parameters_ (which are stored in ``NXfit_parameters``). # # # -# Description of this fit function. +# Human-readable description of this fit function. # # -# +# # -# This should be a python parsable function. -# Here we should provide which keywords are available +# Mathematical formula of the function, taking into account the ``NXfit_parameters``. +# +# This should be a python parsable function. Here we should provide which keywords are available # and a BNF of valid grammar. # # diff --git a/contributed_definitions/nyaml/NXfit_parameter.yaml b/contributed_definitions/nyaml/NXfit_parameter.yaml index 1c3b0260a5..313e5a3cd0 100644 --- a/contributed_definitions/nyaml/NXfit_parameter.yaml +++ b/contributed_definitions/nyaml/NXfit_parameter.yaml @@ -4,7 +4,7 @@ doc: | This would typically be a variable that is optimized in a fit. type: group -NXfit_single_parameter(NXobject): +NXfit_parameter(NXobject): name(NX_CHAR): doc: | The name of the parameter. @@ -14,18 +14,19 @@ NXfit_single_parameter(NXobject): value(NX_NUMBER): unit: NX_ANY doc: | - The value of the parameter. + The value of the parameter. After fitting, this would store the + optimized value. min_value(NX_NUMBER): unit: NX_ANY doc: | - The minimal value of the parameter. + The minimal value of the parameter, to be used as a constraint during fitting. max_value(NX_NUMBER): unit: NX_ANY doc: | - The maximal value of the parameter. + The maximal value of the parameter, to be used as a constraint during fitting. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 67576446846777764015abe86269743cd6e0ae7d6685f4307d982e13a1d1c0b8 +# 86b45dd6443b276fa8997b0d758a2262339c05b2ef70429d700ec583802a8e9b # # # -# +# # # A parameter for a fit function. # This would typically be a variable that @@ -67,17 +68,18 @@ NXfit_single_parameter(NXobject): # # # -# The value of the parameter. +# The value of the parameter. After fitting, this would store the +# optimized value. # # # # -# The minimal value of the parameter. +# The minimal value of the parameter, to be used as a constraint during fitting. # # # # -# The maximal value of the parameter. +# The maximal value of the parameter, to be used as a constraint during fitting. # # # diff --git a/contributed_definitions/nyaml/NXpeak.yaml b/contributed_definitions/nyaml/NXpeak.yaml index f9ecf8c5d6..a92d61feeb 100644 --- a/contributed_definitions/nyaml/NXpeak.yaml +++ b/contributed_definitions/nyaml/NXpeak.yaml @@ -5,12 +5,9 @@ doc: | symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. - n_points: | - Number of discretization points at which the functional form of the peak - has been evaluated. - n_dependent: | - Number of dependent variables to be fitted (for multidimensional/multivariate - fit.) + dimRank: | + Rank of the dependent and independent data arrays (for + multidimensional/multivariate fit.) type: group NXpeak(NXobject): label: @@ -21,17 +18,28 @@ NXpeak(NXobject): position(NX_NUMBER): unit: NX_ANY doc: | - This axis holds the position values for the independent variable. + Position values along one or more data dimensions (to hold the + values for the independent variable). dimensions: - rank: 1 - dim: [[1, n_points]] + rank: dimRank + doc: | + The ``position`` field must have the same rank (``dimRank``) + as the ``intensity`` field. Each individual dimension of ``position`` + must have the same number of points as the corresponding dimension in + the ``intensity`` field. + dim: [] intensity(NX_NUMBER): unit: NX_ANY doc: | This array holds the intensity/count values of the fitted peak at each position. dimensions: - rank: 2 - dim: [[1, n_points], [2, n_dependent]] + rank: dimRank + doc: | + The ``intensity`` field must have the same rank (``dimRank``) + as the ``intensity`` field. Each individual dimension of ``position`` + must have the same number of points as the corresponding dimension in + the ``position`` field. + dim: [] function(NXfit_function): doc: | The functional form of the peak. This could be a Gaussian, Lorentzian, @@ -71,16 +79,10 @@ NXpeak(NXobject): # # The symbols used in the schema to specify e.g. dimensions of arrays. # -# +# # -# Number of discretization points at which the functional form of the peak -# has been evaluated. -# -# -# -# -# Number of dependent variables to be fitted (for multidimensional/multivariate -# fit.) +# Rank of the dependent and independent data arrays (for +# multidimensional/multivariate fit.) # # # @@ -97,19 +99,29 @@ NXpeak(NXobject): # # # -# This axis holds the position values for the independent variable. +# Position values along one or more data dimensions (to hold the +# values for the independent variable). # -# -# +# +# +# The ``position`` field must have the same rank (``dimRank``) +# as the ``intensity`` field. Each individual dimension of ``position`` +# must have the same number of points as the corresponding dimension in +# the ``intensity`` field. +# # # # # # This array holds the intensity/count values of the fitted peak at each position. # -# -# -# +# +# +# The ``intensity`` field must have the same rank (``dimRank``) +# as the ``intensity`` field. Each individual dimension of ``position`` +# must have the same number of points as the corresponding dimension in +# the ``position`` field. +# # # # From f9304ba343dbf87a1a62fa52c40469c2a4597f6f Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 22 May 2024 11:33:39 +0200 Subject: [PATCH 0895/1012] use globlal_fit and error_function in NXfit, fix dimensions --- contributed_definitions/NXfit.nxdl.xml | 101 ++++++++---- contributed_definitions/nyaml/NXfit.yaml | 191 ++++++++++++++++------- 2 files changed, 205 insertions(+), 87 deletions(-) diff --git a/contributed_definitions/NXfit.nxdl.xml b/contributed_definitions/NXfit.nxdl.xml index 6d79b137da..ab0e4f86ba 100644 --- a/contributed_definitions/NXfit.nxdl.xml +++ b/contributed_definitions/NXfit.nxdl.xml @@ -26,15 +26,10 @@ The symbols used in the schema to specify e.g. dimensions of arrays. - + - Number of discretization points inside the fitting region. - - - - - Number of dependent variables to be fitted (for multidimensional/multivariate - fit.) + Rank of the dependent and independent data arrays (for + multidimensional/multivariate fit.) @@ -52,45 +47,64 @@ - Dependent axis for this fit procedure. + Position values along one or more data dimensions (to hold the + values for the independent variable for this fit procedure). - - + + + The ``input_dependent`` field must have the same rank (``dimRank``) + as the ``input_independent`` field. Each individual dimension of ``input_dependent`` + must have the same number of points as the corresponding dimension in + the ``input_independent`` field. + - Independent axis for this fit procedure. + Independent input axis for this fit procedure. - - - + + + The ``input_independent`` field must have the same rank (``dimRank``) + as the ``input_dependent`` field. Each individual dimension of ``input_independent`` + must have the same number of points as the corresponding dimension in + the ``input_dependent`` field. + - Resulting envelope of all NXpeak instances. - Should have the same dimension as the `position` axes of the individual peaks. + Resulting envelope of applying the `global_fit_function` with its parameter to the data stored + in `input_independent`. - - - + + + The ``envelope`` field must have the same rank (``dimRank``) + as the ``input_independent`` field. Each individual dimension of ``envelope`` + must have the same number of points as the corresponding dimension in + the ``input_independent`` field. + - Difference between the envelope and the data to be fitted. + Difference between the envelope and the `input_independent` data to be fitted. - - - + + + The ``residual`` field must have the same rank (``dimRank``) + as the ``input_independent`` field. Each individual dimension of ``residual`` + must have the same number of points as the corresponding dimension in + the ``input_independent`` field. + - One spectral peak of the peak model. - It is envisioned that peaks are labeled as peak_0, peak_1, and so on. + One peak of the peak model. + If there is no characteristic name for each peak component, is envisioned that peaks + are labeled as peak_0, peak_1, and so on. @@ -114,18 +128,32 @@ The relative area can simply be derived by dividing the total_area by the total area of all peaks or by a more complicated method (e.g., by additionally dividing by the relative sensitivity factors). Details shall - be given in fitting_method. + be given in `global_fit_function`. - One fitted background (functional, position, and intensities) of the peak fit. - It is envisioned that peaks are labeled as background_0, background_1, and - so on. + One fitted background (functional form, position, and intensities) of the peak fit. + If there is no characteristic name for each peak component, it is envisioned that backgrounds are labeled + as background_0, background_1, and so on. - + + + Function used to describe the overall fit to the data, taking into account the parameters of the + individual `NXpeak` and `NXfit_background` components. + + + + Oftentimes, if the peaks and fit backgrounds are defined independently (i.e, with their own + parameter sets), the resulting global fit is a of the form + :math:`model = peak_1(p_1) + peak2(p_2) + backgr(p_3).`, where each :math:`p_x` describes the + set of parameters for one peak/background. + + + + Function used to optimize the parameters during peak fitting. @@ -140,6 +168,17 @@ - Bayesian linear regression + + + For the optimization, the formula is any optimization process on the `global_fit_function` given above. + As an example, for a linear least squared algorithm on independent components, the formula of the error_function + would be :math:`LLS(peak_1(p_1) + peak2(p_2) + backgr(p_3))`, where each :math:`p_x` describes the set + of parameters for one peak/background. + + It is however also possible to supply more involved formulas. For example, in the case of constrained fits, the derivatives + of parameters. + + diff --git a/contributed_definitions/nyaml/NXfit.yaml b/contributed_definitions/nyaml/NXfit.yaml index 50fe447068..e02ccf0c5e 100644 --- a/contributed_definitions/nyaml/NXfit.yaml +++ b/contributed_definitions/nyaml/NXfit.yaml @@ -4,11 +4,9 @@ doc: | symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. - n_points: | - Number of discretization points inside the fitting region. - n_dependent: | - Number of dependent variables to be fitted (for multidimensional/multivariate - fit.) + dimRank: | + Rank of the dependent and independent data arrays (for + multidimensional/multivariate fit.) type: group NXfit(NXobject): label: @@ -20,35 +18,58 @@ NXfit(NXobject): input_dependent(NX_NUMBER): unit: NX_ANY doc: | - Dependent axis for this fit procedure. + Position values along one or more data dimensions (to hold the + values for the independent variable for this fit procedure). dimensions: - dim: [[1, n_points]] + rank: dimRank + doc: | + The ``input_dependent`` field must have the same rank (``dimRank``) + as the ``input_independent`` field. Each individual dimension of ``input_dependent`` + must have the same number of points as the corresponding dimension in + the ``input_independent`` field. + dim: [] input_independent(NX_NUMBER): unit: NX_ANY doc: | - Independent axis for this fit procedure. + Independent input axis for this fit procedure. dimensions: - rank: 2 - dim: [[1, n_points], [2, n_dependent]] + rank: dimRank + doc: | + The ``input_independent`` field must have the same rank (``dimRank``) + as the ``input_dependent`` field. Each individual dimension of ``input_independent`` + must have the same number of points as the corresponding dimension in + the ``input_dependent`` field. + dim: [] envelope(NX_NUMBER): unit: NX_ANY doc: | - Resulting envelope of all NXpeak instances. - Should have the same dimension as the `position` axes of the individual peaks. + Resulting envelope of applying the `global_fit_function` with its parameter to the data stored + in `input_independent`. dimensions: - rank: 2 - dim: [[1, n_points], [2, n_dependent]] + rank: dimRank + doc: | + The ``envelope`` field must have the same rank (``dimRank``) + as the ``input_independent`` field. Each individual dimension of ``envelope`` + must have the same number of points as the corresponding dimension in + the ``input_independent`` field. + dim: [] residual(NX_NUMBER): unit: NX_ANY doc: | - Difference between the envelope and the data to be fitted. + Difference between the envelope and the `input_independent` data to be fitted. dimensions: - rank: 2 - dim: [[1, n_points], [2, n_dependent]] + rank: dimRank + doc: | + The ``residual`` field must have the same rank (``dimRank``) + as the ``input_independent`` field. Each individual dimension of ``residual`` + must have the same number of points as the corresponding dimension in + the ``input_independent`` field. + dim: [] peakPEAK(NXpeak): doc: | - One spectral peak of the peak model. - It is envisioned that peaks are labeled as peak_0, peak_1, and so on. + One peak of the peak model. + If there is no characteristic name for each peak component, is envisioned that peaks + are labeled as peak_0, peak_1, and so on. total_area(NX_NUMBER): unit: NX_ANY doc: | @@ -70,13 +91,23 @@ NXfit(NXobject): The relative area can simply be derived by dividing the total_area by the total area of all peaks or by a more complicated method (e.g., by additionally dividing by the relative sensitivity factors). Details shall - be given in fitting_method. + be given in `global_fit_function`. backgroundBACKGROUND(NXfit_background): doc: | - One fitted background (functional, position, and intensities) of the peak fit. - It is envisioned that peaks are labeled as background_0, background_1, and - so on. - fit_function(NXfit_function): + One fitted background (functional form, position, and intensities) of the peak fit. + If there is no characteristic name for each peak component, it is envisioned that backgrounds are labeled + as background_0, background_1, and so on. + global_fit_function(NXfit_function): + doc: | + Function used to describe the overall fit to the data, taking into account the parameters of the + individual `NXpeak` and `NXfit_background` components. + formula: + doc: | + Oftentimes, if the peaks and fit backgrounds are defined independently (i.e, with their own + parameter sets), the resulting global fit is a of the form + :math:`model = peak_1(p_1) + peak2(p_2) + backgr(p_3).`, where each :math:`p_x` describes the + set of parameters for one peak/background. + error_function(NXfit_function): doc: | Function used to optimize the parameters during peak fitting. description: @@ -88,6 +119,15 @@ NXfit(NXobject): - Levenberg-Marquardt algorithm (damped least-squares) - linear regression - Bayesian linear regression + formula: + doc: | + For the optimization, the formula is any optimization process on the `global_fit_function` given above. + As an example, for a linear least squared algorithm on independent components, the formula of the error_function + would be :math:`LLS(peak_1(p_1) + peak2(p_2) + backgr(p_3))`, where each :math:`p_x` describes the set + of parameters for one peak/background. + + It is however also possible to supply more involved formulas. For example, in the case of constrained fits, the derivatives + of parameters. figure_of_meritMETRIC(NX_NUMBER): unit: NX_UNITLESS doc: | @@ -104,7 +144,7 @@ NXfit(NXobject): - :math:`R^2`, the coefficient of determination # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 74119a4cf342af4aea0a177a26d393893e54835ba084cf58ec07ea350b2dcf62 +# efe45ef3f375376f83d16f78f5b4604c83b192e56a3282c3938697a5287b2c2d # # # - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/NXxps.nxdl.xml b/contributed_definitions/NXxps.nxdl.xml index d4c0765cc1..8aee37f954 100644 --- a/contributed_definitions/NXxps.nxdl.xml +++ b/contributed_definitions/NXxps.nxdl.xml @@ -405,11 +405,15 @@ >>>>>>> 7178a95ca (remove NXtransformations from NXcoordinate_system) +<<<<<<< HEAD <<<<<<< HEAD ======= >>>>>>> 5e7c2dec7 (change to NXcoordinate_system_set, use NXfit in NXxps) +======= + +>>>>>>> 248a9c0ff (NXfit extends NXprocess) Peak model for XPS fitting. Each `NXfit` instance shall be used for the description of _one_ peak fit in _one_ XPS region. As an example, this could be used to describe the @@ -419,6 +423,7 @@ .. _3.29: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.29 +<<<<<<< HEAD <<<<<<< HEAD @@ -428,89 +433,49 @@ ======= +======= + + +>>>>>>> 248a9c0ff (NXfit extends NXprocess) - Description of one peak fit. This is meant to be used for a peak fit in - _one_ XPS region. As an example, this could be used to describe the - fitting of one measured C 1s spectrum. + Input data and results of the fit. - - + - Input data and results of the fit. + Dependent variable for this fit procedure. + + This could be a link to entry/data/data. - - - Dependent variable for this fit procedure. - - This could be a link to entry/data/data. - - - + + + + Independent variable for this fit procedure. + + This could be a link to entry/data/energy. + + + + + + + + + - Independent variable for this fit procedure. - This could be a link to entry/data/energy. - - - - - - - - - This could be a link to entry/data/energy. - - - - - Intensity values of the fitted function at each energy in the position field. - - This concept is related to term `3.15`_ of the ISO 18115-1:2023 standard. - - .. _3.15: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.15 - - - - - - - - Area of the peak. - - - - - Width of a peak at a defined fraction of the peak height. - - Usually, this will be the Full Width at Half Maximum of the peak (FWHM). - For asymmetric peaks, convenient measures of peak width are the half-widths of - each side of the peak at half maximum intensity. - - This concept is related to term `3.28`_ of the ISO 18115-1:2023 standard. - - .. _3.28: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.28 - - - - - - Position of the peak on the energy axis. - - - - - + - Total area under the peak after background removal. + Intensity values of the fitted function at each energy in the position field. - This concept is related to term `3.16`_ of the ISO 18115-1:2023 standard. + This concept is related to term `3.15`_ of the ISO 18115-1:2023 standard. - .. _3.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.16 + .. _3.15: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.15 +<<<<<<< HEAD <<<<<<< HEAD >>>>>>> 5e7c2dec7 (change to NXcoordinate_system_set, use NXfit in NXxps) @@ -554,11 +519,15 @@ +======= + +>>>>>>> 248a9c0ff (NXfit extends NXprocess) Area of the peak. +<<<<<<< HEAD @@ -652,54 +621,38 @@ +======= +>>>>>>> 248a9c0ff (NXfit extends NXprocess) - - - - - - Linear background, i.e., a simple straight line from the minimal to - the maximal abscissa value. - - - - - Shirley background. In the Shirley background, the background intensity at any - given binding energy is proportional to the intensity of the total peak area - above the background in the lower binding energy peak range (i.e., the - background goes up in proportion to the total number of photoelectrons below its - binding energy position). - - - - - Tougaard background (or Tougaard universal cross-section approach) which is a - methodology for integrating the intensity of the background at a given binding - energy from the spectral intensities to higher kinetic energies - - - - - In case none of the enumeration items apply, description should be _other_ - and the functional form of the background should be given by the `formula` - field. - - - - - + + + Width of a peak at a defined fraction of the peak height. + + Usually, this will be the Full Width at Half Maximum of the peak (FWHM). + For asymmetric peaks, convenient measures of peak width are the half-widths of + each side of the peak at half maximum intensity. + + This concept is related to term `3.28`_ of the ISO 18115-1:2023 standard. + + .. _3.28: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.28 + + + + + + Position of the peak on the energy axis. + + >>>>>>> c47edfd66 (use new peak fitting in NXxps) - - - - - + - Atomic concentration of each species defined by one peak in the peak model. - This should be an array with the indices pointing to the individual peaks - (i.e, peak_0, peak_1, etc.) + Total area under the peak after background removal. + + This concept is related to term `3.16`_ of the ISO 18115-1:2023 standard. + + .. _3.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.16 >>>>>>> 5e7c2dec7 (change to NXcoordinate_system_set, use NXfit in NXxps) diff --git a/contributed_definitions/nyaml/NXfit.yaml b/contributed_definitions/nyaml/NXfit.yaml index 589e1508a7..cae8de1e8e 100644 --- a/contributed_definitions/nyaml/NXfit.yaml +++ b/contributed_definitions/nyaml/NXfit.yaml @@ -8,7 +8,7 @@ symbols: Rank of the dependent and independent data arrays (for multidimensional/multivariate fit.) type: group -NXfit(NXobject): +NXfit(NXprocess): label: doc: | Human-readable label for this fit procedure. @@ -143,7 +143,7 @@ NXfit(NXobject): - :math:`R^2`, the coefficient of determination # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 5c7eeb273752d19d2601bbf4be890683bf58eaa5bea2bb57e474e1dc0f0f3b84 +# fcf92e26824bac53c43854728f890e890bbbbb7f6f10e102a632304056ac91fd # # # -# +# # # # The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXxps.yaml b/contributed_definitions/nyaml/NXxps.yaml index e27e6aec40..0afab7a31d 100644 --- a/contributed_definitions/nyaml/NXxps.yaml +++ b/contributed_definitions/nyaml/NXxps.yaml @@ -242,137 +242,142 @@ NXxps(NXmpes): spec: ISO 18115-1:2023 term: 3.29 url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.29 - (NXfit): + label: + data(NXdata): doc: | - Description of one peak fit. This is meant to be used for a peak fit in - _one_ XPS region. As an example, this could be used to describe the - fitting of one measured C 1s spectrum. + Input data and results of the fit. + input_dependent(NX_NUMBER): + unit: NX_ANY + doc: | + Dependent variable for this fit procedure. + + This could be a link to entry/data/data. + input_independent(NX_NUMBER): + unit: NX_ANY + doc: | + Independent variable for this fit procedure. + + This could be a link to entry/data/energy. + envelope(NX_NUMBER): + residual(NX_NUMBER): + exists: recommended + peakPEAK(NXpeak): label: data(NXdata): - doc: | - Input data and results of the fit. - input_dependent(NX_NUMBER): - unit: NX_ANY + position(NX_NUMBER): + unit: NX_ENERGY doc: | - Dependent variable for this fit procedure. - - This could be a link to entry/data/data. - input_independent(NX_NUMBER): - unit: NX_ANY - doc: | - Independent variable for this fit procedure. - This could be a link to entry/data/energy. - envelope(NX_NUMBER): - residual(NX_NUMBER): - exists: recommended - peakPEAK(NXpeak): - label: - data(NXdata): - position(NX_NUMBER): - unit: NX_ENERGY - doc: | - This could be a link to entry/data/energy. - intensity(NX_NUMBER): - doc: - - | - Intensity values of the fitted function at each energy in the position field. - - | - xref: - spec: ISO 18115-1:2023 - term: 3.15 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.15 - function(NXfit_function): - formula: - exists: recommended - area(NXfit_single_parameter): - exists: optional - doc: | - Area of the peak. - width(NXfit_single_parameter): - exists: optional - doc: - - | - Width of a peak at a defined fraction of the peak height. - - | - Usually, this will be the Full Width at Half Maximum of the peak (FWHM). - For asymmetric peaks, convenient measures of peak width are the half-widths of - each side of the peak at half maximum intensity. - - | - xref: - spec: ISO 18115-1:2023 - term: 3.28 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.28 - value: - unit: NX_ENERGY - position(NXfit_single_parameter): - exists: optional - doc: | - Position of the peak on the energy axis. - value: - unit: NX_ENERGY - total_area: + intensity(NX_NUMBER): + doc: + - | + Intensity values of the fitted function at each energy in the position field. + - | + xref: + spec: ISO 18115-1:2023 + term: 3.15 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.15 + function(NXfit_function): + formula: exists: recommended + area(NXfit_parameter): + exists: optional + doc: | + Area of the peak. + width(NXfit_parameter): + exists: optional doc: - | - Total area under the peak after background removal. + Width of a peak at a defined fraction of the peak height. + - | + Usually, this will be the Full Width at Half Maximum of the peak (FWHM). + For asymmetric peaks, convenient measures of peak width are the half-widths of + each side of the peak at half maximum intensity. - | xref: spec: ISO 18115-1:2023 - term: 3.16 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.16 - backgroundBACKGROUND(NXfit_background): + term: 3.28 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.28 + value: + unit: NX_ENERGY + position(NXfit_parameter): + exists: optional + doc: | + Position of the peak on the energy axis. + value: + unit: NX_ENERGY + total_area: + exists: recommended doc: - | Total area under the peak after background removal. - | xref: spec: ISO 18115-1:2023 - term: 3.21 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.21 - label: + term: 3.16 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.16 + backgroundBACKGROUND(NXfit_background): + doc: + - | + Functional form of the fitted XPS background. + - | + xref: + spec: ISO 18115-1:2023 + term: 3.21 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.21 + label: + exists: recommended + data(NXdata): + position(NX_NUMBER): + unit: NX_ENERGY + intensity(NX_NUMBER): + function(NXfit_function): + description: + enumeration: + linear: + doc: | + Linear background, i.e., a simple straight line from the minimal to + the maximal abscissa value. + Shirley: + doc: | + Shirley background. In the Shirley background, the background intensity at any + given binding energy is proportional to the intensity of the total peak area + above the background in the lower binding energy peak range (i.e., the + background goes up in proportion to the total number of photoelectrons below its + binding energy position). + Tougaard: + doc: | + Tougaard background (or Tougaard universal cross-section approach) which is a + methodology for integrating the intensity of the background at a given binding + energy from the spectral intensities to higher kinetic energies + other: + doc: | + In case none of the enumeration items apply, description should be _other_ + and the functional form of the background should be given by the `formula` + field. + formula: exists: recommended - data(NXdata): - position(NX_NUMBER): - unit: NX_ENERGY - intensity(NX_NUMBER): - function(NXfit_function): - description: - enumeration: - linear: - doc: | - Linear background, i.e., a simple straight line from the minimal to - the maximal abscissa value. - Shirley: - doc: | - Shirley background. In the Shirley background, the background intensity at any - given binding energy is proportional to the intensity of the total peak area - above the background in the lower binding energy peak range (i.e., the - background goes up in proportion to the total number of photoelectrons below its - binding energy position). - Tougaard: - doc: | - Tougaard background (or Tougaard universal cross-section approach) which is a - methodology for integrating the intensity of the background at a given binding - energy from the spectral intensities to higher kinetic energies - other: - doc: | - In case none of the enumeration items apply, description should be _other_ - and the functional form of the background should be given by the `formula` - field. - formula: - exists: recommended - fit_function(NXfit_function): + global_fit_function(NXfit_function): + exists: recommended + description: exists: recommended - figure_of_meritMETRIC(NX_NUMBER): + formula: exists: recommended - \@metric: - relative_concentration(NX_FLOAT): - unit: NX_ANY - doc: | - Atomic concentration of each species defined by one peak in the peak model. - This should be an array with the indices pointing to the individual peaks - (i.e, peak_0, peak_1, etc.) + error_function(NXfit_function): + exists: recommended + description: + exists: recommended + formula: + exists: recommended + figure_of_meritMETRIC(NX_NUMBER): + exists: recommended + \@metric: + relative_concentration(NX_FLOAT): + unit: NX_ANY + doc: | + Atomic concentration of each species defined by one peak in the peak model. + This should be an array with the indices pointing to the individual peaks + (i.e, peak_0, peak_1, etc.) data(NXdata_mpes): energy(NX_NUMBER): \@energy_indices: @@ -380,7 +385,7 @@ NXxps(NXmpes): exists: recommended # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 40681e40574a11857f079de5eeb412534479c9ca24bd17b6712a3ad92be1e355 +# f4f5cfeb93f60f8c98404b4a15674f0e4ba09ec0366115467a3af99e1598a260 # # # -# -<<<<<<< HEAD -# Description of coordinate system specific to the setup and the measurement -# geometry. ->>>>>>> 8c42628fe (remove NXtransformations from NXcoordinate_system) -======= -# Description of one or more coordinate systems that are specific to the setup -# and the measurement geometry. ->>>>>>> 05529f919 (change to NXcoordinate_system_set, use NXfit in NXxps) ->>>>>>> 5e7c2dec7 (change to NXcoordinate_system_set, use NXfit in NXxps) # # # diff --git a/contributed_definitions/nyaml/NXxps.yaml b/contributed_definitions/nyaml/NXxps.yaml index ba9493c8e8..c15d457deb 100644 --- a/contributed_definitions/nyaml/NXxps.yaml +++ b/contributed_definitions/nyaml/NXxps.yaml @@ -278,6 +278,8 @@ NXxps(NXmpes): term: 3.15 url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.15 function(NXfit_function): + exists: recommended + description: formula: exists: recommended area(NXfit_parameter): @@ -332,6 +334,7 @@ NXxps(NXmpes): unit: NX_ENERGY intensity(NX_NUMBER): function(NXfit_function): + exists: recommended description: enumeration: linear: @@ -378,14 +381,9 @@ NXxps(NXmpes): Atomic concentration of each species defined by one peak in the peak model. This should be an array with the indices pointing to the individual peaks (i.e, peak_0, peak_1, etc.) - data(NXdata_mpes): - energy(NX_NUMBER): - \@energy_indices: - \@energy_depends: - exists: recommended # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 7d6778701f0b2bf5dd5529bec912685b19a2269fb0afef7ed8e142fef9449a0f +# 04421486bc5dffb01865fb8e056d77e5f5157304a3bc3ab9024c8ad160fe21e6 # # # +A rework of the draft version(06/2022) of a NeXus application definition for ellipsometry. + +09/2024 +TODO (Workshop output): +- Better categorization of ellipsoeter types: + Seperate in spectral range and measurement types (In situ vs infrared?? This grouping does not make sense) + Maybe make a given special field for "spectral_range" with units of eV or nm? +- Add a StepScanAnalzer as measurement type (continous/rotating mode the other? Ask Chris) +- Redefine more/higher requirements for Ellipsometry compared to NXoptical_spectroscopy: Especially incident angle and polarization. +- Refinements for ellipsometer_type and add ellipsometer_method/mode: + "~ please consider renaming "ellipsometer_type" to "ellipsometer_method" or "ellipsometer_mode". Motivation: "rotating_compensator" etc. are methods of ellipsometry measurements, and some ellipsometers support multiple methods (e.g. rotating compensator, nulling etc). + ~ please consider to use the field "ellipsometer_type" for entries directly related to the core instrument, i.e. "imaging ellipsometer", "standard ellipsometer" (or: "non-imaging ellipsometer"), maybe others such as "back-focal plane ellipsometer" " +- Add a clear predefined data structure, as initially proposed, but dont add any restrictions regarding dimensions + Make ois maybe similar to NXdata_mpes. In this way, at all FAIR assignments of the data is possible. As well use this to guide the people, to let them know, where they have to save their data. Just use NXdata is too vague. Could be easing the threshold to get into NeXus. + This explicitly refers to a wish to add: "exposure time, number of scans"--> @@ -170,8 +184,15 @@ A rework of the draft version(06/2022) of a NeXus application definition for ell + + + + If the ellipsometer_type is `other`, a specific ellipsometer should be specified + here. + + Define which element rotates, e.g. polarizer or analyzer. diff --git a/contributed_definitions/NXoptical_spectroscopy.nxdl.xml b/contributed_definitions/NXoptical_spectroscopy.nxdl.xml index b053470b10..853b0639e4 100644 --- a/contributed_definitions/NXoptical_spectroscopy.nxdl.xml +++ b/contributed_definitions/NXoptical_spectroscopy.nxdl.xml @@ -32,7 +32,9 @@ TODO: - Make spectralfilter_TYPE(NXbeam_device) own base class -\-> extend NXfilter? and add them to NXinstrument. - Make offset angles for polar and azimutal? - Can angle_reference_frame be replaced later by only using reference_frames and generic angle description? -- Add optical elements and rework them: NXfiber, NXbeam_splitter,--> +- Add optical elements and rework them: NXfiber, NXbeam_splitter, +- Consider to make power flux recommended? Difficult parameter to measure. Relevant for some samples/techniques, but not for all. Powder density? Nominal vs. measured? +- Is there something to describe the spot size?--> @@ -400,6 +402,9 @@ TODO: + + + diff --git a/contributed_definitions/NXraman.nxdl.xml b/contributed_definitions/NXraman.nxdl.xml index 8f133ac117..be89552fd4 100644 --- a/contributed_definitions/NXraman.nxdl.xml +++ b/contributed_definitions/NXraman.nxdl.xml @@ -29,6 +29,22 @@ N_incident_beams: | + @@ -183,6 +199,7 @@ A draft version of a NeXus application definition for Raman spectroscopy.--> + If the raman_experiment_type is `other`, a name should be specified here. From db8b3abc28c93efa5db405490eec9f6f6068e984 Mon Sep 17 00:00:00 2001 From: Ron Hildebrandt Date: Tue, 3 Sep 2024 12:51:20 +0200 Subject: [PATCH 0912/1012] lowercase enumeration, source_type todo added, doc for ellipsometry_type --- contributed_definitions/nyaml/NXellipsometry.yaml | 2 +- contributed_definitions/nyaml/NXoptical_spectroscopy.yaml | 7 ++++--- contributed_definitions/nyaml/NXraman.yaml | 4 ++-- 3 files changed, 7 insertions(+), 6 deletions(-) diff --git a/contributed_definitions/nyaml/NXellipsometry.yaml b/contributed_definitions/nyaml/NXellipsometry.yaml index 364ec39631..c5ad226032 100644 --- a/contributed_definitions/nyaml/NXellipsometry.yaml +++ b/contributed_definitions/nyaml/NXellipsometry.yaml @@ -116,7 +116,7 @@ NXellipsometry(NXoptical_spectroscopy): enumeration: [rotating analyzer, rotating analyzer with analyzer compensator, rotating analyzer with polarizer compensator, rotating polarizer, rotating compensator on polarizer side, rotating compensator on analyzer side, modulator on polarizer side, modulator on analyzer side, dual compensator, phase modulation, imaging ellipsometry, null ellipsometry, other] ellipsometer_type_other: doc: | - If the ellipsometer_type is `other`, a specific ellipsometer should be specified here. + If the ellipsometer_type is `other`, a specific ellipsometry_type" should be added here. rotating_element_type: doc: | Define which element rotates, e.g. polarizer or analyzer. diff --git a/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml b/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml index c6f922ba1c..935dee7fc4 100644 --- a/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml +++ b/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml @@ -36,6 +36,7 @@ symbols: # - Add optical elements and rework them: NXfiber, NXbeam_splitter, # - Consider to make power flux recommended? Difficult parameter to measure. Relevant for some samples/techniques, but not for all. Powder density? Nominal vs. measured? # - Is there something to describe the spot size? +# - Restructure the concept "type" in "source_TYPE" to medium and model(NXfabication) --> suggestion from Markus: "splitting up the concept into type(NXfabrication) and emitting medium(NXion/NXatom) is a better alternative?" type: group NXoptical_spectroscopy(NXobject): (NXentry): @@ -242,7 +243,7 @@ NXoptical_spectroscopy(NXobject): exists: recommended doc: | Description of the detector type. - enumeration: [CCD, Photomultiplier, Photodiode, Avalanche-Photodiode, Streak Camera, Bolometer, Golay Detectors, Pyroelectric Detector, Deuterated Triglycine Sulphate, other] + enumeration: [CCD, photomultiplier, photodiode, avalanche-Photodiode, streak camera, bolometer, golay detectors, pyroelectric detector, deuterated triglycine sulphate, other] detector_type_other: exists: optional doc: | @@ -526,7 +527,7 @@ NXoptical_spectroscopy(NXobject): doc: | Physical principle of the polarization filter used to create a defined incident or scattered light state. - enumeration: [Polarization by Fresnel reflection, Birefringent polarizers, Thin film polarizers, Wire-grid polarizers, other] + enumeration: [polarization by Fresnel reflection, birefringent polarizers, thin film polarizers, wire-grid polarizers, other] specific_polarization_filter_type(NX_CHAR): exists: optional doc: | @@ -547,7 +548,7 @@ NXoptical_spectroscopy(NXobject): doc: | Type of laserline filter used to supress the laser, if measurements close to the laserline are performed. - enumeration: [long-pass filter, short-pass filter, Notch filter, reflection filter, neutral density filter, other] + enumeration: [long-pass filter, short-pass filter, notch filter, reflection filter, neutral density filter, other] intended_use: exists: optional doc: | diff --git a/contributed_definitions/nyaml/NXraman.yaml b/contributed_definitions/nyaml/NXraman.yaml index a03d79558b..77d36c5c5d 100644 --- a/contributed_definitions/nyaml/NXraman.yaml +++ b/contributed_definitions/nyaml/NXraman.yaml @@ -132,8 +132,8 @@ NXraman(NXoptical_spectroscopy): raman_experiment_type: doc: | Specify the type of Raman experiment. - enumeration: [in situ Raman spectroscopy, resonant Raman spectroscopy, non-resonant Raman spectroscopy, Raman imaging, Tip-enhanced Raman spectroscopy (TERS), Surface-enhanced Raman spectroscopy (SERS), Surface plasmon polariton enhanced Raman scattering (SPPERS), Hyper Raman spectroscopy (HRS), Stimulated Raman spectroscopy (SRS), Inverse Raman spectroscopy (IRS), Coherent anti-Stokes Raman spectroscopy (CARS), other] -# enumeration: [in situ, resonant, non-resonant, imaging, Tip-enhanced (TERS), Surface-enhanced (SERS), Surface plasmon polariton enhanced (SPPERS), Hyper Raman spectroscopy (HRS), Stimulated (SRS), Inverse (IRS), Coherent anti-Stokes (CARS), other] + enumeration: [in situ Raman spectroscopy, resonant Raman spectroscopy, non-resonant Raman spectroscopy, Raman imaging, tip-enhanced Raman spectroscopy (TERS), surface-enhanced Raman spectroscopy (SERS), surface plasmon polariton enhanced Raman scattering (SPPERS), hyper Raman spectroscopy (HRS), stimulated Raman spectroscopy (SRS), inverse Raman spectroscopy (IRS), coherent anti-Stokes Raman spectroscopy (CARS), other] +# enumeration: [in situ, resonant, non-resonant, imaging, tip-enhanced (TERS), surface-enhanced (SERS), surface plasmon polariton enhanced (SPPERS), hyper Raman spectroscopy (HRS), stimulated (SRS), inverse (IRS), coherent anti-Stokes (CARS), other] raman_experiment_type_other: exists: optional doc: | From 6a7efaff2cd6f2e1333a357673ded61e701bb220 Mon Sep 17 00:00:00 2001 From: Ron Hildebrandt Date: Tue, 3 Sep 2024 12:53:05 +0200 Subject: [PATCH 0913/1012] HOW LONG? does it take to learn to make nxdl and local before commiting >.< --- .../NXellipsometry.nxdl.xml | 4 +-- .../NXoptical_spectroscopy.nxdl.xml | 29 ++++++++++--------- contributed_definitions/NXraman.nxdl.xml | 16 +++++----- 3 files changed, 25 insertions(+), 24 deletions(-) diff --git a/contributed_definitions/NXellipsometry.nxdl.xml b/contributed_definitions/NXellipsometry.nxdl.xml index 220471c19e..67e4f1ca65 100644 --- a/contributed_definitions/NXellipsometry.nxdl.xml +++ b/contributed_definitions/NXellipsometry.nxdl.xml @@ -189,8 +189,8 @@ TODO (Workshop output): - If the ellipsometer_type is `other`, a specific ellipsometer should be specified - here. + If the ellipsometer_type is `other`, a specific ellipsometry_type" should be + added here. diff --git a/contributed_definitions/NXoptical_spectroscopy.nxdl.xml b/contributed_definitions/NXoptical_spectroscopy.nxdl.xml index 853b0639e4..02ad766746 100644 --- a/contributed_definitions/NXoptical_spectroscopy.nxdl.xml +++ b/contributed_definitions/NXoptical_spectroscopy.nxdl.xml @@ -34,7 +34,8 @@ TODO: - Can angle_reference_frame be replaced later by only using reference_frames and generic angle description? - Add optical elements and rework them: NXfiber, NXbeam_splitter, - Consider to make power flux recommended? Difficult parameter to measure. Relevant for some samples/techniques, but not for all. Powder density? Nominal vs. measured? -- Is there something to describe the spot size?--> +- Is there something to describe the spot size? +- Restructure the concept "type" in "source_TYPE" to medium and model(NXfabication) -\-> suggestion from Markus: "splitting up the concept into type(NXfabrication) and emitting medium(NXion/NXatom) is a better alternative?"--> @@ -321,14 +322,14 @@ TODO: - - - - - - - - + + + + + + + + @@ -667,10 +668,10 @@ TODO: defined incident or scattered light state. - - - - + + + + @@ -698,7 +699,7 @@ TODO: - + diff --git a/contributed_definitions/NXraman.nxdl.xml b/contributed_definitions/NXraman.nxdl.xml index be89552fd4..02290711de 100644 --- a/contributed_definitions/NXraman.nxdl.xml +++ b/contributed_definitions/NXraman.nxdl.xml @@ -189,17 +189,17 @@ dataset examples (i.e. NXdata_raman)--> - - - - - - - + + + + + + + - + If the raman_experiment_type is `other`, a name should be specified here. From 196f2a8d9e237e55737e25e32aa33bb3c2e41bee Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 4 Sep 2024 11:16:07 +0200 Subject: [PATCH 0914/1012] Fixes in EM --- contributed_definitions/NXem.nxdl.xml | 6 +++--- contributed_definitions/nyaml/NXem.yaml | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index b2dfbdc798..262dbef583 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -143,8 +143,8 @@ starting to reorganize the docstrings, as a list of blocks: start_time and end_time together. - - + + Possibility to store a collection of serialized resources associated with the experiment. @@ -169,7 +169,7 @@ starting to reorganize the docstrings, as a list of blocks: - + Information about persons who performed or were involved in the microscope session or simulation run. diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index a0cffc956f..4f23c54030 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -116,9 +116,9 @@ NXem(NXobject): - | See docstring of the start_time field to see how to use the start_time and end_time together. - (NXcite): + citeID(NXcite): exists: [min, 0, max, infty] - (NXserialized): + serializedID(NXserialized): exists: [min, 0, max, infty] doc: - | @@ -142,7 +142,7 @@ NXem(NXobject): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): - (NXuser): + userID(NXuser): exists: [min, 0, max, infty] doc: - | From c7be8123a7acc8ab4fc61aab10ee944958dcf789 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 4 Sep 2024 16:57:33 +0200 Subject: [PATCH 0915/1012] Merging NXem_adf into NXem_img, enabling microstructure reconstructions as dependants of specific method results, introduction of NXatom_set to discuss generalization of NXion towards enabling descriptions of groups of atoms, also to lias with FAIRmat Area C --- contributed_definitions/NXatom_set.nxdl.xml | 158 ++++++++++++++++++ contributed_definitions/NXem.nxdl.xml | 19 +-- contributed_definitions/NXem_adf.nxdl.xml | 46 ----- contributed_definitions/NXem_img.nxdl.xml | 35 ++-- contributed_definitions/NXem_method.nxdl.xml | 6 +- .../NXmicrostructure.nxdl.xml | 5 + contributed_definitions/nyaml/NXatom_set.yaml | 104 ++++++++++++ contributed_definitions/nyaml/NXem.yaml | 22 ++- contributed_definitions/nyaml/NXem_adf.yaml | 19 --- contributed_definitions/nyaml/NXem_eds.yaml | 2 +- contributed_definitions/nyaml/NXem_img.yaml | 19 ++- .../nyaml/NXem_method.yaml | 5 +- .../nyaml/NXmicrostructure.yaml | 3 + .../contributed_definitions/apm-structure.rst | 4 +- .../contributed_definitions/em-structure.rst | 2 +- 15 files changed, 326 insertions(+), 123 deletions(-) create mode 100644 contributed_definitions/NXatom_set.nxdl.xml delete mode 100644 contributed_definitions/NXem_adf.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXatom_set.yaml delete mode 100644 contributed_definitions/nyaml/NXem_adf.yaml diff --git a/contributed_definitions/NXatom_set.nxdl.xml b/contributed_definitions/NXatom_set.nxdl.xml new file mode 100644 index 0000000000..0a1e208560 --- /dev/null +++ b/contributed_definitions/NXatom_set.nxdl.xml @@ -0,0 +1,158 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). + + + + + Number of mass-to-charge-state-ratio range intervals for ion type. + + + + + Base class for documenting a set of atoms. + + + + A unique identifier whereby such an ion can be referred to + via the service offered as described in identifier_type. + + + + + How can the identifier be resolved? + + + + + + + + Ion type (ion species) identifier. + + The identifier zero is reserved for the special unknown ion type. + + + + + Vector of nuclide hash values. + + Individual hash values :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` + encode the number of protons :math:`Z` and the number of neutrons :math:`N` + of each nuclide respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. + + The array is sorted in decreasing order. For the rationale behind this see `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + Table which decodes the entries in nuclide_hash into a human-readable matrix of instances. + The first column specifies the nuclide mass number, i.e. using the hashvalues + from the isotope_vector this is :math:`Z + N` or 0. The value 0 documents that no + isotope-specific information about the element encoded is relevant. + The second row specifies the number of protons :math:`Z` or 0. + The value 0 in this case documents a placeholder or that no element-specific + information is relevant. + Taking a carbon-14 nuclide as an example the mass number is 14. + That is encoded as a value pair (14, 6) as one row of the table. + + Therefore, this notation is the typical superscribed nuclide mass number + and subscripted number of protons element notation e.g. :math:`^{14}C`. + The array is stored matching the order of nuclide_hash. + + + + + + + + + + Assumed volume of the ion. + + In atom probe microscopy this field can be used to store the reconstructed + volume per ion (average) which is typically stored alongside ranging + definitions. + + + + + Charge of the ion. + + + + + Signed charge state if the atoms form an ion reported in multiples of electron charge. + + In the example of atom probe microscopy, only positive values will be measured + as the ions are accelerated by a negatively signed bias electric field. + In the case that the charge state is not explicitly recoverable, the value should + be set to zero. + + In atom probe microscopy this is for example the case when using + classical ranging definition files in formats like RNG, RRNG. + These file formats do not document the charge state explicitly + but the number of atoms of each element per molecular ion + surplus the mass-to-charge-state-ratio interval. + Details on ranging definition files can be found in the literature: + `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + + + + + Human-readable name (e.g. Al +++) of the atom set, the atom group, or ion type. + The string should consists of UTF-8 characters, ideally using LaTeX + notation to specify the isotopes, ions, and charge state. + Examples are 12C + or Al +++. + + To ease automated parsing, isotope_vector should be the + preferred machine-readable information used. + + + + + Associated lower (mqmin) and upper (mqmax) bounds of the + mass-to-charge-state ratio interval(s) [mqmin, mqmax] + (boundaries inclusive). This field is primarily of interest + for documenting :ref:`NXprocess` steps of indexing a + ToF/mass-to-charge state histogram. + + + + + + + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 262dbef583..42c19b7e59 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -1280,8 +1280,8 @@ but normalized in its representation ready to be consumed for a research data management system--> - A region-of-interest analyzed either during or after the session for which - specific processed data are available. + A region-of-interest analyzed either during or after the session + for which specific processed data are available. This concept is related to term `Region Of Interest`_ of the EMglossary standard. @@ -1291,10 +1291,13 @@ research data management system--> an RDM can be sure to find specific pieces of information in a specific way but then every user of this application definition is required to provide such information in this way!--> - - - - + + + + + + + @@ -1433,11 +1436,7 @@ is required to provide such information in this way!--> - - - diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_adf.nxdl.xml deleted file mode 100644 index 35bc42e65f..0000000000 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ /dev/null @@ -1,46 +0,0 @@ - - - - - - Base class method-specific for annular dark field imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). Examples can be single point aka spot - measurements, line profiles, or (rectangular) surface mappings. - The latter pattern is the most frequently used. - - For now the base class provides for scans for which the settings, - binning, and energy resolution is the same for each scan point. - - - - - Annulus inner (first value) and outer (second value) half angle. - - - - - - - diff --git a/contributed_definitions/NXem_img.nxdl.xml b/contributed_definitions/NXem_img.nxdl.xml index 159b342c1e..096865a50a 100644 --- a/contributed_definitions/NXem_img.nxdl.xml +++ b/contributed_definitions/NXem_img.nxdl.xml @@ -22,23 +22,6 @@ # For further information, see http://www.nexusformat.org --> - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - Base class for method-specific generic imaging. @@ -57,6 +40,24 @@ + + + + + + Annulus inner (first value) and outer (second value) half angle. + + + + + + + + A reconstruction of the microstructure or some of its features + based on image information in the parent class. + + + diff --git a/contributed_definitions/NXem_method.nxdl.xml b/contributed_definitions/NXem_method.nxdl.xml index b469980872..985183f35f 100644 --- a/contributed_definitions/NXem_method.nxdl.xml +++ b/contributed_definitions/NXem_method.nxdl.xml @@ -21,8 +21,6 @@ # # For further information, see http://www.nexusformat.org --> - Base class to describe specific analysis methods in electron microscopy. @@ -32,8 +30,8 @@ definition gets equipped with specific groups to document method-specific processing steps and report analyzed quantities. - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + The template base class name :ref:`NXem_method` needs to be changed for + each method e.g. :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. diff --git a/contributed_definitions/NXmicrostructure.nxdl.xml b/contributed_definitions/NXmicrostructure.nxdl.xml index 63718fe7e0..44d462c045 100644 --- a/contributed_definitions/NXmicrostructure.nxdl.xml +++ b/contributed_definitions/NXmicrostructure.nxdl.xml @@ -210,6 +210,11 @@ the idea is we may wish to run as many grain reconstructions as we want and add orientation difference that warrants to assume that there exists an interface between the two regions. + + + The program with which the microstructure was reconstructed. + + diff --git a/contributed_definitions/nyaml/NXatom_set.yaml b/contributed_definitions/nyaml/NXatom_set.yaml new file mode 100644 index 0000000000..3e83a1beff --- /dev/null +++ b/contributed_definitions/nyaml/NXatom_set.yaml @@ -0,0 +1,104 @@ +category: base +doc: | + Base class for documenting a set of atoms. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_ivec_max: | + Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). + n_ranges: | + Number of mass-to-charge-state-ratio range intervals for ion type. +type: group +NXatom_set(NXobject): + identifier(NX_CHAR): + doc: | + A unique identifier whereby such an ion can be referred to + via the service offered as described in identifier_type. + identifier_type(NX_CHAR): + doc: | + How can the identifier be resolved? + enumeration: [inchi] + ion_type(NX_UINT): + doc: | + Ion type (ion species) identifier. + + The identifier zero is reserved for the special unknown ion type. + unit: NX_UNITLESS + nuclide_hash(NX_UINT): + doc: | + Vector of nuclide hash values. + + Individual hash values :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` + encode the number of protons :math:`Z` and the number of neutrons :math:`N` + of each nuclide respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. + + The array is sorted in decreasing order. For the rationale behind this see `M. Kühbach et al. (2021) `_ + unit: NX_UNITLESS + dim: (n_ivec_max,) + nuclide_list(NX_UINT): + doc: | + Table which decodes the entries in nuclide_hash into a human-readable matrix of instances. + The first column specifies the nuclide mass number, i.e. using the hashvalues + from the isotope_vector this is :math:`Z + N` or 0. The value 0 documents that no + isotope-specific information about the element encoded is relevant. + The second row specifies the number of protons :math:`Z` or 0. + The value 0 in this case documents a placeholder or that no element-specific + information is relevant. + Taking a carbon-14 nuclide as an example the mass number is 14. + That is encoded as a value pair (14, 6) as one row of the table. + + Therefore, this notation is the typical superscribed nuclide mass number + and subscripted number of protons element notation e.g. :math:`^{14}C`. + The array is stored matching the order of nuclide_hash. + unit: NX_UNITLESS + dim: (n_ivecmax, 2) + # color(NX_CHAR): + # doc: | + # Color code used for visualizing such ions. + volume(NX_NUMBER): + doc: | + Assumed volume of the ion. + + In atom probe microscopy this field can be used to store the reconstructed + volume per ion (average) which is typically stored alongside ranging + definitions. + unit: NX_VOLUME + charge(NX_NUMBER): + doc: | + Charge of the ion. + unit: NX_CHARGE + charge_state(NX_NUMBER): + doc: | + Signed charge state if the atoms form an ion reported in multiples of electron charge. + + In the example of atom probe microscopy, only positive values will be measured + as the ions are accelerated by a negatively signed bias electric field. + In the case that the charge state is not explicitly recoverable, the value should + be set to zero. + + In atom probe microscopy this is for example the case when using + classical ranging definition files in formats like RNG, RRNG. + These file formats do not document the charge state explicitly + but the number of atoms of each element per molecular ion + surplus the mass-to-charge-state-ratio interval. + Details on ranging definition files can be found in the literature: + `M. K. Miller `_ + unit: NX_UNITLESS + name(NX_CHAR): + doc: | + Human-readable name (e.g. Al +++) of the atom set, the atom group, or ion type. + The string should consists of UTF-8 characters, ideally using LaTeX + notation to specify the isotopes, ions, and charge state. + Examples are 12C + or Al +++. + + To ease automated parsing, isotope_vector should be the + preferred machine-readable information used. + mass_to_charge_range(NX_NUMBER): + doc: | + Associated lower (mqmin) and upper (mqmax) bounds of the + mass-to-charge-state ratio interval(s) [mqmin, mqmax] + (boundaries inclusive). This field is primarily of interest + for documenting :ref:`NXprocess` steps of indexing a + ToF/mass-to-charge state histogram. + unit: NX_ANY # u + dim: (n_ranges, 2) diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index 4f23c54030..0ae23415d6 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -1211,8 +1211,8 @@ NXem(NXobject): exists: [min, 0, max, infty] doc: - | - A region-of-interest analyzed either during or after the session for which - specific processed data are available. + A region-of-interest analyzed either during or after the session + for which specific processed data are available. - | xref: spec: EMglossary @@ -1222,12 +1222,15 @@ NXem(NXobject): # an RDM can be sure to find specific pieces of information in a # specific way but then every user of this application definition # is required to provide such information in this way! - se(NXem_img): + imaging(NXem_img): exists: optional - # remains to be discussed based on examples - bse(NXem_img): - exists: optional - # remains to be discussed based on examples + imaging_mode(NX_CHAR): + (NXimage_set): + exists: [min, 0, max, infty] + half_angle_interval(NX_NUMBER): + exists: optional + microstructureID(NXmicrostructure): + exists: optional ebsd(NXem_ebsd): exists: optional # remains to be discussed based on examples @@ -1353,13 +1356,8 @@ NXem(NXobject): axis_j(NX_NUMBER): # y \@long_name(NX_CHAR): \@units(NX_CHAR): # exemplar test to enforce that units are added - adf(NXem_adf): - exists: optional - # remains to be discussed based on examples eels(NXem_eels): exists: optional - # cl(NXem_cl): - # exists: optional correlation(NXem_correlation): exists: optional # remains to be discussed based on examples diff --git a/contributed_definitions/nyaml/NXem_adf.yaml b/contributed_definitions/nyaml/NXem_adf.yaml deleted file mode 100644 index c64af34d45..0000000000 --- a/contributed_definitions/nyaml/NXem_adf.yaml +++ /dev/null @@ -1,19 +0,0 @@ -category: base -doc: | - Base class method-specific for annular dark field imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). Examples can be single point aka spot - measurements, line profiles, or (rectangular) surface mappings. - The latter pattern is the most frequently used. - - For now the base class provides for scans for which the settings, - binning, and energy resolution is the same for each scan point. -type: group -NXem_adf(NXem_method): - (NXimage_set): - half_angle_interval(NX_NUMBER): - doc: | - Annulus inner (first value) and outer (second value) half angle. - unit: NX_ANGLE - dim: (2,) diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml index a89e5c06f3..82486fbdb0 100644 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -15,7 +15,7 @@ doc: | # energy typically the fastest direction symbols: n_photon_energy: | - Number of X-ray photon energy (bins) + Number of X-ray photon energy (bins) n_elements: | Number of identified elements n_peaks: | diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml index 57f9202445..015e6fa7dc 100644 --- a/contributed_definitions/nyaml/NXem_img.yaml +++ b/contributed_definitions/nyaml/NXem_img.yaml @@ -9,16 +9,19 @@ doc: | For now the base class provides for scans for which the settings, binning, and energy resolution is the same for each scan point. -symbols: - n_images: | - Number of images in the stack. - n_y: | - Number of pixel per image in the slow direction. - n_x: | - Number of pixel per image in the fast direction. type: group NXem_img(NXem_method): imaging_mode(NX_CHAR): doc: | Which imaging mode was used? - enumeration: [secondary_electron, backscattered_electron] + enumeration: [secondary_electron, backscattered_electron, annular_dark_field, cathodoluminescence] + (NXimage_set): + half_angle_interval(NX_NUMBER): + doc: | + Annulus inner (first value) and outer (second value) half angle. + unit: NX_ANGLE + dim: (2,) + (NXmicrostructure): + doc: | + A reconstruction of the microstructure or some of its features + based on image information in the parent class. diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml index f4d7df4a14..28c880f000 100644 --- a/contributed_definitions/nyaml/NXem_method.yaml +++ b/contributed_definitions/nyaml/NXem_method.yaml @@ -7,9 +7,8 @@ doc: | definition gets equipped with specific groups to document method-specific processing steps and report analyzed quantities. - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. -# :ref:`NXem_se`, :ref:`NXem_bse`. + The template base class name :ref:`NXem_method` needs to be changed for + each method e.g. :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. type: group NXem_method(NXobject): (NXprocess): diff --git a/contributed_definitions/nyaml/NXmicrostructure.yaml b/contributed_definitions/nyaml/NXmicrostructure.yaml index e671a49043..88af25f7f5 100644 --- a/contributed_definitions/nyaml/NXmicrostructure.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure.yaml @@ -131,6 +131,9 @@ NXmicrostructure(NXobject): Threshold to define at which disorientation angle to assume two crystalline regions have a significant orientation difference that warrants to assume that there exists an interface between the two regions. unit: NX_ANGLE + (NXprogram): + doc: | + The program with which the microstructure was reconstructed. # use controlled vocabulary terms grid, point, line, surface, volume, use singular term when instantiating (NXcg_grid): (NXcg_point_set): diff --git a/manual/source/classes/contributed_definitions/apm-structure.rst b/manual/source/classes/contributed_definitions/apm-structure.rst index ba275045ce..2cbeaae4a3 100644 --- a/manual/source/classes/contributed_definitions/apm-structure.rst +++ b/manual/source/classes/contributed_definitions/apm-structure.rst @@ -47,7 +47,7 @@ The following base classes are proposed to support modularizing the storage of p Base classes to describe different coordinate systems used and/or to be harmonized or transformed into one another when interpreting the dataset. - :ref:`NXion`: + :ref:`NXion`: (about to become replaced by :ref:`NXatom_set`) A base class to describe molecular ions with an adjustable number of atoms/isotopes building each ion. For the usage in atom probe research the maximum number of atoms supported building a molecular ion is currently set to a maximum of 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with @@ -57,7 +57,7 @@ The following base classes are proposed to support modularizing the storage of p A base class to bundle manufacturer/technology-partner-specific details about a component or device of an instrument. - :ref:`NXpeak`: + :ref:`NXpeak`: (about to become complemented by NXpeak_fitting) A base class to describe peaks mathematically to detail how peaks in mass-to-charge-state ratio histograms (aka mass spectra) are defined and labelled as iontypes. diff --git a/manual/source/classes/contributed_definitions/em-structure.rst b/manual/source/classes/contributed_definitions/em-structure.rst index 4e586e21a3..bd37436503 100644 --- a/manual/source/classes/contributed_definitions/em-structure.rst +++ b/manual/source/classes/contributed_definitions/em-structure.rst @@ -154,7 +154,7 @@ storage (i.e. serialization) using NeXus. More consolidation through the use of NXsubentry classes should be considered in the future. For now we use an approach whereby base classes are combined to reuse vocabulary and a hierarchical organization of pieces of information with specific constraints which are relevant only for specific usage of such data by specific tools used by an eventually smaller circle of users. - :ref:`NXem_method`, :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eds`, :ref:`NXem_eels`, :ref:`NXem_img`, :ref:`NXem_correlation`: + :ref:`NXem_method`, :ref:`NXem_ebsd`, :ref:`NXem_eds`, :ref:`NXem_eels`, :ref:`NXem_img`, :ref:`NXem_correlation`: Base classes with method-specific details especially when it comes to reporting post-processed data within electron microscopy. :ref:`NXcrystal_structure`: From 073f941ab90740f79a12ed3ec269ebea2343df2a Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 4 Sep 2024 17:27:41 +0200 Subject: [PATCH 0916/1012] Removal of non-standardized assumption that i, j, k can be used as counter variables in case one does not know the actual dimensions but one is sure it is not a scalar --- .../NXapm_charge_state_analysis.nxdl.xml | 7 +- ...Xapm_paraprobe_intersector_config.nxdl.xml | 9 +- .../NXapm_paraprobe_spatstat_results.nxdl.xml | 29 +- ...Xapm_paraprobe_transcoder_results.nxdl.xml | 7 +- .../NXapm_volt_and_bowl.nxdl.xml | 2 +- .../NXem_calorimetry.nxdl.xml | 299 ++++++++++++++++++ contributed_definitions/NXem_ebsd.nxdl.xml | 9 +- contributed_definitions/NXem_eds.nxdl.xml | 7 +- .../NXmicrostructure_mtex_config.nxdl.xml | 19 +- .../NXmicrostructure_odf.nxdl.xml | 9 +- .../nyaml/NXapm_charge_state_analysis.yaml | 4 +- .../NXapm_paraprobe_intersector_config.yaml | 6 +- .../NXapm_paraprobe_spatstat_results.yaml | 22 +- .../NXapm_paraprobe_transcoder_results.yaml | 4 +- .../nyaml/NXapm_volt_and_bowl.yaml | 2 +- .../nyaml/NXem_calorimetry.yaml | 213 +++++++++++++ contributed_definitions/nyaml/NXem_ebsd.yaml | 6 +- contributed_definitions/nyaml/NXem_eds.yaml | 4 +- .../nyaml/NXmicrostructure_mtex_config.yaml | 10 +- .../nyaml/NXmicrostructure_odf.yaml | 6 +- 20 files changed, 626 insertions(+), 48 deletions(-) create mode 100644 contributed_definitions/NXem_calorimetry.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXem_calorimetry.yaml diff --git a/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml b/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml index 9441eb0369..e0adb79803 100644 --- a/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml +++ b/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml @@ -36,6 +36,11 @@ Maximum number of allowed atoms per (molecular) ion (fragment). + + + Number of entries + + Base class to document an algorithm for recovering charge state and nuclide composition of a (molecular) ion. @@ -76,7 +81,7 @@ input/config--> analysis may become very time consuming! - + diff --git a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml index db520494fe..efdbdf9aeb 100644 --- a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml @@ -26,6 +26,11 @@ The symbols used in the schema to specify e.g. dimensions of arrays. + + + Number of entries + + Application definition for a configuration file of the paraprobe-intersector tool. @@ -181,7 +186,7 @@ automatically. - + @@ -246,7 +251,7 @@ automatically. - + diff --git a/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml index be81d48063..52187c9518 100644 --- a/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml @@ -21,9 +21,6 @@ # # For further information, see http://www.nexusformat.org --> - @@ -34,6 +31,16 @@ n_bins_knn: | The total number of ions in the reconstruction. + + + The total number of bins in the histogram for the k-th nearest neighbor. + + + + + The total number of bins in the histogram for the radial distribution function. + + Application definition for results files of the paraprobe-spatstat tool. @@ -78,12 +85,12 @@ n_bins_knn: | Right boundary of the binning. - + - + @@ -91,7 +98,7 @@ n_bins_knn: | Cumulated not normalized by total counts. - + @@ -99,7 +106,7 @@ n_bins_knn: | Cumulated and normalized by total counts. - + @@ -112,12 +119,12 @@ n_bins_knn: | Right boundary of the binning. - + - + @@ -125,7 +132,7 @@ n_bins_knn: | Cumulated not normalized by total counts. - + @@ -133,7 +140,7 @@ n_bins_knn: | Cumulated and normalized by total counts. - + diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml index a5519759a2..3153d95581 100644 --- a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml @@ -44,6 +44,11 @@ i be careful n_comb can vary for every instance of (NXion) !--> Total number of integers in the supplementary XDMF topology array. + + + Number of entries + + Application definition for results files of the paraprobe-transcoder tool. @@ -150,7 +155,7 @@ config--> - + diff --git a/contributed_definitions/NXapm_volt_and_bowl.nxdl.xml b/contributed_definitions/NXapm_volt_and_bowl.nxdl.xml index f317e76cbc..30bdbb0fde 100644 --- a/contributed_definitions/NXapm_volt_and_bowl.nxdl.xml +++ b/contributed_definitions/NXapm_volt_and_bowl.nxdl.xml @@ -55,7 +55,7 @@ result--> Raw time-of-flight data without corrections. - + diff --git a/contributed_definitions/NXem_calorimetry.nxdl.xml b/contributed_definitions/NXem_calorimetry.nxdl.xml new file mode 100644 index 0000000000..632722293e --- /dev/null +++ b/contributed_definitions/NXem_calorimetry.nxdl.xml @@ -0,0 +1,299 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + + Number of pattern + + + + + Number of azimuthal integration bins + + + + + Number of coordinates along i axis. + + + + + Number of coordinates along j axis. + + + + + Application definition for minimal example in-situ calorimetry. + + What is the technique about. + + General context. + + Literature references. + + + + + + + + + + + + + + + + + + + + + + + + + + Reference to the resource which stores acquired pattern from the experiment. + + Can refer to the original EMD or MRC files or the parsed NXem in RDM e.g. NOMAD OASIS. + + + + + + + + + Reference to the resource which stores actuator log file from the experiment. + + + + + + + + + Assumptions and computations whereby timestamp data from the + detector used for collecting diffraction pattern and the actuator + (heating chip) were synchronized. + + + + + + + + + + Timestamp when pattern acquisition started. + + + + + + + + Timestamp when pattern acquisition ended. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Acquired diffraction pattern azimuthally integrated as a function of time. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Time since start of the in-situ experiment + + + + + + + + + + + + + + + + + + + + + + Azimuthally integrated diffraction intensities corrected for background as a + function of time. + + + + + + + + + + + + + + + + + + + + + + + + + + + + Time since start of the in-situ experiment + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index 43ff69a43a..8fcfe0e523 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -51,6 +51,11 @@ standardized default plot orientation mapping. + + + Number of phase solutions + + Base class method-specific for Electron Backscatter Diffraction (EBSD). @@ -565,7 +570,7 @@ pattern_available(NX_BOOLEAN): for those scan points with no phases according to n_phases_per_scan_point - + @@ -576,7 +581,7 @@ pattern_available(NX_BOOLEAN): See documentation of phase_identifier for further details. - + diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml index f9320293b4..6e3d797332 100644 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -41,6 +41,11 @@ energy typically the fastest direction--> Number of peaks detected + + + Number of IUPAC line names + + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDXS). @@ -130,7 +135,7 @@ and Adrien Teutrie, Cecile Hebert (EPFL)--> multiple lines are grouped with the same peak. - + diff --git a/contributed_definitions/NXmicrostructure_mtex_config.nxdl.xml b/contributed_definitions/NXmicrostructure_mtex_config.nxdl.xml index 32cc902d72..2dae22c987 100644 --- a/contributed_definitions/NXmicrostructure_mtex_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_mtex_config.nxdl.xml @@ -22,6 +22,18 @@ # For further information, see http://www.nexusformat.org --> + + + + Number of entries in the default color map + + + + + Number of entries in color map + + + Base class to store the configuration when using the MTex/Matlab software. @@ -119,7 +131,7 @@ check against v5.12--> TODO with MTex developers - + @@ -128,15 +140,14 @@ check against v5.12--> TODO with MTex developers - + + unit: NX_UNITLESS--> diff --git a/contributed_definitions/NXmicrostructure_odf.nxdl.xml b/contributed_definitions/NXmicrostructure_odf.nxdl.xml index b0e3311de9..764e0ab77d 100644 --- a/contributed_definitions/NXmicrostructure_odf.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_odf.nxdl.xml @@ -45,6 +45,11 @@ Number of local maxima evaluated in the component analysis. + + + Number of sampled positions in orientation space. + + Base class to store an orientation distribution function (ODF). @@ -149,7 +154,7 @@ in orientation space for which a weight was sampled. - + @@ -158,7 +163,7 @@ Weight at each sampled position following the order in euler. - + diff --git a/contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml b/contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml index fcd276e68d..35b3295598 100644 --- a/contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml +++ b/contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml @@ -23,6 +23,8 @@ symbols: The number of also possible but different (molecular) ions. n_ivec_max: | Maximum number of allowed atoms per (molecular) ion (fragment). + n_variable: | + Number of entries type: group NXapm_charge_state_analysis(NXprocess): # Details and results of the combinatorial analyses of a ranging definition @@ -45,7 +47,7 @@ NXapm_charge_state_analysis(NXprocess): Keep in mind that with a weakly constrained parameter space the combinatorial analysis may become very time consuming! unit: NX_UNITLESS - dim: (i,) + dim: (n_variable,) mass_to_charge_range(NX_FLOAT): doc: | Input constraint, interval within which (molecular) ions need to have the diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml index 953bdbabf4..319ced4c4c 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml @@ -6,6 +6,8 @@ doc: | symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. + n_variable: | + Number of entries type: group NXapm_paraprobe_intersector_config(NXobject): (NXentry): @@ -121,7 +123,7 @@ NXapm_paraprobe_intersector_config(NXobject): doc: | Array of identifier whereby the path to the geometry data can be interferred automatically. unit: NX_UNITLESS - dim: (i,) + dim: (n_variable,) next_set(NXobject): doc: | Next set stores a set of members, meshes of volumetric features, @@ -168,7 +170,7 @@ NXapm_paraprobe_intersector_config(NXobject): doc: | Array of identifier whereby the path to the geometry data can be interferred automatically. unit: NX_UNITLESS - dim: (i,) + dim: (n_variable,) ##MK::tetrahedra volume intersection and tessellation and Nef polyhedra intersection are considered guru features # and therefore currently supported only via modifying the C/C++ source code directly as one should know exactly # what one is doing here before using these functionalities diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml index da1164bd61..4a377bb4c3 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml @@ -8,8 +8,10 @@ symbols: The symbols used in the schema to specify e.g. dimensions of arrays. n_ions: | The total number of ions in the reconstruction. - # n_bins_knn: | - # The total number of bins in the histogram for the k-th nearest neighbor + n_knn: | + The total number of bins in the histogram for the k-th nearest neighbor. + n_rdf: | + The total number of bins in the histogram for the radial distribution function. type: group NXapm_paraprobe_spatstat_results(NXobject): (NXentry): @@ -44,20 +46,20 @@ NXapm_paraprobe_spatstat_results(NXobject): doc: | Right boundary of the binning. unit: NX_LENGTH - dim: (i,) + dim: (n_knn,) probability_mass(NX_FLOAT): unit: NX_DIMENSIONLESS - dim: (i,) + dim: (n_knn,) cumulated(NX_FLOAT): doc: | Cumulated not normalized by total counts. unit: NX_UNITLESS - dim: (i,) + dim: (n_knn,) cumulated_normalized(NX_FLOAT): doc: | Cumulated and normalized by total counts. unit: NX_DIMENSIONLESS - dim: (i,) + dim: (n_knn,) rdf(NXprocess): exists: optional doc: | @@ -66,20 +68,20 @@ NXapm_paraprobe_spatstat_results(NXobject): doc: | Right boundary of the binning. unit: NX_LENGTH - dim: (j,) + dim: (n_rdf,) probability_mass(NX_FLOAT): unit: NX_DIMENSIONLESS - dim: (j,) + dim: (n_rdf,) cumulated(NX_FLOAT): doc: | Cumulated not normalized by total counts. unit: NX_UNITLESS - dim: (j,) + dim: (n_rdf,) cumulated_normalized(NX_FLOAT): doc: | Cumulated and normalized by total counts. unit: NX_DIMENSIONLESS - dim: (j,) + dim: (n_rdf,) common(NXapm_paraprobe_tool_common): status(NX_CHAR): analysis_identifier(NX_UINT): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml index c4f73ef8e0..52d8f25aeb 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml @@ -33,6 +33,8 @@ symbols: Needs to match maximum_number_of_atoms_per_molecular_ion. n_topology: | Total number of integers in the supplementary XDMF topology array. + n_variable: | + Number of entries # i be careful n_comb can vary for every instance of (NXion) ! type: group NXapm_paraprobe_transcoder_results(NXobject): @@ -99,7 +101,7 @@ NXapm_paraprobe_transcoder_results(NXobject): charge_state(NX_INT): mass_to_charge_range(NX_FLOAT): unit: NX_ANY # u - dim: (i, 2) + dim: (n_variable, 2) # (NXapm_charge_state_analysis): common(NXapm_paraprobe_tool_common): status(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_volt_and_bowl.yaml b/contributed_definitions/nyaml/NXapm_volt_and_bowl.yaml index 25cba988cd..5a52bd765c 100644 --- a/contributed_definitions/nyaml/NXapm_volt_and_bowl.yaml +++ b/contributed_definitions/nyaml/NXapm_volt_and_bowl.yaml @@ -27,7 +27,7 @@ NXapm_volt_and_bowl(NXprocess): # when evolving these ideas further inherit fro doc: | Raw time-of-flight data without corrections. unit: NX_TIME - dim: (i,) + dim: (n,) calibrated_tof(NX_FLOAT): doc: | Calibrated time-of-flight. diff --git a/contributed_definitions/nyaml/NXem_calorimetry.yaml b/contributed_definitions/nyaml/NXem_calorimetry.yaml new file mode 100644 index 0000000000..b4f3deff57 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_calorimetry.yaml @@ -0,0 +1,213 @@ +category: application +doc: | + Application definition for minimal example in-situ calorimetry. + + What is the technique about. + + General context. + + Literature references. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_p: | + Number of diffraction pattern. + n_f: | + Number of radial integration bins. + n_i: | + Number of coordinates along i axis. + n_j: | + Number of coordinates along j axis. +# intentionally axes are not named x, y, z to +# i) assure indices can be used for real and complex, +# ii) that people think hard about how their base vectors are aligned with what and how to name things + n_p: | + Number of pattern + n_f: | + Number of azimuthal integration bins +type: group +# for a proper instance of a NeXus file also root level attributes should be set +# NeXus version, h5py version, again can be done later, we have tons of examples +NXem_calorimetry(NXobject): + # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently + (NXentry): + exists: [min, 1, max, 1] + definition(NX_CHAR): + \@version(NX_CHAR): + exists: optional + enumeration: [NXem_calorimetry] + # take here inspiration from the dozens of example appdefs + # e.g. NXem, NXapm_paraprobe_* which shows how to add context + identifier(NXidentifier): + exists: optional + # a place whereby you can refer to your simulation run, etc + (NXuser): + exists: optional + # a place where you can give details about people who did it + (NXsample): + exists: optional + # a place where you can tell e.g. based on which sample you build this simulation + (NXcite): + exists: [min, 0, max, infty] + # a place where to add citations for your work ... + (NXcoordinate_system_set): + diffraction_space(NXcoordinate_system): + (NXcoordinate_system): + exists: [min, 0, max, infty] + # a place where you can describe your coordinate system conventions + # hook-in NXem, alternatively inherit from NXem and just add + # add an actuator(NXactuator): + # doc: | + # DENSsolution heating chip. + # physical_quantity(NX_CHAR): + # # enumeration: [temperature] + # event_data for the actual sensor data + # alternatively + diffraction(NXsource): + doc: | + Reference to the resource which stores acquired pattern from the experiment. + + Can refer to the original EMD or MRC files or the parsed NXem in RDM e.g. NOMAD OASIS. + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + actuator(NXserialized): + doc: | + Reference to the resource which stores actuator log file from the experiment. + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + time_synchronization(NXprocess): + doc: | + Assumptions and computations whereby timestamp data from the + detector used for collecting diffraction pattern and the actuator + (heating chip) were synchronized. + sequence_index(NX_POSINT): + pattern_identifier(NX_UINT): + dim: (n_p,) + unit: NX_UNITLESS + start_time(NX_DATE_TIME): + doc: | + Timestamp when pattern acquisition started. + dim: (n_p,) + end_time(NX_DATE_TIME): + doc: | + Timestamp when pattern acquisition ended. + dim: (n_p,) + # alternatively only timestamp + pattern_center(NXprocess): + sequence_index(NX_POSINT): + config(NXcollection): + result(NXcg_point_set): + # depends_on(NX_CHAR): + # doc: | + # Hint to help resolve in which coordinate system position values are defined. + position(NX_NUMBER): + unit: NX_LENGTH + dim: (n_p, 2) + #\@units: 1/nm + distortion_correction(NXprocess): + exists: optional + sequence_index(NX_POSINT): + programID(NXprogram): + exists: optional + program(NX_CHAR): + \@version(NX_CHAR): + config(NXcollection): + result(NXcg_ellipsoid_set): + # depends_on(NX_CHAR): + center(NX_NUMBER): + unit: NX_LENGTH + dim: (n_p, 2) + #\@units: 1/nm + azimuthal_integration(NXprocess): + # no exists, i.e. assuming required + doc: | + Acquired diffraction pattern azimuthally integrated as a function of time. + sequence_index(NX_POSINT): + programID(NXprogram): + exists: optional + program(NX_CHAR): + \@version(NX_CHAR): + config(NXcollection): + # TODO integration parameter + result(NXdata): + \@signal(NX_CHAR): + \@axes(NX_CHAR): # [axis_s] + \@AXISNAME_indices(NX_CHAR): + title(NX_CHAR): + intensity(NX_FLOAT): + dim: (n_p, n_f) + unit: NX_UNITLESS + \@long_name(NX_CHAR): + axis_pattern_identifier(NX_UINT): + dim: (n_p,) + unit: NX_UNITLESS + \@long_name(NX_CHAR): + axis_s(NX_FLOAT): + dim: (n_f,) + unit: NX_ANY + #\@units: 1/nm + \@long_name(NX_CHAR): + axis_time(NX_FLOAT): + doc: | + Time since start of the in-situ experiment + dim: (n_p,) + unit: NX_TIME + # \@units: s + background_subtraction(NXprocess): + exists: recommended + sequence_index(NX_POSINT): + programID(NXprogram): + program(NX_CHAR): + \@version(NX_CHAR): + config(NXcollection): + # TODO integration parameter + background(NXcollection): + # TODO e.g. could add parameter of functional forms for the background of each pattern + result(NXdata): + doc: | + Azimuthally integrated diffraction intensities corrected for background as a function of time. + \@signal(NX_CHAR): + \@axes(NX_CHAR): # [axis_time, axis_s] + \@AXISNAME_indices(NX_CHAR): + title(NX_CHAR): + intensity(NX_FLOAT): + dim: (n_p, n_f) + unit: NX_UNITLESS + \@long_name(NX_CHAR): + axis_pattern_identifier(NX_UINT): + dim: (n_p,) + unit: NX_UNITLESS + \@long_name(NX_CHAR): + axis_s(NX_FLOAT): + dim: (n_f,) + unit: NX_ANY + #\@units: 1/nm + \@long_name(NX_CHAR): + axis_time(NX_FLOAT): + doc: | + Time since start of the in-situ experiment + dim: (n_p,) + unit: NX_TIME + # \@units: s + # peak_fitting(NXpeak_fitting): + # exists: optional + # doc: | + # Background-corrected azimuthally integrated signals indexed for peaks. + # more NXprocess groups could follow only sky is the limit and your imagination and time devotion + profiling(NXcs_profiling): + exists: optional + # possible place to store details about performance, profiling, etc. + current_working_directory(NX_CHAR): + exists: recommended + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + total_elapsed_time(NX_NUMBER): + # number_of_processes(NX_POSINT): + # number_of_threads(NX_POSINT): + # number_of_gpus(NX_POSINT): diff --git a/contributed_definitions/nyaml/NXem_ebsd.yaml b/contributed_definitions/nyaml/NXem_ebsd.yaml index 67d10fa851..b6fb3dba97 100644 --- a/contributed_definitions/nyaml/NXem_ebsd.yaml +++ b/contributed_definitions/nyaml/NXem_ebsd.yaml @@ -106,6 +106,8 @@ symbols: n_x: | Number of pixel along fast changing dimension for a rediscretized i.e. standardized default plot orientation mapping. + n_solutions: | + Number of phase solutions type: group NXem_ebsd(NXem_method): # (NXcoordinate_system): @@ -404,7 +406,7 @@ NXem_ebsd(NXem_method): the 1-th scan point, the n_sc - 1 th scan point and omitting tuples for those scan points with no phases according to n_phases_per_scan_point unit: NX_UNITLESS - dim: (i,) + dim: (n_solutions,) phase_matching(NX_INT): doc: | One-dimensional array, pattern by pattern labelling the solutions found. @@ -412,7 +414,7 @@ NXem_ebsd(NXem_method): how the phase_identifier and the phase_matching arrays have to be interpreted. See documentation of phase_identifier for further details. unit: NX_UNITLESS - dim: (i,) + dim: (n_solutions,) phase_matching_descriptor(NX_CHAR): doc: | Phase_matching is a descriptor for how well the solution matches or not. diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml index 82486fbdb0..c9a6b03c14 100644 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -20,6 +20,8 @@ symbols: Number of identified elements n_peaks: | Number of peaks detected + n_iupac_line_names: | + Number of IUPAC line names type: group NXem_eds(NXem_method): # NXprocess is composed from NXem_method base class instances where the spectra @@ -76,7 +78,7 @@ NXem_eds(NXem_method): This can be a list of IUPAC notations for (the seldom) case that multiple lines are grouped with the same peak. - dim: (i,) + dim: (n_iupac_line_names,) atom_types(NX_CHAR): doc: | Comma-separated list of names of elements confirmed in the sample via EDS analysis. diff --git a/contributed_definitions/nyaml/NXmicrostructure_mtex_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_mtex_config.yaml index 041c57987d..b33d27a1b7 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_mtex_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_mtex_config.yaml @@ -5,6 +5,11 @@ doc: | MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. See `R. Hielscher et al. `_ and the `MTex source code `_ for details. +symbols: + n_def_color_map: | + Number of entries in the default color map + n_color_map: | + Number of entries in color map type: group NXmicrostructure_mtex_config(NXobject): conventions(NXcollection): @@ -67,17 +72,16 @@ NXmicrostructure_mtex_config(NXobject): doc: | TODO with MTex developers unit: NX_UNITLESS - dim: (i, 3) + dim: (n_color_map, 3) default_color_map(NX_NUMBER): doc: | TODO with MTex developers unit: NX_UNITLESS - dim: (i, 3) + dim: (n_def_color_map, 3) # phase_color_order: # doc: | # TODO with MTex developers # unit: NX_UNITLESS - # dim: (i,) color_palette(NX_CHAR): degree_char(NX_CHAR): doc: | diff --git a/contributed_definitions/nyaml/NXmicrostructure_odf.yaml b/contributed_definitions/nyaml/NXmicrostructure_odf.yaml index 596fbb994b..119dc6b691 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_odf.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_odf.yaml @@ -14,6 +14,8 @@ symbols: Number of pixel per varphi section plot along the :math:`\varphi_2` slow direction. k: | Number of local maxima evaluated in the component analysis. + n_pos: | + Number of sampled positions in orientation space. type: group NXmicrostructure_odf(NXprocess): configuration(NXobject): @@ -83,12 +85,12 @@ NXmicrostructure_odf(NXprocess): Bunge-Euler (i.e. ZXZ convention) locations of each position in orientation space for which a weight was sampled. unit: NX_ANGLE - dim: (i, 3) + dim: (n_pos, 3) weight(NX_NUMBER): doc: | Weight at each sampled position following the order in euler. unit: NX_DIMENSIONLESS # intensity of ODF at euler / intensity of random ODF at euler - dim: (i,) + dim: (n_pos,) phi_two_plot(NXdata): doc: | Visualization of the ODF intensity as discretized orthogonal sections through From 5659cc537936b1fe17a0a65a0484051715132a28 Mon Sep 17 00:00:00 2001 From: Ron Hildebrandt Date: Fri, 6 Sep 2024 08:34:01 +0200 Subject: [PATCH 0917/1012] add missing elements in ellipsometry from specialized NXlens_opt --- contributed_definitions/NXellipsometry.nxdl.xml | 11 ++++++++++- contributed_definitions/nyaml/NXellipsometry.yaml | 5 ++++- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/NXellipsometry.nxdl.xml b/contributed_definitions/NXellipsometry.nxdl.xml index 67e4f1ca65..3ef8bcba85 100644 --- a/contributed_definitions/NXellipsometry.nxdl.xml +++ b/contributed_definitions/NXellipsometry.nxdl.xml @@ -209,7 +209,16 @@ TODO (Workshop output): If focussing probes (lenses) were used, please state if the data were corrected for the window effects. - + + + + + + + + + + Were the recorded data corrected by the window effects of the diff --git a/contributed_definitions/nyaml/NXellipsometry.yaml b/contributed_definitions/nyaml/NXellipsometry.yaml index c5ad226032..98764d8d9b 100644 --- a/contributed_definitions/nyaml/NXellipsometry.yaml +++ b/contributed_definitions/nyaml/NXellipsometry.yaml @@ -126,7 +126,10 @@ NXellipsometry(NXoptical_spectroscopy): doc: | If focussing probes (lenses) were used, please state if the data were corrected for the window effects. - # This as well can be stated in window/aperture + type: + enumeration: [objective, lens, glass fiber, none, other] + device_information(NXfabrication): + exists: optional data_correction(NX_BOOLEAN): exists: recommended doc: | From b6b65505bbbcc99cce5d53fd57f308bfc2dc047e Mon Sep 17 00:00:00 2001 From: Ron Hildebrandt Date: Fri, 6 Sep 2024 09:59:42 +0200 Subject: [PATCH 0918/1012] Add todo notes for beamsize and shape description --- contributed_definitions/NXoptical_spectroscopy.nxdl.xml | 3 ++- contributed_definitions/nyaml/NXoptical_spectroscopy.yaml | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/contributed_definitions/NXoptical_spectroscopy.nxdl.xml b/contributed_definitions/NXoptical_spectroscopy.nxdl.xml index 02ad766746..f19c7499eb 100644 --- a/contributed_definitions/NXoptical_spectroscopy.nxdl.xml +++ b/contributed_definitions/NXoptical_spectroscopy.nxdl.xml @@ -35,7 +35,8 @@ TODO: - Add optical elements and rework them: NXfiber, NXbeam_splitter, - Consider to make power flux recommended? Difficult parameter to measure. Relevant for some samples/techniques, but not for all. Powder density? Nominal vs. measured? - Is there something to describe the spot size? -- Restructure the concept "type" in "source_TYPE" to medium and model(NXfabication) -\-> suggestion from Markus: "splitting up the concept into type(NXfabrication) and emitting medium(NXion/NXatom) is a better alternative?"--> +- Restructure the concept "type" in "source_TYPE" to medium and model(NXfabication) -\-> suggestion from Markus: "splitting up the concept into type(NXfabrication) and emitting medium(NXion/NXatom) is a better alternative?" +- How to describe beam size properties? NXbeam/extend? Is this enough? or do we need more abitrary shapes as elliptically? Maybe as well focus spot size?--> diff --git a/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml b/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml index 935dee7fc4..db286f9b20 100644 --- a/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml +++ b/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml @@ -37,6 +37,7 @@ symbols: # - Consider to make power flux recommended? Difficult parameter to measure. Relevant for some samples/techniques, but not for all. Powder density? Nominal vs. measured? # - Is there something to describe the spot size? # - Restructure the concept "type" in "source_TYPE" to medium and model(NXfabication) --> suggestion from Markus: "splitting up the concept into type(NXfabrication) and emitting medium(NXion/NXatom) is a better alternative?" +# - How to describe beam size properties? NXbeam/extend? Is this enough? or do we need more abitrary shapes as elliptically? Maybe as well focus spot size? type: group NXoptical_spectroscopy(NXobject): (NXentry): From e1a998498a8fd03b9f8a7ee16a50fca06c790c62 Mon Sep 17 00:00:00 2001 From: Ron Hildebrandt Date: Fri, 6 Sep 2024 11:13:37 +0200 Subject: [PATCH 0919/1012] typo and note for possible rework/reconsideration of NXfabrication --- contributed_definitions/NXoptical_spectroscopy.nxdl.xml | 5 +++-- contributed_definitions/nyaml/NXoptical_spectroscopy.yaml | 3 ++- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/NXoptical_spectroscopy.nxdl.xml b/contributed_definitions/NXoptical_spectroscopy.nxdl.xml index f19c7499eb..69b901f552 100644 --- a/contributed_definitions/NXoptical_spectroscopy.nxdl.xml +++ b/contributed_definitions/NXoptical_spectroscopy.nxdl.xml @@ -36,7 +36,8 @@ TODO: - Consider to make power flux recommended? Difficult parameter to measure. Relevant for some samples/techniques, but not for all. Powder density? Nominal vs. measured? - Is there something to describe the spot size? - Restructure the concept "type" in "source_TYPE" to medium and model(NXfabication) -\-> suggestion from Markus: "splitting up the concept into type(NXfabrication) and emitting medium(NXion/NXatom) is a better alternative?" -- How to describe beam size properties? NXbeam/extend? Is this enough? or do we need more abitrary shapes as elliptically? Maybe as well focus spot size?--> +- How to describe beam size properties? NXbeam/extend? Is this enough? or do we need more abitrary shapes as elliptically? Maybe as well focus spot size? +- Think of removing/reworking of (optional) NXfabrications? Con: bloats up the NeXus def (move it to base classes?) Pro: as the fixed name device_information is used, the structure is more FAIR / clean designed?--> @@ -325,7 +326,7 @@ TODO: - + diff --git a/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml b/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml index db286f9b20..5f2853167a 100644 --- a/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml +++ b/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml @@ -38,6 +38,7 @@ symbols: # - Is there something to describe the spot size? # - Restructure the concept "type" in "source_TYPE" to medium and model(NXfabication) --> suggestion from Markus: "splitting up the concept into type(NXfabrication) and emitting medium(NXion/NXatom) is a better alternative?" # - How to describe beam size properties? NXbeam/extend? Is this enough? or do we need more abitrary shapes as elliptically? Maybe as well focus spot size? +# - Think of removing/reworking of (optional) NXfabrications? Con: bloats up the NeXus def (move it to base classes?) Pro: as the fixed name device_information is used, the structure is more FAIR / clean designed? type: group NXoptical_spectroscopy(NXobject): (NXentry): @@ -244,7 +245,7 @@ NXoptical_spectroscopy(NXobject): exists: recommended doc: | Description of the detector type. - enumeration: [CCD, photomultiplier, photodiode, avalanche-Photodiode, streak camera, bolometer, golay detectors, pyroelectric detector, deuterated triglycine sulphate, other] + enumeration: [CCD, photomultiplier, photodiode, avalanche-photodiode, streak camera, bolometer, golay detectors, pyroelectric detector, deuterated triglycine sulphate, other] detector_type_other: exists: optional doc: | From 550920974594041b8ad4e2fb969f9284460a0b45 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Mon, 9 Sep 2024 16:58:34 +0200 Subject: [PATCH 0920/1012] Suggestions from lukaspie --- contributed_definitions/NXapm.nxdl.xml | 4 +- .../NXcoordinate_system.nxdl.xml | 4 +- .../NXcoordinate_system_set.nxdl.xml | 215 -------------- contributed_definitions/NXem.nxdl.xml | 263 ++++++++++++++++-- contributed_definitions/nyaml/NXapm.yaml | 4 +- .../nyaml/NXcoordinate_system.yaml | 3 +- .../nyaml/NXcoordinate_system_set.yaml | 76 ----- contributed_definitions/nyaml/NXem.yaml | 130 ++++++++- 8 files changed, 368 insertions(+), 331 deletions(-) diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index 0c2f9b9fb9..862d4eaee2 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -201,7 +201,7 @@ the appdef definition here is nothing else then the documentation of this for a - + @@ -226,7 +226,7 @@ the appdef definition here is nothing else then the documentation of this for a used which are then arranged and documented with a description of the workflow so that actionable graphs become instantiatable. - + A qualifier whether the sample is a real one or a virtual one (in a computer simulation). diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 1f8b4efeb5..80de81f407 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -45,7 +45,8 @@ +https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 +enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left]--> An alternative name given to that coordinate system. @@ -84,6 +85,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d Exemplar values could be direction of gravity. + Base unit vector along the first axis which spans the coordinate system. diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/contributed_definitions/NXcoordinate_system_set.nxdl.xml index d75bebe7d0..a842d257d2 100644 --- a/contributed_definitions/NXcoordinate_system_set.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system_set.nxdl.xml @@ -209,74 +209,6 @@ convention 1 of DOI: 10.1088/0965-0393/23/8/083501 is implemented by inheriting Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the base vectors of this coordinate system as Xp, Yp, Zp. - - - Location of the origin of the processing_reference_frame. - - It is assumed that regions-of-interest in this reference frame form a rectangle or cuboid. - Edges are interpreted by inspecting the direction of their outer unit normals - (which point either parallel or antiparallel) along respective base vector direction - of the reference frame. - - If any of these assumptions is not met, the user is required to explicitly state this. - - - - - - - - - - - - - - - - Direction of the positively pointing x-axis base vector of the - processing_reference_frame. - - - - - - - - - - - - - - Direction of the positively pointing y-axis base vector of the - processing_reference_frame. - - - - - - - - - - - - - - Direction of the positively pointing z-axis base vector of the - processing_reference_frame. - - - - - - - - - - - @@ -291,80 +223,6 @@ convention 1 of DOI: 10.1088/0965-0393/23/8/083501 is implemented by inheriting Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the base vectors of this coordinate system as Xs, Ys, Zs. - - - Reference to the specifically named :ref:`NXsample` instance for - which these conventions apply (e.g. /entry1/sample1). - - - - - Location of the origin of the sample_reference_frame. - - It is assumed that regions-of-interest in this reference frame form a rectangle or cuboid. - Edges are interpreted by inspecting the direction of their outer unit normals - (which point either parallel or antiparallel) along respective base vector direction - of the reference frame. - - If any of these assumptions is not met, the user is required to explicitly state this. - - - - - - - - - - - - - - - - Direction of the positively pointing x-axis base vector of the - sample_reference_frame. - - - - - - - - - - - - - - Direction of the positively pointing y-axis base vector of the - sample_reference_frame. - - - - - - - - - - - - - - Direction of the positively pointing z-axis base vector of the - sample_reference_frame. - - - - - - - - - - - @@ -378,78 +236,5 @@ convention 1 of DOI: 10.1088/0965-0393/23/8/083501 is implemented by inheriting If any of these assumptions is not met, the user is required to explicitly state this. - - - Reference to the specifically named :ref:`NXdetector` instance for - which these conventions apply (e.g. /entry1/instrument/detector1). - - - - - Location of the origin of the detector_reference_frame. - - If the regions-of-interest forms a rectangle or cuboid, it is assumed that edges are interpreted - by inspecting the direction of their outer unit normals (which point either parallel or antiparallel) - along respective base vector direction of the reference frame. - - If any of these assumptions is not met, the user is required to explicitly state this. - - - - - - - - - - - - - - - - Direction of the positively pointing x-axis base vector of the - detector_reference_frame. - - - - - - - - - - - - - - Direction of the positively pointing y-axis base vector of the - detector_reference_frame. - - - - - - - - - - - - - - Direction of the positively pointing z-axis base vector of the - detector_reference_frame. - - - - - - - - - - - diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 42c19b7e59..18a772f91c 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -152,23 +152,16 @@ starting to reorganize the docstrings, as a list of blocks: An example how to use this set could be to document from which files, which have been e.g. generated by software of technology partners, the information in an instance of NXem was filled with during parsing or transcoding between different formats. - - If resources from technology partners would also be documented with semantic - technology there would not even be a necessity to copy over specific information - into other files as one could write inference and information/fact/knowledge retrieval - algorithm(s) whereby a specific piece of information that is related to an experiment - or simulation is read directly from the respective file of the technology partner. - - The reason why currently this works convincingly in hardly any research data management system - (RDMS) is the strong heterogeneity of the information contained in such files and the fact - that often context and documentation, specifically rich and strongly expressive semantic - documentation or contextualization is underdeveloped. + Information about persons who performed or were involved in the microscope @@ -199,12 +192,12 @@ starting to reorganize the docstrings, as a list of blocks: Writing the most permanently used email is recommended. - + Telephone number at the point in time when the experiment was performed. - + User role at the point in time when the experiment was performed. @@ -212,7 +205,7 @@ starting to reorganize the docstrings, as a list of blocks: principle investigator, or guest. - + Identifier offered by a service to report the user other than by using its name. @@ -226,13 +219,13 @@ starting to reorganize the docstrings, as a list of blocks: A physical entity which contains material intended to be investigated. - Sample and specimen are threaded as de facto synonyms. Samples can be real or virtual ones. + Sample and specimen are treated as de facto synonyms. Samples can be real or virtual ones. This concept is related to term `Specimen`_ of the EMglossary standard. .. _Specimen: https://purls.helmholtz-metadaten.de/emg/EMG_00000046 - + Qualifier whether the sample is a real or a virtual one. @@ -360,13 +353,240 @@ are the ibeam description capabilities not sufficient enough?--> how to define coordinate systems in NeXus. + + + - + + + + + + + + Location of the origin of the processing_reference_frame. + + It is assumed that regions-of-interest in this reference frame form a rectangle or cuboid. + Edges are interpreted by inspecting the direction of their outer unit normals + (which point either parallel or antiparallel) along respective base vector direction + of the reference frame. + + If any of these assumptions is not met, the user is required to explicitly state this. + + + + + + + + + + + + + + + + Direction of the positively pointing x-axis base vector of the + processing_reference_frame. + + + + + + + + + + + + + + Direction of the positively pointing y-axis base vector of the + processing_reference_frame. + + + + + + + + + + + + + + Direction of the positively pointing z-axis base vector of the + processing_reference_frame. + + + + + + + + + + + + + + + + Reference to the specifically named :ref:`NXsample` instance(s) for + which these conventions apply (e.g. /entry1/sample1). + + + - - - + + + Location of the origin of the sample_reference_frame. + + It is assumed that regions-of-interest in this reference frame form a rectangle or cuboid. + Edges are interpreted by inspecting the direction of their outer unit normals + (which point either parallel or antiparallel) along respective base vector direction + of the reference frame. + + If any of these assumptions is not met, the user is required to explicitly state this. + + + + + + + + + + + + + + + + Direction of the positively pointing x-axis base vector of the + sample_reference_frame. + + + + + + + + + + + + + + Direction of the positively pointing y-axis base vector of the + sample_reference_frame. + + + + + + + + + + + + + + Direction of the positively pointing z-axis base vector of the + sample_reference_frame. + + + + + + + + + + + + + + + + Reference to the specifically named :ref:`NXdetector` instance for + which these conventions apply (e.g. /entry1/instrument/detector1). + + + + + + + + Location of the origin of the detector_reference_frame. + + If the regions-of-interest forms a rectangle or cuboid, it is assumed that edges are interpreted + by inspecting the direction of their outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + + If any of these assumptions is not met, the user is required to explicitly state this. + + + + + + + + + + + + + + + + Direction of the positively pointing x-axis base vector of the + detector_reference_frame. + + + + + + + + + + + + + + Direction of the positively pointing y-axis base vector of the + detector_reference_frame. + + + + + + + + + + + + + + Direction of the positively pointing z-axis base vector of the + detector_reference_frame. + + + + + + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml index 61588cfcc5..e949087009 100644 --- a/contributed_definitions/nyaml/NXapm.yaml +++ b/contributed_definitions/nyaml/NXapm.yaml @@ -153,7 +153,7 @@ NXapm(NXobject): (NXuser): exists: recommended name(NX_CHAR): - exists: recommended + exists: optional identifier(NXidentifier): exists: recommended service(NX_CHAR): @@ -177,7 +177,7 @@ NXapm(NXobject): should be stored. For this specific application definitions/schemas can be used which are then arranged and documented with a description of the workflow so that actionable graphs become instantiatable. - method(NX_CHAR): + type(NX_CHAR): doc: | A qualifier whether the sample is a real one or a virtual one (in a computer simulation). diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml index c5f797ebc8..d9dc491fa7 100644 --- a/contributed_definitions/nyaml/NXcoordinate_system.yaml +++ b/contributed_definitions/nyaml/NXcoordinate_system.yaml @@ -18,11 +18,11 @@ NXcoordinate_system(NXobject): Exemplar values could be *left corner of the lab bench*, *door-handle* *pinhole through which the electron beam exists the pole piece*. *barycenter of the triangle*, *center of mass of the stone*. - # implementing a proposal for "a common base table" along thoughts like: # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations # similar to a place where all transformations are stored # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 + # enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] alias(NX_CHAR): doc: | An alternative name given to that coordinate system. @@ -44,6 +44,7 @@ NXcoordinate_system(NXobject): is the mighty world reference frame. Exemplar values could be direction of gravity. + # enumeration: [undefined, north, east, south, west, in, out] x(NX_NUMBER): unit: NX_LENGTH doc: | diff --git a/contributed_definitions/nyaml/NXcoordinate_system_set.yaml b/contributed_definitions/nyaml/NXcoordinate_system_set.yaml index 7fd822e5f5..a08719edb8 100644 --- a/contributed_definitions/nyaml/NXcoordinate_system_set.yaml +++ b/contributed_definitions/nyaml/NXcoordinate_system_set.yaml @@ -146,29 +146,6 @@ NXcoordinate_system_set(NXobject): Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the base vectors of this coordinate system as Xp, Yp, Zp. - origin(NX_CHAR): # specialized the inherited concept origin from NXcoordinate_system - doc: | - Location of the origin of the processing_reference_frame. - - It is assumed that regions-of-interest in this reference frame form a rectangle or cuboid. - Edges are interpreted by inspecting the direction of their outer unit normals - (which point either parallel or antiparallel) along respective base vector direction - of the reference frame. - - If any of these assumptions is not met, the user is required to explicitly state this. - enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] - x_direction(NX_CHAR): - doc: | - Direction of the positively pointing x-axis base vector of the processing_reference_frame. - enumeration: [undefined, north, east, south, west, in, out] - y_direction(NX_CHAR): - doc: | - Direction of the positively pointing y-axis base vector of the processing_reference_frame. - enumeration: [undefined, north, east, south, west, in, out] - z_direction(NX_CHAR): - doc: | - Direction of the positively pointing z-axis base vector of the processing_reference_frame. - enumeration: [undefined, north, east, south, west, in, out] sample_reference_frame(NXcoordinate_system): doc: | Details about the sample_reference_frame that is typically overlaid onto the surface of the sample. @@ -181,33 +158,6 @@ NXcoordinate_system_set(NXobject): Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the base vectors of this coordinate system as Xs, Ys, Zs. - depends_on: - doc: | - Reference to the specifically named :ref:`NXsample` instance for - which these conventions apply (e.g. /entry1/sample1). - origin(NX_CHAR): - doc: | - Location of the origin of the sample_reference_frame. - - It is assumed that regions-of-interest in this reference frame form a rectangle or cuboid. - Edges are interpreted by inspecting the direction of their outer unit normals - (which point either parallel or antiparallel) along respective base vector direction - of the reference frame. - - If any of these assumptions is not met, the user is required to explicitly state this. - enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] - x_direction(NX_CHAR): - doc: | - Direction of the positively pointing x-axis base vector of the sample_reference_frame. - enumeration: [undefined, north, east, south, west, in, out] - y_direction(NX_CHAR): - doc: | - Direction of the positively pointing y-axis base vector of the sample_reference_frame. - enumeration: [undefined, north, east, south, west, in, out] - z_direction(NX_CHAR): - doc: | - Direction of the positively pointing z-axis base vector of the sample_reference_frame. - enumeration: [undefined, north, east, south, west, in, out] detector_reference_frameID(NXcoordinate_system): doc: | Details about the detector_reference_frame for a specific detector. @@ -219,29 +169,3 @@ NXcoordinate_system_set(NXobject): from a position that is located behind the detector. If any of these assumptions is not met, the user is required to explicitly state this. - depends_on: - doc: | - Reference to the specifically named :ref:`NXdetector` instance for - which these conventions apply (e.g. /entry1/instrument/detector1). - origin(NX_CHAR): - doc: | - Location of the origin of the detector_reference_frame. - - If the regions-of-interest forms a rectangle or cuboid, it is assumed that edges are interpreted - by inspecting the direction of their outer unit normals (which point either parallel or antiparallel) - along respective base vector direction of the reference frame. - - If any of these assumptions is not met, the user is required to explicitly state this. - enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] - x_direction(NX_CHAR): - doc: | - Direction of the positively pointing x-axis base vector of the detector_reference_frame. - enumeration: [undefined, north, east, south, west, in, out] - y_direction(NX_CHAR): - doc: | - Direction of the positively pointing y-axis base vector of the detector_reference_frame. - enumeration: [undefined, north, east, south, west, in, out] - z_direction(NX_CHAR): - doc: | - Direction of the positively pointing z-axis base vector of the detector_reference_frame. - enumeration: [undefined, north, east, south, west, in, out] diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index 0ae23415d6..b322bc53db 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -127,22 +127,12 @@ NXem(NXobject): An example how to use this set could be to document from which files, which have been e.g. generated by software of technology partners, the information in an instance of NXem was filled with during parsing or transcoding between different formats. - - If resources from technology partners would also be documented with semantic - technology there would not even be a necessity to copy over specific information - into other files as one could write inference and information/fact/knowledge retrieval - algorithm(s) whereby a specific piece of information that is related to an experiment - or simulation is read directly from the respective file of the technology partner. - - The reason why currently this works convincingly in hardly any research data management system - (RDMS) is the strong heterogeneity of the information contained in such files and the fact - that often context and documentation, specifically rich and strongly expressive semantic - documentation or contextualization is underdeveloped. type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): userID(NXuser): + # this is one of the few examples where groups may end up without fields because for reasons of not breaking GDPR compliance exists: [min, 0, max, infty] doc: - | @@ -173,10 +163,12 @@ NXem(NXobject): - | Writing the most permanently used email is recommended. telephone_number(NX_CHAR): + exists: optional doc: - | Telephone number at the point in time when the experiment was performed. role(NX_CHAR): + exists: optional doc: - | User role at the point in time when the experiment was performed. @@ -184,7 +176,7 @@ NXem(NXobject): Examples are technician operating the microscope, student, postdoc, principle investigator, or guest. identifier(NXidentifier): - exists: recommended + exists: optional doc: - | Identifier offered by a service to report the user other than by using its name. @@ -197,13 +189,13 @@ NXem(NXobject): doc: - | A physical entity which contains material intended to be investigated. - Sample and specimen are threaded as de facto synonyms. Samples can be real or virtual ones. + Sample and specimen are treated as de facto synonyms. Samples can be real or virtual ones. - | xref: spec: EMglossary term: Specimen url: https://purls.helmholtz-metadaten.de/emg/EMG_00000046 - method(NX_CHAR): + type(NX_CHAR): doc: - | Qualifier whether the sample is a real or a virtual one. @@ -320,13 +312,119 @@ NXem(NXobject): how to define coordinate systems in NeXus. (NXcoordinate_system): exists: [min, 1, max, infty] + alias(NX_CHAR): + exists: optional + type(NX_CHAR): + handedness(NX_CHAR): origin(NX_CHAR): + processing_reference_frame(NXcoordinate_system): + exists: recommended alias(NX_CHAR): + exists: optional type(NX_CHAR): handedness(NX_CHAR): + origin(NX_CHAR): + exists: recommended + doc: | + Location of the origin of the processing_reference_frame. + + It is assumed that regions-of-interest in this reference frame form a rectangle or cuboid. + Edges are interpreted by inspecting the direction of their outer unit normals + (which point either parallel or antiparallel) along respective base vector direction + of the reference frame. + + If any of these assumptions is not met, the user is required to explicitly state this. + enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] x_direction(NX_CHAR): + exists: recommended + doc: | + Direction of the positively pointing x-axis base vector of the processing_reference_frame. + enumeration: [undefined, north, east, south, west, in, out] y_direction(NX_CHAR): + exists: recommended + doc: | + Direction of the positively pointing y-axis base vector of the processing_reference_frame. + enumeration: [undefined, north, east, south, west, in, out] z_direction(NX_CHAR): + exists: recommended + doc: | + Direction of the positively pointing z-axis base vector of the processing_reference_frame. + enumeration: [undefined, north, east, south, west, in, out] + sample_reference_frame(NXcoordinate_system): + exists: recommended + depends_on(NX_CHAR): + exists: optional + doc: | + Reference to the specifically named :ref:`NXsample` instance(s) for + which these conventions apply (e.g. /entry1/sample1). + alias(NX_CHAR): + exists: optional + type(NX_CHAR): + handedness(NX_CHAR): + origin(NX_CHAR): + exists: recommended + doc: | + Location of the origin of the sample_reference_frame. + + It is assumed that regions-of-interest in this reference frame form a rectangle or cuboid. + Edges are interpreted by inspecting the direction of their outer unit normals + (which point either parallel or antiparallel) along respective base vector direction + of the reference frame. + + If any of these assumptions is not met, the user is required to explicitly state this. + enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] + x_direction(NX_CHAR): + exists: recommended + doc: | + Direction of the positively pointing x-axis base vector of the sample_reference_frame. + enumeration: [undefined, north, east, south, west, in, out] + y_direction(NX_CHAR): + exists: recommended + doc: | + Direction of the positively pointing y-axis base vector of the sample_reference_frame. + enumeration: [undefined, north, east, south, west, in, out] + z_direction(NX_CHAR): + exists: recommended + doc: | + Direction of the positively pointing z-axis base vector of the sample_reference_frame. + enumeration: [undefined, north, east, south, west, in, out] + detector_reference_frameID(NXcoordinate_system): + exists: [min, 0, max, infty] + depends_on(NX_CHAR): + exists: optional + doc: | + Reference to the specifically named :ref:`NXdetector` instance for + which these conventions apply (e.g. /entry1/instrument/detector1). + alias(NX_CHAR): + exists: optional + type(NX_CHAR): + handedness(NX_CHAR): + origin(NX_CHAR): + exists: recommended + doc: | + Location of the origin of the detector_reference_frame. + + If the regions-of-interest forms a rectangle or cuboid, it is assumed that edges are interpreted + by inspecting the direction of their outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + + If any of these assumptions is not met, the user is required to explicitly state this. + enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] + x_direction(NX_CHAR): + exists: recommended + doc: | + Direction of the positively pointing x-axis base vector of the detector_reference_frame. + enumeration: [undefined, north, east, south, west, in, out] + y_direction(NX_CHAR): + exists: recommended + doc: | + Direction of the positively pointing y-axis base vector of the detector_reference_frame. + enumeration: [undefined, north, east, south, west, in, out] + z_direction(NX_CHAR): + exists: recommended + doc: | + Direction of the positively pointing z-axis base vector of the detector_reference_frame. + enumeration: [undefined, north, east, south, west, in, out] # the description can be so lean because we do not need to overwrite here s.th. as everything is defined already # we just say we compose using the base class NXcoordinate_system measurement(NXem_msr): @@ -1236,6 +1334,10 @@ NXem(NXobject): # remains to be discussed based on examples gnomonic_reference_frame(NXcoordinate_system): exists: optional + alias(NX_CHAR): + exists: optional + type(NX_CHAR): + handedness(NX_CHAR): origin(NX_CHAR): x_direction(NX_CHAR): y_direction(NX_CHAR): From 788dd0b398f03a5b0f104f1be712d0bfa69c180b Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 10 Sep 2024 16:53:12 +0200 Subject: [PATCH 0921/1012] Fixes apm --- contributed_definitions/NXapm.nxdl.xml | 2 +- contributed_definitions/nyaml/NXapm.yaml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index 862d4eaee2..f2604d7c4f 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -358,7 +358,7 @@ schema for heat treatment - + A qualifier whether the specimen is a real one or a virtual one. diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml index e949087009..1f49a51681 100644 --- a/contributed_definitions/nyaml/NXapm.yaml +++ b/contributed_definitions/nyaml/NXapm.yaml @@ -291,7 +291,7 @@ NXapm(NXobject): Magnitude of the standard deviation of the composition (value). unit: NX_DIMENSIONLESS specimen(NXsample): - method(NX_CHAR): + type(NX_CHAR): doc: | A qualifier whether the specimen is a real one or a virtual one. enumeration: [experiment, simulation] From a5b46d45b59913531cbb86ebf70d54b7fb3b0bdd Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 10 Sep 2024 17:08:52 +0200 Subject: [PATCH 0922/1012] Added undefined enum in NXidentifier --- contributed_definitions/NXidentifier.nxdl.xml | 3 ++- contributed_definitions/nyaml/NXidentifier.yaml | 4 ++-- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/NXidentifier.nxdl.xml b/contributed_definitions/NXidentifier.nxdl.xml index 1639d1dfaf..303bb3a2f4 100644 --- a/contributed_definitions/NXidentifier.nxdl.xml +++ b/contributed_definitions/NXidentifier.nxdl.xml @@ -40,6 +40,7 @@ + @@ -52,7 +53,7 @@ - True if the identifier is persistent (i.e., unique and available indefinetely), + True if the identifier is persistent (i.e., unique and available indefinitely), False otherwise. diff --git a/contributed_definitions/nyaml/NXidentifier.yaml b/contributed_definitions/nyaml/NXidentifier.yaml index 4fc57a0589..87863e4c27 100644 --- a/contributed_definitions/nyaml/NXidentifier.yaml +++ b/contributed_definitions/nyaml/NXidentifier.yaml @@ -9,7 +9,7 @@ NXidentifier(NXobject): If the service is not in the list a simple `url` may be used. The `url` can either be a resolving service for the `identifier` or a fully qualified identification in itself. - enumeration: [doi, urn, hdl, purl, orcid, iso, url] + enumeration: [doi, urn, hdl, purl, orcid, iso, url, undefined] identifier(NX_CHAR): doc: | The unique code, IRI or hash to resolve this reference. @@ -18,4 +18,4 @@ NXidentifier(NXobject): or `https://doi.org/10.1107/S1600576714027575`, which are both resolvable. is_persistent(NX_BOOLEAN): doc: | - True if the identifier is persistent (i.e., unique and available indefinetely), False otherwise. \ No newline at end of file + True if the identifier is persistent (i.e., unique and available indefinitely), False otherwise. From f0f78241a618399a0919abfbd71f7459b98f55c4 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 10 Sep 2024 15:38:11 +0200 Subject: [PATCH 0923/1012] use NXidentifier in NXsample and NXfabrication --- base_classes/NXsample.nxdl.xml | 5 + base_classes/NXuser.nxdl.xml | 2 +- base_classes/nyaml/NXsample.yaml | 10 +- base_classes/nyaml/NXuser.yaml | 144 +++++++++--------- contributed_definitions/NXapm.nxdl.xml | 2 +- .../NXfabrication.nxdl.xml | 6 +- contributed_definitions/NXidentifier.nxdl.xml | 14 +- .../NXoptical_spectroscopy.nxdl.xml | 1 - contributed_definitions/nyaml/NXapm.yaml | 2 +- .../nyaml/NXfabrication.yaml | 12 +- .../nyaml/NXidentifier.yaml | 61 +++++++- .../nyaml/NXoptical_spectroscopy.yaml | 2 - 12 files changed, 164 insertions(+), 97 deletions(-) diff --git a/base_classes/NXsample.nxdl.xml b/base_classes/NXsample.nxdl.xml index b63b9da89f..1ac42099ce 100644 --- a/base_classes/NXsample.nxdl.xml +++ b/base_classes/NXsample.nxdl.xml @@ -519,6 +519,11 @@ exists: ['min', '0'] Details about the sample vendor (company or research group) + + + An (ideally) globally unique identifier for the sample. + + -# -# -# 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. -# -# -# Name of user responsible for this entry -# -# -# -# Role of user responsible for this entry. -# Suggested roles are "local_contact", -# "principal_investigator", and "proposer" -# -# -# -# Affiliation of user -# -# -# Address of user -# -# -# Telephone number of user -# -# -# Fax number of user -# -# -# Email of user -# -# -# -# facility based unique identifier for this person -# e.g. their identification code on the facility -# address/contact database -# -# -# -# -# an author code, Open Researcher and Contributor ID, -# defined by https://orcid.org and expressed as a URI -# -# +# +# +# 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. +# +# +# +# Name of user responsible for this entry +# +# +# +# +# Role of user responsible for this entry. +# Suggested roles are "local_contact", +# "principal_investigator", and "proposer" +# +# +# +# +# Affiliation of user +# +# +# +# +# Address of user +# +# +# +# +# Telephone number of user +# +# +# +# +# Fax number of user +# +# +# +# +# Email of user +# +# +# +# +# facility based unique identifier for this person +# e.g. their identification code on the facility +# address/contact database +# +# +# +# +# Details about an author code, open researcher, or contributor +# (persistent) identifier, e.g. defined by https://orcid.org and expressed +# as a URI. +# +# # # -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. # # # -# diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index f2604d7c4f..37e76991e4 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -518,7 +518,7 @@ schema for heat treatment - + diff --git a/contributed_definitions/NXfabrication.nxdl.xml b/contributed_definitions/NXfabrication.nxdl.xml index c8390a7ffe..cd3b57493b 100644 --- a/contributed_definitions/NXfabrication.nxdl.xml +++ b/contributed_definitions/NXfabrication.nxdl.xml @@ -41,12 +41,12 @@ - + - Ideally, (globally) unique persistent identifier, i.e. + Ideally, (globally) unique persistent identifier. This may contain e.g. a serial number or hash identifier of the component. - + Datetime of components initial construction. This refers to the date of diff --git a/contributed_definitions/NXidentifier.nxdl.xml b/contributed_definitions/NXidentifier.nxdl.xml index 303bb3a2f4..c4d07fb13a 100644 --- a/contributed_definitions/NXidentifier.nxdl.xml +++ b/contributed_definitions/NXidentifier.nxdl.xml @@ -31,17 +31,9 @@ If the service is not in the list a simple `url` may be used. The `url` can either be a resolving service for the `identifier` or a fully qualified identification in itself. + + Examples: doi, urn, hdl, purl, orcid, iso, url - - - - - - - - - - @@ -53,7 +45,7 @@ - True if the identifier is persistent (i.e., unique and available indefinitely), + True if the identifier is persistent (i.e., unique and available indefinetely), False otherwise. diff --git a/contributed_definitions/NXoptical_spectroscopy.nxdl.xml b/contributed_definitions/NXoptical_spectroscopy.nxdl.xml index 69b901f552..75e84d6290 100644 --- a/contributed_definitions/NXoptical_spectroscopy.nxdl.xml +++ b/contributed_definitions/NXoptical_spectroscopy.nxdl.xml @@ -961,7 +961,6 @@ TODO: Locally unique ID of the sample, used in the reasearch institute or group. - State the form of the sample, examples are: diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml index 1f49a51681..4b497fd048 100644 --- a/contributed_definitions/nyaml/NXapm.yaml +++ b/contributed_definitions/nyaml/NXapm.yaml @@ -437,7 +437,7 @@ NXapm(NXobject): fabrication(NXfabrication): vendor(NX_CHAR): model(NX_CHAR): - identifier(NX_CHAR): + identifier(NXidentifier): exists: recommended reflectron(NXreflectron): status(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXfabrication.yaml b/contributed_definitions/nyaml/NXfabrication.yaml index 3a5199898b..078b9e01a2 100644 --- a/contributed_definitions/nyaml/NXfabrication.yaml +++ b/contributed_definitions/nyaml/NXfabrication.yaml @@ -14,9 +14,9 @@ NXfabrication(NXobject): doc: | If different versions exist are possible, the value in this field should be made specific enough to resolve the version. - identifier(NX_CHAR): + identifier(NXidentifier): doc: | - Ideally, (globally) unique persistent identifier, i.e. + Ideally, (globally) unique persistent identifier. This may contain e.g. a serial number or hash identifier of the component. construction_year(NX_DATE_TIME): doc: | @@ -31,7 +31,7 @@ NXfabrication(NXobject): functionalities which the component offers. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 1bd65ca97f104626d51743277a21d0f909b560fd3fbdbc8e4f46f5d1fba3dc5c +# 48901d10e39be736b004bc8399a1a758e0abbd91c857d382fe0111d2704e4e72 # # # +# +# +# An identifier for a (persistent) resource, e.g., a DOI or orcid. +# +# +# +# The service by which the resouce can be resolved. +# If the service is not in the list a simple `url` may be used. +# The `url` can either be a resolving service for the `identifier` +# or a fully qualified identification in itself. +# +# Examples: doi, urn, hdl, purl, orcid, iso, url +# +# +# +# +# The unique code, IRI or hash to resolve this reference. +# Typically, this is stated by the service which is considered a complete +# identifier, e.g., for a DOI it's something of the form `10.1107/S1600576714027575` +# or `https://doi.org/10.1107/S1600576714027575`, which are both resolvable. +# +# +# +# +# True if the identifier is persistent (i.e., unique and available indefinetely), +# False otherwise. +# +# +# diff --git a/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml b/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml index 5f2853167a..26476102b9 100644 --- a/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml +++ b/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml @@ -759,8 +759,6 @@ NXoptical_spectroscopy(NXobject): exists: recommended doc: | Locally unique ID of the sample, used in the reasearch institute or group. - sample_id_global(NXidentifier): - exists: optional physical_form: exists: recommended doc: | From d828f1f2ff4922b72a2077a9b8695ccb45f8854a Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 10 Sep 2024 15:48:31 +0200 Subject: [PATCH 0924/1012] rename sample name in NXoptical spectroscopy --- contributed_definitions/NXoptical_spectroscopy.nxdl.xml | 2 +- contributed_definitions/nyaml/NXoptical_spectroscopy.yaml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/NXoptical_spectroscopy.nxdl.xml b/contributed_definitions/NXoptical_spectroscopy.nxdl.xml index 75e84d6290..85442d9bdd 100644 --- a/contributed_definitions/NXoptical_spectroscopy.nxdl.xml +++ b/contributed_definitions/NXoptical_spectroscopy.nxdl.xml @@ -950,7 +950,7 @@ TODO: Information about the sample stage and sample environment should be described in ENTRY/INSTRUMENT/sample_stage. - + Name of the sample, which is uaually pleases human readability. This may be, but does not have to be identical to the sample_id. diff --git a/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml b/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml index 26476102b9..583c8f1798 100644 --- a/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml +++ b/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml @@ -751,7 +751,7 @@ NXoptical_spectroscopy(NXobject): chemical formula, atom types, its history etc. Information about the sample stage and sample environment should be described in ENTRY/INSTRUMENT/sample_stage. - sample_name: + name: doc: | Name of the sample, which is uaually pleases human readability. This may be, but does not have to be identical to the sample_id. From 7f5cce64135d02ab3a431f94af65edd14eaa8ddd Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 10 Sep 2024 16:22:37 +0200 Subject: [PATCH 0925/1012] make ellipsometer_type optional --- contributed_definitions/NXellipsometry.nxdl.xml | 2 +- contributed_definitions/nyaml/NXellipsometry.yaml | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/contributed_definitions/NXellipsometry.nxdl.xml b/contributed_definitions/NXellipsometry.nxdl.xml index 3ef8bcba85..5769036aff 100644 --- a/contributed_definitions/NXellipsometry.nxdl.xml +++ b/contributed_definitions/NXellipsometry.nxdl.xml @@ -187,7 +187,7 @@ TODO (Workshop output): - + If the ellipsometer_type is `other`, a specific ellipsometry_type" should be added here. diff --git a/contributed_definitions/nyaml/NXellipsometry.yaml b/contributed_definitions/nyaml/NXellipsometry.yaml index 98764d8d9b..7d95cdcdbe 100644 --- a/contributed_definitions/nyaml/NXellipsometry.yaml +++ b/contributed_definitions/nyaml/NXellipsometry.yaml @@ -115,6 +115,7 @@ NXellipsometry(NXoptical_spectroscopy): What type of ellipsometry was used? See Fujiwara Table 4.2. enumeration: [rotating analyzer, rotating analyzer with analyzer compensator, rotating analyzer with polarizer compensator, rotating polarizer, rotating compensator on polarizer side, rotating compensator on analyzer side, modulator on polarizer side, modulator on analyzer side, dual compensator, phase modulation, imaging ellipsometry, null ellipsometry, other] ellipsometer_type_other: + exists: optional doc: | If the ellipsometer_type is `other`, a specific ellipsometry_type" should be added here. rotating_element_type: From 0b0538f24090fcc50c392596973a0f864f619cd0 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 10 Sep 2024 17:27:06 +0200 Subject: [PATCH 0926/1012] NXidentifier in NXoptical_spectroscopy instrument --- contributed_definitions/NXoptical_spectroscopy.nxdl.xml | 2 +- contributed_definitions/nyaml/NXoptical_spectroscopy.yaml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/NXoptical_spectroscopy.nxdl.xml b/contributed_definitions/NXoptical_spectroscopy.nxdl.xml index 85442d9bdd..2c3d7a4abf 100644 --- a/contributed_definitions/NXoptical_spectroscopy.nxdl.xml +++ b/contributed_definitions/NXoptical_spectroscopy.nxdl.xml @@ -838,7 +838,7 @@ TODO: - + diff --git a/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml b/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml index 583c8f1798..c8426b08a7 100644 --- a/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml +++ b/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml @@ -656,7 +656,7 @@ NXoptical_spectroscopy(NXobject): exists: recommended model: exists: recommended - identifier: + identifier(NXidentifier): exists: recommended construction_year(NX_DATE_TIME): exists: optional From c40127fa22714c0cd4cd3c3caf596111b7b68384 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 10 Sep 2024 17:30:29 +0200 Subject: [PATCH 0927/1012] remove NXsample name docs from NXoptical_spectroscopy --- contributed_definitions/NXoptical_spectroscopy.nxdl.xml | 7 +------ contributed_definitions/nyaml/NXoptical_spectroscopy.yaml | 3 --- 2 files changed, 1 insertion(+), 9 deletions(-) diff --git a/contributed_definitions/NXoptical_spectroscopy.nxdl.xml b/contributed_definitions/NXoptical_spectroscopy.nxdl.xml index 2c3d7a4abf..1960213459 100644 --- a/contributed_definitions/NXoptical_spectroscopy.nxdl.xml +++ b/contributed_definitions/NXoptical_spectroscopy.nxdl.xml @@ -950,12 +950,7 @@ TODO: Information about the sample stage and sample environment should be described in ENTRY/INSTRUMENT/sample_stage. - - - Name of the sample, which is uaually pleases human readability. - This may be, but does not have to be identical to the sample_id. - - + Locally unique ID of the sample, used in the reasearch institute or group. diff --git a/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml b/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml index c8426b08a7..923e2f5023 100644 --- a/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml +++ b/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml @@ -752,9 +752,6 @@ NXoptical_spectroscopy(NXobject): Information about the sample stage and sample environment should be described in ENTRY/INSTRUMENT/sample_stage. name: - doc: | - Name of the sample, which is uaually pleases human readability. - This may be, but does not have to be identical to the sample_id. sample_id: exists: recommended doc: | From 0c6f1f930c3155188020634df663e4f4361269c2 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 11 Sep 2024 10:02:10 +0200 Subject: [PATCH 0928/1012] add serial_number to NXfabrication --- contributed_definitions/NXfabrication.nxdl.xml | 9 +++++++-- .../nyaml/NXfabrication.yaml | 18 +++++++++++++----- 2 files changed, 20 insertions(+), 7 deletions(-) diff --git a/contributed_definitions/NXfabrication.nxdl.xml b/contributed_definitions/NXfabrication.nxdl.xml index cd3b57493b..71c3944641 100644 --- a/contributed_definitions/NXfabrication.nxdl.xml +++ b/contributed_definitions/NXfabrication.nxdl.xml @@ -43,10 +43,15 @@ - Ideally, (globally) unique persistent identifier. This may contain e.g. - a serial number or hash identifier of the component. + Ideally, (globally) unique persistent identifier. This may contain e.g. a hash + identifier of the component. + + + Serial number of the component. + + Datetime of components initial construction. This refers to the date of diff --git a/contributed_definitions/nyaml/NXfabrication.yaml b/contributed_definitions/nyaml/NXfabrication.yaml index 078b9e01a2..b9fde874e1 100644 --- a/contributed_definitions/nyaml/NXfabrication.yaml +++ b/contributed_definitions/nyaml/NXfabrication.yaml @@ -16,8 +16,11 @@ NXfabrication(NXobject): specific enough to resolve the version. identifier(NXidentifier): doc: | - Ideally, (globally) unique persistent identifier. This may contain e.g. - a serial number or hash identifier of the component. + Ideally, (globally) unique persistent identifier. This may contain e.g. a hash + identifier of the component. + serial_number(NX_CHAR): + doc: | + Serial number of the component. construction_year(NX_DATE_TIME): doc: | Datetime of components initial construction. This refers to the date of @@ -31,7 +34,7 @@ NXfabrication(NXobject): functionalities which the component offers. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 48901d10e39be736b004bc8399a1a758e0abbd91c857d382fe0111d2704e4e72 +# f65b1d8288480aa2c0e4fdbc531ea3c5df221b12fa1fea70b19850712c715807 # # # - + @@ -613,7 +613,7 @@ we just say we compose using the base class NXcoordinate_system--> - + @@ -627,7 +627,7 @@ we just say we compose using the base class NXcoordinate_system--> - + - + - + @@ -697,7 +697,7 @@ technical design perspective--> - + @@ -707,7 +707,7 @@ technical design perspective--> - + @@ -804,13 +804,13 @@ lenses i.e. devices which can affect the pathes of beams - - + @@ -819,7 +819,7 @@ lenses i.e. devices which can affect the pathes of beams - + diff --git a/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml b/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml index c34bb25db5..bfe92039d2 100644 --- a/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml +++ b/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -54,7 +54,7 @@ - + diff --git a/contributed_definitions/NXlab_sample_mounting.nxdl.xml b/contributed_definitions/NXlab_sample_mounting.nxdl.xml index 98dc044ce2..eeb34a01bc 100644 --- a/contributed_definitions/NXlab_sample_mounting.nxdl.xml +++ b/contributed_definitions/NXlab_sample_mounting.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -53,7 +53,7 @@ - + diff --git a/contributed_definitions/NXtransmission.nxdl.xml b/contributed_definitions/NXtransmission.nxdl.xml index c56878d6da..77b34c18af 100644 --- a/contributed_definitions/NXtransmission.nxdl.xml +++ b/contributed_definitions/NXtransmission.nxdl.xml @@ -1,10 +1,10 @@ - + - - + Variables used throughout the experiment @@ -99,12 +100,12 @@ of instrument.--> used to generate the result file(s) with measured data and metadata. - + Version number of the program that was used to generate the result file(s) with measured data and metadata. - + Website of the software @@ -333,8 +334,10 @@ of instrument.--> - + Properties of the sample measured diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index b322bc53db..1e287c91fc 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -438,7 +438,7 @@ NXem(NXobject): exists: optional vendor(NX_CHAR): model(NX_CHAR): - identifier(NX_CHAR): + identifier(NXidentifier): exists: recommended control_programID(NXprogram): exists: [min, 1, max, infty] @@ -454,7 +454,7 @@ NXem(NXobject): exists: optional vendor(NX_CHAR): model(NX_CHAR): - identifier(NX_CHAR): + identifier(NXidentifier): exists: recommended electron_source(NXsource): doc: @@ -470,7 +470,7 @@ NXem(NXobject): exists: optional vendor(NX_CHAR): model(NX_CHAR): - identifier(NX_CHAR): + identifier(NXidentifier): exists: recommended # fabrication is an example which shows when one needs to specify in the appdef if some of the # inherited objects from NXebeam_column have to be specified that is when one wishes to document @@ -483,7 +483,7 @@ NXem(NXobject): exists: optional vendor(NX_CHAR): model(NX_CHAR): - identifier(NX_CHAR): + identifier(NXidentifier): exists: recommended apertureID(NXaperture): exists: [min, 0, max, infty] @@ -491,7 +491,7 @@ NXem(NXobject): exists: optional vendor(NX_CHAR): model(NX_CHAR): - identifier(NX_CHAR): + identifier(NXidentifier): exists: recommended monochromatorID(NXmonochromator): exists: [min, 0, max, infty] @@ -512,7 +512,7 @@ NXem(NXobject): exists: optional vendor(NX_CHAR): model(NX_CHAR): - identifier(NX_CHAR): + identifier(NXidentifier): exists: recommended corrector_cs(NXcorrector_cs): exists: [min, 0, max, 1] @@ -520,7 +520,7 @@ NXem(NXobject): exists: optional vendor(NX_CHAR): model(NX_CHAR): - identifier(NX_CHAR): + identifier(NXidentifier): exists: recommended corrector_ax(NXcomponent): exists: [min, 0, max, 1] @@ -537,7 +537,7 @@ NXem(NXobject): exists: optional vendor(NX_CHAR): model(NX_CHAR): - identifier(NX_CHAR): + identifier(NXidentifier): exists: recommended biprism(NXcomponent): exists: optional @@ -548,7 +548,7 @@ NXem(NXobject): exists: optional vendor(NX_CHAR): model(NX_CHAR): - identifier(NX_CHAR): + identifier(NXidentifier): exists: recommended phaseplateID(NXcomponent): # contributed definition NXwaveplate is a closely related concept but may fit even better but waveplate @@ -573,7 +573,7 @@ NXem(NXobject): exists: optional vendor(NX_CHAR): model(NX_CHAR): - identifier(NX_CHAR): + identifier(NXidentifier): exists: recommended sensorID(NXsensor): exists: [min, 0, max, infty] @@ -588,7 +588,7 @@ NXem(NXobject): exists: optional vendor(NX_CHAR): model(NX_CHAR): - identifier(NX_CHAR): + identifier(NXidentifier): exists: recommended ion_source(NXsource): probe(NXion): @@ -598,7 +598,7 @@ NXem(NXobject): exists: optional vendor(NX_CHAR): model(NX_CHAR): - identifier(NX_CHAR): + identifier(NXidentifier): exists: recommended apertureID(NXaperture): exists: [min, 0, max, infty] @@ -606,7 +606,7 @@ NXem(NXobject): exists: optional vendor(NX_CHAR): model(NX_CHAR): - identifier(NX_CHAR): + identifier(NXidentifier): exists: recommended monochromatorID(NXmonochromator): exists: [min, 0, max, infty] @@ -624,7 +624,7 @@ NXem(NXobject): exists: optional vendor(NX_CHAR): model(NX_CHAR): - identifier(NX_CHAR): + identifier(NXidentifier): exists: recommended # device for correcting axial astigmatism of ion beam? sensorID(NXsensor): @@ -636,7 +636,7 @@ NXem(NXobject): fabrication(NXfabrication): vendor(NX_CHAR): model(NX_CHAR): - # identifier(NX_CHAR): # only relevant when deprecating serial_number + # identifier(NXidentifier): # only relevant when deprecating serial_number # exists: recommended scan_controller(NXscanbox_em): exists: optional @@ -644,7 +644,7 @@ NXem(NXobject): exists: optional vendor(NX_CHAR): model(NX_CHAR): - identifier(NX_CHAR): + identifier(NXidentifier): exists: recommended (NXsensor): exists: [min, 0, max, infty] @@ -656,7 +656,7 @@ NXem(NXobject): exists: optional vendor(NX_CHAR): model(NX_CHAR): - identifier(NX_CHAR): + identifier(NXidentifier): exists: recommended (NXchamber): exists: [min, 0, max, infty] diff --git a/contributed_definitions/nyaml/NXlab_electro_chemo_mechanical_preparation.yaml b/contributed_definitions/nyaml/NXlab_electro_chemo_mechanical_preparation.yaml index bbc1a500c3..4afd18c0e1 100644 --- a/contributed_definitions/nyaml/NXlab_electro_chemo_mechanical_preparation.yaml +++ b/contributed_definitions/nyaml/NXlab_electro_chemo_mechanical_preparation.yaml @@ -28,7 +28,7 @@ NXlab_electro_chemo_mechanical_preparation(NXobject): grinding_machine(NXfabrication): vendor: model: - identifier: + identifier(NXidentifier): exists: recommended GRINDING_STEP(NXprocess): doc: | diff --git a/contributed_definitions/nyaml/NXlab_sample_mounting.yaml b/contributed_definitions/nyaml/NXlab_sample_mounting.yaml index 3963b841f5..5d5a15aea0 100644 --- a/contributed_definitions/nyaml/NXlab_sample_mounting.yaml +++ b/contributed_definitions/nyaml/NXlab_sample_mounting.yaml @@ -27,7 +27,7 @@ NXlab_sample_mounting(NXobject): mounting_machine(NXfabrication): vendor: model: - identifier: + identifier(NXidentifier): exists: recommended mounting_method: doc: | diff --git a/contributed_definitions/nyaml/NXtransmission.yaml b/contributed_definitions/nyaml/NXtransmission.yaml index b4ec2b439b..bea7486f95 100644 --- a/contributed_definitions/nyaml/NXtransmission.yaml +++ b/contributed_definitions/nyaml/NXtransmission.yaml @@ -56,7 +56,7 @@ NXtransmission(NXobject): doc: | Commercial or otherwise defined given name to the program that was used to generate the result file(s) with measured data and metadata. - identifier(NX_CHAR): + identifier(NXidentifier): doc: | Version number of the program that was used to generate the result file(s) with measured data and metadata. From cdc1719c85a244eed49864a883b72f7745f07e18 Mon Sep 17 00:00:00 2001 From: rettigl Date: Tue, 10 Sep 2024 10:31:36 +0200 Subject: [PATCH 0931/1012] decode binary strings in nxdl_utils.py --- dev_tools/utils/nxdl_utils.py | 32 ++++++++++++++++++++++---------- 1 file changed, 22 insertions(+), 10 deletions(-) diff --git a/dev_tools/utils/nxdl_utils.py b/dev_tools/utils/nxdl_utils.py index ee4ac8473e..00add0b0e7 100644 --- a/dev_tools/utils/nxdl_utils.py +++ b/dev_tools/utils/nxdl_utils.py @@ -765,16 +765,28 @@ def get_best_child(nxdl_elem, hdf_node, hdf_name, hdf_class_name, nexus_type): corresponding to the html documentation name html_name""" bestfit = -1 bestchild = None - if ( - "name" in nxdl_elem.attrib.keys() - and nxdl_elem.attrib["name"] == "NXdata" - and hdf_node is not None - and hdf_node.parent is not None - and hdf_node.parent.attrs.get("NX_class") == "NXdata" - ): - (fnd_child, fit) = get_best_nxdata_child(nxdl_elem, hdf_node, hdf_name) - if fnd_child is not None: - return (fnd_child, fit) + try: + if ( + "name" in nxdl_elem.attrib.keys() + and nxdl_elem.attrib["name"] == "NXdata" + and hdf_node is not None + and hdf_node.parent is not None + and hdf_node.parent.attrs.get("NX_class").decode("UTF-8") == "NXdata" + ): + (fnd_child, fit) = get_best_nxdata_child(nxdl_elem, hdf_node, hdf_name) + if fnd_child is not None: + return (fnd_child, fit) + except AttributeError: + if ( + "name" in nxdl_elem.attrib.keys() + and nxdl_elem.attrib["name"] == "NXdata" + and hdf_node is not None + and hdf_node.parent is not None + and hdf_node.parent.attrs.get("NX_class") == "NXdata" + ): + (fnd_child, fit) = get_best_nxdata_child(nxdl_elem, hdf_node, hdf_name) + if fnd_child is not None: + return (fnd_child, fit) for child in nxdl_elem: if not isinstance(child.tag, str): continue From bbf806016a5d62dd5630c4bec53e6bef04942d93 Mon Sep 17 00:00:00 2001 From: rettigl Date: Tue, 10 Sep 2024 22:59:37 +0200 Subject: [PATCH 0932/1012] add function for decoding --- dev_tools/utils/nxdl_utils.py | 39 +++++++++++++++-------------------- 1 file changed, 17 insertions(+), 22 deletions(-) diff --git a/dev_tools/utils/nxdl_utils.py b/dev_tools/utils/nxdl_utils.py index 00add0b0e7..42a96e9f40 100644 --- a/dev_tools/utils/nxdl_utils.py +++ b/dev_tools/utils/nxdl_utils.py @@ -14,6 +14,13 @@ from lxml.etree import ParseError as xmlER +def decode_or_not(elem): + """Decodes a byte array to string if necessary""" + if isinstance(elem, bytes): + elem = elem.decode("UTF-8") + return elem + + def remove_namespace_from_tag(tag): """Helper function to remove the namespace from an XML tag.""" @@ -765,28 +772,16 @@ def get_best_child(nxdl_elem, hdf_node, hdf_name, hdf_class_name, nexus_type): corresponding to the html documentation name html_name""" bestfit = -1 bestchild = None - try: - if ( - "name" in nxdl_elem.attrib.keys() - and nxdl_elem.attrib["name"] == "NXdata" - and hdf_node is not None - and hdf_node.parent is not None - and hdf_node.parent.attrs.get("NX_class").decode("UTF-8") == "NXdata" - ): - (fnd_child, fit) = get_best_nxdata_child(nxdl_elem, hdf_node, hdf_name) - if fnd_child is not None: - return (fnd_child, fit) - except AttributeError: - if ( - "name" in nxdl_elem.attrib.keys() - and nxdl_elem.attrib["name"] == "NXdata" - and hdf_node is not None - and hdf_node.parent is not None - and hdf_node.parent.attrs.get("NX_class") == "NXdata" - ): - (fnd_child, fit) = get_best_nxdata_child(nxdl_elem, hdf_node, hdf_name) - if fnd_child is not None: - return (fnd_child, fit) + if ( + "name" in nxdl_elem.attrib.keys() + and nxdl_elem.attrib["name"] == "NXdata" + and hdf_node is not None + and hdf_node.parent is not None + and decode_or_not(hdf_node.parent.attrs.get("NX_class")) == "NXdata" + ): + (fnd_child, fit) = get_best_nxdata_child(nxdl_elem, hdf_node, hdf_name) + if fnd_child is not None: + return (fnd_child, fit) for child in nxdl_elem: if not isinstance(child.tag, str): continue From 7b0393567698b152483ab7da630997623e546d64 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 11 Sep 2024 14:36:36 +0200 Subject: [PATCH 0933/1012] use NXidentifier in NXentry --- base_classes/NXentry.nxdl.xml | 34 +- base_classes/NXsubentry.nxdl.xml | 381 ++++++++++-------- base_classes/nyaml/NXentry.yaml | 8 +- base_classes/nyaml/NXsubentry.yaml | 6 +- .../NXsensor_scan.nxdl.xml | 2 +- contributed_definitions/NXsts.nxdl.xml | 46 ++- .../NXtransmission.nxdl.xml | 4 +- .../nyaml/NXsensor_scan.yaml | 2 +- contributed_definitions/nyaml/NXsts.yaml | 6 +- .../nyaml/NXtransmission.yaml | 2 +- 10 files changed, 274 insertions(+), 217 deletions(-) diff --git a/base_classes/NXentry.nxdl.xml b/base_classes/NXentry.nxdl.xml index e5865bd60c..0935e6b740 100644 --- a/base_classes/NXentry.nxdl.xml +++ b/base_classes/NXentry.nxdl.xml @@ -1,10 +1,10 @@ - + + ISIS Muon IDF_Version @@ -91,13 +93,13 @@ Extended title for entry - + Unique identifier for the experiment, defined by the facility, possibly linked to the proposals - + Brief summary of the experiment, including key objectives. @@ -108,22 +110,22 @@ Description of the full experiment (document in pdf, latex, ...) - + User or Data Acquisition defined group of NeXus files or NXentry - + Brief summary of the collection, including grouping criteria. - + unique identifier for the measurement, defined by the facility. - - + + UUID identifier for the measurement. @@ -132,7 +134,7 @@ Version of UUID used - + Reserved for future use by NIAC. @@ -209,7 +211,7 @@ - Such as "2007-3". Some user facilities organize their beam time into run cycles. + Such as "2007-3". Some user facilities organize their beam time into run cycles. diff --git a/base_classes/NXsubentry.nxdl.xml b/base_classes/NXsubentry.nxdl.xml index 5f45a76da3..c5e72259d1 100644 --- a/base_classes/NXsubentry.nxdl.xml +++ b/base_classes/NXsubentry.nxdl.xml @@ -1,10 +1,10 @@ - - + + - - - - - .. 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 <validItemName>` the default :ref:`NXentry` group. The - value must be the name of a child of the current group. The child must be a - NeXus group or a link to a NeXus group. - - For more information about how NeXus identifies the default - plottable data, see the - :ref:`Find Plottable Data, v3 <Find-Plottable-Data-v3>` - section. - - - - - Group of multiple application definitions for "multi-modal" (e.g. SAXS/WAXS) measurements. - - ``NXsubentry`` is a base class virtually identical to :ref:`NXentry` - and is used as the (overlay) location for application definitions. - Use a separate ``NXsubentry`` for each application definition. - - To use ``NXsubentry`` with a hypothetical application definition - called ``NXmyappdef``: - - * Create a group with attribute ``NX_class="NXsubentry"`` - * Within that group, create a field called ``definition="NXmyappdef"``. - * There are two optional attributes of definition: ``version`` and ``URL`` - - The intended use is to define application definitions for a - multi-modal (a.k.a. multi-technique) :ref:`NXentry`. - Previously, an application definition - replaced :ref:`NXentry` with its own definition. - With the increasing popularity of instruments combining - multiple techniques for data collection (such as SAXS/WAXS instruments), - it was recognized the application definitions must be entered in the NeXus - data file tree as children of :ref:`NXentry`. - - - - - ISIS Muon IDF_Version - - - - Extended title for entry - - - - Unique identifier for the experiment, defined by - the facility, possibly linked to the proposals - - - - Brief summary of the experiment, including key objectives. - - - Description of the full experiment (document in pdf, latex, ...) - - - User or Data Acquisition defined group of NeXus files or :ref:`NXentry` - - - Brief summary of the collection, including grouping criteria. - - - unique identifier for the measurement, defined by the facility. - - - Official NeXus NXDL schema to which this subentry conforms - NXDL version number - URL of NXDL file - - - - Local NXDL schema extended from the subentry - specified in the ``definition`` field. - This contains any locally-defined, - additional fields in the subentry. - - NXDL version number - URL of NXDL file - - - Starting time of measurement - - - Ending time of measurement - - - Duration of measurement - - - - Time transpired actually collecting data i.e. taking out time when collection was - suspended due to e.g. temperature out of range - - - - Such as "2007-3". Some user facilities organize their beam time into run cycles. - - - Name of program used to generate this file - Program version number - configuration of the program - - - - Revision id of the file due to re-calibration, reprocessing, new analysis, new - instrument definition format, ... - - - - - - This is the flightpath before the sample position. This can be determined by a chopper, - by the moderator or the source itself. In other words: it the distance to the component - which gives the T0 signal to the detector electronics. If another component in the - NXinstrument hierarchy provides this information, this should be a link. - - - - Notes describing entry - - - - A small image that is representative of the entry. An example of this is a 640x480 - jpeg image automatically produced by a low resolution plot of the NXdata. - - - The value should be an ``image/*`` - - - - - - - - - - - - - - + + + Group of multiple application definitions for "multi-modal" (e.g. SAXS/WAXS) measurements. + + ``NXsubentry`` is a base class virtually identical to :ref:`NXentry` + and is used as the (overlay) location for application definitions. + Use a separate ``NXsubentry`` for each application definition. + + To use ``NXsubentry`` with a hypothetical application definition + called ``NXmyappdef``: + + * Create a group with attribute ``NX_class="NXsubentry"`` + * Within that group, create a field called ``definition="NXmyappdef"``. + * There are two optional attributes of definition: ``version`` and ``URL`` + + The intended use is to define application definitions for a + multi-modal (a.k.a. multi-technique) :ref:`NXentry`. + Previously, an application definition + replaced :ref:`NXentry` with its own definition. + With the increasing popularity of instruments combining + multiple techniques for data collection (such as SAXS/WAXS instruments), + it was recognized the application definitions must be entered in the NeXus + data file tree as children of :ref:`NXentry`. + + + + .. 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 <validItemName>` the default :ref:`NXentry` group. The + value must be the name of a child of the current group. The child must be a + NeXus group or a link to a NeXus group. + + For more information about how NeXus identifies the default + plottable data, see the + :ref:`Find Plottable Data, v3 <Find-Plottable-Data-v3>` + section. + + + + + + ISIS Muon IDF_Version + + + + + Extended title for entry + + + + + Unique identifier for the experiment, defined by + the facility, possibly linked to the proposals + + + + + Brief summary of the experiment, including key objectives. + + + + + Description of the full experiment (document in pdf, latex, ...) + + + + + User or Data Acquisition defined group of NeXus files or :ref:`NXentry` + + + + + Brief summary of the collection, including grouping criteria. + + + + + unique identifier for the measurement, defined by the facility. + + + + + Official NeXus NXDL schema to which this subentry conforms + + + + NXDL version number + + + + + URL of NXDL file + + + + + + Local NXDL schema extended from the subentry + specified in the ``definition`` field. + This contains any locally-defined, + additional fields in the subentry. + + + + NXDL version number + + + + + URL of NXDL file + + + + + + Starting time of measurement + + + + + Ending time of measurement + + + + + Duration of measurement + + + + + Time transpired actually collecting data i.e. taking out time when collection was + suspended due to e.g. temperature out of range + + + + + Such as "2007-3". Some user facilities organize their beam time into run cycles. + + + + + Name of program used to generate this file + + + + Program version number + + + + + configuration of the program + + + + + + Revision id of the file due to re-calibration, reprocessing, new analysis, new + instrument definition format, ... + + + + + + This is the flightpath before the sample position. This can be determined by a chopper, + by the moderator or the source itself. In other words: it the distance to the component + which gives the T0 signal to the detector electronics. If another component in the + NXinstrument hierarchy provides this information, this should be a link. + + + + + Notes describing entry + + + + + A small image that is representative of the entry. An example of this is a 640x480 + jpeg image automatically produced by a low resolution plot of the NXdata. + + + + The value should be an ``image/*`` + + + + + + + + + + + + + + + - diff --git a/base_classes/nyaml/NXentry.yaml b/base_classes/nyaml/NXentry.yaml index a1275a308b..85a8e3d022 100644 --- a/base_classes/nyaml/NXentry.yaml +++ b/base_classes/nyaml/NXentry.yaml @@ -62,7 +62,7 @@ NXentry(NXobject): title: doc: | Extended title for entry - experiment_identifier: + experiment_identifier(NXidentifier): doc: | Unique identifier for the experiment, defined by the facility, @@ -73,16 +73,16 @@ NXentry(NXobject): (NXnote)experiment_documentation: doc: | Description of the full experiment (document in pdf, latex, ...) - collection_identifier: + collection_identifier(NXidentifier): doc: | User or Data Acquisition defined group of NeXus files or NXentry collection_description: doc: | Brief summary of the collection, including grouping criteria. - entry_identifier: + entry_identifier(NXidentifier): doc: | unique identifier for the measurement, defined by the facility. - entry_identifier_uuid: + entry_identifier_uuid(NXidentifier): doc: | UUID identifier for the measurement. \@version: diff --git a/base_classes/nyaml/NXsubentry.yaml b/base_classes/nyaml/NXsubentry.yaml index 248111e211..19c87ca29b 100644 --- a/base_classes/nyaml/NXsubentry.yaml +++ b/base_classes/nyaml/NXsubentry.yaml @@ -49,7 +49,7 @@ NXsubentry(NXobject): title: doc: | Extended title for entry - experiment_identifier: + experiment_identifier(NXidentifier): doc: | Unique identifier for the experiment, defined by the facility, possibly linked to the proposals @@ -59,13 +59,13 @@ NXsubentry(NXobject): (NXnote)experiment_documentation: doc: | Description of the full experiment (document in pdf, latex, ...) - collection_identifier: + collection_identifier(NXidentifier): doc: | User or Data Acquisition defined group of NeXus files or :ref:`NXentry` collection_description: doc: | Brief summary of the collection, including grouping criteria. - entry_identifier: + entry_identifier(NXidentifier): doc: | unique identifier for the measurement, defined by the facility. definition: diff --git a/contributed_definitions/NXsensor_scan.nxdl.xml b/contributed_definitions/NXsensor_scan.nxdl.xml index 00ef3e3300..bea9efa218 100644 --- a/contributed_definitions/NXsensor_scan.nxdl.xml +++ b/contributed_definitions/NXsensor_scan.nxdl.xml @@ -45,7 +45,7 @@ - + diff --git a/contributed_definitions/NXsts.nxdl.xml b/contributed_definitions/NXsts.nxdl.xml index 7458dc1133..f13d5a90cb 100644 --- a/contributed_definitions/NXsts.nxdl.xml +++ b/contributed_definitions/NXsts.nxdl.xml @@ -27,6 +27,8 @@ 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the--> + Application definition for temperature-dependent IV curve measurements @@ -76,24 +78,24 @@ What is about [constant current mode, constant height mode]--> - + The name of the output file, with the number of scans at the end. (e.g. 221122_Au_5K00014) - - + + The name of the series output file, which represents only the public part of the output file. (e.g. 221122_Au_5K) - - + + Path to storage of output files. (e.g. Path C:\Users\SPM-PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis-Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711) - + Descriptive comments for this experiment, added by the experimenter, coming from the @@ -126,7 +128,9 @@ crosstalk_compensation: Current amplifier> Capacitive cross-talk compensation: Y - + Status of Lock-in device whether while performing the experiment @@ -143,7 +147,9 @@ hardware: Lock-in Amplifier>Hardware: Nanonis--> - + The signal is modulated by adding the frequency of the sine modulation. The modulation frequency spans can be from 10 mHz to 40 kHz, corresponding to the output filter @@ -154,15 +160,19 @@ hardware: Lock-in Amplifier>Hardware: Nanonis--> - + The amplitude (in physical units of modulated signal) of the sine modulation. - +set in the Frequency field (“4”) or harmonics. +--> The input signal (STS signal) will be demodulated, in order to determine the amplitude and phase at the frequency set in the Frequency field or harmonics, such as current, @@ -170,8 +180,10 @@ set in the Frequency field (“4”) or harmonics.--> - + N denotes 1 or 2. The order of the harmonic oscillation to be detected in the demodulated signal should be considered relative to the modulation frequency. When dealing with @@ -180,8 +192,10 @@ Lock-in>Harmonic D2 2 # See below.--> - + Reference phase for the sine on the demodulated signal with respect to the modulation signal. The determined phase is displayed with respect to the @@ -477,7 +491,7 @@ parameters for a measurement at a single location during the scan--> - In STM experiment, the scan range is the coordinate (x,y) along the X and Y axis from the origin (scan_offset) of + In STM experiment, the scan range is the coordinate (x,y) along the X and Y axis from the origin (scan_offset) of the scan area (e.g. 5.000000E-9 5.000000E-9). diff --git a/contributed_definitions/NXtransmission.nxdl.xml b/contributed_definitions/NXtransmission.nxdl.xml index 77b34c18af..15ed29e3b3 100644 --- a/contributed_definitions/NXtransmission.nxdl.xml +++ b/contributed_definitions/NXtransmission.nxdl.xml @@ -72,7 +72,7 @@ Draft NeXus application definition for transmission experiments--> Start time of the experiment. - + Unique identifier of the experiment, such as a (globally persistent) unique identifier. @@ -81,7 +81,7 @@ Draft NeXus application definition for transmission experiments--> investigator. * The identifier enables to link experiments to e.g. proposals. - + An optional free-text description of the experiment. However, details of the diff --git a/contributed_definitions/nyaml/NXsensor_scan.yaml b/contributed_definitions/nyaml/NXsensor_scan.yaml index 0eea319826..94fd0c0e6e 100644 --- a/contributed_definitions/nyaml/NXsensor_scan.yaml +++ b/contributed_definitions/nyaml/NXsensor_scan.yaml @@ -15,7 +15,7 @@ NXsensor_scan(NXobject): definition(NX_CHAR): \@version: enumeration: [NXsensor_scan] - experiment_identifier(NX_CHAR): + experiment_identifier(NXidentifier): exists: recommended experiment_description(NX_CHAR): start_time(NX_DATE_TIME): diff --git a/contributed_definitions/nyaml/NXsts.yaml b/contributed_definitions/nyaml/NXsts.yaml index 0f1b3fa80d..cad72e7348 100644 --- a/contributed_definitions/nyaml/NXsts.yaml +++ b/contributed_definitions/nyaml/NXsts.yaml @@ -41,16 +41,16 @@ NXsts(NXsensor_scan): # NOTE_: What does the enum refer, scan could be forward or backward. (not in data file) # What is about [constant current mode, constant height mode] enumeration: [background, reference, sample] - entry_identifier: + entry_identifier(NXidentifier): exists: optional doc: | The name of the output file, with the number of scans at the end. (e.g. 221122_Au_5K00014) - collection_identifier: + collection_identifier(NXidentifier): doc: | The name of the series output file, which represents only the public part of the output file. (e.g. 221122_Au_5K) - experiment_identifier: + experiment_identifier(NXidentifier): exists: optional doc: | Path to storage of output files. diff --git a/contributed_definitions/nyaml/NXtransmission.yaml b/contributed_definitions/nyaml/NXtransmission.yaml index bea7486f95..ddc3074d69 100644 --- a/contributed_definitions/nyaml/NXtransmission.yaml +++ b/contributed_definitions/nyaml/NXtransmission.yaml @@ -31,7 +31,7 @@ NXtransmission(NXobject): start_time(NX_DATE_TIME): doc: | Start time of the experiment. - experiment_identifier(NX_CHAR): + experiment_identifier(NXidentifier): doc: | Unique identifier of the experiment, such as a (globally persistent) unique identifier. From b6b3ba3c97b45d9e76e0deafbd049ff5a73771d5 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 11 Sep 2024 15:25:02 +0200 Subject: [PATCH 0934/1012] small changes to NXbeam and NXmonochromator --- base_classes/NXbeam.nxdl.xml | 4 +++- base_classes/NXmonochromator.nxdl.xml | 10 ++++++++++ base_classes/nyaml/NXbeam.yaml | 4 +++- base_classes/nyaml/NXmonochromator.yaml | 6 ++++++ 4 files changed, 22 insertions(+), 2 deletions(-) diff --git a/base_classes/NXbeam.nxdl.xml b/base_classes/NXbeam.nxdl.xml index fc0b4d377b..dad046d605 100644 --- a/base_classes/NXbeam.nxdl.xml +++ b/base_classes/NXbeam.nxdl.xml @@ -202,7 +202,9 @@ Size of the beam entering this component. Note this represents - a rectangular beam aperture, and values represent FWHM + a rectangular beam aperture, and values represent FWHM. + If applicable, the first dimension shall be the horizontal extent + and the second dimension shall be the vertical extent. diff --git a/base_classes/NXmonochromator.nxdl.xml b/base_classes/NXmonochromator.nxdl.xml index e52cc3c3cd..339d47dc17 100644 --- a/base_classes/NXmonochromator.nxdl.xml +++ b/base_classes/NXmonochromator.nxdl.xml @@ -75,6 +75,16 @@ Wavelength dispersion at the exit slit. + + + Size, position and shape of the entrance slit of the monochromator. + + + + + Size, position and shape of the exit slit of the monochromator. + + diff --git a/base_classes/nyaml/NXbeam.yaml b/base_classes/nyaml/NXbeam.yaml index 8dddb78d70..3418ce5f56 100644 --- a/base_classes/nyaml/NXbeam.yaml +++ b/base_classes/nyaml/NXbeam.yaml @@ -158,7 +158,9 @@ NXbeam(NXobject): unit: NX_LENGTH doc: | Size of the beam entering this component. Note this represents - a rectangular beam aperture, and values represent FWHM + a rectangular beam aperture, and values represent FWHM. + If applicable, the first dimension shall be the horizontal extent + and the second dimension shall be the vertical extent. dimensions: rank: 2 dim: [[1, nP], [2, 2]] diff --git a/base_classes/nyaml/NXmonochromator.yaml b/base_classes/nyaml/NXmonochromator.yaml index 6c90145d9d..3a2eadd262 100644 --- a/base_classes/nyaml/NXmonochromator.yaml +++ b/base_classes/nyaml/NXmonochromator.yaml @@ -49,6 +49,12 @@ NXmonochromator(NXobject): unit: NX_ANY doc: | Wavelength dispersion at the exit slit. + entrance_slit(NXaperture): + doc: | + Size, position and shape of the entrance slit of the monochromator. + exit_slit(NXaperture): + doc: | + Size, position and shape of the exit slit of the monochromator. (NXdata)distribution: (NXgeometry)geometry: deprecated: | From e147c2414b2eb83d94fc59759d1033eb8e158897 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 11 Sep 2024 17:12:30 +0200 Subject: [PATCH 0935/1012] typo fixes --- contributed_definitions/NXidentifier.nxdl.xml | 7 ++----- contributed_definitions/nyaml/NXidentifier.yaml | 7 ++----- 2 files changed, 4 insertions(+), 10 deletions(-) diff --git a/contributed_definitions/NXidentifier.nxdl.xml b/contributed_definitions/NXidentifier.nxdl.xml index c4d07fb13a..ce05800f9e 100644 --- a/contributed_definitions/NXidentifier.nxdl.xml +++ b/contributed_definitions/NXidentifier.nxdl.xml @@ -27,10 +27,7 @@ - The service by which the resouce can be resolved. - If the service is not in the list a simple `url` may be used. - The `url` can either be a resolving service for the `identifier` - or a fully qualified identification in itself. + The service by which the resource can be resolved. Examples: doi, urn, hdl, purl, orcid, iso, url @@ -45,7 +42,7 @@ - True if the identifier is persistent (i.e., unique and available indefinetely), + True if the identifier is persistent (i.e., unique and available indefinitely), False otherwise. diff --git a/contributed_definitions/nyaml/NXidentifier.yaml b/contributed_definitions/nyaml/NXidentifier.yaml index c3809edb88..d16e9a269d 100644 --- a/contributed_definitions/nyaml/NXidentifier.yaml +++ b/contributed_definitions/nyaml/NXidentifier.yaml @@ -5,10 +5,7 @@ type: group NXidentifier(NXobject): service(NX_CHAR): doc: | - The service by which the resouce can be resolved. - If the service is not in the list a simple `url` may be used. - The `url` can either be a resolving service for the `identifier` - or a fully qualified identification in itself. + The service by which the resource can be resolved. Examples: doi, urn, hdl, purl, orcid, iso, url identifier(NX_CHAR): @@ -19,7 +16,7 @@ NXidentifier(NXobject): or `https://doi.org/10.1107/S1600576714027575`, which are both resolvable. is_persistent(NX_BOOLEAN): doc: | - True if the identifier is persistent (i.e., unique and available indefinetely), + True if the identifier is persistent (i.e., unique and available indefinitely), False otherwise. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ From 0185e43933a62dbc4fe2384d8c88f5987b70fb38 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 11 Sep 2024 16:09:09 +0200 Subject: [PATCH 0936/1012] proper string decoding --- dev_tools/tests/test_nxdl_utils.py | 49 +++++++++++++++++++ dev_tools/utils/nxdl_utils.py | 78 +++++++++++++++++++++++++++--- requirements.txt | 3 ++ 3 files changed, 123 insertions(+), 7 deletions(-) diff --git a/dev_tools/tests/test_nxdl_utils.py b/dev_tools/tests/test_nxdl_utils.py index 3c1c722e08..99408b0360 100644 --- a/dev_tools/tests/test_nxdl_utils.py +++ b/dev_tools/tests/test_nxdl_utils.py @@ -22,6 +22,7 @@ import lxml.etree as ET import pytest +import numpy as np from ..utils import nxdl_utils as nexus @@ -194,3 +195,51 @@ def test_namefitting_precedence(better_fit, better_ref, worse_fit, worse_ref): assert nexus.get_nx_namefit(better_fit, better_ref) > nexus.get_nx_namefit( worse_fit, worse_ref ) + +@pytest.mark.parametrize( + "string_obj, decode, expected", + [ + # Test with np.ndarray + (np.array([b'fixed1', b'fixed2'], dtype='S10'), True, ['fixed1', 'fixed2']), + (np.array([b'fixed1 ', b'fixed2 '], dtype='S10'), False, np.array([b'fixed1 ', b'fixed2 '], dtype='S10')), + + (np.array([b'var1', b'var2', b'var3']), True, ['var1', 'var2', 'var3']), + (np.array([b'var1', b'var2', b'var3']), False, np.array([b'var1', b'var2', b'var3'])), + + (np.array([], dtype=object), True, None), + (np.array([], dtype=object), False, np.array([])), + + # # Test with bytes + (b'single', True, 'single'), + (b'single', False, b'single'), + + # Test with str + ('single', True, 'single'), + ('single', False, 'single'), + + # Test with mixed np.ndarray + (np.array([b'bytes', 'string'], dtype=object), True, ['bytes', 'string']), + # (np.array([b'bytes', 'string'], dtype=object), False, np.array([b'bytes', 'string'], dtype=object)), + ] +) +def test_decode_string(string_obj, decode, expected): + # Handle normal cases + result = nexus.decode_string(string_obj, decode) + if isinstance(expected, list): + assert list(result) == expected, f"Failed for {string_obj} with decode={decode}" + elif isinstance(expected, np.ndarray): + assert (result == expected).all(), f"Failed for {string_obj} with decode={decode}" + else: + assert result == expected, f"Failed for {string_obj} with decode={decode}" + + +@pytest.mark.parametrize( + "string_obj, decode", + [ + (123, True), + (123, False), + ] +) +def test_decode_string_exceptions(string_obj, decode): + with pytest.raises(ValueError): + nexus.decode_string(string_obj, decode) diff --git a/dev_tools/utils/nxdl_utils.py b/dev_tools/utils/nxdl_utils.py index 42a96e9f40..f389aac932 100644 --- a/dev_tools/utils/nxdl_utils.py +++ b/dev_tools/utils/nxdl_utils.py @@ -7,18 +7,82 @@ from functools import lru_cache from glob import glob from pathlib import Path -from typing import List -from typing import Optional +from typing import List, Optional, Union + +import numpy as np import lxml.etree as ET from lxml.etree import ParseError as xmlER +import numpy as np +from typing import Union, List, Optional -def decode_or_not(elem): - """Decodes a byte array to string if necessary""" - if isinstance(elem, bytes): - elem = elem.decode("UTF-8") - return elem +def decode_string( + string_obj: Union[np.ndarray, bytes, str], + decode: bool = True +) -> Optional[Union[str, List[str], np.ndarray, bytes]]: + """ + Decodes a numpy ndarray of byte objects to a Python string or list of strings. + Also handles single bytes and string objects. If `decode` is False, returns the + initial value without decoding. + + Args: + string_obj: A numpy ndarray, bytes, or str that may need decoding. + decode: A boolean flag indicating whether to perform decoding. + + Returns: + A decoded string, a list of decoded strings, or the initial value if `decode` is False. + Returns None if the input is empty or invalid. + + Raises: + ValueError: If `string_obj` is not one of the supported types or decoding fails. + """ + if not decode: + # Return the initial value without decoding + if not isinstance(string_obj, (np.ndarray, bytes, str)): + raise ValueError(f"Unsupported type {type(string_obj)}. Expected np.ndarray, bytes, or str.") + if isinstance(string_obj, np.ndarray): + return string_obj.tolist() if string_obj.size > 0 else None + return string_obj + + if isinstance(string_obj, np.ndarray): + if string_obj.size == 0: + return None + + # Handle fixed-length strings by stripping padding + if string_obj.dtype.kind == 'S': + valid_entries = [entry.decode("utf-8").rstrip('\x00') if isinstance(entry, bytes) else entry + for entry in string_obj if isinstance(entry, (str, bytes))] + else: + valid_entries = [entry for entry in string_obj if isinstance(entry, (str, bytes))] + + # Decode bytes to strings where necessary + decoded_list = [] + for entry in valid_entries: + if isinstance(entry, bytes): + try: + decoded_list.append(entry.decode("utf-8")) + except UnicodeDecodeError as e: + raise ValueError(f"Error decoding bytes: {e}") + else: + decoded_list.append(entry) + + # Return a scalar string if there's only one element, otherwise return the list + if len(decoded_list) == 1: + return decoded_list[0] + return decoded_list if decoded_list else None + + elif isinstance(string_obj, bytes): + try: + return string_obj.decode("utf-8") + except UnicodeDecodeError as e: + raise ValueError(f"Error decoding bytes: {e}") + + elif isinstance(string_obj, str): + return string_obj + + else: + raise ValueError(f"Unsupported type {type(string_obj)}. Expected np.ndarray, bytes, or str.") def remove_namespace_from_tag(tag): diff --git a/requirements.txt b/requirements.txt index 74294d9b26..1fd4c32dea 100644 --- a/requirements.txt +++ b/requirements.txt @@ -16,3 +16,6 @@ pytest black>=24.1.1 flake8>=4 isort>=5.10 + +# String decoding +numpy \ No newline at end of file From fb6c7593297ad576af4cebbb7c409fdaf7fc2f10 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 11 Sep 2024 16:10:52 +0200 Subject: [PATCH 0937/1012] remove unneeded imports --- dev_tools/utils/nxdl_utils.py | 3 --- 1 file changed, 3 deletions(-) diff --git a/dev_tools/utils/nxdl_utils.py b/dev_tools/utils/nxdl_utils.py index f389aac932..0d2ac0a6c1 100644 --- a/dev_tools/utils/nxdl_utils.py +++ b/dev_tools/utils/nxdl_utils.py @@ -14,9 +14,6 @@ import lxml.etree as ET from lxml.etree import ParseError as xmlER -import numpy as np -from typing import Union, List, Optional - def decode_string( string_obj: Union[np.ndarray, bytes, str], decode: bool = True From c543a141f7c92916bd0219cf50b5e956a2a9bb28 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 11 Sep 2024 16:16:56 +0200 Subject: [PATCH 0938/1012] black formatting --- dev_tools/tests/test_nxdl_utils.py | 40 +++++++++++++++++------------- dev_tools/utils/nxdl_utils.py | 29 ++++++++++++++++------ 2 files changed, 44 insertions(+), 25 deletions(-) diff --git a/dev_tools/tests/test_nxdl_utils.py b/dev_tools/tests/test_nxdl_utils.py index 99408b0360..c3ffd9b7e6 100644 --- a/dev_tools/tests/test_nxdl_utils.py +++ b/dev_tools/tests/test_nxdl_utils.py @@ -196,31 +196,35 @@ def test_namefitting_precedence(better_fit, better_ref, worse_fit, worse_ref): worse_fit, worse_ref ) + @pytest.mark.parametrize( "string_obj, decode, expected", [ # Test with np.ndarray - (np.array([b'fixed1', b'fixed2'], dtype='S10'), True, ['fixed1', 'fixed2']), - (np.array([b'fixed1 ', b'fixed2 '], dtype='S10'), False, np.array([b'fixed1 ', b'fixed2 '], dtype='S10')), - - (np.array([b'var1', b'var2', b'var3']), True, ['var1', 'var2', 'var3']), - (np.array([b'var1', b'var2', b'var3']), False, np.array([b'var1', b'var2', b'var3'])), - + (np.array([b"fixed1", b"fixed2"], dtype="S10"), True, ["fixed1", "fixed2"]), + ( + np.array([b"fixed1 ", b"fixed2 "], dtype="S10"), + False, + np.array([b"fixed1 ", b"fixed2 "], dtype="S10"), + ), + (np.array([b"var1", b"var2", b"var3"]), True, ["var1", "var2", "var3"]), + ( + np.array([b"var1", b"var2", b"var3"]), + False, + np.array([b"var1", b"var2", b"var3"]), + ), (np.array([], dtype=object), True, None), (np.array([], dtype=object), False, np.array([])), - # # Test with bytes - (b'single', True, 'single'), - (b'single', False, b'single'), - + (b"single", True, "single"), + (b"single", False, b"single"), # Test with str - ('single', True, 'single'), - ('single', False, 'single'), - + ("single", True, "single"), + ("single", False, "single"), # Test with mixed np.ndarray - (np.array([b'bytes', 'string'], dtype=object), True, ['bytes', 'string']), + (np.array([b"bytes", "string"], dtype=object), True, ["bytes", "string"]), # (np.array([b'bytes', 'string'], dtype=object), False, np.array([b'bytes', 'string'], dtype=object)), - ] + ], ) def test_decode_string(string_obj, decode, expected): # Handle normal cases @@ -228,7 +232,9 @@ def test_decode_string(string_obj, decode, expected): if isinstance(expected, list): assert list(result) == expected, f"Failed for {string_obj} with decode={decode}" elif isinstance(expected, np.ndarray): - assert (result == expected).all(), f"Failed for {string_obj} with decode={decode}" + assert ( + result == expected + ).all(), f"Failed for {string_obj} with decode={decode}" else: assert result == expected, f"Failed for {string_obj} with decode={decode}" @@ -238,7 +244,7 @@ def test_decode_string(string_obj, decode, expected): [ (123, True), (123, False), - ] + ], ) def test_decode_string_exceptions(string_obj, decode): with pytest.raises(ValueError): diff --git a/dev_tools/utils/nxdl_utils.py b/dev_tools/utils/nxdl_utils.py index 0d2ac0a6c1..3c5b87d887 100644 --- a/dev_tools/utils/nxdl_utils.py +++ b/dev_tools/utils/nxdl_utils.py @@ -14,9 +14,9 @@ import lxml.etree as ET from lxml.etree import ParseError as xmlER + def decode_string( - string_obj: Union[np.ndarray, bytes, str], - decode: bool = True + string_obj: Union[np.ndarray, bytes, str], decode: bool = True ) -> Optional[Union[str, List[str], np.ndarray, bytes]]: """ Decodes a numpy ndarray of byte objects to a Python string or list of strings. @@ -37,7 +37,9 @@ def decode_string( if not decode: # Return the initial value without decoding if not isinstance(string_obj, (np.ndarray, bytes, str)): - raise ValueError(f"Unsupported type {type(string_obj)}. Expected np.ndarray, bytes, or str.") + raise ValueError( + f"Unsupported type {type(string_obj)}. Expected np.ndarray, bytes, or str." + ) if isinstance(string_obj, np.ndarray): return string_obj.tolist() if string_obj.size > 0 else None return string_obj @@ -47,11 +49,20 @@ def decode_string( return None # Handle fixed-length strings by stripping padding - if string_obj.dtype.kind == 'S': - valid_entries = [entry.decode("utf-8").rstrip('\x00') if isinstance(entry, bytes) else entry - for entry in string_obj if isinstance(entry, (str, bytes))] + if string_obj.dtype.kind == "S": + valid_entries = [ + ( + entry.decode("utf-8").rstrip("\x00") + if isinstance(entry, bytes) + else entry + ) + for entry in string_obj + if isinstance(entry, (str, bytes)) + ] else: - valid_entries = [entry for entry in string_obj if isinstance(entry, (str, bytes))] + valid_entries = [ + entry for entry in string_obj if isinstance(entry, (str, bytes)) + ] # Decode bytes to strings where necessary decoded_list = [] @@ -79,7 +90,9 @@ def decode_string( return string_obj else: - raise ValueError(f"Unsupported type {type(string_obj)}. Expected np.ndarray, bytes, or str.") + raise ValueError( + f"Unsupported type {type(string_obj)}. Expected np.ndarray, bytes, or str." + ) def remove_namespace_from_tag(tag): From 4dec01edaaeca962d281b185b1bc3959277ded40 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 11 Sep 2024 16:42:41 +0200 Subject: [PATCH 0939/1012] remove code and move to pynxtools --- dev_tools/tests/test_nxdl_utils.py | 57 +------------------- dev_tools/utils/nxdl_utils.py | 86 +----------------------------- 2 files changed, 3 insertions(+), 140 deletions(-) diff --git a/dev_tools/tests/test_nxdl_utils.py b/dev_tools/tests/test_nxdl_utils.py index c3ffd9b7e6..b72a33aded 100644 --- a/dev_tools/tests/test_nxdl_utils.py +++ b/dev_tools/tests/test_nxdl_utils.py @@ -22,7 +22,6 @@ import lxml.etree as ET import pytest -import numpy as np from ..utils import nxdl_utils as nexus @@ -194,58 +193,4 @@ def test_namefitting_precedence(better_fit, better_ref, worse_fit, worse_ref): assert nexus.get_nx_namefit(better_fit, better_ref) > nexus.get_nx_namefit( worse_fit, worse_ref - ) - - -@pytest.mark.parametrize( - "string_obj, decode, expected", - [ - # Test with np.ndarray - (np.array([b"fixed1", b"fixed2"], dtype="S10"), True, ["fixed1", "fixed2"]), - ( - np.array([b"fixed1 ", b"fixed2 "], dtype="S10"), - False, - np.array([b"fixed1 ", b"fixed2 "], dtype="S10"), - ), - (np.array([b"var1", b"var2", b"var3"]), True, ["var1", "var2", "var3"]), - ( - np.array([b"var1", b"var2", b"var3"]), - False, - np.array([b"var1", b"var2", b"var3"]), - ), - (np.array([], dtype=object), True, None), - (np.array([], dtype=object), False, np.array([])), - # # Test with bytes - (b"single", True, "single"), - (b"single", False, b"single"), - # Test with str - ("single", True, "single"), - ("single", False, "single"), - # Test with mixed np.ndarray - (np.array([b"bytes", "string"], dtype=object), True, ["bytes", "string"]), - # (np.array([b'bytes', 'string'], dtype=object), False, np.array([b'bytes', 'string'], dtype=object)), - ], -) -def test_decode_string(string_obj, decode, expected): - # Handle normal cases - result = nexus.decode_string(string_obj, decode) - if isinstance(expected, list): - assert list(result) == expected, f"Failed for {string_obj} with decode={decode}" - elif isinstance(expected, np.ndarray): - assert ( - result == expected - ).all(), f"Failed for {string_obj} with decode={decode}" - else: - assert result == expected, f"Failed for {string_obj} with decode={decode}" - - -@pytest.mark.parametrize( - "string_obj, decode", - [ - (123, True), - (123, False), - ], -) -def test_decode_string_exceptions(string_obj, decode): - with pytest.raises(ValueError): - nexus.decode_string(string_obj, decode) + ) \ No newline at end of file diff --git a/dev_tools/utils/nxdl_utils.py b/dev_tools/utils/nxdl_utils.py index 3c5b87d887..dca17cb3f5 100644 --- a/dev_tools/utils/nxdl_utils.py +++ b/dev_tools/utils/nxdl_utils.py @@ -7,94 +7,12 @@ from functools import lru_cache from glob import glob from pathlib import Path -from typing import List, Optional, Union - -import numpy as np +from typing import List, Optional import lxml.etree as ET from lxml.etree import ParseError as xmlER -def decode_string( - string_obj: Union[np.ndarray, bytes, str], decode: bool = True -) -> Optional[Union[str, List[str], np.ndarray, bytes]]: - """ - Decodes a numpy ndarray of byte objects to a Python string or list of strings. - Also handles single bytes and string objects. If `decode` is False, returns the - initial value without decoding. - - Args: - string_obj: A numpy ndarray, bytes, or str that may need decoding. - decode: A boolean flag indicating whether to perform decoding. - - Returns: - A decoded string, a list of decoded strings, or the initial value if `decode` is False. - Returns None if the input is empty or invalid. - - Raises: - ValueError: If `string_obj` is not one of the supported types or decoding fails. - """ - if not decode: - # Return the initial value without decoding - if not isinstance(string_obj, (np.ndarray, bytes, str)): - raise ValueError( - f"Unsupported type {type(string_obj)}. Expected np.ndarray, bytes, or str." - ) - if isinstance(string_obj, np.ndarray): - return string_obj.tolist() if string_obj.size > 0 else None - return string_obj - - if isinstance(string_obj, np.ndarray): - if string_obj.size == 0: - return None - - # Handle fixed-length strings by stripping padding - if string_obj.dtype.kind == "S": - valid_entries = [ - ( - entry.decode("utf-8").rstrip("\x00") - if isinstance(entry, bytes) - else entry - ) - for entry in string_obj - if isinstance(entry, (str, bytes)) - ] - else: - valid_entries = [ - entry for entry in string_obj if isinstance(entry, (str, bytes)) - ] - - # Decode bytes to strings where necessary - decoded_list = [] - for entry in valid_entries: - if isinstance(entry, bytes): - try: - decoded_list.append(entry.decode("utf-8")) - except UnicodeDecodeError as e: - raise ValueError(f"Error decoding bytes: {e}") - else: - decoded_list.append(entry) - - # Return a scalar string if there's only one element, otherwise return the list - if len(decoded_list) == 1: - return decoded_list[0] - return decoded_list if decoded_list else None - - elif isinstance(string_obj, bytes): - try: - return string_obj.decode("utf-8") - except UnicodeDecodeError as e: - raise ValueError(f"Error decoding bytes: {e}") - - elif isinstance(string_obj, str): - return string_obj - - else: - raise ValueError( - f"Unsupported type {type(string_obj)}. Expected np.ndarray, bytes, or str." - ) - - def remove_namespace_from_tag(tag): """Helper function to remove the namespace from an XML tag.""" @@ -851,7 +769,7 @@ def get_best_child(nxdl_elem, hdf_node, hdf_name, hdf_class_name, nexus_type): and nxdl_elem.attrib["name"] == "NXdata" and hdf_node is not None and hdf_node.parent is not None - and decode_or_not(hdf_node.parent.attrs.get("NX_class")) == "NXdata" + and decode_string(hdf_node.parent.attrs.get("NX_class")) == "NXdata" ): (fnd_child, fit) = get_best_nxdata_child(nxdl_elem, hdf_node, hdf_name) if fnd_child is not None: From 7bab9e26f0b53d3d8add253a38c7536f6fa86ad7 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 11 Sep 2024 16:43:51 +0200 Subject: [PATCH 0940/1012] remove unneeded requirements --- dev_tools/tests/test_nxdl_utils.py | 2 +- requirements.txt | 5 +---- 2 files changed, 2 insertions(+), 5 deletions(-) diff --git a/dev_tools/tests/test_nxdl_utils.py b/dev_tools/tests/test_nxdl_utils.py index b72a33aded..3c1c722e08 100644 --- a/dev_tools/tests/test_nxdl_utils.py +++ b/dev_tools/tests/test_nxdl_utils.py @@ -193,4 +193,4 @@ def test_namefitting_precedence(better_fit, better_ref, worse_fit, worse_ref): assert nexus.get_nx_namefit(better_fit, better_ref) > nexus.get_nx_namefit( worse_fit, worse_ref - ) \ No newline at end of file + ) diff --git a/requirements.txt b/requirements.txt index 1fd4c32dea..8237e14407 100644 --- a/requirements.txt +++ b/requirements.txt @@ -15,7 +15,4 @@ pytest # Code style and auto-formatting black>=24.1.1 flake8>=4 -isort>=5.10 - -# String decoding -numpy \ No newline at end of file +isort>=5.10 \ No newline at end of file From d6eabbb872beb19aa864aca630319dccb85cb62f Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 11 Sep 2024 17:53:58 +0200 Subject: [PATCH 0941/1012] escape black check --- dev_tools/utils/nxdl_utils.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/dev_tools/utils/nxdl_utils.py b/dev_tools/utils/nxdl_utils.py index dca17cb3f5..2ab42b5945 100644 --- a/dev_tools/utils/nxdl_utils.py +++ b/dev_tools/utils/nxdl_utils.py @@ -769,7 +769,8 @@ def get_best_child(nxdl_elem, hdf_node, hdf_name, hdf_class_name, nexus_type): and nxdl_elem.attrib["name"] == "NXdata" and hdf_node is not None and hdf_node.parent is not None - and decode_string(hdf_node.parent.attrs.get("NX_class")) == "NXdata" + and decode_string(hdf_node.parent.attrs.get("NX_class")) + == "NXdata" # noqa: F821 ): (fnd_child, fit) = get_best_nxdata_child(nxdl_elem, hdf_node, hdf_name) if fnd_child is not None: From e33d9a8cb2f032f991e7f4ebb82bf2acdd45bd08 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 11 Sep 2024 18:01:41 +0200 Subject: [PATCH 0942/1012] ignore flake8 issue --- dev_tools/utils/nxdl_utils.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/dev_tools/utils/nxdl_utils.py b/dev_tools/utils/nxdl_utils.py index 2ab42b5945..be086a792d 100644 --- a/dev_tools/utils/nxdl_utils.py +++ b/dev_tools/utils/nxdl_utils.py @@ -769,8 +769,8 @@ def get_best_child(nxdl_elem, hdf_node, hdf_name, hdf_class_name, nexus_type): and nxdl_elem.attrib["name"] == "NXdata" and hdf_node is not None and hdf_node.parent is not None - and decode_string(hdf_node.parent.attrs.get("NX_class")) - == "NXdata" # noqa: F821 + and decode_string(hdf_node.parent.attrs.get("NX_class")) # noqa: F821 + == "NXdata" ): (fnd_child, fit) = get_best_nxdata_child(nxdl_elem, hdf_node, hdf_name) if fnd_child is not None: From f72c27f88257fb5e0e46776cad5cef67b3b6cffc Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 11 Sep 2024 18:04:03 +0200 Subject: [PATCH 0943/1012] isort imports --- dev_tools/utils/nxdl_utils.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/dev_tools/utils/nxdl_utils.py b/dev_tools/utils/nxdl_utils.py index be086a792d..ea6d0b2c3f 100644 --- a/dev_tools/utils/nxdl_utils.py +++ b/dev_tools/utils/nxdl_utils.py @@ -7,7 +7,8 @@ from functools import lru_cache from glob import glob from pathlib import Path -from typing import List, Optional +from typing import List +from typing import Optional import lxml.etree as ET from lxml.etree import ParseError as xmlER From 9a9c70bb366739c307989adedb6e91dd04f81134 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 12 Sep 2024 08:48:29 +0200 Subject: [PATCH 0944/1012] use less strict version of str decoding --- dev_tools/utils/nxdl_utils.py | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/dev_tools/utils/nxdl_utils.py b/dev_tools/utils/nxdl_utils.py index ea6d0b2c3f..a8d0a6c0d3 100644 --- a/dev_tools/utils/nxdl_utils.py +++ b/dev_tools/utils/nxdl_utils.py @@ -9,11 +9,27 @@ from pathlib import Path from typing import List from typing import Optional +from typing import Union import lxml.etree as ET from lxml.etree import ParseError as xmlER +def decode_or_not(elem: Union[bytes, str]) -> str: + """Decodes a byte array to string if necessary""" + if isinstance(elem, bytes): + try: + return elem.decode("utf-8") + except UnicodeDecodeError as e: + raise ValueError(f"Error decoding bytes: {e}") + + elif isinstance(elem, str): + return elem + + else: + raise ValueError(f"Unsupported type {type(elem)}. Expected bytes, or str.") + + def remove_namespace_from_tag(tag): """Helper function to remove the namespace from an XML tag.""" @@ -770,7 +786,7 @@ def get_best_child(nxdl_elem, hdf_node, hdf_name, hdf_class_name, nexus_type): and nxdl_elem.attrib["name"] == "NXdata" and hdf_node is not None and hdf_node.parent is not None - and decode_string(hdf_node.parent.attrs.get("NX_class")) # noqa: F821 + and decode_or_not(hdf_node.parent.attrs.get("NX_class")) # noqa: F821 == "NXdata" ): (fnd_child, fit) = get_best_nxdata_child(nxdl_elem, hdf_node, hdf_name) From f40693e5b564ca3ec182f87d20bf0d02f1b09a01 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 12 Sep 2024 09:15:44 +0200 Subject: [PATCH 0945/1012] slightly enhanced version of str decoding, test --- dev_tools/tests/test_nxdl_utils.py | 27 +++++++++++++++++++++++++++ dev_tools/utils/nxdl_utils.py | 11 +++++++++-- 2 files changed, 36 insertions(+), 2 deletions(-) diff --git a/dev_tools/tests/test_nxdl_utils.py b/dev_tools/tests/test_nxdl_utils.py index 3c1c722e08..043e48487e 100644 --- a/dev_tools/tests/test_nxdl_utils.py +++ b/dev_tools/tests/test_nxdl_utils.py @@ -194,3 +194,30 @@ def test_namefitting_precedence(better_fit, better_ref, worse_fit, worse_ref): assert nexus.get_nx_namefit(better_fit, better_ref) > nexus.get_nx_namefit( worse_fit, worse_ref ) + +@pytest.mark.parametrize( + "string_obj, decode, expected", + [ + (b"single", True, "single"), + (b"single", False, b"single"), + # Test with str + ("single", True, "single"), + ("single", False, "single"), + ], +) +def test_decode_string(string_obj, decode, expected): + # Handle normal cases + result = nexus.decode_or_not(string_obj, decode) + assert result == expected, f"Failed for {string_obj} with decode={decode}" + + +@pytest.mark.parametrize( + "string_obj, decode", + [ + (123, True), + (123, False), + ], +) +def test_decode_string_exceptions(string_obj, decode): + with pytest.raises(ValueError): + nexus.decode_or_not(string_obj, decode) \ No newline at end of file diff --git a/dev_tools/utils/nxdl_utils.py b/dev_tools/utils/nxdl_utils.py index a8d0a6c0d3..ad0cfbb742 100644 --- a/dev_tools/utils/nxdl_utils.py +++ b/dev_tools/utils/nxdl_utils.py @@ -15,8 +15,15 @@ from lxml.etree import ParseError as xmlER -def decode_or_not(elem: Union[bytes, str]) -> str: +def decode_or_not(elem: Union[bytes, str], decode: bool = True) -> str: """Decodes a byte array to string if necessary""" + __error_msg = f"Unsupported type {type(elem)}. Expected bytes, or str." + if not decode: + # Return the initial value without decoding + if not isinstance(elem, (bytes, str)): + raise ValueError(__error_msg) + return elem + if isinstance(elem, bytes): try: return elem.decode("utf-8") @@ -27,7 +34,7 @@ def decode_or_not(elem: Union[bytes, str]) -> str: return elem else: - raise ValueError(f"Unsupported type {type(elem)}. Expected bytes, or str.") + raise ValueError(__error_msg) def remove_namespace_from_tag(tag): From 611af7ce7883079529356c3fda47448dcd5f532b Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 12 Sep 2024 09:17:20 +0200 Subject: [PATCH 0946/1012] remove flake error catching --- dev_tools/utils/nxdl_utils.py | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/dev_tools/utils/nxdl_utils.py b/dev_tools/utils/nxdl_utils.py index ad0cfbb742..264b9ff898 100644 --- a/dev_tools/utils/nxdl_utils.py +++ b/dev_tools/utils/nxdl_utils.py @@ -793,8 +793,7 @@ def get_best_child(nxdl_elem, hdf_node, hdf_name, hdf_class_name, nexus_type): and nxdl_elem.attrib["name"] == "NXdata" and hdf_node is not None and hdf_node.parent is not None - and decode_or_not(hdf_node.parent.attrs.get("NX_class")) # noqa: F821 - == "NXdata" + and decode_or_not(hdf_node.parent.attrs.get("NX_class")) == "NXdata" ): (fnd_child, fit) = get_best_nxdata_child(nxdl_elem, hdf_node, hdf_name) if fnd_child is not None: From a2d12284269f86d975b612c11ab25c94fe503e66 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 12 Sep 2024 09:20:03 +0200 Subject: [PATCH 0947/1012] reset requirements.txt --- requirements.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/requirements.txt b/requirements.txt index 8237e14407..74294d9b26 100644 --- a/requirements.txt +++ b/requirements.txt @@ -15,4 +15,4 @@ pytest # Code style and auto-formatting black>=24.1.1 flake8>=4 -isort>=5.10 \ No newline at end of file +isort>=5.10 From a9856f63e86496bef64f8e6f12dfc214ac261fa8 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 12 Sep 2024 09:22:10 +0200 Subject: [PATCH 0948/1012] reformatting --- dev_tools/tests/test_nxdl_utils.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/dev_tools/tests/test_nxdl_utils.py b/dev_tools/tests/test_nxdl_utils.py index 043e48487e..1494667f5d 100644 --- a/dev_tools/tests/test_nxdl_utils.py +++ b/dev_tools/tests/test_nxdl_utils.py @@ -195,6 +195,7 @@ def test_namefitting_precedence(better_fit, better_ref, worse_fit, worse_ref): worse_fit, worse_ref ) + @pytest.mark.parametrize( "string_obj, decode, expected", [ @@ -220,4 +221,4 @@ def test_decode_string(string_obj, decode, expected): ) def test_decode_string_exceptions(string_obj, decode): with pytest.raises(ValueError): - nexus.decode_or_not(string_obj, decode) \ No newline at end of file + nexus.decode_or_not(string_obj, decode) From 3039fe39a9eb4518236bfb06b2a05b501a853ec6 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 12 Sep 2024 09:34:51 +0200 Subject: [PATCH 0949/1012] remove strict type checking --- dev_tools/tests/test_nxdl_utils.py | 22 +++++++------------- dev_tools/utils/nxdl_utils.py | 32 ++++++++++++++++++------------ 2 files changed, 26 insertions(+), 28 deletions(-) diff --git a/dev_tools/tests/test_nxdl_utils.py b/dev_tools/tests/test_nxdl_utils.py index 1494667f5d..84c1e5b1c8 100644 --- a/dev_tools/tests/test_nxdl_utils.py +++ b/dev_tools/tests/test_nxdl_utils.py @@ -199,26 +199,18 @@ def test_namefitting_precedence(better_fit, better_ref, worse_fit, worse_ref): @pytest.mark.parametrize( "string_obj, decode, expected", [ + # Test with bytes (b"single", True, "single"), (b"single", False, b"single"), # Test with str ("single", True, "single"), ("single", False, "single"), + # Test with int + (123, True, 123), + (123, False, 123), ], ) -def test_decode_string(string_obj, decode, expected): +def test_decode_or_not(string_obj, decode, expected): # Handle normal cases - result = nexus.decode_or_not(string_obj, decode) - assert result == expected, f"Failed for {string_obj} with decode={decode}" - - -@pytest.mark.parametrize( - "string_obj, decode", - [ - (123, True), - (123, False), - ], -) -def test_decode_string_exceptions(string_obj, decode): - with pytest.raises(ValueError): - nexus.decode_or_not(string_obj, decode) + result = nexus.decode_or_not(elem=string_obj, decode=decode) + assert result == expected, f"Failed for {string_obj} with decode={decode}" \ No newline at end of file diff --git a/dev_tools/utils/nxdl_utils.py b/dev_tools/utils/nxdl_utils.py index 264b9ff898..33b38d7f27 100644 --- a/dev_tools/utils/nxdl_utils.py +++ b/dev_tools/utils/nxdl_utils.py @@ -9,32 +9,38 @@ from pathlib import Path from typing import List from typing import Optional -from typing import Union import lxml.etree as ET from lxml.etree import ParseError as xmlER -def decode_or_not(elem: Union[bytes, str], decode: bool = True) -> str: - """Decodes a byte array to string if necessary""" - __error_msg = f"Unsupported type {type(elem)}. Expected bytes, or str." +def decode_or_not(elem, encoding: str = "utf-8", decode: bool = True): + """ + Decodes a byte array to a string if necessary. All other types are returned untouched. + If `decode` is False, the initial value is returned without decoding, including for byte arrays. + + Args: + elem: Any Python object that may need decoding. + encoding: The encoding scheme to use. Default is "utf-8". + decode: A boolean flag indicating whether to perform decoding. + + Returns: + A decoded string (in case of a byte string) or the initial value. + If `decode` is False, always returns the initial value. + + Raises: + ValueError: If a byte string cannot be decoded using the provided encoding. + """ if not decode: - # Return the initial value without decoding - if not isinstance(elem, (bytes, str)): - raise ValueError(__error_msg) return elem if isinstance(elem, bytes): try: - return elem.decode("utf-8") + return elem.decode(encoding) except UnicodeDecodeError as e: raise ValueError(f"Error decoding bytes: {e}") - elif isinstance(elem, str): - return elem - - else: - raise ValueError(__error_msg) + return elem def remove_namespace_from_tag(tag): From b9e537c15d9ddc6f2ea4f99bb872bbdde47f053a Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 12 Sep 2024 10:33:22 +0200 Subject: [PATCH 0950/1012] add support for list of bytes --- dev_tools/tests/test_nxdl_utils.py | 20 +++++++++++++++++++- dev_tools/utils/nxdl_utils.py | 8 ++++++++ 2 files changed, 27 insertions(+), 1 deletion(-) diff --git a/dev_tools/tests/test_nxdl_utils.py b/dev_tools/tests/test_nxdl_utils.py index 84c1e5b1c8..b9c5c2e5c6 100644 --- a/dev_tools/tests/test_nxdl_utils.py +++ b/dev_tools/tests/test_nxdl_utils.py @@ -199,12 +199,26 @@ def test_namefitting_precedence(better_fit, better_ref, worse_fit, worse_ref): @pytest.mark.parametrize( "string_obj, decode, expected", [ + # Test with lists of bytes and strings + ([b"bytes", "string"], True, ["bytes", "string"]), + ([b"bytes", "string"], False, [b"bytes", "string"]), + ([b"bytes", b"more_bytes", "string"], True, ["bytes", "more_bytes", "string"]), + ([b"bytes", b"more_bytes", "string"], False, [b"bytes", b"more_bytes", "string"]), + ([b"fixed", b"length", b"strings"], True, ["fixed", "length", "strings"]), + ([b"fixed", b"length", b"strings"], False, [b"fixed", b"length", b"strings"]), + + # Test with nested lists + ([[b"nested1"], [b"nested2"]], True, [["nested1"], ["nested2"]]), + ([[b"nested1"], [b"nested2"]], False, [[b"nested1"], [b"nested2"]]), + # Test with bytes (b"single", True, "single"), (b"single", False, b"single"), + # Test with str ("single", True, "single"), ("single", False, "single"), + # Test with int (123, True, 123), (123, False, 123), @@ -213,4 +227,8 @@ def test_namefitting_precedence(better_fit, better_ref, worse_fit, worse_ref): def test_decode_or_not(string_obj, decode, expected): # Handle normal cases result = nexus.decode_or_not(elem=string_obj, decode=decode) - assert result == expected, f"Failed for {string_obj} with decode={decode}" \ No newline at end of file + if isinstance(expected, list): + assert isinstance(result, list), f"Expected list, but got {type(result)}" + # Handle all other cases + else: + assert result == expected, f"Failed for {string_obj} with decode={decode}" \ No newline at end of file diff --git a/dev_tools/utils/nxdl_utils.py b/dev_tools/utils/nxdl_utils.py index 33b38d7f27..169d0be039 100644 --- a/dev_tools/utils/nxdl_utils.py +++ b/dev_tools/utils/nxdl_utils.py @@ -34,6 +34,14 @@ def decode_or_not(elem, encoding: str = "utf-8", decode: bool = True): if not decode: return elem + # Handle lists of bytes or strings + elif isinstance(elem, list): + if not elem: + return elem # Return an empty list unchanged + + decoded_list = [decode_or_not(x, encoding, decode) for x in elem] + return decoded_list + if isinstance(elem, bytes): try: return elem.decode(encoding) From c10e52ab6ae1e54df106e40dc136d65092e18418 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 12 Sep 2024 10:37:13 +0200 Subject: [PATCH 0951/1012] formatting --- dev_tools/tests/test_nxdl_utils.py | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/dev_tools/tests/test_nxdl_utils.py b/dev_tools/tests/test_nxdl_utils.py index b9c5c2e5c6..de0e87c3df 100644 --- a/dev_tools/tests/test_nxdl_utils.py +++ b/dev_tools/tests/test_nxdl_utils.py @@ -203,22 +203,22 @@ def test_namefitting_precedence(better_fit, better_ref, worse_fit, worse_ref): ([b"bytes", "string"], True, ["bytes", "string"]), ([b"bytes", "string"], False, [b"bytes", "string"]), ([b"bytes", b"more_bytes", "string"], True, ["bytes", "more_bytes", "string"]), - ([b"bytes", b"more_bytes", "string"], False, [b"bytes", b"more_bytes", "string"]), + ( + [b"bytes", b"more_bytes", "string"], + False, + [b"bytes", b"more_bytes", "string"], + ), ([b"fixed", b"length", b"strings"], True, ["fixed", "length", "strings"]), ([b"fixed", b"length", b"strings"], False, [b"fixed", b"length", b"strings"]), - # Test with nested lists ([[b"nested1"], [b"nested2"]], True, [["nested1"], ["nested2"]]), ([[b"nested1"], [b"nested2"]], False, [[b"nested1"], [b"nested2"]]), - # Test with bytes (b"single", True, "single"), (b"single", False, b"single"), - # Test with str ("single", True, "single"), ("single", False, "single"), - # Test with int (123, True, 123), (123, False, 123), @@ -231,4 +231,4 @@ def test_decode_or_not(string_obj, decode, expected): assert isinstance(result, list), f"Expected list, but got {type(result)}" # Handle all other cases else: - assert result == expected, f"Failed for {string_obj} with decode={decode}" \ No newline at end of file + assert result == expected, f"Failed for {string_obj} with decode={decode}" From 67072591a7a1ad27edfd1779c2d14ec2998184af Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 13 Sep 2024 10:04:09 +0200 Subject: [PATCH 0952/1012] add pulse_delay to NXbeam --- base_classes/NXbeam.nxdl.xml | 10 ++++++++++ base_classes/nyaml/NXbeam.yaml | 26 +++++++++++++++++++++++--- 2 files changed, 33 insertions(+), 3 deletions(-) diff --git a/base_classes/NXbeam.nxdl.xml b/base_classes/NXbeam.nxdl.xml index dad046d605..126ca8248c 100644 --- a/base_classes/NXbeam.nxdl.xml +++ b/base_classes/NXbeam.nxdl.xml @@ -362,6 +362,16 @@ FWHM duration of the pulses at the diagnostic point + + + Delay time between two pulses of a pulsed beam. + + + + A reference to the beam in relation to which the delay is. + + + FROG trace of the pulse. diff --git a/base_classes/nyaml/NXbeam.yaml b/base_classes/nyaml/NXbeam.yaml index 3418ce5f56..48e5a91d74 100644 --- a/base_classes/nyaml/NXbeam.yaml +++ b/base_classes/nyaml/NXbeam.yaml @@ -158,7 +158,7 @@ NXbeam(NXobject): unit: NX_LENGTH doc: | Size of the beam entering this component. Note this represents - a rectangular beam aperture, and values represent FWHM. + a rectangular beam aperture, and values represent FWHM. If applicable, the first dimension shall be the horizontal extent and the second dimension shall be the vertical extent. dimensions: @@ -295,6 +295,14 @@ NXbeam(NXobject): unit: NX_TIME doc: | FWHM duration of the pulses at the diagnostic point + pulse_delay(NX_FLOAT): + unit: NX_TIME + doc: | + Delay time between two pulses of a pulsed beam. + \@reference_beam: + type: NX_CHAR + doc: | + A reference to the beam in relation to which the delay is. frog_trace(NX_FLOAT): doc: | FROG trace of the pulse. @@ -404,7 +412,7 @@ NXbeam(NXobject): Gives the beam device which this beam will interact with next. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 0f4d4d5bf996841b80a3b24691b91622899dedd9e07a1944f462d2df2f478f09 +# 4b4f97c455cbb96d280eefb201602589458158a8a9d078fa6820cb67f99cdb67 # # # -# +# +# # -# A beamline aperture. This group is deprecated, use NXslit instead. -# -# +# A beamline aperture. +# +# Note, the group was incorrectly documented as deprecated, but it is not and it is in common use. +# +# # # # NeXus positions components by applying a set of translations and rotations @@ -141,6 +153,11 @@ NXaperture(NXobject): # Stores the raw positions of aperture motors. # # +# +# +# Use this group to describe the shape of the aperture +# +# # # # location and shape of aperture @@ -193,11 +210,7 @@ NXaperture(NXobject): # diameter # # -# -# -# describe any additional information in a note* -# -# +# describe any additional information in a note # # # .. index:: plotting diff --git a/base_classes/nyaml/NXattenuator.yaml b/base_classes/nyaml/NXattenuator.yaml index 21fc404d16..954755f9ce 100644 --- a/base_classes/nyaml/NXattenuator.yaml +++ b/base_classes/nyaml/NXattenuator.yaml @@ -80,13 +80,13 @@ NXattenuator(NXobject): Shape of this component. Particulary useful to define the origin for position and orientation in non-standard cases. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 5cb6333d87df9b8f1b009346d2bf55434c7d4ef72f1ce1b62db27caf873c4f7f +# 2a98b9445482f7224d2131e0af674acad938177775e4eca9be678542b70fe08e # # # +# +# +# +# +# These symbols will be used below to illustrate the coordination of the rank and sizes of datasets and the +# preferred ordering of the dimensions. Each of these are optional (so the rank of the datasets +# will vary according to the situation) and the general ordering principle is slowest to fastest. +# The type of each dimension should follow the order of scan points, detector output (e.g. pixels), +# then time-of-flight (i.e. spectroscopy, spectrometry). Note that the output of a detector is not limited +# to single values (0D), lists (1D) and images (2D), but three or higher dimensional arrays can be produced +# by a detector at each trigger. +# +# +# Rank of the ``data`` field associated with this detector +# number of scan points +# number of detector pixels in the slowest direction +# number of detector pixels in the second slowest direction +# number of detector pixels in the third slowest direction +# +# +# +# Description and metadata for a single channel from a multi-channel detector. +# +# Given an :ref:`NXdata` group linked as part of an NXdetector group that has an axis with named channels (see the +# example in :ref:`NXdata </NXdata@default_slice-attribute>`), the NXdetector will have a series of NXdetector_channel groups, one for each +# channel, named CHANNELNAME_channel. +# +# Example, given these axes in the NXdata group:: +# +# @axes = ["image_id", "channel", ".", "."] +# +# And this list of channels in the NXdata group:: +# +# channel = ["threshold_1", "threshold_2", "difference"] +# +# The NXdetector group would have three NXdetector_channel groups:: +# +# detector:NXdetector +# ... +# threshold_1_channel:NXdetector_channel +# threshold_energy = float +# flatfield = float[i, j] +# pixel_mask = uint[i, j] +# flatfield_applied = bool +# pixel_mask_applied = bool +# threshold_2_channel:NXdetector_channel +# threshold_energy = float +# flatfield = float[i, j] +# pixel_mask = uint[i, j] +# flatfield_applied = bool +# pixel_mask_applied = bool +# difference_channel:NXdetector_channel +# threshold_energy = float[2] +# +# +# +# Energy at which a photon will be recorded +# +# +# +# +# True when the flat field correction has been applied in the +# electronics, false otherwise. +# +# +# +# +# Response of each pixel given a constant input +# +# +# +# +# +# +# +# +# +# Errors of the flat field correction data. +# The form flatfield_error is deprecated. +# +# +# +# +# +# +# +# +# +# True when the pixel mask correction has been applied in the +# electronics, false otherwise. +# +# +# +# +# +# Custom pixel mask for this channel. May include nP as the first dimension for +# masks that vary for each scan point. +# +# +# +# +# +# +# +# +# +# +# The value at which the detector goes into saturation. +# Especially common to CCD detectors, the data +# is known to be invalid above this value. +# +# For example, given a saturation_value and an underload_value, the valid +# pixels are those less than or equal to the saturation_value and greater +# than or equal to the underload_value. +# +# The precise type should match the type of the data. +# +# +# +# +# +# The lowest value at which pixels for this detector would be reasonably +# measured. The data is known to be invalid below this value. +# +# For example, given a saturation_value and an underload_value, the valid +# pixels are those less than or equal to the saturation_value and greater +# than or equal to the underload_value. +# +# The precise type should match the type of the data. +# +# +# diff --git a/base_classes/nyaml/NXdetector_group.yaml b/base_classes/nyaml/NXdetector_group.yaml index c087d3b193..36b716eb63 100644 --- a/base_classes/nyaml/NXdetector_group.yaml +++ b/base_classes/nyaml/NXdetector_group.yaml @@ -76,13 +76,13 @@ NXdetector_group(NXobject): for a summary of the discussion. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 691ea608a29ca9acf2ea185458c9dc75285438032148ac1529e5ebcf0d96b4b7 +# fef1c65c76b06c79fe2f874bd122ffcb8cdf9c895464aeddb7658e8379e30beb # # # +# # # ISIS Muon IDF_Version # @@ -306,13 +308,13 @@ NXentry(NXobject): # Extended title for entry # # -# +# # # Unique identifier for the experiment, # defined by the facility, # possibly linked to the proposals # -# +# # # # Brief summary of the experiment, including key objectives. @@ -323,22 +325,22 @@ NXentry(NXobject): # Description of the full experiment (document in pdf, latex, ...) # # -# +# # # User or Data Acquisition defined group of NeXus files or NXentry # -# +# # # # Brief summary of the collection, including grouping criteria. # # -# +# # # unique identifier for the measurement, defined by the facility. # -# -# +# +# # # UUID identifier for the measurement. # @@ -347,7 +349,7 @@ NXentry(NXobject): # Version of UUID used # # -# +# # # # Reserved for future use by NIAC. @@ -424,7 +426,7 @@ NXentry(NXobject): # # # -# Such as "2007-3". Some user facilities organize their beam time into run cycles. +# Such as "2007-3". Some user facilities organize their beam time into run cycles. # # # diff --git a/base_classes/nyaml/NXenvironment.yaml b/base_classes/nyaml/NXenvironment.yaml index 902a647453..717858b87f 100644 --- a/base_classes/nyaml/NXenvironment.yaml +++ b/base_classes/nyaml/NXenvironment.yaml @@ -78,9 +78,9 @@ NXenvironment(NXobject): # # # A parameter (also known as a term) that is used in or results from processing. # diff --git a/base_classes/nyaml/NXpdb.yaml b/base_classes/nyaml/NXpdb.yaml index 24cfd73920..7aa384a626 100644 --- a/base_classes/nyaml/NXpdb.yaml +++ b/base_classes/nyaml/NXpdb.yaml @@ -143,13 +143,13 @@ NXpdb(NXobject): # See: https://github.com/nexusformat/definitions/issues/259 # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a7abffb938a9848149b6d1c2b7f0e7d0f47792f36c6dc44ad9f3831a9c3c0172 +# 2784bb864dfa1608a7ebfad032a43f399341b538937795276ff0c4923061813c # # # -# -# -# -# -# .. 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 <validItemName>` the default :ref:`NXentry` group. The -# value must be the name of a child of the current group. The child must be a -# NeXus group or a link to a NeXus group. -# -# For more information about how NeXus identifies the default -# plottable data, see the -# :ref:`Find Plottable Data, v3 <Find-Plottable-Data-v3>` -# section. -# -# -# -# -# Group of multiple application definitions for "multi-modal" (e.g. SAXS/WAXS) measurements. -# -# ``NXsubentry`` is a base class virtually identical to :ref:`NXentry` -# and is used as the (overlay) location for application definitions. -# Use a separate ``NXsubentry`` for each application definition. -# -# To use ``NXsubentry`` with a hypothetical application definition -# called ``NXmyappdef``: -# -# * Create a group with attribute ``NX_class="NXsubentry"`` -# * Within that group, create a field called ``definition="NXmyappdef"``. -# * There are two optional attributes of definition: ``version`` and ``URL`` -# -# The intended use is to define application definitions for a -# multi-modal (a.k.a. multi-technique) :ref:`NXentry`. -# Previously, an application definition -# replaced :ref:`NXentry` with its own definition. -# With the increasing popularity of instruments combining -# multiple techniques for data collection (such as SAXS/WAXS instruments), -# it was recognized the application definitions must be entered in the NeXus -# data file tree as children of :ref:`NXentry`. -# -# -# -# -# ISIS Muon IDF_Version -# -# -# -# Extended title for entry -# -# -# -# Unique identifier for the experiment, defined by -# the facility, possibly linked to the proposals -# -# -# -# Brief summary of the experiment, including key objectives. -# -# -# Description of the full experiment (document in pdf, latex, ...) -# -# -# User or Data Acquisition defined group of NeXus files or :ref:`NXentry` -# -# -# Brief summary of the collection, including grouping criteria. -# -# -# unique identifier for the measurement, defined by the facility. -# -# -# Official NeXus NXDL schema to which this subentry conforms -# NXDL version number -# URL of NXDL file -# -# -# -# Local NXDL schema extended from the subentry -# specified in the ``definition`` field. -# This contains any locally-defined, -# additional fields in the subentry. -# -# NXDL version number -# URL of NXDL file -# -# -# Starting time of measurement -# -# -# Ending time of measurement -# -# -# Duration of measurement -# -# -# -# Time transpired actually collecting data i.e. taking out time when collection was -# suspended due to e.g. temperature out of range -# -# -# -# Such as "2007-3". Some user facilities organize their beam time into run cycles. -# -# -# Name of program used to generate this file -# Program version number -# configuration of the program -# -# -# -# Revision id of the file due to re-calibration, reprocessing, new analysis, new -# instrument definition format, ... -# -# -# -# -# -# This is the flightpath before the sample position. This can be determined by a chopper, -# by the moderator or the source itself. In other words: it the distance to the component -# which gives the T0 signal to the detector electronics. If another component in the -# NXinstrument hierarchy provides this information, this should be a link. -# -# -# -# Notes describing entry -# -# -# -# A small image that is representative of the entry. An example of this is a 640x480 -# jpeg image automatically produced by a low resolution plot of the NXdata. -# -# -# The value should be an ``image/*`` -# -# -# -# -# -# -# -# -# -# -# -# -# -# +# +# +# Group of multiple application definitions for "multi-modal" (e.g. SAXS/WAXS) measurements. +# +# ``NXsubentry`` is a base class virtually identical to :ref:`NXentry` +# and is used as the (overlay) location for application definitions. +# Use a separate ``NXsubentry`` for each application definition. +# +# To use ``NXsubentry`` with a hypothetical application definition +# called ``NXmyappdef``: +# +# * Create a group with attribute ``NX_class="NXsubentry"`` +# * Within that group, create a field called ``definition="NXmyappdef"``. +# * There are two optional attributes of definition: ``version`` and ``URL`` +# +# The intended use is to define application definitions for a +# multi-modal (a.k.a. multi-technique) :ref:`NXentry`. +# Previously, an application definition +# replaced :ref:`NXentry` with its own definition. +# With the increasing popularity of instruments combining +# multiple techniques for data collection (such as SAXS/WAXS instruments), +# it was recognized the application definitions must be entered in the NeXus +# data file tree as children of :ref:`NXentry`. +# +# +# +# .. 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 <validItemName>` the default :ref:`NXentry` group. The +# value must be the name of a child of the current group. The child must be a +# NeXus group or a link to a NeXus group. +# +# For more information about how NeXus identifies the default +# plottable data, see the +# :ref:`Find Plottable Data, v3 <Find-Plottable-Data-v3>` +# section. +# +# +# +# +# +# ISIS Muon IDF_Version +# +# +# +# +# Extended title for entry +# +# +# +# +# Unique identifier for the experiment, defined by +# the facility, possibly linked to the proposals +# +# +# +# +# Brief summary of the experiment, including key objectives. +# +# +# +# +# Description of the full experiment (document in pdf, latex, ...) +# +# +# +# +# User or Data Acquisition defined group of NeXus files or :ref:`NXentry` +# +# +# +# +# Brief summary of the collection, including grouping criteria. +# +# +# +# +# unique identifier for the measurement, defined by the facility. +# +# +# +# +# Official NeXus NXDL schema to which this subentry conforms +# +# +# +# NXDL version number +# +# +# +# +# URL of NXDL file +# +# +# +# +# +# Local NXDL schema extended from the subentry +# specified in the ``definition`` field. +# This contains any locally-defined, +# additional fields in the subentry. +# +# +# +# NXDL version number +# +# +# +# +# URL of NXDL file +# +# +# +# +# +# Starting time of measurement +# +# +# +# +# Ending time of measurement +# +# +# +# +# Duration of measurement +# +# +# +# +# Time transpired actually collecting data i.e. taking out time when collection was +# suspended due to e.g. temperature out of range +# +# +# +# +# Such as "2007-3". Some user facilities organize their beam time into run cycles. +# +# +# +# +# Name of program used to generate this file +# +# +# +# Program version number +# +# +# +# +# configuration of the program +# +# +# +# +# +# Revision id of the file due to re-calibration, reprocessing, new analysis, new +# instrument definition format, ... +# +# +# +# +# +# This is the flightpath before the sample position. This can be determined by a chopper, +# by the moderator or the source itself. In other words: it the distance to the component +# which gives the T0 signal to the detector electronics. If another component in the +# NXinstrument hierarchy provides this information, this should be a link. +# +# +# +# +# Notes describing entry +# +# +# +# +# A small image that is representative of the entry. An example of this is a 640x480 +# jpeg image automatically produced by a low resolution plot of the NXdata. +# +# +# +# The value should be an ``image/*`` +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# # -# diff --git a/base_classes/nyaml/NXtranslation.yaml b/base_classes/nyaml/NXtranslation.yaml index 99b08fc4fe..5909933d8b 100644 --- a/base_classes/nyaml/NXtranslation.yaml +++ b/base_classes/nyaml/NXtranslation.yaml @@ -33,13 +33,13 @@ NXtranslation(NXobject): for a summary of the discussion. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 3d64610ba1f1776cf277b5aca7e63bf3e504ed9a3f558bf28241565df29d6cc1 +# d90dcde19694778081106952e2d818986eeebc38b04d20b30081ac83cc22f05c # # # +# +# +# Quantified aberration coefficient in an aberration_model. +# +# +# +# Value of the aberration coefficient. +# +# +# +# +# Uncertainty of the value of the aberration coefficient +# according to uncertainty_model. +# +# +# +# +# How was the uncertainty quantified e.g. via the 95% confidence interval +# and using which algorithm or statistical model. +# +# +# +# +# Time elapsed since the last measurement. +# +# +# +# +# For the CEOS definitions the C aberrations are radial-symmetric and have +# no angle entry, while the A, B, D, S, or R aberrations are n-fold +# symmetric and have an angle entry. +# For the NION definitions the coordinate system differs to the one +# used in CEOS and instead two aberration coefficients a and b are used. +# +# +# +# +# Given name to this aberration. +# +# +# +# +# Alias also used to name and refer to this specific type of aberration. +# +# +# diff --git a/contributed_definitions/nyaml/NXactivity.yaml b/contributed_definitions/nyaml/NXactivity.yaml index 0c440d9562..6888050810 100644 --- a/contributed_definitions/nyaml/NXactivity.yaml +++ b/contributed_definitions/nyaml/NXactivity.yaml @@ -25,13 +25,13 @@ NXactivity(NXobject): case these are not available, free-text description. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 95b47c73f55c34a19e14162abf2d4cc56bcd3002210e9929947cdd588076202e +# 2ef302056190c2ac2b4a517bce57ee7727783d1bfb1bb3308c07fda870f51810 # # # +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of pulses collected in between start_time and end_time resolved by an +# instance of :ref:`NXevent_data_apm`. If this is not defined, p is the number of +# ions included in the reconstructed volume if the application definition is used +# to store results of an already reconstructed datasets. +# +# +# +# +# Number of ions spatially filtered from results of the hit_finding algorithm +# from which an instance of a reconstructed volume has been generated. +# These ions get new identifier assigned in the process (the so-called +# evaporation_identifier). This identifier must not be confused with +# the pulse_identifier. +# +# +# +# +# Application definition for atom probe and field ion microscopy experiments. +# +# +# +# +# +# +# +# +# +# +# The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_ or its plugins) +# which was used to generate this NeXus file instance. +# +# +# +# +# A collection of all programs and libraries which are considered relevant +# to understand with which software tools this NeXus file instance was +# generated. Ideally, to enable a binary recreation from the input data. +# +# Examples include the name and version of the libraries used to write the +# instance. Ideally, the software which writes these NXprogram instances +# also includes the version of the set of NeXus classes i.e. the specific +# set of base classes, application definitions, and contributed definitions +# with which the here described concepts can be resolved. +# +# For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ +# which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ +# research data management system, it makes sense to store e.g. the GitHub +# repository commit and respective submodule references used. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The identifier whereby the experiment is referred to in the control software. +# This is neither the specimen_name nor the experiment_identifier. For +# Local Electrode Atom Probe (LEAP) instruments, it is recommended to use the +# run_number from the proprietary software IVAS/APSuite of AMETEK/Cameca. +# For other instruments, such as the one from Stuttgart or Oxcart from Erlangen, +# or the instruments at GPM in Rouen, use the identifier which matches +# best conceptually to the LEAP run number. +# The field does not have to be required if the information is recoverable +# in the dataset which for LEAP instruments is the case (provided these +# RHIT or HITS files respectively are stored alongside a data artifact). +# With NXapm the RHIT or HITS can be stored as via the NXserialized group +# in the hit_finding algorithm section. +# +# As a destructive microscopy technique, a run can be performed only once. +# It is possible, however, to interrupt a run and restart data acquisition +# while still using the same specimen. In this case, each evaporation run +# needs to be distinguished with different run numbers. +# We follow this habit of most atom probe groups. Such interrupted runs +# should be stored as individual :ref:`NXentry` instances in one NeXus file. +# +# +# +# +# Either an identifier or an alias that is human-friendly so that scientists find that experiment again. +# For experiments usually this is the run_number but for simulation typically no run_numbers are issued. +# +# +# +# +# Free-text description about the experiment. +# +# Users are strongly advised to parameterize the description of their experiment +# by using respective groups and fields and base classes instead of writing prose +# into this field. +# +# The reason is that such free-text field is difficult to machine-interpret. +# The motivation behind keeping this field for now is to learn in how far the +# current base classes need extension based on user feedback. +# +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC information +# included when the atom probe session started. If the exact duration of +# the measurement is not relevant start_time only should be used. +# +# Often though it is useful to specify both start_time and end_time to +# capture more detailed bookkeeping of the experiment. The user should +# be aware that even with having both dates specified, it may not be +# possible to infer how long the experiment took or for how long data +# were collected. +# +# More detailed timing data over the course of the experiment have to be +# collected to compute this event chain during the experiment. For this +# purpose the :ref:`NXevent_data_apm` instance should be used. +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC included +# when the atom probe session ended. +# +# +# +# +# +# +# +# +# +# +# +# +# +# What type of atom probe experiment is performed? This field is meant to +# inform research data management systems to allow filtering: +# +# * apt are experiments where the analysis_chamber has no imaging gas. +# experiment with LEAP instruments are typically performed such. +# * fim are experiments where the analysis_chamber has an imaging gas, +# which should be specified with the atmosphere in the analysis_chamber group. +# * apt_fim should be used for combinations of the two imaging modes. +# few experiments of this type have been performed as this can be detrimental +# to LEAP systems (see `S. Katnagallu et al. <https://doi.org/10.1017/S1431927621012381>`_). +# * other should be used in combination with the user specifying details +# in the experiment_documentation field. +# +# If NXapm is used for storing details about a simulation use other for now. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Description of the sample from which the specimen was prepared or +# site-specifically cut out using e.g. a focused-ion beam instrument. +# +# The sample group is currently a place for storing suggestions from +# atom probers about knowledge they have gained about the sample. +# There are cases where the specimen is machined further or exposed to +# external stimuli during the experiment. In this case, these details should +# not be stored under sample but suggestions should be made +# how this application definition can be improved. +# +# In the future also details like how the grain_diameter was characterized, +# how the sample was prepared, how the material was heat-treated etc., +# should be stored. For this specific application definitions/schemas can be +# used which are then arranged and documented with a description of the +# workflow so that actionable graphs become instantiatable. +# +# +# +# A qualifier whether the sample is a real one +# or a virtual one (in a computer simulation). +# +# +# +# +# +# +# +# +# Given name/alias for the sample. +# +# +# +# +# +# +# +# +# +# Qualitative information about the grain size, here specifically +# described as the equivalent spherical diameter of an assumed +# average grain size for the crystal ensemble. +# Users of this information should be aware that although the grain +# diameter or radius is often referred to as grain size. +# +# In atom probe it is possible that the specimen may contain a few +# crystals only. In this case the grain_diameter is not a reliable +# descriptor. Reporting a grain size may be useful though as it allows +# judging if specific features are expected to be found in the +# detector hit map. +# +# +# +# +# Magnitude of the standard deviation of the grain_diameter. +# +# +# +# +# +# The temperature of the last heat treatment step before quenching. +# Knowledge about this value can give an idea how the sample +# was heat treated. However, if a documentation of the annealing +# treatment as a function of time is available one should better +# rely on this information and have it stored alongside the NeXus file. +# +# +# +# +# Magnitude of the standard deviation of the heat_treatment_temperature. +# +# +# +# +# Rate of the last quenching step. Knowledge about this value can give +# an idea how the sample was heat treated. However, there are many +# situations where one can imagine that the scalar value for just the +# quenching rate is insufficient. +# +# An example is when the sample was left in the furnace after the +# furnace was switched off. In this case the sample cools down with +# a specific rate of how this furnace cools down in the lab. +# Processes which in practice are often not documented. +# +# This can be problematic though because when the furnace door was left open +# or the ambient temperature in the lab changed, i.e. for a series of +# experiments where one is conducted on a hot summer day and the next +# during winter this can have an effect on the evolution of the microstructure. +# There are many cases where this has been reported to be an QA issue in industry, +# e.g. think about aging aluminium samples left on the factory +# parking lot on a hot summer day. +# +# +# +# +# Magnitude of the standard deviation of the heat_treatment_quenching_rate. +# +# +# +# +# +# The chemical composition of the sample. Typically, it is assumed that +# this more macroscopic composition is representative for the material +# so that the composition of the typically substantially less voluminous +# specimen probes from the more voluminous sample. +# +# +# +# Reporting compositions as atom and weight percent yields both +# dimensionless quantities but their conceptual interpretation differs. +# A normalization based on atom_percent counts relative to the +# total number of atoms which are of a particular type. +# By contrast, weight_percent normalization factorizes in the +# respective mass of the elements. Python libraries like pint are +# challenged by these differences as at.-% and wt.-% are both +# fractional quantities. +# +# +# +# +# +# +# +# +# +# Human-readable name of the element (e.g. Fe). +# Name has to be a symbol of an element from the periodic table. +# All symbols in the set of NXion instances inside the group +# chemical_composition need to be disjoint. +# +# +# +# +# Composition value for the element/ion referred to under name. +# The value is normalized based on normalization, i.e. composition +# is either an atom or weight percent quantity. +# +# +# +# +# Magnitude of the standard deviation of the composition (value). +# +# +# +# +# +# +# +# +# A qualifier whether the specimen is a real one or a virtual one. +# +# +# +# +# +# +# +# +# Given name an alias. Better use identifier and parent_identifier instead. +# A single NXentry should be used only for the characterization of a single specimen. +# +# +# +# +# +# +# +# +# +# Identifier of the sample from which the specimen was cut or the string +# n/a. The purpose of this field is to support functionalities for +# tracking sample provenance via a research data management system. +# +# +# +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC information +# when the specimen was prepared. +# +# Ideally, report the end of the preparation, i.e. the last known time +# the measured specimen surface was actively prepared. Ideally, this +# matches the last timestamp that is mentioned in the digital resource +# pointed to by parent_identifier. +# +# Knowing when the specimen was exposed to e.g. specific atmosphere is +# especially required for environmentally sensitive material such as +# hydrogen charged specimens or experiments including tracers with a +# short half time. Additional time stamps prior to preparation_date +# should better be placed in resources which describe but which do not +# pollute the description here with prose. Resolving these connected +# pieces of information is considered within the responsibility of the +# research data management system. +# +# +# +# +# List of comma-separated elements from the periodic table that are +# contained in the specimen. If the specimen substance has multiple +# components, all elements from each component must be included in +# `atom_types`. +# +# The purpose of the field is to offer research data management systems an +# opportunity to parse the relevant elements without having to interpret +# these from the resources pointed to by parent_identifier or walk through +# eventually deeply nested groups in data instances. +# +# +# +# +# Discouraged free-text field. +# +# +# +# +# Report if the specimen is polycrystalline, in which case it +# contains a grain or phase boundary, or if the specimen is a +# single crystal. +# +# +# +# +# Report if the specimen is amorphous. +# +# +# +# +# Ideally measured otherwise best elaborated guess of the initial radius of the +# specimen. +# +# +# +# +# Ideally measured otherwise best elaborated guess of the (initial) shank angle. +# This is a measure of the specimen taper. Define it in such a way that the base of the specimen +# is modelled as a conical frustrum so that the shank angle is the (shortest) angle between +# the specimen space z-axis and a vector on the lateral surface of the cone. +# +# +# +# +# +# +# Set to hold different coordinate systems conventions. +# Inspect the description of the :ref:`NXcoordinate_system_set` +# and :ref:`NXcoordinate_system` base classes how to define +# coordinate systems in NeXus. Specific details for application +# in atom probe microscopy follow. +# +# In this research field scientists usually distinguish several +# Euclidean coordinate systems (CS): +# +# * World space; +# a CS specifying a local coordinate system of the planet earth which +# identifies into which direction gravity is pointing such that +# the laboratory space CS can be rotated into this world CS. +# * The laboratory space; +# a CS specifying the room where the instrument is located in or +# a physical landmark on the instrument, e.g. the direction of the +# transfer rod where positive is the direction how the rod +# has to be pushed during loading a specimen into the instrument. +# In summary, this CS is defined by the chassis of the instrument. +# * The specimen space; +# a CS affixed to either the base or the initial apex of the specimen, +# whose z axis points towards the detector. +# * The detector space; +# a CS affixed to the detector plane whose xy plane is usually in the +# detector and whose z axis points towards the specimen. +# This is a distorted space with respect to the reconstructed ion +# positions. +# * The reconstruction space; +# a CS in which the reconstructed ion positions are defined. +# The orientation depends on the analysis software used. +# * Eventually further coordinate systems attached to the +# flight path of individual ions might be defined. +# +# In atom probe microscopy a frequently used choice for the detector +# space (CS) is discussed with the so-called detector space image +# (stack). This is a stack of two-dimensional histograms of detected ions +# within a predefined evaporation identifier interval. Typically, the set of +# ion evaporation sequence IDs is grouped into chunks. +# +# For each chunk a histogram of the ion hit positions on the detector +# is computed. This leaves the possibility for inconsistency between +# the so-called detector space and the e.g. specimen space. +# +# To avoid these ambiguities, instances of :ref:`NXtransformations` should +# be used. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The wavelength of the radiation emitted by the source. +# +# +# +# +# +# +# +# +# The space inside the atom probe along which ions pass nominally +# when they leave the specimen and travel to the detector. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# A region-of-interest analyzed either during or after the session for which +# specific processed data of the measured or simulated data are available. +# +# +# +# +# +# SEM or TEM image of the initial specimen i.e. +# ideally taken prior to the data acquisition. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Integer used to name the first pulse to know if there is an +# offset of the evaporation_identifier to zero. +# +# Identifiers can be defined either implicitly or explicitly. +# For implicit indexing identifiers are defined on the interval +# :math:`[identifier\_offset, identifier\_offset + c - 1]`. +# +# Therefore, implicit identifier are completely defined by the value of +# identifier_offset and cardinality. For example if identifier run from +# -2 to 3 the value for identifier_offset is -2. +# +# For explicit indexing the field identifier has to be used. +# Fortran-/Matlab- and C-/Python-style indexing have specific implicit +# identifier conventions where identifier_offset is 1 and 0 respectively. +# +# +# +# +# (Molecular) ion identifier which resolves the sequence in which +# the ions were evaporated but taking into account that a hit_finding +# and spatial_filtering was applied. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# For LEAP and IVAS/APSuite-based analyses root file which stores +# the settings whereby an RHIT/HITS file can be used to regenerate the +# reconstruction that is here referred to. +# +# The respective RHIT/HITS file should ideally be specified in the serialized +# group of the hit_finding section of this application definition. +# +# +# +# +# +# +# +# +# For LEAP and IVAS/APSuite-based analyses the resulting typically +# file with the reconstructed positions and (calibrated) mass-to-charge +# state ratio values. +# +# For other data collection/analysis software the data artifact which comes +# closest conceptually to AMETEK/Cameca's typical file formats. +# +# These are typically exported as a POS, ePOS, APT, ATO, ENV, or HDF5 file, +# which should be stored alongside this record in the research data +# management system. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The respective ranging definitions file RNG/RRNG/ENV/HDF5. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# (Out-of-sync) background levels in ppm/ns +# reported by e.g. IVAS/APSuite for LEAP systems. +# +# +# +# +# MRP, mass-resolving power, `D. Larson et al. +# <https://doi.org/10.1007/978-1-4614-8721-0>`_ (p282, Eqs. D.7 and D.8). +# +# +# +# +# MRP, at which mrp_value was specified. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Category for the peak offering a qualitative statement of the location of the peak +# in light of limited mass-resolving power that is relevant for +# composition quantification. See `D. Larson et al. (p172) <https://doi.org/10.1007/978-1-4614-8721-0>`_ +# for examples of each category: +# +# * 0, well-separated, :math:`^{10}B^{+}`, :math:`^{28}Si^{2+}` +# * 1, close, but can be sufficiently separated for quantification in a LEAP system, :math:`^{94}Mo^{3+}`, :math:`^{63}Cu^{2+}` +# * 2, closely overlapping, demands better than LEAP4000X MRP can provide :math:`^{14}N^{+}`, :math:`^{28}Si^{2+}` at different charge states +# * 3, overlapped exactly due to multi-charge molecular species, :math:`^{16}{O_{2}}^{2+}`, :math:`^{16}O^{+}` +# * 4, overlapped, same charge state, cannot as of 2013 be discriminated with a LEAP4000X, :math:`^{14}{N_{2}}^{+}`, :math:`^{28}Si^{+}` +# * 5, overlapped, same charge state, any expectation of resolvability, :math:`^{54}Cr^{2+}`, :math:`^{54}Fe^{2+}` +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml b/contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml index 35b3295598..c3b35b8fb6 100644 --- a/contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml +++ b/contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml @@ -27,11 +27,13 @@ symbols: Number of entries type: group NXapm_charge_state_analysis(NXprocess): + # Details and results of the combinatorial analyses of a ranging definition # to clarify (if possible) the charge_state of an ion and its (not necessarily) # unique combination of nuclides contained including their multiplicity. # input/config nuclides(NX_UINT): + unit: NX_UNITLESS doc: | Input constraint, list of nuclide_hash for typically elements used for the ranging definition of the ion whose charge state the analyses covered. @@ -46,62 +48,248 @@ NXapm_charge_state_analysis(NXprocess): Keep in mind that with a weakly constrained parameter space the combinatorial analysis may become very time consuming! - unit: NX_UNITLESS - dim: (n_variable,) + dimensions: + rank: 1 + dim: [[1, n_variable]] mass_to_charge_range(NX_FLOAT): + unit: NX_ANY doc: | Input constraint, interval within which (molecular) ions need to have the mass-to-charge-state-ratio such that an ion qualifies as a candidate. - unit: NX_ANY # u - dim: (1, 2) + dimensions: + rank: 2 + dim: [[1, 1], [2, 2]] min_half_life(NX_FLOAT): + unit: NX_TIME doc: | Input constraint, minimum half life for how long each nuclide of each (molecular) ion needs to be stable such that the ion qualifies as a candidate. - unit: NX_TIME min_abundance(NX_FLOAT): + unit: NX_DIMENSIONLESS doc: | Input constraint, minimum natural abundance of each nuclide of each (molecular) ion such that the ion qualifies as a candidate. - unit: NX_DIMENSIONLESS sacrifice_isotopic_uniqueness(NX_BOOLEAN): doc: | If the value is false, it means that non-unique solutions are accepted. These are solutions where multiple candidates have been built from different nuclide instances but the charge_state of all the ions is the same. + # min_abundance_product(NX_FLOAT): - # doc: | - # For each candidate TO BE DEFINED. - # unit: NX_DIMENSIONLESS - # dim: (n_cand,) - + # doc: | + # For each candidate TO BE DEFINED. + # unit: NX_DIMENSIONLESS + # dim: (n_cand,) + # output/results # the n_cand can be 1 in which case all quantities below are scalar charge_state(NX_INT): + unit: NX_UNITLESS doc: | Signed charge, i.e. integer multiple of the elementary charge of each candidate. - unit: NX_UNITLESS - dim: (n_cand,) + dimensions: + rank: 1 + dim: [[1, n_cand]] nuclide_hash(NX_UINT): + unit: NX_UNITLESS doc: | Table of nuclide instances of which each candidate is composed. Each row vector is sorted in descending order. Unused values are nullified. - unit: NX_UNITLESS - dim: (n_cand, n_ivec_max) + dimensions: + rank: 2 + dim: [[1, n_cand], [2, n_ivec_max]] mass(NX_FLOAT): + unit: NX_MASS doc: | Accumulated mass of the nuclides in each candidate. Not corrected for quantum effects. - unit: NX_MASS - dim: (n_cand,) + dimensions: + rank: 1 + dim: [[1, n_cand]] natural_abundance_product(NX_FLOAT): + unit: NX_DIMENSIONLESS doc: | The product of the natural abundances of the nuclides for each candidate. - unit: NX_DIMENSIONLESS - dim: (n_cand,) + dimensions: + rank: 1 + dim: [[1, n_cand]] shortest_half_life(NX_FLOAT): - doc: | - For each candidate the half life of that nuclide which has the shortest half life. unit: NX_TIME - dim: (n_cand,) + doc: | + For each candidate the half life of that nuclide which has the shortest half + life. + dimensions: + rank: 1 + dim: [[1, n_cand]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# a9ee8cc28f0b65fd86f57409a9c945b6790c9fd714cb38441ad7c595a261f1ef +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The number of also possible but different (molecular) ions. +# +# +# +# +# Maximum number of allowed atoms per (molecular) ion (fragment). +# +# +# +# +# Number of entries +# +# +# +# +# Base class to document an algorithm for recovering charge state and nuclide composition of a (molecular) ion. +# +# Currently ranging definitions in the research field of atom probe face have limitations: +# +# 1. A ranging definition maps all signal within a mass-to-charge-state-ratio value interval +# on one iontype. Facing limited mass-resolving-power, there are mass-to-charge-state-ratio +# values, though, for which not only multiple (molecular) ions are indistinguishable but +# also for which the current practice of documenting classical ranging definitions is incomplete. +# 2. Indeed, ranging definitions often report only (for each interval) the +# mass-to-charge-state-ratio intervals surplus the composition of elements +# that build the (molecular) ion. +# 3. Therefore, classical ranging definitions demand a post-processing with an algorithm +# which can identify nuclides from which the (molecular) ion is constructed +# and a charge state possibly recovered. Combinatorial algorithms are used for this purpose. +# +# This base class documents the configuration and results of such an algorithm. +# +# +# +# +# Input constraint, list of nuclide_hash for typically elements used for the +# ranging definition of the ion whose charge state the analyses covered. +# The list contains each hash as many times as its multiplicity. +# Nuclides are encoded using the hashing rule that is defined in :ref:`NXion`. +# +# As an example, a ranging definition H:2 O:1 is configured by setting nuclides to +# a list with entries :math:`1 + 0 \cdot 256`, :math:`1 + 0 \cdot 256`, :math:`8 + 0 \cdot 256`. +# An empty list does not release the constraint. Instead, a list with all elements +# in the periodic table (encoded as nuclide_hash values) should be used, i.e. +# :math:`1 + 0 \cdot 256`, :math:`2 + 0 \cdot 256`, and so on and so forth. +# +# Keep in mind that with a weakly constrained parameter space the combinatorial +# analysis may become very time consuming! +# +# +# +# +# +# +# +# Input constraint, interval within which (molecular) ions need to have the +# mass-to-charge-state-ratio such that an ion qualifies as a candidate. +# +# +# +# +# +# +# +# +# Input constraint, minimum half life for how long each nuclide of each +# (molecular) ion needs to be stable such that the ion qualifies as a candidate. +# +# +# +# +# Input constraint, minimum natural abundance of each nuclide of each +# (molecular) ion such that the ion qualifies as a candidate. +# +# +# +# +# If the value is false, it means that non-unique solutions are accepted. +# These are solutions where multiple candidates have been built from +# different nuclide instances but the charge_state of all the ions is the same. +# +# +# +# +# +# +# Signed charge, i.e. integer multiple of the elementary +# charge of each candidate. +# +# +# +# +# +# +# +# Table of nuclide instances of which each candidate is composed. +# Each row vector is sorted in descending order. Unused values are nullified. +# +# +# +# +# +# +# +# +# Accumulated mass of the nuclides in each candidate. +# Not corrected for quantum effects. +# +# +# +# +# +# +# +# The product of the natural abundances of the nuclides for each candidate. +# +# +# +# +# +# +# +# For each candidate the half life of that nuclide which has the shortest half +# life. +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml b/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml index 843c1803fe..a9a23d5124 100644 --- a/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml +++ b/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml @@ -9,12 +9,14 @@ doc: | CompositionSpace software using NeXus. type: group NXapm_compositionspace_config(NXobject): + # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently (NXentry): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] definition(NX_CHAR): - \@version(NX_CHAR): - exists: optional # because NXroot should already have the correct NeXus version used + \@version: + type: NX_CHAR + exists: optional enumeration: [NXapm_compositionspace_config] config(NXobject): (NXidentifier): @@ -60,16 +62,18 @@ NXapm_compositionspace_config(NXobject): exists: recommended ranging_definitions(NX_CHAR): doc: | - Name of the (parent) node directly below which the ranging definitions for (molecular) ions are stored. + Name of the (parent) node directly below which the ranging definitions for + (molecular) ions are stored. voxelization(NXprocess): doc: | Step during which the point cloud is discretized to compute element-specific composition fields. Iontypes are atomically decomposed to correctly account for the multiplicity of each element that was ranged for each ion. edge_length(NX_NUMBER): - doc: | - Edge length of cubic voxels building the 3D grid that is used for discretizing the point cloud. unit: NX_LENGTH + doc: | + Edge length of cubic voxels building the 3D grid that is used for discretizing + the point cloud. autophase(NXprocess): doc: | Optional step during which the subsequent segmentation step is prepared with the aim to eventually @@ -82,23 +86,24 @@ NXapm_compositionspace_config(NXobject): doc: | Was the automated phase assignment used? initial_guess(NX_POSINT): + unit: NX_UNITLESS doc: | Estimated guess for which a Gaussian mixture model is evaluted to preprocess a result that is subsequenty post-processed with a random_forest_classifier to lower the number of dimensions in the chemical space to the subset of trunc_species many elements with the highest feature importance. - unit: NX_UNITLESS trunc_species(NX_POSINT): + unit: NX_UNITLESS doc: | The number of elements to use for reducing the dimensionality. - unit: NX_UNITLESS random_forest_classifier(NXprocess): exists: optional doc: | Configuration for the random forest classification model. segmentation(NXprocess): doc: | - Step during which the voxel set is segmented into voxel sets with different chemical composition. + Step during which the voxel set is segmented into voxel sets with different + chemical composition. pca(NXprocess): exists: optional doc: | @@ -106,28 +111,227 @@ NXapm_compositionspace_config(NXobject): with different chemical composition the machine learning algorithm suggests to split the voxel set. ic_opt(NXprocess): doc: | - The decision is guided through the evalution of the information criterion minimization. + The decision is guided through the evalution of the information criterion + minimization. n_max_ic_cluster(NX_POSINT): + unit: NX_UNITLESS doc: | The maximum number of chemical classes to probe with the Gaussian mixture model with which the voxel set is segmented into a mixture of voxels with that many different chemical compositions. - unit: NX_UNITLESS gaussian_mixture(NXprocess): exists: optional doc: | - Configuration for the Gaussian mixture model that is used in the segmentation step. + Configuration for the Gaussian mixture model that is used in the segmentation + step. clustering(NXprocess): doc: | - Step during which the chemically segmented voxel sets are analyzed for their spatial organization. + Step during which the chemically segmented voxel sets are analyzed for their + spatial organization. dbscan(NXobject): doc: | Configuration for the DBScan algorithm that is used in the clustering step. eps(NX_FLOAT): - doc: | - The maximum distance between voxel pairs in a neighborhood to be considered connected. unit: NX_LENGTH - min_samples(NX_UINT): doc: | - The number of voxels in a neighborhood for a voxel to be considered as a core point. + The maximum distance between voxel pairs in a neighborhood to be considered + connected. + min_samples(NX_UINT): unit: NX_UNITLESS + doc: | + The number of voxels in a neighborhood for a voxel to be considered as a core + point. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 97d13fe8c9822f8891a11748531ecb8c52896605f2a1a33a064d7e93e31b0407 +# +# +# +# +# +# Application definition for a configuration of the CompositionSpace tool used in atom probe. +# +# * `A. Saxena et al. <https://www.github.com/eisenforschung/CompositionSpace.git>`_ +# +# This is an application definition for the common NFDI-MatWerk/FAIRmat infrastructure +# use case IUC09 that explores how to improve the organization and results storage of the +# CompositionSpace software using NeXus. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Specification of the tomographic reconstruction used for this analysis. +# Typically, reconstructions in the field of atom probe tomography are communicated via +# files which store at least reconstructed ion positions and mass-to-charge-state-ratio +# values. Container files like HDF5 though can store multiple reconstructions. +# Therefore, the position and mass_to_charge concepts point to specific instances +# to use for this analysis. +# +# +# +# +# +# +# +# Name of the node which resolves the reconstructed +# ion position values to use for this analysis. +# +# +# +# +# Name of the node which resolves the mass-to-charge-state ratio +# values for each reconstructed ion to use for this analysis. +# +# +# +# +# +# Specification of the ranging definitions used for this analysis. +# +# Indices start from 1. The value 0 is reserved for the null model of unranged positions whose +# iontype is unknown_type. The value 0 is also reserved for voxels that lie outside the dataset. +# +# +# +# +# +# +# +# Name of the (parent) node directly below which the ranging definitions for +# (molecular) ions are stored. +# +# +# +# +# +# Step during which the point cloud is discretized to compute element-specific composition fields. +# Iontypes are atomically decomposed to correctly account for the multiplicity of each element that +# was ranged for each ion. +# +# +# +# Edge length of cubic voxels building the 3D grid that is used for discretizing +# the point cloud. +# +# +# +# +# +# Optional step during which the subsequent segmentation step is prepared with the aim to eventually +# reduce the dimensionality of the chemical space in which the machine learning model works. +# +# In this step a supervised reduction of the dimensionality of the chemical space is quantified using +# the (Gini) feature importance of each element to suggest which columns of the composition matrix +# should be taken for the subsequent segmentation step. +# +# +# +# Was the automated phase assignment used? +# +# +# +# +# Estimated guess for which a Gaussian mixture model is evaluted to preprocess a result that +# is subsequenty post-processed with a random_forest_classifier to lower the number of +# dimensions in the chemical space to the subset of trunc_species many elements with the +# highest feature importance. +# +# +# +# +# The number of elements to use for reducing the dimensionality. +# +# +# +# +# Configuration for the random forest classification model. +# +# +# +# +# +# Step during which the voxel set is segmented into voxel sets with different +# chemical composition. +# +# +# +# A principal component analysis of the chemical space to guide a decision into how many sets of voxels +# with different chemical composition the machine learning algorithm suggests to split the voxel set. +# +# +# +# +# The decision is guided through the evalution of the information criterion +# minimization. +# +# +# +# The maximum number of chemical classes to probe with the Gaussian mixture model +# with which the voxel set is segmented into a mixture of voxels with that many different +# chemical compositions. +# +# +# +# +# Configuration for the Gaussian mixture model that is used in the segmentation +# step. +# +# +# +# +# +# +# Step during which the chemically segmented voxel sets are analyzed for their +# spatial organization. +# +# +# +# Configuration for the DBScan algorithm that is used in the clustering step. +# +# +# +# The maximum distance between voxel pairs in a neighborhood to be considered +# connected. +# +# +# +# +# The number of voxels in a neighborhood for a voxel to be considered as a core +# point. +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml b/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml index 145fc6bfbf..ff0a9a823c 100644 --- a/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml +++ b/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml @@ -18,25 +18,31 @@ symbols: Total number of ions in the reconstructed dataset. type: group NXapm_compositionspace_results(NXobject): + # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently (NXentry): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] definition(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR exists: optional enumeration: [NXapm_compositionspace_results] + # can be used for the name of the tool and version but also # for if desired all the dependencies and libraries programID(NXprogram): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): - \@version(NX_CHAR): - \@url(NX_CHAR): + \@version: + type: NX_CHAR + \@url: + type: NX_CHAR exists: optional (NXidentifier): exists: optional analysis_identifier(NX_UINT): exists: recommended + # config config(NXserialized): doc: | @@ -48,11 +54,12 @@ NXapm_compositionspace_results(NXobject): exists: recommended checksum(NX_CHAR): exists: recommended + # results (NXuser): exists: optional voxelization(NXprocess): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] doc: | Step during which the point cloud is discretized to compute element-specific composition fields. Iontypes are atomically decomposed to correctly account for the multiplicity of each element that @@ -71,104 +78,141 @@ NXapm_compositionspace_results(NXobject): unit: NX_UNITLESS origin(NX_NUMBER): unit: NX_LENGTH - dim: (grid_dim,) + dimensions: + rank: 1 + dim: [[1, grid_dim]] symmetry: enumeration: [cubic] cell_dimensions(NX_NUMBER): unit: NX_LENGTH - dim: (grid_dim,) + dimensions: + rank: 1 + dim: [[1, grid_dim]] extent(NX_POSINT): unit: NX_UNITLESS - dim: (grid_dim,) + dimensions: + rank: 1 + dim: [[1, grid_dim]] identifier_offset(NX_INT): unit: NX_UNITLESS position(NX_NUMBER): + unit: NX_LENGTH doc: | Position of each cell in Euclidean space. - unit: NX_LENGTH - dim: (n_voxels, grid_dim) + dimensions: + rank: 2 + dim: [[1, n_voxels], [2, grid_dim]] coordinate(NX_INT): + unit: NX_DIMENSIONLESS doc: | Discrete coordinate of each voxel. - unit: NX_DIMENSIONLESS - dim: (n_voxels, grid_dim) + dimensions: + rank: 2 + dim: [[1, n_voxels], [2, grid_dim]] + # bounding box if needed voxel_identifier(NX_UINT): + unit: NX_UNITLESS doc: | For each ion, the identifier of the voxel into which the ion binned. - unit: NX_UNITLESS - dim: (n_ions) + dimensions: + rank: 1 + dim: [[1, n_ions]] weight(NX_NUMBER): + unit: NX_UNITLESS doc: | Total number of weight (counts for discretization with a rectangular transfer function) for the occupancy of each voxel with atoms. - unit: NX_UNITLESS - dim: (n_voxels,) + dimensions: + rank: 1 + dim: [[1, n_voxels]] elementID(NXion): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] name(NX_CHAR): doc: | Chemical symbol of the element from the periodic table. weight(NX_NUMBER): + unit: NX_UNITLESS doc: | Element-specific weight (counts for discretization with a rectangular transfer function) for the occupancy of each voxel with atoms of this element. - unit: NX_UNITLESS - dim: (n_voxels,) + dimensions: + rank: 1 + dim: [[1, n_voxels]] autophase(NXprocess): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] doc: | - Optional step during which the subsequent segmentation step is prepared to improve the segmentation. + Optional step during which the subsequent segmentation step is prepared to + improve the segmentation. sequence_index(NX_POSINT): enumeration: [2] result(NXdata): - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_CHAR): + \@signal: + type: NX_CHAR + \@axes: + type: NX_CHAR + \@AXISNAME_indices: + type: NX_CHAR title(NX_CHAR): exists: recommended axis_feature_identifier(NX_UINT): + unit: NX_DIMENSIONLESS doc: | Element identifier stored sorted in descending order of feature importance. - unit: NX_DIMENSIONLESS - dim: (i,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, i]] + \@long_name: + type: NX_CHAR doc: | Axis caption axis_feature_importance(NX_FLOAT): - doc: | - Element relative feature importance stored sorted in descending order of feature importance. unit: NX_DIMENSIONLESS - dim: (i,) - \@long_name(NX_CHAR): + doc: | + Element relative feature importance stored sorted in descending order of feature + importance. + dimensions: + rank: 1 + dim: [[1, i]] + \@long_name: + type: NX_CHAR doc: | Axis caption segmentation(NXprocess): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] doc: | - Step during which the voxel set is segmented into voxel sets with different chemical composition. + Step during which the voxel set is segmented into voxel sets with different + chemical composition. pca(NXprocess): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] doc: | PCA in the chemical space (essentially composition correlation analyses). sequence_index(NX_POSINT): enumeration: [2, 3] result(NXdata): - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_CHAR): + \@signal: + type: NX_CHAR + \@axes: + type: NX_CHAR + \@AXISNAME_indices: + type: NX_CHAR title(NX_CHAR): exists: recommended axis_explained_variance(NX_FLOAT): + unit: NX_DIMENSIONLESS doc: | Explained variance values - unit: NX_DIMENSIONLESS - dim: (i,) + dimensions: + rank: 1 + dim: [[1, i]] axis_pca_dimension(NX_UINT): - doc: | - Elements identifier matching those from ENTRY/voxelization/elementID as the principal component analysis. unit: NX_UNITLESS - dim: (i,) + doc: | + Elements identifier matching those from ENTRY/voxelization/elementID as the + principal component analysis. + dimensions: + rank: 1 + dim: [[1, i]] ic_opt(NXprocess): doc: | Information criterion minimization. @@ -178,40 +222,51 @@ NXapm_compositionspace_results(NXobject): doc: | Results of the Gaussian mixture analysis for n_components equal to n_ic_cluster. n_ic_cluster(NX_UINT): + unit: NX_UNITLESS doc: | n_components argument of the Gaussian mixture model. - unit: NX_UNITLESS y_pred(NX_UINT): + unit: NX_UNITLESS doc: | y_pred return values of the computation. - unit: NX_UNITLESS - dim: (n_voxels,) + dimensions: + rank: 1 + dim: [[1, n_voxels]] result(NXdata): doc: | Information criterion as a function of number of n_ic_cluster aka dimensions. - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_CHAR): + \@signal: + type: NX_CHAR + \@axes: + type: NX_CHAR + \@AXISNAME_indices: + type: NX_CHAR title(NX_CHAR): exists: recommended axis_aic(NX_FLOAT): exists: recommended + unit: NX_ANY doc: | Akaike information criterion values - unit: NX_ANY - dim: (i,) + dimensions: + rank: 1 + dim: [[1, i]] axis_bic(NX_FLOAT): + unit: NX_UNITLESS doc: | Bayes information criterion values - unit: NX_UNITLESS - dim: (i,) + dimensions: + rank: 1 + dim: [[1, i]] axis_dimension(NX_UINT): + unit: NX_UNITLESS doc: | Actual n_ic_cluster values used - unit: NX_UNITLESS - dim: (i,) + dimensions: + rank: 1 + dim: [[1, i]] clustering(NXprocess): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] doc: | Step during which the chemically segmented voxel sets are analyzed for their spatial organization into different spatial clusters of voxels in the same chemical set but representing individual object @@ -222,30 +277,36 @@ NXapm_compositionspace_results(NXobject): doc: | Respective DBScan clustering result for each segmentation/ic_opt case. cluster_analysisID(NXprocess): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] dbscanID(NXprocess): - exists: [min, 1, max, infty] # max as many as n_ic_cluster + exists: ['min', '1', 'max', 'unbounded'] epsilon(NX_FLOAT): - doc: | - The maximum distance between voxel pairs in a neighborhood to be considered connected. unit: NX_LENGTH - min_samples(NX_UINT): doc: | - The number of voxels in a neighborhood for a voxel to be considered as a core point. + The maximum distance between voxel pairs in a neighborhood to be considered + connected. + min_samples(NX_UINT): unit: NX_UNITLESS + doc: | + The number of voxels in a neighborhood for a voxel to be considered as a core + point. label(NX_INT): + unit: NX_UNITLESS doc: | Raw label return values - unit: NX_UNITLESS - dim: (k,) + dimensions: + rank: 1 + dim: [[1, k]] voxel(NX_UINT): + unit: NX_UNITLESS doc: | Voxel identifier Using these identifiers correlated element-wise with the values in the label array specifies for which voxel in the grid clusters from this process were found. - unit: NX_UNITLESS - dim: (n_voxels,) + dimensions: + rank: 1 + dim: [[1, n_voxels]] profiling(NXcs_profiling): exists: optional current_working_directory(NX_CHAR): @@ -255,6 +316,400 @@ NXapm_compositionspace_results(NXobject): end_time(NX_DATE_TIME): exists: recommended total_elapsed_time(NX_NUMBER): - # number_of_processes(NX_POSINT): - # number_of_threads(NX_POSINT): - # number_of_gpus(NX_POSINT): + + # number_of_processes(NX_POSINT): + # number_of_threads(NX_POSINT): + # number_of_gpus(NX_POSINT): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# cf31932949a3d5b216551f8f62516c4522531ff17e818ec62daf3257d6badcac +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality of the grid. +# +# +# +# +# Total number of voxels. +# +# +# +# +# Total number of ions in the reconstructed dataset. +# +# +# +# +# Application definition for results of the CompositionSpace tool used in atom probe. +# +# * `A. Saxena et al. <https://www.github.com/eisenforschung/CompositionSpace.git>`_ +# +# This is an application definition for the common NFDI-MatWerk/FAIRmat infrastructure +# use case IUC09 that explores how to improve the organization and results storage of the +# CompositionSpace software using NeXus. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Configuration file that was used in this analysis. +# +# +# +# +# +# +# +# +# +# +# Step during which the point cloud is discretized to compute element-specific composition fields. +# Iontypes are atomically decomposed to correctly account for the multiplicity of each element that +# was ranged for each ion. +# +# Using a discretization grid that is larger than the average distance between reconstructed ion positions +# reduces computational costs. This is the key idea of the CompositionSpace tool compared to other methods +# used in atom probe for characterizing microstructural features using the ion position data directly. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Position of each cell in Euclidean space. +# +# +# +# +# +# +# +# +# Discrete coordinate of each voxel. +# +# +# +# +# +# +# +# +# +# For each ion, the identifier of the voxel into which the ion binned. +# +# +# +# +# +# +# +# +# Total number of weight (counts for discretization with a rectangular transfer function) +# for the occupancy of each voxel with atoms. +# +# +# +# +# +# +# +# +# Chemical symbol of the element from the periodic table. +# +# +# +# +# Element-specific weight (counts for discretization with a rectangular transfer function) +# for the occupancy of each voxel with atoms of this element. +# +# +# +# +# +# +# +# +# +# Optional step during which the subsequent segmentation step is prepared to +# improve the segmentation. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Element identifier stored sorted in descending order of feature importance. +# +# +# +# +# +# +# Axis caption +# +# +# +# +# +# Element relative feature importance stored sorted in descending order of feature +# importance. +# +# +# +# +# +# +# Axis caption +# +# +# +# +# +# +# +# Step during which the voxel set is segmented into voxel sets with different +# chemical composition. +# +# +# +# PCA in the chemical space (essentially composition correlation analyses). +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Explained variance values +# +# +# +# +# +# +# +# Elements identifier matching those from ENTRY/voxelization/elementID as the +# principal component analysis. +# +# +# +# +# +# +# +# +# +# Information criterion minimization. +# +# +# +# +# +# +# +# +# +# Results of the Gaussian mixture analysis for n_components equal to n_ic_cluster. +# +# +# +# n_components argument of the Gaussian mixture model. +# +# +# +# +# y_pred return values of the computation. +# +# +# +# +# +# +# +# +# Information criterion as a function of number of n_ic_cluster aka dimensions. +# +# +# +# +# +# +# +# Akaike information criterion values +# +# +# +# +# +# +# +# Bayes information criterion values +# +# +# +# +# +# +# +# Actual n_ic_cluster values used +# +# +# +# +# +# +# +# +# +# +# Step during which the chemically segmented voxel sets are analyzed for their spatial organization +# into different spatial clusters of voxels in the same chemical set but representing individual object +# not-necessarily watertight or topologically closed objects built from individual voxels. +# +# +# +# +# +# +# +# +# +# Respective DBScan clustering result for each segmentation/ic_opt case. +# +# +# +# +# +# The maximum distance between voxel pairs in a neighborhood to be considered +# connected. +# +# +# +# +# The number of voxels in a neighborhood for a voxel to be considered as a core +# point. +# +# +# +# +# Raw label return values +# +# +# +# +# +# +# +# Voxel identifier +# +# Using these identifiers correlated element-wise with the values in the label array +# specifies for which voxel in the grid clusters from this process were found. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_hit_finding.yaml b/contributed_definitions/nyaml/NXapm_hit_finding.yaml index d71e671939..7337efa8ae 100644 --- a/contributed_definitions/nyaml/NXapm_hit_finding.yaml +++ b/contributed_definitions/nyaml/NXapm_hit_finding.yaml @@ -14,34 +14,43 @@ symbols: p is the number of ions included in the reconstructed volume if an application definition is used to store results of already reconstructed datasets. type: group -NXapm_hit_finding(NXprocess): # when evolving these ideas further inherit from NXapm_method instead +NXapm_hit_finding(NXprocess): (NXprogram): (NXserialized): + # config/input number_of_dld_wires(NX_UINT): + unit: NX_UNITLESS doc: | The number of wires in the detector. - unit: NX_UNITLESS enumeration: [1, 2, 3] dld_wire_names(NX_CHAR): doc: | Alias tuple (begin, end) of each DLD wire of the detector. Order follows arrival_time_pairs. - dim: (n_dld, 2) + dimensions: + rank: 2 + dim: [[1, n_dld], [2, 2]] arrival_time_pairs(NX_NUMBER): + unit: NX_TIME doc: | Raw readings from the analog-to-digital-converter timing circuits of the detector wires. - unit: NX_TIME - dim: (p, n_dld, 2) + dimensions: + rank: 3 + dim: [[1, p], [2, n_dld], [3, 2]] + # results of the hit_finding algorithm hit_positions(NX_NUMBER): + unit: NX_LENGTH doc: | Evaluated ion impact coordinates on the detector. Use the depends_on field to spec - unit: NX_LENGTH - dim: (p, 2) - \@depends_on(NX_CHAR): + dimensions: + rank: 2 + dim: [[1, p], [2, 2]] + \@depends_on: + type: NX_CHAR doc: | Defines in which reference frame the positions are defined. hit_quality_types(NX_CHAR): @@ -49,18 +58,23 @@ NXapm_hit_finding(NXprocess): # when evolving these ideas further inherit from Name of the hit_qualities distinguished. AMETEK/Cameca uses e.g. golden, multiple, partial, irrecoverable, and multi-first and multi-late. - dim: (n_ht,) + dimensions: + rank: 1 + dim: [[1, n_ht]] hit_quality_identifier(NX_UINT): doc: | Identifier used for each hit_quality type. Following the order of hit_quality_types. hit_quality(NX_UINT): + unit: NX_UNITLESS doc: | Hit quality identifier for each pulse. Identifier have to be within hit_quality_identifier. - unit: NX_UNITLESS - dim: (p,) + dimensions: + rank: 1 + dim: [[1, p]] hit_multiplicity(NX_UINT): + unit: NX_UNITLESS doc: | This processing yields for each ion with how many others it evaporated if these were collected on the same pulse. Extraction of multiple ions @@ -69,12 +83,164 @@ NXapm_hit_finding(NXprocess): # when evolving these ideas further inherit from Multiplicity must not be confused with how many atoms of the same element a molecular ion contains (which is instead encoded with the isotope_vector field of each :ref:`NXion` instance). - unit: NX_UNITLESS - dim: (p,) - # the following two quantities are relicts from ePOS files used to give some - # insight into the results of the hit_finding algorithm of IVAS/APSuite but typically - # used only in the context to learn about the multiplicity of an ion. - # pulses_since_last_ion(NX_UINT): - # dim: (n,) - # pulse_identifier(NX_INT): - # dim: (n,) + dimensions: + rank: 1 + dim: [[1, p]] + + # the following two quantities are relicts from ePOS files used to give some + # insight into the results of the hit_finding algorithm of IVAS/APSuite but typically + # used only in the context to learn about the multiplicity of an ion. + # pulses_since_last_ion(NX_UINT): + # dim: (n,) + # pulse_identifier(NX_INT): + # dim: (n,) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 12d784b1916396622fe879f2eea50e3a80b46536f09d2c1d7580cc6c096ef964 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of delay-line wires of the detector. +# +# +# +# +# Number of hit qualities (hit types) distinguished. +# +# +# +# +# Number of pulses collected in between start_time and end_time +# resolved by an instance of :ref:`NXevent_data_apm`. If this is not defined, +# p is the number of ions included in the reconstructed volume if an application +# definition is used to store results of already reconstructed datasets. +# +# +# +# +# Base class for the configuration and results from a hit finding algorithm. +# +# +# +# +# +# +# The number of wires in the detector. +# +# +# +# +# +# +# +# +# +# Alias tuple (begin, end) of each DLD wire of the detector. +# Order follows arrival_time_pairs. +# +# +# +# +# +# +# +# +# Raw readings from the analog-to-digital-converter +# timing circuits of the detector wires. +# +# +# +# +# +# +# +# +# +# +# Evaluated ion impact coordinates on the detector. +# Use the depends_on field to spec +# +# +# +# +# +# +# +# Defines in which reference frame the positions are defined. +# +# +# +# +# +# Name of the hit_qualities distinguished. +# AMETEK/Cameca uses e.g. golden, multiple, partial, +# irrecoverable, and multi-first and multi-late. +# +# +# +# +# +# +# +# Identifier used for each hit_quality type. +# Following the order of hit_quality_types. +# +# +# +# +# Hit quality identifier for each pulse. +# Identifier have to be within hit_quality_identifier. +# +# +# +# +# +# +# +# This processing yields for each ion with how many others it evaporated +# if these were collected on the same pulse. Extraction of multiple ions +# on one pulse on different or even the same pixel of the detector are possible. +# +# Multiplicity must not be confused with how many atoms of the same element +# a molecular ion contains (which is instead encoded with the +# isotope_vector field of each :ref:`NXion` instance). +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_msr.yaml b/contributed_definitions/nyaml/NXapm_msr.yaml index 3c0792807a..277cff91c3 100644 --- a/contributed_definitions/nyaml/NXapm_msr.yaml +++ b/contributed_definitions/nyaml/NXapm_msr.yaml @@ -7,7 +7,7 @@ doc: | experiments and computer simulations for atom probe research. The main motivation for this is the ongoing development and tighter becoming connection between atom probe - and other material characterization techniques foremost electron microscopy (see `T. Kelly et al. `_, `C. Fleischmann et al. `_, and `W. Windl et al. `_ or `C. Freysoldt et al. `_ to mention but a few). + and other material characterization techniques foremost electron microscopy (see `T. Kelly et al. `_, `C. Fleischmann et al. `_, and `W. Windl et al. `_ or `C. Freysoldt et al. `_ to mention but a few). To arrive at a design of base classes and an application definition which can be used for both real and simulated atom probe experiments, it is worthwhile to recall concepts that are related to events and (molecular) ions: * Pulsing events which are used to trigger ion extraction events. @@ -63,6 +63,7 @@ doc: | To conclude, we thus propose two base classes :ref:`NXapm_msr` and :ref:`NXapm_sim` where the second one may become obsolete in the future as people realize that a simulated atom probe is maybe equivalent in design and function to a real atom probe if considering that the simulation is just stripped of many components. + # noteworthy the situation is similar to electron microscopy especially transmission electron microscopy where factually # interpretation without simulations is pointless. The only difference is that in electron microscopy there is a large availability # of documentation and open-source tools for performing such simulations. @@ -73,14 +74,15 @@ symbols: Number of pulses collected in between start_time and end_time resolved by an instance of :ref:`NXevent_data_apm`. type: group -NXapm_msr(NXobject): # when evolving these ideas further inherit from NXapm_method instead +NXapm_msr(NXobject): instrument(NXinstrument): doc: | - Metadata of the atom probe or field-ion microscope instrument, henceforth called - microscope or instrument, and the lab in which it stands. + Metadata of the atom probe or field-ion microscope instrument, henceforth called + microscope or instrument, and the lab in which it stands. (NXcsg): doc: | - Possibility to include a detailed computational geometry description of the instrument. + Possibility to include a detailed computational geometry description of the + instrument. instrument_name(NX_CHAR): doc: | Given name of the microscope as defined by the hosting lab. This is an alias. @@ -94,6 +96,7 @@ NXapm_msr(NXobject): # when evolving these ideas further inherit from NXapm_met decelerate_electrode(NXlens_em): doc: | A counter electrode of the LEAP 6000 series atom probes. + # counter_electrodes being optional WO2016171675A1 # see https://en.wikipedia.org/wiki/Einzel_lens for details double einzel lens in the invizo 6000 # according to A. Breen (UNSW) @@ -101,6 +104,7 @@ NXapm_msr(NXobject): # when evolving these ideas further inherit from NXapm_met doc: | A local electrode guiding the ion flight path. Also called counter or extraction electrode. + # 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 @@ -110,9 +114,11 @@ NXapm_msr(NXobject): # when evolving these ideas further inherit from NXapm_met ion_detector(NXdetector): doc: | Detector for taking raw time-of-flight and ion/hit impact positions data. - # model, serial_number, manufacturer_name all inherited from NXdetector base class + + # model, serial_number, manufacturer_name all inherited from NXdetector base class pulser(NXpulser_apm): stage_lab(NXstage_lab): + # NEW ISSUE: add NXapm_energy_analyzer, a voltage grid like done in Rouen/GPM analysis_chamber(NXchamber): buffer_chamber(NXchamber): @@ -125,3 +131,182 @@ NXapm_msr(NXobject): # when evolving these ideas further inherit from NXapm_met A statement whether the measurement was successful or failed prematurely. enumeration: [success, failure, unknown] (NXevent_data_apm_set): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 9361a1a1be4739ad40d833374588a16335784ec414a2f5878eaf47ba8eb8817e +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of pulses collected in between start_time and end_time +# resolved by an instance of :ref:`NXevent_data_apm`. +# +# +# +# +# Base class for collecting a session with a real atom probe or field-ion microscope. +# +# Ideally, we would like to describe the workflow of experiments and simulations of atom probe and +# field-evaporation simulation research in more detail and contextualize better descriptions of +# experiments and computer simulations for atom probe research. +# +# The main motivation for this is the ongoing development and tighter becoming connection between atom probe +# and other material characterization techniques foremost electron microscopy (see `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_, `C. Fleischmann et al. <https://doi.org/10.1016/j.ultramic.2018.08.010>`_, and `W. Windl et al. <https://doi.org/10.1093/micmic/ozad067.294>`_ or `C. Freysoldt et al. <https://doi.org/10.1103/PhysRevLett.124.176801>`_ to mention but a few). +# To arrive at a design of base classes and an application definition which can be used for both real and simulated atom probe experiments, it is worthwhile to recall concepts that are related to events and (molecular) ions: +# +# * Pulsing events which are used to trigger ion extraction events. +# * Physical events and corresponding signal triggered by an ion hitting the detector. +# Some of these events are not necessarily caused by or directly correlated with an identifiable pulsing event. +# * Processed ion hits which are the result of an algorithm that took the physical and pulsing events as input +# and qualified some of these events as to be of sufficiently high quality to call them (molecular) ions that are +# wortwhile to be considered further and eventually included in the reconstructed volume. +# * Calibration and signal filtering steps applied to these processed ion hits as input which results in actually +# selected (molecular) ions based on which an instance of a reconstruction is created. +# * Correlation of these ions with a statistics and theoretical model of mass-to-charge-state ratio values +# and charge states of the (molecular) ions to substantiate that some of these ions are can be considered +# as rangable ions and hence an iontype can be associated by running peak finding algorithms and labeling +# i.e. algorithms for defining ranging definitions. +# +# Not only in AMETEK/Cameca's IVAS/APSuite software, which the majority of atom probers use, these concepts +# are well distinguished. However, the algorithms used to transform correlations between pulses and physical events +# into actual events (detector hits) ions is a proprietary one. Due to this practical inaccessibility of details, +# virtually all atom probe studies currently use a reporting scheme where the course of the specimen evaporation +# is documented such that quantities are a function of evaporation identifier i.e. actual event/ion, i.e. after having +# the hits finding algorithm and correlations applied. That is evaporation_identifier values take the role of an implicit +# time and course of the experiment given that ion extraction is a sequential physical process. +# +# There is a number of research groups who build own instruments and share different aspects of their technical +# specifications and approaches how they apply data processing (e.g. `M. Monajem et al. <https://doi.org/10.1017/S1431927622003397>`_, `P. Stender et al. <https://doi.org/10.1017/S1431927621013982>`_ , or `I. Dimkou et al. <https://doi.org/10.1093/micmic/ozac051>`_ to name but a few). +# Despite some of these activities embrace practices of open-source development, they use essentially the same +# workflow that has been proposed by AMETEK/Cameca and its forerunner company Imago: A graphical user interface +# software is used to explore and thus analyze reconstructed atom probe datasets. +# +# Specifically, software is used to correlate and interpret pulsing and physical events into processed ion hits. +# Some of these ion hits are reported as (molecular) ions with ranged iontypes to yield a dataset based on which +# scientific conclusions about the characterized material volume are made. +# +# By contrast, simulations of field-evaporation have the luxury to document the flight path and allow following the +# whereabouts of each ion evaporated if needed. This level of detail is currently not characterizable in experiment. +# Thus, there is a divide between schemas describing simulations of atom probe vs measurements of atom probe. +# We argue that this divide can be bridged with realizing the above-mentioned context and the realization that +# similar concepts are used in both research realms with many concepts not only being similar but exactly the same. +# +# A further argument to support this view is that computer simulations of atom probe usually are compared to reconstructed +# datasets, either to the input configuration that served as the virtual specimen or to a real world atom probe experiment +# and its reconstructions. In both cases, the recorded simulated physical events of simulated ions hitting a simulated detector +# is not the end of the research workflow but typically the input to apply addition algorithms such as (spatial) filtering +# and reconstruction algorithms. Only the practical need for making ranging definitions is (at least as of now) not as much needed +# in field-evaporation simulations than it is in real world measurements because each ion has a prescribed iontype in the simulation. +# Be it a specifically charged nuclid or a molecular ion whose flight path the simulation resolves. +# Although, in principle simpler though, we have to consider that this is caused by many assumptions made in the simulations. +# Indeed, the multi-scale (time and space) aspects of the challenge that is the simulating of field-evaporation are simplified +# because of otherwise too high computing resource demands and knowledge gaps in how to deal with some complexities. +# Molecular ion dissociation upon flight is one such complexity. Also the complexity of simulation setups is simpler e.g. the assumption of a straight flight path +# instrument is used or details are ignored such as local electrodes or physical obstacles and electric fields (controlled or stray fields). +# +# To conclude, we thus propose two base classes :ref:`NXapm_msr` and :ref:`NXapm_sim` where the second one may become +# obsolete in the future as people realize that a simulated atom probe is maybe equivalent in design and function to a +# real atom probe if considering that the simulation is just stripped of many components. +# +# +# +# Metadata of the atom probe or field-ion microscope instrument, henceforth called +# microscope or instrument, and the lab in which it stands. +# +# +# +# Possibility to include a detailed computational geometry description of the +# instrument. +# +# +# +# +# Given name of the microscope as defined by the hosting lab. This is an alias. +# Examples could be LEAP6000, Raptor, Oxcart, one atom at a time, etc. +# +# +# +# +# Location of the lab or place where the instrument is installed. +# Using GEOREF is preferred. +# +# +# +# +# +# +# A counter electrode of the LEAP 6000 series atom probes. +# +# +# +# +# +# A local electrode guiding the ion flight path. +# Also called counter or extraction electrode. +# +# +# +# +# +# Detector for taking raw time-of-flight and ion/hit impact positions data. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# A statement whether the measurement was successful or failed prematurely. +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml index 8e709e89ea..24693897d5 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml @@ -6,6 +6,7 @@ doc: | symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. + # n_positions: Number of position values. # n_disjoint_clusters: Number of disjoint cluster. n_ivec_max: | @@ -17,20 +18,21 @@ symbols: type: group NXapm_paraprobe_clusterer_config(NXobject): (NXentry): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] definition(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR enumeration: [NXapm_paraprobe_clusterer_config] number_of_tasks(NX_UINT): + unit: NX_UNITLESS doc: | How many cluster_analysis tasks should the tool execute. - unit: NX_UNITLESS cameca_to_nexus(NXapm_paraprobe_tool_config): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] doc: | This process maps results from a cluster analysis made with IVAS / AP Suite into an interoperable representation. IVAS / AP Suite usually exports such results - as a list of reconstructed ion positions with one cluster label per position. + as a list of reconstructed ion positions with one cluster label per position. These labels are reported via the mass-to-charge-state-ratio column of what is effectively a binary file that is formatted like a POS file but cluster labels written out using floating point numbers. @@ -43,12 +45,12 @@ NXapm_paraprobe_clusterer_config(NXobject): mass_to_charge(NX_CHAR): results(NXserialized): doc: | - File with the results of the cluster analyses that was computed with IVAS / AP suite - (e.g. maximum-separation method clustering algorithm `J. Hyde et al. `_). - The information is stored in an improper (.indexed.) POS file as a matrix of floating - point quadruplets, one quadruplet for each ion. The first three values of each - quadruplet encode the position of the ion. The fourth value is the integer identifier - of the cluster encoded as a floating point number. + File with the results of the cluster analyses that was computed with IVAS / AP suite + (e.g. maximum-separation method clustering algorithm `J. Hyde et al. `_). + The information is stored in an improper (.indexed.) POS file as a matrix of floating + point quadruplets, one quadruplet for each ion. The first three values of each + quadruplet encode the position of the ion. The fourth value is the integer identifier + of the cluster encoded as a floating point number. type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): @@ -57,18 +59,19 @@ NXapm_paraprobe_clusterer_config(NXobject): doc: | Specifies if paraprobe-clusterer should use the evaporation_ids from reconstruction for recovering for each position in the :ref:`NXserialized` results the closest matching position - (within floating point accuracy). This can be useful when users wish to recover the + (within floating point accuracy). This can be useful when users wish to recover the original evaporation_id, which IVAS /AP Suite drops when writing their *.indexed.* cluster results POS files that is referred to results. - # recover_bitmask(NX_BOOLEAN): - # doc: | - # Specifies if the tool should try to recover, after a recovery of the - # evaporation IDs a bitmask which identifies which of the positions - # in dataset/dataset/dataset_name_reconstruction where covered - # by the IVAS/APSuite cluster analysis. This can be useful to recover - # the region of interest. + + # recover_bitmask(NX_BOOLEAN): + # doc: | + # Specifies if the tool should try to recover, after a recovery of the + # evaporation IDs a bitmask which identifies which of the positions + # in dataset/dataset/dataset_name_reconstruction where covered + # by the IVAS/APSuite cluster analysis. This can be useful to recover + # the region of interest. cluster_analysisID(NXapm_paraprobe_tool_config): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] doc: | This process performs a cluster analysis on a reconstructed dataset or a ROI within it. @@ -121,15 +124,17 @@ NXapm_paraprobe_clusterer_config(NXobject): orientation(NX_NUMBER): polyhedron_set(NXcg_polyhedron_set): exists: optional - # TODO + + # TODO bitmask(NXcs_filter_boolean_mask): exists: optional number_of_objects(NX_UINT): bitdepth(NX_UINT): mask(NX_UINT): - # leave open if scalar or matrix - # dim: (i,) - # identifier(NX_UINT): + + # leave open if scalar or matrix + # dim: (i,) + # identifier(NX_UINT): evaporation_id_filter(NXsubsampling_filter): exists: optional min_incr_max(NX_INT): @@ -141,6 +146,7 @@ NXapm_paraprobe_clusterer_config(NXobject): exists: optional method(NX_CHAR): match(NX_NUMBER): + # config ion_type_filter(NX_CHAR): doc: | @@ -172,16 +178,20 @@ NXapm_paraprobe_clusterer_config(NXobject): times because at that position (reconstructed) position it has been assumed that there was a Ti and an O atom. This multiplicity affects the size of the feature and its chemical composition. + # enumeration: [resolve_all, resolve_unknown, resolve_ion, resolve_element, resolve_isotope] enumeration: [resolve_element] ion_query_nuclide_vector(NX_UINT): + unit: NX_UNITLESS doc: | Matrix of nuclide vectors, as many as rows as different candidates for iontypes should be distinguished as possible source iontypes. In the simplest case, the matrix contains only the proton number of the element in the row, all other values set to zero. - unit: NX_UNITLESS - dim: (n_ions, n_ivec_max) + dimensions: + rank: 2 + dim: [[1, n_ions], [2, n_ivec_max]] + # which clustering algorithms to execute? dbscan(NXprocess): doc: | @@ -212,37 +222,41 @@ NXapm_paraprobe_clusterer_config(NXobject): one min_pts value that is equal to 1, and high_throughput_method set to combinatorics. enumeration: [tuple, combinatorics] eps(NX_FLOAT): + unit: NX_LENGTH doc: | Array of epsilon (eps) parameter values. - unit: NX_LENGTH - dim: (i,) + dimensions: + rank: 1 + dim: [[1, i]] min_pts(NX_UINT): + unit: NX_UNITLESS doc: | Array of minimum points (min_pts) parameter values. - unit: NX_UNITLESS - dim: (j,) + dimensions: + rank: 1 + dim: [[1, j]] + # THE IDEA BEHIND paraprobe-clusterer is that users can run a number of cluster analyses # on their dataset on exactly the same point cloud and under the same conditions # optics(NXprocess): - # doc: | - # Settings for the OPTICS clustering algorithm. - # - # * `M. Ankerest et al. `_ - # high_throughput_method(NX_CHAR): - # doc: | - # Strategy how runs with different parameter values are composed, - # following the explanation for higih_throughput_method of dbscan. - # enumeration: [tuple, combinatorics] - # min_pts(NX_UINT): - # doc: | - # Array of minimum points (min_pts) parameter values. - # unit: NX_UNITLESS - # dim: (i,) - # max_eps(NX_FLOAT): - # doc: | - # Array of maximum epsilon (eps) parameter values. - # unit: NX_LENGTH - # dim: (j,) + # doc: | + # Settings for the OPTICS clustering algorithm. + # * `M. Ankerest et al. `_ + # high_throughput_method(NX_CHAR): + # doc: | + # Strategy how runs with different parameter values are composed, + # following the explanation for higih_throughput_method of dbscan. + # enumeration: [tuple, combinatorics] + # min_pts(NX_UINT): + # doc: | + # Array of minimum points (min_pts) parameter values. + # unit: NX_UNITLESS + # dim: (i,) + # max_eps(NX_FLOAT): + # doc: | + # Array of maximum epsilon (eps) parameter values. + # unit: NX_LENGTH + # dim: (j,) hdbscan(NXprocess): doc: | Settings for the HPDBScan clustering algorithm. @@ -258,36 +272,433 @@ NXapm_paraprobe_clusterer_config(NXobject): following the explanation for higih_throughput_method of dbscan. enumeration: [tuple, combinatorics] min_cluster_size(NX_NUMBER): + unit: NX_ANY doc: | Array of min_cluster_size parameter values. - unit: NX_ANY - dim: (i,) + dimensions: + rank: 1 + dim: [[1, i]] min_samples(NX_NUMBER): + unit: NX_ANY doc: | Array of min_samples parameter values. - unit: NX_ANY - dim: (j,) + dimensions: + rank: 1 + dim: [[1, j]] cluster_selection_epsilon(NX_NUMBER): + unit: NX_ANY doc: | Array of cluster_selection parameter values. - unit: NX_ANY - dim: (k,) + dimensions: + rank: 1 + dim: [[1, k]] alpha(NX_NUMBER): + unit: NX_ANY doc: | Array of alpha parameter values. - unit: NX_ANY - dim: (m,) - # ADD FURTHER ALGORITHMS, see L. Stephenson for further details - # e.g. https://doi.org/10.1017/S1431927607070900 - common(NXapm_paraprobe_tool_common): + dimensions: + rank: 1 + dim: [[1, m]] + + # ADD FURTHER ALGORITHMS, see L. Stephenson for further details + # e.g. https://doi.org/10.1017/S1431927607070900 + common(NXapm_paraprobe_tool_common): status(NX_CHAR): programID(NXprogram): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR profiling(NXcs_profiling): exists: recommended start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): total_elapsed_time(NX_FLOAT): current_working_directory(NX_CHAR): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 24724111ada93fe288d1bc2ed0d32f2b9f20f745419144c5bfb2f73eaa822ebd +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# +# Maximum number of atoms per molecular ion. Should be 32 for paraprobe. +# +# +# +# +# Number of clustering algorithms used. +# +# +# +# +# Number of different iontypes to distinguish during clustering. +# +# +# +# +# Application definition for a configuration file of the paraprobe-clusterer tool. +# +# This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. +# +# +# +# +# +# +# +# +# +# +# How many cluster_analysis tasks should the tool execute. +# +# +# +# +# This process maps results from a cluster analysis made with IVAS / AP Suite +# into an interoperable representation. IVAS / AP Suite usually exports such results +# as a list of reconstructed ion positions with one cluster label per position. +# These labels are reported via the mass-to-charge-state-ratio column of what is effectively +# a binary file that is formatted like a POS file but cluster labels written out using floating +# point numbers. +# +# +# +# +# +# +# +# +# +# +# +# File with the results of the cluster analyses that was computed with IVAS / AP suite +# (e.g. maximum-separation method clustering algorithm `J. Hyde et al. <https://doi.org/10.1557/PROC-650-R6.6>`_). +# The information is stored in an improper (.indexed.) POS file as a matrix of floating +# point quadruplets, one quadruplet for each ion. The first three values of each +# quadruplet encode the position of the ion. The fourth value is the integer identifier +# of the cluster encoded as a floating point number. +# +# +# +# +# +# +# +# +# Specifies if paraprobe-clusterer should use the evaporation_ids from reconstruction +# for recovering for each position in the :ref:`NXserialized` results the closest matching position +# (within floating point accuracy). This can be useful when users wish to recover the +# original evaporation_id, which IVAS /AP Suite drops when writing their *.indexed.* cluster +# results POS files that is referred to results. +# +# +# +# +# +# +# This process performs a cluster analysis on a +# reconstructed dataset or a ROI within it. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Distance between each ion and triangulated surface mesh. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# How should iontypes be considered during the cluster analysis. +# +# The value resolve_all will set an ion active +# in the analysis regardless of which iontype it is. +# +# The value resolve_unknown will set an ion active +# when it is of the UNKNOWNTYPE. +# +# The value resolve_ion will set an ion active +# if it is of the specific iontype, irregardless of its nuclide structure. +# +# The value resolve_element will set an ion active and account as many times +# for it, as the (molecular) ion contains atoms of elements in the whitelist +# ion_query_nuclide_vector. +# +# The value resolve_isotope will set an ion active and account as many times +# for it, as the (molecular) ion contains nuclides in the whitelist +# ion_query_nuclide_vector. +# +# In effect, ion_query_nuclide_vector acts as a whitelist to filter which ions are +# considered as source ions of the correlation statistics and how the multiplicity +# of each ion will be factorized. +# +# This is relevant as in atom probe we have the situation that an ion of a molecular +# ion with more than one nuclide, say Ti O for example is counted potentially several +# times because at that position (reconstructed) position it has been assumed that +# there was a Ti and an O atom. This multiplicity affects the size of the feature and its +# chemical composition. +# +# +# +# +# +# +# +# +# Matrix of nuclide vectors, as many as rows as different candidates +# for iontypes should be distinguished as possible source iontypes. +# In the simplest case, the matrix contains only the proton number +# of the element in the row, all other values set to zero. +# +# +# +# +# +# +# +# +# +# Settings for DBScan clustering algorithm. For original details about the +# algorithm and (performance-relevant) details consider: +# +# * `M. Ester et al. <https://dx.doi.org/10.5555/3001460.3001507>`_ +# * `M. Götz et al. <https://dx.doi.org/10.1145/2834892.2834894>`_ +# +# For details about how the DBScan algorithms is the key behind the +# specific modification known as the maximum-separation method in the +# atom probe community consider `E. Jägle et al. <https://dx.doi.org/10.1017/S1431927614013294>`_ +# +# +# +# Strategy how a set of cluster analyses with different parameter is executed: +# +# * For tuple as many runs are performed as parameter values have been defined. +# * For combinatorics individual parameter arrays are looped over. +# +# As an example we may provide ten entries for eps and three entries for min_pts. +# If high_throughput_method is set to tuple, the analysis is invalid because we have +# an insufficient number of min_pts values to pair them with our ten eps values. +# By contrast, if high_throughput_method is set to combinatorics, the tool will run three +# individual min_pts runs for each eps value, resulting in a total of 30 analyses. +# +# A typical example from the literature `M. Kühbach et al. <https://dx.doi.org/10.1038/s41524-020-00486-1>`_ +# can be instructed via setting eps to an array of values np.linspace(0.2, 5.0, nums=241, endpoint=True), +# one min_pts value that is equal to 1, and high_throughput_method set to combinatorics. +# +# +# +# +# +# +# +# +# Array of epsilon (eps) parameter values. +# +# +# +# +# +# +# +# Array of minimum points (min_pts) parameter values. +# +# +# +# +# +# +# +# +# +# Settings for the HPDBScan clustering algorithm. +# +# * L. McInnes et al. <https://dx.doi.org/10.21105/joss.00205>`_ +# * scikit-learn hdbscan library `<https://hdbscan.readthedocs.io/en/latest/how_hdbscan_works.html>`_ +# +# See also this documentation for details about the parameter. +# Here we use the terminology of the hdbscan documentation. +# +# +# +# Strategy how runs with different parameter values are composed, +# following the explanation for higih_throughput_method of dbscan. +# +# +# +# +# +# +# +# +# Array of min_cluster_size parameter values. +# +# +# +# +# +# +# +# Array of min_samples parameter values. +# +# +# +# +# +# +# +# Array of cluster_selection parameter values. +# +# +# +# +# +# +# +# Array of alpha parameter values. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml index 32ba9f89fa..1200e2c575 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml @@ -13,15 +13,17 @@ symbols: type: group NXapm_paraprobe_clusterer_results(NXobject): (NXentry): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] definition(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR enumeration: [NXapm_paraprobe_clusterer_results] + # tasks cameca_to_nexus(NXapm_paraprobe_tool_results): exists: optional cluster_analysisID(NXapm_paraprobe_tool_results): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] analysis_identifier(NX_UINT): config(NXserialized): type(NX_CHAR): @@ -32,26 +34,27 @@ NXapm_paraprobe_clusterer_results(NXobject): number_of_ions(NX_UINT): bitdepth(NX_UINT): mask(NX_UINT): + # results dbscanID(NXsimilarity_grouping): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] doc: | Results of a DBScan clustering analysis. eps(NX_FLOAT): + unit: NX_LENGTH doc: | The epsilon (eps) parameter used. - unit: NX_LENGTH min_pts(NX_UINT): + unit: NX_UNITLESS doc: | The minimum points (min_pts) parameter used. - unit: NX_UNITLESS cardinality(NX_UINT): - doc: | - Number of members in the set which is partitioned into features. - Specifically, this is the total number of targets filtered from the - dataset, i.e. typically the number of clusters which is usually not and - for sure not necessarily the total number of ions in the dataset. - unit: NX_UNITLESS + unit: NX_UNITLESS + doc: | + Number of members in the set which is partitioned into features. + Specifically, this is the total number of targets filtered from the + dataset, i.e. typically the number of clusters which is usually not and + for sure not necessarily the total number of ions in the dataset. identifier_offset(NX_INT): doc: | Which identifier is the first to be used to label a cluster. @@ -64,54 +67,68 @@ NXapm_paraprobe_clusterer_results(NXobject): case that objects of the noise category get the value of -1 and points of the unassigned category get the value 0. targets(NX_UINT): + unit: NX_UNITLESS doc: | The evaporation (sequence) identifier (aka evaporation_id) to figure out which ions from the reconstruction were considered targets. The length of this array is not necessarily n_ions. Instead, it is the value of cardinality. - unit: NX_UNITLESS - dim: (i,) + dimensions: + rank: 1 + dim: [[1, i]] + # quantities for debugging purposes number_of_solutions(NX_UINT): exists: optional + unit: NX_UNITLESS doc: | The number of solutions found for each target. Typically, this value is 1 in which case the field can be omitted. Otherwise, this array is the concatenated set of values of solution tuples for each target that can be used to decode model_labels, core_sample_indices, and weight. - unit: NX_UNITLESS - dim: (i,) + dimensions: + rank: 1 + dim: [[1, i]] model_labels(NX_INT): exists: optional + unit: NX_UNITLESS doc: | The raw labels from the DBScan clustering backend process. The length of this array is not necessarily n_ions. Instead, it is typically the value of cardinality provided that each target has only one associated cluster. If targets are assigned to multiple cluster this array is as long as the total number of solutions - found and - unit: NX_UNITLESS - dim: (k,) + found and + dimensions: + rank: 1 + dim: [[1, k]] core_sample_indices(NX_INT): exists: optional + unit: NX_UNITLESS doc: | The raw array of core sample indices which specify which of the targets are core points. - unit: NX_UNITLESS - dim: (k,) + dimensions: + rank: 1 + dim: [[1, k]] numerical_labels(NX_UINT): + unit: NX_UNITLESS doc: | Numerical label for each target (member in the set) aka cluster identifier. - unit: NX_UNITLESS - dim: (k,) + dimensions: + rank: 1 + dim: [[1, k]] categorical_labels(NX_CHAR): exists: optional doc: | Categorical label(s) for each target (member in the set) aka cluster name(s). - dim: (k,) + dimensions: + rank: 1 + dim: [[1, k]] weights(NX_NUMBER): exists: optional + unit: NX_UNITLESS doc: | Weights for each target that specifies how probable the target is assigned to a specific cluster. @@ -120,66 +137,80 @@ NXapm_paraprobe_clusterer_results(NXobject): multiplicity of each ion with respect to the cluster. That is how many times should the position of the ion be accounted for because the ion is e.g. a molecular ion with several elements or nuclides of requested type. - unit: NX_UNITLESS - dim: (k,) - is_noise(NX_BOOLEAN): # NXcs_filter_boolean_mask): - # number_of_objects(NX_UINT): - # bitdepth(NX_UINT): - # mask(NX_UINT): + dimensions: + rank: 1 + dim: [[1, k]] + + # number_of_objects(NX_UINT): + # bitdepth(NX_UINT): + # mask(NX_UINT): + is_noise(NX_BOOLEAN): exists: optional doc: | Are targets assigned to the noise category or not. - dim: (k,) - is_core(NX_BOOLEAN): # NXcs_filter_boolean_mask): - # number_of_objects(NX_UINT): - # bitdepth(NX_UINT): - # mask(NX_UINT): + dimensions: + rank: 1 + dim: [[1, k]] + + # number_of_objects(NX_UINT): + # bitdepth(NX_UINT): + # mask(NX_UINT): + is_core(NX_BOOLEAN): exists: optional doc: | Are targets assumed a core point. - dim: (k,) + dimensions: + rank: 1 + dim: [[1, k]] statistics(NXprocess): exists: recommended doc: | In addition to the detailed storage which members were grouped to which feature here summary statistics are stored that communicate e.g. how many cluster were found. + # at the level of the set of targets number_of_targets(NX_UINT): doc: | Total number of targets in the set, i.e. ions that were filtered and considered in this cluster analysis. number_of_noise(NX_UINT): + unit: NX_UNITLESS doc: | Total number of members in the set which are categorized as noise. - unit: NX_UNITLESS number_of_core(NX_UINT): + unit: NX_UNITLESS doc: | Total number of members in the set which are categorized as a core point. - unit: NX_UNITLESS number_of_features(NX_UINT): + unit: NX_UNITLESS doc: | Total number of clusters (excluding noise and unassigned). - unit: NX_UNITLESS + # at the level of the feature set feature_identifier(NX_UINT): + unit: NX_UNITLESS doc: | Numerical identifier of each feature aka cluster_identifier. - unit: NX_UNITLESS - dim: (n_feat,) + dimensions: + rank: 1 + dim: [[1, n_feat]] feature_member_count(NX_UINT): + unit: NX_UNITLESS doc: | Number of members for each feature. - unit: NX_UNITLESS - dim: (n_feat,) - # ADD FURTHER RESULTS along the same pattern for e.g. OPTICS and HDBSCAN - - common(NXapm_paraprobe_tool_common): + dimensions: + rank: 1 + dim: [[1, n_feat]] + + # ADD FURTHER RESULTS along the same pattern for e.g. OPTICS and HDBSCAN + common(NXapm_paraprobe_tool_common): status(NX_CHAR): programID(NXprogram): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR profiling(NXcs_profiling): exists: recommended start_time(NX_DATE_TIME): @@ -190,21 +221,329 @@ NXapm_paraprobe_clusterer_results(NXobject): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): userID(NXuser): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] doc: | If used, metadata of at least the person who performed this analysis. name(NX_CHAR): coordinate_system_set(NXcoordinate_system_set): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] paraprobe(NXcoordinate_system): type(NX_CHAR): handedness(NX_CHAR): x(NX_NUMBER): unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] y(NX_NUMBER): unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] z(NX_NUMBER): unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 33ed22efaa12bfb8b3513ac2cabdc684c13ea3e57df905aa3331228f9515991e +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The total number of ions in the reconstruction. +# +# +# +# +# Number of clusters found. +# +# +# +# +# Application definition for results files of the paraprobe-spatstat tool. +# +# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Results of a DBScan clustering analysis. +# +# +# +# The epsilon (eps) parameter used. +# +# +# +# +# The minimum points (min_pts) parameter used. +# +# +# +# +# Number of members in the set which is partitioned into features. +# Specifically, this is the total number of targets filtered from the +# dataset, i.e. typically the number of clusters which is usually not and +# for sure not necessarily the total number of ions in the dataset. +# +# +# +# +# Which identifier is the first to be used to label a cluster. +# +# The value should be chosen in such a way that special values can be resolved: +# * identifier_offset - 1 indicates an object belongs to no cluster. +# * identifier_offset - 2 indicates an object belongs to the noise category. +# +# Setting for instance identifier_offset to 1 recovers the commonly used +# case that objects of the noise category get the value of -1 and points of the +# unassigned category get the value 0. +# +# +# +# +# The evaporation (sequence) identifier (aka evaporation_id) to figure out +# which ions from the reconstruction were considered targets. The length +# of this array is not necessarily n_ions. +# Instead, it is the value of cardinality. +# +# +# +# +# +# +# +# +# The number of solutions found for each target. Typically, +# this value is 1 in which case the field can be omitted. +# Otherwise, this array is the concatenated set of values of solution +# tuples for each target that can be used to decode model_labels, +# core_sample_indices, and weight. +# +# +# +# +# +# +# +# The raw labels from the DBScan clustering backend process. +# The length of this array is not necessarily n_ions. +# Instead, it is typically the value of cardinality provided that each +# target has only one associated cluster. If targets are assigned to +# multiple cluster this array is as long as the total number of solutions +# found and +# +# +# +# +# +# +# +# The raw array of core sample indices which specify which of the +# targets are core points. +# +# +# +# +# +# +# +# Numerical label for each target (member in the set) aka cluster identifier. +# +# +# +# +# +# +# +# Categorical label(s) for each target (member in the set) aka cluster name(s). +# +# +# +# +# +# +# +# Weights for each target that specifies how probable the target is assigned to +# a specific cluster. +# +# For the DBScan algorithm and atom probe tomography this value is the +# multiplicity of each ion with respect to the cluster. That is how many times +# should the position of the ion be accounted for because the ion is e.g. a +# molecular ion with several elements or nuclides of requested type. +# +# +# +# +# +# +# +# +# Are targets assigned to the noise category or not. +# +# +# +# +# +# +# +# +# Are targets assumed a core point. +# +# +# +# +# +# +# +# In addition to the detailed storage which members were grouped to which +# feature here summary statistics are stored that communicate e.g. how many +# cluster were found. +# +# +# +# +# Total number of targets in the set, i.e. ions that were filtered +# and considered in this cluster analysis. +# +# +# +# +# Total number of members in the set which are categorized as noise. +# +# +# +# +# Total number of members in the set which are categorized as a core point. +# +# +# +# +# Total number of clusters (excluding noise and unassigned). +# +# +# +# +# +# Numerical identifier of each feature aka cluster_identifier. +# +# +# +# +# +# +# +# Number of members for each feature. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# If used, metadata of at least the person who performed this analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml index 3de1558709..15119e8f8b 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml @@ -9,12 +9,13 @@ symbols: type: group NXapm_paraprobe_distancer_config(NXobject): (NXentry): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] definition(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR enumeration: [NXapm_paraprobe_distancer_config] point_to_triangle(NXapm_paraprobe_tool_config): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] (NXidentifier): exists: optional analysis_identifier(NX_UINT): @@ -32,6 +33,7 @@ NXapm_paraprobe_distancer_config(NXobject): checksum(NX_CHAR): algorithm(NX_CHAR): ranging_definitions(NX_CHAR): + # filter that are here tool-specific parameter spatial_filter(NXspatial_filter): windowing_method(NX_CHAR): @@ -60,14 +62,16 @@ NXapm_paraprobe_distancer_config(NXobject): orientation(NX_NUMBER): polyhedron_set(NXcg_polyhedron_set): exists: optional - # TODO + + # TODO bitmask(NXcs_filter_boolean_mask): exists: optional number_of_objects(NX_UINT): bitdepth(NX_UINT): mask(NX_UINT): + # leave open if scalar or matrix - # dim: (i,) + # dim: (i,) identifier(NX_UINT): evaporation_id_filter(NXsubsampling_filter): exists: optional @@ -80,6 +84,7 @@ NXapm_paraprobe_distancer_config(NXobject): exists: optional method(NX_CHAR): match(NX_NUMBER): + # config method(NX_CHAR): doc: | @@ -91,26 +96,27 @@ NXapm_paraprobe_distancer_config(NXobject): threshold_distance. enumeration: [default, skin] threshold_distance(NX_FLOAT): - exists: optional # required when method == skin + exists: optional + unit: NX_LENGTH doc: | Maximum distance for which distances are computed when *method* is *skin*. - unit: NX_LENGTH - # nm + + # nm number_of_triangle_sets(NX_UINT): + unit: NX_UNITLESS doc: | How many triangle sets to consider. Multiple triangle sets can be defined which are composed into one joint triangle set for the analysis. - unit: NX_UNITLESS triangle_setID(NXserialized): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] doc: | - Each triangle_set that is referred to here should be a face_list_data_structure, - i.e. an array of (n_vertices, 3) of NX_FLOAT for vertex coordinates, an (n_facets, 3) - array of NX_UINT incident vertices of each facet. Vertex indices are assumed to - start at zero and must not exceed n_vertices - 1, i.e. the identifier_offset is 0. - Facet normal have to be provided as an array of (n_facets, 3) of NX_FLOAT. + Each triangle_set that is referred to here should be a face_list_data_structure, + i.e. an array of (n_vertices, 3) of NX_FLOAT for vertex coordinates, an (n_facets, 3) + array of NX_UINT incident vertices of each facet. Vertex indices are assumed to + start at zero and must not exceed n_vertices - 1, i.e. the identifier_offset is 0. + Facet normal have to be provided as an array of (n_facets, 3) of NX_FLOAT. type(NX_CHAR): algorithm(NX_CHAR): checksum(NX_CHAR): @@ -142,16 +148,223 @@ NXapm_paraprobe_distancer_config(NXobject): exists: optional method(NX_CHAR): match(NX_NUMBER): + # point_set_to_polyline_set(NXapm_paraprobe_tool_config): - common(NXapm_paraprobe_tool_common): + common(NXapm_paraprobe_tool_common): status(NX_CHAR): programID(NXprogram): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR profiling(NXcs_profiling): exists: recommended start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): total_elapsed_time(NX_FLOAT): current_working_directory(NX_CHAR): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 37318b17128a037d6a25bbf554600d3dde6833d30c12508242205c3465f55d18 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Application definition for a configuration file of the paraprobe-distancer tool. +# +# This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Specifies for which point the tool will compute distances. +# +# The value *default* configures that distances are computed for all points. +# The value *skin* configures that distances are computed only for those +# points which are not farther away located to a triangle than +# threshold_distance. +# +# +# +# +# +# +# +# +# Maximum distance for which distances are +# computed when *method* is *skin*. +# +# +# +# +# +# How many triangle sets to consider. +# Multiple triangle sets can be defined which are +# composed into one joint triangle set for the analysis. +# +# +# +# +# Each triangle_set that is referred to here should be a face_list_data_structure, +# i.e. an array of (n_vertices, 3) of NX_FLOAT for vertex coordinates, an (n_facets, 3) +# array of NX_UINT incident vertices of each facet. Vertex indices are assumed to +# start at zero and must not exceed n_vertices - 1, i.e. the identifier_offset is 0. +# Facet normal have to be provided as an array of (n_facets, 3) of NX_FLOAT. +# +# +# +# +# +# +# +# Absolute path in the (HDF5) file that points to the array +# of vertex positions for the triangles in that triangle_set. +# +# +# +# +# Absolute path in the (HDF5) file that points to the array +# of vertex indices for the triangles in that triangle_set. +# +# +# +# +# Absolute path in the (HDF5) file that points to the array +# of vertex normal vectors for the triangles in that triangle_set. +# +# +# +# +# Absolute path in the (HDF5) file that points to the array +# of facet normal vectors for the triangles in that triangle_set. +# +# +# +# +# Absolute path in the (HDF5) file that points to the array +# of identifier for the triangles in that triangle_set. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml index 8621780ee4..4243697265 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml @@ -23,13 +23,16 @@ symbols: type: group NXapm_paraprobe_distancer_results(NXobject): (NXentry): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] definition(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR enumeration: [NXapm_paraprobe_distancer_results] + # tasks point_to_triangle(NXapm_paraprobe_tool_results): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] + # config analysis_identifier(NX_UINT): config(NXserialized): @@ -44,30 +47,36 @@ NXapm_paraprobe_distancer_results(NXobject): # results distance(NX_FLOAT): - doc: | # absolute value? + unit: NX_LENGTH + doc: | The shortest analytical distance of each point to their respectively closest triangle from the joint triangle set. - unit: NX_LENGTH - dim: (n_ions,) + dimensions: + rank: 1 + dim: [[1, n_ions]] triangle_identifier(NX_UINT): - exists: optional - doc: | - For each point the identifier of the triangle for which the - shortest distance was found - unit: NX_UNITLESS - dim: (n_ions,) + exists: optional + unit: NX_UNITLESS + doc: | + For each point the identifier of the triangle for which the + shortest distance was found + dimensions: + rank: 1 + dim: [[1, n_ions]] point_identifier(NX_UINT): exists: optional + unit: NX_UNITLESS doc: | A support field to enable the visualization of each point by an explicit identifier on the interval [0, n_ions - 1]. The field can be used to visualize the points as a function of their distance to the triangle set (e.g. via XDMF/Paraview). - unit: NX_UNITLESS - dim: (n_ions,) + dimensions: + rank: 1 + dim: [[1, n_ions]] sign_valid(NXcs_filter_boolean_mask): exists: optional - doc: | + doc: | A bitmask that identifies which of the distance values is assumed to have a consistent sign because the closest triangle had a consistent outer unit normal defined. @@ -75,22 +84,24 @@ NXapm_paraprobe_distancer_results(NXobject): For points whose bit is set to 0 the distance is correct but the sign is not reliable. number_of_triangles(NX_UINT): + unit: NX_UNITLESS doc: | Number of triangles covered by the mask. - unit: NX_UNITLESS bitdepth(NX_UINT): + unit: NX_UNITLESS doc: | Bitdepth of the elementary datatype that is used to store the information content of the mask (typically 8 bit, uint8). - unit: NX_UNITLESS mask(NX_UINT): + unit: NX_UNITLESS doc: | The content of the mask. Like for all masks used in the tools of the paraprobe-toolbox, padding is used when number_of_objects is not an integer multiple of bitdepth. If padding is used, padded bits are set to 0. - unit: NX_UNITLESS - dim: (n_ions) # a mask for points or triangles? + dimensions: + rank: 1 + dim: [[1, n_ions]] window_triangles(NXcs_filter_boolean_mask): exists: optional doc: | @@ -98,18 +109,22 @@ NXapm_paraprobe_distancer_results(NXobject): considered when certain triangles have been filtered out. number_of_objects(NX_UINT): bitdepth(NX_UINT): + # the following field shows a good example of base class inheritance used, # the field mask of the NXcs_filter_boolean_mask is inherited that means its docstring, # its unit category only the dimensions are constrained strong to match the number of objects # triangles in this case mask(NX_UINT): - dim: (n_tri,) - common(NXapm_paraprobe_tool_common): + dimensions: + rank: 1 + dim: [[1, n_tri]] + common(NXapm_paraprobe_tool_common): status(NX_CHAR): programID(NXprogram): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR profiling(NXcs_profiling): exists: recommended start_time(NX_DATE_TIME): @@ -120,21 +135,232 @@ NXapm_paraprobe_distancer_results(NXobject): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): userID(NXuser): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] doc: | If used, metadata of at least the person who performed this analysis. name(NX_CHAR): coordinate_system_set(NXcoordinate_system_set): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] paraprobe(NXcoordinate_system): type(NX_CHAR): handedness(NX_CHAR): x(NX_NUMBER): unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] y(NX_NUMBER): unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] z(NX_NUMBER): unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# ebd0e335a279b791dad8613cf2d80ffcc3a32d2d7a08d6ec6fbeae3497414275 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The total number of points, i.e. ions in the reconstruction. +# +# +# +# +# The total number of triangles in the set. +# +# +# +# +# Application definition for results files of the paraprobe-distancer tool. +# +# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. +# The paraprobe-distancer tool can be used for the computing of the shortest Euclidean distance for each +# member of a set of points against a set of triangles. In contrast to most approaches in atom probe where the +# distance is computed as the projected distance, this tool evaluates robustly the exact distance between +# a point and a triangle. +# +# Triangles can represent for instance the facets of a triangulated surface mesh like those returned by +# paraprobe-surfacer or any other set of triangles. Triangles do not have to be connected. +# +# Currently, paraprobe-distancer does not check if the respectively specified triangle sets are consistent, +# what their topology is, or whether or not these triangles are consistently oriented. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The shortest analytical distance of each point to their +# respectively closest triangle from the joint triangle set. +# +# +# +# +# +# +# +# For each point the identifier of the triangle for which the +# shortest distance was found +# +# +# +# +# +# +# +# A support field to enable the visualization of each point +# by an explicit identifier on the interval [0, n_ions - 1]. +# The field can be used to visualize the points as a function +# of their distance to the triangle set (e.g. via XDMF/Paraview). +# +# +# +# +# +# +# +# A bitmask that identifies which of the distance values is +# assumed to have a consistent sign because the closest +# triangle had a consistent outer unit normal defined. +# +# For points whose bit is set to 0 the distance is correct +# but the sign is not reliable. +# +# +# +# Number of triangles covered by the mask. +# +# +# +# +# Bitdepth of the elementary datatype that is used to store +# the information content of the mask (typically 8 bit, uint8). +# +# +# +# +# The content of the mask. Like for all masks used in the tools +# of the paraprobe-toolbox, padding is used when number_of_objects +# is not an integer multiple of bitdepth. If padding is used, +# padded bits are set to 0. +# +# +# +# +# +# +# +# +# A bitmask that identifies which of the triangles in the set were +# considered when certain triangles have been filtered out. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# If used, metadata of at least the person who performed this analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml index 319ced4c4c..103ade8d25 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml @@ -11,16 +11,17 @@ symbols: type: group NXapm_paraprobe_intersector_config(NXobject): (NXentry): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] definition(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR enumeration: [NXapm_paraprobe_intersector_config] number_of_tasks(NX_UINT): + unit: NX_UNITLESS doc: | How many v_v_spatial_correlation tasks should the tool execute. - unit: NX_UNITLESS v_v_spatial_correlationID(NXapm_paraprobe_tool_config): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] doc: | Tracking volume_volume_spatial_correlations (v_v) is the process of building logical relations between objects, their proximity and eventual volumetric intersections. @@ -30,7 +31,8 @@ NXapm_paraprobe_intersector_config(NXobject): sets of features to members of other sets of volumetric features. Specifically, for each time step :math:`k` pairs of sets are compared: Members of a so-called current_set to members of a so-called next_set. - Members can be different types of volumetric features. + Members can be different types of volumetric features. + # config intersection_detection_method(NX_CHAR): doc: | @@ -43,7 +45,7 @@ NXapm_paraprobe_intersector_config(NXobject): to identify if two objects intersect or not. However, we found that these geometrical analyses can result in corner cases which the tetrahedralization library used in the tests (TetGen) was not unable to tetrahedralize successfully. These cases were virtually always associated with complicated non-convex polyhedra which had portions - of the mesh that were connected by almost point like tubes of triangles. + of the mesh that were connected by almost point like tubes of triangles. Finding more robust methods for computing intersections between not necessarily convex polyhedra might improve the situation in the future. For practical reasons we have thus deactivated the functionality of tetrahedra-tetrahedron @@ -54,18 +56,21 @@ NXapm_paraprobe_intersector_config(NXobject): Specifies if the tool evaluates if objects intersect volumetrically. analyze_proximity(NX_BOOLEAN): doc: | - Specifies if the tool evaluates if objects lay closer to one another than threshold_proximity. + Specifies if the tool evaluates if objects lay closer to one another than + threshold_proximity. analyze_coprecipitation(NX_BOOLEAN): doc: | Specifies if the tool evaluates, provided that all (preprocessing tasks were successful), how intersecting or proximity related objects build sub-graphs. This is the feature that was used in `M. Kühbach et al. `_ for the high-throughput analyses of how many objects are coprecipitates in the sense that they are single, duplet, triplet, or high-order local groups. - # For these analyses to work has_object_volume needs to be true. + + # For these analyses to work has_object_volume needs to be true. threshold_proximity(NX_FLOAT): - doc: | - The maximum Euclidean distance between two objects below which they are considered within proximity. unit: NX_LENGTH + doc: | + The maximum Euclidean distance between two objects below which they are + considered within proximity. has_current_to_next_links(NX_BOOLEAN): doc: | Specifies if the tool stores the so-called forward relations between nodes representing members of the @@ -81,12 +86,14 @@ NXapm_paraprobe_intersector_config(NXobject): to members of the current_set. The meshes were generated as a result of some other meshing process. set_identifier(NX_UINT): + unit: NX_ANY doc: | This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`k`) step when the current set was taken (see `M. Kühbach et al. 2022 `_). - unit: NX_ANY + # number_of_objects(NX_UINT) for now a support field to tell the tool how many objects to load. number_of_feature_types(NX_UINT): + unit: NX_UNITLESS doc: | The total number of distinguished feature sets featureID. It is assumed that the members within all these featureID sets @@ -101,9 +108,8 @@ NXapm_paraprobe_intersector_config(NXobject): So while these four sub-sets contain different so-called types of features, key is that they were all generated for one set, here the current_set. - unit: NX_UNITLESS featureID(NXserialized): - exists: [min, 1, max, 4] + exists: ['min', '1', 'max', '4'] doc: | Name of the (NeXus)/HDF5 file which contains triangulated surface meshes of the members of the set as instances of NXcg_polyhedron_set. @@ -117,13 +123,18 @@ NXapm_paraprobe_intersector_config(NXobject): algorithm(NX_CHAR): geometry(NX_CHAR): doc: | - Absolute path to the group with geometry data in the HDF5 file referred to by path. + Absolute path to the group with geometry data in the HDF5 file referred to by + path. + # currently groupname_geometry_prefix/object/polyhedron. feature_identifier(NX_UINT): - doc: | - Array of identifier whereby the path to the geometry data can be interferred automatically. unit: NX_UNITLESS - dim: (n_variable,) + doc: | + Array of identifier whereby the path to the geometry data can be interferred + automatically. + dimensions: + rank: 1 + dim: [[1, n_variable]] next_set(NXobject): doc: | Next set stores a set of members, meshes of volumetric features, @@ -131,10 +142,11 @@ NXapm_paraprobe_intersector_config(NXobject): to members of the next_set. The meshes were generated as a result of some other meshing process. set_identifier(NX_UINT): + unit: NX_ANY doc: | This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`k + 1`) step when the current set was taken (see `M. Kühbach et al. 2022 `_). - unit: NX_ANY + # number_of_objects(NX_UINT) for now a support field to tell the tool how many objects to load. number_of_feature_types(NX_UINT): unit: NX_UNITLESS @@ -153,7 +165,7 @@ NXapm_paraprobe_intersector_config(NXobject): features key is that they were all generated for one set, here the next_set. featureID(NXserialized): - exists: [min, 1, max, 4] + exists: ['min', '1', 'max', '4'] feature_type(NX_CHAR): doc: | Descriptive category explaining what these features are. @@ -164,25 +176,313 @@ NXapm_paraprobe_intersector_config(NXobject): algorithm(NX_CHAR): geometry(NX_CHAR): doc: | - Absolute path to the group with geometry data in the HDF5 file referred to by path. + Absolute path to the group with geometry data in the HDF5 file referred to by + path. + # currently groupname_geometry_prefix/object/polyhedron. feature_identifier(NX_UINT): - doc: | - Array of identifier whereby the path to the geometry data can be interferred automatically. unit: NX_UNITLESS - dim: (n_variable,) - ##MK::tetrahedra volume intersection and tessellation and Nef polyhedra intersection are considered guru features - # and therefore currently supported only via modifying the C/C++ source code directly as one should know exactly - # what one is doing here before using these functionalities - common(NXapm_paraprobe_tool_common): + doc: | + Array of identifier whereby the path to the geometry data can be interferred + automatically. + dimensions: + rank: 1 + dim: [[1, n_variable]] + + #MK::tetrahedra volume intersection and tessellation and Nef polyhedra intersection are considered guru features + # and therefore currently supported only via modifying the C/C++ source code directly as one should know exactly + # what one is doing here before using these functionalities + common(NXapm_paraprobe_tool_common): status(NX_CHAR): programID(NXprogram): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR profiling(NXcs_profiling): exists: recommended start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): total_elapsed_time(NX_FLOAT): current_working_directory(NX_CHAR): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 5db3ee30d69765138706932c89c9f8b512b8f6293f3f7240106d81d3322a34dd +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of entries +# +# +# +# +# Application definition for a configuration file of the paraprobe-intersector tool. +# +# This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. +# +# +# +# +# +# +# +# +# +# +# How many v_v_spatial_correlation tasks should the tool execute. +# +# +# +# +# Tracking volume_volume_spatial_correlations (v_v) is the process of building logical +# relations between objects, their proximity and eventual volumetric intersections. +# Here, objects are assumed to be represented as a set of triangulated surface meshes. +# +# Volumetric overlap and proximity of volumetric features is identified for members of +# sets of features to members of other sets of volumetric features. Specifically, for each time +# step :math:`k` pairs of sets are compared: +# Members of a so-called current_set to members of a so-called next_set. +# Members can be different types of volumetric features. +# +# +# +# +# Specifies the method whereby to decide if two objects intersect volumetrically. +# For reasons which are detailed in the supplementary material of `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_, +# it is assumed by default that two objects intersect if they share at least one ion with the same evaporation ID (shared_ion). +# +# Alternatively, with specifying tetrahedra_intersections, the tool can perform an intersection analysis which attempts to +# tetrahedralize first each polyhedron. If successful, the tool then checks for at least one pair of intersecting tetrahedra +# to identify if two objects intersect or not. However, we found that these geometrical analyses can result in corner +# cases which the tetrahedralization library used in the tests (TetGen) was not unable to tetrahedralize successfully. +# These cases were virtually always associated with complicated non-convex polyhedra which had portions +# of the mesh that were connected by almost point like tubes of triangles. +# +# Finding more robust methods for computing intersections between not necessarily convex polyhedra might improve +# the situation in the future. For practical reasons we have thus deactivated the functionality of tetrahedra-tetrahedron +# intersections in paraprobe-intersector. +# +# +# +# +# +# +# +# Specifies if the tool evaluates if objects intersect volumetrically. +# +# +# +# +# Specifies if the tool evaluates if objects lay closer to one another than +# threshold_proximity. +# +# +# +# +# Specifies if the tool evaluates, provided that all (preprocessing tasks were successful), how intersecting +# or proximity related objects build sub-graphs. This is the feature that was used in `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_ +# for the high-throughput analyses of how many objects are coprecipitates in the sense that they are single, +# duplet, triplet, or high-order local groups. +# +# +# +# +# +# The maximum Euclidean distance between two objects below which they are +# considered within proximity. +# +# +# +# +# Specifies if the tool stores the so-called forward relations between nodes representing members of the +# current_set to nodes representing members of the next_set. +# +# +# +# +# Specifies if the tool stores the so-called backward relations between nodes representing members of the +# next_set to nodes representing members of the current_set. +# +# +# +# +# Current set stores a set of members, meshes of volumetric features, +# which will be checked for proximity and/or volumetric intersection, +# to members of the current_set. +# The meshes were generated as a result of some other meshing process. +# +# +# +# This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`k`) +# step when the current set was taken (see `M. Kühbach et al. 2022 <https://arxiv.org/abs/2205.13510>`_). +# +# +# +# +# +# The total number of distinguished feature sets featureID. +# It is assumed that the members within all these featureID sets +# are representing a set together. As an example this set might represent +# all volumetric_features. However, users might have formed +# a subset of this set where individuals were regrouped. +# For paraprobe-nanochem this is the case for objects and proxies. +# Specifically, objects are distinguished further into those far +# from and those close to the edge of the dataset. +# Similarly, proxies are distinguished further into those far +# from and those close to the edge of the dataset. +# So while these four sub-sets contain different so-called types of +# features, key is that they were all generated for one set, here the +# current_set. +# +# +# +# +# Name of the (NeXus)/HDF5 file which contains triangulated surface meshes of the +# members of the set as instances of NXcg_polyhedron_set. +# +# +# +# Descriptive category explaining what these features are. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Absolute path to the group with geometry data in the HDF5 file referred to by +# path. +# +# +# +# +# +# Array of identifier whereby the path to the geometry data can be interferred +# automatically. +# +# +# +# +# +# +# +# +# +# Next set stores a set of members, meshes of volumetric features, +# which will be checked for proximity and/or volumetric intersection, +# to members of the next_set. +# The meshes were generated as a result of some other meshing process. +# +# +# +# This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`k + 1`) +# step when the current set was taken (see `M. Kühbach et al. 2022 <https://arxiv.org/abs/2205.13510>`_). +# +# +# +# +# +# The total number of distinguished feature sets featureID. +# It is assumed that the members within all these featureID sets +# are representing a set together. As an example this set might represent +# all volumetric_features. However, users might have formed +# a subset of this set where individuals were regrouped. +# For paraprobe-nanochem this is the case for objects and proxies. +# Specifically, objects are distinguished further into those far +# from and those close to the edge of the dataset. +# Similarly, proxies are distinguished further into those far +# from and those close to the edge of the dataset. +# So while these four sub-sets contain different so-called types of +# features key is that they were all generated for one set, here the +# next_set. +# +# +# +# +# +# Descriptive category explaining what these features are. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Absolute path to the group with geometry data in the HDF5 file referred to by +# path. +# +# +# +# +# +# Array of identifier whereby the path to the geometry data can be interferred +# automatically. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml index 071453302a..fc74463849 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml @@ -21,30 +21,37 @@ symbols: type: group NXapm_paraprobe_intersector_results(NXobject): (NXentry): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] definition(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR enumeration: [NXapm_paraprobe_intersector_results] + # tasks v_v_spatial_correlation(NXapm_paraprobe_tool_results): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] doc: | The results of an overlap/intersection analysis. + # results current_to_next_link(NX_UINT): + unit: NX_UNITLESS doc: | A matrix of feature_identifier that specifies which named features from the current_set have directed link(s) pointing to which named feature(s) from the next_set. - unit: NX_UNITLESS - dim: (n_c2n, 2) + dimensions: + rank: 2 + dim: [[1, n_c2n], [2, 2]] current_to_next_link_type(NX_UINT): + unit: NX_UNITLESS doc: | For each link/pair in current_to_next a characterization whether the link is due to volumetric overlap (0x00 == 0), proximity (0x01 == 1), or something else unknown (0xFF == 255). - unit: NX_UNITLESS - dim: (n_c2n,) + dimensions: + rank: 1 + dim: [[1, n_c2n]] next_to_current_link(NX_UINT): exists: optional unit: NX_UNITLESS @@ -54,23 +61,29 @@ NXapm_paraprobe_intersector_results(NXobject): feature(s) from the current_set. Only if the mapping whereby the links are defined is symmetric it holds that next_to_current maps the links for current_to_next in just the opposite direction. - dim: (n_n2c, 2) + dimensions: + rank: 2 + dim: [[1, n_n2c], [2, 2]] next_to_current_link_type(NX_UINT): exists: optional + unit: NX_UNITLESS doc: | For each link/pair in next_to_current a characterization whether the link is due to a volumetric overlap (0x00 == 0), proximity (0x01 == 1), or something else unknown (0xFF == 255). - unit: NX_UNITLESS - dim: (n_n2c,) + dimensions: + rank: 1 + dim: [[1, n_n2c]] intersection_volume(NX_FLOAT): exists: optional + unit: NX_VOLUME doc: | For each pair of links in current_to_next the volume of the intersection, i.e. how much volume do the two features share. If features do not intersect the volume is zero. - unit: NX_VOLUME - dim: (n_c2n,) + dimensions: + rank: 1 + dim: [[1, n_c2n]] coprecipitation_analysis(NXprocess): exists: optional doc: | @@ -99,25 +112,32 @@ NXapm_paraprobe_intersector_results(NXobject): characterization results to establish spatial correlations of e.g. the precipitates' spatial arrangement. current_set_feature_to_cluster(NX_UINT): + unit: NX_UNITLESS doc: | Matrix of feature_identifier and cluster_identifier pairs which encodes the cluster to which each feature_identifier was assigned. Here for features of the current_set. - unit: NX_UNITLESS - dim: (n_features_curr, 2) + dimensions: + rank: 2 + dim: [[1, n_features_curr], [2, 2]] next_set_feature_to_cluster(NX_UINT): + unit: NX_UNITLESS doc: | Matrix of feature_identifier and cluster_identifier pairs which encodes the cluster to which each feature_identifier was assigned. Here for features of the next_set. - unit: NX_UNITLESS - dim: (n_features_next, 2) + dimensions: + rank: 2 + dim: [[1, n_features_next], [2, 2]] cluster_identifier(NX_UINT): + unit: NX_UNITLESS doc: | The identifier (names) of the cluster. - unit: NX_UNITLESS - dim: (n_cluster,) + dimensions: + rank: 1 + dim: [[1, n_cluster]] cluster_composition(NX_UINT): + unit: NX_UNITLESS doc: | Pivot table as a matrix. The first column encodes how many members from the current_set @@ -127,9 +147,11 @@ NXapm_paraprobe_intersector_results(NXobject): are in each cluster, in the same row per cluster respectively. The third column encodes the total number of members in the cluster. - unit: NX_UNITLESS - dim: (n_cluster, 3) + dimensions: + rank: 2 + dim: [[1, n_cluster], [2, 3]] cluster_statistics(NX_UINT): + unit: NX_UNITLESS doc: | Pivot table as a matrix. @@ -138,10 +160,10 @@ NXapm_paraprobe_intersector_results(NXobject): The second column encodes how many clusters with as many members exist. - unit: NX_UNITLESS - dim: (n_total, 2) - - common(NXapm_paraprobe_tool_common): + dimensions: + rank: 2 + dim: [[1, n_total], [2, 2]] + common(NXapm_paraprobe_tool_common): status(NX_CHAR): analysis_identifier(NX_UINT): config(NXserialized): @@ -150,9 +172,10 @@ NXapm_paraprobe_intersector_results(NXobject): checksum(NX_CHAR): algorithm(NX_CHAR): programID(NXprogram): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR profiling(NXcs_profiling): exists: recommended start_time(NX_DATE_TIME): @@ -163,21 +186,304 @@ NXapm_paraprobe_intersector_results(NXobject): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): userID(NXuser): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] doc: | If used, metadata of at least the person who performed this analysis. name(NX_CHAR): coordinate_system_set(NXcoordinate_system_set): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] paraprobe(NXcoordinate_system): type(NX_CHAR): handedness(NX_CHAR): x(NX_NUMBER): unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] y(NX_NUMBER): unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] z(NX_NUMBER): unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 7bb9384d9681949480b17595ec20b236caad5ff57e50895ec7cf2e514c51cbb9 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The total number of links pointing from current to next. +# +# +# +# +# The total number of links pointing from next to current. +# +# +# +# +# The total number of members in the current_set. +# +# +# +# +# The total number of members in the next_set. +# +# +# +# +# The total number of cluster found for coprecipitation analysis. +# +# +# +# +# The number of rows in the table/matrix for coprecipitation statistics. +# +# +# +# +# Application definition for results files of the paraprobe-intersector tool. +# +# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. +# +# +# +# +# +# +# +# +# +# +# +# The results of an overlap/intersection analysis. +# +# +# +# +# A matrix of feature_identifier that specifies which named features +# from the current_set have directed link(s) pointing to which named +# feature(s) from the next_set. +# +# +# +# +# +# +# +# +# For each link/pair in current_to_next a characterization whether the +# link is due to volumetric overlap (0x00 == 0), proximity (0x01 == 1), +# or something else unknown (0xFF == 255). +# +# +# +# +# +# +# +# A matrix of feature_identifier which specifies which named feature(s) +# from the next_set have directed link(s) pointing to which named +# feature(s) from the current_set. Only if the mapping whereby the +# links are defined is symmetric it holds that next_to_current maps +# the links for current_to_next in just the opposite direction. +# +# +# +# +# +# +# +# +# For each link/pair in next_to_current a characterization whether the +# link is due to a volumetric overlap (0x00 == 0), proximity (0x01 == 1), +# or something else unknown (0xFF == 255). +# +# +# +# +# +# +# +# For each pair of links in current_to_next the volume of the +# intersection, i.e. how much volume do the two features share. +# If features do not intersect the volume is zero. +# +# +# +# +# +# +# +# During coprecipitation analysis the current and next set are analyzed +# for links in a special way. Three set comparisons are made. Members +# of the set in each comparison are analyzed for overlap and proximity: +# +# The first comparison is the current_set against the current_set. +# The second comparison is the next_set against the next_set. +# The third comparison is the current_set against the next_set. +# +# Once the (forward) links for these comparisons are ready, pair relations +# are analyzed with respect to which objects with feature_identifier(s) +# cluster in identifier space. Thereby, a logical connection (link) is +# established between the features in the current_set and the next_set. +# Recall that these two sets typically represent different features +# within an observed system for otherwise the same parameterization. +# +# Examples include two sets of e.g. precipitates with differing +# chemical composition that were characterized in the same material +# volume representing a snapshot of an e.g. microstructure at the same +# point in time. Researchers may have performed two analyses, one to +# characterize precipitates A and another one for percipitates B. +# +# Coprecipitation analysis now logically connects these independent +# characterization results to establish spatial correlations of e.g. +# the precipitates' spatial arrangement. +# +# +# +# Matrix of feature_identifier and cluster_identifier pairs which +# encodes the cluster to which each feature_identifier was assigned. +# Here for features of the current_set. +# +# +# +# +# +# +# +# +# Matrix of feature_identifier and cluster_identifier pairs which +# encodes the cluster to which each feature_identifier was assigned. +# Here for features of the next_set. +# +# +# +# +# +# +# +# +# The identifier (names) of the cluster. +# +# +# +# +# +# +# +# Pivot table as a matrix. +# The first column encodes how many members from the current_set +# are in each cluster, one row per cluster. +# +# The second column encodes how many members from the next_set +# are in each cluster, in the same row per cluster respectively. +# +# The third column encodes the total number of members in the cluster. +# +# +# +# +# +# +# +# +# Pivot table as a matrix. +# +# The first column encodes the different types of +# clusters based on their number of members in the sub-graph. +# +# The second column encodes how many clusters with +# as many members exist. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# If used, metadata of at least the person who performed this analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml index 793c0c7114..07ceb65500 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml @@ -25,12 +25,13 @@ symbols: type: group NXapm_paraprobe_nanochem_config(NXobject): (NXentry): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] definition(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR enumeration: [NXapm_paraprobe_nanochem_config] delocalization(NXapm_paraprobe_tool_config): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] doc: | Discretization and distributing of the ion point cloud on a 3D grid to enable continuum-scale analyses. @@ -43,9 +44,10 @@ NXapm_paraprobe_nanochem_config(NXobject): grid_resolution and kernel_variance values. For example, setting two grid_resolutions and three kernel_variance will compute six runs. Two sets of three with the first set using the first grid_resolutions and in sequence the kernel_variance respectively. - # Although, this uses an efficient multithreaded algorithm the computation is costly. - # Therefore, it can be advantageous for users to load an already computed delocalization. - # This can be achieved with the load_existent option. + + # Although, this uses an efficient multithreaded algorithm the computation is costly. + # Therefore, it can be advantageous for users to load an already computed delocalization. + # This can be achieved with the load_existent option. (NXidentifier): exists: optional analysis_identifier(NX_UINT): @@ -116,15 +118,17 @@ NXapm_paraprobe_nanochem_config(NXobject): orientation(NX_NUMBER): polyhedron_set(NXcg_polyhedron_set): exists: optional - # TODO + + # TODO bitmask(NXcs_filter_boolean_mask): exists: optional number_of_objects(NX_UINT): bitdepth(NX_UINT): mask(NX_UINT): - # leave open if scalar or matrix - # dim: (i,) - # identifier(NX_UINT): + + # leave open if scalar or matrix + # dim: (i,) + # identifier(NX_UINT): evaporation_id_filter(NXsubsampling_filter): exists: optional min_incr_max(NX_INT): @@ -136,6 +140,7 @@ NXapm_paraprobe_nanochem_config(NXobject): exists: optional method(NX_CHAR): match(NX_NUMBER): + # config method(NX_CHAR): doc: | @@ -153,8 +158,10 @@ NXapm_paraprobe_nanochem_config(NXobject): doc: | Absolute path in the (HDF5) file that points to the group within which individual delocalization results are stored. - # TODO: add more descriptions + + # TODO: add more descriptions nuclide_whitelist(NX_UINT): + unit: NX_UNITLESS doc: | Matrix of nuclides representing how iontypes should be accounted for during the delocalization. This is the most general approach to define if and how many @@ -182,29 +189,34 @@ NXapm_paraprobe_nanochem_config(NXobject): Unused values in each row of the matrix are nullified. Nuclides are identified as hashed nuclide (see :ref:`NXion`) for further details. - unit: NX_UNITLESS - dim: (n_ityp_deloc_cand, n_ivec_max) + dimensions: + rank: 2 + dim: [[1, n_ityp_deloc_cand], [2, n_ivec_max]] grid_resolution(NX_FLOAT): + unit: NX_LENGTH doc: | Array of edge lengths of the cubic cells used for discretizing the reconstructed dataset on a cuboidal 3D grid (:ref:`NXcg_grid`). The tool performs as many delocalization computations as values are specified in grid_resolution. - unit: NX_LENGTH - dim: (n_grid,) + dimensions: + rank: 1 + dim: [[1, n_grid]] kernel_size(NX_UINT): + unit: NX_UNITLESS doc: | Half the width of a :math:`{(2 \cdot n + 1)}^3` cubic kernel of cubic voxel beyond which the Gaussian Ansatz function will be truncated. Intensity outside the kernel is factorized into the kernel via a normalization procedure. - unit: NX_UNITLESS kernel_variance(NX_FLOAT): - doc: | - Array of variance values :math:`\sigma` of the Gaussian Ansatz kernel - (:math:`\sigma_x := \sigma`, :math:`\sigma_x = \sigma_y = 2 \cdot \sigma_z`). - The tool performs as many delocalization computations as values are specified - in kernel_variance. unit: NX_LENGTH - dim: (n_var,) + doc: | + Array of variance values :math:`\sigma` of the Gaussian Ansatz kernel + (:math:`\sigma_x := \sigma`, :math:`\sigma_x = \sigma_y = 2 \cdot \sigma_z`). + The tool performs as many delocalization computations as values are specified + in kernel_variance. + dimensions: + rank: 1 + dim: [[1, n_var]] normalization(NX_CHAR): doc: | How should the results of the kernel-density estimation be normalized into quantities. @@ -216,7 +228,7 @@ NXapm_paraprobe_nanochem_config(NXobject): doc: | Specifies if the tool should report the delocalization 3D field values. isosurfacing(NXprocess): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] doc: | Configuration of the set of iso-surfaces to compute using that delocalization. Such iso-surfaces are the starting point for a reconstruction of so-called objects or @@ -267,6 +279,7 @@ NXapm_paraprobe_nanochem_config(NXobject): was one of the main reasons why the paraprobe-nanochem tool was implemented. enumeration: [default, keep_edge_triangles] edge_threshold(NX_FLOAT): + unit: NX_LENGTH doc: | The ion-to-surface distance that is used in the analyses of features to identify whether these are laying inside the dataset or close to the surface (edge) of the dataset. @@ -283,8 +296,8 @@ NXapm_paraprobe_nanochem_config(NXobject): Practically, humans would likely still state in such case that the object is close to the edge of the dataset; however mathematically the object is indeed completely inside. In short, a distance-based approach is rigorous and flexible. - unit: NX_LENGTH phi(NX_FLOAT): + unit: NX_ANY doc: | Iso-contour values. For each value, the tool computes an iso-surface and performs subsequent analyses for each iso-surface. The unit depends on the choice for the @@ -294,8 +307,6 @@ NXapm_paraprobe_nanochem_config(NXobject): * candidates, total number of ions with type in the isotope_whitelist. * composition, candidates but normalized by composition, i.e. at.-% * concentration, candidates but normalized by voxel volume, i.e. ions/nm^3 - - unit: NX_ANY has_triangle_soup(NX_BOOLEAN): doc: | Specifies if the tool should report the triangle soup which represents each triangle of the @@ -335,7 +346,8 @@ NXapm_paraprobe_nanochem_config(NXobject): that contains no ion. has_object_properties(NX_BOOLEAN): doc: | - Specifies if the tool should report properties of each closed polyhedron, such as volume and other details. + Specifies if the tool should report properties of each closed polyhedron, such + as volume and other details. has_object_obb(NX_BOOLEAN): doc: | Specifies if the tool should report for each closed polyhedron an approximately optimal bounding box @@ -414,13 +426,13 @@ NXapm_paraprobe_nanochem_config(NXobject): in this case the cylinder intersects with any triangle. However, for atom probe this case is practically irrelevant provided constructions such as alpha shapes or alpha wrappings (such as paraproeb-surfacer does) about the ions of the entire reconstructed volume are used. - # has_object_mesh_smoothing(NX_BOOLEAN): - # doc: Specifies if the tool should post-process each mesh to improve the mesh quality. - # mesh_smoothing(NXprocess): - # NEW ISSUE: here we need to specify how the meshes were smoothened - + + # has_object_mesh_smoothing(NX_BOOLEAN): + # doc: Specifies if the tool should post-process each mesh to improve the mesh quality. + # mesh_smoothing(NXprocess): + # NEW ISSUE: here we need to specify how the meshes were smoothened interface_meshing(NXapm_paraprobe_tool_config): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] doc: | Use a principle component analysis (PCA) to mesh a single free-standing interface patch within the reconstructed volume that is decorated by ions of specific iontypes (e.g. solute atoms). @@ -498,15 +510,17 @@ NXapm_paraprobe_nanochem_config(NXobject): orientation(NX_NUMBER): polyhedron_set(NXcg_polyhedron_set): exists: optional - # TODO + + # TODO bitmask(NXcs_filter_boolean_mask): exists: optional number_of_objects(NX_UINT): bitdepth(NX_UINT): mask(NX_UINT): - # leave open if scalar or matrix - # dim: (i,) - # identifier(NX_UINT): + + # leave open if scalar or matrix + # dim: (i,) + # identifier(NX_UINT): evaporation_id_filter(NXsubsampling_filter): exists: optional min_incr_max(NX_INT): @@ -518,6 +532,7 @@ NXapm_paraprobe_nanochem_config(NXobject): exists: optional method(NX_CHAR): match(NX_NUMBER): + # config initialization(NX_CHAR): doc: | @@ -557,22 +572,27 @@ NXapm_paraprobe_nanochem_config(NXobject): method(NX_CHAR): enumeration: [whitelist] match(NX_UINT): + unit: NX_UNITLESS doc: | Array of nuclide iontypes to filter. - unit: NX_UNITLESS - dim: (n_fct_filter_cand, n_ivec_max) + dimensions: + rank: 2 + dim: [[1, n_fct_filter_cand], [2, n_ivec_max]] number_of_iterations(NX_UINT): + unit: NX_UNITLESS doc: | How many times should the DCOM and mesh refinement be applied? - unit: NX_UNITLESS target_edge_length(NX_FLOAT): + unit: NX_LENGTH doc: | Array of decreasing positive not smaller than one nanometer real values which specify how the initial triangles of the mesh should be iteratively refined by edge splitting and related mesh refinement operations. - unit: NX_LENGTH - dim: (n_fct_iterations,) + dimensions: + rank: 1 + dim: [[1, n_fct_iterations]] target_dcom_radius(NX_FLOAT): + unit: NX_LENGTH doc: | Array of decreasing positive not smaller than one nanometer real values which specify the radius of the spherical region of interest within which the @@ -582,9 +602,11 @@ NXapm_paraprobe_nanochem_config(NXobject): likely it becomes that vertices will be relocated so substantially that triangle self-intersections may occur. The tool detects these and stops in a controlled manner so that the user can repeat the analyses with using a different parameterization. - unit: NX_LENGTH - dim: (n_fct_iterations,) + dimensions: + rank: 1 + dim: [[1, n_fct_iterations]] target_smoothing_step(NX_UINT): + unit: NX_UNITLESS doc: | Array of integers which specify for each DCOM step how many times the mesh should be iteratively smoothened. Users should be aware that all three arrays @@ -592,11 +614,11 @@ NXapm_paraprobe_nanochem_config(NXobject): in the same sequence, i.e. the zeroth entry of each array specifies the respective parameter values to be used in the first DCOM iteration. The first entry of each array those for the second DCOM iteration and so on and so forth. - unit: NX_UNITLESS - dim: (n_fct_iterations,) - + dimensions: + rank: 1 + dim: [[1, n_fct_iterations]] oned_profile(NXapm_paraprobe_tool_config): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] doc: | Analysis of one-dimensional profiles in ROIs placed in the dataset. Such analyses are useful for quantifying interfacial excess or for @@ -695,10 +717,13 @@ NXapm_paraprobe_nanochem_config(NXobject): which refer to vertices. facet_normals(NX_CHAR): doc: | - Absolute HDF5 path to the dataset that specifies the array of facet signed unit normals. + Absolute HDF5 path to the dataset that specifies the array of facet signed unit + normals. vertex_normals(NX_CHAR): doc: | - Absolute HDF5 path to the dataset that specifies the array of vertex signed unit normals. + Absolute HDF5 path to the dataset that specifies the array of vertex signed unit + normals. + # triangulated surface meshes are only approximations to eventually curved shape of objects # consequently, vertex and facet normals typically differ, the former are typically interpolated # from normals of neighboring facets, type of weighting schemes can affect results quantitatively @@ -751,15 +776,17 @@ NXapm_paraprobe_nanochem_config(NXobject): orientation(NX_NUMBER): polyhedron_set(NXcg_polyhedron_set): exists: optional - # TODO + + # TODO bitmask(NXcs_filter_boolean_mask): exists: optional number_of_objects(NX_UINT): bitdepth(NX_UINT): mask(NX_UINT): - # leave open if scalar or matrix - # dim: (i,) - # identifier(NX_UINT): + + # leave open if scalar or matrix + # dim: (i,) + # identifier(NX_UINT): evaporation_id_filter(NXsubsampling_filter): exists: optional min_incr_max(NX_INT): @@ -771,6 +798,7 @@ NXapm_paraprobe_nanochem_config(NXobject): exists: optional method(NX_CHAR): match(NX_NUMBER): + # config user_defined_roi(NXobject): exists: optional @@ -781,47 +809,1098 @@ NXapm_paraprobe_nanochem_config(NXobject): for composition analyses via positioning and rotating them via a graphical user interface (such as in IVAS / AP Suite). cylinder_set(NXcg_cylinder_set): + # dimensionality(NX_POSINT): # cardinality(NX_POSINT): identifier_offset(NX_INT): center(NX_NUMBER): - dim: (n_rois, 3) + dimensions: + rank: 2 + dim: [[1, n_rois], [2, 3]] height(NX_NUMBER): - dim: (n_rois, 3) + dimensions: + rank: 2 + dim: [[1, n_rois], [2, 3]] radii(NX_NUMBER): - dim: (n_rois,) - # could add other shapes in the future if necessary - # but cylinders are most frequently used + dimensions: + rank: 1 + dim: [[1, n_rois]] + + # could add other shapes in the future if necessary + # but cylinders are most frequently used distancing_model(NX_CHAR): doc: | Which type of distance should be reported for the profile. - enumeration: [project_to_triangle_plane] # ion_to_feature + enumeration: [project_to_triangle_plane] roi_orientation(NX_CHAR): doc: | For each ROI, along which direction should the cylindrical ROI be oriented if ROIs are placed at triangles of the feature mesh. - enumeration: [triangle_outer_unit_normal] # angularly_geodesic_sphere + enumeration: [triangle_outer_unit_normal] roi_cylinder_height(NX_FLOAT): + unit: NX_LENGTH doc: | For each ROI, how high (projected onto the cylinder axis) should the cylindrical ROI be if ROIs are placed at triangles of the feature mesh. - unit: NX_LENGTH roi_cylinder_radius(NX_FLOAT): + unit: NX_LENGTH doc: | For each ROI, how wide (in radius) should the cylindrical ROI be if ROIs are placed at triangles of the feature mesh. - unit: NX_LENGTH - - common(NXapm_paraprobe_tool_common): + common(NXapm_paraprobe_tool_common): status(NX_CHAR): programID(NXprogram): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR profiling(NXcs_profiling): exists: recommended start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): total_elapsed_time(NX_FLOAT): current_working_directory(NX_CHAR): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# d667ff28671c809848a71108542daa45d12b99d09bff226c4d13ac49c5bb686e +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# How many iontypes does the delocalization filter specify. +# +# +# +# +# How many grid_resolutions values. +# +# +# +# +# How many kernel_variance values. +# +# +# +# +# How many disjoint control points are defined. +# +# +# +# +# How many iontypes does the interface meshing iontype filter specify. +# +# +# +# +# How many DCOM iterations. +# +# +# +# +# Maximum number of atoms per molecular ion. +# +# +# +# +# Number of cylinder ROIs to place for oned_profile if no feature mesh is used. +# +# +# +# +# Application definition for a configuration file of the paraprobe-nanochem tool. +# +# This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. +# +# +# +# +# +# +# +# +# +# +# Discretization and distributing of the ion point cloud on a 3D grid +# to enable continuum-scale analyses. +# +# By default, the tool computes a full kernel density estimation of decomposed +# ions to create one discretized field for each element. +# +# One delocalization task configures a parameter sweep with at least one +# delocalization. The total number of runs depends on the number of +# grid_resolution and kernel_variance values. For example, setting two grid_resolutions +# and three kernel_variance will compute six runs. Two sets of three with the first set using +# the first grid_resolutions and in sequence the kernel_variance respectively. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# A precomputed triangulated surface mesh representing a model (of the surface) +# of the edge of the dataset. This model can be used to detect and control +# various sources of bias in the analyses. +# +# +# +# +# +# +# +# Absolute path in the (HDF5) file that points to the array +# of vertex positions for the triangles in that triangle_set. +# +# +# +# +# Absolute path in the (HDF5) file that points to the array +# of vertex indices for the triangles in that triangle_set. +# +# +# +# +# +# Distance between each ion and triangulated surface mesh. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Compute delocalization or load an existent one from input. +# +# +# +# +# +# +# +# +# Serialized result of an already computed delocalization which is for performance +# reasons here just loaded and not computed again. +# +# +# +# +# +# +# +# Absolute path in the (HDF5) file that points to the group within which +# individual delocalization results are stored. +# +# +# +# +# +# +# Matrix of nuclides representing how iontypes should be accounted for during +# the delocalization. This is the most general approach to define if and how many +# times an ion is to be counted. The tool performs a so-called atomic decomposition +# of all iontypes, i.e. the tool analyses from how many atoms of each nuclide +# or element respectively an (molecular) ion is built from. +# +# Taking the hydroxonium H3O+ molecular ion as an example: +# It contains hydrogen and oxygen atoms. The multiplicity of hydrogen +# is three whereas that of oxygen is one. Therefore, the respective atomic decomposition +# analysis prior to the iso-surface computation adds three hydrogen counts for each +# H3O+ ion. +# +# This is a practical solution which accepts that on the one hand not every bond is +# broken during an atom probe experiment but also that ions may react further during +# their flight to the detector. The exact details depend on the local field conditions, +# quantum mechanics of possible electron transfer and thus the detailed trajectory +# of the system and its electronic state. +# +# The detection of molecular ions instead of always single atom ions only is the +# reason that an atom probe experiment tells much about field evaporation physics +# but also faces an inherent loss of information with respect to the detailed spatial +# arrangement that is independent of other imprecisions such as effect of limited +# accuracy of reconstruction protocols and their parameterization. +# +# Unused values in each row of the matrix are nullified. +# Nuclides are identified as hashed nuclide (see :ref:`NXion`) for further details. +# +# +# +# +# +# +# +# +# Array of edge lengths of the cubic cells used for discretizing the reconstructed dataset +# on a cuboidal 3D grid (:ref:`NXcg_grid`). The tool performs as many delocalization +# computations as values are specified in grid_resolution. +# +# +# +# +# +# +# +# Half the width of a :math:`{(2 \cdot n + 1)}^3` cubic kernel of cubic voxel +# beyond which the Gaussian Ansatz function will be truncated. Intensity outside +# the kernel is factorized into the kernel via a normalization procedure. +# +# +# +# +# Array of variance values :math:`\sigma` of the Gaussian Ansatz kernel +# (:math:`\sigma_x := \sigma`, :math:`\sigma_x = \sigma_y = 2 \cdot \sigma_z`). +# The tool performs as many delocalization computations as values are specified +# in kernel_variance. +# +# +# +# +# +# +# +# How should the results of the kernel-density estimation be normalized into quantities. +# By default, the tool computes the total number (intensity) of ions or elements. +# Alternatively, the tool can compute the total intensity, the composition, +# or the concentration of the ions/elements specified by the nuclide_whitelist. +# +# +# +# +# +# +# +# +# +# Specifies if the tool should report the delocalization 3D field values. +# +# +# +# +# Configuration of the set of iso-surfaces to compute using that delocalization. +# Such iso-surfaces are the starting point for a reconstruction of so-called objects or +# (microstructual) features. Examples of scientific relevant are (line features e.g. dislocations +# poles, surface features such as interfaces, i.e. phase and grain boundaries, or volumetric +# features such as precipitates. +# Users should be aware that reconstructed datasets in atom probe are a model and may face +# inaccuracies and artifacts that can be mistaken incorrectly as microstructural features. +# +# +# +# As it is detailed in `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_, the handling of +# triangles at the surface (edge) of the dataset requires special attention especially for +# composition-normalized delocalization. Here, it is possible that the composition +# increases towards the edge of the dataset because the quotient of two numbers +# that are both smaller than one is larger instead of smaller than the counter. +# +# By default, the tool uses a modified marching cubes algorithm of Lewiner et al. +# which detects if voxels face such a situation. In this case, no triangles are generated +# for such voxels. +# +# Alternatively, keep_edge_triangles instructs the tool to not remove triangles at the +# edge of the dataset at the cost of bias. When using this keep_edge_triangles users +# should understand that all features in contact with the edge of the dataset get usually +# artificial enlarged. Consequently, triangulated surface meshes of these objects are +# closed during the marching. However, this closure is artificial and can biased shape +# analyses for those objects. This also holds for such practices that are offered in +# proprietary software like IVAS / AP Suite. The situation is comparable to analyses +# of grain shapes via orientation microscopy from electron microscopy or X-ray +# diffraction tomography. Features at the edge of the dataset may have not been +# captured fully. +# +# Thanks to collaboration with V. V. Rielli and S. Primig from the Sydney atom probe group, +# paraprobe-nanochem implements a complete pipeline to process features at the edge of the +# dataset. Specifically, these are modelled and replaced with closed polyhedral objects using +# an iterative mesh and hole-filling procedures with fairing operations. +# +# The tool bookkeeps such objects separately to lead the decision whether or not to +# consider these objects to the user. Users should be aware that results from fairing operations +# should be compared to results from analyses where all objects at the edge +# of the dataset have been removed. Furthermore, users should be careful with overestimating +# the statistical significance of their dataset especially when using atom probe when they +# use their atom probe result to compare different descriptors. Even though a dataset may +# deliver statistically significant results for compositions, this does not necessarily mean that +# same dataset will also yield statistically significant and insignificantly biased results for +# 3D object analyses! +# +# Being able to quantify these effects and making atom probers aware of these subtleties +# was one of the main reasons why the paraprobe-nanochem tool was implemented. +# +# +# +# +# +# +# +# +# The ion-to-surface distance that is used in the analyses of features to identify whether +# these are laying inside the dataset or close to the surface (edge) of the dataset. +# +# If an object has at least one ion with an ion-to-surface-distance below this threshold, +# the object is considered close to the edge of the dataset. The tool uses a distance-based +# approach to solve the in general complicated and involved treatment of computing +# volumetric intersections between closed 2-manifolds that are not necessarily convex. +# The main practical reason is that such computational geometry analyses face numerical +# robustness issues as a consequence of which a mesh can be detected as being completely +# inside another mesh although in reality it is only :math:`\epsilon`-close only, i.e. almost +# touching only the edge (e.g. from inside). +# +# Practically, humans would likely still state in such case that the object is close to the +# edge of the dataset; however mathematically the object is indeed completely inside. +# In short, a distance-based approach is rigorous and flexible. +# +# +# +# +# Iso-contour values. For each value, the tool computes an iso-surface and performs +# subsequent analyses for each iso-surface. The unit depends on the choice for the +# normalization of the accumulated ion intensity values per voxel: +# +# * total, total number of ions, irrespective their iontype +# * candidates, total number of ions with type in the isotope_whitelist. +# * composition, candidates but normalized by composition, i.e. at.-% +# * concentration, candidates but normalized by voxel volume, i.e. ions/nm^3 +# +# +# +# +# Specifies if the tool should report the triangle soup which represents each triangle of the +# iso-surface complex. The resulting set of triangles is colloquially referred to as a soup +# because different sub-set may not be connected. +# +# Each triangle is reported with an ID specifying to which triangle cluster (with IDs starting at zero) +# the triangle belongs. The clustering of triangles within the soup is performed with a +# modified DBScan algorithm. +# +# +# +# +# Specifies if the tool should analyze for each cluster of triangles how they can be combinatorially +# processed to describe a closed polyhedron. Such a closed polyhedron (not-necessarily convex!) +# can be used to describe objects with relevance in the microstructure. +# +# Users should be aware that the resulting mesh does not necessarily represent the original precipitate. +# In fact, inaccuracies in the reconstructed positions cause inaccuracies in all downstream processing +# operations. Especially the effect on one-dimensional spatial statistics like nearest neighbor correlation +# functions were discussed in the literature `B. Gault et al. <https://doi.org/10.1017/S1431927621012952>`_. +# +# In continuation of these thoughts, this applies also to reconstructed objects. +# A well-known example is the discussion of shape deviations of scandium-rich precipitates in aluminium alloys +# which in reconstructions may appear as ellipsoids although they should be indeed almost spherical +# provided their size is larger than the atomic length scale. +# +# +# +# +# Specifies if the tool should report a triangulated surface mesh for each identified closed polyhedron. +# It is common that a marching cubes algorithm creates iso-surfaces with a fraction of tiny sub-complexes +# (e.g. small isolated tetrahedra). +# +# These can be small tetrahedra/polyhedra about the center of a voxel of the support grid +# on which marching cubes operates. Such objects may not contain an ion; especially when considering +# that delocalization procedures smoothen the positions of the ions. Although these small objects are +# interesting from a numerical point of view, scientists may argue they are not worth to be reported because +# a microstructural feature should contain at least a few atoms to become relevant. +# Therefore, paraprobe-nanochem by default does not report closed objects which bound a volume +# that contains no ion. +# +# +# +# +# Specifies if the tool should report properties of each closed polyhedron, such +# as volume and other details. +# +# +# +# +# Specifies if the tool should report for each closed polyhedron an approximately optimal bounding box +# fitted to all triangles of the surface mesh of the object and ion positions inside or on the surface of the mesh. +# This bounding box informs about the closed object's shape (aspect ratios). +# +# Users should be aware that the choice of the algorithm to compute the bounding box can have an +# effect on aspect ratio statistics. It is known that computing the true optimal bounding box of in 3D +# is an :math:`\mathcal{O}^3`-time-complex task. The tool uses well-established approximate algorithms +# of the Computational Geometry Algorithms Library (CGAL). +# +# +# +# +# Specifies if the tool should report for each closed polyhedron all evaporation IDs of those ions which +# lay inside or on the boundary of the polyhedron. This information is used by the paraprobe-intersector +# tool to infer if two objects share common ions, which is then understood as that the two objects intersect. +# +# Users should be aware that two arbitrarily closed polyhedra in three-dimensional space can intersect +# but not share a common ion. In fact, the volume bounded by the polyhedron has sharp edges and flat +# face(t)s. When taking two objects, an edge of one object may for instance pierce into the surface of +# another object. In this case the objects partially overlap / intersect volumetrically; however this piercing +# might be so small or happening in the volume between two reconstructed ion positions. Consequently, +# sharing ions is a sufficient but not a necessary condition for interpreting (volumetric) intersections +# between objects. +# +# Paraprobe-intersector implements a rigorous alternative to handle such intersections using a tetrahedralization +# of closed objects. However, in many practical cases, we found through examples that there are polyhedra (especially when they are non-convex and have almost point-like) connected channels, where +# tetrahedralization libraries have challenges dealing with. In this case, checking intersections +# via shared_ions is a more practical alternative. +# +# +# +# +# Specifies if the tool should report if a (closed) object has contact with the surface aka edge of the dataset. +# For this the tool currently inspects if the shortest distance between the set of triangles of the triangulated +# surface mesh and the triangles of the edge model is larger than edge_threshold. +# If this is the case, the object is assumed to be deeply embedded in the interior of the dataset. +# Otherwise, the object is considered to have an edge contact, i.e. it shape is likely affected by the edge. +# +# +# +# +# Specifies if the tool should analyze a closed polyhedron (aka proxy) for each cluster of triangles whose +# combinatorial analysis according to has_object returned that the object is not a closed polyhedron. +# Such proxies are closed via iterative hole-filling, mesh refinement, and fairing operations. +# +# Users should be aware that the resulting mesh does not necessarily represent the original feature. +# In most cases objects, precipitates in atom probe end up as open objects because they have been +# clipped by the edge of the dataset. Using a proxy is in this case a strategy to still be able to account +# for these objects. However, users should make themselves familiar with the consequences and +# potential biases which this can introduce into the analysis. +# +# +# +# +# Like has_object_geometry but for the proxies. +# +# +# +# +# Like has_object_properties but for the proxies. +# +# +# +# +# Like has_object_obb but for the proxies. +# +# +# +# +# Like has_object_ions but for the proxies. +# +# +# +# +# Like has_object_edge_contact but for the proxies. +# +# +# +# +# Specifies if the tool should report for each closed object a (cylindrical) region-of-interest (ROI) that gets +# placed, centered, and aligned with the local normal for each triangle of the object. +# +# +# +# +# Specifies if the tool should report for each ROI that was placed at a triangle of each object if this ROI intersects +# with the edge the dataset. Currently, the tool supports cylindrical ROIs. A computational geometry test is +# performed to check for a possible intersection of each ROI with the triangulated surface mesh that is defined +# via surface. Results of this cylinder-set-of-triangles intersection are interpreted as follows: +# If the cylinder intersects with at least one triangle of the surface (mesh) the ROI is assumed to make edge contact. +# Otherwise, the ROI is assumed to make no edge contact. +# +# Users should note that this approach does not work if the ROI is laying completely outside the dataset as also +# in this case the cylinder intersects with any triangle. However, for atom probe this case is practically irrelevant +# provided constructions such as alpha shapes or alpha wrappings (such as paraproeb-surfacer does) about the +# ions of the entire reconstructed volume are used. +# +# +# +# +# +# +# +# Use a principle component analysis (PCA) to mesh a single free-standing interface patch within +# the reconstructed volume that is decorated by ions of specific iontypes (e.g. solute atoms). +# +# Interface_meshing is a typical starting point for the quantification of Gibbsian interfacial excess +# in cases when closed objects constructed from patches e.g. iso-surfaces are not available or +# when there is no substantial or consistently oriented concentration gradients across an interface +# patch. The functionality can also be useful when the amount of latent crystallographic information +# within the point cloud is insufficient or when combined with interface_meshing based on ion density +# traces in field-desorption maps (see `Y. Wei et al. <https://doi.org/10.1371/journal.pone.0225041>`_ +# and `A. Breen et al. <https://github.com/breen-aj/detector>`_ for details). +# +# Noteworthy to mention is that the method used is conceptually similar to the work of `Z. Peng et al. <https://doi.org/10.1017/S1431927618016112>`_ and related work (DCOM algorithm) by `P. Felfer et al. <https://doi.org/10.1016/j.ultramic.2015.06.002>`_. Compared to these implementations +# paraprobe-nanochem uses inspection functionalities which detect potential geometric +# inconsistencies or self-interactions of the evolved DCOM mesh. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# A precomputed triangulated surface mesh representing a model (of the surface) +# of the edge of the dataset. This model can be used to detect and control +# various sources of bias in the analyses. +# +# +# +# +# +# +# +# Absolute path in the (HDF5) file that points to the array +# of vertex positions for the triangles in that triangle_set. +# +# +# +# +# Absolute path in the (HDF5) file that points to the array +# of vertex indices for the triangles in that triangle_set. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# How is the PCA initialized: +# +# * default, means based on segregated solutes in the ROI +# * control_point_file, means based on reading an external list of +# control points, currently coming from the Leoben APT_Analyzer. +# +# The control_point_file is currently expected with a specific format. +# The Leoben group lead by L. Romaner has developed a GUI tool `A. Reichmann et al. <https://github.com/areichm/APT_analyzer>`_ creates a control_point_file that +# can be parsed by paraprobe-parmsetup-nanochem to match the here required +# formatting in control_points. +# +# +# +# +# +# +# +# +# Details about the control point file used. +# +# +# +# +# +# +# +# X, Y, Z position matrix of disjoint control points. +# +# +# +# +# +# Method used for identifying and refining the location of the interface. Currently, +# paraprobe-nanochem implements a PCA followed by an iterative loop of isotropic +# mesh refinement and DCOM step(s), paired with self-intersection detection. +# +# +# +# +# +# +# +# Specify those nuclides which the tool should inspect iontypes for if they contain such nuclides. +# If this is the case ions of such type are taken with the number of nuclides of this multiplicity found. +# The atoms of these ions are assumed to serve as useful markers for locating the interface and +# refining the interface mesh. +# +# +# +# +# +# +# +# +# Array of nuclide iontypes to filter. +# +# +# +# +# +# +# +# +# +# How many times should the DCOM and mesh refinement be applied? +# +# +# +# +# Array of decreasing positive not smaller than one nanometer real values +# which specify how the initial triangles of the mesh should be iteratively +# refined by edge splitting and related mesh refinement operations. +# +# +# +# +# +# +# +# Array of decreasing positive not smaller than one nanometer real values +# which specify the radius of the spherical region of interest within which the +# DCOM algorithm decides for each vertex how the vertex might be relocated. +# +# The larger it is the DCOM radius in relation to the target_edge_length the more +# likely it becomes that vertices will be relocated so substantially that triangle +# self-intersections may occur. The tool detects these and stops in a controlled +# manner so that the user can repeat the analyses with using a different parameterization. +# +# +# +# +# +# +# +# Array of integers which specify for each DCOM step how many times the mesh +# should be iteratively smoothened. Users should be aware that all three arrays +# target_edge_length, target_dcom_radius, and target_smoothing_step are interpreted +# in the same sequence, i.e. the zeroth entry of each array specifies the respective +# parameter values to be used in the first DCOM iteration. The first entry of each array +# those for the second DCOM iteration and so on and so forth. +# +# +# +# +# +# +# +# +# Analysis of one-dimensional profiles in ROIs placed in the dataset. +# Such analyses are useful for quantifying interfacial excess or for +# performing classical composition analyses. +# +# The tool will test for each ROIs if it is completely embedded in the dataset. +# Specifically, each such test evaluates if the ROI cuts at least one triangle +# of the triangulated surface mesh that is referred to by surface. +# If this is the case the ROI is marked as one close to the surface +# and not analyzed further. Otherwise, the ROI is marked as one far +# from the surface and processed further. +# +# For each ROI the tool computes atomically decomposed profiles. +# This means, molecular ions are splitted into nuclides as many times as +# their respective multiplicity. For each processed ROI the tool stores +# a sorted list of signed distance values to enable post-processing with +# other software like e.g. reporter to perform classical +# Krakauer/Seidman-style interfacial excess analyses. +# +# Users should be aware that the latter intersection analysis is not +# a volumetric intersection analysis. Given that the triangulated mesh +# referred to in surface is not required to mesh neither a watertight +# nor convex polyhedron a rigorous testing of volumetric intersection +# is much more involved. If the mesh is watertight one could use split +# the task in first tessellating the mesh into convex polyhedra (e.g. +# tetrahedra and apply a volumetric intersection method like the +# Gilbert-Johnson-Keerthi algorithm (GJK). In cases when the mesh is not +# even watertight distance-based segmentation in combination with again +# intersection of triangles and convex polyhedra is a robust but currently +# not implemented method to quantify intersections. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# A precomputed triangulated surface mesh representing a model (of the surface) +# of the edge of the dataset. This model can be used to detect and control +# various sources of bias in the analyses. +# +# +# +# +# +# +# +# Absolute path in the (HDF5) file that points to the array +# of vertex positions for the triangles in that triangle_set. +# +# +# +# +# Absolute path in the (HDF5) file that points to the array +# of vertex indices for the triangles in that triangle_set. +# +# +# +# +# +# Distance between each ion and triangulated surface mesh. +# +# +# +# +# +# +# +# Absolute path in the (HDF5) file that points to the distance values. +# The tool assumes that the values are stored in the same order as +# points (ions). +# +# +# +# +# +# A precomputed triangulated mesh of the feature representing a model of the +# interface at which to place ROIs to profile. This can be the mesh of an +# interface as returned e.g. by a previous interface_meshing task or the +# mesh of an iso-surface from a previous delocalization task. +# +# +# +# +# +# +# +# Absolute HDF5 path to the dataset that specifies the array of vertex positions. +# +# +# +# +# Absolute HDF5 path to the dataset that specifies the array of facet indices +# which refer to vertices. +# +# +# +# +# Absolute HDF5 path to the dataset that specifies the array of facet signed unit +# normals. +# +# +# +# +# Absolute HDF5 path to the dataset that specifies the array of vertex signed unit +# normals. +# +# +# +# +# +# If interface_model is isosurface this filter can be used to restrict the analysis to specific +# patches of an iso-surface. +# +# +# +# +# +# +# +# To enable an additional filtration of specific parts of the feature +# mesh it is recommended to feed precomputed distances of each ion to +# the triangles of the feature mesh. +# +# +# +# +# +# +# +# Absolute path in the (HDF5) file that points to the distance values. +# The tool assumes that the values are stored in the same order as +# points (ions). +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# As an alternative mode the tool can be instructed to place ROIs +# at specific locations into the dataset. This is the programmatic +# equivalent to the classical approach in atom probe to place ROIs +# for composition analyses via positioning and rotating them via +# a graphical user interface (such as in IVAS / AP Suite). +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Which type of distance should be reported for the profile. +# +# +# +# +# +# +# +# For each ROI, along which direction should the cylindrical ROI +# be oriented if ROIs are placed at triangles of the feature mesh. +# +# +# +# +# +# +# +# For each ROI, how high (projected onto the cylinder axis) should +# the cylindrical ROI be if ROIs are placed at triangles +# of the feature mesh. +# +# +# +# +# For each ROI, how wide (in radius) should the cylindrical ROI +# be if ROIs are placed at triangles of the feature mesh. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml index 21f067f37a..84a0f55bfb 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml @@ -16,6 +16,7 @@ symbols: The dimensionality of the delocalization grid. c: | The cardinality/total number of cells/grid points in the delocalization grid. + # c_tri_soup: | # The cardinality/total number of triangles in the triangle soup. n_f_tri: | @@ -33,17 +34,20 @@ symbols: type: group NXapm_paraprobe_nanochem_results(NXobject): (NXentry): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] definition(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR enumeration: [NXapm_paraprobe_nanochem_results] + # tasks delocalizationID(NXdelocalization): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] window(NXcs_filter_boolean_mask): number_of_ions(NX_UINT): bitdepth(NX_UINT): mask(NX_UINT): + # results weighting_model(NXmatch_filter): weighting_method(NX_CHAR): @@ -61,23 +65,28 @@ NXapm_paraprobe_nanochem_results(NXobject): doc: | The discretized domain/grid on which the delocalization is applied. dimensionality(NX_POSINT): - enumeration: [1, 2, 3] unit: NX_UNITLESS + enumeration: [1, 2, 3] cardinality(NX_POSINT): + unit: NX_UNITLESS doc: | The total number of cells/voxels of the grid. - unit: NX_UNITLESS origin(NX_NUMBER): - dim: (d,) + dimensions: + rank: 1 + dim: [[1, d]] symmetry(NX_CHAR): doc: | The symmetry of the lattice defining the shape of the unit cell. enumeration: [cubic] cell_dimensions(NX_NUMBER): - doc: | - The unit cell dimensions according to the coordinate system defined under coordinate_system. unit: NX_LENGTH - dim: (d,) + doc: | + The unit cell dimensions according to the coordinate system defined under + coordinate_system. + dimensions: + rank: 1 + dim: [[1, d]] extent(NX_POSINT): doc: | Number of unit cells along each of the d-dimensional base vectors. @@ -86,39 +95,47 @@ NXapm_paraprobe_nanochem_results(NXobject): as it could be for instance the case of a grid where all grid points outside some masking primitive are removed, this extent field should not be used. Instead use the coordinate field. - dim: (d,) + dimensions: + rank: 1 + dim: [[1, d]] + # coordinate_system implicit identifier_offset(NX_INT): + unit: NX_UNITLESS doc: | Integer which specifies the first index to be used for distinguishing identifiers for cells. Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array has to be defined. - unit: NX_UNITLESS kernel_size(NX_POSINT): + unit: NX_DIMENSIONLESS doc: | Halfwidth of the kernel about the central voxel. The shape of the kernel is that of a cuboid of extent 2*kernel_extent[i] + 1 in each dimension i. - unit: NX_DIMENSIONLESS - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] kernel_type(NX_CHAR): doc: | Functional form of the kernel (Ansatz function). enumeration: [gaussian] kernel_sigma(NX_FLOAT): + unit: NX_LENGTH doc: | Standard deviation :math:`\sigma_i` of the kernel in each dimension in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. - unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] kernel_mu(NX_FLOAT): + unit: NX_LENGTH doc: | Expectation value :math:`\mu_i` of the kernel in each dimension in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. - unit: NX_LENGTH - dim: (3,) - + dimensions: + rank: 1 + dim: [[1, 3]] bounding_box(NXcg_hexahedron_set): doc: | A tight axis-aligned bounding box about the grid. @@ -126,31 +143,32 @@ NXapm_paraprobe_nanochem_results(NXobject): doc: | For atom probe should be set to true. identifier_offset(NX_INT): + unit: NX_UNITLESS doc: | Integer which specifies the first index to be used for distinguishing hexahedra. Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array has to be defined. - unit: NX_UNITLESS hexahedron(NXcg_face_list_data_structure): vertex_identifier_offset(NX_INT): + unit: NX_UNITLESS doc: | Integer which specifies the first index to be used for distinguishing identifiers for vertices. Identifiers are defined either implicitly or explicitly. - For implicit indexing the identifiers are defined on the interval + For implicit indexing the identifiers are defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array has to be defined. - unit: NX_UNITLESS face_identifier_offset(NX_INT): + unit: NX_UNITLESS doc: | Integer which specifies the first index to be used for distinguishing identifiers for faces. Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array has to be defined. - unit: NX_UNITLESS vertices(NX_NUMBER): + unit: NX_LENGTH doc: | Positions of the vertices. Users are encouraged to reduce the vertices to unique set of positions @@ -160,9 +178,11 @@ NXapm_paraprobe_nanochem_results(NXobject): Naively here means that one for example stores each vertex of a triangle mesh even though many vertices are shared between triangles and thus the positions of these vertices do not have to be duplicated. - unit: NX_LENGTH - dim: (8, 3) + dimensions: + rank: 2 + dim: [[1, 8], [2, 3]] faces(NX_NUMBER): + unit: NX_UNITLESS doc: | Array of identifiers from vertices which describe each face. @@ -174,31 +194,37 @@ NXapm_paraprobe_nanochem_results(NXobject): Therefore, summating over the number_of_vertices, allows to extract the vertex identifiers for the i-th face on the following index interval of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. - unit: NX_UNITLESS - dim: (6, 4) + dimensions: + rank: 2 + dim: [[1, 6], [2, 4]] xdmf_topology(NX_UINT): + unit: NX_UNITLESS 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 - dim: (36,) + dimensions: + rank: 1 + dim: [[1, 36]] number_of_boundaries(NX_POSINT): exists: optional + unit: NX_UNITLESS doc: | How many distinct boundaries are distinguished? Most grids discretize a cubic or cuboidal region. In this case six sides can be distinguished, each making an own boundary. - unit: NX_UNITLESS boundaries(NX_CHAR): exists: optional doc: | Name of the boundaries. E.g. left, right, front, back, bottom, top, The field must have as many entries as there are number_of_boundaries. - dim: (6,) + dimensions: + rank: 1 + dim: [[1, 6]] boundary_conditions(NX_INT): exists: optional + unit: NX_UNITLESS doc: | The boundary conditions for each boundary: @@ -208,11 +234,13 @@ NXapm_paraprobe_nanochem_results(NXobject): 3 - mirror 4 - von Neumann 5 - Dirichlet - unit: NX_UNITLESS - dim: (6,) - ##MK::how to avoid storing it for once in NeXus for H5Web and for XDMF in ParaView ? + dimensions: + rank: 1 + dim: [[1, 6]] + + #MK::how to avoid storing it for once in NeXus for H5Web and for XDMF in ParaView ? scalar_field_magn_SUFFIX(NXdata): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] doc: | The result of the delocalization :math:`\Phi = f(x, y, z)` based on which subsequent iso-surfaces will be computed. In commercial software so far there is no possibility to export this information. @@ -225,106 +253,146 @@ NXapm_paraprobe_nanochem_results(NXobject): down-stream usage of the here reported values (e.g. with Python scripting). In this case name the individual NXdata instances scalar_field_magn_ionID using the ID of the ion as per the configuration of the ranging definitions used. - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@xpos_indices(NX_UINT): - \@ypos_indices(NX_UINT): - \@zpos_indices(NX_UINT): + \@signal: + type: NX_CHAR + \@axes: + type: NX_CHAR + \@xpos_indices: + type: NX_UINT + \@ypos_indices: + type: NX_UINT + \@zpos_indices: + type: NX_UINT title(NX_CHAR): intensity(NX_FLOAT): + unit: NX_ANY doc: | The actual delocalized intensity values. - unit: NX_ANY - dim: (n_z, n_y, n_x) + dimensions: + rank: 3 + dim: [[1, n_z], [2, n_y], [3, n_x]] xpos(NX_FLOAT): + unit: NX_LENGTH doc: | Cell center of mass positions along x. - unit: NX_LENGTH - dim: (n_x,) + dimensions: + rank: 1 + dim: [[1, n_x]] ypos(NX_FLOAT): + unit: NX_LENGTH doc: | Cell center of mass positions along y. - unit: NX_LENGTH - dim: (n_y,) + dimensions: + rank: 1 + dim: [[1, n_y]] zpos(NX_FLOAT): + unit: NX_LENGTH doc: | Cell center of mass positions along z. - unit: NX_LENGTH - dim: (n_z,) + dimensions: + rank: 1 + dim: [[1, n_z]] xdmf_intensity(NX_FLOAT): exists: optional + unit: NX_ANY doc: | Intensity of the field at given point - unit: NX_ANY - dim: (n_xyz,) + dimensions: + rank: 1 + dim: [[1, n_xyz]] xdmf_xyz(NX_FLOAT): exists: optional + unit: NX_UNITLESS doc: | Center of mass positions of each voxel for rendering the scalar field via XDMF in e.g. Paraview. - unit: NX_UNITLESS - dim: (n_xyz, 3) + dimensions: + rank: 2 + dim: [[1, n_xyz], [2, 3]] xdmf_topology(NX_NUMBER): exists: optional + unit: NX_UNITLESS doc: | XDMF topology for rendering in combination with xdmf_xyz the scalar field via XDMF in e.g. Paraview. - unit: NX_UNITLESS - dim: (i,) # 3*n_xyz + dimensions: + rank: 1 + dim: [[1, i]] scalar_field_grad_SUFFIX(NXdata): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] doc: | The three-dimensional gradient :math:`\nabla \Phi`. Follow the naming convention of scalar_field_magn_SUFFIX to report parallel structures. - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@xpos_indices(NX_CHAR): - \@ypos_indices(NX_CHAR): - \@zpos_indices(NX_CHAR): + \@signal: + type: NX_CHAR + \@axes: + type: NX_CHAR + \@xpos_indices: + type: NX_CHAR + \@ypos_indices: + type: NX_CHAR + \@zpos_indices: + type: NX_CHAR title(NX_CHAR): intensity(NX_FLOAT): + unit: NX_ANY doc: | The actual point-wise component values. - unit: NX_ANY - dim: (n_z, n_y, n_x, 3) + dimensions: + rank: 4 + dim: [[1, n_z], [2, n_y], [3, n_x], [4, 3]] xpos(NX_FLOAT): + unit: NX_LENGTH doc: | Cell center of mass positions along x. - unit: NX_LENGTH - dim: (n_x,) + dimensions: + rank: 1 + dim: [[1, n_x]] ypos(NX_FLOAT): + unit: NX_LENGTH doc: | Cell center of mass positions along y. - unit: NX_LENGTH - dim: (n_y,) + dimensions: + rank: 1 + dim: [[1, n_y]] zpos(NX_FLOAT): + unit: NX_LENGTH doc: | Cell center of mass positions along z. - unit: NX_LENGTH - dim: (n_z,) + dimensions: + rank: 1 + dim: [[1, n_z]] xdmf_gradient(NX_FLOAT): exists: optional - doc: | - The gradient vector formatted for direct visualization via XDMF in e.g. Paraview. unit: NX_ANY - dim: (n_xyz, 3) + doc: | + The gradient vector formatted for direct visualization via XDMF in e.g. + Paraview. + dimensions: + rank: 2 + dim: [[1, n_xyz], [2, 3]] xdmf_xyz(NX_FLOAT): exists: optional + unit: NX_LENGTH doc: | Center of mass positions of each voxel for rendering the scalar field gradient via XDMF in e.g. Paraview. - unit: NX_LENGTH - dim: (n_xyz, 3) + dimensions: + rank: 2 + dim: [[1, n_xyz], [2, 3]] xdmf_topology(NX_NUMBER): exists: optional + unit: NX_UNITLESS doc: | XDMF topology for rendering in combination with xdmf_xyz the scalar field via XDFM in e.g. Paraview. - unit: NX_UNITLESS - dim: (i,) # 3*n_xyz - ##MK:: + dimensions: + rank: 1 + dim: [[1, i]] + + #MK:: iso_surfaceID(NXisocontour): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] doc: | An iso-surface is the boundary between two regions across which the magnitude of a scalar field falls below/exceeds a threshold magnitude :math:`\varphi`. @@ -336,12 +404,13 @@ NXapm_paraprobe_nanochem_results(NXobject): Paraprobe-nanochem approximates this complex with a soup of triangles. dimensionality(NX_POSINT): isovalue(NX_NUMBER): + unit: NX_ANY doc: | The threshold or iso-contour value :math:`\varphi`. - unit: NX_ANY marching_cubes(NXcg_marching_cubes): doc: | - Details about the specific marching cubes algorithm that was used for computing the iso-surface. + Details about the specific marching cubes algorithm that was used for computing + the iso-surface. implementation(NX_CHAR): doc: | Reference to the specific implementation of marching cubes used. @@ -358,17 +427,18 @@ NXapm_paraprobe_nanochem_results(NXobject): cardinality(NX_POSINT): unit: NX_UNITLESS identifier_offset(NX_INT): + unit: NX_UNITLESS doc: | Integer which specifies the first index to be used for distinguishing triangles. Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. - unit: NX_UNITLESS triangles(NXcg_face_list_data_structure): number_of_vertices(NX_POSINT): number_of_faces(NX_POSINT): vertex_identifier_offset(NX_INT): face_identifier_offset(NX_INT): vertices(NX_NUMBER): + unit: NX_LENGTH doc: | Positions of the vertices. @@ -377,9 +447,11 @@ NXapm_paraprobe_nanochem_results(NXobject): It is also possible though to store the vertex positions naively in which case vertices_are_unique is likely False. Naively here means that each vertex is stored even though many share the same positions. - unit: NX_LENGTH - dim: (i, 3) + dimensions: + rank: 2 + dim: [[1, i], [2, 3]] faces(NX_INT): + unit: NX_UNITLESS doc: | Array of identifiers from vertices which describe each face. @@ -391,24 +463,30 @@ NXapm_paraprobe_nanochem_results(NXobject): Therefore, summating over the number_of_vertices, allows to extract the vertex identifiers for the i-th face on the following index interval of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. - unit: NX_UNITLESS - dim: (j,) + dimensions: + rank: 1 + dim: [[1, j]] xdmf_topology(NX_UINT): + unit: NX_UNITLESS doc: | A list of as many tuples of XDMF topology key, XDMF number of vertices and a triple of vertex indices specifying each triangle. The total number of entries is n_f_tri * (1+1+3). - unit: NX_UNITLESS - dim: (n_f_tri_xdmf,) + dimensions: + rank: 1 + dim: [[1, n_f_tri_xdmf]] vertex_normal(NXcg_unit_normal_set): exists: optional normals(NX_FLOAT): + unit: NX_DIMENSIONLESS doc: | Direction of each normal. - unit: NX_DIMENSIONLESS - dim: (j, 3) + dimensions: + rank: 2 + dim: [[1, j], [2, 3]] orientation(NX_UINT): exists: optional + unit: NX_UNITLESS doc: | Qualifier how which specifically oriented normal to its primitive each normal represents. @@ -416,19 +494,24 @@ NXapm_paraprobe_nanochem_results(NXobject): * 0 - undefined * 1 - outer * 2 - inner - unit: NX_UNITLESS - dim: (j,) + dimensions: + rank: 1 + dim: [[1, j]] + # edge_normal(NXcg_unit_normal_set): - # exists: optional + # exists: optional face_normal(NXcg_unit_normal_set): exists: optional normals(NX_FLOAT): + unit: NX_DIMENSIONLESS doc: | Direction of each normal. - unit: NX_DIMENSIONLESS - dim: (k, 3) + dimensions: + rank: 2 + dim: [[1, k], [2, 3]] orientation(NX_UINT): exists: optional + unit: NX_UNITLESS doc: | Qualifier how which specifically oriented normal to its primitive each normal represents. @@ -436,24 +519,29 @@ NXapm_paraprobe_nanochem_results(NXobject): * 0 - undefined * 1 - outer * 2 - inner - unit: NX_UNITLESS - dim: (k,) + dimensions: + rank: 1 + dim: [[1, k]] gradient_guide_magnitude(NX_FLOAT): + unit: NX_ANY doc: | Triangle normals are oriented in the direction of the gradient vector of the local delocalized scalar field. :math:`\sum_{x, y, z} {\nabla{c}_i}^2`. - unit: NX_ANY - dim: (k,) + dimensions: + rank: 1 + dim: [[1, k]] + # gradient_guide_quality(NX_FLOAT): - # doc: | - # Triangle normals are oriented in the direction of the - # gradient vector of the local delocalized scalar field. - # Sum of squared values of cross product of triangle normal - # construction. - # unit: NX_ANY - # dim: (k,) + # doc: | + # Triangle normals are oriented in the direction of the + # gradient vector of the local delocalized scalar field. + # Sum of squared values of cross product of triangle normal + # construction. + # unit: NX_ANY + # dim: (k,) gradient_guide_projection(NX_FLOAT): + unit: NX_ANY doc: | Triangle normals are oriented in the direction of the gradient vector of the local delocalized scalar field. @@ -463,38 +551,46 @@ NXapm_paraprobe_nanochem_results(NXobject): This is a descriptor of how parallel the projection is that is especially useful to document those triangles for whose the projection is almost perpendicular. - unit: NX_ANY - dim: (k,) + dimensions: + rank: 1 + dim: [[1, k]] area(NX_NUMBER): exists: optional unit: NX_AREA - dim: (j,) + dimensions: + rank: 1 + dim: [[1, j]] edge_length(NX_NUMBER): exists: optional + unit: NX_LENGTH doc: | Array of edge length values. For each triangle the edge length is reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - unit: NX_LENGTH - dim: (k, 3) + dimensions: + rank: 2 + dim: [[1, k], [2, 3]] interior_angle(NX_NUMBER): exists: optional + unit: NX_ANGLE doc: | Array of interior angle values. For each triangle the angle is reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - unit: NX_ANGLE - dim: (j, 4) + dimensions: + rank: 2 + dim: [[1, j], [2, 4]] center(NX_NUMBER): exists: optional + unit: NX_LENGTH doc: | The center of mass of each triangle. - unit: NX_LENGTH - dim: (j, 3) - + dimensions: + rank: 2 + dim: [[1, j], [2, 3]] volumetric_features(NXprocess): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] doc: | Iso-surfaces of arbitrary scalar three-dimensional fields can show a complicated topology. Paraprobe-nanochem can run a DBScan-like clustering algorithm which performs a @@ -521,39 +617,49 @@ NXapm_paraprobe_nanochem_results(NXobject): In the second step, the tool can be used to analyze the proximity of these objects to a model of the surface (edge) of the dataset. triangle_cluster_identifier(NX_UINT): + unit: NX_UNITLESS doc: | The identifier which the triangle_soup connectivity analysis returned, which constitutes the first step of the volumetric_feature identification process. - unit: NX_UNITLESS - dim: (n_v_feat,) + dimensions: + rank: 1 + dim: [[1, n_v_feat]] feature_type_dict_keyword(NX_UINT): exists: optional + unit: NX_UNITLESS doc: | The array of keywords of feature_type dictionary. - unit: NX_UNITLESS - dim: (n_feature_dict,) + dimensions: + rank: 1 + dim: [[1, n_feature_dict]] feature_type_dict_value: exists: optional doc: | The array of values for each keyword of the feature_type dictionary. - dim: (n_feature_dict,) + dimensions: + rank: 1 + dim: [[1, n_feature_dict]] feature_type(NX_UINT): + unit: NX_UNITLESS doc: | The array of controlled keywords, need to be from feature_type_dict_keyword, which specify which type each feature triangle cluster belongs to. Keep in mind that not each feature is an object or proxy. - unit: NX_UNITLESS - dim: (n_v_feat,) + dimensions: + rank: 1 + dim: [[1, n_v_feat]] feature_identifier(NX_UINT): + unit: NX_UNITLESS doc: | The explicit identifier of features. - unit: NX_UNITLESS - dim: (n_v_feat,) + dimensions: + rank: 1 + dim: [[1, n_v_feat]] FEATURE(NXprocess): - exists: [min, 0, max, 6] # because there are at most six different categories of features, see below + exists: ['min', '0', 'max', '6'] doc: | In all situations instances of the parent NXprocess group are returned with a very similar information structuring and thus we here replace the template name FEATURE @@ -565,42 +671,52 @@ NXapm_paraprobe_nanochem_results(NXobject): * proxies, proxies, irrespective their distance to the surface * proxies_close_to_edge, sub-set of v_feature_proxies, close to surface * proxies_far_from_edge, sub-set of v_feature_proxies, not close to surface - feature_identifier(NX_UINT): - doc: | - Explicit identifier of the feature a sub-set of the feature_identifier in the parent group. unit: NX_UNITLESS - dim: (i,) + doc: | + Explicit identifier of the feature a sub-set of the feature_identifier in the + parent group. + dimensions: + rank: 1 + dim: [[1, i]] volume(NX_FLOAT): + unit: NX_VOLUME doc: | Volume of the feature. NaN for non-watertight objects. - unit: NX_VOLUME - dim: (i,) + dimensions: + rank: 1 + dim: [[1, i]] obb(NXcg_hexahedron_set): exists: optional doc: | An oriented bounding box (OBB) to each object. size(NX_FLOAT): exists: optional + unit: NX_LENGTH doc: | Edge length of the oriented bounding box from largest to smallest value. - unit: NX_LENGTH - dim: (i, 3) + dimensions: + rank: 2 + dim: [[1, i], [2, 3]] aspect(NX_FLOAT): exists: optional + unit: NX_DIMENSIONLESS doc: | Oriented bounding box aspect ratio. YX versus ZY or second-largest over largest and smallest over second largest. - unit: NX_DIMENSIONLESS - dim: (i, 2) + dimensions: + rank: 2 + dim: [[1, i], [2, 2]] center(NX_NUMBER): exists: optional + unit: NX_LENGTH doc: | Position of the geometric center, which often is but not necessarily has to be the center_of_mass of the hexahedrally-shaped sample/sample part. - unit: NX_LENGTH - dim: (i, 3) + dimensions: + rank: 2 + dim: [[1, i], [2, 3]] hexahedra(NXcg_face_list_data_structure): exists: optional doc: | @@ -608,73 +724,98 @@ NXapm_paraprobe_nanochem_results(NXobject): is to store the shape of the hexahedra for visualization. vertices(NX_NUMBER): unit: NX_LENGTH - dim: (k, 3) - ##MK::again we have no effective way to pinpoint the n_rows - ##MK::namely k != i each OBB has eight vertices + dimensions: + rank: 2 + dim: [[1, k], [2, 3]] + + #MK::again we have no effective way to pinpoint the n_rows + #MK::namely k != i each OBB has eight vertices xdmf_topology(NX_UINT): unit: NX_UNITLESS - dim: (k,) + dimensions: + rank: 1 + dim: [[1, k]] xdmf_feature_identifier(NX_UINT): unit: NX_UNITLESS - dim: (k,) + dimensions: + rank: 1 + dim: [[1, k]] objectID(NXcg_polyhedron_set): - exists: [min, 0, max, infty] # not infty but at most n_v_feat + exists: ['min', '0', 'max', 'unbounded'] polyhedron(NXcg_face_list_data_structure): + # number_of_vertices(NX_POSINT): # number_of_faces(NX_POSINT): # vertex_identifier_offset(NX_UINT): # face_identifier_offset(NX_UINT): vertices(NX_FLOAT): unit: NX_LENGTH - dim: (n_v, 3) + dimensions: + rank: 2 + dim: [[1, n_v], [2, 3]] faces(NX_UINT): unit: NX_UNITLESS - dim: (n_f, 3) + dimensions: + rank: 2 + dim: [[1, n_f], [2, 3]] face_normals(NX_FLOAT): unit: NX_LENGTH - dim: (n_f, 3) + dimensions: + rank: 2 + dim: [[1, n_f], [2, 3]] xdmf_topology(NX_UINT): exists: recommended unit: NX_UNITLESS - dim: (k,) + dimensions: + rank: 1 + dim: [[1, k]] xdmf_feature_identifier(NX_UINT): - exists: recommended - unit: NX_UNITLESS - dim: (k,) + exists: recommended + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, k]] ion_identifier(NX_UINT): exists: optional + unit: NX_UNITLESS doc: | Array of evaporation_identifier / ion_identifier which details which ions lie inside or on the surface of the feature. - unit: NX_UNITLESS - dim: (m,) + dimensions: + rank: 1 + dim: [[1, m]] composition(NXchemical_composition): exists: optional total(NX_NUMBER): + unit: NX_UNITLESS doc: | Total (count) of ions inside or on the surface of the feature relevant for normalization. NaN for non watertight objects. - unit: NX_UNITLESS - dim: (i,) + dimensions: + rank: 1 + dim: [[1, i]] ionID(NXion): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] charge_state(NX_INT): + # check these two ? nuclide_hash(NX_UINT): nuclide_list(NX_UINT): count(NX_NUMBER): + unit: NX_UNITLESS doc: | Count or weight which, when divided by total, yields the composition of this element, nuclide, or (molecular) ion within the volume of the feature/object. - unit: NX_UNITLESS - dim: (i,) - + dimensions: + rank: 1 + dim: [[1, i]] interface_meshing(NXapm_paraprobe_tool_results): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] window(NXcs_filter_boolean_mask): number_of_ions(NX_UINT): bitdepth(NX_UINT): mask(NX_UINT): + # results ion_multiplicity(NX_UINT): exists: optional @@ -690,14 +831,18 @@ NXapm_paraprobe_nanochem_results(NXobject): this molecular ion contributes two carbon atoms at the reconstructed location considering that the spatial resolution of atom probe experiments is limited. - dim: (n_ions,) + dimensions: + rank: 1 + dim: [[1, n_ions]] decorator_multiplicity(NX_UINT): exists: optional unit: NX_UNITLESS doc: | The multiplicity whereby the ion position is accounted for when the ion is considered one which is a decorator of the interface. - dim: (n_ions,) + dimensions: + rank: 1 + dim: [[1, n_ions]] initial_interface(NXprocess): exists: optional doc: | @@ -706,9 +851,11 @@ NXapm_paraprobe_nanochem_results(NXobject): unit: NX_LENGTH doc: | The four parameter :math:`ax + by + cz + d = 0` which define the plane. - dim: (4,) + dimensions: + rank: 1 + dim: [[1, 4]] mesh_stateID(NXcg_triangle_set): - exists: [min, 0, max, infty] # as many as DCOM steps * 2 because one for pre and one for post + exists: ['min', '0', 'max', 'unbounded'] doc: | The triangle surface mesh representing the interface model. Exported at state before or after the next DCOM step. @@ -737,15 +884,21 @@ NXapm_paraprobe_nanochem_results(NXobject): unit: NX_UNITLESS face_identifier(NX_UINT): unit: NX_UNITLESS - dim: (j,) + dimensions: + rank: 1 + dim: [[1, j]] vertices(NX_NUMBER): unit: NX_LENGTH - dim: (i, 3) + dimensions: + rank: 2 + dim: [[1, i], [2, 3]] vertex_normal(NX_FLOAT): unit: NX_LENGTH doc: | Direction of each vertex normal. - dim: (i, 3) + dimensions: + rank: 2 + dim: [[1, i], [2, 3]] vertex_normal_orientation(NX_UINT): unit: NX_UNITLESS doc: | @@ -755,16 +908,21 @@ NXapm_paraprobe_nanochem_results(NXobject): * 0 - undefined * 1 - outer * 2 - inner - - dim: (i,) + dimensions: + rank: 1 + dim: [[1, i]] faces(NX_UINT): unit: NX_UNITLESS - dim: (j, 3) + dimensions: + rank: 2 + dim: [[1, j], [2, 3]] face_normal(NX_FLOAT): + unit: NX_LENGTH doc: | Direction of each face normal. - unit: NX_LENGTH - dim: (j, 3) + dimensions: + rank: 2 + dim: [[1, j], [2, 3]] face_normal_orientation(NX_UINT): unit: NX_UNITLESS doc: | @@ -774,41 +932,50 @@ NXapm_paraprobe_nanochem_results(NXobject): * 0 - undefined * 1 - outer * 2 - inner - - dim: (j,) + dimensions: + rank: 1 + dim: [[1, j]] xdmf_topology(NX_UINT): unit: NX_UNITLESS - dim: (k,) + dimensions: + rank: 1 + dim: [[1, k]] area(NX_NUMBER): unit: NX_AREA - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] edge_length(NX_NUMBER): unit: NX_LENGTH doc: | Array of edge length values. For each triangle the edge length is reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - dim: (c, 3) + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] interior_angle(NX_NUMBER): unit: NX_ANGLE doc: | Array of interior angle values. For each triangle the angle is reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - dim: (c, 4) - + dimensions: + rank: 2 + dim: [[1, c], [2, 4]] oned_profile(NXapm_paraprobe_tool_results): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] window(NXcs_filter_boolean_mask): exists: optional number_of_ions(NX_UINT): bitdepth(NX_UINT): mask(NX_UINT): + # results xdmf_cylinder(NXcg_polyhedron_set): doc: | The ROIs are defined as cylinders for the computations. To visualize these we discretize - them into regular n-gons. Using for instance 360-gons, i.e. a regular n-gon with 360 edges, + them into regular n-gons. Using for instance 360-gons, i.e. a regular n-gon with 360 edges, resolves the lateral surface of each cylinder such that their renditions are smooth in visualization software like Paraview. dimensionality(NX_POSINT): @@ -816,42 +983,55 @@ NXapm_paraprobe_nanochem_results(NXobject): cardinality(NX_POSINT): unit: NX_UNITLESS center(NX_NUMBER): + unit: NX_LENGTH doc: | Position of the geometric center, which often is but not necessarily has to be the center_of_mass of the polyhedra. - unit: NX_LENGTH - dim: (i, 3) + dimensions: + rank: 2 + dim: [[1, i], [2, 3]] orientation(NX_FLOAT): + unit: NX_LENGTH doc: | The orientation of the ROI defined via a vector which points along the cylinder axis and whose length is the height of the cylinder. - unit: NX_LENGTH - dim: (i, 3) + dimensions: + rank: 2 + dim: [[1, i], [2, 3]] + # XDMF support identifier(NX_UINT): exists: optional + unit: NX_UNITLESS doc: | XDMF support to enable colouring each ROI by its identifier. - unit: NX_UNITLESS - dim: (j,) + dimensions: + rank: 1 + dim: [[1, j]] edge_contact(NX_UINT): exists: optional + unit: NX_UNITLESS doc: | XDMF support to enable colouring each ROI whether it has edge contact or not. - unit: NX_UNITLESS - dim: (j,) + dimensions: + rank: 1 + dim: [[1, j]] number_of_atoms(NX_UINT): exists: optional + unit: NX_UNITLESS doc: | XDMF support to enable colouring each ROI by its number of atoms. - unit: NX_UNITLESS - dim: (j,) + dimensions: + rank: 1 + dim: [[1, j]] number_of_ions(NX_UINT): exists: optional + unit: NX_UNITLESS doc: | XDMF support to enable colouring each ROI by its number of ions. - unit: NX_UNITLESS - dim: (j,) + dimensions: + rank: 1 + dim: [[1, j]] rois_far_from_edge(NXprocess): doc: | Distance and iontype-specific processed data for each ROI. @@ -865,20 +1045,23 @@ NXapm_paraprobe_nanochem_results(NXobject): are only expected to display pairwise the same values respectively, if all ions are built from a single atom only. roiID(NXobject): - exists: [min, 0, max, infty] # no max is := i + exists: ['min', '0', 'max', 'unbounded'] signed_distance(NX_FLOAT): + unit: NX_LENGTH doc: | Sorted in increasing order projected along the positive direction of the ROI as defined by orientation in the parent group. - unit: NX_LENGTH - dim: (k,) + dimensions: + rank: 1 + dim: [[1, k]] nuclide_hash(NX_UINT): + unit: NX_UNITLESS doc: | Hashvalue as defined in :ref:`NXion`. - unit: NX_UNITLESS - dim: (k,) - - common(NXapm_paraprobe_tool_common): + dimensions: + rank: 1 + dim: [[1, k]] + common(NXapm_paraprobe_tool_common): status(NX_CHAR): analysis_identifier(NX_UINT): config(NXserialized): @@ -887,9 +1070,10 @@ NXapm_paraprobe_nanochem_results(NXobject): checksum(NX_CHAR): algorithm(NX_CHAR): programID(NXprogram): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR profiling(NXcs_profiling): exists: recommended start_time(NX_DATE_TIME): @@ -900,21 +1084,1302 @@ NXapm_paraprobe_nanochem_results(NXobject): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): userID(NXuser): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] doc: | If used, metadata of at least the person who performed this analysis. name(NX_CHAR): coordinate_system_set(NXcoordinate_system_set): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] paraprobe(NXcoordinate_system): type(NX_CHAR): handedness(NX_CHAR): x(NX_NUMBER): unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] y(NX_NUMBER): unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] z(NX_NUMBER): unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# cf0eca2c8f8d9502e181f8b2627688b4c1068a30da0160e761ccc31e2f1ac2bc +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The total number of ions in the reconstruction. +# +# +# +# +# The total number of atoms in the atomic_decomposition match filter. +# +# +# +# +# The total number of isotopes in the isotopic_decomposition match filter. +# +# +# +# +# The dimensionality of the delocalization grid. +# +# +# +# +# The cardinality/total number of cells/grid points in the delocalization grid. +# +# +# +# +# +# The total number of faces of triangles. +# +# +# +# +# The total number of XDMF values to represent all faces of triangles via XDMF. +# +# +# +# +# The total number of entries in a feature dictionary. +# +# +# +# +# The total number of volumetric features. +# +# +# +# +# The total number of member distinguished when reporting composition. +# +# +# +# +# The total number of ROIs placed in an oned_profile task. +# +# +# +# +# Application definition for results files of the paraprobe-nanochem tool. +# +# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# How were results of the kernel-density estimation normalized: +# * total, the total number (intensity) of ions or elements. +# * candidates, the total number (intensity) of ions matching weighting_model +# * composition, the value for candidates divided by the value for total, +# * concentration, the value for candidates divided by the volume of the cell. +# +# +# +# +# +# +# +# +# +# +# The discretized domain/grid on which the delocalization is applied. +# +# +# +# +# +# +# +# +# +# +# The total number of cells/voxels of the grid. +# +# +# +# +# +# +# +# +# +# The symmetry of the lattice defining the shape of the unit cell. +# +# +# +# +# +# +# +# The unit cell dimensions according to the coordinate system defined under +# coordinate_system. +# +# +# +# +# +# +# +# Number of unit cells along each of the d-dimensional base vectors. +# The total number of cells, or grid points has to be the cardinality. +# If the grid has an irregular number of grid positions in each direction, +# as it could be for instance the case of a grid where all grid points +# outside some masking primitive are removed, this extent field should +# not be used. Instead use the coordinate field. +# +# +# +# +# +# +# +# +# Integer which specifies the first index to be used for distinguishing identifiers for cells. +# Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are +# defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. +# For explicit indexing the identifier array has to be defined. +# +# +# +# +# Halfwidth of the kernel about the central voxel. +# The shape of the kernel is that of a cuboid +# of extent 2*kernel_extent[i] + 1 in each dimension i. +# +# +# +# +# +# +# +# Functional form of the kernel (Ansatz function). +# +# +# +# +# +# +# +# Standard deviation :math:`\sigma_i` of the kernel in each dimension +# in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. +# +# +# +# +# +# +# +# Expectation value :math:`\mu_i` of the kernel in each dimension +# in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. +# +# +# +# +# +# +# +# A tight axis-aligned bounding box about the grid. +# +# +# +# For atom probe should be set to true. +# +# +# +# +# Integer which specifies the first index to be used for distinguishing +# hexahedra. Identifiers are defined either implicitly or explicitly. +# For implicit indexing the identifiers are defined on the interval +# :math:`[identifier\_offset, identifier\_offset + c - 1]`. +# For explicit indexing the identifier array has to be defined. +# +# +# +# +# +# Integer which specifies the first index to be used for distinguishing +# identifiers for vertices. Identifiers are defined either implicitly or explicitly. +# For implicit indexing the identifiers are defined on the interval +# :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array +# has to be defined. +# +# +# +# +# Integer which specifies the first index to be used for distinguishing +# identifiers for faces. Identifiers are defined either implicitly or explicitly. +# For implicit indexing the identifiers are defined on the interval +# :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array +# has to be defined. +# +# +# +# +# Positions of the vertices. +# Users are encouraged to reduce the vertices to unique set of positions +# and vertices as this supports a more efficient storage of the geometry data. +# It is also possible though to store the vertex positions naively in which +# case vertices_are_unique is likely False. +# Naively here means that one for example stores each vertex of a triangle +# mesh even though many vertices are shared between triangles and thus +# the positions of these vertices do not have to be duplicated. +# +# +# +# +# +# +# +# +# Array of identifiers from vertices which describe each face. +# +# The first entry is the identifier of the start vertex of the first face, +# followed by the second vertex of the first face, until the last vertex +# of the first face. Thereafter, the start vertex of the second face, the +# second vertex of the second face, and so on and so forth. +# +# Therefore, summating over the number_of_vertices, allows to extract +# the vertex identifiers for the i-th face on the following index interval +# of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. +# +# +# +# +# +# +# +# +# Six equally formatted sextets chained together. For each sextett the first entry is an +# XDMF primitive topology key (here 5 for polygon), the second entry the XDMF +# primitive count value (here 4 because each face is a quad). +# The remaining four values are the vertex indices. +# +# +# +# +# +# +# +# How many distinct boundaries are distinguished? +# Most grids discretize a cubic or cuboidal region. In this case +# six sides can be distinguished, each making an own boundary. +# +# +# +# +# Name of the boundaries. E.g. left, right, front, back, bottom, top, +# The field must have as many entries as there are number_of_boundaries. +# +# +# +# +# +# +# +# The boundary conditions for each boundary: +# +# 0 - undefined +# 1 - open +# 2 - periodic +# 3 - mirror +# 4 - von Neumann +# 5 - Dirichlet +# +# +# +# +# +# +# +# +# +# +# The result of the delocalization :math:`\Phi = f(x, y, z)` based on which subsequent iso-surfaces +# will be computed. In commercial software so far there is no possibility to export this information. +# +# If the intensity for all matches of the weighting_model are summarized name this NXdata instance +# scalar_field_magn_total. +# +# If the intensity is reported for each iontype one can avoid many subsequent +# computations as individual intensities can be reinterpreted using a different weighting_model in +# down-stream usage of the here reported values (e.g. with Python scripting). +# In this case name the individual NXdata instances scalar_field_magn_ionID using the ID of the ion as +# per the configuration of the ranging definitions used. +# +# +# +# +# +# +# +# +# +# The actual delocalized intensity values. +# +# +# +# +# +# +# +# +# +# Cell center of mass positions along x. +# +# +# +# +# +# +# +# Cell center of mass positions along y. +# +# +# +# +# +# +# +# Cell center of mass positions along z. +# +# +# +# +# +# +# +# Intensity of the field at given point +# +# +# +# +# +# +# +# Center of mass positions of each voxel for rendering the scalar field +# via XDMF in e.g. Paraview. +# +# +# +# +# +# +# +# +# XDMF topology for rendering in combination with xdmf_xyz the scalar field +# via XDMF in e.g. Paraview. +# +# +# +# +# +# +# +# +# The three-dimensional gradient :math:`\nabla \Phi`. +# Follow the naming convention of scalar_field_magn_SUFFIX to report parallel structures. +# +# +# +# +# +# +# +# +# +# The actual point-wise component values. +# +# +# +# +# +# +# +# +# +# +# Cell center of mass positions along x. +# +# +# +# +# +# +# +# Cell center of mass positions along y. +# +# +# +# +# +# +# +# Cell center of mass positions along z. +# +# +# +# +# +# +# +# The gradient vector formatted for direct visualization via XDMF in e.g. +# Paraview. +# +# +# +# +# +# +# +# +# Center of mass positions of each voxel for rendering the scalar field gradient +# via XDMF in e.g. Paraview. +# +# +# +# +# +# +# +# +# XDMF topology for rendering in combination with xdmf_xyz the scalar field +# via XDFM in e.g. Paraview. +# +# +# +# +# +# +# +# +# +# An iso-surface is the boundary between two regions across which the magnitude of a +# scalar field falls below/exceeds a threshold magnitude :math:`\varphi`. +# +# For applications in atom probe microscopy, the location and shape of such a boundary (set) +# is typically approximated by discretization - triangulation to be specific. +# +# This yields a complex of not necessarily connected geometric primitives. +# Paraprobe-nanochem approximates this complex with a soup of triangles. +# +# +# +# +# The threshold or iso-contour value :math:`\varphi`. +# +# +# +# +# Details about the specific marching cubes algorithm that was used for computing +# the iso-surface. +# +# +# +# Reference to the specific implementation of marching cubes used. +# The value placed here should be a DOI. If there are no specific +# DOI or details write not_further_specified, or give at least a +# free-text description. The program and version used is the +# specific paraprobe-nanochem. +# +# +# +# +# +# The resulting triangle soup computed via marching cubes. +# +# +# +# +# +# Integer which specifies the first index to be used for distinguishing triangles. +# Identifiers are defined either implicitly or explicitly. For implicit indexing the +# identifiers are defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. +# +# +# +# +# +# +# +# +# +# Positions of the vertices. +# +# Users are encouraged to reduce the vertices to a unique set as this may +# result in a more efficient storage of the geometry data. +# It is also possible though to store the vertex positions naively in which +# case vertices_are_unique is likely False. Naively here means that each +# vertex is stored even though many share the same positions. +# +# +# +# +# +# +# +# +# Array of identifiers from vertices which describe each face. +# +# The first entry is the identifier of the start vertex of the first face, +# followed by the second vertex of the first face, until the last vertex +# of the first face. Thereafter, the start vertex of the second face, the +# second vertex of the second face, and so on and so forth. +# +# Therefore, summating over the number_of_vertices, allows to extract +# the vertex identifiers for the i-th face on the following index interval +# of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. +# +# +# +# +# +# +# +# A list of as many tuples of XDMF topology key, XDMF number +# of vertices and a triple of vertex indices specifying each +# triangle. The total number of entries is n_f_tri * (1+1+3). +# +# +# +# +# +# +# +# +# Direction of each normal. +# +# +# +# +# +# +# +# +# Qualifier how which specifically oriented normal to its +# primitive each normal represents. +# +# * 0 - undefined +# * 1 - outer +# * 2 - inner +# +# +# +# +# +# +# +# +# +# +# Direction of each normal. +# +# +# +# +# +# +# +# +# Qualifier how which specifically oriented normal to its +# primitive each normal represents. +# +# * 0 - undefined +# * 1 - outer +# * 2 - inner +# +# +# +# +# +# +# +# Triangle normals are oriented in the direction of the +# gradient vector of the local delocalized scalar field. +# :math:`\sum_{x, y, z} {\nabla{c}_i}^2`. +# +# +# +# +# +# +# +# +# Triangle normals are oriented in the direction of the +# gradient vector of the local delocalized scalar field. +# The projection variable here describes the cosine of the +# angle between the gradient direction and the normal +# direction vector. +# This is a descriptor of how parallel the projection is +# that is especially useful to document those triangles +# for whose the projection is almost perpendicular. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Array of edge length values. For each triangle the edge length +# is reported for the edges traversed according to the sequence +# in which vertices are indexed in triangles. +# +# +# +# +# +# +# +# +# Array of interior angle values. For each triangle the angle +# is reported for the angle opposite to the edges which are +# traversed according to the sequence in which vertices +# are indexed in triangles. +# +# +# +# +# +# +# +# +# The center of mass of each triangle. +# +# +# +# +# +# +# +# +# Iso-surfaces of arbitrary scalar three-dimensional fields can show a complicated topology. +# Paraprobe-nanochem can run a DBScan-like clustering algorithm which performs a +# connectivity analysis on the triangle soup representation of such iso-surface. +# This may yield a set of connected features whose individual surfaces are discretized +# by a triangulated mesh each. Such volumetric features can be processed further using +# paraprobe-nanochem using a workflow with at most two steps. +# +# In the first step, the tool distinguishes three types of (v) i.e. volumetric features: +# +# 1. So-called objects, i.e. necessarily watertight features represented by polyhedra. +# These objects were already watertight within the triangulated iso-surface. +# 2. So-called proxies, i.e. features that were not necessarily watertight within the triangulated +# iso-surface but were subsequently replaced by a watertight mesh using polyhedral mesh +# processing operations (hole filling, refinement, fairing operations). +# 3. Remaining triangle surface meshes or parts of these of arbitrary shape and cardinality +# that are not transformable into proxies or for which no transformation into proxies was +# instructed. +# +# These features can be interpreted as microstructural features. Some of them may be precipitates, +# some of them may be poles, some of them may be segments of dislocation lines or other +# crystal defects which are decorated (or not) with solutes. +# +# In the second step, the tool can be used to analyze the proximity of these objects to a +# model of the surface (edge) of the dataset. +# +# +# +# The identifier which the triangle_soup connectivity analysis +# returned, which constitutes the first step of the +# volumetric_feature identification process. +# +# +# +# +# +# +# +# The array of keywords of feature_type dictionary. +# +# +# +# +# +# +# +# The array of values for each keyword of the +# feature_type dictionary. +# +# +# +# +# +# +# +# The array of controlled keywords, need to be from +# feature_type_dict_keyword, which specify which type +# each feature triangle cluster belongs to. +# Keep in mind that not each feature is an object or proxy. +# +# +# +# +# +# +# +# The explicit identifier of features. +# +# +# +# +# +# +# +# In all situations instances of the parent NXprocess group are returned with a very similar +# information structuring and thus we here replace the template name FEATURE +# with one of the following types feature-specific group names: +# +# * objects, objects, irrespective their distance to the surface +# * objects_close_to_edge, sub-set of v_feature_object close surface +# * objects_far_from_edge, sub-set of v_feature_object not close to the surface +# * proxies, proxies, irrespective their distance to the surface +# * proxies_close_to_edge, sub-set of v_feature_proxies, close to surface +# * proxies_far_from_edge, sub-set of v_feature_proxies, not close to surface +# +# +# +# Explicit identifier of the feature a sub-set of the feature_identifier in the +# parent group. +# +# +# +# +# +# +# +# Volume of the feature. NaN for non-watertight objects. +# +# +# +# +# +# +# +# An oriented bounding box (OBB) to each object. +# +# +# +# Edge length of the oriented bounding box from largest to smallest value. +# +# +# +# +# +# +# +# +# Oriented bounding box aspect ratio. +# YX versus ZY or second-largest over largest and smallest over second largest. +# +# +# +# +# +# +# +# +# Position of the geometric center, which often is but +# not necessarily has to be the center_of_mass of the +# hexahedrally-shaped sample/sample part. +# +# +# +# +# +# +# +# +# A simple approach to describe the entire set of hexahedra when the main intention +# is to store the shape of the hexahedra for visualization. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Array of evaporation_identifier / ion_identifier which details which ions +# lie inside or on the surface of the feature. +# +# +# +# +# +# +# +# +# +# +# Total (count) of ions inside or on the surface of the feature relevant for normalization. +# NaN for non watertight objects. +# +# +# +# +# +# +# +# +# +# +# +# +# Count or weight which, when divided by total, yields the composition of this element, +# nuclide, or (molecular) ion within the volume of the feature/object. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The multiplicity whereby the ion position is accounted for +# irrespective whether the ion is considered as a decorator +# of the interface or not. +# As an example, with atom probe it is typically not possible +# to resolve the positions of the atoms which arrive at the detector +# as molecular ions. Therefore, an exemplar molecular ion of two carbon +# atoms can be considered to have a multiplicity of two to account that +# this molecular ion contributes two carbon atoms at the reconstructed +# location considering that the spatial resolution of atom probe +# experiments is limited. +# +# +# +# +# +# +# +# The multiplicity whereby the ion position is accounted for when +# the ion is considered one which is a decorator of the interface. +# +# +# +# +# +# +# +# The equation of the plane that is fitted initially. +# +# +# +# The four parameter :math:`ax + by + cz + d = 0` which define the plane. +# +# +# +# +# +# +# +# +# The triangle surface mesh representing the interface model. +# Exported at state before or after the next DCOM step. +# +# +# +# Was this state exported before or after the next DCOM step. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of each vertex normal. +# +# +# +# +# +# +# +# +# Qualifier which details how specifically oriented the +# face normal is with respect to its primitive (triangle): +# +# * 0 - undefined +# * 1 - outer +# * 2 - inner +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of each face normal. +# +# +# +# +# +# +# +# +# Qualifier which details how specifically oriented the +# face normal is with respect to its primitive (triangle): +# +# * 0 - undefined +# * 1 - outer +# * 2 - inner +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Array of edge length values. For each triangle the edge length is +# reported for the edges traversed according to the sequence +# in which vertices are indexed in triangles. +# +# +# +# +# +# +# +# +# Array of interior angle values. For each triangle the angle is +# reported for the angle opposite to the edges which are traversed +# according to the sequence in which vertices are indexed in triangles. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The ROIs are defined as cylinders for the computations. To visualize these we discretize +# them into regular n-gons. Using for instance 360-gons, i.e. a regular n-gon with 360 edges, +# resolves the lateral surface of each cylinder such that their renditions are smooth in +# visualization software like Paraview. +# +# +# +# +# +# Position of the geometric center, which often is but not +# necessarily has to be the center_of_mass of the polyhedra. +# +# +# +# +# +# +# +# +# The orientation of the ROI defined via a vector which points along +# the cylinder axis and whose length is the height of the cylinder. +# +# +# +# +# +# +# +# +# +# XDMF support to enable colouring each ROI by its identifier. +# +# +# +# +# +# +# +# XDMF support to enable colouring each ROI whether it has edge contact or not. +# +# +# +# +# +# +# +# XDMF support to enable colouring each ROI by its number of atoms. +# +# +# +# +# +# +# +# XDMF support to enable colouring each ROI by its number of ions. +# +# +# +# +# +# +# +# Distance and iontype-specific processed data for each ROI. +# Arrays signed_distance and nuclide_hash are sorted by increasing +# distance. +# Array nuclide_hash reports one hash for each atom of each isotope. +# Effectively, this can yield to groups of values on signed_distance +# with the same distance value as molecular ions are reported decomposed +# into their atoms. +# Therefore, the XDMF support fields number_of_atoms and number_of_ions +# are only expected to display pairwise the same values respectively, +# if all ions are built from a single atom only. +# +# +# +# +# Sorted in increasing order projected along the positive direction +# of the ROI as defined by orientation in the parent group. +# +# +# +# +# +# +# +# Hashvalue as defined in :ref:`NXion`. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# If used, metadata of at least the person who performed this analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml index a55de39968..5c625dc126 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml @@ -14,13 +14,15 @@ symbols: type: group NXapm_paraprobe_ranger_config(NXobject): (NXentry): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] definition(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR enumeration: [NXapm_paraprobe_ranger_config] + # tool-specific range(NXapm_paraprobe_tool_config): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] (NXidentifier): exists: optional analysis_identifier(NX_UINT): @@ -38,6 +40,7 @@ NXapm_paraprobe_ranger_config(NXobject): checksum(NX_CHAR): algorithm(NX_CHAR): ranging_definitions(NX_CHAR): + # filter spatial_filter(NXspatial_filter): windowing_method(NX_CHAR): @@ -66,14 +69,16 @@ NXapm_paraprobe_ranger_config(NXobject): orientation(NX_NUMBER): polyhedron_set(NXcg_polyhedron_set): exists: optional - # TODO + + # TODO bitmask(NXcs_filter_boolean_mask): exists: optional number_of_objects(NX_UINT): bitdepth(NX_UINT): mask(NX_UINT): + # leave open if scalar or matrix - # dim: (i,) + # dim: (i,) identifier(NX_UINT): evaporation_id_filter(NXsubsampling_filter): exists: optional @@ -86,132 +91,381 @@ NXapm_paraprobe_ranger_config(NXobject): exists: optional method(NX_CHAR): match(NX_NUMBER): - - # tool-specific parameter + + # tool-specific parameter # molecular_ion_search(NXapm_paraprobe_tool_config): - # exists: ['min', '0', 'max', 'unbounded'] - # # extent if needed - # assumed_composition_isotopes(NX_UINT): - # exists: optional - # doc: | - # A list of pairs of number of protons and either the value 0 (per row) - # or the mass number for all those isotopes which are assumed present - # in a virtual specimen. - # The purpose of this field is to compute also composition-weighted - # products to yield a simple estimation which could potentially help - # scientists to judge if certain molecular ions are to be expected. - # The corresponding setting store_composition_weighted_product should be - # activated. - # unit: NX_UNITLESS - # dim: (n_composition, 2) - # assumed_composition_value(NX_FLOAT): - # doc: | - # A list of atomic (at.-%) ! percent values for the composition of each - # isotope in the virtual specimen following the sequence of - # assumed_composition_isotopes. - # unit: NX_DIMENSIONLESS - # dim: (n_compositions,) - # isotope_whitelist(NX_UINT): - # doc: | - # A list of pairs of number of protons and mass number for all isotopes - # to consider that can be composed into (molecular) ions, during the - # recursive molecular_ion_search. - # unit: NX_UNITLESS - # dim: (n_nuclids, 2) - # mass_to_charge_interval(NX_FLOAT): - # doc: | - # The mass-to-charge-state ratio interval in which - # all molecular ions are searched. - # unit: NX_ANY # u - # dim: (2,) - # maximum_charge(NX_UINT): - # doc: | - # The maximum charge that a molecular ion should have. - # unit: NX_UNITLESS - # maximum_number_of_isotopes(NX_UINT): - # doc: | - # The maximum number of isotopes of which the molecular ion - # should be composed. Currently this must not be larger than 32. - - # Users should be warned that the larger the maximum_charge and - # especially the larger the maximum_number_of_isotopes is chosen, - # the eventually orders of magnitude more costly the search becomes. - - # This is because paraprobe-ranger computes really all (at least) - # theoretically possible combinations that would have likely a - # mass-to-charge-state ratio in the specified mass_to_charge_interval. - # It is the challenge in atom probe to judge which of these (molecular) - # ions are feasible and also practically possible. This tool does not - # answer this question. - - # Namely, which specific molecular ion will evaporate, remain stable - # during flight and becomes detected is a complicated and in many cases - # not yet in detail understood phenomenon. The ab-initio conditions - # before and during launch, the local environment, arrangement and field - # as well as the flight phase in an evacuated but not analysis chamber - # with a complex electrical field, eventual laser pulsing in place, - # temperature and remaining atoms or molecules all can have an effect - # which iontypes are really physically evaporating and detected. - # unit: NX_UNITLESS - # store_atomic_mass_sum(NX_BOOLEAN): - # doc: | - # Report the accumulated atomic mass from each isotope building the ion. - # Accounts for each identified ion. Relatistic effects are not accounted for. - # store_natural_abundance_product(NX_BOOLEAN): - # doc: | - # Report the product of the natural abundances from each isotope building - # the ion. Accounts for each identified ion. - - # The value zero indicates it is not possible to build such molecular ion - # from nuclids which are all observationally stable. - # Very small values can give an idea/about how likely such a molecular ion - # is expected to form assuming equal probabilities. - - # However in atom probe experiments this product has to be modified - # by the (spatially-correlated) local composition in the region from - # which the ions launch because the formation of a molecular ion depends - # as summarized under maximum_number_of_isotopes on the specific - # quantum-mechanical configuration and field state upon launch - # or/and (early state) of flight respectively. - # We are aware that this modified product can have a substantially - # different value than the natural_abundance_product. - - # Natural abundancies folded with the estimated compositions of the - # specimen can differ by orders of magnitude. - # # add assumed composition of the specimen - # store_composition_weighted_product(NX_BOOLEAN): - # doc: | - # Report the product of the composition from each isotope building the - # ion. This sets strong constraints on the molecular ions which are - # expected to have at all a noteworthy product value. - # It should not be forgotten though the computation relies on assumptions: - - # * The composition is homogeneous within the virtual specimen. - # * It is a priori known which nuclids the specimen is build of. - - # store_charge_state(NX_BOOLEAN): - # doc: | - # Report the charge state of the ions. - # store_disjoint_isotopes(NX_BOOLEAN): - # doc: | - # Report if identified ions should be characterized wrt to their number of disjoint isotopes. + # exists: ['min', '0', 'max', 'unbounded'] + # extent if needed + # assumed_composition_isotopes(NX_UINT): + # exists: optional + # doc: | + # A list of pairs of number of protons and either the value 0 (per row) + # or the mass number for all those isotopes which are assumed present + # in a virtual specimen. + # The purpose of this field is to compute also composition-weighted + # products to yield a simple estimation which could potentially help + # scientists to judge if certain molecular ions are to be expected. + # The corresponding setting store_composition_weighted_product should be + # activated. + # unit: NX_UNITLESS + # dim: (n_composition, 2) + # assumed_composition_value(NX_FLOAT): + # doc: | + # A list of atomic (at.-%) ! percent values for the composition of each + # isotope in the virtual specimen following the sequence of + # assumed_composition_isotopes. + # unit: NX_DIMENSIONLESS + # dim: (n_compositions,) + # isotope_whitelist(NX_UINT): + # doc: | + # A list of pairs of number of protons and mass number for all isotopes + # to consider that can be composed into (molecular) ions, during the + # recursive molecular_ion_search. + # unit: NX_UNITLESS + # dim: (n_nuclids, 2) + # mass_to_charge_interval(NX_FLOAT): + # doc: | + # The mass-to-charge-state ratio interval in which + # all molecular ions are searched. + # unit: NX_ANY # u + # dim: (2,) + # maximum_charge(NX_UINT): + # doc: | + # The maximum charge that a molecular ion should have. + # unit: NX_UNITLESS + # maximum_number_of_isotopes(NX_UINT): + # doc: | + # The maximum number of isotopes of which the molecular ion + # should be composed. Currently this must not be larger than 32. + + # Users should be warned that the larger the maximum_charge and + # especially the larger the maximum_number_of_isotopes is chosen, + # the eventually orders of magnitude more costly the search becomes. + + # This is because paraprobe-ranger computes really all (at least) + # theoretically possible combinations that would have likely a + # mass-to-charge-state ratio in the specified mass_to_charge_interval. + # It is the challenge in atom probe to judge which of these (molecular) + # ions are feasible and also practically possible. This tool does not + # answer this question. + + # Namely, which specific molecular ion will evaporate, remain stable + # during flight and becomes detected is a complicated and in many cases + # not yet in detail understood phenomenon. The ab-initio conditions + # before and during launch, the local environment, arrangement and field + # as well as the flight phase in an evacuated but not analysis chamber + # with a complex electrical field, eventual laser pulsing in place, + # temperature and remaining atoms or molecules all can have an effect + # which iontypes are really physically evaporating and detected. + # unit: NX_UNITLESS + # store_atomic_mass_sum(NX_BOOLEAN): + # doc: | + # Report the accumulated atomic mass from each isotope building the ion. + # Accounts for each identified ion. Relatistic effects are not accounted for. + # store_natural_abundance_product(NX_BOOLEAN): + # doc: | + # Report the product of the natural abundances from each isotope building + # the ion. Accounts for each identified ion. + + # The value zero indicates it is not possible to build such molecular ion + # from nuclids which are all observationally stable. + # Very small values can give an idea/about how likely such a molecular ion + # is expected to form assuming equal probabilities. + + # However in atom probe experiments this product has to be modified + # by the (spatially-correlated) local composition in the region from + # which the ions launch because the formation of a molecular ion depends + # as summarized under maximum_number_of_isotopes on the specific + # quantum-mechanical configuration and field state upon launch + # or/and (early state) of flight respectively. + # We are aware that this modified product can have a substantially + # different value than the natural_abundance_product. + + # Natural abundancies folded with the estimated compositions of the + # specimen can differ by orders of magnitude. + # add assumed composition of the specimen + # store_composition_weighted_product(NX_BOOLEAN): + # doc: | + # Report the product of the composition from each isotope building the + # ion. This sets strong constraints on the molecular ions which are + # expected to have at all a noteworthy product value. + # It should not be forgotten though the computation relies on assumptions: + + # * The composition is homogeneous within the virtual specimen. + # * It is a priori known which nuclids the specimen is build of. + + # store_charge_state(NX_BOOLEAN): + # doc: | + # Report the charge state of the ions. + # store_disjoint_isotopes(NX_BOOLEAN): + # doc: | + # Report if identified ions should be characterized wrt to their number of disjoint isotopes. # check_existent_ranging(NXapm_paraprobe_tool_config): - # exists: ['min', '0', 'max', '1'] - # ranging(NXserialized): - # type(NX_CHAR): - # path(NX_CHAR): - # checksum(NX_CHAR): - # algorithm(NX_CHAR): - # ranging_definitions(NX_CHAR): - common(NXapm_paraprobe_tool_common): + # exists: ['min', '0', 'max', '1'] + # ranging(NXserialized): + # type(NX_CHAR): + # path(NX_CHAR): + # checksum(NX_CHAR): + # algorithm(NX_CHAR): + # ranging_definitions(NX_CHAR): + common(NXapm_paraprobe_tool_common): status(NX_CHAR): programID(NXprogram): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR profiling(NXcs_profiling): exists: recommended start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): total_elapsed_time(NX_FLOAT): current_working_directory(NX_CHAR): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 45a4ba9f9e05881d05976166bfad4eccafbd61896ef7e049dc30f4457cd69bb8 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The number of isotopes to consider as building blocks for searching molecular +# ions. +# +# +# +# +# The number of compositions to consider for molecular ion search tasks. +# +# +# +# +# Application definition for a configuration file of the paraprobe-ranger tool. +# +# This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml index 26653e1ea2..94c0a37ec0 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml @@ -14,10 +14,12 @@ symbols: type: group NXapm_paraprobe_ranger_results(NXobject): (NXentry): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] definition(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR enumeration: [NXapm_paraprobe_ranger_results] + # tasks iontypes(NXapm_paraprobe_tool_results): doc: | @@ -25,15 +27,17 @@ NXapm_paraprobe_ranger_results(NXobject): ion on which iontype it matches. If it matches on None, the ion is considered of the default *unknown_type*. This iontype is marked with a 0 in the iontypes array. - ##MK::number_of_ion_types(NX_POSINT): + + #MK::number_of_ion_types(NX_POSINT): # config window(NXcs_filter_boolean_mask): number_of_ions(NX_UINT): bitdepth(NX_UINT): mask(NX_UINT): + # results (NXion): - exists: [min, 1, max, 256] + exists: ['min', '1', 'max', '256'] nuclide_hash(NX_UINT): nuclide_list(NX_UINT): exists: recommended @@ -42,6 +46,7 @@ NXapm_paraprobe_ranger_results(NXobject): name(NX_CHAR): exists: optional iontypes(NX_UINT): + unit: NX_UNITLESS doc: | The iontype (identifier) for each ion that was best matching, stored in the order of the evaporation sequence ID. The here computed iontypes @@ -49,9 +54,10 @@ NXapm_paraprobe_ranger_results(NXobject): equivalent to interpreting a RNG and RRNG range files for each ion in such a way that only the those elements are considered of which a (molecular) ion is assumed composed according to the NXion instances. - unit: NX_UNITLESS - dim: (n_ions,) - common(NXapm_paraprobe_tool_common): + dimensions: + rank: 1 + dim: [[1, n_ions]] + common(NXapm_paraprobe_tool_common): status(NX_CHAR): analysis_identifier(NX_UINT): config(NXserialized): @@ -60,34 +66,183 @@ NXapm_paraprobe_ranger_results(NXobject): checksum(NX_CHAR): algorithm(NX_CHAR): programID(NXprogram): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR profiling(NXcs_profiling): exists: recommended start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): - total_elapsed_time(NX_FLOAT): + total_elapsed_time(NX_FLOAT): current_working_directory(NX_CHAR): number_of_processes(NX_POSINT): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): userID(NXuser): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] doc: | If used, metadata of at least the person who performed this analysis. name(NX_CHAR): coordinate_system_set(NXcoordinate_system_set): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] paraprobe(NXcoordinate_system): type(NX_CHAR): handedness(NX_CHAR): x(NX_NUMBER): unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] y(NX_NUMBER): unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] z(NX_NUMBER): unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# c1d94f5a0a8eaeb2f4b3b58747c3382a7c43555a47c504e2a4492b28262e398f +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The total number of ions in the reconstructed volume. +# +# +# +# +# Application definition for results files of the paraprobe-ranger tool. +# +# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. +# The purpose and need of the paraprobe-ranger tool is to apply a given set of ranging definitions within +# a certain (possibly complicated) selection of ions (based on their properties or location in the +# reconstructed volume. +# +# +# +# +# +# +# +# +# +# +# +# Paraprobe-ranger loads the iontypes and evaluates for each +# ion on which iontype it matches. If it matches on None, the +# ion is considered of the default *unknown_type*. This iontype +# is marked with a 0 in the iontypes array. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The iontype (identifier) for each ion that was best matching, stored +# in the order of the evaporation sequence ID. The here computed iontypes +# do not take into account the charge state of the ion which is +# equivalent to interpreting a RNG and RRNG range files for each +# ion in such a way that only the those elements are considered of which +# a (molecular) ion is assumed composed according to the NXion instances. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# If used, metadata of at least the person who performed this analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml index 32c812985d..8dbf3aaa11 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml @@ -9,12 +9,13 @@ symbols: type: group NXapm_paraprobe_selector_config(NXobject): (NXentry): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] definition(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR enumeration: [NXapm_paraprobe_selector_config] select(NXapm_paraprobe_tool_config): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] (NXidentifier): exists: optional analysis_identifier(NX_UINT): @@ -32,6 +33,7 @@ NXapm_paraprobe_selector_config(NXobject): checksum(NX_CHAR): algorithm(NX_CHAR): ranging_definitions(NX_CHAR): + # filter that represent here also the tool-specific config spatial_filter(NXspatial_filter): windowing_method(NX_CHAR): @@ -60,14 +62,16 @@ NXapm_paraprobe_selector_config(NXobject): orientation(NX_NUMBER): polyhedron_set(NXcg_polyhedron_set): exists: optional - # TODO + + # TODO bitmask(NXcs_filter_boolean_mask): exists: optional number_of_objects(NX_UINT): bitdepth(NX_UINT): mask(NX_UINT): + # leave open if scalar or matrix - # dim: (i,) + # dim: (i,) identifier(NX_UINT): evaporation_id_filter(NXsubsampling_filter): exists: optional @@ -80,15 +84,144 @@ NXapm_paraprobe_selector_config(NXobject): exists: optional method(NX_CHAR): match(NX_NUMBER): - common(NXapm_paraprobe_tool_common): + common(NXapm_paraprobe_tool_common): status(NX_CHAR): programID(NXprogram): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR profiling(NXcs_profiling): exists: recommended start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): total_elapsed_time(NX_FLOAT): current_working_directory(NX_CHAR): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 548e90a53cb2e0a75151ca12521ce2d822634a0d610ccda5d2e5469d8311afce +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Application definition for a configuration file of the paraprobe-selector tool. +# +# This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml index e830ccdd94..3f03033235 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml @@ -14,18 +14,21 @@ symbols: type: group NXapm_paraprobe_selector_results(NXobject): (NXentry): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] definition(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR enumeration: [NXapm_paraprobe_selector_results] + # tasks roi(NXapm_paraprobe_tool_results): + # results window(NXcs_filter_boolean_mask): number_of_ions(NX_UINT): bitdepth(NX_UINT): mask(NX_UINT): - common(NXapm_paraprobe_tool_common): + common(NXapm_paraprobe_tool_common): status(NX_CHAR): analysis_identifier(NX_UINT): config(NXserialized): @@ -34,9 +37,10 @@ NXapm_paraprobe_selector_results(NXobject): checksum(NX_CHAR): algorithm(NX_CHAR): programID(NXprogram): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR profiling(NXcs_profiling): exists: recommended start_time(NX_DATE_TIME): @@ -47,21 +51,141 @@ NXapm_paraprobe_selector_results(NXobject): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): userID(NXuser): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] doc: | If used, metadata of at least the person who performed this analysis. name(NX_CHAR): coordinate_system_set(NXcoordinate_system_set): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] paraprobe(NXcoordinate_system): type(NX_CHAR): handedness(NX_CHAR): x(NX_NUMBER): unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] y(NX_NUMBER): unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] z(NX_NUMBER): unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# b529eb9b3658a196bca7ba97b734fd740d0d9e3070dba13dcd9c90ea935ca755 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The total number of ions in the reconstruction. +# +# +# +# +# Application definition for results files of the paraprobe-selector tool. +# +# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. +# The purpose and need of the paraprobe-selector tool is to identify which reconstructed positions +# are located inside or on the surface of a (possibly complicated) region-of-interest (ROI). +# In addition, the tool allows to filter ions for properties. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# If used, metadata of at least the person who performed this analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml index 247f87f811..8056293ffb 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml @@ -15,16 +15,17 @@ symbols: type: group NXapm_paraprobe_spatstat_config(NXobject): (NXentry): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] definition(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR enumeration: [NXapm_paraprobe_spatstat_config] number_of_tasks(NX_UINT): + unit: NX_UNITLESS doc: | How many spatial_statistics tasks should the tool execute. - unit: NX_UNITLESS spatial_statisticsID(NXapm_paraprobe_tool_config): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] (NXidentifier): exists: optional analysis_identifier(NX_UINT): @@ -52,6 +53,7 @@ NXapm_paraprobe_spatstat_config(NXobject): algorithm(NX_CHAR): distance(NX_CHAR): edge_distance(NX_FLOAT): + unit: NX_LENGTH doc: | Threshold to define how far an ion has to lay at least from the edge of the dataset so that the ion can act as a source. This means that @@ -63,7 +65,6 @@ NXapm_paraprobe_spatstat_config(NXobject): The threshold is useful to process the dataset such that ROIs do not protrude out of the dataset as this would add bias. - unit: NX_LENGTH feature_distance(NXserialized): exists: optional doc: | @@ -81,6 +82,7 @@ NXapm_paraprobe_spatstat_config(NXobject): Absolute path in the (HDF5) file which points to the distance of each ion to the closest feature. feature_distance(NX_FLOAT): + unit: NX_LENGTH doc: | Threshold to define how close an ion has to lay to a feature so that the ion can at all qualify as a source, i.e. that an ROI is placed @@ -89,7 +91,6 @@ NXapm_paraprobe_spatstat_config(NXobject): Recall that this feature_distance threshold is used in combination with the edge_distance threshold when placing ROI about source ions. - unit: NX_LENGTH spatial_filter(NXspatial_filter): windowing_method(NX_CHAR): hexahedron_set(NXcg_hexahedron_set): @@ -117,15 +118,17 @@ NXapm_paraprobe_spatstat_config(NXobject): orientation(NX_NUMBER): polyhedron_set(NXcg_polyhedron_set): exists: optional - # TODO + + # TODO bitmask(NXcs_filter_boolean_mask): exists: optional number_of_objects(NX_UINT): bitdepth(NX_UINT): mask(NX_UINT): - # leave open if scalar or matrix - # dim: (i,) - # identifier(NX_UINT): + + # leave open if scalar or matrix + # dim: (i,) + # identifier(NX_UINT): evaporation_id_filter(NXsubsampling_filter): exists: optional min_incr_max(NX_INT): @@ -137,6 +140,7 @@ NXapm_paraprobe_spatstat_config(NXobject): exists: optional method(NX_CHAR): match(NX_NUMBER): + # config randomize_iontypes(NX_BOOLEAN): doc: | @@ -184,6 +188,7 @@ NXapm_paraprobe_spatstat_config(NXobject): often it is accounted for. enumeration: [resolve_all, resolve_unknown, resolve_ion, resolve_element, resolve_isotope] ion_query_nuclide_source(NX_UINT): + unit: NX_UNITLESS doc: | Matrix of isotope vectors, as many as rows as different candidates for iontypes should be distinguished as possible source iontypes. @@ -192,8 +197,9 @@ NXapm_paraprobe_spatstat_config(NXobject): Combined with ion_query_type_source set to resolve_element this will recover usual spatial correlation statistics like the 1NN C-C spatial statistics. - dim: (n_ion_source, n_ivec_max) - unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_ion_source], [2, n_ivec_max]] ion_query_type_target(NX_CHAR): doc: | Similarly as ion_query_type_source how should iontypes be interpreted @@ -205,52 +211,400 @@ NXapm_paraprobe_spatstat_config(NXobject): For details about the resolve values consider the explanations in ion_query_type_source. These account for ion_query_type_target as well. enumeration: [resolve_all, resolve_unknown, resolve_ion, resolve_element, resolve_isotope] - # NEW ISSUE: conditionally required only when resolve_isotope + + # NEW ISSUE: conditionally required only when resolve_isotope ion_query_nuclide_target(NX_UINT): + unit: NX_UNITLESS doc: | Matrix of isotope vectors, as many as rows as different candidates for iontypes to distinguish as possible targets. See additional comments under ion_query_isotope_vector_source. - dim: (n_ion_target, n_ivec_max) - unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_ion_target], [2, n_ivec_max]] statistics(NXprocess): doc: | Specifies which spatial statistics to compute. knn(NXprocess): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] doc: | Compute k-th nearest neighbour statistics. kth(NX_UINT): + unit: NX_UNITLESS doc: | Order k. - unit: NX_UNITLESS min_incr_max(NX_FLOAT): + unit: NX_LENGTH doc: | Minimum value, increment, and maximum value of the histogram binning. - unit: NX_LENGTH - # \@units: nm - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] rdf(NXprocess): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] doc: | Compute radial distribution function. min_incr_max(NX_FLOAT): + unit: NX_LENGTH doc: | Minimum value, increment, and maximum value of the histogram binning. - unit: NX_LENGTH - # \@units: nm - dim: (3,) - # NEW ISSUE: ripleyk(NXcollection): - # NEW ISSUE: two_point(NXcollection): - common(NXapm_paraprobe_tool_common): + dimensions: + rank: 1 + dim: [[1, 3]] + + # NEW ISSUE: ripleyk(NXcollection): + # NEW ISSUE: two_point(NXcollection): + common(NXapm_paraprobe_tool_common): status(NX_CHAR): programID(NXprogram): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR profiling(NXcs_profiling): exists: recommended start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): total_elapsed_time(NX_FLOAT): current_working_directory(NX_CHAR): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 82bf2486296668125a3b817eae99a1fc730e5e9c3599752ae5d9526d91456d5a +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Maximum number of atoms per molecular ion. Should be 32 for paraprobe. +# +# +# +# +# Number of different source iontypes to distinguish. +# +# +# +# +# Number of different target iontypes to distinguish. +# +# +# +# +# Application definition for a configuration file of the paraprobe-spatstat tool. +# +# This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. +# +# +# +# +# +# +# +# +# +# +# How many spatial_statistics tasks should the tool execute. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Distance between each ion and triangulated surface mesh. +# +# +# +# +# +# +# +# +# Threshold to define how far an ion has to lay at least from the edge +# of the dataset so that the ion can act as a source. This means that +# an ROI is placed at the location of the ion and its neighbors are +# analyzed how they contribute to the computed statistics. +# +# The edge_distance threshold can be combined with the feature_distance threshold. This threshold defines defines up to which distance to a +# microstructural feature an ROI is placed. +# +# The threshold is useful to process the dataset such that ROIs do +# not protrude out of the dataset as this would add bias. +# +# +# +# +# +# Distance between each ion and triangulated mesh of microstructural features. +# In addition to spatial filtering and considering how far ions lie to the +# edge of the dataset, it is possible to restrict the analyses to a sub-set of +# ions within a distance not farther away to a feature than the feature_distance +# threshold value. +# +# +# +# +# +# +# +# Absolute path in the (HDF5) file which points to the distance of each +# ion to the closest feature. +# +# +# +# +# Threshold to define how close an ion has to lay to a feature so that +# the ion can at all qualify as a source, i.e. that an ROI is placed +# at the location of the ion and its neighbors are then analyzed +# how they contribute to the computed statistics. +# +# Recall that this feature_distance threshold is used in combination +# with the edge_distance threshold when placing ROI about source ions. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Specifies, if the iontypes are randomized for the point cloud or not. +# Internally, paraprobe uses a sequentially executed deterministic MT19987 +# (MersenneTwister) pseudo-random number generator to shuffle the +# iontypes randomly across the entire set of ions. That is the total +# number of ions of either type remain the same but the information about +# their location is randomized. +# +# +# +# +# +# +# +# +# +# How should the iontype be interpreted on the source-side, i.e. +# all these ion positions where a regions-of-interest (ROI) around +# so-called source ions will be placed. Different options exist +# how iontypes are interpreted given an iontype represents +# in general a (molecular) ion with different isotopes that have +# individually different multiplicity. +# +# The value resolve_all will set an ion active in the analysis regardless +# of which iontype it is. Each active ion is accounted for once. +# +# The value resolve_unknown will set an ion active when the ion is +# of the UNKNOWNTYPE type. Each active ion is accounted for once. +# +# The value resolve_ion will set an ion active if it is of the specific +# iontype, irregardless of its elemental or isotopic details. +# Each active ion is counted once. +# +# The value resolve_element will set an ion active, and most importantly, +# account for each as many times as the (molecular) ion contains +# atoms of elements in the whitelist ion_query_isotope_vector. +# +# The value resolve_isotope will set an ion active, and most importantly, +# account for each as many times as the (molecular) ion contains +# isotopes in the whitelist ion_query_isotope_vector. +# +# In effect, ion_query_isotope_vector acts as a whitelist to filter +# which ions are considered as source ions of the correlation statistics +# and how the multiplicity of each ion will be factorized, i.e. how +# often it is accounted for. +# +# +# +# +# +# +# +# +# +# +# +# Matrix of isotope vectors, as many as rows as different candidates +# for iontypes should be distinguished as possible source iontypes. +# In the simplest case, the matrix contains only the proton number +# of the element in the row, all other values set to zero. +# Combined with ion_query_type_source set to resolve_element this will +# recover usual spatial correlation statistics like the 1NN C-C +# spatial statistics. +# +# +# +# +# +# +# +# +# Similarly as ion_query_type_source how should iontypes be interpreted +# on the target-side, i.e. how many counts will be bookkept for ions +# which are neighbors of source ions within or on the surface of each +# inspection/ROI about each source ion. +# Source ion in the center of the ROI are not accounted for during +# counting the summary statistics. +# For details about the resolve values consider the explanations in +# ion_query_type_source. These account for ion_query_type_target as well. +# +# +# +# +# +# +# +# +# +# +# +# +# Matrix of isotope vectors, as many as rows as different candidates for +# iontypes to distinguish as possible targets. See additional comments +# under ion_query_isotope_vector_source. +# +# +# +# +# +# +# +# +# Specifies which spatial statistics to compute. +# +# +# +# Compute k-th nearest neighbour statistics. +# +# +# +# Order k. +# +# +# +# +# Minimum value, increment, and maximum value of the histogram binning. +# +# +# +# +# +# +# +# +# Compute radial distribution function. +# +# +# +# Minimum value, increment, and maximum value of the histogram binning. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml index 4a377bb4c3..412a52d090 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml @@ -15,19 +15,23 @@ symbols: type: group NXapm_paraprobe_spatstat_results(NXobject): (NXentry): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] definition(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR enumeration: [NXapm_paraprobe_spatstat_results] + # tasks spatial_statisticsID(NXapm_paraprobe_tool_results): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] window(NXcs_filter_boolean_mask): number_of_ions(NX_UINT): bitdepth(NX_UINT): mask(NX_UINT): + # results iontypes_randomized(NX_UINT): + unit: NX_UNITLESS doc: | The iontype ID for each ion that was assigned to each ion during the randomization of the ionlabels. Iontype labels are just permuted @@ -36,53 +40,70 @@ NXapm_paraprobe_spatstat_results(NXobject): The order matches the iontypes array from a given ranging results as it is specified in the configuration settings inside the specific config_filename that was used for this paraprobe-spatstat analysis. - unit: NX_UNITLESS - dim: (n_ions,) + dimensions: + rank: 1 + dim: [[1, n_ions]] knn(NXprocess): exists: optional doc: | K-nearest neighbor statistics. distance(NX_FLOAT): + unit: NX_LENGTH doc: | Right boundary of the binning. - unit: NX_LENGTH - dim: (n_knn,) + dimensions: + rank: 1 + dim: [[1, n_knn]] probability_mass(NX_FLOAT): unit: NX_DIMENSIONLESS - dim: (n_knn,) + dimensions: + rank: 1 + dim: [[1, n_knn]] cumulated(NX_FLOAT): + unit: NX_UNITLESS doc: | Cumulated not normalized by total counts. - unit: NX_UNITLESS - dim: (n_knn,) + dimensions: + rank: 1 + dim: [[1, n_knn]] cumulated_normalized(NX_FLOAT): + unit: NX_DIMENSIONLESS doc: | Cumulated and normalized by total counts. - unit: NX_DIMENSIONLESS - dim: (n_knn,) + dimensions: + rank: 1 + dim: [[1, n_knn]] rdf(NXprocess): exists: optional doc: | Radial distribution statistics. distance(NX_FLOAT): + unit: NX_LENGTH doc: | Right boundary of the binning. - unit: NX_LENGTH - dim: (n_rdf,) + dimensions: + rank: 1 + dim: [[1, n_rdf]] probability_mass(NX_FLOAT): unit: NX_DIMENSIONLESS - dim: (n_rdf,) + dimensions: + rank: 1 + dim: [[1, n_rdf]] cumulated(NX_FLOAT): + unit: NX_UNITLESS doc: | Cumulated not normalized by total counts. - unit: NX_UNITLESS - dim: (n_rdf,) + dimensions: + rank: 1 + dim: [[1, n_rdf]] cumulated_normalized(NX_FLOAT): + unit: NX_DIMENSIONLESS doc: | Cumulated and normalized by total counts. - unit: NX_DIMENSIONLESS - dim: (n_rdf,) - common(NXapm_paraprobe_tool_common): + dimensions: + rank: 1 + dim: [[1, n_rdf]] + common(NXapm_paraprobe_tool_common): status(NX_CHAR): analysis_identifier(NX_UINT): config(NXserialized): @@ -91,9 +112,10 @@ NXapm_paraprobe_spatstat_results(NXobject): checksum(NX_CHAR): algorithm(NX_CHAR): programID(NXprogram): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR profiling(NXcs_profiling): exists: recommended start_time(NX_DATE_TIME): @@ -104,21 +126,230 @@ NXapm_paraprobe_spatstat_results(NXobject): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): userID(NXuser): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] doc: | If used, metadata of at least the person who performed this analysis. name(NX_CHAR): coordinate_system_set(NXcoordinate_system_set): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] paraprobe(NXcoordinate_system): type(NX_CHAR): handedness(NX_CHAR): x(NX_NUMBER): unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] y(NX_NUMBER): unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] z(NX_NUMBER): unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 23c56b9160f3c0395fe85be1c18b9467fb32095a9e8f5fc884974281be8ba852 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The total number of ions in the reconstruction. +# +# +# +# +# The total number of bins in the histogram for the k-th nearest neighbor. +# +# +# +# +# The total number of bins in the histogram for the radial distribution function. +# +# +# +# +# Application definition for results files of the paraprobe-spatstat tool. +# +# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The iontype ID for each ion that was assigned to each ion during +# the randomization of the ionlabels. Iontype labels are just permuted +# but the total number of values for each iontype remain the same. +# +# The order matches the iontypes array from a given ranging results +# as it is specified in the configuration settings inside the specific +# config_filename that was used for this paraprobe-spatstat analysis. +# +# +# +# +# +# +# +# K-nearest neighbor statistics. +# +# +# +# Right boundary of the binning. +# +# +# +# +# +# +# +# +# +# +# +# +# Cumulated not normalized by total counts. +# +# +# +# +# +# +# +# Cumulated and normalized by total counts. +# +# +# +# +# +# +# +# +# Radial distribution statistics. +# +# +# +# Right boundary of the binning. +# +# +# +# +# +# +# +# +# +# +# +# +# Cumulated not normalized by total counts. +# +# +# +# +# +# +# +# Cumulated and normalized by total counts. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# If used, metadata of at least the person who performed this analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_config.yaml index 855783cac1..d4dcb9bfc6 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_config.yaml @@ -13,12 +13,13 @@ symbols: type: group NXapm_paraprobe_surfacer_config(NXobject): (NXentry): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] definition(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR enumeration: [NXapm_paraprobe_surfacer_config] surface_meshing(NXapm_paraprobe_tool_config): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] (NXidentifier): exists: optional analysis_identifier(NX_UINT): @@ -36,6 +37,7 @@ NXapm_paraprobe_surfacer_config(NXobject): checksum(NX_CHAR): algorithm(NX_CHAR): ranging_definitions(NX_CHAR): + # filter that are here tool-specific parameter spatial_filter(NXspatial_filter): windowing_method(NX_CHAR): @@ -64,14 +66,16 @@ NXapm_paraprobe_surfacer_config(NXobject): orientation(NX_NUMBER): polyhedron_set(NXcg_polyhedron_set): exists: optional - # TODO + + # TODO bitmask(NXcs_filter_boolean_mask): exists: optional number_of_objects(NX_UINT): bitdepth(NX_UINT): mask(NX_UINT): + # leave open if scalar or matrix - # dim: (i,) + # dim: (i,) identifier(NX_UINT): evaporation_id_filter(NXsubsampling_filter): exists: optional @@ -84,12 +88,13 @@ NXapm_paraprobe_surfacer_config(NXobject): exists: optional method(NX_CHAR): match(NX_NUMBER): + # config preprocessing(NXprocess): method(NX_CHAR): doc: | Specifies the method that is used to preprocess the point cloud - prior to the alpha-shape computation. + prior to the alpha-shape computation. The option *default* specifies that no such filtering is applied. The option *kuehbach* specifies that a Hoshen-Kopelman @@ -98,11 +103,11 @@ NXapm_paraprobe_surfacer_config(NXobject): in `M. Kühbach et al. `_. enumeration: [default, kuehbach] kernel_width(NX_UINT): + unit: NX_UNITLESS doc: | When using the kuehbach preprocessing, this is the width of the kernel for identifying which ions are in voxels close to the edge of the point cloud. - unit: NX_UNITLESS alpha_value_choice(NX_CHAR): doc: | Specifies which method to use to define the alpha value. @@ -132,19 +137,21 @@ NXapm_paraprobe_surfacer_config(NXobject): proximity constraints) on the resulting wrapping. enumeration: [convex_hull_naive, convex_hull_refine, smallest_solid, cgal_optimal, set_of_values, set_of_alpha_wrappings] alpha_values(NX_FLOAT): + unit: NX_ANY doc: | - Array of alpha values to use when alpha_value_choice is + Array of alpha values to use when alpha_value_choice is set_of_values or when alpha_value_choice is set_of_alpha_wrappings. - unit: NX_ANY - # \@units: nm^2 - dim: (n_alpha_values,) + dimensions: + rank: 1 + dim: [[1, n_alpha_values]] offset_values(NX_FLOAT): + unit: NX_LENGTH doc: | Array of offset values to use when alpha_value_choice is set_of_alpha_wrappings. The array of alpha_values and offset_values define a sequence of (alpha and offset value). - unit: NX_LENGTH - # \@units: nm - dim: (n_alpha_values,) + dimensions: + rank: 1 + dim: [[1, n_alpha_values]] has_exterior_facets(NX_BOOLEAN): doc: | Specifies if the tool should compute the set of exterior triangle facets @@ -157,16 +164,256 @@ NXapm_paraprobe_surfacer_config(NXobject): doc: | Specifies if the tool should compute all interior tetrahedra of the alpha complex (currently only for alpha shapes). - # NEW ISSUE: has_facet_appearance(NX_BOOLEAN): - common(NXapm_paraprobe_tool_common): + + # NEW ISSUE: has_facet_appearance(NX_BOOLEAN): + common(NXapm_paraprobe_tool_common): status(NX_CHAR): programID(NXprogram): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR profiling(NXcs_profiling): exists: recommended start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): total_elapsed_time(NX_FLOAT): current_working_directory(NX_CHAR): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 17726b94bf3dee5f7c7a29968f1b27a8da0f1e7882194c0a8d17e18d1b838623 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of alpha values (and offset values) to probe. +# +# +# +# +# How many different match values does the filter specify. +# +# +# +# +# Application definition for a configuration file of the paraprobe-surfacer tool. +# +# This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Specifies the method that is used to preprocess the point cloud +# prior to the alpha-shape computation. +# +# The option *default* specifies that no such filtering is applied. +# The option *kuehbach* specifies that a Hoshen-Kopelman +# percolation analysis is used to identify points that lie closer +# to the edge of the dataset. Details about the methods are reported +# in `M. Kühbach et al. <https://doi.org/10.1038/s41524-020-00486-1>`_. +# +# +# +# +# +# +# +# +# When using the kuehbach preprocessing, this is the width of the +# kernel for identifying which ions are in voxels close to the +# edge of the point cloud. +# +# +# +# +# +# Specifies which method to use to define the alpha value. +# +# The value *convex_hull_naive* is the default. The setting instructs +# the tool to use a fast specialized algorithm for computing only +# the convex hull. The resulting triangles can be skinny. +# +# The value *convex_hull_refine* instructs to tool to refine the +# quality of the mesh resulting from *convex_hull_naive* +# via triangle flipping and splitting. +# +# The value *smallest_solid* instructs the CGAL library to choose a +# value which realizes an alpha-shape that is the smallest solid. +# +# The value *cgal_optimal* instructs the CGAL library to choose a +# value which the library considers as to be an optimal value. +# Details are defined in the respective section of the CGAL library +# on 3D alpha shapes. +# +# The value *set_of_values* instructs the tool to compute a list +# collection of alpha-shapes for the specified alpha-values. +# +# The value *set_of_alpha_wrappings* instructs the tool to generate +# a set of so-called alpha wrappings. These are similar to alpha-shapes +# but provide additional guarantees (such as watertightness and +# proximity constraints) on the resulting wrapping. +# +# +# +# +# +# +# +# +# +# +# +# +# Array of alpha values to use when alpha_value_choice is +# set_of_values or when alpha_value_choice is set_of_alpha_wrappings. +# +# +# +# +# +# +# +# Array of offset values to use when alpha_value_choice is set_of_alpha_wrappings. +# The array of alpha_values and offset_values define a sequence of (alpha and offset value). +# +# +# +# +# +# +# +# Specifies if the tool should compute the set of exterior triangle facets +# for each alpha complex (for convex hull, alpha shapes, and wrappings). +# +# +# +# +# Specifies if the tool should check if the alpha complex of +# exterior triangular facets is a closed polyhedron. +# +# +# +# +# Specifies if the tool should compute all interior tetrahedra +# of the alpha complex (currently only for alpha shapes). +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml index 09acc88f67..accaa828dc 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml @@ -22,10 +22,12 @@ symbols: type: group NXapm_paraprobe_surfacer_results(NXobject): (NXentry): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] definition(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR enumeration: [NXapm_paraprobe_surfacer_results] + # tasks point_set_wrapping(NXapm_paraprobe_tool_results): doc: | @@ -42,14 +44,17 @@ NXapm_paraprobe_surfacer_results(NXobject): Ideally, the resulting mesh should be a watertight polyhedron. This polyhedron is not necessarily convex. For some algorithms there is no guarantee that the resulting mesh yields a watertight mesh. + # config window(NXcs_filter_boolean_mask): number_of_ions(NX_UINT): bitdepth(NX_UINT): mask(NX_UINT): + # results alpha_complexID(NXcg_alpha_complex): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] + # (NXcg_grid): currently we do not store the underlying grid # for eventually performed preprocessing window(NXcs_filter_boolean_mask): @@ -62,28 +67,31 @@ NXapm_paraprobe_surfacer_results(NXobject): parent group because irrelevant ions might have been filtered out in addition to the window defined in *point_set_wrapping* to reduce e.g. computational costs of the alpha complex computation. + # filtered in addition to the ROI or again the entire dataset number_of_ions(NX_UINT): + unit: NX_UNITLESS doc: | Number of ions covered by the mask. - unit: NX_UNITLESS bitdepth(NX_UINT): + unit: NX_UNITLESS doc: | Number of bits assumed matching on a default datatype. - unit: NX_UNITLESS mask(NX_UINT): + unit: NX_UNITLESS doc: | The bitfield of the mask. See :ref:`NXcs_filter_boolean_mask` for how this bitfield is to be interpreted. - unit: NX_UNITLESS - dim: (n_ions,) + dimensions: + rank: 1 + dim: [[1, n_ions]] dimensionality(NX_UINT): - enumeration: [2, 3] unit: NX_UNITLESS + enumeration: [2, 3] type(NX_CHAR): enumeration: [convex_hull, alpha_shape, alpha_wrapping, other, undefined] mode(NX_CHAR): - enumeration: [general, regularized] + enumeration: [general, regularized] alpha(NX_NUMBER): unit: NX_ANY offset(NX_NUMBER): @@ -103,40 +111,45 @@ NXapm_paraprobe_surfacer_results(NXobject): face_identifier_offset(NX_INT): vertices(NX_FLOAT): unit: NX_LENGTH - dim: (n_v_tri, 3) + dimensions: + rank: 2 + dim: [[1, n_v_tri], [2, 3]] faces(NX_UINT): unit: NX_UNITLESS - dim: (n_f_tri, 3) + dimensions: + rank: 2 + dim: [[1, n_f_tri], [2, 3]] xdmf_topology(NX_UINT): + unit: NX_UNITLESS doc: | A list of as many tuples of XDMF topology key, XDMF number of vertices and a triple of vertex indices specifying each triangle. The total number of entries is n_f_tri * (1+1+3). - unit: NX_UNITLESS - dim: (n_f_tri_xdmf,) + dimensions: + rank: 1 + dim: [[1, n_f_tri_xdmf]] is_watertight(NX_BOOLEAN): exists: optional doc: | Do the triangles define a triangulated surface mesh that is watertight? volume(NX_FLOAT): exists: optional + unit: NX_VOLUME doc: | The volume which the triangulated surface mesh encloses if that mesh is watertight. - unit: NX_VOLUME - interior_tetrahedra(NXcg_tetrahedron_set): exists: optional doc: | The set of tetrahedra which represent the interior volume of the complex if that is a closed two-manifold. identifier_offset(NX_INT): - unit: NX_UNITLESS + unit: NX_UNITLESS volume(NX_FLOAT): exists: optional - doc: | - The accumulated volume of all interior tetrahedra. unit: NX_VOLUME + doc: | + The accumulated volume of all interior tetrahedra. tetrahedra(NXcg_face_list_data_structure): exists: optional number_of_vertices(NX_POSINT): @@ -145,17 +158,22 @@ NXapm_paraprobe_surfacer_results(NXobject): face_identifier_offset(NX_INT): vertices(NX_FLOAT): unit: NX_LENGTH - dim: (n_v_tet, 3) + dimensions: + rank: 2 + dim: [[1, n_v_tet], [2, 3]] xdmf_topology(NX_UINT): + unit: NX_UNITLESS doc: | A list of as many tuples of XDMF topology key, XDMF number of vertices and a triple of vertex indices specifying each triangle. The total number of entries is n_f_tet * (1+1+4). - unit: NX_UNITLESS - dim: (n_f_tet_xdmf,) - # TRIANGLE_SET_WRAPPING(NXprocess): - # For the future as we may wish to wrap primitives other like triangles or polylines. - common(NXapm_paraprobe_tool_common): + dimensions: + rank: 1 + dim: [[1, n_f_tet_xdmf]] + + # TRIANGLE_SET_WRAPPING(NXprocess): + # For the future as we may wish to wrap primitives other like triangles or polylines. + common(NXapm_paraprobe_tool_common): status(NX_CHAR): analysis_identifier(NX_UINT): config(NXserialized): @@ -164,9 +182,10 @@ NXapm_paraprobe_surfacer_results(NXobject): checksum(NX_CHAR): algorithm(NX_CHAR): programID(NXprogram): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR profiling(NXcs_profiling): exists: recommended start_time(NX_DATE_TIME): @@ -177,21 +196,319 @@ NXapm_paraprobe_surfacer_results(NXobject): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): userID(NXuser): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] doc: | If used, metadata of at least the person who performed this analysis. name(NX_CHAR): coordinate_system_set(NXcoordinate_system_set): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] paraprobe(NXcoordinate_system): type(NX_CHAR): handedness(NX_CHAR): x(NX_NUMBER): unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] y(NX_NUMBER): unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] z(NX_NUMBER): unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 1569006f7d904095cbe56d589202ba88e43d465603e719641542b56bdaa90d77 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The total number of ions in the reconstruction. +# +# +# +# +# The number of vertices of the alpha complex. +# +# +# +# +# The number of faces of the alpha complex. +# +# +# +# +# The total number of XDMF values to represent all faces of triangles via XDMF. +# +# +# +# +# The total number of XDMF values to represent all faces of tetrahedra via XDMF. +# +# +# +# +# Application definition for results files of the paraprobe-surfacer tool. +# +# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. +# The purpose and need of the paraprobe-surfacer tool is the generation of meshed +# representation of the surface of the the reconstructed volume (or a portion) of it +# using different algorithms from the computational geometry community. +# +# +# +# +# +# +# +# +# +# +# +# Paraprobe-surfacer can be used to load a ROI that is the entire or a +# sub-set of the ion point cloud. In the point_cloud_wrapping process +# the tool computes a triangulated surface mesh which encloses the +# ROI/point cloud. This mesh can be seen as a model for the edge of +# the dataset. +# +# Different algorithms can be used with paraprobe-surfacer to create +# this mesh such as convex hulls, alpha-shapes as their generalization, +# or alpha wrappings. +# +# Ideally, the resulting mesh should be a watertight polyhedron. +# This polyhedron is not necessarily convex. For some algorithms there +# is no guarantee that the resulting mesh yields a watertight mesh. +# +# +# +# +# +# +# +# +# +# +# +# +# A bitmask which identifies exactly all those ions whose positions +# were considered when defining the filtered point set from which +# that alpha_complex instance was computed. +# +# This window can be different to the window of the *point_set_wrapping* +# parent group because irrelevant ions might have been filtered out in addition +# to the window defined in *point_set_wrapping* to reduce e.g. computational +# costs of the alpha complex computation. +# +# +# +# +# Number of ions covered by the mask. +# +# +# +# +# Number of bits assumed matching on a default datatype. +# +# +# +# +# The bitfield of the mask. See :ref:`NXcs_filter_boolean_mask` for +# how this bitfield is to be interpreted. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The set of triangles in the coordinate system paraprobe +# which discretizes the exterior surface of the alpha complex. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# A list of as many tuples of XDMF topology key, XDMF number +# of vertices and a triple of vertex indices specifying each +# triangle. The total number of entries is n_f_tri * (1+1+3). +# +# +# +# +# +# +# +# Do the triangles define a triangulated surface mesh that is watertight? +# +# +# +# +# The volume which the triangulated surface mesh +# encloses if that mesh is watertight. +# +# +# +# +# +# +# The set of tetrahedra which represent the interior volume +# of the complex if that is a closed two-manifold. +# +# +# +# +# The accumulated volume of all interior tetrahedra. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# A list of as many tuples of XDMF topology key, XDMF number +# of vertices and a triple of vertex indices specifying each +# triangle. The total number of entries is n_f_tet * (1+1+4). +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# If used, metadata of at least the person who performed this analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml index db664973ff..43d62dcef3 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml @@ -3,6 +3,7 @@ doc: | Application definition for a configuration file of the paraprobe-tessellator tool. This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + # n_control_points: The number of control points for tessellating regions instead of tessellating the volume about ion positions. # an example for limited conditions in NeXus # if windowing_method is entire_dataset: no constraint on existence of NXcg and NXcs instances @@ -11,12 +12,13 @@ doc: | type: group NXapm_paraprobe_tessellator_config(NXobject): (NXentry): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] definition(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR enumeration: [NXapm_paraprobe_tessellator_config] tessellate(NXapm_paraprobe_tool_config): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] (NXidentifier): exists: optional analysis_identifier(NX_UINT): @@ -68,14 +70,16 @@ NXapm_paraprobe_tessellator_config(NXobject): orientation(NX_NUMBER): polyhedron_set(NXcg_polyhedron_set): exists: optional - # TODO + + # TODO bitmask(NXcs_filter_boolean_mask): exists: optional number_of_objects(NX_UINT): bitdepth(NX_UINT): mask(NX_UINT): + # leave open if scalar or matrix - # dim: (i,) + # dim: (i,) identifier(NX_UINT): evaporation_id_filter(NXsubsampling_filter): exists: optional @@ -88,11 +92,13 @@ NXapm_paraprobe_tessellator_config(NXobject): exists: optional method(NX_CHAR): match(NX_NUMBER): + # config method(NX_CHAR): doc: | The method used to compute the tessellation. The value *default* configures the computation of the Voronoi tessellation. + # check versions prior paraprobe-toolbox v0.5 for control_point-based method enumeration: [default] has_cell_volume(NX_BOOLEAN): @@ -113,21 +119,201 @@ NXapm_paraprobe_tessellator_config(NXobject): into the point cloud so that the shape of their cells are not affected anymore by the boundary. This is valuable information to judge about the significance of finite size effects. - # erosion_distance(NX_FLOAT): - # doc: | - # Maximum distance for which cells are eroded. - # unit: NX_LENGTH - # \@units: nm - # minValue: EPSILON - common(NXapm_paraprobe_tool_common): + + # erosion_distance(NX_FLOAT): + # doc: | + # Maximum distance for which cells are eroded. + # unit: NX_LENGTH + # \@units: nm + # minValue: EPSILON + common(NXapm_paraprobe_tool_common): status(NX_CHAR): programID(NXprogram): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR profiling(NXcs_profiling): exists: recommended start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): total_elapsed_time(NX_FLOAT): current_working_directory(NX_CHAR): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 45ea5ec9e90adc378bd48ba43594b4f2e34daad706bdbfd1106c20023dd2bb47 +# +# +# +# +# +# +# Application definition for a configuration file of the paraprobe-tessellator tool. +# +# This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The method used to compute the tessellation. +# The value *default* configures the computation of the Voronoi tessellation. +# +# +# +# +# +# +# +# +# Specifies if the tool should report the volume of each cell. +# +# +# +# +# Specifies if the tool should report the first-order neighbors of each cell. +# +# +# +# +# Specifies if the tool should report the facets and vertices of each cell. +# +# +# +# +# Specifies if the tool should report for each cell if it makes contact with +# the tight axis-aligned bounding box about the point cloud. +# This can be used to identify if the shape of the cell is likely affected +# by the edge of the dataset or if cells are deeply enough embedded +# into the point cloud so that the shape of their cells are not affected +# anymore by the boundary. This is valuable information to judge +# about the significance of finite size effects. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml index 9ae8bdfc36..a4ad9bad7f 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml @@ -11,17 +11,20 @@ symbols: n_f: | The total number of values required to represent all faces of each cell. n_f_xdmf: | - The total number of values required to represent all faces of each cell (polyhedron) using XDMF. + The total number of values required to represent all faces of each cell + (polyhedron) using XDMF. type: group NXapm_paraprobe_tessellator_results(NXobject): (NXentry): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] definition(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR enumeration: [NXapm_paraprobe_tessellator_results] + # tasks tessellation(NXapm_paraprobe_tool_results): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] doc: | The tool can be used to compute a Voronoi tessellation the entire or of a sub-set of the reconstructed volume. Each point (ion) is wrapped @@ -30,62 +33,76 @@ NXapm_paraprobe_tessellator_results(NXobject): the edge of the point cloud can lay on the surface of the bounding box. The tool detects if cells make contact with the walls of this bounding box. The tessellation is computed without periodic boundary conditions. + # config window(NXcs_filter_boolean_mask): number_of_ions(NX_UINT): bitdepth(NX_UINT): mask(NX_UINT): + # results wall(NXcg_hexahedron_set): exists: recommended doc: | The (tight) axis-aligned bounding box about the point cloud. closest_corner(NX_FLOAT): + unit: NX_LENGTH doc: | Coordinate triplet of the corner that lays closests to the origin of the *paraprobe* coordinate system. - unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] farthest_corner(NX_FLOAT): + unit: NX_LENGTH doc: | Coordinate triplet of the corner that lays farthest away from the origin of the *paraprobe* coordinate system. - unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] voronoi_cells(NXcg_polyhedron_set): exists: optional dimensionality(NX_POSINT): unit: NX_UNITLESS enumeration: [3] cardinality(NX_POSINT): + unit: NX_UNITLESS doc: | The number of points (and thus cells). - unit: NX_UNITLESS volume(NX_FLOAT): + unit: NX_VOLUME doc: | Volume of each Voronoi cell. - unit: NX_VOLUME - dim: (n_ions,) + dimensions: + rank: 1 + dim: [[1, n_ions]] process_identifier(NX_POSINT): exists: optional + unit: NX_UNITLESS doc: | Which MPI process computed which Voronoi cell. - unit: NX_UNITLESS - dim: (n_ions,) + dimensions: + rank: 1 + dim: [[1, n_ions]] thread_identifier(NX_POSINT): exists: optional + unit: NX_UNITLESS doc: | Which OpenMP thread computed which Voronoi cell. - unit: NX_UNITLESS - dim: (n_ions,) + dimensions: + rank: 1 + dim: [[1, n_ions]] number_of_faces(NX_INT): exists: optional + unit: NX_UNITLESS doc: | The number of faces for each cell. Faces of adjoining polyhedra are counted for each polyhedron. This field can be used to interpret the concatenated vector with the individual values for the area of each face. - unit: NX_UNITLESS - dim: (n_ions,) + dimensions: + rank: 1 + dim: [[1, n_ions]] identifier_offset(NX_INT): polyhedra(NXcg_face_list_data_structure): exists: optional @@ -98,6 +115,7 @@ NXapm_paraprobe_tessellator_results(NXobject): face_identifier_offset(NX_INT): vertices(NX_FLOAT): xdmf_topology(NX_UINT): + unit: NX_UNITLESS doc: | Sequence of tuples, concatenated in the order of the Voronoi cells. Each tuple contains encodes information to visualize using XDMF: @@ -105,9 +123,11 @@ NXapm_paraprobe_tessellator_results(NXobject): Secondly, the number of vertices of the polygon. Third, the sequence of vertex identifier which define the facet. Tuples encode faces faster than cells. - unit: NX_UNITLESS - dim: (n_f_xdmf,) # not n_f because primitive key and number of faces in each tuple! + dimensions: + rank: 1 + dim: [[1, n_f_xdmf]] xdmf_cell_identifier(NX_UINT): + unit: NX_UNITLESS doc: | Sequence of cell identifier, concatenated such that each face is associated with its cell. Given that paraprobe-tessellator assigns @@ -115,21 +135,25 @@ NXapm_paraprobe_tessellator_results(NXobject): information enables the segmentation of the tessellation and thus correlate per-ion properties with the volume that each cell represents. - unit: NX_UNITLESS - dim: (n_f,) + dimensions: + rank: 1 + dim: [[1, n_f]] wall_contact_global(NXcs_filter_boolean_mask): exists: recommended doc: | A bitmask that documents which of the cells are likely truncated because they share at least one face with the *aabb* of the point cloud. This field encodes the result of the boolean or operator applied to the value of all six wall_contact groups - that document contact in specific outer unit normal directions of the *aabb*. + that document contact in specific outer unit normal directions of the *aabb*. number_of_objects(NX_UINT): - dim: (n_ions,) + dimensions: + rank: 1 + dim: [[1, n_ions]] bitdepth(NX_UINT): mask(NX_UINT): - # dim: (i,) # not necessarily n_ions because n_ions is not always an integer multiple of bitdepth - # dim: (i,) # one would not need to constrain this but doing so communicates that all six bitfields have the same length + + # dim: (i,) # not necessarily n_ions because n_ions is not always an integer multiple of bitdepth + # dim: (i,) # one would not need to constrain this but doing so communicates that all six bitfields have the same length wall_contact_left(NXcs_filter_boolean_mask): exists: recommended doc: | @@ -137,7 +161,9 @@ NXapm_paraprobe_tessellator_results(NXobject): Its outer unit normal points in the opposite direction of the x-axis of the *paraprobe* coordinate system. number_of_objects(NX_UINT): - dim: (n_ions,) + dimensions: + rank: 1 + dim: [[1, n_ions]] bitdepth(NX_UINT): mask(NX_UINT): wall_contact_right(NXcs_filter_boolean_mask): @@ -147,7 +173,9 @@ NXapm_paraprobe_tessellator_results(NXobject): Its outer unit normal points in the direction of the x-axis of the *paraprobe* coordinate system. number_of_objects(NX_UINT): - dim: (n_ions,) + dimensions: + rank: 1 + dim: [[1, n_ions]] bitdepth(NX_UINT): mask(NX_UINT): wall_contact_front(NXcs_filter_boolean_mask): @@ -157,7 +185,9 @@ NXapm_paraprobe_tessellator_results(NXobject): Its outer unit normal points in the opposite direction of the y-axis of the *paraprobe* coordinate system. number_of_objects(NX_UINT): - dim: (n_ions,) + dimensions: + rank: 1 + dim: [[1, n_ions]] bitdepth(NX_UINT): mask(NX_UINT): wall_contact_rear(NXcs_filter_boolean_mask): @@ -167,7 +197,9 @@ NXapm_paraprobe_tessellator_results(NXobject): Its outer unit normal points in the direction of the y-axis of the *paraprobe* coordinate system. number_of_objects(NX_UINT): - dim: (n_ions,) + dimensions: + rank: 1 + dim: [[1, n_ions]] bitdepth(NX_UINT): mask(NX_UINT): wall_contact_bottom(NXcs_filter_boolean_mask): @@ -177,7 +209,9 @@ NXapm_paraprobe_tessellator_results(NXobject): Its outer unit normal points in the opposite direction of the z-axis of the *paraprobe* coordinate system. number_of_objects(NX_UINT): - dim: (n_ions,) + dimensions: + rank: 1 + dim: [[1, n_ions]] bitdepth(NX_UINT): mask(NX_UINT): wall_contact_top(NXcs_filter_boolean_mask): @@ -186,10 +220,12 @@ NXapm_paraprobe_tessellator_results(NXobject): Its outer unit normal points in the direction of the z-axis of the *paraprobe* coordinate system. number_of_ions(NX_UINT): - dim: (n_ions,) + dimensions: + rank: 1 + dim: [[1, n_ions]] bitdepth(NX_UINT): mask(NX_UINT): - common(NXapm_paraprobe_tool_common): + common(NXapm_paraprobe_tool_common): status(NX_CHAR): analysis_identifier(NX_UINT): config(NXserialized): @@ -198,9 +234,10 @@ NXapm_paraprobe_tessellator_results(NXobject): checksum(NX_CHAR): algorithm(NX_CHAR): programID(NXprogram): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR profiling(NXcs_profiling): exists: recommended start_time(NX_DATE_TIME): @@ -211,21 +248,367 @@ NXapm_paraprobe_tessellator_results(NXobject): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): userID(NXuser): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] doc: | If used, metadata of at least the person who performed this analysis. name(NX_CHAR): coordinate_system_set(NXcoordinate_system_set): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] paraprobe(NXcoordinate_system): type(NX_CHAR): handedness(NX_CHAR): x(NX_NUMBER): unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] y(NX_NUMBER): unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] z(NX_NUMBER): unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 281fc45c747c1793f02edba1e0fc8de5ccb99deb1014f2e7153bc4c1dbe7cb7d +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The total number of ions in the reconstruction. +# +# +# +# +# The total number of values required to represent all faces of each cell. +# +# +# +# +# The total number of values required to represent all faces of each cell +# (polyhedron) using XDMF. +# +# +# +# +# Application definition for results files of the paraprobe-tessellator tool. +# +# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. +# +# +# +# +# +# +# +# +# +# +# +# The tool can be used to compute a Voronoi tessellation the entire +# or of a sub-set of the reconstructed volume. Each point (ion) is wrapped +# in one (Voronoi) cell. The point cloud in the ROI is wrapped into an +# axis-aligned bounding box (AABB) that is tight. This means points at +# the edge of the point cloud can lay on the surface of the bounding box. +# The tool detects if cells make contact with the walls of this bounding box. +# The tessellation is computed without periodic boundary conditions. +# +# +# +# +# +# +# +# +# +# +# The (tight) axis-aligned bounding box about the point cloud. +# +# +# +# Coordinate triplet of the corner that lays closests +# to the origin of the *paraprobe* coordinate system. +# +# +# +# +# +# +# +# Coordinate triplet of the corner that lays farthest away +# from the origin of the *paraprobe* coordinate system. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The number of points (and thus cells). +# +# +# +# +# Volume of each Voronoi cell. +# +# +# +# +# +# +# +# Which MPI process computed which Voronoi cell. +# +# +# +# +# +# +# +# Which OpenMP thread computed which Voronoi cell. +# +# +# +# +# +# +# +# The number of faces for each cell. Faces of adjoining polyhedra are counted +# for each polyhedron. This field can be used to interpret the concatenated vector +# with the individual values for the area of each face. +# +# +# +# +# +# +# +# +# A simple approach to describe the entire set of polyhedra when the main +# intention is to store the shape of the polyhedra for visualization purposes. +# +# +# +# +# +# +# +# +# +# Sequence of tuples, concatenated in the order of the Voronoi cells. +# Each tuple contains encodes information to visualize using XDMF: +# Firstly, an XDMF geometric primitive type key. +# Secondly, the number of vertices of the polygon. +# Third, the sequence of vertex identifier which define the facet. +# Tuples encode faces faster than cells. +# +# +# +# +# +# +# +# Sequence of cell identifier, concatenated such that each face is +# associated with its cell. Given that paraprobe-tessellator assigns +# each cell the evaporation_id of the ion that the cell wraps this +# information enables the segmentation of the tessellation and +# thus correlate per-ion properties with the volume that each cell +# represents. +# +# +# +# +# +# +# +# +# A bitmask that documents which of the cells are likely truncated because they +# share at least one face with the *aabb* of the point cloud. This field encodes the +# result of the boolean or operator applied to the value of all six wall_contact groups +# that document contact in specific outer unit normal directions of the *aabb*. +# +# +# +# +# +# +# +# +# +# +# +# +# In the spirit of wall_contact_global, the left face of *aabb*. +# Its outer unit normal points in the opposite direction of the +# x-axis of the *paraprobe* coordinate system. +# +# +# +# +# +# +# +# +# +# +# +# In the spirit of wall_contact_global, the right face of *aabb*. +# Its outer unit normal points in the direction of the x-axis +# of the *paraprobe* coordinate system. +# +# +# +# +# +# +# +# +# +# +# +# In the spirit of wall_contact_global, the front face of *aabb*. +# Its outer unit normal points in the opposite direction of the +# y-axis of the *paraprobe* coordinate system. +# +# +# +# +# +# +# +# +# +# +# +# In the spirit of wall_contact_global, the rear face of *aabb*. +# Its outer unit normal points in the direction of the y-axis +# of the *paraprobe* coordinate system. +# +# +# +# +# +# +# +# +# +# +# +# In the spirit of wall_contact_global, the front face of *aabb*. +# Its outer unit normal points in the opposite direction of the +# z-axis of the *paraprobe* coordinate system. +# +# +# +# +# +# +# +# +# +# +# +# In the spirit of wall_contact_global, the front face of *aabb*. +# Its outer unit normal points in the direction of the z-axis of the +# *paraprobe* coordinate system. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# If used, metadata of at least the person who performed this analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml index 732305a416..00a76c6634 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml @@ -35,18 +35,20 @@ NXapm_paraprobe_tool_common(NXobject): (NXprogram): (NXidentifier): analysis_identifier(NX_UINT): - doc: | - Internal identifier used by the tool to refer to an analysis (aka simulation id). unit: NX_UNITLESS + doc: | + Internal identifier used by the tool to refer to an analysis (aka simulation + id). config(NXserialized): doc: | The configuration file that was used to parameterize the algorithms that this tool has executed. profiling(NXcs_profiling): + # results_path(NX_CHAR): - # doc: | - # Path where the tool stores tool-specific results. If not specified, - # results will be stored in the current working directory. + # doc: | + # Path where the tool stores tool-specific results. If not specified, + # results will be stored in the current working directory. start_time(NX_DATE_TIME): doc: | ISO 8601 formatted time code with local time zone offset to UTC @@ -58,9 +60,9 @@ NXapm_paraprobe_tool_common(NXobject): information included when the analysis in this results file were completed and the respective process of the tool exited. total_elapsed_time(NX_FLOAT): + unit: NX_TIME doc: | Wall-clock time. - unit: NX_TIME (NXuser): (NXcoordinate_system_set): doc: | @@ -84,5 +86,138 @@ NXapm_paraprobe_tool_common(NXobject): Inspect :ref:`NXtransformations` for further details. (NXcoordinate_system): (NXtransformations): - # add further fields coming from using the charge state recovery - # workflow from the ifes_apt_tc_data_modeling library + + # add further fields coming from using the charge state recovery + # workflow from the ifes_apt_tc_data_modeling library + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# d3a258a391c4a82831ce0c65af5146f833be78e8fba8045f2e0641fd1976747d +# +# +# +# +# +# Base class documenting the information common to tools of the paraprobe-toolbox. +# +# The paraprobe-toolbox is a collection of open-source tools for performing +# efficient analyses of point cloud data where each point can represent atoms or +# (molecular) ions. A key application of the toolbox has been for research in the +# field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): +# +# * `paraprobe-toolbox <https://www.gitlab.com/paraprobe/paraprobe-toolbox>`_ +# * `M. Kühbach et al. <https://paraprobe-toolbox.readthedocs.io/en/main/>`_ +# +# The toolbox does not replace but complements existent software tools in this +# research field. Given its capabilities of handling points as objects with +# properties and enabling analyses of the spatial arrangement of and inter- +# sections between geometric primitives, the software can equally be used +# for analyzing data in Materials Science and Materials Engineering. +# +# The common section can be used as a place to store e.g. organizational +# metadata and contextualization of that analysis in a research data +# management system. +# +# +# +# A statement whether the tool executable managed to process the analysis +# or whether this failed. Status is written to the results file after the +# end_time beyond which point in time the tool must no longer compute +# any further analysis results but exit. +# +# Only when this status message is present and its value is `success`, +# one should consider the results of the tool. In all other cases it might +# be that the tool has terminated prematurely or another error occurred. +# +# +# +# +# +# +# +# +# +# +# Internal identifier used by the tool to refer to an analysis (aka simulation +# id). +# +# +# +# +# The configuration file that was used to parameterize +# the algorithms that this tool has executed. +# +# +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when the analysis in this results file was started, +# i.e. when the respective executable/tool was started as a process. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when the analysis in this results file were +# completed and the respective process of the tool exited. +# +# +# +# +# Wall-clock time. +# +# +# +# +# +# +# Details about coordinate systems (reference frames) used. In atom probe several coordinate +# systems have to be distinguished. Names of instances of such :ref:`NXcoordinate_system` +# should be documented explicitly and doing so by picking from the +# following controlled set of names: +# +# * paraprobe +# * lab +# * specimen +# * laser +# * instrument +# * detector +# * recon +# +# The aim of this convention is to support users with contextualizing which reference frame +# each instance (coordinate system) is. If needed, instances of :ref:`NXtransformations` +# are used to detail the explicit affine transformations whereby one can convert +# representations between different reference frames. +# Inspect :ref:`NXtransformations` for further details. +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml index 459faaac0a..2258eed048 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml @@ -21,12 +21,14 @@ doc: | Hierarchical Data Format 5 (HDF5). type: group NXapm_paraprobe_tool_config(NXobject): + # sequence_id is inherited from NXprocess (NXidentifier): analysis_identifier(NX_UINT): - doc: | - Internal identifier used by the tool to refer to an analysis (aka simulation id). unit: NX_UNITLESS + doc: | + Internal identifier used by the tool to refer to an analysis (aka simulation + id). description(NX_CHAR): doc: | Possibility for leaving a free-text description about this analysis. @@ -34,6 +36,7 @@ NXapm_paraprobe_tool_config(NXobject): Although offered here for convenience we strongly encourage to parameterize such descriptions as much as possible to support reusage and clearer communication. + # tool-specific input, examples for definitions for common types of input granularized into this # base class from which tool-specific appdefs inherit reconstruction(NXserialized): @@ -75,10 +78,11 @@ NXapm_paraprobe_tool_config(NXobject): Such a surface mesh can be used to define the edge of the reconstructed volume to account for finite size effects. - # mesh(NX_CHAR): - # doc: | - # Name of the (parent) node directly below which (in the hierarchy) - # an instance of :ref:`NXcg_triangle_set` is stored. + + # mesh(NX_CHAR): + # doc: | + # Name of the (parent) node directly below which (in the hierarchy) + # an instance of :ref:`NXcg_triangle_set` is stored. surface_distance(NXserialized): doc: | Specification of the point-to-triangulated-surface-mesh distances to @@ -88,7 +92,148 @@ NXapm_paraprobe_tool_config(NXobject): Absolute path in the (HDF5) file that points to the distance values. The tool assumes that the values are stored in the same order as points (ions). + # filters (NXspatial_filter): (NXsubsampling_filter): (NXmatch_filter): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e12a33529aaeaf9b2276b86fdecb3b89bc4d34092bbc8aa9b72c38b684bce23f +# +# +# +# +# +# Base class documenting the configuration used for a tool of the paraprobe-toolbox. +# +# The paraprobe-toolbox is a collection of open-source software tools for performing +# efficient analyses of point cloud data where each point can represent atoms or +# (molecular) ions. A key application of the toolbox has been for research in the +# field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): +# +# * `paraprobe-toolbox <https://www.gitlab.com/paraprobe/paraprobe-toolbox>`_ +# * `M. Kühbach et al. <https://paraprobe-toolbox.readthedocs.io/en/main/>`_ +# +# The toolbox does not replace but complements existent software tools in this +# research field. Given its capabilities of handling points as objects with +# properties and enabling analyses of the spatial arrangement of and inter- +# sections between geometric primitives, the software can equally be used +# for analyzing data in Materials Science and Materials Engineering. +# +# The configuration and results of a run of a tool from the toolbox is documented +# using binary container formats. Currently, paraprobe-toolbox uses the +# Hierarchical Data Format 5 (HDF5). +# +# +# +# +# +# Internal identifier used by the tool to refer to an analysis (aka simulation +# id). +# +# +# +# +# Possibility for leaving a free-text description about this analysis. +# +# Although offered here for convenience we strongly encourage to +# parameterize such descriptions as much as possible to support +# reusage and clearer communication. +# +# +# +# +# +# Specification of the tomographic reconstruction to use for this analysis. +# +# Typically, reconstructions in the field of atom probe tomography are communicated +# via files which store at least reconstructed ion positions and mass-to-charge-state-ratio +# values. Container files like HDF5 though can store multiple reconstructions. +# Therefore, the position and mass_to_charge concepts point to specific instances +# to use for this analysis. +# +# +# +# Name of the node which resolves the reconstructed ion position +# values to use for this analysis. +# +# +# +# +# Name of the node which resolves the mass-to-charge-state-ratio +# values to use for this analysis. +# +# +# +# +# +# Specification of the ranging definitions to use for this analysis. +# +# Ranging is the process of labeling time-of-flight data with so-called iontypes +# (aka ion species). Ideally, iontypes specify the most likely (molecular) ion +# that is assumed to have been evaporated given that its mass-to-charge-state ratio +# lies within the specific mass-to-charge-state-ratio value interval of the iontype. +# +# The so-called UNKNOWNTYPE iontype represents the null model of an ion +# that has not been ranged (for whatever reasons). +# The identifier of this special iontype is always the reserved value 0. +# +# +# +# Name of the (parent) node directly below which (in the hierarchy) +# the ranging definition for (molecular) ions are stored. +# +# +# +# +# +# Specification of the triangulated surface mesh to use for this analysis. +# +# Such a surface mesh can be used to define the edge of the reconstructed +# volume to account for finite size effects. +# +# +# +# +# +# Specification of the point-to-triangulated-surface-mesh distances to +# use for this analysis. +# +# +# +# Absolute path in the (HDF5) file that points to the distance values. +# The tool assumes that the values are stored in the same order as +# points (ions). +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tool_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tool_results.yaml index f675ba9e14..f08cbb7102 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tool_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tool_results.yaml @@ -22,13 +22,15 @@ doc: | The paraprobe coordinate system is the reference *NXcoordinate_system* for each geometric primitive. + # thereby implicitly all \@default attributes for geometric primitives point to the # single instance ENTRY[entry]/COORDINATE_SYSTEM_SET[coordinate_system_set]/paraprobe # symbols: -# doc: | -# The symbols used in the schema to specify e.g. dimensions of arrays. +# doc: | +# The symbols used in the schema to specify e.g. dimensions of arrays. type: group NXapm_paraprobe_tool_results(NXprocess): + # config section description(NX_CHAR): doc: | @@ -37,18 +39,111 @@ NXapm_paraprobe_tool_results(NXprocess): doc: | A bitmask which identifies all ions considered in the analysis. number_of_ions(NX_UINT): + unit: NX_UNITLESS doc: | Number of ions covered by the mask. By default, the total number of ions in the dataset. - unit: NX_UNITLESS bitdepth(NX_UINT): + unit: NX_UNITLESS doc: | Number of bits assumed matching on a default datatype. - unit: NX_UNITLESS mask(NX_UINT): + unit: NX_UNITLESS doc: | The mask. The length of the mask is an integer multiple of bitdepth. In such case, padded bits are set to 0. - unit: NX_UNITLESS - dim: (i,) + dimensions: + rank: 1 + dim: [[1, i]] + # typically tool-specific section follows + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 1241565d5164b6a79f9f6321aa2df39420ef356b753fc262c602f5aaa4b02915 +# +# +# +# +# +# +# Base class documenting the results obtained with a tool of the paraprobe-toolbox. +# +# The paraprobe-toolbox is a collection of open-source tools for performing +# efficient analyses of point cloud data where each point can represent atoms or +# (molecular) ions. A key application of the toolbox has been for research in the +# field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): +# +# * `paraprobe-toolbox <https://www.gitlab.com/paraprobe/paraprobe-toolbox>`_ +# * `M. Kühbach et al. <https://paraprobe-toolbox.readthedocs.io/en/main/>`_ +# +# The toolbox does not replace but complements existent software tools in this +# research field. Given its capabilities of handling points as objects with +# properties and enabling analyses of the spatial arrangement of and inter- +# sections between geometric primitives, the software can equally be used +# for analyzing data in Materials Science and Materials Engineering. +# +# The configuration and results of a run of a tool from the toolbox is documented +# using binary container formats. Currently, paraprobe-toolbox uses the +# Hierarchical Data Format 5 (HDF5). +# +# The paraprobe coordinate system is the reference *NXcoordinate_system* +# for each geometric primitive. +# +# +# +# +# Possibility for leaving a free-text description about this analysis. +# +# +# +# +# A bitmask which identifies all ions considered in the analysis. +# +# +# +# Number of ions covered by the mask. +# By default, the total number of ions in the dataset. +# +# +# +# +# Number of bits assumed matching on a default datatype. +# +# +# +# +# The mask. The length of the mask is an integer multiple of bitdepth. +# In such case, padded bits are set to 0. +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml index 0930e7d234..fc88b927e2 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml @@ -3,21 +3,26 @@ doc: | Application definition for a configuration file of the paraprobe-transcoder tool. This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + # symbols: -# doc: | -# The symbols used in the schema to specify e.g. dimensions of arrays. -type: group +# doc: | +# The symbols used in the schema to specify e.g. dimensions of arrays. + # official NeXus appdef headers +type: group NXapm_paraprobe_transcoder_config(NXobject): (NXentry): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] + # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently definition(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR enumeration: [NXapm_paraprobe_transcoder_config] + # tool-specific transcode(NXapm_paraprobe_tool_config): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] (NXidentifier): exists: optional analysis_identifier(NX_UINT): @@ -36,17 +41,105 @@ NXapm_paraprobe_transcoder_config(NXobject): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): - # tool-specific parameter - # filter - common(NXapm_paraprobe_tool_common): + + # tool-specific parameter + # filter + common(NXapm_paraprobe_tool_common): status(NX_CHAR): programID(NXprogram): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR profiling(NXcs_profiling): exists: recommended start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): total_elapsed_time(NX_FLOAT): current_working_directory(NX_CHAR): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# ab86874f92a46be39257ce80c32be0c4e47a3738d5b6bd12e0ffc3f0d2d9950e +# +# +# +# +# +# +# +# Application definition for a configuration file of the paraprobe-transcoder tool. +# +# This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Specification of the ranging definition file to use for this analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml index 52d8f25aeb..3dc9d7a417 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml @@ -35,16 +35,20 @@ symbols: Total number of integers in the supplementary XDMF topology array. n_variable: | Number of entries + # i be careful n_comb can vary for every instance of (NXion) ! type: group NXapm_paraprobe_transcoder_results(NXobject): (NXentry): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] definition(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR enumeration: [NXapm_paraprobe_transcoder_results] + # tasks atom_probe(NXapm_paraprobe_tool_results): + # this group mirrors the NXapm application definition # config analysis_identifier(NX_UINT): @@ -62,48 +66,59 @@ NXapm_paraprobe_transcoder_results(NXobject): number_of_ions(NX_UINT): bitdepth(NX_UINT): mask(NX_UINT): + # results mass_to_charge_conversion(NXprocess): mass_to_charge(NX_FLOAT): + unit: NX_ANY doc: | Mass-to-charge-state-ratio values. - unit: NX_ANY # u - dim: (n_ions,) + dimensions: + rank: 1 + dim: [[1, n_ions]] reconstruction(NXprocess): reconstructed_positions(NX_FLOAT): + unit: NX_LENGTH doc: | Three-dimensional reconstructed positions of the ions. Interleaved array of x, y, z positions in the specimen space. - unit: NX_LENGTH - dim: (n_ions, 3) - \@depends_on(NX_CHAR): + dimensions: + rank: 2 + dim: [[1, n_ions], [2, 3]] + \@depends_on: + type: NX_CHAR doc: | Defines in which reference frame the positions are defined. visualization(NXprocess): exists: recommended xdmf_topology(NX_UINT): + unit: NX_UNITLESS doc: | An array of triplets of integers which can serve as a supplementary array for Paraview to display the reconstruction. The XDMF datatype is here 1, the number of primitives 1 per triplet, the last integer in each triplet is the identifier of each point starting from zero. - unit: NX_UNITLESS - dim: (n_topology,) + dimensions: + rank: 1 + dim: [[1, n_topology]] ranging(NXprocess): peak_identification(NXprocess): doc: | Details about how peaks are interpreted as ion types or not. (NXion): - exists: [min, 1, max, 256] + exists: ['min', '1', 'max', '256'] nuclide_hash(NX_UINT): nuclide_list(NX_UINT): exists: recommended charge_state(NX_INT): mass_to_charge_range(NX_FLOAT): - unit: NX_ANY # u - dim: (n_variable, 2) - # (NXapm_charge_state_analysis): - common(NXapm_paraprobe_tool_common): + unit: NX_ANY + dimensions: + rank: 2 + dim: [[1, n_variable], [2, 2]] + + # (NXapm_charge_state_analysis): + common(NXapm_paraprobe_tool_common): status(NX_CHAR): analysis_identifier(NX_UINT): config(NXserialized): @@ -112,9 +127,10 @@ NXapm_paraprobe_transcoder_results(NXobject): checksum(NX_CHAR): algorithm(NX_CHAR): programID(NXprogram): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR profiling(NXcs_profiling): exists: recommended start_time(NX_DATE_TIME): @@ -125,21 +141,249 @@ NXapm_paraprobe_transcoder_results(NXobject): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): userID(NXuser): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] doc: | If used, metadata of at least the person who performed this analysis. name(NX_CHAR): coordinate_system_set(NXcoordinate_system_set): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] paraprobe(NXcoordinate_system): type(NX_CHAR): handedness(NX_CHAR): x(NX_NUMBER): unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] y(NX_NUMBER): unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] z(NX_NUMBER): unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 9bd34c352b0573cf258afd984aa23c4791ba99d3dc581b0edd7ad4b5a1fcd9af +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The total number of ions in the reconstruction. +# +# +# +# +# Maximum number of allowed atoms per (molecular) ion (fragment). +# Needs to match maximum_number_of_atoms_per_molecular_ion. +# +# +# +# +# Total number of integers in the supplementary XDMF topology array. +# +# +# +# +# Number of entries +# +# +# +# +# Application definition for results files of the paraprobe-transcoder tool. +# +# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. +# The purpose and need of the paraprobe-transcoder tool is to create a standardized representation +# of reconstructed position and mass-to-charge-state-ratio values surplus other pieces of information +# to enable working with atom probe data in reconstruction space in the paraprobe-toolbox. +# This includes ranging definitions which map mass-to-charge-state ratio values onto iontypes. +# +# So far the atom probe community has not yet agreed upon a comprehensive standardization on how to +# exchange information especially when it comes to the communication of configurations and results +# from analyses of atom probe data. Instead, different simplistic file formats are used, such as POS, ePOS, +# APT, or RNG and RRNG. None of these formats, though, are self-descriptive, standardize, or document +# their origin and thus the sequence in which the file was generated during an analysis. +# +# Paraprobe-transcoder solves this limitation by interpreting the information content in such files +# and standardize the representation prior injection into the scientific data analysis tools of the toolbox. +# Therefore, the here proposed set of NeXus base classes and application definitions can be a useful +# starting point for the atom probe community to take advantage of standardized information +# exchange and improve the here proposed classes and concepts to become more inclusive. +# +# Paraprobe-transcoder uses a Python library developed based on efforts by members of the +# global atom probe community `International Field Emission Society (IFES) Atom Probe Technical Committee (APT TC) <https://www.github.com/atomprobe-tc/ifes_apt_tc_data_modeling>`_. This library offers the +# actual low-level I/O operations and respective information interpretation of above-mentioned file formats. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# By default the entire reconstructed volume is processed. +# In this case, using window is also equivalent to an +# NXspatial_filter that specified a window *entire_dataset*. +# +# +# +# +# +# +# +# +# +# Mass-to-charge-state-ratio values. +# +# +# +# +# +# +# +# +# +# Three-dimensional reconstructed positions of the ions. +# Interleaved array of x, y, z positions in the specimen space. +# +# +# +# +# +# +# +# Defines in which reference frame the positions are defined. +# +# +# +# +# +# +# An array of triplets of integers which can serve as a supplementary +# array for Paraview to display the reconstruction. The XDMF datatype +# is here 1, the number of primitives 1 per triplet, the last integer +# in each triplet is the identifier of each point starting from zero. +# +# +# +# +# +# +# +# +# +# +# Details about how peaks are interpreted as ion types or not. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# If used, metadata of at least the person who performed this analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_ranging.yaml b/contributed_definitions/nyaml/NXapm_ranging.yaml index 335a878ab3..7d6a4f03cc 100644 --- a/contributed_definitions/nyaml/NXapm_ranging.yaml +++ b/contributed_definitions/nyaml/NXapm_ranging.yaml @@ -11,39 +11,38 @@ doc: | * `M. K. Miller `_ * `D. Haley et al. `_ * `M. Kühbach et al. `_ - type: group -NXapm_ranging(NXprocess): # when evolving these ideas further inherit from NXapm_method instead +NXapm_ranging(NXprocess): (NXprogram): (NXserialized): number_of_ion_types(NX_UINT): + unit: NX_UNITLESS doc: | How many ion types are distinguished. If no ranging was performed, each ion is of the special unknown type. The iontype ID of this unknown type is 0 representing a reserve value. Consequently, iontypes start counting from 1. - unit: NX_UNITLESS maximum_number_of_atoms_per_molecular_ion(NX_UINT): + unit: NX_UNITLESS doc: | Assumed maximum value that suffices to store all relevant molecular ions, even the most complicated ones. Currently, a value of 32 is used (see M. Kühbach et al. `_). - unit: NX_UNITLESS - mass_to_charge_distribution(NXprocess): doc: | Specifies the mass-to-charge-state-ratio histogram. (NXprogram): min_incr_max(NX_FLOAT): + unit: NX_ANY doc: | Smallest, increment, and largest mass-to-charge-state ratio value. - unit: NX_ANY # u - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] mass_spectrum(NXdata): doc: | A default histogram aka mass spectrum of the mass-to-charge-state ratio values. - background_quantification(NXprocess): doc: | Details of the background model that was used to @@ -55,12 +54,12 @@ NXapm_ranging(NXprocess): # when evolving these ideas further inherit from NXap atom probers define a background model. Future versions of NXapm_ranging can then use this information to parameterize these models. + # NEW ISSUE: add parameters of the background model in an e.g. # NXcollection as these are specific to every background model # NEW ISSUE: touching upon i.e. research activities by Andrew London et al. # substantiating the need for a clearer description how peak/signals were # eventually processed via deconvolution methods - peak_search_and_deconvolution(NXprocess): doc: | How where peaks in the background-corrected in the histogram @@ -73,3 +72,117 @@ NXapm_ranging(NXprocess): # when evolving these ideas further inherit from NXap error models, were interpreted as ion types or not. (NXprogram): (NXion): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 03d0005c9cd241cb1b84669fc98d723d8342681e660718da5c0be61733f59d18 +# +# +# +# +# +# Base class for the configuration and results of ranging definitions. +# +# Ranging is a data post-processing step used in the research field of +# atom probe during which elemental, isotopic, and/or molecular identities +# are assigned to mass-to-charge-state-ratios within a certain interval. +# The documentation of these steps is based on ideas that +# have been described in the literature: +# +# * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ +# * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ +# * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ +# +# +# +# +# +# How many ion types are distinguished. If no ranging was performed, each +# ion is of the special unknown type. The iontype ID of this unknown type +# is 0 representing a reserve value. Consequently, +# iontypes start counting from 1. +# +# +# +# +# Assumed maximum value that suffices to store all relevant +# molecular ions, even the most complicated ones. +# Currently, a value of 32 is used (see M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_). +# +# +# +# +# Specifies the mass-to-charge-state-ratio histogram. +# +# +# +# +# Smallest, increment, and largest mass-to-charge-state ratio value. +# +# +# +# +# +# +# +# A default histogram aka mass spectrum of +# the mass-to-charge-state ratio values. +# +# +# +# +# +# Details of the background model that was used to +# correct the total counts per bin into counts. +# +# +# +# +# To begin with we use a free-text field to learn how +# atom probers define a background model. Future versions +# of NXapm_ranging can then use this information to parameterize +# these models. +# +# +# +# +# +# +# How where peaks in the background-corrected in the histogram +# of mass-to-charge-state ratio values identified? +# +# +# +# +# +# +# Details about how peaks, with taking into account +# error models, were interpreted as ion types or not. +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_reconstruction.yaml b/contributed_definitions/nyaml/NXapm_reconstruction.yaml index 5529442a0c..7b9d5a9542 100644 --- a/contributed_definitions/nyaml/NXapm_reconstruction.yaml +++ b/contributed_definitions/nyaml/NXapm_reconstruction.yaml @@ -17,9 +17,11 @@ symbols: the pulse_identifier! type: group NXapm_reconstruction(NXprocess): + # when evolving these ideas further inherit from NXapm_method instead (NXprogram): (NXserialized): + # config/input parameter(NX_CHAR): doc: | @@ -42,25 +44,31 @@ NXapm_reconstruction(NXprocess): If no crystallographic calibration was performed, the field should be filled with the n/a, meaning not applied. + # results field_of_view(NX_FLOAT): + unit: NX_LENGTH + # typically in nm reconstruction space not detector coordinates doc: | The nominal diameter of the specimen ROI which is measured in the experiment. The physical specimen cannot be measured completely because ions may launch but hit in locations other than the detector. - unit: NX_LENGTH reconstructed_positions(NX_FLOAT): + unit: NX_LENGTH doc: | Three-dimensional reconstructed positions of the ions. - unit: NX_LENGTH - dim: (n, 3) - \@depends_on(NX_CHAR): + dimensions: + rank: 2 + dim: [[1, n], [2, 3]] + \@depends_on: + type: NX_CHAR doc: | The instance of :ref:`NXcoordinate_system` in which the positions are defined. naive_discretization(NXprocess): (NXprogram): + # config/input # results (NXdata): @@ -69,3 +77,129 @@ NXapm_reconstruction(NXprocess): here a 3d histogram of the ion is stored. Ion counts are characterized using one nanometer cubic bins without applying position smoothening algorithms during the histogram computation. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 2b9ccfe6bd216a1724e272108c536d01562d827dcc129981755fb36cc98e65d0 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of ions spatially filtered from results of the hit_finding algorithm +# :ref:`NXapm_hit_finding` from which an instance of a reconstructed volume +# has been generated. These ions get new identifier assigned in the process - +# the so-called evaporation_identifier, which must not be confused with +# the pulse_identifier! +# +# +# +# +# Base class for the configuration and results of a (static) reconstruction algorithm. +# +# Generating a tomographic reconstruction of the specimen uses selected and +# calibrated ion hit positions, the evaporation sequence, and voltage curve data. +# Very often scientists use own software scripts according to published procedures, +# so-called reconstruction protocols. +# +# +# +# +# +# +# +# Different reconstruction protocols exist. Although these approaches +# are qualitatively similar, each protocol uses different parameters +# (and interprets these differently). The source code to IVAS/APSuite +# is not open. For now users should store reconstruction parameter +# in this free-text field to guide how to parameterize this better in the +# future. For LEAP systems and reconstructions performed with IVAS/APSuite +# see `T. Blum et al. <https://doi.org/10.1002/9781119227250.ch18>`_ (page 371). +# +# +# +# +# Qualitative statement about which reconstruction protocol was used. +# +# +# +# +# +# +# +# +# +# +# +# Different strategies for crystallographic calibration of the +# reconstruction are possible. Therefore, we collect first such +# feedback before parameterizing this further. +# +# If no crystallographic calibration was performed, the field +# should be filled with the n/a, meaning not applied. +# +# +# +# +# +# +# The nominal diameter of the specimen ROI which is measured in the +# experiment. The physical specimen cannot be measured completely +# because ions may launch but hit in locations other than the detector. +# +# +# +# +# Three-dimensional reconstructed positions of the ions. +# +# +# +# +# +# +# +# The instance of :ref:`NXcoordinate_system` +# in which the positions are defined. +# +# +# +# +# +# +# +# +# To get a first visual overview of the reconstructed dataset, +# here a 3d histogram of the ion is stored. Ion counts are characterized +# using one nanometer cubic bins without applying position smoothening +# algorithms during the histogram computation. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_sim.yaml b/contributed_definitions/nyaml/NXapm_sim.yaml index 9f584c1019..48205ae492 100644 --- a/contributed_definitions/nyaml/NXapm_sim.yaml +++ b/contributed_definitions/nyaml/NXapm_sim.yaml @@ -8,9 +8,53 @@ doc: | The strategy to achieve this is detailed in the introducing docstring of :ref:`NXapm_msr`. This :ref:`NXapm_sim` base class is envisioned as the twin of the :ref:`NXapm_msr` base class. + # noteworthy the situation is similar to electron microscopy especially TEM where factually # interpretation without simulations is pointless. The only difference is that in EM there # is a large availability of documentation and open-source tools for performing such simulations. type: group -NXapm_sim(NXobject): # when evolving these ideas further inherit from NXapm_method instead +NXapm_sim(NXobject): (NXprogram): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# f09cde6d7b39bd99afbf369ca236f3bcc81c1e41b12720bae3ecd2eefd4c026c +# +# +# +# +# +# +# Base class for simulating ion extraction from matter via laser and/or voltage pulsing. +# +# Ideally, we would like to describe the workflow of experiments and simulations of +# atom probe and field-evaporation simulation research in more detail and contextualize +# better descriptions of experiments and computer simulations. +# The strategy to achieve this is detailed in the introducing docstring of +# :ref:`NXapm_msr`. This :ref:`NXapm_sim` base class is envisioned as the +# twin of the :ref:`NXapm_msr` base class. +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_volt_and_bowl.yaml b/contributed_definitions/nyaml/NXapm_volt_and_bowl.yaml index 5a52bd765c..9700d40639 100644 --- a/contributed_definitions/nyaml/NXapm_volt_and_bowl.yaml +++ b/contributed_definitions/nyaml/NXapm_volt_and_bowl.yaml @@ -14,9 +14,10 @@ symbols: the so-called evaporation_identifier, which must not be confused with the pulse_identifier! type: group -NXapm_volt_and_bowl(NXprocess): # when evolving these ideas further inherit from NXapm_method instead +NXapm_volt_and_bowl(NXprocess): (NXprogram): (NXserialized): + # config/input to the algorithm # 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). @@ -24,12 +25,88 @@ NXapm_volt_and_bowl(NXprocess): # when evolving these ideas further inherit fro # (as an intermediate/compromise solution) are required in this version of the application definition # result raw_tof(NX_FLOAT): + unit: NX_TIME doc: | Raw time-of-flight data without corrections. - unit: NX_TIME - dim: (n,) + dimensions: + rank: 1 + dim: [[1, n]] calibrated_tof(NX_FLOAT): + unit: NX_TIME doc: | Calibrated time-of-flight. - unit: NX_TIME - dim: (n,) + dimensions: + rank: 1 + dim: [[1, n]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e5f86e813b55935bdb6edcb66614c78722f494931dfdd588ac7c86edbb7ab3f7 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of ions spatially filtered from results of the hit_finding algorithm +# :ref:`NXapm_hit_finding` from which an instance of a reconstructed volume +# has been generated. These ions get new identifier assigned in the process - +# the so-called evaporation_identifier, which must not be confused with +# the pulse_identifier! +# +# +# +# +# Base class for the configuration and results from a voltage-and-bowl ToF correction algorithm. +# +# The voltage-and-bowl correction is a ata post-processing step to correct for ion impact position +# flight path differences, detector biases, and nonlinearities. +# +# +# +# +# +# +# Raw time-of-flight data without corrections. +# +# +# +# +# +# +# +# Calibrated time-of-flight. +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXatom_set.yaml b/contributed_definitions/nyaml/NXatom_set.yaml index 3e83a1beff..42d8dc5608 100644 --- a/contributed_definitions/nyaml/NXatom_set.yaml +++ b/contributed_definitions/nyaml/NXatom_set.yaml @@ -19,12 +19,13 @@ NXatom_set(NXobject): How can the identifier be resolved? enumeration: [inchi] ion_type(NX_UINT): + unit: NX_UNITLESS doc: | Ion type (ion species) identifier. The identifier zero is reserved for the special unknown ion type. - unit: NX_UNITLESS nuclide_hash(NX_UINT): + unit: NX_UNITLESS doc: | Vector of nuclide hash values. @@ -33,9 +34,11 @@ NXatom_set(NXobject): of each nuclide respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. The array is sorted in decreasing order. For the rationale behind this see `M. Kühbach et al. (2021) `_ - unit: NX_UNITLESS - dim: (n_ivec_max,) + dimensions: + rank: 1 + dim: [[1, n_ivec_max]] nuclide_list(NX_UINT): + unit: NX_UNITLESS doc: | Table which decodes the entries in nuclide_hash into a human-readable matrix of instances. The first column specifies the nuclide mass number, i.e. using the hashvalues @@ -50,24 +53,27 @@ NXatom_set(NXobject): Therefore, this notation is the typical superscribed nuclide mass number and subscripted number of protons element notation e.g. :math:`^{14}C`. The array is stored matching the order of nuclide_hash. - unit: NX_UNITLESS - dim: (n_ivecmax, 2) + dimensions: + rank: 2 + dim: [[1, n_ivecmax], [2, 2]] + # color(NX_CHAR): - # doc: | - # Color code used for visualizing such ions. + # doc: | + # Color code used for visualizing such ions. volume(NX_NUMBER): + unit: NX_VOLUME doc: | Assumed volume of the ion. In atom probe microscopy this field can be used to store the reconstructed volume per ion (average) which is typically stored alongside ranging definitions. - unit: NX_VOLUME charge(NX_NUMBER): + unit: NX_CHARGE doc: | Charge of the ion. - unit: NX_CHARGE charge_state(NX_NUMBER): + unit: NX_UNITLESS doc: | Signed charge state if the atoms form an ion reported in multiples of electron charge. @@ -83,7 +89,6 @@ NXatom_set(NXobject): surplus the mass-to-charge-state-ratio interval. Details on ranging definition files can be found in the literature: `M. K. Miller `_ - unit: NX_UNITLESS name(NX_CHAR): doc: | Human-readable name (e.g. Al +++) of the atom set, the atom group, or ion type. @@ -94,11 +99,174 @@ NXatom_set(NXobject): To ease automated parsing, isotope_vector should be the preferred machine-readable information used. mass_to_charge_range(NX_NUMBER): + unit: NX_ANY doc: | Associated lower (mqmin) and upper (mqmax) bounds of the mass-to-charge-state ratio interval(s) [mqmin, mqmax] (boundaries inclusive). This field is primarily of interest for documenting :ref:`NXprocess` steps of indexing a ToF/mass-to-charge state histogram. - unit: NX_ANY # u - dim: (n_ranges, 2) + dimensions: + rank: 2 + dim: [[1, n_ranges], [2, 2]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# c26dcba4e94437fe019c3272bb4116881a59cc9838687a28f48616de696e202c +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). +# +# +# +# +# Number of mass-to-charge-state-ratio range intervals for ion type. +# +# +# +# +# Base class for documenting a set of atoms. +# +# +# +# A unique identifier whereby such an ion can be referred to +# via the service offered as described in identifier_type. +# +# +# +# +# How can the identifier be resolved? +# +# +# +# +# +# +# +# Ion type (ion species) identifier. +# +# The identifier zero is reserved for the special unknown ion type. +# +# +# +# +# Vector of nuclide hash values. +# +# Individual hash values :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` +# encode the number of protons :math:`Z` and the number of neutrons :math:`N` +# of each nuclide respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. +# +# The array is sorted in decreasing order. For the rationale behind this see `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ +# +# +# +# +# +# +# +# Table which decodes the entries in nuclide_hash into a human-readable matrix of instances. +# The first column specifies the nuclide mass number, i.e. using the hashvalues +# from the isotope_vector this is :math:`Z + N` or 0. The value 0 documents that no +# isotope-specific information about the element encoded is relevant. +# The second row specifies the number of protons :math:`Z` or 0. +# The value 0 in this case documents a placeholder or that no element-specific +# information is relevant. +# Taking a carbon-14 nuclide as an example the mass number is 14. +# That is encoded as a value pair (14, 6) as one row of the table. +# +# Therefore, this notation is the typical superscribed nuclide mass number +# and subscripted number of protons element notation e.g. :math:`^{14}C`. +# The array is stored matching the order of nuclide_hash. +# +# +# +# +# +# +# +# +# +# Assumed volume of the ion. +# +# In atom probe microscopy this field can be used to store the reconstructed +# volume per ion (average) which is typically stored alongside ranging +# definitions. +# +# +# +# +# Charge of the ion. +# +# +# +# +# Signed charge state if the atoms form an ion reported in multiples of electron charge. +# +# In the example of atom probe microscopy, only positive values will be measured +# as the ions are accelerated by a negatively signed bias electric field. +# In the case that the charge state is not explicitly recoverable, the value should +# be set to zero. +# +# In atom probe microscopy this is for example the case when using +# classical ranging definition files in formats like RNG, RRNG. +# These file formats do not document the charge state explicitly +# but the number of atoms of each element per molecular ion +# surplus the mass-to-charge-state-ratio interval. +# Details on ranging definition files can be found in the literature: +# `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ +# +# +# +# +# Human-readable name (e.g. Al +++) of the atom set, the atom group, or ion type. +# The string should consists of UTF-8 characters, ideally using LaTeX +# notation to specify the isotopes, ions, and charge state. +# Examples are 12C + or Al +++. +# +# To ease automated parsing, isotope_vector should be the +# preferred machine-readable information used. +# +# +# +# +# Associated lower (mqmin) and upper (mqmax) bounds of the +# mass-to-charge-state ratio interval(s) [mqmin, mqmax] +# (boundaries inclusive). This field is primarily of interest +# for documenting :ref:`NXprocess` steps of indexing a +# ToF/mass-to-charge state histogram. +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXbeam_device.yaml b/contributed_definitions/nyaml/NXbeam_device.yaml index 3e1a236b6b..0d8754c60f 100644 --- a/contributed_definitions/nyaml/NXbeam_device.yaml +++ b/contributed_definitions/nyaml/NXbeam_device.yaml @@ -1,41 +1,106 @@ -category: base +category: base doc: | Properties of generic beam device in an experimental setup. - + Any beam related devices like source, detector, filter, mirror, beamsplitter, ... which may modifies a beam in an experimental setup can be described here with its experimental position and relationship to the other beam devices in the setup. - - +type: group NXbeam_device(NXobject): - - previous_devices: + previous_devices: doc: | Single device or list of devices pointing to the devices from which an beam originated to reach this device. This is used to describe a logical order of devices and for the whole setup. - In this way, a "beam path" can be described (i.e., with starting point (light source) + In this way, a "beam path" can be described (i.e., with starting point (light source) and end point (photo detector)). - + Example: /entry/instrument/detector. - purpose(NX_CHAR): + purpose(NX_CHAR): doc: | Description of the intended purpose of this device for the experimental setup. - - group(NX_CHAR): + group(NX_CHAR): doc: | Name of the group with which this device can be associated. For example, if a group of devices is used for second harmonic generation, all these devices have the group name "second harmonic generation". Is used for simplified setup vizualization (or description?). - - (NXtransformations): doc: | Location and orientation of the device. Note that even a simple distance can be given as a translation. - + You can use the @depends_on to describe from which device - the transformation needs to be applied. \ No newline at end of file + the transformation needs to be applied. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 55ae98919e366f5b67cdeef618353257b5946ff077f8264a0bdd476cf84aef2d +# +# +# +# +# +# Properties of generic beam device in an experimental setup. +# +# Any beam related devices like source, detector, filter, mirror, +# beamsplitter, ... which may modifies a beam in an experimental setup +# can be described here with its experimental position and relationship +# to the other beam devices in the setup. +# +# +# +# Single device or list of devices pointing to the devices from which an +# beam originated to reach this device. +# This is used to describe a logical order of devices and for the whole setup. +# In this way, a "beam path" can be described (i.e., with starting point (light source) +# and end point (photo detector)). +# +# Example: /entry/instrument/detector. +# +# +# +# +# Description of the intended purpose of this device for +# the experimental setup. +# +# +# +# +# Name of the group with which this device can be associated. +# For example, if a group of devices is used for second harmonic generation, +# all these devices have the group name "second harmonic generation". +# Is used for simplified setup vizualization (or description?). +# +# +# +# +# Location and orientation of the device. Note that even a +# simple distance can be given as a translation. +# +# You can use the @depends_on to describe from which device +# the transformation needs to be applied. +# +# +# diff --git a/contributed_definitions/nyaml/NXbeam_path.yaml b/contributed_definitions/nyaml/NXbeam_path.yaml index f7651dee2a..033c921fda 100644 --- a/contributed_definitions/nyaml/NXbeam_path.yaml +++ b/contributed_definitions/nyaml/NXbeam_path.yaml @@ -325,13 +325,13 @@ NXbeam_path(NXobject): (NXfiber): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f0ed01c487c4175dc723d226e0d33b89fa8107576fe95b4f0b825c1f91244ccc +# 0b40f84f18c8bc51a531cc03107424f093dcc0502a98f3fff220df30e4d9de29 # # # +# +# +# +# Variables used throughout the document, e.g. dimensions or parameters. +# +# +# +# Length of the array associated to the data type. +# +# +# +# +# Contains datastructures of an experimental optical setup (i.e., multiple +# transfermatrix tables). These datastructures are used to relate physical +# properties of two beams (NXbeam) which have one common optical element +# (NXopt_element) (one specific transfermatrix). +# One of these beams in an input beam and the other one is an output beam. +# +# The data describes the change of beam properties, e.g. the intensity of a +# beam is reduced because the transmission coefficient of the beam device is +# lower than 1. +# +# +# +# Select which type of data was recorded, for example aperture and +# focal length. +# It is possible to have multiple selections. This selection defines +# how many columns (N_variables) are stored in the data array. +# N in the name, is the index number in which order the given +# property is listed. +# +# +# +# +# +# +# +# +# +# +# Please list in this array the column and row names used in your actual data. +# That is in the case of aperture ['diameter'] or focal length ['focal_length_value'] +# and for orientation matrix ['OM1', 'OM2', 'OM3'] or for jones matrix +# ['JM1','JM2'] +# +# +# +# +# +# +# +# Contains the datastructure which relates beam properties of an +# input and output beam as result of the input beam interaction +# with the beam device. +# +# Transfermatrix relationship between N input beams and M output beams. +# It contains a table with the relevant matricis to be used for different +# transmissitted properties (such as polarization, intensity, phase). +# +# Data structure for all transfermatrices of an beam device in a setup. +# For each combination of N input and M output beams and for L physical +# concept (i.e. beam intensity), one matrix can be defined. +# +# In this way, the transfermatrix table has the dimension NxM. +# +# For each entry, in this transfermatrix, there are L formalisms. +# Each formalism has the dimension math:`dim(L_i)xdim(L_i)`, +# whereby math:`L_i` is the specific physical concept (Intensity, polarization, direction). +# +# A beamsplitter with two input laser beams can have a total of +# four transfermatrices (2 Input x 2 Output). +# +# The dimension of the transfermatrix depends on the parameters. +# Examples are: +# 1x1 for intensity/power +# 2x2 for jones formalism +# 3x3 for direction +# +# +# +# Square matrix with dimension N_variables x N_variables +# +# +# +# +# +# +# Specific name of input beam which the transfermatrix table is related to. +# +# +# +# +# Specific name of output beam which the transfermatrix table is related to. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXbias_spectroscopy.yaml b/contributed_definitions/nyaml/NXbias_spectroscopy.yaml index 87971be740..98d8007058 100644 --- a/contributed_definitions/nyaml/NXbias_spectroscopy.yaml +++ b/contributed_definitions/nyaml/NXbias_spectroscopy.yaml @@ -111,7 +111,7 @@ NXbias_spectroscopy(NXobject): are disabled. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a3079d513b63e99022e710b15756f7cd46a7101b306d34339dc6d6b3c7d685b1 +# 49c9177d438f869e26204da8b11b2075834bc253f2e9578f1f66bfa20be23db9 # # # +# +# +# +# Computational geometry of alpha shapes or alpha wrappings about primitives. +# +# For details see: +# +# * https://dx.doi.org/10.1109/TIT.1983.1056714 for 2D, +# * https://dx.doi.org/10.1145/174462.156635 for 3D, +# * https://dl.acm.org/doi/10.5555/871114 for weighted, and +# * https://doc.cgal.org/latest/Alpha_shapes_3 for 3D implementation +# * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D wrappings +# +# in CGAL, the Computational Geometry Algorithms Library. +# As a starting point, we follow the conventions of the CGAL library. +# +# +# +# Type of alpha complex following the terminology used by CGAL for now. +# +# Basic means (unweighted) alpha shapes. Alpha_wrapping means meshes +# created using the alpha_wrapping algorithm. +# +# +# +# +# +# +# +# +# +# Are singular faces removed, i.e. has the alpha complex +# been regularized or not. +# +# +# +# +# +# The alpha parameter, i.e. the radius of the alpha-sphere that +# is used when computing the alpha complex. +# +# +# +# +# +# The offset distance parameter used when computing alpha_wrappings. +# +# +# +# +# +# +# Point cloud for which the alpha shape or wrapping has been computed. +# +# +# +# +# +# Triangle soup for which the alpha wrapping has been computed. +# +# +# +# +# Triangle mesh representing the alpha complex. +# +# +# +# +# +# Set of tetrahedra representing the volume inside the alpha complex. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_cylinder_set.yaml b/contributed_definitions/nyaml/NXcg_cylinder_set.yaml index 65b686032e..b62b9f9f39 100644 --- a/contributed_definitions/nyaml/NXcg_cylinder_set.yaml +++ b/contributed_definitions/nyaml/NXcg_cylinder_set.yaml @@ -12,16 +12,20 @@ symbols: The dimensionality of the space in which the members are assumed embedded. c: | The cardinality of the set, i.e. the number of members. + # redundant as there is NXcsg, NXquadric, NXsolid_geometry with which # cylinder could be constructed, but NXcylinder is easier to understand type: group NXcg_cylinder_set(NXcg_primitive_set): height(NX_NUMBER): + unit: NX_LENGTH doc: | A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - unit: NX_LENGTH - dim: (c, d) + dimensions: + rank: 2 + dim: [[1, c], [2, d]] + # observe that although we claim that d is the dimensionality we have # currently no strategy to tell it must not be d but the actual value # equally so the symbol c, currently all we say that in the specialization @@ -34,54 +38,218 @@ NXcg_cylinder_set(NXcg_primitive_set): # maybe a future feature for representing skewed cylinder, but then # one should really better use NXquadric... radius(NX_NUMBER): + unit: NX_LENGTH doc: | Radius of the cylinder if all have the same radius. - unit: NX_LENGTH radii(NX_NUMBER): + unit: NX_LENGTH doc: | Radii of the cylinder. - unit: NX_LENGTH - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] upper_cap_radii(NX_NUMBER): + unit: NX_LENGTH doc: | Radii of the upper circular cap. This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - unit: NX_LENGTH - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] lower_cap_radii(NX_NUMBER): + unit: NX_LENGTH doc: | Radii of the upper circular cap. This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - unit: NX_LENGTH - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] + # properties of the cylinder lateral_surface_area(NX_NUMBER): + unit: NX_AREA doc: | Lateral surface area - unit: NX_AREA - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] upper_cap_surface_area(NX_NUMBER): + unit: NX_AREA doc: | Area of the upper cap of each cylinder. - unit: NX_AREA - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] lower_cap_surface_area(NX_NUMBER): + unit: NX_AREA doc: | Area of the lower cap of each cylinder. + dimensions: + rank: 1 + dim: [[1, c]] + total_surface_area(NX_NUMBER): unit: NX_AREA - dim: (c,) - total_surface_area(NX_NUMBER): # example for a specialization of surface_area from the NXcg_primitive_set doc: | Sum of upper and lower cap areas and lateral surface area of each cylinder. - unit: NX_AREA - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] + # again cap, lateral surface area and volume are so trivial to compute # do we need really storage for this or recompute on-the-fly? # similarly to hollow sphere discussion, hollow cylinder, cylinder stack # do wish to define intersections?, if this is the case, one # should use the NXcsg and NXquadric descriptions? + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e9a054e62040918896089e116671843d5eab36a89e2f4d2c48e27266b9edf7b9 +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality of the space in which the members are assumed embedded. +# +# +# +# +# The cardinality of the set, i.e. the number of members. +# +# +# +# +# Computational geometry description of a set of cylinders. +# +# The radius can either be defined in the radii field or by filling both +# the upper_cap_radii or lower_cap_radii field. The latter field case can +# thus be used to represent truncated cones. +# +# +# +# A direction vector which is parallel to the cylinder/cone axis +# and whose magnitude is the height of the cylinder/cone. +# +# +# +# +# +# +# +# +# +# Radius of the cylinder if all have the same radius. +# +# +# +# +# Radii of the cylinder. +# +# +# +# +# +# +# +# Radii of the upper circular cap. +# +# This field, combined with lower_cap_radius can be used to describe +# (eventually truncated) circular cones. +# +# +# +# +# +# +# +# Radii of the upper circular cap. +# +# This field, combined with upper_cap_radius can be used to describe +# (eventually truncated) circular cones. +# +# +# +# +# +# +# +# +# Lateral surface area +# +# +# +# +# +# +# +# Area of the upper cap of each cylinder. +# +# +# +# +# +# +# +# Area of the lower cap of each cylinder. +# +# +# +# +# +# +# +# Sum of upper and lower cap areas and lateral surface area +# of each cylinder. +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml b/contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml index 9aab0dffaf..458fef8c95 100644 --- a/contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml +++ b/contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml @@ -8,19 +8,93 @@ symbols: The dimensionality of the space in which the members are assumed embedded. c: | The cardinality of the set, i.e. the number of members. + # redundant as there is NXcsg, and NXquadric but easier to understand type: group NXcg_ellipsoid_set(NXcg_primitive_set): half_axes_radius(NX_NUMBER): + unit: NX_LENGTH doc: | Radius of the half axes. Use if all ellipsoids in the set have the same half-axes. - unit: NX_LENGTH - dim: (d,) + dimensions: + rank: 1 + dim: [[1, d]] half_axes_radii(NX_NUMBER): + unit: NX_LENGTH doc: | Half-axes radii of each ellipsoid. - unit: NX_LENGTH - dim: (c, d) + dimensions: + rank: 2 + dim: [[1, c], [2, d]] + # properties of ellipsoids + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 3cc31e0d50ce63b233b0995dfb69b62f89ab5908bb19ff8d7f339f5bc000fcbf +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality of the space in which the members are assumed embedded. +# +# +# +# +# The cardinality of the set, i.e. the number of members. +# +# +# +# +# Computational geometry description of a set of ellipsoids. +# +# +# +# Radius of the half axes. +# +# Use if all ellipsoids in the set have the same half-axes. +# +# +# +# +# +# +# +# Half-axes radii of each ellipsoid. +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml b/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml index 839b63e143..3e4209583a 100644 --- a/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml +++ b/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml @@ -29,70 +29,83 @@ symbols: The total number of vertices of all faces. Faces are polygons. n_weinberg: | The total number of Weinberg vector values of all faces. + # duplicate of an NXoff_geometry ? type: group NXcg_face_list_data_structure(NXcg_primitive_set): + # resulting in a design similar to that of NXoff_geometry and the XDMF mixed primitive topology number_of_vertices(NX_INT): + unit: NX_UNITLESS doc: | Number of vertices for each face. Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - unit: NX_UNITLESS - dim: (n_f,) + dimensions: + rank: 1 + dim: [[1, n_f]] number_of_edges(NX_INT): + unit: NX_UNITLESS doc: | Number of edges for each face. Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - unit: NX_UNITLESS - dim: (n_e,) + dimensions: + rank: 1 + dim: [[1, n_e]] number_of_faces(NX_INT): + unit: NX_UNITLESS doc: | Number of faces of the primitives. - unit: NX_UNITLESS vertex_identifier_offset(NX_INT): + unit: NX_UNITLESS doc: | Integer offset whereby the identifier of the first member of the vertices differs from zero. Identifier can be defined explicitly or implicitly. Inspect the definition of NXcg_primitive_set for further details. - unit: NX_UNITLESS edge_identifier_offset(NX_INT): + unit: NX_UNITLESS doc: | Integer offset whereby the identifier of the first member of the edges differs from zero. Identifier can be defined explicitly or implicitly. Inspect the definition of NXcg_primitive_set for further details. - unit: NX_UNITLESS face_identifier_offset(NX_INT): + unit: NX_UNITLESS doc: | Integer offset whereby the identifier of the first member of the faces differs from zero. Identifier can be defined explicitly or implicitly. Inspect the definition of NXcg_primitive_set for further details. - unit: NX_UNITLESS vertex_identifier(NX_INT): unit: NX_UNITLESS doc: | Integer identifier to distinguish all vertices explicitly. - dim: (n_v,) + dimensions: + rank: 1 + dim: [[1, n_v]] edge_identifier(NX_INT): + unit: NX_UNITLESS doc: | Integer used to distinguish all edges explicitly. - unit: NX_UNITLESS - dim: (n_e,) + dimensions: + rank: 1 + dim: [[1, n_e]] face_identifier(NX_INT): + unit: NX_UNITLESS doc: | Integer used to distinguish all faces explicitly. - unit: NX_UNITLESS - dim: (n_f,) + dimensions: + rank: 1 + dim: [[1, n_f]] vertices(NX_NUMBER): + unit: NX_ANY doc: | Positions of the vertices. @@ -101,14 +114,18 @@ NXcg_face_list_data_structure(NXcg_primitive_set): It is also possible though to store the vertex positions naively in which case vertices_are_unique is likely False. Naively here means that each vertex is stored even though many share the same positions. - unit: NX_ANY - dim: (n_v, d) + dimensions: + rank: 2 + dim: [[1, n_v], [2, d]] edges(NX_INT): + unit: NX_UNITLESS doc: | The edges are stored as pairs of vertex identifier. - unit: NX_UNITLESS - dim: (n_e, 2) + dimensions: + rank: 2 + dim: [[1, n_e], [2, 2]] faces(NX_INT): + unit: NX_UNITLESS doc: | The faces are stored as a concatenated array of vertex identifier tuples. @@ -120,8 +137,10 @@ NXcg_face_list_data_structure(NXcg_primitive_set): Therefore, summating over the number_of_vertices, allows to extract the vertex identifiers for the i-th face on the following index interval of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. - unit: NX_UNITLESS - dim: (n_total,) + dimensions: + rank: 1 + dim: [[1, n_total]] + # properties vertices_are_unique(NX_BOOLEAN): doc: | @@ -137,11 +156,246 @@ NXcg_face_list_data_structure(NXcg_primitive_set): doc: | If true, indicates that no face is stored more than once. winding_order(NX_INT): + unit: NX_UNITLESS doc: | Specifies for each face which winding order was used if any: * 0 - undefined * 1 - counter-clockwise (CCW) * 2 - clock-wise (CW) - unit: NX_UNITLESS - dim: (n_f,) + dimensions: + rank: 1 + dim: [[1, n_f]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# a3f36a3c5cda218227a8cbbc7e4877ec1e017989bfb731d809d586ab9af271ea +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality, which has to be at least 2. +# +# +# +# +# The number of vertices. +# +# +# +# +# The number of edges. +# +# +# +# +# The number of faces. +# +# +# +# +# The total number of vertices of all faces. Faces are polygons. +# +# +# +# +# The total number of Weinberg vector values of all faces. +# +# +# +# +# Computational geometry of primitives via a face-and-edge-list data structure. +# +# Primitives must neither be degenerated nor self-intersect but can differ in +# their properties. A face-and-edge-list-based description of primitives is +# frequently used for triangles and polyhedra to store them on disk for +# visualization purposes (see OFF, PLY, VTK, or STL file formats). +# +# Although this description is storage efficient it is not well suited for +# topological analyses though. In this case, scientists may need a different +# view on the primitives which is better represented with e.g. a +# half_edge_data_structure. +# +# Having an own base class for the data structure how primitives are stored is +# useful to embrace both users with small or very detailed specification demands. +# +# +# +# +# Number of vertices for each face. +# +# Each entry represents the total number of vertices for that face, +# irrespectively whether vertices are shared among faces or not. +# +# +# +# +# +# +# +# Number of edges for each face. +# +# Each entry represents the total number of edges for that face, +# irrespectively whether edges are shared across faces or not. +# +# +# +# +# +# +# +# Number of faces of the primitives. +# +# +# +# +# Integer offset whereby the identifier of the first member +# of the vertices differs from zero. +# +# Identifier can be defined explicitly or implicitly. +# Inspect the definition of NXcg_primitive_set for further details. +# +# +# +# +# Integer offset whereby the identifier of the first member +# of the edges differs from zero. +# +# Identifier can be defined explicitly or implicitly. +# Inspect the definition of NXcg_primitive_set for further details. +# +# +# +# +# Integer offset whereby the identifier of the first member +# of the faces differs from zero. +# +# Identifier can be defined explicitly or implicitly. +# Inspect the definition of NXcg_primitive_set for further details. +# +# +# +# +# Integer identifier to distinguish all vertices explicitly. +# +# +# +# +# +# +# +# Integer used to distinguish all edges explicitly. +# +# +# +# +# +# +# +# Integer used to distinguish all faces explicitly. +# +# +# +# +# +# +# +# Positions of the vertices. +# +# Users are encouraged to reduce the vertices to a unique set as this may +# result in a more efficient storage of the geometry data. +# It is also possible though to store the vertex positions naively in which +# case vertices_are_unique is likely False. Naively here means that each +# vertex is stored even though many share the same positions. +# +# +# +# +# +# +# +# +# The edges are stored as pairs of vertex identifier. +# +# +# +# +# +# +# +# +# The faces are stored as a concatenated array of vertex identifier tuples. +# +# The first entry is the identifier of the start vertex of the first face, +# followed by the second vertex of the first face, until the last vertex +# of the first face. Thereafter, the start vertex of the second face, the +# second vertex of the second face, and so on and so forth. +# +# Therefore, summating over the number_of_vertices, allows to extract +# the vertex identifiers for the i-th face on the following index interval +# of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. +# +# +# +# +# +# +# +# +# If true, indicates that the vertices are all placed at different positions +# and have different identifiers, i.e. no points overlap or are counted more +# than once. +# +# +# +# +# If true, indicates that no edge is stored more than once. +# +# Users are encouraged to consider using a half_edge_data_structure instead. +# +# +# +# +# If true, indicates that no face is stored more than once. +# +# +# +# +# Specifies for each face which winding order was used if any: +# +# * 0 - undefined +# * 1 - counter-clockwise (CCW) +# * 2 - clock-wise (CW) +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml b/contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml index 0f4f9afc64..32c49e2392 100644 --- a/contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml +++ b/contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml @@ -29,3 +29,61 @@ NXcg_geodesic_mesh(NXcg_primitive_set): (NXcg_triangulated_surface_mesh): # Discussions with NFDI-Earth could make this base class more meaty and detailed. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# b3dfb393b42a5745efb9464494cea2ba9f08fe0d876869838c299650036eba7f +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Computational geometry description of a geodesic mesh. +# +# A geodesic surface mesh is a triangulated surface mesh with metadata which +# can be used as an approximation to describe the surface of a sphere. +# Triangulation of spheres are commonly used in Materials Science +# for quantifying texture of materials, i.e. the relative rotation of +# crystals to sample directions. +# +# For additional details or an introduction into the topic of geodesic meshes +# see (from which specifically the section on subdivision schemes is relevant). +# +# * `E. S. Popko and C. J. Kitrick <https://doi.org/10.1201/9781003134114>`_ +# +# Earth scientists have specific demands and different views about what should +# be included in such a base class, given that nested geodesic meshes are a key +# component of climate modelling software. For now we propose to use this +# base class as a container for organizing data related to geodesic meshes. +# +# Specifically an instance of this base class should detail the rule set how +# e.g. a geodesic (surface) mesh was instantiated as there are many +# possibilities to do so. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_grid.yaml b/contributed_definitions/nyaml/NXcg_grid.yaml index c8714998b2..45c8654447 100644 --- a/contributed_definitions/nyaml/NXcg_grid.yaml +++ b/contributed_definitions/nyaml/NXcg_grid.yaml @@ -18,23 +18,28 @@ symbols: type: group NXcg_grid(NXcg_primitive_set): origin(NX_NUMBER): + unit: NX_ANY doc: | Location of the origin of the grid. Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - unit: NX_ANY - dim: (d,) + dimensions: + rank: 1 + dim: [[1, d]] symmetry(NX_CHAR): doc: | The symmetry of the lattice defining the shape of the unit cell. - enumeration: [cubic] # enumerate all other possible tilings of R^d + enumeration: [cubic] cell_dimensions(NX_NUMBER): + unit: NX_LENGTH doc: | The unit cell dimensions using crystallographic notation. - unit: NX_LENGTH - dim: (d,) + dimensions: + rank: 1 + dim: [[1, d]] extent(NX_UINT): + unit: NX_UNITLESS doc: | Number of unit cells along each of the d unit vectors. @@ -43,39 +48,49 @@ NXcg_grid(NXcg_primitive_set): as it could be for instance the case of a grid where all grid points outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - unit: NX_UNITLESS - dim: (d,) + dimensions: + rank: 1 + dim: [[1, d]] + # number_of_cells(NX_UINT): maybe already too trivial quantities # should constraints on the grid be place here or not position(NX_NUMBER): + unit: NX_ANY doc: | Position of each cell in Euclidean space. - unit: NX_ANY - dim: (c, d) + dimensions: + rank: 2 + dim: [[1, c], [2, d]] coordinate(NX_INT): + unit: NX_DIMENSIONLESS doc: | Coordinate of each cell with respect to the discrete grid. - unit: NX_DIMENSIONLESS - dim: (c, d) + dimensions: + rank: 2 + dim: [[1, c], [2, d]] + # this should be a ROI bounding_box(NXcg_polyhedron_set): doc: | A tight bounding box about the grid. - # does it have to be a tight bounding box? + + # does it have to be a tight bounding box? # a good example for a general bounding box description for such a grids of triclinic cells # https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallelepiped number_of_boundaries(NX_INT): + unit: NX_UNITLESS doc: | Number of boundaries distinguished Most grids discretize a cubic or cuboidal region. In this case six sides can be distinguished, each making an own boundary. - unit: NX_UNITLESS boundaries(NX_CHAR): doc: | Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - dim: (n_b,) + dimensions: + rank: 1 + dim: [[1, n_b]] boundary_conditions(NX_INT): unit: NX_UNITLESS doc: | @@ -87,4 +102,164 @@ NXcg_grid(NXcg_primitive_set): 3 - mirror 4 - von Neumann 5 - Dirichlet - dim: (n_b,) + dimensions: + rank: 1 + dim: [[1, n_b]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# ed527bf012261fe9a8099480c6b2c19da1d8e031c8abda828ba39a82326b1e8e +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality of the grid. +# +# +# +# +# The cardinality or total number of cells aka grid points. +# +# +# +# +# Number of boundaries of the bounding box or primitive housing the grid. +# +# +# +# +# Computational geometry description of a grid of Wigner-Seitz cells in Euclidean space. +# +# Three-dimensional grids with cubic cells are if not the most frequently used +# example of such grids. Examples of numerical methods where grids are used +# are spectral-solver based crystal plasticity or other stencil methods like +# phase-field or cellular automata. +# +# +# +# Location of the origin of the grid. +# +# Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` +# class to specify the coordinate system in which the origin location is defined. +# +# +# +# +# +# +# +# The symmetry of the lattice defining the shape of the unit cell. +# +# +# +# +# +# +# +# The unit cell dimensions using crystallographic notation. +# +# +# +# +# +# +# +# Number of unit cells along each of the d unit vectors. +# +# The total number of cells or grid points has to be the cardinality. +# If the grid has an irregular number of grid positions in each direction, +# as it could be for instance the case of a grid where all grid points +# outside some masking primitive are removed, this extent field should +# not be used. Instead, use the coordinate field. +# +# +# +# +# +# +# +# +# Position of each cell in Euclidean space. +# +# +# +# +# +# +# +# +# Coordinate of each cell with respect to the discrete grid. +# +# +# +# +# +# +# +# +# +# A tight bounding box about the grid. +# +# +# +# +# +# Number of boundaries distinguished +# +# Most grids discretize a cubic or cuboidal region. In this case +# six sides can be distinguished, each making an own boundary. +# +# +# +# +# Name of domain boundaries of the simulation box/ROI +# e.g. left, right, front, back, bottom, top. +# +# +# +# +# +# +# +# The boundary conditions for each boundary: +# +# 0 - undefined +# 1 - open +# 2 - periodic +# 3 - mirror +# 4 - von Neumann +# 5 - Dirichlet +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml b/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml index 6e22cb5624..4db22e6509 100644 --- a/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml +++ b/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml @@ -4,6 +4,7 @@ doc: | Such a data structure can be used to efficiently circulate around faces and iterate over vertices of a planar graph. + # holes in the polygon mesh can be handled symbols: doc: | @@ -18,43 +19,48 @@ symbols: The number of half-edges. type: group NXcg_half_edge_data_structure(NXcg_primitive_set): + # resulting in a design similar to that of NXoff_geometry and the XDMF mixed primitive topology number_of_vertices(NX_INT): + unit: NX_UNITLESS doc: | Number of vertices for each face. Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - unit: NX_UNITLESS - dim: (n_f,) + dimensions: + rank: 1 + dim: [[1, n_f]] number_of_edges(NX_INT): + unit: NX_UNITLESS doc: | Number of edges for each face. Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - unit: NX_UNITLESS - dim: (n_e,) + dimensions: + rank: 1 + dim: [[1, n_e]] number_of_faces(NX_INT): + unit: NX_UNITLESS doc: | Number of faces of the primitives. - unit: NX_UNITLESS vertex_identifier_offset(NX_INT): + unit: NX_UNITLESS doc: | Integer offset whereby the identifier of the first member of the vertices differs from zero. Identifier can be defined explicitly or implicitly. Inspect the definition of :ref:`NXcg_primitive_set` for further details. - unit: NX_UNITLESS edge_identifier_offset(NX_INT): + unit: NX_UNITLESS doc: | Integer offset whereby the identifier of the first member of the edges differs from zero. Identifier can be defined explicitly or implicitly. Inspect the definition of :ref:`NXcg_primitive_set` for further details. - unit: NX_UNITLESS face_identifier_offset(NX_INT): doc: | Integer offset whereby the identifier of the first member @@ -62,48 +68,65 @@ NXcg_half_edge_data_structure(NXcg_primitive_set): Identifier can be defined explicitly or implicitly. Inspect the definition of :ref:`NXcg_primitive_set` for further details. + # therefore, vertex_-, face_-, half_edge_-identifier are implicit position(NX_NUMBER): + unit: NX_ANY doc: | The position of the vertices. - unit: NX_ANY - dim: (n_v, d) + dimensions: + rank: 2 + dim: [[1, n_v], [2, d]] vertex_incident_half_edge(NX_INT): + unit: NX_UNITLESS doc: | Identifier of the incident half-edge. - unit: NX_UNITLESS - dim: (n_v,) + dimensions: + rank: 1 + dim: [[1, n_v]] face_half_edge(NX_INT): + unit: NX_UNITLESS doc: | Identifier of the (starting)/associated half-edge of the face. - unit: NX_UNITLESS - dim: (n_f,) + dimensions: + rank: 1 + dim: [[1, n_f]] half_edge_vertex_origin(NX_INT): + unit: NX_UNITLESS doc: | The identifier of the vertex from which this half-edge is outwards pointing. - unit: NX_UNITLESS - dim: (n_he,) + dimensions: + rank: 1 + dim: [[1, n_he]] half_edge_twin(NX_INT): + unit: NX_UNITLESS doc: | Identifier of the associated oppositely pointing half-edge. - unit: NX_UNITLESS - dim: (n_he,) + dimensions: + rank: 1 + dim: [[1, n_he]] half_edge_incident_face(NX_INT): + unit: NX_UNITLESS doc: | If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - unit: NX_UNITLESS - dim: (n_he,) + dimensions: + rank: 1 + dim: [[1, n_he]] half_edge_next(NX_INT): + unit: NX_UNITLESS doc: | Identifier of the next half-edge. - unit: NX_UNITLESS - dim: (n_he,) + dimensions: + rank: 1 + dim: [[1, n_he]] half_edge_prev(NX_INT): + unit: NX_UNITLESS doc: | Identifier of the previous half-edge. - unit: NX_UNITLESS - dim: (n_he,) + dimensions: + rank: 1 + dim: [[1, n_he]] weinberg_vector(NX_CHAR): doc: | Users are referred to the literature for the background of L. Weinberg's @@ -120,3 +143,202 @@ NXcg_half_edge_data_structure(NXcg_primitive_set): # which could be more efficient # see https://jerryyin.info/geometry-processing-algorithms/half-edge/ # for an illustrative example of half-edge data structures + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 52d8184a299749c24e19f2b06b4dce80d15eb1645d69665ba05c9707283885a3 +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality, which has to be at least 2. +# +# +# +# +# The number of vertices. +# +# +# +# +# The number of faces. +# +# +# +# +# The number of half-edges. +# +# +# +# +# Computational geeometry description of a half-edge data structure. +# +# Such a data structure can be used to efficiently circulate around faces +# and iterate over vertices of a planar graph. +# +# +# +# +# Number of vertices for each face. +# +# Each entry represents the total number of vertices for that face, +# irrespectively whether vertices are shared among faces or not. +# +# +# +# +# +# +# +# Number of edges for each face. +# +# Each entry represents the total number of edges for that face, +# irrespectively whether edges are shared across faces or not. +# +# +# +# +# +# +# +# Number of faces of the primitives. +# +# +# +# +# Integer offset whereby the identifier of the first member +# of the vertices differs from zero. +# +# Identifier can be defined explicitly or implicitly. +# Inspect the definition of :ref:`NXcg_primitive_set` for further details. +# +# +# +# +# Integer offset whereby the identifier of the first member +# of the edges differs from zero. +# +# Identifier can be defined explicitly or implicitly. +# Inspect the definition of :ref:`NXcg_primitive_set` for further details. +# +# +# +# +# Integer offset whereby the identifier of the first member +# of the faces differs from zero. +# +# Identifier can be defined explicitly or implicitly. +# Inspect the definition of :ref:`NXcg_primitive_set` for further details. +# +# +# +# +# +# The position of the vertices. +# +# +# +# +# +# +# +# +# Identifier of the incident half-edge. +# +# +# +# +# +# +# +# Identifier of the (starting)/associated half-edge of the face. +# +# +# +# +# +# +# +# The identifier of the vertex from which this half-edge is outwards pointing. +# +# +# +# +# +# +# +# Identifier of the associated oppositely pointing half-edge. +# +# +# +# +# +# +# +# If the half-edge is a boundary half-edge the +# incident face identifier is NULL, i.e. 0. +# +# +# +# +# +# +# +# Identifier of the next half-edge. +# +# +# +# +# +# +# +# Identifier of the previous half-edge. +# +# +# +# +# +# +# +# Users are referred to the literature for the background of L. Weinberg's +# work about topological characterization of planar graphs: +# +# * `L. Weinberg 1966a, <https://dx.doi.org/10.1109/TCT.1964.1082216>`_ +# * `L. Weinberg, 1966b, <https://dx.doi.org/10.1137/0114062>`_ +# * `E. A. Lazar et al. <https://doi.org/10.1103/PhysRevLett.109.095505>`_ +# +# and how this work can e.g. be applied in space-filling tessellations +# of microstructural objects like crystals/grains. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_hexahedron_set.yaml b/contributed_definitions/nyaml/NXcg_hexahedron_set.yaml index 574895a93b..af65ad1019 100644 --- a/contributed_definitions/nyaml/NXcg_hexahedron_set.yaml +++ b/contributed_definitions/nyaml/NXcg_hexahedron_set.yaml @@ -49,6 +49,7 @@ symbols: The symbols used in the schema to specify e.g. dimensions of arrays. c: | The cardinality of the set, i.e. the number of hexahedra. + # it is useful to define own base classes for frequently used classes # a polyhedron is a specific polytope in 3d, do we need # higher-dimensional polytopes? that could be useful for simplicies though @@ -56,19 +57,24 @@ symbols: # from MarDI, for now let's assume we do not need polytopes for d > 3 type: group NXcg_hexahedron_set(NXcg_primitive_set): + # qualifiers and properties of hexahedra shape(NX_NUMBER): unit: NX_LENGTH doc: | Qualifier for the shape of each hexahedron. - dim: (c, 3) + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] length(NX_NUMBER): unit: NX_LENGTH doc: | Qualifier that is useful in cases when one edge is longer than all other edges of the hexahedra. Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] width(NX_NUMBER): unit: NX_LENGTH doc: | @@ -77,39 +83,54 @@ NXcg_hexahedron_set(NXcg_primitive_set): For the sake of explicitness quantities like length, width, and height should not be reported without specifying also the assumed reference frame. - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] height(NX_NUMBER): + unit: NX_LENGTH doc: | Qualifier often used to describe the extent of an object in the vertical direction assuming a specific coordinate system. - unit: NX_LENGTH - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] volume(NX_NUMBER): + unit: NX_VOLUME doc: | Volume of each hexahedron. - unit: NX_VOLUME - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] area(NX_NUMBER): + unit: NX_AREA doc: | Total (surface) area (of all six faces) of each hexahedron. - unit: NX_AREA - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] face_area(NX_NUMBER): + unit: NX_AREA doc: | Area of each of the six faces of each hexahedron. - unit: NX_AREA - dim: (c, 6) + dimensions: + rank: 2 + dim: [[1, c], [2, 6]] is_box(NX_BOOLEAN): doc: | Specifies if the hexahedra represent cuboids or cubes eventually rotated ones but at least not too exotic six-faced polyhedra. - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] is_axis_aligned(NX_BOOLEAN): doc: | Only to be used if is_box is present. In this case, this field describes whether hexahedra are boxes whose primary edges are parallel to the axes of the coordinate system. - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] + # substantially more detailed descriptors of the shape, the mesh # orientation(NXorientation_set): vertex_normal(NXcg_unit_normal_set): @@ -126,3 +147,199 @@ NXcg_hexahedron_set(NXcg_primitive_set): hexahedron_half_edgeID(NXcg_half_edge_data_structure): doc: | Individual storage of each hexahedron as a graph. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 2ca4ead97d661d0a560f3004737c458ae323b2fd11b537a542ac5f95dcfbe0b9 +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The cardinality of the set, i.e. the number of hexahedra. +# +# +# +# +# Computational geometry description of a set of hexahedra in Euclidean space. +# +# This class can also be used to describe cuboids or cubes, axis-aligned or not. +# The class represents different access and description levels to offer both +# applied scientists and computational geometry experts an approach whereby +# different specific views can be implemented using the same base class: +# +# * In the simplest case experimentalists may use this base class to describe +# the dimensions or size of a specimen. In this case the alignment with axes +# is not relevant as eventually only the volume of the specimen is of interest. +# * In many cases, take for example an experiment where a specimen was cut out +# from a specifically deformed piece of material, the orientation of the +# specimen's edges with the experiment coordinate system is of high relevance. +# Examples include knowledge about the specimen edge, whether it is +# parallel to the rolling, the transverse, or the normal direction. +# * While the above-mentioned use cases are sufficient to pinpoint the sample +# within a known laboratory/experiment coordinate system, these descriptions +# are not detailed enough to specify e.g. a CAD model of the specimen. +# * Therefore, groups and fields for an additional, computational-geometry- +# based view of hexahedra is offered to serve additional computational +# tasks: storage-oriented simple views or detailed topological/graph-based +# descriptions. +# +# Hexahedra are important geometrical primitives, which are among the most +# frequently used elements in finite element meshing/modeling. +# +# As a specialization of the :ref:`NXcg_primitive_set` base class hexahedra +# are assumed non-degenerated, closed, and built of polygons that are +# not self-intersecting. +# +# The term hexahedra will be used throughout this base class but includes +# the special cases cuboid, cube, box, axis-aligned bounding box (AABB), +# and optimal bounding box (OBB). +# +# An axis-aligned bounding box is a common data object in computational science +# and simulation codes to represent a cuboid whose edges are aligned with the +# base vectors of a coordinate system. As a part of binary trees, these data +# objects are important for making time- as well as space-efficient queries +# of geometric primitives in techniques like kd-trees. +# +# An optimal bounding box is a common data object which provides the best +# tightly fitting box about an arbitrary object. In general, such boxes are +# rotated. Exact and substantially faster in practice approximate algorithms +# exist to compute optimal or near optimal bounding boxes for sets of points. +# +# +# +# +# Qualifier for the shape of each hexahedron. +# +# +# +# +# +# +# +# +# Qualifier that is useful in cases when one edge is longer than all other +# edges of the hexahedra. Often the term length is associated with the +# assumption that one edge is parallel to an axis of the coordinate system. +# +# +# +# +# +# +# +# Qualifier often used to describe the extent of an object in the horizontal +# direction assuming a specific coordinate system. +# +# For the sake of explicitness quantities like length, width, and height +# should not be reported without specifying also the assumed reference frame. +# +# +# +# +# +# +# +# Qualifier often used to describe the extent of an object in the vertical +# direction assuming a specific coordinate system. +# +# +# +# +# +# +# +# Volume of each hexahedron. +# +# +# +# +# +# +# +# Total (surface) area (of all six faces) of each hexahedron. +# +# +# +# +# +# +# +# Area of each of the six faces of each hexahedron. +# +# +# +# +# +# +# +# +# Specifies if the hexahedra represent cuboids or cubes eventually rotated +# ones but at least not too exotic six-faced polyhedra. +# +# +# +# +# +# +# +# Only to be used if is_box is present. In this case, this field describes +# whether hexahedra are boxes whose primary edges are parallel to the +# axes of the coordinate system. +# +# +# +# +# +# +# +# +# +# +# +# +# Combined storage of all primitives of all hexahedra. +# +# +# +# +# Individual storage of each hexahedron. +# +# +# +# +# Individual storage of each hexahedron as a graph. +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_marching_cubes.yaml b/contributed_definitions/nyaml/NXcg_marching_cubes.yaml index 8b9385ff28..41882e07f4 100644 --- a/contributed_definitions/nyaml/NXcg_marching_cubes.yaml +++ b/contributed_definitions/nyaml/NXcg_marching_cubes.yaml @@ -4,6 +4,7 @@ doc: | Documenting which specific version of MC was used helps with understanding how robust the results are with respect to the topology of the triangulation. + # symbols: type: group NXcg_marching_cubes(NXobject): @@ -14,16 +15,77 @@ NXcg_marching_cubes(NXobject): doc: | Reference to the specific implementation of marching cubes used. - See for example the following papers for details about specific + See for example the following papers for details about specific MC implementations: * `W. E. Lorensen `_ * `T. S. Newman and H. Yi `_ - description(NX_CHAR): doc: | Free text field in case a proper identifier is not available. (NXprogram): + # we could also think about storing the rule sets in here explicitly including the # coordinate system conventions; however, the problem is that many commercial # tools like Matlab do not expose the rule set. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 99f62d71440f06f8c62dc35a2827f4ec3b4b3b434c99c5bf8743aad1e44357cc +# +# +# +# +# +# +# Base class to detail the marching cubes (MC) algorithm. +# +# Documenting which specific version of MC was used helps with understanding +# how robust the results are with respect to the topology of the triangulation. +# +# +# +# Metadata of the grid on which the here specified MC is operating. +# +# +# +# +# Reference to the specific implementation of marching cubes used. +# +# See for example the following papers for details about specific +# MC implementations: +# +# * `W. E. Lorensen <https://doi.org/10.1109/MCG.2020.2971284>`_ +# * `T. S. Newman and H. Yi <https://doi.org/10.1016/j.cag.2006.07.021>`_ +# +# +# +# +# Free text field in case a proper identifier is not available. +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_parallelogram_set.yaml b/contributed_definitions/nyaml/NXcg_parallelogram_set.yaml index 05dc7778f1..431d48a6bf 100644 --- a/contributed_definitions/nyaml/NXcg_parallelogram_set.yaml +++ b/contributed_definitions/nyaml/NXcg_parallelogram_set.yaml @@ -41,25 +41,141 @@ symbols: The cardinality of the set, i.e. the number of parallelograms. type: group NXcg_parallelogram_set(NXcg_primitive_set): + # qualifiers and properties of parallelograms is_rectangle(NX_BOOLEAN): doc: | To specify which parallelogram is a rectangle. - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] is_axis_aligned(NX_BOOLEAN): doc: | Only to be used if is_rectangle is present. In this case, this field describes whether parallelograms are rectangles whose primary edges are parallel to the axes of the coordinate system. - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] + # detailed mesh-based representation parallelograms(NXcg_face_list_data_structure): + # exists: [min, 0, max, 1] doc: | Combined storage of all primitives of all parallelograms. parallelogramID(NXcg_face_list_data_structure): doc: | Individual storage of each parallelogram. - ##MK::parallelogram_half_edgeID(NXcg_half_edge_data_structure) + + #MK::parallelogram_half_edgeID(NXcg_half_edge_data_structure) # a half-edge structure would be overkill as this is a simple primitive +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 65f639f5204351cb87c156f5c0a041300104a66e9aa6557ad772e82221700223 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The cardinality of the set, i.e. the number of parallelograms. +# +# +# +# +# Computational geometry description of a set of parallelograms. +# +# This class can also be used to describe rectangles or squares, irrespective +# whether these are axis-aligned or not. The class represents different +# access and description levels to embrace applied scientists and computational +# geometry experts with their different views: +# +# * The simplest case is the communication of dimensions aka the size of a +# region of interest in the 2D plane. In this case, communicating the +# alignment with axes is maybe not as relevant as it is to report the area +# of the ROI. +# * In other cases the extent of the parallelogram is relevant though. +# * Finally, in CAD models it should be possible to specify the polygons +# which the parallelograms represent with exact numerical details. +# +# Parallelograms are important geometrical primitives as their usage for +# describing many scanning experiments shows where typically parallelogram-shaped +# ROIs are scanned across the surface of a sample. +# +# The term parallelogram will be used throughout this base class thus including +# the important special cases rectangle, square, 2D box, axis-aligned bounding box +# (AABB), or optimal bounding box (OBB) as analogous 2D variants to their 3D +# counterparts. See :ref:`NXcg_hexahedron_set` for the generalization in 3D. +# +# An axis-aligned bounding box is a common data object in computational science +# and simulation codes to represent a rectangle whose edges are aligned with the +# axes of a coordinate system. As a part of binary trees AABBs are important data +# objects for executing time- as well as space-efficient queries +# of geometric primitives in techniques like kd-trees. +# +# An optimal bounding box is a common data object which provides the best, i.e. +# most tightly fitting box about an arbitrary object. In general such boxes are +# rotated. Other than in 3D dimensions, the rotation calipher method offers +# a rigorous approach to compute an optimal bounding box to a point set in 2D. +# +# +# +# +# To specify which parallelogram is a rectangle. +# +# +# +# +# +# +# +# Only to be used if is_rectangle is present. In this case, this field +# describes whether parallelograms are rectangles whose primary edges +# are parallel to the axes of the coordinate system. +# +# +# +# +# +# +# +# +# +# Combined storage of all primitives of all parallelograms. +# +# +# +# +# Individual storage of each parallelogram. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_point_set.yaml b/contributed_definitions/nyaml/NXcg_point_set.yaml index 673953b0c6..6002825cfb 100644 --- a/contributed_definitions/nyaml/NXcg_point_set.yaml +++ b/contributed_definitions/nyaml/NXcg_point_set.yaml @@ -21,23 +21,119 @@ symbols: type: group NXcg_point_set(NXcg_primitive_set): position(NX_NUMBER): + unit: NX_ANY doc: | Coordinates of the points. - unit: NX_ANY - dim: (c, d) + dimensions: + rank: 2 + dim: [[1, c], [2, d]] time(NX_NUMBER): + unit: NX_TIME doc: | (Elapsed) time for each point. If the field time is needed contextualize the time_offset relative to which time values are defined. Alternative store timestamp. - unit: NX_TIME - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] timestamp(NX_DATE_TIME): doc: | ISO8601 with local time zone offset for each point. - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] time_offset(NX_DATE_TIME): doc: | ISO8601 with local time zone offset that serves as the reference for values in the field time. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# be22e63c2fd9ed8da282eadabf22fba5ec6165bf6daa856c90cbc48abb741117 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality. +# +# +# +# +# The cardinality of the set, i.e. the number of points. +# +# +# +# +# Computational geometry description of a set of points. +# +# Points may have an associated time value. Users are advised though to store +# time data of point sets rather as instances of time events, where for each +# point in time there is an :ref:`NXcg_point_set` instance which specifies the +# points' locations. +# +# This is a frequent situation in experiments and computer simulations, where +# positions of points are taken at the same point in time (real time or +# simulated physical time). Thereby, the storage of redundant time stamp +# information per point is considered as obsolete. +# +# +# +# Coordinates of the points. +# +# +# +# +# +# +# +# +# (Elapsed) time for each point. +# +# If the field time is needed contextualize the time_offset relative to which +# time values are defined. Alternative store timestamp. +# +# +# +# +# +# +# +# ISO8601 with local time zone offset for each point. +# +# +# +# +# +# +# +# ISO8601 with local time zone offset that serves as the reference +# for values in the field time. +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_polygon_set.yaml b/contributed_definitions/nyaml/NXcg_polygon_set.yaml index 6f712610ff..8a76034eac 100644 --- a/contributed_definitions/nyaml/NXcg_polygon_set.yaml +++ b/contributed_definitions/nyaml/NXcg_polygon_set.yaml @@ -1,4 +1,5 @@ category: base + # somewhat redundant as there is NXoff_geometry but easier to understand doc: | Computational geometry description of a set of polygons in Euclidean space. @@ -24,6 +25,7 @@ doc: | subclass of such complexes, users should rather design an own base class e.g. NXcg_polytope_set to describe such even more complex primitives instead of abusing this base class for such purposes. + # Users can take advantage of NXcg_polygon_set to describe such complexes # when using the defines_plc and related topological and boundary constraint # descriptors. @@ -34,15 +36,17 @@ symbols: The dimensionality, which has to be either 2 or 3. c: | The cardinality of the set, i.e. the number of polygons. + # n_unique: Number of unique points supporting the polygons. n_total: | The total number of vertices when visiting every polygon. type: group NXcg_polygon_set(NXcg_primitive_set): number_of_total_vertices(NX_INT): + unit: NX_UNITLESS doc: | The total number of vertices in the set. - unit: NX_UNITLESS + # detailed mesh-based representation polygons(NXcg_face_list_data_structure): doc: | @@ -53,27 +57,168 @@ NXcg_polygon_set(NXcg_primitive_set): polygon_half_edgeID(NXcg_half_edge_data_structure): doc: | Individual storage of each polygon as a graph. + # properties of the polygon primitives edge_length(NX_NUMBER): + unit: NX_LENGTH doc: | For each polygon its accumulated length along its edges. - unit: NX_LENGTH - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] interior_angle(NX_NUMBER): + unit: NX_ANGLE doc: | Interior angles for each polygon. There are as many values per polygon as the are number_of_vertices. The angle is the angle at the specific vertex, i.e. between the adjoining edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - unit: NX_ANGLE - dim: (n_total,) + dimensions: + rank: 1 + dim: [[1, n_total]] shape(NX_INT): + unit: NX_UNITLESS doc: | Curvature type: * 0 - unspecified, * 1 - convex, * 2 - concave - unit: NX_UNITLESS - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# fef7bf429d95f85623fcce20ff374aff3bfbe48ddab0ecd325a49b49a95d16c6 +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality, which has to be either 2 or 3. +# +# +# +# +# The cardinality of the set, i.e. the number of polygons. +# +# +# +# +# +# The total number of vertices when visiting every polygon. +# +# +# +# +# +# Computational geometry description of a set of polygons in Euclidean space. +# +# Polygons are specialized polylines: +# +# * A polygon is a geometric primitive that is bounded by a closed polyline +# * All vertices of this polyline lay in the d-1 dimensional plane. +# whereas vertices of a polyline do not necessarily lay on a plane. +# * A polygon has at least three vertices. +# +# Each polygon is built from a sequence of vertices (points with identifiers). +# The members of a set of polygons may have a different number of vertices. +# Sometimes a collection/set of polygons is referred to as a soup of polygons. +# +# As three-dimensional objects, a set of polygons can be used to define the +# hull of what is effectively a polyhedron; however users are advised to use +# the specific :ref:`NXcg_polyhedron_set` base class if they wish to describe closed +# polyhedra. Even more general complexes can be thought of. An example are the +# so-called piecewise-linear complexes used in the TetGen library. +# +# As these complexes can have holes though, polyhedra without holes are one +# subclass of such complexes, users should rather design an own +# base class e.g. NXcg_polytope_set to describe such even more +# complex primitives instead of abusing this base class for such purposes. +# +# +# +# The total number of vertices in the set. +# +# +# +# +# +# Combined storage of all primitives of all polygons. +# +# +# +# +# Individual storage of the mesh of each polygon. +# +# +# +# +# Individual storage of each polygon as a graph. +# +# +# +# +# +# For each polygon its accumulated length along its edges. +# +# +# +# +# +# +# +# Interior angles for each polygon. There are as many values per polygon +# as the are number_of_vertices. +# The angle is the angle at the specific vertex, i.e. between the adjoining +# edges of the vertex according to the sequence in the polygons array. +# Usually, the winding_order field is required to interpret the value. +# +# +# +# +# +# +# +# Curvature type: +# +# * 0 - unspecified, +# * 1 - convex, +# * 2 - concave +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_polyhedron_set.yaml b/contributed_definitions/nyaml/NXcg_polyhedron_set.yaml index 9285618b3b..e1edf63381 100644 --- a/contributed_definitions/nyaml/NXcg_polyhedron_set.yaml +++ b/contributed_definitions/nyaml/NXcg_polyhedron_set.yaml @@ -18,6 +18,7 @@ symbols: The total number of edges for all polyhedra. n_f_total: | The total number of faces for all polyhedra. + # it is useful to define own base classes for frequently used classes # a polyhedron is a specific polytope in 3d, do we need # higher-dimensional polytopes? that could be useful for simplicies though @@ -29,27 +30,35 @@ symbols: # for clean graph-based descriptions of polyhedra. type: group NXcg_polyhedron_set(NXcg_primitive_set): + # qualifiers and properties of polyhedra number_of_faces(NX_INT): + unit: NX_UNITLESS doc: | The number of faces for each polyhedron. Faces of adjoining polyhedra are counted for each polyhedron. - unit: NX_UNITLESS - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] face_area(NX_NUMBER): + unit: NX_AREA doc: | Area of each of faces. - unit: NX_AREA - dim: (n_f_total,) + dimensions: + rank: 1 + dim: [[1, n_f_total]] number_of_edges(NX_INT): doc: | The number of edges for each polyhedron. Edges of adjoining polyhedra are counterd for each polyhedron. edge_length(NX_NUMBER): + unit: NX_LENGTH doc: | Length of each edge. - unit: NX_LENGTH - dim: (n_e_total,) + dimensions: + rank: 1 + dim: [[1, n_e_total]] + # detailed mesh-based representation polyhedra(NXcg_face_list_data_structure): doc: | @@ -60,3 +69,120 @@ NXcg_polyhedron_set(NXcg_primitive_set): polyhedron_half_edgeID(NXcg_half_edge_data_structure): doc: | Individual storage of each polygon as a graph. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 7c6eaa559e1c375f053c0ff374251a2d70e14e7433def8e4425d55c747c69aba +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The cardinality of the set, i.e. the number of polyhedra. +# +# +# +# +# The total number of edges for all polyhedra. +# +# +# +# +# The total number of faces for all polyhedra. +# +# +# +# +# Computational geometry description of a set of polyhedra in Euclidean space. +# +# Polyhedra or so-called cells (especially in the convex of tessellations) are +# constructed from polygon meshes. Polyhedra may make contact to allow a usage +# of this base class for a description of tessellations. +# +# For the description of more complicated manifolds and especially for polyhedra +# with holes, users are advised to check if their particular needs are described +# by creating customized instances of an :ref:`NXcg_polygon_set`. +# +# +# +# +# The number of faces for each polyhedron. Faces of adjoining polyhedra +# are counted for each polyhedron. +# +# +# +# +# +# +# +# Area of each of faces. +# +# +# +# +# +# +# +# The number of edges for each polyhedron. Edges of adjoining polyhedra +# are counterd for each polyhedron. +# +# +# +# +# Length of each edge. +# +# +# +# +# +# +# +# +# Combined storage of all primitives of all polyhedra. +# +# +# +# +# Individual storage of each polyhedron. +# +# +# +# +# Individual storage of each polygon as a graph. +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_polyline_set.yaml b/contributed_definitions/nyaml/NXcg_polyline_set.yaml index 3312c4393a..856234915e 100644 --- a/contributed_definitions/nyaml/NXcg_polyline_set.yaml +++ b/contributed_definitions/nyaml/NXcg_polyline_set.yaml @@ -13,6 +13,7 @@ symbols: The dimensionality, which has to be at least 1. c: | The cardinality of the set, i.e. the number of polylines. + # n_unique: The number of unique vertices supporting the polyline. # multiple vertices possible with the same point coordinates but different names. n_v: | @@ -22,26 +23,30 @@ symbols: type: group NXcg_polyline_set(NXcg_primitive_set): number_of_unique_vertices(NX_POSINT): + unit: NX_UNITLESS doc: | The total number of vertices that have different positions. - unit: NX_UNITLESS number_of_total_vertices(NX_INT): + unit: NX_UNITLESS doc: | The total number of vertices, irrespective of their eventual uniqueness. - unit: NX_UNITLESS number_of_vertices(NX_INT): + unit: NX_UNITLESS doc: | The total number of vertices of each polyline, irrespectively whether vertices are shared by vertices or not. See the docstring for polylines for further details about how a set with different polyline members should be stored. - unit: NX_UNITLESS - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] + # Users are encouraged to reduce the vertex set to the unique vertices. # Unique means not necessarily unique in position only but also unique in # identifier. In fact, it is possible to distinguish two vertices as two when # they share the same position in space but have different identifiers. vertices(NX_NUMBER): + unit: NX_ANY doc: | Positions of the vertices which support the members of the polyline set. @@ -52,18 +57,20 @@ NXcg_polyline_set(NXcg_primitive_set): Naively, here means that one stores each vertex of a triangle mesh even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - unit: NX_ANY - dim: (n_v, d) + dimensions: + rank: 2 + dim: [[1, n_v], [2, d]] + # alternatively we may store the actual vertices in an instance of # NXcg_point_set and (e.g. to promote compact storage of information and primitives) # and then use - vertices_are_unique(NX_BOOLEAN): doc: | If true indicates that the vertices are all placed at different positions and have different identifiers, i.e. no points overlap or are counted several times. polylines(NX_INT): + unit: NX_UNITLESS doc: | Sequence of identifier for vertices how they build each polyline. @@ -84,5 +91,147 @@ NXcg_polyline_set(NXcg_primitive_set): Using the (cumulated) counts in number_of_vertices, the vertices of the n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - unit: NX_UNITLESS - dim: (n_total,) + dimensions: + rank: 1 + dim: [[1, n_total]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# eefaf5efe859a45e462b7b7bc0d1f33ac0f9401a8b8ce4b416030d05b69cdfe4 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality, which has to be at least 1. +# +# +# +# +# The cardinality of the set, i.e. the number of polylines. +# +# +# +# +# +# The number of vertices, supporting the polylines. +# +# +# +# +# The total number of vertices traversed when visiting every polyline. +# +# +# +# +# Computational geometry description of a set of polylines. +# +# Each polyline is built from a sequence of vertices (points with identifiers). +# Each polyline must have a start and an end point. +# The sequence describes the positive traversal along the polyline when +# walking from the first to the last vertex. +# +# +# +# The total number of vertices that have different positions. +# +# +# +# +# The total number of vertices, irrespective of their eventual uniqueness. +# +# +# +# +# The total number of vertices of each polyline, irrespectively +# whether vertices are shared by vertices or not. +# See the docstring for polylines for further details about how +# a set with different polyline members should be stored. +# +# +# +# +# +# +# +# +# Positions of the vertices which support the members of the polyline set. +# +# Users are encouraged to reduce the vertices to unique positions and vertices +# as this often supports with storing geometry data more efficiently. +# It is also possible though to store the vertex positions naively +# in which case vertices_are_unique is likely False. +# Naively, here means that one stores each vertex of a triangle mesh +# even though many vertices are shared between triangles and thus +# storing multiple copies of their positions is redundant. +# +# +# +# +# +# +# +# +# +# If true indicates that the vertices are all placed at different +# positions and have different identifiers, i.e. no points overlap +# or are counted several times. +# +# +# +# +# Sequence of identifier for vertices how they build each polyline. +# +# A trivial example is a set with two polylines with three vertices each. +# If the polylines meet in a junction, say the second vertex is shared +# and marking the junction between the two polylines, it is possible that +# there are only five unique positions. This suggests to store five +# unique vertices. +# +# A non-trivial example is a set with several polylines. Assume that each +# has a different number of vertices. The array stores the identifier of +# the vertices in the sequence how the polylines are visited: +# +# The first entry is the identifier of the first vertex of the first polyline, +# followed by the second vertex of the first polyline, until the last vertex +# of the first polyline. +# Thereafter, the first vertex of the second polyline, and so on and so forth. +# Using the (cumulated) counts in number_of_vertices, the vertices of the +# n-th polyline can be accessed on the following array index interval: +# :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml index 7a8466b067..7188df51e5 100644 --- a/contributed_definitions/nyaml/NXcg_primitive_set.yaml +++ b/contributed_definitions/nyaml/NXcg_primitive_set.yaml @@ -4,6 +4,7 @@ doc: | Primitives must neither be degenerated nor self-intersect. Individual primitives can differ in their properties (e.g. size, shape, rotation). + # this base class defines common fields and properties of geometric primitives # more complex primitive sets like NXcg_cylinder_set are considered specializations # of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set @@ -33,22 +34,25 @@ symbols: The cardinality of the set, i.e. the number of members. type: group NXcg_primitive_set(NXobject): + # individual specializations like NXcg_polyline_set typically overwrite # the meaning of the depends_on concept to build consistent inference chains # to enable an instantiation of the actual geometric primitives depends_on(NX_CHAR): doc: | - Reference to an instance of :ref:`NXcoordinate_system` in which these primitives are defined. + Reference to an instance of :ref:`NXcoordinate_system` in which these primitives + are defined. dimensionality(NX_POSINT): + unit: NX_UNITLESS doc: | The dimensionality of the primitive set. - unit: NX_UNITLESS enumeration: [1, 2, 3] cardinality(NX_POSINT): + unit: NX_UNITLESS doc: | The cardinality of the primitive set. - unit: NX_UNITLESS identifier_offset(NX_INT): + unit: NX_UNITLESS doc: | Integer offset whereby the identifier of the first member of the set differs from zero. @@ -64,72 +68,308 @@ NXcg_primitive_set(NXobject): For explicit indexing the field identifier has to be used. Fortran-/Matlab- and C-/Python-style indexing have specific implicit identifier conventions where identifier_offset is 1 and 0 respectively. - unit: NX_UNITLESS identifier(NX_INT): doc: | Identifier of each member for explicit indexing. - dim: (c,) # numpy style indexing + dimensions: + rank: 1 + dim: [[1, c]] center(NX_NUMBER): + unit: NX_ANY doc: | The center of mass position of each primitive. - unit: NX_ANY - dim: (c, d) - # a depends_on to define in which coordinate system + dimensions: + rank: 2 + dim: [[1, c], [2, d]] + + # a depends_on to define in which coordinate system is_center_of_mass(NX_BOOLEAN): doc: | True if the center is a center of mass. - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] shape(NX_NUMBER): + unit: NX_LENGTH doc: | A qualitative description of the shape of each primitive. - unit: NX_LENGTH - dim: (c, d) + dimensions: + rank: 2 + dim: [[1, c], [2, d]] length(NX_NUMBER): + unit: NX_LENGTH doc: | Qualifier for the length of characteristic features of the primitive. Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - unit: NX_LENGTH - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] width(NX_NUMBER): + unit: NX_LENGTH doc: | Qualifier often used to describe the length of one characteristic edge within the coordinate system. - unit: NX_LENGTH - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] is_closed(NX_BOOLEAN): doc: | True if primitive is closed such that it has properties like area or volume. - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] volume(NX_NUMBER): + unit: NX_VOLUME doc: | Volume of each primitive. Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_VOLUME - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] area(NX_NUMBER): + unit: NX_AREA doc: | Alias for surface_area of each primitive. Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_AREA - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] orientation(NX_NUMBER): + unit: NX_DIMENSIONLESS doc: | Direction unit vector which points along the longest principal axis of each primitive. Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - unit: NX_DIMENSIONLESS - dim: (c, d) + dimensions: + rank: 2 + dim: [[1, c], [2, d]] vertex_normal(NXcg_unit_normal_set): edge_normal(NXcg_unit_normal_set): face_normal(NXcg_unit_normal_set): + # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) # but then one would not give any hint at the base class level how to name + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 55f7920f38d9fc75b0487808a83dbd2f35fb901ea2d16ce26c4848e8b5dcf150 +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality of the space. +# +# +# +# +# The cardinality of the set, i.e. the number of members. +# +# +# +# +# Computational geometry description of a set of primitives in Euclidean space. +# +# Primitives must neither be degenerated nor self-intersect. +# Individual primitives can differ in their properties (e.g. size, shape, rotation). +# +# +# +# +# Reference to an instance of :ref:`NXcoordinate_system` in which these primitives +# are defined. +# +# +# +# +# The dimensionality of the primitive set. +# +# +# +# +# +# +# +# +# +# The cardinality of the primitive set. +# +# +# +# +# Integer offset whereby the identifier of the first member +# of the set differs from zero. +# +# Identifiers can be defined either implicitly or explicitly. +# For implicit indexing identifiers are defined on the interval +# :math:`[identifier\_offset, identifier\_offset + c - 1]`. +# +# Therefore, implicit identifier are completely defined by the value of +# identifier_offset and cardinality. For example if identifier run from +# -2 to 3 the value for identifier_offset is -2. +# +# For explicit indexing the field identifier has to be used. +# Fortran-/Matlab- and C-/Python-style indexing have specific implicit +# identifier conventions where identifier_offset is 1 and 0 respectively. +# +# +# +# +# Identifier of each member for explicit indexing. +# +# +# +# +# +# +# +# The center of mass position of each primitive. +# +# +# +# +# +# +# +# +# +# True if the center is a center of mass. +# +# +# +# +# +# +# +# A qualitative description of the shape of each primitive. +# +# +# +# +# +# +# +# +# Qualifier for the length of characteristic features of the primitive. +# +# Often the term length is associated with the assumption that one +# edge is parallel to an axis of the coordinate system. +# +# +# +# +# +# +# +# Qualifier often used to describe the length of one characteristic edge +# within the coordinate system. +# +# +# +# +# +# +# +# True if primitive is closed such that it has properties like area or volume. +# +# +# +# +# +# +# +# Volume of each primitive. +# +# Set to NaN if does not apply for primitives for which is_closed is False. +# +# +# +# +# +# +# +# Alias for surface_area of each primitive. +# +# Set to NaN if does not apply for primitives for which is_closed is False. +# +# +# +# +# +# +# +# Direction unit vector which points along the +# longest principal axis of each primitive. +# +# Use the depends_on attribute to specify in which coordinate system +# these direction unit vectors are defined. +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_roi_set.yaml b/contributed_definitions/nyaml/NXcg_roi_set.yaml index b10a341fe0..7410313756 100644 --- a/contributed_definitions/nyaml/NXcg_roi_set.yaml +++ b/contributed_definitions/nyaml/NXcg_roi_set.yaml @@ -8,18 +8,17 @@ doc: | symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. - - Use the depends_on fields of the respective specialized :ref:`NXcg_primitive_set` - base class surplus :ref:`NXcoordinate_system_set` with at least one instance - of :ref:`NXcoordinate_system` to define explicitly the reference frame in - which the primitives are defined. - - Alternatively, although disencouraged, one may use one :ref:`NXcoordinate_system_set` - with with only one :ref:`NXcoordinate_system` in the application definition - to specify implicitly in which reference frame the primitives are defined. - - If none of these two possibilities is used all primitives are assumed - defined in the McStas coordinate system. + Use the depends_on fields of the respective specialized + :ref:`NXcg_primitive_set` base class surplus + :ref:`NXcoordinate_system_set` with at least one instance of + :ref:`NXcoordinate_system` to define explicitly the reference frame in + which the primitives are defined. Alternatively, although + disencouraged, one may use one :ref:`NXcoordinate_system_set` with + with only one :ref:`NXcoordinate_system` in the application definition + to specify implicitly in which reference frame the primitives are + defined. If none of these two possibilities is used all primitives + are assumed defined in the McStas coordinate system. + # eventually redundant NXsolid_geometry? type: group NXcg_roi_set(NXobject): @@ -29,5 +28,66 @@ NXcg_roi_set(NXobject): (NXcg_parallelogram_set): (NXcg_hexahedron_set): (NXcg_polyhedron_set): + # how to handle cases where multiple primitives should be included? # see comment to NXcg_triangle_set roi + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# d6f52b5de8da4a3970ac6c87ffb8370c01cb55ece78b50303bf85cbdb8168d27 +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# Use the depends_on fields of the respective specialized +# :ref:`NXcg_primitive_set` base class surplus +# :ref:`NXcoordinate_system_set` with at least one instance of +# :ref:`NXcoordinate_system` to define explicitly the reference frame in +# which the primitives are defined. Alternatively, although +# disencouraged, one may use one :ref:`NXcoordinate_system_set` with +# with only one :ref:`NXcoordinate_system` in the application definition +# to specify implicitly in which reference frame the primitives are +# defined. If none of these two possibilities is used all primitives +# are assumed defined in the McStas coordinate system. +# +# +# +# Base class for a region-of-interest (ROI) bound by geometric primitives. +# +# So-called region-of-interest(s) (ROIs) are typically used to describe a +# region in space (and time) where an observation is made or for which +# a computer simulation is performed with given boundary conditions. +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_sphere_set.yaml b/contributed_definitions/nyaml/NXcg_sphere_set.yaml index c6b6e1d59b..9ed6e9b8d1 100644 --- a/contributed_definitions/nyaml/NXcg_sphere_set.yaml +++ b/contributed_definitions/nyaml/NXcg_sphere_set.yaml @@ -10,16 +10,83 @@ symbols: The dimensionality, which has to be at least 2. c: | The cardinality of the set, i.e. the number of circles or spheres. + # redundant as there is NXcsg, and NXquadric but easier to understand type: group NXcg_sphere_set(NXcg_ellipsoid_set): radius(NX_NUMBER): + unit: NX_LENGTH doc: | In the case that all spheres have the same radius. - unit: NX_LENGTH radii(NX_NUMBER): + unit: NX_LENGTH doc: | In the case that spheres have different radius use this instead of the radius field. - unit: NX_LENGTH - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 4244bce7df1a9da99adba31938a2347fc3575c0427819ef5fb02dde22d2e30d6 +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality, which has to be at least 2. +# +# +# +# +# The cardinality of the set, i.e. the number of circles or spheres. +# +# +# +# +# Computational geometry description of a set of spheres. +# +# Each sphere can have a different radius but all need to have finite volume. +# +# +# +# In the case that all spheres have the same radius. +# +# +# +# +# In the case that spheres have different radius use this +# instead of the radius field. +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml b/contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml index 1200fc9e10..8a88da4d47 100644 --- a/contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml +++ b/contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml @@ -12,26 +12,31 @@ symbols: The cardinality of the set, i.e. the number of tetrahedra. type: group NXcg_tetrahedron_set(NXcg_primitive_set): + # qualifiers and properties of tetrahedra face_area(NX_NUMBER): + unit: NX_AREA doc: | Area of each of the four triangular faces of each tetrahedron. - unit: NX_AREA - dim: (c, 4) + dimensions: + rank: 2 + dim: [[1, c], [2, 4]] edge_length(NX_NUMBER): + unit: NX_LENGTH doc: | Length of each edge of each tetrahedron. - unit: NX_LENGTH - dim: (c, 6) + dimensions: + rank: 2 + dim: [[1, c], [2, 6]] + # substantially more detailed descriptors of the shape, the mesh # currently not used should be discussed as sequence might not be clear to everybody # interior_angle(NX_NUMBER): - # doc: | - # Interior angle values for each tetrahedron. - # The quadruplet of angles is a sequence following the order of the vertices. - # The angle is the angle at the specific vertex. - # - # The sequence of the vertices follows their definition in tetrahedra. + # doc: | + # Interior angle values for each tetrahedron. + # The quadruplet of angles is a sequence following the order of the vertices. + # The angle is the angle at the specific vertex. + # The sequence of the vertices follows their definition in tetrahedra. # detailed mesh-based representation tetrahedra(NXcg_face_list_data_structure): doc: | @@ -42,3 +47,92 @@ NXcg_tetrahedron_set(NXcg_primitive_set): tetrahedron_half_edgeID(NXcg_half_edge_data_structure): doc: | Individual storage of each tetrahedron as a graph. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 9af8304da5812e9850077983105c5c0baffa7b6e09f1592ab4b4364db00a8332 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The cardinality of the set, i.e. the number of tetrahedra. +# +# +# +# +# Computational geometry description of a set of tetrahedra. +# +# Among hexahedral elements, tetrahedral elements are one of the most +# frequently used geometric primitive for meshing and describing volumetric +# objects in continuum-field simulations. +# +# +# +# +# Area of each of the four triangular faces of each tetrahedron. +# +# +# +# +# +# +# +# +# Length of each edge of each tetrahedron. +# +# +# +# +# +# +# +# +# +# Combined storage of all primitives of all tetrahedra. +# +# +# +# +# Individual storage of each tetrahedron. +# +# +# +# +# Individual storage of each tetrahedron as a graph. +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_triangle_set.yaml b/contributed_definitions/nyaml/NXcg_triangle_set.yaml index 5eb5b915eb..29fec60e2a 100644 --- a/contributed_definitions/nyaml/NXcg_triangle_set.yaml +++ b/contributed_definitions/nyaml/NXcg_triangle_set.yaml @@ -13,9 +13,9 @@ symbols: type: group NXcg_triangle_set(NXcg_primitive_set): number_of_unique_vertices(NX_INT): + unit: NX_UNITLESS doc: | Number of unique vertices in the triangle set. - unit: NX_UNITLESS triangles(NXcg_face_list_data_structure): doc: | Combined storage of all primitives of all triangles. @@ -27,24 +27,129 @@ NXcg_triangle_set(NXcg_primitive_set): Individual storage of each triangle. Users are advised that using such individual storage of primitives may be less storage efficient than creating a combined storage. - # ##MK::considered too trivial: + + ##MK::considered too trivial: # triangle_half_edgeID(NXcg_half_edge_data_structure): - # doc: | - # Individual storage of each triangle as a graph. + # doc: | + # Individual storage of each triangle as a graph. # properties of triangles edge_length(NX_NUMBER): + unit: NX_LENGTH doc: | Length of the edges of each triangle. For each triangle values are reported via traversing the vertices in the sequence as these are defined. - unit: NX_LENGTH - dim: (c, 3) + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] interior_angle(NX_NUMBER): + unit: NX_ANGLE doc: | Interior angles of each triangle. For each triangle values are reported for the angle opposite to the respective edges in the sequence how vertices are defined. - unit: NX_ANGLE - dim: (c, 3) + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# ae9612828131a3d5dbc9dbec38cca6a904c1284b9c5bd2c45ba2a82f82a26c41 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality, which has to be at least 2. +# +# +# +# +# The cardinality of the set, i.e. the number of triangles. +# +# +# +# +# The number of unique vertices supporting the triangles. +# +# +# +# +# Computational geometry description of a set of triangles. +# +# +# +# Number of unique vertices in the triangle set. +# +# +# +# +# Combined storage of all primitives of all triangles. +# +# This description resembles the typical representation of primitives +# in file formats such as OFF, PLY, VTK, or STL. +# +# +# +# +# Individual storage of each triangle. +# Users are advised that using such individual storage of primitives +# may be less storage efficient than creating a combined storage. +# +# +# +# +# +# Length of the edges of each triangle. +# +# For each triangle values are reported via traversing +# the vertices in the sequence as these are defined. +# +# +# +# +# +# +# +# +# Interior angles of each triangle. +# +# For each triangle values are reported for the angle opposite +# to the respective edges in the sequence how vertices are defined. +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml b/contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml index 927134bb85..c834b7f89f 100644 --- a/contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml +++ b/contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml @@ -13,3 +13,48 @@ NXcg_triangulated_surface_mesh(NXcg_triangle_set): doc: | A graph-based approach to describe the mesh when it is also desired to perform topological processing or analyses on the mesh. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 51a205f7bbac0684cc5a57d15ae2b74b8bbce829cf9a321dfa64349370e7972b +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Computational geometry description of a mesh of triangles. +# +# The mesh may be self-intersecting and have holes but the +# triangles used must not be degenerated. +# +# +# +# A graph-based approach to describe the mesh when it is also desired +# to perform topological processing or analyses on the mesh. +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_unit_normal_set.yaml b/contributed_definitions/nyaml/NXcg_unit_normal_set.yaml index 1f293365d8..8ebac1851b 100644 --- a/contributed_definitions/nyaml/NXcg_unit_normal_set.yaml +++ b/contributed_definitions/nyaml/NXcg_unit_normal_set.yaml @@ -5,6 +5,7 @@ doc: | Store normal vector information as properties of primitives. Use only only as a child of an instance of :ref:`NXcg_primitive_set` so that this instance acts as the parent to define a context. + # eventually remove this base class and make normal vector a property of the primitive symbols: doc: | @@ -20,11 +21,14 @@ symbols: type: group NXcg_unit_normal_set(NXobject): normals(NX_NUMBER): + unit: NX_LENGTH doc: | Direction of each normal - a unit normal. - unit: NX_LENGTH # length is normalized to 1 but it remains a length quantity - dim: (c, d) + dimensions: + rank: 2 + dim: [[1, c], [2, d]] orientation(NX_INT): + unit: NX_UNITLESS doc: | Qualifier which details the orientation of each normal vector in relation to its primitive, assuming the object is viewed @@ -33,5 +37,84 @@ NXcg_unit_normal_set(NXobject): * 0 - undefined * 1 - outer unit normal vector * 2 - inner unit normal vector - unit: NX_UNITLESS - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 7e75ce150a834481da5994ba201eb5582c9fdb4862f5e6bf10f2957f07d9db5d +# +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality, which has to be at least 2. +# +# +# +# +# The cardinality of the set, i.e. the number of unit normals. +# +# +# +# +# Computational geometry description of a set of (oriented) unit normal vectors. +# +# Store normal vector information as properties of primitives. +# Use only only as a child of an instance of :ref:`NXcg_primitive_set` +# so that this instance acts as the parent to define a context. +# +# +# +# Direction of each normal - a unit normal. +# +# +# +# +# +# +# +# +# Qualifier which details the orientation of each normal vector +# in relation to its primitive, assuming the object is viewed +# from a position outside the object. +# +# * 0 - undefined +# * 1 - outer unit normal vector +# * 2 - inner unit normal vector +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXchamber.yaml b/contributed_definitions/nyaml/NXchamber.yaml index 2a4d2c4495..758353a101 100644 --- a/contributed_definitions/nyaml/NXchamber.yaml +++ b/contributed_definitions/nyaml/NXchamber.yaml @@ -12,3 +12,47 @@ NXchamber(NXobject): Free-text field for describing details about the chamber. For example out of which material was the chamber built. (NXfabrication): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# fa1953f5766d4e3abc9af3cf08c564f565d7400ab8cfba9ce35502d1ab60a53c +# +# +# +# +# +# Base class for a chamber in an instrument that stores real or simulated objects. +# +# +# +# Given name for the chamber of this component e.g. analysis chamber +# or buffer chamber, load-lock chamber, microscope column, glove box. +# +# +# +# +# Free-text field for describing details about the chamber. +# For example out of which material was the chamber built. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXchemical_composition.yaml b/contributed_definitions/nyaml/NXchemical_composition.yaml index 4656b10dd8..4e6d8d4664 100644 --- a/contributed_definitions/nyaml/NXchemical_composition.yaml +++ b/contributed_definitions/nyaml/NXchemical_composition.yaml @@ -38,13 +38,13 @@ NXchemical_composition(NXobject): dim: [[1, n]] # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# dcbe5c04c6c94a2087662d892db25152b6af759a9841a0a127cf6c3859d10592 +# a68d56f7fd6f57632b751ec7d1a2bff2cb15bcdabd540958d7da8b035b086627 # # # +# +# +# Base class for components of an instrument - real ones or a simulated ones. +# +# +# +# Specifies the position of the component by pointing to the last +# transformation in the transformation chain that is defined +# via the NXtransformations group. +# +# +# +# +# Was the component used? +# +# +# +# +# Given name +# +# +# +# +# Ideally, use instances of :ref:`NXidentifier` to point to a resource +# that provides further details. +# +# If such a resource does not exist or should not be used, use this, though +# discouraged, free-text. +# +# +# +# +# +# +# +# Collection of axis-based translations and rotations to describe the +# location and geometry of the component in the instrument. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcontainer.yaml b/contributed_definitions/nyaml/NXcontainer.yaml index 2bfbdf7f58..f84ccd7889 100644 --- a/contributed_definitions/nyaml/NXcontainer.yaml +++ b/contributed_definitions/nyaml/NXcontainer.yaml @@ -122,13 +122,13 @@ NXcontainer(NXobject): which these data are valid. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# fbb634b42fbf75d55158a96329119a770f9ff716d2e3ec127b28b192c5fe872a +# 6459188ef3db14546f3ea4825e16e5e505be56f15622c367b0fb23978ee3691e # # # +# https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 +# enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left]--> # # # An alternative name given to that coordinate system. @@ -161,6 +164,7 @@ NXcoordinate_system(NXobject): # Coordinate system type. # # +# # # # @@ -169,6 +173,7 @@ NXcoordinate_system(NXobject): # Handedness of the coordinate system if it is a Cartesian. # # +# # # # @@ -187,6 +192,7 @@ NXcoordinate_system(NXobject): # Exemplar values could be direction of gravity. # # +# # # # Base unit vector along the first axis which spans the coordinate system. diff --git a/contributed_definitions/nyaml/NXcoordinate_system_set.yaml b/contributed_definitions/nyaml/NXcoordinate_system_set.yaml index a08719edb8..246d2a83c9 100644 --- a/contributed_definitions/nyaml/NXcoordinate_system_set.yaml +++ b/contributed_definitions/nyaml/NXcoordinate_system_set.yaml @@ -87,9 +87,10 @@ doc: | system is defined for practical purposes, explicit depends_on fields should always guide the user for each group and field which of the coordinate system one refers to. -type: group + # express conventions explicitly and understandable # use depends_on field - not attribute - to point to conventions used +type: group NXcoordinate_system_set(NXobject): rotation_handedness(NX_CHAR): doc: | @@ -114,7 +115,7 @@ NXcoordinate_system_set(NXobject): The most frequently used convention is zxz, which is based on the work of H.-J. Bunge but other conventions are possible. Apart from undefined, proper Euler angles are distinguished from (improper) Tait-Bryan angles. - enumeration: [undefined, zxz, xyx, yzy, zyz, xzx, yxy, xyz, yzx, zxy, xzy,zyx, yxz] + enumeration: [undefined, zxz, xyx, yzy, zyz, xzx, yxy, xyz, yzx, zxy, xzy, zyx, yxz] axis_angle_convention(NX_CHAR): doc: | To which angular range is the rotation angle argument of an @@ -127,8 +128,10 @@ NXcoordinate_system_set(NXobject): between different parameterizations/representations according to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. enumeration: [undefined, p_plus_one, p_minus_one] + # possibility to add further coordinate systems (NXcoordinate_system): + # frequently used coordinate systems with frequently relevant specializations follow # convention 1 of DOI: 10.1088/0965-0393/23/8/083501 is implemented by inheriting type from NXcoordinate_system processing_reference_frame(NXcoordinate_system): @@ -169,3 +172,246 @@ NXcoordinate_system_set(NXobject): from a position that is located behind the detector. If any of these assumptions is not met, the user is required to explicitly state this. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# fa0669fabccdeeabc454a75796585c48e1c98d117283a916cb459d66dda15aa7 +# +# +# +# +# +# +# Base class to hold different coordinate systems and representation conversions. +# +# How many nodes of type :ref:`NXcoordinate_system_set` should be used in an application definition? +# +# * 0; if there is no instance of :ref:`NXcoordinate_system_set` and therein or elsewhere across +# the application definition, an instance of NXcoordinate_system is defined, +# the default NeXus `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ +# coordinate system is assumed. This makes :ref:`NXcoordinate_system_set` and +# NXcoordinate_system base classes backwards compatible to older +# NeXus conventions and classes. +# * 1; if only one :ref:`NXcoordinate_system_set` is defined, it should be placed +# as high up in the node hierarchy (ideally right below an instance of NXentry) +# of the application definition tree as possible. +# This :ref:`NXcoordinate_system_set` should define at least one NXcoordinate_system +# instance. This shall be named such that it is clear how this coordinate system is +# typically referred to in a community. For the NeXus `McStas coordinate system, it is +# advised to call it mcstas for the sake of improved clarity. +# Additional NXcoordinate_system instances should be specified if possible in that same +# :ref:`NXcoordinate_system_set` instead of cluttering them across the tree. +# +# If this is the case, it is assumed that the NXcoordinate_system_members +# overwrite the NeXus default McStas coordinate system, i.e. users can thereby +# conveniently and explicitly specify the coordinate system(s) that +# they wish to use. +# +# Users are encouraged to write also explicit and clean depends_on fields in +# all groups that encode information about where the interpretation of coordinate +# systems is relevant. If these depends_on hints are not provided, it is +# automatically assumed that all children (to arbitrary depth) +# of that branch and sub-branches below the one in which that +# :ref:`NXcoordinate_system_set` is defined use either the only NXcoordinate_system_set +# instance in that set or the application definition is considered +# underconstrained which should at all costs be avoided and in which case +# again McStas is assumed. +# * 2 and more; as soon as more than one :ref:`NXcoordinate_system_set` is specified +# somewhere in the tree, different interpretations are possible as to which +# of these coordinate system sets and instances apply or take preference. +# We realize that such ambiguities should at all costs be avoided. +# However, the opportunity for multiple sets and their instances enables to +# have branch-specific coordinate system conventions which could especially +# be useful for deep classes where multiple scientific methods are combined or +# cases where having a definition of global translation and conversion tables +# how to convert between representations in different coordinate systems +# is not desired or available for now. +# We argue that having 2 or more :ref:`NXcoordinate_system_set` instances and respective +# NXcoordinate_system instances makes the interpretation eventually unnecessary +# complicated. Instead, developers of application definitions should always try +# to work for clarity and thus use only one top-level coordinate system set. +# +# For these reasons we conclude that the option with one top-level +# :ref:`NXcoordinate_system_set` instance is the preferred choice. +# +# McStas is used if neither an instance of :ref:`NXcoordinate_system_set` nor an instance +# of NXcoordinate_system is specified. However, even in this case it is better +# to be explicit like for every other coordinate system definition to support +# users with interpreting the content and logic behind every instance of the tree. +# +# How to store coordinate systems inside :ref:`NXcoordinate_system_set`? +# Individual coordinate systems should be specified as members of the +# :ref:`NXcoordinate_system_set` instance using instances of NXcoordinate_system. +# +# How many individual instances of NXcoordinate_system to allow within one +# instance of :ref:`NXcoordinate_system_set`? +# +# * 0; This case should be avoided for the sake of clarity but this case could +# mean the authors of the definition meant that McStas is used. We conclude, +# McStas is used in this case. +# * 1; Like above-mentioned this case has the advantage that it is explicit +# and faces no ambiguities. However, in reality typically multiple +# coordinate systems have to be mastered especially for complex +# multi-signal modality experiments. +# * 2 or more; If this case is realized, the best practice is that in every +# case where a coordinate system should be referred to the respective class +# has a depends_on field which resolves the possible ambiguities which specific +# coordinate systems is referred to. The benefit of this explicit and clear +# specifying of the coordinate system used in every case is that especially +# in combination with having coordinate systems inside deeper branches +# makes up for a very versatile, backwards compatible, but powerful system +# to express different types of coordinate systems using NeXus. In the case +# of two or more instances of NXcoordinate_system in one :ref:`NXcoordinate_system_set`, +# it is also advised to specify the relationship between the two coordinate systems by +# using the (NXtransformations) group within NXcoordinate_system. +# +# In effect, 1 should be the preferred choice. However, if more than one coordinate +# system is defined for practical purposes, explicit depends_on fields should +# always guide the user for each group and field which of the coordinate system +# one refers to. +# +# +# +# Convention how a positive rotation angle is defined when viewing +# from the end of the rotation unit vector towards its origin, +# i.e. in accordance with convention 2 of +# DOI: 10.1088/0965-0393/23/8/083501. +# Counter_clockwise is equivalent to a right-handed choice. +# Clockwise is equivalent to a left-handed choice. +# +# +# +# +# +# +# +# +# +# How are rotations interpreted into an orientation +# according to convention 3 of +# DOI: 10.1088/0965-0393/23/8/083501. +# +# +# +# +# +# +# +# +# +# How are Euler angles interpreted given that there are several choices (e.g. zxz, xyz) +# according to convention 4 of DOI: 10.1088/0965-0393/23/8/083501. +# +# The most frequently used convention is zxz, which is based on the work of H.-J. Bunge +# but other conventions are possible. Apart from undefined, proper Euler angles +# are distinguished from (improper) Tait-Bryan angles. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# To which angular range is the rotation angle argument of an +# axis-angle pair parameterization constrained according to +# convention 5 of DOI: 10.1088/0965-0393/23/8/083501. +# +# +# +# +# +# +# +# +# Which sign convention is followed when converting orientations +# between different parameterizations/representations according +# to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. +# +# +# +# +# +# +# +# +# +# +# +# +# Details about eventually relevant named directions that may give reasons for anisotropies. +# The classical example is mechanical processing where one has to specify which directions +# (e.g. rolling, transverse, and normal direction) align how with the direction of the base +# vectors of the sample_reference_frame. +# +# It is assumed that the configuration is inspected by looking towards the sample surface. +# If a detector is involved, it is assumed that the configuration is inspected from a position +# that is located behind this detector. +# +# If any of these assumptions is not met, the user is required to explicitly state this. +# +# Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the +# base vectors of this coordinate system as Xp, Yp, Zp. +# +# +# +# +# Details about the sample_reference_frame that is typically overlaid onto the surface of the sample. +# +# It is assumed that the configuration is inspected by looking towards the sample surface. +# If a detector is involved, it is assumed that the configuration is inspected from a position +# that is located behind this detector. +# +# If any of these assumptions is not met, the user is required to explicitly state this. +# +# Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the +# base vectors of this coordinate system as Xs, Ys, Zs. +# +# +# +# +# Details about the detector_reference_frame for a specific detector. +# +# Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the +# base vectors of this coordinate system as Xd, Yd, Zd. +# +# It is assumed that the configuration is inspected by looking towards the sample surface +# from a position that is located behind the detector. +# +# If any of these assumptions is not met, the user is required to explicitly state this. +# +# +# diff --git a/contributed_definitions/nyaml/NXcorrector_cs.yaml b/contributed_definitions/nyaml/NXcorrector_cs.yaml index f23f7e07a6..c04317d4f4 100644 --- a/contributed_definitions/nyaml/NXcorrector_cs.yaml +++ b/contributed_definitions/nyaml/NXcorrector_cs.yaml @@ -10,25 +10,27 @@ doc: | and microscope. Many of their technical details is proprietary knowledge. If functionalities for correcting multiple aberrations are included in - one :ref:`NXcomponent` `like it is reported here `_ + one :ref:`NXcomponent` `like it is reported here `_ use multiple groups: * :ref:`NXcorrector_cs` for spherical aberration * :ref:`NXmonochromator` for energy filtering or chromatic aberration * corrector_ax in :ref:`NXem` for axial astigmatism correction - -# https://doi.org/10.1017/9781316337455.022 -type: group symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. n_img: | Number of images taken, at least one. + +# https://doi.org/10.1017/9781316337455.022 +type: group NXcorrector_cs(NXcomponent): + # user perspective applied(NX_BOOLEAN): doc: | Was the corrector used? + # NEW ISSUE: clarify further mathematical details tableauID(NXprocess): doc: | @@ -40,26 +42,33 @@ NXcorrector_cs(NXcomponent): corrections. description(NX_CHAR): doc: | - Discouraged free-text field to add further details about the alignment procedure. + Discouraged free-text field to add further details about the alignment + procedure. tilt_angle(NX_NUMBER): + unit: NX_ANGLE doc: | The outer tilt angle of the beam in tableau acquisition. TODO: The relevant axes which span the tilt_angle need a cleaner description. - unit: NX_ANGLE - dim: (n_img,) + dimensions: + rank: 1 + dim: [[1, n_img]] exposure_time(NX_NUMBER): + unit: NX_TIME doc: | The exposure time of single tilt images. - unit: NX_TIME - dim: (n_img,) + dimensions: + rank: 1 + dim: [[1, n_img]] magnification(NX_NUMBER): + unit: NX_DIMENSIONLESS doc: | The factor of enlargement of the apparent size, not the physical size, of an object. - unit: NX_DIMENSIONLESS - dim: (n_img,) + dimensions: + rank: 1 + dim: [[1, n_img]] (NXimage_set): doc: | The images taken during the alignment procedure. @@ -71,33 +80,40 @@ NXcorrector_cs(NXcomponent): for different definitions available and further details. Table 7-2 of Ibid. publication (page 305ff) documents how to convert from the Nion to the CEOS definitions. Conversion tables are also summarized by `Y. Liao `_. enumeration: [ceos, nion] + # specifically-named aberrations following the CEOS / Typke and Dierksen convention c_1(NXaberration): - # magnitude(NX_NUMBER): - # unit: NX_LENGTH + + # magnitude(NX_NUMBER): + # unit: NX_LENGTH a_1(NXaberration): b_2(NXaberration): a_2(NXaberration): c_3(NXaberration): - # magnitude(NX_NUMBER): - # unit: NX_LENGTH + + # magnitude(NX_NUMBER): + # unit: NX_LENGTH s_3(NXaberration): a_3(NXaberration): + # based on feedback from Thilo Remmele the following aberrations could be measured # (enhanced mode, tilt angle > 30 mrad) but are not corrected for with b_4(NXaberration): d_4(NXaberration): a_4(NXaberration): c_5(NXaberration): - # magnitude(NX_NUMBER): - # unit: NX_LENGTH + + # magnitude(NX_NUMBER): + # unit: NX_LENGTH s_5(NXaberration): r_5(NXaberration): a_6(NXaberration): + # specifically-named aberrations following the Nion convention c_1_0(NXaberration): - # magnitude(NX_NUMBER): - # unit: NX_LENGTH + + # magnitude(NX_NUMBER): + # unit: NX_LENGTH c_1_2_a(NXaberration): c_1_2_b(NXaberration): c_2_1_a(NXaberration): @@ -105,8 +121,9 @@ NXcorrector_cs(NXcomponent): c_2_3_a(NXaberration): c_2_3_b(NXaberration): c_3_0(NXaberration): - # magnitude(NX_NUMBER): - # unit: NX_LENGTH + + # magnitude(NX_NUMBER): + # unit: NX_LENGTH c_3_2_a(NXaberration): c_3_2_b(NXaberration): c_3_4_a(NXaberration): @@ -118,53 +135,280 @@ NXcorrector_cs(NXcomponent): c_4_5_a(NXaberration): c_4_5_b(NXaberration): c_5_0(NXaberration): - # magnitude(NX_NUMBER): - # unit: NX_LENGTH + + # magnitude(NX_NUMBER): + # unit: NX_LENGTH c_5_2_a(NXaberration): c_5_2_b(NXaberration): c_5_4_a(NXaberration): c_5_4_b(NXaberration): c_5_6_a(NXaberration): c_5_6_b(NXaberration): - # further comments from Thilo Remmele (Leibniz-Institut für Kristallzüchtung) - # ThermoFisher uses CEOS correctors but makes customizations to these in their microscopes - # Aberration naming schema: C_order_multiplicity (similar to NXem, but with - # another coordinate system and in addition with a confidence entry. - # Aberrations with multiplicity 0 have no angle entry (C1,C3,C5,.., CEOS notation) - # contrast transferfuntion: ctf = e^(-i*Xi(g)) in Fourier space - # aberration function: - # Xi(g) = 2*pi/lamda{ 1/2 * (lamda*g)^2 (C20 + C22 cos[2(phi-phi_22)] - # +1/3 * (lamda*g)^3 (C31 cos[(phi-phi_31) + C33 cos[3(phi-phi_33) - # +1/4 * (lamda*g)^4 (C40 + C42 cos[2(phi-phi_42)] + C44 cos[4(phi-phi_42)] - # +1/f * (lamda*g)^f Sum (Cfm cos[m(phi-phi_fm)] where m=[0,2,..f] for even f and m=[1,3,..,f] for odd f - # Thilo Remmele also mentions that there is a mapping of aberration coefficient names: - # C_2_0 -> C1 Defocus - # C_2_2 -> A1 2-fold astigmatism - # C_3_3 -> A2 3-fold astigmatism - # C_3_1 -> B2 axial coma - # C_4_0 -> C3 spherical aberration - # C_4_4 -> A3 4-fold astigmatism - # C_4_2 -> S3 star aberration - # C_5_5 -> A4 5-fold astigmatism - # C_5_1 -> B4 axial coma - # C_5_3 -> D4 three lobe aberration - # C_6_0 -> C5 spherical aberration - # C_6_2 -> S5 star aberration - # C_6_4 -> R5 rosette aberration - # C_6_6 -> A5 6-fold astigmatism - # In a session with HRTEM images the corrector is commonly aligned. - # The final measurement with the estimated residual aberrations - # should be saved in a corrector.html file (an example is appended - # at the end of this file. Unfortunately the datetime is not included - # in that html output, nor is the used outer tilt angle and exposure time. - # The datetime may be estimated from the file datetime and the Delta t entry, - # but caution if that datetime is not preserved on file transfers! - # More than one detector entry could occure but is not common. - # A seperate corrector schema, so it can be easily exchanged to other correctors if necessary. - # It might be useful to collect all the corrector entries in one table, for example to analyse the performance of the corrector. - # The corrector entry of the nexus em definition lacks the confidence information and the - # parameter settings for the estimation oft the aberrations. + + # further comments from Thilo Remmele (Leibniz-Institut für Kristallzüchtung) + # ThermoFisher uses CEOS correctors but makes customizations to these in their microscopes + # Aberration naming schema: C_order_multiplicity (similar to NXem, but with + # another coordinate system and in addition with a confidence entry. + # Aberrations with multiplicity 0 have no angle entry (C1,C3,C5,.., CEOS notation) + # contrast transferfuntion: ctf = e^(-i*Xi(g)) in Fourier space + # aberration function: + # Xi(g) = 2*pi/lamda{ 1/2 * (lamda*g)^2 (C20 + C22 cos[2(phi-phi_22)] + # +1/3 * (lamda*g)^3 (C31 cos[(phi-phi_31) + C33 cos[3(phi-phi_33) + # +1/4 * (lamda*g)^4 (C40 + C42 cos[2(phi-phi_42)] + C44 cos[4(phi-phi_42)] + # +1/f * (lamda*g)^f Sum (Cfm cos[m(phi-phi_fm)] where m=[0,2,..f] for even f and m=[1,3,..,f] for odd f + # Thilo Remmele also mentions that there is a mapping of aberration coefficient names: + # C_2_0 -> C1 Defocus + # C_2_2 -> A1 2-fold astigmatism + # C_3_3 -> A2 3-fold astigmatism + # C_3_1 -> B2 axial coma + # C_4_0 -> C3 spherical aberration + # C_4_4 -> A3 4-fold astigmatism + # C_4_2 -> S3 star aberration + # C_5_5 -> A4 5-fold astigmatism + # C_5_1 -> B4 axial coma + # C_5_3 -> D4 three lobe aberration + # C_6_0 -> C5 spherical aberration + # C_6_2 -> S5 star aberration + # C_6_4 -> R5 rosette aberration + # C_6_6 -> A5 6-fold astigmatism + # In a session with HRTEM images the corrector is commonly aligned. + # The final measurement with the estimated residual aberrations + # should be saved in a corrector.html file (an example is appended + # at the end of this file. Unfortunately the datetime is not included + # in that html output, nor is the used outer tilt angle and exposure time. + # The datetime may be estimated from the file datetime and the Delta t entry, + # but caution if that datetime is not preserved on file transfers! + # More than one detector entry could occure but is not common. + # A seperate corrector schema, so it can be easily exchanged to other correctors if necessary. + # It might be useful to collect all the corrector entries in one table, for example to analyse the performance of the corrector. + # The corrector entry of the nexus em definition lacks the confidence information and the + # parameter settings for the estimation oft the aberrations. # technical design perspective (NXlens_em): (NXaperture): + # (NXdeflector): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 54b0cb04b663feb598fd601ce1e9a1f54ed33ed4d19bc96fee06ec3c0f7dafee +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of images taken, at least one. +# +# +# +# +# Base class for a corrector reducing (spherical) aberrations in electron microscopy. +# +# Different technology partners use different naming schemes and +# models for quantifying the aberration coefficients. +# +# The corrector in an electron microscope is composed of multiple lenses +# and multipole stigmators with details specific for the technology partner +# and microscope. Many of their technical details is proprietary knowledge. +# +# If functionalities for correcting multiple aberrations are included in +# one :ref:`NXcomponent` `like it is reported here <https://www.ceos-gmbh.de/en/research/electrostat>`_ +# use multiple groups: +# +# * :ref:`NXcorrector_cs` for spherical aberration +# * :ref:`NXmonochromator` for energy filtering or chromatic aberration +# * corrector_ax in :ref:`NXem` for axial astigmatism correction +# +# +# +# +# Was the corrector used? +# +# +# +# +# +# Specific information about the alignment procedure that is a process during which +# the corrector is configured to enable calibrated usage of the instrument. +# +# This :ref:`NXprocess` group should also be used when one describes in a computer +# simulation the specific details about the modelled or assumed aberration +# corrections. +# +# +# +# Discouraged free-text field to add further details about the alignment +# procedure. +# +# +# +# +# The outer tilt angle of the beam in tableau acquisition. +# +# TODO: The relevant axes which span the tilt_angle need a +# cleaner description. +# +# +# +# +# +# +# +# The exposure time of single tilt images. +# +# +# +# +# +# +# +# The factor of enlargement of the apparent size, +# not the physical size, of an object. +# +# +# +# +# +# +# +# The images taken during the alignment procedure. +# +# +# +# +# Place for storing measured or estimated aberrations (for each image or final). +# +# See `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) +# for different definitions available and further details. Table 7-2 of Ibid. publication (page 305ff) documents how +# to convert from the Nion to the CEOS definitions. Conversion tables are also summarized by `Y. Liao <https://www.globalsino.com/EM/page3740.html>`_. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml index d3d659c55f..55f6d8e5b6 100644 --- a/contributed_definitions/nyaml/NXcrystal_structure.yaml +++ b/contributed_definitions/nyaml/NXcrystal_structure.yaml @@ -7,6 +7,7 @@ doc: | Examples where such base class is useful are kinematic or dynamic diffraction simulations of e.g. (Kikuchi or other type of) patterns. + # The actual indexing of Kikuchi patterns may use different algorithms. # Such are used within different workflows where simulated and measured # Kikuchi pattern are compared to rate which phase and orientation is the most @@ -36,41 +37,50 @@ NXcrystal_structure(NXobject): Reference to another resource that was used for instantiating this structure model. a_b_c(NX_NUMBER): + unit: NX_LENGTH doc: | Crystallography unit cell parameters a, b, and c. - unit: NX_LENGTH - dim: (d,) + dimensions: + rank: 1 + dim: [[1, d]] + # defined using which convention? alpha_beta_gamma(NX_NUMBER): + unit: NX_ANGLE doc: | Crystallography unit cell parameters alpha, beta, and gamma. - unit: NX_ANGLE - dim: (d,) + dimensions: + rank: 1 + dim: [[1, d]] area(NX_NUMBER): + unit: NX_AREA doc: | Area of the unit cell considering that d = 2. - unit: NX_AREA volume(NX_NUMBER): + unit: NX_VOLUME doc: | Volume of the unit cell considering that d = 3. - unit: NX_VOLUME crystal_system(NX_CHAR): doc: | Crystal system enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + # 2d laue_group(NX_CHAR): doc: | Laue group using International Table of Crystallography Notation. + # add enumeration of all possible point_group(NX_CHAR): doc: | Point group using International Table of Crystallography Notation. + # add enumeration all possible # 3d space_group(NX_CHAR): doc: | Space group from the International Table of Crystallography Notation. + # add enumeration of all possible is_centrosymmetric(NX_BOOLEAN): doc: | @@ -85,6 +95,7 @@ NXcrystal_structure(NXobject): True if space group is considered a chiral one. False if space group is consider a non-chiral one. phase_identifier(NX_INT): + unit: NX_UNITLESS doc: | Identifier for each phase. @@ -97,7 +108,6 @@ NXcrystal_structure(NXobject): if two phases were used e.g. 0 and 1, two instances of an :ref:`NXcrystal_structure` named phase0 and phase1 should be stored in the HDF5 file. - unit: NX_UNITLESS phase_name(NX_CHAR): doc: | Name of the phase/alias. @@ -107,37 +117,49 @@ NXcrystal_structure(NXobject): atom_identifier(NX_CHAR): doc: | Label for each atom position. - dim: (n_pos,) + dimensions: + rank: 1 + dim: [[1, n_pos]] atom_type(NX_UINT): + unit: NX_UNITLESS doc: | The hash value :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` the number of protons and :math:`N` the number of neutrons of each isotope respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) `_ - unit: NX_UNITLESS - dim: (n_pos,) + dimensions: + rank: 1 + dim: [[1, n_pos]] + # atom_position(NXcg_point_set): atom_position(NX_NUMBER): + unit: NX_ANY doc: | Atom positions. - dim: (n_pos, d) - unit: NX_ANY - \@depends_on(NX_CHAR): + dimensions: + rank: 2 + dim: [[1, n_pos], [2, d]] + \@depends_on: + type: NX_CHAR doc: | Details the reference frame in which the positions are defined. + # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory # to describe the simulated Kikuchi pattern generated from such a model atom_occupancy(NX_NUMBER): + unit: NX_DIMENSIONLESS doc: | Relative occupancy of the atom position. - unit: NX_DIMENSIONLESS - dim: (n_pos,) + dimensions: + rank: 1 + dim: [[1, n_pos]] number_of_planes(NX_UINT): + unit: NX_UNITLESS doc: | How many reflectors are distinguished. Value has to match value for symbol n_hkl. - unit: NX_UNITLESS + # Miller indices :math:`(hkl)[uvw]`. miller(NX_NUMBER): unit: NX_UNITLESS @@ -147,26 +169,310 @@ NXcrystal_structure(NXobject): The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - dim: (n_hkl, 6) + dimensions: + rank: 2 + dim: [[1, n_hkl], [2, 6]] dspacing(NX_NUMBER): + unit: NX_LENGTH doc: | Spacing between crystallographic planes as defined by field miller. - unit: NX_LENGTH - dim: (n_hkl,) + dimensions: + rank: 1 + dim: [[1, n_hkl]] relative_intensity(NX_NUMBER): + unit: NX_DIMENSIONLESS doc: | Relative intensity of the signal for the plane. - unit: NX_DIMENSIONLESS - dim: (n_hkl,) + dimensions: + rank: 1 + dim: [[1, n_hkl]] number_of_scan_points(NX_UINT): + unit: NX_UNITLESS doc: | In case the :ref:`NXcrystal_structure` base class is used with analyzed orientation maps this field stores how many scan points of the map were identified as that phase. - unit: NX_UNITLESS ipfID(NXmicrostructure_ipf): pfID(NXmicrostructure_pf): odfID(NXmicrostructure_odf): -# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) + + # here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) + # can give some good suggestions on how to improve and ideally make even + # more general this section + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# a0ab6b47f498164b0301ca0680e93110a48862b5b3e94e09fe4afb9ab4d5d882 +# +# +# +# +# +# +# +# +# Number of reflectors (Miller crystallographic plane triplets). +# +# +# +# +# Number of atom positions. +# +# +# +# +# Dimensionality of the lattice. +# +# +# +# +# Base class to describe the atomic crystal structure of a phase. +# +# This base class contains key metadata that are relevant parameter to every +# physics-based model to simulate radiation matter interaction. +# +# Examples where such base class is useful are kinematic or dynamic +# diffraction simulations of e.g. (Kikuchi or other type of) patterns. +# +# +# +# Details in which reference frame the unit cell is defined. +# +# +# +# +# Dimensionality of the lattice. +# +# +# +# +# +# +# +# +# +# Reference to another resource that was used for +# instantiating this structure model. +# +# +# +# +# Crystallography unit cell parameters a, b, and c. +# +# +# +# +# +# +# +# +# Crystallography unit cell parameters alpha, beta, and gamma. +# +# +# +# +# +# +# +# Area of the unit cell considering that d = 2. +# +# +# +# +# Volume of the unit cell considering that d = 3. +# +# +# +# +# Crystal system +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Laue group using International Table of Crystallography Notation. +# +# +# +# +# +# Point group using International Table of Crystallography Notation. +# +# +# +# +# +# Space group from the International Table of Crystallography Notation. +# +# +# +# +# +# True if space group is considered a centrosymmetric one. +# False if space group is considered a non-centrosymmetric one. +# Centrosymmetric has all types and combinations of symmetry elements +# (translation, rotational axis, mirror planes, center of inversion) +# Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). +# Chiral compared to non-centrosymmetric is constrained (no mirror planes). +# +# +# +# +# True if space group is considered a chiral one. +# False if space group is consider a non-chiral one. +# +# +# +# +# Identifier for each phase. +# +# The value 0 is reserved for the unknown phase that represents the +# null-model no sufficiently significant confirmation. In other words, +# the phase_name is n/a, notIndexed. +# +# The phase identifier value has to match with the integer postfix of the +# group name which represents that instance in a NeXus/HDF5 file, i.e. +# if two phases were used e.g. 0 and 1, two instances of an +# :ref:`NXcrystal_structure` named phase0 and phase1 +# should be stored in the HDF5 file. +# +# +# +# +# Name of the phase/alias. +# +# If the phase_identifier is 0 and one would like to use the field +# phase_name the value should be n/a. +# +# +# +# +# Label for each atom position. +# +# +# +# +# +# +# +# The hash value :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` +# the number of protons and :math:`N` the number of neutrons +# of each isotope respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. +# For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ +# +# +# +# +# +# +# +# +# Atom positions. +# +# +# +# +# +# +# +# Details the reference frame in which the positions are defined. +# +# +# +# +# +# +# Relative occupancy of the atom position. +# +# +# +# +# +# +# +# How many reflectors are distinguished. +# +# Value has to match value for symbol n_hkl. +# +# +# +# +# +# Miller indices :math:`(hkl)[uvw]` of the planes. +# +# The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. +# Miller indices refer to the Cartesian right-handed coordinate system +# of the unit cell. +# +# +# +# +# +# +# +# +# Spacing between crystallographic planes as defined by field miller. +# +# +# +# +# +# +# +# Relative intensity of the signal for the plane. +# +# +# +# +# +# +# +# In case the :ref:`NXcrystal_structure` base class is used +# with analyzed orientation maps this field stores how many scan points +# of the map were identified as that phase. +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcs_computer.yaml b/contributed_definitions/nyaml/NXcs_computer.yaml index 1517407fea..ad1802ed9d 100644 --- a/contributed_definitions/nyaml/NXcs_computer.yaml +++ b/contributed_definitions/nyaml/NXcs_computer.yaml @@ -16,11 +16,13 @@ NXcs_computer(NXobject): instructions can be found so that the program can be configured in such a manner that the result file is ideally recreatable yielding the same results. + # difference e.g. in Win11 between hardware ID, UUID, and device ID uuid(NX_CHAR): doc: | Ideally a (globally) unique persistent identifier of the computer, i.e. the Universally Unique Identifier (UUID) of the computing node. + # when it comes to performance monitoring processing(NXobject): doc: | @@ -51,9 +53,9 @@ NXcs_computer(NXobject): Qualifier for the type of random access memory. enumeration: [ddr4, ddr5] max_physical_capacity(NX_POSINT): + unit: NX_ANY doc: | Total amount of data which the medium can hold. - unit: NX_ANY name(NX_CHAR): doc: | Given name @@ -68,10 +70,160 @@ NXcs_computer(NXobject): Qualifier for the type of storage medium used. enumeration: [solid_state_disk, hard_disk, tape] max_physical_capacity(NX_POSINT): + unit: NX_ANY doc: | Total amount of data which the medium can hold. - unit: NX_ANY # NX_BIT name(NX_CHAR): doc: | Given name - # NXcircuit inherits fabrication from NXcomponent + + # NXcircuit inherits fabrication from NXcomponent + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# f9c6fb31265951b0d30e5eea2293d2afdf9c812f09307b891ba2442931242a28 +# +# +# +# +# +# Base class for reporting the description of a computer +# +# +# +# Given name/alias to the computing system, e.g. MyDesktop. +# +# +# +# +# Name of the operating system, e.g. Windows, Linux, Mac, Android. +# +# +# +# Version plus build number, commit hash, or description of an ever +# persistent resource where the source code of the program and build +# instructions can be found so that the program can be configured in +# such a manner that the result file is ideally recreatable yielding +# the same results. +# +# +# +# +# +# +# Ideally a (globally) unique persistent identifier of the computer, i.e. +# the Universally Unique Identifier (UUID) of the computing node. +# +# +# +# +# +# Details about the system of processing units e.g. (classical) processing units (CPUs), +# coprocessor, graphic cards, accelerator processing units or a system of these. +# +# +# +# Granularizing the processing units. Typical examples, a desktop computer +# with a single CPU one could describe using one instance of NXcircuit. +# A dual-socket server one could describe using two instances NXcircuit +# A server with two dual-socket server nodes one could describe with +# four instances of NXcircuit surplus a field with their level in the hierarchy. +# +# +# +# General type of the processing unit +# +# +# +# +# +# +# +# +# +# +# Given name +# +# +# +# +# +# +# Details about the memory system. +# +# +# +# Granularizing the components of the memory system. +# +# +# +# Qualifier for the type of random access memory. +# +# +# +# +# +# +# +# +# Total amount of data which the medium can hold. +# +# +# +# +# Given name +# +# +# +# +# +# +# Details about the I/O system. +# +# +# +# Granularizing the components of the I/O system. +# +# +# +# Qualifier for the type of storage medium used. +# +# +# +# +# +# +# +# +# +# Total amount of data which the medium can hold. +# +# +# +# +# Given name +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml b/contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml index 807d983593..be8c6af44b 100644 --- a/contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml +++ b/contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml @@ -44,21 +44,24 @@ NXcs_filter_boolean_mask(NXobject): If depends_on is not provided, it is assumed that the mask applies to its direct parent. number_of_objects(NX_UINT): + unit: NX_UNITLESS doc: | Number of objects represented by the mask. - unit: NX_UNITLESS bitdepth(NX_UINT): + unit: NX_UNITLESS doc: | Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - unit: NX_UNITLESS + (e.g. 8 bits for a C-style uint8). mask(NX_UINT): + unit: NX_UNITLESS doc: | - The content of the mask. If padding is used, + The content of the mask. If padding is used, padding bits have to be set to 0. - unit: NX_UNITLESS - dim: (n_total,) + dimensions: + rank: 1 + dim: [[1, n_total]] identifier(NX_INT): + unit: NX_UNITLESS doc: | Link to/or array of identifiers for the objects. The decoded mask is interpreted consecutively, i.e. the first bit in the mask matches @@ -66,5 +69,123 @@ NXcs_filter_boolean_mask(NXobject): identifier and so on and so forth. Resolving of identifier follows the conventions made for depends_on, so consult also the description of th content to which depends_on refers. - unit: NX_UNITLESS - dim: (n_object,) + dimensions: + rank: 1 + dim: [[1, n_object]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 9878df2d54b3dab7cdaaf9c4322c09222d8d267fd5a2eaad6c414070ac6c9ba5 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of entries (e.g. number of points or objects). +# +# +# +# +# Number of bits assumed for the container datatype used. +# +# +# +# +# Length of mask considering the eventual need for padding. +# +# +# +# +# Base class for packing and unpacking booleans. +# +# This base class bookkeeps metadata to inform software about necessary modulo +# operations to decode e.g. set membership of objects in sets which are encoded +# as a packed array of boolean values. +# +# One use case is processing of object sets (e.g. point cloud data). If e.g. a +# spatial filter has been applied to a set of points we may wish to store +# document efficiently which points were analyzed. Array of boolean values +# is one option to achieve this. A value is true if the point is included. +# The resulting boolean array will be filled with true and false values +# in a manner that is often arbitrary and in general case-dependent. +# +# Especially when the number of points is large, for instance several thousands +# or more, some situations can be more efficiently stored if one does not store +# the boolean array but just lists the identifiers of the points taken. +# +# For example, if within a set of 1000 points only one point is included, it would +# take (naively) 4000 bits to store the array but only 32 bits to store e.g. the +# ID of the single point that is taken. Of course the 4000 bit field is so +# sparse that it could be compressed resulting also in a substantial reduction +# of the storage demands. Therefore, boolean masks are useful in that +# they store compact representation of set memberships. +# +# This base class can deal with the situation when the number of objects +# is not an integer multiple of the bit depth used for storing the states. +# +# +# +# Possibility to refer to which set this mask applies. +# +# If depends_on is not provided, it is assumed that the mask +# applies to its direct parent. +# +# +# +# +# Number of objects represented by the mask. +# +# +# +# +# Number of bits assumed matching on a default datatype. +# (e.g. 8 bits for a C-style uint8). +# +# +# +# +# The content of the mask. If padding is used, +# padding bits have to be set to 0. +# +# +# +# +# +# +# +# Link to/or array of identifiers for the objects. The decoded mask is +# interpreted consecutively, i.e. the first bit in the mask matches +# to the first identifier, the second bit in the mask to the second +# identifier and so on and so forth. Resolving of identifier follows +# the conventions made for depends_on, so consult also the description +# of th content to which depends_on refers. +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcs_prng.yaml b/contributed_definitions/nyaml/NXcs_prng.yaml index 114574f691..61a0ec3e6e 100644 --- a/contributed_definitions/nyaml/NXcs_prng.yaml +++ b/contributed_definitions/nyaml/NXcs_prng.yaml @@ -32,16 +32,103 @@ NXcs_prng(NXobject): available or if the PRNG type was set to other the DOI to the publication or the source code should be given. seed(NX_INT): + unit: NX_UNITLESS doc: | Parameter of the PRNG controlling its initialization and thus controlling the specific sequence generated. - unit: NX_UNITLESS warmup(NX_UINT): + unit: NX_UNITLESS doc: | Number of initial draws from the PRNG after its initialized with the seed. These initial draws are typically discarded in an effort to equilibrate the sequence. If no warmup was performed or if warmup procedures are unclear, users should set the value to zero. - unit: NX_UNITLESS + # one could add spectral properties but this is usually well documented in the PRNG literature # one could also think about making reference to the NIST PRNG test suite to qualify the PRNG + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 5e52a2e904117d44260465fae64b41d929b3ab627dd4c2e347ae684ac85fe6d5 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Computer science description of pseudo-random number generator. +# +# The purpose of this base class is to identify if exactly the same sequence +# can be reproduced, like for a PRNG or not (for a true physically random source). +# +# +# +# Physical approach or algorithm whereby random numbers are generated. +# +# Different approaches for generating random numbers with a computer exists. +# Some use a dedicated physical device whose the state is unpredictable +# (physically). Some use a strategy of mangling information from the system +# clock. Also in this case the sequence is not reproducible without having +# additional pieces of information. +# +# In most cases though so-called pseudo-random number generator (PRNG) +# algorithms are used. These yield a deterministic sequence of practically +# randomly appearing numbers. These algorithms differ in their quality in +# how close the resulting sequences are random, i.e. sequentially +# uncorrelated. Nowadays one of the most commonly used algorithm is the +# MersenneTwister (mt19937). +# +# +# +# +# +# +# +# +# +# +# Name of the PRNG implementation and version. If such information is not +# available or if the PRNG type was set to other the DOI to the publication +# or the source code should be given. +# +# +# +# +# Parameter of the PRNG controlling its initialization +# and thus controlling the specific sequence generated. +# +# +# +# +# Number of initial draws from the PRNG after its initialized with the seed. +# These initial draws are typically discarded in an effort to equilibrate the +# sequence. If no warmup was performed or if warmup procedures are unclear, +# users should set the value to zero. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcs_profiling.yaml b/contributed_definitions/nyaml/NXcs_profiling.yaml index cc41151e96..f886a9866d 100644 --- a/contributed_definitions/nyaml/NXcs_profiling.yaml +++ b/contributed_definitions/nyaml/NXcs_profiling.yaml @@ -46,6 +46,7 @@ symbols: The symbols used in the schema to specify e.g. dimensions of arrays. type: group NXcs_profiling(NXobject): + # details about queuing systems etc current_working_directory(NX_CHAR): doc: | @@ -69,6 +70,7 @@ NXcs_profiling(NXobject): may warrant to use a finer temporal discretization, and thus demands a more precise record of the wall-clock time. number_of_processes(NX_UINT): + unit: NX_UNITLESS doc: | Qualifier which specifies with how many nominal processes the app was invoked. The main idea behind this field e.g. for apps which use e.g. MPI @@ -80,17 +82,17 @@ NXcs_profiling(NXobject): can be larger than 1. If no GPU is used number_of_gpus is 0 even though the hardware may have GPUs installed, thus indicating these were not used though. - unit: NX_UNITLESS number_of_threads(NX_UINT): + unit: NX_UNITLESS doc: | Qualifier how many nominal threads were used at runtime. Specifically here the maximum number of threads used for the high-level threading library used (e.g. OMP_NUM_THREADS), posix. - unit: NX_UNITLESS number_of_gpus(NX_UINT): + unit: NX_UNITLESS doc: | Qualifier with how many nominal GPUs the app was invoked at runtime. - unit: NX_UNITLESS + # there are more complicated usage models, where GPUs are activated in # between runs etc, but here application definition and base class developers # should feel free to suggest customizations wrt to if and how such more @@ -104,6 +106,158 @@ NXcs_profiling(NXobject): A collection of individual profiling event data which detail e.g. how much time the app took for certain computational steps and/or how much memory was consumed during these operations. + + # how to retrieve UUID for cloud computing instances + # https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/identify_ec2_instances.html -# how to retrieve UUID for cloud computing instances -# https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/identify_ec2_instances.html +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# ee1c82625ec49958695a1a217834bda811147c5ead01f50dac3f9b0e2f0cc020 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Computer science description for performance and profiling data of an application. +# +# Performance monitoring and benchmarking of software is a task where questions +# can be asked at various levels of detail. In general, there are three main +# contributions to performance: +# +# * Hardware capabilities and configuration +# * Software configuration and capabilities +# * Dynamic effects of the system in operation and the system working together +# with eventually multiple computers, especially when these have to exchange +# information across a network and these are used usually by multiple users. +# +# At the most basic level users may wish to document how long e.g. a data +# analysis with a scientific software (app) took. +# A frequent idea is here to answer practical questions like how critical is the +# effect on the workflow of the scientists, i.e. is the analysis possible in +# a few seconds or would it take days if I were to run this analysis on a +# comparable machine? +# For this more qualitative performance monitoring, mainly the order of +# magnitude is relevant, as well as how this was achieved using parallelization +# (i.e. reporting the number of CPU and GPU resources used, the number of +# processes and threads configured, and providing basic details about the computer). +# +# At more advanced levels benchmarks may go as deep as detailed temporal tracking +# of individual processor instructions, their relation to other instructions, the +# state of call stacks; in short eventually the entire app execution history +# and hardware state history. Such analyses are mainly used for performance +# optimization, i.e. by software and hardware developers as well as for +# tracking bugs. Specialized software exists which documents such performance +# data in specifically-formatted event log files or databases. +# +# This base class cannot and should not replace these specific solutions for now. +# Instead, the intention of the base class is to serve scientists at the +# basic level to enable simple monitoring of performance data and log profiling +# data of key algorithmic steps or parts of computational workflows, so that +# these pieces of information can guide users which order of magnitude differences +# should be expected or not. +# +# Developers of application definitions should add additional fields and +# references to e.g. more detailed performance data to which they wish to link +# the metadata in this base class. +# +# +# +# +# Path to the directory from which the tool was called. +# +# +# +# +# Command line call with arguments if applicable. +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC information +# included when the app was started. +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC information +# included when the app terminated or crashed. +# +# +# +# +# Wall-clock time how long the app execution took. This may be in principle +# end_time minus start_time; however usage of eventually more precise timers +# may warrant to use a finer temporal discretization, +# and thus demands a more precise record of the wall-clock time. +# +# +# +# +# Qualifier which specifies with how many nominal processes the app was +# invoked. The main idea behind this field e.g. for apps which use e.g. MPI +# (Message Passing Interface) parallelization is to communicate +# how many processes were used. +# +# For sequentially running apps number_of_processes and number_of_threads +# is 1. If the app uses exclusively GPU parallelization number_of_gpus +# can be larger than 1. If no GPU is used number_of_gpus is 0 even though +# the hardware may have GPUs installed, thus indicating these were not +# used though. +# +# +# +# +# Qualifier how many nominal threads were used at runtime. +# Specifically here the maximum number of threads used for the +# high-level threading library used (e.g. OMP_NUM_THREADS), posix. +# +# +# +# +# Qualifier with how many nominal GPUs the app was invoked at runtime. +# +# +# +# +# +# A collection with one or more computing nodes each with own resources. +# This can be as simple as a laptop or the nodes of a cluster computer. +# +# +# +# +# A collection of individual profiling event data which detail e.g. how +# much time the app took for certain computational steps and/or how much +# memory was consumed during these operations. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcs_profiling_event.yaml b/contributed_definitions/nyaml/NXcs_profiling_event.yaml index d92fbe68bb..296db17b2b 100644 --- a/contributed_definitions/nyaml/NXcs_profiling_event.yaml +++ b/contributed_definitions/nyaml/NXcs_profiling_event.yaml @@ -20,6 +20,7 @@ NXcs_profiling_event(NXobject): doc: | Free-text description what was monitored/executed during the event. elapsed_time(NX_NUMBER): + unit: NX_TIME doc: | Wall-clock time how long the event took. @@ -29,26 +30,130 @@ NXcs_profiling_event(NXobject): wall-clock time. Elapsed time may contain time portions where resources were idling. - unit: NX_TIME number_of_processes(NX_UINT): + unit: NX_UNITLESS doc: | Number of processes used (max) during the execution of this event. - unit: NX_UNITLESS number_of_threads(NX_UINT): + unit: NX_UNITLESS doc: | Number of threads used (max) during the execution of this event. - unit: NX_UNITLESS number_of_gpus(NX_UINT): + unit: NX_UNITLESS doc: | Number of GPUs used (max) during the execution of this event. - unit: NX_UNITLESS max_virtual_memory_snapshot(NX_NUMBER): + unit: NX_ANY doc: | Maximum amount of virtual memory allocated per process during the event. - unit: NX_ANY # NX_BIT - dim: (n_processes,) + dimensions: + rank: 1 + dim: [[1, n_processes]] max_resident_memory_snapshot(NX_NUMBER): + unit: NX_ANY doc: | Maximum amount of resident memory allocated per process during the event. - unit: NX_ANY # NX_BIT - dim: (n_processes,) + dimensions: + rank: 1 + dim: [[1, n_processes]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 4e5950718a811a7026a8ca5be648741899b280124fba14a8fb2facadd0c1f0c1 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of processes. +# +# +# +# +# Computer science description of a profiling event. +# +# +# +# ISO 8601 time code with local time zone offset to UTC information +# included when the event tracking started. +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC information +# included when the event tracking ended. +# +# +# +# +# Free-text description what was monitored/executed during the event. +# +# +# +# +# Wall-clock time how long the event took. +# +# This may be in principle end_time minus start_time; however usage of +# eventually more precise timers may warrant to use a finer temporal +# discretization, and thus demand for a more precise record of the +# wall-clock time. +# +# Elapsed time may contain time portions where resources were idling. +# +# +# +# +# Number of processes used (max) during the execution of this event. +# +# +# +# +# Number of threads used (max) during the execution of this event. +# +# +# +# +# Number of GPUs used (max) during the execution of this event. +# +# +# +# +# Maximum amount of virtual memory allocated per process during the event. +# +# +# +# +# +# +# +# Maximum amount of resident memory allocated per process during the event. +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcsg.yaml b/contributed_definitions/nyaml/NXcsg.yaml index e7f408c7a2..b3347fce9a 100644 --- a/contributed_definitions/nyaml/NXcsg.yaml +++ b/contributed_definitions/nyaml/NXcsg.yaml @@ -31,13 +31,13 @@ NXcsg(NXobject): is IS_QUADRIC or IS_MESH. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 26b9cbb33ac382f8758dc8bda210c12a550d888e5d33c1a0e662e9671d2788db +# 1ab0c280f8e356fd31f2171e2f7634c7ffdaeac0f8e52dac74f61fb9f9ad8031 # # # +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of points/objects. +# +# +# +# +# Number of mark data per point/object. +# +# +# +# +# Number of atoms in the whitelist. +# +# +# +# +# Number of isotopes in the whitelist. +# +# +# +# +# Base class of the configuration and results of a delocalization algorithm. +# +# Delocalization is used to distribute point-like objects on a grid to obtain +# e.g. smoother count, composition, or concentration values of scalar fields +# and compute gradients of these fields. +# +# +# +# Details about the grid on which the delocalization is applied. +# +# +# +# +# +# +# The weighting model specifies how mark data are mapped to a weight per +# point/object. +# +# +# +# As an example from the research field of atom probe points/objects are (molecular) ions. +# Different methods are used for weighting ions: +# +# * default, points get all the same weight 1., which for atom probe is equivalent +# to (molecular) iontype-based delocalization. +# * element, points get as much weight as they have atoms representing a nuclide +# with a proton number that is matching to a respective entry in whitelist. +# In atom probe jargon, this means atomic_decomposition. +# * isotope, points get as much weight as they have atoms representing a nuclides +# from a respective entry in whitelist. +# In atom probe jargon, this means isotope_decomposition. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# A list of nuclides based on which to evaluate the weight. Nuclides need to exist in the nuclide table. +# Values are nuclide (isotope) hash values using the following hashing rule :math:`H = Z + N \cdot 256` +# with :math:`Z` the number of protons and :math:`N` the number of neutrons of the nuclide. +# For elements set :math:`N` to zero. +# +# +# +# +# +# +# +# Attribute data for each member of the point cloud. For APM these are the +# iontypes generated via ranging. The number of mark data per point is 1 +# in the case for atom probe. +# +# +# +# +# +# +# +# +# Weighting factor with which the integrated intensity per grid cell is +# multiplied specifically for each point/object. For APM the weight are +# positive integer values, specifically the multiplicity of the ion, +# according to the details of the weighting_method. +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXdispersion.yaml b/contributed_definitions/nyaml/NXdispersion.yaml index cd0be114f2..7f5f09a72f 100644 --- a/contributed_definitions/nyaml/NXdispersion.yaml +++ b/contributed_definitions/nyaml/NXdispersion.yaml @@ -12,13 +12,13 @@ NXdispersion(NXobject): (NXdispersion_function): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 5382258a260b96c72eca642ef6d4c506d5a29926787e0cd5f66dafc96f75fef2 +# a559ba67cd0d603d4ceb93c278ad68372d938bd45c4bdb09d7366fe084633565 # # # +# +# +# +# Base class for a set of components providing a controllable electron beam. +# +# +# +# Typically tech-partner, microscope-, and control software-specific +# name of the specific operation mode how the ebeam_column and its +# components are controlled to achieve a specific illumination condition. +# +# In most cases users do not know, have to care, or are able to disentangle the +# details of the spatiotemporal dynamics of the components of the microscope. +# Instead, they rely on the assumption that the microscope and control software +# work as expected. Selecting then a specific operation_mode assures some level +# of reproducibility in the illumination conditions. +# +# +# +# +# +# +# The source which creates the electron beam. +# +# +# +# Given name/alias. +# +# +# +# +# +# Voltage relevant to compute the energy of the electrons +# immediately after they left the gun. +# +# +# +# +# Type of radiation. +# +# +# +# +# +# +# +# Emitter type used to create the beam. +# +# If the emitter type is other, give further details +# in the description field. +# +# +# +# +# +# Material of which the emitter is build, e.g. the filament material. +# +# +# +# +# +# Ideally, a (globally) unique persistent identifier, link, +# or text to a resource which gives further details. +# +# +# +# +# +# Collection of axis-based translations and rotations to describe the +# location and geometry of the component in the instrument. +# +# +# +# +# +# +# +# +# +# +# +# +# Individual characterization results for the position, shape, +# and characteristics of the electron beam. +# +# :ref:`NXtransformations` should be used to specify the location +# of the position at which the beam was probed. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXelectron_level.yaml b/contributed_definitions/nyaml/NXelectron_level.yaml index ed9149e2fd..ab747b0bb0 100644 --- a/contributed_definitions/nyaml/NXelectron_level.yaml +++ b/contributed_definitions/nyaml/NXelectron_level.yaml @@ -8,359 +8,359 @@ NXelectron_level(NXobject): Symbol of the chemical element. For each, the atomic number, common English name, and standard atomic weight are also given. - enumeration: - H: + enumeration: + H: doc: | Z=1, name="hydrogen", standard_atomic_weight=1.0078 - He: + He: doc: | Z=2, name="helium", standard_atomic_weight=4.0026 - Li: + Li: doc: | Z=3, name="lithium", standard_atomic_weight=6.94 - Be: + Be: doc: | Z=4, name="beryllium", standard_atomic_weight=9.0122 - B: + B: doc: | Z=5, name="boron", standard_atomic_weight=10.81 - C: + C: doc: | Z=6, name="carbon", standard_atomic_weight=12.011 - N: + N: doc: | Z=7, name="nitrogen", standard_atomic_weight=14.007 - O: + O: doc: | Z=8, name="oxygen", standard_atomic_weight=15.999 - F: + F: doc: | Z=9, name="fluorine", standard_atomic_weight=18.9984 - Ne: + Ne: doc: | Z=10, name="neon", standard_atomic_weight=20.1797 - Na: + Na: doc: | Z=11, name="sodium", standard_atomic_weight=22.9898 - Mg: + Mg: doc: | Z=12, name="magnesium", standard_atomic_weight=24.305 - Al: + Al: doc: | Z=13, name="aluminum", standard_atomic_weight=26.9815 - Si: + Si: doc: | Z=14, name="silicon", standard_atomic_weight=28.085 - P: + P: doc: | Z=15, name="phosphorus", standard_atomic_weight=30.9738 - S: + S: doc: | Z=16, name="sulfur", standard_atomic_weight=32.06 - Cl: + Cl: doc: | Z=17, name="chlorine", standard_atomic_weight=35.453 - Ar: + Ar: doc: | Z=18, name="argon", standard_atomic_weight=39.948 - K: + K: doc: | Z=19, name="potassium", standard_atomic_weight=39.0983 - Ca: + Ca: doc: | Z=20, name="calcium", standard_atomic_weight=40.078 - Sc: + Sc: doc: | Z=21, name="scandium", standard_atomic_weight=44.9559 - Ti: + Ti: doc: | Z=22, name="titanium", standard_atomic_weight=47.867 - V: + V: doc: | Z=23, name="vanadium", standard_atomic_weight=50.9415 - Cr: + Cr: doc: | Z=24, name="chromium", standard_atomic_weight=51.996 - Mn: + Mn: doc: | Z=25, name="manganese", standard_atomic_weight=54.938 - Fe: + Fe: doc: | Z=26, name="iron", standard_atomic_weight=55.845 - Co: + Co: doc: | Z=27, name="cobalt", standard_atomic_weight=58.9332 - Ni: + Ni: doc: | Z=28, name="nickel", standard_atomic_weight=58.6934 - Cu: + Cu: doc: | Z=29, name="copper", standard_atomic_weight=63.546 - Zn: + Zn: doc: | Z=30, name="zinc", standard_atomic_weight=65.38 - Ga: + Ga: doc: | Z=31, name="gallium", standard_atomic_weight=69.72 - Ge: + Ge: doc: | Z=32, name="germanium", standard_atomic_weight=72.63 - As: + As: doc: | Z=33, name="arsenic", standard_atomic_weight=74.9216 - Se: + Se: doc: | Z=34, name="selenium", standard_atomic_weight=78.971 - Br: + Br: doc: | Z=35, name="bromine", standard_atomic_weight=79.904 - Kr: + Kr: doc: | Z=36, name="krypton", standard_atomic_weight=83.798 - Rb: + Rb: doc: | Z=37, name="rubidium", standard_atomic_weight=85.4678 - Sr: + Sr: doc: | Z=38, name="strontium", standard_atomic_weight=87.62 - Y: + Y: doc: | Z=39, name="yttrium", standard_atomic_weight=88.9058 - Zr: + Zr: doc: | Z=40, name="zirconium", standard_atomic_weight=91.224 - Nb: + Nb: doc: | Z=41, name="niobium", standard_atomic_weight=92.9064 - Mo: + Mo: doc: | Z=42, name="molybdenum", standard_atomic_weight=95.95 - Tc: + Tc: doc: | Z=43, name="technetium", standard_atomic_weight=97.907 - Ru: + Ru: doc: | Z=44, name="ruthenium", standard_atomic_weight=101.07 - Rh: + Rh: doc: | Z=45, name="rhodium", standard_atomic_weight=102.906 - Pd: + Pd: doc: | Z=46, name="palladium", standard_atomic_weight=106.42 - Ag: + Ag: doc: | Z=47, name="silver", standard_atomic_weight=107.868 - Cd: + Cd: doc: | Z=48, name="cadmium", standard_atomic_weight=112.414 - In: + In: doc: | Z=49, name="indium", standard_atomic_weight=114.818 - Sn: + Sn: doc: | Z=50, name="tin", standard_atomic_weight=118.71 - Sb: + Sb: doc: | Z=51, name="antimony", standard_atomic_weight=121.76 - Te: + Te: doc: | Z=52, name="tellurium", standard_atomic_weight=127.6 - I: + I: doc: | Z=53, name="iodine", standard_atomic_weight=126.905 - Xe: + Xe: doc: | Z=54, name="xenon", standard_atomic_weight=131.293 - Cs: + Cs: doc: | Z=55, name="cesium", standard_atomic_weight=132.905 - Ba: + Ba: doc: | Z=56, name="barium", standard_atomic_weight=137.327 - La: + La: doc: | Z=57, name="lanthanum", standard_atomic_weight=138.905 - Ce: + Ce: doc: | Z=58, name="cerium", standard_atomic_weight=140.116 - Pr: + Pr: doc: | Z=59, name="praseodymium", standard_atomic_weight=140.908 - Nd: + Nd: doc: | Z=60, name="neodymium", standard_atomic_weight=144.242 - Pm: + Pm: doc: | Z=61, name="promethium", standard_atomic_weight=145.0 - Sm: + Sm: doc: | Z=62, name="samarium", standard_atomic_weight=150.36 - Eu: + Eu: doc: | Z=63, name="europium", standard_atomic_weight=151.96 - Gd: + Gd: doc: | Z=64, name="gadolinium", standard_atomic_weight=157.25 - Tb: + Tb: doc: | Z=65, name="terbium", standard_atomic_weight=158.925 - Dy: + Dy: doc: | Z=66, name="dysprosium", standard_atomic_weight=162.5 - Ho: + Ho: doc: | Z=67, name="holmium", standard_atomic_weight=164.93 - Er: + Er: doc: | Z=68, name="erbium", standard_atomic_weight=167.259 - Tm: + Tm: doc: | Z=69, name="thulium", standard_atomic_weight=168.934 - Yb: + Yb: doc: | Z=70, name="ytterbium", standard_atomic_weight=173.045 - Lu: + Lu: doc: | Z=71, name="lutetium", standard_atomic_weight=174.967 - Hf: + Hf: doc: | Z=72, name="hafnium", standard_atomic_weight=178.49 - Ta: + Ta: doc: | Z=73, name="tantalum", standard_atomic_weight=180.948 - W: + W: doc: | Z=74, name="tungsten", standard_atomic_weight=183.84 - Re: + Re: doc: | Z=75, name="rhenium", standard_atomic_weight=186.207 - Os: + Os: doc: | Z=76, name="osmium", standard_atomic_weight=190.23 - Ir: + Ir: doc: | Z=77, name="iridium", standard_atomic_weight=192.217 - Pt: + Pt: doc: | Z=78, name="platinum", standard_atomic_weight=195.084 - Au: + Au: doc: | Z=79, name="gold", standard_atomic_weight=196.967 - Hg: + Hg: doc: | Z=80, name="mercury", standard_atomic_weight=200.592 - Tl: + Tl: doc: | Z=81, name="thallium", standard_atomic_weight=204.383 - Pb: + Pb: doc: | Z=82, name="lead", standard_atomic_weight=207.2 - Bi: + Bi: doc: | Z=83, name="bismuth", standard_atomic_weight=208.98 - Po: + Po: doc: | Z=84, name="polonium", standard_atomic_weight=209.0 - At: + At: doc: | Z=85, name="astatine", standard_atomic_weight=210.0 - Rn: + Rn: doc: | Z=86, name="radon", standard_atomic_weight=222.0 - Fr: + Fr: doc: | Z=87, name="francium", standard_atomic_weight=223.0 - Ra: + Ra: doc: | Z=88, name="radium", standard_atomic_weight=226.0 - Ac: + Ac: doc: | Z=89, name="actinium", standard_atomic_weight=227.0 - Th: + Th: doc: | Z=90, name="thorium", standard_atomic_weight=232.038 - Pa: + Pa: doc: | Z=91, name="protactinium", standard_atomic_weight=231.036 - U: + U: doc: | Z=92, name="uranium", standard_atomic_weight=238.029 - Np: + Np: doc: | Z=93, name="neptunium", standard_atomic_weight=237.048 - Pu: + Pu: doc: | Z=94, name="plutonium", standard_atomic_weight=239.052 - Am: + Am: doc: | Z=95, name="americium", standard_atomic_weight=243.0 - Cm: + Cm: doc: | Z=96, name="curium", standard_atomic_weight=247.0 - Bk: + Bk: doc: | Z=97, name="berkelium", standard_atomic_weight=247.0 - Cf: + Cf: doc: | Z=98, name="californium", standard_atomic_weight=251.0 - Es: + Es: doc: | Z=99, name="einsteinium", standard_atomic_weight=252 - Fm: + Fm: doc: | Z=100, name="fermium", standard_atomic_weight=257 - Md: + Md: doc: | Z=101, name="mendelevium", standard_atomic_weight=258 - "No": + No: doc: | Z=102, name="nobelium", standard_atomic_weight=259 - Lr: + Lr: doc: | Z=103, name="lawrencium", standard_atomic_weight=266 - Rf: + Rf: doc: | Z=104, name="rutherfordium", standard_atomic_weight=267 - Db: + Db: doc: | Z=105, name="dubnium", standard_atomic_weight=268 - Sg: + Sg: doc: | Z=106, name="seaborgium", standard_atomic_weight=269 - Bh: + Bh: doc: | Z=107, name="bohrium", standard_atomic_weight=270 - Hs: + Hs: doc: | Z=108, name="hassium", standard_atomic_weight=269 - Mt: + Mt: doc: | Z=109, name="meitnerium", standard_atomic_weight=278 - Ds: + Ds: doc: | Z=110, name="darmstadtium", standard_atomic_weight=281 - Rg: + Rg: doc: | Z=111, name="roentgenium", standard_atomic_weight=282 - Cn: + Cn: doc: | Z=112, name="copernicium", standard_atomic_weight=285 - Nh: + Nh: doc: | Z=113, name="nihonium", standard_atomic_weight=286 - Fl: + Fl: doc: | Z=114, name="flerovium", standard_atomic_weight=289 - Mc: + Mc: doc: | Z=115, name="moscovium", standard_atomic_weight=290 - Lv: + Lv: doc: | Z=116, name="livermorium", standard_atomic_weight=293 - Ts: + Ts: doc: | Z=117, name="tennessine", standard_atomic_weight=294 - Og: + Og: doc: | Z=118, name="oganesson", standard_atomic_weight=294 level_iupac: @@ -370,162 +370,162 @@ NXelectron_level(NXobject): For reference, see Jenkins, R., Manne, R., Robin, R., & Senemaud, C. (1991). IUPAC—nomenclature system for x-ray spectroscopy. X-Ray Spectrometry, 20(3), 149-155. - enumeration: - K: + enumeration: + K: doc: | same as 1s in level_xray - L1: + L1: doc: | 2s - L2: + L2: doc: | 2p_{1/2} - L3: + L3: doc: | 2p_{3/2} - M1: + M1: doc: | 3s - M2: + M2: doc: | 3p_{1/2} - M3: + M3: doc: | 3p_{3/2} - M4: + M4: doc: | 3d_{3/2} - M5: + M5: doc: | 3d_{5/2} - N1: + N1: doc: | 4s - N2: + N2: doc: | 4p_{1/2} - N3: + N3: doc: | 4p_{3/2} - N4: + N4: doc: | 4d_{3/2} - N5: + N5: doc: | 4d_{5/2} - N6: + N6: doc: | 4f_{5/2} - N7: + N7: doc: | 4f_{7/2} - O1: + O1: doc: | 5s - O2: + O2: doc: | 5p_{1/2} - O3: + O3: doc: | 5p_{3/2} - O4: + O4: doc: | 5d_{3/2} - O5: + O5: doc: | 5d_{5/2} - O6: + O6: doc: | 5f_{5/2} - O7: + O7: doc: | 5f_{7/2} - P1: + P1: doc: | 6s - P2: + P2: doc: | 6p_{1/2} - P3: + P3: doc: | 6p_{3/2} level_electron_config: doc: | Electronic orbital configuration of the electronic level. - enumeration: - 1s: + enumeration: + 1s: doc: | same as K in level_xray - 2s: + 2s: doc: | L1 - 2p1/2: + 2p1/2: doc: | L3 - 3s: + 3s: doc: | M1 - 3p1/2: + 3p1/2: doc: | M2 - 3p3/2: + 3p3/2: doc: | M3 - 3d3/2: + 3d3/2: doc: | M4 - 3d5/2: + 3d5/2: doc: | M5 - 4s: + 4s: doc: | N1 - 4p1/2: + 4p1/2: doc: | N2 - 4p3/2: + 4p3/2: doc: | N3 - 4d3/2: + 4d3/2: doc: | N4 - 4d5/2: + 4d5/2: doc: | N5 - 4f5/2: + 4f5/2: doc: | N6 - 4f7/2: + 4f7/2: doc: | N7 - 5s: + 5s: doc: | O1 - 5p1/2: + 5p1/2: doc: | O2 - 5p3/2: + 5p3/2: doc: | O3 - 5d3/2: + 5d3/2: doc: | O4 - 5d5/2: + 5d5/2: doc: | O5 - 5f5/2: + 5f5/2: doc: | O6 - 5f7/2: + 5f7/2: doc: | O7 - 6s: + 6s: doc: | P1 - 6p1/2: + 6p1/2: doc: | P2 - 6p3/2: + 6p3/2: doc: | P3 \@description: @@ -544,14 +544,14 @@ NXelectron_level(NXobject): for a summary of the discussion. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f15a465a52ff8afca9ae40f5a19eaaa00cf0defe098ab7a0b76a3692acd4bc29 -# +# 696e3b5fea519fce5a310d8d2a6316258cb6183e7898a4f87521904143d007e4 +# # # N,C,S Mueller matrix --> Psi, Delta etc. - + Other types of data, such as temperature or sample location, may be saved in a generic (NXdata) concept from NXopt, or better directly in the location of the sample positioner or temperature sensor. @@ -206,7 +205,6 @@ NXellipsometry(NXoptical_spectroscopy): depends on the type of experiment and may differ for different application definitions. enumeration: [intensity, reflectivity, transmittance, Psi/Delta, tan(Psi)/cos(Delta), Mueller matrix, Jones matrix, N/C/S, raw data] - NAME_spectrum(NX_FLOAT): exists: optional unit: NX_ANY @@ -227,7 +225,7 @@ NXellipsometry(NXoptical_spectroscopy): unit: NX_ANY doc: | Resulting data from the measurement, described by 'data_type'. - + The first dimension is defined by the number of measurements taken, (N_measurements). The instructions on how to order the values contained in the parameter vectors given in the doc string of @@ -300,20 +298,15 @@ NXellipsometry(NXoptical_spectroscopy): doc: | Website of the software. - - - - - # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e5c086ad7e50f420614c5465adc29a57a2b25cc1be09659435b3f1592c0f941a -# +# fc2d596065121b9783b8dbfce04ef4f04ffbddb88589d6145b8f30a030f432f5 +# # # -# -# -# -# -# +# +# # # # Variables used throughout the document, e.g. dimensions or parameters. @@ -362,12 +351,6 @@ NXellipsometry(NXoptical_spectroscopy): # data. # # -# -# -# Number of sensors used to measure parameters that influence the sample, -# such as temperature or pressure. -# -# # # # Number of measurements (1st dimension of measured_data array). This is @@ -387,22 +370,16 @@ NXellipsometry(NXoptical_spectroscopy): # Number of angles of incidence of the incident beam. # # -# -# -# Number of observables that are saved in a measurement. e.g. one for -# intensity, reflectivity or transmittance, two for Psi and Delta etc. This -# is equal to the second dimension of the data array 'measured_data' and the -# number of column names. -# -# -# -# -# Number of time points measured, the length of NXsample/time_points -# -# # # -# Ellipsometry, complex systems, up to variable angle spectroscopy. +# This is the application definition describing ellipsometry experiments. +# +# Such experiments may be as simple as identifying how a reflected +# beam of light with a single wavelength changes its polarization state, +# to a variable angle spectroscopic ellipsometry experiment. +# +# The application definition specifies optical spectroscopy (NXopt), by extending +# the terms and setting specific requirements. # # Information on ellipsometry is provided, e.g. in: # @@ -420,38 +397,24 @@ NXellipsometry(NXoptical_spectroscopy): # # Review articles: # -# * T. E. Jenkins, "Multiple-angle-of-incidence ellipsometry", +# * T. E. Jenkins, "Multiple-angle-of-incidence ellipsometry", # J. Phys. D: Appl. Phys. 32, R45 (1999), # https://doi.org/10.1088/0022-3727/32/9/201 -# * D. E. Aspnes, "Spectroscopic ellipsometry - Past, present, and future", +# * D. E. Aspnes, "Spectroscopic ellipsometry - Past, present, and future", # Thin Solid Films 571, 334-344 (2014), # https://doi.org/10.1016/j.tsf.2014.03.056 -# * R. M. A. Azzam, "Mueller-matrix ellipsometry: a review", +# * R. M. A. Azzam, "Mueller-matrix ellipsometry: a review", # Proc. SPIE 3121, Polarization: Measurement, Analysis, and Remote Sensing, # (3 October 1997), # https://doi.org/10.1117/12.283870 -# * E. A. Irene, "Applications of spectroscopic ellipsometry to microelectronics", +# * E. A. Irene, "Applications of spectroscopic ellipsometry to microelectronics", # Thin Solid Films 233, 96-111 (1993), # https://doi.org/10.1016/0040-6090(93)90069-2 -# * S. Zollner et al., "Spectroscopic ellipsometry from 10 to 700 K", +# * S. Zollner et al., "Spectroscopic ellipsometry from 10 to 700 K", # Adv. Opt. Techn., (2022), # https://doi.org/10.1515/aot-2022-0016 # # -# -# This is the application definition describing ellipsometry experiments. -# -# Such experiments may be as simple as identifying how a reflected -# beam of light with a single wavelength changes its polarization state, -# to a variable angle spectroscopic ellipsometry experiment. -# -# The application definition defines: -# -# * elements of the experimental instrument -# * calibration information if available -# * parameters used to tune the state of the sample -# * sample description -# # # # An application definition for ellipsometry. @@ -462,7 +425,7 @@ NXellipsometry(NXoptical_spectroscopy): # definition was used for this entry/data. # # -# +# # # URL where to find further material (documentation, examples) relevant # to the application definition. @@ -472,16 +435,18 @@ NXellipsometry(NXoptical_spectroscopy): # # # -# +# +# # -# An optional free-text description of the experiment. +# Specify the type of the optical experiment. # -# However, details of the experiment should be defined in the specific -# fields of this application definition rather than in this experiment -# description. +# You may specify fundamental characteristics or properties in the experimental sub-type. # +# +# +# # -# +# # # Specify the type of ellipsometry. # @@ -492,35 +457,18 @@ NXellipsometry(NXoptical_spectroscopy): # # # -# +# # # +# +# +# If the ellipsometry_experiment_type is `other`, a name should be specified here. +# +# # # # Properties of the ellipsometry equipment. # -# -# -# Name of the company which build the instrument. -# -# -# -# -# ISO8601 date when the instrument was constructed. -# UTC offset should be specified. -# -# -# -# -# -# Commercial or otherwise defined given name of the program that was -# used to generate the result file(s) with measured data and metadata. -# This program converts the measured signals to ellipsometry data. If -# home written, one can provide the actual steps in the NOTE subfield -# here. -# -# -# # # # What type of ellipsometry was used? See Fujiwara Table 4.2. @@ -538,8 +486,15 @@ NXellipsometry(NXoptical_spectroscopy): # # # +# # # +# +# +# If the ellipsometer_type is `other`, a specific ellipsometry_type" should be +# added here. +# +# # # # Define which element rotates, e.g. polarizer or analyzer. @@ -551,100 +506,106 @@ NXellipsometry(NXoptical_spectroscopy): # # # -# -# +# +# +# If focussing probes (lenses) were used, please state if the data +# were corrected for the window effects. +# +# +# +# +# +# +# +# +# +# +# +# # -# Specify the used light source. Multiple selection possible. +# Were the recorded data corrected by the window effects of the +# focussing probes (lenses)? # -# -# -# -# -# -# -# -# -# -# +# +# # -# If focussing probes (lenses) were used, please state if the data -# were corrected for the window effects. +# Specify the angular spread caused by the focussing probes. # -# -# -# Were the recorded data corrected by the window effects of the -# focussing probes (lenses)? -# -# -# -# -# Specify the angular spread caused by the focussing probes. -# -# -# -# +# +# +# +# +# Properties of the rotating element defined in +# 'instrument/rotating_element_type'. +# +# # -# Properties of the detector used. Integration time is the count time -# field, or the real time field. See their definition. +# Define how many revolutions of the rotating element were averaged +# for each measurement. If the number of revolutions was fixed to a +# certain value use the field 'fixed_revolutions' instead. # -# -# +# +# # -# Properties of the rotating element defined in -# 'instrument/rotating_element_type'. +# Define how many revolutions of the rotating element were taken +# into account for each measurement (if number of revolutions was +# fixed to a certain value, i.e. not averaged). # -# -# -# Define how many revolutions of the rotating element were averaged -# for each measurement. If the number of revolutions was fixed to a -# certain value use the field 'fixed_revolutions' instead. -# -# -# -# -# Define how many revolutions of the rotating element were taken -# into account for each measurement (if number of revolutions was -# fixed to a certain value, i.e. not averaged). -# -# -# -# -# Specify the maximum value of revolutions of the rotating element -# for each measurement. -# -# -# -# +# +# # -# The spectroscope element of the ellipsometer before the detector, -# but often integrated to form one closed unit. Information on the -# dispersive element can be specified in the subfield GRATING. Note -# that different gratings might be used for different wavelength -# ranges. The dispersion of the grating for each wavelength range can -# be stored in grating_dispersion. +# Specify the maximum value of revolutions of the rotating element +# for each measurement. # -# +# # # # -# +# # # Was the backside of the sample roughened? Relevant for infrared # ellipsometry. # # # -# -# +# +# +# +# Measured data, data errors, and varied parameters. This may be used to describe +# indirectly derived data or data transformed between different descriptions, +# such as: +# Raw Data --> Psi +# Delta Psi, Delta --> N,C,S +# Mueller matrix --> N,C,S +# Mueller matrix --> Psi, Delta +# etc. +# +# Other types of data, such as temperature or sample location, may be saved +# in a generic (NXdata) concept from NXopt, or better directly in the +# location of the sample positioner or temperature sensor. +# +# # -# Select which type of data was recorded, for example Psi and Delta -# (see: https://en.wikipedia.org/wiki/Ellipsometry#Data_acquisition). -# It is possible to have multiple selections. Data types may also be -# converted to each other, e.g. a Mueller matrix contains N,C,S data -# as well. This selection defines how many columns (N_observables) are -# stored in the data array. +# An identifier to correlate data to the experimental conditions, +# if several were used in this measurement; typically an index of 0-N. +# +# +# +# +# Select which type of data was recorded, for example intensity, +# reflectivity, transmittance, Psi and Delta etc. +# It is possible to have multiple selections. The enumeration list +# depends on the type of experiment and may differ for different +# application definitions. # # +# +# +# # # # @@ -653,14 +614,111 @@ NXellipsometry(NXoptical_spectroscopy): # # # +# +# +# Spectral values (e.g. wavelength or energy) used for the measurement. +# An array of 1 or more elements. Length defines N_spectrum. Replace +# 'SPECTRUM' by the physical quantity that is used, e.g. wavelength. +# +# +# +# +# +# +# If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. +# If the unit of the measured data is not covered by NXDL units state +# here which unit was used. +# +# +# +# +# +# Resulting data from the measurement, described by 'data_type'. +# +# The first dimension is defined by the number of measurements taken, +# (N_measurements). The instructions on how to order the values +# contained in the parameter vectors given in the doc string of +# INSTRUMENT/sample_stage/environment_conditions/PARAMETER/values, +# define the N_measurements parameter sets. For example, if the +# experiment was performed at three different temperatures +# (T1, T2, T3), two different pressures (p1, p2) and two different +# angles of incidence (a1, a2), the first measurement was taken at the +# parameters {a1,p1,T1}, the second measurement at {a1,p1,T2} etc. +# +# +# +# +# +# +# +# +# If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. +# If the unit of the measured data is not covered by NXDL units state +# here which unit was used. +# +# +# +# +# +# Specified uncertainties (errors) of the data described by 'data_type' +# and provided in 'measured_data'. +# +# +# +# +# +# +# +# +# If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. +# If the unit of the measured data is not covered by NXDL units state +# here which unit was used. +# +# +# +# +# +# List of links to the values of the sensors. Add a link for each +# varied parameter (i.e. for each sensor). +# +# +# +# +# +# +# +# Link to the NeXus file which describes the reference data if a +# reference measurement was performed. Ideally, the reference +# measurement was performed using the same conditions as the actual +# measurement and should be as close in time to the actual measurement +# as possible. +# +# +# +# +# +# Commercial or otherwise defined given name of the program that was +# used to generate the result file(s) with measured data and/or +# metadata (in most cases, this is the same as INSTRUMENT/software). +# If home written, one can provide the actual steps in the NOTE +# subfield here. +# +# +# +# +# Either version with build number, commit hash, or description of a +# (online) repository where the source code of the program and build +# instructions can be found so that the program can be configured in +# such a way that result files can be created ideally in a +# deterministic manner. +# +# +# +# +# Website of the software. +# +# +# # # -# # diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index 1e287c91fc..48f9b03b9c 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -11,6 +11,7 @@ doc: | physical mechanisms and phenomena, or to characterize materials with an electron microscope. type: group NXem(NXobject): + # \@NX_class: # \@file_time(NX_DATE_TIME): # \@file_name(NX_CHAR): @@ -22,12 +23,13 @@ NXem(NXobject): # starting to reorganize the docstrings, as a list of blocks: # -| req: first part, concept definition, human-readable but such that one could take as is to define an concept in OWL # -| opt: second part, comment, i.e. information that in an ideal world would be ideal if represented strongly semantic - # but for practical purposes currently is interpretable only by human to provide them further contextualization + # but for practical purposes currently is interpretable only by human to provide them further contextualization # -| recommended: xref part (ideally also as a list of triple (spec, term, url to uri) - (NXentry): # means ENTRY(NXentry) - exists: [min, 1, max, infty] + (NXentry): + exists: ['min', '1', 'max', 'unbounded'] definition(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR exists: optional enumeration: [NXem] profiling(NXcs_profiling): @@ -35,13 +37,13 @@ NXem(NXobject): doc: | The configuration of the I/O writer software (e.g. `pynxtools `_ or its plugins) which was used to generate this NeXus file instance. - programID(NXprogram): # program1, program2 - doc: - - | + programID(NXprogram): + exists: ['min', '0', 'max', 'unbounded'] + doc: | A collection of all programs and libraries that are considered as relevant to understand with which software tools this NeXus file instance was generated. Ideally, to enable a binary recreation from the input data. - - | + Examples include the name and version of the libraries used to write the instance. Ideally, the software which writes these NXprogram instances also includes the version of the set of NeXus classes i.e. the specific @@ -52,49 +54,45 @@ NXem(NXobject): which is used by the `NOMAD `_ research data management system, it makes sense to store e.g. the GitHub repository commit and respective submodule references used. - exists: [min, 0, max, infty] program(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR experiment_identifier(NXidentifier): exists: recommended - doc: - - | + doc: | Ideally, a (globally) unique persistent identifier for referring to this experiment. An experiment should be understood in that this can be an experiment in reality or a computer simulation because also the latter is an experiment (see the Cambridge Dictionary experiment *a test done in order to find out something, eg if an idea is correct*). - - | + The identifier is usually issued by the facility, laboratory, or the principle investigator. The identifier enables to link experiments/simulations to e.g. proposals. service(NX_CHAR): identifier(NX_CHAR): is_persistent(NX_BOOLEAN): experiment_alias(NX_CHAR): - doc: - - | + doc: | Alias which scientists can easier identify this experiment by. experiment_description(NX_CHAR): exists: optional - doc: - - | + doc: | Free-text description about the experiment. - - | + Users are strongly advised to parameterize the description of their experiment by using respective groups and fields and base classes instead of writing prose into the field. The reason is that such free-text field is difficult to machine-interpret. The motivation behind keeping this field for now is to learn in how far the current base classes need extension based on user feedback. start_time(NX_DATE_TIME): - doc: - - | + doc: | ISO 8601 time code with local time zone offset to UTC information included when the microscope session started. If the application demands that time codes in this section of the application definition should only be used for specifying when the experiment was performed - and the exact duration is not relevant use this start_time field. - - | + Often though it is useful to specify a time interval via setting both a start_time and an end_time because this enables software tools and users to collect a more detailed bookkeeping of the experiment. @@ -109,21 +107,20 @@ NXem(NXobject): in :ref:`NXevent_data_em` instances. end_time(NX_DATE_TIME): exists: recommended - doc: - - | + doc: | ISO 8601 time code with local time zone offset to UTC included when the microscope session ended. - - | + See docstring of the start_time field to see how to use the start_time and end_time together. citeID(NXcite): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] serializedID(NXserialized): - exists: [min, 0, max, infty] - doc: - - | - Possibility to store a collection of serialized resources associated with the experiment. - - | + exists: ['min', '0', 'max', 'unbounded'] + doc: | + Possibility to store a collection of serialized resources associated with the + experiment. + An example how to use this set could be to document from which files, which have been e.g. generated by software of technology partners, the information in an instance of NXem was filled with during parsing or transcoding between different formats. @@ -131,56 +128,51 @@ NXem(NXobject): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): + + # this is one of the few examples where groups may end up without fields because + # for reasons of not breaking GDPR compliance userID(NXuser): - # this is one of the few examples where groups may end up without fields because for reasons of not breaking GDPR compliance - exists: [min, 0, max, infty] - doc: - - | - Information about persons who performed or were involved in the microscope session or simulation run. - - | + exists: ['min', '0', 'max', 'unbounded'] + doc: | + Information about persons who performed or were involved in the microscope + session or simulation run. + This can be the principle investigator who performed this experiment or the student who performed simulations. Adding multiple users if relevant is recommended. name(NX_CHAR): exists: optional - doc: - - | + doc: | Given (first) name and surname. affiliation(NX_CHAR): exists: optional - doc: - - | + doc: | Name of the affiliation at the point in time when the experiment was performed. address(NX_CHAR): exists: optional - doc: - - | + doc: | Postal address of the affiliation. email(NX_CHAR): exists: optional - doc: - - | + doc: | Email address at the point in time when the experiment was performed. - - | + Writing the most permanently used email is recommended. telephone_number(NX_CHAR): exists: optional - doc: - - | + doc: | Telephone number at the point in time when the experiment was performed. role(NX_CHAR): exists: optional - doc: - - | + doc: | User role at the point in time when the experiment was performed. - - | + Examples are technician operating the microscope, student, postdoc, principle investigator, or guest. identifier(NXidentifier): exists: optional - doc: - - | + doc: | Identifier offered by a service to report the user other than by using its name. - - | + Examples could be an ORCID or social media account of the user. service(NX_CHAR): identifier(NX_CHAR): @@ -196,8 +188,7 @@ NXem(NXobject): term: Specimen url: https://purls.helmholtz-metadaten.de/emg/EMG_00000046 type(NX_CHAR): - doc: - - | + doc: | Qualifier whether the sample is a real or a virtual one. enumeration: [experiment, simulation] identifier(NXidentifier): @@ -260,6 +251,7 @@ NXem(NXobject): individual data instances. thickness(NX_NUMBER): exists: optional + unit: NX_LENGTH doc: | (Measured) sample thickness. @@ -271,7 +263,7 @@ NXem(NXobject): In this case the value should be set to the actual thickness of the specimen viewed for an illumination situation where the nominal surface normal of the specimen is parallel to the optical axis. - unit: NX_LENGTH + # \@units: nm # NEW ISSUE: error estimates of the thickness and origin, i.e. how the value was obtained would be useful # NEW ISSUE: error model @@ -286,16 +278,16 @@ NXem(NXobject): # are the ibeam description capabilities not sufficient enough? density(NX_NUMBER): exists: optional + unit: NX_ANY doc: | (Measured) density of the specimen. For multi-layered specimens this field should only be used to describe the density of the excited volume. For scanning electron microscopy - the usage of this field is discouraged and instead an instance of an + the usage of this field is discouraged and instead an instance of an :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` instances can provide a cleaner description of the relevant details why one may wish to store the density of the specimen. - unit: NX_ANY description(NX_CHAR): exists: optional doc: | @@ -303,15 +295,14 @@ NXem(NXobject): parent_identifier and having a working research data management system should provide this contextualization. coordinate_system_set(NXcoordinate_system_set): - exists: [min, 1, max, 1] - doc: - - | + exists: ['min', '1', 'max', '1'] + doc: | Set to hold different coordinate systems conventions. - - | + Inspect the description of the :ref:`NXcoordinate_system_set` and :ref:`NXcoordinate_system` base classes how to define coordinate systems in NeXus. (NXcoordinate_system): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] alias(NX_CHAR): exists: optional type(NX_CHAR): @@ -338,17 +329,20 @@ NXem(NXobject): x_direction(NX_CHAR): exists: recommended doc: | - Direction of the positively pointing x-axis base vector of the processing_reference_frame. + Direction of the positively pointing x-axis base vector of the + processing_reference_frame. enumeration: [undefined, north, east, south, west, in, out] y_direction(NX_CHAR): exists: recommended doc: | - Direction of the positively pointing y-axis base vector of the processing_reference_frame. + Direction of the positively pointing y-axis base vector of the + processing_reference_frame. enumeration: [undefined, north, east, south, west, in, out] z_direction(NX_CHAR): exists: recommended doc: | - Direction of the positively pointing z-axis base vector of the processing_reference_frame. + Direction of the positively pointing z-axis base vector of the + processing_reference_frame. enumeration: [undefined, north, east, south, west, in, out] sample_reference_frame(NXcoordinate_system): exists: recommended @@ -376,20 +370,23 @@ NXem(NXobject): x_direction(NX_CHAR): exists: recommended doc: | - Direction of the positively pointing x-axis base vector of the sample_reference_frame. + Direction of the positively pointing x-axis base vector of the + sample_reference_frame. enumeration: [undefined, north, east, south, west, in, out] y_direction(NX_CHAR): exists: recommended doc: | - Direction of the positively pointing y-axis base vector of the sample_reference_frame. + Direction of the positively pointing y-axis base vector of the + sample_reference_frame. enumeration: [undefined, north, east, south, west, in, out] z_direction(NX_CHAR): exists: recommended doc: | - Direction of the positively pointing z-axis base vector of the sample_reference_frame. + Direction of the positively pointing z-axis base vector of the + sample_reference_frame. enumeration: [undefined, north, east, south, west, in, out] detector_reference_frameID(NXcoordinate_system): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] depends_on(NX_CHAR): exists: optional doc: | @@ -413,20 +410,24 @@ NXem(NXobject): x_direction(NX_CHAR): exists: recommended doc: | - Direction of the positively pointing x-axis base vector of the detector_reference_frame. + Direction of the positively pointing x-axis base vector of the + detector_reference_frame. enumeration: [undefined, north, east, south, west, in, out] y_direction(NX_CHAR): exists: recommended doc: | - Direction of the positively pointing y-axis base vector of the detector_reference_frame. + Direction of the positively pointing y-axis base vector of the + detector_reference_frame. enumeration: [undefined, north, east, south, west, in, out] z_direction(NX_CHAR): exists: recommended doc: | - Direction of the positively pointing z-axis base vector of the detector_reference_frame. + Direction of the positively pointing z-axis base vector of the + detector_reference_frame. enumeration: [undefined, north, east, south, west, in, out] - # the description can be so lean because we do not need to overwrite here s.th. as everything is defined already - # we just say we compose using the base class NXcoordinate_system + + # the description can be so lean because we do not need to overwrite here s.th. as everything is defined already + # we just say we compose using the base class NXcoordinate_system measurement(NXem_msr): exists: optional em_lab(NXinstrument): @@ -441,12 +442,12 @@ NXem(NXobject): identifier(NXidentifier): exists: recommended control_programID(NXprogram): - exists: [min, 1, max, infty] - doc: - - | + exists: ['min', '1', 'max', 'unbounded'] + doc: | Details about the control program used for operating the microscope. program(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR ebeam_column(NXebeam_column): chamber(NXchamber): exists: optional @@ -455,16 +456,15 @@ NXem(NXobject): vendor(NX_CHAR): model(NX_CHAR): identifier(NXidentifier): - exists: recommended + exists: recommended electron_source(NXsource): - doc: - - | - xref: + doc: | xref: spec: EMglossary term: Source url: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 emitter_type(NX_CHAR): probe(NX_CHAR): + # voltage like all other dynamic quantities should better be placed in instances of NXevent_data_em fabrication(NXfabrication): exists: optional @@ -472,13 +472,14 @@ NXem(NXobject): model(NX_CHAR): identifier(NXidentifier): exists: recommended - # fabrication is an example which shows when one needs to specify in the appdef if some of the - # inherited objects from NXebeam_column have to be specified that is when one wishes to document - # e.g. a combination of cardinality constraints or concept symbol constraints - # i.e. use NXfabrication from NXsource but demand it to be labelled with the symbol fabrication - # likewise if you provide fabrication details you need to provide vendor and model but not necessarily identifier + + # fabrication is an example which shows when one needs to specify in the appdef if some of the + # inherited objects from NXebeam_column have to be specified that is when one wishes to document + # e.g. a combination of cardinality constraints or concept symbol constraints + # i.e. use NXfabrication from NXsource but demand it to be labelled with the symbol fabrication + # likewise if you provide fabrication details you need to provide vendor and model but not necessarily identifier lensID(NXlens_em): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] fabrication(NXfabrication): exists: optional vendor(NX_CHAR): @@ -486,7 +487,7 @@ NXem(NXobject): identifier(NXidentifier): exists: recommended apertureID(NXaperture): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] fabrication(NXfabrication): exists: optional vendor(NX_CHAR): @@ -494,18 +495,19 @@ NXem(NXobject): identifier(NXidentifier): exists: recommended monochromatorID(NXmonochromator): - exists: [min, 0, max, infty] - doc: - - | + exists: ['min', '0', 'max', 'unbounded'] + doc: | Device for improving energy resolution or reducing chromatic aberration. - - | - Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector like `_ + + Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector + like `_ + # user perspective type(NX_CHAR): - doc: - - | + doc: | Qualitative type of the component. enumeration: [wien, alfa, omega, castaing_henry, gatan_imaging, sector_analyzer] + # control level perspective # technical design perspective fabrication(NXfabrication): @@ -515,7 +517,7 @@ NXem(NXobject): identifier(NXidentifier): exists: recommended corrector_cs(NXcorrector_cs): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] fabrication(NXfabrication): exists: optional vendor(NX_CHAR): @@ -523,15 +525,13 @@ NXem(NXobject): identifier(NXidentifier): exists: recommended corrector_ax(NXcomponent): - exists: [min, 0, max, 1] - doc: - - | + exists: ['min', '0', 'max', '1'] + doc: | Device reshaping an ellipse-shaped electron beam to a circular one. * `L. Reimer 1998, Springer, 1998 `_ * `M. Tanaka et al., Electron Microscopy Glossary, 2024 `_ - - | Stigmator is an exact synonym. fabrication(NXfabrication): exists: optional @@ -541,8 +541,7 @@ NXem(NXobject): exists: recommended biprism(NXcomponent): exists: optional - doc: - - | + doc: | Electron biprism as it is used e.g. for electron holography. fabrication(NXfabrication): exists: optional @@ -550,23 +549,22 @@ NXem(NXobject): model(NX_CHAR): identifier(NXidentifier): exists: recommended + + # contributed definition NXwaveplate is a closely related concept but may fit even better but waveplate + # has been defined from the perspective of classical optics + # same challenge like with NXlens and NXlens_em, an electrostatic lens is not the same concept + # like it is an glass lens (i.e. optical) NXlens + # but both concepts have in common that they can be assumed to be specialization of a super class + # lenses i.e. devices which can affect the pathes of beams phaseplateID(NXcomponent): - # contributed definition NXwaveplate is a closely related concept but may fit even better but waveplate - # has been defined from the perspective of classical optics - # same challenge like with NXlens and NXlens_em, an electrostatic lens is not the same concept - # like it is an glass lens (i.e. optical) NXlens - # but both concepts have in common that they can be assumed to be specialization of a super class - # lenses i.e. devices which can affect the pathes of beams - exists: [min, 0, max, infty] - doc: - - | + exists: ['min', '0', 'max', 'unbounded'] + doc: | Device that causes a change in the phase of an electron wave. * `M. Malac et al. `_ * `R. R. Schröder et al. `_ type(NX_CHAR): - doc: - - | + doc: | Qualitative type enumeration: [thin_film, electrostatic] fabrication(NXfabrication): @@ -576,11 +574,12 @@ NXem(NXobject): identifier(NXidentifier): exists: recommended sensorID(NXsensor): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] actuatorID(NXactuator): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] ibeam_column(NXibeam_column): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] + # there are tri-beam SEMs but they typically use a laser for which we should have an own base class chamber(NXchamber): exists: optional @@ -593,7 +592,7 @@ NXem(NXobject): ion_source(NXsource): probe(NXion): lensID(NXlens_em): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] fabrication(NXfabrication): exists: optional vendor(NX_CHAR): @@ -601,7 +600,7 @@ NXem(NXobject): identifier(NXidentifier): exists: recommended apertureID(NXaperture): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] fabrication(NXfabrication): exists: optional vendor(NX_CHAR): @@ -609,15 +608,14 @@ NXem(NXobject): identifier(NXidentifier): exists: recommended monochromatorID(NXmonochromator): - exists: [min, 0, max, infty] - doc: - - | + exists: ['min', '0', 'max', 'unbounded'] + doc: | Device for improving energy resolution or reducing chromatic aberration. - - | - Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector like `_ + + Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector + like `_ type(NX_CHAR): - doc: - - | + doc: | Qualitative type of the component. enumeration: [wien, alfa, omega, castaing_henry, gatan_imaging, sector_analyzer] fabrication(NXfabrication): @@ -626,18 +624,20 @@ NXem(NXobject): model(NX_CHAR): identifier(NXidentifier): exists: recommended + # device for correcting axial astigmatism of ion beam? sensorID(NXsensor): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] actuatorID(NXactuator): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] detectorID(NXdetector): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] fabrication(NXfabrication): vendor(NX_CHAR): model(NX_CHAR): - # identifier(NXidentifier): # only relevant when deprecating serial_number - # exists: recommended + + # identifier(NXidentifier): # only relevant when deprecating serial_number + # exists: recommended scan_controller(NXscanbox_em): exists: optional fabrication(NXfabrication): @@ -647,11 +647,11 @@ NXem(NXobject): identifier(NXidentifier): exists: recommended (NXsensor): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] (NXactuator): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] (NXstage_lab): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] fabrication(NXfabrication): exists: optional vendor(NX_CHAR): @@ -659,20 +659,21 @@ NXem(NXobject): identifier(NXidentifier): exists: recommended (NXchamber): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] (NXpump): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] event_data_em_set(NXevent_data_em_set): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] + # an instance must not have an NXevent_data_em_set but if it has one it must not be more than 1 ! (NXevent_data_em): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] start_time(NX_DATE_TIME): exists: recommended end_time(NX_DATE_TIME): exists: recommended (NXimage_set): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] (NXprocess): source(NXserialized): exists: recommended @@ -685,147 +686,207 @@ NXem(NXobject): detector_identifier(NX_CHAR): image_1d(NXdata): exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): + \@signal: + type: NX_CHAR + \@axes: + type: NX_CHAR + \@AXISNAME_indices: + type: NX_INT title(NX_CHAR): real(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR imag(NX_NUMBER): exists: optional - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR magnitude(NX_NUMBER): exists: optional - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR intensity(NX_COMPLEX): exists: optional - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_i(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR image_2d(NXdata): exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): + \@signal: + type: NX_CHAR + \@axes: + type: NX_CHAR + \@AXISNAME_indices: + type: NX_INT title(NX_CHAR): real(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR imag(NX_NUMBER): exists: optional - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR magnitude(NX_NUMBER): exists: optional - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR intensity(NX_COMPLEX): exists: optional - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_j(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_i(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR image_3d(NXdata): exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): + \@signal: + type: NX_CHAR + \@axes: + type: NX_CHAR + \@AXISNAME_indices: + type: NX_INT title(NX_CHAR): real(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR imag(NX_NUMBER): exists: optional - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR magnitude(NX_NUMBER): exists: optional - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR intensity(NX_COMPLEX): exists: optional - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_k(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_j(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_i(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR stack_1d(NXdata): exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): + \@signal: + type: NX_CHAR + \@axes: + type: NX_CHAR + \@AXISNAME_indices: + type: NX_INT title(NX_CHAR): real(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR imag(NX_NUMBER): exists: optional - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR magnitude(NX_NUMBER): exists: optional - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR intensity(NX_NUMBER): exists: optional - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR group_identifier(NX_INT): exists: optional - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR image_identifier(NX_INT): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_i(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR stack_2d(NXdata): exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): + \@signal: + type: NX_CHAR + \@axes: + type: NX_CHAR + \@AXISNAME_indices: + type: NX_INT title(NX_CHAR): real(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR imag(NX_NUMBER): exists: optional - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR magnitude(NX_NUMBER): exists: optional - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR intensity(NX_NUMBER): exists: optional - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR group_identifier(NX_INT): exists: optional - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR image_identifier(NX_INT): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_j(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_i(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR stack_3d(NXdata): exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): + \@signal: + type: NX_CHAR + \@axes: + type: NX_CHAR + \@AXISNAME_indices: + type: NX_INT title(NX_CHAR): real(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR imag(NX_NUMBER): exists: optional - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR magnitude(NX_NUMBER): exists: optional - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR intensity(NX_NUMBER): exists: optional - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR group_identifier(NX_INT): exists: optional - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR image_identifier(NX_INT): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_k(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_j(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_i(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR (NXspectrum_set): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] (NXprocess): source(NXserialized): exists: recommended @@ -838,125 +899,178 @@ NXem(NXobject): detector_identifier(NX_CHAR): spectrum_0d(NXdata): exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): + \@signal: + type: NX_CHAR + \@axes: + type: NX_CHAR + \@AXISNAME_indices: + type: NX_INT title(NX_CHAR): intensity(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_energy(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR spectrum_1d(NXdata): exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): + \@signal: + type: NX_CHAR + \@axes: + type: NX_CHAR + \@AXISNAME_indices: + type: NX_INT title(NX_CHAR): intensity(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_i(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_energy(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR spectrum_2d(NXdata): exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): + \@signal: + type: NX_CHAR + \@axes: + type: NX_CHAR + \@AXISNAME_indices: + type: NX_INT title(NX_CHAR): intensity(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_j(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_i(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_energy(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR spectrum_3d(NXdata): exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): + \@signal: + type: NX_CHAR + \@axes: + type: NX_CHAR + \@AXISNAME_indices: + type: NX_INT title(NX_CHAR): intensity(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_k(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_j(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_i(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_energy(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR stack_0d(NXdata): exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): + \@signal: + type: NX_CHAR + \@axes: + type: NX_CHAR + \@AXISNAME_indices: + type: NX_INT title(NX_CHAR): intensity(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR spectrum_identifier(NX_INT): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_energy(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR stack_1d(NXdata): exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): + \@signal: + type: NX_CHAR + \@axes: + type: NX_CHAR + \@AXISNAME_indices: + type: NX_INT title(NX_CHAR): intensity(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR spectrum_identifier(NX_INT): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_i(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_energy(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR stack_2d(NXdata): exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): + \@signal: + type: NX_CHAR + \@axes: + type: NX_CHAR + \@AXISNAME_indices: + type: NX_INT title(NX_CHAR): intensity(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR spectrum_identifier(NX_INT): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_j(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_i(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_energy(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR stack_3d(NXdata): exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): + \@signal: + type: NX_CHAR + \@axes: + type: NX_CHAR + \@AXISNAME_indices: + type: NX_INT title(NX_CHAR): intensity(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR spectrum_identifier(NX_INT): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_k(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_j(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_i(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_energy(NX_NUMBER): - \@long_name(NX_CHAR): - + \@long_name: + type: NX_CHAR em_lab(NXinstrument): exists: recommended ebeam_column(NXebeam_column): operation_mode(NX_CHAR): electron_source(NXsource): - doc: - - | - xref: + doc: | xref: spec: EMglossary term: Source url: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 @@ -965,23 +1079,25 @@ NXem(NXobject): - | The potential difference between anode and cathode. - | - xref: + xref: spec: EMglossary term: Acceleration Voltage url: https://purls.helmholtz-metadaten.de/emg/EMG_00000004 extraction_voltage(NX_NUMBER): exists: optional + unit: NX_VOLTAGE doc: - | - Voltage which is utilised to create an electric field that draws particles from the source. + Voltage which is utilised to create an electric field that draws particles from + the source. - | xref: spec: EMglossary term: Extraction Voltage url: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 - unit: NX_VOLTAGE emission_current(NX_NUMBER): exists: optional + unit: NX_CURRENT doc: - | Electrical current which is released from the source. @@ -990,9 +1106,9 @@ NXem(NXobject): spec: EMglossary term: Emission Current url: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 - unit: NX_CURRENT filament_current(NX_NUMBER): exists: optional + unit: NX_CURRENT doc: - | Electrical current which flows through the source. @@ -1001,17 +1117,16 @@ NXem(NXobject): spec: EMglossary term: Filament Current url: https://purls.helmholtz-metadaten.de/emg/EMG_00000027 - unit: NX_CURRENT lensID(NXlens_em): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] value(NX_NUMBER): apertureID(NXaperture): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] value(NX_NUMBER): - doc: - - | + unit: NX_ANY + doc: | Relevant value from the control software. - - | + This is not always just the diameter of the aperture (not even in the case) of a circular aperture. Usually, it is a value that is set in the control software whereby a specific configuration of an aperture is selected by the @@ -1023,41 +1138,40 @@ NXem(NXobject): However, if more details are known or should be documented one should use the description field for this. - unit: NX_ANY monochromatorID(NXmonochromator): - exists: [min, 0, max, infty] - doc: - - | + exists: ['min', '0', 'max', 'unbounded'] + doc: | Device to improve energy resolution or chromatic aberration. - - | - Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector like `_ - # user perspective + + Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector + like `_ + + # user perspective applied(NX_BOOLEAN): - doc: - - | - Was the corrector used? + doc: | + Was the corrector used? + # control level perspective # technical components of the corrector dispersion(NX_NUMBER): exists: recommended - doc: - - | - Energy dispersion in e.g. µm/eV. unit: NX_ANY + doc: | + Energy dispersion in e.g. µm/eV. voltage(NX_NUMBER): exists: recommended - doc: - - | - Corresponding voltage for that energy dispersion. unit: NX_VOLTAGE + doc: | + Corresponding voltage for that energy dispersion. corrector_cs(NXcorrector_cs): - exists: [min, 0, max, 1] # but there are systems with several ones https://www.globalsino.com/EM/page4263.html + exists: ['min', '0', 'max', '1'] applied(NX_BOOLEAN): exists: recommended tableauID(NXprocess): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] + # model(NX_CHAR): - # exists: optional + # exists: optional # ceos c_1(NXaberration): exists: optional @@ -1101,6 +1215,7 @@ NXem(NXobject): a_6(NXaberration): exists: optional magnitude(NX_NUMBER): + # nion c_1_0(NXaberration): exists: optional @@ -1177,68 +1292,62 @@ NXem(NXobject): c_5_6_b(NXaberration): exists: optional magnitude(NX_NUMBER): - # we could write down how to store the aberrations but we should not force to add aberrations - # basically optional use of NXaberration therein at least some value required + + # we could write down how to store the aberrations but we should not force to add aberrations + # basically optional use of NXaberration therein at least some value required corrector_ax(NXcomponent): - exists: [min, 0, max, 1] - doc: - - | + exists: ['min', '0', 'max', '1'] + doc: | Device reshaping an ellipse-shaped electron beam to a circular one. * `L. Reimer 1998, Springer, 1998 `_ * `M. Tanaka et al., Electron Microscopy Glossary, 2024 `_ - - | Stigmator is an exact synonym. applied(NX_BOOLEAN): - doc: - - | - Was the corrector used? + doc: | + Was the corrector used? value_x(NX_NUMBER): - doc: - - | + unit: NX_ANY + doc: | Descriptor for the correction strength along the first direction when exact technical details are unknown or not directly controllable as the control software of the microscope does not enable or was not configured to display these values (for end users). - unit: NX_ANY value_y(NX_NUMBER): - doc: - - | + unit: NX_ANY + doc: | Descriptor for the correction strength along the second direction when exact technical details are unknown or not directly controllable as the control software of the microscope does not enable or was not configured to display these values (for end users). - unit: NX_ANY biprism(NXcomponent): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] phaseplateID(NXcomponent): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] sensorID(NXsensor): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] actuatorID(NXactuator): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] (NXbeam): - exists: [min, 0, max, infty] - doc: - - | - xref: + exists: ['min', '0', 'max', 'unbounded'] + doc: | xref: spec: EMglossary term: Electron Beam url: https://purls.helmholtz-metadaten.de/emg/EMG_00000021 ibeam_column(NXibeam_column): - exists: [min, 0, max, 1] + exists: ['min', '0', 'max', '1'] ion_source(NXsource): probe(NXion): voltage(NX_NUMBER): lensID(NXlens_em): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] value(NX_NUMBER): apertureID(NXaperture): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] value(NX_NUMBER): - doc: - - | + unit: NX_ANY + doc: | Relevant value from the control software. - - | + This is not always just the diameter of the aperture (not even in the case) of a circular aperture. Usually, it is a value that is set in the control software whereby a specific configuration of an aperture is selected by the @@ -1250,63 +1359,58 @@ NXem(NXobject): However, if more details are known or should be documented one should use the description field for this. - unit: NX_ANY monochromatorID(NXmonochromator): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] applied(NX_BOOLEAN): sensorID(NXsensor): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] actuatorID(NXactuator): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] (NXbeam): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] detectorID(NXdetector): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] mode(NX_CHAR): scan_controller(NXscanbox_em): exists: optional scan_schema(NX_CHAR): dwell_time(NX_NUMBER): - (NXsensor): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] (NXactuator): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] heater(NXactuator): exists: optional current(NX_NUMBER): - doc: - - | - Nominal current of the heater. unit: NX_CURRENT + doc: | + Nominal current of the heater. voltage(NX_NUMBER): - doc: - - | - Nominal voltage of the heater. unit: NX_VOLTAGE + doc: | + Nominal voltage of the heater. power(NX_NUMBER): - doc: - - | - Nominal power of the heater. unit: NX_POWER + doc: | + Nominal power of the heater. (NXstage_lab): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] design(NX_CHAR): exists: recommended (NXchamber): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] (NXpump): - exists: [min, 0, max, infty] - + exists: ['min', '0', 'max', 'unbounded'] simulation(NXem_sim): exists: optional - # remains to be discussed based on examples - + + # remains to be discussed based on examples + # relevant research result post-processed for specific community methods # but normalized in its representation ready to be consumed for a # research data management system roiID(NXroi): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] doc: - | A region-of-interest analyzed either during or after the session @@ -1316,6 +1420,7 @@ NXem(NXobject): spec: EMglossary term: Region Of Interest url: https://purls.helmholtz-metadaten.de/emg/EMG_00000042 + # as soon as one entry is here constrained further # an RDM can be sure to find specific pieces of information in a # specific way but then every user of this application definition @@ -1324,13 +1429,14 @@ NXem(NXobject): exists: optional imaging_mode(NX_CHAR): (NXimage_set): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] half_angle_interval(NX_NUMBER): exists: optional microstructureID(NXmicrostructure): exists: optional ebsd(NXem_ebsd): exists: optional + # remains to be discussed based on examples gnomonic_reference_frame(NXcoordinate_system): exists: optional @@ -1376,7 +1482,7 @@ NXem(NXobject): checksum(NX_CHAR): algorithm(NX_CHAR): phaseID(NXcrystal_structure): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] number_of_scan_points(NX_UINT): a_b_c(NX_NUMBER): alpha_beta_gamma(NX_NUMBER): @@ -1387,82 +1493,1786 @@ NXem(NXobject): exists: recommended projection_direction(NX_NUMBER): map(NXdata): - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): + \@signal: + type: NX_CHAR + \@axes: + type: NX_CHAR + \@AXISNAME_indices: + type: NX_INT title(NX_CHAR): data(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_x(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_y(NX_NUMBER): exists: optional - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_z(NX_NUMBER): exists: optional - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR legend(NXdata): - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): + \@signal: + type: NX_CHAR + \@axes: + type: NX_CHAR + \@AXISNAME_indices: + type: NX_INT title(NX_CHAR): data(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_x(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_y(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR roi(NXdata): exists: recommended - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_CHAR): + \@signal: + type: NX_CHAR + \@axes: + type: NX_CHAR + \@AXISNAME_indices: + type: NX_CHAR title(NX_CHAR): descriptor(NX_CHAR): data(NX_NUMBER): axis_y(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR axis_x(NX_NUMBER): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR eds(NXem_eds): exists: optional + # remains to be discussed based on examples indexing(NXprocess): summary(NXdata): exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_CHAR): + \@signal: + type: NX_CHAR + \@axes: + type: NX_CHAR + \@AXISNAME_indices: + type: NX_CHAR title(NX_CHAR): intensity(NX_NUMBER): axis_energy(NX_CHAR): - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR atom_types(NX_CHAR): (NXimage_set): - exists: [min, 0, max, 118] # given that image_set instances should be named with the chemical_symbol of the elements + exists: ['min', '0', 'max', '118'] iupac_line_candidates(NX_CHAR): exists: recommended energy_range(NX_NUMBER): image_2d(NXdata): - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_CHAR): + \@signal: + type: NX_CHAR + \@axes: + type: NX_CHAR + \@AXISNAME_indices: + type: NX_CHAR title(NX_CHAR): exists: optional intensity(NX_NUMBER): - \@units(NX_CHAR): + \@units: + type: NX_CHAR exists: recommended - axis_i(NX_NUMBER): # x - \@long_name(NX_CHAR): - \@units(NX_CHAR): - axis_j(NX_NUMBER): # y - \@long_name(NX_CHAR): - \@units(NX_CHAR): # exemplar test to enforce that units are added + axis_i(NX_NUMBER): + \@long_name: + type: NX_CHAR + \@units: + type: NX_CHAR + axis_j(NX_NUMBER): + \@long_name: + type: NX_CHAR + \@units: + type: NX_CHAR eels(NXem_eels): exists: optional correlation(NXem_correlation): exists: optional - # remains to be discussed based on examples + + # remains to be discussed based on examples + + # see an example how to map e.g. the following flat schema https://www.zenodo.org/record/6513745 to NXem + # in https://github.com/FAIRmat-NFDI/nexus_definitions/commit/0b928c4352bc5636f673b5fb25ce990f1af8a099 -# see an example how to map e.g. the following flat schema https://www.zenodo.org/record/6513745 to NXem -# in https://github.com/FAIRmat-NFDI/nexus_definitions/commit/0b928c4352bc5636f673b5fb25ce990f1af8a099 +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# bfde165f66165201c4056b9ded67a002d464a264001ca767a16cd89474da9b53 +# +# +# +# +# +# Application definition for normalized representation of electron microscopy research. +# +# This application definition is a comprehensive example for a general description +# with which to normalize specific pieces of information and data collected within +# electron microscopy research. +# +# NXem is designed to be used for documenting experiments or computer simulations in which +# controlled electron beams are used for studying electron-beam matter interaction to explore +# physical mechanisms and phenomena, or to characterize materials with an electron microscope. +# +# +# +# +# +# +# +# +# +# +# +# The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_ or its plugins) +# which was used to generate this NeXus file instance. +# +# +# +# A collection of all programs and libraries that are considered as relevant +# to understand with which software tools this NeXus file instance was +# generated. Ideally, to enable a binary recreation from the input data. +# +# Examples include the name and version of the libraries used to write the +# instance. Ideally, the software which writes these NXprogram instances +# also includes the version of the set of NeXus classes i.e. the specific +# set of base classes, application definitions, and contributed definitions +# with which the here described concepts can be resolved. +# +# For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ +# which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ +# research data management system, it makes sense to store e.g. the GitHub +# repository commit and respective submodule references used. +# +# +# +# +# +# +# +# +# Ideally, a (globally) unique persistent identifier for referring to this experiment. +# +# An experiment should be understood in that this can be an experiment +# in reality or a computer simulation because also the latter is an experiment +# (see the Cambridge Dictionary experiment *a test done in order to find out +# something, eg if an idea is correct*). +# +# The identifier is usually issued by the facility, laboratory, or the principle investigator. +# The identifier enables to link experiments/simulations to e.g. proposals. +# +# +# +# +# +# +# +# Alias which scientists can easier identify this experiment by. +# +# +# +# +# Free-text description about the experiment. +# +# Users are strongly advised to parameterize the description of their experiment +# by using respective groups and fields and base classes instead of writing prose +# into the field. The reason is that such free-text field is difficult to machine-interpret. +# The motivation behind keeping this field for now is to learn in how far the +# current base classes need extension based on user feedback. +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC information included +# when the microscope session started. If the application demands that time +# codes in this section of the application definition should only be used +# for specifying when the experiment was performed - and the exact +# duration is not relevant use this start_time field. +# +# Often though it is useful to specify a time interval via setting both a start_time +# and an end_time because this enables software tools and users to collect a +# more detailed bookkeeping of the experiment. +# +# Users should be aware though that even with having both time instances +# specified, it may not be possible to infer how long the experiment took or +# for how long data were acquired. +# +# More detailed timing data over the course of the experiment have +# to be collected to compute this. These computations can take +# advantage of individual time stamps start_time and end_time +# in :ref:`NXevent_data_em` instances. +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC included when +# the microscope session ended. +# +# See docstring of the start_time field to see how to use the +# start_time and end_time together. +# +# +# +# +# +# Possibility to store a collection of serialized resources associated with the +# experiment. +# +# An example how to use this set could be to document from which files, which have been +# e.g. generated by software of technology partners, the information in an instance of +# NXem was filled with during parsing or transcoding between different formats. +# +# +# +# +# +# +# +# +# +# Information about persons who performed or were involved in the microscope +# session or simulation run. +# +# This can be the principle investigator who performed this experiment or the student who performed simulations. +# Adding multiple users if relevant is recommended. +# +# +# +# Given (first) name and surname. +# +# +# +# +# Name of the affiliation at the point in time when the experiment was performed. +# +# +# +# +# Postal address of the affiliation. +# +# +# +# +# Email address at the point in time when the experiment was performed. +# +# Writing the most permanently used email is recommended. +# +# +# +# +# Telephone number at the point in time when the experiment was performed. +# +# +# +# +# User role at the point in time when the experiment was performed. +# +# Examples are technician operating the microscope, student, postdoc, +# principle investigator, or guest. +# +# +# +# +# Identifier offered by a service to report the user other than by using its name. +# +# Examples could be an ORCID or social media account of the user. +# +# +# +# +# +# +# +# +# A physical entity which contains material intended to be investigated. +# Sample and specimen are treated as de facto synonyms. Samples can be real or virtual ones. +# +# This concept is related to term `Specimen`_ of the EMglossary standard. +# +# .. _Specimen: https://purls.helmholtz-metadaten.de/emg/EMG_00000046 +# +# +# +# Qualifier whether the sample is a real or a virtual one. +# +# +# +# +# +# +# +# +# Ideally, (globally) unique persistent identifier which distinguishes the sample from all others +# and especially the predecessor/origin from where that sample was cut. The terms sample +# and specimen are here considered as exact synonyms. +# +# This field must not be used for an alias! Instead, use name. +# +# In cases where multiple specimens were loaded into the microscope, the identifier has to resolve +# the specific sample, whose results are stored by this :ref:`NXentry` instance because a single +# NXentry should be used for the characterization of a single specimen. +# +# Details about the specimen preparation should be stored in resources referring to parent_identifier. +# +# +# +# +# +# +# +# Identifier of the sample from which the sample was cut or the string *None*. +# +# The purpose of this field is to support functionalities for tracking +# sample provenance in a research data management system. +# +# +# +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC information +# when the specimen was prepared. +# +# Ideally, report the end of the preparation, i.e. the last known timestamp when +# the measured specimen surface was actively prepared. Ideally, this matches +# the last timestamp that is mentioned in the digital resource pointed to by +# parent_identifier. +# +# Knowing when the specimen was exposed to e.g. specific atmosphere is especially +# required for environmentally sensitive material such as specimen charged with hydrogen +# or experiments including tracers that have a short halflife. Additional time stamps +# prior to preparation_date should better be placed in resources which describe but +# which do not pollute the description here with prose. Resolving these connected +# pieces of information is considered the responsibility of the +# research data management system not of a NeXus file. +# +# +# +# +# An alias used to refer to the specimen to please readability for humans. +# +# +# +# +# List of comma-separated elements from the periodic table that are contained in the sample. +# If the sample substance has multiple components, all elements from each component +# must be included in atom_types. +# +# The purpose of the field is to offer research data management systems an opportunity +# to parse the relevant elements without having to interpret these from the resources +# pointed to by parent_identifier or walk through eventually deeply nested groups in +# individual data instances. +# +# +# +# +# (Measured) sample thickness. +# +# The information is recorded to qualify if the beam used was likely +# able to shine through the specimen. For scanning electron microscopy, +# in many cases the specimen is typically thicker than what is +# illuminatable by the electron beam. +# +# In this case the value should be set to the actual thickness of +# the specimen viewed for an illumination situation where the nominal +# surface normal of the specimen is parallel to the optical axis. +# +# +# +# +# +# (Measured) density of the specimen. +# +# For multi-layered specimens this field should only be used to describe +# the density of the excited volume. For scanning electron microscopy +# the usage of this field is discouraged and instead an instance of an +# :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` +# instances can provide a cleaner description of the relevant details +# why one may wish to store the density of the specimen. +# +# +# +# +# Discouraged free-text field to provide further detail although adding +# parent_identifier and having a working research data management system +# should provide this contextualization. +# +# +# +# +# +# Set to hold different coordinate systems conventions. +# +# Inspect the description of the :ref:`NXcoordinate_system_set` and :ref:`NXcoordinate_system` base classes +# how to define coordinate systems in NeXus. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Location of the origin of the processing_reference_frame. +# +# It is assumed that regions-of-interest in this reference frame form a rectangle or cuboid. +# Edges are interpreted by inspecting the direction of their outer unit normals +# (which point either parallel or antiparallel) along respective base vector direction +# of the reference frame. +# +# If any of these assumptions is not met, the user is required to explicitly state this. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing x-axis base vector of the +# processing_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing y-axis base vector of the +# processing_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing z-axis base vector of the +# processing_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Reference to the specifically named :ref:`NXsample` instance(s) for +# which these conventions apply (e.g. /entry1/sample1). +# +# +# +# +# +# +# +# Location of the origin of the sample_reference_frame. +# +# It is assumed that regions-of-interest in this reference frame form a rectangle or cuboid. +# Edges are interpreted by inspecting the direction of their outer unit normals +# (which point either parallel or antiparallel) along respective base vector direction +# of the reference frame. +# +# If any of these assumptions is not met, the user is required to explicitly state this. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing x-axis base vector of the +# sample_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing y-axis base vector of the +# sample_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing z-axis base vector of the +# sample_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Reference to the specifically named :ref:`NXdetector` instance for +# which these conventions apply (e.g. /entry1/instrument/detector1). +# +# +# +# +# +# +# +# Location of the origin of the detector_reference_frame. +# +# If the regions-of-interest forms a rectangle or cuboid, it is assumed that edges are interpreted +# by inspecting the direction of their outer unit normals (which point either parallel or antiparallel) +# along respective base vector direction of the reference frame. +# +# If any of these assumptions is not met, the user is required to explicitly state this. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing x-axis base vector of the +# detector_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing y-axis base vector of the +# detector_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing z-axis base vector of the +# detector_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Details about the control program used for operating the microscope. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# This concept is related to term `Source`_ of the EMglossary standard. +# +# .. _Source: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Device for improving energy resolution or reducing chromatic aberration. +# +# Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector +# like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ +# +# +# +# +# Qualitative type of the component. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Device reshaping an ellipse-shaped electron beam to a circular one. +# +# * `L. Reimer 1998, Springer, 1998 <https://dx.doi.org/10.1007/978-3-540-3896>`_ +# * `M. Tanaka et al., Electron Microscopy Glossary, 2024 <https://www.jeol.com/words/semterms/20201020.111014.php#gsc.tab=0>`_ +# +# Stigmator is an exact synonym. +# +# +# +# +# +# +# +# +# +# Electron biprism as it is used e.g. for electron holography. +# +# +# +# +# +# +# +# +# +# +# Device that causes a change in the phase of an electron wave. +# +# * `M. Malac et al. <https://doi.org/10.1093/jmicro/dfaa070>`_ +# * `R. R. Schröder et al. <https://www.lem.kit.edu/152.php>`_ +# +# +# +# Qualitative type +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Device for improving energy resolution or reducing chromatic aberration. +# +# Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector +# like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ +# +# +# +# Qualitative type of the component. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# This concept is related to term `Source`_ of the EMglossary standard. +# +# .. _Source: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 +# +# +# +# The potential difference between anode and cathode. +# +# This concept is related to term `Acceleration Voltage`_ of the EMglossary standard. +# +# .. _Acceleration Voltage: https://purls.helmholtz-metadaten.de/emg/EMG_00000004 +# +# +# +# +# Voltage which is utilised to create an electric field that draws particles from +# the source. +# +# This concept is related to term `Extraction Voltage`_ of the EMglossary standard. +# +# .. _Extraction Voltage: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 +# +# +# +# +# Electrical current which is released from the source. +# +# This concept is related to term `Emission Current`_ of the EMglossary standard. +# +# .. _Emission Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 +# +# +# +# +# Electrical current which flows through the source. +# +# This concept is related to term `Filament Current`_ of the EMglossary standard. +# +# .. _Filament Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000027 +# +# +# +# +# +# +# +# +# +# Relevant value from the control software. +# +# This is not always just the diameter of the aperture (not even in the case) +# of a circular aperture. Usually, it is a value that is set in the control +# software whereby a specific configuration of an aperture is selected by the +# software. +# +# The control software of commercial microscope typically offers the user +# access at a high abstraction level because of which many details about +# the actual settings of the electrical components are typically unknown. +# +# However, if more details are known or should be documented one should +# use the description field for this. +# +# +# +# +# +# Device to improve energy resolution or chromatic aberration. +# +# Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector +# like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ +# +# +# +# +# Was the corrector used? +# +# +# +# +# +# Energy dispersion in e.g. µm/eV. +# +# +# +# +# Corresponding voltage for that energy dispersion. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Device reshaping an ellipse-shaped electron beam to a circular one. +# +# * `L. Reimer 1998, Springer, 1998 <https://dx.doi.org/10.1007/978-3-540-3896>`_ +# * `M. Tanaka et al., Electron Microscopy Glossary, 2024 <https://www.jeol.com/words/semterms/20201020.111014.php#gsc.tab=0>`_ +# +# Stigmator is an exact synonym. +# +# +# +# Was the corrector used? +# +# +# +# +# Descriptor for the correction strength along the first direction when exact technical details +# are unknown or not directly controllable as the control software of the microscope does not +# enable or was not configured to display these values (for end users). +# +# +# +# +# Descriptor for the correction strength along the second direction when exact technical details +# are unknown or not directly controllable as the control software of the microscope does not +# enable or was not configured to display these values (for end users). +# +# +# +# +# +# +# +# +# +# This concept is related to term `Electron Beam`_ of the EMglossary standard. +# +# .. _Electron Beam: https://purls.helmholtz-metadaten.de/emg/EMG_00000021 +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Relevant value from the control software. +# +# This is not always just the diameter of the aperture (not even in the case) +# of a circular aperture. Usually, it is a value that is set in the control +# software whereby a specific configuration of an aperture is selected by the +# software. +# +# The control software of commercial microscope typically offers the user +# access at a high abstraction level because of which many details about +# the actual settings of the electrical components are typically unknown. +# +# However, if more details are known or should be documented one should +# use the description field for this. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Nominal current of the heater. +# +# +# +# +# Nominal voltage of the heater. +# +# +# +# +# Nominal power of the heater. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# A region-of-interest analyzed either during or after the session +# for which specific processed data are available. +# +# This concept is related to term `Region Of Interest`_ of the EMglossary standard. +# +# .. _Region Of Interest: https://purls.helmholtz-metadaten.de/emg/EMG_00000042 +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXem_calorimetry.yaml b/contributed_definitions/nyaml/NXem_calorimetry.yaml index b4f3deff57..8c277cb751 100644 --- a/contributed_definitions/nyaml/NXem_calorimetry.yaml +++ b/contributed_definitions/nyaml/NXem_calorimetry.yaml @@ -10,58 +10,64 @@ doc: | symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. + + # intentionally axes are not named x, y, z to + # i) assure indices can be used for real and complex, + # ii) that people think hard about how their base vectors are aligned with what and how to name things n_p: | - Number of diffraction pattern. + Number of pattern n_f: | - Number of radial integration bins. + Number of azimuthal integration bins n_i: | Number of coordinates along i axis. n_j: | Number of coordinates along j axis. -# intentionally axes are not named x, y, z to -# i) assure indices can be used for real and complex, -# ii) that people think hard about how their base vectors are aligned with what and how to name things - n_p: | - Number of pattern - n_f: | - Number of azimuthal integration bins -type: group + # for a proper instance of a NeXus file also root level attributes should be set # NeXus version, h5py version, again can be done later, we have tons of examples +type: group NXem_calorimetry(NXobject): + # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently (NXentry): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] definition(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR exists: optional enumeration: [NXem_calorimetry] + # take here inspiration from the dozens of example appdefs # e.g. NXem, NXapm_paraprobe_* which shows how to add context identifier(NXidentifier): exists: optional - # a place whereby you can refer to your simulation run, etc + + # a place whereby you can refer to your simulation run, etc (NXuser): exists: optional - # a place where you can give details about people who did it + + # a place where you can give details about people who did it (NXsample): exists: optional - # a place where you can tell e.g. based on which sample you build this simulation + + # a place where you can tell e.g. based on which sample you build this simulation (NXcite): - exists: [min, 0, max, infty] - # a place where to add citations for your work ... + exists: ['min', '0', 'max', 'unbounded'] + + # a place where to add citations for your work ... (NXcoordinate_system_set): diffraction_space(NXcoordinate_system): (NXcoordinate_system): - exists: [min, 0, max, infty] - # a place where you can describe your coordinate system conventions + exists: ['min', '0', 'max', 'unbounded'] + + # a place where you can describe your coordinate system conventions # hook-in NXem, alternatively inherit from NXem and just add # add an actuator(NXactuator): - # doc: | - # DENSsolution heating chip. - # physical_quantity(NX_CHAR): - # # enumeration: [temperature] - # event_data for the actual sensor data + # doc: | + # DENSsolution heating chip. + # physical_quantity(NX_CHAR): + # enumeration: [temperature] + # event_data for the actual sensor data # alternatively diffraction(NXsource): doc: | @@ -86,43 +92,60 @@ NXem_calorimetry(NXobject): (heating chip) were synchronized. sequence_index(NX_POSINT): pattern_identifier(NX_UINT): - dim: (n_p,) unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_p]] start_time(NX_DATE_TIME): doc: | Timestamp when pattern acquisition started. - dim: (n_p,) + dimensions: + rank: 1 + dim: [[1, n_p]] end_time(NX_DATE_TIME): doc: | Timestamp when pattern acquisition ended. - dim: (n_p,) - # alternatively only timestamp + dimensions: + rank: 1 + dim: [[1, n_p]] + + # alternatively only timestamp pattern_center(NXprocess): sequence_index(NX_POSINT): config(NXcollection): result(NXcg_point_set): + # depends_on(NX_CHAR): - # doc: | - # Hint to help resolve in which coordinate system position values are defined. + # doc: | + # Hint to help resolve in which coordinate system position values are defined. position(NX_NUMBER): unit: NX_LENGTH - dim: (n_p, 2) - #\@units: 1/nm + dimensions: + rank: 2 + dim: [[1, n_p], [2, 2]] + + # \@units: 1/nm distortion_correction(NXprocess): exists: optional sequence_index(NX_POSINT): programID(NXprogram): exists: optional program(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR config(NXcollection): result(NXcg_ellipsoid_set): + # depends_on(NX_CHAR): center(NX_NUMBER): unit: NX_LENGTH - dim: (n_p, 2) - #\@units: 1/nm + dimensions: + rank: 2 + dim: [[1, n_p], [2, 2]] + + # \@units: 1/nm azimuthal_integration(NXprocess): + # no exists, i.e. assuming required doc: | Acquired diffraction pattern azimuthally integrated as a function of time. @@ -130,76 +153,115 @@ NXem_calorimetry(NXobject): programID(NXprogram): exists: optional program(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR config(NXcollection): - # TODO integration parameter + + # TODO integration parameter result(NXdata): - \@signal(NX_CHAR): - \@axes(NX_CHAR): # [axis_s] - \@AXISNAME_indices(NX_CHAR): + \@signal: + type: NX_CHAR + \@axes: + type: NX_CHAR + \@AXISNAME_indices: + type: NX_CHAR title(NX_CHAR): intensity(NX_FLOAT): - dim: (n_p, n_f) unit: NX_UNITLESS - \@long_name(NX_CHAR): + dimensions: + rank: 2 + dim: [[1, n_p], [2, n_f]] + \@long_name: + type: NX_CHAR axis_pattern_identifier(NX_UINT): - dim: (n_p,) unit: NX_UNITLESS - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_p]] + \@long_name: + type: NX_CHAR axis_s(NX_FLOAT): - dim: (n_f,) unit: NX_ANY - #\@units: 1/nm - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_f]] + + # \@units: 1/nm + \@long_name: + type: NX_CHAR axis_time(NX_FLOAT): + unit: NX_TIME doc: | Time since start of the in-situ experiment - dim: (n_p,) - unit: NX_TIME - # \@units: s + dimensions: + rank: 1 + dim: [[1, n_p]] + + # \@units: s background_subtraction(NXprocess): exists: recommended sequence_index(NX_POSINT): programID(NXprogram): program(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR config(NXcollection): - # TODO integration parameter + + # TODO integration parameter background(NXcollection): - # TODO e.g. could add parameter of functional forms for the background of each pattern + + # TODO e.g. could add parameter of functional forms for the background of each pattern result(NXdata): doc: | - Azimuthally integrated diffraction intensities corrected for background as a function of time. - \@signal(NX_CHAR): - \@axes(NX_CHAR): # [axis_time, axis_s] - \@AXISNAME_indices(NX_CHAR): + Azimuthally integrated diffraction intensities corrected for background as a + function of time. + \@signal: + type: NX_CHAR + \@axes: + type: NX_CHAR + \@AXISNAME_indices: + type: NX_CHAR title(NX_CHAR): intensity(NX_FLOAT): - dim: (n_p, n_f) unit: NX_UNITLESS - \@long_name(NX_CHAR): + dimensions: + rank: 2 + dim: [[1, n_p], [2, n_f]] + \@long_name: + type: NX_CHAR axis_pattern_identifier(NX_UINT): - dim: (n_p,) unit: NX_UNITLESS - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_p]] + \@long_name: + type: NX_CHAR axis_s(NX_FLOAT): - dim: (n_f,) unit: NX_ANY - #\@units: 1/nm - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_f]] + + # \@units: 1/nm + \@long_name: + type: NX_CHAR axis_time(NX_FLOAT): + unit: NX_TIME doc: | Time since start of the in-situ experiment - dim: (n_p,) - unit: NX_TIME - # \@units: s + dimensions: + rank: 1 + dim: [[1, n_p]] + + # \@units: s # peak_fitting(NXpeak_fitting): - # exists: optional - # doc: | - # Background-corrected azimuthally integrated signals indexed for peaks. + # exists: optional + # doc: | + # Background-corrected azimuthally integrated signals indexed for peaks. # more NXprocess groups could follow only sky is the limit and your imagination and time devotion profiling(NXcs_profiling): exists: optional + # possible place to store details about performance, profiling, etc. current_working_directory(NX_CHAR): exists: recommended @@ -208,6 +270,309 @@ NXem_calorimetry(NXobject): end_time(NX_DATE_TIME): exists: recommended total_elapsed_time(NX_NUMBER): - # number_of_processes(NX_POSINT): - # number_of_threads(NX_POSINT): - # number_of_gpus(NX_POSINT): + + # number_of_processes(NX_POSINT): + # number_of_threads(NX_POSINT): + # number_of_gpus(NX_POSINT): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# f41deb48c75893d566a12ac2f3de95ae2277f8505f71576813fed046deae110f +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# +# Number of pattern +# +# +# +# +# Number of azimuthal integration bins +# +# +# +# +# Number of coordinates along i axis. +# +# +# +# +# Number of coordinates along j axis. +# +# +# +# +# Application definition for minimal example in-situ calorimetry. +# +# What is the technique about. +# +# General context. +# +# Literature references. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Reference to the resource which stores acquired pattern from the experiment. +# +# Can refer to the original EMD or MRC files or the parsed NXem in RDM e.g. NOMAD OASIS. +# +# +# +# +# +# +# +# +# Reference to the resource which stores actuator log file from the experiment. +# +# +# +# +# +# +# +# +# Assumptions and computations whereby timestamp data from the +# detector used for collecting diffraction pattern and the actuator +# (heating chip) were synchronized. +# +# +# +# +# +# +# +# +# +# Timestamp when pattern acquisition started. +# +# +# +# +# +# +# +# Timestamp when pattern acquisition ended. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Acquired diffraction pattern azimuthally integrated as a function of time. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Time since start of the in-situ experiment +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Azimuthally integrated diffraction intensities corrected for background as a +# function of time. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Time since start of the in-situ experiment +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml index d5d6e1dd5b..d0c25acc19 100644 --- a/contributed_definitions/nyaml/NXem_correlation.yaml +++ b/contributed_definitions/nyaml/NXem_correlation.yaml @@ -137,6 +137,7 @@ NXem_correlation(NXem_method): descriptor: doc: | Descriptor representing the image contrast. + # \@signal: # data # \@axes: # [axis_y, axis_x] # \@axis_x_indices: 0 @@ -152,7 +153,10 @@ NXem_correlation(NXem_method): unit: NX_UNITLESS doc: | Descriptor values displaying the ROI. - dim: (n_z, n_y, n_x) + dimensions: + rank: 3 + dim: [[1, n_z], [2, n_y], [3, n_x]] + # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 # in axes fast to fastest # while for _indices fastest to fast @@ -163,7 +167,9 @@ NXem_correlation(NXem_method): unit: NX_LENGTH doc: | Calibrated coordinate along the z-axis. - dim: (n_z,) + dimensions: + rank: 1 + dim: [[1, n_z]] \@long_name: doc: | Label for the z axis @@ -171,7 +177,9 @@ NXem_correlation(NXem_method): unit: NX_LENGTH doc: | Calibrated coordinate along the y-axis. - dim: (n_y,) + dimensions: + rank: 1 + dim: [[1, n_y]] \@long_name: doc: | Label for the y axis @@ -179,13 +187,264 @@ NXem_correlation(NXem_method): unit: NX_LENGTH doc: | Calibrated coordinate along the x-axis. - dim: (n_x,) + dimensions: + rank: 1 + dim: [[1, n_x]] \@long_name: doc: | Label for the x axis - # NEW ISSUE: implement support for filters eventually many of them - # NEW ISSUE: for now only show that data from DREAM3D can be loaded. - # NEW ISSUE: how to handle landmarks - # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid - # image registration etc. - # sequence_index(N0): + + # NEW ISSUE: implement support for filters eventually many of them + # NEW ISSUE: for now only show that data from DREAM3D can be loaded. + # NEW ISSUE: how to handle landmarks + # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid + # image registration etc. + # sequence_index(N0): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 7f16c96c600114d0cff2a2325462e880c20a26d2ad095ed13d00a3b7270dd452 +# +# +# +# +# +# Base class to combine different method-specific data in electron microscopy. +# +# This base class represent a template for documenting correlations +# (spatial, temporal) between different method-specific results. +# +# +# +# Details about processing steps. +# +# +# +# +# +# Details about correlated or logically connected EBSD datasets. +# +# One important class of such correlated experiments are the so-called +# (quasi) in-situ experiments. In this case the same or nearly the same ROI +# gets analyzed via a repetitive sequence of thermomechanical treatment, +# sample preparation, measurement, on-the-fly-indexing. Phenomena +# investigated are recrystallization, strain accumulation, material damage. +# Post-processing is required to correlate and reidentify eventual +# microstructural features or local ROIs across several orientation maps. +# +# Another important class of correlated experiments are the so-called +# serial-sectioning experiments. Here the same sample is measured +# repetitively after polishing each time, to create a stack of +# orientation data which can be reconstructed to a +# three-dimensional volume ROI. +# +# Data can be correlated in time, position (spatial), or both (spatiotemporal). +# +# Spatial correlations between repetitively characterized regions-of-interests +# are typically correlated using image registration and alignment algorithms. +# For this typically so-called landmarks are used. These can be grains with +# a very large size or specific shape, i.e. grains which are qualitatively +# different enough to be used as a guide how images are shifted relative to +# one another. Other commonly used landmarks are fiducial marks which are +# milled into the specimen surface using focus-ion beam milling and/or various +# types of indentation methods. +# +# As far as the same physical region-of-interest is just measured several times, +# the additional issue of the depth increment is not a concern. However, correct +# assumptions for the depth increment, amount of material removed along the milling +# direction is relevant for accurate and precise three-dimensional (serial-sectioning) +# correlations. For these studies it can be tricky though to assume or estimate +# useful depth increments. Different strategies have been proposed like +# calibrations, wedged-shaped landmarks and computer simulation assisted +# assumption making. +# +# Despite the use of landmarks, there are many practical issues which make the +# processing of correlations imprecise and inaccurate. Among these are drift +# and shift of the specimen, instabilities of the holder, the beam, irrespective +# of the source of the drift, charging effects, here specifically causing local +# image distortions and rotations which may require special processing algorithms +# to reduce such imprecisions. +# +# Time correlations face all of the above-mentioned issues surplus the challenge +# that specific experimental protocols have to be used to ensure the material state +# is observed at specific physical time. The example of quasi in-situ characterization +# of crystal growth phenomena, a common topic in engineering or modern catalysis research +# makes it necessary to consider that e.g. the target value for the desired annealing +# temperature is not just gauged based on macroscopic arguments but considers +# that transient effects take place. Heating or quenching a sample might thus might +# not have been executed under conditions in the interaction volume as they are +# documented and/or assumed. +# +# These issue cause that correlations have an error margin as to how accurately +# respective datasets were not only just synced based on the geometry of the +# region-of-interests and the time markers but also to asssure which physical +# conditions the specimen experienced over the course of the measurements. +# +# The fourth example of the em_om reference implementation explores the use of the +# correlation group with a serial-sectioning datasets that was collected by the +# classical Inconel 100 dataset collected by M. D. Uchic and colleagues +# (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and +# characterization of polycrystalline microstructures using a fib-sem system data set. +# Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). +# +# This dataset was specifically relevant in driving forward the implementation +# of the DREAM.3D software. DREAM.3D is an open-source software project for +# post-processing and reconstructing, i.e. correlating sets of orientation +# microscopy data foremost spatially. One focus of the software is the +# (post-)processing of EBSD datasets. Another cutting edge tool with similar +# scope but a commercial solution by Bruker is QUBE which was developed by +# P. Konijnenberg and coworkers. +# +# Conceptually, software like DREAM.3D supports users with creating linear +# workflows of post-processing tasks. Workflows can be instructed via the +# graphical user interface or via so-called pipeline processing via command line +# calls. DREAM.3D is especially useful because its internal system documents all +# input, output, and parameter of the processing steps. This makes DREAM.3D a +# good candidate to interface with tools like em_om parser. Specifically, DREAM.3D +# documents numerical results via a customized HDF5 file format called DREAM3D. +# Workflow steps and settings are stored as nested dictionaries in JSON syntax +# inside a supplementary JSON file or alongside the data in the DREAM3D file. +# DREAM.3D has a few hundred algorithms implemented. These are called filters +# in DREAM.3D terminology. +# +# Users configure a workflow which instructs DREAM.3D to send the data through +# a chain of predefined and configured filters. Given that for each analysis +# the filter is documented via its version tags surplus its parameter and setting +# via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file +# is possible in an automated manner using a parser. This makes DREAM.3D analyses +# repeatable and self-descriptive. A key limitation though is that most frequently +# the initial set of input data come from commercial files like ANG. +# This missing link between the provenance of these input files, their associated +# creation as electron microscope session, is also what NXem_ebsd solves. +# +# Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that +# the DREAM.3D and the em_om parser can work productively together to realize +# RDMS-agnostic parsing of serial-section analyses. +# +# The internal documentation of the DREAM.3D workflow also simplifies the +# provenance tracking represented by an instance of NXem_ebsd as not every +# intermediate results has to be stored. Therefore, the fourth example +# focuses on the key result obtained from DREAM.3D - the reconstructed +# and aligned three-dimensional orientation map. +# +# Usually, this result is the starting point for further post-processing +# and characterization of structural features. As here orientation microscopy +# is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should +# be useful for different characterization methods, such as EBSD, Transmission +# Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), +# Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) +# or open-source implementations of these techniques (such as via pyxem/orix). +# +# The result of orientation microscopy methods are maps of local orientation +# and thermodynamic phase (crystal structure) pieces of information. Virtually +# all post-processing of such results for structural features includes again +# a workflow of steps which are covered though by the NXmicrostructure partner application +# definition. The respective source of the data in an instance of NXmicrostructure can +# again be a link or reference to an instance of NXem_ebsd to complete the +# chain of provenance. +# +# +# +# +# +# Descriptor representing the image contrast. +# +# +# +# +# +# Title of the default plot. +# +# +# +# +# Descriptor values displaying the ROI. +# +# +# +# +# +# +# +# +# +# Descriptor values. +# +# +# +# +# +# Calibrated coordinate along the z-axis. +# +# +# +# +# +# +# Label for the z axis +# +# +# +# +# +# Calibrated coordinate along the y-axis. +# +# +# +# +# +# +# Label for the y axis +# +# +# +# +# +# Calibrated coordinate along the x-axis. +# +# +# +# +# +# +# Label for the x axis +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXem_ebsd.yaml b/contributed_definitions/nyaml/NXem_ebsd.yaml index b6fb3dba97..c2b3f0b195 100644 --- a/contributed_definitions/nyaml/NXem_ebsd.yaml +++ b/contributed_definitions/nyaml/NXem_ebsd.yaml @@ -2,46 +2,46 @@ category: base doc: - | Base class method-specific for Electron Backscatter Diffraction (EBSD). - +- | The general procedure of an EBSD experiment is as follows. Users load the specimen, collect first a coarse image of the surface. Next, they set an approximate value for the calibrated working distance and tilt the stage to set the desired diffraction conditions. - +- | Users then typically configure the microscope for collecting higher quality data and push in the EBSD detector. Subsequently, they fine tune the illumination and aberration corrector settings and select one or multiple ROIs for the microscope to machine off automatically. They configure on-the-fly indexing parameter and start the measurement queue. - +- | Nowadays, this is in most cases an automated process. The pattern collection runs during the allocated microscope session until the queue finishes or gets interrupted by errors or the next user terminates sessions which run over time. - +- | Kikuchi pattern surplus eventually multi-modal detector signals are collected and usually indexed on-the-fly. Patterns may be stored or not so one should not assume that raw data are always stored. - +- | Results are stored in files, which afterwards are typically copied automatically or manual for archival purposes to certain storage locations or further consumption. The result of such an EBSD measurement/experiment is a set of usually proprietary or open files from technology partners. - +- | This :ref:`NXem_ebsd` base class is a proposal how to represent method-specific data, metadata, and connections between these for the research field of electron microscopy. - +- | More specifically, exemplified here for electron backscatter diffraction (EBSD) we show how NeXus can be used to solve two key documentation issues so far missing in the field of EBSD. - +- | Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted according to NXem_ebsd) stores the connection between the microscope session and the key datasets which are considered typically results of the various processing steps involved when working with EBSD data. - +- | Different groups in NXem_ebsd make connections to data artifacts which were collected when working with electron microscopes via the NXem application definition. Using a file which stores information according to the NXem application definition @@ -50,7 +50,7 @@ doc: and details about the acquisition and eventual indexing of Kikuchi pattern, associated overview images, like secondary electron or backscattered electron images of the region-of-interest probed and many more pieces of information. - +- | Secondly, NXem_ebsd connects and stores the conventions and reference frames which were used and which are the key to a correct mathematical interpretation of every EBSD result. Otherwise, results would be ripped out of their context, @@ -60,7 +60,7 @@ doc: format but without communicating all conventions or relying on the assumptions that colleagues likely know these conventions even though multiple definitions are possible. - +- | NXem_ebsd covers experiments with one-, two-dimensional, and so-called three- dimensional EBSD datasets. The third dimension is either time (in the case of quasi in-situ experiments) or space (in the case of serial-sectioning) methods @@ -68,19 +68,19 @@ doc: the same region-of-interest at different depth increments. Material removal can be achieved with electron or ion polishing, using manual steps or using automated equipment like a robot system. - +- | Three-dimensional experiments require to follow a sequence of specimen, surface preparation, and data collection steps. By nature these methods are destructive in that they either require the removal of the previously measured material region or that the sample surface can degrade due to e.g. contamination or other electron-matter interaction. - +- | For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are combined into one reconstructed stack. That is serial-sectioning is mainly a computational workflow. Users collect data for each serial sectioning step via an experiment. This assures that data for associated microscope sessions and steps of data processing stay connected and contextualized. - +- | Eventual tomography methods also use such a workflow because first diffraction images are collected (e.g. with X-ray) and then these imagres are indexed and computed into a 3D orientation mapping. The here proposed NXem_ebsd application @@ -98,7 +98,7 @@ symbols: n_sc: | Number of scan points. n_z: | - Number of pixel along the slowest changing dimension for a rediscretized, + Number of pixel along the slowest changing dimension for a rediscretized, i.e. standardized default plot orientation mapping. n_y: | Number of pixel along slow changing dimension for a rediscretized i.e. @@ -110,6 +110,7 @@ symbols: Number of phase solutions type: group NXem_ebsd(NXem_method): + # (NXcoordinate_system): gnomonic_reference_frame(NXcoordinate_system): doc: | @@ -132,15 +133,18 @@ NXem_ebsd(NXem_method): enumeration: [undefined, in_the_pattern_centre] x_direction(NX_CHAR): doc: | - Direction of the positively pointing x-axis base vector of the gnomonic_reference_frame. + Direction of the positively pointing x-axis base vector of the + gnomonic_reference_frame. enumeration: [undefined, north, east, south, west, in, out] y_direction(NX_CHAR): doc: | - Direction of the positively pointing y-axis base vector of the gnomonic_reference_frame. + Direction of the positively pointing y-axis base vector of the + gnomonic_reference_frame. enumeration: [undefined, north, east, south, west, in, out] z_direction(NX_CHAR): doc: | - Direction of the positively pointing z-axis base vector of the gnomonic_reference_frame. + Direction of the positively pointing z-axis base vector of the + gnomonic_reference_frame. enumeration: [undefined, north, east, south, west, in, out] pattern_centre(NXprocess): doc: | @@ -163,20 +167,25 @@ NXem_ebsd(NXem_method): normals to the respective edges of this rectangle. x_boundary_convention(NX_CHAR): doc: | - From which border of the EBSP (in the detector reference frame) is the pattern centre's x-position (PCx) measured. + From which border of the EBSP (in the detector reference frame) is the pattern + centre's x-position (PCx) measured. enumeration: [undefined, top, right, bottom, left] x_normalization_direction(NX_CHAR): doc: | - In which direction are positive values for the x-axis coordinate value measured from the specified boundary. + In which direction are positive values for the x-axis coordinate value measured + from the specified boundary. enumeration: [undefined, north, east, south, west] y_boundary_convention(NX_CHAR): doc: | - From which border of the EBSP (in the detector reference frame) is the pattern centre's y-position (PCy) measured. + From which border of the EBSP (in the detector reference frame) is the pattern + centre's y-position (PCy) measured. enumeration: [undefined, top, right, bottom, left] y_normalization_direction(NX_CHAR): doc: | - In which direction are positive values for the y-axis coordinate value measured from the specified boundary. + In which direction are positive values for the y-axis coordinate value measured + from the specified boundary. enumeration: [undefined, north, east, south, west] + # distance_convention: # doc: | # How is the third of the three pattern centre parameter values, @@ -197,6 +206,7 @@ NXem_ebsd(NXem_method): regions-of-interested which are sampled with regular square or hexagon-shaped pixels. time(NX_NUMBER): + unit: NX_TIME doc: | Physical time since the beginning of a timestamp that is required to be same for all experiments in the set. The purpose of this marker is @@ -205,19 +215,20 @@ NXem_ebsd(NXem_method): The time is relevant to sort e.g. experiments of consecutive quasi in-situ experiments where a measurement was e.g. taken after 0 minutes, 30 minutes, 6 hours, or 24 hours of annealing. - unit: NX_TIME - \@epoch_start(NX_CHAR): + \@epoch_start: + type: NX_CHAR doc: | Timestamp relative to which time was counted to aid converting between time and timestamp. + # (NXtransformations): - # doc: | - # Transformation which details where the region-of-interest described under - # indexing is located in absolute coordinates and rotation with respect - # to which coordinate system. + # doc: | + # Transformation which details where the region-of-interest described under + # indexing is located in absolute coordinates and rotation with respect + # to which coordinate system. # pattern_available(NX_BOOLEAN): - # doc: | - # True if pattern were stored and are retrieveable via depends_on or source. + # doc: | + # True if pattern were stored and are retrieveable via depends_on or source. depends_on(NX_CHAR): doc: | If available and it is stored in an instance of an application definition this field @@ -351,6 +362,7 @@ NXem_ebsd(NXem_method): integer. We start counting from 1 because the value 0 is reserved for the special phase that is the null-model, i.e. the null phase, notIndexed. status(NX_UINT): + unit: NX_UNITLESS doc: | Which return value did the indexing algorithm yield for each scan point. Practically useful is to use an uint8 mask. @@ -360,9 +372,11 @@ NXem_ebsd(NXem_method): * 2 - No solution * 100 - Success * 255 - Unexpected errors - unit: NX_UNITLESS - dim: (n_sc,) + dimensions: + rank: 1 + dim: [[1, n_sc]] n_phases_per_scan_point(NX_INT): + unit: NX_UNITLESS doc: | How many phases i.e. crystal structure models were used to index each scan point if any? Let's assume an example to explain how this field @@ -379,9 +393,11 @@ NXem_ebsd(NXem_method): point, and all scan points indexed using that same single phase model), phase_identifier has as many entries as scan points and phase_matching has also as many entries as scan points. - unit: NX_UNITLESS - dim: (n_sc,) + dimensions: + rank: 1 + dim: [[1, n_sc]] phase_identifier(NX_INT): + unit: NX_UNITLESS doc: | The array n_phases_per_scan_point details how the phase_identifier and the phase_matching arrays have to be interpreted. @@ -405,16 +421,19 @@ NXem_ebsd(NXem_method): which are organized in sequence: The solutions for the 0-th scan point, the 1-th scan point, the n_sc - 1 th scan point and omitting tuples for those scan points with no phases according to n_phases_per_scan_point - unit: NX_UNITLESS - dim: (n_solutions,) + dimensions: + rank: 1 + dim: [[1, n_solutions]] phase_matching(NX_INT): + unit: NX_UNITLESS doc: | One-dimensional array, pattern by pattern labelling the solutions found. The array n_phases_per_scan_point has to be specified because it details how the phase_identifier and the phase_matching arrays have to be interpreted. See documentation of phase_identifier for further details. - unit: NX_UNITLESS - dim: (n_solutions,) + dimensions: + rank: 1 + dim: [[1, n_solutions]] phase_matching_descriptor(NX_CHAR): doc: | Phase_matching is a descriptor for how well the solution matches or not. @@ -422,7 +441,12 @@ NXem_ebsd(NXem_method): matching probability (other), i.e. the details are implementation-specific. enumeration: [undefined, confidence_index, mean_angular_deviation, other] rotation_set(NXrotation_set): + + # px is no one of the following two calibrated i) is not px*stepsize or ii) is not + # px*stepsize + offset scan_point_positions(NX_NUMBER): + unit: NX_LENGTH + # we make this only required as people may not yet be so happy with # having to walk a graph from measurement -> path -> NXevent_data_em # -> em_lab/ebeam_deflector to retrieve the actual scan positions @@ -432,22 +456,23 @@ NXem_ebsd(NXem_method): doc: | Calibrated center positions of each scan point in the sample surface reference system. - # px is no one of the following two calibrated i) is not px*stepsize or ii) is not px*stepsize + offset - unit: NX_LENGTH - dim: (n_sc, 2) + dimensions: + rank: 2 + dim: [[1, n_sc], [2, 2]] indexing_rate(NX_NUMBER): + unit: NX_DIMENSIONLESS doc: | Fraction of successfully indexed pattern with a phase not the null-phase vs the number_of_scan_points. - unit: NX_DIMENSIONLESS number_of_scan_points(NX_UINT): + unit: NX_UNITLESS doc: | Number of scan points in the original mapping. - unit: NX_UNITLESS odfID(NXmicrostructure_odf): pfID(NXmicrostructure_pf): ipfID(NXmicrostructure_ipf): microstructureID(NXmicrostructure): + # overview over the entire map, rediscretized on a tight aabb roi(NXdata): doc: | @@ -455,8 +480,10 @@ NXem_ebsd(NXem_method): descriptor(NX_CHAR): doc: | Descriptor representing the image contrast. + # taking two examples (CTF and H5OINA choked completely of possibility to find s.th. conceptually common to plot enumeration: [band_contrast, confidence_index, mean_angular_deviation] + # \@signal: # data # \@axes: # [axis_y, axis_x] # \@axis_x_indices: 0 @@ -469,29 +496,754 @@ NXem_ebsd(NXem_method): doc: | Title of the default plot. data(NX_NUMBER): + unit: NX_UNITLESS doc: | Descriptor values displaying the ROI. - unit: NX_UNITLESS - dim: (n_y, n_x) + dimensions: + rank: 2 + dim: [[1, n_y], [2, n_x]] + # n_0 slow 2, n_1 fast 1, rgb triplet is fastest 0 # in axes fast to fastest # while for _indices fastest to fast - \@long_name(NX_CHAR): + \@long_name: + type: NX_CHAR doc: | Descriptor values. axis_y(NX_NUMBER): + unit: NX_LENGTH doc: | Calibrated coordinate along the y-axis. - unit: NX_LENGTH - dim: (n_y,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + type: NX_CHAR doc: | Label for the y axis axis_x(NX_NUMBER): + unit: NX_LENGTH doc: | Calibrated coordinate along the x-axis. - unit: NX_LENGTH - dim: (n_x,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: + type: NX_CHAR doc: | Label for the x axis + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 22b1c39fad61b0675c918c1a4eef96e00364bd4ac83f9d4ffbe8702ac448a9c7 +# +# +# +# +# +# +# +# Number of arguments per orientation for given parameterization. +# +# +# +# +# Number of scan points. +# +# +# +# +# Number of pixel along the slowest changing dimension for a rediscretized, +# i.e. standardized default plot orientation mapping. +# +# +# +# +# Number of pixel along slow changing dimension for a rediscretized i.e. +# standardized default plot orientation mapping. +# +# +# +# +# Number of pixel along fast changing dimension for a rediscretized i.e. +# standardized default plot orientation mapping. +# +# +# +# +# Number of phase solutions +# +# +# +# +# Base class method-specific for Electron Backscatter Diffraction (EBSD). +# +# The general procedure of an EBSD experiment is as follows. +# Users load the specimen, collect first a coarse image of the surface. +# Next, they set an approximate value for the calibrated working distance and +# tilt the stage to set the desired diffraction conditions. +# +# Users then typically configure the microscope for collecting higher quality data +# and push in the EBSD detector. Subsequently, they fine tune the illumination +# and aberration corrector settings and select one or multiple ROIs for +# the microscope to machine off automatically. They configure on-the-fly +# indexing parameter and start the measurement queue. +# +# Nowadays, this is in most cases an automated process. The pattern +# collection runs during the allocated microscope session until the +# queue finishes or gets interrupted by errors or the next user terminates +# sessions which run over time. +# +# Kikuchi pattern surplus eventually multi-modal detector signals are +# collected and usually indexed on-the-fly. Patterns may be stored or not +# so one should not assume that raw data are always stored. +# +# Results are stored in files, which afterwards are typically copied +# automatically or manual for archival purposes to certain storage +# locations or further consumption. The result of such an EBSD +# measurement/experiment is a set of usually proprietary or open files +# from technology partners. +# +# This :ref:`NXem_ebsd` base class is a proposal how to represent method-specific +# data, metadata, and connections between these for the research field of +# electron microscopy. +# +# More specifically, exemplified here for electron backscatter diffraction (EBSD) +# we show how NeXus can be used to solve two key documentation issues so far +# missing in the field of EBSD. +# +# Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted +# according to NXem_ebsd) stores the connection between the microscope session and +# the key datasets which are considered typically results of the various processing +# steps involved when working with EBSD data. +# +# Different groups in NXem_ebsd make connections to data artifacts which were collected +# when working with electron microscopes via the NXem application definition. +# Using a file which stores information according to the NXem application definition +# has the benefit that it connects the sample, references to the sample processing, +# the user operating the microscope, details about the microscope session, +# and details about the acquisition and eventual indexing of Kikuchi pattern, +# associated overview images, like secondary electron or backscattered electron +# images of the region-of-interest probed and many more pieces of information. +# +# Secondly, NXem_ebsd connects and stores the conventions and reference frames +# which were used and which are the key to a correct mathematical interpretation +# of every EBSD result. Otherwise, results would be ripped out of their context, +# as it is the current situation with many traditional studies where EBSD data +# were indexed on-the-fly and shared with the community only via sharing +# the strongly processed results file in some technology-partner-specific file +# format but without communicating all conventions or relying on the assumptions +# that colleagues likely know these conventions even though multiple definitions +# are possible. +# +# NXem_ebsd covers experiments with one-, two-dimensional, and so-called three- +# dimensional EBSD datasets. The third dimension is either time (in the case of +# quasi in-situ experiments) or space (in the case of serial-sectioning) methods +# where a combination of mechanical or ion milling is used repetitively to measure +# the same region-of-interest at different depth increments. Material removal +# can be achieved with electron or ion polishing, using manual +# steps or using automated equipment like a robot system. +# +# Three-dimensional experiments require to follow a sequence of specimen, surface +# preparation, and data collection steps. By nature these methods are destructive +# in that they either require the removal of the previously measured material region +# or that the sample surface can degrade due to e.g. contamination or other +# electron-matter interaction. +# +# For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are +# combined into one reconstructed stack. That is serial-sectioning is mainly a +# computational workflow. Users collect data for each serial sectioning step +# via an experiment. This assures that data for associated microscope sessions +# and steps of data processing stay connected and contextualized. +# +# Eventual tomography methods also use such a workflow because first diffraction +# images are collected (e.g. with X-ray) and then these imagres are indexed and +# computed into a 3D orientation mapping. The here proposed NXem_ebsd application +# definition contains conceptual ideas how this splitting between measurement and +# post-processing can be granularized also for such X-ray-based techniques, whether +# it be 3DXRD or HEDM. +# +# This concept is related to term `Electron Backscatter Diffraction`_ of the EMglossary standard. +# +# .. _Electron Backscatter Diffraction: https://purls.helmholtz-metadaten.de/emg/EMG_00000019 +# +# +# +# +# Details about the gnomonic (projection) reference frame. +# +# It is assumed that the configuration is inspected by looking towards the sample surface. +# If a detector is involved, it is assumed that the configuration is inspected from a position +# that is located behind this detector. +# +# If any of these assumptions is not met, the user is required to explicitly state this. +# +# Reference DOI: 10.1016/j.matchar.2016.04.008 suggests to label the +# base vectors of this coordinate system as Xg, Yg, Zg. +# +# +# +# Origin of the gnomonic_projection_reference_frame. +# +# Reference DOI: 10.1016/j.matchar.2016.04.008 suggests to +# assume that this is coordinate Xg = 0, Yg = 0, Zg = 0. +# +# +# +# +# +# +# +# +# Direction of the positively pointing x-axis base vector of the +# gnomonic_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing y-axis base vector of the +# gnomonic_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing z-axis base vector of the +# gnomonic_reference_frame. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Details about the definition of the pattern centre as a special point in the gnomonic_reference_frame. +# +# Keep in mind that the gnomonic space is in virtually all cases embedded in the detector space. +# Specifically, the XgYg plane is defined such that it is laying inside the XdYd plane +# (of the detector reference frame). +# +# When the normalization direction is the same as e.g. the detector x-axis direction one +# effectively normalizes in fractions of the width of the detector. +# +# The issue with terms like width and height is that these degenerate if the detector +# region-of-interest is square-shaped. This is why instead of referring to width and height +# one should report as if one were to measure practically with a ruler and one is specific +# about in which direction positive distances are measured. +# +# For the concepts used to specify the boundary_convention it is assumed that the +# region-of-interest is defined by a rectangle, referring to the direction of outer-unit +# normals to the respective edges of this rectangle. +# +# +# +# From which border of the EBSP (in the detector reference frame) is the pattern +# centre's x-position (PCx) measured. +# +# +# +# +# +# +# +# +# +# +# +# In which direction are positive values for the x-axis coordinate value measured +# from the specified boundary. +# +# +# +# +# +# +# +# +# +# +# +# From which border of the EBSP (in the detector reference frame) is the pattern +# centre's y-position (PCy) measured. +# +# +# +# +# +# +# +# +# +# +# +# In which direction are positive values for the y-axis coordinate value measured +# from the specified boundary. +# +# +# +# +# +# +# +# +# +# +# +# +# +# This group documents relevant details about the conditions and the tools +# used for measuring a stack of Kikuchi diffraction pattern with an +# electron microscope. +# +# The most frequently collected EBSD data are captured for rectangular +# regions-of-interested which are sampled with regular square or +# hexagon-shaped pixels. +# +# +# +# Physical time since the beginning of a timestamp that is required to be +# same for all experiments in the set. The purpose of this marker is +# to identify how all experiments in the set need to be arranged +# sequentially based on the time elapsed. +# The time is relevant to sort e.g. experiments of consecutive quasi +# in-situ experiments where a measurement was e.g. taken after 0 minutes, +# 30 minutes, 6 hours, or 24 hours of annealing. +# +# +# +# Timestamp relative to which time was counted to aid +# converting between time and timestamp. +# +# +# +# +# +# +# If available and it is stored in an instance of an application definition this field +# specifies the path to an instance of :ref:`NXdata` where the measured patterns +# are stored. +# +# +# +# +# Reference (e.g. path and filename) to an existent data artifact which +# stores either the measured pattern or input (already processed EBSD data). +# +# +# +# +# +# This group documents relevant details about the conditions and the tools +# used for simulating a stack of Kikuchi diffraction pattern with some +# physical model. +# +# This group should not be confused with a group named simulation that +# is however an instance of NXem_sim. Instead, the simulation group here +# should be used if (e.g. instead of a measurement) a stack of pattern +# were simulated that one wishes to use for indexing patterns. +# +# In many practical cases where pattern are analyzed on-the-fly and dictionary +# indexing strategies are used, so-called master pattern(s) are used to compare +# measured or simulated pattern with the master pattern. In this case, +# master pattern are the result of a computer simulation and thus should +# be stored using an own properly documented entry within a simulation +# group as an instance of :ref:`NXem_sim`. +# +# +# +# If available and it is stored in an instance of an application definition this field specifies +# the path to an instance of :ref:`NXimage_set` where the simulated patterns are stored. +# +# +# +# +# Reference (e.g. path and filename) to an existent digital resource which +# stores either the pattern or input (already processed EBSD data) +# which is now processed further as described by this NXem_ebsd instance. +# +# +# +# +# +# The EBSD system, including components like the electron gun, pole-piece, +# stage tilting, EBSD detector, and the gnomonic projection have to be +# calibrated to achieve reliable indexing results. +# +# Specifically, the gnomonic projection has to be calibrated. +# Typically, silicon or quartz crystals are used for this purpose. +# +# Considering a system is well-calibrated, it is much more frequently the +# case in practice that users assume the system is calibrated (and thus usable) +# vs. they perform the calibration of the EBSD system. +# +# In the first case, the user assumes that the principle geometry of the +# hardware components and the settings in the control and EBSD pattern +# acquisition software has been calibrated. Consequently, users pick from +# an existent library of phase candidates, i.e. +# :ref:`NXcrystal_structure` instances. Examples are +# reflector models as stored in CRY files (HKL/Channel 5/Flamenco). +# +# In the second case, users calibrate the system during the session +# using standards (silicon, quartz, or other common specimens). +# There is usually one person in each lab responsible for doing such +# calibrations. Often this person or technician is also in charge of +# configuring the graphical user interface and software with which most +# users control and perform their analyses. +# +# For EBSD this has key implications: Taking TSL OIM/EDAX as an example, +# the conventions how orientations are stored is affected by how the +# reference frames are configured and this setup is made at the level +# of the GUI software. +# +# Unfortunately, these pieces of information are not necessarily stored +# in the results files. In effect, key conventions become disconnected +# from the data so it remains the users' obligation to remember these +# settings or write these down in a lab notebook. Otherwise, these metadata +# get lost. All these issues are a motivation and problem which +# :ref:`NXem_ebsd` solves in that all conventions can be specified explicitly. +# +# +# +# If available and it is stored in an instance of an application definition this field specifies +# the path to an instance of :ref:`NXem_msr` where calibration is stored. +# +# +# +# +# Reference to a digital resource where the calibration is stored. +# +# +# +# +# +# Indexing is a data processing step performed either after or while +# (on-the-fly) the beam scans the specimen. The resulting method is also +# known as orientation imaging microscopy (OIM). +# +# Different algorithms can be used to index EBSD pattern. Common to them +# is the computational step where simulated reference pattern are compared +# with measured or simulated patterns. These latter patterns are referred +# to via the measurement or simulation groups of this base class. +# +# Quality descriptors are defined based on which an indexing algorithm +# yields a quantitative measure of how similar measured and reference +# pattern are, and thus if no, one, or multiple so-called solutions +# were found. +# +# Assumed or simulated pattern are simulated using kinematic or dynamical +# theory of electron diffraction delivering master pattern. +# +# The Hough transform is essentially a discretized Radon transform (for details see `M. van Ginkel et al. <https://www.semanticscholar.org/paper/A-short-introduction-to-the-Radon-and-Hough-and-how-Ginkel/fb6226f606cad489a15e38ed961c419037ccc858>`_). +# Recently, dictionary-based indexing methods are increasingly becoming used +# partly driven by the interest to use artificial intelligence algorithms. +# +# +# +# This group enables to establish a logical connection between previous +# processing steps or on-the-fly-performed indexing of the EBSD map. +# Typically these processing steps are performed with commercial software. +# Therefore, in many cases a results file from this indexing is often +# all that is communicated and saved. These are typically files in a format +# specific to the instrument and its configuration. +# +# Typical file formats are CPR/CRC, ANG, OSC, HDF5, H5EBSD, EDAXH5. +# +# +# +# +# Principal algorithm used for indexing. +# +# +# +# +# +# +# +# +# +# +# +# Details about the background correction applied to each Kikuchi pattern. +# +# +# +# +# Binning i.e. downsampling of the pattern. +# +# +# +# +# Specific parameter relevant only for certain algorithms used. +# +# +# +# +# Details for each phase used as a model with which the patterns were +# indexed. Instances of :ref:`NXcrystal_structure` in this group must +# have the group name prefix phase. The identifier in the name is an +# integer. We start counting from 1 because the value 0 is reserved for +# the special phase that is the null-model, i.e. the null phase, notIndexed. +# +# +# +# +# Which return value did the indexing algorithm yield for each scan point. +# Practically useful is to use an uint8 mask. +# +# * 0 - Not analyzed +# * 1 - Too high angular deviation +# * 2 - No solution +# * 100 - Success +# * 255 - Unexpected errors +# +# +# +# +# +# +# +# How many phases i.e. crystal structure models were used to index each +# scan point if any? Let's assume an example to explain how this field +# should be used: In the simplest case users collected one pattern for +# each scan point and have indexed using one phase, i.e. one instance +# of an NXem_ebsd_crystal_structure_model. +# +# In another example users may have skipped some scan points (not indexed) +# them at all) and/or used differing numbers of phases for different scan +# points. +# +# The cumulated of this array decodes how phase_identifier and phase_matching +# arrays have to be interpreted. In the simplest case (one pattern per scan +# point, and all scan points indexed using that same single phase model), +# phase_identifier has as many entries as scan points +# and phase_matching has also as many entries as scan points. +# +# +# +# +# +# +# +# The array n_phases_per_scan_point details how the phase_identifier +# and the phase_matching arrays have to be interpreted. +# +# For the example with a single phase phase_identifier has trivial +# values either 0 (no solution) or 1 (solution matching +# sufficiently significant with the model for phase 1). +# +# When there are multiple phases, it is possible (although not frequently +# needed) that a pattern matches eventually (not equally well) sufficiently +# significant with multiple pattern. This can especially happen in cases of +# pseudosymmetry and more frequently with an improperly calibrated system +# or false or inaccurate phase models e.g. (ferrite, austenite). +# Having such field is especially relevant for recent machine learning +# or dictionary based indexing schemes because in combination with +# phase_matching these fields communicate the results in a model-agnostic +# way. +# +# Depending on the n_phases_per_scan_point value phase_identifier and +# phase_matching arrays represent a collection of concatenated tuples, +# which are organized in sequence: The solutions for the 0-th scan point, +# the 1-th scan point, the n_sc - 1 th scan point and omitting tuples +# for those scan points with no phases according to n_phases_per_scan_point +# +# +# +# +# +# +# +# One-dimensional array, pattern by pattern labelling the solutions found. +# The array n_phases_per_scan_point has to be specified because it details +# how the phase_identifier and the phase_matching arrays have to be interpreted. +# See documentation of phase_identifier for further details. +# +# +# +# +# +# +# +# Phase_matching is a descriptor for how well the solution matches or not. +# Examples can be confidence_index, mean_angular_deviation, some AI-based +# matching probability (other), i.e. the details are implementation-specific. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Calibrated center positions of each scan point +# in the sample surface reference system. +# +# +# +# +# +# +# +# +# Fraction of successfully indexed pattern with a phase +# not the null-phase vs the number_of_scan_points. +# +# +# +# +# Number of scan points in the original mapping. +# +# +# +# +# +# +# +# +# +# An overview of the entire ROI. +# +# +# +# Descriptor representing the image contrast. +# +# +# +# +# +# +# +# +# +# +# +# Title of the default plot. +# +# +# +# +# Descriptor values displaying the ROI. +# +# +# +# +# +# +# +# +# Descriptor values. +# +# +# +# +# +# Calibrated coordinate along the y-axis. +# +# +# +# +# +# +# Label for the y axis +# +# +# +# +# +# Calibrated coordinate along the x-axis. +# +# +# +# +# +# +# Label for the x axis +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml index c9a6b03c14..c747f63122 100644 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -10,6 +10,7 @@ doc: | In effect, the resulting three-dimensional elemental information mappings are truely the result of a correlation and post-processing of several measurements which is the field of correlative tomographic usage of electron microscopy. + # NEW ISSUE: use computational geometry to offer arbitrary scan pattern # NEW ISSUE: make the binning flexible per scan point # energy typically the fastest direction @@ -24,6 +25,7 @@ symbols: Number of IUPAC line names type: group NXem_eds(NXem_method): + # NXprocess is composed from NXem_method base class instances where the spectra # are stored as instances of (NXspectrum_set) is composed from NXem_method base class # for post-processing of/with the above-defined data entries @@ -40,19 +42,25 @@ NXem_eds(NXem_method): doc: | Accumulated intensity over all pixels of the region-of-interest. intensity(NX_NUMBER): + unit: NX_UNITLESS doc: | Accumulated counts - unit: NX_UNITLESS - dim: (n_photon_energy,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_photon_energy]] + \@long_name: + type: NX_CHAR doc: | Counts axis_energy(NX_NUMBER): + unit: NX_ENERGY doc: | Energy axis - unit: NX_ENERGY - dim: (n_photon_energy,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_photon_energy]] + \@long_name: + type: NX_CHAR doc: | Energy (NXpeak): @@ -63,22 +71,26 @@ NXem_eds(NXem_method): X-ray lines should be specified. (NXion): energy_range(NX_NUMBER): + unit: NX_ENERGY doc: | Associated lower :math:`[e_{min}, e_{max}]` bounds of the energy which is assumed associated with this peak. - unit: NX_ENERGY - dim: (2,) + dimensions: + rank: 1 + dim: [[1, 2]] energy(NX_NUMBER): + unit: NX_ENERGY doc: | Theoretical energy of the line according to IUPAC. - unit: NX_ENERGY iupac_line_names(NX_CHAR): doc: | IUPAC notation identifier of the line which the peak represents. This can be a list of IUPAC notations for (the seldom) case that multiple lines are grouped with the same peak. - dim: (n_iupac_line_names,) + dimensions: + rank: 1 + dim: [[1, n_iupac_line_names]] atom_types(NX_CHAR): doc: | Comma-separated list of names of elements confirmed in the sample via EDS analysis. @@ -88,7 +100,10 @@ NXem_eds(NXem_method): This field can be used when creating instances of NXpeak is not desired. However, a collection of instances of NXpeak with individual NXion specified enables also to distinguish isotopic information. - dim: (n_elements,) + dimensions: + rank: 1 + dim: [[1, n_elements]] + # often the details of implemented background models and ZAF corrections are # implemented and processed using proprietary software, in that case it can be # the proprietary file formats typically have this information not documented completely @@ -106,7 +121,7 @@ NXem_eds(NXem_method): accumulated X-ray quanta *under the curve(s)* of a set of peaks. These element-specific EDS maps are :ref:`NXimage_set` instances - and need to be named with the name of the element from the + and need to be named with the name of the element from the atom_types field. We often observe that signal contributions from several peaks @@ -123,21 +138,253 @@ NXem_eds(NXem_method): documents which elements and their specific lines are theoretically located within the energy_range of the spectrum from which the EDS (element) map has been computed. energy_range(NX_NUMBER): + unit: NX_ENERGY doc: | Associated :math:`[e_{min}, e_{max}]` bounds of the energy range for which spectrum counts have been accumulated. - unit: NX_ENERGY - dim: (2,) + dimensions: + rank: 1 + dim: [[1, 2]] (NXprocess): peaks(NX_CHAR): doc: | A list of NXpeak instance names whose X-ray quanta where accumulated for each pixel which yields an element-specific EDS map. - dim: (n_peaks,) + dimensions: + rank: 1 + dim: [[1, n_peaks]] weights(NX_NUMBER): + unit: NX_UNITLESS doc: | A list of weights by how much the intensity of each peak under peaks was factorized to display the joint intensity of the image. - unit: NX_UNITLESS + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# a2f0e624072e3af9809088c533b6c420843c7c34a4d34dfa4d184b1f3eff1d52 +# +# +# +# +# +# +# +# +# Number of X-ray photon energy (bins) +# +# +# +# +# Number of identified elements +# +# +# +# +# Number of peaks detected +# +# +# +# +# Number of IUPAC line names +# +# +# +# +# Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDXS). +# +# `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. +# +# X-ray spectroscopy is a surface-sensitive technique. Therefore, three-dimensional elemental +# characterzation requires typically a sequence of characterization and preparation of the +# surface to expose a new surface layer that can be characterized in the next acquisition. +# In effect, the resulting three-dimensional elemental information mappings are truely the +# result of a correlation and post-processing of several measurements which is the field +# of correlative tomographic usage of electron microscopy. +# +# +# +# +# Details about computational steps how peaks were indexed as elements. +# +# +# +# The program with which the indexing was performed. +# +# +# +# +# Accumulated intensity over all pixels of the region-of-interest. +# +# +# +# Accumulated counts +# +# +# +# +# +# +# Counts +# +# +# +# +# +# Energy axis +# +# +# +# +# +# +# Energy +# +# +# +# +# +# +# Name and location of each X-ray line which was indexed as a known ion. +# For each ion, an NXion instance should be created which specifies +# the origin of the signal. For each ion also the relevant IUPAC notation +# X-ray lines should be specified. +# +# +# +# +# Associated lower :math:`[e_{min}, e_{max}]` bounds of the +# energy which is assumed associated with this peak. +# +# +# +# +# +# +# +# Theoretical energy of the line according to IUPAC. +# +# +# +# +# IUPAC notation identifier of the line which the peak represents. +# +# This can be a list of IUPAC notations for (the seldom) case that +# multiple lines are grouped with the same peak. +# +# +# +# +# +# +# +# +# +# Comma-separated list of names of elements confirmed in the sample via EDS analysis. +# +# All members of the list have to be valid chemical_symbols from the periodic table. +# +# This field can be used when creating instances of NXpeak is not desired. +# However, a collection of instances of NXpeak with individual NXion specified +# enables also to distinguish isotopic information. +# +# +# +# +# +# +# +# +# Individual element-specific EDS/EDX/EDXS/SXES mapping +# +# A composition map is an image whose intensities for each pixel are the +# accumulated X-ray quanta *under the curve(s)* of a set of peaks. +# +# These element-specific EDS maps are :ref:`NXimage_set` instances +# and need to be named with the name of the element from the +# atom_types field. +# +# We often observe that signal contributions from several peaks +# are summarized and shown together, e.g. the combined signal +# under the curve of carbon and oxygen. +# +# In this case specify the processing details using peaks and weights. +# +# +# +# Discouraged free-text field to add additional information. +# +# +# +# +# Comma-separated list of chemical_symbol-IUPAC X-ray (emission) line name that +# documents which elements and their specific lines are theoretically located within +# the energy_range of the spectrum from which the EDS (element) map has been computed. +# +# +# +# +# Associated :math:`[e_{min}, e_{max}]` bounds of the energy +# range for which spectrum counts have been accumulated. +# +# +# +# +# +# +# +# +# A list of NXpeak instance names whose X-ray quanta +# where accumulated for each pixel which yields an element-specific +# EDS map. +# +# +# +# +# +# +# +# A list of weights by how much the intensity of each peak +# under peaks was factorized to display the joint intensity +# of the image. +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml index 77c194a693..7eebed3c55 100644 --- a/contributed_definitions/nyaml/NXem_eels.yaml +++ b/contributed_definitions/nyaml/NXem_eels.yaml @@ -1,10 +1,12 @@ category: base doc: | Base class method-specific for Electron Energy Loss Spectroscopy (EELS). + # symbols: - # n_energy_loss: Number of electron energy loss bins. +# n_energy_loss: Number of electron energy loss bins. type: group NXem_eels(NXem_method): + # NXem_method also has an NXprocess which in this base class can be # specialized to include EELS-specific post-processing zlp_correction(NXprocess): @@ -25,3 +27,69 @@ NXem_eels(NXem_method): (NXspectrum_set): doc: | NXspectrum_set_em specialized for EELS. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 407770508c979ffc5bf643138ca130ccfd5e1211d79825d9a1925b7e70bbcb12 +# +# +# +# +# +# +# Base class method-specific for Electron Energy Loss Spectroscopy (EELS). +# +# +# +# +# Details about computational stesp how the zero-loss peak was threaded. +# +# +# +# The program with which the zero-loss peak correction was performed. +# +# +# +# +# +# Details about computational steps how peaks were indexed as elements. +# +# +# +# The program with which the indexing was performed. +# +# +# +# +# Name and location of each peak in the spectrum considered to be of relevance. +# +# +# +# +# NXspectrum_set_em specialized for EELS. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml index 015e6fa7dc..9b31b578ef 100644 --- a/contributed_definitions/nyaml/NXem_img.yaml +++ b/contributed_definitions/nyaml/NXem_img.yaml @@ -17,11 +17,79 @@ NXem_img(NXem_method): enumeration: [secondary_electron, backscattered_electron, annular_dark_field, cathodoluminescence] (NXimage_set): half_angle_interval(NX_NUMBER): + unit: NX_ANGLE doc: | Annulus inner (first value) and outer (second value) half angle. - unit: NX_ANGLE - dim: (2,) + dimensions: + rank: 1 + dim: [[1, 2]] (NXmicrostructure): doc: | A reconstruction of the microstructure or some of its features based on image information in the parent class. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e29b7f1c5c13a8020e5e040b6d179f89ddfd3c80fc6edcb0a2bae27aa6f4b7c5 +# +# +# +# +# +# Base class for method-specific generic imaging. +# +# In the majority of cases simple d-dimensional regular scan patterns are used +# to probe a region-of-interest (ROI). Examples can be single point aka spot +# measurements, line profiles, or (rectangular) surface mappings. +# The latter pattern is the most frequently used. +# +# For now the base class provides for scans for which the settings, +# binning, and energy resolution is the same for each scan point. +# +# +# +# Which imaging mode was used? +# +# +# +# +# +# +# +# +# +# +# +# Annulus inner (first value) and outer (second value) half angle. +# +# +# +# +# +# +# +# A reconstruction of the microstructure or some of its features +# based on image information in the parent class. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml index 28c880f000..8fd23cde4a 100644 --- a/contributed_definitions/nyaml/NXem_method.yaml +++ b/contributed_definitions/nyaml/NXem_method.yaml @@ -17,4 +17,53 @@ NXem_method(NXobject): sequence_index(NX_INT): (NXimage_set): (NXspectrum_set): + # add links to relevant data + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 34e8f17377c058eb94a193c981704a91b98da049158a76b976a07d534b2e69b2 +# +# +# +# +# +# Base class to describe specific analysis methods in electron microscopy. +# +# This base class represent a template how specialized, deep, and method-specific +# base classes can be defined with which an (NXem) application +# definition gets equipped with specific groups to document method-specific +# processing steps and report analyzed quantities. +# +# The template base class name :ref:`NXem_method` needs to be changed for +# each method e.g. :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. +# +# +# +# Details about processing steps. +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml index fc509a6213..3a619f721b 100644 --- a/contributed_definitions/nyaml/NXem_msr.yaml +++ b/contributed_definitions/nyaml/NXem_msr.yaml @@ -43,6 +43,7 @@ NXem_msr(NXem_method): (NXebeam_column): (NXibeam_column): (NXoptical_system_em): + # storing these data should happen in event_data, i.e. dynamic quantities (NXscanbox_em): (NXdetector): @@ -55,11 +56,114 @@ NXem_msr(NXem_method): local_name(NX_CHAR): doc: | Instrument-specific alias/name - # it is unfortunate that for NXdetector there are already many places - # how one can specify details which could equally end up in fabrications - # we should give better guidance which option to use, pr to niac - # (NXfabrication): + + # it is unfortunate that for NXdetector there are already many places + # how one can specify details which could equally end up in fabrications + # we should give better guidance which option to use, pr to niac + # (NXfabrication): (NXpump): (NXstage_lab): (NXevent_data_em_set): -# (NXevent_data_em): + + # (NXevent_data_em): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 2cb15b12d7f28560bff7adb283bef98bb6cb829ca6ddd4a14bdbe529caade514 +# +# +# +# +# +# Base class for collecting a session with a real electron microscope. +# +# For collecting data and experiments which are simulations of an +# electron microscope use the :ref:`NXem_sim` base class. +# +# +# +# (Meta)data of the microscope and the lab in which it stands. +# +# This em_lab group differs from potential em_lab groups inside +# :ref:`NXevent_data_em` instances in that here the more static descriptions +# are kept while changing, i.e. time-dependent pieces of information are +# logged, via the em_lab group inside the desired number of instances +# of NXevent_data_em. +# +# While using an :ref:`NXevent_data_em` instance, users should store only those +# settings about a component which are relevant to understand the current +# state of the component. Here, current means for the time interval which +# the event covers (as it is detailed via start_time and end_time) timestamps. +# +# For example it is not relevant to store in each :ref:`NXevent_data_em` +# electron_source group again the details of the gun type and the manufacturer +# but only the high-voltage value and that only if it is different from the value +# that is specified in the em_lab section for the static settings. +# +# In effect, this defines an information inference hierarchy which starts +# in an individual :ref:`NXevent_data_em` instance followed by a probing of the +# static section. +# +# +# +# Given name of the microscope at the hosting institution. +# This is an alias. Examples could be NionHermes, Titan, JEOL, +# Gemini, etc. +# +# +# +# +# Location of the lab or place where the instrument is installed. +# Using GEOREF is preferred. +# +# +# +# +# +# +# +# +# +# +# +# Description of the type of the detector. +# +# Electron microscopes have typically multiple detectors. +# Different technologies are in use like CCD, scintillator, +# direct electron, CMOS, or image plate to name but a few. +# +# +# +# Instrument-specific alias/name +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml index 38492d66e2..330227e350 100644 --- a/contributed_definitions/nyaml/NXem_sim.yaml +++ b/contributed_definitions/nyaml/NXem_sim.yaml @@ -22,12 +22,76 @@ doc: | users, and multiple detectors are typically either ignored or reduced in complexity and number and coming with idealizations to keep the simulations focused on the specific reason questions and efficiently numerically executable. + # abTEM and other simulation packages, TEMgym, etc. type: group NXem_sim(NXem_method): simulation(NXprocess): doc: | Details about the simulation. + # sequence_index(N): (NXprogram): (NXcg_geodesic_mesh): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 3cee64d6c22fcb7e2ca0d790a078d7ca1616990b0061b19437bb0dec55767eb6 +# +# +# +# +# +# +# Base class for simulating electron microscopy relevant beam-matter interaction. +# +# The concept behind this base class is to keep it as generic as possible +# that simulations of electron/ion beam interaction with matter can be +# represented. This base class is envisioned as the twin of the :ref:`NXem_msr` +# base class. +# +# It is an attempt to test the idea if at some point one might even use the +# same base class template to describe measurements and computer simulations +# of electron microscopy. This idea is attractive because the only practical +# difference between a description of a measurement with a microscope and a +# computer simulation is that the latter is typically a substantially simplified +# representation of the real microscope surplus the focus of the research +# in such cases on specific questions. +# +# Such simplification can be with respect to the optical setup, typically the +# ignoring of the fact that the electron beam is produced by a complex setup +# of lenses while in simulations often single Einzel lenses are considered. +# Dynamics of the environment like temperature fluctuation in a lab, vibrations, +# users, and multiple detectors are typically either ignored or reduced in +# complexity and number and coming with idealizations to keep the simulations +# focused on the specific reason questions and efficiently numerically executable. +# +# +# +# Details about the simulation. +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXenergydispersion.yaml b/contributed_definitions/nyaml/NXenergydispersion.yaml index a614ecc1a1..c46424fd04 100644 --- a/contributed_definitions/nyaml/NXenergydispersion.yaml +++ b/contributed_definitions/nyaml/NXenergydispersion.yaml @@ -162,9 +162,9 @@ NXenergydispersion(NXobject): # # +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of pulses collected in between start_time and end_time. +# +# +# +# +# Base class to store state and (meta)data of events over the course of an atom probe experiment. +# +# This base class applies the concept of the :ref:`NXevent_data_em` base class to the specific needs +# of atom probe research. Against static and dynamic quantities are splitted to avoid a duplication +# of information. Specifically, the time interval considered is the entire time +# starting at start_time until end_time during which we assume the pulser triggered named pulses. +# These pulses are identified via the pulse_identifier field. The point in time when each was issued +# is specified via the combination of start_time and delta_time. +# +# Conceptually and technically NeXus currently stores tensorial information as arrays of values +# (with each value of the same datatype). For instance, a field temperature(NX_FLOAT) stores +# a set of temperature values but that field when used somewhere is a concept. However, that +# concept has no information at which point in time these temperatures were taken. +# An existent functional relationship between the two concepts is not defined. +# +# However, a correct interpretation of the temperature values demands knowledge about what is +# the independent quantity on which temperature depends on or according to which frequency +# temperature values were sampled. +# In NeXus there are two approaches which cope with such correlations: +# One is :ref:`NXdata` where the attribute signal specifies the correlation. +# The other one is :ref:`NXlog` which, like NXdata, demands to granularize logged_against +# (dependent signal) and independent quantities into an own group. +# In many cases this additional grouping is not desired though. +# +# One naive solution typically employed is then to store the independent variable values via a second +# vector e.g. time_stamp with the same number of entries (with dimensionality defined through symbols). +# However, there is no independent logical connection between these two concepts, i.e. temperature +# and time_stamp. +# +# In the case of atom probe though the time that one would use in NXlog is defined implicitly via pulse_identifier, +# which is the independent variable vector against which eventually dozens of channels of data are logged. +# Not only are these channels logged they should ideally also be self-descriptive in that these channels have +# pulse_identifier as the independent variable but we do not wish to duplicate this information all the time but +# reference it. +# +# Therefore, we here explore the use of an attribute with symbol logged_against. Maybe it is better to use the +# symbol depends_on but this is easily to be confused with depends_on that is used for instances of +# :ref:`NXtransformations`. Consequently, if depends_on were to be used extra logic is needed by consuming +# applications to understand that the here build correlations are conceptually different ones. +# +# This issue should be discussed further by the NeXus community. +# +# +# +# ISO 8601 time code with local time zone offset to UTC information included +# when the snapshot time interval started. If the user wishes to specify an +# interval of time that the snapshot should represent during which the instrument +# was stable and configured using specific settings and calibrations, +# the start_time is the start (left bound of the time interval) while +# the end_time specifies the end (right bound) of the time interval. +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC information included +# when the snapshot time interval ended. +# +# +# +# +# Delta time array which resolves for each pulse_identifier the time difference +# between when that pulse was issued and start_time. +# +# In summary, using start_time, end_time, delta_time, pulse_identifier_offset, +# and pulse_identifier exactly specifies the connection between when a pulse was +# issued relative to start and absolute in UTC. +# +# +# +# +# +# +# +# Integer used to name the first pulse to know if there is an +# offset of the identifiers to zero. +# +# Identifiers can be defined either implicitly or explicitly. +# For implicit indexing identifiers are defined on the interval +# :math:`[identifier\_offset, identifier\_offset + c - 1]`. +# +# Therefore, implicit identifier are completely defined by the value of +# identifier_offset and cardinality. For example if identifier run from +# -2 to 3 the value for identifier_offset is -2. +# +# For explicit indexing the field identifier has to be used. +# Fortran-/Matlab- and C-/Python-style indexing have specific implicit +# identifier conventions where identifier_offset is 1 and 0 respectively. +# +# +# +# +# Identifier that contextualizes how the detector and pulser of an atom probe +# instrument follows a sequence of pulses to trigger field evaporation. +# +# The pulse_identifier is used to associate thus an information about time +# when the quantities documented in this NXpulser_apm base class have been +# collected via sampling. +# +# In virtually all cases the pulser is a blackbox. Depending on how the +# instrument is configured during a measurement the target +# values and thus also the actual values may change. +# +# Maybe the first part of the experiment is run at a certain pulse fraction but thereafter +# the pulse_fraction is changed. In this case the field pulse_fraction is a vector which +# collects all measured values of the pulse_fraction, pulse_identifier is then an equally +# long vector which stores the set of events (e.g. pulsing events) when that value was +# measured. +# +# This may cause several situations: In the case that e.g. the pulse_fraction is never changed +# and also exact details not interesting, one stores the set value for the pulse_fraction +# and a single value for the pulse_identifier e.g. 0 to indicate that the pulse_fraction was set +# at the beginning and it was maintained constant during the measurement. +# If the pulse_fraction was maybe changed after the 100000th pulse, pulse_fraction is a +# vector with two values one for the first and another one for the value from the 100000-th +# pulse onwards. The values of pulse_identifier are then [0, 99999] respectively. +# +# +# +# +# +# +# +# (Meta)data of the dynamics and changes of the microscope over the course of +# pulsing. +# +# +# +# Relevant quantities during a measurement with a LEAP system as suggested by +# `T. Blum et al. <https://doi.org/10.1002/9781119227250.ch18>`_. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Amplitude of the signal detected on the multi-channel plate (MCP). +# +# This field should be used for storing the signal amplitude quantity +# within ATO files. The ATO file format is used primarily by the +# atom probe groups of the GPM in Rouen, France. +# +# +# +# +# +# +# +# +# +# +# +# Set point temperature to achieve during the measurement. +# +# +# +# +# Average temperature (at the specimen base) during the measurement. +# +# +# +# +# +# The best estimate, at experiment time, for the temperature at the +# sample base (furthest point along sample apex and holding assembly +# that is removable from the sample stage). +# +# +# +# +# +# +# Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. +# +# +# +# +# +# +# +# Average pressure in the analysis chamber during the measurement. +# +# +# +# +# Pressure in the analysis chamber. +# +# +# +# +# +# +# Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. +# +# +# +# +# +# +# +# Pressure in the analysis chamber. +# +# +# +# +# +# +# Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. +# +# +# +# +# +# +# +# Pressure in the analysis chamber. +# +# +# +# +# +# +# Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXevent_data_apm_set.yaml b/contributed_definitions/nyaml/NXevent_data_apm_set.yaml index cf5c26323a..4532031b7b 100644 --- a/contributed_definitions/nyaml/NXevent_data_apm_set.yaml +++ b/contributed_definitions/nyaml/NXevent_data_apm_set.yaml @@ -23,3 +23,54 @@ doc: | type: group NXevent_data_apm_set(NXobject): (NXevent_data_apm): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 6ab9c185ecd1fb4d02fac81fbc42e4a44ffab1be2b37d95f6e8ff3d0215d82ce +# +# +# +# +# +# Base class for a set of :ref:`NXevent_data_apm` instances. +# +# Members of the set are instances of :ref:`NXevent_data_apm`. +# These have an associated time interval during which the conditions +# of the instrument were considered stable and fit enough for purpose. +# +# Which temporal granularity is adequate depends on the situation and research +# question. Using a model which enables a collection of events offers the most +# flexible way to cater for both atom probe experiments or simulation. +# +# To monitor the course of an ion extraction experiment (or simulation) +# it makes sense to track time explicitly via time stamps or implicitly +# via e.g. a clock inside the instrument, such as the clock of the pulser +# and respective pulsing event identifier. +# +# As set and measured quantities typically change over time and we do not +# yet know during the measurement which of the events have associated +# (molecular) ions that will end up in the reconstructed volume, we must not +# document quantities as a function of the evaporated_identifier but as a +# function of the (pulsing) event_identifier. +# +# +# diff --git a/contributed_definitions/nyaml/NXevent_data_em.yaml b/contributed_definitions/nyaml/NXevent_data_em.yaml index b0a98d0388..1dda1803ef 100644 --- a/contributed_definitions/nyaml/NXevent_data_em.yaml +++ b/contributed_definitions/nyaml/NXevent_data_em.yaml @@ -40,7 +40,7 @@ doc: | across multiple :ref:`NXevent_data_em` instance. This reduces the amount of pieces of information that have to be stored repetitively. - We are aware of the fact that given the variety how an electron microscope + We are aware of the fact that given the variety how an electron microscope is used, there is a need for a flexible and adaptive documentation system. At the same time we are also convinced though that just because one has different requirements for some specific aspect under the umbrella of settings @@ -58,7 +58,7 @@ doc: | or a stack of spectra. Having to deal with instabilities is a common theme in electron microscopy practice. Numerical protocols can be used during data post-processing to correct for some of the instabilities. - A few exemplar references to provide an overview on the subject is + A few exemplar references to provide an overview on the subject is available in the literature: * `C. Ophus et al. `_ @@ -87,9 +87,9 @@ NXevent_data_em(NXobject): ISO 8601 time code with local time zone offset to UTC information included when the snapshot time interval ended. event_identifier(NX_INT): + unit: NX_UNITLESS doc: | Identifier of a specific state and setting of the microscope. - unit: NX_UNITLESS event_type(NX_CHAR): doc: | Which specific event/measurement type. Examples are: @@ -121,16 +121,189 @@ NXevent_data_em(NXobject): (NXimage_set): (NXspectrum_set): em_lab(NXinstrument): - doc: | - (Meta)data of the dynamics and changes of the microscope during the event. - # no need to duplicate the fabrication because that should remain the - (NXchamber): - (NXebeam_column): - (NXibeam_column): - (NXoptical_system_em): - (NXdetector): - (NXpump): - (NXstage_lab): - # (NXactuator): + doc: | + (Meta)data of the dynamics and changes of the microscope during the event. + + # no need to duplicate the fabrication because that should remain the + (NXchamber): + (NXebeam_column): + (NXibeam_column): + (NXoptical_system_em): + (NXdetector): + (NXpump): + (NXstage_lab): + + # (NXactuator): (NXuser): (NXinteraction_vol_em): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# eab184a059086415ff22900a64b975982449b99e5387d817e5e44dce11fa577c +# +# +# +# +# +# Base class to store state and (meta)data of events with an electron microscopy. +# +# Electron microscopes are dynamic. Scientists often report that microscopes +# *perform differently* across sessions, that they perform differently from +# one day or another. In some cases, root causes for performance differences +# are unclear. Users of the instrument may consider such conditions impractical, +# or *too poor*, and thus abort their session. Alternatively, users may try to +# bring the microscope into a state where conditions are considered better +# or of whatever high enough quality for continuing the measurement. +# +# In all these use cases in practice it would be useful to have a mechanism +# whereby time-dependent data of the instrument state can be stored and +# documented with an interoperable representation. Indeed, how a session on an +# electron microscope is spent depends strongly on the research question, +# the user, and the imaging modalities used. +# +# :ref:`NXevent_data_em` represents an instance to describe and serialize flexibly +# whatever is considered a time interval during which the instrument is +# considered as stable enough for performing a task with the microscope. +# Examples of such tasks are the collecting of data (images and spectra) or +# the calibrating of some component of the instrument. Users may wish to take +# only a single scan or image and complete their microscope session thereafter. +# Alternatively, users are working for much longer time at the microscope, +# perform recalibrations in between and take several scans (of different +# regions-of-interest of the specimen), or they explore the state of the +# microscope for service or maintenance tasks. +# +# :ref:`NXevent_data_em` serves the harmonization and documentation of this situation +# with providing three key sections: Firstly, there is a header section whose +# purpose is to contextualize and identify the event instance in time. +# Secondly, there is a data and metadata section where individual data collections +# can be stored using a standardized representation. +# +# The idea of the first, the event-based em_lab section, is to document the +# state of the microscope as it was during the event. The idea of the other, +# the NXem application based em_lab(NXinstrument) section is to keep all those +# pieces of information which are static in the sense that they are the same +# across multiple :ref:`NXevent_data_em` instance. This reduces the amount of pieces of +# information that have to be stored repetitively. +# +# We are aware of the fact that given the variety how an electron microscope +# is used, there is a need for a flexible and adaptive documentation system. +# At the same time we are also convinced though that just because one has +# different requirements for some specific aspect under the umbrella of settings +# to an electron microscope, this does not necessarily warrant that one has to +# cook up an own schema. +# +# Instead, the electron microscopy community should work towards reusing schema +# components as frequently as possible. This will enable that there is at all +# not only a value of harmonizing electron microscopy research content but also +# the technical possibility to build services around such harmonized +# pieces of information. +# +# Arguably it is oftentimes tricky to specify a clear time interval when the +# microscope is *stable enough*. Take for instance the acquisition of an image +# or a stack of spectra. Having to deal with instabilities is a common theme in +# electron microscopy practice. Numerical protocols can be used during data +# post-processing to correct for some of the instabilities. +# A few exemplar references to provide an overview on the subject is +# available in the literature: +# +# * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ +# * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ +# * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ +# +# For specific simulation purposes, mainly in an effort to digitally repeat +# or simulate the experiment, it is tempting to consider dynamics of the instrument, +# implemented as time-dependent functional descriptions of e.g. lens excitations, +# beam shape functions, trajectories of groups of electrons and ions, +# or detector noise models. This warrants to document the time-dependent +# details of individual components of the microscope +# as is implemented in :ref:`NXevent_data_em`. +# +# +# +# ISO 8601 time code with local time zone offset to UTC information included +# when the snapshot time interval started. If the user wishes to specify an +# interval of time that the snapshot should represent during which the instrument +# was stable and configured using specific settings and calibrations, +# the start_time is the start (left bound of the time interval) while +# the end_time specifies the end (right bound) of the time interval. +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC information included +# when the snapshot time interval ended. +# +# +# +# +# Identifier of a specific state and setting of the microscope. +# +# +# +# +# Which specific event/measurement type. Examples are: +# +# * In-lens/backscattered electron, usually has quadrants +# * Secondary_electron, image, topography, fractography, overview images +# * Backscattered_electron, image, Z or channeling contrast (ECCI) +# * Bright_field, image, TEM +# * Dark_field, image, crystal defects +# * Annular dark field, image (medium- or high-angle), TEM +# * Diffraction, image, TEM, or a comparable technique in the SEM +# * Kikuchi, image, SEM EBSD and TEM diffraction +# * X-ray spectra (point, line, surface, volume), composition EDS/EDX(S) +# * Electron energy loss spectra for points, lines, surfaces, TEM +# * Auger, spectrum, (low Z contrast element composition) +# * Cathodoluminescence (optical spectra) +# * Ronchigram, image, alignment utility specifically in TEM +# * Chamber, e.g. TV camera inside the chamber, education purposes. +# +# This field may also be used for storing additional information +# about the event. For which there is at the moment no other place. +# +# In the long run such free-text field description should be avoided as +# they are difficult to machine-interpret. Instead, reference should be given +# to refactoring these descriptions into structured metadata. +# The reason why in this base class the field event_type is nonetheless kept +# is to offer a place whereby practically users may enter data for +# follow-up modifications to support arriving at an improved :ref:`NXevent_data_em` base class. +# +# +# +# +# +# +# (Meta)data of the dynamics and changes of the microscope during the event. +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXevent_data_em_set.yaml b/contributed_definitions/nyaml/NXevent_data_em_set.yaml index e6f850f011..70c64c6cd5 100644 --- a/contributed_definitions/nyaml/NXevent_data_em_set.yaml +++ b/contributed_definitions/nyaml/NXevent_data_em_set.yaml @@ -13,9 +13,68 @@ doc: | individual aspects of such experiments. type: group NXevent_data_em_set(NXobject): - # because it should be possible to use the application definition - # to store e.g. just some descriptions about the instrument - # to which eventually no measurements are attached - # this would enable to use nxs files also for instrument - # inventory system like offered through ELNs/or LIMS + + # because it should be possible to use the application definition + # to store e.g. just some descriptions about the instrument + # to which eventually no measurements are attached + # this would enable to use nxs files also for instrument + # inventory system like offered through ELNs/or LIMS (NXevent_data_em): + + # because it should be possible to use the application definition + # to store e.g. just some descriptions about the instrument + # to which eventually no measurements are attached + # this would enable to use nxs files also for instrument + # inventory system like offered through ELNs/or LIMS + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e25e9f921fd88c9eaf1988e4620d558c14aca2a19e4794096568fe74f406fcc6 +# +# +# +# +# +# Base class for a set of :ref:`NXevent_data_em` instances. +# +# Members of the set are instances of :ref:`NXevent_data_em`. These have an associated +# time interval during which the conditions were considered stable and +# fit enough for purpose. +# +# Which temporal granularity is adequate depends on the situation and +# research question. Using a model which enables a collection of events offers +# the most flexible way to cater for both experiments with controlled electron +# beams in a real microscope or the simulation of such experiments or +# individual aspects of such experiments. +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXfabrication.yaml b/contributed_definitions/nyaml/NXfabrication.yaml index b9fde874e1..85f7602206 100644 --- a/contributed_definitions/nyaml/NXfabrication.yaml +++ b/contributed_definitions/nyaml/NXfabrication.yaml @@ -39,9 +39,9 @@ NXfabrication(NXobject): # # +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The number of edges. +# +# +# +# +# A set of (eventually directed) edges which connect nodes of a graph. +# +# Use as a direct child of an instance of :ref:`NXgraph_root`. +# Alternatively, use depends_on to specify which instance +# of :ref:`NXgraph_root` is defined by this instance. +# +# +# +# Specify which instance of :ref:`NXgraph_root` this :ref:`NXgraph_edge_set` +# refers to. +# +# +# +# +# Total number of edges, counting eventual bidirectional edges only once. +# +# +# +# +# Integer which specifies the first index to be used for distinguishing +# edges. Identifiers are defined either implicitly or explicitly. +# +# For implicit indexing the identifiers are defined on the interval +# :math:`[identifier\_offset, identifier\_offset + c - 1]`. +# +# For explicit indexing use the field identifier. For implicit indexing, +# consult :ref:`NXcg_primitive_set` to get guidance how to set identifier_offset. +# +# +# +# +# Integer used to distinguish edges for explicit indexing. +# +# +# +# +# +# +# +# Specifier whether each edge is non-directional, one-directional, +# or bidirectional. Use the smallest available binary representation +# which can store three different states: +# +# * 0 / state 0x00 is non-directional +# * 1 / state 0x01 is one-directional +# * 2 / state 0x02 is bi-directional +# +# +# +# +# +# +# +# Pairs of node/vertex identifier. Each pair represents the connection +# between two nodes. The order in the pair encodes eventual directionality. +# +# In the case that an edge is non- or bi-directional, storing +# node identifier in ascending order is preferred. +# +# In the case that an edge is one-directional, node identifier should be +# stored such that the identifier of the source node is the first entry +# and the identifier of the target is the second entry in the pair. +# +# +# +# +# +# +# +# +# A human-readable qualifier which type or e.g. class instance the +# edge is an instance of. +# +# +# +# +# +# +# +# A human-readable label/caption/tag of each edge. +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXgraph_node_set.yaml b/contributed_definitions/nyaml/NXgraph_node_set.yaml index 93ef93f0ba..2e8272291f 100644 --- a/contributed_definitions/nyaml/NXgraph_node_set.yaml +++ b/contributed_definitions/nyaml/NXgraph_node_set.yaml @@ -16,22 +16,24 @@ type: group NXgraph_node_set(NXobject): depends_on(NX_CHAR): doc: | - Specify which instance of :ref:`NXgraph_root` this :ref:`NXgraph_node_set` refers to. + Specify which instance of :ref:`NXgraph_root` this :ref:`NXgraph_node_set` + refers to. space(NX_CHAR): doc: | About which space does the graph make statements. enumeration: [euclidean, other] dimensionality(NX_UINT): + unit: NX_UNITLESS doc: | Dimensionality of the space about which the graph makes statements. Use only when value of the field space is euclidean. - unit: NX_UNITLESS enumeration: [1, 2, 3] cardinality(NX_UINT): + unit: NX_UNITLESS doc: | Number of nodes of the graph. - unit: NX_UNITLESS identifier_offset(NX_INT): + unit: NX_UNITLESS doc: | Integer which specifies the first index to be used for distinguishing nodes. Identifiers are defined either implicitly or explicitly. @@ -41,12 +43,13 @@ NXgraph_node_set(NXobject): For explicit indexing use the field identifier. For implicit indexing, consult :ref:`NXcg_primitive_set` to get guidance how to set identifier_offset. - unit: NX_UNITLESS identifier(NX_INT): + unit: NX_UNITLESS doc: | Integer used to distinguish nodes for explicit indexing. - unit: NX_UNITLESS - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] is_a(NX_CHAR): doc: | A human-readable qualifier which type or e.g. class instance the @@ -54,8 +57,133 @@ NXgraph_node_set(NXobject): graph, more specifically a hierarchical directed labelled property graph. Instances which are groups like :ref:`NXgraph_node_set` could have an is_a qualifier reading :ref:`NXgraph_node_set`. - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] label(NX_CHAR): doc: | A human-readable label/caption/tag of each node. - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# da6f7949b04a7662f8ba92cc2912a465f0e87eecc00a60f63d61f3cb4a1d4ca1 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The cardinality of the set, i.e. the number of nodes of the graph. +# +# +# +# +# The dimensionality of the graph. Eventually use one for categorical. +# +# +# +# +# A set of nodes representing members of a graph. +# +# Use as a direct child of an instance of :ref:`NXgraph_root`. +# Alternatively, use depends_on to specify which instance +# of NXgraph_root is defined by this instance. +# +# +# +# Specify which instance of :ref:`NXgraph_root` this :ref:`NXgraph_node_set` +# refers to. +# +# +# +# +# About which space does the graph make statements. +# +# +# +# +# +# +# +# +# Dimensionality of the space about which the graph makes statements. +# Use only when value of the field space is euclidean. +# +# +# +# +# +# +# +# +# +# Number of nodes of the graph. +# +# +# +# +# Integer which specifies the first index to be used for distinguishing +# nodes. Identifiers are defined either implicitly or explicitly. +# +# For implicit indexing the identifiers are defined on the interval +# :math:`[identifier\_offset, identifier\_offset + c - 1]`. +# +# For explicit indexing use the field identifier. For implicit indexing, +# consult :ref:`NXcg_primitive_set` to get guidance how to set identifier_offset. +# +# +# +# +# Integer used to distinguish nodes for explicit indexing. +# +# +# +# +# +# +# +# A human-readable qualifier which type or e.g. class instance the +# node is an instance of. An example: a NeXus application definition is a +# graph, more specifically a hierarchical directed labelled property graph. +# Instances which are groups like :ref:`NXgraph_node_set` could have an is_a +# qualifier reading :ref:`NXgraph_node_set`. +# +# +# +# +# +# +# +# A human-readable label/caption/tag of each node. +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXgraph_root.yaml b/contributed_definitions/nyaml/NXgraph_root.yaml index 6fce3503c9..84cc326b14 100644 --- a/contributed_definitions/nyaml/NXgraph_root.yaml +++ b/contributed_definitions/nyaml/NXgraph_root.yaml @@ -8,3 +8,41 @@ type: group NXgraph_root(NXobject): nodes(NXgraph_node_set): relation(NXgraph_edge_set): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# f05819ddfdf99b042d83339bf2e60461b2b2793bcc6eec0a37512154cab3b739 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# An instance of a graph. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXhistory.yaml b/contributed_definitions/nyaml/NXhistory.yaml index 80185ebf47..bcbd911d29 100644 --- a/contributed_definitions/nyaml/NXhistory.yaml +++ b/contributed_definitions/nyaml/NXhistory.yaml @@ -25,13 +25,12 @@ NXhistory(NXobject): doc: | Any chemical process that was performed on the physical entity prior or during the experiment. - (NXidentifier): doc: | An ID or reference to the location or a unique (globally persistent) identifier of e.g. another file which gives as many as possible details of the history event. - + # There should be more activities here, like measurement. notes(NXnote): doc: | @@ -44,7 +43,7 @@ NXhistory(NXobject): that are not well described by an existing base class definition. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 1b69316c874c12a3f6edf44311cdfa1db5b812af014068217ed20c46754bb90f +# 163311ced8903c158bd712975b26239b5c2df71cf0db35feea5825bfb927e56a # # # # # diff --git a/contributed_definitions/nyaml/NXibeam_column.yaml b/contributed_definitions/nyaml/NXibeam_column.yaml index f4e2984c6d..2721c36bff 100644 --- a/contributed_definitions/nyaml/NXibeam_column.yaml +++ b/contributed_definitions/nyaml/NXibeam_column.yaml @@ -21,7 +21,6 @@ doc: | * `E. I. Preiß et al. `_ * `J. F. Ziegler et al. `_ * `J. Lili `_ - type: group NXibeam_column(NXcomponent): (NXchamber): @@ -38,7 +37,7 @@ NXibeam_column(NXcomponent): If the emitter type is other, give further details in the description field. enumeration: [liquid_metal, plasma, gas_field, other] - description(NX_CHAR): # NXidentifier + description(NX_CHAR): doc: | Ideally, a (globally) unique persistent identifier, link, or text to a resource which gives further details. @@ -48,28 +47,30 @@ NXibeam_column(NXcomponent): Examples are gallium, helium, neon, argon, krypton, or xenon, O2+. flux(NX_NUMBER): + unit: NX_ANY doc: | Average/nominal flux - unit: NX_ANY # 1/(area*time) brightness(NX_NUMBER): + unit: NX_ANY doc: | Average/nominal brightness - unit: NX_ANY # 1/steradiant or area + # \@units: A/cm*sr # NEW ISSUE: (at which location?). current(NX_NUMBER): + unit: NX_CURRENT doc: | Charge current - unit: NX_CURRENT voltage(NX_NUMBER): + unit: NX_VOLTAGE doc: | Ion acceleration voltage upon source exit and entering the vacuum flight path. - unit: NX_VOLTAGE ion_energy_profile(NX_NUMBER): + unit: NX_ENERGY doc: | To be defined more specifically. Community suggestions are welcome. - unit: NX_ENERGY + # NEW ISSUE: details about the life/up-time of the source relevant from maintenance point of view (NXlens_em): (NXaperture): @@ -85,5 +86,142 @@ NXibeam_column(NXcomponent): :ref:`NXtransformations` should be used to specify the location or position at which details about the ion beam are probed. (NXdeflector): + # for further ideas and comments inspect version # https://github.com/FAIRmat-NFDI/nexus_definitions/commit/0682943baaef54d4a6386b5433f9721af6d3d81b + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# cf2e5b002ef93fb9014be7937c046c4ca9c28f61f5fcf898cb72fe1d7e22da79 +# +# +# +# +# +# Base class for a set of components equipping an instrument with FIB capabilities. +# +# Focused-ion-beam (FIB) capabilities turn especially scanning electron microscopes +# into specimen preparation labs. FIB is a material preparation technique whereby +# portions of the sample are illuminated with a focused ion beam with controlled +# intensity. The beam is intense enough and with sufficient ion momentum to +# remove material in a controlled manner. +# +# The fact that an electron microscope with FIB capabilities has needs a +# second gun with own relevant control circuits, focusing lenses, and other +# components, warrants the definition of an own base class to group these +# components and distinguish them from the lenses and components for creating +# and shaping the electron beam. +# +# For more details about the relevant physics and application examples +# consult the literature, for example: +# +# * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ +# * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ +# * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ +# * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ +# +# +# +# +# The source which creates the ion beam. +# +# +# +# Given name/alias for the ion gun. +# +# +# +# +# Emitter type used to create the ion beam. +# +# If the emitter type is other, give further +# details in the description field. +# +# +# +# +# +# +# +# +# +# +# Ideally, a (globally) unique persistent identifier, link, +# or text to a resource which gives further details. +# +# +# +# +# Which ionized elements or molecular ions form the beam. +# Examples are gallium, helium, neon, argon, krypton, +# or xenon, O2+. +# +# +# +# +# Average/nominal flux +# +# +# +# +# Average/nominal brightness +# +# +# +# +# +# Charge current +# +# +# +# +# Ion acceleration voltage upon source exit and +# entering the vacuum flight path. +# +# +# +# +# To be defined more specifically. Community suggestions are welcome. +# +# +# +# +# +# +# +# +# +# +# +# +# Individual characterization results for the position, shape, +# and characteristics of the ion beam. +# +# :ref:`NXtransformations` should be used to specify the location or position +# at which details about the ion beam are probed. +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXidentifier.yaml b/contributed_definitions/nyaml/NXidentifier.yaml index d16e9a269d..03b1c4ea83 100644 --- a/contributed_definitions/nyaml/NXidentifier.yaml +++ b/contributed_definitions/nyaml/NXidentifier.yaml @@ -20,7 +20,7 @@ NXidentifier(NXobject): False otherwise. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 88c35109b099e6ad0e21e8cfbf0cdd89be5ebac18967cbe6bf63d6cc9d61f770 +# c197e239497a8aa2e3ca2dd67b414da2b694e2fe8ce40c3b309232e72b75df9b # # # +# +# +# +# +# +# +# Number of images in the stack, for stacks the slowest dimension. +# +# +# +# +# Number of image points along the slow dimension (k equivalent to z). +# +# +# +# +# Number of image points along the fast dimension (j equivalent to y). +# +# +# +# +# Number of image points along the fastest dimension (i equivalent to x). +# +# +# +# +# Base class for reporting a set of images. +# +# The mostly commonly used scanning methods are supported. That is one-, +# two-, three-dimensional ROIs discretized using regular Euclidean tilings. +# +# Colloquially, an image is understood as a discretized representation of intensity distribution +# that was detected or simulated for some ROI. When discretized with regular Euclidean tilings +# the terms pixel and voxel identify the smallest discretization unit. Pixel and voxel are polygonal +# or polyhedral unit cells respectively of the underlying tiling of the ROI within the reference space. +# For all other tilings e.g. non-equispaced, the shape and size of pixel and voxel differs. Using the term +# (image) point is eventually is more appropriate for such tilings. Therefore, all docstrings in this base class +# refer to points (including pixel and voxel i.e. regular tilings). +# +# Point coordinates identify the location of the barycentre. +# +# For images in reciprocal space in practice, complex numbers are encoded via some +# formatted pair of real values. Typically, fast algorithms for computing Fourier transformations +# (FFT) are used to encode images in reciprocal (frequency) space. FFT libraries are used +# for implementing the key functionalities of these mathematical operations. +# +# Different libraries use different representations and encoding of the images. +# Details can be found in the respective sections of the typical FFT libraries documentations +# +# * `FFTW by M. Frigo and S. G. Johnson <https://www.fftw.org/fftw3_doc/Tutorial.html#Tutorial>`_ +# * `Intel MKL by the Intel Co. <https://www.intel.com/content/www/us/en/docs/onemkl/developer-reference-c/2024-2/fourier-transform-functions.html>`_ +# * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ +# * `NFFT by the Chemnitz group <https://www-user.tu-chemnitz.de/~potts/nfft/>`_ for non-equispaced computations +# +# Users are strongly advised to inspect carefully which specific conventions their library uses +# to enable storing and modifying the implementation of their code such that the serialized +# representations as they are detailed here for NeXus match. +# +# It is often the case that several images are combined using processing. In this case, +# the number of images which are combined in a collection is not necessarily the same +# for each collection. The NXimage_set base class addresses this logical distinction +# through the notation of image_identifier and group_identifier concepts. +# That is image_identifier are always counting from offset in increments of one. +# as each image is its own entity. By contrast, a group may contain no, or several images. +# Consequently, group_identifier are not required to be contiguous. +# +# +# +# Details how NXdata instance were processed from detector readings/raw data. +# +# +# +# Resolvable data artifact (e.g. file) from which all values in the :ref:`NXdata` +# instances in this :ref:`NXimage_set` were loaded during parsing. +# +# Possibility to document from which specific other serialized resource as the source +# pieces of information were processed when using NeXus as a semantic file format +# to serialize that information differently. +# +# The group in combination with an added field *absolute_path* therein adds context. +# +# +# +# Reference to a location inside the artifact that points to the specific group of values +# that were processed if the artifacts contains several groups of values and thus +# further resolving of ambiguities is required. +# +# +# +# +# +# +# Link or name of an :ref:`NXdetector` instance with which the data were +# collected. +# +# +# +# +# Program used for processing. +# +# +# +# +# +# +# One-dimensional image. +# +# +# +# Intensity for real-valued images as an alternative for real. +# Magnitude of the image intensity for complex-valued data. +# +# +# +# +# +# +# +# Real part of the image intensity per point. +# +# +# +# +# +# +# +# Imaginary part of the image intensity per point. +# +# +# +# +# +# +# +# Image intensity as a complex number as an alternative to real and +# imaginary fields if values are stored as interleaved complex numbers. +# +# +# +# +# +# +# +# Point coordinate along the fastest dimension. +# +# +# +# +# +# +# Point coordinate along the fastest dimension. +# +# +# +# +# +# +# Two-dimensional image. +# +# +# +# Intensity for real-valued images as an alternative for real. +# Magnitude of the image intensity for complex-valued data. +# +# +# +# +# +# +# +# +# Real part of the image intensity per point. +# +# +# +# +# +# +# +# +# Imaginary part of the image intensity per point. +# +# +# +# +# +# +# +# +# Image intensity as a complex number as an alternative to real and +# imaginary fields if values are stored as interleaved complex numbers. +# +# +# +# +# +# +# +# +# Point coordinate along the fast dimension. +# +# +# +# +# +# +# Point coordinate along the fast dimension. +# +# +# +# +# +# Point coordinate along the fastest dimension. +# +# +# +# +# +# +# Point coordinate along the fastest dimension. +# +# +# +# +# +# +# Three-dimensional image. +# +# +# +# Intensity for real-valued images as an alternative for real. +# Magnitude of the image intensity for complex-valued data. +# +# +# +# +# +# +# +# +# +# Real part of the image intensity per point. +# +# +# +# +# +# +# +# +# +# Imaginary part of the image intensity per point. +# +# +# +# +# +# +# +# +# +# Image intensity as a complex number as an alternative to real and +# imaginary fields if values are stored as interleaved complex numbers. +# +# +# +# +# +# +# +# +# +# Point coordinate along the slow dimension. +# +# +# +# +# +# +# Point coordinate along the slow dimension. +# +# +# +# +# +# Point coordinate along the fast dimension. +# +# +# +# +# +# +# Point coordinate along the fast dimension. +# +# +# +# +# +# Point coordinate along the fastest dimension. +# +# +# +# +# +# +# Point coordinate along the fastest dimension. +# +# +# +# +# +# +# Collection of image_1d. +# +# +# +# Intensity for real-valued images as an alternative for real. +# Magnitude of the image intensity for complex-valued data. +# +# +# +# +# +# +# +# +# Real part of the image intensity per point. +# +# +# +# +# +# +# +# +# Imaginary part of the image intensity per point. +# +# +# +# +# +# +# +# +# Image intensity as a complex number as an alternative to real and +# imaginary fields if values are stored as interleaved complex numbers. +# +# +# +# +# +# +# +# +# Group identifier +# +# +# +# +# +# +# Group identifier +# +# +# +# +# +# Image identifier +# +# +# +# +# +# +# Image identifier +# +# +# +# +# +# Point coordinate along the fastest dimension. +# +# +# +# +# +# +# Point coordinate along the fastest dimension. +# +# +# +# +# +# +# Collection of two-dimensional images. +# +# +# +# Intensity for real-valued images as an alternative for real. +# Magnitude of the image intensity for complex-valued data. +# +# +# +# +# +# +# +# +# +# Real part of the image intensity per point. +# +# +# +# +# +# +# +# +# +# Imaginary part of the image intensity per point. +# +# +# +# +# +# +# +# +# +# Image intensity as a complex number as an alternative to real and +# imaginary fields if values are stored as interleaved complex numbers. +# +# +# +# +# +# +# +# +# +# Group identifier +# +# +# +# +# +# +# Group identifier +# +# +# +# +# +# Image identifier +# +# +# +# +# +# +# Image identifier. +# +# +# +# +# +# Point coordinate along the fast dimension. +# +# +# +# +# +# +# Point coordinate along the fast dimension. +# +# +# +# +# +# Point coordinate along the fastest dimension. +# +# +# +# +# +# +# Point coordinate along the fastest dimension. +# +# +# +# +# +# +# Collection of three-dimensional images. +# +# +# +# Intensity for real-valued images as an alternative for real. +# Magnitude of the image intensity for complex-valued data. +# +# +# +# +# +# +# +# +# +# +# Real part of the image intensity per point. +# +# +# +# +# +# +# +# +# +# +# Imaginary part of the image intensity per point. +# +# +# +# +# +# +# +# +# +# +# Image intensity as a complex number as an alternative to real and +# imaginary fields if values are stored as interleaved complex numbers. +# +# +# +# +# +# +# +# +# +# +# Group identifier +# +# +# +# +# +# +# Group identifier +# +# +# +# +# +# Image identifier +# +# +# +# +# +# +# Image identifier +# +# +# +# +# +# Point coordinate along the slow dimension. +# +# +# +# +# +# +# Point coordinate along the slow dimension. +# +# +# +# +# +# Point coordinate along the fast dimension. +# +# +# +# +# +# +# Point coordinate along the fast dimension. +# +# +# +# +# +# Point coordinate along the fastest dimension. +# +# +# +# +# +# +# Point coordinate along the fastest dimension. +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXinteraction_vol_em.yaml b/contributed_definitions/nyaml/NXinteraction_vol_em.yaml index ce752c0dbd..1654ff83ce 100644 --- a/contributed_definitions/nyaml/NXinteraction_vol_em.yaml +++ b/contributed_definitions/nyaml/NXinteraction_vol_em.yaml @@ -32,3 +32,63 @@ type: group NXinteraction_vol_em(NXobject): (NXdata): (NXprocess): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 8ebfe20f6528a3e617dfdcec2c4386785e4f938b154418fb2d117fe09bc2cd2f +# +# +# +# +# +# Base class for describing the interaction volume of particle-matter interaction. +# +# Computer models like Monte Carlo or molecular dynamics / electron- or ion-beam +# interaction simulations can be used to qualify and (or) quantify the shape of +# the interaction volume. Results of such simulations can be summary statistics +# or single-particle resolved sets of trajectories. +# +# Explicit or implicit descriptions are possible. +# +# * An implicit description is via a set of electron/specimen interactions +# represented ideally as trajectory data from the computer simulation. +# * An explicit description is via an iso-contour surface using either +# a simulation grid or a triangulated surface mesh of the approximated +# iso-contour surface evaluated at specific threshold values. +# Iso-contours could be computed from electron or particle fluxes through +# an imaginary control surface (the iso-surface). +# Threshold values can be defined by particles passing through a unit control +# volume (electrons) or energy-levels (e.g. the case of X-rays). +# Details depend on the model. +# * Another explicit description is via theoretical models which may +# be relevant e.g. for X-ray spectroscopy +# +# Further details on how the interaction volume can be quantified +# is available in the literature for example: +# +# * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ +# * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ +# * `J. F. Ziegler et al. <https://doi.org/10.1007/978-3-642-68779-2_5>`_ +# +# +# +# diff --git a/contributed_definitions/nyaml/NXion.yaml b/contributed_definitions/nyaml/NXion.yaml index 73b1aa40f7..e6a036f64d 100644 --- a/contributed_definitions/nyaml/NXion.yaml +++ b/contributed_definitions/nyaml/NXion.yaml @@ -19,12 +19,13 @@ NXion(NXobject): How can the identifier be resolved? enumeration: [inchi] ion_type(NX_UINT): + unit: NX_UNITLESS doc: | Ion type (ion species) identifier. The identifier zero is reserved for the special unknown ion type. - unit: NX_UNITLESS nuclide_hash(NX_UINT): + unit: NX_UNITLESS doc: | Vector of nuclide hash values. @@ -33,9 +34,11 @@ NXion(NXobject): of each nuclide respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. The array is sorted in decreasing order. For the rationale behind this see `M. Kühbach et al. (2021) `_ - unit: NX_UNITLESS - dim: (n_ivec_max,) + dimensions: + rank: 1 + dim: [[1, n_ivec_max]] nuclide_list(NX_UINT): + unit: NX_UNITLESS doc: | Table which decodes the entries in nuclide_hash into a human-readable matrix of instances. The first column specifies the nuclide mass number, i.e. using the hashvalues @@ -50,24 +53,27 @@ NXion(NXobject): Therefore, this notation is the typical superscribed nuclide mass number and subscripted number of protons element notation e.g. :math:`^{14}C`. The array is stored matching the order of nuclide_hash. - unit: NX_UNITLESS - dim: (n_ivecmax, 2) + dimensions: + rank: 2 + dim: [[1, n_ivecmax], [2, 2]] + # color(NX_CHAR): - # doc: | - # Color code used for visualizing such ions. + # doc: | + # Color code used for visualizing such ions. volume(NX_NUMBER): + unit: NX_VOLUME doc: | Assumed volume of the ion. In atom probe microscopy this field can be used to store the reconstructed volume per ion (average) which is typically stored alongside ranging definitions. - unit: NX_VOLUME charge(NX_NUMBER): + unit: NX_CHARGE doc: | Charge of the ion. - unit: NX_CHARGE charge_state(NX_INT): + unit: NX_UNITLESS doc: | Signed charge state of the ion in multiples of electron charge. @@ -83,7 +89,6 @@ NXion(NXobject): surplus the mass-to-charge-state-ratio interval. Details on ranging definition files can be found in the literature: `M. K. Miller `_ - unit: NX_UNITLESS name(NX_CHAR): doc: | Human-readable ion type name (e.g. Al +++) @@ -94,11 +99,174 @@ NXion(NXobject): To ease automated parsing, isotope_vector should be the preferred machine-readable information used. mass_to_charge_range(NX_NUMBER): + unit: NX_ANY doc: | Associated lower (mqmin) and upper (mqmax) bounds of the mass-to-charge-state ratio interval(s) [mqmin, mqmax] (boundaries inclusive). This field is primarily of interest for documenting :ref:`NXprocess` steps of indexing a ToF/mass-to-charge state histogram. - unit: NX_ANY # u - dim: (n_ranges, 2) + dimensions: + rank: 2 + dim: [[1, n_ranges], [2, 2]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 93c7e1e4f06a32516be5fddd8175154e1e180f664bc5ebb724f6586114ea7fb3 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). +# +# +# +# +# Number of mass-to-charge-state-ratio range intervals for ion type. +# +# +# +# +# Base class for documenting the set of atoms of a (molecular) ion. +# +# +# +# A unique identifier whereby such an ion can be referred to +# via the service offered as described in identifier_type. +# +# +# +# +# How can the identifier be resolved? +# +# +# +# +# +# +# +# Ion type (ion species) identifier. +# +# The identifier zero is reserved for the special unknown ion type. +# +# +# +# +# Vector of nuclide hash values. +# +# Individual hash values :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` +# encode the number of protons :math:`Z` and the number of neutrons :math:`N` +# of each nuclide respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. +# +# The array is sorted in decreasing order. For the rationale behind this see `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ +# +# +# +# +# +# +# +# Table which decodes the entries in nuclide_hash into a human-readable matrix of instances. +# The first column specifies the nuclide mass number, i.e. using the hashvalues +# from the isotope_vector this is :math:`Z + N` or 0. The value 0 documents that no +# isotope-specific information about the element encoded is relevant. +# The second row specifies the number of protons :math:`Z` or 0. +# The value 0 in this case documents a placeholder or that no element-specific +# information is relevant. +# Taking a carbon-14 nuclide as an example the mass number is 14. +# That is encoded as a value pair (14, 6) as one row of the table. +# +# Therefore, this notation is the typical superscribed nuclide mass number +# and subscripted number of protons element notation e.g. :math:`^{14}C`. +# The array is stored matching the order of nuclide_hash. +# +# +# +# +# +# +# +# +# +# Assumed volume of the ion. +# +# In atom probe microscopy this field can be used to store the reconstructed +# volume per ion (average) which is typically stored alongside ranging +# definitions. +# +# +# +# +# Charge of the ion. +# +# +# +# +# Signed charge state of the ion in multiples of electron charge. +# +# In the example of atom probe microscopy, only positive values will be measured +# as the ions are accelerated by a negatively signed bias electric field. +# In the case that the charge state is not explicitly recoverable, the value should +# be set to zero. +# +# In atom probe microscopy this is for example the case when using +# classical ranging definition files in formats like RNG, RRNG. +# These file formats do not document the charge state explicitly +# but the number of atoms of each element per molecular ion +# surplus the mass-to-charge-state-ratio interval. +# Details on ranging definition files can be found in the literature: +# `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ +# +# +# +# +# Human-readable ion type name (e.g. Al +++) +# The string should consists of UTF-8 characters, ideally using LaTeX +# notation to specify the isotopes, ions, and charge state. +# Examples are 12C + or Al +++. +# +# To ease automated parsing, isotope_vector should be the +# preferred machine-readable information used. +# +# +# +# +# Associated lower (mqmin) and upper (mqmax) bounds of the +# mass-to-charge-state ratio interval(s) [mqmin, mqmax] +# (boundaries inclusive). This field is primarily of interest +# for documenting :ref:`NXprocess` steps of indexing a +# ToF/mass-to-charge state histogram. +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXisocontour.yaml b/contributed_definitions/nyaml/NXisocontour.yaml index 0e3171313c..a78cbaaad8 100644 --- a/contributed_definitions/nyaml/NXisocontour.yaml +++ b/contributed_definitions/nyaml/NXisocontour.yaml @@ -26,14 +26,92 @@ symbols: type: group NXisocontour(NXobject): dimensionality(NX_POSINT): + unit: NX_UNITLESS doc: | The dimensionality of the space in which the isocontour is embedded. - unit: NX_UNITLESS enumeration: [1, 2, 3] grid(NXcg_grid): doc: | The discretized grid on which the iso-contour algorithm operates. isovalue(NX_NUMBER): + unit: NX_ANY doc: | The threshold or iso-contour value. - unit: NX_ANY + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# d707db3d9f44694ffc27ccfda00d59f683d5b3bb3ce0715d460f0e05f23a5901 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality of the description. +# +# +# +# +# Base class for describing isocontouring/phase-fields in Euclidean space. +# +# Iso-contouring algorithms such as Marching Cubes and others are frequently +# used to segment d-dimensional regions at crossings of a threshold value, +# the so-called isovalue. +# +# In Computational Materials Science phase-field methods are frequently used. +# Phase-field variables are discretized frequently using regular grids. +# +# Isocontour algorithms are often used in such context to pinpoint the +# locations of microstructural features from this implicit phase-field- +# variable-value-based description. +# +# One of the key intentions of this base class is to provide a starting point +# for scientists from the phase-field community (condensed-matter physicists, +# and materials engineers) to incentivize that also phase-field (and other) +# simulation data can take advantage of NeXus base class to improve +# interoperability. +# +# +# +# The dimensionality of the space in which the isocontour is embedded. +# +# +# +# +# +# +# +# +# +# The discretized grid on which the iso-contour algorithm operates. +# +# +# +# +# The threshold or iso-contour value. +# +# +# diff --git a/contributed_definitions/nyaml/NXiv_bias.yaml b/contributed_definitions/nyaml/NXiv_bias.yaml index 8f53ae52fc..3cd766b364 100644 --- a/contributed_definitions/nyaml/NXiv_bias.yaml +++ b/contributed_definitions/nyaml/NXiv_bias.yaml @@ -129,7 +129,7 @@ NXiv_bias(NXobject): parameters are disabled. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a6b94f019c914824a8a0ec5b134141063c65e973450f5b7ec9ac852e29aac455 +# 4c5a10d05543a8750dd483e9fd47b0b61e96d7523dde8d0e613da3808bde797e # # # -# +# # # # The symbols used in the schema to specify e.g. dimensions of arrays. @@ -183,7 +183,7 @@ NXlab_electro_chemo_mechanical_preparation(NXobject): # # # -# +# # # # diff --git a/contributed_definitions/nyaml/NXlab_sample_mounting.yaml b/contributed_definitions/nyaml/NXlab_sample_mounting.yaml index 5d5a15aea0..d01f0ac6b5 100644 --- a/contributed_definitions/nyaml/NXlab_sample_mounting.yaml +++ b/contributed_definitions/nyaml/NXlab_sample_mounting.yaml @@ -55,13 +55,13 @@ NXlab_sample_mounting(NXobject): # key question is which steps has the sample experienced? # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 1edd9800a540016328456efebddc4ba62635309c1b0a8d7722d35ac79279ff05 -# +# 857fb4f773bd18a61e21bab8d7ca2b1303a65f03918445d1dce65eb66f2f6f70 +# # # -# +# # # # The symbols used in the schema to specify e.g. dimensions of arrays. @@ -111,7 +111,7 @@ NXlab_sample_mounting(NXobject): # # # -# +# # # # diff --git a/contributed_definitions/nyaml/NXlens_em.yaml b/contributed_definitions/nyaml/NXlens_em.yaml index ad26d199fd..03fa2ac275 100644 --- a/contributed_definitions/nyaml/NXlens_em.yaml +++ b/contributed_definitions/nyaml/NXlens_em.yaml @@ -10,12 +10,15 @@ doc: | see e.g. `L. Reimer `_ # has_part pole_piece https://purls.helmholtz-metadaten.de/emg/EMG_00000039 -type: group + # more consolidation to harvest from a generic component base class # with other research fields (MPES, XPS, OPT) could be useful +type: group NXlens_em(NXcomponent): + # user perspective value(NX_NUMBER): + unit: NX_ANY doc: | Descriptor for the lens excitation when the exact technical details are unknown or not directly controllable as the control software of @@ -27,7 +30,6 @@ NXlens_em(NXcomponent): setting, provided a properly working instrument and software sets the lens into a similar state to the technical level possible when no more information is available physically or accessible legally. - unit: NX_ANY mode(NX_CHAR): doc: | Descriptor for the operation mode of the lens when other details are not @@ -36,23 +38,124 @@ NXlens_em(NXcomponent): Like value, the mode can only be interpreted for a specific microscope but can still be useful to guide users as to how to repeat the measurement. + # control level perspective voltage(NX_NUMBER): + unit: NX_VOLTAGE doc: | Excitation voltage of the lens. For dipoles it is a single number. For higher order multipoles, it is an array. - unit: NX_VOLTAGE current(NX_NUMBER): + unit: NX_CURRENT doc: | Excitation current of the lens. For dipoles it is a single number. For higher-order multipoles, it is an array. - unit: NX_CURRENT + # technical design perspective type(NX_CHAR): doc: | Qualitative type of lens with respect to the number of pole pieces. enumeration: [single, double, quadrupole, hexapole, octupole, dodecapole] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 7accbc9f802621c2b2305ed6dd51f52c626a7751872bab4eb1e653881a9c1ef8 +# +# +# +# +# +# +# +# Base class for an electro-magnetic lens or a compound lens. +# +# For :ref:`NXtransformations` the origin of the coordinate system is placed +# in the center of the lens (its polepiece, pinhole, or another +# point of reference). The origin should be specified in the :ref:`NXtransformations`. +# +# For details of electro-magnetic lenses in the literature +# see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ +# +# +# +# +# Descriptor for the lens excitation when the exact technical details +# are unknown or not directly controllable as the control software of +# the microscope does not enable or was not configured to display these +# values (for end users). +# +# Although this value does not document the exact physical voltage or +# excitation, it can still give useful context to reproduce the lens +# setting, provided a properly working instrument and software sets the lens +# into a similar state to the technical level possible when no more +# information is available physically or accessible legally. +# +# +# +# +# Descriptor for the operation mode of the lens when other details are not +# directly controllable as the control software of the microscope +# does not enable or is not configured to display these values. +# +# Like value, the mode can only be interpreted for a specific microscope +# but can still be useful to guide users as to how to repeat the measurement. +# +# +# +# +# +# Excitation voltage of the lens. +# +# For dipoles it is a single number. +# For higher order multipoles, it is an array. +# +# +# +# +# Excitation current of the lens. +# +# For dipoles it is a single number. +# For higher-order multipoles, it is an array. +# +# +# +# +# +# Qualitative type of lens with respect to the number of pole pieces. +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXlens_opt.yaml b/contributed_definitions/nyaml/NXlens_opt.yaml index 43b93190c1..b116bf70fd 100644 --- a/contributed_definitions/nyaml/NXlens_opt.yaml +++ b/contributed_definitions/nyaml/NXlens_opt.yaml @@ -122,15 +122,16 @@ NXlens_opt(NXobject): The numerical aperture of the used incident light optics. magnification(NX_FLOAT): doc: | - Magnification of the lens. + + # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 691e29df6cdccccbeb03000ebbd435adb2c77135939ffb1d329d7da9d11c6539 -# +# 6ec96f848f0d15d7c310444c2c0e9e3f9987e7922ec43c98edabd520b08c2a0d +# # # -# -# +# # # # @@ -231,8 +233,10 @@ NXlens_opt(NXobject): # # # -# +# # # If the lens has a coating describe the material and its properties. # Some basic information can be found e.g. [here] @@ -309,4 +313,14 @@ NXlens_opt(NXobject): # Abbe number (or V-number) of the lens. # # +# +# +# The numerical aperture of the used incident light optics. +# +# +# +# +# +# +# # diff --git a/contributed_definitions/nyaml/NXlockin.yaml b/contributed_definitions/nyaml/NXlockin.yaml index f06cdc0654..25734f99b8 100644 --- a/contributed_definitions/nyaml/NXlockin.yaml +++ b/contributed_definitions/nyaml/NXlockin.yaml @@ -98,14 +98,14 @@ NXlockin(NXobject): Ratio of output signal amplitude to input signal amplitue (V/V). (input gain) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# c73589fddbb7b57d065748d989ab0d3d9e421b9163f8a4b4ab305b1b18bf82a8 -# +# 1590a27b15d28fbdc75ffbb13f8309ad19d255f2898af1d05a9c914c65bc7f01 +# # # -# +# # # Base classes definition for lock in devices. # @@ -171,8 +171,8 @@ NXlockin(NXobject): # # # -# The input signal (STS signal) will be demodulated, in order to determine the amplitude -# and phase at the frequency set in the Frequency field or harmonics, such as current, +# The input signal (STS signal) will be demodulated, in order to determine the amplitude +# and phase at the frequency set in the Frequency field or harmonics, such as current, # bias, et.al. # # @@ -227,7 +227,7 @@ NXlockin(NXobject): # (foreach DemodulatorChannels) # # -# +# # # Reference phase for the sine on the demodulated signal with respect to the # modulation signal. (foreach DemodulatorChannels) diff --git a/contributed_definitions/nyaml/NXmagnetic_kicker.yaml b/contributed_definitions/nyaml/NXmagnetic_kicker.yaml index 317325e62a..88805e21de 100644 --- a/contributed_definitions/nyaml/NXmagnetic_kicker.yaml +++ b/contributed_definitions/nyaml/NXmagnetic_kicker.yaml @@ -42,13 +42,13 @@ NXmagnetic_kicker(NXobject): unit: NX_VOLTAGE # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 34b7476f76592e9226269d3b02886646193836d024fce656135de8c230c8119c +# c5a9c33c0597a8133cb27df4316cf2b9125d768e65326c2bf1a947583a0c00b4 # # # +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# How many different match values does the filter specify. +# +# +# +# +# Base class of a filter to select members of a set based on their identifier. +# +# +# +# Definition of the logic what the filter yields: +# Whitelist specifies which entries with said value to include. +# Entries with all other values will be excluded. +# +# Blacklist specifies which entries with said value to exclude. +# Entries with all other values will be included. +# +# +# +# +# +# +# +# +# Array of values to filter according to method. If the match e.g. specifies +# [1, 5, 6] and method is set to whitelist, only entries with values matching +# 1, 5 or 6 will be processed. All other entries will be excluded. +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXmicrostructure.yaml b/contributed_definitions/nyaml/NXmicrostructure.yaml index 88af25f7f5..b98d12a3c0 100644 --- a/contributed_definitions/nyaml/NXmicrostructure.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure.yaml @@ -18,7 +18,7 @@ doc: | specific states or via sampling coarsely in time relative to the timescale at which the physical phenomena take place. This is typically a compromise between the research questions at hand and technical surplus practical limitations. - The term microstructural feature covers here crystals and all sorts of crystal defects within the material. + The term microstructural feature covers here crystals and all sorts of crystal defects within the material. A key challenge with the description of representations and properties of microstructural features is that features with different dimensionality exist and combinations of features of different dimensionality are frequently expected to be documented with intuitive naming conventions using flat property lists. @@ -50,15 +50,18 @@ doc: | Identifiers can be defined either implicitly or explicitly. Identifiers for implicit indexing are defined on the interval :math:`[identifier\_offset, identifier\_offset + cardinality - 1]`. + # , and Volterra line defects (dislocation, disconnection, disclination). symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. + # one-dimensional sections of either projections (see below) or true one-dimensional cuts across a volume of material n_c_one: | The number of one-dimensional crystal projections n_i_one: | The number of one-dimensional interface projections + # n__one, n__one are hypothetical scenarios such as line defect hitting right into a point # two-dimensional projections of three-dimensional objects using E. E. Underwood notation # crystals/grains are projections that are delineated by projections of interface, i.e. interface lines which meet at projections of triple lines aka triple points @@ -70,23 +73,29 @@ symbols: The number of two-dimensional triple line projections n_ld_two: | The number of two-dimensional line defect projections + # n__two is the hypothetical scenario when a point defect lies right in the projection plane # three-dimensional real objects, volumetrically characterized # crystals are delineated by interfaces that are delineated by triple lines that meet at quad junctions n_c_three: | The number of crystals (grain and sub-grain are exact synonyms for crystal). n_i_three: | - The number of interfaces (grain boundary and phase boundary are subclasses of interfaces). + The number of interfaces (grain boundary and phase boundary are subclasses of + interfaces). n_tj_three: | - The number of triple junctions (triple line is a exact synonym for triple junction, triple point is projection of a triple junction). + The number of triple junctions (triple line is a exact synonym for triple + junction, triple point is projection of a triple junction). n_qj_three: | The number of quadruple junctions. -# n_ld_three: -# The number of line defects. + + # n_ld_three: + # The number of line defects. d: | - The dimensionality of the representation that needs to match the value for configuration/dimensionality + The dimensionality of the representation that needs to match the value for + configuration/dimensionality type: group NXmicrostructure(NXobject): + # as e.g. a result of one grain reconstruction with an algorithm with MTex or the grain/phase i.e. interface network reconstruction software in commercial tools # the idea is we may wish to run as many grain reconstructions as we want and add details about the processing used for each of them if needed comment(NX_CHAR): @@ -96,25 +105,25 @@ NXmicrostructure(NXobject): doc: | ISO8601 with offset to local time zone included when a timestamp is required. time(NX_NUMBER): + unit: NX_TIME doc: | Measured or simulated physical time stamp for this microstructure snapshot. Not to be confused with wall-clock timing or profiling data. - unit: NX_TIME iteration(NX_INT): + unit: NX_UNITLESS doc: | Iteration or increment counter. - unit: NX_UNITLESS configuration(NXprocess): doc: | Group where to store details about the configuration and parameterization of algorithms used whereby microstructural features were identified. dimensionality(NX_POSINT): + unit: NX_UNITLESS doc: | Dimensionality of Euclidean space in which the analysis is performed. This field can be used e.g. by a research data management system to identify if the description specifies one-, two-, or three-dimensional microstructural representations. - unit: NX_UNITLESS enumeration: [1, 2, 3] algorithm(NX_CHAR): doc: | @@ -123,17 +132,18 @@ NXmicrostructure(NXobject): * Disorientation clustering groups nearby material points based on their crystallographic disorientation * Fast multiscale clustering based on `D. Kushnir et al. `_ * Markov chain clustering `F. Niessen et al. `_ - + # could also be used to specify algorithms for precipitate detection enumeration: [unknown, disorientation_clustering, fast_multiscale_clustering, markov_chain_clustering] disorientation_threshold(NX_NUMBER): + unit: NX_ANGLE doc: | Threshold to define at which disorientation angle to assume two crystalline regions have a significant orientation difference that warrants to assume that there exists an interface between the two regions. - unit: NX_ANGLE (NXprogram): doc: | The program with which the microstructure was reconstructed. + # use controlled vocabulary terms grid, point, line, surface, volume, use singular term when instantiating (NXcg_grid): (NXcg_point_set): @@ -141,6 +151,7 @@ NXmicrostructure(NXobject): (NXcg_triangle_set): (NXcg_polygon_set): (NXcg_polyhedron_set): + # constructive solid geometry to describe curved features # (NXcsg): # (NXcontinuous_function): @@ -158,6 +169,7 @@ NXmicrostructure(NXobject): Crystals are represented by a set of pixel, voxel, or polygons and their polyline boundaries. In rare cases the volume bounded gets represented using constructive solid geometry approaches. + # maybe some enum what this is representation(NX_CHAR): doc: | @@ -170,62 +182,78 @@ NXmicrostructure(NXobject): which represent the geometrical entities of the discretization. number_of_crystals(NX_UINT): + unit: NX_UNITLESS doc: | How many crystals are distinguished. Crystals are listed irrespective of the phase to which these are assigned. - unit: NX_UNITLESS number_of_phases(NX_UINT): + unit: NX_UNITLESS doc: | How many phases are distinguished. Phases are typically distinguished based on statistical thermodynamics argument and crystal structure. - unit: NX_UNITLESS crystal_identifier_offset(NX_INT): + unit: NX_UNITLESS doc: | First identifier whereby to identify crystals implicitly. - unit: NX_UNITLESS crystal_identifier(NX_INT): + unit: NX_UNITLESS doc: | Identifier whereby to identify each crystal explicitly. - unit: NX_UNITLESS - dim: (i,) # with i = n_c_one or n_c_two or n_c_three + dimensions: + rank: 1 + dim: [[1, i]] phase_identifier_offset(NX_INT): + unit: NX_UNITLESS doc: | First identifier whereby to identify phases implicitly. - unit: NX_UNITLESS phase_identifier(NX_INT): + unit: NX_UNITLESS doc: | Identifier whereby to identify phase for each crystal explicitly. - unit: NX_UNITLESS - dim: (i,) # with i = n_c_one or n_c_two or n_c_three for all use of i in of fields of group crystal + dimensions: + rank: 1 + dim: [[1, i]] + # EXAMPLES FOR DESCRIPTOR VALUES, SUMMARY STATISTICS boundary_contact(NX_BOOLEAN): doc: | - True or false value, one for each crystal, to communicate whether that feature makes contact with the edge of the ROI. - dim: (i,) + True or false value, one for each crystal, to communicate whether that feature + makes contact with the edge of the ROI. + dimensions: + rank: 1 + dim: [[1, i]] orientation_spread(NX_NUMBER): + unit: NX_ANGLE doc: | Average disorientation angle for each crystal between individual orientations of that crystal evaluated as a summary statistic for all probed positions vs the average disorientation of that crystal. - unit: NX_ANGLE - dim: (i,) + dimensions: + rank: 1 + dim: [[1, i]] length(NX_NUMBER): + unit: NX_LENGTH doc: | Length of each crystal - unit: NX_LENGTH # m - dim: (i,) + dimensions: + rank: 1 + dim: [[1, i]] area(NX_NUMBER): + unit: NX_AREA doc: | Area of each crystal. - unit: NX_AREA # m^2 - dim: (i,) + dimensions: + rank: 1 + dim: [[1, i]] volume(NX_NUMBER): + unit: NX_VOLUME doc: | Volume of each crystal - unit: NX_VOLUME # m^3 - dim: (i,) + dimensions: + rank: 1 + dim: [[1, i]] interface(NXobject): doc: | One- or two-dimensional projections or three-dimensional representation of interfaces @@ -245,72 +273,97 @@ NXmicrostructure(NXobject): which represent the geometrical entities of the discretization. number_of_interfaces(NX_UINT): + unit: NX_UNITLESS doc: | How many interfaces are distinguished. - unit: NX_UNITLESS identifier_offset(NX_INT): + unit: NX_UNITLESS doc: | First identifier whereby to identify interfaces implicitly. - unit: NX_UNITLESS identifier(NX_INT): + unit: NX_UNITLESS doc: | Identifier whereby to identify each interface explicitly. - unit: NX_UNITLESS - dim: (i,) # with i == n_i_one or n_i_two or n_i_three for all fields of group interface + dimensions: + rank: 1 + dim: [[1, i]] + # topological view, interface specification through the the pair of crystals sharing an interface crystal_identifier(NX_INT): + unit: NX_UNITLESS doc: | Set of pairs of crystal_identifier for each interface. - unit: NX_UNITLESS - dim: (i, 2) - \@use_these(NX_CHAR): + dimensions: + rank: 2 + dim: [[1, i], [2, 2]] + \@use_these: + type: NX_CHAR doc: | The specific identifiers whereby to resolve ambiguities. phase_identifier(NX_INT): + unit: NX_UNITLESS doc: | Set of pairs of phase_identifier for each interface. - unit: NX_UNITLESS - dim: (i, 2) - \@use_these(NX_CHAR): + dimensions: + rank: 2 + dim: [[1, i], [2, 2]] + \@use_these: + type: NX_CHAR doc: | The specific identifiers whereby to resolve ambiguities. + # topological view, interface specification through the pair of triple line projections (i.e. triple points) adjoining the interface triple_junction_identifier(NX_INT): + unit: NX_UNITLESS doc: | Set of pairs of triple_junction_identifier for each interface. - unit: NX_UNITLESS - dim: (i, 2) # with i == n_i_two but junctions can be points or lines! - \@use_these(NX_CHAR): + dimensions: + rank: 2 + dim: [[1, i], [2, 2]] + \@use_these: + type: NX_CHAR doc: | The specific identifiers whereby to resolve ambiguities. + # EXAMPLES FOR DESCRIPTOR VALUES boundary_contact(NX_BOOLEAN): doc: | - True or false value, one for each crystal, to communicate whether that feature makes contact with the edge of the ROI. - dim: (i,) + True or false value, one for each crystal, to communicate whether that feature + makes contact with the edge of the ROI. + dimensions: + rank: 1 + dim: [[1, i]] surface_energy(NX_NUMBER): + unit: NX_ANY doc: | Gibbs free surface energy for each interface. - unit: NX_ANY # J/m^2 - dim: (i,) + dimensions: + rank: 1 + dim: [[1, i]] mobility(NX_NUMBER): + unit: NX_ANY doc: | Non-intrinsic mobility of each interface. - unit: NX_ANY # m^4/Js - dim: (i,) + dimensions: + rank: 1 + dim: [[1, i]] length(NX_NUMBER): + unit: NX_LENGTH doc: | The length of each interface if only projections are available. This is not necessarily the same as the length of the individual polyline segments whereby the interface is discretized. - unit: NX_LENGTH - dim: (i,) + dimensions: + rank: 1 + dim: [[1, i]] area(NX_NUMBER): + unit: NX_AREA doc: | The surface area of all interfaces. - unit: NX_AREA - dim: (i,) + dimensions: + rank: 1 + dim: [[1, i]] triple_junction(NXobject): doc: | Projections or representations of junctions at which three interfaces meet. @@ -331,85 +384,119 @@ NXmicrostructure(NXobject): which represent the geometrical entities of the discretization. number_of_junctions(NX_UINT): + unit: NX_UNITLESS doc: | Number of triple junctions. - unit: NX_UNITLESS identifier_offset(NX_INT): + unit: NX_UNITLESS doc: | First identifier to identify triple junctions implicitly. - unit: NX_UNITLESS identifier(NX_INT): + unit: NX_UNITLESS doc: | Identifier to identify each triple junction explicitly. - unit: NX_UNITLESS - dim: (i,) # with i == n_tj_one, n_tj_two, n_tj_three for all fields in group triple_junction + dimensions: + rank: 1 + dim: [[1, i]] + # various strategies are used to talk about aspects of triple junctions, some examples follow # example i) triple points as projections of triple lines have locations location(NX_INT): - doc: | - Set of identifier for positions whereby to identify the location of each junction. unit: NX_UNITLESS - dim: (i,) - \@use_these(NX_CHAR): + doc: | + Set of identifier for positions whereby to identify the location of each + junction. + dimensions: + rank: 1 + dim: [[1, i]] + \@use_these: + type: NX_CHAR doc: | The specific identifiers whereby to resolve ambiguities. position(NX_INT): + unit: NX_LENGTH doc: | Explicit positions. - unit: NX_LENGTH - dim: (i, d) + dimensions: + rank: 2 + dim: [[1, i], [2, d]] crystal_identifier(NX_INT): - doc: | - Set of tuples of identifier of crystals connected to the junction for each triple junction. unit: NX_UNITLESS - dim: (i, 3) + doc: | + Set of tuples of identifier of crystals connected to the junction for each + triple junction. + dimensions: + rank: 2 + dim: [[1, i], [2, 3]] + # example ii) three interfaces (maybe projections of them) meet at a triple junction interface_identifier(NX_INT): - doc: | - Set of tuples of identifier of interfaces connected to the junction for each triple junction. unit: NX_UNITLESS - dim: (i, 3) - \@use_these(NX_CHAR): + doc: | + Set of tuples of identifier of interfaces connected to the junction for each + triple junction. + dimensions: + rank: 2 + dim: [[1, i], [2, 3]] + \@use_these: + type: NX_CHAR doc: | The specific interface identifiers whereby to resolve ambiguities. + # example iii) three polyline segments meet at a triple junction, polyline segments of discretized interface segments polyline_identifier(NX_INT): - doc: | - Set of tuples of identifier for polyline segments connected to the junction for each triple junction. unit: NX_UNITLESS - dim: (i, 3) - \@use_these(NX_CHAR): + doc: | + Set of tuples of identifier for polyline segments connected to the junction for + each triple junction. + dimensions: + rank: 2 + dim: [[1, i], [2, 3]] + \@use_these: + type: NX_CHAR doc: | The specific polyline identifiers whereby to resolve ambiguities. + # example iv) e.g. crystals of three different phases meet at a triple junction # EXAMPLES FOR DESCRIPTOR VALUES boundary_contact(NX_BOOLEAN): doc: | - True or false value, one for each crystal, to communicate whether that feature makes contact with the edge of the ROI. - dim: (i,) + True or false value, one for each crystal, to communicate whether that feature + makes contact with the edge of the ROI. + dimensions: + rank: 1 + dim: [[1, i]] line_energy(NX_NUMBER): + unit: NX_ANY doc: | Specific line energy of each triple junction - unit: NX_ANY - dim: (i,) + dimensions: + rank: 1 + dim: [[1, i]] mobility(NX_NUMBER): + unit: NX_ANY doc: | Non-intrinsic mobility of each triple junction. - unit: NX_ANY - dim: (i,) + dimensions: + rank: 1 + dim: [[1, i]] length(NX_NUMBER): + unit: NX_LENGTH doc: | The length of each triple junction. This is not necessarily the same as the length of the individual polyline segments whereby the junction is discretized. - unit: NX_LENGTH - dim: (i,) + dimensions: + rank: 1 + dim: [[1, i]] volume(NX_NUMBER): + unit: NX_VOLUME doc: | The volume of the each triple junction - unit: NX_VOLUME - dim: (i,) + dimensions: + rank: 1 + dim: [[1, i]] quadruple_junction(NXobject): doc: | Quadruple junctions as a region where four crystals meet. @@ -421,82 +508,900 @@ NXmicrostructure(NXobject): * :ref:`NXcg_point_set` * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks - number_of_junctions(NX_UINT): + unit: NX_UNITLESS doc: | Number of quadruple junctions. - unit: NX_UNITLESS identifier_offset(NX_INT): + unit: NX_UNITLESS doc: | First identifier to identify quadruple junctions implicitly. - unit: NX_UNITLESS identifier(NX_INT): + unit: NX_UNITLESS doc: | Identifier to identify each quadruple junction explicitly. - unit: NX_UNITLESS - dim: (i,) # with i == n_qj_three or n_qj_two + dimensions: + rank: 1 + dim: [[1, i]] + # different scenarios can be envised how quadruple_junctions are discussed # example i) quadruple point locations explicitly location(NX_INT): - doc: | - Set of identifier for positions whereby to identify the location of each junction. unit: NX_UNITLESS - dim: (i,) - \@use_these(NX_CHAR): + doc: | + Set of identifier for positions whereby to identify the location of each + junction. + dimensions: + rank: 1 + dim: [[1, i]] + \@use_these: + type: NX_CHAR doc: | The specific point identifier whereby to resolve ambiguities. position(NX_INT): + unit: NX_LENGTH doc: | Explicit positions. - unit: NX_LENGTH - dim: (i, 3) + dimensions: + rank: 2 + dim: [[1, i], [2, 3]] + # example ii) four crystals meet at a quadruple junction crystal_identifier(NX_INT): - doc: | - Set of tuples of identifier of crystals connected to the junction for each junction. unit: NX_UNITLESS - dim: (i, 4) - \@use_these(NX_CHAR): + doc: | + Set of tuples of identifier of crystals connected to the junction for each + junction. + dimensions: + rank: 2 + dim: [[1, i], [2, 4]] + \@use_these: + type: NX_CHAR doc: | - The specific identifier to instances of crystal identifiers whereby to resolve ambiguities. + The specific identifier to instances of crystal identifiers whereby to resolve + ambiguities. interface_identifier(NX_INT): - doc: | - Set of tuples of identifier of interfaces connected to the junction for each junction. unit: NX_UNITLESS - dim: (i, 4) - \@use_these(NX_CHAR): + doc: | + Set of tuples of identifier of interfaces connected to the junction for each + junction. + dimensions: + rank: 2 + dim: [[1, i], [2, 4]] + \@use_these: + type: NX_CHAR doc: | - The specific identifier to instances of interface identifiers whereby to resolve ambiguities. + The specific identifier to instances of interface identifiers whereby to resolve + ambiguities. + # example iii) e.g. three triple lines meet at a quadruple junction triple_junction_identifier(NX_INT): - doc: | - Set of tuples of identifier for triple junctions connected to the junction for each quadruple junction. unit: NX_UNITLESS - dim: (i, 3) - \@use_these(NX_CHAR): + doc: | + Set of tuples of identifier for triple junctions connected to the junction for + each quadruple junction. + dimensions: + rank: 2 + dim: [[1, i], [2, 3]] + \@use_these: + type: NX_CHAR doc: | - The specific identifier to instances of triple junction identifiers whereby to resolve ambiguities. + The specific identifier to instances of triple junction identifiers whereby to + resolve ambiguities. + # example iv) crystals of eventually four different phases meet at a quadruple junction phase_identifier(NX_INT): - doc: | - Set of tuples of identifier for phases of crystals connected to the junction for each quadruple junction. unit: NX_UNITLESS - dim: (i, 4) - \@use_these(NX_CHAR): + doc: | + Set of tuples of identifier for phases of crystals connected to the junction for + each quadruple junction. + dimensions: + rank: 2 + dim: [[1, i], [2, 4]] + \@use_these: + type: NX_CHAR doc: | - The specific identifier to instances of phase identifier whereby to resolve ambiguities. + The specific identifier to instances of phase identifier whereby to resolve + ambiguities. + # EXAMPLES FOR DESCRIPTOR VALUES boundary_contact(NX_BOOLEAN): doc: | - True or false value, one for each crystal, to communicate whether that feature makes contact with the edge of the ROI. - dim: (i,) + True or false value, one for each crystal, to communicate whether that feature + makes contact with the edge of the ROI. + dimensions: + rank: 1 + dim: [[1, i]] energy(NX_NUMBER): + unit: NX_ANY doc: | Energy of the quadruple_junction as a defect. - unit: NX_ANY - dim: (i,) + dimensions: + rank: 1 + dim: [[1, i]] mobility(NX_NUMBER): + unit: NX_ANY doc: | Non-intrinsic mobility of each quadruple_junction. - unit: NX_ANY - dim: (i,) + dimensions: + rank: 1 + dim: [[1, i]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 99f7c16210448edd29caaa14f77afe6d4c0920fb7150bea6407d096d7b98a513 +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# +# The number of one-dimensional crystal projections +# +# +# +# +# The number of one-dimensional interface projections +# +# +# +# +# +# The number of two-dimensional crystal projections +# +# +# +# +# The number of two-dimensional interface projections +# +# +# +# +# The number of two-dimensional triple line projections +# +# +# +# +# The number of two-dimensional line defect projections +# +# +# +# +# +# The number of crystals (grain and sub-grain are exact synonyms for crystal). +# +# +# +# +# The number of interfaces (grain boundary and phase boundary are subclasses of +# interfaces). +# +# +# +# +# The number of triple junctions (triple line is a exact synonym for triple +# junction, triple point is projection of a triple junction). +# +# +# +# +# The number of quadruple junctions. +# +# +# +# +# +# The dimensionality of the representation that needs to match the value for +# configuration/dimensionality +# +# +# +# +# Base class to describe a microstructure, its structural aspects, associated descriptors, properties. +# +# Whether one uses a continuum or atomic scale description of materials, these are always a model only of +# the true internal structure of a material. Such models are useful as they enable a coarse-graining and +# categorizing of properties and representational aspects from which measured or simulated descriptions +# can be correlated with properties, i.e. descriptor values. +# +# Keep in mind that most specimens are thermo-chemo-mechanically processed prior characterization. +# Therefore, the characterized microstructure may not have probed the same structure as of the untreated +# sample from which the region-of-interests on the specimen were sampled. +# +# Fields such as time and increment enable a quantification of the spatiotemporal evolution of a materials' +# structure by using multiple instances of NXmicrostructure. Both measurements and simulation virtually +# always sample this evolution. Most microscopy techniques support to generate only a two-dimensional +# representation (projection) of the characterized material. Often materials are characterized only for +# specific states or via sampling coarsely in time relative to the timescale at which the +# physical phenomena take place. This is typically a compromise between the research questions at hand and technical surplus practical limitations. +# +# The term microstructural feature covers here crystals and all sorts of crystal defects within the material. +# A key challenge with the description of representations and properties of microstructural features is that +# features with different dimensionality exist and combinations of features of different dimensionality are +# frequently expected to be documented with intuitive naming conventions using flat property lists. +# For these key-value dictionaries often folksonomies are used. These can be based on ad hoc documentation +# of such dictionaries in the literature and the metadata section of public data repositories. +# +# NXmicrostructure is an attempt to standardize these descriptions stronger. +# +# The descriptive variety is large especially for junctions. Like crystals and interfaces, junctions are features in +# three-dimensional Euclidean space even if they are formed maybe only through a monolayer or pearl chain of atoms. +# Either way the local atomic and electronic environment is different compared to the situation of an ideal crystal, +# which gives typically rise to a plethora of configurations of which some yield useful properties. +# +# Like crystals and interfaces, junctions are assumed to represent groups of atoms that have specific descriptor values +# which are different to other features. Taking an example, a triple junction is practically a three-dimensional defect as its atoms +# are arranged in three-dimensional space but the characteristics of that defect can often be reduced to a lower-dimensional +# description such as a triple point or a triple line. Therefore, different representations can be used to describe the location, +# shape, and structure of the defect. As different types of crystal defects can interact, there is a substantial number of +# in principle characterizable and representable objects. Take again a triple line as an example. It is a tubular feature built from three +# adjoining interfaces. However, dislocations as line defects can interact with triple lines. Therefore, one can also argue that +# along a triple line there can be dislocation-line-triple-line junctions, likewise dislocations form own junctions. +# +# It is not the aim of this base class to cover all these cases, rather this base class currently provides examples how the +# typically most relevant types of features can be represented using a combination of base classes in NeXus. Currently, +# these are crystals, interfaces, triple lines, quadruple junctions. +# +# The description attempt here took inspiration from `E. E. Underwood <https://doi.org/10.1111/j.1365-2818.1972.tb03709.x>`_ +# and E. E. Underwood's book on Quantitative Stereology published 1970 to categorize features based on their dimensionality. +# +# Identifiers can be defined either implicitly or explicitly. Identifiers for implicit indexing are defined +# on the interval :math:`[identifier\_offset, identifier\_offset + cardinality - 1]`. +# +# +# +# +# Discouraged free-text field for leaving comments. +# +# +# +# +# ISO8601 with offset to local time zone included when a timestamp is required. +# +# +# +# +# Measured or simulated physical time stamp for this microstructure snapshot. +# Not to be confused with wall-clock timing or profiling data. +# +# +# +# +# Iteration or increment counter. +# +# +# +# +# Group where to store details about the configuration and parameterization of algorithms +# used whereby microstructural features were identified. +# +# +# +# Dimensionality of Euclidean space in which the analysis is performed. +# +# This field can be used e.g. by a research data management system to identify +# if the description specifies one-, two-, or three-dimensional microstructural representations. +# +# +# +# +# +# +# +# +# +# Algorithm whereby interfaces between crystals were reconstructed. +# +# * Disorientation clustering groups nearby material points based on their crystallographic disorientation +# * Fast multiscale clustering based on `D. Kushnir et al. <https://doi.org/10.1016/j.patcog.2006.04.007>`_ +# * Markov chain clustering `F. Niessen et al. <https://doi.org/10.1107/S1600576721011560>`_ +# +# +# +# +# +# +# +# +# +# +# +# Threshold to define at which disorientation angle to assume two crystalline regions have a significant +# orientation difference that warrants to assume that there exists an interface between the two regions. +# +# +# +# +# The program with which the microstructure was reconstructed. +# +# +# +# +# +# +# +# +# +# +# +# +# +# One- or two-dimensional projections, or three-dimensional representations of crystals. +# +# An example for a volume bounded by other crystal defects. Crystals can be grains of +# different phases, precipitates, dispersoids; there are many terms used specifically in +# the materials engineering community. +# +# Typically, crystals are measured on the surface of a sample via optical or electron microscopy. +# Using X-ray diffraction methods crystals can be observed in bulk specimens. +# +# Crystals are represented by a set of pixel, voxel, or polygons and their polyline boundaries. +# In rare cases the volume bounded gets represented using constructive solid geometry approaches. +# +# +# +# +# Reference to an instance of: +# +# * :ref:`NXcg_polyline_set` for a one-dimensional representation as only a projection is available (like in linear intercept analysis) +# * :ref:`NXcg_polygon_set` for a two-dimensional representation as only a projection is available (like in most experiments) +# * :ref:`NXcg_polyhedron_set` or :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions +# (like in computer simulations or 3D experiments) +# +# which represent the geometrical entities of the discretization. +# +# +# +# +# How many crystals are distinguished. +# +# Crystals are listed irrespective of the phase to which these are assigned. +# +# +# +# +# How many phases are distinguished. +# +# Phases are typically distinguished based on statistical thermodynamics argument and crystal structure. +# +# +# +# +# First identifier whereby to identify crystals implicitly. +# +# +# +# +# Identifier whereby to identify each crystal explicitly. +# +# +# +# +# +# +# +# First identifier whereby to identify phases implicitly. +# +# +# +# +# Identifier whereby to identify phase for each crystal explicitly. +# +# +# +# +# +# +# +# +# True or false value, one for each crystal, to communicate whether that feature +# makes contact with the edge of the ROI. +# +# +# +# +# +# +# +# Average disorientation angle for each crystal between individual orientations +# of that crystal evaluated as a summary statistic for all probed positions vs the +# average disorientation of that crystal. +# +# +# +# +# +# +# +# Length of each crystal +# +# +# +# +# +# +# +# Area of each crystal. +# +# +# +# +# +# +# +# Volume of each crystal +# +# +# +# +# +# +# +# +# One- or two-dimensional projections or three-dimensional representation of interfaces +# between crystals as topological entities equivalent to dual_junctions. +# +# An example for a surface defect. Most important are interfaces such as grain and phase boundaries +# but factually interfaces also exist between the environment and crystals exposed at the +# surface of the specimen or internal surfaces like between crystals, cracks, or pores. +# +# +# +# Reference to an instance of: +# +# * :ref:`NXcg_point_set` for a one-dimensional representation as only a projection is available (as in linear intercept analyses) +# * :ref:`NXcg_polyline_set` or :ref:`NXcg_polygon_set` for a two-dimensional representation as only a projection is available (like in most experiments) +# * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks +# (like in computer simulations or 3D experiments) +# +# which represent the geometrical entities of the discretization. +# +# +# +# +# How many interfaces are distinguished. +# +# +# +# +# First identifier whereby to identify interfaces implicitly. +# +# +# +# +# Identifier whereby to identify each interface explicitly. +# +# +# +# +# +# +# +# +# Set of pairs of crystal_identifier for each interface. +# +# +# +# +# +# +# +# The specific identifiers whereby to resolve ambiguities. +# +# +# +# +# +# Set of pairs of phase_identifier for each interface. +# +# +# +# +# +# +# +# The specific identifiers whereby to resolve ambiguities. +# +# +# +# +# +# +# Set of pairs of triple_junction_identifier for each interface. +# +# +# +# +# +# +# +# The specific identifiers whereby to resolve ambiguities. +# +# +# +# +# +# +# True or false value, one for each crystal, to communicate whether that feature +# makes contact with the edge of the ROI. +# +# +# +# +# +# +# +# Gibbs free surface energy for each interface. +# +# +# +# +# +# +# +# Non-intrinsic mobility of each interface. +# +# +# +# +# +# +# +# The length of each interface if only projections are available. +# +# This is not necessarily the same as the length of the individual +# polyline segments whereby the interface is discretized. +# +# +# +# +# +# +# +# The surface area of all interfaces. +# +# +# +# +# +# +# +# +# Projections or representations of junctions at which three interfaces meet. +# +# An example for a line defect. Triple junctions are characterized as triple lines or triple points as their projections, +# or junctions observed between crystals (at the specimen surface exposed to an environment) +# (including wetting phenomena) or inside the specimen (crack, pores). +# +# +# +# Reference to an instance of: +# +# * :ref:`NXcg_point_set` for a one-dimensional representation as only a projection is available (like in most experiments) +# * :ref:`NXcg_polyline_set` for a two-dimensional representation as only a projection is available +# * :ref:`NXcg_polygon_set` for a two-dimensional representation in the (seldom) case of sufficient spatial resolution +# and the line in the projection plane or cases where triple junction locations are approximated e.g. using a set of triangles +# * :ref:`NXcg_polyhedron_set` for a three-dimensional representation via e.g. a representation of Voronoi cells about atoms +# * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks +# +# which represent the geometrical entities of the discretization. +# +# +# +# +# Number of triple junctions. +# +# +# +# +# First identifier to identify triple junctions implicitly. +# +# +# +# +# Identifier to identify each triple junction explicitly. +# +# +# +# +# +# +# +# +# Set of identifier for positions whereby to identify the location of each +# junction. +# +# +# +# +# +# +# The specific identifiers whereby to resolve ambiguities. +# +# +# +# +# +# Explicit positions. +# +# +# +# +# +# +# +# +# Set of tuples of identifier of crystals connected to the junction for each +# triple junction. +# +# +# +# +# +# +# +# +# +# Set of tuples of identifier of interfaces connected to the junction for each +# triple junction. +# +# +# +# +# +# +# +# The specific interface identifiers whereby to resolve ambiguities. +# +# +# +# +# +# +# Set of tuples of identifier for polyline segments connected to the junction for +# each triple junction. +# +# +# +# +# +# +# +# The specific polyline identifiers whereby to resolve ambiguities. +# +# +# +# +# +# +# True or false value, one for each crystal, to communicate whether that feature +# makes contact with the edge of the ROI. +# +# +# +# +# +# +# +# Specific line energy of each triple junction +# +# +# +# +# +# +# +# Non-intrinsic mobility of each triple junction. +# +# +# +# +# +# +# +# The length of each triple junction. +# +# This is not necessarily the same as the length of the individual +# polyline segments whereby the junction is discretized. +# +# +# +# +# +# +# +# The volume of the each triple junction +# +# +# +# +# +# +# +# +# Quadruple junctions as a region where four crystals meet. +# +# An example for a point defect. +# +# +# +# Reference to an instance of: +# +# * :ref:`NXcg_point_set` +# * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks +# +# +# +# +# Number of quadruple junctions. +# +# +# +# +# First identifier to identify quadruple junctions implicitly. +# +# +# +# +# Identifier to identify each quadruple junction explicitly. +# +# +# +# +# +# +# +# +# Set of identifier for positions whereby to identify the location of each +# junction. +# +# +# +# +# +# +# The specific point identifier whereby to resolve ambiguities. +# +# +# +# +# +# Explicit positions. +# +# +# +# +# +# +# +# +# +# Set of tuples of identifier of crystals connected to the junction for each +# junction. +# +# +# +# +# +# +# +# The specific identifier to instances of crystal identifiers whereby to resolve +# ambiguities. +# +# +# +# +# +# Set of tuples of identifier of interfaces connected to the junction for each +# junction. +# +# +# +# +# +# +# +# The specific identifier to instances of interface identifiers whereby to resolve +# ambiguities. +# +# +# +# +# +# +# Set of tuples of identifier for triple junctions connected to the junction for +# each quadruple junction. +# +# +# +# +# +# +# +# The specific identifier to instances of triple junction identifiers whereby to +# resolve ambiguities. +# +# +# +# +# +# +# Set of tuples of identifier for phases of crystals connected to the junction for +# each quadruple junction. +# +# +# +# +# +# +# +# The specific identifier to instances of phase identifier whereby to resolve +# ambiguities. +# +# +# +# +# +# +# True or false value, one for each crystal, to communicate whether that feature +# makes contact with the edge of the ROI. +# +# +# +# +# +# +# +# Energy of the quadruple_junction as a defect. +# +# +# +# +# +# +# +# Non-intrinsic mobility of each quadruple_junction. +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml index befbff7893..39de6ebda0 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml @@ -4,14 +4,16 @@ doc: | GraGLeS is a continuum-scale model for shared-memory-parallelized simulations of the isothermal evolution of 2D and 3D grain boundary networks with a level-set approach. - CPU parallelization is achieved with OpenMP. + CPU parallelization is achieved with OpenMP. The code has been implemented by C. Mießen in the group of G. Gottstein at the Institute für Metallkunde und Metallphysik, RWTH Aachen University. Details of the model are summarized in `C. Mießen `_. + # symbols: # type: group +type: group NXmicrostructure_gragles_config(NXobject): (NXentry): definition(NX_CHAR): @@ -28,7 +30,7 @@ NXmicrostructure_gragles_config(NXobject): profiling(NXcs_profiling): exists: optional (NXuser): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] program1(NXprogram): program_name: \@version: @@ -39,24 +41,27 @@ NXmicrostructure_gragles_config(NXobject): doc: | Programs and libraries representing the computational environment programID(NXprogram): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR discretization(NXmicrostructure): + # [read_from_file] # poisson_voronoi_tessellation # 0, E_READ_FROM_FILE, 1, E_GENERATE_WITH_VORONOY, 2, E_READ_VERTEX, // The edges need to be ordered 3, E_GENERATE_TESTCASE, 4, E_READ_VOXELIZED_MICROSTRUCTURE # read the next three from input file # Microstructure.SimID.10.GrainIDs.2D.1188.raw all in config file # Microstructure.SimID.10.uds # 0 0, E_CUBIC, 1, E_HEXAGONAL fish from config file - grid(NXserialized): # take generated structure as input as code refactoring removed microstructure synthesis related parts + grid(NXserialized): doc: | From which file should the microstructure be instantiated. type: path: algorithm: checksum: - edge_length(NX_FLOAT): # 4.2037e-3 + edge_length(NX_FLOAT): + unit: NX_LENGTH doc: | The formulation of mean curvature flow in the GraGLeS model is scale invariant. Therefore, the discretization has to be scaled to the actual physical length @@ -67,7 +72,6 @@ NXmicrostructure_gragles_config(NXobject): Edge_length is the length of the entire domain along its edge not the length of the Wigner-Seitz cell about each material point! - unit: NX_LENGTH sampling(NXobject): doc: | Configuration when snapshots of the system should be taken. @@ -75,61 +79,63 @@ NXmicrostructure_gragles_config(NXobject): Keep in mind that essentially geometry snapshot data store the polylines and polyhedra of all grains which can take substantial disk space. - system(NX_UINT): # 1 + system(NX_UINT): + unit: NX_UNITLESS doc: | Generate a snapshot of the properties of the grains to follow the evolution of the microstructure every :math:`n`-th iteration. Setting zero causes that no property snapshots are taken. + geometry(NX_UINT): unit: NX_UNITLESS - geometry(NX_UINT): # 100 doc: | Generate a snapshot of the geometry of the entire grain boundary network every :math:`n`-th iteration. Setting zero instructs to store no geometry data. - unit: NX_UNITLESS - # 31 no more sampling - # 1 - + + # 31 no more sampling + # 1 simulation_control(NXobject): doc: | Configuration when the simulation should be stopped in a controlled manner. Whichever criterion is fulfilled first triggers the controlled stop of and termination of GraGLeS. - number_of_grains(NX_UINT): # 1000 + number_of_grains(NX_UINT): + unit: NX_UNITLESS doc: | The simulation stops if the total number of grains becomes smaller than this criterion. + number_of_iterations(NX_UINT): unit: NX_UNITLESS - number_of_iterations(NX_UINT): # 1000000 doc: | The simulation stops if more iterations than this criterion have been computed. - unit: NX_UNITLESS numerics(NXobject): doc: | Configuration of numerical details of the solver. + # use proper environment variable number_of_threads(NX_UINT): # obsolete set 01 16 convolution_mode(NX_CHAR): doc: | Which type of convolution kernel and model is used. - enumeration: [gaussian, laplace, laplace_ritchardson] # 2 - time_slope(NX_FLOAT): # 0.7930 + enumeration: [gaussian, laplace, laplace_ritchardson] + time_slope(NX_FLOAT): + unit: NX_ANY doc: | Constant to calibrate the real time scaling of the simulation. - unit: NX_ANY # or NX_DIMENSIONLESS ?? - # when taking the E_GAUSSIAN convolution mode set the TimeSlopeFactor explicitly here, default Miessen, Liesenjohann was 0.8359--> - # 0 - # 12991 # read from file - # discretization(NX_UINT) # 15 - # 15 - # domain_border_size(NX_UINT): # 7 - # + + # when taking the E_GAUSSIAN convolution mode set the TimeSlopeFactor explicitly here, default Miessen, Liesenjohann was 0.8359-\-> + # 0 + # 12991 # read from file + # discretization(NX_UINT) # 15 + # 15 + # domain_border_size(NX_UINT): # 7 + # 0 + # 0, Energies defined by misorientation, 1, GB Energies and mobilities clambed to 1.0 but uses sectors and Triplejunction mobilities, + # 2, GB Energies clambed to 0.3 or 0.6 / mobilities clambed to 1.0 - use Texture == false + # 0 # 0, E_NO_PROJECT, 1 E_TRIPLE_JUNCTION_DRAG_SINGLE (fixes outermost tj at, 2 empty) + # 1 # 0, E_ITERATIVE, 1, E_SQUARES + # 0.0 + # grid_coarsement(NXobject): doc: | Configuration of the grid coarsement algorithm whereby the representation @@ -142,24 +148,25 @@ NXmicrostructure_gragles_config(NXobject): on the system evolution. Without grid coarsement the total number of material points to consider stays the same throughout the simulation. discretization(NX_UINT): + unit: NX_UNITLESS doc: | Number of material points along each direction to discretize the average grain. The larger this value is chosen the finer the curvature details are that can be resolved but also the longer the simulation takes. - unit: NX_UNITLESS - is_active(NX_BOOLEAN): # 1 + is_active(NX_BOOLEAN): doc: | If true grid coarsement is active, otherwise it is not. - gradient(NX_FLOAT): # 0.98 + gradient(NX_FLOAT): + unit: NX_DIMENSIONLESS doc: | Fraction how strongly the number of grains has to reduce to trigger a grid coarsement step in an iteration. - unit: NX_DIMENSIONLESS - # the next only guru i.e. in C++ code configurable options - # 3 - # 2 - # 0 # 0, DEFAULT, 1 skips comparison and let grains shring isolated + + # the next only guru i.e. in C++ code configurable options + # 3 + # 2 + # 0 # 0, DEFAULT, 1 skips comparison and let grains shring isolated grain_boundary_mobility(NXobject): doc: | Physically-based model of the assumed mobility of the grain boundaries. @@ -169,31 +176,35 @@ NXmicrostructure_gragles_config(NXobject): the actual mobility is a combination of the mobility of the individual defects and the attached boundary patches. Grain boundaries have different degrees of microscopic freedom. Therefore, their mobility follows a distribution. + # 0 - # 0 # + # 0 # model(NX_CHAR): doc: | - Fundamental model how :math:`m` is assumed a function of the disorientation angle :math:`\Theta`. + Fundamental model how :math:`m` is assumed a function of the disorientation + angle :math:`\Theta`. enumeration: [rollett_holm] - # For rollett_holm :math:`m(\Theta) = m_0 \cdot (1 - c_1 * exp(-c_2 \cdot \frac{\Theta}{15}^{c_3}))`. + + # For rollett_holm :math:`m(\Theta) = m_0 \cdot (1 - c_1 * exp(-c_2 \cdot \frac{\Theta}{15}^{c_3}))`. m_null(NX_FLOAT): + unit: NX_ANY doc: | The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed temperature. GraGLeS was developed for modelling isothermal annealing. - unit: NX_ANY # m^4/Js c_one(NX_FLOAT): + unit: NX_DIMENSIONLESS doc: | Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not one. - unit: NX_DIMENSIONLESS - # 7.5e-14 + + # 7.5e-14 c_two(NX_FLOAT): + unit: NX_UNITLESS doc: | Mobility scaling factor :math:`c_2`. Typically 5. - unit: NX_UNITLESS c_three(NX_FLOAT): + unit: NX_UNITLESS doc: | Mobility scaling factor :math:`c_3`. Typically 9. - unit: NX_UNITLESS grain_boundary_energy(NXobject): doc: | Physically-based model of the assumed grain boundary surface energy. @@ -208,19 +219,21 @@ NXmicrostructure_gragles_config(NXobject): enumeration: [isotropic, anisotropic] model(NX_CHAR): doc: | - Fundamental model how :math:`\gamma` is assumed a function of the disorientation angle :math:`\Theta`. + Fundamental model how :math:`\gamma` is assumed a function of the disorientation + angle :math:`\Theta`. enumeration: [read_shockley] - gamma(NX_FLOAT): # HAGBEnergy + gamma(NX_FLOAT): + unit: NX_ANY doc: | Mean grain boundary surface energy that is assumed a function of the disorientation angle :math:`\Theta` of the adjoining grains :math:`\gamma(\Theta)`. This value factorizes the curvature_driving_force model. - unit: NX_ANY # J/m^2 - # For GraGLeS :math:`\gamma(\Theta) = \{\begin{array}1 \text{for} \Theta > 1. \\ 0.01 \text{for} \Theta \leq 1.\end{array}`. - # 1.0 - # 0.01 - # + + # For GraGLeS :math:`\gamma(\Theta) = \{\begin{array}1 \text{for} \Theta > 1. \\ 0.01 \text{for} \Theta \leq 1.\end{array}`. + # 1.0 + # 0.01 + # curvature_driving_force(NXobject): doc: | A continuum-scale curvature of an interface causes the interface to @@ -234,22 +247,23 @@ NXmicrostructure_gragles_config(NXobject): configurations across a grain boundary can exert a driving force on the grain boundary such that the boundary migrates into the volume with the higher stored elastic energy. - is_active(NX_BOOLEAN): # 1 + is_active(NX_BOOLEAN): doc: | If true the dislocation_driving_force is considered, otherwise it is not. - line_energy(NX_FLOAT): # 1.44e-9 + line_energy(NX_FLOAT): + unit: NX_ANY doc: | Prefactor :math:`0.5Gb^2` that factorizes the average stored elastic energy per length dislocation line. - unit: NX_ANY # J/m magnetic_field(NXobject): doc: | In case of an applied magnetic field, a difference of the magnetic susceptibility can exert a driving force on the grain boundary such that the boundary migrates into the volume with the higher magnetic energy. - is_active(NX_BOOLEAN): # 0 + is_active(NX_BOOLEAN): doc: | If true the magnetic_driving_force is considered, otherwise it is not. + # MagneticField.xml # https://github.com/GraGLeS/GraGLeS2D/blob/master/params/MagneticField.xml triple_line_mobility(NXobject): @@ -260,11 +274,384 @@ NXmicrostructure_gragles_config(NXobject): exert what can be conceptualized as a drag (resistance) to the motion of the adjoining interface patches. drag(NX_FLOAT): + unit: NX_ANY doc: | Assumed triple junction drag. - unit: NX_ANY # or reciprocal check Gottstein, Shvindlerman but is this really a drag. - # 1.0e10 - # isotropic, anisotropic - # 1 - # 1 + + # 1.0e10 + # isotropic, anisotropic + # 1 + # 1 25 + # + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# be9cd1aa11b17602615b46e4cf6a600e5b937fdc8480416708388bd9e7f81d9c +# +# +# +# +# +# +# Application definition for configuring GraGLeS. +# +# GraGLeS is a continuum-scale model for shared-memory-parallelized simulations +# of the isothermal evolution of 2D and 3D grain boundary networks with a level-set approach. +# CPU parallelization is achieved with OpenMP. +# +# The code has been implemented by C. Mießen in the group of G. Gottstein +# at the Institute für Metallkunde und Metallphysik, RWTH Aachen University. +# +# Details of the model are summarized in `C. Mießen <https://publications.rwth-aachen.de/record/709678>`_. +# +# +# +# +# +# +# +# +# +# Simulation ID as an alias to refer to this simulation. +# +# +# +# +# Discouraged free-text field to add further details to the computation. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Programs and libraries representing the computational environment +# +# +# +# +# +# +# +# +# +# +# +# From which file should the microstructure be instantiated. +# +# +# +# +# +# +# +# +# The formulation of mean curvature flow in the GraGLeS model is scale invariant. +# Therefore, the discretization has to be scaled to the actual physical length +# of the simulation domain (ve, ROI). +# For GraGLeS the discretization is always a square or cubic axis-aligned +# bounding box with a regular tiling into material points +# (either squares or cubes respectively). +# +# Edge_length is the length of the entire domain along its edge not +# the length of the Wigner-Seitz cell about each material point! +# +# +# +# +# +# Configuration when snapshots of the system should be taken. +# +# Keep in mind that essentially geometry snapshot data store the +# polylines and polyhedra of all grains which can take substantial disk +# space. +# +# +# +# Generate a snapshot of the properties of the grains to follow +# the evolution of the microstructure every :math:`n`-th iteration. +# Setting zero causes that no property snapshots are taken. +# +# +# +# +# Generate a snapshot of the geometry of the entire grain boundary network +# every :math:`n`-th iteration. Setting zero instructs to store no geometry data. +# +# +# +# +# +# +# Configuration when the simulation should be stopped in a controlled manner. +# Whichever criterion is fulfilled first triggers the controlled stop of +# and termination of GraGLeS. +# +# +# +# The simulation stops if the total number of grains +# becomes smaller than this criterion. +# +# +# +# +# The simulation stops if more iterations than this criterion have been computed. +# +# +# +# +# +# Configuration of numerical details of the solver. +# +# +# +# +# Which type of convolution kernel and model is used. +# +# +# +# +# +# +# +# +# +# Constant to calibrate the real time scaling of the simulation. +# +# +# +# +# +# +# Configuration of the grid coarsement algorithm whereby the representation +# of the system is continuously rediscretized such that on average grains +# are discretized with discretization many material points along each +# direction. +# +# Grid coarsement can reduce the computational costs substantially although +# it cannot be ruled out completely that the rediscretizing may have an effect +# on the system evolution. Without grid coarsement the total number of material +# points to consider stays the same throughout the simulation. +# +# +# +# Number of material points along each direction to discretize the +# average grain. The larger this value is chosen the finer the curvature +# details are that can be resolved but also the longer the simulation +# takes. +# +# +# +# +# If true grid coarsement is active, otherwise it is not. +# +# +# +# +# Fraction how strongly the number of grains has to reduce +# to trigger a grid coarsement step in an iteration. +# +# +# +# +# +# +# Physically-based model of the assumed mobility of the grain boundaries. +# +# Grain boundary mobility is not an intrinsic property of a grain boundary but system-dependent +# especially as grain boundaries in reality are decorated with defects as a consequence of which +# the actual mobility is a combination of the mobility of the individual defects and the attached +# boundary patches. Grain boundaries have different degrees of microscopic freedom. +# Therefore, their mobility follows a distribution. +# +# +# +# +# Fundamental model how :math:`m` is assumed a function of the disorientation +# angle :math:`\Theta`. +# +# +# +# +# +# +# +# +# The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed +# temperature. GraGLeS was developed for modelling isothermal annealing. +# +# +# +# +# Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not one. +# +# +# +# +# +# Mobility scaling factor :math:`c_2`. Typically 5. +# +# +# +# +# Mobility scaling factor :math:`c_3`. Typically 9. +# +# +# +# +# +# Physically-based model of the assumed grain boundary surface energy. +# +# Like for the grain boundary mobility, defects cause a distribution of energies for the +# patches of which the boundary is composed. In practice a too complicated dependency +# of the energy and mobility model is observed as a function of the type and chemical +# decoration of the defects. Therefore, simplifying assumptions are typically made. +# +# +# +# Fundamental type of assumption if energies are considered isotropic or not. +# +# +# +# +# +# +# +# +# Fundamental model how :math:`\gamma` is assumed a function of the disorientation +# angle :math:`\Theta`. +# +# +# +# +# +# +# +# Mean grain boundary surface energy that is assumed a function of the +# disorientation angle :math:`\Theta` of the adjoining grains :math:`\gamma(\Theta)`. +# This value factorizes the curvature_driving_force model. +# +# +# +# +# +# +# A continuum-scale curvature of an interface causes the interface to +# migrate towards the center of the curvature radius. +# +# +# +# If true the curvature_driving_force is considered, otherwise it is not. +# +# +# +# +# +# A continuum-scale difference of the stored elastic energy in dislocation +# configurations across a grain boundary can exert a driving force on the +# grain boundary such that the boundary migrates into the volume with the +# higher stored elastic energy. +# +# +# +# If true the dislocation_driving_force is considered, otherwise it is not. +# +# +# +# +# Prefactor :math:`0.5Gb^2` that factorizes the average +# stored elastic energy per length dislocation line. +# +# +# +# +# +# In case of an applied magnetic field, a difference of the magnetic +# susceptibility can exert a driving force on the grain boundary such that +# the boundary migrates into the volume with the higher magnetic energy. +# +# +# +# If true the magnetic_driving_force is considered, otherwise it is not. +# +# +# +# +# +# +# A triple line mediates the atomic arrangement differences between three +# interface patches. Therefore, the triple line is a defect that may not +# have the same mobility as adjoining grain boundaries and thus it may +# exert what can be conceptualized as a drag (resistance) to the motion +# of the adjoining interface patches. +# +# +# +# Assumed triple junction drag. +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml index aea83c2235..aab32a076b 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_gragles_results.yaml @@ -15,7 +15,8 @@ NXmicrostructure_gragles_results(NXobject): (NXentry): definition(NX_CHAR): enumeration: [NXmicrostructure_gragles_results] - # For rollett_holm :math:`m(\Theta) = m_0 \cdot (1 - c_1 * exp(-c_2 \cdot \frac{\Theta}{15}^{c_3}))`. + + # For rollett_holm :math:`m(\Theta) = m_0 \cdot (1 - c_1 * exp(-c_2 \cdot \frac{\Theta}{15}^{c_3}))`. simulation_identifier(NX_UINT): doc: | Simulation ID as an alias to refer to this simulation. @@ -26,7 +27,7 @@ NXmicrostructure_gragles_results(NXobject): end_time(NX_DATE_TIME): exists: recommended (NXuser): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] program1(NXprogram): program_name: \@version: @@ -37,9 +38,10 @@ NXmicrostructure_gragles_results(NXobject): doc: | Programs and libraries representing the computational environment programID(NXprogram): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR coordinate_system_set(NXcoordinate_system_set): rotation_handedness: rotation_convention: @@ -59,6 +61,7 @@ NXmicrostructure_gragles_results(NXobject): spatiotemporalID(NXobject): doc: | Documentation of the spatiotemporal evolution + # static quantities for which no change is modelled # the typical lean summary statistics flattened summary_statistics(NXobject): @@ -72,20 +75,25 @@ NXmicrostructure_gragles_results(NXobject): doc: | Evolution of the recrystallized volume fraction over time. time(NX_NUMBER): - doc: | - Evolution of the physical time not to be confused with wall-clock time or profiling data. unit: NX_TIME - dim: (n_summary_stats,) + doc: | + Evolution of the physical time not to be confused with wall-clock time or + profiling data. + dimensions: + rank: 1 + dim: [[1, n_summary_stats]] iteration(NX_INT): + unit: NX_UNITLESS doc: | Iteration or increment counter. - unit: NX_UNITLESS number_of_crystals(NX_UINT): + unit: NX_UNITLESS doc: | How many crystals are distinguished. Crystals are listed irrespective of the phase to which these are assigned. - unit: NX_UNITLESS - dim: (n_summary_stats,) + dimensions: + rank: 1 + dim: [[1, n_summary_stats]] stress(NXprocess): exists: optional type: @@ -93,20 +101,24 @@ NXmicrostructure_gragles_results(NXobject): Which type of stress. enumeration: [cauchy] stress(NX_FLOAT): + unit: NX_ANY doc: | Applied external stress tensor on the ROI. - unit: NX_ANY - dim: (n_summary_stats, 3, 3) + dimensions: + rank: 3 + dim: [[1, n_summary_stats], [2, 3], [3, 3]] strain(NXprocess): exists: optional type: doc: | Which type of strain. strain(NX_FLOAT): + unit: NX_ANY doc: | Applied external strain tensor on the ROI. - unit: NX_ANY - dim: (n_summary_stats, 3, 3) + dimensions: + rank: 3 + dim: [[1, n_summary_stats], [2, 3], [3, 3]] deformation_gradient(NXprocess): exists: optional type: @@ -114,34 +126,42 @@ NXmicrostructure_gragles_results(NXobject): Which type of deformation gradient. enumeration: [piola] value(NX_FLOAT): + unit: NX_ANY doc: | Applied deformation gradient tensor on the ROI. - unit: NX_ANY - dim: (n_summary_stats, 3, 3) + dimensions: + rank: 3 + dim: [[1, n_summary_stats], [2, 3], [3, 3]] magnetic_field(NXprocess): exists: optional strength(NX_FLOAT): + unit: NX_ANY doc: | Applied external magnetic field on the ROI. - unit: NX_ANY - dim: (n_summary_stats, 3, 3) + dimensions: + rank: 3 + dim: [[1, n_summary_stats], [2, 3], [3, 3]] electrical_field(NXprocess): exists: optional + # specify type of field strength(NX_FLOAT): + unit: NX_ANY doc: | Applied external electrical field on the ROI. - unit: NX_ANY - dim: (n_summary_stats, 3, 3) - # the typically storage-costlier snapshot data + dimensions: + rank: 3 + dim: [[1, n_summary_stats], [2, 3], [3, 3]] + + # the typically storage-costlier snapshot data microstructureID(NXmicrostructure): - exists: [min, 1, max, infty] # always storing starting configuration + exists: ['min', '1', 'max', 'unbounded'] time(NX_NUMBER): iteration(NX_INT): temperature(NX_FLOAT): + unit: NX_TEMPERATURE doc: | Simulated temperature for this snapshot. - unit: NX_TEMPERATURE grid(NXcg_grid): exists: optional crystal(NXobject): @@ -151,14 +171,22 @@ NXmicrostructure_gragles_results(NXobject): number_of_phases(NX_UINT): crystal_identifier_offset(NX_INT): crystal_identifier(NX_INT): - dim: (n_grains,) + dimensions: + rank: 1 + dim: [[1, n_grains]] phase_identifier_offset(NX_INT): phase_identifier(NX_INT): - dim: (n_grains,) + dimensions: + rank: 1 + dim: [[1, n_grains]] area(NX_NUMBER): - dim: (n_grains,) + dimensions: + rank: 1 + dim: [[1, n_grains]] volume(NX_NUMBER): - dim: (n_grains,) + dimensions: + rank: 1 + dim: [[1, n_grains]] interface(NXobject): exists: optional representation(NX_CHAR): @@ -166,16 +194,321 @@ NXmicrostructure_gragles_results(NXobject): number_of_interfaces(NX_UINT): identifier_offset(NX_INT): crystal_identifier(NX_INT): + unit: NX_UNITLESS doc: | Set of pairs of crystal_identifier for each interface. - unit: NX_UNITLESS - dim: (n_interfaces, 2) - \@use_these(NX_CHAR): # point to e.g /NXentry/OBJECT[spatiotemporalID]/MICROSTRUCTURE[microstructureID]/crystal/crystal_identifier + dimensions: + rank: 2 + dim: [[1, n_interfaces], [2, 2]] + \@use_these: + type: NX_CHAR relative_mobility(NX_FLOAT): + unit: NX_DIMENSIONLESS doc: | Mobility times surface energy density of the interface normalized to the maximum such product of the interface set. - unit: NX_DIMENSIONLESS - dim: (n_interfaces,) + dimensions: + rank: 1 + dim: [[1, n_interfaces]] area(NX_NUMBER): - dim: (n_interfaces,) + dimensions: + rank: 1 + dim: [[1, n_interfaces]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# dcafc6105a78380fa5aa50d169894a112f67802486a3455e652ffc8c80052c2c +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The total number of summary statistic log entries. +# +# +# +# +# Number of grains in the computer simulation. +# +# +# +# +# Number of interfaces in the computer simulation. +# +# +# +# +# Application definition for documenting results with GraGLeS. +# +# +# +# +# +# +# +# +# +# +# Simulation ID as an alias to refer to this simulation. +# +# +# +# +# Discouraged free-text field to add further details to the computation. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Programs and libraries representing the computational environment +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Documentation of the spatiotemporal evolution +# +# +# +# +# Summary quantities which are the result of some post-processing of the snapshot data +# (averaging, integrating, interpolating) happening in for practical reasons though in while +# running the simulation. Place used for storing descriptors from continuum mechanics +# and thermodynamics at the scale of the entire ROI. +# +# +# +# Evolution of the recrystallized volume fraction over time. +# +# +# +# Evolution of the physical time not to be confused with wall-clock time or +# profiling data. +# +# +# +# +# +# +# +# Iteration or increment counter. +# +# +# +# +# How many crystals are distinguished. +# Crystals are listed irrespective of the phase to which these are assigned. +# +# +# +# +# +# +# +# +# +# Which type of stress. +# +# +# +# +# +# +# +# Applied external stress tensor on the ROI. +# +# +# +# +# +# +# +# +# +# +# +# Which type of strain. +# +# +# +# +# Applied external strain tensor on the ROI. +# +# +# +# +# +# +# +# +# +# +# +# Which type of deformation gradient. +# +# +# +# +# +# +# +# Applied deformation gradient tensor on the ROI. +# +# +# +# +# +# +# +# +# +# +# +# Applied external magnetic field on the ROI. +# +# +# +# +# +# +# +# +# +# +# +# +# Applied external electrical field on the ROI. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Simulated temperature for this snapshot. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Set of pairs of crystal_identifier for each interface. +# +# +# +# +# +# +# +# +# +# Mobility times surface energy density of the interface normalized +# to the maximum such product of the interface set. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml index f515080354..f174a935b5 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_imm_config.yaml @@ -33,45 +33,49 @@ NXmicrostructure_imm_config(NXobject): doc: | Two-dimensional or three-dimensional simulation. enumeration: [2, 3] - discretization(NX_UINT): # 15# simulation ID via command line 10 + discretization(NX_UINT): + unit: NX_UNITLESS doc: | Target value for the number of material points per equivalent discrete diameter of the arithmetic average sub-grain. - unit: NX_UNITLESS crystal_symmetry(NX_CHAR): doc: | Assumed space group of the material. enumeration: [fcc, bcc, hcp] - # PreferenceOrientations.txt - # 1 # 0, E_HCP, 1 E_FCC, 2 E_BCC, 3 E_DEFAULT_STRUCTURE - number_of_grains(NX_UINT): # 8 + + # PreferenceOrientations.txt + # 1 # 0, E_HCP, 1 E_FCC, 2 E_BCC, 3 E_DEFAULT_STRUCTURE + number_of_grains(NX_UINT): + unit: NX_UNITLESS doc: | Target value for the number of grains. The actual domain size and grid will be configured based on the choices for discretization, number_of_grains, and shape of these grains. + number_of_subgrains(NX_UINT): unit: NX_UNITLESS - number_of_subgrains(NX_UINT): # 1000 doc: | Target value for the average number of sub-grains per grain. - unit: NX_UNITLESS + # 0 is there another one if not remove - # 1 always one - # + # 1 always one + # 1-\-> # 1 grain_shape(NX_FLOAT): exists: optional + unit: NX_DIMENSIONLESS doc: | If available used to define the sequence of relative extent of grains along the y (first value) and z-axis (second value) assuming the relative shape along the x-axis is 1. If not provided, the relative extent of the grains will be 1 one average along each axis (globulitic structure). - unit: NX_DIMENSIONLESS - dim: (2,) - # - + dimensions: + rank: 1 + dim: [[1, 2]] + + # 0.05 + # 1.0 + # remove 0 all the time 0.00 + # remove 0 all the time 0.00 + # component_analysis(NXobject): exists: optional doc: | @@ -84,67 +88,336 @@ NXmicrostructure_imm_config(NXobject): The first entry is always the null model None which measn that an orientation is not categorized as a special component. Examples for special components are Dillamore, Copper, Cube, Y, P and Q. - dim: (n_categories,) + dimensions: + rank: 1 + dim: [[1, n_categories]] bunge_euler(NX_FLOAT): + unit: NX_ANGLE doc: | Bunge-Euler angle parameterization of the texture components location in orientation space for which specifically different settings should be configured. - unit: NX_ANGLE - dim: (n_components, 3) + dimensions: + rank: 2 + dim: [[1, n_components], [2, 3]] theta(NX_FLOAT): - doc: | - Disorientation angle below which an orientation is categorized as one of the components. unit: NX_ANGLE - dim: (n_components,) + doc: | + Disorientation angle below which an orientation is categorized as one of the + components. + dimensions: + rank: 1 + dim: [[1, n_components]] dislocation_distribution(NXobject): doc: | Dislocations are modelled as Rayleigh-distributed mean-field density that can differ between but is constant within grains and sub-grains. min_max_grain(NX_FLOAT): - doc: | - The minimum and the maximum dislocation density to distribute across grains. - unit: NX_ANY # 1/m^2 - dim: (n_categories, 2) + unit: NX_ANY + doc: | + The minimum and the maximum dislocation density to distribute across grains. + dimensions: + rank: 2 + dim: [[1, n_categories], [2, 2]] min_max_subgrain(NX_FLOAT): + unit: NX_ANY doc: | The minimum and the maximum dislocation density to distribute across sub-grains. - unit: NX_ANY # 1/m^2 - dim: (n_categories, 2) - # 10.8e14# 10.8e144.0e14 - # + dimensions: + rank: 2 + dim: [[1, n_categories], [2, 2]] + + # 10.8e14# 10.8e14 doc: | The variance of the dislocation density distribution across the grains. - unit: NX_ANY # 1/m^2 - dim: (n_categories,) - variance_subgrain(NX_FLOAT): # 0.8e14 + dimensions: + rank: 1 + dim: [[1, n_categories]] + variance_subgrain(NX_FLOAT): + unit: NX_ANY doc: | The variance of the dislocation density distribution across the sub-grains. - unit: NX_ANY # 1/m^2 - dim: (n_categories,) - orientation_distribution(NXprocess): # CR70FeSi.Rogge.MTEX.vpsc.odf.5000.txt + dimensions: + rank: 1 + dim: [[1, n_categories]] + orientation_distribution(NXprocess): doc: | Orientations of the grains are sampled from a set of Bunge-Euler angle triplets. Orientations of the sub-grains are sampled by scattering the orientation of the (parent) grain and with optional Rayleigh-distributed scatter. bunge_euler(NX_FLOAT): + unit: NX_ANGLE doc: | Bunge-Euler angle parameterization of the texture components location in orientation space for which specifically different settings should be configured. + dimensions: + rank: 2 + dim: [[1, n_ori], [2, 3]] + variance_subgrain(NX_FLOAT): unit: NX_ANGLE - dim: (n_ori, 3) - variance_subgrain(NX_FLOAT): # 5.0 doc: | The variance of the disorientation of the sub-grain to their parent grain. - unit: NX_ANGLE - dim: (n_categories,) - # what is with preference orientations? + dimensions: + rank: 1 + dim: [[1, n_categories]] + + # what is with preference orientations? + # 1 # via OpenMP + # 1 + # 0.00 + # 1.00 + # 0.00 + # 1.00 + # +# +# +# +# +# +# +# How many texture components are distinguished, minimum is 1. +# +# +# +# +# How many special texture components are distinguished if any. +# +# +# +# +# Number of discrete orientations that are distributed across the grains. +# +# +# +# +# Application definition for the configuration of the legacy (micro)structure generator +# developed by the Institut für Metallkunde und Metallphysik at RWTH Aachen University. +# +# * `N. Leuning et al. <https://doi.org/10.3390/ma14216588>`_ +# * `C. Mießen <https://doi.org/10.18154/RWTH-2017-10148>`_ +# * `M. Kühbach <https://doi.org/10.18154/RWTH-2018-00294>`_ +# * `M. Kühbach et al. <https://github.com/mkuehbach/GraGLeS>`_ +# +# The tool can be used to instantiate specific configurations for two- and three-dimensional discretized microstructures. +# Specifically, single-phase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. +# Grains are modelled as elongated crystals to mimic fundamental geometrical constraints of the interface network in deformed material. +# +# +# +# +# +# +# +# +# +# The computational domain will be synthesized either as a square (for dimensionality = 2) +# or a cube (for dimensionality = 3) with axis-aligned cuboidal parent grains. The domain is +# discretized into material points using either square pixel or cubic voxel as the tessellating +# unit cells. +# +# +# +# Two-dimensional or three-dimensional simulation. +# +# +# +# +# +# +# +# +# Target value for the number of material points per equivalent +# discrete diameter of the arithmetic average sub-grain. +# +# +# +# +# Assumed space group of the material. +# +# +# +# +# +# +# +# +# +# +# Target value for the number of grains. The actual domain size and grid will be configured +# based on the choices for discretization, number_of_grains, and shape of these grains. +# +# +# +# +# Target value for the average number of sub-grains per grain. +# +# +# +# +# +# If available used to define the sequence of relative extent of grains along the y (first value) +# and z-axis (second value) assuming the relative shape along the x-axis is 1. If not provided, +# the relative extent of the grains will be 1 one average along each axis (globulitic structure). +# +# +# +# +# +# +# +# +# +# In texture research component analyses set on the idea that properties +# of grains different based on orientation with certain regions in orientation +# space show similar trends like a different average dislocation density +# or orientation_spread. +# +# +# +# The first entry is always the null model None which measn that an orientation +# is not categorized as a special component. Examples for special components are +# Dillamore, Copper, Cube, Y, P and Q. +# +# +# +# +# +# +# +# Bunge-Euler angle parameterization of the texture components +# location in orientation space for which specifically different settings +# should be configured. +# +# +# +# +# +# +# +# +# Disorientation angle below which an orientation is categorized as one of the +# components. +# +# +# +# +# +# +# +# +# Dislocations are modelled as Rayleigh-distributed mean-field density that +# can differ between but is constant within grains and sub-grains. +# +# +# +# The minimum and the maximum dislocation density to distribute across grains. +# +# +# +# +# +# +# +# +# The minimum and the maximum dislocation density to distribute across sub-grains. +# +# +# +# +# +# +# +# +# +# +# The variance of the dislocation density distribution across the grains. +# +# +# +# +# +# +# +# The variance of the dislocation density distribution across the sub-grains. +# +# +# +# +# +# +# +# +# Orientations of the grains are sampled from a set of Bunge-Euler angle triplets. +# Orientations of the sub-grains are sampled by scattering the orientation +# of the (parent) grain and with optional Rayleigh-distributed scatter. +# +# +# +# Bunge-Euler angle parameterization of the texture components +# location in orientation space for which specifically different settings +# should be configured. +# +# +# +# +# +# +# +# +# The variance of the disorientation of the sub-grain to their parent grain. +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml index a5c03a6189..f32d1481ae 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml @@ -30,20 +30,23 @@ NXmicrostructure_imm_results(NXobject): profiling(NXcs_profiling): exists: optional (NXuser): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] program1(NXprogram): program(NX_CHAR): - \@version(NX_CHAR): - \@url(NX_CHAR): + \@version: + type: NX_CHAR + \@url: + type: NX_CHAR exists: recommended environment(NXobject): exists: optional doc: | Programs and libraries representing the computational environment programID(NXprogram): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR microstructureID(NXmicrostructure): grid(NXcg_grid): extent(NX_UINT): @@ -51,66 +54,283 @@ NXmicrostructure_imm_results(NXobject): structure(NXdata): doc: | Default plot showing the grid. - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_CHAR): + \@signal: + type: NX_CHAR + \@axes: + type: NX_CHAR + \@AXISNAME_indices: + type: NX_CHAR title(NX_CHAR): crystal_identifier(NX_NUMBER): + unit: NX_UNITLESS doc: | Crystal identifier that was assigned to each material point. - unit: NX_UNITLESS - # either (n_edge, n_edge) or (n_edge, n_edge, n_edge) + + # either (n_edge, n_edge) or (n_edge, n_edge, n_edge) z(NX_NUMBER): - exists: optional # to cater for the 2D case + exists: optional + unit: NX_LENGTH doc: | Material point barycentre coordinate along z direction. - unit: NX_LENGTH - dim: (n_edge,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_edge]] + \@long_name: + type: NX_CHAR doc: | Coordinate along z direction. y(NX_NUMBER): + unit: NX_LENGTH doc: | Material point barycentre coordinate along y direction. - unit: NX_LENGTH - dim: (n_edge,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_edge]] + \@long_name: + type: NX_CHAR doc: | Coordinate along y direction. x(NX_NUMBER): + unit: NX_LENGTH doc: | Material point barycentre coordinate along x direction. - unit: NX_LENGTH - dim: (n_edge,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_edge]] + \@long_name: + type: NX_CHAR doc: | Coordinate along x direction. crystal(NXobject): - reference(NX_CHAR): # e.g. /entry1/microstructure1/grid/structure - number_of_crystals(NX_UINT): # sub-grains + reference(NX_CHAR): + number_of_crystals(NX_UINT): crystal_identifier(NX_INT): - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] area(NX_NUMBER): exists: recommended - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] volume(NX_NUMBER): exists: recommended - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] is_subgrain(NX_BOOLEAN): exists: recommended doc: | True if the crystal is considered a sub-grain. False if the crystal is considered a grain. - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] bunge_euler(NX_FLOAT): + unit: NX_ANGLE doc: | Bunge-Euler angle orientation of each crystal. - unit: NX_ANGLE - dim: (c, 3) + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] dislocation_density(NX_FLOAT): + unit: NX_ANY doc: | Mean-field dislocation density as a measure of the stored elastic energy content that is stored in the dislocation network of this grain and related defects within each crystal. - unit: NX_ANY # 1/m^2 - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 1ba122ce8a203a704f08ad4356d50a885d8d48c751352408b765fac58a0f4f11 +# +# +# +# +# +# +# +# Number of material points along the edge of the square- or cube-shaped domain. +# +# +# +# +# Number of crystals. +# +# +# +# +# Application definition for the results of the legacy (micro)structure generator developed +# by the Institut für Metallkunde und Metallphysik at RWTH Aachen University. +# +# * `N. Leuning et al. <https://doi.org/10.3390/ma14216588>`_ +# * `C. Mießen <https://doi.org/10.18154/RWTH-2017-10148>`_ +# * `M. Kühbach <https://doi.org/10.18154/RWTH-2018-00294>`_ +# * `M. Kühbach et al. <https://github.com/mkuehbach/GraGLeS>`_ +# +# The tool can be used to instantiate specific configurations for two- and three-dimensional discretized microstructures. +# Specifically, single-phase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. +# Grains are modelled as elongated crystals to mimic fundamental geometrical constraints of the interface network in deformed material. +# +# +# +# +# +# +# +# +# +# Discouraged free-text field to add further details to the computation. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Programs and libraries representing the computational environment +# +# +# +# +# +# +# +# +# +# +# +# +# +# Default plot showing the grid. +# +# +# +# +# +# +# +# Crystal identifier that was assigned to each material point. +# +# +# +# +# +# Material point barycentre coordinate along z direction. +# +# +# +# +# +# +# Coordinate along z direction. +# +# +# +# +# +# Material point barycentre coordinate along y direction. +# +# +# +# +# +# +# Coordinate along y direction. +# +# +# +# +# +# Material point barycentre coordinate along x direction. +# +# +# +# +# +# +# Coordinate along x direction. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# True if the crystal is considered a sub-grain. +# False if the crystal is considered a grain. +# +# +# +# +# +# +# +# Bunge-Euler angle orientation of each crystal. +# +# +# +# +# +# +# +# +# Mean-field dislocation density as a measure of the stored elastic energy +# content that is stored in the dislocation network of this grain and related +# defects within each crystal. +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXmicrostructure_ipf.yaml b/contributed_definitions/nyaml/NXmicrostructure_ipf.yaml index 105ca5f690..143e9cb8d0 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_ipf.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_ipf.yaml @@ -22,10 +22,12 @@ NXmicrostructure_ipf(NXprocess): If nothing is provided it is assumed that projection_direction is defined in the McStas coordinate system. projection_direction(NX_NUMBER): + unit: NX_UNITLESS doc: | The direction along which orientations are projected. - unit: NX_UNITLESS - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] input_grid(NXcg_grid): doc: | Details about the original grid. @@ -71,43 +73,56 @@ NXmicrostructure_ipf(NXprocess): there is one common understanding which enables also those users who are not necessarily experts in all the details of the underlying techniques an understanding if the dataset is worth to become reused or repurposed. + # \@signal: data # \@axes: [axis_y, axis_x] # \@axis_x_indices: 0 # \@axis_y_indices: 1 data(NX_NUMBER): + unit: NX_UNITLESS + # assume a mapping with step size 0.5 micron # we need to distinguish # pixel position, i.e. 0, 1, 2, 3, unit px - # answers in which pixel on the map but map is disconnected from sample surface context + # answers in which pixel on the map but map is disconnected from sample surface context # calibrated pixel position 0., 0.5, 1.0, 1.5, unit micron - # answers in addition physical dimensions (relevant to get crystal extent etc.) but still disconnected from sample surface context + # answers in addition physical dimensions (relevant to get crystal extent etc.) but still disconnected from sample surface context # calibrated pixel position including the offset of the original coordinate system - # answers everything would enable one to point if still in the microscope where on the sample surface each pixel is located + # answers everything would enable one to point if still in the microscope where on the sample surface each pixel is located # tech partners oftentimes do not report to more than calibrated pixel position doc: | Inverse pole figure color code for each map coordinate. - unit: NX_UNITLESS - dim: (n_y, n_x, 3) # | (n_z, n_y, n_x, 3) + dimensions: + rank: 3 + dim: [[1, n_y], [2, n_x], [3, 3]] axis_z(NX_NUMBER): + unit: NX_LENGTH doc: | Pixel center coordinate calibrated for step size along the z axis of the map. - unit: NX_LENGTH - dim: (n_z,) - # \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_z]] + + # \@long_name(NX_CHAR): axis_y(NX_NUMBER): unit: NX_LENGTH doc: | Pixel center coordinate calibrated for step size along the y axis of the map. - dim: (n_y,) - # \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_y]] + + # \@long_name(NX_CHAR): axis_x(NX_NUMBER): unit: NX_LENGTH doc: | Pixel center coordinate calibrated for step size along the x axis of the map. - dim: (n_x,) - # \@long_name(NX_CHAR): - # title: + dimensions: + rank: 1 + dim: [[1, n_x]] + + # \@long_name(NX_CHAR): + # title: legend(NXdata): doc: | The color code which maps colors to orientation in the fundamental zone. @@ -134,29 +149,285 @@ NXmicrostructure_ipf(NXprocess): visualized using tools like H5Web, which is why for now the matrix of a rasterized image which is rendered by the backend tool gets copied into an RGB matrix to offer a default plot. + # \@signal: data # \@axes: [axis_y, axis_x] # \@axis_x_indices: 0 # \@axis_y_indices: 1 data(NX_NUMBER): + unit: NX_UNITLESS + # hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! doc: | Inverse pole figure color code for each map coordinate. - unit: NX_UNITLESS - dim: (n_y, n_x, 3) + dimensions: + rank: 3 + dim: [[1, n_y], [2, n_x], [3, 3]] axis_y(NX_NUMBER): + unit: NX_UNITLESS doc: | Pixel along the y-axis. - unit: NX_UNITLESS - dim: (n_y,) - # \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_y]] + + # \@long_name(NX_CHAR): axis_x(NX_NUMBER): + unit: NX_UNITLESS doc: | Pixel along the x-axis. - unit: NX_UNITLESS - dim: (n_x,) - # \@long_name(NX_CHAR): - # title: + dimensions: + rank: 1 + dim: [[1, n_x]] + + # \@long_name(NX_CHAR): + # title: + + # for further contextualization see comments in NXms_ipf.yaml + # https://github.com/FAIRmat-NFDI/nexus_definitions/commit/26d4faa5c6950161e48f0672f3fdfd8c9bc907e2 -# for further contextualization see comments in NXms_ipf.yaml -# https://github.com/FAIRmat-NFDI/nexus_definitions/commit/26d4faa5c6950161e48f0672f3fdfd8c9bc907e2 +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# fee9f0abe19901b0c2c22cd8d8a56c6df76e8561ae53936915126e68ebaecf13 +# +# +# +# +# +# +# +# Number of pixel along the z slowest direction. +# +# +# +# +# Number of pixel along the y slow direction. +# +# +# +# +# Number of pixel along the x fast direction. +# +# +# +# +# Number of RGB values along the fastest direction, always three. +# +# +# +# +# Base class to store an inverse pole figure (IPF) mapping (IPF map). +# +# +# +# Reference to an :ref:`NXcoordinate_system` in which the projection_direction is defined. +# +# If the field depends_on is not provided but parents of the instance of this base class or its +# specializations define an instance of :ref:`NXcoordinate_system`, projection_direction +# is defined in this coordinate system. +# +# If nothing is provided it is assumed that projection_direction is defined in the McStas coordinate system. +# +# +# +# +# The direction along which orientations are projected. +# +# +# +# +# +# +# +# Details about the original grid. +# +# Here original grid means the grid for which the IPF map was computed when that +# IPF map was exported from the tech partner's file format representation. +# +# +# +# +# Details about the grid onto which the IPF is recomputed. +# +# Rescaling the visualization of the IPF map may be needed to enable +# visualization in specific software tools like H5Web. +# +# +# +# +# How where orientation values at positions of input_grid computed to values on output_grid. +# +# Nearest neighbour means the orientation of the closed (Euclidean distance) grid point of the input_grid was taken. +# +# +# +# +# +# +# +# Inverse pole figure mapping. +# +# phase. No ipf_mapID instances for non-indexed scan points as these are +# by definition assigned the null phase with phase_identifier 0. +# Inspect the definition of :ref:`NXcrystal_structure` and its field +# phase_identifier for further details. +# +# Details about possible regridding and associated interpolation +# during the computation of the IPF map visualization can be stored +# using the input_grid, output_grid, and interpolation fields. +# +# The main purpose of this map is to offer a normalized default representation +# of the IPF map for consumption by a research data management system (RDMS). +# This is aligned with the first aim of :ref:`NXmicrostructure_ipf`, to bring colleagues +# and users of IPF maps together to discuss which pieces of information need storage. +# +# We are convinced a step-by-step design and community-driven discussion is a practical +# strategy to work towards an interoperable description and data model for exchanging +# IPF maps as a specific community-accepted method to convey orientation maps. +# +# With this design the individual RDMS solutions and tools can still continue +# to support specific custom data analyses workflow and routes but at least +# there is one common understanding which enables also those users who are +# not necessarily experts in all the details of the underlying techniques an +# understanding if the dataset is worth to become reused or repurposed. +# +# +# +# +# +# Inverse pole figure color code for each map coordinate. +# +# +# +# +# +# +# +# +# +# Pixel center coordinate calibrated for step size along the z axis of the map. +# +# +# +# +# +# +# +# +# Pixel center coordinate calibrated for step size along the y axis of the map. +# +# +# +# +# +# +# +# +# Pixel center coordinate calibrated for step size along the x axis of the map. +# +# +# +# +# +# +# +# +# +# The color code which maps colors to orientation in the fundamental zone. +# +# For each stereographic standard triangle (SST), i.e. a rendering of the +# fundamental zone of the crystal-symmetry-reduced orientation space +# SO3, it is possible to define a color model which assigns a color to each +# point in the fundamental zone. +# +# Different mapping models are used. These implement (slightly) different +# scaling relations. Differences exist across representations of tech partners. +# +# Differences are which base colors of the RGB color model are placed in +# which extremal position of the SST and where the white point is located. +# +# For further details see: +# +# * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) +# * [S. Patala et al.](https://doi.org/10.1016/j.pmatsci.2012.04.002). +# +# Details are implementation-specific and not standardized yet. +# +# Given that the SST has a complicated geometry, it can not yet be +# visualized using tools like H5Web, which is why for now the matrix +# of a rasterized image which is rendered by the backend tool gets +# copied into an RGB matrix to offer a default plot. +# +# +# +# +# +# Inverse pole figure color code for each map coordinate. +# +# +# +# +# +# +# +# +# +# Pixel along the y-axis. +# +# +# +# +# +# +# +# +# Pixel along the x-axis. +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml index 46fa21363a..df0de6bbf2 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_kanapy_results.yaml @@ -24,36 +24,43 @@ NXmicrostructure_kanapy_results(NXobject): description(NX_CHAR): doc: | Discouraged free-text field to add further details to the computation. - start_time(NX_DATE_TIME): # better with UTC - end_time(NX_DATE_TIME): # better to get elapsed time + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): exists: recommended profiling(NXcs_profiling): exists: optional - (NXuser): # could use owner(NXuser) meaning a special type of user - exists: [min, 0, max, infty] + (NXuser): + exists: ['min', '0', 'max', 'unbounded'] + # kanapy, the script because this is also a program /Users/alexander/Codes/kanapy/examples/RVE_generation/create_rve.py program1(NXprogram): program(NX_CHAR): - \@version(NX_CHAR): - \@url(NX_CHAR): # https://github.com/ICAMS/Kanapy.git + \@version: + type: NX_CHAR + \@url: + type: NX_CHAR exists: recommended program2(NXprogram): program(NX_CHAR): - \@version(NX_CHAR): - \@url(NX_CHAR): + \@version: + type: NX_CHAR + \@url: + type: NX_CHAR exists: recommended environment(NXobject): exists: optional doc: | Programs and libraries representing the computational environment programID(NXprogram): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR + # no units instead labelled-property graph concepts with units microstructureID(NXmicrostructure): - exists: [min, 1, max, infty] - grid(NXcg_grid): # size but much more capable + exists: ['min', '1', 'max', 'unbounded'] + grid(NXcg_grid): extent(NX_UINT): cell_dimensions(NX_NUMBER): origin(NX_NUMBER): @@ -61,57 +68,277 @@ NXmicrostructure_kanapy_results(NXobject): structure(NXdata): doc: | Default plot showing the grid. - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_CHAR): + \@signal: + type: NX_CHAR + \@axes: + type: NX_CHAR + \@AXISNAME_indices: + type: NX_CHAR title(NX_CHAR): crystal_identifier(NX_NUMBER): + unit: NX_UNITLESS doc: | Crystal identifier that was assigned to each material point. - unit: NX_UNITLESS - # either (n_y, n_x) or (n_z, n_y, n_x) + + # either (n_y, n_x) or (n_z, n_y, n_x) z(NX_NUMBER): - exists: optional # to cater for the 2D case + exists: optional + unit: NX_LENGTH doc: | Material point barycentre coordinate along z direction. - unit: NX_LENGTH - dim: (n_y,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + type: NX_CHAR doc: | Coordinate along z direction. y(NX_NUMBER): + unit: NX_LENGTH doc: | Material point barycentre coordinate along y direction. - unit: NX_LENGTH - dim: (n_y,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + type: NX_CHAR doc: | Coordinate along y direction. x(NX_NUMBER): + unit: NX_LENGTH doc: | Material point barycentre coordinate along x direction. - unit: NX_LENGTH - dim: (n_x,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: + type: NX_CHAR doc: | Coordinate along x direction. + # add nodal positions as suggested in NXmicrostructure crystal(NXobject): - reference(NX_CHAR): # e.g. /entry1/microstructure1/grid/structure + reference(NX_CHAR): number_of_crystals(NX_UINT): number_of_phases(NX_UINT): crystal_identifier(NX_INT): - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] phase_identifier(NX_INT): - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] area(NX_NUMBER): exists: recommended - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] volume(NX_NUMBER): exists: recommended - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] bunge_euler(NX_FLOAT): + unit: NX_ANGLE doc: | Bunge-Euler angle orientation of each crystal. - unit: NX_ANGLE - dim: (c, 3) + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 5786194d801284be3ef38b0d8448d6b57347d2baf8b5c2a535214dd0c0a26e02 +# +# +# +# +# +# +# +# Number of material points along the z axis of the domain. +# +# +# +# +# Number of material points along the y axis of the domain. +# +# +# +# +# Number of material points along the x axis of the domain. +# +# +# +# +# Number of crystals. +# +# +# +# +# Application definition for the microstructure generator kanapy from ICAMS Bochum. +# +# * `A. Hartmeier et al. <https://joss.theoj.org/papers/10.21105/joss.01732>`_ +# +# A draft application definition to support discussion within the infrastructure use case IUC07 of the +# NFDI-MatWerk consortium of the German NFDI working on a data model for documenting simulations +# of spatiotemporal microstructure evolution with scientific software from this community. +# +# +# +# +# +# +# +# +# +# Discouraged free-text field to add further details to the computation. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Programs and libraries representing the computational environment +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Default plot showing the grid. +# +# +# +# +# +# +# +# Crystal identifier that was assigned to each material point. +# +# +# +# +# +# Material point barycentre coordinate along z direction. +# +# +# +# +# +# +# Coordinate along z direction. +# +# +# +# +# +# Material point barycentre coordinate along y direction. +# +# +# +# +# +# +# Coordinate along y direction. +# +# +# +# +# +# Material point barycentre coordinate along x direction. +# +# +# +# +# +# +# Coordinate along x direction. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Bunge-Euler angle orientation of each crystal. +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXmicrostructure_mtex_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_mtex_config.yaml index b33d27a1b7..cdf6368930 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_mtex_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_mtex_config.yaml @@ -19,20 +19,24 @@ NXmicrostructure_mtex_config(NXobject): x_axis_direction(NX_CHAR): doc: | TODO with MTex developers - # enumeration: + + # enumeration: # check against v5.12 z_axis_direction(NX_CHAR): doc: | TODO with MTex developers - # enumeration: + + # enumeration: a_axis_direction(NX_CHAR): doc: | TODO with MTex developers - # enumeration: + + # enumeration: b_axis_direction(NX_CHAR): doc: | TODO with MTex developers - # enumeration: + + # enumeration: euler_angle(NX_CHAR): doc: | TODO with MTex developers @@ -41,21 +45,21 @@ NXmicrostructure_mtex_config(NXobject): doc: | Settings relevant for generating plots. font_size(NX_NUMBER): + unit: NX_ANY doc: | TODO with MTex developers - unit: NX_ANY inner_plot_spacing(NX_NUMBER): + unit: NX_ANY doc: | TODO with MTex developers - unit: NX_ANY outer_plot_spacing(NX_NUMBER): + unit: NX_ANY doc: | TODO with MTex developers - unit: NX_ANY marker_size(NX_NUMBER): + unit: NX_ANY doc: | TODO with MTex developers - unit: NX_ANY figure_size(NX_NUMBER): doc: | TODO with MTex developers @@ -69,19 +73,24 @@ NXmicrostructure_mtex_config(NXobject): doc: | Code for the function handle used for annotating pole figure plots. color_map(NX_NUMBER): + unit: NX_UNITLESS doc: | TODO with MTex developers - unit: NX_UNITLESS - dim: (n_color_map, 3) + dimensions: + rank: 2 + dim: [[1, n_color_map], [2, 3]] default_color_map(NX_NUMBER): + unit: NX_UNITLESS doc: | TODO with MTex developers - unit: NX_UNITLESS - dim: (n_def_color_map, 3) + dimensions: + rank: 2 + dim: [[1, n_def_color_map], [2, 3]] + # phase_color_order: - # doc: | - # TODO with MTex developers - # unit: NX_UNITLESS + # doc: | + # TODO with MTex developers + # unit: NX_UNITLESS color_palette(NX_CHAR): degree_char(NX_CHAR): doc: | @@ -124,33 +133,33 @@ NXmicrostructure_mtex_config(NXobject): doc: | Miscellaneous settings relevant for numerics. eps(NX_NUMBER): + unit: NX_UNITLESS doc: | Return value of the Matlab eps command. - unit: NX_UNITLESS fft_accuracy(NX_NUMBER): + unit: NX_ANY doc: | TODO with MTex developers - unit: NX_ANY # NX_LENGTH or NX_RECIPROCAL_LENGTH? max_stwo_bandwidth(NX_NUMBER): + unit: NX_ANY doc: | TODO with MTex developers - unit: NX_ANY # radiant? max_sothree_bandwidth(NX_NUMBER): + unit: NX_ANY doc: | TODO with MTex developers - unit: NX_ANY # radiant? system(NXcollection): - doc: | - Miscellaneous settings relevant of the system where MTex runs. - memory(NX_NUMBER): - doc: | - TODO with MTex developers - open_gl_bug(NX_BOOLEAN): - doc: | - TODO with MTex developers - save_to_file(NX_BOOLEAN): - doc: | - TODO with MTex developers + doc: | + Miscellaneous settings relevant of the system where MTex runs. + memory(NX_NUMBER): + doc: | + TODO with MTex developers + open_gl_bug(NX_BOOLEAN): + doc: | + TODO with MTex developers + save_to_file(NX_BOOLEAN): + doc: | + TODO with MTex developers path(NXcollection): doc: | Collection of paths from where MTex reads information and code. @@ -188,4 +197,329 @@ NXmicrostructure_mtex_config(NXobject): ebsd_extensions(NX_CHAR): doc: | List of file type suffixes for which MTex assumes EBSD content. - # version as an instance of (NXprogram) one for MTex one for Matlab + + # version as an instance of (NXprogram) one for MTex one for Matlab + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 2728e563bbab6614e70dec02443b6ecf3d9535faa655816a2625950014a76886 +# +# +# +# +# +# +# +# Number of entries in the default color map +# +# +# +# +# Number of entries in color map +# +# +# +# +# Base class to store the configuration when using the MTex/Matlab software. +# +# MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. +# See `R. Hielscher et al. <https://mtex-toolbox.github.io/publications>`_ and +# the `MTex source code <https://github.com/mtex-toolbox>`_ for details. +# +# +# +# Reference frame and orientation conventions. +# Consult the `MTex docs <https://mtex-toolbox.github.io/EBSDReferenceFrame.html>`_ for details. +# +# +# +# TODO with MTex developers +# +# +# +# +# +# TODO with MTex developers +# +# +# +# +# +# TODO with MTex developers +# +# +# +# +# +# TODO with MTex developers +# +# +# +# +# +# TODO with MTex developers +# +# +# +# +# +# +# +# +# +# +# Settings relevant for generating plots. +# +# +# +# TODO with MTex developers +# +# +# +# +# TODO with MTex developers +# +# +# +# +# TODO with MTex developers +# +# +# +# +# TODO with MTex developers +# +# +# +# +# TODO with MTex developers +# +# +# +# +# True if MTex renders a scale bar with figures. +# +# +# +# +# True if MTex renders a grid with figures. +# +# +# +# +# Code for the function handle used for annotating pole figure plots. +# +# +# +# +# TODO with MTex developers +# +# +# +# +# +# +# +# +# TODO with MTex developers +# +# +# +# +# +# +# +# +# +# +# TODO with MTex developers +# +# +# +# +# TODO with MTex developers +# +# +# +# +# TODO with MTex developers +# +# +# +# +# TODO with MTex developers +# +# +# +# +# TODO with MTex developers +# +# +# +# +# TODO with MTex developers +# +# +# +# +# +# Miscellaneous other settings of MTex. +# +# +# +# TODO with MTex developers +# +# +# +# +# TODO with MTex developers +# +# +# +# +# TODO with MTex developers +# +# +# +# +# TODO with MTex developers +# +# +# +# +# TODO with MTex developers +# +# +# +# +# +# +# Miscellaneous settings relevant for numerics. +# +# +# +# Return value of the Matlab eps command. +# +# +# +# +# TODO with MTex developers +# +# +# +# +# TODO with MTex developers +# +# +# +# +# TODO with MTex developers +# +# +# +# +# +# Miscellaneous settings relevant of the system where MTex runs. +# +# +# +# TODO with MTex developers +# +# +# +# +# TODO with MTex developers +# +# +# +# +# TODO with MTex developers +# +# +# +# +# +# Collection of paths from where MTex reads information and code. +# +# +# +# Absolute path to specific component of MTex source code. +# +# +# +# +# Absolute path to specific component of MTex source code. +# +# +# +# +# Absolute path to specific component of MTex source code. +# +# +# +# +# Absolute path to specific component of MTex source code. +# +# +# +# +# Absolute path to specific component of MTex source code. +# +# +# +# +# Absolute path to specific component of MTex source code. +# +# +# +# +# Absolute path to specific component of MTex source code. +# +# +# +# +# Absolute path to specific component of MTex source code. +# +# +# +# +# Absolute path to specific component of MTex source code. +# +# +# +# +# List of file type suffixes for which MTex assumes +# texture/pole figure information. +# +# +# +# +# List of file type suffixes for which MTex assumes EBSD content. +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXmicrostructure_odf.yaml b/contributed_definitions/nyaml/NXmicrostructure_odf.yaml index 119dc6b691..e436f7f7d0 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_odf.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_odf.yaml @@ -7,11 +7,13 @@ doc: | pole figure data in a computational process called `pole figure inversion `_. symbols: n_varphi_one: | - Number of pixel per varphi section plot along the :math:`\varphi_1` fastest direction. + Number of pixel per varphi section plot along the :math:`\varphi_1` fastest + direction. n_capital_phi: | Number of pixel per varphi section plot along the :math:`\Phi` fast direction. n_varphi_two: | - Number of pixel per varphi section plot along the :math:`\varphi_2` slow direction. + Number of pixel per varphi section plot along the :math:`\varphi_2` slow + direction. k: | Number of local maxima evaluated in the component analysis. n_pos: | @@ -30,16 +32,17 @@ NXmicrostructure_odf(NXprocess): Point group assumed for additionally considered sample symmetries following the notation of the International Table of Crystallography). kernel_halfwidth(NX_NUMBER): + unit: NX_ANGLE doc: | Halfwidth of the kernel. - unit: NX_ANGLE kernel_name(NX_CHAR): doc: | Name of the kernel. resolution(NX_NUMBER): + unit: NX_ANGLE doc: | Resolution of the kernel. - unit: NX_ANGLE + # specific values and typical results kth_extrema(NXobject): doc: | @@ -52,45 +55,54 @@ NXmicrostructure_odf(NXprocess): always the first entry in location and volume_fraction. enumeration: [minima, maxima] kth(NX_UINT): + unit: NX_UNITLESS doc: | Number of local extrema evaluated - unit: NX_UNITLESS - # value of kth should be k + + # value of kth should be k theta(NX_NUMBER): + unit: NX_ANGLE doc: | Disorientation threshold within which intensity of the ODF is integrated for the component analysis. - unit: NX_ANGLE location(NX_NUMBER): + unit: NX_ANGLE doc: | Euler angle representation :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` of the kth-most maxima in decreasing order of the intensity maximum. - unit: NX_ANGLE - dim: (k, 3) + dimensions: + rank: 2 + dim: [[1, k], [2, 3]] volume_fraction(NX_NUMBER): + unit: NX_ANY doc: | Integrated ODF intensity within a theta angular region of the orientation space (SO3) about each location (obeying symmetries) as specified for each location. - unit: NX_ANY - dim: (k,) + dimensions: + rank: 1 + dim: [[1, k]] sampling(NXobject): doc: | The ODF intensity values (weights) as sampled with a software resolution(NX_NUMBER): + unit: NX_ANGLE doc: | Sampling resolution - unit: NX_ANGLE euler(NX_NUMBER): + unit: NX_ANGLE doc: | Bunge-Euler (i.e. ZXZ convention) locations of each position in orientation space for which a weight was sampled. - unit: NX_ANGLE - dim: (n_pos, 3) + dimensions: + rank: 2 + dim: [[1, n_pos], [2, 3]] weight(NX_NUMBER): + unit: NX_DIMENSIONLESS doc: | Weight at each sampled position following the order in euler. - unit: NX_DIMENSIONLESS # intensity of ODF at euler / intensity of random ODF at euler - dim: (n_pos,) + dimensions: + rank: 1 + dim: [[1, n_pos]] phi_two_plot(NXdata): doc: | Visualization of the ODF intensity as discretized orthogonal sections through @@ -100,31 +112,271 @@ NXmicrostructure_odf(NXprocess): Mind that when parameterized using Euler angles the orientation space is a distorted space. Therefore, equivalent orientations show intensity contributions in eventually multiple locations. + # \@signal: intensity # \@axes: [varphi_two, capital_phi, varphi_one] # \@varphi_one_indices: 0 # \@capital_phi: 1 # \@varphi_two_indices: 2 intensity(NX_NUMBER): - doc: | - ODF intensity at probed locations relative to the intensity of the null model of a random texture. unit: NX_DIMENSIONLESS - dim: (n_varphi_two, n_capital_phi, n_varphi_one) + doc: | + ODF intensity at probed locations relative to the intensity of the null model of + a random texture. + dimensions: + rank: 3 + dim: [[1, n_varphi_two], [2, n_capital_phi], [3, n_varphi_one]] varphi_one(NX_NUMBER): + unit: NX_ANGLE doc: | Pixel center angular position along the :math:`\varphi_1` direction. - unit: NX_ANGLE - dim: (n_varphi_one,) - # \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_varphi_one]] + + # \@long_name(NX_CHAR): capital_phi(NX_NUMBER): + unit: NX_ANGLE doc: | Pixel center angular position along the :math:`\Phi` direction. - unit: NX_ANGLE - dim: (n_capital_phi,) - # \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_capital_phi]] + + # \@long_name(NX_CHAR): varphi_two(NX_NUMBER): + unit: NX_ANGLE doc: | Pixel center angular position along the :math:`\varphi_2` direction. - unit: NX_ANGLE - dim: (n_varphi_two,) - # \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_varphi_two]] + + # \@long_name(NX_CHAR): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# cae0f111b0054fe92d860666cedc1db0bc9abcf1d69058fb619b351bed79705f +# +# +# +# +# +# +# +# Number of pixel per varphi section plot along the :math:`\varphi_1` fastest +# direction. +# +# +# +# +# Number of pixel per varphi section plot along the :math:`\Phi` fast direction. +# +# +# +# +# Number of pixel per varphi section plot along the :math:`\varphi_2` slow +# direction. +# +# +# +# +# Number of local maxima evaluated in the component analysis. +# +# +# +# +# Number of sampled positions in orientation space. +# +# +# +# +# Base class to store an orientation distribution function (ODF). +# +# An orientation distribution function is a probability distribution that details how +# much volume of material has a specific orientation. An ODF is computed from +# pole figure data in a computational process called `pole figure inversion <https://doi.org/10.1107/S0021889808030112>`_. +# +# +# +# Details about the algorithm used for computing the ODF. +# +# +# +# Point group of the crystal structure of the phase for which the here documented phase- +# dependent ODF was computed.(following the notation of the International Table of Crystallography). +# +# +# +# +# Point group assumed for additionally considered sample symmetries +# following the notation of the International Table of Crystallography). +# +# +# +# +# Halfwidth of the kernel. +# +# +# +# +# Name of the kernel. +# +# +# +# +# Resolution of the kernel. +# +# +# +# +# +# +# Group to store descriptors and summary statistics for extrema of the ODF. +# +# +# +# Minima or maxima, if extrema is set to minima values for location and volume_fraction +# are sorted in increasing order. If extrema is set to maxima values for location and +# volume_fraction are sorted in descreasing order. Therefore, the global extremum is +# always the first entry in location and volume_fraction. +# +# +# +# +# +# +# +# +# Number of local extrema evaluated +# +# +# +# +# +# Disorientation threshold within which intensity of the ODF +# is integrated for the component analysis. +# +# +# +# +# Euler angle representation :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` of the kth-most +# maxima in decreasing order of the intensity maximum. +# +# +# +# +# +# +# +# +# Integrated ODF intensity within a theta angular region of the orientation space (SO3) +# about each location (obeying symmetries) as specified for each location. +# +# +# +# +# +# +# +# +# The ODF intensity values (weights) as sampled with a software +# +# +# +# Sampling resolution +# +# +# +# +# Bunge-Euler (i.e. ZXZ convention) locations of each position +# in orientation space for which a weight was sampled. +# +# +# +# +# +# +# +# +# Weight at each sampled position following the order in euler. +# +# +# +# +# +# +# +# +# Visualization of the ODF intensity as discretized orthogonal sections through +# orientation space parameterized using Bunge-Euler angles. +# +# This is one example of typical default plots used in the texture community in materials engineering. +# +# Mind that when parameterized using Euler angles the orientation space is a distorted space. +# Therefore, equivalent orientations show intensity contributions in eventually multiple locations. +# +# +# +# +# ODF intensity at probed locations relative to the intensity of the null model of +# a random texture. +# +# +# +# +# +# +# +# +# +# Pixel center angular position along the :math:`\varphi_1` direction. +# +# +# +# +# +# +# +# +# Pixel center angular position along the :math:`\Phi` direction. +# +# +# +# +# +# +# +# +# Pixel center angular position along the :math:`\varphi_2` direction. +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXmicrostructure_pf.yaml b/contributed_definitions/nyaml/NXmicrostructure_pf.yaml index cd746406ee..fe72bc47d8 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_pf.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_pf.yaml @@ -20,42 +20,170 @@ NXmicrostructure_pf(NXprocess): was computed (according to International Table of Crystallography). specimen_symmetry_point_group(NX_CHAR): doc: | - Point group of assumed sample symmetries (according to International Table of Crystallography). + Point group of assumed sample symmetries (according to International Table of + Crystallography). + # integration windows halfwidth(NX_NUMBER): + unit: NX_ANGLE doc: | Halfwidth of the kernel. - unit: NX_ANGLE miller_indices(NX_CHAR): doc: | Miller indices (:math:`(hkl)[uvw]`) to specify the pole figure. resolution(NX_NUMBER): + unit: NX_ANGLE doc: | Resolution of the kernel. - unit: NX_ANGLE pf(NXdata): doc: | Pole figure. + # \@signal: intensity # \@axes: [axis_y, axis_x] # \@axis_x_indices: 0 # \@axis_y_indices: 1 intensity(NX_NUMBER): + unit: NX_UNITLESS doc: | Pole figure intensity. - unit: NX_UNITLESS - dim: (n_y, n_x) + dimensions: + rank: 2 + dim: [[1, n_y], [2, n_x]] axis_y(NX_NUMBER): + unit: NX_ANY doc: | Pixel center along y direction in the equatorial plane of a stereographic projection of the unit sphere. - unit: NX_ANY - dim: (n_y,) - # \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_y]] + + # \@long_name(NX_CHAR): axis_x(NX_NUMBER): + unit: NX_ANY doc: | Pixel center along x direction in the equatorial plane of a stereographic projection of the unit sphere. - unit: NX_ANY - dim: (n_x,) - # \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_x]] + + # \@long_name(NX_CHAR): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# b6d653631fbd7c1c0911a62aa985bb4dd9d507e8fa35b61252131fcb403460a5 +# +# +# +# +# +# +# +# Number of pixel per pole figure in the slow direction. +# +# +# +# +# Number of pixel per pole figure in the fast direction. +# +# +# +# +# Base class to store a pole figure (PF) computation. +# +# A pole figure is the X-ray diffraction intensity for specific integrated +# peaks for a hemispherical illumination of a real or virtual specimen. +# +# +# +# Details about the algorithm that was used to compute the pole figure. +# +# +# +# Point group of the crystal structure of the phase for which the pole figure +# was computed (according to International Table of Crystallography). +# +# +# +# +# Point group of assumed sample symmetries (according to International Table of +# Crystallography). +# +# +# +# +# +# Halfwidth of the kernel. +# +# +# +# +# Miller indices (:math:`(hkl)[uvw]`) to specify the pole figure. +# +# +# +# +# Resolution of the kernel. +# +# +# +# +# +# Pole figure. +# +# +# +# +# Pole figure intensity. +# +# +# +# +# +# +# +# +# Pixel center along y direction in the equatorial plane of +# a stereographic projection of the unit sphere. +# +# +# +# +# +# +# +# +# Pixel center along x direction in the equatorial plane of +# a stereographic projection of the unit sphere. +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml index 6e480e6046..7894f93725 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml @@ -4,7 +4,6 @@ doc: | * `M. Kühbach et al. `_ * `M. Diehl et al. `_ - symbols: n_dg_ori: | Number of Bunge-Euler angle triplets for deformed grains. @@ -15,7 +14,8 @@ symbols: n_temp: | Number of suport points for the desired time-temperature profile. n_defrag: | - Number of entries when to defragment i.e. garbage collect the memory holding state information for recrystallized cells. + Number of entries when to defragment i.e. garbage collect the memory holding + state information for recrystallized cells. n_snapshot: | Number of entries when to collect snapshots of the evolving microstructure. n_su: | @@ -37,7 +37,7 @@ NXmicrostructure_score_config(NXobject): profiling(NXcs_profiling): exists: optional (NXuser): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] program1(NXprogram): program_name: \@version: @@ -48,9 +48,10 @@ NXmicrostructure_score_config(NXobject): doc: | Programs and libraries representing the computational environment programID(NXprogram): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR discretization(NXmicrostructure): doc: | Relevant data to instantiate a starting configuration that is typically @@ -74,21 +75,26 @@ NXmicrostructure_score_config(NXobject): Which model should be used to generate a starting microstructure. enumeration: [cuboidal, poisson_voronoi, ebsd, damask] extent(NX_FLOAT): + unit: NX_LENGTH doc: | Extent of each deformed grain in voxel along the x, y, and z direction when type is cuboidal. - unit: NX_LENGTH - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] diameter(NX_FLOAT): + unit: NX_LENGTH doc: | Average spherical diameter when type is poisson_voronoi. - unit: NX_LENGTH bunge_euler(NX_FLOAT): exists: optional - doc: | - Set of Bunge-Euler angles ( :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` ) to sample orientations of deformed grains randomly from. unit: NX_ANGLE - dim: (n_dg_ori, 3) + doc: | + Set of Bunge-Euler angles ( :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` ) + to sample orientations of deformed grains randomly from. + dimensions: + rank: 2 + dim: [[1, n_dg_ori], [2, 3]] ebsd(NXserialized): exists: optional doc: | @@ -99,10 +105,13 @@ NXmicrostructure_score_config(NXobject): algorithm: checksum: stepsize(NX_FLOAT): - doc: | - Extent of the pixel of the EBSD orientation mapping assuming square-shaped pixels. unit: NX_LENGTH - dim: (2,) + doc: | + Extent of the pixel of the EBSD orientation mapping assuming square-shaped + pixels. + dimensions: + rank: 1 + dim: [[1, 2]] nucleation(NXobject): doc: | Phenomenological model according to which recrystallization nuclei @@ -114,7 +123,6 @@ NXmicrostructure_score_config(NXobject): * csr, complete spatial randomness. * custom, implementation specific. * gb, nuclei placed at grain boundaries - enumeration: [csr, custom, gb] incubation_time: doc: | @@ -125,31 +133,35 @@ NXmicrostructure_score_config(NXobject): According to which model will the nuclei get their orientation assigned. enumeration: [sample_from_nucleus_euler] bunge_euler(NX_FLOAT): - doc: | - Set of Bunge-Euler angles ( :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` ) to sample orientations of nuclei randomly from. unit: NX_ANGLE - dim: (n_rx_ori, 3) + doc: | + Set of Bunge-Euler angles ( :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` ) + to sample orientations of nuclei randomly from. + dimensions: + rank: 2 + dim: [[1, n_rx_ori], [2, 3]] material_properties(NXobject): doc: | (Mechanical) properties of the material which scale the amount of stored (elastic) energy in the system and thus mainly affect recrystallization kinetics. reference_shear_modulus(NX_FLOAT): + unit: NX_PRESSURE doc: | Shear modulus at zero Kelvin. - unit: NX_PRESSURE reference_burgers_magnitude(NX_FLOAT): + unit: NX_LENGTH doc: | Magnitude at the Burgers vector at zero Kelvin. - unit: NX_LENGTH + # firstOrderdG0dT # alloyConstantThermalExpCoeff # FirstOrderThermalExpCoeff # SecondOrderThermalExpCoeff melting_temperature(NX_FLOAT): + unit: NX_TEMPERATURE doc: | Melting temperature in degrees Celsius. - unit: NX_TEMPERATURE grain_boundary_mobility(NXobject): doc: | Model for the assumed mobility of grain boundaries with different disorientation @@ -161,6 +173,7 @@ NXmicrostructure_score_config(NXobject): Grain boundaries with disorientation angle smaller than 15 degree are considered as low-angle grain boundaries. Other grain boundaries are high-angle boundaries. + # TODO: add equation for the Sebald-Gottstein model the following equation # TODO: add equation for the Rollett-Holm model the following equation enumeration: [sebald_gottstein, rollett_holm] @@ -169,54 +182,56 @@ NXmicrostructure_score_config(NXobject): doc: | Parameter of the Sebald-Gottstein migration model. lagb_to_hagb_cut(NX_FLOAT): - doc: | - At which disorientation angle are grain boundary considered as high-angle grain boundaries. unit: NX_ANGLE + doc: | + At which disorientation angle are grain boundary considered as high-angle grain + boundaries. lagb_pre_factor(NX_FLOAT): + unit: NX_ANY doc: | Pre-exponential factor for low-angle grain boundaries. - unit: NX_ANY lagb_enthalpy(NX_FLOAT): + unit: NX_ANY doc: | Migration activation enthalpy for low-angle grain boundaries. - unit: NX_ANY hagb_pre_factor(NX_FLOAT): + unit: NX_ANY doc: | Pre-exponential factor for high-angle grain boundaries. - unit: NX_ANY hagb_enthalpy(NX_FLOAT): + unit: NX_ANY doc: | Migration activation enthalpy for high-angle grain boundaries. - unit: NX_ANY special_pre_factor(NX_FLOAT): + unit: NX_ANY doc: | Pre-exponential factor for particularly mobile boundaries. - unit: NX_ANY special_enthalpy(NX_FLOAT): + unit: NX_ANY doc: | Migration activation enthalpy for particularly mobile boundaries. - unit: NX_ANY rollett_holm(NXobject): doc: | Parameter of the Rollett-Holm migration model. + # For rollett_holm :math:`m(\Theta) = m_0 \cdot (1 - c_1 * exp(-c_2 \cdot \frac{\Theta}{15}^{c_3}))`. m_null(NX_FLOAT): + unit: NX_ANY doc: | The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed temperature. GraGLeS was developed for modelling isothermal annealing. - unit: NX_ANY # m^4/Js c_one(NX_FLOAT): + unit: NX_DIMENSIONLESS doc: | Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not one. - unit: NX_DIMENSIONLESS c_two(NX_FLOAT): + unit: NX_UNITLESS doc: | Mobility scaling factor :math:`c_2`. Typically 5. - unit: NX_UNITLESS c_three(NX_FLOAT): + unit: NX_UNITLESS doc: | Mobility scaling factor :math:`c_3`. Typically 9. - unit: NX_UNITLESS stored_energy_recovery(NXobject): doc: | Time-dependent reduction of the stored (elastic) energy to account for recovery. @@ -244,80 +259,91 @@ NXmicrostructure_score_config(NXobject): Average surface energy of the grain-boundary-dispersoid-surface configuration which factorizes the drag pressure. time(NX_FLOAT): + unit: NX_TIME doc: | Support point of the linearized curve of simulated time matching a specific support point of the average dispersoid radius. - unit: NX_TIME - dim: (n_drag,) + dimensions: + rank: 1 + dim: [[1, n_drag]] radius(NX_FLOAT): + unit: NX_LENGTH doc: | Support point of the linearized curve of the average dispersoid radius. - unit: NX_LENGTH - dim: (n_drag,) + dimensions: + rank: 1 + dim: [[1, n_drag]] time_temperature(NXobject): doc: | Desired simulated time-temperature profile time(NX_FLOAT): + unit: NX_TIME doc: | Support point of the linearized curve of simulated time matching a specific support point of the temperature. - unit: NX_TIME - dim: (n_temp,) + dimensions: + rank: 1 + dim: [[1, n_temp]] temperature(NX_FLOAT): + unit: NX_TEMPERATURE doc: | Support point of the linearized curve of the temperature. - unit: NX_TEMPERATURE - dim: (n_temp,) + dimensions: + rank: 1 + dim: [[1, n_temp]] simulation_control(NXobject): doc: | Criteria which enable to stop the simulation in a controlled manner. Whichever criterion is fulfilled first stops the simulation. max_x(NX_FLOAT): + unit: NX_DIMENSIONLESS doc: | Maximum recrystallized volume fraction. - unit: NX_DIMENSIONLESS max_time(NX_NUMBER): + unit: NX_TIME doc: | Maximum simulated physical time. - unit: NX_TIME max_iteration(NX_UINT): + unit: NX_UNITLESS doc: | Maximum number of iteration steps. - unit: NX_UNITLESS numerics(NXobject): doc: | Settings relevant for stable numerical integration. max_delta_x(NX_FLOAT): + unit: NX_DIMENSIONLESS doc: | Maximum fraction equivalent to the migration of the fastest grain boundary in the system how much a cell may be consumed in a single iteration. - unit: NX_DIMENSIONLESS initial_cell_cache(NX_FLOAT): + unit: NX_UNITLESS doc: | Fraction of the total number of cells in the CA which should initially be allocated for offering cells in the recrystallization front. - unit: NX_UNITLESS realloc_cell_cache(NX_FLOAT): + unit: NX_UNITLESS doc: | By how much more times should the already allocated memory be increased to offer space for storing states of cells in the recrystallization front. - unit: NX_UNITLESS defragment_cell_cache(NX_BOOLEAN): doc: | Should the cache for cells in the recrystallization front be defragmented on-the-fly. defragment_x(NX_FLOAT): + unit: NX_DIMENSIONLESS doc: | Heuristic recrystallized volume target values at which the cache for cells in the recrystallization front will be defragmented on-the-fly. - unit: NX_DIMENSIONLESS - dim: (n_defrag,) + dimensions: + rank: 1 + dim: [[1, n_defrag]] sampling(NXobject): x(NX_FLOAT): + unit: NX_DIMENSIONLESS doc: | List of recrystallized volume target values at which a snapshot of the CA state should be stored. @@ -331,39 +357,42 @@ NXmicrostructure_score_config(NXobject): Despite these front data make up for approximately one order of magnitude less cells than represented in the domain, more numerical data have to be collected each cell in the front than just a grain identifier. - unit: NX_DIMENSIONLESS - dim: (n_snapshot,) + dimensions: + rank: 1 + dim: [[1, n_snapshot]] solitary_unit(NXobject): apply(NX_BOOLEAN): doc: | Perform a statistical analyses of the results as it was proposed by M. Kühbach (solitary unit model ensemble approach). number_of_domains(NX_UINT): + unit: NX_UNITLESS doc: | How many independent cellular automaton domains should be instantiated. - unit: NX_UNITLESS rediscretization(NX_UINT): + unit: NX_UNITLESS doc: | Into how many time steps should the real time interval be discretized upon during post-processing the results with the solitary unit modeling approach. - unit: NX_UNITLESS domain_identifier(NX_UINT): + unit: NX_UNITLESS doc: | List of identifier for those domain which should be rendered. Identifier start from 0. - unit: NX_UNITLESS - dim: (n_su,) + dimensions: + rank: 1 + dim: [[1, n_su]] # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 6142d3475f379790762453cd32f9330b04fd40950389a8c7322331e405008183 -# +# 7bf70eb740ed157be8c02cbcf23ff0365420faf9f43aea2267440c2de74d7af1 +# # # -# +# # # # @@ -392,6 +421,27 @@ NXmicrostructure_score_config(NXobject): # Number of Bunge-Euler angle triplets for recrystallization nuclei. # # +# +# +# Number of support points for the linearized drag profile. +# +# +# +# +# Number of suport points for the desired time-temperature profile. +# +# +# +# +# Number of entries when to defragment i.e. garbage collect the memory holding +# state information for recrystallized cells. +# +# +# +# +# Number of entries when to collect snapshots of the evolving microstructure. +# +# # # # Number of solitary unit domains to export. @@ -399,59 +449,72 @@ NXmicrostructure_score_config(NXobject): # # # -# Application definition to control a simulation with the SCORE model. +# Application definition to configure a simulation with the SCORE model. +# +# * `M. Kühbach et al. <https://doi.org/10.1016/j.actamat.2016.01.068>`_ +# * `M. Diehl et al. <https://doi.org/10.1088/1361-651X/ab51bd>`_ # # -# -# -# Version specifier of this application definition. -# -# -# -# -# Official NeXus NXDL schema with which this file was written. -# +# # # # # -# -# -# -# -# -# +# # -# Ideally, a (globally persistent) unique identifier for referring -# to this analysis. +# Simulation ID as an alias to refer to this simulation. # # -# +# # -# Possibility for leaving a free-text description about this analysis. +# Discouraged free-text field to add further details to the computation. # # -# -# -# Path to the directory where the tool should store NeXus/HDF5 results -# of this analysis. If not specified results will be stored in the -# current working directory. -# -# -# +# +# +# +# +# +# +# +# +# +# +# # -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when this configuration file was created. +# Programs and libraries representing the computational environment # -# -# +# +# +# +# +# +# +# # # Relevant data to instantiate a starting configuration that is typically # a microstructure in deformed conditions where stored (elastic) energy # is stored in the form of crystal defects, which in the SCORE model are # is considered as mean-field dislocation content. # -# +# +# +# +# Extend of each CA domain in voxel along the x, y, and z direction. +# Deformation of sheet material is assumed. +# The x axis is assumed pointing along the rolling direction. +# The y axis is assumed pointing along the transverse direction. +# The z axis is assumed pointing along the normal direction. +# +# +# +# +# +# +# +# Details how the deformed grains should be modelled. +# +# # # Which model should be used to generate a starting microstructure. # @@ -462,66 +525,43 @@ NXmicrostructure_score_config(NXobject): # # # -# +# # -# Edge length of the cubic cells of each CA domain. -# -# -# -# -# Extend of each CA domain in voxel along the x, y, and z direction. -# Deformation of sheet material is assumed. -# The x axis is assumed pointing along the rolling direction. -# The y axis is assumed pointing along the transverse direction. -# The z axis is assumed pointing along the normal direction. +# Extent of each deformed grain in voxel along the +# x, y, and z direction when type is cuboidal. # # # # # -# -# -# Extent of each deformed grain along the x, y, and z direction when type is -# cuboidal. -# -# -# -# -# -# +# # # Average spherical diameter when type is poisson_voronoi. # # -# +# # -# Set of Bunge-Euler angles to sample orientations randomly from. +# Set of Bunge-Euler angles ( :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` ) +# to sample orientations of deformed grains randomly from. # # # # # # -# +# # -# The EBSD dataset from which the initial microstructure is instantiated -# if initial_microstructure/type has value ebsd. +# The EBSD dataset from which the initial microstructure is +# instantiated if model is ebsd. # -# -# -# Path and name of the EBSD dataset from which to generate the starting -# microstructure. -# -# -# -# SHA256 checksum of the file which contains the EBSD dataset. -# -# -# +# +# +# +# # # -# Size of the EBSD. The EBSD orientation mapping has to be on a -# regular grid of square-shaped pixels. +# Extent of the pixel of the EBSD orientation mapping assuming square-shaped +# pixels. # # # @@ -529,17 +569,18 @@ NXmicrostructure_score_config(NXobject): # # # -# +# # -# Phenomenological model according to which it nuclei are placed -# into the domain and assumed growing. +# Phenomenological model according to which recrystallization nuclei +# are placed into the domain and assumed growing. # -# +# # -# According to which model will the nuclei become distributed spatially. -# CSR means complete spatial randomness. -# Custom is implementation specific. -# GB places nuclei at grain boundaries. +# According to which model will the nuclei become distributed spatially: +# +# * csr, complete spatial randomness. +# * custom, implementation specific. +# * gb, nuclei placed at grain boundaries # # # @@ -547,7 +588,7 @@ NXmicrostructure_score_config(NXobject): # # # -# +# # # According to which model will the nuclei start to grow. # @@ -555,7 +596,7 @@ NXmicrostructure_score_config(NXobject): # # # -# +# # # According to which model will the nuclei get their orientation assigned. # @@ -563,9 +604,10 @@ NXmicrostructure_score_config(NXobject): # # # -# +# # -# Set of Bunge-Euler angles to sample orientations of nuclei randomly from. +# Set of Bunge-Euler angles ( :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` ) +# to sample orientations of nuclei randomly from. # # # @@ -573,10 +615,11 @@ NXmicrostructure_score_config(NXobject): # # # -# +# # -# (Mechanical) properties of the material which scale the amount -# of stored (elastic) energy in the ROI/system. +# (Mechanical) properties of the material which scale +# the amount of stored (elastic) energy in the system and +# thus mainly affect recrystallization kinetics. # # # @@ -598,42 +641,98 @@ NXmicrostructure_score_config(NXobject): # # # -# +# # -# Model for the assumed mobility of grain boundaries with different -# disorientation. +# Model for the assumed mobility of grain boundaries with different disorientation +# essentially implementing variations of Turnbull's model for +# thermally-activated migration. # # # -# Which type of fundamental model for the grain boundary mobility: -# For the Sebald-Gottstein model the following equation is used. -# For the Rollett-Holm model the following equation is used. +# Which type of fundamental model for the grain boundary mobility. +# +# Grain boundaries with disorientation angle smaller than 15 degree are considered +# as low-angle grain boundaries. Other grain boundaries are high-angle boundaries. # +# # # # # # -# -# -# -# -# -# -# +# +# +# Parameter of the Sebald-Gottstein migration model. +# +# +# +# At which disorientation angle are grain boundary considered as high-angle grain +# boundaries. +# +# +# +# +# Pre-exponential factor for low-angle grain boundaries. +# +# +# +# +# Migration activation enthalpy for low-angle grain boundaries. +# +# +# +# +# Pre-exponential factor for high-angle grain boundaries. +# +# +# +# +# Migration activation enthalpy for high-angle grain boundaries. +# +# +# +# +# Pre-exponential factor for particularly mobile boundaries. +# +# +# +# +# Migration activation enthalpy for particularly mobile boundaries. +# +# # -# -# -# -# -# -# +# +# +# Parameter of the Rollett-Holm migration model. +# +# +# +# +# The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed +# temperature. GraGLeS was developed for modelling isothermal annealing. +# +# +# +# +# Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not one. +# +# +# +# +# Mobility scaling factor :math:`c_2`. Typically 5. +# +# +# +# +# Mobility scaling factor :math:`c_3`. Typically 9. +# +# # # -# +# # -# Simulated evolution of the dislocation density as the stored -# (elastic) energy assumed stored in each grain. +# Time-dependent reduction of the stored (elastic) energy to account for recovery. # # # @@ -644,11 +743,10 @@ NXmicrostructure_score_config(NXobject): # # # -# +# # -# Simulated reduction of the grain boundary speed due to -# the presence of dispersoids through which the total grain boundary -# area of the recrystallization front can be reduced. +# Reduction of the grain boundary migration speed due to the presence of dispersoids +# through which the total grain boundary area of the recrystallization front can be reduced. # # # @@ -659,16 +757,28 @@ NXmicrostructure_score_config(NXobject): # # # -# -# -# +# +# +# Parameter of the Zener-Smith drag model. +# +# +# +# Configuration-dependent constant which factorizes the drag pressure. +# +# +# +# +# Average surface energy of the grain-boundary-dispersoid-surface configuration +# which factorizes the drag pressure. +# +# # # # Support point of the linearized curve of simulated time matching # a specific support point of the average dispersoid radius. # # -# +# # # # @@ -676,14 +786,14 @@ NXmicrostructure_score_config(NXobject): # Support point of the linearized curve of the average dispersoid radius. # # -# +# # # # # -# +# # -# Simulated time temperature profile +# Desired simulated time-temperature profile # # # @@ -691,19 +801,19 @@ NXmicrostructure_score_config(NXobject): # a specific support point of the temperature. # # -# +# # # -# +# # # Support point of the linearized curve of the temperature. # # -# +# # # # -# +# # # Criteria which enable to stop the simulation in a controlled manner. # Whichever criterion is fulfilled first stops the simulation. @@ -724,7 +834,7 @@ NXmicrostructure_score_config(NXobject): # # # -# +# # # Settings relevant for stable numerical integration. # @@ -745,7 +855,7 @@ NXmicrostructure_score_config(NXobject): # # # By how much more times should the already allocated memory -# be is increased to offer space for storing states of cells +# be increased to offer space for storing states of cells # in the recrystallization front. # # @@ -762,20 +872,32 @@ NXmicrostructure_score_config(NXobject): # will be defragmented on-the-fly. # # -# +# # # -# +# +# +# # # List of recrystallized volume target values at which a -# snapshot of the CA state should be exported for. +# snapshot of the CA state should be stored. +# +# The code documents summary statistics like recrystallized volume fraction +# for each iteration. However, snapshots of the microstructure can take much +# space as SCORE is able to evolve automata with up to :math:`1600^3` cells. +# Snapshot data document the current microstructure which includes the grain +# assigned to each of these cells plus the state of the recrystallization front. +# +# Despite these front data make up for approximately one order of magnitude +# less cells than represented in the domain, more numerical data have to be +# collected each cell in the front than just a grain identifier. # # -# +# # # # -# +# # # # Perform a statistical analyses of the results as it was @@ -804,8 +926,5 @@ NXmicrostructure_score_config(NXobject): # # # -# -# -# # # diff --git a/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml index 0013926e25..4532bd3c9b 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml @@ -13,7 +13,6 @@ doc: | * `M. Kühbach et al. `_ * `C. Haase et al. `_ * `M. Diehl et al. `_ - symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -33,6 +32,7 @@ symbols: Number of active cells in the (recrystallization) front. n_grains: | Number of grains in the computer simulation. + # inspect comments behind NXmicrostructure type: group NXmicrostructure_score_results(NXobject): @@ -49,7 +49,7 @@ NXmicrostructure_score_results(NXobject): end_time(NX_DATE_TIME): exists: recommended (NXuser): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] program1(NXprogram): program_name: \@version: @@ -60,9 +60,10 @@ NXmicrostructure_score_results(NXobject): doc: | Programs and libraries representing the computational environment programID(NXprogram): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): - \@version(NX_CHAR): + \@version: + type: NX_CHAR coordinate_system_set(NXcoordinate_system_set): rotation_handedness: rotation_convention: @@ -89,7 +90,7 @@ NXmicrostructure_score_results(NXobject): z_direction: enumeration: [north] discretization(NXmicrostructure): - exists: [min, 1, max, 1] + exists: ['min', '1', 'max', '1'] grid(NXcg_grid): dimensionality(NX_POSINT): cardinality(NX_POSINT): @@ -101,6 +102,7 @@ NXmicrostructure_score_results(NXobject): boundary(NXcg_polyhedron_set): doc: | A tight bounding box or sphere or bounding primitive about the grid. + # a good example for a general bounding box description for such a grids of triclinic cells # https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallelepiped number_of_boundaries(NX_POSINT): @@ -120,16 +122,21 @@ NXmicrostructure_score_results(NXobject): 3 - mirror 4 - von Neumann 5 - Dirichlet - dim: (6,) + dimensions: + rank: 1 + dim: [[1, 6]] boundaries: doc: | Name of the boundaries. Left, right, front, back, bottom, top, The field must have as many entries as there are number_of_boundaries. - dim: (6,) + dimensions: + rank: 1 + dim: [[1, 6]] spatiotemporalID(NXobject): - exists: [min, 1, max, infty] # max 1 in case of classical CA simulation, i.e. without solitary units + exists: ['min', '1', 'max', 'unbounded'] doc: | Documentation of the spatiotemporal evolution + # static quantities for which no change is modelled # the typical lean summary statistics flattened summary_statistics(NXobject): @@ -143,24 +150,31 @@ NXmicrostructure_score_results(NXobject): doc: | Evolution of the recrystallized volume fraction over time. time(NX_NUMBER): - doc: | - Evolution of the physical time not to be confused with wall-clock time or profiling data. unit: NX_TIME - dim: (n_summary_stats,) + doc: | + Evolution of the physical time not to be confused with wall-clock time or + profiling data. + dimensions: + rank: 1 + dim: [[1, n_summary_stats]] iteration(NX_INT): + unit: NX_UNITLESS doc: | Iteration or increment counter. - unit: NX_UNITLESS temperature(NX_FLOAT): + unit: NX_TEMPERATURE doc: | Evolution of the simulated temperature over time. - unit: NX_TEMPERATURE - dim: (n_summary_stats,) + dimensions: + rank: 1 + dim: [[1, n_summary_stats]] recrystallized_volume_fraction(NX_FLOAT): + unit: NX_DIMENSIONLESS doc: | Recrystallized volume fraction. - unit: NX_DIMENSIONLESS - dim: (n_summary_stats,) + dimensions: + rank: 1 + dim: [[1, n_summary_stats]] stress(NXprocess): exists: optional type: @@ -168,20 +182,24 @@ NXmicrostructure_score_results(NXobject): Which type of stress. enumeration: [cauchy] stress(NX_FLOAT): + unit: NX_ANY doc: | Applied external stress tensor on the ROI. - unit: NX_ANY - dim: (n_summary_stats, 3, 3) + dimensions: + rank: 3 + dim: [[1, n_summary_stats], [2, 3], [3, 3]] strain(NXprocess): exists: optional type: doc: | Which type of strain. strain(NX_FLOAT): + unit: NX_ANY doc: | Applied external strain tensor on the ROI. - unit: NX_ANY - dim: (n_summary_stats, 3, 3) + dimensions: + rank: 3 + dim: [[1, n_summary_stats], [2, 3], [3, 3]] deformation_gradient(NXprocess): exists: optional type: @@ -189,57 +207,72 @@ NXmicrostructure_score_results(NXobject): Which type of deformation gradient. enumeration: [piola] value(NX_FLOAT): + unit: NX_ANY doc: | Applied deformation gradient tensor on the ROI. - unit: NX_ANY - dim: (n_summary_stats, 3, 3) + dimensions: + rank: 3 + dim: [[1, n_summary_stats], [2, 3], [3, 3]] magnetic_field(NXprocess): exists: optional strength(NX_FLOAT): + unit: NX_ANY doc: | Applied external magnetic field on the ROI. - unit: NX_ANY - dim: (n_summary_stats, 3, 3) + dimensions: + rank: 3 + dim: [[1, n_summary_stats], [2, 3], [3, 3]] electrical_field(NXprocess): exists: optional + # specify type of field strength(NX_FLOAT): + unit: NX_ANY doc: | Applied external electrical field on the ROI. - unit: NX_ANY - dim: (n_summary_stats, 3, 3) - # the typically storage-costlier snapshot data + dimensions: + rank: 3 + dim: [[1, n_summary_stats], [2, 3], [3, 3]] + + # the typically storage-costlier snapshot data microstructureID(NXmicrostructure): - exists: [min, 1, max, infty] # always storing starting configuration + exists: ['min', '1', 'max', 'unbounded'] time(NX_NUMBER): iteration(NX_INT): temperature(NX_FLOAT): + unit: NX_TEMPERATURE doc: | Simulated temperature for this snapshot. - unit: NX_TEMPERATURE x_value(NX_FLOAT): - doc: | - Current recrystallized volume fraction (taking fractional infections into account). unit: NX_DIMENSIONLESS - x_target(NX_NUMBER): doc: | - Target value for which a snapshot was requested for the recrystallized volume fraction. + Current recrystallized volume fraction (taking fractional infections into + account). + x_target(NX_NUMBER): unit: NX_DIMENSIONLESS + doc: | + Target value for which a snapshot was requested for the recrystallized volume + fraction. + # optional places to store the grid for instance if it changes grid(NXcg_grid): exists: recommended grain_identifier(NX_UINT): exists: recommended + unit: NX_UNITLESS doc: | Grain identifier for each cell. - unit: NX_UNITLESS - dim: (n_x, n_y, n_z) + dimensions: + rank: 3 + dim: [[1, n_x], [2, n_y], [3, n_z]] thread_identifier(NX_UINT): exists: optional + unit: NX_UNITLESS doc: | Identifier of the OpenMP thread which processed this part of the grid. - unit: NX_UNITLESS - dim: (n_x, n_y, n_z) + dimensions: + rank: 3 + dim: [[1, n_x], [2, n_y], [3, n_z]] crystal(NXobject): representation: exists: recommended @@ -247,96 +280,675 @@ NXmicrostructure_score_results(NXobject): number_of_phases(NX_UINT): crystal_identifier_offset(NX_INT): crystal_identifier(NX_INT): - dim: (n_grains,) + dimensions: + rank: 1 + dim: [[1, n_grains]] phase_identifier_offset(NX_INT): phase_identifier(NX_INT): - dim: (n_grains,) + dimensions: + rank: 1 + dim: [[1, n_grains]] volume(NX_NUMBER): + unit: NX_VOLUME doc: | Volume of each grain accounting also for partially transformed cells. - unit: NX_VOLUME - dim: (n_grains,) + dimensions: + rank: 1 + dim: [[1, n_grains]] + # SCORE specific - bunge_euler(NX_FLOAT): # only in the first snapshot + bunge_euler(NX_FLOAT): + unit: NX_ANGLE doc: | Bunge-Euler angle triplets for each grain. - unit: NX_ANGLE - dim: (n_grains, 3) + dimensions: + rank: 2 + dim: [[1, n_grains], [2, 3]] dislocation_density(NX_FLOAT): exists: recommended + unit: NX_ANY doc: | Current value for the dislocation density as a measure of the remaining stored energy in assumed crystal defects inside each grain. - unit: NX_ANY # 1/m^2 - dim: (n_grains,) + dimensions: + rank: 1 + dim: [[1, n_grains]] is_deformed(NX_BOOLEAN): exists: recommended doc: | Is the grain deformed. - dim: (n_grains,) + dimensions: + rank: 1 + dim: [[1, n_grains]] is_recrystallized(NX_BOOLEAN): exists: recommended doc: | Is the grain recrystallized. - dim: (n_grains,) + dimensions: + rank: 1 + dim: [[1, n_grains]] recrystallization_front(NXobject): exists: recommended doc: | - Details about those cells which in this time step represent the discrete recrystallization front. + Details about those cells which in this time step represent the discrete + recrystallization front. halo_region(NX_UINT): exists: optional + unit: NX_UNITLESS doc: | Which cells are currently in a halo region of threads. - unit: NX_UNITLESS - dim: (n_front,) + dimensions: + rank: 1 + dim: [[1, n_front]] mobility_weight(NX_FLOAT): exists: recommended + unit: NX_UNITLESS doc: | So-called mobility weight which is a scaling factor to control the mobility of the grain boundary which is assumed to sweep currently this volume. - unit: NX_UNITLESS - dim: (n_front,) + dimensions: + rank: 1 + dim: [[1, n_front]] coordinate(NX_NUMBER): exists: recommended + unit: NX_UNITLESS doc: | The x, y, z grid coordinates of each cell in the recrystallization front. - unit: NX_UNITLESS - dim: (n_front, 3) + dimensions: + rank: 2 + dim: [[1, n_front], [2, 3]] deformed_grain_identifier(NX_UINT): exists: recommended + unit: NX_UNITLESS doc: | Grain identifier assigned to each cell in the recrystallization front. - unit: NX_UNITLESS - dim: (n_front,) + dimensions: + rank: 1 + dim: [[1, n_front]] recrystallized_grain_identifier(NX_UINT): exists: recommended - doc: | - Grain identifier assigned to each nucleus which affected that cell in the recrystallization front. unit: NX_UNITLESS - dim: (n_front,) + doc: | + Grain identifier assigned to each nucleus which affected that cell in the + recrystallization front. + dimensions: + rank: 1 + dim: [[1, n_front]] thread_identifier(NX_UINT): exists: optional - doc: | - Identifier of the OpenMP thread processing each cell in the recrystallization front. unit: NX_UNITLESS - dim: (n_front,) + doc: | + Identifier of the OpenMP thread processing each cell in the recrystallization + front. + dimensions: + rank: 1 + dim: [[1, n_front]] infection_direction(NX_UINT): exists: optional + unit: NX_UNITLESS doc: | Hint about the direction from which the cell was infected. - unit: NX_UNITLESS - dim: (n_front,) - # performance(NXcs_profiling): - # exists: optional - # current_working_directory: - # command_line_call: - # exists: optional - # start_time(NX_DATE_TIME): - # exists: recommended - # end_time(NX_DATE_TIME): - # exists: recommended - # total_elapsed_time(NX_NUMBER): - # number_of_processes(NX_POSINT): - # number_of_threads(NX_POSINT): - # number_of_gpus(NX_POSINT): + dimensions: + rank: 1 + dim: [[1, n_front]] + + # performance(NXcs_profiling): + # exists: optional + # current_working_directory: + # command_line_call: + # exists: optional + # start_time(NX_DATE_TIME): + # exists: recommended + # end_time(NX_DATE_TIME): + # exists: recommended + # total_elapsed_time(NX_NUMBER): + # number_of_processes(NX_POSINT): + # number_of_threads(NX_POSINT): + # number_of_gpus(NX_POSINT): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 2f9eac16bf0971abe8628a9dc4ae40b3db3ff2315b3c3ae0ae5d3fdeb01c93b0 +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The total number of summary statistic log entries. +# +# +# +# +# Number of boundaries of the bounding box or primitive to domain. +# +# +# +# +# Number of parameter required for chosen orientation parameterization. +# +# +# +# +# Number of texture components identified. +# +# +# +# +# Dimensionality. +# +# +# +# +# Cardinality. +# +# +# +# +# Number of active cells in the (recrystallization) front. +# +# +# +# +# Number of grains in the computer simulation. +# +# +# +# +# Application definition for storing results of the SCORE cellular automaton. +# +# The SCORE cellular automaton model for primary recrystallization is an +# example of typical materials engineering applications used within the field +# of so-called Integral Computational Materials Engineering (ICME) whereby +# one can simulate the evolution of microstructures. +# +# Specifically the SCORE model can be used to simulate the growth of static +# recrystallization nuclei. The model is described in the literature: +# +# * `M. Kühbach et al. <https://doi.org/10.1016/j.actamat.2016.01.068>`_ +# * `C. Haase et al. <https://doi.org/10.1016/j.actamat.2015.08.057>`_ +# * `M. Diehl et al. <https://doi.org/10.1088/1361-651X/ab51bd>`_ +# +# +# +# +# +# +# +# +# +# Simulation ID as an alias to refer to this simulation. +# +# +# +# +# Discouraged free-text field to add further details to the computation. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Programs and libraries representing the computational environment +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# A tight bounding box or sphere or bounding primitive about the grid. +# +# +# +# +# How many distinct boundaries are distinguished? +# Most grids discretize a cubic or cuboidal region. In this case +# six sides can be distinguished, each making an own boundary. +# +# +# +# +# The boundary conditions for each boundary: +# +# 0 - undefined +# 1 - open +# 2 - periodic +# 3 - mirror +# 4 - von Neumann +# 5 - Dirichlet +# +# +# +# +# +# +# +# Name of the boundaries. Left, right, front, back, bottom, top, +# The field must have as many entries as there are number_of_boundaries. +# +# +# +# +# +# +# +# +# +# Documentation of the spatiotemporal evolution +# +# +# +# +# Summary quantities which are the result of some post-processing of the snapshot data +# (averaging, integrating, interpolating) happening in for practical reasons though in while +# running the simulation. Place used for storing descriptors from continuum mechanics +# and thermodynamics at the scale of the entire ROI. +# +# +# +# Evolution of the recrystallized volume fraction over time. +# +# +# +# Evolution of the physical time not to be confused with wall-clock time or +# profiling data. +# +# +# +# +# +# +# +# Iteration or increment counter. +# +# +# +# +# Evolution of the simulated temperature over time. +# +# +# +# +# +# +# +# Recrystallized volume fraction. +# +# +# +# +# +# +# +# +# +# Which type of stress. +# +# +# +# +# +# +# +# Applied external stress tensor on the ROI. +# +# +# +# +# +# +# +# +# +# +# +# Which type of strain. +# +# +# +# +# Applied external strain tensor on the ROI. +# +# +# +# +# +# +# +# +# +# +# +# Which type of deformation gradient. +# +# +# +# +# +# +# +# Applied deformation gradient tensor on the ROI. +# +# +# +# +# +# +# +# +# +# +# +# Applied external magnetic field on the ROI. +# +# +# +# +# +# +# +# +# +# +# +# +# Applied external electrical field on the ROI. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Simulated temperature for this snapshot. +# +# +# +# +# Current recrystallized volume fraction (taking fractional infections into +# account). +# +# +# +# +# Target value for which a snapshot was requested for the recrystallized volume +# fraction. +# +# +# +# +# +# +# Grain identifier for each cell. +# +# +# +# +# +# +# +# +# +# Identifier of the OpenMP thread which processed this part of the grid. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Volume of each grain accounting also for partially transformed cells. +# +# +# +# +# +# +# +# +# Bunge-Euler angle triplets for each grain. +# +# +# +# +# +# +# +# +# Current value for the dislocation density as a measure of the remaining stored energy +# in assumed crystal defects inside each grain. +# +# +# +# +# +# +# +# Is the grain deformed. +# +# +# +# +# +# +# +# Is the grain recrystallized. +# +# +# +# +# +# +# +# +# Details about those cells which in this time step represent the discrete +# recrystallization front. +# +# +# +# Which cells are currently in a halo region of threads. +# +# +# +# +# +# +# +# So-called mobility weight which is a scaling factor to +# control the mobility of the grain boundary which is assumed +# to sweep currently this volume. +# +# +# +# +# +# +# +# The x, y, z grid coordinates of each cell in the recrystallization front. +# +# +# +# +# +# +# +# +# Grain identifier assigned to each cell in the recrystallization front. +# +# +# +# +# +# +# +# Grain identifier assigned to each nucleus which affected that cell in the +# recrystallization front. +# +# +# +# +# +# +# +# Identifier of the OpenMP thread processing each cell in the recrystallization +# front. +# +# +# +# +# +# +# +# Hint about the direction from which the cell was infected. +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXmicrostructure_slip_system.yaml b/contributed_definitions/nyaml/NXmicrostructure_slip_system.yaml index f72d937f60..488da7c104 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_slip_system.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_slip_system.yaml @@ -13,19 +13,109 @@ NXmicrostructure_slip_system(NXobject): Bravais lattice type enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, trigonal, hexagonal, cubic] miller_plane(NX_NUMBER): + unit: NX_UNITLESS doc: | Array of Miller indices which describe the crystallographic planes. - unit: NX_UNITLESS - dim: (n, i) + dimensions: + rank: 2 + dim: [[1, n], [2, i]] + # fastest changing dimension needs to be i and not 3 because for instance for hexagonal hkil notation is used miller_direction(NX_NUMBER): + unit: NX_UNITLESS doc: | Array of Miller indices which describe the crystallographic direction. - unit: NX_UNITLESS - dim: (n, i) + dimensions: + rank: 2 + dim: [[1, n], [2, i]] is_specific(NX_BOOLEAN): unit: NX_UNITLESS doc: | For each slip system a marker whether the specified Miller indices refer to a specific or a crystallographic equivalent set of the slip system. - dim: (n,) + dimensions: + rank: 1 + dim: [[1, n]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 9998fb9937b87e1135df6fe1db659d42a69f77a9c7d2acb969b70c99a84b339a +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of slip systems. +# +# +# +# +# Base class for describing a set of crystallographic slip systems. +# +# +# +# Bravais lattice type +# +# +# +# +# +# +# +# +# +# +# +# +# +# Array of Miller indices which describe the crystallographic planes. +# +# +# +# +# +# +# +# +# +# Array of Miller indices which describe the crystallographic direction. +# +# +# +# +# +# +# +# +# For each slip system a marker whether the specified Miller indices refer to +# a specific or a crystallographic equivalent set of the slip system. +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXopt_window.yaml b/contributed_definitions/nyaml/NXopt_window.yaml index ef0fa19ce4..7550543cea 100644 --- a/contributed_definitions/nyaml/NXopt_window.yaml +++ b/contributed_definitions/nyaml/NXopt_window.yaml @@ -1,10 +1,10 @@ category: base doc: | A window of a cryostat, heater, vacuum chamber or a simple glass slide. - + This first verion originates from NXopt to describe cryostate windows and possible influences for ellipsometry measurements. - + For environmental measurements, the environment (liquid, vapor etc.) is enclosed in a cell, which has windows both in the direction of the source (entry window) and the detector (exit @@ -23,6 +23,7 @@ doc: | The window is considered to be a part of the sample stage but also beam path. Hence, its position within the beam path should be defined by the 'depends_on' field. + # A draft of a new base class to describe a window in a optical setup or device type: group NXopt_window(NXaperture): @@ -71,3 +72,134 @@ NXopt_window(NXaperture): doc: | Angle of the window normal (outer) vs. the substrate normal (similar to the angle of incidence). + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 307ae4819eb6142166f995b2b9baeb2880d3e204b26eae70590096c0b898213e +# +# +# +# +# +# +# A window of a cryostat, heater, vacuum chamber or a simple glass slide. +# +# This first verion originates from NXopt to describe cryostate windows +# and possible influences for ellipsometry measurements. +# +# For environmental measurements, the environment (liquid, vapor +# etc.) is enclosed in a cell, which has windows both in the +# direction of the source (entry window) and the detector (exit +# window) (looking from the sample). In case that the entry and exit +# windows are not the same type and do not have the same properties, +# use a second 'WINDOW(NXaperture)' field. +# +# The windows also add a phase shift to the light altering the +# measured signal. This shift has to be corrected based on measuring +# a known sample (reference sample) or the actual sample of interest +# in the environmental cell. State if a window correction has been +# performed in 'window_effects_corrected'. Reference data should be +# considered as a separate experiment, and a link to the NeXus file +# should be added in reference_data_link in measured_data. +# +# The window is considered to be a part of the sample stage but also +# beam path. Hence, its position within the beam path should be +# defined by the 'depends_on' field. +# +# +# +# +# Was a window correction performed? If 'True' describe the window +# correction procedure in 'window_correction/procedure'. +# +# +# +# +# Type of effects due to this window on the measurement. +# +# +# +# +# +# +# +# +# +# +# Was a window correction performed? If 'True' describe the +# window correction procedure in '' +# +# +# +# Describe when (before or after the main measurement + time +# stamp in 'date') and how the window effects have been +# corrected, i.e. either mathematically or by performing a +# reference measurement. In the latter case, provide the link to +# to the reference data in 'reference_data_link'. +# +# +# +# +# Link to the NeXus file which describes the reference data if a +# reference measurement for window correction was performed. +# Ideally, the reference measurement was performed on a reference +# sample and on the same sample, and using the same conditions as +# for the actual measurement with and without windows. It should +# have been conducted as close in time to the actual measurement +# as possible. +# +# +# +# +# +# The material of the window. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# If you specified 'other' as material, decsribe here what it is. +# +# +# +# +# Thickness of the window. +# +# +# +# +# Angle of the window normal (outer) vs. the substrate normal +# (similar to the angle of incidence). +# +# +# +# diff --git a/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml b/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml index 923e2f5023..e71d573fa4 100644 --- a/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml +++ b/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml @@ -1,14 +1,14 @@ category: application doc: | - A general application definition of optical spectroscopy elements, which may + A general application definition of optical spectroscopy elements, which may be used as a template to derive specialized optical spectroscopy experiments. Possible specializations are ellipsometry, Raman spectroscopy, photoluminescence, reflectivity/transmission spectroscopy. - + A general optical experiment consists of (i) a light/photon source, (ii) a sample, (iii) a detector. - + For any free text descriptions, it is recommended to enter data in english language, as this is the most FAIR representation. symbols: @@ -26,17 +26,16 @@ symbols: # 04/2024 # Extension of the Draft Version (05/2023) of a NeXus application definition which # serves as a template for various optical spectroscopy experiments -# # TODO: # - Add NXlens_opt and NXwaveplate to NXinstrument? -# - Make polfilter_TYPE(NXbeam_device) own base class --> rework NXpolarizer_opt. and add them to NXinstrument. -# - Make spectralfilter_TYPE(NXbeam_device) own base class --> extend NXfilter? and add them to NXinstrument. -# - Make offset angles for polar and azimutal? +# - Make polfilter_TYPE(NXbeam_device) own base class -\-> rework NXpolarizer_opt. and add them to NXinstrument. +# - Make spectralfilter_TYPE(NXbeam_device) own base class -\-> extend NXfilter? and add them to NXinstrument. +# - Make offset angles for polar and azimutal? # - Can angle_reference_frame be replaced later by only using reference_frames and generic angle description? -# - Add optical elements and rework them: NXfiber, NXbeam_splitter, +# - Add optical elements and rework them: NXfiber, NXbeam_splitter, # - Consider to make power flux recommended? Difficult parameter to measure. Relevant for some samples/techniques, but not for all. Powder density? Nominal vs. measured? # - Is there something to describe the spot size? -# - Restructure the concept "type" in "source_TYPE" to medium and model(NXfabication) --> suggestion from Markus: "splitting up the concept into type(NXfabrication) and emitting medium(NXion/NXatom) is a better alternative?" +# - Restructure the concept "type" in "source_TYPE" to medium and model(NXfabication) -\-> suggestion from Markus: "splitting up the concept into type(NXfabrication) and emitting medium(NXion/NXatom) is a better alternative?" # - How to describe beam size properties? NXbeam/extend? Is this enough? or do we need more abitrary shapes as elliptically? Maybe as well focus spot size? # - Think of removing/reworking of (optional) NXfabrications? Con: bloats up the NeXus def (move it to base classes?) Pro: as the fixed name device_information is used, the structure is more FAIR / clean designed? type: group @@ -70,7 +69,7 @@ NXoptical_spectroscopy(NXobject): Datetime of the end of the measurement. Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, otherwise the local time zone is assumed per ISO8601. - + It is required to enter at least one of both measurement times, either "start_time" or "end_time". experiment_identifier(NXidentifier): exists: recommended @@ -101,7 +100,7 @@ NXoptical_spectroscopy(NXobject): Users are strongly advised to parameterize the description of their experiment by using respective groups and fields and base classes instead of writing prose into this field. - + The reason is that such a free-text field is difficult to machine-interpret. The motivation behind keeping this field for now is to learn how far the current base classes need extension based on user feedback. @@ -111,7 +110,7 @@ NXoptical_spectroscopy(NXobject): Chose other if none of these methods are suitable. You may specify fundamental characteristics or properties in the experimental sub-type. - + For Raman spectroscopy or ellipsometry use the respective specializations of NXoptical_spectroscopy. enumeration: [photoluminescence, transmission spectroscopy, reflection spectroscopy, other] @@ -132,7 +131,7 @@ NXoptical_spectroscopy(NXobject): doc: | Description of one or more coordinate systems that are specific to the experiment. Examples are beam centered, sample-normal centered, - laboratory-system centered, sample-stage centered, crystal-symmetry centered. + laboratory-system centered, sample-stage centered, crystal-symmetry centered. beam_ref_frame(NXcoordinate_system): exists: optional depends_on(NX_CHAR): @@ -159,14 +158,14 @@ NXoptical_spectroscopy(NXobject): Set of transformations, describing the orientation of the sample-normal coordinate system with respect to the beam coordinate system (.). (NXuser): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] doc: | Contact information and eventually details of at persons who performed the measurements. This can be for example the principal investigator or student. Examples are: name, affiliation, address, telephone - number, email, role as well as identifiers such as orcid or similar. + number, email, role as well as identifiers such as orcid or similar. It is recommended to add multiple users if relevant. - + Due to data privacy concerns, there is no minimum requirement. If no user with specific name is allowed to be given, it is required to assign at least an affiliation @@ -186,19 +185,19 @@ NXoptical_spectroscopy(NXobject): - Stages(NXmanipulator) - Sensors and actuators to control or measure sample or beam properties beam_TYPE(NXbeam): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] doc: | This can be used to describe properties of a photon beam. A beam is always defined between two beam_devices, via "previous_device" and "next_device". - + It is required to define at least one incident beam which is incident to the sample. You may specify if this beam parameters are acutally measured or just nominal. If this beam is the output of a source, chose the same name appendix as for the NXsource instance (e.g. TYPE=532nm) parameter_reliability: - exists: required + exists: optional doc: | Select the reliability of the respective beam characteristics. Either, the parameters are measured via another device or method or just given @@ -216,7 +215,7 @@ NXoptical_spectroscopy(NXobject): exists: optional doc: | The path to the device which emitted this beam (light source or frequency doubler). - + This parameter is recommended, if the previous optical element is a photon source. In this way, the properties of the laser or light souce can be described and associated. @@ -225,20 +224,21 @@ NXoptical_spectroscopy(NXobject): "source_532nmlaser" and a NXbeam named "beam_532nmlaser". Example: /entry/instrument/source_532nmlaser + # The two polarization descriptions may be completely replaced by polarization beam_polarization_type: exists: optional enumeration: [linear, circular, ellipically, unpolarized] linear_beam_sample_polarization(NX_NUMBER): exists: optional + unit: NX_ANGLE doc: | Angle of the linear polarized light, with respect to a fixed arbitrary defined 0° position. This can be used if no definition of respective cooridnate systems for beam and sample normal is done. If coordinate systems are defined, refer to beam "incident_polarization". - unit: NX_ANGLE detector_TYPE(NXdetector): - exists: [min, 1, max, infty] + exists: ['min', '1', 'max', 'unbounded'] detector_channel_type: enumeration: [single-channel, multichannel] detector_type: @@ -258,33 +258,32 @@ NXoptical_spectroscopy(NXobject): due to hardware pre-processing of the data. This field ideally collects the data with the lowest level of processing possible. - - # Define a similar convention for NXoptical_spectroscopy? Or only for NXraman, NXellipsometry and NXphotoluminescence? - # Fields should be named according to new following convention: - # - # - **pixel_x**: Detector pixel in x direction. - # - **pixel_y**: Detector pixel in y direction. - # - **energy**: (Un)calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). - # - **kx**: (Un)calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). - # - **ky**: (Un)calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). - # - **kz**: (Un)calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). - # - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). - # Unit category: NX_ANGLE - # - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - # Unit category: NX_ANGLE - # - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) - # Unit category: NX_LENGTH - # - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - # Unit category: NX_LENGTH - # - **delay**: Calibrated delay time. Unit category: NX_TIME (s). - # - **polarization_angle**: Linear polarization angle of the incoming or - # outgoing beam. - # Unit category: NX_ANGLE (° or rad) - # - **ellipticity**: Ellipticity of the incoming or outgoing beam. - # Unit category: NX_ANGLE (° or rad) - # - **time_of_flight**: Total time of flight. Unit category: NX_TIME_OF_FLIGHT - # - **time_of_flight_adc**: Time-of-flight values, analog-to-digital converted. - # - **external_AXIS**: Describes an axis which is coming from outside the detectors scope. + + # Define a similar convention for NXoptical_spectroscopy? Or only for NXraman, NXellipsometry and NXphotoluminescence? + # Fields should be named according to new following convention: + # - **pixel_x**: Detector pixel in x direction. + # - **pixel_y**: Detector pixel in y direction. + # - **energy**: (Un)calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). + # - **kx**: (Un)calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). + # - **ky**: (Un)calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). + # - **kz**: (Un)calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). + # - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). + # Unit category: NX_ANGLE + # - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) + # Unit category: NX_ANGLE + # - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) + # Unit category: NX_LENGTH + # - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) + # Unit category: NX_LENGTH + # - **delay**: Calibrated delay time. Unit category: NX_TIME (s). + # - **polarization_angle**: Linear polarization angle of the incoming or + # outgoing beam. + # Unit category: NX_ANGLE (° or rad) + # - **ellipticity**: Ellipticity of the incoming or outgoing beam. + # Unit category: NX_ANGLE (° or rad) + # - **time_of_flight**: Total time of flight. Unit category: NX_TIME_OF_FLIGHT + # - **time_of_flight_adc**: Time-of-flight values, analog-to-digital converted. + # - **external_AXIS**: Describes an axis which is coming from outside the detectors scope. \@signal: enumeration: [raw] raw(NX_NUMBER): @@ -293,9 +292,9 @@ NXoptical_spectroscopy(NXobject): additional_detector_hardware: exists: optional doc: | - Specify respective hardware which was used for the detector. For - example special electronics required for time-correlated single photon - counting (TCSPC). + Specify respective hardware which was used for the detector. For + example special electronics required for time-correlated single photon + counting (TCSPC). device_information(NXfabrication): exists: recommended source_TYPE(NXsource): @@ -331,13 +330,12 @@ NXoptical_spectroscopy(NXobject): exists: recommended device_information(NXfabrication): exists: recommended - angle_reference_frame: exists: recommended doc: | Defines the reference frame which is used to describe the sample orientation with respect to the beam directions. - + A beam centered description is the default and uses 4 angles(similar to XRD): - Omega (angle between sample surface and incident beam) - 2Theta (angle between the transmitted beam and the detection beam) @@ -345,21 +343,19 @@ NXoptical_spectroscopy(NXobject): plane#1 = spanned by incidence beam and detection and detection. If Chi=0°, then plane#1 is the plane of incidence in reflection setups) - - Phi (inplane rotation of sample, rotation axis is the samples + - Phi (inplane rotation of sample, rotation axis is the samples surface normal) - - + + A sample normal centered description is as well possible: - angle of incidence (angle between incident beam and sample surface) - angle of detection (angle between detection beam and sample surface) - angle of incident and detection beam - angle of in-plane sample rotation (direction along the sample's surface normal) - + An arbitrary reference frame can be defined by "reference_frames" and used via "instrument/angle_sample_and_beam_TYPE" - enumeration: [beam centered, sample-normal centered] - omega(NX_NUMBER): exists: optional unit: NX_ANGLE @@ -381,7 +377,6 @@ NXoptical_spectroscopy(NXobject): unit: NX_ANGLE doc: | Inplane rotation of the sample, with rotation axis along sample normal. - angle_of_incidence(NX_NUMBER): exists: optional unit: NX_ANGLE @@ -416,7 +411,6 @@ NXoptical_spectroscopy(NXobject): angle without specific relation to the sample symmetry, of the angle to a specific sample property (i.e. crystallographic axis or sample shape such as wafer flat) - generic_beam_sample_angle_TYPE(NXtransformations): exists: recommended doc: | @@ -426,16 +420,16 @@ NXoptical_spectroscopy(NXobject): angles to define the direction via sperical coordinates. This allows consistent defintion between different coordinate system. You may refer to self defined coordinate system as well. - - + + If "angle_reference_frame = beam centered", then this coordinate system is used: McStas system (NeXus default) (https://manual.nexusformat.org/design.html#mcstas-and-nxgeometry-system) - + i.e. the z-coordinate math:`[0,0,1]` is along the incident beam direction and the x-coordinate math:`[1,0,0]` is in the horizontal plane. Hence, usually math:`[0,1,0]` is vertically oriented. - + If "angle_reference_frame = sample-normal centered", then this coordinate system is used z - math:`[0,0,1]` along sample surface normal @@ -467,17 +461,14 @@ NXoptical_spectroscopy(NXobject): enumeration: [[0, 0, 1]] \@depends_on: enumeration: [offset_tilt] - - lateral_focal_point_offset(NX_NUMBER): exists: optional unit: NX_LENGTH doc: | - Specify if there is a lateral offset on the sample surface, between the focal + Specify if there is a lateral offset on the sample surface, between the focal points of the incident beam and the detection beam. - (NXbeam_device): - exists: [min, 0, max, infty] + exists: ['min', '0', 'max', 'unbounded'] doc: | Describes the order of respective beam devices in the optical beam path. @@ -485,7 +476,7 @@ NXoptical_spectroscopy(NXobject): Everything object which interacts or modifies optical beam properties, may be an beam device, e.g. Filter, Window, Beamsplitter, Photon Source, Detector, etc, - + It is intended, to include this functionality later to "older" beam components, such as NXsource, NXdetector, NXlens, etc. Until this is possbible, auxillary beam devices have to be created, @@ -520,7 +511,7 @@ NXoptical_spectroscopy(NXobject): polfilter_TYPE(NXbeam_device): exists: optional doc: | - polarization filter to prepare light to be measured or to be incident + polarization filter to prepare light to be measured or to be incident on the sample. Genereric polarization filter porperties may be implemented via NXfilter_pol at a later stage. @@ -536,7 +527,7 @@ NXoptical_spectroscopy(NXobject): Specific name or type of the polarizer used. Free text, for example: Glan-Thompson, Glan-Taylor, Rochon Prism, Wollaston - Polarizer... + Polarizer... device_information(NXfabrication): exists: optional spectralfilter_TYPE(NXbeam_device): @@ -570,22 +561,22 @@ NXoptical_spectroscopy(NXobject): enumeration: [transmission, reflection] device_information(NXfabrication): exists: optional + # Later for rework of specific optical elements - #(NXbeam_splitter): - # exists: optional - # doc: | - # Can be used to describe a beam splitter as optical element. - + # (NXbeam_splitter): + # exists: optional + # doc: | + # Can be used to describe a beam splitter as optical element. (NXbeam_transfer_matrix_table): exists: optional doc: | Allows description of beam properties via matrices, which relate ingoing with - outgoing beam properties. + outgoing beam properties. sample_stage(NXmanipulator): exists: optional doc: | Sample stage (or manipulator) for positioning of the sample. This should - only contain the spatial orientation of movement. + only contain the spatial orientation of movement. stage_type: exists: optional doc: | @@ -600,7 +591,7 @@ NXoptical_spectroscopy(NXobject): exists: optional doc: | This allows a description of the stages relation or orientation and - position with respect to the sample or beam, if an laboratory or + position with respect to the sample or beam, if an laboratory or an stage coordinate system is defined. beam_sample_relation: exists: optional @@ -608,7 +599,7 @@ NXoptical_spectroscopy(NXobject): Description of relation of the beam with the sample. How dit the sample hit the beam, e.g. 'center of sample, long edge parallel to the plane of incidence'. - Is redundent, if a full orientation description is done via the + Is redundent, if a full orientation description is done via the stages "transformations" entry. device_information(NXfabrication): exists: optional @@ -624,10 +615,10 @@ NXoptical_spectroscopy(NXobject): device_information(NXfabrication): exists: optional temp_control_TYPE(NXactuator): - doc: - Type of control for the sample temperature. Replace TYPE by - "cryostat" or "heater" to specify it. exists: optional + doc: | + Type of control for the sample temperature. Replace TYPE by "cryostat" or + "heater" to specify it. name: exists: recommended physical_quantity: @@ -645,7 +636,6 @@ NXoptical_spectroscopy(NXobject): exists: recommended device_information(NXfabrication): exists: optional - device_information(NXfabrication): exists: recommended doc: | @@ -682,7 +672,6 @@ NXoptical_spectroscopy(NXobject): doc: | Description of the software by persistent resource, where the program, code, script etc. can be found. - instrument_calibration_DEVICE(NXcalibration): exists: recommended doc: | @@ -718,8 +707,6 @@ NXoptical_spectroscopy(NXobject): doc: | Generic data which does not fit to the 'NX_FLOAT' fields in NXproces. This can be for example the instrument response function. - - wavelength_resolution(NXresolution): exists: optional doc: | @@ -743,8 +730,6 @@ NXoptical_spectroscopy(NXobject): dimensions: rank: 2 dim: [[1, 2], [2, N_spectrum]] - - (NXsample): doc: | Properties of the sample, such as sample type, layer structure, @@ -838,25 +823,28 @@ NXoptical_spectroscopy(NXobject): doc: | Medium, in which the sample is placed. enumeration: [air, vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere, sealed can, water, other] + + # Make something like NXlayer_structure_sample? thickness(NX_NUMBER): - # Make something like NXlayer_structure_sample? exists: optional + unit: NX_LENGTH doc: | (Measured) sample thickness. The information is recorded to qualify if the light used was likely - able to shine through the sample. + able to shine through the sample. In this case the value should be set to the actual thickness of the specimen viewed for an illumination situation where the nominal surface normal of the specimen is parallel to the optical axis. - unit: NX_LENGTH thickness_determination: exists: optional doc: | - If a thickness if given, please specify how this thickness was estimated or determined. - layer_structure: + If a thickness if given, please specify how this thickness was estimated or + determined. + # Maybe consider here to include NXsample_component_set. + layer_structure: exists: optional doc: | Qualitative description of the layer structure for the sample, @@ -879,10 +867,10 @@ NXoptical_spectroscopy(NXobject): Here generic types of data may be saved.. This may refer to data derived from single or multiple raw measurements (i.e. several intensities are evaluated for different parameters: ellipsometry -> psi and delta) - - i.e. non-raw data. + i.e. non-raw data. As well plotable data may be stored/linked here, which provides the most suitable representation of the data (for the respective community). - + You may provide multiple instances of NXdata \@axes: doc: | @@ -898,14 +886,16 @@ NXoptical_spectroscopy(NXobject): exists: recommended doc: | Location to save the calibrated wavelength data. + # The old "data_collection(NXprocess)" is now replaced by more flexbile # NXdata. The detailed inclusion of a data collection description (i.e. # raw data from ellipsometry as polarization values to the usually used # psi and delta values), will be done later after the NXopt workshop. derived_parameters(NXprocess): exists: optional - # >>>This section is transfered from the first NXoptical_spectroscopy version and might - # require a reqwork.<<< + + # >>>This section is transfered from the first NXoptical_spectroscopy version and might + # require a reqwork.<<< doc: | Parameters that are derived from the measured data. depolarization(NX_NUMBER): @@ -957,14 +947,14 @@ NXoptical_spectroscopy(NXobject): deterministic manner. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 7d68d553b6c55f5cdd8fe8d92c325b137c71c875c2bd742f5cf2150df56f4398 -# +# 077a817b91550b6db26aa39a2bb23a6075be62562022208c17b19a8fec1afcc2 +# # # -# -# -# +# +# # # # Variables used throughout the document, e.g. dimensions or parameters. @@ -999,12 +999,6 @@ NXoptical_spectroscopy(NXobject): # data. # # -# -# -# Number of sensors used to measure parameters that influence the sample, -# such as temperature or pressure. -# -# # # # Number of measurements (1st dimension of measured_data array). This is @@ -1013,38 +1007,21 @@ NXoptical_spectroscopy(NXobject): # N_measurements = 2*3 = 6. # # -# -# -# Number of detection angles of the beam reflected or scattered off the -# sample. -# -# -# -# -# Number of angles of incidence of the incident beam. -# -# -# -# -# Number of observables that are saved in a measurement. e.g. one for -# intensity, reflectivity or transmittance, two for Psi and Delta etc. This -# is equal to the second dimension of the data array 'measured_data' and the -# number of column names. -# -# # # -# An application definition for optical spectroscopy experiments. +# A general application definition of optical spectroscopy elements, which may +# be used as a template to derive specialized optical spectroscopy experiments. +# +# Possible specializations are ellipsometry, Raman spectroscopy, photoluminescence, +# reflectivity/transmission spectroscopy. +# +# A general optical experiment consists of (i) a light/photon source, (ii) a sample, +# (iii) a detector. +# +# For any free text descriptions, it is recommended to enter data in english +# language, as this is the most FAIR representation. # # -# -# An application definition template for optical spectroscopy experiments. -# -# A general optical experiment consists of a light or excitation source, a -# beam path, a sample + its stage + its environment, and a detection unit. -# Examples are reflection or transmission measurements, photoluminescence, -# Raman spectroscopy, ellipsometry etc. -# # # # An application definition describing a general optical experiment. @@ -1055,229 +1032,679 @@ NXoptical_spectroscopy(NXobject): # definition was used for this entry/data. # # -# +# # # URL where to find further material (documentation, examples) relevant # to the application definition. # # # -# +# # # -# +# +# +# +# Datetime of the start of the measurement. +# Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, +# otherwise, the local time zone is assumed per ISO8601. +# +# It is required to enter at least one of both measurement times, either "start_time" or "end_time". +# +# +# +# +# Datetime of the end of the measurement. +# Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, +# otherwise the local time zone is assumed per ISO8601. +# +# It is required to enter at least one of both measurement times, either "start_time" or "end_time". +# +# +# # # A (globally persistent) unique identifier of the experiment. -# (i) The identifier is usually defined by the facility or principle -# investigator. +# (i) The identifier is usually defined by the facility, laboratory or +# principal investigator. # (ii) The identifier enables to link experiments to e.g. proposals. # -# +# +# +# +# +# Select the range of validity of this identier. +# Local: Setup#1 at Institute building #2 in Room #3 +# Global: Unique identification of with by unique location and unique +# globally persistent time stamp. +# +# +# +# +# +# +# +# # # # An optional free-text description of the experiment. # -# However, details of the experiment should be defined in the specific -# fields of this application definition rather than in this experiment -# description. +# Users are strongly advised to parameterize the description of their experiment +# by using respective groups and fields and base classes instead of writing prose +# into this field. +# +# The reason is that such a free-text field is difficult to machine-interpret. +# The motivation behind keeping this field for now is to learn how far the +# current base classes need extension based on user feedback. # # # # # Specify the type of the optical experiment. +# +# Chose other if none of these methods are suitable. You may specify +# fundamental characteristics or properties in the experimental sub-type. +# +# For Raman spectroscopy or ellipsometry use the respective specializations +# of NXoptical_spectroscopy. +# +# +# +# +# +# +# +# +# +# +# Specify a special property or characteristic of the experiment, which specifies +# the generic experiment type. # +# +# +# +# +# +# # -# +# # -# Start time of the experiment. UTC offset should be specified. +# If "other" was selected in "experiment_type" and/or in "experiment_sub_type", +# specify the experiment here with a free text name, which is knwon in the +# respective community of interest. # # -# +# # -# Contact information of at least the user of the instrument or the -# investigator who performed this experiment. -# Adding multiple users, if relevant, is recommended. +# Description of one or more coordinate systems that are specific to the +# experiment. Examples are beam centered, sample-normal centered, +# laboratory-system centered, sample-stage centered, crystal-symmetry centered. # -# +# +# +# +# This refers to the coordinate system along the beam path. The origin and +# base is defined at z=0, where the incident beam hits the sample at the surface. +# +# +# +# +# This is the default NeXus coordinate system (McStas), if the transformation +# does not change the coordinate system at all - i.e. it is unity. +# Otherwise, by this a respective transformation of the beam +# reference frame to the default reference frame could be made. i.e. +# exchange of x and z coordinate, rotation of respective coordinates +# towards each other. +# +# +# +# +# +# +# Link to transformations defining the sample-normal base coordinate system, +# which is defined such that the positive z-axis is parallel to the sample normal, +# and the x-y-plane lies inside the sample surface. +# +# +# +# +# Set of transformations, describing the orientation of the sample-normal coordinate system +# with respect to the beam coordinate system (.). +# +# +# +# +# +# +# Contact information and eventually details of at persons who +# performed the measurements. This can be for example the principal +# investigator or student. Examples are: name, affiliation, address, telephone +# number, email, role as well as identifiers such as orcid or similar. +# It is recommended to add multiple users if relevant. +# +# Due to data privacy concerns, there is no minimum requirement. +# If no user with specific name is allowed to be given, it is required to +# assign at least an affiliation +# +# +# +# +# Devices or elements of the optical spectroscopy setup described with its +# properties and general information. +# +# This includes for example: +# - The beam device's or instrument's model, company, serial number, construction year, etc. +# - Used software or code +# - Experiment descriptive parameters as reference frames, resolution, calibration +# - Photon beams with their respective properties such as angles and polarization +# - Various optical beam path devices, which interact, manipulate or measure optical beams +# - Characteristics of the medium surrounding the sample +# - "Beam devices" for a beam path description +# - Stages(NXmanipulator) +# - Sensors and actuators to control or measure sample or beam properties +# +# # -# Name of the user. +# This can be used to describe properties of a photon beam. +# A beam is always defined between two beam_devices, via +# "previous_device" and "next_device". +# +# It is required to define at least one incident beam which is incident +# to the sample. You may specify if this beam parameters are acutally measured +# or just nominal. +# If this beam is the output of a source, chose the same +# name appendix as for the NXsource instance (e.g. TYPE=532nm) # +# +# +# Select the reliability of the respective beam characteristics. Either, +# the parameters are measured via another device or method or just given +# nominally via the properties of a light source properties (532nm, 100mW). +# +# +# +# +# +# +# +# +# +# +# +# +# The path to the device which emitted this beam (light source or frequency doubler). +# +# This parameter is recommended, if the previous optical element is a photon source. +# In this way, the properties of the laser or light souce can be described +# and associated. +# The beam should be named with the same appendix as the source, e.g., +# for TYPE=532nmlaser, there should be both a NXsource named +# "source_532nmlaser" and a NXbeam named "beam_532nmlaser". +# +# Example: /entry/instrument/source_532nmlaser +# +# +# +# +# +# +# +# +# +# +# +# +# +# Angle of the linear polarized light, with respect to a fixed arbitrary +# defined 0° position. This can be used if no definition of respective +# cooridnate systems for beam and sample normal is done. If coordinate systems +# are defined, refer to beam "incident_polarization". +# +# +# +# +# +# +# +# +# +# +# +# +# Description of the detector type. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Type of detector, if "other" was selected in "detector_type". +# +# +# +# +# Contains the raw data collected by the detector before calibration. +# The data which is considered raw might change from experiment to experiment +# due to hardware pre-processing of the data. +# This field ideally collects the data with the lowest level of processing +# possible. +# +# +# +# +# +# +# +# +# +# Raw data before calibration. +# +# +# +# +# +# Specify respective hardware which was used for the detector. For +# example special electronics required for time-correlated single photon +# counting (TCSPC). +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Specification of type, may also go to name. +# +# +# +# +# +# If available, name/ID/norm of the light source standard. +# +# +# +# +# Details about the device information. +# +# +# +# +# The path to a beam emitted by this source. +# Should be named with the same appendix, e.g., +# for TYPE=532nmlaser, there should as well be +# a NXbeam named "beam_532nmlaser" together with this source +# instance named "source_532nmlaser" +# +# Example: /entry/instrument/beam_532nmlaser +# +# +# +# +# +# +# +# +# Defines the reference frame which is used to describe the sample orientation +# with respect to the beam directions. +# +# A beam centered description is the default and uses 4 angles(similar to XRD): +# - Omega (angle between sample surface and incident beam) +# - 2Theta (angle between the transmitted beam and the detection beam) +# - Chi (sample tilt angle, angle between plane#1 and the surface normal, +# plane#1 = spanned by incidence beam and detection +# and detection. If Chi=0°, then plane#1 is the plane of +# incidence in reflection setups) +# - Phi (inplane rotation of sample, rotation axis is the samples +# surface normal) +# +# +# A sample normal centered description is as well possible: +# - angle of incidence (angle between incident beam and sample surface) +# - angle of detection (angle between detection beam and sample surface) +# - angle of incident and detection beam +# - angle of in-plane sample rotation (direction along the sample's surface normal) +# +# An arbitrary reference frame can be defined by "reference_frames" +# and used via "instrument/angle_sample_and_beam_TYPE" +# +# +# +# +# # -# +# # -# Name of the affiliation of the user at the point in time when the -# experiment was performed. +# Angle between sample incident beam and sample surface. # # -# +# # -# Street address of the user's affiliation. +# Angle between incident and detection beam # # -# +# # -# Email address of the user. +# Sample tilt between sample normal, and the plane spanned by detection and +# incident beam. # # -# +# # -# Author ID defined by https://orcid.org/. +# Inplane rotation of the sample, with rotation axis along sample normal. # # -# +# # -# Telephone number of the user. +# Angle(s) of the incident beam vs. the normal of the bottom reflective +# (substrate) surface in the sample. These two directions span the plane +# of incidence. # # -# -# -# -# Properties of the experimental setup. This includes general information -# about the instrument (such as model, company etc.), information about -# the calibration of the instrument, elements of the beam path including -# the excitation or light source and the detector unit, the sample stage -# (plus the sample environment, which also includes sensors used to -# monitor external conditions) and elements of the beam path. -# -# Meta data describing the sample should be specified in ENTRY/SAMPLE -# outside of ENTRY/INSTRUMENT. -# -# +# # -# The name of the instrument. +# Detection angle(s) of the beam reflected or scattered off the sample +# vs. the normal of the bottom reflective (substrate) surface in the +# sample if not equal to the angle(s) of incidence. +# These two directions span the plane of detection. # -# -# -# The used version of the hardware if available. If not a commercial -# instrument use date of completion of the hardware. -# -# # -# +# # -# Name of the company which build the instrument. +# Angle between the incident and detection beam. +# If angle_of_detection + angle_of_incidence = angle_of_incident_and_detection_beam, +# then the setup is a reflection setup. +# If angle_of_detection + angle_of_incidence != angle_of_incident_and_detection_beam +# then the setup may be a light scattering setup. +# (i.e. 90° + 90° != 90°, i.e. incident and detection beam in the sample surface, but +# the angle source-sample-detector is 90°) # # -# +# # -# ISO8601 date when the instrument was constructed. -# UTC offset should be specified. +# Angle of the inplane orientation of the sample. This might be an arbitrary, +# angle without specific relation to the sample symmetry, +# of the angle to a specific sample property (i.e. crystallographic axis or sample +# shape such as wafer flat) # # -# -# -# -# Commercial or otherwise defined given name of the program that was -# used to measure the data, i.e. the software used to start and -# record the measured data and/or metadata. -# If home written, one can provide the actual steps in the NOTE -# subfield here. -# +# +# +# Set of transformations, describing the relative orientation of different +# parts of the experiment (beams or sample). You may select one of the specified +# angles for incident and detection beam or sample, and then use polar and azimuthal +# angles to define the direction via sperical coordinates. +# This allows consistent defintion between different coordinate system. +# You may refer to self defined coordinate system as well. +# +# +# If "angle_reference_frame = beam centered", then this coordinate system is used: +# McStas system (NeXus default) +# (https://manual.nexusformat.org/design.html#mcstas-and-nxgeometry-system) +# +# i.e. the z-coordinate math:`[0,0,1]` is along the incident beam direction and +# the x-coordinate math:`[1,0,0]` is in the horizontal plane. Hence, usually math:`[0,1,0]` +# is vertically oriented. +# +# If "angle_reference_frame = sample-normal centered", then this coordinate +# system is used +# z - math:`[0,0,1]` along sample surface normal +# x - math:`[1,0,0]` defined by sample surface projected incident beam. +# y - math:`[0,1,0]` in the sample surface, orthogonal to z and x. +# For this case, x may be ill defined, if the incident beam is perpendicular +# to the sample surface. In this case, use the beam centered description. +# +# +# +# +# +# +# # -# +# # -# Either version with build number, commit hash, or description of a -# (online) repository where the source code of the program and build -# instructions can be found so that the program can be configured in -# such a way that result files can be created ideally in a -# deterministic manner. +# Rotation about the y axis (polar rotation within the sample plane). # +# +# +# +# +# +# +# +# +# +# +# +# +# Path to a transformation that places the sample surface +# into the origin of the arpes_geometry coordinate system. +# +# # -# +# # -# Website of the software. +# Rotation about the z axis (azimuthal rotation within the sample plane). # -# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# # -# +# # -# Commercial or otherwise defined name of the firmware that was used -# for the measurement - if available. +# Specify if there is a lateral offset on the sample surface, between the focal +# points of the incident beam and the detection beam. # -# +# +# +# +# Describes the order of respective beam devices in the optical beam +# path. +# +# Everything object which interacts or modifies optical beam properties, +# may be an beam device, e.g. Filter, Window, Beamsplitter, Photon Source, +# Detector, etc, +# +# It is intended, to include this functionality later to "older" beam +# components, such as NXsource, NXdetector, NXlens, etc. +# Until this is possbible, auxillary beam devices have to be created, +# for each "older" beam component instead, to allow a beam path description. +# To link the auxillary beam device to the real device properties, the +# attribute \@device should be used. +# +# # -# Version and build number or commit hash of the software source code. +# Reference to beam device, which is described by a NeXus concept +# (e.g. for NXsource, entry/instrument/source_TYPE). # # -# +# # -# Website of the software. +# Reference to the previous beam device, from which the photon beam came +# to reach this beam device. A photon source is related as origin by ".". +# This enables a logical order description of the optical setup. # -# +# # -# +# # -# Was a calibration performed? If yes, when was it done? If the -# calibration time is provided, it should be specified in -# ENTRY/INSTRUMENT/calibration/calibration_time. +# This is the optical element used to focus or collect light. This may +# be a genereic lens or microcope objectives which are used for the +# Raman scattering process. # -# -# -# -# -# -# -# -# -# +# +# +# +# +# +# +# +# +# +# +# +# +# +# # -# The calibration data and metadata should be described in a separate NeXus file -# with the link provided in 'calibration_link'. +# polarization filter to prepare light to be measured or to be incident +# on the sample. +# Genereric polarization filter porperties may be implemented via NXfilter_pol +# at a later stage. # -# +# # -# If calibtration status is 'calibration time provided', specify the -# ISO8601 date when calibration was last performed before this -# measurement. UTC offset should be specified. +# Physical principle of the polarization filter used to create a +# defined incident or scattered light state. # +# +# +# +# +# +# +# # -# +# # -# Link to the NeXus file containing the calibration data and metadata. +# Specific name or type of the polarizer used. +# +# Free text, for example: Glan-Thompson, Glan-Taylor, Rochon Prism, Wollaston +# Polarizer... # # +# # -# +# # -# Describes an arrangement of optical or other elements, e.g. the beam -# path between the light source and the sample, or between the sample -# and the detector unit (including the sources and detectors -# themselves). -# -# If a beam splitter (i.e. a device that splits the incoming beam into -# two or more beams) is part of the beam path, two or more NXbeam_path -# fields may be needed to fully describe the beam paths and the correct -# sequence of the beam path elements. -# Use as many beam paths as needed to describe the setup. +# Spectral filter used to modify properties of the scattered or incident light. +# Genereric spectral filter porperties may be implemented via NXfilter_spec +# at a later stage. # +# +# +# Type of laserline filter used to supress the laser, if measurements +# close to the laserline are performed. +# +# +# +# +# +# +# +# +# +# +# +# +# Type of laserline filter used to supress the laser, if measurements +# close to the laserline are performed. +# +# +# +# +# +# +# +# +# +# +# +# Properties of the spectral filter such as wavelength dependent Transmission +# or reflectivity. +# +# +# +# Which property is used to form the spectral properties of light, +# i.e. transmission or reflection properties. +# +# +# +# +# +# +# +# # -# -# -# Angle(s) of the incident beam vs. the normal of the bottom reflective -# (substrate) surface in the sample. -# -# -# -# -# -# -# +# +# # -# Detection angle(s) of the beam reflected or scattered off the sample -# vs. the normal of the bottom reflective (substrate) surface in the -# sample if not equal to the angle(s) of incidence. +# Allows description of beam properties via matrices, which relate ingoing with +# outgoing beam properties. # -# -# -# -# -# +# +# # -# Sample stage, holding the sample at a specific position in X,Y,Z -# (Cartesian) coordinate system and at an orientation defined -# by three Euler angles (alpha, beta, gamma). +# Sample stage (or manipulator) for positioning of the sample. This should +# only contain the spatial orientation of movement. # -# +# # # Specify the type of the sample stage. # @@ -1287,238 +1714,184 @@ NXoptical_spectroscopy(NXobject): # # # +# +# # # -# +# # -# If there is no motorized stage, we should at least qualify where -# the beam hits the sample and in what direction the sample stands -# in a free-text description, e.g. 'center of sample, long edge -# parallel to the plane of incidence'. +# If "other" was chosen in stage_type, enter here a free text description +# of the stage type. # # -# +# # -# Specify external parameters that have influenced the sample, such -# as the surrounding medium, and varied parameters e.g. temperature, -# pressure, pH value, optical excitation etc. +# This allows a description of the stages relation or orientation and +# position with respect to the sample or beam, if an laboratory or +# an stage coordinate system is defined. # -# -# -# Describe what was the medium above or around the sample. The -# common model is built up from the substrate to the medium on the -# other side. Both boundaries are assumed infinite in the model. -# Here, define the name of the medium (e.g. water, air, UHV, etc.). -# -# -# -# -# Array of pairs of complex refractive indices n + ik of the medium -# for every measured spectral point/wavelength/energy. -# Only necessary if the measurement was performed not in air, or -# something very well known, e.g. high purity water. -# -# -# -# -# -# -# -# -# A sensor used to monitor an external condition influencing the -# sample, such as temperature or pressure. It is suggested to -# replace 'PARAMETER' by the type of the varied parameter defined -# in 'parameter_type'. -# The measured parameter values should be provided in 'values'. -# For each parameter, a 'PARAMETER(NXsensor)' field needs to exist. -# In other words, there are N_sensors 'PARAMETER(NXsensor)' fields. -# -# -# -# Indicates which parameter was changed. Its definition must exist -# below. The specified variable has to be N_measurements long, -# providing the parameters for each data set. If you vary more than -# one parameter simultaneously. -# If the measured parameter is not contained in the list `other` -# should be specified and the `parameter_type_name` should be provided. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If the parameter_type is `other` a name should be specified here. -# -# -# -# -# Number of different parameter values at which the measurement -# was performed. For example, if the measurement was performed at -# temperatures of 4, 77 and 300 K, then number_of_parameters = 3. -# -# -# -# -# Vector containing the values of the varied parameter. Its -# length is equal to N_measurements. The order of the values -# should be as follows: -# -# * Order the sensors according to number_of_parameters starting -# with the lowest number. If number_of_parameters is equal for -# two sensors order them alphabetically (sensor/parameter name). -# * The first sensor's j parameters should be ordered in the -# following way. The first N_measurements/number_of_parameters -# entries of the vector contain the first parameter (a1), the -# second N_measurements/number_of_parameters contain the second -# parameter (a2) etc., so the vector looks like: -# [ -# a1,a1,...,a1, -# a2,a2,...,a2, -# ... -# aj,aj,...aj -# ] -# * The kth sensor's m parameters should be ordered in the -# following way: -# [ -# p1,...p1,p2,...,p2,...pm,...,pm, -# p1,...p1,p2,...,p2,...pm,...,pm, -# ... -# p1,...p1,p2,...,p2,...pm,...,pm -# ] -# * The last sensor's n parameters should be ordered in the -# following way: -# [ -# z1,z2,...,zn, -# z1,z2,...,zn, -# ... -# z1,z2,...,zn] -# -# For example, if the experiment was performed at three different -# temperatures (T1, T2, T3), two different pressures (p1, p2) and -# two different angles of incidence (a1, a2), then -# N_measurements = 12 and the order of the values for the various -# parameter vectors is: -# -# * angle_of_incidence: [a1,a1,a1,a1,a1,a1,a2,a2,a2,a2,a2,a2] -# * pressure: [p1,p1,p1,p2,p2,p2,p1,p1,p1,p2,p2,p2] -# * temperature: [T1,T2,T3,T1,T2,T3,T1,T2,T3,T1,T2,T3] -# -# -# -# -# -# # -# +# # -# For environmental measurements, the environment (liquid, vapor -# etc.) is enclosed in a cell, which has windows both in the -# direction of the source (entry window) and the detector (exit -# window) (looking from the sample). In case that the entry and exit -# windows are not the same type and do not have the same properties, -# use a second 'WINDOW(MXaperture)' field. -# -# The windows also add a phase shift to the light altering the -# measured signal. This shift has to be corrected based on measuring -# a known sample (reference sample) or the actual sample of interest -# in the environmental cell. State if a window correction has been -# performed in 'window_effects_corrected'. Reference data should be -# considered as a separate experiment, and a link to the NeXus file -# should be added in reference_data_link in measured_data. -# -# The window is considered to be a part of the sample stage but also -# beam path. Hence, its position within the beam path should be -# defined by the 'depends_on' field. +# Description of relation of the beam with the sample. How dit the +# sample hit the beam, e.g. 'center of sample, long edge parallel +# to the plane of incidence'. +# Is redundent, if a full orientation description is done via the +# stages "transformations" entry. # -# -# -# Specify the position of the window in the beam path by pointing -# to the preceding element in the sequence of beam path elements. -# -# -# -# -# Was a window correction performed? If 'True' describe the window -# correction procedure in 'window_correction/procedure'. -# -# -# -# -# Was a window correction performed? If 'True' describe the -# window correction procedure in '' -# -# -# -# Describe when (before or after the main measurement + time -# stamp in 'date') and how the window effects have been -# corrected, i.e. either mathematically or by performing a -# reference measurement. In the latter case, provide the link to -# to the reference data in 'reference_data_link'. -# -# -# -# -# Link to the NeXus file which describes the reference data if a -# reference measurement for window correction was performed. -# Ideally, the reference measurement was performed on a reference -# sample and on the same sample, and using the same conditions as -# for the actual measurement with and without windows. It should -# have been conducted as close in time to the actual measurement -# as possible. -# -# -# -# -# -# The material of the window. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If you specified 'other' as material, decsribe here what it is. -# -# -# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Type of control for the sample temperature. Replace TYPE by "cryostat" or +# "heater" to specify it. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Hardware used for actuation, i.e. laser, gas lamp, filament, resistive +# +# +# +# +# +# +# +# +# +# General device information of the optical spectroscopy setup, if +# suitable (e.g. for a tabletop spectrometer or other non-custom build setups). +# For custom build setups, this may be limited to the construction year. +# +# +# +# +# +# +# +# +# +# Commercial or otherwise defined given name of the program that was +# used to control any parts of the optical spectroscopy setup. +# The uppercase TYPE should be replaced by a specification name, i.e. +# "software_detector" or "software_stage" to specify the respective +# program or software components. +# +# # -# Thickness of the window. +# Either version with build number, commit hash, or description of a +# (online) repository where the source code of the program and build +# instructions can be found so that the program can be configured in +# such a way that result files can be created ideally in a +# deterministic manner. # -# -# +# +# # -# Angle of the window normal (outer) vs. the substrate normal -# (similar to the angle of incidence). +# Description of the software by persistent resource, where the program, +# code, script etc. can be found. # -# +# +# +# +# +# +# Pre-calibration of an arbitrary device of the instrumental setup, which +# has the name DEVICE. You can specify here how, at which time by which method +# the calibration was done. As well the accuracy and a link to the calibration +# dataset. +# +# +# +# Path to the device, which was calibrated. +# Example: entry/instrument/DEVICE +# +# +# +# +# Provide data about the determined accuracy of the device, this may +# may be a single value or a dataset like wavelength error vs. wavelength etc. +# # +# +# +# Was a calibration performed? If yes, when was it done? If the +# calibration time is provided, it should be specified in +# ENTRY/INSTRUMENT/calibration/calibration_time. +# +# +# +# +# +# +# +# +# +# +# +# If calibtration status is 'calibration time provided', specify the +# ISO8601 date when calibration was last performed before this +# measurement. UTC offset should be specified. +# +# +# +# +# Generic data which does not fit to the 'NX_FLOAT' fields in NXproces. +# This can be for example the instrument response function. +# +# +# +# +# +# The overall resolution of the optical instrument. +# +# +# +# +# +# +# +# +# +# Minimum distinguishable wavelength separation of peaks in spectra. +# +# # +# +# +# Array of pairs of complex refractive indices n + ik of the medium +# for every measured spectral point/wavelength/energy. +# Only necessary if the measurement was performed not in air, or +# something very well known, e.g. high purity water. +# +# +# +# +# +# # # # @@ -1527,32 +1900,26 @@ NXoptical_spectroscopy(NXobject): # Information about the sample stage and sample environment should be # described in ENTRY/INSTRUMENT/sample_stage. # -# +# +# # -# Descriptive name of the sample +# Locally unique ID of the sample, used in the reasearch institute or group. # # -# +# # -# Specify the type of sample, e.g. thin film, single crystal etc. +# State the form of the sample, examples are: +# thin film, single crystal, poly crystal, amorphous, single layer, +# multi layer, liquid, gas, pellet, powder. +# Generic properties of liquids or gases see NXsample properties. # -# -# -# -# -# -# -# # -# +# # -# Qualitative description of the layer structure for the sample, -# starting with the top layer (i.e. the one on the front surface, on -# which the light incident), e.g. native oxide/bulk substrate, or -# Si/native oxide/thermal oxide/polymer/peptide. +# Free text description of the sample. # # -# +# # # Chemical formula of the sample. Use the Hill system (explained here: # https://en.wikipedia.org/wiki/Chemical_formula#Hill_system) to write @@ -1563,7 +1930,7 @@ NXoptical_spectroscopy(NXobject): # The order must be consistent with layer_structure # # -# +# # # List of comma-separated elements from the periodic table that are # contained in the sample. If the sample substance has multiple @@ -1571,184 +1938,169 @@ NXoptical_spectroscopy(NXobject): # 'atom_types'. # # -# -# -# Ideally, a reference to the location or a unique (globally -# persistent) identifier (e.g.) of e.g. another file which gives -# as many as possible details of the material, its microstructure, -# and its thermo-chemo-mechanical processing/preparation history. -# In the case that such a detailed history of the sample is not -# available, use this field as a free-text description to specify -# details of the sample and its preparation. -# -# # # -# ISO8601 date with time zone (UTC offset) specified. +# ISO 8601 time code with local time zone offset to UTC information +# when the specimen was prepared. +# +# Ideally, report the end of the preparation, i.e. the last known timestamp when +# the measured specimen surface was actively prepared. # # -# +# # -# Description of the substrate. +# A set of activities that occurred to the sample prior to/during the experiment. # -# -# +# +# # -# Specify the sample orientation. +# Sample temperature (either controlled or just measured). # -# -# -# -# -# Measured data, data errors, and varied parameters. If reference data -# were measured they should be considered a separate experiment and a -# link to its NeXus file should be added in reference_data_link. -# -# +# +# +# If no sensor was available for the determination of temperature, selected +# a nominal value which represents approximately the situation of sample temperature. +# +# +# +# +# +# +# +# +# +# +# If temperature_nominal is "other", enter here a nominal/assumed/estimated +# sample temperature. +# +# +# +# +# Temperature sensor measuring the sample temperature. +# This should be a link to /entry/instrument/manipulator/temperature_sensor. +# +# +# +# +# Device to heat the sample. +# This should be a link to /entry/instrument/manipulator/sample_heater. +# +# +# +# +# Device for cooling the sample (Cryostat, Airflow cooler, etc.). +# This should be a link to /entry/instrument/manipulator/cryostat. +# +# +# +# # -# An identifier to correlate data to the experimental conditions, -# if several were used in this measurement; typically an index of 0-N. +# Arbirary sample property which may be varied during the experiment +# and controlled by a device. Examples are pressure, voltage, magnetic field etc. +# Similar to the temperautre description of the sample. # -# -# +# +# +# Medium, in which the sample is placed. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# # -# Select which type of data was recorded, for example intensity, -# reflectivity, transmittance, Psi and Delta etc. -# It is possible to have multiple selections. The enumeration list -# depends on the type of experiment and may differ for different -# application definitions. +# (Measured) sample thickness. +# +# The information is recorded to qualify if the light used was likely +# able to shine through the sample. +# +# In this case the value should be set to the actual thickness of +# the specimen viewed for an illumination situation where the nominal +# surface normal of the specimen is parallel to the optical axis. # -# -# -# -# -# -# -# -# -# -# -# # -# -# +# # -# Spectral values (e.g. wavelength or energy) used for the measurement. -# An array of 1 or more elements. Length defines N_spectrum. Replace -# 'SPECTRUM' by the physical quantity that is used, e.g. wavelength. +# If a thickness if given, please specify how this thickness was estimated or +# determined. # -# -# -# -# -# -# If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. -# If the unit of the measured data is not covered by NXDL units state -# here which unit was used. -# -# # -# +# +# # -# Resulting data from the measurement, described by 'data_type'. -# -# The first dimension is defined by the number of measurements taken, -# (N_measurements). The instructions on how to order the values -# contained in the parameter vectors given in the doc string of -# INSTRUMENT/sample_stage/environment_conditions/PARAMETER/values, -# define the N_measurements parameter sets. For example, if the -# experiment was performed at three different temperatures -# (T1, T2, T3), two different pressures (p1, p2) and two different -# angles of incidence (a1, a2), the first measurement was taken at the -# parameters {a1,p1,T1}, the second measurement at {a1,p1,T2} etc. +# Qualitative description of the layer structure for the sample, +# starting with the top layer (i.e. the one on the front surface, on +# which the light incident), e.g. native oxide/bulk substrate, or +# Si/native oxide/thermal oxide/polymer/peptide. # -# -# -# -# -# -# -# -# If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. -# If the unit of the measured data is not covered by NXDL units state -# here which unit was used. -# -# # -# +# # -# Specified uncertainties (errors) of the data described by 'data_type' -# and provided in 'measured_data'. +# Specify the sample orientation, how is its sample normal oriented +# relative in the laboratory reference frame, incident beam reference +# frame. # -# -# -# -# -# -# -# -# If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. -# If the unit of the measured data is not covered by NXDL units state -# here which unit was used. -# -# # -# +# # -# List of links to the values of the sensors. Add a link for each -# varied parameter (i.e. for each sensor). +# If the sample is grown or fixed on a substrate, specify this here by +# a free text description. # -# -# -# # -# +# +# +# +# Here generic types of data may be saved.. This may refer to data derived +# from single or multiple raw measurements (i.e. several intensities are +# evaluated for different parameters: ellipsometry -> psi and delta) - +# i.e. non-raw data. +# As well plotable data may be stored/linked here, which provides the most suitable +# representation of the data (for the respective community). +# +# You may provide multiple instances of NXdata +# +# # -# Link to the NeXus file which describes the reference data if a -# reference measurement was performed. Ideally, the reference -# measurement was performed using the same conditions as the actual -# measurement and should be as close in time to the actual measurement -# as possible. +# Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) # -# -# -# -# -# Commercial or otherwise defined given name of the program that was -# used to generate the result file(s) with measured data and/or -# metadata (in most cases, this is the same as INSTRUMENT/software). -# If home written, one can provide the actual steps in the NOTE -# subfield here. -# -# -# -# -# Either version with build number, commit hash, or description of a -# (online) repository where the source code of the program and build -# instructions can be found so that the program can be configured in -# such a way that result files can be created ideally in a -# deterministic manner. -# -# -# -# -# Website of the software. -# -# -# -# +# +# # -# A plot of the multi-dimensional data array provided in -# ENTRY/data/measured_data. +# Spectrum, i.e. y-axis of the data (e.g. counts, intensity) # -# +# +# +# +# +# # -# Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) +# Location to save the calibrated wavelength data. # -# +# # # +# # +# # # Parameters that are derived from the measured data. # @@ -1762,7 +2114,7 @@ NXoptical_spectroscopy(NXobject): # # # -# +# # # Jones quality factor. # @@ -1812,17 +2164,5 @@ NXoptical_spectroscopy(NXobject): # # # -# -# -# A default view of the data provided in ENTRY/data_collection/measured_data. This -# should be the part of the data set which provides the most suitable -# representation of the data. -# -# -# -# Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) -# -# -# # # diff --git a/contributed_definitions/nyaml/NXoptical_system_em.yaml b/contributed_definitions/nyaml/NXoptical_system_em.yaml index c0d912b7b7..bbb6eac7b2 100644 --- a/contributed_definitions/nyaml/NXoptical_system_em.yaml +++ b/contributed_definitions/nyaml/NXoptical_system_em.yaml @@ -3,10 +3,12 @@ doc: | A container for qualifying an electron optical system. type: group NXoptical_system_em(NXobject): + # NEW ISSUE: for now used to store difficult to place entries # NEW ISSUE: all the definitions here should better be backed up by the # work of the HMC EM glossary activities camera_length(NX_NUMBER): + unit: NX_LENGTH doc: - | Distance which is present between the specimen surface and the detector plane. @@ -15,33 +17,34 @@ NXoptical_system_em(NXobject): spec: EMglossary term: Camera Length url: https://purls.helmholtz-metadaten.de/emg/EMG_00000008 - unit: NX_LENGTH - magnification(NX_NUMBER): # R+ otherwise it is demagnification + magnification(NX_NUMBER): + unit: NX_DIMENSIONLESS doc: | The factor of enlargement of the apparent size, not the physical size, of an object. - unit: NX_DIMENSIONLESS defocus(NX_NUMBER): unit: NX_LENGTH doc: | The defocus aberration constant (oftentimes referred to as C_1_0). See respective details in :ref:`NXaberration` class instances. semi_convergence_angle(NX_NUMBER): + unit: NX_ANGLE doc: - | - The angle which is given by the semi-opening angle of the cone in a convergent beam. + The angle which is given by the semi-opening angle of the cone in a convergent + beam. - | xref: spec: EMglossary term: Convergence Angle url: https://purls.helmholtz-metadaten.de/emg/EMG_00000010 - unit: NX_ANGLE field_of_view(NX_NUMBER): + unit: NX_LENGTH doc: | The extent of the observable parts of the specimen given the current magnification and other settings of the instrument. - unit: NX_LENGTH working_distance(NX_NUMBER): + unit: NX_LENGTH doc: - | Distance which is determined along the optical axis within the column from (1) the @@ -52,7 +55,7 @@ NXoptical_system_em(NXobject): spec: EMglossary term: Working Distance url: https://purls.helmholtz-metadaten.de/emg/EMG_00000050 - unit: NX_LENGTH + # probe_current and beam_current are related but not the same # the probe_current is equal to the beam_current only right at the surface where the beam enters the specimen # inserting a Faraday cup in the beam path measures the beam_current (along a specific location on the beam @@ -60,8 +63,10 @@ NXoptical_system_em(NXobject): # that the beam current is the probe current. probe(NXcg_ellipsoid_set): doc: | - Geometry of the cross-section formed when the primary beam shines onto the specimen surface. + Geometry of the cross-section formed when the primary beam shines onto the + specimen surface. probe_current(NX_NUMBER): + unit: NX_CURRENT doc: - | Electrical current which arrives at the specimen. @@ -70,16 +75,19 @@ NXoptical_system_em(NXobject): spec: EMglossary term: Probe Current url: https://purls.helmholtz-metadaten.de/emg/EMG_00000041 - unit: NX_CURRENT + # replace with a dedicated base class to describe the dose rate, accumulated dose, dose rate history # based on the AXON Dose monitoring suggestions, for this one could also have an NXdose_monitoring base class # alternatively as that dose monitoring instrument as it is also described in the paper # is a modified Faraday cup sensor one could also wrap that detector in this base dose monitoring base class dose_management(NX_CHAR): + # see AXON Dose monitoring paper doi:10.1017/S1551929522000840 # this is the nominal dose rate e-/(angstrom^2*s) doc: | - Specify further details how incipient electron or ion dose was quantified (using beam_current, probe_current). + Specify further details how incipient electron or ion dose was quantified (using + beam_current, probe_current). + # NEW ISSUE: the KIT/SCC propose: # adding of the image_mode or field mode # imageMode: enum: [normal_image, sad, eds, nbd, cbed] @@ -87,7 +95,8 @@ NXoptical_system_em(NXobject): tilt_correction(NX_BOOLEAN): doc: - | - Details about an imaging setting used during acquisition to correct perspective distortion when imaging a tilted surface or cross section. + Details about an imaging setting used during acquisition to correct perspective + distortion when imaging a tilted surface or cross section. - | xref: spec: EMglossary @@ -112,12 +121,171 @@ NXoptical_system_em(NXobject): term: Dynamic Refocusing url: https://purls.helmholtz-metadaten.de/emg/EMG_00000017 focal_length(NX_NUMBER): + unit: NX_LENGTH doc: - | - Distance which lies between the principal plane of the lens and the focal point along the optical axis. + Distance which lies between the principal plane of the lens and the focal point + along the optical axis. - | xref: spec: EMglossary term: Focal Length url: https://purls.helmholtz-metadaten.de/emg/EMG_00000029 - unit: NX_LENGTH + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# fef210010569e0fac593cd9254f53b802c34a8c45a417cd0a6b1a41b52d01a93 +# +# +# +# +# +# A container for qualifying an electron optical system. +# +# +# +# +# Distance which is present between the specimen surface and the detector plane. +# +# This concept is related to term `Camera Length`_ of the EMglossary standard. +# +# .. _Camera Length: https://purls.helmholtz-metadaten.de/emg/EMG_00000008 +# +# +# +# +# The factor of enlargement of the apparent size, +# not the physical size, of an object. +# +# +# +# +# The defocus aberration constant (oftentimes referred to as C_1_0). +# See respective details in :ref:`NXaberration` class instances. +# +# +# +# +# The angle which is given by the semi-opening angle of the cone in a convergent +# beam. +# +# This concept is related to term `Convergence Angle`_ of the EMglossary standard. +# +# .. _Convergence Angle: https://purls.helmholtz-metadaten.de/emg/EMG_00000010 +# +# +# +# +# The extent of the observable parts of the specimen given the current +# magnification and other settings of the instrument. +# +# +# +# +# Distance which is determined along the optical axis within the column from (1) the +# lower end of the final optical element between the source and the specimen stage; +# to (2) the point where the beam is focused. +# +# This concept is related to term `Working Distance`_ of the EMglossary standard. +# +# .. _Working Distance: https://purls.helmholtz-metadaten.de/emg/EMG_00000050 +# +# +# +# +# +# Geometry of the cross-section formed when the primary beam shines onto the +# specimen surface. +# +# +# +# +# Electrical current which arrives at the specimen. +# +# This concept is related to term `Probe Current`_ of the EMglossary standard. +# +# .. _Probe Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000041 +# +# +# +# +# +# +# Specify further details how incipient electron or ion dose was quantified (using +# beam_current, probe_current). +# +# +# +# +# +# Details about an imaging setting used during acquisition to correct perspective +# distortion when imaging a tilted surface or cross section. +# +# This concept is related to term `Tilt Correction`_ of the EMglossary standard. +# +# .. _Tilt Correction: https://purls.helmholtz-metadaten.de/emg/EMG_00000047 +# +# +# +# +# Details about a dynamic focus correction used. +# +# This concept is related to term `Dynamic Focus Correction`_ of the EMglossary standard. +# +# .. _Dynamic Focus Correction: https://purls.helmholtz-metadaten.de/emg/EMG_00000016 +# +# +# +# +# Details about a workflow used to keep the specimen in focus by automatic means. +# +# This concept is related to term `Dynamic Refocusing`_ of the EMglossary standard. +# +# .. _Dynamic Refocusing: https://purls.helmholtz-metadaten.de/emg/EMG_00000017 +# +# +# +# +# Distance which lies between the principal plane of the lens and the focal point +# along the optical axis. +# +# This concept is related to term `Focal Length`_ of the EMglossary standard. +# +# .. _Focal Length: https://purls.helmholtz-metadaten.de/emg/EMG_00000029 +# +# +# diff --git a/contributed_definitions/nyaml/NXphysical_process.yaml b/contributed_definitions/nyaml/NXphysical_process.yaml index 24a515e973..f4d81c95bd 100644 --- a/contributed_definitions/nyaml/NXphysical_process.yaml +++ b/contributed_definitions/nyaml/NXphysical_process.yaml @@ -28,7 +28,7 @@ NXphysical_process(NXobject): case these are not available, free-text description. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 5792f0ac3cb2c2b5c936e7046ea9dc831875bc6ab9e674c6f705fe2e252c08ce +# 2cea2a56950dd56002cd6da9efbf7115622c989e4e09e1b05223b6c6e8e1dde8 # # # +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of pulses collected in between start_time and end_time +# resolved by an instance of :ref:`NXevent_data_apm`. +# +# +# +# +# Base class for a laser- and/or voltage-pulsing device used in atom probe +# microscopy. +# +# +# +# +# Detail whereby ion extraction is triggered methodologically. +# +# +# +# +# +# +# +# +# +# +# Frequency with which the pulser fire(s). +# +# +# +# +# +# +# Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. +# +# +# +# +# +# Fraction of the pulse_voltage that is applied in addition +# to the standing_voltage at peak voltage of a pulse. +# +# If a standing voltage is applied, this gives nominal pulse fraction +# (as a function of standing voltage). Otherwise, this field should +# not be present. +# +# +# +# +# +# +# Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. +# +# +# +# +# +# +# Pulsed voltage, in laser pulsing mode this field can be omitted. +# +# +# +# +# +# +# Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. +# +# +# +# +# +# Absolute number of pulses starting from the beginning of the experiment. +# +# +# +# +# +# +# Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. +# +# +# +# +# +# +# Direct current voltage between the specimen and the (local electrode) in +# the case of local electrode atom probe (LEAP) instrument. Otherwise, the +# standing voltage applied to the sample, relative to system ground. +# +# +# +# +# +# +# Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. +# +# +# +# +# +# Atom probe microscopes use controlled laser, voltage, or a combination of +# pulsing strategies to trigger ion extraction via exciting and eventual field evaporation +# field emission of ion at the specimen surface. +# +# +# +# Given name/alias. +# +# +# +# +# +# Nominal wavelength of the laser radiation. +# +# +# +# +# Nominal power of the laser source while illuminating the specimen. +# +# +# +# +# Average energy of the laser at peak of each pulse. +# +# +# +# +# +# +# Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. +# +# +# +# +# +# Details about specific positions along the laser beam +# which illuminates the (atom probe) specimen. +# +# +# +# Track time-dependent settings over the course of the measurement +# how the laser beam shines on the specimen, i.e. the mean vector +# is parallel to the laser propagation direction. +# +# +# +# +# +# +# +# Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. +# +# +# +# +# +# Track time-dependent settings over the course of the measurement +# where the laser beam exits the focusing optics. +# +# +# +# +# +# +# +# Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. +# +# +# +# +# +# Track time-dependent settings over the course of the +# measurement where the laser hits the specimen. +# +# +# +# +# +# +# +# Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. +# +# +# +# +# +# +# Affine transformations which describe the geometry how the +# laser focusing optics/pinhole-attached coordinate system is +# defined, how it has to be transformed so that it aligns with +# the specimen coordinate system. +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXpump.yaml b/contributed_definitions/nyaml/NXpump.yaml index a5a803a64d..a8fb3b9a36 100644 --- a/contributed_definitions/nyaml/NXpump.yaml +++ b/contributed_definitions/nyaml/NXpump.yaml @@ -12,3 +12,49 @@ NXpump(NXobject): # NEW ISSUE: take community input and work further to store what is relevant to report about pumps # NEW ISSUE: see e.g. https://www.youtube.com/watch?v=Nsr_AdTiIIA for a discussion about # NEW ISSUE: the role, pros and cons of pump used for atom probe microscopy + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 5e160f93c9e2ffcab9c04e29500c0c4ecc1e0b65fbdbd00f822893e9d9a32872 +# +# +# +# +# +# Device to reduce an atmosphere (real or simulated) to a controlled pressure. +# +# +# +# +# Principle type of the pump. +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXquadric.yaml b/contributed_definitions/nyaml/NXquadric.yaml index f220b55003..a4d0e6b5e5 100644 --- a/contributed_definitions/nyaml/NXquadric.yaml +++ b/contributed_definitions/nyaml/NXquadric.yaml @@ -26,13 +26,13 @@ NXquadric(NXobject): which the orientation of the surface depends. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 267b94fd8c62dec6dbb2c835d40cda184ec544f98b054c545c067c0206a6680f +# 561221af2771bd8071a409c39b044ea2decbb9919d618c5ff2328118acd876f9 # # # # +# # -# +# 09/2024 +# TODO (Workshop output): +# - Talk with VIBSO people - possible to syncrhonize raman_experiment_type with this ontology? +# - Similar to ellipsometry: Seperate in-situ from resonant/non-resonant stuff: OR maybe allow multiple selections? +# - Shorten raman_experiment_type by removal of Raman_spectroscopy, but as well fix the Raman Reader in the same run +# - Which for more dataconverters: Output from usualy Raman setups to neXus format? +# - Spot size description? +# - Descroption of defocusing / maybe as well as experiment_type? +# +# Wishes for NXraman or general next workshop: +# "convert excisting data to NeXus" +# "dictionary lookup keywords/fields in existing formats"(?) +# Template for specific experiments (i.e. too complex to get into NeXus/FAIRdata?) - unclear what to do. +# coorporation with VIBSO ontology? +# dataset examples (i.e. NXdata_raman)--> +# # # # Variables used throughout the document, e.g. dimensions or parameters. # +# +# +# Length of the spectrum array (e.g. wavelength or energy) of the measured +# data. +# +# +# +# +# Number of measurements (1st dimension of measured_data array). This is +# equal to the number of parameters scanned. For example, if the experiment +# was performed at three different temperatures and two different pressures +# N_measurements = 2*3 = 6. +# +# +# +# +# Number of detection angles of the beam reflected or scattered off the +# sample. +# +# +# +# +# Number of angles of incidence of the incident beam. +# +# +# +# +# Number of scattering configurations used in the measurement. +# It is 1 for only parallel polarization meausement, 2 for parallel and cross +# polarization measurement or larger, if i.e. the incident and scattered photon +# direction is varied. +# +# # # # An application definition for Raman spectrocopy experiments. # +# Such experiments may be as simple a single Raman spectrum from spontanous +# Raman scattering and range to Raman imaging Raman spectrometer, +# surface- and tip-enhanced Raman techniques, x-Ray Raman scattering, as well +# as resonant Raman scattering phenomena or multidimenional Raman spectra (i.e. +# varying temperature, pressure, electric field, ....) +# +# The application definition contains two things: +# 1. The structures in the application definition of NXopt: +# * Instrument and data calibrations +# * Sensors for sample or beam conditions +# +# AND +# +# 2. The strucutres specified and extended in NXraman: +# * description of the experiment type +# * descroption of the setup's meta data and optical elements (source, monochromator, detector, waveplate, lens, etc.) +# * description of beam properties and their relations to the sample +# * sample information +# # Information on Raman spectroscopy are provided in: # # General +# # * Lewis, Ian R.; Edwards, Howell G. M. # Handbook of Raman Spectroscopy # ISBN 0-8247-0557-2 # # Raman scattering selection rules +# # * Dresselhaus, M. S.; Dresselhaus, G.; Jorio, A. # Group Theory - Application to the Physics ofCondensed Matter # ISBN 3540328971 # # Semiconductors +# # * Manuel Cardona # Light Scattering in Solids I # eBook ISBN: 978-3-540-37568-5 @@ -252,7 +322,7 @@ NXraman(NXoptical_spectroscopy): # * See as well other Books from the "Light Scattering in Solids" series: # III: Recent Results # IV: Electronic Scattering, Spin Effects, SERS, and Morphic Effects -# V: Superlattices and Other Microstructures +# V: Superlattices and Other Microstructures # VI: Recent Results, Including High-Tc Superconductivity # VII: Crystal-Field and Magnetic Excitations # VIII: Fullerenes, Semiconductor Surfaces, Coherent Phonons @@ -266,25 +336,9 @@ NXraman(NXoptical_spectroscopy): # * https://doi.org/10.1186/s11671-019-3039-2 # # -# -# This is the application definition describing Raman spectroscopy experiments. -# -# Such experiments may be as simple a single Raman spectrum from spontanous -# Raman scattering and range to Raman imaging Raman spectrometer, -# surface- and tip-enhanced Raman techniques, x-Ray Raman scattering, as well -# as resonant Raman scattering phenomena or multidimenional Raman spectra (i.e. -# varying temperature, pressure, electric field, ....) -# -# The application definition defines: -# -# * elements of the experimental instrument -# * calibration information if available -# * parameters used to tune the state of the sample -# * sample description -# # # -# An application definition for ellipsometry. +# An application definition for Raman spectrsocopy. # # # @@ -292,7 +346,7 @@ NXraman(NXoptical_spectroscopy): # definition was used for this entry/data. # # -# +# # # URL where to find further material (documentation, examples) relevant # to the application definition. @@ -302,76 +356,50 @@ NXraman(NXoptical_spectroscopy): # # # -# +# +# # -# An optional free-text description of the experiment. +# Specify the type of the optical experiment. # -# However, details of the experiment should be defined in the specific -# fields of this application definition rather than in this experiment -# description. +# You may specify fundamental characteristics or properties in the experimental sub-type. # +# +# +# # -# +# # -# Specify the type of Raman measurement. +# Specify the type of Raman experiment. # # # # # # -# -# -# -# -# -# -# +# +# +# +# +# +# +# +# # # -# -# -# +# +# +# +# If the raman_experiment_type is `other`, a name should be specified here. +# +# # # -# Properties of the Instruments used for Raman instrumeasurements. +# Metadata of the setup, its optical elements and physical properites which +# defines the Raman measurement. # -# -# -# Name of the company which build the instrument. -# -# -# -# -# ISO8601 date when the instrument was constructed. -# UTC offset should be specified. -# -# -# -# -# -# Commercial or otherwise defined given name of the program that was -# used to generate the result file(s) with measured data and metadata. -# This program converts the measured signals to Raman data. If -# home written, one can provide the actual steps in the NOTE subfield -# here. -# -# -# -# -# -# Which indicent wavelength was used for e.g. a laser source. -# For multiple excitation wavelengths, please state the specific discret -# wavelengths (i.e. for dye laser) or the specific contnious range -# (i.e for white light laser source) -# -# # -# # -# Scattering configuration as defined by the porto notation by three +# Scattering configuration as defined by the porto notation by three # states, which are othogonal to each other. Example: z(xx)z for # parallel polarized backscattering configuration. # @@ -388,11 +416,9 @@ NXraman(NXoptical_spectroscopy): # An orthogonal base is assumed. # Linear polarized light is displayed by e.g. "x","y" or "z" # Unpolarized light is displayed by "." +# For non-orthogonal vectors, use the attribute porto_notation_vectors. # -# -# +# # # Scattering configuration as defined by the porto notation given by # respective vectors. @@ -400,210 +426,23 @@ NXraman(NXoptical_spectroscopy): # Vectors in the porto notation are defined as for A, B, C, D above. # Linear light polarization is assumed. # -# +# # -# 3 x 4 Matrix, which lists the porto notation vectors A, B, C, D. +# 3 x 4 Matrix, which lists the porto notation vectors A, B, C, D. # A has to be perpendicular to B and C perpendicular to D. # # # +# # -# +# # -# -# -# -# Specify the used light source. Multiple selection possible. -# -# -# -# -# -# -# -# -# -# -# -# -# This is the optical element used for the incident light in the Raman -# scattering process. -# -# This can be for example a simple lens or microscope -# objective. -# -# -# -# -# -# -# -# -# -# -# -# -# The numerical aperture of the used incident light optics. -# -# -# -# -# -# This is the optical element used for the incident light in the Raman -# scattering process. -# -# This can be for example a simple lens or microscope -# objective. -# -# -# -# -# -# -# -# -# -# -# -# -# -# The numerical aperture of the used incident light optics. -# -# -# -# -# -# Properties of the detector used. Integration time is the count time -# field, or the real time field. See their definition. -# -# -# -# -# Device for the manipulation of the state of light which is a half wave -# plate. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Physical principle of the polarization filter used to create a -# defined incident or scattered light state. -# -# -# -# -# -# -# -# -# -# -# -# Specific name or type of the polarizer used. -# -# For example: Glan-Thompson, Glan-Taylor, Rochon Prism, Wollaston -# Polarizer... -# -# -# -# -# -# Type of laserline filter used to supress the laser, if measurements -# close to the laserline are performed. -# -# -# -# -# -# -# -# -# -# -# Design wavelength for the laser line filter. -# -# -# -# -# Steepness of the filter by normal incidence of the light as defined -# by 10% - 90% transmittance of the respective filter. -# -# -# -# -# -# Designed supression strength of the laserline at optimal condition -# given in orders of magnitude. -# -# -# -# -# -# Properties of the rotating element defined in -# 'instrument/rotating_element_type'. -# -# -# -# Define how many revolutions of the rotating element were averaged -# for each measurement. If the number of revolutions was fixed to a -# certain value use the field 'fixed_revolutions' instead. -# -# -# -# -# Define how many revolutions of the rotating element were taken -# into account for each measurement (if number of revolutions was -# fixed to a certain value, i.e. not averaged). -# -# -# -# -# Specify the maximum value of revolutions of the rotating element -# for each measurement. -# -# -# -# -# -# The spectroscope element of the ellipsometer before the detector, -# but often integrated to form one closed unit. Information on the -# dispersive element can be specified in the subfield GRATING. Note -# that different gratings might be used for different wavelength -# ranges. The dispersion of the grating for each wavelength range can -# be stored in grating_dispersion. -# -# -# -# -# -# +# # -# Was the backside of the sample roughened? Relevant for infrared -# ellipsometry. +# Beam which is incident to the sample. # -# -# -# -# -# -# Select which type of data was recorded, for example a simple spectrum -# with intensity vs. Raman shift, CCD image or a set of spectra with -# probe, reference and background signals for pump beam on and off. -# -# -# -# -# -# -# +# +# # # # diff --git a/contributed_definitions/nyaml/NXreflectron.yaml b/contributed_definitions/nyaml/NXreflectron.yaml index bb8eb03b54..496051480a 100644 --- a/contributed_definitions/nyaml/NXreflectron.yaml +++ b/contributed_definitions/nyaml/NXreflectron.yaml @@ -9,7 +9,6 @@ doc: | * 3863068 and 6740872 for the reflectron * 8134119 for the curved reflectron - symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -31,16 +30,107 @@ NXreflectron(NXobject): Free-text field to specify further details about the reflectron. The field can be used to inform e. g. if the reflectron is flat or curved. voltage(NX_FLOAT): + unit: NX_VOLTAGE doc: | The maximum voltage applied to the reflectron, relative to system ground. - unit: NX_VOLTAGE - # dim: (p,) + + # dim: (p,) (NXtransformations): doc: | Affine transformation(s) which detail where the reflectron is located relative to e.g. the origin of the specimen space reference coordinate system. This group can also be used for specifying how the reflectron is rotated relative to a given axis in the instrument. - # The purpose of these more detailed instrument descriptions - # is to support the creation of a digital twin of the instrument - # for computational science. + + # The purpose of these more detailed instrument descriptions + # is to support the creation of a digital twin of the instrument + # for computational science. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# cc621f6e28c41b09ee131c7789672e97df02c74e31351ea7f006f1a1d609bad5 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of pulses collected in between start_time and end_time +# resolved by an instance of :ref:`NXevent_data_apm`. +# +# +# +# +# Base class for a device which reduces ToF differences of ions in ToF experiments. +# +# For atom probe the reflectron can be considered an energy compensation device. +# Such a device can be realized technically for example with a Poschenrieder lens. +# +# Consult the following U.S. patents for further details: +# +# * 3863068 and 6740872 for the reflectron +# * 8134119 for the curved reflectron +# +# +# +# Status of eventual existence and potential usage of this reflectron. +# +# +# +# +# +# +# +# +# +# Given name/alias. +# +# +# +# +# +# Free-text field to specify further details about the reflectron. +# The field can be used to inform e. g. if the reflectron is flat or curved. +# +# +# +# +# The maximum voltage applied to the reflectron, relative to system ground. +# +# +# +# +# +# Affine transformation(s) which detail where the reflectron is located +# relative to e.g. the origin of the specimen space reference coordinate +# system. This group can also be used for specifying how the reflectron +# is rotated relative to a given axis in the instrument. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXregion.yaml b/contributed_definitions/nyaml/NXregion.yaml index b074a5f157..cc26458ac7 100644 --- a/contributed_definitions/nyaml/NXregion.yaml +++ b/contributed_definitions/nyaml/NXregion.yaml @@ -144,13 +144,13 @@ NXregion(NXobject): listing the others. All data fields should have shapes of :math:`\boldsymbol{D}`. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8426e78db8c7bfc828d27cea0e29c7cc255b78f1ca7e809672cb6b0174497dd0 +# eac98063430202fc769007d86a644cc5545202b88a03f439afcd64cee8335862 # # # +# +# +# Base class to describe a region-of-interest analyzed. +# +# +# +# Details about processing steps. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXrotation_set.yaml b/contributed_definitions/nyaml/NXrotation_set.yaml index c0a98a7356..8ca8cf4220 100644 --- a/contributed_definitions/nyaml/NXrotation_set.yaml +++ b/contributed_definitions/nyaml/NXrotation_set.yaml @@ -39,6 +39,7 @@ NXrotation_set(NXobject): doc: | Reference to an instance of :ref:`NXcoordinate_system_set` which contextualizes how the here reported parameterized quantities can be interpreted. + # 2D rotations are a special type of 3D rotations and thus treated in 3D # just how to rotate the object into the reference frame defined by depends_on crystal_symmetry(NX_CHAR): @@ -54,7 +55,9 @@ NXrotation_set(NXobject): In this case the first string is for phase A the second one for phase B. An example of this most complex case is the description of the disorientation between crystals adjoining a hetero-phase boundary. - dim: (n_phases,) + dimensions: + rank: 1 + dim: [[1, n_phases]] sample_symmetry(NX_CHAR): doc: | Point group which defines an assumed symmetry imprinted upon processing @@ -76,41 +79,52 @@ NXrotation_set(NXobject): symmetries are anyway not fully observed, and thus an accepting of eventual inaccuracies just for the sake of reporting a simplified symmetrized description should be avoided. - dim: (n_phases,) - rotation_quaternion(NX_NUMBER): # H \in SO3 + dimensions: + rank: 1 + dim: [[1, n_phases]] + rotation_quaternion(NX_NUMBER): + unit: NX_DIMENSIONLESS doc: | The set of rotations expressed in quaternion parameterization considering crystal_symmetry and sample_symmetry. Rotations which should be interpreted as antipodal are not marked as such. - unit: NX_DIMENSIONLESS - dim: (c, 4) + dimensions: + rank: 2 + dim: [[1, c], [2, 4]] rotation_euler(NX_NUMBER): + unit: NX_ANGLE doc: | The set of rotations expressed in Euler angle parameterization considering the same applied symmetries as detailed for the field rotation_quaternion. To interpret Euler angles correctly, it is necessary to inspect the conventions behind depends_on to resolve which of the many Euler-angle conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. - unit: NX_ANGLE - dim: (c, 3) + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] + # rotation_rodrigues(NX_NUMBER): # rotation_homochoric(NX_NUMBER): # rotation_axis_angle(NX_NUMBER): - + # orientation how to rotate the crystal into sample and vice versa obeying crystal and sample symmetry is_antipodal(NX_BOOLEAN): doc: | - True for all those value tuples which have assumed antipodal symmetry. - False for all others. - dim: (c,) + True for all those value tuples which have assumed antipodal symmetry. + False for all others. + dimensions: + rank: 1 + dim: [[1, c]] orientation_quaternion(NX_NUMBER): + unit: NX_DIMENSIONLESS doc: | The set of orientations expressed in quaternion parameterization and obeying symmetry for equivalent cases as detailed in crystal_symmetry and sample_symmetry. The supplementary field is_antipodal can be used to mark orientations with the antipodal property. - unit: NX_DIMENSIONLESS - dim: (c, 4) + dimensions: + rank: 2 + dim: [[1, c], [2, 4]] orientation_euler(NX_NUMBER): unit: NX_ANGLE doc: | @@ -119,59 +133,334 @@ NXrotation_set(NXobject): To interpret Euler angles correctly, it is necessary to inspect the conventions behind depends_on to resolve which of the many Euler-angle conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. - dim: (c, 3) + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] + # orientation_rodrigues(NX_NUMBER): # orientation_homochoric(NX_NUMBER): # orientation_axis_angle(NX_NUMBER): - + # misorientation between two orientations # not the disorientation because for misorientation we ignore # if the angular argument may not have the absolute smallest amount, i.e. # misorientation is not necessarily in the fundamental zone misorientation_quaternion(NX_NUMBER): + unit: NX_DIMENSIONLESS doc: | The set of misorientations expressed in quaternion parameterization obeying symmetry operations for equivalent misorientations as defined by crystal_symmetry and sample_symmetry. - unit: NX_DIMENSIONLESS - dim: (c, 4) + dimensions: + rank: 2 + dim: [[1, c], [2, 4]] misorientation_angle(NX_NUMBER): + unit: NX_ANGLE doc: | Misorientation angular argument (eventually signed) following the same symmetry assumptions as expressed for the field misorientation_quaternion. - unit: NX_ANGLE - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] misorientation_axis(NX_NUMBER): unit: NX_DIMENSIONLESS doc: | Misorientation axis (normalized) and signed following the same symmetry assumptions as expressed for the field misorientation_angle. - dim: (c, 3) - + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] + # disorientation, misorientation with smallest angular argument inside # fundamental zone of SO3 for given crystal and sample symmetry disorientation_quaternion(NX_NUMBER): + unit: NX_DIMENSIONLESS doc: | The set of disorientation expressed in quaternion parameterization obeying symmetry operations for equivalent misorientations as defined by crystal_symmetry and sample_symmetry. - unit: NX_DIMENSIONLESS - dim: (c, 4) + dimensions: + rank: 2 + dim: [[1, c], [2, 4]] disorientation_angle(NX_NUMBER): + unit: NX_ANGLE doc: | Disorientation angular argument (should not be signed, see `D. Rowenhorst et al. `_) following the same symmetry assumptions as expressed for the field disorientation_quaternion. - unit: NX_ANGLE - dim: (c,) + dimensions: + rank: 1 + dim: [[1, c]] disorientation_axis(NX_NUMBER): + unit: NX_DIMENSIONLESS doc: | Disorientation axis (normalized) following the same symmetry assumptions as expressed for the field disorientation_angle. - unit: NX_DIMENSIONLESS - dim: (c, 3) + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] + # e.g. in this way one could easily, efficiently, store and map familiar habits of microscopists # to store e.g. orientations of measurement points or of grains via a (c := Ngrains, n_p := 3) # matrix of Bunge-Euler angles, or of (c := Ngrains, n_p := 4) matrix of quaternions. # the benefit of such a representation is that with a known NXorientation_set base class one can implement a common parameterization transformation library (of which several already exist) in the microstructure modelling communities so that a program can read the information in the (NXorientation_set) instance and automatically transform/compute between different parameterizations. Super relevant for interoperability e.g. in SEM/EBSD, where this was a long standing issue and right now the most frequently accepted consensus is to report either Bunge-Euler angles or quaternions and then use existent transformation libraries (as implemented by e.g. Marc de Graeff for SEM/EBSD and used by many but not yet the majority of people in the computational materials modelling community within crystal plasticity, crystal growth modeling, DREAM.3D) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# da83249c1855975c1652bd2121fc383c93553586da1287d4ef488b25f3167526 +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The cardinality of the set, i.e. the number of value tuples. +# +# +# +# +# How many phases with usually different crystal and symmetry are distinguished. +# +# +# +# +# Base class to detail a set of rotations, orientations, and disorientations. +# +# For getting a more detailed insight into the discussion of the +# parameterized description of orientations in materials science see: +# +# * `H.-J. Bunge <https://doi.org/10.1016/C2013-0-11769-2>`_ +# * `T. B. Britton et al. <https://doi.org/10.1016/j.matchar.2016.04.008>`_ +# * `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_ +# * `A. Morawiec <https://doi.org/10.1007/978-3-662-09156-2>`_ +# +# Once orientations are defined, one can continue to characterize the +# misorientation and specifically the disorientation. The misorientation describes +# the rotation that is required to register the lattices of two oriented objects +# (like crystal lattice) into a crystallographic equivalent orientation: +# +# * `R. Bonnet <https://doi.org/10.1107/S0567739480000186>`_ +# +# +# +# Reference to an instance of :ref:`NXcoordinate_system_set` which contextualizes +# how the here reported parameterized quantities can be interpreted. +# +# +# +# +# +# Point group which defines the symmetry of the crystal. +# +# This has to be at least a single string. If crystal_symmetry is not +# provided point group 1 is assumed. +# +# In the case that misorientation or disorientation fields are used +# and the two crystal sets resolve for phases with a different +# crystal symmetry, this field has to encode two string. +# In this case the first string is for phase A the second one for phase B. +# An example of this most complex case is the description of the +# disorientation between crystals adjoining a hetero-phase boundary. +# +# +# +# +# +# +# +# Point group which defines an assumed symmetry imprinted upon processing +# the material/sample which could give rise to or may justify to use a +# simplified description of rotations, orientations, misorientations, +# and disorientations via numerical procedures that are known as +# symmetrization. +# +# If sample_symmetry is not provided point group 1 is assumed. +# +# The traditionally used symmetrization operations within the texture +# community in Materials Science, though, are thanks to methodology and +# software improvements no longer strictly needed. Therefore, users are +# encouraged to set the sample_symmetry to 1 (triclinic) and thus assume +# there is no justification to assume the imprinting of additional +# symmetry because of the processing. +# +# In practice one often faces situations where indeed these assumed +# symmetries are anyway not fully observed, and thus an accepting of +# eventual inaccuracies just for the sake of reporting a simplified +# symmetrized description should be avoided. +# +# +# +# +# +# +# +# The set of rotations expressed in quaternion parameterization considering +# crystal_symmetry and sample_symmetry. Rotations which should be +# interpreted as antipodal are not marked as such. +# +# +# +# +# +# +# +# +# The set of rotations expressed in Euler angle parameterization considering +# the same applied symmetries as detailed for the field rotation_quaternion. +# To interpret Euler angles correctly, it is necessary to inspect the +# conventions behind depends_on to resolve which of the many Euler-angle +# conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. +# +# +# +# +# +# +# +# +# +# +# True for all those value tuples which have assumed antipodal symmetry. +# False for all others. +# +# +# +# +# +# +# +# The set of orientations expressed in quaternion parameterization and +# obeying symmetry for equivalent cases as detailed in crystal_symmetry +# and sample_symmetry. The supplementary field is_antipodal can be used +# to mark orientations with the antipodal property. +# +# +# +# +# +# +# +# +# The set of orientations expressed in Euler angle parameterization following +# the same assumptions like for orientation_quaternion. +# To interpret Euler angles correctly, it is necessary to inspect the +# conventions behind depends_on to resolve which of the many Euler-angle +# conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. +# +# +# +# +# +# +# +# +# +# +# The set of misorientations expressed in quaternion parameterization +# obeying symmetry operations for equivalent misorientations +# as defined by crystal_symmetry and sample_symmetry. +# +# +# +# +# +# +# +# +# Misorientation angular argument (eventually signed) following the same +# symmetry assumptions as expressed for the field misorientation_quaternion. +# +# +# +# +# +# +# +# Misorientation axis (normalized) and signed following the same +# symmetry assumptions as expressed for the field misorientation_angle. +# +# +# +# +# +# +# +# +# +# The set of disorientation expressed in quaternion parameterization +# obeying symmetry operations for equivalent misorientations +# as defined by crystal_symmetry and sample_symmetry. +# +# +# +# +# +# +# +# +# Disorientation angular argument (should not be signed, see +# `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_) +# following the same symmetry assumptions as expressed for the field +# disorientation_quaternion. +# +# +# +# +# +# +# +# Disorientation axis (normalized) following the same symmetry assumptions +# as expressed for the field disorientation_angle. +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXsample_component_set.yaml b/contributed_definitions/nyaml/NXsample_component_set.yaml index 2567b25d49..593b2807bb 100644 --- a/contributed_definitions/nyaml/NXsample_component_set.yaml +++ b/contributed_definitions/nyaml/NXsample_component_set.yaml @@ -42,7 +42,7 @@ NXsample_component_set(NXobject): For description of a sub-component set. Can contain multiple components itself. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e4d79347fce002e76308abff05f0abadc367858578fa4b9429ebff02d069f395 +# d6c0104267bfb3f1843228c2d31aeffaa45cf9067e45ef67f938ea7f56917407 # # # +# +# +# Scan box and coils which deflect a beam of charged particles in a controlled manner. +# +# The scan box is instructed by an instance of :ref:`NXprogram`, some control software, +# which is not necessarily the same program as for all components of a microscope. +# +# The scanbox directs the probe of charged particles (electrons, ions) +# to controlled locations according to a scan scheme and plan. +# +# +# +# +# Name of the typically tech-partner-specific term that specifies +# an automated protocol which controls the details how the components +# of the microscope work together to achieve a controlled scanning of the +# beam over the sample surface. +# +# In most cases users do not know, have to care, or are able to disentangle the +# details of the spatiotemporal dynamics of the components of the microscope. +# Instead, they rely on the assumption that the microscope and control software +# work as expected. Selecting then a specific scan_schema assures some level +# of reproducibility in the way how the beam is scanned over the surface. +# +# +# +# +# TODO discuss with the electron microscopists. +# +# +# +# +# TODO discuss with the electron microscopists. +# +# +# +# +# +# Time period during which the beam remains at one position. +# +# This concept is related to term `Dwell Time`_ of the EMglossary standard. +# +# .. _Dwell Time: https://purls.helmholtz-metadaten.de/emg/EMG_00000015 +# +# +# +# +# Time period during which the beam moves from the final position of one scan +# line to the starting position of the subsequent scan line. +# +# This concept is related to term `Flyback Time`_ of the EMglossary standard. +# +# .. _Flyback Time: https://purls.helmholtz-metadaten.de/emg/EMG_00000028 +# +# +# +# +# TODO discuss with the electron microscopists. +# +# +# +# +# TODO discuss with the electron microscopists. +# +# +# +# +# TODO discuss with the electron microscopists. +# +# +# +# +# TODO discuss with the electron microscopists. +# +# +# +# +# TODO discuss with the electron microscopists. +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXsensor_scan.yaml b/contributed_definitions/nyaml/NXsensor_scan.yaml index 94fd0c0e6e..467e1fc199 100644 --- a/contributed_definitions/nyaml/NXsensor_scan.yaml +++ b/contributed_definitions/nyaml/NXsensor_scan.yaml @@ -134,14 +134,14 @@ NXsensor_scan(NXobject): Plot of every measured signal as a function of the timestamp of when they have been acquired is also possible. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 5eb0510291ac6f2adfa9fae7ce4425bfb6c9b9a584bbca2d28d32d7beb291a58 -# +# ce40fbfc95dd1eeae1902db14f2a835250d8ef0dc04d05be893fec75b9fe5743 +# # # -# +# # # # Variables used to set a common size for collected sensor data. @@ -182,7 +182,7 @@ NXsensor_scan(NXobject): # # # -# +# # # # @@ -260,7 +260,7 @@ NXsensor_scan(NXobject): # NXsensor groups. Similarly, seperate NXsensor groups are used to store the readings from each # measurement sensor. # -# For example, in a temperature-dependent IV measurement, the temperature and voltage must be +# For example, in a temperature-dependent IV measurement, the temperature and voltage must be # present as independently scanned controllers and the current sensor must also be present with # its readings. # diff --git a/contributed_definitions/nyaml/NXsensor_sts.yaml b/contributed_definitions/nyaml/NXsensor_sts.yaml index 9403c62f77..693fb6df12 100644 --- a/contributed_definitions/nyaml/NXsensor_sts.yaml +++ b/contributed_definitions/nyaml/NXsensor_sts.yaml @@ -148,7 +148,7 @@ NXsensor_sts(NXobject): resolution during STM imaging # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e9d1c4dfb1ffa31931d46320db4e37890c8876331bee6ecc729f3ac844d23a01 +# 663a13e67e85927eccd30a06934af287989d603201e9bab8ce68166d4270d051 # # # +# +# +# Metadata to a set of pieces of information of a resource that has been serialized. +# +# A typical use case is the documentation of the source (file) or database (entry) +# from which pieces of information have been extracted for consumption in e.g. a +# research data management system (RDMS). This may be for reasons of enabling +# services such as providing access to normalized information for which reading +# again from the resource may not be desired, possibe, or feasible. +# +# Possible reasons could be the extraction of specific information for caching, +# performance reasons, or re-evaluate given pieces of information based on other +# views and interaction patterns with the data where information has been formatted +# differently by tools than how these pieces of information were originally +# serialized. +# +# +# +# Answers into what resource the information was serialized. +# +# +# +# +# +# +# +# +# Path to the resource. +# +# E.g. the name of a file or its absolute or relative path, or the +# identifier to a resource in another database. +# +# +# +# +# Value of the hash that is obtained when running algorithm +# on the content of the resource referred to by path. +# +# +# +# +# Name of the algorithm whereby the checksum was computed. +# +# +# +# +# +# Extracted file containing the serialized information. +# +# +# diff --git a/contributed_definitions/nyaml/NXsimilarity_grouping.yaml b/contributed_definitions/nyaml/NXsimilarity_grouping.yaml index bf8ffab934..f10891ce1e 100644 --- a/contributed_definitions/nyaml/NXsimilarity_grouping.yaml +++ b/contributed_definitions/nyaml/NXsimilarity_grouping.yaml @@ -25,17 +25,18 @@ symbols: type: group NXsimilarity_grouping(NXobject): cardinality(NX_UINT): + unit: NX_UNITLESS doc: | Number of members in the set which gets partitioned into features. - unit: NX_UNITLESS number_of_numeric_labels(NX_UINT): + unit: NX_UNITLESS doc: | How many numerical labels does each feature have. - unit: NX_UNITLESS number_of_categorical_labels(NX_UINT): + unit: NX_UNITLESS doc: | How many categorical labels does each feature have. - unit: NX_UNITLESS + # config/input # features: # doc: | @@ -43,6 +44,7 @@ NXsimilarity_grouping(NXobject): # Features need to have disjoint numeric identifier. # results for the object set identifier_offset(NX_INT): + unit: NX_UNITLESS doc: | Which numerical identifier is the first to be used to label a feature. @@ -52,45 +54,215 @@ NXsimilarity_grouping(NXobject): Setting for instance identifier_offset to 1 recovers the commonly used case that objects of the noise category get values to -1 and unassigned points to 0. Numerical identifier have to be strictly increasing. - unit: NX_UNITLESS numerical_label(NX_INT): + unit: NX_UNITLESS doc: | Matrix of numerical label for each member in the set. For classical clustering algorithms this can for instance encode the cluster_identifier. - unit: NX_UNITLESS - dim: (c, n_lbl_num) + dimensions: + rank: 2 + dim: [[1, c], [2, n_lbl_num]] categorical_label(NX_CHAR): doc: | Matrix of categorical attribute data for each member in the set. - dim: (c, n_lbl_cat) - statistics(NXprocess): # of the clusters/features + dimensions: + rank: 2 + dim: [[1, c], [2, n_lbl_cat]] + statistics(NXprocess): doc: | In addition to the detailed storage which objects were grouped to which feature/group summary statistics are stored under this group. + # at the level of the object set # at the level of the feature set unassigned(NX_UINT): + unit: NX_UNITLESS doc: | Total number of features categorized as unassigned. - unit: NX_UNITLESS noise(NX_UINT): + unit: NX_UNITLESS doc: | Total number of features categorized as noise. - unit: NX_UNITLESS total(NX_UINT): + unit: NX_UNITLESS doc: | Total number of features. - unit: NX_UNITLESS + # Total number of features (excluding noise and unassigned) can be trivially computed # when knowing total, noise, and unassigned. identifier(NX_UINT): + unit: NX_UNITLESS doc: | Array of numerical identifier of each feature. - unit: NX_UNITLESS - dim: (n_features,) + dimensions: + rank: 1 + dim: [[1, n_features]] member_count(NX_UINT): + unit: NX_UNITLESS doc: | Array of number of objects for each feature. - unit: NX_UNITLESS - dim: (n_features, n_lbl_num) + dimensions: + rank: 2 + dim: [[1, n_features], [2, n_lbl_num]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 8d93c5681b89657f44646f6fc81976ad1f618e6514aae36fa7c2754cbd0868de +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Cardinality of the set. +# +# +# +# +# Number of numerical labels per object. +# +# +# +# +# Number of categorical labels per object. +# +# +# +# +# Total number of similarity groups aka features/clusters. +# +# +# +# +# Base class to store results obtained from applying a similarity grouping (clustering) algorithm. +# +# Similarity grouping algorithms are segmentation or machine learning algorithms for +# partitioning the members of a set of objects (e.g. geometric primitives) into +# (sub-)groups aka features of different kind/type. A plethora of algorithms exists. +# +# This base class considers metadata and results of having a similarity grouping +# algorithm applied to a set in which objects are either categorized as noise +# or belonging to a cluster, i.e. members of a cluster. +# The algorithm assigns each similarity group (feature/cluster) at least one +# identifier (numerical or categorical labels) to distinguish different cluster. +# +# +# +# Number of members in the set which gets partitioned into features. +# +# +# +# +# How many numerical labels does each feature have. +# +# +# +# +# How many categorical labels does each feature have. +# +# +# +# +# +# Which numerical identifier is the first to be used to label a feature. +# +# The value should be chosen in such a way that special values can be resolved: +# * identifier_offset - 1 indicates that an object belongs to no cluster. +# * identifier_offset - 2 indicates that an object belongs to the noise category. +# Setting for instance identifier_offset to 1 recovers the commonly used +# case that objects of the noise category get values to -1 and unassigned +# points to 0. Numerical identifier have to be strictly increasing. +# +# +# +# +# Matrix of numerical label for each member in the set. +# For classical clustering algorithms this can for instance +# encode the cluster_identifier. +# +# +# +# +# +# +# +# +# Matrix of categorical attribute data for each member in the set. +# +# +# +# +# +# +# +# +# In addition to the detailed storage which objects were grouped to which +# feature/group summary statistics are stored under this group. +# +# +# +# +# Total number of features categorized as unassigned. +# +# +# +# +# Total number of features categorized as noise. +# +# +# +# +# Total number of features. +# +# +# +# +# +# Array of numerical identifier of each feature. +# +# +# +# +# +# +# +# Array of number of objects for each feature. +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXsingle_crystal.yaml b/contributed_definitions/nyaml/NXsingle_crystal.yaml index c249281bcd..81915a214f 100644 --- a/contributed_definitions/nyaml/NXsingle_crystal.yaml +++ b/contributed_definitions/nyaml/NXsingle_crystal.yaml @@ -38,7 +38,7 @@ NXsingle_crystal(NXobject): Unit cell of the single crystal. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# ece5215b46fffec7506fe8a5894f26facb19f44a56424615404f4cf3bd2f6334 +# 12c4f0c9868e381370d85b146404c6f6c835200ad6a1ef21d9501cd4763b23b2 # # # +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of hexahedra. +# +# +# +# +# Number of cylinders. +# +# +# +# +# Number of ellipsoids. +# +# +# +# +# Number of polyhedra. +# +# +# +# +# Base class for a spatial filter for objects within a region-of-interest (ROI). +# +# Objects can be points or objects composed from other geometric primitives. +# +# +# +# Qualitative statement which describes the logical operations +# that define which objects will be included and which excluded: +# +# * entire_dataset, no filter is applied, all objects are included. +# * union_of_primitives, a filter with (possibly non-axis-aligned) geometric +# primitives. Objects in or on the surface of the primitives are included. +# All other objects are excluded. +# * bitmask, a boolean array whose bits encode with 1 which objects +# are included. Bits set to zero encode which objects are excluded. +# Users of python can use the bitfield operations +# of the numpy package to work with bitfields. +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXspectrum_set.yaml b/contributed_definitions/nyaml/NXspectrum_set.yaml index ebddc9b338..7985b749db 100644 --- a/contributed_definitions/nyaml/NXspectrum_set.yaml +++ b/contributed_definitions/nyaml/NXspectrum_set.yaml @@ -6,6 +6,7 @@ doc: | two-, three-dimensional ROIs discretized using regular Euclidean tilings. Use stack for all other tilings. + # https://en.wikipedia.org/wiki/Euclidean_tilings_by_convex_regular_polygons symbols: n_spc: | @@ -20,6 +21,7 @@ symbols: Number of energy bins (always the fastest dimension). type: group NXspectrum_set(NXobject): + # for EELS we likely need a complex-valued NXspectrum_c_set to this # NXspectrum_set base class here which should then be splitted into an # NXspectrum_set to reduce redundant fields and specialized NXspectrum_r/c_set @@ -27,19 +29,17 @@ NXspectrum_set(NXobject): doc: | Details how spectra were processed from the detector readings. source(NXserialized): - doc: - - | + doc: | Resolvable data artifact (e.g. filename) from which all values in the :ref:`NXdata` instances in this :ref:`NXspectrum_set` were loaded during parsing. - - | + Possibility to document from which specific other serialized resource as the source pieces of information were processed when using NeXus as a semantic file format to serialize that information differently. The group in combination with an added field *absolute_path* therein adds context. absolute_path(NX_CHAR): - doc: - - | + doc: | Reference to a location inside the artifact that points to the specific group of values that were processed if the artifacts contains several groups of values and thus further resolving of ambiguities is required. @@ -49,138 +49,179 @@ NXspectrum_set(NXobject): of the data in this :ref:`NXspectrum_set` instance. detector_identifier(NX_CHAR): doc: | - Link or name of an :ref:`NXdetector` instance with which the data were collected. + Link or name of an :ref:`NXdetector` instance with which the data were + collected. (NXprogram): - ##MK::feel free to contact us when you would like to include + + #MK::feel free to contact us when you would like to include # like omega/q mapping more complicated scan pattern than rectangular ones. - spectrum_0d(NXdata): doc: | One spectrum for a point of a 0d ROI. Also known as spot measurement. intensity(NX_NUMBER): + unit: NX_UNITLESS doc: | Counts - unit: NX_UNITLESS - dim: (n_energy,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_energy]] + \@long_name: + type: NX_CHAR doc: | Counts axis_energy(NX_NUMBER): + unit: NX_ENERGY doc: | Energy axis - unit: NX_ENERGY - dim: (n_energy,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_energy]] + \@long_name: + type: NX_CHAR doc: | Energy - spectrum_1d(NXdata): doc: | One spectrum for each point of a 1d ROI. intensity(NX_NUMBER): + unit: NX_UNITLESS doc: | Counts - unit: NX_UNITLESS - dim: (n_i, n_energy) - \@long_name(NX_CHAR): + dimensions: + rank: 2 + dim: [[1, n_i], [2, n_energy]] + \@long_name: + type: NX_CHAR doc: | Counts axis_i(NX_NUMBER): + unit: NX_LENGTH doc: | Point coordinate along the fast dimension. - unit: NX_LENGTH - dim: (n_i,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_i]] + \@long_name: + type: NX_CHAR doc: | Point coordinate along the fast dimension axis_energy(NX_NUMBER): + unit: NX_ENERGY doc: | Energy axis - unit: NX_ENERGY - dim: (n_energy,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_energy]] + \@long_name: + type: NX_CHAR doc: | Energy - spectrum_2d(NXdata): doc: | One spectrum for each scan point of 2d ROI. intensity(NX_NUMBER): + unit: NX_UNITLESS doc: | Counts - unit: NX_UNITLESS - dim: (n_j, n_i, n_energy) - \@long_name(NX_CHAR): + dimensions: + rank: 3 + dim: [[1, n_j], [2, n_i], [3, n_energy]] + \@long_name: + type: NX_CHAR doc: | Counts axis_j(NX_NUMBER): + unit: NX_LENGTH doc: | Point coordinate along the slow dimension. - unit: NX_LENGTH - dim: (n_j,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_j]] + \@long_name: + type: NX_CHAR doc: | Point coordinate along the slow dimension. axis_i(NX_NUMBER): + unit: NX_LENGTH doc: | Point coordinate along the fast dimension. - unit: NX_LENGTH - dim: (n_i,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_i]] + \@long_name: + type: NX_CHAR doc: | Point coordinate along the fast dimension. axis_energy(NX_NUMBER): + unit: NX_ENERGY doc: | Energy axis - unit: NX_ENERGY - dim: (n_energy,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_energy]] + \@long_name: + type: NX_CHAR doc: | Energy - spectrum_3d(NXdata): doc: | One spectrum for point of a 3d ROI. intensity(NX_NUMBER): + unit: NX_UNITLESS doc: | Counts - unit: NX_UNITLESS - dim: (n_k, n_j, n_i, n_energy) - \@long_name(NX_CHAR): + dimensions: + rank: 4 + dim: [[1, n_k], [2, n_j], [3, n_i], [4, n_energy]] + \@long_name: + type: NX_CHAR doc: | Counts axis_k(NX_NUMBER): + unit: NX_LENGTH doc: | Point coordinate along the slower dimension. - unit: NX_LENGTH - dim: (n_k,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_k]] + \@long_name: + type: NX_CHAR doc: | Point coordinate along the slower dimension. axis_j(NX_NUMBER): + unit: NX_LENGTH doc: | Point coordinate along the slow dimension. - unit: NX_LENGTH - dim: (n_j,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_j]] + \@long_name: + type: NX_CHAR doc: | Point coordinate along the slow dimension. axis_i(NX_NUMBER): + unit: NX_LENGTH doc: | Point coordinate along the fast dimension. - unit: NX_LENGTH - dim: (n_i,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_i]] + \@long_name: + type: NX_CHAR doc: | Point coordinate along the fast dimension. axis_energy(NX_NUMBER): + unit: NX_ENERGY doc: | Energy axis - unit: NX_ENERGY - dim: (n_energy,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_energy]] + \@long_name: + type: NX_CHAR doc: | Energy + # in the majority of cases rectangular or line scans are performed # if there is interest to support arbitrary scan pattern one should use # scan points and contact us to generalize this base class and related @@ -189,146 +230,757 @@ NXspectrum_set(NXobject): doc: | Multiple instances of spectrum_0d. intensity(NX_NUMBER): + unit: NX_UNITLESS doc: | Counts - unit: NX_UNITLESS - dim: (n_spc, n_energy) - \@long_name(NX_CHAR): + dimensions: + rank: 2 + dim: [[1, n_spc], [2, n_energy]] + \@long_name: + type: NX_CHAR doc: | Counts group_identifier(NX_INT): + unit: NX_UNITLESS doc: | Group identifier - unit: NX_UNITLESS - dim: (n_spc,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_spc]] + \@long_name: + type: NX_CHAR doc: | Group identifier spectrum_identifier(NX_INT): + unit: NX_UNITLESS doc: | Spectrum identifier - unit: NX_UNITLESS - dim: (n_spc,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_spc]] + \@long_name: + type: NX_CHAR doc: | Spectrum identifier axis_energy(NX_NUMBER): + unit: NX_ENERGY doc: | Energy axis - unit: NX_ENERGY - dim: (n_energy,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_energy]] + \@long_name: + type: NX_CHAR doc: | Energy - stack_2d(NXdata): doc: | Multiple instances of spectrum_2d. intensity(NX_NUMBER): + unit: NX_UNITLESS doc: | Counts - unit: NX_UNITLESS - dim: (n_spc, n_j, n_i, n_energy) - \@long_name(NX_CHAR): + dimensions: + rank: 4 + dim: [[1, n_spc], [2, n_j], [3, n_i], [4, n_energy]] + \@long_name: + type: NX_CHAR doc: | Counts group_identifier(NX_INT): + unit: NX_UNITLESS doc: | Group identifier - unit: NX_UNITLESS - dim: (n_spc,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_spc]] + \@long_name: + type: NX_CHAR doc: | Group identifier spectrum_identifier(NX_INT): + unit: NX_UNITLESS doc: | Spectrum identifier - unit: NX_UNITLESS - dim: (n_spc,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_spc]] + \@long_name: + type: NX_CHAR doc: | Spectrum identifier axis_j(NX_NUMBER): + unit: NX_LENGTH doc: | Point coordinate along the slow dimension. - unit: NX_LENGTH - dim: (n_j,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_j]] + \@long_name: + type: NX_CHAR doc: | Point coordinate along the slow dimension. axis_i(NX_NUMBER): + unit: NX_LENGTH doc: | Point coordinate along the fast dimension. - unit: NX_LENGTH - dim: (n_i,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_i]] + \@long_name: + type: NX_CHAR doc: | Point coordinate along the fast dimension. axis_energy(NX_NUMBER): + unit: NX_ENERGY doc: | Energy axis - unit: NX_ENERGY - dim: (n_energy,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_energy]] + \@long_name: + type: NX_CHAR doc: | Energy - stack_3d(NXdata): doc: | Multiple instances of spectrum_3d. intensity(NX_NUMBER): + unit: NX_UNITLESS doc: | Counts - unit: NX_UNITLESS - dim: (n_spc, n_k, n_j, n_i, n_energy) - \@long_name(NX_CHAR): + dimensions: + rank: 5 + dim: [[1, n_spc], [2, n_k], [3, n_j], [4, n_i], [5, n_energy]] + \@long_name: + type: NX_CHAR doc: | Counts group_identifier(NX_INT): + unit: NX_UNITLESS doc: | Group identifier - unit: NX_UNITLESS - dim: (n_spc,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_spc]] + \@long_name: + type: NX_CHAR doc: | Group identifier spectrum_identifier(NX_INT): + unit: NX_UNITLESS doc: | Spectrum identifier - unit: NX_UNITLESS - dim: (n_spc,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_spc]] + \@long_name: + type: NX_CHAR doc: | Spectrum identifier axis_k(NX_NUMBER): + unit: NX_LENGTH doc: | Point coordinate along the slower dimension. - unit: NX_LENGTH - dim: (n_k,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_k]] + \@long_name: + type: NX_CHAR doc: | Point coordinate along the slower dimension. axis_j(NX_NUMBER): + unit: NX_LENGTH doc: | Point coordinate along the slow dimension. - unit: NX_LENGTH - dim: (n_j,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_j]] + \@long_name: + type: NX_CHAR doc: | Point coordinate along the slow dimension. axis_i(NX_NUMBER): + unit: NX_LENGTH doc: | Point coordinate along the fast dimension. - unit: NX_LENGTH - dim: (n_i,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_i]] + \@long_name: + type: NX_CHAR doc: | Point coordinate along the fast dimension. axis_energy(NX_NUMBER): + unit: NX_ENERGY doc: | Energy axis - unit: NX_ENERGY - dim: (n_energy,) - \@long_name(NX_CHAR): + dimensions: + rank: 1 + dim: [[1, n_energy]] + \@long_name: + type: NX_CHAR doc: | Energy + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 4337732dc413a7a33701ab6894c7bbb5ffa26b7e5ace45143ac316990034bd67 +# +# +# +# +# +# +# +# +# Number of spectra in the stack, for stacks the slowest dimension. +# +# +# +# +# Number of image points along the slower dimension (k equivalent to z). +# +# +# +# +# Number of image points along the slow dimension (j equivalent to y). +# +# +# +# +# Number of image points along the fast dimension (i equivalent to x). +# +# +# +# +# Number of energy bins (always the fastest dimension). +# +# +# +# +# Base class container for reporting a set of spectra. +# +# The mostly commonly used scanning methods are supported. That is one-, +# two-, three-dimensional ROIs discretized using regular Euclidean tilings. +# +# Use stack for all other tilings. +# +# +# +# +# Details how spectra were processed from the detector readings. +# +# +# +# Resolvable data artifact (e.g. filename) from which all values in the :ref:`NXdata` +# instances in this :ref:`NXspectrum_set` were loaded during parsing. +# +# Possibility to document from which specific other serialized resource as the source +# pieces of information were processed when using NeXus as a semantic file format +# to serialize that information differently. +# +# The group in combination with an added field *absolute_path* therein adds context. +# +# +# +# Reference to a location inside the artifact that points to the specific group of values +# that were processed if the artifacts contains several groups of values and thus +# further resolving of ambiguities is required. +# +# +# +# +# +# Imaging (data collection) mode of the instrument during acquisition +# of the data in this :ref:`NXspectrum_set` instance. +# +# +# +# +# Link or name of an :ref:`NXdetector` instance with which the data were +# collected. +# +# +# +# +# +# +# +# One spectrum for a point of a 0d ROI. Also known as spot measurement. +# +# +# +# Counts +# +# +# +# +# +# +# Counts +# +# +# +# +# +# Energy axis +# +# +# +# +# +# +# Energy +# +# +# +# +# +# +# One spectrum for each point of a 1d ROI. +# +# +# +# Counts +# +# +# +# +# +# +# +# Counts +# +# +# +# +# +# Point coordinate along the fast dimension. +# +# +# +# +# +# +# Point coordinate along the fast dimension +# +# +# +# +# +# Energy axis +# +# +# +# +# +# +# Energy +# +# +# +# +# +# +# One spectrum for each scan point of 2d ROI. +# +# +# +# Counts +# +# +# +# +# +# +# +# +# Counts +# +# +# +# +# +# Point coordinate along the slow dimension. +# +# +# +# +# +# +# Point coordinate along the slow dimension. +# +# +# +# +# +# Point coordinate along the fast dimension. +# +# +# +# +# +# +# Point coordinate along the fast dimension. +# +# +# +# +# +# Energy axis +# +# +# +# +# +# +# Energy +# +# +# +# +# +# +# One spectrum for point of a 3d ROI. +# +# +# +# Counts +# +# +# +# +# +# +# +# +# +# Counts +# +# +# +# +# +# Point coordinate along the slower dimension. +# +# +# +# +# +# +# Point coordinate along the slower dimension. +# +# +# +# +# +# Point coordinate along the slow dimension. +# +# +# +# +# +# +# Point coordinate along the slow dimension. +# +# +# +# +# +# Point coordinate along the fast dimension. +# +# +# +# +# +# +# Point coordinate along the fast dimension. +# +# +# +# +# +# Energy axis +# +# +# +# +# +# +# Energy +# +# +# +# +# +# +# +# Multiple instances of spectrum_0d. +# +# +# +# Counts +# +# +# +# +# +# +# +# Counts +# +# +# +# +# +# Group identifier +# +# +# +# +# +# +# Group identifier +# +# +# +# +# +# Spectrum identifier +# +# +# +# +# +# +# Spectrum identifier +# +# +# +# +# +# Energy axis +# +# +# +# +# +# +# Energy +# +# +# +# +# +# +# Multiple instances of spectrum_2d. +# +# +# +# Counts +# +# +# +# +# +# +# +# +# +# Counts +# +# +# +# +# +# Group identifier +# +# +# +# +# +# +# Group identifier +# +# +# +# +# +# Spectrum identifier +# +# +# +# +# +# +# Spectrum identifier +# +# +# +# +# +# Point coordinate along the slow dimension. +# +# +# +# +# +# +# Point coordinate along the slow dimension. +# +# +# +# +# +# Point coordinate along the fast dimension. +# +# +# +# +# +# +# Point coordinate along the fast dimension. +# +# +# +# +# +# Energy axis +# +# +# +# +# +# +# Energy +# +# +# +# +# +# +# Multiple instances of spectrum_3d. +# +# +# +# Counts +# +# +# +# +# +# +# +# +# +# +# Counts +# +# +# +# +# +# Group identifier +# +# +# +# +# +# +# Group identifier +# +# +# +# +# +# Spectrum identifier +# +# +# +# +# +# +# Spectrum identifier +# +# +# +# +# +# Point coordinate along the slower dimension. +# +# +# +# +# +# +# Point coordinate along the slower dimension. +# +# +# +# +# +# Point coordinate along the slow dimension. +# +# +# +# +# +# +# Point coordinate along the slow dimension. +# +# +# +# +# +# Point coordinate along the fast dimension. +# +# +# +# +# +# +# Point coordinate along the fast dimension. +# +# +# +# +# +# Energy axis +# +# +# +# +# +# +# Energy +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXspin_rotator.yaml b/contributed_definitions/nyaml/NXspin_rotator.yaml index 8cdf66348c..e453667d8b 100644 --- a/contributed_definitions/nyaml/NXspin_rotator.yaml +++ b/contributed_definitions/nyaml/NXspin_rotator.yaml @@ -47,13 +47,13 @@ NXspin_rotator(NXobject): unit: NX_VOLTAGE # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 260f697bca7fcdb6e806e85e0cb1459de350eab0f1eb633c5b15ac31d38c1572 +# c9579a21de3419c77dcb3d634bad2e9191219592ca843b1d0006196742cabbf6 # # # +# +# +# Base class for a stage (lab) used to hold, orient, and prepare a specimen. +# +# Modern stages are multi-functional devices. Stages provide a controlled +# environment around the specimen. Stages enable experimentalists to apply +# controlled external stimuli on the specimen. A stage_lab is a multi-purpose +# /-functional tool that is constructed from multiple actuators, sensors, +# and other components. +# +# With such stages comes the need for storing various (meta)data +# that are generated while working and modifying the sample. +# +# Modern stages realize a hierarchy of components. Two examples are given to help +# clarify how :ref:`NXstage_lab` instances should be used: Take a specimen that is +# mounted on a multi-axial tilt rotation holder. This holder is fixed in the +# support unit which connects the holder to the rest of the instrument. +# Evidently different components are all considerable as to represent instances +# of stages. +# +# In another example, taken from atom probe microscopy, researchers may work +# with wire samples which are clipped into a larger fixing unit to enable +# careful specimen handling. Alternatively, a microtip is a silicon post +# upon which e.g. an atom probe specimen is mounted. +# Multiple microtips are grouped into a microtip array to conveniently enable +# loading of multiple specimens into the instrument with fewer operations. +# That microtip array is fixed on a holder. Fixture units in atom probe are known +# as stubs. Stubs in turn are positioned onto pucks. Pucks are then loaded onto +# carousels. A carousel is a carrier unit with which eventually entire sets of +# specimens can be moved in between parts of the microscope. All of these units +# can be considered stage_lab instances. +# +# The :ref:`NXstage_lab` base class reflects this hierarchy. To cover for an as flexible +# design of complex stages as possible, users should nest multiple instances of +# :ref:`NXstage_lab` according to their needs to reflect the differences between what +# they consider as the holder and what they consider is the stage. +# The alias field can be used to specify the community jargon if necessary. +# +# However, a much clearer approach to reflect the hierarchy of all :ref:`NXstage_lab` +# instances is postfix each instance named stage_lab with integers starting +# from 1 as the top level unit. +# In the microtip example one could thus use stage_lab1 for the microtip, +# stage_lab2 for the microtip array, stage_lab3 holder, etc. +# The depends_on keyword should be used to additional clarify the hierarchy +# especially when users decide to not follow the above-mentioned postfixing +# notation or when is not obvious from the postfixes which stage_lab is at +# which level of the stage_lab hierarchy. +# +# Some examples for stage_labs in applications: +# +# * A nanoparticle on a copper grid. The copper grid is the holder. +# The grid itself is fixed to a stage. +# * An atom probe specimen fixed in a stub. In this case the stub can be +# considered the holder, while the cryostat temperature control unit is +# a component of the stage. +# * Samples with arrays of specimens, like a microtip on a microtip array +# is an example of an at least three-layer hierarchy commonly employed for +# efficient sequential processing of atom probe experiments. +# * With one entry of an application definition only one microtip should be +# described. Therefore, the microtip is the specimen, +# the array is the holder and the remaining mounting unit +# that is attached to the cryo-controller is the stage. +# * For in-situ experiments with e.g. chips with read-out electronics +# as actuators, the chips are again placed in a larger unit. A typical +# example are in-situ experiments using e.g. the tools of `Protochips <https://www.protochips.com>`_. +# * Other examples are (quasi) in-situ experiments where experimentalists +# anneal or deform the specimen via e.g. in-situ tensile testing machines +# which are mounted on the specimen holder. +# +# For specific details and inspiration about stages in electron microscopes: +# +# * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ +# * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ +# * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ +# * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) +# * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) +# * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) +# * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ +# +# We are looking forward to suggestions from the scientists. +# +# +# +# Principal design of the stage. +# +# Exemplar terms could be side_entry, top_entry, +# single_tilt, quick_change, multiple_specimen, +# bulk_specimen, double_tilt, tilt_rotate, +# heating_chip, atmosphere_chip, +# electrical_biasing_chip, liquid_cell_chip +# +# +# +# +# Free-text field to give a term how that a stage_lab at this level of the +# stage_lab hierarchy is commonly referred to. Examples could be stub, +# puck, carousel, microtip, clip, holder, etc. +# +# +# +# +# The interpretation of this tilt should be specialized +# and thus detailed via the application definition. +# +# +# +# +# The interpretation of this tilt should be specialized +# and thus detailed via the application definition. +# +# +# +# +# The interpretation of this rotation should be specialized +# and thus detailed via the application definition. +# +# +# +# +# The interpretation of this position should be specialized +# and thus detailed via the application definition. +# +# +# +# +# +# +# +# Voltage applied to the stage to decelerate electrons. +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXsts.yaml b/contributed_definitions/nyaml/NXsts.yaml index cad72e7348..d73a7b416b 100644 --- a/contributed_definitions/nyaml/NXsts.yaml +++ b/contributed_definitions/nyaml/NXsts.yaml @@ -23,6 +23,8 @@ doc: | # 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the +# 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the + # 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the type: group NXsts(NXsensor_scan): @@ -909,7 +911,7 @@ NXsts(NXsensor_scan): Mesh scan with 2D slices of the above alternative plot for other y co-ordinates. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 9b03474c63a6c51c01d31f3cbd3ec65c6f18db027dd4b72cbca8e92c52e34f03 +# 776ea2eb9a35a47c82381344eb9b5edce08066a88c7acc5dc7ff8f00bdf680ba # # # # +# # # # Application definition for temperature-dependent IV curve measurements @@ -988,24 +992,24 @@ NXsts(NXsensor_scan): # # # -# +# # # The name of the output file, with the number of scans at the end. (e.g. # 221122_Au_5K00014) # -# -# +# +# # # The name of the series output file, which represents only the public part of the # output file. (e.g. 221122_Au_5K) # -# -# +# +# # # Path to storage of output files. # (e.g. Path C:\Users\SPM-PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis-Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711) # -# +# # # # Descriptive comments for this experiment, added by the experimenter, coming from the @@ -1038,7 +1042,9 @@ NXsts(NXsensor_scan): # # # -# +# # # Status of Lock-in device whether while performing the experiment # @@ -1055,7 +1061,9 @@ NXsts(NXsensor_scan): # # # -# +# # # The signal is modulated by adding the frequency of the sine modulation. The # modulation frequency spans can be from 10 mHz to 40 kHz, corresponding to the output filter @@ -1066,15 +1074,19 @@ NXsts(NXsensor_scan): # # # -# +# # # The amplitude (in physical units of modulated signal) of the sine modulation. # # # -# +# set in the Frequency field (“4”) or harmonics. +# --> # # The input signal (STS signal) will be demodulated, in order to determine the amplitude # and phase at the frequency set in the Frequency field or harmonics, such as current, @@ -1082,8 +1094,10 @@ NXsts(NXsensor_scan): # # # -# +# # # N denotes 1 or 2. The order of the harmonic oscillation to be detected in the demodulated # signal should be considered relative to the modulation frequency. When dealing with @@ -1092,8 +1106,10 @@ NXsts(NXsensor_scan): # # # -# +# # # Reference phase for the sine on the demodulated signal with respect to the # modulation signal. The determined phase is displayed with respect to the @@ -1389,7 +1405,7 @@ NXsts(NXsensor_scan): # # # -# In STM experiment, the scan range is the coordinate (x,y) along the X and Y axis from the origin (scan_offset) of +# In STM experiment, the scan range is the coordinate (x,y) along the X and Y axis from the origin (scan_offset) of # the scan area (e.g. 5.000000E-9 5.000000E-9). # # diff --git a/contributed_definitions/nyaml/NXsubsampling_filter.yaml b/contributed_definitions/nyaml/NXsubsampling_filter.yaml index b7b47a1e15..c96372f027 100644 --- a/contributed_definitions/nyaml/NXsubsampling_filter.yaml +++ b/contributed_definitions/nyaml/NXsubsampling_filter.yaml @@ -1,10 +1,12 @@ category: base doc: | Base class of a filter to sample members in a set based on their identifier. + # symbols: type: group NXsubsampling_filter(NXobject): min_incr_max(NX_INT): + unit: NX_UNITLESS doc: | Triplet of the minimum, the increment, and the maximum identifier to include of a sequence :math:`[i_0, i_0 + 1, i_0 + 2, \ldots, i_0 + \mathcal{N}] with i_0 \in \mathcal{Z}` @@ -16,5 +18,56 @@ NXsubsampling_filter(NXobject): yield all identifier. Setting min_incr_max to [0, 2, 99] will take each second identifier. Setting min_incr_max to [90, 3, 99] will take each third identifier beginning from identifier 90 up to 99. - unit: NX_UNITLESS - dim: (3,) + dimensions: + rank: 1 + dim: [[1, 3]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e2701c010e3087999ea363371d28ee558079269bea72b3980e707661bbd7d025 +# +# +# +# +# +# +# Base class of a filter to sample members in a set based on their identifier. +# +# +# +# Triplet of the minimum, the increment, and the maximum identifier to +# include of a sequence :math:`[i_0, i_0 + 1, i_0 + 2, \ldots, i_0 + \mathcal{N}] with i_0 \in \mathcal{Z}` +# of identifier. The increment controls which n-th identifier (value) to take. +# +# Take as an example a dataset with 100 identifier (aka entries). Assume that +# the identifier start at zero, i.e. identifier_offset is 0). Assume further +# that min_incr_max is set to [0, 1, 99]. In this case the filter will +# yield all identifier. Setting min_incr_max to [0, 2, 99] will take each +# second identifier. Setting min_incr_max to [90, 3, 99] will take each +# third identifier beginning from identifier 90 up to 99. +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXtransmission.yaml b/contributed_definitions/nyaml/NXtransmission.yaml index ddc3074d69..a0d7fbbc42 100644 --- a/contributed_definitions/nyaml/NXtransmission.yaml +++ b/contributed_definitions/nyaml/NXtransmission.yaml @@ -248,14 +248,14 @@ NXtransmission(NXobject): replaced by any suitable parameter along the X-axis. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8e44140527b6ce26fe9832c663c9074067ec6c8ecfdb137c8740677c772749f8 -# +# 5b7a3a54abdb89ba72cdafc2c4de1b6f5b3a35e93e489aedfd2622fb1b45fc31 +# # # -# -# +# # # # Variables used throughout the experiment @@ -322,7 +323,7 @@ NXtransmission(NXobject): # Start time of the experiment. # # -# +# # # Unique identifier of the experiment, such as a (globally persistent) # unique identifier. @@ -331,7 +332,7 @@ NXtransmission(NXobject): # investigator. # * The identifier enables to link experiments to e.g. proposals. # -# +# # # # An optional free-text description of the experiment. However, details of the @@ -350,12 +351,12 @@ NXtransmission(NXobject): # used to generate the result file(s) with measured data and metadata. # # -# +# # # Version number of the program that was used to generate the result # file(s) with measured data and metadata. # -# +# # # # Website of the software @@ -584,8 +585,10 @@ NXtransmission(NXobject): # # # -# +# # # Properties of the sample measured # diff --git a/contributed_definitions/nyaml/NXunit_cell.yaml b/contributed_definitions/nyaml/NXunit_cell.yaml index f2ebd6fcac..3bb9ecf7f2 100644 --- a/contributed_definitions/nyaml/NXunit_cell.yaml +++ b/contributed_definitions/nyaml/NXunit_cell.yaml @@ -151,13 +151,13 @@ NXunit_cell(NXobject): For definining which coordinate system the unit cell parameters are defined in. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4921c2e1993393e8f5cb0b44e3470cba5cf59b6d1a88c15ef3cec4f60ccee8f3 -# +# a46d03548ce1236f811923401038d3d20837973e153f67e1d7117d5367409825 +# # # -# -# +# +# # # # @@ -199,6 +200,11 @@ NXwaveplate(NXobject): # # # +# +# +# Wavelength resolved retardence of the waveplate. +# +# # # # Diameter of the waveplate. diff --git a/contributed_definitions/nyaml/NXxpcs.yaml b/contributed_definitions/nyaml/NXxpcs.yaml index 20dd211c91..419208e9ef 100644 --- a/contributed_definitions/nyaml/NXxpcs.yaml +++ b/contributed_definitions/nyaml/NXxpcs.yaml @@ -478,13 +478,13 @@ NXxpcs(NXobject): Describe the computation process that produced these results. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 24b656b7be7f0c85955748deed904585a8136c312327d128d6a4a377760052c8 +# e441dbb2703c7c93841979c83e2456dd89139b900d59fea050fb65f601d4f74b # # # +# +# +# +# NXxrd on top of NXmonopd +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# +# +# +# +# raw detector signal (usually counts) as colected +# it can be a multi-dimensional dataset depending on +# the detector type (faster axes) and +# the scanning method (slower axes) +# +# +# +# +# The 2-theta range of the difractogram +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# link (suggested target:/NXentry/NXinstrument/NXdetector/polar_angle) +# Link to ponglar ale in /NXentry/NXinstrument/NXdetector +# +# +# +# +# +# +# +# link (suggested target:/NXentry/NXinstrument/NXdetector/data) +# Link to data in /Nxentry/Nxinstrument/Nxdetector +# +# +# +# +# +# +# +# +# Description of a processing or analysis step, such as the +# baseline extraction or azimuth integration. +# Add additional fields as needed to describe value(s) of +# any variable, parameter, or term related to +# the NXprocess step. Be sure to include units attributes +# for all numerical fields. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXxrd_pan.yaml b/contributed_definitions/nyaml/NXxrd_pan.yaml index cc35136211..10a47787d0 100644 --- a/contributed_definitions/nyaml/NXxrd_pan.yaml +++ b/contributed_definitions/nyaml/NXxrd_pan.yaml @@ -145,14 +145,14 @@ NXxrd_pan(NXxrd): Number of scattered electrons per unit time. dimensions: rank: 1 - dim: (nDet,) + dim: [[1, nDet]] two_theta(NX_FLOAT): unit: NX_ANGLE doc: | Two-theta (scattering angle) of the diffractogram. dimensions: rank: 1 - dim: (nDet,) + dim: [[1, nDet]] omega(NX_FLOAT): exists: optional unit: NX_ANGLE @@ -160,7 +160,7 @@ NXxrd_pan(NXxrd): Incident angle of the diffractogram. dimensions: rank: 1 - dim: (nDet,) + dim: [[1, nDet]] phi(NX_FLOAT): exists: optional unit: NX_ANGLE @@ -168,7 +168,7 @@ NXxrd_pan(NXxrd): The phi range of the diffractogram. dimensions: rank: 1 - dim: (nDet,) + dim: [[1, nDet]] chi(NX_FLOAT): exists: optional unit: NX_ANGLE @@ -176,7 +176,7 @@ NXxrd_pan(NXxrd): The chi range of the diffractogram dimensions: rank: 1 - dim: (nDet,) + dim: [[1, nDet]] q_parallel(NX_FLOAT): exists: optional unit: NX_ANY @@ -243,7 +243,7 @@ NXxrd_pan(NXxrd): assumed name or given name. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# ea24fb9f19ac04432bece15f366c44f2c370632bdcbea76b916920013d4e6c11 +# fc8f25f08e852b590c75f476e9a5b4e369d8c262b7063c38a034184e2f89fbc2 # # # -# -# -# Application definition for normalized representation of electron microscopy research. -# -# This application definition is a comprehensive example for a general description -# with which to normalize specific pieces of information and data collected within -# electron microscopy research. -# -# NXem is designed to be used for documenting experiments or computer simulations in which -# controlled electron beams are used for studying electron-beam matter interaction to explore -# physical mechanisms and phenomena, or to characterize materials with an electron microscope. -# -# -# -# -# -# -# -# -# -# -# -# The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_ or its plugins) -# which was used to generate this NeXus file instance. -# -# -# -# A collection of all programs and libraries that are considered as relevant -# to understand with which software tools this NeXus file instance was -# generated. Ideally, to enable a binary recreation from the input data. -# -# Examples include the name and version of the libraries used to write the -# instance. Ideally, the software which writes these NXprogram instances -# also includes the version of the set of NeXus classes i.e. the specific -# set of base classes, application definitions, and contributed definitions -# with which the here described concepts can be resolved. -# -# For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ -# which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ -# research data management system, it makes sense to store e.g. the GitHub -# repository commit and respective submodule references used. -# -# -# -# -# -# -# -# -# Ideally, a (globally) unique persistent identifier for referring to this experiment. -# -# An experiment should be understood in that this can be an experiment -# in reality or a computer simulation because also the latter is an experiment -# (see the Cambridge Dictionary experiment *a test done in order to find out -# something, eg if an idea is correct*). -# -# The identifier is usually issued by the facility, laboratory, or the principle investigator. -# The identifier enables to link experiments/simulations to e.g. proposals. -# -# -# -# -# -# -# -# Alias which scientists can easier identify this experiment by. -# -# -# -# -# Free-text description about the experiment. -# -# Users are strongly advised to parameterize the description of their experiment -# by using respective groups and fields and base classes instead of writing prose -# into the field. The reason is that such free-text field is difficult to machine-interpret. -# The motivation behind keeping this field for now is to learn in how far the -# current base classes need extension based on user feedback. -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC information included -# when the microscope session started. If the application demands that time -# codes in this section of the application definition should only be used -# for specifying when the experiment was performed - and the exact -# duration is not relevant use this start_time field. -# -# Often though it is useful to specify a time interval via setting both a start_time -# and an end_time because this enables software tools and users to collect a -# more detailed bookkeeping of the experiment. -# -# Users should be aware though that even with having both time instances -# specified, it may not be possible to infer how long the experiment took or -# for how long data were acquired. -# -# More detailed timing data over the course of the experiment have -# to be collected to compute this. These computations can take -# advantage of individual time stamps start_time and end_time -# in :ref:`NXevent_data_em` instances. -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC included when -# the microscope session ended. -# -# See docstring of the start_time field to see how to use the -# start_time and end_time together. -# -# -# -# -# -# Possibility to store a collection of serialized resources associated with the -# experiment. -# -# An example how to use this set could be to document from which files, which have been -# e.g. generated by software of technology partners, the information in an instance of -# NXem was filled with during parsing or transcoding between different formats. -# -# -# -# -# -# -# -# -# -# Information about persons who performed or were involved in the microscope -# session or simulation run. -# -# This can be the principle investigator who performed this experiment or the student who performed simulations. -# Adding multiple users if relevant is recommended. -# -# -# -# Given (first) name and surname. -# -# -# -# -# Name of the affiliation at the point in time when the experiment was performed. -# -# -# -# -# Postal address of the affiliation. -# -# -# -# -# Email address at the point in time when the experiment was performed. -# -# Writing the most permanently used email is recommended. -# -# -# -# -# Telephone number at the point in time when the experiment was performed. -# -# -# -# -# User role at the point in time when the experiment was performed. -# -# Examples are technician operating the microscope, student, postdoc, -# principle investigator, or guest. -# -# -# -# -# Identifier offered by a service to report the user other than by using its name. -# -# Examples could be an ORCID or social media account of the user. -# -# -# -# -# -# -# -# -# A physical entity which contains material intended to be investigated. -# Sample and specimen are treated as de facto synonyms. Samples can be real or virtual ones. -# -# This concept is related to term `Specimen`_ of the EMglossary standard. -# -# .. _Specimen: https://purls.helmholtz-metadaten.de/emg/EMG_00000046 -# -# -# -# Qualifier whether the sample is a real or a virtual one. -# -# -# -# -# -# -# -# -# Ideally, (globally) unique persistent identifier which distinguishes the sample from all others -# and especially the predecessor/origin from where that sample was cut. The terms sample -# and specimen are here considered as exact synonyms. -# -# This field must not be used for an alias! Instead, use name. -# -# In cases where multiple specimens were loaded into the microscope, the identifier has to resolve -# the specific sample, whose results are stored by this :ref:`NXentry` instance because a single -# NXentry should be used for the characterization of a single specimen. -# -# Details about the specimen preparation should be stored in resources referring to parent_identifier. -# -# -# -# -# -# -# -# Identifier of the sample from which the sample was cut or the string *None*. -# -# The purpose of this field is to support functionalities for tracking -# sample provenance in a research data management system. -# -# -# -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC information -# when the specimen was prepared. -# -# Ideally, report the end of the preparation, i.e. the last known timestamp when -# the measured specimen surface was actively prepared. Ideally, this matches -# the last timestamp that is mentioned in the digital resource pointed to by -# parent_identifier. -# -# Knowing when the specimen was exposed to e.g. specific atmosphere is especially -# required for environmentally sensitive material such as specimen charged with hydrogen -# or experiments including tracers that have a short halflife. Additional time stamps -# prior to preparation_date should better be placed in resources which describe but -# which do not pollute the description here with prose. Resolving these connected -# pieces of information is considered the responsibility of the -# research data management system not of a NeXus file. -# -# -# -# -# An alias used to refer to the specimen to please readability for humans. -# -# -# -# -# List of comma-separated elements from the periodic table that are contained in the sample. -# If the sample substance has multiple components, all elements from each component -# must be included in atom_types. -# -# The purpose of the field is to offer research data management systems an opportunity -# to parse the relevant elements without having to interpret these from the resources -# pointed to by parent_identifier or walk through eventually deeply nested groups in -# individual data instances. -# -# -# -# -# (Measured) sample thickness. -# -# The information is recorded to qualify if the beam used was likely -# able to shine through the specimen. For scanning electron microscopy, -# in many cases the specimen is typically thicker than what is -# illuminatable by the electron beam. -# -# In this case the value should be set to the actual thickness of -# the specimen viewed for an illumination situation where the nominal -# surface normal of the specimen is parallel to the optical axis. -# -# -# -# -# -# (Measured) density of the specimen. -# -# For multi-layered specimens this field should only be used to describe -# the density of the excited volume. For scanning electron microscopy -# the usage of this field is discouraged and instead an instance of an -# :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` -# instances can provide a cleaner description of the relevant details -# why one may wish to store the density of the specimen. -# -# -# -# -# Discouraged free-text field to provide further detail although adding -# parent_identifier and having a working research data management system -# should provide this contextualization. -# -# -# -# -# -# Set to hold different coordinate systems conventions. -# -# Inspect the description of the :ref:`NXcoordinate_system_set` and :ref:`NXcoordinate_system` base classes -# how to define coordinate systems in NeXus. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Location of the origin of the processing_reference_frame. -# -# It is assumed that regions-of-interest in this reference frame form a rectangle or cuboid. -# Edges are interpreted by inspecting the direction of their outer unit normals -# (which point either parallel or antiparallel) along respective base vector direction -# of the reference frame. -# -# If any of these assumptions is not met, the user is required to explicitly state this. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing x-axis base vector of the -# processing_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing y-axis base vector of the -# processing_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing z-axis base vector of the -# processing_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Reference to the specifically named :ref:`NXsample` instance(s) for -# which these conventions apply (e.g. /entry1/sample1). -# -# -# -# -# -# -# -# Location of the origin of the sample_reference_frame. -# -# It is assumed that regions-of-interest in this reference frame form a rectangle or cuboid. -# Edges are interpreted by inspecting the direction of their outer unit normals -# (which point either parallel or antiparallel) along respective base vector direction -# of the reference frame. -# -# If any of these assumptions is not met, the user is required to explicitly state this. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing x-axis base vector of the -# sample_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing y-axis base vector of the -# sample_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing z-axis base vector of the -# sample_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Reference to the specifically named :ref:`NXdetector` instance for -# which these conventions apply (e.g. /entry1/instrument/detector1). -# -# -# -# -# -# -# -# Location of the origin of the detector_reference_frame. -# -# If the regions-of-interest forms a rectangle or cuboid, it is assumed that edges are interpreted -# by inspecting the direction of their outer unit normals (which point either parallel or antiparallel) -# along respective base vector direction of the reference frame. -# -# If any of these assumptions is not met, the user is required to explicitly state this. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing x-axis base vector of the -# detector_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing y-axis base vector of the -# detector_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing z-axis base vector of the -# detector_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Details about the control program used for operating the microscope. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# This concept is related to term `Source`_ of the EMglossary standard. -# -# .. _Source: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Device for improving energy resolution or reducing chromatic aberration. -# -# Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector -# like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ -# -# -# -# -# Qualitative type of the component. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Device reshaping an ellipse-shaped electron beam to a circular one. -# -# * `L. Reimer 1998, Springer, 1998 <https://dx.doi.org/10.1007/978-3-540-3896>`_ -# * `M. Tanaka et al., Electron Microscopy Glossary, 2024 <https://www.jeol.com/words/semterms/20201020.111014.php#gsc.tab=0>`_ -# -# Stigmator is an exact synonym. -# -# -# -# -# -# -# -# -# -# Electron biprism as it is used e.g. for electron holography. -# -# -# -# -# -# -# -# -# -# -# Device that causes a change in the phase of an electron wave. -# -# * `M. Malac et al. <https://doi.org/10.1093/jmicro/dfaa070>`_ -# * `R. R. Schröder et al. <https://www.lem.kit.edu/152.php>`_ -# -# -# -# Qualitative type -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Device for improving energy resolution or reducing chromatic aberration. -# -# Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector -# like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ -# -# -# -# Qualitative type of the component. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# This concept is related to term `Source`_ of the EMglossary standard. -# -# .. _Source: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 -# -# -# -# The potential difference between anode and cathode. -# -# This concept is related to term `Acceleration Voltage`_ of the EMglossary standard. -# -# .. _Acceleration Voltage: https://purls.helmholtz-metadaten.de/emg/EMG_00000004 -# -# -# -# -# Voltage which is utilised to create an electric field that draws particles from -# the source. -# -# This concept is related to term `Extraction Voltage`_ of the EMglossary standard. -# -# .. _Extraction Voltage: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 -# -# -# -# -# Electrical current which is released from the source. -# -# This concept is related to term `Emission Current`_ of the EMglossary standard. -# -# .. _Emission Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 -# -# -# -# -# Electrical current which flows through the source. -# -# This concept is related to term `Filament Current`_ of the EMglossary standard. -# -# .. _Filament Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000027 -# -# -# -# -# -# -# -# -# -# Relevant value from the control software. -# -# This is not always just the diameter of the aperture (not even in the case) -# of a circular aperture. Usually, it is a value that is set in the control -# software whereby a specific configuration of an aperture is selected by the -# software. -# -# The control software of commercial microscope typically offers the user -# access at a high abstraction level because of which many details about -# the actual settings of the electrical components are typically unknown. -# -# However, if more details are known or should be documented one should -# use the description field for this. -# -# -# -# -# -# Device to improve energy resolution or chromatic aberration. -# -# Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector -# like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ -# -# -# -# -# Was the corrector used? -# -# -# -# -# -# Energy dispersion in e.g. µm/eV. -# -# -# -# -# Corresponding voltage for that energy dispersion. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Device reshaping an ellipse-shaped electron beam to a circular one. -# -# * `L. Reimer 1998, Springer, 1998 <https://dx.doi.org/10.1007/978-3-540-3896>`_ -# * `M. Tanaka et al., Electron Microscopy Glossary, 2024 <https://www.jeol.com/words/semterms/20201020.111014.php#gsc.tab=0>`_ -# -# Stigmator is an exact synonym. -# -# -# -# Was the corrector used? -# -# -# -# -# Descriptor for the correction strength along the first direction when exact technical details -# are unknown or not directly controllable as the control software of the microscope does not -# enable or was not configured to display these values (for end users). -# -# -# -# -# Descriptor for the correction strength along the second direction when exact technical details -# are unknown or not directly controllable as the control software of the microscope does not -# enable or was not configured to display these values (for end users). -# -# -# -# -# -# -# -# -# -# This concept is related to term `Electron Beam`_ of the EMglossary standard. -# -# .. _Electron Beam: https://purls.helmholtz-metadaten.de/emg/EMG_00000021 -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Relevant value from the control software. -# -# This is not always just the diameter of the aperture (not even in the case) -# of a circular aperture. Usually, it is a value that is set in the control -# software whereby a specific configuration of an aperture is selected by the -# software. -# -# The control software of commercial microscope typically offers the user -# access at a high abstraction level because of which many details about -# the actual settings of the electrical components are typically unknown. -# -# However, if more details are known or should be documented one should -# use the description field for this. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Nominal current of the heater. -# -# -# -# -# Nominal voltage of the heater. -# -# -# -# -# Nominal power of the heater. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# A region-of-interest analyzed either during or after the session -# for which specific processed data are available. -# -# This concept is related to term `Region Of Interest`_ of the EMglossary standard. -# -# .. _Region Of Interest: https://purls.helmholtz-metadaten.de/emg/EMG_00000042 -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# +# see an example how to map e.g. the following flat schema https://www.zenodo.org/record/6513745 to NXem +# in https://github.com/FAIRmat-NFDI/nexus_definitions/commit/0b928c4352bc5636f673b5fb25ce990f1af8a099 \ No newline at end of file From 31f5e9dff2533735b526a7c99d6ebe23eecf7680 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 16 Sep 2024 15:48:12 +0200 Subject: [PATCH 0959/1012] format base classes and applications in accordance to existing NIAC version --- Makefile | 21 +- applications/NXarpes.nxdl.xml | 253 ++- applications/nyaml/NXarpes.yaml | 253 ++- base_classes/NXaperture.nxdl.xml | 100 +- base_classes/NXbeam.nxdl.xml | 359 ++-- base_classes/NXdata.nxdl.xml | 1018 +++++----- base_classes/NXdetector.nxdl.xml | 1965 +++++++++---------- base_classes/NXentry.nxdl.xml | 458 ++--- base_classes/NXenvironment.nxdl.xml | 66 +- base_classes/NXinstrument.nxdl.xml | 120 +- base_classes/NXmonochromator.nxdl.xml | 133 +- base_classes/NXprocess.nxdl.xml | 60 +- base_classes/NXroot.nxdl.xml | 136 +- base_classes/NXsample.nxdl.xml | 859 ++++----- base_classes/NXsample_component.nxdl.xml | 308 ++- base_classes/NXsensor.nxdl.xml | 332 ++-- base_classes/NXsource.nxdl.xml | 569 +++--- base_classes/NXsubentry.nxdl.xml | 376 ++-- base_classes/NXtransformations.nxdl.xml | 703 +++---- base_classes/NXuser.nxdl.xml | 130 +- base_classes/nyaml/NXaperture.yaml | 100 +- base_classes/nyaml/NXbeam.yaml | 377 ++-- base_classes/nyaml/NXdata.yaml | 1570 ++++++++------- base_classes/nyaml/NXdetector.yaml | 2020 ++++++++++---------- base_classes/nyaml/NXentry.yaml | 500 +++-- base_classes/nyaml/NXenvironment.yaml | 74 +- base_classes/nyaml/NXinstrument.yaml | 124 +- base_classes/nyaml/NXmonochromator.yaml | 137 +- base_classes/nyaml/NXprocess.yaml | 60 +- base_classes/nyaml/NXroot.yaml | 136 +- base_classes/nyaml/NXsample.yaml | 876 ++++----- base_classes/nyaml/NXsample_component.yaml | 319 ++-- base_classes/nyaml/NXsensor.yaml | 337 ++-- base_classes/nyaml/NXsource.yaml | 587 +++--- base_classes/nyaml/NXsubentry.yaml | 376 ++-- base_classes/nyaml/NXtransformations.yaml | 870 ++++----- base_classes/nyaml/NXuser.yaml | 130 +- 37 files changed, 8190 insertions(+), 8622 deletions(-) diff --git a/Makefile b/Makefile index 5d43fd96d6..47a60036a2 100644 --- a/Makefile +++ b/Makefile @@ -61,9 +61,6 @@ test :: clean :: $(RM) -rf $(BUILD_DIR) - $(RM) -rf $(BASE_CLASS_DIR)/$(NYAML_SUBDIR) - $(RM) -rf $(APPDEF_DIR)/$(NYAML_SUBDIR) - $(RM) -rf $(CONTRIB_DIR)/$(NYAML_SUBDIR) clean-nyaml :: $(RM) -rf $(BASE_CLASS_DIR)/$(NYAML_SUBDIR) @@ -114,27 +111,13 @@ $(APPDEF_DIR)/%.nxdl.xml : $(APPDEF_DIR)/$(NYAML_SUBDIR)/%.yaml nxdl: $(YBC_NXDL_TARGETS) $(YCONTRIB_NXDL_TARGETS) $(YAPPDEF_NXDL_TARGETS) -nyaml: - $(MAKE) -f nyaml.mk - -$(BASE_CLASS_DIR)/%.nxdl.xml : $(BASE_CLASS_DIR)/$(NYAML_SUBDIR)/%.yaml - nyaml2nxdl $< --output-file $@ - -$(CONTRIB_DIR)/%.nxdl.xml : $(CONTRIB_DIR)/$(NYAML_SUBDIR)/%.yaml - nyaml2nxdl $< --output-file $@ - -$(APPDEF_DIR)/%.nxdl.xml : $(APPDEF_DIR)/$(NYAML_SUBDIR)/%.yaml - nyaml2nxdl $< --output-file $@ - -nxdl: $(YBC_NXDL_TARGETS) $(YCONTRIB_NXDL_TARGETS) $(YAPPDEF_NXDL_TARGETS) - nyaml: $(MAKE) -f nyaml.mk # NeXus - Neutron and X-ray Common Data Format # -# Copyright (C) 2008-2024 NeXus International Advisory Committee (NIAC) +# Copyright (C) 2008-2022 NeXus International Advisory Committee (NIAC) # # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public @@ -150,4 +133,4 @@ nyaml: # License along with this library; if not, write to the Free Software # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA # -# For further information, see http://www.nexusformat.org +# For further information, see http://www.nexusformat.org \ No newline at end of file diff --git a/applications/NXarpes.nxdl.xml b/applications/NXarpes.nxdl.xml index 8d17472ad3..e792d30adb 100644 --- a/applications/NXarpes.nxdl.xml +++ b/applications/NXarpes.nxdl.xml @@ -1,10 +1,10 @@ - - + + - - - This is an application definition for angular resolved photo electron spectroscopy. - - It has been drawn up with hemispherical electron analysers in mind. - - This definition is a legacy support for older NXarpes experiments. - There is, however, a newer definition to collect data & metadata - for general photoemission experiments, called :ref:NXmpes, - as well as a specialization for ARPES experiments, called :ref:NXmpes_arpes." - - - - - NeXus convention is to use "entry1", "entry2", ... - for analysis software to locate each entry. - - - - - - - Official NeXus NXDL schema to which this file conforms. - - - - + + + This is an application definition for angular resolved photo electron spectroscopy. + + It has been drawn up with hemispherical electron analysers in mind. + + This definition is a legacy support for older NXarpes experiments. + There is, however, a newer definition to collect data & metadata + for general photoemission experiments, called :ref:NXmpes, + as well as a specialization for ARPES experiments, called :ref:NXmpes_arpes." + + + + + NeXus convention is to use "entry1", "entry2", ... + for analysis software to locate each entry. + + + + + + Official NeXus NXDL schema to which this file conforms. + + + + + + + + + + + + + + + + + + + + + setting for the electron analyser lens + + + + + + + + + + + + + + + dial setting of the entrance slit + + + size of the entrance slit + + + energy of the electrons on the mean path of the analyser - - - - - - - - - - - - - - - - - - setting for the electron analyser lens - - - - - - - - - - - - - - - - - dial setting of the entrance slit - - - - - size of the entrance slit - - - - - energy of the electrons on the mean path of the analyser - - - - - todo: define more clearly - - - - - Angular axis of the analyser data - which dimension the axis applies to is defined - using the normal NXdata methods. - - - - - Energy axis of the analyser data - which dimension the axis applies to is defined - using the normal NXdata methods. - - - - - number of raw active elements in each dimension - - - - - - - - origin of rectangular region selected for readout - - - - - - - - size of rectangular region selected for readout - - - - - - - - - - - Descriptive name of sample - - - - - + + todo: define more clearly + + + + Angular axis of the analyser data + which dimension the axis applies to is defined + using the normal NXdata methods. + + + + + Energy axis of the analyser data + which dimension the axis applies to is defined + using the normal NXdata methods. + + + + number of raw active elements in each dimension + + + + + + origin of rectangular region selected for readout + + + + + + size of rectangular region selected for readout + + + + + + + + + Descriptive name of sample + + - + + + \ No newline at end of file diff --git a/applications/nyaml/NXarpes.yaml b/applications/nyaml/NXarpes.yaml index fe211e13bf..f39a331d30 100644 --- a/applications/nyaml/NXarpes.yaml +++ b/applications/nyaml/NXarpes.yaml @@ -95,13 +95,13 @@ NXarpes(NXobject): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ # e784cdaecf56854c79a01b60711ee9c499ac4c8d12e5d7f72651309e8663baa3 -# -# +# +# # -# -# -# This is an application definition for angular resolved photo electron spectroscopy. -# -# It has been drawn up with hemispherical electron analysers in mind. -# -# This definition is a legacy support for older NXarpes experiments. -# There is, however, a newer definition to collect data & metadata -# for general photoemission experiments, called :ref:NXmpes, -# as well as a specialization for ARPES experiments, called :ref:NXmpes_arpes." -# -# -# -# -# NeXus convention is to use "entry1", "entry2", ... -# for analysis software to locate each entry. -# -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms. -# -# -# -# +# +# +# This is an application definition for angular resolved photo electron spectroscopy. +# +# It has been drawn up with hemispherical electron analysers in mind. +# +# This definition is a legacy support for older NXarpes experiments. +# There is, however, a newer definition to collect data & metadata +# for general photoemission experiments, called :ref:NXmpes, +# as well as a specialization for ARPES experiments, called :ref:NXmpes_arpes." +# +# +# +# +# NeXus convention is to use "entry1", "entry2", ... +# for analysis software to locate each entry. +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# setting for the electron analyser lens +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# dial setting of the entrance slit +# +# +# size of the entrance slit +# +# +# energy of the electrons on the mean path of the analyser # -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# setting for the electron analyser lens -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# dial setting of the entrance slit -# -# -# -# -# size of the entrance slit -# -# -# -# -# energy of the electrons on the mean path of the analyser -# -# -# -# -# todo: define more clearly -# -# -# -# -# Angular axis of the analyser data -# which dimension the axis applies to is defined -# using the normal NXdata methods. -# -# -# -# -# Energy axis of the analyser data -# which dimension the axis applies to is defined -# using the normal NXdata methods. -# -# -# -# -# number of raw active elements in each dimension -# -# -# -# -# -# -# -# origin of rectangular region selected for readout -# -# -# -# -# -# -# -# size of rectangular region selected for readout -# -# -# -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# -# +# +# todo: define more clearly +# +# +# +# Angular axis of the analyser data +# which dimension the axis applies to is defined +# using the normal NXdata methods. +# +# +# +# +# Energy axis of the analyser data +# which dimension the axis applies to is defined +# using the normal NXdata methods. +# +# +# +# number of raw active elements in each dimension +# +# +# +# +# +# origin of rectangular region selected for readout +# +# +# +# +# +# size of rectangular region selected for readout +# +# +# +# +# +# +# +# +# Descriptive name of sample +# +# # -# +# +# +# \ No newline at end of file diff --git a/base_classes/NXaperture.nxdl.xml b/base_classes/NXaperture.nxdl.xml index 40b8a85996..10be4474fc 100644 --- a/base_classes/NXaperture.nxdl.xml +++ b/base_classes/NXaperture.nxdl.xml @@ -1,9 +1,9 @@ - + - - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - The reference point of the aperture is its center in the x and y axis. The reference point on the z axis is the - surface of the aperture pointing towards the source. - - In complex (asymmetric) geometries an NXoff_geometry group can be used to provide an unambiguous reference. - - .. image:: aperture/aperture.png - :width: 40% - + + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference point of the aperture is its center in the x and y axis. The reference point on the z axis is the + surface of the aperture pointing towards the source. + + In complex (asymmetric) geometries an NXoff_geometry group can be used to provide an unambiguous reference. + + .. image:: aperture/aperture.png + :width: 40% + - - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - + + 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. + @@ -71,32 +71,26 @@ - location and shape of aperture - - .. TODO: documentation needs improvement, contributions welcome - - * description of terms is poor and leaves much to interpretation - * Describe what is meant by translation _here_ and ... - * Similar throughout base classes - * Some base classes do this much better - * Such as where is the gap written? + location and shape of aperture + + .. TODO: documentation needs improvement, contributions welcome + + * description of terms is poor and leaves much to interpretation + * Describe what is meant by translation _here_ and ... + * Similar throughout base classes + * Some base classes do this much better + * Such as where is the gap written? + - - location and shape of each blade - + location and shape of each blade - - - - Absorbing material of the aperture - + + Absorbing material of the aperture - - Description of aperture - + Description of aperture @@ -124,15 +118,15 @@ describe any additional information in a note - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. diff --git a/base_classes/NXbeam.nxdl.xml b/base_classes/NXbeam.nxdl.xml index 053dda1fb7..d1dea2e477 100644 --- a/base_classes/NXbeam.nxdl.xml +++ b/base_classes/NXbeam.nxdl.xml @@ -1,5 +1,5 @@ - - + + - + - These symbols coordinate datasets with the same shape. + These symbols coordinate datasets with the same shape. - - Number of scan points. - + Number of scan points. - - Number of channels in the incident beam spectrum, if known - + Number of channels in the incident beam spectrum, if known - - Number of moments representing beam divergence (x, y, xy, etc.) - + Number of moments representing beam divergence (x, y, xy, etc.) - 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. - - - - Distance from sample. Note, it is recommended to use NXtransformations instead. + 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. + + Distance from sample. Note, it is recommended to use NXtransformations instead. - Energy carried by each particle of the beam on entering the beamline component. - - In the case of a monochromatic beam this is the scalar energy. - Several other use cases are permitted, depending on the - presence of other incident_energy_X fields. - - * In the case of a polychromatic beam this is an array of length m of energies, with the relative weights in incident_energy_weights. - * In the case of a monochromatic beam that varies shot-to-shot, this is an array of energies, one for each recorded shot. - Here, incident_energy_weights and incident_energy_spread are not set. - * In the case of a polychromatic beam that varies shot-to-shot, - this is an array of length m with the relative weights in incident_energy_weights as a 2D array. - * In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, - this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_energy_weights as a 2D array. - - Note, variants are a good way to represent several of these use cases in a single dataset, - e.g. if a calibrated, single-value energy value is available along with the original spectrum from which it was calibrated. - + Energy carried by each particle of the beam on entering the beamline component. + + 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. + @@ -105,78 +101,74 @@ - - Energy carried by each particle of the beam on leaving the beamline component - + Energy carried by each particle of the beam on leaving the beamline component - - Change in particle energy caused by the beamline component - + Change in particle energy caused by the 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 <Design-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 <Design-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 polychromatic beam this is an array of - length **m** of the relative weights of the corresponding - wavelengths in ``incident_wavelength``. - - In the case of a polychromatic beam that varies shot-to- - shot, this is a 2D array of dimensions **nP** by **m** - (slow to fast) of the relative weights of the - corresponding wavelengths in ``incident_wavelength``. + In the case of a polychromatic beam this is an array of + length **m** of the relative weights of the corresponding + wavelengths in ``incident_wavelength``. + + In the case of a polychromatic beam that varies shot-to- + shot, this is a 2D array of dimensions **nP** by **m** + (slow to fast) of the relative weights of the + corresponding wavelengths in ``incident_wavelength``. - The wavelength spread FWHM for the corresponding - wavelength(s) in incident_wavelength. - - In the case of shot-to-shot variation in the wavelength - spread, this is a 2D array of dimension **nP** by - **m** (slow to fast) of the spreads of the - corresponding wavelengths in incident_wavelength. + The wavelength spread FWHM for the corresponding + wavelength(s) in incident_wavelength. + + In the case of shot-to-shot variation in the wavelength + spread, this is a 2D array of dimension **nP** by + **m** (slow to fast) of the spreads of the + corresponding wavelengths in incident_wavelength. @@ -184,15 +176,15 @@ - Beam crossfire in degrees parallel to the laboratory X axis - - The dimension **c** is a series of moments of that represent - the standard uncertainty (e.s.d.) of the directions of - of the beam. The first and second moments are in the XZ and YZ - planes around the mean source beam direction, respectively. - - Further moments in **c** characterize co-variance terms, so - the next moment is the product of the first two, and so on. + Beam crossfire in degrees parallel to the laboratory X axis + + The dimension **c** is a series of moments of that represent + the standard uncertainty (e.s.d.) of the directions of + of the beam. The first and second moments are in the XZ and YZ + planes around the mean source beam direction, respectively. + + Further moments in **c** characterize co-variance terms, so + the next moment is the product of the first two, and so on. @@ -201,10 +193,10 @@ - Size of the beam entering this component. Note this represents - a rectangular beam aperture, and values represent FWHM. - If applicable, the first dimension shall be the horizontal extent - and the second dimension shall be the vertical extent. + Size of the beam entering this component. Note this represents + a rectangular beam aperture, and values represent FWHM. + If applicable, the first dimension shall be the horizontal extent + and the second dimension shall be the vertical extent. @@ -212,17 +204,13 @@ - - Wavelength on leaving beamline component - + Wavelength on leaving beamline component - - Polarization vector on entering beamline component - + Polarization vector on entering beamline component @@ -247,9 +235,7 @@ - - Polarization vector on leaving beamline component - + Polarization vector on leaving beamline component @@ -276,25 +262,25 @@ Polarization vector on entering beamline component using Stokes notation - + The Stokes parameters are four components labelled I,Q,U,V or S_0,S_1,S_2,S_3. These are defined with the standard Nexus coordinate frame unless it is overridden by an NXtransformations field pointed to by a depends_on attribute. The last component, describing the circular polarization state, is positive for a right-hand circular state - that is the electric field vector rotates clockwise at the sample and over time when observed from the source. - - I (S_0) is the beam intensity (often normalized to 1). Q, U, and V scale + + I (S_0) is the beam intensity (often normalized to 1). Q, U, and V scale linearly with the total degree of polarization, and indicate the relative magnitudes of the pure linear and circular orientation contributions. Q (S_1) is linearly polarized along the x axis (Q > 0) or y axis (Q < 0). U (S_2) is linearly polarized along the x==y axis (U > 0) or the - -x==y axis (U < 0). - + -x==y axis (U < 0). + V (S_3) is circularly polarized. V > 0 when the electric field vector rotates - clockwise at the sample with respect to time when observed from the source; + clockwise at the sample with respect to time when observed from the source; V < 0 indicates the opposite rotation. @@ -313,26 +299,20 @@ - - Wavelength spread FWHM of beam leaving this component - + Wavelength spread FWHM of beam leaving this component - - Divergence FWHM of beam leaving this component - + Divergence FWHM of beam leaving this component - - flux incident on beam plane area - + flux incident on beam plane area @@ -407,106 +387,107 @@ Group delay dispersion of the pulse for linear chirp - + + + Indicates the beam device from which this beam originates. + This defines, whether the beam in an "input" or "output" beam. + + + - Distribution of beam with respect to relevant variable e.g. wavelength. This is mainly - useful for simulations which need to store plottable information at each beamline - component. + Gives the beam device which this beam will interact with next. + + + + Distribution of beam with respect to relevant variable e.g. wavelength. This is mainly + useful for simulations which need to store plottable information at each beamline + component. - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. - + + - The NeXus coordinate system defines the Z axis to be along the nominal beam - direction. This is the same as the McStas coordinate system (see :ref:`Design-CoordinateSystem`). - However, the additional transformations needed to represent an altered beam - direction can be provided using this depends_on field that contains the path - to a NXtransformations group. This could represent redirection of the beam, - or a refined beam direction. + The NeXus coordinate system defines the Z axis to be along the nominal beam + direction. This is the same as the McStas coordinate system (see :ref:`Design-CoordinateSystem`). + However, the additional transformations needed to represent an altered beam + direction can be provided using this depends_on field that contains the path + to a NXtransformations group. This could represent redirection of the beam, + or a refined beam direction. + - Direction (and location) for the beam. The location of the beam can be given by - any point which it passes through as its offset attribute. + Direction (and location) for the beam. The location of the beam can be given by + any point which it passes through as its offset attribute. - + - Direction of beam vector, its value is ignored. If missing, then the beam direction is defined as [0,0,1] - and passes through the origin + Direction of beam vector, its value is ignored. If missing, then the beam direction is defined as [0,0,1] + and passes through the origin - + - Three values that define the direction of beam vector + Three values that define the direction of beam vector - Three values that define the location of a point through which the beam passes + Three values that define the location of a point through which the beam passes - Points to the path to a field defining the location on which this - depends or the string "." for origin. + Points to the path to a field defining the location on which this + depends or the string "." for origin. - + - Direction of normal to reference plane used to measure azimuth relative to the beam, its value is ignored. - This also defines the parallel and perpendicular components of the beam's polarization. - If missing, then the reference plane normal is defined as [0,1,0] and passes through the origin + Direction of normal to reference plane used to measure azimuth relative to the beam, its value is ignored. + This also defines the parallel and perpendicular components of the beam's polarization. + If missing, then the reference plane normal is defined as [0,1,0] and passes through the origin - + - Three values that define the direction of reference plane normal + Three values that define the direction of reference plane normal - Not required as beam direction offset locates the plane + Not required as beam direction offset locates the plane - Points to the path to a field defining the location on which this - depends or the string "." for origin. + Points to the path to a field defining the location on which this + depends or the string "." for origin. - - - Indicates the beam device from which this beam originates. - This defines, whether the beam in an "input" or "output" beam. - - - - - Gives the beam device which this beam will interact with next. - - diff --git a/base_classes/NXdata.nxdl.xml b/base_classes/NXdata.nxdl.xml index 9949f70344..8b445f1e21 100644 --- a/base_classes/NXdata.nxdl.xml +++ b/base_classes/NXdata.nxdl.xml @@ -1,5 +1,5 @@ - - + + - - - - - These symbols will be used below to coordinate fields with the same - shape. - - - - rank of the ``DATA`` field - - - - - length of the ``AXISNAME`` field - - - - - length of the ``x`` field - - - - - length of the ``y`` field - - - - - length of the ``z`` field - - - - - :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) - - - - .. index:: plotting - - Array of strings holding the :ref:`names <validItemName>` of additional - signals to be plotted with the default :ref:`signal </NXdata@signal-attribute>`. - These fields or links *must* exist and be direct children of this NXdata group. - - Each auxiliary signal needs to be of the same shape as the default signal. - - .. NIAC2018: - https://www.nexusformat.org/NIAC2018Minutes.html - - - - - .. 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 <validItemName>` 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. - - - - - .. index:: plotting - - Array of strings holding the :ref:`names <validItemName>` of - the independent data fields used in the default plot for all of - the dimensions of the :ref:`signal </NXdata@signal-attribute>` - as well as any :ref:`auxiliary signals </NXdata@auxiliary_signals-attribute>`. - - 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. - - + + + + + + These symbols will be used below to coordinate fields with the same shape. + rank of the ``DATA`` field(s) + length of the ``x`` field + length of the ``y`` field + length of the ``z`` field + + + + The :ref:`NXdata` class is designed to encapsulate all the information required for a set of data to be plotted. + NXdata groups contain plottable data (sometimes referred to as *signals* or *dependent variables*) and their + associated axis coordinates (sometimes referred to as *axes* or *independent variables*). + + The actual names of the :ref:`DATA </NXdata/DATA-field>` and :ref:`AXISNAME </NXdata/AXISNAME-field>` fields + can be chosen :ref:`freely <validItemName>`, as indicated by the upper case (this is a common convention in all NeXus classes). + + .. note:: ``NXdata`` provides data and coordinates to be plotted but + does not describe how the data is to be plotted or even the dimensionality of the plot. + https://www.nexusformat.org/NIAC2018Minutes.html#nxdata-plottype--attribute + + **Signals:** + + .. index:: plotting + + The :ref:`DATA </NXdata/DATA-field>` fields contain the signal values to be plotted. The name of the field + to be used as the *default plot signal* is provided by the :ref:`signal </NXdata@signal-attribute>` attribute. + The names of the fields to be used as *secondary plot signals* are provided by the + :ref:`auxiliary_signals</NXdata@auxiliary_signals-attribute>` attribute. + + An example with three signals, one of which being the default + + .. code-block:: + + data:NXdata + @signal = "data1" + @auxiliary_signals = ["data2", "data3"] + data1: float[10,20,30] --> the default signal + data2: float[10,20,30] + data3: float[10,20,30] + + **Axes:** + + .. index:: axes (attribute) + .. index:: coordinates + + The :ref:`AXISNAME </NXdata/AXISNAME-field>` fields contain the axis coordinates associated with the data values. + The names of all :ref:`AXISNAME </NXdata/AXISNAME-field>` fields are listed in the + :ref:`axes </NXdata@axes-attribute>` attribute. + + `Rank` + + :ref:`AXISNAME </NXdata/AXISNAME-field>` fields are typically one-dimensional arrays, which annotate one of the dimensions. + + An example of this would be + + .. code-block:: + + data:NXdata + @signal = "data" + @axes = ["x", "y"] --> the order matters + data: float[10,20] + x: float[10] --> coordinates along the first dimension + y: float[20] --> coordinates along the second dimension + + In this example each data point ``data[i,j]`` has axis coordinates ``[x[i], y[j]]``. + + However, the fields can also have a rank greater than 1, in which case the rank of each + :ref:`AXISNAME </NXdata/AXISNAME-field>` must be equal to the number of data dimensions it spans. + + An example of this would be + + .. code-block:: + + data:NXdata + @signal = "data" + @axes = ["x", "y"] --> the order does NOT matter + @x_indices = [0, 1] + @y_indices = [0, 1] + data: float[10,20] + x: float[10,20] --> coordinates along both dimensions + y: float[10,20] --> coordinates along both dimensions + + In this example each data point ``data[i,j]`` has axis coordinates ``[x[i,j], y[i,j]]``. + + `Dimensions` + + The data dimensions annotated by an :ref:`AXISNAME </NXdata/AXISNAME-field>` field are defined by the + :ref:`AXISNAME_indices </NXdata@AXISNAME_indices-attribute>` attribute. When this attribute is missing, + the position(s) of the :ref:`AXISNAME </NXdata/AXISNAME-field>` string in the + :ref:`axes </NXdata@axes-attribute>` attribute are used. + + When all :ref:`AXISNAME </NXdata/AXISNAME-field>` fields are one-dimensional, and none of the data dimensions + have more than one axis, the :ref:`AXISNAME_indices </NXdata@AXISNAME_indices-attribute>` attributes + are often omitted. If one of the data dimensions has no :ref:`AXISNAME </NXdata/AXISNAME-field>` field, + the string “.” can be used in the corresponding index of the axes list. + + An example of this would be + + .. code-block:: + + data:NXdata + @signal = "data" + @axes = ["x", ".", "z"] --> the order matters + data: float[10,20,30] + x: float[10] --> coordinates along the first dimension + z: float[30] --> coordinates along the third dimension + + When using :ref:`AXISNAME_indices </NXdata@AXISNAME_indices-attribute>` this becomes + + .. code-block:: + + data:NXdata + @signal = "data" + @axes = ["x", "z"] --> the order does NOT matter + data: float[10,20,30] + @x_indices = 0 + @z_indices = 2 + x: float[10] --> coordinates along the first dimension + z: float[30] --> coordinates along the third dimension + + When providing :ref:`AXISNAME_indices </NXdata@AXISNAME_indices-attribute>` attributes it is recommended + to do it for all axes. + + `Non-trivial axes` + + What follows are two examples where :ref:`AXISNAME_indices </NXdata@AXISNAME_indices-attribute>` attributes + cannot be omitted. + + The first is an example where data dimensions have alternative axis coordinates. The NXdata group represents + a stack of images collected at different energies. The ``wavelength`` is an alternative axis of ``energy`` + for the last dimension (or vice versa). + + .. code-block:: + + data:NXdata + @signal = "data" + @axes = ["x", "y", "energy", "wavelength"] --> the order does NOT matter + @x_indices = 0 + @y_indices = 1 + @energy_indices = 2 + @wavelength_indices = 2 + data: float[10,20,30] + x: float[10] --> coordinates along the first dimension + y: float[20] --> coordinates along the second dimension + energy: float[30] --> coordinates along the third dimension + wavelength: float[30] --> coordinates along the third dimension + + The second is an example with coordinates that span more than one dimension. The NXdata group represents data + from 2D mesh scans performed at multiple energies. Each data point ``data[i,j,k]`` has axis coordinates + ``[x[i,j,k], y[i,j,k], energy[k]]``. + + .. code-block:: + + data:NXdata + @signal = "data" + @axes = ["x", "y", "energy"] --> the order does NOT matter + @x_indices = [0, 1, 2] + @y_indices = [0, 1, 2] + @energy_indices = 2 + data: float[10,20,30] + x: float[10,20,30] --> coordinates along all dimensions + y: float[10,20,30] --> coordinates along all dimensions + energy: float[30] --> coordinates along the third dimension + + **Uncertainties:** + + Standard deviations on data values as well as coordinates can be provided by + :ref:`FIELDNAME_errors </NXdata/FIELDNAME_errors-field>` fields where ``FIELDNAME`` is the name of a + :ref:`DATA </NXdata/DATA-field>` field or an :ref:`AXISNAME </NXdata/AXISNAME-field>` field. + + An example of uncertainties on the signal, auxiliary signals and axis coordinates + + .. code-block:: + + data:NXdata + @signal = "data1" + @auxiliary_signals = ["data2", "data3"] + @axes = ["x", "z"] + @x_indices = 0 + @z_indices = 2 + data1: float[10,20,30] + data2: float[10,20,30] + data3: float[10,20,30] + x: float[10] + z: float[30] + data1_errors: float[10,20,30] + data2_errors: float[10,20,30] + data3_errors: float[10,20,30] + x_errors: float[10] + z_errors: float[30] + + + + + + + .. index:: find the default plottable data + .. index:: plotting + .. index:: signal attribute value + + The value is the :ref:`name <validItemName>` of the signal that contains + the default plottable data. 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. + + + + + .. index:: plotting + + Array of strings holding the :ref:`names <validItemName>` of additional + signals to be plotted with the :ref:`default signal </NXdata@signal-attribute>`. + These fields or links *must* exist and be direct children of this NXdata group. + + Each auxiliary signal needs to be of the same shape as the default signal. + + .. NIAC2018: + https://www.nexusformat.org/NIAC2018Minutes.html + + + + + Which slice of data to show in a plot by default. This is useful especially for + datasets with more than 2 dimensions. + + Should be an array of length equal to the number of dimensions + in the data, with the following possible values: + + * ".": All the data in this dimension should be included + * Integer: Only this slice should be used. + * String: Only this slice should be used. Use if ``AXISNAME`` is a string + array. + + Example:: + + data:NXdata + @signal = "data" + @axes = ["image_id", "channel", ".", "."] + @image_id_indices = 0 + @channel_indices = 1 + @default_slice = [".", "difference", ".", "."] + image_id = [1, ..., nP] + channel = ["threshold_1", "threshold_2", "difference"] + data = uint[nP, nC, i, j] + + Here, a data array with four dimensions, including the number of images + (nP) and number of channels (nC), specifies more dimensions than can be + visualized with a 2D image viewer for a given image. Therefore the + default_slice attribute specifies that the "difference" channel should be + shown by default. + + Alternate version using an integer would look like this (note 2 is a string):: + + data:NXdata + @signal = "data" + @axes = ["image_id", "channel", ".", "."] + @image_id_indices = 0 + @channel_indices = 1 + @default_slice = [".", "2", ".", "."] + image_id = [1, ..., nP] + channel = ["threshold_1", "threshold_2", "difference"] + data = uint[nP, nC, i, j] + + + Points to the path of a field defining the data to which the `DATA` group refers. - + This concept allows to link the data to a respective field in the NeXus hierarchy, thereby defining the physical quantity it represents. - + Example: If the data corresponds to a readout of a detector, ``@reference`` links to that detectors data: - + @reference: '/entry/instrument/detector/data' for a 2D detector - - - - - Each ``AXISNAME_indices`` attribute indicates the dependency - relationship of the ``AXISNAME`` field (where ``AXISNAME`` - is the name of a field that exists in this ``NXdata`` group) - with one or more dimensions of the plottable data. - - Integer array that defines the indices of the *signal* field - (that field will be a multidimensional array) - which need to be used in the *AXISNAME* field in - order to reference the corresponding axis value. - - The first index of an array is ``0`` (zero). - - Here, *AXISNAME* is to be replaced by the name of each - field described in the ``axes`` attribute. - An example with 2-D data, :math:`d(t,P)`, will illustrate:: - - data_2d:NXdata - @signal="data" - @axes=["time", "pressure"] - @time_indices=0 - @pressure_indices=1 - data: float[1000,20] - time: float[1000] - pressure: float[20] - - This attribute is to be provided in all situations. - However, if the indices attributes are missing - (such as for data files written before this specification), - file readers are encouraged to make their best efforts - to plot the data. - Thus the implementation of the - ``AXISNAME_indices`` attribute is based on the model of - "strict writer, liberal reader". - - .. note:: Attributes potentially containing multiple values - (axes and _indices) are to be written as string or integer arrays, - to avoid string parsing in reading applications. - - - - - 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. - - - - A *dimension scale* must have a rank of 1 and has length ``n``. - - - - - - Axis label - - - - - ``0|false``: single value, - ``1|true``: multiple values - - - - - Index of first good value - - - - - Index of last good value - - - - - Index (positive integer) identifying this specific set of numbers. - - N.B. The ``axis`` attribute is the old way of designating a link. - Do not use the ``axes`` attribute with the ``axis`` attribute. - The ``axes`` *group* attribute is now preferred. - - + + + + + The ``AXISNAME_indices`` attribute is a single integer or an array of integers that defines which :ref:`data </NXdata/DATA-field>` + dimension(s) are spanned by the corresponding axis. The first dimension index is ``0`` (zero). + + When the ``AXISNAME_indices`` attribute is missing for an :ref:`AXISNAME </NXdata/AXISNAME-field>` field, its value becomes the index + (or indices) of the :ref:`AXISNAME </NXdata/AXISNAME-field>` name in the :ref:`axes </NXdata@axes-attribute>` attribute. + + .. note:: When ``AXISNAME_indices`` contains multiple integers, it must be saved as an actual array + of integers and not a comma separated string. + + + + + .. index:: plotting + + The ``axes`` attribute is a list of strings which are the names of the :ref:`AXISNAME </NXdata/AXISNAME-field>` fields + that contain the values of the coordinates along the :ref:`data </NXdata/DATA-field>` dimensions. + + .. note:: When ``axes`` contains multiple strings, it must be saved as an actual array + of strings and not a single comma separated string. + + + + + + + Coordinate values along one or more :ref:`data </NXdata/DATA-field>` dimensions. The rank must be equal + to the number of dimensions it spans. + + As the upper case ``AXISNAME`` indicates, the names of the ``AXISNAME`` fields can be chosen :ref:`freely <validItemName>`. + The :ref:`axes </NXdata@axes-attribute>` attribute can be used to find all datasets in the + ``NXdata`` that contain coordinate values. + + Most AXISNAME fields will be sequences of numbers but if an axis is better represented using names, such as channel names, + an array of NX_CHAR can be provided. + + Axis label + + + Unit in which the coordinate values are expressed. + See the section :ref:`Design-Units` for more information. + + + + + ``0|false``: single value, + ``1|true``: multiple values + + + Index of first good value + Index of last good value + + + Index (positive integer) identifying this specific set of numbers. + + N.B. The ``axis`` attribute is the old way of designating a link. + Do not use the :ref:`axes </NXdata@axes-attribute>` attribute with the ``axis`` attribute. + The :ref:`axes </NXdata@axes-attribute>` attribute is now preferred. + + - Points to the path of a field defining the axis to which the ``AXISNAME`` axis refers. - - This concept allows to link an axis to a respective field in the NeXus hierarchy, thereby - defining the physical quantity it represents. - - Examples: - If a calibration has been performed, ``@reference`` links to the result of - that calibration: - - @reference: '/entry/process/calibration/calibrated_axis' - - If the axis corresponds to a coordinate of a detector, ``@reference`` links - to that detector axis: - - @reference: '/entry/instrument/detector/axis/some_axis' for a 2D detector - - If the axis is a scanned motor, ``@reference`` links to the transformation - describing the respective motion, e.g.: - - @reference: '/entry/instrument/detector/transformations/some_transformation' for a motion of the detector - - - - - - "Errors" (meaning *uncertainties* or *standard deviations*) - associated with any field named ``FIELDNAME`` in this ``NXdata`` - group (e.g. an axis, signal or auxiliary signal). - - The dimensions of the ``FIELDNAME_errors`` field must match - the dimensions of the ``FIELDNAME`` field. - - - - - .. 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. - - - - The rank (``dataRank``) of the ``data`` must satisfy - ``1 <= dataRank <= NX_MAXRANK=32``. - At least one ``dim`` must have length ``n``. - - - - - .. index:: plotting - - Plottable (independent) axis, indicate index number. - Only one field in a :ref:`NXdata` group may have the - ``signal=1`` attribute. - Do not use the ``signal`` attribute with the ``axis`` attribute. - - - - - Defines the names of the dimension scales - (independent axes) for this data set - as a colon-delimited array. - NOTE: The ``axes`` attribute is the preferred - method of designating a link. - Do not use the ``axes`` attribute with the ``axis`` attribute. - - - - - data label + Points to the path of a field defining the axis to which the ``AXISNAME`` axis refers. + + This concept allows to link an axis to a respective field in the NeXus hierarchy, thereby + defining the physical quantity it represents. + + Examples: + If a calibration has been performed, ``@reference`` links to the result of + that calibration: + + @reference: '/entry/process/calibration/calibrated_axis' + + If the axis corresponds to a coordinate of a detector, ``@reference`` links + to that detector axis: + + @reference: '/entry/instrument/detector/axis/some_axis' for a 2D detector + + If the axis is a scanned motor, ``@reference`` links to the transformation + describing the respective motion, e.g.: + + @reference: '/entry/instrument/detector/transformations/some_transformation' for a motion of the detector + + + + .. index:: plotting + + Data values to be used as the NeXus *plottable data*. As the upper case ``DATA`` + indicates, the names of the ``DATA`` fields can be chosen :ref:`freely <validItemName>`. The :ref:`signal attribute </NXdata@signal-attribute>` + and :ref:`auxiliary_signals attribute</NXdata@auxiliary_signals-attribute>` can be used to find all datasets in the ``NXdata`` + that contain data values. + + The maximum rank is ``32`` for compatibility with backend file formats. + + + + The rank (``dataRank``) of the ``data`` must satisfy + ``1 <= dataRank <= NX_MAXRANK=32``. + + + + + .. index:: plotting + + Plottable (independent) axis, indicate index number. + Only one field in a :ref:`NXdata` group may have the + ``signal=1`` attribute. + Do not use the ``signal`` attribute with the ``axis`` attribute. + + + + + Defines the names of the coordinates + (independent axes) for this data set + as a colon-delimited array. + NOTE: The :ref:`axes </NXdata@axes-attribute>` attribute is the preferred + method of designating a link. + Do not use the :ref:`axes </NXdata@axes-attribute>` attribute with the ``axis`` attribute. + + + + data label + - Points to the path of a field defining the data to which the `DATA` field refers. - - This concept allows to link the data to a respective field in the NeXus hierarchy, thereby - defining the physical quantity it represents. - - Here, *DATA* is to be replaced by the name of each - data field. - - Example: - If the data corresponds to a readout of a detector, ``@reference`` links - to that detectors data: - - @reference: '/entry/instrument/detector/data' for a 2D detector + Points to the path of a field defining the data to which the `DATA` field refers. + + This concept allows to link the data to a respective field in the NeXus hierarchy, thereby + defining the physical quantity it represents. + + Here, *DATA* is to be replaced by the name of each + data field. + + Example: + If the data corresponds to a readout of a detector, ``@reference`` links + to that detectors data: + + @reference: '/entry/instrument/detector/data' for a 2D detector - - - - Standard deviations of data values - - the data array is identified by the group attribute ``signal``. - The ``errors`` array must have the same dimensions as ``DATA``. - Client is responsible for defining the dimensions of the data. - - - - The ``errors`` must have - the same rank (``dataRank``) - as the ``data``. - At least one ``dim`` must have length "n". - - - - - - The elements in data are usually float values really. For - efficiency reasons these are usually stored as integers - after scaling with a scale factor. This value is the scale - factor. It is required to get the actual physical value, - when necessary. - - - - - An optional offset to apply to the values in data. - - - - - Title for the plot. - - - - - This is an array holding the values to use for the x-axis of - data. The units must be appropriate for the measurement. - - - - - - - - This is an array holding the values to use for the y-axis of - data. The units must be appropriate for the measurement. - - - - - - - - This is an array holding the values to use for the z-axis of - data. The units must be appropriate for the measurement. - - - - - + + + + "Errors" (meaning *uncertainties* or *standard deviations*) + associated with any field named ``FIELDNAME`` in this ``NXdata`` + group (e.g. an axis, signal or auxiliary signal). + + The dimensions of the ``FIELDNAME_errors`` field must match + the dimensions of the ``FIELDNAME`` field. + + + + + Standard deviations of data values - + the data array is identified by the group attribute ``signal``. + The ``errors`` array must have the same dimensions as ``DATA``. + Client is responsible for defining the dimensions of the data. + + + + The ``errors`` must have the same rank (``dataRank``) + as the ``data``. + + + + + + + + An optional scaling factor to apply to the values in any field named ``FIELDNAME`` + in this ``NXdata`` group. This can be a :ref:`DATA </NXdata/DATA-field>` field + (signal or auxiliary signal) or a :ref:`AXISNAME </NXdata/AXISNAME-field>` + field (axis). + + The elements stored in NXdata datasets are often stored as integers for efficiency + reasons and need further correction or conversion, generating floats. For example, + raw values could be stored from a device that need to be converted to values that + represent the physical values. The two fields FIELDNAME_scaling_factor and + FIELDNAME_offset allow linear corrections using the following convention: + + .. code-block:: + + corrected values = (FIELDNAME + offset) * scaling_factor + + This formula will derive the values to use in downstream applications, when necessary. + + When omitted, the scaling factor is assumed to be 1. + + + + + An optional offset to apply to the values in FIELDNAME (usually the signal). + + When omitted, the offset is assumed to be 0. + + See :ref:`FIELDNAME_scaling_factor </NXdata/FIELDNAME_scaling_factor-field>` for more information. + + + + + + The scaling_factor and FIELDNAME_scaling_factor fields have similar semantics. + However, scaling_factor is ambiguous in the case of multiple signals. Therefore + scaling_factor is deprecated. Use FIELDNAME_scaling_factor instead, even when + only a single signal is present. + + + + + The offset and FIELDNAME_offset fields have similar semantics. + However, offset is ambiguous in the case of multiple signals. Therefore + offset is deprecated. Use FIELDNAME_offset instead, even when + only a single signal is present. + + + + + + + + Title for the plot. + + + + + + + This is an array holding the values to use for the x-axis of + data. The units must be appropriate for the measurement. + + This is a special case of a :ref:`AXISNAME field </NXdata/AXISNAME-field>` + kept for backward compatiblity. + + + + + + + + This is an array holding the values to use for the y-axis of + data. The units must be appropriate for the measurement. + + This is a special case of a :ref:`AXISNAME field </NXdata/AXISNAME-field>` + kept for backward compatiblity. + + + + + + + + This is an array holding the values to use for the z-axis of + data. The units must be appropriate for the measurement. + + This is a special case of a :ref:`AXISNAME field </NXdata/AXISNAME-field>` + kept for backward compatiblity. + + + + + diff --git a/base_classes/NXdetector.nxdl.xml b/base_classes/NXdetector.nxdl.xml index c725ce2685..101ee1699e 100644 --- a/base_classes/NXdetector.nxdl.xml +++ b/base_classes/NXdetector.nxdl.xml @@ -1,5 +1,5 @@ - - + + - - - - These symbols will be used below to illustrate the coordination of the - rank and sizes of datasets and the preferred ordering of the - dimensions. Each of these are optional (so the rank of the datasets - will vary according to the situation) and the general ordering - principle is slowest to fastest. The type of each dimension should - follow the order of scan points, detector output (e.g. pixels), then - time-of-flight (i.e. spectroscopy, spectrometry). Note that the output - of a detector is not limited to single values (0D), lists (1D) and - images (2), but three or higher dimensional arrays can be produced by - a detector at each trigger. - - - - number of scan points (only present in scanning measurements) - - - - - number of detector pixels in the first (slowest) direction - - - - - number of detector pixels in the second (faster) direction - - - - - number of detector pixels in the third (if necessary, fastest) - direction - - - - - number of bins in the time-of-flight histogram - - - - - A detector, detector bank, or multidetector. - - - - Total time of flight - - - - - - - - - - - - - - - - - Total time of flight - - - - - - In DAQ clock pulses - - - - - - - Clock frequency in Hz - - - - - - Identifier for detector (pixels) - Can be multidimensional, if needed - - - - - 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. - - - - - - - - - - Title of measurement - - - - - Integral of data as check of data integrity - - - - - - The best estimate of the uncertainty in the data value (array size should match the data field). Where - possible, this should be the standard deviation, which has the same units - as the data. The form data_error is deprecated. - - - - - - - - - - - Offset from the detector center in x-direction. - Can be multidimensional when needed. - - - - - - - - - - - - - - - - - - x-axis offset from detector center - - - - - - Offset from the detector center in the y-direction. - Can be multidimensional when different values are required for each pixel. - - - - - - - - - - - - - - - - - - y-axis offset from detector center - - - - - - Offset from the detector center in the z-direction. - Can be multidimensional when different values are required for each pixel. - - - - - - - - - - - - - - - - - - y-axis offset from detector center - - - - - - This is the distance to the previous component in the - instrument; most often the sample. The usage depends on the - nature of the detector: Most often it is the distance of the - detector assembly. But there are irregular detectors. In this - case the distance must be specified for each detector pixel. - - Note, it is recommended to use NXtransformations instead. - - - - - - - - - - This is the polar angle of the detector towards the previous - component in the instrument; most often the sample. - The usage depends on the - nature of the detector. - Most often it is the polar_angle of the detector assembly. - But there are irregular detectors. - In this - case, the polar_angle must be specified for each detector pixel. - - Note, it is recommended to use NXtransformations instead. - - - - - - - - - - This is the azimuthal angle angle of the detector towards - the previous component in the instrument; most often the sample. - The usage depends on the - nature of the detector. - Most often it is the azimuthal_angle of the detector assembly. - But there are irregular detectors. - In this - case, the azimuthal_angle must be specified for each detector pixel. - - Note, it is recommended to use NXtransformations instead. - - - - - - - - - - name/manufacturer/model/etc. information - - - - - Serial number for the detector - - - - - Local name for the detector - - - - - Position and orientation of detector - - - - - Solid angle subtended by the detector at the sample - - - - - - - - - Size of each detector pixel. If it is scalar all pixels are the same size. - - - - - - - - - Size of each detector pixel. If it is scalar all pixels are the same size - - - - - - - - - Detector dead time - - - - - - - - - - Detector gas pressure - - - - - - - - - maximum drift space dimension - - - - - Crate number of detector - - - - - - - - Equivalent local term - - - - - - Slot number of detector - - - - - - - - Equivalent local term - - - - - - Input number of detector - - - - - - - - Equivalent local term - - - - - - Description of type such as He3 gas cylinder, He3 PSD, scintillator, - fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, - CMOS, ... - - - - - Spectral efficiency of detector with respect to e.g. wavelength - - - - - - - - - - - - - - - - - - - - - - - - - efficiency of the detector - - - - - - - - - - This field can be two things: - - 1. For a pixel detector it provides the nominal wavelength - for which the detector has been calibrated. - - 2. For other detectors this field has to be seen together with - the efficiency field above. - For some detectors, the efficiency is wavelength dependent. - Thus this field provides the wavelength axis for the efficiency field. - In this use case, the efficiency and wavelength arrays must - have the same dimensionality. - - - - - - - - - - - Real-time of the exposure (use this if exposure time varies for - each array element, otherwise use ``count_time`` field). - - Most often there is a single real time value that is constant across - an entire image frame. In such cases, only a 1-D array is needed. - But there are detectors in which the real time - changes per pixel. In that case, more than one dimension is needed. Therefore - the rank of this field should be less than or equal to (detector rank + 1). - - - - - - - - - - start time for each frame, with the ``start`` attribute as absolute reference - - - - - - - - - stop time for each frame, with the ``start`` attribute as absolute reference - - - - - - - - - date of last calibration (geometry and/or efficiency) measurements - - - - - summary of conversion of array data to pixels (e.g. polynomial - approximations) and location of details of the calibrations - - - - - How the detector is represented - - - - - - - - - - Elapsed actual counting time - - - - - - - - - Use this group to provide other data related to this NXdetector group. - + + + + + These symbols will be used below to illustrate the coordination of the rank and sizes of datasets and the + preferred ordering of the dimensions. Each of these are optional (so the rank of the datasets + will vary according to the situation) and the general ordering principle is slowest to fastest. + The type of each dimension should follow the order of scan points, detector output (e.g. pixels), + then time-of-flight (i.e. spectroscopy, spectrometry). Note that the output of a detector is not limited + to single values (0D), lists (1D) and images (2), but three or higher dimensional arrays can be produced + by a detector at each trigger. + + + number of scan points (only present in scanning measurements) + number of detector pixels in the first (slowest) direction + number of detector pixels in the second (faster) direction + number of detector pixels in the third (if necessary, fastest) direction + number of bins in the time-of-flight histogram + + + + A detector, detector bank, or multidetector. + + + + Total time of flight + + + + + + + + + + + + + + + + + + + Total time of flight + + + + + In DAQ clock pulses + + + + + + + Clock frequency in Hz + + + + + + Identifier for detector (pixels) + Can be multidimensional, if needed + + + + + + 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. + + + + + + + + + + + Title of measurement + + + + Integral of data as check of data integrity + + + + + + + The best estimate of the uncertainty in the data value (array size should match the data field). Where + possible, this should be the standard deviation, which has the same units + as the data. The form data_error is deprecated. + + + + + + + + + + + + + + Offset from the detector center in x-direction. + Can be multidimensional when needed. + + + + + + + + + + + + + + + + + + + + + x-axis offset from detector center + + + + + + Offset from the detector center in the y-direction. + Can be multidimensional when different values are required for each pixel. + + + + + + + + + + + + + + + + + + + + + y-axis offset from detector center + + + + + + + Offset from the detector center in the z-direction. + Can be multidimensional when different values are required for each pixel. + + + + + + + + + + + + + + + + + + + + + y-axis offset from detector center + + + + + + This is the distance to the previous component in the + instrument; most often the sample. The usage depends on the + nature of the detector: Most often it is the distance of the + detector assembly. But there are irregular detectors. In this + case the distance must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. + + + + + + + + + + + + This is the polar angle of the detector towards the previous + component in the instrument; most often the sample. + The usage depends on the + nature of the detector. + Most often it is the polar_angle of the detector assembly. + But there are irregular detectors. + In this + case, the polar_angle must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. + + + + + + + + + + + + This is the azimuthal angle angle of the detector towards + the previous component in the instrument; most often the sample. + The usage depends on the + nature of the detector. + Most often it is the azimuthal_angle of the detector assembly. + But there are irregular detectors. + In this + case, the azimuthal_angle must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. + + + + + + + + + + + name/manufacturer/model/etc. information + + + + Serial number for the detector + + + + Local name for the detector + + + + Position and orientation of detector + + + + Solid angle subtended by the detector at the sample + + + + + + + + + + Size of each detector pixel. If it is scalar all pixels are the same size. + + + + + + + + + + Size of each detector pixel. If it is scalar all pixels are the same size + + + + + + + + + Detector dead time + + + + + + + + + + Detector gas pressure + + + + + + + + + maximum drift space dimension + + + + Crate number of detector + + + + + + + + Equivalent local term + + + + + Slot number of detector + + + + + + + + Equivalent local term + + + + + Input number of detector + + + + + + + + Equivalent local term + + + + + + Description of type such as He3 gas cylinder, He3 PSD, scintillator, + fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, + CMOS, ... + + + + + + Group containing the description and metadata for a single channel from a multi-channel + detector. + + Given an :ref:`NXdata` group linked as part of an NXdetector group that has an axis with + named channels (see the example in :ref:`NXdata </NXdata@default_slice-attribute>`), + the NXdetector will have a series of NXdetector_channel groups, one for each channel, + named CHANNELNAME_channel. + + + + + Spectral efficiency of detector with respect to e.g. wavelength + + + + + + + + + + + + + + + + + + + + + + + + efficiency of the detector + + + + + + + + + + + This field can be two things: + + #. For a pixel detector it provides the nominal wavelength + for which the detector has been calibrated. + + #. For other detectors this field has to be seen together with + the efficiency field above. + For some detectors, the efficiency is wavelength dependent. + Thus this field provides the wavelength axis for the efficiency field. + In this use case, the efficiency and wavelength arrays must + have the same dimensionality. + + + + + + + + + + + + Real-time of the exposure (use this if exposure time varies for + each array element, otherwise use ``count_time`` field). + + Most often there is a single real time value that is constant across + an entire image frame. In such cases, only a 1-D array is needed. + But there are detectors in which the real time + changes per pixel. In that case, more than one dimension is needed. Therefore + the rank of this field should be less than or equal to (detector rank + 1). + + + + + + + + + + start time for each frame, with the ``start`` attribute as absolute reference + + + + + + + stop time for each frame, with the ``start`` attribute as absolute reference + + + + + + + + + date of last calibration (geometry and/or efficiency) measurements + + + + + + summary of conversion of array data to pixels (e.g. polynomial + approximations) and location of details of the calibrations + + + + + How the detector is represented + + + + + + + + + + Elapsed actual counting time + + + + + + + + + + + Use this group to provide other data related to this NXdetector group. + + + + + + In order to properly sort the order of the images taken in (for + example) a tomography experiment, a sequence number is stored with each + image. + + + + + + + + + + This is the x position where the direct beam would hit the detector. + This is a length and can be outside of the actual + detector. The length can be in physical units or pixels + as documented by the units attribute. + + + + + + This is the y position where the direct beam would hit the detector. + This is a length and can be outside of the actual + detector. The length can be in physical units or pixels + as documented by the units attribute. + + + + + + This is the start number of the first frame of a scan. In protein crystallography measurements one + often scans a couple of frames on a give sample, then does something else, + then returns to the same sample and scans some more frames. Each time with + a new data file. This number helps concatenating such measurements. + + + + + The diameter of a cylindrical detector + + + + The acquisition mode of the detector. + + + + + + + + + + + + + True when the angular calibration has been applied in the + electronics, false otherwise. + + + + Angular calibration data. + + + + + + + + True when the flat field correction has been applied in the + electronics, false otherwise. + + + + Flat field correction data. + + + + + + + + Errors of the flat field correction data. + The form flatfield_error is deprecated. + + + + + + + + + True when the pixel mask correction has been applied in the + electronics, false otherwise. + + + + + The 32-bit pixel mask for the detector. Can be either one mask + for the whole dataset (i.e. an array with indices i, j) or + each frame can have its own mask (in which case it would be + an array with indices np, i, j). + + Contains a bit field for each pixel to signal dead, + blind or high or otherwise unwanted or undesirable pixels. + They have the following meaning: + + .. can't make a table here, a bullet list will have to do for now + + * bit 0: gap (pixel with no sensor) + * bit 1: dead + * bit 2: under responding + * bit 3: over responding + * bit 4: noisy + * bit 5: -undefined- + * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) + * bit 7: -undefined- + * bit 8: user defined mask (e.g. around beamstop) + * bits 9-30: -undefined- + * bit 31: virtual pixel (corner pixel with interpolated value) + + Normal data analysis software would + not take pixels into account + when a bit in (mask & 0x0000FFFF) is + set. Tag bit in the upper + two bytes would indicate special pixel + properties that normally + would not be a sole reason to reject the + intensity value (unless + lower bits are set. + + If the full bit depths is not required, providing a + mask with fewer bits is permissible. + + If needed, additional pixel masks can be specified by + including additional entries named pixel_mask_N, where + N is an integer. For example, a general bad pixel mask + could be specified in pixel_mask that indicates noisy + and dead pixels, and an additional pixel mask from + experiment-specific shadowing could be specified in + pixel_mask_2. The cumulative mask is the bitwise OR + of pixel_mask and any pixel_mask_N entries. + + + + + + + + + + This field allow to distinguish different types of exposure to the same detector "data" field. + Some techniques require frequent (re-)calibration inbetween measuremnts and this way of + recording the different measurements preserves the chronological order with is important for + correct processing. + + This is used for example in tomography (`:ref:`NXtomo`) sample projections, + dark and flat images, a magic number is recorded per frame. + + The key is as follows: + + * projection (sample) = 0 + * flat field = 1 + * dark field = 2 + * invalid = 3 + * background (no sample, but buffer where applicable) = 4 + + In cases where the data is of type :ref:`NXlog` this can also be an NXlog. + + + + + + + + + Counting detectors usually are not able to measure all incoming particles, + especially at higher count-rates. Count-rate correction is applied to + account for these errors. + + True when count-rate correction has been applied, false otherwise. + + + + + The countrate_correction_lookup_table defines the LUT used for count-rate + correction. It maps a measured count :math:`c` to its corrected value + :math:`countrate\_correction\_lookup\_table[c]`. + + :math:`m` denotes the length of the table. + + + + + + + + True when virtual pixel interpolation has been applied, false otherwise. + + When virtual pixel interpolation is applied, values of some pixels may + contain interpolated values. For example, to account for space between + readout chips on a module, physical pixels on edges and corners between + chips may have larger sensor areas and counts may be distributed between + their logical pixels. + + + + + How many bits the electronics reads per pixel. + With CCD's and single photon counting detectors, + this must not align with traditional integer sizes. + This can be 4, 8, 12, 14, 16, ... + + + + + Time it takes to read the detector (typically milliseconds). + This is important to know for time resolved experiments. + + + + + Time it takes to start exposure after a trigger signal has been received. + This is the reaction time of the detector firmware after receiving the trigger signal + to when the detector starts to acquire the exposure, including any user set delay.. + This is important to know for time resolved experiments. + + + + + User-specified trigger delay. + + + + + Time it takes to start exposure after a trigger signal has been received. + This is the reaction time of the detector hardware after receiving the + trigger signal to when the detector starts to acquire the exposure. + It forms the lower boundary of the trigger_delay_time when the user + does not request an additional delay. + + + + + Time during which no new trigger signal can be accepted. + Typically this is the + trigger_delay_time + exposure_time + readout_time. + This is important to know for time resolved experiments. + + + + + This is time for each frame. This is exposure_time + readout time. + + + + + + + + The gain setting of the detector. This is a detector-specific value + meant to document the gain setting of the detector during data + collection, for detectors with multiple available gain settings. + + Examples of gain settings include: + + * ``standard`` + * ``fast`` + * ``auto`` + * ``high`` + * ``medium`` + * ``low`` + * ``mixed high to medium`` + * ``mixed medium to low`` + + Developers are encouraged to use one of these terms, or to submit + additional terms to add to the list. + + + + + The value at which the detector goes into saturation. + Especially common to CCD detectors, the data + is known to be invalid above this value. + + For example, given a saturation_value and an underload_value, the valid + pixels are those less than or equal to the saturation_value and greater + than or equal to the underload_value. + + The precise type should match the type of the data. + + + + + The lowest value at which pixels for this detector would be reasonably + measured. The data is known to be invalid below this value. + + For example, given a saturation_value and an underload_value, the valid + pixels are those less than or equal to the saturation_value and greater + than or equal to the underload_value. + + The precise type should match the type of the data. + + + + + CCD images are sometimes constructed by summing + together multiple short exposures in the + electronics. This reduces background etc. + This is the number of short exposures used to sum + images for an image. + + + + + At times, radiation is not directly sensed by the detector. + Rather, the detector might sense the output from some + converter like a scintillator. + This is the name of this converter material. + + + + + At times, radiation is not directly sensed by the detector. + Rather, the detector might sense the output from some + converter like a scintillator. + This is the thickness of this converter material. + + + + + Single photon counter detectors can be adjusted + for a certain energy range in which they + work optimally. This is the energy setting for this. + + + + + For use in special cases where the data in NXdetector + is represented in several parts, each with a separate geometry. + + + + + + Shape description of each pixel. Use only if all pixels in the detector + are of uniform shape. + - - - In order to properly sort the order of the images taken in (for - example) a tomography experiment, a sequence number is stored with each - image. - - - - - - - - This is the x position where the direct beam would hit the detector. - This is a length and can be outside of the actual - detector. The length can be in physical units or pixels - as documented by the units attribute. - - - - - This is the y position where the direct beam would hit the detector. - This is a length and can be outside of the actual - detector. The length can be in physical units or pixels - as documented by the units attribute. - - - - - This is the start number of the first frame of a scan. In protein crystallography measurements one - often scans a couple of frames on a give sample, then does something else, - then returns to the same sample and scans some more frames. Each time with - a new data file. This number helps concatenating such measurements. - - - - - The diameter of a cylindrical detector - - - - - The acquisition mode of the detector. - - - - - - - - - - - - - - True when the angular calibration has been applied in the - electronics, false otherwise. - - - - - Angular calibration data. - - - - - - - - - True when the flat field correction has been applied in the - electronics, false otherwise. - - - - - Flat field correction data. - - - - - - - - - Errors of the flat field correction data. - The form flatfield_error is deprecated. - - - - - - - - - True when the pixel mask correction has been applied in the - electronics, false otherwise. - - - - - The 32-bit pixel mask for the detector. Can be either one mask - for the whole dataset (i.e. an array with indices i, j) or - each frame can have its own mask (in which case it would be - an array with indices np, i, j). - - Contains a bit field for each pixel to signal dead, - blind or high or otherwise unwanted or undesirable pixels. - They have the following meaning: - - .. can't make a table here, a bullet list will have to do for now - - * bit 0: gap (pixel with no sensor) - * bit 1: dead - * bit 2: under responding - * bit 3: over responding - * bit 4: noisy - * bit 5: -undefined- - * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) - * bit 7: -undefined- - * bit 8: user defined mask (e.g. around beamstop) - * bits 9-30: -undefined- - * bit 31: virtual pixel (corner pixel with interpolated value) - - Normal data analysis software would - not take pixels into account - when a bit in (mask & 0x0000FFFF) is - set. Tag bit in the upper - two bytes would indicate special pixel - properties that normally - would not be a sole reason to reject the - intensity value (unless - lower bits are set. - - If the full bit depths is not required, providing a - mask with fewer bits is permissible. - - If needed, additional pixel masks can be specified by - including additional entries named pixel_mask_N, where - N is an integer. For example, a general bad pixel mask - could be specified in pixel_mask that indicates noisy - and dead pixels, and an additional pixel mask from - experiment-specific shadowing could be specified in - pixel_mask_2. The cumulative mask is the bitwise OR - of pixel_mask and any pixel_mask_N entries. - - - - - - - - - This field allow to distinguish different types of exposure to the same detector "data" field. - Some techniques require frequent (re-)calibration inbetween measuremnts and this way of - recording the different measurements preserves the chronological order with is important for - correct processing. - - This is used for example in tomography (`:ref:`NXtomo`) sample projections, - dark and flat images, a magic number is recorded per frame. - - The key is as follows: - - * projection (sample) = 0 - * flat field = 1 - * dark field = 2 - * invalid = 3 - * background (no sample, but buffer where applicable) = 4 - - In cases where the data is of type :ref:`NXlog` this can also be an NXlog. - - - - - - - - Counting detectors usually are not able to measure all incoming particles, - especially at higher count-rates. Count-rate correction is applied to - account for these errors. - - True when count-rate correction has been applied, false otherwise. - - - - - The countrate_correction_lookup_table defines the LUT used for count-rate - correction. It maps a measured count :math:`c` to its corrected value - :math:`countrate\_correction\_lookup\_table[c]`. - - :math:`m` denotes the length of the table. - - - - - - - - True when virtual pixel interpolation has been applied, false otherwise. - - When virtual pixel interpolation is applied, values of some pixels may - contain interpolated values. For example, to account for space between - readout chips on a module, physical pixels on edges and corners between - chips may have larger sensor areas and counts may be distributed between - their logical pixels. - - - - - How many bits the electronics reads per pixel. - With CCD's and single photon counting detectors, - this must not align with traditional integer sizes. - This can be 4, 8, 12, 14, 16, ... - - - - - Time it takes to read the detector (typically milliseconds). - This is important to know for time resolved experiments. - - - - - Time it takes to start exposure after a trigger signal has been received. - This is the reaction time of the detector firmware after receiving the trigger signal - to when the detector starts to acquire the exposure, including any user set delay.. - This is important to know for time resolved experiments. - - - - - User-specified trigger delay. - - - - - Time it takes to start exposure after a trigger signal has been received. - This is the reaction time of the detector hardware after receiving the - trigger signal to when the detector starts to acquire the exposure. - It forms the lower boundary of the trigger_delay_time when the user - does not request an additional delay. - - - - - Time during which no new trigger signal can be accepted. - Typically this is the - trigger_delay_time + exposure_time + readout_time. - This is important to know for time resolved experiments. - - - - - This is time for each frame. This is exposure_time + readout time. - - - - - - - - The gain setting of the detector. This is a detector-specific value - meant to document the gain setting of the detector during data - collection, for detectors with multiple available gain settings. - - Examples of gain settings include: - - * ``standard`` - * ``fast`` - * ``auto`` - * ``high`` - * ``medium`` - * ``low`` - * ``mixed high to medium`` - * ``mixed medium to low`` - - Developers are encouraged to use one of these terms, or to submit - additional terms to add to the list. - - - - - The value at which the detector goes into saturation. - Especially common to CCD detectors, the data - is known to be invalid above this value. - - For example, given a saturation_value and an underload_value, the valid - pixels are those less than or equal to the saturation_value and greater - than or equal to the underload_value. - - The precise type should match the type of the data. - - - - - The lowest value at which pixels for this detector would be reasonably - measured. The data is known to be invalid below this value. - - For example, given a saturation_value and an underload_value, the valid - pixels are those less than or equal to the saturation_value and greater - than or equal to the underload_value. - - The precise type should match the type of the data. - - - - - CCD images are sometimes constructed by summing - together multiple short exposures in the - electronics. This reduces background etc. - This is the number of short exposures used to sum - images for an image. - - - - - At times, radiation is not directly sensed by the detector. - Rather, the detector might sense the output from some - converter like a scintillator. - This is the name of this converter material. - - - - - At times, radiation is not directly sensed by the detector. - Rather, the detector might sense the output from some - converter like a scintillator. - This is the thickness of this converter material. - - - - - Single photon counter detectors can be adjusted - for a certain energy range in which they - work optimally. This is the energy setting for this. - - - - - For use in special cases where the data in NXdetector - is represented in several parts, each with a separate geometry. - + + + Shape description of each pixel. Use only if all pixels in the detector + are of uniform shape and require being described by cylinders. + - - - - Shape description of each pixel. Use only if all pixels in the detector - are of uniform shape. - - - - - Shape description of each pixel. Use only if all pixels in the detector - are of uniform shape and require being described by cylinders. - - - - - - - Shape description of the whole detector. Use only if pixels in the - detector are not of uniform shape. - - - - - Shape description of the whole detector. Use only if pixels in the - detector are not of uniform shape and require being described by cylinders. - - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - - - Type of electron amplifier, MCP, channeltron, etc. - - - - - Description of the detector type, DLD, Phosphor+CCD, CMOS. - - - - - Voltage applied to detector. - - - - - Voltage applied to the amplifier. - - - - - The low voltage of the amplifier migh not be the ground. - - - - - Size of each imaging sensor chip on the detector. - - - - - Number of imaging sensor chips on the detector. - - - - - Physical size of the pixels of the imaging chip on the detector. - - - - - Number of raw active elements in each dimension. Important for swept scans. - - - - - - raw data output from the detector - + + + + + Shape description of the whole detector. Use only if pixels in the + detector are not of uniform shape. + - - - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - The reference point of the detector is the center of the first pixel. - In complex geometries the NXoff_geometry groups can be used to provide an unambiguous reference. - - - - - 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. - + + + Shape description of the whole detector. Use only if pixels in the + detector are not of uniform shape and require being described by cylinders. + + + + + Type of electron amplifier, MCP, channeltron, etc. + + + + + Description of the detector type, DLD, Phosphor+CCD, CMOS. + + + + + Voltage applied to detector. + + + + + Voltage applied to the amplifier. + + + + + The low voltage of the amplifier migh not be the ground. + + + + + Size of each imaging sensor chip on the detector. + + + + + Number of imaging sensor chips on the detector. + + + + + Physical size of the pixels of the imaging chip on the detector. + + + + + Number of raw active elements in each dimension. Important for swept scans. + + + + + + raw data output from the detector + + + + + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + + + + + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference point of the detector is the center of the first pixel. + In complex geometries the NXoff_geometry groups can be used to provide an unambiguous reference. + + + + + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. + + diff --git a/base_classes/NXentry.nxdl.xml b/base_classes/NXentry.nxdl.xml index c05ca17046..8f8f323ca9 100644 --- a/base_classes/NXentry.nxdl.xml +++ b/base_classes/NXentry.nxdl.xml @@ -1,5 +1,5 @@ - - + + - - - (**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. - - - - .. 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 <validItemName>` 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 <Find-Plottable-Data-v3>` - section. - - - - - 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 - - - - - - ISIS Muon IDF_Version - - - - - Extended title for entry - - - + + + + + .. 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 <validItemName>` 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 <Find-Plottable-Data-v3>` + section. + + + + + (**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. + + + + 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 + + + + + + + ISIS Muon IDF_Version + + + Extended title for entry + + Unique identifier for the experiment, defined by the facility, possibly linked to the proposals - - - Brief summary of the experiment, including key objectives. - - - - - Description of the full experiment (document in pdf, latex, ...) - - - - - User or Data Acquisition defined group of NeXus files or NXentry - - - - - Brief summary of the collection, including grouping criteria. - - - - - unique identifier for the measurement, defined by the facility. - - - - - UUID identifier for the measurement. - - - - Version of UUID used - - - - - - Reserved for future use by NIAC. - - See https://github.com/nexusformat/definitions/issues/382 - - - - - (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. - - - - NXDL version number - - - - - URL of NXDL file - - - - - - Local NXDL schema extended from the entry - specified in the ``definition`` field. - This contains any locally-defined, - additional fields in the entry. - - - - NXDL version number - - - - - URL of NXDL file - - - - - - Starting time of measurement - - - - - Ending time of measurement - - - - - Duration of measurement - - - - - Time transpired actually collecting data i.e. taking out time when collection was - suspended due to e.g. temperature out of range - - - - - Such as "2007-3". Some user facilities organize their beam time into run cycles. - - - - - Name of program used to generate this file - - - - Program version number - - - - - configuration of the program - - - - - - Revision id of the file due to re-calibration, reprocessing, new analysis, new - instrument definition format, ... - - - - - - This is the flightpath before the sample position. This can be determined by a chopper, - by the moderator or the source itself. In other words: it the distance to the component - which gives the T0 signal to the detector electronics. If another component in the - NXinstrument hierarchy provides this information, this should be a link. - - - - - Notes describing entry - - - - - A small image that is representative of the entry. An example of this is a 640x480 - jpeg image automatically produced by a low resolution plot of the NXdata. - - - - The mime type should be an ``image/*`` - - - - - - + + Brief summary of the experiment, including key objectives. + + + Description of the full experiment (document in pdf, latex, ...) + + + User or Data Acquisition defined group of NeXus files or NXentry + + Brief summary of the collection, including grouping criteria. + + + unique identifier for the measurement, defined by the facility. + + + UUID identifier for the measurement. + Version of UUID used + - - City and country where the experiment took place - + City and country where the experiment took place - Start time of experimental run that includes the current - measurement, for example a beam time. + Start time of experimental run that includes the current + measurement, for example a beam time. @@ -297,12 +154,107 @@ How do we set a default value for the type attribute?--> Name of the laboratory or beamline - - - - - - - - - + + + Reserved for future use by NIAC. + + See https://github.com/nexusformat/definitions/issues/382 + + + + + (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. + + NXDL version number + URL of NXDL file + + + + Local NXDL schema extended from the entry + specified in the ``definition`` field. + This contains any locally-defined, + additional fields in the entry. + + NXDL version number + URL of NXDL file + + + Starting time of measurement + + + Ending time of measurement + + + Duration of measurement + + + + Time transpired actually collecting data i.e. taking out time when collection was + suspended due to e.g. temperature out of range + + + + Such as "2007-3". Some user facilities organize their beam time into run cycles. + + + Name of program used to generate this file + Program version number + configuration of the program + + + + Revision id of the file due to re-calibration, reprocessing, new analysis, new + instrument definition format, ... + + + + + + This is the flightpath before the sample position. This can be determined by a chopper, + by the moderator or the source itself. In other words: it the distance to the component + which gives the T0 signal to the detector electronics. If another component in the + NXinstrument hierarchy provides this information, this should be a link. + + + + Notes describing entry + + + + A small image that is representative of the entry. An example of this is a 640x480 + jpeg image automatically produced by a low resolution plot of the NXdata. + + + The mime type should be an ``image/*`` + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/base_classes/NXenvironment.nxdl.xml b/base_classes/NXenvironment.nxdl.xml index 6adec2e70c..74ed194f03 100644 --- a/base_classes/NXenvironment.nxdl.xml +++ b/base_classes/NXenvironment.nxdl.xml @@ -1,5 +1,5 @@ - - + + - - - Parameters for controlling external conditions - + + Parameters for controlling external conditions - - Apparatus identification code/model number; e.g. OC100 011 - + Apparatus identification code/model number; e.g. OC100 011 - - Alternative short name, perhaps for dashboard display like a present Seblock - name - + Alternative short name, perhaps for dashboard display like a present Seblock name - - Type of apparatus. This could be the SE codes in scheduling database; e.g. - OC/100 - + Type of apparatus. This could be the SE codes in scheduling database; e.g. OC/100 - - Description of the apparatus; e.g. 100mm bore orange cryostat with Roots pump - + Description of the apparatus; e.g. 100mm bore orange cryostat with Roots pump - - Program controlling the apparatus; e.g. LabView VI name - + Program controlling the apparatus; e.g. LabView VI name @@ -64,33 +54,31 @@ the environment parameters, but the user would still like to give a value for it. An example would be a room temperature experiment where the temperature is not actively measured, but rather estimated. - + Note that this method for recording the environment parameters is not advised, but using NXsensor and NXactuator is strongly recommended instead. - NeXus positions components by applying a set of translations and rotations - 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. - 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. - - Additional information, LabView logs, digital photographs, etc - + Additional information, LabView logs, digital photographs, etc @@ -107,10 +95,10 @@ .. index:: plotting - + Declares which child group contains a path leading to a :ref:`NXdata` group. - + It is recommended (as of NIAC2014) to use this attribute to help define the path to the default dataset to be plotted. See https://www.nexusformat.org/2014_How_to_find_default_data.html diff --git a/base_classes/NXinstrument.nxdl.xml b/base_classes/NXinstrument.nxdl.xml index 7ecf803703..197163ff38 100644 --- a/base_classes/NXinstrument.nxdl.xml +++ b/base_classes/NXinstrument.nxdl.xml @@ -1,5 +1,5 @@ - - + + - - - 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. - - - - Name of instrument - - - - short name for instrument, perhaps the acronym - - - + + + 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. + + + Name of instrument + + short name for instrument, perhaps the acronym + + - - - - - - - - - - - - - + + + + + + + + + + + + + - - - - + + + + - - - - - - - + + + + + + - - - - + + + + + - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. diff --git a/base_classes/NXmonochromator.nxdl.xml b/base_classes/NXmonochromator.nxdl.xml index 46edb3bc79..dd96e3a26c 100644 --- a/base_classes/NXmonochromator.nxdl.xml +++ b/base_classes/NXmonochromator.nxdl.xml @@ -1,5 +1,5 @@ - - + + - + - A wavelength defining device. - - This is a base class for everything which - selects a wavelength or energy, be it a - monochromator crystal, a velocity selector, - an undulator or whatever. - - The expected units are: - - * wavelength: angstrom - * energy: eV + A wavelength defining device. + + This is a base class for everything which + selects a wavelength or energy, be it a + monochromator crystal, a velocity selector, + an undulator or whatever. + + The expected units are: + + * wavelength: angstrom + * energy: eV + - - wavelength selected - - - - - wavelength standard deviation - + wavelength selected + + + wavelength standard deviation - - wavelength standard deviation - + wavelength standard deviation - - energy selected - - - - - energy standard deviation - - + energy selected + + + energy standard deviation + - - energy standard deviation - + energy standard deviation @@ -85,56 +80,48 @@ Size, position and shape of the exit slit of the monochromator. - + - - This group describes the shape of the beam line component - - - - - Use as many crystals as necessary to describe - - - - - - For diffraction grating based monochromators + + This group describes the shape of the beam line component + Use as many crystals as necessary to describe + + For diffraction grating based monochromators - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a monochromator. + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a monochromator. - 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. diff --git a/base_classes/NXprocess.nxdl.xml b/base_classes/NXprocess.nxdl.xml index 497abeb037..7a9cecd4d5 100644 --- a/base_classes/NXprocess.nxdl.xml +++ b/base_classes/NXprocess.nxdl.xml @@ -1,5 +1,5 @@ - + - - - Document an event of data processing, reconstruction, or analysis for this data. - + + Document an event of data processing, reconstruction, or analysis for this data. - - Name of the program used - + Name of the program used - Sequence index of processing, - for determining the order of multiple **NXprocess** steps. - Starts with 1. + Sequence index of processing, + for determining the order of multiple **NXprocess** steps. + Starts with 1. - - Version of the program used - + Version of the program used - - Date and time of processing. - + Date and time of processing. @@ -64,25 +60,25 @@ - The note will contain information about how the data was processed - or anything about the data provenance. - The contents of the note can be anything that the processing code - can understand, or simple text. - - The name will be numbered to allow for ordering of steps. + The note will contain information about how the data was processed + or anything about the data provenance. + The contents of the note can be anything that the processing code + can understand, or simple text. + + The name will be numbered to allow for ordering of steps. - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. diff --git a/base_classes/NXroot.nxdl.xml b/base_classes/NXroot.nxdl.xml index 19ec8b7b18..18bca6113c 100644 --- a/base_classes/NXroot.nxdl.xml +++ b/base_classes/NXroot.nxdl.xml @@ -1,5 +1,5 @@ - - + + - - - Definition of the root NeXus group. - + + Definition of the root NeXus group. - The root of any NeXus data file is an ``NXroot`` class - (no other choice is allowed for a valid NeXus data file). - This attribute cements that definition. + The root of any NeXus data file is an ``NXroot`` class + (no other choice is allowed for a valid NeXus data file). + This attribute cements that definition. - + - - Date and time file was originally created - + Date and time file was originally created - - File name of original NeXus file - + File name of original NeXus file - - Date and time of last file change at close - + Date and time of last file change at close - A repository containing the application definitions - used for creating this file. - If the NeXus_version attribute contains a commit distance and hash - this should refer to this repository. + A repository containing the application definitions + used for creating this file. + If the NeXus_version attribute contains a commit distance and hash + this should refer to this repository. - Version of NeXus definitions used in writing the file. - This may either be a date based version tag of the form `vYYYY.MM` - or a version tag with a commit distance and source control (e.g., git) hash of - the form `vYYYY.MM.post1.dev<commit-distance>.g<git-hash>`. - It may contain an additional `.dYYYYMMDD` timestamp appendix - for dirty repositories. - If the version contains a commit distance and hash the - NeXus_repository attribute should be written with the - repository url containing this version. - - Only used when the NAPI or pynxtools has written the file. - Note that this is different from the version of the - base class or application definition version number. + Version of NeXus definitions used in writing the file. + This may either be a date based version tag of the form `vYYYY.MM` + or a version tag with a commit distance and source control (e.g., git) hash of + the form `vYYYY.MM.post1.dev<commit-distance>.g<git-hash>`. + It may contain an additional `.dYYYYMMDD` timestamp appendix + for dirty repositories. + If the version contains a commit distance and hash the + NeXus_repository attribute should be written with the + repository url containing this version. + + Only used when the NAPI or pynxtools has written the file. + Note that this is different from the version of the + base class or application definition version number. @@ -84,61 +80,49 @@ - - Version of HDF (version 4) library used in writing the file - + Version of HDF (version 4) library used in writing the file - Version of HDF5 library used in writing the file. - - Note this attribute is spelled with uppercase "V", - different than other version attributes. + Version of HDF5 library used in writing the file. + + Note this attribute is spelled with uppercase "V", + different than other version attributes. - - Version of XML support library used in writing the XML file - + Version of XML support library used in writing the XML file - - Version of h5py Python package used in writing the file - + Version of h5py Python package used in writing the file - - facility or program where file originated - + facility or program where file originated - - Version of facility or program used in writing the file - + Version of facility or program used in writing the file - - - entries - + + entries - .. index:: find the default plottable data - .. index:: plotting - .. index:: default attribute value - - Declares which :ref:`NXentry` group contains - the data to be shown by default. - It is used to resolve ambiguity when - more than one :ref:`NXentry` group exists. - The value :ref:`names <validItemName>` the default :ref:`NXentry` group. The - value must be the name of a child of the current group. The child must be a - NeXus group or a link to a NeXus group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: find the default plottable data + .. index:: plotting + .. index:: default attribute value + + Declares which :ref:`NXentry` group contains + the data to be shown by default. + It is used to resolve ambiguity when + more than one :ref:`NXentry` group exists. + The value :ref:`names <validItemName>` the default :ref:`NXentry` group. The + value must be the name of a child of the current group. The child must be a + NeXus group or a link to a NeXus group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. - + \ No newline at end of file diff --git a/base_classes/NXsample.nxdl.xml b/base_classes/NXsample.nxdl.xml index b2e880fc5c..4b15f3b8fa 100644 --- a/base_classes/NXsample.nxdl.xml +++ b/base_classes/NXsample.nxdl.xml @@ -1,5 +1,5 @@ - - + + - - - - symbolic array lengths to be coordinated between various fields - - - - number of compositions - - - - - number of temperatures - - - - - number of values in applied electric field - - - - - number of values in applied magnetic field - - - - - number of values in applied pressure field - - - - - number of values in applied stress field - - - - - 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. - - - - Descriptive name of sample - - + + + + symbolic array lengths to be coordinated between various fields + number of compositions + number of temperatures + number of values in applied electric field + number of values in applied magnetic field + number of values in applied pressure field + number of values in applied stress field + + + + 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. + + + Descriptive name of sample + - - Identification number or signatures of the sample used. - - - - - 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. - - - - - Sample temperature. This could be a scanned variable - - - - - - - - - Applied electric field - - - - - + Identification number or signatures of the sample used. + + + + 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. + + + + Sample temperature. This could be a scanned variable + + + + + + Applied electric field + + + - - - - - + + + + + - - - - Applied magnetic field - - - - - + + + Applied magnetic field + + + - - - - - + + + + + - - - - Applied external stress field - - - - - + + + Applied external stress field + + + - - - - - + + + + + - - - - Applied pressure - - - - - - - - - Sample changer position - - - - - Crystallography unit cell parameters a, b, and c - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma - - - - - - - - Unit cell parameters (lengths and angles) - - - - - - - - - Volume of the unit cell - - - - - - - - This will follow the Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - - - - - - - - Orientation matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - - - - - - - - - - UB matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is - the multiplication of the orientation_matrix, given above, - with the :math:`B` matrix which - can be derived from the lattice constants. - - - - - - - - - - Mass of sample - - - - - - - - Density of sample - - - - - - - - Relative Molecular Mass of sample - - - - - - - - - - - - - - - - - - - - - - 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. - - - - - - - - - - - - - - Description of the sample - - - - - Date of preparation of the sample - - - - - The position and orientation of the center of mass of the sample - - - - - Details of beam incident on sample - used to calculate sample/beam interaction - point - - - - - One group per sample component - This is the perferred way of recording per component information over the n_comp arrays - - - - - Details of the component of the sample and/or can - - - - - - - - Type of component - - - - - - - - - - - - - - Concentration of each component - - - + + + Applied pressure + + + + + + Sample changer position + + + Crystallography unit cell parameters a, b, and c + + + + + + Crystallography unit cell parameters alpha, beta, and gamma + + + + + + Unit cell parameters (lengths and angles) + + + + + + + Volume of the unit cell + + + + + + + This will follow the Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + + + + + + + + Orientation matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + + + + + + + + + + UB matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is + the multiplication of the orientation_matrix, given above, + with the :math:`B` matrix which + can be derived from the lattice constants. + + + + + + + + + Mass of sample + + + + + + Density of sample + + + + + + Relative Molecular Mass of sample + + + + + + + + + + + + + + + + + + + + + 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. + + + + + + + + + + + + + + Description of the sample + + + + Date of preparation of the sample + + + The position and orientation of the center of mass of the sample + + + Details of beam incident on sample - used to calculate sample/beam interaction point + + + + One group per sample component + This is the perferred way of recording per component information over the n_comp arrays + + + + Details of the component of the sample and/or can + + + + + + Type of component + + + + + + + + + + + + Concentration of each component + + + + + + Volume fraction of each component + + + + + + Scattering length density of each component + + + + + + + In case it is all we know and we want to record/document it + + + + + + + + + + + + + Crystallographic space group + + + + + + Crystallographic point group, deprecated if space_group present + + - - - - Volume fraction of each component - - - - - - - - Scattering length density of each component - - - - - - - - In case it is all we know and we want to record/document it - - - - - - - - - - - - - - Crystallographic space group - - - - - - - - Crystallographic point group, deprecated if space_group present - - - - - - - - Path length through sample/can for simple case when - it does not vary with scattering direction - - - - - Thickness of a beam entry/exit window on the can (mm) - - assumed same for entry and exit - - - - - sample thickness - - - - - As a function of Wavelength - - - - - temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value - - - - - Additional sample temperature environment information - + + + + Path length through sample/can for simple case when + it does not vary with scattering direction + + + + + Thickness of a beam entry/exit window on the can (mm) + - assumed same for entry and exit + + + + sample thickness + + + As a function of Wavelength + + + temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value + + + Additional sample temperature environment information + + + magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value + + + magnetic_field_log.value is a link to e.g. magnetic_field_env.sensor1.value_log.value + + + Additional sample magnetic environment information + + + value sent to user's sample setup + + + logged value (or logic state) read from user's setup + + + 20 character fixed length sample description for legends + + + + + Optional rotation angle for the case when the powder diagram has + been obtained through an omega-2theta scan like from a traditional + single detector powder diffractometer. + Note, it is recommended to use NXtransformations instead. + + + + + Translation of the sample along the X-direction of the laboratory coordinate system + Note, it is recommended to use NXtransformations instead. + + + + + Translation of the sample along the Z-direction of the laboratory coordinate system. + Note, it is recommended to use NXtransformations instead. + + + + Any positioner (motor, PZT, ...) used to locate the sample - + - magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value - - - - - magnetic_field_log.value is a link to e.g. - magnetic_field_env.sensor1.value_log.value - - - - - Additional sample magnetic environment information - - - - - value sent to user's sample setup - - - - - logged value (or logic state) read from user's setup - - - - - 20 character fixed length sample description for legends - - - - - - Optional rotation angle for the case when the powder diagram has - been obtained through an omega-2theta scan like from a traditional - single detector powder diffractometer. - Note, it is recommended to use NXtransformations instead. - - - - - Translation of the sample along the X-direction of the laboratory coordinate system - Note, it is recommended to use NXtransformations instead. - - - - - Translation of the sample along the Z-direction of the laboratory coordinate system. - Note, it is recommended to use NXtransformations instead. - - - - - Any positioner (motor, PZT, ...) used to locate the sample - - - - - - This group describes the shape of the sample + This group describes the shape of the sample @@ -525,9 +426,7 @@ exists: ['min', '0'] - + Any environmental or external stimuli/measurements. These can include, among others: @@ -542,33 +441,33 @@ eventually, this should be stored in the application definitions - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. - + - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. + 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. - 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. diff --git a/base_classes/NXsample_component.nxdl.xml b/base_classes/NXsample_component.nxdl.xml index c90bfac982..3c4670a148 100644 --- a/base_classes/NXsample_component.nxdl.xml +++ b/base_classes/NXsample_component.nxdl.xml @@ -1,5 +1,5 @@ - - + + - - - - symbolic array lengths to be coordinated between various fields - - - - number of temperatures - - - - - number of values in applied electric field - - - - - number of values in applied magnetic field - - - - - number of values in applied pressure field - - - - - number of values in applied stress field - - - - - One group like this per component can be recorded For a sample consisting of - multiple components. - - - - Descriptive name of sample component - - + + + + symbolic array lengths to be coordinated between various fields + number of temperatures + number of values in applied electric field + number of values in applied magnetic field + number of values in applied pressure field + number of values in applied stress field + + + + One group like this per component can be recorded for a sample consisting of multiple components. + + + Descriptive name of sample component + Identification number or signatures of the sample component used. - - - The chemical formula specified using CIF conventions. - 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. - - - - - Crystallography unit cell parameters a, b, and c - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma - - - - - - - - Volume of the unit cell - - - - - This will follow the Busing and Levy convention from Acta.Crysta v22, p457 - (1967) - - - - - - - - Orientation matrix of single crystal sample component. - This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) - - - - - - - - - Mass of sample component - - - - - Density of sample component - - - - - Relative Molecular Mass of sample component - - - - - Description of the sample component - - - - - Volume fraction of component - - - - - Scattering length density of component - - - - - In case it is all we know and we want to record/document it - - - - - - - - - - - - - - Crystallographic space group - - - - - Crystallographic point group, deprecated if space_group present - - - - - As a function of Wavelength - - + + + 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. + + + + Crystallography unit cell parameters a, b, and c + + + + + + Crystallography unit cell parameters alpha, beta, and gamma + + + + + + Volume of the unit cell + + + This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) + + + + + + + Orientation matrix of single crystal sample component. + This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) + + + + + + + + Mass of sample component + + + Density of sample component + + + Relative Molecular Mass of sample component + + + + Description of the sample component + + + + Volume fraction of component + + + Scattering length density of component + + + + In case it is all we know and we want to record/document it + + + + + + + + + + + + + Crystallographic space group + + + Crystallographic point group, deprecated if space_group present + + + As a function of Wavelength + If the component is a single crystal, add description of single crystal and unit @@ -212,6 +169,11 @@ Details about the sample component vendor (company or research group) + + + An (ideally) globally unique identifier for the sample component. + + A set of physical processes that occurred to the sample component prior/during @@ -226,15 +188,15 @@ - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. - + \ No newline at end of file diff --git a/base_classes/NXsensor.nxdl.xml b/base_classes/NXsensor.nxdl.xml index 09dbe2e227..7c2e5fce39 100644 --- a/base_classes/NXsensor.nxdl.xml +++ b/base_classes/NXsensor.nxdl.xml @@ -1,5 +1,5 @@ - - + + - - - A sensor used to monitor an external condition - - The condition itself is described in :ref:`NXenvironment`. - - - - Sensor identification code/model number - - - - - Name for the sensor - - - - - Short name of sensor used e.g. on monitor display program - - - - - where sensor is attached to ("sample" | "can") - - - - - Defines the axes for logged vector quantities if they are not the global - instrument axes. - - - - - name for measured signal - - - - - - - - - - - - - - - - - - - - - The type of hardware used for the measurement. - Examples (suggestions but not restrictions): - - :Temperature: - J | K | T | E | R | S | Pt100 | Rh/Fe - :pH: - Hg/Hg2Cl2 | Ag/AgCl | ISFET - :Ion selective electrode: - specify species; e.g. Ca2+ - :Magnetic field: - Hall - :Surface pressure: - wilhelmy plate - - - - - Is data collection controlled or synchronised to this quantity: - 1=no, 0=to "value", 1=to "value_deriv1", etc. - - - - - Upper control bound of sensor reading if using run_control - - - - - Lower control bound of sensor reading if using run_control - - - - - nominal setpoint or average value - - need [n] as may be a vector - - - - - - - - Nominal/average first derivative of value - e.g. strain rate - - same dimensions as "value" (may be a vector) - - - - - - - - Nominal/average second derivative of value - - same dimensions as "value" (may be a vector) - - - - - - - - Time history of sensor readings - - - - - Time history of first derivative of sensor readings - - - - - Time history of second derivative of sensor readings - - - - - - - - - - - - - - - For complex external fields not satisfied by External_field_brief - - - - - This group describes the shape of the sensor when necessary. - - + + + A sensor used to monitor an external condition + + The condition itself is described in :ref:`NXenvironment`. + + + Sensor identification code/model number + + + Name for the sensor + + + Short name of sensor used e.g. on monitor display program + + + where sensor is attached to ("sample" | "can") + + + + Defines the axes for logged vector quantities if they are not the global instrument axes. + + + + name for measured signal + + + + + + + + + + + + + + + + + + + + The type of hardware used for the measurement. + Examples (suggestions but not restrictions): + + :Temperature: + J | K | T | E | R | S | Pt100 | Rh/Fe + :pH: + Hg/Hg2Cl2 | Ag/AgCl | ISFET + :Ion selective electrode: + specify species; e.g. Ca2+ + :Magnetic field: + Hall + :Surface pressure: + wilhelmy plate + + + + + Is data collection controlled or synchronised to this quantity: + 1=no, 0=to "value", 1=to "value_deriv1", etc. + + + + + Upper control bound of sensor reading if using run_control + + + + + Lower control bound of sensor reading if using run_control + + + + + nominal setpoint or average value + - need [n] as may be a vector + + + + + + + + Nominal/average first derivative of value + e.g. strain rate + - same dimensions as "value" (may be a vector) + + + + + + + + Nominal/average second derivative of value + - same dimensions as "value" (may be a vector) + + + + + + + Time history of sensor readings + + + Time history of first derivative of sensor readings + + + Time history of second derivative of sensor readings + + + + + + + + + + + + + For complex external fields not satisfied by External_field_brief + + + + This group describes the shape of the sensor when necessary. + + - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a sensor. + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a sensor. + - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. diff --git a/base_classes/NXsource.nxdl.xml b/base_classes/NXsource.nxdl.xml index e5d1ca04ce..815022f889 100644 --- a/base_classes/NXsource.nxdl.xml +++ b/base_classes/NXsource.nxdl.xml @@ -1,5 +1,5 @@ - - + + - - - Radiation source emitting a beam. - - Examples include particle sources (electrons, neutrons, protons) or sources for electromagnetic radiation (photons). - This base class can also be used to describe neutron or x-ray storage ring/facilities. - - - - Effective distance from sample - Distance as seen by radiation from sample. This number should be negative - to signify that it is upstream of the sample. - - - - - Name of source - - - - short name for source, perhaps the acronym - - - - - - type of radiation source (pick one from the enumerated list and spell exactly) - - - - - - - - - - - - - - - - - - - - type of radiation probe (pick one from the enumerated list and spell exactly) - - - - - - - - - - - - - - - - Source power - - - - - Source emittance (nm-rad) in X (horizontal) direction. - - - - - Source emittance (nm-rad) in Y (horizontal) direction. - - - - - particle beam size in x - - - - - particle beam size in y - - - - - Source intensity/area (example: s-1 cm-2) - - - - - Source energy. Typically, this would be the energy of - the emitted beam. For storage rings, this would be - the particle beam energy. - - - - - Accelerator, X-ray tube, or storage ring current - - - - - Accelerator voltage - - - - - Frequency of pulsed source - - - - - Period of pulsed source - - - - - Pulsed source target material - - - - - - - - - - - - - - any source/facility related messages/events that - occurred during the experiment - - - - - For storage rings, description of the bunch pattern. - This is useful to describe irregular bunch patterns. - - - - name of the bunch pattern - - - - - - For storage rings, the number of bunches in use. - - - - - For storage rings, temporal length of the bunch - - - - - For storage rings, time between bunches - - - - - temporal width of source pulse - - - - - - source pulse shape - - - - - - source operating mode - - - - - for storage rings - - - - - for storage rings - - - - - - - - Is the synchrotron operating in top_up mode? - - - - - For storage rings, the current at the end of the most recent injection. - - - - date and time of the most recent injection. - - - - - - The wavelength of the radiation emitted by the source. - - - - - For pulsed sources, the energy of a single pulse. - - - - - For pulsed sources, the pulse energy divided - by the pulse duration - - - - - Material of the anode (for X-ray tubes). - - - - - Filament current (for X-ray tubes). - - - - - Emission current of the generated beam. - - - - - Gas pressure inside ionization source. - - - - - "Engineering" location of source. - - - - - The size and position of an aperture inside the source. - - - - - Deflectors inside the source. - - - - - Individual electromagnetic lenses inside the source. - - - - - - This group describes the shape of the beam line component - - - - - The wavelength or energy distribution of the source - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - - - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the - z axis. - - .. image:: source/source.png - :width: 40% - - - - - 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. - - - + + + Radiation source emitting a beam. + + Examples include particle sources (electrons, neutrons, protons) or sources for electromagnetic radiation (photons). + This base class can also be used to describe neutron or x-ray storage ring/facilities. + + + + Effective distance from sample + Distance as seen by radiation from sample. This number should be negative + to signify that it is upstream of the sample. + + + + Name of source + + short name for source, perhaps the acronym + + + + type of radiation source (pick one from the enumerated list and spell exactly) + + + + + + + + + + + + + + + + + + type of radiation probe (pick one from the enumerated list and spell exactly) + + + + + + + + + + + + + + Source power + + + Source emittance (nm-rad) in X (horizontal) direction. + + + Source emittance (nm-rad) in Y (horizontal) direction. + + + particle beam size in x + + + particle beam size in y + + + Source intensity/area (example: s-1 cm-2) + + + + Source energy. Typically, this would be the energy of + the emitted beam. For storage rings, this would be + the particle beam energy. + + + + Accelerator, X-ray tube, or storage ring current + + + Accelerator voltage + + + Frequency of pulsed source + + + Period of pulsed source + + + Pulsed source target material + + + + + + + + + + + + + any source/facility related messages/events that + occurred during the experiment + + + + + For storage rings, description of the bunch pattern. + This is useful to describe irregular bunch patterns. + + name of the bunch pattern + + + For storage rings, the number of bunches in use. + + + For storage rings, temporal length of the bunch + + + For storage rings, time between bunches + + + temporal width of source pulse + + + source pulse shape + + + source operating mode + + for storage rings + for storage rings + + + + + Is the synchrotron operating in top_up mode? + + + For storage rings, the current at the end of the most recent injection. + date and time of the most recent injection. + + + + The wavelength of the radiation emitted by the source. + + + + + For pulsed sources, the energy of a single pulse. + + + + + For pulsed sources, the pulse energy divided + by the pulse duration + + + + + Material of the anode (for X-ray tubes). + + + + + Filament current (for X-ray tubes). + + + + + Emission current of the generated beam. + + + + + Gas pressure inside ionization source. + + + + + "Engineering" location of source. + + + + + The size and position of an aperture inside the source. + + + + + Deflectors inside the source. + + + + + Individual electromagnetic lenses inside the source. + + + + + + This group describes the shape of the beam line component + + + + The wavelength or energy distribution of the source + + + + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + + + + + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the + z axis. + + .. image:: source/source.png + :width: 40% + + + + + + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. + + + \ No newline at end of file diff --git a/base_classes/NXsubentry.nxdl.xml b/base_classes/NXsubentry.nxdl.xml index c83b8d720e..726080c202 100644 --- a/base_classes/NXsubentry.nxdl.xml +++ b/base_classes/NXsubentry.nxdl.xml @@ -1,5 +1,5 @@ - - + + - - - Group of multiple application definitions for "multi-modal" (e.g. SAXS/WAXS) measurements. - - ``NXsubentry`` is a base class virtually identical to :ref:`NXentry` - and is used as the (overlay) location for application definitions. - Use a separate ``NXsubentry`` for each application definition. - - To use ``NXsubentry`` with a hypothetical application definition - called ``NXmyappdef``: - - * Create a group with attribute ``NX_class="NXsubentry"`` - * Within that group, create a field called ``definition="NXmyappdef"``. - * There are two optional attributes of definition: ``version`` and ``URL`` - - The intended use is to define application definitions for a - multi-modal (a.k.a. multi-technique) :ref:`NXentry`. - Previously, an application definition - replaced :ref:`NXentry` with its own definition. - With the increasing popularity of instruments combining - multiple techniques for data collection (such as SAXS/WAXS instruments), - it was recognized the application definitions must be entered in the NeXus - data file tree as children of :ref:`NXentry`. - - - - .. 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 <validItemName>` the default :ref:`NXentry` group. The - value must be the name of a child of the current group. The child must be a - NeXus group or a link to a NeXus group. - - For more information about how NeXus identifies the default - plottable data, see the - :ref:`Find Plottable Data, v3 <Find-Plottable-Data-v3>` - section. - - - - - - ISIS Muon IDF_Version - - - - - Extended title for entry - - - - - Unique identifier for the experiment, defined by - the facility, possibly linked to the proposals - - - - - Brief summary of the experiment, including key objectives. - - - - - Description of the full experiment (document in pdf, latex, ...) - - - - - User or Data Acquisition defined group of NeXus files or :ref:`NXentry` - - - - - Brief summary of the collection, including grouping criteria. - - - - - unique identifier for the measurement, defined by the facility. - - - - - Official NeXus NXDL schema to which this subentry conforms - - - - NXDL version number - - - - - URL of NXDL file - - - - - - Local NXDL schema extended from the subentry - specified in the ``definition`` field. - This contains any locally-defined, - additional fields in the subentry. - - - - NXDL version number - - - - - URL of NXDL file - - - - - - Starting time of measurement - - - - - Ending time of measurement - - - - - Duration of measurement - - - - - Time transpired actually collecting data i.e. taking out time when collection was - suspended due to e.g. temperature out of range - - - - - Such as "2007-3". Some user facilities organize their beam time into run cycles. - - - - - Name of program used to generate this file - - - - Program version number - - - - - configuration of the program - - - - - - Revision id of the file due to re-calibration, reprocessing, new analysis, new - instrument definition format, ... - - - - - - This is the flightpath before the sample position. This can be determined by a chopper, - by the moderator or the source itself. In other words: it the distance to the component - which gives the T0 signal to the detector electronics. If another component in the - NXinstrument hierarchy provides this information, this should be a link. - - - - - Notes describing entry - - - - - A small image that is representative of the entry. An example of this is a 640x480 - jpeg image automatically produced by a low resolution plot of the NXdata. - - - - The value should be an ``image/*`` - - - - - - - - - - - - - - - - + + + + + .. 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 <validItemName>` the default :ref:`NXentry` group. The + value must be the name of a child of the current group. The child must be a + NeXus group or a link to a NeXus group. + + For more information about how NeXus identifies the default + plottable data, see the + :ref:`Find Plottable Data, v3 <Find-Plottable-Data-v3>` + section. + + + + + Group of multiple application definitions for "multi-modal" (e.g. SAXS/WAXS) measurements. + + ``NXsubentry`` is a base class virtually identical to :ref:`NXentry` + and is used as the (overlay) location for application definitions. + Use a separate ``NXsubentry`` for each application definition. + + To use ``NXsubentry`` with a hypothetical application definition + called ``NXmyappdef``: + + * Create a group with attribute ``NX_class="NXsubentry"`` + * Within that group, create a field called ``definition="NXmyappdef"``. + * There are two optional attributes of definition: ``version`` and ``URL`` + + The intended use is to define application definitions for a + multi-modal (a.k.a. multi-technique) :ref:`NXentry`. + Previously, an application definition + replaced :ref:`NXentry` with its own definition. + With the increasing popularity of instruments combining + multiple techniques for data collection (such as SAXS/WAXS instruments), + it was recognized the application definitions must be entered in the NeXus + data file tree as children of :ref:`NXentry`. + + + + + ISIS Muon IDF_Version + + + + Extended title for entry + + + + Unique identifier for the experiment, defined by + the facility, possibly linked to the proposals + + + + Brief summary of the experiment, including key objectives. + + + Description of the full experiment (document in pdf, latex, ...) + + + User or Data Acquisition defined group of NeXus files or :ref:`NXentry` + + + Brief summary of the collection, including grouping criteria. + + + unique identifier for the measurement, defined by the facility. + + + Official NeXus NXDL schema to which this subentry conforms + NXDL version number + URL of NXDL file + + + + Local NXDL schema extended from the subentry + specified in the ``definition`` field. + This contains any locally-defined, + additional fields in the subentry. + + NXDL version number + URL of NXDL file + + + Starting time of measurement + + + Ending time of measurement + + + Duration of measurement + + + + Time transpired actually collecting data i.e. taking out time when collection was + suspended due to e.g. temperature out of range + + + + Such as "2007-3". Some user facilities organize their beam time into run cycles. + + + Name of program used to generate this file + Program version number + configuration of the program + + + + Revision id of the file due to re-calibration, reprocessing, new analysis, new + instrument definition format, ... + + + + + + This is the flightpath before the sample position. This can be determined by a chopper, + by the moderator or the source itself. In other words: it the distance to the component + which gives the T0 signal to the detector electronics. If another component in the + NXinstrument hierarchy provides this information, this should be a link. + + + + Notes describing entry + + + + A small image that is representative of the entry. An example of this is a 640x480 + jpeg image automatically produced by a low resolution plot of the NXdata. + + + The value should be an ``image/*`` + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/base_classes/NXtransformations.nxdl.xml b/base_classes/NXtransformations.nxdl.xml index 41d2d5d7da..6130240311 100644 --- a/base_classes/NXtransformations.nxdl.xml +++ b/base_classes/NXtransformations.nxdl.xml @@ -1,10 +1,10 @@ - - + + - - - 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 :ref:`McSTAS coordinate frame<Design-CoordinateSystem>` - is assumed, but additional useful coordinate axes may be defined by using axes for which - no transformation type has been specified. - - **Transformation chain** - - The entry point of a chain of transformations is a field called ``depends_on`` - will be outside of this class and points 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` - which in turn depends on :math:`T_3`, the final *active* transformation - matrix :math:`T_f` is - - .. math:: T_f = T_3 . T_2 . T_1 - - For example when positioning a flat detector, its pixel positions in the laboratory - reference frame (:ref:`McSTAS coordinate frame<Design-CoordinateSystem>` by default) - can be calculated by - - .. math:: X_\text{lab} = T_f . X_\text{pixel} = T_3 . T_2 . T_1 . X_\text{pixel} - - Note that :math:`T_1` comes first in the *depends-on* chain and is also applied first - to the pixel coordinates. - - When we say transformation :math:`A` *depends on* transformation :math:`B` we mean that - the physical motor that realizes :math:`A` is *stacked on top of* the motor that realizes :math:`B`. - So the activate coordinate transformation :math:`A` needs to be applied to a coordinate - before applying :math:`B`. In other words :math:`X' = B . A . X`. - - **Transformation matrix** - - In explicit terms, the transformations are a subset of affine transformations expressed as - 4x4 active transformation matrices that act on homogeneous coordinates, :math:`X=[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. - - **Usage** - - 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 description 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. - - **Example 1: goniometer** - - Position a sample mounted on a goniometer in the :ref:`McSTAS coordinate frame<Design-CoordinateSystem>`. - - The sample is oriented as follows - - .. math:: X_\text{lab} = R(\vec{v}_\omega, \omega) . - T(\vec{v}_z, \text{sam}_z) . - T(\vec{v}_y, \text{sam}_y) . - T(\vec{v}_x, \text{sam}_x) . - R(\vec{v}_\chi, \chi) . - R(\vec{v}_\varphi, \varphi) . X_s - - where - - * :math:`R(\vec{v},a)` is a rotation around vector :math:`\vec{v}` with angle :math:`a` - * :math:`T(\vec{u},t)` is a translation along vector :math:`\vec{u}` over a distance :math:`t` - * :math:`X_s` a coordinate in the sample reference frame. - - .. code-block:: - - entry:NXentry - sample:NXsample - depends_on=transformations/phi - transformations:NXtransformations - phi=0 - @depends_on=chi - @transformation_type=rotation - @vector=[-1 -0.0037 -0.002] - @units=degrees - chi=0 - @depends_on=sam_x - @transformation_type=rotation - @vector=[0.0046 0.0372 0.9993] - @units=degrees - sam_x=0 - @depends_on=sam_y - @transformation_type=translation - @vector=[1 0 0] - @units=mm - sam_y=0 - @depends_on=sam_z - @transformation_type=translation - @vector=[0 1 0] - @units=mm - sam_z=0 - @depends_on=omega - @transformation_type=translation - @vector=[0 0 1] - @units=mm - omega=174 - @depends_on=. - @transformation_type=rotation - @vector=[-1 0 0] - @units=degrees - - **Example 2: different coordinate system** - - Define a laboratory reference frame with the X-axis along the beam and the Z-axis opposite to the direction of gravity. - Three point detectors are positioned in this reference: - - * *transmission*: - * point detector in the beam - * 20 cm downstream from the sample (the origin of the reference frame) - * *vertical*: - * point detector 10 cm downstream from the sample - * making an angle of 5 degrees with the beam w.r.t. the sample - * positioned in the XZ-plane above the XY-plane - * *horizontal*: - * point detector 11 cm downstream from the sample - * making an angle of 6 degrees with the beam w.r.t. the sample - * positioned in the XY-plane above the XZ-plane - - The coordinates of the point detectors in the laboratory reference frame are - - * *transmission*: :math:`X_\text{lab} = T_x(20) . X_d` - * *vertical*: :math:`X_\text{lab} = R_y(-5) . T_x(10) . X_d` - * *horizontal*: :math:`X_\text{lab} = R_x(-90) . R_y(-6) . T_x(11) . X_d` - - where - - * :math:`T_x`, :math:`T_y`, :math:`T_z`: active transformation matrices for translation along the X, Y and Z axes - * :math:`R_x`, :math:`R_y`, :math:`R_z`: active transformation matrices for rotation around the X, Y and Z axes - * :math:`X_d` is a coordinate in the detector reference frame. - - Note that as these are point detectors, we only have one coordinate :math:`X_d=[0,0,0,1]^T`. - - .. code-block:: - - entry:NXentry - instrument:NXinstrument - vertical:NXdetector - depends_on=position/distance - position:NXtransformations - distance=10 # move downstream from the sample - @depends_on=polar - @units=cm - @vector=[1 0 0] - polar=5 # title above the horizontal plane - @depends_on=azimuth - @units=degrees - @vector=[0 -1 0] - azimuth=0 # stay in the vertical plane - @depends_on=/entry/coordinate_system/beam - @units=degrees - @vector=[-1 0 0] - horizontal:NXdetector - depends_on=position/distance - position:NXtransformations - distance=11 # move downstream from the sample - @depends_on=polar - @units=cm - @vector=[1 0 0] - polar=6 # title above the horizontal plane - @depends_on=azimuth - @units=degrees - @vector=[0 -1 0] - azimuth=90 # rotate to the horizontal plane - @depends_on=/entry/coordinate_system/beam - @units=degrees - @vector=[-1 0 0] - transmission:NXdetector - depends_on=position/distance - position:NXtransformations - distance=20 # move downstream from the sample - @depends_on=/entry/coordinate_system/beam - @units=cm - @vector=[1 0 0] - coordinate_system:NXtransformations - beam=NaN # value is never used - @depends_on=gravity - @vector=[1 0 0] # X-axis points in the beam direction - gravity=NaN # value is never used - @depends_on=. # end of the chain - @vector=[0 0 -1] # Z-axis points up - - - - 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``. - - - - 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. - - - - - - - - - - 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. - - - - - - - - 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. - - - - - - - - Units of the offset. Values should be consistent with NX_LENGTH. - - - - - Points to the path of a field defining the axis on which this instance of - NXtransformations depends or the string ".". It can also point to an instance of - ``NX_coordinate_system`` if this transformation depends on it. - - - - - An arbitrary identifier of a component of the equipment to which - the transformation belongs, such as 'detector_arm' or 'detector_module'. - NXtransformations with the same equipment_component label form a logical - grouping which can be combined together into a single change-of-basis - operation. - - - - - - ``AXISNAME_end`` is a placeholder for a name constructed from the actual - name of an axis to which ``_end`` has been appended. - - The values in this field are the end points of the motions that start - at the corresponding positions given in the ``AXISNAME`` field. - - - - - ``AXISNAME_increment_set`` is a placeholder for a name constructed from the actual - name of an axis to which ``_increment_set`` has been appended. - - The value of this optional field is the intended average range through which - the corresponding axis moves during the exposure of a frame. Ideally, the - value of this field added to each value of ``AXISNAME`` would agree with the - corresponding values of ``AXISNAME_end``, but there is a possibility of significant - differences. Use of ``AXISNAME_end`` is recommended. - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - + + + + 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 :ref:`McSTAS coordinate frame<Design-CoordinateSystem>` + is assumed, but additional useful coordinate axes may be defined by using axes for which + no transformation type has been specified. + + **Transformation chain** + + The entry point of a chain of transformations is a field called ``depends_on`` + will be outside of this class and points 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` + which in turn depends on :math:`T_3`, the final *active* transformation + matrix :math:`T_f` is + + .. math:: T_f = T_3 . T_2 . T_1 + + For example when positioning a flat detector, its pixel positions in the laboratory + reference frame (:ref:`McSTAS coordinate frame<Design-CoordinateSystem>` by default) + can be calculated by + + .. math:: X_\text{lab} = T_f . X_\text{pixel} = T_3 . T_2 . T_1 . X_\text{pixel} + + Note that :math:`T_1` comes first in the *depends-on* chain and is also applied first + to the pixel coordinates. + + When we say transformation :math:`A` *depends on* transformation :math:`B` we mean that + the physical motor that realizes :math:`A` is *stacked on top of* the motor that realizes :math:`B`. + So the activate coordinate transformation :math:`A` needs to be applied to a coordinate + before applying :math:`B`. In other words :math:`X' = B . A . X`. + + **Transformation matrix** + + In explicit terms, the transformations are a subset of affine transformations expressed as + 4x4 active transformation matrices that act on homogeneous coordinates, :math:`X=[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. + + **Usage** + + 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 description 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. + + **Example 1: goniometer** + + Position a sample mounted on a goniometer in the :ref:`McSTAS coordinate frame<Design-CoordinateSystem>`. + + The sample is oriented as follows + + .. math:: X_\text{lab} = R(\vec{v}_\omega, \omega) . + T(\vec{v}_z, \text{sam}_z) . + T(\vec{v}_y, \text{sam}_y) . + T(\vec{v}_x, \text{sam}_x) . + R(\vec{v}_\chi, \chi) . + R(\vec{v}_\varphi, \varphi) . X_s + + where + + * :math:`R(\vec{v},a)` is a rotation around vector :math:`\vec{v}` with angle :math:`a` + * :math:`T(\vec{u},t)` is a translation along vector :math:`\vec{u}` over a distance :math:`t` + * :math:`X_s` a coordinate in the sample reference frame. + + .. code-block:: + + entry:NXentry + sample:NXsample + depends_on=transformations/phi + transformations:NXtransformations + phi=0 + @depends_on=chi + @transformation_type=rotation + @vector=[-1 -0.0037 -0.002] + @units=degrees + chi=0 + @depends_on=sam_x + @transformation_type=rotation + @vector=[0.0046 0.0372 0.9993] + @units=degrees + sam_x=0 + @depends_on=sam_y + @transformation_type=translation + @vector=[1 0 0] + @units=mm + sam_y=0 + @depends_on=sam_z + @transformation_type=translation + @vector=[0 1 0] + @units=mm + sam_z=0 + @depends_on=omega + @transformation_type=translation + @vector=[0 0 1] + @units=mm + omega=174 + @depends_on=. + @transformation_type=rotation + @vector=[-1 0 0] + @units=degrees + + **Example 2: different coordinate system** + + Define a laboratory reference frame with the X-axis along the beam and the Z-axis opposite to the direction of gravity. + Three point detectors are positioned in this reference: + + * *transmission*: + * point detector in the beam + * 20 cm downstream from the sample (the origin of the reference frame) + * *vertical*: + * point detector 10 cm downstream from the sample + * making an angle of 5 degrees with the beam w.r.t. the sample + * positioned in the XZ-plane above the XY-plane + * *horizontal*: + * point detector 11 cm downstream from the sample + * making an angle of 6 degrees with the beam w.r.t. the sample + * positioned in the XY-plane above the XZ-plane + + The coordinates of the point detectors in the laboratory reference frame are + + * *transmission*: :math:`X_\text{lab} = T_x(20) . X_d` + * *vertical*: :math:`X_\text{lab} = R_y(-5) . T_x(10) . X_d` + * *horizontal*: :math:`X_\text{lab} = R_x(-90) . R_y(-6) . T_x(11) . X_d` + + where + + * :math:`T_x`, :math:`T_y`, :math:`T_z`: active transformation matrices for translation along the X, Y and Z axes + * :math:`R_x`, :math:`R_y`, :math:`R_z`: active transformation matrices for rotation around the X, Y and Z axes + * :math:`X_d` is a coordinate in the detector reference frame. + + Note that as these are point detectors, we only have one coordinate :math:`X_d=[0,0,0,1]^T`. + + .. code-block:: + + entry:NXentry + instrument:NXinstrument + vertical:NXdetector + depends_on=position/distance + position:NXtransformations + distance=10 # move downstream from the sample + @depends_on=polar + @units=cm + @vector=[1 0 0] + polar=5 # title above the horizontal plane + @depends_on=azimuth + @units=degrees + @vector=[0 -1 0] + azimuth=0 # stay in the vertical plane + @depends_on=/entry/coordinate_system/beam + @units=degrees + @vector=[-1 0 0] + horizontal:NXdetector + depends_on=position/distance + position:NXtransformations + distance=11 # move downstream from the sample + @depends_on=polar + @units=cm + @vector=[1 0 0] + polar=6 # title above the horizontal plane + @depends_on=azimuth + @units=degrees + @vector=[0 -1 0] + azimuth=90 # rotate to the horizontal plane + @depends_on=/entry/coordinate_system/beam + @units=degrees + @vector=[-1 0 0] + transmission:NXdetector + depends_on=position/distance + position:NXtransformations + distance=20 # move downstream from the sample + @depends_on=/entry/coordinate_system/beam + @units=cm + @vector=[1 0 0] + coordinate_system:NXtransformations + beam=NaN # value is never used + @depends_on=gravity + @vector=[1 0 0] # X-axis points in the beam direction + gravity=NaN # value is never used + @depends_on=. # end of the chain + @vector=[0 0 -1] # Z-axis points up + + + + + 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``. + + + + 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. In this case the value of the ``AXISNAME`` field + is not used and can be set to the number ``NaN``. + + + + + + + + + + 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. + + + + + + + + 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. + + + + + + + + Units of the offset. Values should be consistent with NX_LENGTH. + + + + + Points to the path of a field defining the axis on which this instance of + NXtransformations depends or the string ".". It can also point to an instance of + ``NX_coordinate_system`` if this transformation depends on it. + + + + + An arbitrary identifier of a component of the equipment to which + the transformation belongs, such as 'detector_arm' or 'detector_module'. + NXtransformations with the same equipment_component label form a logical + grouping which can be combined together into a single change-of-basis + operation. + + + + + + ``AXISNAME_end`` is a placeholder for a name constructed from the actual + name of an axis to which ``_end`` has been appended. + + The values in this field are the end points of the motions that start + at the corresponding positions given in the ``AXISNAME`` field. + + + + + ``AXISNAME_increment_set`` is a placeholder for a name constructed from the actual + name of an axis to which ``_increment_set`` has been appended. + + The value of this optional field is the intended average range through which + the corresponding axis moves during the exposure of a frame. Ideally, the + value of this field added to each value of ``AXISNAME`` would agree with the + corresponding values of ``AXISNAME_end``, but there is a possibility of significant + differences. Use of ``AXISNAME_end`` is recommended. + + + + + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + + + \ No newline at end of file diff --git a/base_classes/NXuser.nxdl.xml b/base_classes/NXuser.nxdl.xml index bf41e6d3c3..e014584c2b 100644 --- a/base_classes/NXuser.nxdl.xml +++ b/base_classes/NXuser.nxdl.xml @@ -1,10 +1,10 @@ - - + + - - - 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. - - - - Name of user responsible for this entry - - - - - Role of user responsible for this entry. - Suggested roles are "local_contact", - "principal_investigator", and "proposer" - - - - - Affiliation of user - - - - - Address of user - - - - - Telephone number of user - - - - - Fax number of user - - - - - Email of user - - - - - facility based unique identifier for this person - e.g. their identification code on the facility - address/contact database - - - + + + 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. + + + Name of user responsible for this entry + + + + Role of user responsible for this entry. + Suggested roles are "local_contact", + "principal_investigator", and "proposer" + + + + Affiliation of user + + + Address of user + + + Telephone number of user + + + Fax number of user + + + Email of user + + + + facility based unique identifier for this person + e.g. their identification code on the facility + address/contact database + + + Details about an author code, open researcher, or contributor (persistent) identifier, e.g. defined by https://orcid.org and expressed @@ -83,15 +75,15 @@ - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. - + \ No newline at end of file diff --git a/base_classes/nyaml/NXaperture.yaml b/base_classes/nyaml/NXaperture.yaml index a58f96e4e3..dd6994bf4f 100644 --- a/base_classes/nyaml/NXaperture.yaml +++ b/base_classes/nyaml/NXaperture.yaml @@ -88,11 +88,11 @@ NXaperture(NXobject): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ # ddea515e1df1292df2a7176d04f026a04c9eef91abb7173bcbe25fa0e01a6a12 # -# +# # # # -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# The reference point of the aperture is its center in the x and y axis. The reference point on the z axis is the -# surface of the aperture pointing towards the source. -# -# In complex (asymmetric) geometries an NXoff_geometry group can be used to provide an unambiguous reference. -# -# .. image:: aperture/aperture.png -# :width: 40% -# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# The reference point of the aperture is its center in the x and y axis. The reference point on the z axis is the +# surface of the aperture pointing towards the source. +# +# In complex (asymmetric) geometries an NXoff_geometry group can be used to provide an unambiguous reference. +# +# .. image:: aperture/aperture.png +# :width: 40% +# # # -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# +# +# 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. +# # # # @@ -160,32 +160,26 @@ NXaperture(NXobject): # # # -# location and shape of aperture -# -# .. TODO: documentation needs improvement, contributions welcome -# -# * description of terms is poor and leaves much to interpretation -# * Describe what is meant by translation _here_ and ... -# * Similar throughout base classes -# * Some base classes do this much better -# * Such as where is the gap written? +# location and shape of aperture +# +# .. TODO: documentation needs improvement, contributions welcome +# +# * description of terms is poor and leaves much to interpretation +# * Describe what is meant by translation _here_ and ... +# * Similar throughout base classes +# * Some base classes do this much better +# * Such as where is the gap written? +# # # # -# -# location and shape of each blade -# +# location and shape of each blade # -# -# -# -# Absorbing material of the aperture -# +# +# Absorbing material of the aperture # # -# -# Description of aperture -# +# Description of aperture # # # @@ -213,15 +207,15 @@ NXaperture(NXobject): # describe any additional information in a note # # -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. # # # diff --git a/base_classes/nyaml/NXbeam.yaml b/base_classes/nyaml/NXbeam.yaml index c58bdf9df1..8f66fd0c49 100644 --- a/base_classes/nyaml/NXbeam.yaml +++ b/base_classes/nyaml/NXbeam.yaml @@ -330,6 +330,13 @@ NXbeam(NXobject): unit: NX_TIME doc: | Group delay dispersion of the pulse for linear chirp + previous_device: + doc: | + Indicates the beam device from which this beam originates. + This defines, whether the beam in an "input" or "output" beam. + next_device: + doc: | + Gives the beam device which this beam will interact with next. (NXdata): doc: | Distribution of beam with respect to relevant variable e.g. wavelength. This is mainly @@ -403,18 +410,11 @@ NXbeam(NXobject): doc: | Points to the path to a field defining the location on which this depends or the string "." for origin. - previous_device: - doc: | - Indicates the beam device from which this beam originates. - This defines, whether the beam in an "input" or "output" beam. - next_device: - doc: | - Gives the beam device which this beam will interact with next. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4b4f97c455cbb96d280eefb201602589458158a8a9d078fa6820cb67f99cdb67 -# -# +# 0a0f638a0e365626f010fb2bb8978aa3675f952b03f7bb56b5821155e8a66916 +# +# # -# +# # # -# These symbols coordinate datasets with the same shape. +# These symbols coordinate datasets with the same shape. # # -# -# Number of scan points. -# +# Number of scan points. # # -# -# Number of channels in the incident beam spectrum, if known -# +# Number of channels in the incident beam spectrum, if known # # -# -# Number of moments representing beam divergence (x, y, xy, etc.) -# +# Number of moments representing beam divergence (x, y, xy, etc.) # # # -# 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. -# -# -# -# Distance from sample. Note, it is recommended to use NXtransformations instead. +# 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. # +# +# Distance from sample. Note, it is recommended to use NXtransformations instead. # # # -# Energy carried by each particle of the beam on entering the beamline component. -# -# In the case of a monochromatic beam this is the scalar energy. -# Several other use cases are permitted, depending on the -# presence of other incident_energy_X fields. -# -# * In the case of a polychromatic beam this is an array of length m of energies, with the relative weights in incident_energy_weights. -# * In the case of a monochromatic beam that varies shot-to-shot, this is an array of energies, one for each recorded shot. -# Here, incident_energy_weights and incident_energy_spread are not set. -# * In the case of a polychromatic beam that varies shot-to-shot, -# this is an array of length m with the relative weights in incident_energy_weights as a 2D array. -# * In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, -# this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_energy_weights as a 2D array. -# -# Note, variants are a good way to represent several of these use cases in a single dataset, -# e.g. if a calibrated, single-value energy value is available along with the original spectrum from which it was calibrated. -# +# Energy carried by each particle of the beam on entering the beamline component. +# +# 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. +# # # # @@ -520,78 +516,74 @@ NXbeam(NXobject): # # # -# -# Energy carried by each particle of the beam on leaving the beamline component -# +# Energy carried by each particle of the beam on leaving the beamline component # # # # # -# -# Change in particle energy caused by the beamline component -# +# Change in particle energy caused by the 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 <Design-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 <Design-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 polychromatic beam this is an array of -# length **m** of the relative weights of the corresponding -# wavelengths in ``incident_wavelength``. -# -# In the case of a polychromatic beam that varies shot-to- -# shot, this is a 2D array of dimensions **nP** by **m** -# (slow to fast) of the relative weights of the -# corresponding wavelengths in ``incident_wavelength``. +# In the case of a polychromatic beam this is an array of +# length **m** of the relative weights of the corresponding +# wavelengths in ``incident_wavelength``. +# +# In the case of a polychromatic beam that varies shot-to- +# shot, this is a 2D array of dimensions **nP** by **m** +# (slow to fast) of the relative weights of the +# corresponding wavelengths in ``incident_wavelength``. # # # # -# The wavelength spread FWHM for the corresponding -# wavelength(s) in incident_wavelength. -# -# In the case of shot-to-shot variation in the wavelength -# spread, this is a 2D array of dimension **nP** by -# **m** (slow to fast) of the spreads of the -# corresponding wavelengths in incident_wavelength. +# The wavelength spread FWHM for the corresponding +# wavelength(s) in incident_wavelength. +# +# In the case of shot-to-shot variation in the wavelength +# spread, this is a 2D array of dimension **nP** by +# **m** (slow to fast) of the spreads of the +# corresponding wavelengths in incident_wavelength. # # # @@ -599,15 +591,15 @@ NXbeam(NXobject): # # # -# Beam crossfire in degrees parallel to the laboratory X axis -# -# The dimension **c** is a series of moments of that represent -# the standard uncertainty (e.s.d.) of the directions of -# of the beam. The first and second moments are in the XZ and YZ -# planes around the mean source beam direction, respectively. -# -# Further moments in **c** characterize co-variance terms, so -# the next moment is the product of the first two, and so on. +# Beam crossfire in degrees parallel to the laboratory X axis +# +# The dimension **c** is a series of moments of that represent +# the standard uncertainty (e.s.d.) of the directions of +# of the beam. The first and second moments are in the XZ and YZ +# planes around the mean source beam direction, respectively. +# +# Further moments in **c** characterize co-variance terms, so +# the next moment is the product of the first two, and so on. # # # @@ -616,10 +608,10 @@ NXbeam(NXobject): # # # -# Size of the beam entering this component. Note this represents -# a rectangular beam aperture, and values represent FWHM. -# If applicable, the first dimension shall be the horizontal extent -# and the second dimension shall be the vertical extent. +# Size of the beam entering this component. Note this represents +# a rectangular beam aperture, and values represent FWHM. +# If applicable, the first dimension shall be the horizontal extent +# and the second dimension shall be the vertical extent. # # # @@ -627,17 +619,13 @@ NXbeam(NXobject): # # # -# -# Wavelength on leaving beamline component -# +# Wavelength on leaving beamline component # # # # # -# -# Polarization vector on entering beamline component -# +# Polarization vector on entering beamline component # # # @@ -662,9 +650,7 @@ NXbeam(NXobject): # # # -# -# Polarization vector on leaving beamline component -# +# Polarization vector on leaving beamline component # # # @@ -691,25 +677,25 @@ NXbeam(NXobject): # # # Polarization vector on entering beamline component using Stokes notation -# +# # The Stokes parameters are four components labelled I,Q,U,V or S_0,S_1,S_2,S_3. # These are defined with the standard Nexus coordinate frame unless it is # overridden by an NXtransformations field pointed to by a depends_on attribute. # The last component, describing the circular polarization state, is positive # for a right-hand circular state - that is the electric field vector rotates # clockwise at the sample and over time when observed from the source. -# -# I (S_0) is the beam intensity (often normalized to 1). Q, U, and V scale +# +# I (S_0) is the beam intensity (often normalized to 1). Q, U, and V scale # linearly with the total degree of polarization, and indicate the relative # magnitudes of the pure linear and circular orientation contributions. # # Q (S_1) is linearly polarized along the x axis (Q > 0) or y axis (Q < 0). # # U (S_2) is linearly polarized along the x==y axis (U > 0) or the -# -x==y axis (U < 0). -# +# -x==y axis (U < 0). +# # V (S_3) is circularly polarized. V > 0 when the electric field vector rotates -# clockwise at the sample with respect to time when observed from the source; +# clockwise at the sample with respect to time when observed from the source; # V < 0 indicates the opposite rotation. # # @@ -728,26 +714,20 @@ NXbeam(NXobject): # # # -# -# Wavelength spread FWHM of beam leaving this component -# +# Wavelength spread FWHM of beam leaving this component # # # # # -# -# Divergence FWHM of beam leaving this component -# +# Divergence FWHM of beam leaving this component # # # # # # -# -# flux incident on beam plane area -# +# flux incident on beam plane area # # # @@ -822,106 +802,107 @@ NXbeam(NXobject): # Group delay dispersion of the pulse for linear chirp # # -# +# # -# Distribution of beam with respect to relevant variable e.g. wavelength. This is mainly -# useful for simulations which need to store plottable information at each beamline -# component. +# Indicates the beam device from which this beam originates. +# This defines, whether the beam in an "input" or "output" beam. # +# +# +# +# Gives the beam device which this beam will interact with next. +# +# +# +# +# Distribution of beam with respect to relevant variable e.g. wavelength. This is mainly +# useful for simulations which need to store plottable information at each beamline +# component. # # # -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. # # -# +# +# # -# The NeXus coordinate system defines the Z axis to be along the nominal beam -# direction. This is the same as the McStas coordinate system (see :ref:`Design-CoordinateSystem`). -# However, the additional transformations needed to represent an altered beam -# direction can be provided using this depends_on field that contains the path -# to a NXtransformations group. This could represent redirection of the beam, -# or a refined beam direction. +# The NeXus coordinate system defines the Z axis to be along the nominal beam +# direction. This is the same as the McStas coordinate system (see :ref:`Design-CoordinateSystem`). +# However, the additional transformations needed to represent an altered beam +# direction can be provided using this depends_on field that contains the path +# to a NXtransformations group. This could represent redirection of the beam, +# or a refined beam direction. # # +# # # -# Direction (and location) for the beam. The location of the beam can be given by -# any point which it passes through as its offset attribute. +# Direction (and location) for the beam. The location of the beam can be given by +# any point which it passes through as its offset attribute. # -# +# # -# Direction of beam vector, its value is ignored. If missing, then the beam direction is defined as [0,0,1] -# and passes through the origin +# Direction of beam vector, its value is ignored. If missing, then the beam direction is defined as [0,0,1] +# and passes through the origin # # # -# +# # # # # -# Three values that define the direction of beam vector +# Three values that define the direction of beam vector # # # # -# Three values that define the location of a point through which the beam passes +# Three values that define the location of a point through which the beam passes # # # # -# Points to the path to a field defining the location on which this -# depends or the string "." for origin. +# Points to the path to a field defining the location on which this +# depends or the string "." for origin. # # # -# +# # -# Direction of normal to reference plane used to measure azimuth relative to the beam, its value is ignored. -# This also defines the parallel and perpendicular components of the beam's polarization. -# If missing, then the reference plane normal is defined as [0,1,0] and passes through the origin +# Direction of normal to reference plane used to measure azimuth relative to the beam, its value is ignored. +# This also defines the parallel and perpendicular components of the beam's polarization. +# If missing, then the reference plane normal is defined as [0,1,0] and passes through the origin # # # -# +# # # # # -# Three values that define the direction of reference plane normal +# Three values that define the direction of reference plane normal # # # # -# Not required as beam direction offset locates the plane +# Not required as beam direction offset locates the plane # # # # -# Points to the path to a field defining the location on which this -# depends or the string "." for origin. +# Points to the path to a field defining the location on which this +# depends or the string "." for origin. # # # # -# -# -# Indicates the beam device from which this beam originates. -# This defines, whether the beam in an "input" or "output" beam. -# -# -# -# -# Gives the beam device which this beam will interact with next. -# -# -# +# \ No newline at end of file diff --git a/base_classes/nyaml/NXdata.yaml b/base_classes/nyaml/NXdata.yaml index b7c31794c5..fdb379861d 100644 --- a/base_classes/nyaml/NXdata.yaml +++ b/base_classes/nyaml/NXdata.yaml @@ -1,114 +1,186 @@ category: base doc: | - :ref:`NXdata` describes the plottable data and related dimension scales. + The :ref:`NXdata` class is designed to encapsulate all the information required for a set of data to be plotted. + NXdata groups contain plottable data (sometimes referred to as *signals* or *dependent variables*) and their + associated axis coordinates (sometimes referred to as *axes* or *independent variables*). + + The actual names of the :ref:`DATA ` and :ref:`AXISNAME ` fields + can be chosen :ref:`freely `, as indicated by the upper case (this is a common convention in all NeXus classes). + + .. note:: ``NXdata`` provides data and coordinates to be plotted but + does not describe how the data is to be plotted or even the dimensionality of the plot. + https://www.nexusformat.org/NIAC2018Minutes.html#nxdata-plottype--attribute + + **Signals:** .. 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 :ref:`DATA ` fields contain the signal values to be plotted. The name of the field + to be used as the *default plot signal* is provided by the :ref:`signal ` attribute. + The names of the fields to be used as *secondary plot signals* are provided by the + :ref:`auxiliary_signals` attribute. - * The group ``axes`` attribute will name the - *dimension scale* associated with the plottable data. + An example with three signals, one of which being the default - 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``. + .. code-block:: + + data:NXdata + @signal = "data1" + @auxiliary_signals = ["data2", "data3"] + data1: float[10,20,30] --> the default signal + data2: float[10,20,30] + data3: float[10,20,30] - * 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. + **Axes:** - .. index:: link .. index:: axes (attribute) + .. index:: coordinates + + The :ref:`AXISNAME ` fields contain the axis coordinates associated with the data values. + The names of all :ref:`AXISNAME ` fields are listed in the + :ref:`axes ` attribute. + + `Rank` + + :ref:`AXISNAME ` fields are typically one-dimensional arrays, which annotate one of the dimensions. + + An example of this would be + + .. code-block:: + + data:NXdata + @signal = "data" + @axes = ["x", "y"] --> the order matters + data: float[10,20] + x: float[10] --> coordinates along the first dimension + y: float[20] --> coordinates along the second dimension + + In this example each data point ``data[i,j]`` has axis coordinates ``[x[i], y[j]]``. + + However, the fields can also have a rank greater than 1, in which case the rank of each + :ref:`AXISNAME ` must be equal to the number of data dimensions it spans. + + An example of this would be + + .. code-block:: + + data:NXdata + @signal = "data" + @axes = ["x", "y"] --> the order does NOT matter + @x_indices = [0, 1] + @y_indices = [0, 1] + data: float[10,20] + x: float[10,20] --> coordinates along both dimensions + y: float[10,20] --> coordinates along both dimensions + + In this example each data point ``data[i,j]`` has axis coordinates ``[x[i,j], y[i,j]]``. + + `Dimensions` + + The data dimensions annotated by an :ref:`AXISNAME ` field are defined by the + :ref:`AXISNAME_indices ` attribute. When this attribute is missing, + the position(s) of the :ref:`AXISNAME ` string in the + :ref:`axes ` attribute are used. + + When all :ref:`AXISNAME ` fields are one-dimensional, and none of the data dimensions + have more than one axis, the :ref:`AXISNAME_indices ` attributes + are often omitted. If one of the data dimensions has no :ref:`AXISNAME ` field, + the string “.” can be used in the corresponding index of the axes list. + + An example of this would be + + .. code-block:: + + data:NXdata + @signal = "data" + @axes = ["x", ".", "z"] --> the order matters + data: float[10,20,30] + x: float[10] --> coordinates along the first dimension + z: float[30] --> coordinates along the third dimension + + When using :ref:`AXISNAME_indices ` this becomes - 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) + .. code-block:: + + data:NXdata + @signal = "data" + @axes = ["x", "z"] --> the order does NOT matter + data: float[10,20,30] + @x_indices = 0 + @z_indices = 2 + x: float[10] --> coordinates along the first dimension + z: float[30] --> coordinates along the third dimension + + When providing :ref:`AXISNAME_indices ` attributes it is recommended + to do it for all axes. + + `Non-trivial axes` + + What follows are two examples where :ref:`AXISNAME_indices ` attributes + cannot be omitted. + + The first is an example where data dimensions have alternative axis coordinates. The NXdata group represents + a stack of images collected at different energies. The ``wavelength`` is an alternative axis of ``energy`` + for the last dimension (or vice versa). + + .. code-block:: + + data:NXdata + @signal = "data" + @axes = ["x", "y", "energy", "wavelength"] --> the order does NOT matter + @x_indices = 0 + @y_indices = 1 + @energy_indices = 2 + @wavelength_indices = 2 + data: float[10,20,30] + x: float[10] --> coordinates along the first dimension + y: float[20] --> coordinates along the second dimension + energy: float[30] --> coordinates along the third dimension + wavelength: float[30] --> coordinates along the third dimension + + The second is an example with coordinates that span more than one dimension. The NXdata group represents data + from 2D mesh scans performed at multiple energies. Each data point ``data[i,j,k]`` has axis coordinates + ``[x[i,j,k], y[i,j,k], energy[k]]``. + + .. code-block:: + + data:NXdata + @signal = "data" + @axes = ["x", "y", "energy"] --> the order does NOT matter + @x_indices = [0, 1, 2] + @y_indices = [0, 1, 2] + @energy_indices = 2 + data: float[10,20,30] + x: float[10,20,30] --> coordinates along all dimensions + y: float[10,20,30] --> coordinates along all dimensions + energy: float[30] --> coordinates along the third dimension + + **Uncertainties:** + + Standard deviations on data values as well as coordinates can be provided by + :ref:`FIELDNAME_errors ` fields where ``FIELDNAME`` is the name of a + :ref:`DATA ` field or an :ref:`AXISNAME ` field. + + An example of uncertainties on the signal, auxiliary signals and axis coordinates + + .. code-block:: + + data:NXdata + @signal = "data1" + @auxiliary_signals = ["data2", "data3"] + @axes = ["x", "z"] + @x_indices = 0 + @z_indices = 2 + data1: float[10,20,30] + data2: float[10,20,30] + data3: float[10,20,30] + x: float[10] + z: float[30] + data1_errors: float[10,20,30] + data2_errors: float[10,20,30] + data3_errors: float[10,20,30] + x_errors: float[10] + z_errors: float[30] # The ignoreExtra* attributes are used in the definition to # avoid warning messages that would be generated from unexpected fields or attributes. @@ -117,12 +189,9 @@ doc: | # without this attribute being set to "true". symbols: doc: | - These symbols will be used below to coordinate fields with the same - shape. + These symbols will be used below to coordinate fields with the same shape. dataRank: | - rank of the ``DATA`` field - n: | - length of the ``AXISNAME`` field + rank of the ``DATA`` field(s) nx: | length of the ``x`` field ny: | @@ -133,66 +202,77 @@ type: group ignoreExtraFields: true ignoreExtraAttributes: true NXdata(NXobject): - \@auxiliary_signals: - doc: | - .. index:: plotting - - Array of strings holding the :ref:`names ` of additional - signals to be plotted with the default :ref:`signal `. - These fields or links *must* exist and be direct children of this NXdata group. - - Each auxiliary signal needs to be of the same shape as the default signal. - - .. NIAC2018: - https://www.nexusformat.org/NIAC2018Minutes.html + + # Attributes for data and coordinate field detection \@signal: doc: | .. 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. + The value is the :ref:`name ` of the signal that contains + the default plottable data. 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. - \@axes: + \@auxiliary_signals: doc: | .. 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 `. + Array of strings holding the :ref:`names ` of additional + signals to be plotted with the :ref:`default signal `. + These fields or links *must* exist and be direct children of this NXdata group. - One name is provided for every dimension in the *signal* or *auxiliary signal* fields. + Each auxiliary signal needs to be of the same shape as the default signal. - The *axes* values are the names of fields or links that *must* exist and be direct - children of this NXdata group. + .. NIAC2018: + https://www.nexusformat.org/NIAC2018Minutes.html + \@default_slice: + type: NX_CHAR_OR_NUMBER + doc: | + Which slice of data to show in a plot by default. This is useful especially for + datasets with more than 2 dimensions. - 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). + Should be an array of length equal to the number of dimensions + in the data, with the following possible values: - When no default axis is available for a particular dimension - of the plottable data, use a "." in that position. - Such as:: + * ".": All the data in this dimension should be included + * Integer: Only this slice should be used. + * String: Only this slice should be used. Use if ``AXISNAME`` is a string + array. - @axes=["time", ".", "."] + Example:: - 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. + data:NXdata + @signal = "data" + @axes = ["image_id", "channel", ".", "."] + @image_id_indices = 0 + @channel_indices = 1 + @default_slice = [".", "difference", ".", "."] + image_id = [1, ..., nP] + channel = ["threshold_1", "threshold_2", "difference"] + data = uint[nP, nC, i, j] - See examples provided on the NeXus wiki: - https://www.nexusformat.org/2014_axes_and_uncertainties.html + Here, a data array with four dimensions, including the number of images + (nP) and number of channels (nC), specifies more dimensions than can be + visualized with a 2D image viewer for a given image. Therefore the + default_slice attribute specifies that the "difference" channel should be + shown by default. - If there are no axes at all (such as with a stack of images), - the axes attribute can be omitted. + Alternate version using an integer would look like this (note 2 is a string):: + + data:NXdata + @signal = "data" + @axes = ["image_id", "channel", ".", "."] + @image_id_indices = 0 + @channel_indices = 1 + @default_slice = [".", "2", ".", "."] + image_id = [1, ..., nP] + channel = ["threshold_1", "threshold_2", "difference"] + data = uint[nP, nC, i, j] \@reference: doc: | Points to the path of a field defining the data to which the `DATA` group refers. @@ -213,59 +293,44 @@ NXdata(NXobject): # AXISNAME_indices documentation copied from datarules.rst doc: | - Each ``AXISNAME_indices`` attribute indicates the dependency - relationship of the ``AXISNAME`` field (where ``AXISNAME`` - is the name of a field that exists in this ``NXdata`` group) - with one or more dimensions of the plottable data. - - Integer array that defines the indices of the *signal* field - (that field will be a multidimensional array) - which need to be used in the *AXISNAME* field in - order to reference the corresponding axis value. - - The first index of an array is ``0`` (zero). - - Here, *AXISNAME* is to be replaced by the name of each - field described in the ``axes`` attribute. - An example with 2-D data, :math:`d(t,P)`, will illustrate:: - - data_2d:NXdata - @signal="data" - @axes=["time", "pressure"] - @time_indices=0 - @pressure_indices=1 - data: float[1000,20] - time: float[1000] - pressure: float[20] - - This attribute is to be provided in all situations. - However, if the indices attributes are missing - (such as for data files written before this specification), - file readers are encouraged to make their best efforts - to plot the data. - Thus the implementation of the - ``AXISNAME_indices`` attribute is based on the model of - "strict writer, liberal reader". - - .. note:: Attributes potentially containing multiple values - (axes and _indices) are to be written as string or integer arrays, - to avoid string parsing in reading applications. - AXISNAME(NX_NUMBER): + The ``AXISNAME_indices`` attribute is a single integer or an array of integers that defines which :ref:`data ` + dimension(s) are spanned by the corresponding axis. The first dimension index is ``0`` (zero). + + When the ``AXISNAME_indices`` attribute is missing for an :ref:`AXISNAME ` field, its value becomes the index + (or indices) of the :ref:`AXISNAME ` name in the :ref:`axes ` attribute. + + .. note:: When ``AXISNAME_indices`` contains multiple integers, it must be saved as an actual array + of integers and not a comma separated string. + \@axes: + doc: | + .. index:: plotting + + The ``axes`` attribute is a list of strings which are the names of the :ref:`AXISNAME ` fields + that contain the values of the coordinates along the :ref:`data ` dimensions. + + .. note:: When ``axes`` contains multiple strings, it must be saved as an actual array + of strings and not a single comma separated string. + + # Data and coordinate fields + AXISNAME(NX_CHAR_OR_NUMBER): nameType: any doc: | - 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. - dimensions: - rank: 1 - doc: | - A *dimension scale* must have a rank of 1 and has length ``n``. - dim: [[1, n]] + Coordinate values along one or more :ref:`data ` dimensions. The rank must be equal + to the number of dimensions it spans. + + As the upper case ``AXISNAME`` indicates, the names of the ``AXISNAME`` fields can be chosen :ref:`freely `. + The :ref:`axes ` attribute can be used to find all datasets in the + ``NXdata`` that contain coordinate values. + + Most AXISNAME fields will be sequences of numbers but if an axis is better represented using names, such as channel names, + an array of NX_CHAR can be provided. \@long_name: doc: | Axis label + \@units: + doc: | + Unit in which the coordinate values are expressed. + See the section :ref:`Design-Units` for more information. \@distribution: type: NX_BOOLEAN doc: | @@ -286,56 +351,46 @@ NXdata(NXobject): Index (positive integer) identifying this specific set of numbers. N.B. The ``axis`` attribute is the old way of designating a link. - Do not use the ``axes`` attribute with the ``axis`` attribute. - The ``axes`` *group* attribute is now preferred. + Do not use the :ref:`axes ` attribute with the ``axis`` attribute. + The :ref:`axes ` attribute is now preferred. \@reference: doc: | Points to the path of a field defining the axis to which the ``AXISNAME`` axis refers. - + This concept allows to link an axis to a respective field in the NeXus hierarchy, thereby defining the physical quantity it represents. - + Examples: If a calibration has been performed, ``@reference`` links to the result of that calibration: - + @reference: '/entry/process/calibration/calibrated_axis' - + If the axis corresponds to a coordinate of a detector, ``@reference`` links to that detector axis: - + @reference: '/entry/instrument/detector/axis/some_axis' for a 2D detector - + If the axis is a scanned motor, ``@reference`` links to the transformation describing the respective motion, e.g.: - + @reference: '/entry/instrument/detector/transformations/some_transformation' for a motion of the detector - FIELDNAME_errors(NX_NUMBER): - nameType: any - doc: | - "Errors" (meaning *uncertainties* or *standard deviations*) - associated with any field named ``FIELDNAME`` in this ``NXdata`` - group (e.g. an axis, signal or auxiliary signal). - - The dimensions of the ``FIELDNAME_errors`` field must match - the dimensions of the ``FIELDNAME`` field. DATA(NX_NUMBER): nameType: any doc: | .. 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. + Data values to be used as the NeXus *plottable data*. As the upper case ``DATA`` + indicates, the names of the ``DATA`` fields can be chosen :ref:`freely `. The :ref:`signal attribute ` + and :ref:`auxiliary_signals attribute` can be used to find all datasets in the ``NXdata`` + that contain data values. + + The maximum rank is ``32`` for compatibility with backend file formats. dimensions: rank: dataRank doc: | The rank (``dataRank``) of the ``data`` must satisfy ``1 <= dataRank <= NX_MAXRANK=32``. - At least one ``dim`` must have length ``n``. dim: [] \@signal: type: NX_POSINT @@ -350,30 +405,39 @@ NXdata(NXobject): \@axes: deprecated: Use the group ``axes`` attribute (NIAC2014) doc: | - Defines the names of the dimension scales + Defines the names of the coordinates (independent axes) for this data set as a colon-delimited array. - NOTE: The ``axes`` attribute is the preferred + NOTE: The :ref:`axes ` attribute is the preferred method of designating a link. - Do not use the ``axes`` attribute with the ``axis`` attribute. + Do not use the :ref:`axes ` attribute with the ``axis`` attribute. \@long_name: doc: | data label \@reference: doc: | Points to the path of a field defining the data to which the `DATA` field refers. - + This concept allows to link the data to a respective field in the NeXus hierarchy, thereby defining the physical quantity it represents. - + Here, *DATA* is to be replaced by the name of each data field. - + Example: If the data corresponds to a readout of a detector, ``@reference`` links to that detectors data: - + @reference: '/entry/instrument/detector/data' for a 2D detector + FIELDNAME_errors(NX_NUMBER): + nameType: any + doc: | + "Errors" (meaning *uncertainties* or *standard deviations*) + associated with any field named ``FIELDNAME`` in this ``NXdata`` + group (e.g. an axis, signal or auxiliary signal). + + The dimensions of the ``FIELDNAME_errors`` field must match + the dimensions of the ``FIELDNAME`` field. errors(NX_NUMBER): deprecated: Use ``DATA_errors`` instead (NIAC2018) doc: | @@ -384,29 +448,67 @@ NXdata(NXobject): dimensions: rank: dataRank doc: | - The ``errors`` must have - the same rank (``dataRank``) + The ``errors`` must have the same rank (``dataRank``) as the ``data``. - At least one ``dim`` must have length "n". dim: [] + + # Data vs. plot coordinates + FIELDNAME_scaling_factor(NX_NUMBER): + doc: | + An optional scaling factor to apply to the values in any field named ``FIELDNAME`` + in this ``NXdata`` group. This can be a :ref:`DATA ` field + (signal or auxiliary signal) or a :ref:`AXISNAME ` + field (axis). + + The elements stored in NXdata datasets are often stored as integers for efficiency + reasons and need further correction or conversion, generating floats. For example, + raw values could be stored from a device that need to be converted to values that + represent the physical values. The two fields FIELDNAME_scaling_factor and + FIELDNAME_offset allow linear corrections using the following convention: + + .. code-block:: + + corrected values = (FIELDNAME + offset) * scaling_factor + + This formula will derive the values to use in downstream applications, when necessary. + + When omitted, the scaling factor is assumed to be 1. + FIELDNAME_offset(NX_NUMBER): + doc: | + An optional offset to apply to the values in FIELDNAME (usually the signal). + + When omitted, the offset is assumed to be 0. + + See :ref:`FIELDNAME_scaling_factor ` for more information. scaling_factor(NX_FLOAT): + deprecated: Use FIELDNAME_scaling_factor instead doc: | - The elements in data are usually float values really. For - efficiency reasons these are usually stored as integers - after scaling with a scale factor. This value is the scale - factor. It is required to get the actual physical value, - when necessary. + The scaling_factor and FIELDNAME_scaling_factor fields have similar semantics. + However, scaling_factor is ambiguous in the case of multiple signals. Therefore + scaling_factor is deprecated. Use FIELDNAME_scaling_factor instead, even when + only a single signal is present. offset(NX_FLOAT): + deprecated: Use FIELDNAME_offset instead doc: | - An optional offset to apply to the values in data. + The offset and FIELDNAME_offset fields have similar semantics. + However, offset is ambiguous in the case of multiple signals. Therefore + offset is deprecated. Use FIELDNAME_offset instead, even when + only a single signal is present. + + # Other fields title: doc: | Title for the plot. + + # Deprecated fields x(NX_FLOAT): unit: NX_ANY doc: | This is an array holding the values to use for the x-axis of - data. The units must be appropriate for the measurement. + data. The units must be appropriate for the measurement. + + This is a special case of a :ref:`AXISNAME field ` + kept for backward compatiblity. dimensions: rank: 1 dim: [[1, nx]] @@ -414,7 +516,10 @@ NXdata(NXobject): unit: NX_ANY doc: | This is an array holding the values to use for the y-axis of - data. The units must be appropriate for the measurement. + data. The units must be appropriate for the measurement. + + This is a special case of a :ref:`AXISNAME field ` + kept for backward compatiblity. dimensions: rank: 1 dim: [[1, ny]] @@ -422,15 +527,18 @@ NXdata(NXobject): unit: NX_ANY doc: | This is an array holding the values to use for the z-axis of - data. The units must be appropriate for the measurement. + data. The units must be appropriate for the measurement. + + This is a special case of a :ref:`AXISNAME field ` + kept for backward compatiblity. dimensions: rank: 1 dim: [[1, nz]] # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4a111f75645f997c122de9d2badd68f6bc5bedfbc69febc5aabd6f481169dcba -# -# +# d23365528998adfba29a8102929213b777f0dbbf6cb37768577aa3c886c715cb +# +# # -# -# -# -# -# These symbols will be used below to coordinate fields with the same -# shape. -# -# -# -# rank of the ``DATA`` field -# -# -# -# -# length of the ``AXISNAME`` field -# -# -# -# -# length of the ``x`` field -# -# -# -# -# length of the ``y`` field -# -# -# -# -# length of the ``z`` field -# -# -# -# -# :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) -# -# -# -# .. index:: plotting -# -# Array of strings holding the :ref:`names <validItemName>` of additional -# signals to be plotted with the default :ref:`signal </NXdata@signal-attribute>`. -# These fields or links *must* exist and be direct children of this NXdata group. -# -# Each auxiliary signal needs to be of the same shape as the default signal. -# -# .. NIAC2018: -# https://www.nexusformat.org/NIAC2018Minutes.html -# -# -# -# -# .. 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 <validItemName>` 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. -# -# -# -# -# .. index:: plotting -# -# Array of strings holding the :ref:`names <validItemName>` of -# the independent data fields used in the default plot for all of -# the dimensions of the :ref:`signal </NXdata@signal-attribute>` -# as well as any :ref:`auxiliary signals </NXdata@auxiliary_signals-attribute>`. -# -# 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. -# -# +# +# +# +# +# +# These symbols will be used below to coordinate fields with the same shape. +# rank of the ``DATA`` field(s) +# length of the ``x`` field +# length of the ``y`` field +# length of the ``z`` field +# +# +# +# The :ref:`NXdata` class is designed to encapsulate all the information required for a set of data to be plotted. +# NXdata groups contain plottable data (sometimes referred to as *signals* or *dependent variables*) and their +# associated axis coordinates (sometimes referred to as *axes* or *independent variables*). +# +# The actual names of the :ref:`DATA </NXdata/DATA-field>` and :ref:`AXISNAME </NXdata/AXISNAME-field>` fields +# can be chosen :ref:`freely <validItemName>`, as indicated by the upper case (this is a common convention in all NeXus classes). +# +# .. note:: ``NXdata`` provides data and coordinates to be plotted but +# does not describe how the data is to be plotted or even the dimensionality of the plot. +# https://www.nexusformat.org/NIAC2018Minutes.html#nxdata-plottype--attribute +# +# **Signals:** +# +# .. index:: plotting +# +# The :ref:`DATA </NXdata/DATA-field>` fields contain the signal values to be plotted. The name of the field +# to be used as the *default plot signal* is provided by the :ref:`signal </NXdata@signal-attribute>` attribute. +# The names of the fields to be used as *secondary plot signals* are provided by the +# :ref:`auxiliary_signals</NXdata@auxiliary_signals-attribute>` attribute. +# +# An example with three signals, one of which being the default +# +# .. code-block:: +# +# data:NXdata +# @signal = "data1" +# @auxiliary_signals = ["data2", "data3"] +# data1: float[10,20,30] --> the default signal +# data2: float[10,20,30] +# data3: float[10,20,30] +# +# **Axes:** +# +# .. index:: axes (attribute) +# .. index:: coordinates +# +# The :ref:`AXISNAME </NXdata/AXISNAME-field>` fields contain the axis coordinates associated with the data values. +# The names of all :ref:`AXISNAME </NXdata/AXISNAME-field>` fields are listed in the +# :ref:`axes </NXdata@axes-attribute>` attribute. +# +# `Rank` +# +# :ref:`AXISNAME </NXdata/AXISNAME-field>` fields are typically one-dimensional arrays, which annotate one of the dimensions. +# +# An example of this would be +# +# .. code-block:: +# +# data:NXdata +# @signal = "data" +# @axes = ["x", "y"] --> the order matters +# data: float[10,20] +# x: float[10] --> coordinates along the first dimension +# y: float[20] --> coordinates along the second dimension +# +# In this example each data point ``data[i,j]`` has axis coordinates ``[x[i], y[j]]``. +# +# However, the fields can also have a rank greater than 1, in which case the rank of each +# :ref:`AXISNAME </NXdata/AXISNAME-field>` must be equal to the number of data dimensions it spans. +# +# An example of this would be +# +# .. code-block:: +# +# data:NXdata +# @signal = "data" +# @axes = ["x", "y"] --> the order does NOT matter +# @x_indices = [0, 1] +# @y_indices = [0, 1] +# data: float[10,20] +# x: float[10,20] --> coordinates along both dimensions +# y: float[10,20] --> coordinates along both dimensions +# +# In this example each data point ``data[i,j]`` has axis coordinates ``[x[i,j], y[i,j]]``. +# +# `Dimensions` +# +# The data dimensions annotated by an :ref:`AXISNAME </NXdata/AXISNAME-field>` field are defined by the +# :ref:`AXISNAME_indices </NXdata@AXISNAME_indices-attribute>` attribute. When this attribute is missing, +# the position(s) of the :ref:`AXISNAME </NXdata/AXISNAME-field>` string in the +# :ref:`axes </NXdata@axes-attribute>` attribute are used. +# +# When all :ref:`AXISNAME </NXdata/AXISNAME-field>` fields are one-dimensional, and none of the data dimensions +# have more than one axis, the :ref:`AXISNAME_indices </NXdata@AXISNAME_indices-attribute>` attributes +# are often omitted. If one of the data dimensions has no :ref:`AXISNAME </NXdata/AXISNAME-field>` field, +# the string “.” can be used in the corresponding index of the axes list. +# +# An example of this would be +# +# .. code-block:: +# +# data:NXdata +# @signal = "data" +# @axes = ["x", ".", "z"] --> the order matters +# data: float[10,20,30] +# x: float[10] --> coordinates along the first dimension +# z: float[30] --> coordinates along the third dimension +# +# When using :ref:`AXISNAME_indices </NXdata@AXISNAME_indices-attribute>` this becomes +# +# .. code-block:: +# +# data:NXdata +# @signal = "data" +# @axes = ["x", "z"] --> the order does NOT matter +# data: float[10,20,30] +# @x_indices = 0 +# @z_indices = 2 +# x: float[10] --> coordinates along the first dimension +# z: float[30] --> coordinates along the third dimension +# +# When providing :ref:`AXISNAME_indices </NXdata@AXISNAME_indices-attribute>` attributes it is recommended +# to do it for all axes. +# +# `Non-trivial axes` +# +# What follows are two examples where :ref:`AXISNAME_indices </NXdata@AXISNAME_indices-attribute>` attributes +# cannot be omitted. +# +# The first is an example where data dimensions have alternative axis coordinates. The NXdata group represents +# a stack of images collected at different energies. The ``wavelength`` is an alternative axis of ``energy`` +# for the last dimension (or vice versa). +# +# .. code-block:: +# +# data:NXdata +# @signal = "data" +# @axes = ["x", "y", "energy", "wavelength"] --> the order does NOT matter +# @x_indices = 0 +# @y_indices = 1 +# @energy_indices = 2 +# @wavelength_indices = 2 +# data: float[10,20,30] +# x: float[10] --> coordinates along the first dimension +# y: float[20] --> coordinates along the second dimension +# energy: float[30] --> coordinates along the third dimension +# wavelength: float[30] --> coordinates along the third dimension +# +# The second is an example with coordinates that span more than one dimension. The NXdata group represents data +# from 2D mesh scans performed at multiple energies. Each data point ``data[i,j,k]`` has axis coordinates +# ``[x[i,j,k], y[i,j,k], energy[k]]``. +# +# .. code-block:: +# +# data:NXdata +# @signal = "data" +# @axes = ["x", "y", "energy"] --> the order does NOT matter +# @x_indices = [0, 1, 2] +# @y_indices = [0, 1, 2] +# @energy_indices = 2 +# data: float[10,20,30] +# x: float[10,20,30] --> coordinates along all dimensions +# y: float[10,20,30] --> coordinates along all dimensions +# energy: float[30] --> coordinates along the third dimension +# +# **Uncertainties:** +# +# Standard deviations on data values as well as coordinates can be provided by +# :ref:`FIELDNAME_errors </NXdata/FIELDNAME_errors-field>` fields where ``FIELDNAME`` is the name of a +# :ref:`DATA </NXdata/DATA-field>` field or an :ref:`AXISNAME </NXdata/AXISNAME-field>` field. +# +# An example of uncertainties on the signal, auxiliary signals and axis coordinates +# +# .. code-block:: +# +# data:NXdata +# @signal = "data1" +# @auxiliary_signals = ["data2", "data3"] +# @axes = ["x", "z"] +# @x_indices = 0 +# @z_indices = 2 +# data1: float[10,20,30] +# data2: float[10,20,30] +# data3: float[10,20,30] +# x: float[10] +# z: float[30] +# data1_errors: float[10,20,30] +# data2_errors: float[10,20,30] +# data3_errors: float[10,20,30] +# x_errors: float[10] +# z_errors: float[30] +# +# +# +# +# +# +# .. index:: find the default plottable data +# .. index:: plotting +# .. index:: signal attribute value +# +# The value is the :ref:`name <validItemName>` of the signal that contains +# the default plottable data. 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. +# +# +# +# +# .. index:: plotting +# +# Array of strings holding the :ref:`names <validItemName>` of additional +# signals to be plotted with the :ref:`default signal </NXdata@signal-attribute>`. +# These fields or links *must* exist and be direct children of this NXdata group. +# +# Each auxiliary signal needs to be of the same shape as the default signal. +# +# .. NIAC2018: +# https://www.nexusformat.org/NIAC2018Minutes.html +# +# +# +# +# Which slice of data to show in a plot by default. This is useful especially for +# datasets with more than 2 dimensions. +# +# Should be an array of length equal to the number of dimensions +# in the data, with the following possible values: +# +# * ".": All the data in this dimension should be included +# * Integer: Only this slice should be used. +# * String: Only this slice should be used. Use if ``AXISNAME`` is a string +# array. +# +# Example:: +# +# data:NXdata +# @signal = "data" +# @axes = ["image_id", "channel", ".", "."] +# @image_id_indices = 0 +# @channel_indices = 1 +# @default_slice = [".", "difference", ".", "."] +# image_id = [1, ..., nP] +# channel = ["threshold_1", "threshold_2", "difference"] +# data = uint[nP, nC, i, j] +# +# Here, a data array with four dimensions, including the number of images +# (nP) and number of channels (nC), specifies more dimensions than can be +# visualized with a 2D image viewer for a given image. Therefore the +# default_slice attribute specifies that the "difference" channel should be +# shown by default. +# +# Alternate version using an integer would look like this (note 2 is a string):: +# +# data:NXdata +# @signal = "data" +# @axes = ["image_id", "channel", ".", "."] +# @image_id_indices = 0 +# @channel_indices = 1 +# @default_slice = [".", "2", ".", "."] +# image_id = [1, ..., nP] +# channel = ["threshold_1", "threshold_2", "difference"] +# data = uint[nP, nC, i, j] +# +# +# # # # Points to the path of a field defining the data to which the `DATA` group refers. @@ -680,254 +862,276 @@ NXdata(NXobject): # @reference: '/entry/instrument/detector/data' for a 2D detector # # -# -# -# -# -# Each ``AXISNAME_indices`` attribute indicates the dependency -# relationship of the ``AXISNAME`` field (where ``AXISNAME`` -# is the name of a field that exists in this ``NXdata`` group) -# with one or more dimensions of the plottable data. -# -# Integer array that defines the indices of the *signal* field -# (that field will be a multidimensional array) -# which need to be used in the *AXISNAME* field in -# order to reference the corresponding axis value. -# -# The first index of an array is ``0`` (zero). -# -# Here, *AXISNAME* is to be replaced by the name of each -# field described in the ``axes`` attribute. -# An example with 2-D data, :math:`d(t,P)`, will illustrate:: -# -# data_2d:NXdata -# @signal="data" -# @axes=["time", "pressure"] -# @time_indices=0 -# @pressure_indices=1 -# data: float[1000,20] -# time: float[1000] -# pressure: float[20] -# -# This attribute is to be provided in all situations. -# However, if the indices attributes are missing -# (such as for data files written before this specification), -# file readers are encouraged to make their best efforts -# to plot the data. -# Thus the implementation of the -# ``AXISNAME_indices`` attribute is based on the model of -# "strict writer, liberal reader". -# -# .. note:: Attributes potentially containing multiple values -# (axes and _indices) are to be written as string or integer arrays, -# to avoid string parsing in reading applications. -# -# -# -# -# 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. -# -# -# -# A *dimension scale* must have a rank of 1 and has length ``n``. -# -# -# -# -# -# Axis label -# -# -# -# -# ``0|false``: single value, -# ``1|true``: multiple values -# -# -# -# -# Index of first good value -# -# -# -# -# Index of last good value -# -# -# -# -# Index (positive integer) identifying this specific set of numbers. -# -# N.B. The ``axis`` attribute is the old way of designating a link. -# Do not use the ``axes`` attribute with the ``axis`` attribute. -# The ``axes`` *group* attribute is now preferred. -# -# +# +# +# +# +# The ``AXISNAME_indices`` attribute is a single integer or an array of integers that defines which :ref:`data </NXdata/DATA-field>` +# dimension(s) are spanned by the corresponding axis. The first dimension index is ``0`` (zero). +# +# When the ``AXISNAME_indices`` attribute is missing for an :ref:`AXISNAME </NXdata/AXISNAME-field>` field, its value becomes the index +# (or indices) of the :ref:`AXISNAME </NXdata/AXISNAME-field>` name in the :ref:`axes </NXdata@axes-attribute>` attribute. +# +# .. note:: When ``AXISNAME_indices`` contains multiple integers, it must be saved as an actual array +# of integers and not a comma separated string. +# +# +# +# +# .. index:: plotting +# +# The ``axes`` attribute is a list of strings which are the names of the :ref:`AXISNAME </NXdata/AXISNAME-field>` fields +# that contain the values of the coordinates along the :ref:`data </NXdata/DATA-field>` dimensions. +# +# .. note:: When ``axes`` contains multiple strings, it must be saved as an actual array +# of strings and not a single comma separated string. +# +# +# +# +# +# +# Coordinate values along one or more :ref:`data </NXdata/DATA-field>` dimensions. The rank must be equal +# to the number of dimensions it spans. +# +# As the upper case ``AXISNAME`` indicates, the names of the ``AXISNAME`` fields can be chosen :ref:`freely <validItemName>`. +# The :ref:`axes </NXdata@axes-attribute>` attribute can be used to find all datasets in the +# ``NXdata`` that contain coordinate values. +# +# Most AXISNAME fields will be sequences of numbers but if an axis is better represented using names, such as channel names, +# an array of NX_CHAR can be provided. +# +# Axis label +# +# +# Unit in which the coordinate values are expressed. +# See the section :ref:`Design-Units` for more information. +# +# +# +# +# ``0|false``: single value, +# ``1|true``: multiple values +# +# +# Index of first good value +# Index of last good value +# +# +# Index (positive integer) identifying this specific set of numbers. +# +# N.B. The ``axis`` attribute is the old way of designating a link. +# Do not use the :ref:`axes </NXdata@axes-attribute>` attribute with the ``axis`` attribute. +# The :ref:`axes </NXdata@axes-attribute>` attribute is now preferred. +# +# # # -# Points to the path of a field defining the axis to which the ``AXISNAME`` axis refers. +# Points to the path of a field defining the axis to which the ``AXISNAME`` axis refers. # -# This concept allows to link an axis to a respective field in the NeXus hierarchy, thereby -# defining the physical quantity it represents. +# This concept allows to link an axis to a respective field in the NeXus hierarchy, thereby +# defining the physical quantity it represents. # -# Examples: -# If a calibration has been performed, ``@reference`` links to the result of -# that calibration: +# Examples: +# If a calibration has been performed, ``@reference`` links to the result of +# that calibration: # -# @reference: '/entry/process/calibration/calibrated_axis' +# @reference: '/entry/process/calibration/calibrated_axis' # -# If the axis corresponds to a coordinate of a detector, ``@reference`` links -# to that detector axis: +# If the axis corresponds to a coordinate of a detector, ``@reference`` links +# to that detector axis: # -# @reference: '/entry/instrument/detector/axis/some_axis' for a 2D detector +# @reference: '/entry/instrument/detector/axis/some_axis' for a 2D detector # -# If the axis is a scanned motor, ``@reference`` links to the transformation -# describing the respective motion, e.g.: -# -# @reference: '/entry/instrument/detector/transformations/some_transformation' for a motion of the detector -# -# -# -# -# -# "Errors" (meaning *uncertainties* or *standard deviations*) -# associated with any field named ``FIELDNAME`` in this ``NXdata`` -# group (e.g. an axis, signal or auxiliary signal). -# -# The dimensions of the ``FIELDNAME_errors`` field must match -# the dimensions of the ``FIELDNAME`` field. -# -# -# -# -# .. 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. -# -# -# -# The rank (``dataRank``) of the ``data`` must satisfy -# ``1 <= dataRank <= NX_MAXRANK=32``. -# At least one ``dim`` must have length ``n``. -# -# -# -# -# .. index:: plotting +# If the axis is a scanned motor, ``@reference`` links to the transformation +# describing the respective motion, e.g.: # -# Plottable (independent) axis, indicate index number. -# Only one field in a :ref:`NXdata` group may have the -# ``signal=1`` attribute. -# Do not use the ``signal`` attribute with the ``axis`` attribute. -# -# -# -# -# Defines the names of the dimension scales -# (independent axes) for this data set -# as a colon-delimited array. -# NOTE: The ``axes`` attribute is the preferred -# method of designating a link. -# Do not use the ``axes`` attribute with the ``axis`` attribute. -# -# -# -# -# data label +# @reference: '/entry/instrument/detector/transformations/some_transformation' for a motion of the detector # # +# +# +# +# .. index:: plotting +# +# Data values to be used as the NeXus *plottable data*. As the upper case ``DATA`` +# indicates, the names of the ``DATA`` fields can be chosen :ref:`freely <validItemName>`. The :ref:`signal attribute </NXdata@signal-attribute>` +# and :ref:`auxiliary_signals attribute</NXdata@auxiliary_signals-attribute>` can be used to find all datasets in the ``NXdata`` +# that contain data values. +# +# The maximum rank is ``32`` for compatibility with backend file formats. +# +# +# +# The rank (``dataRank``) of the ``data`` must satisfy +# ``1 <= dataRank <= NX_MAXRANK=32``. +# +# +# +# +# .. index:: plotting +# +# Plottable (independent) axis, indicate index number. +# Only one field in a :ref:`NXdata` group may have the +# ``signal=1`` attribute. +# Do not use the ``signal`` attribute with the ``axis`` attribute. +# +# +# +# +# Defines the names of the coordinates +# (independent axes) for this data set +# as a colon-delimited array. +# NOTE: The :ref:`axes </NXdata@axes-attribute>` attribute is the preferred +# method of designating a link. +# Do not use the :ref:`axes </NXdata@axes-attribute>` attribute with the ``axis`` attribute. +# +# +# +# data label +# # # -# Points to the path of a field defining the data to which the `DATA` field refers. +# Points to the path of a field defining the data to which the `DATA` field refers. # -# This concept allows to link the data to a respective field in the NeXus hierarchy, thereby -# defining the physical quantity it represents. +# This concept allows to link the data to a respective field in the NeXus hierarchy, thereby +# defining the physical quantity it represents. # -# Here, *DATA* is to be replaced by the name of each -# data field. +# Here, *DATA* is to be replaced by the name of each +# data field. # -# Example: -# If the data corresponds to a readout of a detector, ``@reference`` links -# to that detectors data: +# Example: +# If the data corresponds to a readout of a detector, ``@reference`` links +# to that detectors data: # -# @reference: '/entry/instrument/detector/data' for a 2D detector +# @reference: '/entry/instrument/detector/data' for a 2D detector # # -# -# -# -# Standard deviations of data values - -# the data array is identified by the group attribute ``signal``. -# The ``errors`` array must have the same dimensions as ``DATA``. -# Client is responsible for defining the dimensions of the data. -# -# -# -# The ``errors`` must have -# the same rank (``dataRank``) -# as the ``data``. -# At least one ``dim`` must have length "n". -# -# -# -# -# -# The elements in data are usually float values really. For -# efficiency reasons these are usually stored as integers -# after scaling with a scale factor. This value is the scale -# factor. It is required to get the actual physical value, -# when necessary. -# -# -# -# -# An optional offset to apply to the values in data. -# -# -# -# -# Title for the plot. -# -# -# -# -# This is an array holding the values to use for the x-axis of -# data. The units must be appropriate for the measurement. -# -# -# -# -# -# -# -# This is an array holding the values to use for the y-axis of -# data. The units must be appropriate for the measurement. -# -# -# -# -# -# -# -# This is an array holding the values to use for the z-axis of -# data. The units must be appropriate for the measurement. -# -# -# -# -# +# +# +# +# "Errors" (meaning *uncertainties* or *standard deviations*) +# associated with any field named ``FIELDNAME`` in this ``NXdata`` +# group (e.g. an axis, signal or auxiliary signal). +# +# The dimensions of the ``FIELDNAME_errors`` field must match +# the dimensions of the ``FIELDNAME`` field. +# +# +# +# +# Standard deviations of data values - +# the data array is identified by the group attribute ``signal``. +# The ``errors`` array must have the same dimensions as ``DATA``. +# Client is responsible for defining the dimensions of the data. +# +# +# +# The ``errors`` must have the same rank (``dataRank``) +# as the ``data``. +# +# +# +# +# +# +# +# An optional scaling factor to apply to the values in any field named ``FIELDNAME`` +# in this ``NXdata`` group. This can be a :ref:`DATA </NXdata/DATA-field>` field +# (signal or auxiliary signal) or a :ref:`AXISNAME </NXdata/AXISNAME-field>` +# field (axis). +# +# The elements stored in NXdata datasets are often stored as integers for efficiency +# reasons and need further correction or conversion, generating floats. For example, +# raw values could be stored from a device that need to be converted to values that +# represent the physical values. The two fields FIELDNAME_scaling_factor and +# FIELDNAME_offset allow linear corrections using the following convention: +# +# .. code-block:: +# +# corrected values = (FIELDNAME + offset) * scaling_factor +# +# This formula will derive the values to use in downstream applications, when necessary. +# +# When omitted, the scaling factor is assumed to be 1. +# +# +# +# +# An optional offset to apply to the values in FIELDNAME (usually the signal). +# +# When omitted, the offset is assumed to be 0. +# +# See :ref:`FIELDNAME_scaling_factor </NXdata/FIELDNAME_scaling_factor-field>` for more information. +# +# +# +# +# +# The scaling_factor and FIELDNAME_scaling_factor fields have similar semantics. +# However, scaling_factor is ambiguous in the case of multiple signals. Therefore +# scaling_factor is deprecated. Use FIELDNAME_scaling_factor instead, even when +# only a single signal is present. +# +# +# +# +# The offset and FIELDNAME_offset fields have similar semantics. +# However, offset is ambiguous in the case of multiple signals. Therefore +# offset is deprecated. Use FIELDNAME_offset instead, even when +# only a single signal is present. +# +# +# +# +# +# +# +# Title for the plot. +# +# +# +# +# +# +# This is an array holding the values to use for the x-axis of +# data. The units must be appropriate for the measurement. +# +# This is a special case of a :ref:`AXISNAME field </NXdata/AXISNAME-field>` +# kept for backward compatiblity. +# +# +# +# +# +# +# +# This is an array holding the values to use for the y-axis of +# data. The units must be appropriate for the measurement. +# +# This is a special case of a :ref:`AXISNAME field </NXdata/AXISNAME-field>` +# kept for backward compatiblity. +# +# +# +# +# +# +# +# This is an array holding the values to use for the z-axis of +# data. The units must be appropriate for the measurement. +# +# This is a special case of a :ref:`AXISNAME field </NXdata/AXISNAME-field>` +# kept for backward compatiblity. +# +# +# +# +# # diff --git a/base_classes/nyaml/NXdetector.yaml b/base_classes/nyaml/NXdetector.yaml index 11f6f121d9..67a3a389d4 100644 --- a/base_classes/nyaml/NXdetector.yaml +++ b/base_classes/nyaml/NXdetector.yaml @@ -3,16 +3,13 @@ doc: | A detector, detector bank, or multidetector. symbols: doc: | - These symbols will be used below to illustrate the coordination of the - rank and sizes of datasets and the preferred ordering of the - dimensions. Each of these are optional (so the rank of the datasets - will vary according to the situation) and the general ordering - principle is slowest to fastest. The type of each dimension should - follow the order of scan points, detector output (e.g. pixels), then - time-of-flight (i.e. spectroscopy, spectrometry). Note that the output - of a detector is not limited to single values (0D), lists (1D) and - images (2), but three or higher dimensional arrays can be produced by - a detector at each trigger. + These symbols will be used below to illustrate the coordination of the rank and sizes of datasets and the + preferred ordering of the dimensions. Each of these are optional (so the rank of the datasets + will vary according to the situation) and the general ordering principle is slowest to fastest. + The type of each dimension should follow the order of scan points, detector output (e.g. pixels), + then time-of-flight (i.e. spectroscopy, spectrometry). Note that the output of a detector is not limited + to single values (0D), lists (1D) and images (2), but three or higher dimensional arrays can be produced + by a detector at each trigger. nP: | number of scan points (only present in scanning measurements) i: | @@ -20,8 +17,7 @@ symbols: j: | number of detector pixels in the second (faster) direction k: | - number of detector pixels in the third (if necessary, fastest) - direction + number of detector pixels in the third (if necessary, fastest) direction tof: | number of bins in the time-of-flight histogram type: group @@ -298,6 +294,15 @@ type: group Description of type such as He3 gas cylinder, He3 PSD, scintillator, fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, CMOS, ... + CHANNELNAME_channel(NXdetector_channel): + doc: | + Group containing the description and metadata for a single channel from a multi-channel + detector. + + Given an :ref:`NXdata` group linked as part of an NXdetector group that has an axis with + named channels (see the example in :ref:`NXdata `), + the NXdetector will have a series of NXdetector_channel groups, one for each channel, + named CHANNELNAME_channel. efficiency(NXdata): doc: | Spectral efficiency of detector with respect to e.g. wavelength @@ -323,10 +328,10 @@ type: group doc: | This field can be two things: - 1. For a pixel detector it provides the nominal wavelength + #. For a pixel detector it provides the nominal wavelength for which the detector has been calibrated. - 2. For other detectors this field has to be seen together with + #. For other detectors this field has to be seen together with the efficiency field above. For some detectors, the efficiency is wavelength dependent. Thus this field provides the wavelength axis for the efficiency field. @@ -396,7 +401,7 @@ type: group image. dimensions: rank: 1 - dim: [[1, nBrightFrames]] + dim: [[1, nP]] beam_center_x(NX_FLOAT): unit: NX_LENGTH doc: | @@ -685,17 +690,6 @@ type: group doc: | Shape description of the whole detector. Use only if pixels in the detector are not of uniform shape and require being described by cylinders. - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. amplifier_type(NX_CHAR): doc: | Type of electron amplifier, MCP, channeltron, etc. @@ -734,6 +728,17 @@ type: group (NXdata): doc: | raw data output from the detector + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. depends_on(NX_CHAR): doc: | NeXus positions components by applying a set of translations and rotations @@ -753,9 +758,9 @@ type: group other component groups. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# b8de5d6816422ae746c681a5bb5ad0f66038bc11cc71512ca38258d1132d7262 -# -# +# e8f4b233b107e53ec244f7ab7fd827b3f17e82c00e4223d832bca27d347fb5e6 +# +# # -# -# -# -# These symbols will be used below to illustrate the coordination of the -# rank and sizes of datasets and the preferred ordering of the -# dimensions. Each of these are optional (so the rank of the datasets -# will vary according to the situation) and the general ordering -# principle is slowest to fastest. The type of each dimension should -# follow the order of scan points, detector output (e.g. pixels), then -# time-of-flight (i.e. spectroscopy, spectrometry). Note that the output -# of a detector is not limited to single values (0D), lists (1D) and -# images (2), but three or higher dimensional arrays can be produced by -# a detector at each trigger. -# -# -# -# number of scan points (only present in scanning measurements) -# -# -# -# -# number of detector pixels in the first (slowest) direction -# -# -# -# -# number of detector pixels in the second (faster) direction -# -# -# -# -# number of detector pixels in the third (if necessary, fastest) -# direction -# -# -# -# -# number of bins in the time-of-flight histogram -# -# -# +# +# +# # -# A detector, detector bank, or multidetector. +# These symbols will be used below to illustrate the coordination of the rank and sizes of datasets and the +# preferred ordering of the dimensions. Each of these are optional (so the rank of the datasets +# will vary according to the situation) and the general ordering principle is slowest to fastest. +# The type of each dimension should follow the order of scan points, detector output (e.g. pixels), +# then time-of-flight (i.e. spectroscopy, spectrometry). Note that the output of a detector is not limited +# to single values (0D), lists (1D) and images (2), but three or higher dimensional arrays can be produced +# by a detector at each trigger. # -# -# -# Total time of flight -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Total time of flight -# -# -# -# -# -# In DAQ clock pulses -# -# -# -# -# -# -# Clock frequency in Hz -# -# -# -# -# -# Identifier for detector (pixels) -# Can be multidimensional, if needed -# -# -# -# -# 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. -# -# -# -# -# -# -# -# -# -# Title of measurement -# -# -# -# -# Integral of data as check of data integrity -# -# -# -# -# -# The best estimate of the uncertainty in the data value (array size should match the data field). Where -# possible, this should be the standard deviation, which has the same units -# as the data. The form data_error is deprecated. -# -# -# -# -# -# -# -# -# -# -# Offset from the detector center in x-direction. -# Can be multidimensional when needed. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# x-axis offset from detector center -# -# -# -# -# -# Offset from the detector center in the y-direction. -# Can be multidimensional when different values are required for each pixel. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# y-axis offset from detector center -# -# -# -# -# -# Offset from the detector center in the z-direction. -# Can be multidimensional when different values are required for each pixel. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# y-axis offset from detector center -# -# -# -# -# -# This is the distance to the previous component in the -# instrument; most often the sample. The usage depends on the -# nature of the detector: Most often it is the distance of the -# detector assembly. But there are irregular detectors. In this -# case the distance must be specified for each detector pixel. -# -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# -# -# -# -# -# This is the polar angle of the detector towards the previous -# component in the instrument; most often the sample. -# The usage depends on the -# nature of the detector. -# Most often it is the polar_angle of the detector assembly. -# But there are irregular detectors. -# In this -# case, the polar_angle must be specified for each detector pixel. -# -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# -# -# -# -# -# This is the azimuthal angle angle of the detector towards -# the previous component in the instrument; most often the sample. -# The usage depends on the -# nature of the detector. -# Most often it is the azimuthal_angle of the detector assembly. -# But there are irregular detectors. -# In this -# case, the azimuthal_angle must be specified for each detector pixel. -# -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# -# -# -# -# -# name/manufacturer/model/etc. information -# -# -# -# -# Serial number for the detector -# -# -# -# -# Local name for the detector -# -# -# -# -# Position and orientation of detector -# -# -# -# -# Solid angle subtended by the detector at the sample -# -# -# -# -# -# -# -# -# Size of each detector pixel. If it is scalar all pixels are the same size. -# -# -# -# -# -# -# -# -# Size of each detector pixel. If it is scalar all pixels are the same size -# -# -# -# -# -# -# -# -# Detector dead time -# -# -# -# -# -# -# -# -# -# Detector gas pressure -# -# -# -# -# -# -# -# -# maximum drift space dimension -# -# -# -# -# Crate number of detector -# -# -# -# -# -# -# -# Equivalent local term -# -# -# -# -# -# Slot number of detector -# -# -# -# -# -# -# -# Equivalent local term -# -# -# -# -# -# Input number of detector -# -# -# -# -# -# -# -# Equivalent local term -# -# -# -# -# -# Description of type such as He3 gas cylinder, He3 PSD, scintillator, -# fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, -# CMOS, ... -# -# -# -# -# Spectral efficiency of detector with respect to e.g. wavelength -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# efficiency of the detector -# -# -# -# -# -# -# -# -# -# This field can be two things: -# -# 1. For a pixel detector it provides the nominal wavelength -# for which the detector has been calibrated. -# -# 2. For other detectors this field has to be seen together with -# the efficiency field above. -# For some detectors, the efficiency is wavelength dependent. -# Thus this field provides the wavelength axis for the efficiency field. -# In this use case, the efficiency and wavelength arrays must -# have the same dimensionality. -# -# -# -# -# -# -# -# -# -# -# Real-time of the exposure (use this if exposure time varies for -# each array element, otherwise use ``count_time`` field). -# -# Most often there is a single real time value that is constant across -# an entire image frame. In such cases, only a 1-D array is needed. -# But there are detectors in which the real time -# changes per pixel. In that case, more than one dimension is needed. Therefore -# the rank of this field should be less than or equal to (detector rank + 1). -# -# -# -# -# -# -# -# -# -# start time for each frame, with the ``start`` attribute as absolute reference -# -# -# -# -# -# -# -# -# stop time for each frame, with the ``start`` attribute as absolute reference -# -# -# -# -# -# -# -# -# date of last calibration (geometry and/or efficiency) measurements -# -# -# -# -# summary of conversion of array data to pixels (e.g. polynomial -# approximations) and location of details of the calibrations -# -# -# -# -# How the detector is represented -# -# -# -# -# -# -# -# -# -# Elapsed actual counting time -# -# -# -# -# -# -# -# -# Use this group to provide other data related to this NXdetector group. -# +# +# number of scan points (only present in scanning measurements) +# number of detector pixels in the first (slowest) direction +# number of detector pixels in the second (faster) direction +# number of detector pixels in the third (if necessary, fastest) direction +# number of bins in the time-of-flight histogram +# +# +# +# A detector, detector bank, or multidetector. +# +# +# +# Total time of flight +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Total time of flight +# +# +# +# +# In DAQ clock pulses +# +# +# +# +# +# +# Clock frequency in Hz +# +# +# +# +# +# Identifier for detector (pixels) +# Can be multidimensional, if needed +# +# +# +# +# +# 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. +# +# +# +# +# +# +# +# +# +# +# Title of measurement +# +# +# +# Integral of data as check of data integrity +# +# +# +# +# +# +# The best estimate of the uncertainty in the data value (array size should match the data field). Where +# possible, this should be the standard deviation, which has the same units +# as the data. The form data_error is deprecated. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Offset from the detector center in x-direction. +# Can be multidimensional when needed. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# x-axis offset from detector center +# +# +# +# +# +# Offset from the detector center in the y-direction. +# Can be multidimensional when different values are required for each pixel. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# y-axis offset from detector center +# +# +# +# +# +# +# Offset from the detector center in the z-direction. +# Can be multidimensional when different values are required for each pixel. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# y-axis offset from detector center +# +# +# +# +# +# This is the distance to the previous component in the +# instrument; most often the sample. The usage depends on the +# nature of the detector: Most often it is the distance of the +# detector assembly. But there are irregular detectors. In this +# case the distance must be specified for each detector pixel. +# +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# +# +# +# +# +# +# +# This is the polar angle of the detector towards the previous +# component in the instrument; most often the sample. +# The usage depends on the +# nature of the detector. +# Most often it is the polar_angle of the detector assembly. +# But there are irregular detectors. +# In this +# case, the polar_angle must be specified for each detector pixel. +# +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# +# +# +# +# +# +# +# This is the azimuthal angle angle of the detector towards +# the previous component in the instrument; most often the sample. +# The usage depends on the +# nature of the detector. +# Most often it is the azimuthal_angle of the detector assembly. +# But there are irregular detectors. +# In this +# case, the azimuthal_angle must be specified for each detector pixel. +# +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# +# +# +# +# +# +# name/manufacturer/model/etc. information +# +# +# +# Serial number for the detector +# +# +# +# Local name for the detector +# +# +# +# Position and orientation of detector +# +# +# +# Solid angle subtended by the detector at the sample +# +# +# +# +# +# +# +# +# +# Size of each detector pixel. If it is scalar all pixels are the same size. +# +# +# +# +# +# +# +# +# +# Size of each detector pixel. If it is scalar all pixels are the same size +# +# +# +# +# +# +# +# +# Detector dead time +# +# +# +# +# +# +# +# +# +# Detector gas pressure +# +# +# +# +# +# +# +# +# maximum drift space dimension +# +# +# +# Crate number of detector +# +# +# +# +# +# +# +# Equivalent local term +# +# +# +# +# Slot number of detector +# +# +# +# +# +# +# +# Equivalent local term +# +# +# +# +# Input number of detector +# +# +# +# +# +# +# +# Equivalent local term +# +# +# +# +# +# Description of type such as He3 gas cylinder, He3 PSD, scintillator, +# fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, +# CMOS, ... +# +# +# +# +# +# Group containing the description and metadata for a single channel from a multi-channel +# detector. +# +# Given an :ref:`NXdata` group linked as part of an NXdetector group that has an axis with +# named channels (see the example in :ref:`NXdata </NXdata@default_slice-attribute>`), +# the NXdetector will have a series of NXdetector_channel groups, one for each channel, +# named CHANNELNAME_channel. +# +# +# +# +# Spectral efficiency of detector with respect to e.g. wavelength +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# efficiency of the detector +# +# +# +# +# +# +# +# +# +# +# This field can be two things: +# +# #. For a pixel detector it provides the nominal wavelength +# for which the detector has been calibrated. +# +# #. For other detectors this field has to be seen together with +# the efficiency field above. +# For some detectors, the efficiency is wavelength dependent. +# Thus this field provides the wavelength axis for the efficiency field. +# In this use case, the efficiency and wavelength arrays must +# have the same dimensionality. +# +# +# +# +# +# +# +# +# +# +# +# Real-time of the exposure (use this if exposure time varies for +# each array element, otherwise use ``count_time`` field). +# +# Most often there is a single real time value that is constant across +# an entire image frame. In such cases, only a 1-D array is needed. +# But there are detectors in which the real time +# changes per pixel. In that case, more than one dimension is needed. Therefore +# the rank of this field should be less than or equal to (detector rank + 1). +# +# +# +# +# +# +# +# +# +# start time for each frame, with the ``start`` attribute as absolute reference +# +# +# +# +# +# +# stop time for each frame, with the ``start`` attribute as absolute reference +# +# +# +# +# +# +# +# +# date of last calibration (geometry and/or efficiency) measurements +# +# +# +# +# +# summary of conversion of array data to pixels (e.g. polynomial +# approximations) and location of details of the calibrations +# +# +# +# +# How the detector is represented +# +# +# +# +# +# +# +# +# +# Elapsed actual counting time +# +# +# +# +# +# +# +# +# +# +# Use this group to provide other data related to this NXdetector group. +# +# +# +# +# +# In order to properly sort the order of the images taken in (for +# example) a tomography experiment, a sequence number is stored with each +# image. +# +# +# +# +# +# +# +# +# +# This is the x position where the direct beam would hit the detector. +# This is a length and can be outside of the actual +# detector. The length can be in physical units or pixels +# as documented by the units attribute. +# +# +# +# +# +# This is the y position where the direct beam would hit the detector. +# This is a length and can be outside of the actual +# detector. The length can be in physical units or pixels +# as documented by the units attribute. +# +# +# +# +# +# This is the start number of the first frame of a scan. In protein crystallography measurements one +# often scans a couple of frames on a give sample, then does something else, +# then returns to the same sample and scans some more frames. Each time with +# a new data file. This number helps concatenating such measurements. +# +# +# +# +# The diameter of a cylindrical detector +# +# +# +# The acquisition mode of the detector. +# +# +# +# +# +# +# +# +# +# +# +# +# True when the angular calibration has been applied in the +# electronics, false otherwise. +# +# +# +# Angular calibration data. +# +# +# +# +# +# +# +# True when the flat field correction has been applied in the +# electronics, false otherwise. +# +# +# +# Flat field correction data. +# +# +# +# +# +# +# +# Errors of the flat field correction data. +# The form flatfield_error is deprecated. +# +# +# +# +# +# +# +# +# True when the pixel mask correction has been applied in the +# electronics, false otherwise. +# +# +# +# +# The 32-bit pixel mask for the detector. Can be either one mask +# for the whole dataset (i.e. an array with indices i, j) or +# each frame can have its own mask (in which case it would be +# an array with indices np, i, j). +# +# Contains a bit field for each pixel to signal dead, +# blind or high or otherwise unwanted or undesirable pixels. +# They have the following meaning: +# +# .. can't make a table here, a bullet list will have to do for now +# +# * bit 0: gap (pixel with no sensor) +# * bit 1: dead +# * bit 2: under responding +# * bit 3: over responding +# * bit 4: noisy +# * bit 5: -undefined- +# * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) +# * bit 7: -undefined- +# * bit 8: user defined mask (e.g. around beamstop) +# * bits 9-30: -undefined- +# * bit 31: virtual pixel (corner pixel with interpolated value) +# +# Normal data analysis software would +# not take pixels into account +# when a bit in (mask & 0x0000FFFF) is +# set. Tag bit in the upper +# two bytes would indicate special pixel +# properties that normally +# would not be a sole reason to reject the +# intensity value (unless +# lower bits are set. +# +# If the full bit depths is not required, providing a +# mask with fewer bits is permissible. +# +# If needed, additional pixel masks can be specified by +# including additional entries named pixel_mask_N, where +# N is an integer. For example, a general bad pixel mask +# could be specified in pixel_mask that indicates noisy +# and dead pixels, and an additional pixel mask from +# experiment-specific shadowing could be specified in +# pixel_mask_2. The cumulative mask is the bitwise OR +# of pixel_mask and any pixel_mask_N entries. +# +# +# +# +# +# +# +# +# +# This field allow to distinguish different types of exposure to the same detector "data" field. +# Some techniques require frequent (re-)calibration inbetween measuremnts and this way of +# recording the different measurements preserves the chronological order with is important for +# correct processing. +# +# This is used for example in tomography (`:ref:`NXtomo`) sample projections, +# dark and flat images, a magic number is recorded per frame. +# +# The key is as follows: +# +# * projection (sample) = 0 +# * flat field = 1 +# * dark field = 2 +# * invalid = 3 +# * background (no sample, but buffer where applicable) = 4 +# +# In cases where the data is of type :ref:`NXlog` this can also be an NXlog. +# +# +# +# +# +# +# +# +# Counting detectors usually are not able to measure all incoming particles, +# especially at higher count-rates. Count-rate correction is applied to +# account for these errors. +# +# True when count-rate correction has been applied, false otherwise. +# +# +# +# +# The countrate_correction_lookup_table defines the LUT used for count-rate +# correction. It maps a measured count :math:`c` to its corrected value +# :math:`countrate\_correction\_lookup\_table[c]`. +# +# :math:`m` denotes the length of the table. +# +# +# +# +# +# +# +# True when virtual pixel interpolation has been applied, false otherwise. +# +# When virtual pixel interpolation is applied, values of some pixels may +# contain interpolated values. For example, to account for space between +# readout chips on a module, physical pixels on edges and corners between +# chips may have larger sensor areas and counts may be distributed between +# their logical pixels. +# +# +# +# +# How many bits the electronics reads per pixel. +# With CCD's and single photon counting detectors, +# this must not align with traditional integer sizes. +# This can be 4, 8, 12, 14, 16, ... +# +# +# +# +# Time it takes to read the detector (typically milliseconds). +# This is important to know for time resolved experiments. +# +# +# +# +# Time it takes to start exposure after a trigger signal has been received. +# This is the reaction time of the detector firmware after receiving the trigger signal +# to when the detector starts to acquire the exposure, including any user set delay.. +# This is important to know for time resolved experiments. +# +# +# +# +# User-specified trigger delay. +# +# +# +# +# Time it takes to start exposure after a trigger signal has been received. +# This is the reaction time of the detector hardware after receiving the +# trigger signal to when the detector starts to acquire the exposure. +# It forms the lower boundary of the trigger_delay_time when the user +# does not request an additional delay. +# +# +# +# +# Time during which no new trigger signal can be accepted. +# Typically this is the +# trigger_delay_time + exposure_time + readout_time. +# This is important to know for time resolved experiments. +# +# +# +# +# This is time for each frame. This is exposure_time + readout time. +# +# +# +# +# +# +# +# The gain setting of the detector. This is a detector-specific value +# meant to document the gain setting of the detector during data +# collection, for detectors with multiple available gain settings. +# +# Examples of gain settings include: +# +# * ``standard`` +# * ``fast`` +# * ``auto`` +# * ``high`` +# * ``medium`` +# * ``low`` +# * ``mixed high to medium`` +# * ``mixed medium to low`` +# +# Developers are encouraged to use one of these terms, or to submit +# additional terms to add to the list. +# +# +# +# +# The value at which the detector goes into saturation. +# Especially common to CCD detectors, the data +# is known to be invalid above this value. +# +# For example, given a saturation_value and an underload_value, the valid +# pixels are those less than or equal to the saturation_value and greater +# than or equal to the underload_value. +# +# The precise type should match the type of the data. +# +# +# +# +# The lowest value at which pixels for this detector would be reasonably +# measured. The data is known to be invalid below this value. +# +# For example, given a saturation_value and an underload_value, the valid +# pixels are those less than or equal to the saturation_value and greater +# than or equal to the underload_value. +# +# The precise type should match the type of the data. +# +# +# +# +# CCD images are sometimes constructed by summing +# together multiple short exposures in the +# electronics. This reduces background etc. +# This is the number of short exposures used to sum +# images for an image. +# +# +# +# +# At times, radiation is not directly sensed by the detector. +# Rather, the detector might sense the output from some +# converter like a scintillator. +# This is the name of this converter material. +# +# +# +# +# At times, radiation is not directly sensed by the detector. +# Rather, the detector might sense the output from some +# converter like a scintillator. +# This is the thickness of this converter material. +# +# +# +# +# Single photon counter detectors can be adjusted +# for a certain energy range in which they +# work optimally. This is the energy setting for this. +# +# +# +# +# For use in special cases where the data in NXdetector +# is represented in several parts, each with a separate geometry. +# +# +# +# +# +# Shape description of each pixel. Use only if all pixels in the detector +# are of uniform shape. +# # -# -# -# In order to properly sort the order of the images taken in (for -# example) a tomography experiment, a sequence number is stored with each -# image. -# -# -# -# -# -# -# -# This is the x position where the direct beam would hit the detector. -# This is a length and can be outside of the actual -# detector. The length can be in physical units or pixels -# as documented by the units attribute. -# -# -# -# -# This is the y position where the direct beam would hit the detector. -# This is a length and can be outside of the actual -# detector. The length can be in physical units or pixels -# as documented by the units attribute. -# -# -# -# -# This is the start number of the first frame of a scan. In protein crystallography measurements one -# often scans a couple of frames on a give sample, then does something else, -# then returns to the same sample and scans some more frames. Each time with -# a new data file. This number helps concatenating such measurements. -# -# -# -# -# The diameter of a cylindrical detector -# -# -# -# -# The acquisition mode of the detector. -# -# -# -# -# -# -# -# -# -# -# -# -# -# True when the angular calibration has been applied in the -# electronics, false otherwise. -# -# -# -# -# Angular calibration data. -# -# -# -# -# -# -# -# -# True when the flat field correction has been applied in the -# electronics, false otherwise. -# -# -# -# -# Flat field correction data. -# -# -# -# -# -# -# -# -# Errors of the flat field correction data. -# The form flatfield_error is deprecated. -# -# -# -# -# -# -# -# -# True when the pixel mask correction has been applied in the -# electronics, false otherwise. -# -# -# -# -# The 32-bit pixel mask for the detector. Can be either one mask -# for the whole dataset (i.e. an array with indices i, j) or -# each frame can have its own mask (in which case it would be -# an array with indices np, i, j). -# -# Contains a bit field for each pixel to signal dead, -# blind or high or otherwise unwanted or undesirable pixels. -# They have the following meaning: -# -# .. can't make a table here, a bullet list will have to do for now -# -# * bit 0: gap (pixel with no sensor) -# * bit 1: dead -# * bit 2: under responding -# * bit 3: over responding -# * bit 4: noisy -# * bit 5: -undefined- -# * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) -# * bit 7: -undefined- -# * bit 8: user defined mask (e.g. around beamstop) -# * bits 9-30: -undefined- -# * bit 31: virtual pixel (corner pixel with interpolated value) -# -# Normal data analysis software would -# not take pixels into account -# when a bit in (mask & 0x0000FFFF) is -# set. Tag bit in the upper -# two bytes would indicate special pixel -# properties that normally -# would not be a sole reason to reject the -# intensity value (unless -# lower bits are set. -# -# If the full bit depths is not required, providing a -# mask with fewer bits is permissible. -# -# If needed, additional pixel masks can be specified by -# including additional entries named pixel_mask_N, where -# N is an integer. For example, a general bad pixel mask -# could be specified in pixel_mask that indicates noisy -# and dead pixels, and an additional pixel mask from -# experiment-specific shadowing could be specified in -# pixel_mask_2. The cumulative mask is the bitwise OR -# of pixel_mask and any pixel_mask_N entries. -# -# -# -# -# -# -# -# -# This field allow to distinguish different types of exposure to the same detector "data" field. -# Some techniques require frequent (re-)calibration inbetween measuremnts and this way of -# recording the different measurements preserves the chronological order with is important for -# correct processing. -# -# This is used for example in tomography (`:ref:`NXtomo`) sample projections, -# dark and flat images, a magic number is recorded per frame. -# -# The key is as follows: -# -# * projection (sample) = 0 -# * flat field = 1 -# * dark field = 2 -# * invalid = 3 -# * background (no sample, but buffer where applicable) = 4 -# -# In cases where the data is of type :ref:`NXlog` this can also be an NXlog. -# -# -# -# -# -# -# -# Counting detectors usually are not able to measure all incoming particles, -# especially at higher count-rates. Count-rate correction is applied to -# account for these errors. -# -# True when count-rate correction has been applied, false otherwise. -# -# -# -# -# The countrate_correction_lookup_table defines the LUT used for count-rate -# correction. It maps a measured count :math:`c` to its corrected value -# :math:`countrate\_correction\_lookup\_table[c]`. -# -# :math:`m` denotes the length of the table. -# -# -# -# -# -# -# -# True when virtual pixel interpolation has been applied, false otherwise. -# -# When virtual pixel interpolation is applied, values of some pixels may -# contain interpolated values. For example, to account for space between -# readout chips on a module, physical pixels on edges and corners between -# chips may have larger sensor areas and counts may be distributed between -# their logical pixels. -# -# -# -# -# How many bits the electronics reads per pixel. -# With CCD's and single photon counting detectors, -# this must not align with traditional integer sizes. -# This can be 4, 8, 12, 14, 16, ... -# -# -# -# -# Time it takes to read the detector (typically milliseconds). -# This is important to know for time resolved experiments. -# -# -# -# -# Time it takes to start exposure after a trigger signal has been received. -# This is the reaction time of the detector firmware after receiving the trigger signal -# to when the detector starts to acquire the exposure, including any user set delay.. -# This is important to know for time resolved experiments. -# -# -# -# -# User-specified trigger delay. -# -# -# -# -# Time it takes to start exposure after a trigger signal has been received. -# This is the reaction time of the detector hardware after receiving the -# trigger signal to when the detector starts to acquire the exposure. -# It forms the lower boundary of the trigger_delay_time when the user -# does not request an additional delay. -# -# -# -# -# Time during which no new trigger signal can be accepted. -# Typically this is the -# trigger_delay_time + exposure_time + readout_time. -# This is important to know for time resolved experiments. -# -# -# -# -# This is time for each frame. This is exposure_time + readout time. -# -# -# -# -# -# -# -# The gain setting of the detector. This is a detector-specific value -# meant to document the gain setting of the detector during data -# collection, for detectors with multiple available gain settings. -# -# Examples of gain settings include: -# -# * ``standard`` -# * ``fast`` -# * ``auto`` -# * ``high`` -# * ``medium`` -# * ``low`` -# * ``mixed high to medium`` -# * ``mixed medium to low`` -# -# Developers are encouraged to use one of these terms, or to submit -# additional terms to add to the list. -# -# -# -# -# The value at which the detector goes into saturation. -# Especially common to CCD detectors, the data -# is known to be invalid above this value. -# -# For example, given a saturation_value and an underload_value, the valid -# pixels are those less than or equal to the saturation_value and greater -# than or equal to the underload_value. -# -# The precise type should match the type of the data. -# -# -# -# -# The lowest value at which pixels for this detector would be reasonably -# measured. The data is known to be invalid below this value. -# -# For example, given a saturation_value and an underload_value, the valid -# pixels are those less than or equal to the saturation_value and greater -# than or equal to the underload_value. -# -# The precise type should match the type of the data. -# -# -# -# -# CCD images are sometimes constructed by summing -# together multiple short exposures in the -# electronics. This reduces background etc. -# This is the number of short exposures used to sum -# images for an image. -# -# -# -# -# At times, radiation is not directly sensed by the detector. -# Rather, the detector might sense the output from some -# converter like a scintillator. -# This is the name of this converter material. -# -# -# -# -# At times, radiation is not directly sensed by the detector. -# Rather, the detector might sense the output from some -# converter like a scintillator. -# This is the thickness of this converter material. -# -# -# -# -# Single photon counter detectors can be adjusted -# for a certain energy range in which they -# work optimally. This is the energy setting for this. -# -# -# -# -# For use in special cases where the data in NXdetector -# is represented in several parts, each with a separate geometry. -# +# +# +# Shape description of each pixel. Use only if all pixels in the detector +# are of uniform shape and require being described by cylinders. +# # -# -# -# -# Shape description of each pixel. Use only if all pixels in the detector -# are of uniform shape. -# -# -# -# -# Shape description of each pixel. Use only if all pixels in the detector -# are of uniform shape and require being described by cylinders. -# -# -# -# -# -# -# Shape description of the whole detector. Use only if pixels in the -# detector are not of uniform shape. -# -# -# -# -# Shape description of the whole detector. Use only if pixels in the -# detector are not of uniform shape and require being described by cylinders. -# -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# Type of electron amplifier, MCP, channeltron, etc. -# -# -# -# -# Description of the detector type, DLD, Phosphor+CCD, CMOS. -# -# -# -# -# Voltage applied to detector. -# -# -# -# -# Voltage applied to the amplifier. -# -# -# -# -# The low voltage of the amplifier migh not be the ground. -# -# -# -# -# Size of each imaging sensor chip on the detector. -# -# -# -# -# Number of imaging sensor chips on the detector. -# -# -# -# -# Physical size of the pixels of the imaging chip on the detector. -# -# -# -# -# Number of raw active elements in each dimension. Important for swept scans. -# -# -# -# -# -# raw data output from the detector -# +# +# +# +# +# Shape description of the whole detector. Use only if pixels in the +# detector are not of uniform shape. +# # -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# The reference point of the detector is the center of the first pixel. -# In complex geometries the NXoff_geometry groups can be used to provide an unambiguous reference. -# -# -# -# -# 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. -# +# +# +# Shape description of the whole detector. Use only if pixels in the +# detector are not of uniform shape and require being described by cylinders. +# # +# +# +# +# Type of electron amplifier, MCP, channeltron, etc. +# +# +# +# +# Description of the detector type, DLD, Phosphor+CCD, CMOS. +# +# +# +# +# Voltage applied to detector. +# +# +# +# +# Voltage applied to the amplifier. +# +# +# +# +# The low voltage of the amplifier migh not be the ground. +# +# +# +# +# Size of each imaging sensor chip on the detector. +# +# +# +# +# Number of imaging sensor chips on the detector. +# +# +# +# +# Physical size of the pixels of the imaging chip on the detector. +# +# +# +# +# Number of raw active elements in each dimension. Important for swept scans. +# +# +# +# +# +# raw data output from the detector +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# The reference point of the detector is the center of the first pixel. +# In complex geometries the NXoff_geometry groups can be used to provide an unambiguous reference. +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# # diff --git a/base_classes/nyaml/NXentry.yaml b/base_classes/nyaml/NXentry.yaml index 692d5caa33..44c1dff1b0 100644 --- a/base_classes/nyaml/NXentry.yaml +++ b/base_classes/nyaml/NXentry.yaml @@ -88,6 +88,26 @@ NXentry(NXobject): \@version: doc: | Version of UUID used + experiment_location: + doc: | + City and country where the experiment took place + experiment_start_date(NX_DATE_TIME): + doc: | + Start time of experimental run that includes the current + measurement, for example a beam time. + experiment_end_date(NX_DATE_TIME): + doc: | + End time of experimental run that includes the current + measurement, for example a beam time. + experiment_institution: + doc: | + Name of the institution hosting the facility + experiment_facility: + doc: | + Name of the experimental facility + experiment_laboratory: + doc: | + Name of the laboratory or beamline features: doc: | Reserved for future use by NIAC. @@ -182,26 +202,6 @@ NXentry(NXobject): # This is not perfect. # How do we set a default value for the type attribute? enumeration: [image/*] - experiment_location: - doc: | - City and country where the experiment took place - experiment_start_date(NX_DATE_TIME): - doc: | - Start time of experimental run that includes the current - measurement, for example a beam time. - experiment_end_date(NX_DATE_TIME): - doc: | - End time of experimental run that includes the current - measurement, for example a beam time. - experiment_institution: - doc: | - Name of the institution hosting the facility - experiment_facility: - doc: | - Name of the experimental facility - experiment_laboratory: - doc: | - Name of the laboratory or beamline (NXuser): (NXsample): (NXinstrument): @@ -212,9 +212,9 @@ NXentry(NXobject): (NXsubentry): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 946ca1fae81c2431754e4430b49eb7969a18f21ab555ee515aac10a70b8dea3a -# -# +# 8bc49b1f127bc6bb67ef39fead2e86ebae2f729ff5451e3e04a9066bb4a85b64 +# +# # -# -# -# (**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. -# -# -# -# .. 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 <validItemName>` 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 <Find-Plottable-Data-v3>` -# section. -# -# -# -# -# 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 -# -# -# -# -# -# ISIS Muon IDF_Version -# -# -# -# -# Extended title for entry -# -# -# +# +# +# +# +# .. 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 <validItemName>` 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 <Find-Plottable-Data-v3>` +# section. +# +# +# +# +# (**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. +# +# +# +# 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 +# +# +# +# +# +# +# ISIS Muon IDF_Version +# +# +# Extended title for entry +# +# # # Unique identifier for the experiment, # defined by the facility, # possibly linked to the proposals # # -# -# -# Brief summary of the experiment, including key objectives. -# -# -# -# -# Description of the full experiment (document in pdf, latex, ...) -# -# -# -# -# User or Data Acquisition defined group of NeXus files or NXentry -# -# -# -# -# Brief summary of the collection, including grouping criteria. -# -# -# -# -# unique identifier for the measurement, defined by the facility. -# -# -# -# -# UUID identifier for the measurement. -# -# -# -# Version of UUID used -# -# -# -# -# -# Reserved for future use by NIAC. -# -# See https://github.com/nexusformat/definitions/issues/382 -# -# -# -# -# (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. -# -# -# -# NXDL version number -# -# -# -# -# URL of NXDL file -# -# -# -# -# -# Local NXDL schema extended from the entry -# specified in the ``definition`` field. -# This contains any locally-defined, -# additional fields in the entry. -# -# -# -# NXDL version number -# -# -# -# -# URL of NXDL file -# -# -# -# -# -# Starting time of measurement -# -# -# -# -# Ending time of measurement -# -# -# -# -# Duration of measurement -# -# -# -# -# Time transpired actually collecting data i.e. taking out time when collection was -# suspended due to e.g. temperature out of range -# -# -# -# -# Such as "2007-3". Some user facilities organize their beam time into run cycles. -# -# -# -# -# Name of program used to generate this file -# -# -# -# Program version number -# -# -# -# -# configuration of the program -# -# -# -# -# -# Revision id of the file due to re-calibration, reprocessing, new analysis, new -# instrument definition format, ... -# -# -# -# -# -# This is the flightpath before the sample position. This can be determined by a chopper, -# by the moderator or the source itself. In other words: it the distance to the component -# which gives the T0 signal to the detector electronics. If another component in the -# NXinstrument hierarchy provides this information, this should be a link. -# -# -# -# -# Notes describing entry -# -# -# -# -# A small image that is representative of the entry. An example of this is a 640x480 -# jpeg image automatically produced by a low resolution plot of the NXdata. -# -# -# -# The mime type should be an ``image/*`` -# -# -# -# -# -# +# +# Brief summary of the experiment, including key objectives. +# +# +# Description of the full experiment (document in pdf, latex, ...) +# +# +# User or Data Acquisition defined group of NeXus files or NXentry # +# +# Brief summary of the collection, including grouping criteria. +# +# +# unique identifier for the measurement, defined by the facility. +# +# +# UUID identifier for the measurement. +# Version of UUID used +# # -# -# City and country where the experiment took place -# +# City and country where the experiment took place # # # -# Start time of experimental run that includes the current -# measurement, for example a beam time. +# Start time of experimental run that includes the current +# measurement, for example a beam time. # # # @@ -512,12 +369,107 @@ NXentry(NXobject): # Name of the laboratory or beamline # # -# -# -# -# -# -# -# -# -# +# +# +# Reserved for future use by NIAC. +# +# See https://github.com/nexusformat/definitions/issues/382 +# +# +# +# +# (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. +# +# NXDL version number +# URL of NXDL file +# +# +# +# Local NXDL schema extended from the entry +# specified in the ``definition`` field. +# This contains any locally-defined, +# additional fields in the entry. +# +# NXDL version number +# URL of NXDL file +# +# +# Starting time of measurement +# +# +# Ending time of measurement +# +# +# Duration of measurement +# +# +# +# Time transpired actually collecting data i.e. taking out time when collection was +# suspended due to e.g. temperature out of range +# +# +# +# Such as "2007-3". Some user facilities organize their beam time into run cycles. +# +# +# Name of program used to generate this file +# Program version number +# configuration of the program +# +# +# +# Revision id of the file due to re-calibration, reprocessing, new analysis, new +# instrument definition format, ... +# +# +# +# +# +# This is the flightpath before the sample position. This can be determined by a chopper, +# by the moderator or the source itself. In other words: it the distance to the component +# which gives the T0 signal to the detector electronics. If another component in the +# NXinstrument hierarchy provides this information, this should be a link. +# +# +# +# Notes describing entry +# +# +# +# A small image that is representative of the entry. An example of this is a 640x480 +# jpeg image automatically produced by a low resolution plot of the NXdata. +# +# +# The mime type should be an ``image/*`` +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# \ No newline at end of file diff --git a/base_classes/nyaml/NXenvironment.yaml b/base_classes/nyaml/NXenvironment.yaml index 717858b87f..3c9457dfe0 100644 --- a/base_classes/nyaml/NXenvironment.yaml +++ b/base_classes/nyaml/NXenvironment.yaml @@ -8,12 +8,10 @@ NXenvironment(NXobject): Apparatus identification code/model number; e.g. OC100 011 short_name: doc: | - Alternative short name, perhaps for dashboard display like a present Seblock - name + Alternative short name, perhaps for dashboard display like a present Seblock name type: doc: | - Type of apparatus. This could be the SE codes in scheduling database; e.g. - OC/100 + Type of apparatus. This could be the SE codes in scheduling database; e.g. OC/100 description: doc: | Description of the apparatus; e.g. 100mm bore orange cryostat with Roots pump @@ -73,9 +71,9 @@ NXenvironment(NXobject): for a summary of the discussion. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 3ce4fc8a319f3ee0ad9eb40c88d67121e939a5f05f690725500c62ba88e7632a -# -# +# fbd1ae51f8ebc3b6fbac12baec026b0d389eea9bb992dc2abf34cd926d7753d1 +# +# # -# -# -# Parameters for controlling external conditions -# +# +# Parameters for controlling external conditions # -# -# Apparatus identification code/model number; e.g. OC100 011 -# +# Apparatus identification code/model number; e.g. OC100 011 # # -# -# Alternative short name, perhaps for dashboard display like a present Seblock -# name -# +# Alternative short name, perhaps for dashboard display like a present Seblock name # # -# -# Type of apparatus. This could be the SE codes in scheduling database; e.g. -# OC/100 -# +# Type of apparatus. This could be the SE codes in scheduling database; e.g. OC/100 # # -# -# Description of the apparatus; e.g. 100mm bore orange cryostat with Roots pump -# +# Description of the apparatus; e.g. 100mm bore orange cryostat with Roots pump # # -# -# Program controlling the apparatus; e.g. LabView VI name -# +# Program controlling the apparatus; e.g. LabView VI name # # # @@ -140,33 +128,31 @@ NXenvironment(NXobject): # the environment parameters, but the user would still like to give a value for # it. An example would be a room temperature experiment where the temperature is # not actively measured, but rather estimated. -# +# # Note that this method for recording the environment parameters is not advised, # but using NXsensor and NXactuator is strongly recommended instead. # # # # -# NeXus positions components by applying a set of translations and rotations -# 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. # # # # -# 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. # # # -# -# Additional information, LabView logs, digital photographs, etc -# +# Additional information, LabView logs, digital photographs, etc # # # @@ -183,10 +169,10 @@ NXenvironment(NXobject): # # # .. index:: plotting -# +# # Declares which child group contains a path leading # to a :ref:`NXdata` group. -# +# # It is recommended (as of NIAC2014) to use this attribute # to help define the path to the default dataset to be plotted. # See https://www.nexusformat.org/2014_How_to_find_default_data.html diff --git a/base_classes/nyaml/NXinstrument.yaml b/base_classes/nyaml/NXinstrument.yaml index e960c5d481..4db16ed912 100644 --- a/base_classes/nyaml/NXinstrument.yaml +++ b/base_classes/nyaml/NXinstrument.yaml @@ -42,8 +42,8 @@ NXinstrument(NXobject): (NXmonochromator): (NXpolarizer): (NXpositioner): - (NXsensor): (NXresolution): + (NXsensor): (NXsource): (NXtransformations)DIFFRACTOMETER: (NXvelocity_selector): @@ -61,9 +61,9 @@ NXinstrument(NXobject): for a summary of the discussion. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# fdecdac7e6f3f4cfbdc442355d0be92c315dff9551b943c7492edc8e68fddd10 -# -# +# 983ae9f80eebc3a829055922fe42262a639af0d8b04bb8af4339e82ac5e11312 +# +# # -# -# -# 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. -# -# -# -# Name of instrument -# -# -# -# short name for instrument, perhaps the acronym -# -# -# +# +# +# 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. +# +# +# Name of instrument +# +# short name for instrument, perhaps the acronym +# +# # -# -# -# -# -# -# -# -# -# -# -# -# -# +# +# +# +# +# +# +# +# +# +# +# +# +# # -# -# -# -# +# +# +# +# # -# -# -# -# -# -# -# +# +# +# +# +# +# # -# -# -# -# +# +# +# +# +# # # -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. # # # diff --git a/base_classes/nyaml/NXmonochromator.yaml b/base_classes/nyaml/NXmonochromator.yaml index f22a546db9..5c0653fa3a 100644 --- a/base_classes/nyaml/NXmonochromator.yaml +++ b/base_classes/nyaml/NXmonochromator.yaml @@ -10,7 +10,7 @@ doc: | The expected units are: * wavelength: angstrom - * energy: eV + * energy: eV type: group NXmonochromator(NXobject): wavelength(NX_FLOAT): @@ -100,9 +100,9 @@ NXmonochromator(NXobject): other component groups. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 58e1abbe3ac43752dd34951a3918118c17c865c756e29fb024b0966132ae3f79 -# -# +# c08b96b75acfa31a5ceaceb31ae19710c3e89fc854628ffda4dfa0af2c3389ba +# +# # -# +# # -# A wavelength defining device. -# -# This is a base class for everything which -# selects a wavelength or energy, be it a -# monochromator crystal, a velocity selector, -# an undulator or whatever. -# -# The expected units are: -# -# * wavelength: angstrom -# * energy: eV +# A wavelength defining device. +# +# This is a base class for everything which +# selects a wavelength or energy, be it a +# monochromator crystal, a velocity selector, +# an undulator or whatever. +# +# The expected units are: +# +# * wavelength: angstrom +# * energy: eV +# # # -# -# wavelength selected -# -# -# -# -# wavelength standard deviation -# +# wavelength selected +# +# +# wavelength standard deviation # # -# -# wavelength standard deviation -# +# wavelength standard deviation # # -# -# energy selected -# -# -# -# -# energy standard deviation -# -# +# energy selected +# +# +# energy standard deviation +# # -# -# energy standard deviation -# +# energy standard deviation # # # @@ -188,56 +183,48 @@ NXmonochromator(NXobject): # Size, position and shape of the exit slit of the monochromator. # # -# +# # # -# -# This group describes the shape of the beam line component -# -# -# -# -# Use as many crystals as necessary to describe -# -# -# -# -# -# For diffraction grating based monochromators +# +# This group describes the shape of the beam line component # # +# Use as many crystals as necessary to describe +# +# For diffraction grating based monochromators # # -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. # # # # -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a monochromator. +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a monochromator. # # # # -# 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. # # # diff --git a/base_classes/nyaml/NXprocess.yaml b/base_classes/nyaml/NXprocess.yaml index 5b7534e8a7..4b5dde8655 100644 --- a/base_classes/nyaml/NXprocess.yaml +++ b/base_classes/nyaml/NXprocess.yaml @@ -49,7 +49,7 @@ NXprocess(NXobject): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ # 0230d40dc43d25fc7f29df765b121c6bb3d86c63b4e8702d35308c83fd300c25 # -# +# # -# -# -# Document an event of data processing, reconstruction, or analysis for this data. -# +# +# Document an event of data processing, reconstruction, or analysis for this data. # -# -# Name of the program used -# +# Name of the program used # # # -# Sequence index of processing, -# for determining the order of multiple **NXprocess** steps. -# Starts with 1. +# Sequence index of processing, +# for determining the order of multiple **NXprocess** steps. +# Starts with 1. # # # -# -# Version of the program used -# +# Version of the program used # # -# -# Date and time of processing. -# +# Date and time of processing. # # # @@ -114,25 +110,25 @@ NXprocess(NXobject): # # # -# The note will contain information about how the data was processed -# or anything about the data provenance. -# The contents of the note can be anything that the processing code -# can understand, or simple text. -# -# The name will be numbered to allow for ordering of steps. +# The note will contain information about how the data was processed +# or anything about the data provenance. +# The contents of the note can be anything that the processing code +# can understand, or simple text. +# +# The name will be numbered to allow for ordering of steps. # # # # -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. # # # diff --git a/base_classes/nyaml/NXroot.yaml b/base_classes/nyaml/NXroot.yaml index b9a70983d2..5305e62bfa 100644 --- a/base_classes/nyaml/NXroot.yaml +++ b/base_classes/nyaml/NXroot.yaml @@ -93,8 +93,8 @@ NXroot(NXobject): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ # ab1e1a878a8283f6d94273d270ae61e3ef35ac35060c6c730b71ced5fff6a84d -# -# +# +# # -# -# -# Definition of the root NeXus group. -# +# +# Definition of the root NeXus group. # # -# The root of any NeXus data file is an ``NXroot`` class -# (no other choice is allowed for a valid NeXus data file). -# This attribute cements that definition. +# The root of any NeXus data file is an ``NXroot`` class +# (no other choice is allowed for a valid NeXus data file). +# This attribute cements that definition. # # -# +# # # # -# -# Date and time file was originally created -# +# Date and time file was originally created # # -# -# File name of original NeXus file -# +# File name of original NeXus file # # -# -# Date and time of last file change at close -# +# Date and time of last file change at close # # # -# A repository containing the application definitions -# used for creating this file. -# If the NeXus_version attribute contains a commit distance and hash -# this should refer to this repository. +# A repository containing the application definitions +# used for creating this file. +# If the NeXus_version attribute contains a commit distance and hash +# this should refer to this repository. # # # # -# Version of NeXus definitions used in writing the file. -# This may either be a date based version tag of the form `vYYYY.MM` -# or a version tag with a commit distance and source control (e.g., git) hash of -# the form `vYYYY.MM.post1.dev<commit-distance>.g<git-hash>`. -# It may contain an additional `.dYYYYMMDD` timestamp appendix -# for dirty repositories. -# If the version contains a commit distance and hash the -# NeXus_repository attribute should be written with the -# repository url containing this version. -# -# Only used when the NAPI or pynxtools has written the file. -# Note that this is different from the version of the -# base class or application definition version number. +# Version of NeXus definitions used in writing the file. +# This may either be a date based version tag of the form `vYYYY.MM` +# or a version tag with a commit distance and source control (e.g., git) hash of +# the form `vYYYY.MM.post1.dev<commit-distance>.g<git-hash>`. +# It may contain an additional `.dYYYYMMDD` timestamp appendix +# for dirty repositories. +# If the version contains a commit distance and hash the +# NeXus_repository attribute should be written with the +# repository url containing this version. +# +# Only used when the NAPI or pynxtools has written the file. +# Note that this is different from the version of the +# base class or application definition version number. # # # @@ -179,61 +175,49 @@ NXroot(NXobject): # # # -# -# Version of HDF (version 4) library used in writing the file -# +# Version of HDF (version 4) library used in writing the file # # # -# Version of HDF5 library used in writing the file. -# -# Note this attribute is spelled with uppercase "V", -# different than other version attributes. +# Version of HDF5 library used in writing the file. +# +# Note this attribute is spelled with uppercase "V", +# different than other version attributes. # # # -# -# Version of XML support library used in writing the XML file -# +# Version of XML support library used in writing the XML file # # -# -# Version of h5py Python package used in writing the file -# +# Version of h5py Python package used in writing the file # # -# -# facility or program where file originated -# +# facility or program where file originated # # -# -# Version of facility or program used in writing the file -# +# Version of facility or program used in writing the file # -# -# -# entries -# +# +# entries # # # -# .. index:: find the default plottable data -# .. index:: plotting -# .. index:: default attribute value -# -# Declares which :ref:`NXentry` group contains -# the data to be shown by default. -# It is used to resolve ambiguity when -# more than one :ref:`NXentry` group exists. -# The value :ref:`names <validItemName>` the default :ref:`NXentry` group. The -# value must be the name of a child of the current group. The child must be a -# NeXus group or a link to a NeXus group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. +# .. index:: find the default plottable data +# .. index:: plotting +# .. index:: default attribute value +# +# Declares which :ref:`NXentry` group contains +# the data to be shown by default. +# It is used to resolve ambiguity when +# more than one :ref:`NXentry` group exists. +# The value :ref:`names <validItemName>` the default :ref:`NXentry` group. The +# value must be the name of a child of the current group. The child must be a +# NeXus group or a link to a NeXus group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. # # -# +# \ No newline at end of file diff --git a/base_classes/nyaml/NXsample.yaml b/base_classes/nyaml/NXsample.yaml index 5984e8c326..385a4a68ae 100644 --- a/base_classes/nyaml/NXsample.yaml +++ b/base_classes/nyaml/NXsample.yaml @@ -192,8 +192,7 @@ NXsample(NXobject): The position and orientation of the center of mass of the sample (NXbeam): doc: | - Details of beam incident on sample - used to calculate sample/beam interaction - point + Details of beam incident on sample - used to calculate sample/beam interaction point (NXsample_component): doc: | One group per sample component @@ -277,8 +276,7 @@ NXsample(NXobject): deprecated: | use ``magnetic_field``, see: https://github.com/nexusformat/definitions/issues/816 doc: | - magnetic_field_log.value is a link to e.g. - magnetic_field_env.sensor1.value_log.value + magnetic_field_log.value is a link to e.g. magnetic_field_env.sensor1.value_log.value magnetic_field_env(NXenvironment): doc: | Additional sample magnetic environment information @@ -292,8 +290,8 @@ NXsample(NXobject): short_title: doc: | 20 character fixed length sample description for legends - - # How is the string length limitation imposed by the XSD? + + # How is the string length limitation imposed by the XSD? rotation_angle(NX_FLOAT): unit: NX_ANGLE doc: | @@ -315,8 +313,7 @@ NXsample(NXobject): doc: | Any positioner (motor, PZT, ...) used to locate the sample (NXoff_geometry): - - # exists: ['min', '0'] + exists: ['min', '0'] doc: | This group describes the shape of the sample physical_form: @@ -367,7 +364,7 @@ NXsample(NXobject): to help define the path to the default dataset to be plotted. See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. - depends_on: + depends_on(NX_CHAR): doc: | 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 @@ -383,9 +380,9 @@ NXsample(NXobject): other component groups. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 786390e4cd2891c627c30e55aa0e78d473a61674d32b5a1771f5a75dfee1c262 -# -# +# 75b499ae75ff895a3902ff0f84852bd9acea5d27a2b607880ebf54d9c1f38ca7 +# +# # -# -# -# -# symbolic array lengths to be coordinated between various fields -# -# -# -# number of compositions -# -# -# -# -# number of temperatures -# -# -# -# -# number of values in applied electric field -# -# -# -# -# number of values in applied magnetic field -# -# -# -# -# number of values in applied pressure field -# -# -# -# -# number of values in applied stress field -# -# -# -# -# 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. -# -# -# -# Descriptive name of sample -# -# +# +# +# +# symbolic array lengths to be coordinated between various fields +# number of compositions +# number of temperatures +# number of values in applied electric field +# number of values in applied magnetic field +# number of values in applied pressure field +# number of values in applied stress field +# +# +# +# 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. +# +# +# Descriptive name of sample +# # -# -# Identification number or signatures of the sample used. -# -# -# -# -# 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. -# -# -# -# -# Sample temperature. This could be a scanned variable -# -# -# -# -# -# -# -# -# Applied electric field -# -# -# -# -# +# Identification number or signatures of the sample used. +# +# +# +# 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. +# +# +# +# Sample temperature. This could be a scanned variable +# +# +# +# +# +# Applied electric field +# +# +# # -# -# -# -# -# +# +# +# +# +# # -# -# -# -# Applied magnetic field -# -# -# -# -# +# +# +# Applied magnetic field +# +# +# # -# -# -# -# -# +# +# +# +# +# # -# -# -# -# Applied external stress field -# -# -# -# -# +# +# +# Applied external stress field +# +# +# # -# -# -# -# -# +# +# +# +# +# # -# -# -# -# Applied pressure -# -# -# -# -# -# -# -# -# Sample changer position -# -# -# -# -# Crystallography unit cell parameters a, b, and c -# -# -# -# -# -# -# -# Crystallography unit cell parameters alpha, beta, and gamma -# -# -# -# -# -# -# -# Unit cell parameters (lengths and angles) -# -# -# -# -# -# -# -# -# Volume of the unit cell -# -# -# -# -# -# -# -# This will follow the Busing-Levy convention: -# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 -# -# -# -# -# -# -# -# Orientation matrix of single crystal sample using Busing-Levy convention: -# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 -# -# -# -# -# -# -# -# -# -# UB matrix of single crystal sample using Busing-Levy convention: -# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is -# the multiplication of the orientation_matrix, given above, -# with the :math:`B` matrix which -# can be derived from the lattice constants. -# -# -# -# -# -# -# -# -# -# Mass of sample -# -# -# -# -# -# -# -# Density of sample -# -# -# +# +# +# Applied pressure +# +# +# +# +# +# Sample changer position +# +# +# Crystallography unit cell parameters a, b, and c +# +# +# +# +# +# Crystallography unit cell parameters alpha, beta, and gamma +# +# +# +# +# +# Unit cell parameters (lengths and angles) +# +# +# +# +# +# +# Volume of the unit cell +# +# +# +# +# +# +# This will follow the Busing-Levy convention: +# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 +# +# +# +# +# +# +# +# Orientation matrix of single crystal sample using Busing-Levy convention: +# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 +# +# +# +# +# +# +# +# +# +# UB matrix of single crystal sample using Busing-Levy convention: +# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is +# the multiplication of the orientation_matrix, given above, +# with the :math:`B` matrix which +# can be derived from the lattice constants. +# +# +# +# +# +# +# +# +# Mass of sample +# +# +# +# +# +# Density of sample +# +# +# +# +# +# Relative Molecular Mass of sample +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# 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. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Description of the sample +# +# +# +# Date of preparation of the sample +# +# +# The position and orientation of the center of mass of the sample +# +# +# Details of beam incident on sample - used to calculate sample/beam interaction point +# +# +# +# One group per sample component +# This is the perferred way of recording per component information over the n_comp arrays +# +# +# +# Details of the component of the sample and/or can +# +# +# +# +# +# Type of component +# +# +# +# +# +# +# +# +# +# +# +# Concentration of each component +# +# +# +# +# +# Volume fraction of each component +# +# +# +# +# +# Scattering length density of each component +# +# +# +# +# +# +# In case it is all we know and we want to record/document it +# +# +# +# +# +# +# +# +# +# +# +# +# Crystallographic space group +# +# +# +# +# +# Crystallographic point group, deprecated if space_group present +# +# # -# -# -# -# Relative Molecular Mass of sample -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# 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. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Description of the sample -# -# -# -# -# Date of preparation of the sample -# -# -# -# -# The position and orientation of the center of mass of the sample -# +# +# +# +# Path length through sample/can for simple case when +# it does not vary with scattering direction +# +# +# +# +# Thickness of a beam entry/exit window on the can (mm) +# - assumed same for entry and exit +# +# +# +# sample thickness +# +# +# As a function of Wavelength +# +# +# temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value +# +# +# Additional sample temperature environment information +# +# +# magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value +# +# +# magnetic_field_log.value is a link to e.g. magnetic_field_env.sensor1.value_log.value +# +# +# Additional sample magnetic environment information +# +# +# value sent to user's sample setup +# +# +# logged value (or logic state) read from user's setup +# +# +# 20 character fixed length sample description for legends +# +# +# +# +# Optional rotation angle for the case when the powder diagram has +# been obtained through an omega-2theta scan like from a traditional +# single detector powder diffractometer. +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# Translation of the sample along the X-direction of the laboratory coordinate system +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# Translation of the sample along the Z-direction of the laboratory coordinate system. +# Note, it is recommended to use NXtransformations instead. +# +# +# +# Any positioner (motor, PZT, ...) used to locate the sample # -# +# # -# Details of beam incident on sample - used to calculate sample/beam interaction -# point -# -# -# -# -# One group per sample component -# This is the perferred way of recording per component information over the n_comp arrays -# -# -# -# -# Details of the component of the sample and/or can -# -# -# -# -# -# -# -# Type of component -# -# -# -# -# -# -# -# -# -# -# -# -# -# Concentration of each component -# -# -# -# -# -# -# -# Volume fraction of each component -# -# -# -# -# -# -# -# Scattering length density of each component -# -# -# -# -# -# -# -# In case it is all we know and we want to record/document it -# -# -# -# -# -# -# -# -# -# -# -# -# -# Crystallographic space group -# -# -# -# -# -# -# -# Crystallographic point group, deprecated if space_group present -# -# -# -# -# -# -# -# Path length through sample/can for simple case when -# it does not vary with scattering direction -# -# -# -# -# Thickness of a beam entry/exit window on the can (mm) -# - assumed same for entry and exit -# -# -# -# -# sample thickness -# -# -# -# -# As a function of Wavelength -# -# -# -# -# temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value -# -# -# -# -# Additional sample temperature environment information -# -# -# -# -# magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value -# -# -# -# -# magnetic_field_log.value is a link to e.g. -# magnetic_field_env.sensor1.value_log.value -# -# -# -# -# Additional sample magnetic environment information -# -# -# -# -# value sent to user's sample setup -# -# -# -# -# logged value (or logic state) read from user's setup -# -# -# -# -# 20 character fixed length sample description for legends -# -# -# -# -# -# Optional rotation angle for the case when the powder diagram has -# been obtained through an omega-2theta scan like from a traditional -# single detector powder diffractometer. -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# Translation of the sample along the X-direction of the laboratory coordinate system -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# Translation of the sample along the Z-direction of the laboratory coordinate system. -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# Any positioner (motor, PZT, ...) used to locate the sample -# -# -# -# -# -# This group describes the shape of the sample +# This group describes the shape of the sample # # # @@ -911,9 +809,7 @@ NXsample(NXobject): # # # -# +# # # Any environmental or external stimuli/measurements. # These can include, among others: @@ -928,33 +824,33 @@ NXsample(NXobject): # # # -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. # # -# +# # -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. +# 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. # # # # -# 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. # # # diff --git a/base_classes/nyaml/NXsample_component.yaml b/base_classes/nyaml/NXsample_component.yaml index b2f22bbeba..803366d140 100644 --- a/base_classes/nyaml/NXsample_component.yaml +++ b/base_classes/nyaml/NXsample_component.yaml @@ -1,7 +1,6 @@ category: base doc: | - One group like this per component can be recorded For a sample consisting of - multiple components. + One group like this per component can be recorded for a sample consisting of multiple components. symbols: doc: | symbolic array lengths to be coordinated between various fields @@ -62,8 +61,7 @@ NXsample_component(NXobject): sample_orientation(NX_FLOAT): unit: NX_ANGLE doc: | - This will follow the Busing and Levy convention from Acta.Crysta v22, p457 - (1967) + This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) dimensions: rank: 1 dim: [[1, 3]] @@ -128,6 +126,9 @@ NXsample_component(NXobject): (NXfabrication): doc: | Details about the sample component vendor (company or research group) + identifier(NXidentifier): + doc: | + An (ideally) globally unique identifier for the sample component. history(NXhistory): doc: | A set of physical processes that occurred to the sample component prior/during @@ -149,9 +150,9 @@ NXsample_component(NXobject): for a summary of the discussion. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2584e9026c3e7ee5302e2a4797acd4fe32603984fe172eec2441a2e8ad586872 -# -# +# 4ae2b93583186ce2a10567a007ad729f8b5442fb1c2d8051a941745ed9a6bc99 +# +# # -# -# -# -# symbolic array lengths to be coordinated between various fields -# -# -# -# number of temperatures -# -# -# -# -# number of values in applied electric field -# -# -# -# -# number of values in applied magnetic field -# -# -# -# -# number of values in applied pressure field -# -# -# -# -# number of values in applied stress field -# -# -# -# -# One group like this per component can be recorded For a sample consisting of -# multiple components. -# -# -# -# Descriptive name of sample component -# -# +# +# +# +# symbolic array lengths to be coordinated between various fields +# number of temperatures +# number of values in applied electric field +# number of values in applied magnetic field +# number of values in applied pressure field +# number of values in applied stress field +# +# +# +# One group like this per component can be recorded for a sample consisting of multiple components. +# +# +# Descriptive name of sample component +# # # # Identification number or signatures of the sample component used. # # -# -# -# The chemical formula specified using CIF conventions. -# 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. -# -# -# -# -# Crystallography unit cell parameters a, b, and c -# -# -# -# -# -# -# -# Crystallography unit cell parameters alpha, beta, and gamma -# -# -# -# -# -# -# -# Volume of the unit cell -# -# -# -# -# This will follow the Busing and Levy convention from Acta.Crysta v22, p457 -# (1967) -# -# -# -# -# -# -# -# Orientation matrix of single crystal sample component. -# This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) -# -# -# -# -# -# -# -# -# Mass of sample component -# -# -# -# -# Density of sample component -# -# -# -# -# Relative Molecular Mass of sample component -# -# -# -# -# Description of the sample component -# -# -# -# -# Volume fraction of component -# -# -# -# -# Scattering length density of component -# -# -# -# -# In case it is all we know and we want to record/document it -# -# -# -# -# -# -# -# -# -# -# -# -# -# Crystallographic space group -# -# -# -# -# Crystallographic point group, deprecated if space_group present -# -# -# -# -# As a function of Wavelength -# -# +# +# +# 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. +# +# +# +# Crystallography unit cell parameters a, b, and c +# +# +# +# +# +# Crystallography unit cell parameters alpha, beta, and gamma +# +# +# +# +# +# Volume of the unit cell +# +# +# This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) +# +# +# +# +# +# +# Orientation matrix of single crystal sample component. +# This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) +# +# +# +# +# +# +# +# Mass of sample component +# +# +# Density of sample component +# +# +# Relative Molecular Mass of sample component +# +# +# +# Description of the sample component +# +# +# +# Volume fraction of component +# +# +# Scattering length density of component +# +# +# +# In case it is all we know and we want to record/document it +# +# +# +# +# +# +# +# +# +# +# +# +# Crystallographic space group +# +# +# Crystallographic point group, deprecated if space_group present +# +# +# As a function of Wavelength +# # # # If the component is a single crystal, add description of single crystal and unit @@ -364,6 +322,11 @@ NXsample_component(NXobject): # Details about the sample component vendor (company or research group) # # +# +# +# An (ideally) globally unique identifier for the sample component. +# +# # # # A set of physical processes that occurred to the sample component prior/during @@ -378,15 +341,15 @@ NXsample_component(NXobject): # # # -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. # # -# +# \ No newline at end of file diff --git a/base_classes/nyaml/NXsensor.yaml b/base_classes/nyaml/NXsensor.yaml index 1fe18c3f24..f3159ced7d 100644 --- a/base_classes/nyaml/NXsensor.yaml +++ b/base_classes/nyaml/NXsensor.yaml @@ -21,8 +21,7 @@ NXsensor(NXobject): deprecated: | Use the field `depends_on` and :ref:`NXtransformations` to position the beamstop and NXoff_geometry to describe its shape instead doc: | - Defines the axes for logged vector quantities if they are not the global - instrument axes. + Defines the axes for logged vector quantities if they are not the global instrument axes. measurement: doc: | name for measured signal @@ -129,9 +128,9 @@ NXsensor(NXobject): other component groups. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 6d710cebca8ca188bc40cc8ca1c26df9636e44cac48b28289cc2228e8876828c -# -# +# 784fc1e5cc5954136412e7aa2fc149bf1be1f61cd6a9a5d52863eb85c51ad100 +# +# # -# -# -# A sensor used to monitor an external condition -# -# The condition itself is described in :ref:`NXenvironment`. -# -# -# -# Sensor identification code/model number -# -# -# -# -# Name for the sensor -# -# -# -# -# Short name of sensor used e.g. on monitor display program -# -# -# -# -# where sensor is attached to ("sample" | "can") -# -# -# -# -# Defines the axes for logged vector quantities if they are not the global -# instrument axes. -# -# -# -# -# name for measured signal -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The type of hardware used for the measurement. -# Examples (suggestions but not restrictions): -# -# :Temperature: -# J | K | T | E | R | S | Pt100 | Rh/Fe -# :pH: -# Hg/Hg2Cl2 | Ag/AgCl | ISFET -# :Ion selective electrode: -# specify species; e.g. Ca2+ -# :Magnetic field: -# Hall -# :Surface pressure: -# wilhelmy plate -# -# -# -# -# Is data collection controlled or synchronised to this quantity: -# 1=no, 0=to "value", 1=to "value_deriv1", etc. -# -# -# -# -# Upper control bound of sensor reading if using run_control -# -# -# -# -# Lower control bound of sensor reading if using run_control -# -# -# -# -# nominal setpoint or average value -# - need [n] as may be a vector -# -# -# -# -# -# -# -# Nominal/average first derivative of value -# e.g. strain rate -# - same dimensions as "value" (may be a vector) -# -# -# -# -# -# -# -# Nominal/average second derivative of value -# - same dimensions as "value" (may be a vector) -# -# -# -# -# -# -# -# Time history of sensor readings -# -# -# -# -# Time history of first derivative of sensor readings -# -# -# -# -# Time history of second derivative of sensor readings -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# For complex external fields not satisfied by External_field_brief -# -# -# -# -# This group describes the shape of the sensor when necessary. -# -# +# +# +# A sensor used to monitor an external condition +# +# The condition itself is described in :ref:`NXenvironment`. +# +# +# Sensor identification code/model number +# +# +# Name for the sensor +# +# +# Short name of sensor used e.g. on monitor display program +# +# +# where sensor is attached to ("sample" | "can") +# +# +# +# Defines the axes for logged vector quantities if they are not the global instrument axes. +# +# +# +# name for measured signal +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The type of hardware used for the measurement. +# Examples (suggestions but not restrictions): +# +# :Temperature: +# J | K | T | E | R | S | Pt100 | Rh/Fe +# :pH: +# Hg/Hg2Cl2 | Ag/AgCl | ISFET +# :Ion selective electrode: +# specify species; e.g. Ca2+ +# :Magnetic field: +# Hall +# :Surface pressure: +# wilhelmy plate +# +# +# +# +# Is data collection controlled or synchronised to this quantity: +# 1=no, 0=to "value", 1=to "value_deriv1", etc. +# +# +# +# +# Upper control bound of sensor reading if using run_control +# +# +# +# +# Lower control bound of sensor reading if using run_control +# +# +# +# +# nominal setpoint or average value +# - need [n] as may be a vector +# +# +# +# +# +# +# +# Nominal/average first derivative of value +# e.g. strain rate +# - same dimensions as "value" (may be a vector) +# +# +# +# +# +# +# +# Nominal/average second derivative of value +# - same dimensions as "value" (may be a vector) +# +# +# +# +# +# +# Time history of sensor readings +# +# +# Time history of first derivative of sensor readings +# +# +# Time history of second derivative of sensor readings +# +# +# +# +# +# +# +# +# +# +# +# +# For complex external fields not satisfied by External_field_brief +# +# +# +# This group describes the shape of the sensor when necessary. +# +# # # # -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. # # # # -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a sensor. +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a sensor. +# # # # # -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. # # # diff --git a/base_classes/nyaml/NXsource.yaml b/base_classes/nyaml/NXsource.yaml index 4d5b0f6788..7c8886d9c6 100644 --- a/base_classes/nyaml/NXsource.yaml +++ b/base_classes/nyaml/NXsource.yaml @@ -102,13 +102,13 @@ NXsource(NXobject): unit: NX_TIME doc: | temporal width of source pulse - - # pulsed sources or storage rings could use this + + # pulsed sources or storage rings could use this pulse_shape(NXdata): doc: | source pulse shape - - # pulsed sources or storage rings could use this + + # pulsed sources or storage rings could use this mode: doc: | source operating mode @@ -119,8 +119,10 @@ NXsource(NXobject): Multi Bunch: doc: | for storage rings - - # other sources could add to this + + # other sources could add to this + + # other sources could add to this top_up(NX_BOOLEAN): doc: | Is the synchrotron operating in top_up mode? @@ -179,7 +181,7 @@ NXsource(NXobject): exists: ['min', '0'] doc: | This group describes the shape of the beam line component - distribution(NXdata): + (NXdata)distribution: doc: | The wavelength or energy distribution of the source \@default: @@ -215,9 +217,9 @@ NXsource(NXobject): other component groups. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2e2112dcd5b309b4339af1ac92e7ff2d12e639c98146519a85e6f4bdd85adbb2 -# -# +# edccdd67915ffe14c9ecf03d1a5d57cacb6522a3a62b0f4882cc01bc43ee4f52 +# +# # -# -# -# Radiation source emitting a beam. -# -# Examples include particle sources (electrons, neutrons, protons) or sources for electromagnetic radiation (photons). -# This base class can also be used to describe neutron or x-ray storage ring/facilities. -# -# -# -# Effective distance from sample -# Distance as seen by radiation from sample. This number should be negative -# to signify that it is upstream of the sample. -# -# -# -# -# Name of source -# -# -# -# short name for source, perhaps the acronym -# -# -# -# -# -# type of radiation source (pick one from the enumerated list and spell exactly) -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# type of radiation probe (pick one from the enumerated list and spell exactly) -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Source power -# -# -# -# -# Source emittance (nm-rad) in X (horizontal) direction. -# -# -# -# -# Source emittance (nm-rad) in Y (horizontal) direction. -# -# -# -# -# particle beam size in x -# -# -# -# -# particle beam size in y -# -# -# -# -# Source intensity/area (example: s-1 cm-2) -# -# -# -# -# Source energy. Typically, this would be the energy of -# the emitted beam. For storage rings, this would be -# the particle beam energy. -# -# -# -# -# Accelerator, X-ray tube, or storage ring current -# -# -# -# -# Accelerator voltage -# -# -# -# -# Frequency of pulsed source -# -# -# -# -# Period of pulsed source -# -# -# -# -# Pulsed source target material -# -# -# -# -# -# -# -# -# -# -# -# -# -# any source/facility related messages/events that -# occurred during the experiment -# -# -# -# -# For storage rings, description of the bunch pattern. -# This is useful to describe irregular bunch patterns. -# -# -# -# name of the bunch pattern -# -# -# -# -# -# For storage rings, the number of bunches in use. -# -# -# -# -# For storage rings, temporal length of the bunch -# -# -# -# -# For storage rings, time between bunches -# -# -# -# -# temporal width of source pulse -# -# -# -# -# -# source pulse shape -# -# -# -# -# -# source operating mode -# -# -# -# -# for storage rings -# -# -# -# -# for storage rings -# -# -# -# -# -# -# -# Is the synchrotron operating in top_up mode? -# -# -# -# -# For storage rings, the current at the end of the most recent injection. -# -# -# -# date and time of the most recent injection. -# -# -# -# -# -# The wavelength of the radiation emitted by the source. -# -# -# -# -# For pulsed sources, the energy of a single pulse. -# -# -# -# -# For pulsed sources, the pulse energy divided -# by the pulse duration -# -# -# -# -# Material of the anode (for X-ray tubes). -# -# -# -# -# Filament current (for X-ray tubes). -# -# -# -# -# Emission current of the generated beam. -# -# -# -# -# Gas pressure inside ionization source. -# -# -# -# -# "Engineering" location of source. -# -# -# -# -# The size and position of an aperture inside the source. -# -# -# -# -# Deflectors inside the source. -# -# -# -# -# Individual electromagnetic lenses inside the source. -# -# -# -# -# -# This group describes the shape of the beam line component -# -# -# -# -# The wavelength or energy distribution of the source -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the -# z axis. -# -# .. image:: source/source.png -# :width: 40% -# -# -# -# -# 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. -# -# -# +# +# +# Radiation source emitting a beam. +# +# Examples include particle sources (electrons, neutrons, protons) or sources for electromagnetic radiation (photons). +# This base class can also be used to describe neutron or x-ray storage ring/facilities. +# +# +# +# Effective distance from sample +# Distance as seen by radiation from sample. This number should be negative +# to signify that it is upstream of the sample. +# +# +# +# Name of source +# +# short name for source, perhaps the acronym +# +# +# +# type of radiation source (pick one from the enumerated list and spell exactly) +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# type of radiation probe (pick one from the enumerated list and spell exactly) +# +# +# +# +# +# +# +# +# +# +# +# +# +# Source power +# +# +# Source emittance (nm-rad) in X (horizontal) direction. +# +# +# Source emittance (nm-rad) in Y (horizontal) direction. +# +# +# particle beam size in x +# +# +# particle beam size in y +# +# +# Source intensity/area (example: s-1 cm-2) +# +# +# +# Source energy. Typically, this would be the energy of +# the emitted beam. For storage rings, this would be +# the particle beam energy. +# +# +# +# Accelerator, X-ray tube, or storage ring current +# +# +# Accelerator voltage +# +# +# Frequency of pulsed source +# +# +# Period of pulsed source +# +# +# Pulsed source target material +# +# +# +# +# +# +# +# +# +# +# +# +# any source/facility related messages/events that +# occurred during the experiment +# +# +# +# +# For storage rings, description of the bunch pattern. +# This is useful to describe irregular bunch patterns. +# +# name of the bunch pattern +# +# +# For storage rings, the number of bunches in use. +# +# +# For storage rings, temporal length of the bunch +# +# +# For storage rings, time between bunches +# +# +# temporal width of source pulse +# +# +# source pulse shape +# +# +# source operating mode +# +# for storage rings +# for storage rings +# +# +# +# +# Is the synchrotron operating in top_up mode? +# +# +# For storage rings, the current at the end of the most recent injection. +# date and time of the most recent injection. +# +# +# +# The wavelength of the radiation emitted by the source. +# +# +# +# +# For pulsed sources, the energy of a single pulse. +# +# +# +# +# For pulsed sources, the pulse energy divided +# by the pulse duration +# +# +# +# +# Material of the anode (for X-ray tubes). +# +# +# +# +# Filament current (for X-ray tubes). +# +# +# +# +# Emission current of the generated beam. +# +# +# +# +# Gas pressure inside ionization source. +# +# +# +# +# "Engineering" location of source. +# +# +# +# +# The size and position of an aperture inside the source. +# +# +# +# +# Deflectors inside the source. +# +# +# +# +# Individual electromagnetic lenses inside the source. +# +# +# +# +# +# This group describes the shape of the beam line component +# +# +# +# The wavelength or energy distribution of the source +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the +# z axis. +# +# .. image:: source/source.png +# :width: 40% +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# \ No newline at end of file diff --git a/base_classes/nyaml/NXsubentry.yaml b/base_classes/nyaml/NXsubentry.yaml index 77aa2e7ed0..ce49877348 100644 --- a/base_classes/nyaml/NXsubentry.yaml +++ b/base_classes/nyaml/NXsubentry.yaml @@ -153,8 +153,8 @@ NXsubentry(NXobject): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ # 237d41832bec5b07f576fdda3791b9810addebf81b0700da0815e1b4fdca0c14 -# -# +# +# # -# -# -# Group of multiple application definitions for "multi-modal" (e.g. SAXS/WAXS) measurements. -# -# ``NXsubentry`` is a base class virtually identical to :ref:`NXentry` -# and is used as the (overlay) location for application definitions. -# Use a separate ``NXsubentry`` for each application definition. -# -# To use ``NXsubentry`` with a hypothetical application definition -# called ``NXmyappdef``: -# -# * Create a group with attribute ``NX_class="NXsubentry"`` -# * Within that group, create a field called ``definition="NXmyappdef"``. -# * There are two optional attributes of definition: ``version`` and ``URL`` -# -# The intended use is to define application definitions for a -# multi-modal (a.k.a. multi-technique) :ref:`NXentry`. -# Previously, an application definition -# replaced :ref:`NXentry` with its own definition. -# With the increasing popularity of instruments combining -# multiple techniques for data collection (such as SAXS/WAXS instruments), -# it was recognized the application definitions must be entered in the NeXus -# data file tree as children of :ref:`NXentry`. -# -# -# -# .. 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 <validItemName>` the default :ref:`NXentry` group. The -# value must be the name of a child of the current group. The child must be a -# NeXus group or a link to a NeXus group. -# -# For more information about how NeXus identifies the default -# plottable data, see the -# :ref:`Find Plottable Data, v3 <Find-Plottable-Data-v3>` -# section. -# -# -# -# -# -# ISIS Muon IDF_Version -# -# -# -# -# Extended title for entry -# -# -# -# -# Unique identifier for the experiment, defined by -# the facility, possibly linked to the proposals -# -# -# -# -# Brief summary of the experiment, including key objectives. -# -# -# -# -# Description of the full experiment (document in pdf, latex, ...) -# -# -# -# -# User or Data Acquisition defined group of NeXus files or :ref:`NXentry` -# -# -# -# -# Brief summary of the collection, including grouping criteria. -# -# -# -# -# unique identifier for the measurement, defined by the facility. -# -# -# -# -# Official NeXus NXDL schema to which this subentry conforms -# -# -# -# NXDL version number -# -# -# -# -# URL of NXDL file -# -# -# -# -# -# Local NXDL schema extended from the subentry -# specified in the ``definition`` field. -# This contains any locally-defined, -# additional fields in the subentry. -# -# -# -# NXDL version number -# -# -# -# -# URL of NXDL file -# -# -# -# -# -# Starting time of measurement -# -# -# -# -# Ending time of measurement -# -# -# -# -# Duration of measurement -# -# -# -# -# Time transpired actually collecting data i.e. taking out time when collection was -# suspended due to e.g. temperature out of range -# -# -# -# -# Such as "2007-3". Some user facilities organize their beam time into run cycles. -# -# -# -# -# Name of program used to generate this file -# -# -# -# Program version number -# -# -# -# -# configuration of the program -# -# -# -# -# -# Revision id of the file due to re-calibration, reprocessing, new analysis, new -# instrument definition format, ... -# -# -# -# -# -# This is the flightpath before the sample position. This can be determined by a chopper, -# by the moderator or the source itself. In other words: it the distance to the component -# which gives the T0 signal to the detector electronics. If another component in the -# NXinstrument hierarchy provides this information, this should be a link. -# -# -# -# -# Notes describing entry -# -# -# -# -# A small image that is representative of the entry. An example of this is a 640x480 -# jpeg image automatically produced by a low resolution plot of the NXdata. -# -# -# -# The value should be an ``image/*`` -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# +# +# +# +# +# .. 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 <validItemName>` the default :ref:`NXentry` group. The +# value must be the name of a child of the current group. The child must be a +# NeXus group or a link to a NeXus group. +# +# For more information about how NeXus identifies the default +# plottable data, see the +# :ref:`Find Plottable Data, v3 <Find-Plottable-Data-v3>` +# section. +# +# +# +# +# Group of multiple application definitions for "multi-modal" (e.g. SAXS/WAXS) measurements. +# +# ``NXsubentry`` is a base class virtually identical to :ref:`NXentry` +# and is used as the (overlay) location for application definitions. +# Use a separate ``NXsubentry`` for each application definition. +# +# To use ``NXsubentry`` with a hypothetical application definition +# called ``NXmyappdef``: +# +# * Create a group with attribute ``NX_class="NXsubentry"`` +# * Within that group, create a field called ``definition="NXmyappdef"``. +# * There are two optional attributes of definition: ``version`` and ``URL`` +# +# The intended use is to define application definitions for a +# multi-modal (a.k.a. multi-technique) :ref:`NXentry`. +# Previously, an application definition +# replaced :ref:`NXentry` with its own definition. +# With the increasing popularity of instruments combining +# multiple techniques for data collection (such as SAXS/WAXS instruments), +# it was recognized the application definitions must be entered in the NeXus +# data file tree as children of :ref:`NXentry`. +# +# +# +# +# ISIS Muon IDF_Version +# +# +# +# Extended title for entry +# +# +# +# Unique identifier for the experiment, defined by +# the facility, possibly linked to the proposals +# +# +# +# Brief summary of the experiment, including key objectives. +# +# +# Description of the full experiment (document in pdf, latex, ...) +# +# +# User or Data Acquisition defined group of NeXus files or :ref:`NXentry` +# +# +# Brief summary of the collection, including grouping criteria. +# +# +# unique identifier for the measurement, defined by the facility. +# +# +# Official NeXus NXDL schema to which this subentry conforms +# NXDL version number +# URL of NXDL file +# +# +# +# Local NXDL schema extended from the subentry +# specified in the ``definition`` field. +# This contains any locally-defined, +# additional fields in the subentry. +# +# NXDL version number +# URL of NXDL file +# +# +# Starting time of measurement +# +# +# Ending time of measurement +# +# +# Duration of measurement +# +# +# +# Time transpired actually collecting data i.e. taking out time when collection was +# suspended due to e.g. temperature out of range +# +# +# +# Such as "2007-3". Some user facilities organize their beam time into run cycles. +# +# +# Name of program used to generate this file +# Program version number +# configuration of the program +# +# +# +# Revision id of the file due to re-calibration, reprocessing, new analysis, new +# instrument definition format, ... +# +# +# +# +# +# This is the flightpath before the sample position. This can be determined by a chopper, +# by the moderator or the source itself. In other words: it the distance to the component +# which gives the T0 signal to the detector electronics. If another component in the +# NXinstrument hierarchy provides this information, this should be a link. +# +# +# +# Notes describing entry +# +# +# +# A small image that is representative of the entry. An example of this is a 640x480 +# jpeg image automatically produced by a low resolution plot of the NXdata. +# +# +# The value should be an ``image/*`` +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# \ No newline at end of file diff --git a/base_classes/nyaml/NXtransformations.yaml b/base_classes/nyaml/NXtransformations.yaml index 1d57a9386a..0f567323d3 100644 --- a/base_classes/nyaml/NXtransformations.yaml +++ b/base_classes/nyaml/NXtransformations.yaml @@ -114,40 +114,40 @@ doc: | .. code-block:: - entry:NXentry - sample:NXsample - depends_on=transformations/phi - transformations:NXtransformations - phi=0 - @depends_on=chi - @transformation_type=rotation - @vector=[-1 -0.0037 -0.002] - @units=degrees - chi=0 - @depends_on=sam_x - @transformation_type=rotation - @vector=[0.0046 0.0372 0.9993] - @units=degrees - sam_x=0 - @depends_on=sam_y - @transformation_type=translation - @vector=[1 0 0] - @units=mm - sam_y=0 - @depends_on=sam_z - @transformation_type=translation - @vector=[0 1 0] - @units=mm - sam_z=0 - @depends_on=omega - @transformation_type=translation - @vector=[0 0 1] - @units=mm - omega=174 - @depends_on=. - @transformation_type=rotation - @vector=[-1 0 0] - @units=degrees + entry:NXentry + sample:NXsample + depends_on=transformations/phi + transformations:NXtransformations + phi=0 + @depends_on=chi + @transformation_type=rotation + @vector=[-1 -0.0037 -0.002] + @units=degrees + chi=0 + @depends_on=sam_x + @transformation_type=rotation + @vector=[0.0046 0.0372 0.9993] + @units=degrees + sam_x=0 + @depends_on=sam_y + @transformation_type=translation + @vector=[1 0 0] + @units=mm + sam_y=0 + @depends_on=sam_z + @transformation_type=translation + @vector=[0 1 0] + @units=mm + sam_z=0 + @depends_on=omega + @transformation_type=translation + @vector=[0 0 1] + @units=mm + omega=174 + @depends_on=. + @transformation_type=rotation + @vector=[-1 0 0] + @units=degrees **Example 2: different coordinate system** @@ -182,52 +182,52 @@ doc: | .. code-block:: - entry:NXentry - instrument:NXinstrument - vertical:NXdetector - depends_on=position/distance - position:NXtransformations - distance=10 # move downstream from the sample - @depends_on=polar - @units=cm - @vector=[1 0 0] - polar=5 # title above the horizontal plane - @depends_on=azimuth - @units=degrees - @vector=[0 -1 0] - azimuth=0 # stay in the vertical plane - @depends_on=/entry/coordinate_system/beam - @units=degrees - @vector=[-1 0 0] - horizontal:NXdetector - depends_on=position/distance - position:NXtransformations - distance=11 # move downstream from the sample - @depends_on=polar - @units=cm - @vector=[1 0 0] - polar=6 # title above the horizontal plane - @depends_on=azimuth - @units=degrees - @vector=[0 -1 0] - azimuth=90 # rotate to the horizontal plane - @depends_on=/entry/coordinate_system/beam - @units=degrees - @vector=[-1 0 0] - transmission:NXdetector - depends_on=position/distance - position:NXtransformations - distance=20 # move downstream from the sample - @depends_on=/entry/coordinate_system/beam - @units=cm - @vector=[1 0 0] - coordinate_system:NXtransformations - beam=NaN # value is never used - @depends_on=gravity - @vector=[1 0 0] # X-axis points in the beam direction - gravity=NaN # value is never used - @depends_on=. # end of the chain - @vector=[0 0 -1] # Z-axis points up + entry:NXentry + instrument:NXinstrument + vertical:NXdetector + depends_on=position/distance + position:NXtransformations + distance=10 # move downstream from the sample + @depends_on=polar + @units=cm + @vector=[1 0 0] + polar=5 # title above the horizontal plane + @depends_on=azimuth + @units=degrees + @vector=[0 -1 0] + azimuth=0 # stay in the vertical plane + @depends_on=/entry/coordinate_system/beam + @units=degrees + @vector=[-1 0 0] + horizontal:NXdetector + depends_on=position/distance + position:NXtransformations + distance=11 # move downstream from the sample + @depends_on=polar + @units=cm + @vector=[1 0 0] + polar=6 # title above the horizontal plane + @depends_on=azimuth + @units=degrees + @vector=[0 -1 0] + azimuth=90 # rotate to the horizontal plane + @depends_on=/entry/coordinate_system/beam + @units=degrees + @vector=[-1 0 0] + transmission:NXdetector + depends_on=position/distance + position:NXtransformations + distance=20 # move downstream from the sample + @depends_on=/entry/coordinate_system/beam + @units=cm + @vector=[1 0 0] + coordinate_system:NXtransformations + beam=NaN # value is never used + @depends_on=gravity + @vector=[1 0 0] # X-axis points in the beam direction + gravity=NaN # value is never used + @depends_on=. # end of the chain + @vector=[0 0 -1] # Z-axis points up type: group ignoreExtraGroups: true ignoreExtraFields: true @@ -257,7 +257,8 @@ NXtransformations(NXobject): 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. + coordinate frame. In this case the value of the ``AXISNAME`` field + is not used and can be set to the number ``NaN``. # enumeration: [translation, rotation] @@ -305,7 +306,7 @@ NXtransformations(NXobject): AXISNAME_end(NX_NUMBER): unit: NX_TRANSFORMATION nameType: any - exists: ['min', '0'] + exists: ['min', '0', 'max', 'unbounded'] doc: | ``AXISNAME_end`` is a placeholder for a name constructed from the actual name of an axis to which ``_end`` has been appended. @@ -338,14 +339,14 @@ NXtransformations(NXobject): for a summary of the discussion. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 9fe265099bd7f15a00e1f244948ae17ceb523ee01b164cc947ac5f14e9f68917 -# -# +# 8abd1266eafaa897cf8781251b0af8817c3761a2b9ac075682d60a3878df2c2c +# +# # -# -# -# 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 :ref:`McSTAS coordinate frame<Design-CoordinateSystem>` -# is assumed, but additional useful coordinate axes may be defined by using axes for which -# no transformation type has been specified. -# -# **Transformation chain** -# -# The entry point of a chain of transformations is a field called ``depends_on`` -# will be outside of this class and points 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` -# which in turn depends on :math:`T_3`, the final *active* transformation -# matrix :math:`T_f` is -# -# .. math:: T_f = T_3 . T_2 . T_1 -# -# For example when positioning a flat detector, its pixel positions in the laboratory -# reference frame (:ref:`McSTAS coordinate frame<Design-CoordinateSystem>` by default) -# can be calculated by -# -# .. math:: X_\text{lab} = T_f . X_\text{pixel} = T_3 . T_2 . T_1 . X_\text{pixel} -# -# Note that :math:`T_1` comes first in the *depends-on* chain and is also applied first -# to the pixel coordinates. -# -# When we say transformation :math:`A` *depends on* transformation :math:`B` we mean that -# the physical motor that realizes :math:`A` is *stacked on top of* the motor that realizes :math:`B`. -# So the activate coordinate transformation :math:`A` needs to be applied to a coordinate -# before applying :math:`B`. In other words :math:`X' = B . A . X`. -# -# **Transformation matrix** -# -# In explicit terms, the transformations are a subset of affine transformations expressed as -# 4x4 active transformation matrices that act on homogeneous coordinates, :math:`X=[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. -# -# **Usage** -# -# 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 description 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. -# -# **Example 1: goniometer** -# -# Position a sample mounted on a goniometer in the :ref:`McSTAS coordinate frame<Design-CoordinateSystem>`. -# -# The sample is oriented as follows -# -# .. math:: X_\text{lab} = R(\vec{v}_\omega, \omega) . -# T(\vec{v}_z, \text{sam}_z) . -# T(\vec{v}_y, \text{sam}_y) . -# T(\vec{v}_x, \text{sam}_x) . -# R(\vec{v}_\chi, \chi) . -# R(\vec{v}_\varphi, \varphi) . X_s -# -# where -# -# * :math:`R(\vec{v},a)` is a rotation around vector :math:`\vec{v}` with angle :math:`a` -# * :math:`T(\vec{u},t)` is a translation along vector :math:`\vec{u}` over a distance :math:`t` -# * :math:`X_s` a coordinate in the sample reference frame. -# -# .. code-block:: -# -# entry:NXentry -# sample:NXsample -# depends_on=transformations/phi -# transformations:NXtransformations -# phi=0 -# @depends_on=chi -# @transformation_type=rotation -# @vector=[-1 -0.0037 -0.002] -# @units=degrees -# chi=0 -# @depends_on=sam_x -# @transformation_type=rotation -# @vector=[0.0046 0.0372 0.9993] -# @units=degrees -# sam_x=0 -# @depends_on=sam_y -# @transformation_type=translation -# @vector=[1 0 0] -# @units=mm -# sam_y=0 -# @depends_on=sam_z -# @transformation_type=translation -# @vector=[0 1 0] -# @units=mm -# sam_z=0 -# @depends_on=omega -# @transformation_type=translation -# @vector=[0 0 1] -# @units=mm -# omega=174 -# @depends_on=. -# @transformation_type=rotation -# @vector=[-1 0 0] -# @units=degrees -# -# **Example 2: different coordinate system** -# -# Define a laboratory reference frame with the X-axis along the beam and the Z-axis opposite to the direction of gravity. -# Three point detectors are positioned in this reference: -# -# * *transmission*: -# * point detector in the beam -# * 20 cm downstream from the sample (the origin of the reference frame) -# * *vertical*: -# * point detector 10 cm downstream from the sample -# * making an angle of 5 degrees with the beam w.r.t. the sample -# * positioned in the XZ-plane above the XY-plane -# * *horizontal*: -# * point detector 11 cm downstream from the sample -# * making an angle of 6 degrees with the beam w.r.t. the sample -# * positioned in the XY-plane above the XZ-plane -# -# The coordinates of the point detectors in the laboratory reference frame are -# -# * *transmission*: :math:`X_\text{lab} = T_x(20) . X_d` -# * *vertical*: :math:`X_\text{lab} = R_y(-5) . T_x(10) . X_d` -# * *horizontal*: :math:`X_\text{lab} = R_x(-90) . R_y(-6) . T_x(11) . X_d` -# -# where -# -# * :math:`T_x`, :math:`T_y`, :math:`T_z`: active transformation matrices for translation along the X, Y and Z axes -# * :math:`R_x`, :math:`R_y`, :math:`R_z`: active transformation matrices for rotation around the X, Y and Z axes -# * :math:`X_d` is a coordinate in the detector reference frame. -# -# Note that as these are point detectors, we only have one coordinate :math:`X_d=[0,0,0,1]^T`. -# -# .. code-block:: -# -# entry:NXentry -# instrument:NXinstrument -# vertical:NXdetector -# depends_on=position/distance -# position:NXtransformations -# distance=10 # move downstream from the sample -# @depends_on=polar -# @units=cm -# @vector=[1 0 0] -# polar=5 # title above the horizontal plane -# @depends_on=azimuth -# @units=degrees -# @vector=[0 -1 0] -# azimuth=0 # stay in the vertical plane -# @depends_on=/entry/coordinate_system/beam -# @units=degrees -# @vector=[-1 0 0] -# horizontal:NXdetector -# depends_on=position/distance -# position:NXtransformations -# distance=11 # move downstream from the sample -# @depends_on=polar -# @units=cm -# @vector=[1 0 0] -# polar=6 # title above the horizontal plane -# @depends_on=azimuth -# @units=degrees -# @vector=[0 -1 0] -# azimuth=90 # rotate to the horizontal plane -# @depends_on=/entry/coordinate_system/beam -# @units=degrees -# @vector=[-1 0 0] -# transmission:NXdetector -# depends_on=position/distance -# position:NXtransformations -# distance=20 # move downstream from the sample -# @depends_on=/entry/coordinate_system/beam -# @units=cm -# @vector=[1 0 0] -# coordinate_system:NXtransformations -# beam=NaN # value is never used -# @depends_on=gravity -# @vector=[1 0 0] # X-axis points in the beam direction -# gravity=NaN # value is never used -# @depends_on=. # end of the chain -# @vector=[0 0 -1] # Z-axis points up -# -# -# -# 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``. -# -# -# -# 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. -# -# -# -# -# -# -# -# -# -# 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. -# -# -# -# -# -# -# -# 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. -# -# -# -# -# -# -# -# Units of the offset. Values should be consistent with NX_LENGTH. -# -# -# -# -# Points to the path of a field defining the axis on which this instance of -# NXtransformations depends or the string ".". It can also point to an instance of -# ``NX_coordinate_system`` if this transformation depends on it. -# -# -# -# -# An arbitrary identifier of a component of the equipment to which -# the transformation belongs, such as 'detector_arm' or 'detector_module'. -# NXtransformations with the same equipment_component label form a logical -# grouping which can be combined together into a single change-of-basis -# operation. -# -# -# -# -# -# ``AXISNAME_end`` is a placeholder for a name constructed from the actual -# name of an axis to which ``_end`` has been appended. -# -# The values in this field are the end points of the motions that start -# at the corresponding positions given in the ``AXISNAME`` field. -# -# -# -# -# ``AXISNAME_increment_set`` is a placeholder for a name constructed from the actual -# name of an axis to which ``_increment_set`` has been appended. -# -# The value of this optional field is the intended average range through which -# the corresponding axis moves during the exposure of a frame. Ideally, the -# value of this field added to each value of ``AXISNAME`` would agree with the -# corresponding values of ``AXISNAME_end``, but there is a possibility of significant -# differences. Use of ``AXISNAME_end`` is recommended. -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# +# +# +# +# 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 :ref:`McSTAS coordinate frame<Design-CoordinateSystem>` +# is assumed, but additional useful coordinate axes may be defined by using axes for which +# no transformation type has been specified. +# +# **Transformation chain** +# +# The entry point of a chain of transformations is a field called ``depends_on`` +# will be outside of this class and points 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` +# which in turn depends on :math:`T_3`, the final *active* transformation +# matrix :math:`T_f` is +# +# .. math:: T_f = T_3 . T_2 . T_1 +# +# For example when positioning a flat detector, its pixel positions in the laboratory +# reference frame (:ref:`McSTAS coordinate frame<Design-CoordinateSystem>` by default) +# can be calculated by +# +# .. math:: X_\text{lab} = T_f . X_\text{pixel} = T_3 . T_2 . T_1 . X_\text{pixel} +# +# Note that :math:`T_1` comes first in the *depends-on* chain and is also applied first +# to the pixel coordinates. +# +# When we say transformation :math:`A` *depends on* transformation :math:`B` we mean that +# the physical motor that realizes :math:`A` is *stacked on top of* the motor that realizes :math:`B`. +# So the activate coordinate transformation :math:`A` needs to be applied to a coordinate +# before applying :math:`B`. In other words :math:`X' = B . A . X`. +# +# **Transformation matrix** +# +# In explicit terms, the transformations are a subset of affine transformations expressed as +# 4x4 active transformation matrices that act on homogeneous coordinates, :math:`X=[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. +# +# **Usage** +# +# 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 description 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. +# +# **Example 1: goniometer** +# +# Position a sample mounted on a goniometer in the :ref:`McSTAS coordinate frame<Design-CoordinateSystem>`. +# +# The sample is oriented as follows +# +# .. math:: X_\text{lab} = R(\vec{v}_\omega, \omega) . +# T(\vec{v}_z, \text{sam}_z) . +# T(\vec{v}_y, \text{sam}_y) . +# T(\vec{v}_x, \text{sam}_x) . +# R(\vec{v}_\chi, \chi) . +# R(\vec{v}_\varphi, \varphi) . X_s +# +# where +# +# * :math:`R(\vec{v},a)` is a rotation around vector :math:`\vec{v}` with angle :math:`a` +# * :math:`T(\vec{u},t)` is a translation along vector :math:`\vec{u}` over a distance :math:`t` +# * :math:`X_s` a coordinate in the sample reference frame. +# +# .. code-block:: +# +# entry:NXentry +# sample:NXsample +# depends_on=transformations/phi +# transformations:NXtransformations +# phi=0 +# @depends_on=chi +# @transformation_type=rotation +# @vector=[-1 -0.0037 -0.002] +# @units=degrees +# chi=0 +# @depends_on=sam_x +# @transformation_type=rotation +# @vector=[0.0046 0.0372 0.9993] +# @units=degrees +# sam_x=0 +# @depends_on=sam_y +# @transformation_type=translation +# @vector=[1 0 0] +# @units=mm +# sam_y=0 +# @depends_on=sam_z +# @transformation_type=translation +# @vector=[0 1 0] +# @units=mm +# sam_z=0 +# @depends_on=omega +# @transformation_type=translation +# @vector=[0 0 1] +# @units=mm +# omega=174 +# @depends_on=. +# @transformation_type=rotation +# @vector=[-1 0 0] +# @units=degrees +# +# **Example 2: different coordinate system** +# +# Define a laboratory reference frame with the X-axis along the beam and the Z-axis opposite to the direction of gravity. +# Three point detectors are positioned in this reference: +# +# * *transmission*: +# * point detector in the beam +# * 20 cm downstream from the sample (the origin of the reference frame) +# * *vertical*: +# * point detector 10 cm downstream from the sample +# * making an angle of 5 degrees with the beam w.r.t. the sample +# * positioned in the XZ-plane above the XY-plane +# * *horizontal*: +# * point detector 11 cm downstream from the sample +# * making an angle of 6 degrees with the beam w.r.t. the sample +# * positioned in the XY-plane above the XZ-plane +# +# The coordinates of the point detectors in the laboratory reference frame are +# +# * *transmission*: :math:`X_\text{lab} = T_x(20) . X_d` +# * *vertical*: :math:`X_\text{lab} = R_y(-5) . T_x(10) . X_d` +# * *horizontal*: :math:`X_\text{lab} = R_x(-90) . R_y(-6) . T_x(11) . X_d` +# +# where +# +# * :math:`T_x`, :math:`T_y`, :math:`T_z`: active transformation matrices for translation along the X, Y and Z axes +# * :math:`R_x`, :math:`R_y`, :math:`R_z`: active transformation matrices for rotation around the X, Y and Z axes +# * :math:`X_d` is a coordinate in the detector reference frame. +# +# Note that as these are point detectors, we only have one coordinate :math:`X_d=[0,0,0,1]^T`. +# +# .. code-block:: +# +# entry:NXentry +# instrument:NXinstrument +# vertical:NXdetector +# depends_on=position/distance +# position:NXtransformations +# distance=10 # move downstream from the sample +# @depends_on=polar +# @units=cm +# @vector=[1 0 0] +# polar=5 # title above the horizontal plane +# @depends_on=azimuth +# @units=degrees +# @vector=[0 -1 0] +# azimuth=0 # stay in the vertical plane +# @depends_on=/entry/coordinate_system/beam +# @units=degrees +# @vector=[-1 0 0] +# horizontal:NXdetector +# depends_on=position/distance +# position:NXtransformations +# distance=11 # move downstream from the sample +# @depends_on=polar +# @units=cm +# @vector=[1 0 0] +# polar=6 # title above the horizontal plane +# @depends_on=azimuth +# @units=degrees +# @vector=[0 -1 0] +# azimuth=90 # rotate to the horizontal plane +# @depends_on=/entry/coordinate_system/beam +# @units=degrees +# @vector=[-1 0 0] +# transmission:NXdetector +# depends_on=position/distance +# position:NXtransformations +# distance=20 # move downstream from the sample +# @depends_on=/entry/coordinate_system/beam +# @units=cm +# @vector=[1 0 0] +# coordinate_system:NXtransformations +# beam=NaN # value is never used +# @depends_on=gravity +# @vector=[1 0 0] # X-axis points in the beam direction +# gravity=NaN # value is never used +# @depends_on=. # end of the chain +# @vector=[0 0 -1] # Z-axis points up +# +# +# +# +# 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``. +# +# +# +# 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. In this case the value of the ``AXISNAME`` field +# is not used and can be set to the number ``NaN``. +# +# +# +# +# +# +# +# +# +# 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. +# +# +# +# +# +# +# +# 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. +# +# +# +# +# +# +# +# Units of the offset. Values should be consistent with NX_LENGTH. +# +# +# +# +# Points to the path of a field defining the axis on which this instance of +# NXtransformations depends or the string ".". It can also point to an instance of +# ``NX_coordinate_system`` if this transformation depends on it. +# +# +# +# +# An arbitrary identifier of a component of the equipment to which +# the transformation belongs, such as 'detector_arm' or 'detector_module'. +# NXtransformations with the same equipment_component label form a logical +# grouping which can be combined together into a single change-of-basis +# operation. +# +# +# +# +# +# ``AXISNAME_end`` is a placeholder for a name constructed from the actual +# name of an axis to which ``_end`` has been appended. +# +# The values in this field are the end points of the motions that start +# at the corresponding positions given in the ``AXISNAME`` field. +# +# +# +# +# ``AXISNAME_increment_set`` is a placeholder for a name constructed from the actual +# name of an axis to which ``_increment_set`` has been appended. +# +# The value of this optional field is the intended average range through which +# the corresponding axis moves during the exposure of a frame. Ideally, the +# value of this field added to each value of ``AXISNAME`` would agree with the +# corresponding values of ``AXISNAME_end``, but there is a possibility of significant +# differences. Use of ``AXISNAME_end`` is recommended. +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# \ No newline at end of file diff --git a/base_classes/nyaml/NXuser.yaml b/base_classes/nyaml/NXuser.yaml index 70c7ea26e8..0015eef603 100644 --- a/base_classes/nyaml/NXuser.yaml +++ b/base_classes/nyaml/NXuser.yaml @@ -55,13 +55,13 @@ NXuser(NXobject): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ # 23f00959a9d3d00b25aa5de9d27bd59c9931fcd3726f8c62e5ffb6e3c73860e2 -# -# +# +# # -# -# -# 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. -# -# -# -# Name of user responsible for this entry -# -# -# -# -# Role of user responsible for this entry. -# Suggested roles are "local_contact", -# "principal_investigator", and "proposer" -# -# -# -# -# Affiliation of user -# -# -# -# -# Address of user -# -# -# -# -# Telephone number of user -# -# -# -# -# Fax number of user -# -# -# -# -# Email of user -# -# -# -# -# facility based unique identifier for this person -# e.g. their identification code on the facility -# address/contact database -# -# -# +# +# +# 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. +# +# +# Name of user responsible for this entry +# +# +# +# Role of user responsible for this entry. +# Suggested roles are "local_contact", +# "principal_investigator", and "proposer" +# +# +# +# Affiliation of user +# +# +# Address of user +# +# +# Telephone number of user +# +# +# Fax number of user +# +# +# Email of user +# +# +# +# facility based unique identifier for this person +# e.g. their identification code on the facility +# address/contact database +# +# +# # # Details about an author code, open researcher, or contributor # (persistent) identifier, e.g. defined by https://orcid.org and expressed @@ -140,15 +132,15 @@ NXuser(NXobject): # # # -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. # # -# +# \ No newline at end of file From 2590928b989282121e1a747688ccfc3ea37496c0 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 17 Sep 2024 17:51:14 +0200 Subject: [PATCH 0960/1012] revert changes to NXtransformations docs --- base_classes/NXtransformations.nxdl.xml | 213 ++---------- base_classes/nyaml/NXtransformations.yaml | 399 +++------------------- 2 files changed, 74 insertions(+), 538 deletions(-) diff --git a/base_classes/NXtransformations.nxdl.xml b/base_classes/NXtransformations.nxdl.xml index 6130240311..fd40f89e48 100644 --- a/base_classes/NXtransformations.nxdl.xml +++ b/base_classes/NXtransformations.nxdl.xml @@ -55,42 +55,23 @@ * ``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 :ref:`McSTAS coordinate frame<Design-CoordinateSystem>` - is assumed, but additional useful coordinate axes may be defined by using axes for which - no transformation type has been specified. + 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. - **Transformation chain** - - The entry point of a chain of transformations is a field called ``depends_on`` - will be outside of this class and points 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. + 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` - which in turn depends on :math:`T_3`, the final *active* transformation - matrix :math:`T_f` is - - .. math:: T_f = T_3 . T_2 . T_1 - - For example when positioning a flat detector, its pixel positions in the laboratory - reference frame (:ref:`McSTAS coordinate frame<Design-CoordinateSystem>` by default) - can be calculated by - - .. math:: X_\text{lab} = T_f . X_\text{pixel} = T_3 . T_2 . T_1 . X_\text{pixel} + and that in turn depends on :math:`T_3`, the final transformation :math:`T_f` is - Note that :math:`T_1` comes first in the *depends-on* chain and is also applied first - to the pixel coordinates. + .. math:: T_f = T_3 T_2 T_1 - When we say transformation :math:`A` *depends on* transformation :math:`B` we mean that - the physical motor that realizes :math:`A` is *stacked on top of* the motor that realizes :math:`B`. - So the activate coordinate transformation :math:`A` needs to be applied to a coordinate - before applying :math:`B`. In other words :math:`X' = B . A . X`. - - **Transformation matrix** - - In explicit terms, the transformations are a subset of affine transformations expressed as - 4x4 active transformation matrices that act on homogeneous coordinates, :math:`X=[x,y,z,1]^T`. + 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, @@ -104,8 +85,8 @@ 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. - **Usage** - + 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 @@ -113,7 +94,8 @@ Collecting the motors of a sample table or xyz-stage in an NXtransformations group is equally possible. - Following the section on the general description of axis in NXtransformations is a section which + + 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 @@ -126,143 +108,6 @@ * depends_on as needed. - - **Example 1: goniometer** - - Position a sample mounted on a goniometer in the :ref:`McSTAS coordinate frame<Design-CoordinateSystem>`. - - The sample is oriented as follows - - .. math:: X_\text{lab} = R(\vec{v}_\omega, \omega) . - T(\vec{v}_z, \text{sam}_z) . - T(\vec{v}_y, \text{sam}_y) . - T(\vec{v}_x, \text{sam}_x) . - R(\vec{v}_\chi, \chi) . - R(\vec{v}_\varphi, \varphi) . X_s - - where - - * :math:`R(\vec{v},a)` is a rotation around vector :math:`\vec{v}` with angle :math:`a` - * :math:`T(\vec{u},t)` is a translation along vector :math:`\vec{u}` over a distance :math:`t` - * :math:`X_s` a coordinate in the sample reference frame. - - .. code-block:: - - entry:NXentry - sample:NXsample - depends_on=transformations/phi - transformations:NXtransformations - phi=0 - @depends_on=chi - @transformation_type=rotation - @vector=[-1 -0.0037 -0.002] - @units=degrees - chi=0 - @depends_on=sam_x - @transformation_type=rotation - @vector=[0.0046 0.0372 0.9993] - @units=degrees - sam_x=0 - @depends_on=sam_y - @transformation_type=translation - @vector=[1 0 0] - @units=mm - sam_y=0 - @depends_on=sam_z - @transformation_type=translation - @vector=[0 1 0] - @units=mm - sam_z=0 - @depends_on=omega - @transformation_type=translation - @vector=[0 0 1] - @units=mm - omega=174 - @depends_on=. - @transformation_type=rotation - @vector=[-1 0 0] - @units=degrees - - **Example 2: different coordinate system** - - Define a laboratory reference frame with the X-axis along the beam and the Z-axis opposite to the direction of gravity. - Three point detectors are positioned in this reference: - - * *transmission*: - * point detector in the beam - * 20 cm downstream from the sample (the origin of the reference frame) - * *vertical*: - * point detector 10 cm downstream from the sample - * making an angle of 5 degrees with the beam w.r.t. the sample - * positioned in the XZ-plane above the XY-plane - * *horizontal*: - * point detector 11 cm downstream from the sample - * making an angle of 6 degrees with the beam w.r.t. the sample - * positioned in the XY-plane above the XZ-plane - - The coordinates of the point detectors in the laboratory reference frame are - - * *transmission*: :math:`X_\text{lab} = T_x(20) . X_d` - * *vertical*: :math:`X_\text{lab} = R_y(-5) . T_x(10) . X_d` - * *horizontal*: :math:`X_\text{lab} = R_x(-90) . R_y(-6) . T_x(11) . X_d` - - where - - * :math:`T_x`, :math:`T_y`, :math:`T_z`: active transformation matrices for translation along the X, Y and Z axes - * :math:`R_x`, :math:`R_y`, :math:`R_z`: active transformation matrices for rotation around the X, Y and Z axes - * :math:`X_d` is a coordinate in the detector reference frame. - - Note that as these are point detectors, we only have one coordinate :math:`X_d=[0,0,0,1]^T`. - - .. code-block:: - - entry:NXentry - instrument:NXinstrument - vertical:NXdetector - depends_on=position/distance - position:NXtransformations - distance=10 # move downstream from the sample - @depends_on=polar - @units=cm - @vector=[1 0 0] - polar=5 # title above the horizontal plane - @depends_on=azimuth - @units=degrees - @vector=[0 -1 0] - azimuth=0 # stay in the vertical plane - @depends_on=/entry/coordinate_system/beam - @units=degrees - @vector=[-1 0 0] - horizontal:NXdetector - depends_on=position/distance - position:NXtransformations - distance=11 # move downstream from the sample - @depends_on=polar - @units=cm - @vector=[1 0 0] - polar=6 # title above the horizontal plane - @depends_on=azimuth - @units=degrees - @vector=[0 -1 0] - azimuth=90 # rotate to the horizontal plane - @depends_on=/entry/coordinate_system/beam - @units=degrees - @vector=[-1 0 0] - transmission:NXdetector - depends_on=position/distance - position:NXtransformations - distance=20 # move downstream from the sample - @depends_on=/entry/coordinate_system/beam - @units=cm - @vector=[1 0 0] - coordinate_system:NXtransformations - beam=NaN # value is never used - @depends_on=gravity - @vector=[1 0 0] # X-axis points in the beam direction - gravity=NaN # value is never used - @depends_on=. # end of the chain - @vector=[0 0 -1] # Z-axis points up - @@ -361,17 +206,17 @@ differences. Use of ``AXISNAME_end`` is recommended. - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - + + + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + + \ No newline at end of file diff --git a/base_classes/nyaml/NXtransformations.yaml b/base_classes/nyaml/NXtransformations.yaml index 0f567323d3..0b4ee74536 100644 --- a/base_classes/nyaml/NXtransformations.yaml +++ b/base_classes/nyaml/NXtransformations.yaml @@ -21,42 +21,23 @@ doc: | * ``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 :ref:`McSTAS coordinate frame` - is assumed, but additional useful coordinate axes may be defined by using axes for which - no transformation type has been specified. + 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. - **Transformation chain** - - The entry point of a chain of transformations is a field called ``depends_on`` - will be outside of this class and points 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. + 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` - which in turn depends on :math:`T_3`, the final *active* transformation - matrix :math:`T_f` is - - .. math:: T_f = T_3 . T_2 . T_1 - - For example when positioning a flat detector, its pixel positions in the laboratory - reference frame (:ref:`McSTAS coordinate frame` by default) - can be calculated by - - .. math:: X_\text{lab} = T_f . X_\text{pixel} = T_3 . T_2 . T_1 . X_\text{pixel} + and that in turn depends on :math:`T_3`, the final transformation :math:`T_f` is - Note that :math:`T_1` comes first in the *depends-on* chain and is also applied first - to the pixel coordinates. + .. math:: T_f = T_3 T_2 T_1 - When we say transformation :math:`A` *depends on* transformation :math:`B` we mean that - the physical motor that realizes :math:`A` is *stacked on top of* the motor that realizes :math:`B`. - So the activate coordinate transformation :math:`A` needs to be applied to a coordinate - before applying :math:`B`. In other words :math:`X' = B . A . X`. - - **Transformation matrix** - - In explicit terms, the transformations are a subset of affine transformations expressed as - 4x4 active transformation matrices that act on homogeneous coordinates, :math:`X=[x,y,z,1]^T`. + 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, @@ -70,7 +51,7 @@ doc: | 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. - **Usage** + NOTE One possible use of ``NXtransformations`` is to define the motors and transformations for a diffractometer (goniometer). Such use is mentioned @@ -79,7 +60,8 @@ doc: | Collecting the motors of a sample table or xyz-stage in an NXtransformations group is equally possible. - Following the section on the general description of axis in NXtransformations is a section which + + 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 @@ -92,142 +74,6 @@ doc: | * depends_on as needed. - - **Example 1: goniometer** - - Position a sample mounted on a goniometer in the :ref:`McSTAS coordinate frame`. - - The sample is oriented as follows - - .. math:: X_\text{lab} = R(\vec{v}_\omega, \omega) . - T(\vec{v}_z, \text{sam}_z) . - T(\vec{v}_y, \text{sam}_y) . - T(\vec{v}_x, \text{sam}_x) . - R(\vec{v}_\chi, \chi) . - R(\vec{v}_\varphi, \varphi) . X_s - - where - - * :math:`R(\vec{v},a)` is a rotation around vector :math:`\vec{v}` with angle :math:`a` - * :math:`T(\vec{u},t)` is a translation along vector :math:`\vec{u}` over a distance :math:`t` - * :math:`X_s` a coordinate in the sample reference frame. - - .. code-block:: - - entry:NXentry - sample:NXsample - depends_on=transformations/phi - transformations:NXtransformations - phi=0 - @depends_on=chi - @transformation_type=rotation - @vector=[-1 -0.0037 -0.002] - @units=degrees - chi=0 - @depends_on=sam_x - @transformation_type=rotation - @vector=[0.0046 0.0372 0.9993] - @units=degrees - sam_x=0 - @depends_on=sam_y - @transformation_type=translation - @vector=[1 0 0] - @units=mm - sam_y=0 - @depends_on=sam_z - @transformation_type=translation - @vector=[0 1 0] - @units=mm - sam_z=0 - @depends_on=omega - @transformation_type=translation - @vector=[0 0 1] - @units=mm - omega=174 - @depends_on=. - @transformation_type=rotation - @vector=[-1 0 0] - @units=degrees - - **Example 2: different coordinate system** - - Define a laboratory reference frame with the X-axis along the beam and the Z-axis opposite to the direction of gravity. - Three point detectors are positioned in this reference: - - * *transmission*: - * point detector in the beam - * 20 cm downstream from the sample (the origin of the reference frame) - * *vertical*: - * point detector 10 cm downstream from the sample - * making an angle of 5 degrees with the beam w.r.t. the sample - * positioned in the XZ-plane above the XY-plane - * *horizontal*: - * point detector 11 cm downstream from the sample - * making an angle of 6 degrees with the beam w.r.t. the sample - * positioned in the XY-plane above the XZ-plane - - The coordinates of the point detectors in the laboratory reference frame are - - * *transmission*: :math:`X_\text{lab} = T_x(20) . X_d` - * *vertical*: :math:`X_\text{lab} = R_y(-5) . T_x(10) . X_d` - * *horizontal*: :math:`X_\text{lab} = R_x(-90) . R_y(-6) . T_x(11) . X_d` - - where - - * :math:`T_x`, :math:`T_y`, :math:`T_z`: active transformation matrices for translation along the X, Y and Z axes - * :math:`R_x`, :math:`R_y`, :math:`R_z`: active transformation matrices for rotation around the X, Y and Z axes - * :math:`X_d` is a coordinate in the detector reference frame. - - Note that as these are point detectors, we only have one coordinate :math:`X_d=[0,0,0,1]^T`. - - .. code-block:: - - entry:NXentry - instrument:NXinstrument - vertical:NXdetector - depends_on=position/distance - position:NXtransformations - distance=10 # move downstream from the sample - @depends_on=polar - @units=cm - @vector=[1 0 0] - polar=5 # title above the horizontal plane - @depends_on=azimuth - @units=degrees - @vector=[0 -1 0] - azimuth=0 # stay in the vertical plane - @depends_on=/entry/coordinate_system/beam - @units=degrees - @vector=[-1 0 0] - horizontal:NXdetector - depends_on=position/distance - position:NXtransformations - distance=11 # move downstream from the sample - @depends_on=polar - @units=cm - @vector=[1 0 0] - polar=6 # title above the horizontal plane - @depends_on=azimuth - @units=degrees - @vector=[0 -1 0] - azimuth=90 # rotate to the horizontal plane - @depends_on=/entry/coordinate_system/beam - @units=degrees - @vector=[-1 0 0] - transmission:NXdetector - depends_on=position/distance - position:NXtransformations - distance=20 # move downstream from the sample - @depends_on=/entry/coordinate_system/beam - @units=cm - @vector=[1 0 0] - coordinate_system:NXtransformations - beam=NaN # value is never used - @depends_on=gravity - @vector=[1 0 0] # X-axis points in the beam direction - gravity=NaN # value is never used - @depends_on=. # end of the chain - @vector=[0 0 -1] # Z-axis points up type: group ignoreExtraGroups: true ignoreExtraFields: true @@ -339,7 +185,7 @@ NXtransformations(NXobject): for a summary of the discussion. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8abd1266eafaa897cf8781251b0af8817c3761a2b9ac075682d60a3878df2c2c +# cc6c5475afdcad3cf47b731a16b58acf04d00e3ba9d82f32430c5a60b1532fc5 # # # Metadata of the atom probe or field-ion microscope instrument, henceforth called microscope or instrument, and the lab in which it stands. - - - Possibility to include a detailed computational geometry description of the - instrument. - - + Given name of the microscope as defined by the hosting lab. This is an alias. diff --git a/contributed_definitions/NXapm_sim.nxdl.xml b/contributed_definitions/NXapm_sim.nxdl.xml index edc55a2a03..90ac529f2f 100644 --- a/contributed_definitions/NXapm_sim.nxdl.xml +++ b/contributed_definitions/NXapm_sim.nxdl.xml @@ -22,19 +22,11 @@ # For further information, see http://www.nexusformat.org --> +mirroring the design of NXem_msr/NXem_sim, NXem can be used for experiment and simulation--> - Base class for simulating ion extraction from matter via laser and/or voltage pulsing. - - Ideally, we would like to describe the workflow of experiments and simulations of - atom probe and field-evaporation simulation research in more detail and contextualize - better descriptions of experiments and computer simulations. - The strategy to achieve this is detailed in the introducing docstring of - :ref:`NXapm_msr`. This :ref:`NXapm_sim` base class is envisioned as the - twin of the :ref:`NXapm_msr` base class. + Base class for simulating ion extraction from matter via laser and/or voltage + pulsing. diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 24365acb08..d4b5388641 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -1515,9 +1515,10 @@ is required to provide such information in this way!--> - + diff --git a/contributed_definitions/nyaml/NXapm_msr.yaml b/contributed_definitions/nyaml/NXapm_msr.yaml index 3c0792807a..c9a15fd480 100644 --- a/contributed_definitions/nyaml/NXapm_msr.yaml +++ b/contributed_definitions/nyaml/NXapm_msr.yaml @@ -78,9 +78,9 @@ NXapm_msr(NXobject): # when evolving these ideas further inherit from NXapm_met doc: | Metadata of the atom probe or field-ion microscope instrument, henceforth called microscope or instrument, and the lab in which it stands. - (NXcsg): - doc: | - Possibility to include a detailed computational geometry description of the instrument. + # (NXcsg): + # doc: | + # Possibility to include a detailed computational geometry description of the instrument. instrument_name(NX_CHAR): doc: | Given name of the microscope as defined by the hosting lab. This is an alias. diff --git a/contributed_definitions/nyaml/NXapm_sim.yaml b/contributed_definitions/nyaml/NXapm_sim.yaml index 9f584c1019..bf95b17664 100644 --- a/contributed_definitions/nyaml/NXapm_sim.yaml +++ b/contributed_definitions/nyaml/NXapm_sim.yaml @@ -1,16 +1,7 @@ category: base doc: | Base class for simulating ion extraction from matter via laser and/or voltage pulsing. - - Ideally, we would like to describe the workflow of experiments and simulations of - atom probe and field-evaporation simulation research in more detail and contextualize - better descriptions of experiments and computer simulations. - The strategy to achieve this is detailed in the introducing docstring of - :ref:`NXapm_msr`. This :ref:`NXapm_sim` base class is envisioned as the - twin of the :ref:`NXapm_msr` base class. -# noteworthy the situation is similar to electron microscopy especially TEM where factually -# interpretation without simulations is pointless. The only difference is that in EM there -# is a large availability of documentation and open-source tools for performing such simulations. +# mirroring the design of NXem_msr/NXem_sim, NXem can be used for experiment and simulation type: group -NXapm_sim(NXobject): # when evolving these ideas further inherit from NXapm_method instead +NXapm_sim(NXobject): (NXprogram): diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index 1e287c91fc..bae35b1446 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -1327,8 +1327,8 @@ NXem(NXobject): exists: [min, 0, max, infty] half_angle_interval(NX_NUMBER): exists: optional - microstructureID(NXmicrostructure): - exists: optional + # microstructureID(NXmicrostructure): + # exists: optional ebsd(NXem_ebsd): exists: optional # remains to be discussed based on examples From 139d6647462edb09d3f6fece27be4d9a6a197fdb Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 18 Sep 2024 15:20:57 +0200 Subject: [PATCH 0964/1012] fix dev_tools tests black code style --- dev_tools/tests/test_nxdl_utils.py | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/dev_tools/tests/test_nxdl_utils.py b/dev_tools/tests/test_nxdl_utils.py index d39d0dab25..ba6b14f252 100644 --- a/dev_tools/tests/test_nxdl_utils.py +++ b/dev_tools/tests/test_nxdl_utils.py @@ -49,9 +49,7 @@ def test_get_node_at_nxdl_path(): ) assert node.attrib["name"] == "long_name" - nxdl_file_path = os.path.join( - local_dir, "../../contributed_definitions/NXem.nxdl.xml" - ) + nxdl_file_path = os.path.join(local_dir, "../../applications/NXem.nxdl.xml") elem = ET.parse(nxdl_file_path).getroot() node = nexus.get_node_at_nxdl_path( "/ENTRY/measurement/EVENT_DATA_EM_SET/EVENT_DATA_EM/end_time", elem=elem From 4abdc46cfdc11756f956dea1114bb87a1ffd70d9 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 18 Sep 2024 16:33:02 +0200 Subject: [PATCH 0965/1012] remove use of details_summary_hide --- manual/source/conf.py | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/manual/source/conf.py b/manual/source/conf.py index aa3c496fc0..aa2e4a524a 100755 --- a/manual/source/conf.py +++ b/manual/source/conf.py @@ -95,6 +95,7 @@ } def setup(app): app.add_css_file('to_rtd.css') + app.add_css_file('details_summary_hide.css') elif html_theme== 'alabaster': # Alabaster allows a very high degree of control form Sphinx conf.py html_sidebars = { '**': [ @@ -131,6 +132,7 @@ def setup(app): } def setup(app): app.add_css_file('to_alabaster.css') + app.add_css_file('details_summary_hide.css') else: html_sidebars = { '**': [ @@ -141,9 +143,8 @@ def setup(app): 'google_search.html' ], } - -def setup(app): - app.add_css_file('details_summary_hide.css') + def setup(app): + app.add_css_file('details_summary_hide.css') # The name of an image file (within the static path) to use as favicon of the # docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32 From d20af524459a5b81e0f2fea33f96bc84a4d3e5f1 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 19 Sep 2024 11:28:11 +0200 Subject: [PATCH 0966/1012] change refs in NXarpes --- applications/NXarpes.nxdl.xml | 4 ++-- applications/nyaml/NXarpes.yaml | 10 +++++----- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/applications/NXarpes.nxdl.xml b/applications/NXarpes.nxdl.xml index e792d30adb..9905347b5c 100644 --- a/applications/NXarpes.nxdl.xml +++ b/applications/NXarpes.nxdl.xml @@ -34,8 +34,8 @@ This definition is a legacy support for older NXarpes experiments. There is, however, a newer definition to collect data & metadata - for general photoemission experiments, called :ref:NXmpes, - as well as a specialization for ARPES experiments, called :ref:NXmpes_arpes." + for general photoemission experiments, called :ref:`NXmpes`, + as well as a specialization for ARPES experiments, called :ref:`NXmpes_arpes`." diff --git a/applications/nyaml/NXarpes.yaml b/applications/nyaml/NXarpes.yaml index f39a331d30..406be3dc17 100644 --- a/applications/nyaml/NXarpes.yaml +++ b/applications/nyaml/NXarpes.yaml @@ -6,8 +6,8 @@ doc: | This definition is a legacy support for older NXarpes experiments. There is, however, a newer definition to collect data & metadata - for general photoemission experiments, called :ref:NXmpes, - as well as a specialization for ARPES experiments, called :ref:NXmpes_arpes." + for general photoemission experiments, called :ref:`NXmpes`, + as well as a specialization for ARPES experiments, called :ref:`NXmpes_arpes`." type: group NXarpes(NXobject): (NXentry): @@ -94,7 +94,7 @@ NXarpes(NXobject): (NXdata): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e784cdaecf56854c79a01b60711ee9c499ac4c8d12e5d7f72651309e8663baa3 +# 363b137225f9c57941ef040096f1917d9e68c69ff17e7f3ecd9024f18df65325 # # # - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index 8fcfe0e523..a1926fef46 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -631,11 +631,11 @@ to sample_reference_frame Number of scan points in the original mapping. - - - - - + An overview of the entire ROI. diff --git a/contributed_definitions/NXem_img.nxdl.xml b/contributed_definitions/NXem_img.nxdl.xml index 096865a50a..5574965371 100644 --- a/contributed_definitions/NXem_img.nxdl.xml +++ b/contributed_definitions/NXem_img.nxdl.xml @@ -53,11 +53,9 @@ - - - A reconstruction of the microstructure or some of its features - based on image information in the parent class. - - + diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index bae35b1446..9831335bbb 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -1383,35 +1383,35 @@ NXem(NXobject): space_group(NX_CHAR): phase_identifier(NX_INT): phase_name(NX_CHAR): - ipfID(NXmicrostructure_ipf): - exists: recommended - projection_direction(NX_NUMBER): - map(NXdata): - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): - title(NX_CHAR): - data(NX_NUMBER): - \@long_name(NX_CHAR): - axis_x(NX_NUMBER): - \@long_name(NX_CHAR): - axis_y(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - axis_z(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - legend(NXdata): - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): - title(NX_CHAR): - data(NX_NUMBER): - \@long_name(NX_CHAR): - axis_x(NX_NUMBER): - \@long_name(NX_CHAR): - axis_y(NX_NUMBER): - \@long_name(NX_CHAR): + # ipfID(NXmicrostructure_ipf): + # exists: recommended + # projection_direction(NX_NUMBER): + # map(NXdata): + # \@signal(NX_CHAR): + # \@axes(NX_CHAR): + # \@AXISNAME_indices(NX_INT): + # title(NX_CHAR): + # data(NX_NUMBER): + # \@long_name(NX_CHAR): + # axis_x(NX_NUMBER): + # \@long_name(NX_CHAR): + # axis_y(NX_NUMBER): + # exists: optional + # \@long_name(NX_CHAR): + # axis_z(NX_NUMBER): + # exists: optional + # \@long_name(NX_CHAR): + # legend(NXdata): + # \@signal(NX_CHAR): + # \@axes(NX_CHAR): + # \@AXISNAME_indices(NX_INT): + # title(NX_CHAR): + # data(NX_NUMBER): + # \@long_name(NX_CHAR): + # axis_x(NX_NUMBER): + # \@long_name(NX_CHAR): + # axis_y(NX_NUMBER): + # \@long_name(NX_CHAR): roi(NXdata): exists: recommended \@signal(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXem_ebsd.yaml b/contributed_definitions/nyaml/NXem_ebsd.yaml index b6fb3dba97..69b4f9c5bc 100644 --- a/contributed_definitions/nyaml/NXem_ebsd.yaml +++ b/contributed_definitions/nyaml/NXem_ebsd.yaml @@ -444,10 +444,10 @@ NXem_ebsd(NXem_method): doc: | Number of scan points in the original mapping. unit: NX_UNITLESS - odfID(NXmicrostructure_odf): - pfID(NXmicrostructure_pf): - ipfID(NXmicrostructure_ipf): - microstructureID(NXmicrostructure): + # odfID(NXmicrostructure_odf): + # pfID(NXmicrostructure_pf): + # ipfID(NXmicrostructure_ipf): + # microstructureID(NXmicrostructure): # overview over the entire map, rediscretized on a tight aabb roi(NXdata): doc: | diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml index 015e6fa7dc..7f1fe5273e 100644 --- a/contributed_definitions/nyaml/NXem_img.yaml +++ b/contributed_definitions/nyaml/NXem_img.yaml @@ -21,7 +21,7 @@ NXem_img(NXem_method): Annulus inner (first value) and outer (second value) half angle. unit: NX_ANGLE dim: (2,) - (NXmicrostructure): - doc: | - A reconstruction of the microstructure or some of its features - based on image information in the parent class. + # (NXmicrostructure): + # doc: | + # A reconstruction of the microstructure or some of its features + # based on image information in the parent class. From 4e485a6cb4b185da158439b6e6c726e628eb1740 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 19 Sep 2024 15:18:45 +0200 Subject: [PATCH 0969/1012] Revert one more microstructure --- contributed_definitions/NXcrystal_structure.nxdl.xml | 8 ++++---- contributed_definitions/nyaml/NXcrystal_structure.yaml | 6 +++--- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 2e0a9c4146..e01993be3e 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -265,10 +265,10 @@ to describe the simulated Kikuchi pattern generated from such a model--> of the map were identified as that phase. - - - - diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml index d3d659c55f..9ec09dcd9c 100644 --- a/contributed_definitions/nyaml/NXcrystal_structure.yaml +++ b/contributed_definitions/nyaml/NXcrystal_structure.yaml @@ -164,9 +164,9 @@ NXcrystal_structure(NXobject): with analyzed orientation maps this field stores how many scan points of the map were identified as that phase. unit: NX_UNITLESS - ipfID(NXmicrostructure_ipf): - pfID(NXmicrostructure_pf): - odfID(NXmicrostructure_odf): + # ipfID(NXmicrostructure_ipf): + # pfID(NXmicrostructure_pf): + # odfID(NXmicrostructure_odf): # here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) # can give some good suggestions on how to improve and ideally make even # more general this section From 81d927caf89c9813fee24fa7ab9df1b74c9c45f9 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 19 Sep 2024 16:35:34 +0200 Subject: [PATCH 0970/1012] move new definitions to application and base_classes --- .../NXapm.nxdl.xml | 0 .../NXellipsometry.nxdl.xml | 0 .../NXem.nxdl.xml | 0 .../NXmpes.nxdl.xml | 0 .../NXmpes_arpes.nxdl.xml | 0 .../NXoptical_spectroscopy.nxdl.xml | 0 .../NXraman.nxdl.xml | 0 .../NXxps.nxdl.xml | 0 .../xps/xps_cs.png | Bin .../NXaberration.nxdl.xml | 0 .../NXactivity.nxdl.xml | 0 .../NXactuator.nxdl.xml | 0 .../NXapm_charge_state_analysis.nxdl.xml | 0 .../NXapm_hit_finding.nxdl.xml | 0 .../NXapm_msr.nxdl.xml | 0 .../NXapm_ranging.nxdl.xml | 0 .../NXapm_reconstruction.nxdl.xml | 0 .../NXapm_sim.nxdl.xml | 0 .../NXapm_volt_and_bowl.nxdl.xml | 0 .../NXbeam_device.nxdl.xml | 0 .../NXbeam_transfer_matrix_table.nxdl.xml | 0 .../NXcalibration.nxdl.xml | 0 .../NXcg_alpha_complex.nxdl.xml | 0 .../NXcg_cylinder_set.nxdl.xml | 0 .../NXcg_ellipsoid_set.nxdl.xml | 0 .../NXcg_face_list_data_structure.nxdl.xml | 0 .../NXcg_geodesic_mesh.nxdl.xml | 0 .../NXcg_grid.nxdl.xml | 0 .../NXcg_half_edge_data_structure.nxdl.xml | 0 .../NXcg_hexahedron_set.nxdl.xml | 0 .../NXcg_marching_cubes.nxdl.xml | 0 .../NXcg_parallelogram_set.nxdl.xml | 0 .../NXcg_point_set.nxdl.xml | 0 .../NXcg_polygon_set.nxdl.xml | 0 .../NXcg_polyhedron_set.nxdl.xml | 0 .../NXcg_polyline_set.nxdl.xml | 0 .../NXcg_primitive_set.nxdl.xml | 0 .../NXcg_roi_set.nxdl.xml | 0 .../NXcg_sphere_set.nxdl.xml | 0 .../NXcg_tetrahedron_set.nxdl.xml | 0 .../NXcg_triangle_set.nxdl.xml | 0 .../NXcg_triangulated_surface_mesh.nxdl.xml | 0 .../NXcg_unit_normal_set.nxdl.xml | 0 .../NXchamber.nxdl.xml | 0 .../NXchemical_composition.nxdl.xml | 0 .../NXchemical_process.nxdl.xml | 0 .../NXcircuit.nxdl.xml | 0 .../NXcollectioncolumn.nxdl.xml | 0 .../NXcomponent.nxdl.xml | 0 .../NXcoordinate_system.nxdl.xml | 0 .../NXcoordinate_system_set.nxdl.xml | 0 .../NXcorrector_cs.nxdl.xml | 0 .../NXcrystal_structure.nxdl.xml | 0 .../NXcs_computer.nxdl.xml | 0 .../NXcs_filter_boolean_mask.nxdl.xml | 0 .../NXcs_prng.nxdl.xml | 0 .../NXcs_profiling.nxdl.xml | 0 .../NXcs_profiling_event.nxdl.xml | 0 .../NXdata_mpes.nxdl.xml | 0 .../NXdata_mpes_detector.nxdl.xml | 0 .../NXdeflector.nxdl.xml | 0 .../NXdistortion.nxdl.xml | 0 .../NXebeam_column.nxdl.xml | 0 .../NXelectron_level.nxdl.xml | 0 .../NXelectronanalyser.nxdl.xml | 0 .../NXem_correlation.nxdl.xml | 0 .../NXem_ebsd.nxdl.xml | 0 .../NXem_eds.nxdl.xml | 0 .../NXem_eels.nxdl.xml | 0 .../NXem_img.nxdl.xml | 0 .../NXem_method.nxdl.xml | 0 .../NXem_msr.nxdl.xml | 0 .../NXem_sim.nxdl.xml | 0 .../NXenergydispersion.nxdl.xml | 0 .../NXevent_data_apm.nxdl.xml | 0 .../NXevent_data_apm_set.nxdl.xml | 0 .../NXevent_data_em.nxdl.xml | 0 .../NXevent_data_em_set.nxdl.xml | 0 .../NXfabrication.nxdl.xml | 0 .../NXfit.nxdl.xml | 0 .../NXfit_background.nxdl.xml | 0 .../NXfit_function.nxdl.xml | 0 .../NXfit_parameter.nxdl.xml | 0 .../NXhistory.nxdl.xml | 0 .../NXibeam_column.nxdl.xml | 0 .../NXidentifier.nxdl.xml | 0 .../NXimage_set.nxdl.xml | 0 .../NXinteraction_vol_em.nxdl.xml | 0 .../NXion.nxdl.xml | 0 .../NXlens_em.nxdl.xml | 0 .../NXlens_opt.nxdl.xml | 0 .../NXmanipulator.nxdl.xml | 0 .../NXopt_window.nxdl.xml | 0 .../NXoptical_system_em.nxdl.xml | 0 .../NXpeak.nxdl.xml | 0 .../NXphysical_process.nxdl.xml | 0 .../NXpid.nxdl.xml | 0 .../NXprocess_mpes.nxdl.xml | 0 .../NXprogram.nxdl.xml | 0 .../NXpulser_apm.nxdl.xml | 0 .../NXpump.nxdl.xml | 0 .../NXreflectron.nxdl.xml | 0 .../NXregistration.nxdl.xml | 0 .../NXresolution.nxdl.xml | 0 .../NXroi.nxdl.xml | 0 .../NXrotation_set.nxdl.xml | 0 .../NXsample_component_set.nxdl.xml | 0 .../NXscanbox_em.nxdl.xml | 0 .../NXserialized.nxdl.xml | 0 .../NXsingle_crystal.nxdl.xml | 0 .../NXspectrum_set.nxdl.xml | 0 .../NXspindispersion.nxdl.xml | 0 .../NXstage_lab.nxdl.xml | 0 .../NXsubstance.nxdl.xml | 0 .../NXunit_cell.nxdl.xml | 0 .../NXwaveplate.nxdl.xml | 0 .../nyaml/NXaberration.yaml | 108 - contributed_definitions/nyaml/NXactivity.yaml | 84 - contributed_definitions/nyaml/NXactuator.yaml | 208 -- contributed_definitions/nyaml/NXapm.yaml | 2170 ----------------- .../nyaml/NXapm_charge_state_analysis.yaml | 295 --- .../nyaml/NXapm_hit_finding.yaml | 246 -- contributed_definitions/nyaml/NXapm_msr.yaml | 311 --- .../nyaml/NXapm_ranging.yaml | 188 -- .../nyaml/NXapm_reconstruction.yaml | 205 -- contributed_definitions/nyaml/NXapm_sim.yaml | 50 - .../nyaml/NXapm_volt_and_bowl.yaml | 112 - .../nyaml/NXbeam_device.yaml | 106 - .../nyaml/NXbeam_transfer_matrix_table.yaml | 198 -- .../nyaml/NXcalibration.yaml | 372 --- .../nyaml/NXcg_alpha_complex.yaml | 211 -- .../nyaml/NXcg_cylinder_set.yaml | 255 -- .../nyaml/NXcg_ellipsoid_set.yaml | 100 - .../nyaml/NXcg_face_list_data_structure.yaml | 401 --- .../nyaml/NXcg_geodesic_mesh.yaml | 89 - contributed_definitions/nyaml/NXcg_grid.yaml | 265 -- .../nyaml/NXcg_half_edge_data_structure.yaml | 344 --- .../nyaml/NXcg_hexahedron_set.yaml | 345 --- .../nyaml/NXcg_marching_cubes.yaml | 91 - .../nyaml/NXcg_parallelogram_set.yaml | 181 -- .../nyaml/NXcg_point_set.yaml | 139 -- .../nyaml/NXcg_polygon_set.yaml | 224 -- .../nyaml/NXcg_polyhedron_set.yaml | 188 -- .../nyaml/NXcg_polyline_set.yaml | 237 -- .../nyaml/NXcg_primitive_set.yaml | 375 --- .../nyaml/NXcg_roi_set.yaml | 93 - .../nyaml/NXcg_sphere_set.yaml | 92 - .../nyaml/NXcg_tetrahedron_set.yaml | 138 -- .../nyaml/NXcg_triangle_set.yaml | 155 -- .../nyaml/NXcg_triangulated_surface_mesh.yaml | 60 - .../nyaml/NXcg_unit_normal_set.yaml | 120 - contributed_definitions/nyaml/NXchamber.yaml | 58 - .../nyaml/NXchemical_composition.yaml | 110 - .../nyaml/NXchemical_process.yaml | 90 - contributed_definitions/nyaml/NXcircuit.yaml | 227 -- .../nyaml/NXcollectioncolumn.yaml | 219 -- .../nyaml/NXcomponent.yaml | 99 - .../nyaml/NXcoordinate_system.yaml | 266 -- .../nyaml/NXcoordinate_system_set.yaml | 417 ---- .../nyaml/NXcorrector_cs.yaml | 414 ---- .../nyaml/NXcrystal_structure.yaml | 201 -- .../nyaml/NXcs_computer.yaml | 229 -- .../nyaml/NXcs_filter_boolean_mask.yaml | 191 -- contributed_definitions/nyaml/NXcs_prng.yaml | 134 - .../nyaml/NXcs_profiling.yaml | 263 -- .../nyaml/NXcs_profiling_event.yaml | 159 -- .../nyaml/NXdata_mpes.yaml | 239 -- .../nyaml/NXdata_mpes_detector.yaml | 261 -- .../nyaml/NXdeflector.yaml | 150 -- .../nyaml/NXdistortion.yaml | 175 -- .../nyaml/NXebeam_column.yaml | 196 -- .../nyaml/NXelectron_level.yaml | 1465 ----------- .../nyaml/NXelectronanalyser.yaml | 542 ---- .../nyaml/NXellipsometry.yaml | 724 ------ contributed_definitions/nyaml/NXem.yaml | 1468 ----------- .../nyaml/NXem_correlation.yaml | 450 ---- contributed_definitions/nyaml/NXem_ebsd.yaml | 1249 ---------- contributed_definitions/nyaml/NXem_eds.yaml | 390 --- contributed_definitions/nyaml/NXem_eels.yaml | 95 - contributed_definitions/nyaml/NXem_img.yaml | 28 - .../nyaml/NXem_method.yaml | 69 - contributed_definitions/nyaml/NXem_msr.yaml | 169 -- contributed_definitions/nyaml/NXem_sim.yaml | 97 - .../nyaml/NXenergydispersion.yaml | 369 --- .../nyaml/NXevent_data_apm.yaml | 510 ---- .../nyaml/NXevent_data_apm_set.yaml | 76 - .../nyaml/NXevent_data_em.yaml | 309 --- .../nyaml/NXevent_data_em_set.yaml | 80 - .../nyaml/NXfabrication.yaml | 107 - contributed_definitions/nyaml/NXfit.yaml | 345 --- .../nyaml/NXfit_background.yaml | 128 - .../nyaml/NXfit_function.yaml | 70 - .../nyaml/NXfit_parameter.yaml | 85 - contributed_definitions/nyaml/NXhistory.yaml | 120 - .../nyaml/NXibeam_column.yaml | 227 -- .../nyaml/NXidentifier.yaml | 72 - .../nyaml/NXimage_set.yaml | 1156 --------- .../nyaml/NXinteraction_vol_em.yaml | 94 - contributed_definitions/nyaml/NXion.yaml | 272 --- contributed_definitions/nyaml/NXlens_em.yaml | 161 -- contributed_definitions/nyaml/NXlens_opt.yaml | 326 --- .../nyaml/NXmanipulator.yaml | 422 ---- contributed_definitions/nyaml/NXmpes.yaml | 1742 ------------- .../nyaml/NXmpes_arpes.yaml | 674 ----- .../nyaml/NXopt_window.yaml | 205 -- .../nyaml/NXoptical_spectroscopy.yaml | 2168 ---------------- .../nyaml/NXoptical_system_em.yaml | 291 --- contributed_definitions/nyaml/NXpeak.yaml | 139 -- .../nyaml/NXphysical_process.yaml | 92 - contributed_definitions/nyaml/NXpid.yaml | 183 -- .../nyaml/NXprocess_mpes.yaml | 534 ---- contributed_definitions/nyaml/NXprogram.yaml | 76 - .../nyaml/NXpulser_apm.yaml | 414 ---- contributed_definitions/nyaml/NXpump.yaml | 60 - contributed_definitions/nyaml/NXraman.yaml | 448 ---- .../nyaml/NXreflectron.yaml | 136 -- .../nyaml/NXregistration.yaml | 80 - .../nyaml/NXresolution.yaml | 202 -- contributed_definitions/nyaml/NXroi.yaml | 46 - .../nyaml/NXrotation_set.yaml | 466 ---- .../nyaml/NXsample_component_set.yaml | 123 - .../nyaml/NXscanbox_em.yaml | 197 -- .../nyaml/NXserialized.yaml | 116 - .../nyaml/NXsingle_crystal.yaml | 113 - .../nyaml/NXspectrum_set.yaml | 986 -------- .../nyaml/NXspindispersion.yaml | 154 -- .../nyaml/NXstage_lab.yaml | 319 --- .../nyaml/NXsubstance.yaml | 193 -- .../nyaml/NXunit_cell.yaml | 379 --- .../nyaml/NXwaveplate.yaml | 295 --- contributed_definitions/nyaml/NXxps.yaml | 896 ------- 231 files changed, 36256 deletions(-) rename {contributed_definitions => applications}/NXapm.nxdl.xml (100%) rename {contributed_definitions => applications}/NXellipsometry.nxdl.xml (100%) rename {contributed_definitions => applications}/NXem.nxdl.xml (100%) rename {contributed_definitions => applications}/NXmpes.nxdl.xml (100%) rename {contributed_definitions => applications}/NXmpes_arpes.nxdl.xml (100%) rename {contributed_definitions => applications}/NXoptical_spectroscopy.nxdl.xml (100%) rename {contributed_definitions => applications}/NXraman.nxdl.xml (100%) rename {contributed_definitions => applications}/NXxps.nxdl.xml (100%) rename {contributed_definitions => applications}/xps/xps_cs.png (100%) rename {contributed_definitions => base_classes}/NXaberration.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXactivity.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXactuator.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXapm_charge_state_analysis.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXapm_hit_finding.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXapm_msr.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXapm_ranging.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXapm_reconstruction.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXapm_sim.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXapm_volt_and_bowl.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXbeam_device.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXbeam_transfer_matrix_table.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcalibration.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcg_alpha_complex.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcg_cylinder_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcg_ellipsoid_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcg_face_list_data_structure.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcg_geodesic_mesh.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcg_grid.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcg_half_edge_data_structure.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcg_hexahedron_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcg_marching_cubes.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcg_parallelogram_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcg_point_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcg_polygon_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcg_polyhedron_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcg_polyline_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcg_primitive_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcg_roi_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcg_sphere_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcg_tetrahedron_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcg_triangle_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcg_triangulated_surface_mesh.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcg_unit_normal_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXchamber.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXchemical_composition.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXchemical_process.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcircuit.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcollectioncolumn.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcomponent.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcoordinate_system.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcoordinate_system_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcorrector_cs.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcrystal_structure.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcs_computer.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcs_filter_boolean_mask.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcs_prng.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcs_profiling.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXcs_profiling_event.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXdata_mpes.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXdata_mpes_detector.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXdeflector.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXdistortion.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXebeam_column.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXelectron_level.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXelectronanalyser.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXem_correlation.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXem_ebsd.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXem_eds.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXem_eels.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXem_img.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXem_method.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXem_msr.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXem_sim.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXenergydispersion.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXevent_data_apm.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXevent_data_apm_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXevent_data_em.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXevent_data_em_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXfabrication.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXfit.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXfit_background.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXfit_function.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXfit_parameter.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXhistory.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXibeam_column.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXidentifier.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXimage_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXinteraction_vol_em.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXion.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXlens_em.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXlens_opt.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXmanipulator.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXopt_window.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXoptical_system_em.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXpeak.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXphysical_process.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXpid.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXprocess_mpes.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXprogram.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXpulser_apm.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXpump.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXreflectron.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXregistration.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXresolution.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXroi.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXrotation_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXsample_component_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXscanbox_em.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXserialized.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXsingle_crystal.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXspectrum_set.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXspindispersion.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXstage_lab.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXsubstance.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXunit_cell.nxdl.xml (100%) rename {contributed_definitions => base_classes}/NXwaveplate.nxdl.xml (100%) delete mode 100644 contributed_definitions/nyaml/NXaberration.yaml delete mode 100644 contributed_definitions/nyaml/NXactivity.yaml delete mode 100644 contributed_definitions/nyaml/NXactuator.yaml delete mode 100644 contributed_definitions/nyaml/NXapm.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_hit_finding.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_msr.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_ranging.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_reconstruction.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_sim.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_volt_and_bowl.yaml delete mode 100644 contributed_definitions/nyaml/NXbeam_device.yaml delete mode 100644 contributed_definitions/nyaml/NXbeam_transfer_matrix_table.yaml delete mode 100644 contributed_definitions/nyaml/NXcalibration.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_alpha_complex.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_cylinder_set.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_grid.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_hexahedron_set.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_marching_cubes.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_parallelogram_set.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_point_set.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_polygon_set.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_polyhedron_set.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_polyline_set.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_primitive_set.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_roi_set.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_sphere_set.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_triangle_set.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_unit_normal_set.yaml delete mode 100644 contributed_definitions/nyaml/NXchamber.yaml delete mode 100644 contributed_definitions/nyaml/NXchemical_composition.yaml delete mode 100644 contributed_definitions/nyaml/NXchemical_process.yaml delete mode 100644 contributed_definitions/nyaml/NXcircuit.yaml delete mode 100644 contributed_definitions/nyaml/NXcollectioncolumn.yaml delete mode 100644 contributed_definitions/nyaml/NXcomponent.yaml delete mode 100644 contributed_definitions/nyaml/NXcoordinate_system.yaml delete mode 100644 contributed_definitions/nyaml/NXcoordinate_system_set.yaml delete mode 100644 contributed_definitions/nyaml/NXcorrector_cs.yaml delete mode 100644 contributed_definitions/nyaml/NXcrystal_structure.yaml delete mode 100644 contributed_definitions/nyaml/NXcs_computer.yaml delete mode 100644 contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml delete mode 100644 contributed_definitions/nyaml/NXcs_prng.yaml delete mode 100644 contributed_definitions/nyaml/NXcs_profiling.yaml delete mode 100644 contributed_definitions/nyaml/NXcs_profiling_event.yaml delete mode 100644 contributed_definitions/nyaml/NXdata_mpes.yaml delete mode 100644 contributed_definitions/nyaml/NXdata_mpes_detector.yaml delete mode 100644 contributed_definitions/nyaml/NXdeflector.yaml delete mode 100644 contributed_definitions/nyaml/NXdistortion.yaml delete mode 100644 contributed_definitions/nyaml/NXebeam_column.yaml delete mode 100644 contributed_definitions/nyaml/NXelectron_level.yaml delete mode 100644 contributed_definitions/nyaml/NXelectronanalyser.yaml delete mode 100644 contributed_definitions/nyaml/NXellipsometry.yaml delete mode 100644 contributed_definitions/nyaml/NXem.yaml delete mode 100644 contributed_definitions/nyaml/NXem_correlation.yaml delete mode 100644 contributed_definitions/nyaml/NXem_ebsd.yaml delete mode 100644 contributed_definitions/nyaml/NXem_eds.yaml delete mode 100644 contributed_definitions/nyaml/NXem_eels.yaml delete mode 100644 contributed_definitions/nyaml/NXem_img.yaml delete mode 100644 contributed_definitions/nyaml/NXem_method.yaml delete mode 100644 contributed_definitions/nyaml/NXem_msr.yaml delete mode 100644 contributed_definitions/nyaml/NXem_sim.yaml delete mode 100644 contributed_definitions/nyaml/NXenergydispersion.yaml delete mode 100644 contributed_definitions/nyaml/NXevent_data_apm.yaml delete mode 100644 contributed_definitions/nyaml/NXevent_data_apm_set.yaml delete mode 100644 contributed_definitions/nyaml/NXevent_data_em.yaml delete mode 100644 contributed_definitions/nyaml/NXevent_data_em_set.yaml delete mode 100644 contributed_definitions/nyaml/NXfabrication.yaml delete mode 100644 contributed_definitions/nyaml/NXfit.yaml delete mode 100644 contributed_definitions/nyaml/NXfit_background.yaml delete mode 100644 contributed_definitions/nyaml/NXfit_function.yaml delete mode 100644 contributed_definitions/nyaml/NXfit_parameter.yaml delete mode 100644 contributed_definitions/nyaml/NXhistory.yaml delete mode 100644 contributed_definitions/nyaml/NXibeam_column.yaml delete mode 100644 contributed_definitions/nyaml/NXidentifier.yaml delete mode 100644 contributed_definitions/nyaml/NXimage_set.yaml delete mode 100644 contributed_definitions/nyaml/NXinteraction_vol_em.yaml delete mode 100644 contributed_definitions/nyaml/NXion.yaml delete mode 100644 contributed_definitions/nyaml/NXlens_em.yaml delete mode 100644 contributed_definitions/nyaml/NXlens_opt.yaml delete mode 100644 contributed_definitions/nyaml/NXmanipulator.yaml delete mode 100644 contributed_definitions/nyaml/NXmpes.yaml delete mode 100644 contributed_definitions/nyaml/NXmpes_arpes.yaml delete mode 100644 contributed_definitions/nyaml/NXopt_window.yaml delete mode 100644 contributed_definitions/nyaml/NXoptical_spectroscopy.yaml delete mode 100644 contributed_definitions/nyaml/NXoptical_system_em.yaml delete mode 100644 contributed_definitions/nyaml/NXpeak.yaml delete mode 100644 contributed_definitions/nyaml/NXphysical_process.yaml delete mode 100644 contributed_definitions/nyaml/NXpid.yaml delete mode 100644 contributed_definitions/nyaml/NXprocess_mpes.yaml delete mode 100644 contributed_definitions/nyaml/NXprogram.yaml delete mode 100644 contributed_definitions/nyaml/NXpulser_apm.yaml delete mode 100644 contributed_definitions/nyaml/NXpump.yaml delete mode 100644 contributed_definitions/nyaml/NXraman.yaml delete mode 100644 contributed_definitions/nyaml/NXreflectron.yaml delete mode 100644 contributed_definitions/nyaml/NXregistration.yaml delete mode 100644 contributed_definitions/nyaml/NXresolution.yaml delete mode 100644 contributed_definitions/nyaml/NXroi.yaml delete mode 100644 contributed_definitions/nyaml/NXrotation_set.yaml delete mode 100644 contributed_definitions/nyaml/NXsample_component_set.yaml delete mode 100644 contributed_definitions/nyaml/NXscanbox_em.yaml delete mode 100644 contributed_definitions/nyaml/NXserialized.yaml delete mode 100644 contributed_definitions/nyaml/NXsingle_crystal.yaml delete mode 100644 contributed_definitions/nyaml/NXspectrum_set.yaml delete mode 100644 contributed_definitions/nyaml/NXspindispersion.yaml delete mode 100644 contributed_definitions/nyaml/NXstage_lab.yaml delete mode 100644 contributed_definitions/nyaml/NXsubstance.yaml delete mode 100644 contributed_definitions/nyaml/NXunit_cell.yaml delete mode 100644 contributed_definitions/nyaml/NXwaveplate.yaml delete mode 100644 contributed_definitions/nyaml/NXxps.yaml diff --git a/contributed_definitions/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml similarity index 100% rename from contributed_definitions/NXapm.nxdl.xml rename to applications/NXapm.nxdl.xml diff --git a/contributed_definitions/NXellipsometry.nxdl.xml b/applications/NXellipsometry.nxdl.xml similarity index 100% rename from contributed_definitions/NXellipsometry.nxdl.xml rename to applications/NXellipsometry.nxdl.xml diff --git a/contributed_definitions/NXem.nxdl.xml b/applications/NXem.nxdl.xml similarity index 100% rename from contributed_definitions/NXem.nxdl.xml rename to applications/NXem.nxdl.xml diff --git a/contributed_definitions/NXmpes.nxdl.xml b/applications/NXmpes.nxdl.xml similarity index 100% rename from contributed_definitions/NXmpes.nxdl.xml rename to applications/NXmpes.nxdl.xml diff --git a/contributed_definitions/NXmpes_arpes.nxdl.xml b/applications/NXmpes_arpes.nxdl.xml similarity index 100% rename from contributed_definitions/NXmpes_arpes.nxdl.xml rename to applications/NXmpes_arpes.nxdl.xml diff --git a/contributed_definitions/NXoptical_spectroscopy.nxdl.xml b/applications/NXoptical_spectroscopy.nxdl.xml similarity index 100% rename from contributed_definitions/NXoptical_spectroscopy.nxdl.xml rename to applications/NXoptical_spectroscopy.nxdl.xml diff --git a/contributed_definitions/NXraman.nxdl.xml b/applications/NXraman.nxdl.xml similarity index 100% rename from contributed_definitions/NXraman.nxdl.xml rename to applications/NXraman.nxdl.xml diff --git a/contributed_definitions/NXxps.nxdl.xml b/applications/NXxps.nxdl.xml similarity index 100% rename from contributed_definitions/NXxps.nxdl.xml rename to applications/NXxps.nxdl.xml diff --git a/contributed_definitions/xps/xps_cs.png b/applications/xps/xps_cs.png similarity index 100% rename from contributed_definitions/xps/xps_cs.png rename to applications/xps/xps_cs.png diff --git a/contributed_definitions/NXaberration.nxdl.xml b/base_classes/NXaberration.nxdl.xml similarity index 100% rename from contributed_definitions/NXaberration.nxdl.xml rename to base_classes/NXaberration.nxdl.xml diff --git a/contributed_definitions/NXactivity.nxdl.xml b/base_classes/NXactivity.nxdl.xml similarity index 100% rename from contributed_definitions/NXactivity.nxdl.xml rename to base_classes/NXactivity.nxdl.xml diff --git a/contributed_definitions/NXactuator.nxdl.xml b/base_classes/NXactuator.nxdl.xml similarity index 100% rename from contributed_definitions/NXactuator.nxdl.xml rename to base_classes/NXactuator.nxdl.xml diff --git a/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml b/base_classes/NXapm_charge_state_analysis.nxdl.xml similarity index 100% rename from contributed_definitions/NXapm_charge_state_analysis.nxdl.xml rename to base_classes/NXapm_charge_state_analysis.nxdl.xml diff --git a/contributed_definitions/NXapm_hit_finding.nxdl.xml b/base_classes/NXapm_hit_finding.nxdl.xml similarity index 100% rename from contributed_definitions/NXapm_hit_finding.nxdl.xml rename to base_classes/NXapm_hit_finding.nxdl.xml diff --git a/contributed_definitions/NXapm_msr.nxdl.xml b/base_classes/NXapm_msr.nxdl.xml similarity index 100% rename from contributed_definitions/NXapm_msr.nxdl.xml rename to base_classes/NXapm_msr.nxdl.xml diff --git a/contributed_definitions/NXapm_ranging.nxdl.xml b/base_classes/NXapm_ranging.nxdl.xml similarity index 100% rename from contributed_definitions/NXapm_ranging.nxdl.xml rename to base_classes/NXapm_ranging.nxdl.xml diff --git a/contributed_definitions/NXapm_reconstruction.nxdl.xml b/base_classes/NXapm_reconstruction.nxdl.xml similarity index 100% rename from contributed_definitions/NXapm_reconstruction.nxdl.xml rename to base_classes/NXapm_reconstruction.nxdl.xml diff --git a/contributed_definitions/NXapm_sim.nxdl.xml b/base_classes/NXapm_sim.nxdl.xml similarity index 100% rename from contributed_definitions/NXapm_sim.nxdl.xml rename to base_classes/NXapm_sim.nxdl.xml diff --git a/contributed_definitions/NXapm_volt_and_bowl.nxdl.xml b/base_classes/NXapm_volt_and_bowl.nxdl.xml similarity index 100% rename from contributed_definitions/NXapm_volt_and_bowl.nxdl.xml rename to base_classes/NXapm_volt_and_bowl.nxdl.xml diff --git a/contributed_definitions/NXbeam_device.nxdl.xml b/base_classes/NXbeam_device.nxdl.xml similarity index 100% rename from contributed_definitions/NXbeam_device.nxdl.xml rename to base_classes/NXbeam_device.nxdl.xml diff --git a/contributed_definitions/NXbeam_transfer_matrix_table.nxdl.xml b/base_classes/NXbeam_transfer_matrix_table.nxdl.xml similarity index 100% rename from contributed_definitions/NXbeam_transfer_matrix_table.nxdl.xml rename to base_classes/NXbeam_transfer_matrix_table.nxdl.xml diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/base_classes/NXcalibration.nxdl.xml similarity index 100% rename from contributed_definitions/NXcalibration.nxdl.xml rename to base_classes/NXcalibration.nxdl.xml diff --git a/contributed_definitions/NXcg_alpha_complex.nxdl.xml b/base_classes/NXcg_alpha_complex.nxdl.xml similarity index 100% rename from contributed_definitions/NXcg_alpha_complex.nxdl.xml rename to base_classes/NXcg_alpha_complex.nxdl.xml diff --git a/contributed_definitions/NXcg_cylinder_set.nxdl.xml b/base_classes/NXcg_cylinder_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXcg_cylinder_set.nxdl.xml rename to base_classes/NXcg_cylinder_set.nxdl.xml diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/base_classes/NXcg_ellipsoid_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXcg_ellipsoid_set.nxdl.xml rename to base_classes/NXcg_ellipsoid_set.nxdl.xml diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/base_classes/NXcg_face_list_data_structure.nxdl.xml similarity index 100% rename from contributed_definitions/NXcg_face_list_data_structure.nxdl.xml rename to base_classes/NXcg_face_list_data_structure.nxdl.xml diff --git a/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml b/base_classes/NXcg_geodesic_mesh.nxdl.xml similarity index 100% rename from contributed_definitions/NXcg_geodesic_mesh.nxdl.xml rename to base_classes/NXcg_geodesic_mesh.nxdl.xml diff --git a/contributed_definitions/NXcg_grid.nxdl.xml b/base_classes/NXcg_grid.nxdl.xml similarity index 100% rename from contributed_definitions/NXcg_grid.nxdl.xml rename to base_classes/NXcg_grid.nxdl.xml diff --git a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml b/base_classes/NXcg_half_edge_data_structure.nxdl.xml similarity index 100% rename from contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml rename to base_classes/NXcg_half_edge_data_structure.nxdl.xml diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/base_classes/NXcg_hexahedron_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXcg_hexahedron_set.nxdl.xml rename to base_classes/NXcg_hexahedron_set.nxdl.xml diff --git a/contributed_definitions/NXcg_marching_cubes.nxdl.xml b/base_classes/NXcg_marching_cubes.nxdl.xml similarity index 100% rename from contributed_definitions/NXcg_marching_cubes.nxdl.xml rename to base_classes/NXcg_marching_cubes.nxdl.xml diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/base_classes/NXcg_parallelogram_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXcg_parallelogram_set.nxdl.xml rename to base_classes/NXcg_parallelogram_set.nxdl.xml diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/base_classes/NXcg_point_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXcg_point_set.nxdl.xml rename to base_classes/NXcg_point_set.nxdl.xml diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/base_classes/NXcg_polygon_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXcg_polygon_set.nxdl.xml rename to base_classes/NXcg_polygon_set.nxdl.xml diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/base_classes/NXcg_polyhedron_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXcg_polyhedron_set.nxdl.xml rename to base_classes/NXcg_polyhedron_set.nxdl.xml diff --git a/contributed_definitions/NXcg_polyline_set.nxdl.xml b/base_classes/NXcg_polyline_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXcg_polyline_set.nxdl.xml rename to base_classes/NXcg_polyline_set.nxdl.xml diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/base_classes/NXcg_primitive_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXcg_primitive_set.nxdl.xml rename to base_classes/NXcg_primitive_set.nxdl.xml diff --git a/contributed_definitions/NXcg_roi_set.nxdl.xml b/base_classes/NXcg_roi_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXcg_roi_set.nxdl.xml rename to base_classes/NXcg_roi_set.nxdl.xml diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/base_classes/NXcg_sphere_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXcg_sphere_set.nxdl.xml rename to base_classes/NXcg_sphere_set.nxdl.xml diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/base_classes/NXcg_tetrahedron_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXcg_tetrahedron_set.nxdl.xml rename to base_classes/NXcg_tetrahedron_set.nxdl.xml diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/base_classes/NXcg_triangle_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXcg_triangle_set.nxdl.xml rename to base_classes/NXcg_triangle_set.nxdl.xml diff --git a/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml b/base_classes/NXcg_triangulated_surface_mesh.nxdl.xml similarity index 100% rename from contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml rename to base_classes/NXcg_triangulated_surface_mesh.nxdl.xml diff --git a/contributed_definitions/NXcg_unit_normal_set.nxdl.xml b/base_classes/NXcg_unit_normal_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXcg_unit_normal_set.nxdl.xml rename to base_classes/NXcg_unit_normal_set.nxdl.xml diff --git a/contributed_definitions/NXchamber.nxdl.xml b/base_classes/NXchamber.nxdl.xml similarity index 100% rename from contributed_definitions/NXchamber.nxdl.xml rename to base_classes/NXchamber.nxdl.xml diff --git a/contributed_definitions/NXchemical_composition.nxdl.xml b/base_classes/NXchemical_composition.nxdl.xml similarity index 100% rename from contributed_definitions/NXchemical_composition.nxdl.xml rename to base_classes/NXchemical_composition.nxdl.xml diff --git a/contributed_definitions/NXchemical_process.nxdl.xml b/base_classes/NXchemical_process.nxdl.xml similarity index 100% rename from contributed_definitions/NXchemical_process.nxdl.xml rename to base_classes/NXchemical_process.nxdl.xml diff --git a/contributed_definitions/NXcircuit.nxdl.xml b/base_classes/NXcircuit.nxdl.xml similarity index 100% rename from contributed_definitions/NXcircuit.nxdl.xml rename to base_classes/NXcircuit.nxdl.xml diff --git a/contributed_definitions/NXcollectioncolumn.nxdl.xml b/base_classes/NXcollectioncolumn.nxdl.xml similarity index 100% rename from contributed_definitions/NXcollectioncolumn.nxdl.xml rename to base_classes/NXcollectioncolumn.nxdl.xml diff --git a/contributed_definitions/NXcomponent.nxdl.xml b/base_classes/NXcomponent.nxdl.xml similarity index 100% rename from contributed_definitions/NXcomponent.nxdl.xml rename to base_classes/NXcomponent.nxdl.xml diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/base_classes/NXcoordinate_system.nxdl.xml similarity index 100% rename from contributed_definitions/NXcoordinate_system.nxdl.xml rename to base_classes/NXcoordinate_system.nxdl.xml diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/base_classes/NXcoordinate_system_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXcoordinate_system_set.nxdl.xml rename to base_classes/NXcoordinate_system_set.nxdl.xml diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml similarity index 100% rename from contributed_definitions/NXcorrector_cs.nxdl.xml rename to base_classes/NXcorrector_cs.nxdl.xml diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/base_classes/NXcrystal_structure.nxdl.xml similarity index 100% rename from contributed_definitions/NXcrystal_structure.nxdl.xml rename to base_classes/NXcrystal_structure.nxdl.xml diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_computer.nxdl.xml rename to base_classes/NXcs_computer.nxdl.xml diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml rename to base_classes/NXcs_filter_boolean_mask.nxdl.xml diff --git a/contributed_definitions/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_prng.nxdl.xml rename to base_classes/NXcs_prng.nxdl.xml diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_profiling.nxdl.xml rename to base_classes/NXcs_profiling.nxdl.xml diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_profiling_event.nxdl.xml rename to base_classes/NXcs_profiling_event.nxdl.xml diff --git a/contributed_definitions/NXdata_mpes.nxdl.xml b/base_classes/NXdata_mpes.nxdl.xml similarity index 100% rename from contributed_definitions/NXdata_mpes.nxdl.xml rename to base_classes/NXdata_mpes.nxdl.xml diff --git a/contributed_definitions/NXdata_mpes_detector.nxdl.xml b/base_classes/NXdata_mpes_detector.nxdl.xml similarity index 100% rename from contributed_definitions/NXdata_mpes_detector.nxdl.xml rename to base_classes/NXdata_mpes_detector.nxdl.xml diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml similarity index 100% rename from contributed_definitions/NXdeflector.nxdl.xml rename to base_classes/NXdeflector.nxdl.xml diff --git a/contributed_definitions/NXdistortion.nxdl.xml b/base_classes/NXdistortion.nxdl.xml similarity index 100% rename from contributed_definitions/NXdistortion.nxdl.xml rename to base_classes/NXdistortion.nxdl.xml diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml similarity index 100% rename from contributed_definitions/NXebeam_column.nxdl.xml rename to base_classes/NXebeam_column.nxdl.xml diff --git a/contributed_definitions/NXelectron_level.nxdl.xml b/base_classes/NXelectron_level.nxdl.xml similarity index 100% rename from contributed_definitions/NXelectron_level.nxdl.xml rename to base_classes/NXelectron_level.nxdl.xml diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/base_classes/NXelectronanalyser.nxdl.xml similarity index 100% rename from contributed_definitions/NXelectronanalyser.nxdl.xml rename to base_classes/NXelectronanalyser.nxdl.xml diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/base_classes/NXem_correlation.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_correlation.nxdl.xml rename to base_classes/NXem_correlation.nxdl.xml diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_ebsd.nxdl.xml rename to base_classes/NXem_ebsd.nxdl.xml diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/base_classes/NXem_eds.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_eds.nxdl.xml rename to base_classes/NXem_eds.nxdl.xml diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/base_classes/NXem_eels.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_eels.nxdl.xml rename to base_classes/NXem_eels.nxdl.xml diff --git a/contributed_definitions/NXem_img.nxdl.xml b/base_classes/NXem_img.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_img.nxdl.xml rename to base_classes/NXem_img.nxdl.xml diff --git a/contributed_definitions/NXem_method.nxdl.xml b/base_classes/NXem_method.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_method.nxdl.xml rename to base_classes/NXem_method.nxdl.xml diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/base_classes/NXem_msr.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_msr.nxdl.xml rename to base_classes/NXem_msr.nxdl.xml diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/base_classes/NXem_sim.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_sim.nxdl.xml rename to base_classes/NXem_sim.nxdl.xml diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/base_classes/NXenergydispersion.nxdl.xml similarity index 100% rename from contributed_definitions/NXenergydispersion.nxdl.xml rename to base_classes/NXenergydispersion.nxdl.xml diff --git a/contributed_definitions/NXevent_data_apm.nxdl.xml b/base_classes/NXevent_data_apm.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_apm.nxdl.xml rename to base_classes/NXevent_data_apm.nxdl.xml diff --git a/contributed_definitions/NXevent_data_apm_set.nxdl.xml b/base_classes/NXevent_data_apm_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_apm_set.nxdl.xml rename to base_classes/NXevent_data_apm_set.nxdl.xml diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_em.nxdl.xml rename to base_classes/NXevent_data_em.nxdl.xml diff --git a/contributed_definitions/NXevent_data_em_set.nxdl.xml b/base_classes/NXevent_data_em_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_em_set.nxdl.xml rename to base_classes/NXevent_data_em_set.nxdl.xml diff --git a/contributed_definitions/NXfabrication.nxdl.xml b/base_classes/NXfabrication.nxdl.xml similarity index 100% rename from contributed_definitions/NXfabrication.nxdl.xml rename to base_classes/NXfabrication.nxdl.xml diff --git a/contributed_definitions/NXfit.nxdl.xml b/base_classes/NXfit.nxdl.xml similarity index 100% rename from contributed_definitions/NXfit.nxdl.xml rename to base_classes/NXfit.nxdl.xml diff --git a/contributed_definitions/NXfit_background.nxdl.xml b/base_classes/NXfit_background.nxdl.xml similarity index 100% rename from contributed_definitions/NXfit_background.nxdl.xml rename to base_classes/NXfit_background.nxdl.xml diff --git a/contributed_definitions/NXfit_function.nxdl.xml b/base_classes/NXfit_function.nxdl.xml similarity index 100% rename from contributed_definitions/NXfit_function.nxdl.xml rename to base_classes/NXfit_function.nxdl.xml diff --git a/contributed_definitions/NXfit_parameter.nxdl.xml b/base_classes/NXfit_parameter.nxdl.xml similarity index 100% rename from contributed_definitions/NXfit_parameter.nxdl.xml rename to base_classes/NXfit_parameter.nxdl.xml diff --git a/contributed_definitions/NXhistory.nxdl.xml b/base_classes/NXhistory.nxdl.xml similarity index 100% rename from contributed_definitions/NXhistory.nxdl.xml rename to base_classes/NXhistory.nxdl.xml diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml similarity index 100% rename from contributed_definitions/NXibeam_column.nxdl.xml rename to base_classes/NXibeam_column.nxdl.xml diff --git a/contributed_definitions/NXidentifier.nxdl.xml b/base_classes/NXidentifier.nxdl.xml similarity index 100% rename from contributed_definitions/NXidentifier.nxdl.xml rename to base_classes/NXidentifier.nxdl.xml diff --git a/contributed_definitions/NXimage_set.nxdl.xml b/base_classes/NXimage_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXimage_set.nxdl.xml rename to base_classes/NXimage_set.nxdl.xml diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/base_classes/NXinteraction_vol_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXinteraction_vol_em.nxdl.xml rename to base_classes/NXinteraction_vol_em.nxdl.xml diff --git a/contributed_definitions/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml similarity index 100% rename from contributed_definitions/NXion.nxdl.xml rename to base_classes/NXion.nxdl.xml diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXlens_em.nxdl.xml rename to base_classes/NXlens_em.nxdl.xml diff --git a/contributed_definitions/NXlens_opt.nxdl.xml b/base_classes/NXlens_opt.nxdl.xml similarity index 100% rename from contributed_definitions/NXlens_opt.nxdl.xml rename to base_classes/NXlens_opt.nxdl.xml diff --git a/contributed_definitions/NXmanipulator.nxdl.xml b/base_classes/NXmanipulator.nxdl.xml similarity index 100% rename from contributed_definitions/NXmanipulator.nxdl.xml rename to base_classes/NXmanipulator.nxdl.xml diff --git a/contributed_definitions/NXopt_window.nxdl.xml b/base_classes/NXopt_window.nxdl.xml similarity index 100% rename from contributed_definitions/NXopt_window.nxdl.xml rename to base_classes/NXopt_window.nxdl.xml diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXoptical_system_em.nxdl.xml rename to base_classes/NXoptical_system_em.nxdl.xml diff --git a/contributed_definitions/NXpeak.nxdl.xml b/base_classes/NXpeak.nxdl.xml similarity index 100% rename from contributed_definitions/NXpeak.nxdl.xml rename to base_classes/NXpeak.nxdl.xml diff --git a/contributed_definitions/NXphysical_process.nxdl.xml b/base_classes/NXphysical_process.nxdl.xml similarity index 100% rename from contributed_definitions/NXphysical_process.nxdl.xml rename to base_classes/NXphysical_process.nxdl.xml diff --git a/contributed_definitions/NXpid.nxdl.xml b/base_classes/NXpid.nxdl.xml similarity index 100% rename from contributed_definitions/NXpid.nxdl.xml rename to base_classes/NXpid.nxdl.xml diff --git a/contributed_definitions/NXprocess_mpes.nxdl.xml b/base_classes/NXprocess_mpes.nxdl.xml similarity index 100% rename from contributed_definitions/NXprocess_mpes.nxdl.xml rename to base_classes/NXprocess_mpes.nxdl.xml diff --git a/contributed_definitions/NXprogram.nxdl.xml b/base_classes/NXprogram.nxdl.xml similarity index 100% rename from contributed_definitions/NXprogram.nxdl.xml rename to base_classes/NXprogram.nxdl.xml diff --git a/contributed_definitions/NXpulser_apm.nxdl.xml b/base_classes/NXpulser_apm.nxdl.xml similarity index 100% rename from contributed_definitions/NXpulser_apm.nxdl.xml rename to base_classes/NXpulser_apm.nxdl.xml diff --git a/contributed_definitions/NXpump.nxdl.xml b/base_classes/NXpump.nxdl.xml similarity index 100% rename from contributed_definitions/NXpump.nxdl.xml rename to base_classes/NXpump.nxdl.xml diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/base_classes/NXreflectron.nxdl.xml similarity index 100% rename from contributed_definitions/NXreflectron.nxdl.xml rename to base_classes/NXreflectron.nxdl.xml diff --git a/contributed_definitions/NXregistration.nxdl.xml b/base_classes/NXregistration.nxdl.xml similarity index 100% rename from contributed_definitions/NXregistration.nxdl.xml rename to base_classes/NXregistration.nxdl.xml diff --git a/contributed_definitions/NXresolution.nxdl.xml b/base_classes/NXresolution.nxdl.xml similarity index 100% rename from contributed_definitions/NXresolution.nxdl.xml rename to base_classes/NXresolution.nxdl.xml diff --git a/contributed_definitions/NXroi.nxdl.xml b/base_classes/NXroi.nxdl.xml similarity index 100% rename from contributed_definitions/NXroi.nxdl.xml rename to base_classes/NXroi.nxdl.xml diff --git a/contributed_definitions/NXrotation_set.nxdl.xml b/base_classes/NXrotation_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXrotation_set.nxdl.xml rename to base_classes/NXrotation_set.nxdl.xml diff --git a/contributed_definitions/NXsample_component_set.nxdl.xml b/base_classes/NXsample_component_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXsample_component_set.nxdl.xml rename to base_classes/NXsample_component_set.nxdl.xml diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXscanbox_em.nxdl.xml rename to base_classes/NXscanbox_em.nxdl.xml diff --git a/contributed_definitions/NXserialized.nxdl.xml b/base_classes/NXserialized.nxdl.xml similarity index 100% rename from contributed_definitions/NXserialized.nxdl.xml rename to base_classes/NXserialized.nxdl.xml diff --git a/contributed_definitions/NXsingle_crystal.nxdl.xml b/base_classes/NXsingle_crystal.nxdl.xml similarity index 100% rename from contributed_definitions/NXsingle_crystal.nxdl.xml rename to base_classes/NXsingle_crystal.nxdl.xml diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXspectrum_set.nxdl.xml rename to base_classes/NXspectrum_set.nxdl.xml diff --git a/contributed_definitions/NXspindispersion.nxdl.xml b/base_classes/NXspindispersion.nxdl.xml similarity index 100% rename from contributed_definitions/NXspindispersion.nxdl.xml rename to base_classes/NXspindispersion.nxdl.xml diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml similarity index 100% rename from contributed_definitions/NXstage_lab.nxdl.xml rename to base_classes/NXstage_lab.nxdl.xml diff --git a/contributed_definitions/NXsubstance.nxdl.xml b/base_classes/NXsubstance.nxdl.xml similarity index 100% rename from contributed_definitions/NXsubstance.nxdl.xml rename to base_classes/NXsubstance.nxdl.xml diff --git a/contributed_definitions/NXunit_cell.nxdl.xml b/base_classes/NXunit_cell.nxdl.xml similarity index 100% rename from contributed_definitions/NXunit_cell.nxdl.xml rename to base_classes/NXunit_cell.nxdl.xml diff --git a/contributed_definitions/NXwaveplate.nxdl.xml b/base_classes/NXwaveplate.nxdl.xml similarity index 100% rename from contributed_definitions/NXwaveplate.nxdl.xml rename to base_classes/NXwaveplate.nxdl.xml diff --git a/contributed_definitions/nyaml/NXaberration.yaml b/contributed_definitions/nyaml/NXaberration.yaml deleted file mode 100644 index 6f5aa873fe..0000000000 --- a/contributed_definitions/nyaml/NXaberration.yaml +++ /dev/null @@ -1,108 +0,0 @@ -category: base -doc: | - Quantified aberration coefficient in an aberration_model. -type: group -NXaberration(NXobject): - magnitude(NX_NUMBER): - unit: NX_ANY - doc: | - Value of the aberration coefficient. - uncertainty(NX_NUMBER): - unit: NX_ANY - doc: | - Uncertainty of the value of the aberration coefficient - according to uncertainty_model. - uncertainty_model(NX_CHAR): - doc: | - How was the uncertainty quantified e.g. via the 95% confidence interval - and using which algorithm or statistical model. - delta_time(NX_NUMBER): - unit: NX_TIME - doc: | - Time elapsed since the last measurement. - angle(NX_NUMBER): - unit: NX_ANGLE - doc: | - For the CEOS definitions the C aberrations are radial-symmetric and have - no angle entry, while the A, B, D, S, or R aberrations are n-fold - symmetric and have an angle entry. - For the NION definitions the coordinate system differs to the one - used in CEOS and instead two aberration coefficients a and b are used. - name(NX_CHAR): - doc: | - Given name to this aberration. - alias(NX_CHAR): - doc: | - Alias also used to name and refer to this specific type of aberration. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 08fa419b240c84dd4e3e41e0109acae219d9ce2b0f09876287a30f4d79eff994 -# -# -# -# -# -# Quantified aberration coefficient in an aberration_model. -# -# -# -# Value of the aberration coefficient. -# -# -# -# -# Uncertainty of the value of the aberration coefficient -# according to uncertainty_model. -# -# -# -# -# How was the uncertainty quantified e.g. via the 95% confidence interval -# and using which algorithm or statistical model. -# -# -# -# -# Time elapsed since the last measurement. -# -# -# -# -# For the CEOS definitions the C aberrations are radial-symmetric and have -# no angle entry, while the A, B, D, S, or R aberrations are n-fold -# symmetric and have an angle entry. -# For the NION definitions the coordinate system differs to the one -# used in CEOS and instead two aberration coefficients a and b are used. -# -# -# -# -# Given name to this aberration. -# -# -# -# -# Alias also used to name and refer to this specific type of aberration. -# -# -# diff --git a/contributed_definitions/nyaml/NXactivity.yaml b/contributed_definitions/nyaml/NXactivity.yaml deleted file mode 100644 index 6888050810..0000000000 --- a/contributed_definitions/nyaml/NXactivity.yaml +++ /dev/null @@ -1,84 +0,0 @@ -category: base -doc: | - A planned or unplanned action that has a temporal extension and for some time depends on some entity. - - This class is planned be used in the future as the super class for all other activities if inheritance - in base classes is supported in NeXus. -type: group -NXactivity(NXobject): - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code (with local time zone offset to UTC information - included) when this activity started. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code (with local time zone offset to UTC information - included) when this activity ended. - description: - doc: | - Short description of the activity. - notes(NXnote): - doc: | - This can be any data or other descriptor acquired during the activity - (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2ef302056190c2ac2b4a517bce57ee7727783d1bfb1bb3308c07fda870f51810 -# -# -# -# -# -# A planned or unplanned action that has a temporal extension and for some time depends on some entity. -# -# This class is planned be used in the future as the super class for all other activities if inheritance -# in base classes is supported in NeXus. -# -# -# -# ISO 8601 formatted time code (with local time zone offset to UTC information -# included) when this activity started. -# -# -# -# -# ISO 8601 formatted time code (with local time zone offset to UTC information -# included) when this activity ended. -# -# -# -# -# Short description of the activity. -# -# -# -# -# This can be any data or other descriptor acquired during the activity -# (NXnote allows to add pictures, audio, movies). Alternatively, a -# reference to the location or a unique identifier or other metadata file. In the -# case these are not available, free-text description. -# -# -# diff --git a/contributed_definitions/nyaml/NXactuator.yaml b/contributed_definitions/nyaml/NXactuator.yaml deleted file mode 100644 index ca59bb0a60..0000000000 --- a/contributed_definitions/nyaml/NXactuator.yaml +++ /dev/null @@ -1,208 +0,0 @@ -category: base -doc: | - An actuator used to control an external condition. - - The condition itself is described in :ref:`NXenvironment`. -type: group -NXactuator(NXobject): - model: - doc: | - Actuator identification code/model number - name: - doc: | - Name of the actuator - short_name: - doc: | - Short name of actuator used e.g. on monitor display program - attached_to: - doc: | - Describe where the actuator is attached to. - This could be an instance of NXsample or a device on NXinstrument. - physical_quantity: - doc: | - Name for the physical quantity effected by the actuation - - Examples: - temperature | pH | magnetic_field | electric_field | current | conductivity | resistance | voltage | - pressure | flow | stress | strain | shear | surface_pressure - type: - doc: | - The type of hardware used for the actuation. - - Examples (suggestions, but not restrictions): - - :Temperature: laser | gas lamp | filament | resistive - :Pressure: anvil cell - :Voltage: potentiostat - OUTPUT(NX_FLOAT): - unit: NX_ANY - doc: | - Any output that the actuator produces. - For example, a heater can have the field heater_power(NX_FLOAT). - OUTPUT_log(NXlog): - doc: | - Time history of actuator outputs. - (NXpid): - doc: | - If the actuator is PID-controlled, the settings of the PID controller can be - stored here. - setpoint(NX_FLOAT): - unit: NX_ANY - doc: | - Nominal actuator setpoint. - Can be a scalar or a vector (of [n] actuations). - setpoint_log(NXlog): - doc: | - Time history of actuator setpoints. - depends_on(NX_CHAR): - doc: | - Refers to the last transformation specifying the position of the actuator - in the NXtransformations chain. - (NXtransformations): - doc: | - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the actuator within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - (NXfabrication): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 9eda87a10fdbfaa3518c014b170c81c03eac50d88643109b20b68ce66e12f1c1 -# -# -# -# -# -# An actuator used to control an external condition. -# -# The condition itself is described in :ref:`NXenvironment`. -# -# -# -# Actuator identification code/model number -# -# -# -# -# Name of the actuator -# -# -# -# -# Short name of actuator used e.g. on monitor display program -# -# -# -# -# Describe where the actuator is attached to. -# This could be an instance of NXsample or a device on NXinstrument. -# -# -# -# -# Name for the physical quantity effected by the actuation -# -# Examples: -# temperature | pH | magnetic_field | electric_field | current | conductivity | resistance | voltage | -# pressure | flow | stress | strain | shear | surface_pressure -# -# -# -# -# The type of hardware used for the actuation. -# -# Examples (suggestions, but not restrictions): -# -# :Temperature: laser | gas lamp | filament | resistive -# :Pressure: anvil cell -# :Voltage: potentiostat -# -# -# -# -# Any output that the actuator produces. -# For example, a heater can have the field heater_power(NX_FLOAT). -# -# -# -# -# Time history of actuator outputs. -# -# -# -# -# If the actuator is PID-controlled, the settings of the PID controller can be -# stored here. -# -# -# -# Nominal actuator setpoint. -# Can be a scalar or a vector (of [n] actuations). -# -# -# -# -# Time history of actuator setpoints. -# -# -# -# -# -# Refers to the last transformation specifying the position of the actuator -# in the NXtransformations chain. -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the actuator within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml deleted file mode 100644 index cc5419586e..0000000000 --- a/contributed_definitions/nyaml/NXapm.yaml +++ /dev/null @@ -1,2170 +0,0 @@ -category: application -doc: | - Application definition for atom probe and field ion microscopy experiments. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - p: | - Number of pulses collected in between start_time and end_time resolved by an - instance of :ref:`NXevent_data_apm`. If this is not defined, p is the number of - ions included in the reconstructed volume if the application definition is used - to store results of an already reconstructed datasets. - n: | - Number of ions spatially filtered from results of the hit_finding algorithm - from which an instance of a reconstructed volume has been generated. - These ions get new identifier assigned in the process (the so-called - evaporation_identifier). This identifier must not be confused with - the pulse_identifier. -type: group -NXapm(NXobject): - (NXentry): - exists: ['min', '1', 'max', 'unbounded'] - definition(NX_CHAR): - \@version: - type: NX_CHAR - exists: optional - enumeration: [NXapm] - profiling(NXcs_profiling): - exists: optional - doc: | - The configuration of the I/O writer software (e.g. `pynxtools `_ or its plugins) - which was used to generate this NeXus file instance. - - # command_line_call(NX_CHAR): - programID(NXprogram): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - A collection of all programs and libraries which are considered relevant - to understand with which software tools this NeXus file instance was - generated. Ideally, to enable a binary recreation from the input data. - - Examples include the name and version of the libraries used to write the - instance. Ideally, the software which writes these NXprogram instances - also includes the version of the set of NeXus classes i.e. the specific - set of base classes, application definitions, and contributed definitions - with which the here described concepts can be resolved. - - For the `pynxtools library `_ - which is used by the `NOMAD `_ - research data management system, it makes sense to store e.g. the GitHub - repository commit and respective submodule references used. - program(NX_CHAR): - \@version: - type: NX_CHAR - - # \@url: - experiment_identifier(NXidentifier): - exists: recommended - service(NX_CHAR): - identifier(NX_CHAR): - is_persistent(NX_BOOLEAN): - run_number(NX_CHAR): - exists: recommended - - # cannot be made required as for simulations you do not have a run number! - doc: | - The identifier whereby the experiment is referred to in the control software. - This is neither the specimen_name nor the experiment_identifier. For - Local Electrode Atom Probe (LEAP) instruments, it is recommended to use the - run_number from the proprietary software IVAS/APSuite of AMETEK/Cameca. - For other instruments, such as the one from Stuttgart or Oxcart from Erlangen, - or the instruments at GPM in Rouen, use the identifier which matches - best conceptually to the LEAP run number. - The field does not have to be required if the information is recoverable - in the dataset which for LEAP instruments is the case (provided these - RHIT or HITS files respectively are stored alongside a data artifact). - With NXapm the RHIT or HITS can be stored as via the NXserialized group - in the hit_finding algorithm section. - - As a destructive microscopy technique, a run can be performed only once. - It is possible, however, to interrupt a run and restart data acquisition - while still using the same specimen. In this case, each evaporation run - needs to be distinguished with different run numbers. - We follow this habit of most atom probe groups. Such interrupted runs - should be stored as individual :ref:`NXentry` instances in one NeXus file. - experiment_alias(NX_CHAR): - doc: | - Either an identifier or an alias that is human-friendly so that scientists find that experiment again. - For experiments usually this is the run_number but for simulation typically no run_numbers are issued. - experiment_description(NX_CHAR): - exists: optional - doc: | - Free-text description about the experiment. - - Users are strongly advised to parameterize the description of their experiment - by using respective groups and fields and base classes instead of writing prose - into this field. - - The reason is that such free-text field is difficult to machine-interpret. - The motivation behind keeping this field for now is to learn in how far the - current base classes need extension based on user feedback. - - # optional quantities do not need to be mentioned in an appdef because they can always be added - # if NXapm inherits from NXapm_base having this optional field does not need to be - # mentioned because optional nodes can always be added to a NeXus file instance without - # making it thereby non-compliant to the application definition - # the only difference is that if the consuming application wishes to demand to find that field - # it has to be specified in the appdef for the appdef to be a useful document of the contract - # which pieces of information a software expects to find and which not - # if you think about you being the consuming human (agent) also you would like to know - # if there is a run_number for the atom probe measurement from your colleague i.e. you - # effectively ask your colleague for that information while working off your imagined list of requirements - # the appdef definition here is nothing else then the documentation of this for a software - start_time(NX_DATE_TIME): - doc: | - ISO 8601 time code with local time zone offset to UTC information - included when the atom probe session started. If the exact duration of - the measurement is not relevant start_time only should be used. - - Often though it is useful to specify both start_time and end_time to - capture more detailed bookkeeping of the experiment. The user should - be aware that even with having both dates specified, it may not be - possible to infer how long the experiment took or for how long data - were collected. - - More detailed timing data over the course of the experiment have to be - collected to compute this event chain during the experiment. For this - purpose the :ref:`NXevent_data_apm` instance should be used. - end_time(NX_DATE_TIME): - exists: recommended - doc: | - ISO 8601 time code with local time zone offset to UTC included - when the atom probe session ended. - (NXcite): - exists: ['min', '0', 'max', 'unbounded'] - doi(NX_CHAR): - serializedID(NXserialized): - exists: ['min', '0', 'max', 'unbounded'] - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - operation_mode(NX_CHAR): - doc: | - What type of atom probe experiment is performed? This field is meant to - inform research data management systems to allow filtering: - - * apt are experiments where the analysis_chamber has no imaging gas. - experiment with LEAP instruments are typically performed such. - * fim are experiments where the analysis_chamber has an imaging gas, - which should be specified with the atmosphere in the analysis_chamber group. - * apt_fim should be used for combinations of the two imaging modes. - few experiments of this type have been performed as this can be detrimental - to LEAP systems (see `S. Katnagallu et al. `_). - * other should be used in combination with the user specifying details - in the experiment_documentation field. - - If NXapm is used for storing details about a simulation use other for now. - enumeration: [apt, fim, apt_fim, other] - (NXuser): - exists: recommended - name(NX_CHAR): - exists: optional - identifier(NXidentifier): - exists: recommended - service(NX_CHAR): - identifier(NX_CHAR): - is_persistent(NX_BOOLEAN): - sample(NXsample): - exists: recommended - doc: | - Description of the sample from which the specimen was prepared or - site-specifically cut out using e.g. a focused-ion beam instrument. - - The sample group is currently a place for storing suggestions from - atom probers about knowledge they have gained about the sample. - There are cases where the specimen is machined further or exposed to - external stimuli during the experiment. In this case, these details should - not be stored under sample but suggestions should be made - how this application definition can be improved. - - In the future also details like how the grain_diameter was characterized, - how the sample was prepared, how the material was heat-treated etc., - should be stored. For this specific application definitions/schemas can be - used which are then arranged and documented with a description of the - workflow so that actionable graphs become instantiatable. - type(NX_CHAR): - doc: | - A qualifier whether the sample is a real one - or a virtual one (in a computer simulation). - enumeration: [experiment, simulation] - alias(NX_CHAR): - doc: | - Given name/alias for the sample. - identifier(NXidentifier): - exists: recommended - service(NX_CHAR): - identifier(NX_CHAR): - is_persistent(NX_BOOLEAN): - grain_diameter(NX_FLOAT): - exists: optional - unit: NX_LENGTH - doc: | - Qualitative information about the grain size, here specifically - described as the equivalent spherical diameter of an assumed - average grain size for the crystal ensemble. - Users of this information should be aware that although the grain - diameter or radius is often referred to as grain size. - - In atom probe it is possible that the specimen may contain a few - crystals only. In this case the grain_diameter is not a reliable - descriptor. Reporting a grain size may be useful though as it allows - judging if specific features are expected to be found in the - detector hit map. - grain_diameter_error(NX_FLOAT): - exists: optional - unit: NX_LENGTH - doc: | - Magnitude of the standard deviation of the grain_diameter. - - # schema for heat treatment - heat_treatment_temperature(NX_FLOAT): - exists: optional - unit: NX_TEMPERATURE - doc: | - The temperature of the last heat treatment step before quenching. - Knowledge about this value can give an idea how the sample - was heat treated. However, if a documentation of the annealing - treatment as a function of time is available one should better - rely on this information and have it stored alongside the NeXus file. - heat_treatment_temperature_error(NX_FLOAT): - exists: optional - unit: NX_TEMPERATURE - doc: | - Magnitude of the standard deviation of the heat_treatment_temperature. - heat_treatment_quenching_rate(NX_FLOAT): - exists: optional - unit: NX_ANY - doc: | - Rate of the last quenching step. Knowledge about this value can give - an idea how the sample was heat treated. However, there are many - situations where one can imagine that the scalar value for just the - quenching rate is insufficient. - - An example is when the sample was left in the furnace after the - furnace was switched off. In this case the sample cools down with - a specific rate of how this furnace cools down in the lab. - Processes which in practice are often not documented. - - This can be problematic though because when the furnace door was left open - or the ambient temperature in the lab changed, i.e. for a series of - experiments where one is conducted on a hot summer day and the next - during winter this can have an effect on the evolution of the microstructure. - There are many cases where this has been reported to be an QA issue in industry, - e.g. think about aging aluminium samples left on the factory - parking lot on a hot summer day. - heat_treatment_quenching_rate_error(NX_FLOAT): - exists: optional - unit: NX_ANY - doc: | - Magnitude of the standard deviation of the heat_treatment_quenching_rate. - description(NX_CHAR): - exists: optional - chemical_composition(NXchemical_composition): - exists: recommended - doc: | - The chemical composition of the sample. Typically, it is assumed that - this more macroscopic composition is representative for the material - so that the composition of the typically substantially less voluminous - specimen probes from the more voluminous sample. - normalization(NX_CHAR): - doc: | - Reporting compositions as atom and weight percent yields both - dimensionless quantities but their conceptual interpretation differs. - A normalization based on atom_percent counts relative to the - total number of atoms which are of a particular type. - By contrast, weight_percent normalization factorizes in the - respective mass of the elements. Python libraries like pint are - challenged by these differences as at.-% and wt.-% are both - fractional quantities. - enumeration: [atom_percent, weight_percent] - ionID(NXion): - exists: ['min', '1', 'max', '118'] - chemical_symbol(NX_CHAR): - doc: | - Human-readable name of the element (e.g. Fe). - Name has to be a symbol of an element from the periodic table. - All symbols in the set of NXion instances inside the group - chemical_composition need to be disjoint. - composition(NX_FLOAT): - unit: NX_DIMENSIONLESS - 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. - composition_error(NX_FLOAT): - exists: optional - unit: NX_DIMENSIONLESS - doc: | - Magnitude of the standard deviation of the composition (value). - specimen(NXsample): - type(NX_CHAR): - doc: | - A qualifier whether the specimen is a real one or a virtual one. - enumeration: [experiment, simulation] - alias(NX_CHAR): - exists: recommended - doc: | - Given name an alias. Better use identifier and parent_identifier instead. - A single NXentry should be used only for the characterization of a single specimen. - identifier(NXidentifier): - exists: recommended - service(NX_CHAR): - identifier(NX_CHAR): - is_persistent(NX_BOOLEAN): - parent_identifier(NXidentifier): - exists: recommended - doc: | - Identifier of the sample from which the specimen was cut or the string - n/a. The purpose of this field is to support functionalities for - tracking sample provenance via a research data management system. - service(NX_CHAR): - identifier(NX_CHAR): - is_persistent(NX_BOOLEAN): - preparation_date(NX_DATE_TIME): - exists: recommended - doc: | - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Ideally, this - matches the last timestamp that is mentioned in the digital resource - pointed to by parent_identifier. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments including tracers with a - short half time. Additional time stamps prior to preparation_date - should better be placed in resources which describe but which do not - pollute the description here with prose. Resolving these connected - pieces of information is considered within the responsibility of the - research data management system. - atom_types(NX_CHAR): - doc: | - List of comma-separated elements from the periodic table that are - contained in the specimen. If the specimen substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer research data management systems an - opportunity to parse the relevant elements without having to interpret - these from the resources pointed to by parent_identifier or walk through - eventually deeply nested groups in data instances. - description(NX_CHAR): - exists: optional - doc: | - Discouraged free-text field. - is_polycrystalline(NX_BOOLEAN): - exists: recommended - doc: | - Report if the specimen is polycrystalline, in which case it - contains a grain or phase boundary, or if the specimen is a - single crystal. - is_amorphous(NX_BOOLEAN): - exists: recommended - doc: | - Report if the specimen is amorphous. - initial_radius(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - doc: | - Ideally measured otherwise best elaborated guess of the initial radius of the - specimen. - shank_angle(NX_FLOAT): - exists: recommended - unit: NX_ANGLE - doc: | - Ideally measured otherwise best elaborated guess of the (initial) shank angle. - This is a measure of the specimen taper. Define it in such a way that the base of the specimen - is modelled as a conical frustrum so that the shank angle is the (shortest) angle between - the specimen space z-axis and a vector on the lateral surface of the cone. - - # describing the geometry of the specimen - coordinate_system_set(NXcoordinate_system_set): - doc: | - Set to hold different coordinate systems conventions. - Inspect the description of the :ref:`NXcoordinate_system_set` - and :ref:`NXcoordinate_system` base classes how to define - coordinate systems in NeXus. Specific details for application - in atom probe microscopy follow. - - In this research field scientists usually distinguish several - Euclidean coordinate systems (CS): - - * World space; - a CS specifying a local coordinate system of the planet earth which - identifies into which direction gravity is pointing such that - the laboratory space CS can be rotated into this world CS. - * The laboratory space; - a CS specifying the room where the instrument is located in or - a physical landmark on the instrument, e.g. the direction of the - transfer rod where positive is the direction how the rod - has to be pushed during loading a specimen into the instrument. - In summary, this CS is defined by the chassis of the instrument. - * The specimen space; - a CS affixed to either the base or the initial apex of the specimen, - whose z axis points towards the detector. - * The detector space; - a CS affixed to the detector plane whose xy plane is usually in the - detector and whose z axis points towards the specimen. - This is a distorted space with respect to the reconstructed ion - positions. - * The reconstruction space; - a CS in which the reconstructed ion positions are defined. - The orientation depends on the analysis software used. - * Eventually further coordinate systems attached to the - flight path of individual ions might be defined. - - In atom probe microscopy a frequently used choice for the detector - space (CS) is discussed with the so-called detector space image - (stack). This is a stack of two-dimensional histograms of detected ions - within a predefined evaporation identifier interval. Typically, the set of - ion evaporation sequence IDs is grouped into chunks. - - For each chunk a histogram of the ion hit positions on the detector - is computed. This leaves the possibility for inconsistency between - the so-called detector space and the e.g. specimen space. - - To avoid these ambiguities, instances of :ref:`NXtransformations` should - be used. - (NXcoordinate_system): - exists: ['min', '1', 'max', 'unbounded'] - origin(NX_CHAR): - alias(NX_CHAR): - type(NX_CHAR): - handedness(NX_CHAR): - x_direction(NX_CHAR): - y_direction(NX_CHAR): - z_direction(NX_CHAR): - measurement(NXapm_msr): - exists: optional - instrument(NXinstrument): - instrument_name(NX_CHAR): - exists: optional - fabrication(NXfabrication): - vendor(NX_CHAR): - model(NX_CHAR): - identifier(NXidentifier): - exists: recommended - reflectron(NXreflectron): - status(NX_CHAR): - fabrication(NXfabrication): - exists: recommended - vendor(NX_CHAR): - model(NX_CHAR): - - # decelerate_electrode(NXlens_em): - local_electrode(NXlens_em): - - # add flat test status - name(NX_CHAR): - fabrication(NXfabrication): - exists: recommended - vendor(NX_CHAR): - model(NX_CHAR): - ion_detector(NXdetector): - exists: recommended - fabrication(NXfabrication): - exists: recommended - vendor(NX_CHAR): - model(NX_CHAR): - pulser(NXpulser_apm): - fabrication(NXfabrication): - exists: recommended - vendor(NX_CHAR): - model(NX_CHAR): - pulse_mode(NX_CHAR): - sourceID(NXsource): - exists: ['min', '0', 'max', '2'] - fabrication(NXfabrication): - exists: recommended - vendor(NX_CHAR): - model(NX_CHAR): - wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - The wavelength of the radiation emitted by the source. - - # use NXbeam in the future - # stage_lab(NXstage_lab): - analysis_chamber(NXchamber): - exists: recommended - flight_path(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - doc: | - The space inside the atom probe along which ions pass nominally - when they leave the specimen and travel to the detector. - - # atmosphere(NXcollection): - # buffer_chamber(NXchamber): - # load_lock_chamber(NXchamber): - # getter_pump(NXpump): - # roughening_pump(NXpump): - # turbomolecular_pump(NXpump): - status(NX_CHAR): - event_data_apm_set(NXevent_data_apm_set): - exists: optional - - # the case of allowing to not have event_data but only the above-mentioned instrument - # details can be useful to convey details about an atom probe instrument in general - event_data_apm(NXevent_data_apm): - exists: recommended - - # all these cannot be made required because for LEAP only stored in RHIT/HITS - # but for M-TAP and Oxcart these pieces of information are available. - # start_time(NX_DATE_TIME): - # end_time(NX_DATE_TIME): - # delta_time(NX_NUMBER): - # pulse_identifier_offset(NX_INT): - # pulse_identifier(NX_INT): - instrument(NXinstrument): - exists: recommended - control(NXcollection): - evaporation_control(NX_CHAR): - target_detection_rate(NX_FLOAT): - - # optional groups can always be added but they will not be annotated eventually properly by pynxtools - # reflectron(NXreflectron): - # decelerate_electrode(NXlens_em): - # local_electrode(NXlens_em): - # ion_detector(NXdetector): - # exists: optional - # signal_amplitude(NX_FLOAT): - pulser(NXpulser_apm): - pulse_frequency(NX_FLOAT): - - # unit: NX_FREQUENCY - # dim: (p,) - \@logged_against: - type: NX_CHAR - pulse_fraction(NX_FLOAT): - - # unit: NX_DIMENSIONLESS - # dim: (p,) - \@logged_against: - type: NX_CHAR - pulse_voltage(NX_FLOAT): - exists: recommended - - # unit: NX_VOLTAGE - # dim: (p,) - \@logged_against: - type: NX_CHAR - - # pulse_number(NX_UINT): - standing_voltage(NX_FLOAT): - - # unit: NX_VOLTAGE - # dim: (p,) - \@logged_against: - type: NX_CHAR - (NXsource): - exists: ['min', '0', 'max', '2'] - pulse_energy(NX_FLOAT): - - # unit: NX_ENERGY - # dim: (p,) - \@logged_against: - type: NX_CHAR - - # laser geometry at the moment has no example nor any feedback from the community - # but NXpulser_apm base class shows how this could be done, plus examples for NXmpes - stage_lab(NXstage_lab): - - # setpoint_temperature(NX_FLOAT): - base_temperature(NX_FLOAT): - analysis_chamber(NXchamber): - chamber_pressure(NX_FLOAT): - - # buffer_chamber(NXchamber): - # load_lock_chamber(NXchamber): - # getter_pump(NXpump): - # roughening_pump(NXpump): - # turbomolecular_pump(NXpump): - simulation(NXapm_sim): - exists: optional - atom_probe(NXroi): - exists: recommended - doc: | - A region-of-interest analyzed either during or after the session for which - specific processed data of the measured or simulated data are available. - - # add a default plot V = f(time/evaporation_id), essentially for each quantity - # NEW ISSUE: check also here the PYCCAPT pipeline from P. Felfer's group - # all other details are instances of NXprocess as steps along the pipeline - - # NEW ISSUE: hit_quality table - # NEW ISSUE: pyccapt - # NEW ISSUE: add section for propagation_delay(NXprocess) ? - # NEW ISSUE: make recon an own subentry NXapm_reconstruction - # NEW ISSUE: different algorithms used one could create a class for each reconstruction method - # NEW ISSUE: make this rather an own subentry NXapm_ranging - initial_specimen(NXimage_set): - exists: recommended - doc: | - SEM or TEM image of the initial specimen i.e. - ideally taken prior to the data acquisition. - image_2d(NXdata): - \@signal: - type: NX_CHAR - \@axes: - type: NX_CHAR - \@AXISNAME_indices: - type: NX_CHAR - real(NX_NUMBER): - axis_j(NX_NUMBER): - dimensions: - rank: 1 - dim: [[1, n_j]] - \@long_name: - type: NX_CHAR - axis_i(NX_NUMBER): - dimensions: - rank: 1 - dim: [[1, n_i]] - \@long_name: - type: NX_CHAR - - # one could use a stack_3d(NXdata) to record - # a time series of the specimen shape evolution - raw_data(NXprocess): - exists: recommended - sequence_index(NX_POSINT): - exists: recommended - programID(NXprogram): - exists: ['min', '0', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - - # point at least to the proprietary artifact - serialized(NXserialized): - exists: recommended - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - hit_finding(NXapm_hit_finding): - exists: recommended - - # we careful how we go about doing this here, we recommended to make some details of the hit_finding - # algorithm open namely the input and the output what the black box then does by AMETEK/Cameca - # does not have to be exposed (although this clearly is against FAIR principles but the scientific community - # is does not have the authority to decide which portions of proprietary code have to be public - # we can only make recommendations - sequence_index(NX_POSINT): - exists: recommended - programID(NXprogram): - exists: ['min', '0', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - - # config of the hit_finding algorithm - serialized(NXserialized): - exists: recommended - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - number_of_dld_wires(NX_UINT): - exists: recommended - arrival_time_pairs(NX_NUMBER): - exists: optional - - # results of the hit_finding algorithm - hit_quality_types(NX_CHAR): - exists: optional - hit_quality_identifier(NX_UINT): - exists: optional - hit_positions(NX_NUMBER): - exists: recommended - dimensions: - rank: 2 - dim: [[1, i], [2, 2]] - hit_quality(NX_UINT): - exists: optional - dimensions: - rank: 1 - dim: [[1, i]] - hit_multiplicity(NX_UINT): - exists: recommended - dimensions: - rank: 1 - dim: [[1, i]] - - # statistics(NXprocess): - # multiples(NX_FLOAT): - # doc: | - # Fraction of multiple hits. - # unit: NX_DIMENSIONLESS - # the following two quantities are relicts from ePOS files used to give some - # insight into the results of the hit_finding algorithm of IVAS/APSuite but typically - # used only in the context to learn about the multiplicity of an ion. - # pulses_since_last_ion(NX_UINT): - # exists: optional - # dim: (i,) - # pulse_identifier(NX_INT): # this is the pulse on which they came - # exists: optional - # dim: (i,) - # i number of hits after hits finding but prior calibrations - hit_spatial_filtering(NXprocess): - exists: recommended - sequence_index(NX_POSINT): - exists: recommended - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - serialized(NXserialized): - exists: optional - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - evaporation_identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer used to name the first pulse to know if there is an - offset of the evaporation_identifier to zero. - - Identifiers can be defined either implicitly or explicitly. - For implicit indexing identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. - - Therefore, implicit identifier are completely defined by the value of - identifier_offset and cardinality. For example if identifier run from - -2 to 3 the value for identifier_offset is -2. - - For explicit indexing the field identifier has to be used. - Fortran-/Matlab- and C-/Python-style indexing have specific implicit - identifier conventions where identifier_offset is 1 and 0 respectively. - evaporation_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - (Molecular) ion identifier which resolves the sequence in which - the ions were evaporated but taking into account that a hit_finding - and spatial_filtering was applied. - dimensions: - rank: 1 - dim: [[1, n]] - hit_filter(NXcs_filter_boolean_mask): - exists: recommended - - # use NXcs_filter needs conditionally an instance of concept ../../hit_finding - number_of_objects(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - identifier(NX_INT): - - # at this point the original set of events p has been filtered down to n - voltage_and_bowl(NXapm_volt_and_bowl): - exists: recommended - sequence_index(NX_POSINT): - exists: recommended - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - serialized(NXserialized): - exists: optional - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - - # config/input to the algorithm - # 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 - dimensions: - rank: 1 - dim: [[1, n]] - - # result - calibrated_tof(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, n]] - mass_to_charge_conversion(NXprocess): - exists: recommended - sequence_index(NX_POSINT): - exists: recommended - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - serialized(NXserialized): - exists: recommended - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - - # config/input - # results - mass_to_charge(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, n]] - reconstruction(NXapm_reconstruction): - exists: recommended - sequence_index(NX_POSINT): - exists: recommended - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - config(NXserialized): - exists: recommended - doc: | - For LEAP and IVAS/APSuite-based analyses root file which stores - the settings whereby an RHIT/HITS file can be used to regenerate the - reconstruction that is here referred to. - - The respective RHIT/HITS file should ideally be specified in the serialized - group of the hit_finding section of this application definition. - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - results(NXserialized): - exists: recommended - doc: | - For LEAP and IVAS/APSuite-based analyses the resulting typically - file with the reconstructed positions and (calibrated) mass-to-charge - state ratio values. - - For other data collection/analysis software the data artifact which comes - closest conceptually to AMETEK/Cameca's typical file formats. - - These are typically exported as a POS, ePOS, APT, ATO, ENV, or HDF5 file, - which should be stored alongside this record in the research data - management system. - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - - # config/input - parameter(NX_CHAR): - protocol_name(NX_CHAR): - exists: recommended - crystallographic_calibration(NX_CHAR): - exists: recommended - field_of_view(NX_FLOAT): - exists: recommended - reconstructed_positions(NX_FLOAT): - dimensions: - rank: 2 - dim: [[1, n], [2, 3]] - naive_discretization(NXprocess): - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - - # config/input - # results - (NXdata): - \@signal: - type: NX_CHAR - \@axes: - type: NX_CHAR - \@AXISNAME_indices: - type: NX_CHAR - - # dim: (3,) - # \@long_name: - title(NX_CHAR): - intensity(NX_NUMBER): - dimensions: - rank: 3 - dim: [[1, n_z], [2, n_y], [3, n_x]] - axis_z(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, n_z]] - \@long_name: - type: NX_CHAR - axis_y(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - type: NX_CHAR - axis_x(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - type: NX_CHAR - ranging(NXapm_ranging): - exists: recommended - sequence_index(NX_POSINT): - exists: recommended - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - definitions(NXserialized): - exists: recommended - doc: | - The respective ranging definitions file RNG/RRNG/ENV/HDF5. - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - - # number_of_ion_types(NX_UINT): - maximum_number_of_atoms_per_molecular_ion(NX_UINT): - mass_to_charge_distribution(NXprocess): - exists: recommended - sequence_index(NX_POSINT): - exists: recommended - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - min_incr_max(NX_FLOAT): - - # dim: (3,) # u - mass_spectrum(NXdata): - \@signal: - type: NX_CHAR - \@axes: - type: NX_CHAR - \@AXISNAME_indices: - type: NX_CHAR - - # \@long_name(NX_CHAR): - title(NX_CHAR): - intensity(NX_NUMBER): - dimensions: - rank: 1 - dim: [[1, n_bins]] - \@long_name: - type: NX_CHAR - axis_mass_to_charge(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, n_bins]] - \@long_name: - type: NX_CHAR - background_quantification(NXprocess): - exists: recommended - sequence_index(NX_POSINT): - exists: recommended - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - background(NX_FLOAT): - exists: recommended - unit: NX_ANY - doc: | - (Out-of-sync) background levels in ppm/ns - reported by e.g. IVAS/APSuite for LEAP systems. - mrp_value(NX_FLOAT): - exists: recommended - unit: NX_DIMENSIONLESS - doc: | - MRP, mass-resolving power, `D. Larson et al. - `_ (p282, Eqs. D.7 and D.8). - mrp_mass_to_charge(NX_FLOAT): - exists: recommended - unit: NX_ANY - doc: | - MRP, at which mrp_value was specified. - - # config/input - # results - # NEW ISSUE: add parameters of the background model - # in an e.g. work of A. London et al. - peak_search(NXprocess): - exists: recommended - sequence_index(NX_POSINT): - exists: recommended - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - peakID(NXpeak): - exists: ['min', '0', 'max', 'unbounded'] - label(NX_CHAR): - exists: recommended - description(NX_CHAR): - category(NX_CHAR): - exists: recommended - doc: | - Category for the peak offering a qualitative statement of the location of the peak - in light of limited mass-resolving power that is relevant for - composition quantification. See `D. Larson et al. (p172) `_ - for examples of each category: - - * 0, well-separated, :math:`^{10}B^{+}`, :math:`^{28}Si^{2+}` - * 1, close, but can be sufficiently separated for quantification in a LEAP system, :math:`^{94}Mo^{3+}`, :math:`^{63}Cu^{2+}` - * 2, closely overlapping, demands better than LEAP4000X MRP can provide :math:`^{14}N^{+}`, :math:`^{28}Si^{2+}` at different charge states - * 3, overlapped exactly due to multi-charge molecular species, :math:`^{16}{O_{2}}^{2+}`, :math:`^{16}O^{+}` - * 4, overlapped, same charge state, cannot as of 2013 be discriminated with a LEAP4000X, :math:`^{14}{N_{2}}^{+}`, :math:`^{28}Si^{+}` - * 5, overlapped, same charge state, any expectation of resolvability, :math:`^{54}Cr^{2+}`, :math:`^{54}Fe^{2+}` - enumeration: [0, 1, 2, 3, 4, 5] - position(NX_NUMBER): - - # peak deconvolution(NXprocess): - peak_identification(NXprocess): - exists: recommended - sequence_index(NX_POSINT): - exists: recommended - programID(NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program(NX_CHAR): - \@version: - type: NX_CHAR - ionID(NXion): - exists: ['min', '1', 'max', '256'] - nuclide_hash(NX_UINT): - charge_state(NX_INT): - charge_state_analysis(NXapm_charge_state_analysis): - exists: optional - - # config - nuclides(NX_UINT): - mass_to_charge_range(NX_FLOAT): - min_half_life(NX_FLOAT): - min_abundance(NX_FLOAT): - min_abundance_product(NX_FLOAT): - sacrifice_isotopic_uniqueness(NX_BOOLEAN): - - # results - charge_state(NX_INT): - nuclide_hash(NX_UINT): - mass(NX_FLOAT): - natural_abundance_product(NX_FLOAT): - shortest_half_life(NX_FLOAT): - mass_to_charge_range(NX_FLOAT): - nuclide_list(NX_UINT): - exists: recommended - name(NX_CHAR): - exists: recommended - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 1c7143c9e21a60f751383457144a2a62e67bbf06354716f03869297b8f145010 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of pulses collected in between start_time and end_time resolved by an -# instance of :ref:`NXevent_data_apm`. If this is not defined, p is the number of -# ions included in the reconstructed volume if the application definition is used -# to store results of an already reconstructed datasets. -# -# -# -# -# Number of ions spatially filtered from results of the hit_finding algorithm -# from which an instance of a reconstructed volume has been generated. -# These ions get new identifier assigned in the process (the so-called -# evaporation_identifier). This identifier must not be confused with -# the pulse_identifier. -# -# -# -# -# Application definition for atom probe and field ion microscopy experiments. -# -# -# -# -# -# -# -# -# -# -# The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_ or its plugins) -# which was used to generate this NeXus file instance. -# -# -# -# -# A collection of all programs and libraries which are considered relevant -# to understand with which software tools this NeXus file instance was -# generated. Ideally, to enable a binary recreation from the input data. -# -# Examples include the name and version of the libraries used to write the -# instance. Ideally, the software which writes these NXprogram instances -# also includes the version of the set of NeXus classes i.e. the specific -# set of base classes, application definitions, and contributed definitions -# with which the here described concepts can be resolved. -# -# For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ -# which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ -# research data management system, it makes sense to store e.g. the GitHub -# repository commit and respective submodule references used. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The identifier whereby the experiment is referred to in the control software. -# This is neither the specimen_name nor the experiment_identifier. For -# Local Electrode Atom Probe (LEAP) instruments, it is recommended to use the -# run_number from the proprietary software IVAS/APSuite of AMETEK/Cameca. -# For other instruments, such as the one from Stuttgart or Oxcart from Erlangen, -# or the instruments at GPM in Rouen, use the identifier which matches -# best conceptually to the LEAP run number. -# The field does not have to be required if the information is recoverable -# in the dataset which for LEAP instruments is the case (provided these -# RHIT or HITS files respectively are stored alongside a data artifact). -# With NXapm the RHIT or HITS can be stored as via the NXserialized group -# in the hit_finding algorithm section. -# -# As a destructive microscopy technique, a run can be performed only once. -# It is possible, however, to interrupt a run and restart data acquisition -# while still using the same specimen. In this case, each evaporation run -# needs to be distinguished with different run numbers. -# We follow this habit of most atom probe groups. Such interrupted runs -# should be stored as individual :ref:`NXentry` instances in one NeXus file. -# -# -# -# -# Either an identifier or an alias that is human-friendly so that scientists find that experiment again. -# For experiments usually this is the run_number but for simulation typically no run_numbers are issued. -# -# -# -# -# Free-text description about the experiment. -# -# Users are strongly advised to parameterize the description of their experiment -# by using respective groups and fields and base classes instead of writing prose -# into this field. -# -# The reason is that such free-text field is difficult to machine-interpret. -# The motivation behind keeping this field for now is to learn in how far the -# current base classes need extension based on user feedback. -# -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC information -# included when the atom probe session started. If the exact duration of -# the measurement is not relevant start_time only should be used. -# -# Often though it is useful to specify both start_time and end_time to -# capture more detailed bookkeeping of the experiment. The user should -# be aware that even with having both dates specified, it may not be -# possible to infer how long the experiment took or for how long data -# were collected. -# -# More detailed timing data over the course of the experiment have to be -# collected to compute this event chain during the experiment. For this -# purpose the :ref:`NXevent_data_apm` instance should be used. -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC included -# when the atom probe session ended. -# -# -# -# -# -# -# -# -# -# -# -# -# -# What type of atom probe experiment is performed? This field is meant to -# inform research data management systems to allow filtering: -# -# * apt are experiments where the analysis_chamber has no imaging gas. -# experiment with LEAP instruments are typically performed such. -# * fim are experiments where the analysis_chamber has an imaging gas, -# which should be specified with the atmosphere in the analysis_chamber group. -# * apt_fim should be used for combinations of the two imaging modes. -# few experiments of this type have been performed as this can be detrimental -# to LEAP systems (see `S. Katnagallu et al. <https://doi.org/10.1017/S1431927621012381>`_). -# * other should be used in combination with the user specifying details -# in the experiment_documentation field. -# -# If NXapm is used for storing details about a simulation use other for now. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Description of the sample from which the specimen was prepared or -# site-specifically cut out using e.g. a focused-ion beam instrument. -# -# The sample group is currently a place for storing suggestions from -# atom probers about knowledge they have gained about the sample. -# There are cases where the specimen is machined further or exposed to -# external stimuli during the experiment. In this case, these details should -# not be stored under sample but suggestions should be made -# how this application definition can be improved. -# -# In the future also details like how the grain_diameter was characterized, -# how the sample was prepared, how the material was heat-treated etc., -# should be stored. For this specific application definitions/schemas can be -# used which are then arranged and documented with a description of the -# workflow so that actionable graphs become instantiatable. -# -# -# -# A qualifier whether the sample is a real one -# or a virtual one (in a computer simulation). -# -# -# -# -# -# -# -# -# Given name/alias for the sample. -# -# -# -# -# -# -# -# -# -# Qualitative information about the grain size, here specifically -# described as the equivalent spherical diameter of an assumed -# average grain size for the crystal ensemble. -# Users of this information should be aware that although the grain -# diameter or radius is often referred to as grain size. -# -# In atom probe it is possible that the specimen may contain a few -# crystals only. In this case the grain_diameter is not a reliable -# descriptor. Reporting a grain size may be useful though as it allows -# judging if specific features are expected to be found in the -# detector hit map. -# -# -# -# -# Magnitude of the standard deviation of the grain_diameter. -# -# -# -# -# -# The temperature of the last heat treatment step before quenching. -# Knowledge about this value can give an idea how the sample -# was heat treated. However, if a documentation of the annealing -# treatment as a function of time is available one should better -# rely on this information and have it stored alongside the NeXus file. -# -# -# -# -# Magnitude of the standard deviation of the heat_treatment_temperature. -# -# -# -# -# Rate of the last quenching step. Knowledge about this value can give -# an idea how the sample was heat treated. However, there are many -# situations where one can imagine that the scalar value for just the -# quenching rate is insufficient. -# -# An example is when the sample was left in the furnace after the -# furnace was switched off. In this case the sample cools down with -# a specific rate of how this furnace cools down in the lab. -# Processes which in practice are often not documented. -# -# This can be problematic though because when the furnace door was left open -# or the ambient temperature in the lab changed, i.e. for a series of -# experiments where one is conducted on a hot summer day and the next -# during winter this can have an effect on the evolution of the microstructure. -# There are many cases where this has been reported to be an QA issue in industry, -# e.g. think about aging aluminium samples left on the factory -# parking lot on a hot summer day. -# -# -# -# -# Magnitude of the standard deviation of the heat_treatment_quenching_rate. -# -# -# -# -# -# The chemical composition of the sample. Typically, it is assumed that -# this more macroscopic composition is representative for the material -# so that the composition of the typically substantially less voluminous -# specimen probes from the more voluminous sample. -# -# -# -# Reporting compositions as atom and weight percent yields both -# dimensionless quantities but their conceptual interpretation differs. -# A normalization based on atom_percent counts relative to the -# total number of atoms which are of a particular type. -# By contrast, weight_percent normalization factorizes in the -# respective mass of the elements. Python libraries like pint are -# challenged by these differences as at.-% and wt.-% are both -# fractional quantities. -# -# -# -# -# -# -# -# -# -# Human-readable name of the element (e.g. Fe). -# Name has to be a symbol of an element from the periodic table. -# All symbols in the set of NXion instances inside the group -# chemical_composition need to be disjoint. -# -# -# -# -# Composition value for the element/ion referred to under name. -# The value is normalized based on normalization, i.e. composition -# is either an atom or weight percent quantity. -# -# -# -# -# Magnitude of the standard deviation of the composition (value). -# -# -# -# -# -# -# -# -# A qualifier whether the specimen is a real one or a virtual one. -# -# -# -# -# -# -# -# -# Given name an alias. Better use identifier and parent_identifier instead. -# A single NXentry should be used only for the characterization of a single specimen. -# -# -# -# -# -# -# -# -# -# Identifier of the sample from which the specimen was cut or the string -# n/a. The purpose of this field is to support functionalities for -# tracking sample provenance via a research data management system. -# -# -# -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC information -# when the specimen was prepared. -# -# Ideally, report the end of the preparation, i.e. the last known time -# the measured specimen surface was actively prepared. Ideally, this -# matches the last timestamp that is mentioned in the digital resource -# pointed to by parent_identifier. -# -# Knowing when the specimen was exposed to e.g. specific atmosphere is -# especially required for environmentally sensitive material such as -# hydrogen charged specimens or experiments including tracers with a -# short half time. Additional time stamps prior to preparation_date -# should better be placed in resources which describe but which do not -# pollute the description here with prose. Resolving these connected -# pieces of information is considered within the responsibility of the -# research data management system. -# -# -# -# -# List of comma-separated elements from the periodic table that are -# contained in the specimen. If the specimen substance has multiple -# components, all elements from each component must be included in -# `atom_types`. -# -# The purpose of the field is to offer research data management systems an -# opportunity to parse the relevant elements without having to interpret -# these from the resources pointed to by parent_identifier or walk through -# eventually deeply nested groups in data instances. -# -# -# -# -# Discouraged free-text field. -# -# -# -# -# Report if the specimen is polycrystalline, in which case it -# contains a grain or phase boundary, or if the specimen is a -# single crystal. -# -# -# -# -# Report if the specimen is amorphous. -# -# -# -# -# Ideally measured otherwise best elaborated guess of the initial radius of the -# specimen. -# -# -# -# -# Ideally measured otherwise best elaborated guess of the (initial) shank angle. -# This is a measure of the specimen taper. Define it in such a way that the base of the specimen -# is modelled as a conical frustrum so that the shank angle is the (shortest) angle between -# the specimen space z-axis and a vector on the lateral surface of the cone. -# -# -# -# -# -# -# Set to hold different coordinate systems conventions. -# Inspect the description of the :ref:`NXcoordinate_system_set` -# and :ref:`NXcoordinate_system` base classes how to define -# coordinate systems in NeXus. Specific details for application -# in atom probe microscopy follow. -# -# In this research field scientists usually distinguish several -# Euclidean coordinate systems (CS): -# -# * World space; -# a CS specifying a local coordinate system of the planet earth which -# identifies into which direction gravity is pointing such that -# the laboratory space CS can be rotated into this world CS. -# * The laboratory space; -# a CS specifying the room where the instrument is located in or -# a physical landmark on the instrument, e.g. the direction of the -# transfer rod where positive is the direction how the rod -# has to be pushed during loading a specimen into the instrument. -# In summary, this CS is defined by the chassis of the instrument. -# * The specimen space; -# a CS affixed to either the base or the initial apex of the specimen, -# whose z axis points towards the detector. -# * The detector space; -# a CS affixed to the detector plane whose xy plane is usually in the -# detector and whose z axis points towards the specimen. -# This is a distorted space with respect to the reconstructed ion -# positions. -# * The reconstruction space; -# a CS in which the reconstructed ion positions are defined. -# The orientation depends on the analysis software used. -# * Eventually further coordinate systems attached to the -# flight path of individual ions might be defined. -# -# In atom probe microscopy a frequently used choice for the detector -# space (CS) is discussed with the so-called detector space image -# (stack). This is a stack of two-dimensional histograms of detected ions -# within a predefined evaporation identifier interval. Typically, the set of -# ion evaporation sequence IDs is grouped into chunks. -# -# For each chunk a histogram of the ion hit positions on the detector -# is computed. This leaves the possibility for inconsistency between -# the so-called detector space and the e.g. specimen space. -# -# To avoid these ambiguities, instances of :ref:`NXtransformations` should -# be used. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The wavelength of the radiation emitted by the source. -# -# -# -# -# -# -# -# -# The space inside the atom probe along which ions pass nominally -# when they leave the specimen and travel to the detector. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# A region-of-interest analyzed either during or after the session for which -# specific processed data of the measured or simulated data are available. -# -# -# -# -# -# SEM or TEM image of the initial specimen i.e. -# ideally taken prior to the data acquisition. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Integer used to name the first pulse to know if there is an -# offset of the evaporation_identifier to zero. -# -# Identifiers can be defined either implicitly or explicitly. -# For implicit indexing identifiers are defined on the interval -# :math:`[identifier\_offset, identifier\_offset + c - 1]`. -# -# Therefore, implicit identifier are completely defined by the value of -# identifier_offset and cardinality. For example if identifier run from -# -2 to 3 the value for identifier_offset is -2. -# -# For explicit indexing the field identifier has to be used. -# Fortran-/Matlab- and C-/Python-style indexing have specific implicit -# identifier conventions where identifier_offset is 1 and 0 respectively. -# -# -# -# -# (Molecular) ion identifier which resolves the sequence in which -# the ions were evaporated but taking into account that a hit_finding -# and spatial_filtering was applied. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# For LEAP and IVAS/APSuite-based analyses root file which stores -# the settings whereby an RHIT/HITS file can be used to regenerate the -# reconstruction that is here referred to. -# -# The respective RHIT/HITS file should ideally be specified in the serialized -# group of the hit_finding section of this application definition. -# -# -# -# -# -# -# -# -# For LEAP and IVAS/APSuite-based analyses the resulting typically -# file with the reconstructed positions and (calibrated) mass-to-charge -# state ratio values. -# -# For other data collection/analysis software the data artifact which comes -# closest conceptually to AMETEK/Cameca's typical file formats. -# -# These are typically exported as a POS, ePOS, APT, ATO, ENV, or HDF5 file, -# which should be stored alongside this record in the research data -# management system. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The respective ranging definitions file RNG/RRNG/ENV/HDF5. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# (Out-of-sync) background levels in ppm/ns -# reported by e.g. IVAS/APSuite for LEAP systems. -# -# -# -# -# MRP, mass-resolving power, `D. Larson et al. -# <https://doi.org/10.1007/978-1-4614-8721-0>`_ (p282, Eqs. D.7 and D.8). -# -# -# -# -# MRP, at which mrp_value was specified. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Category for the peak offering a qualitative statement of the location of the peak -# in light of limited mass-resolving power that is relevant for -# composition quantification. See `D. Larson et al. (p172) <https://doi.org/10.1007/978-1-4614-8721-0>`_ -# for examples of each category: -# -# * 0, well-separated, :math:`^{10}B^{+}`, :math:`^{28}Si^{2+}` -# * 1, close, but can be sufficiently separated for quantification in a LEAP system, :math:`^{94}Mo^{3+}`, :math:`^{63}Cu^{2+}` -# * 2, closely overlapping, demands better than LEAP4000X MRP can provide :math:`^{14}N^{+}`, :math:`^{28}Si^{2+}` at different charge states -# * 3, overlapped exactly due to multi-charge molecular species, :math:`^{16}{O_{2}}^{2+}`, :math:`^{16}O^{+}` -# * 4, overlapped, same charge state, cannot as of 2013 be discriminated with a LEAP4000X, :math:`^{14}{N_{2}}^{+}`, :math:`^{28}Si^{+}` -# * 5, overlapped, same charge state, any expectation of resolvability, :math:`^{54}Cr^{2+}`, :math:`^{54}Fe^{2+}` -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml b/contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml deleted file mode 100644 index c3b35b8fb6..0000000000 --- a/contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml +++ /dev/null @@ -1,295 +0,0 @@ -category: base -doc: | - Base class to document an algorithm for recovering charge state and nuclide composition of a (molecular) ion. - - Currently ranging definitions in the research field of atom probe face have limitations: - - 1. A ranging definition maps all signal within a mass-to-charge-state-ratio value interval - on one iontype. Facing limited mass-resolving-power, there are mass-to-charge-state-ratio - values, though, for which not only multiple (molecular) ions are indistinguishable but - also for which the current practice of documenting classical ranging definitions is incomplete. - 2. Indeed, ranging definitions often report only (for each interval) the - mass-to-charge-state-ratio intervals surplus the composition of elements - that build the (molecular) ion. - 3. Therefore, classical ranging definitions demand a post-processing with an algorithm - which can identify nuclides from which the (molecular) ion is constructed - and a charge state possibly recovered. Combinatorial algorithms are used for this purpose. - - This base class documents the configuration and results of such an algorithm. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_cand: | - The number of also possible but different (molecular) ions. - n_ivec_max: | - Maximum number of allowed atoms per (molecular) ion (fragment). - n_variable: | - Number of entries -type: group -NXapm_charge_state_analysis(NXprocess): - - # Details and results of the combinatorial analyses of a ranging definition - # to clarify (if possible) the charge_state of an ion and its (not necessarily) - # unique combination of nuclides contained including their multiplicity. - # input/config - nuclides(NX_UINT): - unit: NX_UNITLESS - doc: | - Input constraint, list of nuclide_hash for typically elements used for the - ranging definition of the ion whose charge state the analyses covered. - The list contains each hash as many times as its multiplicity. - Nuclides are encoded using the hashing rule that is defined in :ref:`NXion`. - - As an example, a ranging definition H:2 O:1 is configured by setting nuclides to - a list with entries :math:`1 + 0 \cdot 256`, :math:`1 + 0 \cdot 256`, :math:`8 + 0 \cdot 256`. - An empty list does not release the constraint. Instead, a list with all elements - in the periodic table (encoded as nuclide_hash values) should be used, i.e. - :math:`1 + 0 \cdot 256`, :math:`2 + 0 \cdot 256`, and so on and so forth. - - Keep in mind that with a weakly constrained parameter space the combinatorial - analysis may become very time consuming! - dimensions: - rank: 1 - dim: [[1, n_variable]] - mass_to_charge_range(NX_FLOAT): - unit: NX_ANY - doc: | - Input constraint, interval within which (molecular) ions need to have the - mass-to-charge-state-ratio such that an ion qualifies as a candidate. - dimensions: - rank: 2 - dim: [[1, 1], [2, 2]] - min_half_life(NX_FLOAT): - unit: NX_TIME - doc: | - Input constraint, minimum half life for how long each nuclide of each - (molecular) ion needs to be stable such that the ion qualifies as a candidate. - min_abundance(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Input constraint, minimum natural abundance of each nuclide of each - (molecular) ion such that the ion qualifies as a candidate. - sacrifice_isotopic_uniqueness(NX_BOOLEAN): - doc: | - If the value is false, it means that non-unique solutions are accepted. - These are solutions where multiple candidates have been built from - different nuclide instances but the charge_state of all the ions is the same. - - # min_abundance_product(NX_FLOAT): - # doc: | - # For each candidate TO BE DEFINED. - # unit: NX_DIMENSIONLESS - # dim: (n_cand,) - - # output/results - # the n_cand can be 1 in which case all quantities below are scalar - charge_state(NX_INT): - unit: NX_UNITLESS - doc: | - Signed charge, i.e. integer multiple of the elementary - charge of each candidate. - dimensions: - rank: 1 - dim: [[1, n_cand]] - nuclide_hash(NX_UINT): - unit: NX_UNITLESS - doc: | - Table of nuclide instances of which each candidate is composed. - Each row vector is sorted in descending order. Unused values are nullified. - dimensions: - rank: 2 - dim: [[1, n_cand], [2, n_ivec_max]] - mass(NX_FLOAT): - unit: NX_MASS - doc: | - Accumulated mass of the nuclides in each candidate. - Not corrected for quantum effects. - dimensions: - rank: 1 - dim: [[1, n_cand]] - natural_abundance_product(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - The product of the natural abundances of the nuclides for each candidate. - dimensions: - rank: 1 - dim: [[1, n_cand]] - shortest_half_life(NX_FLOAT): - unit: NX_TIME - doc: | - For each candidate the half life of that nuclide which has the shortest half - life. - dimensions: - rank: 1 - dim: [[1, n_cand]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a9ee8cc28f0b65fd86f57409a9c945b6790c9fd714cb38441ad7c595a261f1ef -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The number of also possible but different (molecular) ions. -# -# -# -# -# Maximum number of allowed atoms per (molecular) ion (fragment). -# -# -# -# -# Number of entries -# -# -# -# -# Base class to document an algorithm for recovering charge state and nuclide composition of a (molecular) ion. -# -# Currently ranging definitions in the research field of atom probe face have limitations: -# -# 1. A ranging definition maps all signal within a mass-to-charge-state-ratio value interval -# on one iontype. Facing limited mass-resolving-power, there are mass-to-charge-state-ratio -# values, though, for which not only multiple (molecular) ions are indistinguishable but -# also for which the current practice of documenting classical ranging definitions is incomplete. -# 2. Indeed, ranging definitions often report only (for each interval) the -# mass-to-charge-state-ratio intervals surplus the composition of elements -# that build the (molecular) ion. -# 3. Therefore, classical ranging definitions demand a post-processing with an algorithm -# which can identify nuclides from which the (molecular) ion is constructed -# and a charge state possibly recovered. Combinatorial algorithms are used for this purpose. -# -# This base class documents the configuration and results of such an algorithm. -# -# -# -# -# Input constraint, list of nuclide_hash for typically elements used for the -# ranging definition of the ion whose charge state the analyses covered. -# The list contains each hash as many times as its multiplicity. -# Nuclides are encoded using the hashing rule that is defined in :ref:`NXion`. -# -# As an example, a ranging definition H:2 O:1 is configured by setting nuclides to -# a list with entries :math:`1 + 0 \cdot 256`, :math:`1 + 0 \cdot 256`, :math:`8 + 0 \cdot 256`. -# An empty list does not release the constraint. Instead, a list with all elements -# in the periodic table (encoded as nuclide_hash values) should be used, i.e. -# :math:`1 + 0 \cdot 256`, :math:`2 + 0 \cdot 256`, and so on and so forth. -# -# Keep in mind that with a weakly constrained parameter space the combinatorial -# analysis may become very time consuming! -# -# -# -# -# -# -# -# Input constraint, interval within which (molecular) ions need to have the -# mass-to-charge-state-ratio such that an ion qualifies as a candidate. -# -# -# -# -# -# -# -# -# Input constraint, minimum half life for how long each nuclide of each -# (molecular) ion needs to be stable such that the ion qualifies as a candidate. -# -# -# -# -# Input constraint, minimum natural abundance of each nuclide of each -# (molecular) ion such that the ion qualifies as a candidate. -# -# -# -# -# If the value is false, it means that non-unique solutions are accepted. -# These are solutions where multiple candidates have been built from -# different nuclide instances but the charge_state of all the ions is the same. -# -# -# -# -# -# -# Signed charge, i.e. integer multiple of the elementary -# charge of each candidate. -# -# -# -# -# -# -# -# Table of nuclide instances of which each candidate is composed. -# Each row vector is sorted in descending order. Unused values are nullified. -# -# -# -# -# -# -# -# -# Accumulated mass of the nuclides in each candidate. -# Not corrected for quantum effects. -# -# -# -# -# -# -# -# The product of the natural abundances of the nuclides for each candidate. -# -# -# -# -# -# -# -# For each candidate the half life of that nuclide which has the shortest half -# life. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_hit_finding.yaml b/contributed_definitions/nyaml/NXapm_hit_finding.yaml deleted file mode 100644 index 7337efa8ae..0000000000 --- a/contributed_definitions/nyaml/NXapm_hit_finding.yaml +++ /dev/null @@ -1,246 +0,0 @@ -category: base -doc: | - Base class for the configuration and results from a hit finding algorithm. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_dld: | - Number of delay-line wires of the detector. - n_ht: | - Number of hit qualities (hit types) distinguished. - p: | - Number of pulses collected in between start_time and end_time - resolved by an instance of :ref:`NXevent_data_apm`. If this is not defined, - p is the number of ions included in the reconstructed volume if an application - definition is used to store results of already reconstructed datasets. -type: group -NXapm_hit_finding(NXprocess): - (NXprogram): - (NXserialized): - - # config/input - number_of_dld_wires(NX_UINT): - unit: NX_UNITLESS - doc: | - The number of wires in the detector. - enumeration: [1, 2, 3] - dld_wire_names(NX_CHAR): - doc: | - Alias tuple (begin, end) of each DLD wire of the detector. - Order follows arrival_time_pairs. - dimensions: - rank: 2 - dim: [[1, n_dld], [2, 2]] - arrival_time_pairs(NX_NUMBER): - unit: NX_TIME - doc: | - Raw readings from the analog-to-digital-converter - timing circuits of the detector wires. - dimensions: - rank: 3 - dim: [[1, p], [2, n_dld], [3, 2]] - - # results of the hit_finding algorithm - hit_positions(NX_NUMBER): - unit: NX_LENGTH - doc: | - Evaluated ion impact coordinates on the detector. - Use the depends_on field to spec - dimensions: - rank: 2 - dim: [[1, p], [2, 2]] - \@depends_on: - type: NX_CHAR - doc: | - Defines in which reference frame the positions are defined. - hit_quality_types(NX_CHAR): - doc: | - Name of the hit_qualities distinguished. - AMETEK/Cameca uses e.g. golden, multiple, partial, - irrecoverable, and multi-first and multi-late. - dimensions: - rank: 1 - dim: [[1, n_ht]] - hit_quality_identifier(NX_UINT): - doc: | - Identifier used for each hit_quality type. - Following the order of hit_quality_types. - hit_quality(NX_UINT): - unit: NX_UNITLESS - doc: | - Hit quality identifier for each pulse. - Identifier have to be within hit_quality_identifier. - dimensions: - rank: 1 - dim: [[1, p]] - hit_multiplicity(NX_UINT): - unit: NX_UNITLESS - doc: | - This processing yields for each ion with how many others it evaporated - if these were collected on the same pulse. Extraction of multiple ions - on one pulse on different or even the same pixel of the detector are possible. - - Multiplicity must not be confused with how many atoms of the same element - a molecular ion contains (which is instead encoded with the - isotope_vector field of each :ref:`NXion` instance). - dimensions: - rank: 1 - dim: [[1, p]] - - # the following two quantities are relicts from ePOS files used to give some - # insight into the results of the hit_finding algorithm of IVAS/APSuite but typically - # used only in the context to learn about the multiplicity of an ion. - # pulses_since_last_ion(NX_UINT): - # dim: (n,) - # pulse_identifier(NX_INT): - # dim: (n,) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 12d784b1916396622fe879f2eea50e3a80b46536f09d2c1d7580cc6c096ef964 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of delay-line wires of the detector. -# -# -# -# -# Number of hit qualities (hit types) distinguished. -# -# -# -# -# Number of pulses collected in between start_time and end_time -# resolved by an instance of :ref:`NXevent_data_apm`. If this is not defined, -# p is the number of ions included in the reconstructed volume if an application -# definition is used to store results of already reconstructed datasets. -# -# -# -# -# Base class for the configuration and results from a hit finding algorithm. -# -# -# -# -# -# -# The number of wires in the detector. -# -# -# -# -# -# -# -# -# -# Alias tuple (begin, end) of each DLD wire of the detector. -# Order follows arrival_time_pairs. -# -# -# -# -# -# -# -# -# Raw readings from the analog-to-digital-converter -# timing circuits of the detector wires. -# -# -# -# -# -# -# -# -# -# -# Evaluated ion impact coordinates on the detector. -# Use the depends_on field to spec -# -# -# -# -# -# -# -# Defines in which reference frame the positions are defined. -# -# -# -# -# -# Name of the hit_qualities distinguished. -# AMETEK/Cameca uses e.g. golden, multiple, partial, -# irrecoverable, and multi-first and multi-late. -# -# -# -# -# -# -# -# Identifier used for each hit_quality type. -# Following the order of hit_quality_types. -# -# -# -# -# Hit quality identifier for each pulse. -# Identifier have to be within hit_quality_identifier. -# -# -# -# -# -# -# -# This processing yields for each ion with how many others it evaporated -# if these were collected on the same pulse. Extraction of multiple ions -# on one pulse on different or even the same pixel of the detector are possible. -# -# Multiplicity must not be confused with how many atoms of the same element -# a molecular ion contains (which is instead encoded with the -# isotope_vector field of each :ref:`NXion` instance). -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_msr.yaml b/contributed_definitions/nyaml/NXapm_msr.yaml deleted file mode 100644 index 7a84f4acc4..0000000000 --- a/contributed_definitions/nyaml/NXapm_msr.yaml +++ /dev/null @@ -1,311 +0,0 @@ -category: base -doc: | - Base class for collecting a session with a real atom probe or field-ion microscope. - - Ideally, we would like to describe the workflow of experiments and simulations of atom probe and - field-evaporation simulation research in more detail and contextualize better descriptions of - experiments and computer simulations for atom probe research. - - The main motivation for this is the ongoing development and tighter becoming connection between atom probe - and other material characterization techniques foremost electron microscopy (see `T. Kelly et al. `_, `C. Fleischmann et al. `_, and `W. Windl et al. `_ or `C. Freysoldt et al. `_ to mention but a few). - To arrive at a design of base classes and an application definition which can be used for both real and simulated atom probe experiments, it is worthwhile to recall concepts that are related to events and (molecular) ions: - - * Pulsing events which are used to trigger ion extraction events. - * Physical events and corresponding signal triggered by an ion hitting the detector. - Some of these events are not necessarily caused by or directly correlated with an identifiable pulsing event. - * Processed ion hits which are the result of an algorithm that took the physical and pulsing events as input - and qualified some of these events as to be of sufficiently high quality to call them (molecular) ions that are - wortwhile to be considered further and eventually included in the reconstructed volume. - * Calibration and signal filtering steps applied to these processed ion hits as input which results in actually - selected (molecular) ions based on which an instance of a reconstruction is created. - * Correlation of these ions with a statistics and theoretical model of mass-to-charge-state ratio values - and charge states of the (molecular) ions to substantiate that some of these ions are can be considered - as rangable ions and hence an iontype can be associated by running peak finding algorithms and labeling - i.e. algorithms for defining ranging definitions. - - Not only in AMETEK/Cameca's IVAS/APSuite software, which the majority of atom probers use, these concepts - are well distinguished. However, the algorithms used to transform correlations between pulses and physical events - into actual events (detector hits) ions is a proprietary one. Due to this practical inaccessibility of details, - virtually all atom probe studies currently use a reporting scheme where the course of the specimen evaporation - is documented such that quantities are a function of evaporation identifier i.e. actual event/ion, i.e. after having - the hits finding algorithm and correlations applied. That is evaporation_identifier values take the role of an implicit - time and course of the experiment given that ion extraction is a sequential physical process. - - There is a number of research groups who build own instruments and share different aspects of their technical - specifications and approaches how they apply data processing (e.g. `M. Monajem et al. `_, `P. Stender et al. `_ , or `I. Dimkou et al. `_ to name but a few). - Despite some of these activities embrace practices of open-source development, they use essentially the same - workflow that has been proposed by AMETEK/Cameca and its forerunner company Imago: A graphical user interface - software is used to explore and thus analyze reconstructed atom probe datasets. - - Specifically, software is used to correlate and interpret pulsing and physical events into processed ion hits. - Some of these ion hits are reported as (molecular) ions with ranged iontypes to yield a dataset based on which - scientific conclusions about the characterized material volume are made. - - By contrast, simulations of field-evaporation have the luxury to document the flight path and allow following the - whereabouts of each ion evaporated if needed. This level of detail is currently not characterizable in experiment. - Thus, there is a divide between schemas describing simulations of atom probe vs measurements of atom probe. - We argue that this divide can be bridged with realizing the above-mentioned context and the realization that - similar concepts are used in both research realms with many concepts not only being similar but exactly the same. - - A further argument to support this view is that computer simulations of atom probe usually are compared to reconstructed - datasets, either to the input configuration that served as the virtual specimen or to a real world atom probe experiment - and its reconstructions. In both cases, the recorded simulated physical events of simulated ions hitting a simulated detector - is not the end of the research workflow but typically the input to apply addition algorithms such as (spatial) filtering - and reconstruction algorithms. Only the practical need for making ranging definitions is (at least as of now) not as much needed - in field-evaporation simulations than it is in real world measurements because each ion has a prescribed iontype in the simulation. - Be it a specifically charged nuclid or a molecular ion whose flight path the simulation resolves. - Although, in principle simpler though, we have to consider that this is caused by many assumptions made in the simulations. - Indeed, the multi-scale (time and space) aspects of the challenge that is the simulating of field-evaporation are simplified - because of otherwise too high computing resource demands and knowledge gaps in how to deal with some complexities. - Molecular ion dissociation upon flight is one such complexity. Also the complexity of simulation setups is simpler e.g. the assumption of a straight flight path - instrument is used or details are ignored such as local electrodes or physical obstacles and electric fields (controlled or stray fields). - - To conclude, we thus propose two base classes :ref:`NXapm_msr` and :ref:`NXapm_sim` where the second one may become - obsolete in the future as people realize that a simulated atom probe is maybe equivalent in design and function to a - real atom probe if considering that the simulation is just stripped of many components. - -# noteworthy the situation is similar to electron microscopy especially transmission electron microscopy where factually -# interpretation without simulations is pointless. The only difference is that in electron microscopy there is a large availability -# of documentation and open-source tools for performing such simulations. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - p: | - Number of pulses collected in between start_time and end_time - resolved by an instance of :ref:`NXevent_data_apm`. -type: group -NXapm_msr(NXobject): - instrument(NXinstrument): - doc: | - Metadata of the atom probe or field-ion microscope instrument, henceforth called - microscope or instrument, and the lab in which it stands. - # (NXcsg): - # doc: | - # Possibility to include a detailed computational geometry description of the instrument. - instrument_name(NX_CHAR): - doc: | - Given name of the microscope as defined by the hosting lab. This is an alias. - Examples could be LEAP6000, Raptor, Oxcart, one atom at a time, etc. - location(NX_CHAR): - doc: | - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - (NXfabrication): - (NXreflectron): - decelerate_electrode(NXlens_em): - doc: | - A counter electrode of the LEAP 6000 series atom probes. - - # counter_electrodes being optional WO2016171675A1 - # see https://en.wikipedia.org/wiki/Einzel_lens for details double einzel lens in the invizo 6000 - # according to A. Breen (UNSW) - local_electrode(NXlens_em): - doc: | - A local electrode guiding the ion flight path. - Also called counter or extraction electrode. - - # 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. - - # model, serial_number, manufacturer_name all inherited from NXdetector base class - pulser(NXpulser_apm): - stage_lab(NXstage_lab): - - # NEW ISSUE: add NXapm_energy_analyzer, a voltage grid like done in Rouen/GPM - analysis_chamber(NXchamber): - buffer_chamber(NXchamber): - load_lock_chamber(NXchamber): - getter_pump(NXpump): - roughening_pump(NXpump): - turbomolecular_pump(NXpump): - status(NX_CHAR): - doc: | - A statement whether the measurement was successful or failed prematurely. - enumeration: [success, failure, unknown] - (NXevent_data_apm_set): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 9361a1a1be4739ad40d833374588a16335784ec414a2f5878eaf47ba8eb8817e -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of pulses collected in between start_time and end_time -# resolved by an instance of :ref:`NXevent_data_apm`. -# -# -# -# -# Base class for collecting a session with a real atom probe or field-ion microscope. -# -# Ideally, we would like to describe the workflow of experiments and simulations of atom probe and -# field-evaporation simulation research in more detail and contextualize better descriptions of -# experiments and computer simulations for atom probe research. -# -# The main motivation for this is the ongoing development and tighter becoming connection between atom probe -# and other material characterization techniques foremost electron microscopy (see `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_, `C. Fleischmann et al. <https://doi.org/10.1016/j.ultramic.2018.08.010>`_, and `W. Windl et al. <https://doi.org/10.1093/micmic/ozad067.294>`_ or `C. Freysoldt et al. <https://doi.org/10.1103/PhysRevLett.124.176801>`_ to mention but a few). -# To arrive at a design of base classes and an application definition which can be used for both real and simulated atom probe experiments, it is worthwhile to recall concepts that are related to events and (molecular) ions: -# -# * Pulsing events which are used to trigger ion extraction events. -# * Physical events and corresponding signal triggered by an ion hitting the detector. -# Some of these events are not necessarily caused by or directly correlated with an identifiable pulsing event. -# * Processed ion hits which are the result of an algorithm that took the physical and pulsing events as input -# and qualified some of these events as to be of sufficiently high quality to call them (molecular) ions that are -# wortwhile to be considered further and eventually included in the reconstructed volume. -# * Calibration and signal filtering steps applied to these processed ion hits as input which results in actually -# selected (molecular) ions based on which an instance of a reconstruction is created. -# * Correlation of these ions with a statistics and theoretical model of mass-to-charge-state ratio values -# and charge states of the (molecular) ions to substantiate that some of these ions are can be considered -# as rangable ions and hence an iontype can be associated by running peak finding algorithms and labeling -# i.e. algorithms for defining ranging definitions. -# -# Not only in AMETEK/Cameca's IVAS/APSuite software, which the majority of atom probers use, these concepts -# are well distinguished. However, the algorithms used to transform correlations between pulses and physical events -# into actual events (detector hits) ions is a proprietary one. Due to this practical inaccessibility of details, -# virtually all atom probe studies currently use a reporting scheme where the course of the specimen evaporation -# is documented such that quantities are a function of evaporation identifier i.e. actual event/ion, i.e. after having -# the hits finding algorithm and correlations applied. That is evaporation_identifier values take the role of an implicit -# time and course of the experiment given that ion extraction is a sequential physical process. -# -# There is a number of research groups who build own instruments and share different aspects of their technical -# specifications and approaches how they apply data processing (e.g. `M. Monajem et al. <https://doi.org/10.1017/S1431927622003397>`_, `P. Stender et al. <https://doi.org/10.1017/S1431927621013982>`_ , or `I. Dimkou et al. <https://doi.org/10.1093/micmic/ozac051>`_ to name but a few). -# Despite some of these activities embrace practices of open-source development, they use essentially the same -# workflow that has been proposed by AMETEK/Cameca and its forerunner company Imago: A graphical user interface -# software is used to explore and thus analyze reconstructed atom probe datasets. -# -# Specifically, software is used to correlate and interpret pulsing and physical events into processed ion hits. -# Some of these ion hits are reported as (molecular) ions with ranged iontypes to yield a dataset based on which -# scientific conclusions about the characterized material volume are made. -# -# By contrast, simulations of field-evaporation have the luxury to document the flight path and allow following the -# whereabouts of each ion evaporated if needed. This level of detail is currently not characterizable in experiment. -# Thus, there is a divide between schemas describing simulations of atom probe vs measurements of atom probe. -# We argue that this divide can be bridged with realizing the above-mentioned context and the realization that -# similar concepts are used in both research realms with many concepts not only being similar but exactly the same. -# -# A further argument to support this view is that computer simulations of atom probe usually are compared to reconstructed -# datasets, either to the input configuration that served as the virtual specimen or to a real world atom probe experiment -# and its reconstructions. In both cases, the recorded simulated physical events of simulated ions hitting a simulated detector -# is not the end of the research workflow but typically the input to apply addition algorithms such as (spatial) filtering -# and reconstruction algorithms. Only the practical need for making ranging definitions is (at least as of now) not as much needed -# in field-evaporation simulations than it is in real world measurements because each ion has a prescribed iontype in the simulation. -# Be it a specifically charged nuclid or a molecular ion whose flight path the simulation resolves. -# Although, in principle simpler though, we have to consider that this is caused by many assumptions made in the simulations. -# Indeed, the multi-scale (time and space) aspects of the challenge that is the simulating of field-evaporation are simplified -# because of otherwise too high computing resource demands and knowledge gaps in how to deal with some complexities. -# Molecular ion dissociation upon flight is one such complexity. Also the complexity of simulation setups is simpler e.g. the assumption of a straight flight path -# instrument is used or details are ignored such as local electrodes or physical obstacles and electric fields (controlled or stray fields). -# -# To conclude, we thus propose two base classes :ref:`NXapm_msr` and :ref:`NXapm_sim` where the second one may become -# obsolete in the future as people realize that a simulated atom probe is maybe equivalent in design and function to a -# real atom probe if considering that the simulation is just stripped of many components. -# -# -# -# Metadata of the atom probe or field-ion microscope instrument, henceforth called -# microscope or instrument, and the lab in which it stands. -# -# -# -# Possibility to include a detailed computational geometry description of the -# instrument. -# -# -# -# -# Given name of the microscope as defined by the hosting lab. This is an alias. -# Examples could be LEAP6000, Raptor, Oxcart, one atom at a time, etc. -# -# -# -# -# Location of the lab or place where the instrument is installed. -# Using GEOREF is preferred. -# -# -# -# -# -# -# A counter electrode of the LEAP 6000 series atom probes. -# -# -# -# -# -# A local electrode guiding the ion flight path. -# Also called counter or extraction electrode. -# -# -# -# -# -# Detector for taking raw time-of-flight and ion/hit impact positions data. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# A statement whether the measurement was successful or failed prematurely. -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_ranging.yaml b/contributed_definitions/nyaml/NXapm_ranging.yaml deleted file mode 100644 index 7d6a4f03cc..0000000000 --- a/contributed_definitions/nyaml/NXapm_ranging.yaml +++ /dev/null @@ -1,188 +0,0 @@ -category: base -doc: | - Base class for the configuration and results of ranging definitions. - - Ranging is a data post-processing step used in the research field of - atom probe during which elemental, isotopic, and/or molecular identities - are assigned to mass-to-charge-state-ratios within a certain interval. - The documentation of these steps is based on ideas that - have been described in the literature: - - * `M. K. Miller `_ - * `D. Haley et al. `_ - * `M. Kühbach et al. `_ -type: group -NXapm_ranging(NXprocess): - (NXprogram): - (NXserialized): - number_of_ion_types(NX_UINT): - unit: NX_UNITLESS - doc: | - How many ion types are distinguished. If no ranging was performed, each - ion is of the special unknown type. The iontype ID of this unknown type - is 0 representing a reserve value. Consequently, - iontypes start counting from 1. - maximum_number_of_atoms_per_molecular_ion(NX_UINT): - unit: NX_UNITLESS - doc: | - Assumed maximum value that suffices to store all relevant - molecular ions, even the most complicated ones. - Currently, a value of 32 is used (see M. Kühbach et al. `_). - mass_to_charge_distribution(NXprocess): - doc: | - Specifies the mass-to-charge-state-ratio histogram. - (NXprogram): - min_incr_max(NX_FLOAT): - unit: NX_ANY - doc: | - Smallest, increment, and largest mass-to-charge-state ratio value. - dimensions: - rank: 1 - dim: [[1, 3]] - mass_spectrum(NXdata): - doc: | - A default histogram aka mass spectrum of - the mass-to-charge-state ratio values. - background_quantification(NXprocess): - doc: | - Details of the background model that was used to - correct the total counts per bin into counts. - (NXprogram): - description(NX_CHAR): - doc: | - To begin with we use a free-text field to learn how - atom probers define a background model. Future versions - of NXapm_ranging can then use this information to parameterize - these models. - - # NEW ISSUE: add parameters of the background model in an e.g. - # NXcollection as these are specific to every background model - # NEW ISSUE: touching upon i.e. research activities by Andrew London et al. - # substantiating the need for a clearer description how peak/signals were - # eventually processed via deconvolution methods - peak_search_and_deconvolution(NXprocess): - doc: | - How where peaks in the background-corrected in the histogram - of mass-to-charge-state ratio values identified? - (NXprogram): - (NXpeak): - peak_identification(NXprocess): - doc: | - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - (NXprogram): - (NXion): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 03d0005c9cd241cb1b84669fc98d723d8342681e660718da5c0be61733f59d18 -# -# -# -# -# -# Base class for the configuration and results of ranging definitions. -# -# Ranging is a data post-processing step used in the research field of -# atom probe during which elemental, isotopic, and/or molecular identities -# are assigned to mass-to-charge-state-ratios within a certain interval. -# The documentation of these steps is based on ideas that -# have been described in the literature: -# -# * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ -# * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ -# * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ -# -# -# -# -# -# How many ion types are distinguished. If no ranging was performed, each -# ion is of the special unknown type. The iontype ID of this unknown type -# is 0 representing a reserve value. Consequently, -# iontypes start counting from 1. -# -# -# -# -# Assumed maximum value that suffices to store all relevant -# molecular ions, even the most complicated ones. -# Currently, a value of 32 is used (see M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_). -# -# -# -# -# Specifies the mass-to-charge-state-ratio histogram. -# -# -# -# -# Smallest, increment, and largest mass-to-charge-state ratio value. -# -# -# -# -# -# -# -# A default histogram aka mass spectrum of -# the mass-to-charge-state ratio values. -# -# -# -# -# -# Details of the background model that was used to -# correct the total counts per bin into counts. -# -# -# -# -# To begin with we use a free-text field to learn how -# atom probers define a background model. Future versions -# of NXapm_ranging can then use this information to parameterize -# these models. -# -# -# -# -# -# -# How where peaks in the background-corrected in the histogram -# of mass-to-charge-state ratio values identified? -# -# -# -# -# -# -# Details about how peaks, with taking into account -# error models, were interpreted as ion types or not. -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_reconstruction.yaml b/contributed_definitions/nyaml/NXapm_reconstruction.yaml deleted file mode 100644 index 7b9d5a9542..0000000000 --- a/contributed_definitions/nyaml/NXapm_reconstruction.yaml +++ /dev/null @@ -1,205 +0,0 @@ -category: base -doc: | - Base class for the configuration and results of a (static) reconstruction algorithm. - - Generating a tomographic reconstruction of the specimen uses selected and - calibrated ion hit positions, the evaporation sequence, and voltage curve data. - Very often scientists use own software scripts according to published procedures, - so-called reconstruction protocols. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n: | - Number of ions spatially filtered from results of the hit_finding algorithm - :ref:`NXapm_hit_finding` from which an instance of a reconstructed volume - has been generated. These ions get new identifier assigned in the process - - the so-called evaporation_identifier, which must not be confused with - the pulse_identifier! -type: group -NXapm_reconstruction(NXprocess): - - # when evolving these ideas further inherit from NXapm_method instead - (NXprogram): - (NXserialized): - - # config/input - parameter(NX_CHAR): - doc: | - Different reconstruction protocols exist. Although these approaches - are qualitatively similar, each protocol uses different parameters - (and interprets these differently). The source code to IVAS/APSuite - is not open. For now users should store reconstruction parameter - in this free-text field to guide how to parameterize this better in the - future. For LEAP systems and reconstructions performed with IVAS/APSuite - see `T. Blum et al. `_ (page 371). - protocol_name(NX_CHAR): - doc: | - Qualitative statement about which reconstruction protocol was used. - enumeration: [bas, geiser, gault, cameca, other] - crystallographic_calibration(NX_CHAR): - doc: | - Different strategies for crystallographic calibration of the - reconstruction are possible. Therefore, we collect first such - feedback before parameterizing this further. - - If no crystallographic calibration was performed, the field - should be filled with the n/a, meaning not applied. - - # results - field_of_view(NX_FLOAT): - unit: NX_LENGTH - - # typically in nm reconstruction space not detector coordinates - doc: | - The nominal diameter of the specimen ROI which is measured in the - experiment. The physical specimen cannot be measured completely - because ions may launch but hit in locations other than the detector. - reconstructed_positions(NX_FLOAT): - unit: NX_LENGTH - doc: | - Three-dimensional reconstructed positions of the ions. - dimensions: - rank: 2 - dim: [[1, n], [2, 3]] - \@depends_on: - type: NX_CHAR - doc: | - The instance of :ref:`NXcoordinate_system` - in which the positions are defined. - naive_discretization(NXprocess): - (NXprogram): - - # config/input - # results - (NXdata): - doc: | - To get a first visual overview of the reconstructed dataset, - here a 3d histogram of the ion is stored. Ion counts are characterized - using one nanometer cubic bins without applying position smoothening - algorithms during the histogram computation. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2b9ccfe6bd216a1724e272108c536d01562d827dcc129981755fb36cc98e65d0 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of ions spatially filtered from results of the hit_finding algorithm -# :ref:`NXapm_hit_finding` from which an instance of a reconstructed volume -# has been generated. These ions get new identifier assigned in the process - -# the so-called evaporation_identifier, which must not be confused with -# the pulse_identifier! -# -# -# -# -# Base class for the configuration and results of a (static) reconstruction algorithm. -# -# Generating a tomographic reconstruction of the specimen uses selected and -# calibrated ion hit positions, the evaporation sequence, and voltage curve data. -# Very often scientists use own software scripts according to published procedures, -# so-called reconstruction protocols. -# -# -# -# -# -# -# -# Different reconstruction protocols exist. Although these approaches -# are qualitatively similar, each protocol uses different parameters -# (and interprets these differently). The source code to IVAS/APSuite -# is not open. For now users should store reconstruction parameter -# in this free-text field to guide how to parameterize this better in the -# future. For LEAP systems and reconstructions performed with IVAS/APSuite -# see `T. Blum et al. <https://doi.org/10.1002/9781119227250.ch18>`_ (page 371). -# -# -# -# -# Qualitative statement about which reconstruction protocol was used. -# -# -# -# -# -# -# -# -# -# -# -# Different strategies for crystallographic calibration of the -# reconstruction are possible. Therefore, we collect first such -# feedback before parameterizing this further. -# -# If no crystallographic calibration was performed, the field -# should be filled with the n/a, meaning not applied. -# -# -# -# -# -# -# The nominal diameter of the specimen ROI which is measured in the -# experiment. The physical specimen cannot be measured completely -# because ions may launch but hit in locations other than the detector. -# -# -# -# -# Three-dimensional reconstructed positions of the ions. -# -# -# -# -# -# -# -# The instance of :ref:`NXcoordinate_system` -# in which the positions are defined. -# -# -# -# -# -# -# -# -# To get a first visual overview of the reconstructed dataset, -# here a 3d histogram of the ion is stored. Ion counts are characterized -# using one nanometer cubic bins without applying position smoothening -# algorithms during the histogram computation. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_sim.yaml b/contributed_definitions/nyaml/NXapm_sim.yaml deleted file mode 100644 index 79c489f2f3..0000000000 --- a/contributed_definitions/nyaml/NXapm_sim.yaml +++ /dev/null @@ -1,50 +0,0 @@ -category: base -doc: | - Base class for simulating ion extraction from matter via laser and/or voltage pulsing. -# mirroring the design of NXem_msr/NXem_sim, NXem can be used for experiment and simulation -type: group -NXapm_sim(NXobject): - (NXprogram): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f09cde6d7b39bd99afbf369ca236f3bcc81c1e41b12720bae3ecd2eefd4c026c -# -# -# -# -# -# -# Base class for simulating ion extraction from matter via laser and/or voltage pulsing. -# -# Ideally, we would like to describe the workflow of experiments and simulations of -# atom probe and field-evaporation simulation research in more detail and contextualize -# better descriptions of experiments and computer simulations. -# The strategy to achieve this is detailed in the introducing docstring of -# :ref:`NXapm_msr`. This :ref:`NXapm_sim` base class is envisioned as the -# twin of the :ref:`NXapm_msr` base class. -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_volt_and_bowl.yaml b/contributed_definitions/nyaml/NXapm_volt_and_bowl.yaml deleted file mode 100644 index 9700d40639..0000000000 --- a/contributed_definitions/nyaml/NXapm_volt_and_bowl.yaml +++ /dev/null @@ -1,112 +0,0 @@ -category: base -doc: | - Base class for the configuration and results from a voltage-and-bowl ToF correction algorithm. - - The voltage-and-bowl correction is a ata post-processing step to correct for ion impact position - flight path differences, detector biases, and nonlinearities. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n: | - Number of ions spatially filtered from results of the hit_finding algorithm - :ref:`NXapm_hit_finding` from which an instance of a reconstructed volume - has been generated. These ions get new identifier assigned in the process - - the so-called evaporation_identifier, which must not be confused with - the pulse_identifier! -type: group -NXapm_volt_and_bowl(NXprocess): - (NXprogram): - (NXserialized): - - # config/input to the algorithm - # 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 - # result - raw_tof(NX_FLOAT): - unit: NX_TIME - doc: | - Raw time-of-flight data without corrections. - dimensions: - rank: 1 - dim: [[1, n]] - calibrated_tof(NX_FLOAT): - unit: NX_TIME - doc: | - Calibrated time-of-flight. - dimensions: - rank: 1 - dim: [[1, n]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e5f86e813b55935bdb6edcb66614c78722f494931dfdd588ac7c86edbb7ab3f7 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of ions spatially filtered from results of the hit_finding algorithm -# :ref:`NXapm_hit_finding` from which an instance of a reconstructed volume -# has been generated. These ions get new identifier assigned in the process - -# the so-called evaporation_identifier, which must not be confused with -# the pulse_identifier! -# -# -# -# -# Base class for the configuration and results from a voltage-and-bowl ToF correction algorithm. -# -# The voltage-and-bowl correction is a ata post-processing step to correct for ion impact position -# flight path differences, detector biases, and nonlinearities. -# -# -# -# -# -# -# Raw time-of-flight data without corrections. -# -# -# -# -# -# -# -# Calibrated time-of-flight. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXbeam_device.yaml b/contributed_definitions/nyaml/NXbeam_device.yaml deleted file mode 100644 index 0d8754c60f..0000000000 --- a/contributed_definitions/nyaml/NXbeam_device.yaml +++ /dev/null @@ -1,106 +0,0 @@ -category: base -doc: | - Properties of generic beam device in an experimental setup. - - Any beam related devices like source, detector, filter, mirror, - beamsplitter, ... which may modifies a beam in an experimental setup - can be described here with its experimental position and relationship - to the other beam devices in the setup. -type: group -NXbeam_device(NXobject): - previous_devices: - doc: | - Single device or list of devices pointing to the devices from which an - beam originated to reach this device. - This is used to describe a logical order of devices and for the whole setup. - In this way, a "beam path" can be described (i.e., with starting point (light source) - and end point (photo detector)). - - Example: /entry/instrument/detector. - purpose(NX_CHAR): - doc: | - Description of the intended purpose of this device for - the experimental setup. - group(NX_CHAR): - doc: | - Name of the group with which this device can be associated. - For example, if a group of devices is used for second harmonic generation, - all these devices have the group name "second harmonic generation". - Is used for simplified setup vizualization (or description?). - (NXtransformations): - doc: | - Location and orientation of the device. Note that even a - simple distance can be given as a translation. - - You can use the @depends_on to describe from which device - the transformation needs to be applied. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 55ae98919e366f5b67cdeef618353257b5946ff077f8264a0bdd476cf84aef2d -# -# -# -# -# -# Properties of generic beam device in an experimental setup. -# -# Any beam related devices like source, detector, filter, mirror, -# beamsplitter, ... which may modifies a beam in an experimental setup -# can be described here with its experimental position and relationship -# to the other beam devices in the setup. -# -# -# -# Single device or list of devices pointing to the devices from which an -# beam originated to reach this device. -# This is used to describe a logical order of devices and for the whole setup. -# In this way, a "beam path" can be described (i.e., with starting point (light source) -# and end point (photo detector)). -# -# Example: /entry/instrument/detector. -# -# -# -# -# Description of the intended purpose of this device for -# the experimental setup. -# -# -# -# -# Name of the group with which this device can be associated. -# For example, if a group of devices is used for second harmonic generation, -# all these devices have the group name "second harmonic generation". -# Is used for simplified setup vizualization (or description?). -# -# -# -# -# Location and orientation of the device. Note that even a -# simple distance can be given as a translation. -# -# You can use the @depends_on to describe from which device -# the transformation needs to be applied. -# -# -# diff --git a/contributed_definitions/nyaml/NXbeam_transfer_matrix_table.yaml b/contributed_definitions/nyaml/NXbeam_transfer_matrix_table.yaml deleted file mode 100644 index f8e025367e..0000000000 --- a/contributed_definitions/nyaml/NXbeam_transfer_matrix_table.yaml +++ /dev/null @@ -1,198 +0,0 @@ -category: base -doc: | - Contains datastructures of an experimental optical setup (i.e., multiple - transfermatrix tables). These datastructures are used to relate physical - properties of two beams (NXbeam) which have one common optical element - (NXopt_element) (one specific transfermatrix). - One of these beams in an input beam and the other one is an output beam. - - The data describes the change of beam properties, e.g. the intensity of a - beam is reduced because the transmission coefficient of the beam device is - lower than 1. -symbols: - doc: | - Variables used throughout the document, e.g. dimensions or parameters. - N_variables: | - Length of the array associated to the data type. -type: group -NXbeam_transfer_matrix_table(NXobject): - datatype_N: - doc: | - Select which type of data was recorded, for example aperture and - focal length. - It is possible to have multiple selections. This selection defines - how many columns (N_variables) are stored in the data array. - N in the name, is the index number in which order the given - property is listed. - enumeration: [aperture, focallength, orientation, jones matrix] - matrix_elements: - doc: | - Please list in this array the column and row names used in your actual data. - That is in the case of aperture ['diameter'] or focal length ['focal_length_value'] - and for orientation matrix ['OM1', 'OM2', 'OM3'] or for jones matrix - ['JM1','JM2'] - dimensions: - rank: 1 - dim: [[1, N_variables]] - TRANSFER_MATRIX(NX_NUMBER): - doc: | - Contains the datastructure which relates beam properties of an - input and output beam as result of the input beam interaction - with the beam device. - - Transfermatrix relationship between N input beams and M output beams. - It contains a table with the relevant matricis to be used for different - transmissitted properties (such as polarization, intensity, phase). - - Data structure for all transfermatrices of an beam device in a setup. - For each combination of N input and M output beams and for L physical - concept (i.e. beam intensity), one matrix can be defined. - - In this way, the transfermatrix table has the dimension NxM. - - For each entry, in this transfermatrix, there are L formalisms. - Each formalism has the dimension math:`dim(L_i)xdim(L_i)`, - whereby math:`L_i` is the specific physical concept (Intensity, polarization, direction). - - A beamsplitter with two input laser beams can have a total of - four transfermatrices (2 Input x 2 Output). - - The dimension of the transfermatrix depends on the parameters. - Examples are: - 1x1 for intensity/power - 2x2 for jones formalism - 3x3 for direction - dimensions: - rank: 2 - doc: | - Square matrix with dimension N_variables x N_variables - dim: [[1, N_variables], [2, N_variables]] - \@input: - doc: | - Specific name of input beam which the transfermatrix table is related to. - \@output: - doc: | - Specific name of output beam which the transfermatrix table is related to. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# fb6e6115fd2b7a0d8168bd635355b9ebf6ee101fedc0e61bd162e72d97e340ab -# -# -# -# -# -# -# Variables used throughout the document, e.g. dimensions or parameters. -# -# -# -# Length of the array associated to the data type. -# -# -# -# -# Contains datastructures of an experimental optical setup (i.e., multiple -# transfermatrix tables). These datastructures are used to relate physical -# properties of two beams (NXbeam) which have one common optical element -# (NXopt_element) (one specific transfermatrix). -# One of these beams in an input beam and the other one is an output beam. -# -# The data describes the change of beam properties, e.g. the intensity of a -# beam is reduced because the transmission coefficient of the beam device is -# lower than 1. -# -# -# -# Select which type of data was recorded, for example aperture and -# focal length. -# It is possible to have multiple selections. This selection defines -# how many columns (N_variables) are stored in the data array. -# N in the name, is the index number in which order the given -# property is listed. -# -# -# -# -# -# -# -# -# -# -# Please list in this array the column and row names used in your actual data. -# That is in the case of aperture ['diameter'] or focal length ['focal_length_value'] -# and for orientation matrix ['OM1', 'OM2', 'OM3'] or for jones matrix -# ['JM1','JM2'] -# -# -# -# -# -# -# -# Contains the datastructure which relates beam properties of an -# input and output beam as result of the input beam interaction -# with the beam device. -# -# Transfermatrix relationship between N input beams and M output beams. -# It contains a table with the relevant matricis to be used for different -# transmissitted properties (such as polarization, intensity, phase). -# -# Data structure for all transfermatrices of an beam device in a setup. -# For each combination of N input and M output beams and for L physical -# concept (i.e. beam intensity), one matrix can be defined. -# -# In this way, the transfermatrix table has the dimension NxM. -# -# For each entry, in this transfermatrix, there are L formalisms. -# Each formalism has the dimension math:`dim(L_i)xdim(L_i)`, -# whereby math:`L_i` is the specific physical concept (Intensity, polarization, direction). -# -# A beamsplitter with two input laser beams can have a total of -# four transfermatrices (2 Input x 2 Output). -# -# The dimension of the transfermatrix depends on the parameters. -# Examples are: -# 1x1 for intensity/power -# 2x2 for jones formalism -# 3x3 for direction -# -# -# -# Square matrix with dimension N_variables x N_variables -# -# -# -# -# -# -# Specific name of input beam which the transfermatrix table is related to. -# -# -# -# -# Specific name of output beam which the transfermatrix table is related to. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcalibration.yaml b/contributed_definitions/nyaml/NXcalibration.yaml deleted file mode 100644 index f5de70352f..0000000000 --- a/contributed_definitions/nyaml/NXcalibration.yaml +++ /dev/null @@ -1,372 +0,0 @@ -category: base -doc: | - Subclass of NXprocess to describe post-processing calibrations. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays - ncoeff: | - Number of coefficients of the calibration function - ncal: | - Number of points of the calibrated and uncalibrated axes -type: group -NXcalibration(NXobject): - description(NX_CHAR): - doc: | - A description of the procedures employed. - physical_quantity: - doc: | - The physical quantity of the calibration, e.g., - energy, momentum, time, etc. - calibration_method(NXidentifier): - doc: | - A digital persistent identifier (e.g., DOI, ISO standard) referring to a detailed description of a - calibration method but no actual calibration data. - calibration_reference(NXidentifier): - doc: | - A digital persistent identifier (e.g., a DOI) referring to a publicly available calibration measurement - used for this instrument, e.g., a measurement of a known standard containing calibration information. - The axis values may be copied or linked in the appropriate NXcalibration fields for reference. - calibration_object(NXserialized): - doc: | - A file serialisation of a calibration which may not be publicly available (externally from the nexus file). - - This metadata can be a documentation of the source (file) or database (entry) from which pieces - of information have been extracted for consumption (e.g. in a research data management system (RDMS)). - It is also possible to include the actual file by using the `file` field. - - The axis values may be copied or linked in the appropriate NXcalibration fields for reference. - last_process(NX_CHAR): - doc: | - Indicates the name of the last operation applied in the NXprocess sequence. - applied(NX_BOOLEAN): - doc: | - Has the calibration been applied? - calibration_software: - doc: | - Name of the software used for this calibration. - \@version: - doc: | - Software version. - original_axis(NX_FLOAT): - unit: NX_ANY - doc: | - Vector containing the data coordinates in the original uncalibrated axis - dimensions: - rank: 1 - dim: [[1, ncal]] - \@symbol: - doc: | - The symbol of the axis to be used in the fit_function, e.g., `energy`, `E`. - This should comply to the following naming rules (similar to python's naming rules): - - * A variable name must start with a letter or the underscore character - * A variable name cannot start with a number - * A variable name can only contain alpha-numeric characters and underscores (A-z, 0-9, and _ ) - * Variable names are case-sensitive (age, Age and AGE are three different variables) - \@input_path: - doc: | - The path from which this data is derived, e.g., raw detector axis. - Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. - input_SYMBOL(NX_FLOAT): - unit: NX_ANY - doc: | - Additional input axis to be used in the formula. - The part after `input_` is used as the symbol to be used in the `fit_function`, i.e., - if the field name is `input_my_field` you should refer to this axis by `my_field` in the `fit_function`. - dimensions: - rank: 1 - dim: [[1, ncal]] - \@input_path: - doc: | - The path from which this data is derived, e.g., raw detector axis. - Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. - coefficients(NX_FLOAT): - unit: NX_ANY - doc: | - For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit - to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the array of fit coefficients. - dimensions: - rank: 1 - dim: [[1, ncoeff]] - fit_function(NX_CHAR): - doc: | - For non-linear energy calibrations. Here we can store the formula of the - fit function. - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - - Use x0, x1, ..., xn for the nth position in the `original_axis` field. - If there is the symbol attribute specified for the `original_axis` this may be used instead of x. - If you want to use the whole axis use `x`. - Alternate axis can also be available as specified by the `input_SYMBOL` field. - The data should then be referred here by the `SYMBOL` name, e.g., for a field - name `input_my_field` it should be referred here by `my_field` or `my_field0` if - you want to read the zeroth element of the array. - - The formula should be numpy compliant. - scaling(NX_FLOAT): - unit: NX_ANY - doc: | - For linear calibration. Scaling parameter. - This should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. - offset(NX_FLOAT): - unit: NX_ANY - doc: | - For linear calibration. Offset parameter. - This should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. - mapping_MAPPING(NX_FLOAT): - doc: | - Mapping data for calibration. - - This can be used to map data points from uncalibrated to calibrated values, - i.e., by multiplying each point in the input axis by the corresponding point in the mapping data. - calibrated_axis(NX_FLOAT): - unit: NX_ANY - doc: | - A vector representing the axis after calibration, matching the data length - dimensions: - rank: 1 - dim: [[1, ncal]] - \@output_path: - doc: | - The path to which this data is written, e.g., the calibrated energy. - Should be a valid NeXus path name, e.g., /entry/data/energy. - (NXdata): - doc: | - Any data acquired/used during the calibration that does not fit the `NX_FLOAT` fields above. - NXdata groups can be used for multidimensional data which are relevant to the calibration - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 5b3f68876a95d97b868d1689748fea53aa780cddc8c874615e21821ae60d4ccc -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays -# -# -# -# Number of coefficients of the calibration function -# -# -# -# -# Number of points of the calibrated and uncalibrated axes -# -# -# -# -# Subclass of NXprocess to describe post-processing calibrations. -# -# -# -# A description of the procedures employed. -# -# -# -# -# The physical quantity of the calibration, e.g., -# energy, momentum, time, etc. -# -# -# -# -# A digital persistent identifier (e.g., DOI, ISO standard) referring to a detailed description of a -# calibration method but no actual calibration data. -# -# -# -# -# A digital persistent identifier (e.g., a DOI) referring to a publicly available calibration measurement -# used for this instrument, e.g., a measurement of a known standard containing calibration information. -# The axis values may be copied or linked in the appropriate NXcalibration fields for reference. -# -# -# -# -# A file serialisation of a calibration which may not be publicly available (externally from the nexus file). -# -# This metadata can be a documentation of the source (file) or database (entry) from which pieces -# of information have been extracted for consumption (e.g. in a research data management system (RDMS)). -# It is also possible to include the actual file by using the `file` field. -# -# The axis values may be copied or linked in the appropriate NXcalibration fields for reference. -# -# -# -# -# Indicates the name of the last operation applied in the NXprocess sequence. -# -# -# -# -# Has the calibration been applied? -# -# -# -# -# Name of the software used for this calibration. -# -# -# -# Software version. -# -# -# -# -# -# Vector containing the data coordinates in the original uncalibrated axis -# -# -# -# -# -# -# The symbol of the axis to be used in the fit_function, e.g., `energy`, `E`. -# This should comply to the following naming rules (similar to python's naming rules): -# -# * A variable name must start with a letter or the underscore character -# * A variable name cannot start with a number -# * A variable name can only contain alpha-numeric characters and underscores (A-z, 0-9, and _ ) -# * Variable names are case-sensitive (age, Age and AGE are three different variables) -# -# -# -# -# The path from which this data is derived, e.g., raw detector axis. -# Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. -# -# -# -# -# -# Additional input axis to be used in the formula. -# The part after `input_` is used as the symbol to be used in the `fit_function`, i.e., -# if the field name is `input_my_field` you should refer to this axis by `my_field` in the `fit_function`. -# -# -# -# -# -# -# The path from which this data is derived, e.g., raw detector axis. -# Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. -# -# -# -# -# -# For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit -# to a set of features (peaks) at well defined energy positions to determine -# E(TOF). Here we can store the array of fit coefficients. -# -# -# -# -# -# -# -# For non-linear energy calibrations. Here we can store the formula of the -# fit function. -# -# Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. -# -# Use x0, x1, ..., xn for the nth position in the `original_axis` field. -# If there is the symbol attribute specified for the `original_axis` this may be used instead of x. -# If you want to use the whole axis use `x`. -# Alternate axis can also be available as specified by the `input_SYMBOL` field. -# The data should then be referred here by the `SYMBOL` name, e.g., for a field -# name `input_my_field` it should be referred here by `my_field` or `my_field0` if -# you want to read the zeroth element of the array. -# -# The formula should be numpy compliant. -# -# -# -# -# For linear calibration. Scaling parameter. -# This should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. -# -# -# -# -# For linear calibration. Offset parameter. -# This should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. -# -# -# -# -# Mapping data for calibration. -# -# This can be used to map data points from uncalibrated to calibrated values, -# i.e., by multiplying each point in the input axis by the corresponding point in the mapping data. -# -# -# -# -# A vector representing the axis after calibration, matching the data length -# -# -# -# -# -# -# The path to which this data is written, e.g., the calibrated energy. -# Should be a valid NeXus path name, e.g., /entry/data/energy. -# -# -# -# -# -# Any data acquired/used during the calibration that does not fit the `NX_FLOAT` fields above. -# NXdata groups can be used for multidimensional data which are relevant to the calibration -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_alpha_complex.yaml b/contributed_definitions/nyaml/NXcg_alpha_complex.yaml deleted file mode 100644 index 0e0b3deb2e..0000000000 --- a/contributed_definitions/nyaml/NXcg_alpha_complex.yaml +++ /dev/null @@ -1,211 +0,0 @@ -category: base -doc: | - Computational geometry of alpha shapes or alpha wrappings about primitives. - - For details see: - - * https://dx.doi.org/10.1109/TIT.1983.1056714 for 2D, - * https://dx.doi.org/10.1145/174462.156635 for 3D, - * https://dl.acm.org/doi/10.5555/871114 for weighted, and - * https://doc.cgal.org/latest/Alpha_shapes_3 for 3D implementation - * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D wrappings - - in CGAL, the Computational Geometry Algorithms Library. - As a starting point, we follow the conventions of the CGAL library. - -# The so-called spectrum or sets of (weighted) alpha shapes includes the convex hull of a point set. -type: group -NXcg_alpha_complex(NXcg_primitive_set): - type: - doc: | - Type of alpha complex following the terminology used by CGAL for now. - - Basic means (unweighted) alpha shapes. Alpha_wrapping means meshes - created using the alpha_wrapping algorithm. - enumeration: [convex_hull, alpha_shape, alpha_wrapping] - regularize_alpha_complex(NX_BOOLEAN): - doc: | - Are singular faces removed, i.e. has the alpha complex - been regularized or not. - - # R+0 means positive real number including zero which is a super set of NX_FLOAT and a sub-set of NX_NUMBER - alpha(NX_NUMBER): - unit: NX_LENGTH - doc: | - The alpha parameter, i.e. the radius of the alpha-sphere that - is used when computing the alpha complex. - - # the dim: argument can be omitted to indicate that a scalar is expected - # means a length quantity, i.e. m, km, or nm is possible i.e. has to be length but no further constraints - # stating meter is a stronger constraint while m is the strongest constraint, meaning literally the value is m. - offset(NX_NUMBER): - unit: NX_LENGTH - doc: | - The offset distance parameter used when computing alpha_wrappings. - - # check again carefully the CGAL documentation talks about, for 3D, the square of the radius! - point_setID(NXcg_point_set): - - # basically just constraints that if you use one or more instances of NXcg_point_set - # inside an instance of NXcg_alpha_complex, name that group with the prefix "point_set" - doc: | - Point cloud for which the alpha shape or wrapping has been computed. - - # this could also just be implemented as a link but how would this be possible - # unfold the NXcg_point_set and add a - # weight(NX_NUMBER): - # doc: Weights for each point - # In general, an alpha complex is a disconnected and non-pure complex, - # meaning in particular that the alpha complex may have singular faces. - # so the number of cells, faces and edges depends on how a specific alpha complex, - # i.e. an alpha-shape of S for alpha, is filtrated with respect to k < d-dimensional - # simplices. Here we assume that number_of_cells, number_of_faces, number_of_edges - # are reported assuming one filtrates these simplices according to type. - # also using the assumption the base class reports the unique vertices - # of the specifically filtrated alpha complex. - triangle_setID(NXcg_triangle_set): - doc: | - Triangle soup for which the alpha wrapping has been computed. - triangle_meshID(NXcg_triangle_set): - doc: | - Triangle mesh representing the alpha complex. - - # add for each triangle if desirable a notation of whether the simplex is - # exterior, regular, singular, or interior with respect to the alpha complex - # a triangulation is more than a triangle (soup)/set because there it has connectivity - # customize the NXcg_triangle_set base class members such that connectivity can be contained naturally - # we need to find also a better name for this, what people intutive understand - # as the interior, may not even exist for a given alpha value - # more specifically it is the set of filtrated cells acknowledging mode - # e.g. the interior cells of the regularized alpha complex - interior_cellsID(NXcg_tetrahedron_set): - doc: | - Set of tetrahedra representing the volume inside the alpha complex. - - # document the alpha status - # https://doc.cgal.org/latest/Alpha_shapes_3/classCGAL_1_1Alpha__status.html - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# dd06c16333261a05abace6d8d71666f4b2db3bae426d74901fa6d0f87fea97df -# -# -# -# -# -# -# Computational geometry of alpha shapes or alpha wrappings about primitives. -# -# For details see: -# -# * https://dx.doi.org/10.1109/TIT.1983.1056714 for 2D, -# * https://dx.doi.org/10.1145/174462.156635 for 3D, -# * https://dl.acm.org/doi/10.5555/871114 for weighted, and -# * https://doc.cgal.org/latest/Alpha_shapes_3 for 3D implementation -# * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D wrappings -# -# in CGAL, the Computational Geometry Algorithms Library. -# As a starting point, we follow the conventions of the CGAL library. -# -# -# -# Type of alpha complex following the terminology used by CGAL for now. -# -# Basic means (unweighted) alpha shapes. Alpha_wrapping means meshes -# created using the alpha_wrapping algorithm. -# -# -# -# -# -# -# -# -# -# Are singular faces removed, i.e. has the alpha complex -# been regularized or not. -# -# -# -# -# -# The alpha parameter, i.e. the radius of the alpha-sphere that -# is used when computing the alpha complex. -# -# -# -# -# -# The offset distance parameter used when computing alpha_wrappings. -# -# -# -# -# -# -# Point cloud for which the alpha shape or wrapping has been computed. -# -# -# -# -# -# Triangle soup for which the alpha wrapping has been computed. -# -# -# -# -# Triangle mesh representing the alpha complex. -# -# -# -# -# -# Set of tetrahedra representing the volume inside the alpha complex. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_cylinder_set.yaml b/contributed_definitions/nyaml/NXcg_cylinder_set.yaml deleted file mode 100644 index b62b9f9f39..0000000000 --- a/contributed_definitions/nyaml/NXcg_cylinder_set.yaml +++ /dev/null @@ -1,255 +0,0 @@ -category: base -doc: | - Computational geometry description of a set of cylinders. - - The radius can either be defined in the radii field or by filling both - the upper_cap_radii or lower_cap_radii field. The latter field case can - thus be used to represent truncated cones. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the space in which the members are assumed embedded. - c: | - The cardinality of the set, i.e. the number of members. - -# redundant as there is NXcsg, NXquadric, NXsolid_geometry with which -# cylinder could be constructed, but NXcylinder is easier to understand -type: group -NXcg_cylinder_set(NXcg_primitive_set): - height(NX_NUMBER): - unit: NX_LENGTH - doc: | - A direction vector which is parallel to the cylinder/cone axis - and whose magnitude is the height of the cylinder/cone. - dimensions: - rank: 2 - dim: [[1, c], [2, d]] - - # observe that although we claim that d is the dimensionality we have - # currently no strategy to tell it must not be d but the actual value - # equally so the symbol c, currently all we say that in the specialization - # defined here the fields radii, upper_cap_radius, and others are all having - # value arguments of the same shape, i.e. these are arrays of rank one with some length c! - # behind the dimensionality field defined either in the here defined specialization - # of NXcg_primitive_set or otherwise that variable is undefined - # alternatively one could store the center of the lower and upper cap but - # these are then no longer necessarily on the same axis - # maybe a future feature for representing skewed cylinder, but then - # one should really better use NXquadric... - radius(NX_NUMBER): - unit: NX_LENGTH - doc: | - Radius of the cylinder if all have the same radius. - radii(NX_NUMBER): - unit: NX_LENGTH - doc: | - Radii of the cylinder. - dimensions: - rank: 1 - dim: [[1, c]] - upper_cap_radii(NX_NUMBER): - unit: NX_LENGTH - doc: | - Radii of the upper circular cap. - - This field, combined with lower_cap_radius can be used to describe - (eventually truncated) circular cones. - dimensions: - rank: 1 - dim: [[1, c]] - lower_cap_radii(NX_NUMBER): - unit: NX_LENGTH - doc: | - Radii of the upper circular cap. - - This field, combined with upper_cap_radius can be used to describe - (eventually truncated) circular cones. - dimensions: - rank: 1 - dim: [[1, c]] - - # properties of the cylinder - lateral_surface_area(NX_NUMBER): - unit: NX_AREA - doc: | - Lateral surface area - dimensions: - rank: 1 - dim: [[1, c]] - upper_cap_surface_area(NX_NUMBER): - unit: NX_AREA - doc: | - Area of the upper cap of each cylinder. - dimensions: - rank: 1 - dim: [[1, c]] - lower_cap_surface_area(NX_NUMBER): - unit: NX_AREA - doc: | - Area of the lower cap of each cylinder. - dimensions: - rank: 1 - dim: [[1, c]] - total_surface_area(NX_NUMBER): - unit: NX_AREA - doc: | - Sum of upper and lower cap areas and lateral surface area - of each cylinder. - dimensions: - rank: 1 - dim: [[1, c]] - - # again cap, lateral surface area and volume are so trivial to compute - # do we need really storage for this or recompute on-the-fly? - # similarly to hollow sphere discussion, hollow cylinder, cylinder stack - # do wish to define intersections?, if this is the case, one - # should use the NXcsg and NXquadric descriptions? - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e9a054e62040918896089e116671843d5eab36a89e2f4d2c48e27266b9edf7b9 -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality of the space in which the members are assumed embedded. -# -# -# -# -# The cardinality of the set, i.e. the number of members. -# -# -# -# -# Computational geometry description of a set of cylinders. -# -# The radius can either be defined in the radii field or by filling both -# the upper_cap_radii or lower_cap_radii field. The latter field case can -# thus be used to represent truncated cones. -# -# -# -# A direction vector which is parallel to the cylinder/cone axis -# and whose magnitude is the height of the cylinder/cone. -# -# -# -# -# -# -# -# -# -# Radius of the cylinder if all have the same radius. -# -# -# -# -# Radii of the cylinder. -# -# -# -# -# -# -# -# Radii of the upper circular cap. -# -# This field, combined with lower_cap_radius can be used to describe -# (eventually truncated) circular cones. -# -# -# -# -# -# -# -# Radii of the upper circular cap. -# -# This field, combined with upper_cap_radius can be used to describe -# (eventually truncated) circular cones. -# -# -# -# -# -# -# -# -# Lateral surface area -# -# -# -# -# -# -# -# Area of the upper cap of each cylinder. -# -# -# -# -# -# -# -# Area of the lower cap of each cylinder. -# -# -# -# -# -# -# -# Sum of upper and lower cap areas and lateral surface area -# of each cylinder. -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml b/contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml deleted file mode 100644 index 458fef8c95..0000000000 --- a/contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml +++ /dev/null @@ -1,100 +0,0 @@ -category: base -doc: | - Computational geometry description of a set of ellipsoids. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the space in which the members are assumed embedded. - c: | - The cardinality of the set, i.e. the number of members. - -# redundant as there is NXcsg, and NXquadric but easier to understand -type: group -NXcg_ellipsoid_set(NXcg_primitive_set): - half_axes_radius(NX_NUMBER): - unit: NX_LENGTH - doc: | - Radius of the half axes. - - Use if all ellipsoids in the set have the same half-axes. - dimensions: - rank: 1 - dim: [[1, d]] - half_axes_radii(NX_NUMBER): - unit: NX_LENGTH - doc: | - Half-axes radii of each ellipsoid. - dimensions: - rank: 2 - dim: [[1, c], [2, d]] - - # properties of ellipsoids - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 3cc31e0d50ce63b233b0995dfb69b62f89ab5908bb19ff8d7f339f5bc000fcbf -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality of the space in which the members are assumed embedded. -# -# -# -# -# The cardinality of the set, i.e. the number of members. -# -# -# -# -# Computational geometry description of a set of ellipsoids. -# -# -# -# Radius of the half axes. -# -# Use if all ellipsoids in the set have the same half-axes. -# -# -# -# -# -# -# -# Half-axes radii of each ellipsoid. -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml b/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml deleted file mode 100644 index 3e4209583a..0000000000 --- a/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml +++ /dev/null @@ -1,401 +0,0 @@ -category: base -doc: | - Computational geometry of primitives via a face-and-edge-list data structure. - - Primitives must neither be degenerated nor self-intersect but can differ in - their properties. A face-and-edge-list-based description of primitives is - frequently used for triangles and polyhedra to store them on disk for - visualization purposes (see OFF, PLY, VTK, or STL file formats). - - Although this description is storage efficient it is not well suited for - topological analyses though. In this case, scientists may need a different - view on the primitives which is better represented with e.g. a - half_edge_data_structure. - - Having an own base class for the data structure how primitives are stored is - useful to embrace both users with small or very detailed specification demands. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality, which has to be at least 2. - n_v: | - The number of vertices. - n_e: | - The number of edges. - n_f: | - The number of faces. - n_total: | - The total number of vertices of all faces. Faces are polygons. - n_weinberg: | - The total number of Weinberg vector values of all faces. - -# duplicate of an NXoff_geometry ? -type: group -NXcg_face_list_data_structure(NXcg_primitive_set): - - # resulting in a design similar to that of NXoff_geometry and the XDMF mixed primitive topology - number_of_vertices(NX_INT): - unit: NX_UNITLESS - doc: | - Number of vertices for each face. - - Each entry represents the total number of vertices for that face, - irrespectively whether vertices are shared among faces or not. - dimensions: - rank: 1 - dim: [[1, n_f]] - number_of_edges(NX_INT): - unit: NX_UNITLESS - doc: | - Number of edges for each face. - - Each entry represents the total number of edges for that face, - irrespectively whether edges are shared across faces or not. - dimensions: - rank: 1 - dim: [[1, n_e]] - number_of_faces(NX_INT): - unit: NX_UNITLESS - doc: | - Number of faces of the primitives. - vertex_identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer offset whereby the identifier of the first member - of the vertices differs from zero. - - Identifier can be defined explicitly or implicitly. - Inspect the definition of NXcg_primitive_set for further details. - edge_identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer offset whereby the identifier of the first member - of the edges differs from zero. - - Identifier can be defined explicitly or implicitly. - Inspect the definition of NXcg_primitive_set for further details. - face_identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer offset whereby the identifier of the first member - of the faces differs from zero. - - Identifier can be defined explicitly or implicitly. - Inspect the definition of NXcg_primitive_set for further details. - vertex_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Integer identifier to distinguish all vertices explicitly. - dimensions: - rank: 1 - dim: [[1, n_v]] - edge_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Integer used to distinguish all edges explicitly. - dimensions: - rank: 1 - dim: [[1, n_e]] - face_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Integer used to distinguish all faces explicitly. - dimensions: - rank: 1 - dim: [[1, n_f]] - vertices(NX_NUMBER): - unit: NX_ANY - doc: | - Positions of the vertices. - - Users are encouraged to reduce the vertices to a unique set as this may - result in a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. Naively here means that each - vertex is stored even though many share the same positions. - dimensions: - rank: 2 - dim: [[1, n_v], [2, d]] - edges(NX_INT): - unit: NX_UNITLESS - doc: | - The edges are stored as pairs of vertex identifier. - dimensions: - rank: 2 - dim: [[1, n_e], [2, 2]] - faces(NX_INT): - unit: NX_UNITLESS - doc: | - The faces are stored as a concatenated array of vertex identifier tuples. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. - dimensions: - rank: 1 - dim: [[1, n_total]] - - # properties - vertices_are_unique(NX_BOOLEAN): - doc: | - If true, indicates that the vertices are all placed at different positions - and have different identifiers, i.e. no points overlap or are counted more - than once. - edges_are_unique(NX_BOOLEAN): - doc: | - If true, indicates that no edge is stored more than once. - - Users are encouraged to consider using a half_edge_data_structure instead. - faces_are_unique(NX_BOOLEAN): - doc: | - If true, indicates that no face is stored more than once. - winding_order(NX_INT): - unit: NX_UNITLESS - doc: | - Specifies for each face which winding order was used if any: - - * 0 - undefined - * 1 - counter-clockwise (CCW) - * 2 - clock-wise (CW) - dimensions: - rank: 1 - dim: [[1, n_f]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a3f36a3c5cda218227a8cbbc7e4877ec1e017989bfb731d809d586ab9af271ea -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality, which has to be at least 2. -# -# -# -# -# The number of vertices. -# -# -# -# -# The number of edges. -# -# -# -# -# The number of faces. -# -# -# -# -# The total number of vertices of all faces. Faces are polygons. -# -# -# -# -# The total number of Weinberg vector values of all faces. -# -# -# -# -# Computational geometry of primitives via a face-and-edge-list data structure. -# -# Primitives must neither be degenerated nor self-intersect but can differ in -# their properties. A face-and-edge-list-based description of primitives is -# frequently used for triangles and polyhedra to store them on disk for -# visualization purposes (see OFF, PLY, VTK, or STL file formats). -# -# Although this description is storage efficient it is not well suited for -# topological analyses though. In this case, scientists may need a different -# view on the primitives which is better represented with e.g. a -# half_edge_data_structure. -# -# Having an own base class for the data structure how primitives are stored is -# useful to embrace both users with small or very detailed specification demands. -# -# -# -# -# Number of vertices for each face. -# -# Each entry represents the total number of vertices for that face, -# irrespectively whether vertices are shared among faces or not. -# -# -# -# -# -# -# -# Number of edges for each face. -# -# Each entry represents the total number of edges for that face, -# irrespectively whether edges are shared across faces or not. -# -# -# -# -# -# -# -# Number of faces of the primitives. -# -# -# -# -# Integer offset whereby the identifier of the first member -# of the vertices differs from zero. -# -# Identifier can be defined explicitly or implicitly. -# Inspect the definition of NXcg_primitive_set for further details. -# -# -# -# -# Integer offset whereby the identifier of the first member -# of the edges differs from zero. -# -# Identifier can be defined explicitly or implicitly. -# Inspect the definition of NXcg_primitive_set for further details. -# -# -# -# -# Integer offset whereby the identifier of the first member -# of the faces differs from zero. -# -# Identifier can be defined explicitly or implicitly. -# Inspect the definition of NXcg_primitive_set for further details. -# -# -# -# -# Integer identifier to distinguish all vertices explicitly. -# -# -# -# -# -# -# -# Integer used to distinguish all edges explicitly. -# -# -# -# -# -# -# -# Integer used to distinguish all faces explicitly. -# -# -# -# -# -# -# -# Positions of the vertices. -# -# Users are encouraged to reduce the vertices to a unique set as this may -# result in a more efficient storage of the geometry data. -# It is also possible though to store the vertex positions naively in which -# case vertices_are_unique is likely False. Naively here means that each -# vertex is stored even though many share the same positions. -# -# -# -# -# -# -# -# -# The edges are stored as pairs of vertex identifier. -# -# -# -# -# -# -# -# -# The faces are stored as a concatenated array of vertex identifier tuples. -# -# The first entry is the identifier of the start vertex of the first face, -# followed by the second vertex of the first face, until the last vertex -# of the first face. Thereafter, the start vertex of the second face, the -# second vertex of the second face, and so on and so forth. -# -# Therefore, summating over the number_of_vertices, allows to extract -# the vertex identifiers for the i-th face on the following index interval -# of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. -# -# -# -# -# -# -# -# -# If true, indicates that the vertices are all placed at different positions -# and have different identifiers, i.e. no points overlap or are counted more -# than once. -# -# -# -# -# If true, indicates that no edge is stored more than once. -# -# Users are encouraged to consider using a half_edge_data_structure instead. -# -# -# -# -# If true, indicates that no face is stored more than once. -# -# -# -# -# Specifies for each face which winding order was used if any: -# -# * 0 - undefined -# * 1 - counter-clockwise (CCW) -# * 2 - clock-wise (CW) -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml b/contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml deleted file mode 100644 index 32c49e2392..0000000000 --- a/contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml +++ /dev/null @@ -1,89 +0,0 @@ -category: base -doc: | - Computational geometry description of a geodesic mesh. - - A geodesic surface mesh is a triangulated surface mesh with metadata which - can be used as an approximation to describe the surface of a sphere. - Triangulation of spheres are commonly used in Materials Science - for quantifying texture of materials, i.e. the relative rotation of - crystals to sample directions. - - For additional details or an introduction into the topic of geodesic meshes - see (from which specifically the section on subdivision schemes is relevant). - - * `E. S. Popko and C. J. Kitrick `_ - - Earth scientists have specific demands and different views about what should - be included in such a base class, given that nested geodesic meshes are a key - component of climate modelling software. For now we propose to use this - base class as a container for organizing data related to geodesic meshes. - - Specifically an instance of this base class should detail the rule set how - e.g. a geodesic (surface) mesh was instantiated as there are many - possibilities to do so. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXcg_geodesic_mesh(NXcg_primitive_set): - (NXcg_triangulated_surface_mesh): - - # Discussions with NFDI-Earth could make this base class more meaty and detailed. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# b3dfb393b42a5745efb9464494cea2ba9f08fe0d876869838c299650036eba7f -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Computational geometry description of a geodesic mesh. -# -# A geodesic surface mesh is a triangulated surface mesh with metadata which -# can be used as an approximation to describe the surface of a sphere. -# Triangulation of spheres are commonly used in Materials Science -# for quantifying texture of materials, i.e. the relative rotation of -# crystals to sample directions. -# -# For additional details or an introduction into the topic of geodesic meshes -# see (from which specifically the section on subdivision schemes is relevant). -# -# * `E. S. Popko and C. J. Kitrick <https://doi.org/10.1201/9781003134114>`_ -# -# Earth scientists have specific demands and different views about what should -# be included in such a base class, given that nested geodesic meshes are a key -# component of climate modelling software. For now we propose to use this -# base class as a container for organizing data related to geodesic meshes. -# -# Specifically an instance of this base class should detail the rule set how -# e.g. a geodesic (surface) mesh was instantiated as there are many -# possibilities to do so. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_grid.yaml b/contributed_definitions/nyaml/NXcg_grid.yaml deleted file mode 100644 index 45c8654447..0000000000 --- a/contributed_definitions/nyaml/NXcg_grid.yaml +++ /dev/null @@ -1,265 +0,0 @@ -category: base -doc: | - Computational geometry description of a grid of Wigner-Seitz cells in Euclidean space. - - Three-dimensional grids with cubic cells are if not the most frequently used - example of such grids. Examples of numerical methods where grids are used - are spectral-solver based crystal plasticity or other stencil methods like - phase-field or cellular automata. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the grid. - c: | - The cardinality or total number of cells aka grid points. - n_b: | - Number of boundaries of the bounding box or primitive housing the grid. -type: group -NXcg_grid(NXcg_primitive_set): - origin(NX_NUMBER): - unit: NX_ANY - doc: | - Location of the origin of the grid. - - Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` - class to specify the coordinate system in which the origin location is defined. - dimensions: - rank: 1 - dim: [[1, d]] - symmetry(NX_CHAR): - doc: | - The symmetry of the lattice defining the shape of the unit cell. - enumeration: [cubic] - cell_dimensions(NX_NUMBER): - unit: NX_LENGTH - doc: | - The unit cell dimensions using crystallographic notation. - dimensions: - rank: 1 - dim: [[1, d]] - extent(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of unit cells along each of the d unit vectors. - - The total number of cells or grid points has to be the cardinality. - If the grid has an irregular number of grid positions in each direction, - as it could be for instance the case of a grid where all grid points - outside some masking primitive are removed, this extent field should - not be used. Instead, use the coordinate field. - dimensions: - rank: 1 - dim: [[1, d]] - - # number_of_cells(NX_UINT): maybe already too trivial quantities - # should constraints on the grid be place here or not - position(NX_NUMBER): - unit: NX_ANY - doc: | - Position of each cell in Euclidean space. - dimensions: - rank: 2 - dim: [[1, c], [2, d]] - coordinate(NX_INT): - unit: NX_DIMENSIONLESS - doc: | - Coordinate of each cell with respect to the discrete grid. - dimensions: - rank: 2 - dim: [[1, c], [2, d]] - - # this should be a ROI - bounding_box(NXcg_polyhedron_set): - doc: | - A tight bounding box about the grid. - - # does it have to be a tight bounding box? - # a good example for a general bounding box description for such a grids of triclinic cells - # https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallelepiped - number_of_boundaries(NX_INT): - unit: NX_UNITLESS - doc: | - Number of boundaries distinguished - - Most grids discretize a cubic or cuboidal region. In this case - six sides can be distinguished, each making an own boundary. - boundaries(NX_CHAR): - doc: | - Name of domain boundaries of the simulation box/ROI - e.g. left, right, front, back, bottom, top. - dimensions: - rank: 1 - dim: [[1, n_b]] - boundary_conditions(NX_INT): - unit: NX_UNITLESS - doc: | - The boundary conditions for each boundary: - - 0 - undefined - 1 - open - 2 - periodic - 3 - mirror - 4 - von Neumann - 5 - Dirichlet - dimensions: - rank: 1 - dim: [[1, n_b]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# ed527bf012261fe9a8099480c6b2c19da1d8e031c8abda828ba39a82326b1e8e -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality of the grid. -# -# -# -# -# The cardinality or total number of cells aka grid points. -# -# -# -# -# Number of boundaries of the bounding box or primitive housing the grid. -# -# -# -# -# Computational geometry description of a grid of Wigner-Seitz cells in Euclidean space. -# -# Three-dimensional grids with cubic cells are if not the most frequently used -# example of such grids. Examples of numerical methods where grids are used -# are spectral-solver based crystal plasticity or other stencil methods like -# phase-field or cellular automata. -# -# -# -# Location of the origin of the grid. -# -# Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` -# class to specify the coordinate system in which the origin location is defined. -# -# -# -# -# -# -# -# The symmetry of the lattice defining the shape of the unit cell. -# -# -# -# -# -# -# -# The unit cell dimensions using crystallographic notation. -# -# -# -# -# -# -# -# Number of unit cells along each of the d unit vectors. -# -# The total number of cells or grid points has to be the cardinality. -# If the grid has an irregular number of grid positions in each direction, -# as it could be for instance the case of a grid where all grid points -# outside some masking primitive are removed, this extent field should -# not be used. Instead, use the coordinate field. -# -# -# -# -# -# -# -# -# Position of each cell in Euclidean space. -# -# -# -# -# -# -# -# -# Coordinate of each cell with respect to the discrete grid. -# -# -# -# -# -# -# -# -# -# A tight bounding box about the grid. -# -# -# -# -# -# Number of boundaries distinguished -# -# Most grids discretize a cubic or cuboidal region. In this case -# six sides can be distinguished, each making an own boundary. -# -# -# -# -# Name of domain boundaries of the simulation box/ROI -# e.g. left, right, front, back, bottom, top. -# -# -# -# -# -# -# -# The boundary conditions for each boundary: -# -# 0 - undefined -# 1 - open -# 2 - periodic -# 3 - mirror -# 4 - von Neumann -# 5 - Dirichlet -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml b/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml deleted file mode 100644 index 4db22e6509..0000000000 --- a/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml +++ /dev/null @@ -1,344 +0,0 @@ -category: base -doc: | - Computational geeometry description of a half-edge data structure. - - Such a data structure can be used to efficiently circulate around faces - and iterate over vertices of a planar graph. - -# holes in the polygon mesh can be handled -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality, which has to be at least 2. - n_v: | - The number of vertices. - n_f: | - The number of faces. - n_he: | - The number of half-edges. -type: group -NXcg_half_edge_data_structure(NXcg_primitive_set): - - # resulting in a design similar to that of NXoff_geometry and the XDMF mixed primitive topology - number_of_vertices(NX_INT): - unit: NX_UNITLESS - doc: | - Number of vertices for each face. - - Each entry represents the total number of vertices for that face, - irrespectively whether vertices are shared among faces or not. - dimensions: - rank: 1 - dim: [[1, n_f]] - number_of_edges(NX_INT): - unit: NX_UNITLESS - doc: | - Number of edges for each face. - - Each entry represents the total number of edges for that face, - irrespectively whether edges are shared across faces or not. - dimensions: - rank: 1 - dim: [[1, n_e]] - number_of_faces(NX_INT): - unit: NX_UNITLESS - doc: | - Number of faces of the primitives. - vertex_identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer offset whereby the identifier of the first member - of the vertices differs from zero. - - Identifier can be defined explicitly or implicitly. - Inspect the definition of :ref:`NXcg_primitive_set` for further details. - edge_identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer offset whereby the identifier of the first member - of the edges differs from zero. - - Identifier can be defined explicitly or implicitly. - Inspect the definition of :ref:`NXcg_primitive_set` for further details. - face_identifier_offset(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the faces differs from zero. - - Identifier can be defined explicitly or implicitly. - Inspect the definition of :ref:`NXcg_primitive_set` for further details. - - # therefore, vertex_-, face_-, half_edge_-identifier are implicit - position(NX_NUMBER): - unit: NX_ANY - doc: | - The position of the vertices. - dimensions: - rank: 2 - dim: [[1, n_v], [2, d]] - vertex_incident_half_edge(NX_INT): - unit: NX_UNITLESS - doc: | - Identifier of the incident half-edge. - dimensions: - rank: 1 - dim: [[1, n_v]] - face_half_edge(NX_INT): - unit: NX_UNITLESS - doc: | - Identifier of the (starting)/associated half-edge of the face. - dimensions: - rank: 1 - dim: [[1, n_f]] - half_edge_vertex_origin(NX_INT): - unit: NX_UNITLESS - doc: | - The identifier of the vertex from which this half-edge is outwards pointing. - dimensions: - rank: 1 - dim: [[1, n_he]] - half_edge_twin(NX_INT): - unit: NX_UNITLESS - doc: | - Identifier of the associated oppositely pointing half-edge. - dimensions: - rank: 1 - dim: [[1, n_he]] - half_edge_incident_face(NX_INT): - unit: NX_UNITLESS - doc: | - If the half-edge is a boundary half-edge the - incident face identifier is NULL, i.e. 0. - dimensions: - rank: 1 - dim: [[1, n_he]] - half_edge_next(NX_INT): - unit: NX_UNITLESS - doc: | - Identifier of the next half-edge. - dimensions: - rank: 1 - dim: [[1, n_he]] - half_edge_prev(NX_INT): - unit: NX_UNITLESS - doc: | - Identifier of the previous half-edge. - dimensions: - rank: 1 - dim: [[1, n_he]] - weinberg_vector(NX_CHAR): - doc: | - Users are referred to the literature for the background of L. Weinberg's - work about topological characterization of planar graphs: - - * `L. Weinberg 1966a, `_ - * `L. Weinberg, 1966b, `_ - * `E. A. Lazar et al. `_ - - and how this work can e.g. be applied in space-filling tessellations - of microstructural objects like crystals/grains. - - # eventually store the Weinberg vector as an integer array - # which could be more efficient - # see https://jerryyin.info/geometry-processing-algorithms/half-edge/ - # for an illustrative example of half-edge data structures - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 52d8184a299749c24e19f2b06b4dce80d15eb1645d69665ba05c9707283885a3 -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality, which has to be at least 2. -# -# -# -# -# The number of vertices. -# -# -# -# -# The number of faces. -# -# -# -# -# The number of half-edges. -# -# -# -# -# Computational geeometry description of a half-edge data structure. -# -# Such a data structure can be used to efficiently circulate around faces -# and iterate over vertices of a planar graph. -# -# -# -# -# Number of vertices for each face. -# -# Each entry represents the total number of vertices for that face, -# irrespectively whether vertices are shared among faces or not. -# -# -# -# -# -# -# -# Number of edges for each face. -# -# Each entry represents the total number of edges for that face, -# irrespectively whether edges are shared across faces or not. -# -# -# -# -# -# -# -# Number of faces of the primitives. -# -# -# -# -# Integer offset whereby the identifier of the first member -# of the vertices differs from zero. -# -# Identifier can be defined explicitly or implicitly. -# Inspect the definition of :ref:`NXcg_primitive_set` for further details. -# -# -# -# -# Integer offset whereby the identifier of the first member -# of the edges differs from zero. -# -# Identifier can be defined explicitly or implicitly. -# Inspect the definition of :ref:`NXcg_primitive_set` for further details. -# -# -# -# -# Integer offset whereby the identifier of the first member -# of the faces differs from zero. -# -# Identifier can be defined explicitly or implicitly. -# Inspect the definition of :ref:`NXcg_primitive_set` for further details. -# -# -# -# -# -# The position of the vertices. -# -# -# -# -# -# -# -# -# Identifier of the incident half-edge. -# -# -# -# -# -# -# -# Identifier of the (starting)/associated half-edge of the face. -# -# -# -# -# -# -# -# The identifier of the vertex from which this half-edge is outwards pointing. -# -# -# -# -# -# -# -# Identifier of the associated oppositely pointing half-edge. -# -# -# -# -# -# -# -# If the half-edge is a boundary half-edge the -# incident face identifier is NULL, i.e. 0. -# -# -# -# -# -# -# -# Identifier of the next half-edge. -# -# -# -# -# -# -# -# Identifier of the previous half-edge. -# -# -# -# -# -# -# -# Users are referred to the literature for the background of L. Weinberg's -# work about topological characterization of planar graphs: -# -# * `L. Weinberg 1966a, <https://dx.doi.org/10.1109/TCT.1964.1082216>`_ -# * `L. Weinberg, 1966b, <https://dx.doi.org/10.1137/0114062>`_ -# * `E. A. Lazar et al. <https://doi.org/10.1103/PhysRevLett.109.095505>`_ -# -# and how this work can e.g. be applied in space-filling tessellations -# of microstructural objects like crystals/grains. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_hexahedron_set.yaml b/contributed_definitions/nyaml/NXcg_hexahedron_set.yaml deleted file mode 100644 index af65ad1019..0000000000 --- a/contributed_definitions/nyaml/NXcg_hexahedron_set.yaml +++ /dev/null @@ -1,345 +0,0 @@ -category: base -doc: | - Computational geometry description of a set of hexahedra in Euclidean space. - - This class can also be used to describe cuboids or cubes, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts an approach whereby - different specific views can be implemented using the same base class: - - * In the simplest case experimentalists may use this base class to describe - the dimensions or size of a specimen. In this case the alignment with axes - is not relevant as eventually only the volume of the specimen is of interest. - * In many cases, take for example an experiment where a specimen was cut out - from a specifically deformed piece of material, the orientation of the - specimen's edges with the experiment coordinate system is of high relevance. - Examples include knowledge about the specimen edge, whether it is - parallel to the rolling, the transverse, or the normal direction. - * While the above-mentioned use cases are sufficient to pinpoint the sample - within a known laboratory/experiment coordinate system, these descriptions - are not detailed enough to specify e.g. a CAD model of the specimen. - * Therefore, groups and fields for an additional, computational-geometry- - based view of hexahedra is offered to serve additional computational - tasks: storage-oriented simple views or detailed topological/graph-based - descriptions. - - Hexahedra are important geometrical primitives, which are among the most - frequently used elements in finite element meshing/modeling. - - As a specialization of the :ref:`NXcg_primitive_set` base class hexahedra - are assumed non-degenerated, closed, and built of polygons that are - not self-intersecting. - - The term hexahedra will be used throughout this base class but includes - the special cases cuboid, cube, box, axis-aligned bounding box (AABB), - and optimal bounding box (OBB). - - An axis-aligned bounding box is a common data object in computational science - and simulation codes to represent a cuboid whose edges are aligned with the - base vectors of a coordinate system. As a part of binary trees, these data - objects are important for making time- as well as space-efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tightly fitting box about an arbitrary object. In general, such boxes are - rotated. Exact and substantially faster in practice approximate algorithms - exist to compute optimal or near optimal bounding boxes for sets of points. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - c: | - The cardinality of the set, i.e. the number of hexahedra. - -# it is useful to define own base classes for frequently used classes -# a polyhedron is a specific polytope in 3d, do we need -# higher-dimensional polytopes? that could be useful for simplicies though -# as they are used in numerics etc. maybe reach out here to our friends -# from MarDI, for now let's assume we do not need polytopes for d > 3 -type: group -NXcg_hexahedron_set(NXcg_primitive_set): - - # qualifiers and properties of hexahedra - shape(NX_NUMBER): - unit: NX_LENGTH - doc: | - Qualifier for the shape of each hexahedron. - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] - length(NX_NUMBER): - unit: NX_LENGTH - doc: | - Qualifier that is useful in cases when one edge is longer than all other - edges of the hexahedra. Often the term length is associated with the - assumption that one edge is parallel to an axis of the coordinate system. - dimensions: - rank: 1 - dim: [[1, c]] - width(NX_NUMBER): - unit: NX_LENGTH - doc: | - Qualifier often used to describe the extent of an object in the horizontal - direction assuming a specific coordinate system. - - For the sake of explicitness quantities like length, width, and height - should not be reported without specifying also the assumed reference frame. - dimensions: - rank: 1 - dim: [[1, c]] - height(NX_NUMBER): - unit: NX_LENGTH - doc: | - Qualifier often used to describe the extent of an object in the vertical - direction assuming a specific coordinate system. - dimensions: - rank: 1 - dim: [[1, c]] - volume(NX_NUMBER): - unit: NX_VOLUME - doc: | - Volume of each hexahedron. - dimensions: - rank: 1 - dim: [[1, c]] - area(NX_NUMBER): - unit: NX_AREA - doc: | - Total (surface) area (of all six faces) of each hexahedron. - dimensions: - rank: 1 - dim: [[1, c]] - face_area(NX_NUMBER): - unit: NX_AREA - doc: | - Area of each of the six faces of each hexahedron. - dimensions: - rank: 2 - dim: [[1, c], [2, 6]] - is_box(NX_BOOLEAN): - doc: | - Specifies if the hexahedra represent cuboids or cubes eventually rotated - ones but at least not too exotic six-faced polyhedra. - dimensions: - rank: 1 - dim: [[1, c]] - is_axis_aligned(NX_BOOLEAN): - doc: | - Only to be used if is_box is present. In this case, this field describes - whether hexahedra are boxes whose primary edges are parallel to the - axes of the coordinate system. - dimensions: - rank: 1 - dim: [[1, c]] - - # substantially more detailed descriptors of the shape, the mesh - # orientation(NXorientation_set): - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - - # detailed mesh-based representation - hexahedra(NXcg_face_list_data_structure): - doc: | - Combined storage of all primitives of all hexahedra. - hexahedronID(NXcg_face_list_data_structure): - doc: | - Individual storage of each hexahedron. - hexahedron_half_edgeID(NXcg_half_edge_data_structure): - doc: | - Individual storage of each hexahedron as a graph. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2ca4ead97d661d0a560f3004737c458ae323b2fd11b537a542ac5f95dcfbe0b9 -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The cardinality of the set, i.e. the number of hexahedra. -# -# -# -# -# Computational geometry description of a set of hexahedra in Euclidean space. -# -# This class can also be used to describe cuboids or cubes, axis-aligned or not. -# The class represents different access and description levels to offer both -# applied scientists and computational geometry experts an approach whereby -# different specific views can be implemented using the same base class: -# -# * In the simplest case experimentalists may use this base class to describe -# the dimensions or size of a specimen. In this case the alignment with axes -# is not relevant as eventually only the volume of the specimen is of interest. -# * In many cases, take for example an experiment where a specimen was cut out -# from a specifically deformed piece of material, the orientation of the -# specimen's edges with the experiment coordinate system is of high relevance. -# Examples include knowledge about the specimen edge, whether it is -# parallel to the rolling, the transverse, or the normal direction. -# * While the above-mentioned use cases are sufficient to pinpoint the sample -# within a known laboratory/experiment coordinate system, these descriptions -# are not detailed enough to specify e.g. a CAD model of the specimen. -# * Therefore, groups and fields for an additional, computational-geometry- -# based view of hexahedra is offered to serve additional computational -# tasks: storage-oriented simple views or detailed topological/graph-based -# descriptions. -# -# Hexahedra are important geometrical primitives, which are among the most -# frequently used elements in finite element meshing/modeling. -# -# As a specialization of the :ref:`NXcg_primitive_set` base class hexahedra -# are assumed non-degenerated, closed, and built of polygons that are -# not self-intersecting. -# -# The term hexahedra will be used throughout this base class but includes -# the special cases cuboid, cube, box, axis-aligned bounding box (AABB), -# and optimal bounding box (OBB). -# -# An axis-aligned bounding box is a common data object in computational science -# and simulation codes to represent a cuboid whose edges are aligned with the -# base vectors of a coordinate system. As a part of binary trees, these data -# objects are important for making time- as well as space-efficient queries -# of geometric primitives in techniques like kd-trees. -# -# An optimal bounding box is a common data object which provides the best -# tightly fitting box about an arbitrary object. In general, such boxes are -# rotated. Exact and substantially faster in practice approximate algorithms -# exist to compute optimal or near optimal bounding boxes for sets of points. -# -# -# -# -# Qualifier for the shape of each hexahedron. -# -# -# -# -# -# -# -# -# Qualifier that is useful in cases when one edge is longer than all other -# edges of the hexahedra. Often the term length is associated with the -# assumption that one edge is parallel to an axis of the coordinate system. -# -# -# -# -# -# -# -# Qualifier often used to describe the extent of an object in the horizontal -# direction assuming a specific coordinate system. -# -# For the sake of explicitness quantities like length, width, and height -# should not be reported without specifying also the assumed reference frame. -# -# -# -# -# -# -# -# Qualifier often used to describe the extent of an object in the vertical -# direction assuming a specific coordinate system. -# -# -# -# -# -# -# -# Volume of each hexahedron. -# -# -# -# -# -# -# -# Total (surface) area (of all six faces) of each hexahedron. -# -# -# -# -# -# -# -# Area of each of the six faces of each hexahedron. -# -# -# -# -# -# -# -# -# Specifies if the hexahedra represent cuboids or cubes eventually rotated -# ones but at least not too exotic six-faced polyhedra. -# -# -# -# -# -# -# -# Only to be used if is_box is present. In this case, this field describes -# whether hexahedra are boxes whose primary edges are parallel to the -# axes of the coordinate system. -# -# -# -# -# -# -# -# -# -# -# -# -# Combined storage of all primitives of all hexahedra. -# -# -# -# -# Individual storage of each hexahedron. -# -# -# -# -# Individual storage of each hexahedron as a graph. -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_marching_cubes.yaml b/contributed_definitions/nyaml/NXcg_marching_cubes.yaml deleted file mode 100644 index 41882e07f4..0000000000 --- a/contributed_definitions/nyaml/NXcg_marching_cubes.yaml +++ /dev/null @@ -1,91 +0,0 @@ -category: base -doc: | - Base class to detail the marching cubes (MC) algorithm. - - Documenting which specific version of MC was used helps with understanding - how robust the results are with respect to the topology of the triangulation. - -# symbols: -type: group -NXcg_marching_cubes(NXobject): - grid(NXcg_grid): - doc: | - Metadata of the grid on which the here specified MC is operating. - (NXidentifier): - doc: | - Reference to the specific implementation of marching cubes used. - - See for example the following papers for details about specific - MC implementations: - - * `W. E. Lorensen `_ - * `T. S. Newman and H. Yi `_ - description(NX_CHAR): - doc: | - Free text field in case a proper identifier is not available. - (NXprogram): - - # we could also think about storing the rule sets in here explicitly including the - # coordinate system conventions; however, the problem is that many commercial - # tools like Matlab do not expose the rule set. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 99f62d71440f06f8c62dc35a2827f4ec3b4b3b434c99c5bf8743aad1e44357cc -# -# -# -# -# -# -# Base class to detail the marching cubes (MC) algorithm. -# -# Documenting which specific version of MC was used helps with understanding -# how robust the results are with respect to the topology of the triangulation. -# -# -# -# Metadata of the grid on which the here specified MC is operating. -# -# -# -# -# Reference to the specific implementation of marching cubes used. -# -# See for example the following papers for details about specific -# MC implementations: -# -# * `W. E. Lorensen <https://doi.org/10.1109/MCG.2020.2971284>`_ -# * `T. S. Newman and H. Yi <https://doi.org/10.1016/j.cag.2006.07.021>`_ -# -# -# -# -# Free text field in case a proper identifier is not available. -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_parallelogram_set.yaml b/contributed_definitions/nyaml/NXcg_parallelogram_set.yaml deleted file mode 100644 index 431d48a6bf..0000000000 --- a/contributed_definitions/nyaml/NXcg_parallelogram_set.yaml +++ /dev/null @@ -1,181 +0,0 @@ -category: base -doc: | - Computational geometry description of a set of parallelograms. - - This class can also be used to describe rectangles or squares, irrespective - whether these are axis-aligned or not. The class represents different - access and description levels to embrace applied scientists and computational - geometry experts with their different views: - - * The simplest case is the communication of dimensions aka the size of a - region of interest in the 2D plane. In this case, communicating the - alignment with axes is maybe not as relevant as it is to report the area - of the ROI. - * In other cases the extent of the parallelogram is relevant though. - * Finally, in CAD models it should be possible to specify the polygons - which the parallelograms represent with exact numerical details. - - Parallelograms are important geometrical primitives as their usage for - describing many scanning experiments shows where typically parallelogram-shaped - ROIs are scanned across the surface of a sample. - - The term parallelogram will be used throughout this base class thus including - the important special cases rectangle, square, 2D box, axis-aligned bounding box - (AABB), or optimal bounding box (OBB) as analogous 2D variants to their 3D - counterparts. See :ref:`NXcg_hexahedron_set` for the generalization in 3D. - - An axis-aligned bounding box is a common data object in computational science - and simulation codes to represent a rectangle whose edges are aligned with the - axes of a coordinate system. As a part of binary trees AABBs are important data - objects for executing time- as well as space-efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best, i.e. - most tightly fitting box about an arbitrary object. In general such boxes are - rotated. Other than in 3D dimensions, the rotation calipher method offers - a rigorous approach to compute an optimal bounding box to a point set in 2D. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - c: | - The cardinality of the set, i.e. the number of parallelograms. -type: group -NXcg_parallelogram_set(NXcg_primitive_set): - - # qualifiers and properties of parallelograms - is_rectangle(NX_BOOLEAN): - doc: | - To specify which parallelogram is a rectangle. - dimensions: - rank: 1 - dim: [[1, c]] - is_axis_aligned(NX_BOOLEAN): - doc: | - Only to be used if is_rectangle is present. In this case, this field - describes whether parallelograms are rectangles whose primary edges - are parallel to the axes of the coordinate system. - dimensions: - rank: 1 - dim: [[1, c]] - - # detailed mesh-based representation - parallelograms(NXcg_face_list_data_structure): - - # exists: [min, 0, max, 1] - doc: | - Combined storage of all primitives of all parallelograms. - parallelogramID(NXcg_face_list_data_structure): - doc: | - Individual storage of each parallelogram. - - #MK::parallelogram_half_edgeID(NXcg_half_edge_data_structure) - # a half-edge structure would be overkill as this is a simple primitive - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 65f639f5204351cb87c156f5c0a041300104a66e9aa6557ad772e82221700223 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The cardinality of the set, i.e. the number of parallelograms. -# -# -# -# -# Computational geometry description of a set of parallelograms. -# -# This class can also be used to describe rectangles or squares, irrespective -# whether these are axis-aligned or not. The class represents different -# access and description levels to embrace applied scientists and computational -# geometry experts with their different views: -# -# * The simplest case is the communication of dimensions aka the size of a -# region of interest in the 2D plane. In this case, communicating the -# alignment with axes is maybe not as relevant as it is to report the area -# of the ROI. -# * In other cases the extent of the parallelogram is relevant though. -# * Finally, in CAD models it should be possible to specify the polygons -# which the parallelograms represent with exact numerical details. -# -# Parallelograms are important geometrical primitives as their usage for -# describing many scanning experiments shows where typically parallelogram-shaped -# ROIs are scanned across the surface of a sample. -# -# The term parallelogram will be used throughout this base class thus including -# the important special cases rectangle, square, 2D box, axis-aligned bounding box -# (AABB), or optimal bounding box (OBB) as analogous 2D variants to their 3D -# counterparts. See :ref:`NXcg_hexahedron_set` for the generalization in 3D. -# -# An axis-aligned bounding box is a common data object in computational science -# and simulation codes to represent a rectangle whose edges are aligned with the -# axes of a coordinate system. As a part of binary trees AABBs are important data -# objects for executing time- as well as space-efficient queries -# of geometric primitives in techniques like kd-trees. -# -# An optimal bounding box is a common data object which provides the best, i.e. -# most tightly fitting box about an arbitrary object. In general such boxes are -# rotated. Other than in 3D dimensions, the rotation calipher method offers -# a rigorous approach to compute an optimal bounding box to a point set in 2D. -# -# -# -# -# To specify which parallelogram is a rectangle. -# -# -# -# -# -# -# -# Only to be used if is_rectangle is present. In this case, this field -# describes whether parallelograms are rectangles whose primary edges -# are parallel to the axes of the coordinate system. -# -# -# -# -# -# -# -# -# -# Combined storage of all primitives of all parallelograms. -# -# -# -# -# Individual storage of each parallelogram. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_point_set.yaml b/contributed_definitions/nyaml/NXcg_point_set.yaml deleted file mode 100644 index 6002825cfb..0000000000 --- a/contributed_definitions/nyaml/NXcg_point_set.yaml +++ /dev/null @@ -1,139 +0,0 @@ -category: base -doc: | - Computational geometry description of a set of points. - - Points may have an associated time value. Users are advised though to store - time data of point sets rather as instances of time events, where for each - point in time there is an :ref:`NXcg_point_set` instance which specifies the - points' locations. - - This is a frequent situation in experiments and computer simulations, where - positions of points are taken at the same point in time (real time or - simulated physical time). Thereby, the storage of redundant time stamp - information per point is considered as obsolete. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality. - c: | - The cardinality of the set, i.e. the number of points. -type: group -NXcg_point_set(NXcg_primitive_set): - position(NX_NUMBER): - unit: NX_ANY - doc: | - Coordinates of the points. - dimensions: - rank: 2 - dim: [[1, c], [2, d]] - time(NX_NUMBER): - unit: NX_TIME - doc: | - (Elapsed) time for each point. - - If the field time is needed contextualize the time_offset relative to which - time values are defined. Alternative store timestamp. - dimensions: - rank: 1 - dim: [[1, c]] - timestamp(NX_DATE_TIME): - doc: | - ISO8601 with local time zone offset for each point. - dimensions: - rank: 1 - dim: [[1, c]] - time_offset(NX_DATE_TIME): - doc: | - ISO8601 with local time zone offset that serves as the reference - for values in the field time. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# be22e63c2fd9ed8da282eadabf22fba5ec6165bf6daa856c90cbc48abb741117 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality. -# -# -# -# -# The cardinality of the set, i.e. the number of points. -# -# -# -# -# Computational geometry description of a set of points. -# -# Points may have an associated time value. Users are advised though to store -# time data of point sets rather as instances of time events, where for each -# point in time there is an :ref:`NXcg_point_set` instance which specifies the -# points' locations. -# -# This is a frequent situation in experiments and computer simulations, where -# positions of points are taken at the same point in time (real time or -# simulated physical time). Thereby, the storage of redundant time stamp -# information per point is considered as obsolete. -# -# -# -# Coordinates of the points. -# -# -# -# -# -# -# -# -# (Elapsed) time for each point. -# -# If the field time is needed contextualize the time_offset relative to which -# time values are defined. Alternative store timestamp. -# -# -# -# -# -# -# -# ISO8601 with local time zone offset for each point. -# -# -# -# -# -# -# -# ISO8601 with local time zone offset that serves as the reference -# for values in the field time. -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_polygon_set.yaml b/contributed_definitions/nyaml/NXcg_polygon_set.yaml deleted file mode 100644 index 8a76034eac..0000000000 --- a/contributed_definitions/nyaml/NXcg_polygon_set.yaml +++ /dev/null @@ -1,224 +0,0 @@ -category: base - -# somewhat redundant as there is NXoff_geometry but easier to understand -doc: | - Computational geometry description of a set of polygons in Euclidean space. - - Polygons are specialized polylines: - - * A polygon is a geometric primitive that is bounded by a closed polyline - * All vertices of this polyline lay in the d-1 dimensional plane. - whereas vertices of a polyline do not necessarily lay on a plane. - * A polygon has at least three vertices. - - Each polygon is built from a sequence of vertices (points with identifiers). - The members of a set of polygons may have a different number of vertices. - Sometimes a collection/set of polygons is referred to as a soup of polygons. - - As three-dimensional objects, a set of polygons can be used to define the - hull of what is effectively a polyhedron; however users are advised to use - the specific :ref:`NXcg_polyhedron_set` base class if they wish to describe closed - polyhedra. Even more general complexes can be thought of. An example are the - so-called piecewise-linear complexes used in the TetGen library. - - As these complexes can have holes though, polyhedra without holes are one - subclass of such complexes, users should rather design an own - base class e.g. NXcg_polytope_set to describe such even more - complex primitives instead of abusing this base class for such purposes. - -# Users can take advantage of NXcg_polygon_set to describe such complexes -# when using the defines_plc and related topological and boundary constraint -# descriptors. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality, which has to be either 2 or 3. - c: | - The cardinality of the set, i.e. the number of polygons. - - # n_unique: Number of unique points supporting the polygons. - n_total: | - The total number of vertices when visiting every polygon. -type: group -NXcg_polygon_set(NXcg_primitive_set): - number_of_total_vertices(NX_INT): - unit: NX_UNITLESS - doc: | - The total number of vertices in the set. - - # detailed mesh-based representation - polygons(NXcg_face_list_data_structure): - doc: | - Combined storage of all primitives of all polygons. - polygonID(NXcg_face_list_data_structure): - doc: | - Individual storage of the mesh of each polygon. - polygon_half_edgeID(NXcg_half_edge_data_structure): - doc: | - Individual storage of each polygon as a graph. - - # properties of the polygon primitives - edge_length(NX_NUMBER): - unit: NX_LENGTH - doc: | - For each polygon its accumulated length along its edges. - dimensions: - rank: 1 - dim: [[1, c]] - interior_angle(NX_NUMBER): - unit: NX_ANGLE - doc: | - Interior angles for each polygon. There are as many values per polygon - as the are number_of_vertices. - The angle is the angle at the specific vertex, i.e. between the adjoining - edges of the vertex according to the sequence in the polygons array. - Usually, the winding_order field is required to interpret the value. - dimensions: - rank: 1 - dim: [[1, n_total]] - shape(NX_INT): - unit: NX_UNITLESS - doc: | - Curvature type: - - * 0 - unspecified, - * 1 - convex, - * 2 - concave - dimensions: - rank: 1 - dim: [[1, c]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# fef7bf429d95f85623fcce20ff374aff3bfbe48ddab0ecd325a49b49a95d16c6 -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality, which has to be either 2 or 3. -# -# -# -# -# The cardinality of the set, i.e. the number of polygons. -# -# -# -# -# -# The total number of vertices when visiting every polygon. -# -# -# -# -# -# Computational geometry description of a set of polygons in Euclidean space. -# -# Polygons are specialized polylines: -# -# * A polygon is a geometric primitive that is bounded by a closed polyline -# * All vertices of this polyline lay in the d-1 dimensional plane. -# whereas vertices of a polyline do not necessarily lay on a plane. -# * A polygon has at least three vertices. -# -# Each polygon is built from a sequence of vertices (points with identifiers). -# The members of a set of polygons may have a different number of vertices. -# Sometimes a collection/set of polygons is referred to as a soup of polygons. -# -# As three-dimensional objects, a set of polygons can be used to define the -# hull of what is effectively a polyhedron; however users are advised to use -# the specific :ref:`NXcg_polyhedron_set` base class if they wish to describe closed -# polyhedra. Even more general complexes can be thought of. An example are the -# so-called piecewise-linear complexes used in the TetGen library. -# -# As these complexes can have holes though, polyhedra without holes are one -# subclass of such complexes, users should rather design an own -# base class e.g. NXcg_polytope_set to describe such even more -# complex primitives instead of abusing this base class for such purposes. -# -# -# -# The total number of vertices in the set. -# -# -# -# -# -# Combined storage of all primitives of all polygons. -# -# -# -# -# Individual storage of the mesh of each polygon. -# -# -# -# -# Individual storage of each polygon as a graph. -# -# -# -# -# -# For each polygon its accumulated length along its edges. -# -# -# -# -# -# -# -# Interior angles for each polygon. There are as many values per polygon -# as the are number_of_vertices. -# The angle is the angle at the specific vertex, i.e. between the adjoining -# edges of the vertex according to the sequence in the polygons array. -# Usually, the winding_order field is required to interpret the value. -# -# -# -# -# -# -# -# Curvature type: -# -# * 0 - unspecified, -# * 1 - convex, -# * 2 - concave -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_polyhedron_set.yaml b/contributed_definitions/nyaml/NXcg_polyhedron_set.yaml deleted file mode 100644 index e1edf63381..0000000000 --- a/contributed_definitions/nyaml/NXcg_polyhedron_set.yaml +++ /dev/null @@ -1,188 +0,0 @@ -category: base -doc: | - Computational geometry description of a set of polyhedra in Euclidean space. - - Polyhedra or so-called cells (especially in the convex of tessellations) are - constructed from polygon meshes. Polyhedra may make contact to allow a usage - of this base class for a description of tessellations. - - For the description of more complicated manifolds and especially for polyhedra - with holes, users are advised to check if their particular needs are described - by creating customized instances of an :ref:`NXcg_polygon_set`. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - c: | - The cardinality of the set, i.e. the number of polyhedra. - n_e_total: | - The total number of edges for all polyhedra. - n_f_total: | - The total number of faces for all polyhedra. - -# it is useful to define own base classes for frequently used classes -# a polyhedron is a specific polytope in 3d, do we need -# higher-dimensional polytopes? that could be useful for simplicies though -# as they are used in numerics etc. maybe reach out here to our friends -# from MarDI, for now let's assume we do not need polytopes for d > 3 -# NeXus already supports polyhedra via NXoff_geometry -# the here proposed base class extends the capabilities to qualifiers of -# polyhedra and also half_edge_data_structures that can be useful -# for clean graph-based descriptions of polyhedra. -type: group -NXcg_polyhedron_set(NXcg_primitive_set): - - # qualifiers and properties of polyhedra - number_of_faces(NX_INT): - unit: NX_UNITLESS - doc: | - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. - dimensions: - rank: 1 - dim: [[1, c]] - face_area(NX_NUMBER): - unit: NX_AREA - doc: | - Area of each of faces. - dimensions: - rank: 1 - dim: [[1, n_f_total]] - number_of_edges(NX_INT): - doc: | - The number of edges for each polyhedron. Edges of adjoining polyhedra - are counterd for each polyhedron. - edge_length(NX_NUMBER): - unit: NX_LENGTH - doc: | - Length of each edge. - dimensions: - rank: 1 - dim: [[1, n_e_total]] - - # detailed mesh-based representation - polyhedra(NXcg_face_list_data_structure): - doc: | - Combined storage of all primitives of all polyhedra. - polyhedronID(NXcg_face_list_data_structure): - doc: | - Individual storage of each polyhedron. - polyhedron_half_edgeID(NXcg_half_edge_data_structure): - doc: | - Individual storage of each polygon as a graph. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 7c6eaa559e1c375f053c0ff374251a2d70e14e7433def8e4425d55c747c69aba -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The cardinality of the set, i.e. the number of polyhedra. -# -# -# -# -# The total number of edges for all polyhedra. -# -# -# -# -# The total number of faces for all polyhedra. -# -# -# -# -# Computational geometry description of a set of polyhedra in Euclidean space. -# -# Polyhedra or so-called cells (especially in the convex of tessellations) are -# constructed from polygon meshes. Polyhedra may make contact to allow a usage -# of this base class for a description of tessellations. -# -# For the description of more complicated manifolds and especially for polyhedra -# with holes, users are advised to check if their particular needs are described -# by creating customized instances of an :ref:`NXcg_polygon_set`. -# -# -# -# -# The number of faces for each polyhedron. Faces of adjoining polyhedra -# are counted for each polyhedron. -# -# -# -# -# -# -# -# Area of each of faces. -# -# -# -# -# -# -# -# The number of edges for each polyhedron. Edges of adjoining polyhedra -# are counterd for each polyhedron. -# -# -# -# -# Length of each edge. -# -# -# -# -# -# -# -# -# Combined storage of all primitives of all polyhedra. -# -# -# -# -# Individual storage of each polyhedron. -# -# -# -# -# Individual storage of each polygon as a graph. -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_polyline_set.yaml b/contributed_definitions/nyaml/NXcg_polyline_set.yaml deleted file mode 100644 index 856234915e..0000000000 --- a/contributed_definitions/nyaml/NXcg_polyline_set.yaml +++ /dev/null @@ -1,237 +0,0 @@ -category: base -doc: | - Computational geometry description of a set of polylines. - - Each polyline is built from a sequence of vertices (points with identifiers). - Each polyline must have a start and an end point. - The sequence describes the positive traversal along the polyline when - walking from the first to the last vertex. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality, which has to be at least 1. - c: | - The cardinality of the set, i.e. the number of polylines. - - # n_unique: The number of unique vertices supporting the polyline. - # multiple vertices possible with the same point coordinates but different names. - n_v: | - The number of vertices, supporting the polylines. - n_total: | - The total number of vertices traversed when visiting every polyline. -type: group -NXcg_polyline_set(NXcg_primitive_set): - number_of_unique_vertices(NX_POSINT): - unit: NX_UNITLESS - doc: | - The total number of vertices that have different positions. - number_of_total_vertices(NX_INT): - unit: NX_UNITLESS - doc: | - The total number of vertices, irrespective of their eventual uniqueness. - number_of_vertices(NX_INT): - unit: NX_UNITLESS - doc: | - The total number of vertices of each polyline, irrespectively - whether vertices are shared by vertices or not. - See the docstring for polylines for further details about how - a set with different polyline members should be stored. - dimensions: - rank: 1 - dim: [[1, c]] - - # Users are encouraged to reduce the vertex set to the unique vertices. - # Unique means not necessarily unique in position only but also unique in - # identifier. In fact, it is possible to distinguish two vertices as two when - # they share the same position in space but have different identifiers. - vertices(NX_NUMBER): - unit: NX_ANY - doc: | - Positions of the vertices which support the members of the polyline set. - - Users are encouraged to reduce the vertices to unique positions and vertices - as this often supports with storing geometry data more efficiently. - It is also possible though to store the vertex positions naively - in which case vertices_are_unique is likely False. - Naively, here means that one stores each vertex of a triangle mesh - even though many vertices are shared between triangles and thus - storing multiple copies of their positions is redundant. - dimensions: - rank: 2 - dim: [[1, n_v], [2, d]] - - # alternatively we may store the actual vertices in an instance of - # NXcg_point_set and (e.g. to promote compact storage of information and primitives) - # and then use - vertices_are_unique(NX_BOOLEAN): - doc: | - If true indicates that the vertices are all placed at different - positions and have different identifiers, i.e. no points overlap - or are counted several times. - polylines(NX_INT): - unit: NX_UNITLESS - doc: | - Sequence of identifier for vertices how they build each polyline. - - A trivial example is a set with two polylines with three vertices each. - If the polylines meet in a junction, say the second vertex is shared - and marking the junction between the two polylines, it is possible that - there are only five unique positions. This suggests to store five - unique vertices. - - A non-trivial example is a set with several polylines. Assume that each - has a different number of vertices. The array stores the identifier of - the vertices in the sequence how the polylines are visited: - - The first entry is the identifier of the first vertex of the first polyline, - followed by the second vertex of the first polyline, until the last vertex - of the first polyline. - Thereafter, the first vertex of the second polyline, and so on and so forth. - Using the (cumulated) counts in number_of_vertices, the vertices of the - n-th polyline can be accessed on the following array index interval: - :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - dimensions: - rank: 1 - dim: [[1, n_total]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# eefaf5efe859a45e462b7b7bc0d1f33ac0f9401a8b8ce4b416030d05b69cdfe4 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality, which has to be at least 1. -# -# -# -# -# The cardinality of the set, i.e. the number of polylines. -# -# -# -# -# -# The number of vertices, supporting the polylines. -# -# -# -# -# The total number of vertices traversed when visiting every polyline. -# -# -# -# -# Computational geometry description of a set of polylines. -# -# Each polyline is built from a sequence of vertices (points with identifiers). -# Each polyline must have a start and an end point. -# The sequence describes the positive traversal along the polyline when -# walking from the first to the last vertex. -# -# -# -# The total number of vertices that have different positions. -# -# -# -# -# The total number of vertices, irrespective of their eventual uniqueness. -# -# -# -# -# The total number of vertices of each polyline, irrespectively -# whether vertices are shared by vertices or not. -# See the docstring for polylines for further details about how -# a set with different polyline members should be stored. -# -# -# -# -# -# -# -# -# Positions of the vertices which support the members of the polyline set. -# -# Users are encouraged to reduce the vertices to unique positions and vertices -# as this often supports with storing geometry data more efficiently. -# It is also possible though to store the vertex positions naively -# in which case vertices_are_unique is likely False. -# Naively, here means that one stores each vertex of a triangle mesh -# even though many vertices are shared between triangles and thus -# storing multiple copies of their positions is redundant. -# -# -# -# -# -# -# -# -# -# If true indicates that the vertices are all placed at different -# positions and have different identifiers, i.e. no points overlap -# or are counted several times. -# -# -# -# -# Sequence of identifier for vertices how they build each polyline. -# -# A trivial example is a set with two polylines with three vertices each. -# If the polylines meet in a junction, say the second vertex is shared -# and marking the junction between the two polylines, it is possible that -# there are only five unique positions. This suggests to store five -# unique vertices. -# -# A non-trivial example is a set with several polylines. Assume that each -# has a different number of vertices. The array stores the identifier of -# the vertices in the sequence how the polylines are visited: -# -# The first entry is the identifier of the first vertex of the first polyline, -# followed by the second vertex of the first polyline, until the last vertex -# of the first polyline. -# Thereafter, the first vertex of the second polyline, and so on and so forth. -# Using the (cumulated) counts in number_of_vertices, the vertices of the -# n-th polyline can be accessed on the following array index interval: -# :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml deleted file mode 100644 index 7188df51e5..0000000000 --- a/contributed_definitions/nyaml/NXcg_primitive_set.yaml +++ /dev/null @@ -1,375 +0,0 @@ -category: base -doc: | - Computational geometry description of a set of primitives in Euclidean space. - - Primitives must neither be degenerated nor self-intersect. - Individual primitives can differ in their properties (e.g. size, shape, rotation). - -# this base class defines common fields and properties of geometric primitives -# more complex primitive sets like NXcg_cylinder_set are considered specializations -# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set -# defines. This is an action of compositing an information set; an act of inheriting -# TODO:: many properties of non-degenerate primitives are in the number set -# R+ instead of in R+0 but currently NeXus does not allow for such value range -# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT -# but there is no say NX_FLOAT+0 -# MK::but in computational geometry numerical precision matters as it defines -# whether objects numerically intersect or not and thus it can make a real difference -# if one stores triangles with 16, 32, or 64 bit precision, however: -# are two triangle_set instance A and B no longer conceptually triangle sets -# because A stores the positions of vertices using int8 while B stores such using float64 ? -# we here assume that we still conceptually talk that A and B are triangle sets -# but this brings at the level of the application definition the problem that if the -# precision is not properly constrainted a consuming application will not obtain -# the instances of the concept triangle_set with relevant high enough precision -# and thus neither the base class nor the application definition is specific enough -# for what it was designed in the first place - be specific about the requirements -# on your data... -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the space. - c: | - The cardinality of the set, i.e. the number of members. -type: group -NXcg_primitive_set(NXobject): - - # individual specializations like NXcg_polyline_set typically overwrite - # the meaning of the depends_on concept to build consistent inference chains - # to enable an instantiation of the actual geometric primitives - depends_on(NX_CHAR): - doc: | - Reference to an instance of :ref:`NXcoordinate_system` in which these primitives - are defined. - dimensionality(NX_POSINT): - unit: NX_UNITLESS - doc: | - The dimensionality of the primitive set. - enumeration: [1, 2, 3] - cardinality(NX_POSINT): - unit: NX_UNITLESS - doc: | - The cardinality of the primitive set. - identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer offset whereby the identifier of the first member - of the set differs from zero. - - Identifiers can be defined either implicitly or explicitly. - For implicit indexing identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. - - Therefore, implicit identifier are completely defined by the value of - identifier_offset and cardinality. For example if identifier run from - -2 to 3 the value for identifier_offset is -2. - - For explicit indexing the field identifier has to be used. - Fortran-/Matlab- and C-/Python-style indexing have specific implicit - identifier conventions where identifier_offset is 1 and 0 respectively. - identifier(NX_INT): - doc: | - Identifier of each member for explicit indexing. - dimensions: - rank: 1 - dim: [[1, c]] - center(NX_NUMBER): - unit: NX_ANY - doc: | - The center of mass position of each primitive. - dimensions: - rank: 2 - dim: [[1, c], [2, d]] - - # a depends_on to define in which coordinate system - is_center_of_mass(NX_BOOLEAN): - doc: | - True if the center is a center of mass. - dimensions: - rank: 1 - dim: [[1, c]] - shape(NX_NUMBER): - unit: NX_LENGTH - doc: | - A qualitative description of the shape of each primitive. - dimensions: - rank: 2 - dim: [[1, c], [2, d]] - length(NX_NUMBER): - unit: NX_LENGTH - doc: | - Qualifier for the length of characteristic features of the primitive. - - Often the term length is associated with the assumption that one - edge is parallel to an axis of the coordinate system. - dimensions: - rank: 1 - dim: [[1, c]] - width(NX_NUMBER): - unit: NX_LENGTH - doc: | - Qualifier often used to describe the length of one characteristic edge - within the coordinate system. - dimensions: - rank: 1 - dim: [[1, c]] - is_closed(NX_BOOLEAN): - doc: | - True if primitive is closed such that it has properties like area or volume. - dimensions: - rank: 1 - dim: [[1, c]] - volume(NX_NUMBER): - unit: NX_VOLUME - doc: | - Volume of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - dimensions: - rank: 1 - dim: [[1, c]] - area(NX_NUMBER): - unit: NX_AREA - doc: | - Alias for surface_area of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - dimensions: - rank: 1 - dim: [[1, c]] - orientation(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - Direction unit vector which points along the - longest principal axis of each primitive. - - Use the depends_on attribute to specify in which coordinate system - these direction unit vectors are defined. - dimensions: - rank: 2 - dim: [[1, c], [2, d]] - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - - # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) - # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) - # but then one would not give any hint at the base class level how to name - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 55f7920f38d9fc75b0487808a83dbd2f35fb901ea2d16ce26c4848e8b5dcf150 -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality of the space. -# -# -# -# -# The cardinality of the set, i.e. the number of members. -# -# -# -# -# Computational geometry description of a set of primitives in Euclidean space. -# -# Primitives must neither be degenerated nor self-intersect. -# Individual primitives can differ in their properties (e.g. size, shape, rotation). -# -# -# -# -# Reference to an instance of :ref:`NXcoordinate_system` in which these primitives -# are defined. -# -# -# -# -# The dimensionality of the primitive set. -# -# -# -# -# -# -# -# -# -# The cardinality of the primitive set. -# -# -# -# -# Integer offset whereby the identifier of the first member -# of the set differs from zero. -# -# Identifiers can be defined either implicitly or explicitly. -# For implicit indexing identifiers are defined on the interval -# :math:`[identifier\_offset, identifier\_offset + c - 1]`. -# -# Therefore, implicit identifier are completely defined by the value of -# identifier_offset and cardinality. For example if identifier run from -# -2 to 3 the value for identifier_offset is -2. -# -# For explicit indexing the field identifier has to be used. -# Fortran-/Matlab- and C-/Python-style indexing have specific implicit -# identifier conventions where identifier_offset is 1 and 0 respectively. -# -# -# -# -# Identifier of each member for explicit indexing. -# -# -# -# -# -# -# -# The center of mass position of each primitive. -# -# -# -# -# -# -# -# -# -# True if the center is a center of mass. -# -# -# -# -# -# -# -# A qualitative description of the shape of each primitive. -# -# -# -# -# -# -# -# -# Qualifier for the length of characteristic features of the primitive. -# -# Often the term length is associated with the assumption that one -# edge is parallel to an axis of the coordinate system. -# -# -# -# -# -# -# -# Qualifier often used to describe the length of one characteristic edge -# within the coordinate system. -# -# -# -# -# -# -# -# True if primitive is closed such that it has properties like area or volume. -# -# -# -# -# -# -# -# Volume of each primitive. -# -# Set to NaN if does not apply for primitives for which is_closed is False. -# -# -# -# -# -# -# -# Alias for surface_area of each primitive. -# -# Set to NaN if does not apply for primitives for which is_closed is False. -# -# -# -# -# -# -# -# Direction unit vector which points along the -# longest principal axis of each primitive. -# -# Use the depends_on attribute to specify in which coordinate system -# these direction unit vectors are defined. -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_roi_set.yaml b/contributed_definitions/nyaml/NXcg_roi_set.yaml deleted file mode 100644 index 7410313756..0000000000 --- a/contributed_definitions/nyaml/NXcg_roi_set.yaml +++ /dev/null @@ -1,93 +0,0 @@ -category: base -doc: | - Base class for a region-of-interest (ROI) bound by geometric primitives. - - So-called region-of-interest(s) (ROIs) are typically used to describe a - region in space (and time) where an observation is made or for which - a computer simulation is performed with given boundary conditions. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - Use the depends_on fields of the respective specialized - :ref:`NXcg_primitive_set` base class surplus - :ref:`NXcoordinate_system_set` with at least one instance of - :ref:`NXcoordinate_system` to define explicitly the reference frame in - which the primitives are defined. Alternatively, although - disencouraged, one may use one :ref:`NXcoordinate_system_set` with - with only one :ref:`NXcoordinate_system` in the application definition - to specify implicitly in which reference frame the primitives are - defined. If none of these two possibilities is used all primitives - are assumed defined in the McStas coordinate system. - -# eventually redundant NXsolid_geometry? -type: group -NXcg_roi_set(NXobject): - (NXcg_sphere_set): - (NXcg_ellipsoid_set): - (NXcg_cylinder_set): - (NXcg_parallelogram_set): - (NXcg_hexahedron_set): - (NXcg_polyhedron_set): - - # how to handle cases where multiple primitives should be included? - # see comment to NXcg_triangle_set roi - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d6f52b5de8da4a3970ac6c87ffb8370c01cb55ece78b50303bf85cbdb8168d27 -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# Use the depends_on fields of the respective specialized -# :ref:`NXcg_primitive_set` base class surplus -# :ref:`NXcoordinate_system_set` with at least one instance of -# :ref:`NXcoordinate_system` to define explicitly the reference frame in -# which the primitives are defined. Alternatively, although -# disencouraged, one may use one :ref:`NXcoordinate_system_set` with -# with only one :ref:`NXcoordinate_system` in the application definition -# to specify implicitly in which reference frame the primitives are -# defined. If none of these two possibilities is used all primitives -# are assumed defined in the McStas coordinate system. -# -# -# -# Base class for a region-of-interest (ROI) bound by geometric primitives. -# -# So-called region-of-interest(s) (ROIs) are typically used to describe a -# region in space (and time) where an observation is made or for which -# a computer simulation is performed with given boundary conditions. -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_sphere_set.yaml b/contributed_definitions/nyaml/NXcg_sphere_set.yaml deleted file mode 100644 index 9ed6e9b8d1..0000000000 --- a/contributed_definitions/nyaml/NXcg_sphere_set.yaml +++ /dev/null @@ -1,92 +0,0 @@ -category: base -doc: | - Computational geometry description of a set of spheres. - - Each sphere can have a different radius but all need to have finite volume. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality, which has to be at least 2. - c: | - The cardinality of the set, i.e. the number of circles or spheres. - -# redundant as there is NXcsg, and NXquadric but easier to understand -type: group -NXcg_sphere_set(NXcg_ellipsoid_set): - radius(NX_NUMBER): - unit: NX_LENGTH - doc: | - In the case that all spheres have the same radius. - radii(NX_NUMBER): - unit: NX_LENGTH - doc: | - In the case that spheres have different radius use this - instead of the radius field. - dimensions: - rank: 1 - dim: [[1, c]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4244bce7df1a9da99adba31938a2347fc3575c0427819ef5fb02dde22d2e30d6 -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality, which has to be at least 2. -# -# -# -# -# The cardinality of the set, i.e. the number of circles or spheres. -# -# -# -# -# Computational geometry description of a set of spheres. -# -# Each sphere can have a different radius but all need to have finite volume. -# -# -# -# In the case that all spheres have the same radius. -# -# -# -# -# In the case that spheres have different radius use this -# instead of the radius field. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml b/contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml deleted file mode 100644 index 8a88da4d47..0000000000 --- a/contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml +++ /dev/null @@ -1,138 +0,0 @@ -category: base -doc: | - Computational geometry description of a set of tetrahedra. - - Among hexahedral elements, tetrahedral elements are one of the most - frequently used geometric primitive for meshing and describing volumetric - objects in continuum-field simulations. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - c: | - The cardinality of the set, i.e. the number of tetrahedra. -type: group -NXcg_tetrahedron_set(NXcg_primitive_set): - - # qualifiers and properties of tetrahedra - face_area(NX_NUMBER): - unit: NX_AREA - doc: | - Area of each of the four triangular faces of each tetrahedron. - dimensions: - rank: 2 - dim: [[1, c], [2, 4]] - edge_length(NX_NUMBER): - unit: NX_LENGTH - doc: | - Length of each edge of each tetrahedron. - dimensions: - rank: 2 - dim: [[1, c], [2, 6]] - - # substantially more detailed descriptors of the shape, the mesh - # currently not used should be discussed as sequence might not be clear to everybody - # interior_angle(NX_NUMBER): - # doc: | - # Interior angle values for each tetrahedron. - # The quadruplet of angles is a sequence following the order of the vertices. - # The angle is the angle at the specific vertex. - # The sequence of the vertices follows their definition in tetrahedra. - # detailed mesh-based representation - tetrahedra(NXcg_face_list_data_structure): - doc: | - Combined storage of all primitives of all tetrahedra. - tetrahedronID(NXcg_face_list_data_structure): - doc: | - Individual storage of each tetrahedron. - tetrahedron_half_edgeID(NXcg_half_edge_data_structure): - doc: | - Individual storage of each tetrahedron as a graph. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 9af8304da5812e9850077983105c5c0baffa7b6e09f1592ab4b4364db00a8332 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The cardinality of the set, i.e. the number of tetrahedra. -# -# -# -# -# Computational geometry description of a set of tetrahedra. -# -# Among hexahedral elements, tetrahedral elements are one of the most -# frequently used geometric primitive for meshing and describing volumetric -# objects in continuum-field simulations. -# -# -# -# -# Area of each of the four triangular faces of each tetrahedron. -# -# -# -# -# -# -# -# -# Length of each edge of each tetrahedron. -# -# -# -# -# -# -# -# -# -# Combined storage of all primitives of all tetrahedra. -# -# -# -# -# Individual storage of each tetrahedron. -# -# -# -# -# Individual storage of each tetrahedron as a graph. -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_triangle_set.yaml b/contributed_definitions/nyaml/NXcg_triangle_set.yaml deleted file mode 100644 index 29fec60e2a..0000000000 --- a/contributed_definitions/nyaml/NXcg_triangle_set.yaml +++ /dev/null @@ -1,155 +0,0 @@ -category: base -doc: | - Computational geometry description of a set of triangles. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality, which has to be at least 2. - c: | - The cardinality of the set, i.e. the number of triangles. - n_unique: | - The number of unique vertices supporting the triangles. -type: group -NXcg_triangle_set(NXcg_primitive_set): - number_of_unique_vertices(NX_INT): - unit: NX_UNITLESS - doc: | - Number of unique vertices in the triangle set. - triangles(NXcg_face_list_data_structure): - doc: | - Combined storage of all primitives of all triangles. - - This description resembles the typical representation of primitives - in file formats such as OFF, PLY, VTK, or STL. - triangleID(NXcg_face_list_data_structure): - doc: | - Individual storage of each triangle. - Users are advised that using such individual storage of primitives - may be less storage efficient than creating a combined storage. - - ##MK::considered too trivial: - # triangle_half_edgeID(NXcg_half_edge_data_structure): - # doc: | - # Individual storage of each triangle as a graph. - # properties of triangles - edge_length(NX_NUMBER): - unit: NX_LENGTH - doc: | - Length of the edges of each triangle. - - For each triangle values are reported via traversing - the vertices in the sequence as these are defined. - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] - interior_angle(NX_NUMBER): - unit: NX_ANGLE - doc: | - Interior angles of each triangle. - - For each triangle values are reported for the angle opposite - to the respective edges in the sequence how vertices are defined. - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# ae9612828131a3d5dbc9dbec38cca6a904c1284b9c5bd2c45ba2a82f82a26c41 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality, which has to be at least 2. -# -# -# -# -# The cardinality of the set, i.e. the number of triangles. -# -# -# -# -# The number of unique vertices supporting the triangles. -# -# -# -# -# Computational geometry description of a set of triangles. -# -# -# -# Number of unique vertices in the triangle set. -# -# -# -# -# Combined storage of all primitives of all triangles. -# -# This description resembles the typical representation of primitives -# in file formats such as OFF, PLY, VTK, or STL. -# -# -# -# -# Individual storage of each triangle. -# Users are advised that using such individual storage of primitives -# may be less storage efficient than creating a combined storage. -# -# -# -# -# -# Length of the edges of each triangle. -# -# For each triangle values are reported via traversing -# the vertices in the sequence as these are defined. -# -# -# -# -# -# -# -# -# Interior angles of each triangle. -# -# For each triangle values are reported for the angle opposite -# to the respective edges in the sequence how vertices are defined. -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml b/contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml deleted file mode 100644 index c834b7f89f..0000000000 --- a/contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml +++ /dev/null @@ -1,60 +0,0 @@ -category: base -doc: | - Computational geometry description of a mesh of triangles. - - The mesh may be self-intersecting and have holes but the - triangles used must not be degenerated. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXcg_triangulated_surface_mesh(NXcg_triangle_set): - (NXcg_half_edge_data_structure): - doc: | - A graph-based approach to describe the mesh when it is also desired - to perform topological processing or analyses on the mesh. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 51a205f7bbac0684cc5a57d15ae2b74b8bbce829cf9a321dfa64349370e7972b -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Computational geometry description of a mesh of triangles. -# -# The mesh may be self-intersecting and have holes but the -# triangles used must not be degenerated. -# -# -# -# A graph-based approach to describe the mesh when it is also desired -# to perform topological processing or analyses on the mesh. -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_unit_normal_set.yaml b/contributed_definitions/nyaml/NXcg_unit_normal_set.yaml deleted file mode 100644 index 8ebac1851b..0000000000 --- a/contributed_definitions/nyaml/NXcg_unit_normal_set.yaml +++ /dev/null @@ -1,120 +0,0 @@ -category: base -doc: | - Computational geometry description of a set of (oriented) unit normal vectors. - - Store normal vector information as properties of primitives. - Use only only as a child of an instance of :ref:`NXcg_primitive_set` - so that this instance acts as the parent to define a context. - -# eventually remove this base class and make normal vector a property of the primitive -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality, which has to be at least 2. - c: | - The cardinality of the set, i.e. the number of unit normals. - -# the benefit of NXcg_point_set is that the origin is 0 by default -# how to resolve the association between the unit normal and its associated primitive? -# rather make this a set of vectors, irrespective whether these are unit or not -type: group -NXcg_unit_normal_set(NXobject): - normals(NX_NUMBER): - unit: NX_LENGTH - doc: | - Direction of each normal - a unit normal. - dimensions: - rank: 2 - dim: [[1, c], [2, d]] - orientation(NX_INT): - unit: NX_UNITLESS - doc: | - Qualifier which details the orientation of each normal vector - in relation to its primitive, assuming the object is viewed - from a position outside the object. - - * 0 - undefined - * 1 - outer unit normal vector - * 2 - inner unit normal vector - dimensions: - rank: 1 - dim: [[1, c]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 7e75ce150a834481da5994ba201eb5582c9fdb4862f5e6bf10f2957f07d9db5d -# -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality, which has to be at least 2. -# -# -# -# -# The cardinality of the set, i.e. the number of unit normals. -# -# -# -# -# Computational geometry description of a set of (oriented) unit normal vectors. -# -# Store normal vector information as properties of primitives. -# Use only only as a child of an instance of :ref:`NXcg_primitive_set` -# so that this instance acts as the parent to define a context. -# -# -# -# Direction of each normal - a unit normal. -# -# -# -# -# -# -# -# -# Qualifier which details the orientation of each normal vector -# in relation to its primitive, assuming the object is viewed -# from a position outside the object. -# -# * 0 - undefined -# * 1 - outer unit normal vector -# * 2 - inner unit normal vector -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXchamber.yaml b/contributed_definitions/nyaml/NXchamber.yaml deleted file mode 100644 index 758353a101..0000000000 --- a/contributed_definitions/nyaml/NXchamber.yaml +++ /dev/null @@ -1,58 +0,0 @@ -category: base -doc: | - Base class for a chamber in an instrument that stores real or simulated objects. -type: group -NXchamber(NXobject): - name(NX_CHAR): - doc: | - Given name for the chamber of this component e.g. analysis chamber - or buffer chamber, load-lock chamber, microscope column, glove box. - description(NX_CHAR): - doc: | - Free-text field for describing details about the chamber. - For example out of which material was the chamber built. - (NXfabrication): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# fa1953f5766d4e3abc9af3cf08c564f565d7400ab8cfba9ce35502d1ab60a53c -# -# -# -# -# -# Base class for a chamber in an instrument that stores real or simulated objects. -# -# -# -# Given name for the chamber of this component e.g. analysis chamber -# or buffer chamber, load-lock chamber, microscope column, glove box. -# -# -# -# -# Free-text field for describing details about the chamber. -# For example out of which material was the chamber built. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXchemical_composition.yaml b/contributed_definitions/nyaml/NXchemical_composition.yaml deleted file mode 100644 index 4e6d8d4664..0000000000 --- a/contributed_definitions/nyaml/NXchemical_composition.yaml +++ /dev/null @@ -1,110 +0,0 @@ -category: base -doc: | - (Chemical) composition of a sample or a set of things. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n: | - The number of samples or things. -type: group -NXchemical_composition(NXobject): - - # molecule descriptor - # chemical_formula: - # doc: | - # IUPAC chemical formula - total(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Total based on which composition information is normalized. - dimensions: - rank: 1 - dim: [[1, n]] - ION(NXion): - count(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Count or weight which, when divided by total yields the composition - of this element, isotope, molecule or ion. - dimensions: - rank: 1 - dim: [[1, n]] - composition(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - Count divided by total in atom percent. - dimensions: - rank: 1 - dim: [[1, n]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a68d56f7fd6f57632b751ec7d1a2bff2cb15bcdabd540958d7da8b035b086627 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The number of samples or things. -# -# -# -# -# (Chemical) composition of a sample or a set of things. -# -# -# -# -# Total based on which composition information is normalized. -# -# -# -# -# -# -# -# -# Count or weight which, when divided by total yields the composition -# of this element, isotope, molecule or ion. -# -# -# -# -# -# -# -# Count divided by total in atom percent. -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXchemical_process.yaml b/contributed_definitions/nyaml/NXchemical_process.yaml deleted file mode 100644 index 71e07c1abe..0000000000 --- a/contributed_definitions/nyaml/NXchemical_process.yaml +++ /dev/null @@ -1,90 +0,0 @@ -category: base -doc: | - A planned or unplanned process which results in chemical changes (i.e., changes in the chemical bonds) in a specified material. - - Examples include any chemical reactions (addition, subtraction, replacement, ...). -type: group -NXchemical_process(NXobject): - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code (with local time zone offset to UTC information - included) when this process started. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code (with local time zone offset to UTC information - included) when this process ended. - description: - doc: | - Short description of the chemical process. - method: - doc: | - Method by which this process was performed. - notes(NXnote): - doc: | - This can be any data or other descriptor acquired during the chemical process - (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e6324cf3c3e2fa8cbfd0a9d0298aa9fb73740518b31cba75da2366f623111345 -# -# -# -# -# -# A planned or unplanned process which results in chemical changes (i.e., changes in the chemical bonds) in a specified material. -# -# Examples include any chemical reactions (addition, subtraction, replacement, ...). -# -# -# -# ISO 8601 formatted time code (with local time zone offset to UTC information -# included) when this process started. -# -# -# -# -# ISO 8601 formatted time code (with local time zone offset to UTC information -# included) when this process ended. -# -# -# -# -# Short description of the chemical process. -# -# -# -# -# Method by which this process was performed. -# -# -# -# -# This can be any data or other descriptor acquired during the chemical process -# (NXnote allows to add pictures, audio, movies). Alternatively, a -# reference to the location or a unique identifier or other metadata file. In the -# case these are not available, free-text description. -# -# -# diff --git a/contributed_definitions/nyaml/NXcircuit.yaml b/contributed_definitions/nyaml/NXcircuit.yaml deleted file mode 100644 index dbcdd9b4e6..0000000000 --- a/contributed_definitions/nyaml/NXcircuit.yaml +++ /dev/null @@ -1,227 +0,0 @@ -category: base -doc: | - Application definition for circuit devices. -type: group -NXcircuit(NXobject): - hardware(NXfabrication): - doc: | - Hardware type used in circuit, includes hardware manufacturers and type - tunneling_current(NX_NUMBER): - unit: NX_CURRENT - doc: | - The tunneling current between tip and sample after application of bias voltage. - calibration(NX_NUMBER): - doc: | - Calibration of the current measurement (A/V). - offset(NX_NUMBER): - unit: NX_CURRENT - doc: | - Offset of the current measurement. - gain(NX_NUMBER): - doc: | - Proportional relationship between the probe output voltage and the actual - tunneling current when measuring the tunneling current. - channels(NX_CHAR): - doc: | - The scan channels are selected by users (in scan contronaller). - rt_frequency(NX_NUMBER): - unit: NX_FREQUENCY - doc: | - The bandwitdh of the Hardware and/or Software - signals_oversampling(NX_NUMBER): - unit: NX_ANY - doc: | - (Signals Periods) The Signals Period is the rate at which the signals are - transferred to the host computer running the control software. This is usually - lower by a factor of 10 than the sampling rate, because an internal oversampling - of the signal is done on the real time engine. You can reduce the oversampling - down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. - acquisition_period(NX_NUMBER): - unit: NX_TIME - doc: | - Update rate for several processes like History Graph, Auto-Approach, and for - many Programming Interface functions. This is usually set to 20 ms. All - additional timings (7-9) can only be integer multiples of this value. They can - be set to different values, but the actual timing value will be coerced to a - multiple of the Acquisition Period. - animations_period(NX_NUMBER): - unit: NX_TIME - doc: | - Update rate of animated graphical indicators. These are e.g. some graphs & - sliders. A reasonable value is 40 ms (25 updates per second). Increase this - period to reduce the processor load for the graphical user interface, especially - on slow computers. This value is purely a user interface update rate and does - not affect measurements in any way. - indicators_period(NX_NUMBER): - unit: NX_TIME - doc: | - Update rate of digital indicators, e.g. the numbers displayed besides each - slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a - user interface update rate and does not affect measurements in any way. - measurements_period(NX_NUMBER): - unit: NX_TIME - doc: | - The Measurements period is the integration time for precise measurements - (averaging over specified period), mostly used in sweep modules. Examples are - recording of a force-distance curve or a resonance of a cantilever. For fast - measurements with small steps, a value of 40 ms may be reasonable. For normal - use, 300-500 ms is a good value, but for recording a resonance of a high-Q - cantilever, values of several seconds might be necessary. Usually this parameter - doesn’t need to be set from this module; the sweep modules will set this value - according to the sweep timings. - number_of_outputs(NX_INT): - doc: | - Number of output channels - output_mode(NX_CHAR): - doc: | - The user output in each monitor mode. - output_value(NX_NUMBER): - unit: NX_ANY - doc: | - The values for each output channel. - output_name(NX_CHAR): - doc: | - User outputs whose name can be modified in the corresponding module. - output_slew_rate(NX_CHAR): - doc: | - The rate at which the one of the signal changes when ramping to the starting - point. (V/s) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 48b8540164b18fd3947881c9e586339a06655cf585853a58e5e830063350eb7c -# -# -# -# -# -# Application definition for circuit devices. -# -# -# -# Hardware type used in circuit, includes hardware manufacturers and type -# -# -# -# -# The tunneling current between tip and sample after application of bias voltage. -# -# -# -# -# Calibration of the current measurement (A/V). -# -# -# -# -# Offset of the current measurement. -# -# -# -# -# Proportional relationship between the probe output voltage and the actual -# tunneling current when measuring the tunneling current. -# -# -# -# -# The scan channels are selected by users (in scan contronaller). -# -# -# -# -# The bandwitdh of the Hardware and/or Software -# -# -# -# -# (Signals Periods) The Signals Period is the rate at which the signals are -# transferred to the host computer running the control software. This is usually -# lower by a factor of 10 than the sampling rate, because an internal oversampling -# of the signal is done on the real time engine. You can reduce the oversampling -# down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. -# -# -# -# -# Update rate for several processes like History Graph, Auto-Approach, and for -# many Programming Interface functions. This is usually set to 20 ms. All -# additional timings (7-9) can only be integer multiples of this value. They can -# be set to different values, but the actual timing value will be coerced to a -# multiple of the Acquisition Period. -# -# -# -# -# Update rate of animated graphical indicators. These are e.g. some graphs & -# sliders. A reasonable value is 40 ms (25 updates per second). Increase this -# period to reduce the processor load for the graphical user interface, especially -# on slow computers. This value is purely a user interface update rate and does -# not affect measurements in any way. -# -# -# -# -# Update rate of digital indicators, e.g. the numbers displayed besides each -# slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a -# user interface update rate and does not affect measurements in any way. -# -# -# -# -# The Measurements period is the integration time for precise measurements -# (averaging over specified period), mostly used in sweep modules. Examples are -# recording of a force-distance curve or a resonance of a cantilever. For fast -# measurements with small steps, a value of 40 ms may be reasonable. For normal -# use, 300-500 ms is a good value, but for recording a resonance of a high-Q -# cantilever, values of several seconds might be necessary. Usually this parameter -# doesn’t need to be set from this module; the sweep modules will set this value -# according to the sweep timings. -# -# -# -# -# Number of output channels -# -# -# -# -# The user output in each monitor mode. -# -# -# -# -# The values for each output channel. -# -# -# -# -# User outputs whose name can be modified in the corresponding module. -# -# -# -# -# The rate at which the one of the signal changes when ramping to the starting -# point. (V/s) -# -# -# diff --git a/contributed_definitions/nyaml/NXcollectioncolumn.yaml b/contributed_definitions/nyaml/NXcollectioncolumn.yaml deleted file mode 100644 index 775c1d1f3e..0000000000 --- a/contributed_definitions/nyaml/NXcollectioncolumn.yaml +++ /dev/null @@ -1,219 +0,0 @@ -category: base -doc: | - Subclass of NXelectronanalyser to describe the electron collection - column of a photoelectron analyser. -type: group -NXcollectioncolumn(NXobject): - scheme(NX_CHAR): - doc: | - Scheme of the electron collection lens, i.e. angular dispersive, - spatial dispersive, momentum dispersive, non-dispersive, etc. - extractor_voltage(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - Voltage applied to the extractor lens - extractor_current(NX_FLOAT): - unit: NX_CURRENT - doc: | - Current necessary to keep the extractor lens at a set voltage. Variations - indicate leakage, field emission or arc currents to the extractor lens. - working_distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Distance between sample and detector entrance - lens_mode(NX_CHAR): - doc: | - Labelling of the lens setting in use. - projection(NX_CHAR): - doc: | - The space projected in the angularly dispersive directions, real or reciprocal - enumeration: [real, reciprocal] - angular_acceptance(NX_FLOAT): - unit: NX_ANGLE - doc: - - | - Acceptance angle of the collection column. - - | - xref: - spec: ISO 18115-1:2023 - term: 7.4 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:7.4 - spatial_acceptance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Acceptance length or area of the collection column. - magnification(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - The magnification of the electron lens assembly. - depends_on(NX_CHAR): - doc: | - Specifies the position of the collectioncolumn by pointing to the last - transformation in the transformation chain in the NXtransformations group. - (NXtransformations): - doc: | - Collection of axis-based translations and rotations to describe the location and - geometry of the deflector as a component in the instrument. Conventions from the - NXtransformations base class are used. In principle, the McStas coordinate - system is used. The first transformation has to point either to another - component of the system or . (for pointing to the reference frame) to relate it - relative to the experimental setup. Typically, the components of a system should - all be related relative to each other and only one component should relate to - the reference coordinate system. - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - (NXaperture): - doc: | - The size and position of an aperture inserted in the column, e.g. field aperture - or contrast aperture - (NXdeflector): - doc: | - Deflectors in the collection column section - (NXlens_em): - doc: | - Individual lenses in the collection column section - (NXfabrication): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 9d145c8a243e6861798d5d80c027066f3e936167dd52070a15e141238e9331b1 -# -# -# -# -# -# Subclass of NXelectronanalyser to describe the electron collection -# column of a photoelectron analyser. -# -# -# -# Scheme of the electron collection lens, i.e. angular dispersive, -# spatial dispersive, momentum dispersive, non-dispersive, etc. -# -# -# -# -# Voltage applied to the extractor lens -# -# -# -# -# Current necessary to keep the extractor lens at a set voltage. Variations -# indicate leakage, field emission or arc currents to the extractor lens. -# -# -# -# -# Distance between sample and detector entrance -# -# -# -# -# Labelling of the lens setting in use. -# -# -# -# -# The space projected in the angularly dispersive directions, real or reciprocal -# -# -# -# -# -# -# -# -# Acceptance angle of the collection column. -# -# This concept is related to term `7.4`_ of the ISO 18115-1:2023 standard. -# -# .. _7.4: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:7.4 -# -# -# -# -# Acceptance length or area of the collection column. -# -# -# -# -# The magnification of the electron lens assembly. -# -# -# -# -# Specifies the position of the collectioncolumn by pointing to the last -# transformation in the transformation chain in the NXtransformations group. -# -# -# -# -# Collection of axis-based translations and rotations to describe the location and -# geometry of the deflector as a component in the instrument. Conventions from the -# NXtransformations base class are used. In principle, the McStas coordinate -# system is used. The first transformation has to point either to another -# component of the system or . (for pointing to the reference frame) to relate it -# relative to the experimental setup. Typically, the components of a system should -# all be related relative to each other and only one component should relate to -# the reference coordinate system. -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# The size and position of an aperture inserted in the column, e.g. field aperture -# or contrast aperture -# -# -# -# -# Deflectors in the collection column section -# -# -# -# -# Individual lenses in the collection column section -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcomponent.yaml b/contributed_definitions/nyaml/NXcomponent.yaml deleted file mode 100644 index 80c2e9d388..0000000000 --- a/contributed_definitions/nyaml/NXcomponent.yaml +++ /dev/null @@ -1,99 +0,0 @@ -category: base -doc: | - Base class for components of an instrument - real ones or a simulated ones. -type: group -NXcomponent(NXobject): - \@depends_on: - type: NX_CHAR - doc: | - Specifies the position of the component by pointing to the last - transformation in the transformation chain that is defined - via the NXtransformations group. - applied(NX_BOOLEAN): - doc: | - Was the component used? - name(NX_CHAR): - doc: | - Given name - description(NX_CHAR): - doc: | - Ideally, use instances of :ref:`NXidentifier` to point to a resource - that provides further details. - - If such a resource does not exist or should not be used, use this, though - discouraged, free-text. - (NXfabrication): - (NXidentifier): - (NXprogram): - (NXtransformations): - doc: | - Collection of axis-based translations and rotations to describe the - location and geometry of the component in the instrument. - (NXcircuit): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# b78c1fe3dffc7cd9159b6c0f3dce9c85deaecd4f9a80fd712654bff440048a41 -# -# -# -# -# -# Base class for components of an instrument - real ones or a simulated ones. -# -# -# -# Specifies the position of the component by pointing to the last -# transformation in the transformation chain that is defined -# via the NXtransformations group. -# -# -# -# -# Was the component used? -# -# -# -# -# Given name -# -# -# -# -# Ideally, use instances of :ref:`NXidentifier` to point to a resource -# that provides further details. -# -# If such a resource does not exist or should not be used, use this, though -# discouraged, free-text. -# -# -# -# -# -# -# -# Collection of axis-based translations and rotations to describe the -# location and geometry of the component in the instrument. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml deleted file mode 100644 index e903d33ed3..0000000000 --- a/contributed_definitions/nyaml/NXcoordinate_system.yaml +++ /dev/null @@ -1,266 +0,0 @@ -category: base -doc: | - Base class to detail a coordinate system (CS). - - Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as - a member in an :ref:`NXcoordinate_system_set` and the name of the instance - should be this alias. This may support a process whereby jargon when talking - about coordinate systems and conventions may become cleaner for users - because it is not evident for people outside a lab that terms like e.g. - tip space or specimen space refer to the same coordinate system. - This is an example of jargon used in e.g. the field of atom - probe tomography. -type: group -NXcoordinate_system(NXobject): - origin(NX_CHAR): - doc: | - Human-readable field telling where the origin of this CS is. - Exemplar values could be *left corner of the lab bench*, *door-handle* - *pinhole through which the electron beam exists the pole piece*. - *barycenter of the triangle*, *center of mass of the stone*. - - # implementing a proposal for "a common base table" along thoughts like: - # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations - # similar to a place where all transformations are stored - # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 - # enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] - alias(NX_CHAR): - doc: | - An alternative name given to that coordinate system. - type(NX_CHAR): - doc: | - Coordinate system type. - enumeration: [undefined, cartesian] - handedness(NX_CHAR): - doc: | - Handedness of the coordinate system if it is a Cartesian. - enumeration: [undefined, right_handed, left_handed] - x_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the x-axis. - x_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - - # enumeration: [undefined, north, east, south, west, in, out] - x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Base unit vector along the first axis which spans the coordinate system. - This axis is frequently referred to as the x-axis in real space and - the i-axis in reciprocal space. - dimensions: - rank: 1 - dim: [[1, 3]] - y_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the y-axis. - y_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Base unit vector along the second axis which spans the coordinate system. - This axis is frequently referred to as the y-axis in real space and - the j-axis in reciprocal space. - dimensions: - rank: 1 - dim: [[1, 3]] - z_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the z-axis. - z_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - z(NX_NUMBER): - unit: NX_LENGTH - doc: | - Base unit vector along the third axis which spans the coordinate system. - This axis is frequently referred to as the z-axis in real space and - the k-axis in reciprocal space. - dimensions: - rank: 1 - dim: [[1, 3]] - depends_on(NX_CHAR): - doc: | - This specificies the relation to another coordinate system by pointing to the last - transformation in the transformation chain in the NXtransformations group. - (NXtransformations): - doc: | - Collection of axis-based translations and rotations to describe this coordinate system - with respect to another coordinate system. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d7af70560e4ec12c974abcef748ae4a4befd1d634cb343cdebc9087d546d027c -# -# -# -# -# -# Base class to detail a coordinate system (CS). -# -# Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as -# a member in an :ref:`NXcoordinate_system_set` and the name of the instance -# should be this alias. This may support a process whereby jargon when talking -# about coordinate systems and conventions may become cleaner for users -# because it is not evident for people outside a lab that terms like e.g. -# tip space or specimen space refer to the same coordinate system. -# This is an example of jargon used in e.g. the field of atom -# probe tomography. -# -# -# -# Human-readable field telling where the origin of this CS is. -# Exemplar values could be *left corner of the lab bench*, *door-handle* -# *pinhole through which the electron beam exists the pole piece*. -# *barycenter of the triangle*, *center of mass of the stone*. -# -# -# -# -# -# An alternative name given to that coordinate system. -# -# -# -# -# Coordinate system type. -# -# -# -# -# -# -# -# -# Handedness of the coordinate system if it is a Cartesian. -# -# -# -# -# -# -# -# -# -# Possibility to define an alias for the name of the x-axis. -# -# -# -# -# Human-readable field telling in which direction the x-axis points if that -# instance of :ref:`NXcoordinate_system` has no reference to any parent and as such -# is the mighty world reference frame. -# -# Exemplar values could be direction of gravity. -# -# -# -# -# -# Base unit vector along the first axis which spans the coordinate system. -# This axis is frequently referred to as the x-axis in real space and -# the i-axis in reciprocal space. -# -# -# -# -# -# -# -# Possibility to define an alias for the name of the y-axis. -# -# -# -# -# Human-readable field telling in which direction the y-axis points if that -# instance of :ref:`NXcoordinate_system` has no reference to any parent and as such -# is the mighty world reference frame. -# -# See docstring of x_alias for further details. -# -# -# -# -# Base unit vector along the second axis which spans the coordinate system. -# This axis is frequently referred to as the y-axis in real space and -# the j-axis in reciprocal space. -# -# -# -# -# -# -# -# Possibility to define an alias for the name of the z-axis. -# -# -# -# -# Human-readable field telling in which direction the z-axis points if that -# instance of :ref:`NXcoordinate_system` has no reference to any parent and as such -# is the mighty world reference frame. -# -# See docstring of x_alias for further details. -# -# -# -# -# Base unit vector along the third axis which spans the coordinate system. -# This axis is frequently referred to as the z-axis in real space and -# the k-axis in reciprocal space. -# -# -# -# -# -# -# -# This specificies the relation to another coordinate system by pointing to the last -# transformation in the transformation chain in the NXtransformations group. -# -# -# -# -# Collection of axis-based translations and rotations to describe this coordinate system -# with respect to another coordinate system. -# -# -# diff --git a/contributed_definitions/nyaml/NXcoordinate_system_set.yaml b/contributed_definitions/nyaml/NXcoordinate_system_set.yaml deleted file mode 100644 index 246d2a83c9..0000000000 --- a/contributed_definitions/nyaml/NXcoordinate_system_set.yaml +++ /dev/null @@ -1,417 +0,0 @@ -category: base -doc: | - Base class to hold different coordinate systems and representation conversions. - - How many nodes of type :ref:`NXcoordinate_system_set` should be used in an application definition? - - * 0; if there is no instance of :ref:`NXcoordinate_system_set` and therein or elsewhere across - the application definition, an instance of NXcoordinate_system is defined, - the default NeXus `McStas `_ - coordinate system is assumed. This makes :ref:`NXcoordinate_system_set` and - NXcoordinate_system base classes backwards compatible to older - NeXus conventions and classes. - * 1; if only one :ref:`NXcoordinate_system_set` is defined, it should be placed - as high up in the node hierarchy (ideally right below an instance of NXentry) - of the application definition tree as possible. - This :ref:`NXcoordinate_system_set` should define at least one NXcoordinate_system - instance. This shall be named such that it is clear how this coordinate system is - typically referred to in a community. For the NeXus `McStas coordinate system, it is - advised to call it mcstas for the sake of improved clarity. - Additional NXcoordinate_system instances should be specified if possible in that same - :ref:`NXcoordinate_system_set` instead of cluttering them across the tree. - - If this is the case, it is assumed that the NXcoordinate_system_members - overwrite the NeXus default McStas coordinate system, i.e. users can thereby - conveniently and explicitly specify the coordinate system(s) that - they wish to use. - - Users are encouraged to write also explicit and clean depends_on fields in - all groups that encode information about where the interpretation of coordinate - systems is relevant. If these depends_on hints are not provided, it is - automatically assumed that all children (to arbitrary depth) - of that branch and sub-branches below the one in which that - :ref:`NXcoordinate_system_set` is defined use either the only NXcoordinate_system_set - instance in that set or the application definition is considered - underconstrained which should at all costs be avoided and in which case - again McStas is assumed. - * 2 and more; as soon as more than one :ref:`NXcoordinate_system_set` is specified - somewhere in the tree, different interpretations are possible as to which - of these coordinate system sets and instances apply or take preference. - We realize that such ambiguities should at all costs be avoided. - However, the opportunity for multiple sets and their instances enables to - have branch-specific coordinate system conventions which could especially - be useful for deep classes where multiple scientific methods are combined or - cases where having a definition of global translation and conversion tables - how to convert between representations in different coordinate systems - is not desired or available for now. - We argue that having 2 or more :ref:`NXcoordinate_system_set` instances and respective - NXcoordinate_system instances makes the interpretation eventually unnecessary - complicated. Instead, developers of application definitions should always try - to work for clarity and thus use only one top-level coordinate system set. - - For these reasons we conclude that the option with one top-level - :ref:`NXcoordinate_system_set` instance is the preferred choice. - - McStas is used if neither an instance of :ref:`NXcoordinate_system_set` nor an instance - of NXcoordinate_system is specified. However, even in this case it is better - to be explicit like for every other coordinate system definition to support - users with interpreting the content and logic behind every instance of the tree. - - How to store coordinate systems inside :ref:`NXcoordinate_system_set`? - Individual coordinate systems should be specified as members of the - :ref:`NXcoordinate_system_set` instance using instances of NXcoordinate_system. - - How many individual instances of NXcoordinate_system to allow within one - instance of :ref:`NXcoordinate_system_set`? - - * 0; This case should be avoided for the sake of clarity but this case could - mean the authors of the definition meant that McStas is used. We conclude, - McStas is used in this case. - * 1; Like above-mentioned this case has the advantage that it is explicit - and faces no ambiguities. However, in reality typically multiple - coordinate systems have to be mastered especially for complex - multi-signal modality experiments. - * 2 or more; If this case is realized, the best practice is that in every - case where a coordinate system should be referred to the respective class - has a depends_on field which resolves the possible ambiguities which specific - coordinate systems is referred to. The benefit of this explicit and clear - specifying of the coordinate system used in every case is that especially - in combination with having coordinate systems inside deeper branches - makes up for a very versatile, backwards compatible, but powerful system - to express different types of coordinate systems using NeXus. In the case - of two or more instances of NXcoordinate_system in one :ref:`NXcoordinate_system_set`, - it is also advised to specify the relationship between the two coordinate systems by - using the (NXtransformations) group within NXcoordinate_system. - - In effect, 1 should be the preferred choice. However, if more than one coordinate - system is defined for practical purposes, explicit depends_on fields should - always guide the user for each group and field which of the coordinate system - one refers to. - -# express conventions explicitly and understandable -# use depends_on field - not attribute - to point to conventions used -type: group -NXcoordinate_system_set(NXobject): - rotation_handedness(NX_CHAR): - doc: | - Convention how a positive rotation angle is defined when viewing - from the end of the rotation unit vector towards its origin, - i.e. in accordance with convention 2 of - DOI: 10.1088/0965-0393/23/8/083501. - Counter_clockwise is equivalent to a right-handed choice. - Clockwise is equivalent to a left-handed choice. - enumeration: [undefined, counter_clockwise, clockwise] - rotation_convention(NX_CHAR): - doc: | - How are rotations interpreted into an orientation - according to convention 3 of - DOI: 10.1088/0965-0393/23/8/083501. - enumeration: [undefined, passive, active] - euler_angle_convention(NX_CHAR): - doc: | - How are Euler angles interpreted given that there are several choices (e.g. zxz, xyz) - according to convention 4 of DOI: 10.1088/0965-0393/23/8/083501. - - The most frequently used convention is zxz, which is based on the work of H.-J. Bunge - but other conventions are possible. Apart from undefined, proper Euler angles - are distinguished from (improper) Tait-Bryan angles. - enumeration: [undefined, zxz, xyx, yzy, zyz, xzx, yxy, xyz, yzx, zxy, xzy, zyx, yxz] - axis_angle_convention(NX_CHAR): - doc: | - To which angular range is the rotation angle argument of an - axis-angle pair parameterization constrained according to - convention 5 of DOI: 10.1088/0965-0393/23/8/083501. - enumeration: [undefined, rotation_angle_on_interval_zero_to_pi] - sign_convention(NX_CHAR): - doc: | - Which sign convention is followed when converting orientations - between different parameterizations/representations according - to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. - enumeration: [undefined, p_plus_one, p_minus_one] - - # possibility to add further coordinate systems - (NXcoordinate_system): - - # frequently used coordinate systems with frequently relevant specializations follow - # convention 1 of DOI: 10.1088/0965-0393/23/8/083501 is implemented by inheriting type from NXcoordinate_system - processing_reference_frame(NXcoordinate_system): - doc: | - Details about eventually relevant named directions that may give reasons for anisotropies. - The classical example is mechanical processing where one has to specify which directions - (e.g. rolling, transverse, and normal direction) align how with the direction of the base - vectors of the sample_reference_frame. - - It is assumed that the configuration is inspected by looking towards the sample surface. - If a detector is involved, it is assumed that the configuration is inspected from a position - that is located behind this detector. - - If any of these assumptions is not met, the user is required to explicitly state this. - - Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the - base vectors of this coordinate system as Xp, Yp, Zp. - sample_reference_frame(NXcoordinate_system): - doc: | - Details about the sample_reference_frame that is typically overlaid onto the surface of the sample. - - It is assumed that the configuration is inspected by looking towards the sample surface. - If a detector is involved, it is assumed that the configuration is inspected from a position - that is located behind this detector. - - If any of these assumptions is not met, the user is required to explicitly state this. - - Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the - base vectors of this coordinate system as Xs, Ys, Zs. - detector_reference_frameID(NXcoordinate_system): - doc: | - Details about the detector_reference_frame for a specific detector. - - Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the - base vectors of this coordinate system as Xd, Yd, Zd. - - It is assumed that the configuration is inspected by looking towards the sample surface - from a position that is located behind the detector. - - If any of these assumptions is not met, the user is required to explicitly state this. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# fa0669fabccdeeabc454a75796585c48e1c98d117283a916cb459d66dda15aa7 -# -# -# -# -# -# -# Base class to hold different coordinate systems and representation conversions. -# -# How many nodes of type :ref:`NXcoordinate_system_set` should be used in an application definition? -# -# * 0; if there is no instance of :ref:`NXcoordinate_system_set` and therein or elsewhere across -# the application definition, an instance of NXcoordinate_system is defined, -# the default NeXus `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ -# coordinate system is assumed. This makes :ref:`NXcoordinate_system_set` and -# NXcoordinate_system base classes backwards compatible to older -# NeXus conventions and classes. -# * 1; if only one :ref:`NXcoordinate_system_set` is defined, it should be placed -# as high up in the node hierarchy (ideally right below an instance of NXentry) -# of the application definition tree as possible. -# This :ref:`NXcoordinate_system_set` should define at least one NXcoordinate_system -# instance. This shall be named such that it is clear how this coordinate system is -# typically referred to in a community. For the NeXus `McStas coordinate system, it is -# advised to call it mcstas for the sake of improved clarity. -# Additional NXcoordinate_system instances should be specified if possible in that same -# :ref:`NXcoordinate_system_set` instead of cluttering them across the tree. -# -# If this is the case, it is assumed that the NXcoordinate_system_members -# overwrite the NeXus default McStas coordinate system, i.e. users can thereby -# conveniently and explicitly specify the coordinate system(s) that -# they wish to use. -# -# Users are encouraged to write also explicit and clean depends_on fields in -# all groups that encode information about where the interpretation of coordinate -# systems is relevant. If these depends_on hints are not provided, it is -# automatically assumed that all children (to arbitrary depth) -# of that branch and sub-branches below the one in which that -# :ref:`NXcoordinate_system_set` is defined use either the only NXcoordinate_system_set -# instance in that set or the application definition is considered -# underconstrained which should at all costs be avoided and in which case -# again McStas is assumed. -# * 2 and more; as soon as more than one :ref:`NXcoordinate_system_set` is specified -# somewhere in the tree, different interpretations are possible as to which -# of these coordinate system sets and instances apply or take preference. -# We realize that such ambiguities should at all costs be avoided. -# However, the opportunity for multiple sets and their instances enables to -# have branch-specific coordinate system conventions which could especially -# be useful for deep classes where multiple scientific methods are combined or -# cases where having a definition of global translation and conversion tables -# how to convert between representations in different coordinate systems -# is not desired or available for now. -# We argue that having 2 or more :ref:`NXcoordinate_system_set` instances and respective -# NXcoordinate_system instances makes the interpretation eventually unnecessary -# complicated. Instead, developers of application definitions should always try -# to work for clarity and thus use only one top-level coordinate system set. -# -# For these reasons we conclude that the option with one top-level -# :ref:`NXcoordinate_system_set` instance is the preferred choice. -# -# McStas is used if neither an instance of :ref:`NXcoordinate_system_set` nor an instance -# of NXcoordinate_system is specified. However, even in this case it is better -# to be explicit like for every other coordinate system definition to support -# users with interpreting the content and logic behind every instance of the tree. -# -# How to store coordinate systems inside :ref:`NXcoordinate_system_set`? -# Individual coordinate systems should be specified as members of the -# :ref:`NXcoordinate_system_set` instance using instances of NXcoordinate_system. -# -# How many individual instances of NXcoordinate_system to allow within one -# instance of :ref:`NXcoordinate_system_set`? -# -# * 0; This case should be avoided for the sake of clarity but this case could -# mean the authors of the definition meant that McStas is used. We conclude, -# McStas is used in this case. -# * 1; Like above-mentioned this case has the advantage that it is explicit -# and faces no ambiguities. However, in reality typically multiple -# coordinate systems have to be mastered especially for complex -# multi-signal modality experiments. -# * 2 or more; If this case is realized, the best practice is that in every -# case where a coordinate system should be referred to the respective class -# has a depends_on field which resolves the possible ambiguities which specific -# coordinate systems is referred to. The benefit of this explicit and clear -# specifying of the coordinate system used in every case is that especially -# in combination with having coordinate systems inside deeper branches -# makes up for a very versatile, backwards compatible, but powerful system -# to express different types of coordinate systems using NeXus. In the case -# of two or more instances of NXcoordinate_system in one :ref:`NXcoordinate_system_set`, -# it is also advised to specify the relationship between the two coordinate systems by -# using the (NXtransformations) group within NXcoordinate_system. -# -# In effect, 1 should be the preferred choice. However, if more than one coordinate -# system is defined for practical purposes, explicit depends_on fields should -# always guide the user for each group and field which of the coordinate system -# one refers to. -# -# -# -# Convention how a positive rotation angle is defined when viewing -# from the end of the rotation unit vector towards its origin, -# i.e. in accordance with convention 2 of -# DOI: 10.1088/0965-0393/23/8/083501. -# Counter_clockwise is equivalent to a right-handed choice. -# Clockwise is equivalent to a left-handed choice. -# -# -# -# -# -# -# -# -# -# How are rotations interpreted into an orientation -# according to convention 3 of -# DOI: 10.1088/0965-0393/23/8/083501. -# -# -# -# -# -# -# -# -# -# How are Euler angles interpreted given that there are several choices (e.g. zxz, xyz) -# according to convention 4 of DOI: 10.1088/0965-0393/23/8/083501. -# -# The most frequently used convention is zxz, which is based on the work of H.-J. Bunge -# but other conventions are possible. Apart from undefined, proper Euler angles -# are distinguished from (improper) Tait-Bryan angles. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# To which angular range is the rotation angle argument of an -# axis-angle pair parameterization constrained according to -# convention 5 of DOI: 10.1088/0965-0393/23/8/083501. -# -# -# -# -# -# -# -# -# Which sign convention is followed when converting orientations -# between different parameterizations/representations according -# to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. -# -# -# -# -# -# -# -# -# -# -# -# -# Details about eventually relevant named directions that may give reasons for anisotropies. -# The classical example is mechanical processing where one has to specify which directions -# (e.g. rolling, transverse, and normal direction) align how with the direction of the base -# vectors of the sample_reference_frame. -# -# It is assumed that the configuration is inspected by looking towards the sample surface. -# If a detector is involved, it is assumed that the configuration is inspected from a position -# that is located behind this detector. -# -# If any of these assumptions is not met, the user is required to explicitly state this. -# -# Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the -# base vectors of this coordinate system as Xp, Yp, Zp. -# -# -# -# -# Details about the sample_reference_frame that is typically overlaid onto the surface of the sample. -# -# It is assumed that the configuration is inspected by looking towards the sample surface. -# If a detector is involved, it is assumed that the configuration is inspected from a position -# that is located behind this detector. -# -# If any of these assumptions is not met, the user is required to explicitly state this. -# -# Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the -# base vectors of this coordinate system as Xs, Ys, Zs. -# -# -# -# -# Details about the detector_reference_frame for a specific detector. -# -# Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the -# base vectors of this coordinate system as Xd, Yd, Zd. -# -# It is assumed that the configuration is inspected by looking towards the sample surface -# from a position that is located behind the detector. -# -# If any of these assumptions is not met, the user is required to explicitly state this. -# -# -# diff --git a/contributed_definitions/nyaml/NXcorrector_cs.yaml b/contributed_definitions/nyaml/NXcorrector_cs.yaml deleted file mode 100644 index c04317d4f4..0000000000 --- a/contributed_definitions/nyaml/NXcorrector_cs.yaml +++ /dev/null @@ -1,414 +0,0 @@ -category: base -doc: | - Base class for a corrector reducing (spherical) aberrations in electron microscopy. - - Different technology partners use different naming schemes and - models for quantifying the aberration coefficients. - - The corrector in an electron microscope is composed of multiple lenses - and multipole stigmators with details specific for the technology partner - and microscope. Many of their technical details is proprietary knowledge. - - If functionalities for correcting multiple aberrations are included in - one :ref:`NXcomponent` `like it is reported here `_ - use multiple groups: - - * :ref:`NXcorrector_cs` for spherical aberration - * :ref:`NXmonochromator` for energy filtering or chromatic aberration - * corrector_ax in :ref:`NXem` for axial astigmatism correction -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_img: | - Number of images taken, at least one. - -# https://doi.org/10.1017/9781316337455.022 -type: group -NXcorrector_cs(NXcomponent): - - # user perspective - applied(NX_BOOLEAN): - doc: | - Was the corrector used? - - # NEW ISSUE: clarify further mathematical details - tableauID(NXprocess): - doc: | - Specific information about the alignment procedure that is a process during which - the corrector is configured to enable calibrated usage of the instrument. - - This :ref:`NXprocess` group should also be used when one describes in a computer - simulation the specific details about the modelled or assumed aberration - corrections. - description(NX_CHAR): - doc: | - Discouraged free-text field to add further details about the alignment - procedure. - tilt_angle(NX_NUMBER): - unit: NX_ANGLE - doc: | - The outer tilt angle of the beam in tableau acquisition. - - TODO: The relevant axes which span the tilt_angle need a - cleaner description. - dimensions: - rank: 1 - dim: [[1, n_img]] - exposure_time(NX_NUMBER): - unit: NX_TIME - doc: | - The exposure time of single tilt images. - dimensions: - rank: 1 - dim: [[1, n_img]] - magnification(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - The factor of enlargement of the apparent size, - not the physical size, of an object. - dimensions: - rank: 1 - dim: [[1, n_img]] - (NXimage_set): - doc: | - The images taken during the alignment procedure. - model(NX_CHAR): - doc: | - Place for storing measured or estimated aberrations (for each image or final). - - See `S. J. Pennycock and P. D. Nellist `_ (page 44ff, and page 118ff) - for different definitions available and further details. Table 7-2 of Ibid. publication (page 305ff) documents how - to convert from the Nion to the CEOS definitions. Conversion tables are also summarized by `Y. Liao `_. - enumeration: [ceos, nion] - - # specifically-named aberrations following the CEOS / Typke and Dierksen convention - c_1(NXaberration): - - # magnitude(NX_NUMBER): - # unit: NX_LENGTH - a_1(NXaberration): - b_2(NXaberration): - a_2(NXaberration): - c_3(NXaberration): - - # magnitude(NX_NUMBER): - # unit: NX_LENGTH - s_3(NXaberration): - a_3(NXaberration): - - # based on feedback from Thilo Remmele the following aberrations could be measured - # (enhanced mode, tilt angle > 30 mrad) but are not corrected for with - b_4(NXaberration): - d_4(NXaberration): - a_4(NXaberration): - c_5(NXaberration): - - # magnitude(NX_NUMBER): - # unit: NX_LENGTH - s_5(NXaberration): - r_5(NXaberration): - a_6(NXaberration): - - # specifically-named aberrations following the Nion convention - c_1_0(NXaberration): - - # magnitude(NX_NUMBER): - # unit: NX_LENGTH - c_1_2_a(NXaberration): - c_1_2_b(NXaberration): - c_2_1_a(NXaberration): - c_2_1_b(NXaberration): - c_2_3_a(NXaberration): - c_2_3_b(NXaberration): - c_3_0(NXaberration): - - # magnitude(NX_NUMBER): - # unit: NX_LENGTH - c_3_2_a(NXaberration): - c_3_2_b(NXaberration): - c_3_4_a(NXaberration): - c_3_4_b(NXaberration): - c_4_1_a(NXaberration): - c_4_1_b(NXaberration): - c_4_3_a(NXaberration): - c_4_3_b(NXaberration): - c_4_5_a(NXaberration): - c_4_5_b(NXaberration): - c_5_0(NXaberration): - - # magnitude(NX_NUMBER): - # unit: NX_LENGTH - c_5_2_a(NXaberration): - c_5_2_b(NXaberration): - c_5_4_a(NXaberration): - c_5_4_b(NXaberration): - c_5_6_a(NXaberration): - c_5_6_b(NXaberration): - - # further comments from Thilo Remmele (Leibniz-Institut für Kristallzüchtung) - # ThermoFisher uses CEOS correctors but makes customizations to these in their microscopes - # Aberration naming schema: C_order_multiplicity (similar to NXem, but with - # another coordinate system and in addition with a confidence entry. - # Aberrations with multiplicity 0 have no angle entry (C1,C3,C5,.., CEOS notation) - # contrast transferfuntion: ctf = e^(-i*Xi(g)) in Fourier space - # aberration function: - # Xi(g) = 2*pi/lamda{ 1/2 * (lamda*g)^2 (C20 + C22 cos[2(phi-phi_22)] - # +1/3 * (lamda*g)^3 (C31 cos[(phi-phi_31) + C33 cos[3(phi-phi_33) - # +1/4 * (lamda*g)^4 (C40 + C42 cos[2(phi-phi_42)] + C44 cos[4(phi-phi_42)] - # +1/f * (lamda*g)^f Sum (Cfm cos[m(phi-phi_fm)] where m=[0,2,..f] for even f and m=[1,3,..,f] for odd f - # Thilo Remmele also mentions that there is a mapping of aberration coefficient names: - # C_2_0 -> C1 Defocus - # C_2_2 -> A1 2-fold astigmatism - # C_3_3 -> A2 3-fold astigmatism - # C_3_1 -> B2 axial coma - # C_4_0 -> C3 spherical aberration - # C_4_4 -> A3 4-fold astigmatism - # C_4_2 -> S3 star aberration - # C_5_5 -> A4 5-fold astigmatism - # C_5_1 -> B4 axial coma - # C_5_3 -> D4 three lobe aberration - # C_6_0 -> C5 spherical aberration - # C_6_2 -> S5 star aberration - # C_6_4 -> R5 rosette aberration - # C_6_6 -> A5 6-fold astigmatism - # In a session with HRTEM images the corrector is commonly aligned. - # The final measurement with the estimated residual aberrations - # should be saved in a corrector.html file (an example is appended - # at the end of this file. Unfortunately the datetime is not included - # in that html output, nor is the used outer tilt angle and exposure time. - # The datetime may be estimated from the file datetime and the Delta t entry, - # but caution if that datetime is not preserved on file transfers! - # More than one detector entry could occure but is not common. - # A seperate corrector schema, so it can be easily exchanged to other correctors if necessary. - # It might be useful to collect all the corrector entries in one table, for example to analyse the performance of the corrector. - # The corrector entry of the nexus em definition lacks the confidence information and the - # parameter settings for the estimation oft the aberrations. - # technical design perspective - (NXlens_em): - (NXaperture): - - # (NXdeflector): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 54b0cb04b663feb598fd601ce1e9a1f54ed33ed4d19bc96fee06ec3c0f7dafee -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of images taken, at least one. -# -# -# -# -# Base class for a corrector reducing (spherical) aberrations in electron microscopy. -# -# Different technology partners use different naming schemes and -# models for quantifying the aberration coefficients. -# -# The corrector in an electron microscope is composed of multiple lenses -# and multipole stigmators with details specific for the technology partner -# and microscope. Many of their technical details is proprietary knowledge. -# -# If functionalities for correcting multiple aberrations are included in -# one :ref:`NXcomponent` `like it is reported here <https://www.ceos-gmbh.de/en/research/electrostat>`_ -# use multiple groups: -# -# * :ref:`NXcorrector_cs` for spherical aberration -# * :ref:`NXmonochromator` for energy filtering or chromatic aberration -# * corrector_ax in :ref:`NXem` for axial astigmatism correction -# -# -# -# -# Was the corrector used? -# -# -# -# -# -# Specific information about the alignment procedure that is a process during which -# the corrector is configured to enable calibrated usage of the instrument. -# -# This :ref:`NXprocess` group should also be used when one describes in a computer -# simulation the specific details about the modelled or assumed aberration -# corrections. -# -# -# -# Discouraged free-text field to add further details about the alignment -# procedure. -# -# -# -# -# The outer tilt angle of the beam in tableau acquisition. -# -# TODO: The relevant axes which span the tilt_angle need a -# cleaner description. -# -# -# -# -# -# -# -# The exposure time of single tilt images. -# -# -# -# -# -# -# -# The factor of enlargement of the apparent size, -# not the physical size, of an object. -# -# -# -# -# -# -# -# The images taken during the alignment procedure. -# -# -# -# -# Place for storing measured or estimated aberrations (for each image or final). -# -# See `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) -# for different definitions available and further details. Table 7-2 of Ibid. publication (page 305ff) documents how -# to convert from the Nion to the CEOS definitions. Conversion tables are also summarized by `Y. Liao <https://www.globalsino.com/EM/page3740.html>`_. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml deleted file mode 100644 index 13d8053618..0000000000 --- a/contributed_definitions/nyaml/NXcrystal_structure.yaml +++ /dev/null @@ -1,201 +0,0 @@ -category: base -doc: | - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. - -# The actual indexing of Kikuchi patterns may use different algorithms. -# Such are used within different workflows where simulated and measured -# Kikuchi pattern are compared to rate which phase and orientation is the most -# likely candidate describing the pattern measured at that each scan point -# respectively. If this evaluation yields scan points without any solutions, -# these are represented using the null-phase model phase0, aka n/a aka notIndexed. -# Traditionally, Hough transformation-based indexing has been the most frequently -# used algorithm. Dictionary-based alternatives are emerging. -symbols: - n_hkl: | - Number of reflectors (Miller crystallographic plane triplets). - n_pos: | - Number of atom positions. - d: | - Dimensionality of the lattice. -type: group -NXcrystal_structure(NXobject): - depends_on(NX_CHAR): - doc: | - Details in which reference frame the unit cell is defined. - dimensionality(NX_POSINT): - doc: | - Dimensionality of the lattice. - enumeration: [1, 2, 3] - reference(NXidentifier): - doc: | - Reference to another resource that was used for - instantiating this structure model. - a_b_c(NX_NUMBER): - unit: NX_LENGTH - doc: | - Crystallography unit cell parameters a, b, and c. - dimensions: - rank: 1 - dim: [[1, d]] - - # defined using which convention? - alpha_beta_gamma(NX_NUMBER): - unit: NX_ANGLE - doc: | - Crystallography unit cell parameters alpha, beta, and gamma. - dimensions: - rank: 1 - dim: [[1, d]] - area(NX_NUMBER): - unit: NX_AREA - doc: | - Area of the unit cell considering that d = 2. - volume(NX_NUMBER): - unit: NX_VOLUME - doc: | - Volume of the unit cell considering that d = 3. - crystal_system(NX_CHAR): - doc: | - Crystal system - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - - # 2d - laue_group(NX_CHAR): - doc: | - Laue group using International Table of Crystallography Notation. - - # add enumeration of all possible - point_group(NX_CHAR): - doc: | - Point group using International Table of Crystallography Notation. - - # add enumeration all possible - # 3d - space_group(NX_CHAR): - doc: | - Space group from the International Table of Crystallography Notation. - - # add enumeration of all possible - is_centrosymmetric(NX_BOOLEAN): - doc: | - True if space group is considered a centrosymmetric one. - False if space group is considered a non-centrosymmetric one. - Centrosymmetric has all types and combinations of symmetry elements - (translation, rotational axis, mirror planes, center of inversion) - Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). - Chiral compared to non-centrosymmetric is constrained (no mirror planes). - is_chiral(NX_BOOLEAN): - doc: | - True if space group is considered a chiral one. - False if space group is consider a non-chiral one. - phase_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - phase_name(NX_CHAR): - doc: | - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - atom_identifier(NX_CHAR): - doc: | - Label for each atom position. - dimensions: - rank: 1 - dim: [[1, n_pos]] - atom_type(NX_UINT): - unit: NX_UNITLESS - doc: | - The hash value :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) `_ - dimensions: - rank: 1 - dim: [[1, n_pos]] - - # atom_position(NXcg_point_set): - atom_position(NX_NUMBER): - unit: NX_ANY - doc: | - Atom positions. - dimensions: - rank: 2 - dim: [[1, n_pos], [2, d]] - \@depends_on: - type: NX_CHAR - doc: | - Details the reference frame in which the positions are defined. - - # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory - # to describe the simulated Kikuchi pattern generated from such a model - atom_occupancy(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - Relative occupancy of the atom position. - dimensions: - rank: 1 - dim: [[1, n_pos]] - number_of_planes(NX_UINT): - unit: NX_UNITLESS - doc: | - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - - # Miller indices :math:`(hkl)[uvw]`. - miller(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - dimensions: - rank: 2 - dim: [[1, n_hkl], [2, 6]] - dspacing(NX_NUMBER): - unit: NX_LENGTH - doc: | - Spacing between crystallographic planes as defined by field miller. - dimensions: - rank: 1 - dim: [[1, n_hkl]] - relative_intensity(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - Relative intensity of the signal for the plane. - dimensions: - rank: 1 - dim: [[1, n_hkl]] - number_of_scan_points(NX_UINT): - unit: NX_UNITLESS - doc: | - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - unit: NX_UNITLESS - # ipfID(NXmicrostructure_ipf): - # pfID(NXmicrostructure_pf): - # odfID(NXmicrostructure_odf): -# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) -# can give some good suggestions on how to improve and ideally make even -# more general this section diff --git a/contributed_definitions/nyaml/NXcs_computer.yaml b/contributed_definitions/nyaml/NXcs_computer.yaml deleted file mode 100644 index ad1802ed9d..0000000000 --- a/contributed_definitions/nyaml/NXcs_computer.yaml +++ /dev/null @@ -1,229 +0,0 @@ -category: base -doc: | - Base class for reporting the description of a computer -type: group -NXcs_computer(NXobject): - name(NX_CHAR): - doc: | - Given name/alias to the computing system, e.g. MyDesktop. - operating_system(NX_CHAR): - doc: | - Name of the operating system, e.g. Windows, Linux, Mac, Android. - \@version: - doc: | - Version plus build number, commit hash, or description of an ever - persistent resource where the source code of the program and build - instructions can be found so that the program can be configured in - such a manner that the result file is ideally recreatable yielding - the same results. - - # difference e.g. in Win11 between hardware ID, UUID, and device ID - uuid(NX_CHAR): - doc: | - Ideally a (globally) unique persistent identifier of the computer, i.e. - the Universally Unique Identifier (UUID) of the computing node. - - # when it comes to performance monitoring - processing(NXobject): - doc: | - Details about the system of processing units e.g. (classical) processing units (CPUs), - coprocessor, graphic cards, accelerator processing units or a system of these. - (NXcircuit): - doc: | - Granularizing the processing units. Typical examples, a desktop computer - with a single CPU one could describe using one instance of NXcircuit. - A dual-socket server one could describe using two instances NXcircuit - A server with two dual-socket server nodes one could describe with - four instances of NXcircuit surplus a field with their level in the hierarchy. - type(NX_CHAR): - doc: | - General type of the processing unit - enumeration: [cpu, gpu, fpga, other] - name(NX_CHAR): - doc: | - Given name - memory(NXobject): - doc: | - Details about the memory system. - (NXcircuit): - doc: | - Granularizing the components of the memory system. - type(NX_CHAR): - doc: | - Qualifier for the type of random access memory. - enumeration: [ddr4, ddr5] - max_physical_capacity(NX_POSINT): - unit: NX_ANY - doc: | - Total amount of data which the medium can hold. - name(NX_CHAR): - doc: | - Given name - storage(NXobject): - doc: | - Details about the I/O system. - (NXcircuit): - doc: | - Granularizing the components of the I/O system. - type(NX_CHAR): - doc: | - Qualifier for the type of storage medium used. - enumeration: [solid_state_disk, hard_disk, tape] - max_physical_capacity(NX_POSINT): - unit: NX_ANY - doc: | - Total amount of data which the medium can hold. - name(NX_CHAR): - doc: | - Given name - - # NXcircuit inherits fabrication from NXcomponent - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f9c6fb31265951b0d30e5eea2293d2afdf9c812f09307b891ba2442931242a28 -# -# -# -# -# -# Base class for reporting the description of a computer -# -# -# -# Given name/alias to the computing system, e.g. MyDesktop. -# -# -# -# -# Name of the operating system, e.g. Windows, Linux, Mac, Android. -# -# -# -# Version plus build number, commit hash, or description of an ever -# persistent resource where the source code of the program and build -# instructions can be found so that the program can be configured in -# such a manner that the result file is ideally recreatable yielding -# the same results. -# -# -# -# -# -# -# Ideally a (globally) unique persistent identifier of the computer, i.e. -# the Universally Unique Identifier (UUID) of the computing node. -# -# -# -# -# -# Details about the system of processing units e.g. (classical) processing units (CPUs), -# coprocessor, graphic cards, accelerator processing units or a system of these. -# -# -# -# Granularizing the processing units. Typical examples, a desktop computer -# with a single CPU one could describe using one instance of NXcircuit. -# A dual-socket server one could describe using two instances NXcircuit -# A server with two dual-socket server nodes one could describe with -# four instances of NXcircuit surplus a field with their level in the hierarchy. -# -# -# -# General type of the processing unit -# -# -# -# -# -# -# -# -# -# -# Given name -# -# -# -# -# -# -# Details about the memory system. -# -# -# -# Granularizing the components of the memory system. -# -# -# -# Qualifier for the type of random access memory. -# -# -# -# -# -# -# -# -# Total amount of data which the medium can hold. -# -# -# -# -# Given name -# -# -# -# -# -# -# Details about the I/O system. -# -# -# -# Granularizing the components of the I/O system. -# -# -# -# Qualifier for the type of storage medium used. -# -# -# -# -# -# -# -# -# -# Total amount of data which the medium can hold. -# -# -# -# -# Given name -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml b/contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml deleted file mode 100644 index be8c6af44b..0000000000 --- a/contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml +++ /dev/null @@ -1,191 +0,0 @@ -category: base -doc: | - Base class for packing and unpacking booleans. - - This base class bookkeeps metadata to inform software about necessary modulo - operations to decode e.g. set membership of objects in sets which are encoded - as a packed array of boolean values. - - One use case is processing of object sets (e.g. point cloud data). If e.g. a - spatial filter has been applied to a set of points we may wish to store - document efficiently which points were analyzed. Array of boolean values - is one option to achieve this. A value is true if the point is included. - The resulting boolean array will be filled with true and false values - in a manner that is often arbitrary and in general case-dependent. - - Especially when the number of points is large, for instance several thousands - or more, some situations can be more efficiently stored if one does not store - the boolean array but just lists the identifiers of the points taken. - - For example, if within a set of 1000 points only one point is included, it would - take (naively) 4000 bits to store the array but only 32 bits to store e.g. the - ID of the single point that is taken. Of course the 4000 bit field is so - sparse that it could be compressed resulting also in a substantial reduction - of the storage demands. Therefore, boolean masks are useful in that - they store compact representation of set memberships. - - This base class can deal with the situation when the number of objects - is not an integer multiple of the bit depth used for storing the states. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_objs: | - Number of entries (e.g. number of points or objects). - bitdepth: | - Number of bits assumed for the container datatype used. - n_total: | - Length of mask considering the eventual need for padding. -type: group -NXcs_filter_boolean_mask(NXobject): - depends_on(NX_CHAR): - doc: | - Possibility to refer to which set this mask applies. - - If depends_on is not provided, it is assumed that the mask - applies to its direct parent. - number_of_objects(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of objects represented by the mask. - bitdepth(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - mask(NX_UINT): - unit: NX_UNITLESS - doc: | - The content of the mask. If padding is used, - padding bits have to be set to 0. - dimensions: - rank: 1 - dim: [[1, n_total]] - identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Link to/or array of identifiers for the objects. The decoded mask is - interpreted consecutively, i.e. the first bit in the mask matches - to the first identifier, the second bit in the mask to the second - identifier and so on and so forth. Resolving of identifier follows - the conventions made for depends_on, so consult also the description - of th content to which depends_on refers. - dimensions: - rank: 1 - dim: [[1, n_object]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 9878df2d54b3dab7cdaaf9c4322c09222d8d267fd5a2eaad6c414070ac6c9ba5 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of entries (e.g. number of points or objects). -# -# -# -# -# Number of bits assumed for the container datatype used. -# -# -# -# -# Length of mask considering the eventual need for padding. -# -# -# -# -# Base class for packing and unpacking booleans. -# -# This base class bookkeeps metadata to inform software about necessary modulo -# operations to decode e.g. set membership of objects in sets which are encoded -# as a packed array of boolean values. -# -# One use case is processing of object sets (e.g. point cloud data). If e.g. a -# spatial filter has been applied to a set of points we may wish to store -# document efficiently which points were analyzed. Array of boolean values -# is one option to achieve this. A value is true if the point is included. -# The resulting boolean array will be filled with true and false values -# in a manner that is often arbitrary and in general case-dependent. -# -# Especially when the number of points is large, for instance several thousands -# or more, some situations can be more efficiently stored if one does not store -# the boolean array but just lists the identifiers of the points taken. -# -# For example, if within a set of 1000 points only one point is included, it would -# take (naively) 4000 bits to store the array but only 32 bits to store e.g. the -# ID of the single point that is taken. Of course the 4000 bit field is so -# sparse that it could be compressed resulting also in a substantial reduction -# of the storage demands. Therefore, boolean masks are useful in that -# they store compact representation of set memberships. -# -# This base class can deal with the situation when the number of objects -# is not an integer multiple of the bit depth used for storing the states. -# -# -# -# Possibility to refer to which set this mask applies. -# -# If depends_on is not provided, it is assumed that the mask -# applies to its direct parent. -# -# -# -# -# Number of objects represented by the mask. -# -# -# -# -# Number of bits assumed matching on a default datatype. -# (e.g. 8 bits for a C-style uint8). -# -# -# -# -# The content of the mask. If padding is used, -# padding bits have to be set to 0. -# -# -# -# -# -# -# -# Link to/or array of identifiers for the objects. The decoded mask is -# interpreted consecutively, i.e. the first bit in the mask matches -# to the first identifier, the second bit in the mask to the second -# identifier and so on and so forth. Resolving of identifier follows -# the conventions made for depends_on, so consult also the description -# of th content to which depends_on refers. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcs_prng.yaml b/contributed_definitions/nyaml/NXcs_prng.yaml deleted file mode 100644 index 61a0ec3e6e..0000000000 --- a/contributed_definitions/nyaml/NXcs_prng.yaml +++ /dev/null @@ -1,134 +0,0 @@ -category: base -doc: | - Computer science description of pseudo-random number generator. - - The purpose of this base class is to identify if exactly the same sequence - can be reproduced, like for a PRNG or not (for a true physically random source). -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXcs_prng(NXobject): - type(NX_CHAR): - doc: | - Physical approach or algorithm whereby random numbers are generated. - - Different approaches for generating random numbers with a computer exists. - Some use a dedicated physical device whose the state is unpredictable - (physically). Some use a strategy of mangling information from the system - clock. Also in this case the sequence is not reproducible without having - additional pieces of information. - - In most cases though so-called pseudo-random number generator (PRNG) - algorithms are used. These yield a deterministic sequence of practically - randomly appearing numbers. These algorithms differ in their quality in - how close the resulting sequences are random, i.e. sequentially - uncorrelated. Nowadays one of the most commonly used algorithm is the - MersenneTwister (mt19937). - enumeration: [physical, system_clock, mt19937, other] - (NXprogram): - doc: | - Name of the PRNG implementation and version. If such information is not - available or if the PRNG type was set to other the DOI to the publication - or the source code should be given. - seed(NX_INT): - unit: NX_UNITLESS - doc: | - Parameter of the PRNG controlling its initialization - and thus controlling the specific sequence generated. - warmup(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of initial draws from the PRNG after its initialized with the seed. - These initial draws are typically discarded in an effort to equilibrate the - sequence. If no warmup was performed or if warmup procedures are unclear, - users should set the value to zero. - - # one could add spectral properties but this is usually well documented in the PRNG literature - # one could also think about making reference to the NIST PRNG test suite to qualify the PRNG - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 5e52a2e904117d44260465fae64b41d929b3ab627dd4c2e347ae684ac85fe6d5 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Computer science description of pseudo-random number generator. -# -# The purpose of this base class is to identify if exactly the same sequence -# can be reproduced, like for a PRNG or not (for a true physically random source). -# -# -# -# Physical approach or algorithm whereby random numbers are generated. -# -# Different approaches for generating random numbers with a computer exists. -# Some use a dedicated physical device whose the state is unpredictable -# (physically). Some use a strategy of mangling information from the system -# clock. Also in this case the sequence is not reproducible without having -# additional pieces of information. -# -# In most cases though so-called pseudo-random number generator (PRNG) -# algorithms are used. These yield a deterministic sequence of practically -# randomly appearing numbers. These algorithms differ in their quality in -# how close the resulting sequences are random, i.e. sequentially -# uncorrelated. Nowadays one of the most commonly used algorithm is the -# MersenneTwister (mt19937). -# -# -# -# -# -# -# -# -# -# -# Name of the PRNG implementation and version. If such information is not -# available or if the PRNG type was set to other the DOI to the publication -# or the source code should be given. -# -# -# -# -# Parameter of the PRNG controlling its initialization -# and thus controlling the specific sequence generated. -# -# -# -# -# Number of initial draws from the PRNG after its initialized with the seed. -# These initial draws are typically discarded in an effort to equilibrate the -# sequence. If no warmup was performed or if warmup procedures are unclear, -# users should set the value to zero. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcs_profiling.yaml b/contributed_definitions/nyaml/NXcs_profiling.yaml deleted file mode 100644 index f886a9866d..0000000000 --- a/contributed_definitions/nyaml/NXcs_profiling.yaml +++ /dev/null @@ -1,263 +0,0 @@ -category: base -doc: | - Computer science description for performance and profiling data of an application. - - Performance monitoring and benchmarking of software is a task where questions - can be asked at various levels of detail. In general, there are three main - contributions to performance: - - * Hardware capabilities and configuration - * Software configuration and capabilities - * Dynamic effects of the system in operation and the system working together - with eventually multiple computers, especially when these have to exchange - information across a network and these are used usually by multiple users. - - At the most basic level users may wish to document how long e.g. a data - analysis with a scientific software (app) took. - A frequent idea is here to answer practical questions like how critical is the - effect on the workflow of the scientists, i.e. is the analysis possible in - a few seconds or would it take days if I were to run this analysis on a - comparable machine? - For this more qualitative performance monitoring, mainly the order of - magnitude is relevant, as well as how this was achieved using parallelization - (i.e. reporting the number of CPU and GPU resources used, the number of - processes and threads configured, and providing basic details about the computer). - - At more advanced levels benchmarks may go as deep as detailed temporal tracking - of individual processor instructions, their relation to other instructions, the - state of call stacks; in short eventually the entire app execution history - and hardware state history. Such analyses are mainly used for performance - optimization, i.e. by software and hardware developers as well as for - tracking bugs. Specialized software exists which documents such performance - data in specifically-formatted event log files or databases. - - This base class cannot and should not replace these specific solutions for now. - Instead, the intention of the base class is to serve scientists at the - basic level to enable simple monitoring of performance data and log profiling - data of key algorithmic steps or parts of computational workflows, so that - these pieces of information can guide users which order of magnitude differences - should be expected or not. - - Developers of application definitions should add additional fields and - references to e.g. more detailed performance data to which they wish to link - the metadata in this base class. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXcs_profiling(NXobject): - - # details about queuing systems etc - current_working_directory(NX_CHAR): - doc: | - Path to the directory from which the tool was called. - command_line_call(NX_CHAR): - doc: | - Command line call with arguments if applicable. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 time code with local time zone offset to UTC information - included when the app was started. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 time code with local time zone offset to UTC information - included when the app terminated or crashed. - total_elapsed_time(NX_NUMBER): - unit: NX_TIME - doc: | - Wall-clock time how long the app execution took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demands a more precise record of the wall-clock time. - number_of_processes(NX_UINT): - unit: NX_UNITLESS - doc: | - Qualifier which specifies with how many nominal processes the app was - invoked. The main idea behind this field e.g. for apps which use e.g. MPI - (Message Passing Interface) parallelization is to communicate - how many processes were used. - - For sequentially running apps number_of_processes and number_of_threads - is 1. If the app uses exclusively GPU parallelization number_of_gpus - can be larger than 1. If no GPU is used number_of_gpus is 0 even though - the hardware may have GPUs installed, thus indicating these were not - used though. - number_of_threads(NX_UINT): - unit: NX_UNITLESS - doc: | - Qualifier how many nominal threads were used at runtime. - Specifically here the maximum number of threads used for the - high-level threading library used (e.g. OMP_NUM_THREADS), posix. - number_of_gpus(NX_UINT): - unit: NX_UNITLESS - doc: | - Qualifier with how many nominal GPUs the app was invoked at runtime. - - # there are more complicated usage models, where GPUs are activated in - # between runs etc, but here application definition and base class developers - # should feel free to suggest customizations wrt to if and how such more - # complicated models should be captured. - (NXcs_computer): - doc: | - A collection with one or more computing nodes each with own resources. - This can be as simple as a laptop or the nodes of a cluster computer. - (NXcs_profiling_event): - doc: | - A collection of individual profiling event data which detail e.g. how - much time the app took for certain computational steps and/or how much - memory was consumed during these operations. - - # how to retrieve UUID for cloud computing instances - # https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/identify_ec2_instances.html - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# ee1c82625ec49958695a1a217834bda811147c5ead01f50dac3f9b0e2f0cc020 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Computer science description for performance and profiling data of an application. -# -# Performance monitoring and benchmarking of software is a task where questions -# can be asked at various levels of detail. In general, there are three main -# contributions to performance: -# -# * Hardware capabilities and configuration -# * Software configuration and capabilities -# * Dynamic effects of the system in operation and the system working together -# with eventually multiple computers, especially when these have to exchange -# information across a network and these are used usually by multiple users. -# -# At the most basic level users may wish to document how long e.g. a data -# analysis with a scientific software (app) took. -# A frequent idea is here to answer practical questions like how critical is the -# effect on the workflow of the scientists, i.e. is the analysis possible in -# a few seconds or would it take days if I were to run this analysis on a -# comparable machine? -# For this more qualitative performance monitoring, mainly the order of -# magnitude is relevant, as well as how this was achieved using parallelization -# (i.e. reporting the number of CPU and GPU resources used, the number of -# processes and threads configured, and providing basic details about the computer). -# -# At more advanced levels benchmarks may go as deep as detailed temporal tracking -# of individual processor instructions, their relation to other instructions, the -# state of call stacks; in short eventually the entire app execution history -# and hardware state history. Such analyses are mainly used for performance -# optimization, i.e. by software and hardware developers as well as for -# tracking bugs. Specialized software exists which documents such performance -# data in specifically-formatted event log files or databases. -# -# This base class cannot and should not replace these specific solutions for now. -# Instead, the intention of the base class is to serve scientists at the -# basic level to enable simple monitoring of performance data and log profiling -# data of key algorithmic steps or parts of computational workflows, so that -# these pieces of information can guide users which order of magnitude differences -# should be expected or not. -# -# Developers of application definitions should add additional fields and -# references to e.g. more detailed performance data to which they wish to link -# the metadata in this base class. -# -# -# -# -# Path to the directory from which the tool was called. -# -# -# -# -# Command line call with arguments if applicable. -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC information -# included when the app was started. -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC information -# included when the app terminated or crashed. -# -# -# -# -# Wall-clock time how long the app execution took. This may be in principle -# end_time minus start_time; however usage of eventually more precise timers -# may warrant to use a finer temporal discretization, -# and thus demands a more precise record of the wall-clock time. -# -# -# -# -# Qualifier which specifies with how many nominal processes the app was -# invoked. The main idea behind this field e.g. for apps which use e.g. MPI -# (Message Passing Interface) parallelization is to communicate -# how many processes were used. -# -# For sequentially running apps number_of_processes and number_of_threads -# is 1. If the app uses exclusively GPU parallelization number_of_gpus -# can be larger than 1. If no GPU is used number_of_gpus is 0 even though -# the hardware may have GPUs installed, thus indicating these were not -# used though. -# -# -# -# -# Qualifier how many nominal threads were used at runtime. -# Specifically here the maximum number of threads used for the -# high-level threading library used (e.g. OMP_NUM_THREADS), posix. -# -# -# -# -# Qualifier with how many nominal GPUs the app was invoked at runtime. -# -# -# -# -# -# A collection with one or more computing nodes each with own resources. -# This can be as simple as a laptop or the nodes of a cluster computer. -# -# -# -# -# A collection of individual profiling event data which detail e.g. how -# much time the app took for certain computational steps and/or how much -# memory was consumed during these operations. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcs_profiling_event.yaml b/contributed_definitions/nyaml/NXcs_profiling_event.yaml deleted file mode 100644 index 296db17b2b..0000000000 --- a/contributed_definitions/nyaml/NXcs_profiling_event.yaml +++ /dev/null @@ -1,159 +0,0 @@ -category: base -doc: | - Computer science description of a profiling event. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_processes: | - Number of processes. -type: group -NXcs_profiling_event(NXobject): - start_time(NX_DATE_TIME): - doc: | - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking started. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 time code with local time zone offset to UTC information - included when the event tracking ended. - description(NX_CHAR): - doc: | - Free-text description what was monitored/executed during the event. - elapsed_time(NX_NUMBER): - unit: NX_TIME - doc: | - Wall-clock time how long the event took. - - This may be in principle end_time minus start_time; however usage of - eventually more precise timers may warrant to use a finer temporal - discretization, and thus demand for a more precise record of the - wall-clock time. - - Elapsed time may contain time portions where resources were idling. - number_of_processes(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of processes used (max) during the execution of this event. - number_of_threads(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of threads used (max) during the execution of this event. - number_of_gpus(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of GPUs used (max) during the execution of this event. - max_virtual_memory_snapshot(NX_NUMBER): - unit: NX_ANY - doc: | - Maximum amount of virtual memory allocated per process during the event. - dimensions: - rank: 1 - dim: [[1, n_processes]] - max_resident_memory_snapshot(NX_NUMBER): - unit: NX_ANY - doc: | - Maximum amount of resident memory allocated per process during the event. - dimensions: - rank: 1 - dim: [[1, n_processes]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4e5950718a811a7026a8ca5be648741899b280124fba14a8fb2facadd0c1f0c1 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of processes. -# -# -# -# -# Computer science description of a profiling event. -# -# -# -# ISO 8601 time code with local time zone offset to UTC information -# included when the event tracking started. -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC information -# included when the event tracking ended. -# -# -# -# -# Free-text description what was monitored/executed during the event. -# -# -# -# -# Wall-clock time how long the event took. -# -# This may be in principle end_time minus start_time; however usage of -# eventually more precise timers may warrant to use a finer temporal -# discretization, and thus demand for a more precise record of the -# wall-clock time. -# -# Elapsed time may contain time portions where resources were idling. -# -# -# -# -# Number of processes used (max) during the execution of this event. -# -# -# -# -# Number of threads used (max) during the execution of this event. -# -# -# -# -# Number of GPUs used (max) during the execution of this event. -# -# -# -# -# Maximum amount of virtual memory allocated per process during the event. -# -# -# -# -# -# -# -# Maximum amount of resident memory allocated per process during the event. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXdata_mpes.yaml b/contributed_definitions/nyaml/NXdata_mpes.yaml deleted file mode 100644 index b077d5da73..0000000000 --- a/contributed_definitions/nyaml/NXdata_mpes.yaml +++ /dev/null @@ -1,239 +0,0 @@ -category: base -doc: | - :ref:`NXdata_mpes` describes the plottable data and related dimension scales in photoemission - experiments. - - It extends the NXdata class and provides a glossary of explicitly named axis names - which are typical for photoemission data. -type: group -ignoreExtraFields: true -ignoreExtraAttributes: true -NXdata_mpes(NXdata): - energy(NX_NUMBER): - unit: NX_ENERGY - doc: | - Calibrated energy axis. - - Could be linked from the respective '@reference' field. - \@type: - type: NX_CHAR - doc: | - The energy can be either stored as kinetic or as binding energy. - enumeration: - kinetic: - doc: - - | - Calibrated kinetic energy axis. - - | - xref: - spec: ISO 18115-1:2023 - term: 3.35 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 - binding: - doc: - - | - Calibrated binding energy axis. - - | - xref: - spec: ISO 18115-1:2023 - term: 12.16 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - \@reference: - doc: | - The energy can be dispersed according to different strategies. ``@reference`` points to - the path of a field defining the calibrated axis which the ``energy`` axis refers. - - For example: - @reference: 'entry/process/energy_calibration/calibrated_axis' - @reference: 'entry/process/energy_referencing/calibrated_axis' - kN(NX_NUMBER): - unit: NX_WAVENUMBER - doc: | - One calibrated k-space coordinate. It is envisioned that the axes are named kx, ky, and kz, - in accordance with the calibrations defined in NXprocess_mpes. - - Typically, the vectors in momentum space are defined such that kx and ky comprise the parallel component, - while kz is taken as the perpendicular component. - - It is also possible to define k_parallel and k_perp for the parallel and perpendicular momenta, respectively. - Units are 1/Angström. - angularN(NX_NUMBER): - unit: NX_ANGLE - doc: | - One calibrated angular coordinate. It is envisioned that the axes are name angular0, angular1, etc., - in accordance with the calibrations defined in NXprocess_mpes. - - The angular axes should be named in order of decreasing speed, i.e., angular0 should be - the fastest scan axis and angular1 should be the slow-axis angular coordinate. However, - angular0 may also be second slow axis if the measurement is angularly integrated and angular1 - could also be the second fast axis in the case of simultaneous dispersion in two angular - dimensions. - spatialN(NX_NUMBER): - unit: NX_ANGLE - doc: | - One calibrated spatial coordinate. It is envisioned that the axes are name spatial0, spatial1, etc., - in accordance with the calibrations defined in NXprocess_mpes. - - The spatial axes should be named in order of decreasing speed, i.e., spatial0 should be - the fastest scan axis and spatial1 should be the slow-axis spatial coordinate. However, - spatial0 may also be second slow axis if the measurement is spatially integrated and spatial1 - could also be the second fast axis in the case of simultaneous dispersion in two spatial - dimensions. - delay(NX_NUMBER): - unit: NX_TIME - doc: | - Calibrated delay time. - polarization_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Linear polarization angle of the incoming or outgoing beam. - - In an application definition, this could be a link to - /entry/instrument/beam/incident_polarization_angle or - /entry/instrument/beam/final_polarization_angle if they exist. - ellipticity(NX_FLOAT): - unit: NX_ANGLE - doc: | - Ellipticity of the incoming or outgoing beam. - - Can be any of linear polarization angle (degrees), ellipticity (arb. units). - In an application definition, this could be a link to - /entry/instrument/beam/incident_ellipticity or - /entry/instrument/beam/final_ellipticity if they exist. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 573cec819375e8bb2e4895fc3869450883e1ad5d4756d4784807f3678792460d -# -# -# -# -# -# :ref:`NXdata_mpes` describes the plottable data and related dimension scales in photoemission -# experiments. -# -# It extends the NXdata class and provides a glossary of explicitly named axis names -# which are typical for photoemission data. -# -# -# -# Calibrated energy axis. -# -# Could be linked from the respective '@reference' field. -# -# -# -# The energy can be either stored as kinetic or as binding energy. -# -# -# -# -# Calibrated kinetic energy axis. -# -# This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. -# -# .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 -# -# -# -# -# Calibrated binding energy axis. -# -# This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. -# -# .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 -# -# -# -# -# -# -# The energy can be dispersed according to different strategies. ``@reference`` points to -# the path of a field defining the calibrated axis which the ``energy`` axis refers. -# -# For example: -# @reference: 'entry/process/energy_calibration/calibrated_axis' -# @reference: 'entry/process/energy_referencing/calibrated_axis' -# -# -# -# -# -# One calibrated k-space coordinate. It is envisioned that the axes are named kx, ky, and kz, -# in accordance with the calibrations defined in NXprocess_mpes. -# -# Typically, the vectors in momentum space are defined such that kx and ky comprise the parallel component, -# while kz is taken as the perpendicular component. -# -# It is also possible to define k_parallel and k_perp for the parallel and perpendicular momenta, respectively. -# Units are 1/Angström. -# -# -# -# -# One calibrated angular coordinate. It is envisioned that the axes are name angular0, angular1, etc., -# in accordance with the calibrations defined in NXprocess_mpes. -# -# The angular axes should be named in order of decreasing speed, i.e., angular0 should be -# the fastest scan axis and angular1 should be the slow-axis angular coordinate. However, -# angular0 may also be second slow axis if the measurement is angularly integrated and angular1 -# could also be the second fast axis in the case of simultaneous dispersion in two angular -# dimensions. -# -# -# -# -# One calibrated spatial coordinate. It is envisioned that the axes are name spatial0, spatial1, etc., -# in accordance with the calibrations defined in NXprocess_mpes. -# -# The spatial axes should be named in order of decreasing speed, i.e., spatial0 should be -# the fastest scan axis and spatial1 should be the slow-axis spatial coordinate. However, -# spatial0 may also be second slow axis if the measurement is spatially integrated and spatial1 -# could also be the second fast axis in the case of simultaneous dispersion in two spatial -# dimensions. -# -# -# -# -# Calibrated delay time. -# -# -# -# -# Linear polarization angle of the incoming or outgoing beam. -# -# In an application definition, this could be a link to -# /entry/instrument/beam/incident_polarization_angle or -# /entry/instrument/beam/final_polarization_angle if they exist. -# -# -# -# -# Ellipticity of the incoming or outgoing beam. -# -# Can be any of linear polarization angle (degrees), ellipticity (arb. units). -# In an application definition, this could be a link to -# /entry/instrument/beam/incident_ellipticity or -# /entry/instrument/beam/final_ellipticity if they exist. -# -# -# diff --git a/contributed_definitions/nyaml/NXdata_mpes_detector.yaml b/contributed_definitions/nyaml/NXdata_mpes_detector.yaml deleted file mode 100644 index 86236dbc74..0000000000 --- a/contributed_definitions/nyaml/NXdata_mpes_detector.yaml +++ /dev/null @@ -1,261 +0,0 @@ -category: base -doc: | - :ref:`NXdata_mpes_detector` describes the plottable data and related - dimension scales for raw detector data in photoemission experiments. - - It extends the NXdata class and provides a glossary of explicitly named axis names - which are typical for raw photoemission data. -type: group -ignoreExtraFields: true -ignoreExtraAttributes: true -NXdata_mpes_detector(NXdata): - raw(NX_NUMBER): - doc: | - Raw data before calibration. - pixel_x(NX_FLOAT): - unit: NX_ANY - doc: | - Detector pixel in x direction. - pixel_y(NX_FLOAT): - unit: NX_ANY - doc: | - Detector pixel in y direction. - energy(NX_NUMBER): - unit: NX_ENERGY - doc: | - (Un)calibrated energy axis. - \@type: - type: NX_CHAR - doc: | - The energy can be either stored as kinetic or as binding energy. - enumeration: - kinetic: - doc: - - | - (Un)calibrated kinetic energy axis. - - | - xref: - spec: ISO 18115-1:2023 - term: 3.35 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 - binding: - doc: - - | - (Un)calibrated binding energy axis. - - | - xref: - spec: ISO 18115-1:2023 - term: 12.16 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - kN(NX_NUMBER): - unit: NX_WAVENUMBER - doc: | - One (un)calibrated k-space coordinate. It is envisioned that the axes are named kx, ky, and kz. - - Typically, the vectors in momentum space are defined such that kx and ky comprise the parallel component, - while kz is taken as the perpendicular component. - - It is also possible to define k_parallel and k_perp for the parallel and perpendicular momenta, respectively. - Units are 1/Angström. - angularN(NX_NUMBER): - unit: NX_ANGLE - doc: | - One (un)calibrated angular coordinate. It is envisioned that the axes are name angular0, angular1, etc. - - The angular axes should be named in order of decreasing speed, i.e., angular0 should be - the fastest scan axis and angular1 should be the slow-axis angular coordinate. However, - angular0 may also be second slow axis if the measurement is angularly integrated and angular1 - could also be the second fast axis in the case of simultaneous dispersion in two angular - dimensions. - spatialN(NX_NUMBER): - unit: NX_ANGLE - doc: | - One (un)calibrated spatial coordinate. It is envisioned that the axes are name spatial0, spatial1, etc. - - The spatial axes should be named in order of decreasing speed, i.e., spatial0 should be - the fastest scan axis and spatial1 should be the slow-axis spatial coordinate. However, - spatial0 may also be second slow axis if the measurement is spatially integrated and spatial1 - could also be the second fast axis in the case of simultaneous dispersion in two spatial - dimensions. - - # exists in NXdetector base class - time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - doc: | - Total time of flight. - time_of_flight_adc(NX_FLOAT): - unit: NX_ANY - doc: | - Time-of-flight values, analog-to-digital converted. - delay(NX_NUMBER): - unit: NX_TIME - doc: | - (Un)calibrated delay time. - polarization_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Linear polarization angle of the incoming or outgoing beam. - ellipticity(NX_FLOAT): - unit: NX_ANGLE - doc: | - Ellipticity of the incoming or outgoing beam. - external_AXIS(NX_NUMBER): - unit: NX_ANY - doc: | - Describes an axis which is coming from outside the detectors scope. - - Think of a detector just being triggered for readout by the rest of the experimental - setup - it would just know that it collected N images, which would flatten the external - parameters to one axis, too. - This can then be linked, e.g. with NXcalibration, to the appropriate fields in the instrument - and write it to the top-level NXdata_mpes. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 859f68ddc5c8198cdef216da02ea6316d9a28439fb57da2321a289c8a966d669 -# -# -# -# -# -# :ref:`NXdata_mpes_detector` describes the plottable data and related -# dimension scales for raw detector data in photoemission experiments. -# -# It extends the NXdata class and provides a glossary of explicitly named axis names -# which are typical for raw photoemission data. -# -# -# -# Raw data before calibration. -# -# -# -# -# Detector pixel in x direction. -# -# -# -# -# Detector pixel in y direction. -# -# -# -# -# (Un)calibrated energy axis. -# -# -# -# The energy can be either stored as kinetic or as binding energy. -# -# -# -# -# (Un)calibrated kinetic energy axis. -# -# This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. -# -# .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 -# -# -# -# -# (Un)calibrated binding energy axis. -# -# This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. -# -# .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 -# -# -# -# -# -# -# -# One (un)calibrated k-space coordinate. It is envisioned that the axes are named kx, ky, and kz. -# -# Typically, the vectors in momentum space are defined such that kx and ky comprise the parallel component, -# while kz is taken as the perpendicular component. -# -# It is also possible to define k_parallel and k_perp for the parallel and perpendicular momenta, respectively. -# Units are 1/Angström. -# -# -# -# -# One (un)calibrated angular coordinate. It is envisioned that the axes are name angular0, angular1, etc. -# -# The angular axes should be named in order of decreasing speed, i.e., angular0 should be -# the fastest scan axis and angular1 should be the slow-axis angular coordinate. However, -# angular0 may also be second slow axis if the measurement is angularly integrated and angular1 -# could also be the second fast axis in the case of simultaneous dispersion in two angular -# dimensions. -# -# -# -# -# One (un)calibrated spatial coordinate. It is envisioned that the axes are name spatial0, spatial1, etc. -# -# The spatial axes should be named in order of decreasing speed, i.e., spatial0 should be -# the fastest scan axis and spatial1 should be the slow-axis spatial coordinate. However, -# spatial0 may also be second slow axis if the measurement is spatially integrated and spatial1 -# could also be the second fast axis in the case of simultaneous dispersion in two spatial -# dimensions. -# -# -# -# -# -# Total time of flight. -# -# -# -# -# Time-of-flight values, analog-to-digital converted. -# -# -# -# -# (Un)calibrated delay time. -# -# -# -# -# Linear polarization angle of the incoming or outgoing beam. -# -# -# -# -# Ellipticity of the incoming or outgoing beam. -# -# -# -# -# Describes an axis which is coming from outside the detectors scope. -# -# Think of a detector just being triggered for readout by the rest of the experimental -# setup - it would just know that it collected N images, which would flatten the external -# parameters to one axis, too. -# This can then be linked, e.g. with NXcalibration, to the appropriate fields in the instrument -# and write it to the top-level NXdata_mpes. -# -# -# diff --git a/contributed_definitions/nyaml/NXdeflector.yaml b/contributed_definitions/nyaml/NXdeflector.yaml deleted file mode 100644 index 2f32bc8caa..0000000000 --- a/contributed_definitions/nyaml/NXdeflector.yaml +++ /dev/null @@ -1,150 +0,0 @@ -category: base -doc: | - Deflectors as they are used e.g. in an electron analyser. -type: group -NXdeflector(NXobject): - type(NX_CHAR): - doc: | - Qualitative type of deflector with respect to the number of pole pieces. - enumeration: [dipole, quadrupole, hexapole, octupole] - name(NX_CHAR): - doc: | - Colloquial or short name for the deflector. For manufacturer names and - identifiers use respective manufacturer fields. - (NXfabrication): - description(NX_CHAR): - doc: | - Ideally an identifier, persistent link, or free text which gives - further details about the deflector. - voltage(NX_NUMBER): - unit: NX_VOLTAGE - doc: | - Excitation voltage of the deflector. For dipoles it is a single number. - For higher order multipoles, it is an array. - current(NX_NUMBER): - unit: NX_CURRENT - doc: | - Excitation current of the deflector. For dipoles it is a single number. For - higher orders, it is an array. - offset_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Spatial offset of the deflector in x direction (perpendicular to - ```offset_y```). - offset_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Spatial offset of the deflector in y direction (perpendicular to - ```offset_x```). - \@depends_on: - type: NX_CHAR - doc: | - Specifies the position of the deflector by pointing to the last transformation - in the transformation chain in the NXtransformations group. - (NXtransformations): - doc: | - Collection of axis-based translations and rotations to describe the location and - geometry of the deflector as a component in the instrument. Conventions from the - :ref:`NXtransformations` base class are used. In principle, the McStas coordinate - 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e16416dcbac006d9e2a7fff7c0ed1d61a6bed2d1f6254a419f10f6ab36922cc5 -# -# -# -# -# -# Deflectors as they are used e.g. in an electron analyser. -# -# -# -# Qualitative type of deflector with respect to the number of pole pieces. -# -# -# -# -# -# -# -# -# -# -# Colloquial or short name for the deflector. For manufacturer names and -# identifiers use respective manufacturer fields. -# -# -# -# -# -# Ideally an identifier, persistent link, or free text which gives -# further details about the deflector. -# -# -# -# -# Excitation voltage of the deflector. For dipoles it is a single number. -# For higher order multipoles, it is an array. -# -# -# -# -# Excitation current of the deflector. For dipoles it is a single number. For -# higher orders, it is an array. -# -# -# -# -# Spatial offset of the deflector in x direction (perpendicular to -# ```offset_y```). -# -# -# -# -# Spatial offset of the deflector in y direction (perpendicular to -# ```offset_x```). -# -# -# -# -# Specifies the position of the deflector by pointing to the last transformation -# in the transformation chain in the NXtransformations group. -# -# -# -# -# Collection of axis-based translations and rotations to describe the location and -# geometry of the deflector as a component in the instrument. Conventions from the -# :ref:`NXtransformations` base class are used. In principle, the McStas coordinate -# system is used. The first transformation has to point either to another -# component of the system or . (for pointing to the reference frame) to relate it -# relative to the experimental setup. Typically, the components of a system should -# all be related relative to each other and only one component should relate to -# the reference coordinate system. -# -# -# diff --git a/contributed_definitions/nyaml/NXdistortion.yaml b/contributed_definitions/nyaml/NXdistortion.yaml deleted file mode 100644 index b5e3b15873..0000000000 --- a/contributed_definitions/nyaml/NXdistortion.yaml +++ /dev/null @@ -1,175 +0,0 @@ -category: base -doc: | - Subclass of NXprocess to describe post-processing distortion correction. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays - nsym: | - Number of symmetry points used for distortion correction - ndx: | - Number of points of the matrix distortion field (x direction) - ndy: | - Number of points of the matrix distortion field (y direction) -type: group -NXdistortion(NXobject): - last_process(NX_CHAR): - doc: | - Indicates the name of the last operation applied in the NXprocess sequence. - applied(NX_BOOLEAN): - doc: | - Has the distortion correction been applied? - symmetry(NX_INT): - unit: NX_UNITLESS - doc: | - 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 - original_centre(NX_FLOAT): - unit: NX_UNITLESS - doc: | - For symmetry-guided distortion correction. Here we record the coordinates of the - symmetry centre point. - dimensions: - rank: 1 - dim: [[1, 2]] - original_points(NX_FLOAT): - unit: NX_UNITLESS - doc: | - For symmetry-guided distortion correction. Here we record the coordinates of the - relevant symmetry points. - dimensions: - rank: 2 - dim: [[1, nsym], [2, 2]] - cdeform_field(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Column deformation field for general non-rigid distortion corrections. 2D matrix - holding the column information of the mapping of each original coordinate. - dimensions: - rank: 2 - dim: [[1, ndx], [2, ndy]] - rdeform_field(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Row deformation field for general non-rigid distortion corrections. 2D matrix - holding the row information of the mapping of each original coordinate. - dimensions: - rank: 2 - dim: [[1, ndx], [2, ndy]] - description(NX_CHAR): - doc: | - Description of the procedures employed. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 5129b9e172865cef8b0f8680aaf5e0e1c6c636fcbeca0bbe2b5752dc45a2ce45 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays -# -# -# -# Number of symmetry points used for distortion correction -# -# -# -# -# Number of points of the matrix distortion field (x direction) -# -# -# -# -# Number of points of the matrix distortion field (y direction) -# -# -# -# -# Subclass of NXprocess to describe post-processing distortion correction. -# -# -# -# Indicates the name of the last operation applied in the NXprocess sequence. -# -# -# -# -# Has the distortion correction been applied? -# -# -# -# -# For `symmetry-guided distortion correction`_, -# where a pattern of features is mapped to the regular geometric structure expected -# from the symmetry. Here we record the number of elementary symmetry operations. -# -# .. _symmetry-guided distortion correction: https://www.sciencedirect.com/science/article/abs/pii/S0304399118303474?via%3Dihub -# -# -# -# -# For symmetry-guided distortion correction. Here we record the coordinates of the -# symmetry centre point. -# -# -# -# -# -# -# -# For symmetry-guided distortion correction. Here we record the coordinates of the -# relevant symmetry points. -# -# -# -# -# -# -# -# -# Column deformation field for general non-rigid distortion corrections. 2D matrix -# holding the column information of the mapping of each original coordinate. -# -# -# -# -# -# -# -# -# Row deformation field for general non-rigid distortion corrections. 2D matrix -# holding the row information of the mapping of each original coordinate. -# -# -# -# -# -# -# -# -# Description of the procedures employed. -# -# -# diff --git a/contributed_definitions/nyaml/NXebeam_column.yaml b/contributed_definitions/nyaml/NXebeam_column.yaml deleted file mode 100644 index 7f4bb9fcf6..0000000000 --- a/contributed_definitions/nyaml/NXebeam_column.yaml +++ /dev/null @@ -1,196 +0,0 @@ -category: base -doc: | - Base class for a set of components providing a controllable electron beam. - -# NXebeam_column is an NXobject instead of an NXcomponent to make that -# part "an electron gun" reusable in other context -type: group -NXebeam_column(NXobject): - operation_mode(NX_CHAR): - doc: | - Typically tech-partner, microscope-, and control software-specific - name of the specific operation mode how the ebeam_column and its - components are controlled to achieve a specific illumination condition. - - In most cases users do not know, have to care, or are able to disentangle the - details of the spatiotemporal dynamics of the components of the microscope. - Instead, they rely on the assumption that the microscope and control software - work as expected. Selecting then a specific operation_mode assures some level - of reproducibility in the illumination conditions. - (NXfabrication): - (NXchamber): - electron_source(NXsource): - doc: | - The source which creates the electron beam. - name(NX_CHAR): - doc: | - Given name/alias. - (NXfabrication): - voltage(NX_NUMBER): - unit: NX_VOLTAGE - doc: | - Voltage relevant to compute the energy of the electrons - immediately after they left the gun. - probe(NX_CHAR): - doc: | - Type of radiation. - enumeration: [electron] - emitter_type(NX_CHAR): - doc: | - Emitter type used to create the beam. - - If the emitter type is other, give further details - in the description field. - - # enumeration: [filament, schottky, cold_cathode_field_emitter, other] - emitter_material(NX_CHAR): - doc: | - Material of which the emitter is build, e.g. the filament material. - - # MK could be made an instance of NXsample - description(NX_CHAR): - doc: | - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - - # NEW ISSUE: details about the life/up-time of the source - # relevant from maintenance point of view - (NXtransformations): - doc: | - Collection of axis-based translations and rotations to describe the - location and geometry of the component in the instrument. - (NXlens_em): - (NXaperture): - (NXmonochromator): - (NXcorrector_cs): - (NXcomponent): - (NXsensor): - (NXactuator): - (NXbeam): - doc: | - Individual characterization results for the position, shape, - and characteristics of the electron beam. - - :ref:`NXtransformations` should be used to specify the location - of the position at which the beam was probed. - (NXdeflector): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 600e3b74ca13f402922ec4259cd4a2eef61c5b50f202d876d7d8b3839a69d631 -# -# -# -# -# -# -# Base class for a set of components providing a controllable electron beam. -# -# -# -# Typically tech-partner, microscope-, and control software-specific -# name of the specific operation mode how the ebeam_column and its -# components are controlled to achieve a specific illumination condition. -# -# In most cases users do not know, have to care, or are able to disentangle the -# details of the spatiotemporal dynamics of the components of the microscope. -# Instead, they rely on the assumption that the microscope and control software -# work as expected. Selecting then a specific operation_mode assures some level -# of reproducibility in the illumination conditions. -# -# -# -# -# -# -# The source which creates the electron beam. -# -# -# -# Given name/alias. -# -# -# -# -# -# Voltage relevant to compute the energy of the electrons -# immediately after they left the gun. -# -# -# -# -# Type of radiation. -# -# -# -# -# -# -# -# Emitter type used to create the beam. -# -# If the emitter type is other, give further details -# in the description field. -# -# -# -# -# -# Material of which the emitter is build, e.g. the filament material. -# -# -# -# -# -# Ideally, a (globally) unique persistent identifier, link, -# or text to a resource which gives further details. -# -# -# -# -# -# Collection of axis-based translations and rotations to describe the -# location and geometry of the component in the instrument. -# -# -# -# -# -# -# -# -# -# -# -# -# Individual characterization results for the position, shape, -# and characteristics of the electron beam. -# -# :ref:`NXtransformations` should be used to specify the location -# of the position at which the beam was probed. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXelectron_level.yaml b/contributed_definitions/nyaml/NXelectron_level.yaml deleted file mode 100644 index aabb741cc8..0000000000 --- a/contributed_definitions/nyaml/NXelectron_level.yaml +++ /dev/null @@ -1,1465 +0,0 @@ -category: base -doc: | - Electronic level probed in X-ray spectroscopy or resonance experiments. -type: group -NXelectron_level(NXobject): - element: - doc: | - Symbol of the chemical element. - - For each, the atomic number, common English name, and standard atomic weight are also given. - enumeration: - H: - doc: | - Z=1, name="hydrogen", standard_atomic_weight=1.0078 - He: - doc: | - Z=2, name="helium", standard_atomic_weight=4.0026 - Li: - doc: | - Z=3, name="lithium", standard_atomic_weight=6.94 - Be: - doc: | - Z=4, name="beryllium", standard_atomic_weight=9.0122 - B: - doc: | - Z=5, name="boron", standard_atomic_weight=10.81 - C: - doc: | - Z=6, name="carbon", standard_atomic_weight=12.011 - N: - doc: | - Z=7, name="nitrogen", standard_atomic_weight=14.007 - O: - doc: | - Z=8, name="oxygen", standard_atomic_weight=15.999 - F: - doc: | - Z=9, name="fluorine", standard_atomic_weight=18.9984 - Ne: - doc: | - Z=10, name="neon", standard_atomic_weight=20.1797 - Na: - doc: | - Z=11, name="sodium", standard_atomic_weight=22.9898 - Mg: - doc: | - Z=12, name="magnesium", standard_atomic_weight=24.305 - Al: - doc: | - Z=13, name="aluminum", standard_atomic_weight=26.9815 - Si: - doc: | - Z=14, name="silicon", standard_atomic_weight=28.085 - P: - doc: | - Z=15, name="phosphorus", standard_atomic_weight=30.9738 - S: - doc: | - Z=16, name="sulfur", standard_atomic_weight=32.06 - Cl: - doc: | - Z=17, name="chlorine", standard_atomic_weight=35.453 - Ar: - doc: | - Z=18, name="argon", standard_atomic_weight=39.948 - K: - doc: | - Z=19, name="potassium", standard_atomic_weight=39.0983 - Ca: - doc: | - Z=20, name="calcium", standard_atomic_weight=40.078 - Sc: - doc: | - Z=21, name="scandium", standard_atomic_weight=44.9559 - Ti: - doc: | - Z=22, name="titanium", standard_atomic_weight=47.867 - V: - doc: | - Z=23, name="vanadium", standard_atomic_weight=50.9415 - Cr: - doc: | - Z=24, name="chromium", standard_atomic_weight=51.996 - Mn: - doc: | - Z=25, name="manganese", standard_atomic_weight=54.938 - Fe: - doc: | - Z=26, name="iron", standard_atomic_weight=55.845 - Co: - doc: | - Z=27, name="cobalt", standard_atomic_weight=58.9332 - Ni: - doc: | - Z=28, name="nickel", standard_atomic_weight=58.6934 - Cu: - doc: | - Z=29, name="copper", standard_atomic_weight=63.546 - Zn: - doc: | - Z=30, name="zinc", standard_atomic_weight=65.38 - Ga: - doc: | - Z=31, name="gallium", standard_atomic_weight=69.72 - Ge: - doc: | - Z=32, name="germanium", standard_atomic_weight=72.63 - As: - doc: | - Z=33, name="arsenic", standard_atomic_weight=74.9216 - Se: - doc: | - Z=34, name="selenium", standard_atomic_weight=78.971 - Br: - doc: | - Z=35, name="bromine", standard_atomic_weight=79.904 - Kr: - doc: | - Z=36, name="krypton", standard_atomic_weight=83.798 - Rb: - doc: | - Z=37, name="rubidium", standard_atomic_weight=85.4678 - Sr: - doc: | - Z=38, name="strontium", standard_atomic_weight=87.62 - Y: - doc: | - Z=39, name="yttrium", standard_atomic_weight=88.9058 - Zr: - doc: | - Z=40, name="zirconium", standard_atomic_weight=91.224 - Nb: - doc: | - Z=41, name="niobium", standard_atomic_weight=92.9064 - Mo: - doc: | - Z=42, name="molybdenum", standard_atomic_weight=95.95 - Tc: - doc: | - Z=43, name="technetium", standard_atomic_weight=97.907 - Ru: - doc: | - Z=44, name="ruthenium", standard_atomic_weight=101.07 - Rh: - doc: | - Z=45, name="rhodium", standard_atomic_weight=102.906 - Pd: - doc: | - Z=46, name="palladium", standard_atomic_weight=106.42 - Ag: - doc: | - Z=47, name="silver", standard_atomic_weight=107.868 - Cd: - doc: | - Z=48, name="cadmium", standard_atomic_weight=112.414 - In: - doc: | - Z=49, name="indium", standard_atomic_weight=114.818 - Sn: - doc: | - Z=50, name="tin", standard_atomic_weight=118.71 - Sb: - doc: | - Z=51, name="antimony", standard_atomic_weight=121.76 - Te: - doc: | - Z=52, name="tellurium", standard_atomic_weight=127.6 - I: - doc: | - Z=53, name="iodine", standard_atomic_weight=126.905 - Xe: - doc: | - Z=54, name="xenon", standard_atomic_weight=131.293 - Cs: - doc: | - Z=55, name="cesium", standard_atomic_weight=132.905 - Ba: - doc: | - Z=56, name="barium", standard_atomic_weight=137.327 - La: - doc: | - Z=57, name="lanthanum", standard_atomic_weight=138.905 - Ce: - doc: | - Z=58, name="cerium", standard_atomic_weight=140.116 - Pr: - doc: | - Z=59, name="praseodymium", standard_atomic_weight=140.908 - Nd: - doc: | - Z=60, name="neodymium", standard_atomic_weight=144.242 - Pm: - doc: | - Z=61, name="promethium", standard_atomic_weight=145.0 - Sm: - doc: | - Z=62, name="samarium", standard_atomic_weight=150.36 - Eu: - doc: | - Z=63, name="europium", standard_atomic_weight=151.96 - Gd: - doc: | - Z=64, name="gadolinium", standard_atomic_weight=157.25 - Tb: - doc: | - Z=65, name="terbium", standard_atomic_weight=158.925 - Dy: - doc: | - Z=66, name="dysprosium", standard_atomic_weight=162.5 - Ho: - doc: | - Z=67, name="holmium", standard_atomic_weight=164.93 - Er: - doc: | - Z=68, name="erbium", standard_atomic_weight=167.259 - Tm: - doc: | - Z=69, name="thulium", standard_atomic_weight=168.934 - Yb: - doc: | - Z=70, name="ytterbium", standard_atomic_weight=173.045 - Lu: - doc: | - Z=71, name="lutetium", standard_atomic_weight=174.967 - Hf: - doc: | - Z=72, name="hafnium", standard_atomic_weight=178.49 - Ta: - doc: | - Z=73, name="tantalum", standard_atomic_weight=180.948 - W: - doc: | - Z=74, name="tungsten", standard_atomic_weight=183.84 - Re: - doc: | - Z=75, name="rhenium", standard_atomic_weight=186.207 - Os: - doc: | - Z=76, name="osmium", standard_atomic_weight=190.23 - Ir: - doc: | - Z=77, name="iridium", standard_atomic_weight=192.217 - Pt: - doc: | - Z=78, name="platinum", standard_atomic_weight=195.084 - Au: - doc: | - Z=79, name="gold", standard_atomic_weight=196.967 - Hg: - doc: | - Z=80, name="mercury", standard_atomic_weight=200.592 - Tl: - doc: | - Z=81, name="thallium", standard_atomic_weight=204.383 - Pb: - doc: | - Z=82, name="lead", standard_atomic_weight=207.2 - Bi: - doc: | - Z=83, name="bismuth", standard_atomic_weight=208.98 - Po: - doc: | - Z=84, name="polonium", standard_atomic_weight=209.0 - At: - doc: | - Z=85, name="astatine", standard_atomic_weight=210.0 - Rn: - doc: | - Z=86, name="radon", standard_atomic_weight=222.0 - Fr: - doc: | - Z=87, name="francium", standard_atomic_weight=223.0 - Ra: - doc: | - Z=88, name="radium", standard_atomic_weight=226.0 - Ac: - doc: | - Z=89, name="actinium", standard_atomic_weight=227.0 - Th: - doc: | - Z=90, name="thorium", standard_atomic_weight=232.038 - Pa: - doc: | - Z=91, name="protactinium", standard_atomic_weight=231.036 - U: - doc: | - Z=92, name="uranium", standard_atomic_weight=238.029 - Np: - doc: | - Z=93, name="neptunium", standard_atomic_weight=237.048 - Pu: - doc: | - Z=94, name="plutonium", standard_atomic_weight=239.052 - Am: - doc: | - Z=95, name="americium", standard_atomic_weight=243.0 - Cm: - doc: | - Z=96, name="curium", standard_atomic_weight=247.0 - Bk: - doc: | - Z=97, name="berkelium", standard_atomic_weight=247.0 - Cf: - doc: | - Z=98, name="californium", standard_atomic_weight=251.0 - Es: - doc: | - Z=99, name="einsteinium", standard_atomic_weight=252 - Fm: - doc: | - Z=100, name="fermium", standard_atomic_weight=257 - Md: - doc: | - Z=101, name="mendelevium", standard_atomic_weight=258 - "No": - doc: | - Z=102, name="nobelium", standard_atomic_weight=259 - Lr: - doc: | - Z=103, name="lawrencium", standard_atomic_weight=266 - Rf: - doc: | - Z=104, name="rutherfordium", standard_atomic_weight=267 - Db: - doc: | - Z=105, name="dubnium", standard_atomic_weight=268 - Sg: - doc: | - Z=106, name="seaborgium", standard_atomic_weight=269 - Bh: - doc: | - Z=107, name="bohrium", standard_atomic_weight=270 - Hs: - doc: | - Z=108, name="hassium", standard_atomic_weight=269 - Mt: - doc: | - Z=109, name="meitnerium", standard_atomic_weight=278 - Ds: - doc: | - Z=110, name="darmstadtium", standard_atomic_weight=281 - Rg: - doc: | - Z=111, name="roentgenium", standard_atomic_weight=282 - Cn: - doc: | - Z=112, name="copernicium", standard_atomic_weight=285 - Nh: - doc: | - Z=113, name="nihonium", standard_atomic_weight=286 - Fl: - doc: | - Z=114, name="flerovium", standard_atomic_weight=289 - Mc: - doc: | - Z=115, name="moscovium", standard_atomic_weight=290 - Lv: - doc: | - Z=116, name="livermorium", standard_atomic_weight=293 - Ts: - doc: | - Z=117, name="tennessine", standard_atomic_weight=294 - Og: - doc: | - Z=118, name="oganesson", standard_atomic_weight=294 - level_iupac: - doc: | - IUPAC symbol of the electronic level. - For each level, the electronic orbital configuration is also given - - For reference, see Jenkins, R., Manne, R., Robin, R., & Senemaud, C. (1991). - IUPAC—nomenclature system for x-ray spectroscopy. X-Ray Spectrometry, 20(3), 149-155. - enumeration: - K: - doc: | - same as 1s in level_xray - L1: - doc: | - 2s - L2: - doc: | - 2p_{1/2} - L3: - doc: | - 2p_{3/2} - M1: - doc: | - 3s - M2: - doc: | - 3p_{1/2} - M3: - doc: | - 3p_{3/2} - M4: - doc: | - 3d_{3/2} - M5: - doc: | - 3d_{5/2} - N1: - doc: | - 4s - N2: - doc: | - 4p_{1/2} - N3: - doc: | - 4p_{3/2} - N4: - doc: | - 4d_{3/2} - N5: - doc: | - 4d_{5/2} - N6: - doc: | - 4f_{5/2} - N7: - doc: | - 4f_{7/2} - O1: - doc: | - 5s - O2: - doc: | - 5p_{1/2} - O3: - doc: | - 5p_{3/2} - O4: - doc: | - 5d_{3/2} - O5: - doc: | - 5d_{5/2} - O6: - doc: | - 5f_{5/2} - O7: - doc: | - 5f_{7/2} - P1: - doc: | - 6s - P2: - doc: | - 6p_{1/2} - P3: - doc: | - 6p_{3/2} - level_electron_config: - doc: | - Electronic orbital configuration of the electronic level. - enumeration: - 1s: - doc: | - same as K in level_xray - 2s: - doc: | - L1 - 2p1/2: - doc: | - L3 - 3s: - doc: | - M1 - 3p1/2: - doc: | - M2 - 3p3/2: - doc: | - M3 - 3d3/2: - doc: | - M4 - 3d5/2: - doc: | - M5 - 4s: - doc: | - N1 - 4p1/2: - doc: | - N2 - 4p3/2: - doc: | - N3 - 4d3/2: - doc: | - N4 - 4d5/2: - doc: | - N5 - 4f5/2: - doc: | - N6 - 4f7/2: - doc: | - N7 - 5s: - doc: | - O1 - 5p1/2: - doc: | - O2 - 5p3/2: - doc: | - O3 - 5d3/2: - doc: | - O4 - 5d5/2: - doc: | - O5 - 5f5/2: - doc: | - O6 - 5f7/2: - doc: | - O7 - 6s: - doc: | - P1 - 6p1/2: - doc: | - P2 - 6p3/2: - doc: | - P3 - \@description: - doc: | - description of X-ray electronic level - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 696e3b5fea519fce5a310d8d2a6316258cb6183e7898a4f87521904143d007e4 -# -# -# -# -# -# Electronic level probed in X-ray spectroscopy or resonance experiments. -# -# -# -# Symbol of the chemical element. -# -# For each, the atomic number, common English name, and standard atomic weight are also given. -# -# -# -# -# Z=1, name="hydrogen", standard_atomic_weight=1.0078 -# -# -# -# -# Z=2, name="helium", standard_atomic_weight=4.0026 -# -# -# -# -# Z=3, name="lithium", standard_atomic_weight=6.94 -# -# -# -# -# Z=4, name="beryllium", standard_atomic_weight=9.0122 -# -# -# -# -# Z=5, name="boron", standard_atomic_weight=10.81 -# -# -# -# -# Z=6, name="carbon", standard_atomic_weight=12.011 -# -# -# -# -# Z=7, name="nitrogen", standard_atomic_weight=14.007 -# -# -# -# -# Z=8, name="oxygen", standard_atomic_weight=15.999 -# -# -# -# -# Z=9, name="fluorine", standard_atomic_weight=18.9984 -# -# -# -# -# Z=10, name="neon", standard_atomic_weight=20.1797 -# -# -# -# -# Z=11, name="sodium", standard_atomic_weight=22.9898 -# -# -# -# -# Z=12, name="magnesium", standard_atomic_weight=24.305 -# -# -# -# -# Z=13, name="aluminum", standard_atomic_weight=26.9815 -# -# -# -# -# Z=14, name="silicon", standard_atomic_weight=28.085 -# -# -# -# -# Z=15, name="phosphorus", standard_atomic_weight=30.9738 -# -# -# -# -# Z=16, name="sulfur", standard_atomic_weight=32.06 -# -# -# -# -# Z=17, name="chlorine", standard_atomic_weight=35.453 -# -# -# -# -# Z=18, name="argon", standard_atomic_weight=39.948 -# -# -# -# -# Z=19, name="potassium", standard_atomic_weight=39.0983 -# -# -# -# -# Z=20, name="calcium", standard_atomic_weight=40.078 -# -# -# -# -# Z=21, name="scandium", standard_atomic_weight=44.9559 -# -# -# -# -# Z=22, name="titanium", standard_atomic_weight=47.867 -# -# -# -# -# Z=23, name="vanadium", standard_atomic_weight=50.9415 -# -# -# -# -# Z=24, name="chromium", standard_atomic_weight=51.996 -# -# -# -# -# Z=25, name="manganese", standard_atomic_weight=54.938 -# -# -# -# -# Z=26, name="iron", standard_atomic_weight=55.845 -# -# -# -# -# Z=27, name="cobalt", standard_atomic_weight=58.9332 -# -# -# -# -# Z=28, name="nickel", standard_atomic_weight=58.6934 -# -# -# -# -# Z=29, name="copper", standard_atomic_weight=63.546 -# -# -# -# -# Z=30, name="zinc", standard_atomic_weight=65.38 -# -# -# -# -# Z=31, name="gallium", standard_atomic_weight=69.72 -# -# -# -# -# Z=32, name="germanium", standard_atomic_weight=72.63 -# -# -# -# -# Z=33, name="arsenic", standard_atomic_weight=74.9216 -# -# -# -# -# Z=34, name="selenium", standard_atomic_weight=78.971 -# -# -# -# -# Z=35, name="bromine", standard_atomic_weight=79.904 -# -# -# -# -# Z=36, name="krypton", standard_atomic_weight=83.798 -# -# -# -# -# Z=37, name="rubidium", standard_atomic_weight=85.4678 -# -# -# -# -# Z=38, name="strontium", standard_atomic_weight=87.62 -# -# -# -# -# Z=39, name="yttrium", standard_atomic_weight=88.9058 -# -# -# -# -# Z=40, name="zirconium", standard_atomic_weight=91.224 -# -# -# -# -# Z=41, name="niobium", standard_atomic_weight=92.9064 -# -# -# -# -# Z=42, name="molybdenum", standard_atomic_weight=95.95 -# -# -# -# -# Z=43, name="technetium", standard_atomic_weight=97.907 -# -# -# -# -# Z=44, name="ruthenium", standard_atomic_weight=101.07 -# -# -# -# -# Z=45, name="rhodium", standard_atomic_weight=102.906 -# -# -# -# -# Z=46, name="palladium", standard_atomic_weight=106.42 -# -# -# -# -# Z=47, name="silver", standard_atomic_weight=107.868 -# -# -# -# -# Z=48, name="cadmium", standard_atomic_weight=112.414 -# -# -# -# -# Z=49, name="indium", standard_atomic_weight=114.818 -# -# -# -# -# Z=50, name="tin", standard_atomic_weight=118.71 -# -# -# -# -# Z=51, name="antimony", standard_atomic_weight=121.76 -# -# -# -# -# Z=52, name="tellurium", standard_atomic_weight=127.6 -# -# -# -# -# Z=53, name="iodine", standard_atomic_weight=126.905 -# -# -# -# -# Z=54, name="xenon", standard_atomic_weight=131.293 -# -# -# -# -# Z=55, name="cesium", standard_atomic_weight=132.905 -# -# -# -# -# Z=56, name="barium", standard_atomic_weight=137.327 -# -# -# -# -# Z=57, name="lanthanum", standard_atomic_weight=138.905 -# -# -# -# -# Z=58, name="cerium", standard_atomic_weight=140.116 -# -# -# -# -# Z=59, name="praseodymium", standard_atomic_weight=140.908 -# -# -# -# -# Z=60, name="neodymium", standard_atomic_weight=144.242 -# -# -# -# -# Z=61, name="promethium", standard_atomic_weight=145.0 -# -# -# -# -# Z=62, name="samarium", standard_atomic_weight=150.36 -# -# -# -# -# Z=63, name="europium", standard_atomic_weight=151.96 -# -# -# -# -# Z=64, name="gadolinium", standard_atomic_weight=157.25 -# -# -# -# -# Z=65, name="terbium", standard_atomic_weight=158.925 -# -# -# -# -# Z=66, name="dysprosium", standard_atomic_weight=162.5 -# -# -# -# -# Z=67, name="holmium", standard_atomic_weight=164.93 -# -# -# -# -# Z=68, name="erbium", standard_atomic_weight=167.259 -# -# -# -# -# Z=69, name="thulium", standard_atomic_weight=168.934 -# -# -# -# -# Z=70, name="ytterbium", standard_atomic_weight=173.045 -# -# -# -# -# Z=71, name="lutetium", standard_atomic_weight=174.967 -# -# -# -# -# Z=72, name="hafnium", standard_atomic_weight=178.49 -# -# -# -# -# Z=73, name="tantalum", standard_atomic_weight=180.948 -# -# -# -# -# Z=74, name="tungsten", standard_atomic_weight=183.84 -# -# -# -# -# Z=75, name="rhenium", standard_atomic_weight=186.207 -# -# -# -# -# Z=76, name="osmium", standard_atomic_weight=190.23 -# -# -# -# -# Z=77, name="iridium", standard_atomic_weight=192.217 -# -# -# -# -# Z=78, name="platinum", standard_atomic_weight=195.084 -# -# -# -# -# Z=79, name="gold", standard_atomic_weight=196.967 -# -# -# -# -# Z=80, name="mercury", standard_atomic_weight=200.592 -# -# -# -# -# Z=81, name="thallium", standard_atomic_weight=204.383 -# -# -# -# -# Z=82, name="lead", standard_atomic_weight=207.2 -# -# -# -# -# Z=83, name="bismuth", standard_atomic_weight=208.98 -# -# -# -# -# Z=84, name="polonium", standard_atomic_weight=209.0 -# -# -# -# -# Z=85, name="astatine", standard_atomic_weight=210.0 -# -# -# -# -# Z=86, name="radon", standard_atomic_weight=222.0 -# -# -# -# -# Z=87, name="francium", standard_atomic_weight=223.0 -# -# -# -# -# Z=88, name="radium", standard_atomic_weight=226.0 -# -# -# -# -# Z=89, name="actinium", standard_atomic_weight=227.0 -# -# -# -# -# Z=90, name="thorium", standard_atomic_weight=232.038 -# -# -# -# -# Z=91, name="protactinium", standard_atomic_weight=231.036 -# -# -# -# -# Z=92, name="uranium", standard_atomic_weight=238.029 -# -# -# -# -# Z=93, name="neptunium", standard_atomic_weight=237.048 -# -# -# -# -# Z=94, name="plutonium", standard_atomic_weight=239.052 -# -# -# -# -# Z=95, name="americium", standard_atomic_weight=243.0 -# -# -# -# -# Z=96, name="curium", standard_atomic_weight=247.0 -# -# -# -# -# Z=97, name="berkelium", standard_atomic_weight=247.0 -# -# -# -# -# Z=98, name="californium", standard_atomic_weight=251.0 -# -# -# -# -# Z=99, name="einsteinium", standard_atomic_weight=252 -# -# -# -# -# Z=100, name="fermium", standard_atomic_weight=257 -# -# -# -# -# Z=101, name="mendelevium", standard_atomic_weight=258 -# -# -# -# -# Z=102, name="nobelium", standard_atomic_weight=259 -# -# -# -# -# Z=103, name="lawrencium", standard_atomic_weight=266 -# -# -# -# -# Z=104, name="rutherfordium", standard_atomic_weight=267 -# -# -# -# -# Z=105, name="dubnium", standard_atomic_weight=268 -# -# -# -# -# Z=106, name="seaborgium", standard_atomic_weight=269 -# -# -# -# -# Z=107, name="bohrium", standard_atomic_weight=270 -# -# -# -# -# Z=108, name="hassium", standard_atomic_weight=269 -# -# -# -# -# Z=109, name="meitnerium", standard_atomic_weight=278 -# -# -# -# -# Z=110, name="darmstadtium", standard_atomic_weight=281 -# -# -# -# -# Z=111, name="roentgenium", standard_atomic_weight=282 -# -# -# -# -# Z=112, name="copernicium", standard_atomic_weight=285 -# -# -# -# -# Z=113, name="nihonium", standard_atomic_weight=286 -# -# -# -# -# Z=114, name="flerovium", standard_atomic_weight=289 -# -# -# -# -# Z=115, name="moscovium", standard_atomic_weight=290 -# -# -# -# -# Z=116, name="livermorium", standard_atomic_weight=293 -# -# -# -# -# Z=117, name="tennessine", standard_atomic_weight=294 -# -# -# -# -# Z=118, name="oganesson", standard_atomic_weight=294 -# -# -# -# -# -# -# IUPAC symbol of the electronic level. -# For each level, the electronic orbital configuration is also given -# -# For reference, see Jenkins, R., Manne, R., Robin, R., & Senemaud, C. (1991). -# IUPAC—nomenclature system for x-ray spectroscopy. X-Ray Spectrometry, 20(3), 149-155. -# -# -# -# -# same as 1s in level_xray -# -# -# -# -# 2s -# -# -# -# -# 2p_{1/2} -# -# -# -# -# 2p_{3/2} -# -# -# -# -# 3s -# -# -# -# -# 3p_{1/2} -# -# -# -# -# 3p_{3/2} -# -# -# -# -# 3d_{3/2} -# -# -# -# -# 3d_{5/2} -# -# -# -# -# 4s -# -# -# -# -# 4p_{1/2} -# -# -# -# -# 4p_{3/2} -# -# -# -# -# 4d_{3/2} -# -# -# -# -# 4d_{5/2} -# -# -# -# -# 4f_{5/2} -# -# -# -# -# 4f_{7/2} -# -# -# -# -# 5s -# -# -# -# -# 5p_{1/2} -# -# -# -# -# 5p_{3/2} -# -# -# -# -# 5d_{3/2} -# -# -# -# -# 5d_{5/2} -# -# -# -# -# 5f_{5/2} -# -# -# -# -# 5f_{7/2} -# -# -# -# -# 6s -# -# -# -# -# 6p_{1/2} -# -# -# -# -# 6p_{3/2} -# -# -# -# -# -# -# Electronic orbital configuration of the electronic level. -# -# -# -# -# same as K in level_xray -# -# -# -# -# L1 -# -# -# -# -# L3 -# -# -# -# -# M1 -# -# -# -# -# M2 -# -# -# -# -# M3 -# -# -# -# -# M4 -# -# -# -# -# M5 -# -# -# -# -# N1 -# -# -# -# -# N2 -# -# -# -# -# N3 -# -# -# -# -# N4 -# -# -# -# -# N5 -# -# -# -# -# N6 -# -# -# -# -# N7 -# -# -# -# -# O1 -# -# -# -# -# O2 -# -# -# -# -# O3 -# -# -# -# -# O4 -# -# -# -# -# O5 -# -# -# -# -# O6 -# -# -# -# -# O7 -# -# -# -# -# P1 -# -# -# -# -# P2 -# -# -# -# -# P3 -# -# -# -# -# -# -# description of X-ray electronic level -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# diff --git a/contributed_definitions/nyaml/NXelectronanalyser.yaml b/contributed_definitions/nyaml/NXelectronanalyser.yaml deleted file mode 100644 index 7589b64dd7..0000000000 --- a/contributed_definitions/nyaml/NXelectronanalyser.yaml +++ /dev/null @@ -1,542 +0,0 @@ -category: base -doc: -- | - Basic class for describing a electron analyzer. -- | - xref: - spec: ISO 18115-1:2023 - term: 12.59 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.59 -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays - nfa: | - Number of fast axes (axes acquired simultaneously, without scanning a - physical quantity) - nsa: | - Number of slow axes (axes acquired scanning a physical quantity) - n_transmission_function: | - Number of data points in the transmission function. -type: group -NXelectronanalyser(NXobject): - description(NX_CHAR): - doc: | - Free text description of the type of the detector - name(NX_CHAR): - doc: | - Name or model of the equipment - \@short_name: - type: NX_CHAR - doc: | - Acronym or other shorthand name - work_function(NX_FLOAT): - unit: NX_ENERGY - doc: | - Work function of the electron analyser. - - The work function of a uniform surface of a conductor is the minimum energy required to remove - an electron from the interior of the solid to a vacuum level immediately outside the solid surface. - - The kinetic energy :math:`E_K` of a photoelectron emitted from an energy-level with binding energy - :math:`E_B` below the Fermi level is given by :math:`E_K = h\nu - E_B - W = h\nu - E_B - e \phi_{\mathrm{sample}}`. - Here, :math:`W = e \phi_{\mathrm{sample}}` is the work function of the sample surface (with the potential difference :math:`\phi_{\mathrm{sample}}` - between the electrochemical potential of electrons in the bulk and the electrostatic potential of an electron in the vacuum just outside the surface). - - In PES measurements, the sample and the spectrometer (with work function :math:`\phi_{\mathrm{spectr.}}`) - are electrically connected and therefore their Fermi levels are aligned. Due to the difference in local - vacuum level between the sample and spectrometer, there exists an electric potential difference (contact potential) - :math:`\Delta\phi = \phi_{\mathrm{sample}} - \phi_{\mathrm{spectr.}}`. The measured kinetic energy of - a photoelectron in PES is therefore given by - :math:`E_K^{\mathrm{meas.}} = h\nu - E_B + \Delta \phi = h\nu - E_B - e \phi_{\mathrm{spectr.}}`. - As a result, the measured kinetic energy :math:`E_K^{\mathrm{meas.}}` of a photoelectron is `independent` - of the sample work function. Nonetheless, the work function :math:`\phi_s` needs to be known to - accurately determine the binding energy scale. - voltage_energy_range(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - Energy range of the voltage supplies. This influences the noise of the supplies, - and thereby the energy resolution. - energy_resolution(NXresolution): - doc: | - Energy resolution of the analyser with the current setting. May be linked from an - NXcalibration. - physical_quantity: - enumeration: [energy] - resolution(NX_FLOAT): - unit: NX_ENERGY - doc: - - | - Minimum distinguishable energy separation in the energy spectra. - - | - xref: - spec: ISO 18115-1:2023 - term: 10.24 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 - resolution_errors(NX_FLOAT): - unit: NX_ENERGY - relative_resolution(NX_FLOAT): - doc: - - | - Ratio of the energy resolution of the electron analyser at a specified energy - value to that energy value. - - | - xref: - spec: ISO 18115-1:2023 - term: 10.7 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 - momentum_resolution(NXresolution): - doc: | - Momentum resolution of the electron analyser (FWHM) - physical_quantity: - enumeration: [momentum] - resolution(NX_FLOAT): - unit: NX_WAVENUMBER - resolution_errors(NX_FLOAT): - unit: NX_WAVENUMBER - angular_resolution(NXresolution): - doc: | - Angular resolution of the electron analyser (FWHM) - physical_quantity: - enumeration: [angle] - resolution(NX_FLOAT): - unit: NX_ANGLE - resolution_errors(NX_FLOAT): - unit: NX_ANGLE - spatial_resolution(NXresolution): - doc: - - | - Spatial resolution of the electron analyser (Airy disk radius) - - | - xref: - spec: ISO 18115-1:2023 - term: 10.14 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.15 - physical_quantity: - enumeration: [length] - resolution(NX_FLOAT): - unit: NX_LENGTH - resolution_errors(NX_FLOAT): - unit: NX_LENGTH - fast_axes(NX_CHAR): - doc: | - 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. - dimensions: - rank: 1 - dim: [[1, nfa]] - slow_axes(NX_CHAR): - doc: | - List of the axes that are acquired by scanning a physical parameter, listed in - order of decreasing speed. See fast_axes for examples. - dimensions: - rank: 1 - dim: [[1, nsa]] - transmission_function(NXdata): - doc: - - | - Transmission function of the electron analyser. - - | - The transmission function (TF) specifies the detection efficiency per solid angle for electrons of - different kinetic energy passing through the electron analyser. It depends on the spectrometer - geometry as well as operation settings such as lens mode and pass energy. - The transmission function is usually given as relative intensity vs. kinetic energy. - - | - The TF is used for calibration of the intensity scale in quantitative XPS. Without proper - transmission correction, a comparison of results measured from the same sample using different - operating modes for an instrument would show significant variations in atomic - concentrations. - - | - xref: - spec: ISO 18115-1:2023 - term: 7.15 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:7.15 - \@signal: - enumeration: [relative_intensity] - \@axes: - enumeration: [kinetic_energy] - kinetic_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - Kinetic energy values - dimensions: - rank: 1 - dim: [[1, n_transmission_function]] - relative_intensity(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Relative transmission efficiency for the given kinetic energies - dimensions: - rank: 1 - dim: [[1, n_transmission_function]] - depends_on(NX_CHAR): - doc: | - Refers to the last transformation specifying the position of the electron analyser - in the NXtransformations chain. - (NXtransformations): - doc: | - 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. - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - (NXcollectioncolumn): - doc: | - Describes the electron collection (spatial and momentum imaging) column - (NXenergydispersion): - doc: | - Describes the energy dispersion section - (NXspindispersion): - doc: | - Describes the spin dispersion section - (NXdetector): - doc: | - Describes the electron detector - (NXdeflector): - doc: | - Deflectors outside the main optics ensembles described by the subclasses - (NXlens_em): - doc: | - Individual lenses outside the main optics ensembles described by the subclasses - (NXfabrication): - (NXresolution): - doc: | - Any other resolution not explicitly named in this base class. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 697ed2417255fcb8ac209a81b9833502f0bc72192b8537965d6a48c773572fd6 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays -# -# -# -# Number of fast axes (axes acquired simultaneously, without scanning a -# physical quantity) -# -# -# -# -# Number of slow axes (axes acquired scanning a physical quantity) -# -# -# -# -# Number of data points in the transmission function. -# -# -# -# -# Basic class for describing a electron analyzer. -# -# This concept is related to term `12.59`_ of the ISO 18115-1:2023 standard. -# -# .. _12.59: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.59 -# -# -# -# Free text description of the type of the detector -# -# -# -# -# Name or model of the equipment -# -# -# -# Acronym or other shorthand name -# -# -# -# -# -# Work function of the electron analyser. -# -# The work function of a uniform surface of a conductor is the minimum energy required to remove -# an electron from the interior of the solid to a vacuum level immediately outside the solid surface. -# -# The kinetic energy :math:`E_K` of a photoelectron emitted from an energy-level with binding energy -# :math:`E_B` below the Fermi level is given by :math:`E_K = h\nu - E_B - W = h\nu - E_B - e \phi_{\mathrm{sample}}`. -# Here, :math:`W = e \phi_{\mathrm{sample}}` is the work function of the sample surface (with the potential difference :math:`\phi_{\mathrm{sample}}` -# between the electrochemical potential of electrons in the bulk and the electrostatic potential of an electron in the vacuum just outside the surface). -# -# In PES measurements, the sample and the spectrometer (with work function :math:`\phi_{\mathrm{spectr.}}`) -# are electrically connected and therefore their Fermi levels are aligned. Due to the difference in local -# vacuum level between the sample and spectrometer, there exists an electric potential difference (contact potential) -# :math:`\Delta\phi = \phi_{\mathrm{sample}} - \phi_{\mathrm{spectr.}}`. The measured kinetic energy of -# a photoelectron in PES is therefore given by -# :math:`E_K^{\mathrm{meas.}} = h\nu - E_B + \Delta \phi = h\nu - E_B - e \phi_{\mathrm{spectr.}}`. -# As a result, the measured kinetic energy :math:`E_K^{\mathrm{meas.}}` of a photoelectron is `independent` -# of the sample work function. Nonetheless, the work function :math:`\phi_s` needs to be known to -# accurately determine the binding energy scale. -# -# -# -# -# Energy range of the voltage supplies. This influences the noise of the supplies, -# and thereby the energy resolution. -# -# -# -# -# Energy resolution of the analyser with the current setting. May be linked from an -# NXcalibration. -# -# -# -# -# -# -# -# -# Minimum distinguishable energy separation in the energy spectra. -# -# This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. -# -# .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 -# -# -# -# -# -# Ratio of the energy resolution of the electron analyser at a specified energy -# value to that energy value. -# -# This concept is related to term `10.7`_ of the ISO 18115-1:2023 standard. -# -# .. _10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 -# -# -# -# -# -# Momentum resolution of the electron analyser (FWHM) -# -# -# -# -# -# -# -# -# -# -# -# Angular resolution of the electron analyser (FWHM) -# -# -# -# -# -# -# -# -# -# -# -# Spatial resolution of the electron analyser (Airy disk radius) -# -# This concept is related to term `10.14`_ of the ISO 18115-1:2023 standard. -# -# .. _10.14: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.15 -# -# -# -# -# -# -# -# -# -# -# -# List of the axes that are acquired simultaneously by the detector. -# These refer only to the experimental variables recorded by the electron analyser. -# Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. -# -# .. csv-table:: Examples -# :header: "Mode", "fast_axes", "slow_axes" -# -# Hemispherical in ARPES mode, "['energy', 'kx']","" -# "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] -# "Tof", "['energy', 'kx', 'ky']","" -# "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" -# -# Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. -# If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. -# -# -# -# -# -# -# -# List of the axes that are acquired by scanning a physical parameter, listed in -# order of decreasing speed. See fast_axes for examples. -# -# -# -# -# -# -# -# Transmission function of the electron analyser. -# -# The transmission function (TF) specifies the detection efficiency per solid angle for electrons of -# different kinetic energy passing through the electron analyser. It depends on the spectrometer -# geometry as well as operation settings such as lens mode and pass energy. -# The transmission function is usually given as relative intensity vs. kinetic energy. -# -# The TF is used for calibration of the intensity scale in quantitative XPS. Without proper -# transmission correction, a comparison of results measured from the same sample using different -# operating modes for an instrument would show significant variations in atomic -# concentrations. -# -# This concept is related to term `7.15`_ of the ISO 18115-1:2023 standard. -# -# .. _7.15: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:7.15 -# -# -# -# -# -# -# -# -# -# -# -# -# -# Kinetic energy values -# -# -# -# -# -# -# -# Relative transmission efficiency for the given kinetic energies -# -# -# -# -# -# -# -# -# Refers to the last transformation specifying the position of the electron analyser -# in the NXtransformations chain. -# -# -# -# -# Collection of axis-based translations and rotations to describe the location and -# geometry of the electron analyser as a component in the instrument. Conventions -# from the NXtransformations base class are used. In principle, the McStas -# coordinate system is used. The first transformation has to point either to -# another component of the system or "." (for pointing to the reference frame) to -# relate it relative to the experimental setup. Typically, the components of a -# system should all be related relative to each other and only one component -# should relate to the reference coordinate system. -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# Describes the electron collection (spatial and momentum imaging) column -# -# -# -# -# Describes the energy dispersion section -# -# -# -# -# Describes the spin dispersion section -# -# -# -# -# Describes the electron detector -# -# -# -# -# Deflectors outside the main optics ensembles described by the subclasses -# -# -# -# -# Individual lenses outside the main optics ensembles described by the subclasses -# -# -# -# -# -# Any other resolution not explicitly named in this base class. -# -# -# diff --git a/contributed_definitions/nyaml/NXellipsometry.yaml b/contributed_definitions/nyaml/NXellipsometry.yaml deleted file mode 100644 index 72a6e07b77..0000000000 --- a/contributed_definitions/nyaml/NXellipsometry.yaml +++ /dev/null @@ -1,724 +0,0 @@ -category: application -doc: | - This is the application definition describing ellipsometry experiments. - - Such experiments may be as simple as identifying how a reflected - beam of light with a single wavelength changes its polarization state, - to a variable angle spectroscopic ellipsometry experiment. - - The application definition specifies optical spectroscopy (NXopt), by extending - the terms and setting specific requirements. - - Information on ellipsometry is provided, e.g. in: - - * H. Fujiwara, Spectroscopic ellipsometry: principles and applications, - John Wiley & Sons, 2007. - * R. M. A. Azzam and N. M. Bashara, Ellipsometry and Polarized Light, - North-Holland Publishing Company, 1977. - * H. G. Tompkins and E. A. Irene, Handbook of Ellipsometry, - William Andrew, 2005. - - Open access sources: - - * https://www.angstromadvanced.com/resource.asp - * https://pypolar.readthedocs.io/en/latest/ - - Review articles: - - * T. E. Jenkins, "Multiple-angle-of-incidence ellipsometry", - J. Phys. D: Appl. Phys. 32, R45 (1999), - https://doi.org/10.1088/0022-3727/32/9/201 - * D. E. Aspnes, "Spectroscopic ellipsometry - Past, present, and future", - Thin Solid Films 571, 334-344 (2014), - https://doi.org/10.1016/j.tsf.2014.03.056 - * R. M. A. Azzam, "Mueller-matrix ellipsometry: a review", - Proc. SPIE 3121, Polarization: Measurement, Analysis, and Remote Sensing, - (3 October 1997), - https://doi.org/10.1117/12.283870 - * E. A. Irene, "Applications of spectroscopic ellipsometry to microelectronics", - Thin Solid Films 233, 96-111 (1993), - https://doi.org/10.1016/0040-6090(93)90069-2 - * S. Zollner et al., "Spectroscopic ellipsometry from 10 to 700 K", - Adv. Opt. Techn., (2022), - https://doi.org/10.1515/aot-2022-0016 -symbols: - doc: | - Variables used throughout the document, e.g. dimensions or parameters. - N_spectrum: | - Length of the spectrum array (e.g. wavelength or energy) of the measured - data. - N_measurements: | - Number of measurements (1st dimension of measured_data array). This is - equal to the number of parameters scanned. For example, if the experiment - was performed at three different temperatures and two different pressures - N_measurements = 2*3 = 6. - N_detection_angles: | - Number of detection angles of the beam reflected or scattered off the - sample. - N_incident_angles: | - Number of angles of incidence of the incident beam. - -# 04/2024 -# A rework of the draft version(06/2022) of a NeXus application definition for ellipsometry. -# 09/2024 -# TODO (Workshop output): -# - Better categorization of ellipsoeter types: -# Seperate in spectral range and measurement types (In situ vs infrared?? This grouping does not make sense) -# Maybe make a given special field for "spectral_range" with units of eV or nm? -# - Add a StepScanAnalzer as measurement type (continous/rotating mode the other? Ask Chris) -# - Redefine more/higher requirements for Ellipsometry compared to NXoptical_spectroscopy: Especially incident angle and polarization. -# - Refinements for ellipsometer_type and add ellipsometer_method/mode: -# "~ please consider renaming "ellipsometer_type" to "ellipsometer_method" or "ellipsometer_mode". Motivation: "rotating_compensator" etc. are methods of ellipsometry measurements, and some ellipsometers support multiple methods (e.g. rotating compensator, nulling etc). -# ~ please consider to use the field "ellipsometer_type" for entries directly related to the core instrument, i.e. "imaging ellipsometer", "standard ellipsometer" (or: "non-imaging ellipsometer"), maybe others such as "back-focal plane ellipsometer" " -# - Add a clear predefined data structure, as initially proposed, but dont add any restrictions regarding dimensions -# Make ois maybe similar to NXdata_mpes. In this way, at all FAIR assignments of the data is possible. As well use this to guide the people, to let them know, where they have to save their data. Just use NXdata is too vague. Could be easing the threshold to get into NeXus. -# This explicitly refers to a wish to add: "exposure time, number of scans" -type: group -NXellipsometry(NXoptical_spectroscopy): - (NXentry): - definition: - doc: | - An application definition for ellipsometry. - \@version: - doc: | - Version number to identify which definition of this application - definition was used for this entry/data. - \@URL: - doc: | - URL where to find further material (documentation, examples) relevant - to the application definition. - enumeration: [NXellipsometry] - title: - exists: recommended - experiment_type: - doc: | - Specify the type of the optical experiment. - - You may specify fundamental characteristics or properties in the experimental sub-type. - enumeration: [ellipsometry] - ellipsometry_experiment_type: - doc: | - Specify the type of ellipsometry. - enumeration: [in situ spectroscopic ellipsometry, THz spectroscopic ellipsometry, infrared spectroscopic ellipsometry, ultraviolet spectroscopic ellipsometry, uv-vis spectroscopic ellipsometry, NIR-Vis-UV spectroscopic ellipsometry, other] - ellipsometry_experiment_type_other: - exists: optional - doc: | - If the ellipsometry_experiment_type is `other`, a name should be specified here. - (NXinstrument): - doc: | - Properties of the ellipsometry equipment. - ellipsometer_type: - doc: | - What type of ellipsometry was used? See Fujiwara Table 4.2. - enumeration: [rotating analyzer, rotating analyzer with analyzer compensator, rotating analyzer with polarizer compensator, rotating polarizer, rotating compensator on polarizer side, rotating compensator on analyzer side, modulator on polarizer side, modulator on analyzer side, dual compensator, phase modulation, imaging ellipsometry, null ellipsometry, other] - ellipsometer_type_other: - exists: optional - doc: | - If the ellipsometer_type is `other`, a specific ellipsometry_type" should be - added here. - rotating_element_type: - doc: | - Define which element rotates, e.g. polarizer or analyzer. - enumeration: [polarizer (source side), analyzer (detector side), compensator (source side), compensator (detector side)] - focussing_probes(NXlens_opt): - exists: optional - doc: | - If focussing probes (lenses) were used, please state if the data - were corrected for the window effects. - type: - enumeration: [objective, lens, glass fiber, none, other] - device_information(NXfabrication): - exists: optional - data_correction(NX_BOOLEAN): - exists: recommended - doc: | - Were the recorded data corrected by the window effects of the - focussing probes (lenses)? - angular_spread(NX_NUMBER): - exists: recommended - unit: NX_ANGLE - doc: | - Specify the angular spread caused by the focussing probes. - rotating_element(NXwaveplate): - exists: optional - doc: | - Properties of the rotating element defined in - 'instrument/rotating_element_type'. - revolutions(NX_NUMBER): - exists: optional - unit: NX_COUNT - doc: | - Define how many revolutions of the rotating element were averaged - for each measurement. If the number of revolutions was fixed to a - certain value use the field 'fixed_revolutions' instead. - fixed_revolutions(NX_NUMBER): - exists: optional - unit: NX_COUNT - doc: | - Define how many revolutions of the rotating element were taken - into account for each measurement (if number of revolutions was - fixed to a certain value, i.e. not averaged). - max_revolutions(NX_NUMBER): - exists: optional - unit: NX_COUNT - doc: | - Specify the maximum value of revolutions of the rotating element - for each measurement. - (NXsample): - backside_roughness(NX_BOOLEAN): - exists: optional - doc: | - Was the backside of the sample roughened? Relevant for infrared - ellipsometry. - - # The following NXdata setction called data_collection, is specialization - # from the old (NXopt and NXellipsometry) for the new NXellipometry. - # The generic description of the data collection will in future be - # included in the generic NXopt, but is now keept limited to - # NXellipsometry. - data_collection(NXdata): - exists: optional - doc: | - Measured data, data errors, and varied parameters. This may be used to describe - indirectly derived data or data transformed between different descriptions, - such as: - Raw Data --> Psi - Delta Psi, Delta --> N,C,S - Mueller matrix --> N,C,S - Mueller matrix --> Psi, Delta - etc. - - Other types of data, such as temperature or sample location, may be saved - in a generic (NXdata) concept from NXopt, or better directly in the - location of the sample positioner or temperature sensor. - data_identifier(NX_NUMBER): - exists: recommended - doc: | - An identifier to correlate data to the experimental conditions, - if several were used in this measurement; typically an index of 0-N. - data_type: - exists: recommended - doc: | - Select which type of data was recorded, for example intensity, - reflectivity, transmittance, Psi and Delta etc. - It is possible to have multiple selections. The enumeration list - depends on the type of experiment and may differ for different - application definitions. - enumeration: [intensity, reflectivity, transmittance, Psi/Delta, tan(Psi)/cos(Delta), Mueller matrix, Jones matrix, N/C/S, raw data] - NAME_spectrum(NX_FLOAT): - exists: optional - unit: NX_ANY - doc: | - Spectral values (e.g. wavelength or energy) used for the measurement. - An array of 1 or more elements. Length defines N_spectrum. Replace - 'SPECTRUM' by the physical quantity that is used, e.g. wavelength. - dimensions: - rank: 1 - dim: [[1, N_spectrum]] - \@units: - exists: optional - doc: | - If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. - If the unit of the measured data is not covered by NXDL units state - here which unit was used. - measured_data(NX_FLOAT): - unit: NX_ANY - doc: | - Resulting data from the measurement, described by 'data_type'. - - The first dimension is defined by the number of measurements taken, - (N_measurements). The instructions on how to order the values - contained in the parameter vectors given in the doc string of - INSTRUMENT/sample_stage/environment_conditions/PARAMETER/values, - define the N_measurements parameter sets. For example, if the - experiment was performed at three different temperatures - (T1, T2, T3), two different pressures (p1, p2) and two different - angles of incidence (a1, a2), the first measurement was taken at the - parameters {a1,p1,T1}, the second measurement at {a1,p1,T2} etc. - dimensions: - rank: 3 - dim: [[1, N_measurements], [2, N_observables], [3, N_spectrum]] - \@units: - exists: optional - doc: | - If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. - If the unit of the measured data is not covered by NXDL units state - here which unit was used. - measured_data_errors(NX_FLOAT): - exists: optional - unit: NX_ANY - doc: | - Specified uncertainties (errors) of the data described by 'data_type' - and provided in 'measured_data'. - dimensions: - rank: 3 - dim: [[1, N_measurements], [2, N_observables], [3, N_spectrum]] - \@units: - exists: optional - doc: | - If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. - If the unit of the measured data is not covered by NXDL units state - here which unit was used. - varied_parameter_link: - exists: optional - doc: | - List of links to the values of the sensors. Add a link for each - varied parameter (i.e. for each sensor). - dimensions: - rank: 1 - dim: [[1, N_sensors]] - reference_data_link: - exists: optional - doc: | - Link to the NeXus file which describes the reference data if a - reference measurement was performed. Ideally, the reference - measurement was performed using the same conditions as the actual - measurement and should be as close in time to the actual measurement - as possible. - data_software(NXprogram): - exists: optional - program: - exists: recommended - doc: | - Commercial or otherwise defined given name of the program that was - used to generate the result file(s) with measured data and/or - metadata (in most cases, this is the same as INSTRUMENT/software). - If home written, one can provide the actual steps in the NOTE - subfield here. - version: - exists: recommended - doc: | - Either version with build number, commit hash, or description of a - (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner. - \@URL: - exists: optional - doc: | - Website of the software. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# fc2d596065121b9783b8dbfce04ef4f04ffbddb88589d6145b8f30a030f432f5 -# -# -# -# -# -# -# -# Variables used throughout the document, e.g. dimensions or parameters. -# -# -# -# Length of the spectrum array (e.g. wavelength or energy) of the measured -# data. -# -# -# -# -# Number of measurements (1st dimension of measured_data array). This is -# equal to the number of parameters scanned. For example, if the experiment -# was performed at three different temperatures and two different pressures -# N_measurements = 2*3 = 6. -# -# -# -# -# Number of detection angles of the beam reflected or scattered off the -# sample. -# -# -# -# -# Number of angles of incidence of the incident beam. -# -# -# -# -# This is the application definition describing ellipsometry experiments. -# -# Such experiments may be as simple as identifying how a reflected -# beam of light with a single wavelength changes its polarization state, -# to a variable angle spectroscopic ellipsometry experiment. -# -# The application definition specifies optical spectroscopy (NXopt), by extending -# the terms and setting specific requirements. -# -# Information on ellipsometry is provided, e.g. in: -# -# * H. Fujiwara, Spectroscopic ellipsometry: principles and applications, -# John Wiley & Sons, 2007. -# * R. M. A. Azzam and N. M. Bashara, Ellipsometry and Polarized Light, -# North-Holland Publishing Company, 1977. -# * H. G. Tompkins and E. A. Irene, Handbook of Ellipsometry, -# William Andrew, 2005. -# -# Open access sources: -# -# * https://www.angstromadvanced.com/resource.asp -# * https://pypolar.readthedocs.io/en/latest/ -# -# Review articles: -# -# * T. E. Jenkins, "Multiple-angle-of-incidence ellipsometry", -# J. Phys. D: Appl. Phys. 32, R45 (1999), -# https://doi.org/10.1088/0022-3727/32/9/201 -# * D. E. Aspnes, "Spectroscopic ellipsometry - Past, present, and future", -# Thin Solid Films 571, 334-344 (2014), -# https://doi.org/10.1016/j.tsf.2014.03.056 -# * R. M. A. Azzam, "Mueller-matrix ellipsometry: a review", -# Proc. SPIE 3121, Polarization: Measurement, Analysis, and Remote Sensing, -# (3 October 1997), -# https://doi.org/10.1117/12.283870 -# * E. A. Irene, "Applications of spectroscopic ellipsometry to microelectronics", -# Thin Solid Films 233, 96-111 (1993), -# https://doi.org/10.1016/0040-6090(93)90069-2 -# * S. Zollner et al., "Spectroscopic ellipsometry from 10 to 700 K", -# Adv. Opt. Techn., (2022), -# https://doi.org/10.1515/aot-2022-0016 -# -# -# -# -# An application definition for ellipsometry. -# -# -# -# Version number to identify which definition of this application -# definition was used for this entry/data. -# -# -# -# -# URL where to find further material (documentation, examples) relevant -# to the application definition. -# -# -# -# -# -# -# -# -# -# Specify the type of the optical experiment. -# -# You may specify fundamental characteristics or properties in the experimental sub-type. -# -# -# -# -# -# -# -# Specify the type of ellipsometry. -# -# -# -# -# -# -# -# -# -# -# -# -# -# If the ellipsometry_experiment_type is `other`, a name should be specified here. -# -# -# -# -# Properties of the ellipsometry equipment. -# -# -# -# What type of ellipsometry was used? See Fujiwara Table 4.2. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If the ellipsometer_type is `other`, a specific ellipsometry_type" should be -# added here. -# -# -# -# -# Define which element rotates, e.g. polarizer or analyzer. -# -# -# -# -# -# -# -# -# -# -# If focussing probes (lenses) were used, please state if the data -# were corrected for the window effects. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Were the recorded data corrected by the window effects of the -# focussing probes (lenses)? -# -# -# -# -# Specify the angular spread caused by the focussing probes. -# -# -# -# -# -# Properties of the rotating element defined in -# 'instrument/rotating_element_type'. -# -# -# -# Define how many revolutions of the rotating element were averaged -# for each measurement. If the number of revolutions was fixed to a -# certain value use the field 'fixed_revolutions' instead. -# -# -# -# -# Define how many revolutions of the rotating element were taken -# into account for each measurement (if number of revolutions was -# fixed to a certain value, i.e. not averaged). -# -# -# -# -# Specify the maximum value of revolutions of the rotating element -# for each measurement. -# -# -# -# -# -# -# -# Was the backside of the sample roughened? Relevant for infrared -# ellipsometry. -# -# -# -# -# -# -# Measured data, data errors, and varied parameters. This may be used to describe -# indirectly derived data or data transformed between different descriptions, -# such as: -# Raw Data --> Psi -# Delta Psi, Delta --> N,C,S -# Mueller matrix --> N,C,S -# Mueller matrix --> Psi, Delta -# etc. -# -# Other types of data, such as temperature or sample location, may be saved -# in a generic (NXdata) concept from NXopt, or better directly in the -# location of the sample positioner or temperature sensor. -# -# -# -# An identifier to correlate data to the experimental conditions, -# if several were used in this measurement; typically an index of 0-N. -# -# -# -# -# Select which type of data was recorded, for example intensity, -# reflectivity, transmittance, Psi and Delta etc. -# It is possible to have multiple selections. The enumeration list -# depends on the type of experiment and may differ for different -# application definitions. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Spectral values (e.g. wavelength or energy) used for the measurement. -# An array of 1 or more elements. Length defines N_spectrum. Replace -# 'SPECTRUM' by the physical quantity that is used, e.g. wavelength. -# -# -# -# -# -# -# If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. -# If the unit of the measured data is not covered by NXDL units state -# here which unit was used. -# -# -# -# -# -# Resulting data from the measurement, described by 'data_type'. -# -# The first dimension is defined by the number of measurements taken, -# (N_measurements). The instructions on how to order the values -# contained in the parameter vectors given in the doc string of -# INSTRUMENT/sample_stage/environment_conditions/PARAMETER/values, -# define the N_measurements parameter sets. For example, if the -# experiment was performed at three different temperatures -# (T1, T2, T3), two different pressures (p1, p2) and two different -# angles of incidence (a1, a2), the first measurement was taken at the -# parameters {a1,p1,T1}, the second measurement at {a1,p1,T2} etc. -# -# -# -# -# -# -# -# -# If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. -# If the unit of the measured data is not covered by NXDL units state -# here which unit was used. -# -# -# -# -# -# Specified uncertainties (errors) of the data described by 'data_type' -# and provided in 'measured_data'. -# -# -# -# -# -# -# -# -# If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. -# If the unit of the measured data is not covered by NXDL units state -# here which unit was used. -# -# -# -# -# -# List of links to the values of the sensors. Add a link for each -# varied parameter (i.e. for each sensor). -# -# -# -# -# -# -# -# Link to the NeXus file which describes the reference data if a -# reference measurement was performed. Ideally, the reference -# measurement was performed using the same conditions as the actual -# measurement and should be as close in time to the actual measurement -# as possible. -# -# -# -# -# -# Commercial or otherwise defined given name of the program that was -# used to generate the result file(s) with measured data and/or -# metadata (in most cases, this is the same as INSTRUMENT/software). -# If home written, one can provide the actual steps in the NOTE -# subfield here. -# -# -# -# -# Either version with build number, commit hash, or description of a -# (online) repository where the source code of the program and build -# instructions can be found so that the program can be configured in -# such a way that result files can be created ideally in a -# deterministic manner. -# -# -# -# -# Website of the software. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml deleted file mode 100644 index 93d22fbac8..0000000000 --- a/contributed_definitions/nyaml/NXem.yaml +++ /dev/null @@ -1,1468 +0,0 @@ -category: application -doc: | - Application definition for normalized representation of electron microscopy research. - - This application definition is a comprehensive example for a general description - with which to normalize specific pieces of information and data collected within - electron microscopy research. - - NXem is designed to be used for documenting experiments or computer simulations in which - controlled electron beams are used for studying electron-beam matter interaction to explore - physical mechanisms and phenomena, or to characterize materials with an electron microscope. -type: group -NXem(NXobject): - # \@NX_class: - # \@file_time(NX_DATE_TIME): - # \@file_name(NX_CHAR): - # \@file_update_time(NX_DATE_TIME): - # \@NeXus_version(NX_CHAR): - # \@HDF5_Version(NX_CHAR): - # \@h5py_version(NX_CHAR): - # \@default(NX_CHAR): - # starting to reorganize the docstrings, as a list of blocks: - # -| req: first part, concept definition, human-readable but such that one could take as is to define an concept in OWL - # -| opt: second part, comment, i.e. information that in an ideal world would be ideal if represented strongly semantic - # but for practical purposes currently is interpretable only by human to provide them further contextualization - # -| recommended: xref part (ideally also as a list of triple (spec, term, url to uri) - (NXentry): # means ENTRY(NXentry) - exists: [min, 1, max, infty] - definition(NX_CHAR): - \@version(NX_CHAR): - exists: optional - enumeration: [NXem] - profiling(NXcs_profiling): - exists: optional - doc: | - The configuration of the I/O writer software (e.g. `pynxtools `_ or its plugins) - which was used to generate this NeXus file instance. - programID(NXprogram): # program1, program2 - doc: - - | - A collection of all programs and libraries that are considered as relevant - to understand with which software tools this NeXus file instance was - generated. Ideally, to enable a binary recreation from the input data. - - | - Examples include the name and version of the libraries used to write the - instance. Ideally, the software which writes these NXprogram instances - also includes the version of the set of NeXus classes i.e. the specific - set of base classes, application definitions, and contributed definitions - with which the here described concepts can be resolved. - - For the `pynxtools library `_ - which is used by the `NOMAD `_ - research data management system, it makes sense to store e.g. the GitHub - repository commit and respective submodule references used. - exists: [min, 0, max, infty] - program(NX_CHAR): - \@version(NX_CHAR): - experiment_identifier(NXidentifier): - exists: recommended - doc: - - | - Ideally, a (globally) unique persistent identifier for referring to this experiment. - - An experiment should be understood in that this can be an experiment - in reality or a computer simulation because also the latter is an experiment - (see the Cambridge Dictionary experiment *a test done in order to find out - something, eg if an idea is correct*). - - | - The identifier is usually issued by the facility, laboratory, or the principle investigator. - The identifier enables to link experiments/simulations to e.g. proposals. - service(NX_CHAR): - identifier(NX_CHAR): - is_persistent(NX_BOOLEAN): - experiment_alias(NX_CHAR): - doc: - - | - Alias which scientists can easier identify this experiment by. - experiment_description(NX_CHAR): - exists: optional - doc: - - | - Free-text description about the experiment. - - | - Users are strongly advised to parameterize the description of their experiment - by using respective groups and fields and base classes instead of writing prose - into the field. The reason is that such free-text field is difficult to machine-interpret. - The motivation behind keeping this field for now is to learn in how far the - current base classes need extension based on user feedback. - start_time(NX_DATE_TIME): - doc: - - | - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant use this start_time field. - - | - Often though it is useful to specify a time interval via setting both a start_time - and an end_time because this enables software tools and users to collect a - more detailed bookkeeping of the experiment. - - Users should be aware though that even with having both time instances - specified, it may not be possible to infer how long the experiment took or - for how long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps start_time and end_time - in :ref:`NXevent_data_em` instances. - end_time(NX_DATE_TIME): - exists: recommended - doc: - - | - ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. - - | - See docstring of the start_time field to see how to use the - start_time and end_time together. - citeID(NXcite): - exists: [min, 0, max, infty] - serializedID(NXserialized): - exists: [min, 0, max, infty] - doc: - - | - Possibility to store a collection of serialized resources associated with the experiment. - - | - An example how to use this set could be to document from which files, which have been - e.g. generated by software of technology partners, the information in an instance of - NXem was filled with during parsing or transcoding between different formats. - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - userID(NXuser): - # this is one of the few examples where groups may end up without fields because for reasons of not breaking GDPR compliance - exists: [min, 0, max, infty] - doc: - - | - Information about persons who performed or were involved in the microscope session or simulation run. - - | - This can be the principle investigator who performed this experiment or the student who performed simulations. - Adding multiple users if relevant is recommended. - name(NX_CHAR): - exists: optional - doc: - - | - Given (first) name and surname. - affiliation(NX_CHAR): - exists: optional - doc: - - | - Name of the affiliation at the point in time when the experiment was performed. - address(NX_CHAR): - exists: optional - doc: - - | - Postal address of the affiliation. - email(NX_CHAR): - exists: optional - doc: - - | - Email address at the point in time when the experiment was performed. - - | - Writing the most permanently used email is recommended. - telephone_number(NX_CHAR): - exists: optional - doc: - - | - Telephone number at the point in time when the experiment was performed. - role(NX_CHAR): - exists: optional - doc: - - | - User role at the point in time when the experiment was performed. - - | - Examples are technician operating the microscope, student, postdoc, - principle investigator, or guest. - identifier(NXidentifier): - exists: optional - doc: - - | - Identifier offered by a service to report the user other than by using its name. - - | - Examples could be an ORCID or social media account of the user. - service(NX_CHAR): - identifier(NX_CHAR): - is_persistent(NX_BOOLEAN): - sample(NXsample): - doc: - - | - A physical entity which contains material intended to be investigated. - Sample and specimen are treated as de facto synonyms. Samples can be real or virtual ones. - - | - xref: - spec: EMglossary - term: Specimen - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000046 - type(NX_CHAR): - doc: - - | - Qualifier whether the sample is a real or a virtual one. - enumeration: [experiment, simulation] - identifier(NXidentifier): - exists: recommended - doc: | - Ideally, (globally) unique persistent identifier which distinguishes the sample from all others - and especially the predecessor/origin from where that sample was cut. The terms sample - and specimen are here considered as exact synonyms. - - This field must not be used for an alias! Instead, use name. - - In cases where multiple specimens were loaded into the microscope, the identifier has to resolve - the specific sample, whose results are stored by this :ref:`NXentry` instance because a single - NXentry should be used for the characterization of a single specimen. - - Details about the specimen preparation should be stored in resources referring to parent_identifier. - service(NX_CHAR): - identifier(NX_CHAR): - is_persistent(NX_BOOLEAN): - parent_identifier(NXidentifier): - exists: recommended - doc: | - Identifier of the sample from which the sample was cut or the string *None*. - - The purpose of this field is to support functionalities for tracking - sample provenance in a research data management system. - service(NX_CHAR): - identifier(NX_CHAR): - is_persistent(NX_BOOLEAN): - preparation_date(NX_DATE_TIME): - doc: | - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known timestamp when - the measured specimen surface was actively prepared. Ideally, this matches - the last timestamp that is mentioned in the digital resource pointed to by - parent_identifier. - - Knowing when the specimen was exposed to e.g. specific atmosphere is especially - required for environmentally sensitive material such as specimen charged with hydrogen - or experiments including tracers that have a short halflife. Additional time stamps - prior to preparation_date should better be placed in resources which describe but - which do not pollute the description here with prose. Resolving these connected - pieces of information is considered the responsibility of the - research data management system not of a NeXus file. - name(NX_CHAR): - exists: recommended - doc: | - An alias used to refer to the specimen to please readability for humans. - atom_types(NX_CHAR): - doc: | - List of comma-separated elements from the periodic table that are contained in the sample. - If the sample substance has multiple components, all elements from each component - must be included in atom_types. - - The purpose of the field is to offer research data management systems an opportunity - to parse the relevant elements without having to interpret these from the resources - pointed to by parent_identifier or walk through eventually deeply nested groups in - individual data instances. - thickness(NX_NUMBER): - exists: optional - doc: | - (Measured) sample thickness. - - The information is recorded to qualify if the beam used was likely - able to shine through the specimen. For scanning electron microscopy, - in many cases the specimen is typically thicker than what is - illuminatable by the electron beam. - - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - unit: NX_LENGTH - # \@units: nm - # NEW ISSUE: error estimates of the thickness and origin, i.e. how the value was obtained would be useful - # NEW ISSUE: error model - # NEW ISSUE: the KIT/SCC SEM, TEM schemata further qualify samples whether they are conductive e/ibeam sensitive - # etc. The problem with this is that beam sensitivity is too vague but spatiotemporal electron dose integral dependent - # KIT/SCC distinguish further conductivity and magnetic properties. While the motivation is clear, making - # it thus simple is likely problematic when the data entered in such fields remaining qualitative. - # what are good or bad properties, it would make sense though to quantify these values - # this includes the description of eventual plasma cleaning steps, - # just knowing that a sample was plasma cleaned is insufficient, maybe it was not cleaned long enough - # if plasma cleaning is done outside the EM than its certainly history, if it happens inside the EM - # are the ibeam description capabilities not sufficient enough? - density(NX_NUMBER): - exists: optional - doc: | - (Measured) density of the specimen. - - For multi-layered specimens this field should only be used to describe - the density of the excited volume. For scanning electron microscopy - the usage of this field is discouraged and instead an instance of an - :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` - instances can provide a cleaner description of the relevant details - why one may wish to store the density of the specimen. - unit: NX_ANY - description(NX_CHAR): - exists: optional - doc: | - Discouraged free-text field to provide further detail although adding - parent_identifier and having a working research data management system - should provide this contextualization. - coordinate_system_set(NXcoordinate_system_set): - exists: [min, 1, max, 1] - doc: - - | - Set to hold different coordinate systems conventions. - - | - Inspect the description of the :ref:`NXcoordinate_system_set` and :ref:`NXcoordinate_system` base classes - how to define coordinate systems in NeXus. - (NXcoordinate_system): - exists: [min, 1, max, infty] - alias(NX_CHAR): - exists: optional - type(NX_CHAR): - handedness(NX_CHAR): - origin(NX_CHAR): - processing_reference_frame(NXcoordinate_system): - exists: recommended - alias(NX_CHAR): - exists: optional - type(NX_CHAR): - handedness(NX_CHAR): - origin(NX_CHAR): - exists: recommended - doc: | - Location of the origin of the processing_reference_frame. - - It is assumed that regions-of-interest in this reference frame form a rectangle or cuboid. - Edges are interpreted by inspecting the direction of their outer unit normals - (which point either parallel or antiparallel) along respective base vector direction - of the reference frame. - - If any of these assumptions is not met, the user is required to explicitly state this. - enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] - x_direction(NX_CHAR): - exists: recommended - doc: | - Direction of the positively pointing x-axis base vector of the processing_reference_frame. - enumeration: [undefined, north, east, south, west, in, out] - y_direction(NX_CHAR): - exists: recommended - doc: | - Direction of the positively pointing y-axis base vector of the processing_reference_frame. - enumeration: [undefined, north, east, south, west, in, out] - z_direction(NX_CHAR): - exists: recommended - doc: | - Direction of the positively pointing z-axis base vector of the processing_reference_frame. - enumeration: [undefined, north, east, south, west, in, out] - sample_reference_frame(NXcoordinate_system): - exists: recommended - depends_on(NX_CHAR): - exists: optional - doc: | - Reference to the specifically named :ref:`NXsample` instance(s) for - which these conventions apply (e.g. /entry1/sample1). - alias(NX_CHAR): - exists: optional - type(NX_CHAR): - handedness(NX_CHAR): - origin(NX_CHAR): - exists: recommended - doc: | - Location of the origin of the sample_reference_frame. - - It is assumed that regions-of-interest in this reference frame form a rectangle or cuboid. - Edges are interpreted by inspecting the direction of their outer unit normals - (which point either parallel or antiparallel) along respective base vector direction - of the reference frame. - - If any of these assumptions is not met, the user is required to explicitly state this. - enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] - x_direction(NX_CHAR): - exists: recommended - doc: | - Direction of the positively pointing x-axis base vector of the sample_reference_frame. - enumeration: [undefined, north, east, south, west, in, out] - y_direction(NX_CHAR): - exists: recommended - doc: | - Direction of the positively pointing y-axis base vector of the sample_reference_frame. - enumeration: [undefined, north, east, south, west, in, out] - z_direction(NX_CHAR): - exists: recommended - doc: | - Direction of the positively pointing z-axis base vector of the sample_reference_frame. - enumeration: [undefined, north, east, south, west, in, out] - detector_reference_frameID(NXcoordinate_system): - exists: [min, 0, max, infty] - depends_on(NX_CHAR): - exists: optional - doc: | - Reference to the specifically named :ref:`NXdetector` instance for - which these conventions apply (e.g. /entry1/instrument/detector1). - alias(NX_CHAR): - exists: optional - type(NX_CHAR): - handedness(NX_CHAR): - origin(NX_CHAR): - exists: recommended - doc: | - Location of the origin of the detector_reference_frame. - - If the regions-of-interest forms a rectangle or cuboid, it is assumed that edges are interpreted - by inspecting the direction of their outer unit normals (which point either parallel or antiparallel) - along respective base vector direction of the reference frame. - - If any of these assumptions is not met, the user is required to explicitly state this. - enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] - x_direction(NX_CHAR): - exists: recommended - doc: | - Direction of the positively pointing x-axis base vector of the detector_reference_frame. - enumeration: [undefined, north, east, south, west, in, out] - y_direction(NX_CHAR): - exists: recommended - doc: | - Direction of the positively pointing y-axis base vector of the detector_reference_frame. - enumeration: [undefined, north, east, south, west, in, out] - z_direction(NX_CHAR): - exists: recommended - doc: | - Direction of the positively pointing z-axis base vector of the detector_reference_frame. - enumeration: [undefined, north, east, south, west, in, out] - # the description can be so lean because we do not need to overwrite here s.th. as everything is defined already - # we just say we compose using the base class NXcoordinate_system - measurement(NXem_msr): - exists: optional - em_lab(NXinstrument): - instrument_name(NX_CHAR): - exists: recommended - location(NX_CHAR): - exists: recommended - fabrication(NXfabrication): - exists: optional - vendor(NX_CHAR): - model(NX_CHAR): - identifier(NXidentifier): - exists: recommended - control_programID(NXprogram): - exists: [min, 1, max, infty] - doc: - - | - Details about the control program used for operating the microscope. - program(NX_CHAR): - \@version(NX_CHAR): - ebeam_column(NXebeam_column): - chamber(NXchamber): - exists: optional - fabrication(NXfabrication): - exists: optional - vendor(NX_CHAR): - model(NX_CHAR): - identifier(NXidentifier): - exists: recommended - electron_source(NXsource): - doc: - - | - xref: - spec: EMglossary - term: Source - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 - emitter_type(NX_CHAR): - probe(NX_CHAR): - # voltage like all other dynamic quantities should better be placed in instances of NXevent_data_em - fabrication(NXfabrication): - exists: optional - vendor(NX_CHAR): - model(NX_CHAR): - identifier(NXidentifier): - exists: recommended - # fabrication is an example which shows when one needs to specify in the appdef if some of the - # inherited objects from NXebeam_column have to be specified that is when one wishes to document - # e.g. a combination of cardinality constraints or concept symbol constraints - # i.e. use NXfabrication from NXsource but demand it to be labelled with the symbol fabrication - # likewise if you provide fabrication details you need to provide vendor and model but not necessarily identifier - lensID(NXlens_em): - exists: [min, 0, max, infty] - fabrication(NXfabrication): - exists: optional - vendor(NX_CHAR): - model(NX_CHAR): - identifier(NXidentifier): - exists: recommended - apertureID(NXaperture): - exists: [min, 0, max, infty] - fabrication(NXfabrication): - exists: optional - vendor(NX_CHAR): - model(NX_CHAR): - identifier(NXidentifier): - exists: recommended - monochromatorID(NXmonochromator): - exists: [min, 0, max, infty] - doc: - - | - Device for improving energy resolution or reducing chromatic aberration. - - | - Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector like `_ - # user perspective - type(NX_CHAR): - doc: - - | - Qualitative type of the component. - enumeration: [wien, alfa, omega, castaing_henry, gatan_imaging, sector_analyzer] - # control level perspective - # technical design perspective - fabrication(NXfabrication): - exists: optional - vendor(NX_CHAR): - model(NX_CHAR): - identifier(NXidentifier): - exists: recommended - corrector_cs(NXcorrector_cs): - exists: [min, 0, max, 1] - fabrication(NXfabrication): - exists: optional - vendor(NX_CHAR): - model(NX_CHAR): - identifier(NXidentifier): - exists: recommended - corrector_ax(NXcomponent): - exists: [min, 0, max, 1] - doc: - - | - Device reshaping an ellipse-shaped electron beam to a circular one. - - * `L. Reimer 1998, Springer, 1998 `_ - * `M. Tanaka et al., Electron Microscopy Glossary, 2024 `_ - - - | - Stigmator is an exact synonym. - fabrication(NXfabrication): - exists: optional - vendor(NX_CHAR): - model(NX_CHAR): - identifier(NXidentifier): - exists: recommended - biprism(NXcomponent): - exists: optional - doc: - - | - Electron biprism as it is used e.g. for electron holography. - fabrication(NXfabrication): - exists: optional - vendor(NX_CHAR): - model(NX_CHAR): - identifier(NXidentifier): - exists: recommended - phaseplateID(NXcomponent): - # contributed definition NXwaveplate is a closely related concept but may fit even better but waveplate - # has been defined from the perspective of classical optics - # same challenge like with NXlens and NXlens_em, an electrostatic lens is not the same concept - # like it is an glass lens (i.e. optical) NXlens - # but both concepts have in common that they can be assumed to be specialization of a super class - # lenses i.e. devices which can affect the pathes of beams - exists: [min, 0, max, infty] - doc: - - | - Device that causes a change in the phase of an electron wave. - - * `M. Malac et al. `_ - * `R. R. Schröder et al. `_ - type(NX_CHAR): - doc: - - | - Qualitative type - enumeration: [thin_film, electrostatic] - fabrication(NXfabrication): - exists: optional - vendor(NX_CHAR): - model(NX_CHAR): - identifier(NXidentifier): - exists: recommended - sensorID(NXsensor): - exists: [min, 0, max, infty] - actuatorID(NXactuator): - exists: [min, 0, max, infty] - ibeam_column(NXibeam_column): - exists: [min, 0, max, 1] - # there are tri-beam SEMs but they typically use a laser for which we should have an own base class - chamber(NXchamber): - exists: optional - fabrication(NXfabrication): - exists: optional - vendor(NX_CHAR): - model(NX_CHAR): - identifier(NXidentifier): - exists: recommended - ion_source(NXsource): - probe(NXion): - lensID(NXlens_em): - exists: [min, 0, max, infty] - fabrication(NXfabrication): - exists: optional - vendor(NX_CHAR): - model(NX_CHAR): - identifier(NXidentifier): - exists: recommended - apertureID(NXaperture): - exists: [min, 0, max, infty] - fabrication(NXfabrication): - exists: optional - vendor(NX_CHAR): - model(NX_CHAR): - identifier(NXidentifier): - exists: recommended - monochromatorID(NXmonochromator): - exists: [min, 0, max, infty] - doc: - - | - Device for improving energy resolution or reducing chromatic aberration. - - | - Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector like `_ - type(NX_CHAR): - doc: - - | - Qualitative type of the component. - enumeration: [wien, alfa, omega, castaing_henry, gatan_imaging, sector_analyzer] - fabrication(NXfabrication): - exists: optional - vendor(NX_CHAR): - model(NX_CHAR): - identifier(NXidentifier): - exists: recommended - # device for correcting axial astigmatism of ion beam? - sensorID(NXsensor): - exists: [min, 0, max, infty] - actuatorID(NXactuator): - exists: [min, 0, max, infty] - detectorID(NXdetector): - exists: [min, 0, max, infty] - fabrication(NXfabrication): - vendor(NX_CHAR): - model(NX_CHAR): - # identifier(NXidentifier): # only relevant when deprecating serial_number - # exists: recommended - scan_controller(NXscanbox_em): - exists: optional - fabrication(NXfabrication): - exists: optional - vendor(NX_CHAR): - model(NX_CHAR): - identifier(NXidentifier): - exists: recommended - (NXsensor): - exists: [min, 0, max, infty] - (NXactuator): - exists: [min, 0, max, infty] - (NXstage_lab): - exists: [min, 0, max, infty] - fabrication(NXfabrication): - exists: optional - vendor(NX_CHAR): - model(NX_CHAR): - identifier(NXidentifier): - exists: recommended - (NXchamber): - exists: [min, 0, max, infty] - (NXpump): - exists: [min, 0, max, infty] - event_data_em_set(NXevent_data_em_set): - exists: [min, 0, max, 1] - # an instance must not have an NXevent_data_em_set but if it has one it must not be more than 1 ! - (NXevent_data_em): - exists: [min, 0, max, infty] - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - (NXimage_set): - exists: [min, 0, max, infty] - (NXprocess): - source(NXserialized): - exists: recommended - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - absolute_path(NX_CHAR): - exists: recommended - detector_identifier(NX_CHAR): - image_1d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): - title(NX_CHAR): - real(NX_NUMBER): - \@long_name(NX_CHAR): - imag(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - magnitude(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - intensity(NX_COMPLEX): - exists: optional - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - image_2d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): - title(NX_CHAR): - real(NX_NUMBER): - \@long_name(NX_CHAR): - imag(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - magnitude(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - intensity(NX_COMPLEX): - exists: optional - \@long_name(NX_CHAR): - axis_j(NX_NUMBER): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - image_3d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): - title(NX_CHAR): - real(NX_NUMBER): - \@long_name(NX_CHAR): - imag(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - magnitude(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - intensity(NX_COMPLEX): - exists: optional - \@long_name(NX_CHAR): - axis_k(NX_NUMBER): - \@long_name(NX_CHAR): - axis_j(NX_NUMBER): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - stack_1d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): - title(NX_CHAR): - real(NX_NUMBER): - \@long_name(NX_CHAR): - imag(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - magnitude(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - intensity(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - group_identifier(NX_INT): - exists: optional - \@long_name(NX_CHAR): - image_identifier(NX_INT): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - stack_2d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): - title(NX_CHAR): - real(NX_NUMBER): - \@long_name(NX_CHAR): - imag(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - magnitude(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - intensity(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - group_identifier(NX_INT): - exists: optional - \@long_name(NX_CHAR): - image_identifier(NX_INT): - \@long_name(NX_CHAR): - axis_j(NX_NUMBER): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - stack_3d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): - title(NX_CHAR): - real(NX_NUMBER): - \@long_name(NX_CHAR): - imag(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - magnitude(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - intensity(NX_NUMBER): - exists: optional - \@long_name(NX_CHAR): - group_identifier(NX_INT): - exists: optional - \@long_name(NX_CHAR): - image_identifier(NX_INT): - \@long_name(NX_CHAR): - axis_k(NX_NUMBER): - \@long_name(NX_CHAR): - axis_j(NX_NUMBER): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - (NXspectrum_set): - exists: [min, 0, max, infty] - (NXprocess): - source(NXserialized): - exists: recommended - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - absolute_path(NX_CHAR): - exists: recommended - detector_identifier(NX_CHAR): - spectrum_0d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): - title(NX_CHAR): - intensity(NX_NUMBER): - \@long_name(NX_CHAR): - axis_energy(NX_NUMBER): - \@long_name(NX_CHAR): - spectrum_1d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): - title(NX_CHAR): - intensity(NX_NUMBER): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - axis_energy(NX_NUMBER): - \@long_name(NX_CHAR): - spectrum_2d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): - title(NX_CHAR): - intensity(NX_NUMBER): - \@long_name(NX_CHAR): - axis_j(NX_NUMBER): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - axis_energy(NX_NUMBER): - \@long_name(NX_CHAR): - spectrum_3d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): - title(NX_CHAR): - intensity(NX_NUMBER): - \@long_name(NX_CHAR): - axis_k(NX_NUMBER): - \@long_name(NX_CHAR): - axis_j(NX_NUMBER): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - axis_energy(NX_NUMBER): - \@long_name(NX_CHAR): - stack_0d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): - title(NX_CHAR): - intensity(NX_NUMBER): - \@long_name(NX_CHAR): - spectrum_identifier(NX_INT): - \@long_name(NX_CHAR): - axis_energy(NX_NUMBER): - \@long_name(NX_CHAR): - stack_1d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): - title(NX_CHAR): - intensity(NX_NUMBER): - \@long_name(NX_CHAR): - spectrum_identifier(NX_INT): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - axis_energy(NX_NUMBER): - \@long_name(NX_CHAR): - stack_2d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): - title(NX_CHAR): - intensity(NX_NUMBER): - \@long_name(NX_CHAR): - spectrum_identifier(NX_INT): - \@long_name(NX_CHAR): - axis_j(NX_NUMBER): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - axis_energy(NX_NUMBER): - \@long_name(NX_CHAR): - stack_3d(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_INT): - title(NX_CHAR): - intensity(NX_NUMBER): - \@long_name(NX_CHAR): - spectrum_identifier(NX_INT): - \@long_name(NX_CHAR): - axis_k(NX_NUMBER): - \@long_name(NX_CHAR): - axis_j(NX_NUMBER): - \@long_name(NX_CHAR): - axis_i(NX_NUMBER): - \@long_name(NX_CHAR): - axis_energy(NX_NUMBER): - \@long_name(NX_CHAR): - - em_lab(NXinstrument): - exists: recommended - ebeam_column(NXebeam_column): - operation_mode(NX_CHAR): - electron_source(NXsource): - doc: - - | - xref: - spec: EMglossary - term: Source - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 - voltage(NX_NUMBER): - doc: - - | - The potential difference between anode and cathode. - - | - xref: - spec: EMglossary - term: Acceleration Voltage - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000004 - extraction_voltage(NX_NUMBER): - exists: optional - doc: - - | - Voltage which is utilised to create an electric field that draws particles from the source. - - | - xref: - spec: EMglossary - term: Extraction Voltage - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 - unit: NX_VOLTAGE - emission_current(NX_NUMBER): - exists: optional - doc: - - | - Electrical current which is released from the source. - - | - xref: - spec: EMglossary - term: Emission Current - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 - unit: NX_CURRENT - filament_current(NX_NUMBER): - exists: optional - doc: - - | - Electrical current which flows through the source. - - | - xref: - spec: EMglossary - term: Filament Current - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000027 - unit: NX_CURRENT - lensID(NXlens_em): - exists: [min, 0, max, infty] - value(NX_NUMBER): - apertureID(NXaperture): - exists: [min, 0, max, infty] - value(NX_NUMBER): - doc: - - | - Relevant value from the control software. - - | - This is not always just the diameter of the aperture (not even in the case) - of a circular aperture. Usually, it is a value that is set in the control - software whereby a specific configuration of an aperture is selected by the - software. - - The control software of commercial microscope typically offers the user - access at a high abstraction level because of which many details about - the actual settings of the electrical components are typically unknown. - - However, if more details are known or should be documented one should - use the description field for this. - unit: NX_ANY - monochromatorID(NXmonochromator): - exists: [min, 0, max, infty] - doc: - - | - Device to improve energy resolution or chromatic aberration. - - | - Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector like `_ - # user perspective - applied(NX_BOOLEAN): - doc: - - | - Was the corrector used? - # control level perspective - # technical components of the corrector - dispersion(NX_NUMBER): - exists: recommended - doc: - - | - Energy dispersion in e.g. µm/eV. - unit: NX_ANY - voltage(NX_NUMBER): - exists: recommended - doc: - - | - Corresponding voltage for that energy dispersion. - unit: NX_VOLTAGE - corrector_cs(NXcorrector_cs): - exists: [min, 0, max, 1] # but there are systems with several ones https://www.globalsino.com/EM/page4263.html - applied(NX_BOOLEAN): - exists: recommended - tableauID(NXprocess): - exists: [min, 1, max, infty] - # model(NX_CHAR): - # exists: optional - # ceos - c_1(NXaberration): - exists: optional - magnitude(NX_NUMBER): - a_1(NXaberration): - exists: optional - magnitude(NX_NUMBER): - b_2(NXaberration): - exists: optional - magnitude(NX_NUMBER): - a_2(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_3(NXaberration): - exists: optional - magnitude(NX_NUMBER): - s_3(NXaberration): - exists: optional - magnitude(NX_NUMBER): - a_3(NXaberration): - exists: optional - magnitude(NX_NUMBER): - b_4(NXaberration): - exists: optional - magnitude(NX_NUMBER): - d_4(NXaberration): - exists: optional - magnitude(NX_NUMBER): - a_4(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_5(NXaberration): - exists: optional - magnitude(NX_NUMBER): - s_5(NXaberration): - exists: optional - magnitude(NX_NUMBER): - r_5(NXaberration): - exists: optional - magnitude(NX_NUMBER): - a_6(NXaberration): - exists: optional - magnitude(NX_NUMBER): - # nion - c_1_0(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_1_2_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_1_2_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_2_1_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_2_1_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_2_3_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_2_3_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_3_0(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_3_2_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_3_2_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_3_4_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_3_4_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_4_1_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_4_1_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_4_3_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_4_3_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_4_5_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_4_5_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_5_0(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_5_2_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_5_2_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_5_4_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_5_4_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_5_6_a(NXaberration): - exists: optional - magnitude(NX_NUMBER): - c_5_6_b(NXaberration): - exists: optional - magnitude(NX_NUMBER): - # we could write down how to store the aberrations but we should not force to add aberrations - # basically optional use of NXaberration therein at least some value required - corrector_ax(NXcomponent): - exists: [min, 0, max, 1] - doc: - - | - Device reshaping an ellipse-shaped electron beam to a circular one. - - * `L. Reimer 1998, Springer, 1998 `_ - * `M. Tanaka et al., Electron Microscopy Glossary, 2024 `_ - - - | - Stigmator is an exact synonym. - applied(NX_BOOLEAN): - doc: - - | - Was the corrector used? - value_x(NX_NUMBER): - doc: - - | - Descriptor for the correction strength along the first direction when exact technical details - are unknown or not directly controllable as the control software of the microscope does not - enable or was not configured to display these values (for end users). - unit: NX_ANY - value_y(NX_NUMBER): - doc: - - | - Descriptor for the correction strength along the second direction when exact technical details - are unknown or not directly controllable as the control software of the microscope does not - enable or was not configured to display these values (for end users). - unit: NX_ANY - biprism(NXcomponent): - exists: [min, 0, max, 1] - phaseplateID(NXcomponent): - exists: [min, 0, max, infty] - sensorID(NXsensor): - exists: [min, 0, max, infty] - actuatorID(NXactuator): - exists: [min, 0, max, infty] - (NXbeam): - exists: [min, 0, max, infty] - doc: - - | - xref: - spec: EMglossary - term: Electron Beam - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000021 - ibeam_column(NXibeam_column): - exists: [min, 0, max, 1] - ion_source(NXsource): - probe(NXion): - voltage(NX_NUMBER): - lensID(NXlens_em): - exists: [min, 0, max, infty] - value(NX_NUMBER): - apertureID(NXaperture): - exists: [min, 0, max, infty] - value(NX_NUMBER): - doc: - - | - Relevant value from the control software. - - | - This is not always just the diameter of the aperture (not even in the case) - of a circular aperture. Usually, it is a value that is set in the control - software whereby a specific configuration of an aperture is selected by the - software. - - The control software of commercial microscope typically offers the user - access at a high abstraction level because of which many details about - the actual settings of the electrical components are typically unknown. - - However, if more details are known or should be documented one should - use the description field for this. - unit: NX_ANY - monochromatorID(NXmonochromator): - exists: [min, 0, max, infty] - applied(NX_BOOLEAN): - sensorID(NXsensor): - exists: [min, 0, max, infty] - actuatorID(NXactuator): - exists: [min, 0, max, infty] - (NXbeam): - exists: [min, 0, max, infty] - detectorID(NXdetector): - exists: [min, 0, max, infty] - mode(NX_CHAR): - scan_controller(NXscanbox_em): - exists: optional - scan_schema(NX_CHAR): - dwell_time(NX_NUMBER): - - (NXsensor): - exists: [min, 0, max, infty] - (NXactuator): - exists: [min, 0, max, infty] - heater(NXactuator): - exists: optional - current(NX_NUMBER): - doc: - - | - Nominal current of the heater. - unit: NX_CURRENT - voltage(NX_NUMBER): - doc: - - | - Nominal voltage of the heater. - unit: NX_VOLTAGE - power(NX_NUMBER): - doc: - - | - Nominal power of the heater. - unit: NX_POWER - (NXstage_lab): - exists: [min, 0, max, infty] - design(NX_CHAR): - exists: recommended - (NXchamber): - exists: [min, 0, max, infty] - (NXpump): - exists: [min, 0, max, infty] - - simulation(NXem_sim): - exists: optional - # remains to be discussed based on examples - - # relevant research result post-processed for specific community methods - # but normalized in its representation ready to be consumed for a - # research data management system - roiID(NXroi): - exists: [min, 0, max, infty] - doc: - - | - A region-of-interest analyzed either during or after the session - for which specific processed data are available. - - | - xref: - spec: EMglossary - term: Region Of Interest - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000042 - # as soon as one entry is here constrained further - # an RDM can be sure to find specific pieces of information in a - # specific way but then every user of this application definition - # is required to provide such information in this way! - imaging(NXem_img): - exists: optional - imaging_mode(NX_CHAR): - (NXimage_set): - exists: [min, 0, max, infty] - half_angle_interval(NX_NUMBER): - exists: optional - # microstructureID(NXmicrostructure): - # exists: optional - ebsd(NXem_ebsd): - exists: optional - # remains to be discussed based on examples - gnomonic_reference_frame(NXcoordinate_system): - exists: optional - alias(NX_CHAR): - exists: optional - type(NX_CHAR): - handedness(NX_CHAR): - origin(NX_CHAR): - x_direction(NX_CHAR): - y_direction(NX_CHAR): - z_direction(NX_CHAR): - pattern_centre(NXprocess): - exists: recommended - x_boundary_convention(NX_CHAR): - x_normalization_direction(NX_CHAR): - y_boundary_convention(NX_CHAR): - y_normalization_direction(NX_CHAR): - measurement(NXprocess): - exists: optional - depends_on(NX_CHAR): - source(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - simulation(NXprocess): - exists: optional - depends_on(NX_CHAR): - source(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - indexing(NXprocess): - exists: optional - number_of_scan_points(NX_UINT): - indexing_rate(NX_NUMBER): - exists: recommended - source(NXserialized): - exists: optional - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - phaseID(NXcrystal_structure): - exists: [min, 0, max, infty] - number_of_scan_points(NX_UINT): - a_b_c(NX_NUMBER): - alpha_beta_gamma(NX_NUMBER): - space_group(NX_CHAR): - phase_identifier(NX_INT): - phase_name(NX_CHAR): - # ipfID(NXmicrostructure_ipf): - # exists: recommended - # projection_direction(NX_NUMBER): - # map(NXdata): - # \@signal(NX_CHAR): - # \@axes(NX_CHAR): - # \@AXISNAME_indices(NX_INT): - # title(NX_CHAR): - # data(NX_NUMBER): - # \@long_name(NX_CHAR): - # axis_x(NX_NUMBER): - # \@long_name(NX_CHAR): - # axis_y(NX_NUMBER): - # exists: optional - # \@long_name(NX_CHAR): - # axis_z(NX_NUMBER): - # exists: optional - # \@long_name(NX_CHAR): - # legend(NXdata): - # \@signal(NX_CHAR): - # \@axes(NX_CHAR): - # \@AXISNAME_indices(NX_INT): - # title(NX_CHAR): - # data(NX_NUMBER): - # \@long_name(NX_CHAR): - # axis_x(NX_NUMBER): - # \@long_name(NX_CHAR): - # axis_y(NX_NUMBER): - # \@long_name(NX_CHAR): - roi(NXdata): - exists: recommended - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_CHAR): - title(NX_CHAR): - descriptor(NX_CHAR): - data(NX_NUMBER): - axis_y(NX_NUMBER): - \@long_name(NX_CHAR): - axis_x(NX_NUMBER): - \@long_name(NX_CHAR): - eds(NXem_eds): - exists: optional - # remains to be discussed based on examples - indexing(NXprocess): - summary(NXdata): - exists: optional - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_CHAR): - title(NX_CHAR): - intensity(NX_NUMBER): - axis_energy(NX_CHAR): - \@long_name(NX_CHAR): - atom_types(NX_CHAR): - (NXimage_set): - exists: [min, 0, max, 118] # given that image_set instances should be named with the chemical_symbol of the elements - iupac_line_candidates(NX_CHAR): - exists: recommended - energy_range(NX_NUMBER): - image_2d(NXdata): - \@signal(NX_CHAR): - \@axes(NX_CHAR): - \@AXISNAME_indices(NX_CHAR): - title(NX_CHAR): - exists: optional - intensity(NX_NUMBER): - \@units(NX_CHAR): - exists: recommended - axis_i(NX_NUMBER): # x - \@long_name(NX_CHAR): - \@units(NX_CHAR): - axis_j(NX_NUMBER): # y - \@long_name(NX_CHAR): - \@units(NX_CHAR): # exemplar test to enforce that units are added - eels(NXem_eels): - exists: optional - correlation(NXem_correlation): - exists: optional - # remains to be discussed based on examples - -# see an example how to map e.g. the following flat schema https://www.zenodo.org/record/6513745 to NXem -# in https://github.com/FAIRmat-NFDI/nexus_definitions/commit/0b928c4352bc5636f673b5fb25ce990f1af8a099 \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml deleted file mode 100644 index d0c25acc19..0000000000 --- a/contributed_definitions/nyaml/NXem_correlation.yaml +++ /dev/null @@ -1,450 +0,0 @@ -category: base -doc: | - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. -type: group -NXem_correlation(NXem_method): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - indexing(NXprocess): - doc: | - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXmicrostructure partner application - definition. The respective source of the data in an instance of NXmicrostructure can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - (NXcrystal_structure): - roi(NXdata): - descriptor: - doc: | - Descriptor representing the image contrast. - - # \@signal: # data - # \@axes: # [axis_y, axis_x] - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - # \@signal: - # \@axes: - # \@AXISNAME_indices: - # \@long_name: - title: - doc: | - Title of the default plot. - data(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Descriptor values displaying the ROI. - dimensions: - rank: 3 - dim: [[1, n_z], [2, n_y], [3, n_x]] - - # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - Descriptor values. - axis_z(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the z-axis. - dimensions: - rank: 1 - dim: [[1, n_z]] - \@long_name: - doc: | - Label for the z axis - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the y-axis. - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - doc: | - Label for the y axis - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the x-axis. - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - doc: | - Label for the x axis - - # NEW ISSUE: implement support for filters eventually many of them - # NEW ISSUE: for now only show that data from DREAM3D can be loaded. - # NEW ISSUE: how to handle landmarks - # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid - # image registration etc. - # sequence_index(N0): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 7f16c96c600114d0cff2a2325462e880c20a26d2ad095ed13d00a3b7270dd452 -# -# -# -# -# -# Base class to combine different method-specific data in electron microscopy. -# -# This base class represent a template for documenting correlations -# (spatial, temporal) between different method-specific results. -# -# -# -# Details about processing steps. -# -# -# -# -# -# Details about correlated or logically connected EBSD datasets. -# -# One important class of such correlated experiments are the so-called -# (quasi) in-situ experiments. In this case the same or nearly the same ROI -# gets analyzed via a repetitive sequence of thermomechanical treatment, -# sample preparation, measurement, on-the-fly-indexing. Phenomena -# investigated are recrystallization, strain accumulation, material damage. -# Post-processing is required to correlate and reidentify eventual -# microstructural features or local ROIs across several orientation maps. -# -# Another important class of correlated experiments are the so-called -# serial-sectioning experiments. Here the same sample is measured -# repetitively after polishing each time, to create a stack of -# orientation data which can be reconstructed to a -# three-dimensional volume ROI. -# -# Data can be correlated in time, position (spatial), or both (spatiotemporal). -# -# Spatial correlations between repetitively characterized regions-of-interests -# are typically correlated using image registration and alignment algorithms. -# For this typically so-called landmarks are used. These can be grains with -# a very large size or specific shape, i.e. grains which are qualitatively -# different enough to be used as a guide how images are shifted relative to -# one another. Other commonly used landmarks are fiducial marks which are -# milled into the specimen surface using focus-ion beam milling and/or various -# types of indentation methods. -# -# As far as the same physical region-of-interest is just measured several times, -# the additional issue of the depth increment is not a concern. However, correct -# assumptions for the depth increment, amount of material removed along the milling -# direction is relevant for accurate and precise three-dimensional (serial-sectioning) -# correlations. For these studies it can be tricky though to assume or estimate -# useful depth increments. Different strategies have been proposed like -# calibrations, wedged-shaped landmarks and computer simulation assisted -# assumption making. -# -# Despite the use of landmarks, there are many practical issues which make the -# processing of correlations imprecise and inaccurate. Among these are drift -# and shift of the specimen, instabilities of the holder, the beam, irrespective -# of the source of the drift, charging effects, here specifically causing local -# image distortions and rotations which may require special processing algorithms -# to reduce such imprecisions. -# -# Time correlations face all of the above-mentioned issues surplus the challenge -# that specific experimental protocols have to be used to ensure the material state -# is observed at specific physical time. The example of quasi in-situ characterization -# of crystal growth phenomena, a common topic in engineering or modern catalysis research -# makes it necessary to consider that e.g. the target value for the desired annealing -# temperature is not just gauged based on macroscopic arguments but considers -# that transient effects take place. Heating or quenching a sample might thus might -# not have been executed under conditions in the interaction volume as they are -# documented and/or assumed. -# -# These issue cause that correlations have an error margin as to how accurately -# respective datasets were not only just synced based on the geometry of the -# region-of-interests and the time markers but also to asssure which physical -# conditions the specimen experienced over the course of the measurements. -# -# The fourth example of the em_om reference implementation explores the use of the -# correlation group with a serial-sectioning datasets that was collected by the -# classical Inconel 100 dataset collected by M. D. Uchic and colleagues -# (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and -# characterization of polycrystalline microstructures using a fib-sem system data set. -# Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). -# -# This dataset was specifically relevant in driving forward the implementation -# of the DREAM.3D software. DREAM.3D is an open-source software project for -# post-processing and reconstructing, i.e. correlating sets of orientation -# microscopy data foremost spatially. One focus of the software is the -# (post-)processing of EBSD datasets. Another cutting edge tool with similar -# scope but a commercial solution by Bruker is QUBE which was developed by -# P. Konijnenberg and coworkers. -# -# Conceptually, software like DREAM.3D supports users with creating linear -# workflows of post-processing tasks. Workflows can be instructed via the -# graphical user interface or via so-called pipeline processing via command line -# calls. DREAM.3D is especially useful because its internal system documents all -# input, output, and parameter of the processing steps. This makes DREAM.3D a -# good candidate to interface with tools like em_om parser. Specifically, DREAM.3D -# documents numerical results via a customized HDF5 file format called DREAM3D. -# Workflow steps and settings are stored as nested dictionaries in JSON syntax -# inside a supplementary JSON file or alongside the data in the DREAM3D file. -# DREAM.3D has a few hundred algorithms implemented. These are called filters -# in DREAM.3D terminology. -# -# Users configure a workflow which instructs DREAM.3D to send the data through -# a chain of predefined and configured filters. Given that for each analysis -# the filter is documented via its version tags surplus its parameter and setting -# via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file -# is possible in an automated manner using a parser. This makes DREAM.3D analyses -# repeatable and self-descriptive. A key limitation though is that most frequently -# the initial set of input data come from commercial files like ANG. -# This missing link between the provenance of these input files, their associated -# creation as electron microscope session, is also what NXem_ebsd solves. -# -# Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that -# the DREAM.3D and the em_om parser can work productively together to realize -# RDMS-agnostic parsing of serial-section analyses. -# -# The internal documentation of the DREAM.3D workflow also simplifies the -# provenance tracking represented by an instance of NXem_ebsd as not every -# intermediate results has to be stored. Therefore, the fourth example -# focuses on the key result obtained from DREAM.3D - the reconstructed -# and aligned three-dimensional orientation map. -# -# Usually, this result is the starting point for further post-processing -# and characterization of structural features. As here orientation microscopy -# is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should -# be useful for different characterization methods, such as EBSD, Transmission -# Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), -# Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) -# or open-source implementations of these techniques (such as via pyxem/orix). -# -# The result of orientation microscopy methods are maps of local orientation -# and thermodynamic phase (crystal structure) pieces of information. Virtually -# all post-processing of such results for structural features includes again -# a workflow of steps which are covered though by the NXmicrostructure partner application -# definition. The respective source of the data in an instance of NXmicrostructure can -# again be a link or reference to an instance of NXem_ebsd to complete the -# chain of provenance. -# -# -# -# -# -# Descriptor representing the image contrast. -# -# -# -# -# -# Title of the default plot. -# -# -# -# -# Descriptor values displaying the ROI. -# -# -# -# -# -# -# -# -# -# Descriptor values. -# -# -# -# -# -# Calibrated coordinate along the z-axis. -# -# -# -# -# -# -# Label for the z axis -# -# -# -# -# -# Calibrated coordinate along the y-axis. -# -# -# -# -# -# -# Label for the y axis -# -# -# -# -# -# Calibrated coordinate along the x-axis. -# -# -# -# -# -# -# Label for the x axis -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXem_ebsd.yaml b/contributed_definitions/nyaml/NXem_ebsd.yaml deleted file mode 100644 index a182b05785..0000000000 --- a/contributed_definitions/nyaml/NXem_ebsd.yaml +++ /dev/null @@ -1,1249 +0,0 @@ -category: base -doc: -- | - Base class method-specific for Electron Backscatter Diffraction (EBSD). -- | - The general procedure of an EBSD experiment is as follows. - Users load the specimen, collect first a coarse image of the surface. - Next, they set an approximate value for the calibrated working distance and - tilt the stage to set the desired diffraction conditions. -- | - Users then typically configure the microscope for collecting higher quality data - and push in the EBSD detector. Subsequently, they fine tune the illumination - and aberration corrector settings and select one or multiple ROIs for - the microscope to machine off automatically. They configure on-the-fly - indexing parameter and start the measurement queue. -- | - Nowadays, this is in most cases an automated process. The pattern - collection runs during the allocated microscope session until the - queue finishes or gets interrupted by errors or the next user terminates - sessions which run over time. -- | - Kikuchi pattern surplus eventually multi-modal detector signals are - collected and usually indexed on-the-fly. Patterns may be stored or not - so one should not assume that raw data are always stored. -- | - Results are stored in files, which afterwards are typically copied - automatically or manual for archival purposes to certain storage - locations or further consumption. The result of such an EBSD - measurement/experiment is a set of usually proprietary or open files - from technology partners. -- | - This :ref:`NXem_ebsd` base class is a proposal how to represent method-specific - data, metadata, and connections between these for the research field of - electron microscopy. -- | - More specifically, exemplified here for electron backscatter diffraction (EBSD) - we show how NeXus can be used to solve two key documentation issues so far - missing in the field of EBSD. -- | - Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted - according to NXem_ebsd) stores the connection between the microscope session and - the key datasets which are considered typically results of the various processing - steps involved when working with EBSD data. -- | - Different groups in NXem_ebsd make connections to data artifacts which were collected - when working with electron microscopes via the NXem application definition. - Using a file which stores information according to the NXem application definition - has the benefit that it connects the sample, references to the sample processing, - the user operating the microscope, details about the microscope session, - and details about the acquisition and eventual indexing of Kikuchi pattern, - associated overview images, like secondary electron or backscattered electron - images of the region-of-interest probed and many more pieces of information. -- | - Secondly, NXem_ebsd connects and stores the conventions and reference frames - which were used and which are the key to a correct mathematical interpretation - of every EBSD result. Otherwise, results would be ripped out of their context, - as it is the current situation with many traditional studies where EBSD data - were indexed on-the-fly and shared with the community only via sharing - the strongly processed results file in some technology-partner-specific file - format but without communicating all conventions or relying on the assumptions - that colleagues likely know these conventions even though multiple definitions - are possible. -- | - NXem_ebsd covers experiments with one-, two-dimensional, and so-called three- - dimensional EBSD datasets. The third dimension is either time (in the case of - quasi in-situ experiments) or space (in the case of serial-sectioning) methods - where a combination of mechanical or ion milling is used repetitively to measure - the same region-of-interest at different depth increments. Material removal - can be achieved with electron or ion polishing, using manual - steps or using automated equipment like a robot system. -- | - Three-dimensional experiments require to follow a sequence of specimen, surface - preparation, and data collection steps. By nature these methods are destructive - in that they either require the removal of the previously measured material region - or that the sample surface can degrade due to e.g. contamination or other - electron-matter interaction. -- | - For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are - combined into one reconstructed stack. That is serial-sectioning is mainly a - computational workflow. Users collect data for each serial sectioning step - via an experiment. This assures that data for associated microscope sessions - and steps of data processing stay connected and contextualized. -- | - Eventual tomography methods also use such a workflow because first diffraction - images are collected (e.g. with X-ray) and then these imagres are indexed and - computed into a 3D orientation mapping. The here proposed NXem_ebsd application - definition contains conceptual ideas how this splitting between measurement and - post-processing can be granularized also for such X-ray-based techniques, whether - it be 3DXRD or HEDM. -- | - xref: - spec: EMglossary - term: Electron Backscatter Diffraction - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000019 -symbols: - n_op: | - Number of arguments per orientation for given parameterization. - n_sc: | - Number of scan points. - n_z: | - Number of pixel along the slowest changing dimension for a rediscretized, - i.e. standardized default plot orientation mapping. - n_y: | - Number of pixel along slow changing dimension for a rediscretized i.e. - standardized default plot orientation mapping. - n_x: | - Number of pixel along fast changing dimension for a rediscretized i.e. - standardized default plot orientation mapping. - n_solutions: | - Number of phase solutions -type: group -NXem_ebsd(NXem_method): - - # (NXcoordinate_system): - gnomonic_reference_frame(NXcoordinate_system): - doc: | - Details about the gnomonic (projection) reference frame. - - It is assumed that the configuration is inspected by looking towards the sample surface. - If a detector is involved, it is assumed that the configuration is inspected from a position - that is located behind this detector. - - If any of these assumptions is not met, the user is required to explicitly state this. - - Reference DOI: 10.1016/j.matchar.2016.04.008 suggests to label the - base vectors of this coordinate system as Xg, Yg, Zg. - origin(NX_CHAR): - doc: | - Origin of the gnomonic_projection_reference_frame. - - Reference DOI: 10.1016/j.matchar.2016.04.008 suggests to - assume that this is coordinate Xg = 0, Yg = 0, Zg = 0. - enumeration: [undefined, in_the_pattern_centre] - x_direction(NX_CHAR): - doc: | - Direction of the positively pointing x-axis base vector of the - gnomonic_reference_frame. - enumeration: [undefined, north, east, south, west, in, out] - y_direction(NX_CHAR): - doc: | - Direction of the positively pointing y-axis base vector of the - gnomonic_reference_frame. - enumeration: [undefined, north, east, south, west, in, out] - z_direction(NX_CHAR): - doc: | - Direction of the positively pointing z-axis base vector of the - gnomonic_reference_frame. - enumeration: [undefined, north, east, south, west, in, out] - pattern_centre(NXprocess): - doc: | - Details about the definition of the pattern centre as a special point in the gnomonic_reference_frame. - - Keep in mind that the gnomonic space is in virtually all cases embedded in the detector space. - Specifically, the XgYg plane is defined such that it is laying inside the XdYd plane - (of the detector reference frame). - - When the normalization direction is the same as e.g. the detector x-axis direction one - effectively normalizes in fractions of the width of the detector. - - The issue with terms like width and height is that these degenerate if the detector - region-of-interest is square-shaped. This is why instead of referring to width and height - one should report as if one were to measure practically with a ruler and one is specific - about in which direction positive distances are measured. - - For the concepts used to specify the boundary_convention it is assumed that the - region-of-interest is defined by a rectangle, referring to the direction of outer-unit - normals to the respective edges of this rectangle. - x_boundary_convention(NX_CHAR): - doc: | - From which border of the EBSP (in the detector reference frame) is the pattern - centre's x-position (PCx) measured. - enumeration: [undefined, top, right, bottom, left] - x_normalization_direction(NX_CHAR): - doc: | - In which direction are positive values for the x-axis coordinate value measured - from the specified boundary. - enumeration: [undefined, north, east, south, west] - y_boundary_convention(NX_CHAR): - doc: | - From which border of the EBSP (in the detector reference frame) is the pattern - centre's y-position (PCy) measured. - enumeration: [undefined, top, right, bottom, left] - y_normalization_direction(NX_CHAR): - doc: | - In which direction are positive values for the y-axis coordinate value measured - from the specified boundary. - enumeration: [undefined, north, east, south, west] - - # distance_convention: - # doc: | - # How is the third of the three pattern centre parameter values, - # the (distance) parameter DD, normalized. Which convention - # is followed. We are aware that specifying one of the options here - # also implicitly comes with conventions for some of the parameter - # requested in this ELN. For now we would rather like to ask - # the users though to be specific also to learn how such an ELN - # will be used in practice. - # enumeration: [undefined, Bruker, JEOL, FEI, Oxford] - measurement(NXprocess): - doc: | - This group documents relevant details about the conditions and the tools - used for measuring a stack of Kikuchi diffraction pattern with an - electron microscope. - - The most frequently collected EBSD data are captured for rectangular - regions-of-interested which are sampled with regular square or - hexagon-shaped pixels. - time(NX_NUMBER): - unit: NX_TIME - doc: | - Physical time since the beginning of a timestamp that is required to be - same for all experiments in the set. The purpose of this marker is - to identify how all experiments in the set need to be arranged - sequentially based on the time elapsed. - The time is relevant to sort e.g. experiments of consecutive quasi - in-situ experiments where a measurement was e.g. taken after 0 minutes, - 30 minutes, 6 hours, or 24 hours of annealing. - \@epoch_start: - type: NX_CHAR - doc: | - Timestamp relative to which time was counted to aid - converting between time and timestamp. - - # (NXtransformations): - # doc: | - # Transformation which details where the region-of-interest described under - # indexing is located in absolute coordinates and rotation with respect - # to which coordinate system. - # pattern_available(NX_BOOLEAN): - # doc: | - # True if pattern were stored and are retrieveable via depends_on or source. - depends_on(NX_CHAR): - doc: | - If available and it is stored in an instance of an application definition this field - specifies the path to an instance of :ref:`NXdata` where the measured patterns - are stored. - source(NXserialized): - doc: | - Reference (e.g. path and filename) to an existent data artifact which - stores either the measured pattern or input (already processed EBSD data). - simulation(NXprocess): - doc: | - This group documents relevant details about the conditions and the tools - used for simulating a stack of Kikuchi diffraction pattern with some - physical model. - - This group should not be confused with a group named simulation that - is however an instance of NXem_sim. Instead, the simulation group here - should be used if (e.g. instead of a measurement) a stack of pattern - were simulated that one wishes to use for indexing patterns. - - In many practical cases where pattern are analyzed on-the-fly and dictionary - indexing strategies are used, so-called master pattern(s) are used to compare - measured or simulated pattern with the master pattern. In this case, - master pattern are the result of a computer simulation and thus should - be stored using an own properly documented entry within a simulation - group as an instance of :ref:`NXem_sim`. - depends_on(NX_CHAR): - doc: | - If available and it is stored in an instance of an application definition this field specifies - the path to an instance of :ref:`NXimage_set` where the simulated patterns are stored. - source(NXserialized): - doc: | - Reference (e.g. path and filename) to an existent digital resource which - stores either the pattern or input (already processed EBSD data) - which is now processed further as described by this NXem_ebsd instance. - calibration(NXprocess): - doc: | - The EBSD system, including components like the electron gun, pole-piece, - stage tilting, EBSD detector, and the gnomonic projection have to be - calibrated to achieve reliable indexing results. - - Specifically, the gnomonic projection has to be calibrated. - Typically, silicon or quartz crystals are used for this purpose. - - Considering a system is well-calibrated, it is much more frequently the - case in practice that users assume the system is calibrated (and thus usable) - vs. they perform the calibration of the EBSD system. - - In the first case, the user assumes that the principle geometry of the - hardware components and the settings in the control and EBSD pattern - acquisition software has been calibrated. Consequently, users pick from - an existent library of phase candidates, i.e. - :ref:`NXcrystal_structure` instances. Examples are - reflector models as stored in CRY files (HKL/Channel 5/Flamenco). - - In the second case, users calibrate the system during the session - using standards (silicon, quartz, or other common specimens). - There is usually one person in each lab responsible for doing such - calibrations. Often this person or technician is also in charge of - configuring the graphical user interface and software with which most - users control and perform their analyses. - - For EBSD this has key implications: Taking TSL OIM/EDAX as an example, - the conventions how orientations are stored is affected by how the - reference frames are configured and this setup is made at the level - of the GUI software. - - Unfortunately, these pieces of information are not necessarily stored - in the results files. In effect, key conventions become disconnected - from the data so it remains the users' obligation to remember these - settings or write these down in a lab notebook. Otherwise, these metadata - get lost. All these issues are a motivation and problem which - :ref:`NXem_ebsd` solves in that all conventions can be specified explicitly. - depends_on(NX_CHAR): - doc: | - If available and it is stored in an instance of an application definition this field specifies - the path to an instance of :ref:`NXem_msr` where calibration is stored. - source(NXserialized): - doc: | - Reference to a digital resource where the calibration is stored. - indexing(NXprocess): - doc: | - Indexing is a data processing step performed either after or while - (on-the-fly) the beam scans the specimen. The resulting method is also - known as orientation imaging microscopy (OIM). - - Different algorithms can be used to index EBSD pattern. Common to them - is the computational step where simulated reference pattern are compared - with measured or simulated patterns. These latter patterns are referred - to via the measurement or simulation groups of this base class. - - Quality descriptors are defined based on which an indexing algorithm - yields a quantitative measure of how similar measured and reference - pattern are, and thus if no, one, or multiple so-called solutions - were found. - - Assumed or simulated pattern are simulated using kinematic or dynamical - theory of electron diffraction delivering master pattern. - - The Hough transform is essentially a discretized Radon transform (for details see `M. van Ginkel et al. `_). - Recently, dictionary-based indexing methods are increasingly becoming used - partly driven by the interest to use artificial intelligence algorithms. - source(NXserialized): - doc: | - This group enables to establish a logical connection between previous - processing steps or on-the-fly-performed indexing of the EBSD map. - Typically these processing steps are performed with commercial software. - Therefore, in many cases a results file from this indexing is often - all that is communicated and saved. These are typically files in a format - specific to the instrument and its configuration. - - Typical file formats are CPR/CRC, ANG, OSC, HDF5, H5EBSD, EDAXH5. - method(NX_CHAR): - doc: | - Principal algorithm used for indexing. - enumeration: [undefined, hough_transform, dictionary, radon_transform, other] - background_correction(NXprocess): - doc: | - Details about the background correction applied to each Kikuchi pattern. - binning(NXprocess): - doc: | - Binning i.e. downsampling of the pattern. - parameter(NXprocess): - doc: | - Specific parameter relevant only for certain algorithms used. - phaseID(NXcrystal_structure): - doc: | - Details for each phase used as a model with which the patterns were - indexed. Instances of :ref:`NXcrystal_structure` in this group must - have the group name prefix phase. The identifier in the name is an - integer. We start counting from 1 because the value 0 is reserved for - the special phase that is the null-model, i.e. the null phase, notIndexed. - status(NX_UINT): - unit: NX_UNITLESS - doc: | - Which return value did the indexing algorithm yield for each scan point. - Practically useful is to use an uint8 mask. - - * 0 - Not analyzed - * 1 - Too high angular deviation - * 2 - No solution - * 100 - Success - * 255 - Unexpected errors - dimensions: - rank: 1 - dim: [[1, n_sc]] - n_phases_per_scan_point(NX_INT): - unit: NX_UNITLESS - doc: | - How many phases i.e. crystal structure models were used to index each - scan point if any? Let's assume an example to explain how this field - should be used: In the simplest case users collected one pattern for - each scan point and have indexed using one phase, i.e. one instance - of an NXem_ebsd_crystal_structure_model. - - In another example users may have skipped some scan points (not indexed) - them at all) and/or used differing numbers of phases for different scan - points. - - The cumulated of this array decodes how phase_identifier and phase_matching - arrays have to be interpreted. In the simplest case (one pattern per scan - point, and all scan points indexed using that same single phase model), - phase_identifier has as many entries as scan points - and phase_matching has also as many entries as scan points. - dimensions: - rank: 1 - dim: [[1, n_sc]] - phase_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - The array n_phases_per_scan_point details how the phase_identifier - and the phase_matching arrays have to be interpreted. - - For the example with a single phase phase_identifier has trivial - values either 0 (no solution) or 1 (solution matching - sufficiently significant with the model for phase 1). - - When there are multiple phases, it is possible (although not frequently - needed) that a pattern matches eventually (not equally well) sufficiently - significant with multiple pattern. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models e.g. (ferrite, austenite). - Having such field is especially relevant for recent machine learning - or dictionary based indexing schemes because in combination with - phase_matching these fields communicate the results in a model-agnostic - way. - - Depending on the n_phases_per_scan_point value phase_identifier and - phase_matching arrays represent a collection of concatenated tuples, - which are organized in sequence: The solutions for the 0-th scan point, - the 1-th scan point, the n_sc - 1 th scan point and omitting tuples - for those scan points with no phases according to n_phases_per_scan_point - dimensions: - rank: 1 - dim: [[1, n_solutions]] - phase_matching(NX_INT): - unit: NX_UNITLESS - doc: | - One-dimensional array, pattern by pattern labelling the solutions found. - The array n_phases_per_scan_point has to be specified because it details - how the phase_identifier and the phase_matching arrays have to be interpreted. - See documentation of phase_identifier for further details. - dimensions: - rank: 1 - dim: [[1, n_solutions]] - phase_matching_descriptor(NX_CHAR): - doc: | - Phase_matching is a descriptor for how well the solution matches or not. - Examples can be confidence_index, mean_angular_deviation, some AI-based - matching probability (other), i.e. the details are implementation-specific. - enumeration: [undefined, confidence_index, mean_angular_deviation, other] - rotation_set(NXrotation_set): - - # px is no one of the following two calibrated i) is not px*stepsize or ii) is not - # px*stepsize + offset - scan_point_positions(NX_NUMBER): - unit: NX_LENGTH - - # we make this only required as people may not yet be so happy with - # having to walk a graph from measurement -> path -> NXevent_data_em - # -> em_lab/ebeam_deflector to retrieve the actual scan positions - # although this would be cleaner, also scan_point_positions could be - # an instance of NXcg_point_set with a depends_on pointing - # to sample_reference_frame - doc: | - Calibrated center positions of each scan point - in the sample surface reference system. - dimensions: - rank: 2 - dim: [[1, n_sc], [2, 2]] - indexing_rate(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - Fraction of successfully indexed pattern with a phase - not the null-phase vs the number_of_scan_points. - number_of_scan_points(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of scan points in the original mapping. - unit: NX_UNITLESS - # odfID(NXmicrostructure_odf): - # pfID(NXmicrostructure_pf): - # ipfID(NXmicrostructure_ipf): - # microstructureID(NXmicrostructure): - # overview over the entire map, rediscretized on a tight aabb - roi(NXdata): - doc: | - An overview of the entire ROI. - descriptor(NX_CHAR): - doc: | - Descriptor representing the image contrast. - - # taking two examples (CTF and H5OINA choked completely of possibility to find s.th. conceptually common to plot - enumeration: [band_contrast, confidence_index, mean_angular_deviation] - - # \@signal: # data - # \@axes: # [axis_y, axis_x] - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - # \@signal: - # \@axes: - # \@AXISNAME_indices: - # \@long_name: - title(NX_CHAR): - doc: | - Title of the default plot. - data(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Descriptor values displaying the ROI. - dimensions: - rank: 2 - dim: [[1, n_y], [2, n_x]] - - # n_0 slow 2, n_1 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - type: NX_CHAR - doc: | - Descriptor values. - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the y-axis. - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - type: NX_CHAR - doc: | - Label for the y axis - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the x-axis. - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - type: NX_CHAR - doc: | - Label for the x axis - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 22b1c39fad61b0675c918c1a4eef96e00364bd4ac83f9d4ffbe8702ac448a9c7 -# -# -# -# -# -# -# -# Number of arguments per orientation for given parameterization. -# -# -# -# -# Number of scan points. -# -# -# -# -# Number of pixel along the slowest changing dimension for a rediscretized, -# i.e. standardized default plot orientation mapping. -# -# -# -# -# Number of pixel along slow changing dimension for a rediscretized i.e. -# standardized default plot orientation mapping. -# -# -# -# -# Number of pixel along fast changing dimension for a rediscretized i.e. -# standardized default plot orientation mapping. -# -# -# -# -# Number of phase solutions -# -# -# -# -# Base class method-specific for Electron Backscatter Diffraction (EBSD). -# -# The general procedure of an EBSD experiment is as follows. -# Users load the specimen, collect first a coarse image of the surface. -# Next, they set an approximate value for the calibrated working distance and -# tilt the stage to set the desired diffraction conditions. -# -# Users then typically configure the microscope for collecting higher quality data -# and push in the EBSD detector. Subsequently, they fine tune the illumination -# and aberration corrector settings and select one or multiple ROIs for -# the microscope to machine off automatically. They configure on-the-fly -# indexing parameter and start the measurement queue. -# -# Nowadays, this is in most cases an automated process. The pattern -# collection runs during the allocated microscope session until the -# queue finishes or gets interrupted by errors or the next user terminates -# sessions which run over time. -# -# Kikuchi pattern surplus eventually multi-modal detector signals are -# collected and usually indexed on-the-fly. Patterns may be stored or not -# so one should not assume that raw data are always stored. -# -# Results are stored in files, which afterwards are typically copied -# automatically or manual for archival purposes to certain storage -# locations or further consumption. The result of such an EBSD -# measurement/experiment is a set of usually proprietary or open files -# from technology partners. -# -# This :ref:`NXem_ebsd` base class is a proposal how to represent method-specific -# data, metadata, and connections between these for the research field of -# electron microscopy. -# -# More specifically, exemplified here for electron backscatter diffraction (EBSD) -# we show how NeXus can be used to solve two key documentation issues so far -# missing in the field of EBSD. -# -# Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted -# according to NXem_ebsd) stores the connection between the microscope session and -# the key datasets which are considered typically results of the various processing -# steps involved when working with EBSD data. -# -# Different groups in NXem_ebsd make connections to data artifacts which were collected -# when working with electron microscopes via the NXem application definition. -# Using a file which stores information according to the NXem application definition -# has the benefit that it connects the sample, references to the sample processing, -# the user operating the microscope, details about the microscope session, -# and details about the acquisition and eventual indexing of Kikuchi pattern, -# associated overview images, like secondary electron or backscattered electron -# images of the region-of-interest probed and many more pieces of information. -# -# Secondly, NXem_ebsd connects and stores the conventions and reference frames -# which were used and which are the key to a correct mathematical interpretation -# of every EBSD result. Otherwise, results would be ripped out of their context, -# as it is the current situation with many traditional studies where EBSD data -# were indexed on-the-fly and shared with the community only via sharing -# the strongly processed results file in some technology-partner-specific file -# format but without communicating all conventions or relying on the assumptions -# that colleagues likely know these conventions even though multiple definitions -# are possible. -# -# NXem_ebsd covers experiments with one-, two-dimensional, and so-called three- -# dimensional EBSD datasets. The third dimension is either time (in the case of -# quasi in-situ experiments) or space (in the case of serial-sectioning) methods -# where a combination of mechanical or ion milling is used repetitively to measure -# the same region-of-interest at different depth increments. Material removal -# can be achieved with electron or ion polishing, using manual -# steps or using automated equipment like a robot system. -# -# Three-dimensional experiments require to follow a sequence of specimen, surface -# preparation, and data collection steps. By nature these methods are destructive -# in that they either require the removal of the previously measured material region -# or that the sample surface can degrade due to e.g. contamination or other -# electron-matter interaction. -# -# For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are -# combined into one reconstructed stack. That is serial-sectioning is mainly a -# computational workflow. Users collect data for each serial sectioning step -# via an experiment. This assures that data for associated microscope sessions -# and steps of data processing stay connected and contextualized. -# -# Eventual tomography methods also use such a workflow because first diffraction -# images are collected (e.g. with X-ray) and then these imagres are indexed and -# computed into a 3D orientation mapping. The here proposed NXem_ebsd application -# definition contains conceptual ideas how this splitting between measurement and -# post-processing can be granularized also for such X-ray-based techniques, whether -# it be 3DXRD or HEDM. -# -# This concept is related to term `Electron Backscatter Diffraction`_ of the EMglossary standard. -# -# .. _Electron Backscatter Diffraction: https://purls.helmholtz-metadaten.de/emg/EMG_00000019 -# -# -# -# -# Details about the gnomonic (projection) reference frame. -# -# It is assumed that the configuration is inspected by looking towards the sample surface. -# If a detector is involved, it is assumed that the configuration is inspected from a position -# that is located behind this detector. -# -# If any of these assumptions is not met, the user is required to explicitly state this. -# -# Reference DOI: 10.1016/j.matchar.2016.04.008 suggests to label the -# base vectors of this coordinate system as Xg, Yg, Zg. -# -# -# -# Origin of the gnomonic_projection_reference_frame. -# -# Reference DOI: 10.1016/j.matchar.2016.04.008 suggests to -# assume that this is coordinate Xg = 0, Yg = 0, Zg = 0. -# -# -# -# -# -# -# -# -# Direction of the positively pointing x-axis base vector of the -# gnomonic_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing y-axis base vector of the -# gnomonic_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing z-axis base vector of the -# gnomonic_reference_frame. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Details about the definition of the pattern centre as a special point in the gnomonic_reference_frame. -# -# Keep in mind that the gnomonic space is in virtually all cases embedded in the detector space. -# Specifically, the XgYg plane is defined such that it is laying inside the XdYd plane -# (of the detector reference frame). -# -# When the normalization direction is the same as e.g. the detector x-axis direction one -# effectively normalizes in fractions of the width of the detector. -# -# The issue with terms like width and height is that these degenerate if the detector -# region-of-interest is square-shaped. This is why instead of referring to width and height -# one should report as if one were to measure practically with a ruler and one is specific -# about in which direction positive distances are measured. -# -# For the concepts used to specify the boundary_convention it is assumed that the -# region-of-interest is defined by a rectangle, referring to the direction of outer-unit -# normals to the respective edges of this rectangle. -# -# -# -# From which border of the EBSP (in the detector reference frame) is the pattern -# centre's x-position (PCx) measured. -# -# -# -# -# -# -# -# -# -# -# -# In which direction are positive values for the x-axis coordinate value measured -# from the specified boundary. -# -# -# -# -# -# -# -# -# -# -# -# From which border of the EBSP (in the detector reference frame) is the pattern -# centre's y-position (PCy) measured. -# -# -# -# -# -# -# -# -# -# -# -# In which direction are positive values for the y-axis coordinate value measured -# from the specified boundary. -# -# -# -# -# -# -# -# -# -# -# -# -# -# This group documents relevant details about the conditions and the tools -# used for measuring a stack of Kikuchi diffraction pattern with an -# electron microscope. -# -# The most frequently collected EBSD data are captured for rectangular -# regions-of-interested which are sampled with regular square or -# hexagon-shaped pixels. -# -# -# -# Physical time since the beginning of a timestamp that is required to be -# same for all experiments in the set. The purpose of this marker is -# to identify how all experiments in the set need to be arranged -# sequentially based on the time elapsed. -# The time is relevant to sort e.g. experiments of consecutive quasi -# in-situ experiments where a measurement was e.g. taken after 0 minutes, -# 30 minutes, 6 hours, or 24 hours of annealing. -# -# -# -# Timestamp relative to which time was counted to aid -# converting between time and timestamp. -# -# -# -# -# -# -# If available and it is stored in an instance of an application definition this field -# specifies the path to an instance of :ref:`NXdata` where the measured patterns -# are stored. -# -# -# -# -# Reference (e.g. path and filename) to an existent data artifact which -# stores either the measured pattern or input (already processed EBSD data). -# -# -# -# -# -# This group documents relevant details about the conditions and the tools -# used for simulating a stack of Kikuchi diffraction pattern with some -# physical model. -# -# This group should not be confused with a group named simulation that -# is however an instance of NXem_sim. Instead, the simulation group here -# should be used if (e.g. instead of a measurement) a stack of pattern -# were simulated that one wishes to use for indexing patterns. -# -# In many practical cases where pattern are analyzed on-the-fly and dictionary -# indexing strategies are used, so-called master pattern(s) are used to compare -# measured or simulated pattern with the master pattern. In this case, -# master pattern are the result of a computer simulation and thus should -# be stored using an own properly documented entry within a simulation -# group as an instance of :ref:`NXem_sim`. -# -# -# -# If available and it is stored in an instance of an application definition this field specifies -# the path to an instance of :ref:`NXimage_set` where the simulated patterns are stored. -# -# -# -# -# Reference (e.g. path and filename) to an existent digital resource which -# stores either the pattern or input (already processed EBSD data) -# which is now processed further as described by this NXem_ebsd instance. -# -# -# -# -# -# The EBSD system, including components like the electron gun, pole-piece, -# stage tilting, EBSD detector, and the gnomonic projection have to be -# calibrated to achieve reliable indexing results. -# -# Specifically, the gnomonic projection has to be calibrated. -# Typically, silicon or quartz crystals are used for this purpose. -# -# Considering a system is well-calibrated, it is much more frequently the -# case in practice that users assume the system is calibrated (and thus usable) -# vs. they perform the calibration of the EBSD system. -# -# In the first case, the user assumes that the principle geometry of the -# hardware components and the settings in the control and EBSD pattern -# acquisition software has been calibrated. Consequently, users pick from -# an existent library of phase candidates, i.e. -# :ref:`NXcrystal_structure` instances. Examples are -# reflector models as stored in CRY files (HKL/Channel 5/Flamenco). -# -# In the second case, users calibrate the system during the session -# using standards (silicon, quartz, or other common specimens). -# There is usually one person in each lab responsible for doing such -# calibrations. Often this person or technician is also in charge of -# configuring the graphical user interface and software with which most -# users control and perform their analyses. -# -# For EBSD this has key implications: Taking TSL OIM/EDAX as an example, -# the conventions how orientations are stored is affected by how the -# reference frames are configured and this setup is made at the level -# of the GUI software. -# -# Unfortunately, these pieces of information are not necessarily stored -# in the results files. In effect, key conventions become disconnected -# from the data so it remains the users' obligation to remember these -# settings or write these down in a lab notebook. Otherwise, these metadata -# get lost. All these issues are a motivation and problem which -# :ref:`NXem_ebsd` solves in that all conventions can be specified explicitly. -# -# -# -# If available and it is stored in an instance of an application definition this field specifies -# the path to an instance of :ref:`NXem_msr` where calibration is stored. -# -# -# -# -# Reference to a digital resource where the calibration is stored. -# -# -# -# -# -# Indexing is a data processing step performed either after or while -# (on-the-fly) the beam scans the specimen. The resulting method is also -# known as orientation imaging microscopy (OIM). -# -# Different algorithms can be used to index EBSD pattern. Common to them -# is the computational step where simulated reference pattern are compared -# with measured or simulated patterns. These latter patterns are referred -# to via the measurement or simulation groups of this base class. -# -# Quality descriptors are defined based on which an indexing algorithm -# yields a quantitative measure of how similar measured and reference -# pattern are, and thus if no, one, or multiple so-called solutions -# were found. -# -# Assumed or simulated pattern are simulated using kinematic or dynamical -# theory of electron diffraction delivering master pattern. -# -# The Hough transform is essentially a discretized Radon transform (for details see `M. van Ginkel et al. <https://www.semanticscholar.org/paper/A-short-introduction-to-the-Radon-and-Hough-and-how-Ginkel/fb6226f606cad489a15e38ed961c419037ccc858>`_). -# Recently, dictionary-based indexing methods are increasingly becoming used -# partly driven by the interest to use artificial intelligence algorithms. -# -# -# -# This group enables to establish a logical connection between previous -# processing steps or on-the-fly-performed indexing of the EBSD map. -# Typically these processing steps are performed with commercial software. -# Therefore, in many cases a results file from this indexing is often -# all that is communicated and saved. These are typically files in a format -# specific to the instrument and its configuration. -# -# Typical file formats are CPR/CRC, ANG, OSC, HDF5, H5EBSD, EDAXH5. -# -# -# -# -# Principal algorithm used for indexing. -# -# -# -# -# -# -# -# -# -# -# -# Details about the background correction applied to each Kikuchi pattern. -# -# -# -# -# Binning i.e. downsampling of the pattern. -# -# -# -# -# Specific parameter relevant only for certain algorithms used. -# -# -# -# -# Details for each phase used as a model with which the patterns were -# indexed. Instances of :ref:`NXcrystal_structure` in this group must -# have the group name prefix phase. The identifier in the name is an -# integer. We start counting from 1 because the value 0 is reserved for -# the special phase that is the null-model, i.e. the null phase, notIndexed. -# -# -# -# -# Which return value did the indexing algorithm yield for each scan point. -# Practically useful is to use an uint8 mask. -# -# * 0 - Not analyzed -# * 1 - Too high angular deviation -# * 2 - No solution -# * 100 - Success -# * 255 - Unexpected errors -# -# -# -# -# -# -# -# How many phases i.e. crystal structure models were used to index each -# scan point if any? Let's assume an example to explain how this field -# should be used: In the simplest case users collected one pattern for -# each scan point and have indexed using one phase, i.e. one instance -# of an NXem_ebsd_crystal_structure_model. -# -# In another example users may have skipped some scan points (not indexed) -# them at all) and/or used differing numbers of phases for different scan -# points. -# -# The cumulated of this array decodes how phase_identifier and phase_matching -# arrays have to be interpreted. In the simplest case (one pattern per scan -# point, and all scan points indexed using that same single phase model), -# phase_identifier has as many entries as scan points -# and phase_matching has also as many entries as scan points. -# -# -# -# -# -# -# -# The array n_phases_per_scan_point details how the phase_identifier -# and the phase_matching arrays have to be interpreted. -# -# For the example with a single phase phase_identifier has trivial -# values either 0 (no solution) or 1 (solution matching -# sufficiently significant with the model for phase 1). -# -# When there are multiple phases, it is possible (although not frequently -# needed) that a pattern matches eventually (not equally well) sufficiently -# significant with multiple pattern. This can especially happen in cases of -# pseudosymmetry and more frequently with an improperly calibrated system -# or false or inaccurate phase models e.g. (ferrite, austenite). -# Having such field is especially relevant for recent machine learning -# or dictionary based indexing schemes because in combination with -# phase_matching these fields communicate the results in a model-agnostic -# way. -# -# Depending on the n_phases_per_scan_point value phase_identifier and -# phase_matching arrays represent a collection of concatenated tuples, -# which are organized in sequence: The solutions for the 0-th scan point, -# the 1-th scan point, the n_sc - 1 th scan point and omitting tuples -# for those scan points with no phases according to n_phases_per_scan_point -# -# -# -# -# -# -# -# One-dimensional array, pattern by pattern labelling the solutions found. -# The array n_phases_per_scan_point has to be specified because it details -# how the phase_identifier and the phase_matching arrays have to be interpreted. -# See documentation of phase_identifier for further details. -# -# -# -# -# -# -# -# Phase_matching is a descriptor for how well the solution matches or not. -# Examples can be confidence_index, mean_angular_deviation, some AI-based -# matching probability (other), i.e. the details are implementation-specific. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Calibrated center positions of each scan point -# in the sample surface reference system. -# -# -# -# -# -# -# -# -# Fraction of successfully indexed pattern with a phase -# not the null-phase vs the number_of_scan_points. -# -# -# -# -# Number of scan points in the original mapping. -# -# -# -# -# -# -# -# -# -# An overview of the entire ROI. -# -# -# -# Descriptor representing the image contrast. -# -# -# -# -# -# -# -# -# -# -# -# Title of the default plot. -# -# -# -# -# Descriptor values displaying the ROI. -# -# -# -# -# -# -# -# -# Descriptor values. -# -# -# -# -# -# Calibrated coordinate along the y-axis. -# -# -# -# -# -# -# Label for the y axis -# -# -# -# -# -# Calibrated coordinate along the x-axis. -# -# -# -# -# -# -# Label for the x axis -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml deleted file mode 100644 index c747f63122..0000000000 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ /dev/null @@ -1,390 +0,0 @@ -category: base -doc: | - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDXS). - - `IUPAC instead of Siegbahn notation `_ should be used. - - X-ray spectroscopy is a surface-sensitive technique. Therefore, three-dimensional elemental - characterzation requires typically a sequence of characterization and preparation of the - surface to expose a new surface layer that can be characterized in the next acquisition. - In effect, the resulting three-dimensional elemental information mappings are truely the - result of a correlation and post-processing of several measurements which is the field - of correlative tomographic usage of electron microscopy. - -# NEW ISSUE: use computational geometry to offer arbitrary scan pattern -# NEW ISSUE: make the binning flexible per scan point -# energy typically the fastest direction -symbols: - n_photon_energy: | - Number of X-ray photon energy (bins) - n_elements: | - Number of identified elements - n_peaks: | - Number of peaks detected - n_iupac_line_names: | - Number of IUPAC line names -type: group -NXem_eds(NXem_method): - - # NXprocess is composed from NXem_method base class instances where the spectra - # are stored as instances of (NXspectrum_set) is composed from NXem_method base class - # for post-processing of/with the above-defined data entries - # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), - # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), - # and Adrien Teutrie, Cecile Hebert (EPFL) - indexing(NXprocess): - doc: | - Details about computational steps how peaks were indexed as elements. - (NXprogram): - doc: | - The program with which the indexing was performed. - summary(NXdata): - doc: | - Accumulated intensity over all pixels of the region-of-interest. - intensity(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Accumulated counts - dimensions: - rank: 1 - dim: [[1, n_photon_energy]] - \@long_name: - type: NX_CHAR - doc: | - Counts - axis_energy(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy axis - dimensions: - rank: 1 - dim: [[1, n_photon_energy]] - \@long_name: - type: NX_CHAR - doc: | - Energy - (NXpeak): - doc: | - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - (NXion): - energy_range(NX_NUMBER): - unit: NX_ENERGY - doc: | - Associated lower :math:`[e_{min}, e_{max}]` bounds of the - energy which is assumed associated with this peak. - dimensions: - rank: 1 - dim: [[1, 2]] - energy(NX_NUMBER): - unit: NX_ENERGY - doc: | - Theoretical energy of the line according to IUPAC. - iupac_line_names(NX_CHAR): - doc: | - IUPAC notation identifier of the line which the peak represents. - - This can be a list of IUPAC notations for (the seldom) case that - multiple lines are grouped with the same peak. - dimensions: - rank: 1 - dim: [[1, n_iupac_line_names]] - atom_types(NX_CHAR): - doc: | - Comma-separated list of names of elements confirmed in the sample via EDS analysis. - - All members of the list have to be valid chemical_symbols from the periodic table. - - This field can be used when creating instances of NXpeak is not desired. - However, a collection of instances of NXpeak with individual NXion specified - enables also to distinguish isotopic information. - dimensions: - rank: 1 - dim: [[1, n_elements]] - - # often the details of implemented background models and ZAF corrections are - # implemented and processed using proprietary software, in that case it can be - # the proprietary file formats typically have this information not documented completely - # for the example of EDAX, APEX software e.g. one finds EDS maps with just human-editable - # labels such as InL or P K or In P Mn i.e. combinations of signals from multiple ROIs - # but even a label InL is not physically not meaning ful enough, only with the knowledge - # that in an SEM and using an EDS detector, i.e. not a monochromating unit the energy - # resolution is not sufficient to resolve specific signals like e.g. separate certain lines - # therefore we use for now the - (NXimage_set): - doc: | - Individual element-specific EDS/EDX/EDXS/SXES mapping - - A composition map is an image whose intensities for each pixel are the - accumulated X-ray quanta *under the curve(s)* of a set of peaks. - - These element-specific EDS maps are :ref:`NXimage_set` instances - and need to be named with the name of the element from the - atom_types field. - - We often observe that signal contributions from several peaks - are summarized and shown together, e.g. the combined signal - under the curve of carbon and oxygen. - - In this case specify the processing details using peaks and weights. - description(NX_CHAR): - doc: | - Discouraged free-text field to add additional information. - iupac_line_candidates(NX_CHAR): - doc: | - Comma-separated list of chemical_symbol-IUPAC X-ray (emission) line name that - documents which elements and their specific lines are theoretically located within - the energy_range of the spectrum from which the EDS (element) map has been computed. - energy_range(NX_NUMBER): - unit: NX_ENERGY - doc: | - Associated :math:`[e_{min}, e_{max}]` bounds of the energy - range for which spectrum counts have been accumulated. - dimensions: - rank: 1 - dim: [[1, 2]] - (NXprocess): - peaks(NX_CHAR): - doc: | - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - dimensions: - rank: 1 - dim: [[1, n_peaks]] - weights(NX_NUMBER): - unit: NX_UNITLESS - doc: | - A list of weights by how much the intensity of each peak - under peaks was factorized to display the joint intensity - of the image. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a2f0e624072e3af9809088c533b6c420843c7c34a4d34dfa4d184b1f3eff1d52 -# -# -# -# -# -# -# -# -# Number of X-ray photon energy (bins) -# -# -# -# -# Number of identified elements -# -# -# -# -# Number of peaks detected -# -# -# -# -# Number of IUPAC line names -# -# -# -# -# Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDXS). -# -# `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. -# -# X-ray spectroscopy is a surface-sensitive technique. Therefore, three-dimensional elemental -# characterzation requires typically a sequence of characterization and preparation of the -# surface to expose a new surface layer that can be characterized in the next acquisition. -# In effect, the resulting three-dimensional elemental information mappings are truely the -# result of a correlation and post-processing of several measurements which is the field -# of correlative tomographic usage of electron microscopy. -# -# -# -# -# Details about computational steps how peaks were indexed as elements. -# -# -# -# The program with which the indexing was performed. -# -# -# -# -# Accumulated intensity over all pixels of the region-of-interest. -# -# -# -# Accumulated counts -# -# -# -# -# -# -# Counts -# -# -# -# -# -# Energy axis -# -# -# -# -# -# -# Energy -# -# -# -# -# -# -# Name and location of each X-ray line which was indexed as a known ion. -# For each ion, an NXion instance should be created which specifies -# the origin of the signal. For each ion also the relevant IUPAC notation -# X-ray lines should be specified. -# -# -# -# -# Associated lower :math:`[e_{min}, e_{max}]` bounds of the -# energy which is assumed associated with this peak. -# -# -# -# -# -# -# -# Theoretical energy of the line according to IUPAC. -# -# -# -# -# IUPAC notation identifier of the line which the peak represents. -# -# This can be a list of IUPAC notations for (the seldom) case that -# multiple lines are grouped with the same peak. -# -# -# -# -# -# -# -# -# -# Comma-separated list of names of elements confirmed in the sample via EDS analysis. -# -# All members of the list have to be valid chemical_symbols from the periodic table. -# -# This field can be used when creating instances of NXpeak is not desired. -# However, a collection of instances of NXpeak with individual NXion specified -# enables also to distinguish isotopic information. -# -# -# -# -# -# -# -# -# Individual element-specific EDS/EDX/EDXS/SXES mapping -# -# A composition map is an image whose intensities for each pixel are the -# accumulated X-ray quanta *under the curve(s)* of a set of peaks. -# -# These element-specific EDS maps are :ref:`NXimage_set` instances -# and need to be named with the name of the element from the -# atom_types field. -# -# We often observe that signal contributions from several peaks -# are summarized and shown together, e.g. the combined signal -# under the curve of carbon and oxygen. -# -# In this case specify the processing details using peaks and weights. -# -# -# -# Discouraged free-text field to add additional information. -# -# -# -# -# Comma-separated list of chemical_symbol-IUPAC X-ray (emission) line name that -# documents which elements and their specific lines are theoretically located within -# the energy_range of the spectrum from which the EDS (element) map has been computed. -# -# -# -# -# Associated :math:`[e_{min}, e_{max}]` bounds of the energy -# range for which spectrum counts have been accumulated. -# -# -# -# -# -# -# -# -# A list of NXpeak instance names whose X-ray quanta -# where accumulated for each pixel which yields an element-specific -# EDS map. -# -# -# -# -# -# -# -# A list of weights by how much the intensity of each peak -# under peaks was factorized to display the joint intensity -# of the image. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml deleted file mode 100644 index 7eebed3c55..0000000000 --- a/contributed_definitions/nyaml/NXem_eels.yaml +++ /dev/null @@ -1,95 +0,0 @@ -category: base -doc: | - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). - -# symbols: -# n_energy_loss: Number of electron energy loss bins. -type: group -NXem_eels(NXem_method): - - # NXem_method also has an NXprocess which in this base class can be - # specialized to include EELS-specific post-processing - zlp_correction(NXprocess): - doc: | - Details about computational stesp how the zero-loss peak was threaded. - (NXprogram): - doc: | - The program with which the zero-loss peak correction was performed. - indexing(NXprocess): - doc: | - Details about computational steps how peaks were indexed as elements. - (NXprogram): - doc: | - The program with which the indexing was performed. - (NXpeak): - doc: | - Name and location of each peak in the spectrum considered to be of relevance. - (NXspectrum_set): - doc: | - NXspectrum_set_em specialized for EELS. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 407770508c979ffc5bf643138ca130ccfd5e1211d79825d9a1925b7e70bbcb12 -# -# -# -# -# -# -# Base class method-specific for Electron Energy Loss Spectroscopy (EELS). -# -# -# -# -# Details about computational stesp how the zero-loss peak was threaded. -# -# -# -# The program with which the zero-loss peak correction was performed. -# -# -# -# -# -# Details about computational steps how peaks were indexed as elements. -# -# -# -# The program with which the indexing was performed. -# -# -# -# -# Name and location of each peak in the spectrum considered to be of relevance. -# -# -# -# -# NXspectrum_set_em specialized for EELS. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml deleted file mode 100644 index 08d43800e1..0000000000 --- a/contributed_definitions/nyaml/NXem_img.yaml +++ /dev/null @@ -1,28 +0,0 @@ -category: base -doc: | - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). Examples can be single point aka spot - measurements, line profiles, or (rectangular) surface mappings. - The latter pattern is the most frequently used. - - For now the base class provides for scans for which the settings, - binning, and energy resolution is the same for each scan point. -type: group -NXem_img(NXem_method): - imaging_mode(NX_CHAR): - doc: | - Which imaging mode was used? - enumeration: [secondary_electron, backscattered_electron, annular_dark_field, cathodoluminescence] - (NXimage_set): - half_angle_interval(NX_NUMBER): - unit: NX_ANGLE - doc: | - Annulus inner (first value) and outer (second value) half angle. - unit: NX_ANGLE - dim: (2,) - # (NXmicrostructure): - # doc: | - # A reconstruction of the microstructure or some of its features - # based on image information in the parent class. diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml deleted file mode 100644 index 8fd23cde4a..0000000000 --- a/contributed_definitions/nyaml/NXem_method.yaml +++ /dev/null @@ -1,69 +0,0 @@ -category: base -doc: | - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for - each method e.g. :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. -type: group -NXem_method(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - (NXimage_set): - (NXspectrum_set): - - # add links to relevant data - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 34e8f17377c058eb94a193c981704a91b98da049158a76b976a07d534b2e69b2 -# -# -# -# -# -# Base class to describe specific analysis methods in electron microscopy. -# -# This base class represent a template how specialized, deep, and method-specific -# base classes can be defined with which an (NXem) application -# definition gets equipped with specific groups to document method-specific -# processing steps and report analyzed quantities. -# -# The template base class name :ref:`NXem_method` needs to be changed for -# each method e.g. :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. -# -# -# -# Details about processing steps. -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml deleted file mode 100644 index 3a619f721b..0000000000 --- a/contributed_definitions/nyaml/NXem_msr.yaml +++ /dev/null @@ -1,169 +0,0 @@ -category: base -doc: | - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. -type: group -NXem_msr(NXem_method): - em_lab(NXinstrument): - doc: | - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - instrument_name(NX_CHAR): - doc: | - Given name of the microscope at the hosting institution. - This is an alias. Examples could be NionHermes, Titan, JEOL, - Gemini, etc. - location(NX_CHAR): - doc: | - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - (NXfabrication): - (NXchamber): - (NXebeam_column): - (NXibeam_column): - (NXoptical_system_em): - - # storing these data should happen in event_data, i.e. dynamic quantities - (NXscanbox_em): - (NXdetector): - doc: | - Description of the type of the detector. - - Electron microscopes have typically multiple detectors. - Different technologies are in use like CCD, scintillator, - direct electron, CMOS, or image plate to name but a few. - local_name(NX_CHAR): - doc: | - Instrument-specific alias/name - - # it is unfortunate that for NXdetector there are already many places - # how one can specify details which could equally end up in fabrications - # we should give better guidance which option to use, pr to niac - # (NXfabrication): - (NXpump): - (NXstage_lab): - (NXevent_data_em_set): - - # (NXevent_data_em): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2cb15b12d7f28560bff7adb283bef98bb6cb829ca6ddd4a14bdbe529caade514 -# -# -# -# -# -# Base class for collecting a session with a real electron microscope. -# -# For collecting data and experiments which are simulations of an -# electron microscope use the :ref:`NXem_sim` base class. -# -# -# -# (Meta)data of the microscope and the lab in which it stands. -# -# This em_lab group differs from potential em_lab groups inside -# :ref:`NXevent_data_em` instances in that here the more static descriptions -# are kept while changing, i.e. time-dependent pieces of information are -# logged, via the em_lab group inside the desired number of instances -# of NXevent_data_em. -# -# While using an :ref:`NXevent_data_em` instance, users should store only those -# settings about a component which are relevant to understand the current -# state of the component. Here, current means for the time interval which -# the event covers (as it is detailed via start_time and end_time) timestamps. -# -# For example it is not relevant to store in each :ref:`NXevent_data_em` -# electron_source group again the details of the gun type and the manufacturer -# but only the high-voltage value and that only if it is different from the value -# that is specified in the em_lab section for the static settings. -# -# In effect, this defines an information inference hierarchy which starts -# in an individual :ref:`NXevent_data_em` instance followed by a probing of the -# static section. -# -# -# -# Given name of the microscope at the hosting institution. -# This is an alias. Examples could be NionHermes, Titan, JEOL, -# Gemini, etc. -# -# -# -# -# Location of the lab or place where the instrument is installed. -# Using GEOREF is preferred. -# -# -# -# -# -# -# -# -# -# -# -# Description of the type of the detector. -# -# Electron microscopes have typically multiple detectors. -# Different technologies are in use like CCD, scintillator, -# direct electron, CMOS, or image plate to name but a few. -# -# -# -# Instrument-specific alias/name -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml deleted file mode 100644 index 330227e350..0000000000 --- a/contributed_definitions/nyaml/NXem_sim.yaml +++ /dev/null @@ -1,97 +0,0 @@ -category: base -doc: | - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. - -# abTEM and other simulation packages, TEMgym, etc. -type: group -NXem_sim(NXem_method): - simulation(NXprocess): - doc: | - Details about the simulation. - - # sequence_index(N): - (NXprogram): - (NXcg_geodesic_mesh): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 3cee64d6c22fcb7e2ca0d790a078d7ca1616990b0061b19437bb0dec55767eb6 -# -# -# -# -# -# -# Base class for simulating electron microscopy relevant beam-matter interaction. -# -# The concept behind this base class is to keep it as generic as possible -# that simulations of electron/ion beam interaction with matter can be -# represented. This base class is envisioned as the twin of the :ref:`NXem_msr` -# base class. -# -# It is an attempt to test the idea if at some point one might even use the -# same base class template to describe measurements and computer simulations -# of electron microscopy. This idea is attractive because the only practical -# difference between a description of a measurement with a microscope and a -# computer simulation is that the latter is typically a substantially simplified -# representation of the real microscope surplus the focus of the research -# in such cases on specific questions. -# -# Such simplification can be with respect to the optical setup, typically the -# ignoring of the fact that the electron beam is produced by a complex setup -# of lenses while in simulations often single Einzel lenses are considered. -# Dynamics of the environment like temperature fluctuation in a lab, vibrations, -# users, and multiple detectors are typically either ignored or reduced in -# complexity and number and coming with idealizations to keep the simulations -# focused on the specific reason questions and efficiently numerically executable. -# -# -# -# Details about the simulation. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXenergydispersion.yaml b/contributed_definitions/nyaml/NXenergydispersion.yaml deleted file mode 100644 index c46424fd04..0000000000 --- a/contributed_definitions/nyaml/NXenergydispersion.yaml +++ /dev/null @@ -1,369 +0,0 @@ -category: base -doc: | - Subclass of NXelectronanalyser to describe the energy dispersion section of a - photoelectron analyser. -type: group -NXenergydispersion(NXobject): - scheme(NX_CHAR): - doc: | - Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, - mirror, retarding grid, etc. - pass_energy(NX_FLOAT): - unit: NX_ENERGY - doc: - - | - Mean kinetic energy of the electrons in the energy-dispersive portion of the analyser. - This term should be used for hemispherical analysers. - - | - xref: - spec: ISO 18115-1:2023 - term: 12.63 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.63 - kinetic_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - Kinetic energy set for the dispersive analyzer section. Can be either the set kinetic energy, - or the whole calibrated energy axis of a scan. - drift_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - Drift energy for time-of-flight energy dispersive elements. - center_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - Center of the energy window - energy_interval(NX_FLOAT): - unit: NX_ENERGY - doc: | - The interval of transmitted energies. It can be two different things depending - on whether the scan is fixed or swept. With a fixed scan it is a 2 vector - containing the extrema of the transmitted energy window (smaller number first). - With a swept scan of m steps it is a 2xm array of windows one for each - measurement point. - diameter(NX_FLOAT): - unit: NX_LENGTH - doc: | - Diameter of the dispersive orbit - radius(NX_FLOAT): - unit: NX_LENGTH - doc: | - Radius of the dispersive orbit - energy_scan_mode(NX_CHAR): - doc: | - Way of scanning the energy axis - enumeration: - fixed_analyser_transmission: - doc: - - | - constant :math:`\Delta E` mode, where the electron retardation (i.e., the fraction of pass energy to - kinetic energy, :math:`R = (E_K - W/E_p)`, is scanned, but the pass energy :math:`E_p` is kept constant. - Here, :math:`W = e \phi` is the spectrometer work function (with the potential difference :math:`\phi_{\mathrm{sample}}` - between the electrochemical potential of electrons in the bulk and the electrostatic potential of an electron in the - vacuum just outside the surface). - - | - This mode is often used in XPS/UPS because the energy resolution does not change with - changing energy (due to the constant pass energy). - - | - Synonyms: constant :math:`\Delta E` mode, constant analyser energy mode, CAE - mode, FAT mode - - | - xref: - spec: ISO 18115-1:2023 - term: 12.64 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.64 - fixed_retardation_ratio: - doc: - - | - constant :math:`\Delta E/E` mode, where the pass energy is scanned such that the electron retardation - ratio is constant. In this mode, electrons of all energies are decelerated with this same - fixed factor. Thus, the pass energy is proportional to the kinetic energy. This mode is often - used in Auger electron spectroscopy (AES) to improve S/N for high-KE electrons, but this - leads to a changing energy resolution (:math:`\Delta E \sim E_p`) at different kinetic energies. - It can however also be used in XPS. - - | - Synonyms: constant :math:`\Delta E/E` mode, constant retardation ratio mode, CRR - mode, FRR mode - - | - xref: - spec: ISO 18115-1:2023 - term: 12.66 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.66 - fixed_energy: - doc: | - In the fixed energy (FE) mode, the intensity for one single kinetic energy is measured for a - specified time. This mode is particulary useful during setup or alignment of the - electron analyzer, for analysis of stability of the excitation source or for sample - alignment. - - Since the mode measures intensity as a function of time, the difference in channel signals - is not of interest. Therefore, the signals from all channels are summed. - - Synonyms: FE mode - snapshot: - doc: | - Snapshot mode does not involve an energy scan and instead collects data from all channels of - the detector without averaging. The resulting spectrum reflects the energy distribution of - particles passing through the analyzer using the current settings. This mode is commonly used - to position the detection energy at the peak of a peak and record the signal, enabling faster - data acquisition within a limited energy range compared to FAT. Snapshot measurements are - particularly suitable for CCD and DLD detectors, which have multiple channels and can accurately - display the peak shape. While five or nine-channel detectors can also be used for snapshot - measurements, their energy resolution is relatively lower. - dither: - doc: | - In dither acquisition mode, the kinetic energy of the analyzer is randomly varied by a small value - around a central value and at fixed pass energy. This allows reducing or removing inhomogeneities - of the detector efficiency, such as e.g. imposed by a mesh in front of the detector. - Mostly relevant for CCD/DLD type of detectors. - tof_distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Length of the tof drift electrode - (NXaperture): - doc: | - Size, position and shape of a slit in dispersive analyzer, e.g. entrance and - exit slits. - (NXdeflector): - doc: | - Deflectors in the energy dispersive section - (NXlens_em): - doc: | - Individual lenses in the energy dispersive section - (NXfabrication): - depends_on(NX_CHAR): - doc: | - Specifies the position of the energy dispesive elemeent by pointing to the last - transformation in the transformation chain in the NXtransformations group. - (NXtransformations): - doc: | - Collection of axis-based translations and rotations to describe the location and - geometry of the energy dispersive element as a component in the instrument. - Conventions from the NXtransformations base class are used. In principle, - the McStas coordinate system is used. The first transformation has to point - either to another component of the system or . (for pointing to the reference frame) - to relate it relative to the experimental setup. Typically, the components of a system - should all be related relative to each other and only one component should relate to - the reference coordinate system. - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 452a3427a6f6f009c7bab95daa4446fc74167c9d4ef6aad50811eee8e5c41ea5 -# -# -# -# -# -# Subclass of NXelectronanalyser to describe the energy dispersion section of a -# photoelectron analyser. -# -# -# -# Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, -# mirror, retarding grid, etc. -# -# -# -# -# Mean kinetic energy of the electrons in the energy-dispersive portion of the analyser. -# This term should be used for hemispherical analysers. -# -# This concept is related to term `12.63`_ of the ISO 18115-1:2023 standard. -# -# .. _12.63: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.63 -# -# -# -# -# Kinetic energy set for the dispersive analyzer section. Can be either the set kinetic energy, -# or the whole calibrated energy axis of a scan. -# -# -# -# -# Drift energy for time-of-flight energy dispersive elements. -# -# -# -# -# Center of the energy window -# -# -# -# -# The interval of transmitted energies. It can be two different things depending -# on whether the scan is fixed or swept. With a fixed scan it is a 2 vector -# containing the extrema of the transmitted energy window (smaller number first). -# With a swept scan of m steps it is a 2xm array of windows one for each -# measurement point. -# -# -# -# -# Diameter of the dispersive orbit -# -# -# -# -# Radius of the dispersive orbit -# -# -# -# -# Way of scanning the energy axis -# -# -# -# -# constant :math:`\Delta E` mode, where the electron retardation (i.e., the fraction of pass energy to -# kinetic energy, :math:`R = (E_K - W/E_p)`, is scanned, but the pass energy :math:`E_p` is kept constant. -# Here, :math:`W = e \phi` is the spectrometer work function (with the potential difference :math:`\phi_{\mathrm{sample}}` -# between the electrochemical potential of electrons in the bulk and the electrostatic potential of an electron in the -# vacuum just outside the surface). -# -# This mode is often used in XPS/UPS because the energy resolution does not change with -# changing energy (due to the constant pass energy). -# -# Synonyms: constant :math:`\Delta E` mode, constant analyser energy mode, CAE -# mode, FAT mode -# -# This concept is related to term `12.64`_ of the ISO 18115-1:2023 standard. -# -# .. _12.64: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.64 -# -# -# -# -# constant :math:`\Delta E/E` mode, where the pass energy is scanned such that the electron retardation -# ratio is constant. In this mode, electrons of all energies are decelerated with this same -# fixed factor. Thus, the pass energy is proportional to the kinetic energy. This mode is often -# used in Auger electron spectroscopy (AES) to improve S/N for high-KE electrons, but this -# leads to a changing energy resolution (:math:`\Delta E \sim E_p`) at different kinetic energies. -# It can however also be used in XPS. -# -# Synonyms: constant :math:`\Delta E/E` mode, constant retardation ratio mode, CRR -# mode, FRR mode -# -# This concept is related to term `12.66`_ of the ISO 18115-1:2023 standard. -# -# .. _12.66: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.66 -# -# -# -# -# In the fixed energy (FE) mode, the intensity for one single kinetic energy is measured for a -# specified time. This mode is particulary useful during setup or alignment of the -# electron analyzer, for analysis of stability of the excitation source or for sample -# alignment. -# -# Since the mode measures intensity as a function of time, the difference in channel signals -# is not of interest. Therefore, the signals from all channels are summed. -# -# Synonyms: FE mode -# -# -# -# -# Snapshot mode does not involve an energy scan and instead collects data from all channels of -# the detector without averaging. The resulting spectrum reflects the energy distribution of -# particles passing through the analyzer using the current settings. This mode is commonly used -# to position the detection energy at the peak of a peak and record the signal, enabling faster -# data acquisition within a limited energy range compared to FAT. Snapshot measurements are -# particularly suitable for CCD and DLD detectors, which have multiple channels and can accurately -# display the peak shape. While five or nine-channel detectors can also be used for snapshot -# measurements, their energy resolution is relatively lower. -# -# -# -# -# In dither acquisition mode, the kinetic energy of the analyzer is randomly varied by a small value -# around a central value and at fixed pass energy. This allows reducing or removing inhomogeneities -# of the detector efficiency, such as e.g. imposed by a mesh in front of the detector. -# Mostly relevant for CCD/DLD type of detectors. -# -# -# -# -# -# -# Length of the tof drift electrode -# -# -# -# -# Size, position and shape of a slit in dispersive analyzer, e.g. entrance and -# exit slits. -# -# -# -# -# Deflectors in the energy dispersive section -# -# -# -# -# Individual lenses in the energy dispersive section -# -# -# -# -# -# Specifies the position of the energy dispesive elemeent by pointing to the last -# transformation in the transformation chain in the NXtransformations group. -# -# -# -# -# Collection of axis-based translations and rotations to describe the location and -# geometry of the energy dispersive element as a component in the instrument. -# Conventions from the NXtransformations base class are used. In principle, -# the McStas coordinate system is used. The first transformation has to point -# either to another component of the system or . (for pointing to the reference frame) -# to relate it relative to the experimental setup. Typically, the components of a system -# should all be related relative to each other and only one component should relate to -# the reference coordinate system. -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# diff --git a/contributed_definitions/nyaml/NXevent_data_apm.yaml b/contributed_definitions/nyaml/NXevent_data_apm.yaml deleted file mode 100644 index a68bc87cdb..0000000000 --- a/contributed_definitions/nyaml/NXevent_data_apm.yaml +++ /dev/null @@ -1,510 +0,0 @@ -category: base -doc: | - Base class to store state and (meta)data of events over the course of an atom probe experiment. - - This base class applies the concept of the :ref:`NXevent_data_em` base class to the specific needs - of atom probe research. Against static and dynamic quantities are splitted to avoid a duplication - of information. Specifically, the time interval considered is the entire time - starting at start_time until end_time during which we assume the pulser triggered named pulses. - These pulses are identified via the pulse_identifier field. The point in time when each was issued - is specified via the combination of start_time and delta_time. - - Conceptually and technically NeXus currently stores tensorial information as arrays of values - (with each value of the same datatype). For instance, a field temperature(NX_FLOAT) stores - a set of temperature values but that field when used somewhere is a concept. However, that - concept has no information at which point in time these temperatures were taken. - An existent functional relationship between the two concepts is not defined. - - However, a correct interpretation of the temperature values demands knowledge about what is - the independent quantity on which temperature depends on or according to which frequency - temperature values were sampled. - In NeXus there are two approaches which cope with such correlations: - One is :ref:`NXdata` where the attribute signal specifies the correlation. - The other one is :ref:`NXlog` which, like NXdata, demands to granularize logged_against - (dependent signal) and independent quantities into an own group. - In many cases this additional grouping is not desired though. - - One naive solution typically employed is then to store the independent variable values via a second - vector e.g. time_stamp with the same number of entries (with dimensionality defined through symbols). - However, there is no independent logical connection between these two concepts, i.e. temperature - and time_stamp. - - In the case of atom probe though the time that one would use in NXlog is defined implicitly via pulse_identifier, - which is the independent variable vector against which eventually dozens of channels of data are logged. - Not only are these channels logged they should ideally also be self-descriptive in that these channels have - pulse_identifier as the independent variable but we do not wish to duplicate this information all the time but - reference it. - - Therefore, we here explore the use of an attribute with symbol logged_against. Maybe it is better to use the - symbol depends_on but this is easily to be confused with depends_on that is used for instances of - :ref:`NXtransformations`. Consequently, if depends_on were to be used extra logic is needed by consuming - applications to understand that the here build correlations are conceptually different ones. - - This issue should be discussed further by the NeXus community. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - p: | - Number of pulses collected in between start_time and end_time. -type: group -NXevent_data_apm(NXobject): - start_time(NX_DATE_TIME): - doc: | - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval started. If the user wishes to specify an - interval of time that the snapshot should represent during which the instrument - was stable and configured using specific settings and calibrations, - the start_time is the start (left bound of the time interval) while - the end_time specifies the end (right bound) of the time interval. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval ended. - delta_time(NX_NUMBER): - unit: NX_TIME - doc: | - Delta time array which resolves for each pulse_identifier the time difference - between when that pulse was issued and start_time. - - In summary, using start_time, end_time, delta_time, pulse_identifier_offset, - and pulse_identifier exactly specifies the connection between when a pulse was - issued relative to start and absolute in UTC. - dimensions: - rank: 1 - dim: [[1, p]] - pulse_identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer used to name the first pulse to know if there is an - offset of the identifiers to zero. - - Identifiers can be defined either implicitly or explicitly. - For implicit indexing identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. - - Therefore, implicit identifier are completely defined by the value of - identifier_offset and cardinality. For example if identifier run from - -2 to 3 the value for identifier_offset is -2. - - For explicit indexing the field identifier has to be used. - Fortran-/Matlab- and C-/Python-style indexing have specific implicit - identifier conventions where identifier_offset is 1 and 0 respectively. - pulse_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Identifier that contextualizes how the detector and pulser of an atom probe - instrument follows a sequence of pulses to trigger field evaporation. - - The pulse_identifier is used to associate thus an information about time - when the quantities documented in this NXpulser_apm base class have been - collected via sampling. - - In virtually all cases the pulser is a blackbox. Depending on how the - instrument is configured during a measurement the target - values and thus also the actual values may change. - - Maybe the first part of the experiment is run at a certain pulse fraction but thereafter - the pulse_fraction is changed. In this case the field pulse_fraction is a vector which - collects all measured values of the pulse_fraction, pulse_identifier is then an equally - long vector which stores the set of events (e.g. pulsing events) when that value was - measured. - - This may cause several situations: In the case that e.g. the pulse_fraction is never changed - and also exact details not interesting, one stores the set value for the pulse_fraction - and a single value for the pulse_identifier e.g. 0 to indicate that the pulse_fraction was set - at the beginning and it was maintained constant during the measurement. - If the pulse_fraction was maybe changed after the 100000th pulse, pulse_fraction is a - vector with two values one for the first and another one for the value from the 100000-th - pulse onwards. The values of pulse_identifier are then [0, 99999] respectively. - dimensions: - rank: 1 - dim: [[1, p]] - instrument(NXinstrument): - doc: | - (Meta)data of the dynamics and changes of the microscope over the course of - pulsing. - control(NXcollection): - doc: | - Relevant quantities during a measurement with a LEAP system as suggested by - `T. Blum et al. `_. - evaporation_control(NX_CHAR): - enumeration: [detection_rate] - target_detection_rate(NX_FLOAT): - unit: NX_ANY - (NXreflectron): - local_electrode(NXlens_em): - ion_detector(NXdetector): - signal_amplitude(NX_FLOAT): - unit: NX_CURRENT - doc: | - Amplitude of the signal detected on the multi-channel plate (MCP). - - This field should be used for storing the signal amplitude quantity - within ATO files. The ATO file format is used primarily by the - atom probe groups of the GPM in Rouen, France. - dimensions: - rank: 1 - dim: [[1, p]] - - # does p only specific the length or does it also convey a logical correlation - # conceptually to another vector which happens to have the same dimensions - # I clear say NO ! - pulser(NXpulser_apm): - stage_lab(NXstage_lab): - setpoint_temperature(NX_FLOAT): - unit: NX_TEMPERATURE - doc: | - Set point temperature to achieve during the measurement. - base_temperature(NX_FLOAT): - unit: NX_TEMPERATURE - doc: | - Average temperature (at the specimen base) during the measurement. - - # normally one would use NXsensor/NXlog but point is that the temperature - # is logged against the pulse_identifier as even in the proprietary file format from - # AMETEK/Cameca nowhere there is the actual time when the pulse was triggered - # just the sampling frequency and I guess but am not 100percent sure which quantity - # from Cameca this is also the time when the first pulse was triggered - # using NXlog does make sense when individual NXsensors have different timing - # but for atom probe if at all the pulse-based implicit time is available - temperature(NX_FLOAT): - unit: NX_TEMPERATURE - 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). - dimensions: - rank: 1 - dim: [[1, p]] - \@logged_against: - type: NX_CHAR - doc: | - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - analysis_chamber(NXchamber): - chamber_pressure(NX_FLOAT): - unit: NX_PRESSURE - doc: | - Average pressure in the analysis chamber during the measurement. - pressure(NX_FLOAT): - unit: NX_PRESSURE - doc: | - Pressure in the analysis chamber. - dimensions: - rank: 1 - dim: [[1, p]] - \@logged_against: - type: NX_CHAR - doc: | - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - buffer_chamber(NXchamber): - pressure(NX_FLOAT): - unit: NX_PRESSURE - doc: | - Pressure in the analysis chamber. - dimensions: - rank: 1 - dim: [[1, p]] - \@logged_against: - type: NX_CHAR - doc: | - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - load_lock_chamber(NXchamber): - pressure(NX_FLOAT): - unit: NX_PRESSURE - doc: | - Pressure in the analysis chamber. - dimensions: - rank: 1 - dim: [[1, p]] - \@logged_against: - type: NX_CHAR - doc: | - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - - # getter_pump(NXpump): - # roughening_pump(NXpump): - # turbomolecular_pump(NXpump): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f48e7979b04cec84716a871e1372a642d3d537c462dd27dc7f29c624c164e096 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of pulses collected in between start_time and end_time. -# -# -# -# -# Base class to store state and (meta)data of events over the course of an atom probe experiment. -# -# This base class applies the concept of the :ref:`NXevent_data_em` base class to the specific needs -# of atom probe research. Against static and dynamic quantities are splitted to avoid a duplication -# of information. Specifically, the time interval considered is the entire time -# starting at start_time until end_time during which we assume the pulser triggered named pulses. -# These pulses are identified via the pulse_identifier field. The point in time when each was issued -# is specified via the combination of start_time and delta_time. -# -# Conceptually and technically NeXus currently stores tensorial information as arrays of values -# (with each value of the same datatype). For instance, a field temperature(NX_FLOAT) stores -# a set of temperature values but that field when used somewhere is a concept. However, that -# concept has no information at which point in time these temperatures were taken. -# An existent functional relationship between the two concepts is not defined. -# -# However, a correct interpretation of the temperature values demands knowledge about what is -# the independent quantity on which temperature depends on or according to which frequency -# temperature values were sampled. -# In NeXus there are two approaches which cope with such correlations: -# One is :ref:`NXdata` where the attribute signal specifies the correlation. -# The other one is :ref:`NXlog` which, like NXdata, demands to granularize logged_against -# (dependent signal) and independent quantities into an own group. -# In many cases this additional grouping is not desired though. -# -# One naive solution typically employed is then to store the independent variable values via a second -# vector e.g. time_stamp with the same number of entries (with dimensionality defined through symbols). -# However, there is no independent logical connection between these two concepts, i.e. temperature -# and time_stamp. -# -# In the case of atom probe though the time that one would use in NXlog is defined implicitly via pulse_identifier, -# which is the independent variable vector against which eventually dozens of channels of data are logged. -# Not only are these channels logged they should ideally also be self-descriptive in that these channels have -# pulse_identifier as the independent variable but we do not wish to duplicate this information all the time but -# reference it. -# -# Therefore, we here explore the use of an attribute with symbol logged_against. Maybe it is better to use the -# symbol depends_on but this is easily to be confused with depends_on that is used for instances of -# :ref:`NXtransformations`. Consequently, if depends_on were to be used extra logic is needed by consuming -# applications to understand that the here build correlations are conceptually different ones. -# -# This issue should be discussed further by the NeXus community. -# -# -# -# ISO 8601 time code with local time zone offset to UTC information included -# when the snapshot time interval started. If the user wishes to specify an -# interval of time that the snapshot should represent during which the instrument -# was stable and configured using specific settings and calibrations, -# the start_time is the start (left bound of the time interval) while -# the end_time specifies the end (right bound) of the time interval. -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC information included -# when the snapshot time interval ended. -# -# -# -# -# Delta time array which resolves for each pulse_identifier the time difference -# between when that pulse was issued and start_time. -# -# In summary, using start_time, end_time, delta_time, pulse_identifier_offset, -# and pulse_identifier exactly specifies the connection between when a pulse was -# issued relative to start and absolute in UTC. -# -# -# -# -# -# -# -# Integer used to name the first pulse to know if there is an -# offset of the identifiers to zero. -# -# Identifiers can be defined either implicitly or explicitly. -# For implicit indexing identifiers are defined on the interval -# :math:`[identifier\_offset, identifier\_offset + c - 1]`. -# -# Therefore, implicit identifier are completely defined by the value of -# identifier_offset and cardinality. For example if identifier run from -# -2 to 3 the value for identifier_offset is -2. -# -# For explicit indexing the field identifier has to be used. -# Fortran-/Matlab- and C-/Python-style indexing have specific implicit -# identifier conventions where identifier_offset is 1 and 0 respectively. -# -# -# -# -# Identifier that contextualizes how the detector and pulser of an atom probe -# instrument follows a sequence of pulses to trigger field evaporation. -# -# The pulse_identifier is used to associate thus an information about time -# when the quantities documented in this NXpulser_apm base class have been -# collected via sampling. -# -# In virtually all cases the pulser is a blackbox. Depending on how the -# instrument is configured during a measurement the target -# values and thus also the actual values may change. -# -# Maybe the first part of the experiment is run at a certain pulse fraction but thereafter -# the pulse_fraction is changed. In this case the field pulse_fraction is a vector which -# collects all measured values of the pulse_fraction, pulse_identifier is then an equally -# long vector which stores the set of events (e.g. pulsing events) when that value was -# measured. -# -# This may cause several situations: In the case that e.g. the pulse_fraction is never changed -# and also exact details not interesting, one stores the set value for the pulse_fraction -# and a single value for the pulse_identifier e.g. 0 to indicate that the pulse_fraction was set -# at the beginning and it was maintained constant during the measurement. -# If the pulse_fraction was maybe changed after the 100000th pulse, pulse_fraction is a -# vector with two values one for the first and another one for the value from the 100000-th -# pulse onwards. The values of pulse_identifier are then [0, 99999] respectively. -# -# -# -# -# -# -# -# (Meta)data of the dynamics and changes of the microscope over the course of -# pulsing. -# -# -# -# Relevant quantities during a measurement with a LEAP system as suggested by -# `T. Blum et al. <https://doi.org/10.1002/9781119227250.ch18>`_. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Amplitude of the signal detected on the multi-channel plate (MCP). -# -# This field should be used for storing the signal amplitude quantity -# within ATO files. The ATO file format is used primarily by the -# atom probe groups of the GPM in Rouen, France. -# -# -# -# -# -# -# -# -# -# -# -# Set point temperature to achieve during the measurement. -# -# -# -# -# Average temperature (at the specimen base) during the measurement. -# -# -# -# -# -# The best estimate, at experiment time, for the temperature at the -# sample base (furthest point along sample apex and holding assembly -# that is removable from the sample stage). -# -# -# -# -# -# -# Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. -# -# -# -# -# -# -# -# Average pressure in the analysis chamber during the measurement. -# -# -# -# -# Pressure in the analysis chamber. -# -# -# -# -# -# -# Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. -# -# -# -# -# -# -# -# Pressure in the analysis chamber. -# -# -# -# -# -# -# Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. -# -# -# -# -# -# -# -# Pressure in the analysis chamber. -# -# -# -# -# -# -# Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXevent_data_apm_set.yaml b/contributed_definitions/nyaml/NXevent_data_apm_set.yaml deleted file mode 100644 index 4532031b7b..0000000000 --- a/contributed_definitions/nyaml/NXevent_data_apm_set.yaml +++ /dev/null @@ -1,76 +0,0 @@ -category: base -doc: | - Base class for a set of :ref:`NXevent_data_apm` instances. - - Members of the set are instances of :ref:`NXevent_data_apm`. - These have an associated time interval during which the conditions - of the instrument were considered stable and fit enough for purpose. - - Which temporal granularity is adequate depends on the situation and research - question. Using a model which enables a collection of events offers the most - flexible way to cater for both atom probe experiments or simulation. - - To monitor the course of an ion extraction experiment (or simulation) - it makes sense to track time explicitly via time stamps or implicitly - via e.g. a clock inside the instrument, such as the clock of the pulser - and respective pulsing event identifier. - - As set and measured quantities typically change over time and we do not - yet know during the measurement which of the events have associated - (molecular) ions that will end up in the reconstructed volume, we must not - document quantities as a function of the evaporated_identifier but as a - function of the (pulsing) event_identifier. -type: group -NXevent_data_apm_set(NXobject): - (NXevent_data_apm): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 6ab9c185ecd1fb4d02fac81fbc42e4a44ffab1be2b37d95f6e8ff3d0215d82ce -# -# -# -# -# -# Base class for a set of :ref:`NXevent_data_apm` instances. -# -# Members of the set are instances of :ref:`NXevent_data_apm`. -# These have an associated time interval during which the conditions -# of the instrument were considered stable and fit enough for purpose. -# -# Which temporal granularity is adequate depends on the situation and research -# question. Using a model which enables a collection of events offers the most -# flexible way to cater for both atom probe experiments or simulation. -# -# To monitor the course of an ion extraction experiment (or simulation) -# it makes sense to track time explicitly via time stamps or implicitly -# via e.g. a clock inside the instrument, such as the clock of the pulser -# and respective pulsing event identifier. -# -# As set and measured quantities typically change over time and we do not -# yet know during the measurement which of the events have associated -# (molecular) ions that will end up in the reconstructed volume, we must not -# document quantities as a function of the evaporated_identifier but as a -# function of the (pulsing) event_identifier. -# -# -# diff --git a/contributed_definitions/nyaml/NXevent_data_em.yaml b/contributed_definitions/nyaml/NXevent_data_em.yaml deleted file mode 100644 index 1dda1803ef..0000000000 --- a/contributed_definitions/nyaml/NXevent_data_em.yaml +++ /dev/null @@ -1,309 +0,0 @@ -category: base -doc: | - Base class to store state and (meta)data of events with an electron microscopy. - - Electron microscopes are dynamic. Scientists often report that microscopes - *perform differently* across sessions, that they perform differently from - one day or another. In some cases, root causes for performance differences - are unclear. Users of the instrument may consider such conditions impractical, - or *too poor*, and thus abort their session. Alternatively, users may try to - bring the microscope into a state where conditions are considered better - or of whatever high enough quality for continuing the measurement. - - In all these use cases in practice it would be useful to have a mechanism - whereby time-dependent data of the instrument state can be stored and - documented with an interoperable representation. Indeed, how a session on an - electron microscope is spent depends strongly on the research question, - the user, and the imaging modalities used. - - :ref:`NXevent_data_em` represents an instance to describe and serialize flexibly - whatever is considered a time interval during which the instrument is - considered as stable enough for performing a task with the microscope. - Examples of such tasks are the collecting of data (images and spectra) or - the calibrating of some component of the instrument. Users may wish to take - only a single scan or image and complete their microscope session thereafter. - Alternatively, users are working for much longer time at the microscope, - perform recalibrations in between and take several scans (of different - regions-of-interest of the specimen), or they explore the state of the - microscope for service or maintenance tasks. - - :ref:`NXevent_data_em` serves the harmonization and documentation of this situation - with providing three key sections: Firstly, there is a header section whose - purpose is to contextualize and identify the event instance in time. - Secondly, there is a data and metadata section where individual data collections - can be stored using a standardized representation. - - The idea of the first, the event-based em_lab section, is to document the - state of the microscope as it was during the event. The idea of the other, - the NXem application based em_lab(NXinstrument) section is to keep all those - pieces of information which are static in the sense that they are the same - across multiple :ref:`NXevent_data_em` instance. This reduces the amount of pieces of - information that have to be stored repetitively. - - We are aware of the fact that given the variety how an electron microscope - is used, there is a need for a flexible and adaptive documentation system. - At the same time we are also convinced though that just because one has - different requirements for some specific aspect under the umbrella of settings - to an electron microscope, this does not necessarily warrant that one has to - cook up an own schema. - - Instead, the electron microscopy community should work towards reusing schema - components as frequently as possible. This will enable that there is at all - not only a value of harmonizing electron microscopy research content but also - the technical possibility to build services around such harmonized - pieces of information. - - Arguably it is oftentimes tricky to specify a clear time interval when the - microscope is *stable enough*. Take for instance the acquisition of an image - or a stack of spectra. Having to deal with instabilities is a common theme in - electron microscopy practice. Numerical protocols can be used during data - post-processing to correct for some of the instabilities. - A few exemplar references to provide an overview on the subject is - available in the literature: - - * `C. Ophus et al. `_ - * `B. Berkels et al. `_ - * `L. Jones et al. `_ - - For specific simulation purposes, mainly in an effort to digitally repeat - or simulate the experiment, it is tempting to consider dynamics of the instrument, - implemented as time-dependent functional descriptions of e.g. lens excitations, - beam shape functions, trajectories of groups of electrons and ions, - or detector noise models. This warrants to document the time-dependent - details of individual components of the microscope - as is implemented in :ref:`NXevent_data_em`. -type: group -NXevent_data_em(NXobject): - start_time(NX_DATE_TIME): - doc: | - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval started. If the user wishes to specify an - interval of time that the snapshot should represent during which the instrument - was stable and configured using specific settings and calibrations, - the start_time is the start (left bound of the time interval) while - the end_time specifies the end (right bound) of the time interval. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 time code with local time zone offset to UTC information included - when the snapshot time interval ended. - event_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Identifier of a specific state and setting of the microscope. - event_type(NX_CHAR): - doc: | - Which specific event/measurement type. Examples are: - - * In-lens/backscattered electron, usually has quadrants - * Secondary_electron, image, topography, fractography, overview images - * Backscattered_electron, image, Z or channeling contrast (ECCI) - * Bright_field, image, TEM - * Dark_field, image, crystal defects - * Annular dark field, image (medium- or high-angle), TEM - * Diffraction, image, TEM, or a comparable technique in the SEM - * Kikuchi, image, SEM EBSD and TEM diffraction - * X-ray spectra (point, line, surface, volume), composition EDS/EDX(S) - * Electron energy loss spectra for points, lines, surfaces, TEM - * Auger, spectrum, (low Z contrast element composition) - * Cathodoluminescence (optical spectra) - * Ronchigram, image, alignment utility specifically in TEM - * Chamber, e.g. TV camera inside the chamber, education purposes. - - This field may also be used for storing additional information - about the event. For which there is at the moment no other place. - - In the long run such free-text field description should be avoided as - they are difficult to machine-interpret. Instead, reference should be given - to refactoring these descriptions into structured metadata. - The reason why in this base class the field event_type is nonetheless kept - is to offer a place whereby practically users may enter data for - follow-up modifications to support arriving at an improved :ref:`NXevent_data_em` base class. - (NXimage_set): - (NXspectrum_set): - em_lab(NXinstrument): - doc: | - (Meta)data of the dynamics and changes of the microscope during the event. - - # no need to duplicate the fabrication because that should remain the - (NXchamber): - (NXebeam_column): - (NXibeam_column): - (NXoptical_system_em): - (NXdetector): - (NXpump): - (NXstage_lab): - - # (NXactuator): - (NXuser): - (NXinteraction_vol_em): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# eab184a059086415ff22900a64b975982449b99e5387d817e5e44dce11fa577c -# -# -# -# -# -# Base class to store state and (meta)data of events with an electron microscopy. -# -# Electron microscopes are dynamic. Scientists often report that microscopes -# *perform differently* across sessions, that they perform differently from -# one day or another. In some cases, root causes for performance differences -# are unclear. Users of the instrument may consider such conditions impractical, -# or *too poor*, and thus abort their session. Alternatively, users may try to -# bring the microscope into a state where conditions are considered better -# or of whatever high enough quality for continuing the measurement. -# -# In all these use cases in practice it would be useful to have a mechanism -# whereby time-dependent data of the instrument state can be stored and -# documented with an interoperable representation. Indeed, how a session on an -# electron microscope is spent depends strongly on the research question, -# the user, and the imaging modalities used. -# -# :ref:`NXevent_data_em` represents an instance to describe and serialize flexibly -# whatever is considered a time interval during which the instrument is -# considered as stable enough for performing a task with the microscope. -# Examples of such tasks are the collecting of data (images and spectra) or -# the calibrating of some component of the instrument. Users may wish to take -# only a single scan or image and complete their microscope session thereafter. -# Alternatively, users are working for much longer time at the microscope, -# perform recalibrations in between and take several scans (of different -# regions-of-interest of the specimen), or they explore the state of the -# microscope for service or maintenance tasks. -# -# :ref:`NXevent_data_em` serves the harmonization and documentation of this situation -# with providing three key sections: Firstly, there is a header section whose -# purpose is to contextualize and identify the event instance in time. -# Secondly, there is a data and metadata section where individual data collections -# can be stored using a standardized representation. -# -# The idea of the first, the event-based em_lab section, is to document the -# state of the microscope as it was during the event. The idea of the other, -# the NXem application based em_lab(NXinstrument) section is to keep all those -# pieces of information which are static in the sense that they are the same -# across multiple :ref:`NXevent_data_em` instance. This reduces the amount of pieces of -# information that have to be stored repetitively. -# -# We are aware of the fact that given the variety how an electron microscope -# is used, there is a need for a flexible and adaptive documentation system. -# At the same time we are also convinced though that just because one has -# different requirements for some specific aspect under the umbrella of settings -# to an electron microscope, this does not necessarily warrant that one has to -# cook up an own schema. -# -# Instead, the electron microscopy community should work towards reusing schema -# components as frequently as possible. This will enable that there is at all -# not only a value of harmonizing electron microscopy research content but also -# the technical possibility to build services around such harmonized -# pieces of information. -# -# Arguably it is oftentimes tricky to specify a clear time interval when the -# microscope is *stable enough*. Take for instance the acquisition of an image -# or a stack of spectra. Having to deal with instabilities is a common theme in -# electron microscopy practice. Numerical protocols can be used during data -# post-processing to correct for some of the instabilities. -# A few exemplar references to provide an overview on the subject is -# available in the literature: -# -# * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ -# * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ -# * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ -# -# For specific simulation purposes, mainly in an effort to digitally repeat -# or simulate the experiment, it is tempting to consider dynamics of the instrument, -# implemented as time-dependent functional descriptions of e.g. lens excitations, -# beam shape functions, trajectories of groups of electrons and ions, -# or detector noise models. This warrants to document the time-dependent -# details of individual components of the microscope -# as is implemented in :ref:`NXevent_data_em`. -# -# -# -# ISO 8601 time code with local time zone offset to UTC information included -# when the snapshot time interval started. If the user wishes to specify an -# interval of time that the snapshot should represent during which the instrument -# was stable and configured using specific settings and calibrations, -# the start_time is the start (left bound of the time interval) while -# the end_time specifies the end (right bound) of the time interval. -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC information included -# when the snapshot time interval ended. -# -# -# -# -# Identifier of a specific state and setting of the microscope. -# -# -# -# -# Which specific event/measurement type. Examples are: -# -# * In-lens/backscattered electron, usually has quadrants -# * Secondary_electron, image, topography, fractography, overview images -# * Backscattered_electron, image, Z or channeling contrast (ECCI) -# * Bright_field, image, TEM -# * Dark_field, image, crystal defects -# * Annular dark field, image (medium- or high-angle), TEM -# * Diffraction, image, TEM, or a comparable technique in the SEM -# * Kikuchi, image, SEM EBSD and TEM diffraction -# * X-ray spectra (point, line, surface, volume), composition EDS/EDX(S) -# * Electron energy loss spectra for points, lines, surfaces, TEM -# * Auger, spectrum, (low Z contrast element composition) -# * Cathodoluminescence (optical spectra) -# * Ronchigram, image, alignment utility specifically in TEM -# * Chamber, e.g. TV camera inside the chamber, education purposes. -# -# This field may also be used for storing additional information -# about the event. For which there is at the moment no other place. -# -# In the long run such free-text field description should be avoided as -# they are difficult to machine-interpret. Instead, reference should be given -# to refactoring these descriptions into structured metadata. -# The reason why in this base class the field event_type is nonetheless kept -# is to offer a place whereby practically users may enter data for -# follow-up modifications to support arriving at an improved :ref:`NXevent_data_em` base class. -# -# -# -# -# -# -# (Meta)data of the dynamics and changes of the microscope during the event. -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXevent_data_em_set.yaml b/contributed_definitions/nyaml/NXevent_data_em_set.yaml deleted file mode 100644 index 70c64c6cd5..0000000000 --- a/contributed_definitions/nyaml/NXevent_data_em_set.yaml +++ /dev/null @@ -1,80 +0,0 @@ -category: base -doc: | - Base class for a set of :ref:`NXevent_data_em` instances. - - Members of the set are instances of :ref:`NXevent_data_em`. These have an associated - time interval during which the conditions were considered stable and - fit enough for purpose. - - Which temporal granularity is adequate depends on the situation and - research question. Using a model which enables a collection of events offers - the most flexible way to cater for both experiments with controlled electron - beams in a real microscope or the simulation of such experiments or - individual aspects of such experiments. -type: group -NXevent_data_em_set(NXobject): - - # because it should be possible to use the application definition - # to store e.g. just some descriptions about the instrument - # to which eventually no measurements are attached - # this would enable to use nxs files also for instrument - # inventory system like offered through ELNs/or LIMS - (NXevent_data_em): - - # because it should be possible to use the application definition - # to store e.g. just some descriptions about the instrument - # to which eventually no measurements are attached - # this would enable to use nxs files also for instrument - # inventory system like offered through ELNs/or LIMS - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e25e9f921fd88c9eaf1988e4620d558c14aca2a19e4794096568fe74f406fcc6 -# -# -# -# -# -# Base class for a set of :ref:`NXevent_data_em` instances. -# -# Members of the set are instances of :ref:`NXevent_data_em`. These have an associated -# time interval during which the conditions were considered stable and -# fit enough for purpose. -# -# Which temporal granularity is adequate depends on the situation and -# research question. Using a model which enables a collection of events offers -# the most flexible way to cater for both experiments with controlled electron -# beams in a real microscope or the simulation of such experiments or -# individual aspects of such experiments. -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXfabrication.yaml b/contributed_definitions/nyaml/NXfabrication.yaml deleted file mode 100644 index 85f7602206..0000000000 --- a/contributed_definitions/nyaml/NXfabrication.yaml +++ /dev/null @@ -1,107 +0,0 @@ -category: base -doc: | - Details about a component as it is defined by its manufacturer. -type: group -NXfabrication(NXobject): - vendor(NX_CHAR): - doc: | - Company name of the manufacturer. - model(NX_CHAR): - doc: | - Version or model of the component named by the manufacturer. - \@version: - type: NX_CHAR - doc: | - If different versions exist are possible, the value in this field should be made - specific enough to resolve the version. - identifier(NXidentifier): - doc: | - Ideally, (globally) unique persistent identifier. This may contain e.g. a hash - identifier of the component. - serial_number(NX_CHAR): - doc: | - Serial number of the component. - construction_year(NX_DATE_TIME): - doc: | - Datetime of components initial construction. This refers to the date of - first measurement after new construction or to the relocation date, - if it describes a multicomponent/custom-build setup. - Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, - otherwise the local time zone is assumed per ISO8601. - capability(NX_CHAR): - doc: | - Free-text list with eventually multiple terms of - functionalities which the component offers. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f65b1d8288480aa2c0e4fdbc531ea3c5df221b12fa1fea70b19850712c715807 -# -# -# -# -# -# Details about a component as it is defined by its manufacturer. -# -# -# -# Company name of the manufacturer. -# -# -# -# -# Version or model of the component named by the manufacturer. -# -# -# -# If different versions exist are possible, the value in this field should be made -# specific enough to resolve the version. -# -# -# -# -# -# Ideally, (globally) unique persistent identifier. This may contain e.g. a hash -# identifier of the component. -# -# -# -# -# Serial number of the component. -# -# -# -# -# Datetime of components initial construction. This refers to the date of -# first measurement after new construction or to the relocation date, -# if it describes a multicomponent/custom-build setup. -# Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, -# otherwise the local time zone is assumed per ISO8601. -# -# -# -# -# Free-text list with eventually multiple terms of -# functionalities which the component offers. -# -# -# diff --git a/contributed_definitions/nyaml/NXfit.yaml b/contributed_definitions/nyaml/NXfit.yaml deleted file mode 100644 index cae8de1e8e..0000000000 --- a/contributed_definitions/nyaml/NXfit.yaml +++ /dev/null @@ -1,345 +0,0 @@ -category: base -doc: | - Description of a fit procedure. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - dimRank: | - Rank of the dependent and independent data arrays (for - multidimensional/multivariate fit.) -type: group -NXfit(NXprocess): - label: - doc: | - Human-readable label for this fit procedure. - data(NXdata): - doc: | - Input data and results of the fit. - input_dependent(NX_NUMBER): - unit: NX_ANY - doc: | - Position values along one or more data dimensions (to hold the - values for the independent variable for this fit procedure). - dimensions: - rank: dimRank - doc: | - The ``input_dependent`` field must have the same rank (``dimRank``) - as the ``input_independent`` field. Each individual dimension of ``input_dependent`` - must have the same number of points as the corresponding dimension in - the ``input_independent`` field. - dim: [] - input_independent(NX_NUMBER): - unit: NX_ANY - doc: | - Independent input axis for this fit procedure. - dimensions: - rank: dimRank - doc: | - The ``input_independent`` field must have the same rank (``dimRank``) - as the ``input_dependent`` field. Each individual dimension of ``input_independent`` - must have the same number of points as the corresponding dimension in - the ``input_dependent`` field. - dim: [] - envelope(NX_NUMBER): - unit: NX_ANY - doc: | - Resulting envelope of applying the `global_fit_function` with its parameter to the data stored - in `input_independent`. - dimensions: - rank: dimRank - doc: | - The ``envelope`` field must have the same rank (``dimRank``) - as the ``input_independent`` field. Each individual dimension of ``envelope`` - must have the same number of points as the corresponding dimension in - the ``input_independent`` field. - dim: [] - residual(NX_NUMBER): - unit: NX_ANY - doc: | - Difference between the envelope and the `input_independent` data to be fitted. - dimensions: - rank: dimRank - doc: | - The ``residual`` field must have the same rank (``dimRank``) - as the ``input_independent`` field. Each individual dimension of ``residual`` - must have the same number of points as the corresponding dimension in - the ``input_independent`` field. - dim: [] - peakPEAK(NXpeak): - doc: | - One peak of the peak model. - If there is no characteristic name for each peak component, is envisioned that peaks - are labeled as peak_0, peak_1, and so on. - total_area(NX_NUMBER): - unit: NX_ANY - doc: | - Total area under the curve (can also be used for the total area minus any - background values). - relative_sensitivity_factor(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Relative sensitivity for this peak, to be used for quantification in - an NXprocess. - - As an example, in X-ray spectroscopy could depend on the energy scale - (see position), the ionization cross section, and the element probed. - relative_area(NX_NUMBER): - unit: NX_ANY - doc: | - Relative area of this peak compared to other peaks. - - The relative area can simply be derived by dividing the total_area by the - total area of all peaks or by a more complicated method (e.g., by - additionally dividing by the relative sensitivity factors). Details shall - be given in `global_fit_function`. - backgroundBACKGROUND(NXfit_background): - doc: | - One fitted background (functional form, position, and intensities) of the peak fit. - If there is no characteristic name for each peak component, it is envisioned that backgrounds are labeled - as background_0, background_1, and so on. - global_fit_function(NXfit_function): - doc: | - Function used to describe the overall fit to the data, taking into account the parameters of the - individual `NXpeak` and `NXfit_background` components. - formula: - doc: | - Oftentimes, if the peaks and fit backgrounds are defined independently (i.e, with their own - parameter sets), the resulting global fit is a function of the form - :math:`model = peak_1(p_1) + peak2(p_2) + backgr(p_3).`, where each :math:`p_x` describes the - set of parameters for one peak/background. - error_function(NXfit_function): - doc: | - Function used to optimize the parameters during peak fitting. - description: - doc: | - Description of the method used to optimize the parameters during peak fitting. - Examples: - - least squares - - non-linear least squares - - Levenberg-Marquardt algorithm (damped least-squares) - - linear regression - - Bayesian linear regression - formula: - doc: | - For the optimization, the formula is any optimization process on the `global_fit_function` given above. - As an example, for a linear least squared algorithm on independent components, the formula of the error_function - would be :math:`LLS(peak_1(p_1) + peak2(p_2) + backgr(p_3))`, where each :math:`p_x` describes the set - of parameters for one peak/background. - - It is however also possible to supply more involved formulas (e.g., in the case of constrained fits). - figure_of_meritMETRIC(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Figure-of-merit to determine the goodness of fit, i.e., how well the peak model - fits the measured observations. - - This value (which is a single number) is oftenused to guide adjustments to the - fitting parameters in the peak fitting process. - \@metric: - doc: | - Metric used to determine the goodness of fit. Examples include: - - :math:`\chi^2`, the squared sum of the sigma-weighted residuals - - reduced :math:`\chi^2`:, :math:`\chi^2`: per degree of freedom - - :math:`R^2`, the coefficient of determination - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# fcf92e26824bac53c43854728f890e890bbbbb7f6f10e102a632304056ac91fd -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Rank of the dependent and independent data arrays (for -# multidimensional/multivariate fit.) -# -# -# -# -# Description of a fit procedure. -# -# -# -# Human-readable label for this fit procedure. -# -# -# -# -# Input data and results of the fit. -# -# -# -# Position values along one or more data dimensions (to hold the -# values for the independent variable for this fit procedure). -# -# -# -# The ``input_dependent`` field must have the same rank (``dimRank``) -# as the ``input_independent`` field. Each individual dimension of ``input_dependent`` -# must have the same number of points as the corresponding dimension in -# the ``input_independent`` field. -# -# -# -# -# -# Independent input axis for this fit procedure. -# -# -# -# The ``input_independent`` field must have the same rank (``dimRank``) -# as the ``input_dependent`` field. Each individual dimension of ``input_independent`` -# must have the same number of points as the corresponding dimension in -# the ``input_dependent`` field. -# -# -# -# -# -# Resulting envelope of applying the `global_fit_function` with its parameter to the data stored -# in `input_independent`. -# -# -# -# The ``envelope`` field must have the same rank (``dimRank``) -# as the ``input_independent`` field. Each individual dimension of ``envelope`` -# must have the same number of points as the corresponding dimension in -# the ``input_independent`` field. -# -# -# -# -# -# Difference between the envelope and the `input_independent` data to be fitted. -# -# -# -# The ``residual`` field must have the same rank (``dimRank``) -# as the ``input_independent`` field. Each individual dimension of ``residual`` -# must have the same number of points as the corresponding dimension in -# the ``input_independent`` field. -# -# -# -# -# -# -# One peak of the peak model. -# If there is no characteristic name for each peak component, is envisioned that peaks -# are labeled as peak_0, peak_1, and so on. -# -# -# -# Total area under the curve (can also be used for the total area minus any -# background values). -# -# -# -# -# Relative sensitivity for this peak, to be used for quantification in -# an NXprocess. -# -# As an example, in X-ray spectroscopy could depend on the energy scale -# (see position), the ionization cross section, and the element probed. -# -# -# -# -# Relative area of this peak compared to other peaks. -# -# The relative area can simply be derived by dividing the total_area by the -# total area of all peaks or by a more complicated method (e.g., by -# additionally dividing by the relative sensitivity factors). Details shall -# be given in `global_fit_function`. -# -# -# -# -# -# One fitted background (functional form, position, and intensities) of the peak fit. -# If there is no characteristic name for each peak component, it is envisioned that backgrounds are labeled -# as background_0, background_1, and so on. -# -# -# -# -# Function used to describe the overall fit to the data, taking into account the parameters of the -# individual `NXpeak` and `NXfit_background` components. -# -# -# -# Oftentimes, if the peaks and fit backgrounds are defined independently (i.e, with their own -# parameter sets), the resulting global fit is a function of the form -# :math:`model = peak_1(p_1) + peak2(p_2) + backgr(p_3).`, where each :math:`p_x` describes the -# set of parameters for one peak/background. -# -# -# -# -# -# Function used to optimize the parameters during peak fitting. -# -# -# -# Description of the method used to optimize the parameters during peak fitting. -# Examples: -# - least squares -# - non-linear least squares -# - Levenberg-Marquardt algorithm (damped least-squares) -# - linear regression -# - Bayesian linear regression -# -# -# -# -# For the optimization, the formula is any optimization process on the `global_fit_function` given above. -# As an example, for a linear least squared algorithm on independent components, the formula of the error_function -# would be :math:`LLS(peak_1(p_1) + peak2(p_2) + backgr(p_3))`, where each :math:`p_x` describes the set -# of parameters for one peak/background. -# -# It is however also possible to supply more involved formulas (e.g., in the case of constrained fits). -# -# -# -# -# -# Figure-of-merit to determine the goodness of fit, i.e., how well the peak model -# fits the measured observations. -# -# This value (which is a single number) is oftenused to guide adjustments to the -# fitting parameters in the peak fitting process. -# -# -# -# Metric used to determine the goodness of fit. Examples include: -# - :math:`\chi^2`, the squared sum of the sigma-weighted residuals -# - reduced :math:`\chi^2`:, :math:`\chi^2`: per degree of freedom -# - :math:`R^2`, the coefficient of determination -# -# -# -# diff --git a/contributed_definitions/nyaml/NXfit_background.yaml b/contributed_definitions/nyaml/NXfit_background.yaml deleted file mode 100644 index f988a8bfc6..0000000000 --- a/contributed_definitions/nyaml/NXfit_background.yaml +++ /dev/null @@ -1,128 +0,0 @@ -category: base -doc: | - Description of the background for an NXfit model. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - dimRank: | - Rank of the dependent and independent data arrays (for - multidimensional/multivariate fit.) -type: group -NXfit_background(NXobject): - label(NX_CHAR): - doc: | - Human-readable label which specifies which concept/entity - the background represents/identifies. - data(NXdata): - position(NX_NUMBER): - unit: NX_ANY - doc: | - Position values along one or more data dimensions (to hold the - values for the independent variable). - dimensions: - rank: dimRank - doc: | - The ``position`` field must have the same rank (``dimRank``) - as the ``intensity`` field. Each individual dimension of ``position`` - must have the same number of points as the corresponding dimension in - the ``intensity`` field. - dim: [] - intensity(NX_NUMBER): - unit: NX_ANY - doc: | - This array holds the intensity/count values of the fitted background - at each position. - dimensions: - rank: dimRank - doc: | - The ``intensity`` field must have the same rank (``dimRank``) - as the ``intensity`` field. Each individual dimension of ``position`` - must have the same number of points as the corresponding dimension in - the ``position`` field. - dim: [] - function(NXfit_function): - doc: | - The functional form of the background. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f2aa053cf2efec41fdae311ac6df33ac71072aeb03ff3d640b641c1e8b1f2be6 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Rank of the dependent and independent data arrays (for -# multidimensional/multivariate fit.) -# -# -# -# -# Description of the background for an NXfit model. -# -# -# -# Human-readable label which specifies which concept/entity -# the background represents/identifies. -# -# -# -# -# -# Position values along one or more data dimensions (to hold the -# values for the independent variable). -# -# -# -# The ``position`` field must have the same rank (``dimRank``) -# as the ``intensity`` field. Each individual dimension of ``position`` -# must have the same number of points as the corresponding dimension in -# the ``intensity`` field. -# -# -# -# -# -# This array holds the intensity/count values of the fitted background -# at each position. -# -# -# -# The ``intensity`` field must have the same rank (``dimRank``) -# as the ``intensity`` field. Each individual dimension of ``position`` -# must have the same number of points as the corresponding dimension in -# the ``position`` field. -# -# -# -# -# -# -# The functional form of the background. -# -# -# diff --git a/contributed_definitions/nyaml/NXfit_function.yaml b/contributed_definitions/nyaml/NXfit_function.yaml deleted file mode 100644 index 49239bbcf7..0000000000 --- a/contributed_definitions/nyaml/NXfit_function.yaml +++ /dev/null @@ -1,70 +0,0 @@ -category: base -doc: | - This describes a fit function that is used to fit data to any functional form. - - A fit function is used to describe a set of data :math:`y_k, k = 1 ... M`, which are collected as a function - of one or more independent variables :math:`x` at the points :math:`x_k`. The fit function :math:`f` describes - these data in an approximative way as :math:`y_k \approx f(a_0, . . . a_n, x_k)`, - where :math:`a_i, i = 0 . . . n` are the *fit parameters* (which are stored the instances of ``NXfit_parameter``). -type: group -NXfit_function(NXobject): - description: - doc: | - Human-readable description of this fit function. - formula: - doc: | - Mathematical formula of the function, taking into account the instances of ``NXfit_parameter``. - - This should be a python parsable function. Here we should provide which keywords are available - and a BNF of valid grammar. - (NXfit_parameter): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# b51591b808787be4a867f81d41f3052c7ee34d1f259aad4d3488c0df05cfd211 -# -# -# -# -# -# This describes a fit function that is used to fit data to any functional form. -# -# A fit function is used to describe a set of data :math:`y_k, k = 1 ... M`, which are collected as a function -# of one or more independent variables :math:`x` at the points :math:`x_k`. The fit function :math:`f` describes -# these data in an approximative way as :math:`y_k \approx f(a_0, . . . a_n, x_k)`, -# where :math:`a_i, i = 0 . . . n` are the *fit parameters* (which are stored the instances of ``NXfit_parameter``). -# -# -# -# Human-readable description of this fit function. -# -# -# -# -# Mathematical formula of the function, taking into account the instances of ``NXfit_parameter``. -# -# This should be a python parsable function. Here we should provide which keywords are available -# and a BNF of valid grammar. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXfit_parameter.yaml b/contributed_definitions/nyaml/NXfit_parameter.yaml deleted file mode 100644 index 313e5a3cd0..0000000000 --- a/contributed_definitions/nyaml/NXfit_parameter.yaml +++ /dev/null @@ -1,85 +0,0 @@ -category: base -doc: | - A parameter for a fit function. - This would typically be a variable that - is optimized in a fit. -type: group -NXfit_parameter(NXobject): - name(NX_CHAR): - doc: | - The name of the parameter. - description(NX_CHAR): - doc: | - A description of what this parameter represents. - value(NX_NUMBER): - unit: NX_ANY - doc: | - The value of the parameter. After fitting, this would store the - optimized value. - min_value(NX_NUMBER): - unit: NX_ANY - doc: | - The minimal value of the parameter, to be used as a constraint during fitting. - max_value(NX_NUMBER): - unit: NX_ANY - doc: | - The maximal value of the parameter, to be used as a constraint during fitting. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 86b45dd6443b276fa8997b0d758a2262339c05b2ef70429d700ec583802a8e9b -# -# -# -# -# -# A parameter for a fit function. -# This would typically be a variable that -# is optimized in a fit. -# -# -# -# The name of the parameter. -# -# -# -# -# A description of what this parameter represents. -# -# -# -# -# The value of the parameter. After fitting, this would store the -# optimized value. -# -# -# -# -# The minimal value of the parameter, to be used as a constraint during fitting. -# -# -# -# -# The maximal value of the parameter, to be used as a constraint during fitting. -# -# -# diff --git a/contributed_definitions/nyaml/NXhistory.yaml b/contributed_definitions/nyaml/NXhistory.yaml deleted file mode 100644 index bcbd911d29..0000000000 --- a/contributed_definitions/nyaml/NXhistory.yaml +++ /dev/null @@ -1,120 +0,0 @@ -category: base -doc: | - A set of activities that occurred to a physical entity prior/during experiment. - - Ideally, a full report of the previous operations (or links to a chain of operations). - Alternatively, notes allow for additional descriptors in any format. -type: group -NXhistory(NXobject): - (NXactivity): - doc: | - Any activity that was performed on the physical entity prior or during the experiment. In - the future, if there is base class inheritance, this can describe any activity, - including processes and measurements. - - # For now, one workaround would be to have NXactivity as a application definition with a subentry. - # subentry(NXsuxbentry): - # doc: | - # Any activity that was performed on the physical entity prior or during the experiment. - # definition: ["NXactivity"] - (NXphysical_process): - doc: | - Any physical process that was performed on the physical entity prior or during the - experiment. - (NXchemical_process): - doc: | - Any chemical process that was performed on the physical entity prior or during the - experiment. - (NXidentifier): - doc: | - An ID or reference to the location or a unique (globally - persistent) identifier of e.g. another file which gives - as many as possible details of the history event. - - # There should be more activities here, like measurement. - notes(NXnote): - doc: | - A descriptor to keep track of the treatment of the physical entity before or during the - experiment (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - This should only be used in case that there is no rigorous description - using the base classes above. This field can also be used to pull in any activities - that are not well described by an existing base class definition. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 163311ced8903c158bd712975b26239b5c2df71cf0db35feea5825bfb927e56a -# -# -# -# -# -# A set of activities that occurred to a physical entity prior/during experiment. -# -# Ideally, a full report of the previous operations (or links to a chain of operations). -# Alternatively, notes allow for additional descriptors in any format. -# -# -# -# Any activity that was performed on the physical entity prior or during the experiment. In -# the future, if there is base class inheritance, this can describe any activity, -# including processes and measurements. -# -# -# -# -# -# Any physical process that was performed on the physical entity prior or during the -# experiment. -# -# -# -# -# Any chemical process that was performed on the physical entity prior or during the -# experiment. -# -# -# -# -# An ID or reference to the location or a unique (globally -# persistent) identifier of e.g. another file which gives -# as many as possible details of the history event. -# -# -# -# -# -# A descriptor to keep track of the treatment of the physical entity before or during the -# experiment (NXnote allows to add pictures, audio, movies). Alternatively, a -# reference to the location or a unique identifier or other metadata file. In the -# case these are not available, free-text description. -# This should only be used in case that there is no rigorous description -# using the base classes above. This field can also be used to pull in any activities -# that are not well described by an existing base class definition. -# -# -# diff --git a/contributed_definitions/nyaml/NXibeam_column.yaml b/contributed_definitions/nyaml/NXibeam_column.yaml deleted file mode 100644 index 2721c36bff..0000000000 --- a/contributed_definitions/nyaml/NXibeam_column.yaml +++ /dev/null @@ -1,227 +0,0 @@ -category: base -doc: | - Base class for a set of components equipping an instrument with FIB capabilities. - - Focused-ion-beam (FIB) capabilities turn especially scanning electron microscopes - into specimen preparation labs. FIB is a material preparation technique whereby - portions of the sample are illuminated with a focused ion beam with controlled - intensity. The beam is intense enough and with sufficient ion momentum to - remove material in a controlled manner. - - The fact that an electron microscope with FIB capabilities has needs a - second gun with own relevant control circuits, focusing lenses, and other - components, warrants the definition of an own base class to group these - components and distinguish them from the lenses and components for creating - and shaping the electron beam. - - For more details about the relevant physics and application examples - consult the literature, for example: - - * `L. A. Giannuzzi et al. `_ - * `E. I. Preiß et al. `_ - * `J. F. Ziegler et al. `_ - * `J. Lili `_ -type: group -NXibeam_column(NXcomponent): - (NXchamber): - ion_source(NXsource): - doc: | - The source which creates the ion beam. - name(NX_CHAR): - doc: | - Given name/alias for the ion gun. - emitter_type(NX_CHAR): - doc: | - Emitter type used to create the ion beam. - - If the emitter type is other, give further - details in the description field. - enumeration: [liquid_metal, plasma, gas_field, other] - description(NX_CHAR): - doc: | - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - probe(NXion): - doc: | - Which ionized elements or molecular ions form the beam. - Examples are gallium, helium, neon, argon, krypton, - or xenon, O2+. - flux(NX_NUMBER): - unit: NX_ANY - doc: | - Average/nominal flux - brightness(NX_NUMBER): - unit: NX_ANY - doc: | - Average/nominal brightness - - # \@units: A/cm*sr - # NEW ISSUE: (at which location?). - current(NX_NUMBER): - unit: NX_CURRENT - doc: | - Charge current - voltage(NX_NUMBER): - unit: NX_VOLTAGE - doc: | - Ion acceleration voltage upon source exit and - entering the vacuum flight path. - ion_energy_profile(NX_NUMBER): - unit: NX_ENERGY - doc: | - To be defined more specifically. Community suggestions are welcome. - - # NEW ISSUE: details about the life/up-time of the source relevant from maintenance point of view - (NXlens_em): - (NXaperture): - (NXmonochromator): - (NXcomponent): - (NXsensor): - (NXactuator): - (NXbeam): - doc: | - Individual characterization results for the position, shape, - and characteristics of the ion beam. - - :ref:`NXtransformations` should be used to specify the location or position - at which details about the ion beam are probed. - (NXdeflector): - - # for further ideas and comments inspect version - # https://github.com/FAIRmat-NFDI/nexus_definitions/commit/0682943baaef54d4a6386b5433f9721af6d3d81b - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# cf2e5b002ef93fb9014be7937c046c4ca9c28f61f5fcf898cb72fe1d7e22da79 -# -# -# -# -# -# Base class for a set of components equipping an instrument with FIB capabilities. -# -# Focused-ion-beam (FIB) capabilities turn especially scanning electron microscopes -# into specimen preparation labs. FIB is a material preparation technique whereby -# portions of the sample are illuminated with a focused ion beam with controlled -# intensity. The beam is intense enough and with sufficient ion momentum to -# remove material in a controlled manner. -# -# The fact that an electron microscope with FIB capabilities has needs a -# second gun with own relevant control circuits, focusing lenses, and other -# components, warrants the definition of an own base class to group these -# components and distinguish them from the lenses and components for creating -# and shaping the electron beam. -# -# For more details about the relevant physics and application examples -# consult the literature, for example: -# -# * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ -# * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ -# * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ -# * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ -# -# -# -# -# The source which creates the ion beam. -# -# -# -# Given name/alias for the ion gun. -# -# -# -# -# Emitter type used to create the ion beam. -# -# If the emitter type is other, give further -# details in the description field. -# -# -# -# -# -# -# -# -# -# -# Ideally, a (globally) unique persistent identifier, link, -# or text to a resource which gives further details. -# -# -# -# -# Which ionized elements or molecular ions form the beam. -# Examples are gallium, helium, neon, argon, krypton, -# or xenon, O2+. -# -# -# -# -# Average/nominal flux -# -# -# -# -# Average/nominal brightness -# -# -# -# -# -# Charge current -# -# -# -# -# Ion acceleration voltage upon source exit and -# entering the vacuum flight path. -# -# -# -# -# To be defined more specifically. Community suggestions are welcome. -# -# -# -# -# -# -# -# -# -# -# -# -# Individual characterization results for the position, shape, -# and characteristics of the ion beam. -# -# :ref:`NXtransformations` should be used to specify the location or position -# at which details about the ion beam are probed. -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXidentifier.yaml b/contributed_definitions/nyaml/NXidentifier.yaml deleted file mode 100644 index 03b1c4ea83..0000000000 --- a/contributed_definitions/nyaml/NXidentifier.yaml +++ /dev/null @@ -1,72 +0,0 @@ -category: base -doc: | - An identifier for a (persistent) resource, e.g., a DOI or orcid. -type: group -NXidentifier(NXobject): - service(NX_CHAR): - doc: | - The service by which the resource can be resolved. - - Examples: doi, urn, hdl, purl, orcid, iso, url - identifier(NX_CHAR): - doc: | - The unique code, IRI or hash to resolve this reference. - Typically, this is stated by the service which is considered a complete - identifier, e.g., for a DOI it's something of the form `10.1107/S1600576714027575` - or `https://doi.org/10.1107/S1600576714027575`, which are both resolvable. - is_persistent(NX_BOOLEAN): - doc: | - True if the identifier is persistent (i.e., unique and available indefinitely), - False otherwise. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# c197e239497a8aa2e3ca2dd67b414da2b694e2fe8ce40c3b309232e72b75df9b -# -# -# -# -# -# An identifier for a (persistent) resource, e.g., a DOI or orcid. -# -# -# -# The service by which the resource can be resolved. -# -# Examples: doi, urn, hdl, purl, orcid, iso, url -# -# -# -# -# The unique code, IRI or hash to resolve this reference. -# Typically, this is stated by the service which is considered a complete -# identifier, e.g., for a DOI it's something of the form `10.1107/S1600576714027575` -# or `https://doi.org/10.1107/S1600576714027575`, which are both resolvable. -# -# -# -# -# True if the identifier is persistent (i.e., unique and available indefinitely), -# False otherwise. -# -# -# diff --git a/contributed_definitions/nyaml/NXimage_set.yaml b/contributed_definitions/nyaml/NXimage_set.yaml deleted file mode 100644 index 50c47b87ef..0000000000 --- a/contributed_definitions/nyaml/NXimage_set.yaml +++ /dev/null @@ -1,1156 +0,0 @@ -category: base -doc: | - Base class for reporting a set of images. - - The mostly commonly used scanning methods are supported. That is one-, - two-, three-dimensional ROIs discretized using regular Euclidean tilings. - - Colloquially, an image is understood as a discretized representation of intensity distribution - that was detected or simulated for some ROI. When discretized with regular Euclidean tilings - the terms pixel and voxel identify the smallest discretization unit. Pixel and voxel are polygonal - or polyhedral unit cells respectively of the underlying tiling of the ROI within the reference space. - For all other tilings e.g. non-equispaced, the shape and size of pixel and voxel differs. Using the term - (image) point is eventually is more appropriate for such tilings. Therefore, all docstrings in this base class - refer to points (including pixel and voxel i.e. regular tilings). - - Point coordinates identify the location of the barycentre. - - For images in reciprocal space in practice, complex numbers are encoded via some - formatted pair of real values. Typically, fast algorithms for computing Fourier transformations - (FFT) are used to encode images in reciprocal (frequency) space. FFT libraries are used - for implementing the key functionalities of these mathematical operations. - - Different libraries use different representations and encoding of the images. - Details can be found in the respective sections of the typical FFT libraries documentations - - * `FFTW by M. Frigo and S. G. Johnson `_ - * `Intel MKL by the Intel Co. `_ - * `cuFFT by the NVidia Co. `_ - * `NFFT by the Chemnitz group `_ for non-equispaced computations - - Users are strongly advised to inspect carefully which specific conventions their library uses - to enable storing and modifying the implementation of their code such that the serialized - representations as they are detailed here for NeXus match. - - It is often the case that several images are combined using processing. In this case, - the number of images which are combined in a collection is not necessarily the same - for each collection. The NXimage_set base class addresses this logical distinction - through the notation of image_identifier and group_identifier concepts. - That is image_identifier are always counting from offset in increments of one. - as each image is its own entity. By contrast, a group may contain no, or several images. - Consequently, group_identifier are not required to be contiguous. - -# for earlier variants see here -# https://github.com/FAIRmat-NFDI/nexus_definitions/commit/0682943baaef54d4a6386b5433f9721af6d3d81b -# https://en.wikipedia.org/wiki/Euclidean_tilings_by_convex_regular_polygons -symbols: - n_img: | - Number of images in the stack, for stacks the slowest dimension. - n_k: | - Number of image points along the slow dimension (k equivalent to z). - n_j: | - Number of image points along the fast dimension (j equivalent to y). - n_i: | - Number of image points along the fastest dimension (i equivalent to x). - -# a key challenge is setting constraints, lets explain with contrasting two use cases: -# case 1 assuming an image is nothing but a collection of point-wise information without making explicit tiling and discretization information -# case 2 assuming that like most frequently assumed we understand an image probing Euclidean space -# assuming that we expect that the image is represented using a pixel grid because it was captured -# using sensors that are arranged on generator points of a regular tiling. -# in the first case, one should not constrain the dimensions for images beyond 1d -# because beyond 1d the question of offset and stride comes up i.e. the question which -# tiling is used to construct the sensor array -# in the second case, one should constrain the dimensions for all dimensions as otherwise -# there are no instructions how to arrange the sensors or the pixels for visualizing the image -# because the image is not just a bunch of point wise intensities -# but if the dimensions are not constrained again images in application definitions will be represented -# using different conventions. -type: group -NXimage_set(NXobject): - (NXprocess): - doc: | - Details how NXdata instance were processed from detector readings/raw data. - source(NXserialized): - doc: | - Resolvable data artifact (e.g. file) from which all values in the :ref:`NXdata` - instances in this :ref:`NXimage_set` were loaded during parsing. - - Possibility to document from which specific other serialized resource as the source - pieces of information were processed when using NeXus as a semantic file format - to serialize that information differently. - - The group in combination with an added field *absolute_path* therein adds context. - absolute_path(NX_CHAR): - doc: | - Reference to a location inside the artifact that points to the specific group of values - that were processed if the artifacts contains several groups of values and thus - further resolving of ambiguities is required. - - # mode(NX_CHAR): - # doc: | - # Imaging (data collection) mode of the instrument during acquisition. - detector_identifier(NX_CHAR): - doc: | - Link or name of an :ref:`NXdetector` instance with which the data were - collected. - (NXprogram): - doc: | - Program used for processing. - - # space(NX_CHAR): - # doc: - # - | - # The reference space in which the image set is defined. - # enumeration: [real, reciprocal] - image_1d(NXdata): - doc: | - One-dimensional image. - intensity(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Intensity for real-valued images as an alternative for real. - Magnitude of the image intensity for complex-valued data. - dimensions: - rank: 1 - dim: [[1, n_i]] - real(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Real part of the image intensity per point. - dimensions: - rank: 1 - dim: [[1, n_i]] - imag(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Imaginary part of the image intensity per point. - dimensions: - rank: 1 - dim: [[1, n_i]] - complex(NX_COMPLEX): - unit: NX_UNITLESS - doc: | - Image intensity as a complex number as an alternative to real and - imaginary fields if values are stored as interleaved complex numbers. - dimensions: - rank: 1 - dim: [[1, n_i]] - axis_i(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the fastest dimension. - dimensions: - rank: 1 - dim: [[1, n_i]] - \@long_name: - type: NX_CHAR - doc: | - Point coordinate along the fastest dimension. - image_2d(NXdata): - doc: | - Two-dimensional image. - intensity(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Intensity for real-valued images as an alternative for real. - Magnitude of the image intensity for complex-valued data. - dimensions: - rank: 2 - dim: [[1, n_j], [2, n_i]] - real(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Real part of the image intensity per point. - dimensions: - rank: 2 - dim: [[1, n_j], [2, n_i]] - imag(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Imaginary part of the image intensity per point. - dimensions: - rank: 2 - dim: [[1, n_j], [2, n_i]] - complex(NX_COMPLEX): - unit: NX_UNITLESS - doc: | - Image intensity as a complex number as an alternative to real and - imaginary fields if values are stored as interleaved complex numbers. - dimensions: - rank: 2 - dim: [[1, n_j], [2, n_i]] - axis_j(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the fast dimension. - dimensions: - rank: 1 - dim: [[1, n_j]] - \@long_name: - type: NX_CHAR - doc: | - Point coordinate along the fast dimension. - axis_i(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the fastest dimension. - dimensions: - rank: 1 - dim: [[1, n_i]] - \@long_name: - type: NX_CHAR - doc: | - Point coordinate along the fastest dimension. - image_3d(NXdata): - doc: | - Three-dimensional image. - intensity(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Intensity for real-valued images as an alternative for real. - Magnitude of the image intensity for complex-valued data. - dimensions: - rank: 3 - dim: [[1, n_k], [2, n_j], [3, n_i]] - real(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Real part of the image intensity per point. - dimensions: - rank: 3 - dim: [[1, n_k], [2, n_j], [3, n_i]] - imag(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Imaginary part of the image intensity per point. - dimensions: - rank: 3 - dim: [[1, n_k], [2, n_j], [3, n_i]] - complex(NX_COMPLEX): - unit: NX_UNITLESS - doc: | - Image intensity as a complex number as an alternative to real and - imaginary fields if values are stored as interleaved complex numbers. - dimensions: - rank: 3 - dim: [[1, n_k], [2, n_j], [3, n_i]] - axis_k(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the slow dimension. - dimensions: - rank: 1 - dim: [[1, n_k]] - \@long_name: - type: NX_CHAR - doc: | - Point coordinate along the slow dimension. - axis_j(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the fast dimension. - dimensions: - rank: 1 - dim: [[1, n_j]] - \@long_name: - type: NX_CHAR - doc: | - Point coordinate along the fast dimension. - axis_i(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the fastest dimension. - dimensions: - rank: 1 - dim: [[1, n_i]] - \@long_name: - type: NX_CHAR - doc: | - Point coordinate along the fastest dimension. - stack_1d(NXdata): - doc: | - Collection of image_1d. - intensity(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Intensity for real-valued images as an alternative for real. - Magnitude of the image intensity for complex-valued data. - dimensions: - rank: 2 - dim: [[1, n_img], [2, n_i]] - real(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Real part of the image intensity per point. - dimensions: - rank: 2 - dim: [[1, n_img], [2, n_i]] - imag(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Imaginary part of the image intensity per point. - dimensions: - rank: 2 - dim: [[1, n_img], [2, n_i]] - complex(NX_COMPLEX): - unit: NX_UNITLESS - doc: | - Image intensity as a complex number as an alternative to real and - imaginary fields if values are stored as interleaved complex numbers. - dimensions: - rank: 2 - dim: [[1, n_img], [2, n_i]] - group_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Group identifier - dimensions: - rank: 1 - dim: [[1, n_img]] - \@long_name: - type: NX_CHAR - doc: | - Group identifier - image_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Image identifier - dimensions: - rank: 1 - dim: [[1, n_img]] - \@long_name: - type: NX_CHAR - doc: | - Image identifier - axis_i(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the fastest dimension. - dimensions: - rank: 1 - dim: [[1, n_i]] - \@long_name: - type: NX_CHAR - doc: | - Point coordinate along the fastest dimension. - stack_2d(NXdata): - doc: | - Collection of two-dimensional images. - intensity(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Intensity for real-valued images as an alternative for real. - Magnitude of the image intensity for complex-valued data. - dimensions: - rank: 3 - dim: [[1, n_img], [2, n_j], [3, n_i]] - real(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Real part of the image intensity per point. - dimensions: - rank: 3 - dim: [[1, n_img], [2, n_j], [3, n_i]] - imag(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Imaginary part of the image intensity per point. - dimensions: - rank: 3 - dim: [[1, n_img], [2, n_j], [3, n_i]] - complex(NX_COMPLEX): - unit: NX_UNITLESS - doc: | - Image intensity as a complex number as an alternative to real and - imaginary fields if values are stored as interleaved complex numbers. - dimensions: - rank: 3 - dim: [[1, n_img], [2, n_j], [3, n_i]] - group_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Group identifier - dimensions: - rank: 1 - dim: [[1, n_img]] - \@long_name: - type: NX_CHAR - doc: | - Group identifier - image_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Image identifier - dimensions: - rank: 1 - dim: [[1, n_img]] - \@long_name: - type: NX_CHAR - doc: | - Image identifier. - axis_j(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the fast dimension. - dimensions: - rank: 1 - dim: [[1, n_j]] - \@long_name: - type: NX_CHAR - doc: | - Point coordinate along the fast dimension. - axis_i(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the fastest dimension. - dimensions: - rank: 1 - dim: [[1, n_i]] - \@long_name: - type: NX_CHAR - doc: | - Point coordinate along the fastest dimension. - stack_3d(NXdata): - doc: | - Collection of three-dimensional images. - intensity(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Intensity for real-valued images as an alternative for real. - Magnitude of the image intensity for complex-valued data. - dimensions: - rank: 4 - dim: [[1, n_img], [2, n_k], [3, n_j], [4, n_i]] - real(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Real part of the image intensity per point. - dimensions: - rank: 4 - dim: [[1, n_img], [2, n_k], [3, n_j], [4, n_i]] - imag(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Imaginary part of the image intensity per point. - dimensions: - rank: 4 - dim: [[1, n_img], [2, n_k], [3, n_j], [4, n_i]] - complex(NX_COMPLEX): - unit: NX_UNITLESS - doc: | - Image intensity as a complex number as an alternative to real and - imaginary fields if values are stored as interleaved complex numbers. - dimensions: - rank: 4 - dim: [[1, n_img], [2, n_k], [3, n_j], [4, n_i]] - group_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Group identifier - dimensions: - rank: 1 - dim: [[1, n_img]] - \@long_name: - type: NX_CHAR - doc: | - Group identifier - image_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Image identifier - dimensions: - rank: 1 - dim: [[1, n_img]] - \@long_name: - type: NX_CHAR - doc: | - Image identifier - axis_k(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the slow dimension. - dimensions: - rank: 1 - dim: [[1, n_k]] - \@long_name: - type: NX_CHAR - doc: | - Point coordinate along the slow dimension. - axis_j(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the fast dimension. - dimensions: - rank: 1 - dim: [[1, n_j]] - \@long_name: - type: NX_CHAR - doc: | - Point coordinate along the fast dimension. - axis_i(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the fastest dimension. - dimensions: - rank: 1 - dim: [[1, n_i]] - \@long_name: - type: NX_CHAR - doc: | - Point coordinate along the fastest dimension. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 515133277716bfdfdb8e4b620051a8af15f9130855a29198286adc393185c69f -# -# -# -# -# -# -# -# -# -# Number of images in the stack, for stacks the slowest dimension. -# -# -# -# -# Number of image points along the slow dimension (k equivalent to z). -# -# -# -# -# Number of image points along the fast dimension (j equivalent to y). -# -# -# -# -# Number of image points along the fastest dimension (i equivalent to x). -# -# -# -# -# Base class for reporting a set of images. -# -# The mostly commonly used scanning methods are supported. That is one-, -# two-, three-dimensional ROIs discretized using regular Euclidean tilings. -# -# Colloquially, an image is understood as a discretized representation of intensity distribution -# that was detected or simulated for some ROI. When discretized with regular Euclidean tilings -# the terms pixel and voxel identify the smallest discretization unit. Pixel and voxel are polygonal -# or polyhedral unit cells respectively of the underlying tiling of the ROI within the reference space. -# For all other tilings e.g. non-equispaced, the shape and size of pixel and voxel differs. Using the term -# (image) point is eventually is more appropriate for such tilings. Therefore, all docstrings in this base class -# refer to points (including pixel and voxel i.e. regular tilings). -# -# Point coordinates identify the location of the barycentre. -# -# For images in reciprocal space in practice, complex numbers are encoded via some -# formatted pair of real values. Typically, fast algorithms for computing Fourier transformations -# (FFT) are used to encode images in reciprocal (frequency) space. FFT libraries are used -# for implementing the key functionalities of these mathematical operations. -# -# Different libraries use different representations and encoding of the images. -# Details can be found in the respective sections of the typical FFT libraries documentations -# -# * `FFTW by M. Frigo and S. G. Johnson <https://www.fftw.org/fftw3_doc/Tutorial.html#Tutorial>`_ -# * `Intel MKL by the Intel Co. <https://www.intel.com/content/www/us/en/docs/onemkl/developer-reference-c/2024-2/fourier-transform-functions.html>`_ -# * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ -# * `NFFT by the Chemnitz group <https://www-user.tu-chemnitz.de/~potts/nfft/>`_ for non-equispaced computations -# -# Users are strongly advised to inspect carefully which specific conventions their library uses -# to enable storing and modifying the implementation of their code such that the serialized -# representations as they are detailed here for NeXus match. -# -# It is often the case that several images are combined using processing. In this case, -# the number of images which are combined in a collection is not necessarily the same -# for each collection. The NXimage_set base class addresses this logical distinction -# through the notation of image_identifier and group_identifier concepts. -# That is image_identifier are always counting from offset in increments of one. -# as each image is its own entity. By contrast, a group may contain no, or several images. -# Consequently, group_identifier are not required to be contiguous. -# -# -# -# Details how NXdata instance were processed from detector readings/raw data. -# -# -# -# Resolvable data artifact (e.g. file) from which all values in the :ref:`NXdata` -# instances in this :ref:`NXimage_set` were loaded during parsing. -# -# Possibility to document from which specific other serialized resource as the source -# pieces of information were processed when using NeXus as a semantic file format -# to serialize that information differently. -# -# The group in combination with an added field *absolute_path* therein adds context. -# -# -# -# Reference to a location inside the artifact that points to the specific group of values -# that were processed if the artifacts contains several groups of values and thus -# further resolving of ambiguities is required. -# -# -# -# -# -# -# Link or name of an :ref:`NXdetector` instance with which the data were -# collected. -# -# -# -# -# Program used for processing. -# -# -# -# -# -# -# One-dimensional image. -# -# -# -# Intensity for real-valued images as an alternative for real. -# Magnitude of the image intensity for complex-valued data. -# -# -# -# -# -# -# -# Real part of the image intensity per point. -# -# -# -# -# -# -# -# Imaginary part of the image intensity per point. -# -# -# -# -# -# -# -# Image intensity as a complex number as an alternative to real and -# imaginary fields if values are stored as interleaved complex numbers. -# -# -# -# -# -# -# -# Point coordinate along the fastest dimension. -# -# -# -# -# -# -# Point coordinate along the fastest dimension. -# -# -# -# -# -# -# Two-dimensional image. -# -# -# -# Intensity for real-valued images as an alternative for real. -# Magnitude of the image intensity for complex-valued data. -# -# -# -# -# -# -# -# -# Real part of the image intensity per point. -# -# -# -# -# -# -# -# -# Imaginary part of the image intensity per point. -# -# -# -# -# -# -# -# -# Image intensity as a complex number as an alternative to real and -# imaginary fields if values are stored as interleaved complex numbers. -# -# -# -# -# -# -# -# -# Point coordinate along the fast dimension. -# -# -# -# -# -# -# Point coordinate along the fast dimension. -# -# -# -# -# -# Point coordinate along the fastest dimension. -# -# -# -# -# -# -# Point coordinate along the fastest dimension. -# -# -# -# -# -# -# Three-dimensional image. -# -# -# -# Intensity for real-valued images as an alternative for real. -# Magnitude of the image intensity for complex-valued data. -# -# -# -# -# -# -# -# -# -# Real part of the image intensity per point. -# -# -# -# -# -# -# -# -# -# Imaginary part of the image intensity per point. -# -# -# -# -# -# -# -# -# -# Image intensity as a complex number as an alternative to real and -# imaginary fields if values are stored as interleaved complex numbers. -# -# -# -# -# -# -# -# -# -# Point coordinate along the slow dimension. -# -# -# -# -# -# -# Point coordinate along the slow dimension. -# -# -# -# -# -# Point coordinate along the fast dimension. -# -# -# -# -# -# -# Point coordinate along the fast dimension. -# -# -# -# -# -# Point coordinate along the fastest dimension. -# -# -# -# -# -# -# Point coordinate along the fastest dimension. -# -# -# -# -# -# -# Collection of image_1d. -# -# -# -# Intensity for real-valued images as an alternative for real. -# Magnitude of the image intensity for complex-valued data. -# -# -# -# -# -# -# -# -# Real part of the image intensity per point. -# -# -# -# -# -# -# -# -# Imaginary part of the image intensity per point. -# -# -# -# -# -# -# -# -# Image intensity as a complex number as an alternative to real and -# imaginary fields if values are stored as interleaved complex numbers. -# -# -# -# -# -# -# -# -# Group identifier -# -# -# -# -# -# -# Group identifier -# -# -# -# -# -# Image identifier -# -# -# -# -# -# -# Image identifier -# -# -# -# -# -# Point coordinate along the fastest dimension. -# -# -# -# -# -# -# Point coordinate along the fastest dimension. -# -# -# -# -# -# -# Collection of two-dimensional images. -# -# -# -# Intensity for real-valued images as an alternative for real. -# Magnitude of the image intensity for complex-valued data. -# -# -# -# -# -# -# -# -# -# Real part of the image intensity per point. -# -# -# -# -# -# -# -# -# -# Imaginary part of the image intensity per point. -# -# -# -# -# -# -# -# -# -# Image intensity as a complex number as an alternative to real and -# imaginary fields if values are stored as interleaved complex numbers. -# -# -# -# -# -# -# -# -# -# Group identifier -# -# -# -# -# -# -# Group identifier -# -# -# -# -# -# Image identifier -# -# -# -# -# -# -# Image identifier. -# -# -# -# -# -# Point coordinate along the fast dimension. -# -# -# -# -# -# -# Point coordinate along the fast dimension. -# -# -# -# -# -# Point coordinate along the fastest dimension. -# -# -# -# -# -# -# Point coordinate along the fastest dimension. -# -# -# -# -# -# -# Collection of three-dimensional images. -# -# -# -# Intensity for real-valued images as an alternative for real. -# Magnitude of the image intensity for complex-valued data. -# -# -# -# -# -# -# -# -# -# -# Real part of the image intensity per point. -# -# -# -# -# -# -# -# -# -# -# Imaginary part of the image intensity per point. -# -# -# -# -# -# -# -# -# -# -# Image intensity as a complex number as an alternative to real and -# imaginary fields if values are stored as interleaved complex numbers. -# -# -# -# -# -# -# -# -# -# -# Group identifier -# -# -# -# -# -# -# Group identifier -# -# -# -# -# -# Image identifier -# -# -# -# -# -# -# Image identifier -# -# -# -# -# -# Point coordinate along the slow dimension. -# -# -# -# -# -# -# Point coordinate along the slow dimension. -# -# -# -# -# -# Point coordinate along the fast dimension. -# -# -# -# -# -# -# Point coordinate along the fast dimension. -# -# -# -# -# -# Point coordinate along the fastest dimension. -# -# -# -# -# -# -# Point coordinate along the fastest dimension. -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXinteraction_vol_em.yaml b/contributed_definitions/nyaml/NXinteraction_vol_em.yaml deleted file mode 100644 index 1654ff83ce..0000000000 --- a/contributed_definitions/nyaml/NXinteraction_vol_em.yaml +++ /dev/null @@ -1,94 +0,0 @@ -category: base -doc: | - Base class for describing the interaction volume of particle-matter interaction. - - Computer models like Monte Carlo or molecular dynamics / electron- or ion-beam - interaction simulations can be used to qualify and (or) quantify the shape of - the interaction volume. Results of such simulations can be summary statistics - or single-particle resolved sets of trajectories. - - Explicit or implicit descriptions are possible. - - * An implicit description is via a set of electron/specimen interactions - represented ideally as trajectory data from the computer simulation. - * An explicit description is via an iso-contour surface using either - a simulation grid or a triangulated surface mesh of the approximated - iso-contour surface evaluated at specific threshold values. - Iso-contours could be computed from electron or particle fluxes through - an imaginary control surface (the iso-surface). - Threshold values can be defined by particles passing through a unit control - volume (electrons) or energy-levels (e.g. the case of X-rays). - Details depend on the model. - * Another explicit description is via theoretical models which may - be relevant e.g. for X-ray spectroscopy - - Further details on how the interaction volume can be quantified - is available in the literature for example: - - * `S. Richter et al. `_ - * `J. Bünger et al. `_ - * `J. F. Ziegler et al. `_ -type: group -NXinteraction_vol_em(NXobject): - (NXdata): - (NXprocess): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8ebfe20f6528a3e617dfdcec2c4386785e4f938b154418fb2d117fe09bc2cd2f -# -# -# -# -# -# Base class for describing the interaction volume of particle-matter interaction. -# -# Computer models like Monte Carlo or molecular dynamics / electron- or ion-beam -# interaction simulations can be used to qualify and (or) quantify the shape of -# the interaction volume. Results of such simulations can be summary statistics -# or single-particle resolved sets of trajectories. -# -# Explicit or implicit descriptions are possible. -# -# * An implicit description is via a set of electron/specimen interactions -# represented ideally as trajectory data from the computer simulation. -# * An explicit description is via an iso-contour surface using either -# a simulation grid or a triangulated surface mesh of the approximated -# iso-contour surface evaluated at specific threshold values. -# Iso-contours could be computed from electron or particle fluxes through -# an imaginary control surface (the iso-surface). -# Threshold values can be defined by particles passing through a unit control -# volume (electrons) or energy-levels (e.g. the case of X-rays). -# Details depend on the model. -# * Another explicit description is via theoretical models which may -# be relevant e.g. for X-ray spectroscopy -# -# Further details on how the interaction volume can be quantified -# is available in the literature for example: -# -# * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ -# * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ -# * `J. F. Ziegler et al. <https://doi.org/10.1007/978-3-642-68779-2_5>`_ -# -# -# -# diff --git a/contributed_definitions/nyaml/NXion.yaml b/contributed_definitions/nyaml/NXion.yaml deleted file mode 100644 index e6a036f64d..0000000000 --- a/contributed_definitions/nyaml/NXion.yaml +++ /dev/null @@ -1,272 +0,0 @@ -category: base -doc: | - Base class for documenting the set of atoms of a (molecular) ion. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_ivec_max: | - Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). - n_ranges: | - Number of mass-to-charge-state-ratio range intervals for ion type. -type: group -NXion(NXobject): - identifier(NX_CHAR): - doc: | - A unique identifier whereby such an ion can be referred to - via the service offered as described in identifier_type. - identifier_type(NX_CHAR): - doc: | - How can the identifier be resolved? - enumeration: [inchi] - ion_type(NX_UINT): - unit: NX_UNITLESS - doc: | - Ion type (ion species) identifier. - - The identifier zero is reserved for the special unknown ion type. - nuclide_hash(NX_UINT): - unit: NX_UNITLESS - doc: | - Vector of nuclide hash values. - - Individual hash values :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` - encode the number of protons :math:`Z` and the number of neutrons :math:`N` - of each nuclide respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. - - The array is sorted in decreasing order. For the rationale behind this see `M. Kühbach et al. (2021) `_ - dimensions: - rank: 1 - dim: [[1, n_ivec_max]] - nuclide_list(NX_UINT): - unit: NX_UNITLESS - doc: | - Table which decodes the entries in nuclide_hash into a human-readable matrix of instances. - The first column specifies the nuclide mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N` or 0. The value 0 documents that no - isotope-specific information about the element encoded is relevant. - The second row specifies the number of protons :math:`Z` or 0. - The value 0 in this case documents a placeholder or that no element-specific - information is relevant. - Taking a carbon-14 nuclide as an example the mass number is 14. - That is encoded as a value pair (14, 6) as one row of the table. - - Therefore, this notation is the typical superscribed nuclide mass number - and subscripted number of protons element notation e.g. :math:`^{14}C`. - The array is stored matching the order of nuclide_hash. - dimensions: - rank: 2 - dim: [[1, n_ivecmax], [2, 2]] - - # color(NX_CHAR): - # doc: | - # Color code used for visualizing such ions. - volume(NX_NUMBER): - unit: NX_VOLUME - doc: | - Assumed volume of the ion. - - In atom probe microscopy this field can be used to store the reconstructed - volume per ion (average) which is typically stored alongside ranging - definitions. - charge(NX_NUMBER): - unit: NX_CHARGE - doc: | - Charge of the ion. - charge_state(NX_INT): - unit: NX_UNITLESS - doc: | - Signed charge state of the ion in multiples of electron charge. - - In the example of atom probe microscopy, only positive values will be measured - as the ions are accelerated by a negatively signed bias electric field. - In the case that the charge state is not explicitly recoverable, the value should - be set to zero. - - In atom probe microscopy this is for example the case when using - classical ranging definition files in formats like RNG, RRNG. - These file formats do not document the charge state explicitly - but the number of atoms of each element per molecular ion - surplus the mass-to-charge-state-ratio interval. - Details on ranging definition files can be found in the literature: - `M. K. Miller `_ - name(NX_CHAR): - doc: | - Human-readable ion type name (e.g. Al +++) - The string should consists of UTF-8 characters, ideally using LaTeX - notation to specify the isotopes, ions, and charge state. - Examples are 12C + or Al +++. - - To ease automated parsing, isotope_vector should be the - preferred machine-readable information used. - mass_to_charge_range(NX_NUMBER): - unit: NX_ANY - doc: | - Associated lower (mqmin) and upper (mqmax) bounds of the - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries inclusive). This field is primarily of interest - for documenting :ref:`NXprocess` steps of indexing a - ToF/mass-to-charge state histogram. - dimensions: - rank: 2 - dim: [[1, n_ranges], [2, 2]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 93c7e1e4f06a32516be5fddd8175154e1e180f664bc5ebb724f6586114ea7fb3 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). -# -# -# -# -# Number of mass-to-charge-state-ratio range intervals for ion type. -# -# -# -# -# Base class for documenting the set of atoms of a (molecular) ion. -# -# -# -# A unique identifier whereby such an ion can be referred to -# via the service offered as described in identifier_type. -# -# -# -# -# How can the identifier be resolved? -# -# -# -# -# -# -# -# Ion type (ion species) identifier. -# -# The identifier zero is reserved for the special unknown ion type. -# -# -# -# -# Vector of nuclide hash values. -# -# Individual hash values :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` -# encode the number of protons :math:`Z` and the number of neutrons :math:`N` -# of each nuclide respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. -# -# The array is sorted in decreasing order. For the rationale behind this see `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ -# -# -# -# -# -# -# -# Table which decodes the entries in nuclide_hash into a human-readable matrix of instances. -# The first column specifies the nuclide mass number, i.e. using the hashvalues -# from the isotope_vector this is :math:`Z + N` or 0. The value 0 documents that no -# isotope-specific information about the element encoded is relevant. -# The second row specifies the number of protons :math:`Z` or 0. -# The value 0 in this case documents a placeholder or that no element-specific -# information is relevant. -# Taking a carbon-14 nuclide as an example the mass number is 14. -# That is encoded as a value pair (14, 6) as one row of the table. -# -# Therefore, this notation is the typical superscribed nuclide mass number -# and subscripted number of protons element notation e.g. :math:`^{14}C`. -# The array is stored matching the order of nuclide_hash. -# -# -# -# -# -# -# -# -# -# Assumed volume of the ion. -# -# In atom probe microscopy this field can be used to store the reconstructed -# volume per ion (average) which is typically stored alongside ranging -# definitions. -# -# -# -# -# Charge of the ion. -# -# -# -# -# Signed charge state of the ion in multiples of electron charge. -# -# In the example of atom probe microscopy, only positive values will be measured -# as the ions are accelerated by a negatively signed bias electric field. -# In the case that the charge state is not explicitly recoverable, the value should -# be set to zero. -# -# In atom probe microscopy this is for example the case when using -# classical ranging definition files in formats like RNG, RRNG. -# These file formats do not document the charge state explicitly -# but the number of atoms of each element per molecular ion -# surplus the mass-to-charge-state-ratio interval. -# Details on ranging definition files can be found in the literature: -# `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ -# -# -# -# -# Human-readable ion type name (e.g. Al +++) -# The string should consists of UTF-8 characters, ideally using LaTeX -# notation to specify the isotopes, ions, and charge state. -# Examples are 12C + or Al +++. -# -# To ease automated parsing, isotope_vector should be the -# preferred machine-readable information used. -# -# -# -# -# Associated lower (mqmin) and upper (mqmax) bounds of the -# mass-to-charge-state ratio interval(s) [mqmin, mqmax] -# (boundaries inclusive). This field is primarily of interest -# for documenting :ref:`NXprocess` steps of indexing a -# ToF/mass-to-charge state histogram. -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXlens_em.yaml b/contributed_definitions/nyaml/NXlens_em.yaml deleted file mode 100644 index 03fa2ac275..0000000000 --- a/contributed_definitions/nyaml/NXlens_em.yaml +++ /dev/null @@ -1,161 +0,0 @@ -category: base -doc: | - Base class for an electro-magnetic lens or a compound lens. - - For :ref:`NXtransformations` the origin of the coordinate system is placed - in the center of the lens (its polepiece, pinhole, or another - point of reference). The origin should be specified in the :ref:`NXtransformations`. - - For details of electro-magnetic lenses in the literature - see e.g. `L. Reimer `_ - -# has_part pole_piece https://purls.helmholtz-metadaten.de/emg/EMG_00000039 - -# more consolidation to harvest from a generic component base class -# with other research fields (MPES, XPS, OPT) could be useful -type: group -NXlens_em(NXcomponent): - - # user perspective - value(NX_NUMBER): - unit: NX_ANY - doc: | - Descriptor for the lens excitation when the exact technical details - are unknown or not directly controllable as the control software of - the microscope does not enable or was not configured to display these - values (for end users). - - Although this value does not document the exact physical voltage or - excitation, it can still give useful context to reproduce the lens - setting, provided a properly working instrument and software sets the lens - into a similar state to the technical level possible when no more - information is available physically or accessible legally. - mode(NX_CHAR): - doc: | - Descriptor for the operation mode of the lens when other details are not - directly controllable as the control software of the microscope - does not enable or is not configured to display these values. - - Like value, the mode can only be interpreted for a specific microscope - but can still be useful to guide users as to how to repeat the measurement. - - # control level perspective - voltage(NX_NUMBER): - unit: NX_VOLTAGE - doc: | - Excitation voltage of the lens. - - For dipoles it is a single number. - For higher order multipoles, it is an array. - current(NX_NUMBER): - unit: NX_CURRENT - doc: | - Excitation current of the lens. - - For dipoles it is a single number. - For higher-order multipoles, it is an array. - - # technical design perspective - type(NX_CHAR): - doc: | - Qualitative type of lens with respect to the number of pole pieces. - enumeration: [single, double, quadrupole, hexapole, octupole, dodecapole] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 7accbc9f802621c2b2305ed6dd51f52c626a7751872bab4eb1e653881a9c1ef8 -# -# -# -# -# -# -# -# Base class for an electro-magnetic lens or a compound lens. -# -# For :ref:`NXtransformations` the origin of the coordinate system is placed -# in the center of the lens (its polepiece, pinhole, or another -# point of reference). The origin should be specified in the :ref:`NXtransformations`. -# -# For details of electro-magnetic lenses in the literature -# see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ -# -# -# -# -# Descriptor for the lens excitation when the exact technical details -# are unknown or not directly controllable as the control software of -# the microscope does not enable or was not configured to display these -# values (for end users). -# -# Although this value does not document the exact physical voltage or -# excitation, it can still give useful context to reproduce the lens -# setting, provided a properly working instrument and software sets the lens -# into a similar state to the technical level possible when no more -# information is available physically or accessible legally. -# -# -# -# -# Descriptor for the operation mode of the lens when other details are not -# directly controllable as the control software of the microscope -# does not enable or is not configured to display these values. -# -# Like value, the mode can only be interpreted for a specific microscope -# but can still be useful to guide users as to how to repeat the measurement. -# -# -# -# -# -# Excitation voltage of the lens. -# -# For dipoles it is a single number. -# For higher order multipoles, it is an array. -# -# -# -# -# Excitation current of the lens. -# -# For dipoles it is a single number. -# For higher-order multipoles, it is an array. -# -# -# -# -# -# Qualitative type of lens with respect to the number of pole pieces. -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXlens_opt.yaml b/contributed_definitions/nyaml/NXlens_opt.yaml deleted file mode 100644 index b116bf70fd..0000000000 --- a/contributed_definitions/nyaml/NXlens_opt.yaml +++ /dev/null @@ -1,326 +0,0 @@ -category: base -doc: | - Description of an optical lens. -symbols: - N_spectrum: | - Size of the wavelength array for which the refractive index of the material - is given. - N_spectrum_coating: | - Size of the wavelength array for which the refractive index of the coating - is given. - N_spectrum_RT: | - Size of the wavelength array for which the reflectance or transmission of - the lens is given. - -# A draft of a new base class describing an optical lens -# (Note: NXlens_em describes an electro-magnetic lens or a compound lens) -type: group -NXlens_opt(NXobject): - type: - doc: | - Type of the lens (e.g. concave, convex etc.). - enumeration: [biconcave, plano-concave, convexo-concave, biconvex, plano-convex, concavo-convex, Fresnel lens, other] - other_type: - doc: | - If you chose 'other' as type specify what it is. - chromatic(NX_BOOLEAN): - doc: | - Is it a chromatic lens? - lens_diameter(NX_NUMBER): - unit: NX_LENGTH - doc: | - Diameter of the lens. - substrate(NXsample): - doc: | - Properties of the substrate material of the lens. If the lens has a - coating specify the coating material and its properties in 'coating'. - substrate_material: - doc: | - Specify the substrate material of the lens. - substrate_thickness(NX_NUMBER): - unit: NX_LENGTH - doc: | - Thickness of the lens substrate at the optical axis. - index_of_refraction(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Complex index of refraction of the lens material. Specify at given - wavelength (or energy, wavenumber etc.) values. - dimensions: - rank: 2 - dim: [[1, 2], [2, N_spectrum]] - COATING(NXsample): - - # Used captial letters for COATING so that more than one can be defined if - # the lens has different coatings on the front and back side. - doc: | - If the lens has a coating describe the material and its properties. - Some basic information can be found e.g. [here] - (https://www.opto-e.com/basics/reflection-transmission-and-coatings). - If the back and front side of the lens are coated with different - materials, use separate COATING(NXsample) fields to describe the coatings - on the front and back side, respectively. For example: - coating_front(NXsample) and coating_back(NXsample). - coating_type: - doc: | - Specify the coating type (e.g. dielectric, anti-reflection (AR), - multilayer coating etc.). - coating_material: - doc: | - Describe the coating material (e.g. MgF2). - coating_thickness(NX_NUMBER): - unit: NX_LENGTH - doc: | - Thickness of the coating. - index_of_refraction_coating(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Complex index of refraction of the coating. Specify at given spectral - values (wavelength, energy, wavenumber etc.). - dimensions: - rank: 2 - dim: [[1, 2], [2, N_spectrum_coating]] - reflectance: - unit: NX_UNITLESS - doc: | - Reflectance of the lens at given spectral values. - dimensions: - rank: 1 - dim: [[1, N_spectrum_RT]] - transmission: - unit: NX_UNITLESS - doc: | - Transmission of the lens at given spectral values. - dimensions: - rank: 1 - dim: [[1, N_spectrum_RT]] - focal_length(NX_NUMBER): - exists: recommended - unit: NX_LENGTH - doc: | - Focal length of the lens on the front side (first value), i.e. where the - beam is incident, and on the back side (second value). - dimensions: - rank: 1 - dim: [[1, 2]] - curvature_radius_FACE(NX_NUMBER): - exists: recommended - unit: NX_LENGTH - doc: | - Curvature radius of the lens. - Instead of 'FACE' in the name of this field, the user is advised to - specify for which surface (e.g. front or back) the curvature is provided: - e.g. curvature_front or curvature_back. The front face is the surface on - which the light beam is incident, while the back face is the one from - which the light beam exits the lens. - Abbe_number(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Abbe number (or V-number) of the lens. - numerical_aperture(NX_NUMBER): - doc: | - The numerical aperture of the used incident light optics. - magnification(NX_FLOAT): - doc: | - - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 6ec96f848f0d15d7c310444c2c0e9e3f9987e7922ec43c98edabd520b08c2a0d -# -# -# -# -# -# -# -# -# Size of the wavelength array for which the refractive index of the material -# is given. -# -# -# -# -# Size of the wavelength array for which the refractive index of the coating -# is given. -# -# -# -# -# Size of the wavelength array for which the reflectance or transmission of -# the lens is given. -# -# -# -# -# Description of an optical lens. -# -# -# -# Type of the lens (e.g. concave, convex etc.). -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If you chose 'other' as type specify what it is. -# -# -# -# -# Is it a chromatic lens? -# -# -# -# -# Diameter of the lens. -# -# -# -# -# Properties of the substrate material of the lens. If the lens has a -# coating specify the coating material and its properties in 'coating'. -# -# -# -# Specify the substrate material of the lens. -# -# -# -# -# Thickness of the lens substrate at the optical axis. -# -# -# -# -# Complex index of refraction of the lens material. Specify at given -# wavelength (or energy, wavenumber etc.) values. -# -# -# -# -# -# -# -# -# -# -# If the lens has a coating describe the material and its properties. -# Some basic information can be found e.g. [here] -# (https://www.opto-e.com/basics/reflection-transmission-and-coatings). -# If the back and front side of the lens are coated with different -# materials, use separate COATING(NXsample) fields to describe the coatings -# on the front and back side, respectively. For example: -# coating_front(NXsample) and coating_back(NXsample). -# -# -# -# Specify the coating type (e.g. dielectric, anti-reflection (AR), -# multilayer coating etc.). -# -# -# -# -# Describe the coating material (e.g. MgF2). -# -# -# -# -# Thickness of the coating. -# -# -# -# -# Complex index of refraction of the coating. Specify at given spectral -# values (wavelength, energy, wavenumber etc.). -# -# -# -# -# -# -# -# -# -# Reflectance of the lens at given spectral values. -# -# -# -# -# -# -# -# Transmission of the lens at given spectral values. -# -# -# -# -# -# -# -# Focal length of the lens on the front side (first value), i.e. where the -# beam is incident, and on the back side (second value). -# -# -# -# -# -# -# -# Curvature radius of the lens. -# Instead of 'FACE' in the name of this field, the user is advised to -# specify for which surface (e.g. front or back) the curvature is provided: -# e.g. curvature_front or curvature_back. The front face is the surface on -# which the light beam is incident, while the back face is the one from -# which the light beam exits the lens. -# -# -# -# -# Abbe number (or V-number) of the lens. -# -# -# -# -# The numerical aperture of the used incident light optics. -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXmanipulator.yaml b/contributed_definitions/nyaml/NXmanipulator.yaml deleted file mode 100644 index 9f39a5b4c9..0000000000 --- a/contributed_definitions/nyaml/NXmanipulator.yaml +++ /dev/null @@ -1,422 +0,0 @@ -category: base -doc: | - Extension of NXpositioner to include fields to describe the use of manipulators - in photoemission experiments. -type: group -NXmanipulator(NXobject): - name(NX_CHAR): - doc: | - Name of the manipulator. - description(NX_CHAR): - doc: | - A description of the manipulator. - type(NX_CHAR): - doc: | - Type of manipulator, Hexapod, Rod, etc. - cryostat(NXactuator): - doc: | - Cryostat for cooling the sample. - physical_quantity: - enumeration: [temperature] - (NXpid): - setpoint(NX_FLOAT): - unit: NX_TEMPERATURE - doc: | - In case of a fixed or averaged cooling temperature, this is the scalar temperature setpoint. - It can also be a 1D array of temperature setpoints (without time stamps). - setpoint_log(NXlog): - value(NX_FLOAT): - unit: NX_TEMPERATURE - doc: | - In the case of an experiment in which the temperature is changed and the setpoints are - recorded with time stamps, this is an array of length m of temperature setpoints. - temperature_sensor(NXsensor): - doc: | - Temperature sensor measuring the sample temperature. - measurement: - enumeration: [temperature] - value(NX_FLOAT): - unit: NX_TEMPERATURE - doc: | - In case of a single or averaged temperature measurement, this is the scalar temperature measured - by the sample temperature sensor. It can also be a 1D array of measured temperatures - (without time stamps). - value_log(NXlog): - value(NX_FLOAT): - unit: NX_TEMPERATURE - doc: | - In the case of an experiment in which the temperature changes and is recorded with time stamps, - this is an array of length m of temperatures. - sample_heater(NXactuator): - doc: | - Device to heat the sample. - physical_quantity: - enumeration: [temperature] - heater_power(NX_FLOAT): - unit: NX_POWER - doc: | - In case of a fixed or averaged heating power, this is the scalar heater power. - It can also be a 1D array of heater powers (without time stamps). - heater_power_log(NXlog): - value(NX_FLOAT): - unit: NX_POWER - doc: | - In the case of an experiment in which the heater power is changed and recorded with time stamps, - this is an array of length m of temperature setpoints. - (NXpid): - setpoint(NX_FLOAT): - unit: NX_TEMPERATURE - doc: | - In case of a fixed or averaged temperature, this is the scalar temperature setpoint. - It can also be a 1D array of temperature setpoints (without time stamps). - setpoint_log(NXlog): - value(NX_FLOAT): - unit: NX_TEMPERATURE - doc: | - In the case of an experiment in which the temperature is changed and the setpoints are - recorded with time stamps, this is an array of length m of temperature setpoints. - drain_current_amperemeter(NXsensor): - doc: | - Amperemeter measuring the drain current of the sample and sample holder. - measurement: - enumeration: [current] - value(NX_FLOAT): - unit: NX_CURRENT - doc: | - In case of a single or averaged drain current measurement, this is the scalar drain current measured between - the sample and sample holder. It can also be an 1D array of measured currents (without time stamps). - value_log(NXlog): - value(NX_FLOAT): - unit: NX_CURRENT - doc: | - In the case of an experiment in which the current changes and is recorded with - time stamps, this is an array of length m of currents. - sample_bias_potentiostat(NXactuator): - doc: | - Actuator applying a voltage to sample and sample holder. - physical_quantity: - enumeration: [voltage] - (NXpid): - setpoint(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - In case of a fixed or averaged applied bias, this is the scalar voltage applied between - sample and sample holder. It can also be an 1D array of voltage setpoints (without time stamps). - setpoint_log(NXlog): - value(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - In the case of an experiment in which the bias is changed and the setpoints are - recorded with time stamps, this is an array of length m of voltage setpoints. - sample_bias_voltmeter(NXsensor): - doc: | - Sensor measuring the voltage applied to sample and sample holder. - measurement: - enumeration: [voltage] - value(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - In case of a single or averaged bias measurement, this is the scalar voltage measured between - sample and sample holder. It can also be an 1D array of measured voltages (without time stamps). - value_log(NXlog): - value(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - In the case of an experiment in which the bias changes and is recorded with - time stamps, this is an array of length m of voltages. - (NXactuator): - doc: | - Any additional actuator on the manipulator used to control an external - condition. - (NXsensor): - doc: | - Any additional sensors on the manipulator used to monitor an external condition. - (NXpositioner): - doc: | - Class to describe the motors that are used in the manipulator - depends_on(NX_CHAR): - doc: | - Refers to the last transformation specifying the positon of the manipulator in - the NXtransformations chain. - (NXtransformations): - doc: | - 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. - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - (NXfabrication): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 1e84ea091f45dce3534d71bb2766b0df2951875fac92d3c255ba90138ece3f05 -# -# -# -# -# -# Extension of NXpositioner to include fields to describe the use of manipulators -# in photoemission experiments. -# -# -# -# Name of the manipulator. -# -# -# -# -# A description of the manipulator. -# -# -# -# -# Type of manipulator, Hexapod, Rod, etc. -# -# -# -# -# Cryostat for cooling the sample. -# -# -# -# -# -# -# -# -# -# In case of a fixed or averaged cooling temperature, this is the scalar temperature setpoint. -# It can also be a 1D array of temperature setpoints (without time stamps). -# -# -# -# -# -# In the case of an experiment in which the temperature is changed and the setpoints are -# recorded with time stamps, this is an array of length m of temperature setpoints. -# -# -# -# -# -# -# -# Temperature sensor measuring the sample temperature. -# -# -# -# -# -# -# -# -# In case of a single or averaged temperature measurement, this is the scalar temperature measured -# by the sample temperature sensor. It can also be a 1D array of measured temperatures -# (without time stamps). -# -# -# -# -# -# In the case of an experiment in which the temperature changes and is recorded with time stamps, -# this is an array of length m of temperatures. -# -# -# -# -# -# -# Device to heat the sample. -# -# -# -# -# -# -# -# -# In case of a fixed or averaged heating power, this is the scalar heater power. -# It can also be a 1D array of heater powers (without time stamps). -# -# -# -# -# -# In the case of an experiment in which the heater power is changed and recorded with time stamps, -# this is an array of length m of temperature setpoints. -# -# -# -# -# -# -# In case of a fixed or averaged temperature, this is the scalar temperature setpoint. -# It can also be a 1D array of temperature setpoints (without time stamps). -# -# -# -# -# -# In the case of an experiment in which the temperature is changed and the setpoints are -# recorded with time stamps, this is an array of length m of temperature setpoints. -# -# -# -# -# -# -# -# Amperemeter measuring the drain current of the sample and sample holder. -# -# -# -# -# -# -# -# -# In case of a single or averaged drain current measurement, this is the scalar drain current measured between -# the sample and sample holder. It can also be an 1D array of measured currents (without time stamps). -# -# -# -# -# -# In the case of an experiment in which the current changes and is recorded with -# time stamps, this is an array of length m of currents. -# -# -# -# -# -# -# Actuator applying a voltage to sample and sample holder. -# -# -# -# -# -# -# -# -# -# In case of a fixed or averaged applied bias, this is the scalar voltage applied between -# sample and sample holder. It can also be an 1D array of voltage setpoints (without time stamps). -# -# -# -# -# -# In the case of an experiment in which the bias is changed and the setpoints are -# recorded with time stamps, this is an array of length m of voltage setpoints. -# -# -# -# -# -# -# -# Sensor measuring the voltage applied to sample and sample holder. -# -# -# -# -# -# -# -# -# In case of a single or averaged bias measurement, this is the scalar voltage measured between -# sample and sample holder. It can also be an 1D array of measured voltages (without time stamps). -# -# -# -# -# -# In the case of an experiment in which the bias changes and is recorded with -# time stamps, this is an array of length m of voltages. -# -# -# -# -# -# -# Any additional actuator on the manipulator used to control an external -# condition. -# -# -# -# -# Any additional sensors on the manipulator used to monitor an external condition. -# -# -# -# -# Class to describe the motors that are used in the manipulator -# -# -# -# -# Refers to the last transformation specifying the positon of the manipulator in -# the NXtransformations chain. -# -# -# -# -# Collection of axis-based translations and rotations to describe the location and -# geometry of the manipulator as a component in the instrument. Conventions from -# the NXtransformations base class are used. In principle, the McStas coordinate -# system is used. The first transformation has to point either to another -# component of the system or . (for pointing to the reference frame) to relate it -# relative to the experimental setup. Typically, the components of a system should -# all be related relative to each other and only one component should relate to -# the reference coordinate system. -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml deleted file mode 100644 index ee9f582364..0000000000 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ /dev/null @@ -1,1742 +0,0 @@ -category: application -doc: | - This is the most general application definition for - photoemission experiments. - - Groups and fields are named according to the - `ISO 18115-1:2023`_ specification as well as the `IUPAC Recommendations 2020`_. - - .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html - .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays - n_transmission_function: | - Number of data points in the transmission function. -type: group -NXmpes(NXobject): - (NXentry): - definition: - \@version: - enumeration: [NXmpes] - title: - start_time(NX_DATE_TIME): - doc: | - Datetime of the start of the measurement. - Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, - otherwise the local time zone is assumed per ISO8601. - end_time(NX_DATE_TIME): - exists: recommended - doc: | - Datetime of the end of the measurement. - Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, - otherwise the local time zone is assumed per ISO8601. - method: - exists: recommended - doc: | - Name of the experimental method. - - If applicable, this name should match the terms given by `Clause 11`_ of - the `ISO 18115-1:2023`_ specification. - - Examples include: - * X-ray photoelectron spectroscopy (XPS) - * angle-resolved X-ray photoelectron spectroscopy (ARXPS) - * ultraviolet photoelectron spectroscopy (UPS) - * angle-resolved photoelectron spectroscopy (ARPES) - * hard X-ray photoemission spectroscopy (HAXPES) - * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) - * photoelectron emission microscopy (PEEM) - * electron spectroscopy for chemical analysis (ESCA) - * time-resolved angle-resolved X-ray photoelectron spectroscopy (trARPES) - * spin-resolved angle-resolved X-ray photoelectron spectroscopy (spin-ARPES) - * momentum microscopy - - .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html - .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 - geometries(NXcoordinate_system_set): - exists: optional - doc: | - Description of one or more coordinate systems that are specific to the setup - and the measurement geometry. - (NXuser): - exists: recommended - doc: | - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - name: - doc: | - Name of the user. - affiliation: - doc: | - Name of the affiliation of the user at the time when the experiment was - performed. - (NXinstrument): - doc: - - | - Description of the photoemission spectrometer and its individual parts. - - | - xref: - spec: ISO 18115-1:2023 - term: 12.58 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 - energy_resolution(NXresolution): - exists: optional - doc: | - Overall energy resolution of the photoemission instrument. - physical_quantity: - enumeration: [energy] - type: - exists: recommended - resolution(NX_FLOAT): - unit: NX_ENERGY - doc: - - | - Minimum distinguishable energy separation in the energy spectra. - - | - xref: - spec: ISO 18115-1:2023 - term: 10.24 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 - relative_resolution(NX_FLOAT): - exists: optional - doc: - - | - Ratio of the energy resolution of the photoemission spectrometer at a specified energy - value to that energy value. - - | - xref: - spec: ISO 18115-1:2023 - term: 10.7 ff. - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 - device_information(NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier(NXidentifier): - exists: recommended - sourceTYPE(NXsource): - exists: recommended - doc: | - A source used to generate a beam. Properties refer strictly to parameters of the - source, not of the output beam. For example, the energy of the source is not the - optical power of the beam, but the energy of the electron beam in a synchrotron - or similar. - - Note that the uppercase notation in sourceTYPE means that multiple sources can - be provided. The uppercase part can be substituted with any string that consists - of alphanumeric characters, including both uppercase and lowercase letters from A to Z - and numerical digits from 0 to 9. For example, in pump-probe experiments, it is possible - to have both a `source_probe` and a `source_pump`. - type: - enumeration: [Synchrotron X-ray Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, UV Plasma Source, Metal Jet X-ray, HHG laser, UV lamp, Monochromatized electron source, other] - type_other: - exists: optional - doc: | - Specification of type, may also go to name. - name: - exists: recommended - probe: - exists: optional - device_information(NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier(NXidentifier): - exists: recommended - associated_beam(NX_CHAR): - doc: | - A reference to a beam emitted by this source. - Should be named with the same appendix, e.g., - for `source_probe` it should refer to `beam_probe`. - - Example: - * /entry/instrument/source_probe = /entry/instrument/beam_probe - beamTYPE(NXbeam): - doc: | - Properties of the photon beam at a given location. - Should be named with the same appendix as sourceTYPE, e.g., - for `source_probe` it should refer to `beam_probe`. - distance(NX_NUMBER): - unit: NX_LENGTH - exists: recommended - doc: | - Distance between the point where the current NXbeam instance is evaluating - the beam properties and the point where the beam interacts with the sample. - For photoemission, the latter is the point where the the centre of the beam - touches the sample surface. - incident_energy(NX_FLOAT): - unit: NX_ENERGY - incident_energy_spread(NX_NUMBER): - exists: recommended - unit: NX_ENERGY - incident_polarization(NX_NUMBER): - exists: recommended - unit: NX_ANY - extent(NX_FLOAT): - exists: recommended - associated_source(NX_CHAR): - exists: recommended - doc: | - The source that emitted this beam. - Should be named with the same appendix, e.g., - for `beam_probe` it should refer to `source_probe`. - This should be specified if an associated source exists. - - Example: - * /entry/instrument/beam_probe = /entry/instrument/source_probe - (NXelectronanalyser): - device_information(NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier(NXidentifier): - exists: recommended - description: - exists: recommended - work_function(NX_FLOAT): - unit: NX_ENERGY - exists: recommended - energy_resolution(NXresolution): - exists: optional - type: - exists: recommended - physical_quantity: - enumeration: [energy] - resolution(NX_FLOAT): - fast_axes: - exists: recommended - slow_axes: - exists: recommended - transmission_function(NXdata): - exists: optional - (NXcollectioncolumn): - scheme: - doc: | - Scheme of the electron collection column. - enumeration: [angular dispersive, spatial dispersive, momentum dispersive, non-dispersive] - lens_mode: - exists: recommended - projection: - exists: recommended - angular_acceptance(NX_FLOAT): - exists: optional - spatial_acceptance(NX_FLOAT): - exists: optional - field_aperture(NXaperture): - exists: optional - doc: | - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - contrast_aperture(NXaperture): - exists: optional - doc: | - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - iris(NXaperture): - exists: optional - doc: | - Size, position and shape of the iris inserted in the column. - - The iris is an aperture in the lens with a variable diameter which can reduce the number of - electrons entering the analyzer. - - To add additional or other slits use the APERTURE group of NXcollectioncolumn. - device_information(NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier(NXidentifier): - exists: recommended - (NXenergydispersion): - scheme: - enumeration: [tof, hemispherical, double hemispherical, cylindrical mirror, display mirror, retarding grid] - pass_energy(NX_FLOAT): - exists: recommended - unit: NX_ENERGY - doc: | - Either `pass_energy` or `drift_energy` must be supplied. `pass_energy` should be used when working - with hemispherical analysers. - drift_energy(NX_FLOAT): - exists: recommended - unit: NX_ENERGY - doc: | - Either `pass_energy` or `drift_energy` must be supplied. `drift_energy` should be used if a TOF is used in the - energy dispersive part of the electron analyzer. - energy_scan_mode: - exists: recommended - entrance_slit(NXaperture): - exists: optional - doc: | - Size, position and shape of the entrance slit in dispersive analyzers. - - To add additional or other slits use the APERTURE group of NXenergydispersion. - exit_slit(NXaperture): - exists: optional - doc: | - Size, position and shape of the exit slit in dispersive analyzers. - - To add additional or other slits use the APERTURE group of NXenergydispersion. - device_information(NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier(NXidentifier): - exists: recommended - (NXdetector): - amplifier_type: - exists: recommended - doc: | - Type of electron amplifier in the first amplification step. - enumeration: [MCP, channeltron] - detector_type: - exists: recommended - doc: | - Description of the detector type. - enumeration: [DLD, Phosphor+CCD, Phosphor+CMOS, ECMOS, Anode, Multi-anode] - device_information(NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier(NXidentifier): - exists: recommended - raw_data(NXdata): - exists: recommended - doc: | - Contains the raw data collected by the detector before calibration. - The data which is considered raw might change from experiment to experiment - due to hardware pre-processing of the data. - This group ideally collects the data with the lowest level of processing - possible. - - Fields should be named according to the following convention: - - - **pixel_x**: Detector pixel in x direction. - - **pixel_y**: Detector pixel in y direction. - - **energy**: (Un)calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). - - **kx**: (Un)calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). - - **ky**: (Un)calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). - - **kz**: (Un)calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). - - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). - Unit category: NX_ANGLE - - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - Unit category: NX_ANGLE - - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) - Unit category: NX_LENGTH - - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - Unit category: NX_LENGTH - - **delay**: Calibrated delay time. Unit category: NX_TIME (s). - - **polarization_angle**: Linear polarization angle of the incoming or - outgoing beam. - Unit category: NX_ANGLE (° or rad) - - **ellipticity**: Ellipticity of the incoming or outgoing beam. - Unit category: NX_ANGLE (° or rad) - - **time_of_flight**: Total time of flight. Unit category: NX_TIME_OF_FLIGHT - - **time_of_flight_adc**: Time-of-flight values, analog-to-digital converted. - - **external_AXIS**: Describes an axis which is coming from outside the detectors scope. - - Note that this list is a glossary with explicitly named axis names, which is only intended to cover the most - common measurement axes and is therefore not complete. It is possible to add axes with other names at any time. - \@signal: - enumeration: [raw] - raw(NX_NUMBER): - doc: | - Raw data before calibration. - (NXmanipulator): - exists: optional - doc: | - Manipulator for positioning of the sample. - temperature_sensor(NXsensor): - exists: recommended - name: - exists: recommended - measurement: - enumeration: [temperature] - type: - exists: optional - value(NX_FLOAT): - sample_heater(NXactuator): - exists: optional - name: - exists: recommended - physical_quantity: - enumeration: [temperature] - type: - exists: optional - heater_power(NX_FLOAT): - (NXpid): - exists: recommended - setpoint(NX_FLOAT): - exists: recommended - cryostat(NXactuator): - exists: optional - name: - exists: recommended - physical_quantity: - enumeration: [temperature] - type: - exists: optional - (NXpid): - setpoint(NX_FLOAT): - exists: recommended - drain_current_amperemeter(NXsensor): - exists: optional - name: - exists: recommended - measurement: - enumeration: [current] - type: - exists: optional - value(NX_FLOAT): - sample_bias_voltmeter(NXsensor): - exists: recommended - name: - exists: recommended - measurement: - enumeration: [voltage] - type: - exists: optional - value(NX_FLOAT): - sample_bias_potentiostat(NXactuator): - exists: recommended - name: - exists: recommended - physical_quantity: - enumeration: [voltage] - type: - exists: optional - (NXpid): - exists: recommended - setpoint(NX_FLOAT): - exists: recommended - device_information(NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier(NXidentifier): - exists: recommended - pressure_gauge(NXsensor): - exists: recommended - doc: | - Device to measure the gas pressure in the instrument. - name: - exists: recommended - measurement: - enumeration: [pressure] - type: - exists: optional - value(NX_FLOAT): - unit: NX_PRESSURE - doc: | - In case of a single or averaged gas pressure measurement, this is the scalar gas pressure. - It can also be an 1D array of measured pressures (without time stamps). - value_log(NXlog): - exists: optional - value(NX_NUMBER): - unit: NX_PRESSURE - doc: | - In the case of an experiment in which the gas pressure changes and is recorded, - this is an array of length m of gas pressures. - flood_gun(NXactuator): - exists: optional - doc: | - Device to bring low-energy electrons to the sample for charge neutralization - name: - exists: recommended - physical_quantity: - enumeration: [current] - type: - exists: optional - current(NX_FLOAT): - exists: recommended - unit: NX_CURRENT - doc: | - In case of a fixed or averaged electron current, this is the scalar current. - It can also be an 1D array of output current (without time stamps). - current_log(NXlog): - exists: optional - value(NX_NUMBER): - unit: NX_CURRENT - doc: | - In the case of an experiment in which the electron current is changed and - recorded with time stamps, this is an array of length m of current setpoints. - history(NXhistory): - exists: optional - doc: | - A set of activities that occurred to the instrument prior to/during the photoemission - experiment, including any activities performed on the individual instrument parts. - This group can be used to describe the preparation of the instrument prior to the - experiment, e.g. the cleaning procedure for a spin filter crystal. - (NXprocess_mpes): - exists: recommended - doc: | - Document an event of data processing, reconstruction, or analysis for this data. - The appropriate axis calibrations for a given experiment should be described using - one or more of the following NXcalibrations. The individual calibrations for a given - `AXISNAME` in `data` should be called `AXISNAME_calibration`. - energy_calibration(NXcalibration): - exists: optional - calibrated_axis(NX_FLOAT): - exists: recommended - kN_calibration(NXcalibration): - exists: optional - calibrated_axis(NX_FLOAT): - exists: recommended - angularN_calibration(NXcalibration): - exists: optional - calibrated_axis(NX_FLOAT): - exists: recommended - spatialN_calibration(NXcalibration): - exists: optional - calibrated_axis(NX_FLOAT): - exists: recommended - delay_calibration(NXcalibration): - exists: optional - calibrated_axis(NX_FLOAT): - exists: recommended - polarization_angle_calibration(NXcalibration): - exists: optional - calibrated_axis(NX_FLOAT): - exists: recommended - ellipticity_calibration(NXcalibration): - exists: optional - calibrated_axis(NX_FLOAT): - exists: recommended - energy_referencing(NXcalibration): - exists: optional - level(NXelectron_level): - exists: recommended - reference_peak: - binding_energy(NX_FLOAT): - unit: NX_ENERGY - exists: recommended - offset(NX_FLOAT): - unit: NX_ENERGY - exists: recommended - calibrated_axis(NX_FLOAT): - unit: NX_ENERGY - exists: recommended - transmission_correction(NXcalibration): - exists: optional - transmission_function(NXdata): - exists: recommended - \@signal: - \@axes: - kinetic_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - Kinetic energy values - dimensions: - rank: 1 - dim: [[1, n_transmission_function]] - relative_intensity(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Relative transmission efficiency for the given kinetic energies - dimensions: - rank: 1 - dim: [[1, n_transmission_function]] - (NXsample): - name: - identifier(NXidentifier): - exists: recommended - (NXsubstance): - exists: recommended - doc: | - For samples containing a single pure substance. For mixtures use the - NXsample_component_set and NXsample_component group in NXsample instead. - molecular_formula_hill: - exists: recommended - doc: | - The chemical formula of the sample (using CIF conventions). - atom_types: - exists: recommended - 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`. - physical_form: - exists: recommended - situation: - exists: recommended - enumeration: [vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere] - history(NXhistory): - exists: recommended - doc: | - A set of activities that occurred to the sample prior to/during photoemission - experiment. - sample_preparation(NXphysical_process): - exists: recommended - doc: | - Details about the sample preparation for the photoemission experiment (e.g. UHV cleaving, - in-situ growth, sputtering/annealing, etc.). - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - exists: recommended - method: - exists: recommended - doc: | - Details about the method of sample preparation before the photoemission - experiment. - temperature_env(NXenvironment): - exists: recommended - doc: | - Sample temperature (either controlled or just measured) and actuators/sensors - controlling/measuring it. - temperature_sensor(NXsensor): - exists: recommended - doc: | - Temperature sensor measuring the sample temperature. - - In most cases, this can be a link to /entry/instrument/manipulator/temperature_sensor - if a manipulator is present in the instrument. - sample_heater(NXactuator): - exists: optional - doc: | - Device to heat the sample. - - In most cases, this can be a link to /entry/instrument/manipulator/sample_heater - if a manipulator is present in the instrument. - cryostat(NXactuator): - exists: optional - doc: | - Cryostat for cooling the sample. - - In most cases, this can be a link to /entry/instrument/manipulator/cryostat - if a manipulator is present in the instrument. - value(NX_FLOAT): - exists: optional - unit: NX_TEMPERATURE - doc: | - This is to be used if there is no actuator/sensor that controls/measures - the temperature. - - An example would be a room temperature experiment where the temperature is - not actively measured, but rather estimated. - - Note that this method for recording the temperature is not advised, but using - NXsensor and NXactuator is strongly recommended instead. - gas_pressure_env(NXenvironment): - exists: recommended - doc: | - Gas pressure surrounding the sample and actuators/sensors controlling/measuring - it. - pressure_gauge(NXsensor): - exists: recommended - doc: | - Gauge measuring the gas pressure. - - In most cases, this can be a link to /entry/instrument/pressure_gauge or to another - NXsensor measuring gas pressure (typically, the gauge in closest proximity to the - sample) if such a pressure gauge is present in the instrument. - value(NX_FLOAT): - exists: optional - unit: NX_PRESSURE - doc: | - This is to be used if there is no actuator/sensor that controls/measures - the gas pressure around the sample. An example would be a UHV experiment where the - gas pressure is not monitored. - - Note that this method for recording the gas pressure is not advised, but using - NXsensor and NXactuator is strongly recommended instead. - bias_env(NXenvironment): - exists: recommended - doc: - - | - Bias of the sample with respect to analyser ground and actuators/sensors - controlling/measuring it. - - | - xref: - spec: ISO 18115-1:2023 - term: 8.41 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 - voltmeter(NXsensor): - exists: recommended - doc: | - Sensor measuring the applied voltage. - - In most cases, this can be a link to /entry/instrument/manipulator/sample_bias_voltmeter - if a manipulator is present in the instrument. - potentiostat(NXactuator): - exists: optional - doc: | - Actuator applying a voltage to sample and sample holder. - - In most cases, this can be a link to /entry/instrument/manipulator/sample_bias_potentiostat - if a manipulator is present in the instrument. - value(NX_FLOAT): - exists: optional - unit: NX_VOLTAGE - doc: | - This is to be used if there is no actuator/sensor that controls/measures - the bias. - - Note that this method for recording the bias is not advised, but using - NXsensor and NXactuator is strongly recommended instead. - drain_current_env(NXenvironment): - exists: optional - doc: | - Drain current of the sample and sample holder. - amperemeter(NXsensor): - exists: recommended - doc: | - Amperemeter measuring the drain current of the sample and sample holder. - - In most cases, this can be a link to /entry/instrument/manipulator/drain_current_amperemeter - if a manipulator is present in the instrument. - value(NX_FLOAT): - exists: optional - unit: NX_CURRENT - doc: | - This is to be used if there is no actuator/sensor that controls/measures - the drain current. - - Note that this method for recording the drain current is not advised, but using - NXsensor and NXactuator is strongly recommended instead. - flood_gun_current_env(NXenvironment): - exists: optional - doc: | - Current of low-energy electrons to the sample (for charge neutralization) and - actuators/sensors controlling/measuring it. - flood_gun(NXactuator): - exists: recommended - doc: | - Flood gun creating a current of low-energy electrons. - - In most cases this can be a link to /entry/instrument/flood_gun - if a flood_gun is present in the instrument. - value(NX_FLOAT): - exists: optional - unit: NX_CURRENT - doc: | - This is to be used if there is no actuator/sensor that controls/measures - the drain_current. - - Note that this method for recording the flood gun current is not advised, but using - NXsensor and NXactuator is strongly recommended instead. - data(NXdata): - doc: | - The default NXdata group containing a view on the measured data. - This NXdata group contains a collection of the main relevant fields (axes). - If you want to provide additional views on your data, you can additionally use - the generic NXdata group of NXentry. - - In NXmpes, it is recommended to provide an energy axis. - - Fields should be named according to the following convention: - - - **energy**: Calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). - - **kx**: Calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). - - **ky**: Calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). - - **kz**: Calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). - - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). - Unit category: NX_ANGLE - - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - Unit category: NX_ANGLE - - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) - Unit category: NX_LENGTH - - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - Unit category: NX_LENGTH - - **delay**: Calibrated delay time. Unit category: NX_TIME (s). - - **polarization_angle**: Linear polarization angle of the incoming or - outgoing beam. This could be a link to - /entry/instrument/beam/incident_polarization_angle or - /entry/instrument/beam/final_polarization_angle if they exist. - Unit category: NX_ANGLE (° or rad) - - **ellipticity**: Ellipticity of the incoming or outgoing beam. - Could be a link to /entry/instrument/beam/incident_ellipticity or - /entry/instrument/beam/final_ellipticity if they exist. - Unit category: NX_ANGLE (° or rad) - - Note that this list is a glossary with explicitly named axis names, which is only intended to cover the most - common measurement axes and is therefore not complete. It is possible to add axes with other names at any time. - \@signal: - enumeration: [data] - data(NX_NUMBER): - unit: NX_ANY - doc: | - 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. - energy(NX_NUMBER): - unit: NX_ENERGY - exists: recommended - doc: | - Calibrated energy axis. - - Could be linked from the respective '@reference' field. - \@type: - type: NX_CHAR - doc: | - The energy can be either stored as kinetic or as binding energy. - enumeration: - kinetic: - doc: - - | - Calibrated kinetic energy axis. - - | - In case the kinetic energy axis is referenced to the Fermi level :math:`E_F` - (e.g., in entry/process/energy_referencing), kinetic energies :math:`E` are - provided as :math:`E-E_F`. - - | - xref: - spec: ISO 18115-1:2023 - term: 3.35 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 - binding: - doc: - - | - Calibrated binding energy axis. - - | - xref: - spec: ISO 18115-1:2023 - term: 12.16 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - \@reference: - type: NX_CHAR - exists: recommended - doc: | - The energy can be dispersed according to different strategies. ``@reference`` points to - the path of a field defining the calibrated axis which the ``energy`` axis refers. - - For example: - @reference: 'entry/process/energy_calibration/calibrated_axis' - \@energy_indices: - exists: recommended - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# adc1fee75c052527de27c89790a9bc29359665b4d9b62ad6a40e9a489845d804 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays -# -# -# -# Number of data points in the transmission function. -# -# -# -# -# This is the most general application definition for -# photoemission experiments. -# -# Groups and fields are named according to the -# `ISO 18115-1:2023`_ specification as well as the `IUPAC Recommendations 2020`_. -# -# .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html -# .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 -# -# -# -# -# -# -# -# -# -# -# -# Datetime of the start of the measurement. -# Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, -# otherwise the local time zone is assumed per ISO8601. -# -# -# -# -# Datetime of the end of the measurement. -# Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, -# otherwise the local time zone is assumed per ISO8601. -# -# -# -# -# Name of the experimental method. -# -# If applicable, this name should match the terms given by `Clause 11`_ of -# the `ISO 18115-1:2023`_ specification. -# -# Examples include: -# * X-ray photoelectron spectroscopy (XPS) -# * angle-resolved X-ray photoelectron spectroscopy (ARXPS) -# * ultraviolet photoelectron spectroscopy (UPS) -# * angle-resolved photoelectron spectroscopy (ARPES) -# * hard X-ray photoemission spectroscopy (HAXPES) -# * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) -# * photoelectron emission microscopy (PEEM) -# * electron spectroscopy for chemical analysis (ESCA) -# * time-resolved angle-resolved X-ray photoelectron spectroscopy (trARPES) -# * spin-resolved angle-resolved X-ray photoelectron spectroscopy (spin-ARPES) -# * momentum microscopy -# -# .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html -# .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 -# -# -# -# -# Description of one or more coordinate systems that are specific to the setup -# and the measurement geometry. -# -# -# -# -# Contact information of at least the user of the instrument or the investigator -# who performed this experiment. Adding multiple users if relevant is recommended. -# -# -# -# Name of the user. -# -# -# -# -# Name of the affiliation of the user at the time when the experiment was -# performed. -# -# -# -# -# -# Description of the photoemission spectrometer and its individual parts. -# -# This concept is related to term `12.58`_ of the ISO 18115-1:2023 standard. -# -# .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 -# -# -# -# Overall energy resolution of the photoemission instrument. -# -# -# -# -# -# -# -# -# -# Minimum distinguishable energy separation in the energy spectra. -# -# This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. -# -# .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 -# -# -# -# -# Ratio of the energy resolution of the photoemission spectrometer at a specified energy -# value to that energy value. -# -# This concept is related to term `10.7 ff.`_ of the ISO 18115-1:2023 standard. -# -# .. _10.7 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 -# -# -# -# -# -# -# -# -# -# -# A source used to generate a beam. Properties refer strictly to parameters of the -# source, not of the output beam. For example, the energy of the source is not the -# optical power of the beam, but the energy of the electron beam in a synchrotron -# or similar. -# -# Note that the uppercase notation in sourceTYPE means that multiple sources can -# be provided. The uppercase part can be substituted with any string that consists -# of alphanumeric characters, including both uppercase and lowercase letters from A to Z -# and numerical digits from 0 to 9. For example, in pump-probe experiments, it is possible -# to have both a `source_probe` and a `source_pump`. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Specification of type, may also go to name. -# -# -# -# -# -# -# -# -# -# -# -# A reference to a beam emitted by this source. -# Should be named with the same appendix, e.g., -# for `source_probe` it should refer to `beam_probe`. -# -# Example: -# * /entry/instrument/source_probe = /entry/instrument/beam_probe -# -# -# -# -# -# Properties of the photon beam at a given location. -# Should be named with the same appendix as sourceTYPE, e.g., -# for `source_probe` it should refer to `beam_probe`. -# -# -# -# Distance between the point where the current NXbeam instance is evaluating -# the beam properties and the point where the beam interacts with the sample. -# For photoemission, the latter is the point where the the centre of the beam -# touches the sample surface. -# -# -# -# -# -# -# -# -# The source that emitted this beam. -# Should be named with the same appendix, e.g., -# for `beam_probe` it should refer to `source_probe`. -# This should be specified if an associated source exists. -# -# Example: -# * /entry/instrument/beam_probe = /entry/instrument/source_probe -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Scheme of the electron collection column. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The size and position of the field aperture inserted in the column. To add -# additional or other apertures use the APERTURE group of NXcollectioncolumn. -# -# -# -# -# The size and position of the contrast aperture inserted in the column. To add -# additional or other apertures use the APERTURE group of NXcollectioncolumn. -# -# -# -# -# Size, position and shape of the iris inserted in the column. -# -# The iris is an aperture in the lens with a variable diameter which can reduce the number of -# electrons entering the analyzer. -# -# To add additional or other slits use the APERTURE group of NXcollectioncolumn. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Either `pass_energy` or `drift_energy` must be supplied. `pass_energy` should be used when working -# with hemispherical analysers. -# -# -# -# -# Either `pass_energy` or `drift_energy` must be supplied. `drift_energy` should be used if a TOF is used in the -# energy dispersive part of the electron analyzer. -# -# -# -# -# -# Size, position and shape of the entrance slit in dispersive analyzers. -# -# To add additional or other slits use the APERTURE group of NXenergydispersion. -# -# -# -# -# Size, position and shape of the exit slit in dispersive analyzers. -# -# To add additional or other slits use the APERTURE group of NXenergydispersion. -# -# -# -# -# -# -# -# -# -# -# -# Type of electron amplifier in the first amplification step. -# -# -# -# -# -# -# -# -# Description of the detector type. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Contains the raw data collected by the detector before calibration. -# The data which is considered raw might change from experiment to experiment -# due to hardware pre-processing of the data. -# This group ideally collects the data with the lowest level of processing -# possible. -# -# Fields should be named according to the following convention: -# -# - **pixel_x**: Detector pixel in x direction. -# - **pixel_y**: Detector pixel in y direction. -# - **energy**: (Un)calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). -# - **kx**: (Un)calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). -# - **ky**: (Un)calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). -# - **kz**: (Un)calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). -# - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). -# Unit category: NX_ANGLE -# - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) -# Unit category: NX_ANGLE -# - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) -# Unit category: NX_LENGTH -# - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) -# Unit category: NX_LENGTH -# - **delay**: Calibrated delay time. Unit category: NX_TIME (s). -# - **polarization_angle**: Linear polarization angle of the incoming or -# outgoing beam. -# Unit category: NX_ANGLE (° or rad) -# - **ellipticity**: Ellipticity of the incoming or outgoing beam. -# Unit category: NX_ANGLE (° or rad) -# - **time_of_flight**: Total time of flight. Unit category: NX_TIME_OF_FLIGHT -# - **time_of_flight_adc**: Time-of-flight values, analog-to-digital converted. -# - **external_AXIS**: Describes an axis which is coming from outside the detectors scope. -# -# Note that this list is a glossary with explicitly named axis names, which is only intended to cover the most -# common measurement axes and is therefore not complete. It is possible to add axes with other names at any time. -# -# -# -# -# -# -# -# -# Raw data before calibration. -# -# -# -# -# -# -# -# Manipulator for positioning of the sample. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Device to measure the gas pressure in the instrument. -# -# -# -# -# -# -# -# -# -# -# In case of a single or averaged gas pressure measurement, this is the scalar gas pressure. -# It can also be an 1D array of measured pressures (without time stamps). -# -# -# -# -# -# In the case of an experiment in which the gas pressure changes and is recorded, -# this is an array of length m of gas pressures. -# -# -# -# -# -# -# Device to bring low-energy electrons to the sample for charge neutralization -# -# -# -# -# -# -# -# -# -# -# In case of a fixed or averaged electron current, this is the scalar current. -# It can also be an 1D array of output current (without time stamps). -# -# -# -# -# -# In the case of an experiment in which the electron current is changed and -# recorded with time stamps, this is an array of length m of current setpoints. -# -# -# -# -# -# -# A set of activities that occurred to the instrument prior to/during the photoemission -# experiment, including any activities performed on the individual instrument parts. -# This group can be used to describe the preparation of the instrument prior to the -# experiment, e.g. the cleaning procedure for a spin filter crystal. -# -# -# -# -# -# Document an event of data processing, reconstruction, or analysis for this data. -# The appropriate axis calibrations for a given experiment should be described using -# one or more of the following NXcalibrations. The individual calibrations for a given -# `AXISNAME` in `data` should be called `AXISNAME_calibration`. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Kinetic energy values -# -# -# -# -# -# -# -# Relative transmission efficiency for the given kinetic energies -# -# -# -# -# -# -# -# -# -# -# -# -# -# For samples containing a single pure substance. For mixtures use the -# NXsample_component_set and NXsample_component group in NXsample instead. -# -# -# -# The chemical formula of the sample (using CIF conventions). -# -# -# -# -# -# List of comma-separated elements from the periodic table -# that are contained in the sample. -# If the sample substance has multiple components, all -# elements from each component must be included in `atom_types`. -# -# -# -# -# -# -# -# -# -# -# -# -# -# A set of activities that occurred to the sample prior to/during photoemission -# experiment. -# -# -# -# Details about the sample preparation for the photoemission experiment (e.g. UHV cleaving, -# in-situ growth, sputtering/annealing, etc.). -# -# -# -# -# -# Details about the method of sample preparation before the photoemission -# experiment. -# -# -# -# -# -# -# Sample temperature (either controlled or just measured) and actuators/sensors -# controlling/measuring it. -# -# -# -# Temperature sensor measuring the sample temperature. -# -# In most cases, this can be a link to /entry/instrument/manipulator/temperature_sensor -# if a manipulator is present in the instrument. -# -# -# -# -# Device to heat the sample. -# -# In most cases, this can be a link to /entry/instrument/manipulator/sample_heater -# if a manipulator is present in the instrument. -# -# -# -# -# Cryostat for cooling the sample. -# -# In most cases, this can be a link to /entry/instrument/manipulator/cryostat -# if a manipulator is present in the instrument. -# -# -# -# -# This is to be used if there is no actuator/sensor that controls/measures -# the temperature. -# -# An example would be a room temperature experiment where the temperature is -# not actively measured, but rather estimated. -# -# Note that this method for recording the temperature is not advised, but using -# NXsensor and NXactuator is strongly recommended instead. -# -# -# -# -# -# Gas pressure surrounding the sample and actuators/sensors controlling/measuring -# it. -# -# -# -# Gauge measuring the gas pressure. -# -# In most cases, this can be a link to /entry/instrument/pressure_gauge or to another -# NXsensor measuring gas pressure (typically, the gauge in closest proximity to the -# sample) if such a pressure gauge is present in the instrument. -# -# -# -# -# This is to be used if there is no actuator/sensor that controls/measures -# the gas pressure around the sample. An example would be a UHV experiment where the -# gas pressure is not monitored. -# -# Note that this method for recording the gas pressure is not advised, but using -# NXsensor and NXactuator is strongly recommended instead. -# -# -# -# -# -# Bias of the sample with respect to analyser ground and actuators/sensors -# controlling/measuring it. -# -# This concept is related to term `8.41`_ of the ISO 18115-1:2023 standard. -# -# .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 -# -# -# -# Sensor measuring the applied voltage. -# -# In most cases, this can be a link to /entry/instrument/manipulator/sample_bias_voltmeter -# if a manipulator is present in the instrument. -# -# -# -# -# Actuator applying a voltage to sample and sample holder. -# -# In most cases, this can be a link to /entry/instrument/manipulator/sample_bias_potentiostat -# if a manipulator is present in the instrument. -# -# -# -# -# This is to be used if there is no actuator/sensor that controls/measures -# the bias. -# -# Note that this method for recording the bias is not advised, but using -# NXsensor and NXactuator is strongly recommended instead. -# -# -# -# -# -# Drain current of the sample and sample holder. -# -# -# -# Amperemeter measuring the drain current of the sample and sample holder. -# -# In most cases, this can be a link to /entry/instrument/manipulator/drain_current_amperemeter -# if a manipulator is present in the instrument. -# -# -# -# -# This is to be used if there is no actuator/sensor that controls/measures -# the drain current. -# -# Note that this method for recording the drain current is not advised, but using -# NXsensor and NXactuator is strongly recommended instead. -# -# -# -# -# -# Current of low-energy electrons to the sample (for charge neutralization) and -# actuators/sensors controlling/measuring it. -# -# -# -# Flood gun creating a current of low-energy electrons. -# -# In most cases this can be a link to /entry/instrument/flood_gun -# if a flood_gun is present in the instrument. -# -# -# -# This is to be used if there is no actuator/sensor that controls/measures -# the drain_current. -# -# Note that this method for recording the flood gun current is not advised, but using -# NXsensor and NXactuator is strongly recommended instead. -# -# -# -# -# -# -# -# The default NXdata group containing a view on the measured data. -# This NXdata group contains a collection of the main relevant fields (axes). -# If you want to provide additional views on your data, you can additionally use -# the generic NXdata group of NXentry. -# -# In NXmpes, it is recommended to provide an energy axis. -# -# Fields should be named according to the following convention: -# -# - **energy**: Calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). -# - **kx**: Calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). -# - **ky**: Calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). -# - **kz**: Calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). -# - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). -# Unit category: NX_ANGLE -# - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) -# Unit category: NX_ANGLE -# - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) -# Unit category: NX_LENGTH -# - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) -# Unit category: NX_LENGTH -# - **delay**: Calibrated delay time. Unit category: NX_TIME (s). -# - **polarization_angle**: Linear polarization angle of the incoming or -# outgoing beam. This could be a link to -# /entry/instrument/beam/incident_polarization_angle or -# /entry/instrument/beam/final_polarization_angle if they exist. -# Unit category: NX_ANGLE (° or rad) -# - **ellipticity**: Ellipticity of the incoming or outgoing beam. -# Could be a link to /entry/instrument/beam/incident_ellipticity or -# /entry/instrument/beam/final_ellipticity if they exist. -# Unit category: NX_ANGLE (° or rad) -# -# Note that this list is a glossary with explicitly named axis names, which is only intended to cover the most -# common measurement axes and is therefore not complete. It is possible to add axes with other names at any time. -# -# -# -# -# -# -# -# -# Represents a measure of one- or more-dimensional photoemission counts, where the -# varied axis may be for example energy, momentum, spatial coordinate, pump-probe -# delay, spin index, temperature, etc. The axes traces should be linked to the -# actual encoder position in NXinstrument or calibrated axes in NXprocess. -# -# -# -# -# Calibrated energy axis. -# -# Could be linked from the respective '@reference' field. -# -# -# -# The energy can be either stored as kinetic or as binding energy. -# -# -# -# -# Calibrated kinetic energy axis. -# -# In case the kinetic energy axis is referenced to the Fermi level :math:`E_F` -# (e.g., in entry/process/energy_referencing), kinetic energies :math:`E` are -# provided as :math:`E-E_F`. -# -# This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. -# -# .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 -# -# -# -# -# Calibrated binding energy axis. -# -# This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. -# -# .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 -# -# -# -# -# -# -# The energy can be dispersed according to different strategies. ``@reference`` points to -# the path of a field defining the calibrated axis which the ``energy`` axis refers. -# -# For example: -# @reference: 'entry/process/energy_calibration/calibrated_axis' -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXmpes_arpes.yaml b/contributed_definitions/nyaml/NXmpes_arpes.yaml deleted file mode 100644 index 0e31e529f1..0000000000 --- a/contributed_definitions/nyaml/NXmpes_arpes.yaml +++ /dev/null @@ -1,674 +0,0 @@ -category: application - -# Pincelli, Rettig, Arora at fhi-berlin.mpg.de, Dobener at hu-berlin.de, 06/2022 -# Draft version of a NeXus application definition for angle resolved photoemission. -# This appdef aims to describe data produced from hemispherical analysers, -# with at least an angular coordinate and one energy coordinate. -# It is designed to be extended by other application definitions -# with higher granularity in the data description. -doc: | - This is an general application definition for angle-resolved multidimensional - photoelectron spectroscopy. -type: group -NXmpes_arpes(NXmpes): - (NXentry): - definition: - \@version: - enumeration: [NXmpes_arpes] - geometries(NXcoordinate_system_set): - arpes_geometry(NXcoordinate_system): - depends_on(NX_CHAR): - doc: | - Link to transformations defining an APRES base coordinate system, - which is defined such that the positive z-axis points towards the analyzer entry, - and the x-axis lies within the beam/analyzer plane. - (NXtransformations): - doc: | - Set of transformations, describing the orientation of the ARPES coordinate system - with respect to the beam coordinate system (.). - (NXinstrument): - angularN_resolution(NXresolution): - exists: recommended - doc: | - Overall angular resolution along the Nth angular axis. Create one such entry per relevant angular axis, - corresponding to the angular axes in NXdata. - For hemispherical analyzers, angular0_resolution corresponds to the direction along the analyzer slit, - and angular1_resolution to the one perpendicular to it. - physical_quantity: - enumeration: [angle] - type: - exists: recommended - resolution(NX_FLOAT): - unit: NX_ANGLE - (NXelectronanalyser): - angularN_resolution(NXresolution): - exists: recommended - doc: | - Analyzer angular resolution along the Nth angular axis. - Create one such entry per relevant angular axis, corresponding to the angular axes in NXdata. - For hemispherical analyzers, angular0_resolution corresponds to the direction along the analyzer slit, - and angular1_resolution to the one perpendicular to it. - physical_quantity: - enumeration: [angle] - type: - exists: recommended - resolution(NX_FLOAT): - unit: NX_ANGLE - depends_on(NX_CHAR): - doc: | - Reference to the last transformation describing the orientation of the analyzer relative to the beam, - e.g. transformations/analyzer_elevation. - transformations(NXtransformations): - doc: | - Set of transformations, describing the relative orientation of the analyzer - with respect to the beam coordinate system (.). - analyzer_rotation(NX_NUMBER): - unit: NX_ANGLE - doc: | - Rotation about the analyzer lens axis. - Its zero reference is defined such that the angular0 axis is - increasing towards the positive y axis (analyzer slit vertical). - \@transformation_type: - enumeration: [rotation] - \@vector: - enumeration: [[0, 0, 1]] - \@depends_on: - doc: | - Path to a transformation that places the analyzer origin system into the - arpes_geometry coordinate system. - analyzer_elevation(NX_NUMBER): - unit: NX_ANGLE - doc: | - Elevation of the effective analyzer acceptance area, e.g. realized by - deflectors, or as one angle in a TOF detector. If a resolved angle, place the - calibrated axis coordinates here. - \@transformation_type: - enumeration: [rotation] - \@vector: - enumeration: [[0, 1, 0]] - \@depends_on: - enumeration: [analyzer_dispersion] - analyzer_dispersion(NX_NUMBER): - unit: NX_ANGLE - doc: | - In-plane analyzer coordinate along a dispersive direction, - e.g. along an analyzer slit. If a resolved angle, place the calibrated coordinates here. - \@transformation_type: - enumeration: [rotation] - \@vector: - enumeration: [[1, 0, 0]] - \@depends_on: - enumeration: [analyzer_rotation] - (NXcollectioncolumn): - scheme: - exists: recommended - doc: | - Scheme of the electron collection column. - enumeration: [angular dispersive, non-dispersive] - angular_acceptance(NX_FLOAT): - exists: recommended - (NXenergydispersion): - diameter(NX_NUMBER): - exists: recommended - unit: NX_LENGTH - entrance_slit(NXaperture): - exists: recommended - shape: - enumeration: [straight slit, curved slit] - (NXsample): - situation: - enumeration: [vacuum] - depends_on(NX_CHAR): - doc: | - Reference to the end of the transformation chain, - orienting the sample surface within the arpes_geometry coordinate system - (sample_azimuth or anything depending on it). - transformations(NXtransformations): - doc: | - Set of transformations, describing the relative orientation of the sample - with respect to the arpes_geometry coordinate system. - sample_polar(NX_NUMBER): - unit: NX_ANGLE - doc: | - Rotation about the y axis (typically the long manipulator axis). - \@transformation_type: - enumeration: [rotation] - \@vector: - enumeration: [[0, 1, 0]] - \@depends_on: - doc: | - Path to a transformation that places the sample surface - into the origin of the arpes_geometry coordinate system. - offset_polar(NX_NUMBER): - unit: NX_ANGLE - doc: | - Offset of polar rotation. - \@transformation_type: - enumeration: [rotation] - \@vector: - enumeration: [[0, 1, 0]] - \@depends_on: - enumeration: [sample_polar] - sample_tilt(NX_NUMBER): - unit: NX_ANGLE - doc: | - Rotation about the x axis (typically a manipulator tilt). - \@transformation_type: - enumeration: [rotation] - \@vector: - enumeration: [[1, 0, 0]] - \@depends_on: - enumeration: [offset_polar] - offset_tilt(NX_NUMBER): - unit: NX_ANGLE - doc: | - Offset of tilt rotation. - \@transformation_type: - enumeration: [rotation] - \@vector: - enumeration: [[1, 0, 0]] - \@depends_on: - enumeration: [sample_tilt] - sample_azimuth(NX_NUMBER): - unit: NX_ANGLE - doc: | - Rotation about the z axis (azimuthal rotation within the sample plane). - \@transformation_type: - enumeration: [rotation] - \@vector: - enumeration: [[0, 0, 1]] - \@depends_on: - enumeration: [offset_tilt] - offset_azimuth(NX_NUMBER): - unit: NX_ANGLE - doc: | - Offset of azimuthal rotation. - \@transformation_type: - enumeration: [rotation] - \@vector: - enumeration: [[0, 0, 1]] - \@depends_on: - enumeration: [sample_azimuth] - data(NXdata): - \@signal: - doc: | - There is an object named data that contains the signal. - enumeration: [data] - \@axes: - doc: | - There are three dimensions, one energy and two angular coordinates. Any coordinates that do not move, - are represented by one point. - enumeration: [['angular0', 'angular1', 'energy']] - \@energy_indices: - \@angular0_indices: - \@angular1_indices: - energy(NX_NUMBER): - unit: NX_ENERGY - doc: | - Trace of the energy axis. Could be linked from the respective ``@reference`` - field. - \@reference: - exists: recommended - doc: | - Points to the path of a field defining the calibrated axis which the energy axis refers. - - For example: - @reference: '/entry/instrument/detector/sensor_y' for a 2D detector - @reference: '/entry/instrument/energydispersion/center_kinetic_energy' for a swept scan - @reference: '/entry/process/calibration/energy_calibration/calibrated_axis' for a preprocessed axis. - angular0(NX_NUMBER): - unit: NX_ANGLE - doc: | - Trace of the first angular axis. Could be linked from the respective - ``@reference`` field. - \@reference: - exists: recommended - doc: | - Points to the path of a field defining the calibrated axis which the ``angular0`` axis refers. - - For example: - @reference: '/entry/sample/transformations/sample_tilt' for a manipulator angular scan - @reference: '/entry/instrument/detector/sensor_x' for a 2D detector - @reference: '/entry/instrument/collectioncolumn/deflector' for a deflector scan - @reference: '/entry/process/calibration/angular0_calibration/calibrated_axis' for a preprocessed axis. - angular1(NX_NUMBER): - unit: NX_ANGLE - doc: | - Trace of the second axis. Could be linked from the respective ``@reference`` - field. - \@reference: - exists: recommended - doc: | - Points to the path of a field defining the calibrated axis which the ``angular1`` axis refers. - - For example: - @reference: '/entry/sample/transformations/sample_polar' for a manipulator angular scan - @reference: '/entry/instrument/detector/sensor_y' for a 2D detector - @reference: '/entry/instrument/collectioncolumn/deflector' for a deflector scan - @reference: '/entry/process/calibration/angular1_calibration/calibrated_axis' for a preprocessed axis. - data(NX_NUMBER): - unit: NX_ANY - doc: | - Represents a measure of three-dimensional photoemission counts, where - the varied axes are energy, and one or more angular coordinates. Axes traces - should be linked to the actual encoder position in NXinstrument or calibrated axes in NXprocess. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 3b1e58cabb7b243061af49cd2bc38324b715a2320bab79fc406b3d2c18e4c9d1 -# -# -# -# -# -# -# This is an general application definition for angle-resolved multidimensional -# photoelectron spectroscopy. -# -# -# -# -# -# -# -# -# -# -# -# -# Link to transformations defining an APRES base coordinate system, -# which is defined such that the positive z-axis points towards the analyzer entry, -# and the x-axis lies within the beam/analyzer plane. -# -# -# -# -# Set of transformations, describing the orientation of the ARPES coordinate system -# with respect to the beam coordinate system (.). -# -# -# -# -# -# -# -# Overall angular resolution along the Nth angular axis. Create one such entry per relevant angular axis, -# corresponding to the angular axes in NXdata. -# For hemispherical analyzers, angular0_resolution corresponds to the direction along the analyzer slit, -# and angular1_resolution to the one perpendicular to it. -# -# -# -# -# -# -# -# -# -# -# -# -# Analyzer angular resolution along the Nth angular axis. -# Create one such entry per relevant angular axis, corresponding to the angular axes in NXdata. -# For hemispherical analyzers, angular0_resolution corresponds to the direction along the analyzer slit, -# and angular1_resolution to the one perpendicular to it. -# -# -# -# -# -# -# -# -# -# -# -# Reference to the last transformation describing the orientation of the analyzer relative to the beam, -# e.g. transformations/analyzer_elevation. -# -# -# -# -# Set of transformations, describing the relative orientation of the analyzer -# with respect to the beam coordinate system (.). -# -# -# -# Rotation about the analyzer lens axis. -# Its zero reference is defined such that the angular0 axis is -# increasing towards the positive y axis (analyzer slit vertical). -# -# -# -# -# -# -# -# -# -# -# -# -# -# Path to a transformation that places the analyzer origin system into the -# arpes_geometry coordinate system. -# -# -# -# -# -# Elevation of the effective analyzer acceptance area, e.g. realized by -# deflectors, or as one angle in a TOF detector. If a resolved angle, place the -# calibrated axis coordinates here. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# In-plane analyzer coordinate along a dispersive direction, -# e.g. along an analyzer slit. If a resolved angle, place the calibrated coordinates here. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Scheme of the electron collection column. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Reference to the end of the transformation chain, -# orienting the sample surface within the arpes_geometry coordinate system -# (sample_azimuth or anything depending on it). -# -# -# -# -# Set of transformations, describing the relative orientation of the sample -# with respect to the arpes_geometry coordinate system. -# -# -# -# Rotation about the y axis (typically the long manipulator axis). -# -# -# -# -# -# -# -# -# -# -# -# -# -# Path to a transformation that places the sample surface -# into the origin of the arpes_geometry coordinate system. -# -# -# -# -# -# Offset of polar rotation. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Rotation about the x axis (typically a manipulator tilt). -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Offset of tilt rotation. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Rotation about the z axis (azimuthal rotation within the sample plane). -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Offset of azimuthal rotation. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# There is an object named data that contains the signal. -# -# -# -# -# -# -# -# There are three dimensions, one energy and two angular coordinates. Any coordinates that do not move, -# are represented by one point. -# -# -# -# -# -# -# -# -# -# -# Trace of the energy axis. Could be linked from the respective ``@reference`` -# field. -# -# -# -# Points to the path of a field defining the calibrated axis which the energy axis refers. -# -# For example: -# @reference: '/entry/instrument/detector/sensor_y' for a 2D detector -# @reference: '/entry/instrument/energydispersion/center_kinetic_energy' for a swept scan -# @reference: '/entry/process/calibration/energy_calibration/calibrated_axis' for a preprocessed axis. -# -# -# -# -# -# Trace of the first angular axis. Could be linked from the respective -# ``@reference`` field. -# -# -# -# Points to the path of a field defining the calibrated axis which the ``angular0`` axis refers. -# -# For example: -# @reference: '/entry/sample/transformations/sample_tilt' for a manipulator angular scan -# @reference: '/entry/instrument/detector/sensor_x' for a 2D detector -# @reference: '/entry/instrument/collectioncolumn/deflector' for a deflector scan -# @reference: '/entry/process/calibration/angular0_calibration/calibrated_axis' for a preprocessed axis. -# -# -# -# -# -# Trace of the second axis. Could be linked from the respective ``@reference`` -# field. -# -# -# -# Points to the path of a field defining the calibrated axis which the ``angular1`` axis refers. -# -# For example: -# @reference: '/entry/sample/transformations/sample_polar' for a manipulator angular scan -# @reference: '/entry/instrument/detector/sensor_y' for a 2D detector -# @reference: '/entry/instrument/collectioncolumn/deflector' for a deflector scan -# @reference: '/entry/process/calibration/angular1_calibration/calibrated_axis' for a preprocessed axis. -# -# -# -# -# -# Represents a measure of three-dimensional photoemission counts, where -# the varied axes are energy, and one or more angular coordinates. Axes traces -# should be linked to the actual encoder position in NXinstrument or calibrated axes in NXprocess. -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXopt_window.yaml b/contributed_definitions/nyaml/NXopt_window.yaml deleted file mode 100644 index 7550543cea..0000000000 --- a/contributed_definitions/nyaml/NXopt_window.yaml +++ /dev/null @@ -1,205 +0,0 @@ -category: base -doc: | - A window of a cryostat, heater, vacuum chamber or a simple glass slide. - - This first verion originates from NXopt to describe cryostate windows - and possible influences for ellipsometry measurements. - - For environmental measurements, the environment (liquid, vapor - etc.) is enclosed in a cell, which has windows both in the - direction of the source (entry window) and the detector (exit - window) (looking from the sample). In case that the entry and exit - windows are not the same type and do not have the same properties, - use a second 'WINDOW(NXaperture)' field. - - The windows also add a phase shift to the light altering the - measured signal. This shift has to be corrected based on measuring - a known sample (reference sample) or the actual sample of interest - in the environmental cell. State if a window correction has been - performed in 'window_effects_corrected'. Reference data should be - considered as a separate experiment, and a link to the NeXus file - should be added in reference_data_link in measured_data. - - The window is considered to be a part of the sample stage but also - beam path. Hence, its position within the beam path should be - defined by the 'depends_on' field. - -# A draft of a new base class to describe a window in a optical setup or device -type: group -NXopt_window(NXaperture): - (NXentry): - window_effects_corrected(NX_BOOLEAN): - doc: | - Was a window correction performed? If 'True' describe the window - correction procedure in 'window_correction/procedure'. - window_effects_type: - doc: | - Type of effects due to this window on the measurement. - enumeration: [interference effects, light absorption, light scattering, other] - window_correction(NXprocess): - doc: | - Was a window correction performed? If 'True' describe the - window correction procedure in '' - procedure: - doc: | - Describe when (before or after the main measurement + time - stamp in 'date') and how the window effects have been - corrected, i.e. either mathematically or by performing a - reference measurement. In the latter case, provide the link to - to the reference data in 'reference_data_link'. - reference_data_link: - doc: | - Link to the NeXus file which describes the reference data if a - reference measurement for window correction was performed. - Ideally, the reference measurement was performed on a reference - sample and on the same sample, and using the same conditions as - for the actual measurement with and without windows. It should - have been conducted as close in time to the actual measurement - as possible. - material(NX_CHAR): - doc: | - The material of the window. - enumeration: [quartz, diamond, calcium fluoride, zinc selenide, thallium bromoiodide, alkali halide compound, Mylar, other] - material_other(NX_CHAR): - doc: | - If you specified 'other' as material, decsribe here what it is. - thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - Thickness of the window. - orientation_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Angle of the window normal (outer) vs. the substrate normal - (similar to the angle of incidence). - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 307ae4819eb6142166f995b2b9baeb2880d3e204b26eae70590096c0b898213e -# -# -# -# -# -# -# A window of a cryostat, heater, vacuum chamber or a simple glass slide. -# -# This first verion originates from NXopt to describe cryostate windows -# and possible influences for ellipsometry measurements. -# -# For environmental measurements, the environment (liquid, vapor -# etc.) is enclosed in a cell, which has windows both in the -# direction of the source (entry window) and the detector (exit -# window) (looking from the sample). In case that the entry and exit -# windows are not the same type and do not have the same properties, -# use a second 'WINDOW(NXaperture)' field. -# -# The windows also add a phase shift to the light altering the -# measured signal. This shift has to be corrected based on measuring -# a known sample (reference sample) or the actual sample of interest -# in the environmental cell. State if a window correction has been -# performed in 'window_effects_corrected'. Reference data should be -# considered as a separate experiment, and a link to the NeXus file -# should be added in reference_data_link in measured_data. -# -# The window is considered to be a part of the sample stage but also -# beam path. Hence, its position within the beam path should be -# defined by the 'depends_on' field. -# -# -# -# -# Was a window correction performed? If 'True' describe the window -# correction procedure in 'window_correction/procedure'. -# -# -# -# -# Type of effects due to this window on the measurement. -# -# -# -# -# -# -# -# -# -# -# Was a window correction performed? If 'True' describe the -# window correction procedure in '' -# -# -# -# Describe when (before or after the main measurement + time -# stamp in 'date') and how the window effects have been -# corrected, i.e. either mathematically or by performing a -# reference measurement. In the latter case, provide the link to -# to the reference data in 'reference_data_link'. -# -# -# -# -# Link to the NeXus file which describes the reference data if a -# reference measurement for window correction was performed. -# Ideally, the reference measurement was performed on a reference -# sample and on the same sample, and using the same conditions as -# for the actual measurement with and without windows. It should -# have been conducted as close in time to the actual measurement -# as possible. -# -# -# -# -# -# The material of the window. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If you specified 'other' as material, decsribe here what it is. -# -# -# -# -# Thickness of the window. -# -# -# -# -# Angle of the window normal (outer) vs. the substrate normal -# (similar to the angle of incidence). -# -# -# -# diff --git a/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml b/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml deleted file mode 100644 index e71d573fa4..0000000000 --- a/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml +++ /dev/null @@ -1,2168 +0,0 @@ -category: application -doc: | - A general application definition of optical spectroscopy elements, which may - be used as a template to derive specialized optical spectroscopy experiments. - - Possible specializations are ellipsometry, Raman spectroscopy, photoluminescence, - reflectivity/transmission spectroscopy. - - A general optical experiment consists of (i) a light/photon source, (ii) a sample, - (iii) a detector. - - For any free text descriptions, it is recommended to enter data in english - language, as this is the most FAIR representation. -symbols: - doc: | - Variables used throughout the document, e.g. dimensions or parameters. - N_spectrum: | - Length of the spectrum array (e.g. wavelength or energy) of the measured - data. - N_measurements: | - Number of measurements (1st dimension of measured_data array). This is - equal to the number of parameters scanned. For example, if the experiment - was performed at three different temperatures and two different pressures - N_measurements = 2*3 = 6. - -# 04/2024 -# Extension of the Draft Version (05/2023) of a NeXus application definition which -# serves as a template for various optical spectroscopy experiments -# TODO: -# - Add NXlens_opt and NXwaveplate to NXinstrument? -# - Make polfilter_TYPE(NXbeam_device) own base class -\-> rework NXpolarizer_opt. and add them to NXinstrument. -# - Make spectralfilter_TYPE(NXbeam_device) own base class -\-> extend NXfilter? and add them to NXinstrument. -# - Make offset angles for polar and azimutal? -# - Can angle_reference_frame be replaced later by only using reference_frames and generic angle description? -# - Add optical elements and rework them: NXfiber, NXbeam_splitter, -# - Consider to make power flux recommended? Difficult parameter to measure. Relevant for some samples/techniques, but not for all. Powder density? Nominal vs. measured? -# - Is there something to describe the spot size? -# - Restructure the concept "type" in "source_TYPE" to medium and model(NXfabication) -\-> suggestion from Markus: "splitting up the concept into type(NXfabrication) and emitting medium(NXion/NXatom) is a better alternative?" -# - How to describe beam size properties? NXbeam/extend? Is this enough? or do we need more abitrary shapes as elliptically? Maybe as well focus spot size? -# - Think of removing/reworking of (optional) NXfabrications? Con: bloats up the NeXus def (move it to base classes?) Pro: as the fixed name device_information is used, the structure is more FAIR / clean designed? -type: group -NXoptical_spectroscopy(NXobject): - (NXentry): - definition: - doc: | - An application definition describing a general optical experiment. - \@version: - doc: | - Version number to identify which definition of this application - definition was used for this entry/data. - \@URL: - doc: | - URL where to find further material (documentation, examples) relevant - to the application definition. - enumeration: [NXoptical_spectroscopy] - title: - exists: recommended - start_time(NX_DATE_TIME): - exists: recommended - doc: | - Datetime of the start of the measurement. - Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, - otherwise, the local time zone is assumed per ISO8601. - - It is required to enter at least one of both measurement times, either "start_time" or "end_time". - end_time(NX_DATE_TIME): - exists: recommended - doc: | - Datetime of the end of the measurement. - Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, - otherwise the local time zone is assumed per ISO8601. - - It is required to enter at least one of both measurement times, either "start_time" or "end_time". - experiment_identifier(NXidentifier): - exists: recommended - doc: | - A (globally persistent) unique identifier of the experiment. - (i) The identifier is usually defined by the facility, laboratory or - principal investigator. - (ii) The identifier enables to link experiments to e.g. proposals. - service(NX_CHAR): - exists: optional - identifier(NX_CHAR): - exists: recommended - identifier_type: - exists: recommended - doc: | - Select the range of validity of this identier. - Local: Setup#1 at Institute building #2 in Room #3 - Global: Unique identification of with by unique location and unique - globally persistent time stamp. - enumeration: [local, global] - is_persistent(NX_BOOLEAN): - exists: optional - experiment_description: - exists: optional - doc: | - An optional free-text description of the experiment. - - Users are strongly advised to parameterize the description of their experiment - by using respective groups and fields and base classes instead of writing prose - into this field. - - The reason is that such a free-text field is difficult to machine-interpret. - The motivation behind keeping this field for now is to learn how far the - current base classes need extension based on user feedback. - experiment_type: - doc: | - Specify the type of the optical experiment. - - Chose other if none of these methods are suitable. You may specify - fundamental characteristics or properties in the experimental sub-type. - - For Raman spectroscopy or ellipsometry use the respective specializations - of NXoptical_spectroscopy. - enumeration: [photoluminescence, transmission spectroscopy, reflection spectroscopy, other] - experiment_sub_type: - exists: optional - doc: | - Specify a special property or characteristic of the experiment, which specifies - the generic experiment type. - enumeration: [time resolved, imaging, pump-probe, other] - experiment_type_other: - exists: optional - doc: | - If "other" was selected in "experiment_type" and/or in "experiment_sub_type", - specify the experiment here with a free text name, which is knwon in the - respective community of interest. - reference_frames(NXcoordinate_system_set): - exists: optional - doc: | - Description of one or more coordinate systems that are specific to the - experiment. Examples are beam centered, sample-normal centered, - laboratory-system centered, sample-stage centered, crystal-symmetry centered. - beam_ref_frame(NXcoordinate_system): - exists: optional - depends_on(NX_CHAR): - doc: | - This refers to the coordinate system along the beam path. The origin and - base is defined at z=0, where the incident beam hits the sample at the surface. - (NXtransformations): - doc: | - This is the default NeXus coordinate system (McStas), if the transformation - does not change the coordinate system at all - i.e. it is unity. - Otherwise, by this a respective transformation of the beam - reference frame to the default reference frame could be made. i.e. - exchange of x and z coordinate, rotation of respective coordinates - towards each other. - sample_normal_ref_frame(NXcoordinate_system): - exists: optional - depends_on(NX_CHAR): - doc: | - Link to transformations defining the sample-normal base coordinate system, - which is defined such that the positive z-axis is parallel to the sample normal, - and the x-y-plane lies inside the sample surface. - (NXtransformations): - doc: | - Set of transformations, describing the orientation of the sample-normal coordinate system - with respect to the beam coordinate system (.). - (NXuser): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - Contact information and eventually details of at persons who - performed the measurements. This can be for example the principal - investigator or student. Examples are: name, affiliation, address, telephone - number, email, role as well as identifiers such as orcid or similar. - It is recommended to add multiple users if relevant. - - Due to data privacy concerns, there is no minimum requirement. - If no user with specific name is allowed to be given, it is required to - assign at least an affiliation - (NXinstrument): - doc: | - Devices or elements of the optical spectroscopy setup described with its - properties and general information. - - This includes for example: - - The beam device's or instrument's model, company, serial number, construction year, etc. - - Used software or code - - Experiment descriptive parameters as reference frames, resolution, calibration - - Photon beams with their respective properties such as angles and polarization - - Various optical beam path devices, which interact, manipulate or measure optical beams - - Characteristics of the medium surrounding the sample - - "Beam devices" for a beam path description - - Stages(NXmanipulator) - - Sensors and actuators to control or measure sample or beam properties - beam_TYPE(NXbeam): - exists: ['min', '1', 'max', 'unbounded'] - doc: | - This can be used to describe properties of a photon beam. - A beam is always defined between two beam_devices, via - "previous_device" and "next_device". - - It is required to define at least one incident beam which is incident - to the sample. You may specify if this beam parameters are acutally measured - or just nominal. - If this beam is the output of a source, chose the same - name appendix as for the NXsource instance (e.g. TYPE=532nm) - parameter_reliability: - exists: optional - doc: | - Select the reliability of the respective beam characteristics. Either, - the parameters are measured via another device or method or just given - nominally via the properties of a light source properties (532nm, 100mW). - enumeration: [measured, nominal] - incident_wavelength(NX_NUMBER): - exists: recommended - incident_wavelength_spread(NX_NUMBER): - exists: recommended - incident_polarization(NX_NUMBER): - exists: recommended - extent(NX_FLOAT): - exists: recommended - associated_source(NX_CHAR): - exists: optional - doc: | - The path to the device which emitted this beam (light source or frequency doubler). - - This parameter is recommended, if the previous optical element is a photon source. - In this way, the properties of the laser or light souce can be described - and associated. - The beam should be named with the same appendix as the source, e.g., - for TYPE=532nmlaser, there should be both a NXsource named - "source_532nmlaser" and a NXbeam named "beam_532nmlaser". - - Example: /entry/instrument/source_532nmlaser - - # The two polarization descriptions may be completely replaced by polarization - beam_polarization_type: - exists: optional - enumeration: [linear, circular, ellipically, unpolarized] - linear_beam_sample_polarization(NX_NUMBER): - exists: optional - unit: NX_ANGLE - doc: | - Angle of the linear polarized light, with respect to a fixed arbitrary - defined 0° position. This can be used if no definition of respective - cooridnate systems for beam and sample normal is done. If coordinate systems - are defined, refer to beam "incident_polarization". - detector_TYPE(NXdetector): - exists: ['min', '1', 'max', 'unbounded'] - detector_channel_type: - enumeration: [single-channel, multichannel] - detector_type: - exists: recommended - doc: | - Description of the detector type. - enumeration: [CCD, photomultiplier, photodiode, avalanche-photodiode, streak camera, bolometer, golay detectors, pyroelectric detector, deuterated triglycine sulphate, other] - detector_type_other: - exists: optional - doc: | - Type of detector, if "other" was selected in "detector_type". - raw_data(NXdata): - exists: recommended - doc: | - Contains the raw data collected by the detector before calibration. - The data which is considered raw might change from experiment to experiment - due to hardware pre-processing of the data. - This field ideally collects the data with the lowest level of processing - possible. - - # Define a similar convention for NXoptical_spectroscopy? Or only for NXraman, NXellipsometry and NXphotoluminescence? - # Fields should be named according to new following convention: - # - **pixel_x**: Detector pixel in x direction. - # - **pixel_y**: Detector pixel in y direction. - # - **energy**: (Un)calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). - # - **kx**: (Un)calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). - # - **ky**: (Un)calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). - # - **kz**: (Un)calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). - # - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). - # Unit category: NX_ANGLE - # - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - # Unit category: NX_ANGLE - # - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) - # Unit category: NX_LENGTH - # - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - # Unit category: NX_LENGTH - # - **delay**: Calibrated delay time. Unit category: NX_TIME (s). - # - **polarization_angle**: Linear polarization angle of the incoming or - # outgoing beam. - # Unit category: NX_ANGLE (° or rad) - # - **ellipticity**: Ellipticity of the incoming or outgoing beam. - # Unit category: NX_ANGLE (° or rad) - # - **time_of_flight**: Total time of flight. Unit category: NX_TIME_OF_FLIGHT - # - **time_of_flight_adc**: Time-of-flight values, analog-to-digital converted. - # - **external_AXIS**: Describes an axis which is coming from outside the detectors scope. - \@signal: - enumeration: [raw] - raw(NX_NUMBER): - doc: | - Raw data before calibration. - additional_detector_hardware: - exists: optional - doc: | - Specify respective hardware which was used for the detector. For - example special electronics required for time-correlated single photon - counting (TCSPC). - device_information(NXfabrication): - exists: recommended - source_TYPE(NXsource): - exists: recommended - type: - exists: recommended - enumeration: [laser, dye-laser, broadband tunable light source, X-ray Source, arc lamp, halogen lamp, LED, mercury cadmium telluride, deuterium lamp, xenon lamp, globar, other] - type_other: - exists: optional - doc: | - Specification of type, may also go to name. - name: - exists: recommended - standard: - exists: optional - doc: | - If available, name/ID/norm of the light source standard. - device_information(NXfabrication): - exists: recommended - doc: | - Details about the device information. - associated_beam(NX_CHAR): - exists: recommended - doc: | - The path to a beam emitted by this source. - Should be named with the same appendix, e.g., - for TYPE=532nmlaser, there should as well be - a NXbeam named "beam_532nmlaser" together with this source - instance named "source_532nmlaser" - - Example: /entry/instrument/beam_532nmlaser - (NXmonochromator): - exists: recommended - device_information(NXfabrication): - exists: recommended - angle_reference_frame: - exists: recommended - doc: | - Defines the reference frame which is used to describe the sample orientation - with respect to the beam directions. - - A beam centered description is the default and uses 4 angles(similar to XRD): - - Omega (angle between sample surface and incident beam) - - 2Theta (angle between the transmitted beam and the detection beam) - - Chi (sample tilt angle, angle between plane#1 and the surface normal, - plane#1 = spanned by incidence beam and detection - and detection. If Chi=0°, then plane#1 is the plane of - incidence in reflection setups) - - Phi (inplane rotation of sample, rotation axis is the samples - surface normal) - - - A sample normal centered description is as well possible: - - angle of incidence (angle between incident beam and sample surface) - - angle of detection (angle between detection beam and sample surface) - - angle of incident and detection beam - - angle of in-plane sample rotation (direction along the sample's surface normal) - - An arbitrary reference frame can be defined by "reference_frames" - and used via "instrument/angle_sample_and_beam_TYPE" - enumeration: [beam centered, sample-normal centered] - omega(NX_NUMBER): - exists: optional - unit: NX_ANGLE - doc: | - Angle between sample incident beam and sample surface. - twotheta(NX_NUMBER): - exists: optional - unit: NX_ANGLE - doc: | - Angle between incident and detection beam - chi(NX_NUMBER): - exists: optional - unit: NX_ANGLE - doc: | - Sample tilt between sample normal, and the plane spanned by detection and - incident beam. - phi(NX_NUMBER): - exists: optional - unit: NX_ANGLE - doc: | - Inplane rotation of the sample, with rotation axis along sample normal. - angle_of_incidence(NX_NUMBER): - exists: optional - unit: NX_ANGLE - doc: | - Angle(s) of the incident beam vs. the normal of the bottom reflective - (substrate) surface in the sample. These two directions span the plane - of incidence. - angle_of_detection(NX_NUMBER): - exists: optional - unit: NX_ANGLE - doc: | - Detection angle(s) of the beam reflected or scattered off the sample - vs. the normal of the bottom reflective (substrate) surface in the - sample if not equal to the angle(s) of incidence. - These two directions span the plane of detection. - angle_of_incident_and_detection_beam(NX_NUMBER): - exists: optional - unit: NX_ANGLE - doc: | - Angle between the incident and detection beam. - If angle_of_detection + angle_of_incidence = angle_of_incident_and_detection_beam, - then the setup is a reflection setup. - If angle_of_detection + angle_of_incidence != angle_of_incident_and_detection_beam - then the setup may be a light scattering setup. - (i.e. 90° + 90° != 90°, i.e. incident and detection beam in the sample surface, but - the angle source-sample-detector is 90°) - angle_of_in_plane_sample_rotation(NX_NUMBER): - exists: optional - unit: NX_ANGLE - doc: | - Angle of the inplane orientation of the sample. This might be an arbitrary, - angle without specific relation to the sample symmetry, - of the angle to a specific sample property (i.e. crystallographic axis or sample - shape such as wafer flat) - generic_beam_sample_angle_TYPE(NXtransformations): - exists: recommended - doc: | - Set of transformations, describing the relative orientation of different - parts of the experiment (beams or sample). You may select one of the specified - angles for incident and detection beam or sample, and then use polar and azimuthal - angles to define the direction via sperical coordinates. - This allows consistent defintion between different coordinate system. - You may refer to self defined coordinate system as well. - - - If "angle_reference_frame = beam centered", then this coordinate system is used: - McStas system (NeXus default) - (https://manual.nexusformat.org/design.html#mcstas-and-nxgeometry-system) - - i.e. the z-coordinate math:`[0,0,1]` is along the incident beam direction and - the x-coordinate math:`[1,0,0]` is in the horizontal plane. Hence, usually math:`[0,1,0]` - is vertically oriented. - - If "angle_reference_frame = sample-normal centered", then this coordinate - system is used - z - math:`[0,0,1]` along sample surface normal - x - math:`[1,0,0]` defined by sample surface projected incident beam. - y - math:`[0,1,0]` in the sample surface, orthogonal to z and x. - For this case, x may be ill defined, if the incident beam is perpendicular - to the sample surface. In this case, use the beam centered description. - type: - enumeration: [incident beam, detection beam, sample] - polar(NX_NUMBER): - unit: NX_ANGLE - doc: | - Rotation about the y axis (polar rotation within the sample plane). - \@transformation_type: - enumeration: [rotation] - \@vector: - enumeration: [[0, 1, 0]] - \@depends_on: - doc: | - Path to a transformation that places the sample surface - into the origin of the arpes_geometry coordinate system. - azimuth(NX_NUMBER): - unit: NX_ANGLE - doc: | - Rotation about the z axis (azimuthal rotation within the sample plane). - \@transformation_type: - enumeration: [rotation] - \@vector: - enumeration: [[0, 0, 1]] - \@depends_on: - enumeration: [offset_tilt] - lateral_focal_point_offset(NX_NUMBER): - exists: optional - unit: NX_LENGTH - doc: | - Specify if there is a lateral offset on the sample surface, between the focal - points of the incident beam and the detection beam. - (NXbeam_device): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - Describes the order of respective beam devices in the optical beam - path. - - Everything object which interacts or modifies optical beam properties, - may be an beam device, e.g. Filter, Window, Beamsplitter, Photon Source, - Detector, etc, - - It is intended, to include this functionality later to "older" beam - components, such as NXsource, NXdetector, NXlens, etc. - Until this is possbible, auxillary beam devices have to be created, - for each "older" beam component instead, to allow a beam path description. - To link the auxillary beam device to the real device properties, the - attribute \@device should be used. - \@device: - exists: recommended - doc: | - Reference to beam device, which is described by a NeXus concept - (e.g. for NXsource, entry/instrument/source_TYPE). - previous_device: - exists: recommended - doc: | - Reference to the previous beam device, from which the photon beam came - to reach this beam device. A photon source is related as origin by ".". - This enables a logical order description of the optical setup. - (NXlens_opt): - exists: optional - doc: | - This is the optical element used to focus or collect light. This may - be a genereic lens or microcope objectives which are used for the - Raman scattering process. - type: - enumeration: [objective, lens, glass fiber, none, other] - device_information(NXfabrication): - exists: optional - (NXwaveplate): - exists: optional - (NXopt_window): - exists: optional - polfilter_TYPE(NXbeam_device): - exists: optional - doc: | - polarization filter to prepare light to be measured or to be incident - on the sample. - Genereric polarization filter porperties may be implemented via NXfilter_pol - at a later stage. - filter_mechanism(NX_CHAR): - exists: optional - doc: | - Physical principle of the polarization filter used to create a - defined incident or scattered light state. - enumeration: [polarization by Fresnel reflection, birefringent polarizers, thin film polarizers, wire-grid polarizers, other] - specific_polarization_filter_type(NX_CHAR): - exists: optional - doc: | - Specific name or type of the polarizer used. - - Free text, for example: Glan-Thompson, Glan-Taylor, Rochon Prism, Wollaston - Polarizer... - device_information(NXfabrication): - exists: optional - spectralfilter_TYPE(NXbeam_device): - exists: optional - doc: | - Spectral filter used to modify properties of the scattered or incident light. - Genereric spectral filter porperties may be implemented via NXfilter_spec - at a later stage. - filter_type: - exists: optional - doc: | - Type of laserline filter used to supress the laser, if measurements - close to the laserline are performed. - enumeration: [long-pass filter, short-pass filter, notch filter, reflection filter, neutral density filter, other] - intended_use: - exists: optional - doc: | - Type of laserline filter used to supress the laser, if measurements - close to the laserline are performed. - enumeration: [laser line cleanup, raylight line removal, spectral filtering, intensity manipulation, other] - filter_characteristics(NXdata): - exists: optional - doc: | - Properties of the spectral filter such as wavelength dependent Transmission - or reflectivity. - \@characteristics_type: - exists: optional - doc: | - Which property is used to form the spectral properties of light, - i.e. transmission or reflection properties. - enumeration: [transmission, reflection] - device_information(NXfabrication): - exists: optional - - # Later for rework of specific optical elements - # (NXbeam_splitter): - # exists: optional - # doc: | - # Can be used to describe a beam splitter as optical element. - (NXbeam_transfer_matrix_table): - exists: optional - doc: | - Allows description of beam properties via matrices, which relate ingoing with - outgoing beam properties. - sample_stage(NXmanipulator): - exists: optional - doc: | - Sample stage (or manipulator) for positioning of the sample. This should - only contain the spatial orientation of movement. - stage_type: - exists: optional - doc: | - Specify the type of the sample stage. - enumeration: [manual stage, scanning stage, liquid stage, gas cell, cryostat, heater, other] - stage_type_other: - exists: optional - doc: | - If "other" was chosen in stage_type, enter here a free text description - of the stage type. - transformations(NXtransformations): - exists: optional - doc: | - This allows a description of the stages relation or orientation and - position with respect to the sample or beam, if an laboratory or - an stage coordinate system is defined. - beam_sample_relation: - exists: optional - doc: | - Description of relation of the beam with the sample. How dit the - sample hit the beam, e.g. 'center of sample, long edge parallel - to the plane of incidence'. - Is redundent, if a full orientation description is done via the - stages "transformations" entry. - device_information(NXfabrication): - exists: optional - temperature_sensor(NXsensor): - exists: recommended - name: - exists: recommended - measurement: - enumeration: [temperature] - type: - exists: optional - value(NX_FLOAT): - device_information(NXfabrication): - exists: optional - temp_control_TYPE(NXactuator): - exists: optional - doc: | - Type of control for the sample temperature. Replace TYPE by "cryostat" or - "heater" to specify it. - name: - exists: recommended - physical_quantity: - enumeration: [temperature] - cooler_or_heater: - exists: recommended - enumeration: [cooler, heater] - type: - exists: optional - doc: | - Hardware used for actuation, i.e. laser, gas lamp, filament, resistive - (NXpid): - exists: recommended - setpoint(NX_FLOAT): - exists: recommended - device_information(NXfabrication): - exists: optional - device_information(NXfabrication): - exists: recommended - doc: | - General device information of the optical spectroscopy setup, if - suitable (e.g. for a tabletop spectrometer or other non-custom build setups). - For custom build setups, this may be limited to the construction year. - vendor: - exists: recommended - model: - exists: recommended - identifier(NXidentifier): - exists: recommended - construction_year(NX_DATE_TIME): - exists: optional - software_TYPE(NXprogram): - exists: recommended - program: - doc: | - Commercial or otherwise defined given name of the program that was - used to control any parts of the optical spectroscopy setup. - The uppercase TYPE should be replaced by a specification name, i.e. - "software_detector" or "software_stage" to specify the respective - program or software components. - \@version: - exists: recommended - doc: | - Either version with build number, commit hash, or description of a - (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner. - \@URL: - exists: optional - doc: | - Description of the software by persistent resource, where the program, - code, script etc. can be found. - instrument_calibration_DEVICE(NXcalibration): - exists: recommended - doc: | - Pre-calibration of an arbitrary device of the instrumental setup, which - has the name DEVICE. You can specify here how, at which time by which method - the calibration was done. As well the accuracy and a link to the calibration - dataset. - device_path: - exists: recommended - doc: | - Path to the device, which was calibrated. - Example: entry/instrument/DEVICE - calibration_accuracy(NXdata): - exists: optional - doc: | - Provide data about the determined accuracy of the device, this may - may be a single value or a dataset like wavelength error vs. wavelength etc. - calibration_status(NX_CHAR): - exists: recommended - doc: | - Was a calibration performed? If yes, when was it done? If the - calibration time is provided, it should be specified in - ENTRY/INSTRUMENT/calibration/calibration_time. - enumeration: [calibration time provided, no calibration, within 1 hour, within 1 day, within 1 week] - calibration_time(NX_DATE_TIME): - exists: optional - doc: | - If calibtration status is 'calibration time provided', specify the - ISO8601 date when calibration was last performed before this - measurement. UTC offset should be specified. - (NXdata): - exists: optional - doc: | - Generic data which does not fit to the 'NX_FLOAT' fields in NXproces. - This can be for example the instrument response function. - wavelength_resolution(NXresolution): - exists: optional - doc: | - The overall resolution of the optical instrument. - physical_quantity: - enumeration: [wavelength] - type: - exists: recommended - resolution(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - Minimum distinguishable wavelength separation of peaks in spectra. - sample_medium_refractive_indices(NX_FLOAT): - exists: optional - unit: NX_UNITLESS - doc: | - Array of pairs of complex refractive indices n + ik of the medium - for every measured spectral point/wavelength/energy. - Only necessary if the measurement was performed not in air, or - something very well known, e.g. high purity water. - dimensions: - rank: 2 - dim: [[1, 2], [2, N_spectrum]] - (NXsample): - doc: | - Properties of the sample, such as sample type, layer structure, - chemical formula, atom types, its history etc. - Information about the sample stage and sample environment should be - described in ENTRY/INSTRUMENT/sample_stage. - name: - sample_id: - exists: recommended - doc: | - Locally unique ID of the sample, used in the reasearch institute or group. - physical_form: - exists: recommended - doc: | - State the form of the sample, examples are: - thin film, single crystal, poly crystal, amorphous, single layer, - multi layer, liquid, gas, pellet, powder. - Generic properties of liquids or gases see NXsample properties. - description: - exists: optional - doc: | - Free text description of the sample. - chemical_formula: - exists: recommended - doc: | - Chemical formula of the sample. Use the Hill system (explained here: - https://en.wikipedia.org/wiki/Chemical_formula#Hill_system) to write - the chemical formula. In case the sample consists of several layers, - this should be a list of the chemical formulas of the individual - layers, where the first entry is the chemical formula of the top - layer (the one on the front surface, on which the light incident). - The order must be consistent with layer_structure - atom_types: - exists: optional - doc: | - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - 'atom_types'. - preparation_date(NX_DATE_TIME): - exists: recommended - doc: | - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known timestamp when - the measured specimen surface was actively prepared. - history(NXhistory): - exists: recommended - doc: | - A set of activities that occurred to the sample prior to/during the experiment. - temperature(NXenvironment): - exists: recommended - doc: | - Sample temperature (either controlled or just measured). - temperature_nominal: - exists: optional - doc: | - If no sensor was available for the determination of temperature, selected - a nominal value which represents approximately the situation of sample temperature. - enumeration: [room temperature, liquid helium temperature, liquid nitrogen temperature, other] - temperature_nominal_other(NX_NUMBER): - exists: optional - unit: NX_TEMPERATURE - doc: | - If temperature_nominal is "other", enter here a nominal/assumed/estimated - sample temperature. - temperature_sensor(NXsensor): - exists: recommended - doc: | - Temperature sensor measuring the sample temperature. - This should be a link to /entry/instrument/manipulator/temperature_sensor. - sample_heater(NXactuator): - exists: optional - doc: | - Device to heat the sample. - This should be a link to /entry/instrument/manipulator/sample_heater. - sample_cooler(NXactuator): - exists: optional - doc: | - Device for cooling the sample (Cryostat, Airflow cooler, etc.). - This should be a link to /entry/instrument/manipulator/cryostat. - (NXenvironment): - exists: optional - doc: | - Arbirary sample property which may be varied during the experiment - and controlled by a device. Examples are pressure, voltage, magnetic field etc. - Similar to the temperautre description of the sample. - sample_medium: - exists: recommended - doc: | - Medium, in which the sample is placed. - enumeration: [air, vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere, sealed can, water, other] - - # Make something like NXlayer_structure_sample? - thickness(NX_NUMBER): - exists: optional - unit: NX_LENGTH - doc: | - (Measured) sample thickness. - - The information is recorded to qualify if the light used was likely - able to shine through the sample. - - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - thickness_determination: - exists: optional - doc: | - If a thickness if given, please specify how this thickness was estimated or - determined. - - # Maybe consider here to include NXsample_component_set. - layer_structure: - exists: optional - doc: | - Qualitative description of the layer structure for the sample, - starting with the top layer (i.e. the one on the front surface, on - which the light incident), e.g. native oxide/bulk substrate, or - Si/native oxide/thermal oxide/polymer/peptide. - sample_orientation: - exists: optional - doc: | - Specify the sample orientation, how is its sample normal oriented - relative in the laboratory reference frame, incident beam reference - frame. - substrate: - exists: recommended - doc: | - If the sample is grown or fixed on a substrate, specify this here by - a free text description. - (NXdata): - doc: | - Here generic types of data may be saved.. This may refer to data derived - from single or multiple raw measurements (i.e. several intensities are - evaluated for different parameters: ellipsometry -> psi and delta) - - i.e. non-raw data. - As well plotable data may be stored/linked here, which provides the most suitable - representation of the data (for the respective community). - - You may provide multiple instances of NXdata - \@axes: - doc: | - Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) - \@signal: - doc: | - Spectrum, i.e. y-axis of the data (e.g. counts, intensity) - measurement_data_calibration_TYPE(NXprocess): - exists: recommended - wavelength_calibration(NXcalibration): - exists: optional - calibrated_axis(NX_FLOAT): - exists: recommended - doc: | - Location to save the calibrated wavelength data. - - # The old "data_collection(NXprocess)" is now replaced by more flexbile - # NXdata. The detailed inclusion of a data collection description (i.e. - # raw data from ellipsometry as polarization values to the usually used - # psi and delta values), will be done later after the NXopt workshop. - derived_parameters(NXprocess): - exists: optional - - # >>>This section is transfered from the first NXoptical_spectroscopy version and might - # require a reqwork.<<< - doc: | - Parameters that are derived from the measured data. - depolarization(NX_NUMBER): - exists: optional - unit: NX_UNITLESS - doc: | - Light loss due to depolarization as a value in [0-1]. - dimensions: - rank: 3 - dim: [[1, N_measurements], [2, 1], [3, N_spectrum]] - jones_quality_factor(NX_NUMBER): - exists: optional - unit: NX_UNITLESS - doc: | - Jones quality factor. - dimensions: - rank: 3 - dim: [[1, N_measurements], [2, 1], [3, N_spectrum]] - reflectivity(NX_NUMBER): - exists: optional - unit: NX_UNITLESS - doc: | - Reflectivity. - dimensions: - rank: 3 - dim: [[1, N_measurements], [2, 1], [3, N_spectrum]] - transmittance(NX_NUMBER): - exists: optional - unit: NX_UNITLESS - doc: | - Transmittance. - dimensions: - rank: 3 - dim: [[1, N_measurements], [2, 1], [3, N_spectrum]] - ANALYSIS_program(NXprocess): - exists: optional - program: - doc: | - Commercial or otherwise defined given name of the program that was - used to generate or calculate the derived parameters. - If home written, one can provide the actual steps in the NOTE - subfield here. - version: - doc: | - Either version with build number, commit hash, or description of a - (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 077a817b91550b6db26aa39a2bb23a6075be62562022208c17b19a8fec1afcc2 -# -# -# -# -# -# -# -# Variables used throughout the document, e.g. dimensions or parameters. -# -# -# -# Length of the spectrum array (e.g. wavelength or energy) of the measured -# data. -# -# -# -# -# Number of measurements (1st dimension of measured_data array). This is -# equal to the number of parameters scanned. For example, if the experiment -# was performed at three different temperatures and two different pressures -# N_measurements = 2*3 = 6. -# -# -# -# -# A general application definition of optical spectroscopy elements, which may -# be used as a template to derive specialized optical spectroscopy experiments. -# -# Possible specializations are ellipsometry, Raman spectroscopy, photoluminescence, -# reflectivity/transmission spectroscopy. -# -# A general optical experiment consists of (i) a light/photon source, (ii) a sample, -# (iii) a detector. -# -# For any free text descriptions, it is recommended to enter data in english -# language, as this is the most FAIR representation. -# -# -# -# -# An application definition describing a general optical experiment. -# -# -# -# Version number to identify which definition of this application -# definition was used for this entry/data. -# -# -# -# -# URL where to find further material (documentation, examples) relevant -# to the application definition. -# -# -# -# -# -# -# -# -# -# Datetime of the start of the measurement. -# Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, -# otherwise, the local time zone is assumed per ISO8601. -# -# It is required to enter at least one of both measurement times, either "start_time" or "end_time". -# -# -# -# -# Datetime of the end of the measurement. -# Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, -# otherwise the local time zone is assumed per ISO8601. -# -# It is required to enter at least one of both measurement times, either "start_time" or "end_time". -# -# -# -# -# A (globally persistent) unique identifier of the experiment. -# (i) The identifier is usually defined by the facility, laboratory or -# principal investigator. -# (ii) The identifier enables to link experiments to e.g. proposals. -# -# -# -# -# -# Select the range of validity of this identier. -# Local: Setup#1 at Institute building #2 in Room #3 -# Global: Unique identification of with by unique location and unique -# globally persistent time stamp. -# -# -# -# -# -# -# -# -# -# -# An optional free-text description of the experiment. -# -# Users are strongly advised to parameterize the description of their experiment -# by using respective groups and fields and base classes instead of writing prose -# into this field. -# -# The reason is that such a free-text field is difficult to machine-interpret. -# The motivation behind keeping this field for now is to learn how far the -# current base classes need extension based on user feedback. -# -# -# -# -# Specify the type of the optical experiment. -# -# Chose other if none of these methods are suitable. You may specify -# fundamental characteristics or properties in the experimental sub-type. -# -# For Raman spectroscopy or ellipsometry use the respective specializations -# of NXoptical_spectroscopy. -# -# -# -# -# -# -# -# -# -# -# Specify a special property or characteristic of the experiment, which specifies -# the generic experiment type. -# -# -# -# -# -# -# -# -# -# -# If "other" was selected in "experiment_type" and/or in "experiment_sub_type", -# specify the experiment here with a free text name, which is knwon in the -# respective community of interest. -# -# -# -# -# Description of one or more coordinate systems that are specific to the -# experiment. Examples are beam centered, sample-normal centered, -# laboratory-system centered, sample-stage centered, crystal-symmetry centered. -# -# -# -# -# This refers to the coordinate system along the beam path. The origin and -# base is defined at z=0, where the incident beam hits the sample at the surface. -# -# -# -# -# This is the default NeXus coordinate system (McStas), if the transformation -# does not change the coordinate system at all - i.e. it is unity. -# Otherwise, by this a respective transformation of the beam -# reference frame to the default reference frame could be made. i.e. -# exchange of x and z coordinate, rotation of respective coordinates -# towards each other. -# -# -# -# -# -# -# Link to transformations defining the sample-normal base coordinate system, -# which is defined such that the positive z-axis is parallel to the sample normal, -# and the x-y-plane lies inside the sample surface. -# -# -# -# -# Set of transformations, describing the orientation of the sample-normal coordinate system -# with respect to the beam coordinate system (.). -# -# -# -# -# -# -# Contact information and eventually details of at persons who -# performed the measurements. This can be for example the principal -# investigator or student. Examples are: name, affiliation, address, telephone -# number, email, role as well as identifiers such as orcid or similar. -# It is recommended to add multiple users if relevant. -# -# Due to data privacy concerns, there is no minimum requirement. -# If no user with specific name is allowed to be given, it is required to -# assign at least an affiliation -# -# -# -# -# Devices or elements of the optical spectroscopy setup described with its -# properties and general information. -# -# This includes for example: -# - The beam device's or instrument's model, company, serial number, construction year, etc. -# - Used software or code -# - Experiment descriptive parameters as reference frames, resolution, calibration -# - Photon beams with their respective properties such as angles and polarization -# - Various optical beam path devices, which interact, manipulate or measure optical beams -# - Characteristics of the medium surrounding the sample -# - "Beam devices" for a beam path description -# - Stages(NXmanipulator) -# - Sensors and actuators to control or measure sample or beam properties -# -# -# -# This can be used to describe properties of a photon beam. -# A beam is always defined between two beam_devices, via -# "previous_device" and "next_device". -# -# It is required to define at least one incident beam which is incident -# to the sample. You may specify if this beam parameters are acutally measured -# or just nominal. -# If this beam is the output of a source, chose the same -# name appendix as for the NXsource instance (e.g. TYPE=532nm) -# -# -# -# Select the reliability of the respective beam characteristics. Either, -# the parameters are measured via another device or method or just given -# nominally via the properties of a light source properties (532nm, 100mW). -# -# -# -# -# -# -# -# -# -# -# -# -# The path to the device which emitted this beam (light source or frequency doubler). -# -# This parameter is recommended, if the previous optical element is a photon source. -# In this way, the properties of the laser or light souce can be described -# and associated. -# The beam should be named with the same appendix as the source, e.g., -# for TYPE=532nmlaser, there should be both a NXsource named -# "source_532nmlaser" and a NXbeam named "beam_532nmlaser". -# -# Example: /entry/instrument/source_532nmlaser -# -# -# -# -# -# -# -# -# -# -# -# -# -# Angle of the linear polarized light, with respect to a fixed arbitrary -# defined 0° position. This can be used if no definition of respective -# cooridnate systems for beam and sample normal is done. If coordinate systems -# are defined, refer to beam "incident_polarization". -# -# -# -# -# -# -# -# -# -# -# -# -# Description of the detector type. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Type of detector, if "other" was selected in "detector_type". -# -# -# -# -# Contains the raw data collected by the detector before calibration. -# The data which is considered raw might change from experiment to experiment -# due to hardware pre-processing of the data. -# This field ideally collects the data with the lowest level of processing -# possible. -# -# -# -# -# -# -# -# -# -# Raw data before calibration. -# -# -# -# -# -# Specify respective hardware which was used for the detector. For -# example special electronics required for time-correlated single photon -# counting (TCSPC). -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Specification of type, may also go to name. -# -# -# -# -# -# If available, name/ID/norm of the light source standard. -# -# -# -# -# Details about the device information. -# -# -# -# -# The path to a beam emitted by this source. -# Should be named with the same appendix, e.g., -# for TYPE=532nmlaser, there should as well be -# a NXbeam named "beam_532nmlaser" together with this source -# instance named "source_532nmlaser" -# -# Example: /entry/instrument/beam_532nmlaser -# -# -# -# -# -# -# -# -# Defines the reference frame which is used to describe the sample orientation -# with respect to the beam directions. -# -# A beam centered description is the default and uses 4 angles(similar to XRD): -# - Omega (angle between sample surface and incident beam) -# - 2Theta (angle between the transmitted beam and the detection beam) -# - Chi (sample tilt angle, angle between plane#1 and the surface normal, -# plane#1 = spanned by incidence beam and detection -# and detection. If Chi=0°, then plane#1 is the plane of -# incidence in reflection setups) -# - Phi (inplane rotation of sample, rotation axis is the samples -# surface normal) -# -# -# A sample normal centered description is as well possible: -# - angle of incidence (angle between incident beam and sample surface) -# - angle of detection (angle between detection beam and sample surface) -# - angle of incident and detection beam -# - angle of in-plane sample rotation (direction along the sample's surface normal) -# -# An arbitrary reference frame can be defined by "reference_frames" -# and used via "instrument/angle_sample_and_beam_TYPE" -# -# -# -# -# -# -# -# -# Angle between sample incident beam and sample surface. -# -# -# -# -# Angle between incident and detection beam -# -# -# -# -# Sample tilt between sample normal, and the plane spanned by detection and -# incident beam. -# -# -# -# -# Inplane rotation of the sample, with rotation axis along sample normal. -# -# -# -# -# Angle(s) of the incident beam vs. the normal of the bottom reflective -# (substrate) surface in the sample. These two directions span the plane -# of incidence. -# -# -# -# -# Detection angle(s) of the beam reflected or scattered off the sample -# vs. the normal of the bottom reflective (substrate) surface in the -# sample if not equal to the angle(s) of incidence. -# These two directions span the plane of detection. -# -# -# -# -# Angle between the incident and detection beam. -# If angle_of_detection + angle_of_incidence = angle_of_incident_and_detection_beam, -# then the setup is a reflection setup. -# If angle_of_detection + angle_of_incidence != angle_of_incident_and_detection_beam -# then the setup may be a light scattering setup. -# (i.e. 90° + 90° != 90°, i.e. incident and detection beam in the sample surface, but -# the angle source-sample-detector is 90°) -# -# -# -# -# Angle of the inplane orientation of the sample. This might be an arbitrary, -# angle without specific relation to the sample symmetry, -# of the angle to a specific sample property (i.e. crystallographic axis or sample -# shape such as wafer flat) -# -# -# -# -# Set of transformations, describing the relative orientation of different -# parts of the experiment (beams or sample). You may select one of the specified -# angles for incident and detection beam or sample, and then use polar and azimuthal -# angles to define the direction via sperical coordinates. -# This allows consistent defintion between different coordinate system. -# You may refer to self defined coordinate system as well. -# -# -# If "angle_reference_frame = beam centered", then this coordinate system is used: -# McStas system (NeXus default) -# (https://manual.nexusformat.org/design.html#mcstas-and-nxgeometry-system) -# -# i.e. the z-coordinate math:`[0,0,1]` is along the incident beam direction and -# the x-coordinate math:`[1,0,0]` is in the horizontal plane. Hence, usually math:`[0,1,0]` -# is vertically oriented. -# -# If "angle_reference_frame = sample-normal centered", then this coordinate -# system is used -# z - math:`[0,0,1]` along sample surface normal -# x - math:`[1,0,0]` defined by sample surface projected incident beam. -# y - math:`[0,1,0]` in the sample surface, orthogonal to z and x. -# For this case, x may be ill defined, if the incident beam is perpendicular -# to the sample surface. In this case, use the beam centered description. -# -# -# -# -# -# -# -# -# -# -# Rotation about the y axis (polar rotation within the sample plane). -# -# -# -# -# -# -# -# -# -# -# -# -# -# Path to a transformation that places the sample surface -# into the origin of the arpes_geometry coordinate system. -# -# -# -# -# -# Rotation about the z axis (azimuthal rotation within the sample plane). -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Specify if there is a lateral offset on the sample surface, between the focal -# points of the incident beam and the detection beam. -# -# -# -# -# Describes the order of respective beam devices in the optical beam -# path. -# -# Everything object which interacts or modifies optical beam properties, -# may be an beam device, e.g. Filter, Window, Beamsplitter, Photon Source, -# Detector, etc, -# -# It is intended, to include this functionality later to "older" beam -# components, such as NXsource, NXdetector, NXlens, etc. -# Until this is possbible, auxillary beam devices have to be created, -# for each "older" beam component instead, to allow a beam path description. -# To link the auxillary beam device to the real device properties, the -# attribute \@device should be used. -# -# -# -# Reference to beam device, which is described by a NeXus concept -# (e.g. for NXsource, entry/instrument/source_TYPE). -# -# -# -# -# Reference to the previous beam device, from which the photon beam came -# to reach this beam device. A photon source is related as origin by ".". -# This enables a logical order description of the optical setup. -# -# -# -# -# -# This is the optical element used to focus or collect light. This may -# be a genereic lens or microcope objectives which are used for the -# Raman scattering process. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# polarization filter to prepare light to be measured or to be incident -# on the sample. -# Genereric polarization filter porperties may be implemented via NXfilter_pol -# at a later stage. -# -# -# -# Physical principle of the polarization filter used to create a -# defined incident or scattered light state. -# -# -# -# -# -# -# -# -# -# -# -# Specific name or type of the polarizer used. -# -# Free text, for example: Glan-Thompson, Glan-Taylor, Rochon Prism, Wollaston -# Polarizer... -# -# -# -# -# -# -# Spectral filter used to modify properties of the scattered or incident light. -# Genereric spectral filter porperties may be implemented via NXfilter_spec -# at a later stage. -# -# -# -# Type of laserline filter used to supress the laser, if measurements -# close to the laserline are performed. -# -# -# -# -# -# -# -# -# -# -# -# -# Type of laserline filter used to supress the laser, if measurements -# close to the laserline are performed. -# -# -# -# -# -# -# -# -# -# -# -# Properties of the spectral filter such as wavelength dependent Transmission -# or reflectivity. -# -# -# -# Which property is used to form the spectral properties of light, -# i.e. transmission or reflection properties. -# -# -# -# -# -# -# -# -# -# -# -# -# Allows description of beam properties via matrices, which relate ingoing with -# outgoing beam properties. -# -# -# -# -# Sample stage (or manipulator) for positioning of the sample. This should -# only contain the spatial orientation of movement. -# -# -# -# Specify the type of the sample stage. -# -# -# -# -# -# -# -# -# -# -# -# -# -# If "other" was chosen in stage_type, enter here a free text description -# of the stage type. -# -# -# -# -# This allows a description of the stages relation or orientation and -# position with respect to the sample or beam, if an laboratory or -# an stage coordinate system is defined. -# -# -# -# -# Description of relation of the beam with the sample. How dit the -# sample hit the beam, e.g. 'center of sample, long edge parallel -# to the plane of incidence'. -# Is redundent, if a full orientation description is done via the -# stages "transformations" entry. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Type of control for the sample temperature. Replace TYPE by "cryostat" or -# "heater" to specify it. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Hardware used for actuation, i.e. laser, gas lamp, filament, resistive -# -# -# -# -# -# -# -# -# -# General device information of the optical spectroscopy setup, if -# suitable (e.g. for a tabletop spectrometer or other non-custom build setups). -# For custom build setups, this may be limited to the construction year. -# -# -# -# -# -# -# -# -# -# Commercial or otherwise defined given name of the program that was -# used to control any parts of the optical spectroscopy setup. -# The uppercase TYPE should be replaced by a specification name, i.e. -# "software_detector" or "software_stage" to specify the respective -# program or software components. -# -# -# -# Either version with build number, commit hash, or description of a -# (online) repository where the source code of the program and build -# instructions can be found so that the program can be configured in -# such a way that result files can be created ideally in a -# deterministic manner. -# -# -# -# -# Description of the software by persistent resource, where the program, -# code, script etc. can be found. -# -# -# -# -# -# -# Pre-calibration of an arbitrary device of the instrumental setup, which -# has the name DEVICE. You can specify here how, at which time by which method -# the calibration was done. As well the accuracy and a link to the calibration -# dataset. -# -# -# -# Path to the device, which was calibrated. -# Example: entry/instrument/DEVICE -# -# -# -# -# Provide data about the determined accuracy of the device, this may -# may be a single value or a dataset like wavelength error vs. wavelength etc. -# -# -# -# -# Was a calibration performed? If yes, when was it done? If the -# calibration time is provided, it should be specified in -# ENTRY/INSTRUMENT/calibration/calibration_time. -# -# -# -# -# -# -# -# -# -# -# -# If calibtration status is 'calibration time provided', specify the -# ISO8601 date when calibration was last performed before this -# measurement. UTC offset should be specified. -# -# -# -# -# Generic data which does not fit to the 'NX_FLOAT' fields in NXproces. -# This can be for example the instrument response function. -# -# -# -# -# -# The overall resolution of the optical instrument. -# -# -# -# -# -# -# -# -# -# Minimum distinguishable wavelength separation of peaks in spectra. -# -# -# -# -# -# Array of pairs of complex refractive indices n + ik of the medium -# for every measured spectral point/wavelength/energy. -# Only necessary if the measurement was performed not in air, or -# something very well known, e.g. high purity water. -# -# -# -# -# -# -# -# -# -# Properties of the sample, such as sample type, layer structure, -# chemical formula, atom types, its history etc. -# Information about the sample stage and sample environment should be -# described in ENTRY/INSTRUMENT/sample_stage. -# -# -# -# -# Locally unique ID of the sample, used in the reasearch institute or group. -# -# -# -# -# State the form of the sample, examples are: -# thin film, single crystal, poly crystal, amorphous, single layer, -# multi layer, liquid, gas, pellet, powder. -# Generic properties of liquids or gases see NXsample properties. -# -# -# -# -# Free text description of the sample. -# -# -# -# -# Chemical formula of the sample. Use the Hill system (explained here: -# https://en.wikipedia.org/wiki/Chemical_formula#Hill_system) to write -# the chemical formula. In case the sample consists of several layers, -# this should be a list of the chemical formulas of the individual -# layers, where the first entry is the chemical formula of the top -# layer (the one on the front surface, on which the light incident). -# The order must be consistent with layer_structure -# -# -# -# -# List of comma-separated elements from the periodic table that are -# contained in the sample. If the sample substance has multiple -# components, all elements from each component must be included in -# 'atom_types'. -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC information -# when the specimen was prepared. -# -# Ideally, report the end of the preparation, i.e. the last known timestamp when -# the measured specimen surface was actively prepared. -# -# -# -# -# A set of activities that occurred to the sample prior to/during the experiment. -# -# -# -# -# Sample temperature (either controlled or just measured). -# -# -# -# If no sensor was available for the determination of temperature, selected -# a nominal value which represents approximately the situation of sample temperature. -# -# -# -# -# -# -# -# -# -# -# If temperature_nominal is "other", enter here a nominal/assumed/estimated -# sample temperature. -# -# -# -# -# Temperature sensor measuring the sample temperature. -# This should be a link to /entry/instrument/manipulator/temperature_sensor. -# -# -# -# -# Device to heat the sample. -# This should be a link to /entry/instrument/manipulator/sample_heater. -# -# -# -# -# Device for cooling the sample (Cryostat, Airflow cooler, etc.). -# This should be a link to /entry/instrument/manipulator/cryostat. -# -# -# -# -# -# Arbirary sample property which may be varied during the experiment -# and controlled by a device. Examples are pressure, voltage, magnetic field etc. -# Similar to the temperautre description of the sample. -# -# -# -# Medium, in which the sample is placed. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# (Measured) sample thickness. -# -# The information is recorded to qualify if the light used was likely -# able to shine through the sample. -# -# In this case the value should be set to the actual thickness of -# the specimen viewed for an illumination situation where the nominal -# surface normal of the specimen is parallel to the optical axis. -# -# -# -# -# If a thickness if given, please specify how this thickness was estimated or -# determined. -# -# -# -# -# -# Qualitative description of the layer structure for the sample, -# starting with the top layer (i.e. the one on the front surface, on -# which the light incident), e.g. native oxide/bulk substrate, or -# Si/native oxide/thermal oxide/polymer/peptide. -# -# -# -# -# Specify the sample orientation, how is its sample normal oriented -# relative in the laboratory reference frame, incident beam reference -# frame. -# -# -# -# -# If the sample is grown or fixed on a substrate, specify this here by -# a free text description. -# -# -# -# -# -# Here generic types of data may be saved.. This may refer to data derived -# from single or multiple raw measurements (i.e. several intensities are -# evaluated for different parameters: ellipsometry -> psi and delta) - -# i.e. non-raw data. -# As well plotable data may be stored/linked here, which provides the most suitable -# representation of the data (for the respective community). -# -# You may provide multiple instances of NXdata -# -# -# -# Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) -# -# -# -# -# Spectrum, i.e. y-axis of the data (e.g. counts, intensity) -# -# -# -# -# -# -# -# Location to save the calibrated wavelength data. -# -# -# -# -# -# -# -# -# Parameters that are derived from the measured data. -# -# -# -# Light loss due to depolarization as a value in [0-1]. -# -# -# -# -# -# -# -# -# -# Jones quality factor. -# -# -# -# -# -# -# -# -# -# Reflectivity. -# -# -# -# -# -# -# -# -# -# Transmittance. -# -# -# -# -# -# -# -# -# -# -# Commercial or otherwise defined given name of the program that was -# used to generate or calculate the derived parameters. -# If home written, one can provide the actual steps in the NOTE -# subfield here. -# -# -# -# -# Either version with build number, commit hash, or description of a -# (online) repository where the source code of the program and build -# instructions can be found so that the program can be configured in -# such a way that result files can be created ideally in a -# deterministic manner. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXoptical_system_em.yaml b/contributed_definitions/nyaml/NXoptical_system_em.yaml deleted file mode 100644 index bbb6eac7b2..0000000000 --- a/contributed_definitions/nyaml/NXoptical_system_em.yaml +++ /dev/null @@ -1,291 +0,0 @@ -category: base -doc: | - A container for qualifying an electron optical system. -type: group -NXoptical_system_em(NXobject): - - # NEW ISSUE: for now used to store difficult to place entries - # NEW ISSUE: all the definitions here should better be backed up by the - # work of the HMC EM glossary activities - camera_length(NX_NUMBER): - unit: NX_LENGTH - doc: - - | - Distance which is present between the specimen surface and the detector plane. - - | - xref: - spec: EMglossary - term: Camera Length - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000008 - magnification(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - The factor of enlargement of the apparent size, - not the physical size, of an object. - defocus(NX_NUMBER): - unit: NX_LENGTH - doc: | - The defocus aberration constant (oftentimes referred to as C_1_0). - See respective details in :ref:`NXaberration` class instances. - semi_convergence_angle(NX_NUMBER): - unit: NX_ANGLE - doc: - - | - The angle which is given by the semi-opening angle of the cone in a convergent - beam. - - | - xref: - spec: EMglossary - term: Convergence Angle - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000010 - field_of_view(NX_NUMBER): - unit: NX_LENGTH - doc: | - The extent of the observable parts of the specimen given the current - magnification and other settings of the instrument. - working_distance(NX_NUMBER): - unit: NX_LENGTH - doc: - - | - Distance which is determined along the optical axis within the column from (1) the - lower end of the final optical element between the source and the specimen stage; - to (2) the point where the beam is focused. - - | - xref: - spec: EMglossary - term: Working Distance - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000050 - - # probe_current and beam_current are related but not the same - # the probe_current is equal to the beam_current only right at the surface where the beam enters the specimen - # inserting a Faraday cup in the beam path measures the beam_current (along a specific location on the beam - # before it enters the specimen but it is often assumed for the practical reason that measuring right at the surface - # that the beam current is the probe current. - probe(NXcg_ellipsoid_set): - doc: | - Geometry of the cross-section formed when the primary beam shines onto the - specimen surface. - probe_current(NX_NUMBER): - unit: NX_CURRENT - doc: - - | - Electrical current which arrives at the specimen. - - | - xref: - spec: EMglossary - term: Probe Current - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000041 - - # replace with a dedicated base class to describe the dose rate, accumulated dose, dose rate history - # based on the AXON Dose monitoring suggestions, for this one could also have an NXdose_monitoring base class - # alternatively as that dose monitoring instrument as it is also described in the paper - # is a modified Faraday cup sensor one could also wrap that detector in this base dose monitoring base class - dose_management(NX_CHAR): - - # see AXON Dose monitoring paper doi:10.1017/S1551929522000840 - # this is the nominal dose rate e-/(angstrom^2*s) - doc: | - Specify further details how incipient electron or ion dose was quantified (using - beam_current, probe_current). - - # NEW ISSUE: the KIT/SCC propose: - # adding of the image_mode or field mode - # imageMode: enum: [normal_image, sad, eds, nbd, cbed] - # fieldMode: enum: [dark_field, bright_field] - tilt_correction(NX_BOOLEAN): - doc: - - | - Details about an imaging setting used during acquisition to correct perspective - distortion when imaging a tilted surface or cross section. - - | - xref: - spec: EMglossary - term: Tilt Correction - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000047 - dynamic_focus_correction(NX_BOOLEAN): - doc: - - | - Details about a dynamic focus correction used. - - | - xref: - spec: EMglossary - term: Dynamic Focus Correction - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000016 - dynamic_refocusing(NX_CHAR): - doc: - - | - Details about a workflow used to keep the specimen in focus by automatic means. - - | - xref: - spec: EMglossary - term: Dynamic Refocusing - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000017 - focal_length(NX_NUMBER): - unit: NX_LENGTH - doc: - - | - Distance which lies between the principal plane of the lens and the focal point - along the optical axis. - - | - xref: - spec: EMglossary - term: Focal Length - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000029 - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# fef210010569e0fac593cd9254f53b802c34a8c45a417cd0a6b1a41b52d01a93 -# -# -# -# -# -# A container for qualifying an electron optical system. -# -# -# -# -# Distance which is present between the specimen surface and the detector plane. -# -# This concept is related to term `Camera Length`_ of the EMglossary standard. -# -# .. _Camera Length: https://purls.helmholtz-metadaten.de/emg/EMG_00000008 -# -# -# -# -# The factor of enlargement of the apparent size, -# not the physical size, of an object. -# -# -# -# -# The defocus aberration constant (oftentimes referred to as C_1_0). -# See respective details in :ref:`NXaberration` class instances. -# -# -# -# -# The angle which is given by the semi-opening angle of the cone in a convergent -# beam. -# -# This concept is related to term `Convergence Angle`_ of the EMglossary standard. -# -# .. _Convergence Angle: https://purls.helmholtz-metadaten.de/emg/EMG_00000010 -# -# -# -# -# The extent of the observable parts of the specimen given the current -# magnification and other settings of the instrument. -# -# -# -# -# Distance which is determined along the optical axis within the column from (1) the -# lower end of the final optical element between the source and the specimen stage; -# to (2) the point where the beam is focused. -# -# This concept is related to term `Working Distance`_ of the EMglossary standard. -# -# .. _Working Distance: https://purls.helmholtz-metadaten.de/emg/EMG_00000050 -# -# -# -# -# -# Geometry of the cross-section formed when the primary beam shines onto the -# specimen surface. -# -# -# -# -# Electrical current which arrives at the specimen. -# -# This concept is related to term `Probe Current`_ of the EMglossary standard. -# -# .. _Probe Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000041 -# -# -# -# -# -# -# Specify further details how incipient electron or ion dose was quantified (using -# beam_current, probe_current). -# -# -# -# -# -# Details about an imaging setting used during acquisition to correct perspective -# distortion when imaging a tilted surface or cross section. -# -# This concept is related to term `Tilt Correction`_ of the EMglossary standard. -# -# .. _Tilt Correction: https://purls.helmholtz-metadaten.de/emg/EMG_00000047 -# -# -# -# -# Details about a dynamic focus correction used. -# -# This concept is related to term `Dynamic Focus Correction`_ of the EMglossary standard. -# -# .. _Dynamic Focus Correction: https://purls.helmholtz-metadaten.de/emg/EMG_00000016 -# -# -# -# -# Details about a workflow used to keep the specimen in focus by automatic means. -# -# This concept is related to term `Dynamic Refocusing`_ of the EMglossary standard. -# -# .. _Dynamic Refocusing: https://purls.helmholtz-metadaten.de/emg/EMG_00000017 -# -# -# -# -# Distance which lies between the principal plane of the lens and the focal point -# along the optical axis. -# -# This concept is related to term `Focal Length`_ of the EMglossary standard. -# -# .. _Focal Length: https://purls.helmholtz-metadaten.de/emg/EMG_00000029 -# -# -# diff --git a/contributed_definitions/nyaml/NXpeak.yaml b/contributed_definitions/nyaml/NXpeak.yaml deleted file mode 100644 index 66e5a9c541..0000000000 --- a/contributed_definitions/nyaml/NXpeak.yaml +++ /dev/null @@ -1,139 +0,0 @@ -category: base -doc: | - Base class for describing a peak, its functional form, and support values - (i.e., the discretization (points) at which the function has been evaluated). -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - dimRank: | - Rank of the dependent and independent data arrays (for - multidimensional/multivariate fit.) -type: group -NXpeak(NXobject): - label(NX_CHAR): - doc: | - Human-readable label which specifies which concept/entity - the peak represents/identifies. - data(NXdata): - position(NX_NUMBER): - unit: NX_ANY - doc: | - Position values along one or more data dimensions (to hold the - values for the independent variable). - dimensions: - rank: dimRank - doc: | - The ``position`` field must have the same rank (``dimRank``) - as the ``intensity`` field. Each individual dimension of ``position`` - must have the same number of points as the corresponding dimension in - the ``intensity`` field. - dim: [] - intensity(NX_NUMBER): - unit: NX_ANY - doc: | - This array holds the intensity/count values of the fitted peak at each position. - dimensions: - rank: dimRank - doc: | - The ``intensity`` field must have the same rank (``dimRank``) - as the ``intensity`` field. Each individual dimension of ``position`` - must have the same number of points as the corresponding dimension in - the ``position`` field. - dim: [] - function(NXfit_function): - doc: | - The functional form of the peak. This could be a Gaussian, Lorentzian, - Voigt, etc. - total_area(NX_NUMBER): - unit: NX_ANY - doc: | - Total area under the curve. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 68e3d1c34fd21241aad36095e5b4bd937b868e7ff36860025bb55a6e78e4d0bb -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Rank of the dependent and independent data arrays (for -# multidimensional/multivariate fit.) -# -# -# -# -# Base class for describing a peak, its functional form, and support values -# (i.e., the discretization (points) at which the function has been evaluated). -# -# -# -# Human-readable label which specifies which concept/entity -# the peak represents/identifies. -# -# -# -# -# -# Position values along one or more data dimensions (to hold the -# values for the independent variable). -# -# -# -# The ``position`` field must have the same rank (``dimRank``) -# as the ``intensity`` field. Each individual dimension of ``position`` -# must have the same number of points as the corresponding dimension in -# the ``intensity`` field. -# -# -# -# -# -# This array holds the intensity/count values of the fitted peak at each position. -# -# -# -# The ``intensity`` field must have the same rank (``dimRank``) -# as the ``intensity`` field. Each individual dimension of ``position`` -# must have the same number of points as the corresponding dimension in -# the ``position`` field. -# -# -# -# -# -# -# The functional form of the peak. This could be a Gaussian, Lorentzian, -# Voigt, etc. -# -# -# -# -# Total area under the curve. -# -# -# diff --git a/contributed_definitions/nyaml/NXphysical_process.yaml b/contributed_definitions/nyaml/NXphysical_process.yaml deleted file mode 100644 index f4d81c95bd..0000000000 --- a/contributed_definitions/nyaml/NXphysical_process.yaml +++ /dev/null @@ -1,92 +0,0 @@ -category: base -doc: | - A planned or unplanned process which results in physical changes in a specified material. - - A physical change involve changes only in intermolecular forces, not in the chemical bonds. - Examples include sample preparation, material transformation, or (partially) destructive measurements. -type: group -NXphysical_process(NXobject): - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code (with local time zone offset to UTC information - included) when this process started. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code (with local time zone offset to UTC information - included) when this process ended. - description: - doc: | - Short description of the activity. - method: - doc: | - Method by which this process was performed. - notes(NXnote): - doc: | - This can be any data or other descriptor acquired during the physical process - (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2cea2a56950dd56002cd6da9efbf7115622c989e4e09e1b05223b6c6e8e1dde8 -# -# -# -# -# -# A planned or unplanned process which results in physical changes in a specified material. -# -# A physical change involve changes only in intermolecular forces, not in the chemical bonds. -# Examples include sample preparation, material transformation, or (partially) destructive measurements. -# -# -# -# ISO 8601 formatted time code (with local time zone offset to UTC information -# included) when this process started. -# -# -# -# -# ISO 8601 formatted time code (with local time zone offset to UTC information -# included) when this process ended. -# -# -# -# -# Short description of the activity. -# -# -# -# -# Method by which this process was performed. -# -# -# -# -# This can be any data or other descriptor acquired during the physical process -# (NXnote allows to add pictures, audio, movies). Alternatively, a -# reference to the location or a unique identifier or other metadata file. In the -# case these are not available, free-text description. -# -# -# diff --git a/contributed_definitions/nyaml/NXpid.yaml b/contributed_definitions/nyaml/NXpid.yaml deleted file mode 100644 index cf7e1f77f6..0000000000 --- a/contributed_definitions/nyaml/NXpid.yaml +++ /dev/null @@ -1,183 +0,0 @@ -category: base -doc: | - Contains the settings of a PID controller. -type: group -NXpid(NXobject): - description: - doc: | - Description of how the Process Value for the PID controller is produced by sensor(s) in the setup. - - For example, a set of sensors could be averaged over before feeding it back into the loop. - pv_sensor(NXsensor): - doc: | - The sensor representing the Process Value used in the feedback loop for the PID. - - In case multiple sensors were used, this NXsensor should contain the proper calculated/aggregated value. - value_log(NXlog): - value(NX_NUMBER): - doc: | - The actual timeseries data fed back to the PID loop. - setpoint(NX_FLOAT): - unit: NX_ANY - doc: | - The Setpoint(s) used as an input for the PID controller. - - It can also be a link to an NXsensor.value field. - setpoint_log(NXlog): - doc: | - Time log of the setpoint(s) used as an input for the PID controller. - K_p_value(NX_NUMBER): - doc: | - Proportional term. The proportional term produces an output value - that is proportional to the current error value. - The proportional response can be adjusted by multiplying the error - by a constant Kp, called the proportional gain constant. - The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows I = P/T. - K_i_value(NX_NUMBER): - doc: | - The contribution from the integral term is proportional to both - the magnitude of the error and the duration of the error. - The integral in a PID controller is the sum of the instantaneous - error over time and gives the accumulated offset that should have - been corrected previously. The accumulated error is then - multiplied by the integral gain (Ki) and added to the - controller output. - K_d_value(NX_NUMBER): - doc: | - The derivative of the process error is calculated by determining - the slope of the error over time and multiplying this rate of - change by the derivative gain K_d. The magnitude of the - contribution of the derivative term to the overall control - action is termed the derivative gain, K_d - K_t_const(NX_NUMBER): - unit: NX_TIME - doc: | - The Type switches controller parameters between P/I (proportional gain/integral - gain) and P/T (proportional gain/time constant). The formula for the controller - in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and - time constant are related as follows I = P/T. - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f7e9d17617b925bb83d4b43f19f7a739ce4023290ecdec013a07c0a3d3d8ac7f -# -# -# -# -# -# Contains the settings of a PID controller. -# -# -# -# Description of how the Process Value for the PID controller is produced by sensor(s) in the setup. -# -# For example, a set of sensors could be averaged over before feeding it back into the loop. -# -# -# -# -# The sensor representing the Process Value used in the feedback loop for the PID. -# -# In case multiple sensors were used, this NXsensor should contain the proper calculated/aggregated value. -# -# -# -# -# The actual timeseries data fed back to the PID loop. -# -# -# -# -# -# -# The Setpoint(s) used as an input for the PID controller. -# -# It can also be a link to an NXsensor.value field. -# -# -# -# -# Time log of the setpoint(s) used as an input for the PID controller. -# -# -# -# -# Proportional term. The proportional term produces an output value -# that is proportional to the current error value. -# The proportional response can be adjusted by multiplying the error -# by a constant Kp, called the proportional gain constant. -# The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows I = P/T. -# -# -# -# -# The contribution from the integral term is proportional to both -# the magnitude of the error and the duration of the error. -# The integral in a PID controller is the sum of the instantaneous -# error over time and gives the accumulated offset that should have -# been corrected previously. The accumulated error is then -# multiplied by the integral gain (Ki) and added to the -# controller output. -# -# -# -# -# The derivative of the process error is calculated by determining -# the slope of the error over time and multiplying this rate of -# change by the derivative gain K_d. The magnitude of the -# contribution of the derivative term to the overall control -# action is termed the derivative gain, K_d -# -# -# -# -# The Type switches controller parameters between P/I (proportional gain/integral -# gain) and P/T (proportional gain/time constant). The formula for the controller -# in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and -# time constant are related as follows I = P/T. -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# diff --git a/contributed_definitions/nyaml/NXprocess_mpes.yaml b/contributed_definitions/nyaml/NXprocess_mpes.yaml deleted file mode 100644 index c72c49a95e..0000000000 --- a/contributed_definitions/nyaml/NXprocess_mpes.yaml +++ /dev/null @@ -1,534 +0,0 @@ -category: base -doc: | - :ref:`NXprocess_mpes` describes events of data processing, reconstruction, - or analysis for photoemission-related data. - - It extends the NXprocess class and provides a glossary of explicitly named processes - and their metadata which are typical for photoemission data. - - For now, the extension of NXprocess is performed by simply copying all existing groups, fields, - and attibute from NXprocess. In the future, it is envisioned that this extension can be solved by - base class inheritance. -type: group -NXprocess_mpes(NXobject): - program(NX_CHAR): - doc: | - Name of the program used - sequence_index(NX_POSINT): - doc: | - Sequence index of processing, - for determining the order of multiple **NXprocess** steps. - Starts with 1. - version(NX_CHAR): - doc: | - Version of the program used - date(NX_DATE_TIME): - doc: | - Date and time of processing. - energy_calibration(NXcalibration): - doc: | - Calibration event on the energy axis. - - For XPS, the calibration should ideally be performed according to - `ISO 15472:2010`_ specification. - - .. _ISO 15472:2010: https://www.iso.org/standard/74811.html - physical_quantity: - enumeration: [energy] - calibrated_axis(NX_FLOAT): - unit: NX_ENERGY - doc: | - This is the calibrated energy axis to be used for data plotting. - kN_calibration(NXcalibration): - doc: | - Calibration event on a k-space axis. - - It is envisioned that the individual calibrations for each coordinate are - stored as kx_calibration, ky_calibration, kz_calibration, in accordance - with the axis name definitions in NXdata_mpes. - - It is also possible to have k_parallel_calibration and k_perp_calibration if - the momentum axes are defined as k_parallel and k_perp for the parallel and - perpendicular momenta, respectively. - physical_quantity: - enumeration: [momentum] - calibrated_axis(NX_FLOAT): - unit: NX_WAVENUMBER - doc: | - This is the calibrated k-space axis to be used for data plotting. - angularN_calibration(NXcalibration): - doc: | - Calibration event of an angular axis. - - It is envisioned that the individual calibrations for each angle are - stored as angular0_calibration, angular1_calibration, etc., in accordance - with the axis name definitions in NXdata_mpes. - physical_quantity: - enumeration: [angle] - calibrated_axis(NX_FLOAT): - unit: NX_ANGLE - doc: | - This is the calibrated angular axis to be used for data plotting. - spatialN_calibration(NXcalibration): - doc: | - Calibration event of a spatial axis. - - It is envisioned that the individual calibrations for each angle are - stored as spatial0_calibration, spatial1_calibration, etc., in accordance - with the axis name definitions in NXdata_mpes. - physical_quantity: - enumeration: [space] - calibrated_axis(NX_FLOAT): - unit: NX_LENGTH - doc: | - This is the calibrated spatial axis to be used for data plotting. - delay_calibration(NXcalibration): - doc: | - Calibration event of the delay time. - physical_quantity: - enumeration: [time] - calibrated_axis(NX_FLOAT): - unit: NX_TIME - doc: | - This is the calibrated delay time axis to be used for data plotting. - polarization_angle_calibration(NXcalibration): - doc: | - Calibration event of the beam polarization angle. - physical_quantity: - enumeration: [beam polarization angle] - calibrated_axis(NX_FLOAT): - unit: NX_ANGLE - doc: | - This is the calibrated polarization angle axis to be used for data plotting. - ellipticity_calibration(NXcalibration): - doc: | - Calibration event of the ellipticity of the incoming or outgoing beam. - physical_quantity: - enumeration: [beam ellipticity] - calibrated_axis(NX_FLOAT): - unit: NX_ANGLE - doc: | - This is the calibrated ellipticity axis to be used for data plotting. - energy_referencing(NXcalibration): - doc: - - | - For energy referencing, the measured energies are corrected for the charging potential - (i.e., the electrical potential of the surface region of an insulating sample, caused by - irradiation) such that those energies correspond to a sample with no surface charge. - Usually, the energy axis is adjusted by shifting all energies uniformally until one - well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. - - | - xref: - spec: ISO 18115-1:2023 - term: 12.74 ff. - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 - physical_quantity: - enumeration: [energy] - level(NXelectron_level): - doc: | - Electronic core or valence level that was used for the calibration. - reference_peak: - doc: | - Reference peak that was used for the calibration. - - For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge | vacuum level - binding_energy(NX_FLOAT): - unit: NX_ENERGY - doc: - - | - The binding energy (in units of eV) that the specified emission line appeared at, - after adjusting the binding energy scale. - - | - xref: - spec: ISO 18115-1:2023 - term: 12.16 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - offset(NX_FLOAT): - unit: NX_ENERGY - doc: | - Offset between measured binding energy and calibrated binding energy of the - emission line. - calibrated_axis(NX_FLOAT): - unit: NX_ENERGY - doc: | - This is the calibrated energy axis to be used for data plotting. - - This should link to /entry/data/energy. - transmission_correction(NXcalibration): - doc: | - In the transmission correction, each intensity measurement for electrons of a given - kinetic energy is multiplied by the corresponding value in the relative_intensity - field of the transmission_function. This calibration procedure is used to account for - the different tranmsission efficiencies when using different lens modes. - transmission_function(NXdata): - doc: | - Transmission function of the electron analyser. - - The transmission function (TF) specifies the detection efficiency for electrons of - different kinetic energy passing through the electron analyser. - This can be a link to /entry/instrument/electronanalyser/transmission_function. - \@signal: - enumeration: [relative_intensity] - \@axes: - enumeration: [kinetic_energy] - kinetic_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - Kinetic energy values - dimensions: - rank: 1 - dim: [[1, n_transmission_function]] - relative_intensity(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Relative transmission efficiency for the given kinetic energies - dimensions: - rank: 1 - dim: [[1, n_transmission_function]] - (NXregistration): - doc: | - Describes the operations of image registration - (NXdistortion): - doc: | - Describes the operations of image distortion correction - (NXcalibration): - doc: | - Describes the operations of calibration procedures, e.g. axis calibrations. - (NXnote): - doc: | - The note will contain information about how the data was processed - or anything about the data provenance. - The contents of the note can be anything that the processing code - can understand, or simple text. - - The name will be numbered to allow for ordering of steps. - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f7eae0ccfa2244399969cf9dae4780f55d857f5326e033565198ca26a01ab9da -# -# -# -# -# -# :ref:`NXprocess_mpes` describes events of data processing, reconstruction, -# or analysis for photoemission-related data. -# -# It extends the NXprocess class and provides a glossary of explicitly named processes -# and their metadata which are typical for photoemission data. -# -# For now, the extension of NXprocess is performed by simply copying all existing groups, fields, -# and attibute from NXprocess. In the future, it is envisioned that this extension can be solved by -# base class inheritance. -# -# -# -# Name of the program used -# -# -# -# -# Sequence index of processing, -# for determining the order of multiple **NXprocess** steps. -# Starts with 1. -# -# -# -# -# Version of the program used -# -# -# -# -# Date and time of processing. -# -# -# -# -# Calibration event on the energy axis. -# -# For XPS, the calibration should ideally be performed according to -# `ISO 15472:2010`_ specification. -# -# .. _ISO 15472:2010: https://www.iso.org/standard/74811.html -# -# -# -# -# -# -# -# -# This is the calibrated energy axis to be used for data plotting. -# -# -# -# -# -# Calibration event on a k-space axis. -# -# It is envisioned that the individual calibrations for each coordinate are -# stored as kx_calibration, ky_calibration, kz_calibration, in accordance -# with the axis name definitions in NXdata_mpes. -# -# It is also possible to have k_parallel_calibration and k_perp_calibration if -# the momentum axes are defined as k_parallel and k_perp for the parallel and -# perpendicular momenta, respectively. -# -# -# -# -# -# -# -# -# This is the calibrated k-space axis to be used for data plotting. -# -# -# -# -# -# Calibration event of an angular axis. -# -# It is envisioned that the individual calibrations for each angle are -# stored as angular0_calibration, angular1_calibration, etc., in accordance -# with the axis name definitions in NXdata_mpes. -# -# -# -# -# -# -# -# -# This is the calibrated angular axis to be used for data plotting. -# -# -# -# -# -# Calibration event of a spatial axis. -# -# It is envisioned that the individual calibrations for each angle are -# stored as spatial0_calibration, spatial1_calibration, etc., in accordance -# with the axis name definitions in NXdata_mpes. -# -# -# -# -# -# -# -# -# This is the calibrated spatial axis to be used for data plotting. -# -# -# -# -# -# Calibration event of the delay time. -# -# -# -# -# -# -# -# -# This is the calibrated delay time axis to be used for data plotting. -# -# -# -# -# -# Calibration event of the beam polarization angle. -# -# -# -# -# -# -# -# -# This is the calibrated polarization angle axis to be used for data plotting. -# -# -# -# -# -# Calibration event of the ellipticity of the incoming or outgoing beam. -# -# -# -# -# -# -# -# -# This is the calibrated ellipticity axis to be used for data plotting. -# -# -# -# -# -# For energy referencing, the measured energies are corrected for the charging potential -# (i.e., the electrical potential of the surface region of an insulating sample, caused by -# irradiation) such that those energies correspond to a sample with no surface charge. -# Usually, the energy axis is adjusted by shifting all energies uniformally until one -# well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. -# -# This concept is related to term `12.74 ff.`_ of the ISO 18115-1:2023 standard. -# -# .. _12.74 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 -# -# -# -# -# -# -# -# -# Electronic core or valence level that was used for the calibration. -# -# -# -# -# Reference peak that was used for the calibration. -# -# For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge | vacuum level -# -# -# -# -# The binding energy (in units of eV) that the specified emission line appeared at, -# after adjusting the binding energy scale. -# -# This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. -# -# .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 -# -# -# -# -# Offset between measured binding energy and calibrated binding energy of the -# emission line. -# -# -# -# -# This is the calibrated energy axis to be used for data plotting. -# -# This should link to /entry/data/energy. -# -# -# -# -# -# In the transmission correction, each intensity measurement for electrons of a given -# kinetic energy is multiplied by the corresponding value in the relative_intensity -# field of the transmission_function. This calibration procedure is used to account for -# the different tranmsission efficiencies when using different lens modes. -# -# -# -# Transmission function of the electron analyser. -# -# The transmission function (TF) specifies the detection efficiency for electrons of -# different kinetic energy passing through the electron analyser. -# This can be a link to /entry/instrument/electronanalyser/transmission_function. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Kinetic energy values -# -# -# -# -# -# -# -# Relative transmission efficiency for the given kinetic energies -# -# -# -# -# -# -# -# -# -# Describes the operations of image registration -# -# -# -# -# Describes the operations of image distortion correction -# -# -# -# -# Describes the operations of calibration procedures, e.g. axis calibrations. -# -# -# -# -# The note will contain information about how the data was processed -# or anything about the data provenance. -# The contents of the note can be anything that the processing code -# can understand, or simple text. -# -# The name will be numbered to allow for ordering of steps. -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# -# -# diff --git a/contributed_definitions/nyaml/NXprogram.yaml b/contributed_definitions/nyaml/NXprogram.yaml deleted file mode 100644 index 6ed4c73bf4..0000000000 --- a/contributed_definitions/nyaml/NXprogram.yaml +++ /dev/null @@ -1,76 +0,0 @@ -category: base -doc: | - Base class to describe a software tool or library. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXprogram(NXobject): - program: - doc: | - Given name of the program. Program can be a commercial one a script, - or a library or a library component. - \@version: - doc: | - Program version plus build number, or commit hash. - \@url: - doc: | - Description of an ideally ever persistent resource where the source code - of the program or this specific compiled version of the program can be - found so that the program yields repeatably exactly the same numerical - and categorical results. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# deb86f979481479d020585dbe1ca8456068519a38b0d4d6ce494d40c562da2ba -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Base class to describe a software tool or library. -# -# -# -# Given name of the program. Program can be a commercial one a script, -# or a library or a library component. -# -# -# -# Program version plus build number, or commit hash. -# -# -# -# -# Description of an ideally ever persistent resource where the source code -# of the program or this specific compiled version of the program can be -# found so that the program yields repeatably exactly the same numerical -# and categorical results. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXpulser_apm.yaml b/contributed_definitions/nyaml/NXpulser_apm.yaml deleted file mode 100644 index d172923812..0000000000 --- a/contributed_definitions/nyaml/NXpulser_apm.yaml +++ /dev/null @@ -1,414 +0,0 @@ -category: base -doc: | - Base class for a laser- and/or voltage-pulsing device used in atom probe - microscopy. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - p: | - Number of pulses collected in between start_time and end_time - resolved by an instance of :ref:`NXevent_data_apm`. -type: group -NXpulser_apm(NXobject): - (NXfabrication): - pulse_mode(NX_CHAR): - doc: | - Detail whereby ion extraction is triggered methodologically. - enumeration: [laser, voltage, laser_and_voltage] - - # the example of how the IFES APT TC's HDF format deals with such data - # conceptually, concepts are mixed into superconcepts interleaved tuple with - # different units: "PulseFrequency : Real array, 2xn (Hz) This is the frequency of - # the high voltage or laser pulser. first entry : first pulse number where the - # spacing between this and all subsequent pulses are considered to be at the - # selected frequency. Each first entry must be strictly increasing in value. The - # second entry contains the frequency value" as data can be compressed in this - # case very efficiently we go for with an array of length 1xn_ions - pulse_frequency(NX_FLOAT): - unit: NX_FREQUENCY - doc: | - Frequency with which the pulser fire(s). - dimensions: - rank: 1 - dim: [[1, p]] - \@logged_against: - type: NX_CHAR - doc: | - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - pulse_fraction(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Fraction of the pulse_voltage that is applied in addition - to the standing_voltage at peak voltage of a pulse. - - If a standing voltage is applied, this gives nominal pulse fraction - (as a function of standing voltage). Otherwise, this field should - not be present. - dimensions: - rank: 1 - dim: [[1, p]] - \@logged_against: - type: NX_CHAR - doc: | - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - - # example of a conditional requirement that can be dealt with igorously by OWL but not by NeXus! - # as either pulse_voltage is required in an appdef but then that - # existence constraint is independent of other values. - pulse_voltage(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - Pulsed voltage, in laser pulsing mode this field can be omitted. - dimensions: - rank: 1 - dim: [[1, p]] - \@logged_against: - type: NX_CHAR - doc: | - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - pulse_number(NX_UINT): - unit: NX_UNITLESS - doc: | - Absolute number of pulses starting from the beginning of the experiment. - dimensions: - rank: 1 - dim: [[1, p]] - \@logged_against: - type: NX_CHAR - doc: | - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - - # eventually equivalent to pulse_identifier within NXevent_data_apm - standing_voltage(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - Direct current voltage between the specimen and the (local electrode) in - the case of local electrode atom probe (LEAP) instrument. Otherwise, the - standing voltage applied to the sample, relative to system ground. - dimensions: - rank: 1 - dim: [[1, p]] - \@logged_against: - type: NX_CHAR - doc: | - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - (NXsource): - doc: | - Atom probe microscopes use controlled laser, voltage, or a combination of - pulsing strategies to trigger ion extraction via exciting and eventual field evaporation - field emission of ion at the specimen surface. - name(NX_CHAR): - doc: | - Given name/alias. - (NXfabrication): - wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - Nominal wavelength of the laser radiation. - power(NX_FLOAT): - unit: NX_POWER - doc: | - Nominal power of the laser source while illuminating the specimen. - pulse_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - Average energy of the laser at peak of each pulse. - dimensions: - rank: 1 - dim: [[1, p]] - \@logged_against: - type: NX_CHAR - doc: | - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - (NXbeam): - doc: | - Details about specific positions along the laser beam - which illuminates the (atom probe) specimen. - incidence_vector(NX_NUMBER): - unit: NX_LENGTH - doc: | - Track time-dependent settings over the course of the measurement - how the laser beam shines on the specimen, i.e. the mean vector - is parallel to the laser propagation direction. - dimensions: - rank: 2 - dim: [[1, p], [2, 3]] - \@logged_against: - type: NX_CHAR - doc: | - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - pinhole_position(NX_NUMBER): - unit: NX_LENGTH - doc: | - Track time-dependent settings over the course of the measurement - where the laser beam exits the focusing optics. - dimensions: - rank: 2 - dim: [[1, p], [2, 3]] - \@logged_against: - type: NX_CHAR - doc: | - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - spot_position(NX_NUMBER): - unit: NX_LENGTH - doc: | - Track time-dependent settings over the course of the - measurement where the laser hits the specimen. - dimensions: - rank: 2 - dim: [[1, p], [2, 3]] - \@logged_against: - type: NX_CHAR - doc: | - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - (NXtransformations): - doc: | - Affine transformations which describe the geometry how the - laser focusing optics/pinhole-attached coordinate system is - defined, how it has to be transformed so that it aligns with - the specimen coordinate system. - - # A right-handed Cartesian coordinate system, the so-called laser space, - # should be assumed, whose positive z-axis points - # into the direction of the propagating laser beam. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e7e7e3d1886ee2dedae01f73002da0057b76fd9327bd305b231a15a1621e7cb0 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of pulses collected in between start_time and end_time -# resolved by an instance of :ref:`NXevent_data_apm`. -# -# -# -# -# Base class for a laser- and/or voltage-pulsing device used in atom probe -# microscopy. -# -# -# -# -# Detail whereby ion extraction is triggered methodologically. -# -# -# -# -# -# -# -# -# -# -# Frequency with which the pulser fire(s). -# -# -# -# -# -# -# Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. -# -# -# -# -# -# Fraction of the pulse_voltage that is applied in addition -# to the standing_voltage at peak voltage of a pulse. -# -# If a standing voltage is applied, this gives nominal pulse fraction -# (as a function of standing voltage). Otherwise, this field should -# not be present. -# -# -# -# -# -# -# Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. -# -# -# -# -# -# -# Pulsed voltage, in laser pulsing mode this field can be omitted. -# -# -# -# -# -# -# Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. -# -# -# -# -# -# Absolute number of pulses starting from the beginning of the experiment. -# -# -# -# -# -# -# Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. -# -# -# -# -# -# -# Direct current voltage between the specimen and the (local electrode) in -# the case of local electrode atom probe (LEAP) instrument. Otherwise, the -# standing voltage applied to the sample, relative to system ground. -# -# -# -# -# -# -# Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. -# -# -# -# -# -# Atom probe microscopes use controlled laser, voltage, or a combination of -# pulsing strategies to trigger ion extraction via exciting and eventual field evaporation -# field emission of ion at the specimen surface. -# -# -# -# Given name/alias. -# -# -# -# -# -# Nominal wavelength of the laser radiation. -# -# -# -# -# Nominal power of the laser source while illuminating the specimen. -# -# -# -# -# Average energy of the laser at peak of each pulse. -# -# -# -# -# -# -# Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. -# -# -# -# -# -# Details about specific positions along the laser beam -# which illuminates the (atom probe) specimen. -# -# -# -# Track time-dependent settings over the course of the measurement -# how the laser beam shines on the specimen, i.e. the mean vector -# is parallel to the laser propagation direction. -# -# -# -# -# -# -# -# Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. -# -# -# -# -# -# Track time-dependent settings over the course of the measurement -# where the laser beam exits the focusing optics. -# -# -# -# -# -# -# -# Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. -# -# -# -# -# -# Track time-dependent settings over the course of the -# measurement where the laser hits the specimen. -# -# -# -# -# -# -# -# Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. -# -# -# -# -# -# -# Affine transformations which describe the geometry how the -# laser focusing optics/pinhole-attached coordinate system is -# defined, how it has to be transformed so that it aligns with -# the specimen coordinate system. -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXpump.yaml b/contributed_definitions/nyaml/NXpump.yaml deleted file mode 100644 index a8fb3b9a36..0000000000 --- a/contributed_definitions/nyaml/NXpump.yaml +++ /dev/null @@ -1,60 +0,0 @@ -category: base -doc: | - Device to reduce an atmosphere (real or simulated) to a controlled pressure. -type: group -NXpump(NXobject): - (NXfabrication): - design(NX_CHAR): - doc: | - Principle type of the pump. - enumeration: [membrane, rotary_vane, roots, turbo_molecular] - - # NEW ISSUE: take community input and work further to store what is relevant to report about pumps - # NEW ISSUE: see e.g. https://www.youtube.com/watch?v=Nsr_AdTiIIA for a discussion about - # NEW ISSUE: the role, pros and cons of pump used for atom probe microscopy - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 5e160f93c9e2ffcab9c04e29500c0c4ecc1e0b65fbdbd00f822893e9d9a32872 -# -# -# -# -# -# Device to reduce an atmosphere (real or simulated) to a controlled pressure. -# -# -# -# -# Principle type of the pump. -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXraman.yaml b/contributed_definitions/nyaml/NXraman.yaml deleted file mode 100644 index 61fcb90a00..0000000000 --- a/contributed_definitions/nyaml/NXraman.yaml +++ /dev/null @@ -1,448 +0,0 @@ -category: application -doc: | - An application definition for Raman spectrocopy experiments. - - Such experiments may be as simple a single Raman spectrum from spontanous - Raman scattering and range to Raman imaging Raman spectrometer, - surface- and tip-enhanced Raman techniques, x-Ray Raman scattering, as well - as resonant Raman scattering phenomena or multidimenional Raman spectra (i.e. - varying temperature, pressure, electric field, ....) - - The application definition contains two things: - 1. The structures in the application definition of NXopt: - * Instrument and data calibrations - * Sensors for sample or beam conditions - - AND - - 2. The strucutres specified and extended in NXraman: - * description of the experiment type - * descroption of the setup's meta data and optical elements (source, monochromator, detector, waveplate, lens, etc.) - * description of beam properties and their relations to the sample - * sample information - - Information on Raman spectroscopy are provided in: - - General - - * Lewis, Ian R.; Edwards, Howell G. M. - Handbook of Raman Spectroscopy - ISBN 0-8247-0557-2 - - Raman scattering selection rules - - * Dresselhaus, M. S.; Dresselhaus, G.; Jorio, A. - Group Theory - Application to the Physics ofCondensed Matter - ISBN 3540328971 - - Semiconductors - - * Manuel Cardona - Light Scattering in Solids I - eBook ISBN: 978-3-540-37568-5 - DOI: https://doi.org/10.1007/978-3-540-37568-5 - - * Manuel Cardona, Gernot Güntherodt - Light Scattering in Solids II - eBook ISBN: 978-3-540-39075-6 - DOI: https://doi.org/10.1007/3-540-11380-0 - - * See as well other Books from the "Light Scattering in Solids" series: - III: Recent Results - IV: Electronic Scattering, Spin Effects, SERS, and Morphic Effects - V: Superlattices and Other Microstructures - VI: Recent Results, Including High-Tc Superconductivity - VII: Crystal-Field and Magnetic Excitations - VIII: Fullerenes, Semiconductor Surfaces, Coherent Phonons - IX: Novel Materials and Techniques - - Glasses, Liquids, Gasses, ... - - Review articles: - Stimulated Raman scattering, Coherent anti-Stokes Raman scattering, - Surface-enhanced Raman scattering, Tip-enhanced Raman scattering - * https://doi.org/10.1186/s11671-019-3039-2 -symbols: - doc: | - Variables used throughout the document, e.g. dimensions or parameters. - N_spectrum: | - Length of the spectrum array (e.g. wavelength or energy) of the measured - data. - N_measurements: | - Number of measurements (1st dimension of measured_data array). This is - equal to the number of parameters scanned. For example, if the experiment - was performed at three different temperatures and two different pressures - N_measurements = 2*3 = 6. - N_detection_angles: | - Number of detection angles of the beam reflected or scattered off the - sample. - N_incident_angles: | - Number of angles of incidence of the incident beam. - N_scattering_configurations: | - Number of scattering configurations used in the measurement. - It is 1 for only parallel polarization meausement, 2 for parallel and cross - polarization measurement or larger, if i.e. the incident and scattered photon - direction is varied. - -# N_incident_wavelengths: | -# Number of the incident wavelen -# N_incident_beams: | -# to be done.... - -# 04/2024 -# A draft version of a NeXus application definition for Raman spectroscopy. - -# 09/2024 -# TODO (Workshop output): -# - Talk with VIBSO people - possible to syncrhonize raman_experiment_type with this ontology? -# - Similar to ellipsometry: Seperate in-situ from resonant/non-resonant stuff: OR maybe allow multiple selections? -# - Shorten raman_experiment_type by removal of Raman_spectroscopy, but as well fix the Raman Reader in the same run -# - Which for more dataconverters: Output from usualy Raman setups to neXus format? -# - Spot size description? -# - Descroption of defocusing / maybe as well as experiment_type? -# Wishes for NXraman or general next workshop: -# "convert excisting data to NeXus" -# "dictionary lookup keywords/fields in existing formats"(?) -# Template for specific experiments (i.e. too complex to get into NeXus/FAIRdata?) - unclear what to do. -# coorporation with VIBSO ontology? -# dataset examples (i.e. NXdata_raman) -type: group -NXraman(NXoptical_spectroscopy): - (NXentry): - definition: - doc: | - An application definition for Raman spectrsocopy. - \@version: - doc: | - Version number to identify which definition of this application - definition was used for this entry/data. - \@URL: - doc: | - URL where to find further material (documentation, examples) relevant - to the application definition. - enumeration: [NXraman] - title: - exists: recommended - experiment_type: - doc: | - Specify the type of the optical experiment. - - You may specify fundamental characteristics or properties in the experimental sub-type. - enumeration: [Raman spectroscopy] - raman_experiment_type: - doc: | - Specify the type of Raman experiment. - enumeration: [in situ Raman spectroscopy, resonant Raman spectroscopy, non-resonant Raman spectroscopy, Raman imaging, tip-enhanced Raman spectroscopy (TERS), surface-enhanced Raman spectroscopy (SERS), surface plasmon polariton enhanced Raman scattering (SPPERS), hyper Raman spectroscopy (HRS), stimulated Raman spectroscopy (SRS), inverse Raman spectroscopy (IRS), coherent anti-Stokes Raman spectroscopy (CARS), other] - - # enumeration: [in situ, resonant, non-resonant, imaging, tip-enhanced (TERS), surface-enhanced (SERS), surface plasmon polariton enhanced (SPPERS), hyper Raman spectroscopy (HRS), stimulated (SRS), inverse (IRS), coherent anti-Stokes (CARS), other] - raman_experiment_type_other: - exists: optional - doc: | - If the raman_experiment_type is `other`, a name should be specified here. - (NXinstrument): - doc: | - Metadata of the setup, its optical elements and physical properites which - defines the Raman measurement. - scattering_configuration(NX_CHAR): - doc: | - Scattering configuration as defined by the porto notation by three - states, which are othogonal to each other. Example: z(xx)z for - parallel polarized backscattering configuration. - - See: - https://www.cryst.ehu.es/cgi-bin/cryst/programs/nph-doc-raman - - A(BC)D - - A = The propagation direction of the incident light (k_i) - B = The polarization direction of the incident light (E_i) - C = The polarization direction of the scattered light (E_s) - D = The propagation direction of the scattered light (k_s) - - An orthogonal base is assumed. - Linear polarized light is displayed by e.g. "x","y" or "z" - Unpolarized light is displayed by "." - For non-orthogonal vectors, use the attribute porto_notation_vectors. - \@porto_notation_vectors: - type: NX_NUMBER - exists: recommended - doc: | - Scattering configuration as defined by the porto notation given by - respective vectors. - - Vectors in the porto notation are defined as for A, B, C, D above. - Linear light polarization is assumed. - dimensions: - rank: 3 - doc: | - 3 x 4 Matrix, which lists the porto notation vectors A, B, C, D. - A has to be perpendicular to B and C perpendicular to D. - dim: [[1, 4], [2, 3], [3, N_scattering_configurations]] - beam_incident(NXbeam): - doc: | - Beam which is incident to the sample. - wavelength(NX_NUMBER): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 22950da7434494ce975a35a79d24daf563a86b13264633852c950b2633add6a3 -# -# -# -# -# -# -# -# -# -# Variables used throughout the document, e.g. dimensions or parameters. -# -# -# -# Length of the spectrum array (e.g. wavelength or energy) of the measured -# data. -# -# -# -# -# Number of measurements (1st dimension of measured_data array). This is -# equal to the number of parameters scanned. For example, if the experiment -# was performed at three different temperatures and two different pressures -# N_measurements = 2*3 = 6. -# -# -# -# -# Number of detection angles of the beam reflected or scattered off the -# sample. -# -# -# -# -# Number of angles of incidence of the incident beam. -# -# -# -# -# Number of scattering configurations used in the measurement. -# It is 1 for only parallel polarization meausement, 2 for parallel and cross -# polarization measurement or larger, if i.e. the incident and scattered photon -# direction is varied. -# -# -# -# -# An application definition for Raman spectrocopy experiments. -# -# Such experiments may be as simple a single Raman spectrum from spontanous -# Raman scattering and range to Raman imaging Raman spectrometer, -# surface- and tip-enhanced Raman techniques, x-Ray Raman scattering, as well -# as resonant Raman scattering phenomena or multidimenional Raman spectra (i.e. -# varying temperature, pressure, electric field, ....) -# -# The application definition contains two things: -# 1. The structures in the application definition of NXopt: -# * Instrument and data calibrations -# * Sensors for sample or beam conditions -# -# AND -# -# 2. The strucutres specified and extended in NXraman: -# * description of the experiment type -# * descroption of the setup's meta data and optical elements (source, monochromator, detector, waveplate, lens, etc.) -# * description of beam properties and their relations to the sample -# * sample information -# -# Information on Raman spectroscopy are provided in: -# -# General -# -# * Lewis, Ian R.; Edwards, Howell G. M. -# Handbook of Raman Spectroscopy -# ISBN 0-8247-0557-2 -# -# Raman scattering selection rules -# -# * Dresselhaus, M. S.; Dresselhaus, G.; Jorio, A. -# Group Theory - Application to the Physics ofCondensed Matter -# ISBN 3540328971 -# -# Semiconductors -# -# * Manuel Cardona -# Light Scattering in Solids I -# eBook ISBN: 978-3-540-37568-5 -# DOI: https://doi.org/10.1007/978-3-540-37568-5 -# -# * Manuel Cardona, Gernot Güntherodt -# Light Scattering in Solids II -# eBook ISBN: 978-3-540-39075-6 -# DOI: https://doi.org/10.1007/3-540-11380-0 -# -# * See as well other Books from the "Light Scattering in Solids" series: -# III: Recent Results -# IV: Electronic Scattering, Spin Effects, SERS, and Morphic Effects -# V: Superlattices and Other Microstructures -# VI: Recent Results, Including High-Tc Superconductivity -# VII: Crystal-Field and Magnetic Excitations -# VIII: Fullerenes, Semiconductor Surfaces, Coherent Phonons -# IX: Novel Materials and Techniques -# -# Glasses, Liquids, Gasses, ... -# -# Review articles: -# Stimulated Raman scattering, Coherent anti-Stokes Raman scattering, -# Surface-enhanced Raman scattering, Tip-enhanced Raman scattering -# * https://doi.org/10.1186/s11671-019-3039-2 -# -# -# -# -# An application definition for Raman spectrsocopy. -# -# -# -# Version number to identify which definition of this application -# definition was used for this entry/data. -# -# -# -# -# URL where to find further material (documentation, examples) relevant -# to the application definition. -# -# -# -# -# -# -# -# -# -# Specify the type of the optical experiment. -# -# You may specify fundamental characteristics or properties in the experimental sub-type. -# -# -# -# -# -# -# -# Specify the type of Raman experiment. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If the raman_experiment_type is `other`, a name should be specified here. -# -# -# -# -# Metadata of the setup, its optical elements and physical properites which -# defines the Raman measurement. -# -# -# -# Scattering configuration as defined by the porto notation by three -# states, which are othogonal to each other. Example: z(xx)z for -# parallel polarized backscattering configuration. -# -# See: -# https://www.cryst.ehu.es/cgi-bin/cryst/programs/nph-doc-raman -# -# A(BC)D -# -# A = The propagation direction of the incident light (k_i) -# B = The polarization direction of the incident light (E_i) -# C = The polarization direction of the scattered light (E_s) -# D = The propagation direction of the scattered light (k_s) -# -# An orthogonal base is assumed. -# Linear polarized light is displayed by e.g. "x","y" or "z" -# Unpolarized light is displayed by "." -# For non-orthogonal vectors, use the attribute porto_notation_vectors. -# -# -# -# Scattering configuration as defined by the porto notation given by -# respective vectors. -# -# Vectors in the porto notation are defined as for A, B, C, D above. -# Linear light polarization is assumed. -# -# -# -# 3 x 4 Matrix, which lists the porto notation vectors A, B, C, D. -# A has to be perpendicular to B and C perpendicular to D. -# -# -# -# -# -# -# -# -# -# Beam which is incident to the sample. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXreflectron.yaml b/contributed_definitions/nyaml/NXreflectron.yaml deleted file mode 100644 index 496051480a..0000000000 --- a/contributed_definitions/nyaml/NXreflectron.yaml +++ /dev/null @@ -1,136 +0,0 @@ -category: base -doc: | - Base class for a device which reduces ToF differences of ions in ToF experiments. - - For atom probe the reflectron can be considered an energy compensation device. - Such a device can be realized technically for example with a Poschenrieder lens. - - Consult the following U.S. patents for further details: - - * 3863068 and 6740872 for the reflectron - * 8134119 for the curved reflectron -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - p: | - Number of pulses collected in between start_time and end_time - resolved by an instance of :ref:`NXevent_data_apm`. -type: group -NXreflectron(NXobject): - status(NX_CHAR): - doc: | - Status of eventual existence and potential usage of this reflectron. - enumeration: [none, present, used] - name(NX_CHAR): - doc: | - Given name/alias. - (NXfabrication): - description(NX_CHAR): - doc: | - Free-text field to specify further details about the reflectron. - The field can be used to inform e. g. if the reflectron is flat or curved. - voltage(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - The maximum voltage applied to the reflectron, relative to system ground. - - # dim: (p,) - (NXtransformations): - doc: | - Affine transformation(s) which detail where the reflectron is located - relative to e.g. the origin of the specimen space reference coordinate - system. This group can also be used for specifying how the reflectron - is rotated relative to a given axis in the instrument. - - # The purpose of these more detailed instrument descriptions - # is to support the creation of a digital twin of the instrument - # for computational science. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# cc621f6e28c41b09ee131c7789672e97df02c74e31351ea7f006f1a1d609bad5 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of pulses collected in between start_time and end_time -# resolved by an instance of :ref:`NXevent_data_apm`. -# -# -# -# -# Base class for a device which reduces ToF differences of ions in ToF experiments. -# -# For atom probe the reflectron can be considered an energy compensation device. -# Such a device can be realized technically for example with a Poschenrieder lens. -# -# Consult the following U.S. patents for further details: -# -# * 3863068 and 6740872 for the reflectron -# * 8134119 for the curved reflectron -# -# -# -# Status of eventual existence and potential usage of this reflectron. -# -# -# -# -# -# -# -# -# -# Given name/alias. -# -# -# -# -# -# Free-text field to specify further details about the reflectron. -# The field can be used to inform e. g. if the reflectron is flat or curved. -# -# -# -# -# The maximum voltage applied to the reflectron, relative to system ground. -# -# -# -# -# -# Affine transformation(s) which detail where the reflectron is located -# relative to e.g. the origin of the specimen space reference coordinate -# system. This group can also be used for specifying how the reflectron -# is rotated relative to a given axis in the instrument. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXregistration.yaml b/contributed_definitions/nyaml/NXregistration.yaml deleted file mode 100644 index 1d37bbc6e9..0000000000 --- a/contributed_definitions/nyaml/NXregistration.yaml +++ /dev/null @@ -1,80 +0,0 @@ -category: base -doc: | - Describes image registration procedures. -type: group -NXregistration(NXobject): - applied(NX_BOOLEAN): - doc: | - Has the registration been applied? - last_process(NX_CHAR): - doc: | - Indicates the name of the last operation applied in the NXprocess sequence. - depends_on(NX_CHAR): - doc: | - Specifies the position by pointing to the last transformation in the - transformation chain in the NXtransformations group. - (NXtransformations): - doc: | - To describe the operations of image registration (combinations of rigid - translations and rotations) - description(NX_CHAR): - doc: | - Description of the procedures employed. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a6b823cc2bf2162f3fbc06d84d1ea5625a81489e35f930e5aea1dc9d71ffc04e -# -# -# -# -# -# Describes image registration procedures. -# -# -# -# Has the registration been applied? -# -# -# -# -# Indicates the name of the last operation applied in the NXprocess sequence. -# -# -# -# -# Specifies the position by pointing to the last transformation in the -# transformation chain in the NXtransformations group. -# -# -# -# -# To describe the operations of image registration (combinations of rigid -# translations and rotations) -# -# -# -# -# Description of the procedures employed. -# -# -# diff --git a/contributed_definitions/nyaml/NXresolution.yaml b/contributed_definitions/nyaml/NXresolution.yaml deleted file mode 100644 index 6b433c7389..0000000000 --- a/contributed_definitions/nyaml/NXresolution.yaml +++ /dev/null @@ -1,202 +0,0 @@ -category: base -doc: | - Describes the resolution of a physical quantity. -type: group -NXresolution(NXobject): - physical_quantity: - doc: | - The physical quantity of the resolution, e.g., - energy, momentum, time, etc. - type: - doc: | - The process by which the resolution was determined. - enumeration: [estimated, derived, calibrated, other] - note(NXnote): - doc: | - Additional details of the estimate or description of the calibration procedure - resolution(NX_FLOAT): - unit: NX_ANY - doc: | - The resolution of the physical quantity. - resolution_errors(NX_FLOAT): - unit: NX_ANY - doc: | - Standard deviation of the resolution of the physical quantity. - relative_resolution(NX_FLOAT): - unit: NX_ANY - doc: | - Ratio of the resolution at a specified measurand value to that measurand value, - relative_resolution_errors(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Standard deviation of the relative resolution of the physical quantity. - response_function(NXdata): - doc: | - The response of the instrument or part to a infinitesimally sharp input signal - along the physical quantity of this group. - This is also sometimes called instrument response function for time resolution or - point spread function for spatial response. - The resolution is typically determined by taking the full width at half maximum (FWHM) - of the response function. - input(NX_FLOAT): - unit: NX_ANY - doc: | - The input axis or grid of the response function. - The unit should match the one of the resolution field. - magnitude(NX_FLOAT): - doc: | - The magnitude of the response function corresponding to the points - in the input axis or grid. - This field should have the same dimensions as `input`. - formula_SYMBOL(NX_CHAR): - doc: | - A symbol linking to another path in this appdef to be referred to from the - `resolution_formula` field. This should be a valid path inside this application - definition, i.e., of the form /entry/instrument/my_part/my_field. - resolution_formula(NX_CHAR): - doc: | - A resolution formula to determine the resolution from a set of symbols as - entered by the `formula_...` fields. - The output unit should match the provided unit of this field. - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - (NXcalibration): - doc: | - For storing details and data of a calibration to derive a resolution from data. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 354ca53d42e75b920aa0abc13f3156051cf9d0bcfd1a61ff852d0ba6d763da6c -# -# -# -# -# -# Describes the resolution of a physical quantity. -# -# -# -# The physical quantity of the resolution, e.g., -# energy, momentum, time, etc. -# -# -# -# -# The process by which the resolution was determined. -# -# -# -# -# -# -# -# -# -# -# Additional details of the estimate or description of the calibration procedure -# -# -# -# -# The resolution of the physical quantity. -# -# -# -# -# Standard deviation of the resolution of the physical quantity. -# -# -# -# -# Ratio of the resolution at a specified measurand value to that measurand value, -# -# -# -# -# Standard deviation of the relative resolution of the physical quantity. -# -# -# -# -# The response of the instrument or part to a infinitesimally sharp input signal -# along the physical quantity of this group. -# This is also sometimes called instrument response function for time resolution or -# point spread function for spatial response. -# The resolution is typically determined by taking the full width at half maximum (FWHM) -# of the response function. -# -# -# -# The input axis or grid of the response function. -# The unit should match the one of the resolution field. -# -# -# -# -# The magnitude of the response function corresponding to the points -# in the input axis or grid. -# This field should have the same dimensions as `input`. -# -# -# -# -# -# A symbol linking to another path in this appdef to be referred to from the -# `resolution_formula` field. This should be a valid path inside this application -# definition, i.e., of the form /entry/instrument/my_part/my_field. -# -# -# -# -# A resolution formula to determine the resolution from a set of symbols as -# entered by the `formula_...` fields. -# The output unit should match the provided unit of this field. -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# For storing details and data of a calibration to derive a resolution from data. -# -# -# diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml deleted file mode 100644 index 59cf99dfc2..0000000000 --- a/contributed_definitions/nyaml/NXroi.yaml +++ /dev/null @@ -1,46 +0,0 @@ -category: base -doc: | - Base class to describe a region-of-interest analyzed. -type: group -NXroi(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# b87390b078845006b944da546aacc15b774fdb1f4287ebeb1619493ab1246ddf -# -# -# -# -# -# Base class to describe a region-of-interest analyzed. -# -# -# -# Details about processing steps. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXrotation_set.yaml b/contributed_definitions/nyaml/NXrotation_set.yaml deleted file mode 100644 index 8ca8cf4220..0000000000 --- a/contributed_definitions/nyaml/NXrotation_set.yaml +++ /dev/null @@ -1,466 +0,0 @@ -category: base -doc: | - Base class to detail a set of rotations, orientations, and disorientations. - - For getting a more detailed insight into the discussion of the - parameterized description of orientations in materials science see: - - * `H.-J. Bunge `_ - * `T. B. Britton et al. `_ - * `D. Rowenhorst et al. `_ - * `A. Morawiec `_ - - Once orientations are defined, one can continue to characterize the - misorientation and specifically the disorientation. The misorientation describes - the rotation that is required to register the lattices of two oriented objects - (like crystal lattice) into a crystallographic equivalent orientation: - - * `R. Bonnet `_ - -# This class stores a set of specifically parameterized NXtransformations which describe -# how each object is oriented/rotated with respect to a reference coordinate system. -# we should offer here support for d==2, d==3 -# several well accepted parameterizations for rotations exists in Materials Science -# thus not using NXtransformations, different Materials Science groups follow -# different conventions not every reporting of rotations is consistent and correct -# having a base class like the one proposed here offers a suggestion to start -# discussing at all about how to convert between groups who report using -# different conventions -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - c: | - The cardinality of the set, i.e. the number of value tuples. - n_phases: | - How many phases with usually different crystal and symmetry are distinguished. -type: group -NXrotation_set(NXobject): - depends_on(NX_CHAR): - doc: | - Reference to an instance of :ref:`NXcoordinate_system_set` which contextualizes - how the here reported parameterized quantities can be interpreted. - - # 2D rotations are a special type of 3D rotations and thus treated in 3D - # just how to rotate the object into the reference frame defined by depends_on - crystal_symmetry(NX_CHAR): - doc: | - Point group which defines the symmetry of the crystal. - - This has to be at least a single string. If crystal_symmetry is not - provided point group 1 is assumed. - - In the case that misorientation or disorientation fields are used - and the two crystal sets resolve for phases with a different - crystal symmetry, this field has to encode two string. - In this case the first string is for phase A the second one for phase B. - An example of this most complex case is the description of the - disorientation between crystals adjoining a hetero-phase boundary. - dimensions: - rank: 1 - dim: [[1, n_phases]] - sample_symmetry(NX_CHAR): - doc: | - Point group which defines an assumed symmetry imprinted upon processing - the material/sample which could give rise to or may justify to use a - simplified description of rotations, orientations, misorientations, - and disorientations via numerical procedures that are known as - symmetrization. - - If sample_symmetry is not provided point group 1 is assumed. - - The traditionally used symmetrization operations within the texture - community in Materials Science, though, are thanks to methodology and - software improvements no longer strictly needed. Therefore, users are - encouraged to set the sample_symmetry to 1 (triclinic) and thus assume - there is no justification to assume the imprinting of additional - symmetry because of the processing. - - In practice one often faces situations where indeed these assumed - symmetries are anyway not fully observed, and thus an accepting of - eventual inaccuracies just for the sake of reporting a simplified - symmetrized description should be avoided. - dimensions: - rank: 1 - dim: [[1, n_phases]] - rotation_quaternion(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - The set of rotations expressed in quaternion parameterization considering - crystal_symmetry and sample_symmetry. Rotations which should be - interpreted as antipodal are not marked as such. - dimensions: - rank: 2 - dim: [[1, c], [2, 4]] - rotation_euler(NX_NUMBER): - unit: NX_ANGLE - doc: | - The set of rotations expressed in Euler angle parameterization considering - the same applied symmetries as detailed for the field rotation_quaternion. - To interpret Euler angles correctly, it is necessary to inspect the - conventions behind depends_on to resolve which of the many Euler-angle - conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] - - # rotation_rodrigues(NX_NUMBER): - # rotation_homochoric(NX_NUMBER): - # rotation_axis_angle(NX_NUMBER): - - # orientation how to rotate the crystal into sample and vice versa obeying crystal and sample symmetry - is_antipodal(NX_BOOLEAN): - doc: | - True for all those value tuples which have assumed antipodal symmetry. - False for all others. - dimensions: - rank: 1 - dim: [[1, c]] - orientation_quaternion(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - The set of orientations expressed in quaternion parameterization and - obeying symmetry for equivalent cases as detailed in crystal_symmetry - and sample_symmetry. The supplementary field is_antipodal can be used - to mark orientations with the antipodal property. - dimensions: - rank: 2 - dim: [[1, c], [2, 4]] - orientation_euler(NX_NUMBER): - unit: NX_ANGLE - doc: | - The set of orientations expressed in Euler angle parameterization following - the same assumptions like for orientation_quaternion. - To interpret Euler angles correctly, it is necessary to inspect the - conventions behind depends_on to resolve which of the many Euler-angle - conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] - - # orientation_rodrigues(NX_NUMBER): - # orientation_homochoric(NX_NUMBER): - # orientation_axis_angle(NX_NUMBER): - - # misorientation between two orientations - # not the disorientation because for misorientation we ignore - # if the angular argument may not have the absolute smallest amount, i.e. - # misorientation is not necessarily in the fundamental zone - misorientation_quaternion(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - The set of misorientations expressed in quaternion parameterization - obeying symmetry operations for equivalent misorientations - as defined by crystal_symmetry and sample_symmetry. - dimensions: - rank: 2 - dim: [[1, c], [2, 4]] - misorientation_angle(NX_NUMBER): - unit: NX_ANGLE - doc: | - Misorientation angular argument (eventually signed) following the same - symmetry assumptions as expressed for the field misorientation_quaternion. - dimensions: - rank: 1 - dim: [[1, c]] - misorientation_axis(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - Misorientation axis (normalized) and signed following the same - symmetry assumptions as expressed for the field misorientation_angle. - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] - - # disorientation, misorientation with smallest angular argument inside - # fundamental zone of SO3 for given crystal and sample symmetry - disorientation_quaternion(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - The set of disorientation expressed in quaternion parameterization - obeying symmetry operations for equivalent misorientations - as defined by crystal_symmetry and sample_symmetry. - dimensions: - rank: 2 - dim: [[1, c], [2, 4]] - disorientation_angle(NX_NUMBER): - unit: NX_ANGLE - doc: | - Disorientation angular argument (should not be signed, see - `D. Rowenhorst et al. `_) - following the same symmetry assumptions as expressed for the field - disorientation_quaternion. - dimensions: - rank: 1 - dim: [[1, c]] - disorientation_axis(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - Disorientation axis (normalized) following the same symmetry assumptions - as expressed for the field disorientation_angle. - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] - - # e.g. in this way one could easily, efficiently, store and map familiar habits of microscopists - # to store e.g. orientations of measurement points or of grains via a (c := Ngrains, n_p := 3) - # matrix of Bunge-Euler angles, or of (c := Ngrains, n_p := 4) matrix of quaternions. - # the benefit of such a representation is that with a known NXorientation_set base class one can implement a common parameterization transformation library (of which several already exist) in the microstructure modelling communities so that a program can read the information in the (NXorientation_set) instance and automatically transform/compute between different parameterizations. Super relevant for interoperability e.g. in SEM/EBSD, where this was a long standing issue and right now the most frequently accepted consensus is to report either Bunge-Euler angles or quaternions and then use existent transformation libraries (as implemented by e.g. Marc de Graeff for SEM/EBSD and used by many but not yet the majority of people in the computational materials modelling community within crystal plasticity, crystal growth modeling, DREAM.3D) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# da83249c1855975c1652bd2121fc383c93553586da1287d4ef488b25f3167526 -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The cardinality of the set, i.e. the number of value tuples. -# -# -# -# -# How many phases with usually different crystal and symmetry are distinguished. -# -# -# -# -# Base class to detail a set of rotations, orientations, and disorientations. -# -# For getting a more detailed insight into the discussion of the -# parameterized description of orientations in materials science see: -# -# * `H.-J. Bunge <https://doi.org/10.1016/C2013-0-11769-2>`_ -# * `T. B. Britton et al. <https://doi.org/10.1016/j.matchar.2016.04.008>`_ -# * `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_ -# * `A. Morawiec <https://doi.org/10.1007/978-3-662-09156-2>`_ -# -# Once orientations are defined, one can continue to characterize the -# misorientation and specifically the disorientation. The misorientation describes -# the rotation that is required to register the lattices of two oriented objects -# (like crystal lattice) into a crystallographic equivalent orientation: -# -# * `R. Bonnet <https://doi.org/10.1107/S0567739480000186>`_ -# -# -# -# Reference to an instance of :ref:`NXcoordinate_system_set` which contextualizes -# how the here reported parameterized quantities can be interpreted. -# -# -# -# -# -# Point group which defines the symmetry of the crystal. -# -# This has to be at least a single string. If crystal_symmetry is not -# provided point group 1 is assumed. -# -# In the case that misorientation or disorientation fields are used -# and the two crystal sets resolve for phases with a different -# crystal symmetry, this field has to encode two string. -# In this case the first string is for phase A the second one for phase B. -# An example of this most complex case is the description of the -# disorientation between crystals adjoining a hetero-phase boundary. -# -# -# -# -# -# -# -# Point group which defines an assumed symmetry imprinted upon processing -# the material/sample which could give rise to or may justify to use a -# simplified description of rotations, orientations, misorientations, -# and disorientations via numerical procedures that are known as -# symmetrization. -# -# If sample_symmetry is not provided point group 1 is assumed. -# -# The traditionally used symmetrization operations within the texture -# community in Materials Science, though, are thanks to methodology and -# software improvements no longer strictly needed. Therefore, users are -# encouraged to set the sample_symmetry to 1 (triclinic) and thus assume -# there is no justification to assume the imprinting of additional -# symmetry because of the processing. -# -# In practice one often faces situations where indeed these assumed -# symmetries are anyway not fully observed, and thus an accepting of -# eventual inaccuracies just for the sake of reporting a simplified -# symmetrized description should be avoided. -# -# -# -# -# -# -# -# The set of rotations expressed in quaternion parameterization considering -# crystal_symmetry and sample_symmetry. Rotations which should be -# interpreted as antipodal are not marked as such. -# -# -# -# -# -# -# -# -# The set of rotations expressed in Euler angle parameterization considering -# the same applied symmetries as detailed for the field rotation_quaternion. -# To interpret Euler angles correctly, it is necessary to inspect the -# conventions behind depends_on to resolve which of the many Euler-angle -# conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. -# -# -# -# -# -# -# -# -# -# -# True for all those value tuples which have assumed antipodal symmetry. -# False for all others. -# -# -# -# -# -# -# -# The set of orientations expressed in quaternion parameterization and -# obeying symmetry for equivalent cases as detailed in crystal_symmetry -# and sample_symmetry. The supplementary field is_antipodal can be used -# to mark orientations with the antipodal property. -# -# -# -# -# -# -# -# -# The set of orientations expressed in Euler angle parameterization following -# the same assumptions like for orientation_quaternion. -# To interpret Euler angles correctly, it is necessary to inspect the -# conventions behind depends_on to resolve which of the many Euler-angle -# conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. -# -# -# -# -# -# -# -# -# -# -# The set of misorientations expressed in quaternion parameterization -# obeying symmetry operations for equivalent misorientations -# as defined by crystal_symmetry and sample_symmetry. -# -# -# -# -# -# -# -# -# Misorientation angular argument (eventually signed) following the same -# symmetry assumptions as expressed for the field misorientation_quaternion. -# -# -# -# -# -# -# -# Misorientation axis (normalized) and signed following the same -# symmetry assumptions as expressed for the field misorientation_angle. -# -# -# -# -# -# -# -# -# -# The set of disorientation expressed in quaternion parameterization -# obeying symmetry operations for equivalent misorientations -# as defined by crystal_symmetry and sample_symmetry. -# -# -# -# -# -# -# -# -# Disorientation angular argument (should not be signed, see -# `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_) -# following the same symmetry assumptions as expressed for the field -# disorientation_quaternion. -# -# -# -# -# -# -# -# Disorientation axis (normalized) following the same symmetry assumptions -# as expressed for the field disorientation_angle. -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXsample_component_set.yaml b/contributed_definitions/nyaml/NXsample_component_set.yaml deleted file mode 100644 index 593b2807bb..0000000000 --- a/contributed_definitions/nyaml/NXsample_component_set.yaml +++ /dev/null @@ -1,123 +0,0 @@ -category: base -doc: | - Set of sample components and their configuration. - - The idea here is to have a united place for all materials descriptors that are not - part of the individual sample components, but rather their configuration. -symbols: - n_comp: | - number of components -type: group -NXsample_component_set(NXobject): - \@components: - doc: | - Array of strings referring to the names of the NXsample_components. - The order of these components serves as an index (starting at 1). - concentration(NX_FLOAT): - unit: NX_ANY - doc: | - Concentration of each component - dimensions: - rank: 1 - dim: [[1, n_comp]] - volume_fraction(NX_FLOAT): - unit: NX_ANY - doc: | - Volume fraction of each component - dimensions: - rank: 1 - dim: [[1, n_comp]] - scattering_length_density(NX_FLOAT): - unit: NX_ANY - doc: | - Scattering length density of each component - dimensions: - rank: 1 - dim: [[1, n_comp]] - (NXsample_component): - doc: | - Each component set can contain multiple components. - (NXsample_component_set): - doc: | - For description of a sub-component set. Can contain multiple components itself. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d6c0104267bfb3f1843228c2d31aeffaa45cf9067e45ef67f938ea7f56917407 -# -# -# -# -# -# -# -# number of components -# -# -# -# -# Set of sample components and their configuration. -# -# The idea here is to have a united place for all materials descriptors that are not -# part of the individual sample components, but rather their configuration. -# -# -# -# Array of strings referring to the names of the NXsample_components. -# The order of these components serves as an index (starting at 1). -# -# -# -# -# Concentration of each component -# -# -# -# -# -# -# -# Volume fraction of each component -# -# -# -# -# -# -# -# Scattering length density of each component -# -# -# -# -# -# -# -# Each component set can contain multiple components. -# -# -# -# -# For description of a sub-component set. Can contain multiple components itself. -# -# -# diff --git a/contributed_definitions/nyaml/NXscanbox_em.yaml b/contributed_definitions/nyaml/NXscanbox_em.yaml deleted file mode 100644 index 1ba3a51751..0000000000 --- a/contributed_definitions/nyaml/NXscanbox_em.yaml +++ /dev/null @@ -1,197 +0,0 @@ -category: base -doc: | - Scan box and coils which deflect a beam of charged particles in a controlled manner. - - The scan box is instructed by an instance of :ref:`NXprogram`, some control software, - which is not necessarily the same program as for all components of a microscope. - - The scanbox directs the probe of charged particles (electrons, ions) - to controlled locations according to a scan scheme and plan. -type: group -NXscanbox_em(NXcomponent): - - # user perspective - scan_schema(NX_CHAR): - doc: | - Name of the typically tech-partner-specific term that specifies - an automated protocol which controls the details how the components - of the microscope work together to achieve a controlled scanning of the - beam over the sample surface. - - In most cases users do not know, have to care, or are able to disentangle the - details of the spatiotemporal dynamics of the components of the microscope. - Instead, they rely on the assumption that the microscope and control software - work as expected. Selecting then a specific scan_schema assures some level - of reproducibility in the way how the beam is scanned over the surface. - calibration_style(NX_CHAR): - doc: | - TODO discuss with the electron microscopists. - center(NX_NUMBER): - unit: NX_ANY - doc: | - TODO discuss with the electron microscopists. - - # descriptors relevant from economic usage and dose management perspective - dwell_time(NX_NUMBER): - unit: NX_TIME - doc: - - | - Time period during which the beam remains at one position. - - | - xref: - spec: EMglossary - term: Dwell Time - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000015 - flyback_time(NX_NUMBER): - unit: NX_TIME - doc: - - | - Time period during which the beam moves from the final position of one scan - line to the starting position of the subsequent scan line. - - | - xref: - spec: EMglossary - term: Flyback Time - url: https://purls.helmholtz-metadaten.de/emg/EMG_00000028 - line_time(NX_NUMBER): - unit: NX_TIME - doc: | - TODO discuss with the electron microscopists. - pixel_time(NX_NUMBER): - unit: NX_TIME - doc: | - TODO discuss with the electron microscopists. - requested_pixel_time(NX_NUMBER): - unit: NX_TIME - doc: | - TODO discuss with the electron microscopists. - ac_line_sync(NX_BOOLEAN): - doc: | - TODO discuss with the electron microscopists. - rotation(NX_NUMBER): - unit: NX_ANGLE - doc: | - TODO discuss with the electron microscopists. - - # technical design perspective - # (NXlens_em): - (NXdeflector): - (NXcircuit): - - # (NXcg_point_set): - # NEW ISSUE: build on work of EMglossary with HMC and use duty cycle instead - # NEW ISSUE: make use of and define duty cycle - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 3c74c9f70e2dd5437b2d14ca67310cab2f737fa8cd8beaeba6ce3070af90a142 -# -# -# -# -# -# Scan box and coils which deflect a beam of charged particles in a controlled manner. -# -# The scan box is instructed by an instance of :ref:`NXprogram`, some control software, -# which is not necessarily the same program as for all components of a microscope. -# -# The scanbox directs the probe of charged particles (electrons, ions) -# to controlled locations according to a scan scheme and plan. -# -# -# -# -# Name of the typically tech-partner-specific term that specifies -# an automated protocol which controls the details how the components -# of the microscope work together to achieve a controlled scanning of the -# beam over the sample surface. -# -# In most cases users do not know, have to care, or are able to disentangle the -# details of the spatiotemporal dynamics of the components of the microscope. -# Instead, they rely on the assumption that the microscope and control software -# work as expected. Selecting then a specific scan_schema assures some level -# of reproducibility in the way how the beam is scanned over the surface. -# -# -# -# -# TODO discuss with the electron microscopists. -# -# -# -# -# TODO discuss with the electron microscopists. -# -# -# -# -# -# Time period during which the beam remains at one position. -# -# This concept is related to term `Dwell Time`_ of the EMglossary standard. -# -# .. _Dwell Time: https://purls.helmholtz-metadaten.de/emg/EMG_00000015 -# -# -# -# -# Time period during which the beam moves from the final position of one scan -# line to the starting position of the subsequent scan line. -# -# This concept is related to term `Flyback Time`_ of the EMglossary standard. -# -# .. _Flyback Time: https://purls.helmholtz-metadaten.de/emg/EMG_00000028 -# -# -# -# -# TODO discuss with the electron microscopists. -# -# -# -# -# TODO discuss with the electron microscopists. -# -# -# -# -# TODO discuss with the electron microscopists. -# -# -# -# -# TODO discuss with the electron microscopists. -# -# -# -# -# TODO discuss with the electron microscopists. -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXserialized.yaml b/contributed_definitions/nyaml/NXserialized.yaml deleted file mode 100644 index 08fe9b9f05..0000000000 --- a/contributed_definitions/nyaml/NXserialized.yaml +++ /dev/null @@ -1,116 +0,0 @@ -category: base -doc: | - Metadata to a set of pieces of information of a resource that has been serialized. - - A typical use case is the documentation of the source (file) or database (entry) - from which pieces of information have been extracted for consumption in e.g. a - research data management system (RDMS). This may be for reasons of enabling - services such as providing access to normalized information for which reading - again from the resource may not be desired, possibe, or feasible. - - Possible reasons could be the extraction of specific information for caching, - performance reasons, or re-evaluate given pieces of information based on other - views and interaction patterns with the data where information has been formatted - differently by tools than how these pieces of information were originally - serialized. -type: group -NXserialized(NXobject): - type(NX_CHAR): - doc: | - Answers into what resource the information was serialized. - enumeration: [file, database] - path(NX_CHAR): - doc: | - Path to the resource. - - E.g. the name of a file or its absolute or relative path, or the - identifier to a resource in another database. - checksum(NX_CHAR): - doc: | - Value of the hash that is obtained when running algorithm - on the content of the resource referred to by path. - algorithm(NX_CHAR): - doc: | - Name of the algorithm whereby the checksum was computed. - - # enumeration: [md5, sha256] - file(NXnote): - doc: | - Extracted file containing the serialized information. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# bf960ad0cfba03d3de3cc9169fcd53b2c77594d6d336cb3b198c496ac6dfd571 -# -# -# -# -# -# Metadata to a set of pieces of information of a resource that has been serialized. -# -# A typical use case is the documentation of the source (file) or database (entry) -# from which pieces of information have been extracted for consumption in e.g. a -# research data management system (RDMS). This may be for reasons of enabling -# services such as providing access to normalized information for which reading -# again from the resource may not be desired, possibe, or feasible. -# -# Possible reasons could be the extraction of specific information for caching, -# performance reasons, or re-evaluate given pieces of information based on other -# views and interaction patterns with the data where information has been formatted -# differently by tools than how these pieces of information were originally -# serialized. -# -# -# -# Answers into what resource the information was serialized. -# -# -# -# -# -# -# -# -# Path to the resource. -# -# E.g. the name of a file or its absolute or relative path, or the -# identifier to a resource in another database. -# -# -# -# -# Value of the hash that is obtained when running algorithm -# on the content of the resource referred to by path. -# -# -# -# -# Name of the algorithm whereby the checksum was computed. -# -# -# -# -# -# Extracted file containing the serialized information. -# -# -# diff --git a/contributed_definitions/nyaml/NXsingle_crystal.yaml b/contributed_definitions/nyaml/NXsingle_crystal.yaml deleted file mode 100644 index 81915a214f..0000000000 --- a/contributed_definitions/nyaml/NXsingle_crystal.yaml +++ /dev/null @@ -1,113 +0,0 @@ -category: base -doc: | - Description of a single crystal material or a single crystalline phase in a material. - - There is the option of using Busing-Levy convention (as orginally designed in NXsample) - or using a more detailed description with NXrotation_set. -type: group -NXsingle_crystal(NXobject): - sample_orientation(NX_FLOAT): - unit: NX_ANGLE - doc: | - This will follow the Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - dimensions: - rank: 1 - dim: [[1, 3]] - orientation_matrix(NX_FLOAT): - doc: | - Orientation matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - dimensions: - rank: 2 - dim: [[1, 3], [2, 3]] - ub_matrix(NX_FLOAT): - doc: | - UB matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is - the multiplication of the orientation_matrix, given above, - with the :math:`B` matrix which can be derived from the lattice constants. - dimensions: - rank: 2 - dim: [[1, 3], [2, 3]] - rotation_set(NXrotation_set): - doc: | - Detailed description of single crystal orientation and misorientation. - (NXunit_cell): - doc: | - Unit cell of the single crystal. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 12c4f0c9868e381370d85b146404c6f6c835200ad6a1ef21d9501cd4763b23b2 -# -# -# -# -# -# Description of a single crystal material or a single crystalline phase in a material. -# -# There is the option of using Busing-Levy convention (as orginally designed in NXsample) -# or using a more detailed description with NXrotation_set. -# -# -# -# This will follow the Busing-Levy convention: -# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 -# -# -# -# -# -# -# -# Orientation matrix of single crystal sample using Busing-Levy convention: -# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 -# -# -# -# -# -# -# -# -# UB matrix of single crystal sample using Busing-Levy convention: -# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is -# the multiplication of the orientation_matrix, given above, -# with the :math:`B` matrix which can be derived from the lattice constants. -# -# -# -# -# -# -# -# -# Detailed description of single crystal orientation and misorientation. -# -# -# -# -# Unit cell of the single crystal. -# -# -# diff --git a/contributed_definitions/nyaml/NXspectrum_set.yaml b/contributed_definitions/nyaml/NXspectrum_set.yaml deleted file mode 100644 index 7985b749db..0000000000 --- a/contributed_definitions/nyaml/NXspectrum_set.yaml +++ /dev/null @@ -1,986 +0,0 @@ -category: base -doc: | - Base class container for reporting a set of spectra. - - The mostly commonly used scanning methods are supported. That is one-, - two-, three-dimensional ROIs discretized using regular Euclidean tilings. - - Use stack for all other tilings. - -# https://en.wikipedia.org/wiki/Euclidean_tilings_by_convex_regular_polygons -symbols: - n_spc: | - Number of spectra in the stack, for stacks the slowest dimension. - n_k: | - Number of image points along the slower dimension (k equivalent to z). - n_j: | - Number of image points along the slow dimension (j equivalent to y). - n_i: | - Number of image points along the fast dimension (i equivalent to x). - n_energy: | - Number of energy bins (always the fastest dimension). -type: group -NXspectrum_set(NXobject): - - # for EELS we likely need a complex-valued NXspectrum_c_set to this - # NXspectrum_set base class here which should then be splitted into an - # NXspectrum_set to reduce redundant fields and specialized NXspectrum_r/c_set - (NXprocess): - doc: | - Details how spectra were processed from the detector readings. - source(NXserialized): - doc: | - Resolvable data artifact (e.g. filename) from which all values in the :ref:`NXdata` - instances in this :ref:`NXspectrum_set` were loaded during parsing. - - Possibility to document from which specific other serialized resource as the source - pieces of information were processed when using NeXus as a semantic file format - to serialize that information differently. - - The group in combination with an added field *absolute_path* therein adds context. - absolute_path(NX_CHAR): - doc: | - Reference to a location inside the artifact that points to the specific group of values - that were processed if the artifacts contains several groups of values and thus - further resolving of ambiguities is required. - mode(NX_CHAR): - doc: | - Imaging (data collection) mode of the instrument during acquisition - of the data in this :ref:`NXspectrum_set` instance. - detector_identifier(NX_CHAR): - doc: | - Link or name of an :ref:`NXdetector` instance with which the data were - collected. - (NXprogram): - - #MK::feel free to contact us when you would like to include - # like omega/q mapping more complicated scan pattern than rectangular ones. - spectrum_0d(NXdata): - doc: | - One spectrum for a point of a 0d ROI. Also known as spot measurement. - intensity(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Counts - dimensions: - rank: 1 - dim: [[1, n_energy]] - \@long_name: - type: NX_CHAR - doc: | - Counts - axis_energy(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy axis - dimensions: - rank: 1 - dim: [[1, n_energy]] - \@long_name: - type: NX_CHAR - doc: | - Energy - spectrum_1d(NXdata): - doc: | - One spectrum for each point of a 1d ROI. - intensity(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Counts - dimensions: - rank: 2 - dim: [[1, n_i], [2, n_energy]] - \@long_name: - type: NX_CHAR - doc: | - Counts - axis_i(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the fast dimension. - dimensions: - rank: 1 - dim: [[1, n_i]] - \@long_name: - type: NX_CHAR - doc: | - Point coordinate along the fast dimension - axis_energy(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy axis - dimensions: - rank: 1 - dim: [[1, n_energy]] - \@long_name: - type: NX_CHAR - doc: | - Energy - spectrum_2d(NXdata): - doc: | - One spectrum for each scan point of 2d ROI. - intensity(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Counts - dimensions: - rank: 3 - dim: [[1, n_j], [2, n_i], [3, n_energy]] - \@long_name: - type: NX_CHAR - doc: | - Counts - axis_j(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the slow dimension. - dimensions: - rank: 1 - dim: [[1, n_j]] - \@long_name: - type: NX_CHAR - doc: | - Point coordinate along the slow dimension. - axis_i(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the fast dimension. - dimensions: - rank: 1 - dim: [[1, n_i]] - \@long_name: - type: NX_CHAR - doc: | - Point coordinate along the fast dimension. - axis_energy(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy axis - dimensions: - rank: 1 - dim: [[1, n_energy]] - \@long_name: - type: NX_CHAR - doc: | - Energy - spectrum_3d(NXdata): - doc: | - One spectrum for point of a 3d ROI. - intensity(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Counts - dimensions: - rank: 4 - dim: [[1, n_k], [2, n_j], [3, n_i], [4, n_energy]] - \@long_name: - type: NX_CHAR - doc: | - Counts - axis_k(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the slower dimension. - dimensions: - rank: 1 - dim: [[1, n_k]] - \@long_name: - type: NX_CHAR - doc: | - Point coordinate along the slower dimension. - axis_j(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the slow dimension. - dimensions: - rank: 1 - dim: [[1, n_j]] - \@long_name: - type: NX_CHAR - doc: | - Point coordinate along the slow dimension. - axis_i(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the fast dimension. - dimensions: - rank: 1 - dim: [[1, n_i]] - \@long_name: - type: NX_CHAR - doc: | - Point coordinate along the fast dimension. - axis_energy(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy axis - dimensions: - rank: 1 - dim: [[1, n_energy]] - \@long_name: - type: NX_CHAR - doc: | - Energy - - # in the majority of cases rectangular or line scans are performed - # if there is interest to support arbitrary scan pattern one should use - # scan points and contact us to generalize this base class and related - # base classes - stack_0d(NXdata): - doc: | - Multiple instances of spectrum_0d. - intensity(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Counts - dimensions: - rank: 2 - dim: [[1, n_spc], [2, n_energy]] - \@long_name: - type: NX_CHAR - doc: | - Counts - group_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Group identifier - dimensions: - rank: 1 - dim: [[1, n_spc]] - \@long_name: - type: NX_CHAR - doc: | - Group identifier - spectrum_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Spectrum identifier - dimensions: - rank: 1 - dim: [[1, n_spc]] - \@long_name: - type: NX_CHAR - doc: | - Spectrum identifier - axis_energy(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy axis - dimensions: - rank: 1 - dim: [[1, n_energy]] - \@long_name: - type: NX_CHAR - doc: | - Energy - stack_2d(NXdata): - doc: | - Multiple instances of spectrum_2d. - intensity(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Counts - dimensions: - rank: 4 - dim: [[1, n_spc], [2, n_j], [3, n_i], [4, n_energy]] - \@long_name: - type: NX_CHAR - doc: | - Counts - group_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Group identifier - dimensions: - rank: 1 - dim: [[1, n_spc]] - \@long_name: - type: NX_CHAR - doc: | - Group identifier - spectrum_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Spectrum identifier - dimensions: - rank: 1 - dim: [[1, n_spc]] - \@long_name: - type: NX_CHAR - doc: | - Spectrum identifier - axis_j(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the slow dimension. - dimensions: - rank: 1 - dim: [[1, n_j]] - \@long_name: - type: NX_CHAR - doc: | - Point coordinate along the slow dimension. - axis_i(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the fast dimension. - dimensions: - rank: 1 - dim: [[1, n_i]] - \@long_name: - type: NX_CHAR - doc: | - Point coordinate along the fast dimension. - axis_energy(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy axis - dimensions: - rank: 1 - dim: [[1, n_energy]] - \@long_name: - type: NX_CHAR - doc: | - Energy - stack_3d(NXdata): - doc: | - Multiple instances of spectrum_3d. - intensity(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Counts - dimensions: - rank: 5 - dim: [[1, n_spc], [2, n_k], [3, n_j], [4, n_i], [5, n_energy]] - \@long_name: - type: NX_CHAR - doc: | - Counts - group_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Group identifier - dimensions: - rank: 1 - dim: [[1, n_spc]] - \@long_name: - type: NX_CHAR - doc: | - Group identifier - spectrum_identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Spectrum identifier - dimensions: - rank: 1 - dim: [[1, n_spc]] - \@long_name: - type: NX_CHAR - doc: | - Spectrum identifier - axis_k(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the slower dimension. - dimensions: - rank: 1 - dim: [[1, n_k]] - \@long_name: - type: NX_CHAR - doc: | - Point coordinate along the slower dimension. - axis_j(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the slow dimension. - dimensions: - rank: 1 - dim: [[1, n_j]] - \@long_name: - type: NX_CHAR - doc: | - Point coordinate along the slow dimension. - axis_i(NX_NUMBER): - unit: NX_LENGTH - doc: | - Point coordinate along the fast dimension. - dimensions: - rank: 1 - dim: [[1, n_i]] - \@long_name: - type: NX_CHAR - doc: | - Point coordinate along the fast dimension. - axis_energy(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy axis - dimensions: - rank: 1 - dim: [[1, n_energy]] - \@long_name: - type: NX_CHAR - doc: | - Energy - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4337732dc413a7a33701ab6894c7bbb5ffa26b7e5ace45143ac316990034bd67 -# -# -# -# -# -# -# -# -# Number of spectra in the stack, for stacks the slowest dimension. -# -# -# -# -# Number of image points along the slower dimension (k equivalent to z). -# -# -# -# -# Number of image points along the slow dimension (j equivalent to y). -# -# -# -# -# Number of image points along the fast dimension (i equivalent to x). -# -# -# -# -# Number of energy bins (always the fastest dimension). -# -# -# -# -# Base class container for reporting a set of spectra. -# -# The mostly commonly used scanning methods are supported. That is one-, -# two-, three-dimensional ROIs discretized using regular Euclidean tilings. -# -# Use stack for all other tilings. -# -# -# -# -# Details how spectra were processed from the detector readings. -# -# -# -# Resolvable data artifact (e.g. filename) from which all values in the :ref:`NXdata` -# instances in this :ref:`NXspectrum_set` were loaded during parsing. -# -# Possibility to document from which specific other serialized resource as the source -# pieces of information were processed when using NeXus as a semantic file format -# to serialize that information differently. -# -# The group in combination with an added field *absolute_path* therein adds context. -# -# -# -# Reference to a location inside the artifact that points to the specific group of values -# that were processed if the artifacts contains several groups of values and thus -# further resolving of ambiguities is required. -# -# -# -# -# -# Imaging (data collection) mode of the instrument during acquisition -# of the data in this :ref:`NXspectrum_set` instance. -# -# -# -# -# Link or name of an :ref:`NXdetector` instance with which the data were -# collected. -# -# -# -# -# -# -# -# One spectrum for a point of a 0d ROI. Also known as spot measurement. -# -# -# -# Counts -# -# -# -# -# -# -# Counts -# -# -# -# -# -# Energy axis -# -# -# -# -# -# -# Energy -# -# -# -# -# -# -# One spectrum for each point of a 1d ROI. -# -# -# -# Counts -# -# -# -# -# -# -# -# Counts -# -# -# -# -# -# Point coordinate along the fast dimension. -# -# -# -# -# -# -# Point coordinate along the fast dimension -# -# -# -# -# -# Energy axis -# -# -# -# -# -# -# Energy -# -# -# -# -# -# -# One spectrum for each scan point of 2d ROI. -# -# -# -# Counts -# -# -# -# -# -# -# -# -# Counts -# -# -# -# -# -# Point coordinate along the slow dimension. -# -# -# -# -# -# -# Point coordinate along the slow dimension. -# -# -# -# -# -# Point coordinate along the fast dimension. -# -# -# -# -# -# -# Point coordinate along the fast dimension. -# -# -# -# -# -# Energy axis -# -# -# -# -# -# -# Energy -# -# -# -# -# -# -# One spectrum for point of a 3d ROI. -# -# -# -# Counts -# -# -# -# -# -# -# -# -# -# Counts -# -# -# -# -# -# Point coordinate along the slower dimension. -# -# -# -# -# -# -# Point coordinate along the slower dimension. -# -# -# -# -# -# Point coordinate along the slow dimension. -# -# -# -# -# -# -# Point coordinate along the slow dimension. -# -# -# -# -# -# Point coordinate along the fast dimension. -# -# -# -# -# -# -# Point coordinate along the fast dimension. -# -# -# -# -# -# Energy axis -# -# -# -# -# -# -# Energy -# -# -# -# -# -# -# -# Multiple instances of spectrum_0d. -# -# -# -# Counts -# -# -# -# -# -# -# -# Counts -# -# -# -# -# -# Group identifier -# -# -# -# -# -# -# Group identifier -# -# -# -# -# -# Spectrum identifier -# -# -# -# -# -# -# Spectrum identifier -# -# -# -# -# -# Energy axis -# -# -# -# -# -# -# Energy -# -# -# -# -# -# -# Multiple instances of spectrum_2d. -# -# -# -# Counts -# -# -# -# -# -# -# -# -# -# Counts -# -# -# -# -# -# Group identifier -# -# -# -# -# -# -# Group identifier -# -# -# -# -# -# Spectrum identifier -# -# -# -# -# -# -# Spectrum identifier -# -# -# -# -# -# Point coordinate along the slow dimension. -# -# -# -# -# -# -# Point coordinate along the slow dimension. -# -# -# -# -# -# Point coordinate along the fast dimension. -# -# -# -# -# -# -# Point coordinate along the fast dimension. -# -# -# -# -# -# Energy axis -# -# -# -# -# -# -# Energy -# -# -# -# -# -# -# Multiple instances of spectrum_3d. -# -# -# -# Counts -# -# -# -# -# -# -# -# -# -# -# Counts -# -# -# -# -# -# Group identifier -# -# -# -# -# -# -# Group identifier -# -# -# -# -# -# Spectrum identifier -# -# -# -# -# -# -# Spectrum identifier -# -# -# -# -# -# Point coordinate along the slower dimension. -# -# -# -# -# -# -# Point coordinate along the slower dimension. -# -# -# -# -# -# Point coordinate along the slow dimension. -# -# -# -# -# -# -# Point coordinate along the slow dimension. -# -# -# -# -# -# Point coordinate along the fast dimension. -# -# -# -# -# -# -# Point coordinate along the fast dimension. -# -# -# -# -# -# Energy axis -# -# -# -# -# -# -# Energy -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXspindispersion.yaml b/contributed_definitions/nyaml/NXspindispersion.yaml deleted file mode 100644 index 28328ce4c1..0000000000 --- a/contributed_definitions/nyaml/NXspindispersion.yaml +++ /dev/null @@ -1,154 +0,0 @@ -category: base -doc: | - Subclass of NXelectronanalyser to describe the spin filters in photoemission - experiments. -type: group -NXspindispersion(NXobject): - type(NX_CHAR): - doc: | - Type of spin detector, VLEED, SPLEED, Mott, etc. - figure_of_merit(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Figure of merit of the spin detector - shermann_function(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Effective Shermann function, calibrated spin selectivity factor - scattering_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - Energy of the spin-selective scattering - scattering_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Angle of the spin-selective scattering - target(NX_CHAR): - doc: | - Name of the target - target_preparation(NX_CHAR): - doc: | - Preparation procedure of the spin target - target_preparation_date(NX_DATE_TIME): - doc: | - Date of last preparation of the spin target - depends_on(NX_CHAR): - doc: | - Specifies the position of the lens by pointing to the last transformation in the - transformation chain in the NXtransformations group. - (NXtransformations): - doc: | - Collection of axis-based translations and rotations to describe the location and - geometry of the deflector as a component in the instrument. Conventions from the - NXtransformations base class are used. In principle, the McStas coordinate - system is used. The first transformation has to point either to another - component of the system or . (for pointing to the reference frame) to relate it - relative to the experimental setup. Typically, the components of a system should - all be related relative to each other and only one component should relate to - the reference coordinate system. - (NXdeflector): - doc: | - Deflectors in the spin dispersive section - (NXlens_em): - doc: | - Individual lenses in the spin dispersive section - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 1aa3a407983adc6ddde5a0304a41f80699c70497b7c453610e5d16393a67ff93 -# -# -# -# -# -# Subclass of NXelectronanalyser to describe the spin filters in photoemission -# experiments. -# -# -# -# Type of spin detector, VLEED, SPLEED, Mott, etc. -# -# -# -# -# Figure of merit of the spin detector -# -# -# -# -# Effective Shermann function, calibrated spin selectivity factor -# -# -# -# -# Energy of the spin-selective scattering -# -# -# -# -# Angle of the spin-selective scattering -# -# -# -# -# Name of the target -# -# -# -# -# Preparation procedure of the spin target -# -# -# -# -# Date of last preparation of the spin target -# -# -# -# -# Specifies the position of the lens by pointing to the last transformation in the -# transformation chain in the NXtransformations group. -# -# -# -# -# Collection of axis-based translations and rotations to describe the location and -# geometry of the deflector as a component in the instrument. Conventions from the -# NXtransformations base class are used. In principle, the McStas coordinate -# system is used. The first transformation has to point either to another -# component of the system or . (for pointing to the reference frame) to relate it -# relative to the experimental setup. Typically, the components of a system should -# all be related relative to each other and only one component should relate to -# the reference coordinate system. -# -# -# -# -# Deflectors in the spin dispersive section -# -# -# -# -# Individual lenses in the spin dispersive section -# -# -# diff --git a/contributed_definitions/nyaml/NXstage_lab.yaml b/contributed_definitions/nyaml/NXstage_lab.yaml deleted file mode 100644 index a9f6f5f920..0000000000 --- a/contributed_definitions/nyaml/NXstage_lab.yaml +++ /dev/null @@ -1,319 +0,0 @@ -category: base -doc: | - Base class for a stage (lab) used to hold, orient, and prepare a specimen. - - Modern stages are multi-functional devices. Stages provide a controlled - environment around the specimen. Stages enable experimentalists to apply - controlled external stimuli on the specimen. A stage_lab is a multi-purpose - /-functional tool that is constructed from multiple actuators, sensors, - and other components. - - With such stages comes the need for storing various (meta)data - that are generated while working and modifying the sample. - - Modern stages realize a hierarchy of components. Two examples are given to help - clarify how :ref:`NXstage_lab` instances should be used: Take a specimen that is - mounted on a multi-axial tilt rotation holder. This holder is fixed in the - support unit which connects the holder to the rest of the instrument. - Evidently different components are all considerable as to represent instances - of stages. - - In another example, taken from atom probe microscopy, researchers may work - with wire samples which are clipped into a larger fixing unit to enable - careful specimen handling. Alternatively, a microtip is a silicon post - upon which e.g. an atom probe specimen is mounted. - Multiple microtips are grouped into a microtip array to conveniently enable - loading of multiple specimens into the instrument with fewer operations. - That microtip array is fixed on a holder. Fixture units in atom probe are known - as stubs. Stubs in turn are positioned onto pucks. Pucks are then loaded onto - carousels. A carousel is a carrier unit with which eventually entire sets of - specimens can be moved in between parts of the microscope. All of these units - can be considered stage_lab instances. - - The :ref:`NXstage_lab` base class reflects this hierarchy. To cover for an as flexible - design of complex stages as possible, users should nest multiple instances of - :ref:`NXstage_lab` according to their needs to reflect the differences between what - they consider as the holder and what they consider is the stage. - The alias field can be used to specify the community jargon if necessary. - - However, a much clearer approach to reflect the hierarchy of all :ref:`NXstage_lab` - instances is postfix each instance named stage_lab with integers starting - from 1 as the top level unit. - In the microtip example one could thus use stage_lab1 for the microtip, - stage_lab2 for the microtip array, stage_lab3 holder, etc. - The depends_on keyword should be used to additional clarify the hierarchy - especially when users decide to not follow the above-mentioned postfixing - notation or when is not obvious from the postfixes which stage_lab is at - which level of the stage_lab hierarchy. - - Some examples for stage_labs in applications: - - * A nanoparticle on a copper grid. The copper grid is the holder. - The grid itself is fixed to a stage. - * An atom probe specimen fixed in a stub. In this case the stub can be - considered the holder, while the cryostat temperature control unit is - a component of the stage. - * Samples with arrays of specimens, like a microtip on a microtip array - is an example of an at least three-layer hierarchy commonly employed for - efficient sequential processing of atom probe experiments. - * With one entry of an application definition only one microtip should be - described. Therefore, the microtip is the specimen, - the array is the holder and the remaining mounting unit - that is attached to the cryo-controller is the stage. - * For in-situ experiments with e.g. chips with read-out electronics - as actuators, the chips are again placed in a larger unit. A typical - example are in-situ experiments using e.g. the tools of `Protochips `_. - * Other examples are (quasi) in-situ experiments where experimentalists - anneal or deform the specimen via e.g. in-situ tensile testing machines - which are mounted on the specimen holder. - - For specific details and inspiration about stages in electron microscopes: - - * `Holders with multiple axes `_ - * `Chip-based designs `_ - * `Further chip-based designs `_ - * `Stages in transmission electron microscopy `_ (page 103, table 4.2) - * `Further stages in transmission electron microscopy `_ (page 124ff) - * `Specimens in atom probe `_ (page 47ff) - * `Exemplar micro-manipulators `_ - - We are looking forward to suggestions from the scientists. -type: group -NXstage_lab(NXcomponent): - design(NX_CHAR): - doc: | - Principal design of the stage. - - Exemplar terms could be side_entry, top_entry, - single_tilt, quick_change, multiple_specimen, - bulk_specimen, double_tilt, tilt_rotate, - heating_chip, atmosphere_chip, - electrical_biasing_chip, liquid_cell_chip - alias(NX_CHAR): - doc: | - Free-text field to give a term how that a stage_lab at this level of the - stage_lab hierarchy is commonly referred to. Examples could be stub, - puck, carousel, microtip, clip, holder, etc. - tilt_1(NX_NUMBER): - unit: NX_ANGLE - doc: | - The interpretation of this tilt should be specialized - and thus detailed via the application definition. - tilt_2(NX_NUMBER): - unit: NX_ANGLE - doc: | - The interpretation of this tilt should be specialized - and thus detailed via the application definition. - rotation(NX_NUMBER): - unit: NX_ANGLE - doc: | - The interpretation of this rotation should be specialized - and thus detailed via the application definition. - position(NX_NUMBER): - unit: NX_LENGTH - doc: | - The interpretation of this position should be specialized - and thus detailed via the application definition. - dimensions: - rank: 1 - dim: [[1, 3]] - bias_voltage(NX_NUMBER): - unit: NX_VOLTAGE - doc: | - Voltage applied to the stage to decelerate electrons. - - # NEW ISSUE: rather the field if possible should be specified - (NXpositioner): - (NXsensor): - - # (NXactuator): - # see for complicated positioning tools like an eucentric five-axis table stage in an SEM - # https://www.nanotechnik.com/e5as.html - # shipswing_tilt(NXpositioner): - # normal_rotate(NXpositioner): - # normal_height(NXpositioner): - # inplane_translate1(NXpositioner): - # inplane_translate2(NXpositioner): - # NEW ISSUE: add temperature control units and components to apply external stimuli - # NEW ISSUE: on the specimen such as NXmech_testing_unit and NXfurnace, NXreaction_cell - # NEW ISSUE: by contrast, the purpose and design of so-called nano/or micromanipulators, - # i.e. automatable devices to perform e.g. site-specific lift out, procedures warrants - # to define an own class NXspecimen_manipulator given this is nothing else than - # miniature robot arm essential one could also think about creating an own NXrobotarm class, - # below are two examples of such tools as they are used in FIB and SEMs - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 9194893893c4618febc96567e99b9e8fbe181bdc274e21d8b65ae4d91e5ff7bd -# -# -# -# -# -# Base class for a stage (lab) used to hold, orient, and prepare a specimen. -# -# Modern stages are multi-functional devices. Stages provide a controlled -# environment around the specimen. Stages enable experimentalists to apply -# controlled external stimuli on the specimen. A stage_lab is a multi-purpose -# /-functional tool that is constructed from multiple actuators, sensors, -# and other components. -# -# With such stages comes the need for storing various (meta)data -# that are generated while working and modifying the sample. -# -# Modern stages realize a hierarchy of components. Two examples are given to help -# clarify how :ref:`NXstage_lab` instances should be used: Take a specimen that is -# mounted on a multi-axial tilt rotation holder. This holder is fixed in the -# support unit which connects the holder to the rest of the instrument. -# Evidently different components are all considerable as to represent instances -# of stages. -# -# In another example, taken from atom probe microscopy, researchers may work -# with wire samples which are clipped into a larger fixing unit to enable -# careful specimen handling. Alternatively, a microtip is a silicon post -# upon which e.g. an atom probe specimen is mounted. -# Multiple microtips are grouped into a microtip array to conveniently enable -# loading of multiple specimens into the instrument with fewer operations. -# That microtip array is fixed on a holder. Fixture units in atom probe are known -# as stubs. Stubs in turn are positioned onto pucks. Pucks are then loaded onto -# carousels. A carousel is a carrier unit with which eventually entire sets of -# specimens can be moved in between parts of the microscope. All of these units -# can be considered stage_lab instances. -# -# The :ref:`NXstage_lab` base class reflects this hierarchy. To cover for an as flexible -# design of complex stages as possible, users should nest multiple instances of -# :ref:`NXstage_lab` according to their needs to reflect the differences between what -# they consider as the holder and what they consider is the stage. -# The alias field can be used to specify the community jargon if necessary. -# -# However, a much clearer approach to reflect the hierarchy of all :ref:`NXstage_lab` -# instances is postfix each instance named stage_lab with integers starting -# from 1 as the top level unit. -# In the microtip example one could thus use stage_lab1 for the microtip, -# stage_lab2 for the microtip array, stage_lab3 holder, etc. -# The depends_on keyword should be used to additional clarify the hierarchy -# especially when users decide to not follow the above-mentioned postfixing -# notation or when is not obvious from the postfixes which stage_lab is at -# which level of the stage_lab hierarchy. -# -# Some examples for stage_labs in applications: -# -# * A nanoparticle on a copper grid. The copper grid is the holder. -# The grid itself is fixed to a stage. -# * An atom probe specimen fixed in a stub. In this case the stub can be -# considered the holder, while the cryostat temperature control unit is -# a component of the stage. -# * Samples with arrays of specimens, like a microtip on a microtip array -# is an example of an at least three-layer hierarchy commonly employed for -# efficient sequential processing of atom probe experiments. -# * With one entry of an application definition only one microtip should be -# described. Therefore, the microtip is the specimen, -# the array is the holder and the remaining mounting unit -# that is attached to the cryo-controller is the stage. -# * For in-situ experiments with e.g. chips with read-out electronics -# as actuators, the chips are again placed in a larger unit. A typical -# example are in-situ experiments using e.g. the tools of `Protochips <https://www.protochips.com>`_. -# * Other examples are (quasi) in-situ experiments where experimentalists -# anneal or deform the specimen via e.g. in-situ tensile testing machines -# which are mounted on the specimen holder. -# -# For specific details and inspiration about stages in electron microscopes: -# -# * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ -# * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ -# * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ -# * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) -# * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) -# * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) -# * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ -# -# We are looking forward to suggestions from the scientists. -# -# -# -# Principal design of the stage. -# -# Exemplar terms could be side_entry, top_entry, -# single_tilt, quick_change, multiple_specimen, -# bulk_specimen, double_tilt, tilt_rotate, -# heating_chip, atmosphere_chip, -# electrical_biasing_chip, liquid_cell_chip -# -# -# -# -# Free-text field to give a term how that a stage_lab at this level of the -# stage_lab hierarchy is commonly referred to. Examples could be stub, -# puck, carousel, microtip, clip, holder, etc. -# -# -# -# -# The interpretation of this tilt should be specialized -# and thus detailed via the application definition. -# -# -# -# -# The interpretation of this tilt should be specialized -# and thus detailed via the application definition. -# -# -# -# -# The interpretation of this rotation should be specialized -# and thus detailed via the application definition. -# -# -# -# -# The interpretation of this position should be specialized -# and thus detailed via the application definition. -# -# -# -# -# -# -# -# Voltage applied to the stage to decelerate electrons. -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXsubstance.yaml b/contributed_definitions/nyaml/NXsubstance.yaml deleted file mode 100644 index 046ca73848..0000000000 --- a/contributed_definitions/nyaml/NXsubstance.yaml +++ /dev/null @@ -1,193 +0,0 @@ -category: base -doc: | - A form of matter with a constant, definite chemical composition. - - Examples can be single chemical elements, chemical compunds, or alloys. - For further information, see https://en.wikipedia.org/wiki/Chemical_substance. -type: group -NXsubstance(NXobject): - name: - doc: | - User-defined chemical name of the substance - molecular_mass(NX_FLOAT): - unit: NX_MOLECULAR_WEIGHT - doc: | - Molecular mass of the substance - cas_number: - doc: | - Unique numeric CAS REGISTRY number of the sample chemical content - For further information, see https://www.cas.org/. - cas_name: - doc: | - CAS REGISTRY name of the sample chemical content - cas_uri: - doc: | - CAS REGISTRY URI - cas_image(NXnote): - doc: | - CAS REGISTRY image - cas_synonyms: - doc: | - Synonyms in the CAS system. - inchi_str: - doc: | - String InChi identifier. - The InChI identifier expresses chemical structures in terms of atomic connectivity, - tautomeric state, isotopes, stereochemistry and electronic charge in order to - produce a string of machine-readable characters unique to the respective molecule. - For further information, see https://iupac.org/who-we-are/divisions/division-details/inchi/. - inchi_key: - doc: | - Condensed, 27 character InChI key. - Hashed version of the full InChI (using the SHA-256 algorithm). - iupac_name: - doc: | - Name according to the IUPAC system (standard). - For further information, see https://iupac.org/. - smile: - doc: | - Identifier in the SMILES (Simplified Molecular Input Line Entry System) system - For further information, see https://www.daylight.com/smiles/. - canonical_smile: - doc: | - Canonical version of the smiles identifier - molecular_formula_hill: - doc: | - The chemical formula specified using CIF conventions. - Abbreviated version of CIF standard:107 - This is the *Hill* system used by Chemical Abstracts. - - * Only recognized element symbols may be used. - * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. - * A space or parenthesis must separate each cluster of (element symbol + count). - * Where a group of elements is enclosed in parentheses, the multiplier for the - group must follow the closing parentheses. That is, all element and group - multipliers are assumed to be printed as subscripted numbers. - * Unless the elements are ordered in a manner that corresponds to their chemical - structure, the order of the elements within any group or moiety depends on - whether or not carbon is present. - * If carbon is present, the order should be: - - C, then H, then the other elements in alphabetical order of their symbol. - - If carbon is not present, the elements are listed purely in alphabetic order of their symbol. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# c7ae6e64d284340e8b3ad667882f9b7f3a31bf7c509b6cc8794529ec765cb25a -# -# -# -# -# -# A form of matter with a constant, definite chemical composition. -# -# Examples can be single chemical elements, chemical compunds, or alloys. -# For further information, see https://en.wikipedia.org/wiki/Chemical_substance. -# -# -# -# User-defined chemical name of the substance -# -# -# -# -# Molecular mass of the substance -# -# -# -# -# Unique numeric CAS REGISTRY number of the sample chemical content -# For further information, see https://www.cas.org/. -# -# -# -# -# CAS REGISTRY name of the sample chemical content -# -# -# -# -# CAS REGISTRY URI -# -# -# -# -# CAS REGISTRY image -# -# -# -# -# Synonyms in the CAS system. -# -# -# -# -# String InChi identifier. -# The InChI identifier expresses chemical structures in terms of atomic connectivity, -# tautomeric state, isotopes, stereochemistry and electronic charge in order to -# produce a string of machine-readable characters unique to the respective molecule. -# For further information, see https://iupac.org/who-we-are/divisions/division-details/inchi/. -# -# -# -# -# Condensed, 27 character InChI key. -# Hashed version of the full InChI (using the SHA-256 algorithm). -# -# -# -# -# Name according to the IUPAC system (standard). -# For further information, see https://iupac.org/. -# -# -# -# -# Identifier in the SMILES (Simplified Molecular Input Line Entry System) system -# For further information, see https://www.daylight.com/smiles/. -# -# -# -# -# Canonical version of the smiles identifier -# -# -# -# -# The chemical formula specified using CIF conventions. -# Abbreviated version of CIF standard:107 -# This is the *Hill* system used by Chemical Abstracts. -# -# * Only recognized element symbols may be used. -# * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. -# * A space or parenthesis must separate each cluster of (element symbol + count). -# * Where a group of elements is enclosed in parentheses, the multiplier for the -# group must follow the closing parentheses. That is, all element and group -# multipliers are assumed to be printed as subscripted numbers. -# * Unless the elements are ordered in a manner that corresponds to their chemical -# structure, the order of the elements within any group or moiety depends on -# whether or not carbon is present. -# * If carbon is present, the order should be: -# - C, then H, then the other elements in alphabetical order of their symbol. -# - If carbon is not present, the elements are listed purely in alphabetic order of their symbol. -# -# -# diff --git a/contributed_definitions/nyaml/NXunit_cell.yaml b/contributed_definitions/nyaml/NXunit_cell.yaml deleted file mode 100644 index 3bb9ecf7f2..0000000000 --- a/contributed_definitions/nyaml/NXunit_cell.yaml +++ /dev/null @@ -1,379 +0,0 @@ -category: base -doc: | - Description of a unit cell, i.e., the crystal structure of a single - thermodynamic phase. -symbols: - n_pos: | - Number of atom positions. -type: group -NXunit_cell(NXobject): - crystallographic_database_identifier: - doc: | - Identifier of an entry resolvable via crystallographic_database - which was used for creating this structure model. - crystallographic_database: - doc: | - Name of the crystallographic database to resolve - crystallographic_database_identifier e.g. COD, ICSD, or others. - lattice_system: - doc: | - A lattice system is a group of lattices with the same set of lattice point groups. - For further information, see https://en.wikipedia.org/wiki/Crystal_system. - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - space_group: - doc: | - Crystallographic space group. - A space group is the symmetry group of a repeating pattern in space. - For further information, see International Table for Crystallography (https://it.iucr.org/). - point_group: - doc: | - Crystallographic point group. - A crystallographic point group is a set of symmetry operations, corresponding to one of the point groups in three dimensions, - such that each operation (perhaps followed by a translation) would leave the structure of a crystal unchanged. - This field should use Schoenflies notation (see Schoenflies, A., Krystallsysteme und Krystallstructur, 1891). - For further information, see https://dictionary.iucr.org/Point_group. - laue_group: - doc: | - Laue group (also called Laue class). - The Laue classes are eleven geometric crystal classes containing centrosymmetric crystallographic types of point groups and their subgroups. - When absorption is negligible and Friedel's law applies, it is impossible to distinguish by diffraction between a centrosymmetric point group - and one of its non-centrosymmetric subgroups; only point groups belonging to different Laue classes can then be distinguished. - For further information, see https://dictionary.iucr.org/Laue_class. - - # defined using which convention? - a_b_c(NX_FLOAT): - unit: NX_LENGTH - doc: | - Crystallography unit cell parameters a, b, and c - dimensions: - rank: 1 - dim: [[1, 3]] - base_vector_a(NX_FLOAT): - unit: NX_LENGTH - doc: | - Crystallography unit cell vector a - dimensions: - rank: 1 - dim: [[1, 3]] - \@depends_on: - doc: | - For definining which coordinate system the unit cell vector a is defined in. - base_vector_b(NX_FLOAT): - unit: NX_LENGTH - doc: | - Crystallography unit cell vector b - dimensions: - rank: 1 - dim: [[1, 3]] - \@depends_on: - doc: | - For definining which coordinate system the unit cell vector b is defined in. - base_vector_c(NX_FLOAT): - unit: NX_LENGTH - doc: | - Crystallography unit cell vector c - dimensions: - rank: 1 - dim: [[1, 3]] - \@depends_on: - doc: | - For definining which coordinate system the unit cell vector c is defined in. - alpha_beta_gamma(NX_FLOAT): - unit: NX_ANGLE - doc: | - Crystallography unit cell angles alpha, beta, and gamma - dimensions: - rank: 1 - dim: [[1, 3]] - volume(NX_FLOAT): - unit: NX_VOLUME - doc: | - Volume of the unit cell - - # add enumeration of all possible - is_centrosymmetric(NX_BOOLEAN): - doc: | - True if space group is considered a centrosymmetric one. - False if space group is considered a non-centrosymmetric one. - Centrosymmetric has all types and combinations of symmetry elements - (translation, rotational axis, mirror planes, center of inversion) - Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). - Chiral compared to non-centrosymmetric is constrained (no mirror planes). - is_chiral(NX_BOOLEAN): - doc: | - True if space group is considered a chiral one. - False if space group is consider a non-chiral one. - phase_identifier(NX_UINT): - unit: NX_UNITLESS - doc: | - Identifier for the phase. - The value 0 is reserved for the unknown phase which represents the null-model - that no phase model was sufficiently significantly confirmed. - phase_name: - doc: | - Trivial name of the phase/alias. - atom_identifier: - doc: | - Labels for each atom position - dimensions: - rank: 1 - dim: [[1, n_pos]] - atom(NX_UINT): - unit: NX_UNITLESS - doc: | - The hash value :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) `_ - dimensions: - rank: 1 - dim: [[1, n_pos]] - atom_positions(NX_FLOAT): - unit: NX_LENGTH - doc: | - Atom positions x, y, z. - dimensions: - rank: 2 - dim: [[1, n_pos], [2, 3]] - \@depends_on: - doc: | - Reference to an instance of NXcoordinate_system whereby the positions can be - resolved. - atom_occupancy(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Relative occupancy of the atom position. - dimensions: - rank: 1 - dim: [[1, n_pos]] - depends_on: - doc: | - For definining which coordinate system the unit cell parameters are defined in. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a46d03548ce1236f811923401038d3d20837973e153f67e1d7117d5367409825 -# -# -# -# -# -# -# -# Number of atom positions. -# -# -# -# -# Description of a unit cell, i.e., the crystal structure of a single -# thermodynamic phase. -# -# -# -# Identifier of an entry resolvable via crystallographic_database -# which was used for creating this structure model. -# -# -# -# -# Name of the crystallographic database to resolve -# crystallographic_database_identifier e.g. COD, ICSD, or others. -# -# -# -# -# A lattice system is a group of lattices with the same set of lattice point groups. -# For further information, see https://en.wikipedia.org/wiki/Crystal_system. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Crystallographic space group. -# A space group is the symmetry group of a repeating pattern in space. -# For further information, see International Table for Crystallography (https://it.iucr.org/). -# -# -# -# -# Crystallographic point group. -# A crystallographic point group is a set of symmetry operations, corresponding to one of the point groups in three dimensions, -# such that each operation (perhaps followed by a translation) would leave the structure of a crystal unchanged. -# This field should use Schoenflies notation (see Schoenflies, A., Krystallsysteme und Krystallstructur, 1891). -# For further information, see https://dictionary.iucr.org/Point_group. -# -# -# -# -# Laue group (also called Laue class). -# The Laue classes are eleven geometric crystal classes containing centrosymmetric crystallographic types of point groups and their subgroups. -# When absorption is negligible and Friedel's law applies, it is impossible to distinguish by diffraction between a centrosymmetric point group -# and one of its non-centrosymmetric subgroups; only point groups belonging to different Laue classes can then be distinguished. -# For further information, see https://dictionary.iucr.org/Laue_class. -# -# -# -# -# -# Crystallography unit cell parameters a, b, and c -# -# -# -# -# -# -# -# Crystallography unit cell vector a -# -# -# -# -# -# -# For definining which coordinate system the unit cell vector a is defined in. -# -# -# -# -# -# Crystallography unit cell vector b -# -# -# -# -# -# -# For definining which coordinate system the unit cell vector b is defined in. -# -# -# -# -# -# Crystallography unit cell vector c -# -# -# -# -# -# -# For definining which coordinate system the unit cell vector c is defined in. -# -# -# -# -# -# Crystallography unit cell angles alpha, beta, and gamma -# -# -# -# -# -# -# -# Volume of the unit cell -# -# -# -# -# -# True if space group is considered a centrosymmetric one. -# False if space group is considered a non-centrosymmetric one. -# Centrosymmetric has all types and combinations of symmetry elements -# (translation, rotational axis, mirror planes, center of inversion) -# Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). -# Chiral compared to non-centrosymmetric is constrained (no mirror planes). -# -# -# -# -# True if space group is considered a chiral one. -# False if space group is consider a non-chiral one. -# -# -# -# -# Identifier for the phase. -# The value 0 is reserved for the unknown phase which represents the null-model -# that no phase model was sufficiently significantly confirmed. -# -# -# -# -# Trivial name of the phase/alias. -# -# -# -# -# Labels for each atom position -# -# -# -# -# -# -# -# The hash value :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` -# the number of protons and :math:`N` the number of neutrons -# of each isotope respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. -# For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ -# -# -# -# -# -# -# -# Atom positions x, y, z. -# -# -# -# -# -# -# -# Reference to an instance of NXcoordinate_system whereby the positions can be -# resolved. -# -# -# -# -# -# Relative occupancy of the atom position. -# -# -# -# -# -# -# -# For definining which coordinate system the unit cell parameters are defined in. -# -# -# diff --git a/contributed_definitions/nyaml/NXwaveplate.yaml b/contributed_definitions/nyaml/NXwaveplate.yaml deleted file mode 100644 index 11611e2049..0000000000 --- a/contributed_definitions/nyaml/NXwaveplate.yaml +++ /dev/null @@ -1,295 +0,0 @@ -category: base -doc: | - A waveplate or retarder. -symbols: - N_spectrum: | - Size of the wavelength array for which the refractive index of the material - and/or coating is given. - N_wavelengths: | - Number of discrete wavelengths for which the waveplate is designed. If it - operates for a range of wavelengths then N_wavelengths = 2 and the minimum - and maximum values of the range should be provided. - -# A draft of a new base class to describe a waveplate -type: group -NXwaveplate(NXobject): - type: - doc: | - Type of waveplate (e.g. achromatic waveplate or zero-order waveplate). - - # A waveplate can be e.g. a dual-wavelength multi-order plate - # => multiple selection needs to be possible - enumeration: [zero-order waveplate, achromatic waveplate, multiple-order waveplate, dual-wavelength waveplate, other] - - # Are there any other common wave plate types? - other_type: - doc: | - If you selected 'other' in type describe what it is. - retardance: - doc: | - Specify the retardance of the waveplate (e.g. full-wave, half-wave - (lambda/2), quarter-wave (lambda/4) plate). - enumeration: [full-wave plate, half-wave plate, quarter-wave plate] - wavelengths(NX_NUMBER): - exists: recommended - doc: | - Discrete wavelengths for which the waveplate is designed. If the - waveplate operates over an entire range of wavelengths, enter the minimum - and maximum values of the wavelength range (in this case - N_wavelengths = 2). - dimensions: - rank: 1 - dim: [[1, N_wavelengths]] - retardance_distribution(NXdata): - doc: | - Wavelength resolved retardence of the waveplate. - diameter(NX_FLOAT): - unit: NX_LENGTH - doc: | - Diameter of the waveplate. - clear_aperture(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Clear aperture of the device (e.g. 90% of diameter for a disc or 90% of - length/height for square geometry). - - # Would it be better to provide the clear aperture as length? - substrate(NXsample): - doc: | - Describe the material of the substrate of the wave plate in - substrate/substrate_material and provide its index of refraction in - substrate/index_of_refraction_substrate, if known. - substrate_material: - doc: | - Specify the material of the wave plate. If the device has a - coating it should be described in coating/coating_material. - substrate_thickness(NX_NUMBER): - unit: NX_LENGTH - doc: | - Thickness of the wave plate substrate. - index_of_refration_substrate(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Complex index of refraction of the wave plate substrate. Specify at - given wavelength (or energy, wavenumber etc.) values. - dimensions: - rank: 2 - dim: [[1, 2], [2, N_spectrum]] - coating(NXsample): - doc: | - Is the wave plate coated? If yes, specify the type and material of the - coating and the wavelength range for which it is designed. If known, you - may also provide its index of refraction. - coating_type: - doc: | - Specify the coating type (e.g. dielectric, anti-reflection (AR), - multilayer coating etc.). - coating_material: - doc: | - Specify the coating material. - coating_thickness(NX_NUMBER): - unit: NX_LENGTH - doc: | - Thickness of the coating. - wavelength_range_coating(NX_NUMBER): - exists: recommended - doc: | - Wavelength range for which the coating is designed. Enter the minimum - and maximum values of the wavelength range. - dimensions: - rank: 1 - dim: [[1, 2]] - index_of_refraction_coating(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Complex index of refraction of the coating. Specify at given spectral - values (wavelength, energy, wavenumber etc.). - dimensions: - rank: 2 - dim: [[1, 2], [2, N_spectrum]] - reflectance(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Average reflectance of the waveplate in percentage. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e6c99e9c240c03dc06ebe145daaa20ed4413a767e76674043b59663fc3d9f8d0 -# -# -# -# -# -# -# -# -# Size of the wavelength array for which the refractive index of the material -# and/or coating is given. -# -# -# -# -# Number of discrete wavelengths for which the waveplate is designed. If it -# operates for a range of wavelengths then N_wavelengths = 2 and the minimum -# and maximum values of the range should be provided. -# -# -# -# -# A waveplate or retarder. -# -# -# -# Type of waveplate (e.g. achromatic waveplate or zero-order waveplate). -# -# -# -# -# -# -# -# -# -# -# -# -# -# If you selected 'other' in type describe what it is. -# -# -# -# -# Specify the retardance of the waveplate (e.g. full-wave, half-wave -# (lambda/2), quarter-wave (lambda/4) plate). -# -# -# -# -# -# -# -# -# -# Discrete wavelengths for which the waveplate is designed. If the -# waveplate operates over an entire range of wavelengths, enter the minimum -# and maximum values of the wavelength range (in this case -# N_wavelengths = 2). -# -# -# -# -# -# -# -# Wavelength resolved retardence of the waveplate. -# -# -# -# -# Diameter of the waveplate. -# -# -# -# -# Clear aperture of the device (e.g. 90% of diameter for a disc or 90% of -# length/height for square geometry). -# -# -# -# -# -# Describe the material of the substrate of the wave plate in -# substrate/substrate_material and provide its index of refraction in -# substrate/index_of_refraction_substrate, if known. -# -# -# -# Specify the material of the wave plate. If the device has a -# coating it should be described in coating/coating_material. -# -# -# -# -# Thickness of the wave plate substrate. -# -# -# -# -# Complex index of refraction of the wave plate substrate. Specify at -# given wavelength (or energy, wavenumber etc.) values. -# -# -# -# -# -# -# -# -# -# Is the wave plate coated? If yes, specify the type and material of the -# coating and the wavelength range for which it is designed. If known, you -# may also provide its index of refraction. -# -# -# -# Specify the coating type (e.g. dielectric, anti-reflection (AR), -# multilayer coating etc.). -# -# -# -# -# Specify the coating material. -# -# -# -# -# Thickness of the coating. -# -# -# -# -# Wavelength range for which the coating is designed. Enter the minimum -# and maximum values of the wavelength range. -# -# -# -# -# -# -# -# Complex index of refraction of the coating. Specify at given spectral -# values (wavelength, energy, wavenumber etc.). -# -# -# -# -# -# -# -# -# -# Average reflectance of the waveplate in percentage. -# -# -# diff --git a/contributed_definitions/nyaml/NXxps.yaml b/contributed_definitions/nyaml/NXxps.yaml deleted file mode 100644 index c15d457deb..0000000000 --- a/contributed_definitions/nyaml/NXxps.yaml +++ /dev/null @@ -1,896 +0,0 @@ -category: application -doc: | - This is the application definition for X-ray photoelectron spectroscopy. -type: group -NXxps(NXmpes): - (NXentry): - definition(NX_CHAR): - enumeration: [NXxps] - method: - doc: | - A name of the experimental method according to `Clause 11`_ of - the `ISO 18115-1:2023`_ specification. - - Examples for XPS-related experiments include: - * X-ray photoelectron spectroscopy (XPS) - * angle-resolved X-ray photoelectron spectroscopy (ARXPS) - * ultraviolet photoelectron spectroscopy (UPS) - * hard X-ray photoemission spectroscopy (HAXPES) - * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) - * electron spectroscopy for chemical analysis (ESCA) - - .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html - .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 - geometries(NXcoordinate_system_set): - exists: recommended - xps_coordinate_system(NXcoordinate_system): - exists: optional - doc: | - In traditional surface science, a left-handed coordinate system is used such that the positive z-axis - points along the normal of the sample stage, and the x- and y-axes lie in the plane of the sample stage. - However, in NeXus, a coordinate system that is the same as `McStas`_ is used. `xps_coordinate_system` - gives the user the opportunity to work in the traditional base coordinate system. - - .. _McStas: http://mcstas.org/ - - .. image:: xps/xps_cs.png - :width: 40% - origin: - enumeration: [sample stage] - handedness: - enumeration: [left_handed] - z_direction: - enumeration: [sample stage normal] - x: - enumeration: [[-1, 0, 0]] - y: - enumeration: [[0, 1, 0]] - z: - enumeration: [[0, 0, 1]] - depends_on(NX_CHAR): - doc: | - Link to transformations defining the XPS base coordinate system, - which is defined such that the positive z-axis points along the sample stage normal, and the - x- and y-axes lie in the plane of the sample stage. - coordinate_system_transformations(NXtransformations): - doc: | - Set of transformations, describing the orientation of the XPS coordinate system - with respect to the beam coordinate system (.) or any other coordinate system. - - The transformations in `coordinate_system_transformations` depend on the actual instrument geometry. - If the z-axis is pointing in the direction of gravity (i.e., if the sample is mounted horizontally), - the following transformations can be used for describing the XPS coordinate system - with respect to the beam coordinate system (.): - - .. code-block:: - - xps_coordinate_system:NXcoordinate_system - depends_on=entry/geometries/xps_coordinate_system/coordinate_transformations/z_rotation - coordinate_system_transformations:NXtransformations - z_rotation=beam_azimuth_angle - @depends_on=y_flip - @transformation_type=rotation - @vector=[0, 0, 1] - @units=degree - y_flip=180 - @depends_on=y_rotation - @transformation_type=rotation - @vector=[0, 1, 0] - @units=degree - y_rotation=beam_polar_angle_of_incidence - @depends_on=. - @transformation_type=rotation - @vector=[0, 1, 0] - @units=degree - (NXinstrument): - doc: - - | - Description of the XPS spectrometer and its individual parts. - - | - xref: - spec: ISO 18115-1:2023 - term: 12.58 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 - sourceTYPE(NXsource): - exists: recommended - power(NX_FLOAT): - unit: NX_POWER - exists: recommended - beamTYPE(NXbeam): - depends_on: - exists: recommended - doc: | - Reference to the transformation describing the orientation of the beam - relative to a defined coordinate system. - transformations(NXtransformations): - exists: recommended - beam_polar_angle_of_incidence(NX_NUMBER): - unit: NX_ANGLE - doc: | - Incidence angle of the beam with respect to the upward z-direction, defined by - the sample stage. - \@transformation_type: - enumeration: [rotation] - \@vector: - enumeration: [[0, -1, 0]] - \@depends_on: - enumeration: [beam_azimuth_angle] - beam_azimuth_angle(NX_NUMBER): - unit: NX_ANGLE - doc: | - Azimuthal rotation of the beam from the y-direction towards the operator, defined - by the sample stage. - \@transformation_type: - enumeration: [rotation] - \@vector: - enumeration: [[0, 0, -1]] - \@depends_on: - doc: | - This should point to the last element of the coordinate system transformations defined in - /entry/geometries/xps_coordinate_system/coordinate_system_transformations. - (NXelectronanalyser): - work_function(NX_FLOAT): - transmission_function(NXdata): - exists: recommended - (NXcollectioncolumn): - magnification(NX_FLOAT): - exists: recommended - unit: NX_DIMENSIONLESS - (NXenergydispersion): - radius(NX_NUMBER): - exists: recommended - unit: NX_LENGTH - energy_scan_mode: - depends_on: - exists: recommended - doc: | - Reference to the transformation describing the orientation of the analyzer - relative to a defined coordinate system. - transformations(NXtransformations): - exists: recommended - analyser_take_off_polar_angle(NX_NUMBER): - unit: NX_ANGLE - doc: | - Polar tilt of the analyser with respect to the upward z-direction, defined by - the sample stage. - - The angle between the incoming beam and the analyser is given by - beam_analyser_angle = beam_polar_angle_of_incidence + analyser_take_off_polar_angle. - In practice, the analyser axis is often set as the z axis (analyser_take_off_polar_angle = 0), - so that beam_analyser_angle = beam_polar_angle_of_incidence. For magic angle configurations, - this angle is 54.5°. - \@transformation_type: - enumeration: [rotation] - \@vector: - enumeration: [[0, -1, 0]] - \@depends_on: - enumeration: [analyser_take_off_azimuth_angle] - analyser_take_off_azimuth_angle(NX_NUMBER): - unit: NX_ANGLE - doc: | - Azimuthal rotation of the analyser from the y-direction towards the operator, - defined by the sample stage. - \@transformation_type: - enumeration: [rotation] - \@vector: - enumeration: [[0, 0, -1]] - \@depends_on: - doc: | - This should point to the last element of the coordinate system transformations defined in - /entry/geometries/xps_coordinate_system/coordinate_system_transformations. - (NXprocess_mpes): - energy_referencing(NXcalibration): - exists: recommended - transmission_correction(NXcalibration): - exists: recommended - (NXsample): - depends_on: - exists: recommended - doc: | - Reference to the transformation describing the orientation of the sample - relative to a defined coordinate system. - transformations(NXtransformations): - exists: recommended - sample_rotation_angle(NX_NUMBER): - unit: NX_ANGLE - doc: | - Clockwise rotation about the sample normal. - \@transformation_type: - enumeration: [rotation] - \@vector: - enumeration: [[0, 0, -1]] - \@depends_on: - enumeration: [sample_normal_polar_angle_of_tilt] - sample_normal_polar_angle_of_tilt(NX_NUMBER): - unit: NX_ANGLE - doc: | - Polar tilt of the sample with respect to the upward z-direction, defined by - the sample stage. - \@transformation_type: - enumeration: [rotation] - \@vector: - enumeration: [[0, -1, 0]] - \@depends_on: - enumeration: [sample_normal_tilt_azimuth_angle] - sample_normal_tilt_azimuth_angle(NX_NUMBER): - unit: NX_ANGLE - doc: | - Azimuthal rotation of the sample from the y-direction towards the operator, - defined by the sample stage. - \@transformation_type: - enumeration: [rotation] - \@vector: - enumeration: [[0, 0, -1]] - \@depends_on: - doc: | - This should point to the last element of the coordinate system transformations defined in - /entry/geometries/xps_coordinate_system/coordinate_system_transformations. - data(NXdata): - energy(NX_NUMBER): - \@reference: - exists: recommended - \@energy_indices: - (NXfit): - exists: recommended - doc: - - | - Peak model for XPS fitting. Each `NXfit` instance shall be used for the description of - _one_ peak fit in _one_ XPS region. As an example, this could be used to describe the - fitting of one measured C 1s spectrum. - - | - xref: - spec: ISO 18115-1:2023 - term: 3.29 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.29 - label: - data(NXdata): - doc: | - Input data and results of the fit. - input_dependent(NX_NUMBER): - unit: NX_ANY - doc: | - Dependent variable for this fit procedure. - - This could be a link to entry/data/data. - input_independent(NX_NUMBER): - unit: NX_ANY - doc: | - Independent variable for this fit procedure. - - This could be a link to entry/data/energy. - envelope(NX_NUMBER): - residual(NX_NUMBER): - exists: recommended - peakPEAK(NXpeak): - label: - data(NXdata): - position(NX_NUMBER): - unit: NX_ENERGY - doc: | - This could be a link to entry/data/energy. - intensity(NX_NUMBER): - doc: - - | - Intensity values of the fitted function at each energy in the position field. - - | - xref: - spec: ISO 18115-1:2023 - term: 3.15 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.15 - function(NXfit_function): - exists: recommended - description: - formula: - exists: recommended - area(NXfit_parameter): - exists: optional - doc: | - Area of the peak. - width(NXfit_parameter): - exists: optional - doc: - - | - Width of a peak at a defined fraction of the peak height. - - | - Usually, this will be the Full Width at Half Maximum of the peak (FWHM). - For asymmetric peaks, convenient measures of peak width are the half-widths of - each side of the peak at half maximum intensity. - - | - xref: - spec: ISO 18115-1:2023 - term: 3.28 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.28 - value: - unit: NX_ENERGY - position(NXfit_parameter): - exists: optional - doc: | - Position of the peak on the energy axis. - value: - unit: NX_ENERGY - total_area: - exists: recommended - doc: - - | - Total area under the peak after background removal. - - | - xref: - spec: ISO 18115-1:2023 - term: 3.16 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.16 - backgroundBACKGROUND(NXfit_background): - doc: - - | - Functional form of the fitted XPS background. - - | - xref: - spec: ISO 18115-1:2023 - term: 3.21 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.21 - label: - exists: recommended - data(NXdata): - position(NX_NUMBER): - unit: NX_ENERGY - intensity(NX_NUMBER): - function(NXfit_function): - exists: recommended - description: - enumeration: - linear: - doc: | - Linear background, i.e., a simple straight line from the minimal to - the maximal abscissa value. - Shirley: - doc: | - Shirley background. In the Shirley background, the background intensity at any - given binding energy is proportional to the intensity of the total peak area - above the background in the lower binding energy peak range (i.e., the - background goes up in proportion to the total number of photoelectrons below its - binding energy position). - Tougaard: - doc: | - Tougaard background (or Tougaard universal cross-section approach) which is a - methodology for integrating the intensity of the background at a given binding - energy from the spectral intensities to higher kinetic energies - other: - doc: | - In case none of the enumeration items apply, description should be _other_ - and the functional form of the background should be given by the `formula` - field. - formula: - exists: recommended - global_fit_function(NXfit_function): - exists: recommended - description: - exists: recommended - formula: - exists: recommended - error_function(NXfit_function): - exists: recommended - description: - exists: recommended - formula: - exists: recommended - figure_of_meritMETRIC(NX_NUMBER): - exists: recommended - \@metric: - relative_concentration(NX_FLOAT): - unit: NX_ANY - doc: | - Atomic concentration of each species defined by one peak in the peak model. - This should be an array with the indices pointing to the individual peaks - (i.e, peak_0, peak_1, etc.) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 04421486bc5dffb01865fb8e056d77e5f5157304a3bc3ab9024c8ad160fe21e6 -# -# -# -# -# -# This is the application definition for X-ray photoelectron spectroscopy. -# -# -# -# -# -# -# -# -# -# A name of the experimental method according to `Clause 11`_ of -# the `ISO 18115-1:2023`_ specification. -# -# Examples for XPS-related experiments include: -# * X-ray photoelectron spectroscopy (XPS) -# * angle-resolved X-ray photoelectron spectroscopy (ARXPS) -# * ultraviolet photoelectron spectroscopy (UPS) -# * hard X-ray photoemission spectroscopy (HAXPES) -# * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) -# * electron spectroscopy for chemical analysis (ESCA) -# -# .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html -# .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 -# -# -# -# -# -# In traditional surface science, a left-handed coordinate system is used such that the positive z-axis -# points along the normal of the sample stage, and the x- and y-axes lie in the plane of the sample stage. -# However, in NeXus, a coordinate system that is the same as `McStas`_ is used. `xps_coordinate_system` -# gives the user the opportunity to work in the traditional base coordinate system. -# -# .. _McStas: http://mcstas.org/ -# -# .. image:: xps/xps_cs.png -# :width: 40% -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Link to transformations defining the XPS base coordinate system, -# which is defined such that the positive z-axis points along the sample stage normal, and the -# x- and y-axes lie in the plane of the sample stage. -# -# -# -# -# Set of transformations, describing the orientation of the XPS coordinate system -# with respect to the beam coordinate system (.) or any other coordinate system. -# -# The transformations in `coordinate_system_transformations` depend on the actual instrument geometry. -# If the z-axis is pointing in the direction of gravity (i.e., if the sample is mounted horizontally), -# the following transformations can be used for describing the XPS coordinate system -# with respect to the beam coordinate system (.): -# -# .. code-block:: -# -# xps_coordinate_system:NXcoordinate_system -# depends_on=entry/geometries/xps_coordinate_system/coordinate_transformations/z_rotation -# coordinate_system_transformations:NXtransformations -# z_rotation=beam_azimuth_angle -# @depends_on=y_flip -# @transformation_type=rotation -# @vector=[0, 0, 1] -# @units=degree -# y_flip=180 -# @depends_on=y_rotation -# @transformation_type=rotation -# @vector=[0, 1, 0] -# @units=degree -# y_rotation=beam_polar_angle_of_incidence -# @depends_on=. -# @transformation_type=rotation -# @vector=[0, 1, 0] -# @units=degree -# -# -# -# -# -# -# Description of the XPS spectrometer and its individual parts. -# -# This concept is related to term `12.58`_ of the ISO 18115-1:2023 standard. -# -# .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 -# -# -# -# -# -# -# -# Reference to the transformation describing the orientation of the beam -# relative to a defined coordinate system. -# -# -# -# -# -# Incidence angle of the beam with respect to the upward z-direction, defined by -# the sample stage. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Azimuthal rotation of the beam from the y-direction towards the operator, defined -# by the sample stage. -# -# -# -# -# -# -# -# -# -# -# -# -# -# This should point to the last element of the coordinate system transformations defined in -# /entry/geometries/xps_coordinate_system/coordinate_system_transformations. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Reference to the transformation describing the orientation of the analyzer -# relative to a defined coordinate system. -# -# -# -# -# -# Polar tilt of the analyser with respect to the upward z-direction, defined by -# the sample stage. -# -# The angle between the incoming beam and the analyser is given by -# beam_analyser_angle = beam_polar_angle_of_incidence + analyser_take_off_polar_angle. -# In practice, the analyser axis is often set as the z axis (analyser_take_off_polar_angle = 0), -# so that beam_analyser_angle = beam_polar_angle_of_incidence. For magic angle configurations, -# this angle is 54.5°. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Azimuthal rotation of the analyser from the y-direction towards the operator, -# defined by the sample stage. -# -# -# -# -# -# -# -# -# -# -# -# -# -# This should point to the last element of the coordinate system transformations defined in -# /entry/geometries/xps_coordinate_system/coordinate_system_transformations. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Reference to the transformation describing the orientation of the sample -# relative to a defined coordinate system. -# -# -# -# -# -# Clockwise rotation about the sample normal. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Polar tilt of the sample with respect to the upward z-direction, defined by -# the sample stage. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Azimuthal rotation of the sample from the y-direction towards the operator, -# defined by the sample stage. -# -# -# -# -# -# -# -# -# -# -# -# -# -# This should point to the last element of the coordinate system transformations defined in -# /entry/geometries/xps_coordinate_system/coordinate_system_transformations. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Peak model for XPS fitting. Each `NXfit` instance shall be used for the description of -# _one_ peak fit in _one_ XPS region. As an example, this could be used to describe the -# fitting of one measured C 1s spectrum. -# -# This concept is related to term `3.29`_ of the ISO 18115-1:2023 standard. -# -# .. _3.29: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.29 -# -# -# -# -# Input data and results of the fit. -# -# -# -# Dependent variable for this fit procedure. -# -# This could be a link to entry/data/data. -# -# -# -# -# Independent variable for this fit procedure. -# -# This could be a link to entry/data/energy. -# -# -# -# -# -# -# -# -# -# -# This could be a link to entry/data/energy. -# -# -# -# -# Intensity values of the fitted function at each energy in the position field. -# -# This concept is related to term `3.15`_ of the ISO 18115-1:2023 standard. -# -# .. _3.15: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.15 -# -# -# -# -# -# -# -# -# Area of the peak. -# -# -# -# -# Width of a peak at a defined fraction of the peak height. -# -# Usually, this will be the Full Width at Half Maximum of the peak (FWHM). -# For asymmetric peaks, convenient measures of peak width are the half-widths of -# each side of the peak at half maximum intensity. -# -# This concept is related to term `3.28`_ of the ISO 18115-1:2023 standard. -# -# .. _3.28: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.28 -# -# -# -# -# -# Position of the peak on the energy axis. -# -# -# -# -# -# -# Total area under the peak after background removal. -# -# This concept is related to term `3.16`_ of the ISO 18115-1:2023 standard. -# -# .. _3.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.16 -# -# -# -# -# -# Functional form of the fitted XPS background. -# -# This concept is related to term `3.21`_ of the ISO 18115-1:2023 standard. -# -# .. _3.21: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.21 -# -# -# -# -# -# -# -# -# -# -# -# Linear background, i.e., a simple straight line from the minimal to -# the maximal abscissa value. -# -# -# -# -# Shirley background. In the Shirley background, the background intensity at any -# given binding energy is proportional to the intensity of the total peak area -# above the background in the lower binding energy peak range (i.e., the -# background goes up in proportion to the total number of photoelectrons below its -# binding energy position). -# -# -# -# -# Tougaard background (or Tougaard universal cross-section approach) which is a -# methodology for integrating the intensity of the background at a given binding -# energy from the spectral intensities to higher kinetic energies -# -# -# -# -# In case none of the enumeration items apply, description should be _other_ -# and the functional form of the background should be given by the `formula` -# field. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Atomic concentration of each species defined by one peak in the peak model. -# This should be an array with the indices pointing to the individual peaks -# (i.e, peak_0, peak_1, etc.) -# -# -# -# -# From 4bbc85057ee06018d27a37cffa0409b3766edc41 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 19 Sep 2024 23:49:55 +0200 Subject: [PATCH 0971/1012] small update to mpes-structure --- manual/source/classes/base_classes/mpes-structure.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/manual/source/classes/base_classes/mpes-structure.rst b/manual/source/classes/base_classes/mpes-structure.rst index 80093d7e78..4610b5f90b 100644 --- a/manual/source/classes/base_classes/mpes-structure.rst +++ b/manual/source/classes/base_classes/mpes-structure.rst @@ -43,7 +43,7 @@ Base Classes A base class to describe the complex manipulators used in photoemission experiments, often with > 4 degrees of freedom, cryogenic cooling and other advanced features. -Three base classes to describe data processing, which can be used as subclasses of :ref:`NXprocess` if describing post-processing or as subclasses of :ref:`NXdetector` if describing live, electronics level processing: +Four base classes to describe data processing, which can be used as subclasses of :ref:`NXprocess` if describing post-processing or as subclasses of :ref:`NXdetector` if describing live, electronics level processing: :ref:`NXcalibration`: A base class to describe the 1D calibration of an axis, with a function mapping a raw data scale to a calibrated scale with the same number of points. From 69bc9dc1b799ce5cffe84c301ed4b01ac6377fa6 Mon Sep 17 00:00:00 2001 From: RubelMozumder <32923026+RubelMozumder@users.noreply.github.com> Date: Fri, 20 Sep 2024 09:10:40 +0200 Subject: [PATCH 0972/1012] update category for NXxrd.nxdl. (#296) --- contributed_definitions/NXxrd.nxdl.xml | 12 ++++++------ contributed_definitions/nyaml/NXxrd.yaml | 22 +++++++++++----------- 2 files changed, 17 insertions(+), 17 deletions(-) diff --git a/contributed_definitions/NXxrd.nxdl.xml b/contributed_definitions/NXxrd.nxdl.xml index 7c55fd9de1..c534d8194e 100644 --- a/contributed_definitions/NXxrd.nxdl.xml +++ b/contributed_definitions/NXxrd.nxdl.xml @@ -24,7 +24,7 @@ - + NXxrd on top of NXmonopd @@ -46,7 +46,7 @@ raw detector signal (usually counts) as colected it can be a multi-dimensional dataset depending on - the detector type (faster axes) and + the detector type (faster axes) and the scanning method (slower axes) @@ -87,11 +87,11 @@ - Description of a processing or analysis step, such as the + Description of a processing or analysis step, such as the baseline extraction or azimuth integration. - Add additional fields as needed to describe value(s) of - any variable, parameter, or term related to - the NXprocess step. Be sure to include units attributes + Add additional fields as needed to describe value(s) of + any variable, parameter, or term related to + the NXprocess step. Be sure to include units attributes for all numerical fields. diff --git a/contributed_definitions/nyaml/NXxrd.yaml b/contributed_definitions/nyaml/NXxrd.yaml index d69eb86c5a..d81c3d1e11 100644 --- a/contributed_definitions/nyaml/NXxrd.yaml +++ b/contributed_definitions/nyaml/NXxrd.yaml @@ -1,4 +1,4 @@ -category: base +category: application doc: | NXxrd on top of NXmonopd @@ -30,7 +30,7 @@ NXxrd(NXmonopd): The 2-theta range of the difractogram dimensions: rank: 1 - dim: [[1, nDet]] + dim: (nDet,) \@units: enumeration: [deg] (NXdata): @@ -40,14 +40,14 @@ NXxrd(NXmonopd): Link to ponglar ale in /NXentry/NXinstrument/NXdetector dimensions: rank: 1 - dim: [[1, nDet]] + dim: (nDet,) data(NX_NUMBER): doc: | link (suggested target:/NXentry/NXinstrument/NXdetector/data) Link to data in /Nxentry/Nxinstrument/Nxdetector dimensions: rank: 1 - dim: [[1, nDet]] + dim: (nDet,) (NXprocess): exists: optional doc: | @@ -59,7 +59,7 @@ NXxrd(NXmonopd): for all numerical fields. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 563a1765b4319294e962e0315345a2bb40d270faef3654fe4f3fb417bdc128e0 +# 4f2ea4ee6a66e3c162fccfc9a20a793590853e1d1577142e20f73699cfc792ab # # # -# +# # # NXxrd on top of NXmonopd # @@ -108,7 +108,7 @@ NXxrd(NXmonopd): # # raw detector signal (usually counts) as colected # it can be a multi-dimensional dataset depending on -# the detector type (faster axes) and +# the detector type (faster axes) and # the scanning method (slower axes) # # @@ -149,11 +149,11 @@ NXxrd(NXmonopd): # # # -# Description of a processing or analysis step, such as the +# Description of a processing or analysis step, such as the # baseline extraction or azimuth integration. -# Add additional fields as needed to describe value(s) of -# any variable, parameter, or term related to -# the NXprocess step. Be sure to include units attributes +# Add additional fields as needed to describe value(s) of +# any variable, parameter, or term related to +# the NXprocess step. Be sure to include units attributes # for all numerical fields. # # From 0200cd6a0afe11a2fbf0f539505ac874d03c6ceb Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 20 Sep 2024 10:28:41 +0200 Subject: [PATCH 0973/1012] remove fairmat-specific files --- .github/workflows/ci.yaml | 8 +- .github/workflows/fairmat-build-pages.yaml | 58 ------ .github/workflows/fairmat-clean-pages.yaml | 27 --- .../fairmat-nxdl-yaml-consistency.yaml | 32 --- .gitignore | 4 +- Makefile | 11 +- README.md | 13 +- common/favicon.ico | Bin 15406 -> 2238 bytes dev_tools/globals/urls.py | 2 +- manual/source/_static/blockquote.css.bak | 23 --- manual/source/_static/to_alabaster.css | 73 ------- manual/source/_static/to_rtd.css | 10 - manual/source/apm-structure.rst | 9 - manual/source/cgms-structure.rst | 13 -- manual/source/conf.py | 95 ++------- manual/source/em-structure.rst | 9 - manual/source/examples/index.rst | 6 +- manual/source/fairmat-cover.rst | 146 -------------- manual/source/icme-structure.rst | 9 - manual/source/img/FAIRmat.png | Bin 114746 -> 0 bytes manual/source/img/FAIRmat_new.png | Bin 10334 -> 0 bytes manual/source/img/FAIRmat_new_with_text.png | Bin 29306 -> 0 bytes manual/source/index.rst | 59 ++---- manual/source/laboratory-structure.rst | 9 - manual/source/mpes-structure.rst | 38 ---- manual/source/nexus-index.rst | 20 -- manual/source/north-structure.rst | 26 --- .../source/optical-spectroscopy-structure.rst | 184 ------------------ manual/source/sed/entry-page.html | 6 - manual/source/sts-structure.rst | 8 - manual/source/transport-structure.rst | 14 -- requirements.txt | 7 +- 32 files changed, 53 insertions(+), 866 deletions(-) delete mode 100644 .github/workflows/fairmat-build-pages.yaml delete mode 100644 .github/workflows/fairmat-clean-pages.yaml delete mode 100644 .github/workflows/fairmat-nxdl-yaml-consistency.yaml delete mode 100644 manual/source/_static/blockquote.css.bak delete mode 100644 manual/source/_static/to_alabaster.css delete mode 100644 manual/source/_static/to_rtd.css delete mode 100644 manual/source/apm-structure.rst delete mode 100644 manual/source/cgms-structure.rst mode change 100755 => 100644 manual/source/conf.py delete mode 100644 manual/source/em-structure.rst delete mode 100644 manual/source/fairmat-cover.rst delete mode 100644 manual/source/icme-structure.rst delete mode 100644 manual/source/img/FAIRmat.png delete mode 100644 manual/source/img/FAIRmat_new.png delete mode 100644 manual/source/img/FAIRmat_new_with_text.png delete mode 100644 manual/source/laboratory-structure.rst delete mode 100644 manual/source/mpes-structure.rst delete mode 100644 manual/source/nexus-index.rst delete mode 100644 manual/source/north-structure.rst delete mode 100644 manual/source/optical-spectroscopy-structure.rst delete mode 100644 manual/source/sed/entry-page.html delete mode 100644 manual/source/sts-structure.rst delete mode 100644 manual/source/transport-structure.rst diff --git a/.github/workflows/ci.yaml b/.github/workflows/ci.yaml index 587fdcd82b..7eb59beb28 100755 --- a/.github/workflows/ci.yaml +++ b/.github/workflows/ci.yaml @@ -3,12 +3,10 @@ name: CI on: push: branches: - - main - - fairmat # push commit to the fairmat branch + - main # push commit to the main branch pull_request: branches: - - main - - fairmat # pull request to the fairmat branch + - main # pull request to the main branch workflow_dispatch: # allow manual triggering inputs: deploy: @@ -32,7 +30,7 @@ jobs: runs-on: ubuntu-latest strategy: matrix: - python-version: ['3.8', '3.9', '3.10', '3.11', '3.12'] + python-version: ['3.8', '3.9', '3.10', '3.11'] max-parallel: 5 env: python_version: ${{ matrix.python-version }} diff --git a/.github/workflows/fairmat-build-pages.yaml b/.github/workflows/fairmat-build-pages.yaml deleted file mode 100644 index 22543778e3..0000000000 --- a/.github/workflows/fairmat-build-pages.yaml +++ /dev/null @@ -1,58 +0,0 @@ -name: GH pages fairmat proposal - -on: - push: - branches: [fairmat] - pull_request: - branches: [fairmat] - -jobs: - pages: - runs-on: ubuntu-20.04 - steps: - - name: Checkout Repository - uses: actions/checkout@v2 - with: - fetch-depth: 0 - - name: Set up Python 3.9 - uses: actions/setup-python@v4 - with: - python-version: "3.9" - - name: install dependencies - run: pip install -r requirements.txt - - name: Get branch name - id: branch-name - uses: tj-actions/branch-names@v7 - - name: test - run: make test - - name: prepare - run: make prepare - - name: html - run: make html - - name: Remove build artifacts - run: rm -rf build/manual/build/html/.doctrees build/manual/build/html/_sources - - name: Checkout fairmat-docs branch - run: | - git fetch origin fairmat-docs - git checkout fairmat-docs || git checkout --orphan fairmat-docs - - - name: Move default branch build into fairmat-docs - if: steps.branch-name.outputs.is_default == 'true' - run: | - mkdir -p docs - cp -r build/manual/build/html/* docs - rm -R build/manual/build/html/* - - name: Move PR build into fairmat-docs - if: steps.branch-name.outputs.is_default == 'false' - run: | - mkdir -p docs/${{ steps.branch-name.outputs.current_branch }} - cp -r build/manual/build/html/* docs/${{ steps.branch-name.outputs.current_branch }} - rm -R build/manual/build/html/* - - name: Deploy - uses: peaceiris/actions-gh-pages@v3 - with: - github_token: ${{ secrets.GITHUB_TOKEN }} - publish_dir: docs - publish_branch: fairmat-docs - destination_dir: docs - force_orphan: true diff --git a/.github/workflows/fairmat-clean-pages.yaml b/.github/workflows/fairmat-clean-pages.yaml deleted file mode 100644 index c1cb6db0c5..0000000000 --- a/.github/workflows/fairmat-clean-pages.yaml +++ /dev/null @@ -1,27 +0,0 @@ -name: GH pages cleanup - -on: - delete: - -jobs: - cleanup: - if: github.event.ref_type == 'branch' - runs-on: ubuntu-latest - steps: - - name: Checkout pages - uses: actions/checkout@v2 - with: - ref: fairmat-docs - persist-credentials: false - fetch-depth: 0 - - name: Remove branch directory - run: rm -rf docs/${{ github.event.ref }} - - name: Get current date - id: date - run: echo "::set-output name=date::$(date +'%Y-%m-%d')" - - name: Commit & Push changes - uses: actions-js/push@master - with: - github_token: ${{ secrets.GITHUB_TOKEN }} - branch: fairmat-docs - message: Fairmat docs cleanup ${{ steps.date.outputs.date }} \ No newline at end of file diff --git a/.github/workflows/fairmat-nxdl-yaml-consistency.yaml b/.github/workflows/fairmat-nxdl-yaml-consistency.yaml deleted file mode 100644 index 5234937c6d..0000000000 --- a/.github/workflows/fairmat-nxdl-yaml-consistency.yaml +++ /dev/null @@ -1,32 +0,0 @@ -name: Check nxdl/yaml consistency - -on: - push: - branches: [fairmat] - pull_request: - branches: [fairmat] - -jobs: - check_nxdl: - runs-on: ubuntu-latest - steps: - - name: Set up Python 3.9 - uses: actions/setup-python@v4 - with: - python-version: "3.9" - - name: Checkout Repository - uses: actions/checkout@v2 - with: - fetch-depth: 0 - - name: install dependencies - run: pip install -r requirements.txt - - name: make nxdls - run: make nxdl - - uses: CatChen/check-git-status-action@v1 - with: - fail-if-not-clean: true - request-changes-if-not-clean: false - push-if-not-clean: false - - name: git diff - if: failure() - run: git diff \ No newline at end of file diff --git a/.gitignore b/.gitignore index 3a528d290c..353bdd61c2 100644 --- a/.gitignore +++ b/.gitignore @@ -13,6 +13,4 @@ nyaml/ # Unknown /python/ -__github_creds__.txt -MANIFEST -*_parsed.yaml \ No newline at end of file +__github_creds__.txt \ No newline at end of file diff --git a/Makefile b/Makefile index 47a60036a2..3a882c2568 100644 --- a/Makefile +++ b/Makefile @@ -28,7 +28,6 @@ help :: @echo "make autoformat Format all files to the coding style conventions." @echo "make test Run NXDL syntax and documentation tests." @echo "make clean Remove all build files." - @echo "make clean-nyaml Remove all nyaml files." @echo "make prepare (Re)create all build files." @echo "make html Build HTML version of manual. Requires prepare first." @echo "make pdf Build PDF version of manual. Requires prepare first." @@ -61,8 +60,6 @@ test :: clean :: $(RM) -rf $(BUILD_DIR) - -clean-nyaml :: $(RM) -rf $(BASE_CLASS_DIR)/$(NYAML_SUBDIR) $(RM) -rf $(APPDEF_DIR)/$(NYAML_SUBDIR) $(RM) -rf $(CONTRIB_DIR)/$(NYAML_SUBDIR) @@ -73,7 +70,7 @@ prepare :: pdf :: $(SPHINX) -M latexpdf $(BUILD_DIR)/manual/source/ $(BUILD_DIR)/manual/build - cp $(BUILD_DIR)/manual/build/latex/nexus-fairmat.pdf $(BUILD_DIR)/manual/source/_static/NeXusManual.pdf + cp $(BUILD_DIR)/manual/build/latex/nexus.pdf $(BUILD_DIR)/manual/source/_static/NeXusManual.pdf html :: $(SPHINX) -b html -W $(BUILD_DIR)/manual/source/ $(BUILD_DIR)/manual/build/html @@ -98,7 +95,7 @@ all :: @echo "HTML built: `ls -lAFgh $(BUILD_DIR)/impatient-guide/build/html/index.html`" @echo "PDF built: `ls -lAFgh $(BUILD_DIR)/impatient-guide/build/latex/NXImpatient.pdf`" @echo "HTML built: `ls -lAFgh $(BUILD_DIR)/manual/build/html/index.html`" - @echo "PDF built: `ls -lAFgh $(BUILD_DIR)/manual/build/latex/nexus-fairmat.pdf`" + @echo "PDF built: `ls -lAFgh $(BUILD_DIR)/manual/build/latex/nexus.pdf`" $(BASE_CLASS_DIR)/%.nxdl.xml : $(BASE_CLASS_DIR)/$(NYAML_SUBDIR)/%.yaml nyaml2nxdl $< --output-file $@ @@ -117,7 +114,7 @@ nyaml: # NeXus - Neutron and X-ray Common Data Format # -# Copyright (C) 2008-2022 NeXus International Advisory Committee (NIAC) +# Copyright (C) 2008-2024 NeXus International Advisory Committee (NIAC) # # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public @@ -133,4 +130,4 @@ nyaml: # License along with this library; if not, write to the Free Software # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA # -# For further information, see http://www.nexusformat.org \ No newline at end of file +# For further information, see http://www.nexusformat.org diff --git a/README.md b/README.md index e2b91e05b5..5a0a9e734d 100755 --- a/README.md +++ b/README.md @@ -25,17 +25,6 @@ Open the HTML manual in a web brower for visual verification firefox build/manual/build/html/index.html -Convenient editing of definitions is available in nyaml format. For this, definitions need to be converted first from xml to yaml format by the command - - make nyaml - -After editing the definitions in nyaml format in the nyaml subdirectories, the following command can be used to update the definitions in nxdl.xml format: - - make nxdl - -> [!WARNING] -> Please be aware that your nyaml files might be out of sync with the nxdl files when you update your repo. So it's best practice to stash your changes to the nyaml files and regenerate the files with `make nyaml` before adding any changes. - ### HTML pages with contributor information To build the html pages that contains contributor information on the sidebar set a github access token to an environment variable called GH_TOKEN. @@ -86,4 +75,4 @@ package/ | directory for packaging this content utils/ | various tools used in the definitions tree www/ | launch (home) page of NeXus WWW site xslt/ | various XML stylesheet transformations -dev_tools/ | developer tools for testing and building +dev_tools/ | developer tools for testing and building \ No newline at end of file diff --git a/common/favicon.ico b/common/favicon.ico index 20fba88d3ba20159775a13673ecd08e8befdba58..c8e69d204bec19a03aa349dc8512300568c042ed 100644 GIT binary patch literal 2238 zcmeH{TTqQr6vux_H}`9~E0>CpTjW~qLaK8*s8ocGv#AI%lIxHcM((Bu4-6?YYN~Pf zkQu6R_mFCsW|GSoHRMc8OBYH>UN?+TULP-(G9)Z|#{6?BsEGM@DC|oWT|F z78i*?aZUe|g%HY8yAVR`LJ74GBdomvgM$%+qY#47+$NI&J^{bVJZw)k98~E}42aS!5G&MER+}un{OUs|G zuuX64z+ZR3?yocdkHnEmvu^sw1S&lBP&doMDUZ@V5J?|U!q0yUpLKG zpr6EQmKKarJz<#a726f2s)?HB7RAf34IiwAsJhfuE4935);$ literal 15406 zcmeI3eSBR-na6Ke3QOIkxK(n2c~tl$C#3az}9mhSgA=ghh1p4@vI zYT+;L=QEi(GxNO6GtWHp%rlcrW>n@~nSJ-okdM!F?UBheWipxZq$n1b5;0?a>g>T}zGZIP-uZ(2+vZ~D0j)hfdt?LWW4VH}4!XU-&Ik69#-MwuX`A2ipie9=Cf}QqCDjK`BlWlDik)?)kMCTQgq_fP!d?x5^EKLD5_~Rj z-hlpU%Hx`@ocUhzhZ_pcHVY50b0+n)?I|4DLg$Q}@BExT^PqKjbMLHu^1j!>_n$~l zG!(q`D(8G}TK&)$_s#m#4mV>8oSSk5&!v1d?W;)38v|!5`Ivm*E+*dr&HG7e+W~(! zsSO^E4(r_q_`X6sG!;Alj`C5Ydq_oSJ`dj8GK<>Y)kcEf+o^vRxeQUhD?iY6Wc@(b zc){vN+c^094EgU!KP9~c{LNvjX}`50a9_yz?# z-qR3xche5f-jW92U8-`v;N3B4u;Xvwzd`c@AIpIGUbfizb;@_phxu!tOg<)G^gad7 z*C=Z~pJ%)(pE#+n`>%4v8Fj$l$oEokofq*xHaFn3Q}+jwnLqMXS#*W`AkrFWy&BG+ z_xpU{oI%}KJ3fOW@UEk7D`_Hq|Cjue^+R3bk3dd2zvFoLxi5sLkMI0A3EQ%$ZEyOo z%N4s1Yeg^fgI!G;AN@l8^_^eCcZ2ktej4N2wEnjCw6coBU%uGYDt>{#jC`)j=<`(D zp6qMuk~zFy0L*z4dS~sWMERS!0r$(vKD(#;p2Fh8t4ck7hEnIs!1c}FrIC0l|#x2sRC*!2&)N~abaW4kTlLF@UR zTwlio@`Pz6h0#2EQsz1#?@c&_HD^Jo- z)IXQ&>paXNqJFaWA=_S&e!+Qz`5$U<-O&~;=L@-*cN~)~tRL=b!mrvSDjsLhtGO(B~QEu3NS)gWfdy-oN6jv zL^Re@p36LG|9gdTT|)kp+SsqJ1;@RD(SAW)8^uvt1NlPNIec$St}XE1uSETWf>#3f zL-nk6;fR0mBORmtW!tYp{vvf_#d{1#fj#)s;FN!0?L{SPKBuLK9a&B*KcD9O)(wznQT_j%cOzDJXc&dN_o;dnCVcTUrO zL;cgqHt;SM-|%smku~xt`61{bK8t9g+n=!GqiziI_BHtes#70ydNugJr|%T~qI@3J z>(_kEtbJIQ*H|86`o7aAdx+m;=omkVJwMY{Zd*ev;a}s+$UiH|^A&h_j_=oP9ed#^ zNf?!L16}g7>>O?t41Bz5>%^1%;51zNoBpSfHdwey`3UG+K9c$4%)zN?diFcodp@ae zXlgFLVfF&-Z2i3U55vE)2N6GCwQx~Bit%1(d8O~|28QzlbuZ$V#PiC$pOjo5QwGlb zpi*7`^g|7N;Qc~p0pZOqnEnCjy~?Ti-@$zUva!#p$6hyqU-l&)t7I)0?C){fH&s?& z`u&o%{zl`%?gK>=nEjJ*aoK0C(H)&}1gjr7XOcF@eW1rT{*KY-m^SU37~`}MN_5-z z!#)jCAMYs^hw#DUYf8vlw#?u$bnsRA9%Jz+&kh>Dy_Wr9f9)>YUnec%Y@oUEOLi-! ziH@4HY`E6PYCPEe1<>7J^zwrpACd2F$_2N;9A6aixQTLX4=DdP^*Yyy|F1JQeS*=M zB;P;dP?f1a2sxk+W^WyB>8ee?NsHR{)HzAzx~sb04^AJL*Q@M*=c*ramd!d*W#lJ$ z*?HJx+O_}d?814&&Sid}qbaF>>SurS9S!eaK~}Qk23IBe@b=iS{nwmnE7G?-JrB-v zTeY{<_~nAGQ|TAmnhNw+Vn>cmqhM_x2b|r*lH)h@@l9llPENz6zoB;~{RE@_FIoD` z+Xl{u($ABy>j3tP4%N$tK-OKrtrcGM?DWVlG2_vErRgQV4_z?*uYrA% z#JSkLP`YgWi@K}Mc(=jHzCpVgXUhN8zGu!Ibyv*}`-bO(arB=joTSG|Wos%)KlHIp zykvd4-&AxG-MA&f6Uwx7{xIKaLoPo{```7Kx9>~aQ=$Hc@qr}WbeXq&ZY1}Z zwEt~*sI)f-z8X%8dn7qHt{{od6ReSqCHXtgP-pfm^lbh}aJ|_+*oLXr*5Vf)D;Y~C zw5LOREV}kjA#ct$#kSro{+;!guA`F+u`^{cjwGDs9v=GZ2D;v#tbeCmT>^40W%S!g zyCY5lnu@<>&KKE1?^x{9rOZ)P8(@KrP8HnC8y2`nC4EiX{&wa~^G&R^2v3`%z3H@S zdzkpL_L=pvMg7s+`DvTB|3K8m*C0#^2X@N&80_yB?MO;q(vS zr`>1z%clC?jk2L{C(mhG@X|(7+*S6EIC$q5u}R-xT)ondBiXxT`>+9XkathikG|eU z*`_qUxBFW>=Kc8mtTAjAkMMhS%zwfCNyN8li`o}P^YT`*Jj(ckwJ6|oz|Xl6f8yVy zD*VUo^gFB8S}`Pd>=+i0sKttHYyDNv9`bLoDFgWd_o8Za>MlLw-SBZSX_)W6bN-zz zxuSbswK<5^`sLuBS5G`9ipN?OYv#ntTA;rcSjlS(`{qY00w5pSC!+7)A%8ULKN9&r zjL###{NQTyi+`z@s(el1Tf-fJiSbqBBURZl7rPSrbm4ploC6oRW2xglXhvPCyL=!M z&tS|2lA&2e{+g#qp2Pihol|sPk-rFhBDUhJ);^P_TkAXW_rviAu41qFSkAge-}#P( zlkJrM(=zuQ6C0sk^KlHc@4`;{cKuRUr0({n1!2rg@YF?jWA1+@@C{J^fX0qJR$Nl@ z`;+3^w$Dg&?JMwiQ)Jh}c>rG-|Gp#t|Npd36wkBw6V#10@s@C2MmG$(lXV6VZN({b z#L}^y0rGf;ac;3ZK~Mb0v?y>0x?K9FG{{J31+y)NqOEJze{tJeG+RR!15A^#% zt^Ks&2d+JHC?;v}?u>tU_*td6a;37c} zM)_H5yIB)Q(8t`d*fCV$Uvl`0WSCe}W5gS%tL|ywB+kJds_!n#4|KN5cM&hL(X{38 z6aGthO&x!zQ#@n^NpVmkQ~0^wydMbtx^2{NWer{@+X(N92U*!aix0Gd`Pdla3!F=! ze;+Wj2B>DBq_WbJf&E4S@$vZ>QqrcuEoC@zF#FH3b;I2ZJC#CHQ zILDy_*MoDIPc@uBPwV9FIEC*)%zaVRS24n0vDdWgEk;sCD)UxH_9>j(VX}9&p-aoq z!TaDx^H^z4US#}E8n4bkzg* zbgydkB#ilXy7n%X^<1dTm-7PSo~?a{_Jc^gIdRJDj)jBHMdF|DvDm6JwZ_bN(5nbu zzIkYK1Kz$6L$>^;;~`ozjQM=}6dQ+1@oJqDS^J-({xRnDVRCa$ufV_FfGkSB)v>Y# zhIdZh&&lI63}wm5@E_gbt)p%Y^Zn`iq0+gsexP0J`bXgYQriAl{C3RIncUa_=_aw! zQ-BlQ$ObSkp}jdfn%`J2n7h@;CcfJ%!_7w{J_&f9AjL4?TEh3)jN?3VY^oX4X4dZw z(Eew>jjZICinlb*YTv*~UN@54v#q7ceX+~E1ZlWlKPVlnhEwwb&h@}qT*|jaxY#Gk zeJ$FaXMD1s2Uo*ct)6w)1wPH^>!c*TTIF5gzdAnM7ZtpRO?qv`sdOn66(FCm|W z@qZWoACJdC+y*`Q346jd%=y~5J{;q&@c*E2;X7XkuH+j39Wwluxu*%w!K3Uxnr7L4 z%TH0vpZ)qITPHupj6-h>!h88gwC>H?@QIt2&yDs_-emdjJmjdoil5LN3Yk#!AK=UfSv9PieJm=LT(1BY7n+J{y4TrqAya{gxxE0nQvNVtl+) zk^QqaL;j3>X<&Pq56#85?K-qD$y~f@&*m=rBeq_)O*R1@?f`y!t@ERNUd@GIqxj=> z@OY(UsXFZPzkoxsv18RcZ5b+B$qenUjB z2LCUkW6Ov;9#;*qbd%V?Z{aJ}p$htA<*yuD=&Zw^K7FKmV`=LS7k=1#%FdtV@xw6w zhX1HDoYSpyg@I=s8ULMJYYIN%w|9Eq(-?SPpl&(yyS*0wj8$_#Py4LpYovMjKNN8s z;dRFH7`R?d$zS`&9OE-bcMbFzL*E|izaQUY2i~RFVe>xS(3fwhxBBKSR`{ku_0js( zxmUD8y$#$a&AaT8GETo}54jZ_b}rZC2D>Nd9R+&zd5ennIF_QgC;D*;d>fyXywd%V zIkP9@vB|gw|J#7hy3N>{DeO&;TKdT2dTSFb?OHkZ^GMcj_--nkL-~{ye|i%Fos&sF zMSfc>%_{sO56;1XbFJv%c%Q4tNTM?GLr;c>hiZ*o=lO=B-mq|9 zFU^&qS)KoAPKmp*W^}eN=febfQ&=;mx2TNu&GBF0|4Y!5U8TFb;Nbfx=GeTg(iqU2>q&Z3 zUABH%PuwZFH`{SiUe7uk@txf6;x~!MtX=sRQQQEY*2>puS#-|c*wi}3JR(~*S!)$L zcnJL4_z8DIPH)vUoFw!XmEmQ7e3btom#x-&;xCiO{&kwH&Tfpchxw9i+eUfui0>xS z$acfG_SVM!>555RjP1V{nVUDYwNPgVXMTt=ugDd;&ewZe>)+Lad8h3i3A|Mj_ a { - font-size: 11pt !important; - line-height: 1.8 !important; -} - -/* Control TOC tree second level links */ -.sphinxsidebar ul li.toctree-l2 > a { - font-size: 10pt !important; - line-height: 1.8 !important; -} - -/* Control quick search bar */ -.sphinxsidebar input { - margin-top: 5px !important; - margin-bottom: 12px !important; -} - -/* Control quick search bar wrapper, nasty alignment with the google search bar */ -.sphinxsidebar div.searchformwrapper { - width: 209px !important; - align-self: center !important; - margin-left: 3px !important; -} - -/* Control text blurb explaining the project under the logo name */ -.sphinxsidebarwrapper p.blurb { - margin-top: 10px !important; - margin-bottom: 20px !important; -} - -/* Slightly increase the padding in the body */ -.bodywrapper div.body { - padding: 0 45px 0 45px !important; -} - -.body h1 { - margin-bottom: 50px !important; -} \ No newline at end of file diff --git a/manual/source/_static/to_rtd.css b/manual/source/_static/to_rtd.css deleted file mode 100644 index 0b69475425..0000000000 --- a/manual/source/_static/to_rtd.css +++ /dev/null @@ -1,10 +0,0 @@ -/* Theme override commands to control the html aspect in read the docs sphinx theme*/ - -/* Sidebar header (and topbar for mobile) */ -.wy-side-nav-search, .wy-nav-top { - background: #FF331C; - } -/* Sidebar */ -.wy-nav-side { - background: #005F73; - } \ No newline at end of file diff --git a/manual/source/apm-structure.rst b/manual/source/apm-structure.rst deleted file mode 100644 index 581e2ec5b8..0000000000 --- a/manual/source/apm-structure.rst +++ /dev/null @@ -1,9 +0,0 @@ -.. _Apm-Structure-Fairmat: - -===================== -Atom-probe tomography -===================== - -Atom probe tomography and related field-ion microscopy, aka atom probe microscopy (techniques) cover metrology methods with an origin in the materials science and condensed-matter physics communities. With its maturation and commercialization in the last two decades atom probe is increasingly being used for characterization of bio materials and fundamental science of field evaporation physics. - -A status report of the ongoing work on data schemas for atom probe using NeXus is available here: :ref:`Apm-Structure`. diff --git a/manual/source/cgms-structure.rst b/manual/source/cgms-structure.rst deleted file mode 100644 index 563479b17f..0000000000 --- a/manual/source/cgms-structure.rst +++ /dev/null @@ -1,13 +0,0 @@ -.. _Cg-Structure-Fairmat: - -============================ -Geometry and microstructures -============================ - -Computational geometry is a frequently used tool for describing the shape and geometry of structural features in materials and components of instruments used for materials characterization. -NeXus has a long history of base classes which serve specifically the former tasks. Upon closer inspection during the first year of the FAIRmat project we found though that the collection of -base classes could profit from an extension to make working with computational geometry data in NeXus simpler and more fine-grained. - -A status report of this ongoing work is available here: :ref:`CgmsFeatures-Structure`. - -A status report of how these definitions can be of value for the field of Integrated Materials Engineering (ICME) is available here: :ref:`Icme-Structure`. diff --git a/manual/source/conf.py b/manual/source/conf.py old mode 100755 new mode 100644 index aa2e4a524a..9b90263f10 --- a/manual/source/conf.py +++ b/manual/source/conf.py @@ -6,9 +6,8 @@ # -- Path setup -------------------------------------------------------------- -import datetime -import os -import sys +import sys, os, datetime + # If extensions (or modules to document with autodoc) are in another directory, # add these directories to sys.path here. If the directory is relative to the @@ -19,10 +18,10 @@ # -- Project information ----------------------------------------------------- -project = 'NeXus-FAIRmat' -author = 'The FAIRmat collaboration' -copyright = u'2022-{}, {}'.format(datetime.datetime.now().year, author) -description = u'Proposal of NeXus expansion for FAIRmat data' +project = 'nexus' +author = 'NIAC, https://www.nexusformat.org' +copyright = u'1996-{}, {}'.format(datetime.datetime.now().year, author) +description = u'NeXus: A Common Data Format for Neutron, X-ray, and Muon Science' # The full version, including alpha/beta/rc tags version = u'unknown NXDL version' @@ -36,7 +35,7 @@ # -- General configuration --------------------------------------------------- # https://github.com/nexusformat/definitions/issues/659#issuecomment-577438319 -needs_sphinx = '2.5' +needs_sphinx = '2.3' # Add any Sphinx extension module names here, as strings. They can be # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom @@ -47,13 +46,11 @@ 'sphinx.ext.ifconfig', 'sphinx.ext.viewcode', 'sphinx.ext.githubpages', - 'sphinx_comments', 'sphinx.ext.todo', 'sphinx_tabs.tabs', 'contrib_ext' ] - # Show `.. todo` directives in the output # todo_include_todos = True @@ -71,9 +68,8 @@ # The theme to use for HTML and HTML Help pages. See the documentation for # a list of builtin themes. # -html_theme = 'alabaster' -# html_theme = 'sphinxdoc' -# html_theme = 'sphinx_rtd_theme' +# html_theme = 'alabaster' +html_theme = 'sphinxdoc' # Add any paths that contain custom static files (such as style sheets) here, # relative to this directory. They are copied after the builtin static files, @@ -82,69 +78,19 @@ # Add extra files html_extra_path = ['CNAME'] -html_logo = 'img/FAIRmat_new.png' - -if html_theme== 'sphinx_rtd_theme': - html_theme_options = { - 'logo_only': False, - 'collapse_navigation': True, - 'sticky_navigation': True, - 'navigation_depth': 4, - 'includehidden': True, - 'titles_only': False - } - def setup(app): - app.add_css_file('to_rtd.css') - app.add_css_file('details_summary_hide.css') -elif html_theme== 'alabaster': # Alabaster allows a very high degree of control form Sphinx conf.py - html_sidebars = { - '**': [ - 'about.html', - 'navigation.html', - 'localtoc.html', - 'relations.html', - 'sourcelink.html', - 'searchbox.html', - 'google_search.html' - ], - } - html_theme_options = { - 'body_text_align': 'justify', - 'logo_name': True, - 'github_button': True, - 'github_type': 'watch', - 'github_repo': 'nexus_definitions', - 'github_user': 'FAIRmat-NFDI', - 'github_count': 'false', # We don't get the cute counter baloon if we want to point to the branch - 'sidebar_width': '300px', - 'body_max_width': 'auto', - 'page_width': 'auto', - 'font_size': '12pt', - 'font_family': 'Arial', - 'description': 'Proposal of NeXus expansion for FAIRmat data.', - 'show_powered_by': True, - 'sidebar_header': '#ffffff', - 'sidebar_hr': '#ffffff', - 'sidebar_link': '#ffffff', - 'sidebar_list': '#ffffff', - 'sidebar_link_underscore': '#ffffff', - 'sidebar_text': '#ffffff' - } - def setup(app): - app.add_css_file('to_alabaster.css') - app.add_css_file('details_summary_hide.css') -else: - html_sidebars = { + +html_sidebars = { '**': [ 'localtoc.html', 'relations.html', 'sourcelink.html', 'searchbox.html', 'google_search.html' - ], - } - def setup(app): - app.add_css_file('details_summary_hide.css') + ], +} + +def setup(app): + app.add_css_file('details_summary_hide.css') # The name of an image file (within the static path) to use as favicon of the # docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32 @@ -154,19 +100,12 @@ def setup(app): # Output file base name for HTML help builder. htmlhelp_basename = 'NeXusManualdoc' -comments_config = { - "hypothesis": True -} - # -- Options for Latex output ------------------------------------------------- latex_elements = { - 'maxlistdepth': 25, # some application definitions are deeply nested + 'maxlistdepth':25, # some application definitions are deeply nested 'preamble': r''' \usepackage{amsbsy} - \listfiles \DeclareUnicodeCharacter{1F517}{X} \DeclareUnicodeCharacter{2906}{<=} - \DeclareUnicodeCharacter{394}{$\Delta$} - \DeclareUnicodeCharacter{2206}{$\Delta$} \listfiles''' } diff --git a/manual/source/em-structure.rst b/manual/source/em-structure.rst deleted file mode 100644 index 148e513aa2..0000000000 --- a/manual/source/em-structure.rst +++ /dev/null @@ -1,9 +0,0 @@ -.. _Em-Structure-Fairmat: - -=================== -Electron microscopy -=================== - -Electron microscopy is a cross-cutting characterization technique of key demand and relevance within materials science, materials engineering, and bio-science/omics research communities. - -A status report of the ongoing work on data schemas for electron microscopy using NeXus is available here: :ref:`Em-Structure`. diff --git a/manual/source/examples/index.rst b/manual/source/examples/index.rst index 52407feb08..dbea811c48 100644 --- a/manual/source/examples/index.rst +++ b/manual/source/examples/index.rst @@ -1,8 +1,8 @@ .. _Examples: -============================== -NeXus: Examples data files I/O -============================== +================================================ +Examples of writing and reading NeXus data files +================================================ .. .. image:: ../img/NeXus.png diff --git a/manual/source/fairmat-cover.rst b/manual/source/fairmat-cover.rst deleted file mode 100644 index 9545073b62..0000000000 --- a/manual/source/fairmat-cover.rst +++ /dev/null @@ -1,146 +0,0 @@ -.. _FairmatCover: - -======================= -FAIRmat-NeXus Proposal -======================= - -.. index:: - IntroductionCover - OurScope - Outreach - WhichData - WhatIsNew - -Aim -######################### - -Experiments nowadays create a set of very often voluminous and diverse numerical data and metadata. -These pieces of information represent entities of what is effectively a graph of materials data. -This graph can have a very large number of nodes and edges representing the large variety of -relations which scientists ideally want to identify and master -when transforming experimental research into knowledge. - -Experimentalists face the challenge that these pieces of information come at different levels -of granularity and format, of which many need to be better documented. You have very likely experienced -yourself how file and data formats are routinely encountered tasks to master in your daily -research practice and you might have questioned how these formats are currently handled -when you want to produce FAIR research data and publications. - -The NeXus-FAIRmat proposal is an interdisciplinary data science activity initiated by scientists of the -condensed-matter physics community which strives to develop community-maintained open file and data formats -for describing specific experimental techniques, their numerical data and metadata, -and strategies how to exchange these pieces of information. - -.. _IntroductionCover: - -The FAIRmat proposal to NeXus is an effort by the community of scientists of the `FAIRmat consortium `_ -to refine and expand the structure of NeXus. As a project which aims at creating an infrastructure -for experimental data to be findable, accessible, interoperable, and reusable (FAIR) in the fields of -condensed-matter physics and the chemical physics of solids, FAIRmat has adopted NeXus as the common format. - -`NeXus `_ is a common data exchange format which has its origin in the community of -scientists performing neutron, x-ray, and muon experiments. The development of NeXus is coordinated by the -NeXus International Advisory Committee (NIAC). -NeXus defines a schema of data entries with a controlled vocabulary and defined relations between the entries. -NeXus offers not only tools to document these schema definitions in a version-controlled manner but -also tools to check and verify how and if specific instances of NeXus schemata comply with the intended -schema definition when the data are written to files. Although, the Hierarchical Data Format (HDF5) is the -most commonly used file format to write NeXus file to, NeXus can also be used with other file formats. - -NeXus defines domain-specific rules for organizing data in e.g. HDF5 files (:ref:`application.definitions`) -and defines a dictionary of well-defined domain-specific (a vocabulary) of terms (:ref:`base.class.definitions`). -The meta- and numerical data in a NeXus file represent a hierarchical graph which encodes a specifically -granularized representation of relevant pieces of information and results that should be stored with -an experiment. - -Base classes and application definitions are two key components of the NeXus data model. -A base class represents a set of numerical data and metadata which specify details about -scientists, projects, instruments, and other physical devices, including the numerical data -and metadata which are deemed relevant for their description and the associated -computational analyses. Application definitions are constructed from combining such experiment- -and research-question-specifically customized base classes. - -In this combination, an application definition is a data contract between -a producer and a consumer of these scientific data. - -This design has sufficient flexibility to cover any experimental technique and instrumentation, while -ensuring rigorous, application-specific structures that can be processed in an automated manner. - -In cases where base classes or application definitions have not yet been proposed advantage of NeXus can be taken -if the respective scientific community explicitly designs, implements, uses, and continuously evolves -these classes and definitions. Here the role of the NIAC is to support the community with -data modeling and data science technical expertise, thus taking an important role of -cross-disciplinary review. - -The NeXus-FAIRmat proposal represents the results of this development for experiments and use cases which have not yet used NeXus. -Specifically, the proposal includes cases in the materials-science-branch of electron microscopy (EM), photo-emission spectroscopy, -ellipsometry, and the field of atom probe tomography and related field-ion microscopy, here jointly referred to as atom probe microscopy. - - -The documentation available here includes parts of the contents of the NeXus User Manual (also available `here `_), -reported here for the convenience of the user, but is restricted to the parts most pertinent to the our proposal. - -For more extensive information, please visit the original manual. - -.. _OurScope: - -Our scope and perspective -######################### - -Thanks to a cooperative approach across a wide variety of experimental techniques, -the NeXus-FAIRmat proposal of the FAIRmat project has an opportunity -to expand the set of data/metadata accurately described via NeXus. - -With a closely-connected team of domain experts, we will develop such expansion while at the same time maintaining -a consistent structure across different techniques and methods, striving for the maximum simplicity of use. - -Achieving a standardized and FAIR data structure has a wide spectrum of advantages, ranging from radical -progress in scientific transparency to the development of new, far-reaching tools that can be shared across -the whole scientific community. The convenience of such tools can range from guaranteeing data reusability within -a single lab, to enabling open-source availability of ready-to-use advanced analysis software. - -Perhaps the greatest resource, however, is the inclusion of experimental datasets in the `NOMAD Laboratory `_: -a data infrastructure that already hosts the largest computational material science repository in the world, representing a -homogeneous and machine-readable archive, a human-accessible encyclopedia of materials data -with tools for automated artificial intelligence analyses and data access. - -.. _Outreach: - -Outreach to the community -########################## - -A data infrastructure is not effective if it does not integrate seamlessly in the day-to-day workflow of a laboratory. -For this reason, we approach our newly developed NeXus proposal as a community-driven development. -We have drafted an accurate and consistent expansion of NeXus capabilities for a number of lab-based techniques, -but need extensive testing and tweaking of its characteristics by the community. - -If your data is generated with these techniques and you are interested in producing FAIR data and accessing the FAIRmat tools, we -invite you to try out our proposed structure. If you find any conflicts or inconsistencies, please raise them to us using the -comment section. These comments are implemented with `Hypothesis `_, a modern web annotation -tool from the journalism community. The commenting function for each page of the proposal enable you to contribute to the -creation of a more consistent and practical NeXus structure which, in our firm belief, can serve your community and beyond. - -If you do not find your specific experimental technique but would be interested in participating in the development -of a standard using NeXus, feel also very much invited to contact us directly at the `FAIRmat-Team `_. - -.. _WhichData: - -Which data should I convert? -############################ - -You are free to choose at which point in the workflow you wish to convert the data to NeXus, as its flexibility allows to -describe raw data, pre-processed data and fully processed data. As an entry step, we suggest to use a test dataset -that is fully processed and already published (or, alternatively, of negligible scientific content). These datasets, indeed, require often the most -extensive metadata description, but are most easily converted to NeXus, with minimal to no impact on the data processing pipeline. - -In fact, a low barrier (but high yield!) way to participate to FAIRmat consists in converting only fully processed datasets that -are used for a publication, and publishing them via FAIRmat only when your manuscript is in press. This makes the task of -converting to NeXus much more sporadic than fairifying raw data, to the point that it may be even acceptable not to automate it. At the same time, -it guarantees full control on the data until publication. We are confident that if you take this approach, more appetite will come with eating, -and you will be naturally inclined to gradually integrate FAIRmat structures and tools further in your workflow. - - -.. _WhatIsNew: - -.. What is New? -.. ############## diff --git a/manual/source/icme-structure.rst b/manual/source/icme-structure.rst deleted file mode 100644 index 8ff31eaf78..0000000000 --- a/manual/source/icme-structure.rst +++ /dev/null @@ -1,9 +0,0 @@ -.. _Icme-Structure-Fairmat: - -============================================== -Integrated Computational Materials Engineering -============================================== - -With a large set of data schemas for computational geometry, and methods from condensed-matter physics as well as materials engineering we are convinced that the NeXus standardization framework can be one component of efforts to harmonize and consolidate the zoo of descriptions and data schemas used within the field of Integrated Computational Materials Engineering (ICME). - -A status report along these lines of thoughts and ongoing efforts is available here: :ref:`Icme-Structure`. diff --git a/manual/source/img/FAIRmat.png b/manual/source/img/FAIRmat.png deleted file mode 100644 index 034aa452deb2c7695940d513cf0efe94291a1d69..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 114746 zcmeFZhd-77|37}AXc&1VWs8bRD0_8OMzSLzvqH$;`?QdiO0p??6S6rnLu7}HjAUi+ z^?O|Bc)i}=f8lq#eY(|+bI$X+uIKYH?vMLpoL;IZ$x8mT=`z_rr233@kQ~vt`%f?wl^zRFm122UC{T=a( zJ4W{J3rT94k$-=}p9NCXJf6 z{TfReQeJEk>>I^M8m{DlrIiyOg{j<_l9 zS^f{k@f#C++oN}C_S{ahAezsGtU65QSrqH2>$5wCV6o)c^C*vzydw}n?Gs;#3D}E| z^;%S6Mt)nkag20*E!^8$J4s#7{#F}S#XTk5+01OkchKK=ceirS3ghMHysK`E@V2)8 z%1f_QHr`3^0mBSL=1uZ;{fSyQJ9 z_Y5hI7tb;kqZ^S9!_%ib-_2wh8Izv&-}sh9-P)Jbf#BB6_}M*+Zy6Q(L2m>mIcika>^IXZ7!XvE44-nYmG8y}X`{@-=s%<0vCz z^(p=5o|Tm+)wkFJ_6nUQT7)^iOX=W>OPC^ii!ytVtnEPr!Jg&AbFt9OjzHm3zdv)W zPEVUZ`20oYAMNaHcw}lzc$7EUT0Qbp8VwNb8XA3W0c5Rms@Vs6&mc{${D(w zPmJt64qjMVd}ZP-(@_8`u_Bl8g82PGLwQ;?J)d}Xql4dr6j?9T5IfPHHnQ$ev+?q9 zHmsbF##_j++sf)~x-5^OivAw~fu+SskMt`4(Kr_rwPzE5om zLwrcEy3MzZ!Wl;}DecTTI#_yzpzXi$9f7CF?=BfGgYaURI*gFGHig>NJN9-=Hv9qW z&f}tB&NvJ&ULw14=}b1Or!#Nrc75e?dOM343@`<0tho(6k|`5?>AWO(->#_uG6<{{ zVSPnXo5Jy5pPd>v!aaA--@oE$L8PhNFP5sJ;kS0u^#0GsQ+?>&S@6jPj-_jgy8I+{ zd3jg#p|wkIZ7$Rj;Y3Rqlh2!<4d1uZEFReTc3q=7{3z;}l!?-nUS4auSS_8fk{z8j zO^(}~q-unh+n;GYFzEqc(SetC}OD>tcvx3;DiST}x)j%)<2m?0Ujv?WFcikd%d z=>tOWkWuSr={mu}?$E<%f|8M~EpcDi&w0twBPs1Mf5$CNMDrwB^$I6EZK=6*!F8t@ zR?VNpdt^?`<}=^H!Og2&p51~Hq}W9ZOX(;N&DK~C!9Y+?RBQ~WC=xO^Z0+H-sx6`DC$^Py^{q81pA~OgnkOUgnF>s$zs(o4AF!Bn7N(T! z71fP(@RA@Ah zsCbuVYluZhddJ%b!Sk`icyq>0m0onv+S_n$?E{gIBRI3ti_Qzy@Q@Ao`|@ip+%tn8 zpJQs=OJ=xyD&oLW`MFWwSg$uENct?m+wV}uiu!L3HEp~jqwlz2xu%>(5*F+A_AQ{ZZ0O>wd9MVTF;?zCpJc zk&7uBubhQ6-snF^jWbFh4c*5fyeKp&3S6ZCksL2pU#gSgGa^UQlh&@&S*kjgPHv9} zz(SlK-sG`U)Ak)Vegr0Q(OL)wI(G{mB*k{MJxcmQ>+fU-(v(sd1L%@;z+;i5LqQ+4 z)u0SxP{^;)M2%O%ry7Z{T{gmRsy>0e_0D|jSC>M)X@AF4rrV!O>%?FJ*SF;; z5%qpuml$z8f}cafr^4Gs}R#p3+~wTE_*ifZToZmZM6 ze$}7i%|^X?RmnAFVCb%Q`cny9H*ktlGjDb4-ImF(mjV@odSNH!G^0F^P4O`h@%*>q%uT>De_*bN~>8EyG*rj(^1qQbNC5H=ksuv}@6I^NG zCaP%h2t1mJ>m@VTI3|)8T9V$NLvqAh=%(W}lzX;pqx^zl)jXjnBmQ$BA+%bxMn;W! z+SslBh8YqX-?0*&7bF-lnX&QPLaJKpI4I61_sR+Qv1QKB4zM?n#nnCV%|S}`8WHv& z1fDb6<8FVuQ(BTf!HtLY34+*JCZn#@IbZ$yF+aPj8*J6al_%ua`mEj$e`g`bRdl5u z-W-NwE#{;c$t8k+&k;nXjf7P~IFB37zUt*C>`Hgp#tYrB1KuR&9e@&o3zdngdXG+< zt?-K+11`rKLbT^8V<8+5qMdglEHo)_jW}c?aA9p_+cct^7+Lymmi*=T&-#UF-=*Wn z%|U1DEO=jE*R|rwz>h;+Aj}Nsiw;^2DLw|(zwSAn>24h?FH-54dL5|nQ^h)GK*dGFFR6kBQxfl z$N7n+@qX&eX*Epcsjnmk?i~OJO=rxmLA=BD~EiJ zr@cn_xCN~BOGG)9N*dVy8r#Q8o};1WSCkTkk)l^kHW4ESo32F4M8(Q5Mk;{2tFT>E zgG+7|l*g0HGG{tUC0`^%c6F_k>4L`7yE;UAU4R?K-NYkUVo8}Vig06XED1i}koijm zuA608#&e_gdQd2h6UHw(E9QEhWbwzNq<7`8g6zh)>7t0|C6xYL$Fuy9$5(=!tric4 zFR!uFcMlWIp8#7a?Y{Ho>z2R05_+Hghlw#uHz(P$zN%6oMYad3K9Dy&5LBFa01Dhc zUkOhS^+YnPn2q+;xJQYsKaQhsQSR6{1<$%KQEVY#RSSz%ihxhdT)1DodFu*FJvY=u zkYR=EdO|(aOhyW@w4I8K9+0b)ONa#5KV)23xP@}${dLidc;Mo_f$aLH!!EOGrFJF7xy3oM$482J>M`7mgOb`Up{e4^*fA*r{pg){4 zNX844UJ36|w4ilht|xdHnl=*-CUV)w08O&;la1EGbKs>p>Ufn-n_W@zV)faTyha>n zA80J)rB5k5{r`MClbA~P@HY4u`8cBT>B*W)lpUCq=2gN;R>wt0w$&-ea{B{+{Cq))<32zq}rK74fk1vodLhK;It~rIpqA8pdUa|_Pe;W*ZOG>37 z6A5EIpb|3}b2x5{kABk#2pm>mZR~Sb*$J>Q#Adas+I$ht>Rd7UOF;54B#BO=%R*fJ z6Ux-Bv5l}TgKv0!OWH2qCLPOd3;0tWOd@$0_2eit_B7nWW647Z(avX4ElKl7*dm%n zfyS;FAI7VCiAyN6F;~W~8VdBjf(BH@6T}7%OhFGNne$TZ(9ieqnHX-aLPwUdGL*yx zD84ojpNx+h{cge=QL#z*RnPGZ&C9{_P10jY${i2T^v4gA)(>s%qFeBZ3W|#GT{CSWP^M(;Bn_U9-RhE|dh6R8%JTsKaFBJrM~fnu6?wF^;ok9IMZsMSa!|(;xrQER>3-_S+S70&Q53jdScKie zr+ip1-Q<;~zxBjH6GZm^tTeSC^CKX+A68tSlU@8rjJ2qb}72``j=U zeT9my65l2n-VO4`A9~dK3<)+0q7Z1?v?kXM9)he9^u6;f$yAhV49W(N=NgDueUyam z+sRXo*@!R7qeSIr|9^)TZ}@-QGJhP&Q9wDH%_f8UDhOD`h7cXCtDk`1$J4br?GbU^ znR{`Cu_YSrlR=KR3ua5aTMowDC&hgNin8M>e-E=|;kaZS*3#ubqSYR;f@TO}z7- z{!8cJ>U4st>o@*Y(5y^;ADDOoAd#Ca>~>o;S_nL0_z6DMaW32U%bYJ%2D#qsbiwr~ z`(i`;OU(PXLK!TjEd(;uM7ge8@!(DL6va+Eh#7gc`k#9ajT7<&%?dnOWsV?e2JJ6c zM(uhVZS8|Ikb_5r&@F?p$7sbhJ? zC)y?(KllN9UwEg+n9bw?SD{#LG3*X?^V2B{|{88#dQTiAz{QiA)z7Gg1^H9YBeRw4RZ#6 z9By5ecdlFa|x$d5mUt$ADAWQc&f&6>2!K`ZH$moqG@Q;1MTk zcE1S_Q@g%z!H)_QIqoF^3&=}X&$vA4U!T&|v12Eqw069yZPGRSOze_cr8p=AcU}Bn zR)D+SIhA@Q??23upf$6*I5KQq@gjo7D|k9>bER@=OB;^TbnU|3Q9k%P0 zu!iC54jI0Wg&aQ8U^m|JzIjwh^0}un9kt_KdHEfzRZ$k*P`_~uFzn!M6fzBRA#})L zf^T@mDdhPo3bwfnLhE= zbhOZIp-ZlW$0h1tFZZN}>Ma^UxH|tsB`%%JnC`*wn>Q%omMDwqYKe~(WRlBr*Rva;Rvk*H0fkQ6KAvTBLBYSzcAW##$tuIaF9C;b z(#?C1kL*6WqI7)p+=HH9_Y}-(O;9dnzJHxLfwpuUQQ6IE3vhP$XW@6|q-sWzhS)%5 zwQ5Q1M(M639pwZDF6kyTzMBN-B8P8WEtfC~$E0B|b$RZCTTM2iOlS&ARB2^2L%95(x}q+yBl2yan3c zV8R~)hW6j39>qbz7%=M@#}3z82ZuuKMeC66hU=+<8N|Co=AO|*OAXWO4x($QasKl^ zv}o^|GF5z#$$d1`3M~~RuWW`heB)=bD!ey4w^YyaGZxi_#@3b?1}$SXCrvx(a@RLz zk6n(G5jW2sG6%I{XZF+mUj7ruS$#CbGRbvM?p&+kx!c84UBw2aQR>pdLOo306~^KK z??!9b^g}|$$R*lCbMB7gSRUnDbEt?>dZ*v|0$UV z5K6@b4;o`a^o>||(icCy%FESfRG&WanVw7TQBDr-X|4KTehZDx3pY^ZMud!G%Y5QCv{MOq5Dr2l8%s|w#0wGK^cpY z7WXRA9ck1=YXY0~7 z)U5b7sqB#YdO^^T|Jy8E;E%r*iI(cY+By zzhH#a*nRg5Dx?cH@PT(qWIs=C~b*% zPX!}B8El{_yF7PTeqZW=!oRhlEMC@onQ8iarGuC~NXTr1Zw)kUXSfSxb#H38Yk(M!0IhLtj3i9a=#P{zF}px zApLfib>w|I)KplyS30gFH zVSf)8Rd_K5v9(;~vRoWB;51ouF%?Clbl3h>9zYIuukWWy5ko!wKX0Y0>PIIOWJvbz zu18okF9-~oCEvd^X1$Nz^LxFeZpoiNKi2;dpKf_!TxBZcxeAkxG*39AW{dTSnPazt zE=A=v2(f)W@+B}$!T3^oi|MUco|(L9bWu`rJAmysQaiezQ6I{+}HXY;roRf`Nt&7sb4#k zo5bGoDH>@%{nr#~k)!ea^xL`i3TKrIg{VujJK-X1V)6}CthKKlI{y)yR<>tSC0$FJ_QkZtZ;HUN*QJYxvIRwU3YP1M(;D z?`;{6EfzAJpQecB_^Ld2M#2mBC3$UowAFQ186{b9Di^vs1LcvI;y(wa+<(0K^N{+U z;!0S7*Nz&6-_+2a>NBnBSn1^w>WODGq0givp=in99t#($93w^*K-1BpS92|iGRN$| zh@U(wrADhN$H?M!CisYxh8-;gaVG6*O?4hba5I74U(l#P^F|UcO9%G^0PUskVygIq z$l(t%LQlb-MK%RIPX6x6NfET~aO5W8h||Vq@b<+HIjQV))cI*b3HNan5^O(;7-(#o zOm0B*K#trZ+-W*C$r92N@u3|}CzKl;Q6{_}sT81e5OGd@(5i;sB^G~|^k0i?_xaVy z5bOjLxbZtcB!3-7Ehb0Ql>?qU&sZ-DKM>rlV|f1M5a3OH_v93OKy&vbb)gXa_TOg( zAh3>?(2f+Zv;W5?DiuB8MS`ZfY=wgU#KJqc2SrdUf`$S${&p+N%ItsZ(cAH@asLA! z9u0=#41!D>x8ygD+nM%e{`+{dsF{6gPV z+<&(}(l`C61AL&d$2DS^fr>BV%o9{98vQo3m!nfi5J@Rl?kR^ZI576zSv+Ahi&VOO zk_JK8O2Y9?`wV`<75do>Hdb7x5EWZ+koR?8;dD8D1grJQh$lrPiRS1mS|o z^_vvX8tNvP-Yr?YVc7m_dKpRS{>x>k&d##q9oPlGM~zm{<%|e;G}iVXRA+Hzf9qsk z5+UiyUZK}fXHdCLIN80u&L@|_ZvNI&muI0(X%%h42mSWlb-Ea^@ zQ)1-dSvVe!>JaLPxK?nhwYt|ti2TUvxsi5Fw2Qk=P1y50)ben)!stfe-NXCuw(-Kj z#wJ~d!_iWb=QaGpnMZHF7e-iR;mJa3=!Vx1;+H!I{A+#g%dPE8XznzxMmV}=x#d&~ zF_Lq0ZPa%+6;%?Bov^6~iX7)@$l#Of8|eB+g!ME#dA|J&;BmAM(76B=^eN5+k8@7L z`zUR^(?^uF&L1FLp$?-iE0Q4Gjgpd^t*Ck9;_>){v$IEC>@#&BUZO)0?b{4U;*|$-u%8Ed8q^Nb>~Ug8@ENlHy%^s_2fKpWYG}VdbMgfrMpe8c)&mVEq5Y z$|!J{p&!1A!;=nijnd-_E}Z0K2$xJ^MBS%YDmLvHGy@&JOz@YxQ-QushN8h)>abDG zi~{W%L!rRinL_x}cwQ&?+r#ou${392Ei$M(xTFcS+sSpGXb0QCvJfO#nXb-G`H7$T z&PiItpto#LsrCG9kTyI8H$<@WLTxW5-np67gGf#paJQBn+f%t+>gc$`x<6j5QVB}d z6Z&kFfvhCRk%yVI3tOi2i6yzIXooB$2ESzd^WS51h$a!$uia+~MF2(E+jtv{i@MO| z>&Ou(D_~5HXr2&rtE&V}?89J)vborZ`>{69Y+3|2m8!0mT-0PZ#faMVS-ee1x^yy_ z@=qBG-Oo&7hB1SC>4_$>uVUN7oMFj+_|OP;qVHcf<1xP zH_pu5iEa0kRN0`$QGn)F={Ysttnp&N0BqNOIP5c%(V^_9%2wh;5IN99eXLiT$Vpi6 z?hI-%IJ4d#3h}C5m_W_+R5ApY9TVOy!3QRtBf9$vAJP8-xiLGKC|`m?r+Ip~XzfZX z+h#H_g$UTF$|IDYrq^aVVr~0+{ny25yus{(ZV3d2V_2l}KX;MDWeh>sxQHrLlVZBS zHzV@PvFkR-xT=+u4kbI~mB=+P-U1DO;h7}WG=|72B9)|qmAz8At@Q40n1@)ek6r1D zZ3N1rkw~AL7b{9E@wgjE%-moa1@6MVz3H6KgDOWg1^&mtbIh{1*@E~Us1s=n)GO=v z^mNG4#}7=W9Ys_$(aqL&^(l?&^v&%}e5-Z6AxUg-2b^G5Y3k5a9y4N4p=Xsmk>x0R z3DLM?zU7sb%~JPBU)zZUsZ9jCRuN~2gqAsGD7ctKHvjPtBqOBTQHq1F;-E$}r470y z~0O>U}X)_Y0DhI_4_a&M^u>n zxI}@2+KPTs8SyhI552mlZwBj(Br{O0@YhEOxn zlOi^7umkLf->+?XZJ*X#b7ww!nFR>Ks6_zGsD;*-)n$V7EMGvHl5Yn#l+gUywlG^gv+_thv=RtC4P^m56wMyWv5w9PGy*Wl&o+svd>k|}5 zDgVTZuxX;92&LPFMNLNw5KY>5W=FEV*)d(EPYSZBdqjeWv_qcX(CUin#`jh1Zw7Dw zn|oVgTV|9wiK($4Rm*otieuk*QH9gALSNWQhS{+ zYH08QJqm4lLA0PAEfZ|wTA5?LITBnyF?S720L>a3Cs!P6Sf16|a}W=EiOu}ZWBKmM zVsrK8))%y_3TB*hYDET$i#2t|yI${|tk`94WFN+{&CG}_ABd5`=aiJr8F)K(`9O>K z=X3?E@9^(c);~IB<4$AaHYxxUqiDVomc62VnsyQmhu&@J&MyL>Q|VqUhowq6EH9MR4xo0USFIa&!!fd}&&~e`GPZ+HF4By-}}> z=3Co3<2z{!seC`75F|C*D)q;N*KIck=jeoxt{Hc44UAi`lzllmjZh~{SqbrOd$F+pnSBWw@~1UWuPKn!PR z@i-~BQ+nz9rOt;CzYn61*Gn3Z(|zK1%G=-f&qKW%*ktW&>4yXMZud@6B3PFcp?1$3 z)Fli=T=CDU@9&m7t+r3>wZ!xsL!1SH8V$RAjxY_7+w#a2N-B)_!iXrh{gv9j%xQUy z9=J4h0ODNI?U=hJ&T{UJ4(03sG17YfA!(r7VM!Na9kbnwGO`lf?z&#V1%jxE&jFU%CAV6yE#f`c?tKhPT0<*N3{zsiV2>r)yPs zZT(FLiaSRX7X?n6Va|Ucn1`S!R2f5b$@S7emSY~hCMmH^Ev(^smhSJXcbAu#GZt7CL*)2&p)v>c z4j(GOy(=)8bW^+EwE1RuwKes5^4oPS&XUDDUf&iiBS;{3ZvD*diWqhDaj%tB+*aJ` zn;=0i^ZgEI09!DA@@*s=va?Go$Svb?T2OY`XB+Y{1%ksi^mj?u*d&P^Q{jGRR`N$D zHLdnp8}CP_`+%DvVc;+-8ff%oSXg+=`*SFB=fn{r&bN>`bjv-6x3U7(g&lz!f}?)o zgqERj++)Yp7r%D125)W+Y6;CgBS8}50XISv!QkZ_S09ILH{1WSaF6ex6w;Vdz|{8D z{Vw94ysyc=9bt#(rOYV@Rg|U+I+=o4p#B1BZF!b9BKZ>a8>3HM0m3W^)TzXjn7gS{ z|B!|Bk4x7?%Ftg10@?IXRIW9(R1r4uQ#71@`&MGaYBi6KsTU){c@PXCj$BZXosu$8 z#v{nds^iZI?3H`jiHeR4^*FXa_|QY-Z|(59Wc$w_%8-F-O_dm9{s7^tensV~M-fd! zNCk2l0imC9jjVju7Vmi!23#cJ+iC^_uYz z@lqQd&jbx>+#yigwc9H)Qt}i;Y-~(dKhp~a5FwgTlV?U!;-87(3LRIU|I(XUaqPnk z^{T;>uR+MgrL~ottbzth6@O7-t?s0qcefZl6(+Ec6y2_1C~DI-*vjmB3{^*LbKQtl65J8giZyB>_KYSkvy%(mGcWLs_HaNT=Y1nuTWIGnh-XHRB9lNicPBA|)t`<{oT%Ro*G9Gj%D>j8sdwyd zZJcxp2Zo29Q+U+oHc30ScX8dw=f(MXq#LcF>q_b=J2aqowb;RM`4R zrS@MFR^RxI4Xuejd3 z6gm*;y}*sM-m#K`FJh>6B17#2we4E+2mFanzz{i?0C`&CnaY{T;=cW-U+*%)g_fB# zX=T2iXvGsOQKam7+c0kEFhoX4#`$5-sHa3SUx~^BC?D1?@Y0ugMeM>P{za&M8qhr! zU~eI#o?Rm*lD=*ABbeAZwaI5ei^GfvQL%>vIji5|NHtNJx_STLgV*Y5re1sQ!Fpl{ z>s_#M$rwSwjv`?OhFS+q&?A=}#Q1(Wt<8^>@62ZD!qUP&~5l`=!3lwms zfqvFGfk|FMSjo_vFoTO`Fxc$Ye(-9`>|*Oh+{XejYB4w3s&s&p(cPru1xQ$8bop}mq}cIBX#!$4 z7SjGTh7i=;2afgXNx^)YhskOyo2xG9?;z@Nw26bhKwk2P`kOTc-kG5lVa**GE_-fkk$@j&X+ZL@pgdkHG|XnTr5NRGT?q6eGFZjKmPhP$ zIs!~pO)*fg2Z^H3moKLVR2E&odJxe=%f`PGZ|{gQzk>=S`(XJUGOSCVSyEOM2nu`W zEI=HwO->1bh!#ht8&McUnaS&?#^-ru97F-(!Y-o@AxbOSPLM2Gme# zzx20&_eus00j4xB-934p+{EK(PT0yU@UgeH?SUr{<6D3hVJ}v+Yvz)vSulsI-wkMA zx^JS-gwPs_%0<@B4fX*>g}rOzy}x$HwdEgg63u{U4|p`By-P13?R6nR=Gjn;lm~;# z`?#ZbY28fp<$5NajgZDsthAYhY`&Q3aXLvGB++5Kfp%3uEQNTft77ciU7E+_~$xz3tZbYLV-Sf;x3L`#*ZWCgbm zwYh-9uuT>j^?*V!d`+pUK^<9tcT3>luiaCJsu%bfBDMQS#w_?1evQQ|(UXxPD#qZ0 z-0f|QtX^VnU#!KyY4Am><%>=JBqmU$;k!qhpEcJVXcdZm>JPMC<*yL*b#K1qn<&M+dd&dT9h}l$T3qvn$OMmYMEP z<5@^Xfl%Xj)b%$(aOI12bG6}J3MBN~qf-!xvTRBcVUla)!$nK^yE@oJd+QX^=E3P% zUkvGF6bS+~B5VrE8Uf1sI{Ajy!n;?Hrc|#`Q5QYk6etPNw+ig=L9!=vPtompvvOiY ziwL*RWH~8v))<)bc!8e0Zs}vm9L}{-`x`9S@q*lN%W1c(*lj{6y6%am_LohOroT{D z(oiF#U30fa6Qp=rBm_n9kdAAib@8Gz#;>7RC+0SV2>6C+x~jyMbbJM- zMw;y3#HeWpF8?IP*`}-OhMdK$c$ZTkXk!3tD+;B>MJPZ}zCdVhWHSI)8=1O(2~u}! z2kM2S*D-1cr}wkwvs#O99Xg>%4;AsaD482VDPLPbe1VD%2&Z4EO`o{unxMoDs6`v{ z2mJ7O7b9=)Lc|#aP)l}Qua#=`3c~rpYg;ROCzTutX$KU|d%-F~N1>KOj2$txNT&XQ zVwTH#52hR@!7!u9NGZI!afLO(uUBN8+(vR zo12$SiAXyN1%Ynr42A|%$dLIfg+i0XBh?kWjFN4$Ge@gm$6B5vCzDKtA}J0S>!TF7 z(uBw1Br(1XGH{o=KAge?8J>g`Ctk@lCP$V?#eKRUe~!$hsQj`e6TTOM^#vHF4}Nt^ z;NyTQOsKYD7kqIQTHFy+l2^0HR@o3%D6|e=WcWUox}!&dXnY$G z1`@PvhtZ%ySc~_5)BS4UBgQp~2&#l`Ef%xWW5Qqo6)nY4qrj68|Q^$CMDOP{hPY+L-I&Q z7Fs8kAN}-XZtH(Gz*1at(@=O?0^6lG=fRwWF>J##;#PY2x*CcVb3uFptStMOlksWt z4BNESOhr2#Dbi@buQ0TwRZk>E*{Qk>R@LyZIvY_HFi z9~UYnGB}~YG3i#`bmCJRl$|03=P-L`Nyw|Y= z)xF*>>CLNihozB_Tjhp4uiRrXG9|}}aYJC?3;B0Q*P}4eJmCOR&g3S;8f`@;%`!k;#T)f5FsO-&$HZT*u;eS$2=ALHGa-$S z_ye5R1V>UHs4*a+z4mV^vWHMO;Y^Q~Fce-H^Z-vWln zYSr^>x%}rekiZb#Qg-l0P#J=aMe$ajjw0~tX^fZ~^|UAramXMTU9~6uS4Y(9H1qo- zmnF6hF&;c5DwYh9rbCo4NKwL1hE$>*zgIR1@+U<^XVQp}uaClHJ~En=v?Dk+R0mFL z@0x58cL%`tF;rE^@JZCTF9Trg@cj=k*3-N~>k3@1LKG`RxVkm?W_zybwQ}Iw+?DgM zFw+H?cSH#DhueYc;tF10J`TK6lVydk&aP-rotu*MzO#_+m3B>aXA5J7Gdo40mh2p_ zO0*vHKRvuyaR?y8>Z5g#m`^`ujKR|Y*e&ASh}MHjZNQ$WSyt7s^oVoJmd)l>k2Q@` zl-N0Qr{}*Kl(R2Faqv|Fh*i96<2{P71`9ut1H+g5qJ5(!bS=*B6C1y>?y1zOf8Zit&m>MRQL%`{V*UiC;;2rvRHd3AcnLS>iPfZRU=!xm&dR~iL|2a z7oINYbT4*%1(beYTy~RPQ@jJoxnRC5L_yX7#X$~vcD2*lCiKW~FKVobz!okt%#J-w zr$aFu;aTE6vJ3gRYaBB|V`s6O^tz(e{_4Tu#HqmiIZ~IRE8(Pw9$IBJuJRUh5e1lr zmZl}+f*}Ug$5yT@WI=!HC*7t2)FnufJcG)>GI1SEC@P|@OK4m&wqanuxw&+0eHvs? z>EsW1Bmj+(4_-)U2k0YNn}SIl3CjecZ1qfhx%K%rkpby{`UrsLOt;w-ZbXs8R6O`Q zF_Nc&X4SxA%&P8hPsf_6sPFB*qR%;X_vH0{q}gg`$t7&}xpXOu?2MqqC^R$COgzs% z3hc=F&_x87Az?q<>yb!8g>2AMbgZd%+o+J^fYyM?$_}$2#%P1x7&_i@VcRn^(izh# zhj38!!snyXzEO&%}u(I+h(L=4V>bPc*8SYo#s9lOw0 zG_zDbJunHO9wL-Dcnsy!Q~DBxVYbZ1z7`WB%^_f~&3&_q=*&igZ24er6k2IL<+;1myxjadN{FXs8vt)($+_q34XM8x7W0rkhl3LupaR-ts383hn zGp@nhi+=)$HDlktf7Wb%%QK1v!Tp2=Do#AmTc$iXwx=H|nNuqEz{@sHW}j6N2fw1) zGF={+4Rl53yJi(PJ%Ke<@IV2_1T!+qF}-{zCpUbxm6fUm8Wvfoeg=bnF0#pz`GDO( zVmzd5@rk5X2z9kvtx_d>NJu|Ay^%O~kPIjJT0%#!LpS5cOyp~h2~wDi2Oi981&;GrEgCe;Sz($UYhs`;M@wGKT#0|7-2>T=5?Qh&$~s8GfmZvMoy zWcWYnQcq1%vUz`lD4k8D0c@4h((ztDn^)t@4^tgazi;AsN6*(^Cutb6~Oy9ZugPz4r}T^?j!biH^>9+5hv} zfep&UCg%{pg6;v2cUS8jwhyeQ-3}C!R)6;J!vX$JZ{4Ax zL$m>*s~CFHyr}jbIgRquk}u}unyS}-gx)P#c>ge>4DCgLH&+hs;|NzIIQ`W*L3ZxI zQc~x9uwF0nfZ667O=AaaJ2CPT#0c&SShpni(P1?vWuSe~wBQ8B66*t<)R^R+K(y>| z)|x1X21=@S#XTo9Nzs-L{TvWx+cG~h^eBZHaangvD4^s(cnbg5?7pllwv{>Fb|WLb*%g9)?_4BYL`L6%hZ^F{8iZ`H1s zW}jWtGuIp)CnDS|8BH`|Z|EK|`E9sdH(>}#l?3v87N1mU9WkIb?}kWKjQG#Hip^d; zH7jxtio6Z23$N)BNhR=ER%PJG@17mB1%AMym$Z^&IQ#iB?z%)koL7f0FbgtVMo*d* zy^K2%mo^mXPjdULJ~sX^Xl?U)8!G0nmk>#A^e$HQ;UuJsZzum*drZZyNEyga)X+s> zg^5!+M8if9!nDUk*3Mt& zp*VVTeL=0J4gi45A75CiQLQ&3!A@kzzsmE~VE2e2&S9Ji?0mP&YDYJhs@=b8(V)E7 zTtb7`qS3o4u18U5;WX83kYZPTin>}RVUB_-W_55ujMU!_>P6ed*2ui@4qt3!&ZB7o z-Ad<(=yI9>yVQk+>3JwBjg5Lnt!@!vbKMY1Y1M4J?-U7QvDR9>taDOUNDn*aiBba( z!9mDexo(+@9sJcd*Y)(h%a8Q+9rfg@Ij!u;1X-w923#WB7c5*nSA;ZR-$o1h$l+z6Ca*wYeu<_PD@{8N)JoS{H=dle&GAA z&yDyCU)xk+*v>!>4Hj35%b}{2O0t3Ws?2&N0=o9bi@PSsc zSVtFae*Zaq822Tkr(HViRjf|_{ffT1j;k_FS7kaGJck;b%3YHA;A?b8fuv~)mS?q` z9h+diI9KTbQwtkC>-0otX+PXnoGV;HZ=JB8C0@y5*7S%sqz{a6VEq2&dhC+eByoVh z2G^p86DO7~d{{^%i%(Y^CZo|29NO0TF6~PeKi_|Ky<~A}&og3oC%ArYpt`CSObYk$ z=U_r`gU^ny+i7ZpT5$J_*@bHFzc?l{PB;0q1O)r^N9M;;AzbJPsHR4^BBSkXZ^at0!sq?H zORjnDFs-td{LNi6%7?PNQh+_{z)kE^pg(1%e^iM5^)My__PMpv7eg0zdOc%HXe|Zq zZVkBx7i-FR;-@o1gMkTgrMG>5#IU&J>LwtxGz~*p9|CWO4uKTLtyieH4Z?p0b|fBP zCw;=U;do#hy(#`{7(NVJ5DsL34W16v@Ti1@ycb}f3;-Q(U0$G;DNx8yzwKmGFz$+($w1j(>9$n{1p;ktb3sM2?xEtr zn?kEprJ|;}C6({ft*wcq?eL{0nN-wab2QgRmp7LFW-6V@xtVEk^0uah`H=lp9Ujez zYDd{ZnZ=Ijk|_8-73#Ns!;4?4E<$$3Q}g59LCQPmTQExYAj_h;Fx?Ia&E#n#pfKaBwCz1V0>%1-rY+EsxY_lO8KwrXEusU za#l&OPtl44+oUn2R6}dkuf=U$LBYx(KOMdc|Ljix8vgRf;9r28@XTPwEy2J;kmzLI z*s6?#fvR@DK94q$zDMcWrwS=I9?!d9o9sW@@gOw5;1e`o2YzUBFXrWj%b1L%!i-Vq zdgv7{e^+)UoreSCqD9y{z+Lm{O`iwJljC5PcGB)aA)SrO2j-kVCcmq*{59tJ?tSZ& zu%W99`TTj7>@^I#_QjGRN6<;$BZc!oh@K)4mk~^2-8A|BrFmYo-kKzOM z>;w0(`b8za>zUzKg$|e+UIqb=_+~ZE^UtoOM&7@e>=6#t!?!L#6Y<{?;5-HP#z~*q z`&A7(Y6AZ1=xAL>UAiQd_|n>H_A`Ir$T+sxUYN)Fo8BoxIef2B$duo#yUp|fZR&vB zNg18|rxRM~iCKOw2W~m7&K`XoI|?2bXMifsmz#$%<4tUId2N7!PIe+i_p8`|>?c~9 z>C)St5uVA=)F7c9KfP?***1RireQC;p_XP*W|F@KuRImIPu}1Ap2@KLwUg*KW^|}v z68;F9>G`F>81dMIb&&3ni)b?*W+*F2jkD3t@u#9^M_G%@e1BLZnFv3i{!nIK1mhwu z2v=R5@sZhW|mnyaU0^S$`yOo?R@-z1}R$yj0-ZpD5?XWO@#FGShfzHxPJ4T79oW_v#&g>R4i)t`E6xFC=^Ki5N6?Y8&a~{Um4(*(G zd@iC*xyiL{U@~r0T;Bc~Xc=Ov4j9T*i||F@zVcU@x%r8Z7t4EjPK8Pq*}Axt_rih; zyltn>T%dHgeQoLwx%!uc2rS3C;2&c@u4bCM#{xx*7@v(DvL|(4q+-mCa9Wxv?^is% zF+N>lY!(}CV)5qZbVZNPQ^@bu61GPa7{h|zHBNKLXDa>qM6^Y7{#ugC_Dmd~e^k#yc& zZloltoD*ql9i})3yfJ2={TdKcpzwsp%cNe4l+%)OB{#TDCUwU-U!kf4jWz7VxmX<4zHY1ukUf|uRjB5l{O4}Umi1f*nj%?rWE-yFJ zh`(>!uT?S$agM$eu+J5k?vD{AOS1FFd6`a5Rxt&-P(;ol-_qYm?G?g?lnk^uR9p! zUT)Q>{q3Yqi`|PNJhwnR{c^`#{$@c{N{ir&M%^m+lM*t!n#gy(+k9!a8B{;seiAa! zqm};ajz#gru;o{+mcKFn!`@tX4czwc8J~qfMq0nZ5eN8UE!LW(EcU z%$&*PG1a$yCW+bU>D1pfQMPL%OAW`xC&Ek}k@h~k*k=7`rJuh_2*#(Uu}{I1{fnU3=(j6t@Y5%#EJg ziiqz;02`E?y6Rb=h3G;uU$cyV;n?U;Kf!G*9b2=PKQ0;X_FFE|SM$oXn-S$qhADDA z$DR2|0|rKQiHOJ`ir;Rvg(EZ7ddcU!R(4D;>SdHL1{^&!AZwvaI5coa;RN3~FH6xQ z_g~qxy?gn}p2#eNT4b4AItQTN@*ga!DSkfZs8{(=#N!~#j1tQ{dE2v3GmZ$kSh=(1 zj&Q_M2gKSF45J@1bDHEm+r}wSaqDkpq&m)Len=9D?PmsO>htDRZuXZ*wY|+HqoT88 zC#y)EdENVE-72-~gud&xo;sW6lMmS4ef7MK!!Mm6V0*Qii8Si|le!9H=ALkZ<0Qz- zmZr{3TvBF_yUu_5r3U+|f5NJMqKEH6e#x0{6iT(9tMFaLr!I3+7m%c!loCt{&;;lU z{5AH4Nd)EG7^YgLQFI(a`gJAjSsKr z5a3J(U#*l4(l*D;-{WO?s84C3xDW z*3>`Gc^VO23MD`t-+(%Xy|`hU-f zr~*69M`Z1Cg!xfJm=*6e_&v;SlV%G~#7LY2denf3Z`oSXr_%|BaiSi*i$; zeS@zX_5IF(tG!KU3qRh`Mv|Tn?)hI5w}th!;t`}^(jj0Z z;mOEmuJ^Z}Slw~8DiYp}k(A<4Ghyw9NII`A_)ypb40*!bMyiN`m~YeOqrS_+L-qby z%0p21YfQ|vpG(IEyc_>M$Z3(cquJ8zXtYHIYIvuzZ4gGFV0Inb!!~2T37HxU?i(nL zvML}AGzG-za+KIPIPf(Dg0u#8T8`YZCeB6Oy+oC2UopfwZ(<`)xdnnc2>H~&oh|*) zHASbplP|aZME@p|Y))Q`)$um5H1uCDKoQT8cP}+!T)6mU6^^mmdM?g?vpD?qUy#_2 zh}&zGUk%X+rCO)zUTr%xK4B8PTlzXf+CW|r4Rw@nzb4V{%uv0XO;EQ{Khd&vd&|@} zN<{_xB*FYF$gE)b{JW#jlYBIIG#Abkg+0O4*Qz|@QUfVW-Q=O-3=my!ZY;W7`(vbX z6gLNa(mS2!;GJo#D$)d2a66k`#}hc#`L_EDCxmeqFa>keyZ#nNG@FFT@e)GY*=)ML za>Qt|tEx6t>tv|3eqyTDNxxP3o@&=Yf_KN(j?mx~iYUel6VS$usG*|yRA!7kNcf{R z_OeW+?@rbCri&(&ewNqjE4@F!nQ*mfe~9Z-9()F7yO`OM3{HmQtO4c z09Hs9`qA!hH_&a4M^>u0yRr%sE zEBV-uXn0}D7sMQ`wF5Mzfnf`+D?0HL6ts$Dyp^TnU$7>14N9)Qu=C(KNADvVkCcxO zcuE-8FK#3qu=f@%fTM)iU+as*E&|a#?W#ji#O6a9X>Y2p1P3H?)!p81|LO@6Zl11e+lZj@W!v4gNDT7f-JeJ^E&yTzWnE8x4(xpC9ch)siIl; z`(Z2lmy%ZF?hh6h4zR8=5IdUUW;UTdJJ2Y!{%asGa066-z=-Uzk^)5iYN1k^`LL4U zsn0y@+>Ix zAHN6?y=lA_n%qO{ID$-L6;7lKFdz;NZZi&cZ#dHW=h5C%6aM`W%k2{sNMhG3%4n#R zLXx7h6Jq~b@%b~OM_XCkjkcjFUMx)ObDt?0a;Q(@@FlJAbX|ju=uxftwPpLR6c@B0 z*VqLI<1iJ#P+zP{IQkn+vGcaZwdh6ir!$bk_0rGfcIsGHEr`!XzFm#J+Virc7e=j$}7=TKxUW;XpMd3Corv zSeQx(CCQG@>xwo`fLJ#}!_ZfAWv@w-_XIRWs610u%?$)z^T#}w9&1c6h&gsugDH$g;vmbuT4Y6 zb&Rf#f_RhRB@@F6sL$lWuzs9NYrV52oG$6=s6ShX#gf!sSnf2x6_rNdMLVmj<}r}2 z>m?7J$^)ZN#)Bk{ln*zv>uJ4WB3r?ZV)B6=67&Vc`1w>}bR^4IUv*4*RO5sq*i$bB zbhfuuGog?D17edg4A8NO<Hi{%Sn|CD3ks{ zd7+;S#FY!f(VVWW^|gS1)^F|1{?Z>*ghBJ)Pv=#^(Mo9yi*DdAfA0lRc+_>_Kzo+= z$}_7DL>dJsvzxK+vUEfd|AG^yb{$A{9pnEa3SE27cciUGE4TdK#Ez77=|Z{H%_Wm;GX6iXq20|(U#V7 z4bWp#y+*AL-9uYlGz4?PU!e>DU zBz0n3s&2!AB-Iif&JFHs{~!t{gZH%ha`{jGdXO7=MN65y&VX(?deb_3a zoPo6?e{|;|hEvs^|By%0%4IGsn2DGTh76|OwA)re2nf}3x=&6Vz+bN}998~42mfQL zmK+^2@CSDyuFp>R(`?TTk~ct)fKq$-FMkHoS&V@J3Crxrw7t_KBXoJ;KzjoNxfILg zH+wnbYP;R2;dTGMS1nvDD1JMp^}zRD6YhOTvgCwSk#b(MlmQE=L+g+V;N@1cI#E!S zz??q_bRVM{r&-R(Q${qRG`Np-aIDLifxLB1U7F@B9@S7j2yclFCcUZHRJ?Yp4QLp z>LbkdV=i+u#y8C_fmU9&wo&n#@F;|_t~}|8cvPBA zu&IQ@d7Q#Pnx<=BJ4jJGUq0bE6It+3=(F4o%9+s3*I4+2 zTQ6i}EUq*zfgo)>e931SLkVfR*_;{G&v&ga>YYoCnTN*EO#HN43~VjQd-BB&CRA^p z5NY*O*G7pIl|EKJ3}>G7x;TtV+9DcUvtl9Fo98m3HLCvYCoRS? ztcb)-x3fjf`y+0K5E1DhfTbP45S%ez;RZ60D|FnC$-3C!@`wV~RJU?i?B9-?VU9=B zg##2;u;DOpdrduI7n(X~_MkHCIJ9ijZOr-!dRk-rGeWU96CyQz3HnG95-reN6I0e8 z;W}3Zoyl~kt+y*pDcaT1JID{L!U1J=Zs+^6=;B5Aq~v2-)s4dgDdF3+5vsuP*Mh6n zct`g7^u-K$I8q!0v>1q4pMt8a^;j41f;6p@yyEOyHuj4LEgZxmv3@8NzFdRBDweAo z@-^CzCszjZfm*~BU~y1s^HnEyw8D;`HBugLNP}A_gc~cF$pc@2{+!^%E}C?goj^EV zMvIE}t${Mu?oT$NfL6%%c!0QY4SAL&!?r{WlcO~)b`3Eh?2?6bSsrL__gcf!C@Ft9 z)T?k|1%I`aM_N~!O-h#mwH(*&=&_`(o&=!CLARvg^C;rb{k&KEx4MdH)FzjC$hIf=t0iOai^p8G21kEIwWM77JZ%@ZR zIl=mKY#|TU3dtah0PnWjVreFI6kK_@uyEjDXGVG;oKs)`N@V@eIpN4@`{oM@}P=$`LXj;0u@7L z1SEM9Q=n8N)N$Ll`Pdo*aK8rn8T;IOpW@H?*yTX86|b7w1|)e9KSIWYaI z;Nvb?8&|BXL}kn)om}18R_SM!pcd{+w{INVktKE_h2y$BUhUxNn-E)#mNY?%!;$`B z2&rS*=M6LF8L?`l=x|c|8MSYvhOT5RuZXkW1;bvEK2b`sgAf6kVqY&}*X)G;V5`h_ zShpbXm+NwJbW30PylUkJBr>)F3X)vP)6GB>#&T%Et0p3AJKo8HL?ZoIiBG@!axMMB z1`yk44xpO%dP<28iV((}5KnZ-7+qRXYd?+1x$@qH+IrmV#B%GaLQTH65<;&5q_ikR zc~1_1H8eYpBDUaHwgtfyGd-{lFm6d%=>Y!`l6zK41UDj@PW*h)!-_O9dIjX_)H~}3 zF|k7eBBuc|t@RLv<}P*S{n`WOk7DDOZe98ga*11T(jy>CxAyTW1d)4TFhY*qf11NkFl~g-e#c0Rdk@?T|diaIX z&a`3AGYQFXkB%^Q5LE-D^+4QB62|%&0Y3QXIUmqtQuSw`T?NF>h_o4-z`^{>jd{9$ z;_Ps+A@D7B)ZohxeS4*7%ck}7+n{qrCwb_%Q4l+lbiop;uXPwmdTYiK(1&b%IF!~u zu;K?)2gK_zZUMP9t{i@|-*2(X(uNFN`8jZAMw& zsUJR`QDF@MlDuKi%T`EKhb4a??@YavCy8MWZ7nN^jC%3cwg3 zkfW7waIfGv{?w6y{DUx~wgsH^ z71ns)06A$0MTxB&@V-oBK3UwJwJbjg?iEIekE3J9Y9fpv>kiDy$>+yueKY-Ze-=)g zyk~LmDZPSPUK;@l6Raj7B(cTH_FXwf-_F?qfX9?>tBW$4oeo8m(!7}$6hwgkW`$cg2~*|E&K z!ecuz8H6WrscGb^jDaB#ub%Em9_GU`@zErK$9_%dVC9RdP4Fv_aEod2k|-Pv0IwhC zJw@t(6PL@%ffK;XtEDZLhkNd{YvW+y)hAA%Xi51aH={s^-x$#r{8Ir^eCKi_|D=}j zZ$Wa%)f$k0?ObwnT-0Qle`BN@jIcXhP==Gv%7ot#{BFSnOzK}d64IBj>aTKM5<;;n zhg7841nCmBP==B7qymsy@<{Nie~4*0llfy7(g#cvi{eq`uc@%=XnvSKGnjRyHZK@_ zOP+uFd~L4MX!hTmD6sTL7pYRl1zh&dqFhMw04Bchjv*H)kyYhw*n>z%JKv7*e5%w^ z558wopbMkbb9OgzD#4CNlX$1|Bj;Cn`WT2QSbWpmeyHR=(g4wA1V>0xond>uHO~3* zX6K1>VZmHA=ouH7pvo&CNoV{!ZQtjPxu1s0&V^Xu{=FKXb0vw>cZXeCq|>oLLSmlZ zcRom;6`A5-A>!KgaE_8Ze<)}G0y)IA5U%6=IL;)d1|A1rq;Hmb!JP{=;4+S6{eyea z#HswqmaXs)MYhH6kEJ+R*It-;TMknz_k-51RoO^Tp2q3Uh@prZcs2Zl-$J0op<}Bt zz=bKRc~^H^LMO#>|I|3a>bH*jZyg5Icaq;XcCSKdh#B+AZxpm-f zv=pt>d~6q?SMB60!^YVU@Nu*ji+|Mpax61){2Mz@34u9$^*;8(K$8{c)1{!vZprF$ z3M%cVL3z%_vUXQ8k@ay1L9_h&VonR%+R0y_xaj_Q!;RfWv8~4}I1q7^mezgJ{m64z z$Dc=ky@Ud+!J6k!a5u@v+`Jq%dfndmZ+1yVJ*B<5oWKfB+)P@+DuJb^7jnZ5M}bCJ zA`o=rdc)Or_=#6MYMV2nc5J;5LF&)8AssM^v1ZQd$0@~F;KgtfIm;Z1fKkrgASfts zXz3Wmo!bnO);w&-C>};Y5+r6EJ6j$`l}E%I7 zFM{D`rdPYFZ*OnL=~yNGiwh8pf0;FjZ9fG$b@#fQo?;$pe1*dAh$( z`y6b(XES&Ln#zZF>opQG8ED~VI`&(Uq~0%By-ThHh4H_tPV0~6+1JUCZYApSFT3-% zq@lnNvx)MjKpxeW+fS(3-6vrS+E?&aI}8lg__%!!!6KE$qJiu)&`)I=>r9sorDB5cj4|#vLlkbWBxoS`DDp7Jy=grV;kAbPZ)jc=!eKz?3g%N=| zqDz0|*`)oZ5do{~+7XJ5%Ch?}#;}8wr73j~N6F2>mzuBw^wFa_h3+}QvEos9)>y`0 z#sWIVj~>`Eq=N}=Kdcj{>t6m0HsOoixP?5B;p4vab!N(5!nNsr@Uy%9#xGJuQC|W6 z{fd)gxt^&lY;Y*U*3;eR*yb$@2C*g%`@ts|)+weq` zLR+9UKxra24*5{m@KUFu3FGDp6g4_-uh5qpSM&$nG$B8Wgc2++IcqvIz$eMyX40B0 zVnb|;0pbZ!K)XH@kXt4fEVpEblJW+}=IR&P=)ZkUTDhNwp!sjSj&NRF_VVvODf|+S zj8gN%sqtDZ=ME}jT4fN%D@zFM^4g;8s1)N--z>2H*}&^P(?6a;Ky@3?7xZf#vWYBo zTByW2e`%lvCjtJ1VtNcZI`8=-r|`H~Z2vxr?5riODkHpT8E82ubu_VoFoz#6WtxXg z5Yp=N((KhRn!T{Rfu{CGoQv#4OS8g%xeHoanm!_{(hp!tPvX_OWnF;bXb7~7k{jt> z&Jf`e+iF>t1E(}j=x+1H5{mvyoAWbKd4LD?2`_A_aL%Vckgh~5U^Ji(IUBUBhjkbKQbfcHpyPfZon>6wX#}hJAkdKr+t_Ob&{h$_ z4>(2sZ4f>DZG~;~TSX@yB|xVDj3JV72;K zSh15G0wYWe(-sW>K|i9$4sAe&wm{Ky-A?;Sg%iW`FGZm$RydOul>tI~Tm^5d3xsph zkuIEZMIfB#fY0cXL3AyAJDjRBX$68xOagn3OnU*iEJuELhv3-P0Xt$LRF<7jkWbuy z2t%pQIbB*$tGu`CCoCVMV?%IrV*UB!1I>x7XzJu28I`~?N_PC-J3K!^w+##Pgz@?HFeS3vRD{xpS~XJY|?n@f3H~J zJT-XP@?K2PIg0(BddEAAY^3(_T$<->XXQyGmL6r>Q-TR5OHUNqv1=tTkgxEhU$K*> z5rDX~w6Ioll;sqgaU~pZ#u4*8Yd4rEzzX%qVlF6QY-3sU%>0KbJ_76FN{{z%5jMp7 zzrEA57+KmGM;xQqv3`?ZjYf}5u7pbap!-yvlDrlEHqr(ZI6R;V3>M?V3?A6SCJ68; zsG=eSC1mK2$#Cu5aug-KFmvwYn6z3fgS=5em*EJ2A7(;7W-eFz-wN%^UT$V(>|n~5 zOIG$ObW(bqk*N^nR3~MU3bkV}P_%`irmOgOMCiX$GNJU1J0b0lC$NPKg{B-C7r!PfdF7jdIL0W88Rb*&~iT~*153_wK%n`c96UBI~c+D!(S%U zKrO*s;re#0Ls0E#bE#6k#)pz_Bt-UBBE@O235GM~3X`G?Xh9q=+IIkZh{6M!7rBMu z`Tp$PNcHbQ#jPmb9EyDBk53BOd4i#uQpMyj9Dx3$o%%RZ;2Q~DHa1I)}8J;QYiHzlIfI}Y$R*+;rp6i(Yel`&lZojmiF_Ije)H$5OKy=8E zpz%)+sDcOl5$9#d`yqfzH?8``8xsT7VF-kSQe=?o2W9CBGf446U9s#&sznQw!8c&0 zM7&-u@n@d|&F2XA292_pBXBXH-b^GZz`x7^fNSIi4OIy3#PL!5rvHTo8JE!RH_+1- zBX1A?v*hAa!H5Qr@(q;{%XsVo#31*BQBmVLX8B`?&I-#p+0pLs{{+uoBvdF8_a)f_ z5-*e0^M<2YUF*=AgR6c{RTbjFyluCOGt~0^PcH^9y;E-1>HRCA7P(l z+waMVxb$#j7B&wV7u6t4YaK~!Wp#GD;+?oX46KdGT&w#zFMl!G=lZGz=4IU?te z9#ryFpB6?><{j*8oDhm&0YP>v%A55nWC*bL<;F(4*{6!Web@YaTIrUM6NktvJ)Yf5 zEs)Hy-)`R%^wuu$aP{!4-dYbhu)w5)z@(~sa<}{T5Bh`PCScZ?zWWK=$9xYdz|4sQ;kLh)$+x7E^BsnmUz`zHK%oeVfK>Xdt~N z!TUh<*v7v5_V_VGw6v_n{h+pU?b*8-0bR%@3M4Pot%5UREkFbCVhZO3c*N@kLOi_Rw#N~64 zfKb*twB_OMOR+7`oG_toHb#V&iMtsdN&Lt7gOZYY(bU(Q7!W7hp$Ua408Z$@3Fe(p zts&KFFUoc<(F&qpAXpnASTf2$iUjtl!LVY0iH&9U7?j7Ouhphr5sQLUXBbTApZrcV(t}- zBeX@mDtpg4VT;-vw;<(~-figIIenv%RUL4sG@iE}R69*?tEvJmjo+P+-A-?#B51>a zm-U)97cP$XzM?o^<`w^9wqnot{RK_l)|Jy6NG2{_^~>+Hj!#lZ#xrTk$7$g>O(SU! zs}VWTFKbKPZ5{knBl`cN^1mcksU ze>g)mv?Rn1i)~T71EQc&nl~GrKQ(>vam~g6`~MdZ!djGDtBlvWO~qO3cvxs97aS4= zDFgFk!X}JaRZtW!$tx9L3aEb%9Xw|?gZIoJiGwdm`KY`&gEMNi+c{0JXO<(Weoze6 zf9eQ%6MJGjP3#|z7lc6HdU0#m(e}cz;ai0!p7DFqAB37MmP1P7L~(DiLk07FDvv-##6Mffs(7Q; zot;hDok2<3ikBgo8pfuJ!m3OgtI|xML!2d&(o6VEXv|Ty(PjgQz#jpLI4i@uJzgf! z;l%d{`qpc74kTtb{{_i)=+)#FJYs-hqQ4VI{GT^N3GOd8GVjJgR67L^-+|HO4(bgt3c4UhC zinpAAIS-5RUliS6lsoJBNbFVrzBlh%Q}g*0pF)cvIo_T)Accs{X3v<02vg)Q*cm%Y%F6N_`dW{ zLl>!jzZmEq1!;>_p6QWmP31Ug03C?*!q?D?E3wREK5z-h1N$v{J!PfUpKZj=uMm0{ z91&*FenNZwP@6{U9itU^#p_&7J3#s1x(BgRaZ|DQWDLppPe--B6)q6c&kJaa$$2gk zHG8=LqVKitLSp`5ECnyL4pDs*D7~C3s)s4>j?~VB6ZpkOVlrH}vDA){t|o*@yS6GO z(tQk_)vA3^b!_YUdk-h|KkxDI8|bht)kzjvcyTR(B~m;{LbEZ4O>ZVmXFWP1aub>0 z@lz#QDrfgEC{}1ZrzeG9+3y2Qz=4if27n9yG=R%8fQx;Y)m4e6Dn`;`i@EML*^Bgk zBd_@BUZvRT%+R_m9t;tepk1w7x2iP}G~z^xdy;~!)mupFK@duu2K|ftw?<8*=|2y2 zjuHC0#*HH~TI-CIuJfA@>8un~hOM)qhH!}Zc%3^>Y*T#du9X^76qZauV%X&o3;uZK z@p^_{&W8K$Kd8llkOx?Wp!;4-S@d0{X=N+fih084PdRQGdCueiGDHYKD)y37Zrr@G z;u-23^wwlJ3ZaWQms)R<`0OUxS@BFZJ(Zd9{_`v=nIJ>py7y}0r^#Q@dBHPcUPcUA zZlKm7*!S$(5dROjo~ec>-bILPCGWu6?*JL@n`)^sH$U7lcIqr*8(g{qIpI~>fT95CvNU z&Sj#|Zj$WnZ#(Xt*G(T9Y=E*Q5T>-syjl`9q(F1@2XD)c-AE~xLk|~dcn-p-a1iGB zt4;R(*X1=8P2f{R> z$IqOo-Yb&CC@GY-u(Imtl)87?%xI8pMob|XMX1bI`p?VhR1}qQz;TDpb{65Lf6>&w zZBYF@99GUNUvB+dhI3?Kyf~=mDL}fxtg<0t%F$|^Fm*u3I2vBc?UUl86uLjy7o-{ zm1$^pv&H8mZ%m&nO)M_kPh1R!#tcC2OFvd+rMcl$(8D#2N5i^ReuE8phGkHvTu|bH zYT?ln1+)(zpKljw>UK?)`Qr!)Ph?#tZ-!Jps z8;GYeSahJ>Kj$|l}d?9X#z(A+W<>eHGoC3Ixt5%VWzyI_hf3TTt7E3U6D0%RHsA}~$5 zI-ZqxiqfPUPbsHPT-hFQjDPrbVZkCh!CcvUR$j zca;CMZfkR_WoFFTna2@0cGuLgt9`F~o78FFq@%~g{r0+ZT|GcK_4Ax{*->wSfZQ*S z3U?1xvh$ijvfTnIFX311hD_AnM2#nsjDHsw^$gDFixF*4x2r4`mCLM8Qc4~kP`y}k zyqB9B2F;9yM{lLxeW25rGqULEc;o272V^OI_IDhRcc)GKgp=m{JZJ0;%bIe2`rTv~ zfO+cp7X;HXR8~4%UqJaMSn!mMMD)v_8B6YGTE^Gh1Z!`3Z05ANan#t+Y|Y20KCd)- zaY0nV3g^5i_ZAy-bZr{ns#5yz5Lib#X7|z3Dj(MdYus8}$Os93Y#qu#;(h~TzXDX< z^gLxZdMAp4J?o0n&vg5ILTO9gkWWNh_q-g3tHR<>!&!q*$K=z?7GG>2yilI)aNp(L z_Eo$+P1Mw*N&Q&xGqd+ABRVC#3X~iYHK!=XJ&d*&aVmq*a@y2ZZHov9r1?XrWbk`w zk7>KxbImPnJQeLja|xot8vnYyS*h^Lt9_j=Z*-|H&aCn8kTIY3_UEH9)gBeos|P7} zcX;Oq`zTNtW0QJ5`SDJk5?*Iie2+y&Dx@EjI40xP?to)O-xm|$u<{XpNvkGx2OCO9 z?c}sOB7pYb$TDVGxL;>?1RNJ-6A)pmyb8kHGdYwv+C4SuThVJU%}lXK)_VLgs+PGiZq+M- zVJ5BPi)EDHhu=<}Ghz`1go}=cIL#);E9cu{AuqJ`Go)N{ZY76lo;vMQm%LZ;=n>)Z zzaN7mDak)fwMpl&Z}sh|nD01mh~7)(cIK45vQOM&-$`NR8NZwiCB=TXd|KLlrI5-O zvEygfo|&Clq@|^g(5O1(;8tFaH%5YUC6Jzt_=~>ykROzL(Wd(zJ}_1lzF1~MSXbIU z)i^w4{G0h;k$k(;&IN;zQLCJh)^WQ=Md3@AO%69^YRZ}Bx?fwXk=k4OInJn;s>9>d zXF^L;h+K3({(>VQTR-rJ)A4qXSzYJ>`)CfruajRC!+pZ4P3O#wUk{43Zn;)I7j;u_ zzqg|AyhS@^cE?WjKG!C@oMU$^Zyc2{SFd<(X0V_0W!_0o_qNpbw%y0&%??s>%Gb=? z+iu-YAg~$=Q;KOFcR$ReX~_*x%4xi)K@#9!ZsCk_vpG@ZfD2T;N6XNPtD4@=B00(65jcJNJpcb@=FTPrx(q4jMC5+$042*sBDisE;%Su2Xxr(c;)!H0)F} z-@{Pj!rg`OcX}IhPIZqC>sXERD;$;YZgS#j8Pb_@D@#~eQ5B-xO^MqxU&3+Gl7=)k z0uSP?wIXFF5?WnqH!JN4cDVb#jaMSG|GNIH(3<&3?o$i(H5s`R?*ERCauN>M7KL$3 z2`CiB->K0ypyXXwqUwZ%>Pc=ZIN4(J_QjBn9q)|TLMvh1=H?PWUhN0t5tsY|q&SMX z@Xm5#*lkYQDl1;H;AGL`p;h&aI~#mf_7p|kp?m^;zC`2+v#gdX5))G{9Ur>4nOkb= zH>G7iMc0ChM*04|xvK6rA3ux|tLfH=Wj3kHi9e(}(U7Cn+RG6C2sByog?Ouj>T=Dc zBZ@EoxxVV3r<@@=eTa9)@%HD~M$rIns{5S{Em=jY??RIPAhcdue-SN>z2=2kna8Tb zdh~E4MWUtA!gS)hFy-!gQ;uq?-vHf~Eoyvt029!~fya{UV?m{9qfWFd%p%H}QR5em zP^#~aosz4iyszHs%Vuh_w7K>8i=Me1W)&?Gi}NmLm?WaiVti@|;|ES#DP@}7pKP4r z1c$+^KBq|?6zZLRJU-LV&g_F(J=IH-=5y^w)Mvy(vY(hSNZ8Cg z8KsfApl4GE>l**gg*L;-&PEmiES$q0Pt@#LCj6IQx=B|2@>?t`FFCr*o!mR_qAzk( zesV6Z->bcem4_-9;S)Q{$DMd-wFm`E^D9N~4X5_b&k0jvCS8YgJ^@k}V5F9wLz1o- zPD^!~U{~mu35$iEH9b`@StE{USpa!$FAnGgL z&c9w1mT*+u#C!kk*7Yzm_aSoWuufUR%!rQ02;YS9laT(jEEZDHYk<>~C*R|I9{zAT zFt71^TI5xGqx8WxsblO%D759GpW95#YJ>wNdFzj(L<{${9;{ z-WBnK>3;YlmwIzY&CrfrNjH+YvWsZ6^==1ofn#1PzX?`*?u5^lSmmE^C0sT37%>T$ z?UtmxDd82i{ENcq(+G}AY78~MMtyQ4x}XFm?W*{+Z+or%)Di8MG9kwEcZ^RSuve&Q zjOL~uQGXHJIN^6)EFZgWw7-}%$_eAY>nq*c92%EyCQ%*OD2na(2$^*`z+!ftYH8H3Ut~pxE&^qqjF+5dckm);JSw@7alWJb zQ=X`#c*r%)n7I|B=RT8JgJ%OqEhdJU8!2sv8Hd-?;^vN1#v<5io`cbAdYl?+rgQ!w zfi=bA*wbZ-&*^iF=#U!zDi@cdS81S*NE<{G=`Usd27**LSSCteClBO)nEte6ob;yW z_8F#Y*;nfc^_>4CC8lU5!{Bi}J1pcN5Rr@9U*?(Z+=8}q04Yf8zgNdHOu|oSMC63% zPu>g?Qu?uXc)m-ix}w*^U?&d)Y0+8!c2Crh4*%JGl)H<+y~VqjHlRK^{BA|Tmj>yS z^!)42Sc2P=t;?pLMTgtBQdlEX)VD0k`RzRl*8~2JcHFlygfN~JLM6I$ft6-w4J>-r zlfM)7v4El>c5rnI7p1Mr=xAy@oh=sGvgL|G-xXLetnY|dPzWIIK&gY}5tDi9#bnbgzWSfM|Xlf_kozZo> zTblZBQhz{;j5AoM>N~xTF3+qy0qzFOZ0)Kb4V38^ubgRApVM=~A(DUPaiHTO6Q@N{ znDl6H+)V!o=mN$5$4YtYEZ@am%RpvwS`q(Hb#6#*g1r>^_$!Rn0`~{N=|n=_=@QQt;P5&^J06n=ytX1$dANAAH^~`Ffcysuz zNfBf0`fvxok&&}!*n*z7&ywAzk~5Y#pu@;0ihrv{DGa##eNp{^o;DPz`kFDDD1T=& z#zQ+)5r6Bg9BNB88%$bAu4Fpu#uifh-WS@>wvp@g=6=9rTtiGfs!6mwxgLTu>$2Jr z@sPu@3i<6!P;;sq2EFl_@%r_^y{D)9_UR37qO5^%0JkmVIu7j!ym-kpJ?)0`_T2ZP z`B=!bLIGtyud?Tk{fiE4s&HWL!mVS?kHYQcKhfsz)QBL8rH%YRu0V4qv{}+)5MkAhyk_>85)*7y*a5j0o{w_%#tyPYMq*Oa&vA@L%q9qRkA(t%A;DT@`5138>Xr8 zFt~Tf_C#d|^njIO=Sk6C*Rx}HLH-dg1lI|WXx3nunYP9YorXKOZqmz z!7SjGJy-cgJv)G|Bvz)Cm{8NI>U{ziy7-_0>mR@f$-S9|RJRrO8rdTPB>$ev8Aio2 z+<`jwZu{UWQtMNadu>glV}@jVmUKzKy(e7HPjDlVSom#XF*s01Dq80*Y=4^po_+jm zvGB!)f%cIUsCbjDNB0hQs+-ohJ%`C7CscnirC5O_x+%8_NqS?Jj{?`S7vF%x;yjHM zQa-l-uNNR?&}Vmc$|YUJ^@*UoSXI$*IavJrYB>j?`-M#{&<1luYC<} z5=^>;w;%_}f#q(#H!f(!MR? zczs@4zt75Zb~xy1>W_)wlAb}0Sk=-KBhAp|7p$e4zeobM(Yv6>w3v;(Dn8AuR$Y$9 zu=CZOcd%=V+i@)U@cH8y_9eR@ouTU~>*5QMjpE`Xl|L%$@QP*F+5Q*fP81QFTAuSy zM|aOH!zrH{p*``@ZRMwlJ>R*YD=`T|TvP`}dAeUlWvaqMoL|xXd(Y7D0oqH~{lGjY zCplwDiHs%wdNd68D@6M|{5CnlWD50G9J-2xpPwE!P?=_i$tLWA;L*XY#9EUg1Gdnv z!fDkZWP;+Ou`Uni7TFLKP>cPy>;X9I)U+x&@KYP~8NlY;A92J%8Qs}Mb-?6<)dpK( zDh1-a0rDuv0Vn@+jj<=Pjq}{fJyyWdRM|MW%Jhu-|!7Ww|9DbqlGv$ z1Hi4&_BRaV5cAuU@5+mN8$AxgHBoq{BQToR>Z+biCO3ndJKbCuYE42V)=dXMfv#2` z;4Zk$n5iok6DBvmcNS|y3vR}eY#uWtGW28RtkBdu-HEh>jFbdMM8m#=B&3rZOV>xa zC3qR!Wc^r-;a1a%X_4!>OyrB&7RvftXKrMx@xpm1jIRv^*E1czulo)94?}Hjsub>S z0DOm|0ET7L313B@PK!wF zYI;n|WayKHtX{yL%rOQM^|k`s6jP_i;MP-`*ZTMyFt=`a?&AypvCh_e=+eu-*kV(9 zKDA4s=QXR6*D3nZaBiG((@}1~Km`tuzVWQs3HZ!{VkL}h^5h2?MWW!|^R0cG(^Q#J ziW#_Uy^Rk>JpLxY{ckxT)`c74s;2QfrZD?j1!lk<{ZykD*^fv8&9K3%?YHX8-lU3b zAh$SoVp25r-`Nc}#DUbiW2wK#fDU2EAdh)eQO{(+opd$D{6iA(pF%=#VHxn6-|WWG z@hA{*csmqJ*}eg*_vRAqo3KeD)yRI<--ZYu+&JyO(I2*%>2rmHXy`2dXoX&il9x>gIp_g7R`kuA{?Iwj}^v_J^Ho0)xR7s)6OXBHqy6s&E4 zn>q!s6`nc{uqyfsJn%snuz#dU2rM|T`P=Ni0Ss;{-#b03EEHblnI$m8^ayMP7Oq{) z)Bk&FS~KGSBKh(0`$G#%*1dcnUe@)@9R8x-#-;tRmPEW3*H&IQ``S9kvy&und>Srs z|I~55s#}8(EqKxexoVVK?=Tz{3jq}&)mZ+YB+nOP7iq1_jk9??fC>3#wl)yWN? zgGV3rOw|QVXgl75Wh5SNCA~~PFdl8xkaw;0&)Er$A}OOTAh}nYJBRN4ge=h?lS!5m z^DYqVZ?&36Z=V^S9Ox;QLT?|z_4KS(EewYedp;HS`kWN_#E3LR@IqQ(03U#_Tl-}` zrnk>3AHyb1*1jujXCkF&XDB%pcWk|G=MN3>&oLV#m_bxe-@u}p(w8DYr`?p}&JA-NZPc_cHTk~?P&vuGl) z_l`^(uZXuF@>+Rr1)(v%-7uUAf2EE6+)u}R+F0v&TCcZElLvhL_}^F~(^5`41X-p| zIE#`?PyHPFy&LYsrN=ShBJVXxl0s zb(St;YDmzM8+S?_gQk}pRrs>v9!Pim^mN}M84fAO0O(K`fUtwR?G;l)D0q{`PuQ>9 zIKXG!@n`FXTF2prRq#ty#M-Nvh=wqP2G;!w+c=tWQCMCf{A1Wx{3ON^#XXR|So=wh z+?aWVp>ERSNd;VWUqYBSJ4GgF(_QA-xB1d=oAYC=U++K=q__R&hlrFgX+p&J6_+t! zm_nWH{|RgSYYaEfyRV2FS45@qmTEJLWR~2h>UaoK26SR#hT^E`xhBBr(g6_JPx#hn zyz&vHvZreHF&VG+D(cJ@%fc8Dk?`f0qqmXCf8v^l-E2fpg1~V3)bXOWmnO6Pilaci z?#J-y4!$KCZ@d#1SB}q|`}XWF;9!$vUtz{$^5@P89^w3rE>H&uFeIE0#ft$EufxO> zk&wLFdtYGI1&a8azK)J(q3kHp3A=QC6dM$)SN7ET9RR5aGa??rYWVgp-HER%d2B2| zPJ>?9=ZuhqgG$KyQUx%(O}t(3RJZkm)RS-si`Ybe<5}Z`K1+5H)bVmm|0EC#;~7ZD zRu{`ADR!h6ZT|yRI3gN=K~+Qg52*Hi*htiZbYRxcyKsfeXzO_Nso(uFZ?-c?dLM2~ z^Ua&HRz>LTZmc-h@~+miM!_)PZ%FlGSwB2KQhVWe)OS4_-+U(3`gygwiqm|^n5GdB(`4(xZmeMSeO?&uw?WZK%J zGN@??MZsB}g$wxW>l3Zx{|{SV9#3`l|Nlm+X)}hj*cxWgO3IdNX(CgTtt1taLRmxh z;x#hB@uXw}!#85{ZX2TYqGVz)3jVQYceyAvJMm|8`e z{f3#bwZegD!AEO`RVRpg6+Esok$9sf!vQ5!bC&R6a@mC{oR5U`eLrmnyr1UL*!>I~v{#nxc2}!MkF&e_7IYeV<%dqX?FZ4U8s4D<5 zMW3T{&nEjrC|!MQhfvycaSf||U?RtWskyycrb{B%QyP4S`{Gp-z)|r&VPMSC!zNcx z^mSbb|{Q3&9FT%k||#nit}? zrtoK`*|=?mj@J_y8T2Kwvy#iG)20=jXD3_YA!`Z+2t#cjM{nTRBfudJkS&*ms{ta( zykfg6zDNk)y}0tug%W=~CD)C;cOm1Y2)%gv-dG$_g@cqkxomfxC;>Xj<#Ar-a~8_k zKz|fZu!RQF?nTI;-Rc_$UM$SYm0Fs==>!rW2d9f0tpx1OT|acvI`3hcO%VmXmhdJ@ z*6z`*6^d{rCv%nGYkj$R^?K0EL3pMfOdB^HyIs{kd4Uf%zOWQe%RTH zHie;V7Hkf1SWdh`js3Y*iVYGLeOr)nOdzlM1jkD`adfk=yT)M-hHnjuq(JNQ?Oth7 zXYYtKB|@f@AY0t8*3Rz-9>(^(Yb8=t`)Et6mIy>CidVy;;e&TC{j!^~P)BU`OEwhR zCluU6{vS{4w$5jkPSk6ZP|<~dDO1#g?%H1a4YQ{r?G|wbAcj{SJ)H=B(!!UHwpD-1 zc%`iQ=9b;T-tnFQFguVhxY^?Yw1FO(({!3B*L%(le#$sx4YoA>vFEey7 z$uEG5aqgnBXV727h|CpPp;)-Dx;H^>y$?l65u@`4#J~n->A^(pR8=V_m;}&-^ewH{ zL5exJJ$1i_QkNv)@5j@ep#T7Y>8Bx`2A(|s)viKGU*A+nA-jv4zh z1PjL8Ms})8dDc5$ONtw zOc$80zxD0jw}G{LD{7r{Bg+Dc;WG$a@i6G7HT$5{Fb`#5N#kq=;Ff{eDfuRv%Rzc8 zc-G(GLP`BUl{yO((oOI(a1$l&E?H_rE6NR?ifX}exXmiY|gD!hx%Jm8KLcP(VGsVYm zD;Zt7v2dL&(NxHqs9X0i`@~xLVE`OFCpDxOXKKQr&!EM+R&1~Rg8k6MhtjW& z0C02qVAxX7h2K_J`DV{w#N-Cx6W>)K9wbS}aOL!k>m}7OBoqaQ>sAIojpn2ub(4o) zxSasL#?6O79p#D5OG|jzEzd3WmZ(f$7tq3|+gy*>$wGtMckbM{hZ64RhMQO%5Fku~ z@a{dOu>D>Kz4I1;V$1jNPh(Z-3-JWYH1{LXVBH{icZC$sj$aYkZ*_h51Xs;`M8vS> zkhf0O&dv_g4Xj0A_DlY0tk{Kv8*%oGdHpz)*tuunerNaVBQYrgP~ zUgC=92E4eJdBdPH)NeDtQ^LbPhh(Hn@*Lj%NTJ+|AjaS@T&6j~d(guj0D+3GiWcN1(6l}Xxpx0i_CTC{;yY{_1VLfyfyXsrnUOx6KPSu-dX3}5-)5P zO~|fVkAS+m*ZapOBT~{uUY{0ooIo3DpbbwF&zj-60YzXJ%den(nhq*nhPy= zu0gM*qTwp&m_~!|oyC2Do`t!f-XFwb7O1@8!QXl#VUT_*`c58dpIA{Nzv6@R6)~#t zG1UMQJ1x_Z5}wBvwDc9g@3sG$>m9YvU$rH2_mav2IxV3t++Gxa_~E~qa2OYJT{a_Q z_43E=Umg0w(c)Y4$s99HIW{hBRN}HR_IlExJ4-aRr)m8HwpTRKoc5nqds&}d&jaYt zYPvH&_~7XlK1uJENC{q}9Tk~BY#8_F?Few zcKDAxe{}Yd6f#(jkXv6+vmmnvIHW(U@f!s<`zI1aRw&xOKb~alWJ%Os07z2)Mz8Vd zpWb}h7WdnJ(@33MhvR1#!3L*=HeXJU-$rG3$rqACXw2E;rl&b`O5}+VD(T=~rClL< z3iH`*o*^TTG6LfdVB383eGfpqesC_UzM$nAWcp*RS@wlAEGHmlu(L9 z-D>_zqEKV0F(rcdV{CZM^@x|q2y*_$)>b!{r;rYnMXN?rwrnyg|2x{vT>|QW)?Wls zB!;#74$Io!k-uf9qS6Vq^l#u0=Y`<$hqs1gdJj1XE5aP4?c;y`mpYJyp1U%h7zE65 zjoJL(4@Sqkk377Xla!W-oHMkNVO=LgW%TAl?dRJEQVdo>9xtpXo_Ff8)u)^v$||IO z!S+W|`fF96F6E+Ff6|Xv!3i4-zv1HVCW)_-^l?z=&FU9GUxkK-m5=Y#S8aROl?Cx{ z^zy%y+ap5Uh4JtVK%;4H^#@V7Y?Pfau19QxnyCR!_i34)xPGqup^}Sj_VRKnc1b>2HVX` z{7v1cB(9!+;A_HJFqqiEi`4{r%bpxwnO)=d_2T192z|^}`FUBG6LP1nPJX8dnesV`I5|fV=^0A}B)F*Egu*o&n*Top zk;|m5O6q~zCa1oxRQAmWL})KfnV$izB@zprZ^8y$rU zE}L~drX~Q)zFoob54!AZur{JeW$oUeWt#jmBl??}(sEE-SWDnx&^?cniCu7qd{X;E zVKeiwVGIu?vy@1r6ihq2kY1#x2TcU)!7)bpwwAhx_$FweHwZ>n-km&JJQ?NR66l|E z$CEr$7@wI}mfbQL72k=6_R$Yrp9>w;p_MqCmspjL<9zENwbE7b?;q)3>KJC!-}{;k z8pg7E)4LNHkQ1P;eZ)~}(Fo%mQ5s~a?II7bu7WAFHMP9-7RM7DzrP^ncOzxN`^)nR zL-K*J#bj*E_TolwxZ%N#V1@k|4pC{4`Ynp}b_u-^&c_Z$uV0=d1fvX)77d%s=-kV) zQ+4oy<1|yNgP$%NOD91-xEKB;tV`y3pDsj)7J9!!vm(FtFaYijoS3h*mAI-F6a94X zI{5l|_u{$;|K4*nWHk4i@jcb^e4VZaK1MR|;NQ!;XL{+BGa_7An%T0pFlc@#Rb&+SlCjazcWl z^l4}2BdH{n`ds!r@(r=~-v1gYDGEveV(1giwS6rRAmJJPql3pfuc18;Jh*?idU}yP z1=EjgreUA^4#Dc~P1Pg=s5tn1I!BVC_@Lfx>x>DS!!;2|RTWYjdeBG6;gYS=41nGDs*y-*V?$WCAxK4I%cJvzuTTbSXLS~~ zUw$E}eS$fz-oP!j9P`ubVf zvOpLj{)aASpJU}eQ^CW*1wCm6e{nH&Fxpq$_ooFUEG&KUgvI>wkF(Q9Hd8YHjI4=$ zezWUy=6`g3O=myz&yM~)2I?cA!d^q(E{ko7RPb@wo^l0JN#gaZuUq3B?i!URpIhae zLShOAR%+Z%c~Z9=odev}UV5J#c==%?W#LFLgIxpvPSZ}fD{(KN0YmfojwFw+VsbK5 zcxP@~*~R=O;Ulzf8aTw+);Dg3cM3UCqHT)9 zdy{(hZNg0+98Z=6@e_m^sc#81MH!-j1TdUA92TG1*pfVqV8*2uKc(eWk^z1mpoc$6 z3L=eC;L%Sv;X){bpU4X?4~GeE`?h$72)wRaEoL~iJ2Ji1AIyg)h2ddB3R~zPbyMPm zu_?HS-5&MHvl&V%+5^*idbOZr@m0Z3^(H|GhY^}3R1>D#cBJwk+4c@8yU1m#Vup;m z{Ti`7BSFO|;JwtcG{rF|=RNi?C!tbGdZe(0T2O#8K{n?w0WoV(K2;NGCd{3YM3YSX@?t?IJ)14lmak-5GAb#KAS zwj7v_pZywS&x=_>blkeG%gg*O4V~&QK`!zQ$g;15bkduA2MrpP4giJAgV~9P9sh)j zQ8L8K&ssT$#vSEXG-Y1F(Q@gSGsQAZoM;m>R91cUb$q69T#WhC#Hq+}d4sD^d!HY6 z+H)4o01<4d@xrb;{>P_lr?gmCIKfJciu3zYyXw5L+!Da zh4K*%I@VDcquNp#d(P4{(xxTT<9MUow*Xl60LeLfu>63*->@V|60UFY<1|?+1o1<~ zy|zW!S@w;bpNnYP4MPYr=XUs03UizEcZMr_Y6rhawtn(6!eyFyFr2ctq<&96UF<(6)0oI&Jguw*(7 z*~^^N9$?_N4grFX)cVBM0Tb-v5Q&aT9P%-Lz+)hGBTYxtE_kfxam+q$FfD0HCip^0 zWvT4^@E9Cp^3avmmO&u#*hX@UBU{9@Mcm^v|GbL;2@LbGZ(4Bqd*3iV8FwWY`IS?# z2oMHa>+#KFJ~er4k_;6t}a$X@0W z2-VL)!S$z=j1P`sH9Q_ljBGBJX-{BfeVf}J=Svcg_VG{!Bq%?4>;{B?>-Hy#87ay6 z#NitPx4zy~k6V=J_;l_u56O-~TQlmzK%xE~#c-tGkyHFke%mjlW6=Z5=~kZZxS&FH z$)B|DNpmNnY=AmnI_@M96=cxG17n zfjWo(T!!qDnKaFOX>#iQvrUqVY;*$352VAt?T*em2AdM{DoJx?42==9ifR(HqaHGF zbc6k)JJu&!tnLXkz4NqfWUmO*B}&vo$;Gn1#egBx3c5N*YXn_SlEcPlKZV9Gpi06R z+!`lrHX-;-0PyfOvPDcC6cRH3l=v1T+c$3kYmZH7kzVnkBFRP8-IGHJ13J`hB=g5F zIGue^oI-J9wA&y-W=-N4Vy;8_;nbVdjzs~f|4v3olj3FmwE5bVgKnd4mhby7LTe4F z=<%*waL8d_=N;g3T~V9jQ}tz((Vt`&e>Mq|b09{KP-b29Z%Q;dSKKA!Tsbq^b4XI! zcg&oZwE>P^y;F_BCY)2t7P%@_PK@>MtgGN+W)VG_-SEvhckKR;f+wFY>MC+BzP?|E z3MqzU(GoK>kh*bMoJbYgG5s~?payY7v1H)r3KdUPdyLp5{h3;#XZ`WBOeHB)5=Kn) zZtIVHNK|5!|8UsOc%k9&Kxa^?CKY0UDCA#y^{2gL{weXQtFA_BIK}=KjuWP2Z2Igp zd^#};_~YuLAe%#v$e!~ydt#xE{HBm1koL$NY4uL;}pH!i)u-s801xteqH)^30B;!bdl zz`kSKSN-eMihaeRQ4yinFMdrU<$69>miK>%^mw&L-J;V$BlvifZ`2QslNt4p0Yj&y z9`^3}adD5e;FG4xzDqO03s@W0)mE;!*y$hmz+2N$EWe^|>3$4PB2G-J(XAzQ@+I>x z97@oRH1Be{kKqR)MV-HN9Fx}g(%klF!Ijy>w*%U_c5Fp0L|<&l`k=EuC(+}N(eIFoUq=>-t(_`UEf?VMu~YJwB5YAbSQ8dX=I z-!sTwF3GWU-0(q@Gf3`j+9@7}f*)UPS&(c?QaLcJD{qE^d{@NsoYZUwHdkda9)P&>{@vN6iP`kue8 zjW#92FC5QW$=9YRC)U?A#-*8M?`YNfrvKfaeA?lL<>G5+V zm)B$7(UuNN!8huHOCbF+I?;43E35oR6dYQIG_9PJp6TPFPawA9p8u`wnlhC|zi?*G z_f^hfY6iJd^P-v`qFa>o1~som>s=Cw(T-OZ<<{KAm|$_czCYPnI-Rs8!Aj&`};&AwlR8?CpZLjQ=2x36!Eh2V`d1L1<8X+R~I*c&`?hCNYK(Sx%l-b}8 z-6N|5TY`RGBy*mIc$3I<1Q;i%`j7um^`x-{zGO~}P|vk(F`4osycquUKUA%xD{AlK z{@338$q|WG1=k!&Dx_rh#*VQKTSE4)S|rGJk8E4I1gzl-Q4eLG&4GfDvj$Dhj0x$i zqqYyP&EMU3^m>yhUpnXSbyNrvO1#P^6E{v8e9W+_Wy{e(fddAq zb;k2ERDEp0rJJwLh}<3gyzt7X`PdtupMgy&(nrqSt$Hx7c62n*;XO4-N{9+wJtMV5 z`kLlZ+K7&B%HMhBW4Oh976VP9vW8A*DDCFDa&jzHWlD=&WbD$Z9l~SpYg+}x^Q5^8 z2Z*Ira7=NUQ(Rm1yBbR-F3rC)#lI#FdA;CCjOrk9-I=1{ye+<}7rNTiD66M?E1J8; zHn^^2tyH=<)%uzyYv1#LR!0Yo}6Q<8W>~vu)}Oi!44Q)q~c*JKDM^2B?xf%yUw_{MCR_`c}R2MP}WtLtxQTKWY+gWA+}kS=R%-iD zj)TEP8K&Q8s>1NFDS^Un1y1;tr0{z1CeiMkuF{}8i>NVDEz+*@g%I`K??nBSns zLe!MT*U{&%ms3`tX)oQ3(D9{&rVI9c(TABcgFrM!3n|@mk_}V4f!(`HcW`7ZYgR3z zc7O1;=oA>_^bfdnmcH?I42357uDN{bK}%Vmb74h&X{T=i+}zj6N7n00CkB0u zf)TE3`Bz<4ML@{2zr=`M;z^^}r9~c1uLb~C=I}!$d2ts7YLRb7Usq0Fn#W=4)+OBN zt)fxs#67=lcRqA@)#?7vk07g@w@kSDKTnaAs~*V05Wp+<3-)6VucC7o1}H|bN3XRg zrN{6j3zFY|Cnl|D`pgay$2rm-cg+@qs)Ptq3RPFhbePqE$?XNd@Bff>1;EB{hITh-x_BiDX^yMy0d_x24GEz(E ztre?mN{uButp64(beW#+T`j@G`YZb4=A69BdrVA$8*jPqcNaW}WW1Mug8oxrv-gL9 zxBXgY#I)_V9p=)!Y|1xt#(kcN@u)|ZDCdMmh84HwK}c?~+Wrq;mD{_(u9r;{$;I3Y zZmXHa(33Cp079m{xwL6IX-&2qX#UJC3DlZc+#=Bq~70q2k7Hc!&W7+ zK1Ioks~ObHo1$MbPKenHtMkxyYeKeK{Swyiq22lQl))mPSlAKZXYV_Va*}^F%gcO< zYR?Dve5+F=3zKsF#O=G?bz_rpB~=NPPZ~wjn0FawUmDIH130n>fsS*OFDo|^co-8h z&sz2B_(sag*)J4AT+eYEcYFQP1zA=p^cCm;_tYy*EAI2i%$%J%(S~EV5?=tPlc=Tq z&Rh0^i`j1M__EG#y#f(mi3_Cu;WGcwk{gOGu=W_|S7aJnnHq#e82Z+Kih1{LSz$92 z`@%D0GsVjduI^T--gRcP+G5RJ4GR~vJ8eLUw6`Q@(}5pZCi**;*Mr#GYvK27cWVg( zcdmckSZ-CG*19J4vw;Bb~y%Payl3`OIhh2N!;msM% zpZ^xLQ6DW-3xv4}7n9gzML5AjN%uCb=Ac@hfW1y1e(>kZ^ItB#hP>GB_t0pIhH73p zW2wvwNEYF01uV{c9V=uJ!W95T1gD@-9f z;}C_&zI)*4U37IopQlqIP>+$w05A+-S2j5-t@<(W@O_Tcp5Xk=T!WL~ErUMRHU2ZZ zv?{(V6GWAnz6z}hcafi>s;%$e%4z}youVlyuWY#lB`S zUBkY`v;G1M-b_#>pY6M$N* zCEXeV{d>1-6|5MNGelT*g(cbYAGRLD8~(IbroZF59@?2}(eC|fh^dpFJj~GK@9Y>w zO!%rktiFrjzQ|(nG$vb(uAw;#3;;`F_+u3wIsC{f$n!gKRwLezsQyDE$yN^z!1$raam;!8^E$OgvzK0qgdrMj>zp6SVr9@7| zY}@~6XDZ(okJFdAsrJyRJBX8NoJPbp3M?Lpg8%Cov-a(33DHQ_C> z%NjnVqz(?bpJo#`#81#Xmd zdF9VmJ|G+6i$wL&7=J>7zwEK9Q)HW(LqL<5W*SZW=0ItDX99>ew34Vlcy-oQ3o~Giq4cujQFKhMJoRQ4yei>qr)F@nC4bgW$ZUh z$pCz4l$FL-t{7@f8ZhZFambEIIpNMj^UrWmbCpD1mhC%aElVyFh#@r+=AM#%k_0iu zs9TL7RkViQt>|_`~P5x#iw`J?uJ-*>FR|ikoAcrR5iz9SYR>eJ51`$ zl1&wF^A|Z|8$Z(9*pRqe!S(eOL-t)fK$4A;MQFO@Co&l#h^$*hyEnSN`DRj4LUirr z6B=i|#L`*~KvUR{3MolGA_>{Lg<@VHZa5QDRiB2187Z-}fWbIaU`YgxB^yW@bzui> z^foWC`G=o;q5TLx*;iC)XjX@vUj<5AIRD#6V{AJI)Jy$ptFQ)#Kom?D;-I4~P7@j) zo||skItJv7-B#H^X_i4KLAeK}_WfJy#79t>ceq;QD~!m46!SVkl8_xlsiYMu$2oSU z$**|ZYiC-EGiG$i@RH+BHJ#WwCzn=`oiOWP6Tx)roE2(X2&Z7zkFFm-5dVQ@G@kpR z&%j}kK5`K^=lY57S75gu@wWADMfNZDz`(}!g!y5z`pR}3y(>i(HYek_VX}RCi7oYW znHO?xiWv~0^7RQu2=j$4CI=ojppB8f9nX;c5283|^ffS5L>J{-A@1=$TpCm5pDN5^G(K-o)Qm`!e=V%G{uZd>}7nW&#Wv=+VkC+Qsg%XX; z(R_TC^%04mwyRzfm`$g&H-JilJ*muc8k@ zAd=k1!CbiAeP-|2Jf~5ZSz!E#{U8%&^?DwPaf7gCPocOpMsRl4{W%n#LN_~+r}?Y2 zksM3&CEqLLR|Xy#rSSK2ekZBsSOwPi!flM2MC*0H`G~7$%uTpzj`Wcci&Z#aCvJVr zw1QGZES3lwje(OFreWn0(~c}p^|{-BP2avo7rA|3lmEJXN;V165(gyCOHAbXU%Gr7 zWgjm=G3}+Ps#y=rzimXju{mIjQ68DScR%Xlod}Z6nCJ0t7SVyYLbe`OZV<@7=ZazR z&V9JrSvrhU|G$EnN^-gn9qv}c2+jXyiK~RB)q$MrEU?E&qR^txQW3uMKQH8axc)C z_@ywB9=E^YinnBavERq8Mua7?2nx?zi*$(Yehcu zlsHPh-@TTW{Z`IZ+ngIso#29mQiMh>_$mjT5cj?_w++AgIkI=5Otyj^Ev_*V&SJfe2ebi|C=kMw#)2_y_nn->>p=~Ap>dpJ9u zqAzS(Kk8!0YOi;2)P{MNs;c6@j0z#pkcs;ylg%q>By1n0*)8yrzIzsN6=*hq;p!y~ zXYAcaQv~JdxSqJvP*e{eIklUBEkyf2P6YB(gHL+`{jVhPw?x}*oJ&byEje`fzxcjE zYL%19*_?YAmC=pgC}jBDW=vWPFCi~e=KG07baiF+2h>B8yuQkNwIu5B-{Q6~*W{6v zuOH|huIB^vCmtEOwoHUN(>o`hu`mbScNYv~4|7wlWS5m!Xy;o!xGz~<$^X84TK&sS z$K5~1-QRYj|IRX9SKBP;F{I$?2NQ`XD1*C=?YzXicDh)7&joOE{exDl!0O@?x__Li zLWO;xXV}9ZD8Wj=*K=u~UUBy|Yg#>{Otgfn821{9{YH-#z=0cP0Ic zLS}Q~{{t6GhWvS<{`!A{t0lh6IjZ9B-oUZf6$A5VG*~p^ydd)Lj9OkH}hH1X5z_hD!|6(p$B_(}QuXRaa< zAdkNqjMON)MwS`6HDc#!RWvJyPBtfpsfr%V_l5rpLqA}oP=mh_^m!wj6>N@aWLOp_ zD^z zXEsDOIV(ON@tF@8S&)sUG4@DgM=|bu`^D0lDP`aue4}z2o@rGSJSvmZH9~2`Hr3tt z%;`~@tEwLG$7J&->}1bSg>l5w&9PJ-OIM$UGnp*bhE3I5+6oZNqQZFaBNoxv_q2Jw za@*B8!A7xbYk0%-%~n`Y7D2?T==DVo_I|MPyCBafp54%= ze79DPl*C{qIVc8xj5+Q&P`;R|B;BkG=7)BB?HnPVT(Vdv>d#kxnnVnYsX{#I<(7(7 zy3TN_xz5Rx!KaR;UaQlZoXdEr-9$wTshT#+KSRu2y>EMrZlZ&D9M2s+l)*ZJPw@bF z!cMK(Vx!gck1#^#Y;t7-IGjk(-C$w`$DHJ3rLAzKpBS@Jx>wmWsdoP3Tpf)CKOkWi zhcr~I_E?OY%J;?OAvr@nN=5}ANd6tZn15!T2n>C^54#L&=3c{A&X*RYi&b0}=Lo3C zWUJ4Lk`vP4xn#}u4>PLoEra8hT1-si4UZeP-fgQ`F%fYMS`Jnr!i*gKmdZC=-7VGxzI6%HSLk;?o|NcMKnX2bLX|ZoA&FPkQpt2oLf$8gHo={N-DHK- z1H>mZwhYkM{42?ldU-O-STf^9_$`{)SbJ#uo87D=2|W0f+~gS2-l7fj#2(U|o8k<3 zqf}(on*nGSbkmb2_`bK3Oaqm(ylDMowjR;*ys0toc{&pw_ zC5ty3bnb9m&*79XHMW5Kkoc(F<&TH7Y1XgF)juE~tln6CW;NV@Jpuky6OL6BN-wC*qD-~!$L$r080 zoDV0h=}IojoY)-gU21zImZhVGwxpOet^g}}kC=2gpSZmaiI7u+cL~5tvQ}xQuI8T> zsPQ9@P*)rks~Db$j>=J*T=WCIqr+EwNbHd;p*QHDNU*=!+sVz3byuixTtEXhIQpb81j zhxrvf%SfC2M(~5Hfda941O+S-35Jv(#i>W-Pi;n{dn|*iP0sA6G1;3?!B5<|Py?}z zXYMoKK|lDDm^7xCgqNtlwB%wA)20^UjCZZp&6$h`!QFxAN1S%zs_1%pRx|G3Z1y|g zebL33Q|GI{kz)QsC_bbOIM}E4Ilrt5ZVarcOl%>pCFlyO1L&Mkq0(tH0tNu1Q)>=d zGp}gw>RL-kpAw>BI@Eks;!q$2+R2^dGfYsjwQn|(AC`e7n-G!CEU6`_6gy29pC(UG z5)zz$JgO@7mkMHRHBqz?7?I*{aaup?^i8O4h@H%-+?5kmsf*fc64|v-X%5=*dHmhx z5gJ?@f*ZEFz5#zl-VzNilTDb7(*!O*C(M{7hz&4K6BciAl2F{OIg0!7^f!vLc+z|| zf9d>D(@Gfi#3^Cn1#CyR_z+BUoV)d|ugYb)hyif)!Ncg(^f~sruRiq`atZ_Wl#}cT zaMvjK3y8v2c%y>DkUWJD3i-39%1gLwW-j2{%mFpsz4;2eXfv~NbExdM@F25b7y|U& ztF~|8WsZZLDK}Ps9-h$yyk`Q*y9KVQK_?U>CZr!A5uX^#TOzFW8f>+iiB$gPm;pay z-1An$X|Y%)5TepVh=Q5<$skph@3yXFc9cIdKu5*lMp3vU0x|mAd6$W#Sz~a(!RQj# zZF$#w4H65Krf*CgfrUl-DKTT*{6g<|*sX`-4>~!$`N1<{(pgI#KUyLmw%SF0In{mu zb2W0RB40=9&e@$~YJf^$jxKRD(YbJi1IQ!T%Yim?NRwv%Q+Fc_*;l8dxlF<9Xy=p4 z|Iua&gOSBzig>pxFv|A|*-Q6n)gVlf9eQ#sfc74aRa@6o@_V!$Ph3b9rqJH0pFsO? zna_Mu7l|A|5xD0u5!*!6EZ%fc0pxdN52Q21mL5G4S^<9k$sRggk2d|%o{8|nQ zqS()%WY_wCj0sy!fXI|b5=p(Cf_yh{U_ap}VbZXHz}LQ!yG5%RpL}&MQZOhBJwgCs zN)RZH()#O(gP-h!UDc<|$#InCF!1je#H%J33zcy}r+=NXR*t}vz58fDd+G+?Xr8Zh z`aKs+iw5uwxq)vyc8=28)4u4-$JW5hB3BP?KG?gic8W{ZNwKP|2AAo3_-3_B8Kpz3wC{1e2i$15F-}cA)`epyojsh#J3QLEmxrvblyUa$s;;7 zB<%s>3GdfbE0{*d&7oyt1*fve zy?o1(BZiV;@q>ZiDTW5*3hl)?eB_Km1CKT&%$!(_C(sx?5S_Rw)zpmn+xJ9*KXy>L zq%%iuZrX^c$JsNtdXvsse(~{QzxO6Mk5@i;|0}Bj2&rk9KWm)YahRWyC4J6H8s?%$ zZ}|kRh~$-UZwot3Kwy!D!$_n5sxk8}^100F|Dt3_q%@#j9o@pU>BK7+zZK5OqGayo zH@)OmDNywZP_>L{`T29#-M@6(&djh+CMG-Ev-j1Y58Nq0Bb9Nu)c#)0f&4! zDtYB47(#|BcrH0{#S9k*cNo_OA(wV(WpoHakon?wuPy%!#x4YNyCLU2tx>$_OrxR_*YAs1?SIu8SW)8Y#$E>uXR{q6BO zXxwI+&ecK4gdi@Ixv=BZ!AA(lckS*&t_|}p2A9F2o6Eh!4EL-jO(~m~k!DllN+Ua} zFRw=?px^bZIxr`L52z)o$2?dwOn-pE#2ohv_ih`J=S7wn;Z{F7+5bhcv}ot0M5AbR z5Ty~fx9UYl&HBSiTr!~%Z!);5qbn8|gzW!gDO3)yiZDM_pE`#fZy-@I^vtq@XzjF9 zR=skIU&6)_L<0Ks@?D)Ka(>Xf+}vj6=$0CzB4qGdbu`1Klw<^E4rZO84ev&EwA2mki(ryK$dvr1c7AEg;|2o{_1@?nHqS9T~ z1`C?_`Q&9}_T=2C4vNUnK|=-rRHgu~RksM2OO`F)6rE4l$g%skY`77XFpl!!5;D!Z z7FaltlOBh(J%~Tugp2EW4gLK&HA~lowvd& zLy5cQVYYl4oL_n6J1vlI3Qc_vG<8C_=^YLHOkOyVnI$P0AD2A-PB=a^GCrCXru3znQ(Ni8Ox;wujK zg@*2g_U4~${;LCcPP;N5nN#H>pT|y1S=WZIWc|_;*xWO8$L5c1NLG)qc1&%$nz;(! z82_v+(rplCqeBUi;>TOvzYcs^cej^^OVFC=!V;}ND00b!2eLCZ{sBZUoH~?X#WV0N z*km9E%D)224oQ#>N%pU|hpM6?P?S6bVtU4%RBa(TLP&JSm zqtj5hn9e~MH^{i*#c$A@(i!?>{WgrY1n=DNX>t3}MBdRMDgav6oPIH}g6X2B>ie-v z{3lwdJ8#&_P4!W1Gbk4WDBlx8u+PO#8SFdAHb0xTsNnGRJf8{m^rGi z*tdn!Moy~J>r2rB2dI!gW`A*IAu*Qq(x&uE()i~S{ulyH?B{6nWo;gLBEK2ZX2cRL z-T6EQQW1x}9wfI6eO{QGyIVonSwG4C(L9zZB7zXv@|0cTi!WzxXv{-CW{Y5Z!3K%BljM+ zrWS~eIXm7lmM^?nBqINk1hFjxn^)V|u0*ZG=Cgdc%s}h>8|i!wcjqCWIFT#Wl!y6S zTDpr#MT#UfMXFE`9<&95gLhv=bq1r_bu~$|U@>T?s8`+V1q<5`BqVgJejGZOe*9oaiu#luxK*`o=m>b+Dvsl%^K-O7D}*pqml1W z?E@F|qjirAJf%3Z<4JW;OEhqbHr(6c&*yYn+x-EB0`qV{&pMO*-+^()T_osiBn;_S z=J|GWxm!a}@!9a*ZMWvRaMEMA!MVl**@HApb@o5b@@@XGe2Pw1uTryHIkNg>`LWS8 z`hPgfs0FHSi!J;l^26RgBUj%LtC4>2Vs|-HFk6$~b5!4f9hhc-7PbY+7FuNOwB%cz1@CfgGFmrXPlA?pruRjM&Cg}vURDe zZdR#oSa8HHt)vKP6?9ghSjv&wf4RgN6+~w~brxYtpr+A1=D6Amwr|*xe$RI|RJjY) z2*OPIhPf}3cy$r;2+`N#s!oHTNBqjgn$KKHi_D7~bb?nKNF}(dTe~kS=4N(eMjdbI zDoOFLjw$A0m&h%r7$o>H_+ycg`>uJz^o zclYuWIw(QN8Mj+4)^%pg@vflIdm?wQV5d z1CGUwTiF>M=wBFjJnz=hq}YKJE+HzQ!+YgWZn&F}@c7Z0tj^o#)>59tOl{w6pHZOh z$jx!ya@jL0CYAvg1ed1s>1FaB_DFjRh~Hb~ROnG;@5#%&J2thpcdhJbN!rvkbs%;2g< ziq2W-L}*#hcGc-_k}c+DhpR@Pt!#etBQM2R2cXIg1h*7L2b+b3BKfOC%^~dce3nUi zlb8FGnwzT6y_+>{WX=rRVdhGRExBbc|wSs&mLQ#&sH4YhMcbU_Bg}sJ0^!`#9ng1zUaa~t{Jd}Uf~@Qx7gGVGNNO@H)}8UN zaLV4Et<)5!G`@5JrR_YU*egyz#*PBeyMm}>;@Y=Z^;X!+CAMZH^9PPR?KR5L-}5_< z!G@;3q%6rn&wfRpn6s%3!c0pPfVK{0+w6e4a31q0>5UqmZ0zjD~iu zr;u}VU}ls*ijWK*S@(OY48P+JK58RdP(|k55oFiOZLZ!{+O3a1O8m*1pg+d~N@*6LB9@6(LBhIxKItC#|CEz;TVQwg-T{TVmcBaI z{7vYX7z;;?CpYx^H2>uVU2*=jf4460aVh{cCV}&Ad$w1{`_-6cvnLlbxwEqUJsV$o z&tC)VlAyOx(C1#9b2QOx6yR{~EM7?Qc2!DFMeiQzg%Xj?C4&|Uy+V13x}$Q{%|pr3 zxJ+(>-P+@?`$e=Omr5RTK>HP%D`<(V-^62(jHgyOe|;mlbn5rGsNnD@o+n@;j?xEX zJ%JQLg=bc(b2EPg=NnQo0o5^2X9is~die{dTuS*Q!FL6T(qeL%@5_1rKg2)E9YE)*IDTNtHXuz` zkj`|oivhaH#3j`RDGRfeZY;e_36|Ke2AaG(Yx##-r7GA&IWA9TD+n}sU0wdc_xa`m zd|{!S3`9VBe#7vpAf#)&FhA1&(sou%qo+ILCw##y>iym*E}`qHtM5|Gn?yt!4|Pr# z$#f)lcZ#x!0TV->g-Qz z__Q{p1Xd-rso3SaQZoOFyTSii?$i zXe~3h!R)e{{yO{hjg&nVV1?|pv)A3Yg}aXWW*tkC1y)}t=w$U)QXJtU)-|~ zP&NKCpQVYUBT-o$v0#&Bn9jHn#To=j`+n)@@~z`l_xlO=hCYR*4sNF?8PfXRz!NOk+lP0Kpj#^k{0IyxNn4sV z4jDv{2j&t%E-bx|l991l?`40pr(WQI;vsya)6lnjG<&>-uTt8B@fml>oF%@1!TtAd z+kL41w*cqQ(U&kEb@4$#(64w-JM!$8kHtl{X`Ia|u4}$QATy%sROdCqjdY5(QH4t2 zj?}DOf{^pu>e^x92=F_X8O7>{(FN$15pe9-7S4+UPQzOKQ;z_G4Z#!X#^Ac=Z@^7o z+y%G*4NSPfpqT?X>(_k|TyEh=hb2;v-W6e5HrV<$^wi!|9rmfSYcM#uW&!hVmKb|< zlI7H?`Vwa#In%x^0N5}T73Evp?wuX`{6uVXcyEU z>F*v@l`Ci-D*7GJn<9X3uQz%;p6T_dopMDJ3WzA*l2jE+yIeGQA}j3<3MOX`#ECj9 zRyr*a=H-$JK(r@Q_{n6kv4@EfJ~6nMK%l^;FXHBxUIoGzzi^gR)LtNJ%*al5U|xRn zwb>~(fX4{|#{f>oxS8*#91+5ko|2&4R5&8=HR50GPcsQ4_m+CYCBy1-k1qLqx+}

=^=bkL$gpupv?0e)PMJA}-dMGe$vcV6I})KxOQN%Ku~OxyezNAAR46O`oXeLPJ3 zX1i3C$dHT8L{4Y3yyspq2{d}juLY8fczvdFt??5!Fu9ka>2sq*f=qhyvxm2s(c<}g zcmMoe>C3vNwPi7#Q`h053bi)v`J*#C5zlA8(X*m25y`P(=8sTG@q;czWgg-3gps^C zc-77)`AqmiZ}tCMh}aPXp#zp-^?=DD5 zND2ZXARPT{bKl;}oBgog z+3(buIcLtC^E?!WC;J0UiD=Py$N7${uYkGxr6xXaN>0_>aox&lLlb$NUD z12yt75}hFW7aiXWiG@(=4=R!_bd3PMA*~bh$M1n(KltC)wmJ25tli^gDjDNl^AH z5+AnT8PJt;0C+Joibqi`K`iJf&iI7I!aMYcSo6LLaZ`f3m~!!ScRz|v7u<7h+0D(R zGGy42p#~Ifp{pl5mCe5|OE;cgvW{PEn(49Kp3BgkyFs(cum4WAk7mWe_(S9EHW)4- zdU|?(+8qx7DgfX~IideA-I@$o{YoUOW71?i)0ADGBn&05d#T2V)z7{+*KMYZ_hZNT zxnH~9?*dnO5ydH*%=$2XN7=CrfA;}+8Ywr$aHHqk@Sx zT_w_F8*D2&u>y_aS1-KRSJxo^!(qiY_e`Y$;xVbXGj z$Ni?gx_6(%HcI&Oz$Ruh?Cak4{OAGHyyzJ-mpXUcCQL3f2EY|s*y@Yh8S<0arH!uL z+U|g7#w^niAjfmnS$0Tz3ObC&(CLhJ-E(pghzfieC=ywL@sVx*>WhfTqi_@UJJ*$> z!>vrkKWd0_*ZfU}UlJNb3xA`0B)&;zGK6?2_{^l`s(|$3uv#M`!%AiV>y}oo$`Edg zT)f2yxleI5q2c?4JoJ5xYB=R%Ed%u*{*oA$DbaoY?j~ippWSw9pob4M3g+h`N*%>! z%tNo6g5P=h8?E@Ibsp@5GXvPBM6CPnrF8<0L3$hfb3G9haCVBRhF7Y2pB7hqcY5bb zez7zZcNGR@-*ZB}63V=az38Q0UCWS~o08UW0+j7Wd3=`(ufDEj93OseFM7)mbdp*5 zP1RxspcLXfCh!8c*e5H!k&Xn`QaVjqSOR?S#gFJ^pZV0b_FeHA`Y;Z;^sC_ZZQ{S? zPFzwKMw(w$h8CP-=sX-0OcF?&BH6MIRe&?7$&o}&Zvw`m6KewK!_UD^*)PMXK3NLG z^o3;xx);0(-oJ%rRd+iuh67MLFf-@rr=UY1_W;0n2nQw+Ad`WfP86Q|z7#?D7=PW* zCq1@si3E#8jYLC8NXY(l=OTkfKk~+di`bcNj*qdvTVmdQkF`Ip-SlZ~2qF}kbz3hY zB4MS)E{mnt{)XQD_i!(81D5tJ$prEEKYDDe$amFGuKz8`1}uh{U-h3_%@up*9rbjms<2R)K4JxpbMMCO(s`ZG;zgcXKcAik&{IMZV zmQI#&tRc58EibxRp$5iL))AW&Pw%_X$$Bes^7o8*Y#z~(IV5*P`%*x5sy-ek9=k`x z@XCtFX6OUpUE38;^!69-JMIp9(y!}mJL3{7sIs9oyn9kFy1fm1v6-(Rzx|2DrT z`!Hhm2>L(gOnL7La=9Q@?HDmmOV$aoh|U_;m3jhcM4(|HxW+;Pdwo`tcYlR-^wcVsWhwmgova$c!#UDh^gIv~^9(CEM*>W9{#vJ=m}Rt}VBf0i;_IhxmVFJm+wZ zkCU4>M$K9lndWX#OPUYv3`2XHwUthSUMa8GEkW4tLLm>`7F^nZ=a+DE7p>E=TUq+ufs|_6U(^8=X5$to;!>Xfp5v!7(SlE8$u5FP0=ErW-nfI^oFos)Ft|L^togWlh!D`2BznU!G63N)TowCzBA{gAR+ zX2%S7mh^5G5ebYo7MDHt+2?`Q^K&G|tBb96qDpxi&eLmM6!>K|iH=Y(aQGp_s%t$s_%cpTmlXRcgkJ^K_O4cN*PSearbqXIv16VmTgdH z?(4NKm_6*tc6Z_k!njP+SHAQ>0jt%8hdiOX*LW?9X)kVH;gzkq=U!tTi znUPq*{MyjVdyft35zRX-#6?59f)8m6HKdrCRY(c(M}DLWm(zddR7P70oQzmhocEho zE??EiP#;S8$a@;N01D^wx&4Ysnt-iaY;JlaH=@b?4IL>9Qifj!q|bx+(bclr-y^K% zWeQhuAf$Jr&I*mtRMBvsa%$r5ug|T;ex0Iv3AAW`rQ1K0jcp|9q-!0%G#@^6kw%}Z zoTBs2r7rNa$8=BZyy^2LVD8gBpnL5g`*H~%3X%-4xVUpo*}H@(ey`26>Mtt8sDU#L~{4({Hd781M^FelyQSsUFF?O>g(my+Q_y{R1jInlNOmYC>3wRL`S0U3qy z%zwRGLDA`fVp6OECz#cho(3)Kt4YuWQuGa&RXca$(j{6J^fAv;pH+ z4f`px6b){wN+KyMJb5f>lbuGsN%*DMbF<@>ON^hc+3JrMq_}(i9?kj05e9Nbk(eB( zu8$tEP}d{KG@1U$g~vhVs$$>MNq2uNb08?!nXQiN>7A=L$A>=CBMrr@=Y6aZi+p}h zpZ350j4-5Q_l2zK@iBDv32Gmi(+s4h4t(Q+?=4stEPf=Ykd7WLmud7qCWr~Abi6H~ z0oNVefk!V_&%^NsaNnC+XFPt8_>`i*iior#JO1hWnmogINsF~21?KaT**)D>J{*qXfpxC^E#`=6BO&Z4N`)48~*oqZIBfwO$B@`b9# zm+(`z(0;7VpROQ;sA5>Q1`yyRK2LBr1^%%~GIirSq_TV8Kn|<)CzB}|g4qUK(O3bC z=f6;i7!adJ7r^+UEdp~ZroI@E)I@iLI zI9%BiEoRYo8GQ~Z5igE5|J*b%=e{a8YS06ySBDaI7mJtdW@0bKx8|}VzCRP^wTpn2 z@Y@0;4-csz?z5k-=>)j6bI@p}-2dS;F*_l!1_p$UX9ZILJb4Sz=nCJ@{Q+SP_yJ(a zVf6et+6-cyH|n~{@mQMp`uvTa=7{Uc4Ny9yCgXty@ao8iMC^o zj0Fip5kuMFA*W4Bc#xa%6O1=u89s7V8cJ0pm;=l_Fn;5c){51VLw~b!bU?z|@{7cZ z+}zGft0l}F-TmLAqUG*K>1;B$3&!iU=UXY(q3%lf#E%Vn5|88G0#DU9kHw^Dk~q|Y zkcn7gq3H?nCY4yDYXdByw0z2S-le&l@&g@1tKIrYz9ILb-6B9G^`!qMUisVoL%F(X z;GB_|&>_7~T}YAJbg(uTS$swIq5_?z#eGBbwC-|^UZ+!i5ET&%nB7=6RwZwJ7nq(X z3dl(lB_?Dw@wK>Oto>NqFDlp6?-!2QTkFG#{5tR1BBun*rKj%9s9GbnUpGNDwg zK3Y1)hfk&7gowfe-gur_(wBTa+|=&2x3@vV8`9wT&N787(?toWiTL96(mhp8APUSN?&F(-%kU zhe5;mlOA9Fm*{eNZ0MD z_m1(YfVM+mK%3jY{_MOw%e4zH|7%sxpbP300+f7?$b+G{bDL1fJsf!Gl5g|m$I0HtHpHOi*P6rHW#eA zqX$JR>SfWxv{YU(S~ec58&J&x!?)ZuZajGkzv0|v3AGz9)r=6uu|F9U#VNtkaM-QM zomMNqZ$CzuqTWumYv%v#>~sDp_O8i|&tBX3+a}byLJ9#5_G8$rGW%XpOj{=2?4F9R z!^@E06HfN*sdj7L2C|Gp6E5~e-8x+olh!m|0WGcbS@S{VQxV;Md75vZ{t@*gI1)R* zk0H%Pe|8sgm!iH+qIR@(&%?Q5SVF;;8^)TsxNfDeYk28FMnhzjv{TEXZ;BG-wo0Pe zy_anE#(jUzx?y;N_|{Ho&zoS^o3V77{mWR1W^X3y>(WHndYjN?wa5C%Ug<=Hjgk)K zbP@K!Ot{#E|J6;Me%OmkFKkOaH4m18n0sq>Z{P`Qy9S%}6bK=KamU;cwYPX@A!_ZG z_>P7uC6LL51yf;!C-)Y()f zc4q>wFASUKLgOPmImfKM2HVxegVs`~{?RlOlT*R3Dsz^CvWkd8DK&bJ3MX2sj<4BD zP{g?BLjEU?-Um76y3X~C&RI|xH1oUO-+4)#)vsrMj*SPAHjVvArE0aL;<_L8q`#$A+47m@Qs&4QpqUO>HvmNBnudpnKmrB$6%#!^2aZMB`7kbq&) zLKlHZ)8tbp_dlbDIj!qDoCuDe>t;fcNYolYqL~LI@=#r`;qzk3| zBr`b?umfBBNGu_%B;T?ASDMY$FP^ulf-^)-d09Mx2*PeGHUeF_krIWc^Cb##u&s*!xkiPG~_LGDSV}T-8!|( zxqouUgyoM-05gqMKQ`2|VYF(mfMFTsB`7^$Q})w16-XCQW?94wI+7sD7jR&t z-dKH#h}vWSAjSJbv|3HTAt|CWSxswM&3M@cS8fQ(b3IAk@gpxQhDb+gc}`oq)4x$6 zrv%Sw#sT^=FS;+qk?3ZlvNGwRz3SKJO-sAkY{efRoDYchw`_KrW-^ON?x?Nd)$f5-o13}eXV)#vCwN~gPVkK>MF8$GE@lfG${ z*{%wk@H(GJIaG~=S90N+y0O6xgYt(WTw`RE;F`VP$NfW%Zf>-9QhS{m=JkqVUGPJl zoSb%C#uC)m4sp$&6dqroP;=~3gST6PX+hJ&y3^Tk`r23_{-J%b_# zZO41l4pWR9M;uZ*DL;J7)_sTt%~r-YsBhY@-Sm!pp{XuPt^LegU0rzhTb#nk3^eGQ z2{}_>)MC;hTi9(Y!qDUgXMW9t%xn=RPZ?D)F{8LwWpH@hY^K<13?@GjWxrZPJDGk6 zr7vj}b~aATDz*C`r}ij2TuN1P2|R4@QhwsX(nJ6xe#Zb zHO`Ok()SIxUDbb}jL(O!5XjCiT0p{V7p8Y4dgAFh|I{^3$zrI@*)$($l-R~;Y;5lG z_Kj!$sbtcL-)a~gh_c{nRSDCh3W(jte!@EMNv77W+nsUE3hLALl7{nAQwz#crDDfV z_dtZIGd9W+b+f7K`xz99os%UV)I9qYn z>(_%wBfhciop8bY02R95^>Ql?jtdOOHXBO~uT%luHiqZ8NdWuY>b?+QnJ z475Nf6^<%$lgK6D=9WNftL1E*=!=HFAa0ZYAyYt6(;Iht8?3dbK*kw0W&>9UVxz;= zZz`a9!Sj{7sjXDE*lNCngPpuAT1HXO;Jl9;E+=-yQDhKYoqeB3lCt1kGs<>P^Ji29 zhuINdZvd3s+YH%PIFQ%Dx${6FE*pC+RX7YD!$|dZhWwE{*T@A|(hJfm4F_PK;RDlj zm8Op(Mwn_+@wIh?_w6ZfSQwQWR?33Yd>ZX0YtdwCOv^=QUXh#@qNa+BD!Q9k^CmjE zG9lZVvCnxKrOzVGwa$Mlkr1jkcN&ERE8p|=W`mEkBNSgZ5ieI0UTEy^fBByL$8&AP zF~!o$qnpK1UWql#R0(HnKcZ@pJ$NNk2^A4vt|cX0F6*+R+oox2mvbOHf8cs{&2{Y% zF3rVLbbiW=q%vi zFiNd?r|oh_rfi85L?M2-*;#pHNT-UrHLf~T%_1-x>Lxbu-E|=d&c+rb3@L?wi=go> zBo|K-5cl;l;dxWl*7ElUBI>-gecRK5`FCi_f}4fvZ9&fGcP*$F`t5v2`?3SXuu1k| zVyfoMfHI^z{J`^BVCoUQc6xUHZQ;|4+kSx3?S>n5TaXT3tcEKd{f~$w`r*kghDhHsDm$BMPjmT5G$?^C74ha7A zX|2&{03I3f;=oc+!0?~#=-)!r)B|quHgSVPuN##eJOim}Qh4we1PzbBbbuq0ay7)(c7-tH3Q$Yl(b!UpPy)tF>%gvnA&D>e#=8w8_<-{)`ksj4|w+|EF}p~ zZAwDmd4d@y^^y7wlp-d=CVlIMq9QuTm}w|l$N0g)n_T6j-t(*JCj`E(r*yhXjZrup z0XqZ!2>!6JFm%{K*mUiimbgQP0qSzCqlQxFh>h1pty>2=HdDyDp;k)U=PiNWJ`_?& zuz7sZOz9k+zfJTH84olr{B1(W`zr#QN|I1%&Nbi>k>Sm1b4BcV$IFz>RG?d#x1;sG z+BA726ddb|J{#C1)O#3|{8KVM4hIImI(Ux#EK73pvyB2L2jTjD4_(~yaK*XxN2Sy4 z!%A(QxigF>KwB$=aa>Xxst27mC*k=^XabGL*%B*_ zn(};u61g)4>-DZu9G7#ZQL;4GkmBK?vP!LzJyGScaZI*29G;?=$Ki2oCb20>Q}Mi- z>3Mo^_XE*N9L@Sg}0f?g2*ZG-MRe*`8(Ks$u;(( zGik+?^PIlI%@|?ZS5FVxze=387tHsjG-O+|gvt{eD0$@W3_qM!w6}@(y4Hb*KjC0j zDt6tLDV!8e8!(Kder}d5UHVAC&{apvXE{bB*7lW&LrgkY2|V9c#Z8~atg!=*5 z6BHUp^N3x^YSste9|RqI*kCtbm)i&l7#93TsP`;i?dW=>$zDOrMUgz>%1z!Ob_uuX z8+EPVsmX?ag^mC=)O~MJT3@RXT$S!AIu+5rE^k+u(0N@X1V~UCz2(w!CQOUTI=)sO zSI08aa}pT}XXw0KtG+}i9`?d+pHd)l1&n_JYeK^%pid3gENgn*^v8Ie%hJqM1NU!% zj1K!=GU*{qyG)&t=mcbRvZU-^Z?>a5QpE`!MQhv!#(iCa7K%rn+kQ98+@2YNr`u+c z*-5JNci*-iPnaM4{UtOF@$C%1>r7c*bo4!kufRcTkE;DU+u2k=9In|7(p`ENiA`wnA#pm%m}JDJs|H`T@QBe)f5MDJ6lhi)`=?+2=AV-b zOTMOOi&!BIhZdp%l56-O`nACE@l!zM9^KBP^bx3Vu_vy0ui0(V?6hoR&!!Wzyba^-Cpw9ZO-e@+g)MgPuyn$IFq@D}jsXG#x?Pk}x>Z7Ve(h5Aw@a|#02!p@z=+lzxnYV zuXB#|)gPJmDdA`^w6?Z7(@nMoOd8H@S_!E5{l4&h)8JoG^&k~Z_7%s!ZAtNsP?dglll?ZBC&^H4V!r%@Powr6qt zaI1SVu{g?hMR`~{=BxFvfTw^?+EVmn3f3L{-;pnjwCAEJKivLan zT#?G3TwDS=vN@S=F4zUI6ws5uGm@W`rySMrlL=uBoK zV4UJ?wyjBDnGg>+1;!35l?g?TPQzbde3M3Cep10V5b+LVJ6mIlBNSWLVwj!w=l)I^ z{8-EK131c4*C%TW%!-}>y|q;LNyM+#VJBz2BUhvW$6;aNpG`Z2naLL8=l#}C4l%(K z7V>YZ#$tVMO7!P&`n}u=e!o5)Hlh38c={w?PU`pCTdg6^v9z(Q>WQ*(-V~=o3*fD3 z@&l*u9W$Yc>_L(TvDw%RA|)K8&)sjd_O>qOo#!JmyX|a=QYQlTcb;m{+n3%PZDdvq z6x}wQB~gEz7v=I~mUka5_{GVq<4!c>gHaCNkex$OLQ%oGyMY%M{k568?fdP^hWHxE z%lsTImhIxao+Era$jB&aa3jTkzL}$aOI%ciPio&Cc~?y6VP1N(ZF;ob6y zArcZW&k=}^Rn2%OU&M`(gcG*KAE#?}CPR0xUXNF4u@coq>)p9mj*&-5TCO_8rZZDG z&3^kbRTaQyc+=@NTXGnB6 zy9Bkp_UST8QM<57o-BsYOW&d zc#c!%ro)rp+AcVof6Rt&dZSdFnOee>EBsn7!#+FyNUZ3ZMJ-2J>~waC4QA%|E$j>Rbfq zr9FCE-mya3RM|5Q{i=?LRS(=cU(CU#H7OJx`o`$cE zd;}uarf`y^e7o7Vt2L22R|C9=KcA{QHyLjw1T)QWq;yNg!3zGuV2&`2C@HwOuJwdN zOYG89?51zX9C2LkD(FAvy#?p`rCl{KtRR`!n4nENqp$3cuhURhIMf?+7LJ5^e zBe~{3p_+R`ELd7}OMZ=F9^zpkx+XlTMGVWG7H5&Z)CrzRoo{%K_OEpuT@P#8yf+40 z=Y#v$+(~#Px?%zbJ>Rl(4&(@EIL)-BsIWJgtDj%?3V$<7Yq06kAiY; z$ze~@D%cu0>eqvB^itw4&VpH?B;gYNrpT8Vb~D%=AF^Y|E>7yLij%k0YR#P-+UmG zhDg&Ofmdf`U{67G8;P>)B`CQ z3py_YTbLygj7Ruo1Q;G@zcN-`10DqOv-c##RNtmZ{QFc(X&pHDQRW5bAM4}telf=( zfCSTwY;J9}{d0Cov1#)grYGQ)<^mmu%57G%lVU-#`N{_OXj@jWc75BRjTX~b4Zi&U zB8L7mQ@BW(%`qUKi0!FwCn^wTEs3?e?^gul|d@ zHdIic!J3wSS5u^3yW>n)_wjw4p-C*OU^33?Pu~FG6p3@q5cN`MEvp=1xY4rv;m0!Sml7 zIzS}sEAOJqkZtJrtp0YOWxkZ%Ud{@%wDf_FVM-JH}Z&&%g6L#{|MiFG`%Yf001C zy*zF%8zVgC!W1h?&sk={42Ip@@Ac?KDUguV4p6iS5#ZPEaDO+FhX}hA=(bRmUDLb0 zZBOjh8Zl||BfG%xzp@UK=W3DhEEojX`BBwjH16|J6!p z*m9q$>Z;?}Zy_+GYG_k=V-ZFU)G{QvGYu?HVS}ES480&GR}=kGAVHql$NGtQn2_LH zEnDEFd^&|dE!SruGy3pNXEp(A=(#hc%Bm=^e;>`&xTX^ric~aqnY8PICec)*O;`v- zY7>YtwRX`+i>TiuE(A;+5IZY543*7Fpo!4J3(4*Q)8x=rz=Fxi{t${F?k|-z0ehD+ z7J3#T$NQzS4#wHd7SrL2KhBqTrqKRm%dG9MI}*cyr0%OXK@zT@ z0(w=G{BZLTzVSsP9-g7C@Bf|fV1<1Zoa1VwV=|q7SM+x#+Z^lvdRBJF1U>o?25l@T zoO%3G>oHhr!G?^sIqRNT3zB2cG=PkOL4p*qgi@v_i{cv6RrU_i?pUKo4&o_|kQt4_ z;RY8a;6JHW5;#H-58dgX1fi7pyfjr3jaOdiX@Jmt$cA-(z$xS7V#B$_iHk@9orT26 zB4n0Gz>Wm@ z$4d%H3P+GQ&DuocX(EG#oVODf&&2NR@Pl7xE8-azwSYZ>7*^aU{eKE;=mTYVFQe|m zy?(G&LlA_ZP^r3e0E4i(JZ{K;^(!D`<_C9-9?_Nv3J&Cx6x7HJ`GKMkdGNsGVUy1Y zb_uaZK!;GL&qYiO7AJTj2n|K|5n>gc4TJ;&p#~EMKBRiV#tZ&F@%_I(hG|}o=LmK9 ze|<|J0pBQHijQ|T5biKp1#+`Q3f`3MOA7xKHSDGCEsd6jrTERQnqu+8P9}71?o76f z0_jMt>=DA0wCT(5VkZr>ZPbs@ElH=BCP6A2o|<|Z&kzqgdpmeE}$*0bf4ZV3S+y2v0Xl2|@Eg6Km( p=K^*z`t$$0xBow5RS>#(3&|iVWoWjS^Z~U&l;qXqDrC$<{};xwv2p+a literal 114535 zcmX7v1yI~<7lkRsp+NCcw8e`ScXlaGVR5(O6nCfSBE{X^-QC^Y-4}PafBXG2o1ICr znPlF)o1Al=dxJnSVjoZlQD9(TK1hiFkcWYJPX}GHkq}^D-hH*{06=%Vvy&GC!jz2> z9Y9y$i~&EP8!N+6pY`CO>&VvPYIZO%_#gi*?}n(Z1Yuy_awUEM6rHt?UocXLlw$9~ zWuqh#g#P%!Az@Mq^}s}qz|ak2r~1K*a5DSC22e1{EtVGu8GSkJGyK(+E+(W35c)d( z9vdL?I(BaC-(S&(dpBI>P0cjucl?@_oIc!bR4ox`IY)gY3ORdNY0BTfJ<*s|npIkz zUEP0iO)b=@w_GhcC~}iYeX18Ju(~}_o2?9}bFoq>U@vth%Y!&)D!Vtk?frQHk%coQ zI+V+NQA}((@=gGnF16$Um2CLYH0a z**^-g()`wq;EqiX4I{mov7;UuuyYUvLcAF&ly{Xg-Cj0(c@`KndwmV&SdZkBFrGDRB9$@l@*?dys zD0XoVW$U5uxOV4l?M~OZ3-qQSBokLm>Wc%zCzkwPm!=j{W@fk}CqZ==E zCca)neQctWezS(W>^_@njEH61-u(nRffQ&YRy_ok1#8l4!idA8^aM+kV!_3~|Q}W37(}CwXi1TpC9&1M3Zq3%Cst^Aut~mZRnlDO%vP zz0YzghJ70Vu=mGE^V1Bh6z=ou_ZWwL5$wa`c}zURZ- zAC=#6;YpxWPJ&(qh(}4D=pxY&PcY(1&=D9^miuNzQkV-i)wr&xuzN-d|GI%)>*DicK3N|KB$K+t!CX`X2iq*G6q zfPwJrq>k%G%SSN!eg3`Pq-j^wYFUqgQ`uanfy7xSGh;gC;aeBR-uMlN-Hh=Cbr|o? zj>=!e>4oE0$tUC660>!r&e!Dm^aG8ZL7UMt?b%4**;iRm`RGin|+96ATQ zpYOwuuK4+6qYm(^Wvz-)_;XHh`RKhDr{`Y-(DS-38;>j}G0Y~MRg-U&b?*Vkr@y@j z=|X2Uk|GFONS1LV<&8q!2}q`ve{7K6Cfy>A$vxT4zwkj2`-L|Vzy8p@E4l^ioquqV zCYAJ^N%D=~soNo^TWQ~2$J?)a#yvCshEP4qnal+8AMOnOWDk2@loo`MWA8bkor~3+<__;`%P9Uir+u zZvKhrZGkm{SWLk^Nek%cM97w`@+gS0qZOEn&;m@~eLv0 z%7!$=-K*TV2*O(F$n-yLtp8^3sB1*Sv&QX}^S^XUj+q?x9 z-!?s?D%zdS`2JG?VIO%4 ziXaXX6qVd})5eOSt@1P?rmR5@Jr$f-X5T zNkt>f9U`3!U-qnwx{M*RYu$jRG$k8>h)$;84c%3CH*T#=HDXMuKfH`DeJge|gu^%5 zV8!vTd-DsfJ7*}bT{I_KZl1GGPLDu3zl}^y-OLAN_yR?K>ok7U2nNn8+*s2bzcgHf z@b0XF4r|3MpVTIJnIBnVxEp>@iboK>cSc&hdpn-1>&`0z_k1@RS*ULTW0l=y&n~GR z>c$l!e&tOv0pDLXc$&MD`1+Vtw@qO6crsrf{9cZby4Ry8T(IAM&{22dJo7Tyy*ryS z9r{&RZCdo9*PVcf@!EdUf?m^mQG6o&`RD9p^L2IopY6^VcM;<6Hwp6(dO~Y&gY0>d zpKo+vD@dfj*iEvrJt8Kr^Em!}+#HB@TB7&Fq+usAnv{T@oZkdPJlLFZqu0Q2@qaVd zSCnYTLzU%WBty`@9BY^zV__>cX=1?NQjc_3K7Mz@pn^@Ezs{dkqewpY%`E?3>+E~x zdm#{nO83`r^Fy~&0ixYL>^kBh+2!|MB@-0cI0~!#QKge_4iyC5vX!K0IZtyp*||mq z#XX{GxA1U}{453K;65wCI*>8ll($qWd?DLYr%+z{rP!MgSk%jUTaSlCI%z{4(|)t7 zPSd#mIzwJT4iQDGxTNUp?%Lt_8y~@Tf9-;?K+LBTRPC7yN_`G3_Bq1Wcf-mik992U zT!-EXxuUT|Z{RGNg}AslAbdeyfu!K(luwHu>LiNUFCAaw9wBf)ML8)k9eWu;|d4@?%_d@p=v0EC^JY-r2Og^$hc#k^ba#l_3+>YP+S}nx|5XfAHGYRMt0qGE)hK z=WqPd8eS;D>>IVl;O^ny`Rskri8C9@|2i}VjP`qA2J+)Xe^9}BU{{nUtQU64;Vk?6 zxJA19+)3)?vM+02A#{wWKjCsBl#+ScK%!H9Yo|*E1agQ3dRrX~4hY-S)$+NSraGXM z{Q0t)>J7${Tn%{k`5K{8*VdDTbrC{svv-HSlI6Sksf{KiL^MaNmPG#7d}Z4Pq3`#@ zVmlWv-j_d5*OnqPO^S0ExJx+KCtuzmoA9lTC-;-HanHF4>GeKYlY&9m>f?D$Y>&b$ z$Zzn}Gk%+vv(k(PAMFUFj7+F*l)`X$B>IF&f|D~(3FlOYg$KzlL4E;$cu(^KVqzd@ zPV0-`S7OCyqmxJ6ZIH4D{@edOkPiod2}k~+rwz%63@P?2HjY71y2ot{?`_E;5__h1 zgaE-+L%?p&S1PvWM-4TjlVP11`3U!Ce}xBnL_G>7+|{-$rmG<3~(()fARJ4F&u@j|rZ-?Fm37 zwlh^7N!{>cq%c34_+5}r%lt4U`7s!Vg>>vHorn9He*FgRt%H=yaq@1=t3RLAx{yh7 z&mE+VJ}3`TL#nS0TOHT?+V+kbi=g+}`=1lYYaIV>`W(Yqk-Gyr@CRq#MT5QEJqa*b zW%@bkR4y<^eB^-_l)1kakC!c*&FA9V_4-`Ya)g_2U^Fpu$*Cn-y>tVMb3oq(Yis2U zqwuWU8@ENT$XlNM6|7kA$aze^%H;&;N{x`N#@rEmY;HTI#ET4_hliWtU+Gm4{kRpS zwm>Q&T_|TOaDL(%D@Q5S?E$b!mYCk&)xwNh6Qc_+wT5I-_qAgW!!qQkVJK6yrU`ogW2mM+3kUta3Q*(nG?>RI zcV`!Caa)Wwvw7>6fjB|+zx|YJ*12$UdOKtDCRVDLg$;Ca@r3a=lr3o6BF@7FZxZd?lUwDXM$*th0CbjtD{hyOA26+47L8Oak;67n*YeJ-xHz87V1YdpZ z1eV#?$l;&^@u>q5DJ{b^!F#?ydKSl#h4*_HBqC)=c4wnJ$>zecnauNitrxuZ%+v0A zmT#eDq^&8C>7(#BbJGXPy6ZmzrC+L~nvcMD(JT!5Yg7A)=T!=rCdhct2(=n^QJK7* zqcjk2sA#$ol9&yWvR@*rs=kdU-4iZCL?;$JahUJ^GqGv#h%lez>PGW-T==5rEbsagfB5_d;LDkdaExr4uVolmm z)GNcfM$~c?7*b&VPlV*Z^&hh4Uxb%u>kCt6Ou&lg?z<8zZvL|ahg#7U#KebJ!?bkU z{b3JoN+@U=QF34SBfcTj*Tcsm(6PMb`TF=WXTzmUE>F;pg|_7QGK4&dX>TCQ zcqlKjlZJw&HU$-1c@-%)`hJ3g*98bo@NSQX;Z;^)U%p{bX(tGx}P2rTavl)G1~O~|Yl*#J|~@|93FM&9rwu%tCr zOdfikPHIp)GjGrB?=zjQ+lGV_$R4ipU|-27Z*6*O790tXh)4 zRPy&=WyHQOM^?KPh3bBMNQOkzTSn@l(Q~LUee|szjN^KtkAUwXL7R+PXYXHrfRLk zh%bfe6s1fpyXq91JgpyIx*cwB(@T9rM-kg<>bB}>H^59?)Tw7TgLezLz9ROwXbrOj zl6@0a0x6!zn<5hdOph5$=uq)p*S(r6LTn?fCE`);L*sfC(EReK_wXoiAE`lABf>Fs z*z%pe%}PoayZWY<>JPJE3C4W^=&#qFAl;+h0d^~S{&2AWwl~e!mL|K3QAnvg1)UO0 z`F41sN{VCnQXGLSJHG}JhSN(ix*KQj^7q4#whB7+M3a#b?lIENeQ^CIn+ToFGpbiX z!4*+#0-@`hGv@upPq$wJIC!MLyjmel>@yQZ9@*5pmyNz9KrY7fP5SiavH?VOzKUHQ zI)*9BkMS2r>xzP0PMld&ax-^#E4%BjRD~Jrr0NeI@lINookFIl`zpHGIH}(r@eg%B zbf_fIeXQ{>@{#zF> z5hw0YqULRZOaaKm*Ob^0Dp3jAI)0jWnkb6HU(~UcLbecU!zBk?zn0*K19;yF zI={0eSazuJLw(!FXg3ldP=Hu((3jsBLRev5bcc=@-Lc{cpJ2-nyRxFWBEef7L<9QW zf(a-2_Y)_sWSFE@I&zR-OZ4~bH(UMw6Yn34CWKk|PdT5)KuU!6YpHZyot+AK?VGMN z*ysZG*8+d%#wEW|ddpH{V4s>pvIL|G85t6;xTH;K<@9lO%P>8v-1Pn&0{J|TL2WXt zkp|1}1ruyH^xV(w*6-`q9ORwJUQ5#r4_X{`!_a-cNle_iBrSc0U$wJgXmdK1N?kaU zX9%W4xp*J-qtJ}$iB^;Ly6WN9r|`FP2Q3wy5N*Z28VfRrJyPO3Q|A^`o@>1{$hK5n z)tfzCjy+Yva|L+FbQd@?d1S5%7-p2+lVl7r*W&nk%P)4NRU+xi;1Q#ZMl-!NKYnK= zg%!l{d+#h~wVE>{TS|Mr_BsjHJ&Ol8^M0@XTe6Q3+;lUC z{K?_0Q|UaHisA>*0=UTV31DB=(5^1ZiIYBEmiOEn-vBsf|xfa#JHopB~2vy52Y77kzn*P!1@2G!IC z!I@>>cHJ~E;Q$2*nWq*!6b1pCmh0YpP`Q1BsGJ^+i~!dOknOKTv=V(+=^v(Kn8*Ma z_&((7_fazW5mOE@fOQp~G}AP#M9_tl$}~F&v^zgJO?+Pl#1x_VOv?sn zM1sdqM+ak&r@d|p6;2yseH@z6f0*d>%4)aXvOy!_jp2Ud(iXRel}`4$33B&TMFHE| zU`0(`vY2qYRMpHvQ#)L&_zWSrM{!irnc#j+c(NigQYK!2Nn@`PO&3aPx@o#|Q!&gB z+#xX{ugyQjFg>vtB+ZcK7-Ny)r<|@i+_Q(GV$1~K;7tB!BKIc(xPB!gAghmBNh*_v zyw7jv_#v46H2VdqGT052r@@cd8g~UFetCK;3l~pXOioF*hcPaKSyF<>tAJ1f-n?A~ z74koP_KV2BX(i;mxn0zknMOSZO7TaWCx(BT*vq85o>rH|b6aqqMnr#QaEYUmLEWMw z@H8dYRt9Eoxd#2rq3&c@)VJ(HpWVa1sOVV9{btM?u3+dW^_ z_)pD_+uw7hd#yNW`FB9U#aqvT!kpLjD)?>2fhZPH+Y(5;^(5aM2A>Pwa9)sQlT`4M zw)|W_&j^z@Eh}+pQL0~QFGRv_Y{U~6-tu(5!S3%j!cuF|C-~6PGvuVj@l?0WRhA-* zQLNveYOmTa8yQagCN|CFi8Ehr{7m$K1t#61V|#nfowgDc1>QD3YZbR!w)bH2#CWYw z;tPZ^<73{_+vTU-{Y@OhOX2+IOh&k-=k*eqEwj`e%0F7;5va_5hf6mqa~{e!@s=f5 zkgn6wMG{CoZm=C|S!WS!M>w!~AKH^4`;LZIJkYN9NPj#MX)$X@AxP&JE1&)p?dQ>L z#)po|kTyhAzw6rvBOcbY9P-3HI+&HIw@ZAP)(;wCoZWe3X+H)K+L$W83H)8yN6_3R zkLokp#+P|XDu!9G0r*_gv1Z0`>HOk4XKe4fk=Uaq7nqgTVPs)VVc*`+X+QzsbVeAb zrh*LB`(^G^k0?0=Yd7>k@;BVLGhtg!D@xdP_P0NsHXcXCDSmHZNf%{a6(PB14ar}` zxishQ>ez!OQXF=~(ra{nArZ^Rbr>pjp^S+Ll+o=TAf{iVI=ufW-3yP91wE)b14Pa( zj2P18sAtA;jK3gDV@h&DZj>C%V7)Wy(;FHVKl*sdIbx65v;7E^8g^897f2T~uB7b< zM4_+I(Zy4J$D_TYlaZ0|l(&$s$;DX!+T^knA~4MS?_ZW*l*&AK$kxqy?bsgACE3DI zLAE7=Cop9`XFQdjS?DUGMb0dz4%X9es_`J||fl6YIQc zqN&eR_6JHx14E1>c@SpLrCpfkloFDUpA5D_Dqp6Kxp>O8=ZDzCLm(Gb80izQN~SLN zZN-HZsOqX^rZZyhEf^hzoZD;*Ia!OzMl+K>qyz&6nLauZ!6%8s;XTkG*leicOa%X2 zYY8@8Ts=>}cpDZKe`?b%Sg`({PdDJ;9z$I5!>2B~Dy)DeDr3{1GBt(^Og30POH3;7 z^Z?7DZSdq&^9L4c=fLUVkTTXAaB+oVJIqhJ)}C3+CP$+f5n*2-kgl*zrJ)8D;TGIf z#Qk-!Dw?|et-lPP+amL~6hMLy2PJS#DdEX6K}5_j8OjbUZW4P%u zg6giUdfk2z>TCC5B^phii-*S+nhvvjH6+!~0tm%jbNk~r%19DHvmfcG3V1)_5na~u zaOKJ8VhD8mCDa^R{Di^~8(;J|C^k98iaMeAERJwttHtZII$JY3)$(4>7?uAI<=Gd! z7|YfVQZFMI%3{|C79XMBEWOWhyeN#X3+l`CUH*3Y?r!VesVoU*`=YeR>+DX>zam_^ zTs^Yx>*@3=xb_tPKo;^pl+^0DWCZ9aleZ%j(e{b^Vn8ElYj~8p;p9oCY##} zxYssksWGP}sBu8)6DJcIDZ_DqY4#f$Y%*WTBYb;&=km%818mvXJ$f%SwA224ZxQQBD zEn($9L{m$Fj2}h$Ql9$ZNLM`&>XKCO@4{PjH9~vuEVwajxazp-chwz8)INKt7W_#{ z+`nLINyYdIbsM!FP^}&)AFUXcW90bvxl!b89Dx|Eck7kmh952aUE%QA;y*vQwabc% zH{5XZ@W7M!6Uz>Md}3J+sEV}`kB*1qzs3No>{kMe8UlzX09q}$Ai4B(AZU*7xbjwe z-4c)*Crou)!(am#(p+ zW9Pxy-Ht3^?0kko3|taV_XfeLaf3+s!sE2SGoFY2(6-&%o2m75mo8V>4^*hCl zHAVf|F1w@>ls?0w(a?obDLo}2=}$|%JOmSre8TOGzu8XK#O%#kgx%^P5ukVV5DQj$ zMX3RQ>JALL;oZB|I;2`f*Lo05<*ZzA6?~o^!D-noXZ{1N(JdEyY2a!(%~1D%VzU%3 z4X@Sp{f$*=C+bNR8e`m!=uqBv*FaWw^54udQB{m864JD@6*GZ^;J&ZYCvl8ix2Tr& zZb)*U4i6_Y*(830Ks)FGsl$lIV`qb_H5t_P`hYVbfu@}~r(5)%2d^x90*04%=r};V zdy*r~k4H2o{%m0z@7peFyt+K2opHu1g}Vkyp#wT~ie^A8Vh)CUl0p}QHd zTehxhsPrtO$Q})Jw3@5*^R%L2`4&-=L>rZ@Got&V4)t@sd z31zc0pR{)~gi4y?{}`gyN;{=9ABI_h;!m8`V{MBWliE@h*4nHBJXEq!r!}zB2iz%f zJ>*Vnrv&(5U1H}i9BV*KjC?^*_T>I#_x+ElX1O5qM0tc0VZfW!;69!Jb}c)K|2_Fl z7szR_$5l=aPv6BWs#~r8&_cOF$LLthwR7;12%?$xP4!+J-f#JvE;q^vxxpu0JxvSp zy|~X9+%n=3)QoA_!fp19q>!}rWGT0h6C&B^9%-_|8NVyyo_f*c#2H(i z45pwkHG_pI7C$B6QZQ>QjB6!zI#WIXirv6Pz{oR}m0C4$7Rc0XVrdeeZ?fzfp34j6 zkw1Uy9@C$qj5O;T>QFa)&v7>VLe#>A!!T&xI9S`&uTkiO&NVBID6ZsSilF34uPkF+M;-JczE=>u=cd|Jfv zRW6Z#kK>HZIC=AQK1V3sW8Fap=)(v?m3l^L5TZww-WanM2q#_eW>R96+H+D#9LDI2 z8tZ1npj$&m#YRGW558T2@13b3ZdC8fSMOR+a#ZP}+2b7@4!wQJYCP%LsEf8rrL5o0 ziXT)B*>$emY@H5ue|8KTDZhu747^6Dftmz8m)~quv6Y0(UCwsB9x}eAO*ISTE~wo$ z%@Fwep@=_Ct%yU^E<;e7lV@T-dH|{Uy>(JM{J$ESozP@OEHEXhfd;6_5!YyFt_L~( zLBIw~_l>v4>~(q^0MIyj-iBu<#xfmUG*8-_HZ@lSNdhFSFR$3x`5nE?rz*cZo4Ky1 zU+~>{CQJ=~qX9L3fP&yc%JrMD7r6ySIetz1A8N-RaQ&bcfD2DC$Zrb74p~2~3!eujeQBP5+Uw|Fo;GN28!RVTqN8H+a&{7vpyR zFDXIkAAg%_YGxXL+4>mFghSO+T#fBR9Wc?%Au%dVJL5y~(~%o>1N>s^kY;V7r-L6? z!LT0PfVluGb=lwA=%$h0VxE4)m3n0R`c)qnZ~6}4Hh?HT!K}8z@e5-Ft4czBz1|Q7 zok(k@t#GNFY`Dt(wCP0-HS^#(J0iiq3-2mARHpR4{(Mj3ww6BkW#fEt$3xy_zu@Cv zQG8c-TUxnvo%<2G)D{_m)*|8k+V_V2MGFymZ&Y56i3QHBK;;4#m-z3`k?~yEzTp51&-oj>{bYEARW0k#tRpylENq?q zbv((CXJ2E*Pi+u-VtGFr8jgeq%0q7NiG7s~h!i}1scbSV;xHO9YERM3o+svVkR zD`k@i3=77 z>yU3$35{nIS5A-T*XidIDY%=%4Zad9VFRR*Opt99$qTtl#)18~7eKsUItKwXF*XJvXlx zYG=r6&)eFKwg&-|b9u0xDtd?B6<7A9$SXzP>x-oJqD#Ew4prnk)uCWTt4_LSbj)Sb z{ae9Z3A zU~54cz}E8YCG^fEy2D4wXCj5~rSiwV9-dFcQfVK64n-b_BC*XnLpgk?X3${my0Dgh5x#raxdnTGT5z3gMyn zhob*|BB<)!b@wQwWf(q$_-w%Z&eJz-V5hHP!p=qZ0m!}6GbQGw3XM&J%RF7UxK1By zT2>NQr5WwkmIs&!;H5hE_??vb=ne1Y%f3Vkh+!t7>>DdbY!IC(0!-Y$;A6&dwyoG? zj|pQE#<#)uKX)j>WFZ-TRTeREMsLu5EdV|Y5c&Z1uOgjDU$c&O!@r10o3Cb9WBW0q z9a?DFgg`ez%{&z}AVb=zgx2fK|0QO{v#`0THM?G5VX$h{exX{F93>S2%jEwK4d=QAV!BjERM4k-OcUFeJWm~dB6no3q~&1(&}^dGJz3e~;>2ZB zrBx(Gm0rsmC+rJ4TxylY3kHKYeksA>%RsY>9Lm9K^Xz6#CNITI_c)hDWS?JY#X>RI zJWS1!cQM&ZuY)(2Vv+wab}sb7olZaeUeqON^=sP?O0y%62Z2)FXOO%h!ZK4Ei$!GBmx}LuZ49Z@B##*O(k578CcKWxM=*MeWqLo{ zm&7_fwe&m~R$DcXI?y9?o2+!Ywel9Q+=gIeLZV==|0PwUN+2@v^6%J$u|kNRw=s4V zbQ*Lr0=sT;O}=OwHFRFLZC}$j&vlr1A3l2?s6y`1Vv{FKq-|R}7&B`g{?#5dhxLBk z$v-9gM$fB%h;f4dmVGAhoNq7AeW_Ozf?-Ci!MTm@cmCJ((^cHM6q=Onk7bs2gG4sZ zq0b9VQ)0OGt9Pel8hksh4?i>6Tm;ws{ipb{ZLtacd9|2WP>IK>m6*)|YlrAneSS9j zo@cHP5XL@yQcNBYel#?a-X%{~48sWK#RN-|x93o7jP4TI2SORRBlg zsp|vnnwq%JR%9aRj>x*T2de-6<)0e`L9Ak!d-oVb%@8*u9)&#_{OdZ-Avi0ZryTyn1qOfuZ;2~ zj+0GQ^N3gIzLFnB*q)G`@jiC-($nJCsm8}o}pp$#2#hwq^VTg z(x!^uopaLqD8$RbBYsVt56B`H{<2hI!T{u=gYVM;f6JF0xz=GpW&HjkcLI2aez#u* zuWMdlx9vg%%Vl^&QhO$ely982PUqTFZ&C5RFBK!=DECgg__nte85Cy6h856vtvqn2PuHW zGc<}T;IoOdvLne=!OIpnl{s9*D6xdQO?`dV>l;mLdcsSKw490+7M*t7XW+xifg!bG z;*q=dMpRelufF6i|Do9dlYjGcw3{5e@6@jKSX@b?+upS*R0~c z;*<`t%o0@p?pa8I8!;!b-T$A~bR?syN1zF5)Me%W)l^7o$`aa}Y?}GoTB`2A60J)^GI12zFSlS^F0fJu)Tj zGt@3wBr zBz;TOGLqnQbh>e>F&o0F6Z${aQ71F|Z|z60vEypsBJHvc56g%L4VK|^N!FH2(dZ~K z`_Q9I74VukGV<)6r$gVBG~aEWRp|-7=J>6fhhy?+eorH|+4GEm%k7nBY-rnv{5LrM zmz@-Fz{?#?CYD}&ZR=ZE(CX1VXGrfUMNoi<;IN-P1*|W^kNIIzk+^g_wz(52oLjMH zGQr(#o`s4O`};(%BiA4;kBW&8lp`DTNQPPowgc=dcUs`~JL)xJB&z8Dzs82l$UGkw zO~KWcJbMfCfY`aUc>p}|6W8D;9!*8$2{JChkP+v0wmPy@hCOCIu}7ky4Kmt(0Zh-# z1Bp#Ny>`%%p)Z?#NkPWB%b&2!46bntIL&JQstLWDtYjO{mufO`QlmUEB=;{4?|qX0 ztCNG?O@hp6RHljuBtr)H@kxK{glo*4Z=8pbQ_@r)VFOoc;X}%%Tu#;wfWQ%()(%gs zIVL?8)C7h=6(=${yGIu6`UVs~hI(!0ZGdDLVGJlC9Ry@HL3V2GvGJ?w4k^#kjK`~a zh5`gGS55eC97$~TBhWjSFs%M5d7JTKJ8gUD4|{7k3Rbr+sEi2lf~`)==vb_IZUgVo zpUS-e$VT#;sy}RbB`^j(9zir9E;9SIcHIyzl;Sqs8ipBb0A^W2W|_1{_|wgJ(GQyC zDo-?5%Hq$MU*y<^cS;H^+Orx&)-qw2Z|aa-GxN7|_u`2rq(VJ^v`yG3@k=lJ9OPTe zkunL{Xo5hwC0)3zE2-lkJ>=bp{zzMw>5HQoVx-7H!GCQud8O;-pDB-YH+u8%@Bh5` z#QRQ9Hx_jy>?;tJL{%|ra+xGc0|4&;0B-}BdDN7g3Cd@I#_tzzoZk--^Wtx1S_bIy zV50`Ue*Z*E@xyE`CuO4cvr%3Dh);ZSj-|31U8fSLNXMBGI>i6TfijMWzPC@NFN$0H zX$5NUxd>^FY?X?*~0O}yA`bu@xj0pMASpNJ-!3S_G zik4lnlPS4U!A5~n+_8@jEYLP>ZIok?mS)5*UzYz)Z9XJ5M|bR(N2{%Y&Y~f5%QH_w z22h@@($8h3jxUkQ4c=ek#_sQBdq=Z0O&WFQnE~fVIPV%R>f&}Qo{3={wp-uVr!3Mx zlA{(lEZBOIZs1gbYJ>U=<{*56odZMSAZ!Wd(vQ9`WT1wMD*HLFb^8q1ipW>HeZe#Q zbkiywP{(snDfq;;_1fmgK5Y&%Zp;T7%rYS0qs3c&?yl9fr3Z)<-hUB~ZI9wFh~(z_ zZH`G1gdpMG-=7TwxVF44Ecby0Dc~O2p%o*zsr6*7oGG3vNb5r4H3NXKlX8psuPDJ1 zIk3V9+cGeh`xNKgf08_vP>CGx$!RDsSwD1fg-@e$To=!bV<_mr_d1lT{Ip2EkcFyk zlqD1UN3Qb_j0$$0SE~aC4V*B}v)E}Q^uq)A62zgK{w24EW@WEcC2=x)O)6TPB%cZk z10xckY81IHZ44e(9C*w4UwBa+I83orrpqY{olVhUWw>KVzO~VyfXupqTg_z%+OEX( zu>L;~Q8y^>P=ZygTcA^6*2ec}7m+K^H>hfBq;nBEt|va-KzNg*!?6z%rjVNcO0Zfu z_86~|#5(|d@9|z2E(}ndPTQ}~kh}}FINP^S7=D+hc|*vR7a{w)vjoy>duZdPI9+OubY*TyEDVARJQQIwzW=#(m>L1Tj(Ap2MBE%qf-NVP)!&Pebiw!9 zACpfdB*1zzm8l__H{eO1(M6=8;?MuF*%V)jJWFgo-RFUz=F%zxCs4gw(F3~Z=~>aa zDSv-EuVTdjF)vhNxTgUPXF`$p@pW1|6hS7uIEuO`2fPS^K|ZjZjfZ4<0mB&ry;!14 z5{G}m*Bn>Se|-E)vLZq+DWWkC6d!=nC-k2AJ&IO+5|+CD!OY|LyE zk~Uv+&=%b`*5-H(-^KlF{Ry$tc$E~x&kWZpcJhz#d+Z^jexY>oPH2{<9%MULv9BO< zXpU>9BYV+!{TZYLswnpr(IY2>&&OqY8=K9Sp|k(Vl3V^FnObtVAmIP-;16w?+l@8> z6Ssv1XZv7XMwc?8w1Ga)=zeL|-I$gj9)$snImwZGe=Uc9@|T3ciMdqH-C`6#I2|uF zW{Qowcir19mVLmlj(|W$Fcm>Vo&I^j4XA^lJAEES7AQqn`f^i9nJ%YfoV&*HO`_FW zz&|HM;}JVklf0AVo~CY^5&qk!spIGQ7Bq*4vcGtUu8XsFmu?5#+9;B)Gc~i$|GJO5 z#gEoo_?;&L+@rb;IS(u@;oL1lb>8NZE|{Ll<##)w0lXwtJ|-4LG$A7VdnR1yBg3(i z1>Rpg9V<@in!_dS7@eqDf6b}Ur=5$_c0cM>XJn!oC|WR_^hqls7zI5?dXrnqDw@)7 z8$HCQG#?HkpyNE;NRsc)Xc#|#Q+H~EOOm}ovF0x(*B1rThTmE|Ve|Rgav0iQv<&Ur zC``viPKxO%`d$t9+e+a&(*Q{g{@BUmc$;Jp*^0n$7Gi&7k)5Rta%Bl|Cvl)){P??G zbAH>W#L1r!YnPnu@V(vKX{Xo*EOw(jnJ6!^mKd&l>v9zvr)}rI_8fN%9-dGCm=rOg zp^4R0s^Agq6_}m+wI&A;eLb@@}QaXzIO61!=)K=Gh>ZaAQ(%n8- zk9MY&sW18Iaa4=P?^>g!R2J}Q?J005WSadG0aY-|tR}$-&_`dBW(2&c0$RZ+@eG>r z3e{fd%1;cV%j;^>@Jv^)F!6V8894M8eW!;^Lqnzg2!scG)Pz)6O!-8y86R1E#XRcW z!>@*kZR8!}DRmT_K8=A=6{sO=PF@`BXtG+WqYliPc08Mi`-#d6Z-3T( z`k1BN-bdt#hrlyySRKV0Jc_HOYupYK!>L79UEwFQTj^a{panD+&w8xB%DJqs*aF@y zh;a?Ujoq>z`WrOupgC|q>0j(8q?fsJGz~fW*FVLO%kZ#L0Rl+{$)}uEBdHT1 z$Hb~N8JzW=|Hxd`^^W7n8F52yH79=mS+O}ZE(NGS;atw;S2^G{+XwHHkz|*wjEeVG zc!WI{o-=MVYRm;!S9db%6RhWd?|xwrL7UKItx^ytp_QiJa5KP-%&E()*0BNx@`+J_ zlQO_`_0PO2)OF60Ah?vC4=Rd07q;IHKaY?jY{>uyY@jMr%4vl(_b zx}R6)1y(eSt-PKCrU+1^1!{|Wv*V2%mq!1!tIZDA^YsfT&l&%rw^yJ>y-R6wqWi%^ zmk=0daM1DF4$3Q)@g8L|%VQT;;m+|Ix>|P2C>A)oeSD!B3vDhl{>Z_^xb^5uF~-Dv zlye&v%JUyLf=+CFu_W54k^zVxk#pux7G7$E&X+n6GiX7Y3qvJe6u>&8bz?bk{$4`@o!B0)P&YtPFw&gTa`ePj4su1tF} zYnzSrTQoNNQSdE&$I3s6GM(sF!ypSxe{~IPU)+}ijreTP(NIF+Uy5dq+_qiwn$f2> zMy|e$Z_r{A@5N##se<5cMga*}3T7t;GhdK@u~YO0PirYVfQcY177s6doIzDZAxJk1 z(RN|}XjOMXY?E2P|3aDj&5;tOFXR62*NH8w9>olnpwb^9lbVbRq%5t%L(dh`L@3dTD4Sj7+v^y z#y2Ay%VGTl2;eNh2w=rH1=6L%{9K^xTzYH-C|r)a+dQ2FGtb7z<5JIgfrv82MgHbO>iy`b5}k4#oa41#EHuqpv`^kK49TR`Z;SaFF17L}yBvJTK8 zbv9^HZ~L^{$8s|TC8xx!l9Mh2V)>h026!DP$Ty!bJz@+YXV$KIv(GAh=d(4aQkm!5 zO_;43d>6OTt8J@l%#+>FM^_a2dmCswVMOe04#J;O6#O{2z!hh%8C*lWyQ&WDi;|rGtoZdPBZ897OfQ_nbzDt%2q&t_KR@4Nl@eO$Quq5) z%W13cE{buc(YP+wd>L&qo~F1w!%RWcJb)aPLiwdRleOeZn@vJkTnZ}1>0Fl(Nwc~@ zs#`pNOHS!OiES-sg#o7?pT|@0YAEiOVx=B+iiiG3)LDl`)kSR|q=#;XM#7=H%K>Sm zq$Gxxl9KKkLKqqZ5ox4T>F#ck?(Xh-hv)mQ_vPZRxlZkK&faJ3z3%(BN|I0XUDQB` z86V)e;hkm;<%~Qj0tb3^e)B8*IC4ioL$R1_4)K=MT|eskgpPs3Sm|ZO%C>EYH{b(XvJad zfUi@}1NG31hev^*;3}gBN&nr8Y@yOqLsso9?MJ|kCdA3UM+ z?&^=}{u+Cc8=7^mGN20HTist~IOmR9qKBWGwuYn@;F@{3g5;uX_OQ7xf>Qkckpiwc z9lAEU2~ye5zNqD8!(j5d>6$AIq@o6wVgkY!0;|ea=QxQ-%GUTXUy)*I;uiBY`0JoN zHuMQ9lsqzWTt#YM^z$z?V}x`S)f|eRrj^mmhP>jbaeX*G6jG!)k`Z7E$~>29ec*U5 znj3;kR&s;i2h2vVO?@F2MDh?=a>(n@P7ht`)sCLc{(?y!-$y zqWd`Z7L0-t(q*H|=Ggbw3}RGg-$@mTDzF$Xb@Gy19+u*^e*oVP`;v$dPa=6HJjOA8 zjGq^KKD&qTS}w=DCn-@hTP-SF({}&e!-@soHJs+A#lC>y{6lUunub5M`9t`naWI_@ zO5WesirbN(lIXCLK}YPmCoqX{9(=PkoWKgkeMj}p^~J6gh!vvjUR0EeDBa4KO6D}Z z68Yd6G03k><3MVv5)6+@HM3lI@#oy~=CN$}uK}-%xi2d@Kliwu!DjU<#XZ|MM^k&5 zoA1mi8uyT%WpKRL?BoJbLbm^|_0y<<5)T$Fl+^@9mJIEtV9_E5;hj)7{l6`~Fe^66 zZogTu8W{eX=zvd)A|vkuxGeyR1O}5&ZNegCz$RTA+Qc5`jZu*1cqj|aUx4o8({v6mi*{~tHTT@CjcP4IDPGc<)r734jlF)MEpzWbo#_;?D&Hav1EF*Jt#_dwf!;Gjn z(3CV0IWA}-0KV(w_h$=PKot>(5}$SG-0< zeiywg^HfZH61;B}!Pak2Oo0*ub1^OVj$#`f!O^;EdY`wccs5T*9ac|7M<2#i)vSir z@kIFJ%JyWz?QecQH+Kp$3mt8w&8yU}rg>XOss2{)UH*YMAq7zEY0FQ-5eZz*4i?x6 z_T z9!H4wJ*^YYMZ?;SE-U`}b02(ZNF(#NpnD+BKP(;a*BKE>#nY3;j+hy@H1o@VKyN%H}veL=bD) zGm5Yf<>JL9$3GwGz=T7bxB>_DkC)n0RYa=bGKJCvPB z{R2E!nRMlO?J65>hOlz@2Vp8^seP+ukg2n&Q_f<5w5WSjdD9)uA0Qqg>0lY(=@_5| z!T%tqi50m!uOCUIP}p{W1^woeslOlRG<97PEt@;^2@*oeUVXWf(UDZ_eLxi@eqbPl z1n&m=gp>2!d+c1XzH)}ON0V7dmb z+9$UrD}r|onng79RS~Y7dnHN)0ACH&hWvT9K-+Cq~g0n_9ne^xx&E5g!TJy^vqr{8n1Sj51Og?=51Gk!n!j;FS zF(ob}i31X~@#c`kkZ2-l!xSmdX+1{K=SLJ$^%B56E{Llv=nTHtC+pT!Us0e+QGTrb ziOgBUJB`#uV=yO~Nn4lXVoP8zQ_Z%oWZI=jOU8}u>-)bQ$G2uhxUzM((oz5Nw* zegZrp4u&n^KuZ?%%1=!E{KuV(7M7JhXPf>;H~&wP0t&HxK23HfDSgf!@%G$)45=V- zjpgcWi(^s@HgW2ffl8P&!AFIRVdM=;{nGpypH+K@};&b76djfO7eV0%4Wpm_q< zm`wduX+rsjS@yP_8#5w;LFjXS?KQuNB<4?kA9htY&Z(@bTupf>gOhJ)JFdwyboMdn zYShC|@tz_*ST)*Dvsa>Hn*;*!nvHCkHsoyhSr*%)u2z6hILE?^Gjoq>0)aRHbR-9K zQ(k7Uu4;WEHAoowhQxr3jx`pL1(mni*F8|8_qecF!{V)eb=1vnUa%872M9JE2BV9l z_Jmr#ORe4a(Q~=l`s8|rlY8E&y;Ij|s)jgY({k}y=7v#lJzy}K%Po!dJ#zNcg1BoX zxtdPiDCFETTac^F`U-E0y|xF_MBxDu$F*C}D#^&l@9QJPe(67U13cG>BC}~nB#^u9 z{Fh5a%G#vf9@0>O6rMy|`7Xb-Q%Nb|Ogdl7tiQHQ0=$@BU+zVd zw`Iflbl{W5TvahN5a`otMQ<{+)=f%GEJ`>4@g4QBg@U3QV56aZL)25k=@iEDFBZc( zko$J>xRE>(CP0;9&J~ZVfx&$ri}BH=aB@j3`J%zcE@V@hzw^fj|NZL}1Y_CBf4600MGBy>I9%$z=PT>5d7-8|8 z*VSn>TEbjPyI{=8Xe_~7*Lnwbk=FeMP>`mEk^@QB9`o&kmKfhKD7;!mZ)){@al#d}T$XX4Xl(O8@?Na=fNlDC-eM1n&DpDY?7-6|q`pWW0}j)7I`|u& z$?T?G%61$=mk{kkIlrky^XK%>E9?>MN^4u>b~m@gNtkQBWm8zEUA+5{E$oFTNV7vi z&j8hp@7dZ7nXD2(G8$rUC$YKeH~h1dIfi_ASM8n`#7it;Pl_2vg=CBrawNhD~1 zrz_1}$%-qz!SS0<^ex@DcNM@rF9iThp|3t5gb5|YqOOrHRH^Gt9!|6r(i$<@nMvy5 zzO+Ow6lCmb&cXIRn2!%b3fL8oE(Hv2Aop8C0~cTc_1V!aVn^BO-iJ0Ge+I&5&&@jd zeVMFucIgKag)O$7@Xe=;3-*bteT(kRZ1i=+X4!uyVg_-7Xgdw9IkTD3U13B7U=R}E z>rf3HI-)!sK9mQ`$mJ{i#}lOWw6KOU`q?5gWH2bOQB3lY``Rlah!(FXmM!hqHC*8I zfB#t!;NBfEdBqrPcI56KC&Nhkt)-E#)}#% zPWT6de^=K(ac^zc5|i7$MqK~6wc0|Wm+kS|P~#u|v-a>Y)Vxsm5GD$F|2rjbB!hn+ zwDNxG=1XrB2h!S`|J+|a^(>_DYs#|rOkrsKyGzBkJau(#y!tnbY7IKM@p9T*RaYE01oRB5KS z zDv_}a`#3X1>v|GzdA~`7dk}m)6SKHlJn8NAU4A+0&fB-w&VlawFSoCK;+YY(n-T8Z zn+^WMaPF8L%SJIG>^H&6A!B6s-EZfH%0*K6xCY*Sso!5-lII*q8Y&|qXE{4U$VkD$ zm?6-*qp{$g$A2#eCKHst{=L}94sSwLlgHmKLV-psS|G8&_hBB1vEYW zvhB710n~3HvVj$T8~m?2Cmn&|4CW($ZzXeW-;!b%7GuPzM;W|aL|i`z1q_n*+dcSk zc@)8T%2ND&`OI&q{FsXNvNCe1 zgcxp*IYoB$UycR8Me>ioXwhvDYL)t@H6&aIsA{9Ffx*-zXcyuDiO-EUf0-rSnC}!f zk1&^S16Y?-E7CC+M_rffFoMRQE-_TRR{=_emhV3)i&)Sva!Q0cXt;9_RbEkr#rQAg z?c@NkFgBAVUz}no_a@jwA9-<}Q1X)P{e#AQuuP#%N`aP!V@J~0xJbdc>jDqFaQ7R^ z3thyK*-P@pt4eWLmylom7=OmHi@p+Zp1?UGdgr9rN+ZaKF7@H$u0LV<*(|xEOiuXA z+G$E5mF%xwTgdD8vb&1+UnlcRV&cOx`pgr9#`rd#H*RcO4mC!iXyK~#Q^-RML!*3Z zjkE?R$MMCCiECZi{q&y*YX;Zbk8J!F-nx_xZnE(_7=_k}WCGu&iAqfmp;1G`brv6)i}yCufm7@s%ER@m$q<6ecczr z6kKVHu17u;PxPbv3U~Fs7gewd4*Ij*x;}|p7d@4*^4uoL`R7lGTnt-swmU}NsOop2 zqxaL?`mrR~_hn`rU|fC?IaE3fsmBRYOAUE4Vi6tR66$fcAx=ZW|;?mKl!5i$l^S?9SUU z?0_f`gm#f^DDj}Zyf92DDg<+xO~*T!+>xO?l)q-0TUM%1xIK`zD%rwY1aJFF1MGCW z;eF9=^_02HjO}XX8weG>SZ_j@RRMnY*dw!*0Sde4a_`fG*F-`+D8uTa0VXu#XJu~ zsoirErns~h%uK9+{XJkLM9{pavYlsrEqr|OqkQanPqek?AiNnt5Xg=fH7w#+flEF#f~*-$#zideXzVUH6R0PoMVF&5TZ z=g2po4il;rbzh3Fv9A*3U&n}=jPnu}haHoPef4lAPobT?3Hi|a>zn{NOJsvnBx_rr zqg!8PDAYqz6}dOwO4=j`QFyl^I-_9%ngrJqm<08C%R>_}>~xLAVyQb4G^8pVbVBHG zmLh>VDlSVww7E*T3UtFY*f0g|nD4>l@4xCDcK39;!n!H*Xr_#JiD^ga@r&L)_3E_T z?{mn|$T~_i5lrsX_0&W0eV_OUzZ*urTMev)z>bC8$HPj}-Bs3__6%f52cp9WTjIXt#=y z%1{yCZ!gUIvMVyae{$S5A`V%hV(xR}gtZMs&Fl+Y4n5z+J6Eb5&BTAXm~b+cpgBKm zV6^_a2xbVP)$B>dSZ8|rm**1PMQQfx^c)mV;N3vl2w)$$%XVmWSt@#m$6 zPFc#cF=3j0Q8<(O`YZ~{e`n^dx z{Cg`!RdxB`PIcuDA8IkZ8EWX(YlQ{N^n;I82?=IhF4+!_FdWD?5-2AM(&DBmO%3IsyHP^4Rp&BY` zcEr;+E99FD_MBDDmIjs4BfTC1S%@j5Zaj)*PhY5%r0j3j*IQI?J6Q>!pDd;eKWshr z<#_}{M?NSnx(*TLDoo~Z_x`$hpYJdz`sU{qZX&hPGXNW!der{%B`=3~&z07Zy6Oat z8EiDFKCCr!blYM!5jGxfy!iYh#b^tndFHw59vN(sP3-fTr|k)Jb|kLVo@x`&u@(O} zrr|@$dJ|$Ub1d=+pvs6_`6e31(v%M9au|E9(-~qHJDngkLXS_L_Au!$vTvW9U0wtK z;Ey5w+8T@6Shlymty|I>^TS=cw8!vSP$o=-SSh}K59l`xI`rt0xs+nT7Y{`~u1eia z>CLa3Xn2|QW&pY!iMUyl7&5dtKV-X%Re|A&(ID5MbAZc;Itouj$5)iM^l0KGy^ zo``xarj7i{tn<{5`n~XKsGI#z*mzLfs_jhBKJ;hM=K62#rP5Kt)D#Q#H#y2m9Fo3! zF*|;49<^G&GvNp<#34Z@VRVVwp1__K9uPt=o@J=@JrcbNkchGqeu~d!=C68bP0UQm zQ-nGW1wP%&YsPdX3V+ysjvYx-phM}#idW`a$tgvEZ32YiMw{dsFmu^gb?7gFY zwu8785yR@^d!=n)J@6k^LuNZW%Lp%`4{8FB)Ivmbx;1Hf zb<~2nny#DVMiJ_G`JJ`3!tnb?7m0#hJm_1T1+R7(nqfrCoYZwtGRa^O(<_Tlf+^2f z_g33u>Hr;)&%;8{Tc3juH)sr&I~5VzW-wsbpC*Sc--QLzy;oYk2O13=fq{;m$bIx* zFBfyrui1j%*&$7AV@O#Egc*u5+6kMQvdV6(F_xi&e5o{NA}H?F_87!P6oF{YgDLlE zxZU4nyJvSs$+j23*-aEs{87^_I`eN9>#sF|PSQeMX^JTKWz^d0)9#k5wkrm|71`xG zw0*O@R5R$&>lp z&O&vlC-Ngd`#qZe1&ygS*EZWWo9&3vJgIp{YG0$tsrw4F<^ckml2-~X##IN-DZfT1 zPS`U~gc}ATfXb&;ZyJ^WzPtV?+3qNG%x7d9+Zs*P1e$s6#o$Z58IE2qJrnQvID9GM z3-+Z}PW1jbId`LElknF&hW|v|unep&tiI=dQ9g0+&&C!uu#3{RQ9xtLZ{_sqDY*4Y8)sRylVtvhbT_7b;S{LC)O%C!m#>9|EPo4 zy$&EB(rC;!VtgW*pyorq=W|5b;{8L;j~(BQ>%7Ye+CNeMa&%{2WCN7fucd}EmKaC) zrA7Kf@QS)SdsWj?>YdX+z_L4q4101kE zWX46nAd^mTg-=6NCY%oLx5e+|89203g~y#Gn1T;-hCY~);j3bo%a~G09~Fa=ad|ND zxo2dnhA>H_0qzt;0?-c99jmToX^m?2rn(j!0j6$L#u>P~EPd}OCE8B2#uR9fyjJ=q z>zUp~m50q)dDp%08G^S*_UAWN+*Y~+89o_BR%%5hs8?;eQ<3}!(zzv@?^vD(g%*>l z5MWSMZ0qqpNDZw`cgGmxd2!+_EOT9o7~M=WwDGDM3!d(7o-WuZ7dtE~Zy<8W8K~nf z)dk`5;|8hG#BK-f%BM9~$w!t3f^Q9#2Hh(dzn9=*Ofi(?Pf#|g#6Ksjm*3VXVF<>r zJTvrn#V-Y|U;^>@WuY~J;*~o$ukGajdJxYUh5LTi3gS^~P)+DV=w-mmSws7UK0q_> zb|8?fQD)ixocAOR?h{eFVA#RfEI!$_v!6!IEr`olW1@d*)z{;?tR0{!v(}BfuzPF0k%iN+#^xv=vDoS!S3{F^LDr!jf86Bz%c@;vGyeFB9M{iK@u) z!*_q$0MPvJ%L3h-R;lYcg+;rnlym@B6rj!9qD7zbi3FqLvseZHHGXJTWfVpRr)=JL zI{K=>^adURygA9Y^KQN~q<6V@4!P5fQhMR)3grBZ<3pV)&!WjeAsO@@eWDEdws_o9|~eS`j^Y05^+uAZ}r1bI zHu=QqoYFpXdwoVQ3eJeR$86)4NS-&>MaUD*;dEI~?2aQM(qhEY#2xDRV9**U&| zUxVvkmxUV6566x2U7e>--6U;gonbE+@bLhbVieLu~D*NqAp(FI$MZ`tdj#90RG;daX> z35CUSS_T}{^bn3A_}bKl`*pSCunDn(qsN7A<6gt(U#n&ay-qM0x!V7T@k>ol%33r- zo++}(o+1~VJ1{q$18St3se&UV{P%Kf?CW5`)Y>WGRoV>P%nTy%Sj~Mj`{am_@>8%0HPTkg zPgH%9#%1n{LrM`0fS{<3|3 z_>d->XWSGKm1d`jaK<^OvrW8gq#gLi`EbEiCxLs`m^|f-=LSoR?&o`Up&#aBnEx2L z!gajcXI7|qmw6>a9IlqWLB{0rkM zQDnEpiOk68`Sr zNjfDXkV1c&v5i8PV7%cgW0X{LRzqB$p{}mK*f(PGIdI@NJcAQ7{uW8JJL!U)_q@pvyX6HA<3Y3g7aTOX=M#$8<8<&_W4d=pY-vU4T&Tkbr{?Mw z{YT0v<<|YCM}kyp5LS!)7hFTj*}pZw=e&d|q!VQpy8v7y7$7FaQh7aa-A@*U*5Hg1 znQp&NiGmR1{ux^aV#D^wa&7K-m+XO|1Hq)L-7)1fV3dE=mh>#g*^z^Su;tBkeH(0> zYrA_p)Eu=x5>mlYr{I7BmdDRuE7Z9vOBYQL`=-=q_EDNgzRKi9ioDtWF8S})<7_GV#rXXuiis+2KYATt*|DvMEjZ> z2)r;5hTv{$Z+Jb0R(tp51q<)8<2vIP$GEg{tnS4jx_vrbJNkJ^Lf1-fY89L|Q%LPl!2M3-$hn}oG;SV`)$$x0tbb&i)^%XRVZI^!ET?pqctP0m9 zwX~M_zo>6CF02KL{=veh-p8%ja5w)T+DT2{tS{%HF3$SZ5@@2XPZQkUi%3B_=ZCA` z>WrMFx1bVa-ShLn;BjeJ?ZT@ze9_;tXLbXn$qEQ1m|dLq3lIwtrI?aWd7D-27VkE7 z0{OeuVF&!BUb#-!gez2@T?1TnEGNKYiSFiNq0A@f&Yw7+MDEG`#*1za5MT+4MNwqR zS*X4nn&m)RO>DWcYrNYM@TC$^lYJ}Llpv*J2Wmp$!uhOe5Op*oXp&=0PW%}$@0n>t z#(?hU2xh1pV-c)`oCwC<-mB&*;8IhA-f({W}$q5%d4S!Vg>pR$tS7q?SYn1J{;64Zf*%v*V^X}#Dt3&G0pz0JmY z;`vcN5WiH55FNZBU0Oo0e*963_OYkj-!>}#rP##6o!DFsIpPKK&_EcnS87PHO^D^$ zMaR(9L&HPMG>NCIx$~-cy{V)3JX{<-fy&IsNcJPPyC_zZ8%wc;Ji83dOh#65S*p5! zAUBqaX|CUm+fLn-X@%&v)E>B!B?O#zc8N+e&L@8!8yS`B< z{wYkMGKlrfz)DRsVT)MjOhX#GoA&imdYhWKS?Thk)r%lirxpi{@4Tkc#3`- zG&FD@5t&^&@#f^8%p&#@{4=rAs&rL#!87vJ#%Lvc3^GFFCqI!Q^hxRJs2I#MS%EfI zcq*B0FjyLe?svFJztBm*05JXE_VfNTtU1>`QX)?qY9z+dj_T2STnVOO>EPq2*?y6O zSL-zMPn-mMqGXY`RrKk6{K-?ct-s7oWK+nXQ@SNrH-d1YoZieg?%DM4w46CY@=0$| zCCDNHCCfgbBNX~Ex7PpTH>q)uM#@`*#P>|1%5#W-a^Z+I@$Y5ZLTKzAR!GHuH(b=v^gGBh3ej zU&*hgeCN!knA^uTuPKjWKl(n2;fl-Z9g2;Lh3E}zvOqGH^l9}KU}-v|TzL@2K9g;z z$Yg2z_=ep);vF$GBdfA#q@$TMox5<>g=On8$II5*p25)v7Ps{HT**_D9U6lqLE1(Jl9rl2xe}%kV9B|LH4XnknBM-=hK2ba{CBVXPe9h(F-i!Q zMiMtjttzxbOQX!D@E`q3GQ3I!TIj~jYO^HEf_u0?9>`kSgd7!&M`XjJ$O$q><_p(x z_QBVwWyy5J9GKSZfIqwg4n_UO+Phv6#ol`3m9ok_` zeX85f`X~bfQHhep zBVaHtE4%eQS8f9k2ll<#hp5TN@nH|V_o9GJ^Vi88Ye5GK-d?P}g1coPZ_KJxj{#D| zV6E9n8r#44E7ty5+JL>^zx`q^0jS$~{LJPzXYr=|d`0O)^+P1rF&isM27b$upWLvC zvw)sO_j|c5MFc(e1>2>Im_upy-701^)hXMnlwI?HCCZbOt(oKqET!%3(8o9YnrjVs0=% z^olX<9PP46sS*fv2jJA=uUHp>&8K2C4%xwI{ex25j6*Or|n^B;SjFb z;9XW_Gf&c${jLl?@SkAyKzB5kQt1nQ zBb2UCv0E=mYG)F!cqmkVno zbYv;bR-zc>?3~w-djVHt(|ItSsQfk16chZWV3N+3KB_pHfC5OM+p8O|FLTjbsy*Y_ zC|n<|uRPdCl#mbsnw>6u4DsnIKvyT*Thi)=SmbcJM1g;_TZw}0&9={;6iGorr`7^7 z6$B?7nt!6bwj=I8Wt_+vw*Kwea`nO6k+#<;+0vVk{PMMEslh?%)YLGfpLkYH7d6`$ z6akCix6WDq$A!=avjp-h&pDDMh%~?=1TofkF1riRiBJEA{MLI>Xm}@?M*G#)Zjzr2 z3y}VHg7Z3>A1xCm)GzPgJ_l>RJku!b@31N{F=lf{+3ss;s~4fdz!?0&jozOLifR!% z0y29^u=?W{NoTHIHSwDIe`sTTNq9w(U}SZr_UNl-nDQ@m9QN zP14g;=r>P%GH#&IB<68~Db|&>Ya@v@6Ha>`ceT}wOa*($R?*rN}b!tF=aRYJgxPoAowB_{1dKY~2QLO*swqM+#O1p>44jblGf>9}2VGl_zCZ z^v-ShQNPe(_F+0f<3}PazI7t3*b_tgc&1rfEc+ei{#r6Xe8cK-&qd>ZmSk_+lfZUM z7XoFQ?!hpCNJ53W$?3HQ%Kn!D8;pmKpx(b~yrZUc%mm`teW*hs zk%ez7rdF|qwy508i{rSu2g(y~urFT*aFx$nRweJHdd!QL*aKmM99ml1Cf>@3+FMhv zdQhg#>FLp3v5N)<4OBh# z6s9PZ-VY}#QuN2hX3gO3c7}+hydQ8b`>aO}#v@oSjO3)1&OtTa^E&vns}Q``{?=kY z|3S+qiA3$}-~3G{&$RDbM^2GKOwdk+QRiwDKrG=6N14Y~5FGQERIt?HbtF>s`a(B< zZ-i}V%7W<=KS_+>=~W~eAHa184x-acHpqgaEcvJ{C8z6Xxh0X)Pl|z1R%&%Ms$p`J z29N|3^RZa!?nsb>Cd=mlwEviaWCUbHR7pY}$)_p_4F6g_1i+_ZHi8&jEI!IG#VE2P zjz=5HJumI<7Y=+hc!3p?rs5Ea*pZG8ZnBjBoMW0{W=g%zbsV!L>Qx4`?3up@N=4C} z0t_p%y5FTteJ{p}XxuyGFG*xhp?Pk7(r30HBR#fyY^NTsV{J{PsXc24$>M9taeBie zCtXTRExm#{DPqz??aS+K==Z%G=EAGCpmq>nN0=bXTk=)gfP7eF64g~!lhzCuS6M}2 zUs!{^+IFQn99k7D@~lCRF!T1LI=~Yf^|o!L&~de4N&H)*EcUK})3caX+c(@E{cWmX zPVQ>|hFrbJ(CW6Nswq>SSu=Cbyva^;#G#H%ucz55cL~(V*1I7JOM>|i`U{d(z^Egy z6lau}6{xK25y9X2DX0Ch>N(X3 z95a0`7NSok5gq^dZQ35v7k*lKOgHv(FEl6nh5cy}wn}rfN?9J2kQ?PG7D0@@uvJ<5FZQ88KlZN+L!xE4l?2vDX~PEH5f_o7gjy zi9Yv}vO(smKz;qdXH!qk8lI5kY+RJUevtb64-QbT7> zl%MylX$)p3TkJU%S_nQ$xSt?wx)PrKoehH*o{=`;?_FEoLGWA}7bAqnv8dOVA}nm* z_it9TBBwTuAz*n@{uX2u23y~&oKY=BnttUCUbSk zDYiQIFixoIq4wq!snw~l7s<@@a*Ictv~l<=R==JHV+sT!rzLd&F`qJqkA2v{T|ZbQYH7-b4#Sx@$9oW6;_*kPr)cG4zSIA%g=P<3W^oC1?$4j3(b zQQxbU`>htRfnCz+6pLydlUY*PJ3BEm+B6eOnUNx5(|P)ki}*5v7j4*vUU^?brCrJ- zzgdh=gq^6zAeQ_4=cRLt-(~(9G~_7h3gP%Cx?e~`Hzw|DpE#ckxdp#Vq!BIMM2i@| zpf=47%u7kKgsoEVj2z0U;(I)`y>Nmxj8%>9lkzF2zWKk9KK4LwerX(8)9{g&Re9=0 zVu%Gj+tv6i8@-L2VNM zSOYgpz&!J187&|6LS}*ckC?2oDR2v(nj z0MkV`P0ckS*1`{lTf))ZJAAlU#W5|nq?Q=5)iSyt963!E$jv-?9u4d3bji4d*E2!E zfm(FJVFO7TI$*8)^+ntNSAf9H2Dc2-Mv(u*q+g7btN&p=WVTRI?&U%}lIP3&nQu%7$PL;|(rcIg zIJF9-;=9?meng~5fWIvDVr0MHn;zGlqM2lY^0T-?Cbmq340@G;FV!m&1r+HeennP_ zqGmpR`a|{Jlj(?m1#ZBdZ4|0yga--hKuwJht?Of_-^txuZ30Xj4$$?8iH3CwU%!0bz(yJTGJ+Jbk+^tiyu=fprE^F8kJMy%ir z7*O=64ecpI^vk8WWmig zj7%hn^)@(we^t~QEuNZHO{e1ZImO?)#&Ta$3SufPWN#3IvhZkGWp-1w667yrB^`=%=s^2Kn^ryC6wao?N9P8HR0J-3oC zTHR`*6_dD7Td=URU@z5U*mj0P>|zL^pJ@+4?Cf4q?naDPpO%4`vzZ$@2@}=E!D}Bj z`3Fcx=L9!9M%Zf*1KL)Uh0M>Wr@22Yd2WUItxZ3fMyk@c+)74|6k71Naqd2MV-3*5 z9q}3o{dl*YT?TC>W%HWKJHZaE%KNYX5_5sRvU6zWSG+nu*O{!`s?sb%XA5=; zz8F`S`Hi>zqIf}Q($v&&@3go+mV&hmh5nF9i_l{xFA! zd3Ij4pHgfmb_zgzFm*%?>~F3IHF2~<%=!nr`T?vQ9O`E*e-<;_TdP8St(7p!Y-U{_ z7j8dmx@h9(Kn9HesvmhyIyPNrEd)EaJV*7u4@MB)`s2wt>x3sjQf5|DaMW+s)AWAV zDP~ENpNpw;(S};^Ox7_9DTP>knA!Nv%PrlU8|y3rzAjxpr;4sIV2o38hvJ=3I*LT2S4 z$bT(WYa*F5F)87p`i`@E>)XFzoFz*N#J=&EvKfyN>1CRg#{^P?rvq=!=Rve#KD+_? zv5KMFgi#5J7vgHbJ`wq8SObmz#IqhQ)o6lc{A?0vQ2Yl%JTFVN!MPzP5SGM1daLx(8l2!ZQ%lTpc z<-^OBu&Zbl#$YZAV&_G7UI!hBwD^d`6hBvR$b+Rdc>nlV+gB_tznxHT~(R zc^WnJGFueqKk>5F1y)IfSmbo`Q&52p*R0-I6em{>u*|a(7F=>au$t`*}a*_!dmW-4tqo z8v(F^f;cj42Mi0%%mXJ%>)8T?hqg4 zHb>`Xkur>(BCXbt#t(r3iJAOIEbUqUfU~b4@TWVUFDVlUk2(U0%mx%i*?L%vp>tO*I%AODB`a&>))EpIw zed0fP%06ca7QNLj24~&Jll+sZDv~78d*%D`LzaQdP~5g&=Wr<4wUl1;tO z;yMQ?t)|LSyhqP10l0$2TMG(!CfgNL#E(7*ZuJg*Pj(PCy?a)=x1wN9ZGfjL&GO&( zXLwI!r9`x#cYXj;y-N|Zpg0}%+sQ&R=+#}C@|?vLeu$QPI&-iT_nAE3a{AyX4%fA; zg;^C`|8N;^jbe>f=bqP!nA5F$-(^oRe#o{U`|7~fXi$EOm-QhdoaDuzFFP6}3-DY;l6*`BCMU`I2!Ob?LoWnbI4q7VHS5%=dQCu| zM;ZDGJVLwoi2~M5HKCu3{Zx-s;(uJ&XM^&}DV9v|D)^He+6!X2xoh77@dgW0^xJxJ zHA1L=h2c{q!HvJ)V7qOX)dqz*6WLq@t!b7TDmWq+;f7@%8{U2EIt5=jevgHZj&?iz z3Pyf~GiYbAoiCby&m3XJ@lD{-lxZrhKY$}}nL&s{MreYXFa zV!~{@Xj*o}_^bT^nmc&`xs4vvFqUt_l5g6pJ0P5UzFPawcvS&9mOog5x+#2Ors=r{ zAn$N%O(B(ICY6*xw-<-w4e;C4&tSWrW}PejJGS}#PB#}SH(+30&=nC@whPs{T~}|w zT0TegAC6`kVsfG}JlPPjL@*D_j-v*4OJ40tGQ+w24bWHs;{b^g$!BP(wpNS~C4Zg$ zth16(;lLRx8vt4I{n;$+fI6ROoTFxyD+ogt9Qkef&*>{)Pgn@iZ0Hw2R8+)#g-5ZZ z)KE3NRtAK-jo0%^16Cg{T@rU=f=u`^_5P65=pM-+a)ZTS2IDC?pCgTU`+0R)QZ|M& zp+S)4=QOs85xk`Fu#@yJbwss0wVMEJ#FcAmeahN=&MF=8YIwi1k0tS}XlG&mAocUZ zz73avK&D=3*RRaKJ`H5Sw4JYv)n@7{cBJ!Q0&Q==rcpP)j4c#5-V>CgO{h)#oS6@h zV>}(w!E2_CaU}KxOm+3yB>f3oj-L%uQ>JPfDl`L zJzY%N^iL_3>uQ^8*ncrmpQRV}8q{~L$C_?!i%yLz#_{H3bpL&#rUjbcilrhHes= zUsZwrDNC-Ikecj>x6rfY1o2BgDVyrpv0j(s^-p$bLv>W6yX_=(_=>MK$IkF=%_<|p zl4R31_)tFQ_`quBm>xY8I$06O74<4(+a^s;r12DD#Uzrvy`@u6syNrBC-I$_7J6+s z;0Whl?;C4A9kL#BzL`PDK)$tpJgD;?#a0X)X{4I{`$g6pCTuEJgQ_c`b zoLI`FJ0W`KOhQhhMOCxbQld%m4$-Jy=6~pV3!tjLu5@+A?tb^-|2*$}-+c4UFeAue@4aHLb+3D^>vv6Q*s}dD_lVEl z{iEVIYEXULxWur1#bE!p$GRwIox^=h{an*2g5JxD$@yF4VHag!!ZNjLo-e}j(W)vGqnw=;@ z(mRc2IXl9iRB198wQ@OyWX!lFi@4CXG~~I~5k&>MP=JR-gnMYBi%GZ`Si!R?iWlkIWs&C2p|L?!MEeHR1 zruUh@fRtdhRd%$5-L#=o&Fg>kp@N1GkwVA*eN~6#@KYqAo9dUVq&oke+Vq=zmi9$@ zdZlv=xQ6XW-L1~FvXT{gjJqHHWa+8ASN)dWk6Ur?_86?{NKk{y_jo#-U5g}I;DMk? zqSA%Sa@4#mwH_S7{PKoye2j;;(WZ4tMSd=0`&SFEoR%xV>TZ$+4gf5h)&{-kDzegTN`ViHEUJyG_~q3Twl3-+&}*z*Z>uZPL!&>^ z6|loo-;6hb#j10gCNelbCkok8KW3#nGN$Pr1mlC*yZB+&*u2H1V=L>m+nt+*_O<&1 ziKJ~>#zNX7J1wK5Zcmg%vG&uGMa=pc@#M;c>`XI7EVY|{G~s!c@+gR(f>b&^ka9Xi z`}f(nT$w0xa13y|a`lfufe3f<|C%e}9t$mn-J^fjg~1W|6Ng+$G&~(?A5Aqa38dvX zdGO;CJLr6B{MIXkQwRBYV}i)?rGB1g!XCB(;ng9L_L$NkDLc3qTgEfgfj}}Wc9vl?a)8gQD2fn%I?J~f@~W0 zUa|;|*d%3R-jRwm%i_EmDj>-J_|04tbPzCbc1Q#!kw&Fb`m1Fe9&)~cQ;dn3Us~j| zDyosC)3y-;83fasE29MZFR75=qkV2GjVS;W9xp(c`A+1EyQujn=*Q6FOpT$uW=7H~ zIWnG+cxP(c_7_99G&_e&zVgKKa%Ex%Tl$vv_Uz8-5-lH!QF3N+)kL`%)I>EsM$ggq zC2PVF;909RRlZ^%i4Un2(g!RWR`YZ~xV7!1IF%^onKF*6FMqwwlxNaEZa4#s8 zGaV5=>dvpGb)u=8$Ygk@tQj6fXZ~6DlpE0C%t?sd6Z8`SiSZaF@0Y7{ekeWOH;;w4#xA z@v%zVOU?F11153Q0xy^$IA&;>EizXmJAq#KuP>RDtCm0SO}##!51u zt?kdf0aV}7`ph4v@-v=RMwbjElt|+*SdgHUnT@F}NvokP>ZMiPt)mESNk*2_dVmZS zA=$jv9I-s#K^V?;e2UZT7q-ju7q`*efX$qLI_PfuibfZy?5KLtXg%uAt z^@B9R5#3z{d?Pq|*pZ~4g(wc+OpX-pZ9aK4S8(NDyzcV$CwBs%)x$&^h+U+Omc7dc zCz!(nXIMO%fK~%!o!|NX@<%dVe=hn52u-op;0-A+!T=d5RHTv(P%LKwLSHNd3Q7ZM z*k?n4oe&(hx3FK^r|;{`ou2o8DLF1=`&)bovp1l?DPGkM1>?fL>+`(oRAsaokvFCqg{x5KlaH0zs)ijfqi-+GPyqB z(s+ysxHttnvBaqdYQ#-@x(bPf8kX32AOh^#@(}_t_jk*-eQzg{D&1H2bAop2rAsJ* ziy@55#t5Eg+WvMR!c~fj5Pp3Cl;0mmL*g=KBjahZ->D(&`#Ztb(?wk|*Hk9hgAUnI z-;A^#^%ZFMP>H{-3-_aFl-Pt_iu1i{%*HZ*nbnU$J%9X-tZ%SZNr_3OzVXxOJ$%k} zH=>E)@oZg7RLFb&P#%UAOzDJI;_+EhHTbCue?x+uh!9q(uQT3AJgzAf+|L^00nqai z!NaDwriKpC_2)x~4HdRNzVorwIXK~#r38ia)> zA&_2$&cunj0YySIEt4;pbmqQG0jr_s+t7D0{7NCI<+NDu#UBxz?Uy;3+QrC4*~4rvqm_JIawwK*?Mz+ zk>iyO%WgUFDgQ=e!u&j^|A%~M5~e*y$RcgG>`XrX{CFc(upH*5;6wwMW-uvs>xhtc z#{7oqfO$^7Bb!!w4LwVhh3hvnZC{n-@ru_LfhinLC8PqnN&R?&bchmT;EaiGZ>udYu$I_K7J*cU`MpWGWe#M{GK25CCVs!>~Tjh z&EdnL$YMNDX?z&&$Fm~K4n%lLkG)li9vS1%WlLof za1ZdrwMCCnug}CnpX!~@+xUMAyr&aX!+7vq)+$# z*3u8{0YNJs7--+tBSvIb*8k@M=fTRfHZzT`)ehgus8{A4MuF?&x?tNCk z0;PJ!o;Q-YqXVzVej10vBc?V=YXbXO<-}72aPD|h)*;b1)`Rh5q{}3%XMu$P+5IT2 z{Zrz2sFP0=wb-jJSee#euCtSUV8ZiLI4I(rd)75m0J>@y7>S^}r4V@0vef&%+@}Yc zvOc3By9FI)ejt!d}RlTU$mmg`H}zK zV>aJ>7DZcmPe?Kg)D)xj^PvhNjOnEH{ z^W7hsS-W#}n`D{}|zbcBad^Yy97)Lhf z;*0`&p79g|)nJD=cE{h-0-K0~ustG5Y2P7*i*<4i2jSn3P|GxcXBB^$)yFkUtt4mK zE^!i=b``jz1R^Yk{i&~Hl+O+i8V5YzfjFRZIyvZ%OFv9HB%8*5BzEp)7?PMz6RD#H zbX{5JHYx<|$b)rOR_-socfrG`c5ukP@=wxKW}jK|iY&A%JwKUtkFXoB)qk)}=YKIy zkP9J(seIKupf=wCgf5%2PaT2zbm)H;o%< zSI#Crk|D^Lc1JqKRPKyn;L=zljjsm+v5w}cYP#c$s`kJK@s+X_Eu>~b)s)f@9sY0h zk1p-&>6KH;3SlU9P4y8s$X}H5?R2_ifMPlE`PVGNly*!%JT&zY?Za-`S{bzyHadHs z{(85Xv{Oc2$iiAI_uU8CfLF3TMAX4&;;gCwv*bdAGW_gVIf@Y07d&?)WAVqX==bJ7 za$_=bG{!Z*TaZ8EMf9O)Kgr~TWTWFWzX4{uAQDe&wn5YGV4|p#<}qvfQQc zH4Hz?Jzm^ZB{Tzw1E|@QA6IXg%?E?;7Q>a_TDqm%=WgRh_y7U<&&ZV0X`o&Vq)l)n zv|OeX&pnV|O20)u&?YaF+J{7H;UiX=e7KB#9*1s$TmF=Ll#BTNZyr$U4hGO_RTJz` z91D;auASn_-uW03dW^*DmTjy|cRG!Gta@P&RI-JL`S?V#;+2n`UHh zNw)+5?YjRBpAR!}?E)8!!&{-Jre*e%DT5ct8eBY}QUp&C7yz~Vi6Pltaf<>8>ez1> zsFQg5j`m_M9ISLR!JiT2rGwO)LiHA4Wz*k$>wqVvP~amK@tis9Jd1dJFx;UEWN1p~@d5U3rc3~!1u2LI z(!U#DF#{%}ysjEgkNJ9`rC;kENND(T=FC4XHm&O;R4H#g15l7!&RG%628rtycFjMZtI8A zw%rIjhm4lbOA#GvDAZrW^*U=%R^Bh=ao~AS*SVKF5>C?P-W}$MX^Mbyus`CtIyN^Y!o=lUN?#LiLsBzkC`y4<&P;Um{<< z#2LET@(|oZn3A}UTTYS$WzP2L`tp8iCU*3VX*pE??c0EYm5q!-1_Kh*b%CSmqEef=dk^QAHZU44 z%v;g_V^dnA^GsF!+SS6NpJ(Bnm!V}3ja05uO@2ny{?LXES`HWcP`+H4m6-E8x9@4? zsoQ6);!0Tl_DI^{MqDY?E1}Er1d;+F*&jewEc!=-Z}f;9--O9VIvQn3GNCj9Ac}fk zH2%)YfG+hx($l|JB=n092o(Ia`u%`X)d4w=W3kFJd! zrY)2g_$cnrV7CH`GoDY~7{HBklqasRMmq_7O%Y+E;9a7&vZjj_o?Aj zPA1Jqrc5?YjDoT3N210nJcdt5-dO-?DkvZ= zfYE?sAocTAdr4CNVIp=;pvb;hX(ZcY`-`M{z?ruD9iWeK=Req^^Su>*ufdO~i8g#sHvKdxE=>P9cF8SL|&YTqZWGf8??c1lG#E)O?>0LFWxXNBeV{KF%ieveUqrBefd>s$W zbvB*uJi&Wa+h@jXzY$jk{Gb@$HjD$cdt;&oz zHgJT$#(XZT2BvO*nkv$FzG`#$CE&+)8Zzbq35wrs)O5xmKlmuH?!XxX3`?wv5&1UkP z2a)S6X5n#U+D{~3@dx4$J#B{6ZNkL3&>35y`-sfw!S5;0~Jlo?<-yoyQdOoL={wG&r z){L9tGdiWX&og@>e{0JZP3L=WYlT#9LW+8tu9bZTaVsBPVe0xt4_k%bbo>>=oOm$G z{;@j$?%flVCUc_%#nyfwqeT-gVviHRT91EI!{VHmo~ySfpfrHnTLo%MRCWUeFy~TI>{m_~&IftPV$8R=TZJom7PMl*K(ozXe7>7kVZ1 zs68`tLcH0=+TnOx!1zAN5S+hKK1qQ9`a?%|8@jKm67QdM1#g>Y8!XGhiCtXroagcc zqSY19SBtU zf=|f=9!C%Xo|2p%wGAo40pb4p`f*ADb2k*%@b*su??w0d+r1ki=CfzYfbcIR?9a3R zC#*4&7q~D~^xmf#Mc_5FzfD+`PY=~c@XW^mlVfa+a#h}jj^tTk22Y$}zm70o@A>t( zl;_;}z2Pm2DkOPr=2B6XTTXM<`>%?%0z%8Yy(cslmQC_?JNa6~6_srw7f{mdyv)ha z+T;CIXYsc{ot`olz_Y=d{V;)yF7dyUpaQ}GsS8Bf`sJPN>%%`MOx$GESU>oGTiOzF z3KD(%!j#ak{T4eVPBS8Dwy_tM)^S~86PFnQhM!=CzwWZxq-;m&v7ly%z8Xxp^hf0wiy#Al$ z%cN1Tf>L|ui>OL{R{nU7ZA2Nr3ByB<*#bibK>^vjfJ@wni6-cJ)-?M!`X$Nk)X6ai zz7TRuw;|-U?Ao!)?K`Mj+33a)F_0O42g?C2xIfx1=iT`bGb3FLl`BPFubjc)N3Yv+ zlv%2%*>nPkR~l4_>Q-lWI{Kc`N%n`I@6UW+TzbKB7SGs6#E8Q!J|Ksfb(kcBqrvtg z{6wG6Keq|9daHB3zDM#2KyhS-Q{#qT0-U9kb5iWxWWLYb_CN^BMm*q$_c0=f#JkV8 z=OL3Q;BRHORgM|4Qy(es69E9_T zbmy(CJ5q4DMcz0N{^L|=!evSGPwjQm%m5sV6TKTX1~ZwpqeLKYNQFQl&#)DCL(UwwYfn-|O7`Z~E26JkKR0Sx7AWe{N(v zPN+LQSJ4%eU3*bQlr3EHO&8XCgkqU-U<~U}kpV_s8_ah|9p#+12#5h^0a>fpbTgw{ z>t2NZpOlaApBw0@3iozL2ZvZ%WI*?iu;uHQ`$FgC9pb9sO4BZUMCk4VjvUC$C8NXm z%)1Z);YcZ^qbmXW?{8#@(opmcBxLw6ppu?fqmRqw-1{57ZX!89sv9FD{L=FTVo>`d zGi%xM2XahhHC9d#aUKl56zyy|Jz1*@BU2gAwU;$*dy<}hWh7NLm$yOrG$ypVx9FSg zl*<@gQ2)ughqpW|M7H2`?H%jc`%b8~4XVfHku9w6#S6G0m+NRN%;{LNwL}&!`uiam z+Ss@HVukYYfq*eH@cw$h$&2Lb6I_ns*w0Rls%k}+69Mjs+JK^+KkJ|8vYW*_!1x=Q zaTrPZX`jnRp!2?~*z8hF0V4)n3G*tt3zv$)5TuE4?&9tH(L(?>tro(Cp4cI$dH$O5 z6b@D0*lsfVz|)}CtFqUZwHf`R)f+bc9LYnMXM!l-u@5a0e)N;$)zHhtH94VYplSWv zeuv#%-zfgcfg`0&4==l*?7Qz=XdsbWHhi%XW5J7l*m@7%<7Yyo(yJj&4w>3 zoXlK7g2pg)?FIs1L8+`eMgEo!SMq(LhKRquQ;g9BPtD}i5^GBX3b7hal)5q1Q}{Td zVIfg)E~TA7NLhnZtuaX8Otby-jngnI()8bg<^~Dgvj6oeJFni2^k{ zKgT9QghlgECD^~Sk-_e@nr^^%L*0yZ{+6Q&e;!WAaBDpVlkCX^9!UC#2k;e_Xa!P+ zEdV~#F6P$KCsA~9MXo0`Y&Rhxr8wgcb!OttCw%nnubJuvXBz3h2Vu9fks=Y*z5|&_ zd;u)V8MLrWcJ#v>0E2NvJ7>rtwM4TCVKWZS`?`dP;@1YsDZVq$^Cz$%Ij@qzGW z4OBm5ufLhwInpJ)I)5^P3Qc*_rg6%=z8bSmD|h`q4PNB8eA)rF)X9Vdhs3{FCMtEI z0rw~)KY_6Ir0*v@EyP5;gn<(1?z!*y(laQAXFrH_6BbW%W2}%?cH2hGT&aL<%mS0e_9x#?k`O=2ssEQXOcodRTsM$b0Wf0Vou}O1m#louTrBnS4KBt#8L{NO3o65 z{1ztb?Ynf^u6HVorG#$bi%xL-(q%>aH|;<1f@7bzmqp7CIGGl!&|gxf7yGn*lCkGR zzr=*%L?rqH1sHKQjmEG0)jXzD96=QLT>4SjgGqd?M$;|!Zw5{s;>XEygC_%$fCVI- z0l_|1ddF5noQszI64@4O?JsNDmTy5W=m3$5nO(9?dXKQ2r*qLQUZMRnYXf_^L3!S& z$NFN(rgoOo4*^}QV#(;bQ&_~xSLncmS&TAK=|q4$9^@N$u_xb=zb#bMCW;^m4dtJx zEXJ5v{p9zh=O(}c#f_e6tt`o3hmzaE*9|~-g8GvZ*uWngUp~4(3g3Rv_hbggO+=*E z$6ubn=@v!!ztZjY+0%^eAoV{DkiT|}xo{PX_dIid*HXfIwR1Zlm1Wg#*WQ}kQ&ZvB zx|+hin^*b0ZtVn3G^Pp9njZ<%CTz{j1GZI_XNRK+mcz=1%R_=x#BvuJtF`E{<^Cds z?m+3#a#Xx8ON!68T|siWtCcNy1c`O*3pEvVGKM+Rc)*0~ijyuq?l43nE=8GMEYGoG ztjycK;2P6GF7BE`8;c{D8ID{#ah{d(!VfzB#*eP^bqD~82ACGs6K>%HOR%WBRO)2< zhyTHY18o0`eMSa`D7y$({F2-Jp*_jeFWc1tS%tb(!OWe-7(-&wja~utRDF8{%330_ zG`sQ9mo`-`MAi=j@!>f$gv*dJzIkS1LDn%u<4>QjNIK!;G5)9xFQhOMRo%#X0nunWe41k#+DkBD|sU!EWchM&UJy zh|ny`K>_cm+mM_n#z4a)v5wQv$_#1m%XJE@*g#M4k7O4aH1Mas_YHHX|1@2R1Gu-4 z!Vy}uB~SLWX}M)Zvy3FaKbf1|Xpc774;ScHo|nVOR2|+m-lxD+LciyV4Hml4q6hYVym zY=~vp(;qOQ7N6K0?fw?W07wt-&$d{}46OsvvA+Cc4PZN4vD?3|;*X{d3!z+0QKgm{)m?<Ay}b68_zO$=dG}pW#!Or1J6C>@DU0(A4zDOelwmMg$Tu z2gIq{g_;}FKLS0C*#xiNGTCqe%U%sD>&eas- zfuz6#3zssdsz@$8FuwFhub>D5SS@O?_P~c49N5yIF!cit^oA#VOl|R;`w-TDO zo0+@iKh&9`<=cKkE1X1wiugBNt9`l?9{T$-WfDKxbWOj^eyWV3J&h9BK+Q|``SnUe zqjDuG>aBrt41z_>n>L0Jwe%SvJfu%@3_KJ|uNYOUWYeecJBbm%>w8Q{@Dg)vVayEx z$8)NQ$7FDNo?;~atVjqW;ULhyVtWW9=ftp-{w1t|0p7Y-l|o%`^8fQS2&xFc&SHT> z48Z(yuLVo=W2c5NTcRS0@nV zc=}5@?$ULU#?S8(JY}=lbe6;@Nc6&_{ot~=)xUC^brt4<1iZD<6y-sw8SMJE6}w1k|@TnztOGZd=$aU#Tc0VR1`&)_2&KqeTwF_Rip^&A~PebvH9-7Qa8Eah)RpB&JH zW+#5CM*BO4{*p}~@bpC6krI?Sl(q6#{@R5>oX|*_8=VzBkmPcnFo&`WQP+XpLn`Kb zK@8^)@qCx|KE0mcdj(v%*?sockW;Y|ga7k)~k`~`KFrhQ4alx$MzbN(Nh}1nS z6>l(IRuPs+65d)7bvKCG%zZ!8me(f4|gmZ_jQ!La8p*u=N(nD*P`325`M)dQt>;XErOW)=apQ~nHq=wLf5jQ zdkh((&mIYlw>uU}GKj@w0dXuPnkNUEjzWY1PCzg|z5oP_{O-?~v^7R`-o}^eQi^35 z)YnM^BNLyM6>#V3QLastacmnLRx;cJ^z9rR*;`@(&p z`E8=&mL;3gnfmX~-biZiRtal{MJha2gMpv7UDc)qq3(w{ zF02uyqQL}cC3D?`e($f{BKE`G)6nAH5)S z9iG_m`kTX~sCYG7plf1$Fp?!v;>#ELIAV|8F6IGpTLA7ZzQ9FBFsI`QUg>+?;fE-O z^T*r!qDa}@18}o9T91qoH&;|Ux4gOZK>vympo5m!E#afj3==BDjMGOsG8NXNo|R7u z$w0PH97Nv$t58ZS9J$i`JWruhf z_nBLbr79!e3~vCwhn6#Ea|!PN7eVT9JfiIvzLjFua>VMY2~=pd(Hh7wPv_mNsj~ed zTBK6L<@wPNmET!XXXbT(+HuJFj+x)zKsLBmouVzb4=vOXagh7VEDw?Il4;>eI|pDb zVbXz63_pYZ6#;f}vte`X5#0fHXEiLS_Y!OPXl!Al(X0}3=k9Pj7w3Kxx>U5KWM#o$ zL+T`ipQOoUb-v_rFCF$A%E&FCe&L0*M@Danl7mP@yW0MxqbxWU z?dpUdSKw+A*HhaKHy`pPCv$)b#mt3TT_TqFOB2N-o+~**N%U5u8=+^ z=U~R-Y&{T$*81nR!sz3OGakp9Bz7bt1kvz`LR)&IO>KJ_NyBvbq4O_uA>yM-6f|#4 ziX+9j@jOgz4&NVOrV5evfB56x+~esqV;r(o8$l; z$VPS)c0cN*g^KJR<d$<_5dz14U{v_9V!v% z01~0Ui?yc<`O-VTyKS4(-yV(1IVln0D3M>cmcO@P&fv6j2aVwRH^RlMAiYeN1YGe1gA}`GS{mf$ecO$@OFAWO&jdzwe2Tw} zD|BzceDZ?Vxyz+AD?&oXkE^oF93s&&dJ$3dY3>E13jI?ymllk5Udz>Xx@BFrst08> z+)PsaODm3@hM&?%dC~LoHx)7Rqs(92s&I7HiIfxI)Gg~z4V}4f{>RE{FRR(A_>t#+ zlWIzC5#cK?Og|Q4GhjTWhKEEb&ffTS@SEmEvZ4j+AEVqb80MaFhDoZ+b-y}?>&%V5 zfY!X;^l^Rzo$&Fzk(p?sCoty2ueo4j=<$qJc=??p{zFHt7#x;~8$jJ#wZJ=kd9w{1 z9_{}J;pfZHs`|5-3#o}!sl%A zZsraguaMKW6yfoXi)%W;7M#N^3PK+i;eeQczcLXbP#E8ehai$obKFd&l@*V9sq{_( zva*>&0AjcRKn%;M?;2WYLUP~Bc7Hx~kW^b&vN)Wa&o@5t&>YrGo&Q$0gzrD;^R3O? zCE4Wa;$Z9GaIZeisCp2I`kh(0lG%$K-}kG8uInodnp_M(OficB)zDjzR3T<}D)&4(2b{+$ zsEmIH<9p#zblT}%6<-owo!2bqgmvz6#AfK%N{CG+>T^g;^Us%-`4XXmak=nb=p&(p zu`?Mlag%E1s@?^*%kR`Etlq2H;{XFxSf$(r4V93MiqTO{#k#|Yh1qYTtzD&(nzl(g zm1AW}&M>jJ0nPf-ddfeCrl>Eti}F~~vB54XM;)5T*2;84q5&;ko>deiT8LE<9>ObX`z75s zipz(E*j2IR?@X2Q5y7VlMs^Gfc^YHlFhw&jWEV@_#hnixu8xJHNd48}9Y>$^L?{74W`I{aEXuO;WT@^(?B;w$-WdB9HGs1&L5&aoN!v?C#0 zV)YH9oS|l%z}wcV*q1mbl>lt>6}4dUc$?A~gzi2===>{W zj1cd4Bt&n;3M|@XrEFT_-$FuS{kl3y&o#EXMeiTdvXyfoaH0r3ZS4;dG(K5EQQnjS zZ6FW;SBiedmo=tdDXL`qp`a)R-4zGb<{C(;Kur2|3H`rK3rbVRrsX@%ejoWSuek>*>E*XShS=WAgcXh zIb8lW7_*R2wm@Ye@io_+gaV*+)x5aa7RiYjTPa6mDmVASrdoEeU#Fznt-e0-rm5|ACj`fB zna>f9)y1XgD{sY2@pl#UBkJF!^3N~wt6Bb~r@OA)gNU1_caOHO8C?iG3Xy^o6zn{A zJVw@8hc_#&l%?S*MMe7HOye>(K|jL&T`03QK@-w>=Hxq~#~4^d>vA>(s~q=+^58Wa zYZT~-0DMZ2Ybp!Mg&cTNYUpnFj|kRH`1~bRqJi#gtQ0QbvA1v@dR8a@X2X1 zE*d5gDDZ1zjLJOu9s0g+#Nu(uvWl}pZ`sx1IX;_+u;~`mZ4&M71{=yBzqzJ@h|vtw zzS7~Bav^-sEFV_@yuD<$%6^qEH;o)Crv_4jit@(V=XllCgNzU*#4%}f>hzrxB9;X+ za(g8LH+aBtjEHq6UgaMlh3skvETM)3<2gXQNcR?us2pBY%nlAk35#X_x1Fa)QZ#KAW#tG$7oCZ>__FI17bRatm45(bD>}Z z<04<5h7<(RJU(QW%1uM951BqXwDj$k&4L#v+7+=79`CQ6x0U2bY*nZvVM9hNv)-JS z3%X7*c=^JZrv`d@dj9s~)JWE)ifVd;oCyI>RqiH%3CMfPkMspI3cm6m?qd*GzRo6I zxwN25EkN}%g0N@9n^274-53yDPk5@DCR1=kZxUX{3I$q>%GM7If*#}oxM)c>5tJr! z8cU8pUMt7b43AnLj#B_ym^08*!qR6Hl(S$RR<82hmqYjtK7^L6uV<7Xo!{s%Cq~-3 zN=Z=#>)ErucIwmJ%LyRb0T>bz7@rV}*<811p)H{RCx`u>`02{Y^oXE_UoYxkwKdNbwy^**xR(QPCaO!Q`;7#b!n zKPVGLwfy@8@AB5Xe;EK2@f^)x|CYipFG`Zh%>9d1=#dtI{}Js~r#={87IUbXAAXaF zMCpX^)M4RO0i!cRghgb!ZtCYki~U53Fa;k-Wl7!8nHDf{<9Pqt3=3h5K<53N!I@s* zyG87&B~E0oBHzyqF3}gf_ikhO?D98hO5-5%z Qg1|b!eT<9`x7=JTNo5Cr=z#| zOsoYNm!rbKuS-QU^(h2r-H;f6;zh86nYbufWsupM7ZE?q>Wf2&um3u?;j#hPecM$# z>_}FCLZj(5?dSo|d-KC=ms+#vSpm}bYzq+{u{sq|U>_5Er*n>Q3aK(_O$prWLMHyj+F z-^0agrchqF%01m~iuQU?$>n?QB5HonO}DkAUXCZ?XUi^>FtD4!QnkQ_l)5zyLw+3v zk_@x~Q5_s-grY`Z$|MJBIWO+sm}XhJ(oup`$AJ?W?1?efp68P}S@FqN{$_ZC4#Zp& zZ`tLQ!$L;={S|(y`F$Lo-20nj%ZFdeqx-HqT=b@6l972NFSC?UORq#RVMFw*FXRR= zYZrn4_$LBs6HRK?-j}={dBOpYvxm^r(3v6W61lqT61-#TPpR#--n+{w(o3Eliv(ciKkjc;Ro48_+ zh~&rcTI8X(XokRBR=;O0ZV7L?l=Js7JIBBAnJrtu{Ix63O2)4p9#7j)#j^7y_dYvA zSaKqdOI~u1$fP++*b+v8%};R;H-8IoXRTvj{7s{mDnQh z4yvQsBC9Ca(IZ_JBDr-Ve@Ikjsy-~6e!9cz8 zQ`!yKr9`nPy8=@lA{_Qm{!;)-Do$isxanPt__jQzOm0&vBYi-f8qA+Tu)1~Xy0*q+ zJD8OrCNCQd3(+EHz=AlB0w4;&efW&{S4&<(SJ_r;z=jBmn%HDPLCin?oI#sXfZ*!IAAY=^yN_MkRb2j_r4O==hg`$`Mg`z?W6O|$s zIS@bj#BpDfLUXK;e z^Rhfp<5%ko-{7^6iK@uRDlP%~0OFXRl`iRY z9bv#+!nrwY>!5__X=rfmOq1D8ihflEb33>2v_5oHT$)dlY%y7RL4QF=|7Q+R@D4`l zWV{YfN|yu>wvJj(FkWmuX3WFzUG81)6ZYMss6@^jYWV3Y-z@`kWeotm!-%;}FM^oD zjVhs0c~<-JXD^*YExU*B$~k9$CXti$Qh52>3Sj>FHNhcq(SJ4g8_8=OlK#p1tISpn zyq*2Hy?BER=qmEb@3Fu@u9&tCaMd~-9$tE6l_WXvm-yY}OxU522dYi@C;G)@sXw7B zL5RTr93u2+<75t>PpQYiL3dj(+HL)d4=s3^Pxn}H{9L)sfm&qheH!B}VR3~kkoNk= zrMNHv2(_oa6eqr}DFV#BQze$B9d@5SctxiBB=RO=W`=iC7nyXleeyq-kJ;hUf`R;k z^ySOJ3wY%WvRLe|8p%8JfP;nv5JW$p)laF6=xbP9;i%)YO7%(gYe~X<@xxOkS>I33 z1e|7MJH1Pf_8SD<>!!@3s+M$3GblPw-#mSpko$4f6g#5rTKC8w`$F46s5UG2cUwX_ z(&>x-wTELbvmnr5ysDVBS&dPiXC8BX&7|XZ zLSjBPX`o{HP0$DeDGHHalSZHy$1NJxKMydnF_Y=<$|;luRBQU&_u(jO-04+kaLprT zL01CV2s6j0ORTQaX-iYz)3EfcQGNIe}zqcQZyI1U09-p{1b&bxC}r4bY8W z<=nnQQbGR*;t+S_$9G?eOS?oQA=y@UPJ6N4kQrJnV1)B%NWb~D)0E?+ITqXckp1)A zTTAj;EN_L)!?Hw!^jGk#uESKkwcO#1EUCSf5dD2abBo12Q`l+^tIf_#HiQrV!g%3h zl#=A&nK@CO1)GIQXpaCM!NZKaC{2Pc! zj}bcB0PXbGcciAso27A$T;Q>A6c>WqHxu9_?lT7VPa7WooWN|10IV{z+OG+u_q0id zM6WfnQ9{ZM^f%*#2}cxYqG*2Z6fw~hIn(PTxZoH9VVZX{;n4$*3m?@} z=T94#NCNO{Pq}_k2E||)Dl1PVM}M{dm_oZgJUGCSt5Ajh16aSYZ~LZt%2lNh#~-xVyXC z8~VSW=epic&lkc;&d!I)!Pw-!UcvqjfgAe zegiy*UqSe81<(iUPgUEH%%X~MxD2B6^|Ylo9B_XscCbQ(H$w}I6?>EUUkBLlLaF-{ z3}98i%o!@~Xx?2ib$q}hGBR`ra3iusVyrmaa34$NS97_*G2(x&>3vv&bC6EVm6&Ww z7RI?xSE1BOM@{g^n}`ogAJ`Y*^1jqMSKk1>7DCM5+X)*pQeb^+TwN=JDuO<_@|B(W zlr1rZCp#UAb)~EgoA`KMnyh+>PtuF49DgaTX~RGF!IGuK?_ngD3Z$D6iQ;V+>mmW= zFLfHIJF**tb6hfb$#L0fWDFFUTS0G*OJSJCuyg0lKeNh`E_CrSn>Br{`4us?%z)S- zw&v^p!QaZmzU!-`jLllO1JIu-YUugWQHx4~oAu3|cRqf(|H>VJH)>6E9CDqWU@_xT zLBmxAM(-DdrZV%J(qIfqcnKF0oA>$@@%5|gswSlT5})Rv(~V9%1FpB&!*GV$-o=wC z(C!@%tA<)>w9EP6+WUQE2Z-)Lg_~rEe_lKrA~wf&HN@@>LFi$<`)>5)wzG@jFH9kPpJG*#7L#E(jlG{ZE}-Z2uF%z8AYC~Cg2 zsj3)b#ejP)YUBavw`DMTm9uump5}JwmCL|l67w6T$iLoClGfZAb9v!AiIe$}6W73J z11?@C%2z9WR6x*Qg*Z;jFiIW@;4_pJ>fLHznxNw4H8pwoqghpMk2?)Sk2awNe46mX zf86=gp@e|7uE<@sE|+82f!MbE#VsAZz$k|*;9bz5e<&cN@#t%Z!zqEE@)T~eCo4*` zzbcu&Rk0gX*>WGEU)9U4cc*o!+%M9X%m`=tVd)NdwQoLY zlh-=u4zTl(4m!uiA!Uq)izqszf#pKTf`Yo~j3Ut7SlU!UcD68}LH&+5GbgYE?`)G! zIs>?bJ!MyvqT@(L_BJDbRCxhkEtLwDTes>jZ*SM9TWj(!K}+PM&+YRh?@L*lYrGEh zmcc!>*dgl)n7fw{3%?@3g}+P)>b#;XYZodyYQFZElDOm5Mp@@QcPqV1d{j}I0z*v7(0wt#x6VV7NCz9vV0lyB{}1nbLptQ>|q>#3jzZ;H_R+w$6`^R0JTq<{o1~c z&g2&S!O_-7i~nNCE(Ik)CMNjY-Bp<%^&VN(r2Zbj&g@4Wvwgi~qmEEpCj@Eec_^Hk zepg1KNi6=E>cfeALc!Ufx{K{hBD0jf@rAV*!o*tUwbmI8a5HFk7rIv#E438zOH0=6 z?yVHoD10@^=AU%#zTk%hN*imTKQgG?V=wGNZwRemyP>I!1+o0UX3M@jfTWfRjzC2QFWLP;6PE>DBBY5CW2-a z%f|D?e;5}(M?G&aXGmO96=_~S`H%xvyA4$&=RBRH^=?FR@w%bz(&jTHu>k%=RZF?o zEAlImLM|!()f4I`*1T&ZqqraK%v62|wFK87-JQ?fAbG1=!(jA*76fR6BjQ(hqF^QJ ztm$a32!!L}qxK-jnI6mdE{h=E{HuUr_E6mxLI-BIaAORonx5NVWxn5p2qTabtKsS+ zQ04?}Kd|9ESl9S5HtNylbkp8imcN-(TuJ#O+Li#TXl>^@l-@~lI&?~%-^Th@ftDKG z$t!q66QBI(PQ6Ahu3myR(xVUAJWw5BWQr*IQfpk#3nz2l{38@!F*_NTi%u4mf{T^e zxx;6FNMTzmpDf90-6=>$Cuiu*(hGjTc(Et%s>H)^`hAC-H!-5ad+KPew>fc2!Hv3O zS%!+pL;k(e1;$^wn68pJ(7`0?CHvAZ(C?N2ShbS zyOq1hBSrG{SvrE(WoeI5t3%rGhB<2UlgW`*TXGH(Zf?F&B}PH?G`#5EbETqiok7G8^(mdl z^4Y1vDXVIxFUL;~8#O>PB^FAfifmI_jF*DjC;|KKC%mXrT6f$>_y!!yFyYvNg_ty) zQm{%lIhc9klTMobhFn&B2_K3$2;ABdq@EXD!MWxo!HY}TIdJIxw7R3hy$H3ilG|>G zhzJg@yA1I~9;ZbkvF237=3R0!secf;dhq?N?=~l~=f# z=&1NK&{Y2PQ~BZoA_9vd^Mp@~W7&3OymMF=veF}pzm8?j-fUUBTN*8~&9{PSO%td8 zAD5z13x_fmftmd9w9_fWZgKmG>0g9`aAq)3>J_-H9r#0ZAr zZ8jA}QNmp#rnJRsh+jTCHgO8BcArC1XU=FkYDm9wB9W?H?+B>%NE#tqkUGVhaF$cJ zcZu6c##ZAg;-szy=jmG+$wKYBR(c&>>5YNezo(`aR19Doi%5+!MAQ0Q+FU9XD>xTa z@&n#w4;T`~7a|7vWi$S=;`p(|fjB~E#3lxxv&zJA)HqHILM2X3>YWiICJ78GX`49OoEp&%4>9z2x{*<9q7iRhGI{m;Ks<5U>6pxsL?DAR@%z&GD0+Wg z$ndhwraJbSer?&&hZGhxv~P*$thOvR3c>vSe+e-ooOzgy0$Ex?#_8&dpOwEVw9C2y z&=bLzj4V?0pFS;Ya>=i|Ba&>iy+kY=&ox2vc**J?h+`D8z+HQsslb4G_rJw_Nb^#a z@olz@_ibsSvrVBVM~W@q7pAr90;1Y7v(H76-F`0|l66bnu2p{Uv3(cO^{B=9CzFQt zZEksz=64uGA#Gpo7;Y6NNg}uLXyHqUs;Pe2-m#cEdBM_G(Q&{`l9i-R^p{-VG*BQf z%*%FuTfys7qg}+<{Q!q~z{t$?mymXT(DfuulubttEHgEK3Cn-YI~qMW@D?ds3iz47 zXOM&e@)Xa$lB2ZN@FV08FI#J9CE_5%G89Xjg(gqvfA;`b#^l(g3B!Pc!=j^|4LH|} zBbbqQC{=|{(hSWf%durqXYatzdZ8jE|J$FVwxphsZe*ma>2is>{I)Sfc%kQ+du#kb zGU_?4vEci5+4;Wo!IREwcemMK6APOSOP$3;WA)QPn13{}IX#8+3mZ;thpwxiEZ|5A zLPEU{SHP(D)P>8(8!2tD@qi&MJ6ONw!O)WN4&7TUQC-f%T{Y~RSCxm!f=zG98v~$u z-AH&T`ft522BM7$4~E|D^|eAfqKUB!+=>1@YkiqIhr8=pZ=yxn1X`j6P85)O`GiyD z#*ODx;EE(Q6qqmUCq$qtMcM4@{Nh5qAJIDQO`E~$8adf(j2O9TN)R|>#XHuoxl5&> zQI&(;pxEY*)nwudQ1~F?My86PFpgHPQVq@W0qQ7BgQ~u2V79c>mX}+oF)#1ynd>4x zpXma%U2E^kVPa@vm4h#fhAeb<-Dx=-R#Ge+(jGrDauKeqESjbiu7-dK5A(@swkvv@nPqZ>K%b|EX z?Vv_{)B?`Um0>X=!V~Ipned3>Wk|523i707GDRlFOIizvJ>4e`Bv-o?Eyy@wn!77U z3%Jf@Pg7;DUl!s!B)KIH8NU4;^^SJKs>4_o6IOhl(Gjw_%()tcmC4MH?~8aJ{9udw zhU7QQ)=xJ@4yh38eNq0s!B*6$v3onnT{7e5oX zBHHlKf9U+$N}Jb=C~_~g-cr!dkH4|YMTUBmGr1B}c=qiVNyDq9e{cr8(tbrOPmyDP zvvcAzZTRuOP=K`ZQY%MKJ}pk;x`$;!#mfcz`Z2Sk_-3k$9`gi>dCy{C``&K^$aLNi z$I8eC;21WeB%rB>XF(~2wiN{Lxk>PPO_(&2Ky~wol z0#s?yjEu?z9{J9xUQoBZj0R`yG`Mp0Wo1)tpV0I&KjjG&ta$+H;%`(p6P+g+s`DT4 z15)WGyta}yB;b)02w1FsYUFt7xB`dw34kZ274rAs*GPT+)DurE<2<-E(lp{f2NhU!@OlNXA+WieyDb; z5Drs`>r7T#xai$~<7D7dcd5tQj=;tI&O(%cOuep0)913>`1IFq9c%7+Y2f)xcs^#v z|AHn5RWQ8(zGJmfvJ;;qn%$aVBjtc92WK~Y{zA=vuAC~S0fn|>w1J zM8tsMyDPgeMi0@$&*zoxmQ(9_{mlE5vFhd4v8cMuOwnjxyYrt^KaL;~?{bx-3!bo& z-A(MCd$AWKpT<2T4b>NE4oW9s&*m*BOQv3u&Iw=SPLsXd13Evqdk8!{B zOH7op#F&Q~`9hMwA^K5qJ-EA|A5EZfXAX&ATY?q7)v*2HX~@@7OA|V0@h8Z=C;j^X z>2Gr^8)GYlF8*Nyb<&D+7`l_w?-mOWPYVsm?jlZarqxOj3t7;$KGI0=!i3;W_G;dY z-oQ=R_A=pqOM)Z5b6*oL%l&GgDBZCg8ONq5Q>zc*S*{C1Si#zzUO1B4og+!h3l8U) zQ{RfUd`Uqf52uvmXIl3>sb{z{5!gwfV|JY8pjhF0SZrtjlwIZSX3;kJwJ6h86i5jx z4aneeHy7?9X7KovzUkR}Qid4)+mGGS%(8aoEQd2R5K&8q(_jK)Pev7OJ73@)yNBtD zVYE@<_o@L=&4pHzdDzPaAf4!jnPOYmFAU-8q@L~`4!oRnlqRd{q$a9~n8=ox&9f#6o4xmm@w1>j>vK*h? z5sRSxV-BoR9%5433mU?@_B5N;H=Fd3{g6}g1NZwiHb4}hoC#4ff8sOim2qj5G^sn{ zR~MEt8AXRz(J*XsjEV;JQqP1J-xm!JX*pZ)MvS4+P}<8LO07@^Xwf zWg>)$FO~m3`W!$p(zI2<+ly|reqZ3I|(9#z_;B}>Y|d_Vko((NuNvXBHwvwgxFR63XDj#tFrmq*GVHmAFa?G zDJ$^2+^`MI;B~T@DlO7dtt;|g9@&0|G=d6j7GVW7AC8_k(fgO}z6_Qz21_affHMmZ zgr)bZ1uSkd(_Dl0Y$RUeeLZFF+elpZwX^v?qFvsS$hS3o=rjzNEFR=;A9v?3Gk<4j zj$h~S3n{0~V0u7{XjjviN+rNHPgDNUEvQ0wA_+;mK+MbGVTc|A_NEChJ{0h(T7l}k zxzu`q(JZ}b`S2As=Rc% z9;Nxw27{hgCK7&|jz1y?o6|2EZy}$gpRvced(C$=ibuBfc@rz78}da@Y5Axc#`b{i z=SoLj19{d8P$rfXQ^(_*81x5nChLT@Nk_%fxQ^ z$a-9Yt_0iob7&k3&^LHU$xbQykMd&+Kb1(FOtH)X0~hNAB{w#r8yMjQhva#bI`y-SbP& z?GXjfdqJ9dZWqK8a5KT^Zp-dQFm`39W~32JP3CjrS#xd(FPX^QOz3CgqBi7t=+2*> zD5kv(InTKmJIcpDNh3%VR8eSNxyRDPnc7#)XAPM6-d1i(?wbPZ@V2(_-$`2yrDUs{ z>^7L{m+b=8Trd-qL4bSY{R24xA??Xl>SH?sAR6iIkvoyS+GsE+wG>#j4uJAFvkhH?z-G4Fkwu=e-u{q+fsxLLDM%lRVEMn zqL_xvkzsc5nr;VpaIAvpsmr$j!E+if-|JOz%oo)Z^!TGyT9166uYKzwQ~`QY{D7N& z|7V1tZ29L<;!o&s^T_T^)xQ1wyCY!C56#+7ThTT3qBD+w5W(5lZLO&a^D+0FB2zHYMw>B`Qzz@JBro7!09 zbg`l%ZIS2x+p%@~Rhx&A=`8DlMc(G4EyQEFC3s=oXcx$<&TqH)kp3HFpWo=4TJ5dH zac1h~$UQ#qEvZppe_g`z@e@ogRpuotk9p>0*Jl}ZuT6&{F*LlM5|ZP7iAV!yDH`5i zCR&g`AP$4G$&A&^&m?6bW;u%&E$JXq;JI61 zA=H>JJ#)^%S#L3=-r8(F!O1dJ5VJl5Y4B?F%8`#pnig7#s~4SzV1ylU#(Sj2!sAgSMtztnnVv-+e~ybr?;mb^HUTl5+_1p22o?*a#F4_X>0?D}dM!G3$# zA83uDDyMIG@jd_A7HsVT?>x3IFX#a={zUDhmwRuM7X}YW8a*6(s!FkaK|Tk#2lpKZ zydFYL0gBty^S1I=f|lUqM>kWQQQ{Q&JS$14)ZWJ_(#LwP1z^vg`^pbo>mHR6>d=Qe z%ckaM*ZX)7+q{X}Xi3PbfZ{;)^s_cJNj=#j2e=WeT0vFjNcY+REM4TKAK+nw?@MB^ zW5hcBv;v9rI%&x4rTKa4IzWn*=WkMN-Oq7Niq4w==K0)R(W;S+i%<=gwrBt-0`f(B zp?;Ekz%;M3Xtxme&&GB8^0Yg6{?658lDYCGH|Jn^+T^Ad9}T$JK&7qqY%xO@F7UO23+IybuNSUM3$R9XluMWD3y%MXU*bvP%NbASF4-`rV?`E zEqR3US8Om7c?M;`p9LOIDgVM1i8Su^2jREL%kfJg5$;eTrkyXg6Vt~~u(Y3go?^-4 z6nl*P#_@%gxHec?!=KDvrJXPF^4@lMtJ!GnX7e26(Kn3}NKDl={IqxGQ~z)%6GNLp zd_P?5?e%ov#OUyhIA1V^VRVH8< zp%VIg0{;VFpBKjwISU+igk3f8cWBm4XaTZwsR*!aXqV5Mkt@aoqcUi)vJZMcgIW{F z-EK8c5{;Sf_VlDe&V;HQ>hRbPSk$I?l>75$mgxhF9`g55wu;T*X}Na~n%So1c-xZDMiB_-lsAcCEtud=(V82Ydn?ov`OT1M|xh zpYd0~^HX(N2E9;kM>T6!c;*F&qm{=rJ}yT_fLRtg3?0 zr#E_NIJC=GdD|4Czmq{i({yrRzwOJ=RQWkaKvWL7()ao;n@Q?86{Wwe3RX=-Fe6Tl z*lJMk4w+tOUSElRMd1@0{3@zdt=!v^7e5*1=r{si?_SGxaL$tx;O60czevIY)p{jo zy{_aqiOuluF^|u9yooM*w7(m;Y7y+%4y7%!`8ff3uY6dae9M=4vq{A^_y|(bfEeeL z$O=kx2F_&6<4B-@MF{xjBEYB?oR;{HiN+#lK-uKOz>MeZD+TiAy2XV~{n-V~UD+du zeStFT{8H^i#^a7nlPFv8sA0UHkm-q6t23I~T=3(G+g?1bNUciWkcyuOn-3Pns?*?T z)`}^4;2|Q{jn#Jc^n5?UvBTBS5l33Izd9esk`>bI0xp?^6-9;@i`tuDy!hZR-nkaC zv?YWjVf8i}Mu^c1Tw4u##uA{1WphxNhCKJ)s)89Fa2|ymNJEE>?Q|pyfuh7F(%@!Vsy2AwP$wt&n^&^5&ym$ z1lxKO)^_CSI}f=@2!k>Q4yRuz-}`_D5M^@&aBn%eq7q zCLFcTLRuNFC=xrfG_Ce}p-}x@QCjNE-mrC!T*28XmsO$Z1<<_qu_@!>$jl41t7d=~ z^wO;fkz=4dlUa>AOKLuVxgW(UmG}*1?&Gz5=^V7gUse zVgdznd00DLGfJ4(EBUGM#L*^P8$|m(utm>A8SkAq%oc+EPk)!o1f}fM(|t^*eUYar({;XZ4U^mi0V*~JqI9k zSVt{pajLIdFWl9*DEg4CSi7!$a1NpBiLn-P=?JEmQDP`F02sDHL_;~&|$?(So?_)L-)Dns8@6J$NkzvAF=*_TGUoFd(3*)N?6FCGv{BhPng}l1D zJARC=E#Ph4)U-S&7jFgs%TRQTEwd_e|wsx$z_ekRK+AiNXovC=-=Cs;3;2kMHwe z{gp8>nGYc*54rtI!nX;YembsI800AtYBI&UPsPiGB!oTqxOWz58$Uv9cH%GV9SRmf`;zpk`hYCgAG; zOZUO}`t-Sq*JB)Q<$5xF3b9pZhHz5ZAp2lld6+HtZ7ju+~{ncjLP-E%9A-=wr*DoMHSpy^_&qCp^1suxf9CG(i=Yr zi?Ds6SH#Ru`!N`juX1WK&5{9q^5t=X7V#rCaY`I0`f|;;D5Ifq1+SiW+K*s?Q6D~z zjqu@}yA)=sSiH+qUYFF%S78flf3iA%GI_M*C9h@ysLz;I%(M0+a}IJg>rxSznMv$n zko!$l)yC|S%9J{C_y5>Ai@3)Er?40-W+MoQhCEbx3bHmT|71({Rl z1bv!Vh%)tSAN8mCE5juIZh^4#iKs{Mq{XMV=F14b!+B4zo--^wMb1a}*qw8c`SKtJ zV|F{rA~s>%bFX+~^8OSP45l|3ZE)Auu8|bq`BFk7;Zu+e>bKcyo-LolYsw^N1hk4kWt*9|L+8c#4W}*MDW5m{ zrC|Jatfz=z%7_=IVKsO}s~psORrP2YRZOrIOmKyaj;GA@=Lr)M#WK{!#D08fDiokI zVCd=y{JU_~W%W1GMIb=^#^!|Ba4g)+=16z$%G1Rd!K$oPgVvxeGpN9#-^tKzTzt zpod&$Q_{x=%{w$a*H>v#v=t|*#;!BA5XYVrYfx(0>tLU!Geoigor&B4MvVqaxxv~lOditu+eFkv&8 z9m+_^y}53(JexFfn^kVa(4)w#H`m$F$`Bk?z9IQdbJPyg*{M#zC4PF_pv(guES;>} zb_;qddY|Ymp$fTvrlhQ7Yo&)ud??5J$^_>V=HM_-ZE7R77wlwwS(4I0CUeiEVHSgF zoH3vE=VHqsI|L(1`oruM@<$0RLuY1Gkr1Y0{E%aTN$AkiQTlgX6dMw5y%L9yv9Q$< zX)A9WYhPUC9Ys`Ju;ftA(^^VE)sLt*(=-L=uqdge$MJ)t`iL4hk|E)%kN4ra(5Vxk z%6jIOVwswSVxp@blOtFUF?uXFlC>3QxasU0a3s`F7(P$G%taO)Rvc*MWH=vSsHmGf zh(WoATvB+i{o&!6S`H~}I`ms;-GWqr-}ZeDk}ewW&-XY7Px>;<9hS5V%h^lUwZ%$X zXS4gqBZnG@wZ#GbXe7*uRaJ)tde^$#hIT3g10AQY5Y*X>p617}A|F^X)Tem|qgAO| zhOsAbNC`Q}q}i4!c?lUlX(KuE?s&R)#S{c!;_sg}{kdIxYw$*OP>CXmo~U62Fgh=ZBd_i6_4_|3E#{I5tcl8UX8e4KYB?NJ zF4Ymq!TbC*h_=7X9+8}Bh>EuMrrf0Ht4b9M;%MtUy*~a(uzr4t+>M0T%HM^5nZ0b? zn6u%S)+ldxdS~VFl#k#JAZuN6>;=|9; zmNl=?TE)HHQ(pX94hL=26%V~ zP+o?WhYipin@;)Dt-yQldk}D}X5o!9$B5E2aV5XWKUvc{_{$K3D+89qUDl@I+v_r1 z0R% zV*gi<{&f~kxn9RmK{h#;I@_s61s@fK^IDeMr4!&4S-`HV@9n)fEM#rj`h374RqcP$ zP3JV1!>OM8)_T~8m1$zh8SrecdM{mPq(ox5FUly!33Ej)IM_aa94QRoznB=D);AR=1Pq#->pgCT=&6#|kle10w zh9!0s^N!z@O49+$p=24n4}^yloyBwSjq8Ygf^2i^bcR~(>+2p7lHFN)+D-)JHzblH z-*Eion(NLXc4pvI#E>SNoyHib^xGGhF_Fxmm80CEe3m3Jj;YmS!5MF4XlTi1`Ag*E zh|}79{SE&sEXwoXWOzjuT&KcD7V1d4#qE38EsKOp=xhy`zF@BDPXLLTM%A+NcxIQG)rFm@OW0&+MaZ1i%xU) zjh0;GSq}d>OG@mqoGN>&k>k@uD%-vB1&^NPj}-Lst|HY670RI9gRctF=M)`IU!*rHLgeq+&5N|%-Csr-np$m7qCOPmrzNBJR z;?;D~oa#G!vg;EEO4sb+LQE4kAC1m$IILXG4%J-X*MFWH!6)W8G=8%qq-ORCgO6=c zg_)jg+)4-F!3a%haFHn~^tagg+vhi0rDC6{e?K&^1n6kZrME&(eh;g{KhuvxGW+e~ z?D+7TIBctT(3}7^1sl$QEeBbT17I&}vaHmT=DW|6^`3@l`unr3LiNuL6i-y^8qrH> z0kdU<=M_;{i%9&}9RaOZhh`L@)TNS`bDgcSYPNZ=d>1zTur*8U^yt9WSw$C6%IB_r z_-6`3*qPl`XTU2Tj&m2LJe4*!)7i%+5?Z6$Y8A?c-`YJm>(u4jPfshw^|RjAJ*(%J zfQ1twgo$v?4bw+!2M6z~5G1|vVh7gwN$+Rdok({la$!EC)?jt0bk^Sip4~3aH1&$( z6K^Fxe5eL`!a!*1n&#aOa0N8$>|ws;L;6WEL`16UN0SkRhGr%TIUJna5xhv^OzH21 zB}i3Ee?U|-vP|I#UvBSky(OF+HF!{<&UA5?_6^i#hIvfrPyoNiEJ^{jZy$|xnB#O& z&qEjF!xI6BIel=ts7x-bC~^X*GGIb%*52CuQ6w`JI$tUfn{Lw@zLvVH;vay-@}yKybYrX*mo-I|+^x<Lq5;pL6+d(dFtXvz_Y>K6_GzV#nRxNEU<&It_F9*QC5n5N^8d#GD`5&H(pHQd^bqBf>uVbW5z8CM@Sg zTv|Vzyzp%FT%4%e)Jhe~K3dn>g$%AH{ZTgk;LfPu?kr^RKdZrVuoo^R9p28caP>#A zirZ0sO3j|4)!>je3+D397|P7n0n(tiyVA#0`8HMNd<Y>MU4T-|a`L`*L2et+xYX;s5?gbAM zpVfL_Ue_+BLL0{jS)r*SrPaLnxVjP7?$0GvUtJ5}V-WPBK-s(o?XEPOlTc9>M*p+R z$K-;1VpboHrU2Ic6HC~MVSX11M|J}qKw#(Vtw_aaq@$w@h&pW&OtH}n?!ThfW}htH zV07@%AW@7JpYh^nUiV#>)3mCfcr9V#AlbE@dKi=<%Lw#>N?WIyFMs#AGv#Zrn^^F`oAGXqv~w0+s+V0Svkh}oRnuNjSy{j zPVQoG)t5!G`kJbtVgnUIM)ytPN%(lIcuxj{!YwvzCPxqLZIiO_5{h>@0(~LL-duSC zGi9!Kuh8C8V=;kz#gsW-YBY^nUiReINr=xWUq5&*8C&^#gr#r_A+*RD-T9+Y$asuc zQ=j^)v=i~EuSA86TVi2vMJyv2ejc_7*+rUm7aPs6h6Ytc5 zlJ5=EU2+mR{*LdaC!zcszf_>Eigc&=3qee;i<8wCR~N%-Z8$;_TPm@LQvIznAlGe2 zd#qK~i8NXhqLrD ze;ff4PRW>5C748iT1?cdpxKjxkEG+LclRW3v-n z>fUI*{v+DU=VH?3HvFvb+b_BUWA4UoPg@}N9J9~)OChl+kIHLdYH>xG+rjDvZ8!JS zeo7!qtIVnpn`WN=gZRK0%Pa~vgM=aw`*_<$4fa??_x6dL{^yEn4VhPRnE^J*V_PZk!j>j~t;7;}1qT9S+39BXWCiR3 z77DL+F}H{)Vrj!)OvZ!G#WIq29D+M8+k5Gf2Ga~08o16F#&XgJ$kWF=#GfhC@!m1= zPjdmIdgoj*m_AHT%yJ|wO+kn_py@7bG!*W6*pAzl}hG!Xt}uOvri zsCy{3^0B0@9TnH=Zf^}TJp8!UsX4>7setFi&uMF-OQu##-Yopb0mbE#^P{Jf6BUi0 z=R0x&{#A9wkDJ`8^dF&!Z*9!gYck3!;AJi;;-;;+6?nGuxIv5j7C_efjnPQ19a@oZ z32y|?iV$3z6AqD;AFnexDtP_DhS{W5TSb(b!?VoyNMs4kNzQl2ea?y{?4$1JPKRc4 zY~#Od{XdEnz1{*59|-0qAzQ$4w-HcI(HAmyORiiV1$z1v`;L@mD7B(_3^u znq2Qpqt!PCxfVYZtzqlZYivddDbWr|-9Q?&2chf(?H)UxSFc)SzKRJ0(bDb$KjD3R z$0;i%>if%3RA*jOCE^p}$l|AX)Swtd{he+eYf-M6D;f)$)l6+Jn1k~UEy2srosvfB zB$kjeQVyHZxmA}cH;T0~Hl~}t&_7Knc#kk}65*#VWv<(w=QG7?rKw7E=L|(M49d>| z1|5N)=mT^PHK*8T9*cBkr0}y~>~EP>e7CN3Al}o3Oyl5i#B>4~0)Jz|aB8c;1LwzE z+Wa&UH@)F8f8QANoKzP|8tNcjd=mlqMmHl+Lsg#8+Qibk> zWy+Vd4f>V|Bj?vvh6iI?ioBl1STv?7s#=4V5z~tyFvhTu*KjLVW7-+|6B|jsLL8Y9 zA;FCejFxT-OSs}%y%p&tH7uqtuu7o5*uR92t_3WRntis1e+FwO`{35076h z%MzO(0uw8STNo+sP`lB^csZWH_oaDJm;N+Cv4a7;$wUWAEi&a)C-bFY1npHS-kl=s zN^B_n*pZ=IDxM9N5QZ^`Oqp2SaL?<^5Qr@T2zik$uoJ!`80F;yC$13IBoGMOOC$0B zzkz;+D)19kz~Zu!>5@Z!-KoG!9!ts%yndHbhDsS2qw%jT4FO`4!oL>EJpWoG4Czn9J=)ZZ3U?X2(569bqT7|< z_);tCw)>OOoe4%;89rc9OI6Y^;vb!=N?6qT$PfX0K>kDzs!lKT-v1yl!cd%P?Wk(?^W7AtlGME3mgc0hJ)Pvo(1}B)9 zb@W@83idz17ZCLSX5@v}&~Ed}rp_qK)DIH>@%`DXaVC?f|A&eEJAt#C%cS(HFkL}P zPL-FAcoDB?n7#6~p>&$8ki&vPhOXl-VN}VUhS5QgQ2NvD7`5b=Lj8=?uK$S9sO5)Q zV-L8?*`&DLaXsITm@b-y<4#|dxOSMy6Z4%V3)aBTneYbZL-@^mP~_G6&+$27K6zOH6ECF|kIc%MM$u9(*UZlcWk zfIUy0-%O_>Pv)?4e%x~MHDmNghfU+&1!#9q$I z`ncr|E~BC_*lVrPA-&5ioQyD)?!V5l5H7>@P?dF)qs!pG8}$MSJr4-JRbukk`x)Mf z9Gg30k^Y}BxqZa+wG!y$Xq%sJ11xZLy)KQ^z5dd_+cV*&0Ah9Uge_A3ACl}_KdcE= zbmPCSOOWZzx*c%{`o+-P-})TgToA8IQjBd!#(espSW>S!zM-GTk>abYy-}@cxn5`)f%2XAi3enriAGEZ~-X;u&G~0oidOH z8~yJw9v@A9XJ3g!&$0LI>m;Eyk{zx9FWX^Fmfd4ig|}Ny{|yYytAzbUn*6}N8#Zd6 zfHppR9?#eJroUUgr-Sw{uO(47o&OsgDKZTj=P$CMxEtU3n~d*_T7*4|iJB#niS_j2 z|F24XMx@jQq>ysd-6I~AntP}gkQjZ~E8t44hD*=3A5)vKQr$N8KXt1?N^Ak%8Uza6zR*Sv?{Io6Dme1y zAA2#m0bd(XEC4px1MjmQUbNM1`41Eyqxx{Y@dp{9Xwbi2j-l}nDVjC>YMAT}7w;5} zOP#x#!W<0ew&jPQl5vKypf#5MqVf_^<{o6z;#U6~Z>hN6s8w%Jzud^nE|{%f)dc8~ z#5}`zDE^dOZuvx%7&2;+MuPY+k2{=-*14RGmxu;(yh zIL(Rvlk<-W=wsDHOY}Zfa45$vCoN2|q&_M+tb%!L_7ptVajO=pj%|yM+!-Q5oH&NLF8LoO>8>MPUM+qeOmo}IUaRr-ba!(r@BVctFo4m} zmHU^4&_0&l2}-!-yXKEca-QpTl2JsE?tr;*Lv9w4J2$GPC`geOVtcx>+dvPNBt5gUmahDmDBNFVnKQ&jIN%2q zic~$*u!&e=0(4DyhxyzJ{td}kZY5n5F8;(njRqJ*YM34rp0-NtBr4F*jBUy3+~F0) zt}fIZ;&phk1WraEb+P|jAxn@stw1d+31s!mhRNYCR*^E7RMDC#z}Pv1$Q-ZZfmwxK z`?hG)T3EdDzH7&tQdLs!lVkr(Y>&6+^%U04%Y3ODp>S z&j|xQJ0uTWRgX&vsp-UAdkNGx-g759+hK2&@wY-vUgpB%|D8{zE>8`5T~2R1;$IJ6 zNyDUwG5j;&84{E6EDny|_4?DbNkY$n8#N9fH=oBtmsC4f zHiC-r0(CIz@4$p1Cc_k=WX@I9f2%?l;&3|a-TSg|qW;T&I_2Bc$(|z_#S_Ke+9K>x zJl|t_?e#8RJBpm=imP62PSMXfn23^=2Z9Km?31e;AW{SWX%v1QHbxZC1o6gp2%bLutS}UJ;r4V68G4~ z$9)S5^#MEtoKl3rgt3sT4Ko>j=hH^Mte-|O^!}ubcfFLQgF0v*VjWL}MjV^H@Zl#h zpJgYg^`C*jSco?~PIbEbJJAz;M>{-C^i#-gk!R%Ys=QP1A-`I8G{etzfbrklv%pXs zlXiQ}n%V?9kz-nZ+R2Xgu^XSMzFxhv6n(m2XA@~2#8XlI&@v-Xy3A!;UZ5lBwji{+ zVAVnMv&`HLwz;WwpRYyx{-KG*Q@JkkJBQ>yD?5ZiE>Dg-pzZM2pK|$2DnW(;=kowP z^j0fJBI4;|Swk&`p{JCreewsyV`0<(8Lay0j+m2Z2meSCm$#ryZ}s-R&)IwJwb$C`jN8DrQX)-(Le3nMAh5Ck@Au{?8zgq=TG7ls z!>hELZuBxeE4X_#q`u^GhYveyXSj)kq$k!Y^VGWz_8$Vl-YAO54*AZ%EK{S|ar>`Y zVZNG1{%)e!ttc&u*n}BXnv=F*WrpyLsAP8MHplaA|IjzaPWuTJ^w(pbh^ue$@7S&o zQLCf_ct@@u8wB`cY~UXy-!;3en3wekhg=k4$CN^`;1_*@o%`tvim8Kl>VY8B6coVO z;m^bX)avbtb{Nw&XuRPDasJB1B5}vz%EYd(?;HzOjOC-n6WXdMFcbwmF5&jQ&HH=2 zg>Xeel3~f{ug_C)%X4AO zKmd*X?j7u?$#U_y^}{}PyFNF-@reec)oc;e*@}k7_4p1ZT>U5uJq9zGf>m%3Nb;< z{Bq(gEGwCL!937&8fx0LV+g4bDOeHUy+N znuZ3JwjBB>6!0(;CFqvOv9s+XLgiZIy8n8#|Bu#D6z*CD7Qlht_oos6LM}0a0p6=dBp-K`fFtY=O7K9G_d|#xzl+~e zdPSo$mnDng_*p3X{_pqxYl6!w88cTASw~+41U9}Tk-^#wL8_a;3yR=f^Bk}w3SdLL zb$X@P4P9cX_UKFAV-0|`{*!IKFMS|qDT-=5!oC}G%M64FvF=YIoeyaEgLx=3a(TFs zjdwW65VYwFU|jvX_P*k@CD3ESVIxQ|eK!a`|z0Q3=vHM=&K zAd{*N6en}rH7>b@$H2bQ$TFJ4o_$_M3Ax2WrZ$sUa!j%8|!r6AZ8x+iKh0| zuz>bwXKJ@(?Dr_zrE)vRmLcKrPq8f^6rr{k=eE5SmY*m6ZlTJghI3Rma~P zujdu__}(?~i}uikuLCGN6hHnVS#^~IL~690LVkd?+vfXx+MjGhhXF`k7=5Bi-h6s#s2W?yLRMJFO zzWnIAS#j3X@A68c^Gx}Ms*6b}iu@OIopL+g^THcv7W_if}9U%kt^W(#oKk~PoJx*W1z5RFuq4CsjzwzI%v@2R1)5^y> z6A$J%L$8x1U#iFn^zCZYj!9N$w)_@z;#>IGj*4zK^nYg2ka z#Az!4T7E_S=u$jqUtVd-6-ACwn}biAc(RWT0yiZiGF(a*MBy9an}Wph6HghFeYANz zP*iOVmA0PP6yUXi<~*mP!ItQ&Pc-z+X6}QAr0m>H+7AyuuG8o7m?}+8T#`6N6{1CV zyxe5Uk}ewu&WnpDcN-(Htx>1oH^(0_cxx^-EUvGUnU%`ZFlqsU&Y6WA5K7gg3&8e> z13+>!Q!-T=d|KZ96PSG(s)=Tfr?j$uFPDH=hkbl*z8Z|`G*vboiAL3_{4QjG4^^7y%3xjSF^GlU^9^%m)7L36EA&Ra{vZALtN8w14^WaCTg{2BAv}%4M!~-?FHXBEpOb51evW;pzfT1WrCBmscjB5m z_kj4bgRpgK@nTbEFjiHWiLdU^|Jm(Ojw9qmwXB?0-zD!Ct8YLD(@&!k1*&lrVh=No z=jva4ehxw_ncN0FlpO`@h|F)Vymx(KQ4iEd;HEReVgCM}H*=iNr)S9|zK7|C?-jpz zpj7}uEN+e323wZFCDwHC7~R%~;{L_UbhY)P@LMMn3zkLb#B8n%Yjklnaj>RbyTZdF z+_<6rF-z1s8K(PjAC~pd?ksmp-nTwwo;C2pm+IhV}QacD>A6mQeZbNT8DT z&0Mttd@*ofcRS-V_JB~v@s88qC2Tt!>VaL2o)5iIJ5^d4aFrJBye+qZm~EXtiRLrO zVcZ^U)|3Y43I&)S;WaBjav7F z4sOqo4u?SpA`uBXWXEny^zwNlRu8ZZrpWE**>9HtnIe12-vOohB*AU7{$FT&B!=H- zOA+dNy#K14lJF5QrXu6^!2~mZF7EoMVGjA;z7)RY&`cvg-6Y67MEldJnuM9<7{C)# zL7zo)fQFlcs&S-*#KjN{?klQtOEE@|wKp7!h_c^pi3`vFP=(~Me4YYO z*8&c8_Rpvlmtr_l%Dk}Gn}6aX1l;GgFJZb^Q(e01ERH|R#wYl=@1I!aW92*o_Y536 ziWP}rbs3*C#xX$vUJVc{BEj#mwpXdz*@o?av+B^1BPy?JScOVAzMyyh!xzE;dX_Z| z)Jb~^(8-m$HFhwUSBR3gu)1X9(dR4hTAvI-9%Jp2m*W@5rC*;k|9Z$J2)U=@*omhh zE?Fp#x^8MKWOk`rhMd@DG4pooIjqbsUZ=W62KQu`d2G$TMP@P(wMwJXtSA-lzUnQ} zS3%vO-faZv2YQe8*y#$})DR`zCe;MiQc@|gGSgF@F@#P94HW{OD=`^otu>#vPBHbp zRN?Cb8$$_Ge}K=jKl%{H`YT(gzo`V%$}C)pbq?OVjwsP-JKWz6G-^&{C;a)aeM(rN zdSGK=ivAl=vl|6y6GD5GL4s@5D=O(jt8ueJD+!Dk9Gy(?W`WsSPJzkc%qL_NZp;)Lz}F5O-LIaf}%5`F^^K4l>2S)zgZ zQ$J+U{!^^wOTS|>tWqmP9Q5a+lVVXGo1z~6;?nrbmP(J$n*ZYD&@~l7EbUIjsVCwn z>-HAtR`T4PCX5ajDiIN`&?-Sj-p544oAht{aab|{mXbp7XS6!5QFrYFmD?tqs6YO)JNFMEY|x3h4D@4@`1N4n zMs@ezA^mw~spsE*hpr-olCvQFhm;IZDrT8IBLPq5O&W^$^{fYr{{Cj(WR%Je$LnQQ zBa%+J+BZ5_&vn_1zBE<$0(^j^Vu6?HIFUNU?L`#OrWL{?AMrg*w>-Ude|tNKxy&R% znDLxfsDLn15hsy*V1@IiQ=f+tHlbGFZIa}=arN=_v!eL9G8X20qGu=@}j>@*O(~4H&rK- zVmpgurLrKX^@YC zK%NTdG!{kKDS8{ee-?})PoufmHyOSgtsA{(b97hnbIuS?xp3-h7tRb+YM#v00oE^F z;FbD0=jms@fNx?gyt9kJUTHK5EUY7K@Dm4DzN)BhuX+X9i=0}%Zbs0!G!j&bZ)ZqL|0fQGFgm&kpzXrW-{cD7C&rrL?|SGC+Bq#u5MqCp=2 zHh3PCb^8`sIVA_|8jUmAXdI2;2_{hmP(#JRYeh7Nj}n5#YX=ep!GG52hRKEf3Kb1= zSVOEl3(&A>fYqA&C`{jWSgg&?otQ;Y5k;hf^(((?y*<>+~IjB2+q*8;q}W-RpH=0K6LbD{x8 zj_;po=_387jfK94f zs8?FH{Z^8&f`>bzEU03{@`F=EVlAt_ss6ygsPA;YY}z2b3;1@J1|JKvmLPU+{$1us`?~o0+_9j-g_#>QQsooC7Iaj2aMQeP$!VsDK5_V7L-at3mN5cdVXqy${tjg5hfROb)i~km7)%yX;&YhNn$g8 z8I`IXi)tdQzW<>}e_sfsY1w?JA9xA{I&5xq)t&p(0vk~)NQS_E(T(C2skr&x;v_~I z{2`ExBEG?$hLkn{c8*ZnX_)dkqIn% z&djQWtx5qv=ldK%&pcqAs^+J={1K_n2I_PrTls|R8ybKfW-P@4A{Zi+a=HW_D+=yC z&Kl&x!Kg>X_;scjQ%gND9iBl|p{d|uy4sTIJ9C+|jjOXpA zk}_O=nB>3;szIMxbR-wdUbz0E$h1$e?->SF?WnXvXG9Ah%9~Benhd zg??&eU&lN^qYvdkJ32(TDsn*7n}UG|V1T#&Yo8Z{ClPtJ;BAuGZT4p7U4X59jAlY?m_!pVC=^J;>u_{VR;{LHp3x!PY^8>!@Q_4iZbU+y*TNFU|Zt~-S1p`(Q z!Y$dDmJn0TUzTE6F<91H#pRpaOrYjrNq>0z77nT7kf?QCj?)YNKu!KFtA+EdCB@Zi z@UqWFgWez18V-PJ$I7hP4uQqzZmfCj4en)x?FF~&yG0S**!a;M?I21B!RE}fh!C6Q z&P^(XylEMCR~*Kd-#)^!j;)pMwuZbcZi61e9@PRo0UX&pir!6QGVnjEn~vFRt1n%k z&&#%0=u6rAzIt?ZFL4;Ht&rbtQlz-*EH3^9w`-=mOEDH(Y1wR-N)Ja&PvFyd48Yww$h zxLBC&eDuMmOhOTe;}zXBiD6Bw=B{iph75IU6Ynh~IY}QQm8p!K=RtFSFeo*DyC0J? zt^f(V71Kx~lr%}m)m=$E`s8uyr4{rOkK77f?Bvw0dl+s;KwhX#03||DJwM$05-*ilfY@a+% z%XGT%b@<55lr~2wY@U_l%704fs~voM-YL;4q)*-S=9{n08CRt|UwnsV&muKc1(wC0 zLHR>;?VOrlBcMmD&4Ec|J1;l@5jAY z>O0Y#b?`8J5vfGm`JFU<*K-9H-iHycR`cGGYZ`IdMj6T^%3+&VKT2qOe|n+>w0bN|@ahX~E>Drro@`ijh~u9O zS~mSy8Y=6flpd4MA*!XPQ3<%)qjszvW^Cj&)yWl&MJzyJQ@MF21Z@ex*pYT$oG z@WO;FWn8LVT&W||g|e(T;eM<;q&uVokguEXyeNA6{gDQJ4@T-tUhHnT6blslxK0IS zN<71pUNmD-AEBpJY4%ozZN0*u?Y{HQ7DS%%6nIQwkUMG=HJmIt|esEi?};jVQ$a>a@|x^f&_;f$Ieb=P;pD z_4AHDQ$Vl+!OSf=833A91k?W3t^LZ#9*ovxVEAYr-XAIU3wH?C_Rd8?LCxvEq;rW- zPo8XRv;QQ0)>LNn6iY2XPM*QTX@~*Fd=s)33DFVdkdJk5piC<{$8%m6z{Vj?v7rX7 z4feq_U9kmMnpTBJCACtEeZ*R6$wUM@Gv(R~XbnZwh>F@9WNbIu-T8!|D$_l$)ptgS zAAD18N;UC3uLTOEDtT|u&X!SfPot^=0qyJTfHN2wO;KW_qP(D{ihlnv5=uu}oi8vn z?7#z6H1A-N&p4eJUzjE3!je`EONtr3VC)jx?63gds=|tG3> zxWTC}-_&JdZJwQ{pIgVTj!(DrQ8VqS&rN_M9jQ+>W|ZKb^~_(hx;f-GWX^?+QFzdN z#O*m8s`7V{;s1mCU($O*SDuuFU}L|CQZDS6C+O{N*5t)o?%5WM8Aa$+1vq*xmkcG! z>?g_ODFZ-R%m*}2ayqRpTFX2a{eFB0ZEvOwU!Br|$S=@QEya(P7wR~{1g6*DF@W6a z0Ow+xgv~{mlDCzUgEtcb_J95Cl~QV1YCJ=EcHOqTi3IK@IE=+rr7^r5v%AzAVub~D zlqnn9;*XYJg3XE37;{ncmBmkwbfrB`{zN}MZul+M{W7J8dNn(lPCs5M!QL=)2s@<0 zcp1%H$b0n6w#N_n`_cIZCDAr3Yr@zzhtz#y6i-p}n_9#FSa&2&LNDnRw%02*%wuk}p=)4M25Fw4k_$n{E2 zy?I?bn}B!Zj&UP5E?afTHBnd+W@sT3cIvpPzwwYKV0V*cn)&dIt z?D)xbiq%Yj#1`BtBw(uq@^}M4eS=kf2kr2otc_r$d}c=aA>llO{R&!0shrG95%%hS z8u1$sL3VsVg{0eXE5*m9dy;2a`Y8ZK=}Y2heZbpAPFg(4&US?KT{E7+=AV)_&EOsH zKCy>GQgj7&TfQ#O)Su`UQTEn2YU@;<30@4HpR<0Cq`Ww9)T{dV41V(Nw`d_DusK%U z#Twr{+<^Y6V~rRxUH33&@<4R29GxI96QiaBX0AA*umw+J+6~6WwzXY9Un`Z6b}}>a z_UfSUfLU|VbAAV?pv?`vTN(!x`dpOoSZbF0$juyvU)&ni-)IezYBjaHlNyYLKCthd&!Eb6deYzS649sQ;ML`(32YTDtDE?b5BX+JDE-IrE zdbE@f?5dl3OEBWlv{y^1HOkG#Ip%9{w)KHAuZ&F+jC6GH^Mv~{j4l(8YUI4>1bAlQ z<#99}>uUg!j9g-HNRJe*Vk@9$-5e|G_LkDtuCiL$uiOep>At= zZ8lMPbn=0jA*g*a>-XH z4MqQ{xtuT|;#)>yC_DB@xjN7J>IeWqqJ=3O7ES_Bq2OYN!*gUVvpaiudClwldMv|F z4AvSR7~P$ET6Tmuuw&ACsvE?Cjwb5y09+7t@lhiNr8qZ=PqUu?nqx zWWI=bn#rv6`nUG-vs$Ih3M@ubqaTci9jiL&O1 z-tx_7g&p+aYOP_>B-SL{EabWxx<0sFflFUB0annkL($u_N4Xtv&F!{8xjymAV>POl z1vve~IvioyaT*hiu*zg10&e8!umEfBl;gP@A7!!5zIz`!82u$JxJomsog;%ckY^V@ ze1cQ|vf7zz!*4SzC>d0gsUoOU3q>ab?C^$o?+%o7vPHc(Rqo;`Bt5oK-EV_(u>T$x zX-XC&l&d%aPne`SY84bEG$>}NNNdOu;URkkm2+c}lyh}VHZaKSmUn;OPVhEzv`Mv& z0Dj=|Y{Sndbw@Q6qE}22%cT!$>taUU2@FLbuJV^+pVD~&(+PkLpZ$MzgzrleoGmua zW8#C2Fx^$9NXh6&6fxcDR~PhlcYW0)%~)h}6i`A@?%ulgx`HBsx%j#!T$RT0ptHfL zbT`xf@cQ8LPh;`1mgbQraIHK;ZW9vJ(lFTk{Og}}i?C*Jpo8E>1~4yKCVcdn<|CWf zR-lsulD>%}IGRH)YF4c_BJ*iVQcTpVQrXPXCWTVjnj|HgY{RX}WAc5#46_@znt7e- z?K;$&2H01eId2@0QVP*dOj=7{#E7S!^|R_me5KcSV%Up)%H=Iylv2ho^ToQ&#r1^) zew+VPc2{^;J%zgpdlb;!L{k%z!}$_Z*iKV#OJZ*)qDY+n^Gls!#xDq=NzadOFqfxF zvHKvIQu(jP*>r3T9J87QH+rahieM4$3MG%^JVKGe|k`ZR(M`LEUxYrSX#9nB6Pl~4Z@915}C7C(` zw{HtzKQ`w6TrS7BN>%@(2%6^dNc~0AZ?|*iJW65roRiGxbD%50=6p;!mQB=>xT}X7 zMbvSpc~+j1WUW2#z`yW)|MiQ#ZznDH)nA;t=GmlAz0N)xCQtTbMs>}^hW(<)B_+ZO z8$5vY9kK{J|Ke0$@?9$AM}h_#UeEiLRR8-2)RS@G0x6?sc@U_540vn2I7BUN7)gER zK3^X@S}XZI!uhc#?&;M_6NJ~e43qv{b9=bRw# zuA?S(NvAFD90yh(QJ0;mk|VLHK<lNIQv{U+zHVi&I@k&DqGFQk_CK;cTW&Ssv?)m6KKMN{G7zR zO0E90+?rgY<>qnA9So9Gs|f0k;?{ixy1OT7AIBv>#cfjn&+S@nQD7|e_);^Q#}(jF zH^0Ot&g{U4yBi*7RcZBH)?PLa;7!o(j#UU=N&&NuVc@fu=4zsO#UvXok#6nI))nTo zI1)GkUO;e)&C8OiSW`%2JEHf?d;wb z8tS-(#}Hz{U0uRLC6k5(oqMQ-uf&GFLO&Tw9<;X1IZ-f0_Zy5 zh9xP(IsIT^htcAq}gf$Dc#^89A__pfJqbApy za5Y0oQJKT2_(S2}lfohWprOoD4i;VidoBw{jdq8J#6kzpco5r`6Uz;%Kx{>yzwaO5dw7?8|P2C?l`P#%7Ol!&0oef*K zyUZ^q|MnlzR0|Mh8^MvXUNN*peTPCGgDs~QFd4|QY)AV3%k6fgQ9%64%Ph8;ZxsBX zxR7{A3K$oM6tQAPC?EHqA_^}X>`uL$oT^86!5z^_gQ3uH7WzeN?R?CxA7dyV;ODy; z`p)k=OBthVoyUlq4}0XXtnNX8^f4B7MG^D{TX_Diw0)53GpiGyyNq?gl7fo0Tmf(> za&h#Kuy2v!Y8*a67kE7JKRwy9(+F?bDDZwCRYFo?G)srS-olc%WjG%<9Qq%q8Hwrf zNV>!>r6+9wN&yvh6j|#&sL%#=mLS(-rcD$Hx*UfA-m z;;(uH=qR**3swXL(KqFMz8Iyn`Ol;gJ2~CY`gaZ)OT#l+XmLrWS}IBU4#}qb9`)w= z4yd13jJ1}iF9*jMcA^Cq%|EX4{}cQ$)U%AY+%YfL$k&#lFP*OiKzqcZoYrQA8NWX5 zbtNZLR8n!?M~hEE<3A$_Q`7-yu|{`6e^>7@ok9=hvmotzM>!^V;`eF^sh5YX^0gr8 z5&U{~`IAW{rGQOn{QTy-{qq`u9vJ)gzA=^rP-UM?DLVYZZ4`~%zK@K{YBQ|1t4s)f zAsAsp?U!wm1zskc?e<=*4@EB!a3~ZScKPX{h|s_P-BZ7mx#!R$WBv8E@`@ z1XGi8DWBgo$U`t?3bZt{eYV=GcRdu2gW#NzhxiwG2l-u@T7vs?A?)Q^f=CjFKKAmx z)80;J{K4b=^@7ddba_n^OxC=8-he+oZ&<}%QTA-q9Knx}FqYy`IP&Soqj$Yo&Z<^F;0GK%U$ z{#w@~W#X4xYaiwyJ2Yun->-uLF?8u1NO}xQq2%GfiQ2SoHo--y6&`slP@aELJ|Zjdg@KfoFJ# z?>e5302fcoO2=rqA$qzc9WARtcddZNUd2lSwnFSp;(>0iVeGc_{?5Y^Xa*3>?JRCc zp{0cZvzDXPT9wD-Z%47^S!w<~hXpYbq;s;HyY6et=i{Q_6T!LWFD2HN!R=7Y*Syn$ zt|jg8JhE7C3doNdZS&^neF);QAYoL@>#Uq@H=p0Zr=+{-mtxD(yJcA-{!d)zAdwQ6)}R zJ=X;}pyBj(nQR3RG8!}8%r&(l2C)pj7=JV`79?7F+t3Wfi($qlt?%mb$|?9RO24%@ z-u>IMd7ap-dufPv4A|z&Bb;=m&_Iv40NQ8=&KEL?4)J^lt)6)Eni87*|R4mGy z>n?Kw=Lbd>Uo{k_muX=Ur z@+SKRcgcU@iqGolcybVE=mNU+J|w2FGLO;;kFhH;{ShQ;sm*Tpbla+v9mr-(j{(=8 z&)CRbFnyvbMTEYg-1s2ZKozx(7h{v;6pigg@AwMC#xLlQQk>e&s#+QGW(fRi+$YHL z-aiq0xQR7Gnjpa3{&CNx&yFc?K|w-o#=eKZcG}O+^<9bWr{8CXoM!K+Uq645w|gWq zF49;Zbn8FrnSCX7nnn5ps@KKf*&xQjif;Xp;^cKXn|tx?`iW8XH)P~tZpS;$_E$H$ zDkcaJK$o^kS#=!Ly$z(_rE2$%k3Zsh4yUQ&Kx?fCrjCY%cHOe_g9nCRS z9~FCttG2S`)f<>UUg7<^9gi_g_{P(muur<0w9|ozlEmQ`mw7xG^QA5U7|_^o!`?As zf?=#9sR7eraB{9Dv7yZU>2l5-WmYnMQ)K!`seXn%y}mZ`ocK90{*xVGFWnbj)u+}vke?YC&EkF6?AR4;3d>?`lDS&387>XUwFG3 z+<*<)nDxd|(>0OtyG0{Z;y7*x7dYJ%rC>wj1Pri=MpXBM7{VTh_a*@}i6{RAw;%T# z1+k9VA8l0R}S_OD@SQ6+FD~q7DF!+$Tr>2=jAoa}o+n=pW z<(d}KDh7r$tAL9+f6X`|aeahuV~*yX6z`kmJzJUT?=qf#`BNU~2cm85uCRRNPk-eO zVxrd0ZFlHCLlm9K@}GRm*?)SYT-o)?{XoaBVQ&5aJGOV7Y6FlBn?96`2roPW9fBh{f*8a7Z#W6(% zz$n%b4ZBDR=W_1aLb@=#hTn1l1!z)HJi2Ex1K&sy+oVk{30gRWrlRRNuWC03Bb#1ggm$LJozWFWqgJq}BYP@a{6#gV4%sk+Qv`7LS-3apwSy zD-XEexu{g;*Pv}7>|bk^YL?2X%ypTxi!otz@%m9JkaDF@$O0!XiZQitz+%haY+3j* z))l*DEvj)rw{;r)Ts1T$T4-~*^*sC3t5#1)gKqaOe$|Q}q9Y$6{d9dbdX5j?CZGP- z&hwVNfR2>%5xZJx)T1jCiM+k#XSnAOuFhTkZ$6kKH!^}ci!%S6FTX}Po~K_qiTEMG z-YU~zb1rPse{}It9HPR~=CyIRj}rRaIiXlBLnI%9bAiOkswC~h^J+6@Dkl1NRBFi( z*Hdl&G<1EB!5nW#(7O>dHkWXF2Kym;R`+bl8xuG=N8$Z^#wuG9Vvtwe@p#Mh7pTW+ zw88ptUA}Q0n^Xc0**%9X*{%wY)m_t^wmw>(^jEgL7?Rl0llXI6zik=teotc9-3Iz8 z;P#Ok^QfRhf5!QLV4kGe3nt;M>|mDDkL4IA!5_-(KTH+@dsrN8$Q2Qc2Cv^%FfaE1 zc2;WH4ZNU}Z>pD8^^8R5Ce&#dnS<6$lP5ek=vVnO*51fOADk83KKmb{X+`^S_zF_v z(SD0lcGH+dpKJRwS!)-M@!#Z`x92dj%YT~ziqKDB2957c$fw!5AT_y3LWc}4b5Rm5 zfO?`cXi#Ec>dvU1#QkC!N&BNcf`8XIgx-Q-1qMQ?!?@%!dMcuQlG>G98-g9$?j#DQ zKQ~|Kx2?dV<09nx>Qw#y@#uw@&X5UWtn)&ILt*ajz-L6Jk%WtSKr0!7VNXQQAEWnF z6{tp#6ii5hn>si&X@lK4b(qHVc90Xe@HE%+Ds^^D`oF_HA7x)jGTMWW9eeL977XZ& zrfaucU69XwXpiQa{2c-}U0sGcrA*$wET>6S^ZZ^p4(>gNALcLpE-|D&S>je2yYm%{ zHLB*_)kFL2WNkQ;ebTSUc=S=7+HeAw&uPm8U{d*)<2b=TchNng%gDRv41YDo zA>D9cbn7In&|oF>9(+lMYo|>HjLb){{{5Xb@b|aZt{$*VNBN=h5?Ww|gKk`%0HF#= zWqFnS?x3iMY=Y{YmR%JWq%k1~^29_DdoS%gawEW#E**2>gVG0OR&HlNw^G%U6B1J+ zSkEPXyQWNpf3QptTbm|~Lbj(Oh<*nB1A`aE91!YAeGAF;_Z_o5VP0}!gMGlSHFa@R z`zgH6IRfuxkI%T$k?Nplwi6b7&KyhD#Xs@=BUi=@!GwSY&+Nk;kq&-{l+NE4KeFqF zD6Oo(qY_RR`*#KbQRt&@ynvs?alxl=-W~GwDAl4|66<;i41Tf9M6beQDYi4@{UjCw z=MlAMzzT;lJ!^{kBfdhJKRe-zNMs&UTXIP~oyQgoJK_y<>md%Usglpz%fvVw>-y5^ zS$D_PSQIS9Ra~{m5aBmkWFMXOBxS>mH!D=fR_)yUPryCZVLXK#wS7^LlVJ%tX)psN z854xEX$8%mo>ykkL&xb^Z}G2FfL9hL6ZMU|ml(bZgELrQg!+O{Y`VJ|;f#7r?h2-k z?=LYT4c?wHX<`-@@`V%{e=mZ@gif_weOxTdP-z86@q(99SPC#PLHA5lXD0@xjD-Vo zf1v|JR68D~1u)w8?7B1s0BsoWMHgJWO4|GIXKp*7LUM?4Qr?GBzp=|3xG(=ru4UrZ}&o}4N9@%3r2@+Y;CHNBEFg}Z04_J(mowq~;K&=8hu z_=m@zID=#bdNDV=MNNYlVT_^$Oh}4a7*1-wnR4l)M#nt%i`oTXWKs$1c!Pr$H#?ei z6XGrW%#+46fb`j7N{`zxn#2_1u5^wrFNtHw^f-93yLBg#Rof0d5jR|IdX6h1hh*`E zid}a$9s%xwD$g@n617rsI#OT@ZB|}Nutdn2is>t0g#tgMvytZCC&IsF$hZ)Eq9q*q@rX#qO~$_fJ$RPM{-Y2JHn) zbayX~VHIxUjZl{&kQ8Y7qHoUJ=C743t1Pu7$r!k4+?~AfNsN?Ce6!coV5Ughc!HM z7!ZKWS7n6NVd1v(mG-`M847VfHBdoUiBeYVpz;WN;rV>@j4hm7YVkJxPtvST7;aJk z!_yGY2Jeu+;{)Nio$t9l|I6O#VAhpgYApTeYQzxi#es#Jol=!n&;q9Rm6`+RhbX~V+wbt!AY zWhormiOoS096$SKeuU~|US8gNCtxQ^bIei?C{)sP1XwEfoc!ZJR=mKj@Ogzkn%Atb zZ{4_$i&ZJi8heiH5*_`#;p&;qgFr&P|G-HO?hdZCN+D2VEGe63Y!SgbZw=*)ArtD$ z<(67;Ow=klwsNtqt{;;EiCnU*BD~WFcoX+OFkoB;v|?QQ6DPYrLhkfIaWGY?AT_hs zTOw#mbAJ?Bbxn^gp8&tL=U+vdC@y44eeoj}sD()xy=jaC@u&Ee47?y|t}ocRLPcjs zbb|OPeR6lI?a(Fcw1R`j=Ttf%p}9cqXpF>Yin&Aqfer^bXn4$p`&Ag0t76ohsfb-s z&+o@q3m!83;)C|FP=NV|ME`a@eZ4(z|Gj9+J~P^~xs-JceKkTrJdG-0Hna}7mdxfX zKMf1?Pbg@)8gvrSmdN+=@aqfEab%67`pn_JX$SAgIWL>;qb9^?#`^&x;?_|H?q_Pm zT=stYkL)J#PznVmaoQ^ArqGz_3mWk5{pf-+N!X9C+2`eK9J~E`A=PyczsE*a;?)t- z^K}k~5YNGkk!g44?>@E-3sB$s7g-~M!SYb!Fu~=2iRxb*&%`X2fw4%0Wzjt%5ZpcJ z7!WX?>2l{x>G*4AOlnRQA(RuyZk}WteD4(Dy%mC_Ini7rbz$p|MgR0VL@Mn!hOvKl zwtzQc{oYU@5jRAs3%DC+Y9q6xO1;hr&5`j(DZF1(|LRSTd~NE0_Y0$^%;Zv;a-ACf zr?PTs-JvH_yszw8wT=+Y_wNJw0 z8KRP*W-1hX*r0z^l#`K8gWQFVySok%;h`7#n4xTkLFMM~SQ=*6vsq`drsy)E4g2Uv z8+nenOM}=anxHn(nT1fIe}~tB%T;B|ZU0<$JCp z$^Uba4a&SHK7GE1q@}KS|Ax>_$SiCmK{ltfJvIFkOE)p_A)x>0o|E@kHj#6yq!RWN zO@Xh%62LP+-@L=~W{gG^F->H|86i-8HH@2fb9ZkD!_2J**2kc?|N0}9yrl1Jc~CUD zVv^&pHO!^d_yIO+U{|4qkCH>?D~^q)C*ppg>EE8L$z-|83G8HX4J%t0?Xb zFjgdjhZxKWa8XO4bAFOfafJ9U@Rjzv7jnlji_1lV4Fz5m6yB-;OdQ~~v#I6p1&JxT zpbkO9dcr^}q!{@IzliMcjr)sqoE){8F**&UMAXKH^Xo7f>vh5RMMn$`LM;YXvNSHk z)F+xmx&xz^*};nE2_z?Vx=e;iwjut+QN$a03Cg#CNeZKp4nd?D4N{{Ub{>A`bIu>Yc=qfY z_kG=0PzV_Mm>CohW&Et&T*Kw_`=<*$rG~MW3?E04onp5Zbof6xzBnu#HE^;PQk0o| zVplO+skl3vLkPntB#@m=MHb&da>?gR9t8qZ3YcwP3);F<4tW*!5V-#5lfN~5|7p4h za$f2+k2aol)SJ)~i*uhK9^-n&(h)!L3Zf*Si`~6&no+;gjDWUSK#?qL09C8tJ(v>e ztiG8uPgY6LP2iZgX`cXm(6;6@rBrt)nz~EzT(6v!1T4pwNXW;p*ls=)A?oGNgo)tLBNw)_JyLP^$oD5^}HR^5vDKp2Kq#_ail!zSI&u=nPXCX|Lu z*I-hhmE)4N`&H4Wav*6}S7}B^@nV1&Ne&D@fKfL zK46+uh(kVT`A(NjHnKxeM`iPOvgT2>^dmAeb^9%Xn2@O2 zOzzjeTjk5E>935xxE+`#ZJPw*dlzf1!-4|NwtCk?j(A=Q&W6vian+x z)v{v^X6lR4>Q7HM1X>NMc=ot+0|+uYtdYvWXJfyq19Ts=YJrmX0rSulE?g$0AnYBF zaAe@a2NqSNks*u%bG@_B9xx7VGgC{$XwR<)9totTh$S;~!0T}&md7VaqVZkR79qqotevFiA`R$S8-51^QqRF(bK*{gG zu9Ng~w7-=zxRR~Bg4K3UorXVBovgq8=2ZZ}U`H5ZVan~Mh#5;0L)oWPA5?PXV*Q}@B&X$7}!v|U8j7TdrlDLk5R4_~)WSx`#imc~kHx5dVXw9WjqS5C*o3*( zI}FpS%tc<=ir5grEes1(V%)oIfP-Ab$xok`*-{waZF zmKM0RaKY_?gi3((aYl`{BXVTUc#jrW7we5OG9X}3lIJs zz~*7CC@rbOE$~!(amod85RE3^34()u&7PI)KN_^aj`4pu(+JxabdO(H3tAY63*VvG zTDW!TR)G0Lippd~gX@jLXUKkuFMmROcYFs8Lu*Ha-1Ip~>)tAfnloKc1lxtc;I$3e zVqI+YoPbIe518>_GvotWW<5adzgb>YL|DG%W}wW}pc^ebN0P1hWmq2|-DRLRT}$sQ zvwPBND)@d4I1G%!&vC7&{GKw<$Z@L|$G?C)qTZCrf>hGb@GPB$2d@H0eaOj|Q;gWj z^Bv2)~U+o=h@wJc^2F|f3{bTGf2w`)LXU0zY>1Gi)_{6zj3AN zdNY&%L8B&Loii@0N`I~7F*RLx()L{S0@KnJapYoOCte{gb2{z_hqbm!_Iy*L$COtN zRonUPtwL@Qo@%UFc{v#SPCoao4}ROJ3dsqR?LDaSEmk>5X*ZwA&rBl~_~e&1OR;SP zd_m%jea{BzyGxZ`cU#c%!vtv8@@yWZ(@^td1$lV|oQI_Ode5y^`ggh2+4Q$n^t7<5 z9^Bp9=PUvit#DXIqx6F`+Q|6~0$?iww}~dUPtj5+u20EhN(j#Zg>B(LgbMYeqK3Qu z(8SrJqkR*S!+`rF-22L_u%|z+C%74%{K=Q%Z7@H%fOk-C?-z|Lsa@4L+u0&JK3B^K%ndi#eW9J>G-T87PLC(9-LbbpGYdX|REY*%7F%jW6ZC*>q4 zk+YDu^mY?!(^9j0jdLpq#pt&yph&SHo8)@KPw9V%0$|$&Z~_$>xRw}P=uJY$Ln@Rk z&wrQPxsXbz71oPHzULpl_zIfMH(V>S>b+&LoNZ&As&}Dk{;(}gbC3eG2dMxr3!VOX z>(*}gh@*T)#Gm3(>!m)SKdf^Aa=jss$OhX)Z1r+(9to@D?8m|J zM=7#kcZ{gUFGv8W;%BfgILtIBN}9R}w;3D@XwQmjpRuAHnT z*S@>cxc_R>Xf*=D;b*WiSZ0V_!asQiRL6XpsZ;tFM58DpmD)dc`H3xQoc}Bt>zwu$zljd#vFIJUKdEuh#-WvyS3*Xtf& z@_w;6C-Hi9I6#n1v*d$*-%_v&aJTFirHg!%09Jnd9zeZgFoYN7MbP3wIhi9Mm5DAj zzoZSdoS!z?IlRQY5?dDeots7pWb;a{s^kK^P_9N>w4tq?Pz(3rzV*2GpQ|_-*`zEg zio91b)$d(^#=EX#DWr|AlVO!{YYLQ&X0E>IroNI{%OifHU`9lyMb(+s;UidTrj$gm z@#OakE@zY^EA4$9odR;&`l2eW-AiKF8##&j6oVvx6iUvD3q39=PO(f>RIaXyb=RLJ|wf&Vmd@XIr} z7E+D@Y1f!^P*qEn!-D=i`*AyOqDfXxe$ zMNpJY{Bh-6@~o9I z-L+4)Q2E_T`T+}7PyE<3sPQjcA41amFJmZ4NQ`}c1iNi4xUo22t@f7xh)1nH~u-NApfc_^AezQyqX15=NJSN z8@H^Gh^XCZc0ybD*6VvQUPmjf3+AkP*mHGB{@j4@gixa!@Em+oUYzO~luKqqw&fOX zd+_~7+_s_Dl+x?QPLACNBpVi9*>benbk0O>44yi?l**)AQvs1xR4|-K<2UYwBfy|q z$sgO^Mj#T6@33@R$o%9Q|L?%KxN_`*YRbz>A9JgPi#O$)JY6uqgZ^}bTti23;I{=vn2MZ3yC(^6#eS-Fjv3{!KLxaQrPy2_Vfz;q zIBuh;Kig?Kwl*d_K?BUwj6*-GNXy1VqGm+~>zCRCrv~l9#@g>dEo5_3plciJtYCRV zjd=B*unve8a-|tD?Ma>cC(Wu9nj8^C=meP!h5l{hi!_9DE=)8PdaxyRR11=oh48}U z4fF%Bp#M(L8X-a#3v0I@mc+IBg%V@gq+Zw1b&Gi;Ql$-I{Ngb;DWRf&;mEiA=C0hoW8xt9PM6ObhfRKX>k>gzeq~J2m)wCSw)!Ncjaji)fA`>{ z)OEb%j2)beXYf-=AmO17(t25P(iz z=@AHDl=;?@-11FGynY>JHE~1Cbo+d6>9;bFCIOXQ`nGLwE`O@EJpPWgTOfY3M}1O` z4_uboVOdFhS8tBf+I|3&nZyu6yg~ z7hJXFRD=Km&)W&u;wLyOiB}_CIyK>m?@hQqaPJR@jZd^`fINVpwGV>HWdaAW#Tk&e zTv{8&SkOo{xzk;R!U-ZhlJ_GLCYYg^B9vhjhHB0-C)uNu6$ig~jqA^=*wQO&_+qM7 zEi^XD;1T>a@2Dnf9|=Akpv3d*$(QoOh|fsK8g4FCG8J zje5##(A9qZ@J7aQMvnW3Ydua7=}-*1<=|3kb1jIgU0$jeflfxJUQ2DrkXnCT9%a1K zyE60nK32cTlC=jCcnScn0~?pV`eeY8K*N}5UW#iSAy`icZG}X)phq>FYOofJ1aN2+VS4T`Gew>KCbG*!tDVwo zgWcD206>BhKXCm+2j#I95GM9c}8&Y#I?*QZ9%&olur zEvz5)pG$qjaWLu^p~@FU;19@+(C^2qJEE(4GRF!Vcm20Qo!UjdmG4|*GtF?0THgeI ziDR9q=pks~J}(-oTC~V|&;b#>kcbSthp2xc{xNOgAez+BbdT^Jc`)M0w&zqat8KU<|$#hs@#zN4tV zxXyU+VIp;`hyw4X;w<6gL1%!qSgg07KFtcoqm{2iR=_5`JT$?v^`xcWQuIAXgxEajFDC&&-a=NoqX zmZWCto|ZrFAz0~RzK2e~i78788b#oJcqc3ZnCUXO?v|SM$nv=}w%#thah{{*a=iQS z^S|E(1LYf|GBvux{b>#YlMc&??OMk18s!y%hw^!$|ob+W} zU+P~O%&;^Tni0tIdpPk0 ztFL99+A>TQ*$IbQcPsw*Q%@wvC(lgPOdY3Yq1X6+`S|yU&P3b#pL&0|5`RY9m33T2@gtvNp zNXNOJF%Y4`bOc@=0a`Olk&kIr=^HD)YM^EPv(EL#PhoY0QI9_q`+ompMF~!40)_{l zze$SYx5BU0+B1s*)`}oe?u}A8@mo1Q8mBC?r(o(KXTiv*aMmDxejSiZ;MK;qmDU_0)%*v9-Tf8H06*aq+5HXj5}Momvh;Oh7L$Ln)|iI~tD?PP z%CQP1w1kk7`^vdRPy7KfuAvDVE|W<3 z&LO}+tHkHBz1AivGg~&(E$dnpor*8Zd64Bi+E3tTbn;~_B0NCYZ0b1D9v`hoZ&e1X zG>-?=%^hdU-ffP}&7lQH$PFL2D%ZRiKDP4NVL9KHh-IHq!M5E;pO3v8BA3LxwP}G) zUz>ts<7*G-v)8z0cSM=Nqlv?>SNaHpgsXIXcbepQlFq=f>fXEBre)wag5woxS-=L6 zj$CVHSsC1BDWR!hqFo)gWthA9Yg0_o!YfJZcneBFJp&^@9B;!D+kS33#O4Q@`py3i zhefa>nqWilq)TRMSJTLlx!V5@_RtT3!SE1;B82>dCsutGk1>L7c~uNp=rnWgEMHp$ zl^4|4>#Qcb`M%u8{J!4mN~J~4m|PT{B(t2YI6a4i{EP@qy{@D@=A=CKPDNEqT)l}1_BR9PPhAzmJoJ!QC-7u7+JDU4CINIII6tQ)o6rS3p60 zfP+@b^%Q}2i8AIL^vzh~Djz&AR9D4~dD#U{F@ncSc`*7sa{2ra7WT~PT_-T29Qg0Y z8rd84Q(HTpI16>ipdi!nhut()*oId0R57GSrvKM3o$Z*fvm_$_EX!-ZsN*dX!2>g7 z()@!f>5ufIf8wWd83>EXI>t`fTJ{3R$s(23CeY?A%hm74nah~UT1{QQ=IKzBGtGKT z6duEY;$N)*41$atK+XF=N*ZE1@~CxN{}9F=G?I;b%gEqBX&o3C`{8t-d{;))WKs%RVdG-V3#V9n;glzX$vszMX;ugq;iOK(e1l zB?$aSu;MfQjJa_+9-PQj=|wI|Zi(+phSmP6#5lj}T)q)@3#z%I)yCXe!3R>px78tp zYly5>+g}M{yGn6~^Cd_=B03ld-b*~WxRQUxOwDPq#taWMg39u+YkY`jihS}cdl8AL z@AaLum*5J1?d)*ReD^E%&5Mmj_r=JwjsZ2@cD@wBc6>Z+=FMV#)A0A{0vB78EH| zVaX+?fSs1Xgmm8TTq5XN&BbwTf~Ew(htDVOLAdRIO5qUTC7)K21AN7kTd+e0BetD}3AHtuyU5W=FTlzN`BuX{@;U?nx+Zm&)t!13Dt;#vihe%zIMOjB-4i8fE#E^eilaTB+E&8HddhKx>r|nTvm_Y(zDioLHWoyO9fl ze@}i+jqwPf3>$BEOriv?AT9fu#+gKx@T5)>Ih!Oadf5iP7p`hfm7lTM7-J zUCk+0hF<))Or@cs);lv~>+X*TKe`INah-!}ZY_xwp)mnltWECA<{4qvwm61kJ4eVEyC-*I3axjWO@y9|{YEcv>9LHx)Yj z-G2Qe+80l@kc4%OIQ=Vi0UU5b*VkFM@xkgog08;->C+pl5ns@D^OK$7^PWw{Ak;&% zxAI>j&`J@0PGwJtPIJ?7a-WxJa(lEW=_<}#u= z)evEcR-dx9z*=Dh-NT%zkcIHQZvpuK16V!6g{uYavU*Fl)AURT{GLI$A}*a6Le$Qe zG=qQ7gZk|&o&~BXYD?#IAv?Ge zzzDy&J49In5qFo(B&FQn{ZLu?xVs5>K-F^DuDS*(yQy$6tjV~M+>o0jFq>|o9IIqRJF^82adG77B!ur$AJlcu#5~3*LXB@_xSSn{ zwR5DBI9jxl?Lp@ilFa33#fLOWpp-S#w%TlI3jD?}kE?H+Kq8z9%6;NNHOKbB>~}

yZj4a z+&Sp*Aa2!ph6crB)@h1>vb*{8)k7m%G`F~$i&PBD)HnyI}%JeO1C57J8z zf%F1G^LT$~hhee=afXy$sk0e_`V&n+rBL9L58F)-RKkI5ye^aL;O3lNaD*=`{MTa1 z1urur5Wm4nuY>57V5$;lhLnc!r3MaG;ouK3!!L~jjyckxN#)?Uy%`Q%({eOMJr8(h zZWm`(H;Nwh>n1FN;Bd5RNxgAoQXlG_unHUo9K$Y!0_#wdQ6E}Wd1^488HuL1AOg#R zev@GrwWMqA@CWK`NVk6O1q_NbMFD>AEkem1_GJu#gz65BERwn<5I0 OdyC(8-{OtzqyGX}z-~YQ literal 0 HcmV?d00001 diff --git a/manual/source/index.rst b/manual/source/index.rst index bb47170555..25f293f57f 100644 --- a/manual/source/index.rst +++ b/manual/source/index.rst @@ -1,35 +1,40 @@ -.. image:: img/NeXus.png - :width: 40% - ======================================= User Manual and Reference Documentation ======================================= +Welcome to the user manual of the NeXus for FAIRmat project. + https://www.nexusformat.org/ .. toctree:: :maxdepth: 2 - :numbered: 4 - - user_manual - examples/index - ref_doc - napi - community - installation - utilities - history - docs_about + + fairmat-cover + nexus-index + em-structure + mpes-structure + ellipsometry-structure + apm-structure + transport-structure + stm-structure + cgms-structure + laboratory-structure + north-structure + + ----------- .. rubric:: Publishing Information -This manual built |today|. +| This commit time code <>. +| This commit identifier <>. +| This manual built |today|. + .. seealso:: - This document is available in these formats online: + The extended NeXus documentation: :HTML: https://manual.nexusformat.org/ @@ -46,11 +51,14 @@ This manual built |today|. :PDF: https://manual.nexusformat.org/_static/NXImpatient.pdf -.. Suggestions for adding to this manual: + FAIRmat website: + + ``_ + + NOMAD website: + + ``_ + + + - Look for some other "section" such as "introduction.rst" and act similarly. - Any examples go as text files in the examples/ subdirectory and are pulled into - Sphinx inside a :directive:`literalcode` directive. Look for the pattern - or wing it. If you are ambitious, add index entries. Many examples of the - constructs you might use are already in the manual. - diff --git a/manual/source/laboratory-structure.rst b/manual/source/laboratory-structure.rst new file mode 100644 index 0000000000..05523bcbfe --- /dev/null +++ b/manual/source/laboratory-structure.rst @@ -0,0 +1,25 @@ +.. _Lab-Structure: + +================== +Sample preparation +================== + +.. index:: + Draft classes + +.. _LaboratorySteps: + +Virtually all experiments require a preparation of the sample. As most techniques +are surface-sensitive or probe exclusively the surface, the use of careful preparation +techniques is the key to successful experiments. Unfortunately, the quality of +such processes is often difficult to reproduce. Nevertheless, documenting how samples +are prepared is relevant. The classes here provide minimal examples how descriptions +of the sample preparation steps can be interfaced to NeXus. +Currently, we consider these drafts to work towards harmonization with the +specific examples developed by the team of area A of FAIRmat. + + :ref:`NXlab_sample_mounting`: + An application definition to document how a sample was mounted. + + :ref:`NXlab_electro_chemo_mechanical_preparation`: + An application definition to document how a sample was prepared. diff --git a/manual/source/nexus-index.rst b/manual/source/nexus-index.rst new file mode 100644 index 0000000000..1e9bf529ac --- /dev/null +++ b/manual/source/nexus-index.rst @@ -0,0 +1,20 @@ +.. _NexusIndex: + +======================================= +NeXus Documentation +======================================= + +Welcome to the user manual of the NeXus. + +https://www.nexusformat.org/ + +.. toctree:: + :maxdepth: 2 + + user_manual + examples/index + ref_doc + community + installation + utilities + docs_about \ No newline at end of file diff --git a/manual/source/sed/entry-page.html b/manual/source/sed/entry-page.html new file mode 100644 index 0000000000..b7c84946c2 --- /dev/null +++ b/manual/source/sed/entry-page.html @@ -0,0 +1,6 @@ + + + + + + \ No newline at end of file diff --git a/manual/source/stm-structure.rst b/manual/source/stm-structure.rst new file mode 100644 index 0000000000..944c262033 --- /dev/null +++ b/manual/source/stm-structure.rst @@ -0,0 +1,32 @@ +.. _Stm-Structure: + +============================= +Scanning Tunneling Microscopy +============================= + + +.. index:: + IntroductionStm + StmAppDef + StmNewBC + + +.. _IntroductionStm: + +Introduction +############## +TBD + + +.. _StmAppDef: + +Application Definitions +####################### +TBD + + +.. _StmNewBC: + +Base Classes +############ +TBD From ef186ce54a4ff43085da772887dda17f9451ebab Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Wed, 19 Jul 2023 13:04:03 +0200 Subject: [PATCH 0061/1012] restore further pages for FAIRmat proposal site --- manual/source/apm-structure.rst | 90 ++++++++++++++ .../container/ComplexContainerBeampath.png | Bin 0 -> 7089 bytes .../container/ComplexExampleContainer.png | Bin 0 -> 25103 bytes manual/source/mpes-structure.rst | 111 ++++++++++++++++++ 4 files changed, 201 insertions(+) create mode 100644 manual/source/apm-structure.rst create mode 100644 manual/source/classes/contributed_definitions/container/ComplexContainerBeampath.png create mode 100644 manual/source/classes/contributed_definitions/container/ComplexExampleContainer.png create mode 100644 manual/source/mpes-structure.rst diff --git a/manual/source/apm-structure.rst b/manual/source/apm-structure.rst new file mode 100644 index 0000000000..11ef11f39b --- /dev/null +++ b/manual/source/apm-structure.rst @@ -0,0 +1,90 @@ +.. _Apm-Structure: + +========================= +B5: Atom-probe tomography +========================= + +.. index:: + IntroductionApm + ApmAppDef + ApmBC + ApmRemovedBC + ApmFurtherDefs + + +.. _IntroductionApm: + +Introduction +############## + +Set of data storage objects to describe the acquisition/measurement side, the reconstruction, and the ranging for atom probe microscopy experiments. The data storage objects can be useful as well for field-ion microscopy experiments. + +.. _ApmAppDef: + +Application Definitions +####################### + +We created one new application definition whose intention is to serve both the description of atom probe tomography and field-ion microscopy measurements: + + :ref:`NXapm`: + A general application definition with many detailed places for leaving metadata and computational steps described which are commonly used when reporting the measurement of atom probe data including also detector hit data, as well as how to proceed with reconstructing atom positions from these data, and how to store details about definitions made, which describe how mass-to-charge-state ratio values are mapped to iontypes (ranging). + +.. _ApmBC: + +Base Classes +############ + +We developed new base classes to structure the application definition into lab experiment and computational steps: + + :ref:`NXchamber`: + A base class to describe a component of the instrument which houses other components. A chamber may offer a controlled atmosphere to execute an experiment and/or offer functionalities for storing and loading specimens. + + :ref:`NXcoordinate_system_set` + A base class to describe different coordinate systems used and/or to be harmonized or transformed into one another when interpreting the dataset. + + :ref:`NXion`: + A base class to describe charged molecular ions with an adjustable number of atoms/isotopes building each ion. Right now the maximum number of atoms supported building a molecular ion is 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with which all possible isotopes can be described. + + :ref:`NXfabrication`: + A base class to bundle manufacturer/technology-partner-specific details about a component or device of an instrument. + + :ref:`NXpeak`: + A base class to describe peaks mathematically so that it can be used to detail how peaks in mass-to-charge-state ratio histograms (aka mass spectra) are defined and labelled as iontypes. + + :ref:`NXpump`: + A base class to describe details about a pump in an instrument. + + :ref:`NXpulser_apm`: + A base class to describe the high-voltage and/or laser pulsing capabilities of an atom probe microscope. + + :ref:`NXreflectron`: + A base class to describe a kinetic-energy-sensitive filtering device for time of flight (ToF). + + :ref:`NXstage_lab`: + A base class to describe the specimen fixture including the cryo-head. This base class is an example that the so far used :ref:`NXstage_lab` base class is insufficiently detailed to represent the functionalities which modern stages of an + atom probe microscope or especially an electron microscope offer. Nowadays, these stages represent small-scale laboratory platforms. Hence, there is a need to define their characteristics in more detail, especially in light of in-situ experiments. We see many similarities between a stage in an electron microscope and one in an atom probe instrument, given that both offer fixture functionalities and additional components for applying e.g. stimuli on the specimen. For this reason, we use this base class currently for atom probe and electron microscopy. + +Microscopy experiments, not only taking into account those performed on commercial instruments, offer the user usually +a set of frequently on-the-fly processed computational data. For now we represent these steps with specifically named instances of the :ref:`NXprocess` base class. + +.. _ApmRemovedBC: + +.. Removed base classes +.. #################### + +.. _ApmFurtherDefs: + +Further data schemas for atom probe +################################### + +We have also developed a collection of application definition which exemplify how data post-processing workflows +with typical steps specific for atom probe and reconstruction of microstructural features can be described with NeXus. +These application definitions and base classes have an own section in the proposal which you can find on the landing +page by inspection the section on computational geometry and microstructures. + +Furthermore, we are working with the NFDI-MatWerk consortium to explore how tools from the FAIRmat and the NFDI-MatWerk +consortium can be used to describe research, data, metadata, and workflows. This work is organized in the infrastructure +use case IUC09 within the NFDI-MatWerk project. One example how NeXus could be used to describe processing of +atom probe data with a tool which was developed by Alaukik Saxena et al. at the Max-Planck-Institut für Eisenforschung GmbH +in Düsseldorf is available as the so-called :ref:`NXapm_composition_space_results` application definition. + diff --git a/manual/source/classes/contributed_definitions/container/ComplexContainerBeampath.png b/manual/source/classes/contributed_definitions/container/ComplexContainerBeampath.png new file mode 100644 index 0000000000000000000000000000000000000000..597cee834c0426bd0e60b1afbf6554a5f3b04a99 GIT binary patch literal 7089 zcmbVxgT!j8lW(I7CP9R3l4E<2>J5 z)AI_IpP{<#g$8#av2ACx&qHz?7*6{wc9+~vb1nw=8zsvCGZ@1U!ma35{YCTeb^go#}G;SGXdmMbu z&k(dLz+>M0rk*>Sf)`6r0rqXS-WdWA6B8%4ZJE%EdqQPyjwzkRB;aOHTl>4)o5x|d zk^nCj4;eIl%(n^F+aGp�Z2d70QK#NZGhGGt4!*DVv+aK@%#_`tEYYN5riu(%l4#$J*D7^Wj?wMl{e?}qh~ zY>s%K&(C)zD>TXgDhM0}O&=C2r+yy#K3pp3G_SZgw*E;r78oa{=-eoZRr2X4M1X%T zpwKhuUnefLT1P?+p*cUDbF;27;urNXIdV3GP9r`-Tm1Iz!5axr2q&_2aKHv)6R*sV zoC86Z4ZQcMBBg7vGph*EBH-3c92|H`VKT=wJcAF`QUTL~RppiMF@&7l+%|jh=q_Yl zl(4Ai%5;s*CbbwAZH2$YiG@Y5cQ^ujWfjnl_}!#bRb1n>F}OTlrVE!&9&uFk^!!4^ z;FHzbDye5^Xk#UxwXh=zxB3+h)q$p^rRmjVynV~|G~Rjyp=(MM0mu_vg>= zxp&taB#b47RTc~^Sn`WBaGB9RJ~<@SMf)iaypK+F>MgC7zsG<%r}Pqabh%S?=ZlnO z^3i`NU#PHfxzukcD5suN`yh?Xm0-C9poTO!`bZon&_&qD+`{Bx!n8>beH987Qkx%6 zRNOt{;*|T%y-h7HKpqjqJ|6|a$DY4jlDeCYdZAn2&+t{t*H<)>RWW_m=_B!yXoyoi~j%|VXyXk z04CaDLB0Woc^Km9>6tgSGvc<^MsnrPilHHjLv>{cIk;b)x=dF3^O!*;WI(#z7`=S_P(B*fsh&^#>LCqbFwo<4%S1-m5+rtCdO_86H82|ZC-J$ z^0QbYQ`^F#vI*`-R!K??acY7!^%XsR4*+eK%Hj)EVh@1o1ZacHTr3XZeXE%-cJZ^~ z?igTnbhO%Wgc-Tl^we?eguId(P0owu>bd@t3XpYIWGuOgQ3;QMy?OJ-3M_sY35mfq zuL>o*x~!TS!N0WzGR3%G{DKF@zLYPS60_t>W-)`#e=IG9h1bEVcPafZw@P#@ERv6p zy`y8B4KrpKCaWw_2M6wwSG%=MfhV6$c;?N^>W7f6Z-J zDZ9VEuFcES$qeV@;ra2!?iU#qRgB+afU-yn!0$B5%45;`0FQ+Jpvg1>NBLMTz?jA| z)(osl*JpZq(Vf!EzRs{Z#ZpRbFK?ztkBILl;4p?=3tZpa=+|-|^w7C6v9sgywH;Fs z5D@4!^2MZlIShqt{M-5$5}9@b3BTNuH88kO!XO#foj}bZFw%z41MhYee!kk11Oklz z`dh>Fa}3e4#Q&K^U0w$2y?M`4s?}sm*A~AeYh%N5dpXtdeQ1dE*Lyz0`5f+^M4G6z zHCqtGR@VAntA~)o{%h9k?(R;MI#dUbIHEcyL@Z3EPxQq*VzL9^&^mv_@!);Obxb`s0N9NAtehd-L8uV}6C42C7z=Ib>PI6$H_DA_up%NN{Fh^> z@6}Hj#FD_{!Tfx_zu5NJ|A5Ka53{$5E!*l!AM|fiPAus(m+^;m79F8dyynf(?=1rH zL1Z)>HwZHN>dAH-*ru$A9m`(xn;An7#+IpHMW`trs;7o`dodKo%*qNKlD;Z0@SS}M zHU)v8)BotDgVO^R+R17TGolBVnK8I7s(9m@l)VE3NI5x(eSbQnP-m9fpg%(h52&{L zb-y_Dz`Ik#*O}nHg zNlM)8!9#x}(&v1I@WQ?csp#Kj<(@;5C9WOi9N+_lr(szFV>MwNGCcRs0*lZ|JIVP9 zA=!WCs+T1Mg;0=m61V*fl8wT){%kq|Mn?2fwDZ(fo$MHgwK`?lUyM`_1(0Ukfxp`(RR^z-IUr-0Hi-PWow{Cu;JB3(UcuYs*w zS4*6aR_LvhhkwGVo|nTL3j)wU85OH)F@&*_VhEf6T494$f9%^o{wW)R-E2MjvGeza zFSC{4jJ5&0C5fpaM@X8+x{0vKT$s9P6dx_!2}!7${-?<)v7eVYfycvLXmo&twy8~2 zSzgxcRWV?%+mDKmCxGJOHY}zf zBEzVtsQQD4x4pr}DhW>kTOQr`_F+|Id_uJWpE4krDs1n$j^ z4~#^#*Vo<6%_-@S^o6&xx9o;ptbyqcres_rlnA$?e4mR+7B4CynP7Ygfwge$eLz}V zGHzyvt(_DOG`TG4bC_tSFx*_?tgdwH@@G^c9{#)#bZ|j__6fymYZZ3A(t^oZFRLDJ z<|7pqNdZ|D!)U?g&d%b-{%;MSR7p(6^ymT)h)QkekSh-{N&J1hTjn*>H)-(^OFEn3 zfYf#FlAvDXSZH;}`L!fzojkUZ-u6h1~<|ldl38{cs(Tz z^yf0hlCvn;jF)zoekSZnWBb{^yuUDabL6)Zuf3|k>+R2D zMvZ^Gh-lu&y-J9rKP7y=AV`reWqLvN9_W;5A}8f@GEIFJ>MP(|aY1j>ljymVg<{x4 zjTFww#AKCVyAHqe?wr(PU0Yvgn<*~*(cO)Zkf1efbUo?C5fXKog#!N9hvflQ_Ei@1S=cn*o&~0NkFVWeV!*?(Mf@_YaIXRWBoSN8N{9R{?_E)?I0Pl)- zSk3-lc6VCwGx2l6)(wj|_KY$|AtH*hpC?w_!mj9Eym)c1V@Ac9UMldOv9Ym=hDLYW znZ#o0TO2BlDK1H~Tb&O}SYUmu{fUFUp;BFPRH*QlWfB*sA(cD;7K8SsKm<0T%Jh2< zl25-sW)G5-%1!FyUy%-yRq84#LT$7pDM1{kASaKA|J*&W{>_j1Bet3!Q3ERr3${`r zxt8<=t9tQd$(x@834HBwAge03Xrmn&8TmB#UY;zXJtTXHv-mT3HX4_wdxXvk*q_u~ zB^KOt1>j_xQ&o(Mfjf`PTK&m~q|UNl_(H6f+C%*J+s^o{zeB+URn(uW&@u3)lKb|J z;p;&>2N*w%=;1HNUykTZO0!8|{kbxXs;a8Jy}g~u@F#jT#yUC?U%fU8K$QTFg)4oE z%_J{+UxjhaAyD}a+Cs@wwyCv08}-sKhMprLBO|M=zF~n3htt&!q@|o7$!ghePmm7z z=+^r^QYn-8Z8ux1OeYQ)J;h$WBE@i|1QQu8Z9J*;IbdgJ7r&Ia))|34-QYs^?AbGZ z=Sd!<%U1ubM*O7q$3I697l{b1@r}c zb#YGrIZ^e>4+;7>IyR=G?@1{o-#w>byhE2awIfv-SjnB5>qWm1bS$f`p7=skW1XFT zab*!&nTEAa*pl^45h`few>x}ywmtEbT}whUI9L)~CN=kUf=-|A2g^ng;RDWaM3N{S zftMEMw&v9*0uNO={Kbrmkq%3Z5NXTI?3koyUB@P}H98^f}=x3TKl?q2}O2mR_|A|nL zG%`hFHXWWohRc4KLB~t}UJ|dtfA+lL(mfBsorQsVS4B-NvMQG`*|mrnY;qfg*hFN{ zAVt)=7mvOnW!V#zSZ;&1_0}9V3d%PhmV*IWUO1bT7+5{`@uWt=L$Aen^UF!p7wjLOt42~RsEI<~v438pG3D_0z4+^UFEz|`) zvuD@Lii^O;!@>~8S9gxNMoiLx4hhjF6<`Q53Q7mdctdkR2MJQ(Hb3194@9I}(Z6jDB zJ-!i-Y^d~bBcC&hzN{R&7{>TGfa3hb5Hl;n^pGGf31?*`JccmBb>U5|n<%zhE5z0o zFs#D*K1$Z!-dX3=Ia(A>%e}X|NL+4)pCwH^KJlswMT6a+iTAMxVxlBhGDD=E4w!Xl zR`oTwY|rFK!#R0fgRZJNaIvu794Qm5yb=~B`#Y=?lD|D9mB+$H zGGJ}T z>oxbA*&q6uHWjLhk7x@@K%-tEY!@WtNf=nyYKLH|PiyahN^|b2kcg7p`!3!)O1;1M zD8B@WA@E4Zz66RO5QvrA8XNqw&$>ONTwlKIRz-bacHh*#f`TAOsjnZcp1tkwDX9tt zZ{qN8LFksZFmv_H?%aH{-5m}-3H#ct$VIS<=6#fu9l;H<{q^2lw`hBNw4T9Fhg>pw z-#_9?|jjKcL2)~hIOYm38(_cRw(@DuF$S@N9u3V*z!Az)-2&b_hHdUq^ z3xAG=x_$BS|6XF^xpYf4D&8f*`ZGCZZ*GH5cAFtri0_{bBW7wN&i!X;U;vBKFoUaB z6dC4ff2%rVim5w%$osJCH6|G^oQf{XGA&-h3Vz9;(IbvVh*_!@a$6 zyTloD+(iBw#EpzJ3i{pq)k`)&d?7g=D>&G!kx|lUUOLEtfpK)Sl+m;S2)lf}(;y}2HdDyC+iQAu1*gEi}#v~#)tauKr>f77x zt6>sJhdB3RN6g7o#Nn!O5c2@$o2<(txGSh4PEM)$;^+L99-&Aj;AE5vj1>sQN8#5B zF>QemN{)ubKP~$|T#CZT>1e}^Yd5Ps9XV5SNamaJ%QYO<)?X+s!HDn+>w zgkDCoQRbQqMq)6TbMKLEM=HzKk<4|35{?o}k|!F4XAzn)`Jp=2rzD#7Y<@KZ9_6xr z9pG^flGkOg=6S@9K%*$XI8h=F4-3p?WM;QM;o1v@ECrnoCksU7yJVMox*z0C<2SkI zpI;8id|nc0`Y*%L>%eNNE3z$!^6!M<_Bk7b8p6h(>7>O`A0 z<+Zv*G%oobe{*ED{dM1NZ?PGvV#``j4cAc7NNPgGz!Dkv{TaS@;b(}yo^=0#PGFJz zZnL536YPaW4f$FI*7aZ8k+WfKpLp58WA|%}Q@wZTZb|N&MlBd(NM`?fsxmB0elg5a zyhTfzYtn^Y>O}{*Xk9rgF>z5nn_pVy(}ezLUu)}VJ-yP^B{+!VuV+ohkm{K0X1(jcKbDH?b&>a_(vxDPrweFG!4ZAQaM@IzzoNjj}rA zDd{kJNtN8Ib6~C!yRUCI`0r^kQiz=V_+lWl4sGU=mKMH|Lz&xg`au%S7JWZM-(ZyC zY#>w0b+bZ4{R69Ou8h`8GW{N}ZKwn{hbDlMWY(nFn;@L7Cww3hUttM6+E&%TSqy$H zO&vQlZoeprsc76h-5UFw_||P67JNj!psA8~0(<040j;#8ZhWd1PAZ)@XY#1pN)8>I z64k46S?F;kD#aHQ)0rptsTt&LEW5MFr}iV=DwtlH#MuJc^?~}{NW{(*GKiKKp`5JJSn=tL zWw`ym#rh3c5D}+>zU7-!QKX}9Q^r3wOy16eEhKnz|J>v1gl6sbZ`IcmKef_PdcMtKNSG<9Xx4}|=|E$9hEynSWZfFpV5_G*B%drKT zf{p37pZB$gbas&@46(47YZbb@8iCPEJw!2f+^TU{;OoX*ofcVd4Ci}K&W{udOOZ=t z#S%e0z1B4hVGwq$;tgot*W3B8oi}G=XMrnFctcBY#-FJdPMc3$vx24TVrm__`JV{r zWa$;L>gx-iP}rwlo)7P^BtBUGJ-T&NRCFAm0y}ZW$gYQY;R;z9O3Hq_ZqLg}D}5gC-$dChBeP#=_&Wpc z6)^{U=SlU}^T*LAGHTrz*Ap~tFkB5b#KBBH*19n!!Q|!N93nX5?j!e>NF|R`ZpIhF zfmx@Ej=QHU&3KG@J$PDno7xgmx2veFAUE;jl8Mo>b>~UIVQ`vsRSAk>_BorqYgesWGUr@`D=W&OA`>A)AQ05o^3v}i5Lh$_1g0Db0lX8X^R58= zdf_PfS`7(&c_EpEf#a8U@*f-_5PbCK9~ip&QWWqep_7c3ld7$mldF+~Da6&)mG!fY zrK7QtohhrW!>5!(VIl~G0`gi~Ld`98f5FvDO??sJ_>&oD^1wR}x|gq!KA*>kW5EVw zuUbm{adpZ^)|#v<)Y9k-VZzhDP{*;_)>cuIo~8+KLbAq6P{#TvKm7Nd=TnVILXyxI zl%HESKB7158}lhreFI-Shi*ud+gI%T>QLF(*pdb}OAZlKLK#?DW!>D|G+hJ3hT`Qk zUH!BpqoSlOEG)n~d3pyk6^H@?0(uLmRDw!Sw1tuBKgK6BpE8`C`NC!=5?;L}APMt; zaR+}E78d4#hJZ*#MU@cM>JN@+jO{4EQ73XtfufD`t#80g8K5T(wmmSFzPQ|niIO#% zUOgN34?|k1wVv~&`)qK;1#&U|SUpzI;H)JFc+BQ?Po4OrOMFz>WFf8o z9?c@2ej~~&m*e?<85w(3)Uwse+1)OJ5mUdcTO9zA|L5vGqJP89V4Q zLZPB^_-L2eM9r>zZP#fA*Ywo1dUUg(N4JSGKmb1D~NPY=dncQ+j0(tM>i z71eHtTc`hR$-q0qBmFFo^&dP6g{;}xe&oJ58oC&mDk$LbTt#kZ%08?1cO#%9_&ha! z=6r>TS=o|>yj!oBigB55F8cCxgpz^-)9q%XWDg%xg|BN_+0eZBF}=T!_U223F&dv=VeyWm~`2Y7bj>l_ksTBB;}*4 z>ovbvbPPNMuVab10~F*RHt0m-_7C7u{h#Nam|r;$`Vz9_J>_!8qVvNhmTZCJc^C9eHBn(jF{TXU6 z?l($^k2k|5du(8~I>BrOzJGatj(yyL-BO_5hBy24PUxp~61hoX@4Ez(1+<<+#b!p43p z8BdoPDYKhnsF1fTi;HMzYZKAFOY%b{=1pDjr_WytMKR6p?dJ8bS?k)$j!QJG(4eesX z6PgCmwT@dZ*IPU0OI~NFi|$)#Xivgd3$Em>_50=ErSy0;2miqUYVn7Zd;qA)nY?!`;cw*oY5aGy9sqo=jkm9DvOR~@huRbmO4pY=SL?N zwlDEmw1Z?K@tmh`_-q%W@>PGkOy7iu{a7RU|6maK?^q;UR|f|S^2I<3A38CgjnzfX zf=y_ziKMr;NV?DMXXX#(KT$lUf}Z179x*)wgM_|*`W)}X#6;RS@f5$B#Q(fyCqIW^ z5HS5JEvMQ({`u=MzhXxrBt*Qkv!gdsIQgGoS_f0Cv3Dw9V6ddPAMQy~@P8o84&)RH zJ@4z52KTcv`?W5O*tr82g6J;R?Rfs@$ewMJ`Sa%scXxNag=k*;ynz1$@jtfY5CR+y zjOA2GaOcO*7d7oG;w~<{|Hj7ZGc`d}2mZ$yPP=$=!?CHUDQz12>VIba##{F9%&VUPR2&MNw#8UcrRPQcZL zn4j+>uW%t_Q9vFL@KtZ2QV~QJX=(4-d{xxvo65?fel%`8Zh=$DKA0>fjtWD<9p7zg zEb)8Z8@H(wg>V0SR>kGyvW&~HbrAJA>4aeoY;W=39op5e{!a+-9@4SJHM+YLq@gX~ z_@v1H@85m=kKKMd3Yh0OaY4kxqhYn69a&VQ9TY@wzvLaCeX!`s_R`2G9SQY7=L~xm z?my?5XZY&Ju;>I$pdq4dr>PUM)wE2R+7a-+n+q4&*L&U$d2*gN8(*etE70QO8Ff9a zk>0<*k4spMjHhm_ud{5#dcKVFTeAvMA=gPtt_nP&Xp*Z%CZ7w#i2~^t@a`0}U4>sf zr}>@@My2|spG|$bp_Yh{kZ1Z&4w_j7`ysnk(j>T}$PZ0CLG1rrj95w39XeMv(Kb8` zr~3Prnr8z2^JgCdvBlqo^|GJXpDz?@+0-2P`#02ek&t!va3gVT`JlL^%xE#;(lv9a z`+25GKX%6mS}p2E4-62QnDHJQu{-5~`^djO*&AT}CtwK7DI3lH>A@YWhW~qp_U%zo z`L~v{Oa30L&l^tAGC0`G#B`#~%yBt4MN(#tSqBd#`CZ=c%u&1ftctH*$1p`aJfto@ z&nH``x>S)pJ=mg_mj}gS(+xoUI;1Q6m+e-9AJb+!$!rg1E6cQ)i^*L1NqUBcWIa6U zex8x|ZW1OTBhS`*Dn8rJc<#-aWBfODxLVz$oMW*kY$r3z&uBt_@rx&&dEWlFD|$ZB zTUY%X?uQRNBYOumkGB}3yh_5DsG)F4+`afdK3;p&yLh{eL$JmfQqYMpE^umQ&lKc}o?D z5U>_18IE(-a%HA(c_0*wZ-R+!kT%NT{*!`?M{*w?DeGBx4kSxtTOT%yAz#gpq37o} z%`f>65e33kzE@R+%NgB1y(uVQ{8XQifR%Wl#)u0G3p?BB>#bmI%>qRT?B8NyVoE!h z_ZAZt5y2$r=^t!VP>9C$y;s>IahYz?n_i+6)j#0m*R>D6UUNFM;zh(k{-Eiaqsq>& z%oK^w*0noPIA>LD(u)NmOUK3;m)Sr|hzpUyUjO6cRkQI#fx2~-=k-eH$#FY+y_cwn z2x$tRtxb2jimTm0WoVgw4#uXpH*S*P1o`LBZI5W&HQqNH z5^hfqKT8fj{sz;Sn7iQ3w2s^U9sEdX1l`W5Y;)P>w)ym zTNYMJs)4jQbWL5%pugN=Q1YP%(xJq57%gTrH;)Jd5dtwEzIU|sXFggr z(!igi(JX|4xbSH*4r{E{;)seu(bi}6Y?(v(XXemt4+ovr0_nkyWZ-1D{Zl{viL z?0&xEi=5GzgE>oJJ7BXDJ@5GfMy8J+8|?O{;j_DSJ&UgyksOAts*Im}L>wHVMs}c| zM5B5Jd6sXs*6fzNi>r^n_xj-*L`jMJAtoen%fET=+W#xRphunnjWnR$B3Pj`v`xVq zDZl8`_m7N$frP*%)I~Ct@Gq0NC>L&kU76@9l!{n50h0{Pc0@ltQveTFeb)32;rysn z@=XMJTf2x}x+=4>6JJ43uIP``(@av)`-Y)Ue949kY={tgDamIqBiR4Pm^PK)sB67< zRbsiMzRe!EJm5gvlQ=|K*%DRXR#x)vFBzbxDb{$5xZzT=4TnV&%Z2$gBBH6SC4c%j ztSc}=K`DV+S?3ycmY1EKT3uLeC2+K?Ty2a<^68C{CnsGvw} zgqWD=^o&2~JqDurB93mv+eQN3yn5_v^6`eZsoN<#YYGj8!XdaBbw!EisjaT`kEw>x zrHAdrHM#ISeIB#BpZNp>p-cBfTXCI-3632W$T*r-RT8lEj3w;{E@&LnY)~-Fwpj#K zyap-?ypKTms0|_=N1d{UnS_hW*aTdfqE@Bdea*{n-x#tTk!cmrJ5M+4hujhE?JelP zd0$yXKYe8wfs#Snv!u-FS!5n_VyTQa`WywPdhrdUFLD)z?y~siK`9~a#9B~L#P2c? zq>|Ghlaay0L=cGZIqt`9$|g!s`&as#L@-_tp3Cdr^Tz&1Zql&=noZ=nNxEs zbew(I#CyS^WV=f$3kUI3_$-o#0q_t%RokZU5Y^upPq%x@7m1h7!ayxGy_DtaiyK3pK{5MSHP;e``f}&!@^S6bfvVUuxnfjPS4Ba&~A=A)Wu$#y2{XoQ~yZyM@aaa-T z^yvqmEg7%P{PeDU{la0@k5c+%=KucbPnr_OuYRp0u9Ukk8a zM-c`Zi9NiC<@)9ac17Os*q${#J-gAi^2x>F&d%fUX@U?F=Vj*uDH=KNau23dVIAUH z_uXA`1aSm`2f9HB!KG~3-OafJfK=f&_0$1{lPe{J^m0F6&aMorvvakO^stVJ z#B~98vA1#G3l+75iB{jC*9UAamqm2s_f!n8qvNSNx7;9YWpK_MwInN!n-u5Yb(BvY zuIQic9mj3v5FCxN%pHR@P@2!3Ug&#qwAnP`l2P5wfzYdx;c&Ge*zn{tW@gyh`eq=N zp~$67oAmg2d!gc_SOc-V;(|qknftNc&WI-6*T-+${^|Y`GY&EZ!|T8fX`X<9q2hZ1 zXVls^!Eu(QGCh@3un=ZbQ()b}m32gDg}7w?{>ljOtz67d&R=&&EFcD5FuDlYtp>gP z^JlgFAobUcUW@F*^s!HT8P*%DP)WP_e9gJ#y}aNZ|LsM>(; zs@#|WdWnaNOF1Glb|FI|UAD`~t^pl=@5RY2~Z}&w5Kh5F1E4t;aq(r#7Hc_)* zF8%_s-pAdboThKXas2MtxHoPu@`ifErR+JZDl3)UJf#SUkdNZ2SHw(_8|0!ByhIT~ z6~87Xh8{IPEm{+&42Co`2p92J=udw0JZi*`aGXE=kw@KdcUV8Ncfp#mRPiacA}u!M zv>H@61QYu*McHku4#Fb58uU!5-#0_Y)x@Gm=NzwG>6t1FuMX?X3h{z`BO?a*oy=3W zP~wVGT{_gi8M!c5&#=#9Z*k4TOsZoshU888hF%Iu6@;IT&Wcaym`)d>=Nd3E^O ziaq>=zWq+(yf|fnEB{XIIZ1S=bt6E6o-a?pVNEFOMtS4wBelmU}{rukC-1=+%M|t zy5tFclG@v^hk(w6LZaY;0o&~)8RBS)5n?5XZ)l|rt^L>GsXI z0?dYj+NSU)nxA4q60m@`S!dRQ4EM;t(DSM7KjY$e^6y!fhbD8br^YPYuWVi(KvjhP z-C8a@S`qJ=DBtl*XUsij5J9@xt+kQ9v!+cRT)Eo0UKq}luU#Lv=f2AD_a_@#c@fx( zP+WCkABbql?q+wSvm%jJy55ei0)ix@g-e*^Z(6o`KQ+QrC(~$bIdYii2j6g`b;B<43G;rQVb`dh7~OOKOg=H{$6Hx6IDZyAcz)$?X+;-7Do z*tzQWoKy6^nFk)0?QLY)XVI;x)} zJVV|dQoCroQn#m#uR^t3V&&{SG`AZRR3W;^rJILg;aKta2Y8Hm?aBfICJmg`p7>k} z44j|RZz9+V3X74T`}c{MUwUImg?6aSOblE@#}-w}qCnaF^9V)s_KWUI6V92H z6-w*{+m&m3Y+9woy@sO|N-5n`eAZeTjM34O>V`v>U%BDBDl&3XxoT}je=_&ahB4h{ zOcP>@m#Wbb($FBwTsEowF2H|#$Mu?YXZV7e&hEO53?3d^I+PTTEvD_?FH%htd4pF{ zkF2j;9xz@mixz3~V3amL(t+Yu*u-d{m4&QJWz5Ff>$b!!he7 z@MeR^{?*mj($c@)hai&gv)z)YDE*qS&=cL-+he*B=6JeB1S5dmcOhw7K^R|jCBJ=o zI2yV^QFIZCs;$ktz0f4_Jrv*uxHbf-`N73J6wTQk)TP;?KeO8c+Cx!mwzI{5=H61V zC`>O&{IbaS<5M_8UO(lz`gI8Iw-a*eKle<2Isbx>0-|}0p_9$dZt|(-t!Ymsft{(b zJm?Q7Y)#j|rRe=*eW2Wpy#M`9VjGn&bH8GExok%Hde*WmRWy2?>+U^w-`(9({MB+G z3)vYVAKD3%W}S#wAe;*NrwT#kvbiwoWDk;F?&WJAYW=BK60GGjqas)5?QOyFTRdW| zdYv78syl8gr@2}1&B{Vl304FmW6;Rg2${}yNHJ9_|2(7lYihB?KZg#dQS7216zib` zXOKr|7Q;f^Iy?T_nAp}z3!dku#MM~f;@FgU0oF)bWU`9Q^0p*Imluf*33P;FLW^5qfw zMikkK6p7R)X|5QYp1ctnMShyPspeb?@3HRxjbU=QvNp)Yes{6}Q%+WpI}kB%jX?8m zghD_)QsT2Vc-7Lcqs?D7Ly}iqNl77oZ)$k5nloLNh2>ZFl>=1O9L8SH$>;-4LxU34 z1MkU!XL#Nj{JWG8zt3Z-GFcEqD;HiI3!bm7t#R&E=~Lr);665++bTJZZ+GQxS?dT)ki5#8Nobsb()G(Bi|VF7opQgb$BNAoH_ zJ}%Q=w*3d9w1`FphxkQ{|CTf3^M#kUGMG*lJzqV8RIgtLo}JY2vu$6j`mQiF{?JEa zHbX2zMa%QeBn@zLcUsPZXd~u1N+NKOLx{g=02hvFc{&HuHyl?hNPvSd*`y>=O1Ecqy?6;HI zmYjVIp=mdf-5|D6jm?Lo?VCm~(Kf$4Wv`o!LIQr}1Bcj`RJ(J`8ynBLc0 zqD514`%v1&bd7zDc~&-XLhZ%XA+6nVFpY}{wYs!*O95G3A-{ib2puu0a|Y4nu|Haf zNuz4i?uY)?#0v;Sq!gIBxPL*lE3)fyD7~R1)~c%&7LrY+#mJ~V;Ar>j&-eD;jeeCn zkIFN9Q#|r?6Cm)1*4hRfnN{;k6`&}4J9@UF}Hh#bglo3a7d7+K{ zF)nuL5x(hT3iDaV1nYC@vK+T&6uIPJ%`vT=&q;VG>4eDYaH&AKVi6xDS#dFp3q1R?VKN0#KEW~hhW*O z4FA>qp+LfyZ@yHcuD{dA@MPrsI|3^bx#cQLJ!&27CeSgVX18f>8`Y!n)-)7 z9?s$0U$AMfKeoL%A*}`VB+j>Q#nn$xsM>1PTt{M%^_)he^_+!FM*YL3-6*n4W2LW- z=&7W)>7H$YYvzLKM&rEo8yvD9NE9!aG{3jB=j4kWEQlE*@D>#X%;#(fG{WJ^H!FB~ z`yTSbIaIy;0>iS&WOwhztWiY2ANS~euEIb>R3a{rT}JjhE%vSr?z4F#Di?*WNRLGS zD_ITxICSa~X(TiWbV5I7wKek!mqld?1Pf{L;7AN4+#gN0!SV=pEW9>F!P>=Lmj{*8 zO^tYe{^&o$)}uaFvue=~cY87!DPm%6G9R|t?@wJ=geQu9b3+x*WY5{zM$aBjUEslX z9|%dNXNEfZh|SjfcE_d|vJXg`X5sB={%xQUw9=k+o3777+xz}4z1Ed4hQ$BO(Y51h z$|OBd6{4~B_3VVetrm*rsS@f;Z+%fi!ud6|wvS>{HfW71Oi6yA(;R|*JZ=12TUgXs zHnSf;ovn$!y+FM)dw9WKt|oFBBT$LF5LS6&H`#MB#)*(b)cx;^5F%o~xp>W~^9S>z zM^aHMaqoqLyizy~wg=0nT>#K3kzIsj<(~8@2>Z!gZxXkdGuvD}*4_$ug3Xv{>lG`i z?f2uyr1w!+Df!(L$HUz+9C~8witg=IFWoP##=46=d7TH(eJDtiEPf`AJ3WMUbZxpT@!m~ZEM z;unukEgsuykQP>T~owx~fV!b^JNW%yzAE|Uy=)0eW9*8`B z<^x%Ds#+>OM4w#V-!9m9lWH{zV)s|wBgZz6b6lzQV{%E}D->jp1oTO+u&sV#t0QU; zg|4!+Sp@^+?$M$(VMxS^5 zY8Z}VPr4Uu7akHHXO{72Z(UWkGZ6PRR=jTN&rTlOuKoZxdLYfyvHq&`=HK+@>gqTW zDlWP9EFe%cEcYspNKY<|p9FJ#;SdWjvHtly^!IaRH#A&)Yp%NeJw^zkdF-}*^yXkn zXf!cjmB+kIb-OutHX#3it<$7?>@rkueQsS5?~D~&Jx?^qrlp44T>UtWiqO;8kO@T% zzUqlT&ftUx*)Cdai}>r`=KzJOzbPE!(X?$ktns9_`&E58tj=#oN8g9G6ekG@W%p^| zYiQ_LqL|C^6(?KmF3dVlc)UQ0cuz(D<{JJRlhg4Py49Iu#_*M9)`$e0EsglB)d~f@ zPU8(<9dcF;au$0_2uohqBbOtwg;8fHe=xc|@)R|6Ds#tTLWw^*tp=yXyx~~#WeD^{ z=6yn$WZS~~!h+8Q-8hxh^7VSOXqKtKThcHfGm>BelkqC!XH8G07Ahuy@cQ$AU6rFUC>*&%v? zb1QaDF*`e#{)IaH$EdjfTg;%h!%zjamH_GzDMS&3EK`DQbhaRB^3F2DJq;0`yW*jn z`I9wl4AKQbr{qDGq(QXn+Xw?%8Y&C)N}cMDOXoXf^$es7sSAeUk4sN6x88T`+iS54 zA&7u6;tR->M!t`y;k z&S~UOfAsS;!Fey;aYXp%i6JIlyobk2zVo}eCA(X(r`Gs6n?Qxq?vqa$GS{T8Efof0 zqX5;wNUJ7d{(yz->+8!;(gH@X)umzF^_OJvnL<5kOnf0uuRuz67(TCS6dS=|+|ez* zxBC~;)X|WK9VUM&2@)sFa7JmG{5XD1znI3xrpy@tc8PzK?L ze+1V6Q()Cas&Dl>WowpRZ@h}A+PLJGK9Hw{3qhOsxY&SH^nnX$XJ_@TRDT~c0jCM# z>gwZj6j4z#2~qrnp{L6FMF8RzS;N6N{{2Jz#b=&L7N*WUzO)uV&=o8B$ePB(qn&g@ zrN`eUqo5cu(nBE9Ec(n0+}sgKV&tG$hJo-960**nM8K)w+wqgQt;d_2m`xgvDXgjlf{qbgvQ`Y)No@ax{p!dt{0Lu)$< zt4!qET|^aS!>&;B?}q2*_F;`_}& z!ly?8%xGAQ%__l^ckYk3C+Rc89Ip}>^kT{=v%DvuMgA2+)cbl=RJ;l}{Gpdl2+&A( zX2sOFwILzrnw?zbB0VAb^O}GE5MI2XU)kC55x~QARzkBJ!}>IQd<0c$h|0}OJLB${wn6#oF_w;K!>iw(sgHj&7 z?0cPQWtxt6Z8@<`2jyDmkb!h>B;R|=uLFv2-e=^$&1zk4CHncRmQ~`d^g{Qh9t*%F%shk7>e6!|=2irsw`A zNoS|A-Q9s41oCj}zIrjW#^LGGxH>_`P zF|gPm@A#6$;5uY_SU0UqA}b0Z4mKx#qb7VPR8W)*&cG8@4xbHy1a16iG5VCP$sCtN zvGK;N(3pC282_@+F0j=<4<9A=sv|r0*7%7HpVGYrUaNfF+r&f-kl~Zo?v`JAS?f~r zas1<5UdToq*-X=O55=6%DbNq8WNw$i)-k{G^M|BMxz{S56GV3UM26FKoVxyf0M(B`hqW$p#;KOk%{^d?Y|PM7M0e#ZeGld`kJHqk+1By z$D0#_(Bpna1#nt%n-a`=mkEKyAI*0*A0x9r4C3Pbz$DDKu(TmiDP3RL3e7_#Ge4QW zo}WJx+HxmVkZx3TC`VZG75m%SL=3bBp|Wc>*V)EP$sjR*t{%6%0b4zY1R_B309P{^1j~K@PNm}_Mzm10xVT=i5R{wj+t5B@; z-9y#F)^@3opcj>M58@D`@Es6Tx1A8~A3ZB80yh7ChIz(DwmE()@`x9HYafnfD;&Q7 z^n;V*W~SA_EbrWp(=+?iPJERrGt>l)QrVWjpKa#O=u*RGqu<%c{G&lhpyi1ktD9xo z`l{&vJNE^Jz(l~h8jA3QC}ha`rMai)X>aZ?OQ5eh{aJQUTR+&0$0i!V*32yDRzrt{ ztuyqy=KeHuXqz{F%s?t|z8_`x+AS|TCo3W%pty-_^9vmaoPM=s7!X5N#B+&_qh(&PI-e^iw0Di!?s-9+zAXg1b84Z=$j)K>vHGi=Ee^(97y6AnzJd^f-$LV;KWBYd^DJwfa8a5pR&P@ zR0OmeJVRIaZqEps$J7|m^#SJ6ZZh|JHPT~iWC&Q8vjFDVwhA=@^cYK$@It%l)?>@M zbb7i%RG-Tn1K^H9zlsJ-i4j6$%y{AW<{@9dyErR>-j7f?J1&8@QH8I*gT-=P%$EY% zn)mO$I6fyB#HL5_TYTlyD6uNY{LDTbpJM5!_^Bi4<*MZ|pmOEqr_q#@j0(>;J-vVa zye=WHRsTixYzCs8?J{H)6g{z|lrb zE$dcqMV;7h_w=CB(~DX1zR1A9-?kZ-RaN-x9do)HDEqU4?+!y!%2Qh~PG+tg1e||g zCIx_6mG7IMBIEW-zIYWqE=z!P17c1n{ut4km9xHyoMm*h_@BXz-CvpQsx2qH9lB8) z`;D0S(}e0-xYd(qf7p1k68b7hY{{G9U@_Z3OsV1YjjFpfh~Evul+rYG^-Z(vKKC|i z8rm4ddlT8Lozs6r34|su?2w&{M|5l?M)yi{cB_}-u3F&2JRjYAgcpXr^Ox%J5ld?k zfJ7m#7sKJ8l68)g|8I2&g5k!S6}F#U%}K(-kiyEh^)ll*+~{b=-BtYz#7we_&WY^J z**~SHV0;UU+Bld9}?N!X~Lgn4Kw9RZ#^!!|0szBmseUE33w9)mo`O295qReeACQcT5zqN zO>7$-@q6Gh%k=2S`&3y4W-t)I0srw@=?;$mgj{|B0lD2aweSQy$k+W4(RMp^@dp?;$~aOHRIzXnXDkPWNuA=Eqm~CBpMwT*r%^dUI^q z>A5EnQpy;1Xk6{XQ|g-VIdy`#o|of7p?u}#7G=hAq&78_f5+~|NP9L~{(~#DcrQey z*dWV%%%1%q;RwnrNSk8e%*?80Y+oPq@o^j_dz|g-gHGQ*oG8$IRabu~InfpEw}4g( z11CLak&s|0=mG`sNzAlq|18PmvTJ_h%^lp^?~q7*l7AMstFjgC5Vw z4g2vx-;>d{Z3mL!y1d~eb7nMtt>Z7XzSOtWV-Kr25Y|EGud3%a&x};s%KY`e6`;BhXMEKeT>Ysec z|2K6KTF$83^J&yo<(QAv7XGpS1+cti4hTUeNE49 zpUw7O^}%i{Z6z#XH$`R+gw7=X(TCHi&ttHL6)#(v>AJ&;n2j>fgC!9HDHYC>faVZ* z< z*$rxPvO=}DmtP*eQGV{mz#}>$8d5)x*rQfn;=f>!%j&ng-w2(mfqA-}hpYm)dY-eB2xWN}H>B zZBo7b<#0MfMtbo!9b2GDRzW|RdNts>06*^-TUM8CAN(%_wdMXs+$hV=w-uH`gmimK z={_~BV@lH>C}lfdB_f&rBqk!6t}H}r4~?9P;CJZo)6{1G6uO-$m1xtIQr*|KIUWDe zoJJ0hzk9PdQX%Gl-0Xi=@OJVorG`8VnD-2&<;VmE®w_`d`gV3yjY{|b6NDG+(F z+Dfp*;kmaQ( zgpwxhnx_R<$?z+(zcBOG)xj(O-onKv&u}*Y!5QxL?cP`t?_fsj3Ui*C1C%hkGmf%^ z$sYlM5zvGrsp|LslzMZq9neG{PhO9SWE6y`=nDqj z1!%~VaeKI+f{24Yh5YfiTrykv1_s2|_N4heH8s^wYtsen8*a~)!^|IO3%vpGm`S1{nVrYa5Y=)!`dfCh0Rn_j zm(8`DmU7cSLw9JQWpjCopTxDauI}8wxVyF3n_>Ml8_BFdMt#r0e~v37)8hNY#B3_$ zfiq(6_mhS~fUxGc4Uesct@)l)-)3G`xg!LX*ly=n;_61Ce%o{7)XTJ^xpdD%0pY88 zN1%RdaOcWZOpDk`_r^Qh929y|N=iX#IE}EoixKkU;>s85%vWuxvKDu*Wq)CRHfT+r zGsd%^_-41J$(cGl94Iq+59(F4XZ=7A0hE}QjKol{eFad^uSSB(p%@Qe|YfeXzUdkFO8W_f}7`qNU|fp^x<*l}Vf9 z+x02ZF!KF&Fc*A>P3K}`N6!dbQY%|?u*bB|Ug&g&f1a-@{yN-FhZW!F`(0)kyOOSB z^qwFm@QUH4{V{Onv#wIpE&b^DdN^PK5W*Kt=Ch=>ysY-QhX2llv}W;fB?rB-yu0EP z!NZ`?HO(u*do2H}?Vn1ryc+5MDIF%=Eqm|wt=`ej?-WTXO#&|2>5S}b*t}wRpL@)j z(>GHG35bU|Ug1ztpIgzuFOQy>l zZ<11~->-5khf1P!O3D!^VSpbBTM(z(Eg3Tut#Kydl|mLJ6|7d}8?C3syj)qg74JK1 zqvgZ=-$6!^ufNp&tRL@uyoS4;YObq7cMxFrU zy=`(ee)9{8O^Y-aD0ZEByyvqX2J_rCP`)Xl7=tPHpceiW#~_Mi2NgY5RGB@$`p=xo z`J@hit(U+6ol>0*-51L12quiX^RW>$^2N>1gd`q?-giNn5G1yO6h63@FIncUZ(wYj z7@}UW8L%>c(y1vk?KRjX-rWT%GF%^oy4kmEFwIY_1A6?<$ONJ!0QNE5Rij{6){+33 zr$QDC2C|Hdoa=`~Pa*)daLWfu1nRPl>NGdOUM;chr({kr0@elnxsL`&wEuEHk*SVl zmI8e>KffhjfzQpagDx~gMc+FXMm{U?)7eU-&m^o){;gTn7ESH5|9%xqNjVOSGU+*JN?!^@FQXL%yo@TU$)hH`Q zs~s^1%AqYXb{luqdc%Pp&49gR9VTAk=PqFSe)*uNT8qN@>`>y z!!$xH_uUC11dA9x~48ZFS z`0DB)!=iXv2~`1*Gp=>N3>n~XA=J4u7)Bd1ePBJn+b-COB zOAF9)ePUf*n*X_O@THk|H`sJ*F7-P*Ee}^Hnt63_l|*j$_C{nwCu@>%^eniSe+YP? zVNv_LWS0!c!9|17zndPaV9~`=(IH4^8iIv7xw*)=cmhh?(Uu*gdWqHR$=mxmU+WEDh<=CA(S=MtUcBI}$q(dspoKg__2F0wzUgL@8?t=7 zV&8x~8uHxV_^-y)iwhKvpify|Ny+w%Wby~mv%DL~#P&*fr2@aa3t5j9>zWKh0(w*M z0cb3<0bS0_{V)9N*Mb%h^RGM~E^=$xfhrUOd#v&yi;Rt5%WElG?5RlVeS(`g5V;s# z9SR=S!_*XYpg@|MN?bo!52-0bx|3fI!KnUDpV-n233?7ayH|(7E6Wmz2iIt$Q`U0` z4Hw^mV?#{$ZL++RN~0F4|17yu^r7t=Vz$d<%~42wBVW^XHWYB%5b*yd7QK&zPet9%Octy%~{j4aaLGWQ&Ab33uzBsp*D@t z;ff|UalgK+w`yM=(cIX8;W9&7n}e{MgeeOocrEV#+^YpCrV8YQVoCY_GEp`1ki--x){S~laCA$%ViX;?S7!J_$ zZDQ9+65(mndK-T12*LRn(zb8GZIUZK4(05V#b)J47ohds?SNMv&TO6y_p>{i@dgBxvwK}DGV3NqJ_`|hzicY*f4-toWyBP=#DhG`^_1(( zqJOUK(_*6yrn4~jA_53Gx4#NZ+#tFbL^T&;YTEW-)E>lh*XZ28fkq_<&+Uc+rxKJ| zau}ud?OPj=B1q9AZJHsfWgl8y?qf8Z$O@Ycqe+1J#kSEInQy^~V03g&S=n%R_t3dE z?B*=3+VQZ7*c|{W{X1i}#`Omz8CfPMe>Y#vg5&nY>nl zTYMj>zosAhn{X0B{%-kVyaGuHB5i zmo!D14NAFtI2+ zxFf<(WH5s2{ny15IOxE`BS8(j5di{x$m#u1@>(O;QR7vxV^C-{?DsU+Th&s15f!xr zhy*{NQ&_CR|dJ2w--ev$C&PANTG!2#n;bM z%myW%Fm)x-gDEk?A)YQVh`NJrOoNE!IBYwj1Me7*-lflkHB1B>e=d? zJOY?+_uk87q6Aq-RU;(ZOe5%VgwPVj!ik3junQg=P5YgMUcM1@ z-6dnUgT%b*f@q&jto)@R?|eX9&FGYg{sCKQ!SiM)L#}tG;==aLuQEbmf+`=M3pUX0 zgL?2NFI{Xl$*lMLqm>oMP%4AOyC|C_)O;NIx5S~M-cYvg`46v6IH55S0b}PoH5DK& zQ=xCQLn$7gC9*LxI@Ybl(l|UETuf=rVj8pXhez3!3JiuXv!@=(d@AJHTWS_VGe@UD zcU=x>8Z;Q`D^T{={n=_ZP0q2K6Klso^TM^%V2bVM1g~IoN}ON)R0-u)BwI%{i{}NF z4(;xvI+S3fZsqV-q7!j4&(^leavS`@NfcpA7-rp?{hD?utMtLZ@Gzc_Pu)iO-sM7A zBvV&sq^UwkNK_Q#*RN`>ySQw6TSLKn^R;;mj)=duhNZrI2`oq@5ibmW_bXtq%*ZZ@ zJxhiq3yP*UlVZF39TUNcixz;wNj&`x&K5G1l#~F=r(QkrO^WV3c)YK;CYuOA@V#y) zH{3WxYrb~V{lSY0u1efIBEDPNHy|ycfrpGnhO<;rRvCQI6JN)QW?(???Pa)kguc^w z_^SM4@aGLYwi0wS$1MkY`dx>2Gp=xuD%)Yu0mHD`MC=@?Dst>+{d>-}y};I>k%#OM zF;Gg=c{A#<4w}N}nm+=8jO8i>7QRLASoigxk-S3;UAu;AeAjSW4X1-_-y+J9iN!F* zibk}xhwAvWFTqFrDCflK?v_gX`a--KGx{%f>}$$hD>4uH;I_7==h?binmVe_Qq!h* z^$Nnu>cBNMBK&_9_MPEyebKu|?>)LO(Sm5vJHsfE5TZtn7NSQ&ln~t@TBIYo45B4O zH%b_Sh~7IfdWjbGzvuow-RHUG>zO(G?0xpyYrU(zhlQiAXw;@SQ+a*?|7~eV{7v}qdubVtvZOoa?Bd{ndDwe!0eQ!ch@8{y2L#knCEQ_T850aAfExCG-WWT~ z+(g!$3XPCeBS^iJcDiLhonQ^wo?s%8%1xPl2yyu~#L46lRtB7{KfM>jT7+J=0H zV7AeTEZZiMQ^fG7qIchpXV6)4)a6t-99VK#xE}9}6yH`fZ}7jFjcnkx^8zC;s&p3emI!it_H1c;GA3Lj=C|9ty1%gP zjBCXEt*&@6{3MkkMNWmG=LfL0NdCK~c6*M~#D+vf!^k8tEua)Y8=<$Kj0!)XLc-Tx z`(EdzRy?d;Vwz?}(jJP}n;26hctgWUE84~lh2W2{^p_KM_sHHq@Yu5eyM}t^HC>zr zx(SZ|OnQln!e}pr$S`c1N!WWxbVitt8-y}<; zqSr=h-B~z!={v2hZ@Ns%Ubp)c5Uxib079D)RV z$s&lUTB|S5iPBf5Qa5w3iE zIjFxzh?mbSsy4q#b$RT6d~wXPp_Qc7@uyc#(Hlk&8a$nhZfh{m0f3i4^}4Can}VY4 zefK-N^%atX1omTjSTnZLhnQqd0)zxAcw9;Lyh(24(eU6oTP!!N>ii&IZL8rsi>n58 zyXhh0_Y$vNV+lBubEKwD=ulePn!fS2kb?Hmp+j7a*08?3yjr_&A|DHM{8#o;nKMPe zV3gmJsme9GeaUH|$#)_6kAa$pyfxT8(wAx0A%EZQiVmoG#!yFm6R>FY+%P}RR3Ivz zXXZY3Oev>EH+&sxm; z0wE+?jpdZrX;(bvI-{5`_bG4A#%lPVtbVr450TM`Zocec9i!y@5|sPBK8Kqx-|#+w z|Ew@1%K8e20x#!{wGb6n&|Yi(Dl?O-)TTbp%qD=SIuAW((xu@~V<(psfeM=!G{mp0 ziDY?>T&Y0NBW-zOcJ~MGE}kT;zn5^*EgtCus`9wKy#*{~x3O-ET;n4pZJ#R5(tEEM z1MW2i<5d1w)zm3mwX@%!$21m{j9 zLtr*bZ6{o4AkWMot2Z3M4L2~L9VxYrk7c<2{r>sVuU{+y8!V+gA0k>ovTf^=vbSyB z5LP$$F~YbTLR> z2JB1S>^JQR54UHNdV20`%rvqG9c{HAMA~{6N@)q_RvOwjH{TF2^qKXujh zoYGEn7ii1`KCM$`(^&p=^2pDQRi(U-u-=4kx|L8v}joqoNh) zL0(k#k|WqAkW5}=YPR+9&nu){&qMj3q4Se#4&6-Y2ZvgK7%W#pq{Kt$4q_Tm5%^jr zCML3|JeRYwvg)yBRO4=Grec5K=2#`;5JH@Mve&(%>_d2nhet_^7?yIt$%+Zc$otyiZk_-)*WoonH$6EB z2-`3y6Fw`R661ix@XjDt<1efi2MJwVGWvL5@fTQSTfSI7~7u`w~-#dQ%Qt5Hd<4~PjH=i9KQCC5XJf+LHr6qyjM;06mHjV6= zV$AxrelTi_Io(EkeP01VHU_{0_M`)JF`d09k9lLQVu2An+hfP0feJF%~7!Fw*k!a&gP6 zfF}<|iXRsj*TcjCH4hFl`1$#5URX6kyB+KYc-%@HoHtCtzWBm{Ua@a!Y0+7QdIyBw zkS}&5XgqydIlcy1YQjn^s}~m9;|&Up!Qi!p;St#&#nXQME;pY9{fEhF9=8>JV$vK@ zqyu;f!*WW;FfC3+V)T0!IpD4IY)<+*z(Dv=hL7)0DJNYO{&$cxC@!X;rLu&n=iM_V z_&wD`wZHLbONhQ-**>0tu8OsSXkqEr($Q)JEA;C6o#q5k@~G+awYFFrafG9HnMeou ztc5>4Ew`a7czAW9FIyrW2hXd6Dd+>TIpjpICbSiF)VjTNOOBA}+WKPBW6$3(+^@Ke zpU40=1Cb<0r(Vw{r+x@F4*@o>)14zcd@g8-^vvD?2&DqqFTh&#?a6yNx+d+!EICo? z!jzQGlVbd(C?dKhoA+7>L+4Hw?8kbBAPK*20L$6SE|gC7^=J zq3*U@KpbYiGBPZ>|T|wp#rD>obwtk6v(N$q76)(%3n5U)9eFa_NmxRV{5^u zuWyZ7ROL+kXUGLBM4SAYaQ))E*NR7iv0ey?>aO5YDnJr|L*r zDrOEHC<~XTesyIGVUr~OM?x*d$_A+c#J^9Y`a|B!Yw5-1`T27)#8oCsAcx&wX(%JN zX;ib8_8*;#zPz3piTU}4ze+97Yb`a+IWho*48ZSEZ5t{K)9u0SX`yl>rcw@ z4Z)`nT+P>zuJl(1MJ88BsE}NZ2pW;&hwCe~w#kJ+2U6!uWBoW}Xl;&MGAaJ?cP5_6 z4nzx+C&pNWK@A^0upa~my=lKqO}Te#SH%BJNGAqmiAGs7B8EJMh)BW0aC#jaX2fU| zuy(}t;yz8s_|p0Lb#9oXn4^vay=Y>{;NW-CDqXle-lGeSv5$6r#2bxkzl>j12+j&aMaf?fBHny;`_#^Z3^0p zOBZz1J82OYQBYhn5r94Oi{3;TVt3!6o9$W&BSuY~oELwc96-%Q1hvI(#h~%D4VUh-X@d;?mq@>W+5+fjwnn?ecxFgklNg$^ z_S=(hN9(|32lixoRo=mEx0rcogBM!*xK`mN9e7PJfJXN%YG}_#OCow&;AJoQWtppI zgPEZRt7~x|2k!AkM!{1v%gjp82KWGKqex=BF<14FN@#Gvd$|H*5O~oLQX9{la(Xb@ zIaAA^LPDc%|ETct-*WfD-wjNn=IXz{H5K01B0sWK+|l%rh|^D3J0am}J|8xluktJD z-;TIx0)mdDRGRbiZNz9*O-$mo&CTkYJF}Nsea@e1S5^$VaYRnTU%6zd!QRHMD1Y+D zuYM~M@jVCs&FX5++#*5Ja(6%INoP7dJUZj>aN-L|lOl6MpA$pLosQm=WMTHrkPaic zab7_V&~GNJtf4U2lSvtHiE^quyDNwZgIOGLD_bpy2SEicNn+q#y-rso0b2~gJT@)H z64;`amb)Jxo%rf_xIb9grumS|6SufvU~NnY8bt%IJd<$`Jsrr`QxS7mH=P!H3J(od zgE+WCSnj#GUBPtZz!ccj^{57B0x5StFNW^Y*}L|=OkP(H#3v)&XZ!boeLuF{7qc2Zsi zXC#Lo=UMEWA3f&b#)k~ve27gGYmCg}yZt~lL@6Ek*$z6S?&oI~m3#9UFV1gMQjOTy zumtQ2d}(ah|LJl=C>bakPxKKd1OpbNUrd5tLR&lH=!;t|w)O$u3Hr3O1~SpRMJC$! zDItg9Is}36oUvRN80dX;+&dz%5GhsOjbvd1en&^Lb^QZLN2E;!P;`ia zSA4WmY`kSwWT(x|Zdd6cuJ;zu78M&l-{XDt z4p1rPYA?S2CMgOE`S)p5)Rr?8duJqp>Dl$iZcQhs6J(uIOs;1<`_bq6v)eG_ps4>; z;Z8b=f`H1jq_Vs^W^~ePl$o9oVEvbNL5Ij}JcyTxiKWuFc` zq@d8r)Vr;c68Dtu+I;W928W1w&8mRy1~etpQ*%$S2Du>20gkaOfc7{h z<(Mtd+Dd0A8K{kT(6ii)Jv~Be{8<{p{#{$JUji69EuMMtWeka^URrcL85!|*ehDfR z_@aTJ?F1ZPn$z9IwCANiTJb^PYau}I{)hg+K(BH9SgRRqaD9L7!NbTJ^obDf*AA** zK==gMC|#t!8@@Nr7N6kmUukDk$x;>f|KE__{5c_3RFJYRlJ_9)e{go!$&)V$evbwA8w- zmG<5Ew}f9T6(GVowBxNA)lC>nRZoS1NHz!j>3O(q8L&dV#m}pj z@tzb|DFO6Tvi9BG-!qLj-qKZ0@RwC@j1OYT-%weyQ2HherA$o7SeikAM@81Mz>d@~ zt)@2s=qp!Of>#Jp%;t;B`f)d4o@`!BA#T%DapDf%DeQ?)_1E^^E$O zrPu01S(mDss;7eK&OI(?x2*yBxO#YaySHuMTJrHPwV{f+ zmAYfOiM;@FA|U^a8u%slwZMQ_QIf&CK1e2P+u7l@gYKTI(&WDeKl1?L1j^fO;M-)X z;GiK99Hn~GZdgxEmKf21$o@^iRp8<}LiWFw#ZBOOxqZ1XvbP*+8V^j!OT4N&?}AgZpye1q&=$Khe-I|zw;0~CUjzpDwdFz&^RwIs~~Tw ziD@!t1bD{?1o0RNA+mQJgf_5DN)m>80kty{T{00Q@fgkPcjGVsHn37r0dWC-EOJF; zTr9VQkyFLJk_b_3I@*_)tg|n3A))mLYmR;x0n2J`_8COKYj`e?Q-R=svTs~ukF*1; z>lo^LdEuQQsjY;Td7<)C%+~Wz0iFxr`|7kH77$e}yP=gpuL|O+SCT~19yRsNR8gq= zR{7fuhK09H7n`+Hl~Hz$eI+uve;BM0j(C!_gQk90vM`igJ}NE z2FL6tu*-L3U&UEM>Fin6OEL;YMJSYCj7Ak$C!p&oMJ4h~iVb~Eq(aCj5hpQRaoa(q zR)wH{ z^n3uin$*Mu1lEZ-MwpGTi>Q$7STl6{Fz;ksr-nXgL@e1QN>a?~JcU;l8x){uaN|=aZsOKA!Xr=&M_~-3G|(=@>c$fuUlB0Nx#_L)dBV2K(LV8W_blN@@fVJ_p&b)x3flVFDI~)w`FB1 z$7>nP{`7mA$@uC<&uGJ-w&lji+FnSF(r3LgSdqoD=#%w(LUi-1&ZtpGAn ztD`_Kup2SDYuiG9eOVs;g833>)skAV!tA)$k z6K()EIg{BY)Tzt{f<{#@?^n;iMuZpj+}RDL$iK&7Rp|bk$Q~K|AgiY4RYiu<8;zK_ zqu1=LVlbmZ@uk$e-a*p}IP*3@!JGvw8ow_KInV)G!m$uMjq}tCN@{^Z7NrGdbn2S4L7i+}z$vohe#9SBJ;J zrw3ec-w4=ttFk~1yE-~K*&VD6Bi+mYqU3k3Ta$eAS=N1G7KXgTYg7mpzjdl|@5T+C zk}nq7T7P&_x+j&6b%aF{JiiQ&J2^RB6BO*48g^lFHo 4 degrees of freedom, + cryogenic cooling and other advanced features. + +We developed three base classes to describe data processing, which can be used as subclasses of :ref:`NXprocess` if describing post-processing or as subclasses of :ref:`NXdetector` if describing live, electronics level processing: + + :ref:`NXcalibration`: + A base class to describe the 1D calibration of an axis, with a function mapping a raw data scale to a calibrated scale with the same number of points. + + :ref:`NXdistortion`: + A base class to describe the 2D distortion correction of an axis, with a matrix mapping a raw data image to a undistorted image. + + :ref:`NXregistration`: + A base class to describe the rigid transformations that are applied to an image. May be redundant as they can be described with :ref:`NXtransformations`. + +.. _MpesCommonBC: + +Common Base Classes +################### + +We developed two classes that are common to other techniques: + + :ref:`NXlens_em`: + A class to describe all types of lenses. Includes electrostatic lenses for electron energy analysers. + + :ref:`NXdeflector` + A class to describe all kinds of deflectors, including electrostatic and magnetostatic deflectors for electron energy analysers. + +.. _MpesExtendedBC: + +Base Classes Extended in Application Definitions +################################################ + +We use existent base classes in application definitions and add descriptors: + + :ref:`NXaperture` + Added fileds to describe analyser apertures and slits. + + :ref:`NXbeam` + Adedd fields to describe utrafast laser beams. + + :ref:`NXdetector` + Added fields to describe electron detectors (MCP+Phospor screen, delay lines etc.). + + :ref:`NXentry` + Added fields to describe an experiment. + + :ref:`NXprocess` + Added subclasses and collective processing descriptors. + + :ref:`NXsample` + Added descriptors specific to photoemission experiments. + + :ref:`NXsource` + Added descriptors for laboratory sources (X-ray, UV lamps) but mostly for ultrafast lasers with complex time structures. + + :ref:`NXinstrument` + Added descriptors for the overall resolutions of the experiment (energy, momentum, angular, spatial, temporal). From 9516e91576cb7aa36db950fcf0b2cf15b485c20c Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Wed, 19 Jul 2023 16:44:40 +0200 Subject: [PATCH 0062/1012] adding old FAIRmat task pages back --- manual/source/apm-structure.rst | 22 +- manual/source/cgms-structure.rst | 284 +++++++++++++++++++++++ manual/source/ellipsometry-structure.rst | 157 +++++++++++++ manual/source/em-structure.rst | 151 ++++++++++++ manual/source/index.rst | 6 +- manual/source/mpes-structure.rst | 22 +- manual/source/north-structure.rst | 264 +++++++++++++++++++++ manual/source/transport-structure.rst | 26 +++ 8 files changed, 909 insertions(+), 23 deletions(-) create mode 100644 manual/source/cgms-structure.rst create mode 100644 manual/source/ellipsometry-structure.rst create mode 100644 manual/source/em-structure.rst create mode 100644 manual/source/north-structure.rst create mode 100644 manual/source/transport-structure.rst diff --git a/manual/source/apm-structure.rst b/manual/source/apm-structure.rst index 11ef11f39b..01be214ac5 100644 --- a/manual/source/apm-structure.rst +++ b/manual/source/apm-structure.rst @@ -1,25 +1,25 @@ -.. _Apm-Structure: +.. _Apm-Structure1: ========================= B5: Atom-probe tomography ========================= .. index:: - IntroductionApm - ApmAppDef - ApmBC - ApmRemovedBC - ApmFurtherDefs + IntroductionApm1 + ApmAppDef1 + ApmBC1 + ApmRemovedBC1 + ApmFurtherDefs1 -.. _IntroductionApm: +.. _IntroductionApm1: Introduction ############## Set of data storage objects to describe the acquisition/measurement side, the reconstruction, and the ranging for atom probe microscopy experiments. The data storage objects can be useful as well for field-ion microscopy experiments. -.. _ApmAppDef: +.. _ApmAppDef1: Application Definitions ####################### @@ -29,7 +29,7 @@ We created one new application definition whose intention is to serve both the d :ref:`NXapm`: A general application definition with many detailed places for leaving metadata and computational steps described which are commonly used when reporting the measurement of atom probe data including also detector hit data, as well as how to proceed with reconstructing atom positions from these data, and how to store details about definitions made, which describe how mass-to-charge-state ratio values are mapped to iontypes (ranging). -.. _ApmBC: +.. _ApmBC1: Base Classes ############ @@ -67,12 +67,12 @@ We developed new base classes to structure the application definition into lab e Microscopy experiments, not only taking into account those performed on commercial instruments, offer the user usually a set of frequently on-the-fly processed computational data. For now we represent these steps with specifically named instances of the :ref:`NXprocess` base class. -.. _ApmRemovedBC: +.. _ApmRemovedBC1: .. Removed base classes .. #################### -.. _ApmFurtherDefs: +.. _ApmFurtherDefs1: Further data schemas for atom probe ################################### diff --git a/manual/source/cgms-structure.rst b/manual/source/cgms-structure.rst new file mode 100644 index 0000000000..cb32812b3c --- /dev/null +++ b/manual/source/cgms-structure.rst @@ -0,0 +1,284 @@ +.. _CgmsFeatures-Structure1: + +========================= +Geometry & Microstructure +========================= + +.. index:: + IntroductionCgms1 + PhysicsCgms1 + CgmsAppDef1 + CgmsBC1 + IcmeMsModels1 + + +.. _IntroductionCgms1: + +Introduction +############ + +The computational-geometry/microstructure-modeling-based part of the proposal +has the following aims: + +First, we would like to contribute to efforts on standardizing a controlled +vocabulary, definitions for these terms, and relations between the terms, for +computational-geometry-based descriptions of the microstructure of materials +and atomic configurations used when characterizing materials in experiments +and computer simulations. + +As far as NeXus is concerned, the here proposed distinct sets of simple +geometric primitives and shapes offer a complementary alternative to the +already existent base classes in NeXus for constructive solid geometry +such as :ref:`NXcsg`, :ref:`NXoff_geometry`, or :ref:`NXquadric` to name but a few. + +Second, we would like to explore with this proposal how we can harmonize terms +frequently used by materials scientists in the field of condensed-matter physics +with definitions and terms offer by the NOMAD MetaInfo description. + +Third, the proposal should yield a substantiated set of arguments and suggestions +how descriptors for the structure and atomic architecture of materials can be +harmonized. With this we especially would like to reach out and intensify the +cooperation between the materials-science-related consortia of the German +National Research Infrastructure, specifically, FAIRmat, NFDI-MatWerk, NFDI4Ing, +NFDI4Chem, NFDI4Cat, MaRDi, and DAPHNE. + +.. The proposal reaches out to our colleagues in the materials engineering-based +.. consortia to document that there is value in discussing about controlled vocabulary. + +.. _PhysicsCgms1: + +Physics background +################## +Microstructural features or crystal defects are spatial arrangements of atoms. +Given their specific atomic arrangement and composition, such features have +specific constraints on the degrees of freedom how atoms can arrange. This causes +that these defects have specific properties. +Provided well-defined coarse-graining procedures are used and regions-of-interest +and/or regions-of-applicability are defined, microstructural features are often +characterized and modelled to have associated thermodynamic descriptors. + +Another motivation for the proposal was the observation that frequently the design +of file formats for simulation software in the computational materials science especially +those tools at the interface between condensed-matter physics and materials engineering +are frequently reimplementing the wheel (at least partly) when it comes to decide how to store +e.g. atom and feature positions or shape of regions-of-interest, grids, crystals, +grains, precipitates, and dislocations. + +Maybe this is a historical burden given the large set of technical terms and jargon +in place, which then motivated pragmatic solutions that resulted in many research groups +have developed similar formats using similar descriptions. + +We see this work on base classes and application definitions not primarily an +effort to improve and extend NeXus for now. Rather this part of the proposal +is an effort to support activities in materials science to work towards +common terminology and using controlled vocabularies more frequently. +These are the foundation for more sophisticated thoughts about practically +useful ontologies. + +Defining crystal defects is a question of how to coarse-grain a given spatio- +temporal set of atoms, each having a nuclid type and position/trajectory. +In most cases, such a coarse-graining is an ill-posed task because different +mathematical/geometrical methods exists how a point, a line, a surface, or a volumetric defect +can be described and be spatio-temporally constrained through a geometrical model +with defined geometric primitives and associated coarser-scale properties. + +The key motivation to such coarse-graining is to reduce the complexity of the +description. On the one hand to support visualization and scientific analyses - not only +of crystal defect arrangements. On the other hand it is the hope that using descriptors +at a coarser level, i.e. nanometer, micrometer, and larger, it is still possible +to find sufficiently accurate and precise descriptors which avoid that one has +to account for the dynamics of each atom to predict or understand the properties +of defects and their dynamics. + +Nevertheless, experience has shown that computational-geometry-based descriptions +when combined with hierarchical clustering/labeling methods, applied on set of +atoms and features turn out to yield useful descriptors. Examples include point, +line, surface defects, such as vacancies, solute cluster, dislocations, +disconnections, interfaces to name but a few. + +.. _CgmsBC1: + +Base Classes +############ + +We propose the following base classes, starting with a set of descriptors +for frequently used shapes and geometric primitives: + + :ref:`NXcg_sphere_set`: + A description for a set of possibly dissimilar spheres. + + :ref:`NXcg_ellipsoid_set`: + A description for a set of possibly dissimilar rotated ellipsoids. + + :ref:`NXcg_cylinder_set`: + A description for a set of possibly dissimilar rotated cylinders. + + :ref:`NXcg_point_set`: + A collection of points with labels or mark data. + + :ref:`NXcg_polyline_set`: + A collection of lines and linearized segments. + + :ref:`NXcg_triangle_set`: + A collection (or soup) of triangles. + + :ref:`NXcg_parallelogram_set`: + A collection of possibly dissimilar parallelograms. + + :ref:`NXcg_triangulated_surface_mesh`: + A mesh of triangles. + + :ref:`NXcg_polygon_set`: + A collection (or soup) of polygons. + + :ref:`NXcg_polyhedron_set`: + A collection (or soup) of polyhedra. + + :ref:`NXcg_roi_set`: + A container to host a number of different types of primitives. + + :ref:`NXcg_tetrahedron_set`: + A collection (or soup) of tetrahedra. + + :ref:`NXcg_hexahedron_set`: + A collection (or soup) of hexahedra with capabilities to represent + also simpler (bounding) boxes for e.g. binary trees. + +These base classes make use of new base classes which describe data structures: + + :ref:`NXcg_face_list_data_structure`: + In essence, the usual way how polygon/polyhedra data are reported: + Via a list of vertices and faces with identifier and properties. + + :ref:`NXcg_half_edge_data_structure`: + A half-edge data structure is a useful complementary descriptor for + polygon/polyhedra which enables topological analyses and traversal + of the graph how polygons and polyhedra can alternatively be described. + + :ref:`NXcg_unit_normal_set`: + As an additional structuring element especially for meshes, well-documented + normal information is crucial for distance computations. + + :ref:`NXcg_geodesic_mesh`: + Geodesic meshes are useful for all applications when meshing the surface + of a sphere. + + :ref:`NXcg_alpha_complex`: + Alpha shapes and alpha wrappings, specifically the special case of the + convex hull, are frequently used geometrical models for describing + a boundary or edge to a set of geometric primitives. + +Furthermore, we propose a few base classes for operations when working with +discretized representations of material (area or volume) which can be useful +not only for stencil-based methods: + + :ref:`NXcg_grid`: + A grid of cells. + + :ref:`NXisocontour`: + A description for isocontour descriptions. + + :ref:`NXcg_marching_cubes`: + An approach to store metadata of a specific implementation of + the Marching Cubes algorithm, whose sensitivity to specific topological + configurations is known to result in different triangle soups. + + :ref:`NXdelocalization`: + An approach to document procedures whereby a scalar field + is smoothened in a controlled manner. + +Assuming that these base classes can serve as building blocks, we would like +to test with the proposal also how these base classes can be applied in base +classes for specific types of microstructural features and/or utility classes +to hold metadata for these features: + + :ref:`NXsimilarity_grouping`: + An alias for NXclustering. + + :ref:`NXclustering`: + A description for clustering of objects (such as atoms or features). + + :ref:`NXorientation_set`: + A set of rotations to describe the relative orientation of members of a set of features/objects. + + :ref:`NXslip_system_set`: + Metadata to a set of slip system/slip system family for + a given crystal structure. + + :ref:`NXms_feature_set`: + Generic base class to describe any nested set of features + of a microstructure at the continuum-, micron-, nano-scale, or + to represent a topology of molecules and atoms. + + :ref:`NXms_snapshot`: + A container to describe the state of microstructural features + at a given point in time. + + :ref:`NXms_snapshot_set`: + The corresponding class to hold a set of :ref:`NXms_snapshot` objects. + + :ref:`NXchemical_composition`: + (Chemical) composition of a sample or a set of things. + +Furthermore, we found that it can be useful to have a set of base classes with +which software documents it state and gives a summary for users about the performance +and elapsed time measured while processing data. These utility classes include: + + :ref:`NXprogram`: + A named and version of a program of library/component of a larger software framework. + + :ref:`NXcs_filter_boolean_mask`: + A boolean mask. + + :ref:`NXcs_prng`: + Metadata of a pseudo-random number generator (PRNG) algorithm. + + :ref:`NXcs_profiling`: + A structuring group holding a set of :ref:`NXcs_profiling_event` instances. + + :ref:`NXcs_profiling_event`: + Profiling/benchmark data to an event of + tracking an algorithm/computational step. + + :ref:`NXcs_computer`: + Metadata of a computer. + + :ref:`NXcs_cpu`: + Metadata of a central processing unit. + + :ref:`NXcs_gpu`: + Metadata of a graphical processing unit / accelerator. + + :ref:`NXcs_mm_sys`: + Metadata of the (main) memory (sub-)system. + + :ref:`NXcs_io_sys`: + Metadata of the input/output system. + + :ref:`NXcs_io_obj`: + Metadata of a component storing data of an :ref:`NXcs_io_sys` instance. + +.. _IcmeMsModels1: + +Application definitions for ICME models +####################################### + +To bridge to our colleagues from the NFDI-MatWerk and NFDI4Ing consortia we +have created an example how the proposed components of the nexus-fairmat-proposal +can be used to create data schemes for vanilla-type ICME microstructure models. +ICME is an abbreviation for Integrated Computational Materials Engineering, which +is a design strategy and workflow whereby physics-based modelling of microstructure +evolution at the mesoscopic scale is used to understand the relations between +the microstructure and technological relevant descriptors for the properties +of materials. + +To begin with we propose the following draft application definitions. + + :ref:`NXms`: + An application definition for arbitrary spatiotemporally resolved simulations. + + :ref:`NXms_score_config`: + A specific example how :ref:`NXapm_paraprobe_config_ranger` can be specialized for documenting the configuration of a computer simulation with the static recrystallization cellular automata model SCORE. + + :ref:`NXms_score_results`: + A specific example how :ref:`NXms` can be specialized for documenting results of computer simulations with the static recrystallization cellular automata model SCORE. diff --git a/manual/source/ellipsometry-structure.rst b/manual/source/ellipsometry-structure.rst new file mode 100644 index 0000000000..add5aaaec0 --- /dev/null +++ b/manual/source/ellipsometry-structure.rst @@ -0,0 +1,157 @@ +.. _Ellipsometry-Structure1: + +======================== +B4: Optical spectroscopy +======================== + +.. index:: + Ellipsometry1 + DispersiveMaterial1 + + +.. _Ellipsometry1: + +Ellipsometry +############## + +Ellipsometry is an optical characterization method to describe optical properties of interfaces and thickness of films. The measurements are based on determining how the polarization state of light changes upon transmission and reflection. Interpretation is based on Fresnel equations and numerical models of the optical properties of the materials. + +In the application definition we provide a minimum set of description elements allowing for a reproducible recording of ellipsometry measurements. + + +Application Definitions +----------------------- + +We created one application definition: + + :ref:`NXellipsometry`: + A general application definition for ellipsometry measurements, including complex systems up to variable angle spectroscopic ellipsometry. + + + +Base Classes Extended in Application Definitions +------------------------------------------------ + +We use existent base classes in application definitions and add descriptors: + + :ref:`NXinstrument` + Added fields to add information that is important for an ellipsometry setup, such as the ellipsometer type, the light source, the type of the sample stage, or the angle(s) of incidence, as well as information on calibration, focussing probes, data correction etc. + + :ref:`NXdetector` + Added fields to describe spectroscopic detection with polarization (e.g. rotating analyzer). + + :ref:`NXaperture` + Added fields to define parameters that describe windows (e.g. windows of a UHV cryostat), such as the thickness and the orientation angle of the window, as well as reference data to calculate window effects. + + :ref:`NXsample` + Added fields to specify the sample and material properties, as well as the sample environment (e.g. refractive index of surrounding medium) and experimental conditions (e.g. temperature, pressure, pH value etc.). + +.. _DispersiveMaterial1: + + +Dispersive Material +################### + +A dispersive material is a description for the optical dispersion of materials. +This description may be used to store optical model data from an ellipsometric analysis +(or any other technique) or to build a database of optical constants for optical properties of materials. + +Application Definition +---------------------- + + :ref:`NXdispersive_material`: + An application definition to describe the dispersive properties of a material. + The material may be isotropic, uniaxial or biaxial. Hence, it may contain up + to three dispersive functions or tables. + + + +Base Classes +------------ + +There is a set of base classes for describing a dispersion. + + :ref:`NXdispersion` + This is an umbrella base class for a group of dispersion functions to describe the material. + For a simple dispersion it may contain only on NXdispersion_function or NXdispersion_table entry. + If it contains multiple entries the actual dispersion is the sum of all dispersion functions and tables. + This allows for, e.g. splitting real and imaginary parts and describing them seperately or + adding a dielectric background (e.g. Sellmeier model) to an oscillator model (e.g. Lorentz). + + :ref:`NXdispersion_function` + This dispersion is described by a function and its single and repeated parameter values. + It follows a formula of the form ``eps = eps_inf + sum[A * lambda ** 2 / (lambda ** 2 - B ** 2)]`` + (Sellmeier formula). See the formula grammar below for an ebnf grammar for this form. + + :ref:`NXdispersion_single_parameter` + This denotes a parameter which is used outside the summed part of a dispersion function, + e.g. ``eps_inf`` in the formula example above. + + :ref:`NXdispersion_repeated_parameter` + This denotes arrays of repeated parameters which are used to build a sum of parameter values, e.g. + ``A`` and ``B`` are repeated parameters in the formula above. + + :ref:`NXdispersion_table` + This describes a tabular dispersion where the dielectric function is an array versus wavelength or energy. + +Formula Grammar +--------------- + +Below you find a grammar to which the formula should adhere and which can be used to parse and +evaluate the dispersion function. The terms ``single_param_name`` and ``param_name`` should be +filled with the respective single and repeated params from the stored data. + +.. code-block:: + + ?assignment: "eps" "=" kkr_expression -> eps + | "n" "=" kkr_expression -> n + + ?kkr_expression: expression + | "" "+" "1j" "*" term -> kkr_term + + ?expression: term + | expression "+" term -> add + | expression "-" term -> sub + + ?term: factor + | term "*" factor -> mul + | term "/" factor -> div + + ?factor: power + | power "**" power -> power + + + ?power: "(" expression ")" + | FUNC "(" expression ")" -> func + | "sum" "[" repeated_expression "]" -> sum_expr + | NAME -> single_param_name + | SIGNED_NUMBER -> number + | BUILTIN -> builtin + + ?repeated_expression: repeated_term + | repeated_expression "+" repeated_term -> add + | repeated_expression "-" repeated_term -> sub + + + ?repeated_term: repeated_factor + | repeated_term "*" repeated_factor -> mul + | repeated_term "/" repeated_factor -> div + + ?repeated_factor: repeated_power + | repeated_power "**" repeated_power -> power + + ?repeated_power: "(" repeated_expression ")" + | FUNC "(" repeated_expression ")" -> func + | SIGNED_NUMBER -> number + | NAME -> param_name + | BUILTIN -> builtin + + FUNC.1: "sin" | "cos" | "tan" | "sqrt" | "dawsn" | "ln" | "log" | "heaviside" + BUILTIN.1: "1j" | "pi" | "eps_0" | "hbar" | "h" | "c" + + %import common.CNAME -> NAME + %import common.SIGNED_NUMBER + %import common.WS_INLINE + + %ignore WS_INLINE + diff --git a/manual/source/em-structure.rst b/manual/source/em-structure.rst new file mode 100644 index 0000000000..3a4b41d257 --- /dev/null +++ b/manual/source/em-structure.rst @@ -0,0 +1,151 @@ +.. _Em-Structure1: + +======================= +B1: Electron microscopy +======================= + +.. index:: + IntroductionEm1 + EmAppDef1 + EmBC1 + EmCommonBC1 + EmPartnerClasses1 + EmDeprecated1 + + + +.. _IntroductionEm1: + +Introduction +############ + +Set of data storage objects to describe components of an electron microscope and its eventually available focused-ion beam functionalities. The data storage objects were designed from the perspective of how electron microscopes are used by colleagues in the materials-science-branch of electron microscopy. We realize that the biology-/bio-materials/omics-branch of electron microscopy is eventually in an already more mature state of discussion with respect to data management practices. Realizing that we need to start somewhere, though, we focus for now on the condensed-matter physics, chemical physics of solids, and materials science applications of electron microscopy. As many of the components of electron microscopes used in the bio-materials communities are the same or at least many components very similar to those used and described in materials science, we are confident that the here presented schema definitions can also inspire discussion and exchange with the bio-materials community in the future. Partner consortia in the German National Research Data Infrastructure are here NFDI-Microbiota, NFDI4Health, and e.g. NFDI-Neuro. + +Electron microscopes are functionally very customizable tools: Examples include multi-signal/-modal analyses which are frequently realized as on-the-fly computational analyses, regularly switching between GUI-based instrument control, computational steps, and more and more using high-throughput stream-based processing. Also artificial intelligence methods get increasingly used and become closer interconnected with classical modes of controlling the instrument and perform data processing. A challenge in electron microscopy is that these steps are often executed within commercial integrated control and analysis software. This makes it additionally difficult to keep track of workflows and challenging to identify which specific quantities in the control software mean and represent in technical detail which physical quantity (and how these +quantities can be connected to the development of ontologies for electron microscopy experiments). + +.. _EmAppDef1: + +Application Definitions +####################### + +We acknowledge that it can be difficult to agree on a single application definition which is generally enough applicable yet remains easy enough and useful across a variety of instruments, technology partners, and instrument use cases. Therefore, we conceptualized first the basic components of an electron microscope and the usual workflow how an electron microscope is used. That is scientists place a specimen/sample into the microscope, calibrate the instrument, take measurements, may perform experiments or prepare their specimens with a focused ion beam, calibrate again, and take other measurements, before their session on the instrument ends. In between virtually all these steps data are collected and stream in from different detectors probing different physical mechanisms of the interaction between electrons or other types of radiation with the specimen. The session ends with the scientist removing +the specimen from the instrument or parking it so that the next user can start a session. Occasionally, service technicians perform calibrations and maintenance which also can be described as session on the microscope. Next, we wrote base classes to describe these steps and events. + + :ref:`NXem`: + A general application definition which explores the possibilities of electron microscopes. + +.. _EmBC1: + +Base Classes +############ + +We developed entirely new base classes. Some of them are also used for other techniques of this proposal but mentioned here for the sake of completeness: + + + :ref:`NXaberration_model`, :ref:`NXaberration_model_ceos`, :ref:`NXaberration_model_nion`, :ref:`NXaberration`: + Base classes to describe procedures and values for the calibration of aberrations based on either CEOS or Nion. + + :ref:`NXaperture_em`: + A base class to describe an aperture. + + :ref:`NXchamber`: + A base class to describe the chamber as a part of the microscope or storage unit for transferring specimens in-between or within an instrument. + + :ref:`NXcoordinate_system_set`: + A base class to describe different coordinate systems used and/or to be harmonized or transformed into one another when interpreting the dataset. + + :ref:`NXcorrector_cs`: + A base class to describe details about corrective lens or compound lens devices which reduce the aberration of an electron beam. + + :ref:`NXebeam_column`: + A base class serving the possibility to group the components relevant for generating and shaping the electron beam in an electron microscope. + + :ref:`NXevent_data_em`: + A base class representing a container to hold time-stamped and microscope-state-annotated data during a session at an electron microscope. + + :ref:`NXevent_data_em_set`: + A base class to group all :ref:`NXevent_data_em` instances. + + :ref:`NXibeam_column`: + A base class serving the possibility to group the components relevant for generating and shaping an ion beam of an instrument to offer focused ion beam (milling) capabilities. + + :ref:`NXimage_set`: + Base classes for storing acquisition details for individual images or stacks of images. Specialized versions can be defined and use controlled vocabulary terms for group name prefixes like **adf** annular dark field, **bf** bright field, **bse** backscattered electron, **chamber** camera to monitor the stage and chamber, **df** darkfield, **diffrac** diffraction, **ecci** electron channeling contrast imaging, **kikuchi** electron backscatter diffraction, **ronchigram** - convergent beam diffraction pattern, or **se** secondary electron. + + :ref:`NXinteraction_vol_em`: + A base class to describe details about e.g. the simulated or known volume of interaction of the electrons with the specimen, especially in scanning electron microscopy. + + :ref:`NXion`: + A base class to describe charged molecular ions with an adjustable number of atoms/isotopes building each ion. Right now the maximum number of atoms supported building a molecular ion is 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with which all possible isotopes can be described. + + :ref:`NXlens_em`: + A base class to detail an electro-magnetic lens. In practice, an electron microscope has many such lenses. It is possible to specify as many lenses as necessary to represent eventually each single lens of the microscope and thus describe how the lenses are affecting the electron beam. This can offer opportunities for developers of software tools which strive to model the instrument e.g. to create digital twins of the instrument. We understand there is still a way to go with this to arrive there though. Consequently, we suggest to focus first on which details should be collected for a lens as a component so that developers of application definitions can take immediate advantage of this work. + + :ref:`NXfabrication`: + A base class to bundle manufacturer/technology-partner-specific details about a component or device of an instrument. + + :ref:`NXoptical_system_em`: + A base class to store for now qualitative and quantitative values of frequent interest which are affected by the interplay of the components and state of an electron microscope. + Examples are the semiconvergence angle or the depth of field and depth of focus, the magnification, or the camera length. + + :ref:`NXpeak`: + A base class to describe peaks mathematically so that it can be used to detail how peaks in mass-to-charge-state ratio histograms (aka mass spectra) are defined and labelled as iontypes. + + :ref:`NXpump`: + A base class to describe details about a pump in an instrument. + + :ref:`NXscanbox_em`: + A base class to represent the component of an electron microscope which realizes a controlled deflection (and eventually shift, blanking, and/or descanning) of the electron beam to illuminate the specimen in a controlled manner. This can be used to document the scan pattern. + + :ref:`NXspectrum_set`: + Base class and specializations comparable to NXimage_set but for storing spectra. Specialized base classes should use controlled vocabulary items as prefixes such as **eels** electron energy loss spectroscopy, **xray** X-ray spectroscopy (EDS/STEM, EDX, SEM/EDX, SEM/EDS), **auger** Auger spectroscopy, or **cathodolum** for cathodoluminescence spectra. + + :ref:`NXstage_lab`: + As it was mentioned for atom probe microscopy, this is a base class to describe the stage/specimen holder which offers place for the documentation of the small-scale laboratory functionalities which modern stages of electron microscopes frequently offer. + + :ref:`NXcircuit_board`:, :ref:`NXadc`, and :ref:`NXdac`: + Base classes to describe electronic components of an electron microscope. These base classes need still to be harmonized with those used in the field of low-temperature scanning probe microscopy. + +.. _EmCommonBC1: + +Common Base Classes +################### + +We support the proposal of our colleagues from photoemission spectroscopy that the :ref:`NXlens_em` and :ref:`NXxraylens` have similarities. +It should be discussed with the NIAC if these classes can be consolidated/harmonized further e.g. eventually become a child class of a more general +base class lenses. We understand also that the proposed set of NXimage_set_em base classes can benefit from future discussion and consolidation efforts. + +The first result of such consolidations is the NXem_ebsd partner application definition. + +.. _EmPartnerClasses1: + +Partner application definitions +############################### + +A partner application definition is considered an application definition which stores data and metadata which are relevant for a given experiment but have usually only few connections to the detailed description of the workflow and experiment which motivates to granularize these pieces of information in an own application definition. In fact, one limitation of application definitions in NeXus is that they define a set of constraints on their graph of controlled concepts and terms. If we take for example diffraction experiments with an electron microscope it is usually the case that the pattern are collected in the session at the microscope but all scientifically relevant conclusions are drawn later, i.e. in post-processing of these data. These numerical and algorithmic steps define computational workflows were data from the application definitions such as NXem are used as input but many additional concepts and constraints may apply without any need for changing constraints on fields or groups of NXem. If we were to modify NXem for these cases, NXem would likely combinatorially diverge as every different combination of required constraints trigger the need for having an own but almost similar application definition. For this reason we use the concept of partner application definition which have fields/links where specifically relevant sources of information are connected to e.g. NXem. + +The first partner application definition is NXem_ebsd. + + :ref:`NXem_ebsd`: + Application definition for collecting and indexing Kikuchi pattern into orientation maps for the two-dimensional, three- and four-dimensional case. + +Several new base classes are used by this application definition. + + :ref:`NXem_ebsd_conventions`: + A collection of reference frames and rotation conventions necessary to interpret the alignment and orientation data. + + :ref:`NXem_ebsd_crystal_structure_model`: + A description of a crystalline phase/structure used for a forward simulation using kinetic or dynamic diffraction theory to generate simulated diffraction pattern against which measured pattern can be indexed. + + +.. _EmDeprecated1: + +Deprecated +########## + +In April/May 2023, we refactored the design of the NXimage_set and NXspectrum set base classes. Therefore, the following base classes should not longer be used: +NXimage_set_em_bf, NXimage_set_em_bse, NXimage_set_em_chamber, NXimage_set_em_df, NXimage_set_em_diffrac, NXimage_set_em_ecci, NXimage_set_em_kikuchi, NXimage_set_em_ronchigram, NXimage_set_em_se, NXimage_set_em, NXspectrum_set_em_eels, NXspectrum_set_em_xray, NXspectrum_set_em_auger, NXspectrum_set_em_cathodolum. + +With the NeXus 2022.06 Code Camp, we refactored the NXem application definition. Therefore, the following base classes and application definitions should no longer be used: +NXem_nion (replaced by :ref:`NXem`), NXfib (replaced by :ref:`NXibeam_column`). diff --git a/manual/source/index.rst b/manual/source/index.rst index 25f293f57f..ca2de5522f 100644 --- a/manual/source/index.rst +++ b/manual/source/index.rst @@ -7,7 +7,8 @@ Welcome to the user manual of the NeXus for FAIRmat project. https://www.nexusformat.org/ .. toctree:: - :maxdepth: 2 + :maxdepth: 5 + :numbered: 5 fairmat-cover nexus-index @@ -20,6 +21,9 @@ https://www.nexusformat.org/ cgms-structure laboratory-structure north-structure + napi + history + diff --git a/manual/source/mpes-structure.rst b/manual/source/mpes-structure.rst index 9755e8b2c5..eb45358f7a 100644 --- a/manual/source/mpes-structure.rst +++ b/manual/source/mpes-structure.rst @@ -1,18 +1,18 @@ -.. _Mpes-Structure: +.. _Mpes-Structure1: ============================================== B2/B3: Photoemission & core-level spectroscopy ============================================== .. index:: - IntroductionMpes - MpesAppDef - MpesBC - MpesCommonBC - MpesExtendedBC + IntroductionMpes1 + MpesAppDef1 + MpesBC1 + MpesCommonBC1 + MpesExtendedBC1 -.. _IntroductionMpes: +.. _IntroductionMpes1: Introduction ############ @@ -22,7 +22,7 @@ hard x-ray photoelectron spectroscopy (HAXPES), angle-resolved photoemission spe and photoemission electron microscopy (PEEM). We also included descriptors for advanced specializations, such as spin-resolution, time resolution, near-ambient pressure conditions, dichroism etc. -.. _MpesAppDef: +.. _MpesAppDef1: Application Definitions ####################### @@ -32,7 +32,7 @@ We created two new application definitions: :ref:`NXmpes`: A general appdef with minimalistic metadata requirements, apt to describe all photemission experiments. -.. _MpesBC: +.. _MpesBC1: Base Classes ############ @@ -66,7 +66,7 @@ We developed three base classes to describe data processing, which can be used a :ref:`NXregistration`: A base class to describe the rigid transformations that are applied to an image. May be redundant as they can be described with :ref:`NXtransformations`. -.. _MpesCommonBC: +.. _MpesCommonBC1: Common Base Classes ################### @@ -79,7 +79,7 @@ We developed two classes that are common to other techniques: :ref:`NXdeflector` A class to describe all kinds of deflectors, including electrostatic and magnetostatic deflectors for electron energy analysers. -.. _MpesExtendedBC: +.. _MpesExtendedBC1: Base Classes Extended in Application Definitions ################################################ diff --git a/manual/source/north-structure.rst b/manual/source/north-structure.rst new file mode 100644 index 0000000000..2198f3f866 --- /dev/null +++ b/manual/source/north-structure.rst @@ -0,0 +1,264 @@ +.. _North-Structure1: + +====================== +Nomad Remote Tools Hub +====================== + + +.. index:: + IntroductionApmParaprobe1 + WhatHasBeenAchieved1 + ApmParaprobeAppDef1 + ApmParaprobeNewBC1 + NextStep1 + + +.. _IntroductionApmParaprobe1: + +Introduction +############## + +NORTH (the NOMAD Oasis Remote Tools Hub) is a NOMAD Oasis service which makes +preconfigured scientific software of different communities available and coupled +to Oasis and accessible via the webbrowser. This part of the proposal documents +examples for specific NeXus-related work to some of the tools and containers +available in NORTH. + + +apmtools +######## + +One tool is the paraprobe-toolbox software package in the the apmtools container. +The software is developed by `M. Kühbach et al. `_. + +Here we show how NeXus is used to consistently define application definitions +for scientific software in the field of atom probe. In this community the paraprobe-toolbox is an example of an open-source parallelized +software for analyzing point cloud data, for assessing meshes in 3D continuum +space, and analyzing the effects of parameterization on descriptors +about the microstructure of materials which were studied with atom probe microscopy. + +The need for a thorough documentation of the tools in not only the paraprobe-toolbox was motivated by several needs: + +First, users of software would like to better understand and also be able to +study themselves which individual parameter and settings for each tool exist +and how configuring these affects their analyses quantitatively. + +Second, scientific software like the tools in the paraprobe-toolbox implement a +numerical/algorithmical (computational) workflow whereby data from multiple input sources +(like previous analysis results) are processed and carried through more involved analysis +within several steps inside the tool. The tool then creates output as files. + +Individual tools are developed in C/C++ and/or Python. Here, having a possibility +for provenance tracking is useful as it is one component and requirement for +making workflows exactly numerically reproducible and thus to empower scientists +to fullfill better the "R", i.e. reproducibility of daily FAIR research practices. + +The paraprobe-toolbox is one example of a software which implements a workflow +via a sequence of operations executed within a jupyter notebook +(or Python script respectively). Specifically, individual tools are chained. +Convenience functions are available to create well-defined input/configuration +files for each tool. These config files instruct the tool upon processing. + +In this design, each workflow step (with a tool) is in fact a pair (or triple) of +at least two sub-steps: i) the creation of a configuration file, +ii) the actual analysis using the Python/or C/C++ tools, +iii) the optional post-processing/visualizing of the results inside the NeXus/HDF5 +files generated from each tool run using other software. + + +.. _WhatHasBeenAchieved1: + +What has been achieved so far? +############################## + +This proposal summarizes both of the steps which we worked on between Q3/2022-Q1/2023 to change the interface and +file interaction in all tools of the paraprobe-toolbox to accept exclusively +well-defined configuration files and yield exclusively specific output. + +Data and metadata between the tools are exchanged with NeXus/HDF5 files. +Specifically, we created for each tool an application definition (see below) +which details all possible settings and options for the configuration as to +guide users. The config(uration) files are HDF5 files, whose content matches +to the naming conventions of the respective `config` application definition for each tool. +As an example NXapm_paraprobe_config_surfacer specifies how a configuration file +for the paraprobe-surfacer tool should be formatted and which parameter it contains. + +That is each config file uses a controlled vocabulary of terms. Furthermore, +the config files store a SHA256 checksum for each input file. +This implements a full provenance tracking on the input files along the +processing chain/workflow. + +As an example, a user may first range their reconstruction and then compute +correlation functions. The config file for the ranging tool stores the files +which hold the reconstructed ion position and ranging definitions. +The ranging tool generates a results file with the ion type labels stored. +This results file is formatted according to the tool-specific `results` +application definition. This results file and the reconstruction is +imported by the spatial statistics tool which again keeps track of all files. + +This design makes it possible to rigorously trace which numerical results +were achieved with a specific chain of input and +settings using specifically-versioned tools. + +We understand that this additional handling of metadata and provenance tracking +may not be at first glance super relevant for scientists or appears to be an +unnecessarily complex feature. There is indeed an additional layer of work which +came with the development and maintenance of this functionality. + +However, we are convinced that this is the preferred way of performing software +development and data analyses as it enables users to take advantage of a completely +automated provenance tracking which happens silently in the background. + +.. _ApmParaprobeAppDef1: + +Application Definitions +####################### + +Firstly, we define application definitions for the input side (configuration) of each tool. + + :ref:`NXapm_paraprobe_config_transcoder`: + Configuration of paraprobe-transcoder + Load POS, ePOS, APSuite APT, RRNG, RNG, and NXapm HDF5 files. + + :ref:`NXapm_paraprobe_config_ranger`: + Configuration of paraprobe-ranger + Apply ranging definitions and explore possible molecular ions. + + :ref:`NXapm_paraprobe_config_selector`: + Configuration of paraprobe-selector + Defining complex spatial regions-of-interest to filter reconstructed datasets. + + :ref:`NXapm_paraprobe_config_surfacer`: + Configuration of paraprobe-surfacer + Create a model for the edge of a point cloud via convex hulls, alpha shapes. + + :ref:`NXapm_paraprobe_config_distancer`: + Configuration of paraprobe-distancer + Compute analytical distances between ions to a set of triangles. + + :ref:`NXapm_paraprobe_config_tessellator`: + Configuration of paraprobe-tessellator + Compute Voronoi cells for if desired all ions in a dataset. + + :ref:`NXapm_paraprobe_config_nanochem`: + Configuration of paraprobe-nanochem + Compute delocalization, iso-surfaces, analyze 3D objects, and composition profiles. + + :ref:`NXapm_paraprobe_config_intersector`: + Configuration of paraprobe-intersector + Assess intersections and proximity of 3D triangulated surface meshes in + continuum space to study the effect the parameterization of surface + extraction algorithms on the resulting shape, spatial arrangement, + and colocation of 3D objects via graph-based techniques. + + :ref:`NXapm_paraprobe_config_spatstat`: + Configuration of paraprobe-spatstat + Spatial statistics on the entire or selected regions of the reconstructed dataset. + + :ref:`NXapm_paraprobe_config_clusterer`: + Configuration of paraprobe-clusterer + Import cluster analysis results of IVAS/APSuite and perform clustering + analyses in a Python ecosystem. + +Secondly, we define application definitions for the output side (results) of each tool. + + :ref:`NXapm_paraprobe_results_transcoder`: + Results of paraprobe-transcoder + Store reconstructed positions, ions, and charge states. + + :ref:`NXapm_paraprobe_results_ranger`: + Results of paraprobe-ranger + Store applied ranging definitions and combinatorial analyses of all possible iontypes. + + :ref:`NXapm_paraprobe_results_selector`: + Results of paraprobe-selector + Store which points are inside or on the boundary of complex spatial regions-of-interest. + + :ref:`NXapm_paraprobe_results_surfacer`: + Results of paraprobe-surfacer + Store triangulated surface meshes of models for the edge of a dataset. + + :ref:`NXapm_paraprobe_results_distancer`: + Results of paraprobe-distancer + Store analytical distances between ions to a set of triangles. + + :ref:`NXapm_paraprobe_results_tessellator`: + Results of paraprobe-tessellator + Store volume of all Voronoi cells about each ion in the dataset. + + :ref:`NXapm_paraprobe_results_nanochem`: + Results of paraprobe-nanochem + Store all results of delocalization, isosurface, and interface detection algorithms, + store all extracted triangulated surface meshes of found microstructural features, + store composition profiles and corresponding geometric primitives (ROIs). + + :ref:`NXapm_paraprobe_results_intersector`: + Results of paraprobe-intersector + Store graph of microstructural features and relations/link identified between them. + + :ref:`NXapm_paraprobe_results_spatstat`: + Results of paraprobe-spatstat + Store spatial correlation functions. + + :ref:`NXapm_paraprobe_results_clusterer`: + Results of paraprobe-clusterer + Store results of cluster analyses. + +.. _ApmParaprobeNewBC1: + +Base Classes +############ + +We envision that the above-mentioned definitions can be useful not only to take +inspiration for other software tools in the field of atom probe but also to support +a discussion towards a stronger standardization of the vocabulary used. +Therefore, we are happy for your comments and suggestions on this and the related +pages via the hypothesis web annotation service or as your issues posted on GitHub. + +We are convinced that the majority of data analyses in atom probe use +an in fact common set of operations and conditions on the input data +even though this might not be immediately evident. In particular this is not +the case for some community built tools with a very specific scope where oftentimes +the algorithms are hardcoded for specific material systems. A typical example is a +reseacher who implements a ranging tool and uses that all the examples are on a +specific material. We are convinced it is better to follow a much more generalized approach. + +In this spirit, we propose the following base classes and the above application +definitions as examples how very flexible constraints can be implemented which +restrict which ions in the dataset should be processed or not. We see that these +suggestions complement the proposal on computational geometry base classes: + + :ref:`NXapm_input_reconstruction`: + A description from which file the reconstructed ion positions are imported. + + :ref:`NXapm_input_ranging`: + A description from which file the ranging definitions are imported. + The design of the ranging definitions is, thanks to :ref:`NXion` so + general that all possible nuclids can be considered, be they observationally stable, + be they radioactive or transuranium nuclids. + +A detailed inspection of spatial and other type of filters used in atom probe microscopy +data analysis revealed that it is better to define atom probe agnostic, i.e. more +general filters: + + :ref:`NXspatial_filter`: + A proposal how a point cloud can be spatial filtered in a very specific, + flexible, yet general manner. This base class takes advantage of + :ref:`NXcg_ellipsoid_set`, :ref:`NXcg_cylinder_set`, and :ref:`NXcg_hexahedron_set` + to cater for all of the most commonly used geometric primitives in + atom probe. + + :ref:`NXsubsampling_filter`: + A proposal for a filter that can also be used for specifying how entries + like ions can be filtered via sub-sampling. + + :ref:`NXmatch_filter`: + A proposal for a filter that can also be used for specifying how entries + like ions can be filtered based on their type (ion species) + or hit multiplicity. + +In summary, we report with this proposal our experience made in an experimental +project that is about using NeXus for standardizing a set of non-trivial scientific software tools. +During the implementation we learned that for handling computational geometry +and microstructure-related terms many subtilities have to be considered which +makes a controlled vocabulary valuable not only to avoid a reimplementing of the wheel. diff --git a/manual/source/transport-structure.rst b/manual/source/transport-structure.rst new file mode 100644 index 0000000000..304a4f0e29 --- /dev/null +++ b/manual/source/transport-structure.rst @@ -0,0 +1,26 @@ +.. _Transport-Structure1: + +=================== +Transport Phenomena +=================== + +.. index:: + IntroductionTransport1 + TransportAppDef1 + + +.. _IntroductionTransport1: + +Introduction +############## + + +.. _TransportAppDef1: + +Application Definitions +####################### + +Work on handshaking between EPICS-controlled experiments and NeXus resulted in one application definition for temperature dependent IV curve measurements. + + :ref:`NXiv_temp`: + Application definition for temperature dependent IV curve measurements. From 4188634b21a6f5c4491e964412c70df63e495b54 Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Thu, 20 Jul 2023 11:12:35 +0200 Subject: [PATCH 0063/1012] Typo fixes --- dev_tools/docs/nxdl_index.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/dev_tools/docs/nxdl_index.py b/dev_tools/docs/nxdl_index.py index a580d57a9d..a116720e0c 100644 --- a/dev_tools/docs/nxdl_index.py +++ b/dev_tools/docs/nxdl_index.py @@ -159,7 +159,7 @@ def get_nxclass_description(nxdl_file: Path, namespaces) -> str: definitions and provide feedback to the authors before ratification and acceptance as either a base class or application definition. -Some contributions are groupped together: +Some contributions are grouped together: :ref:`Optical Spectroscopy ` :ref:`Multi-dimensional Photoemission Spectroscopy ` @@ -170,7 +170,7 @@ def get_nxclass_description(nxdl_file: Path, namespaces) -> str: :ref:`Transport Measurements ` - :ref:`Geomerty and Microstructures ` + :ref:`Geometry and Microstructures ` and others are simply listed here: From f73228ad65ff0bb1c3050248e47faf0927e9c2cd Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Thu, 20 Jul 2023 12:22:37 +0200 Subject: [PATCH 0064/1012] make TOC not too deep --- manual/source/index.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/manual/source/index.rst b/manual/source/index.rst index ca2de5522f..412a30dd00 100644 --- a/manual/source/index.rst +++ b/manual/source/index.rst @@ -7,7 +7,7 @@ Welcome to the user manual of the NeXus for FAIRmat project. https://www.nexusformat.org/ .. toctree:: - :maxdepth: 5 + :maxdepth: 2 :numbered: 5 fairmat-cover From 400ac9bddd7aa0907bc18f610e5c1dec7087fb16 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Thu, 20 Jul 2023 12:48:17 +0200 Subject: [PATCH 0065/1012] fixing merge --- dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py | 2 +- dev_tools/tests/test_nyaml2nxdl.py | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py b/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py index 984d7674f0..664f687484 100644 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py +++ b/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py @@ -29,7 +29,7 @@ import yaml -from ..utils import nexus as pynxtools_nxlib +from ..utils import nxdl_utils as pynxtools_nxlib from .comment_collector import CommentCollector from .nyaml2nxdl_helper import LineLoader from .nyaml2nxdl_helper import cleaning_empty_lines diff --git a/dev_tools/tests/test_nyaml2nxdl.py b/dev_tools/tests/test_nyaml2nxdl.py index 2722cf4755..792d8d4626 100755 --- a/dev_tools/tests/test_nyaml2nxdl.py +++ b/dev_tools/tests/test_nyaml2nxdl.py @@ -3,7 +3,7 @@ from click.testing import CliRunner from ..nyaml2nxdl import nyaml2nxdl as conv -from ..utils.nexus import find_definition_file +from ..utils.nxdl_utils import find_definition_file # import subprocess From d73387843ba18a1354a387c7e1eaf84e3138d7b8 Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 24 Jul 2023 09:09:11 +0200 Subject: [PATCH 0066/1012] Removes base classes from appdef overview pages --- manual/source/apm-structure.rst | 63 ------------ manual/source/ellipsometry-structure.rst | 21 ---- manual/source/em-structure.rst | 119 ----------------------- manual/source/mpes-structure.rst | 82 ---------------- 4 files changed, 285 deletions(-) diff --git a/manual/source/apm-structure.rst b/manual/source/apm-structure.rst index 01be214ac5..d7e94f6af1 100644 --- a/manual/source/apm-structure.rst +++ b/manual/source/apm-structure.rst @@ -7,9 +7,6 @@ B5: Atom-probe tomography .. index:: IntroductionApm1 ApmAppDef1 - ApmBC1 - ApmRemovedBC1 - ApmFurtherDefs1 .. _IntroductionApm1: @@ -28,63 +25,3 @@ We created one new application definition whose intention is to serve both the d :ref:`NXapm`: A general application definition with many detailed places for leaving metadata and computational steps described which are commonly used when reporting the measurement of atom probe data including also detector hit data, as well as how to proceed with reconstructing atom positions from these data, and how to store details about definitions made, which describe how mass-to-charge-state ratio values are mapped to iontypes (ranging). - -.. _ApmBC1: - -Base Classes -############ - -We developed new base classes to structure the application definition into lab experiment and computational steps: - - :ref:`NXchamber`: - A base class to describe a component of the instrument which houses other components. A chamber may offer a controlled atmosphere to execute an experiment and/or offer functionalities for storing and loading specimens. - - :ref:`NXcoordinate_system_set` - A base class to describe different coordinate systems used and/or to be harmonized or transformed into one another when interpreting the dataset. - - :ref:`NXion`: - A base class to describe charged molecular ions with an adjustable number of atoms/isotopes building each ion. Right now the maximum number of atoms supported building a molecular ion is 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with which all possible isotopes can be described. - - :ref:`NXfabrication`: - A base class to bundle manufacturer/technology-partner-specific details about a component or device of an instrument. - - :ref:`NXpeak`: - A base class to describe peaks mathematically so that it can be used to detail how peaks in mass-to-charge-state ratio histograms (aka mass spectra) are defined and labelled as iontypes. - - :ref:`NXpump`: - A base class to describe details about a pump in an instrument. - - :ref:`NXpulser_apm`: - A base class to describe the high-voltage and/or laser pulsing capabilities of an atom probe microscope. - - :ref:`NXreflectron`: - A base class to describe a kinetic-energy-sensitive filtering device for time of flight (ToF). - - :ref:`NXstage_lab`: - A base class to describe the specimen fixture including the cryo-head. This base class is an example that the so far used :ref:`NXstage_lab` base class is insufficiently detailed to represent the functionalities which modern stages of an - atom probe microscope or especially an electron microscope offer. Nowadays, these stages represent small-scale laboratory platforms. Hence, there is a need to define their characteristics in more detail, especially in light of in-situ experiments. We see many similarities between a stage in an electron microscope and one in an atom probe instrument, given that both offer fixture functionalities and additional components for applying e.g. stimuli on the specimen. For this reason, we use this base class currently for atom probe and electron microscopy. - -Microscopy experiments, not only taking into account those performed on commercial instruments, offer the user usually -a set of frequently on-the-fly processed computational data. For now we represent these steps with specifically named instances of the :ref:`NXprocess` base class. - -.. _ApmRemovedBC1: - -.. Removed base classes -.. #################### - -.. _ApmFurtherDefs1: - -Further data schemas for atom probe -################################### - -We have also developed a collection of application definition which exemplify how data post-processing workflows -with typical steps specific for atom probe and reconstruction of microstructural features can be described with NeXus. -These application definitions and base classes have an own section in the proposal which you can find on the landing -page by inspection the section on computational geometry and microstructures. - -Furthermore, we are working with the NFDI-MatWerk consortium to explore how tools from the FAIRmat and the NFDI-MatWerk -consortium can be used to describe research, data, metadata, and workflows. This work is organized in the infrastructure -use case IUC09 within the NFDI-MatWerk project. One example how NeXus could be used to describe processing of -atom probe data with a tool which was developed by Alaukik Saxena et al. at the Max-Planck-Institut für Eisenforschung GmbH -in Düsseldorf is available as the so-called :ref:`NXapm_composition_space_results` application definition. - diff --git a/manual/source/ellipsometry-structure.rst b/manual/source/ellipsometry-structure.rst index add5aaaec0..c801f341f6 100644 --- a/manual/source/ellipsometry-structure.rst +++ b/manual/source/ellipsometry-structure.rst @@ -28,27 +28,6 @@ We created one application definition: A general application definition for ellipsometry measurements, including complex systems up to variable angle spectroscopic ellipsometry. - -Base Classes Extended in Application Definitions ------------------------------------------------- - -We use existent base classes in application definitions and add descriptors: - - :ref:`NXinstrument` - Added fields to add information that is important for an ellipsometry setup, such as the ellipsometer type, the light source, the type of the sample stage, or the angle(s) of incidence, as well as information on calibration, focussing probes, data correction etc. - - :ref:`NXdetector` - Added fields to describe spectroscopic detection with polarization (e.g. rotating analyzer). - - :ref:`NXaperture` - Added fields to define parameters that describe windows (e.g. windows of a UHV cryostat), such as the thickness and the orientation angle of the window, as well as reference data to calculate window effects. - - :ref:`NXsample` - Added fields to specify the sample and material properties, as well as the sample environment (e.g. refractive index of surrounding medium) and experimental conditions (e.g. temperature, pressure, pH value etc.). - -.. _DispersiveMaterial1: - - Dispersive Material ################### diff --git a/manual/source/em-structure.rst b/manual/source/em-structure.rst index 3a4b41d257..40965d1cfc 100644 --- a/manual/source/em-structure.rst +++ b/manual/source/em-structure.rst @@ -7,11 +7,6 @@ B1: Electron microscopy .. index:: IntroductionEm1 EmAppDef1 - EmBC1 - EmCommonBC1 - EmPartnerClasses1 - EmDeprecated1 - .. _IntroductionEm1: @@ -35,117 +30,3 @@ the specimen from the instrument or parking it so that the next user can start a :ref:`NXem`: A general application definition which explores the possibilities of electron microscopes. -.. _EmBC1: - -Base Classes -############ - -We developed entirely new base classes. Some of them are also used for other techniques of this proposal but mentioned here for the sake of completeness: - - - :ref:`NXaberration_model`, :ref:`NXaberration_model_ceos`, :ref:`NXaberration_model_nion`, :ref:`NXaberration`: - Base classes to describe procedures and values for the calibration of aberrations based on either CEOS or Nion. - - :ref:`NXaperture_em`: - A base class to describe an aperture. - - :ref:`NXchamber`: - A base class to describe the chamber as a part of the microscope or storage unit for transferring specimens in-between or within an instrument. - - :ref:`NXcoordinate_system_set`: - A base class to describe different coordinate systems used and/or to be harmonized or transformed into one another when interpreting the dataset. - - :ref:`NXcorrector_cs`: - A base class to describe details about corrective lens or compound lens devices which reduce the aberration of an electron beam. - - :ref:`NXebeam_column`: - A base class serving the possibility to group the components relevant for generating and shaping the electron beam in an electron microscope. - - :ref:`NXevent_data_em`: - A base class representing a container to hold time-stamped and microscope-state-annotated data during a session at an electron microscope. - - :ref:`NXevent_data_em_set`: - A base class to group all :ref:`NXevent_data_em` instances. - - :ref:`NXibeam_column`: - A base class serving the possibility to group the components relevant for generating and shaping an ion beam of an instrument to offer focused ion beam (milling) capabilities. - - :ref:`NXimage_set`: - Base classes for storing acquisition details for individual images or stacks of images. Specialized versions can be defined and use controlled vocabulary terms for group name prefixes like **adf** annular dark field, **bf** bright field, **bse** backscattered electron, **chamber** camera to monitor the stage and chamber, **df** darkfield, **diffrac** diffraction, **ecci** electron channeling contrast imaging, **kikuchi** electron backscatter diffraction, **ronchigram** - convergent beam diffraction pattern, or **se** secondary electron. - - :ref:`NXinteraction_vol_em`: - A base class to describe details about e.g. the simulated or known volume of interaction of the electrons with the specimen, especially in scanning electron microscopy. - - :ref:`NXion`: - A base class to describe charged molecular ions with an adjustable number of atoms/isotopes building each ion. Right now the maximum number of atoms supported building a molecular ion is 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with which all possible isotopes can be described. - - :ref:`NXlens_em`: - A base class to detail an electro-magnetic lens. In practice, an electron microscope has many such lenses. It is possible to specify as many lenses as necessary to represent eventually each single lens of the microscope and thus describe how the lenses are affecting the electron beam. This can offer opportunities for developers of software tools which strive to model the instrument e.g. to create digital twins of the instrument. We understand there is still a way to go with this to arrive there though. Consequently, we suggest to focus first on which details should be collected for a lens as a component so that developers of application definitions can take immediate advantage of this work. - - :ref:`NXfabrication`: - A base class to bundle manufacturer/technology-partner-specific details about a component or device of an instrument. - - :ref:`NXoptical_system_em`: - A base class to store for now qualitative and quantitative values of frequent interest which are affected by the interplay of the components and state of an electron microscope. - Examples are the semiconvergence angle or the depth of field and depth of focus, the magnification, or the camera length. - - :ref:`NXpeak`: - A base class to describe peaks mathematically so that it can be used to detail how peaks in mass-to-charge-state ratio histograms (aka mass spectra) are defined and labelled as iontypes. - - :ref:`NXpump`: - A base class to describe details about a pump in an instrument. - - :ref:`NXscanbox_em`: - A base class to represent the component of an electron microscope which realizes a controlled deflection (and eventually shift, blanking, and/or descanning) of the electron beam to illuminate the specimen in a controlled manner. This can be used to document the scan pattern. - - :ref:`NXspectrum_set`: - Base class and specializations comparable to NXimage_set but for storing spectra. Specialized base classes should use controlled vocabulary items as prefixes such as **eels** electron energy loss spectroscopy, **xray** X-ray spectroscopy (EDS/STEM, EDX, SEM/EDX, SEM/EDS), **auger** Auger spectroscopy, or **cathodolum** for cathodoluminescence spectra. - - :ref:`NXstage_lab`: - As it was mentioned for atom probe microscopy, this is a base class to describe the stage/specimen holder which offers place for the documentation of the small-scale laboratory functionalities which modern stages of electron microscopes frequently offer. - - :ref:`NXcircuit_board`:, :ref:`NXadc`, and :ref:`NXdac`: - Base classes to describe electronic components of an electron microscope. These base classes need still to be harmonized with those used in the field of low-temperature scanning probe microscopy. - -.. _EmCommonBC1: - -Common Base Classes -################### - -We support the proposal of our colleagues from photoemission spectroscopy that the :ref:`NXlens_em` and :ref:`NXxraylens` have similarities. -It should be discussed with the NIAC if these classes can be consolidated/harmonized further e.g. eventually become a child class of a more general -base class lenses. We understand also that the proposed set of NXimage_set_em base classes can benefit from future discussion and consolidation efforts. - -The first result of such consolidations is the NXem_ebsd partner application definition. - -.. _EmPartnerClasses1: - -Partner application definitions -############################### - -A partner application definition is considered an application definition which stores data and metadata which are relevant for a given experiment but have usually only few connections to the detailed description of the workflow and experiment which motivates to granularize these pieces of information in an own application definition. In fact, one limitation of application definitions in NeXus is that they define a set of constraints on their graph of controlled concepts and terms. If we take for example diffraction experiments with an electron microscope it is usually the case that the pattern are collected in the session at the microscope but all scientifically relevant conclusions are drawn later, i.e. in post-processing of these data. These numerical and algorithmic steps define computational workflows were data from the application definitions such as NXem are used as input but many additional concepts and constraints may apply without any need for changing constraints on fields or groups of NXem. If we were to modify NXem for these cases, NXem would likely combinatorially diverge as every different combination of required constraints trigger the need for having an own but almost similar application definition. For this reason we use the concept of partner application definition which have fields/links where specifically relevant sources of information are connected to e.g. NXem. - -The first partner application definition is NXem_ebsd. - - :ref:`NXem_ebsd`: - Application definition for collecting and indexing Kikuchi pattern into orientation maps for the two-dimensional, three- and four-dimensional case. - -Several new base classes are used by this application definition. - - :ref:`NXem_ebsd_conventions`: - A collection of reference frames and rotation conventions necessary to interpret the alignment and orientation data. - - :ref:`NXem_ebsd_crystal_structure_model`: - A description of a crystalline phase/structure used for a forward simulation using kinetic or dynamic diffraction theory to generate simulated diffraction pattern against which measured pattern can be indexed. - - -.. _EmDeprecated1: - -Deprecated -########## - -In April/May 2023, we refactored the design of the NXimage_set and NXspectrum set base classes. Therefore, the following base classes should not longer be used: -NXimage_set_em_bf, NXimage_set_em_bse, NXimage_set_em_chamber, NXimage_set_em_df, NXimage_set_em_diffrac, NXimage_set_em_ecci, NXimage_set_em_kikuchi, NXimage_set_em_ronchigram, NXimage_set_em_se, NXimage_set_em, NXspectrum_set_em_eels, NXspectrum_set_em_xray, NXspectrum_set_em_auger, NXspectrum_set_em_cathodolum. - -With the NeXus 2022.06 Code Camp, we refactored the NXem application definition. Therefore, the following base classes and application definitions should no longer be used: -NXem_nion (replaced by :ref:`NXem`), NXfib (replaced by :ref:`NXibeam_column`). diff --git a/manual/source/mpes-structure.rst b/manual/source/mpes-structure.rst index eb45358f7a..cae1c026b9 100644 --- a/manual/source/mpes-structure.rst +++ b/manual/source/mpes-structure.rst @@ -7,10 +7,6 @@ B2/B3: Photoemission & core-level spectroscopy .. index:: IntroductionMpes1 MpesAppDef1 - MpesBC1 - MpesCommonBC1 - MpesExtendedBC1 - .. _IntroductionMpes1: @@ -31,81 +27,3 @@ We created two new application definitions: :ref:`NXmpes`: A general appdef with minimalistic metadata requirements, apt to describe all photemission experiments. - -.. _MpesBC1: - -Base Classes -############ - -We developed entirely new base classes: - - :ref:`NXelectronanalyser`: - A base class to describe electron kinetic energy analizers. Contains the collective characteristics of the instrument such as energy resolution, and includes the following subclasses: - - :ref:`NXcollectioncolumn`: - Base class to describe the set of electronic lenses in the electron collection column (standard, PEEM, momentum-microscope, etc.). - - :ref:`NXenergydispersion`: - Base class to describe the energy dispersion sytem (hemispherical, time-of-flight, etc.). - - :ref:`NXspindispersion`: - Base class to describe the set of electronic lenses in the electron collection column. - - :ref:`NXmanipulator`: - A base class to describe the complex manipulators used in photoemission experiments, often with > 4 degrees of freedom, - cryogenic cooling and other advanced features. - -We developed three base classes to describe data processing, which can be used as subclasses of :ref:`NXprocess` if describing post-processing or as subclasses of :ref:`NXdetector` if describing live, electronics level processing: - - :ref:`NXcalibration`: - A base class to describe the 1D calibration of an axis, with a function mapping a raw data scale to a calibrated scale with the same number of points. - - :ref:`NXdistortion`: - A base class to describe the 2D distortion correction of an axis, with a matrix mapping a raw data image to a undistorted image. - - :ref:`NXregistration`: - A base class to describe the rigid transformations that are applied to an image. May be redundant as they can be described with :ref:`NXtransformations`. - -.. _MpesCommonBC1: - -Common Base Classes -################### - -We developed two classes that are common to other techniques: - - :ref:`NXlens_em`: - A class to describe all types of lenses. Includes electrostatic lenses for electron energy analysers. - - :ref:`NXdeflector` - A class to describe all kinds of deflectors, including electrostatic and magnetostatic deflectors for electron energy analysers. - -.. _MpesExtendedBC1: - -Base Classes Extended in Application Definitions -################################################ - -We use existent base classes in application definitions and add descriptors: - - :ref:`NXaperture` - Added fileds to describe analyser apertures and slits. - - :ref:`NXbeam` - Adedd fields to describe utrafast laser beams. - - :ref:`NXdetector` - Added fields to describe electron detectors (MCP+Phospor screen, delay lines etc.). - - :ref:`NXentry` - Added fields to describe an experiment. - - :ref:`NXprocess` - Added subclasses and collective processing descriptors. - - :ref:`NXsample` - Added descriptors specific to photoemission experiments. - - :ref:`NXsource` - Added descriptors for laboratory sources (X-ray, UV lamps) but mostly for ultrafast lasers with complex time structures. - - :ref:`NXinstrument` - Added descriptors for the overall resolutions of the experiment (energy, momentum, angular, spatial, temporal). From e56c5e1006c491cff9576280d2cc5672234d8aed Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Mon, 24 Jul 2023 13:30:35 +0200 Subject: [PATCH 0067/1012] Remaining refactoring to remove unnecessary duplicates of old fairmat-proposal introductions and explanations which have now been replaced by the respective subgroups in contributed_classes, fixed typos, rerouted ci pipeline to point to fairmat branch --- .github/workflows/ci.yaml | 4 +- .../NXelectronanalyser.nxdl.xml | 6 +- dev_tools/docs/nxdl_index.py | 2 + manual/source/apm-structure.rst | 24 +- manual/source/cgms-structure.rst | 287 +--------------- .../contributed_definitions/apm-structure.rst | 310 +++++++++--------- .../cgms-structure.rst | 240 ++++++-------- .../ellipsometry-structure.rst | 6 +- .../contributed_definitions/em-structure.rst | 79 +++-- .../icme-structure.rst | 37 +++ .../mpes-structure.rst | 4 +- .../sample-prep-structure.rst | 20 ++ .../transport-structure.rst | 4 +- manual/source/conf.py | 2 +- manual/source/ellipsometry-structure.rst | 2 +- manual/source/em-structure.rst | 29 +- manual/source/icme-structure.rst | 9 + manual/source/img/FAIRmat_new.png | Bin 0 -> 24990 bytes manual/source/img/FAIRmat_new_with_text.png | Bin 0 -> 29306 bytes manual/source/index.rst | 3 +- manual/source/laboratory-structure.rst | 22 +- manual/source/mpes-structure.rst | 2 +- manual/source/north-structure.rst | 274 +--------------- manual/source/stm-structure.rst | 19 +- manual/source/transport-structure.rst | 22 +- 25 files changed, 424 insertions(+), 983 deletions(-) create mode 100644 manual/source/classes/contributed_definitions/icme-structure.rst create mode 100644 manual/source/classes/contributed_definitions/sample-prep-structure.rst create mode 100644 manual/source/icme-structure.rst create mode 100644 manual/source/img/FAIRmat_new.png create mode 100644 manual/source/img/FAIRmat_new_with_text.png diff --git a/.github/workflows/ci.yaml b/.github/workflows/ci.yaml index 74a8eaa38b..b174615f3a 100755 --- a/.github/workflows/ci.yaml +++ b/.github/workflows/ci.yaml @@ -3,10 +3,10 @@ name: CI on: push: branches: - - main # push commit to the main branch + - fairmat # push commit to the fairmat branch pull_request: branches: - - main # pull request to the main branch + - fairmat # pull request to the fairmat branch workflow_dispatch: # allow manual triggering inputs: deploy: diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml index dfc4b339a6..821edaae2d 100644 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -28,13 +28,13 @@ - Number of fast axes (axes acquired symultaneously, without scanning a pysical - quantity) + Number of fast axes (axes acquired simultaneously, without scanning a + physical quantity) - Number of slow axes (axes acquired scanning a pysical quantity) + Number of slow axes (axes acquired scanning a physical quantity) diff --git a/dev_tools/docs/nxdl_index.py b/dev_tools/docs/nxdl_index.py index a116720e0c..93b0692950 100644 --- a/dev_tools/docs/nxdl_index.py +++ b/dev_tools/docs/nxdl_index.py @@ -73,6 +73,8 @@ def nxdl_indices() -> Dict[str, dict]: rst_lines.append(f"{indentation}apm-structure\n") rst_lines.append(f"{indentation}transport-structure\n") rst_lines.append(f"{indentation}cgms-structure\n") + rst_lines.append(f"{indentation}icme-structure\n") + rst_lines.append(f"{indentation}sample-prep-structure\n") for cname in sorted(classes): rst_lines.append(f"{indentation}{cname}\n") diff --git a/manual/source/apm-structure.rst b/manual/source/apm-structure.rst index d7e94f6af1..84ff91a115 100644 --- a/manual/source/apm-structure.rst +++ b/manual/source/apm-structure.rst @@ -1,27 +1,9 @@ -.. _Apm-Structure1: +.. _Apm-Structure-Fairmat: ========================= B5: Atom-probe tomography ========================= -.. index:: - IntroductionApm1 - ApmAppDef1 +Atom probe tomography and related field-ion microscopy, aka atom probe microscopy (techniques) cover metrology methods with an origin in the materials science and condensed-matter physics communities. With its maturation and commercialization in the last two decades atom probe is increasingly being used for characterization of bio materials and fundamental science of field evaporation physics. - -.. _IntroductionApm1: - -Introduction -############## - -Set of data storage objects to describe the acquisition/measurement side, the reconstruction, and the ranging for atom probe microscopy experiments. The data storage objects can be useful as well for field-ion microscopy experiments. - -.. _ApmAppDef1: - -Application Definitions -####################### - -We created one new application definition whose intention is to serve both the description of atom probe tomography and field-ion microscopy measurements: - - :ref:`NXapm`: - A general application definition with many detailed places for leaving metadata and computational steps described which are commonly used when reporting the measurement of atom probe data including also detector hit data, as well as how to proceed with reconstructing atom positions from these data, and how to store details about definitions made, which describe how mass-to-charge-state ratio values are mapped to iontypes (ranging). +A status report of the ongoing work on data schemas for atom probe using NeXus is available here: :ref:`Apm-Structure`. diff --git a/manual/source/cgms-structure.rst b/manual/source/cgms-structure.rst index cb32812b3c..4a4950933d 100644 --- a/manual/source/cgms-structure.rst +++ b/manual/source/cgms-structure.rst @@ -1,284 +1,9 @@ -.. _CgmsFeatures-Structure1: +.. _Cg-Structure-Fairmat: -========================= -Geometry & Microstructure -========================= +====================== +Computational geometry +====================== -.. index:: - IntroductionCgms1 - PhysicsCgms1 - CgmsAppDef1 - CgmsBC1 - IcmeMsModels1 +Computational geometry is a frequently used tool for describing the shape and geometry of structural features in materials and components of instruments used for materials characterization. NeXus has a long history of base classes which serve these purposes. Upon closer inspection during the first year of the FAIRmat project, we found though that the collection of base classes could profit from an extension to make working with computational geometry data in NeXus simpler and more fine-grained. - -.. _IntroductionCgms1: - -Introduction -############ - -The computational-geometry/microstructure-modeling-based part of the proposal -has the following aims: - -First, we would like to contribute to efforts on standardizing a controlled -vocabulary, definitions for these terms, and relations between the terms, for -computational-geometry-based descriptions of the microstructure of materials -and atomic configurations used when characterizing materials in experiments -and computer simulations. - -As far as NeXus is concerned, the here proposed distinct sets of simple -geometric primitives and shapes offer a complementary alternative to the -already existent base classes in NeXus for constructive solid geometry -such as :ref:`NXcsg`, :ref:`NXoff_geometry`, or :ref:`NXquadric` to name but a few. - -Second, we would like to explore with this proposal how we can harmonize terms -frequently used by materials scientists in the field of condensed-matter physics -with definitions and terms offer by the NOMAD MetaInfo description. - -Third, the proposal should yield a substantiated set of arguments and suggestions -how descriptors for the structure and atomic architecture of materials can be -harmonized. With this we especially would like to reach out and intensify the -cooperation between the materials-science-related consortia of the German -National Research Infrastructure, specifically, FAIRmat, NFDI-MatWerk, NFDI4Ing, -NFDI4Chem, NFDI4Cat, MaRDi, and DAPHNE. - -.. The proposal reaches out to our colleagues in the materials engineering-based -.. consortia to document that there is value in discussing about controlled vocabulary. - -.. _PhysicsCgms1: - -Physics background -################## -Microstructural features or crystal defects are spatial arrangements of atoms. -Given their specific atomic arrangement and composition, such features have -specific constraints on the degrees of freedom how atoms can arrange. This causes -that these defects have specific properties. -Provided well-defined coarse-graining procedures are used and regions-of-interest -and/or regions-of-applicability are defined, microstructural features are often -characterized and modelled to have associated thermodynamic descriptors. - -Another motivation for the proposal was the observation that frequently the design -of file formats for simulation software in the computational materials science especially -those tools at the interface between condensed-matter physics and materials engineering -are frequently reimplementing the wheel (at least partly) when it comes to decide how to store -e.g. atom and feature positions or shape of regions-of-interest, grids, crystals, -grains, precipitates, and dislocations. - -Maybe this is a historical burden given the large set of technical terms and jargon -in place, which then motivated pragmatic solutions that resulted in many research groups -have developed similar formats using similar descriptions. - -We see this work on base classes and application definitions not primarily an -effort to improve and extend NeXus for now. Rather this part of the proposal -is an effort to support activities in materials science to work towards -common terminology and using controlled vocabularies more frequently. -These are the foundation for more sophisticated thoughts about practically -useful ontologies. - -Defining crystal defects is a question of how to coarse-grain a given spatio- -temporal set of atoms, each having a nuclid type and position/trajectory. -In most cases, such a coarse-graining is an ill-posed task because different -mathematical/geometrical methods exists how a point, a line, a surface, or a volumetric defect -can be described and be spatio-temporally constrained through a geometrical model -with defined geometric primitives and associated coarser-scale properties. - -The key motivation to such coarse-graining is to reduce the complexity of the -description. On the one hand to support visualization and scientific analyses - not only -of crystal defect arrangements. On the other hand it is the hope that using descriptors -at a coarser level, i.e. nanometer, micrometer, and larger, it is still possible -to find sufficiently accurate and precise descriptors which avoid that one has -to account for the dynamics of each atom to predict or understand the properties -of defects and their dynamics. - -Nevertheless, experience has shown that computational-geometry-based descriptions -when combined with hierarchical clustering/labeling methods, applied on set of -atoms and features turn out to yield useful descriptors. Examples include point, -line, surface defects, such as vacancies, solute cluster, dislocations, -disconnections, interfaces to name but a few. - -.. _CgmsBC1: - -Base Classes -############ - -We propose the following base classes, starting with a set of descriptors -for frequently used shapes and geometric primitives: - - :ref:`NXcg_sphere_set`: - A description for a set of possibly dissimilar spheres. - - :ref:`NXcg_ellipsoid_set`: - A description for a set of possibly dissimilar rotated ellipsoids. - - :ref:`NXcg_cylinder_set`: - A description for a set of possibly dissimilar rotated cylinders. - - :ref:`NXcg_point_set`: - A collection of points with labels or mark data. - - :ref:`NXcg_polyline_set`: - A collection of lines and linearized segments. - - :ref:`NXcg_triangle_set`: - A collection (or soup) of triangles. - - :ref:`NXcg_parallelogram_set`: - A collection of possibly dissimilar parallelograms. - - :ref:`NXcg_triangulated_surface_mesh`: - A mesh of triangles. - - :ref:`NXcg_polygon_set`: - A collection (or soup) of polygons. - - :ref:`NXcg_polyhedron_set`: - A collection (or soup) of polyhedra. - - :ref:`NXcg_roi_set`: - A container to host a number of different types of primitives. - - :ref:`NXcg_tetrahedron_set`: - A collection (or soup) of tetrahedra. - - :ref:`NXcg_hexahedron_set`: - A collection (or soup) of hexahedra with capabilities to represent - also simpler (bounding) boxes for e.g. binary trees. - -These base classes make use of new base classes which describe data structures: - - :ref:`NXcg_face_list_data_structure`: - In essence, the usual way how polygon/polyhedra data are reported: - Via a list of vertices and faces with identifier and properties. - - :ref:`NXcg_half_edge_data_structure`: - A half-edge data structure is a useful complementary descriptor for - polygon/polyhedra which enables topological analyses and traversal - of the graph how polygons and polyhedra can alternatively be described. - - :ref:`NXcg_unit_normal_set`: - As an additional structuring element especially for meshes, well-documented - normal information is crucial for distance computations. - - :ref:`NXcg_geodesic_mesh`: - Geodesic meshes are useful for all applications when meshing the surface - of a sphere. - - :ref:`NXcg_alpha_complex`: - Alpha shapes and alpha wrappings, specifically the special case of the - convex hull, are frequently used geometrical models for describing - a boundary or edge to a set of geometric primitives. - -Furthermore, we propose a few base classes for operations when working with -discretized representations of material (area or volume) which can be useful -not only for stencil-based methods: - - :ref:`NXcg_grid`: - A grid of cells. - - :ref:`NXisocontour`: - A description for isocontour descriptions. - - :ref:`NXcg_marching_cubes`: - An approach to store metadata of a specific implementation of - the Marching Cubes algorithm, whose sensitivity to specific topological - configurations is known to result in different triangle soups. - - :ref:`NXdelocalization`: - An approach to document procedures whereby a scalar field - is smoothened in a controlled manner. - -Assuming that these base classes can serve as building blocks, we would like -to test with the proposal also how these base classes can be applied in base -classes for specific types of microstructural features and/or utility classes -to hold metadata for these features: - - :ref:`NXsimilarity_grouping`: - An alias for NXclustering. - - :ref:`NXclustering`: - A description for clustering of objects (such as atoms or features). - - :ref:`NXorientation_set`: - A set of rotations to describe the relative orientation of members of a set of features/objects. - - :ref:`NXslip_system_set`: - Metadata to a set of slip system/slip system family for - a given crystal structure. - - :ref:`NXms_feature_set`: - Generic base class to describe any nested set of features - of a microstructure at the continuum-, micron-, nano-scale, or - to represent a topology of molecules and atoms. - - :ref:`NXms_snapshot`: - A container to describe the state of microstructural features - at a given point in time. - - :ref:`NXms_snapshot_set`: - The corresponding class to hold a set of :ref:`NXms_snapshot` objects. - - :ref:`NXchemical_composition`: - (Chemical) composition of a sample or a set of things. - -Furthermore, we found that it can be useful to have a set of base classes with -which software documents it state and gives a summary for users about the performance -and elapsed time measured while processing data. These utility classes include: - - :ref:`NXprogram`: - A named and version of a program of library/component of a larger software framework. - - :ref:`NXcs_filter_boolean_mask`: - A boolean mask. - - :ref:`NXcs_prng`: - Metadata of a pseudo-random number generator (PRNG) algorithm. - - :ref:`NXcs_profiling`: - A structuring group holding a set of :ref:`NXcs_profiling_event` instances. - - :ref:`NXcs_profiling_event`: - Profiling/benchmark data to an event of - tracking an algorithm/computational step. - - :ref:`NXcs_computer`: - Metadata of a computer. - - :ref:`NXcs_cpu`: - Metadata of a central processing unit. - - :ref:`NXcs_gpu`: - Metadata of a graphical processing unit / accelerator. - - :ref:`NXcs_mm_sys`: - Metadata of the (main) memory (sub-)system. - - :ref:`NXcs_io_sys`: - Metadata of the input/output system. - - :ref:`NXcs_io_obj`: - Metadata of a component storing data of an :ref:`NXcs_io_sys` instance. - -.. _IcmeMsModels1: - -Application definitions for ICME models -####################################### - -To bridge to our colleagues from the NFDI-MatWerk and NFDI4Ing consortia we -have created an example how the proposed components of the nexus-fairmat-proposal -can be used to create data schemes for vanilla-type ICME microstructure models. -ICME is an abbreviation for Integrated Computational Materials Engineering, which -is a design strategy and workflow whereby physics-based modelling of microstructure -evolution at the mesoscopic scale is used to understand the relations between -the microstructure and technological relevant descriptors for the properties -of materials. - -To begin with we propose the following draft application definitions. - - :ref:`NXms`: - An application definition for arbitrary spatiotemporally resolved simulations. - - :ref:`NXms_score_config`: - A specific example how :ref:`NXapm_paraprobe_config_ranger` can be specialized for documenting the configuration of a computer simulation with the static recrystallization cellular automata model SCORE. - - :ref:`NXms_score_results`: - A specific example how :ref:`NXms` can be specialized for documenting results of computer simulations with the static recrystallization cellular automata model SCORE. +A status report of this ongoing work is available here: :ref:`CgmsFeatures-Structure`. diff --git a/manual/source/classes/contributed_definitions/apm-structure.rst b/manual/source/classes/contributed_definitions/apm-structure.rst index 10e2c77c36..1e8b361527 100644 --- a/manual/source/classes/contributed_definitions/apm-structure.rst +++ b/manual/source/classes/contributed_definitions/apm-structure.rst @@ -1,36 +1,33 @@ .. _Apm-Structure: -========================= +===================== Atom-probe tomography -========================= +===================== .. index:: IntroductionApm ApmAppDef ApmBC - WhatHasBeenAchieved + StatusQuoApm ApmParaprobeAppDef ApmParaprobeNewBC - NextStep - - .. _IntroductionApm: Introduction -############## +############ -Set of data storage objects to describe the acquisition/measurement side, the reconstruction, and the ranging for atom probe microscopy experiments. The data storage objects can be useful as well for field-ion microscopy experiments. +Set of data schemas to describe the acquisition, i.e. measurement side, the extraction of hits from detector raw data, +steps to compute mass-to-charge state ratios from uncorrected time of flight data, the reconstruction, and the ranging, +i.e. identification of peaks in the mass-to-charge-state ratio histogram to detect (molecular) ions. +The data schemas can be useful to generate data artifacts also for field-ion microscopy experiments. .. _ApmAppDef: Application Definition ###################### -It is proposed to use one application definition to serve atom probe tomography -and field-ion microscopy measurements, i.e. the data collection with the instrument: - :ref:`NXapm`: A general application definition with many detailed places for leaving metadata and computational steps described which are commonly used when reporting the measurement of atom probe data including also detector hit data, as well as how to proceed with reconstructing atom positions from these data, and how to store details about definitions made, which describe how mass-to-charge-state ratio values are mapped to iontypes in a process called ranging. @@ -43,178 +40,209 @@ The following base classes are proposed to support modularizing the storage of p :ref:`NXchamber`: A base class to describe a component of the instrument which houses other components. - A chamber may offer a controlled atmosphere to execute an experiment and/or offer functionalities for storing and loading specimens. + A chamber may offer a controlled atmosphere to execute an experiment and/or offer functionalities + for storing and loading specimens. :ref:`NXcoordinate_system_set` A base class to describe different coordinate systems used and/or to be harmonized or transformed into one another when interpreting the dataset. :ref:`NXion`: - A base class to describe charged molecular ions with an adjustable number of atoms/isotopes building each ion. Right now the maximum number of atoms supported building a molecular ion - is 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with - which all possible isotopes can be described. + A base class to describe molecular ions with an adjustable number of atoms/isotopes building each ion. + For the usage in atom probe research the maximum number of atoms supported building a molecular ion + is currently set to a maximum of 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with + which all possible isotopes (stable, radioactive, or synthetically generated ones) can be described. :ref:`NXfabrication`: - A base class to bundle manufacturer/technology-partner-specific details about a - component or device of an instrument. + A base class to bundle manufacturer/technology-partner-specific details about + a component or device of an instrument. :ref:`NXpeak`: A base class to describe peaks mathematically to detail how peaks in - mass-to-charge-state ratio histograms (aka mass spectra) are - defined and labelled as iontypes. + mass-to-charge-state ratio histograms (aka mass spectra) are defined and + labelled as iontypes. :ref:`NXpump`: - A base class to describe details about pump(s) of an instrument. + A base class to describe details about pump(s) used as components of an instrument. :ref:`NXpulser_apm`: - A base class to describe the high-voltage and/or laser pulsing capabilities of - an atom probe microscope. + A base class to describe the high-voltage and/or laser pulsing capabilities. :ref:`NXreflectron`: A base class to describe a kinetic-energy-sensitive filtering device - for time of flight (ToF) mass spectrometry. + for time-of-flight (ToF) mass spectrometry. :ref:`NXstage_lab`: A base class to describe the specimen fixture including the cryo-head. - Nowadays, these stages represent small-scale laboratory platforms. + Nowadays, stages of microscopes represent small-scale laboratory platforms. Therefore, there is a need to define the characteristics of such stages in more detail, especially in light of in-situ experiments. Many similarities exists between a stage - in an electron microscope and one in an atom probe instrument. Both offer fixture functionalities and additional components for applying e.g. stimuli on the specimen. + in an electron microscope and one in an atom probe instrument. Both offer fixture + functionalities and additional components for applying e.g. stimuli on the specimen. -Microscopy experiments, not only taking into account those performed on commercial instruments, offer the user usually to apply a set of data processing steps. Some of them are frequently applied on-the-fly. For now we represent these steps with specifically named instances of the :ref:`NXprocess` base class. +Microscopy experiments, not only taking into account those performed on commercial instruments, offer users to apply a set of +data processing steps. Some of them are frequently applied on-the-fly. For now we represent these steps with specifically named +instances of the :ref:`NXprocess` base class. +Data processing steps are essential to transform measurements into knowledge. Therefore, these steps +should be documented to enable reproducible research, ideally numerically, and learn how pieces of information are connected. +In what follows, an example is presented how an open-source community software can be modified to use descriptions +of these computational steps. + +The respective research software here is the `paraprobe-toolbox `_ +The software is developed by `M. Kühbach et al. `_. +For atom probe research the proposal can also serve as a blue print how computational steps of other software +tool including commercial ones could be developed further to benefit from NeXus. -Like every research community data processing steps are essential to transform measurements -into knowledge. These processing steps should be documented to enable reproducible research -and learn how pieces of information were connected. In what follows, an example is presented -how an open-source community software can be modified to use descriptions of these computational -steps. The respective research software here is the `paraprobe-toolbox `_ .. _IntroductionApmParaprobe: apmtools ######## -One tool is the paraprobe-toolbox software package in the the apmtools container. -The software is developed by `M. Kühbach et al. `_. - -Here we show how NeXus is used to consistently define application definitions for scientific software -in the field of atom probe. In this community the paraprobe-toolbox is an example of an -open-source parallelized software for analyzing point cloud data, for assessing meshes in -3D continuum space, and for studying the effects of parameterization on descriptors -which describe the micro- and nanostructure of materials that are studied with -atom probe microscopy. +The paraprobe-toolbox is an example of an open-source parallelized software for analyzing +point cloud data, for assessing meshes in 3D continuum space, and for studying the effects of +parameterization on descriptors of micro- and nanoscale structural features (crystal defects) +within materials when characterized and studied with atom probe. The need for a thorough documentation of the tools in not only the paraprobe-toolbox was motivated by several needs: -First, users of software would like to better understand and also be able to -study for themselves which individual parameters and settings for each tool exist -and how configuring these affects their analyses quantitatively. +First, users of software would like to better understand and also be able to study for themselves +which individual parameters and settings for each tool exist and how configuring these +affects analyses quantitatively. This stresses the aspect how to improve documentation. -Second, scientific software like the tools in the paraprobe-toolbox implement a -numerical/algorithmical (computational) workflow whereby data from multiple input sources -(like previous analysis results) are processed and carried through more involved analysis -within several steps inside the tool. The tool then creates output as files. +Second, scientific software like paraprobe-toolbox implement numerical/algorithmical +(computational) workflows whereby data coming from multiple input sources +(like previous analysis results) are processed and carried through more involved analyses +within several steps inside the tool. The tool then creates output as files. This +provenance and workflow should be documented. Individual tools of paraprobe-toolbox are developed in C/C++ and/or Python. Provenance tracking is useful as it is one component and requirement for making -workflows exactly numerically reproducible and thereby empower scientists -to fulfill better the "R", i.e. reproducibility of their daily FAIR research practices. - -The paraprobe-toolbox is one example of a software which implements a workflow -via a sequence of operations executed within a jupyter notebook -(or Python script respectively). Specifically, individual tools are chained. -Convenience functions are available to create well-defined input/configuration -files for each tool. These config files instruct the tool upon processing. - -In this design, each workflow step (with a tool) is in fact a pair (or triple) of -at least two sub-steps: i) the creation of a configuration file, -ii) the actual analysis using the Python/or C/C++ tools, -iii) the optional post-processing/visualizing of the results inside the NeXus/HDF5 -files generated from each tool run using other software. +workflows exactly numerically reproducible and thus to enable reproducibility (the "R" +of the FAIR principles of data stewardship). +For tools of the paraprobe-toolbox each workflow step is a pair or triple of sub-steps: +1. The creation of a configuration file. +2. The actual analysis using the Python/or C/C++ tools. +3. The optional analyses/visualization of the results based on data in NeXus/HDF5 files generated by each tool. -.. _WhatHasBeenAchieved: +.. _StatusQuoApm: What has been achieved so far? ############################## -This proposal summarizes work of members of the FAIRmat project, which is part -of the German National Research Data Infrastructure aimed at a change of the paraprobe-toolbox -and its interaction with files for all tools so that only well-defined configuration files -are accepted as input and results end up as specifically formatted output. For this -NeXus application definitions are used. - -Data and metadata between the tools are exchanged with NeXus/HDF5 files. -Specifically, we created for each tool an application definition (see below) -which details all possible settings and options for the configuration as to -guide users. The config(uration) files are currently implemented as HDF5 files, -whose content matches to the naming conventions of the respective `config` application -definition for each tool. As an example NXapm_paraprobe_config_surfacer specifies +This proposal summarizes work of members of the FAIRmat project, which is part of the `German +National Research Data Infrastructure `_. The here detailed +proposal documents how all tools of the paraprobe-toolbox were modified to generate +only well-defined configuration files as accepted input and yield specifically formatted output +files according to the following NeXus application definitions. + +Data and metadata between the tools are exchanged with NeXus/HDF5 files. This means that data +inside HDF5 binary containers are named, formatted, and hierarchically structured according +to application definitions. + +For example the application definition NXapm_paraprobe_config_surfacer specifies how a configuration file for the paraprobe-surfacer tool should be formatted -and which parameter it should and/or may contain. +and which parameters it contains including optionality and cardinality constraints. -That is each config file uses a controlled vocabulary of terms. Furthermore, -the config files store a SHA256 checksum for each input file. -This implements a full provenance tracking on the input files along the -processing chain/workflow. +Thereby, each config file uses a controlled vocabulary of terms. Furthermore, +the config files store a SHA256 checksum for each input file. This implements a full +provenance tracking on the input files along the workflow. -As an example, a user may first range their reconstruction and then compute +As an example, a user may first range their reconstruction and then compute spatial correlation functions. The config file for the ranging tool stores the files which hold the reconstructed ion position and ranging definitions. -The ranging tool generates a results file with the ion type labels stored. +The ranging tool generates a results file with the labels of each molecular ion. This results file is formatted according to the tool-specific `results` -application definition. This results file and the reconstruction is -imported by the spatial statistics tool which again keeps track of all files. - -This design makes it possible to rigorously trace which numerical results -were achieved with a specific input and settings using specifically-versioned tools. +application definition. The generated results file and the reconstruction is +imported by the spatial statistics tool which again keeps track of all files +and reports its results in a spatial statistics tool results file. -We understand that this additional handling of metadata and provenance tracking -may not be at first glance super relevant for scientists or appears to be an -unnecessarily complex feature. There is indeed an additional layer of work which -came with the development and maintenance of this functionality. +This design makes it possible to rigorously trace which numerical results were achieved +with specific inputs and settings using specifically-versioned tools. Noteworthy +this includes Y-junction on a graph which is where multiple input sources are +combined to generate new results. -However, we are convinced that this is the preferred way of performing software -development and data analyses as it enables users to take advantage of a completely -automated provenance tracking which happens silently in the background. +We are convinced that defining, documenting, using, and sharing application definitions +is useful and future-proof strategy for software development and data analyses as it enables +automated provenance tracking which happens silently in the background .. _ApmParaprobeAppDef: Application Definitions ####################### -Application definitions for the input side (configuration) of each tool were defined. +NXapm_paraprobe application definitions are in fact pairs of application definitions. +One for the configuration (input) side and one for the results (output) side. For each +tool one such pair is proposed: :ref:`NXapm_paraprobe_config_transcoder`: Configuration of paraprobe-transcoder Load POS, ePOS, APSuite APT, RRNG, RNG, and NXapm HDF5 files. + :ref:`NXapm_paraprobe_results_transcoder`: + Results of paraprobe-transcoder + Store reconstructed positions, ions, and charge states. + + :ref:`NXapm_paraprobe_config_ranger`: Configuration of paraprobe-ranger Apply ranging definitions and explore possible molecular ions. + :ref:`NXapm_paraprobe_results_ranger`: + Results of paraprobe-ranger + Store applied ranging definitions and combinatorial analyses of all possible iontypes. + + :ref:`NXapm_paraprobe_config_selector`: Configuration of paraprobe-selector Defining complex spatial regions-of-interest to filter reconstructed datasets. + :ref:`NXapm_paraprobe_results_selector`: + Results of paraprobe-selector + Store which points are inside or on the boundary of complex spatial regions-of-interest. + + :ref:`NXapm_paraprobe_config_surfacer`: Configuration of paraprobe-surfacer Create a model for the edge of a point cloud via convex hulls, alpha shapes. + :ref:`NXapm_paraprobe_results_surfacer`: + Results of paraprobe-surfacer + Store triangulated surface meshes of models for the edge of a dataset. + + :ref:`NXapm_paraprobe_config_distancer`: Configuration of paraprobe-distancer Compute analytical distances between ions to a set of triangles. + :ref:`NXapm_paraprobe_results_distancer`: + Results of paraprobe-distancer + Store analytical distances between ions to a set of triangles. + + :ref:`NXapm_paraprobe_config_tessellator`: Configuration of paraprobe-tessellator Compute Voronoi cells for if desired all ions in a dataset. + :ref:`NXapm_paraprobe_results_tessellator`: + Results of paraprobe-tessellator + Store volume of all Voronoi cells about each ion in the dataset. + + :ref:`NXapm_paraprobe_config_nanochem`: Configuration of paraprobe-nanochem Compute delocalization, iso-surfaces, analyze 3D objects, and composition profiles. + :ref:`NXapm_paraprobe_results_nanochem`: + Results of paraprobe-nanochem + Store all results of delocalization, isosurface, and interface detection algorithms, + store all extracted triangulated surface meshes of found microstructural features, + store composition profiles and corresponding geometric primitives (ROIs). + + :ref:`NXapm_paraprobe_config_intersector`: Configuration of paraprobe-intersector Assess intersections and proximity of 3D triangulated surface meshes in @@ -222,55 +250,25 @@ Application definitions for the input side (configuration) of each tool were def extraction algorithms on the resulting shape, spatial arrangement, and colocation of 3D objects via graph-based techniques. + :ref:`NXapm_paraprobe_results_intersector`: + Results of paraprobe-intersector + Store graph of microstructural features and relations/link identified between them. + + :ref:`NXapm_paraprobe_config_spatstat`: Configuration of paraprobe-spatstat Spatial statistics on the entire or selected regions of the reconstructed dataset. + :ref:`NXapm_paraprobe_results_spatstat`: + Results of paraprobe-spatstat + Store spatial correlation functions. + + :ref:`NXapm_paraprobe_config_clusterer`: Configuration of paraprobe-clusterer Import cluster analysis results of IVAS/APSuite and perform clustering analyses in a Python ecosystem. -Application definitions for the output side (results) of each tool were defined. - - :ref:`NXapm_paraprobe_results_transcoder`: - Results of paraprobe-transcoder - Store reconstructed positions, ions, and charge states. - - :ref:`NXapm_paraprobe_results_ranger`: - Results of paraprobe-ranger - Store applied ranging definitions and combinatorial analyses of all possible iontypes. - - :ref:`NXapm_paraprobe_results_selector`: - Results of paraprobe-selector - Store which points are inside or on the boundary of complex spatial regions-of-interest. - - :ref:`NXapm_paraprobe_results_surfacer`: - Results of paraprobe-surfacer - Store triangulated surface meshes of models for the edge of a dataset. - - :ref:`NXapm_paraprobe_results_distancer`: - Results of paraprobe-distancer - Store analytical distances between ions to a set of triangles. - - :ref:`NXapm_paraprobe_results_tessellator`: - Results of paraprobe-tessellator - Store volume of all Voronoi cells about each ion in the dataset. - - :ref:`NXapm_paraprobe_results_nanochem`: - Results of paraprobe-nanochem - Store all results of delocalization, isosurface, and interface detection algorithms, - store all extracted triangulated surface meshes of found microstructural features, - store composition profiles and corresponding geometric primitives (ROIs). - - :ref:`NXapm_paraprobe_results_intersector`: - Results of paraprobe-intersector - Store graph of microstructural features and relations/link identified between them. - - :ref:`NXapm_paraprobe_results_spatstat`: - Results of paraprobe-spatstat - Store spatial correlation functions. - :ref:`NXapm_paraprobe_results_clusterer`: Results of paraprobe-clusterer Store results of cluster analyses. @@ -282,45 +280,33 @@ Base Classes We envision that the above-mentioned definitions can be useful not only to take inspiration for other software tools in the field of atom probe but also to support -a discussion towards a stronger standardization of the vocabulary used. -Therefore, we are happy for comments and suggestions. - -The majority of data analyses in atom probe use a common set of operations and -conditions on the input data even though this might not be immediately evident -or might not have been so explicitly communicated in the literature. -Some tools have a specific scope because of which algorithms are hardcoded -to work for specific material systems. A typical example is a ranging tool -which exploits that all the examples it is used for apply to a specific material -and thus specific iontypes can be hardcoded. - -Instead, we are convinced it is better to follow a more generalized approach. -The following base classes and the above application definitions present examples -how one can use NeXus for this. +a discussion towards a stronger standardization of the vocabulary used. This is an +ongoing discussion in the field emission community `IFES `_. +We are happy for taking comments and suggestions. The use of base classes for atom probe +is motivated by the observation that the majority of data analyses in atom probe +use a common set of operations and conditions on the input data: :ref:`NXapm_input_reconstruction`: - A description from which file the reconstructed ion positions are imported. + A base class documenting from where reconstructed ion positions are imported. :ref:`NXapm_input_ranging`: - A description from which file the ranging definitions are imported. + A base class documenting from where ranging definitions are imported. The design of the ranging definitions is, thanks to :ref:`NXion`, so - general that all possible nuclids can be considered, be they observationally - stable, be they radioactive or transuranium nuclids. + general that all possible nuclids can be considered. -A detailed inspection of spatial and other type of filters frequently used in -analysis of atom probe data revealed that it is better to define atom-probe-agnostic, -i.e. more general filters: +A detailed inspection of spatial and other type of filters frequently used in analysis of atom probe +data revealed that it is better to define atom-probe-agnostic reusable concepts for filters: :ref:`NXspatial_filter`: - A proposal how a point cloud can be spatially filtered in a specific yet general manner. + A base class proposing how a point cloud can be spatially filtered in a specific yet general manner. This base class takes advantage of :ref:`NXcg_ellipsoid_set`, :ref:`NXcg_cylinder_set`, - and :ref:`NXcg_hexahedron_set` to cater for all of the most commonly used - geometric primitives in atom probe. + and :ref:`NXcg_hexahedron_set` to cater for commonly used geometric primitives in atom probe. + The primitives are used for defining the shape and extent of a region of interest (ROI). :ref:`NXsubsampling_filter`: - A proposal for a filter that can also be used for specifying how entries + A base class for a filter that can also be used for specifying how entries like ions can be filtered via sub-sampling. :ref:`NXmatch_filter`: - A proposal for a filter that can also be used for specifying how entries - like ions can be filtered based on their type (ion species) - or hit multiplicity. + A base class for a filter that can also be used for specifying how entries + like ions can be filtered based on their type or other descriptors like hit multiplicity. diff --git a/manual/source/classes/contributed_definitions/cgms-structure.rst b/manual/source/classes/contributed_definitions/cgms-structure.rst index 7bc1621393..61e4a0bb82 100644 --- a/manual/source/classes/contributed_definitions/cgms-structure.rst +++ b/manual/source/classes/contributed_definitions/cgms-structure.rst @@ -1,15 +1,14 @@ .. _CgmsFeatures-Structure: -========================= -Geometry & Microstructure -========================= +============================ +Geometry and microstructures +============================ .. index:: IntroductionCgms PhysicsCgms CgmsAppDef CgmsBC - IcmeMsModels .. _IntroductionCgms: @@ -20,30 +19,23 @@ Introduction The computational-geometry/microstructure-modeling-based part of the proposal has the following aims: -First, we would like to contribute to efforts on standardizing a controlled -vocabulary, definitions for these terms, and relations between the terms, for -computational-geometry-based descriptions of the structure of materials and -atomic configurations used when characterizing materials in experiments +First, to contribute to efforts on standardizing a controlled vocabulary, definitions for terms, +and relations between terms, for computational-geometry-based descriptions of the structure of +materials and atomic configurations used when characterizing materials in experiments and computer simulations. -As far as NeXus is concerned, the here proposed distinct sets of simple -geometric primitives and shapes offer a complementary alternative to the -already existent base classes in NeXus for constructive solid geometry -such as :ref:`NXcsg`, :ref:`NXoff_geometry`, or :ref:`NXquadric` to name but a few. +As far as NeXus is concerned, the here proposed distinct sets of geometric primitives offer +a complementary alternative to the already existent base classes in NeXus for +constructive solid geometry (CSG) such as :ref:`NXcsg`, :ref:`NXoff_geometry`, or :ref:`NXquadric`. -Second, we would like to explore with this proposal how we can harmonize terms -frequently used by materials scientists in the field of condensed-matter physics -with definitions and terms offer by the NOMAD MetaInfo description. +Second, to explore how terms which are frequently used by materials scientists in the field of +condensed-matter physics can be harmonized with definitions and terms offer by the NOMAD MetaInfo +description. NOMAD MetaInfo is the data schema of the NOMAD research data management system. -Third, the proposal should yield a substantiated set of arguments and suggestions -how descriptors for the structure and atomic architecture of materials can be -harmonized. With this we especially would like to reach out and intensify the -cooperation between the materials-science-related consortia of the German -National Research Infrastructure, specifically, FAIRmat, NFDI-MatWerk, NFDI4Ing, -NFDI4Chem, NFDI4Cat, MaRDi, and DAPHNE. - -.. The proposal reaches out to our colleagues in the materials engineering-based -.. consortia to document that there is value in discussing about controlled vocabulary. +Third, to yield a substantiated set of arguments and suggestions how descriptors for the structure +and the atomic architecture of materials can be harmonized. Especially this proposal reaches out to +other materials-science-related projects and consortia including the activities in the German NFDI +FAIRmat, NFDI-MatWerk, NFDI4Ing, NFDI4Chem, NFDI4Cat, MaRDI, and DAPHNE. .. _PhysicsCgms: @@ -51,47 +43,38 @@ Physics background ################## Microstructural features or crystal defects are spatial arrangements of atoms. Given their specific atomic arrangement and composition, such features have -specific constraints on the degrees of freedom how atoms can arrange. This causes -that these defects have specific properties. -Provided well-defined coarse-graining procedures are used and regions-of-interest -and/or regions-of-applicability are defined, microstructural features are often -characterized and modelled to have associated thermodynamic descriptors. +specific constraints on the degrees of freedom. This equips these defects with specific +properties (thermodynamic observables/descriptors). Provided well-defined coarse-graining procedures +are used and regions-of-interest and/or regions-of-applicability are defined, microstructural +features are often characterized and modelled to have associated thermodynamic descriptors. Another motivation for the proposal was the observation that frequently the design of file formats for simulation software in the computational materials science especially -those tools at the interface between condensed-matter physics and materials engineering -are frequently reimplementing the wheel (at least partly) when it comes to decide how to store -e.g. atom and feature positions or shape of regions-of-interest, grids, crystals, -grains, precipitates, and dislocations. - -Maybe this is a historical burden given the large set of technical terms and jargon -in place, which then motivated pragmatic solutions that resulted in many research groups -have developed similar formats using similar descriptions. - -We see this work on base classes and application definitions not primarily an -effort to improve and extend NeXus for now. Rather this part of the proposal -is an effort to support activities in materials science to work towards -common terminology and using controlled vocabularies more frequently. -These are the foundation for more sophisticated thoughts about practically -useful ontologies. - -Defining crystal defects is a question of how to coarse-grain a given spatio- -temporal set of atoms, each having a nuclid type and position/trajectory. -In most cases, such a coarse-graining is an ill-posed task because different -mathematical/geometrical methods exists how a point, a line, a surface, or a volumetric defect -can be described and be spatio-temporally constrained through a geometrical model -with defined geometric primitives and associated coarser-scale properties. - -The key motivation to such coarse-graining is to reduce the complexity of the -description. On the one hand to support visualization and scientific analyses - not only -of crystal defect arrangements. On the other hand it is the hope that using descriptors -at a coarser level, i.e. nanometer, micrometer, and larger, it is still possible -to find sufficiently accurate and precise descriptors which avoid that one has +at the interface between condensed-matter physics and materials engineering are frequently +reimplementing the wheel when it comes to making decision how to store e.g. atom and feature positions +or how to document the shape of regions-of-interest, grids, crystals, grains, precipitates, and dislocations. +This generates a diversity of file formats and data schemas which hampers semantic interpretation +and interoperability. + +Maybe this is a historical burden given the large set of technical terms in place which then +motivated pragmatic solutions that have resulted in many research groups having developed +similar formats using similar descriptions. + +Defining crystal defects is a question of how to coarse-grain a given spatio-temporal set of atoms, +each having a nuclid type and position/trajectory. In most cases, such a coarse-graining is an ill-posed +task because different mathematical/geometrical methods exists how a point, a line, a surface, or a volumetric +defect can be described and be spatio-temporally constrained through a geometrical model +with defined primitives and associated observables. + +The key motivation to such coarse-graining is to reduce the complexity of the description. +On the one hand to support visualization and scientific analyses - not only of crystal defect arrangements. +On the other hand it is the hope that using descriptors at a coarser level, i.e. nanometer, micrometer, and larger, +are still sufficiently accurate and precise to yield descriptors which avoid that one has to account for the dynamics of each atom to predict or understand the properties of defects and their dynamics. -Nevertheless, experience has shown that computational-geometry-based descriptions -when combined with hierarchical clustering/labeling methods, applied on set of +Experience has shown that computational-geometry-based descriptions +when combined with hierarchical clustering/labeling methods, applied on sets of atoms and features turn out to yield useful descriptors. Examples include point, line, surface defects, such as vacancies, solute cluster, dislocations, disconnections, interfaces to name but a few. @@ -101,68 +84,68 @@ disconnections, interfaces to name but a few. Base Classes ############ -The following base classes are defined to incentivize the use of NeXus for -using computational-geometry-based descriptions. In what follows, base classes +The following base classes are defined to incentivize the use of NeXus for using +computational-geometry-based descriptions. In what follows, base classes for frequently used shapes and geometric primitives are proposed: :ref:`NXcg_sphere_set`: - A description for a set of possibly dissimilar spheres. + A base class for a set of possibly dissimilar spheres. :ref:`NXcg_ellipsoid_set`: - A description for a set of possibly dissimilar rotated ellipsoids. + A base class for a set of possibly dissimilar rotated ellipsoids. :ref:`NXcg_cylinder_set`: - A description for a set of possibly dissimilar rotated cylinders. + A base class for a set of possibly dissimilar rotated cylinders. :ref:`NXcg_point_set`: - A collection of points with labels or mark data. + A base class for a collection of points with labels or mark data. :ref:`NXcg_polyline_set`: - A collection of lines and linearized segments. + A base class for a collection of lines and linearized segments. :ref:`NXcg_triangle_set`: - A collection (or soup) of triangles. + A base class for a collection (or soup) of triangles. :ref:`NXcg_parallelogram_set`: - A collection of possibly dissimilar parallelograms. + A base class for a collection of possibly dissimilar parallelograms. :ref:`NXcg_triangulated_surface_mesh`: - A mesh of triangles. + A base class for a collection and/or mesh of triangles. :ref:`NXcg_polygon_set`: - A collection (or soup) of polygons. + A base class for a collection (or soup) of polygons. :ref:`NXcg_polyhedron_set`: - A collection (or soup) of polyhedra. + A base class for a collection (or soup) of polyhedra. :ref:`NXcg_roi_set`: A container to host a number of different types of primitives. :ref:`NXcg_tetrahedron_set`: - A collection (or soup) of tetrahedra. + A base class for a collection (or soup) of tetrahedra. :ref:`NXcg_hexahedron_set`: - A collection (or soup) of hexahedra with capabilities to represent - also simpler (bounding) boxes for e.g. binary trees. + A base class for a collection (or soup) of hexahedra to represent + e.g. simpler (bounding) boxes for e.g. binary trees. These base classes make use of base classes which describe data structures: :ref:`NXcg_face_list_data_structure`: - In essence, the usual way how polygon/polyhedra data are reported: - Via a list of vertices and faces with identifier and properties. + A base class to store the usual way how polygon/polyhedra data are reported: + Via a list of vertices and faces with identifiers and properties. :ref:`NXcg_half_edge_data_structure`: + A base class for more advanced but more efficiently traversable data structure: A half-edge data structure is a useful complementary descriptor for - polygon/polyhedra which enables topological analyses and traversal - of the graph how polygons and polyhedra can alternatively be described. + polygon/polyhedra which enables topological analyses and traversal of half-edges + about a topology of primitives. :ref:`NXcg_unit_normal_set`: - As an additional structuring element especially for meshes, well-documented - normal information is crucial for distance computations. + A base class for storing primitive unit normal vectors. :ref:`NXcg_geodesic_mesh`: - Geodesic meshes are useful for all applications when meshing the surface - of a sphere. + Geodesic meshes are useful for all applications when meshing the surface of a sphere + with many applications in the analyses of diffraction data. :ref:`NXcg_alpha_complex`: Alpha shapes and alpha wrappings, specifically the special case of the @@ -174,113 +157,84 @@ discretized representations of material (area or volume) which can be useful not only for stencil-based methods: :ref:`NXcg_grid`: - A grid of cells. + A base class for a grid of cells discretizing e.g. a computational domain + or computation with models using representative volume elements (RVEs). :ref:`NXisocontour`: - A description for isocontour descriptions. + A base class for isocontour descriptions. :ref:`NXcg_marching_cubes`: - An approach to store metadata of a specific implementation of + A base class to store metadata of a specific implementation of the Marching Cubes algorithm, whose sensitivity to specific topological configurations is known to result in different triangle soups. + This is relevant e.g. for computations of isocontours. :ref:`NXdelocalization`: - An approach to document procedures whereby a scalar field - is smoothened in a controlled manner. + A base class to document procedures whereby a scalar field + is smoothened in a controlled manner (typically using kernel methods). :ref:`NXsimilarity_grouping`: - An alias for NXclustering. + A base class defining an alias for NXclustering. :ref:`NXclustering`: - A description for clustering of objects (such as atoms or features). + A base class to describe clustering of objects (such as atoms or features). :ref:`NXorientation_set`: - A set of rotations to describe the relative orientation of members of a set of features/objects. + A base class to describe the relative orientation or rotation members + of a set of features/objects. :ref:`NXslip_system_set`: - Metadata to a set of slip system/slip system family for + A base class to describe a set of slip system/slip system family for a given crystal structure. :ref:`NXms_feature_set`: - Generic base class to describe any nested set of features - of a microstructure at the continuum-, micron-, nano-scale, or - to represent a topology of molecules and atoms. + A base class to describe any nested set of features of a material at the + continuum-, micron-, or nano-scale, including representation of a topology + of molecules and atoms. :ref:`NXms_snapshot`: - A container to describe the state of microstructural features + A base class to describe the state of microstructural features at a given point in time. :ref:`NXms_snapshot_set`: - The corresponding class to hold a set of :ref:`NXms_snapshot` objects. + A base class to store a set of :ref:`NXms_snapshot` objects. :ref:`NXchemical_composition`: - (Chemical) composition of a sample or a set of things. + A base class to document (chemical) composition of a sample or a set of things. -Furthermore, it can be useful to have a set of base classes with -which software documents it state and gives a summary for users about the performance -and elapsed time measured while processing data. These utility classes include: +Furthermore, it can be useful to have a set of base classes whereby software tools can +documents their state and return summaries for users about the performance +and elapsed time measured while processing data. These utility base classes are: :ref:`NXprogram`: - A named and version of a program of library/component. + A base class for a specifically named and versioned program or library/component. :ref:`NXcs_filter_boolean_mask`: - A boolean mask. + A base class for a boolean mask. :ref:`NXcs_prng`: - Metadata of a pseudo-random number generator (PRNG) algorithm. + A base class for settings of a pseudo-random number generator (PRNG) algorithm. :ref:`NXcs_profiling`: - A structuring group holding a set of :ref:`NXcs_profiling_event` instances. + A base class for holding a set of :ref:`NXcs_profiling_event` instances. :ref:`NXcs_profiling_event`: - Profiling/benchmark data to an event of - tracking an algorithm/computational step. + A base class for documenting profiling/benchmark for an algorithm or computational step. :ref:`NXcs_computer`: - Metadata of a computer. + A base class for documenting a computer. :ref:`NXcs_cpu`: - Metadata of a central processing unit. + A base class for documenting a central processing unit. :ref:`NXcs_gpu`: - Metadata of a graphical processing unit / accelerator. + A base class for documenting a graphical processing unit / accelerator. :ref:`NXcs_mm_sys`: - Metadata of the (main) memory (sub-)system. + A base class for documenting the (main) memory (sub-)system. :ref:`NXcs_io_sys`: - Metadata of the input/output system. + A base class for documenting the input/output system. :ref:`NXcs_io_obj`: - Metadata of a component storing data of an :ref:`NXcs_io_sys` instance. - -.. _IcmeMsModels: - -Application definitions for ICME models -####################################### - -It is important to embrace the large research community of materials engineers -as they are frequent users of electron microscopy and atom probe microscopy. -In this community frequently ICME microstructure models are used. ICME is an -abbreviation for Integrated Computational Materials Engineering, which is a -design strategy and workflow whereby physics-based modelling of microstructure -evolution at the mesoscopic scale is used to understand the relations between -the microstructure and technological relevant descriptors for the properties -of materials. - -The following application definitions are proposed to support the discussion -how materials engineering-specific data models and connect to or be mapped on -concepts which are equally modellable with NeXus: - - :ref:`NXms`: - An application definition for arbitrary spatiotemporally resolved simulations. - - :ref:`NXms_score_config`: - A specific example how :ref:`NXapm_paraprobe_config_ranger` can be - specialized for documenting the configuration of a computer simulation - with the static recrystallization cellular automata model SCORE. - - :ref:`NXms_score_results`: - A specific example how :ref:`NXms` can be specialized for documenting - results of computer simulations with the static recrystallization - cellular automata model SCORE. + A base class for storing data inside an :ref:`NXcs_io_sys` instance. diff --git a/manual/source/classes/contributed_definitions/ellipsometry-structure.rst b/manual/source/classes/contributed_definitions/ellipsometry-structure.rst index 40173f3b39..35f0420a23 100644 --- a/manual/source/classes/contributed_definitions/ellipsometry-structure.rst +++ b/manual/source/classes/contributed_definitions/ellipsometry-structure.rst @@ -1,8 +1,8 @@ .. _Ellipsometry-Structure: -======================== +==================== Optical Spectroscopy -======================== +==================== .. index:: Ellipsometry @@ -12,7 +12,7 @@ Optical Spectroscopy .. _Ellipsometry: Ellipsometry -############## +############ Ellipsometry is an optical characterization method to describe optical properties of interfaces and thickness of films. The measurements are based on determining how the polarization state of light changes upon transmission and reflection. diff --git a/manual/source/classes/contributed_definitions/em-structure.rst b/manual/source/classes/contributed_definitions/em-structure.rst index f3acf66ef2..5ead19ffac 100644 --- a/manual/source/classes/contributed_definitions/em-structure.rst +++ b/manual/source/classes/contributed_definitions/em-structure.rst @@ -1,8 +1,8 @@ .. _Em-Structure: -======================= +=================== Electron microscopy -======================= +=================== .. index:: IntroductionEm @@ -10,17 +10,24 @@ Electron microscopy EmBC EmPartnerClasses - .. _IntroductionEm: Introduction ############ -Set of data storage objects to describe components of an electron microscope and its eventually available focused-ion beam functionalities. The data storage objects were designed from the perspective of how electron microscopes are used by colleagues in the materials-science-branch of electron microscopy. We realize that the biology-/bio-materials/omics-branch of electron microscopy is eventually in an already more mature state of discussion with respect to data management practices. In what follows the focus is on the usage of electron microscopy in condensed-matter physics, chemical physics of solids, and materials engineering applications. As many of the components of electron microscopes used in the bio-materials communities are the same or at least many components very similar to those used and described in materials science, we are confident that the here presented schema definitions can also inspire discussion and exchange with the bio-materials community in the future. -Partner consortia in the German National Research Data Infrastructure are here e.g. -NFDI-BioImage, NFDI-Microbiota, NFDI4Health, and e.g. NFDI-Neuro. - -Electron microscopes are functionally very customizable tools: Examples include multi-signal/-modal analyses which are frequently realized as on-the-fly computational analyses, regularly switching between GUI-based instrument control, computational steps, and more and more using high-throughput stream-based processing. Also artificial intelligence methods are increasingly used and become closer interconnected with classical modes of controlling the instrument and perform data processing. A challenge in electron microscopy is that these steps are often executed within commercial integrated control and analysis software. This makes it difficult to keep track of workflows in a technology-partner-agnostic, +A set of data schemas is proposed to describe components of an electron microscope and its eventually available focused-ion beam functionalities. +The data schemas were designed from the perspective of how electron microscopes are used by colleagues in the materials-science-branch of electron microscopy. +We realize that the biology-/bio-materials/omics-branch of electron microscopy is eventually in an already more mature state of discussion with respect +to data management practices. In what follows, the focus is on the usage of electron microscopy in condensed-matter physics, chemical physics of solids, +and materials engineering applications. As many of the components of electron microscopes used in the bio-materials communities are the same or at least many +components are very similar, it is likely that the here presented schema definitions can also inspire discussion and exchange with the bio-materials community. +International and national projects and consortia including the German National Research Data Infrastructure are addressed NFDI-MatWerk, NFDI-BioImage, MaRDI, +NFDI-Microbiota, NFDI4Health, and e.g. NFDI-Neuro. + +Electron microscopes are functionally very customizable tools: Examples include multi-signal/-modal analyses which are frequently realized as on-the-fly computational analyses, +regularly switching between GUI-based instrument control, computational steps, and more and more using high-throughput stream-based processing. Also artificial intelligence +methods are increasingly used and become closer interconnected with classical modes of controlling the instrument and perform data processing. A challenge in electron microscopy +is that these steps are often executed within commercial integrated control and analysis software. This makes it difficult to keep track of workflows in a technology-partner-agnostic, i.e. interdisciplinary manner. .. _EmAppDef: @@ -28,24 +35,30 @@ i.e. interdisciplinary manner. Application Definitions ####################### -We acknowledge that it can be difficult to agree on a single application definition which is generally enough applicable yet not unnecessary complex and useful for application across a variety of instruments, technology partners, and instrument use cases. In what follows, the proposal conceptualizes first the basic components of an electron microscope and the usual workflow how an electron microscope is used for collecting data with detectors via probing radiation-specimen-matter interaction mechanisms. +We acknowledge that it can be difficult to agree on a single application definition which is generally enough applicable but not too complex to remain useful for application across a +variety of instruments, technology partners, and instrument use cases. In what follows, the proposal conceptualizes first the basic components of an electron microscope. Secondly, +the proposal documents the steps of usual workflows how an electron microscope is used when collecting data with detectors via probing radiation-specimen-matter interaction mechanisms. -In summary, scientists place a specimen/sample into the microscope, calibrate the instrument, take measurements, may perform experiments, prepare their specimens with a focused ion beam, calibrate again, and take other measurements, before their session on the instrument ends. In between virtually all of these steps data are collected and stream in from different detectors probing different physical mechanisms of the interaction between electrons or other types of radiation with the specimen. +In summary, scientists place a specimen/sample into the microscope, calibrate the instrument, take measurements, may perform experiments, prepare their specimens with a focused ion beam, +calibrate again, and take other measurements, before their session on the instrument ends. In between virtually all of these steps data are collected and stream in from different detectors +probing different physical mechanisms of the interaction between electrons or other types of radiation with the specimen. -A microscope session ends with the scientist removing the specimen from the instrument or parking it so that the next user can start a session. Occasionally, service technicians perform calibrations and maintenance which also can be described as session on the microscope. Next, we wrote base classes to describe these steps and events. +A microscope session ends with the scientist removing the specimen from the instrument or parking it so that the next user can start a session. +Occasionally, service technicians perform calibrations and maintenance which also can be described as a session on the microscope. :ref:`NXem`: - A general application definition which explores the possibilities of electron microscopes. + An application definition which explores the possibilities of electron microscopes. .. _EmBC: Base Classes ############ -The following base classes are proposed to support modularizing the storage of pieces of information: +The following base classes are proposed to support modularizing the storage of pieces of information related to electron microscopy research: :ref:`NXaberration_model`, :ref:`NXaberration_model_ceos`, :ref:`NXaberration_model_nion`, :ref:`NXaberration`: - Base classes to describe procedures and values for the calibration of aberrations based on either CEOS or Nion. + Base classes to describe procedures and values for the calibration of aberrations based on + conventions of different companies active in the field of aberration correction. :ref:`NXaperture_em`: A base class to describe an aperture. @@ -56,7 +69,7 @@ The following base classes are proposed to support modularizing the storage of p :ref:`NXcoordinate_system_set`: A base class to describe different coordinate systems used and/or to be harmonized - or transformed into one another when interpreting the dataset. + or transformed into one another. :ref:`NXcorrector_cs`: A base class to describe details about corrective lens or compound lens devices @@ -78,20 +91,19 @@ The following base classes are proposed to support modularizing the storage of p and shaping an ion beam of an instrument to offer focused-ion beam (milling) capabilities. :ref:`NXimage_set`: - Base classes for storing acquisition details for individual images or stacks of images. Specialized versions can be defined and use controlled vocabulary terms for group name prefixes like **adf** annular dark field, **bf** bright field, **bse** backscattered electron, **chamber** camera to monitor the stage and chamber, **df** darkfield, **diffrac** diffraction, **ecci** electron channeling contrast imaging, **kikuchi** electron backscatter diffraction, **ronchigram** - convergent beam diffraction pattern, or **se** secondary electron. + Base classes for storing acquisition details for individual images or stacks of images. Specialized versions can be defined. Each such uses controlled vocabulary terms for group name prefixes like **adf** annular dark field, **bf** bright field, **bse** backscattered electron, **chamber** camera to monitor the stage and chamber, **df** darkfield, **diffrac** diffraction, **ecci** electron channeling contrast imaging, **kikuchi** electron backscatter diffraction, **ronchigram** - convergent beam diffraction pattern, or **se** secondary electron. :ref:`NXinteraction_vol_em`: - A base class to describe details about e.g. the simulated or known volume of interaction of the electrons with the specimen. + A base class to describe details about e.g. the assumed or simulated volume of interaction of the electrons with the specimen. :ref:`NXion`: - A base class to describe charged molecular ions with an adjustable number of atoms/isotopes building each ion. Right now the maximum number of atoms supported building a molecular ion is 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with which all possible isotopes can be described. + A base class to describe molecular ions with an adjustable number of atoms/isotopes building each ion. Right now the maximum number of atoms supported building a molecular ion is 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with which all possible isotopes can be described. :ref:`NXlens_em`: A base class to detail an electro-magnetic lens. In practice, an electron microscope has many such lenses. It is possible to specify as many lenses as necessary to represent eventually each single lens of the microscope and thus describe how the lenses are affecting the electron beam. This can offer opportunities for developers of software tools which strive to model the instrument e.g. to create digital twins of the instrument. We understand there is still a way to go with this to arrive there though. Consequently, we suggest to focus first on which details should be collected for a lens as a component so that developers of application definitions can take immediate advantage of this work. :ref:`NXfabrication`: - A base class to bundle manufacturer/technology-partner-specific details about - a component or device of an instrument. + A base class to bundle manufacturer/technology-partner-specific details about a component or device of an instrument. :ref:`NXoptical_system_em`: A base class to store for now qualitative and quantitative values of frequent interest @@ -99,19 +111,23 @@ The following base classes are proposed to support modularizing the storage of p Examples are the semiconvergence angle or the depth of field and depth of focus, the magnification, or the camera length. :ref:`NXpeak`: - A base class to describe peaks mathematically so that it can be used to detail how peaks in mass-to-charge-state ratio histograms (aka mass spectra) are defined and labelled as iontypes. + A base class to describe peaks mathematically. :ref:`NXpump`: - A base class to describe details about a pump in an instrument. + A base class to describe details about pump(s) as components of an electron microscope. :ref:`NXscanbox_em`: - A base class to represent the component of an electron microscope which realizes a controlled deflection (and eventually shift, blanking, and/or descanning) of the electron beam to illuminate the specimen in a controlled manner. This can be used to document the scan pattern. + A base class to represent the component of an electron microscope which realizes a controlled deflection + (and eventually shift, blanking, and/or descanning) of the electron beam to illuminate the specimen in a controlled manner + This base class can be used to document the scan pattern. The base class focuses mostly on the concept idea that there + is a component in a microscope which controls eventually multiple other components such as beam deflectors to achieve deflection. :ref:`NXspectrum_set`: - Base class and specializations comparable to NXimage_set but for storing spectra. Specialized base classes should use controlled vocabulary items as prefixes such as **eels** electron energy loss spectroscopy, **xray** X-ray spectroscopy (EDS/STEM, EDX, SEM/EDX, SEM/EDS), **auger** Auger spectroscopy, or **cathodolum** for cathodoluminescence spectra. + A base class and specializations comparable to :ref:`NXimage_set` but for storing spectra. Specialized base classes should use including controlled vocabulary items as prefixes such as **eels** electron energy loss spectroscopy, **xray** X-ray spectroscopy (EDS/STEM, EDX, SEM/EDX, SEM/EDS), **auger** Auger spectroscopy, or **cathodolum** for cathodoluminescence spectra. :ref:`NXstage_lab`: - As it was mentioned for atom probe microscopy, this is a base class to describe the stage/specimen holder which offers place for the documentation of the small-scale laboratory functionalities which modern stages of electron microscopes frequently offer. + A base class to describe the stage/specimen holder which offers place for the documentation of the small-scale laboratory functionalities + which modern stages of electron microscopes typically offer. .. _EmPartnerClasses: @@ -119,16 +135,17 @@ The following base classes are proposed to support modularizing the storage of p Partner application definitions ############################### -A partner application definition is considered an application definition which stores data and metadata which are relevant for a given experiment but have usually only few connections to the detailed description of the workflow and experiment which motivates to granularize these pieces of information in an own application definition. In fact, one limitation of application definitions in NeXus is that they define a set of constraints on their graph of controlled concepts and terms. If we take for example diffraction experiments with an electron microscope it is usually the case that (diffraction) patterns are collected in the session at the microscope but all scientifically relevant conclusions are drawn later, i.e. through post-processing these data. These numerical and algorithmic steps define computational workflows were data from the application definitions such as NXem are used as input but many additional concepts and constraints may apply without any need for changing constraints on fields or groups of NXem. If we were to modify NXem for these cases, NXem would likely combinatorially diverge as every different combination of required constraints demands having an own but almost similar application definition. For this reason, the concept of partner application definition which have fields/links where specifically relevant sources of information are connected to e.g. NXem. -More consolidation through the use of NXsubentry classes should be considered in the future. +A partner application definition is considered an application definition which stores data and metadata which are relevant for a given experiment but have usually only few connections to the detailed description of the workflow and experiment which motivates to granularize out these pieces of information into an own application definition. In fact, one limitation of application definitions in NeXus is currently that they define a set of constraints on their graph of controlled concepts and terms. If we take for example diffraction experiments with an electron microscope, it is usually the case that (diffraction) patterns are collected in the session at the microscope. However, all scientifically relevant conclusions are typically drawn later, i.e. through post-processing the collected diffraction (raw) data. These numerical and algorithmic steps define computational workflows were data from an instance of an application definition such as NXem are used as input but many additional concepts and constraints are applied without these demanding necessarily for changing constraints on fields or groups of NXem. If we were to modify NXem for these cases, NXem would combinatorially diverge as every different combination of required constraints demands having an own but almost similar application definition. For this reason, the concept of partner application definition are currently used which have fields/links whereby specifically +relevant sources of information are connected to e.g. NXem. More consolidation through the use of NXsubentry classes should be considered in the future. An alternative solution is to define both NXem and its partner application definitions +are deep base classes for which each field and group is optional. Specific instances of these blue print base classes could then elegantly combine the reuse of vocabulary and hierarchical organization information with specific constraints which are relevant only for specific usage of such data by specific tools used by an eventually smaller circle of users. :ref:`NXem_ebsd`: - Application definition for collecting and indexing Kikuchi pattern into orientation maps for the two-dimensional, three- and four-dimensional case. + Application definition for collecting and indexing Kikuchi pattern into orientation maps for the two-dimensional, three- (serial sectioning) and four-dimensional (spatial and time-dependent) case. -Several new base classes are used by this application definition. +The definition of several new base classes is motivated by by NXem_ebsd: :ref:`NXem_ebsd_conventions`: - A collection of reference frames and rotation conventions necessary to interpret the alignment and orientation data. + A base class to store all reference frames and rotation conventions which are necessary to interpret the alignment and conventions used when working with orientation data. :ref:`NXem_ebsd_crystal_structure_model`: - A description of a crystalline phase/structure used for a forward simulation using kinetic or dynamic diffraction theory to generate simulated diffraction pattern against which measured pattern can be indexed. + A base class to store crystalline phase/structure used for a simulation of diffraction pattern and comparison of these pattern against patterns to support indexin. diff --git a/manual/source/classes/contributed_definitions/icme-structure.rst b/manual/source/classes/contributed_definitions/icme-structure.rst new file mode 100644 index 0000000000..b21ad199e5 --- /dev/null +++ b/manual/source/classes/contributed_definitions/icme-structure.rst @@ -0,0 +1,37 @@ +.. _Icme-Structure: + +============================================== +Integrated Computational Materials Engineering +============================================== + +.. index:: + IcmeMsModels + +.. _IcmeMsModels: + +Application definitions for ICME models +####################################### + +It is important to embrace the large research community of materials engineers +as they are frequent users of electron microscopy and atom probe microscopy. +ICME is an abbreviation for Integrated Computational Materials Engineering, which is +a design strategy and workflow whereby physics-based modelling of microstructure +evolution is used to understand the relations between the microstructure and +its technologically relevant descriptors to understand and tailor properties of materials. + +The following application definitions are proposed to support the discussion +how materials engineering-specific data schemas can connect to or be mapped on +concepts which are equally modellable with NeXus: + + :ref:`NXms`: + An application definition for arbitrary spatiotemporally resolved simulations. + + :ref:`NXms_score_config`: + A specific example how :ref:`NXapm_paraprobe_config_ranger` can be + specialized for documenting the configuration of a computer simulation + with the static recrystallization cellular automata model SCORE. + + :ref:`NXms_score_results`: + A specific example how :ref:`NXms` can be specialized for documenting + results of computer simulations with the static recrystallization + cellular automata model SCORE. diff --git a/manual/source/classes/contributed_definitions/mpes-structure.rst b/manual/source/classes/contributed_definitions/mpes-structure.rst index 1d37fdba67..df89809bfb 100644 --- a/manual/source/classes/contributed_definitions/mpes-structure.rst +++ b/manual/source/classes/contributed_definitions/mpes-structure.rst @@ -1,8 +1,8 @@ .. _Mpes-Structure: -============================================== +======================================= Photoemission & core-level spectroscopy -============================================== +======================================= .. index:: IntroductionMpes diff --git a/manual/source/classes/contributed_definitions/sample-prep-structure.rst b/manual/source/classes/contributed_definitions/sample-prep-structure.rst new file mode 100644 index 0000000000..39f8249e9e --- /dev/null +++ b/manual/source/classes/contributed_definitions/sample-prep-structure.rst @@ -0,0 +1,20 @@ +.. _Synthesis-Structure: + +================== +Sample preparation +================== + +.. index:: + SamplePreparation + +.. _SamplePreparation: + +Document steps of wet-lab sample preparation +############################################ + +Virtually all experiments require a preparation of the sample. As most techniques are surface-sensitive or probe exclusively the surface, the use of careful preparation +techniques is the key to successful experiments. Unfortunately, the quality of such processes is often difficult to reproduce. Nevertheless, documenting how samples +are prepared is relevant. This part of the proposal provides prototypes how descriptions of steps performed by human or robots in a lab could be described using NeXus. + + :ref:`NXlab_electro_chemo_mechanical_preparation`, :ref:`NXlab_sample_mounting`: + Prototype application definitions for documenting steps during sample preparation. diff --git a/manual/source/classes/contributed_definitions/transport-structure.rst b/manual/source/classes/contributed_definitions/transport-structure.rst index 8238b52196..3d06c840cf 100644 --- a/manual/source/classes/contributed_definitions/transport-structure.rst +++ b/manual/source/classes/contributed_definitions/transport-structure.rst @@ -12,7 +12,7 @@ Transport Phenomena .. _IntroductionTransport: Introduction -############## +############ .. _TransportAppDef: @@ -20,7 +20,5 @@ Introduction Application Definitions ####################### -Work on handshaking between EPICS-controlled experiments and NeXus resulted in one application definition for temperature dependent IV curve measurements. - :ref:`NXiv_temp`: Application definition for temperature dependent IV curve measurements. diff --git a/manual/source/conf.py b/manual/source/conf.py index 17a0091f06..45235e151a 100755 --- a/manual/source/conf.py +++ b/manual/source/conf.py @@ -80,7 +80,7 @@ # Add extra files html_extra_path = ['CNAME'] -html_logo = 'img/FAIRmat.png' +html_logo = 'img/FAIRmat_new.png' if html_theme== 'sphinx_rtd_theme': html_theme_options = { diff --git a/manual/source/ellipsometry-structure.rst b/manual/source/ellipsometry-structure.rst index c801f341f6..223643d685 100644 --- a/manual/source/ellipsometry-structure.rst +++ b/manual/source/ellipsometry-structure.rst @@ -1,4 +1,4 @@ -.. _Ellipsometry-Structure1: +.. _Ellipsometry-Structure-Fairmat: ======================== B4: Optical spectroscopy diff --git a/manual/source/em-structure.rst b/manual/source/em-structure.rst index 40965d1cfc..ae9fed2f74 100644 --- a/manual/source/em-structure.rst +++ b/manual/source/em-structure.rst @@ -1,32 +1,9 @@ -.. _Em-Structure1: +.. _Em-Structure-Fairmat: ======================= B1: Electron microscopy ======================= -.. index:: - IntroductionEm1 - EmAppDef1 - - -.. _IntroductionEm1: - -Introduction -############ - -Set of data storage objects to describe components of an electron microscope and its eventually available focused-ion beam functionalities. The data storage objects were designed from the perspective of how electron microscopes are used by colleagues in the materials-science-branch of electron microscopy. We realize that the biology-/bio-materials/omics-branch of electron microscopy is eventually in an already more mature state of discussion with respect to data management practices. Realizing that we need to start somewhere, though, we focus for now on the condensed-matter physics, chemical physics of solids, and materials science applications of electron microscopy. As many of the components of electron microscopes used in the bio-materials communities are the same or at least many components very similar to those used and described in materials science, we are confident that the here presented schema definitions can also inspire discussion and exchange with the bio-materials community in the future. Partner consortia in the German National Research Data Infrastructure are here NFDI-Microbiota, NFDI4Health, and e.g. NFDI-Neuro. - -Electron microscopes are functionally very customizable tools: Examples include multi-signal/-modal analyses which are frequently realized as on-the-fly computational analyses, regularly switching between GUI-based instrument control, computational steps, and more and more using high-throughput stream-based processing. Also artificial intelligence methods get increasingly used and become closer interconnected with classical modes of controlling the instrument and perform data processing. A challenge in electron microscopy is that these steps are often executed within commercial integrated control and analysis software. This makes it additionally difficult to keep track of workflows and challenging to identify which specific quantities in the control software mean and represent in technical detail which physical quantity (and how these -quantities can be connected to the development of ontologies for electron microscopy experiments). - -.. _EmAppDef1: - -Application Definitions -####################### - -We acknowledge that it can be difficult to agree on a single application definition which is generally enough applicable yet remains easy enough and useful across a variety of instruments, technology partners, and instrument use cases. Therefore, we conceptualized first the basic components of an electron microscope and the usual workflow how an electron microscope is used. That is scientists place a specimen/sample into the microscope, calibrate the instrument, take measurements, may perform experiments or prepare their specimens with a focused ion beam, calibrate again, and take other measurements, before their session on the instrument ends. In between virtually all these steps data are collected and stream in from different detectors probing different physical mechanisms of the interaction between electrons or other types of radiation with the specimen. The session ends with the scientist removing -the specimen from the instrument or parking it so that the next user can start a session. Occasionally, service technicians perform calibrations and maintenance which also can be described as session on the microscope. Next, we wrote base classes to describe these steps and events. - - :ref:`NXem`: - A general application definition which explores the possibilities of electron microscopes. +Electron microscopy is a cross-cutting characterization technique of key demand and relevance within materials science, materials engineering, and bio-science/omics research communities. +A status report of the ongoing work on data schemas for electron microscopy using NeXus is available here: :ref:`Em-Structure`. diff --git a/manual/source/icme-structure.rst b/manual/source/icme-structure.rst new file mode 100644 index 0000000000..8ff31eaf78 --- /dev/null +++ b/manual/source/icme-structure.rst @@ -0,0 +1,9 @@ +.. _Icme-Structure-Fairmat: + +============================================== +Integrated Computational Materials Engineering +============================================== + +With a large set of data schemas for computational geometry, and methods from condensed-matter physics as well as materials engineering we are convinced that the NeXus standardization framework can be one component of efforts to harmonize and consolidate the zoo of descriptions and data schemas used within the field of Integrated Computational Materials Engineering (ICME). + +A status report along these lines of thoughts and ongoing efforts is available here: :ref:`Icme-Structure`. diff --git a/manual/source/img/FAIRmat_new.png b/manual/source/img/FAIRmat_new.png new file mode 100644 index 0000000000000000000000000000000000000000..eeddabe3400c469ed1619f50d834533d2afc0303 GIT binary patch literal 24990 zcmYIwWk6J2v^L!_4Ba&n0!j*!Lk}SWDk+^((%s#yf^o@cE?l)9QCAs!7L3JMCL5<*TB1qBTk{E_2efh+p%c2p=RsG+Z9 zW!05rWtkkEUt7Mivp_-NNb*aPKzxPM^%y-X$|uJbBXjCkr|*7ne@&-M2Lr#Tajlkw3Q<{mV=@H%D@ePGX2QCA&N&=V5?So_s8J-;JlozS9{IYNp9Ax$e70KGAd7b6cYlJw8XShc7YgO&-f~z^K);?P2Htmw{#)Oo#ug0Vex#6 zpCW}Lt%P~9jwGET-`op3&-5J6#fM5c8@OM@xeS;DS%t^id1s5raldWS*)!F8^n8ta zEi&IG_2I@#Es@twTIFt2ZR`OipK>eBzo@y8;c_!ak;(O!6a?SrmU}gc;7cmL`4SP( zefXjOUP?KdLOkX~u8i~bO29$0eyxbaCL88Dd_TrMAQm;qAb0Z9?!MW)Ll(-d)r#`= zx$P6q3?A4TS%DnQEMtoH60epjG|cfbYANtqDJ{ znN$pTmQk=HIy|FlrX`jZrx)kjt>$iSP~v!;tIq<1TEMnonW`wtp+uuZpal7jR^EXt zxQ+;27Zj8StjIr9&mt*za1q;8>4`k{FKjA&EXv2-`+6uSOejin($78Tc3K0}pKG_B zUTv_=#Wv2Jb{oUke^2R0GZawvuBU~2a*NlAM&WoD;-GRB540%q%f4_f7)^h?S>-M8 zinpz6vht{&Z8##rlp@-A1Q)ubG7euQ7L=Gae9DKO4hF&} zzXy0!q3eudEZCa*JzxESE`t)kk*Bbd_o8JaR2>HSD{;F-e0^fSQnP(}cax{UAXd_q z$arr3XZLQtm1t#kwPor`A?5*;BbzqOgb{|>V z`(wIyL838a^810O{P0`#D96UvXW2CCC%(QX=B@bDgEX1$P!+r>YWxrH`?iqkniZ)2 zsyPdkCn1l&hfqiO@G;obP&so8&(pie?-ze{KBc19K01^f=$Mw|d+|)`%aNQbMjt<^ zpW|z~gFA!NvlBv!=!fi3pUWi+LL9KrUMMcxipGEo>4UdNl0EO+-TJ2by@gfP_E?bf zV(B7I>0a>Fy=Y2Bg;#H61X6YK2naO%l_Wv_*vlH`+}`#yy5}8vl%x^En~_n`WKIWn zk$+DP-e{RXQ{9EOQ6;6iugL7fudB17cqu9bKSPnvj!10`-dswKK#lZZ-q-bNd(&s? zton?&V6Qby@^$Ny24bs%&p7pbcVpCYwLdL@&C~0-l0%w;hWG)wnv-thj;V@yU1Dqb z#_BHJ{1fCadw;%Rz{mz}Xddot_(cmExkrA4>Nd7xc=CpwMS*>Xy7{NU=+*h<> zs>77$E64a9n@d~QlC#Z<45yzqlfVNkn55r3WRnxtZ?@-?ZZ2{f&;kbH?ZusQ@&1JZ z8eNU!`loxo;Xd^FSK&yrn$JE#ylcP54=vvrYVGL5G@Z-k{&n=u0JwOJK^%fkx_?RN zuQjzk1JaOx{X|sSG7glep2P<1Q*xcUxb)x|DztsWmK=omhdCa4mA6deM>=FMvK_V} zknX&XE~;_+w*O&5_^Ch}ZY24oQSngg=I!qG2~K-gA7)+#XFG1B14(*P>pXHcrq;Ks zj~k7ae_3??5(NRn%p$w0{R$X2e9)z+)9CKQ)rNzY@27B{1aJ-@r5DmI*E~r%!U_BP zzPqGchfg&(ZU6^;CCy#v9%)J!}wZnr3dYL%OD%GlSv70F@1$&r1>4rkj4f zY-f*s)tk|Xs=59)>{Z`fAUq;M2W5NgykOuAYz6x~VR^1-dAUSy(ZG!2>kY5?a4h*Um5tq`1LYd`aFgFKVf+aChYU&3yM21*$9jgh)?v3CLTCf$-0g~WRl>K z!(P^J7I>26B1Xu*Mk zzkppa|FG56Ha41uA^JTp#J79*o?+X91b|4xAwX@V)QQkJ zd;+gPk$Qh$D>O9pSllb{sb-MCgG+ML{x{|C#)KV{!g3L#j~71##a4E_6dt`J-zKqd z+ktSkkJRemLk-&=ko$)nksot)2QCNbMA2VOudP&jzijkQ$IL^FQnyLw*3lsRNe>93 z1J2w@x1sgKjyVVPzRAkVs8QS@VW#i?9BEyW=XZy-)ovY6p`k48&xUEANhAzEv!|l5 zykYH>n65HvALb9my(7=PNPyp7HQenRJVaAE()obk+rYlnW0(9AHw+vQb{{xkgi!l5 zs<>XS&TpI}Jz0{LkgSGlpNyXP56@zF1x$!yy0b6_z``rD;HTvt6gViKK4@I)f>q!y zSij0t4uYGW(|HHt4|Fl9w9CkCiBG!g2ce)Wb*g>I$dPs%a`4^Ux2pb=xMZ9MMoCKh36*)j7TscZURE=PxTJySXEh!KXQy}9r5X6 zYIvQ{`fOd;nJJC~?)hT7ESgc`ps2gU=~NO&&*#{+>?o5tA(5HB=^&5l?>HwV9%kCn z)xuFijZAD8v0Srl%nrY#K;+S6J0wT8`tUpoED00O$ZV;(b0(ZMSv;V}VFS3=ud7g{ zBCU9WSGWSC{59^(M+25EtJi1iOkt`%p*9Ehlo~w>>jiE-VH_d5mtZIB)XP;@Fa$rUy!bYHZEg-W(+dU6P*!8cQu5_ zZVe49Mo_T_F|Uk9z_t9$0}{TX3GQO3lIk9*BM*;%GrOzgDoD!3k~-{I}xR-Qqh#>~ASv#9afMhAS!j z>ui$F?9ATc6FA~^$~Z5ekBAt``>rIK^KX5Gi}$+nA9H3RpQk;qLLny%v{$slKx6VH zhP9|FVK9`F8NEFd)ggukS$*Si|Hv?02*(ldL#H%jfuQ6z`Qd+_vhR3hMEp85&jX4k zYg)dn!PB>W=zv~<>&wF0`44{ezOMwM_XCucK!MM!%+jU*Wd3l>>N{TmJ-%f{uc%K@ z-VI*wg3>5UrUeOb`=f?y^GLF@_koH>fdSXS{+Q4%mkr3;cC|8ID30^oG;0_fB``tK z_K`2FzSEi8ZuO%G8m4Sh2aP+`G#AY zMrDM3lMnke@^oD-xaL}dsS1p>d!iZ@izTIs_H(z$C}<&z)1eyu#F_z9MzHSZEDM&mS0Ywm7_Nh=B&R52{wQEOF1)E+B? z9eTVbKq7O`Oo>50`0vKY`kA$lS=XBf4|Yvinx;wM*X3eN2Dn?qEi?D0p^+*Nz!okPeG` zvZcN0luYcoy?**aGtTKdLa~=yWd__ng$LR>>hJ%(c7o;`(bMytoBuoe-=lBdzIX@H&OPQ?Y%Ez zY6$~!s1E8bb5JAXm!{v{wINDi&bjiMF5R^N0>|O}>bw72EHSotyWhd4FIaO#y%+kDqkve|R#7M(Z4lCtf=72-Oq?*0s_COoipnPuJI`V5rcS6yV2 za+4eYOsoMXHQ>V?-VMYoC}{$^L>jNjKn%`ALHpjTWmdN**#@Wk;r3pIh%cl)PgQO& z{b{paMsz?NSI~|BSgt_jyVATkZhFh!ux6Wu4{*A>izs`&th@GNT(X&C5UL*aDtq$h ztzt6|@lgf-g|Rx!H=#S-xk1hwE2w~-^-8P`XSc#zlDHErZ{%dW3NqOw(DnFv9bzM# z^$kg!90Lu}N{3RTRYJx2n71T^4A*0&k)Y8ir$Cfn5v5JCgoG72Qxae8^7NHoWh?$FeFTz2SNqiCSq`_M_4i@=1j~OBNxU?N#Qlp7*5s-YSm)4x zt;TtOMV-{&(fHWMXGET*woLu+(#C41||6R^bYb|FAXUbC6RVnUF{ zhBoiA;UBko6>`@MzyakFM3J&))fx2>t-3z``HhW)HmjnzK(eUFbB3aYMM86P6y3iT zgRb7ThcTDzP6s-EqlyqPZOsPpId1pQ;+nA7kW}+VeHIldG|{HsGY?-s_^bK@`sZGo z9|Qa)6SH`6Ys3(J({pQsVM$;&)}w&-a_>x!WuDH+T_hf{5k6=Yi=V4Pe9` zacb+-g>Ie0tBkvayEh;dx()3Ea&hfza$sZsVt+1{PN`B}L@Kkict5x9`8iQpS!#>l z3H#@NHq8>d-EH5d{SrB4=;cAe?Nqy>lZq*m1feO%bH$YYgSrlo*--{6*(I|N7Gkb`+jZZX${GmsSeC)}d7;J4djTl-@Y%3b; z7thf8#-a`jP49B62--2Xh?>;*Xz-pcmVwm|k__M6m@3-ty|nPdE;DY}gMnUR}7{@6E&ZjvJILkqJ*W09++-UMLq5TFu zG+W?&t!kH)sDs$Zz)~u-+}YA<6R)|qmFS+z-zY)*%;Vqa!D;O1*>M#i*&N(t{+KTm z#fNB=B>2Ik-}VNhF$ukCL#H>1%INXMiVo%YiVwgC6MenhE{X zrK|yAOM~TAHW=01H5Q^ozkAwMNKwz4Nw2yyA+Wt8$fXIB%lM%E3Cr8c945rfI;IgS zK%I5mErUF*-6*zb>b2o+qhjEgms2S{>5W(pa7nF+XUQDct?vHbRn{}hjUg`+tFxad zHXRg8|Aw`6U~$YBdv-RQuBhUEdJNty2zL-!Rnnj})hX$F&*KZ(8m!Di0dY<3w5&$1 zL>g^;*DmTg2~ToUK}fwixqWI)7s;>!+jgIn1vuBiFfys{G$oOJtXMxwXq4=q*Wp;j zYidz6^Ca*jkl{j;L{fN??iV=2>c@B;Lu-@zb&~tQ<|BGts4Ig0SSL-~kN4F2FFg*{ zTCP%v8^>EQb3kEV1(TLA3RWCTXq75y=!)z_pbRU&c;$mtF~S3<)IfI09USte!klC+ zb-Qb8AzA&VF&JKuziUUKMZG>;Z^@Q1b$;%kxAr;spNfUFCR)BaNx3%yor;`kCVC|pnbp2nlIPz0U zg1iDLVJ;-l9$WpAWLvr|=Fyt&B*Ny^@;m?Pl&>0t8;_7E>dz^UXMvNzgX1gEXwW72fgdfl! zSO>*MBqdFV2je`9b!3ws2O;L+pPcSavlH>)Tm(+gZB^j7jq%3}1ALfZ9mz;+ArXDf z{!b2zOCkhL%W^Hg{`RBX?FA=_5Ec_UjPTHXYK8 zF0Z|p;5NRz|BtEVgH5WgJFrcWAPF`F&{YSH6$?qo^zi!kuWBumb&I1sDZS*lQ`7|J zEY5lInzT;cwU3n3+t6941sF3UqDa>`pahEJ;>PGF3Qh=j$*qN_EPwT|4)91*CY(&~9qR`yz&jarFDZx>s zs@zx}P=^p9RL48IEpHM>9UWp8;-aFCrvYVm>k)oe9FR!YLUxL^lWSt*oE(K9coHvG z@=w$!VnMxhQ^EbU1)~!fX|A`ZZ{J~iwg&zf@KH7$4yG=zwqNw=H`Fq=UPhId;RUfJ zeJISR)80w~VaM?h`+))4_>Yr^5Wxzq+#0C$Yb!Wu6z-z@TU~o#eOZrhL(*@;K{aE z1uw(edXIyO7KOT2FW>M6g&l<$Ksa3hkRUf6)+erePTn#P)+r2D5-svD0gYJ)N*dJa z14cn!`@kFL1MU~U*9ub<8i%1>1oFVaVLtzNi-;*g^4q&9tWE(<$#OZkU&sa zKyR+2LiYAxd07#%W~aIsmeshg&ZG{bvN&;JO@7asJy~2w zwzXwU&mzx+vNQWtl!JgZ(~LNQ)>KKEe^iiBt7r^ob}FUH2fDgzDo==wT3TB#OI{h! z=Wz8HhYHA}QRC~ugg~m3mk(>H;(?&(=?9fQ3u<%;dzasCv^2eagc=s+TTB*2GE9b> zRJ0Fn7Z)<{I%UD>g652n6xaAa zB*R%B<_`X}{X$~@Jy?Ie<~ByL0~V1l3P$*Z_aCqeA1QxpkJjf_M&D3=Tz=?|WB0k* zZ`S59E+%I6GA;-tYo?Nlq6(WhzwrI64go$Zn{O~anDesus3P%HMoS{GntW?ZbD#dL zAo0u<{|%mZaRv7y{qy(xOk!eRT0+XoGP+o_*uKd|?6qu57b3^0y1oI)kkI2u;DE^e zzQ_KA-~&LcCh)*PI4O0r2c8seG+vcEWc34mXP$C#d3KSogphmM`k z<$moyc2CAN?7L}%?a4m!$a;3rRZY|r5@I_7TLDoECfZs*xFlQOOk381Oo(Fu^_c*q zqA0!{bA7$#N_>14^CrOA`82zahRwwTrxB#?%;sVGzNsd{!E>TmE~p@$ zewa~S{WFR7;74nX+wu(3TTufIb;B`P5lc(khMq|80o4GU`lySpGSY6DHDHrnMD0^V(z}ydFMG%a1j95 z>O*y^i z@s5(a+nvBXB~sPjN6*sC(vOz0Ym8n@SE*k_JF%A16XmuV+%AS1f8Ihz9W&u|E6egeP?(Z~ z6Sc*#I|ZZP6oE{VW5#5H_Bpw7IRGgWO^*uXG@BPY zid5j6w?cbd{~&fVxff7>!kt&j^)Wwn{~R~i%*;PoQi3ZCf@IZ307?F z$$2*|=yyGsu2g7GA{o9f&#L`m5r9r&%bqce4+9wHmS{%4c|PsIfZ_m&07>azGq}@y zECO6%2LxV!Oa;v$MYHuM%hDx`do{in)|DX*F^*bAV!qO3hxlG@Ey^|Byk$X^cPX`r3GQ9tJKWd;Fnb(^VdWsP^ zm=TyW*{pg5FJuMm6rN!$D#1kPWavV-LykI7+3=E`+NSB(tcS?LA8O=0rFyY%J{((v zprRq-;3R7Mdsgt<(_S@!{5b?y+yMv43M^*sm6oE?&~#npHQKzHv$}y@lTk(}GNE)C z>uaL9x+wvFdBS83_+x@&F=CYTzM^IyUW0y};Lpv)xpAr*6n@nChT2|Gkt*Hfd!C#e z*y`i9sy&LY7g{@}$oUM`A3c~fF?J2#`vc{w9Mhwby?3vN_t{@Wq}?J-V~#yPF6#Iw zQ?GbRE-#QB>T=ncHAT4Lv$ZT;>9KKBTE@S}5A3&>2y>niaIkEseOZ+Gq=278{KcI| z(B)&$7v~dx|2vbSx;{L?2LNnmC1b)@o3`9>6RV$T zCi-i##Kmmvl>iL^t+BBJwNWB2jtmEyj|9NZb?(rE<&U)l8eJx+(E>q5F%y|px!QXA zujp8peX7E%Hi^1g)9IJs` zL?Uu4PXZ_J_rginyByx7<^F^8@@S2;$hQVfme2k+*2&v588Ra<4y|1nO<@uPKMdjN zv&3QRGZd(Cvt|y=n@{4m%P3OXlJLBJVDT|zjDxEH9tqX{Xs7@v4X7*S!ADU+ z+ZjEt?8oqwVk3Uwl95N@SV6U#hUpdke$lF0Pf%xmDY>E#kE1)JBSJ$pUY2B% z%Bg2!xj6j&VHS@X3kWf54fYn|TBFqnFw>F$l9!+@2{%2xDNFzpZOpMzF4WV$5|U`X zfUJfPD&9v@SUij@Ak$tghD!6T&7M%KY@12+Mvq{Vk)f29ezRk0V3#t&>7UY?GK~dZ zEG#VN#Qq5@UxPT&U5qYEjrZHY0hfBlUS9TU_oH?>9tHf5zj@fI)!Jn5&w zWxUCkT4<;%TN=YsOnIyB=pz!?-F>wb!vDb7*zTXcUW5(G)*eMUoPjIRQR5kUh0*J+ zw*!D#uO~>{4JbuL$6$CvpBE3}@4OP+^R&u&O2-9bf5wz}0AwmrQ3Czogol}ha9)%J zC3SM-`A08=(eBUP_~(9%FO7$Ziez<6RfgN8Uk@%P07;v`LerByh(%i7W(sASzW0a~ z^di;p@6jc0t-GUVJfh}@ML#A0eHfICn(jagX1YaPH}LTg{$xe0{-WnsVE5Zz1>?#4 zvX|rl$x)c8H?#j%K)u7gW{;YUx2ytjh{+#S-KKJr4eg=GuyrYA2Wt zKe!4S*EHUHiHDJYbXJY-xr%90Cj=p7PXmlGeELWV?#-f~a)RLjb*;Xfv3|MSnI{X^ zqR2tbXTXXt{K;W;vjbCy^{aY`CN>YIwT0aJn zf`M*aHtwhXcrm2!)<7wz#v+*|XyI)yo$(}TtUFsMRq{YevGIEJyHBRZ68`gAy(A;a z9qZvb>z~m|3|QHvp;_8U6r_VA&eQuxJPFru_ z{4zegK*@-6i;UE%M4hT)T((}>b6~#jNk$Shg55APz-%T%dsq>H_ycM&VEc-y zCyUsFGQ=|`2z6U*+c{eQ5N&`vToVeYzu=>qcvvxz7Xun^rM9#I<>P$64`dDaxcF2^ zw@!suwZctJ&;36FQ7~e9=&cge1zIc-oMUCz2V@VR3nVe|&2enDe3-C(b$k^R zjkjcG5H(4Yn7TXwsa0JQkw)7 zG(kcQvtk{sdj{~2M?-(>^yiAG4bw?fS2x@$ICp-;6EId9v1`bZ}|Z(fRU)O}^y!EX*|^uV1n8DeDR?qcUkhsHsimrCph{UdL)K z)p2?Q9eq?mTv%|lDwndXEU?j~$H6q9UGp6vChggGAiz9>g(mgVt%@O(wD#w`eR>9i z+R(EiUto_eJrKn+1^j}d7O5y0UXmXN4`Hh2JaDH(M=b)?`9k-~TlyP3AndGsMmM@v z{*LqO*1uXaP3&D8`eNjy0&>W)eIcF7uBy?=9#))xYo-M4A$8`Z(aS{ZBl{NDP zZ4n&~3N}$BIhr4~C`q|6OQwLp<`F#x5H-`AwJ$r?Q8l0Sd@L~KNkL&P<%IS|1Fj1a zlYHWv9-m75YEjeFnr~p0Cb0V3k}_!T&vDI7JvM4EJg=ybZRkFeLFW-?&eIAM&1a3y zKf-icSBXn22=+NFbjMgqTMgNm|6snuPZNEyqkR9THqh3LUh2xXqsgO%?!#$|D&FsR z>{CWBTNdoYg-z=f?7n{Z0MbLHmQ&sMl3IJPVgDesIVC#Y)Bo|d+a);x7gRw(q+C?l z>(BE`B3D)|*+@sNxKuI)&28KSMFK;Y##H*l>!Fi7lP!{wUQ%4Ziab2Z^tt&{ z-#Y*LjwAR8tz64V=2h&9noJ$_W94+TAc%~DB6tj_JSl){&=slTFq{2%0cbxmIJnq& z$Tv{^dpF`-Lj)YKPMq@_5G;XZATlf=|E6=FpTFy|6cExw6A=ZDFd_M1WnSdZrV;;s z_Ew-R`i2}XO5)#eTev)3=>@5{%yJLN5`eK1v!=Ah#u3Y?%%S}%FW%sMj@!`(cMd^3jkM$HD(+aW@n2dKvX|Um26)Vt@c} zn9J6kqZZfDv5~=>3KMC>NGIe?T_tGDVi`z7o0F7+q9z-Tm z!$}miin9NkIS&W4En)!15c{wVWx-)81R@g~{OGE<2Kq@)mpD39BQgP7SvgR^Dzpp+ zrt?5Z$dvuDL{>d`A9hrf%nKWV4qWEYl8|{G_xPi~-D>=K2%P9+*F1h(8y$QZoG~%A z4>Oz(I7!6%z?#if+43H>g7AXFESCV_RI5*q8XtH-OsiZy$H3s23rx(g1j(ejhj|ky zKp{g-Gg-YLvmb%O{CCYghJK|*eC&@J2Q)u?0QUShp!Z&nx218IYgQa1>6eqCp9Mjg zimH}+rcSA3G8u|ojA>LK>$jguN)?#$!E!p4rncqfF+3@u5UBm&P|xrKq{6G2lG;r& z0xt0=D|f5y6+c00FEZ9|X7Ffe_z{Jins^@GtF4tKj} zn!vain4k0>uK~A^>Di?at4mKuj=_PWC{8NVe~xs=wvZBMMiqz!D4P&rADqqy4i!Bl zXXL@c2Ix!jp`0Hb(TdUSJ@5AYfZL}x1i>yMK%-*=%b|ksB#Uz4b8w-Tm2CukAIn5v zJ<@fF21&MF|5OSp^5@Cl*jmre#^$!-Y|JI~sF$ znn>1vt_|=LR&9FHL@30Jk00r*z~i1+&2ti9hEFzev9gwWVMya>kcY8m`k|w5onCN2 zO`n{+b+=nokN6=Wd9nltH7f;8Qkmy6wEQ0c5xV>HBK31!$L9bktlRB&*8mA+S7Cze z_Hf~>h-%{#f(ourtgA_{{)jt)p|}48cFFj6KxB@izA`s8l8I~K5D>4A_A#<s?jZ2}XQu;m=4bzp*(y473Vak;99?S}R>_i9E+pmxhsu z*e20Uj9_P$)%lT)zlJTB*OG2GcyHdY%!K-5-c)28dZKRaS@OvAAo&MM#uLU``N(mS z;kF>uFYn(c`kwQOPk-d}x=P)3pb`%toYbE??ER@Abc4sq8Cy6-`r-w^4OEcH3>l~+qs^;Zj4x7+)p(%%ZLO+b&;;d`Cni0QUT)dG{Kah)S;{s25Z0dnYO=TG z+8RDPRCZTqUpG%^PAO=;xog4V_pIJ)v^HZJop7D5R{U!e@^@?u<=gK-UB4jr_L0Yq ze3bvLKh8bpK35M>v1whlXxNV5RpRmwvvd9LJ6ND``(buPA2xRL1jC_fd$1(Px&C4C zL?>1C?M6Gf-?E0@DzvIUV|Bm(AUVSjef6c_?i~Zxn506~Rg*{NqCqJS;zPjPCf7QA0(^B@5hy&W& zxpHA!a;{5j$YrBmYoQra_~7BM?^EbN=j_nd$cqPp@r#|*QIA|=komc0#&v)Jil?V( z=R5$Q!&n-Y-qC4hoNU$ybAPGXl~IX}hYuP!Mp(1`B&!8LZ&ENS(hKp>0Mmo z0UXuG$`x~_L@YvQsyMc*HSXbXnsEuUSjacGv$Ia4o<=80dd+UtjY8BPJ9&31#L|cHmiJVbSzlC|w@v9&4c{P@2Y+ zT-MZt!r`IyCsU+jk%gc|Npj#DC>-Y@BFU8%HA!zsqW+anqj+tA(zW6w8|oRLO&ouF z%gv8Z*_r()2a~z_>pIDui)hf=+6ubYwSR77dI~g(>>La0U@zzHTRi3-Y>RRetfUR+ zQSy6|VL2A0N}1poPjS|A6Tr~+@fZG9#pH;r=}0Xz>uX$wNa3S_=578?_RPO9=YJ?8 zZqIIi7jtk>gp)7%%OYKZq=MelEScGXl&0T0j(Xf_1?zdwxkyQ!ad`DZw^x z?C8X@k28Li`+-3b)*WBLZ6dnRX5b1;`A^MJQ-*1d&QC|woVqVQQLdn&!*CT}bQ=3g z4EP%b2ffmhhV?9MIAB9U>ZLd2ZnL05k2$^T}H^%FUaS3I`BYUGbiD!?D=(L(wZT}k!*o{A9A z-FD1zgD2;(;IQ)h18Vu9`)!k- z(E-PI!^jFD3+JO|%%_w^rav<=)(u)luy+;)#=2mi0eUG?A@r*Iw7;RWadv$0I2Xah zZ#Gi9YJ{KNvB8-V>v2d=&oY?^+H3*R2wHeK)@I9l47LG$f?&LW_yb1~aYe{6lR{qs z(BbqB)eqY{&XLWG5|^&HkXH{@zlz0|t_rtgbNrpm8&3kor6bBMR}nYEBE!LMYNA@T z1ATsEz1db@-!|~adF`M?+5`Br@{Ky)lg-4?)GM%WZe{K=W6}q{4Bd<~>VLA7ON&VOpfoZJ+ndkDt$&V#5b8Ha4S-=`YFq7ac_c zPu+8ClF?Ql=zMq*BF2htz@_~cM~3-JO0Ek7PoVM>durfA3nGfr~9?2u9qC|>uNfXb` z*UwqlBm6O=F`(R!#VE{vi8Ue&`7?SV*;-ozhk8V*l023z2=fswv$4tKT#l9}HX=L} z6o3!KV)|qgwqME;y_I^Sx-8Aj!DU7m8$EPS&s6ETk}3iYCaWl}f+vBSYz!vqs&U_P zSjm{rRNj`W6-U8pgkcOiG}Tv-E4HI~K>OeG;2(}i=~^$ODx_OGSRRm)h|sZEW-_bseHFE* zQP!&HP|hLl0no=~mnH_-e%*Ma)@0si`{4QTIvEcC%8^qb^x}aVXt=|G=~h|~eh*_8 zdegI_7JSLurK`DR!@m6C6Xbm0Db*hs>TRU8=`ic;9(Cr02Moh}JMf#lmexb>j6p_ajYXzPz5&=E30U^aC^?!=*FI>ct@V>m=}YJ3TOfd3PPRo zi%nw#XVjS=N!pHsK$B2!H$*D+*|VPGX2kIL2cN81#g@yPq>I_0z!~Wb(KqWIvK`{D zphzL6KZXL?MrKl2NA_tpFgp4m0Dk4$)vDI7Q(A&^H?p$@5wp_Ot$3Zb5(%PE>8Dwq znbRdvJKtAf&TSz87q1O&mRAQbhlQEGnVh3(t6lx;EZJi2`{iZVL&$?9J#{AcZ?J>z zb29NIM2-|ASXhbfm&B0=@-oMOjR5(mQ{9*<%l^Z`pQ9_so`4tGls_FKUuc&Ue~c%p zR*~-a#C5Z40G$IcyGNz`GD|l{IT~~0`I$P#NCv8^Q)|KO-j;&zGv~Ycao070__dvb z9H0mU+3y?)%KBI>X;R-}{nEz42-P>RY-);~&DeL1wtdK%bS9+rB8tA!IJ$th>o_WeGh!nA`N=n`17}+e5_Dby1qx_XglJ13LK09!1MWXHv67R!DT}7L+C*OTtwPSs_YIwPYkcGf2YWqsCKq|! zJ6y+=QkH*&0IWIc{U_BqK`(hSx>Z*f`JPb9j77BReJ!(f6|Mt#i(b$}*&q|T3aM~< z+p~h&sq%LG{t@h&+P*d9}On{wQl2hD-W4?kzLbtmMfGYg8QI2LpCg?XXx$#bAXZwpE&%*2pzT6$Evf`v( zU6^&p1L$@2#z1t$e!5N0$kW8tOc%EBd$lcozKE#!1NxIEYxpn7>#~wtTIP*h96l~| zaY)?__Za|Kzgjcvx;(BUBof*9{X4+4(gB5faI;XaahRRnXM!cSZFPP#to8$dar=;` zd+1K5YJ+1F-|Ff>Pa~wIEhJZJtgM^q{kUds`(5*0WrOw}v0VhZPLpfuW`dG$p8sK3 z+YKI3-;rN%h+Uxb2c1FD73!<9ZH!5UqUae_{MhSCfeE@xE{h0$C_g~BpW?2PQ z!d2hRzb~HeI|N;&Tl#^1h+8=q)E^&WCNteJNXob*##7%cE;um8fjTpul#4=uKW2jB zP9*GJ-0sLjgZpPfO)rJT?15IP_V#C$dg^sH13=Gt07P$oj6Ea37VNbIs-{=DOGDX7=T)Rcl%jzzJcOFV>)-qECEFm}{^M;ozOl7D05%ZQ` zi`laSy^=-6ssK*@fQ`&egfBuuc=^K@mDC@1H4a?l-lCu|h9Lhh!2TKvpdj#`k-1nd z$T8f@%i1VEP^5iih*SYiZAlO4&ZwhEDD%5*j0Amt(C}{b%n_^dgCzS-}B)VPWXL zRc~MUbCO(04U7w~Qb0;MJO{vZ`nxI(XR}zVS6;)y8HG8N~eZc;YO?DMg2r<&Z6=k-p)4$o1Ic*~j`npEISh;^L0;jmyORcY{7 zjy?~5ZAYNC07{?*)%ecr)n?tHs+c7-baH=JzbY$eX0ShzSz1r{+U$@8MzWAYE`f6R zbbx+UwYLo~VPp12hc`X6^I*KF+HW-;Bp^icMt@A##r?(g)s8#S-fCSV1y~gv;3yF>CTMiIPT@VOfvXF1BWCm0ynh_vNLc)`M`guLpwJu@}`{pU3abobl8aDnDuS0Htu&A3IG?pM{h zB0}U*xVXrFt>BSYyGurtngbMDWsxjrd<=L?Tak+Vgi}R=+#bM=cFP}K(~^^rhI-*5 z003RKehtQO#_3$3vxh4MgcGc zJ?0z^9>6`jvp!EhVy!p8P z3n`ZTX~;6>dtO|vVR)2tKU4q~gHW7YVFJ=dL0yr2BgqIE?gqs_qWcJi2>X)_`8MR$ zH%l5S!a&fK0e%xhzS|BW&ag7dJoZtMC1M17VzQb@VQlH2B1{EQ5TVVi;2s-UUi_{H zx(^vScrfig>tjok)Soo`6OpmjTod-^H3qv^#PGleE<^XUT491{sC?(I{yf)sW~u|0 z3WDpu3LUW@CAKEX z5+Vu{lfB83HIy)fvPQN+WGUH_Eo5tuEz9prpI)!;@84&hdG2%XJ@=gRe!tIoYH>eb z7t+77mJF$>ZSB!3)J{Iaug8XuFgomyfXTZ9_CjzyG(5liKspy(b*VT ztpUvzAl-eSbdqc^l*X9SHvS^pr_P<+LT8*x(_d<#_dKPkX}smt4sq(s4cXClqfTUm z;TvI`{8_PlD;p%S9x&|+llEm|hXRqO{zPi^`wx--0UBsQ;f&3;x>xjPPd72l8F)83 z^oOS0BM8YIC8dtSSCF8KD zaoZ*}&>m2pju?lR28kP2bM5o}&m+RV25alY3SFe{$ zObUD(98Xw4cZrF}VjxC@n3fK%D$stDH#H(M8^{t+tdv&oeNJi63lZrh2ye{qx+G z1V}hq`mv_Y1qH7{UlRznsWaWII2W}jB(#gjtVKC-UZCeW?p|$b29juURXj?Mv6g=% zol*_iWGmSuZ3Ct7hswM+H-MG^BsY!IkRr4nE=}G?A}rDkvI;3tI<{i{17WS`upf>+ zhG%fW7UrUY2KpMdYT?<7*7F$=_$&OAkfY(2>wQei0*_8GA#48f`a<-Yw$RYXSegm| zc)!}=20P%;!tNfKI#uyH)F+g`{ppYfCGvCEUPm}wV?VCOW2hf{%URFx!neL=Q=B-C@Xhwour@CNQOdE^^=L(6k3)wEh*Zbi=&cf z>6V?HJ)G>pV&myKfX^Z(y5D!lZ|^ciW#Np9Z-Ib;HnowNSmLzlLXv)Z>o4)l(<@#w zNCtf|o<10$<$IB!a^i~bQ)_~{A@a3bZfM&pi$BBNSi1K_<1z;? zR9zD9zZ7DK$ACun9`+AjNT2VzE>S|JHk z*w}eFf!TEvFr};~`cVYbnMclzoR{9(D1(vv3W`!z%=SaW3)v>`?W|qR54CCm*;Eo3 zqxToY->ZQ)!$1=Lb*<0|2>Ay8yCkF47ba)$$Bp*uyHba;UN19}h1pbQGC>J1Z>G=3 z+Ry_jG%RxKG4~Ue6*cOUlyhCFr8(tmlwV55F+W)J55~&#IoMk z&)yBF2N}ndGA5#9VAwZC3=?<>{-|or;^tORb}xXovn$B%Ah73olG5Lfx;=jR z>u6UB3eKKqO?!Ka7S>3%d1q-@nUU$dbyte-0*1Lw$L;kgLuE6}?ylWWj*HMHbSlZu zGhJCj?I{a2O)lX=Xu|IK2GdFen_vEE=z#)+FtOUcGA`!-1MBE5JfdIWa{YviYvCn} zwD9%cwCvi;|G6atw8qGgDde;BvVL(^9*k7kUggupgJPIXMYbPeZ<;e@xWHLqfYbPW zCkCb;_FnwwB4!dVu;?=j^%);aFPjWzIdQ^yQ%3vW6)a67lKBNpE{dyKmFH@Fk`b%W5pmjk8AnJNcP70q8q0 zkZ3}Uq67o&;t+4}!9Ac--p)4O37n!TvI_kYee&-#;u_H8&@XK6*g6@#(XP2Kh1Yc? z(r6vSIMc=pYX6zPEo>~9hm{$$@wkrqs*N-BQmY%Mc0VOut?~K##+9`@k$;@fi-qia z+V-7FsIcvXf7Xz1`uB-7o8F3rxudYDik?ZH zVzrJdQ8H5je>V9+T9k)kn3mRTmsy>+Qj*pgGH!aIPM_^CO$-97aWA?S9dwZz&D*l$ z(;u`XsPU}Ffjx$I#w@PtWlB=9S(y{5s0Sb21H#w{4r6&N>U~yOCoIAV%jX&0bAC@ zRqJBLk!9o5hNT(pDs^b(?n&;tZX~uN^Q)0LqE}3@Pny(lRx!?MpIgf+b zj@dPNg=3#%^Wr4p-paly$Oohv1m!$9SVh`d1V(QQ@M5q4c1<^4ocht}8M=e7Z$+3A z3nD^A*24UyWE$R(LB5bQQJO^_7&tg^WkT{VWcU>?RVX ztA;&3A(oS9Lo6jTW7BUzzp|U@4_~ggPvhVSj7-I=112V22iSLbp z=S4FgNHkhKd_+*Q<9&H_cE4`f{GI2RB|B88J_T@+$4q(rT5r@#RTA|sr16lMhuV3%%21D$ux zv!$X(yWBj##|PqDOJ9XkK&~L-{s{|}l$u$IdT|L+F$_}CBdPoVcA872=ax0re^*N- zVfS}(h9dsPv0QWnOfn}Vt&W41xQ@y7EXYlW=d%7~=-ecq&Ykt4Ulq?Qi&(W^Unw4V zk?lCC=4|!+Zz%l5()WpHax2;MSPkc|g>xlf|5Xe-j`K5@{{Qb5L32BD%UHy`dyojPm!x zj3qKvgzVb+o@$Bu7ZbIF*zSv2jDW>`p#rtwgLAxJlm*C5*`rQlb041Y04z=V>v=5( zVGuvw^e#TmVvS~WfBc|)w&@zFE^yo|Reb#(JT{Ofkk5Md&fUZvXr1YEm=Sca)q8`w z9p@jX3?SDSJ|j_LDdno0H>n<8K*)oKx>SkUciAz%^S^sPHwo{@0>vRAk@JMH1U}2DV|1UP$G#Xc{U1?t9Tg#cJkAz89Cz=U%6q+-T#4o; z&x9I;@6`@&#@JJCzQ@5$d^C)v^xSmi+FWwJ(1Ht(C(q=;r-&VoPp+iokJ*XpySu_} zJUWsWs2__yWd}}8Lz+8L0otm6br3}kiZt)BEDxsZrQGq4)k7>9C_SQ2JAj1`_Zt>HdPgiw`(A@Y@=jzmD7X>F| zeqOdqJ6fF@u;Axcy;)iBaHSn_s!;;$RW4@EBYGU`};CIIisEJs0feP!8kWMQaBz$8QFw@=M&4RV-6S4!mmT%hq4 z+yxOd8GOh<5mYu>m5IzSP|+SPQ%(&}Ni)l!pi%&mJSca*4Ot&70gv`I5go?}r}%4` zPos2qc0et7t_9tklTP3w|ACTAyK<17th1_RM%}C|XDtuLrg}cB1hh1L|cDwg*$)<)k`lHkR@$j4+lkUl=-%&X49(LKowNoav z-{gJkjAUr)e+k;kL=URoS$C_14mAPCO-dw^% z7p*wRiI+E~xkBeAVxf*Pj6Q^hm5D>_Z2Izt+Mp5mpkxcMbhupZ&W(-jUuhG2_$Mb> z;06vB4h}XQ3-j-5fkqV`++WU_x7dLgxi87c(snpH+HM)aVlx>17`j*a&hq#(U*6keLt*?FDNbWE!6lLy%>!)cuUw4UIkX~l$keo&w@@__^V9$ z3d#hH!PpB@sIJQ6MPumeLVAhOt+ldWHFzU*vX0!Pub@17sveD=^))}7>kUd+bt;l* z2$*2+SxsM8UPa&j{MFxJW&Dq3V9=1mJw<$ZkF2rm7(Y2V$CPdGNqWTnk?+5&I=b~L zM9-GsJ374NDY$<9Vf%__h@hw;sqCCAOl)Y-UHg39ZEd~x@CO6MH*97@XC1k!sQ@W` z>Z_Xvdx`CIB&sNq1D<5_QhX(&N13T>+* zN5B09l_wOSZWN0V5Q?VYCM~PIarWH9reC0M4$#=k{ek!H|p zzQ*E3L87&Z(i47w7}V5Vf9X`YSxuZMJkl|*Bk40FPsgqPk(76 zCC_jgCO&nn?qAM$wwpmt8$t0t&Sc`L(=F7gN4W;->OId7O^zNb?bz73+UMh^A2&3A z>rr?27-MPm?09cYjk(4^dS{g!XDHvoh6|kx@tt4_4j~7z<;w#;TR{RJg5mj!{-4gh z7=FEh$2|>iatv5Qo(T?4{TBHmm`*E$=ERoZc!)lU2`uU`H?-q5QBMo&1(rurOBcf?gE{l(>{t-|Rvgn*003s2+_baV75mrh_$SUu5XAxls}b*OCwF z2>vnTaF$dxUf!vbQXE@vTH3Ej7r&Iv31gJF;`5w+yB-|dpCU*zEi2X5m?xiQh;6ru zc5w3$Cyr(xuoKz;M{0YYRzt~b#l=-oAim?ip5AuSJ0>o=YCMb#Q)3omT=tUvIn%>Y z$yMEAE23u$mUmeLPG4W)NMf6glETEITRawR^ORu$Y-;5s;CH!ayIX*>J?W+Pg#94#$hwNPSdOB z6_Z|^3GFg{brbQf%=+$q;z3OKS%LpB>083Do7dQAxs%Z0>WdB|<0dVn=o-0PGh;L~ z?sPVwrHMUGepZ*~>V!Sb8Dy3)6Lk;*{aSFmZM3>kaCa%Bu6M4s&|77=SV{&NdSUCrV7 z8)q>OC*`~s?HH{DH}dbq+h0Vsbl!xFUkSsO=>wpT)@s zO^(iP_3u@MvIf(fNh>30Gp$9625TN;1d?C5o0`|Ou60pkp9Kno2gx5{1S5H`dTfH| z=#7OLH|_7<)z{PSQ7@3b`@gr}rhMcF96n)kB3_*+c>xmE`KHyE0)_(jocr0wc8umB2_yX?0$&?-I;W3AW_q8`;1507te<#g{*_2fHqt&;1mi3|5?jN&< zY~V4!P)90hBl|VdO0A!b-;f*8gGj*@de0<@aN=khAInDhfB*!i$_znf=3*&JBjdGO zR!(BkgFe+`4f~P)iu&IC#Gk<`>~9MPy!@C0e%v#m45#47nYrCJa8UQ4q~uyNH{A2O zteBRSEhuow;!~4#1r6QJ>}glgj1aMj;0vKkLlsGqlvJ?fW&1nS?eA#y@peA42HHqn zA@T@{?-{u%{xUQe3bG7u6Q-|YWAQFSjw-tf`d*#CJWgPeNYu!FWn;t$#js21bxmS( z!fUt$)WDMCH&R&5xXnWg<11^X!7$OCgFh3<#9;>^hx<=R(pS_IPK{wLfJiznS1Woab4Hm$B!CnO84-n@E{P#Jr!m7mkAYKBaSZb+WXvw}3!cV*+9%l{;jpyNqAueIdmbCvoZ3py}jhU(+en!Nkui87&Oz z%QGI$eXQc*LSleV0O!=AF-Z6Da3;lUBP7x$XHg($I|@|!tPp|SbK~uG;Brntl=|jt zswAJxBqu{gXn6f~A%(XB#1sZe{*?S5i$J)pcT}0*#f2~VrtZ@AEp?D;+gpS>V-(+F zd8kOJl?YeHiIhud0@M48bno$O{0GvmhMt#^ZhfXms}B+OzL}!(oQdCc_RX|}U$0TF zg?_P(=h-mO5_NLXD)N|WW(hPc&n|ger{+e2%lY^tiF|KC&O3Had7DXPzL>8!bs>SB zNBO->aYg8gQCL5+XG-#rFh~dl=|5U>2d>~c zE9<&JAlwY7zi8fh(w^WVw!6v;1?+8X3VbZ6w{E%}1VRT94CzUj=did~5FbP>cwKntmdGtU@Do*=tMz%c6(;XK?0*8($KM)M<;opv`OkEVk|(a^_m950aJo2@%`Wd9 z2kna6PVe2#k>bixLTeDTl+*{Ii!in4%r|h)5{~|hHkv{?(Cbq(yU8f++;Y}B7Ok)g zO*Iusrbx({7mFC=)qUQ!UJu57IwH2s9R#bLxPaK76$nIXv7`D&VdlBqT|`ysgDb0^bkD-#jD*TvW+t?PM>&`@z4`Bb49uHjG8wTj%L z5J#+sjp08c$}qmX7BZ6_;VS)49j{ABv6BXqKJp^VXobfq#4FxeI=X(wRFh+0dy1k| zgx2Yp#(OOF@>liuclL|U5e$wn7CG1(?q__Y{MrMPkqR-}5d`5opKGtDqgTnlRxIRPAcm%;p!!LiDw8@U%m{Q*yMBiOxhRgu4X^xeK-scP;~ZvpVpd*U)*>>d^%~O*Aw!}Nvu{PDasr*PQ2$DI{5;Bk8uu^Dr*3e_-&Rka#vFi~ z&FsyJl^4ehVr6kAcflisM?&;qzZC}WwOD&_ROxP~#CPv(+}6#@FUZn`W#cNkOz~8W zuwOjsO4}tC$#NDDrGw(g-#?!*)0AQ^Lc|Fj9{mw{G-}Lwur4suDfApz0Bbv~AcReS z6CR<>-YG27mAM-y{Hmrh3`qgLXUJHB^ zKxJY7!7ZOfAKAlysizRPYY|DPhxBxsP4|7gZ}-G7eS*lLQl!AQF}@9r zPlhh+Cd8>`!6MqYq3cXUp=a5@HQR8h$Ev)dgdcS`jfH7hp)U4emJPguyE>vr?IRet z(l|{XMx<;L_i~fl4-?VSNYk)PN*#1F{i-4$%F0##Khr^Up6F|fNc)BtR6UFe<5I&m z7iSc^I?>ruH;9WC=tEv}CHJbc>QCAIKKLl}!+p++9xc*;Lm^!hx+Hu}I#MEj@$N!; z1VJq7MAkqt_GIhg8nMvUwjK#10L~pF@u;6eK_#UaU5)R9Xe_h=sgAcv9VBT@-ta_Q zBIaJiZN7Gtj5Q;nURSj;$|DmAEin#rHzr6Jgz{HE7%zM_PG>k5lc0N-Bp}vmEY5Ip zVwN&;Ka7P#XG$4H6qA(ms9)Ih8_pHrjkc-BdGQWl+`uK7!*Z7w37`c}68~4P9p&t5ni*$r! z&UATX<6xyXBqyWJD*j04E3n_(d(gDH#89w4wzu5`rD#V~^kDXX?h&TR+fZq;GK+~i zp}dc6;B}`Eosl?dv}V(H_r2SPJhG2`+J}H00z2`E=CYh+h+GWP`roNuU9^fo)U}*x ztnD+4O>`Mhvx+?Uib0sV#4A`}G5p;n16H8rghb^nXXFyfT~F-Trys0k+hOFs~8*LpJdT8{d)xr@q3J6W(8_jMTVhZhm^BGn#&)MP$)mtM605$fs%bQZ-fb$cK2Df{S8I8ch=BBw!M+ma@u!`0cnf9LM`r=t09LS71&ubaUZ zDF{|F)>~xmPM;->^q2OF7N* zJBt>+qAGA`foz^$#r3kcyHuCXJ~)LBGCkp`tbh3$3RO8LmJr-+8TrNFJdM(ZR9DIl|9Mj-G6AN^V;0y0j_9whjHOcFr zb2c~vdEi=iyP;y2Jn%aZA%J+Yuw{Bx6TeU)DAJV#^sTZ$TJf(1iVITUgdwTz!@44~f z+Va1))_iwO>;Cs^<1{j2Sa{g~>zG#2|3vGHLHZ#f~aRJ+F}0lF6vNXI#K!h)fD zrM<5aOiaU_z5^V+$BX3x~dmq zSN`y#_#H!9eGnaX&^_f@Jb#f4yZc`=n+IkBoL~HaOPvtc1@XciXy`}iQrplVyFMXy zG%@1UuUCHA9_3xo>9fB|mjHot<&_hkXy_*|J@zkGCn;I2G{F@or=dK1%Ct-i>UQ@( zrLl{noE2IJf*aI0t)j6mNvTk2@hoeF#_sto}^(R&)k;{Ty3QheC12 z4E2ZgLsP9;n4_joY?#W2M4pok8so3-o-tze7yhA%A(tIHEyqoM z10DQH^ypUp{5YG`yYfx^D8Fdv_lF&5jc(WEFQvOL1(JUL78=t=m?T5uOB2tJ>i>%6 zKTd2;4J(9O_Z{<0mbOf%b`$i%lkpHjV{2>e!{kyI85x8iF|W;kCj@{Z1;KKirh z?gG6DPP6-5*kiCJ6lGD39WdZm;-q?WA#AlbxyQ?L1I6i!4kP$b>FSH7E-o#(=IiCd zA#J*ZC_u6ZIm4<1=SFH;=Xnmc4PLH2AIvIQmVXnV?q*<>(6C#vMnp_z!P|y2$Y}PirkoRNzobH+)Fd`FX+>dx?khQrpl|<1GSWowHkU8GX$dgLOju?W1{e-k+XQ zX=TGHQKva}2@BPUQ@cNe-&<74N0PwMD;Q(6sT*zAn0wxXOsYDww7Tq)0ZHpp5x?Ld zPJ7%v;gjKg4yoA!aE*iTm{{R^!^%816Lf32~AikLmX2Xk(-0j`_M&-MA1{%P5d_a3dL$38DILDpZy)a{O-IJZfP^k zz~;gX|8(}$hyq5mUv65z5Y0p8Mujedc=`zaRUor3->B%mj?*TK#BBd{u(wY;R}?(i zikEwDN$jJ?1I3wmT2&$@m&J*D1D?3#6-w#eWNbUSI1gxQQap^3Khw&EBq5gyQ7ro?_Gw z(7Nq(odq&p`Xbt=5ykBHgEcN_1w)N)PoVNck_sVh%u$|}WPBrZav%W6fq>y%V#?ur z#jW(mDsb~a;pV@Lm(q9lboD(9r+Oi#g563RC>&jzMt|aVJuRP!^r^M(Cvk$eTqrRS zM||0WMZRr{!3}=Q6E0N$(XXpX&X)P^?AAg8g&%^}(DO zT<+()y_h%D9SgH;r9MTCZRRiRa6NxGw2K)}*WK+$t|I=NkWKN-L@Gt@mi9qRIl(KjQ1|1U~?i?Leq#Gs@^ED~J!+ZyT*s#93C!h0wzC+8Uc`pfv#*G(-Ri!A|5+y`MEm+O$c^%*-!C!NL_UIYm={ z9*Dn1xpDJ=_00ONnw48iT6z^%?LyZt)95$4Z3QaEbo5oq)HqB9B zfaDi@zV&-z{bV^z$ypjkrIzsaxJ!CUb@fYJuP9Tk68nl;ZG$4WEr?ovCC_JIEnw3= zZ_V7cY_l{@ynK9WKCH&I)%gCe_sZ5#nn*n?2WNrEYlA=V*Avb$Hr>WcrwTs;sVvbr z8lEJ4ooYN@_8C?yRJujS2|nyP4i>M`|C9d+=P_L+dUO(cG?$iB4;>MNfEs6ywQUFM zc?Ev_?Lo`ktIoi$UFkdly6esF2xniWh~um-Em~*qYL2)OzQdcf~ z?FFmqVTfuc=@r09*llauDsF-iP|(ST?pj3qZhMATEpq86XVEpRP*{@AqYT3Iv#SrZ zP(?Mp&j%kyMF0G(Qt5$J%+4c5e|xrrzq}nQ zm^=wjN$!O_R@6Bw2*AQxgUzmM9@GbjNS@&$sXLy>^0Vlgq%_3iw?Q6%Kt0lS9o#M_ zbVAH3NcFJe`T1qR@LazFShD$7lI&Q4&V+1NIC^A8cMtDGE!dFc82&WWM+t;WH>e8a zH?J|NQq0Vgf7LwVV&9rQJg>arL_R2EX%yy!CcauNRyXUCdgw0fuDn5UDZ0gM$Hn z2{02wT{}}VdJN1IOh*WLfB|-sbAtlUZM)oQw`x(adGaYGq0x=g0>u{hBMeMRfaqO4 zAyZVP@0Ua~YW+?Gq-DP#GQd;CU#l@e5?DImekGz;7yoqrEIaw;f(^Y`D<*4nwyzpz60BXfM%mQ% ze9G*+O-S_GMKYR(f-XYyJYQzj?u&g)4=#y{W9@}&)qF}8FD3yI?4P*82mckC!P{?~VFFz;ywa=HA4)F1ZKIP118{(RxF%|P z?3u{*(w>xDK-!dXanU~dIp6l4Q%KHbPr?6i0VUnftJx}i`aZ-ZZmkPUKqY%oKRjzv zIvfy_ohQ<=EokTsbg|F>WM;MU4KjYddL>?w;~3{yMDyn%9mx$&!QhrSf)U@qBROky zsvA7P4%I8N2%?FV@6^HdZ~uuYEr&n%&%g5;vE=)EP|zMmx0)sCV87`~wYlwQ2J?fR35g)255Kz`1< z+b4^(fN-qBVZ?~Z0R%Dt(b0ZN=c7~7dVM(uSSOvNA?6eLSY8(0!(%)aVV>pg6$Dy4 z1;rz@e&O(I%(Rpp*`rNYv==XAYS2}xnTa*DpziL@iRfLVCol@S;7ij)^w%wTbs_@N zNVAbuNU0Il@d;XxnbqfCzvzFOy3%){oxr+3h~b#WIG~Y@U=!3K-x1c)k{Aj66NrEEPb)rN}7Ae5x-jHq!j3y7I)!^B2y_Zm3A$Z3a z5gmGsd7!q%GI~?LxJHoD)<&_U-#y>JDg1CcNRb3c`8LDcP;3|x<6G7Hm$)=MCo{&Dxdtiz@QG%PFwLKj9W2aO#bqsUWyPxFy(FG^}&84VrF554Nv z1|!uPi=~EZ_z_>WThWHyG}61$qXV!Wndx@B{aY0VHAhL7VK9SI9l_Yz$&t0J=@uit zXKBErv?M30zm{j7~96o7>u9xVp+`c8Y9nh21gF z0~T^{$znl(jm(o;+QRMialCynafgsY}hqvlskTgRte1G_{E?J;^r3Oml51GYt2az=#YT58 zx814_ATeJ|Ufp%NjTCE_X0=s+mi<9J9}Pfl>wMX8RE_T&*qNuvvFFNY$nQ;-1u?Df z_O#M2-&jRN&WtOOkd-4y91BKQ*XO(RHM1iDiOiXUU`%uw1+211_fTlT_*C59sQF$r zRa}CvBOp>2}VX+r@VypsDsTcGOK^FG|T3SOD{%0 zYfCC!RVCm#vYr#&UArUek`ymWoK|(VHrXh`$6!(8I#Ra2rh>{CAXFy=+?(7FTG_|0 zECiwjK!htgHhUHGIe}jfPCiPZQBsceU3fKgjd1fs-?|kjSjg*_tOa_{ zg~tT<>*~f_K%3wg!P&;f0h^aR)_>=^j)0R85+yCOV%X&vqOcugQH zJ6q=3F`A`PdU_k5$LXD!+^IwmNP0jcgR0jy&-v|CO;%PbZm_s#zB;IPDgNdepQy+@ zTh^c-Pp?;U)HLDQ&}GibNfOQWK-5Xr7EAzWDW*z`%mDWPJU*Q~;DmZfe>(cW8vdG3 z8fl&<#)1g?#8ec+Ecn?KkjqtGkr{v#0P@$f)bs)!VqN005 z_Y(Ipu`OW{fK=NRKRh$Q$PcSi7S1F{f+r8UtxM#Tf zfFsSy`C{F7SE^32uTlYu^O^ku()%|r)gdj&Ja1(FG$soq5$`4$xYVai?mJ-*!^MmJ zLM7X1&LWLD;YXr$US?(%d380%CtcNAT3@f{`_tdH4REB-H2SAi?!^T9tgu{U+wrsz zI{Eyg972D821u^$OOM-IX1fPbbQA*|qT!-UT@|sl)zWoX{pX|oh4Vo-2YV;>dB!z- zY(>e^=-}rBZGe>KW%j8N1Y{!fo}VMtwc5K9z4j&$UaEszuZ#@(GRB40E%>xt@Xd1I zUB2d>ACOIoGmRrIs{|6}`5*{&Kkk*LDUqCUG?(qUb0M1NF4(I^=|(0|Pd8Zp!1I<) z25LYmNSG6DSd@7+Q5%FIvdaDv>TGep;TFBJtnLgSD0`Ht z6u@CXljcMnv%E|j_U{^psoy#_X)o-%$VeCeI_?`iTB!6|2lY_J9LdT-rs#4-bN-KZ)zxo)BY0*;RuUEh0CW1f zz(hvfQ5EAO;{M6Lpy4ZfIEHpsXNaq zGa(e+Y~lQdUBfIrcgDGqii3QE%_|-fTG<6uxu|(f^f;1J)zgac3K+ru!w9j?l>Oh6 zt611=;!ixcbB+p&VRz5wO^BusTM>0%nPO^lHTonl5_)(AWJbe4Fd>~6?nxVhrc3kG zc=p6v@oGI3adlvWPe+Wgmi{`~7D~v$dVq|^vgpv1 z6!Sf(tm+af>!=xu$?oABtY~NKDp>NdhmwtuOJZBQ!&{WsRHIf4W`@;bB-I6DqoR(q zxr1|RwKv%1&3okdK+qKp`26CxO8E1axtjY@wg|2=fR8yNx@Vx+h--^z664SDLLWH9 zP=Ey`$pYEnJ5VPYXfO}9=N4rzt_y#@$i^bTFEYdVb)n zbTvA|N=2nE{JvEH+mkF! zW(aLx4uS+vEj9^J_hKRsLPPJ`?%35rc`mJV7GXg#NfkwC^MA!KR&LAVHBqb{-YQ9c z49wW~LooXxtnsWhy@lvy!XJ|#2?M|U{jV5P*zxUyb(GP3K5Bsv^n>aIBNG@(mk#3p zCuT-!%LP3$WRgAVGZ_!imL#nm{+*jhjYG4(6$^+cyRpiv6|;yE{gfjR zQ|DqqUq58+GIZC|h>%2#0Q+z)T*kH1F$rOwJlP|K!=C1d`Bl1fWSbTTQe6!Y8;pSU zc-Pa#VR9}nBnJxE8n1H)DtpVWo2;Mc z4%mWv31g38xNgf0;S6oc+pp_2L%SiZ5agQ50S(D4ZHnNL)TGnArRVFn2$`c5V0)(+ z0mCL>v~hZxT8Cy(-IDgaL88bw>-R_ePcqkf&w6vw!L6;=O5p77O)+M#Vcl#|mP_)p zox-QQ=C|CMxlz>)2~QJ*jH#Q`lvgI&JVRWe`$CNv5bh@Q+IJ9W=#lys!sRY`QYSD- zcFDco{xuJo-~SBV@OX2OFoAQV(<)iRA! zr02bzD!uwILjh+95$kKWL!zNC#(^p<7kZ)bW`QOBctSke#1TNTta?`ufwr{qPI>Jy zHxiR-8iRw}MNr`WFTL*K_sMo}au%th?Asq|+&ErD?t`Xi&@;56BtB6(T=YrBBSKB; z7s|XQfDp`RA3g?5l^X{GGovB}dE%LEU)6j9Q;wCHM1#Q~McUzkP-tfhLs*Uyvs(Ms z<~#~bZn1!a zvM2e~72_lM2`dfJjCP()kK}4T)H?c0LKq2&sL4z^T(y`#F(M1`b-+cM>&hyH=@txZ z#5?rT$6Z6gm>8LUmXiFpe8i~OcvUe@d6)bV?3_@;l7v|(SsLX}Z`}<_UeWA2>_UQ- z-*4!orN5muLxV0Fw9ELVk!#!*{q88t%v0tJenort0rLd5gTA)JxF?NW$u%g1+8QmFnwu$o8C%jKlVC-Ofhf6%< zX*~1R_Of9Og@aCGiou*FfY%q8;g|z=0qt zATxFyJTy@2QY?rOjPoi0RyD#hOkY*$-II^iM%JsKP%#9w=P_1VyYf7NJ}#YvFV1lE z9#sLE(1`9+P(l`X+O)lO9$uwXmEr?U#d%#KV^^e%9$}R!TkxFuXht7I!fdRtZ5E(O zhDttM?gH}XrJew&CWK%CO+=`N7aQFS-{lxUE^B5D2NJ8Rl$5zZ?v#|ZdgtPA!mOED z<(%tc*S0r-D9dT5SP=UlcBy%qX>64*YQ8~}u82M<-pxAzqy+XLKntpwQ9{<&g;#z* zk_RisVML0buP7|D)E98yz6JS=82KB=Jo!yW#rWKsXShKgIJ=ZD6j2G5h(m|cZG}wP zns+fd%RJw|rVOod#xN4TcB)n?EuFIb-(u2%1o1F^cs`2_PgtXB&@c?O9-wG}tp9hA zhD@_2`7Zst57fs;hR-j~jzPoYW7XxZ{Y|N?XN?X9z@*Ry!wr6#C%JFo?SPu1*ab?V z3q*VO+dNrZ9Lc5cxEvX~fwWEjzbVG071_hzE%m7Gu*hiqJD8eletw;rf{!vn?f>`8 z7jO7GBk%-+jD`=)jgC(B)1YM{mo2?URo1?a{wCrTX_-{-cAawGps;*HvJK)wy{>>{?oxR4K>{hjtMtzu` zevg%#>=KtYI`$HmJu+d+6LEM!5@pIvKTcotX5rf1ll}Y$5J>VVstwzV_aL&>IhY_Z zepHrTa2#t;0M?0%J6Ec;#tGF0D(U@S3GM$9jRg2o`CNCP?P5|rLXCDM3>Nck<1x1^ z^~H^hVMYxz*W8}O6-wbYg|<(9>v9^@O8mp=j?3B`Gd`@avav{aagx^IH z)fVJhS$8p<1*!n|V_^R}f!P21k6!xm%tTr!I4hLyn46Hn#jTbUZYL{G!qKKGfP&AT zQpZ@iUzR0Z;>yd9y{!(Dzz7NYr%`skeW2-}gndFB8cIL3M@DM#PX*Kk60z8M)^Hhnz8~x zh^U@nlU_Ze{M{%~Vbr6Lva)D2ISC*3hKhg`{5>u!7Y5$qsfWELL=I_UTB)J0O{*5U zPqjEl=y)YyBePY>yRM(>8q&mZDht?bx}siqh)!?5I=BZkLit>eHi@9$woE6mCjn9$ zKPKDe<_ZVhUb16%fTJy6}! z5FKfqp2qfjMa&;X`~L5hM_y)HtV)0@c;>m9BrTQ=n$tl*eC9lzUrwa4V$Z+z zy`gJPw}jgNE7lWG_Y`-AU>O>!wnX$NiJcjLk4lZzYHV)O9Qr4-k>wL73n+d2zPGpO zyP)n=rc)&5);Slm;Qq;~Jg?&Z)Rfj{6tO!c9j4Fx-=hzEthQ&5I<%YcGO^u2shAl z#Z%%a&IT{9#TOTz{M@uz?5iFH(rMQow6e03vSB2D+2ioClj^O73(IqSdtpsqLoH_2 z3et5kKQb{7kN$1oF%+_>0#?bri$8MFzUsW9THkYmEMoLl+|ezoMBS!e>Er|Fo$VrhmYHJxu5^ZF8?emg7U2Wj`=0Rp6E2qs=MS=ix{AYM@ITrRJS@}Gpj=h zXkLm-KPDm?`5#nJ;2oh8*KZQ_u*TW!i857lt13N4iF}%VCFJu-^@ppg1pjx~u5Mkr z{#Ni)oo{KdC z{rA_HS?Ur=5iqcG$Tc6R133?UeknnHzS>c>C4$%UCaE;%cOF?|O||S$%@CNe{e1Dg zHi4@`c84vNi<`9yY&TA2$FOb6i>oV*nNdV>BH1Ept8jv9n;tbxQ@{2qcJ~wp)}`W7 zAzF3r{VgVo2q(1XiBF~XE~9kPvv022f+N|#FIokBR-Ij*|aD1}xz;*7w{T>lBt|2%=ID zaZ+!3e$a5xfVj{geL1_gW-q;Do(J;R5DGrX@{X*O)XKAcGxHA!2y}`bln5FHp$f+k zZ0}yRk%V#Vhey}E_oAPt77WMX*EkrJL#!R4x5wnoE0r9qM31iW@+zdI&%6;~cv{TX z?+37o_3{=p(dmw1sSV%V7tvzS-pNbN%)gI@2ci{)Z=1un?4R>87MyH=pmzFWR()W> z@hEzT8U4MrRkoK`cq>8)cTV$l?pqTg3fgWZa_;Q4KQ{Xm@;K2H^c%w!Z&|H@4XT(==^(C?od^U8c>ny-+(ay4b=c$EE``n zI)Qnw-mO@$hc}K96jN_!updXEtgyms*yM(T>@8<{7uM$sTo9IHW#+rWXC{}1V}T5E zMMljb=``t6%=HbF{X*Rbrl&*t&phJ;kFZeE2Udp7ExJ`IA$@}=DaQ#}!DLNJs5Qy$ z=f^)Xo^+{%!-%W}Gy5IALA3U9O7uk~t9>GXQdGiS%~EnYV=bB2-Uk}K%O8J!<#!AO z(lI4Y560^H#n!bhGttyx_bY!^Nq9QSRavPM{RI-s{x*YV(rb8jDFG|@)_a-X1t|UG z$7TevvGJp&zY|$HDL_P^SLv%5H@|&-^pSA#*wqLp*U-X(en#k*llCXn32DSL4LyJD zR{Te&x*Dy)vtpCSCVY~;bbj#pqNE4FOb8i1%Nj=0jw#N;Sx0gf>sj z8OmMrxKCi;{d_gX=K4|U8!Ij6rRBy3PiIcwmH5C$F(h{G#?p|rc>17co<$v%lhOND zE@K6C+_ra4Wt1PVXY(8J69`g{LB><=L>D}QWI7=UgT^Msi5+4gTY zGzr@KtYFL6+H6UYNHrD#-{DLPP_o60%_!|r#YS&MV#vs%@nDA0fX1L&wIm-Xb;lqC zDcBq9)E$jS{;QVrxamAOOJ;1-8S+s0XN`Tu?@rt;O4i-BOE$5FI+*R%KnfZoGe%X` zZRTy}^+sRo7lkk5rrs1kf39H3#+X-qOi%LI>8$?xv_(3AN?%kQDUOpnw1~0jX?)FG ziD31abVZGi1$@>6!#nUOy@1%mCiFLJ^Mf7MIliVhaE4T)-SvH zpd!r$0;T#B$7pJNO-hQDQdwAeeQeD& zMv{!9<+BH#%`IeUwOm%tL>$-z&iDR&txvHd!sz};tXbnP)@V1~o*3VWwMu~gUhX_7 zX)UjoJo!n&PPUQ}&ofH%2#icnZC(H4uR?X!*bvhuE75o(JS|hk&QTBLOO*8DP8D_x z=HQA9Z==Daiey@jNWXsXEtq2U*=20;-e3wS5LZPJ&`Dn%aOB@Zxc zxv$XlPghzQbMsSMV%3CXp513g)e#4(nGJUGLc?;dZL4tD8cGSC*NQ! zc;zB;_5?Q=E+Q2M#Go*?oPrF0Su>}VWi}W zOgJkw#GfG9BbZpf|CGdnJl||N1go4gV_;>a`QS=sx2mV1fs%T(H(hNdC)(`J?*?9a z!wSR2?adS?$H2lW*dQRpz$^hBq*SPL^LhUaG@@#0mxjvAMzeUf#92fNCfYG-8P7;% z&5W(doW-;;AMV5lDm&?YIJ`7$(BE6Up6#wg09o_n-XZXtwK;2C# zU(gb=2#?Q{_I>~U^MK;V6uPB=*EcznRDP_ebn0*1hIkwy#e6cK#;z9e%eNOJdv!#^ z!|!wFzw*~fOj6q3=OS9!M~gIcaruL;6^;F`b+K;Pv_D-4|HVU*FD`B9+)xZmF&(hc z=cZ_hl1TueDp$=T`{IyKL+H~$XCux4m5u+|?#JDcoqaNK3oVYaE*ySFMiUQ3C=?G* zhpZ3s7!LX?{TX;8&JwGRC9)R`Kr7J{+3m>j->wk`D#CmL{%K>UvKh)W0i{$1ZUB)1 zEaNzJ#p+S5auC1>PF77#2_5pQI{cmHqq;?zzH_{Kx))i%7E>JD`wyCx%8AZ5y?N6Z z$|l(0`Mx=h6em<7=)YHa0|MnWHD=Gu8J^^1oD*aJ$HrDLJP;(#5su=iU!HC94N4~c z)u_6oSSqJ^U)yB7gso=;>Z65)-C0>HCw&>1mepZoExrq`o()JOTK%?Z-Qt&>E$`~; zk2Jg=PhjacHz?={uvgpkbpFC7K=5GLZV>ItZrvm^_3t7;AEF3)hp53FpJ$m^=$T%b zC#|0pev z%T=7@#bl4{pSA;NZYzDOQ*Vy_R1W<(%Ll4GUG}fD>kxRK_iVk~EZ-m?AQk4XXryL} zR%KbWit5C7b{p>u(+4dgL0#1QXzy;>8Z#^mQl@<^GC5U$ar^3AzsdeG>)>Wf z@ZzS{>${+ys{ZKY`}FTmyoWR2?2qF|CG6`|yhCjpXd1IR>~A(;vSRV~{fu4a;2`rt zh2x5cZFFK`56aKq8FJh-tcii<0_UtM(LY!mpMHy8ScII?66)5}FIlU9tsTDY$s_Km z3{P`t@sgp!2@Ol@i%a-vwbBfy0aSoQSTGv^m->-5_c&aq&8>fm*Nh|pTUmEKPnhNz z0w;HrhHlNBuj_R8C4!u#>V_<1V4%tJ9eDGQ0Q*y>)KymBAZBVRB_;^Ef4M2=)iSJ1H0c9Apaa05Z;^&*U({>T2QnQcH52$5buV4L5Xryc)`ULf_MzG;(_;7z91I;&~pqZPf2 zR?m9HCEG_TuKXHW%;;HRcs?Wb4#F<^H2pF(IY*v54!Zw2ZxE|qFHXMq;x>@^b$!{J zS)`?)UG8uKjY`-eXy0nmojKVDH7||pW)rOvyqkmkuVF5ol>sr(1`I9j5He~^E~8@0 zcVF?2Y6*^sQ86C)fjEwDoMC!cf)9Rt`nQWWWshD|vz)rbXM5!3d08EXw3`s6+~Jc! zhK7#Hs=eyvN6jN-CZpTvVnxJWKhp#ICz_VF%A0ny*8W~uxbW59>3PMtfMqr+Z+dyT zVar;e%BE4KQ-+zyser0tJ_E%ZVEdrm>uGU9!pG%|tVby;D+jf%zvlXDN7*Jp|1?0p zT4eu)LqKz#?&Mi74GWKLOBQk|;`I~-cbtm+Aa>AN#aMur1)`$pRNwxre7&&v+j13(cLcoNiN`f+<6y$9*il zk{)5=IC{Cq6kB#dPYY%PVSvEAbm4H?c&AnR!(kGk zCHD8PsgySnDo{uZ=KgS-7|^lVM8~XR!aZ9qdFcr|2?-G|4@d#cgnFc^;BDuK?s+lv z)z?@+e@jYG5FRlpZj0JoWZO@+D zVZU6Sxr!PG&-(5uS~0D#a330*OD^Y|CzX17fUp6bgzB&rw1PX?p0*i3q;8Mg>9`x- z8U25~0IF(wjl!bA%i39?JDTk+H!XJ$8jQD2K8oQLR_b+;I}{J^_7v7?KWDk#a(*20 z^fe(P%Rp`7n>V)Dc#gHb2ceTmtu1$c3z>x-_KIU)6nNEMm$AGkTPA!e_wH*}+E)xr z(nTEDdhj+eThs#}ifJe*{ox>QA6w*_6UO*ls}x1rVmvsf;c{_$I>n<^W#3r8-z3FW!`Wti z4|3C<8xW~Dr{-Y#a-XkGH>4f{IU)#y)W$-5!Q_*)C{F+IRywq+uFP1edn~71M2HOq zT9DnFb1Otth0*5csX?L>*I4B83JD2EL)Y56Hf+-}vYW>KXeVt!1yA4x^|v5|{%m%{ z{4loUN(M;!%743C?+WbK6-#Bm<$iTl3u+H*XyBXOe7C);yLknK%51+U)0-WDm;5Q+0?X$^27`Y5p&Fp1`bw)dh;`cJ_8R^dgd$1O1e` ze{J}VE`xW8`lD&g;c~$hab}nXz;GVjjlKthk_+EYsVqxJI)f_vf_kNoNP7FbzxDNAVB7rCNLMzm)DT|h*i)PTSi^s)7Oh(!U&>?mAG?-f zz3)W1c}Yq6&E?3<)yUo8B>`y5&e?W-6h(9K$^bA@TQEZu{k~)DvOfNc{Qjg`N$k~g z;K{2Jz9a-ylnM9}y@B&VE zh!QNvBonRce4-fQy-nk?`zfPj%I)M5alS;{Mx+V*ho((03#aeS;ZRU6Zw6C#@iNpY zP@K1HG2V?x9s(Cj0ZIux$Qm6`1^jkkMJ|6gfe z{TKBU?G1>qNQZQTfYJ?;BBg+Iw{#;dxsoCxB_$~!-Q7q?cXxN!0+P?H-}`#*A8>!# zn$N_UGw(UQ*bFq$ric4!rS|vU#CUkMO!Kd5b-ntu_ovmmmZ9qlZ!E1x-5e1dwF}!|ZWap6e$_Gzf7LXQ9zCK(eHBZI2I7nLF)ORN z1f$l!w3ir$R8>6fnlEfIZgYum*Ug8diRcdbqR>+nJl)>LsUSU%)VJdRF6Bp>C11AW>2VvT z!t!9SdJ3dpeF!wbN^!d@Hq{>O0OGsXar?Pt6{nV*72gpyFl-G0#V!lnT_0TUJQv)I z#t(4YGkc_M7putuB>T@qceo?{IZ^HYX#l)lDyqQPUfLMLgk}5YjX;a_)806Cneu!Y zZ(y!-=-el0yf&xgI~tGx>R&TAQ*fFDUzCNCMz%e86omNLf9d;Em7Y+>z|fWw8?@Uf zoRyum?JJ_S=@DkOqj!5NHn{?naW)jGzpC9YxULEcU{P>C9%A&ly_vNUp69_O`9gRLp3=b9WMrWT9X+ z`!}TsGk@~*a7f8ENhHC2*t!P-w!^i}tX}|CAQC8-0U+8Y>a05}w3}JaKjo<8574Y@ zsd>0INjkpu(4XSJdnqonrFFeZAIl*?O`wj8#Sv z3XeTj5S6W87#g~*RfYtVoqrK)DZq3C7ljI!nxJ7n-T9KbOD)6#uDFOLeI;H$x?#j2 zC1MdD>kOCO!lil?=#gL~`@4LLtMsTHDNbtl^rGX%p;keGRIo@-tEH*0|2M&Ya|{9k zxH1EuNyidh48y8SP*^RF=c-evaKOH8aS$MVx|~!PNazFZ4n1E(AOEoQusQsY?fv*P zuoFc_zW&8(Da#g|kB~#p^$ypzEhiQdEh3ZqVZ)@GjN8Erds6O-*hKz_{^W~!mMgTm zUp}H(*Kv#eEd09nGxv)IU$qI8`qQ@VGb&)o;<~J#f_ltTxiWmlJ#iH1NO|wu>~s+2<#kuU zi~KnH%odJv|o3=GSamC1jy6)iwKF@JQY}jT9yo8Wx&|!cU1SQfvYsaKP2?q}MJ7H! z#U~~ED>@cguUaT<0&>JyY{o~6{MCs*qEwN}es6Nwd1+gnIo$$m`+w0uAk07aNZ{(B zeVhoF_-A22gTOh~!+l^O5%_ree*O$79=dyfe(<6Kf|P+r%*^@~hd+z3%5zyjabAJW zp}lWEFySdHz@3Z3gEmE9Cy);` z5y6yA#_8zj;j;IS7kdYScsZ44yLN!ahx#sUlZgCL;4oaqOEDymzvgT{E|KGCjf8@8 z3?Bm^tI9*r$g9-WcNEV$CMP{l_A6kyB@bFnCa4q}jI|Zz#~Su*qY4b*-cl+v4IPiD zNiRSLrm4?}60+}V^dsvFKP={3dAvBdSU5v|jRZ`YaQjU++dK86$Hu9jM&Yyq++%4a zSg;s_zR6g-(7VB?mYw}RJsn}jd8;il^7zs(&7P~(m{0C*dI=c33|)X83_l;%Z*_k8 zezieoy}Z2yet^%7ZO`E5sD52ug&TGN7%p_+u$a!7izC-4C}ez$pInL?%WiFOWBn4x z^6A5Bhu3`~=F&s+_z?UgG~}RmAQc6Nf*<{gr3?%iCV!p?I5`3H&$UIQRWCv9=xCO& z=+mMic`Z}mtN}tB5IN(nIg9&sIX1;^)PA6OEiQb9H4s^DNm<$wxa%Y)_UapgBf79b z5}02-8D`d}2R8O~({13oX_=7QeWN*G^8bNQDw*HSKw`+lCrr7!OCAGmq2&Y~2|FpIv@? zPt23alAP?f!2H6I#HpkNogg7`-yr!KL_>r4>ujs9Da`SjXN!kJytc(zUo_e3UShT@ z9z>{}aa)AkUQ#9U;KHxE!ON*$bwa_9<=xy&%&J^N>GjtFlZAqx%|lCAXY}h`D8MQ4 z*KhbSKB$<$EB7PBRPL=mFcbnCrRe+A)`ZmA`8t(LX-C7BZ=1zz%{{=QCNF0ezVa5_ zq$SOXAsI_7v2bz=zoUosyZttU8N6*|6$~ zSzkPzVDDcsU`!sV6+g7jA6@IxzVPUK#P6`!n0F}!7s7y)3#uAi`e<<+_CEg7EN(<> zXGfGJ^cDaxx?KEV_{`Bwj^DL=kK5DH<94cSW4tBq(m7OGbc%^;sqpmqOfhoKk#7*wT^Qx@tH_wOM-9!Kt$Ei0W zcCxfzyF!Ui;gIiGo$(zA8$62vepR|42S-N;3`S)#@FT!BqL2o-mnKW!_qgNk8ept%@` zEFfmM6Esi-4c37T8LphLz)V=ScO^;;{m_c*(Qzu3CToFN!`He4Bu+8Of}O{c<4*+B zIlkzL!N5_=4l3`2m1t>A64Ny``EHU7*D#4`=%}!>=`q39D!iKNlg82u5LRq+G_T7$ zfv-Y*RVZPz#eX?fadA-VjxiD$iCxx!AXI@MBBtgzjipF zNS6#eK?B^Sn_4^Dob>dvnipDpcBH^*LHhv0Rg!Z{)=xstJ#gP~&>PJ-lW3I+JZ&iv z{p5yLov1xYOaWFjKAF0%j3g!L;Ro|3|KRY^>S$o_ljkL;WlvG5W;`w`{s9cyBApBY(6_9lpc{L z=UlgZ3F`acX33}drycf&T5Hqyk+$Q5i}!d1>w=p)&#};D9WbSkwOK@QB@a)bF3|lD zCAKrv346*rkCTNz;sQa(cxzBq4{X>{h;P`zowYZKa>x+Kv|uVRQ)y-VKn|etrA8r?juAEc zd7~f@nvCH$>A+lE`+b8thpq&bVy{)W@w_rIo{~;I!C%}bzrff+wL!{ zai#aZYyOWdf%SDt1QQ79vI1sNEH)TR=R3grJm(~k!faGV|KXMFTR`dL!Kc&Jc7kLt zf_iw&-pV?YYE=_cYH$XgA(pzZrKXCR=$S<&PZA4SSuyO-#rs!RqvsY15741TxAiB6 zGO?vb^!Lxq^L|cOx3VfVs71Jh-Lwp8gO$H}vi3a8RNG{o1OrX0-i2**DD6{luxf7M z{$_^KJONP-ExQAv5VJJ6_Tk%seaU1N!J_+>g_2XUTdS8A@U}<{gMy^-3SQ&Gy-uMH zZ#cR{SyO{PFXmB83t>=@95K1%2++5Ta5rz)T%qY8p)y1C6Ky3cowGwcYQ8;#j4zBZxDW4aVTZ>4FtD-W*C-R_TksdBaQ; zNNazz$O0aCW&QRExjFZJ8ndR0m>uV=Ko|{5F(y`7A?G&~)DR_o9|_F`LQurW^Ym|O$whZhB3hD>* zWC7rJ#DG`UG`T*1?r}CC3}>#Amc_wxS<;w9Zv2y8W-|_%K zBJl5RY#N|Inq@;?*ckn_XKB;$I|yFT&yz<$Ah5T0Ob=3@6CJGq}Mh1UkGV+xhD6PhuZ%E#+Ul(5Z#M7lRF^ zWBXOoWO8vaB8HLO>0gJvpyuFDk2{!KoCqGM;ul+17$xyxXVjI4uY5HKUa~IKES%t5 zlUKv=+}@T1ye{BGX<<~Gx~^Arm^c_lt*u=8i#&9BBN+u=ISwz5S0(HAqUPaGpcMQw z68KDCRdeb5?h(9H-AnM1M@=IYm^tCUnz7hqS;Cb9Qqp&K4+jgzwrc8&T_-I)(a-JU zBt}_Z@DyQI^6vBD*p{+Nhp`ryNyN({3#tVE}Ju&!+M|V_QS(`nVnQ^n9$39w&jr%bUvbZct{q!?5(yd_?2UkqNXv}cXg(wEvWcXDDAu5oQ9mQ@8S1@ zGSGOU>v*@|!E~Aq0)bLZix!sE3dmU7`0*Yb!RMqq=LuHCV6um=qg$}S?q?NwdfH~? zS5keUsZrB9Wf;*nlKHR_fQp1<#4UzlGhek=rdvOfQ}O=KdqGE|7?}G=4+JGFtE5EP z+B%MY9P86>mYJ$O&Vq=YSj~5w|7LAojcrp{(&E=Cw3){isVLSYFM8`3P_l>rf_dwW z;?T>PYCG8X2+eF&0|O=)>{8dqn}XtD^$`RNX>;`Hpq(`7#|u?oJ73>o+qr6;Mc;-+ zO&HprKZ2vPI;?hfd%x1D*;(zjf({Q~kq}>{V$*_k+Ie~@>WUO{lCw?Jivul_GP1fF z2HM;C__SRdY@BW;4ZQ^vKd^gBu-*f{(4cbAokJ7-40fH5gd$v94_>?|pZ6v>D0xgrm>b0(XRAYIPGox7T|(1$`USu<60Lto02orJfIMD;v`6 z-@l0)#o10De?C7itjG{;O?>>}^3dYzdEC7HV6xXUaszuW+bLqs3N?Re@rHFnUH(e*W9S;?}F{y$?GFA_J)S&F(`T9UaI6 z2x4>fFp&Zow#GZRrtjZ{muHs3x*TMMecNLx!y4*5VLx*G9E_H|J|5Q5X|%9=c}~`i zh9M0HAkZ&go%j~Czv9qZw-Ufnj-Y64)C&8&puY2^5r z@rB%6b%R%=E2+3R!f5M-arj(KykcE5LVx$rP?hgA-5w7Vir~?Y-A+nI8t0s$H#uB7 zf9*;tdSeU4e+(G@>0AhJ^VNH^wmnvASHLG9Pox?wwC0=dkpFwK6+F2>xf_zCQK)5m zH$HaMP5%DEXd!Y%i(O4# z5zZN4dh^Q>6Qr6>8KWKNIz-ti!h#Hj-XEgiof-WA45h1EAdyA;jsV-wpx@*9x0|zm_f6{ldg`Ifn#tDZ?rwBk z?F}L`V3)bz5ca;-fCrmDQc(39U}ptj88X^T1(^GEH7vG23=xp6%6ThzeM0jgv3m8- z!CaqNd$5cEF5&gfl9-~6;uwG!72O+VN)bShEIDD{*WW1bA{tM>)KpA7CEDsvauDt7 zek=zTrQrK;6ObCxWmGEb-};ng98Qa{k&y%!cfXYxlaR?t>%2T|iFVz6z!Njg3rUIm z%*(L&ix@7?g!ML$IppZ5Y7Q0^9g%vUmS|qXBGTy$L3dpZgOju z7{sU-)K}KDmrCK_KrvizJz6Sja+ca9*MLa`Cy9 zLrdiO!Ww|;TJbA2KsMjY2KQ*J5DZ;pM8s~c9#OaHnv&pRv$UJlu&~qHvo8E={a{vq zC|Da2=EsAon6X9e$*Cpw26wU7CT7ru2C+ywnR~A(KZ|Kv(8iZ*j8>_zCQ>k4H|LXa z7y=?o_2c>|6t0)qK5Hwh_Tod@U5 zx5f+!dj6@q7W}Z#{yQ8BBS>L@vsL7coYOVE+o!Kgo7?HU|sQeQY@W37Mg9qQ5k?zO;-~v7zD}>~g`P zvH3G}nIWnEVkiYaFMl=J$oie}S|ayhI0mAl`_1KE_%10q59RU4j%9Pw%AfbYJ4=zg zSaq{01rfSEk&$brRs5FIu@FP8EpY@rzq=toAdW%duhH$$SxYtbQ-18=fn5v!<>hJC z5=c00(}m@kf`Ekd^~;~bmiOCNC*UpYOcn z2uKpqe0JsTf-5dNdt+XAryK4MT;C+mJA1kQYtF-8K!W3U_39}>^Fy;xM0JL8l%m*% zGnOd{C1*mmuHW#y@LkI6>4xWx426U_8uIu$lg-o@7nj@~691<;)61Q% z{R|tm9_%Au2KK9K}Ps5pg$+jADR2r_vA zztjt42t;;vIC60>p5@K{r3(;be`3+h3EvbZ9wZCD(FHU0xZn7@91wbEK%H*rEe#$< zL+(GPt*ji51H1Ajv zR(XlIm{TQVapHtmBnn2K?N2l^V5nHCu8_jMNc~g~3BSAGFrtC}u9euIG*v_KY&K1n*cou6~FrX;#4(qImgTkNS)B(d}LR%cy}QDUD(tvajzsc~A3N3+S;9f;}c?;gz>IVw^3 zIh5RQEp;e5SInlJd~lBtT&S=7lhL=>I#DJwNyr{m7~@qbNvK+>_3>!g%=V z8<5>Ba<1pADszR}B|Fw=(|oci?fO%gRrC)IEF(LmqhNazq8QNN#r29B2PXWv?c^ON5gL^6N+6u4E5<#&k}z1kl&6n;_UQS ztVWnv_56CSBeZ^LiaGAx1AG~%H0bl9Z2a0A8=fTqE)8^RBl)_K{qDK#IAX+ZX$s;6 z7^$~k`n+s*8KD}@3 zXr@Dh9G~0E*WCa9*C_XOHK}Eu(%RK4(mjbyOlFz8AY52ye z1T>09(IFvNp|&$^f&->^cjnFMcO0Dyb&=m=LvL@lXv2sU@4S|LatP%;_lnNl=!C)` ztUC13@%*sw(}T^sEc-kQUhV6c67L4jyL41C?&k!>Xx%9<=j-yCrhX(jumw&`nim({ z-#H*5;hD zV|UjCb6Cw!2ZcPh#)1UNAdtNBU-!R_^RYfbBNGQxd7U}S%<8s#L>>#d|=U>^o2mxOzy6AouB56#^}XK?XER%t4ry`4y%B(^m+jHczj7u7iDX@tV2oN zK~>Gt{FKqKEd(1ys=mJ8R?b~RD`{eKw?vmN+BLHYKGnSY->u$|gx=Nwb5HDf&!ucy zJZ1gv>_ZQS8aF#@_b}C<09M`kg()MYhfQ%wKMk!pyZPLf@VzNCNWv#O0JWR1e;M1U`rwa zmOLA6)(ys#!&^C6gdi!*{PuSA*L4%5>zmoV;KaexdhbLilw@19z}@B-H@+)`A-Ij^ ztnC$jbjssG2G1MctJWkR{R(NZ{*L#FKBBIgEdyNFh(C+pt*3hJ-;DTRa8NARzvc&j z^Rb6>eSM{NmB>vJy|WRbAlw3@)BVDQe;_sNy73ldQddJbFgR`ho6WugXK&C!IF-kcBl}5YXhOk!T z+kD4bm_swCGk^3zBh%GOADyQPbs}Yo)fbcr_1m7$@kY=;PZgicJVvB31K{AEbUN|< z)*Ci0lM|oWk_JuhEBXuS70o3zHKAfH48_E|q?H-gn+_q%$O=(%(#wH^8OE-=(Dq^% zhdP5H?(cwuC2CSmd~?bnw;Lt9KQxkdZV#KhK1h9>CLPc~(a*`jDb1FPYjt7CsUZXp z8F@bF;J=%(d(m-t;!iz!wrI_g?_Qe8zT@?byOJ|UtUuE1Z-tXuoi|P%T9^wPtBT^s6brmh8uP^* zIjE5E4tS@VbhGlmRM#dYlh6JRCo7I&oQRk^^MFE^U&7lJvt?r;a_{Wo<(1^bLlyoEtAu8I~ko_y0vy+W-zR1)5rp7*8*S3-cA+Vs1Yyhw~< z?9_j3s}>xx!#8C5?AgUW(CVB|I8u(3vV!jEf{WRrVwn$wxE5AKV|E77mR;{Y1%O%w z&q&q(7>!f>Rsixady^zb_b!yf&v$cZqFC22viODNE{-EV1qCv4Eg2Rm8A*5~43UOx zTQqE`#n5z7_<>UBjE0^aPuYf~*4R=uD_7Qm3>2|qZ|Rqi=U^wKBgerh-ySHQliJ+M zAm4mls%ZT4303`3L4+vYOnJ~npf>o=5cm?%K;aRrR%tT+UDQBFEz>cEHmZI>FTOju zln@Dibl#NflE%iQrrP=@2V~@1$(nm=)mbRiC_aR8w1gcOSJ3rsR(0G(Ac>vbPQ&q8 z?N{is;3g8h!%xue&4Ft~<0Atkq<$D>0(lt_{(u~!qTO>%ZPg|W84K+q$)IcVhE(Sl zj4es?ZkeHANu&L29jD;xUsH)f$~~k&HjGH8tenC$?|Qmldj5V=Rxh}Z6Ltx zwIdot)bU=}ZaJN>{hgvHxLZ<$CTd-&)nC6huO6F}jzC0gWqg;Kg-JgCe%fkB#W{i$ zs;1uv(B{G|YE)%58oK;wkbG4s_jT#i+0dTDT2alo7o{xFL$2pMcAw8i0md7rnh$-6 zEF^MYn@AZrmSZKCC4IR`L-0O<7O_<(SF9Gmh+FRfuWI4+$SYl1-bar-OG1OeupE+Vy z$K}VVrnR1ma%E^}kG0lgT+CL!d3g5?MuOl+O2tU+ApvCex|zWpo3#&j(BI&9E*SY` zjN&+k8^W!L$MhA4G9_m%F3t<)1L0zE@gO1!Fa|TfX85zIDhDb%G$@qg*}}%#zTSNi zzJ+563jYQ9ug@%eQ0V0@I|FE{`89JZbHU_mxRw9doq4V?w4tBTOc#_6%a^S-9F4}w zCReOG<$t5d#B|-k;(bOFZpN@`J8e-@et97`v6q{b@ zgMi=d$fA$)PxpAJqtJpq>4H5i`}Vv1*YMGsP_;o@F3yP7`@0LOoTRfg76aRb0W!oD zH-Kpj@5&E|aCUL_2_d=9oLzbO%0(aH#l+{dgvSv^9ooBJIJl^-9~<8-R>cuEwA{EI z@m(iAqn0<%xc`lP7McX%1gjtDcoIQN5JAIm0^>P z>Ag4aT<)PT4K3|a#k18He)3Jk%nI~RIs5k zX}Js@qsYsz10Zb>8v>5FkQ;Ft^f8I$#0zf3);j#^I+RW{P9O_}mF6YNFuwq$ zp705H{Ba_P8O9XSe03Zp`TLbZj9Nk{xz2J|u0G7-aqHG`HGJbIRZlCaa~>#KP&Kfh zpuxi-uOG7A-L*eJsYnUsfNu^G;)Fs0GdTmsd-Lqg^`D<=x3>g_0x6b9w5scwU z>nM$wVT(}YOJqNf`;T{a@b*=1MTs-Q6~IvV^lTRgM^bVyWz4HdAvUK+r|RtyY@Ft* zeJvts25XO-TDdhnh3030oT;OdLa}K+^U}C5B&O+DViuhc4MIyBg0<7MIL?!~lTK!z z`}#NpWG-E}-5r2IqA}6<0(+HY*MX*g@}WvGC@3El7J%LF%{HI=3LRPUV*ibyEHN1! zwdE95pu}O8Oi2QSAB_B3Aso>0`ng?b$HZiQgKJ4c|7#j`bWScO=icMF9BC|M$!c3= zktclbVyPgxcW-4BWaPqb5*Z-%%Iq!zVcwiN0jaVJ;3;XMCU&#jGj$ja<3OgR;)z{rmU+?(7J^xld}lH4XD1uoa~$C6mxpUP9q}1FtEc|43eAgNJ;CR)%$i>^m5}`2$gR{ d6q4?#q@uktPOtB2fH@4|jnq5IVhJPv{|Cl_E@l7# literal 0 HcmV?d00001 diff --git a/manual/source/index.rst b/manual/source/index.rst index 412a30dd00..306329d7bc 100644 --- a/manual/source/index.rst +++ b/manual/source/index.rst @@ -19,8 +19,9 @@ https://www.nexusformat.org/ transport-structure stm-structure cgms-structure - laboratory-structure north-structure + laboratory-structure + icme-structure napi history diff --git a/manual/source/laboratory-structure.rst b/manual/source/laboratory-structure.rst index 05523bcbfe..568e6d4823 100644 --- a/manual/source/laboratory-structure.rst +++ b/manual/source/laboratory-structure.rst @@ -1,25 +1,9 @@ -.. _Lab-Structure: +.. _Lab-Structure-Fairmat: ================== Sample preparation ================== -.. index:: - Draft classes +Prototype application definitions for documenting steps during sample preparation are a part of ongoing work. -.. _LaboratorySteps: - -Virtually all experiments require a preparation of the sample. As most techniques -are surface-sensitive or probe exclusively the surface, the use of careful preparation -techniques is the key to successful experiments. Unfortunately, the quality of -such processes is often difficult to reproduce. Nevertheless, documenting how samples -are prepared is relevant. The classes here provide minimal examples how descriptions -of the sample preparation steps can be interfaced to NeXus. -Currently, we consider these drafts to work towards harmonization with the -specific examples developed by the team of area A of FAIRmat. - - :ref:`NXlab_sample_mounting`: - An application definition to document how a sample was mounted. - - :ref:`NXlab_electro_chemo_mechanical_preparation`: - An application definition to document how a sample was prepared. +A status quo of this work is reported here: :ref:`Synthesis-Structure` via the :ref:`NXlab_electro_chemo_mechanical_preparation` and the :ref:`NXlab_sample_mounting` application definitions. These are drafts. diff --git a/manual/source/mpes-structure.rst b/manual/source/mpes-structure.rst index cae1c026b9..3b0fd8394c 100644 --- a/manual/source/mpes-structure.rst +++ b/manual/source/mpes-structure.rst @@ -1,4 +1,4 @@ -.. _Mpes-Structure1: +.. _Mpes-Structure-Fairmat: ============================================== B2/B3: Photoemission & core-level spectroscopy diff --git a/manual/source/north-structure.rst b/manual/source/north-structure.rst index 2198f3f866..26526638d2 100644 --- a/manual/source/north-structure.rst +++ b/manual/source/north-structure.rst @@ -1,264 +1,26 @@ -.. _North-Structure1: - -====================== -Nomad Remote Tools Hub -====================== +.. _North-Structure-Fairmat: +============================ +NOMAD OASIS Remote Tools Hub +============================ .. index:: - IntroductionApmParaprobe1 - WhatHasBeenAchieved1 - ApmParaprobeAppDef1 - ApmParaprobeNewBC1 - NextStep1 - - -.. _IntroductionApmParaprobe1: - -Introduction -############## - -NORTH (the NOMAD Oasis Remote Tools Hub) is a NOMAD Oasis service which makes -preconfigured scientific software of different communities available and coupled -to Oasis and accessible via the webbrowser. This part of the proposal documents -examples for specific NeXus-related work to some of the tools and containers -available in NORTH. - - -apmtools -######## - -One tool is the paraprobe-toolbox software package in the the apmtools container. -The software is developed by `M. Kühbach et al. `_. - -Here we show how NeXus is used to consistently define application definitions -for scientific software in the field of atom probe. In this community the paraprobe-toolbox is an example of an open-source parallelized -software for analyzing point cloud data, for assessing meshes in 3D continuum -space, and analyzing the effects of parameterization on descriptors -about the microstructure of materials which were studied with atom probe microscopy. - -The need for a thorough documentation of the tools in not only the paraprobe-toolbox was motivated by several needs: - -First, users of software would like to better understand and also be able to -study themselves which individual parameter and settings for each tool exist -and how configuring these affects their analyses quantitatively. - -Second, scientific software like the tools in the paraprobe-toolbox implement a -numerical/algorithmical (computational) workflow whereby data from multiple input sources -(like previous analysis results) are processed and carried through more involved analysis -within several steps inside the tool. The tool then creates output as files. - -Individual tools are developed in C/C++ and/or Python. Here, having a possibility -for provenance tracking is useful as it is one component and requirement for -making workflows exactly numerically reproducible and thus to empower scientists -to fullfill better the "R", i.e. reproducibility of daily FAIR research practices. - -The paraprobe-toolbox is one example of a software which implements a workflow -via a sequence of operations executed within a jupyter notebook -(or Python script respectively). Specifically, individual tools are chained. -Convenience functions are available to create well-defined input/configuration -files for each tool. These config files instruct the tool upon processing. - -In this design, each workflow step (with a tool) is in fact a pair (or triple) of -at least two sub-steps: i) the creation of a configuration file, -ii) the actual analysis using the Python/or C/C++ tools, -iii) the optional post-processing/visualizing of the results inside the NeXus/HDF5 -files generated from each tool run using other software. - - -.. _WhatHasBeenAchieved1: - -What has been achieved so far? -############################## - -This proposal summarizes both of the steps which we worked on between Q3/2022-Q1/2023 to change the interface and -file interaction in all tools of the paraprobe-toolbox to accept exclusively -well-defined configuration files and yield exclusively specific output. - -Data and metadata between the tools are exchanged with NeXus/HDF5 files. -Specifically, we created for each tool an application definition (see below) -which details all possible settings and options for the configuration as to -guide users. The config(uration) files are HDF5 files, whose content matches -to the naming conventions of the respective `config` application definition for each tool. -As an example NXapm_paraprobe_config_surfacer specifies how a configuration file -for the paraprobe-surfacer tool should be formatted and which parameter it contains. - -That is each config file uses a controlled vocabulary of terms. Furthermore, -the config files store a SHA256 checksum for each input file. -This implements a full provenance tracking on the input files along the -processing chain/workflow. - -As an example, a user may first range their reconstruction and then compute -correlation functions. The config file for the ranging tool stores the files -which hold the reconstructed ion position and ranging definitions. -The ranging tool generates a results file with the ion type labels stored. -This results file is formatted according to the tool-specific `results` -application definition. This results file and the reconstruction is -imported by the spatial statistics tool which again keeps track of all files. - -This design makes it possible to rigorously trace which numerical results -were achieved with a specific chain of input and -settings using specifically-versioned tools. - -We understand that this additional handling of metadata and provenance tracking -may not be at first glance super relevant for scientists or appears to be an -unnecessarily complex feature. There is indeed an additional layer of work which -came with the development and maintenance of this functionality. - -However, we are convinced that this is the preferred way of performing software -development and data analyses as it enables users to take advantage of a completely -automated provenance tracking which happens silently in the background. - -.. _ApmParaprobeAppDef1: - -Application Definitions -####################### - -Firstly, we define application definitions for the input side (configuration) of each tool. - - :ref:`NXapm_paraprobe_config_transcoder`: - Configuration of paraprobe-transcoder - Load POS, ePOS, APSuite APT, RRNG, RNG, and NXapm HDF5 files. - - :ref:`NXapm_paraprobe_config_ranger`: - Configuration of paraprobe-ranger - Apply ranging definitions and explore possible molecular ions. - - :ref:`NXapm_paraprobe_config_selector`: - Configuration of paraprobe-selector - Defining complex spatial regions-of-interest to filter reconstructed datasets. - - :ref:`NXapm_paraprobe_config_surfacer`: - Configuration of paraprobe-surfacer - Create a model for the edge of a point cloud via convex hulls, alpha shapes. - - :ref:`NXapm_paraprobe_config_distancer`: - Configuration of paraprobe-distancer - Compute analytical distances between ions to a set of triangles. - - :ref:`NXapm_paraprobe_config_tessellator`: - Configuration of paraprobe-tessellator - Compute Voronoi cells for if desired all ions in a dataset. - - :ref:`NXapm_paraprobe_config_nanochem`: - Configuration of paraprobe-nanochem - Compute delocalization, iso-surfaces, analyze 3D objects, and composition profiles. - - :ref:`NXapm_paraprobe_config_intersector`: - Configuration of paraprobe-intersector - Assess intersections and proximity of 3D triangulated surface meshes in - continuum space to study the effect the parameterization of surface - extraction algorithms on the resulting shape, spatial arrangement, - and colocation of 3D objects via graph-based techniques. - - :ref:`NXapm_paraprobe_config_spatstat`: - Configuration of paraprobe-spatstat - Spatial statistics on the entire or selected regions of the reconstructed dataset. - - :ref:`NXapm_paraprobe_config_clusterer`: - Configuration of paraprobe-clusterer - Import cluster analysis results of IVAS/APSuite and perform clustering - analyses in a Python ecosystem. - -Secondly, we define application definitions for the output side (results) of each tool. - - :ref:`NXapm_paraprobe_results_transcoder`: - Results of paraprobe-transcoder - Store reconstructed positions, ions, and charge states. - - :ref:`NXapm_paraprobe_results_ranger`: - Results of paraprobe-ranger - Store applied ranging definitions and combinatorial analyses of all possible iontypes. - - :ref:`NXapm_paraprobe_results_selector`: - Results of paraprobe-selector - Store which points are inside or on the boundary of complex spatial regions-of-interest. - - :ref:`NXapm_paraprobe_results_surfacer`: - Results of paraprobe-surfacer - Store triangulated surface meshes of models for the edge of a dataset. - - :ref:`NXapm_paraprobe_results_distancer`: - Results of paraprobe-distancer - Store analytical distances between ions to a set of triangles. - - :ref:`NXapm_paraprobe_results_tessellator`: - Results of paraprobe-tessellator - Store volume of all Voronoi cells about each ion in the dataset. - - :ref:`NXapm_paraprobe_results_nanochem`: - Results of paraprobe-nanochem - Store all results of delocalization, isosurface, and interface detection algorithms, - store all extracted triangulated surface meshes of found microstructural features, - store composition profiles and corresponding geometric primitives (ROIs). - - :ref:`NXapm_paraprobe_results_intersector`: - Results of paraprobe-intersector - Store graph of microstructural features and relations/link identified between them. - - :ref:`NXapm_paraprobe_results_spatstat`: - Results of paraprobe-spatstat - Store spatial correlation functions. - - :ref:`NXapm_paraprobe_results_clusterer`: - Results of paraprobe-clusterer - Store results of cluster analyses. - -.. _ApmParaprobeNewBC1: - -Base Classes -############ - -We envision that the above-mentioned definitions can be useful not only to take -inspiration for other software tools in the field of atom probe but also to support -a discussion towards a stronger standardization of the vocabulary used. -Therefore, we are happy for your comments and suggestions on this and the related -pages via the hypothesis web annotation service or as your issues posted on GitHub. - -We are convinced that the majority of data analyses in atom probe use -an in fact common set of operations and conditions on the input data -even though this might not be immediately evident. In particular this is not -the case for some community built tools with a very specific scope where oftentimes -the algorithms are hardcoded for specific material systems. A typical example is a -reseacher who implements a ranging tool and uses that all the examples are on a -specific material. We are convinced it is better to follow a much more generalized approach. - -In this spirit, we propose the following base classes and the above application -definitions as examples how very flexible constraints can be implemented which -restrict which ions in the dataset should be processed or not. We see that these -suggestions complement the proposal on computational geometry base classes: - - :ref:`NXapm_input_reconstruction`: - A description from which file the reconstructed ion positions are imported. - - :ref:`NXapm_input_ranging`: - A description from which file the ranging definitions are imported. - The design of the ranging definitions is, thanks to :ref:`NXion` so - general that all possible nuclids can be considered, be they observationally stable, - be they radioactive or transuranium nuclids. + IntroductionNorth + IntroductionApmTools -A detailed inspection of spatial and other type of filters used in atom probe microscopy -data analysis revealed that it is better to define atom probe agnostic, i.e. more -general filters: +.. _IntroductionNorth: - :ref:`NXspatial_filter`: - A proposal how a point cloud can be spatial filtered in a very specific, - flexible, yet general manner. This base class takes advantage of - :ref:`NXcg_ellipsoid_set`, :ref:`NXcg_cylinder_set`, and :ref:`NXcg_hexahedron_set` - to cater for all of the most commonly used geometric primitives in - atom probe. +Introduction to NORTH +##################### +The NOMAD OASIS Remote Tools Hub (NORTH), is a `NOMAD OASIS `_ service which provides access to containerized applications. +These containers contain pre-configured scientific software of different academic communities and offer access to the data inside the NOMAD OASIS research data management system. +This page delivers status reports of ongoing work specific to NeXus and how NeXus is being used by tools within specific containers offered by NORTH. - :ref:`NXsubsampling_filter`: - A proposal for a filter that can also be used for specifying how entries - like ions can be filtered via sub-sampling. +.. _IntroductionApmTools: - :ref:`NXmatch_filter`: - A proposal for a filter that can also be used for specifying how entries - like ions can be filtered based on their type (ion species) - or hit multiplicity. +apmtools container +################## -In summary, we report with this proposal our experience made in an experimental -project that is about using NeXus for standardizing a set of non-trivial scientific software tools. -During the implementation we learned that for handling computational geometry -and microstructure-related terms many subtilities have to be considered which -makes a controlled vocabulary valuable not only to avoid a reimplementing of the wheel. +One containerized application in NORTH and its apmtools container, is the paraprobe-toolbox. This software is developed by `M. Kühbach et al. `_. +The software provides an implementation which exemplifies how NeXus/HDF5 and community tools for atom probe can be used to document provenance and steps of post-processing +for many steps relevant within the field of atom probe tomography and related field-ion microscopy: Inspect :ref:`Apm-Structure` for a status report and details. diff --git a/manual/source/stm-structure.rst b/manual/source/stm-structure.rst index 944c262033..253b6f3e8f 100644 --- a/manual/source/stm-structure.rst +++ b/manual/source/stm-structure.rst @@ -1,4 +1,4 @@ -.. _Stm-Structure: +.. _Stm-Structure-Fairmat: ============================= Scanning Tunneling Microscopy @@ -14,19 +14,18 @@ Scanning Tunneling Microscopy .. _IntroductionStm: Introduction -############## -TBD +############ +Scientists of the scanning tunneling microscopy community and FAIRmat have worked together to create an application definition and related base classes for +documenting scanning tunneling spectroscopy. This is one community under the large umbrella of scanning (probe) microscopy methods. A status report of these efforts will be reported here. .. _StmAppDef: -Application Definitions -####################### -TBD - +.. Application Definitions +.. ####################### .. _StmNewBC: -Base Classes -############ -TBD +.. Base Classes +.. ############ + diff --git a/manual/source/transport-structure.rst b/manual/source/transport-structure.rst index 304a4f0e29..d75649a1fd 100644 --- a/manual/source/transport-structure.rst +++ b/manual/source/transport-structure.rst @@ -1,26 +1,14 @@ -.. _Transport-Structure1: +.. _Transport-Structure-Fairmat: =================== Transport Phenomena =================== -.. index:: - IntroductionTransport1 - TransportAppDef1 +Work of scientists within FAIRmat how to handshake between instrument control software like EPICS and CAMELS using NeXus resulted in an application definition for exemplar temperature dependent IV curve measurements. +IV curve measurements are one example of a large group of so-called transport measurements. The key idea behind these is to monitor one or more observables under controlled environmental conditions and eventual stimuli applied on a sample. - -.. _IntroductionTransport1: - -Introduction -############## - - -.. _TransportAppDef1: - -Application Definitions -####################### - -Work on handshaking between EPICS-controlled experiments and NeXus resulted in one application definition for temperature dependent IV curve measurements. +Many techniques especially used within materials engineering fall into this category and thus could make use of specializations or extensions of NXiv_temp. +Examples include hardness measurements, nanoindentation, resistance, electro-chemical probing, or diffusion. :ref:`NXiv_temp`: Application definition for temperature dependent IV curve measurements. From d60d818e4bd767a93dc8ddb84902a373c7378536 Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Mon, 24 Jul 2023 13:47:00 +0200 Subject: [PATCH 0068/1012] Fix conflict in dependent module sphinx_comments --- pyproject.toml | 1 + requirements.txt | 1 + 2 files changed, 2 insertions(+) diff --git a/pyproject.toml b/pyproject.toml index f4377ff3f4..70bad9e3a1 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -22,6 +22,7 @@ dependencies = [ "sphinx>=5", "sphinx-tabs", "sphinx-toolbox", + "sphinx_comments", "pytest", "black>=22.3", "flake8>=4", diff --git a/requirements.txt b/requirements.txt index 91c5ae31a1..3303e068ca 100644 --- a/requirements.txt +++ b/requirements.txt @@ -7,6 +7,7 @@ click sphinx>=5 sphinx-tabs sphinx-toolbox +sphinx_comments # Testing pytest From 1d8af8f87149cb6aada7182212bb6edc9aae61e1 Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Mon, 24 Jul 2023 14:37:30 +0200 Subject: [PATCH 0069/1012] Fixed bugs related to naming conventions of makefile recipes because of which the pdf did not compile properly --- .github/workflows/ci.yaml | 2 ++ Makefile | 4 ++-- manual/source/conf.py | 3 ++- 3 files changed, 6 insertions(+), 3 deletions(-) diff --git a/.github/workflows/ci.yaml b/.github/workflows/ci.yaml index b174615f3a..42740b7301 100755 --- a/.github/workflows/ci.yaml +++ b/.github/workflows/ci.yaml @@ -3,9 +3,11 @@ name: CI on: push: branches: + - main - fairmat # push commit to the fairmat branch pull_request: branches: + - main - fairmat # pull request to the fairmat branch workflow_dispatch: # allow manual triggering inputs: diff --git a/Makefile b/Makefile index eff518f189..f50c7b7514 100644 --- a/Makefile +++ b/Makefile @@ -60,7 +60,7 @@ prepare :: pdf :: $(SPHINX) -M latexpdf $(BUILD_DIR)/manual/source/ $(BUILD_DIR)/manual/build - cp $(BUILD_DIR)/manual/build/latex/nexus.pdf $(BUILD_DIR)/manual/source/_static/NeXusManual.pdf + cp $(BUILD_DIR)/manual/build/latex/nexus-fairmat.pdf $(BUILD_DIR)/manual/source/_static/NeXusManual.pdf html :: $(SPHINX) -b html -W $(BUILD_DIR)/manual/source/ $(BUILD_DIR)/manual/build/html @@ -85,7 +85,7 @@ all :: @echo "HTML built: `ls -lAFgh $(BUILD_DIR)/impatient-guide/build/html/index.html`" @echo "PDF built: `ls -lAFgh $(BUILD_DIR)/impatient-guide/build/latex/NXImpatient.pdf`" @echo "HTML built: `ls -lAFgh $(BUILD_DIR)/manual/build/html/index.html`" - @echo "PDF built: `ls -lAFgh $(BUILD_DIR)/manual/build/latex/nexus.pdf`" + @echo "PDF built: `ls -lAFgh $(BUILD_DIR)/manual/build/latex/nexus-fairmat.pdf`" NXDLS := $(foreach dir,$(NXDL_DIRS),$(wildcard $(dir)/*.nxdl.xml)) nyaml : $(DIRS) $(NXDLS) diff --git a/manual/source/conf.py b/manual/source/conf.py index 45235e151a..0e3cf29dcd 100755 --- a/manual/source/conf.py +++ b/manual/source/conf.py @@ -153,9 +153,10 @@ def setup(app): # -- Options for Latex output ------------------------------------------------- latex_elements = { - 'maxlistdepth':7, # some application definitions are deeply nested + 'maxlistdepth': 25, # some application definitions are deeply nested 'preamble': r''' \usepackage{amsbsy} + \listfiles \DeclareUnicodeCharacter{1F517}{X} \DeclareUnicodeCharacter{2906}{<=}''' } From 60779868bffbb6c40e0d2e470de9d3905322a38c Mon Sep 17 00:00:00 2001 From: sanbrock <45483558+sanbrock@users.noreply.github.com> Date: Wed, 15 Feb 2023 15:18:45 +0100 Subject: [PATCH 0070/1012] Create NXiv_sweep2.yaml --- .../nyaml/NXiv_sweep2.yaml | 46 +++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 contributed_definitions/nyaml/NXiv_sweep2.yaml diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml new file mode 100644 index 0000000000..3c8020701e --- /dev/null +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -0,0 +1,46 @@ +doc: | + Application definition for temperature-dependent IV curve measurements. + + In this application definition, times should be specified always together + with an UTC offset. + + This is the application definition describing temperature dependent IV curve + measurements. For this a temperature is set. After reaching the temperature, + a voltage sweep is performed. For each voltage a current is measured. + Then, the next desired temperature is set and an IV measurement is performed. +symbols: + n_different_temperatures: "Number of different temperature setpoints used in the experiment." + n_different_voltages: "Number of different voltage setpoints used in the experiment." +category: application +NXiv_temp(NXsensor_scan): + (NXentry): + definition(NX_CHAR): + enumeration: [NXiv_temp] + (NXinstrument): + (NXenvironment): + doc: | + Describes an environment setup for a temperature-dependent IV measurement experiment. + + The temperature and voltage must be present as independently scanned controllers and + the current sensor must also be present with its readings. + voltage_controller(NXsensor): + temperature_controller(NXsensor): + current_sensor(NXsensor): + (NXdata): + doc: | + This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. + There should also be two more fields called temperature and voltage containing the setpoint values. + There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension + equal to the number of voltage setpoints. + temperature(NX_NUMBER): + voltage(NX_NUMBER): + current(NX_NUMBER): + dimensions: + rank: 2 + dim: [[1, n_different_temperatures], [2, n_different_voltages]] + + + + + + From f4fea529e927d8412fac090508f1c5dfacb1f0d5 Mon Sep 17 00:00:00 2001 From: sanbrock <45483558+sanbrock@users.noreply.github.com> Date: Tue, 21 Feb 2023 12:35:01 +0100 Subject: [PATCH 0071/1012] Update NXiv_sweep2.yaml --- .../nyaml/NXiv_sweep2.yaml | 229 ++++++++++++++++++ 1 file changed, 229 insertions(+) diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index 3c8020701e..91262022ea 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -43,4 +43,233 @@ NXiv_temp(NXsensor_scan): + +ENTRY + PROCESS + USER + INSTRUMENT + ENVIRONMENT + SENSOR + value (settings or readngs) + value_timestamp + run_control + calibration_time + PID + DATA (specific plot) + + +STS_ENTRY + (file)type [background, reference, sample] + finename -> description (e.g. 221122_Au_5K00014) + series name -> description? Scan>series name 221122_Au_5K + session path (ELN?!)-> NanonisMain>Session Path C:\Users\SPM-PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis-Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711 + description: Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, locked Au(111), 50pA, 100 mV set point, 1mV DCA, 973Hz,138 1st H, -84 2nd H + INSTRUMENT + Hardware: Nanonis BP5e + Software: SoftwareMain>SW Version Generic 5e -- SoftwareMain>UI Release 10771 -- SoftwareMain>RT Release 10771 + Current amplifier + Current amplifier> hardware: CreaTec GmbH + Current amplifier> factor (V/V): 1E-10 + Current amplifier> Capacitive cross-talk compensation: Yes/No + Lock in (optional) + Lock-in Amplifier>Yes/No # If a lock-in amplifier employed to filter or obtain the electronic derivatives dI/dV of the signal + Lock-in Amplifier>Hardware: Nanonis + if Lock-in -- Bias Divider 1/10 or 1/100 # if the modulation + + Bias Spectroscopy>Channels Current (A);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A) # Select the channels to record. + Bias Spectroscopy>Reset Bias TRUE # When selected, the Bias voltage returns to the initial value (before starting the sweep) at the end of the spectroscopy measurement (default). When not selected, Bias remains at the last value of the sweep. This is useful e.g. when combining several sweep segments. Example for an automated measurement (using Programming Interface): switch off Z-Controller, start spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, switch on Z-Controller. + Bias Spectroscopy>Record final Z FALSE # Select whether to record the Z position during Z averaging time at the end of the sweep (after Z control time) and store the average value in the header of the file when saving. Using this option increases the sweep time by Z averaging time. + Bias Spectroscopy>Lock-In run FALSE # Select whether to set the Lock-In to run during the measurement. When using this feature, make sure the Lock-In is configured correctly and settling times are set to twice the Lock-In period at least. This option is ignored when Lock-In is already running. This option is disabled if the Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline segment editor is set. + Lock-in>Lock-in status ON # ON/OFF of Lock-in amplifier + Lock-in>Modulated signal Bias (V) # This is the signal on which the modulation (sine) will be added. + Lock-in>Frequency (Hz) 973E+0 # Sets the frequency of the sine modulation added to the signal to modulate. The frequency range is from 10 mHz to 40 kHz (corresponding to the SC5 output filter cut-off). When working with harmonics, make sure the harmonic frequencies don’t exceed ~100 kHz (SC5 input filter cut-off). Remember the SC5 hardware filters will affect the amplitude when getting close to their cut-off frequencies. + Lock-in>Amplitude 2E-3 + Lock-in>Demodulated signal Current (A) + Lock-in>Harmonic D1 1 + Lock-in>Harmonic D2 2 + Lock-in>Reference phase D1 (deg) 137.597E+0 + Lock-in>Reference phase D2 (deg) -83.6562E+0 + + Bias: Tip bias/Sample bias # If the spectroscopy V bias is applied to the + Modulated signal Bias (V) 1E-3 # Applied modulation to the bias voltage. + ModulationBias> Tip bias/Sample bias + STM head + temp Temperature 1 (K) 4.92997E+0 # Temperature of STM head. + Cryo + bottom_temp Temperature 2 (K) - # Temperature of bottom of LHe helium cryostat. + shield_temp Temperature 3 (K) - # Temperature of LN2 nitrogen shield. + Cabling & Config + Outputs>Output 0 Mode User Output + Outputs>Output 1 Mode User Output + Outputs>Output 2 Mode User Output + Outputs>Output 3 Mode User Output + Outputs>Output 4 Mode User Output + Outputs>Output 5 Mode User Output + Outputs>Output 6 Mode User Output + Outputs>Output 7 Mode User Output + Outputs>Output 0 Value 0E+0 + Outputs>Output 1 Value 0E+0 + Outputs>Output 2 Value 0E+0 + Outputs>Output 3 Value 2.5539E+0 + Outputs>Output 4 Value 0E+0 + Outputs>Output 5 Value 0E+0 + Outputs>Output 6 Value 0E+0 + Outputs>Output 7 Value 0E+0 + Outputs>Output 0 Name Input 24 (V) + Outputs>Output 1 Name Bias (V) + Outputs>Output 2 Name Output 2 (V) + Outputs>Output 3 Name T1 Supply voltage (V) + Outputs>Output 4 Name Output 4 (V) + Outputs>Output 5 Name X (m) + Outputs>Output 6 Name Y (m) + Outputs>Output 7 Name Z (m) + Outputs>Output 0 Slew Rate Inf + Outputs>Output 1 Slew Rate Inf + Outputs>Output 2 Slew Rate Inf + Outputs>Output 3 Slew Rate Inf + Outputs>Output 4 Slew Rate Inf + Outputs>Output 5 Slew Rate Inf + Outputs>Output 6 Slew Rate Inf + Outputs>Output 7 Slew Rate Inf + Piezo Config + Piezo Configuration>Active Calib. LHe + Piezo Configuration>Calib. X (m/V) 3.8E-9 + Piezo Configuration>Calib. Y (m/V) 3.8E-9 + Piezo Configuration>Calib. Z (m/V) 900E-12 + Piezo Configuration>HV Gain X 14.5 + Piezo Configuration>HV Gain Y 14.5 + Piezo Configuration>HV Gain Z 14.5 + Piezo Configuration>Tilt X (deg) 0.318343 + Piezo Configuration>Tilt Y (deg) 1.584 + Piezo Configuration>Curvature radius X (m) Inf + Piezo Configuration>Curvature radius Y (m) Inf + Piezo Configuration>2nd order corr X (V/m^2) 0E+0 + Piezo Configuration>2nd order corr Y (V/m^2) 0E+0 + Piezo Configuration>Drift X (m/s) 0E+0 + Piezo Configuration>Drift Y (m/s) 0E+0 + Piezo Configuration>Drift Z (m/s) 0E+0 + Piezo Configuration>Drift correction status (on/off) FALSE + + MEASUREMENT + Position + X (m) -890.53E-12 + Y (m) 29.6968E-9 + Z (m) 130.5E-9 + Z-Controller>Z (m) 130.5E-9 + SCAN + Integration time (s) 150E-6 # Time during which the spectroscopy data are acquired and averaged. + Bias Spectroscopy>Number of sweeps 100 # Number of sweeps to measure and average. + Bias Spectroscopy>Sweep Start (V) -300E-3 # The first bias values of the sweep. + Bias Spectroscopy>Sweep End (V) 300E-3 # The last bias values of the sweep. + Bias Spectroscopy>Num Pixel 4096 # Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. + Bias Spectroscopy>Z Avg time (s) 100E-3 # Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). + SoftwareMain>RT Frequency (Hz) 20E+3 # The bandwitdh of the Hardware and/or Software + SoftwareMain>Signals Oversampling 10 # (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. + SoftwareMain>Acquisition Period (s) 20E-3 # Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. + SoftwareMain>Animations Period (s) 20E-3 # Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. + SoftwareMain>Indicators Period (s) 300E-3 # Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. + SoftwareMain>Measurements Period (s) 500E-3 # The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. + Z-Controller + Scan>Scanfield 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0 + Scan>channels Current (A);Bias (V);Z (m);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A) + Scan>pixels/line 512 + Scan>lines 512 + Scan>speed forw. (m/s) 11.7187E-9 + Scan>speed backw. (m/s) 11.7187E-9 + + SW Filter (PROCESS) + type Butterworth + Order 1 + Cutoff frq 0.01 + HW Filter (INSTRUMENT) + Lock-in>LP Filter Cutoff D1 (Hz) 621.699E+0 # Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) value) for D1. The filter is applied to the demodulated signals (X,Y). + Lock-in>LP Filter Cutoff D2 (Hz) 621.699E+0 # Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) value) for D2. The filter is applied to the demodulated signals (X,Y). + Lock-in>LP Filter Order D1 8 # Order and cut-off frequency of the low-pass filter applied on the demodulated signals (X,Y). Reducing the bandwidth or increasing the order reduces noise on the demodulated signals, but will require longer settling and measurement times. + Lock-in>LP Filter Order D2 8 # See below. + Lock-in>HP Filter Cutoff D1 (Hz) # Sets the cut-off frequency of the high-pass filter (affects the displayed TC (s) value) for D1. The filter is applied to the demodulated signals (X,Y). + Lock-in>HP Filter Cutoff D2 (Hz) # See below + Lock-in>HP Filter Order D1 1 # Order and cut-off frequency of the high-pass filter applied on the demodulation signal of D!. This is used mainly to suppress a DC component of the demodulation signal, which would lead to a component at modulation frequency in the demodulated signals. + Lock-in>HP Filter Order D2 1 # See below + Lock-in>Sync Filter D1 ON # Switch the Sync filter on the demodulated signals (X,Y) on or off for D1. The sync filter operates after the low-pass filter and averages the demodulated signals over one period of the modulation frequency. + Lock-in>Sync Filter D2 ON # See below. + RESOLUTION (calculation input) + Temperature 1>link to INSTR/STM/head Temperature 1 (K) 4.92997E+0 # Temperature of STM head. + Temperature 2>link to Temperature 2 (K) - # Temperature of bottom of LHe helium cryostat. + Temperature 3>link to Temperature 3 (K) - # Temperature of LN2 nitrogen shield. + Lock-in>link to Modulated signal Bias (V) 1E-3 # Applied modulation to the bias voltage. + link to Integration time (s) 150E-6 # Time during which the spectroscopy data are acquired and averaged. + link to Bias Spectroscopy>Number of sweeps 100 # Number of sweeps to measure and average. + link to Bias Spectroscopy>Sweep Start (V) -300E-3 # The first bias values of the sweep. + link to Bias Spectroscopy>Sweep End (V) 300E-3 # The last bias values of the sweep. + link to Bias Spectroscopy>Num Pixel 4096 # Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. + link to Bias Spectroscopy>Z Avg time (s) 100E-3 # Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). + link to SoftwareMain>RT Frequency (Hz) 20E+3 # The bandwitdh of the Hardware and/or Software + link to SoftwareMain>Signals Oversampling 10 # (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. + link to SoftwareMain>Acquisition Period (s) 20E-3 # Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. + link to SoftwareMain>Animations Period (s) 20E-3 # Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. + link to SoftwareMain>Indicators Period (s) 300E-3 # Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. + link to SoftwareMain>Measurements Period (s) 500E-3 # The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. + REPRODUCIBILITY + link to + Bias>Bias (V) 100E-3 # Applied bias voltage. + Current>Current (A) -5.3429E-15 # The tunneling current is displayed here. + Bias>Calibration (V/V) 1E+0 # Calibration of the Bias output. If you have a Range switch the calibration is stored per range setting. + Bias>Offset (V) 0E+0 # Allows compensating for an offset in Bias. + Current>Calibration (A/V) 100E-12 # The signals voltages are converted to real world physical values according to the calibration & offset parameters: Physical signal = (Voltage * calibration) + offset. + Current>Offset (A) 16.2897E-15 # The same as "Current>Calibration (A/V)" tag + Current>Gain Not switchable # None + Z offset (m) 0E+0 # Offset added to the initial averaged position Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an alternate Z-controller setpoint is enabled. + Settling time (s) 2.1E-3 # Time to wait after changing the bias to the next level and before starting to acquire data. Adjust this parameter to avoid transient effect induced by the bias change. Integration time: time during which the data are acquired and averaged. + Z-Ctrl hold TRUE # When selected, the Z-Controller is set to hold during the pulse. This means that the controller doesn't control the Z position during the pulse. + Final Z (m) N/A + Start time 23.11.2022 18:55:16 # Timestamp of the moment when the acquisition starts by pressing the Start button. + Bias Spectroscopy>Z offset (m) 0E+0 # Offset added to the initial averaged position Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an alternate Z-controller setpoint is enabled. + Bias Spectroscopy>1st Settling time (s) 2.1E-3 # See the "Settling time (s)" below. + Bias Spectroscopy>Settling time (s) 2.1E-3 # See the "Settling time (s)" below. + Bias Spectroscopy>Integration time (s) 150E-6 # Time during which the data are acquired and averaged. + Bias Spectroscopy>End Settling time (s) 4E-3 # Time to wait after the sweep has finished and the bias is ramped to the initial value. + Bias Spectroscopy>Z control time (s) 200E-3 # Time during which the Z-Controller is enabled once a sweep has finished. When averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled for this duration between each sweep. After the last sweep, it will wait the specified time before continuing a running scan. This ensures each sweep reliably starts from the same position. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. + Bias Spectroscopy>Max Slew rate (V/s) 1E+0 # Maximum rate at which the bias changes (before, during and after sweeping). + Bias Spectroscopy>backward sweep TRUE # Select whether to measure the backward (return) sweep or the forward only. + Bias Spectroscopy>Z-controller hold TRUE # Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. + Z-Controller>Controller name log Current # Controller name. This name which will be displayed at places where you can select a controller. + Z-Controller>Controller status OFF # ON/OFF + Z-Controller>Setpoint 50E-12 # Set Point is the desired value of the control signal. It can be set by editing the number or using the slider bar. Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. + Z-Controller>Setpoint unit A # Angstrom + Z-Controller>P gain 6E-12 # The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. + Z-Controller>I gain 39.8241E-9 # See "Z-Controller>P gain" below. + Z-Controller>Time const (s) 150.662E-6 # See "Z-Controller>P gain" below. + Z-Controller>TipLift (m) 0E+0 # Lifts the tip by the specified amount when then controller is switched off. This can be a positive or a negative number, i.e. the tip can also be moved towards the sample. Be careful with sign and value when using this feature. + Z-Controller>Switch off delay (s) 0E+0 # Use this parameter for a reproducible position when switching off the Z-controller. When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. + + DATA + Bias calc (V) + Current (A) + LI Demod 2 X (A) + LI Demod 2 Y (A) + LI Demod 1 X (A) + LI Demod 1 Y (A) + Current [bwd] (A) + LI Demod 2 X [bwd] (A) + LI Demod 2 Y [bwd] (A) + LI Demod 1 X [bwd] (A) + LI Demod 1 Y [bwd] (A) + Current (A) [filt] + LI Demod 2 X (A) [filt] + LI Demod 2 Y (A) [filt] + LI Demod 1 X (A) [filt] + LI Demod 1 Y (A) [filt] + Current (A) [bwd] [filt] + LI Demod 2 X (A) [bwd] [filt] + LI Demod 2 Y (A) [bwd] [filt] + LI Demod 1 X (A) [bwd] [filt] + LI Demod 1 Y (A) [bwd] [filt] + + + + + + + + From 3fc434f6433487e6050bfac592a82e1a6b9fe7ba Mon Sep 17 00:00:00 2001 From: sanbrock <45483558+sanbrock@users.noreply.github.com> Date: Wed, 8 Mar 2023 16:07:25 +0100 Subject: [PATCH 0072/1012] Update NXiv_sweep2.yaml new base classes: NXamplifier, and NXlockin --- .../nyaml/NXiv_sweep2.yaml | 42 ++++++++++++++++--- 1 file changed, 36 insertions(+), 6 deletions(-) diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index 91262022ea..6f6bcc4831 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -57,9 +57,38 @@ ENTRY PID DATA (specific plot) - - -STS_ENTRY + + +Base Classes: +============= + +NXamplifier: + hw (IC, device) (NXmanufacturer?) + NumOfChannels + ActiveChannels (array of chIDs) + openloop_amplification (array for active channels) + amplification (array for active channels) + s/n (array for active channels) + cross-talk factor (if active >1) + cross-talk compensation (bool) + +NXlockin: + hw (NXmanufacturer?) + (NXamplifier) (input and output amplifiers) + frequency + NumOfHarmonics + LowPass cut-off frq (low pass filter) (foreach Harmonics) + HiPass cut-off frq (low pass filter) (foreach Harmonics) + Synch filter (foreach Harmonics) + refPhase (foreach Harmonics) + + + +Application Definition: +======================= + +NXsts(NXsensor_scan) +ENTRY (file)type [background, reference, sample] finename -> description (e.g. 221122_Au_5K00014) series name -> description? Scan>series name 221122_Au_5K @@ -68,11 +97,13 @@ STS_ENTRY INSTRUMENT Hardware: Nanonis BP5e Software: SoftwareMain>SW Version Generic 5e -- SoftwareMain>UI Release 10771 -- SoftwareMain>RT Release 10771 - Current amplifier + Current amplifier (NXamplifier) Current amplifier> hardware: CreaTec GmbH Current amplifier> factor (V/V): 1E-10 Current amplifier> Capacitive cross-talk compensation: Yes/No - Lock in (optional) + + Lock-in>Lock-in status ON # ON/OFF of Lock-in amplifier + Lock in (optional) (NXlockin) Lock-in Amplifier>Yes/No # If a lock-in amplifier employed to filter or obtain the electronic derivatives dI/dV of the signal Lock-in Amplifier>Hardware: Nanonis if Lock-in -- Bias Divider 1/10 or 1/100 # if the modulation @@ -81,7 +112,6 @@ STS_ENTRY Bias Spectroscopy>Reset Bias TRUE # When selected, the Bias voltage returns to the initial value (before starting the sweep) at the end of the spectroscopy measurement (default). When not selected, Bias remains at the last value of the sweep. This is useful e.g. when combining several sweep segments. Example for an automated measurement (using Programming Interface): switch off Z-Controller, start spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, switch on Z-Controller. Bias Spectroscopy>Record final Z FALSE # Select whether to record the Z position during Z averaging time at the end of the sweep (after Z control time) and store the average value in the header of the file when saving. Using this option increases the sweep time by Z averaging time. Bias Spectroscopy>Lock-In run FALSE # Select whether to set the Lock-In to run during the measurement. When using this feature, make sure the Lock-In is configured correctly and settling times are set to twice the Lock-In period at least. This option is ignored when Lock-In is already running. This option is disabled if the Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline segment editor is set. - Lock-in>Lock-in status ON # ON/OFF of Lock-in amplifier Lock-in>Modulated signal Bias (V) # This is the signal on which the modulation (sine) will be added. Lock-in>Frequency (Hz) 973E+0 # Sets the frequency of the sine modulation added to the signal to modulate. The frequency range is from 10 mHz to 40 kHz (corresponding to the SC5 output filter cut-off). When working with harmonics, make sure the harmonic frequencies don’t exceed ~100 kHz (SC5 input filter cut-off). Remember the SC5 hardware filters will affect the amplitude when getting close to their cut-off frequencies. Lock-in>Amplitude 2E-3 From 04bccd90868a92fe1b286ceb053dba7ebda82d5f Mon Sep 17 00:00:00 2001 From: Yichen Date: Wed, 15 Mar 2023 14:32:15 +0100 Subject: [PATCH 0073/1012] Update NXiv_sweep2.yaml --- .../nyaml/NXiv_sweep2.yaml | 62 ++++++++++--------- 1 file changed, 32 insertions(+), 30 deletions(-) diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index 6f6bcc4831..4eda15df19 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -71,6 +71,8 @@ NXamplifier: s/n (array for active channels) cross-talk factor (if active >1) cross-talk compensation (bool) + preamplifiers + circuits NXlockin: hw (NXmanufacturer?) @@ -114,12 +116,12 @@ ENTRY Bias Spectroscopy>Lock-In run FALSE # Select whether to set the Lock-In to run during the measurement. When using this feature, make sure the Lock-In is configured correctly and settling times are set to twice the Lock-In period at least. This option is ignored when Lock-In is already running. This option is disabled if the Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline segment editor is set. Lock-in>Modulated signal Bias (V) # This is the signal on which the modulation (sine) will be added. Lock-in>Frequency (Hz) 973E+0 # Sets the frequency of the sine modulation added to the signal to modulate. The frequency range is from 10 mHz to 40 kHz (corresponding to the SC5 output filter cut-off). When working with harmonics, make sure the harmonic frequencies don’t exceed ~100 kHz (SC5 input filter cut-off). Remember the SC5 hardware filters will affect the amplitude when getting close to their cut-off frequencies. - Lock-in>Amplitude 2E-3 - Lock-in>Demodulated signal Current (A) - Lock-in>Harmonic D1 1 - Lock-in>Harmonic D2 2 - Lock-in>Reference phase D1 (deg) 137.597E+0 - Lock-in>Reference phase D2 (deg) -83.6562E+0 + Lock-in>Amplitude 2E-3 # Sets the amplitude (in physical units of the modulated signal) of the sine modulation. + Lock-in>Demodulated signal Current (A) # This is the signal which will be demodulated, in order to determine the amplitude and phase at the frequency set in the Frequency field (“4”) or harmonics. + Lock-in>Harmonic D1 1 # Order of the harmonic oscillation to detect on the demodulated signal (with respect to the modulation frequency). If you work with higher harmonics make sure the frequency does not exceed the analog signal bandwidth (100 kHz). + Lock-in>Harmonic D2 2 # See below. + Lock-in>Reference phase D1 (deg) 137.597E+0 # Reference phase for the sine on the demodulated signal with respect to the modulation signal. The determined phase (phi) is displayed with respect to the reference phase. + Lock-in>Reference phase D2 (deg) -83.6562E+0 # See below. Bias: Tip bias/Sample bias # If the spectroscopy V bias is applied to the Modulated signal Bias (V) 1E-3 # Applied modulation to the bias voltage. @@ -163,23 +165,23 @@ ENTRY Outputs>Output 6 Slew Rate Inf Outputs>Output 7 Slew Rate Inf Piezo Config - Piezo Configuration>Active Calib. LHe - Piezo Configuration>Calib. X (m/V) 3.8E-9 - Piezo Configuration>Calib. Y (m/V) 3.8E-9 - Piezo Configuration>Calib. Z (m/V) 900E-12 - Piezo Configuration>HV Gain X 14.5 - Piezo Configuration>HV Gain Y 14.5 - Piezo Configuration>HV Gain Z 14.5 - Piezo Configuration>Tilt X (deg) 0.318343 - Piezo Configuration>Tilt Y (deg) 1.584 - Piezo Configuration>Curvature radius X (m) Inf - Piezo Configuration>Curvature radius Y (m) Inf - Piezo Configuration>2nd order corr X (V/m^2) 0E+0 - Piezo Configuration>2nd order corr Y (V/m^2) 0E+0 - Piezo Configuration>Drift X (m/s) 0E+0 - Piezo Configuration>Drift Y (m/s) 0E+0 - Piezo Configuration>Drift Z (m/s) 0E+0 - Piezo Configuration>Drift correction status (on/off) FALSE + Piezo Configuration>Active Calib. LHe # Tne name of caliberation type. + Piezo Configuration>Calib. X (m/V) 3.8E-9 # There are 3 controls available: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. + Piezo Configuration>Calib. Y (m/V) 3.8E-9 # See below. + Piezo Configuration>Calib. Z (m/V) 900E-12 # See below. + Piezo Configuration>HV Gain X 14.5 # See below. + Piezo Configuration>HV Gain Y 14.5 # See below. + Piezo Configuration>HV Gain Z 14.5 # See below. + Piezo Configuration>Tilt X (deg) 0.318343 # This tab is used to set the sample tilt (in degrees, first order correction). + Piezo Configuration>Tilt Y (deg) 1.584 # See below. + Piezo Configuration>Curvature radius X (m) Inf # This tab is used to set a curvature (can be set approximately to the length of the piezotube). + Piezo Configuration>Curvature radius Y (m) Inf # See below. + Piezo Configuration>2nd order corr X (V/m^2) 0E+0 # If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. + Piezo Configuration>2nd order corr Y (V/m^2) 0E+0 # See below. + Piezo Configuration>Drift X (m/s) 0E+0 # Define the drift speed for all three axes. When the compensation is on, the piezos will start to move at that speed. + Piezo Configuration>Drift Y (m/s) 0E+0 # See below. + Piezo Configuration>Drift Z (m/s) 0E+0 # See below. + Piezo Configuration>Drift correction status (on/off) FALSE # Use the button to turn on/off the drift compensation. MEASUREMENT Position @@ -200,13 +202,13 @@ ENTRY SoftwareMain>Animations Period (s) 20E-3 # Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. SoftwareMain>Indicators Period (s) 300E-3 # Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. SoftwareMain>Measurements Period (s) 500E-3 # The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. - Z-Controller - Scan>Scanfield 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0 - Scan>channels Current (A);Bias (V);Z (m);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A) - Scan>pixels/line 512 - Scan>lines 512 - Scan>speed forw. (m/s) 11.7187E-9 - Scan>speed backw. (m/s) 11.7187E-9 + Scan control + Scan>Scanfield 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0 # Configure the scan frame. + Scan>channels Current (A);Bias (V);Z (m);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A) # The scan channels are selected by users. + Scan>pixels/line 512 # Scan resolution by setting the Lines equal to Pixels. + Scan>lines 512 # Define the image resolution. + Scan>speed forw. (m/s) 11.7187E-9 # Define the scan forward speed in the forward direction. + Scan>speed backw. (m/s) 11.7187E-9 # Define the scan backward speed in the forward direction. SW Filter (PROCESS) type Butterworth From 0c5bc5cab18c1cbac8ea149ad1235444f7aae00f Mon Sep 17 00:00:00 2001 From: ca-palma <124777158+ca-palma@users.noreply.github.com> Date: Wed, 15 Mar 2023 22:52:29 +0800 Subject: [PATCH 0074/1012] Update NXiv_sweep2.yaml --- .../nyaml/NXiv_sweep2.yaml | 36 +++++++++++++++---- 1 file changed, 30 insertions(+), 6 deletions(-) diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index 4eda15df19..a0630ff85f 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -1,13 +1,21 @@ doc: | - Application definition for temperature-dependent IV curve measurements. + Application definition for temperature-dependent IV curve measurements, #CAP with a focus on bias spectroscopy in scanning tunneling microscopy. In this application definition, times should be specified always together with an UTC offset. - - This is the application definition describing temperature dependent IV curve + + This is the application definition describing temperature (T) dependent current voltage (IV) curve measurements. For this a temperature is set. After reaching the temperature, a voltage sweep is performed. For each voltage a current is measured. Then, the next desired temperature is set and an IV measurement is performed. + #CAP the X, Y, Z, position of the probes or tip can be defined. #CAP The data can be visualized in a tensor with: + I (NXsensor_C, NXsoftware_Read_offset, NXcircuit) + parameters: + V (NXsource+offset, NXsoftware_Scan_offset, NXsensor_V, NXcircuit) + T (NXsource, NXsoftware_Scan_offset, NXsensor_T) + x (NXsoftware_Scan_offset) + y (NXsoftware_Scan_offset) + z (NXsoftware_Scan_offset) symbols: n_different_temperatures: "Number of different temperature setpoints used in the experiment." n_different_voltages: "Number of different voltage setpoints used in the experiment." @@ -62,17 +70,20 @@ ENTRY Base Classes: ============= + + NXamplifier: hw (IC, device) (NXmanufacturer?) NumOfChannels ActiveChannels (array of chIDs) openloop_amplification (array for active channels) amplification (array for active channels) - s/n (array for active channels) + signal/noise (array for active channels) cross-talk factor (if active >1) cross-talk compensation (bool) - preamplifiers - circuits + bandwidth + LowPass cut-off frq (low pass filter) + HiPass cut-off frq (low pass filter) NXlockin: hw (NXmanufacturer?) @@ -84,6 +95,19 @@ NXlockin: Synch filter (foreach Harmonics) refPhase (foreach Harmonics) + +NXcircuit: + +NXsensor: +# link to second amplifer circuit with 1MOhm[NXcircuit] +# link to [NXamplifier] + +NXparameter: + +NXbias: +# link to Tunneling resistor circuit[NXcircuit] +# Hardware paramater offset + Application Definition: From e44ac186be800b6e254a598ef5d618225990efd1 Mon Sep 17 00:00:00 2001 From: sanbrock <45483558+sanbrock@users.noreply.github.com> Date: Thu, 16 Mar 2023 09:50:56 +0100 Subject: [PATCH 0075/1012] Update NXiv_sweep2.yaml --- .../nyaml/NXiv_sweep2.yaml | 26 ++++++++++++------- 1 file changed, 16 insertions(+), 10 deletions(-) diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index a0630ff85f..d722242caf 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -11,11 +11,11 @@ doc: | #CAP the X, Y, Z, position of the probes or tip can be defined. #CAP The data can be visualized in a tensor with: I (NXsensor_C, NXsoftware_Read_offset, NXcircuit) parameters: - V (NXsource+offset, NXsoftware_Scan_offset, NXsensor_V, NXcircuit) - T (NXsource, NXsoftware_Scan_offset, NXsensor_T) - x (NXsoftware_Scan_offset) - y (NXsoftware_Scan_offset) - z (NXsoftware_Scan_offset) + V has (NXsource+offset, NXsoftware_Scan_offset, NXsensor_V, NXcircuit) + T has (NXsource, NXsoftware_Scan_offset, NXsensor_T) + x has (NXsoftware_Scan_offset) + y has (NXsoftware_Scan_offset) + z has (NXsoftware_Scan_offset) symbols: n_different_temperatures: "Number of different temperature setpoints used in the experiment." n_different_voltages: "Number of different voltage setpoints used in the experiment." @@ -84,16 +84,22 @@ NXamplifier: bandwidth LowPass cut-off frq (low pass filter) HiPass cut-off frq (low pass filter) + type {"current", "voltage"} NXlockin: hw (NXmanufacturer?) (NXamplifier) (input and output amplifiers) frequency - NumOfHarmonics - LowPass cut-off frq (low pass filter) (foreach Harmonics) - HiPass cut-off frq (low pass filter) (foreach Harmonics) - Synch filter (foreach Harmonics) - refPhase (foreach Harmonics) + #output (demodulated signal) characterisation + NumOfDemodulatorChannels + LowPass cut-off frq (low pass filter) (foreach DemodulatorChannels) + HiPass cut-off frq (low pass filter) (foreach DemodulatorChannels) + Synch filter (foreach DemodulatorChannels) + refPhase (foreach DemodulatorChannels) ??? + integrationTime (for the input filter) + NumOfHarmonics + sensitivityFactor (input gain) + NXcircuit: From 38a011eb383b6dc32a807fda5d6c636b57d66105 Mon Sep 17 00:00:00 2001 From: Yichen Date: Wed, 22 Mar 2023 14:00:53 +0100 Subject: [PATCH 0076/1012] Update NXiv_sweep2.yaml --- contributed_definitions/nyaml/NXiv_sweep2.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index d722242caf..14d3e94982 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -95,7 +95,7 @@ NXlockin: LowPass cut-off frq (low pass filter) (foreach DemodulatorChannels) HiPass cut-off frq (low pass filter) (foreach DemodulatorChannels) Synch filter (foreach DemodulatorChannels) - refPhase (foreach DemodulatorChannels) ??? + refPhase (foreach DemodulatorChannels) integrationTime (for the input filter) NumOfHarmonics sensitivityFactor (input gain) From 2f692b40fbc013600fa91246dd746766bf85ea6c Mon Sep 17 00:00:00 2001 From: Yichen Date: Wed, 22 Mar 2023 15:07:49 +0100 Subject: [PATCH 0077/1012] Update NXiv_sweep2.yaml --- contributed_definitions/nyaml/NXiv_sweep2.yaml | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index 14d3e94982..b2b882c4b2 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -199,7 +199,7 @@ ENTRY Piezo Configuration>Calib. X (m/V) 3.8E-9 # There are 3 controls available: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. Piezo Configuration>Calib. Y (m/V) 3.8E-9 # See below. Piezo Configuration>Calib. Z (m/V) 900E-12 # See below. - Piezo Configuration>HV Gain X 14.5 # See below. + Piezo Configuration>HV Gain X 14.5 # For some systems HV gain readout is available, so for those systems the HV gain should be adjusted automatically when the gain is changed at the high voltage amplifier. Piezo Configuration>HV Gain Y 14.5 # See below. Piezo Configuration>HV Gain Z 14.5 # See below. Piezo Configuration>Tilt X (deg) 0.318343 # This tab is used to set the sample tilt (in degrees, first order correction). @@ -233,7 +233,7 @@ ENTRY SoftwareMain>Indicators Period (s) 300E-3 # Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. SoftwareMain>Measurements Period (s) 500E-3 # The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. Scan control - Scan>Scanfield 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0 # Configure the scan frame. + Scan>Scanfield 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0 # Configure the scan frame: x position; y position; width; height. Scan>channels Current (A);Bias (V);Z (m);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A) # The scan channels are selected by users. Scan>pixels/line 512 # Scan resolution by setting the Lines equal to Pixels. Scan>lines 512 # Define the image resolution. @@ -241,9 +241,9 @@ ENTRY Scan>speed backw. (m/s) 11.7187E-9 # Define the scan backward speed in the forward direction. SW Filter (PROCESS) - type Butterworth - Order 1 - Cutoff frq 0.01 + type Butterworth # Select a filter to smooth the displayed data. Note: When saving, if any filter selected, filtered data are saved to file along with the unfiltered data. + Order 1 # Filter order of a dynamic filter or width (in number of points) for the gaussian filter. + Cutoff frq 0.01 # Cutoff frequency for dynamic filters. HW Filter (INSTRUMENT) Lock-in>LP Filter Cutoff D1 (Hz) 621.699E+0 # Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) value) for D1. The filter is applied to the demodulated signals (X,Y). Lock-in>LP Filter Cutoff D2 (Hz) 621.699E+0 # Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) value) for D2. The filter is applied to the demodulated signals (X,Y). From a6c32aaaaeb7ff9916368a7cde9a67ecc5f3eabd Mon Sep 17 00:00:00 2001 From: sanbrock <45483558+sanbrock@users.noreply.github.com> Date: Wed, 22 Mar 2023 16:00:04 +0100 Subject: [PATCH 0078/1012] Update NXiv_sweep2.yaml --- .../nyaml/NXiv_sweep2.yaml | 64 +++++++++++-------- 1 file changed, 38 insertions(+), 26 deletions(-) diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index b2b882c4b2..8228138d1b 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -90,7 +90,7 @@ NXlockin: hw (NXmanufacturer?) (NXamplifier) (input and output amplifiers) frequency - #output (demodulated signal) characterisation + #output (demodulated signal) characterisation (foreach channel, like demodulation, a separate sensor output, e.g. X,Y) NumOfDemodulatorChannels LowPass cut-off frq (low pass filter) (foreach DemodulatorChannels) HiPass cut-off frq (low pass filter) (foreach DemodulatorChannels) @@ -214,12 +214,12 @@ ENTRY Piezo Configuration>Drift correction status (on/off) FALSE # Use the button to turn on/off the drift compensation. MEASUREMENT - Position + Position (NXtransformation) # also clarify the frame laboratory frame X (m) -890.53E-12 Y (m) 29.6968E-9 Z (m) 130.5E-9 Z-Controller>Z (m) 130.5E-9 - SCAN + SCAN # parameters for a measurement at a single location during the scan Integration time (s) 150E-6 # Time during which the spectroscopy data are acquired and averaged. Bias Spectroscopy>Number of sweeps 100 # Number of sweeps to measure and average. Bias Spectroscopy>Sweep Start (V) -300E-3 # The first bias values of the sweep. @@ -232,7 +232,8 @@ ENTRY SoftwareMain>Animations Period (s) 20E-3 # Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. SoftwareMain>Indicators Period (s) 300E-3 # Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. SoftwareMain>Measurements Period (s) 500E-3 # The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. - Scan control + Scan control # parameters how to change the location from measurement to measurement during the scan + frame(NXtransformation) # also clarify the frame for the ROI of the scan (should depend on the lab frame) Scan>Scanfield 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0 # Configure the scan frame: x position; y position; width; height. Scan>channels Current (A);Bias (V);Z (m);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A) # The scan channels are selected by users. Scan>pixels/line 512 # Scan resolution by setting the Lines equal to Pixels. @@ -244,7 +245,8 @@ ENTRY type Butterworth # Select a filter to smooth the displayed data. Note: When saving, if any filter selected, filtered data are saved to file along with the unfiltered data. Order 1 # Filter order of a dynamic filter or width (in number of points) for the gaussian filter. Cutoff frq 0.01 # Cutoff frequency for dynamic filters. - HW Filter (INSTRUMENT) + filtered_data # result of filtering if applied + HW Filter (NXlockin) # maybe the same as INSTRUMENT/lockin Lock-in>LP Filter Cutoff D1 (Hz) 621.699E+0 # Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) value) for D1. The filter is applied to the demodulated signals (X,Y). Lock-in>LP Filter Cutoff D2 (Hz) 621.699E+0 # Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) value) for D2. The filter is applied to the demodulated signals (X,Y). Lock-in>LP Filter Order D1 8 # Order and cut-off frequency of the low-pass filter applied on the demodulated signals (X,Y). Reducing the bandwidth or increasing the order reduces noise on the demodulated signals, but will require longer settling and measurement times. @@ -305,28 +307,38 @@ ENTRY Z-Controller>TipLift (m) 0E+0 # Lifts the tip by the specified amount when then controller is switched off. This can be a positive or a negative number, i.e. the tip can also be moved towards the sample. Be careful with sign and value when using this feature. Z-Controller>Switch off delay (s) 0E+0 # Use this parameter for a reproducible position when switching off the Z-controller. When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. - DATA - Bias calc (V) - Current (A) - LI Demod 2 X (A) - LI Demod 2 Y (A) - LI Demod 1 X (A) - LI Demod 1 Y (A) - Current [bwd] (A) - LI Demod 2 X [bwd] (A) - LI Demod 2 Y [bwd] (A) - LI Demod 1 X [bwd] (A) - LI Demod 1 Y [bwd] (A) - Current (A) [filt] - LI Demod 2 X (A) [filt] - LI Demod 2 Y (A) [filt] - LI Demod 1 X (A) [filt] - LI Demod 1 Y (A) [filt] + DATA # multi dimensional array: multi I-V array per scan point; + Bias calc (V) #scanning parameter + Current (A) # current during forward direction scanning of bias - original NXsensor + LI Demod 2 X (A) lockin (NXsensor+lockin) + LI Demod 2 Y (A) lockin + LI Demod 1 X (A) lockin + LI Demod 1 Y (A) lockin + Current [bwd] (A) #bwd - backward (the positive direction shall be clarified by the reference bias scanning frame) + LI Demod 2 X [bwd] (A) lockin + LI Demod 2 Y [bwd] (A) lockin + LI Demod 1 X [bwd] (A) lockin + LI Demod 1 Y [bwd] (A) lockin + Current (A) [filt] # forward direction (maybe from lockin#2?) + LI Demod 2 X (A) [filt] lockin + LI Demod 2 Y (A) [filt] lockin + LI Demod 1 X (A) [filt] lockin + LI Demod 1 Y (A) [filt] lockin Current (A) [bwd] [filt] - LI Demod 2 X (A) [bwd] [filt] - LI Demod 2 Y (A) [bwd] [filt] - LI Demod 1 X (A) [bwd] [filt] - LI Demod 1 Y (A) [bwd] [filt] + LI Demod 2 X (A) [bwd] [filt] lockin + LI Demod 2 Y (A) [bwd] [filt] lockin + LI Demod 1 X (A) [bwd] [filt] lockin + LI Demod 1 Y (A) [bwd] [filt] lockin + Temperature + x + y + z + + single point default plot # current(I) vs bias(V) + line scan default plot # multi I vs. V curves + alternative plot # current(I) curve in the 2D space of (position(x), bias(V)) + mesh scan default plot # 2D slices of the above alternative plot + From aaf1400c09b11c70b3e500ccb7ceeb25db2b3596 Mon Sep 17 00:00:00 2001 From: Yichen Date: Wed, 29 Mar 2023 15:39:25 +0200 Subject: [PATCH 0079/1012] Update NXiv_sweep2.yaml --- contributed_definitions/nyaml/NXiv_sweep2.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index 8228138d1b..a51113cb13 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -314,7 +314,7 @@ ENTRY LI Demod 2 Y (A) lockin LI Demod 1 X (A) lockin LI Demod 1 Y (A) lockin - Current [bwd] (A) #bwd - backward (the positive direction shall be clarified by the reference bias scanning frame) + Current [bwd] (A) #bwd - backward (the positive direction shall be clarified by the reference bias scanning frame. Fwd means from left(neg) to right(pos). In the scannig image, the bottom(neg) to top(pos), the left(neg) to right(pos) LI Demod 2 X [bwd] (A) lockin LI Demod 2 Y [bwd] (A) lockin LI Demod 1 X [bwd] (A) lockin From a3e1d2e25401e45089d6331b5bd4671846a92bef Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Wed, 5 Apr 2023 14:54:33 +0200 Subject: [PATCH 0080/1012] new base classes in NYAML format --- .../nyaml/NXamplifier.nxdl.xml | 77 +++++++ .../nyaml/NXamplifier.yaml | 25 +++ contributed_definitions/nyaml/NXbias.nxdl.xml | 34 +++ contributed_definitions/nyaml/NXbias.yaml | 7 + .../nyaml/NXcircuit.nxdl.xml | 33 +++ contributed_definitions/nyaml/NXcircuit.yaml | 6 + .../nyaml/NXiv_sweep2.yaml | 85 +------ .../nyaml/NXiv_temp.nxdl.xml | 84 +++++++ .../nyaml/NXlockin.nxdl.xml | 67 ++++++ contributed_definitions/nyaml/NXlockin.yaml | 26 +++ .../nyaml/NXsensor.nxdl.xml | 212 ++++++++++++++++++ contributed_definitions/nyaml/NXsensor.yaml | 130 +++++++++++ 12 files changed, 703 insertions(+), 83 deletions(-) create mode 100644 contributed_definitions/nyaml/NXamplifier.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXamplifier.yaml create mode 100644 contributed_definitions/nyaml/NXbias.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXbias.yaml create mode 100644 contributed_definitions/nyaml/NXcircuit.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcircuit.yaml create mode 100644 contributed_definitions/nyaml/NXiv_temp.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXlockin.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXlockin.yaml create mode 100644 contributed_definitions/nyaml/NXsensor.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXsensor.yaml diff --git a/contributed_definitions/nyaml/NXamplifier.nxdl.xml b/contributed_definitions/nyaml/NXamplifier.nxdl.xml new file mode 100644 index 0000000000..8eaa91786e --- /dev/null +++ b/contributed_definitions/nyaml/NXamplifier.nxdl.xml @@ -0,0 +1,77 @@ + + + + + + Application definition for lock in devices. + + + + (IC, device) (NXmanufacturer?) + + + + + + (array of chIDs) + + + + + (array for active channels) + + + + + (array for active channels) + + + + + (array for active channels) + + + + + (if active >1) + + + + + + + cut-off frq (low pass filter) + + + + + cut-off frq (hi pass filter) + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXamplifier.yaml b/contributed_definitions/nyaml/NXamplifier.yaml new file mode 100644 index 0000000000..28982c28b9 --- /dev/null +++ b/contributed_definitions/nyaml/NXamplifier.yaml @@ -0,0 +1,25 @@ +doc: | + Application definition for lock in devices. +category: base +NXamplifier: + hardware(NXfabrication): + doc: (IC, device) (NXmanufacturer?) + NumOfChannels(NX_NUMBER): + ActiveChannels(NX_NUMBER): + doc: (array of chIDs) + openloop_amplification(NX_NUMBER): + doc: (array for active channels) + amplification(NX_NUMBER): + doc: (array for active channels) + signal_over_noise(NX_NUMBER): + doc: (array for active channels) + crosstalk_factor(NX_NUMBER): + doc: (if active >1) + crosstalk_compensation(NX_BOOLEAN): + bandwidth(NX_NUMBER): + LowPass(NX_NUMBER): + doc: cut-off frq (low pass filter) + HiPass(NX_NUMBER): + doc: cut-off frq (hi pass filter) + type: + enumeration: [current, voltage] diff --git a/contributed_definitions/nyaml/NXbias.nxdl.xml b/contributed_definitions/nyaml/NXbias.nxdl.xml new file mode 100644 index 0000000000..ce26b61ae6 --- /dev/null +++ b/contributed_definitions/nyaml/NXbias.nxdl.xml @@ -0,0 +1,34 @@ + + + + + + Application definition for lock in devices. + + + + + Hardware parameter offset + + + diff --git a/contributed_definitions/nyaml/NXbias.yaml b/contributed_definitions/nyaml/NXbias.yaml new file mode 100644 index 0000000000..ebd34e0d13 --- /dev/null +++ b/contributed_definitions/nyaml/NXbias.yaml @@ -0,0 +1,7 @@ +doc: | + Application definition for lock in devices. +category: base +NXbias: + tunneling resistor(NXcircuit): + offset(NX_NUMBER): + doc: Hardware parameter offset diff --git a/contributed_definitions/nyaml/NXcircuit.nxdl.xml b/contributed_definitions/nyaml/NXcircuit.nxdl.xml new file mode 100644 index 0000000000..82557b289e --- /dev/null +++ b/contributed_definitions/nyaml/NXcircuit.nxdl.xml @@ -0,0 +1,33 @@ + + + + + + Application definition for lock in devices. + + + + (NXmanufacturer?) + + + diff --git a/contributed_definitions/nyaml/NXcircuit.yaml b/contributed_definitions/nyaml/NXcircuit.yaml new file mode 100644 index 0000000000..c155a76857 --- /dev/null +++ b/contributed_definitions/nyaml/NXcircuit.yaml @@ -0,0 +1,6 @@ +doc: | + Application definition for lock in devices. +category: base +NXcircuit: + hardware(NX_FABRICATION): + doc: (NXmanufacturer?) diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index a51113cb13..8fb149f544 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -16,14 +16,11 @@ doc: | x has (NXsoftware_Scan_offset) y has (NXsoftware_Scan_offset) z has (NXsoftware_Scan_offset) -symbols: - n_different_temperatures: "Number of different temperature setpoints used in the experiment." - n_different_voltages: "Number of different voltage setpoints used in the experiment." category: application -NXiv_temp(NXsensor_scan): +NXiv_sweep2(NXsensor_scan): (NXentry): definition(NX_CHAR): - enumeration: [NXiv_temp] + enumeration: [NXiv_sweep2] (NXinstrument): (NXenvironment): doc: | @@ -40,87 +37,9 @@ NXiv_temp(NXsensor_scan): There should also be two more fields called temperature and voltage containing the setpoint values. There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension equal to the number of voltage setpoints. - temperature(NX_NUMBER): - voltage(NX_NUMBER): - current(NX_NUMBER): - dimensions: - rank: 2 - dim: [[1, n_different_temperatures], [2, n_different_voltages]] - - - -ENTRY - PROCESS - USER - INSTRUMENT - ENVIRONMENT - SENSOR - value (settings or readngs) - value_timestamp - run_control - calibration_time - PID - DATA (specific plot) - - - -Base Classes: -============= - - - -NXamplifier: - hw (IC, device) (NXmanufacturer?) - NumOfChannels - ActiveChannels (array of chIDs) - openloop_amplification (array for active channels) - amplification (array for active channels) - signal/noise (array for active channels) - cross-talk factor (if active >1) - cross-talk compensation (bool) - bandwidth - LowPass cut-off frq (low pass filter) - HiPass cut-off frq (low pass filter) - type {"current", "voltage"} - -NXlockin: - hw (NXmanufacturer?) - (NXamplifier) (input and output amplifiers) - frequency - #output (demodulated signal) characterisation (foreach channel, like demodulation, a separate sensor output, e.g. X,Y) - NumOfDemodulatorChannels - LowPass cut-off frq (low pass filter) (foreach DemodulatorChannels) - HiPass cut-off frq (low pass filter) (foreach DemodulatorChannels) - Synch filter (foreach DemodulatorChannels) - refPhase (foreach DemodulatorChannels) - integrationTime (for the input filter) - NumOfHarmonics - sensitivityFactor (input gain) - - - -NXcircuit: - -NXsensor: -# link to second amplifer circuit with 1MOhm[NXcircuit] -# link to [NXamplifier] - -NXparameter: - -NXbias: -# link to Tunneling resistor circuit[NXcircuit] -# Hardware paramater offset - - - -Application Definition: -======================= - -NXsts(NXsensor_scan) -ENTRY (file)type [background, reference, sample] finename -> description (e.g. 221122_Au_5K00014) series name -> description? Scan>series name 221122_Au_5K diff --git a/contributed_definitions/nyaml/NXiv_temp.nxdl.xml b/contributed_definitions/nyaml/NXiv_temp.nxdl.xml new file mode 100644 index 0000000000..876db0de5e --- /dev/null +++ b/contributed_definitions/nyaml/NXiv_temp.nxdl.xml @@ -0,0 +1,84 @@ + + + + + + + + Number of different temperature setpoints used in the experiment. + + + + + Number of different voltage setpoints used in the experiment. + + + + + Application definition for temperature-dependent IV curve measurements. + + In this application definition, times should be specified always together + with an UTC offset. + + This is the application definition describing temperature dependent IV curve + measurements. For this a temperature is set. After reaching the temperature, + a voltage sweep is performed. For each voltage a current is measured. + Then, the next desired temperature is set and an IV measurement is performed. + + + + + + + + + + + Describes an environment setup for a temperature-dependent IV measurement experiment. + + The temperature and voltage must be present as independently scanned controllers and + the current sensor must also be present with its readings. + + + + + + + + + This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. + There should also be two more fields called temperature and voltage containing the setpoint values. + There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension + equal to the number of voltage setpoints. + + + + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXlockin.nxdl.xml b/contributed_definitions/nyaml/NXlockin.nxdl.xml new file mode 100644 index 0000000000..8b7a79a097 --- /dev/null +++ b/contributed_definitions/nyaml/NXlockin.nxdl.xml @@ -0,0 +1,67 @@ + + + + + + Application definition for lock in devices. + + + + + input and output amplifiers + + + + + + + cut-off frq (low pass filter) (foreach DemodulatorChannels) + + + + + cut-off frq (hi pass filter) (foreach DemodulatorChannels) + + + + + filter (foreach DemodulatorChannels) + + + + + (foreach DemodulatorChannels) + + + + + (for the input filter) + + + + + + (input gain) + + + diff --git a/contributed_definitions/nyaml/NXlockin.yaml b/contributed_definitions/nyaml/NXlockin.yaml new file mode 100644 index 0000000000..6b79ad0d14 --- /dev/null +++ b/contributed_definitions/nyaml/NXlockin.yaml @@ -0,0 +1,26 @@ +doc: | + Application definition for lock in devices. +category: base +NXlockin: + hardware(NXfabrication): + (NXamplifier): + doc: input and output amplifiers + frequency(NX_NUMBER): + unit: NX_FREQUENCY + #output (demodulated signal) characterisation (foreach channel, like demodulation, a separate sensor output, e.g. X,Y) + NumOfDemodulatorChannels(NX_NUMBER): + LowPass(NX_NUMBER): + doc: cut-off frq (low pass filter) (foreach DemodulatorChannels) + HiPass(NX_NUMBER): + doc: cut-off frq (hi pass filter) (foreach DemodulatorChannels) + Synch(NX_NUMBER): + doc: filter (foreach DemodulatorChannels) + refPhase(NX_NUMBER): + doc: (foreach DemodulatorChannels) + integrationTime(NX_NUMBER): + doc: (for the input filter) + unit: NX_TIME + NumOfHarmonics(NX_NUMBER): + sensitivityFactor(NX_NUMBER): + doc: (input gain) + diff --git a/contributed_definitions/nyaml/NXsensor.nxdl.xml b/contributed_definitions/nyaml/NXsensor.nxdl.xml new file mode 100644 index 0000000000..ea5f295aa1 --- /dev/null +++ b/contributed_definitions/nyaml/NXsensor.nxdl.xml @@ -0,0 +1,212 @@ + + + + + + A sensor used to monitor an external condition + + The condition itself is described in :ref:`NXenvironment`. + + + + Sensor identification code/model number + + + + + Name for the sensor + + + + + Short name of sensor used e.g. on monitor display program + + + + + where sensor is attached to ("sample" | "can") + + + + + Defines the axes for logged vector quantities if they are not the global instrument axes. + + + + + name for measured signal + + + + + + + + + + + + + + + + + + + + + The type of hardware used for the measurement. + Examples (suggestions but not restrictions): + + :Temperature: + J | K | T | E | R | S | Pt100 | Pt1000 | Rh/Fe + :pH: + Hg/Hg2Cl2 | Ag/AgCl | ISFET + :Ion selective electrode: + specify species; e.g. Ca2+ + :Magnetic field: + Hall + :Surface pressure: + wilhelmy plate + + + + + + link to second amplifer circuit with 1MOhm + + + + + Is data collection controlled or synchronised to this quantity: + 1=no, 0=to "value", 1=to "value_deriv1", etc. + + + + + Upper control bound of sensor reading if using run_control + + + + + Lower control bound of sensor reading if using run_control + + + + + nominal setpoint or average value + - need [n] as may be a vector + + + + + + + + Nominal/average first derivative of value + e.g. strain rate + - same dimensions as "value" (may be a vector) + + + + + + + + Nominal/average second derivative of value + - same dimensions as "value" (may be a vector) + + + + + + + + Time history of sensor readings + + + + + Time history of first derivative of sensor readings + + + + + Time history of second derivative of sensor readings + + + + + + + + + + + + + + + For complex external fields not satisfied by External_field_brief + + + + + This group describes the shape of the sensor when necessary. + + + + + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + + + + + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a sensor. + + + + + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. + + + diff --git a/contributed_definitions/nyaml/NXsensor.yaml b/contributed_definitions/nyaml/NXsensor.yaml new file mode 100644 index 0000000000..6364061284 --- /dev/null +++ b/contributed_definitions/nyaml/NXsensor.yaml @@ -0,0 +1,130 @@ +category: base +doc: | + A sensor used to monitor an external condition + + The condition itself is described in ':'ref':'`NXenvironment`. + +type: group +NXsensor(NXobject): + model: + doc: | + Sensor identification code/model number + name: + doc: | + Name for the sensor + short_name: + doc: | + Short name of sensor used e.g. on monitor display program + attached_to: + doc: | + where sensor is attached to ("sample" | "can") + geometry(NXgeometry): + deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the beamstop and NXoff_geometry to describe its shape instead + doc: | + Defines the axes for logged vector quantities if they are not the global instrument axes. + measurement: + doc: | + name for measured signal + enumeration: [temperature, pH, magnetic_field, electric_field, conductivity, resistance, voltage, current, pressure, flow, stress, strain, shear, surface_pressure] + type: + doc: | + The type of hardware used for the measurement. + Examples (suggestions but not restrictions)':' + + ':'Temperature':' + J | K | T | E | R | S | Pt100 | Pt1000 | Rh/Fe + ':'pH':' + Hg/Hg2Cl2 | Ag/AgCl | ISFET + ':'Ion selective electrode':' + specify species; e.g. Ca2+ + ':'Magnetic field':' + Hall + ':'Surface pressure':' + wilhelmy plate + amplifier(NXamplifier): + second_amplifier(NX_circuit): + doc: link to second amplifer circuit with 1MOhm + run_control(NX_BOOLEAN): + doc: | + Is data collection controlled or synchronised to this quantity':' + 1=no, 0=to "value", 1=to "value_deriv1", etc. + high_trip_value(NX_FLOAT): + unit: NX_ANY + doc: | + Upper control bound of sensor reading if using run_control + low_trip_value(NX_FLOAT): + unit: NX_ANY + doc: | + Lower control bound of sensor reading if using run_control + value(NX_FLOAT): + unit: NX_ANY + doc: | + nominal setpoint or average value + - need [n] as may be a vector + dimensions: + dim: [[1, n]] + value_deriv1(NX_FLOAT): + unit: NX_ANY + doc: | + Nominal/average first derivative of value + e.g. strain rate + - same dimensions as "value" (may be a vector) + dimensions: + dim: [[1, ]] + dim_parameters: + ref: ['value'] + value_deriv2(NX_FLOAT): + unit: NX_ANY + doc: | + Nominal/average second derivative of value + - same dimensions as "value" (may be a vector) + dimensions: + dim: [[1, ]] + dim_parameters: + ref: ['value'] + value_log(NXlog): + doc: | + Time history of sensor readings + value_deriv1_log(NXlog): + doc: | + Time history of first derivative of sensor readings + value_deriv2_log(NXlog): + doc: | + Time history of second derivative of sensor readings + external_field_brief: + enumeration: [along beam, across beam, transverse, solenoidal, flow shear gradient, flow vorticity] + external_field_full(NXorientation): + doc: | + For complex external fields not satisfied by External_field_brief + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the sensor when necessary. + \@default: + doc: | + .. index':'':' plotting + + Declares which child group contains a path leading + to a ':'ref':'`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https':'//www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo':'':' + Add a definition for the reference point of a sensor. + (NXtransformations): + doc: | + 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. From 129fedd802cf98914f93795eec8084bc8e2608c4 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Wed, 5 Apr 2023 15:24:09 +0200 Subject: [PATCH 0081/1012] clarification on sweep controls --- contributed_definitions/nyaml/NXiv_sweep2.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index 8fb149f544..6394585fd9 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -22,6 +22,8 @@ NXiv_sweep2(NXsensor_scan): definition(NX_CHAR): enumeration: [NXiv_sweep2] (NXinstrument): + Hardware: + doc: the name of the instrument device used.... (NXenvironment): doc: | Describes an environment setup for a temperature-dependent IV measurement experiment. @@ -138,7 +140,7 @@ NXiv_sweep2(NXsensor_scan): Y (m) 29.6968E-9 Z (m) 130.5E-9 Z-Controller>Z (m) 130.5E-9 - SCAN # parameters for a measurement at a single location during the scan + sweep control # parameters for a measurement at a single location during the scan Integration time (s) 150E-6 # Time during which the spectroscopy data are acquired and averaged. Bias Spectroscopy>Number of sweeps 100 # Number of sweeps to measure and average. Bias Spectroscopy>Sweep Start (V) -300E-3 # The first bias values of the sweep. From 5f4107a97eeaced2d78e73355d085faf1dc8753e Mon Sep 17 00:00:00 2001 From: Yichen Date: Sun, 9 Apr 2023 17:44:17 +0200 Subject: [PATCH 0082/1012] Update NXlockin.yaml --- contributed_definitions/nyaml/NXlockin.yaml | 22 +++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/contributed_definitions/nyaml/NXlockin.yaml b/contributed_definitions/nyaml/NXlockin.yaml index 6b79ad0d14..83cc197167 100644 --- a/contributed_definitions/nyaml/NXlockin.yaml +++ b/contributed_definitions/nyaml/NXlockin.yaml @@ -2,25 +2,31 @@ doc: | Application definition for lock in devices. category: base NXlockin: - hardware(NXfabrication): + hardware(NXfabrication): Nanonis BP5e (NXamplifier): doc: input and output amplifiers frequency(NX_NUMBER): + doc: Sets the frequency of the sine modulation added to the signal to modulate. unit: NX_FREQUENCY #output (demodulated signal) characterisation (foreach channel, like demodulation, a separate sensor output, e.g. X,Y) NumOfDemodulatorChannels(NX_NUMBER): + doc: The number of signals which will be demodulated. LowPass(NX_NUMBER): - doc: cut-off frq (low pass filter) (foreach DemodulatorChannels) + doc: Order and cut-off frequency of the low-pass filter applied on the demodulated signals (X,Y). Cut-off frq (low pass filter) (foreach DemodulatorChannels) + unit: NX_FREQUENCY HiPass(NX_NUMBER): - doc: cut-off frq (hi pass filter) (foreach DemodulatorChannels) - Synch(NX_NUMBER): - doc: filter (foreach DemodulatorChannels) + doc: Order and cut-off frequency of the high-pass filter applied on the demodulation signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) + unit: NX_FREQUENCY + Synch(NX_CHAR): + doc: Switch the Sync filter on the demodulated signals (X,Y) on or off. (foreach DemodulatorChannels) refPhase(NX_NUMBER): - doc: (foreach DemodulatorChannels) + doc: Reference phase for the sine on the demodulated signal with respect to the modulation signal. (foreach DemodulatorChannels) + unit: NX_FREQUENCY integrationTime(NX_NUMBER): - doc: (for the input filter) + doc: Time during which the data are acquired and averaged. (for the input filter) unit: NX_TIME NumOfHarmonics(NX_NUMBER): + doc: The number of order of the harmonic oscillation to detect on the demodulated signals. (with respect to the modulation frequency) sensitivityFactor(NX_NUMBER): - doc: (input gain) + doc: Ratio of output signal amplitude to input signal amplitue. (input gain) # Not sure about it. From fcecda01315a28ca1216680409ef979c905c546c Mon Sep 17 00:00:00 2001 From: Yichen Date: Sun, 9 Apr 2023 17:45:53 +0200 Subject: [PATCH 0083/1012] Update NXlockin.yaml --- contributed_definitions/nyaml/NXlockin.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributed_definitions/nyaml/NXlockin.yaml b/contributed_definitions/nyaml/NXlockin.yaml index 83cc197167..c227ab232c 100644 --- a/contributed_definitions/nyaml/NXlockin.yaml +++ b/contributed_definitions/nyaml/NXlockin.yaml @@ -28,5 +28,5 @@ NXlockin: NumOfHarmonics(NX_NUMBER): doc: The number of order of the harmonic oscillation to detect on the demodulated signals. (with respect to the modulation frequency) sensitivityFactor(NX_NUMBER): - doc: Ratio of output signal amplitude to input signal amplitue. (input gain) # Not sure about it. + doc: Ratio of output signal amplitude to input signal amplitue (V/V). (input gain) # Not sure about it. From 9f590e56083dc75c69ed4b8a16cdbab237544d09 Mon Sep 17 00:00:00 2001 From: Yichen Date: Sun, 9 Apr 2023 18:20:39 +0200 Subject: [PATCH 0084/1012] Update NXamplifier.yaml --- .../nyaml/NXamplifier.yaml | 21 ++++++++++++------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/contributed_definitions/nyaml/NXamplifier.yaml b/contributed_definitions/nyaml/NXamplifier.yaml index 28982c28b9..57d98850bf 100644 --- a/contributed_definitions/nyaml/NXamplifier.yaml +++ b/contributed_definitions/nyaml/NXamplifier.yaml @@ -1,25 +1,30 @@ doc: | - Application definition for lock in devices. + Application definition for amplifier devices. category: base NXamplifier: - hardware(NXfabrication): + hardware(NXfabrication): CreaTec GmbH doc: (IC, device) (NXmanufacturer?) NumOfChannels(NX_NUMBER): + doc: The number of preamplifier channels are assgined. ActiveChannels(NX_NUMBER): - doc: (array of chIDs) + doc: The number of preamplifier channels are ready tp to be used. (array for active channels) openloop_amplification(NX_NUMBER): - doc: (array for active channels) + doc: The output signal does not go through a feedback loop to adjust the amplification of the amplifier. (array for active channels) # From google. amplification(NX_NUMBER): - doc: (array for active channels) + doc: The ratio of the amplitude of the output signal to the amplitude of the input signal. (array for active channels) # From google. signal_over_noise(NX_NUMBER): - doc: (array for active channels) + doc: The ratio of the amplitue of the useful signal to the amplitude of the noise in the output signal of the amplifier. S/N=V_signal/V_noise. (array for active channels) crosstalk_factor(NX_NUMBER): doc: (if active >1) crosstalk_compensation(NX_BOOLEAN): bandwidth(NX_NUMBER): + doc: The spectrum of frequency it can amplify, from its lowest to highest frequency limits. + unit: NX_FREQUENCY LowPass(NX_NUMBER): - doc: cut-off frq (low pass filter) + doc: Order and cut-off frequency of the low-pass filter applied on the demodulated signals (X,Y). Cut-off frq (low pass filter) (foreach DemodulatorChannels) + unit: NX_FREQUENCY HiPass(NX_NUMBER): - doc: cut-off frq (hi pass filter) + doc: Order and cut-off frequency of the high-pass filter applied on the demodulation signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) + unit: NX_FREQUENCY type: enumeration: [current, voltage] From 40880c0115ff764abf6867a36ae44186d185ef22 Mon Sep 17 00:00:00 2001 From: Yichen Date: Sun, 9 Apr 2023 18:36:58 +0200 Subject: [PATCH 0085/1012] Update NXbias.yaml --- contributed_definitions/nyaml/NXbias.yaml | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/nyaml/NXbias.yaml b/contributed_definitions/nyaml/NXbias.yaml index ebd34e0d13..1f4c9f19aa 100644 --- a/contributed_definitions/nyaml/NXbias.yaml +++ b/contributed_definitions/nyaml/NXbias.yaml @@ -1,7 +1,10 @@ doc: | - Application definition for lock in devices. + Application definition for bias devices. category: base NXbias: tunneling resistor(NXcircuit): + doc: The ratio between the tunneling current at the sample surface and the bias voltage applied between between the sample and the tip. + unit: NX_CHAR (No NX_resistance) offset(NX_NUMBER): - doc: Hardware parameter offset + doc: Allows compensating for an offset in Bias. Hardware parameter offset. + unit: NX_VOLTAGE From 4e0e72625f31d68859344aa48b3304b40d29e046 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Tue, 11 Apr 2023 15:37:42 +0200 Subject: [PATCH 0086/1012] fixes and regeneration of nxdl files: nyaml2nxdl --input-file NXamplifier.yaml ... --- .../nyaml/NXamplifier.nxdl.xml | 38 +++++++++++----- .../nyaml/NXamplifier.yaml | 4 +- contributed_definitions/nyaml/NXbias.nxdl.xml | 13 ++++-- .../nyaml/NXlockin.nxdl.xml | 43 +++++++++++++------ contributed_definitions/nyaml/NXlockin.yaml | 2 +- 5 files changed, 69 insertions(+), 31 deletions(-) diff --git a/contributed_definitions/nyaml/NXamplifier.nxdl.xml b/contributed_definitions/nyaml/NXamplifier.nxdl.xml index 8eaa91786e..68ad2777bb 100644 --- a/contributed_definitions/nyaml/NXamplifier.nxdl.xml +++ b/contributed_definitions/nyaml/NXamplifier.nxdl.xml @@ -23,32 +23,41 @@ --> - Application definition for lock in devices. + Application definition for amplifier devices. (IC, device) (NXmanufacturer?) - + + + The number of preamplifier channels are assgined. + + - (array of chIDs) + The number of preamplifier channels are ready tp to be used. (array for active + channels) - (array for active channels) + The output signal does not go through a feedback loop to adjust the + amplification of the amplifier. (array for active channels) - (array for active channels) + The ratio of the amplitude of the output signal to the amplitude of the input + signal. (array for active channels) - (array for active channels) + The ratio of the amplitue of the useful signal to the amplitude of the noise in + the output signal of the amplifier. S/N=V_signal/V_noise. (array for active + channels) @@ -57,15 +66,22 @@ - - + + + The spectrum of frequency it can amplify, from its lowest to highest frequency + limits. + + + - cut-off frq (low pass filter) + Order and cut-off frequency of the low-pass filter applied on the demodulated + signals (X,Y). Cut-off frq (low pass filter) (foreach DemodulatorChannels) - + - cut-off frq (hi pass filter) + Order and cut-off frequency of the high-pass filter applied on the demodulation + signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) diff --git a/contributed_definitions/nyaml/NXamplifier.yaml b/contributed_definitions/nyaml/NXamplifier.yaml index 57d98850bf..098198d0c3 100644 --- a/contributed_definitions/nyaml/NXamplifier.yaml +++ b/contributed_definitions/nyaml/NXamplifier.yaml @@ -2,7 +2,7 @@ doc: | Application definition for amplifier devices. category: base NXamplifier: - hardware(NXfabrication): CreaTec GmbH + hardware(NXfabrication): doc: (IC, device) (NXmanufacturer?) NumOfChannels(NX_NUMBER): doc: The number of preamplifier channels are assgined. @@ -27,4 +27,4 @@ NXamplifier: doc: Order and cut-off frequency of the high-pass filter applied on the demodulation signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) unit: NX_FREQUENCY type: - enumeration: [current, voltage] + enumeration: [current, voltage] \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXbias.nxdl.xml b/contributed_definitions/nyaml/NXbias.nxdl.xml index ce26b61ae6..b6cb0892cf 100644 --- a/contributed_definitions/nyaml/NXbias.nxdl.xml +++ b/contributed_definitions/nyaml/NXbias.nxdl.xml @@ -23,12 +23,17 @@ --> - Application definition for lock in devices. + Application definition for bias devices. - - + - Hardware parameter offset + The ratio between the tunneling current at the sample surface and the bias + voltage applied between between the sample and the tip. + + + + + Allows compensating for an offset in Bias. Hardware parameter offset. diff --git a/contributed_definitions/nyaml/NXlockin.nxdl.xml b/contributed_definitions/nyaml/NXlockin.nxdl.xml index 8b7a79a097..37048d5c75 100644 --- a/contributed_definitions/nyaml/NXlockin.nxdl.xml +++ b/contributed_definitions/nyaml/NXlockin.nxdl.xml @@ -31,37 +31,54 @@ input and output amplifiers - - - + - cut-off frq (low pass filter) (foreach DemodulatorChannels) + Sets the frequency of the sine modulation added to the signal to modulate. - + - cut-off frq (hi pass filter) (foreach DemodulatorChannels) + The number of signals which will be demodulated. - + - filter (foreach DemodulatorChannels) + Order and cut-off frequency of the low-pass filter applied on the demodulated + signals (X,Y). Cut-off frq (low pass filter) (foreach DemodulatorChannels) - + - (foreach DemodulatorChannels) + Order and cut-off frequency of the high-pass filter applied on the demodulation + signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) + + + + + Switch the Sync filter on the demodulated signals (X,Y) on or off. (foreach + DemodulatorChannels) + + + + + Reference phase for the sine on the demodulated signal with respect to the + modulation signal. (foreach DemodulatorChannels) - (for the input filter) + Time during which the data are acquired and averaged. (for the input filter) + + + + + The number of order of the harmonic oscillation to detect on the demodulated + signals. (with respect to the modulation frequency) - - (input gain) + Ratio of output signal amplitude to input signal amplitue (V/V). (input gain) diff --git a/contributed_definitions/nyaml/NXlockin.yaml b/contributed_definitions/nyaml/NXlockin.yaml index c227ab232c..2487638699 100644 --- a/contributed_definitions/nyaml/NXlockin.yaml +++ b/contributed_definitions/nyaml/NXlockin.yaml @@ -2,7 +2,7 @@ doc: | Application definition for lock in devices. category: base NXlockin: - hardware(NXfabrication): Nanonis BP5e + hardware(NXfabrication): (NXamplifier): doc: input and output amplifiers frequency(NX_NUMBER): From b69c91e88cf4fbec8354cc41e7971c0e39898167 Mon Sep 17 00:00:00 2001 From: Yichen Date: Wed, 12 Apr 2023 14:55:05 +0200 Subject: [PATCH 0087/1012] Update NXlockin.yaml --- contributed_definitions/nyaml/NXlockin.yaml | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/nyaml/NXlockin.yaml b/contributed_definitions/nyaml/NXlockin.yaml index 2487638699..652cf1ac78 100644 --- a/contributed_definitions/nyaml/NXlockin.yaml +++ b/contributed_definitions/nyaml/NXlockin.yaml @@ -5,9 +5,16 @@ NXlockin: hardware(NXfabrication): (NXamplifier): doc: input and output amplifiers + Modulate signal(NX_CHAR): + doc: This is the signal on which the modulation (sine) will be added, such as current, bias, et.al. + Amplitude(NX_NUMBER): + doc: Sets the amplitude (in physical units of the modulated signal) of the sine modulation. + unit: NX_VOLTAGE (For bais modulate signal, it depands on the modulate type) frequency(NX_NUMBER): doc: Sets the frequency of the sine modulation added to the signal to modulate. unit: NX_FREQUENCY + Demodulated signal(NX_CHAR): + doc: This is the signal which will be demodulated, in order to determine the amplitude and phase at the frequency set in the Frequency field or harmonics, such as current, bias, et.al. #output (demodulated signal) characterisation (foreach channel, like demodulation, a separate sensor output, e.g. X,Y) NumOfDemodulatorChannels(NX_NUMBER): doc: The number of signals which will be demodulated. @@ -17,7 +24,7 @@ NXlockin: HiPass(NX_NUMBER): doc: Order and cut-off frequency of the high-pass filter applied on the demodulation signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) unit: NX_FREQUENCY - Synch(NX_CHAR): + Sync(NX_CHAR): doc: Switch the Sync filter on the demodulated signals (X,Y) on or off. (foreach DemodulatorChannels) refPhase(NX_NUMBER): doc: Reference phase for the sine on the demodulated signal with respect to the modulation signal. (foreach DemodulatorChannels) @@ -25,8 +32,8 @@ NXlockin: integrationTime(NX_NUMBER): doc: Time during which the data are acquired and averaged. (for the input filter) unit: NX_TIME - NumOfHarmonics(NX_NUMBER): - doc: The number of order of the harmonic oscillation to detect on the demodulated signals. (with respect to the modulation frequency) + OrderOfHarmonics(NX_NUMBER): + doc: The order of the harmonic oscillation to detect on the demodulated signals. (with respect to the modulation frequency) sensitivityFactor(NX_NUMBER): doc: Ratio of output signal amplitude to input signal amplitue (V/V). (input gain) # Not sure about it. From 647b02687387b484c305ef04109bfbb7059a1f9a Mon Sep 17 00:00:00 2001 From: Yichen Date: Wed, 12 Apr 2023 14:55:07 +0200 Subject: [PATCH 0088/1012] Update NXcircuit.yaml --- contributed_definitions/nyaml/NXcircuit.yaml | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/contributed_definitions/nyaml/NXcircuit.yaml b/contributed_definitions/nyaml/NXcircuit.yaml index c155a76857..d6395b6cc9 100644 --- a/contributed_definitions/nyaml/NXcircuit.yaml +++ b/contributed_definitions/nyaml/NXcircuit.yaml @@ -1,6 +1,14 @@ doc: | - Application definition for lock in devices. + Application definition for circuit devices. category: base NXcircuit: hardware(NX_FABRICATION): doc: (NXmanufacturer?) + Tunneling Current(NX_NUMBER): + doc: The tunneling current between tip and sample after application of bias voltage. + unit: NX_CURRENT + Calibration(NX_NUMBER): + doc: Calibration of the current measurement (A/V). + Offset(NX_NUMBER): + doc: Offset of the current measurement. + unit: NX_CURRENT From 80ae9108300a127425a3b84be0f7b88f13b0180a Mon Sep 17 00:00:00 2001 From: Yichen Date: Wed, 12 Apr 2023 14:55:11 +0200 Subject: [PATCH 0089/1012] Update NXamplifier.yaml --- contributed_definitions/nyaml/NXamplifier.yaml | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/contributed_definitions/nyaml/NXamplifier.yaml b/contributed_definitions/nyaml/NXamplifier.yaml index 098198d0c3..9a1bb41fa7 100644 --- a/contributed_definitions/nyaml/NXamplifier.yaml +++ b/contributed_definitions/nyaml/NXamplifier.yaml @@ -27,4 +27,8 @@ NXamplifier: doc: Order and cut-off frequency of the high-pass filter applied on the demodulation signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) unit: NX_FREQUENCY type: - enumeration: [current, voltage] \ No newline at end of file + enumeration: [current, voltage] + Current amplifier factor(NX_NUMBER): + doc: (V/V) + Current amplifier Capacitive cross-talk compensation: + doc: From a62710b8ac9642d5e019421a6e51f2099b74640b Mon Sep 17 00:00:00 2001 From: Yichen Date: Wed, 12 Apr 2023 15:28:44 +0200 Subject: [PATCH 0090/1012] Update NXbias.yaml --- contributed_definitions/nyaml/NXbias.yaml | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/contributed_definitions/nyaml/NXbias.yaml b/contributed_definitions/nyaml/NXbias.yaml index 1f4c9f19aa..0aa161b466 100644 --- a/contributed_definitions/nyaml/NXbias.yaml +++ b/contributed_definitions/nyaml/NXbias.yaml @@ -2,9 +2,21 @@ doc: | Application definition for bias devices. category: base NXbias: + (NXbias): + doc: Applied a voltage between tip and sample. + unit: NX_VOLTAGE tunneling resistor(NXcircuit): doc: The ratio between the tunneling current at the sample surface and the bias voltage applied between between the sample and the tip. - unit: NX_CHAR (No NX_resistance) + unit: NX_ANY (No NX_resistance) + Calibration(NX_NUMBER): + doc: Calibration of the Bias output (V/V). offset(NX_NUMBER): doc: Allows compensating for an offset in Bias. Hardware parameter offset. unit: NX_VOLTAGE + Modulated signal Bias(NXlockin): # or transfer it to NXlockin? + doc: Sets the amplitude (in physical units of the modulated signal) of the sine modulation. + unit: NX_VOLTAGE + Bias Spectroscopy(NX_CHAR): + doc: Bias sweeps while measuring arbitrary channels with I(V) curves. + + From 6c0d8086012c467fa514570af34bdf9560394b4a Mon Sep 17 00:00:00 2001 From: Rubel Date: Wed, 14 Jun 2023 08:45:52 +0200 Subject: [PATCH 0091/1012] fix conflict in rebase --- .../nyaml/NXiv_sweep2.yaml | 48 +++++++++++++++++++ 1 file changed, 48 insertions(+) diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index 6394585fd9..efcb614511 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -42,6 +42,54 @@ NXiv_sweep2(NXsensor_scan): + + + +ENTRY + PROCESS + USER + INSTRUMENT + ENVIRONMENT + SENSOR + value (settings or readngs) + value_timestamp + run_control + calibration_time + PID + DATA (specific plot) + + + +Base Classes: +============= + +NXamplifier: + hw (IC, device) (NXmanufacturer?) + NumOfChannels + ActiveChannels (array of chIDs) + openloop_amplification (array for active channels) + amplification (array for active channels) + s/n (array for active channels) + cross-talk factor (if active >1) + cross-talk compensation (bool) + +NXlockin: + hw (NXmanufacturer?) + (NXamplifier) (input and output amplifiers) + frequency + NumOfHarmonics + LowPass cut-off frq (low pass filter) (foreach Harmonics) + HiPass cut-off frq (low pass filter) (foreach Harmonics) + Synch filter (foreach Harmonics) + refPhase (foreach Harmonics) + + + +Application Definition: +======================= + +NXsts(NXsensor_scan) +ENTRY (file)type [background, reference, sample] finename -> description (e.g. 221122_Au_5K00014) series name -> description? Scan>series name 221122_Au_5K From 86452e793ef99179e379f3dace7d4a947418cb82 Mon Sep 17 00:00:00 2001 From: Rubel Date: Wed, 14 Jun 2023 08:46:43 +0200 Subject: [PATCH 0092/1012] fix conflict in rebase --- contributed_definitions/nyaml/NXiv_sweep2.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index efcb614511..6a2fec68e7 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -72,6 +72,8 @@ NXamplifier: s/n (array for active channels) cross-talk factor (if active >1) cross-talk compensation (bool) + preamplifiers + circuits NXlockin: hw (NXmanufacturer?) From 180fa3e21a47be43fa979e019b3e515a27105190 Mon Sep 17 00:00:00 2001 From: Rubel Date: Wed, 14 Jun 2023 08:47:38 +0200 Subject: [PATCH 0093/1012] fix conflict in rebase --- .../nyaml/NXiv_sweep2.yaml | 22 ++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index 6a2fec68e7..34562e910a 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -63,17 +63,20 @@ ENTRY Base Classes: ============= + + NXamplifier: hw (IC, device) (NXmanufacturer?) NumOfChannels ActiveChannels (array of chIDs) openloop_amplification (array for active channels) amplification (array for active channels) - s/n (array for active channels) + signal/noise (array for active channels) cross-talk factor (if active >1) cross-talk compensation (bool) - preamplifiers - circuits + bandwidth + LowPass cut-off frq (low pass filter) + HiPass cut-off frq (low pass filter) NXlockin: hw (NXmanufacturer?) @@ -85,6 +88,19 @@ NXlockin: Synch filter (foreach Harmonics) refPhase (foreach Harmonics) + +NXcircuit: + +NXsensor: +# link to second amplifer circuit with 1MOhm[NXcircuit] +# link to [NXamplifier] + +NXparameter: + +NXbias: +# link to Tunneling resistor circuit[NXcircuit] +# Hardware paramater offset + Application Definition: From b8ad8b85f46a329f1c379f6e65840a4c9395fab1 Mon Sep 17 00:00:00 2001 From: sanbrock <45483558+sanbrock@users.noreply.github.com> Date: Thu, 16 Mar 2023 09:50:56 +0100 Subject: [PATCH 0094/1012] Update NXiv_sweep2.yaml --- .../nyaml/NXiv_sweep2.yaml | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index 34562e910a..83dea826cb 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -16,6 +16,9 @@ doc: | x has (NXsoftware_Scan_offset) y has (NXsoftware_Scan_offset) z has (NXsoftware_Scan_offset) +symbols: + n_different_temperatures: "Number of different temperature setpoints used in the experiment." + n_different_voltages: "Number of different voltage setpoints used in the experiment." category: application NXiv_sweep2(NXsensor_scan): (NXentry): @@ -77,16 +80,22 @@ NXamplifier: bandwidth LowPass cut-off frq (low pass filter) HiPass cut-off frq (low pass filter) + type {"current", "voltage"} NXlockin: hw (NXmanufacturer?) (NXamplifier) (input and output amplifiers) frequency - NumOfHarmonics - LowPass cut-off frq (low pass filter) (foreach Harmonics) - HiPass cut-off frq (low pass filter) (foreach Harmonics) - Synch filter (foreach Harmonics) - refPhase (foreach Harmonics) + #output (demodulated signal) characterisation + NumOfDemodulatorChannels + LowPass cut-off frq (low pass filter) (foreach DemodulatorChannels) + HiPass cut-off frq (low pass filter) (foreach DemodulatorChannels) + Synch filter (foreach DemodulatorChannels) + refPhase (foreach DemodulatorChannels) ??? + integrationTime (for the input filter) + NumOfHarmonics + sensitivityFactor (input gain) + NXcircuit: From 0827d45abc3eb48ae851edb2f159a88c7e787ac2 Mon Sep 17 00:00:00 2001 From: Yichen Date: Wed, 22 Mar 2023 14:00:53 +0100 Subject: [PATCH 0095/1012] Update NXiv_sweep2.yaml --- contributed_definitions/nyaml/NXiv_sweep2.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index 83dea826cb..217b748a4c 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -91,7 +91,7 @@ NXlockin: LowPass cut-off frq (low pass filter) (foreach DemodulatorChannels) HiPass cut-off frq (low pass filter) (foreach DemodulatorChannels) Synch filter (foreach DemodulatorChannels) - refPhase (foreach DemodulatorChannels) ??? + refPhase (foreach DemodulatorChannels) integrationTime (for the input filter) NumOfHarmonics sensitivityFactor (input gain) From a8e9f87a6bb94baafff2721633c3a13556ae3879 Mon Sep 17 00:00:00 2001 From: sanbrock <45483558+sanbrock@users.noreply.github.com> Date: Wed, 22 Mar 2023 16:00:04 +0100 Subject: [PATCH 0096/1012] Update NXiv_sweep2.yaml --- contributed_definitions/nyaml/NXiv_sweep2.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index 217b748a4c..e7180125cc 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -86,7 +86,7 @@ NXlockin: hw (NXmanufacturer?) (NXamplifier) (input and output amplifiers) frequency - #output (demodulated signal) characterisation + #output (demodulated signal) characterisation (foreach channel, like demodulation, a separate sensor output, e.g. X,Y) NumOfDemodulatorChannels LowPass cut-off frq (low pass filter) (foreach DemodulatorChannels) HiPass cut-off frq (low pass filter) (foreach DemodulatorChannels) From d50978fa1f091b68e5bfed42e49eee72aa2b77e9 Mon Sep 17 00:00:00 2001 From: Rubel Date: Wed, 14 Jun 2023 08:55:00 +0200 Subject: [PATCH 0097/1012] fix conflict in rebase --- .../nyaml/NXiv_sweep2.yaml | 75 ------------------- 1 file changed, 75 deletions(-) diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index e7180125cc..6394585fd9 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -16,9 +16,6 @@ doc: | x has (NXsoftware_Scan_offset) y has (NXsoftware_Scan_offset) z has (NXsoftware_Scan_offset) -symbols: - n_different_temperatures: "Number of different temperature setpoints used in the experiment." - n_different_voltages: "Number of different voltage setpoints used in the experiment." category: application NXiv_sweep2(NXsensor_scan): (NXentry): @@ -45,78 +42,6 @@ NXiv_sweep2(NXsensor_scan): - - - -ENTRY - PROCESS - USER - INSTRUMENT - ENVIRONMENT - SENSOR - value (settings or readngs) - value_timestamp - run_control - calibration_time - PID - DATA (specific plot) - - - -Base Classes: -============= - - - -NXamplifier: - hw (IC, device) (NXmanufacturer?) - NumOfChannels - ActiveChannels (array of chIDs) - openloop_amplification (array for active channels) - amplification (array for active channels) - signal/noise (array for active channels) - cross-talk factor (if active >1) - cross-talk compensation (bool) - bandwidth - LowPass cut-off frq (low pass filter) - HiPass cut-off frq (low pass filter) - type {"current", "voltage"} - -NXlockin: - hw (NXmanufacturer?) - (NXamplifier) (input and output amplifiers) - frequency - #output (demodulated signal) characterisation (foreach channel, like demodulation, a separate sensor output, e.g. X,Y) - NumOfDemodulatorChannels - LowPass cut-off frq (low pass filter) (foreach DemodulatorChannels) - HiPass cut-off frq (low pass filter) (foreach DemodulatorChannels) - Synch filter (foreach DemodulatorChannels) - refPhase (foreach DemodulatorChannels) - integrationTime (for the input filter) - NumOfHarmonics - sensitivityFactor (input gain) - - - -NXcircuit: - -NXsensor: -# link to second amplifer circuit with 1MOhm[NXcircuit] -# link to [NXamplifier] - -NXparameter: - -NXbias: -# link to Tunneling resistor circuit[NXcircuit] -# Hardware paramater offset - - - -Application Definition: -======================= - -NXsts(NXsensor_scan) -ENTRY (file)type [background, reference, sample] finename -> description (e.g. 221122_Au_5K00014) series name -> description? Scan>series name 221122_Au_5K From b93426f81cca4b8ff85ba1aa64cd551d349b0029 Mon Sep 17 00:00:00 2001 From: Rubel Date: Wed, 14 Jun 2023 08:56:18 +0200 Subject: [PATCH 0098/1012] fix conflict in rebase --- contributed_definitions/nyaml/NXlockin.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributed_definitions/nyaml/NXlockin.yaml b/contributed_definitions/nyaml/NXlockin.yaml index 652cf1ac78..c1b1f88869 100644 --- a/contributed_definitions/nyaml/NXlockin.yaml +++ b/contributed_definitions/nyaml/NXlockin.yaml @@ -2,7 +2,7 @@ doc: | Application definition for lock in devices. category: base NXlockin: - hardware(NXfabrication): + hardware(NXfabrication): Nanonis BP5e (NXamplifier): doc: input and output amplifiers Modulate signal(NX_CHAR): From df8f03ee4583129bedc3bef7497cc807fe78015a Mon Sep 17 00:00:00 2001 From: Yichen Date: Sun, 9 Apr 2023 18:20:39 +0200 Subject: [PATCH 0099/1012] Update NXamplifier.yaml --- contributed_definitions/nyaml/NXamplifier.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributed_definitions/nyaml/NXamplifier.yaml b/contributed_definitions/nyaml/NXamplifier.yaml index 9a1bb41fa7..5245bb24c4 100644 --- a/contributed_definitions/nyaml/NXamplifier.yaml +++ b/contributed_definitions/nyaml/NXamplifier.yaml @@ -2,7 +2,7 @@ doc: | Application definition for amplifier devices. category: base NXamplifier: - hardware(NXfabrication): + hardware(NXfabrication): CreaTec GmbH doc: (IC, device) (NXmanufacturer?) NumOfChannels(NX_NUMBER): doc: The number of preamplifier channels are assgined. From 63cd5cb2a1dec4330c9a803c15c9805d4a9d9a4a Mon Sep 17 00:00:00 2001 From: Rubel Date: Wed, 14 Jun 2023 08:59:20 +0200 Subject: [PATCH 0100/1012] fix conflict in rebase --- contributed_definitions/nyaml/NXamplifier.yaml | 2 +- contributed_definitions/nyaml/NXlockin.yaml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/nyaml/NXamplifier.yaml b/contributed_definitions/nyaml/NXamplifier.yaml index 5245bb24c4..9a1bb41fa7 100644 --- a/contributed_definitions/nyaml/NXamplifier.yaml +++ b/contributed_definitions/nyaml/NXamplifier.yaml @@ -2,7 +2,7 @@ doc: | Application definition for amplifier devices. category: base NXamplifier: - hardware(NXfabrication): CreaTec GmbH + hardware(NXfabrication): doc: (IC, device) (NXmanufacturer?) NumOfChannels(NX_NUMBER): doc: The number of preamplifier channels are assgined. diff --git a/contributed_definitions/nyaml/NXlockin.yaml b/contributed_definitions/nyaml/NXlockin.yaml index c1b1f88869..652cf1ac78 100644 --- a/contributed_definitions/nyaml/NXlockin.yaml +++ b/contributed_definitions/nyaml/NXlockin.yaml @@ -2,7 +2,7 @@ doc: | Application definition for lock in devices. category: base NXlockin: - hardware(NXfabrication): Nanonis BP5e + hardware(NXfabrication): (NXamplifier): doc: input and output amplifiers Modulate signal(NX_CHAR): From 6c1e691d5d8b74e12f504406a899c0e235a86a3c Mon Sep 17 00:00:00 2001 From: Yichen Date: Tue, 18 Apr 2023 17:45:49 +0200 Subject: [PATCH 0101/1012] Update NXbias.yaml --- contributed_definitions/nyaml/NXbias.yaml | 46 ++++++++++++++++++++++- 1 file changed, 44 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/nyaml/NXbias.yaml b/contributed_definitions/nyaml/NXbias.yaml index 0aa161b466..4a99225e56 100644 --- a/contributed_definitions/nyaml/NXbias.yaml +++ b/contributed_definitions/nyaml/NXbias.yaml @@ -16,7 +16,49 @@ NXbias: Modulated signal Bias(NXlockin): # or transfer it to NXlockin? doc: Sets the amplitude (in physical units of the modulated signal) of the sine modulation. unit: NX_VOLTAGE - Bias Spectroscopy(NX_CHAR): + Bias Spectroscopy(NXbias): doc: Bias sweeps while measuring arbitrary channels with I(V) curves. - + Channels(NX_CHAR): + doc: Select the channels to record. + Reset Bias(NX_CHAR): + doc: When selected, the Bias voltage returns to the initial value (before starting the sweep) at the end of the spectroscopy measurement (default). When not selected, Bias remains at the last value of the sweep. This is useful e.g. when combining several sweep segments. Example for an automated measurement (using Programming Interface): switch off Z-Controller, start spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, switch on Z-Controller. + Record final Z(NX_CHAR): + doc: Select whether to record the Z position during Z averaging time at the end of the sweep (after Z control time) and store the average value in the header of the file when saving. Using this option increases the sweep time by Z averaging time. + Lock-In run(NX_CHAR): + doc: Select whether to set the Lock-In to run during the measurement. When using this feature, make sure the Lock-In is configured correctly and settling times are set to twice the Lock-In period at least. This option is ignored when Lock-In is already running. This option is disabled if the Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline segment editor is set. + Number of sweeps(NX_NUMBER): + doc: Number of sweeps to measure and average. + Sweep Start(NX_NUMBER): + doc: The first bias values of the sweep. + unit: NX_VOLTAGE + Sweep End(NX_NUMBER): + doc: The last bias values of the sweep. + unit: NX_VOLTAGE + Num Pixel(NX_NUMBER): + doc: Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. + Z Avg time(NX_NUMBER): + doc: Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). + unit: NX_TIME + Z offset(NX_NUMBER): + doc: Offset added to the initial averaged position Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an alternate Z-controller setpoint is enabled. + unit: NX_LENGTH + Settling time(NX_NUMBER): + doc: time to wait after changing the bias to the next level and before starting to acquire data. + unit: NX_TIME + Integration time(NX_NUMBER): + doc: Time during which the data are acquired and averaged. + unit: NX_TIME + End Settling time(NX_NUMBER): + doc: Time to wait after the sweep has finished and the bias is ramped to the initial value. + unit: NX_TIME + Z control time(NX_NUMBER): + doc: Time during which the Z-Controller is enabled once a sweep has finished. When averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled for this duration between each sweep. After the last sweep, it will wait the specified time before continuing a running scan. This ensures each sweep reliably starts from the same position. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. + unit: NX_TIME + Max Slew rate(NX_NUMBER): + doc: Maximum rate at which the bias changes (before, during and after sweeping). (V/s) + backward sweep(NX_CHAR): + doc: Select whether to measure the backward (return) sweep or the forward only. + Z-controller hold(NX_CHAR): + doc: Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. + From 90e6bc342603c1c7693faa8a0cd045a08934ab97 Mon Sep 17 00:00:00 2001 From: Yichen Date: Tue, 18 Apr 2023 18:07:28 +0200 Subject: [PATCH 0102/1012] Update NXbias.yaml --- contributed_definitions/nyaml/NXbias.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributed_definitions/nyaml/NXbias.yaml b/contributed_definitions/nyaml/NXbias.yaml index 4a99225e56..8c5cd5fa62 100644 --- a/contributed_definitions/nyaml/NXbias.yaml +++ b/contributed_definitions/nyaml/NXbias.yaml @@ -2,7 +2,7 @@ doc: | Application definition for bias devices. category: base NXbias: - (NXbias): + NXbias(NXobject): doc: Applied a voltage between tip and sample. unit: NX_VOLTAGE tunneling resistor(NXcircuit): From d7a18ef7cca308a6de6827eebe5fa47c0a57c8fa Mon Sep 17 00:00:00 2001 From: Yichen Date: Tue, 18 Apr 2023 18:37:30 +0200 Subject: [PATCH 0103/1012] Update NXsensor.yaml --- contributed_definitions/nyaml/NXsensor.yaml | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/contributed_definitions/nyaml/NXsensor.yaml b/contributed_definitions/nyaml/NXsensor.yaml index 6364061284..594a602917 100644 --- a/contributed_definitions/nyaml/NXsensor.yaml +++ b/contributed_definitions/nyaml/NXsensor.yaml @@ -128,3 +128,14 @@ NXsensor(NXobject): and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups. + ############## + Temperature(NX_sensor): + doc: External sensors connected to the device. For example, T1, temperature of STM head. T2, temperature of bottom of LHe helium cryostat. T3, temperature of LN2 nitrogen shield. + unit: NX_TEMPERATURE + Pressure(NX_sensor): + doc: External sensors connected to the device. Pressure of each chamber or ion pump, such as prepare chamber and analysis chamber + unit: NX_PRESSURE + Power Spectral Density (NX_sensor): + doc: The power present in the signal as a function of frequency. TBA + + From 923665f9548911e63a09bbec03025bab947db47d Mon Sep 17 00:00:00 2001 From: Yichen Date: Wed, 19 Apr 2023 13:35:08 +0200 Subject: [PATCH 0104/1012] Create NXpositioner.yaml Copy from base_classes to the contribution_definations, to extend NXpositioners. Add parameter STM piezo, z-offset, and z-contronller. --- .../nyaml/NXpositioner.yaml | 158 ++++++++++++++++++ 1 file changed, 158 insertions(+) create mode 100644 contributed_definitions/nyaml/NXpositioner.yaml diff --git a/contributed_definitions/nyaml/NXpositioner.yaml b/contributed_definitions/nyaml/NXpositioner.yaml new file mode 100644 index 0000000000..30ab555324 --- /dev/null +++ b/contributed_definitions/nyaml/NXpositioner.yaml @@ -0,0 +1,158 @@ +category: base +doc: | + A generic positioner such as a motor or piezo-electric transducer. + +type: group +NXpositioner(NXobject): + name: + doc: | + symbolic or mnemonic name (one word) + description: + doc: | + description of positioner + value(NX_NUMBER): + unit: NX_ANY + doc: | + best known value of positioner - need [n] as may be scanned + dimensions: + rank: 1 + dim: [[1, n]] + raw_value(NX_NUMBER): + unit: NX_ANY + doc: | + raw value of positioner - need [n] as may be scanned + dimensions: + rank: 1 + dim: [[1, n]] + target_value(NX_NUMBER): + unit: NX_ANY + doc: | + targeted (commanded) value of positioner - need [n] as may be scanned + dimensions: + rank: 1 + dim: [[1, n]] + tolerance(NX_NUMBER): + unit: NX_ANY + doc: | + maximum allowable difference between target_value and value + dimensions: + rank: 1 + dim: [[1, n]] + soft_limit_min(NX_NUMBER): + unit: NX_ANY + doc: | + minimum allowed limit to set value + soft_limit_max(NX_NUMBER): + unit: NX_ANY + doc: | + maximum allowed limit to set value + velocity(NX_NUMBER): + unit: NX_ANY + doc: | + velocity of the positioner (distance moved per unit time) + acceleration_time(NX_NUMBER): + unit: NX_ANY + doc: | + time to ramp the velocity up to full speed + controller_record: + doc: | + Hardware device record, e.g. EPICS process variable, taco/tango ... + \@default: + doc: | + .. index':'':' plotting + + Declares which child group contains a path leading + to a ':'ref':'`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https':'//www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo':'':' + Add a definition for the reference point of a positioner. + (NXtransformations): + doc: | + 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. + + Position(NXtransformation): + doc: To clarify the frame laboratory frame. The scanning area in x, y, and z position in the frame. + unit: NX_LENGTH + Z_contronller: + doc: This controllers task is to continuously adjust the Z position of the stm-tip in order to keep the selected control signal as close as possible to the Set Point. Different contro; signals lead to different contronller beahvior. + Z-offset(NX_NUMBER): + doc: Offset added to the initial averaged position Zaver before starting to swepp. + unit: NX_LENGTH + Tip_position_Z(NX_NUMBER): + doc: Indicate the tip position Z between tip and sample. The tip position can also be varied when the controller is not running. + unit: NX_LENGTH + Controller name(NX_CHAR): + doc: Controller name. This name which will be displayed at places where you can select a controller. + Setpoint(NX_NUMBER): + doc: Set Point is the desired value of the control signal. It can be set by editing the number or using the slider bar. Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. + unit: NX_CUTTENT + Setpoint unit(NX_CHAR): + doc: The unit of setpoint during the scanning. + P gain(NX_NUMBER): + dos: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. + unit: NX_LENGTH + I gain(NX_NUMBER): + dos: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. + unit: NX_ANY (NX_SPEED?) + Time const(NX_NUMBER): + dos: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. + unit: NX_TIME + TipLift(NX_NUMBER): + doc: Lifts the tip by the specified amount when then controller is switched off. This can be a positive or a negative number, i.e. the tip can also be moved towards the sample. Be careful with sign and value when using this feature. + unit: NX_LENGTH + Switch off delay(NX_NUMBER): + doc: Use this parameter for a reproducible position when switching off the Z-controller. When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. + unit: NX_TIME + Piezo_calibration: + doc: Piezo calibration module is used to define the X Y Z piezos calibration. + Calibr(NX_NUMBER): + doc: There are 3 parameters in X, Y, and Z directions and there are 3 controls available: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. + unit: NX_ANY + Range(NX_NUMBER): + doc: Adjusts the amplitude range or amplitude of the Piezo output signal + unit: NX_LENGTH + HV Gain(NX_NUMBER): + doc: For some systems HV gain readout is available, so for those systems the HV gain should be adjusted automatically when the gain is changed at the high voltage amplifier. + unit: NX_ANY + Tilt(NX_NUMBER): + doc: There are 2 parameters in X and Y directions and this tab is used to set the sample tilt (in degrees, first order correction). + unit: NX_ANGLE + Curvature radius(NX_NUMBER): + doc: There are 2 parameters in X and Y directions and this tab is used to set a curvature (can be set approximately to the length of the piezotube). + unit: NX_LENGTH + 2nd order corr: + doc: There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2) + Drift(NX_NUMBER): + doc: There are 2 parameters in X and Y directions. Define the drift speed for all three axes. When the compensation is on, the piezos will start to move at that speed. + unit: NX_ANY (need NX_SPEED) + Drift correction status(NX_CHAR): + doc: Use the button to turn on/off the drift compensation. + + + + + + + + + + + + + From 7949925b35c8cbbeb2f5d629df6009096bbb572c Mon Sep 17 00:00:00 2001 From: Yichen Date: Wed, 19 Apr 2023 14:15:05 +0200 Subject: [PATCH 0105/1012] Update NXsensor.yaml Extend the NXsensor with temperature, pressure, and PSD sensor in the stm system. --- contributed_definitions/nyaml/NXsensor.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributed_definitions/nyaml/NXsensor.yaml b/contributed_definitions/nyaml/NXsensor.yaml index 594a602917..a3d8a54405 100644 --- a/contributed_definitions/nyaml/NXsensor.yaml +++ b/contributed_definitions/nyaml/NXsensor.yaml @@ -136,6 +136,6 @@ NXsensor(NXobject): doc: External sensors connected to the device. Pressure of each chamber or ion pump, such as prepare chamber and analysis chamber unit: NX_PRESSURE Power Spectral Density (NX_sensor): - doc: The power present in the signal as a function of frequency. TBA + doc: The power present in the signal as a function of frequency. Used to characterise the vibration and noise of scanning probes to detect and reduce the impact on resolution during STM imaging From 5bb3935ef768649b2bb38306b3b9414980832c29 Mon Sep 17 00:00:00 2001 From: Yichen Date: Wed, 19 Apr 2023 14:54:44 +0200 Subject: [PATCH 0106/1012] Copying yaml files from base_classed spm branch. To extend the Nxpositioner.yaml file with Position, Z-controller, piezo calibration, and scan-contronller in STM system. --- .../nyaml/NXpositioner.yaml | 24 +++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/nyaml/NXpositioner.yaml b/contributed_definitions/nyaml/NXpositioner.yaml index 30ab555324..f7cecf676b 100644 --- a/contributed_definitions/nyaml/NXpositioner.yaml +++ b/contributed_definitions/nyaml/NXpositioner.yaml @@ -119,8 +119,27 @@ NXpositioner(NXobject): Switch off delay(NX_NUMBER): doc: Use this parameter for a reproducible position when switching off the Z-controller. When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. unit: NX_TIME - Piezo_calibration: - doc: Piezo calibration module is used to define the X Y Z piezos calibration. + Z-controller hold(NX_CHAR): + doc: (In biase spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. + Scan contronller: + doc: To contron the tip and various scan operations. + Scanfield(NX_NUMBER): + doc: Configure the scan frame: x position; y position; width; height. + unit: NX_LENGTH + pixels/line(NX_NUMBER): + doc: Scan resolution by setting the Lines equal to Pixels. + unit: NX_ANY + lines(NX_NUMBER): + doc: Define the image resolution. + unit: NX_ANY + speed forw.(NX_NUMBER): + doc: Define the scan forward speed in the forward direction. + unit: NX_ANY(NX_SPEED?) + speed backw.(NX_NUMBER): + doc: Define the scan backward speed in the forward direction. + unit: NX_ANY(NX_SPEED?) + Piezo_calibration: + doc: Piezo calibration module is used to define the X Y Z piezos calibration. Calibr(NX_NUMBER): doc: There are 3 parameters in X, Y, and Z directions and there are 3 controls available: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. unit: NX_ANY @@ -143,6 +162,7 @@ NXpositioner(NXobject): unit: NX_ANY (need NX_SPEED) Drift correction status(NX_CHAR): doc: Use the button to turn on/off the drift compensation. + From 812ee886afc1472046737629c769410495330397 Mon Sep 17 00:00:00 2001 From: Yichen Date: Wed, 19 Apr 2023 14:54:55 +0200 Subject: [PATCH 0107/1012] Update NXcircuit.yaml add the Nanonismain to NXcircuit.yaml --- contributed_definitions/nyaml/NXcircuit.yaml | 21 ++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/contributed_definitions/nyaml/NXcircuit.yaml b/contributed_definitions/nyaml/NXcircuit.yaml index d6395b6cc9..15e4dec7ac 100644 --- a/contributed_definitions/nyaml/NXcircuit.yaml +++ b/contributed_definitions/nyaml/NXcircuit.yaml @@ -12,3 +12,24 @@ NXcircuit: Offset(NX_NUMBER): doc: Offset of the current measurement. unit: NX_CURRENT + channels(NX_CHAR): + doc: The scan channels are selected by users (in scan contronaller). + RT Frequency(NX_NUMBER): + doc: The bandwitdh of the Hardware and/or Software + unit: NX_FREQUENCY + Signals Oversampling(NX_NUMBER): + doc: (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. + unit: NX_ANY + Acquisition Period(NX_NUMBER): + doc: Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. + unit: NX_TIME + Animations Period(NX_NUMBER): + doc: Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. + unit: NX_TIME + Indicators Period(NX_NUMBER): + doc: Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. + unit: NX_TIME + Measurements Period(NX_NUMBER): + doc: The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. + unit: NX_TIME + From a6ba83142cd62ccd3f8ac90d84b69f809b9b3ed9 Mon Sep 17 00:00:00 2001 From: Rubel Date: Wed, 14 Jun 2023 10:42:05 +0200 Subject: [PATCH 0108/1012] fix conflict in rebase --- .../nyaml/NXamplifier.nxdl.xml | 10 + contributed_definitions/nyaml/NXbias.nxdl.xml | 133 ++++++++++- contributed_definitions/nyaml/NXbias.yaml | 5 +- .../nyaml/NXcircuit.nxdl.xml | 73 +++++- .../nyaml/NXlockin.nxdl.xml | 27 ++- .../nyaml/NXpositioner.nxdl.xml | 217 ++++++++++++++++++ .../nyaml/NXpositioner.yaml | 27 ++- .../nyaml/NXsensor.nxdl.xml | 20 ++ 8 files changed, 492 insertions(+), 20 deletions(-) create mode 100644 contributed_definitions/nyaml/NXpositioner.nxdl.xml diff --git a/contributed_definitions/nyaml/NXamplifier.nxdl.xml b/contributed_definitions/nyaml/NXamplifier.nxdl.xml index 68ad2777bb..9b51e4e833 100644 --- a/contributed_definitions/nyaml/NXamplifier.nxdl.xml +++ b/contributed_definitions/nyaml/NXamplifier.nxdl.xml @@ -90,4 +90,14 @@ + + + (V/V) + + + + + + + diff --git a/contributed_definitions/nyaml/NXbias.nxdl.xml b/contributed_definitions/nyaml/NXbias.nxdl.xml index b6cb0892cf..49d2b17754 100644 --- a/contributed_definitions/nyaml/NXbias.nxdl.xml +++ b/contributed_definitions/nyaml/NXbias.nxdl.xml @@ -25,15 +25,146 @@ Application definition for bias devices. - + + + Applied a voltage between tip and sample. + + + The ratio between the tunneling current at the sample surface and the bias voltage applied between between the sample and the tip. + + + Calibration of the Bias output (V/V). + + Allows compensating for an offset in Bias. Hardware parameter offset. + + + Sets the amplitude (in physical units of the modulated signal) of the sine + modulation. + + + + + Bias sweeps while measuring arbitrary channels with I(V) curves. + + + + Select the channels to record. + + + + + When selected, the Bias voltage returns to the initial value (before starting the sweep) at the end of the spectroscopy measurement (default). When not selected, Bias remains at the last value of the sweep. This is useful e.g. when combining several sweep segments. Example for an automated measurement (using Programming Interface): switch off Z-Controller, start spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, switch on Z-Controller. + + + + + Select whether to record the Z position during Z averaging time at the end of + the sweep (after Z control time) and store the average value in the header of + the file when saving. Using this option increases the sweep time by Z averaging + time. + + + + + Select whether to set the Lock-In to run during the measurement. When using this + feature, make sure the Lock-In is configured correctly and settling times are + set to twice the Lock-In period at least. This option is ignored when Lock-In is + already running. This option is disabled if the Sweep Mode is MLS and the flag + to configure the Lock-In per segment in the Multiline segment editor is set. + + + + + Number of sweeps to measure and average. + + + + + The first bias values of the sweep. + + + + + The last bias values of the sweep. + + + + + Define the sweep number of points, that is, the maximum spectrum resolution eq. + Bias window divide by Num Pixel. + + + + + Duration over which the Z position is recorded and averaged before and after the + sweep (the latter only if Record final Z position is selected in the Advanced + section). After the initial Z averaging time, if Z-Controller to Hold is + selected in the Advanced section, the Z-Controller is set to hold and the tip is + placed at the previously averaged Z position (plus Z offset). + + + + + Offset added to the initial averaged position Zaver before starting to sweep. + This parameter is disabled when Z-Controller to Hold is deselected in the + Advanced section. The LED “Alt” next to the Z offset indicates if an alternate + Z-controller setpoint is enabled. + + + + + time to wait after changing the bias to the next level and before starting to + acquire data. + + + + + Time during which the data are acquired and averaged. + + + + + Time to wait after the sweep has finished and the bias is ramped to the initial + value. + + + + + Time during which the Z-Controller is enabled once a sweep has finished. When + averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled for this + duration between each sweep. After the last sweep, it will wait the specified + time before continuing a running scan. This ensures each sweep reliably starts + from the same position. This parameter is disabled when Z-Controller to Hold is + deselected in the Advanced section. + + + + + Maximum rate at which the bias changes (before, during and after sweeping). + (V/s) + + + + + Select whether to measure the backward (return) sweep or the forward only. + + + + + Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. + It is selected by default. When deselected, Z-offset and Z control time + parameters are disabled. + + + diff --git a/contributed_definitions/nyaml/NXbias.yaml b/contributed_definitions/nyaml/NXbias.yaml index 8c5cd5fa62..d2e8e091fb 100644 --- a/contributed_definitions/nyaml/NXbias.yaml +++ b/contributed_definitions/nyaml/NXbias.yaml @@ -17,11 +17,12 @@ NXbias: doc: Sets the amplitude (in physical units of the modulated signal) of the sine modulation. unit: NX_VOLTAGE Bias Spectroscopy(NXbias): - doc: Bias sweeps while measuring arbitrary channels with I(V) curves. + doc: Bias sweeps while measuring arbitrary channels with I(V) curves. Channels(NX_CHAR): doc: Select the channels to record. Reset Bias(NX_CHAR): - doc: When selected, the Bias voltage returns to the initial value (before starting the sweep) at the end of the spectroscopy measurement (default). When not selected, Bias remains at the last value of the sweep. This is useful e.g. when combining several sweep segments. Example for an automated measurement (using Programming Interface): switch off Z-Controller, start spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, switch on Z-Controller. + doc: | + When selected, the Bias voltage returns to the initial value (before starting the sweep) at the end of the spectroscopy measurement (default). When not selected, Bias remains at the last value of the sweep. This is useful e.g. when combining several sweep segments. Example for an automated measurement (using Programming Interface): switch off Z-Controller, start spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, switch on Z-Controller. Record final Z(NX_CHAR): doc: Select whether to record the Z position during Z averaging time at the end of the sweep (after Z control time) and store the average value in the header of the file when saving. Using this option increases the sweep time by Z averaging time. Lock-In run(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXcircuit.nxdl.xml b/contributed_definitions/nyaml/NXcircuit.nxdl.xml index 82557b289e..dd26578b87 100644 --- a/contributed_definitions/nyaml/NXcircuit.nxdl.xml +++ b/contributed_definitions/nyaml/NXcircuit.nxdl.xml @@ -23,11 +23,82 @@ --> - Application definition for lock in devices. + Application definition for circuit devices. (NXmanufacturer?) + + + The tunneling current between tip and sample after application of bias voltage. + + + + + Calibration of the current measurement (A/V). + + + + + Offset of the current measurement. + + + + + The scan channels are selected by users (in scan contronaller). + + + + + The bandwitdh of the Hardware and/or Software + + + + + (Signals Periods) The Signals Period is the rate at which the signals are + transferred to the host computer running the control software. This is usually + lower by a factor of 10 than the sampling rate, because an internal oversampling + of the signal is done on the real time engine. You can reduce the oversampling + down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. + + + + + Update rate for several processes like History Graph, Auto-Approach, and for + many Programming Interface functions. This is usually set to 20 ms. All + additional timings (7-9) can only be integer multiples of this value. They can + be set to different values, but the actual timing value will be coerced to a + multiple of the Acquisition Period. + + + + + Update rate of animated graphical indicators. These are e.g. some graphs & + sliders. A reasonable value is 40 ms (25 updates per second). Increase this + period to reduce the processor load for the graphical user interface, especially + on slow computers. This value is purely a user interface update rate and does + not affect measurements in any way. + + + + + Update rate of digital indicators, e.g. the numbers displayed besides each + slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a + user interface update rate and does not affect measurements in any way. + + + + + The Measurements period is the integration time for precise measurements + (averaging over specified period), mostly used in sweep modules. Examples are + recording of a force-distance curve or a resonance of a cantilever. For fast + measurements with small steps, a value of 40 ms may be reasonable. For normal + use, 300-500 ms is a good value, but for recording a resonance of a high-Q + cantilever, values of several seconds might be necessary. Usually this parameter + doesn’t need to be set from this module; the sweep modules will set this value + according to the sweep timings. + + diff --git a/contributed_definitions/nyaml/NXlockin.nxdl.xml b/contributed_definitions/nyaml/NXlockin.nxdl.xml index 37048d5c75..44aeb401ad 100644 --- a/contributed_definitions/nyaml/NXlockin.nxdl.xml +++ b/contributed_definitions/nyaml/NXlockin.nxdl.xml @@ -31,11 +31,30 @@ input and output amplifiers + + + This is the signal on which the modulation (sine) will be added, such as + current, bias, et.al. + + + + + Sets the amplitude (in physical units of the modulated signal) of the sine + modulation. + + Sets the frequency of the sine modulation added to the signal to modulate. + + + This is the signal which will be demodulated, in order to determine the + amplitude and phase at the frequency set in the Frequency field or harmonics, + such as current, bias, et.al. + + The number of signals which will be demodulated. @@ -53,7 +72,7 @@ signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) - + Switch the Sync filter on the demodulated signals (X,Y) on or off. (foreach DemodulatorChannels) @@ -70,10 +89,10 @@ Time during which the data are acquired and averaged. (for the input filter) - + - The number of order of the harmonic oscillation to detect on the demodulated - signals. (with respect to the modulation frequency) + The order of the harmonic oscillation to detect on the demodulated signals. + (with respect to the modulation frequency) diff --git a/contributed_definitions/nyaml/NXpositioner.nxdl.xml b/contributed_definitions/nyaml/NXpositioner.nxdl.xml new file mode 100644 index 0000000000..614316833b --- /dev/null +++ b/contributed_definitions/nyaml/NXpositioner.nxdl.xml @@ -0,0 +1,217 @@ + + + + + + A generic positioner such as a motor or piezo-electric transducer. + + + + symbolic or mnemonic name (one word) + + + + + description of positioner + + + + + best known value of positioner - need [n] as may be scanned + + + + + + + + raw value of positioner - need [n] as may be scanned + + + + + + + + targeted (commanded) value of positioner - need [n] as may be scanned + + + + + + + + maximum allowable difference between target_value and value + + + + + + + + minimum allowed limit to set value + + + + + maximum allowed limit to set value + + + + + velocity of the positioner (distance moved per unit time) + + + + + time to ramp the velocity up to full speed + + + + + Hardware device record, e.g. EPICS process variable, taco/tango ... + + + + + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + + + + + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a positioner. + + + + + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. + + + + + To clarify the frame laboratory frame. The scanning area in x, y, and z position + in the frame. + + + + + This controllers task is to continuously adjust the Z position of the stm tip in order to keep the selected control signal as close as possible to the Set Point. Different contro; signals lead to different contronller beahvior. + Z_offset(NX_NUMBER): + doc: Offset added to the initial averaged position Zaver before starting to swepp. + unit: NX_LENGTH + Tip_position_Z(NX_NUMBER): + doc: Indicate the tip position Z between tip and sample. The tip position can also be varied when the controller is not running. + unit: NX_LENGTH + Controller name(NX_CHAR): + doc: Controller name. This name which will be displayed at places where you can select a controller. + Setpoint(NX_NUMBER): + doc: Set Point is the desired value of the control signal. It can be set by editing the number or using the slider bar. Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. + unit: NX_CUTTENT + Setpoint unit(NX_CHAR): + doc: The unit of setpoint during the scanning. + P gain(NX_NUMBER): + dos: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. + unit: NX_LENGTH + I gain(NX_NUMBER): + dos: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. + unit: NX_ANY (NX_SPEED?) + Time const(NX_NUMBER): + dos: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. + unit: NX_TIME + TipLift(NX_NUMBER): + doc: Lifts the tip by the specified amount when then controller is switched off. This can be a positive or a negative number, i.e. the tip can also be moved towards the sample. Be careful with sign and value when using this feature. + unit: NX_LENGTH + Switch off delay(NX_NUMBER): + doc: Use this parameter for a reproducible position when switching off the Z-controller. When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. + unit: NX_TIME + Z-controller hold(NX_CHAR): + doc: (In biase spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. + + + + + To contron the tip and various scan operations. + scanfield(NX_NUMBER): + doc: Configure the scan frame: x position; y position; width; height. + unit: NX_LENGTH + pixels/line(NX_NUMBER): + doc: Scan resolution by setting the Lines equal to Pixels. + unit: NX_ANY + lines(NX_NUMBER): + doc: Define the image resolution. + unit: NX_ANY + speed forw.(NX_NUMBER): + doc: Define the scan forward speed in the forward direction. + unit: NX_ANY(NX_SPEED?) + speed backw.(NX_NUMBER): + doc: Define the scan backward speed in the forward direction. + unit: NX_ANY(NX_SPEED?) + + + + Piezo calibration module is used to define the X Y Z piezos calibration. + calibr(NX_NUMBER): + doc: There are 3 parameters in X, Y, and Z directions and there are 3 controls available: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. + unit: NX_ANY + Range(NX_NUMBER): + doc: Adjusts the amplitude range or amplitude of the Piezo output signal + unit: NX_LENGTH + HV Gain(NX_NUMBER): + doc: For some systems HV gain readout is available, so for those systems the HV gain should be adjusted automatically when the gain is changed at the high voltage amplifier. + unit: NX_ANY + Tilt(NX_NUMBER): + doc: There are 2 parameters in X and Y directions and this tab is used to set the sample tilt (in degrees, first order correction). + unit: NX_ANGLE + Curvature radius(NX_NUMBER): + doc: There are 2 parameters in X and Y directions and this tab is used to set a curvature (can be set approximately to the length of the piezotube). + unit: NX_LENGTH + 2nd order corr: + doc: There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2) + Drift(NX_NUMBER): + doc: There are 2 parameters in X and Y directions. Define the drift speed for all three axes. When the compensation is on, the piezos will start to move at that speed. + unit: NX_ANY (need NX_SPEED) + Drift correction status(NX_CHAR): + doc: Use the button to turn on/off the drift compensation. + + + + diff --git a/contributed_definitions/nyaml/NXpositioner.yaml b/contributed_definitions/nyaml/NXpositioner.yaml index f7cecf676b..8c08aad57f 100644 --- a/contributed_definitions/nyaml/NXpositioner.yaml +++ b/contributed_definitions/nyaml/NXpositioner.yaml @@ -90,8 +90,9 @@ NXpositioner(NXobject): doc: To clarify the frame laboratory frame. The scanning area in x, y, and z position in the frame. unit: NX_LENGTH Z_contronller: - doc: This controllers task is to continuously adjust the Z position of the stm-tip in order to keep the selected control signal as close as possible to the Set Point. Different contro; signals lead to different contronller beahvior. - Z-offset(NX_NUMBER): + doc: | + This controllers task is to continuously adjust the Z position of the stm tip in order to keep the selected control signal as close as possible to the Set Point. Different contro; signals lead to different contronller beahvior. + Z_offset(NX_NUMBER): doc: Offset added to the initial averaged position Zaver before starting to swepp. unit: NX_LENGTH Tip_position_Z(NX_NUMBER): @@ -122,8 +123,9 @@ NXpositioner(NXobject): Z-controller hold(NX_CHAR): doc: (In biase spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. Scan contronller: - doc: To contron the tip and various scan operations. - Scanfield(NX_NUMBER): + doc: | + To contron the tip and various scan operations. + scanfield(NX_NUMBER): doc: Configure the scan frame: x position; y position; width; height. unit: NX_LENGTH pixels/line(NX_NUMBER): @@ -139,28 +141,29 @@ NXpositioner(NXobject): doc: Define the scan backward speed in the forward direction. unit: NX_ANY(NX_SPEED?) Piezo_calibration: - doc: Piezo calibration module is used to define the X Y Z piezos calibration. - Calibr(NX_NUMBER): + doc: | + Piezo calibration module is used to define the X Y Z piezos calibration. + calibr(NX_NUMBER): doc: There are 3 parameters in X, Y, and Z directions and there are 3 controls available: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. unit: NX_ANY - Range(NX_NUMBER): + range(NX_NUMBER): doc: Adjusts the amplitude range or amplitude of the Piezo output signal unit: NX_LENGTH - HV Gain(NX_NUMBER): + HV_Gain(NX_NUMBER): doc: For some systems HV gain readout is available, so for those systems the HV gain should be adjusted automatically when the gain is changed at the high voltage amplifier. unit: NX_ANY - Tilt(NX_NUMBER): + tilt(NX_NUMBER): doc: There are 2 parameters in X and Y directions and this tab is used to set the sample tilt (in degrees, first order correction). unit: NX_ANGLE - Curvature radius(NX_NUMBER): + curvature radius(NX_NUMBER): doc: There are 2 parameters in X and Y directions and this tab is used to set a curvature (can be set approximately to the length of the piezotube). unit: NX_LENGTH 2nd order corr: doc: There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2) - Drift(NX_NUMBER): + drift(NX_NUMBER): doc: There are 2 parameters in X and Y directions. Define the drift speed for all three axes. When the compensation is on, the piezos will start to move at that speed. unit: NX_ANY (need NX_SPEED) - Drift correction status(NX_CHAR): + drift correction status(NX_CHAR): doc: Use the button to turn on/off the drift compensation. diff --git a/contributed_definitions/nyaml/NXsensor.nxdl.xml b/contributed_definitions/nyaml/NXsensor.nxdl.xml index ea5f295aa1..08fb5f76f9 100644 --- a/contributed_definitions/nyaml/NXsensor.nxdl.xml +++ b/contributed_definitions/nyaml/NXsensor.nxdl.xml @@ -209,4 +209,24 @@ other component groups. + + + External sensors connected to the device. For example, T1, temperature of STM + head. T2, temperature of bottom of LHe helium cryostat. T3, temperature of LN2 + nitrogen shield. + + + + + External sensors connected to the device. Pressure of each chamber or ion pump, + such as prepare chamber and analysis chamber + + + + + The power present in the signal as a function of frequency. Used to characterise + the vibration and noise of scanning probes to detect and reduce the impact on + resolution during STM imaging + + From 8e4960ad1104ed4f4b6294822864bf04b9e13a74 Mon Sep 17 00:00:00 2001 From: Yichen Date: Mon, 24 Apr 2023 18:14:07 +0200 Subject: [PATCH 0109/1012] test push --- .../nyaml/NXamplifier.yaml.bp | 34 +++ contributed_definitions/nyaml/NXbias.yaml.bp | 65 +++++ .../nyaml/NXcircuit.yaml.bp | 35 +++ .../nyaml/NXlockin.yaml.bp | 39 +++ .../nyaml/NXpositioner.nxdl.xml | 227 +++++++++++------- .../nyaml/NXpositioner.yaml | 153 ++++++------ .../nyaml/NXpositioner.yaml.bp | 181 ++++++++++++++ .../nyaml/NXpositioner.yaml.bp2 | 186 ++++++++++++++ .../nyaml/NXsensor.yaml.bp | 141 +++++++++++ 9 files changed, 906 insertions(+), 155 deletions(-) create mode 100644 contributed_definitions/nyaml/NXamplifier.yaml.bp create mode 100644 contributed_definitions/nyaml/NXbias.yaml.bp create mode 100644 contributed_definitions/nyaml/NXcircuit.yaml.bp create mode 100644 contributed_definitions/nyaml/NXlockin.yaml.bp create mode 100644 contributed_definitions/nyaml/NXpositioner.yaml.bp create mode 100644 contributed_definitions/nyaml/NXpositioner.yaml.bp2 create mode 100644 contributed_definitions/nyaml/NXsensor.yaml.bp diff --git a/contributed_definitions/nyaml/NXamplifier.yaml.bp b/contributed_definitions/nyaml/NXamplifier.yaml.bp new file mode 100644 index 0000000000..9a1bb41fa7 --- /dev/null +++ b/contributed_definitions/nyaml/NXamplifier.yaml.bp @@ -0,0 +1,34 @@ +doc: | + Application definition for amplifier devices. +category: base +NXamplifier: + hardware(NXfabrication): + doc: (IC, device) (NXmanufacturer?) + NumOfChannels(NX_NUMBER): + doc: The number of preamplifier channels are assgined. + ActiveChannels(NX_NUMBER): + doc: The number of preamplifier channels are ready tp to be used. (array for active channels) + openloop_amplification(NX_NUMBER): + doc: The output signal does not go through a feedback loop to adjust the amplification of the amplifier. (array for active channels) # From google. + amplification(NX_NUMBER): + doc: The ratio of the amplitude of the output signal to the amplitude of the input signal. (array for active channels) # From google. + signal_over_noise(NX_NUMBER): + doc: The ratio of the amplitue of the useful signal to the amplitude of the noise in the output signal of the amplifier. S/N=V_signal/V_noise. (array for active channels) + crosstalk_factor(NX_NUMBER): + doc: (if active >1) + crosstalk_compensation(NX_BOOLEAN): + bandwidth(NX_NUMBER): + doc: The spectrum of frequency it can amplify, from its lowest to highest frequency limits. + unit: NX_FREQUENCY + LowPass(NX_NUMBER): + doc: Order and cut-off frequency of the low-pass filter applied on the demodulated signals (X,Y). Cut-off frq (low pass filter) (foreach DemodulatorChannels) + unit: NX_FREQUENCY + HiPass(NX_NUMBER): + doc: Order and cut-off frequency of the high-pass filter applied on the demodulation signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) + unit: NX_FREQUENCY + type: + enumeration: [current, voltage] + Current amplifier factor(NX_NUMBER): + doc: (V/V) + Current amplifier Capacitive cross-talk compensation: + doc: diff --git a/contributed_definitions/nyaml/NXbias.yaml.bp b/contributed_definitions/nyaml/NXbias.yaml.bp new file mode 100644 index 0000000000..cb51529cb3 --- /dev/null +++ b/contributed_definitions/nyaml/NXbias.yaml.bp @@ -0,0 +1,65 @@ +doc: | + Application definition for bias devices. +category: base +NXbias(NXobject): + bias(NX_NUMBER): + doc: Applied a voltage between tip and sample. + unit: NX_VOLTAGE + tunneling resistor(NXcircuit): + doc: The ratio between the tunneling current at the sample surface and the bias voltage applied between between the sample and the tip. + unit: NX_ANY (No NX_resistance) + Calibration(NX_NUMBER): + doc: Calibration of the Bias output (V/V). + offset(NX_NUMBER): + doc: Allows compensating for an offset in Bias. Hardware parameter offset. + unit: NX_VOLTAGE + Modulated signal Bias(NXlockin): # or transfer it to NXlockin? + doc: Sets the amplitude (in physical units of the modulated signal) of the sine modulation. + unit: NX_VOLTAGE + Bias Spectroscopy(NXbias): + doc: Bias sweeps while measuring arbitrary channels with I(V) curves. + Channels(NX_CHAR): + doc: Select the channels to record. + Reset Bias(NX_CHAR): + doc: | + When selected, the Bias voltage returns to the initial value (before starting the sweep) at the end of the spectroscopy measurement (default). When not selected, Bias remains at the last value of the sweep. This is useful e.g. when combining several sweep segments. Example for an automated measurement (using Programming Interface): switch off Z-Controller, start spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, switch on Z-Controller. + Record final Z(NX_CHAR): + doc: Select whether to record the Z position during Z averaging time at the end of the sweep (after Z control time) and store the average value in the header of the file when saving. Using this option increases the sweep time by Z averaging time. + Lock-In run(NX_CHAR): + doc: Select whether to set the Lock-In to run during the measurement. When using this feature, make sure the Lock-In is configured correctly and settling times are set to twice the Lock-In period at least. This option is ignored when Lock-In is already running. This option is disabled if the Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline segment editor is set. + Number of sweeps(NX_NUMBER): + doc: Number of sweeps to measure and average. + Sweep Start(NX_NUMBER): + doc: The first bias values of the sweep. + unit: NX_VOLTAGE + Sweep End(NX_NUMBER): + doc: The last bias values of the sweep. + unit: NX_VOLTAGE + Num Pixel(NX_NUMBER): + doc: Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. + Z Avg time(NX_NUMBER): + doc: Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). + unit: NX_TIME + Z offset(NX_NUMBER): + doc: Offset added to the initial averaged position Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an alternate Z-controller setpoint is enabled. + unit: NX_LENGTH + Settling time(NX_NUMBER): + doc: time to wait after changing the bias to the next level and before starting to acquire data. + unit: NX_TIME + Integration time(NX_NUMBER): + doc: Time during which the data are acquired and averaged. + unit: NX_TIME + End Settling time(NX_NUMBER): + doc: Time to wait after the sweep has finished and the bias is ramped to the initial value. + unit: NX_TIME + Z control time(NX_NUMBER): + doc: Time during which the Z-Controller is enabled once a sweep has finished. When averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled for this duration between each sweep. After the last sweep, it will wait the specified time before continuing a running scan. This ensures each sweep reliably starts from the same position. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. + unit: NX_TIME + Max Slew rate(NX_NUMBER): + doc: Maximum rate at which the bias changes (before, during and after sweeping). (V/s) + backward sweep(NX_CHAR): + doc: Select whether to measure the backward (return) sweep or the forward only. + Z-controller hold(NX_CHAR): + doc: Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. + + diff --git a/contributed_definitions/nyaml/NXcircuit.yaml.bp b/contributed_definitions/nyaml/NXcircuit.yaml.bp new file mode 100644 index 0000000000..15e4dec7ac --- /dev/null +++ b/contributed_definitions/nyaml/NXcircuit.yaml.bp @@ -0,0 +1,35 @@ +doc: | + Application definition for circuit devices. +category: base +NXcircuit: + hardware(NX_FABRICATION): + doc: (NXmanufacturer?) + Tunneling Current(NX_NUMBER): + doc: The tunneling current between tip and sample after application of bias voltage. + unit: NX_CURRENT + Calibration(NX_NUMBER): + doc: Calibration of the current measurement (A/V). + Offset(NX_NUMBER): + doc: Offset of the current measurement. + unit: NX_CURRENT + channels(NX_CHAR): + doc: The scan channels are selected by users (in scan contronaller). + RT Frequency(NX_NUMBER): + doc: The bandwitdh of the Hardware and/or Software + unit: NX_FREQUENCY + Signals Oversampling(NX_NUMBER): + doc: (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. + unit: NX_ANY + Acquisition Period(NX_NUMBER): + doc: Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. + unit: NX_TIME + Animations Period(NX_NUMBER): + doc: Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. + unit: NX_TIME + Indicators Period(NX_NUMBER): + doc: Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. + unit: NX_TIME + Measurements Period(NX_NUMBER): + doc: The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. + unit: NX_TIME + diff --git a/contributed_definitions/nyaml/NXlockin.yaml.bp b/contributed_definitions/nyaml/NXlockin.yaml.bp new file mode 100644 index 0000000000..652cf1ac78 --- /dev/null +++ b/contributed_definitions/nyaml/NXlockin.yaml.bp @@ -0,0 +1,39 @@ +doc: | + Application definition for lock in devices. +category: base +NXlockin: + hardware(NXfabrication): + (NXamplifier): + doc: input and output amplifiers + Modulate signal(NX_CHAR): + doc: This is the signal on which the modulation (sine) will be added, such as current, bias, et.al. + Amplitude(NX_NUMBER): + doc: Sets the amplitude (in physical units of the modulated signal) of the sine modulation. + unit: NX_VOLTAGE (For bais modulate signal, it depands on the modulate type) + frequency(NX_NUMBER): + doc: Sets the frequency of the sine modulation added to the signal to modulate. + unit: NX_FREQUENCY + Demodulated signal(NX_CHAR): + doc: This is the signal which will be demodulated, in order to determine the amplitude and phase at the frequency set in the Frequency field or harmonics, such as current, bias, et.al. + #output (demodulated signal) characterisation (foreach channel, like demodulation, a separate sensor output, e.g. X,Y) + NumOfDemodulatorChannels(NX_NUMBER): + doc: The number of signals which will be demodulated. + LowPass(NX_NUMBER): + doc: Order and cut-off frequency of the low-pass filter applied on the demodulated signals (X,Y). Cut-off frq (low pass filter) (foreach DemodulatorChannels) + unit: NX_FREQUENCY + HiPass(NX_NUMBER): + doc: Order and cut-off frequency of the high-pass filter applied on the demodulation signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) + unit: NX_FREQUENCY + Sync(NX_CHAR): + doc: Switch the Sync filter on the demodulated signals (X,Y) on or off. (foreach DemodulatorChannels) + refPhase(NX_NUMBER): + doc: Reference phase for the sine on the demodulated signal with respect to the modulation signal. (foreach DemodulatorChannels) + unit: NX_FREQUENCY + integrationTime(NX_NUMBER): + doc: Time during which the data are acquired and averaged. (for the input filter) + unit: NX_TIME + OrderOfHarmonics(NX_NUMBER): + doc: The order of the harmonic oscillation to detect on the demodulated signals. (with respect to the modulation frequency) + sensitivityFactor(NX_NUMBER): + doc: Ratio of output signal amplitude to input signal amplitue (V/V). (input gain) # Not sure about it. + diff --git a/contributed_definitions/nyaml/NXpositioner.nxdl.xml b/contributed_definitions/nyaml/NXpositioner.nxdl.xml index 614316833b..022e4e3106 100644 --- a/contributed_definitions/nyaml/NXpositioner.nxdl.xml +++ b/contributed_definitions/nyaml/NXpositioner.nxdl.xml @@ -132,86 +132,151 @@ in the frame. - - - This controllers task is to continuously adjust the Z position of the stm tip in order to keep the selected control signal as close as possible to the Set Point. Different contro; signals lead to different contronller beahvior. - Z_offset(NX_NUMBER): - doc: Offset added to the initial averaged position Zaver before starting to swepp. - unit: NX_LENGTH - Tip_position_Z(NX_NUMBER): - doc: Indicate the tip position Z between tip and sample. The tip position can also be varied when the controller is not running. - unit: NX_LENGTH - Controller name(NX_CHAR): - doc: Controller name. This name which will be displayed at places where you can select a controller. - Setpoint(NX_NUMBER): - doc: Set Point is the desired value of the control signal. It can be set by editing the number or using the slider bar. Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. - unit: NX_CUTTENT - Setpoint unit(NX_CHAR): - doc: The unit of setpoint during the scanning. - P gain(NX_NUMBER): - dos: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. - unit: NX_LENGTH - I gain(NX_NUMBER): - dos: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. - unit: NX_ANY (NX_SPEED?) - Time const(NX_NUMBER): - dos: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. - unit: NX_TIME - TipLift(NX_NUMBER): - doc: Lifts the tip by the specified amount when then controller is switched off. This can be a positive or a negative number, i.e. the tip can also be moved towards the sample. Be careful with sign and value when using this feature. - unit: NX_LENGTH - Switch off delay(NX_NUMBER): - doc: Use this parameter for a reproducible position when switching off the Z-controller. When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. - unit: NX_TIME - Z-controller hold(NX_CHAR): - doc: (In biase spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. - - - - - To contron the tip and various scan operations. - scanfield(NX_NUMBER): - doc: Configure the scan frame: x position; y position; width; height. - unit: NX_LENGTH - pixels/line(NX_NUMBER): - doc: Scan resolution by setting the Lines equal to Pixels. - unit: NX_ANY - lines(NX_NUMBER): - doc: Define the image resolution. - unit: NX_ANY - speed forw.(NX_NUMBER): - doc: Define the scan forward speed in the forward direction. - unit: NX_ANY(NX_SPEED?) - speed backw.(NX_NUMBER): - doc: Define the scan backward speed in the forward direction. - unit: NX_ANY(NX_SPEED?) - - - - Piezo calibration module is used to define the X Y Z piezos calibration. - calibr(NX_NUMBER): - doc: There are 3 parameters in X, Y, and Z directions and there are 3 controls available: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. - unit: NX_ANY - Range(NX_NUMBER): - doc: Adjusts the amplitude range or amplitude of the Piezo output signal - unit: NX_LENGTH - HV Gain(NX_NUMBER): - doc: For some systems HV gain readout is available, so for those systems the HV gain should be adjusted automatically when the gain is changed at the high voltage amplifier. - unit: NX_ANY - Tilt(NX_NUMBER): - doc: There are 2 parameters in X and Y directions and this tab is used to set the sample tilt (in degrees, first order correction). - unit: NX_ANGLE - Curvature radius(NX_NUMBER): - doc: There are 2 parameters in X and Y directions and this tab is used to set a curvature (can be set approximately to the length of the piezotube). - unit: NX_LENGTH - 2nd order corr: - doc: There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2) - Drift(NX_NUMBER): - doc: There are 2 parameters in X and Y directions. Define the drift speed for all three axes. When the compensation is on, the piezos will start to move at that speed. - unit: NX_ANY (need NX_SPEED) - Drift correction status(NX_CHAR): - doc: Use the button to turn on/off the drift compensation. - - + + + Offset added to the initial averaged position Zaver before starting to swepp. + + + + + Indicate the tip position Z between tip and sample. The tip position can also be + varied when the controller is not running. + + + + + Controller name. This name which will be displayed at places where you can + select a controller. + + + + + Set Point is the desired value of the control signal. It can be set by editing + the number or using the slider bar. Click the "Set" button above the input field + to use the actual value as Set Point. The slider shows the Set Point as well as + the current value. + + + + + The unit of setpoint during the scanning. + + + + + The Type switches controller parameters between P/I (proportional gain/integral + gain) and P/T (proportional gain/time constant). The formula for the controller + in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral + gain and time constant are related as follows I = P/T. + + + + + The Type switches controller parameters between P/I (proportional gain/integral + gain) and P/T (proportional gain/time constant). The formula for the controller + in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and + time constant are related as follows I = P/T. + + + + + The Type switches controller parameters between P/I (proportional gain/integral + gain) and P/T (proportional gain/time constant). The formula for the controller + in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and + time constant are related as follows I = P/T. + + + + + Lifts the tip by the specified amount when then controller is switched off. This + can be a positive or a negative number, i.e. the tip can also be moved towards + the sample. Be careful with sign and value when using this feature. + + + + + Use this parameter for a reproducible position when switching off the + Z-controller. When >0 and the Z-controller is switched off, it doesn't switch + off immediately but continues to run for the specified time and averages the Z + position. + + + + + (In bias spectroscopy) Select whether to set the Z-Controller on hold (i.e. + disabled) during the sweep. It is selected by default. When deselected, Z-offset + and Z control time parameters are disabled. + + + + + Configure the scan frame like x position; y position; width; height. + + + + + Scan resolution by setting the Lines equal to Pixels. + + + + + Define the image resolution. + + + + + Define the scan forward speed in the forward direction. + + + + + Define the scan backward speed in the forward direction. + + + + + There are 3 parameters in X, Y, and Z directions and there are 3 controls available: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. + + + + + Adjusts the amplitude range or amplitude of the Piezo output signal + + + + + For some systems HV gain readout is available, so for those systems the HV gain + should be adjusted automatically when the gain is changed at the high voltage + amplifier. + + + + + There are 2 parameters in X and Y directions and this tab is used to set the + sample tilt (in degrees, first order correction). + + + + + There are 2 parameters in X and Y directions and this tab is used to set a + curvature (can be set approximately to the length of the piezotube). + + + + + There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2) + + + + + There are 2 parameters in X and Y directions. Define the drift speed for all + three axes. When the compensation is on, the piezos will start to move at that + speed. + + + + + Use the button to turn on/off the drift compensation. + diff --git a/contributed_definitions/nyaml/NXpositioner.yaml b/contributed_definitions/nyaml/NXpositioner.yaml index 8c08aad57f..4ef1de27fc 100644 --- a/contributed_definitions/nyaml/NXpositioner.yaml +++ b/contributed_definitions/nyaml/NXpositioner.yaml @@ -89,82 +89,87 @@ NXpositioner(NXobject): Position(NXtransformation): doc: To clarify the frame laboratory frame. The scanning area in x, y, and z position in the frame. unit: NX_LENGTH - Z_contronller: +#Z_contronller: +# Name: +# doc: | +# This controllers task is to continuously adjust the Z position of the stm tip in order to keep the selected control signal as close as possible to the Set Point. Different contro; signals lead to different contronller beahvior. + Z_offset(NX_NUMBER): + doc: Offset added to the initial averaged position Zaver before starting to swepp. + unit: NX_LENGTH + Tip_position_Z(NX_NUMBER): + doc: Indicate the tip position Z between tip and sample. The tip position can also be varied when the controller is not running. + unit: NX_LENGTH + Controller name(NX_CHAR): + doc: Controller name. This name which will be displayed at places where you can select a controller. + Setpoint(NX_NUMBER): + doc: Set Point is the desired value of the control signal. It can be set by editing the number or using the slider bar. Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. + unit: NX_CUTTENT + Setpoint unit(NX_CHAR): + doc: The unit of setpoint during the scanning. + P gain(NX_NUMBER): + doc: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows I = P/T. + unit: NX_LENGTH + I gain(NX_NUMBER): + doc: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows I = P/T. + unit: NX_ANY (NX_SPEED?) + Time const(NX_NUMBER): + doc: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows I = P/T. + unit: NX_TIME + TipLift(NX_NUMBER): + doc: Lifts the tip by the specified amount when then controller is switched off. This can be a positive or a negative number, i.e. the tip can also be moved towards the sample. Be careful with sign and value when using this feature. + unit: NX_LENGTH + Switch off delay(NX_NUMBER): + doc: Use this parameter for a reproducible position when switching off the Z-controller. When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. + unit: NX_TIME + Z-controller hold(NX_CHAR): + doc: (In bias spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. +#Scan contronller: +# name: +# doc: | +# To contron the tip and various scan operations. + scanfield(NX_NUMBER): + doc: Configure the scan frame like x position; y position; width; height. + unit: NX_LENGTH + pixels/line(NX_NUMBER): + doc: Scan resolution by setting the Lines equal to Pixels. + unit: NX_ANY + lines(NX_NUMBER): + doc: Define the image resolution. + unit: NX_ANY + speed forw.(NX_NUMBER): + doc: Define the scan forward speed in the forward direction. + unit: NX_ANY(NX_SPEED?) + speed backw.(NX_NUMBER): + doc: Define the scan backward speed in the forward direction. + unit: NX_ANY(NX_SPEED?) +#Piezo_calibration: +# name: +# doc: | +# Piezo calibration module is used to define the X Y Z piezos calibration. + calibr(NX_NUMBER): doc: | - This controllers task is to continuously adjust the Z position of the stm tip in order to keep the selected control signal as close as possible to the Set Point. Different contro; signals lead to different contronller beahvior. - Z_offset(NX_NUMBER): - doc: Offset added to the initial averaged position Zaver before starting to swepp. - unit: NX_LENGTH - Tip_position_Z(NX_NUMBER): - doc: Indicate the tip position Z between tip and sample. The tip position can also be varied when the controller is not running. - unit: NX_LENGTH - Controller name(NX_CHAR): - doc: Controller name. This name which will be displayed at places where you can select a controller. - Setpoint(NX_NUMBER): - doc: Set Point is the desired value of the control signal. It can be set by editing the number or using the slider bar. Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. - unit: NX_CUTTENT - Setpoint unit(NX_CHAR): - doc: The unit of setpoint during the scanning. - P gain(NX_NUMBER): - dos: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. - unit: NX_LENGTH - I gain(NX_NUMBER): - dos: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. - unit: NX_ANY (NX_SPEED?) - Time const(NX_NUMBER): - dos: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. - unit: NX_TIME - TipLift(NX_NUMBER): - doc: Lifts the tip by the specified amount when then controller is switched off. This can be a positive or a negative number, i.e. the tip can also be moved towards the sample. Be careful with sign and value when using this feature. - unit: NX_LENGTH - Switch off delay(NX_NUMBER): - doc: Use this parameter for a reproducible position when switching off the Z-controller. When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. - unit: NX_TIME - Z-controller hold(NX_CHAR): - doc: (In biase spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. - Scan contronller: + There are 3 parameters in X, Y, and Z directions and there are 3 controls available: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. + unit: NX_ANY + range(NX_NUMBER): + doc: Adjusts the amplitude range or amplitude of the Piezo output signal + unit: NX_LENGTH + HV_Gain(NX_NUMBER): + doc: For some systems HV gain readout is available, so for those systems the HV gain should be adjusted automatically when the gain is changed at the high voltage amplifier. + unit: NX_ANY + tilt(NX_NUMBER): + doc: There are 2 parameters in X and Y directions and this tab is used to set the sample tilt (in degrees, first order correction). + unit: NX_ANGLE + curvature radius(NX_NUMBER): + doc: There are 2 parameters in X and Y directions and this tab is used to set a curvature (can be set approximately to the length of the piezotube). + unit: NX_LENGTH + 2nd order corr: doc: | - To contron the tip and various scan operations. - scanfield(NX_NUMBER): - doc: Configure the scan frame: x position; y position; width; height. - unit: NX_LENGTH - pixels/line(NX_NUMBER): - doc: Scan resolution by setting the Lines equal to Pixels. - unit: NX_ANY - lines(NX_NUMBER): - doc: Define the image resolution. - unit: NX_ANY - speed forw.(NX_NUMBER): - doc: Define the scan forward speed in the forward direction. - unit: NX_ANY(NX_SPEED?) - speed backw.(NX_NUMBER): - doc: Define the scan backward speed in the forward direction. - unit: NX_ANY(NX_SPEED?) - Piezo_calibration: - doc: | - Piezo calibration module is used to define the X Y Z piezos calibration. - calibr(NX_NUMBER): - doc: There are 3 parameters in X, Y, and Z directions and there are 3 controls available: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. - unit: NX_ANY - range(NX_NUMBER): - doc: Adjusts the amplitude range or amplitude of the Piezo output signal - unit: NX_LENGTH - HV_Gain(NX_NUMBER): - doc: For some systems HV gain readout is available, so for those systems the HV gain should be adjusted automatically when the gain is changed at the high voltage amplifier. - unit: NX_ANY - tilt(NX_NUMBER): - doc: There are 2 parameters in X and Y directions and this tab is used to set the sample tilt (in degrees, first order correction). - unit: NX_ANGLE - curvature radius(NX_NUMBER): - doc: There are 2 parameters in X and Y directions and this tab is used to set a curvature (can be set approximately to the length of the piezotube). - unit: NX_LENGTH - 2nd order corr: - doc: There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2) - drift(NX_NUMBER): - doc: There are 2 parameters in X and Y directions. Define the drift speed for all three axes. When the compensation is on, the piezos will start to move at that speed. - unit: NX_ANY (need NX_SPEED) - drift correction status(NX_CHAR): - doc: Use the button to turn on/off the drift compensation. + There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2) + drift(NX_NUMBER): + doc: There are 2 parameters in X and Y directions. Define the drift speed for all three axes. When the compensation is on, the piezos will start to move at that speed. + unit: NX_ANY (need NX_SPEED) + drift correction status(NX_CHAR): + doc: Use the button to turn on/off the drift compensation. diff --git a/contributed_definitions/nyaml/NXpositioner.yaml.bp b/contributed_definitions/nyaml/NXpositioner.yaml.bp new file mode 100644 index 0000000000..8c08aad57f --- /dev/null +++ b/contributed_definitions/nyaml/NXpositioner.yaml.bp @@ -0,0 +1,181 @@ +category: base +doc: | + A generic positioner such as a motor or piezo-electric transducer. + +type: group +NXpositioner(NXobject): + name: + doc: | + symbolic or mnemonic name (one word) + description: + doc: | + description of positioner + value(NX_NUMBER): + unit: NX_ANY + doc: | + best known value of positioner - need [n] as may be scanned + dimensions: + rank: 1 + dim: [[1, n]] + raw_value(NX_NUMBER): + unit: NX_ANY + doc: | + raw value of positioner - need [n] as may be scanned + dimensions: + rank: 1 + dim: [[1, n]] + target_value(NX_NUMBER): + unit: NX_ANY + doc: | + targeted (commanded) value of positioner - need [n] as may be scanned + dimensions: + rank: 1 + dim: [[1, n]] + tolerance(NX_NUMBER): + unit: NX_ANY + doc: | + maximum allowable difference between target_value and value + dimensions: + rank: 1 + dim: [[1, n]] + soft_limit_min(NX_NUMBER): + unit: NX_ANY + doc: | + minimum allowed limit to set value + soft_limit_max(NX_NUMBER): + unit: NX_ANY + doc: | + maximum allowed limit to set value + velocity(NX_NUMBER): + unit: NX_ANY + doc: | + velocity of the positioner (distance moved per unit time) + acceleration_time(NX_NUMBER): + unit: NX_ANY + doc: | + time to ramp the velocity up to full speed + controller_record: + doc: | + Hardware device record, e.g. EPICS process variable, taco/tango ... + \@default: + doc: | + .. index':'':' plotting + + Declares which child group contains a path leading + to a ':'ref':'`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https':'//www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo':'':' + Add a definition for the reference point of a positioner. + (NXtransformations): + doc: | + 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. + + Position(NXtransformation): + doc: To clarify the frame laboratory frame. The scanning area in x, y, and z position in the frame. + unit: NX_LENGTH + Z_contronller: + doc: | + This controllers task is to continuously adjust the Z position of the stm tip in order to keep the selected control signal as close as possible to the Set Point. Different contro; signals lead to different contronller beahvior. + Z_offset(NX_NUMBER): + doc: Offset added to the initial averaged position Zaver before starting to swepp. + unit: NX_LENGTH + Tip_position_Z(NX_NUMBER): + doc: Indicate the tip position Z between tip and sample. The tip position can also be varied when the controller is not running. + unit: NX_LENGTH + Controller name(NX_CHAR): + doc: Controller name. This name which will be displayed at places where you can select a controller. + Setpoint(NX_NUMBER): + doc: Set Point is the desired value of the control signal. It can be set by editing the number or using the slider bar. Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. + unit: NX_CUTTENT + Setpoint unit(NX_CHAR): + doc: The unit of setpoint during the scanning. + P gain(NX_NUMBER): + dos: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. + unit: NX_LENGTH + I gain(NX_NUMBER): + dos: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. + unit: NX_ANY (NX_SPEED?) + Time const(NX_NUMBER): + dos: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. + unit: NX_TIME + TipLift(NX_NUMBER): + doc: Lifts the tip by the specified amount when then controller is switched off. This can be a positive or a negative number, i.e. the tip can also be moved towards the sample. Be careful with sign and value when using this feature. + unit: NX_LENGTH + Switch off delay(NX_NUMBER): + doc: Use this parameter for a reproducible position when switching off the Z-controller. When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. + unit: NX_TIME + Z-controller hold(NX_CHAR): + doc: (In biase spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. + Scan contronller: + doc: | + To contron the tip and various scan operations. + scanfield(NX_NUMBER): + doc: Configure the scan frame: x position; y position; width; height. + unit: NX_LENGTH + pixels/line(NX_NUMBER): + doc: Scan resolution by setting the Lines equal to Pixels. + unit: NX_ANY + lines(NX_NUMBER): + doc: Define the image resolution. + unit: NX_ANY + speed forw.(NX_NUMBER): + doc: Define the scan forward speed in the forward direction. + unit: NX_ANY(NX_SPEED?) + speed backw.(NX_NUMBER): + doc: Define the scan backward speed in the forward direction. + unit: NX_ANY(NX_SPEED?) + Piezo_calibration: + doc: | + Piezo calibration module is used to define the X Y Z piezos calibration. + calibr(NX_NUMBER): + doc: There are 3 parameters in X, Y, and Z directions and there are 3 controls available: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. + unit: NX_ANY + range(NX_NUMBER): + doc: Adjusts the amplitude range or amplitude of the Piezo output signal + unit: NX_LENGTH + HV_Gain(NX_NUMBER): + doc: For some systems HV gain readout is available, so for those systems the HV gain should be adjusted automatically when the gain is changed at the high voltage amplifier. + unit: NX_ANY + tilt(NX_NUMBER): + doc: There are 2 parameters in X and Y directions and this tab is used to set the sample tilt (in degrees, first order correction). + unit: NX_ANGLE + curvature radius(NX_NUMBER): + doc: There are 2 parameters in X and Y directions and this tab is used to set a curvature (can be set approximately to the length of the piezotube). + unit: NX_LENGTH + 2nd order corr: + doc: There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2) + drift(NX_NUMBER): + doc: There are 2 parameters in X and Y directions. Define the drift speed for all three axes. When the compensation is on, the piezos will start to move at that speed. + unit: NX_ANY (need NX_SPEED) + drift correction status(NX_CHAR): + doc: Use the button to turn on/off the drift compensation. + + + + + + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXpositioner.yaml.bp2 b/contributed_definitions/nyaml/NXpositioner.yaml.bp2 new file mode 100644 index 0000000000..4ef1de27fc --- /dev/null +++ b/contributed_definitions/nyaml/NXpositioner.yaml.bp2 @@ -0,0 +1,186 @@ +category: base +doc: | + A generic positioner such as a motor or piezo-electric transducer. + +type: group +NXpositioner(NXobject): + name: + doc: | + symbolic or mnemonic name (one word) + description: + doc: | + description of positioner + value(NX_NUMBER): + unit: NX_ANY + doc: | + best known value of positioner - need [n] as may be scanned + dimensions: + rank: 1 + dim: [[1, n]] + raw_value(NX_NUMBER): + unit: NX_ANY + doc: | + raw value of positioner - need [n] as may be scanned + dimensions: + rank: 1 + dim: [[1, n]] + target_value(NX_NUMBER): + unit: NX_ANY + doc: | + targeted (commanded) value of positioner - need [n] as may be scanned + dimensions: + rank: 1 + dim: [[1, n]] + tolerance(NX_NUMBER): + unit: NX_ANY + doc: | + maximum allowable difference between target_value and value + dimensions: + rank: 1 + dim: [[1, n]] + soft_limit_min(NX_NUMBER): + unit: NX_ANY + doc: | + minimum allowed limit to set value + soft_limit_max(NX_NUMBER): + unit: NX_ANY + doc: | + maximum allowed limit to set value + velocity(NX_NUMBER): + unit: NX_ANY + doc: | + velocity of the positioner (distance moved per unit time) + acceleration_time(NX_NUMBER): + unit: NX_ANY + doc: | + time to ramp the velocity up to full speed + controller_record: + doc: | + Hardware device record, e.g. EPICS process variable, taco/tango ... + \@default: + doc: | + .. index':'':' plotting + + Declares which child group contains a path leading + to a ':'ref':'`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https':'//www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo':'':' + Add a definition for the reference point of a positioner. + (NXtransformations): + doc: | + 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. + + Position(NXtransformation): + doc: To clarify the frame laboratory frame. The scanning area in x, y, and z position in the frame. + unit: NX_LENGTH +#Z_contronller: +# Name: +# doc: | +# This controllers task is to continuously adjust the Z position of the stm tip in order to keep the selected control signal as close as possible to the Set Point. Different contro; signals lead to different contronller beahvior. + Z_offset(NX_NUMBER): + doc: Offset added to the initial averaged position Zaver before starting to swepp. + unit: NX_LENGTH + Tip_position_Z(NX_NUMBER): + doc: Indicate the tip position Z between tip and sample. The tip position can also be varied when the controller is not running. + unit: NX_LENGTH + Controller name(NX_CHAR): + doc: Controller name. This name which will be displayed at places where you can select a controller. + Setpoint(NX_NUMBER): + doc: Set Point is the desired value of the control signal. It can be set by editing the number or using the slider bar. Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. + unit: NX_CUTTENT + Setpoint unit(NX_CHAR): + doc: The unit of setpoint during the scanning. + P gain(NX_NUMBER): + doc: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows I = P/T. + unit: NX_LENGTH + I gain(NX_NUMBER): + doc: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows I = P/T. + unit: NX_ANY (NX_SPEED?) + Time const(NX_NUMBER): + doc: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows I = P/T. + unit: NX_TIME + TipLift(NX_NUMBER): + doc: Lifts the tip by the specified amount when then controller is switched off. This can be a positive or a negative number, i.e. the tip can also be moved towards the sample. Be careful with sign and value when using this feature. + unit: NX_LENGTH + Switch off delay(NX_NUMBER): + doc: Use this parameter for a reproducible position when switching off the Z-controller. When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. + unit: NX_TIME + Z-controller hold(NX_CHAR): + doc: (In bias spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. +#Scan contronller: +# name: +# doc: | +# To contron the tip and various scan operations. + scanfield(NX_NUMBER): + doc: Configure the scan frame like x position; y position; width; height. + unit: NX_LENGTH + pixels/line(NX_NUMBER): + doc: Scan resolution by setting the Lines equal to Pixels. + unit: NX_ANY + lines(NX_NUMBER): + doc: Define the image resolution. + unit: NX_ANY + speed forw.(NX_NUMBER): + doc: Define the scan forward speed in the forward direction. + unit: NX_ANY(NX_SPEED?) + speed backw.(NX_NUMBER): + doc: Define the scan backward speed in the forward direction. + unit: NX_ANY(NX_SPEED?) +#Piezo_calibration: +# name: +# doc: | +# Piezo calibration module is used to define the X Y Z piezos calibration. + calibr(NX_NUMBER): + doc: | + There are 3 parameters in X, Y, and Z directions and there are 3 controls available: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. + unit: NX_ANY + range(NX_NUMBER): + doc: Adjusts the amplitude range or amplitude of the Piezo output signal + unit: NX_LENGTH + HV_Gain(NX_NUMBER): + doc: For some systems HV gain readout is available, so for those systems the HV gain should be adjusted automatically when the gain is changed at the high voltage amplifier. + unit: NX_ANY + tilt(NX_NUMBER): + doc: There are 2 parameters in X and Y directions and this tab is used to set the sample tilt (in degrees, first order correction). + unit: NX_ANGLE + curvature radius(NX_NUMBER): + doc: There are 2 parameters in X and Y directions and this tab is used to set a curvature (can be set approximately to the length of the piezotube). + unit: NX_LENGTH + 2nd order corr: + doc: | + There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2) + drift(NX_NUMBER): + doc: There are 2 parameters in X and Y directions. Define the drift speed for all three axes. When the compensation is on, the piezos will start to move at that speed. + unit: NX_ANY (need NX_SPEED) + drift correction status(NX_CHAR): + doc: Use the button to turn on/off the drift compensation. + + + + + + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXsensor.yaml.bp b/contributed_definitions/nyaml/NXsensor.yaml.bp new file mode 100644 index 0000000000..9284f54c59 --- /dev/null +++ b/contributed_definitions/nyaml/NXsensor.yaml.bp @@ -0,0 +1,141 @@ +category: base +doc: | + A sensor used to monitor an external condition + + The condition itself is described in ':'ref':'`NXenvironment`. + +type: group +NXsensor(NXobject): + model: + doc: | + Sensor identification code/model number + name: + doc: | + Name for the sensor + short_name: + doc: | + Short name of sensor used e.g. on monitor display program + attached_to: + doc: | + where sensor is attached to ("sample" | "can") + geometry(NXgeometry): + deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the beamstop and NXoff_geometry to describe its shape instead + doc: | + Defines the axes for logged vector quantities if they are not the global instrument axes. + measurement: + doc: | + name for measured signal + enumeration: [temperature, pH, magnetic_field, electric_field, conductivity, resistance, voltage, current, pressure, flow, stress, strain, shear, surface_pressure] + type: + doc: | + The type of hardware used for the measurement. + Examples (suggestions but not restrictions)':' + + ':'Temperature':' + J | K | T | E | R | S | Pt100 | Pt1000 | Rh/Fe + ':'pH':' + Hg/Hg2Cl2 | Ag/AgCl | ISFET + ':'Ion selective electrode':' + specify species; e.g. Ca2+ + ':'Magnetic field':' + Hall + ':'Surface pressure':' + wilhelmy plate + amplifier(NXamplifier): + second_amplifier(NX_circuit): + doc: link to second amplifer circuit with 1MOhm + run_control(NX_BOOLEAN): + doc: | + Is data collection controlled or synchronised to this quantity':' + 1=no, 0=to "value", 1=to "value_deriv1", etc. + high_trip_value(NX_FLOAT): + unit: NX_ANY + doc: | + Upper control bound of sensor reading if using run_control + low_trip_value(NX_FLOAT): + unit: NX_ANY + doc: | + Lower control bound of sensor reading if using run_control + value(NX_FLOAT): + unit: NX_ANY + doc: | + nominal setpoint or average value + - need [n] as may be a vector + dimensions: + dim: [[1, n]] + value_deriv1(NX_FLOAT): + unit: NX_ANY + doc: | + Nominal/average first derivative of value + e.g. strain rate + - same dimensions as "value" (may be a vector) + dimensions: + dim: [[1, ]] + dim_parameters: + ref: ['value'] + value_deriv2(NX_FLOAT): + unit: NX_ANY + doc: | + Nominal/average second derivative of value + - same dimensions as "value" (may be a vector) + dimensions: + dim: [[1, ]] + dim_parameters: + ref: ['value'] + value_log(NXlog): + doc: | + Time history of sensor readings + value_deriv1_log(NXlog): + doc: | + Time history of first derivative of sensor readings + value_deriv2_log(NXlog): + doc: | + Time history of second derivative of sensor readings + external_field_brief: + enumeration: [along beam, across beam, transverse, solenoidal, flow shear gradient, flow vorticity] + external_field_full(NXorientation): + doc: | + For complex external fields not satisfied by External_field_brief + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the sensor when necessary. + \@default: + doc: | + .. index':'':' plotting + + Declares which child group contains a path leading + to a ':'ref':'`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https':'//www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo':'':' + Add a definition for the reference point of a sensor. + (NXtransformations): + doc: | + 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. + ############## + Temperature(NX_sensor): + doc: External sensors connected to the device. For example, T1, temperature of STM head. T2, temperature of bottom of LHe helium cryostat. T3, temperature of LN2 nitrogen shield. + unit: NX_TEMPERATURE + Pressure(NX_sensor): + doc: External sensors connected to the device. Pressure of each chamber or ion pump, such as prepare chamber and analysis chamber + unit: NX_PRESSURE + Power Spectral Density (NX_sensor): + doc: The power present in the signal as a function of frequency. Used to characterise the vibration and noise of scanning probes to detect and reduce the impact on resolution during STM imaging + + From 79dc804fac799baf852c0b9d043ae7326a8bc1f0 Mon Sep 17 00:00:00 2001 From: Rubel Date: Wed, 14 Jun 2023 10:42:48 +0200 Subject: [PATCH 0110/1012] fix conflict in rebase --- .../nyaml/NXpositioner.yaml | 38 +++++++++++++++++++ 1 file changed, 38 insertions(+) diff --git a/contributed_definitions/nyaml/NXpositioner.yaml b/contributed_definitions/nyaml/NXpositioner.yaml index 4ef1de27fc..86a018d211 100644 --- a/contributed_definitions/nyaml/NXpositioner.yaml +++ b/contributed_definitions/nyaml/NXpositioner.yaml @@ -89,6 +89,7 @@ NXpositioner(NXobject): Position(NXtransformation): doc: To clarify the frame laboratory frame. The scanning area in x, y, and z position in the frame. unit: NX_LENGTH +<<<<<<< HEAD #Z_contronller: # Name: # doc: | @@ -163,6 +164,43 @@ NXpositioner(NXobject): doc: There are 2 parameters in X and Y directions and this tab is used to set a curvature (can be set approximately to the length of the piezotube). unit: NX_LENGTH 2nd order corr: +======= + Z_contronller: + name: + doc: | + This controllers task is to continuously adjust the Z position of the stm tip in order to keep the selected control signal as close as possible to the Set Point. Different contro; signals lead to different contronller beahvior. + Z_offset(NX_NUMBER): + doc: Offset added to the initial averaged position Zaver before starting to swepp. + unit: NX_LENGTH + Tip_position_Z(NX_NUMBER): + doc: Indicate the tip position Z between tip and sample. The tip position can also be varied when the controller is not running. + unit: NX_LENGTH + Controller name(NX_CHAR): + doc: Controller name. This name which will be displayed at places where you can select a controller. + Setpoint(NX_NUMBER): + doc: Set Point is the desired value of the control signal. It can be set by editing the number or using the slider bar. Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. + unit: NX_CUTTENT + Setpoint unit(NX_CHAR): + doc: The unit of setpoint during the scanning. + P gain(NX_NUMBER): + doc: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. + unit: NX_LENGTH + I gain(NX_NUMBER): + doc: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. + unit: NX_ANY (NX_SPEED?) + Time const(NX_NUMBER): + dos: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. + unit: NX_TIME + TipLift(NX_NUMBER): + doc: Lifts the tip by the specified amount when then controller is switched off. This can be a positive or a negative number, i.e. the tip can also be moved towards the sample. Be careful with sign and value when using this feature. + unit: NX_LENGTH + Switch off delay(NX_NUMBER): + doc: Use this parameter for a reproducible position when switching off the Z-controller. When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. + unit: NX_TIME + Z-controller hold(NX_CHAR): + doc: (In biase spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. + Scan contronller: +>>>>>>> 3637da15 (Update NXpositioner.yaml) doc: | There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2) drift(NX_NUMBER): From 3e81ee252476ffc51e4ece313d6ac4cef80461c7 Mon Sep 17 00:00:00 2001 From: Rubel Date: Wed, 14 Jun 2023 10:49:19 +0200 Subject: [PATCH 0111/1012] fix conflict in rebase --- .../nyaml/NXpositioner.yaml | 34 ++----------------- 1 file changed, 2 insertions(+), 32 deletions(-) diff --git a/contributed_definitions/nyaml/NXpositioner.yaml b/contributed_definitions/nyaml/NXpositioner.yaml index 86a018d211..25441ef5b3 100644 --- a/contributed_definitions/nyaml/NXpositioner.yaml +++ b/contributed_definitions/nyaml/NXpositioner.yaml @@ -89,7 +89,7 @@ NXpositioner(NXobject): Position(NXtransformation): doc: To clarify the frame laboratory frame. The scanning area in x, y, and z position in the frame. unit: NX_LENGTH -<<<<<<< HEAD + #Z_contronller: # Name: # doc: | @@ -148,23 +148,7 @@ NXpositioner(NXobject): # doc: | # Piezo calibration module is used to define the X Y Z piezos calibration. calibr(NX_NUMBER): - doc: | - There are 3 parameters in X, Y, and Z directions and there are 3 controls available: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. - unit: NX_ANY - range(NX_NUMBER): - doc: Adjusts the amplitude range or amplitude of the Piezo output signal - unit: NX_LENGTH - HV_Gain(NX_NUMBER): - doc: For some systems HV gain readout is available, so for those systems the HV gain should be adjusted automatically when the gain is changed at the high voltage amplifier. - unit: NX_ANY - tilt(NX_NUMBER): - doc: There are 2 parameters in X and Y directions and this tab is used to set the sample tilt (in degrees, first order correction). - unit: NX_ANGLE - curvature radius(NX_NUMBER): - doc: There are 2 parameters in X and Y directions and this tab is used to set a curvature (can be set approximately to the length of the piezotube). - unit: NX_LENGTH - 2nd order corr: -======= + Z_contronller: name: doc: | @@ -200,7 +184,6 @@ NXpositioner(NXobject): Z-controller hold(NX_CHAR): doc: (In biase spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. Scan contronller: ->>>>>>> 3637da15 (Update NXpositioner.yaml) doc: | There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2) drift(NX_NUMBER): @@ -209,16 +192,3 @@ NXpositioner(NXobject): drift correction status(NX_CHAR): doc: Use the button to turn on/off the drift compensation. - - - - - - - - - - - - - From e37397ebb223008ea3e076f5d1c762925a1050bf Mon Sep 17 00:00:00 2001 From: Yichen Date: Tue, 25 Apr 2023 14:12:53 +0200 Subject: [PATCH 0112/1012] Create NXiv_sweep2.yaml.bp --- .../nyaml/NXiv_sweep2.yaml.bp | 270 ++++++++++++++++++ 1 file changed, 270 insertions(+) create mode 100644 contributed_definitions/nyaml/NXiv_sweep2.yaml.bp diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml.bp b/contributed_definitions/nyaml/NXiv_sweep2.yaml.bp new file mode 100644 index 0000000000..6394585fd9 --- /dev/null +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml.bp @@ -0,0 +1,270 @@ +doc: | + Application definition for temperature-dependent IV curve measurements, #CAP with a focus on bias spectroscopy in scanning tunneling microscopy. + + In this application definition, times should be specified always together + with an UTC offset. + + This is the application definition describing temperature (T) dependent current voltage (IV) curve + measurements. For this a temperature is set. After reaching the temperature, + a voltage sweep is performed. For each voltage a current is measured. + Then, the next desired temperature is set and an IV measurement is performed. + #CAP the X, Y, Z, position of the probes or tip can be defined. #CAP The data can be visualized in a tensor with: + I (NXsensor_C, NXsoftware_Read_offset, NXcircuit) + parameters: + V has (NXsource+offset, NXsoftware_Scan_offset, NXsensor_V, NXcircuit) + T has (NXsource, NXsoftware_Scan_offset, NXsensor_T) + x has (NXsoftware_Scan_offset) + y has (NXsoftware_Scan_offset) + z has (NXsoftware_Scan_offset) +category: application +NXiv_sweep2(NXsensor_scan): + (NXentry): + definition(NX_CHAR): + enumeration: [NXiv_sweep2] + (NXinstrument): + Hardware: + doc: the name of the instrument device used.... + (NXenvironment): + doc: | + Describes an environment setup for a temperature-dependent IV measurement experiment. + + The temperature and voltage must be present as independently scanned controllers and + the current sensor must also be present with its readings. + voltage_controller(NXsensor): + temperature_controller(NXsensor): + current_sensor(NXsensor): + (NXdata): + doc: | + This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. + There should also be two more fields called temperature and voltage containing the setpoint values. + There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension + equal to the number of voltage setpoints. + + + + (file)type [background, reference, sample] + finename -> description (e.g. 221122_Au_5K00014) + series name -> description? Scan>series name 221122_Au_5K + session path (ELN?!)-> NanonisMain>Session Path C:\Users\SPM-PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis-Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711 + description: Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, locked Au(111), 50pA, 100 mV set point, 1mV DCA, 973Hz,138 1st H, -84 2nd H + INSTRUMENT + Hardware: Nanonis BP5e + Software: SoftwareMain>SW Version Generic 5e -- SoftwareMain>UI Release 10771 -- SoftwareMain>RT Release 10771 + Current amplifier (NXamplifier) + Current amplifier> hardware: CreaTec GmbH + Current amplifier> factor (V/V): 1E-10 + Current amplifier> Capacitive cross-talk compensation: Yes/No + + Lock-in>Lock-in status ON # ON/OFF of Lock-in amplifier + Lock in (optional) (NXlockin) + Lock-in Amplifier>Yes/No # If a lock-in amplifier employed to filter or obtain the electronic derivatives dI/dV of the signal + Lock-in Amplifier>Hardware: Nanonis + if Lock-in -- Bias Divider 1/10 or 1/100 # if the modulation + + Bias Spectroscopy>Channels Current (A);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A) # Select the channels to record. + Bias Spectroscopy>Reset Bias TRUE # When selected, the Bias voltage returns to the initial value (before starting the sweep) at the end of the spectroscopy measurement (default). When not selected, Bias remains at the last value of the sweep. This is useful e.g. when combining several sweep segments. Example for an automated measurement (using Programming Interface): switch off Z-Controller, start spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, switch on Z-Controller. + Bias Spectroscopy>Record final Z FALSE # Select whether to record the Z position during Z averaging time at the end of the sweep (after Z control time) and store the average value in the header of the file when saving. Using this option increases the sweep time by Z averaging time. + Bias Spectroscopy>Lock-In run FALSE # Select whether to set the Lock-In to run during the measurement. When using this feature, make sure the Lock-In is configured correctly and settling times are set to twice the Lock-In period at least. This option is ignored when Lock-In is already running. This option is disabled if the Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline segment editor is set. + Lock-in>Modulated signal Bias (V) # This is the signal on which the modulation (sine) will be added. + Lock-in>Frequency (Hz) 973E+0 # Sets the frequency of the sine modulation added to the signal to modulate. The frequency range is from 10 mHz to 40 kHz (corresponding to the SC5 output filter cut-off). When working with harmonics, make sure the harmonic frequencies don’t exceed ~100 kHz (SC5 input filter cut-off). Remember the SC5 hardware filters will affect the amplitude when getting close to their cut-off frequencies. + Lock-in>Amplitude 2E-3 # Sets the amplitude (in physical units of the modulated signal) of the sine modulation. + Lock-in>Demodulated signal Current (A) # This is the signal which will be demodulated, in order to determine the amplitude and phase at the frequency set in the Frequency field (“4”) or harmonics. + Lock-in>Harmonic D1 1 # Order of the harmonic oscillation to detect on the demodulated signal (with respect to the modulation frequency). If you work with higher harmonics make sure the frequency does not exceed the analog signal bandwidth (100 kHz). + Lock-in>Harmonic D2 2 # See below. + Lock-in>Reference phase D1 (deg) 137.597E+0 # Reference phase for the sine on the demodulated signal with respect to the modulation signal. The determined phase (phi) is displayed with respect to the reference phase. + Lock-in>Reference phase D2 (deg) -83.6562E+0 # See below. + + Bias: Tip bias/Sample bias # If the spectroscopy V bias is applied to the + Modulated signal Bias (V) 1E-3 # Applied modulation to the bias voltage. + ModulationBias> Tip bias/Sample bias + STM head + temp Temperature 1 (K) 4.92997E+0 # Temperature of STM head. + Cryo + bottom_temp Temperature 2 (K) - # Temperature of bottom of LHe helium cryostat. + shield_temp Temperature 3 (K) - # Temperature of LN2 nitrogen shield. + Cabling & Config + Outputs>Output 0 Mode User Output + Outputs>Output 1 Mode User Output + Outputs>Output 2 Mode User Output + Outputs>Output 3 Mode User Output + Outputs>Output 4 Mode User Output + Outputs>Output 5 Mode User Output + Outputs>Output 6 Mode User Output + Outputs>Output 7 Mode User Output + Outputs>Output 0 Value 0E+0 + Outputs>Output 1 Value 0E+0 + Outputs>Output 2 Value 0E+0 + Outputs>Output 3 Value 2.5539E+0 + Outputs>Output 4 Value 0E+0 + Outputs>Output 5 Value 0E+0 + Outputs>Output 6 Value 0E+0 + Outputs>Output 7 Value 0E+0 + Outputs>Output 0 Name Input 24 (V) + Outputs>Output 1 Name Bias (V) + Outputs>Output 2 Name Output 2 (V) + Outputs>Output 3 Name T1 Supply voltage (V) + Outputs>Output 4 Name Output 4 (V) + Outputs>Output 5 Name X (m) + Outputs>Output 6 Name Y (m) + Outputs>Output 7 Name Z (m) + Outputs>Output 0 Slew Rate Inf + Outputs>Output 1 Slew Rate Inf + Outputs>Output 2 Slew Rate Inf + Outputs>Output 3 Slew Rate Inf + Outputs>Output 4 Slew Rate Inf + Outputs>Output 5 Slew Rate Inf + Outputs>Output 6 Slew Rate Inf + Outputs>Output 7 Slew Rate Inf + Piezo Config + Piezo Configuration>Active Calib. LHe # Tne name of caliberation type. + Piezo Configuration>Calib. X (m/V) 3.8E-9 # There are 3 controls available: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. + Piezo Configuration>Calib. Y (m/V) 3.8E-9 # See below. + Piezo Configuration>Calib. Z (m/V) 900E-12 # See below. + Piezo Configuration>HV Gain X 14.5 # For some systems HV gain readout is available, so for those systems the HV gain should be adjusted automatically when the gain is changed at the high voltage amplifier. + Piezo Configuration>HV Gain Y 14.5 # See below. + Piezo Configuration>HV Gain Z 14.5 # See below. + Piezo Configuration>Tilt X (deg) 0.318343 # This tab is used to set the sample tilt (in degrees, first order correction). + Piezo Configuration>Tilt Y (deg) 1.584 # See below. + Piezo Configuration>Curvature radius X (m) Inf # This tab is used to set a curvature (can be set approximately to the length of the piezotube). + Piezo Configuration>Curvature radius Y (m) Inf # See below. + Piezo Configuration>2nd order corr X (V/m^2) 0E+0 # If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. + Piezo Configuration>2nd order corr Y (V/m^2) 0E+0 # See below. + Piezo Configuration>Drift X (m/s) 0E+0 # Define the drift speed for all three axes. When the compensation is on, the piezos will start to move at that speed. + Piezo Configuration>Drift Y (m/s) 0E+0 # See below. + Piezo Configuration>Drift Z (m/s) 0E+0 # See below. + Piezo Configuration>Drift correction status (on/off) FALSE # Use the button to turn on/off the drift compensation. + + MEASUREMENT + Position (NXtransformation) # also clarify the frame laboratory frame + X (m) -890.53E-12 + Y (m) 29.6968E-9 + Z (m) 130.5E-9 + Z-Controller>Z (m) 130.5E-9 + sweep control # parameters for a measurement at a single location during the scan + Integration time (s) 150E-6 # Time during which the spectroscopy data are acquired and averaged. + Bias Spectroscopy>Number of sweeps 100 # Number of sweeps to measure and average. + Bias Spectroscopy>Sweep Start (V) -300E-3 # The first bias values of the sweep. + Bias Spectroscopy>Sweep End (V) 300E-3 # The last bias values of the sweep. + Bias Spectroscopy>Num Pixel 4096 # Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. + Bias Spectroscopy>Z Avg time (s) 100E-3 # Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). + SoftwareMain>RT Frequency (Hz) 20E+3 # The bandwitdh of the Hardware and/or Software + SoftwareMain>Signals Oversampling 10 # (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. + SoftwareMain>Acquisition Period (s) 20E-3 # Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. + SoftwareMain>Animations Period (s) 20E-3 # Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. + SoftwareMain>Indicators Period (s) 300E-3 # Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. + SoftwareMain>Measurements Period (s) 500E-3 # The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. + Scan control # parameters how to change the location from measurement to measurement during the scan + frame(NXtransformation) # also clarify the frame for the ROI of the scan (should depend on the lab frame) + Scan>Scanfield 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0 # Configure the scan frame: x position; y position; width; height. + Scan>channels Current (A);Bias (V);Z (m);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A) # The scan channels are selected by users. + Scan>pixels/line 512 # Scan resolution by setting the Lines equal to Pixels. + Scan>lines 512 # Define the image resolution. + Scan>speed forw. (m/s) 11.7187E-9 # Define the scan forward speed in the forward direction. + Scan>speed backw. (m/s) 11.7187E-9 # Define the scan backward speed in the forward direction. + + SW Filter (PROCESS) + type Butterworth # Select a filter to smooth the displayed data. Note: When saving, if any filter selected, filtered data are saved to file along with the unfiltered data. + Order 1 # Filter order of a dynamic filter or width (in number of points) for the gaussian filter. + Cutoff frq 0.01 # Cutoff frequency for dynamic filters. + filtered_data # result of filtering if applied + HW Filter (NXlockin) # maybe the same as INSTRUMENT/lockin + Lock-in>LP Filter Cutoff D1 (Hz) 621.699E+0 # Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) value) for D1. The filter is applied to the demodulated signals (X,Y). + Lock-in>LP Filter Cutoff D2 (Hz) 621.699E+0 # Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) value) for D2. The filter is applied to the demodulated signals (X,Y). + Lock-in>LP Filter Order D1 8 # Order and cut-off frequency of the low-pass filter applied on the demodulated signals (X,Y). Reducing the bandwidth or increasing the order reduces noise on the demodulated signals, but will require longer settling and measurement times. + Lock-in>LP Filter Order D2 8 # See below. + Lock-in>HP Filter Cutoff D1 (Hz) # Sets the cut-off frequency of the high-pass filter (affects the displayed TC (s) value) for D1. The filter is applied to the demodulated signals (X,Y). + Lock-in>HP Filter Cutoff D2 (Hz) # See below + Lock-in>HP Filter Order D1 1 # Order and cut-off frequency of the high-pass filter applied on the demodulation signal of D!. This is used mainly to suppress a DC component of the demodulation signal, which would lead to a component at modulation frequency in the demodulated signals. + Lock-in>HP Filter Order D2 1 # See below + Lock-in>Sync Filter D1 ON # Switch the Sync filter on the demodulated signals (X,Y) on or off for D1. The sync filter operates after the low-pass filter and averages the demodulated signals over one period of the modulation frequency. + Lock-in>Sync Filter D2 ON # See below. + RESOLUTION (calculation input) + Temperature 1>link to INSTR/STM/head Temperature 1 (K) 4.92997E+0 # Temperature of STM head. + Temperature 2>link to Temperature 2 (K) - # Temperature of bottom of LHe helium cryostat. + Temperature 3>link to Temperature 3 (K) - # Temperature of LN2 nitrogen shield. + Lock-in>link to Modulated signal Bias (V) 1E-3 # Applied modulation to the bias voltage. + link to Integration time (s) 150E-6 # Time during which the spectroscopy data are acquired and averaged. + link to Bias Spectroscopy>Number of sweeps 100 # Number of sweeps to measure and average. + link to Bias Spectroscopy>Sweep Start (V) -300E-3 # The first bias values of the sweep. + link to Bias Spectroscopy>Sweep End (V) 300E-3 # The last bias values of the sweep. + link to Bias Spectroscopy>Num Pixel 4096 # Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. + link to Bias Spectroscopy>Z Avg time (s) 100E-3 # Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). + link to SoftwareMain>RT Frequency (Hz) 20E+3 # The bandwitdh of the Hardware and/or Software + link to SoftwareMain>Signals Oversampling 10 # (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. + link to SoftwareMain>Acquisition Period (s) 20E-3 # Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. + link to SoftwareMain>Animations Period (s) 20E-3 # Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. + link to SoftwareMain>Indicators Period (s) 300E-3 # Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. + link to SoftwareMain>Measurements Period (s) 500E-3 # The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. + REPRODUCIBILITY + link to + Bias>Bias (V) 100E-3 # Applied bias voltage. + Current>Current (A) -5.3429E-15 # The tunneling current is displayed here. + Bias>Calibration (V/V) 1E+0 # Calibration of the Bias output. If you have a Range switch the calibration is stored per range setting. + Bias>Offset (V) 0E+0 # Allows compensating for an offset in Bias. + Current>Calibration (A/V) 100E-12 # The signals voltages are converted to real world physical values according to the calibration & offset parameters: Physical signal = (Voltage * calibration) + offset. + Current>Offset (A) 16.2897E-15 # The same as "Current>Calibration (A/V)" tag + Current>Gain Not switchable # None + Z offset (m) 0E+0 # Offset added to the initial averaged position Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an alternate Z-controller setpoint is enabled. + Settling time (s) 2.1E-3 # Time to wait after changing the bias to the next level and before starting to acquire data. Adjust this parameter to avoid transient effect induced by the bias change. Integration time: time during which the data are acquired and averaged. + Z-Ctrl hold TRUE # When selected, the Z-Controller is set to hold during the pulse. This means that the controller doesn't control the Z position during the pulse. + Final Z (m) N/A + Start time 23.11.2022 18:55:16 # Timestamp of the moment when the acquisition starts by pressing the Start button. + Bias Spectroscopy>Z offset (m) 0E+0 # Offset added to the initial averaged position Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an alternate Z-controller setpoint is enabled. + Bias Spectroscopy>1st Settling time (s) 2.1E-3 # See the "Settling time (s)" below. + Bias Spectroscopy>Settling time (s) 2.1E-3 # See the "Settling time (s)" below. + Bias Spectroscopy>Integration time (s) 150E-6 # Time during which the data are acquired and averaged. + Bias Spectroscopy>End Settling time (s) 4E-3 # Time to wait after the sweep has finished and the bias is ramped to the initial value. + Bias Spectroscopy>Z control time (s) 200E-3 # Time during which the Z-Controller is enabled once a sweep has finished. When averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled for this duration between each sweep. After the last sweep, it will wait the specified time before continuing a running scan. This ensures each sweep reliably starts from the same position. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. + Bias Spectroscopy>Max Slew rate (V/s) 1E+0 # Maximum rate at which the bias changes (before, during and after sweeping). + Bias Spectroscopy>backward sweep TRUE # Select whether to measure the backward (return) sweep or the forward only. + Bias Spectroscopy>Z-controller hold TRUE # Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. + Z-Controller>Controller name log Current # Controller name. This name which will be displayed at places where you can select a controller. + Z-Controller>Controller status OFF # ON/OFF + Z-Controller>Setpoint 50E-12 # Set Point is the desired value of the control signal. It can be set by editing the number or using the slider bar. Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. + Z-Controller>Setpoint unit A # Angstrom + Z-Controller>P gain 6E-12 # The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. + Z-Controller>I gain 39.8241E-9 # See "Z-Controller>P gain" below. + Z-Controller>Time const (s) 150.662E-6 # See "Z-Controller>P gain" below. + Z-Controller>TipLift (m) 0E+0 # Lifts the tip by the specified amount when then controller is switched off. This can be a positive or a negative number, i.e. the tip can also be moved towards the sample. Be careful with sign and value when using this feature. + Z-Controller>Switch off delay (s) 0E+0 # Use this parameter for a reproducible position when switching off the Z-controller. When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. + + DATA # multi dimensional array: multi I-V array per scan point; + Bias calc (V) #scanning parameter + Current (A) # current during forward direction scanning of bias - original NXsensor + LI Demod 2 X (A) lockin (NXsensor+lockin) + LI Demod 2 Y (A) lockin + LI Demod 1 X (A) lockin + LI Demod 1 Y (A) lockin + Current [bwd] (A) #bwd - backward (the positive direction shall be clarified by the reference bias scanning frame. Fwd means from left(neg) to right(pos). In the scannig image, the bottom(neg) to top(pos), the left(neg) to right(pos) + LI Demod 2 X [bwd] (A) lockin + LI Demod 2 Y [bwd] (A) lockin + LI Demod 1 X [bwd] (A) lockin + LI Demod 1 Y [bwd] (A) lockin + Current (A) [filt] # forward direction (maybe from lockin#2?) + LI Demod 2 X (A) [filt] lockin + LI Demod 2 Y (A) [filt] lockin + LI Demod 1 X (A) [filt] lockin + LI Demod 1 Y (A) [filt] lockin + Current (A) [bwd] [filt] + LI Demod 2 X (A) [bwd] [filt] lockin + LI Demod 2 Y (A) [bwd] [filt] lockin + LI Demod 1 X (A) [bwd] [filt] lockin + LI Demod 1 Y (A) [bwd] [filt] lockin + Temperature + x + y + z + + single point default plot # current(I) vs bias(V) + line scan default plot # multi I vs. V curves + alternative plot # current(I) curve in the 2D space of (position(x), bias(V)) + mesh scan default plot # 2D slices of the above alternative plot + + + + + + + + + From 43fc5f6a5dd5981ea8b02e2d7ecd6087c4de524b Mon Sep 17 00:00:00 2001 From: Yichen Date: Tue, 25 Apr 2023 14:13:24 +0200 Subject: [PATCH 0113/1012] Rename NXiv_sweep2.yaml.bp to NXiv_sweep2.backup.yaml --- .../nyaml/{NXiv_sweep2.yaml.bp => NXiv_sweep2.backup.yaml} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename contributed_definitions/nyaml/{NXiv_sweep2.yaml.bp => NXiv_sweep2.backup.yaml} (100%) diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml.bp b/contributed_definitions/nyaml/NXiv_sweep2.backup.yaml similarity index 100% rename from contributed_definitions/nyaml/NXiv_sweep2.yaml.bp rename to contributed_definitions/nyaml/NXiv_sweep2.backup.yaml From 5722eb68f12535c92ec791463ad7aab47053c8e6 Mon Sep 17 00:00:00 2001 From: Yichen Date: Tue, 25 Apr 2023 17:18:15 +0200 Subject: [PATCH 0114/1012] Update the sweep as a backup with classification --- .../nyaml/NXiv_sweep2.backup.yaml | 188 +++++++++--------- 1 file changed, 94 insertions(+), 94 deletions(-) diff --git a/contributed_definitions/nyaml/NXiv_sweep2.backup.yaml b/contributed_definitions/nyaml/NXiv_sweep2.backup.yaml index 6394585fd9..78c4a0c03f 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.backup.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.backup.yaml @@ -61,28 +61,28 @@ NXiv_sweep2(NXsensor_scan): Lock-in Amplifier>Hardware: Nanonis if Lock-in -- Bias Divider 1/10 or 1/100 # if the modulation - Bias Spectroscopy>Channels Current (A);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A) # Select the channels to record. - Bias Spectroscopy>Reset Bias TRUE # When selected, the Bias voltage returns to the initial value (before starting the sweep) at the end of the spectroscopy measurement (default). When not selected, Bias remains at the last value of the sweep. This is useful e.g. when combining several sweep segments. Example for an automated measurement (using Programming Interface): switch off Z-Controller, start spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, switch on Z-Controller. - Bias Spectroscopy>Record final Z FALSE # Select whether to record the Z position during Z averaging time at the end of the sweep (after Z control time) and store the average value in the header of the file when saving. Using this option increases the sweep time by Z averaging time. - Bias Spectroscopy>Lock-In run FALSE # Select whether to set the Lock-In to run during the measurement. When using this feature, make sure the Lock-In is configured correctly and settling times are set to twice the Lock-In period at least. This option is ignored when Lock-In is already running. This option is disabled if the Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline segment editor is set. - Lock-in>Modulated signal Bias (V) # This is the signal on which the modulation (sine) will be added. - Lock-in>Frequency (Hz) 973E+0 # Sets the frequency of the sine modulation added to the signal to modulate. The frequency range is from 10 mHz to 40 kHz (corresponding to the SC5 output filter cut-off). When working with harmonics, make sure the harmonic frequencies don’t exceed ~100 kHz (SC5 input filter cut-off). Remember the SC5 hardware filters will affect the amplitude when getting close to their cut-off frequencies. - Lock-in>Amplitude 2E-3 # Sets the amplitude (in physical units of the modulated signal) of the sine modulation. - Lock-in>Demodulated signal Current (A) # This is the signal which will be demodulated, in order to determine the amplitude and phase at the frequency set in the Frequency field (“4”) or harmonics. - Lock-in>Harmonic D1 1 # Order of the harmonic oscillation to detect on the demodulated signal (with respect to the modulation frequency). If you work with higher harmonics make sure the frequency does not exceed the analog signal bandwidth (100 kHz). - Lock-in>Harmonic D2 2 # See below. - Lock-in>Reference phase D1 (deg) 137.597E+0 # Reference phase for the sine on the demodulated signal with respect to the modulation signal. The determined phase (phi) is displayed with respect to the reference phase. - Lock-in>Reference phase D2 (deg) -83.6562E+0 # See below. + Bias Spectroscopy>Channels(NXBias) Current (A);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A) # Select the channels to record. + Bias Spectroscopy>Reset Bias(NXBias) TRUE # When selected, the Bias voltage returns to the initial value (before starting the sweep) at the end of the spectroscopy measurement (default). When not selected, Bias remains at the last value of the sweep. This is useful e.g. when combining several sweep segments. Example for an automated measurement (using Programming Interface): switch off Z-Controller, start spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, switch on Z-Controller. + Bias Spectroscopy>Record final Z(NXBias) FALSE # Select whether to record the Z position during Z averaging time at the end of the sweep (after Z control time) and store the average value in the header of the file when saving. Using this option increases the sweep time by Z averaging time. + Bias Spectroscopy>Lock-In run(NXBias) FALSE # Select whether to set the Lock-In to run during the measurement. When using this feature, make sure the Lock-In is configured correctly and settling times are set to twice the Lock-In period at least. This option is ignored when Lock-In is already running. This option is disabled if the Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline segment editor is set. + Lock-in>Modulated signal Bias(NXlockin) (V) # This is the signal on which the modulation (sine) will be added. + Lock-in>Frequency(NXlockin) (Hz) 973E+0 # Sets the frequency of the sine modulation added to the signal to modulate. The frequency range is from 10 mHz to 40 kHz (corresponding to the SC5 output filter cut-off). When working with harmonics, make sure the harmonic frequencies don’t exceed ~100 kHz (SC5 input filter cut-off). Remember the SC5 hardware filters will affect the amplitude when getting close to their cut-off frequencies. + Lock-in>Amplitude(NXlockin) 2E-3 # Sets the amplitude (in physical units of the modulated signal) of the sine modulation. + Lock-in>Demodulated signal Current(NXlockin) (A) # This is the signal which will be demodulated, in order to determine the amplitude and phase at the frequency set in the Frequency field (“4”) or harmonics. + Lock-in>Harmonic D1(NXlockin) 1 # Order of the harmonic oscillation to detect on the demodulated signal (with respect to the modulation frequency). If you work with higher harmonics make sure the frequency does not exceed the analog signal bandwidth (100 kHz). + Lock-in>Harmonic D2(NXlockin) 2 # See below. + Lock-in>Reference phase D1(NXlockin) (deg) 137.597E+0 # Reference phase for the sine on the demodulated signal with respect to the modulation signal. The determined phase (phi) is displayed with respect to the reference phase. + Lock-in>Reference phase D2(NXlockin) (deg) -83.6562E+0 # See below. Bias: Tip bias/Sample bias # If the spectroscopy V bias is applied to the - Modulated signal Bias (V) 1E-3 # Applied modulation to the bias voltage. + Modulated signal Bias(NXbias) (V) 1E-3 # Applied modulation to the bias voltage. ModulationBias> Tip bias/Sample bias STM head - temp Temperature 1 (K) 4.92997E+0 # Temperature of STM head. + temp Temperature 1(NXsensor) (K) 4.92997E+0 # Temperature of STM head. Cryo - bottom_temp Temperature 2 (K) - # Temperature of bottom of LHe helium cryostat. - shield_temp Temperature 3 (K) - # Temperature of LN2 nitrogen shield. - Cabling & Config + bottom_temp Temperature 2(NXsensor) (K) - # Temperature of bottom of LHe helium cryostat. + shield_temp Temperature 3(NXsensor) (K) - # Temperature of LN2 nitrogen shield. + Cabling & Config(NXdata) Outputs>Output 0 Mode User Output Outputs>Output 1 Mode User Output Outputs>Output 2 Mode User Output @@ -117,50 +117,50 @@ NXiv_sweep2(NXsensor_scan): Outputs>Output 7 Slew Rate Inf Piezo Config Piezo Configuration>Active Calib. LHe # Tne name of caliberation type. - Piezo Configuration>Calib. X (m/V) 3.8E-9 # There are 3 controls available: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. - Piezo Configuration>Calib. Y (m/V) 3.8E-9 # See below. - Piezo Configuration>Calib. Z (m/V) 900E-12 # See below. - Piezo Configuration>HV Gain X 14.5 # For some systems HV gain readout is available, so for those systems the HV gain should be adjusted automatically when the gain is changed at the high voltage amplifier. - Piezo Configuration>HV Gain Y 14.5 # See below. - Piezo Configuration>HV Gain Z 14.5 # See below. - Piezo Configuration>Tilt X (deg) 0.318343 # This tab is used to set the sample tilt (in degrees, first order correction). - Piezo Configuration>Tilt Y (deg) 1.584 # See below. - Piezo Configuration>Curvature radius X (m) Inf # This tab is used to set a curvature (can be set approximately to the length of the piezotube). - Piezo Configuration>Curvature radius Y (m) Inf # See below. - Piezo Configuration>2nd order corr X (V/m^2) 0E+0 # If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. - Piezo Configuration>2nd order corr Y (V/m^2) 0E+0 # See below. - Piezo Configuration>Drift X (m/s) 0E+0 # Define the drift speed for all three axes. When the compensation is on, the piezos will start to move at that speed. - Piezo Configuration>Drift Y (m/s) 0E+0 # See below. - Piezo Configuration>Drift Z (m/s) 0E+0 # See below. - Piezo Configuration>Drift correction status (on/off) FALSE # Use the button to turn on/off the drift compensation. + Piezo Configuration>Calib. X(NXpositioner) (m/V) 3.8E-9 # There are 3 controls available: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. + Piezo Configuration>Calib. Y(NXpositioner) (m/V) 3.8E-9 # See below. + Piezo Configuration>Calib. Z(NXpositioner) (m/V) 900E-12 # See below. + Piezo Configuration>HV Gain X(NXpositioner) 14.5 # For some systems HV gain readout is available, so for those systems the HV gain should be adjusted automatically when the gain is changed at the high voltage amplifier. + Piezo Configuration>HV Gain Y(NXpositioner) 14.5 # See below. + Piezo Configuration>HV Gain Z(NXpositioner) 14.5 # See below. + Piezo Configuration>Tilt X(NXpositioner) (deg) 0.318343 # This tab is used to set the sample tilt (in degrees, first order correction). + Piezo Configuration>Tilt Y(NXpositioner) (deg) 1.584 # See below. + Piezo Configuration>Curvature radius X(NXpositioner) (m) Inf # This tab is used to set a curvature (can be set approximately to the length of the piezotube). + Piezo Configuration>Curvature radius Y(NXpositioner) (m) Inf # See below. + Piezo Configuration>2nd order corr X(NXpositioner) (V/m^2) 0E+0 # If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. + Piezo Configuration>2nd order corr Y(NXpositioner) (V/m^2) 0E+0 # See below. + Piezo Configuration>Drift X(NXpositioner) (m/s) 0E+0 # Define the drift speed for all three axes. When the compensation is on, the piezos will start to move at that speed. + Piezo Configuration>Drift Y(NXpositioner) (m/s) 0E+0 # See below. + Piezo Configuration>Drift Z(NXpositioner) (m/s) 0E+0 # See below. + Piezo Configuration>Drift correction status (on/off)(NXpositioner) FALSE # Use the button to turn on/off the drift compensation. MEASUREMENT - Position (NXtransformation) # also clarify the frame laboratory frame - X (m) -890.53E-12 - Y (m) 29.6968E-9 - Z (m) 130.5E-9 - Z-Controller>Z (m) 130.5E-9 + Position (NXpositioner) # also clarify the frame laboratory frame + X(NXpositioner) (m) -890.53E-12 + Y(NXpositioner) (m) 29.6968E-9 + Z(NXpositioner) (m) 130.5E-9 + Z-Controller>Z(NXpositioner) (m) 130.5E-9 sweep control # parameters for a measurement at a single location during the scan - Integration time (s) 150E-6 # Time during which the spectroscopy data are acquired and averaged. - Bias Spectroscopy>Number of sweeps 100 # Number of sweeps to measure and average. - Bias Spectroscopy>Sweep Start (V) -300E-3 # The first bias values of the sweep. - Bias Spectroscopy>Sweep End (V) 300E-3 # The last bias values of the sweep. - Bias Spectroscopy>Num Pixel 4096 # Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. - Bias Spectroscopy>Z Avg time (s) 100E-3 # Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). - SoftwareMain>RT Frequency (Hz) 20E+3 # The bandwitdh of the Hardware and/or Software - SoftwareMain>Signals Oversampling 10 # (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. - SoftwareMain>Acquisition Period (s) 20E-3 # Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. - SoftwareMain>Animations Period (s) 20E-3 # Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. - SoftwareMain>Indicators Period (s) 300E-3 # Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. - SoftwareMain>Measurements Period (s) 500E-3 # The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. + Integration time(NXbias) (s) 150E-6 # Time during which the spectroscopy data are acquired and averaged. + Bias Spectroscopy>Number of sweeps(NXBias) 100 # Number of sweeps to measure and average. + Bias Spectroscopy>Sweep Start(NXBias) (V) -300E-3 # The first bias values of the sweep. + Bias Spectroscopy>Sweep End(NXBias) (V) 300E-3 # The last bias values of the sweep. + Bias Spectroscopy>Num Pixel(NXBias) 4096 # Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. + Bias Spectroscopy>Z Avg time(NXBias) (s) 100E-3 # Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). + (TBA)SoftwareMain>RT Frequency (Hz) 20E+3 # The bandwitdh of the Hardware and/or Software + (TBA)SoftwareMain>Signals Oversampling 10 # (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. + (TBA)SoftwareMain>Acquisition Period (s) 20E-3 # Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. + (TBA)SoftwareMain>Animations Period (s) 20E-3 # Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. + (TBA)SoftwareMain>Indicators Period (s) 300E-3 # Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. + (TBA)SoftwareMain>Measurements Period (s) 500E-3 # The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. Scan control # parameters how to change the location from measurement to measurement during the scan frame(NXtransformation) # also clarify the frame for the ROI of the scan (should depend on the lab frame) - Scan>Scanfield 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0 # Configure the scan frame: x position; y position; width; height. - Scan>channels Current (A);Bias (V);Z (m);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A) # The scan channels are selected by users. - Scan>pixels/line 512 # Scan resolution by setting the Lines equal to Pixels. - Scan>lines 512 # Define the image resolution. - Scan>speed forw. (m/s) 11.7187E-9 # Define the scan forward speed in the forward direction. - Scan>speed backw. (m/s) 11.7187E-9 # Define the scan backward speed in the forward direction. + Scan>Scanfield(NXpositioner) 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0 # Configure the scan frame: x position; y position; width; height. + Scan>channels Current(NXcircuit) (A);Bias (V);Z (m);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A) # The scan channels are selected by users. + Scan>pixels/line(NXpositioner) 512 # Scan resolution by setting the Lines equal to Pixels. + Scan>lines(NXpositioner) 512 # Define the image resolution. + Scan>speed forw.(NXpositioner) (m/s) 11.7187E-9 # Define the scan forward speed in the forward direction. + Scan>speed backw.(NXpositioner) (m/s) 11.7187E-9 # Define the scan backward speed in the forward direction. SW Filter (PROCESS) type Butterworth # Select a filter to smooth the displayed data. Note: When saving, if any filter selected, filtered data are saved to file along with the unfiltered data. @@ -168,16 +168,16 @@ NXiv_sweep2(NXsensor_scan): Cutoff frq 0.01 # Cutoff frequency for dynamic filters. filtered_data # result of filtering if applied HW Filter (NXlockin) # maybe the same as INSTRUMENT/lockin - Lock-in>LP Filter Cutoff D1 (Hz) 621.699E+0 # Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) value) for D1. The filter is applied to the demodulated signals (X,Y). - Lock-in>LP Filter Cutoff D2 (Hz) 621.699E+0 # Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) value) for D2. The filter is applied to the demodulated signals (X,Y). - Lock-in>LP Filter Order D1 8 # Order and cut-off frequency of the low-pass filter applied on the demodulated signals (X,Y). Reducing the bandwidth or increasing the order reduces noise on the demodulated signals, but will require longer settling and measurement times. - Lock-in>LP Filter Order D2 8 # See below. - Lock-in>HP Filter Cutoff D1 (Hz) # Sets the cut-off frequency of the high-pass filter (affects the displayed TC (s) value) for D1. The filter is applied to the demodulated signals (X,Y). - Lock-in>HP Filter Cutoff D2 (Hz) # See below - Lock-in>HP Filter Order D1 1 # Order and cut-off frequency of the high-pass filter applied on the demodulation signal of D!. This is used mainly to suppress a DC component of the demodulation signal, which would lead to a component at modulation frequency in the demodulated signals. - Lock-in>HP Filter Order D2 1 # See below - Lock-in>Sync Filter D1 ON # Switch the Sync filter on the demodulated signals (X,Y) on or off for D1. The sync filter operates after the low-pass filter and averages the demodulated signals over one period of the modulation frequency. - Lock-in>Sync Filter D2 ON # See below. + Lock-in>LP Filter Cutoff(NXlockin) D1 (Hz) 621.699E+0 # Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) value) for D1. The filter is applied to the demodulated signals (X,Y). + Lock-in>LP Filter Cutoff(NXlockin) D2 (Hz) 621.699E+0 # Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) value) for D2. The filter is applied to the demodulated signals (X,Y). + Lock-in>LP Filter Order(NXlockin) D1 8 # Order and cut-off frequency of the low-pass filter applied on the demodulated signals (X,Y). Reducing the bandwidth or increasing the order reduces noise on the demodulated signals, but will require longer settling and measurement times. + Lock-in>LP Filter Order(NXlockin) D2 8 # See below. + Lock-in>HP Filter Cutoff(NXlockin) D1 (Hz) # Sets the cut-off frequency of the high-pass filter (affects the displayed TC (s) value) for D1. The filter is applied to the demodulated signals (X,Y). + Lock-in>HP Filter Cutoff(NXlockin) D2 (Hz) # See below + Lock-in>HP Filter Order(NXlockin) D1 1 # Order and cut-off frequency of the high-pass filter applied on the demodulation signal of D!. This is used mainly to suppress a DC component of the demodulation signal, which would lead to a component at modulation frequency in the demodulated signals. + Lock-in>HP Filter Order(NXlockin) D2 1 # See below + Lock-in>Sync Filter(NXlockin) D1 ON # Switch the Sync filter on the demodulated signals (X,Y) on or off for D1. The sync filter operates after the low-pass filter and averages the demodulated signals over one period of the modulation frequency. + Lock-in>Sync Filter(NXlockin) D2 ON # See below. RESOLUTION (calculation input) Temperature 1>link to INSTR/STM/head Temperature 1 (K) 4.92997E+0 # Temperature of STM head. Temperature 2>link to Temperature 2 (K) - # Temperature of bottom of LHe helium cryostat. @@ -197,36 +197,36 @@ NXiv_sweep2(NXsensor_scan): link to SoftwareMain>Measurements Period (s) 500E-3 # The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. REPRODUCIBILITY link to - Bias>Bias (V) 100E-3 # Applied bias voltage. - Current>Current (A) -5.3429E-15 # The tunneling current is displayed here. - Bias>Calibration (V/V) 1E+0 # Calibration of the Bias output. If you have a Range switch the calibration is stored per range setting. - Bias>Offset (V) 0E+0 # Allows compensating for an offset in Bias. - Current>Calibration (A/V) 100E-12 # The signals voltages are converted to real world physical values according to the calibration & offset parameters: Physical signal = (Voltage * calibration) + offset. - Current>Offset (A) 16.2897E-15 # The same as "Current>Calibration (A/V)" tag - Current>Gain Not switchable # None - Z offset (m) 0E+0 # Offset added to the initial averaged position Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an alternate Z-controller setpoint is enabled. - Settling time (s) 2.1E-3 # Time to wait after changing the bias to the next level and before starting to acquire data. Adjust this parameter to avoid transient effect induced by the bias change. Integration time: time during which the data are acquired and averaged. - Z-Ctrl hold TRUE # When selected, the Z-Controller is set to hold during the pulse. This means that the controller doesn't control the Z position during the pulse. + Bias>Bias(NXBias) (V) 100E-3 # Applied bias voltage. + Current>Current(NXcircuit) (A) -5.3429E-15 # The tunneling current is displayed here. + Bias>Calibration(NXbias) (V/V) 1E+0 # Calibration of the Bias output. If you have a Range switch the calibration is stored per range setting. + Bias>Offset(NXbias) (V) 0E+0 # Allows compensating for an offset in Bias. + Current>Calibration(NXcircuit) (A/V) 100E-12 # The signals voltages are converted to real world physical values according to the calibration & offset parameters: Physical signal = (Voltage * calibration) + offset. + Current>Offset(NXcircuit) (A) 16.2897E-15 # The same as "Current>Calibration (A/V)" tag + Current>Gain(TBA) Not switchable # None + Z offset(NXpositioner) (m) 0E+0 # Offset added to the initial averaged position Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an alternate Z-controller setpoint is enabled. + Settling time(NXbias) (s) 2.1E-3 # Time to wait after changing the bias to the next level and before starting to acquire data. Adjust this parameter to avoid transient effect induced by the bias change. Integration time: time during which the data are acquired and averaged. + Z-Ctrl hold(NXpositioner) TRUE # When selected, the Z-Controller is set to hold during the pulse. This means that the controller doesn't control the Z position during the pulse. Final Z (m) N/A Start time 23.11.2022 18:55:16 # Timestamp of the moment when the acquisition starts by pressing the Start button. - Bias Spectroscopy>Z offset (m) 0E+0 # Offset added to the initial averaged position Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an alternate Z-controller setpoint is enabled. - Bias Spectroscopy>1st Settling time (s) 2.1E-3 # See the "Settling time (s)" below. - Bias Spectroscopy>Settling time (s) 2.1E-3 # See the "Settling time (s)" below. - Bias Spectroscopy>Integration time (s) 150E-6 # Time during which the data are acquired and averaged. - Bias Spectroscopy>End Settling time (s) 4E-3 # Time to wait after the sweep has finished and the bias is ramped to the initial value. - Bias Spectroscopy>Z control time (s) 200E-3 # Time during which the Z-Controller is enabled once a sweep has finished. When averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled for this duration between each sweep. After the last sweep, it will wait the specified time before continuing a running scan. This ensures each sweep reliably starts from the same position. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. - Bias Spectroscopy>Max Slew rate (V/s) 1E+0 # Maximum rate at which the bias changes (before, during and after sweeping). - Bias Spectroscopy>backward sweep TRUE # Select whether to measure the backward (return) sweep or the forward only. - Bias Spectroscopy>Z-controller hold TRUE # Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. - Z-Controller>Controller name log Current # Controller name. This name which will be displayed at places where you can select a controller. - Z-Controller>Controller status OFF # ON/OFF - Z-Controller>Setpoint 50E-12 # Set Point is the desired value of the control signal. It can be set by editing the number or using the slider bar. Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. - Z-Controller>Setpoint unit A # Angstrom - Z-Controller>P gain 6E-12 # The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. - Z-Controller>I gain 39.8241E-9 # See "Z-Controller>P gain" below. - Z-Controller>Time const (s) 150.662E-6 # See "Z-Controller>P gain" below. - Z-Controller>TipLift (m) 0E+0 # Lifts the tip by the specified amount when then controller is switched off. This can be a positive or a negative number, i.e. the tip can also be moved towards the sample. Be careful with sign and value when using this feature. - Z-Controller>Switch off delay (s) 0E+0 # Use this parameter for a reproducible position when switching off the Z-controller. When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. + Bias Spectroscopy>Z offset(NXbias) (m) 0E+0 # Offset added to the initial averaged position Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an alternate Z-controller setpoint is enabled. + Bias Spectroscopy>1st Settling time(NXbias) (s) 2.1E-3 # See the "Settling time (s)" below. + Bias Spectroscopy>Settling time(NXbias) (s) 2.1E-3 # See the "Settling time (s)" below. + Bias Spectroscopy>Integration time(NXbias) (s) 150E-6 # Time during which the data are acquired and averaged. + Bias Spectroscopy>End Settling time(NXbias) (s) 4E-3 # Time to wait after the sweep has finished and the bias is ramped to the initial value. + Bias Spectroscopy>Z control time(NXbias) (s) 200E-3 # Time during which the Z-Controller is enabled once a sweep has finished. When averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled for this duration between each sweep. After the last sweep, it will wait the specified time before continuing a running scan. This ensures each sweep reliably starts from the same position. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. + Bias Spectroscopy>Max Slew rate(NXbias) (V/s) 1E+0 # Maximum rate at which the bias changes (before, during and after sweeping). + Bias Spectroscopy>backward sweep(NXbias) TRUE # Select whether to measure the backward (return) sweep or the forward only. + Bias Spectroscopy>Z-controller hold(NXbias) TRUE # Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. + Z-Controller>Controller name(NXpositioner) log Current # Controller name. This name which will be displayed at places where you can select a controller. + Z-Controller>Controller status(NXpositioner) OFF # ON/OFF + Z-Controller>Setpoint(NXpositioner) 50E-12 # Set Point is the desired value of the control signal. It can be set by editing the number or using the slider bar. Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. + Z-Controller>Setpoint unit(NXpositioner) A # Angstrom + Z-Controller>P gain(NXpositioner) 6E-12 # The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. + Z-Controller>I gain(NXpositioner) 39.8241E-9 # See "Z-Controller>P gain" below. + Z-Controller>Time const(NXpositioner) (s) 150.662E-6 # See "Z-Controller>P gain" below. + Z-Controller>TipLift(NXpositioner) (m) 0E+0 # Lifts the tip by the specified amount when then controller is switched off. This can be a positive or a negative number, i.e. the tip can also be moved towards the sample. Be careful with sign and value when using this feature. + Z-Controller>Switch off delay(NXpositioner) (s) 0E+0 # Use this parameter for a reproducible position when switching off the Z-controller. When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. DATA # multi dimensional array: multi I-V array per scan point; Bias calc (V) #scanning parameter From 1444382f28435ccdf41a9a6fdf525e82a926bc17 Mon Sep 17 00:00:00 2001 From: Yichen Date: Tue, 25 Apr 2023 17:19:41 +0200 Subject: [PATCH 0115/1012] Update the LP/HP order and cutoff defination --- contributed_definitions/nyaml/NXlockin.yaml | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/contributed_definitions/nyaml/NXlockin.yaml b/contributed_definitions/nyaml/NXlockin.yaml index 652cf1ac78..e3283affa0 100644 --- a/contributed_definitions/nyaml/NXlockin.yaml +++ b/contributed_definitions/nyaml/NXlockin.yaml @@ -24,8 +24,18 @@ NXlockin: HiPass(NX_NUMBER): doc: Order and cut-off frequency of the high-pass filter applied on the demodulation signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) unit: NX_FREQUENCY + LP Filter Cutoff(NX_NUMBER): + doc: Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) value) for D1. The filter is applied to the demodulated signals (X,Y). + unit: NX_FREQUENCY + LP Filter Order(NX_NUMBER): + doc: Order and cut-off frequency of the low-pass filter applied on the demodulated signals (X,Y). Reducing the bandwidth or increasing the order reduces noise on the demodulated signals, but will require longer settling and measurement times. + HP Filter Cutoff(NX_NUMBER): + doc: Sets the cut-off frequency of the high-pass filter (affects the displayed TC (s) value) for D1. The filter is applied to the demodulated signals (X,Y). + unit: NX_FREQUENCY + HP Filter Order(NX_NUMBER): + doc: Order and cut-off frequency of the high-pass filter applied on the demodulation signal of D!. This is used mainly to suppress a DC component of the demodulation signal, which would lead to a component at modulation frequency in the demodulated signals. Sync(NX_CHAR): - doc: Switch the Sync filter on the demodulated signals (X,Y) on or off. (foreach DemodulatorChannels) + doc: Switch on/off the Sync filter on the demodulated signals (X,Y) on or off. (foreach DemodulatorChannels) refPhase(NX_NUMBER): doc: Reference phase for the sine on the demodulated signal with respect to the modulation signal. (foreach DemodulatorChannels) unit: NX_FREQUENCY From 86ab34aaa0e4a604dafcb0d146a6cae78769fee1 Mon Sep 17 00:00:00 2001 From: Yichen Date: Tue, 25 Apr 2023 17:26:55 +0200 Subject: [PATCH 0116/1012] Delete the backup file --- .../nyaml/NXpositioner.yaml.bp2 | 186 ------------------ 1 file changed, 186 deletions(-) delete mode 100644 contributed_definitions/nyaml/NXpositioner.yaml.bp2 diff --git a/contributed_definitions/nyaml/NXpositioner.yaml.bp2 b/contributed_definitions/nyaml/NXpositioner.yaml.bp2 deleted file mode 100644 index 4ef1de27fc..0000000000 --- a/contributed_definitions/nyaml/NXpositioner.yaml.bp2 +++ /dev/null @@ -1,186 +0,0 @@ -category: base -doc: | - A generic positioner such as a motor or piezo-electric transducer. - -type: group -NXpositioner(NXobject): - name: - doc: | - symbolic or mnemonic name (one word) - description: - doc: | - description of positioner - value(NX_NUMBER): - unit: NX_ANY - doc: | - best known value of positioner - need [n] as may be scanned - dimensions: - rank: 1 - dim: [[1, n]] - raw_value(NX_NUMBER): - unit: NX_ANY - doc: | - raw value of positioner - need [n] as may be scanned - dimensions: - rank: 1 - dim: [[1, n]] - target_value(NX_NUMBER): - unit: NX_ANY - doc: | - targeted (commanded) value of positioner - need [n] as may be scanned - dimensions: - rank: 1 - dim: [[1, n]] - tolerance(NX_NUMBER): - unit: NX_ANY - doc: | - maximum allowable difference between target_value and value - dimensions: - rank: 1 - dim: [[1, n]] - soft_limit_min(NX_NUMBER): - unit: NX_ANY - doc: | - minimum allowed limit to set value - soft_limit_max(NX_NUMBER): - unit: NX_ANY - doc: | - maximum allowed limit to set value - velocity(NX_NUMBER): - unit: NX_ANY - doc: | - velocity of the positioner (distance moved per unit time) - acceleration_time(NX_NUMBER): - unit: NX_ANY - doc: | - time to ramp the velocity up to full speed - controller_record: - doc: | - Hardware device record, e.g. EPICS process variable, taco/tango ... - \@default: - doc: | - .. index':'':' plotting - - Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https':'//www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo':'':' - Add a definition for the reference point of a positioner. - (NXtransformations): - doc: | - 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. - - Position(NXtransformation): - doc: To clarify the frame laboratory frame. The scanning area in x, y, and z position in the frame. - unit: NX_LENGTH -#Z_contronller: -# Name: -# doc: | -# This controllers task is to continuously adjust the Z position of the stm tip in order to keep the selected control signal as close as possible to the Set Point. Different contro; signals lead to different contronller beahvior. - Z_offset(NX_NUMBER): - doc: Offset added to the initial averaged position Zaver before starting to swepp. - unit: NX_LENGTH - Tip_position_Z(NX_NUMBER): - doc: Indicate the tip position Z between tip and sample. The tip position can also be varied when the controller is not running. - unit: NX_LENGTH - Controller name(NX_CHAR): - doc: Controller name. This name which will be displayed at places where you can select a controller. - Setpoint(NX_NUMBER): - doc: Set Point is the desired value of the control signal. It can be set by editing the number or using the slider bar. Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. - unit: NX_CUTTENT - Setpoint unit(NX_CHAR): - doc: The unit of setpoint during the scanning. - P gain(NX_NUMBER): - doc: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows I = P/T. - unit: NX_LENGTH - I gain(NX_NUMBER): - doc: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows I = P/T. - unit: NX_ANY (NX_SPEED?) - Time const(NX_NUMBER): - doc: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows I = P/T. - unit: NX_TIME - TipLift(NX_NUMBER): - doc: Lifts the tip by the specified amount when then controller is switched off. This can be a positive or a negative number, i.e. the tip can also be moved towards the sample. Be careful with sign and value when using this feature. - unit: NX_LENGTH - Switch off delay(NX_NUMBER): - doc: Use this parameter for a reproducible position when switching off the Z-controller. When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. - unit: NX_TIME - Z-controller hold(NX_CHAR): - doc: (In bias spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. -#Scan contronller: -# name: -# doc: | -# To contron the tip and various scan operations. - scanfield(NX_NUMBER): - doc: Configure the scan frame like x position; y position; width; height. - unit: NX_LENGTH - pixels/line(NX_NUMBER): - doc: Scan resolution by setting the Lines equal to Pixels. - unit: NX_ANY - lines(NX_NUMBER): - doc: Define the image resolution. - unit: NX_ANY - speed forw.(NX_NUMBER): - doc: Define the scan forward speed in the forward direction. - unit: NX_ANY(NX_SPEED?) - speed backw.(NX_NUMBER): - doc: Define the scan backward speed in the forward direction. - unit: NX_ANY(NX_SPEED?) -#Piezo_calibration: -# name: -# doc: | -# Piezo calibration module is used to define the X Y Z piezos calibration. - calibr(NX_NUMBER): - doc: | - There are 3 parameters in X, Y, and Z directions and there are 3 controls available: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. - unit: NX_ANY - range(NX_NUMBER): - doc: Adjusts the amplitude range or amplitude of the Piezo output signal - unit: NX_LENGTH - HV_Gain(NX_NUMBER): - doc: For some systems HV gain readout is available, so for those systems the HV gain should be adjusted automatically when the gain is changed at the high voltage amplifier. - unit: NX_ANY - tilt(NX_NUMBER): - doc: There are 2 parameters in X and Y directions and this tab is used to set the sample tilt (in degrees, first order correction). - unit: NX_ANGLE - curvature radius(NX_NUMBER): - doc: There are 2 parameters in X and Y directions and this tab is used to set a curvature (can be set approximately to the length of the piezotube). - unit: NX_LENGTH - 2nd order corr: - doc: | - There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2) - drift(NX_NUMBER): - doc: There are 2 parameters in X and Y directions. Define the drift speed for all three axes. When the compensation is on, the piezos will start to move at that speed. - unit: NX_ANY (need NX_SPEED) - drift correction status(NX_CHAR): - doc: Use the button to turn on/off the drift compensation. - - - - - - - - - - - - - - From f66a3f3cf146eb75ef2584b4cd9b765c767c7e8e Mon Sep 17 00:00:00 2001 From: Yichen Date: Tue, 25 Apr 2023 17:27:10 +0200 Subject: [PATCH 0117/1012] Delete the backup file --- .../nyaml/NXamplifier.yaml.bp | 34 ------------------- 1 file changed, 34 deletions(-) delete mode 100644 contributed_definitions/nyaml/NXamplifier.yaml.bp diff --git a/contributed_definitions/nyaml/NXamplifier.yaml.bp b/contributed_definitions/nyaml/NXamplifier.yaml.bp deleted file mode 100644 index 9a1bb41fa7..0000000000 --- a/contributed_definitions/nyaml/NXamplifier.yaml.bp +++ /dev/null @@ -1,34 +0,0 @@ -doc: | - Application definition for amplifier devices. -category: base -NXamplifier: - hardware(NXfabrication): - doc: (IC, device) (NXmanufacturer?) - NumOfChannels(NX_NUMBER): - doc: The number of preamplifier channels are assgined. - ActiveChannels(NX_NUMBER): - doc: The number of preamplifier channels are ready tp to be used. (array for active channels) - openloop_amplification(NX_NUMBER): - doc: The output signal does not go through a feedback loop to adjust the amplification of the amplifier. (array for active channels) # From google. - amplification(NX_NUMBER): - doc: The ratio of the amplitude of the output signal to the amplitude of the input signal. (array for active channels) # From google. - signal_over_noise(NX_NUMBER): - doc: The ratio of the amplitue of the useful signal to the amplitude of the noise in the output signal of the amplifier. S/N=V_signal/V_noise. (array for active channels) - crosstalk_factor(NX_NUMBER): - doc: (if active >1) - crosstalk_compensation(NX_BOOLEAN): - bandwidth(NX_NUMBER): - doc: The spectrum of frequency it can amplify, from its lowest to highest frequency limits. - unit: NX_FREQUENCY - LowPass(NX_NUMBER): - doc: Order and cut-off frequency of the low-pass filter applied on the demodulated signals (X,Y). Cut-off frq (low pass filter) (foreach DemodulatorChannels) - unit: NX_FREQUENCY - HiPass(NX_NUMBER): - doc: Order and cut-off frequency of the high-pass filter applied on the demodulation signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) - unit: NX_FREQUENCY - type: - enumeration: [current, voltage] - Current amplifier factor(NX_NUMBER): - doc: (V/V) - Current amplifier Capacitive cross-talk compensation: - doc: From 4f1c2243cae234439b033ef2305cdc1a305b3ef2 Mon Sep 17 00:00:00 2001 From: Yichen Date: Tue, 25 Apr 2023 17:27:20 +0200 Subject: [PATCH 0118/1012] Delete the backup file --- contributed_definitions/nyaml/NXbias.yaml.bp | 65 -------------------- 1 file changed, 65 deletions(-) delete mode 100644 contributed_definitions/nyaml/NXbias.yaml.bp diff --git a/contributed_definitions/nyaml/NXbias.yaml.bp b/contributed_definitions/nyaml/NXbias.yaml.bp deleted file mode 100644 index cb51529cb3..0000000000 --- a/contributed_definitions/nyaml/NXbias.yaml.bp +++ /dev/null @@ -1,65 +0,0 @@ -doc: | - Application definition for bias devices. -category: base -NXbias(NXobject): - bias(NX_NUMBER): - doc: Applied a voltage between tip and sample. - unit: NX_VOLTAGE - tunneling resistor(NXcircuit): - doc: The ratio between the tunneling current at the sample surface and the bias voltage applied between between the sample and the tip. - unit: NX_ANY (No NX_resistance) - Calibration(NX_NUMBER): - doc: Calibration of the Bias output (V/V). - offset(NX_NUMBER): - doc: Allows compensating for an offset in Bias. Hardware parameter offset. - unit: NX_VOLTAGE - Modulated signal Bias(NXlockin): # or transfer it to NXlockin? - doc: Sets the amplitude (in physical units of the modulated signal) of the sine modulation. - unit: NX_VOLTAGE - Bias Spectroscopy(NXbias): - doc: Bias sweeps while measuring arbitrary channels with I(V) curves. - Channels(NX_CHAR): - doc: Select the channels to record. - Reset Bias(NX_CHAR): - doc: | - When selected, the Bias voltage returns to the initial value (before starting the sweep) at the end of the spectroscopy measurement (default). When not selected, Bias remains at the last value of the sweep. This is useful e.g. when combining several sweep segments. Example for an automated measurement (using Programming Interface): switch off Z-Controller, start spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, switch on Z-Controller. - Record final Z(NX_CHAR): - doc: Select whether to record the Z position during Z averaging time at the end of the sweep (after Z control time) and store the average value in the header of the file when saving. Using this option increases the sweep time by Z averaging time. - Lock-In run(NX_CHAR): - doc: Select whether to set the Lock-In to run during the measurement. When using this feature, make sure the Lock-In is configured correctly and settling times are set to twice the Lock-In period at least. This option is ignored when Lock-In is already running. This option is disabled if the Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline segment editor is set. - Number of sweeps(NX_NUMBER): - doc: Number of sweeps to measure and average. - Sweep Start(NX_NUMBER): - doc: The first bias values of the sweep. - unit: NX_VOLTAGE - Sweep End(NX_NUMBER): - doc: The last bias values of the sweep. - unit: NX_VOLTAGE - Num Pixel(NX_NUMBER): - doc: Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. - Z Avg time(NX_NUMBER): - doc: Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). - unit: NX_TIME - Z offset(NX_NUMBER): - doc: Offset added to the initial averaged position Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an alternate Z-controller setpoint is enabled. - unit: NX_LENGTH - Settling time(NX_NUMBER): - doc: time to wait after changing the bias to the next level and before starting to acquire data. - unit: NX_TIME - Integration time(NX_NUMBER): - doc: Time during which the data are acquired and averaged. - unit: NX_TIME - End Settling time(NX_NUMBER): - doc: Time to wait after the sweep has finished and the bias is ramped to the initial value. - unit: NX_TIME - Z control time(NX_NUMBER): - doc: Time during which the Z-Controller is enabled once a sweep has finished. When averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled for this duration between each sweep. After the last sweep, it will wait the specified time before continuing a running scan. This ensures each sweep reliably starts from the same position. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. - unit: NX_TIME - Max Slew rate(NX_NUMBER): - doc: Maximum rate at which the bias changes (before, during and after sweeping). (V/s) - backward sweep(NX_CHAR): - doc: Select whether to measure the backward (return) sweep or the forward only. - Z-controller hold(NX_CHAR): - doc: Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. - - From a6097fc206f17932fde18d8604241492a1adbc0e Mon Sep 17 00:00:00 2001 From: Yichen Date: Tue, 25 Apr 2023 17:27:30 +0200 Subject: [PATCH 0119/1012] Delete the backup file --- .../nyaml/NXcircuit.yaml.bp | 35 ------------------- 1 file changed, 35 deletions(-) delete mode 100644 contributed_definitions/nyaml/NXcircuit.yaml.bp diff --git a/contributed_definitions/nyaml/NXcircuit.yaml.bp b/contributed_definitions/nyaml/NXcircuit.yaml.bp deleted file mode 100644 index 15e4dec7ac..0000000000 --- a/contributed_definitions/nyaml/NXcircuit.yaml.bp +++ /dev/null @@ -1,35 +0,0 @@ -doc: | - Application definition for circuit devices. -category: base -NXcircuit: - hardware(NX_FABRICATION): - doc: (NXmanufacturer?) - Tunneling Current(NX_NUMBER): - doc: The tunneling current between tip and sample after application of bias voltage. - unit: NX_CURRENT - Calibration(NX_NUMBER): - doc: Calibration of the current measurement (A/V). - Offset(NX_NUMBER): - doc: Offset of the current measurement. - unit: NX_CURRENT - channels(NX_CHAR): - doc: The scan channels are selected by users (in scan contronaller). - RT Frequency(NX_NUMBER): - doc: The bandwitdh of the Hardware and/or Software - unit: NX_FREQUENCY - Signals Oversampling(NX_NUMBER): - doc: (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. - unit: NX_ANY - Acquisition Period(NX_NUMBER): - doc: Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. - unit: NX_TIME - Animations Period(NX_NUMBER): - doc: Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. - unit: NX_TIME - Indicators Period(NX_NUMBER): - doc: Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. - unit: NX_TIME - Measurements Period(NX_NUMBER): - doc: The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. - unit: NX_TIME - From 8d1447e6fc0d50630364f8f0d5fb80ccb2602517 Mon Sep 17 00:00:00 2001 From: Yichen Date: Tue, 25 Apr 2023 17:27:43 +0200 Subject: [PATCH 0120/1012] Delete the backup file --- .../nyaml/NXlockin.yaml.bp | 39 ------------------- 1 file changed, 39 deletions(-) delete mode 100644 contributed_definitions/nyaml/NXlockin.yaml.bp diff --git a/contributed_definitions/nyaml/NXlockin.yaml.bp b/contributed_definitions/nyaml/NXlockin.yaml.bp deleted file mode 100644 index 652cf1ac78..0000000000 --- a/contributed_definitions/nyaml/NXlockin.yaml.bp +++ /dev/null @@ -1,39 +0,0 @@ -doc: | - Application definition for lock in devices. -category: base -NXlockin: - hardware(NXfabrication): - (NXamplifier): - doc: input and output amplifiers - Modulate signal(NX_CHAR): - doc: This is the signal on which the modulation (sine) will be added, such as current, bias, et.al. - Amplitude(NX_NUMBER): - doc: Sets the amplitude (in physical units of the modulated signal) of the sine modulation. - unit: NX_VOLTAGE (For bais modulate signal, it depands on the modulate type) - frequency(NX_NUMBER): - doc: Sets the frequency of the sine modulation added to the signal to modulate. - unit: NX_FREQUENCY - Demodulated signal(NX_CHAR): - doc: This is the signal which will be demodulated, in order to determine the amplitude and phase at the frequency set in the Frequency field or harmonics, such as current, bias, et.al. - #output (demodulated signal) characterisation (foreach channel, like demodulation, a separate sensor output, e.g. X,Y) - NumOfDemodulatorChannels(NX_NUMBER): - doc: The number of signals which will be demodulated. - LowPass(NX_NUMBER): - doc: Order and cut-off frequency of the low-pass filter applied on the demodulated signals (X,Y). Cut-off frq (low pass filter) (foreach DemodulatorChannels) - unit: NX_FREQUENCY - HiPass(NX_NUMBER): - doc: Order and cut-off frequency of the high-pass filter applied on the demodulation signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) - unit: NX_FREQUENCY - Sync(NX_CHAR): - doc: Switch the Sync filter on the demodulated signals (X,Y) on or off. (foreach DemodulatorChannels) - refPhase(NX_NUMBER): - doc: Reference phase for the sine on the demodulated signal with respect to the modulation signal. (foreach DemodulatorChannels) - unit: NX_FREQUENCY - integrationTime(NX_NUMBER): - doc: Time during which the data are acquired and averaged. (for the input filter) - unit: NX_TIME - OrderOfHarmonics(NX_NUMBER): - doc: The order of the harmonic oscillation to detect on the demodulated signals. (with respect to the modulation frequency) - sensitivityFactor(NX_NUMBER): - doc: Ratio of output signal amplitude to input signal amplitue (V/V). (input gain) # Not sure about it. - From 35f006c8c5d0e11e72affdd511684b5428ca4fcb Mon Sep 17 00:00:00 2001 From: Yichen Date: Tue, 25 Apr 2023 17:27:54 +0200 Subject: [PATCH 0121/1012] Delete the backup file --- .../nyaml/NXpositioner.yaml.bp | 181 ------------------ 1 file changed, 181 deletions(-) delete mode 100644 contributed_definitions/nyaml/NXpositioner.yaml.bp diff --git a/contributed_definitions/nyaml/NXpositioner.yaml.bp b/contributed_definitions/nyaml/NXpositioner.yaml.bp deleted file mode 100644 index 8c08aad57f..0000000000 --- a/contributed_definitions/nyaml/NXpositioner.yaml.bp +++ /dev/null @@ -1,181 +0,0 @@ -category: base -doc: | - A generic positioner such as a motor or piezo-electric transducer. - -type: group -NXpositioner(NXobject): - name: - doc: | - symbolic or mnemonic name (one word) - description: - doc: | - description of positioner - value(NX_NUMBER): - unit: NX_ANY - doc: | - best known value of positioner - need [n] as may be scanned - dimensions: - rank: 1 - dim: [[1, n]] - raw_value(NX_NUMBER): - unit: NX_ANY - doc: | - raw value of positioner - need [n] as may be scanned - dimensions: - rank: 1 - dim: [[1, n]] - target_value(NX_NUMBER): - unit: NX_ANY - doc: | - targeted (commanded) value of positioner - need [n] as may be scanned - dimensions: - rank: 1 - dim: [[1, n]] - tolerance(NX_NUMBER): - unit: NX_ANY - doc: | - maximum allowable difference between target_value and value - dimensions: - rank: 1 - dim: [[1, n]] - soft_limit_min(NX_NUMBER): - unit: NX_ANY - doc: | - minimum allowed limit to set value - soft_limit_max(NX_NUMBER): - unit: NX_ANY - doc: | - maximum allowed limit to set value - velocity(NX_NUMBER): - unit: NX_ANY - doc: | - velocity of the positioner (distance moved per unit time) - acceleration_time(NX_NUMBER): - unit: NX_ANY - doc: | - time to ramp the velocity up to full speed - controller_record: - doc: | - Hardware device record, e.g. EPICS process variable, taco/tango ... - \@default: - doc: | - .. index':'':' plotting - - Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https':'//www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo':'':' - Add a definition for the reference point of a positioner. - (NXtransformations): - doc: | - 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. - - Position(NXtransformation): - doc: To clarify the frame laboratory frame. The scanning area in x, y, and z position in the frame. - unit: NX_LENGTH - Z_contronller: - doc: | - This controllers task is to continuously adjust the Z position of the stm tip in order to keep the selected control signal as close as possible to the Set Point. Different contro; signals lead to different contronller beahvior. - Z_offset(NX_NUMBER): - doc: Offset added to the initial averaged position Zaver before starting to swepp. - unit: NX_LENGTH - Tip_position_Z(NX_NUMBER): - doc: Indicate the tip position Z between tip and sample. The tip position can also be varied when the controller is not running. - unit: NX_LENGTH - Controller name(NX_CHAR): - doc: Controller name. This name which will be displayed at places where you can select a controller. - Setpoint(NX_NUMBER): - doc: Set Point is the desired value of the control signal. It can be set by editing the number or using the slider bar. Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. - unit: NX_CUTTENT - Setpoint unit(NX_CHAR): - doc: The unit of setpoint during the scanning. - P gain(NX_NUMBER): - dos: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. - unit: NX_LENGTH - I gain(NX_NUMBER): - dos: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. - unit: NX_ANY (NX_SPEED?) - Time const(NX_NUMBER): - dos: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. - unit: NX_TIME - TipLift(NX_NUMBER): - doc: Lifts the tip by the specified amount when then controller is switched off. This can be a positive or a negative number, i.e. the tip can also be moved towards the sample. Be careful with sign and value when using this feature. - unit: NX_LENGTH - Switch off delay(NX_NUMBER): - doc: Use this parameter for a reproducible position when switching off the Z-controller. When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. - unit: NX_TIME - Z-controller hold(NX_CHAR): - doc: (In biase spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. - Scan contronller: - doc: | - To contron the tip and various scan operations. - scanfield(NX_NUMBER): - doc: Configure the scan frame: x position; y position; width; height. - unit: NX_LENGTH - pixels/line(NX_NUMBER): - doc: Scan resolution by setting the Lines equal to Pixels. - unit: NX_ANY - lines(NX_NUMBER): - doc: Define the image resolution. - unit: NX_ANY - speed forw.(NX_NUMBER): - doc: Define the scan forward speed in the forward direction. - unit: NX_ANY(NX_SPEED?) - speed backw.(NX_NUMBER): - doc: Define the scan backward speed in the forward direction. - unit: NX_ANY(NX_SPEED?) - Piezo_calibration: - doc: | - Piezo calibration module is used to define the X Y Z piezos calibration. - calibr(NX_NUMBER): - doc: There are 3 parameters in X, Y, and Z directions and there are 3 controls available: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. - unit: NX_ANY - range(NX_NUMBER): - doc: Adjusts the amplitude range or amplitude of the Piezo output signal - unit: NX_LENGTH - HV_Gain(NX_NUMBER): - doc: For some systems HV gain readout is available, so for those systems the HV gain should be adjusted automatically when the gain is changed at the high voltage amplifier. - unit: NX_ANY - tilt(NX_NUMBER): - doc: There are 2 parameters in X and Y directions and this tab is used to set the sample tilt (in degrees, first order correction). - unit: NX_ANGLE - curvature radius(NX_NUMBER): - doc: There are 2 parameters in X and Y directions and this tab is used to set a curvature (can be set approximately to the length of the piezotube). - unit: NX_LENGTH - 2nd order corr: - doc: There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2) - drift(NX_NUMBER): - doc: There are 2 parameters in X and Y directions. Define the drift speed for all three axes. When the compensation is on, the piezos will start to move at that speed. - unit: NX_ANY (need NX_SPEED) - drift correction status(NX_CHAR): - doc: Use the button to turn on/off the drift compensation. - - - - - - - - - - - - - - From bb499451ac959dc7e853c278596bff41fcd9bb28 Mon Sep 17 00:00:00 2001 From: Yichen Date: Tue, 25 Apr 2023 17:28:05 +0200 Subject: [PATCH 0122/1012] Delete the backup file --- .../nyaml/NXsensor.yaml.bp | 141 ------------------ 1 file changed, 141 deletions(-) delete mode 100644 contributed_definitions/nyaml/NXsensor.yaml.bp diff --git a/contributed_definitions/nyaml/NXsensor.yaml.bp b/contributed_definitions/nyaml/NXsensor.yaml.bp deleted file mode 100644 index 9284f54c59..0000000000 --- a/contributed_definitions/nyaml/NXsensor.yaml.bp +++ /dev/null @@ -1,141 +0,0 @@ -category: base -doc: | - A sensor used to monitor an external condition - - The condition itself is described in ':'ref':'`NXenvironment`. - -type: group -NXsensor(NXobject): - model: - doc: | - Sensor identification code/model number - name: - doc: | - Name for the sensor - short_name: - doc: | - Short name of sensor used e.g. on monitor display program - attached_to: - doc: | - where sensor is attached to ("sample" | "can") - geometry(NXgeometry): - deprecated: Use the field `depends_on` and ':'ref':'`NXtransformations` to position the beamstop and NXoff_geometry to describe its shape instead - doc: | - Defines the axes for logged vector quantities if they are not the global instrument axes. - measurement: - doc: | - name for measured signal - enumeration: [temperature, pH, magnetic_field, electric_field, conductivity, resistance, voltage, current, pressure, flow, stress, strain, shear, surface_pressure] - type: - doc: | - The type of hardware used for the measurement. - Examples (suggestions but not restrictions)':' - - ':'Temperature':' - J | K | T | E | R | S | Pt100 | Pt1000 | Rh/Fe - ':'pH':' - Hg/Hg2Cl2 | Ag/AgCl | ISFET - ':'Ion selective electrode':' - specify species; e.g. Ca2+ - ':'Magnetic field':' - Hall - ':'Surface pressure':' - wilhelmy plate - amplifier(NXamplifier): - second_amplifier(NX_circuit): - doc: link to second amplifer circuit with 1MOhm - run_control(NX_BOOLEAN): - doc: | - Is data collection controlled or synchronised to this quantity':' - 1=no, 0=to "value", 1=to "value_deriv1", etc. - high_trip_value(NX_FLOAT): - unit: NX_ANY - doc: | - Upper control bound of sensor reading if using run_control - low_trip_value(NX_FLOAT): - unit: NX_ANY - doc: | - Lower control bound of sensor reading if using run_control - value(NX_FLOAT): - unit: NX_ANY - doc: | - nominal setpoint or average value - - need [n] as may be a vector - dimensions: - dim: [[1, n]] - value_deriv1(NX_FLOAT): - unit: NX_ANY - doc: | - Nominal/average first derivative of value - e.g. strain rate - - same dimensions as "value" (may be a vector) - dimensions: - dim: [[1, ]] - dim_parameters: - ref: ['value'] - value_deriv2(NX_FLOAT): - unit: NX_ANY - doc: | - Nominal/average second derivative of value - - same dimensions as "value" (may be a vector) - dimensions: - dim: [[1, ]] - dim_parameters: - ref: ['value'] - value_log(NXlog): - doc: | - Time history of sensor readings - value_deriv1_log(NXlog): - doc: | - Time history of first derivative of sensor readings - value_deriv2_log(NXlog): - doc: | - Time history of second derivative of sensor readings - external_field_brief: - enumeration: [along beam, across beam, transverse, solenoidal, flow shear gradient, flow vorticity] - external_field_full(NXorientation): - doc: | - For complex external fields not satisfied by External_field_brief - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the sensor when necessary. - \@default: - doc: | - .. index':'':' plotting - - Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https':'//www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo':'':' - Add a definition for the reference point of a sensor. - (NXtransformations): - doc: | - 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. - ############## - Temperature(NX_sensor): - doc: External sensors connected to the device. For example, T1, temperature of STM head. T2, temperature of bottom of LHe helium cryostat. T3, temperature of LN2 nitrogen shield. - unit: NX_TEMPERATURE - Pressure(NX_sensor): - doc: External sensors connected to the device. Pressure of each chamber or ion pump, such as prepare chamber and analysis chamber - unit: NX_PRESSURE - Power Spectral Density (NX_sensor): - doc: The power present in the signal as a function of frequency. Used to characterise the vibration and noise of scanning probes to detect and reduce the impact on resolution during STM imaging - - From 42f1cbb71224d2c8acb4733e712bbdb40509818f Mon Sep 17 00:00:00 2001 From: Rubel Date: Wed, 14 Jun 2023 10:53:25 +0200 Subject: [PATCH 0123/1012] fix conflict in rebase --- .../nyaml/NXamplifier.yaml | 61 +++++---- contributed_definitions/nyaml/NXbias.yaml | 121 +++++++++--------- contributed_definitions/nyaml/NXcircuit.yaml | 60 ++++----- contributed_definitions/nyaml/NXlockin.yaml | 90 ++++++------- contributed_definitions/nyaml/NXsensor.yaml | 6 +- 5 files changed, 169 insertions(+), 169 deletions(-) diff --git a/contributed_definitions/nyaml/NXamplifier.yaml b/contributed_definitions/nyaml/NXamplifier.yaml index 9a1bb41fa7..4fef3f80ba 100644 --- a/contributed_definitions/nyaml/NXamplifier.yaml +++ b/contributed_definitions/nyaml/NXamplifier.yaml @@ -1,34 +1,33 @@ doc: | - Application definition for amplifier devices. + Base classed definition for amplifier devices. category: base NXamplifier: - hardware(NXfabrication): - doc: (IC, device) (NXmanufacturer?) - NumOfChannels(NX_NUMBER): - doc: The number of preamplifier channels are assgined. - ActiveChannels(NX_NUMBER): - doc: The number of preamplifier channels are ready tp to be used. (array for active channels) - openloop_amplification(NX_NUMBER): - doc: The output signal does not go through a feedback loop to adjust the amplification of the amplifier. (array for active channels) # From google. - amplification(NX_NUMBER): - doc: The ratio of the amplitude of the output signal to the amplitude of the input signal. (array for active channels) # From google. - signal_over_noise(NX_NUMBER): - doc: The ratio of the amplitue of the useful signal to the amplitude of the noise in the output signal of the amplifier. S/N=V_signal/V_noise. (array for active channels) - crosstalk_factor(NX_NUMBER): - doc: (if active >1) - crosstalk_compensation(NX_BOOLEAN): - bandwidth(NX_NUMBER): - doc: The spectrum of frequency it can amplify, from its lowest to highest frequency limits. - unit: NX_FREQUENCY - LowPass(NX_NUMBER): - doc: Order and cut-off frequency of the low-pass filter applied on the demodulated signals (X,Y). Cut-off frq (low pass filter) (foreach DemodulatorChannels) - unit: NX_FREQUENCY - HiPass(NX_NUMBER): - doc: Order and cut-off frequency of the high-pass filter applied on the demodulation signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) - unit: NX_FREQUENCY - type: - enumeration: [current, voltage] - Current amplifier factor(NX_NUMBER): - doc: (V/V) - Current amplifier Capacitive cross-talk compensation: - doc: + hardware(NXfabrication): + doc: (IC, device) (NXmanufacturer?) + NumOfChannels(NX_NUMBER): + doc: The number of preamplifier channels are assgined. + ActiveChannels(NX_NUMBER): + doc: The number of preamplifier channels are ready tp to be used. (array for active channels) + openloop_amplification(NX_NUMBER): + doc: The output signal does not go through a feedback loop to adjust the amplification of the amplifier. (array for active channels) # From google. + amplification(NX_NUMBER): + doc: The ratio of the amplitude of the output signal to the amplitude of the input signal. (array for active channels) # From google. + signal_over_noise(NX_NUMBER): + doc: The ratio of the amplitue of the useful signal to the amplitude of the noise in the output signal of the amplifier. S/N=V_signal/V_noise. (array for active channels) + crosstalk_factor(NX_NUMBER): + doc: (if active >1) + crosstalk_compensation(NX_BOOLEAN): + doc: for reducing interferences between different signalling pathways + bandwidth(NX_NUMBER): + doc: The spectrum of frequency it can amplify, from its lowest to highest frequency limits. + unit: NX_FREQUENCY + LowPass(NX_NUMBER): + doc: Order and cut-off frequency of the low-pass filter applied on the demodulated signals (X,Y). Cut-off frq (low pass filter) (foreach DemodulatorChannels) + unit: NX_FREQUENCY + HiPass(NX_NUMBER): + doc: Order and cut-off frequency of the high-pass filter applied on the demodulation signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) + unit: NX_FREQUENCY + Current amplifier factor(NX_NUMBER): + doc: Current Amplifier Factor typically refers to the gain of the probe current amplifier. (V/V) + Current amplifier Capacitive cross-talk compensation(NX_CHAR): + doc: Reduces the effect of capacitive crosstalk in the circuit on experimental results. diff --git a/contributed_definitions/nyaml/NXbias.yaml b/contributed_definitions/nyaml/NXbias.yaml index d2e8e091fb..51f5a72796 100644 --- a/contributed_definitions/nyaml/NXbias.yaml +++ b/contributed_definitions/nyaml/NXbias.yaml @@ -1,65 +1,66 @@ doc: | Application definition for bias devices. category: base -NXbias: - NXbias(NXobject): - doc: Applied a voltage between tip and sample. - unit: NX_VOLTAGE - tunneling resistor(NXcircuit): - doc: The ratio between the tunneling current at the sample surface and the bias voltage applied between between the sample and the tip. - unit: NX_ANY (No NX_resistance) - Calibration(NX_NUMBER): - doc: Calibration of the Bias output (V/V). - offset(NX_NUMBER): - doc: Allows compensating for an offset in Bias. Hardware parameter offset. - unit: NX_VOLTAGE - Modulated signal Bias(NXlockin): # or transfer it to NXlockin? - doc: Sets the amplitude (in physical units of the modulated signal) of the sine modulation. - unit: NX_VOLTAGE - Bias Spectroscopy(NXbias): - doc: Bias sweeps while measuring arbitrary channels with I(V) curves. - Channels(NX_CHAR): - doc: Select the channels to record. - Reset Bias(NX_CHAR): - doc: | - When selected, the Bias voltage returns to the initial value (before starting the sweep) at the end of the spectroscopy measurement (default). When not selected, Bias remains at the last value of the sweep. This is useful e.g. when combining several sweep segments. Example for an automated measurement (using Programming Interface): switch off Z-Controller, start spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, switch on Z-Controller. - Record final Z(NX_CHAR): - doc: Select whether to record the Z position during Z averaging time at the end of the sweep (after Z control time) and store the average value in the header of the file when saving. Using this option increases the sweep time by Z averaging time. - Lock-In run(NX_CHAR): - doc: Select whether to set the Lock-In to run during the measurement. When using this feature, make sure the Lock-In is configured correctly and settling times are set to twice the Lock-In period at least. This option is ignored when Lock-In is already running. This option is disabled if the Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline segment editor is set. - Number of sweeps(NX_NUMBER): - doc: Number of sweeps to measure and average. - Sweep Start(NX_NUMBER): - doc: The first bias values of the sweep. - unit: NX_VOLTAGE - Sweep End(NX_NUMBER): - doc: The last bias values of the sweep. - unit: NX_VOLTAGE - Num Pixel(NX_NUMBER): - doc: Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. - Z Avg time(NX_NUMBER): - doc: Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). - unit: NX_TIME - Z offset(NX_NUMBER): - doc: Offset added to the initial averaged position Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an alternate Z-controller setpoint is enabled. - unit: NX_LENGTH - Settling time(NX_NUMBER): - doc: time to wait after changing the bias to the next level and before starting to acquire data. - unit: NX_TIME - Integration time(NX_NUMBER): - doc: Time during which the data are acquired and averaged. - unit: NX_TIME - End Settling time(NX_NUMBER): - doc: Time to wait after the sweep has finished and the bias is ramped to the initial value. - unit: NX_TIME - Z control time(NX_NUMBER): - doc: Time during which the Z-Controller is enabled once a sweep has finished. When averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled for this duration between each sweep. After the last sweep, it will wait the specified time before continuing a running scan. This ensures each sweep reliably starts from the same position. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. - unit: NX_TIME - Max Slew rate(NX_NUMBER): - doc: Maximum rate at which the bias changes (before, during and after sweeping). (V/s) - backward sweep(NX_CHAR): - doc: Select whether to measure the backward (return) sweep or the forward only. - Z-controller hold(NX_CHAR): - doc: Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. +NXbias(NXobject): + bias(NX_NUMBER): + doc: Applied a voltage between tip and sample. + unit: NX_VOLTAGE + tunneling resistor(NX_NUMBER): + doc: The ratio between the tunneling current at the sample surface and the bias voltage applied between between the sample and the tip. + unit: NX_ANY (No NX_resistance) + Calibration(NX_NUMBER): + doc: Calibration of the Bias output (V/V). + offset(NX_NUMBER): + doc: Allows compensating for an offset in Bias. Hardware parameter offset. + unit: NX_VOLTAGE + Modulated signal Bias(NX_NUMBER): # or transfer it to NXlockin? + doc: Sets the amplitude (in physical units of the modulated signal) of the sine modulation. + unit: NX_VOLTAGE + (Bias Spectroscopy): + doc: Bias sweeps while measuring arbitrary channels with I(V) curves. + Channels(NX_CHAR): + doc: Select the channels to record. + Reset Bias(NX_BOOLEAN): + doc: | + When selected, the Bias voltage returns to the initial value (before starting the sweep) at the end of the spectroscopy measurement (default). When not selected, Bias remains at the last value of the sweep. This is useful e.g. when combining several sweep segments. Example for an automated measurement (using Programming Interface): switch off Z-Controller, start spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, switch on Z-Controller. + Record final Z(NX_BOOLEAN): + doc: Select whether to record the Z position during Z averaging time at the end of the sweep (after Z control time) and store the average value in the header of the file when saving. Using this option increases the sweep time by Z averaging time. + Lock-In run(NX_BOOLEAN): + doc: Select whether to set the Lock-In to run during the measurement. When using this feature, make sure the Lock-In is configured correctly and settling times are set to twice the Lock-In period at least. This option is ignored when Lock-In is already running. This option is disabled if the Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline segment editor is set. + Integration time(NX_NUMBER): + doc: Time during which the spectroscopy data are acquired and averaged. + unit: NX_TIME + Number of sweeps(NX_NUMBER): + doc: Number of sweeps to measure and average. + Sweep Start(NX_NUMBER): + doc: The first bias values of the sweep. + unit: NX_VOLTAGE + Sweep End(NX_NUMBER): + doc: The last bias values of the sweep. + unit: NX_VOLTAGE + Num Pixel(NX_NUMBER): + doc: Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. + Z Avg time(NX_NUMBER): + doc: Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). + unit: NX_TIME + Z offset(NX_NUMBER): + doc: Offset added to the initial averaged position Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an alternate Z-controller setpoint is enabled. + unit: NX_LENGTH + Settling time(NX_NUMBER): + doc: time to wait after changing the bias to the next level and before starting to acquire data. + unit: NX_TIME + End Settling time(NX_NUMBER): + doc: Time to wait after the sweep has finished and the bias is ramped to the initial value. + unit: NX_TIME + Z control time(NX_NUMBER): + doc: Time during which the Z-Controller is enabled once a sweep has finished. When averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled for this duration between each sweep. After the last sweep, it will wait the specified time before continuing a running scan. This ensures each sweep reliably starts from the same position. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. + unit: NX_TIME + Max Slew rate(NX_NUMBER): + doc: Maximum rate at which the bias changes (before, during and after sweeping). (V/s) + backward sweep(NX_BOOLEAN): + doc: Select whether to measure the backward (return) sweep or the forward only. + Z-controller hold(NX_BOOLEAN): + doc: Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. + diff --git a/contributed_definitions/nyaml/NXcircuit.yaml b/contributed_definitions/nyaml/NXcircuit.yaml index 15e4dec7ac..722f133f9c 100644 --- a/contributed_definitions/nyaml/NXcircuit.yaml +++ b/contributed_definitions/nyaml/NXcircuit.yaml @@ -2,34 +2,34 @@ doc: | Application definition for circuit devices. category: base NXcircuit: - hardware(NX_FABRICATION): - doc: (NXmanufacturer?) - Tunneling Current(NX_NUMBER): - doc: The tunneling current between tip and sample after application of bias voltage. - unit: NX_CURRENT - Calibration(NX_NUMBER): - doc: Calibration of the current measurement (A/V). - Offset(NX_NUMBER): - doc: Offset of the current measurement. - unit: NX_CURRENT - channels(NX_CHAR): - doc: The scan channels are selected by users (in scan contronaller). - RT Frequency(NX_NUMBER): - doc: The bandwitdh of the Hardware and/or Software - unit: NX_FREQUENCY - Signals Oversampling(NX_NUMBER): - doc: (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. - unit: NX_ANY - Acquisition Period(NX_NUMBER): - doc: Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. - unit: NX_TIME - Animations Period(NX_NUMBER): - doc: Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. - unit: NX_TIME - Indicators Period(NX_NUMBER): - doc: Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. - unit: NX_TIME - Measurements Period(NX_NUMBER): - doc: The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. - unit: NX_TIME + hardware(NX_FABRICATION): + doc: (NXmanufacturer?) + Tunneling Current(NX_NUMBER): + doc: The tunneling current between tip and sample after application of bias voltage. + unit: NX_CURRENT + Calibration(NX_NUMBER): + doc: Calibration of the current measurement (A/V). + Offset(NX_NUMBER): + doc: Offset of the current measurement. + unit: NX_CURRENT + channels(NX_CHAR): + doc: The scan channels are selected by users (in scan contronaller). + RT Frequency(NX_NUMBER): + doc: The bandwitdh of the Hardware and/or Software + unit: NX_FREQUENCY + Signals Oversampling(NX_NUMBER): + doc: (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. + unit: NX_ANY + Acquisition Period(NX_NUMBER): + doc: Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. + unit: NX_TIME + Animations Period(NX_NUMBER): + doc: Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. + unit: NX_TIME + Indicators Period(NX_NUMBER): + doc: Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. + unit: NX_TIME + Measurements Period(NX_NUMBER): + doc: The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. + unit: NX_TIME diff --git a/contributed_definitions/nyaml/NXlockin.yaml b/contributed_definitions/nyaml/NXlockin.yaml index e3283affa0..8530c2b903 100644 --- a/contributed_definitions/nyaml/NXlockin.yaml +++ b/contributed_definitions/nyaml/NXlockin.yaml @@ -1,49 +1,49 @@ doc: | - Application definition for lock in devices. + Base classes definition for lock in devices. category: base NXlockin: - hardware(NXfabrication): - (NXamplifier): - doc: input and output amplifiers - Modulate signal(NX_CHAR): - doc: This is the signal on which the modulation (sine) will be added, such as current, bias, et.al. - Amplitude(NX_NUMBER): - doc: Sets the amplitude (in physical units of the modulated signal) of the sine modulation. - unit: NX_VOLTAGE (For bais modulate signal, it depands on the modulate type) - frequency(NX_NUMBER): - doc: Sets the frequency of the sine modulation added to the signal to modulate. - unit: NX_FREQUENCY - Demodulated signal(NX_CHAR): - doc: This is the signal which will be demodulated, in order to determine the amplitude and phase at the frequency set in the Frequency field or harmonics, such as current, bias, et.al. - #output (demodulated signal) characterisation (foreach channel, like demodulation, a separate sensor output, e.g. X,Y) - NumOfDemodulatorChannels(NX_NUMBER): - doc: The number of signals which will be demodulated. - LowPass(NX_NUMBER): - doc: Order and cut-off frequency of the low-pass filter applied on the demodulated signals (X,Y). Cut-off frq (low pass filter) (foreach DemodulatorChannels) - unit: NX_FREQUENCY - HiPass(NX_NUMBER): - doc: Order and cut-off frequency of the high-pass filter applied on the demodulation signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) - unit: NX_FREQUENCY - LP Filter Cutoff(NX_NUMBER): - doc: Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) value) for D1. The filter is applied to the demodulated signals (X,Y). - unit: NX_FREQUENCY - LP Filter Order(NX_NUMBER): - doc: Order and cut-off frequency of the low-pass filter applied on the demodulated signals (X,Y). Reducing the bandwidth or increasing the order reduces noise on the demodulated signals, but will require longer settling and measurement times. - HP Filter Cutoff(NX_NUMBER): - doc: Sets the cut-off frequency of the high-pass filter (affects the displayed TC (s) value) for D1. The filter is applied to the demodulated signals (X,Y). - unit: NX_FREQUENCY - HP Filter Order(NX_NUMBER): - doc: Order and cut-off frequency of the high-pass filter applied on the demodulation signal of D!. This is used mainly to suppress a DC component of the demodulation signal, which would lead to a component at modulation frequency in the demodulated signals. - Sync(NX_CHAR): - doc: Switch on/off the Sync filter on the demodulated signals (X,Y) on or off. (foreach DemodulatorChannels) - refPhase(NX_NUMBER): - doc: Reference phase for the sine on the demodulated signal with respect to the modulation signal. (foreach DemodulatorChannels) - unit: NX_FREQUENCY - integrationTime(NX_NUMBER): - doc: Time during which the data are acquired and averaged. (for the input filter) - unit: NX_TIME - OrderOfHarmonics(NX_NUMBER): - doc: The order of the harmonic oscillation to detect on the demodulated signals. (with respect to the modulation frequency) - sensitivityFactor(NX_NUMBER): - doc: Ratio of output signal amplitude to input signal amplitue (V/V). (input gain) # Not sure about it. + hardware(NXfabrication): + (NXamplifier): + doc: input and output amplifiers + Modulate signal(NX_CHAR): + doc: This is the signal on which the modulation (sine) will be added, such as current, bias, et.al. + Amplitude(NX_NUMBER): + doc: Sets the amplitude (in physical units of the modulated signal) of the sine modulation. + unit: NX_VOLTAGE (For bais modulate signal, it depands on the modulate type) + frequency(NX_NUMBER): + doc: Sets the frequency of the sine modulation added to the signal to modulate. + unit: NX_FREQUENCY + Demodulated signal(NX_CHAR): + doc: This is the signal which will be demodulated, in order to determine the amplitude and phase at the frequency set in the Frequency field or harmonics, such as current, bias, et.al. + #output (demodulated signal) characterisation (foreach channel, like demodulation, a separate sensor output, e.g. X,Y) + NumOfDemodulatorChannels(NX_NUMBER): + doc: The number of signals which will be demodulated. + LowPass(NX_NUMBER): + doc: Order and cut-off frequency of the low-pass filter applied on the demodulated signals (X,Y). Cut-off frq (low pass filter) (foreach DemodulatorChannels) + unit: NX_FREQUENCY + HiPass(NX_NUMBER): + doc: Order and cut-off frequency of the high-pass filter applied on the demodulation signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) + unit: NX_FREQUENCY + LP Filter Cutoff(NX_NUMBER): + doc: Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) value) for D1. The filter is applied to the demodulated signals (X,Y). + unit: NX_FREQUENCY + LP Filter Order(NX_NUMBER): + doc: Order and cut-off frequency of the low-pass filter applied on the demodulated signals (X,Y). Reducing the bandwidth or increasing the order reduces noise on the demodulated signals, but will require longer settling and measurement times. + HP Filter Cutoff(NX_NUMBER): + doc: Sets the cut-off frequency of the high-pass filter (affects the displayed TC (s) value) for D1. The filter is applied to the demodulated signals (X,Y). + unit: NX_FREQUENCY + HP Filter Order(NX_NUMBER): + doc: Order and cut-off frequency of the high-pass filter applied on the demodulation signal of D!. This is used mainly to suppress a DC component of the demodulation signal, which would lead to a component at modulation frequency in the demodulated signals. + Sync(NX_BOOLEAN): + doc: Switch on/off the Sync filter on the demodulated signals (X,Y) on or off. (foreach DemodulatorChannels) + refPhase(NX_NUMBER): + doc: Reference phase for the sine on the demodulated signal with respect to the modulation signal. (foreach DemodulatorChannels) + unit: NX_FREQUENCY + integrationTime(NX_NUMBER): + doc: Time during which the data are acquired and averaged. (for the input filter) + unit: NX_TIME + OrderOfHarmonics(NX_NUMBER): + doc: The order of the harmonic oscillation to detect on the demodulated signals. (with respect to the modulation frequency) + sensitivityFactor(NX_NUMBER): + doc: Ratio of output signal amplitude to input signal amplitue (V/V). (input gain) # Not sure about it. diff --git a/contributed_definitions/nyaml/NXsensor.yaml b/contributed_definitions/nyaml/NXsensor.yaml index a3d8a54405..9ab4452156 100644 --- a/contributed_definitions/nyaml/NXsensor.yaml +++ b/contributed_definitions/nyaml/NXsensor.yaml @@ -129,13 +129,13 @@ NXsensor(NXobject): the instrument. The dependency chain may however traverse similar groups in other component groups. ############## - Temperature(NX_sensor): + Temperature(NX_NUMBER): doc: External sensors connected to the device. For example, T1, temperature of STM head. T2, temperature of bottom of LHe helium cryostat. T3, temperature of LN2 nitrogen shield. unit: NX_TEMPERATURE - Pressure(NX_sensor): + Pressure(NX_BUMBER): doc: External sensors connected to the device. Pressure of each chamber or ion pump, such as prepare chamber and analysis chamber unit: NX_PRESSURE - Power Spectral Density (NX_sensor): + Power Spectral Density (NX_NUMBER): doc: The power present in the signal as a function of frequency. Used to characterise the vibration and noise of scanning probes to detect and reduce the impact on resolution during STM imaging From c9ef3c992c30fea86d7c0b416b0b8a92b7072316 Mon Sep 17 00:00:00 2001 From: Rubel Date: Wed, 14 Jun 2023 10:55:02 +0200 Subject: [PATCH 0124/1012] fix conflict in rebase --- .../nyaml/NXpositioner.yaml | 24 ++++++++----------- 1 file changed, 10 insertions(+), 14 deletions(-) diff --git a/contributed_definitions/nyaml/NXpositioner.yaml b/contributed_definitions/nyaml/NXpositioner.yaml index 25441ef5b3..5e830aa34b 100644 --- a/contributed_definitions/nyaml/NXpositioner.yaml +++ b/contributed_definitions/nyaml/NXpositioner.yaml @@ -89,11 +89,9 @@ NXpositioner(NXobject): Position(NXtransformation): doc: To clarify the frame laboratory frame. The scanning area in x, y, and z position in the frame. unit: NX_LENGTH - -#Z_contronller: -# Name: -# doc: | -# This controllers task is to continuously adjust the Z position of the stm tip in order to keep the selected control signal as close as possible to the Set Point. Different contro; signals lead to different contronller beahvior. +#(Z_contronller): +# doc: | +# This controllers task is to continuously adjust the Z position of the stm tip in order to keep the selected control signal as close as possible to the Set Point. Different control signals lead to different contronller beahvior. Z_offset(NX_NUMBER): doc: Offset added to the initial averaged position Zaver before starting to swepp. unit: NX_LENGTH @@ -122,12 +120,11 @@ NXpositioner(NXobject): Switch off delay(NX_NUMBER): doc: Use this parameter for a reproducible position when switching off the Z-controller. When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. unit: NX_TIME - Z-controller hold(NX_CHAR): + Z-controller hold(NX_BOOLEAN): doc: (In bias spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. -#Scan contronller: -# name: -# doc: | -# To contron the tip and various scan operations. + (Scan contronller): + doc: | + To contron the tip and various scan operations. scanfield(NX_NUMBER): doc: Configure the scan frame like x position; y position; width; height. unit: NX_LENGTH @@ -143,10 +140,9 @@ NXpositioner(NXobject): speed backw.(NX_NUMBER): doc: Define the scan backward speed in the forward direction. unit: NX_ANY(NX_SPEED?) -#Piezo_calibration: -# name: -# doc: | -# Piezo calibration module is used to define the X Y Z piezos calibration. + (Piezo_calibration): + doc: | + Piezo calibration module is used to define the X Y Z piezos calibration. calibr(NX_NUMBER): Z_contronller: From a2236a8a0bba1717d2d3b4ce530a290c4114bf39 Mon Sep 17 00:00:00 2001 From: Yichen Date: Wed, 26 Apr 2023 14:41:11 +0200 Subject: [PATCH 0125/1012] Update some defination and debug --- contributed_definitions/nyaml/NXcircuit.yaml | 17 +++++++++++++ .../nyaml/NXiv_sweep2.backup.yaml | 24 +++++++++---------- contributed_definitions/nyaml/NXlockin.yaml | 2 ++ .../nyaml/NXpositioner.yaml | 2 ++ 4 files changed, 33 insertions(+), 12 deletions(-) diff --git a/contributed_definitions/nyaml/NXcircuit.yaml b/contributed_definitions/nyaml/NXcircuit.yaml index 722f133f9c..043e6139b9 100644 --- a/contributed_definitions/nyaml/NXcircuit.yaml +++ b/contributed_definitions/nyaml/NXcircuit.yaml @@ -32,4 +32,21 @@ NXcircuit: Measurements Period(NX_NUMBER): doc: The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. unit: NX_TIME + RT Frequency(NX_NUMBER): + doc: The bandwitdh of the Hardware and/or Software. + unit: NX_FREQUENCT + Signals Oversampling(NX_CHAR): + doc: The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. + Acquisition Period(NX_NUMBER): + doc: Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. + unit: NX_TIME + Animations Period(NX_NUMBER): + doc: Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. + unit: NX_TIME + Indicators Period(NX_NUMBER): + doc: Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. + unit: NX_TIME + Measurements Period(NX_NUMBER): + doc: The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. + unit: NX_TIME diff --git a/contributed_definitions/nyaml/NXiv_sweep2.backup.yaml b/contributed_definitions/nyaml/NXiv_sweep2.backup.yaml index 78c4a0c03f..5ce9d85621 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.backup.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.backup.yaml @@ -51,14 +51,14 @@ NXiv_sweep2(NXsensor_scan): Hardware: Nanonis BP5e Software: SoftwareMain>SW Version Generic 5e -- SoftwareMain>UI Release 10771 -- SoftwareMain>RT Release 10771 Current amplifier (NXamplifier) - Current amplifier> hardware: CreaTec GmbH - Current amplifier> factor (V/V): 1E-10 - Current amplifier> Capacitive cross-talk compensation: Yes/No + Current amplifier(NXamplifier)> hardware: CreaTec GmbH + Current amplifier(NXamplifier)> factor (V/V): 1E-10 + Current amplifier(NXamplifier)> Capacitive cross-talk compensation: Yes/No Lock-in>Lock-in status ON # ON/OFF of Lock-in amplifier Lock in (optional) (NXlockin) - Lock-in Amplifier>Yes/No # If a lock-in amplifier employed to filter or obtain the electronic derivatives dI/dV of the signal - Lock-in Amplifier>Hardware: Nanonis + Lock-in Amplifier(NXlockin)>Yes/No # If a lock-in amplifier employed to filter or obtain the electronic derivatives dI/dV of the signal + Lock-in Amplifier(NXlockin)>Hardware: Nanonis if Lock-in -- Bias Divider 1/10 or 1/100 # if the modulation Bias Spectroscopy>Channels(NXBias) Current (A);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A) # Select the channels to record. @@ -116,7 +116,7 @@ NXiv_sweep2(NXsensor_scan): Outputs>Output 6 Slew Rate Inf Outputs>Output 7 Slew Rate Inf Piezo Config - Piezo Configuration>Active Calib. LHe # Tne name of caliberation type. + Piezo Configuration>Active Calib.(NXpositioner) LHe # Tne name of caliberation type. Piezo Configuration>Calib. X(NXpositioner) (m/V) 3.8E-9 # There are 3 controls available: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. Piezo Configuration>Calib. Y(NXpositioner) (m/V) 3.8E-9 # See below. Piezo Configuration>Calib. Z(NXpositioner) (m/V) 900E-12 # See below. @@ -147,12 +147,12 @@ NXiv_sweep2(NXsensor_scan): Bias Spectroscopy>Sweep End(NXBias) (V) 300E-3 # The last bias values of the sweep. Bias Spectroscopy>Num Pixel(NXBias) 4096 # Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. Bias Spectroscopy>Z Avg time(NXBias) (s) 100E-3 # Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). - (TBA)SoftwareMain>RT Frequency (Hz) 20E+3 # The bandwitdh of the Hardware and/or Software - (TBA)SoftwareMain>Signals Oversampling 10 # (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. - (TBA)SoftwareMain>Acquisition Period (s) 20E-3 # Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. - (TBA)SoftwareMain>Animations Period (s) 20E-3 # Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. - (TBA)SoftwareMain>Indicators Period (s) 300E-3 # Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. - (TBA)SoftwareMain>Measurements Period (s) 500E-3 # The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. + SoftwareMain>RT Frequency(NXcircuit) (Hz) 20E+3 # The bandwitdh of the Hardware and/or Software + SoftwareMain>Signals Oversampling(NXcircuit) 10 # (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. + SoftwareMain>Acquisition Period(NXcircuit) (s) 20E-3 # Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. + SoftwareMain>Animations Period(NXcircuit) (s) 20E-3 # Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. + SoftwareMain>Indicators Period(NXcircuit) (s) 300E-3 # Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. + SoftwareMain>Measurements Period(NXcircuit) (s) 500E-3 # The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. Scan control # parameters how to change the location from measurement to measurement during the scan frame(NXtransformation) # also clarify the frame for the ROI of the scan (should depend on the lab frame) Scan>Scanfield(NXpositioner) 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0 # Configure the scan frame: x position; y position; width; height. diff --git a/contributed_definitions/nyaml/NXlockin.yaml b/contributed_definitions/nyaml/NXlockin.yaml index 8530c2b903..e9ee15fff4 100644 --- a/contributed_definitions/nyaml/NXlockin.yaml +++ b/contributed_definitions/nyaml/NXlockin.yaml @@ -5,6 +5,8 @@ NXlockin: hardware(NXfabrication): (NXamplifier): doc: input and output amplifiers + Lock-in stats(NX_BOOLEAN): + doc: Switch the lock-in moulation on or off. Modulate signal(NX_CHAR): doc: This is the signal on which the modulation (sine) will be added, such as current, bias, et.al. Amplitude(NX_NUMBER): diff --git a/contributed_definitions/nyaml/NXpositioner.yaml b/contributed_definitions/nyaml/NXpositioner.yaml index 5e830aa34b..55990db18d 100644 --- a/contributed_definitions/nyaml/NXpositioner.yaml +++ b/contributed_definitions/nyaml/NXpositioner.yaml @@ -143,6 +143,8 @@ NXpositioner(NXobject): (Piezo_calibration): doc: | Piezo calibration module is used to define the X Y Z piezos calibration. + Active Calib(NX_CHAR): + doc: The name of caliberation type. calibr(NX_NUMBER): Z_contronller: From b7146dd6ee72745ff4831b89510e4795a5a7d7d1 Mon Sep 17 00:00:00 2001 From: Yichen Date: Tue, 9 May 2023 14:48:00 +0200 Subject: [PATCH 0126/1012] Update NXlockin.yaml --- contributed_definitions/nyaml/NXlockin.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/contributed_definitions/nyaml/NXlockin.yaml b/contributed_definitions/nyaml/NXlockin.yaml index e9ee15fff4..606e617f62 100644 --- a/contributed_definitions/nyaml/NXlockin.yaml +++ b/contributed_definitions/nyaml/NXlockin.yaml @@ -3,6 +3,7 @@ doc: | category: base NXlockin: hardware(NXfabrication): + doc: Hardware manufacturers and type of lockin amplifier. (NXamplifier): doc: input and output amplifiers Lock-in stats(NX_BOOLEAN): From 39efbc0a6dc67a8a84bc5ff03cd424e2332e926d Mon Sep 17 00:00:00 2001 From: Yichen Date: Tue, 9 May 2023 15:42:55 +0200 Subject: [PATCH 0127/1012] Update final Z position to here --- contributed_definitions/nyaml/NXpositioner.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/contributed_definitions/nyaml/NXpositioner.yaml b/contributed_definitions/nyaml/NXpositioner.yaml index 55990db18d..27ca7894fd 100644 --- a/contributed_definitions/nyaml/NXpositioner.yaml +++ b/contributed_definitions/nyaml/NXpositioner.yaml @@ -122,6 +122,9 @@ NXpositioner(NXobject): unit: NX_TIME Z-controller hold(NX_BOOLEAN): doc: (In bias spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. + Final Z(NX_NUMBER): + doc: The final z-position during the bias spectroscopy scan. The availability of values is related to the mode of scanning. + unit: NX_LENGTH (Scan contronller): doc: | To contron the tip and various scan operations. From 1a0bd5307b13a21d2717fb149f674e3a85f44747 Mon Sep 17 00:00:00 2001 From: Yichen Date: Tue, 9 May 2023 15:48:04 +0200 Subject: [PATCH 0128/1012] Update bias filter, order, and curoff frq --- contributed_definitions/nyaml/NXbias.yaml | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/contributed_definitions/nyaml/NXbias.yaml b/contributed_definitions/nyaml/NXbias.yaml index 51f5a72796..e8652e9d68 100644 --- a/contributed_definitions/nyaml/NXbias.yaml +++ b/contributed_definitions/nyaml/NXbias.yaml @@ -43,6 +43,12 @@ NXbias(NXobject): Z Avg time(NX_NUMBER): doc: Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). unit: NX_TIME + SW Filter type (NX_CHAR): + doc Select a filter to smooth the displayed data. When saving, if any filter selected, filtered data are saved to file along with the unfiltered data. + SW Filter Order(NX_NUMBER): + doc: Filter order of a dynamic filter or width (in number of points) for the gaussian filter. + SW Filter Cutoff frq(NX_NUMBER): + doc: Cutoff frequency for dynamic filters. Z offset(NX_NUMBER): doc: Offset added to the initial averaged position Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an alternate Z-controller setpoint is enabled. unit: NX_LENGTH From 5fc17ec8bdc661c80822dc5878899c0211087f64 Mon Sep 17 00:00:00 2001 From: Yichen Date: Tue, 9 May 2023 15:48:32 +0200 Subject: [PATCH 0129/1012] Update output channel mode, name, value, and slew rate --- contributed_definitions/nyaml/NXcircuit.yaml | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/contributed_definitions/nyaml/NXcircuit.yaml b/contributed_definitions/nyaml/NXcircuit.yaml index 043e6139b9..f463b2b72c 100644 --- a/contributed_definitions/nyaml/NXcircuit.yaml +++ b/contributed_definitions/nyaml/NXcircuit.yaml @@ -3,7 +3,7 @@ doc: | category: base NXcircuit: hardware(NX_FABRICATION): - doc: (NXmanufacturer?) + doc: Hardware type used in circuit, includes hardware manufacturers and type Tunneling Current(NX_NUMBER): doc: The tunneling current between tip and sample after application of bias voltage. unit: NX_CURRENT @@ -12,6 +12,8 @@ NXcircuit: Offset(NX_NUMBER): doc: Offset of the current measurement. unit: NX_CURRENT + Gain(NX_NUMBER): + doc: Proportional relationship between the probe output voltage and the actual tunneling current when measuring the tunneling current. channels(NX_CHAR): doc: The scan channels are selected by users (in scan contronaller). RT Frequency(NX_NUMBER): @@ -49,4 +51,19 @@ NXcircuit: Measurements Period(NX_NUMBER): doc: The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. unit: NX_TIME + Output N Mode(NX_CHAR): + doc: N represents the number of signal channels. The user output in each monitor mode. + Output N Value(NX_NUMBER): + doc: N represents the number of signal channels. The values for each output channel. + unit: NX_ANY + Output N Name(NX_CHAR): + doc: N represents the number of signal channels. User outputs whose name can be modified in the corresponding module. + Output N Slew Rate(NX_CHAR): + doc: N represents the number of signal channels. The rate at which the one of the signal changes when ramping to the starting point. (V/s) + + + + + + From 285bbb8d5d2f7e60d07a5f0c9296ffc5eec61c83 Mon Sep 17 00:00:00 2001 From: Yichen Date: Tue, 9 May 2023 15:49:22 +0200 Subject: [PATCH 0130/1012] Update the format and complete the files --- .../nyaml/NXiv_sweep2.backup.yaml | 305 +++++++++--------- 1 file changed, 144 insertions(+), 161 deletions(-) diff --git a/contributed_definitions/nyaml/NXiv_sweep2.backup.yaml b/contributed_definitions/nyaml/NXiv_sweep2.backup.yaml index 5ce9d85621..075a438ec4 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.backup.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.backup.yaml @@ -43,192 +43,175 @@ NXiv_sweep2(NXsensor_scan): (file)type [background, reference, sample] - finename -> description (e.g. 221122_Au_5K00014) - series name -> description? Scan>series name 221122_Au_5K - session path (ELN?!)-> NanonisMain>Session Path C:\Users\SPM-PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis-Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711 - description: Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, locked Au(111), 50pA, 100 mV set point, 1mV DCA, 973Hz,138 1st H, -84 2nd H + filename(NX_CHAR): (e.g. 221122_Au_5K00014) + doc: The name of the output file, with the number of scans at the end. + Scan>series name(NX_CHAR): (e.g. 221122_Au_5K) + doc: The name of the series output file, which represents only the public part of the output file. + NanonisMain>session path(NX_CHAR): (e.g. Path C:\Users\SPM-PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis-Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711) + doc: Path to storage of output files. + Comment01(NX_CHAR): (e.g. SYNC & Filter LP 8order WITHDRAW 600 steps, locked Au(111), 50pA, 100 mV set point, 1mV DCA, 973Hz,138 1st H, -84 2nd H) + doc: Descriptive comments for this experiment, added by the experimenter, coming from the output file. INSTRUMENT - Hardware: Nanonis BP5e - Software: SoftwareMain>SW Version Generic 5e -- SoftwareMain>UI Release 10771 -- SoftwareMain>RT Release 10771 - Current amplifier (NXamplifier) - Current amplifier(NXamplifier)> hardware: CreaTec GmbH - Current amplifier(NXamplifier)> factor (V/V): 1E-10 - Current amplifier(NXamplifier)> Capacitive cross-talk compensation: Yes/No + Hardware(NX_CHAR): (e.g. Nanonis BP5e) + doc: Hardware type used in SPM experiment, includes hardware manufacturers and type. + SoftwareMain>Software(NX_CHAR): (e.g. SW Version Generic 5e -- SoftwareMain>UI Release 10771 -- SoftwareMain>RT Release 10771) + doc: Type of software used in SPM experiments, e.g. software version serial number, UI and RT probe release method. + Current amplifier + Current amplifier>hardware(NXamplifier): (e.g. CreaTec GmbH) + Current amplifier>factor(NXamplifier): (e.g. 1E-10) + Current amplifier(NXamplifier)> Capacitive cross-talk compensation: (e.g. Yes/No) Lock-in>Lock-in status ON # ON/OFF of Lock-in amplifier Lock in (optional) (NXlockin) Lock-in Amplifier(NXlockin)>Yes/No # If a lock-in amplifier employed to filter or obtain the electronic derivatives dI/dV of the signal - Lock-in Amplifier(NXlockin)>Hardware: Nanonis - if Lock-in -- Bias Divider 1/10 or 1/100 # if the modulation + Lock-in Amplifier(NXlockin)>Hardware: (e.g. Nanonis) + Bias Divider(NX_NUMBER): (e.g. 1/10 or 1/100) # if the modulation + doc: The input bias signal is split into two parts, e.g. the input voltage is split into a smaller reference bias and a larger operating bias. This value is obtained by dividing Lock-in>Amplitude by Bias. - Bias Spectroscopy>Channels(NXBias) Current (A);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A) # Select the channels to record. - Bias Spectroscopy>Reset Bias(NXBias) TRUE # When selected, the Bias voltage returns to the initial value (before starting the sweep) at the end of the spectroscopy measurement (default). When not selected, Bias remains at the last value of the sweep. This is useful e.g. when combining several sweep segments. Example for an automated measurement (using Programming Interface): switch off Z-Controller, start spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, switch on Z-Controller. - Bias Spectroscopy>Record final Z(NXBias) FALSE # Select whether to record the Z position during Z averaging time at the end of the sweep (after Z control time) and store the average value in the header of the file when saving. Using this option increases the sweep time by Z averaging time. - Bias Spectroscopy>Lock-In run(NXBias) FALSE # Select whether to set the Lock-In to run during the measurement. When using this feature, make sure the Lock-In is configured correctly and settling times are set to twice the Lock-In period at least. This option is ignored when Lock-In is already running. This option is disabled if the Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline segment editor is set. - Lock-in>Modulated signal Bias(NXlockin) (V) # This is the signal on which the modulation (sine) will be added. - Lock-in>Frequency(NXlockin) (Hz) 973E+0 # Sets the frequency of the sine modulation added to the signal to modulate. The frequency range is from 10 mHz to 40 kHz (corresponding to the SC5 output filter cut-off). When working with harmonics, make sure the harmonic frequencies don’t exceed ~100 kHz (SC5 input filter cut-off). Remember the SC5 hardware filters will affect the amplitude when getting close to their cut-off frequencies. - Lock-in>Amplitude(NXlockin) 2E-3 # Sets the amplitude (in physical units of the modulated signal) of the sine modulation. - Lock-in>Demodulated signal Current(NXlockin) (A) # This is the signal which will be demodulated, in order to determine the amplitude and phase at the frequency set in the Frequency field (“4”) or harmonics. - Lock-in>Harmonic D1(NXlockin) 1 # Order of the harmonic oscillation to detect on the demodulated signal (with respect to the modulation frequency). If you work with higher harmonics make sure the frequency does not exceed the analog signal bandwidth (100 kHz). - Lock-in>Harmonic D2(NXlockin) 2 # See below. - Lock-in>Reference phase D1(NXlockin) (deg) 137.597E+0 # Reference phase for the sine on the demodulated signal with respect to the modulation signal. The determined phase (phi) is displayed with respect to the reference phase. - Lock-in>Reference phase D2(NXlockin) (deg) -83.6562E+0 # See below. + Bias Spectroscopy>Channels(NXBias) Current (e.g. (A);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A)) # Select the channels to record. + Bias Spectroscopy>Reset Bias(NXBias) (e.g. TRUE) # When selected, the Bias voltage returns to the initial value (before starting the sweep) at the end of the spectroscopy measurement (default). When not selected, Bias remains at the last value of the sweep. This is useful e.g. when combining several sweep segments. Example for an automated measurement (using Programming Interface): switch off Z-Controller, start spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, switch on Z-Controller. + Bias Spectroscopy>Record final Z(NXBias) (e.g. FALSE) # Select whether to record the Z position during Z averaging time at the end of the sweep (after Z control time) and store the average value in the header of the file when saving. Using this option increases the sweep time by Z averaging time. + Bias Spectroscopy>Lock-In run(NXBias) (e.g. FALSE) # Select whether to set the Lock-In to run during the measurement. When using this feature, make sure the Lock-In is configured correctly and settling times are set to twice the Lock-In period at least. This option is ignored when Lock-In is already running. This option is disabled if the Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline segment editor is set. + Lock-in>Modulated signal(NXlockin) (e.g. Bias (V)) # This is the signal on which the modulation (sine) will be added. + Lock-in>Frequency(NXlockin) (Hz) (e.g. 973E+0) # Sets the frequency of the sine modulation added to the signal to modulate. The frequency range is from 10 mHz to 40 kHz (corresponding to the SC5 output filter cut-off). When working with harmonics, make sure the harmonic frequencies don’t exceed ~100 kHz (SC5 input filter cut-off). Remember the SC5 hardware filters will affect the amplitude when getting close to their cut-off frequencies. + Lock-in>Amplitude(NXlockin) (e.g. 2E-3) # Sets the amplitude (in physical units of the modulated signal) of the sine modulation. + Lock-in>Demodulated signal(NXlockin) (e.g. Current (A)) # This is the signal which will be demodulated, in order to determine the amplitude and phase at the frequency set in the Frequency field (“4”) or harmonics. + Lock-in>Harmonic D1(NXlockin) (e.g. 1) # Order of the harmonic oscillation to detect on the demodulated signal (with respect to the modulation frequency). If you work with higher harmonics make sure the frequency does not exceed the analog signal bandwidth (100 kHz). + Lock-in>Harmonic D2(NXlockin) (e.g. 2) # See below. + Lock-in>Reference phase D1(NXlockin) (deg) (e.g. 137.597E+0) # Reference phase for the sine on the demodulated signal with respect to the modulation signal. The determined phase (phi) is displayed with respect to the reference phase. + Lock-in>Reference phase D2(NXlockin) (deg) (e.g. -83.6562E+0) # See below. - Bias: Tip bias/Sample bias # If the spectroscopy V bias is applied to the - Modulated signal Bias(NXbias) (V) 1E-3 # Applied modulation to the bias voltage. - ModulationBias> Tip bias/Sample bias + Bias + doc: Bias refers to the voltage difference applied between the probe tip and the sample surface, usually bias is expressed as the needle tip bias voltage. A positive value means that the needle tip voltage is higher than the sample. However this may depend on the settings of different systems. + Modulated signal Bias(NXbias) (V) 1E-3 # Applied modulation to the bias voltage. + ModulationBias: + doc: Same directional representation as bias. STM head - temp Temperature 1(NXsensor) (K) 4.92997E+0 # Temperature of STM head. + temp Temperature 1(NXsensor) (K) (e.g. 4.92997E+0) # Temperature of STM head. Cryo bottom_temp Temperature 2(NXsensor) (K) - # Temperature of bottom of LHe helium cryostat. shield_temp Temperature 3(NXsensor) (K) - # Temperature of LN2 nitrogen shield. - Cabling & Config(NXdata) - Outputs>Output 0 Mode User Output - Outputs>Output 1 Mode User Output - Outputs>Output 2 Mode User Output - Outputs>Output 3 Mode User Output - Outputs>Output 4 Mode User Output - Outputs>Output 5 Mode User Output - Outputs>Output 6 Mode User Output - Outputs>Output 7 Mode User Output - Outputs>Output 0 Value 0E+0 - Outputs>Output 1 Value 0E+0 - Outputs>Output 2 Value 0E+0 - Outputs>Output 3 Value 2.5539E+0 - Outputs>Output 4 Value 0E+0 - Outputs>Output 5 Value 0E+0 - Outputs>Output 6 Value 0E+0 - Outputs>Output 7 Value 0E+0 - Outputs>Output 0 Name Input 24 (V) - Outputs>Output 1 Name Bias (V) - Outputs>Output 2 Name Output 2 (V) - Outputs>Output 3 Name T1 Supply voltage (V) - Outputs>Output 4 Name Output 4 (V) - Outputs>Output 5 Name X (m) - Outputs>Output 6 Name Y (m) - Outputs>Output 7 Name Z (m) - Outputs>Output 0 Slew Rate Inf - Outputs>Output 1 Slew Rate Inf - Outputs>Output 2 Slew Rate Inf - Outputs>Output 3 Slew Rate Inf - Outputs>Output 4 Slew Rate Inf - Outputs>Output 5 Slew Rate Inf - Outputs>Output 6 Slew Rate Inf - Outputs>Output 7 Slew Rate Inf + Cabling & Config # not data + Outputs>Output N Mode(NXcircuit) (e.g. User Output) + Outputs>Output N Value(NXcircuit) (e.g. 0E+0) + Outputs>Output N Name(NXcircuit) (e.g. Input 24 (V)) + Outputs>Output N Slew Rate(NXcircuit) (e.g. Inf) + Piezo Config - Piezo Configuration>Active Calib.(NXpositioner) LHe # Tne name of caliberation type. - Piezo Configuration>Calib. X(NXpositioner) (m/V) 3.8E-9 # There are 3 controls available: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. - Piezo Configuration>Calib. Y(NXpositioner) (m/V) 3.8E-9 # See below. - Piezo Configuration>Calib. Z(NXpositioner) (m/V) 900E-12 # See below. - Piezo Configuration>HV Gain X(NXpositioner) 14.5 # For some systems HV gain readout is available, so for those systems the HV gain should be adjusted automatically when the gain is changed at the high voltage amplifier. - Piezo Configuration>HV Gain Y(NXpositioner) 14.5 # See below. - Piezo Configuration>HV Gain Z(NXpositioner) 14.5 # See below. - Piezo Configuration>Tilt X(NXpositioner) (deg) 0.318343 # This tab is used to set the sample tilt (in degrees, first order correction). - Piezo Configuration>Tilt Y(NXpositioner) (deg) 1.584 # See below. - Piezo Configuration>Curvature radius X(NXpositioner) (m) Inf # This tab is used to set a curvature (can be set approximately to the length of the piezotube). - Piezo Configuration>Curvature radius Y(NXpositioner) (m) Inf # See below. - Piezo Configuration>2nd order corr X(NXpositioner) (V/m^2) 0E+0 # If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. - Piezo Configuration>2nd order corr Y(NXpositioner) (V/m^2) 0E+0 # See below. - Piezo Configuration>Drift X(NXpositioner) (m/s) 0E+0 # Define the drift speed for all three axes. When the compensation is on, the piezos will start to move at that speed. - Piezo Configuration>Drift Y(NXpositioner) (m/s) 0E+0 # See below. - Piezo Configuration>Drift Z(NXpositioner) (m/s) 0E+0 # See below. - Piezo Configuration>Drift correction status (on/off)(NXpositioner) FALSE # Use the button to turn on/off the drift compensation. - + Piezo Configuration>Active Calib.(NX_CHAR): (e.g. LHe) # Tne name of caliberation type. + doc: The name of caliberation type. + Piezo Configuration>Calib. N(NX_NUMBER): (e.g. 3.8E-9) # There are 3 controls available: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. + doc: N denotes X or Y or Z. There are 3 parameters in X, Y, and Z directions and there are 3 controls available: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. + Piezo Configuration>HV Gain N(NX_NUMBER): (e.g. 14.5) # For some systems HV gain readout is available, so for those systems the HV gain should be adjusted automatically when the gain is changed at the high voltage amplifier. + doc: N denotes X or Y or Z. For some systems HV gain readout is available, so for those systems the HV gain should be adjusted automatically when the gain is changed at the high voltage amplifier + Piezo Configuration>Tilt N(NX_NUMBER): (e.g. 0.318343) # This tab is used to set the sample tilt (in degrees, first order correction). + doc: N denotes X or Y. There are 2 parameters in X and Y directions and this tab is used to set the sample tilt (in degrees, first order correction). + unit: NX_ANGLE + Piezo Configuration>Curvature radius N(NX_NUMBER): Inf # This tab is used to set a curvature (can be set approximately to the length of the piezotube). + doc: N denotes X or Y. There are 2 parameters in X and Y directions and this tab is used to set a curvature (can be set approximately to the length of the piezotube). + unit: NX_LENGTH + Piezo Configuration>2nd order corr N(NX_NUMBER): (e.g. 0E+0) # If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. + doc: N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2). + Piezo Configuration>Drift N(NX_NUMBER): (e.g. 0E+0) # Define the drift speed for all three axes. When the compensation is on, the piezos will start to move at that speed. + doc: N denotes X or Y. There are 2 parameters in X and Y directions. Define the drift speed for all three axes. When the compensation is on, the piezos will start to move at that speed. + Piezo Configuration>Drift correction status(NX_BOOLEAN): (e.g. FALSE) # Use the button to turn on/off the drift compensation. + doc: Use the button to turn on/off the drift compensation. + MEASUREMENT Position (NXpositioner) # also clarify the frame laboratory frame - X(NXpositioner) (m) -890.53E-12 - Y(NXpositioner) (m) 29.6968E-9 - Z(NXpositioner) (m) 130.5E-9 - Z-Controller>Z(NXpositioner) (m) 130.5E-9 + X(NXpositioner) (m) (e.g. -890.53E-12) + Y(NXpositioner) (m) (e.g. 29.6968E-9) + Z(NXpositioner) (m) (e.g. 130.5E-9) + Z-Controller>Z(NXpositioner) (m) (e.g. 130.5E-9) sweep control # parameters for a measurement at a single location during the scan - Integration time(NXbias) (s) 150E-6 # Time during which the spectroscopy data are acquired and averaged. - Bias Spectroscopy>Number of sweeps(NXBias) 100 # Number of sweeps to measure and average. - Bias Spectroscopy>Sweep Start(NXBias) (V) -300E-3 # The first bias values of the sweep. - Bias Spectroscopy>Sweep End(NXBias) (V) 300E-3 # The last bias values of the sweep. - Bias Spectroscopy>Num Pixel(NXBias) 4096 # Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. - Bias Spectroscopy>Z Avg time(NXBias) (s) 100E-3 # Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). - SoftwareMain>RT Frequency(NXcircuit) (Hz) 20E+3 # The bandwitdh of the Hardware and/or Software - SoftwareMain>Signals Oversampling(NXcircuit) 10 # (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. - SoftwareMain>Acquisition Period(NXcircuit) (s) 20E-3 # Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. - SoftwareMain>Animations Period(NXcircuit) (s) 20E-3 # Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. - SoftwareMain>Indicators Period(NXcircuit) (s) 300E-3 # Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. - SoftwareMain>Measurements Period(NXcircuit) (s) 500E-3 # The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. + Integration time(NXbias) (s) (e.g. 150E-6) # Time during which the spectroscopy data are acquired and averaged. + Bias Spectroscopy>Number of sweeps(NXBias) (e.g. 100) # Number of sweeps to measure and average. + Bias Spectroscopy>Sweep Start(NXBias) (V) (e.g. -300E-3) # The first bias values of the sweep. + Bias Spectroscopy>Sweep End(NXBias) (V) (e.g. 300E-3) # The last bias values of the sweep. + Bias Spectroscopy>Num Pixel(NXBias) (e.g. 4096) # Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. + Bias Spectroscopy>Z Avg time(NXBias) (s) (e.g. 100E-3) # Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). + SoftwareMain>RT Frequency(NXcircuit) (Hz) (e.g. 20E+3) # The bandwitdh of the Hardware and/or Software + SoftwareMain>Signals Oversampling(NXcircuit) (e.g. 10) # (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. + SoftwareMain>Acquisition Period(NXcircuit) (s) (e.g. 20E-3) # Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. + SoftwareMain>Animations Period(NXcircuit) (s) (e.g. 20E-3) # Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. + SoftwareMain>Indicators Period(NXcircuit) (s) (e.g. 300E-3) # Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. + SoftwareMain>Measurements Period(NXcircuit) (s) (e.g. 500E-3) # The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. Scan control # parameters how to change the location from measurement to measurement during the scan frame(NXtransformation) # also clarify the frame for the ROI of the scan (should depend on the lab frame) - Scan>Scanfield(NXpositioner) 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0 # Configure the scan frame: x position; y position; width; height. - Scan>channels Current(NXcircuit) (A);Bias (V);Z (m);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A) # The scan channels are selected by users. - Scan>pixels/line(NXpositioner) 512 # Scan resolution by setting the Lines equal to Pixels. - Scan>lines(NXpositioner) 512 # Define the image resolution. - Scan>speed forw.(NXpositioner) (m/s) 11.7187E-9 # Define the scan forward speed in the forward direction. - Scan>speed backw.(NXpositioner) (m/s) 11.7187E-9 # Define the scan backward speed in the forward direction. + Scan>Scanfield(NXpositioner) (e.g. 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0) # Configure the scan frame: x position; y position; width; height. + Scan>channels Current(NXcircuit) (e.g. (A);Bias (V);Z (m);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A)) # The scan channels are selected by users. + Scan>pixels/line(NXpositioner) (e.g. 512) # Scan resolution by setting the Lines equal to Pixels. + Scan>lines(NXpositioner) (e.g. 512) # Define the image resolution. + Scan>speed forw.(NXpositioner) (m/s) (e.g. 11.7187E-9) # Define the scan forward speed in the forward direction. + Scan>speed backw.(NXpositioner) (m/s) (e.g. 11.7187E-9) # Define the scan backward speed in the forward direction. - SW Filter (PROCESS) - type Butterworth # Select a filter to smooth the displayed data. Note: When saving, if any filter selected, filtered data are saved to file along with the unfiltered data. - Order 1 # Filter order of a dynamic filter or width (in number of points) for the gaussian filter. - Cutoff frq 0.01 # Cutoff frequency for dynamic filters. - filtered_data # result of filtering if applied + SW Filter (NXbias) + type(NXbias) (e.g. Butterworth) # Select a filter to smooth the displayed data. Note: When saving, if any filter selected, filtered data are saved to file along with the unfiltered data. + Order(NXbias) (e.g. 1) # Filter order of a dynamic filter or width (in number of points) for the gaussian filter. + Cutoff frq(NXbias) (e.g. 0.01) # Cutoff frequency for dynamic filters. HW Filter (NXlockin) # maybe the same as INSTRUMENT/lockin - Lock-in>LP Filter Cutoff(NXlockin) D1 (Hz) 621.699E+0 # Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) value) for D1. The filter is applied to the demodulated signals (X,Y). - Lock-in>LP Filter Cutoff(NXlockin) D2 (Hz) 621.699E+0 # Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) value) for D2. The filter is applied to the demodulated signals (X,Y). - Lock-in>LP Filter Order(NXlockin) D1 8 # Order and cut-off frequency of the low-pass filter applied on the demodulated signals (X,Y). Reducing the bandwidth or increasing the order reduces noise on the demodulated signals, but will require longer settling and measurement times. - Lock-in>LP Filter Order(NXlockin) D2 8 # See below. - Lock-in>HP Filter Cutoff(NXlockin) D1 (Hz) # Sets the cut-off frequency of the high-pass filter (affects the displayed TC (s) value) for D1. The filter is applied to the demodulated signals (X,Y). - Lock-in>HP Filter Cutoff(NXlockin) D2 (Hz) # See below - Lock-in>HP Filter Order(NXlockin) D1 1 # Order and cut-off frequency of the high-pass filter applied on the demodulation signal of D!. This is used mainly to suppress a DC component of the demodulation signal, which would lead to a component at modulation frequency in the demodulated signals. - Lock-in>HP Filter Order(NXlockin) D2 1 # See below - Lock-in>Sync Filter(NXlockin) D1 ON # Switch the Sync filter on the demodulated signals (X,Y) on or off for D1. The sync filter operates after the low-pass filter and averages the demodulated signals over one period of the modulation frequency. - Lock-in>Sync Filter(NXlockin) D2 ON # See below. + Lock-in>LP Filter Cutoff(NXlockin) D1 (Hz) (e.g. 621.699E+0) # Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) value) for D1. The filter is applied to the demodulated signals (X,Y). + Lock-in>LP Filter Cutoff(NXlockin) D2 (Hz) (e.g. 621.699E+0) # Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) value) for D2. The filter is applied to the demodulated signals (X,Y). + Lock-in>LP Filter Order(NXlockin) D1 (e.g. 8) # Order and cut-off frequency of the low-pass filter applied on the demodulated signals (X,Y). Reducing the bandwidth or increasing the order reduces noise on the demodulated signals, but will require longer settling and measurement times. + Lock-in>LP Filter Order(NXlockin) D2 (e.g. 8) # See below. + Lock-in>HP Filter Cutoff(NXlockin) D1 (Hz) (e.g. 621.699E+0) # Sets the cut-off frequency of the high-pass filter (affects the displayed TC (s) value) for D1. The filter is applied to the demodulated signals (X,Y). + Lock-in>HP Filter Cutoff(NXlockin) D2 (Hz) (e.g. 621.699E+0) # See below + Lock-in>HP Filter Order(NXlockin) D1 (e.g. 1 # Order and cut-off frequency of the high-pass filter applied on the demodulation signal of D!. This is used mainly to suppress a DC component of the demodulation signal, which would lead to a component at modulation frequency in the demodulated signals. + Lock-in>HP Filter Order(NXlockin) D2 (e.g. 1) # See below + Lock-in>Sync Filter(NXlockin) D1 (e.g. ON) # Switch the Sync filter on the demodulated signals (X,Y) on or off for D1. The sync filter operates after the low-pass filter and averages the demodulated signals over one period of the modulation frequency. + Lock-in>Sync Filter(NXlockin) D2 (e.g. ON) # See below. RESOLUTION (calculation input) - Temperature 1>link to INSTR/STM/head Temperature 1 (K) 4.92997E+0 # Temperature of STM head. + Temperature 1>link to INSTR/STM/head Temperature 1 (K) (e.g. 4.92997E+0) # Temperature of STM head. Temperature 2>link to Temperature 2 (K) - # Temperature of bottom of LHe helium cryostat. Temperature 3>link to Temperature 3 (K) - # Temperature of LN2 nitrogen shield. - Lock-in>link to Modulated signal Bias (V) 1E-3 # Applied modulation to the bias voltage. - link to Integration time (s) 150E-6 # Time during which the spectroscopy data are acquired and averaged. - link to Bias Spectroscopy>Number of sweeps 100 # Number of sweeps to measure and average. - link to Bias Spectroscopy>Sweep Start (V) -300E-3 # The first bias values of the sweep. - link to Bias Spectroscopy>Sweep End (V) 300E-3 # The last bias values of the sweep. - link to Bias Spectroscopy>Num Pixel 4096 # Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. - link to Bias Spectroscopy>Z Avg time (s) 100E-3 # Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). - link to SoftwareMain>RT Frequency (Hz) 20E+3 # The bandwitdh of the Hardware and/or Software - link to SoftwareMain>Signals Oversampling 10 # (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. - link to SoftwareMain>Acquisition Period (s) 20E-3 # Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. - link to SoftwareMain>Animations Period (s) 20E-3 # Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. - link to SoftwareMain>Indicators Period (s) 300E-3 # Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. - link to SoftwareMain>Measurements Period (s) 500E-3 # The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. + Lock-in>link to Modulated signal Bias (V) (e.g. 1E-3) # Applied modulation to the bias voltage. + link to Integration time (s) (e.g. 150E-6) # Time during which the spectroscopy data are acquired and averaged. + link to Bias Spectroscopy>Number of sweeps (e.g. 100) # Number of sweeps to measure and average. + link to Bias Spectroscopy>Sweep Start (V) (e.g. -300E-3) # The first bias values of the sweep. + link to Bias Spectroscopy>Sweep End (V) (e.g. 300E-3) # The last bias values of the sweep. + link to Bias Spectroscopy>Num Pixel (e.g. 4096) # Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. + link to Bias Spectroscopy>Z Avg time (s) (e.g. 100E-3) # Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). + link to SoftwareMain>RT Frequency (Hz) (e.g. 20E+3) # The bandwitdh of the Hardware and/or Software + link to SoftwareMain>Signals Oversampling (e.g. 10) # (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. + link to SoftwareMain>Acquisition Period (s) (e.g. 20E-3) # Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. + link to SoftwareMain>Animations Period (s) (e.g. 20E-3) # Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. + link to SoftwareMain>Indicators Period (s) (e.g. 300E-3) # Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. + link to SoftwareMain>Measurements Period (s) (e.g. 500E-3) # The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. REPRODUCIBILITY link to - Bias>Bias(NXBias) (V) 100E-3 # Applied bias voltage. - Current>Current(NXcircuit) (A) -5.3429E-15 # The tunneling current is displayed here. - Bias>Calibration(NXbias) (V/V) 1E+0 # Calibration of the Bias output. If you have a Range switch the calibration is stored per range setting. - Bias>Offset(NXbias) (V) 0E+0 # Allows compensating for an offset in Bias. - Current>Calibration(NXcircuit) (A/V) 100E-12 # The signals voltages are converted to real world physical values according to the calibration & offset parameters: Physical signal = (Voltage * calibration) + offset. - Current>Offset(NXcircuit) (A) 16.2897E-15 # The same as "Current>Calibration (A/V)" tag - Current>Gain(TBA) Not switchable # None - Z offset(NXpositioner) (m) 0E+0 # Offset added to the initial averaged position Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an alternate Z-controller setpoint is enabled. - Settling time(NXbias) (s) 2.1E-3 # Time to wait after changing the bias to the next level and before starting to acquire data. Adjust this parameter to avoid transient effect induced by the bias change. Integration time: time during which the data are acquired and averaged. - Z-Ctrl hold(NXpositioner) TRUE # When selected, the Z-Controller is set to hold during the pulse. This means that the controller doesn't control the Z position during the pulse. - Final Z (m) N/A - Start time 23.11.2022 18:55:16 # Timestamp of the moment when the acquisition starts by pressing the Start button. - Bias Spectroscopy>Z offset(NXbias) (m) 0E+0 # Offset added to the initial averaged position Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an alternate Z-controller setpoint is enabled. - Bias Spectroscopy>1st Settling time(NXbias) (s) 2.1E-3 # See the "Settling time (s)" below. - Bias Spectroscopy>Settling time(NXbias) (s) 2.1E-3 # See the "Settling time (s)" below. - Bias Spectroscopy>Integration time(NXbias) (s) 150E-6 # Time during which the data are acquired and averaged. - Bias Spectroscopy>End Settling time(NXbias) (s) 4E-3 # Time to wait after the sweep has finished and the bias is ramped to the initial value. - Bias Spectroscopy>Z control time(NXbias) (s) 200E-3 # Time during which the Z-Controller is enabled once a sweep has finished. When averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled for this duration between each sweep. After the last sweep, it will wait the specified time before continuing a running scan. This ensures each sweep reliably starts from the same position. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. - Bias Spectroscopy>Max Slew rate(NXbias) (V/s) 1E+0 # Maximum rate at which the bias changes (before, during and after sweeping). - Bias Spectroscopy>backward sweep(NXbias) TRUE # Select whether to measure the backward (return) sweep or the forward only. - Bias Spectroscopy>Z-controller hold(NXbias) TRUE # Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. - Z-Controller>Controller name(NXpositioner) log Current # Controller name. This name which will be displayed at places where you can select a controller. - Z-Controller>Controller status(NXpositioner) OFF # ON/OFF - Z-Controller>Setpoint(NXpositioner) 50E-12 # Set Point is the desired value of the control signal. It can be set by editing the number or using the slider bar. Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. - Z-Controller>Setpoint unit(NXpositioner) A # Angstrom - Z-Controller>P gain(NXpositioner) 6E-12 # The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. - Z-Controller>I gain(NXpositioner) 39.8241E-9 # See "Z-Controller>P gain" below. - Z-Controller>Time const(NXpositioner) (s) 150.662E-6 # See "Z-Controller>P gain" below. - Z-Controller>TipLift(NXpositioner) (m) 0E+0 # Lifts the tip by the specified amount when then controller is switched off. This can be a positive or a negative number, i.e. the tip can also be moved towards the sample. Be careful with sign and value when using this feature. - Z-Controller>Switch off delay(NXpositioner) (s) 0E+0 # Use this parameter for a reproducible position when switching off the Z-controller. When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. + Bias>Bias(NXBias) (V) (e.g. 100E-3) # Applied bias voltage. + Current>Current(NXcircuit) (A) (e.g. -5.3429E-15) # The tunneling current is displayed here. + Bias>Calibration(NXbias) (V/V) (e.g. 1E+0) # Calibration of the Bias output. If you have a Range switch the calibration is stored per range setting. + Bias>Offset(NXbias) (V) (e.g. 0E+0) # Allows compensating for an offset in Bias. + Current>Calibration(NXcircuit) (A/V) (e.g. 100E-12) # The signals voltages are converted to real world physical values according to the calibration & offset parameters: Physical signal = (Voltage * calibration) + offset. + Current>Offset(NXcircuit) (A) (e.g. 16.2897E-15) # The same as "Current>Calibration (A/V)" tag + Current>Gain(NXcircuit) (e.g. Not switchable) # None + Z offset(NXpositioner) (m) (e.g. 0E+0) # Offset added to the initial averaged position Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an alternate Z-controller setpoint is enabled. + Settling time(NXbias) (s) (e.g. 2.1E-3) # Time to wait after changing the bias to the next level and before starting to acquire data. Adjust this parameter to avoid transient effect induced by the bias change. Integration time: time during which the data are acquired and averaged. + Z-Ctrl hold(NXpositioner) (e.g. TRUE) # When selected, the Z-Controller is set to hold during the pulse. This means that the controller doesn't control the Z position during the pulse. + Final Z(NXpositioner) (m) (e.g. N/A) + Start time(NXlog) (e.g.23.11.2022 18:55:16) # Timestamp of the moment when the acquisition starts by pressing the Start button. + Bias Spectroscopy>Z offset(NXbias) (m) (e.g.0E+0) # Offset added to the initial averaged position Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an alternate Z-controller setpoint is enabled. + Bias Spectroscopy>1st Settling time(NXbias) (s) (e.g.2.1E-3) # See the "Settling time (s)" below. + Bias Spectroscopy>Settling time(NXbias) (s) (e.g.2.1E-3) # See the "Settling time (s)" below. + Bias Spectroscopy>Integration time(NXbias) (s) (e.g.150E-6) # Time during which the data are acquired and averaged. + Bias Spectroscopy>End Settling time(NXbias) (s) (e.g.4E-3) # Time to wait after the sweep has finished and the bias is ramped to the initial value. + Bias Spectroscopy>Z control time(NXbias) (s) (e.g.200E-3) # Time during which the Z-Controller is enabled once a sweep has finished. When averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled for this duration between each sweep. After the last sweep, it will wait the specified time before continuing a running scan. This ensures each sweep reliably starts from the same position. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. + Bias Spectroscopy>Max Slew rate(NXbias) (V/s) (e.g.1E+0) # Maximum rate at which the bias changes (before, during and after sweeping). + Bias Spectroscopy>backward sweep(NXbias) (e.g.TRUE) # Select whether to measure the backward (return) sweep or the forward only. + Bias Spectroscopy>Z-controller hold(NXbias) (e.g.TRUE # Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. + Z-Controller>Controller name(NXpositioner) (e.g.log Current) # Controller name. This name which will be displayed at places where you can select a controller. + Z-Controller>Controller status(NXpositioner) (e.g.OFF) # ON/OFF + Z-Controller>Setpoint(NXpositioner) (e.g.50E-12) # Set Point is the desired value of the control signal. It can be set by editing the number or using the slider bar. Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. + Z-Controller>Setpoint unit(NXpositioner) (e.g.A) # Angstrom + Z-Controller>P gain(NXpositioner) (e.g.6E-12) # The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. + Z-Controller>I gain(NXpositioner) (e.g.39.8241E-9) # See "Z-Controller>P gain" below. + Z-Controller>Time const(NXpositioner) (s) (e.g.150.662E-6) # See "Z-Controller>P gain" below. + Z-Controller>TipLift(NXpositioner) (m) (e.g.0E+0) # Lifts the tip by the specified amount when then controller is switched off. This can be a positive or a negative number, i.e. the tip can also be moved towards the sample. Be careful with sign and value when using this feature. + Z-Controller>Switch off delay(NXpositioner) (s) (e.g.0E+0) # Use this parameter for a reproducible position when switching off the Z-controller. When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. - DATA # multi dimensional array: multi I-V array per scan point; + DATA(NXdata) # multi dimensional array: multi I-V array per scan point; + doc: The format of the data here is similar to a column matrix. Bias calc (V) #scanning parameter Current (A) # current during forward direction scanning of bias - original NXsensor LI Demod 2 X (A) lockin (NXsensor+lockin) From d35f6eafb9c4e389c72fbee59f4af397143db5ff Mon Sep 17 00:00:00 2001 From: Yichen Date: Tue, 9 May 2023 17:41:12 +0200 Subject: [PATCH 0131/1012] Correct the format --- contributed_definitions/nyaml/NXbias.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributed_definitions/nyaml/NXbias.yaml b/contributed_definitions/nyaml/NXbias.yaml index e8652e9d68..ed13826fe6 100644 --- a/contributed_definitions/nyaml/NXbias.yaml +++ b/contributed_definitions/nyaml/NXbias.yaml @@ -44,7 +44,7 @@ NXbias(NXobject): doc: Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). unit: NX_TIME SW Filter type (NX_CHAR): - doc Select a filter to smooth the displayed data. When saving, if any filter selected, filtered data are saved to file along with the unfiltered data. + doc: Select a filter to smooth the displayed data. When saving, if any filter selected, filtered data are saved to file along with the unfiltered data. SW Filter Order(NX_NUMBER): doc: Filter order of a dynamic filter or width (in number of points) for the gaussian filter. SW Filter Cutoff frq(NX_NUMBER): From cfc15cb6bd07933e3eb4cbe23d995548646e69b1 Mon Sep 17 00:00:00 2001 From: Rubel Date: Wed, 14 Jun 2023 10:57:13 +0200 Subject: [PATCH 0132/1012] fix conflict in rebase --- contributed_definitions/nyaml/NXbias.yaml | 8 +- .../nyaml/NXbias_spectroscopy.yaml | 56 +++++ contributed_definitions/nyaml/NXcircuit.yaml | 119 +++++------ .../nyaml/NXiv_sweep2.yaml | 198 +++++++++--------- contributed_definitions/nyaml/NXlockin.yaml | 38 ++-- 5 files changed, 226 insertions(+), 193 deletions(-) create mode 100644 contributed_definitions/nyaml/NXbias_spectroscopy.yaml diff --git a/contributed_definitions/nyaml/NXbias.yaml b/contributed_definitions/nyaml/NXbias.yaml index ed13826fe6..dd84894338 100644 --- a/contributed_definitions/nyaml/NXbias.yaml +++ b/contributed_definitions/nyaml/NXbias.yaml @@ -5,18 +5,18 @@ NXbias(NXobject): bias(NX_NUMBER): doc: Applied a voltage between tip and sample. unit: NX_VOLTAGE - tunneling resistor(NX_NUMBER): + tunneling_resistor(NX_NUMBER): doc: The ratio between the tunneling current at the sample surface and the bias voltage applied between between the sample and the tip. unit: NX_ANY (No NX_resistance) - Calibration(NX_NUMBER): + calibration(NX_NUMBER): doc: Calibration of the Bias output (V/V). offset(NX_NUMBER): doc: Allows compensating for an offset in Bias. Hardware parameter offset. unit: NX_VOLTAGE - Modulated signal Bias(NX_NUMBER): # or transfer it to NXlockin? + modulated_signal_bias(NX_NUMBER): # or transfer it to NXlockin? doc: Sets the amplitude (in physical units of the modulated signal) of the sine modulation. unit: NX_VOLTAGE - (Bias Spectroscopy): + (NXbias_spectroscopy): doc: Bias sweeps while measuring arbitrary channels with I(V) curves. Channels(NX_CHAR): doc: Select the channels to record. diff --git a/contributed_definitions/nyaml/NXbias_spectroscopy.yaml b/contributed_definitions/nyaml/NXbias_spectroscopy.yaml new file mode 100644 index 0000000000..d74c76d92c --- /dev/null +++ b/contributed_definitions/nyaml/NXbias_spectroscopy.yaml @@ -0,0 +1,56 @@ +doc: | + Base classes definition for bias spectroscopy. +category: base +NXbias_spectroscopy(NXobject): + doc: Bias sweeps while measuring arbitrary channels with I(V) curves. + channels: + doc: Select the channels to record. + reset_bias(NX_BOOLEAN): + doc: | + When selected, the Bias voltage returns to the initial value (before starting the sweep) at the end of the spectroscopy measurement (default). When not selected, Bias remains at the last value of the sweep. This is useful e.g. when combining several sweep segments. Example for an automated measurement (using Programming Interface): switch off Z-Controller, start spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, switch on Z-Controller. + record_final_z(NX_BOOLEAN): + doc: Select whether to record the Z position during Z averaging time at the end of the sweep (after Z control time) and store the average value in the header of the file when saving. Using this option increases the sweep time by Z averaging time. + lock_in_run(NX_BOOLEAN): + doc: Select whether to set the Lock-In to run during the measurement. When using this feature, make sure the Lock-In is configured correctly and settling times are set to twice the Lock-In period at least. This option is ignored when Lock-In is already running. This option is disabled if the Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline segment editor is set. + integration_time(NX_NUMBER): + doc: Time during which the spectroscopy data are acquired and averaged. + unit: NX_TIME + number_of_sweeps(NX_NUMBER): + doc: Number of sweeps to measure and average. + sweep_start(NX_NUMBER): + doc: The first bias values of the sweep. + unit: NX_VOLTAGE + sweep_end(NX_NUMBER): + doc: The last bias values of the sweep. + unit: NX_VOLTAGE + num_pixel(NX_NUMBER): + doc: Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. + z_avg_time(NX_NUMBER): + doc: Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). + unit: NX_TIME + sw_filter_type (NX_CHAR): + doc: Select a filter to smooth the displayed data. When saving, if any filter selected, filtered data are saved to file along with the unfiltered data. + sw_filter_order(NX_NUMBER): + doc: Filter order of a dynamic filter or width (in number of points) for the gaussian filter. + sw_filter_cutoff_frq(NX_NUMBER): + doc: Cutoff frequency for dynamic filters. + z_offset(NX_NUMBER): + doc: Offset added to the initial averaged position Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an alternate Z-controller setpoint is enabled. + unit: NX_LENGTH + settling_time(NX_NUMBER): + doc: time to wait after changing the bias to the next level and before starting to acquire data. + unit: NX_TIME + end_settling_time(NX_NUMBER): + doc: Time to wait after the sweep has finished and the bias is ramped to the initial value. + unit: NX_TIME + z_control_time(NX_NUMBER): + doc: Time during which the Z-Controller is enabled once a sweep has finished. When averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled for this duration between each sweep. After the last sweep, it will wait the specified time before continuing a running scan. This ensures each sweep reliably starts from the same position. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. + unit: NX_TIME + max_slew_rate(NX_NUMBER): + doc: Maximum rate at which the bias changes (before, during and after sweeping). (V/s) + backward_sweep(NX_BOOLEAN): + doc: Select whether to measure the backward (return) sweep or the forward only. + z_ccontroller_hold(NX_BOOLEAN): + doc: Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. + + diff --git a/contributed_definitions/nyaml/NXcircuit.yaml b/contributed_definitions/nyaml/NXcircuit.yaml index f463b2b72c..7577ba12a1 100644 --- a/contributed_definitions/nyaml/NXcircuit.yaml +++ b/contributed_definitions/nyaml/NXcircuit.yaml @@ -1,69 +1,54 @@ -doc: | +doc: | Application definition for circuit devices. category: base -NXcircuit: - hardware(NX_FABRICATION): - doc: Hardware type used in circuit, includes hardware manufacturers and type - Tunneling Current(NX_NUMBER): - doc: The tunneling current between tip and sample after application of bias voltage. - unit: NX_CURRENT - Calibration(NX_NUMBER): - doc: Calibration of the current measurement (A/V). - Offset(NX_NUMBER): - doc: Offset of the current measurement. - unit: NX_CURRENT - Gain(NX_NUMBER): - doc: Proportional relationship between the probe output voltage and the actual tunneling current when measuring the tunneling current. - channels(NX_CHAR): - doc: The scan channels are selected by users (in scan contronaller). - RT Frequency(NX_NUMBER): - doc: The bandwitdh of the Hardware and/or Software - unit: NX_FREQUENCY - Signals Oversampling(NX_NUMBER): - doc: (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. - unit: NX_ANY - Acquisition Period(NX_NUMBER): - doc: Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. - unit: NX_TIME - Animations Period(NX_NUMBER): - doc: Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. - unit: NX_TIME - Indicators Period(NX_NUMBER): - doc: Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. - unit: NX_TIME - Measurements Period(NX_NUMBER): - doc: The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. - unit: NX_TIME - RT Frequency(NX_NUMBER): - doc: The bandwitdh of the Hardware and/or Software. - unit: NX_FREQUENCT - Signals Oversampling(NX_CHAR): - doc: The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. - Acquisition Period(NX_NUMBER): - doc: Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. - unit: NX_TIME - Animations Period(NX_NUMBER): - doc: Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. - unit: NX_TIME - Indicators Period(NX_NUMBER): - doc: Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. - unit: NX_TIME - Measurements Period(NX_NUMBER): - doc: The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. - unit: NX_TIME - Output N Mode(NX_CHAR): - doc: N represents the number of signal channels. The user output in each monitor mode. - Output N Value(NX_NUMBER): - doc: N represents the number of signal channels. The values for each output channel. - unit: NX_ANY - Output N Name(NX_CHAR): - doc: N represents the number of signal channels. User outputs whose name can be modified in the corresponding module. - Output N Slew Rate(NX_CHAR): - doc: N represents the number of signal channels. The rate at which the one of the signal changes when ramping to the starting point. (V/s) - - - - - - - +NXcircuit(NXobject): + hardware(NX_FABRICATION): + doc: Hardware type used in circuit, includes hardware manufacturers and type + tunneling_current(NX_NUMBER): + doc: The tunneling current between tip and sample after application of bias voltage. + unit: NX_CURRENT + calibration(NX_NUMBER): + doc: Calibration of the current measurement (A/V). + offset(NX_NUMBER): + doc: Offset of the current measurement. + unit: NX_CURRENT + gain(NX_NUMBER): + doc: Proportional relationship between the probe output voltage and the actual tunneling current when measuring the tunneling current. + channels(NX_CHAR): + doc: The scan channels are selected by users (in scan contronaller). + rt_frequency(NX_NUMBER): + doc: The bandwitdh of the Hardware and/or Software + unit: NX_FREQUENCY + signals_oversampling(NX_NUMBER): + doc: (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. + unit: NX_ANY + acquisition_period(NX_NUMBER): + doc: Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. + unit: NX_TIME + animations_period(NX_NUMBER): + doc: Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. + unit: NX_TIME + indicators_period(NX_NUMBER): + doc: Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. + unit: NX_TIME + measurements_period(NX_NUMBER): + doc: The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. + unit: NX_TIME + number_of_outputs(NX_INT): + doc: number of output channels + output_mode_N(NX_CHAR): + doc: N represents the number of signal channels. The user output in each monitor mode. + output_value_N(NX_NUMBER): + doc: N represents the number of signal channels. The values for each output channel. + unit: NX_ANY + output_name_N: + doc: N represents the number of signal channels. User outputs whose name can be modified in the corresponding module. + output_slew_rate_N(NX_CHAR): + doc: N represents the number of signal channels. The rate at which the one of the signal changes when ramping to the starting point. (V/s) + + + + + + + diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index 6394585fd9..664cb6667e 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -1,17 +1,17 @@ -doc: | +doc: | Application definition for temperature-dependent IV curve measurements, #CAP with a focus on bias spectroscopy in scanning tunneling microscopy. - + In this application definition, times should be specified always together with an UTC offset. - + This is the application definition describing temperature (T) dependent current voltage (IV) curve measurements. For this a temperature is set. After reaching the temperature, a voltage sweep is performed. For each voltage a current is measured. Then, the next desired temperature is set and an IV measurement is performed. - #CAP the X, Y, Z, position of the probes or tip can be defined. #CAP The data can be visualized in a tensor with: + #CAP the X, Y, Z, position of the probes or tip can be defined. #CAP The data can be visualized in a tensor with: I (NXsensor_C, NXsoftware_Read_offset, NXcircuit) - parameters: - V has (NXsource+offset, NXsoftware_Scan_offset, NXsensor_V, NXcircuit) + parameters: + V has (NXsource+offset, NXsoftware_Scan_offset, NXsensor_V, NXcircuit) T has (NXsource, NXsoftware_Scan_offset, NXsensor_T) x has (NXsoftware_Scan_offset) y has (NXsoftware_Scan_offset) @@ -19,102 +19,94 @@ doc: | category: application NXiv_sweep2(NXsensor_scan): (NXentry): - definition(NX_CHAR): + definition: enumeration: [NXiv_sweep2] + type: + enumeration: [background, reference, sample] + experiment_identifier: + doc: e.g. finename -> description (e.g. 221122_Au_5K00014) + collection_dentifier: + doc: series name -> description? Scan>series name 221122_Au_5K + entry_identifier: + doc: session path (ELN?!)-> NanonisMain>Session Path C:\Users\SPM-PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis-Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711 + experiment_description: + doc: Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, locked Au(111), 50pA, 100 mV set point, 1mV DCA, 973Hz,138 1st H, -84 2nd H (NXinstrument): - Hardware: - doc: the name of the instrument device used.... + (NXfabrication): # any or specifique 'harware' and 'software'? + doc: | + hardware and software + the name of the instrument device used.... e.g. Nanonis BP5e + Software: SoftwareMain>SW Version Generic 5e -- SoftwareMain>UI Release 10771 -- SoftwareMain>RT Release 10771 + current_amplifier(NXamplifier): + # hardware: Current amplifier> hardware: CreaTec GmbH + # amplification: Current amplifier> factor (V/V): 1E-10 + # crosstalk_compensation: Current amplifier> Capacitive cross-talk compensation: Yes/No + lock_in(NXlockin): + exists: optional + # status: Lock-in>Lock-in status ON # ON/OFF of Lock-in amplifier + amplifier_status: + doc: Lock-in Amplifier>Yes/No # If a lock-in amplifier employed to filter or obtain the electronic derivatives dI/dV of the signal + # hardware: Lock-in Amplifier>Hardware: Nanonis + bias_divider: + doc: if Lock-in -- Bias Divider 1/10 or 1/100 # if the modulation + # modulate_signal: Lock-in>Modulated signal Bias (V) # This is the signal on which the modulation (sine) will be added. + # frequency: Lock-in>Frequency (Hz) 973E+0 # Sets the frequency of the sine modulation added to the signal to modulate. The frequency range is from 10 mHz to 40 kHz (corresponding to the SC5 output filter cut-off). When working with harmonics, make sure the harmonic frequencies don’t exceed ~100 kHz (SC5 input filter cut-off). Remember the SC5 hardware filters will affect the amplitude when getting close to their cut-off frequencies. + # amplitude: Lock-in>Amplitude 2E-3 # Sets the amplitude (in physical units of the modulated signal) of the sine modulation. + # demodulated_signal: Lock-in>Demodulated signal Current (A) # This is the signal which will be demodulated, in order to determine the amplitude and phase at the frequency set in the Frequency field (“4”) or harmonics. + # order_of_harmonics: + # Lock-in>Harmonic D1 1 # Order of the harmonic oscillation to detect on the demodulated signal (with respect to the modulation frequency). If you work with higher harmonics make sure the frequency does not exceed the analog signal bandwidth (100 kHz). + # Lock-in>Harmonic D2 2 # See below. + # ref_phase: + # Lock-in>Reference phase D1 (deg) 137.597E+0 # Reference phase for the sine on the demodulated signal with respect to the modulation signal. The determined phase (phi) is displayed with respect to the reference phase. + # Lock-in>Reference phase D2 (deg) -83.6562E+0 # See below. + # items below should go to bias/spectroscopy/...!!! + #recorded_channels: + # doc: here??? Bias Spectroscopy>Channels Current (A);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A) # Select the channels to record. + #bias_reset: + # doc: here??? Bias Spectroscopy>Reset Bias TRUE # When selected, the Bias voltage returns to the initial value (before starting the sweep) at the end of the spectroscopy measurement (default). When not selected, Bias remains at the last value of the sweep. This is useful e.g. when combining several sweep segments. Example for an automated measurement (using Programming Interface): switch off Z-Controller, start spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, switch on Z-Controller. + #record_final_z: + # doc: here??? Bias Spectroscopy>Record final Z FALSE # Select whether to record the Z position during Z averaging time at the end of the sweep (after Z control time) and store the average value in the header of the file when saving. Using this option increases the sweep time by Z averaging time. + #run: + # doc: Bias Spectroscopy>Lock-In run FALSE # Select whether to set the Lock-In to run during the measurement. When using this feature, make sure the Lock-In is configured correctly and settling times are set to twice the Lock-In period at least. This option is ignored when Lock-In is already running. This option is disabled if the Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline segment editor is set. + tip_bias(NXbias): + sample_bias(NXbias): + # Tip bias/Sample bias # If the spectroscopy V bias is applied to the + # Modulated signal Bias (V) 1E-3 # Applied modulation to the bias voltage. + # ModulationBias> Tip bias/Sample bias + modulated_signal_bias: + doc: here??? Modulated signal Bias (V) 1E-3 # Applied modulation to the bias voltage. + stm_head_temperature(NX_NUMBER): + unit: NX_TEMPERATURE + doc: | + STM head + temp Temperature 1 (K) 4.92997E+0 # Temperature of STM head. + cryo_bottom_temp: + unit: NX_TEMPERATURE + doc: bottom_temp Temperature 2 (K) - # Temperature of bottom of LHe helium cryostat. + cryo_shield_temp: + unit: NX_TEMPERATURE + doc: shield_temp Temperature 3 (K) - # Temperature of LN2 nitrogen shield. + output_cabling(NXcircuit): + # Cabling & Config (NXenvironment): - doc: | + doc: | Describes an environment setup for a temperature-dependent IV measurement experiment. - + The temperature and voltage must be present as independently scanned controllers and the current sensor must also be present with its readings. voltage_controller(NXsensor): temperature_controller(NXsensor): current_sensor(NXsensor): (NXdata): - doc: | + doc: | This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. There should also be two more fields called temperature and voltage containing the setpoint values. There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension equal to the number of voltage setpoints. - - - - (file)type [background, reference, sample] - finename -> description (e.g. 221122_Au_5K00014) - series name -> description? Scan>series name 221122_Au_5K - session path (ELN?!)-> NanonisMain>Session Path C:\Users\SPM-PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis-Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711 - description: Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, locked Au(111), 50pA, 100 mV set point, 1mV DCA, 973Hz,138 1st H, -84 2nd H + + + INSTRUMENT - Hardware: Nanonis BP5e - Software: SoftwareMain>SW Version Generic 5e -- SoftwareMain>UI Release 10771 -- SoftwareMain>RT Release 10771 - Current amplifier (NXamplifier) - Current amplifier> hardware: CreaTec GmbH - Current amplifier> factor (V/V): 1E-10 - Current amplifier> Capacitive cross-talk compensation: Yes/No - - Lock-in>Lock-in status ON # ON/OFF of Lock-in amplifier - Lock in (optional) (NXlockin) - Lock-in Amplifier>Yes/No # If a lock-in amplifier employed to filter or obtain the electronic derivatives dI/dV of the signal - Lock-in Amplifier>Hardware: Nanonis - if Lock-in -- Bias Divider 1/10 or 1/100 # if the modulation - - Bias Spectroscopy>Channels Current (A);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A) # Select the channels to record. - Bias Spectroscopy>Reset Bias TRUE # When selected, the Bias voltage returns to the initial value (before starting the sweep) at the end of the spectroscopy measurement (default). When not selected, Bias remains at the last value of the sweep. This is useful e.g. when combining several sweep segments. Example for an automated measurement (using Programming Interface): switch off Z-Controller, start spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, switch on Z-Controller. - Bias Spectroscopy>Record final Z FALSE # Select whether to record the Z position during Z averaging time at the end of the sweep (after Z control time) and store the average value in the header of the file when saving. Using this option increases the sweep time by Z averaging time. - Bias Spectroscopy>Lock-In run FALSE # Select whether to set the Lock-In to run during the measurement. When using this feature, make sure the Lock-In is configured correctly and settling times are set to twice the Lock-In period at least. This option is ignored when Lock-In is already running. This option is disabled if the Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline segment editor is set. - Lock-in>Modulated signal Bias (V) # This is the signal on which the modulation (sine) will be added. - Lock-in>Frequency (Hz) 973E+0 # Sets the frequency of the sine modulation added to the signal to modulate. The frequency range is from 10 mHz to 40 kHz (corresponding to the SC5 output filter cut-off). When working with harmonics, make sure the harmonic frequencies don’t exceed ~100 kHz (SC5 input filter cut-off). Remember the SC5 hardware filters will affect the amplitude when getting close to their cut-off frequencies. - Lock-in>Amplitude 2E-3 # Sets the amplitude (in physical units of the modulated signal) of the sine modulation. - Lock-in>Demodulated signal Current (A) # This is the signal which will be demodulated, in order to determine the amplitude and phase at the frequency set in the Frequency field (“4”) or harmonics. - Lock-in>Harmonic D1 1 # Order of the harmonic oscillation to detect on the demodulated signal (with respect to the modulation frequency). If you work with higher harmonics make sure the frequency does not exceed the analog signal bandwidth (100 kHz). - Lock-in>Harmonic D2 2 # See below. - Lock-in>Reference phase D1 (deg) 137.597E+0 # Reference phase for the sine on the demodulated signal with respect to the modulation signal. The determined phase (phi) is displayed with respect to the reference phase. - Lock-in>Reference phase D2 (deg) -83.6562E+0 # See below. - - Bias: Tip bias/Sample bias # If the spectroscopy V bias is applied to the - Modulated signal Bias (V) 1E-3 # Applied modulation to the bias voltage. - ModulationBias> Tip bias/Sample bias - STM head - temp Temperature 1 (K) 4.92997E+0 # Temperature of STM head. - Cryo - bottom_temp Temperature 2 (K) - # Temperature of bottom of LHe helium cryostat. - shield_temp Temperature 3 (K) - # Temperature of LN2 nitrogen shield. - Cabling & Config - Outputs>Output 0 Mode User Output - Outputs>Output 1 Mode User Output - Outputs>Output 2 Mode User Output - Outputs>Output 3 Mode User Output - Outputs>Output 4 Mode User Output - Outputs>Output 5 Mode User Output - Outputs>Output 6 Mode User Output - Outputs>Output 7 Mode User Output - Outputs>Output 0 Value 0E+0 - Outputs>Output 1 Value 0E+0 - Outputs>Output 2 Value 0E+0 - Outputs>Output 3 Value 2.5539E+0 - Outputs>Output 4 Value 0E+0 - Outputs>Output 5 Value 0E+0 - Outputs>Output 6 Value 0E+0 - Outputs>Output 7 Value 0E+0 - Outputs>Output 0 Name Input 24 (V) - Outputs>Output 1 Name Bias (V) - Outputs>Output 2 Name Output 2 (V) - Outputs>Output 3 Name T1 Supply voltage (V) - Outputs>Output 4 Name Output 4 (V) - Outputs>Output 5 Name X (m) - Outputs>Output 6 Name Y (m) - Outputs>Output 7 Name Z (m) - Outputs>Output 0 Slew Rate Inf - Outputs>Output 1 Slew Rate Inf - Outputs>Output 2 Slew Rate Inf - Outputs>Output 3 Slew Rate Inf - Outputs>Output 4 Slew Rate Inf - Outputs>Output 5 Slew Rate Inf - Outputs>Output 6 Slew Rate Inf - Outputs>Output 7 Slew Rate Inf Piezo Config Piezo Configuration>Active Calib. LHe # Tne name of caliberation type. Piezo Configuration>Calib. X (m/V) 3.8E-9 # There are 3 controls available: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. @@ -129,11 +121,11 @@ NXiv_sweep2(NXsensor_scan): Piezo Configuration>Curvature radius Y (m) Inf # See below. Piezo Configuration>2nd order corr X (V/m^2) 0E+0 # If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. Piezo Configuration>2nd order corr Y (V/m^2) 0E+0 # See below. - Piezo Configuration>Drift X (m/s) 0E+0 # Define the drift speed for all three axes. When the compensation is on, the piezos will start to move at that speed. + Piezo Configuration>Drift X (m/s) 0E+0 # Define the drift speed for all three axes. When the compensation is on, the piezos will start to move at that speed. Piezo Configuration>Drift Y (m/s) 0E+0 # See below. Piezo Configuration>Drift Z (m/s) 0E+0 # See below. Piezo Configuration>Drift correction status (on/off) FALSE # Use the button to turn on/off the drift compensation. - + MEASUREMENT Position (NXtransformation) # also clarify the frame laboratory frame X (m) -890.53E-12 @@ -157,11 +149,11 @@ NXiv_sweep2(NXsensor_scan): frame(NXtransformation) # also clarify the frame for the ROI of the scan (should depend on the lab frame) Scan>Scanfield 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0 # Configure the scan frame: x position; y position; width; height. Scan>channels Current (A);Bias (V);Z (m);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A) # The scan channels are selected by users. - Scan>pixels/line 512 # Scan resolution by setting the Lines equal to Pixels. + Scan>pixels/line 512 # Scan resolution by setting the Lines equal to Pixels. Scan>lines 512 # Define the image resolution. - Scan>speed forw. (m/s) 11.7187E-9 # Define the scan forward speed in the forward direction. + Scan>speed forw. (m/s) 11.7187E-9 # Define the scan forward speed in the forward direction. Scan>speed backw. (m/s) 11.7187E-9 # Define the scan backward speed in the forward direction. - + SW Filter (PROCESS) type Butterworth # Select a filter to smooth the displayed data. Note: When saving, if any filter selected, filtered data are saved to file along with the unfiltered data. Order 1 # Filter order of a dynamic filter or width (in number of points) for the gaussian filter. @@ -245,7 +237,7 @@ NXiv_sweep2(NXsensor_scan): LI Demod 2 Y (A) [filt] lockin LI Demod 1 X (A) [filt] lockin LI Demod 1 Y (A) [filt] lockin - Current (A) [bwd] [filt] + Current (A) [bwd] [filt] LI Demod 2 X (A) [bwd] [filt] lockin LI Demod 2 Y (A) [bwd] [filt] lockin LI Demod 1 X (A) [bwd] [filt] lockin @@ -254,17 +246,17 @@ NXiv_sweep2(NXsensor_scan): x y z - + single point default plot # current(I) vs bias(V) line scan default plot # multi I vs. V curves alternative plot # current(I) curve in the 2D space of (position(x), bias(V)) mesh scan default plot # 2D slices of the above alternative plot - - - - - - - - - + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXlockin.yaml b/contributed_definitions/nyaml/NXlockin.yaml index 606e617f62..00e1efedf0 100644 --- a/contributed_definitions/nyaml/NXlockin.yaml +++ b/contributed_definitions/nyaml/NXlockin.yaml @@ -1,4 +1,4 @@ -doc: | +doc: | Base classes definition for lock in devices. category: base NXlockin: @@ -6,47 +6,47 @@ NXlockin: doc: Hardware manufacturers and type of lockin amplifier. (NXamplifier): doc: input and output amplifiers - Lock-in stats(NX_BOOLEAN): + status(NX_BOOLEAN): doc: Switch the lock-in moulation on or off. - Modulate signal(NX_CHAR): + modulate_signal: doc: This is the signal on which the modulation (sine) will be added, such as current, bias, et.al. - Amplitude(NX_NUMBER): + amplitude(NX_NUMBER): doc: Sets the amplitude (in physical units of the modulated signal) of the sine modulation. unit: NX_VOLTAGE (For bais modulate signal, it depands on the modulate type) frequency(NX_NUMBER): - doc: Sets the frequency of the sine modulation added to the signal to modulate. + doc: Sets the frequency of the sine modulation added to the signal to modulate. unit: NX_FREQUENCY - Demodulated signal(NX_CHAR): + demodulated_signal: doc: This is the signal which will be demodulated, in order to determine the amplitude and phase at the frequency set in the Frequency field or harmonics, such as current, bias, et.al. #output (demodulated signal) characterisation (foreach channel, like demodulation, a separate sensor output, e.g. X,Y) - NumOfDemodulatorChannels(NX_NUMBER): + number_of_demodulator_channels(NX_NUMBER): doc: The number of signals which will be demodulated. - LowPass(NX_NUMBER): + low_pass(NX_NUMBER): doc: Order and cut-off frequency of the low-pass filter applied on the demodulated signals (X,Y). Cut-off frq (low pass filter) (foreach DemodulatorChannels) unit: NX_FREQUENCY - HiPass(NX_NUMBER): + hi_pass(NX_NUMBER): doc: Order and cut-off frequency of the high-pass filter applied on the demodulation signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) unit: NX_FREQUENCY - LP Filter Cutoff(NX_NUMBER): + lp_filter Cutoff(NX_NUMBER): doc: Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) value) for D1. The filter is applied to the demodulated signals (X,Y). unit: NX_FREQUENCY - LP Filter Order(NX_NUMBER): + lp_filter_order(NX_NUMBER): doc: Order and cut-off frequency of the low-pass filter applied on the demodulated signals (X,Y). Reducing the bandwidth or increasing the order reduces noise on the demodulated signals, but will require longer settling and measurement times. - HP Filter Cutoff(NX_NUMBER): + hp_filter_cutoff(NX_NUMBER): doc: Sets the cut-off frequency of the high-pass filter (affects the displayed TC (s) value) for D1. The filter is applied to the demodulated signals (X,Y). unit: NX_FREQUENCY - HP Filter Order(NX_NUMBER): + hp_filter_order(NX_NUMBER): doc: Order and cut-off frequency of the high-pass filter applied on the demodulation signal of D!. This is used mainly to suppress a DC component of the demodulation signal, which would lead to a component at modulation frequency in the demodulated signals. - Sync(NX_BOOLEAN): + sync(NX_BOOLEAN): doc: Switch on/off the Sync filter on the demodulated signals (X,Y) on or off. (foreach DemodulatorChannels) - refPhase(NX_NUMBER): + ref_phase(NX_NUMBER): doc: Reference phase for the sine on the demodulated signal with respect to the modulation signal. (foreach DemodulatorChannels) unit: NX_FREQUENCY - integrationTime(NX_NUMBER): + integration_time(NX_NUMBER): doc: Time during which the data are acquired and averaged. (for the input filter) unit: NX_TIME - OrderOfHarmonics(NX_NUMBER): + order_of_harmonics(NX_NUMBER): doc: The order of the harmonic oscillation to detect on the demodulated signals. (with respect to the modulation frequency) - sensitivityFactor(NX_NUMBER): + sensitivity_factor(NX_NUMBER): doc: Ratio of output signal amplitude to input signal amplitue (V/V). (input gain) # Not sure about it. - + From dffa45d964d76e8484c5f66f784ff8725a37acac Mon Sep 17 00:00:00 2001 From: Yichen Date: Tue, 16 May 2023 23:41:59 +0200 Subject: [PATCH 0133/1012] Update file following the new version of backup, NXbias, Nxcircuit....files --- .../nyaml/NXiv_sweep2.yaml | 308 +++++++++++------- 1 file changed, 189 insertions(+), 119 deletions(-) diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index 664cb6667e..ec2bdaf8b0 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -24,19 +24,21 @@ NXiv_sweep2(NXsensor_scan): type: enumeration: [background, reference, sample] experiment_identifier: - doc: e.g. finename -> description (e.g. 221122_Au_5K00014) + doc: The name of the output file, with the number of scans at the end.e.g. (e.g. 221122_Au_5K00014) collection_dentifier: - doc: series name -> description? Scan>series name 221122_Au_5K + doc: The name of the series output file, which represents only the public part of the output file. (e.g. 221122_Au_5K） entry_identifier: - doc: session path (ELN?!)-> NanonisMain>Session Path C:\Users\SPM-PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis-Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711 + doc: Path to storage of output files. (e.g. Path C:\Users\SPM-PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis-Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711) experiment_description: - doc: Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, locked Au(111), 50pA, 100 mV set point, 1mV DCA, 973Hz,138 1st H, -84 2nd H + doc: Descriptive comments for this experiment, added by the experimenter, coming from the output file. (e.g. Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, locked Au(111), 50pA, 100 mV set point, 1mV DCA, 973Hz,138 1st H, -84 2nd H) (NXinstrument): (NXfabrication): # any or specifique 'harware' and 'software'? doc: | - hardware and software - the name of the instrument device used.... e.g. Nanonis BP5e - Software: SoftwareMain>SW Version Generic 5e -- SoftwareMain>UI Release 10771 -- SoftwareMain>RT Release 10771 + Software and hardware for control, scanning and data collection in the SPM system + hardware: + doc: Hardware type used in SPM experiment, includes hardware manufacturers and type. (e.g. Nanonis BP5e) + softwareMain>Software: + doc: Type of software used in SPM experiments, e.g. software version serial number, UI and RT probe release method. (e.g. SW Version Generic 5e -- SoftwareMain>UI Release 10771 -- SoftwareMain>RT Release 10771) current_amplifier(NXamplifier): # hardware: Current amplifier> hardware: CreaTec GmbH # amplification: Current amplifier> factor (V/V): 1E-10 @@ -61,11 +63,11 @@ NXiv_sweep2(NXsensor_scan): # Lock-in>Reference phase D2 (deg) -83.6562E+0 # See below. # items below should go to bias/spectroscopy/...!!! #recorded_channels: - # doc: here??? Bias Spectroscopy>Channels Current (A);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A) # Select the channels to record. + # doc: Select the channels to record. (e.g. Current (A);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A) # Select the channels to record.) #bias_reset: - # doc: here??? Bias Spectroscopy>Reset Bias TRUE # When selected, the Bias voltage returns to the initial value (before starting the sweep) at the end of the spectroscopy measurement (default). When not selected, Bias remains at the last value of the sweep. This is useful e.g. when combining several sweep segments. Example for an automated measurement (using Programming Interface): switch off Z-Controller, start spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, switch on Z-Controller. + # doc: When selected, the Bias voltage returns to the initial value (before starting the sweep) at the end of the spectroscopy measurement (default). When not selected, Bias remains at the last value of the sweep. This is useful e.g. when combining several sweep segments. Example for an automated measurement (using Programming Interface): switch off Z-Controller, start spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, switch on Z-Controller. (e.g. TRUE) #record_final_z: - # doc: here??? Bias Spectroscopy>Record final Z FALSE # Select whether to record the Z position during Z averaging time at the end of the sweep (after Z control time) and store the average value in the header of the file when saving. Using this option increases the sweep time by Z averaging time. + # doc: Select whether to record the Z position during Z averaging time at the end of the sweep (after Z control time) and store the average value in the header of the file when saving. Using this option increases the sweep time by Z averaging time. (e.g. FALSE) #run: # doc: Bias Spectroscopy>Lock-In run FALSE # Select whether to set the Lock-In to run during the measurement. When using this feature, make sure the Lock-In is configured correctly and settling times are set to twice the Lock-In period at least. This option is ignored when Lock-In is already running. This option is disabled if the Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline segment editor is set. tip_bias(NXbias): @@ -73,21 +75,29 @@ NXiv_sweep2(NXsensor_scan): # Tip bias/Sample bias # If the spectroscopy V bias is applied to the # Modulated signal Bias (V) 1E-3 # Applied modulation to the bias voltage. # ModulationBias> Tip bias/Sample bias - modulated_signal_bias: - doc: here??? Modulated signal Bias (V) 1E-3 # Applied modulation to the bias voltage. + modulated_signal_bias(NX_NUMBER): + unit: NX_VOLTAGE + doc: Same directional representation as bias. (e.g. 1E-3) stm_head_temperature(NX_NUMBER): unit: NX_TEMPERATURE doc: | - STM head - temp Temperature 1 (K) 4.92997E+0 # Temperature of STM head. - cryo_bottom_temp: + Temperature of STM head. Temperature 1 (K) (e.g. 4.92997E+0) + cryo_bottom_temp(NX_NUMBER): unit: NX_TEMPERATURE - doc: bottom_temp Temperature 2 (K) - # Temperature of bottom of LHe helium cryostat. - cryo_shield_temp: + doc: Temperature of LHe helium cryostat. Temperature 2 (K) (e.g 4.92997E+0) + cryo_shield_temp(NX_NUMBER): unit: NX_TEMPERATURE - doc: shield_temp Temperature 3 (K) - # Temperature of LN2 nitrogen shield. + doc: Temperature of LN2 nitrogen shield. Temperature 3 (K) (e.g 78.00000E+0) output_cabling(NXcircuit): # Cabling & Config + output_mode: + doc: Number of output channels. (e.g. User Output) + output_value(NX_NUMBER): + doc: The user output in each monitor mode. (e.g. 0E+0) + output_name: + doc: User outputs whose name can be modified in the corresponding module. (e.g. Input 24 (V)) + output_slew_rate(NX_NUMBER): + doc: The rate at which the one of the signal changes when ramping to the starting point. (V/s) (e.g. Inf) (NXenvironment): doc: | Describes an environment setup for a temperature-dependent IV measurement experiment. @@ -108,119 +118,179 @@ NXiv_sweep2(NXsensor_scan): INSTRUMENT Piezo Config - Piezo Configuration>Active Calib. LHe # Tne name of caliberation type. - Piezo Configuration>Calib. X (m/V) 3.8E-9 # There are 3 controls available: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. - Piezo Configuration>Calib. Y (m/V) 3.8E-9 # See below. - Piezo Configuration>Calib. Z (m/V) 900E-12 # See below. - Piezo Configuration>HV Gain X 14.5 # For some systems HV gain readout is available, so for those systems the HV gain should be adjusted automatically when the gain is changed at the high voltage amplifier. - Piezo Configuration>HV Gain Y 14.5 # See below. - Piezo Configuration>HV Gain Z 14.5 # See below. - Piezo Configuration>Tilt X (deg) 0.318343 # This tab is used to set the sample tilt (in degrees, first order correction). - Piezo Configuration>Tilt Y (deg) 1.584 # See below. - Piezo Configuration>Curvature radius X (m) Inf # This tab is used to set a curvature (can be set approximately to the length of the piezotube). - Piezo Configuration>Curvature radius Y (m) Inf # See below. - Piezo Configuration>2nd order corr X (V/m^2) 0E+0 # If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. - Piezo Configuration>2nd order corr Y (V/m^2) 0E+0 # See below. - Piezo Configuration>Drift X (m/s) 0E+0 # Define the drift speed for all three axes. When the compensation is on, the piezos will start to move at that speed. - Piezo Configuration>Drift Y (m/s) 0E+0 # See below. - Piezo Configuration>Drift Z (m/s) 0E+0 # See below. - Piezo Configuration>Drift correction status (on/off) FALSE # Use the button to turn on/off the drift compensation. + active_calib.: + doc: The name of caliberation type. (e.g. LHe) + calib._N(NX_NUMBER): + doc: N denotes X or Y or Z. There are 3 parameters in X, Y, and Z directions and there are 3 controls available: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. (e.g. 3.8E-9) + hv_gain_N(NX_NUMBER): + doc: N denotes X or Y or Z. For some systems HV gain readout is available, so for those systems the HV gain should be adjusted automatically when the gain is changed at the high voltage amplifier. (e.g. 14.5) + tilt_N(NX_NUMBER): (e.g. 0.318343) + unit: NX_ANGLE + doc: N denotes X or Y. There are 2 parameters in X and Y directions and this tab is used to set the sample tilt (in degrees, first order correction). + curvature radius N(NX_NUMBER): Inf + unit: NX_LENGTH + doc: N denotes X or Y. There are 2 parameters in X and Y directions and this tab is used to set a curvature (can be set approximately to the length of the piezotube). + 2nd_order_corr N(NX_NUMBER): + doc: N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2). (e.g. 0E+0) + drift_N(NX_NUMBER): + doc: N denotes X or Y. There are 2 parameters in X and Y directions. Define the drift speed for all three axes. When the compensation is on, the piezos will start to move at that speed. (e.g. 0E+0) + drift_correction_status(NX_BOOLEAN): + doc: Use the button to turn on/off the drift compensation. (e.g. FALSE) MEASUREMENT - Position (NXtransformation) # also clarify the frame laboratory frame - X (m) -890.53E-12 - Y (m) 29.6968E-9 - Z (m) 130.5E-9 - Z-Controller>Z (m) 130.5E-9 + Position(NXpositioner): + doc: Clarify the frame laboratory frame. + x(NX_NUMBER): + unit: NX_LENGTH + doc: The scanning area in x position in the frame. (e.g. -890.53E-12) + y(NX_NUMBER): + unit: NX_LENGTH + doc: The scanning area in y position in the frame. (e.g. 29.6968E-9) + z(NX_NUMBER): + unit: NX_LENGTH + doc: The scanning area in x position in the frame. (e.g. 130.5E-9) + z-controller(NB_NUMBER): + unit: NX_LENGTH + doc: Indicate the tip position Z between tip and sample. The tip position can also be varied when the controller is not running. (e.g. 130.5E-9) sweep control # parameters for a measurement at a single location during the scan - Integration time (s) 150E-6 # Time during which the spectroscopy data are acquired and averaged. - Bias Spectroscopy>Number of sweeps 100 # Number of sweeps to measure and average. - Bias Spectroscopy>Sweep Start (V) -300E-3 # The first bias values of the sweep. - Bias Spectroscopy>Sweep End (V) 300E-3 # The last bias values of the sweep. - Bias Spectroscopy>Num Pixel 4096 # Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. - Bias Spectroscopy>Z Avg time (s) 100E-3 # Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). - SoftwareMain>RT Frequency (Hz) 20E+3 # The bandwitdh of the Hardware and/or Software - SoftwareMain>Signals Oversampling 10 # (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. - SoftwareMain>Acquisition Period (s) 20E-3 # Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. - SoftwareMain>Animations Period (s) 20E-3 # Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. - SoftwareMain>Indicators Period (s) 300E-3 # Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. - SoftwareMain>Measurements Period (s) 500E-3 # The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. + (NXbias_spectroscopy): + integration time(NX_NUMBER): + unit: NX_TIME + doc: Time during which the spectroscopy data are acquired and averaged. (e.g. 150E-6) + number_of_sweeps(NX_NUMBER): + doc: Number of sweeps to measure and average. (e.g. 100) + sweep_start(NX_NUMBER): + unit: NX_VOLTAGE + doc: The first bias values of the sweep. (e.g. -300E-3) + sweep_end(NX_NUMBER): + unit: NX_VOLTAGE + doc: The last bias values of the sweep. (e.g. 300E-3) + num_pixel(NX_NUMBER): + doc: Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. (e.g. 4096) + z_avg_time(NX_NUMBER): + unit: NX_TIME + doc: Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). (e.g. 100E-3) + (NXcircuit): + rt_frequency(NX_NUMBER): + unit: NX_FREQENCY + doc: The bandwitdh of the Hardware and/or Software (e.g. 20E+3) + signals_oversampling(NX_NUMBER): + doc: (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. (e.g. 10) + acquisition_period(NX_NUMBER): + unit: NX_TIME + doc: Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. (e.g. 20E-3) + animations_period(NX_NUMBER): + unit: NX_TIME + doc: Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. (e.g. 20E-3) + indicators_period(NX_NUMBER): + unit: NX_TIME + doc: Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. (e.g. 300E-3) + measurements_period (NX_NUMBER): + unit: NX_TIME + doc: The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. (e.g. 500E-3) Scan control # parameters how to change the location from measurement to measurement during the scan - frame(NXtransformation) # also clarify the frame for the ROI of the scan (should depend on the lab frame) - Scan>Scanfield 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0 # Configure the scan frame: x position; y position; width; height. - Scan>channels Current (A);Bias (V);Z (m);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A) # The scan channels are selected by users. - Scan>pixels/line 512 # Scan resolution by setting the Lines equal to Pixels. - Scan>lines 512 # Define the image resolution. - Scan>speed forw. (m/s) 11.7187E-9 # Define the scan forward speed in the forward direction. - Scan>speed backw. (m/s) 11.7187E-9 # Define the scan backward speed in the forward direction. + (NXtransformation): + frame: + doc: Also clarify the frame for the ROI of the scan (should depend on the lab frame) + (NXcircuit): + channels_current: + doc: The scan channels are selected by users. (e.g. (A);Bias (V);Z (m);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A)) + (NXpositioner): + scanfield(NX_NUMBER): + doc: Configure the scan frame like x position; y position; width; height. (e.g. 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0) + pixels/line(NX_NUMBER): + doc: Scan resolution by setting the Lines equal to Pixels. (e.g. 512) + lines(NX_NUMBER): + doc: Define the image resolution. (e.g. 512) + speed_forw.(NX_NUMBER): + doc: Define the scan forward speed in the forward direction. (m/s) (e.g. 11.7187E-9) + speed_backw.(NX_NUMBER): + doc: Define the scan backward speed in the forward direction. (m/s) (e.g. 11.7187E-9) - SW Filter (PROCESS) - type Butterworth # Select a filter to smooth the displayed data. Note: When saving, if any filter selected, filtered data are saved to file along with the unfiltered data. - Order 1 # Filter order of a dynamic filter or width (in number of points) for the gaussian filter. - Cutoff frq 0.01 # Cutoff frequency for dynamic filters. - filtered_data # result of filtering if applied - HW Filter (NXlockin) # maybe the same as INSTRUMENT/lockin - Lock-in>LP Filter Cutoff D1 (Hz) 621.699E+0 # Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) value) for D1. The filter is applied to the demodulated signals (X,Y). - Lock-in>LP Filter Cutoff D2 (Hz) 621.699E+0 # Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) value) for D2. The filter is applied to the demodulated signals (X,Y). - Lock-in>LP Filter Order D1 8 # Order and cut-off frequency of the low-pass filter applied on the demodulated signals (X,Y). Reducing the bandwidth or increasing the order reduces noise on the demodulated signals, but will require longer settling and measurement times. - Lock-in>LP Filter Order D2 8 # See below. - Lock-in>HP Filter Cutoff D1 (Hz) # Sets the cut-off frequency of the high-pass filter (affects the displayed TC (s) value) for D1. The filter is applied to the demodulated signals (X,Y). - Lock-in>HP Filter Cutoff D2 (Hz) # See below - Lock-in>HP Filter Order D1 1 # Order and cut-off frequency of the high-pass filter applied on the demodulation signal of D!. This is used mainly to suppress a DC component of the demodulation signal, which would lead to a component at modulation frequency in the demodulated signals. - Lock-in>HP Filter Order D2 1 # See below - Lock-in>Sync Filter D1 ON # Switch the Sync filter on the demodulated signals (X,Y) on or off for D1. The sync filter operates after the low-pass filter and averages the demodulated signals over one period of the modulation frequency. - Lock-in>Sync Filter D2 ON # See below. + SW Filter(NXbias_spectroscopy): + type: + doc: Select a filter to smooth the displayed data. When saving, if any filter selected, filtered data are saved to file along with the unfiltered data. (e.g. Butterworth) + order: + doc: Filter order of a dynamic filter or width (in number of points) for the gaussian filter. (e.g. 1) + cutoff_frq: + doc: Cutoff frequency for dynamic filters. (e.g. 0.01) + HW Filter(NXlockin): + lp_filter_cutoff_d1(NX_NUMBER): + unit: NX_FREQUENCY + doc: Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) value) for D1. The filter is applied to the demodulated signals (X,Y). (e.g. 621.699E+0) + lp_filter_cutoff_d2(NX_NUMBER): + unit: NX_FREQUENCY + doc: Same as D1. (e.g. 621.699E+0) + lp_filter_order_d1(NX_NUMBER): + doc: Order and cut-off frequency of the low-pass filter applied on the demodulated signals (X,Y). Reducing the bandwidth or increasing the order reduces noise on the demodulated signals, but will require longer settling and measurement times. (e.g. 8) + lp_Filter_order_d2(NX_NUMBER): + doc: Same as D1. (e.g. 8) + hp_filter_cutoff_d1(NX_NUMBER): + unit: NX_FREQUENCY + doc: Sets the cut-off frequency of the high-pass filter (affects the displayed TC (s) value) for D1. The filter is applied to the demodulated signals (X,Y). (e.g. 621.699E+0) + hp_filter_cutoff_d2(NX_NUMBER): + unit: NX_FREQUENCY + doc: Same as D1. (e.g. 621.699E+0) # See below + hp_filter_order_d1(NX_NUMBER): + doc: Order and cut-off frequency of the high-pass filter applied on the demodulation signal of D!. This is used mainly to suppress a DC component of the demodulation signal, which would lead to a component at modulation frequency in the demodulated signals. (e.g. 1) + hp_filter_order_d2(NX_NUMBER): + doc: Same as D1. (e.g. 1) + sync_filter_d1(NX_BOOLEAN): + doc: Switch on/off the Sync filter on the demodulated signals (X,Y) on or off. (foreach DemodulatorChannels) (e.g. ON) + sync_filter_d2(NX_BOOLEAN): + doc: Same as D1. (e.g. ON) RESOLUTION (calculation input) - Temperature 1>link to INSTR/STM/head Temperature 1 (K) 4.92997E+0 # Temperature of STM head. + Temperature 1>link to INSTR/STM/head Temperature 1 (K) (e.g. 4.92997E+0) # Temperature of STM head. Temperature 2>link to Temperature 2 (K) - # Temperature of bottom of LHe helium cryostat. Temperature 3>link to Temperature 3 (K) - # Temperature of LN2 nitrogen shield. - Lock-in>link to Modulated signal Bias (V) 1E-3 # Applied modulation to the bias voltage. - link to Integration time (s) 150E-6 # Time during which the spectroscopy data are acquired and averaged. - link to Bias Spectroscopy>Number of sweeps 100 # Number of sweeps to measure and average. - link to Bias Spectroscopy>Sweep Start (V) -300E-3 # The first bias values of the sweep. - link to Bias Spectroscopy>Sweep End (V) 300E-3 # The last bias values of the sweep. - link to Bias Spectroscopy>Num Pixel 4096 # Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. - link to Bias Spectroscopy>Z Avg time (s) 100E-3 # Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). - link to SoftwareMain>RT Frequency (Hz) 20E+3 # The bandwitdh of the Hardware and/or Software - link to SoftwareMain>Signals Oversampling 10 # (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. - link to SoftwareMain>Acquisition Period (s) 20E-3 # Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. - link to SoftwareMain>Animations Period (s) 20E-3 # Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. - link to SoftwareMain>Indicators Period (s) 300E-3 # Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. - link to SoftwareMain>Measurements Period (s) 500E-3 # The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. + Lock-in>link to Modulated signal Bias (V) (e.g. 1E-3) # Applied modulation to the bias voltage. + link to Integration time (s) (e.g. 150E-6) # Time during which the spectroscopy data are acquired and averaged. + link to Bias Spectroscopy>Number of sweeps (e.g. 100) # Number of sweeps to measure and average. + link to Bias Spectroscopy>Sweep Start (V) (e.g. -300E-3) # The first bias values of the sweep. + link to Bias Spectroscopy>Sweep End (V) (e.g. 300E-3) # The last bias values of the sweep. + link to Bias Spectroscopy>Num Pixel (e.g. 4096) # Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. + link to Bias Spectroscopy>Z Avg time (s) (e.g. 100E-3) # Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). + link to SoftwareMain>RT Frequency (Hz) (e.g. 20E+3) # The bandwitdh of the Hardware and/or Software + link to SoftwareMain>Signals Oversampling (e.g. 10) # (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. + link to SoftwareMain>Acquisition Period (s) (e.g. 20E-3) # Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. + link to SoftwareMain>Animations Period (s) (e.g. 20E-3) # Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. + link to SoftwareMain>Indicators Period (s) (e.g. 300E-3) # Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. + link to SoftwareMain>Measurements Period (s) (e.g. 500E-3) # The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. REPRODUCIBILITY link to - Bias>Bias (V) 100E-3 # Applied bias voltage. - Current>Current (A) -5.3429E-15 # The tunneling current is displayed here. - Bias>Calibration (V/V) 1E+0 # Calibration of the Bias output. If you have a Range switch the calibration is stored per range setting. - Bias>Offset (V) 0E+0 # Allows compensating for an offset in Bias. - Current>Calibration (A/V) 100E-12 # The signals voltages are converted to real world physical values according to the calibration & offset parameters: Physical signal = (Voltage * calibration) + offset. - Current>Offset (A) 16.2897E-15 # The same as "Current>Calibration (A/V)" tag - Current>Gain Not switchable # None - Z offset (m) 0E+0 # Offset added to the initial averaged position Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an alternate Z-controller setpoint is enabled. - Settling time (s) 2.1E-3 # Time to wait after changing the bias to the next level and before starting to acquire data. Adjust this parameter to avoid transient effect induced by the bias change. Integration time: time during which the data are acquired and averaged. - Z-Ctrl hold TRUE # When selected, the Z-Controller is set to hold during the pulse. This means that the controller doesn't control the Z position during the pulse. - Final Z (m) N/A - Start time 23.11.2022 18:55:16 # Timestamp of the moment when the acquisition starts by pressing the Start button. - Bias Spectroscopy>Z offset (m) 0E+0 # Offset added to the initial averaged position Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an alternate Z-controller setpoint is enabled. - Bias Spectroscopy>1st Settling time (s) 2.1E-3 # See the "Settling time (s)" below. - Bias Spectroscopy>Settling time (s) 2.1E-3 # See the "Settling time (s)" below. - Bias Spectroscopy>Integration time (s) 150E-6 # Time during which the data are acquired and averaged. - Bias Spectroscopy>End Settling time (s) 4E-3 # Time to wait after the sweep has finished and the bias is ramped to the initial value. - Bias Spectroscopy>Z control time (s) 200E-3 # Time during which the Z-Controller is enabled once a sweep has finished. When averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled for this duration between each sweep. After the last sweep, it will wait the specified time before continuing a running scan. This ensures each sweep reliably starts from the same position. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. - Bias Spectroscopy>Max Slew rate (V/s) 1E+0 # Maximum rate at which the bias changes (before, during and after sweeping). - Bias Spectroscopy>backward sweep TRUE # Select whether to measure the backward (return) sweep or the forward only. - Bias Spectroscopy>Z-controller hold TRUE # Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. - Z-Controller>Controller name log Current # Controller name. This name which will be displayed at places where you can select a controller. - Z-Controller>Controller status OFF # ON/OFF - Z-Controller>Setpoint 50E-12 # Set Point is the desired value of the control signal. It can be set by editing the number or using the slider bar. Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. - Z-Controller>Setpoint unit A # Angstrom - Z-Controller>P gain 6E-12 # The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. - Z-Controller>I gain 39.8241E-9 # See "Z-Controller>P gain" below. - Z-Controller>Time const (s) 150.662E-6 # See "Z-Controller>P gain" below. - Z-Controller>TipLift (m) 0E+0 # Lifts the tip by the specified amount when then controller is switched off. This can be a positive or a negative number, i.e. the tip can also be moved towards the sample. Be careful with sign and value when using this feature. - Z-Controller>Switch off delay (s) 0E+0 # Use this parameter for a reproducible position when switching off the Z-controller. When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. + Bias>Bias(NXBias) (V) (e.g. 100E-3) # Applied bias voltage. + Current>Current(NXcircuit) (A) (e.g. -5.3429E-15) # The tunneling current is displayed here. + Bias>Calibration(NXbias) (V/V) (e.g. 1E+0) # Calibration of the Bias output. If you have a Range switch the calibration is stored per range setting. + Bias>Offset(NXbias) (V) (e.g. 0E+0) # Allows compensating for an offset in Bias. + Current>Calibration(NXcircuit) (A/V) (e.g. 100E-12) # The signals voltages are converted to real world physical values according to the calibration & offset parameters: Physical signal = (Voltage * calibration) + offset. + Current>Offset(NXcircuit) (A) (e.g. 16.2897E-15) # The same as "Current>Calibration (A/V)" tag + Current>Gain(NXcircuit) (e.g. Not switchable) # None + Z offset(NXpositioner) (m) (e.g. 0E+0) # Offset added to the initial averaged position Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an alternate Z-controller setpoint is enabled. + Settling time(NXbias) (s) (e.g. 2.1E-3) # Time to wait after changing the bias to the next level and before starting to acquire data. Adjust this parameter to avoid transient effect induced by the bias change. Integration time: time during which the data are acquired and averaged. + Z-Ctrl hold(NXpositioner) (e.g. TRUE) # When selected, the Z-Controller is set to hold during the pulse. This means that the controller doesn't control the Z position during the pulse. + Final Z(NXpositioner) (m) (e.g. N/A) + Start time(NXlog) (e.g.23.11.2022 18:55:16) # Timestamp of the moment when the acquisition starts by pressing the Start button. + Bias Spectroscopy>Z offset(NXbias) (m) (e.g.0E+0) # Offset added to the initial averaged position Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an alternate Z-controller setpoint is enabled. + Bias Spectroscopy>1st Settling time(NXbias) (s) (e.g.2.1E-3) # See the "Settling time (s)" below. + Bias Spectroscopy>Settling time(NXbias) (s) (e.g.2.1E-3) # See the "Settling time (s)" below. + Bias Spectroscopy>Integration time(NXbias) (s) (e.g.150E-6) # Time during which the data are acquired and averaged. + Bias Spectroscopy>End Settling time(NXbias) (s) (e.g.4E-3) # Time to wait after the sweep has finished and the bias is ramped to the initial value. + Bias Spectroscopy>Z control time(NXbias) (s) (e.g.200E-3) # Time during which the Z-Controller is enabled once a sweep has finished. When averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled for this duration between each sweep. After the last sweep, it will wait the specified time before continuing a running scan. This ensures each sweep reliably starts from the same position. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. + Bias Spectroscopy>Max Slew rate(NXbias) (V/s) (e.g.1E+0) # Maximum rate at which the bias changes (before, during and after sweeping). + Bias Spectroscopy>backward sweep(NXbias) (e.g.TRUE) # Select whether to measure the backward (return) sweep or the forward only. + Bias Spectroscopy>Z-controller hold(NXbias) (e.g.TRUE # Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. + Z-Controller>Controller name(NXpositioner) (e.g.log Current) # Controller name. This name which will be displayed at places where you can select a controller. + Z-Controller>Controller status(NXpositioner) (e.g.OFF) # ON/OFF + Z-Controller>Setpoint(NXpositioner) (e.g.50E-12) # Set Point is the desired value of the control signal. It can be set by editing the number or using the slider bar. Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. + Z-Controller>Setpoint unit(NXpositioner) (e.g.A) # Angstrom + Z-Controller>P gain(NXpositioner) (e.g.6E-12) # The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. + Z-Controller>I gain(NXpositioner) (e.g.39.8241E-9) # See "Z-Controller>P gain" below. + Z-Controller>Time const(NXpositioner) (s) (e.g.150.662E-6) # See "Z-Controller>P gain" below. + Z-Controller>TipLift(NXpositioner) (m) (e.g.0E+0) # Lifts the tip by the specified amount when then controller is switched off. This can be a positive or a negative number, i.e. the tip can also be moved towards the sample. Be careful with sign and value when using this feature. + Z-Controller>Switch off delay(NXpositioner) (s) (e.g.0E+0) # Use this parameter for a reproducible position when switching off the Z-controller. When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. DATA # multi dimensional array: multi I-V array per scan point; + doc: The format of the data here is similar to a column matrix. Bias calc (V) #scanning parameter Current (A) # current during forward direction scanning of bias - original NXsensor LI Demod 2 X (A) lockin (NXsensor+lockin) From 1d883f3ec964ae120adc6ad46a32817f9040a15e Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Wed, 17 May 2023 16:28:43 +0200 Subject: [PATCH 0134/1012] clean up on an expert meeting --- .../nyaml/NXamplifier.nxdl.xml | 103 ------- .../nyaml/NXamplifier.yaml | 20 +- contributed_definitions/nyaml/NXbias.nxdl.xml | 170 ----------- .../nyaml/NXcircuit.nxdl.xml | 104 ------- .../nyaml/{NXbias.yaml => NXiv_bias.yaml} | 2 +- .../nyaml/NXiv_sweep2.yaml | 108 +++---- .../nyaml/NXiv_temp.nxdl.xml | 84 ------ .../nyaml/NXlockin.nxdl.xml | 103 ------- contributed_definitions/nyaml/NXlockin.yaml | 18 +- .../nyaml/NXpositioner.nxdl.xml | 282 ------------------ .../nyaml/NXsensor.nxdl.xml | 232 -------------- 11 files changed, 60 insertions(+), 1166 deletions(-) delete mode 100644 contributed_definitions/nyaml/NXamplifier.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXbias.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXcircuit.nxdl.xml rename contributed_definitions/nyaml/{NXbias.yaml => NXiv_bias.yaml} (99%) delete mode 100644 contributed_definitions/nyaml/NXiv_temp.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXlockin.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXpositioner.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXsensor.nxdl.xml diff --git a/contributed_definitions/nyaml/NXamplifier.nxdl.xml b/contributed_definitions/nyaml/NXamplifier.nxdl.xml deleted file mode 100644 index 9b51e4e833..0000000000 --- a/contributed_definitions/nyaml/NXamplifier.nxdl.xml +++ /dev/null @@ -1,103 +0,0 @@ - - - - - - Application definition for amplifier devices. - - - - (IC, device) (NXmanufacturer?) - - - - - The number of preamplifier channels are assgined. - - - - - The number of preamplifier channels are ready tp to be used. (array for active - channels) - - - - - The output signal does not go through a feedback loop to adjust the - amplification of the amplifier. (array for active channels) - - - - - The ratio of the amplitude of the output signal to the amplitude of the input - signal. (array for active channels) - - - - - The ratio of the amplitue of the useful signal to the amplitude of the noise in - the output signal of the amplifier. S/N=V_signal/V_noise. (array for active - channels) - - - - - (if active >1) - - - - - - The spectrum of frequency it can amplify, from its lowest to highest frequency - limits. - - - - - Order and cut-off frequency of the low-pass filter applied on the demodulated - signals (X,Y). Cut-off frq (low pass filter) (foreach DemodulatorChannels) - - - - - Order and cut-off frequency of the high-pass filter applied on the demodulation - signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) - - - - - - - - - - - (V/V) - - - - - - - - diff --git a/contributed_definitions/nyaml/NXamplifier.yaml b/contributed_definitions/nyaml/NXamplifier.yaml index 4fef3f80ba..19ed013ade 100644 --- a/contributed_definitions/nyaml/NXamplifier.yaml +++ b/contributed_definitions/nyaml/NXamplifier.yaml @@ -1,17 +1,17 @@ -doc: | +doc: | Base classed definition for amplifier devices. category: base NXamplifier: hardware(NXfabrication): doc: (IC, device) (NXmanufacturer?) - NumOfChannels(NX_NUMBER): + num_of_channels(NX_NUMBER): doc: The number of preamplifier channels are assgined. - ActiveChannels(NX_NUMBER): + active_channels(NX_NUMBER): doc: The number of preamplifier channels are ready tp to be used. (array for active channels) openloop_amplification(NX_NUMBER): doc: The output signal does not go through a feedback loop to adjust the amplification of the amplifier. (array for active channels) # From google. amplification(NX_NUMBER): - doc: The ratio of the amplitude of the output signal to the amplitude of the input signal. (array for active channels) # From google. + doc: !!! The ratio of the amplitude of the output signal to the amplitude of the input signal. (array for active channels) # From google. signal_over_noise(NX_NUMBER): doc: The ratio of the amplitue of the useful signal to the amplitude of the noise in the output signal of the amplifier. S/N=V_signal/V_noise. (array for active channels) crosstalk_factor(NX_NUMBER): @@ -21,13 +21,13 @@ NXamplifier: bandwidth(NX_NUMBER): doc: The spectrum of frequency it can amplify, from its lowest to highest frequency limits. unit: NX_FREQUENCY - LowPass(NX_NUMBER): + low_pass(NX_NUMBER): doc: Order and cut-off frequency of the low-pass filter applied on the demodulated signals (X,Y). Cut-off frq (low pass filter) (foreach DemodulatorChannels) unit: NX_FREQUENCY - HiPass(NX_NUMBER): + hi_pass(NX_NUMBER): doc: Order and cut-off frequency of the high-pass filter applied on the demodulation signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) unit: NX_FREQUENCY - Current amplifier factor(NX_NUMBER): - doc: Current Amplifier Factor typically refers to the gain of the probe current amplifier. (V/V) - Current amplifier Capacitive cross-talk compensation(NX_CHAR): - doc: Reduces the effect of capacitive crosstalk in the circuit on experimental results. + voltage_amplifier_factor(NX_NUMBER): + doc: !!! Current Amplifier Factor typically refers to the gain of the probe current amplifier. (V/V) + current_amplifier_capacitive_cross_talk_compensation(NX_CHAR): + doc: !!! Reduces the effect of capacitive crosstalk in the circuit on experimental results. diff --git a/contributed_definitions/nyaml/NXbias.nxdl.xml b/contributed_definitions/nyaml/NXbias.nxdl.xml deleted file mode 100644 index 49d2b17754..0000000000 --- a/contributed_definitions/nyaml/NXbias.nxdl.xml +++ /dev/null @@ -1,170 +0,0 @@ - - - - - - Application definition for bias devices. - - - - Applied a voltage between tip and sample. - - - - - The ratio between the tunneling current at the sample surface and the bias - voltage applied between between the sample and the tip. - - - - - Calibration of the Bias output (V/V). - - - - - Allows compensating for an offset in Bias. Hardware parameter offset. - - - - - Sets the amplitude (in physical units of the modulated signal) of the sine - modulation. - - - - - Bias sweeps while measuring arbitrary channels with I(V) curves. - - - - Select the channels to record. - - - - - When selected, the Bias voltage returns to the initial value (before starting the sweep) at the end of the spectroscopy measurement (default). When not selected, Bias remains at the last value of the sweep. This is useful e.g. when combining several sweep segments. Example for an automated measurement (using Programming Interface): switch off Z-Controller, start spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, switch on Z-Controller. - - - - - Select whether to record the Z position during Z averaging time at the end of - the sweep (after Z control time) and store the average value in the header of - the file when saving. Using this option increases the sweep time by Z averaging - time. - - - - - Select whether to set the Lock-In to run during the measurement. When using this - feature, make sure the Lock-In is configured correctly and settling times are - set to twice the Lock-In period at least. This option is ignored when Lock-In is - already running. This option is disabled if the Sweep Mode is MLS and the flag - to configure the Lock-In per segment in the Multiline segment editor is set. - - - - - Number of sweeps to measure and average. - - - - - The first bias values of the sweep. - - - - - The last bias values of the sweep. - - - - - Define the sweep number of points, that is, the maximum spectrum resolution eq. - Bias window divide by Num Pixel. - - - - - Duration over which the Z position is recorded and averaged before and after the - sweep (the latter only if Record final Z position is selected in the Advanced - section). After the initial Z averaging time, if Z-Controller to Hold is - selected in the Advanced section, the Z-Controller is set to hold and the tip is - placed at the previously averaged Z position (plus Z offset). - - - - - Offset added to the initial averaged position Zaver before starting to sweep. - This parameter is disabled when Z-Controller to Hold is deselected in the - Advanced section. The LED “Alt” next to the Z offset indicates if an alternate - Z-controller setpoint is enabled. - - - - - time to wait after changing the bias to the next level and before starting to - acquire data. - - - - - Time during which the data are acquired and averaged. - - - - - Time to wait after the sweep has finished and the bias is ramped to the initial - value. - - - - - Time during which the Z-Controller is enabled once a sweep has finished. When - averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled for this - duration between each sweep. After the last sweep, it will wait the specified - time before continuing a running scan. This ensures each sweep reliably starts - from the same position. This parameter is disabled when Z-Controller to Hold is - deselected in the Advanced section. - - - - - Maximum rate at which the bias changes (before, during and after sweeping). - (V/s) - - - - - Select whether to measure the backward (return) sweep or the forward only. - - - - - Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. - It is selected by default. When deselected, Z-offset and Z control time - parameters are disabled. - - - - diff --git a/contributed_definitions/nyaml/NXcircuit.nxdl.xml b/contributed_definitions/nyaml/NXcircuit.nxdl.xml deleted file mode 100644 index dd26578b87..0000000000 --- a/contributed_definitions/nyaml/NXcircuit.nxdl.xml +++ /dev/null @@ -1,104 +0,0 @@ - - - - - - Application definition for circuit devices. - - - - (NXmanufacturer?) - - - - - The tunneling current between tip and sample after application of bias voltage. - - - - - Calibration of the current measurement (A/V). - - - - - Offset of the current measurement. - - - - - The scan channels are selected by users (in scan contronaller). - - - - - The bandwitdh of the Hardware and/or Software - - - - - (Signals Periods) The Signals Period is the rate at which the signals are - transferred to the host computer running the control software. This is usually - lower by a factor of 10 than the sampling rate, because an internal oversampling - of the signal is done on the real time engine. You can reduce the oversampling - down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. - - - - - Update rate for several processes like History Graph, Auto-Approach, and for - many Programming Interface functions. This is usually set to 20 ms. All - additional timings (7-9) can only be integer multiples of this value. They can - be set to different values, but the actual timing value will be coerced to a - multiple of the Acquisition Period. - - - - - Update rate of animated graphical indicators. These are e.g. some graphs & - sliders. A reasonable value is 40 ms (25 updates per second). Increase this - period to reduce the processor load for the graphical user interface, especially - on slow computers. This value is purely a user interface update rate and does - not affect measurements in any way. - - - - - Update rate of digital indicators, e.g. the numbers displayed besides each - slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a - user interface update rate and does not affect measurements in any way. - - - - - The Measurements period is the integration time for precise measurements - (averaging over specified period), mostly used in sweep modules. Examples are - recording of a force-distance curve or a resonance of a cantilever. For fast - measurements with small steps, a value of 40 ms may be reasonable. For normal - use, 300-500 ms is a good value, but for recording a resonance of a high-Q - cantilever, values of several seconds might be necessary. Usually this parameter - doesn’t need to be set from this module; the sweep modules will set this value - according to the sweep timings. - - - diff --git a/contributed_definitions/nyaml/NXbias.yaml b/contributed_definitions/nyaml/NXiv_bias.yaml similarity index 99% rename from contributed_definitions/nyaml/NXbias.yaml rename to contributed_definitions/nyaml/NXiv_bias.yaml index dd84894338..5df3566eb4 100644 --- a/contributed_definitions/nyaml/NXbias.yaml +++ b/contributed_definitions/nyaml/NXiv_bias.yaml @@ -1,7 +1,7 @@ doc: | Application definition for bias devices. category: base -NXbias(NXobject): +NXiv_bias(NXobject): bias(NX_NUMBER): doc: Applied a voltage between tip and sample. unit: NX_VOLTAGE diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index ec2bdaf8b0..d8d65659d9 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -22,23 +22,25 @@ NXiv_sweep2(NXsensor_scan): definition: enumeration: [NXiv_sweep2] type: + doc: !!! enumeration: [background, reference, sample] - experiment_identifier: + entry_identifier: doc: The name of the output file, with the number of scans at the end.e.g. (e.g. 221122_Au_5K00014) collection_dentifier: doc: The name of the series output file, which represents only the public part of the output file. (e.g. 221122_Au_5K） - entry_identifier: + experiment_identifier: doc: Path to storage of output files. (e.g. Path C:\Users\SPM-PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis-Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711) experiment_description: doc: Descriptive comments for this experiment, added by the experimenter, coming from the output file. (e.g. Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, locked Au(111), 50pA, 100 mV set point, 1mV DCA, 973Hz,138 1st H, -84 2nd H) (NXinstrument): - (NXfabrication): # any or specifique 'harware' and 'software'? - doc: | - Software and hardware for control, scanning and data collection in the SPM system - hardware: - doc: Hardware type used in SPM experiment, includes hardware manufacturers and type. (e.g. Nanonis BP5e) - softwareMain>Software: - doc: Type of software used in SPM experiments, e.g. software version serial number, UI and RT probe release method. (e.g. SW Version Generic 5e -- SoftwareMain>UI Release 10771 -- SoftwareMain>RT Release 10771) + hardware(NXfabrication): + software(NXfabrication): # any or specifique 'harware' and 'software'? + # doc: | + # Software and hardware for control, scanning and data collection in the SPM system + # hardware: + # doc: Hardware type used in SPM experiment, includes hardware manufacturers and type. (e.g. Nanonis BP5e) + # softwareMain>Software: + # doc: Type of software used in SPM experiments, e.g. software version serial number, UI and RT probe release method. (e.g. SW Version Generic 5e -- SoftwareMain>UI Release 10771 -- SoftwareMain>RT Release 10771) current_amplifier(NXamplifier): # hardware: Current amplifier> hardware: CreaTec GmbH # amplification: Current amplifier> factor (V/V): 1E-10 @@ -46,11 +48,9 @@ NXiv_sweep2(NXsensor_scan): lock_in(NXlockin): exists: optional # status: Lock-in>Lock-in status ON # ON/OFF of Lock-in amplifier - amplifier_status: - doc: Lock-in Amplifier>Yes/No # If a lock-in amplifier employed to filter or obtain the electronic derivatives dI/dV of the signal + # amplifier_status: -> amplifier/active_channels + # doc: Lock-in Amplifier>Yes/No # If a lock-in amplifier employed to filter or obtain the electronic derivatives dI/dV of the signal # hardware: Lock-in Amplifier>Hardware: Nanonis - bias_divider: - doc: if Lock-in -- Bias Divider 1/10 or 1/100 # if the modulation # modulate_signal: Lock-in>Modulated signal Bias (V) # This is the signal on which the modulation (sine) will be added. # frequency: Lock-in>Frequency (Hz) 973E+0 # Sets the frequency of the sine modulation added to the signal to modulate. The frequency range is from 10 mHz to 40 kHz (corresponding to the SC5 output filter cut-off). When working with harmonics, make sure the harmonic frequencies don’t exceed ~100 kHz (SC5 input filter cut-off). Remember the SC5 hardware filters will affect the amplitude when getting close to their cut-off frequencies. # amplitude: Lock-in>Amplitude 2E-3 # Sets the amplitude (in physical units of the modulated signal) of the sine modulation. @@ -70,14 +70,14 @@ NXiv_sweep2(NXsensor_scan): # doc: Select whether to record the Z position during Z averaging time at the end of the sweep (after Z control time) and store the average value in the header of the file when saving. Using this option increases the sweep time by Z averaging time. (e.g. FALSE) #run: # doc: Bias Spectroscopy>Lock-In run FALSE # Select whether to set the Lock-In to run during the measurement. When using this feature, make sure the Lock-In is configured correctly and settling times are set to twice the Lock-In period at least. This option is ignored when Lock-In is already running. This option is disabled if the Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline segment editor is set. - tip_bias(NXbias): - sample_bias(NXbias): + sample_bias(NXiv_bias): + #sample_bias(NXbias): # Tip bias/Sample bias # If the spectroscopy V bias is applied to the # Modulated signal Bias (V) 1E-3 # Applied modulation to the bias voltage. # ModulationBias> Tip bias/Sample bias - modulated_signal_bias(NX_NUMBER): - unit: NX_VOLTAGE - doc: Same directional representation as bias. (e.g. 1E-3) + # modulated_signal_bias(NX_NUMBER): + # unit: NX_VOLTAGE + # doc: Same directional representation as bias. (e.g. 1E-3) stm_head_temperature(NX_NUMBER): unit: NX_TEMPERATURE doc: | @@ -90,14 +90,14 @@ NXiv_sweep2(NXsensor_scan): doc: Temperature of LN2 nitrogen shield. Temperature 3 (K) (e.g 78.00000E+0) output_cabling(NXcircuit): # Cabling & Config - output_mode: - doc: Number of output channels. (e.g. User Output) - output_value(NX_NUMBER): - doc: The user output in each monitor mode. (e.g. 0E+0) - output_name: - doc: User outputs whose name can be modified in the corresponding module. (e.g. Input 24 (V)) - output_slew_rate(NX_NUMBER): - doc: The rate at which the one of the signal changes when ramping to the starting point. (V/s) (e.g. Inf) + #output_mode: + # doc: Number of output channels. (e.g. User Output) + #output_value(NX_NUMBER): + # doc: The user output in each monitor mode. (e.g. 0E+0) + #output_name: + # doc: User outputs whose name can be modified in the corresponding module. (e.g. Input 24 (V)) + #output_slew_rate(NX_NUMBER): + # doc: The rate at which the one of the signal changes when ramping to the starting point. (V/s) (e.g. Inf) (NXenvironment): doc: | Describes an environment setup for a temperature-dependent IV measurement experiment. @@ -117,14 +117,14 @@ NXiv_sweep2(NXsensor_scan): INSTRUMENT - Piezo Config + piezo_config(NXcollection): active_calib.: doc: The name of caliberation type. (e.g. LHe) calib._N(NX_NUMBER): doc: N denotes X or Y or Z. There are 3 parameters in X, Y, and Z directions and there are 3 controls available: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. (e.g. 3.8E-9) - hv_gain_N(NX_NUMBER): - doc: N denotes X or Y or Z. For some systems HV gain readout is available, so for those systems the HV gain should be adjusted automatically when the gain is changed at the high voltage amplifier. (e.g. 14.5) - tilt_N(NX_NUMBER): (e.g. 0.318343) + hv_gain_N(NX_NUMBER): + doc: N denotes X or Y or Z. For some systems HV gain readout is available, so for those systems the HV gain should be adjusted automatically when the gain is changed at the high voltage amplifier. (e.g. 14.5) + tilt_N(NX_NUMBER): (e.g. 0.318343) unit: NX_ANGLE doc: N denotes X or Y. There are 2 parameters in X and Y directions and this tab is used to set the sample tilt (in degrees, first order correction). curvature radius N(NX_NUMBER): Inf @@ -132,10 +132,10 @@ NXiv_sweep2(NXsensor_scan): doc: N denotes X or Y. There are 2 parameters in X and Y directions and this tab is used to set a curvature (can be set approximately to the length of the piezotube). 2nd_order_corr N(NX_NUMBER): doc: N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2). (e.g. 0E+0) - drift_N(NX_NUMBER): - doc: N denotes X or Y. There are 2 parameters in X and Y directions. Define the drift speed for all three axes. When the compensation is on, the piezos will start to move at that speed. (e.g. 0E+0) - drift_correction_status(NX_BOOLEAN): - doc: Use the button to turn on/off the drift compensation. (e.g. FALSE) + drift_N(NX_NUMBER): + doc: N denotes X or Y. There are 2 parameters in X and Y directions. Define the drift speed for all three axes. When the compensation is on, the piezos will start to move at that speed. (e.g. 0E+0) + drift_correction_status(NX_BOOLEAN): + doc: Use the button to turn on/off the drift compensation. (e.g. FALSE) MEASUREMENT Position(NXpositioner): @@ -181,20 +181,20 @@ NXiv_sweep2(NXsensor_scan): doc: Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. (e.g. 20E-3) animations_period(NX_NUMBER): unit: NX_TIME - doc: Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. (e.g. 20E-3) + doc: Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. (e.g. 20E-3) indicators_period(NX_NUMBER): unit: NX_TIME - doc: Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. (e.g. 300E-3) + doc: Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. (e.g. 300E-3) measurements_period (NX_NUMBER): unit: NX_TIME - doc: The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. (e.g. 500E-3) + doc: The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. (e.g. 500E-3) Scan control # parameters how to change the location from measurement to measurement during the scan (NXtransformation): frame: doc: Also clarify the frame for the ROI of the scan (should depend on the lab frame) (NXcircuit): channels_current: - doc: The scan channels are selected by users. (e.g. (A);Bias (V);Z (m);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A)) + doc: The scan channels are selected by users. (e.g. (A);Bias (V);Z (m);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A)) (NXpositioner): scanfield(NX_NUMBER): doc: Configure the scan frame like x position; y position; width; height. (e.g. 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0) @@ -207,38 +207,6 @@ NXiv_sweep2(NXsensor_scan): speed_backw.(NX_NUMBER): doc: Define the scan backward speed in the forward direction. (m/s) (e.g. 11.7187E-9) - SW Filter(NXbias_spectroscopy): - type: - doc: Select a filter to smooth the displayed data. When saving, if any filter selected, filtered data are saved to file along with the unfiltered data. (e.g. Butterworth) - order: - doc: Filter order of a dynamic filter or width (in number of points) for the gaussian filter. (e.g. 1) - cutoff_frq: - doc: Cutoff frequency for dynamic filters. (e.g. 0.01) - HW Filter(NXlockin): - lp_filter_cutoff_d1(NX_NUMBER): - unit: NX_FREQUENCY - doc: Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) value) for D1. The filter is applied to the demodulated signals (X,Y). (e.g. 621.699E+0) - lp_filter_cutoff_d2(NX_NUMBER): - unit: NX_FREQUENCY - doc: Same as D1. (e.g. 621.699E+0) - lp_filter_order_d1(NX_NUMBER): - doc: Order and cut-off frequency of the low-pass filter applied on the demodulated signals (X,Y). Reducing the bandwidth or increasing the order reduces noise on the demodulated signals, but will require longer settling and measurement times. (e.g. 8) - lp_Filter_order_d2(NX_NUMBER): - doc: Same as D1. (e.g. 8) - hp_filter_cutoff_d1(NX_NUMBER): - unit: NX_FREQUENCY - doc: Sets the cut-off frequency of the high-pass filter (affects the displayed TC (s) value) for D1. The filter is applied to the demodulated signals (X,Y). (e.g. 621.699E+0) - hp_filter_cutoff_d2(NX_NUMBER): - unit: NX_FREQUENCY - doc: Same as D1. (e.g. 621.699E+0) # See below - hp_filter_order_d1(NX_NUMBER): - doc: Order and cut-off frequency of the high-pass filter applied on the demodulation signal of D!. This is used mainly to suppress a DC component of the demodulation signal, which would lead to a component at modulation frequency in the demodulated signals. (e.g. 1) - hp_filter_order_d2(NX_NUMBER): - doc: Same as D1. (e.g. 1) - sync_filter_d1(NX_BOOLEAN): - doc: Switch on/off the Sync filter on the demodulated signals (X,Y) on or off. (foreach DemodulatorChannels) (e.g. ON) - sync_filter_d2(NX_BOOLEAN): - doc: Same as D1. (e.g. ON) RESOLUTION (calculation input) Temperature 1>link to INSTR/STM/head Temperature 1 (K) (e.g. 4.92997E+0) # Temperature of STM head. Temperature 2>link to Temperature 2 (K) - # Temperature of bottom of LHe helium cryostat. diff --git a/contributed_definitions/nyaml/NXiv_temp.nxdl.xml b/contributed_definitions/nyaml/NXiv_temp.nxdl.xml deleted file mode 100644 index 876db0de5e..0000000000 --- a/contributed_definitions/nyaml/NXiv_temp.nxdl.xml +++ /dev/null @@ -1,84 +0,0 @@ - - - - - - - - Number of different temperature setpoints used in the experiment. - - - - - Number of different voltage setpoints used in the experiment. - - - - - Application definition for temperature-dependent IV curve measurements. - - In this application definition, times should be specified always together - with an UTC offset. - - This is the application definition describing temperature dependent IV curve - measurements. For this a temperature is set. After reaching the temperature, - a voltage sweep is performed. For each voltage a current is measured. - Then, the next desired temperature is set and an IV measurement is performed. - - - - - - - - - - - Describes an environment setup for a temperature-dependent IV measurement experiment. - - The temperature and voltage must be present as independently scanned controllers and - the current sensor must also be present with its readings. - - - - - - - - - This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. - There should also be two more fields called temperature and voltage containing the setpoint values. - There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension - equal to the number of voltage setpoints. - - - - - - - - - - - - diff --git a/contributed_definitions/nyaml/NXlockin.nxdl.xml b/contributed_definitions/nyaml/NXlockin.nxdl.xml deleted file mode 100644 index 44aeb401ad..0000000000 --- a/contributed_definitions/nyaml/NXlockin.nxdl.xml +++ /dev/null @@ -1,103 +0,0 @@ - - - - - - Application definition for lock in devices. - - - - - input and output amplifiers - - - - - This is the signal on which the modulation (sine) will be added, such as - current, bias, et.al. - - - - - Sets the amplitude (in physical units of the modulated signal) of the sine - modulation. - - - - - Sets the frequency of the sine modulation added to the signal to modulate. - - - - - This is the signal which will be demodulated, in order to determine the - amplitude and phase at the frequency set in the Frequency field or harmonics, - such as current, bias, et.al. - - - - - The number of signals which will be demodulated. - - - - - Order and cut-off frequency of the low-pass filter applied on the demodulated - signals (X,Y). Cut-off frq (low pass filter) (foreach DemodulatorChannels) - - - - - Order and cut-off frequency of the high-pass filter applied on the demodulation - signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) - - - - - Switch the Sync filter on the demodulated signals (X,Y) on or off. (foreach - DemodulatorChannels) - - - - - Reference phase for the sine on the demodulated signal with respect to the - modulation signal. (foreach DemodulatorChannels) - - - - - Time during which the data are acquired and averaged. (for the input filter) - - - - - The order of the harmonic oscillation to detect on the demodulated signals. - (with respect to the modulation frequency) - - - - - Ratio of output signal amplitude to input signal amplitue (V/V). (input gain) - - - diff --git a/contributed_definitions/nyaml/NXlockin.yaml b/contributed_definitions/nyaml/NXlockin.yaml index 00e1efedf0..759c1c47f6 100644 --- a/contributed_definitions/nyaml/NXlockin.yaml +++ b/contributed_definitions/nyaml/NXlockin.yaml @@ -5,19 +5,23 @@ NXlockin: hardware(NXfabrication): doc: Hardware manufacturers and type of lockin amplifier. (NXamplifier): - doc: input and output amplifiers + doc: !!! input and output amplifiers + bias_divider: + doc: if Lock-in -- Bias Divider 1/10 or 1/100 # if the modulation status(NX_BOOLEAN): + doc: !!! if lock_in is on or off + modulation_status(NX_BOOLEAN): doc: Switch the lock-in moulation on or off. - modulate_signal: - doc: This is the signal on which the modulation (sine) will be added, such as current, bias, et.al. - amplitude(NX_NUMBER): + modulation_signal: + doc: !!! This is the signal on which the modulation (sine) will be added, such as current, bias, et.al. + modulation_amplitude(NX_NUMBER): doc: Sets the amplitude (in physical units of the modulated signal) of the sine modulation. unit: NX_VOLTAGE (For bais modulate signal, it depands on the modulate type) - frequency(NX_NUMBER): + modulation_frequency(NX_NUMBER): doc: Sets the frequency of the sine modulation added to the signal to modulate. unit: NX_FREQUENCY demodulated_signal: - doc: This is the signal which will be demodulated, in order to determine the amplitude and phase at the frequency set in the Frequency field or harmonics, such as current, bias, et.al. + doc: !!! This is the signal which will be demodulated, in order to determine the amplitude and phase at the frequency set in the Frequency field or harmonics, such as current, bias, et.al. #output (demodulated signal) characterisation (foreach channel, like demodulation, a separate sensor output, e.g. X,Y) number_of_demodulator_channels(NX_NUMBER): doc: The number of signals which will be demodulated. @@ -27,7 +31,7 @@ NXlockin: hi_pass(NX_NUMBER): doc: Order and cut-off frequency of the high-pass filter applied on the demodulation signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) unit: NX_FREQUENCY - lp_filter Cutoff(NX_NUMBER): + lp_filter_cutoff(NX_NUMBER): doc: Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) value) for D1. The filter is applied to the demodulated signals (X,Y). unit: NX_FREQUENCY lp_filter_order(NX_NUMBER): diff --git a/contributed_definitions/nyaml/NXpositioner.nxdl.xml b/contributed_definitions/nyaml/NXpositioner.nxdl.xml deleted file mode 100644 index 022e4e3106..0000000000 --- a/contributed_definitions/nyaml/NXpositioner.nxdl.xml +++ /dev/null @@ -1,282 +0,0 @@ - - - - - - A generic positioner such as a motor or piezo-electric transducer. - - - - symbolic or mnemonic name (one word) - - - - - description of positioner - - - - - best known value of positioner - need [n] as may be scanned - - - - - - - - raw value of positioner - need [n] as may be scanned - - - - - - - - targeted (commanded) value of positioner - need [n] as may be scanned - - - - - - - - maximum allowable difference between target_value and value - - - - - - - - minimum allowed limit to set value - - - - - maximum allowed limit to set value - - - - - velocity of the positioner (distance moved per unit time) - - - - - time to ramp the velocity up to full speed - - - - - Hardware device record, e.g. EPICS process variable, taco/tango ... - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - - - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a positioner. - - - - - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - - - - - To clarify the frame laboratory frame. The scanning area in x, y, and z position - in the frame. - - - - - Offset added to the initial averaged position Zaver before starting to swepp. - - - - - Indicate the tip position Z between tip and sample. The tip position can also be - varied when the controller is not running. - - - - - Controller name. This name which will be displayed at places where you can - select a controller. - - - - - Set Point is the desired value of the control signal. It can be set by editing - the number or using the slider bar. Click the "Set" button above the input field - to use the actual value as Set Point. The slider shows the Set Point as well as - the current value. - - - - - The unit of setpoint during the scanning. - - - - - The Type switches controller parameters between P/I (proportional gain/integral - gain) and P/T (proportional gain/time constant). The formula for the controller - in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral - gain and time constant are related as follows I = P/T. - - - - - The Type switches controller parameters between P/I (proportional gain/integral - gain) and P/T (proportional gain/time constant). The formula for the controller - in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and - time constant are related as follows I = P/T. - - - - - The Type switches controller parameters between P/I (proportional gain/integral - gain) and P/T (proportional gain/time constant). The formula for the controller - in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and - time constant are related as follows I = P/T. - - - - - Lifts the tip by the specified amount when then controller is switched off. This - can be a positive or a negative number, i.e. the tip can also be moved towards - the sample. Be careful with sign and value when using this feature. - - - - - Use this parameter for a reproducible position when switching off the - Z-controller. When >0 and the Z-controller is switched off, it doesn't switch - off immediately but continues to run for the specified time and averages the Z - position. - - - - - (In bias spectroscopy) Select whether to set the Z-Controller on hold (i.e. - disabled) during the sweep. It is selected by default. When deselected, Z-offset - and Z control time parameters are disabled. - - - - - Configure the scan frame like x position; y position; width; height. - - - - - Scan resolution by setting the Lines equal to Pixels. - - - - - Define the image resolution. - - - - - Define the scan forward speed in the forward direction. - - - - - Define the scan backward speed in the forward direction. - - - - - There are 3 parameters in X, Y, and Z directions and there are 3 controls available: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. - - - - - Adjusts the amplitude range or amplitude of the Piezo output signal - - - - - For some systems HV gain readout is available, so for those systems the HV gain - should be adjusted automatically when the gain is changed at the high voltage - amplifier. - - - - - There are 2 parameters in X and Y directions and this tab is used to set the - sample tilt (in degrees, first order correction). - - - - - There are 2 parameters in X and Y directions and this tab is used to set a - curvature (can be set approximately to the length of the piezotube). - - - - - There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2) - - - - - There are 2 parameters in X and Y directions. Define the drift speed for all - three axes. When the compensation is on, the piezos will start to move at that - speed. - - - - - Use the button to turn on/off the drift compensation. - - - diff --git a/contributed_definitions/nyaml/NXsensor.nxdl.xml b/contributed_definitions/nyaml/NXsensor.nxdl.xml deleted file mode 100644 index 08fb5f76f9..0000000000 --- a/contributed_definitions/nyaml/NXsensor.nxdl.xml +++ /dev/null @@ -1,232 +0,0 @@ - - - - - - A sensor used to monitor an external condition - - The condition itself is described in :ref:`NXenvironment`. - - - - Sensor identification code/model number - - - - - Name for the sensor - - - - - Short name of sensor used e.g. on monitor display program - - - - - where sensor is attached to ("sample" | "can") - - - - - Defines the axes for logged vector quantities if they are not the global instrument axes. - - - - - name for measured signal - - - - - - - - - - - - - - - - - - - - - The type of hardware used for the measurement. - Examples (suggestions but not restrictions): - - :Temperature: - J | K | T | E | R | S | Pt100 | Pt1000 | Rh/Fe - :pH: - Hg/Hg2Cl2 | Ag/AgCl | ISFET - :Ion selective electrode: - specify species; e.g. Ca2+ - :Magnetic field: - Hall - :Surface pressure: - wilhelmy plate - - - - - - link to second amplifer circuit with 1MOhm - - - - - Is data collection controlled or synchronised to this quantity: - 1=no, 0=to "value", 1=to "value_deriv1", etc. - - - - - Upper control bound of sensor reading if using run_control - - - - - Lower control bound of sensor reading if using run_control - - - - - nominal setpoint or average value - - need [n] as may be a vector - - - - - - - - Nominal/average first derivative of value - e.g. strain rate - - same dimensions as "value" (may be a vector) - - - - - - - - Nominal/average second derivative of value - - same dimensions as "value" (may be a vector) - - - - - - - - Time history of sensor readings - - - - - Time history of first derivative of sensor readings - - - - - Time history of second derivative of sensor readings - - - - - - - - - - - - - - - For complex external fields not satisfied by External_field_brief - - - - - This group describes the shape of the sensor when necessary. - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - - - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a sensor. - - - - - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - - - - - External sensors connected to the device. For example, T1, temperature of STM - head. T2, temperature of bottom of LHe helium cryostat. T3, temperature of LN2 - nitrogen shield. - - - - - External sensors connected to the device. Pressure of each chamber or ion pump, - such as prepare chamber and analysis chamber - - - - - The power present in the signal as a function of frequency. Used to characterise - the vibration and noise of scanning probes to detect and reduce the impact on - resolution during STM imaging - - - From 8d362268de4622a4368812f44f43937cb0b2b8be Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Fri, 19 May 2023 10:07:29 +0200 Subject: [PATCH 0135/1012] finalisation of rearrangement: also indicators and plots --- .../nyaml/NXiv_sweep2.yaml | 361 +++++++++--------- 1 file changed, 175 insertions(+), 186 deletions(-) diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index d8d65659d9..01c56fcbf3 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -98,6 +98,25 @@ NXiv_sweep2(NXsensor_scan): # doc: User outputs whose name can be modified in the corresponding module. (e.g. Input 24 (V)) #output_slew_rate(NX_NUMBER): # doc: The rate at which the one of the signal changes when ramping to the starting point. (V/s) (e.g. Inf) + piezo_config(NXcollection): + active_calib.: + doc: The name of caliberation type. (e.g. LHe) + calib._N(NX_NUMBER): + doc: N denotes X or Y or Z. There are 3 parameters in X, Y, and Z directions and there are 3 controls available: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. (e.g. 3.8E-9) + hv_gain_N(NX_NUMBER): + doc: N denotes X or Y or Z. For some systems HV gain readout is available, so for those systems the HV gain should be adjusted automatically when the gain is changed at the high voltage amplifier. (e.g. 14.5) + tilt_N(NX_NUMBER): (e.g. 0.318343) + unit: NX_ANGLE + doc: N denotes X or Y. There are 2 parameters in X and Y directions and this tab is used to set the sample tilt (in degrees, first order correction). + curvature_radius N(NX_NUMBER): Inf + unit: NX_LENGTH + doc: N denotes X or Y. There are 2 parameters in X and Y directions and this tab is used to set a curvature (can be set approximately to the length of the piezotube). + 2nd_order_corr_N(NX_NUMBER): + doc: N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2). (e.g. 0E+0) + drift_N(NX_NUMBER): + doc: N denotes X or Y. There are 2 parameters in X and Y directions. Define the drift speed for all three axes. When the compensation is on, the piezos will start to move at that speed. (e.g. 0E+0) + drift_correction_status(NX_BOOLEAN): + doc: Use the button to turn on/off the drift compensation. (e.g. FALSE) (NXenvironment): doc: | Describes an environment setup for a temperature-dependent IV measurement experiment. @@ -107,194 +126,164 @@ NXiv_sweep2(NXsensor_scan): voltage_controller(NXsensor): temperature_controller(NXsensor): current_sensor(NXsensor): - (NXdata): + position(NXpositioner): + doc: Clarify the frame laboratory frame. + x(NX_NUMBER): + unit: NX_LENGTH + doc: The scanning area in x position in the frame. (e.g. -890.53E-12) + y(NX_NUMBER): + unit: NX_LENGTH + doc: The scanning area in y position in the frame. (e.g. 29.6968E-9) + z(NX_NUMBER): + unit: NX_LENGTH + doc: The scanning area in x position in the frame. (e.g. 130.5E-9) + z-controller(NB_NUMBER): + unit: NX_LENGTH + doc: Indicate the tip position Z between tip and sample. The tip position can also be varied when the controller is not running. (e.g. 130.5E-9) + sweep_control(NXcollection): # parameters for a measurement at a single location during the scan + bias_spectroscopy(NXcollection)): + integration time(NX_NUMBER): + unit: NX_TIME + doc: Time during which the spectroscopy data are acquired and averaged. (e.g. 150E-6) + number_of_sweeps(NX_NUMBER): + doc: Number of sweeps to measure and average. (e.g. 100) + sweep_start(NX_NUMBER): + unit: NX_VOLTAGE + doc: The first bias values of the sweep. (e.g. -300E-3) + sweep_end(NX_NUMBER): + unit: NX_VOLTAGE + doc: The last bias values of the sweep. (e.g. 300E-3) + num_pixel(NX_NUMBER): + doc: Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. (e.g. 4096) + z_avg_time(NX_NUMBER): + unit: NX_TIME + doc: Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). (e.g. 100E-3) + circuit(NXcollection): + rt_frequency(NX_NUMBER): + unit: NX_FREQENCY + doc: The bandwitdh of the Hardware and/or Software (e.g. 20E+3) + signals_oversampling(NX_NUMBER): + doc: (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. (e.g. 10) + acquisition_period(NX_NUMBER): + unit: NX_TIME + doc: Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. (e.g. 20E-3) + animations_period(NX_NUMBER): + unit: NX_TIME + doc: Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. (e.g. 20E-3) + indicators_period(NX_NUMBER): + unit: NX_TIME + doc: Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. (e.g. 300E-3) + measurements_period (NX_NUMBER): + unit: NX_TIME + doc: The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. (e.g. 500E-3) + scan_control(NXcollection): # parameters how to change the location from measurement to measurement during the scan + roi(NXtransformation): + frame: + doc: Also clarify the frame for the ROI of the scan (should depend on the lab frame) + circuit(NXcollection): + channels_current: + doc: The scan channels are selected by users. (e.g. (A);Bias (V);Z (m);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A)) + positioner(NXcollection)): + scanfield(NX_NUMBER): + doc: Configure the scan frame like x position; y position; width; height. (e.g. 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0) + pixels/line(NX_NUMBER): + doc: Scan resolution by setting the Lines equal to Pixels. (e.g. 512) + lines(NX_NUMBER): + doc: Define the image resolution. (e.g. 512) + speed_forw.(NX_NUMBER): + doc: Define the scan forward speed in the forward direction. (m/s) (e.g. 11.7187E-9) + speed_backw.(NX_NUMBER): + doc: Define the scan backward speed in the forward direction. (m/s) (e.g. 11.7187E-9) + resolution_indicators(NXprocess): # RESOLUTION (calculation input) + temp_stm_head: #Temperature 1>link to INSTR/STM/head Temperature 1 (K) (e.g. 4.92997E+0) # Temperature of STM head. + temp_cryo_bottom: #Temperature 2>link to Temperature 2 (K) - # Temperature of bottom of LHe helium cryostat. + temp_cryo_shield: #Temperature 3>link to Temperature 3 (K) - # Temperature of LN2 nitrogen shield. + modulated_signal_bias: #Lock-in>link to Modulated signal Bias (V) (e.g. 1E-3) # Applied modulation to the bias voltage. + integration_time: #link to Integration time (s) (e.g. 150E-6) # Time during which the spectroscopy data are acquired and averaged. + number_of_sweps: #link to Bias Spectroscopy>Number of sweeps (e.g. 100) # Number of sweeps to measure and average. + sweep_start: #link to Bias Spectroscopy>Sweep Start (V) (e.g. -300E-3) # The first bias values of the sweep. + sweep_end: #link to Bias Spectroscopy>Sweep End (V) (e.g. 300E-3) # The last bias values of the sweep. + number_of_pixels: #link to Bias Spectroscopy>Num Pixel (e.g. 4096) # Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. + z_avg_time: #link to Bias Spectroscopy>Z Avg time (s) (e.g. 100E-3) # Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). + rt_freq: #link to SoftwareMain>RT Frequency (Hz) (e.g. 20E+3) # The bandwitdh of the Hardware and/or Software + oversampling: #link to SoftwareMain>Signals Oversampling (e.g. 10) # (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. + acquisition_period: #link to SoftwareMain>Acquisition Period (s) (e.g. 20E-3) # Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. + animation_period: #link to SoftwareMain>Animations Period (s) (e.g. 20E-3) # Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. + indicators_period: #link to SoftwareMain>Indicators Period (s) (e.g. 300E-3) # Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. + measurement_period: #link to SoftwareMain>Measurements Period (s) (e.g. 500E-3) # The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. + reproducibility_indicators(NXprocess): #REPRODUCIBILITY + bias: # Bias>Bias(NXBias) (V) (e.g. 100E-3) # Applied bias voltage. + current: # Current>Current(NXcircuit) (A) (e.g. -5.3429E-15) # The tunneling current is displayed here. + bias_calibration: # Bias>Calibration(NXbias) (V/V) (e.g. 1E+0) # Calibration of the Bias output. If you have a Range switch the calibration is stored per range setting. + bias_offset: # Bias>Offset(NXbias) (V) (e.g. 0E+0) # Allows compensating for an offset in Bias. + current_calibration: # Current>Calibration(NXcircuit) (A/V) (e.g. 100E-12) # The signals voltages are converted to real world physical values according to the calibration & offset parameters: Physical signal = (Voltage * calibration) + offset. + current_offset: # Current>Offset(NXcircuit) (A) (e.g. 16.2897E-15) # The same as "Current>Calibration (A/V)" tag + current_gain: # Current>Gain(NXcircuit) (e.g. Not switchable) # None + z_offset: # Z offset(NXpositioner) (m) (e.g. 0E+0) # Offset added to the initial averaged position Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an alternate Z-controller setpoint is enabled. + settling_time: # Settling time(NXbias) (s) (e.g. 2.1E-3) # Time to wait after changing the bias to the next level and before starting to acquire data. Adjust this parameter to avoid transient effect induced by the bias change. Integration time: time during which the data are acquired and averaged. + z_control_hold: # Z-Ctrl hold(NXpositioner) (e.g. TRUE) # When selected, the Z-Controller is set to hold during the pulse. This means that the controller doesn't control the Z position during the pulse. + final_z: # Final Z(NXpositioner) (m) (e.g. N/A) + start_time: # Start time(NXlog) (e.g.23.11.2022 18:55:16) # Timestamp of the moment when the acquisition starts by pressing the Start button. + z_offset: !!! do not we have it already above ??? # Bias Spectroscopy>Z offset(NXbias) (m) (e.g.0E+0) # Offset added to the initial averaged position Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an alternate Z-controller setpoint is enabled. + 1st_settling_time: # Bias Spectroscopy>1st Settling time(NXbias) (s) (e.g.2.1E-3) # See the "Settling time (s)" below. + settling_time: !!! # Bias Spectroscopy>Settling time(NXbias) (s) (e.g.2.1E-3) # See the "Settling time (s)" below. + integration_time: # Bias Spectroscopy>Integration time(NXbias) (s) (e.g.150E-6) # Time during which the data are acquired and averaged. + end_settling_time: # Bias Spectroscopy>End Settling time(NXbias) (s) (e.g.4E-3) # Time to wait after the sweep has finished and the bias is ramped to the initial value. + z_contro_time: # Bias Spectroscopy>Z control time(NXbias) (s) (e.g.200E-3) # Time during which the Z-Controller is enabled once a sweep has finished. When averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled for this duration between each sweep. After the last sweep, it will wait the specified time before continuing a running scan. This ensures each sweep reliably starts from the same position. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. + max_slew_rate: # Bias Spectroscopy>Max Slew rate(NXbias) (V/s) (e.g.1E+0) # Maximum rate at which the bias changes (before, during and after sweeping). + backward_sweep: # Bias Spectroscopy>backward sweep(NXbias) (e.g.TRUE) # Select whether to measure the backward (return) sweep or the forward only. + z_control_hold: !!! # Bias Spectroscopy>Z-controller hold(NXbias) (e.g.TRUE # Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. + z_control_name: # Z-Controller>Controller name(NXpositioner) (e.g.log Current) # Controller name. This name which will be displayed at places where you can select a controller. + z_control_status: # Z-Controller>Controller status(NXpositioner) (e.g.OFF) # ON/OFF + z_sontrol_setpoint: # Z-Controller>Setpoint(NXpositioner) (e.g.50E-12) # Set Point is the desired value of the control signal. It can be set by editing the number or using the slider bar. Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. + # Z-Controller>Setpoint unit(NXpositioner) (e.g.A) # Angstrom + z_control_p_gain: ??? looks like an NXpid # Z-Controller>P gain(NXpositioner) (e.g.6E-12) # The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. + z_control_i_gain: # Z-Controller>I gain(NXpositioner) (e.g.39.8241E-9) # See "Z-Controller>P gain" below. + z_control_time_const: # Z-Controller>Time const(NXpositioner) (s) (e.g.150.662E-6) # See "Z-Controller>P gain" below. + z_control_tip_lift: # Z-Controller>TipLift(NXpositioner) (m) (e.g.0E+0) # Lifts the tip by the specified amount when then controller is switched off. This can be a positive or a negative number, i.e. the tip can also be moved towards the sample. Be careful with sign and value when using this feature. + z_control_switchoff_delay: # Z-Controller>Switch off delay(NXpositioner) (s) (e.g.0E+0) # Use this parameter for a reproducible position when switching off the Z-controller. When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. + data(NXdata): doc: | This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. There should also be two more fields called temperature and voltage containing the setpoint values. There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension equal to the number of voltage setpoints. - - - - INSTRUMENT - piezo_config(NXcollection): - active_calib.: - doc: The name of caliberation type. (e.g. LHe) - calib._N(NX_NUMBER): - doc: N denotes X or Y or Z. There are 3 parameters in X, Y, and Z directions and there are 3 controls available: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. (e.g. 3.8E-9) - hv_gain_N(NX_NUMBER): - doc: N denotes X or Y or Z. For some systems HV gain readout is available, so for those systems the HV gain should be adjusted automatically when the gain is changed at the high voltage amplifier. (e.g. 14.5) - tilt_N(NX_NUMBER): (e.g. 0.318343) - unit: NX_ANGLE - doc: N denotes X or Y. There are 2 parameters in X and Y directions and this tab is used to set the sample tilt (in degrees, first order correction). - curvature radius N(NX_NUMBER): Inf - unit: NX_LENGTH - doc: N denotes X or Y. There are 2 parameters in X and Y directions and this tab is used to set a curvature (can be set approximately to the length of the piezotube). - 2nd_order_corr N(NX_NUMBER): - doc: N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2). (e.g. 0E+0) - drift_N(NX_NUMBER): - doc: N denotes X or Y. There are 2 parameters in X and Y directions. Define the drift speed for all three axes. When the compensation is on, the piezos will start to move at that speed. (e.g. 0E+0) - drift_correction_status(NX_BOOLEAN): - doc: Use the button to turn on/off the drift compensation. (e.g. FALSE) - - MEASUREMENT - Position(NXpositioner): - doc: Clarify the frame laboratory frame. - x(NX_NUMBER): - unit: NX_LENGTH - doc: The scanning area in x position in the frame. (e.g. -890.53E-12) - y(NX_NUMBER): - unit: NX_LENGTH - doc: The scanning area in y position in the frame. (e.g. 29.6968E-9) - z(NX_NUMBER): - unit: NX_LENGTH - doc: The scanning area in x position in the frame. (e.g. 130.5E-9) - z-controller(NB_NUMBER): - unit: NX_LENGTH - doc: Indicate the tip position Z between tip and sample. The tip position can also be varied when the controller is not running. (e.g. 130.5E-9) - sweep control # parameters for a measurement at a single location during the scan - (NXbias_spectroscopy): - integration time(NX_NUMBER): - unit: NX_TIME - doc: Time during which the spectroscopy data are acquired and averaged. (e.g. 150E-6) - number_of_sweeps(NX_NUMBER): - doc: Number of sweeps to measure and average. (e.g. 100) - sweep_start(NX_NUMBER): - unit: NX_VOLTAGE - doc: The first bias values of the sweep. (e.g. -300E-3) - sweep_end(NX_NUMBER): - unit: NX_VOLTAGE - doc: The last bias values of the sweep. (e.g. 300E-3) - num_pixel(NX_NUMBER): - doc: Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. (e.g. 4096) - z_avg_time(NX_NUMBER): - unit: NX_TIME - doc: Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). (e.g. 100E-3) - (NXcircuit): - rt_frequency(NX_NUMBER): - unit: NX_FREQENCY - doc: The bandwitdh of the Hardware and/or Software (e.g. 20E+3) - signals_oversampling(NX_NUMBER): - doc: (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. (e.g. 10) - acquisition_period(NX_NUMBER): - unit: NX_TIME - doc: Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. (e.g. 20E-3) - animations_period(NX_NUMBER): - unit: NX_TIME - doc: Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. (e.g. 20E-3) - indicators_period(NX_NUMBER): - unit: NX_TIME - doc: Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. (e.g. 300E-3) - measurements_period (NX_NUMBER): - unit: NX_TIME - doc: The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. (e.g. 500E-3) - Scan control # parameters how to change the location from measurement to measurement during the scan - (NXtransformation): - frame: - doc: Also clarify the frame for the ROI of the scan (should depend on the lab frame) - (NXcircuit): - channels_current: - doc: The scan channels are selected by users. (e.g. (A);Bias (V);Z (m);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A)) - (NXpositioner): - scanfield(NX_NUMBER): - doc: Configure the scan frame like x position; y position; width; height. (e.g. 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0) - pixels/line(NX_NUMBER): - doc: Scan resolution by setting the Lines equal to Pixels. (e.g. 512) - lines(NX_NUMBER): - doc: Define the image resolution. (e.g. 512) - speed_forw.(NX_NUMBER): - doc: Define the scan forward speed in the forward direction. (m/s) (e.g. 11.7187E-9) - speed_backw.(NX_NUMBER): - doc: Define the scan backward speed in the forward direction. (m/s) (e.g. 11.7187E-9) - - RESOLUTION (calculation input) - Temperature 1>link to INSTR/STM/head Temperature 1 (K) (e.g. 4.92997E+0) # Temperature of STM head. - Temperature 2>link to Temperature 2 (K) - # Temperature of bottom of LHe helium cryostat. - Temperature 3>link to Temperature 3 (K) - # Temperature of LN2 nitrogen shield. - Lock-in>link to Modulated signal Bias (V) (e.g. 1E-3) # Applied modulation to the bias voltage. - link to Integration time (s) (e.g. 150E-6) # Time during which the spectroscopy data are acquired and averaged. - link to Bias Spectroscopy>Number of sweeps (e.g. 100) # Number of sweeps to measure and average. - link to Bias Spectroscopy>Sweep Start (V) (e.g. -300E-3) # The first bias values of the sweep. - link to Bias Spectroscopy>Sweep End (V) (e.g. 300E-3) # The last bias values of the sweep. - link to Bias Spectroscopy>Num Pixel (e.g. 4096) # Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. - link to Bias Spectroscopy>Z Avg time (s) (e.g. 100E-3) # Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). - link to SoftwareMain>RT Frequency (Hz) (e.g. 20E+3) # The bandwitdh of the Hardware and/or Software - link to SoftwareMain>Signals Oversampling (e.g. 10) # (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. - link to SoftwareMain>Acquisition Period (s) (e.g. 20E-3) # Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. - link to SoftwareMain>Animations Period (s) (e.g. 20E-3) # Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. - link to SoftwareMain>Indicators Period (s) (e.g. 300E-3) # Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. - link to SoftwareMain>Measurements Period (s) (e.g. 500E-3) # The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. - REPRODUCIBILITY - link to - Bias>Bias(NXBias) (V) (e.g. 100E-3) # Applied bias voltage. - Current>Current(NXcircuit) (A) (e.g. -5.3429E-15) # The tunneling current is displayed here. - Bias>Calibration(NXbias) (V/V) (e.g. 1E+0) # Calibration of the Bias output. If you have a Range switch the calibration is stored per range setting. - Bias>Offset(NXbias) (V) (e.g. 0E+0) # Allows compensating for an offset in Bias. - Current>Calibration(NXcircuit) (A/V) (e.g. 100E-12) # The signals voltages are converted to real world physical values according to the calibration & offset parameters: Physical signal = (Voltage * calibration) + offset. - Current>Offset(NXcircuit) (A) (e.g. 16.2897E-15) # The same as "Current>Calibration (A/V)" tag - Current>Gain(NXcircuit) (e.g. Not switchable) # None - Z offset(NXpositioner) (m) (e.g. 0E+0) # Offset added to the initial averaged position Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an alternate Z-controller setpoint is enabled. - Settling time(NXbias) (s) (e.g. 2.1E-3) # Time to wait after changing the bias to the next level and before starting to acquire data. Adjust this parameter to avoid transient effect induced by the bias change. Integration time: time during which the data are acquired and averaged. - Z-Ctrl hold(NXpositioner) (e.g. TRUE) # When selected, the Z-Controller is set to hold during the pulse. This means that the controller doesn't control the Z position during the pulse. - Final Z(NXpositioner) (m) (e.g. N/A) - Start time(NXlog) (e.g.23.11.2022 18:55:16) # Timestamp of the moment when the acquisition starts by pressing the Start button. - Bias Spectroscopy>Z offset(NXbias) (m) (e.g.0E+0) # Offset added to the initial averaged position Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an alternate Z-controller setpoint is enabled. - Bias Spectroscopy>1st Settling time(NXbias) (s) (e.g.2.1E-3) # See the "Settling time (s)" below. - Bias Spectroscopy>Settling time(NXbias) (s) (e.g.2.1E-3) # See the "Settling time (s)" below. - Bias Spectroscopy>Integration time(NXbias) (s) (e.g.150E-6) # Time during which the data are acquired and averaged. - Bias Spectroscopy>End Settling time(NXbias) (s) (e.g.4E-3) # Time to wait after the sweep has finished and the bias is ramped to the initial value. - Bias Spectroscopy>Z control time(NXbias) (s) (e.g.200E-3) # Time during which the Z-Controller is enabled once a sweep has finished. When averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled for this duration between each sweep. After the last sweep, it will wait the specified time before continuing a running scan. This ensures each sweep reliably starts from the same position. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. - Bias Spectroscopy>Max Slew rate(NXbias) (V/s) (e.g.1E+0) # Maximum rate at which the bias changes (before, during and after sweeping). - Bias Spectroscopy>backward sweep(NXbias) (e.g.TRUE) # Select whether to measure the backward (return) sweep or the forward only. - Bias Spectroscopy>Z-controller hold(NXbias) (e.g.TRUE # Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. - Z-Controller>Controller name(NXpositioner) (e.g.log Current) # Controller name. This name which will be displayed at places where you can select a controller. - Z-Controller>Controller status(NXpositioner) (e.g.OFF) # ON/OFF - Z-Controller>Setpoint(NXpositioner) (e.g.50E-12) # Set Point is the desired value of the control signal. It can be set by editing the number or using the slider bar. Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. - Z-Controller>Setpoint unit(NXpositioner) (e.g.A) # Angstrom - Z-Controller>P gain(NXpositioner) (e.g.6E-12) # The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. - Z-Controller>I gain(NXpositioner) (e.g.39.8241E-9) # See "Z-Controller>P gain" below. - Z-Controller>Time const(NXpositioner) (s) (e.g.150.662E-6) # See "Z-Controller>P gain" below. - Z-Controller>TipLift(NXpositioner) (m) (e.g.0E+0) # Lifts the tip by the specified amount when then controller is switched off. This can be a positive or a negative number, i.e. the tip can also be moved towards the sample. Be careful with sign and value when using this feature. - Z-Controller>Switch off delay(NXpositioner) (s) (e.g.0E+0) # Use this parameter for a reproducible position when switching off the Z-controller. When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. - - DATA # multi dimensional array: multi I-V array per scan point; - doc: The format of the data here is similar to a column matrix. - Bias calc (V) #scanning parameter - Current (A) # current during forward direction scanning of bias - original NXsensor - LI Demod 2 X (A) lockin (NXsensor+lockin) - LI Demod 2 Y (A) lockin - LI Demod 1 X (A) lockin - LI Demod 1 Y (A) lockin - Current [bwd] (A) #bwd - backward (the positive direction shall be clarified by the reference bias scanning frame. Fwd means from left(neg) to right(pos). In the scannig image, the bottom(neg) to top(pos), the left(neg) to right(pos) - LI Demod 2 X [bwd] (A) lockin - LI Demod 2 Y [bwd] (A) lockin - LI Demod 1 X [bwd] (A) lockin - LI Demod 1 Y [bwd] (A) lockin - Current (A) [filt] # forward direction (maybe from lockin#2?) - LI Demod 2 X (A) [filt] lockin - LI Demod 2 Y (A) [filt] lockin - LI Demod 1 X (A) [filt] lockin - LI Demod 1 Y (A) [filt] lockin - Current (A) [bwd] [filt] - LI Demod 2 X (A) [bwd] [filt] lockin - LI Demod 2 Y (A) [bwd] [filt] lockin - LI Demod 1 X (A) [bwd] [filt] lockin - LI Demod 1 Y (A) [bwd] [filt] lockin - Temperature - x - y - z - - single point default plot # current(I) vs bias(V) - line scan default plot # multi I vs. V curves - alternative plot # current(I) curve in the 2D space of (position(x), bias(V)) - mesh scan default plot # 2D slices of the above alternative plot - - - - - - - - - + axes: bias_calc + signals: + li_demod_[1;2]_[X/Y]_[-;bwd;filt;bwd_filt] + current_[-;bwd;filt;bwd_filt] + temperature + x + y + z + # DATA # multi dimensional array: multi I-V array per scan point; + # doc: The format of the data here is similar to a column matrix. + # Bias calc (V) #scanning parameter + # Current (A) # current during forward direction scanning of bias - original NXsensor + # LI Demod 2 X (A) lockin (NXsensor+lockin) + # LI Demod 2 Y (A) lockin + # LI Demod 1 X (A) lockin + # LI Demod 1 Y (A) lockin + # Current [bwd] (A) #bwd - backward (the positive direction shall be clarified by the reference bias scanning frame. Fwd means from left(neg) to right(pos). In the scannig image, the bottom(neg) to top(pos), the left(neg) to right(pos) + # LI Demod 2 X [bwd] (A) lockin + # LI Demod 2 Y [bwd] (A) lockin + # LI Demod 1 X [bwd] (A) lockin + # LI Demod 1 Y [bwd] (A) lockin + # Current (A) [filt] # forward direction (maybe from lockin#2?) + # LI Demod 2 X (A) [filt] lockin + # LI Demod 2 Y (A) [filt] lockin + # LI Demod 1 X (A) [filt] lockin + # LI Demod 1 Y (A) [filt] lockin + # Current (A) [bwd] [filt] + # LI Demod 2 X (A) [bwd] [filt] lockin + # LI Demod 2 Y (A) [bwd] [filt] lockin + # LI Demod 1 X (A) [bwd] [filt] lockin + # LI Demod 1 Y (A) [bwd] [filt] lockin + # Temperature + # x + # y + # z + single_point(NXdata): # single point default plot # current(I) vs bias(V) + line_scan(NXdata): # line scan default plot # multi I vs. V curves + alternative_plot(NXdata): # alternative plot # current(I) curve in the 2D space of (position(x), bias(V)) + mesh_scan(NXdata): # mesh scan default plot # 2D slices of the above alternative plot From 32ba9da7171aac8067f70ef6bb6b9370b0c28eb1 Mon Sep 17 00:00:00 2001 From: Yichen Date: Fri, 19 May 2023 11:24:55 +0200 Subject: [PATCH 0136/1012] Delete the dupulicate word and update, then the 237-240 should go to NXpid --- contributed_definitions/nyaml/NXiv_sweep2.yaml | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index 01c56fcbf3..1b535a3772 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -22,7 +22,7 @@ NXiv_sweep2(NXsensor_scan): definition: enumeration: [NXiv_sweep2] type: - doc: !!! + doc: The equipment and techniques as well as the parameter settings and reference signals are used during the experiments used in the scanning tunneling microscopy. enumeration: [background, reference, sample] entry_identifier: doc: The name of the output file, with the number of scans at the end.e.g. (e.g. 221122_Au_5K00014) @@ -224,23 +224,20 @@ NXiv_sweep2(NXsensor_scan): z_control_hold: # Z-Ctrl hold(NXpositioner) (e.g. TRUE) # When selected, the Z-Controller is set to hold during the pulse. This means that the controller doesn't control the Z position during the pulse. final_z: # Final Z(NXpositioner) (m) (e.g. N/A) start_time: # Start time(NXlog) (e.g.23.11.2022 18:55:16) # Timestamp of the moment when the acquisition starts by pressing the Start button. - z_offset: !!! do not we have it already above ??? # Bias Spectroscopy>Z offset(NXbias) (m) (e.g.0E+0) # Offset added to the initial averaged position Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an alternate Z-controller setpoint is enabled. 1st_settling_time: # Bias Spectroscopy>1st Settling time(NXbias) (s) (e.g.2.1E-3) # See the "Settling time (s)" below. - settling_time: !!! # Bias Spectroscopy>Settling time(NXbias) (s) (e.g.2.1E-3) # See the "Settling time (s)" below. integration_time: # Bias Spectroscopy>Integration time(NXbias) (s) (e.g.150E-6) # Time during which the data are acquired and averaged. end_settling_time: # Bias Spectroscopy>End Settling time(NXbias) (s) (e.g.4E-3) # Time to wait after the sweep has finished and the bias is ramped to the initial value. z_contro_time: # Bias Spectroscopy>Z control time(NXbias) (s) (e.g.200E-3) # Time during which the Z-Controller is enabled once a sweep has finished. When averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled for this duration between each sweep. After the last sweep, it will wait the specified time before continuing a running scan. This ensures each sweep reliably starts from the same position. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. max_slew_rate: # Bias Spectroscopy>Max Slew rate(NXbias) (V/s) (e.g.1E+0) # Maximum rate at which the bias changes (before, during and after sweeping). backward_sweep: # Bias Spectroscopy>backward sweep(NXbias) (e.g.TRUE) # Select whether to measure the backward (return) sweep or the forward only. - z_control_hold: !!! # Bias Spectroscopy>Z-controller hold(NXbias) (e.g.TRUE # Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. z_control_name: # Z-Controller>Controller name(NXpositioner) (e.g.log Current) # Controller name. This name which will be displayed at places where you can select a controller. z_control_status: # Z-Controller>Controller status(NXpositioner) (e.g.OFF) # ON/OFF z_sontrol_setpoint: # Z-Controller>Setpoint(NXpositioner) (e.g.50E-12) # Set Point is the desired value of the control signal. It can be set by editing the number or using the slider bar. Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. # Z-Controller>Setpoint unit(NXpositioner) (e.g.A) # Angstrom - z_control_p_gain: ??? looks like an NXpid # Z-Controller>P gain(NXpositioner) (e.g.6E-12) # The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. - z_control_i_gain: # Z-Controller>I gain(NXpositioner) (e.g.39.8241E-9) # See "Z-Controller>P gain" below. - z_control_time_const: # Z-Controller>Time const(NXpositioner) (s) (e.g.150.662E-6) # See "Z-Controller>P gain" below. - z_control_tip_lift: # Z-Controller>TipLift(NXpositioner) (m) (e.g.0E+0) # Lifts the tip by the specified amount when then controller is switched off. This can be a positive or a negative number, i.e. the tip can also be moved towards the sample. Be careful with sign and value when using this feature. + z_control_p_gain: ??? looks like an NXpid (yes, the p_gain, i_gain, and time_const can assign to NXpid) # Z-Controller>P gain(NXpositioner) (e.g.6E-12) # The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. + z_control_i_gain: !!!(NXpid) # Z-Controller>I gain(NXpositioner) (e.g.39.8241E-9) # See "Z-Controller>P gain" below. + z_control_time_const: !!!(NXpid) # Z-Controller>Time const(NXpositioner) (s) (e.g.150.662E-6) # See "Z-Controller>P gain" below. + z_control_tip_lift: !!!(NXpid) # Z-Controller>TipLift(NXpositioner) (m) (e.g.0E+0) # Lifts the tip by the specified amount when then controller is switched off. This can be a positive or a negative number, i.e. the tip can also be moved towards the sample. Be careful with sign and value when using this feature. z_control_switchoff_delay: # Z-Controller>Switch off delay(NXpositioner) (s) (e.g.0E+0) # Use this parameter for a reproducible position when switching off the Z-controller. When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. data(NXdata): doc: | From 9eef10010e9b9ddece00f1f15edd5b1c379f0b28 Mon Sep 17 00:00:00 2001 From: Yichen Date: Fri, 19 May 2023 11:55:15 +0200 Subject: [PATCH 0137/1012] Clarify the defination of signal and delete the status. --- contributed_definitions/nyaml/NXlockin.yaml | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/contributed_definitions/nyaml/NXlockin.yaml b/contributed_definitions/nyaml/NXlockin.yaml index 759c1c47f6..aa62774d2f 100644 --- a/contributed_definitions/nyaml/NXlockin.yaml +++ b/contributed_definitions/nyaml/NXlockin.yaml @@ -5,15 +5,13 @@ NXlockin: hardware(NXfabrication): doc: Hardware manufacturers and type of lockin amplifier. (NXamplifier): - doc: !!! input and output amplifiers + doc: By mixing the input signal (STS signal) with the modulated signal (such as Bias) and comparing it with the reference signal, they are enhanced and the effects of noise interference are reduced, resulting in more accurate measurements. bias_divider: - doc: if Lock-in -- Bias Divider 1/10 or 1/100 # if the modulation - status(NX_BOOLEAN): - doc: !!! if lock_in is on or off + doc: if Lock-in -- Bias Divider 1/10 or 1/100 # if the modulation modulation_status(NX_BOOLEAN): doc: Switch the lock-in moulation on or off. modulation_signal: - doc: !!! This is the signal on which the modulation (sine) will be added, such as current, bias, et.al. + doc: A modulation signal (such as bias, current et.al.) is a periodic voltage signal, usually applied to the surface of a sample, which serves to modify the physical properties of the sample surface and generate weak AC current signals that can be detected and analysed by instruments such as lock-in amplifiers. modulation_amplitude(NX_NUMBER): doc: Sets the amplitude (in physical units of the modulated signal) of the sine modulation. unit: NX_VOLTAGE (For bais modulate signal, it depands on the modulate type) @@ -21,7 +19,7 @@ NXlockin: doc: Sets the frequency of the sine modulation added to the signal to modulate. unit: NX_FREQUENCY demodulated_signal: - doc: !!! This is the signal which will be demodulated, in order to determine the amplitude and phase at the frequency set in the Frequency field or harmonics, such as current, bias, et.al. + doc: The input signal (STS signal) will be demodulated, in order to determine the amplitude and phase at the frequency set in the Frequency field or harmonics, such as current, bias, et.al. #output (demodulated signal) characterisation (foreach channel, like demodulation, a separate sensor output, e.g. X,Y) number_of_demodulator_channels(NX_NUMBER): doc: The number of signals which will be demodulated. From 6e26d7e73fb666c1802f1cd0c32b1ad9a99ac9ce Mon Sep 17 00:00:00 2001 From: Yichen Date: Fri, 19 May 2023 12:06:24 +0200 Subject: [PATCH 0138/1012] Update defination --- contributed_definitions/nyaml/NXlockin.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributed_definitions/nyaml/NXlockin.yaml b/contributed_definitions/nyaml/NXlockin.yaml index aa62774d2f..cb90dc229c 100644 --- a/contributed_definitions/nyaml/NXlockin.yaml +++ b/contributed_definitions/nyaml/NXlockin.yaml @@ -7,7 +7,7 @@ NXlockin: (NXamplifier): doc: By mixing the input signal (STS signal) with the modulated signal (such as Bias) and comparing it with the reference signal, they are enhanced and the effects of noise interference are reduced, resulting in more accurate measurements. bias_divider: - doc: if Lock-in -- Bias Divider 1/10 or 1/100 # if the modulation + doc: if Lock-in -- Bias Divider 1/10 or 1/100, Bias divider = V(ref)/[V(ref)+V(input)] # if the modulation modulation_status(NX_BOOLEAN): doc: Switch the lock-in moulation on or off. modulation_signal: From 2c555181e3903fe9878a94e3f0a2629c8f63eef8 Mon Sep 17 00:00:00 2001 From: Yichen Date: Fri, 19 May 2023 12:12:07 +0200 Subject: [PATCH 0139/1012] Comments some definitions that do not exist --- contributed_definitions/nyaml/NXamplifier.yaml | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/contributed_definitions/nyaml/NXamplifier.yaml b/contributed_definitions/nyaml/NXamplifier.yaml index 19ed013ade..d32a6db1e2 100644 --- a/contributed_definitions/nyaml/NXamplifier.yaml +++ b/contributed_definitions/nyaml/NXamplifier.yaml @@ -10,8 +10,8 @@ NXamplifier: doc: The number of preamplifier channels are ready tp to be used. (array for active channels) openloop_amplification(NX_NUMBER): doc: The output signal does not go through a feedback loop to adjust the amplification of the amplifier. (array for active channels) # From google. - amplification(NX_NUMBER): - doc: !!! The ratio of the amplitude of the output signal to the amplitude of the input signal. (array for active channels) # From google. + #amplification(NX_NUMBER): + # doc: !!! The ratio of the amplitude of the output signal to the amplitude of the input signal. (array for active channels) # From google. signal_over_noise(NX_NUMBER): doc: The ratio of the amplitue of the useful signal to the amplitude of the noise in the output signal of the amplifier. S/N=V_signal/V_noise. (array for active channels) crosstalk_factor(NX_NUMBER): @@ -27,7 +27,7 @@ NXamplifier: hi_pass(NX_NUMBER): doc: Order and cut-off frequency of the high-pass filter applied on the demodulation signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) unit: NX_FREQUENCY - voltage_amplifier_factor(NX_NUMBER): - doc: !!! Current Amplifier Factor typically refers to the gain of the probe current amplifier. (V/V) - current_amplifier_capacitive_cross_talk_compensation(NX_CHAR): - doc: !!! Reduces the effect of capacitive crosstalk in the circuit on experimental results. + #voltage_amplifier_factor(NX_NUMBER): + # doc: !!! Current Amplifier Factor typically refers to the gain of the probe current amplifier. (V/V) + #current_amplifier_capacitive_cross_talk_compensation(NX_CHAR): + # doc: !!! Reduces the effect of capacitive crosstalk in the circuit on experimental results. From d7a1e42c4f8c6f57dd7fdd8179c65aed33e763f9 Mon Sep 17 00:00:00 2001 From: Yichen Date: Fri, 19 May 2023 12:16:53 +0200 Subject: [PATCH 0140/1012] Modify the format and move i, p gain and t to NXpid --- .../nyaml/NXpositioner.yaml | 27 +++++++------------ 1 file changed, 9 insertions(+), 18 deletions(-) diff --git a/contributed_definitions/nyaml/NXpositioner.yaml b/contributed_definitions/nyaml/NXpositioner.yaml index 27ca7894fd..aa4db1d4ba 100644 --- a/contributed_definitions/nyaml/NXpositioner.yaml +++ b/contributed_definitions/nyaml/NXpositioner.yaml @@ -92,37 +92,28 @@ NXpositioner(NXobject): #(Z_contronller): # doc: | # This controllers task is to continuously adjust the Z position of the stm tip in order to keep the selected control signal as close as possible to the Set Point. Different control signals lead to different contronller beahvior. - Z_offset(NX_NUMBER): + z_offset(NX_NUMBER): doc: Offset added to the initial averaged position Zaver before starting to swepp. unit: NX_LENGTH - Tip_position_Z(NX_NUMBER): + yip_position_Z(NX_NUMBER): doc: Indicate the tip position Z between tip and sample. The tip position can also be varied when the controller is not running. unit: NX_LENGTH - Controller name(NX_CHAR): + controller name(NX_CHAR): doc: Controller name. This name which will be displayed at places where you can select a controller. - Setpoint(NX_NUMBER): + setpoint(NX_NUMBER): doc: Set Point is the desired value of the control signal. It can be set by editing the number or using the slider bar. Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. unit: NX_CUTTENT - Setpoint unit(NX_CHAR): + setpoint unit(NX_CHAR): doc: The unit of setpoint during the scanning. - P gain(NX_NUMBER): - doc: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows I = P/T. - unit: NX_LENGTH - I gain(NX_NUMBER): - doc: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows I = P/T. - unit: NX_ANY (NX_SPEED?) - Time const(NX_NUMBER): - doc: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows I = P/T. - unit: NX_TIME - TipLift(NX_NUMBER): + tipLift(NX_NUMBER): doc: Lifts the tip by the specified amount when then controller is switched off. This can be a positive or a negative number, i.e. the tip can also be moved towards the sample. Be careful with sign and value when using this feature. unit: NX_LENGTH - Switch off delay(NX_NUMBER): + switch off delay(NX_NUMBER): doc: Use this parameter for a reproducible position when switching off the Z-controller. When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. unit: NX_TIME - Z-controller hold(NX_BOOLEAN): + z-controller hold(NX_BOOLEAN): doc: (In bias spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. - Final Z(NX_NUMBER): + final_z(NX_NUMBER): doc: The final z-position during the bias spectroscopy scan. The availability of values is related to the mode of scanning. unit: NX_LENGTH (Scan contronller): From af1cde4a0016a19f3b16ce2f1452d9dec1da578b Mon Sep 17 00:00:00 2001 From: Rubel Date: Wed, 26 Jul 2023 10:03:13 +0200 Subject: [PATCH 0141/1012] Removing contribute pip.yaml --- contributed_definitions/nyaml/NXpid.yaml | 56 ++++++++++++++++++++++++ 1 file changed, 56 insertions(+) create mode 100644 contributed_definitions/nyaml/NXpid.yaml diff --git a/contributed_definitions/nyaml/NXpid.yaml b/contributed_definitions/nyaml/NXpid.yaml new file mode 100644 index 0000000000..b7187cbf60 --- /dev/null +++ b/contributed_definitions/nyaml/NXpid.yaml @@ -0,0 +1,56 @@ +doc: | + Contains the settings of a PID controller. +category: base +NXpid: + description: + doc: | + Description of how the Process Value for the PID controller is produced by sensor(s) in the setup. + + For example, a set of sensors could be averaged over before feeding it back into the loop. + pv_sensor(NXsensor): + doc: | + The sensor representing the Process Value used in the feedback loop for the PID. + + In case multiple sensors were used, this NXsensor should contain the proper calculated/aggregated value. + value_log(NXlog): + value(NX_NUMBER): + doc: | + The actual timeseries data fed back to the PID loop. + setpoint(NX_FLOAT): + unit: NX_ANY + doc: | + The Setpoint(s) used as an input for the PID controller. + + It can also be a link to an NXsensor.value field. + K_p_value(NX_NUMBER): + doc: | + Proportional term. The proportional term produces an output value + that is proportional to the current error value. + The proportional response can be adjusted by multiplying the error + by a constant Kp, called the proportional gain constant. + K_i_value(NX_NUMBER): + doc: | + The contribution from the integral term is proportional to both + the magnitude of the error and the duration of the error. + The integral in a PID controller is the sum of the instantaneous + error over time and gives the accumulated offset that should have + been corrected previously. The accumulated error is then + multiplied by the integral gain (Ki) and added to the + controller output. + K_d_value(NX_NUMBER): + doc: | + The derivative of the process error is calculated by determining + the slope of the error over time and multiplying this rate of + change by the derivative gain K_d. The magnitude of the + contribution of the derivative term to the overall control + action is termed the derivative gain, K_d + + p_gain(NX_NUMBER): + doc: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows I = P/T. + unit: NX_LENGTH + i_gain(NX_NUMBER): + doc: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows I = P/T. + unit: NX_ANY (NX_SPEED?) + time_const(NX_NUMBER): + doc: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows I = P/T. + unit: NX_TIME From 71ae1c0a40ce7ede9de34728c077b2a852d978ab Mon Sep 17 00:00:00 2001 From: Yichen Date: Fri, 19 May 2023 12:20:55 +0200 Subject: [PATCH 0142/1012] Update 237-239 to NXpid and modify the format --- contributed_definitions/nyaml/NXiv_sweep2.yaml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index 1b535a3772..eb81184cde 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -234,10 +234,10 @@ NXiv_sweep2(NXsensor_scan): z_control_status: # Z-Controller>Controller status(NXpositioner) (e.g.OFF) # ON/OFF z_sontrol_setpoint: # Z-Controller>Setpoint(NXpositioner) (e.g.50E-12) # Set Point is the desired value of the control signal. It can be set by editing the number or using the slider bar. Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. # Z-Controller>Setpoint unit(NXpositioner) (e.g.A) # Angstrom - z_control_p_gain: ??? looks like an NXpid (yes, the p_gain, i_gain, and time_const can assign to NXpid) # Z-Controller>P gain(NXpositioner) (e.g.6E-12) # The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. - z_control_i_gain: !!!(NXpid) # Z-Controller>I gain(NXpositioner) (e.g.39.8241E-9) # See "Z-Controller>P gain" below. - z_control_time_const: !!!(NXpid) # Z-Controller>Time const(NXpositioner) (s) (e.g.150.662E-6) # See "Z-Controller>P gain" below. - z_control_tip_lift: !!!(NXpid) # Z-Controller>TipLift(NXpositioner) (m) (e.g.0E+0) # Lifts the tip by the specified amount when then controller is switched off. This can be a positive or a negative number, i.e. the tip can also be moved towards the sample. Be careful with sign and value when using this feature. + z_control_p_gain: # Z-Controller>P gain(NXpid) (e.g.6E-12) # The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. + z_control_i_gain: # Z-Controller>I gain(NXpid) (e.g.39.8241E-9) # See "Z-Controller>P gain" below. + z_control_time_const: # Z-Controller>Time const(NXpid) (s) (e.g.150.662E-6) # See "Z-Controller>P gain" below. + z_control_tip_lift: # Z-Controller>TipLift(NXpositioner) (m) (e.g.0E+0) # Lifts the tip by the specified amount when then controller is switched off. This can be a positive or a negative number, i.e. the tip can also be moved towards the sample. Be careful with sign and value when using this feature. z_control_switchoff_delay: # Z-Controller>Switch off delay(NXpositioner) (s) (e.g.0E+0) # Use this parameter for a reproducible position when switching off the Z-controller. When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. data(NXdata): doc: | From 56d9f91df525bd833f1df1754c45f5ecc939bbd1 Mon Sep 17 00:00:00 2001 From: Yichen Date: Fri, 19 May 2023 13:27:39 +0200 Subject: [PATCH 0143/1012] update format --- contributed_definitions/nyaml/NXcircuit.yaml | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/contributed_definitions/nyaml/NXcircuit.yaml b/contributed_definitions/nyaml/NXcircuit.yaml index 7577ba12a1..8b24e76b9b 100644 --- a/contributed_definitions/nyaml/NXcircuit.yaml +++ b/contributed_definitions/nyaml/NXcircuit.yaml @@ -35,16 +35,16 @@ NXcircuit(NXobject): doc: The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. unit: NX_TIME number_of_outputs(NX_INT): - doc: number of output channels - output_mode_N(NX_CHAR): - doc: N represents the number of signal channels. The user output in each monitor mode. - output_value_N(NX_NUMBER): - doc: N represents the number of signal channels. The values for each output channel. + doc: Number of output channels + output_mode(NX_CHAR): + doc: The user output in each monitor mode. + output_value(NX_NUMBER): + doc: The values for each output channel. unit: NX_ANY - output_name_N: - doc: N represents the number of signal channels. User outputs whose name can be modified in the corresponding module. - output_slew_rate_N(NX_CHAR): - doc: N represents the number of signal channels. The rate at which the one of the signal changes when ramping to the starting point. (V/s) + output_name(NX_CHAR): + doc: User outputs whose name can be modified in the corresponding module. + output_slew_rate(NX_CHAR): + doc: The rate at which the one of the signal changes when ramping to the starting point. (V/s) From b160d52a033d5f494753e4735203323ae7b05832 Mon Sep 17 00:00:00 2001 From: Rubel Date: Wed, 14 Jun 2023 10:58:06 +0200 Subject: [PATCH 0144/1012] fix conflict in rebase --- .../nyaml/NXpositioner.yaml | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/contributed_definitions/nyaml/NXpositioner.yaml b/contributed_definitions/nyaml/NXpositioner.yaml index aa4db1d4ba..c285b7436e 100644 --- a/contributed_definitions/nyaml/NXpositioner.yaml +++ b/contributed_definitions/nyaml/NXpositioner.yaml @@ -95,23 +95,23 @@ NXpositioner(NXobject): z_offset(NX_NUMBER): doc: Offset added to the initial averaged position Zaver before starting to swepp. unit: NX_LENGTH - yip_position_Z(NX_NUMBER): + tip_position_z(NX_NUMBER): doc: Indicate the tip position Z between tip and sample. The tip position can also be varied when the controller is not running. unit: NX_LENGTH - controller name(NX_CHAR): + controller_name(NX_CHAR): doc: Controller name. This name which will be displayed at places where you can select a controller. setpoint(NX_NUMBER): doc: Set Point is the desired value of the control signal. It can be set by editing the number or using the slider bar. Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. unit: NX_CUTTENT - setpoint unit(NX_CHAR): - doc: The unit of setpoint during the scanning. - tipLift(NX_NUMBER): + #setpoint unit(NX_CHAR): + # doc: The unit of setpoint during the scanning. + tip_lift(NX_NUMBER): doc: Lifts the tip by the specified amount when then controller is switched off. This can be a positive or a negative number, i.e. the tip can also be moved towards the sample. Be careful with sign and value when using this feature. unit: NX_LENGTH - switch off delay(NX_NUMBER): + switch_off_delay(NX_NUMBER): doc: Use this parameter for a reproducible position when switching off the Z-controller. When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. unit: NX_TIME - z-controller hold(NX_BOOLEAN): + z-controller_hold(NX_BOOLEAN): doc: (In bias spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. final_z(NX_NUMBER): doc: The final z-position during the bias spectroscopy scan. The availability of values is related to the mode of scanning. @@ -128,10 +128,10 @@ NXpositioner(NXobject): lines(NX_NUMBER): doc: Define the image resolution. unit: NX_ANY - speed forw.(NX_NUMBER): + speed_forw.(NX_NUMBER): doc: Define the scan forward speed in the forward direction. - unit: NX_ANY(NX_SPEED?) - speed backw.(NX_NUMBER): + unit: NX_ANY + speed_backw.(NX_NUMBER): doc: Define the scan backward speed in the forward direction. unit: NX_ANY(NX_SPEED?) (Piezo_calibration): From a38177e9ea48f52084a5e3e147404de101d9fc31 Mon Sep 17 00:00:00 2001 From: Yichen Date: Fri, 19 May 2023 13:35:09 +0200 Subject: [PATCH 0145/1012] update format --- contributed_definitions/nyaml/NXsensor.yaml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/nyaml/NXsensor.yaml b/contributed_definitions/nyaml/NXsensor.yaml index 9ab4452156..6600a6c729 100644 --- a/contributed_definitions/nyaml/NXsensor.yaml +++ b/contributed_definitions/nyaml/NXsensor.yaml @@ -129,13 +129,13 @@ NXsensor(NXobject): the instrument. The dependency chain may however traverse similar groups in other component groups. ############## - Temperature(NX_NUMBER): + temperature(NX_NUMBER): doc: External sensors connected to the device. For example, T1, temperature of STM head. T2, temperature of bottom of LHe helium cryostat. T3, temperature of LN2 nitrogen shield. unit: NX_TEMPERATURE - Pressure(NX_BUMBER): + pressure(NX_BUMBER): doc: External sensors connected to the device. Pressure of each chamber or ion pump, such as prepare chamber and analysis chamber unit: NX_PRESSURE - Power Spectral Density (NX_NUMBER): + power_spectral_density (NX_NUMBER): doc: The power present in the signal as a function of frequency. Used to characterise the vibration and noise of scanning probes to detect and reduce the impact on resolution during STM imaging From e21b9fe2b01021aae0a9a58eb143df91bc673325 Mon Sep 17 00:00:00 2001 From: Yichen Date: Fri, 19 May 2023 14:16:05 +0200 Subject: [PATCH 0146/1012] Merge P_gain and I_gain to original one --- contributed_definitions/nyaml/NXpid.yaml | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/contributed_definitions/nyaml/NXpid.yaml b/contributed_definitions/nyaml/NXpid.yaml index b7187cbf60..eb63567991 100644 --- a/contributed_definitions/nyaml/NXpid.yaml +++ b/contributed_definitions/nyaml/NXpid.yaml @@ -28,6 +28,7 @@ NXpid: that is proportional to the current error value. The proportional response can be adjusted by multiplying the error by a constant Kp, called the proportional gain constant. + The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows I = P/T. K_i_value(NX_NUMBER): doc: | The contribution from the integral term is proportional to both @@ -44,13 +45,7 @@ NXpid: change by the derivative gain K_d. The magnitude of the contribution of the derivative term to the overall control action is termed the derivative gain, K_d - - p_gain(NX_NUMBER): - doc: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows I = P/T. - unit: NX_LENGTH - i_gain(NX_NUMBER): - doc: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows I = P/T. - unit: NX_ANY (NX_SPEED?) - time_const(NX_NUMBER): + K_t_const(NX_NUMBER): doc: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows I = P/T. unit: NX_TIME + From a9b29c4b2ee4853bedefd71121ba809948861818 Mon Sep 17 00:00:00 2001 From: Rubel Date: Mon, 22 May 2023 22:50:27 +0200 Subject: [PATCH 0147/1012] Addging notes after discussion with Yichen. --- contributed_definitions/NXpid.nxdl.xml | 9 ++++ .../nyaml/NXbias_spectroscopy.yaml | 3 +- .../nyaml/NXiv_sweep2.yaml | 49 +++++++++++++------ 3 files changed, 46 insertions(+), 15 deletions(-) diff --git a/contributed_definitions/NXpid.nxdl.xml b/contributed_definitions/NXpid.nxdl.xml index a2a98375e8..2be21767ed 100644 --- a/contributed_definitions/NXpid.nxdl.xml +++ b/contributed_definitions/NXpid.nxdl.xml @@ -59,6 +59,7 @@ that is proportional to the current error value. The proportional response can be adjusted by multiplying the error by a constant Kp, called the proportional gain constant. + The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows I = P/T. @@ -81,4 +82,12 @@ action is termed the derivative gain, K_d + + + The Type switches controller parameters between P/I (proportional gain/integral + gain) and P/T (proportional gain/time constant). The formula for the controller + in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and + time constant are related as follows I = P/T. + + diff --git a/contributed_definitions/nyaml/NXbias_spectroscopy.yaml b/contributed_definitions/nyaml/NXbias_spectroscopy.yaml index d74c76d92c..6d53631502 100644 --- a/contributed_definitions/nyaml/NXbias_spectroscopy.yaml +++ b/contributed_definitions/nyaml/NXbias_spectroscopy.yaml @@ -1,8 +1,9 @@ doc: | Base classes definition for bias spectroscopy. + + Bias sweeps while measuring arbitrary channels with I(V) curves. category: base NXbias_spectroscopy(NXobject): - doc: Bias sweeps while measuring arbitrary channels with I(V) curves. channels: doc: Select the channels to record. reset_bias(NX_BOOLEAN): diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index eb81184cde..c9f9ff9f49 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -27,7 +27,7 @@ NXiv_sweep2(NXsensor_scan): entry_identifier: doc: The name of the output file, with the number of scans at the end.e.g. (e.g. 221122_Au_5K00014) collection_dentifier: - doc: The name of the series output file, which represents only the public part of the output file. (e.g. 221122_Au_5K） + doc: The name of the series output file, which represents only the public part of the output file. (e.g. 221122_Au_5K) experiment_identifier: doc: Path to storage of output files. (e.g. Path C:\Users\SPM-PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis-Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711) experiment_description: @@ -78,16 +78,27 @@ NXiv_sweep2(NXsensor_scan): # modulated_signal_bias(NX_NUMBER): # unit: NX_VOLTAGE # doc: Same directional representation as bias. (e.g. 1E-3) - stm_head_temperature(NX_NUMBER): + stm_head_temp(NX_NUMBER): + exists: optional unit: NX_TEMPERATURE doc: | - Temperature of STM head. Temperature 1 (K) (e.g. 4.92997E+0) + Temperature of STM head. Temperature 1 (K) (e.g. 4.92997E+0). Note: At least + one field from stm_head_temperature, cryo_bottom_temp and + cryo_sheild_temp must be provided. cryo_bottom_temp(NX_NUMBER): + exists: optional unit: NX_TEMPERATURE - doc: Temperature of LHe helium cryostat. Temperature 2 (K) (e.g 4.92997E+0) + doc: | + Temperature of LHe helium cryostat. Temperature 2 (K) (e.g 4.92997E+0). Note: At + least one field from stm_head_temperature, cryo_bottom_temp and + cryo_sheild_temp must be provided. cryo_shield_temp(NX_NUMBER): + exists: optional unit: NX_TEMPERATURE - doc: Temperature of LN2 nitrogen shield. Temperature 3 (K) (e.g 78.00000E+0) + doc: | + Temperature of LN2 nitrogen shield. Temperature 3 (K) (e.g 78.00000E+0). Note: At + least one field from stm_head_temperature, cryo_bottom_temp and + cryo_sheild_temp must be provided. output_cabling(NXcircuit): # Cabling & Config #output_mode: @@ -102,17 +113,19 @@ NXiv_sweep2(NXsensor_scan): active_calib.: doc: The name of caliberation type. (e.g. LHe) calib._N(NX_NUMBER): - doc: N denotes X or Y or Z. There are 3 parameters in X, Y, and Z directions and there are 3 controls available: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. (e.g. 3.8E-9) + doc: | + N denotes X or Y or Z. There are 3 parameters in X, Y, and Z directions and there are 3 controls availables: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. (e.g. 3.8E-9) hv_gain_N(NX_NUMBER): doc: N denotes X or Y or Z. For some systems HV gain readout is available, so for those systems the HV gain should be adjusted automatically when the gain is changed at the high voltage amplifier. (e.g. 14.5) - tilt_N(NX_NUMBER): (e.g. 0.318343) - unit: NX_ANGLE - doc: N denotes X or Y. There are 2 parameters in X and Y directions and this tab is used to set the sample tilt (in degrees, first order correction). - curvature_radius N(NX_NUMBER): Inf - unit: NX_LENGTH - doc: N denotes X or Y. There are 2 parameters in X and Y directions and this tab is used to set a curvature (can be set approximately to the length of the piezotube). + tilt_N(NX_NUMBER): # (e.g. 0.318343) + unit: NX_ANGLE + doc: N denotes X or Y. There are 2 parameters in X and Y directions and this tab is used to set the sample tilt (in degrees, first order correction). + curvature_radius N(NX_NUMBER): # Inf + unit: NX_LENGTH + doc: N denotes X or Y. There are 2 parameters in X and Y directions and this tab is used to set a curvature (can be set approximately to the length of the piezotube). 2nd_order_corr_N(NX_NUMBER): - doc: N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2). (e.g. 0E+0) + doc: | + N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2). (e.g. 0E+0) drift_N(NX_NUMBER): doc: N denotes X or Y. There are 2 parameters in X and Y directions. Define the drift speed for all three axes. When the compensation is on, the piezos will start to move at that speed. (e.g. 0E+0) drift_correction_status(NX_BOOLEAN): @@ -124,6 +137,7 @@ NXiv_sweep2(NXsensor_scan): The temperature and voltage must be present as independently scanned controllers and the current sensor must also be present with its readings. voltage_controller(NXsensor): + exists: optional temperature_controller(NXsensor): current_sensor(NXsensor): position(NXpositioner): @@ -141,7 +155,7 @@ NXiv_sweep2(NXsensor_scan): unit: NX_LENGTH doc: Indicate the tip position Z between tip and sample. The tip position can also be varied when the controller is not running. (e.g. 130.5E-9) sweep_control(NXcollection): # parameters for a measurement at a single location during the scan - bias_spectroscopy(NXcollection)): + bias_spectroscopy(NXbias_spectroscopy): integration time(NX_NUMBER): unit: NX_TIME doc: Time during which the spectroscopy data are acquired and averaged. (e.g. 150E-6) @@ -177,6 +191,7 @@ NXiv_sweep2(NXsensor_scan): unit: NX_TIME doc: The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. (e.g. 500E-3) scan_control(NXcollection): # parameters how to change the location from measurement to measurement during the scan + exists: optional roi(NXtransformation): frame: doc: Also clarify the frame for the ROI of the scan (should depend on the lab frame) @@ -195,6 +210,7 @@ NXiv_sweep2(NXsensor_scan): speed_backw.(NX_NUMBER): doc: Define the scan backward speed in the forward direction. (m/s) (e.g. 11.7187E-9) resolution_indicators(NXprocess): # RESOLUTION (calculation input) + exists: optional temp_stm_head: #Temperature 1>link to INSTR/STM/head Temperature 1 (K) (e.g. 4.92997E+0) # Temperature of STM head. temp_cryo_bottom: #Temperature 2>link to Temperature 2 (K) - # Temperature of bottom of LHe helium cryostat. temp_cryo_shield: #Temperature 3>link to Temperature 3 (K) - # Temperature of LN2 nitrogen shield. @@ -212,6 +228,7 @@ NXiv_sweep2(NXsensor_scan): indicators_period: #link to SoftwareMain>Indicators Period (s) (e.g. 300E-3) # Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. measurement_period: #link to SoftwareMain>Measurements Period (s) (e.g. 500E-3) # The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. reproducibility_indicators(NXprocess): #REPRODUCIBILITY + exists: optional bias: # Bias>Bias(NXBias) (V) (e.g. 100E-3) # Applied bias voltage. current: # Current>Current(NXcircuit) (A) (e.g. -5.3429E-15) # The tunneling current is displayed here. bias_calibration: # Bias>Calibration(NXbias) (V/V) (e.g. 1E+0) # Calibration of the Bias output. If you have a Range switch the calibration is stored per range setting. @@ -281,6 +298,10 @@ NXiv_sweep2(NXsensor_scan): # y # z single_point(NXdata): # single point default plot # current(I) vs bias(V) + exists: optional line_scan(NXdata): # line scan default plot # multi I vs. V curves + exists: optional alternative_plot(NXdata): # alternative plot # current(I) curve in the 2D space of (position(x), bias(V)) + exists: optional mesh_scan(NXdata): # mesh scan default plot # 2D slices of the above alternative plot + exists: optional From 853bdeb26a05d71fd475fe6e5b2c55d7f383ce52 Mon Sep 17 00:00:00 2001 From: Rubel Date: Tue, 23 May 2023 13:16:05 +0200 Subject: [PATCH 0148/1012] Generating nxddl from nyaml for spm. --- contributed_definitions/NXamplifier.nxdl.xml | 91 ++++ .../NXbias_spectroscopy.nxdl.xml | 157 ++++++ contributed_definitions/NXcircuit.nxdl.xml | 136 +++++ contributed_definitions/NXiv_bias.nxdl.xml | 60 +++ contributed_definitions/NXiv_sweep2.nxdl.xml | 480 ++++++++++++++++++ contributed_definitions/NXlockin.nxdl.xml | 150 ++++++ contributed_definitions/NXpositioner.nxdl.xml | 223 ++++++++ contributed_definitions/NXsensor.nxdl.xml | 233 +++++++++ 8 files changed, 1530 insertions(+) create mode 100644 contributed_definitions/NXamplifier.nxdl.xml create mode 100644 contributed_definitions/NXbias_spectroscopy.nxdl.xml create mode 100644 contributed_definitions/NXcircuit.nxdl.xml create mode 100644 contributed_definitions/NXiv_bias.nxdl.xml create mode 100644 contributed_definitions/NXiv_sweep2.nxdl.xml create mode 100644 contributed_definitions/NXlockin.nxdl.xml create mode 100644 contributed_definitions/NXpositioner.nxdl.xml create mode 100644 contributed_definitions/NXsensor.nxdl.xml diff --git a/contributed_definitions/NXamplifier.nxdl.xml b/contributed_definitions/NXamplifier.nxdl.xml new file mode 100644 index 0000000000..c9b719a7b1 --- /dev/null +++ b/contributed_definitions/NXamplifier.nxdl.xml @@ -0,0 +1,91 @@ + + + + + + Base classed definition for amplifier devices. + + + + (IC, device) (NXmanufacturer?) + + + + + The number of preamplifier channels are assgined. + + + + + The number of preamplifier channels are ready tp to be used. (array for active + channels) + + + + + The output signal does not go through a feedback loop to adjust the + amplification of the amplifier. (array for active channels) + + + + + + The ratio of the amplitue of the useful signal to the amplitude of the noise in + the output signal of the amplifier. S/N=V_signal/V_noise. (array for active + channels) + + + + + (if active >1) + + + + + for reducing interferences between different signalling pathways + + + + + The spectrum of frequency it can amplify, from its lowest to highest frequency + limits. + + + + + Order and cut-off frequency of the low-pass filter applied on the demodulated + signals (X,Y). Cut-off frq (low pass filter) (foreach DemodulatorChannels) + + + + + Order and cut-off frequency of the high-pass filter applied on the demodulation + signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) + + + + diff --git a/contributed_definitions/NXbias_spectroscopy.nxdl.xml b/contributed_definitions/NXbias_spectroscopy.nxdl.xml new file mode 100644 index 0000000000..8be1269319 --- /dev/null +++ b/contributed_definitions/NXbias_spectroscopy.nxdl.xml @@ -0,0 +1,157 @@ + + + + + + Base classes definition for bias spectroscopy. + + Bias sweeps while measuring arbitrary channels with I(V) curves. + + + + Select the channels to record. + + + + + When selected, the Bias voltage returns to the initial value (before starting the sweep) at the end of the spectroscopy measurement (default). When not selected, Bias remains at the last value of the sweep. This is useful e.g. when combining several sweep segments. Example for an automated measurement (using Programming Interface): switch off Z-Controller, start spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, switch on Z-Controller. + + + + + Select whether to record the Z position during Z averaging time at the end of + the sweep (after Z control time) and store the average value in the header of + the file when saving. Using this option increases the sweep time by Z averaging + time. + + + + + Select whether to set the Lock-In to run during the measurement. When using this + feature, make sure the Lock-In is configured correctly and settling times are + set to twice the Lock-In period at least. This option is ignored when Lock-In is + already running. This option is disabled if the Sweep Mode is MLS and the flag + to configure the Lock-In per segment in the Multiline segment editor is set. + + + + + Time during which the spectroscopy data are acquired and averaged. + + + + + Number of sweeps to measure and average. + + + + + The first bias values of the sweep. + + + + + The last bias values of the sweep. + + + + + Define the sweep number of points, that is, the maximum spectrum resolution eq. + Bias window divide by Num Pixel. + + + + + Duration over which the Z position is recorded and averaged before and after the + sweep (the latter only if Record final Z position is selected in the Advanced + section). After the initial Z averaging time, if Z-Controller to Hold is + selected in the Advanced section, the Z-Controller is set to hold and the tip is + placed at the previously averaged Z position (plus Z offset). + + + + + Select a filter to smooth the displayed data. When saving, if any filter + selected, filtered data are saved to file along with the unfiltered data. + + + + + Filter order of a dynamic filter or width (in number of points) for the gaussian + filter. + + + + + Cutoff frequency for dynamic filters. + + + + + Offset added to the initial averaged position Zaver before starting to sweep. + This parameter is disabled when Z-Controller to Hold is deselected in the + Advanced section. The LED “Alt” next to the Z offset indicates if an alternate + Z-controller setpoint is enabled. + + + + + time to wait after changing the bias to the next level and before starting to + acquire data. + + + + + Time to wait after the sweep has finished and the bias is ramped to the initial + value. + + + + + Time during which the Z-Controller is enabled once a sweep has finished. When + averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled for this + duration between each sweep. After the last sweep, it will wait the specified + time before continuing a running scan. This ensures each sweep reliably starts + from the same position. This parameter is disabled when Z-Controller to Hold is + deselected in the Advanced section. + + + + + Maximum rate at which the bias changes (before, during and after sweeping). + (V/s) + + + + + Select whether to measure the backward (return) sweep or the forward only. + + + + + Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. + It is selected by default. When deselected, Z-offset and Z control time + parameters are disabled. + + + diff --git a/contributed_definitions/NXcircuit.nxdl.xml b/contributed_definitions/NXcircuit.nxdl.xml new file mode 100644 index 0000000000..150a78abe0 --- /dev/null +++ b/contributed_definitions/NXcircuit.nxdl.xml @@ -0,0 +1,136 @@ + + + + + + Application definition for circuit devices. + + + + Hardware type used in circuit, includes hardware manufacturers and type + + + + + The tunneling current between tip and sample after application of bias voltage. + + + + + Calibration of the current measurement (A/V). + + + + + Offset of the current measurement. + + + + + Proportional relationship between the probe output voltage and the actual + tunneling current when measuring the tunneling current. + + + + + The scan channels are selected by users (in scan contronaller). + + + + + The bandwitdh of the Hardware and/or Software + + + + + (Signals Periods) The Signals Period is the rate at which the signals are + transferred to the host computer running the control software. This is usually + lower by a factor of 10 than the sampling rate, because an internal oversampling + of the signal is done on the real time engine. You can reduce the oversampling + down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. + + + + + Update rate for several processes like History Graph, Auto-Approach, and for + many Programming Interface functions. This is usually set to 20 ms. All + additional timings (7-9) can only be integer multiples of this value. They can + be set to different values, but the actual timing value will be coerced to a + multiple of the Acquisition Period. + + + + + Update rate of animated graphical indicators. These are e.g. some graphs & + sliders. A reasonable value is 40 ms (25 updates per second). Increase this + period to reduce the processor load for the graphical user interface, especially + on slow computers. This value is purely a user interface update rate and does + not affect measurements in any way. + + + + + Update rate of digital indicators, e.g. the numbers displayed besides each + slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a + user interface update rate and does not affect measurements in any way. + + + + + The Measurements period is the integration time for precise measurements + (averaging over specified period), mostly used in sweep modules. Examples are + recording of a force-distance curve or a resonance of a cantilever. For fast + measurements with small steps, a value of 40 ms may be reasonable. For normal + use, 300-500 ms is a good value, but for recording a resonance of a high-Q + cantilever, values of several seconds might be necessary. Usually this parameter + doesn’t need to be set from this module; the sweep modules will set this value + according to the sweep timings. + + + + + Number of output channels + + + + + The user output in each monitor mode. + + + + + The values for each output channel. + + + + + User outputs whose name can be modified in the corresponding module. + + + + + The rate at which the one of the signal changes when ramping to the starting + point. (V/s) + + + diff --git a/contributed_definitions/NXiv_bias.nxdl.xml b/contributed_definitions/NXiv_bias.nxdl.xml new file mode 100644 index 0000000000..e766bc786c --- /dev/null +++ b/contributed_definitions/NXiv_bias.nxdl.xml @@ -0,0 +1,60 @@ + + + + + + Base classes definition for bias devices. + + + + Applied a voltage between tip and sample. + + + + + The ratio between the tunneling current at the sample surface and the bias + voltage applied between between the sample and the tip. + + + + + Calibration of the Bias output (V/V). + + + + + Allows compensating for an offset in Bias. Hardware parameter offset. + + + + + Sets the amplitude (in physical units of the modulated signal) of the sine + modulation. + + + + + Bias sweeps while measuring arbitrary channels with I(V) curves. + + + diff --git a/contributed_definitions/NXiv_sweep2.nxdl.xml b/contributed_definitions/NXiv_sweep2.nxdl.xml new file mode 100644 index 0000000000..d6454f3f81 --- /dev/null +++ b/contributed_definitions/NXiv_sweep2.nxdl.xml @@ -0,0 +1,480 @@ + + + + + + + Application definition for temperature-dependent IV curve measurements, #CAP with a focus on bias spectroscopy in scanning tunneling microscopy. + + In this application definition, times should be specified always together + with an UTC offset. + + This is the application definition describing temperature (T) dependent current voltage (IV) curve + measurements. For this a temperature is set. After reaching the temperature, + a voltage sweep is performed. For each voltage a current is measured. + Then, the next desired temperature is set and an IV measurement is performed. + #CAP the X, Y, Z, position of the probes or tip can be defined. #CAP The data can be visualized in a tensor with: + I (NXsensor_C, NXsoftware_Read_offset, NXcircuit) + parameters: + V has (NXsource+offset, NXsoftware_Scan_offset, NXsensor_V, NXcircuit) + T has (NXsource, NXsoftware_Scan_offset, NXsensor_T) + x has (NXsoftware_Scan_offset) + y has (NXsoftware_Scan_offset) + z has (NXsoftware_Scan_offset) + + + + + + + + + + The equipment and techniques as well as the parameter settings and reference + signals are used during the experiments used in the scanning tunneling + microscopy. + + + + + + + + + + The name of the output file, with the number of scans at the end.e.g. (e.g. + 221122_Au_5K00014) + + + + + The name of the series output file, which represents only the public part of the + output file. (e.g. 221122_Au_5K) + + + + + Path to storage of output files. (e.g. Path C:\Users\SPM- + PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis- + Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711) + + + + + Descriptive comments for this experiment, added by the experimenter, coming from + the output file. (e.g. Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, + locked Au(111), 50pA, 100 mV set point, 1mV DCA, 973Hz,138 1st H, -84 2nd H) + + + + + + + + + + + + + + + Temperature of STM head. Temperature 1 (K) (e.g. 4.92997E+0) + + + + + Temperature of LHe helium cryostat. Temperature 2 (K) (e.g 4.92997E+0) + + + + + Temperature of LN2 nitrogen shield. Temperature 3 (K) (e.g 78.00000E+0) + + + + + + + + The name of caliberation type. (e.g. LHe) + + + + + N denotes X or Y or Z. There are 3 parameters in X, Y, and Z directions and there are 3 controls availables: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. (e.g. 3.8E-9) + + + + + N denotes X or Y or Z. For some systems HV gain readout is available, so for + those systems the HV gain should be adjusted automatically when the gain is + changed at the high voltage amplifier. (e.g. 14.5) + + + + + N denotes X or Y. There are 2 parameters in X and Y directions and this tab is + used to set the sample tilt (in degrees, first order correction). + + + + + N denotes X or Y. There are 2 parameters in X and Y directions and this tab is + used to set a curvature (can be set approximately to the length of the + piezotube). + + + + + N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2). (e.g. 0E+0) + + + + + N denotes X or Y. There are 2 parameters in X and Y directions. Define the drift + speed for all three axes. When the compensation is on, the piezos will start to + move at that speed. (e.g. 0E+0) + + + + + Use the button to turn on/off the drift compensation. (e.g. FALSE) + + + + + + Describes an environment setup for a temperature-dependent IV measurement experiment. + + The temperature and voltage must be present as independently scanned controllers and + the current sensor must also be present with its readings. + + + + + + + Clarify the frame laboratory frame. + + + + The scanning area in x position in the frame. (e.g. -890.53E-12) + + + + + The scanning area in y position in the frame. (e.g. 29.6968E-9) + + + + + The scanning area in x position in the frame. (e.g. 130.5E-9) + + + + + Indicate the tip position Z between tip and sample. The tip position can also be + varied when the controller is not running. (e.g. 130.5E-9) + + + + + + + + Time during which the spectroscopy data are acquired and averaged. (e.g. 150E-6) + + + + + Number of sweeps to measure and average. (e.g. 100) + + + + + The first bias values of the sweep. (e.g. -300E-3) + + + + + The last bias values of the sweep. (e.g. 300E-3) + + + + + Define the sweep number of points, that is, the maximum spectrum resolution eq. + Bias window divide by Num Pixel. (e.g. 4096) + + + + + Duration over which the Z position is recorded and averaged before and after the + sweep (the latter only if Record final Z position is selected in the Advanced + section). After the initial Z averaging time, if Z-Controller to Hold is + selected in the Advanced section, the Z-Controller is set to hold and the tip is + placed at the previously averaged Z position (plus Z offset). (e.g. 100E-3) + + + + + + + The bandwitdh of the Hardware and/or Software (e.g. 20E+3) + + + + + (Signals Periods) The Signals Period is the rate at which the signals are + transferred to the host computer running the control software. This is usually + lower by a factor of 10 than the sampling rate, because an internal oversampling + of the signal is done on the real time engine. You can reduce the oversampling + down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. (e.g. + 10) + + + + + Update rate for several processes like History Graph, Auto-Approach, and for + many Programming Interface functions. This is usually set to 20 ms. All + additional timings (7-9) can only be integer multiples of this value. They can + be set to different values, but the actual timing value will be coerced to a + multiple of the Acquisition Period. (e.g. 20E-3) + + + + + Update rate of animated graphical indicators. These are e.g. some graphs & + sliders. A reasonable value is 40 ms (25 updates per second). Increase this + period to reduce the processor load for the graphical user interface, especially + on slow computers. This value is purely a user interface update rate and does + not affect measurements in any way. (e.g. 20E-3) + + + + + Update rate of digital indicators, e.g. the numbers displayed besides each + slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a + user interface update rate and does not affect measurements in any way. (e.g. + 300E-3) + + + + + The Measurements period is the integration time for precise measurements + (averaging over specified period), mostly used in sweep modules. Examples are + recording of a force-distance curve or a resonance of a cantilever. For fast + measurements with small steps, a value of 40 ms may be reasonable. For normal + use, 300-500 ms is a good value, but for recording a resonance of a high-Q + cantilever, values of several seconds might be necessary. Usually this parameter + doesn’t need to be set from this module; the sweep modules will set this value + according to the sweep timings. (e.g. 500E-3) + + + + + + + + + Also clarify the frame for the ROI of the scan (should depend on the lab frame) + + + + + + + The scan channels are selected by users. (e.g. (A);Bias (V);Z (m);LI Demod 2 X + (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A)) + + + + + + + Configure the scan frame like x position; y position; width; height. (e.g. + 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0) + + + + + Scan resolution by setting the Lines equal to Pixels. (e.g. 512) + + + + + Define the image resolution. (e.g. 512) + + + + + Define the scan forward speed in the forward direction. (m/s) (e.g. 11.7187E-9) + + + + + Define the scan backward speed in the forward direction. (m/s) (e.g. 11.7187E-9) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. + There should also be two more fields called temperature and voltage containing the setpoint values. + There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension + equal to the number of voltage setpoints. + axes: bias_calc + signals: + li_demod_[1;2]_[X/Y]_[-;bwd;filt;bwd_filt] + current_[-;bwd;filt;bwd_filt] + temperature + x + y + z + + + + + + + + + diff --git a/contributed_definitions/NXlockin.nxdl.xml b/contributed_definitions/NXlockin.nxdl.xml new file mode 100644 index 0000000000..1b4c4f2a82 --- /dev/null +++ b/contributed_definitions/NXlockin.nxdl.xml @@ -0,0 +1,150 @@ + + + + + + Base classes definition for lock in devices. + + + + Hardware manufacturers and type of lockin amplifier. + + + + + By mixing the input signal (STS signal) with the modulated signal (such as Bias) + and comparing it with the reference signal, they are enhanced and the effects of + noise interference are reduced, resulting in more accurate measurements. + + + + + if Lock-in -- Bias Divider 1/10 or 1/100, Bias divider = + V(ref)/[V(ref)+V(input)] + + + + + Switch the lock-in moulation on or off. + + + + + A modulation signal (such as bias, current et.al.) is a periodic voltage signal, + usually applied to the surface of a sample, which serves to modify the physical + properties of the sample surface and generate weak AC current signals that can + be detected and analysed by instruments such as lock-in amplifiers. + + + + + Sets the amplitude (in physical units of the modulated signal) of the sine + modulation. + + + + + Sets the frequency of the sine modulation added to the signal to modulate. + + + + + The input signal (STS signal) will be demodulated, in order to determine the + amplitude and phase at the frequency set in the Frequency field or harmonics, + such as current, bias, et.al. + + + + + + The number of signals which will be demodulated. + + + + + Order and cut-off frequency of the low-pass filter applied on the demodulated + signals (X,Y). Cut-off frq (low pass filter) (foreach DemodulatorChannels) + + + + + Order and cut-off frequency of the high-pass filter applied on the demodulation + signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) + + + + + Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) + value) for D1. The filter is applied to the demodulated signals (X,Y). + + + + + Order and cut-off frequency of the low-pass filter applied on the demodulated + signals (X,Y). Reducing the bandwidth or increasing the order reduces noise on + the demodulated signals, but will require longer settling and measurement times. + + + + + Sets the cut-off frequency of the high-pass filter (affects the displayed TC (s) + value) for D1. The filter is applied to the demodulated signals (X,Y). + + + + + Order and cut-off frequency of the high-pass filter applied on the demodulation + signal of D!. This is used mainly to suppress a DC component of the demodulation + signal, which would lead to a component at modulation frequency in the + demodulated signals. + + + + + Switch on/off the Sync filter on the demodulated signals (X,Y) on or off. + (foreach DemodulatorChannels) + + + + + Reference phase for the sine on the demodulated signal with respect to the + modulation signal. (foreach DemodulatorChannels) + + + + + Time during which the data are acquired and averaged. (for the input filter) + + + + + The order of the harmonic oscillation to detect on the demodulated signals. + (with respect to the modulation frequency) + + + + + Ratio of output signal amplitude to input signal amplitue (V/V). (input gain) + + + diff --git a/contributed_definitions/NXpositioner.nxdl.xml b/contributed_definitions/NXpositioner.nxdl.xml new file mode 100644 index 0000000000..094f5611b0 --- /dev/null +++ b/contributed_definitions/NXpositioner.nxdl.xml @@ -0,0 +1,223 @@ + + + + + + A generic positioner such as a motor or piezo-electric transducer. + + + + symbolic or mnemonic name (one word) + + + + + description of positioner + + + + + best known value of positioner - need [n] as may be scanned + + + + + + + + raw value of positioner - need [n] as may be scanned + + + + + + + + targeted (commanded) value of positioner - need [n] as may be scanned + + + + + + + + maximum allowable difference between target_value and value + + + + + + + + minimum allowed limit to set value + + + + + maximum allowed limit to set value + + + + + velocity of the positioner (distance moved per unit time) + + + + + time to ramp the velocity up to full speed + + + + + Hardware device record, e.g. EPICS process variable, taco/tango ... + + + + + .. index':'':' plotting + + Declares which child group contains a path leading + to a ':'ref':'`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https':'//www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + + + + + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo':'':' + Add a definition for the reference point of a positioner. + + + + + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. + + + + + To clarify the frame laboratory frame. The scanning area in x, y, and z position + in the frame. + + + + + + Offset added to the initial averaged position Zaver before starting to swepp. + + + + + Indicate the tip position Z between tip and sample. The tip position can also be + varied when the controller is not running. + + + + + Controller name. This name which will be displayed at places where you can + select a controller. + + + + + Set Point is the desired value of the control signal. It can be set by editing + the number or using the slider bar. Click the "Set" button above the input field + to use the actual value as Set Point. The slider shows the Set Point as well as + the current value. + + + + + + Lifts the tip by the specified amount when then controller is switched off. This + can be a positive or a negative number, i.e. the tip can also be moved towards + the sample. Be careful with sign and value when using this feature. + + + + + Use this parameter for a reproducible position when switching off the + Z-controller. When >0 and the Z-controller is switched off, it doesn't switch + off immediately but continues to run for the specified time and averages the Z + position. + + + + + (In bias spectroscopy) Select whether to set the Z-Controller on hold (i.e. + disabled) during the sweep. It is selected by default. When deselected, Z-offset + and Z control time parameters are disabled. + + + + + The final z-position during the bias spectroscopy scan. The availability of + values is related to the mode of scanning. + + + + + To contron the tip and various scan operations. + + + + + Configure the scan frame like x position; y position; width; height. + + + + + Scan resolution by setting the Lines equal to Pixels. + + + + + Define the image resolution. + + + + + Define the scan forward speed in the forward direction. + + + + + Define the scan backward speed in the forward direction. + + + diff --git a/contributed_definitions/NXsensor.nxdl.xml b/contributed_definitions/NXsensor.nxdl.xml new file mode 100644 index 0000000000..f2d3b01227 --- /dev/null +++ b/contributed_definitions/NXsensor.nxdl.xml @@ -0,0 +1,233 @@ + + + + + + A sensor used to monitor an external condition + + The condition itself is described in ':'ref':'`NXenvironment`. + + + + Sensor identification code/model number + + + + + Name for the sensor + + + + + Short name of sensor used e.g. on monitor display program + + + + + where sensor is attached to ("sample" | "can") + + + + + Defines the axes for logged vector quantities if they are not the global instrument axes. + + + + + name for measured signal + + + + + + + + + + + + + + + + + + + + + The type of hardware used for the measurement. + Examples (suggestions but not restrictions)':' + + ':'Temperature':' + J | K | T | E | R | S | Pt100 | Pt1000 | Rh/Fe + ':'pH':' + Hg/Hg2Cl2 | Ag/AgCl | ISFET + ':'Ion selective electrode':' + specify species; e.g. Ca2+ + ':'Magnetic field':' + Hall + ':'Surface pressure':' + wilhelmy plate + + + + + + link to second amplifer circuit with 1MOhm + + + + + Is data collection controlled or synchronised to this quantity':' + 1=no, 0=to "value", 1=to "value_deriv1", etc. + + + + + Upper control bound of sensor reading if using run_control + + + + + Lower control bound of sensor reading if using run_control + + + + + nominal setpoint or average value + - need [n] as may be a vector + + + + + + + + Nominal/average first derivative of value + e.g. strain rate + - same dimensions as "value" (may be a vector) + + + + + + + + Nominal/average second derivative of value + - same dimensions as "value" (may be a vector) + + + + + + + + Time history of sensor readings + + + + + Time history of first derivative of sensor readings + + + + + Time history of second derivative of sensor readings + + + + + + + + + + + + + + + For complex external fields not satisfied by External_field_brief + + + + + This group describes the shape of the sensor when necessary. + + + + + .. index':'':' plotting + + Declares which child group contains a path leading + to a ':'ref':'`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https':'//www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + + + + + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo':'':' + Add a definition for the reference point of a sensor. + + + + + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. + + + + + + External sensors connected to the device. For example, T1, temperature of STM + head. T2, temperature of bottom of LHe helium cryostat. T3, temperature of LN2 + nitrogen shield. + + + + + External sensors connected to the device. Pressure of each chamber or ion pump, + such as prepare chamber and analysis chamber + + + + + The power present in the signal as a function of frequency. Used to characterise + the vibration and noise of scanning probes to detect and reduce the impact on + resolution during STM imaging + + + From a32a94ac204b5a5c91292ffaaa24dcf424148ea4 Mon Sep 17 00:00:00 2001 From: Rubel Date: Wed, 24 May 2023 08:45:55 +0200 Subject: [PATCH 0149/1012] Fixing some typo and bug in NXiv_sweep2. --- .../nyaml/NXiv_sweep2.yaml | 257 +++++++++++++----- 1 file changed, 182 insertions(+), 75 deletions(-) diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index c9f9ff9f49..13b855741d 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -34,13 +34,14 @@ NXiv_sweep2(NXsensor_scan): doc: Descriptive comments for this experiment, added by the experimenter, coming from the output file. (e.g. Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, locked Au(111), 50pA, 100 mV set point, 1mV DCA, 973Hz,138 1st H, -84 2nd H) (NXinstrument): hardware(NXfabrication): - software(NXfabrication): # any or specifique 'harware' and 'software'? - # doc: | - # Software and hardware for control, scanning and data collection in the SPM system - # hardware: - # doc: Hardware type used in SPM experiment, includes hardware manufacturers and type. (e.g. Nanonis BP5e) - # softwareMain>Software: - # doc: Type of software used in SPM experiments, e.g. software version serial number, UI and RT probe release method. (e.g. SW Version Generic 5e -- SoftwareMain>UI Release 10771 -- SoftwareMain>RT Release 10771) + # any or specifique 'harware' and 'software'? + software(NXfabrication): + # doc: | + # Software and hardware for control, scanning and data collection in the SPM system + # hardware: + # doc: Hardware type used in SPM experiment, includes hardware manufacturers and type. (e.g. Nanonis BP5e) + # softwareMain>Software: + # doc: Type of software used in SPM experiments, e.g. software version serial number, UI and RT probe release method. (e.g. SW Version Generic 5e -- SoftwareMain>UI Release 10771 -- SoftwareMain>RT Release 10771) current_amplifier(NXamplifier): # hardware: Current amplifier> hardware: CreaTec GmbH # amplification: Current amplifier> factor (V/V): 1E-10 @@ -71,13 +72,13 @@ NXiv_sweep2(NXsensor_scan): #run: # doc: Bias Spectroscopy>Lock-In run FALSE # Select whether to set the Lock-In to run during the measurement. When using this feature, make sure the Lock-In is configured correctly and settling times are set to twice the Lock-In period at least. This option is ignored when Lock-In is already running. This option is disabled if the Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline segment editor is set. sample_bias(NXiv_bias): - #sample_bias(NXbias): - # Tip bias/Sample bias # If the spectroscopy V bias is applied to the - # Modulated signal Bias (V) 1E-3 # Applied modulation to the bias voltage. + # sample_bias(NXbias): + # Tip bias/Sample bias If the spectroscopy V bias is applied to the + # Modulated signal Bias (V) 1E-3 Applied modulation to the bias voltage. # ModulationBias> Tip bias/Sample bias # modulated_signal_bias(NX_NUMBER): - # unit: NX_VOLTAGE - # doc: Same directional representation as bias. (e.g. 1E-3) + # unit: NX_VOLTAGE + # doc: Same directional representation as bias. (e.g. 1E-3) stm_head_temp(NX_NUMBER): exists: optional unit: NX_TEMPERATURE @@ -101,14 +102,14 @@ NXiv_sweep2(NXsensor_scan): cryo_sheild_temp must be provided. output_cabling(NXcircuit): # Cabling & Config - #output_mode: - # doc: Number of output channels. (e.g. User Output) - #output_value(NX_NUMBER): - # doc: The user output in each monitor mode. (e.g. 0E+0) - #output_name: - # doc: User outputs whose name can be modified in the corresponding module. (e.g. Input 24 (V)) - #output_slew_rate(NX_NUMBER): - # doc: The rate at which the one of the signal changes when ramping to the starting point. (V/s) (e.g. Inf) + # output_mode: + # doc: Number of output channels. (e.g. User Output) + # output_value(NX_NUMBER): + # doc: The user output in each monitor mode. (e.g. 0E+0) + # output_name: + # doc: User outputs whose name can be modified in the corresponding module. (e.g. Input 24 (V)) + # output_slew_rate(NX_NUMBER): + # doc: The rate at which the one of the signal changes when ramping to the starting point. (V/s) (e.g. Inf) piezo_config(NXcollection): active_calib.: doc: The name of caliberation type. (e.g. LHe) @@ -117,10 +118,12 @@ NXiv_sweep2(NXsensor_scan): N denotes X or Y or Z. There are 3 parameters in X, Y, and Z directions and there are 3 controls availables: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. (e.g. 3.8E-9) hv_gain_N(NX_NUMBER): doc: N denotes X or Y or Z. For some systems HV gain readout is available, so for those systems the HV gain should be adjusted automatically when the gain is changed at the high voltage amplifier. (e.g. 14.5) - tilt_N(NX_NUMBER): # (e.g. 0.318343) + # (e.g. 0.318343) + tilt_N(NX_NUMBER): unit: NX_ANGLE doc: N denotes X or Y. There are 2 parameters in X and Y directions and this tab is used to set the sample tilt (in degrees, first order correction). - curvature_radius N(NX_NUMBER): # Inf + # Inf + curvature_radius N(NX_NUMBER): unit: NX_LENGTH doc: N denotes X or Y. There are 2 parameters in X and Y directions and this tab is used to set a curvature (can be set approximately to the length of the piezotube). 2nd_order_corr_N(NX_NUMBER): @@ -151,10 +154,11 @@ NXiv_sweep2(NXsensor_scan): z(NX_NUMBER): unit: NX_LENGTH doc: The scanning area in x position in the frame. (e.g. 130.5E-9) - z-controller(NB_NUMBER): + z-controller(NX_NUMBER): unit: NX_LENGTH doc: Indicate the tip position Z between tip and sample. The tip position can also be varied when the controller is not running. (e.g. 130.5E-9) - sweep_control(NXcollection): # parameters for a measurement at a single location during the scan + # parameters for a measurement at a single location during the scan + sweep_control(NXcollection): bias_spectroscopy(NXbias_spectroscopy): integration time(NX_NUMBER): unit: NX_TIME @@ -190,9 +194,10 @@ NXiv_sweep2(NXsensor_scan): measurements_period (NX_NUMBER): unit: NX_TIME doc: The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. (e.g. 500E-3) - scan_control(NXcollection): # parameters how to change the location from measurement to measurement during the scan + # parameters how to change the location from measurement to measurement during the scan + scan_control(NXcollection): exists: optional - roi(NXtransformation): + roi(NXtransformations): frame: doc: Also clarify the frame for the ROI of the scan (should depend on the lab frame) circuit(NXcollection): @@ -209,53 +214,151 @@ NXiv_sweep2(NXsensor_scan): doc: Define the scan forward speed in the forward direction. (m/s) (e.g. 11.7187E-9) speed_backw.(NX_NUMBER): doc: Define the scan backward speed in the forward direction. (m/s) (e.g. 11.7187E-9) - resolution_indicators(NXprocess): # RESOLUTION (calculation input) + # RESOLUTION (calculation input) + resolution_indicators(NXprocess): exists: optional - temp_stm_head: #Temperature 1>link to INSTR/STM/head Temperature 1 (K) (e.g. 4.92997E+0) # Temperature of STM head. - temp_cryo_bottom: #Temperature 2>link to Temperature 2 (K) - # Temperature of bottom of LHe helium cryostat. - temp_cryo_shield: #Temperature 3>link to Temperature 3 (K) - # Temperature of LN2 nitrogen shield. - modulated_signal_bias: #Lock-in>link to Modulated signal Bias (V) (e.g. 1E-3) # Applied modulation to the bias voltage. - integration_time: #link to Integration time (s) (e.g. 150E-6) # Time during which the spectroscopy data are acquired and averaged. - number_of_sweps: #link to Bias Spectroscopy>Number of sweeps (e.g. 100) # Number of sweeps to measure and average. - sweep_start: #link to Bias Spectroscopy>Sweep Start (V) (e.g. -300E-3) # The first bias values of the sweep. - sweep_end: #link to Bias Spectroscopy>Sweep End (V) (e.g. 300E-3) # The last bias values of the sweep. - number_of_pixels: #link to Bias Spectroscopy>Num Pixel (e.g. 4096) # Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. - z_avg_time: #link to Bias Spectroscopy>Z Avg time (s) (e.g. 100E-3) # Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). - rt_freq: #link to SoftwareMain>RT Frequency (Hz) (e.g. 20E+3) # The bandwitdh of the Hardware and/or Software - oversampling: #link to SoftwareMain>Signals Oversampling (e.g. 10) # (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. - acquisition_period: #link to SoftwareMain>Acquisition Period (s) (e.g. 20E-3) # Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. - animation_period: #link to SoftwareMain>Animations Period (s) (e.g. 20E-3) # Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. - indicators_period: #link to SoftwareMain>Indicators Period (s) (e.g. 300E-3) # Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. - measurement_period: #link to SoftwareMain>Measurements Period (s) (e.g. 500E-3) # The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. - reproducibility_indicators(NXprocess): #REPRODUCIBILITY + # Temperature 1>link to INSTR/STM/head Temperature 1 (K) (e.g. 4.92997E+0) # Temperature of STM head. + temp_stm_head: + # Temperature 2>link to Temperature 2 (K) - # Temperature of bottom of LHe helium cryostat. + temp_cryo_bottom: + # Temperature 3>link to Temperature 3 (K) - # Temperature of LN2 nitrogen shield. + temp_cryo_shield: + # Lock-in>link to Modulated signal Bias (V) (e.g. 1E-3) # Applied modulation to the bias voltage. + modulated_signal_bias: + # link to Integration time (s) (e.g. 150E-6) # Time during which the spectroscopy data are acquired and averaged. + integration_time: + # link to Bias Spectroscopy>Number of sweeps (e.g. 100) # Number of sweeps to measure and average. + number_of_sweps: + # link to Bias Spectroscopy>Sweep Start (V) (e.g. -300E-3) # The first bias values of the sweep. + sweep_start: + # link to Bias Spectroscopy>Sweep End (V) (e.g. 300E-3) # The last bias values of the sweep. + sweep_end: + # link to Bias Spectroscopy>Num Pixel (e.g. 4096) # Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. + number_of_pixels: + # link to Bias Spectroscopy>Z Avg time (s) (e.g. 100E-3) # Duration over which the Z + # position is recorded and averaged before and after the sweep (the latter only if Record + # final Z position is selected in the Advanced section). After the initial Z averaging + # time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is + # set to hold and the tip is placed at the previously averaged Z position (plus Z offset). + z_avg_time: + # link to SoftwareMain>RT Frequency (Hz) (e.g. 20E+3) # The bandwitdh of the + # Hardware and/or Software + rt_freq: + # link to SoftwareMain>Signals Oversampling (e.g. 10) # (Signals Periods) + # The Signals Period is the rate at which the signals are transferred to the host computer + # running the control software. This is usually lower by a factor of 10 than the sampling + # rate, because an internal oversampling of the signal is done on the real time engine. + # You can reduce the oversampling down to 1 in order to resolve higher frequencies in the + # Spectrum Analyzer. + oversampling: + # link to SoftwareMain>Acquisition Period (s) (e.g. 20E-3) # Update rate for several + # processes like History Graph, Auto-Approach, and for many Programming Interface functions. + # This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples + # of this value. They can be set to different values, but the actual timing value will be + # coerced to a multiple of the Acquisition Period. + acquisition_period: + # link to SoftwareMain>Animations Period (s) (e.g. 20E-3) # Update rate of animated + # graphical indicators. These are e.g. some graphs & sliders. A reasonable value is + # 40 ms (25 updates per second). Increase this period to reduce the processor load + # for the graphical user interface, especially on slow computers. This value is purely a + # user interface update rate and does not affect measurements in any way. + animation_period: + # link to SoftwareMain>Indicators Period (s) (e.g. 300E-3) # Update rate of digital + # indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per + # second, or 300 ms is enough. This value is purely a user interface update rate and + # does not affect measurements in any way. + indicators_period: + # link to SoftwareMain>Measurements Period (s) (e.g. 500E-3) # The Measurements + # period is the integration time for precise measurements (averaging over specified period), + # mostly used in sweep modules. Examples are recording of a force-distance curve or a + # resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be + # reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a + # high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. + measurement_period: + # REPRODUCIBILITY + reproducibility_indicators(NXprocess): exists: optional - bias: # Bias>Bias(NXBias) (V) (e.g. 100E-3) # Applied bias voltage. - current: # Current>Current(NXcircuit) (A) (e.g. -5.3429E-15) # The tunneling current is displayed here. - bias_calibration: # Bias>Calibration(NXbias) (V/V) (e.g. 1E+0) # Calibration of the Bias output. If you have a Range switch the calibration is stored per range setting. - bias_offset: # Bias>Offset(NXbias) (V) (e.g. 0E+0) # Allows compensating for an offset in Bias. - current_calibration: # Current>Calibration(NXcircuit) (A/V) (e.g. 100E-12) # The signals voltages are converted to real world physical values according to the calibration & offset parameters: Physical signal = (Voltage * calibration) + offset. - current_offset: # Current>Offset(NXcircuit) (A) (e.g. 16.2897E-15) # The same as "Current>Calibration (A/V)" tag - current_gain: # Current>Gain(NXcircuit) (e.g. Not switchable) # None - z_offset: # Z offset(NXpositioner) (m) (e.g. 0E+0) # Offset added to the initial averaged position Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an alternate Z-controller setpoint is enabled. - settling_time: # Settling time(NXbias) (s) (e.g. 2.1E-3) # Time to wait after changing the bias to the next level and before starting to acquire data. Adjust this parameter to avoid transient effect induced by the bias change. Integration time: time during which the data are acquired and averaged. - z_control_hold: # Z-Ctrl hold(NXpositioner) (e.g. TRUE) # When selected, the Z-Controller is set to hold during the pulse. This means that the controller doesn't control the Z position during the pulse. - final_z: # Final Z(NXpositioner) (m) (e.g. N/A) - start_time: # Start time(NXlog) (e.g.23.11.2022 18:55:16) # Timestamp of the moment when the acquisition starts by pressing the Start button. - 1st_settling_time: # Bias Spectroscopy>1st Settling time(NXbias) (s) (e.g.2.1E-3) # See the "Settling time (s)" below. - integration_time: # Bias Spectroscopy>Integration time(NXbias) (s) (e.g.150E-6) # Time during which the data are acquired and averaged. - end_settling_time: # Bias Spectroscopy>End Settling time(NXbias) (s) (e.g.4E-3) # Time to wait after the sweep has finished and the bias is ramped to the initial value. - z_contro_time: # Bias Spectroscopy>Z control time(NXbias) (s) (e.g.200E-3) # Time during which the Z-Controller is enabled once a sweep has finished. When averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled for this duration between each sweep. After the last sweep, it will wait the specified time before continuing a running scan. This ensures each sweep reliably starts from the same position. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. - max_slew_rate: # Bias Spectroscopy>Max Slew rate(NXbias) (V/s) (e.g.1E+0) # Maximum rate at which the bias changes (before, during and after sweeping). - backward_sweep: # Bias Spectroscopy>backward sweep(NXbias) (e.g.TRUE) # Select whether to measure the backward (return) sweep or the forward only. - z_control_name: # Z-Controller>Controller name(NXpositioner) (e.g.log Current) # Controller name. This name which will be displayed at places where you can select a controller. - z_control_status: # Z-Controller>Controller status(NXpositioner) (e.g.OFF) # ON/OFF - z_sontrol_setpoint: # Z-Controller>Setpoint(NXpositioner) (e.g.50E-12) # Set Point is the desired value of the control signal. It can be set by editing the number or using the slider bar. Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. - # Z-Controller>Setpoint unit(NXpositioner) (e.g.A) # Angstrom - z_control_p_gain: # Z-Controller>P gain(NXpid) (e.g.6E-12) # The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. - z_control_i_gain: # Z-Controller>I gain(NXpid) (e.g.39.8241E-9) # See "Z-Controller>P gain" below. - z_control_time_const: # Z-Controller>Time const(NXpid) (s) (e.g.150.662E-6) # See "Z-Controller>P gain" below. - z_control_tip_lift: # Z-Controller>TipLift(NXpositioner) (m) (e.g.0E+0) # Lifts the tip by the specified amount when then controller is switched off. This can be a positive or a negative number, i.e. the tip can also be moved towards the sample. Be careful with sign and value when using this feature. - z_control_switchoff_delay: # Z-Controller>Switch off delay(NXpositioner) (s) (e.g.0E+0) # Use this parameter for a reproducible position when switching off the Z-controller. When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. + # Bias>Bias(NXBias) (V) (e.g. 100E-3) # Applied bias voltage. + bias: + # Current>Current(NXcircuit) (A) (e.g. -5.3429E-15) # The tunneling current is displayed here. + current: + # Bias>Calibration(NXbias) (V/V) (e.g. 1E+0) Calibration of the Bias output. If you have a Range switch the calibration is stored per range setting. + bias_calibration: + # Bias>Offset(NXbias) (V) (e.g. 0E+0) Allows compensating for an offset in Bias. + bias_offset: + # Current>Calibration(NXcircuit) (A/V) (e.g. 100E-12) + # The signals voltages are converted to real world physical values according to the calibration & offset parameters: + # Physical signal = (Voltage * calibration) + offset. + current_calibration: + # Current>Offset(NXcircuit) (A) (e.g. 16.2897E-15) # The same as "Current>Calibration (A/V)" tag + current_offset: + # Current>Gain(NXcircuit) (e.g. Not switchable) # None + current_gain: + # Z offset(NXpositioner) (m) (e.g. 0E+0) # Offset added to the initial averaged position + # Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is + # deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an + # alternate Z-controller setpoint is enabled. + z_offset: + # Settling time(NXbias) (s) (e.g. 2.1E-3) Time to wait after changing the bias to the next + # level and before starting to acquire data. Adjust this parameter to avoid transient + # effect induced by the bias change. Integration time: time during which the data are + # acquired and averaged. + settling_time: + # Z-Ctrl hold(NXpositioner) (e.g. TRUE) # When selected, the Z-Controller is set to hold + # during the pulse. This means that the controller doesn't control the Z position during the pulse. + z_control_hold: + # Final Z(NXpositioner) (m) (e.g. N/A) + final_z: + # Start time(NXlog) (e.g.23.11.2022 18:55:16) # Timestamp of the moment when the acquisition starts by pressing the Start button. + start_time: + # Bias Spectroscopy>1st Settling time(NXbias) (s) (e.g.2.1E-3) # See the "Settling time (s)" below. + 1st_settling_time: + # Bias Spectroscopy>Integration time(NXbias) (s) (e.g.150E-6) # Time during which the data + # are acquired and averaged. + integration_time: + # Bias Spectroscopy>End Settling time(NXbias) (s) (e.g.4E-3) # Time to wait after the sweep has finished and the bias is ramped to the initial value. + end_settling_time: + # Bias Spectroscopy>Z control time(NXbias) (s) (e.g.200E-3) # Time during which the + # Z-Controller is enabled once a sweep has finished. When averaging multiple sweeps + # (i.e. Sweeps>1), the Z-Controller is enabled for this duration between each sweep. + # After the last sweep, it will wait the specified time before continuing a running scan. + # This ensures each sweep reliably starts from the same position. This parameter is + # disabled when Z-Controller to Hold is deselected in the Advanced section. + z_contro_time: + # Bias Spectroscopy>Max Slew rate(NXbias) (V/s) (e.g.1E+0) # Maximum rate at which + # the bias changes (before, during and after sweeping). + max_slew_rate: + # Bias Spectroscopy>backward sweep(NXbias) (e.g.TRUE) # Select whether to measure + # the backward (return) sweep or the forward only. + backward_sweep: + # Z-Controller>Controller name(NXpositioner) (e.g.log Current) # Controller name. + # This name which will be displayed at places where you can select a controller. + z_control_name: + # Z-Controller>Controller status(NXpositioner) (e.g.OFF) # ON/OFF + z_control_status: + # Z-Controller>Setpoint(NXpositioner) (e.g.50E-12) # Set Point is the desired value + # of the control signal. It can be set by editing the number or using the slider bar. + # Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. + # Z-Controller>Setpoint unit(NXpositioner) (e.g.A) # Angstrom + z_sontrol_setpoint: + # Z-Controller>P gain(NXpid) (e.g.6E-12) # The Type switches controller parameters + # between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). + # The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). + # The integral gain and time constant are related as follows: I = P/T. + z_control_p_gain: + # Z-Controller>I gain(NXpid) (e.g.39.8241E-9) # See "Z-Controller>P gain" below. + z_control_i_gain: + # Z-Controller>Time const(NXpid) (s) (e.g.150.662E-6) # See "Z-Controller>P gain" below. + z_control_time_const: + # Z-Controller>TipLift(NXpositioner) (m) (e.g.0E+0) # Lifts the tip by the specified + # amount when then controller is switched off. This can be a positive or a negative number, + # i.e. the tip can also be moved towards the sample. Be careful with sign and value when + # using this feature. + z_control_tip_lift: + # Z-Controller>Switch off delay(NXpositioner) (s) (e.g.0E+0) # Use this parameter for + # a reproducible position when switching off the Z-controller. When >0 and the Z-controller + # is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. + z_control_switchoff_delay: data(NXdata): doc: | This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. @@ -297,11 +400,15 @@ NXiv_sweep2(NXsensor_scan): # x # y # z - single_point(NXdata): # single point default plot # current(I) vs bias(V) + # single point default plot # current(I) vs bias(V) + single_point(NXdata): exists: optional - line_scan(NXdata): # line scan default plot # multi I vs. V curves + # line scan default plot # multi I vs. V curves + line_scan(NXdata): exists: optional - alternative_plot(NXdata): # alternative plot # current(I) curve in the 2D space of (position(x), bias(V)) + # alternative plot # current(I) curve in the 2D space of (position(x), bias(V)) + alternative_plot(NXdata): exists: optional - mesh_scan(NXdata): # mesh scan default plot # 2D slices of the above alternative plot + # mesh scan default plot # 2D slices of the above alternative plot + mesh_scan(NXdata): exists: optional From 79c5ce5481610b623103c4017df055f0f6a4a934 Mon Sep 17 00:00:00 2001 From: Rubel Date: Wed, 24 May 2023 08:53:23 +0200 Subject: [PATCH 0150/1012] update NXiv_sweep2.nxdl.xml according to the change in yaml. --- contributed_definitions/NXiv_sweep2.nxdl.xml | 183 +++++++++++++++---- 1 file changed, 148 insertions(+), 35 deletions(-) diff --git a/contributed_definitions/NXiv_sweep2.nxdl.xml b/contributed_definitions/NXiv_sweep2.nxdl.xml index d6454f3f81..d65027fc41 100644 --- a/contributed_definitions/NXiv_sweep2.nxdl.xml +++ b/contributed_definitions/NXiv_sweep2.nxdl.xml @@ -88,13 +88,14 @@ + - + - +unit: NX_VOLTAGE +doc: Same directional representation as bias. (e.g. 1E-3)--> + - Temperature of STM head. Temperature 1 (K) (e.g. 4.92997E+0) + Temperature of STM head. Temperature 1 (K) (e.g. 4.92997E+0). Note: At least + one field from stm_head_temperature, cryo_bottom_temp and + cryo_sheild_temp must be provided. - + - Temperature of LHe helium cryostat. Temperature 2 (K) (e.g 4.92997E+0) + Temperature of LHe helium cryostat. Temperature 2 (K) (e.g 4.92997E+0). Note: At + least one field from stm_head_temperature, cryo_bottom_temp and + cryo_sheild_temp must be provided. - + - Temperature of LN2 nitrogen shield. Temperature 3 (K) (e.g 78.00000E+0) + Temperature of LN2 nitrogen shield. Temperature 3 (K) (e.g 78.00000E+0). Note: At + least one field from stm_head_temperature, cryo_bottom_temp and + cryo_sheild_temp must be provided. +doc: The rate at which the one of the signal changes when ramping to the starting point. (V/s) (e.g. Inf)--> @@ -174,12 +181,14 @@ output_slew_rate(NX_NUMBER): changed at the high voltage amplifier. (e.g. 14.5) + N denotes X or Y. There are 2 parameters in X and Y directions and this tab is used to set the sample tilt (in degrees, first order correction). + N denotes X or Y. There are 2 parameters in X and Y directions and this tab is @@ -212,7 +221,7 @@ output_slew_rate(NX_NUMBER): The temperature and voltage must be present as independently scanned controllers and the current sensor must also be present with its readings. - + @@ -234,15 +243,16 @@ output_slew_rate(NX_NUMBER): The scanning area in x position in the frame. (e.g. 130.5E-9) - + Indicate the tip position Z between tip and sample. The tip position can also be varied when the controller is not running. (e.g. 130.5E-9) - + + - + Time during which the spectroscopy data are acquired and averaged. (e.g. 150E-6) @@ -278,7 +288,7 @@ output_slew_rate(NX_NUMBER): placed at the previously averaged Z position (plus Z offset). (e.g. 100E-3) - + @@ -335,8 +345,9 @@ output_slew_rate(NX_NUMBER): - - + + + Also clarify the frame for the ROI of the scan (should depend on the lab frame) @@ -382,51 +393,149 @@ output_slew_rate(NX_NUMBER): - + + + + + + + + + + + + + + + + + + - + + + + + + + + + + + + + + + + + + + + + + + - + + + + + @@ -471,10 +580,14 @@ LI Demod 1 Y (A) [bwd] [filt] lockin Temperature x y -z--> - - - - +z +single point default plot # current(I) vs bias(V)--> + + + + + + + From 7218325932612ca08f2d28d7d7744f8259588489 Mon Sep 17 00:00:00 2001 From: Rubel Date: Wed, 24 May 2023 09:24:08 +0200 Subject: [PATCH 0151/1012] Commenting some of the groups as they are giving error while generating template. --- .../nyaml/NXiv_sweep2.nxdl.xml | 596 ++++++++++++++++++ .../nyaml/NXiv_sweep2.yaml | 14 +- 2 files changed, 604 insertions(+), 6 deletions(-) create mode 100644 contributed_definitions/nyaml/NXiv_sweep2.nxdl.xml diff --git a/contributed_definitions/nyaml/NXiv_sweep2.nxdl.xml b/contributed_definitions/nyaml/NXiv_sweep2.nxdl.xml new file mode 100644 index 0000000000..215afa032f --- /dev/null +++ b/contributed_definitions/nyaml/NXiv_sweep2.nxdl.xml @@ -0,0 +1,596 @@ + + + + + + + Application definition for temperature-dependent IV curve measurements, #CAP with a focus on bias spectroscopy in scanning tunneling microscopy. + + In this application definition, times should be specified always together + with an UTC offset. + + This is the application definition describing temperature (T) dependent current voltage (IV) curve + measurements. For this a temperature is set. After reaching the temperature, + a voltage sweep is performed. For each voltage a current is measured. + Then, the next desired temperature is set and an IV measurement is performed. + #CAP the X, Y, Z, position of the probes or tip can be defined. #CAP The data can be visualized in a tensor with: + I (NXsensor_C, NXsoftware_Read_offset, NXcircuit) + parameters: + V has (NXsource+offset, NXsoftware_Scan_offset, NXsensor_V, NXcircuit) + T has (NXsource, NXsoftware_Scan_offset, NXsensor_T) + x has (NXsoftware_Scan_offset) + y has (NXsoftware_Scan_offset) + z has (NXsoftware_Scan_offset) + + + + + + + + + + The equipment and techniques as well as the parameter settings and reference + signals are used during the experiments used in the scanning tunneling + microscopy. + + + + + + + + + + The name of the output file, with the number of scans at the end.e.g. (e.g. + 221122_Au_5K00014) + + + + + The name of the series output file, which represents only the public part of the + output file. (e.g. 221122_Au_5K) + + + + + Path to storage of output files. (e.g. Path C:\Users\SPM- + PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis- + Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711) + + + + + Descriptive comments for this experiment, added by the experimenter, coming from + the output file. (e.g. Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, + locked Au(111), 50pA, 100 mV set point, 1mV DCA, 973Hz,138 1st H, -84 2nd H) + + + + + + + + + + + + + + + + Temperature of STM head. Temperature 1 (K) (e.g. 4.92997E+0). Note: At least + one field from stm_head_temperature, cryo_bottom_temp and + cryo_sheild_temp must be provided. + + + + + Temperature of LHe helium cryostat. Temperature 2 (K) (e.g 4.92997E+0). Note: At + least one field from stm_head_temperature, cryo_bottom_temp and + cryo_sheild_temp must be provided. + + + + + Temperature of LN2 nitrogen shield. Temperature 3 (K) (e.g 78.00000E+0). Note: At + least one field from stm_head_temperature, cryo_bottom_temp and + cryo_sheild_temp must be provided. + + + + + + + + The name of caliberation type. (e.g. LHe) + + + + + N denotes X or Y or Z. There are 3 parameters in X, Y, and Z directions and there are 3 controls availables: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. (e.g. 3.8E-9) + + + + + N denotes X or Y or Z. For some systems HV gain readout is available, so for + those systems the HV gain should be adjusted automatically when the gain is + changed at the high voltage amplifier. (e.g. 14.5) + + + + + + N denotes X or Y. There are 2 parameters in X and Y directions and this tab is + used to set the sample tilt (in degrees, first order correction). + + + + + + N denotes X or Y. There are 2 parameters in X and Y directions and this tab is + used to set a curvature (can be set approximately to the length of the + piezotube). + + + + + N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2). (e.g. 0E+0) + + + + + N denotes X or Y. There are 2 parameters in X and Y directions. Define the drift + speed for all three axes. When the compensation is on, the piezos will start to + move at that speed. (e.g. 0E+0) + + + + + Use the button to turn on/off the drift compensation. (e.g. FALSE) + + + + + + Describes an environment setup for a temperature-dependent IV measurement experiment. + + The temperature and voltage must be present as independently scanned controllers and + the current sensor must also be present with its readings. + + + + + Clarify the frame laboratory frame. + + + + The scanning area in x position in the frame. (e.g. -890.53E-12) + + + + + The scanning area in y position in the frame. (e.g. 29.6968E-9) + + + + + The scanning area in x position in the frame. (e.g. 130.5E-9) + + + + + Indicate the tip position Z between tip and sample. The tip position can also be + varied when the controller is not running. (e.g. 130.5E-9) + + + + + + + + + Time during which the spectroscopy data are acquired and averaged. (e.g. 150E-6) + + + + + Number of sweeps to measure and average. (e.g. 100) + + + + + The first bias values of the sweep. (e.g. -300E-3) + + + + + The last bias values of the sweep. (e.g. 300E-3) + + + + + Define the sweep number of points, that is, the maximum spectrum resolution eq. + Bias window divide by Num Pixel. (e.g. 4096) + + + + + Duration over which the Z position is recorded and averaged before and after the + sweep (the latter only if Record final Z position is selected in the Advanced + section). After the initial Z averaging time, if Z-Controller to Hold is + selected in the Advanced section, the Z-Controller is set to hold and the tip is + placed at the previously averaged Z position (plus Z offset). (e.g. 100E-3) + + + + + + + The bandwitdh of the Hardware and/or Software (e.g. 20E+3) + + + + + (Signals Periods) The Signals Period is the rate at which the signals are + transferred to the host computer running the control software. This is usually + lower by a factor of 10 than the sampling rate, because an internal oversampling + of the signal is done on the real time engine. You can reduce the oversampling + down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. (e.g. + 10) + + + + + Update rate for several processes like History Graph, Auto-Approach, and for + many Programming Interface functions. This is usually set to 20 ms. All + additional timings (7-9) can only be integer multiples of this value. They can + be set to different values, but the actual timing value will be coerced to a + multiple of the Acquisition Period. (e.g. 20E-3) + + + + + Update rate of animated graphical indicators. These are e.g. some graphs & + sliders. A reasonable value is 40 ms (25 updates per second). Increase this + period to reduce the processor load for the graphical user interface, especially + on slow computers. This value is purely a user interface update rate and does + not affect measurements in any way. (e.g. 20E-3) + + + + + Update rate of digital indicators, e.g. the numbers displayed besides each + slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a + user interface update rate and does not affect measurements in any way. (e.g. + 300E-3) + + + + + The Measurements period is the integration time for precise measurements + (averaging over specified period), mostly used in sweep modules. Examples are + recording of a force-distance curve or a resonance of a cantilever. For fast + measurements with small steps, a value of 40 ms may be reasonable. For normal + use, 300-500 ms is a good value, but for recording a resonance of a high-Q + cantilever, values of several seconds might be necessary. Usually this parameter + doesn’t need to be set from this module; the sweep modules will set this value + according to the sweep timings. (e.g. 500E-3) + + + + + + + + + + Also clarify the frame for the ROI of the scan (should depend on the lab frame) + + + + + + + The scan channels are selected by users. (e.g. (A);Bias (V);Z (m);LI Demod 2 X + (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A)) + + + + + + + Configure the scan frame like x position; y position; width; height. (e.g. + 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0) + + + + + Scan resolution by setting the Lines equal to Pixels. (e.g. 512) + + + + + Define the image resolution. (e.g. 512) + + + + + Define the scan forward speed in the forward direction. (m/s) (e.g. 11.7187E-9) + + + + + Define the scan backward speed in the forward direction. (m/s) (e.g. 11.7187E-9) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. + There should also be two more fields called temperature and voltage containing the setpoint values. + There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension + equal to the number of voltage setpoints. + axes: bias_calc + signals: + li_demod_[1;2]_[X/Y]_[-;bwd;filt;bwd_filt] + current_[-;bwd;filt;bwd_filt] + temperature + x + y + z + + + + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index 13b855741d..c27df08af3 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -139,10 +139,12 @@ NXiv_sweep2(NXsensor_scan): The temperature and voltage must be present as independently scanned controllers and the current sensor must also be present with its readings. - voltage_controller(NXsensor): - exists: optional - temperature_controller(NXsensor): - current_sensor(NXsensor): + # TODO: Bellow command must be removed later. These are commented because we are + # while generation template getting error in this + # voltage_controller(NXsensor): + # exists: optional + # temperature_controller(NXsensor): + # current_sensor(NXsensor): position(NXpositioner): doc: Clarify the frame laboratory frame. x(NX_NUMBER): @@ -203,10 +205,10 @@ NXiv_sweep2(NXsensor_scan): circuit(NXcollection): channels_current: doc: The scan channels are selected by users. (e.g. (A);Bias (V);Z (m);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A)) - positioner(NXcollection)): + positioner(NXcollection): scanfield(NX_NUMBER): doc: Configure the scan frame like x position; y position; width; height. (e.g. 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0) - pixels/line(NX_NUMBER): + pixels_line(NX_NUMBER): doc: Scan resolution by setting the Lines equal to Pixels. (e.g. 512) lines(NX_NUMBER): doc: Define the image resolution. (e.g. 512) From f765312893dd88612d563ec383a2815e5815ec84 Mon Sep 17 00:00:00 2001 From: Rubel Date: Wed, 24 May 2023 09:28:26 +0200 Subject: [PATCH 0152/1012] adding mving nxdl file to ../ --- contributed_definitions/NXiv_sweep2.nxdl.xml | 15 +- .../nyaml/NXiv_sweep2.nxdl.xml | 596 ------------------ 2 files changed, 9 insertions(+), 602 deletions(-) delete mode 100644 contributed_definitions/nyaml/NXiv_sweep2.nxdl.xml diff --git a/contributed_definitions/NXiv_sweep2.nxdl.xml b/contributed_definitions/NXiv_sweep2.nxdl.xml index d65027fc41..215afa032f 100644 --- a/contributed_definitions/NXiv_sweep2.nxdl.xml +++ b/contributed_definitions/NXiv_sweep2.nxdl.xml @@ -221,9 +221,12 @@ doc: The rate at which the one of the signal changes when ramping to the startin The temperature and voltage must be present as independently scanned controllers and the current sensor must also be present with its readings. - - - + Clarify the frame laboratory frame. @@ -362,14 +365,14 @@ doc: The rate at which the one of the signal changes when ramping to the startin - + Configure the scan frame like x position; y position; width; height. (e.g. 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0) - + Scan resolution by setting the Lines equal to Pixels. (e.g. 512) @@ -389,7 +392,7 @@ doc: The rate at which the one of the signal changes when ramping to the startin Define the scan backward speed in the forward direction. (m/s) (e.g. 11.7187E-9) - + diff --git a/contributed_definitions/nyaml/NXiv_sweep2.nxdl.xml b/contributed_definitions/nyaml/NXiv_sweep2.nxdl.xml deleted file mode 100644 index 215afa032f..0000000000 --- a/contributed_definitions/nyaml/NXiv_sweep2.nxdl.xml +++ /dev/null @@ -1,596 +0,0 @@ - - - - - - - Application definition for temperature-dependent IV curve measurements, #CAP with a focus on bias spectroscopy in scanning tunneling microscopy. - - In this application definition, times should be specified always together - with an UTC offset. - - This is the application definition describing temperature (T) dependent current voltage (IV) curve - measurements. For this a temperature is set. After reaching the temperature, - a voltage sweep is performed. For each voltage a current is measured. - Then, the next desired temperature is set and an IV measurement is performed. - #CAP the X, Y, Z, position of the probes or tip can be defined. #CAP The data can be visualized in a tensor with: - I (NXsensor_C, NXsoftware_Read_offset, NXcircuit) - parameters: - V has (NXsource+offset, NXsoftware_Scan_offset, NXsensor_V, NXcircuit) - T has (NXsource, NXsoftware_Scan_offset, NXsensor_T) - x has (NXsoftware_Scan_offset) - y has (NXsoftware_Scan_offset) - z has (NXsoftware_Scan_offset) - - - - - - - - - - The equipment and techniques as well as the parameter settings and reference - signals are used during the experiments used in the scanning tunneling - microscopy. - - - - - - - - - - The name of the output file, with the number of scans at the end.e.g. (e.g. - 221122_Au_5K00014) - - - - - The name of the series output file, which represents only the public part of the - output file. (e.g. 221122_Au_5K) - - - - - Path to storage of output files. (e.g. Path C:\Users\SPM- - PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis- - Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711) - - - - - Descriptive comments for this experiment, added by the experimenter, coming from - the output file. (e.g. Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, - locked Au(111), 50pA, 100 mV set point, 1mV DCA, 973Hz,138 1st H, -84 2nd H) - - - - - - - - - - - - - - - - Temperature of STM head. Temperature 1 (K) (e.g. 4.92997E+0). Note: At least - one field from stm_head_temperature, cryo_bottom_temp and - cryo_sheild_temp must be provided. - - - - - Temperature of LHe helium cryostat. Temperature 2 (K) (e.g 4.92997E+0). Note: At - least one field from stm_head_temperature, cryo_bottom_temp and - cryo_sheild_temp must be provided. - - - - - Temperature of LN2 nitrogen shield. Temperature 3 (K) (e.g 78.00000E+0). Note: At - least one field from stm_head_temperature, cryo_bottom_temp and - cryo_sheild_temp must be provided. - - - - - - - - The name of caliberation type. (e.g. LHe) - - - - - N denotes X or Y or Z. There are 3 parameters in X, Y, and Z directions and there are 3 controls availables: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. (e.g. 3.8E-9) - - - - - N denotes X or Y or Z. For some systems HV gain readout is available, so for - those systems the HV gain should be adjusted automatically when the gain is - changed at the high voltage amplifier. (e.g. 14.5) - - - - - - N denotes X or Y. There are 2 parameters in X and Y directions and this tab is - used to set the sample tilt (in degrees, first order correction). - - - - - - N denotes X or Y. There are 2 parameters in X and Y directions and this tab is - used to set a curvature (can be set approximately to the length of the - piezotube). - - - - - N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2). (e.g. 0E+0) - - - - - N denotes X or Y. There are 2 parameters in X and Y directions. Define the drift - speed for all three axes. When the compensation is on, the piezos will start to - move at that speed. (e.g. 0E+0) - - - - - Use the button to turn on/off the drift compensation. (e.g. FALSE) - - - - - - Describes an environment setup for a temperature-dependent IV measurement experiment. - - The temperature and voltage must be present as independently scanned controllers and - the current sensor must also be present with its readings. - - - - - Clarify the frame laboratory frame. - - - - The scanning area in x position in the frame. (e.g. -890.53E-12) - - - - - The scanning area in y position in the frame. (e.g. 29.6968E-9) - - - - - The scanning area in x position in the frame. (e.g. 130.5E-9) - - - - - Indicate the tip position Z between tip and sample. The tip position can also be - varied when the controller is not running. (e.g. 130.5E-9) - - - - - - - - - Time during which the spectroscopy data are acquired and averaged. (e.g. 150E-6) - - - - - Number of sweeps to measure and average. (e.g. 100) - - - - - The first bias values of the sweep. (e.g. -300E-3) - - - - - The last bias values of the sweep. (e.g. 300E-3) - - - - - Define the sweep number of points, that is, the maximum spectrum resolution eq. - Bias window divide by Num Pixel. (e.g. 4096) - - - - - Duration over which the Z position is recorded and averaged before and after the - sweep (the latter only if Record final Z position is selected in the Advanced - section). After the initial Z averaging time, if Z-Controller to Hold is - selected in the Advanced section, the Z-Controller is set to hold and the tip is - placed at the previously averaged Z position (plus Z offset). (e.g. 100E-3) - - - - - - - The bandwitdh of the Hardware and/or Software (e.g. 20E+3) - - - - - (Signals Periods) The Signals Period is the rate at which the signals are - transferred to the host computer running the control software. This is usually - lower by a factor of 10 than the sampling rate, because an internal oversampling - of the signal is done on the real time engine. You can reduce the oversampling - down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. (e.g. - 10) - - - - - Update rate for several processes like History Graph, Auto-Approach, and for - many Programming Interface functions. This is usually set to 20 ms. All - additional timings (7-9) can only be integer multiples of this value. They can - be set to different values, but the actual timing value will be coerced to a - multiple of the Acquisition Period. (e.g. 20E-3) - - - - - Update rate of animated graphical indicators. These are e.g. some graphs & - sliders. A reasonable value is 40 ms (25 updates per second). Increase this - period to reduce the processor load for the graphical user interface, especially - on slow computers. This value is purely a user interface update rate and does - not affect measurements in any way. (e.g. 20E-3) - - - - - Update rate of digital indicators, e.g. the numbers displayed besides each - slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a - user interface update rate and does not affect measurements in any way. (e.g. - 300E-3) - - - - - The Measurements period is the integration time for precise measurements - (averaging over specified period), mostly used in sweep modules. Examples are - recording of a force-distance curve or a resonance of a cantilever. For fast - measurements with small steps, a value of 40 ms may be reasonable. For normal - use, 300-500 ms is a good value, but for recording a resonance of a high-Q - cantilever, values of several seconds might be necessary. Usually this parameter - doesn’t need to be set from this module; the sweep modules will set this value - according to the sweep timings. (e.g. 500E-3) - - - - - - - - - - Also clarify the frame for the ROI of the scan (should depend on the lab frame) - - - - - - - The scan channels are selected by users. (e.g. (A);Bias (V);Z (m);LI Demod 2 X - (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A)) - - - - - - - Configure the scan frame like x position; y position; width; height. (e.g. - 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0) - - - - - Scan resolution by setting the Lines equal to Pixels. (e.g. 512) - - - - - Define the image resolution. (e.g. 512) - - - - - Define the scan forward speed in the forward direction. (m/s) (e.g. 11.7187E-9) - - - - - Define the scan backward speed in the forward direction. (m/s) (e.g. 11.7187E-9) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. - There should also be two more fields called temperature and voltage containing the setpoint values. - There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension - equal to the number of voltage setpoints. - axes: bias_calc - signals: - li_demod_[1;2]_[X/Y]_[-;bwd;filt;bwd_filt] - current_[-;bwd;filt;bwd_filt] - temperature - x - y - z - - - - - - - - - - - - From ee2de4d4d47f3642481e390b363e91d3849dc042 Mon Sep 17 00:00:00 2001 From: Rubel Date: Wed, 24 May 2023 17:59:51 +0200 Subject: [PATCH 0153/1012] Updating NXiv_sweep both yaml and nxsdl.xml step-1: before working on stm reader. --- contributed_definitions/NXiv_sweep2.nxdl.xml | 59 +++++++++++-------- .../nyaml/NXiv_sweep2.yaml | 50 +++++++++++----- 2 files changed, 72 insertions(+), 37 deletions(-) diff --git a/contributed_definitions/NXiv_sweep2.nxdl.xml b/contributed_definitions/NXiv_sweep2.nxdl.xml index 215afa032f..a2c1954490 100644 --- a/contributed_definitions/NXiv_sweep2.nxdl.xml +++ b/contributed_definitions/NXiv_sweep2.nxdl.xml @@ -60,7 +60,7 @@ - + The name of the output file, with the number of scans at the end.e.g. (e.g. 221122_Au_5K00014) @@ -72,14 +72,14 @@ output file. (e.g. 221122_Au_5K) - + Path to storage of output files. (e.g. Path C:\Users\SPM- PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis- Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711) - + Descriptive comments for this experiment, added by the experimenter, coming from the output file. (e.g. Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, @@ -87,16 +87,16 @@ - + - + - + @@ -124,7 +124,13 @@ record_final_z: doc: Select whether to record the Z position during Z averaging time at the end of the sweep (after Z control time) and store the average value in the header of the file when saving. Using this option increases the sweep time by Z averaging time. (e.g. FALSE) run: doc: Bias Spectroscopy>Lock-In run FALSE # Select whether to set the Lock-In to run during the measurement. When using this feature, make sure the Lock-In is configured correctly and settling times are set to twice the Lock-In period at least. This option is ignored when Lock-In is already running. This option is disabled if the Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline segment editor is set.--> - + + + + Applied a voltage between tip and sample. + + + cryo_sheild_temp must be provided. - + + - + The name of caliberation type. (e.g. LHe) - + - N denotes X or Y or Z. There are 3 parameters in X, Y, and Z directions and there are 3 controls availables: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. (e.g. 3.8E-9) + N denotes X or Y or Z. There are 3 parameters in X, Y, and Z directions and there + are 3 controls availables: Calibr. (m/V), Range (m) and HV gain. Two of them are + enough to define the calibration, so when changing any value one of the other values + will be updated automatically. (e.g. 3.8E-9) @@ -189,7 +199,7 @@ doc: The rate at which the one of the signal changes when ramping to the startin - + N denotes X or Y. There are 2 parameters in X and Y directions and this tab is used to set a curvature (can be set approximately to the length of the @@ -203,9 +213,9 @@ doc: The rate at which the one of the signal changes when ramping to the startin - N denotes X or Y. There are 2 parameters in X and Y directions. Define the drift - speed for all three axes. When the compensation is on, the piezos will start to - move at that speed. (e.g. 0E+0) + N denotes X, Y or Z. There are 3 parameters in X, Y and Z directions. Define the + drift speed for all three axes. When the compensation is on, the piezos will + start to move at that speed. (e.g. 0E+0) @@ -246,7 +256,7 @@ current_sensor(NXsensor):--> The scanning area in x position in the frame. (e.g. 130.5E-9) - + Indicate the tip position Z between tip and sample. The tip position can also be varied when the controller is not running. (e.g. 130.5E-9) @@ -256,7 +266,7 @@ current_sensor(NXsensor):--> - + Time during which the spectroscopy data are acquired and averaged. (e.g. 150E-6) @@ -308,7 +318,7 @@ current_sensor(NXsensor):--> 10) - + Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All @@ -317,7 +327,7 @@ current_sensor(NXsensor):--> multiple of the Acquisition Period. (e.g. 20E-3) - + Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this @@ -382,12 +392,12 @@ current_sensor(NXsensor):--> Define the image resolution. (e.g. 512) - + Define the scan forward speed in the forward direction. (m/s) (e.g. 11.7187E-9) - + Define the scan backward speed in the forward direction. (m/s) (e.g. 11.7187E-9) @@ -396,7 +406,9 @@ current_sensor(NXsensor):--> - + @@ -457,7 +469,8 @@ reasonable. For normal use, 300-500 ms is a good value, but for recording a reso high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings.--> - + diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index c27df08af3..ea7263f2de 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -25,17 +25,22 @@ NXiv_sweep2(NXsensor_scan): doc: The equipment and techniques as well as the parameter settings and reference signals are used during the experiments used in the scanning tunneling microscopy. enumeration: [background, reference, sample] entry_identifier: + exists: optional doc: The name of the output file, with the number of scans at the end.e.g. (e.g. 221122_Au_5K00014) collection_dentifier: doc: The name of the series output file, which represents only the public part of the output file. (e.g. 221122_Au_5K) experiment_identifier: + exists: optional doc: Path to storage of output files. (e.g. Path C:\Users\SPM-PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis-Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711) experiment_description: - doc: Descriptive comments for this experiment, added by the experimenter, coming from the output file. (e.g. Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, locked Au(111), 50pA, 100 mV set point, 1mV DCA, 973Hz,138 1st H, -84 2nd H) + exists: optional + doc: Descriptive comments for this experiment, added by the experimenter, coming from the output file. (e.g. Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, locked Au(111), 50pA, 100 mV set point, 1mV DCA, 973Hz,138 1st H, -84 2nd H) (NXinstrument): hardware(NXfabrication): + exists: optional # any or specifique 'harware' and 'software'? - software(NXfabrication): + software(NXfabrication): + exists: optional # doc: | # Software and hardware for control, scanning and data collection in the SPM system # hardware: @@ -43,6 +48,7 @@ NXiv_sweep2(NXsensor_scan): # softwareMain>Software: # doc: Type of software used in SPM experiments, e.g. software version serial number, UI and RT probe release method. (e.g. SW Version Generic 5e -- SoftwareMain>UI Release 10771 -- SoftwareMain>RT Release 10771) current_amplifier(NXamplifier): + exists: optional # hardware: Current amplifier> hardware: CreaTec GmbH # amplification: Current amplifier> factor (V/V): 1E-10 # crosstalk_compensation: Current amplifier> Capacitive cross-talk compensation: Yes/No @@ -72,6 +78,9 @@ NXiv_sweep2(NXsensor_scan): #run: # doc: Bias Spectroscopy>Lock-In run FALSE # Select whether to set the Lock-In to run during the measurement. When using this feature, make sure the Lock-In is configured correctly and settling times are set to twice the Lock-In period at least. This option is ignored when Lock-In is already running. This option is disabled if the Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline segment editor is set. sample_bias(NXiv_bias): + bias(NX_NUMBER): + unit: NX_VOLTAGE + doc: Applied a voltage between tip and sample. # sample_bias(NXbias): # Tip bias/Sample bias If the spectroscopy V bias is applied to the # Modulated signal Bias (V) 1E-3 Applied modulation to the bias voltage. @@ -100,7 +109,9 @@ NXiv_sweep2(NXsensor_scan): Temperature of LN2 nitrogen shield. Temperature 3 (K) (e.g 78.00000E+0). Note: At least one field from stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp must be provided. + # TODO: after fixing the sxm remove the optional field output_cabling(NXcircuit): + exists: optional # Cabling & Config # output_mode: # doc: Number of output channels. (e.g. User Output) @@ -111,26 +122,32 @@ NXiv_sweep2(NXsensor_scan): # output_slew_rate(NX_NUMBER): # doc: The rate at which the one of the signal changes when ramping to the starting point. (V/s) (e.g. Inf) piezo_config(NXcollection): - active_calib.: + active_calib: doc: The name of caliberation type. (e.g. LHe) - calib._N(NX_NUMBER): + calib_N(NX_NUMBER): doc: | - N denotes X or Y or Z. There are 3 parameters in X, Y, and Z directions and there are 3 controls availables: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. (e.g. 3.8E-9) + N denotes X or Y or Z. There are 3 parameters in X, Y, and Z directions and there + are 3 controls availables: Calibr. (m/V), Range (m) and HV gain. Two of them are + enough to define the calibration, so when changing any value one of the other values + will be updated automatically. (e.g. 3.8E-9) hv_gain_N(NX_NUMBER): - doc: N denotes X or Y or Z. For some systems HV gain readout is available, so for those systems the HV gain should be adjusted automatically when the gain is changed at the high voltage amplifier. (e.g. 14.5) + doc: N denotes X or Y or Z. For some systems HV gain readout is available, + so for those systems the HV gain should be adjusted automatically when the gain is changed at the high voltage amplifier. (e.g. 14.5) # (e.g. 0.318343) tilt_N(NX_NUMBER): unit: NX_ANGLE doc: N denotes X or Y. There are 2 parameters in X and Y directions and this tab is used to set the sample tilt (in degrees, first order correction). # Inf - curvature_radius N(NX_NUMBER): + curvature_radius_N(NX_NUMBER): unit: NX_LENGTH doc: N denotes X or Y. There are 2 parameters in X and Y directions and this tab is used to set a curvature (can be set approximately to the length of the piezotube). 2nd_order_corr_N(NX_NUMBER): doc: | N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2). (e.g. 0E+0) drift_N(NX_NUMBER): - doc: N denotes X or Y. There are 2 parameters in X and Y directions. Define the drift speed for all three axes. When the compensation is on, the piezos will start to move at that speed. (e.g. 0E+0) + doc: N denotes X, Y or Z. There are 3 parameters in X, Y and Z directions. Define the drift + speed for all three axes. When the compensation is on, the piezos will start to move at + that speed. (e.g. 0E+0) drift_correction_status(NX_BOOLEAN): doc: Use the button to turn on/off the drift compensation. (e.g. FALSE) (NXenvironment): @@ -156,13 +173,13 @@ NXiv_sweep2(NXsensor_scan): z(NX_NUMBER): unit: NX_LENGTH doc: The scanning area in x position in the frame. (e.g. 130.5E-9) - z-controller(NX_NUMBER): + z_controller(NX_NUMBER): unit: NX_LENGTH doc: Indicate the tip position Z between tip and sample. The tip position can also be varied when the controller is not running. (e.g. 130.5E-9) # parameters for a measurement at a single location during the scan sweep_control(NXcollection): bias_spectroscopy(NXbias_spectroscopy): - integration time(NX_NUMBER): + integration_time(NX_NUMBER): unit: NX_TIME doc: Time during which the spectroscopy data are acquired and averaged. (e.g. 150E-6) number_of_sweeps(NX_NUMBER): @@ -186,9 +203,11 @@ NXiv_sweep2(NXsensor_scan): doc: (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. (e.g. 10) acquisition_period(NX_NUMBER): unit: NX_TIME + exists: optional doc: Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. (e.g. 20E-3) animations_period(NX_NUMBER): unit: NX_TIME + exists: optional doc: Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. (e.g. 20E-3) indicators_period(NX_NUMBER): unit: NX_TIME @@ -212,11 +231,13 @@ NXiv_sweep2(NXsensor_scan): doc: Scan resolution by setting the Lines equal to Pixels. (e.g. 512) lines(NX_NUMBER): doc: Define the image resolution. (e.g. 512) - speed_forw.(NX_NUMBER): + speed_forw(NX_NUMBER): doc: Define the scan forward speed in the forward direction. (m/s) (e.g. 11.7187E-9) - speed_backw.(NX_NUMBER): + speed_backw(NX_NUMBER): doc: Define the scan backward speed in the forward direction. (m/s) (e.g. 11.7187E-9) # RESOLUTION (calculation input) + # TODO: After fix resolution_indicators back to required + # As all of the bellow are linked resolution_indicators(NXprocess): exists: optional # Temperature 1>link to INSTR/STM/head Temperature 1 (K) (e.g. 4.92997E+0) # Temperature of STM head. @@ -277,8 +298,9 @@ NXiv_sweep2(NXsensor_scan): # reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a # high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. measurement_period: - # REPRODUCIBILITY - reproducibility_indicators(NXprocess): + # TODO: Later fix REPRODUCIBILITY_indicator + # as all of the bellow are linked + reproducibility_indicators(NXprocess): exists: optional # Bias>Bias(NXBias) (V) (e.g. 100E-3) # Applied bias voltage. bias: From db9999e65a9811de82ee342662c810dd23d99a82 Mon Sep 17 00:00:00 2001 From: Rubel Date: Sun, 28 May 2023 11:40:30 +0200 Subject: [PATCH 0154/1012] Making some fields optional as concatenarted part of the field is upper case and after replacing that part converter is not working. --- contributed_definitions/NXiv_sweep2.nxdl.xml | 44 +++++++++---------- .../nyaml/NXiv_sweep2.yaml | 30 ++++++++++--- 2 files changed, 46 insertions(+), 28 deletions(-) diff --git a/contributed_definitions/NXiv_sweep2.nxdl.xml b/contributed_definitions/NXiv_sweep2.nxdl.xml index a2c1954490..998b9a8849 100644 --- a/contributed_definitions/NXiv_sweep2.nxdl.xml +++ b/contributed_definitions/NXiv_sweep2.nxdl.xml @@ -48,11 +48,10 @@ - + - The equipment and techniques as well as the parameter settings and reference - signals are used during the experiments used in the scanning tunneling - microscopy. + The equipment and techniques as well as the parameter settings and reference signals + are used during the experiments used in the scanning tunneling microscopy. @@ -79,13 +78,13 @@ Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711) - - - Descriptive comments for this experiment, added by the experimenter, coming from - the output file. (e.g. Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, - locked Au(111), 50pA, 100 mV set point, 1mV DCA, 973Hz,138 1st H, -84 2nd H) - - + @@ -176,7 +175,7 @@ doc: The rate at which the one of the signal changes when ramping to the startin The name of caliberation type. (e.g. LHe) - + N denotes X or Y or Z. There are 3 parameters in X, Y, and Z directions and there are 3 controls availables: Calibr. (m/V), Range (m) and HV gain. Two of them are @@ -184,7 +183,7 @@ doc: The rate at which the one of the signal changes when ramping to the startin will be updated automatically. (e.g. 3.8E-9) - + N denotes X or Y or Z. For some systems HV gain readout is available, so for those systems the HV gain should be adjusted automatically when the gain is @@ -192,26 +191,26 @@ doc: The rate at which the one of the signal changes when ramping to the startin - + N denotes X or Y. There are 2 parameters in X and Y directions and this tab is used to set the sample tilt (in degrees, first order correction). - + N denotes X or Y. There are 2 parameters in X and Y directions and this tab is used to set a curvature (can be set approximately to the length of the piezotube). - + N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2). (e.g. 0E+0) - + N denotes X, Y or Z. There are 3 parameters in X, Y and Z directions. Define the drift speed for all three axes. When the compensation is on, the piezos will @@ -241,17 +240,17 @@ current_sensor(NXsensor):--> Clarify the frame laboratory frame. - + The scanning area in x position in the frame. (e.g. -890.53E-12) - + The scanning area in y position in the frame. (e.g. 29.6968E-9) - + The scanning area in x position in the frame. (e.g. 130.5E-9) @@ -344,7 +343,7 @@ current_sensor(NXsensor):--> 300E-3) - + The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are @@ -554,7 +553,8 @@ a reproducible position when switching off the Z-controller. When >0 and the Z-c is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position.--> - + + This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. There should also be two more fields called temperature and voltage containing the setpoint values. diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index ea7263f2de..0cd3137a93 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -22,8 +22,11 @@ NXiv_sweep2(NXsensor_scan): definition: enumeration: [NXiv_sweep2] type: - doc: The equipment and techniques as well as the parameter settings and reference signals are used during the experiments used in the scanning tunneling microscopy. + exists: optional enumeration: [background, reference, sample] + doc: | + The equipment and techniques as well as the parameter settings and reference signals + are used during the experiments used in the scanning tunneling microscopy. entry_identifier: exists: optional doc: The name of the output file, with the number of scans at the end.e.g. (e.g. 221122_Au_5K00014) @@ -32,9 +35,13 @@ NXiv_sweep2(NXsensor_scan): experiment_identifier: exists: optional doc: Path to storage of output files. (e.g. Path C:\Users\SPM-PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis-Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711) - experiment_description: - exists: optional - doc: Descriptive comments for this experiment, added by the experimenter, coming from the output file. (e.g. Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, locked Au(111), 50pA, 100 mV set point, 1mV DCA, 973Hz,138 1st H, -84 2nd H) + # TODO: Uncomment it after running the reader perfectly + # experiment_description: + # exists: optional + # doc: | + # Descriptive comments for this experiment, added by the experimenter, coming from the + # output file. (e.g. Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, locked Au(111), + # 50pA, 100 mV set point, 1mV DCA, 973Hz,138 1st H, -84 2nd H) (NXinstrument): hardware(NXfabrication): exists: optional @@ -125,26 +132,32 @@ NXiv_sweep2(NXsensor_scan): active_calib: doc: The name of caliberation type. (e.g. LHe) calib_N(NX_NUMBER): + exists: optional doc: | N denotes X or Y or Z. There are 3 parameters in X, Y, and Z directions and there are 3 controls availables: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values will be updated automatically. (e.g. 3.8E-9) hv_gain_N(NX_NUMBER): + exists: optional doc: N denotes X or Y or Z. For some systems HV gain readout is available, so for those systems the HV gain should be adjusted automatically when the gain is changed at the high voltage amplifier. (e.g. 14.5) # (e.g. 0.318343) tilt_N(NX_NUMBER): + exists: optional unit: NX_ANGLE doc: N denotes X or Y. There are 2 parameters in X and Y directions and this tab is used to set the sample tilt (in degrees, first order correction). # Inf curvature_radius_N(NX_NUMBER): + exists: optional unit: NX_LENGTH doc: N denotes X or Y. There are 2 parameters in X and Y directions and this tab is used to set a curvature (can be set approximately to the length of the piezotube). 2nd_order_corr_N(NX_NUMBER): + exists: optional doc: | N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2). (e.g. 0E+0) drift_N(NX_NUMBER): + exists: optional doc: N denotes X, Y or Z. There are 3 parameters in X, Y and Z directions. Define the drift speed for all three axes. When the compensation is on, the piezos will start to move at that speed. (e.g. 0E+0) @@ -165,12 +178,15 @@ NXiv_sweep2(NXsensor_scan): position(NXpositioner): doc: Clarify the frame laboratory frame. x(NX_NUMBER): + exists: optional unit: NX_LENGTH doc: The scanning area in x position in the frame. (e.g. -890.53E-12) y(NX_NUMBER): + exists: optional unit: NX_LENGTH doc: The scanning area in y position in the frame. (e.g. 29.6968E-9) z(NX_NUMBER): + exists: optional unit: NX_LENGTH doc: The scanning area in x position in the frame. (e.g. 130.5E-9) z_controller(NX_NUMBER): @@ -212,7 +228,8 @@ NXiv_sweep2(NXsensor_scan): indicators_period(NX_NUMBER): unit: NX_TIME doc: Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. (e.g. 300E-3) - measurements_period (NX_NUMBER): + measurements_period(NX_NUMBER): + exists: optional unit: NX_TIME doc: The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. (e.g. 500E-3) # parameters how to change the location from measurement to measurement during the scan @@ -383,7 +400,8 @@ NXiv_sweep2(NXsensor_scan): # a reproducible position when switching off the Z-controller. When >0 and the Z-controller # is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. z_control_switchoff_delay: - data(NXdata): + # TODO: discuss convertion data to DATA + (NXdata): doc: | This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. There should also be two more fields called temperature and voltage containing the setpoint values. From 9ca3af144e2401c7125da57ff4b2823ad0cbab56 Mon Sep 17 00:00:00 2001 From: Rubel Date: Thu, 15 Jun 2023 14:35:49 +0200 Subject: [PATCH 0155/1012] Adding some comments and doc in yaml files. --- .../nyaml/NXiv_sweep2.backup.yaml | 21 +- .../nyaml/NXiv_sweep2.yaml | 185 +++++++++++------- 2 files changed, 126 insertions(+), 80 deletions(-) diff --git a/contributed_definitions/nyaml/NXiv_sweep2.backup.yaml b/contributed_definitions/nyaml/NXiv_sweep2.backup.yaml index 075a438ec4..911e247bb2 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.backup.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.backup.yaml @@ -8,21 +8,24 @@ doc: | measurements. For this a temperature is set. After reaching the temperature, a voltage sweep is performed. For each voltage a current is measured. Then, the next desired temperature is set and an IV measurement is performed. - #CAP the X, Y, Z, position of the probes or tip can be defined. #CAP The data can be visualized in a tensor with: - I (NXsensor_C, NXsoftware_Read_offset, NXcircuit) - parameters: - V has (NXsource+offset, NXsoftware_Scan_offset, NXsensor_V, NXcircuit) - T has (NXsource, NXsoftware_Scan_offset, NXsensor_T) - x has (NXsoftware_Scan_offset) - y has (NXsoftware_Scan_offset) - z has (NXsoftware_Scan_offset) + NOTE_ : The text below is not comprehensive Should they be in symbol + #CAP the X, Y, Z, position of the probes or tip can be defined. + #CAP The data can be visualized in a tensor with: + I (NXsensor_C, NXsoftware_Read_offset, NXcircuit) + parameters: + V has (NXsource+offset, NXsoftware_Scan_offset, NXsensor_V, NXcircuit) + T has (NXsource, NXsoftware_Scan_offset, NXsensor_T) + x has (NXsoftware_Scan_offset) + y has (NXsoftware_Scan_offset) + z has (NXsoftware_Scan_offset) + category: application NXiv_sweep2(NXsensor_scan): (NXentry): definition(NX_CHAR): enumeration: [NXiv_sweep2] (NXinstrument): - Hardware: + hardware: doc: the name of the instrument device used.... (NXenvironment): doc: | diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index 0cd3137a93..f5bd1701a8 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -1,32 +1,37 @@ -doc: | - Application definition for temperature-dependent IV curve measurements, #CAP with a focus on bias spectroscopy in scanning tunneling microscopy. - +doc: | + Application definition for temperature-dependent IV curve measurements, + NOTE_: What is CAP + #CAP with a focus on bias spectroscopy in scanning tunneling microscopy. + In this application definition, times should be specified always together with an UTC offset. - + This is the application definition describing temperature (T) dependent current voltage (IV) curve measurements. For this a temperature is set. After reaching the temperature, a voltage sweep is performed. For each voltage a current is measured. Then, the next desired temperature is set and an IV measurement is performed. - #CAP the X, Y, Z, position of the probes or tip can be defined. #CAP The data can be visualized in a tensor with: - I (NXsensor_C, NXsoftware_Read_offset, NXcircuit) - parameters: - V has (NXsource+offset, NXsoftware_Scan_offset, NXsensor_V, NXcircuit) - T has (NXsource, NXsoftware_Scan_offset, NXsensor_T) - x has (NXsoftware_Scan_offset) - y has (NXsoftware_Scan_offset) - z has (NXsoftware_Scan_offset) + NOTE_ : The text below is not comprehensive Should they be in symbol + #CAP the X, Y, Z, position of the probes or tip can be defined. + #CAP The data can be visualized in a tensor with: + I (NXsensor_C, NXsoftware_Read_offset, NXcircuit) + parameters: + V has (NXsource+offset, NXsoftware_Scan_offset, NXsensor_V, NXcircuit) + T has (NXsource, NXsoftware_Scan_offset, NXsensor_T) + x has (NXsoftware_Scan_offset) + y has (NXsoftware_Scan_offset) + z has (NXsoftware_Scan_offset) category: application NXiv_sweep2(NXsensor_scan): (NXentry): definition: enumeration: [NXiv_sweep2] type: - exists: optional + # NOTE_: What does the enum refer, scan could be forward or backward. (not in data file) + # What is about [constant current mode, constand height mode] enumeration: [background, reference, sample] doc: | - The equipment and techniques as well as the parameter settings and reference signals - are used during the experiments used in the scanning tunneling microscopy. + The equipments and techniques as well as the parameter settings and reference signals + are used during the experiments used in the scanning tunneling microscopy(STM). entry_identifier: exists: optional doc: The name of the output file, with the number of scans at the end.e.g. (e.g. 221122_Au_5K00014) @@ -35,30 +40,31 @@ NXiv_sweep2(NXsensor_scan): experiment_identifier: exists: optional doc: Path to storage of output files. (e.g. Path C:\Users\SPM-PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis-Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711) - # TODO: Uncomment it after running the reader perfectly - # experiment_description: - # exists: optional - # doc: | - # Descriptive comments for this experiment, added by the experimenter, coming from the - # output file. (e.g. Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, locked Au(111), - # 50pA, 100 mV set point, 1mV DCA, 973Hz,138 1st H, -84 2nd H) + experiment_description: + exists: optional + doc: | + Descriptive comments for this experiment, added by the experimenter, coming from the + output file. (e.g. Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, locked Au(111), + 50pA, 100 mV set point, 1mV DCA, 973Hz,138 1st H, -84 2nd H) (NXinstrument): hardware(NXfabrication): exists: optional + # NOTE_: No documentaion available + doc: Hardware type used in SPM experiment, includes hardware manufacturers and type. (e.g. Nanonis BP5e) # any or specifique 'harware' and 'software'? software(NXfabrication): - exists: optional - # doc: | - # Software and hardware for control, scanning and data collection in the SPM system - # hardware: - # doc: Hardware type used in SPM experiment, includes hardware manufacturers and type. (e.g. Nanonis BP5e) - # softwareMain>Software: - # doc: Type of software used in SPM experiments, e.g. software version serial number, UI and RT probe release method. (e.g. SW Version Generic 5e -- SoftwareMain>UI Release 10771 -- SoftwareMain>RT Release 10771) + exists: optional + doc: | + Type of software used in SPM experiments, e.g. software version serial number, UI and + RT probe release method. (e.g. SW Version Generic 5e -- SoftwareMain>UI Release 10771 + -- SoftwareMain>RT Release 10771) + # hardware: Current amplifier> hardware: CreaTec GmbH + # amplification: Current amplifier> factor (V/V): 1E-10 + # crosstalk_compensation: Current amplifier> Capacitive cross-talk compensation: Yes/No current_amplifier(NXamplifier): exists: optional - # hardware: Current amplifier> hardware: CreaTec GmbH - # amplification: Current amplifier> factor (V/V): 1E-10 - # crosstalk_compensation: Current amplifier> Capacitive cross-talk compensation: Yes/No + doc: | + The Amplifier description that improves or helps to determine tunnel current (current between tip and bias). lock_in(NXlockin): exists: optional # status: Lock-in>Lock-in status ON # ON/OFF of Lock-in amplifier @@ -66,59 +72,85 @@ NXiv_sweep2(NXsensor_scan): # doc: Lock-in Amplifier>Yes/No # If a lock-in amplifier employed to filter or obtain the electronic derivatives dI/dV of the signal # hardware: Lock-in Amplifier>Hardware: Nanonis # modulate_signal: Lock-in>Modulated signal Bias (V) # This is the signal on which the modulation (sine) will be added. - # frequency: Lock-in>Frequency (Hz) 973E+0 # Sets the frequency of the sine modulation added to the signal to modulate. The frequency range is from 10 mHz to 40 kHz (corresponding to the SC5 output filter cut-off). When working with harmonics, make sure the harmonic frequencies don’t exceed ~100 kHz (SC5 input filter cut-off). Remember the SC5 hardware filters will affect the amplitude when getting close to their cut-off frequencies. - # amplitude: Lock-in>Amplitude 2E-3 # Sets the amplitude (in physical units of the modulated signal) of the sine modulation. - # demodulated_signal: Lock-in>Demodulated signal Current (A) # This is the signal which will be demodulated, in order to determine the amplitude and phase at the frequency set in the Frequency field (“4”) or harmonics. + # frequency: Lock-in>Frequency (Hz) 973E+0 # Sets the frequency of the sine modulation + # added to the signal to modulate. The frequency range is from 10 mHz to 40 kHz + # (corresponding to the SC5 output filter cut-off). When working with harmonics, make + # sure the harmonic frequencies don’t exceed ~100 kHz (SC5 input filter cut-off). + # Remember the SC5 hardware filters will affect the amplitude when getting close to + # their cut-off frequencies. + # amplitude: Lock-in>Amplitude 2E-3 # Sets the amplitude (in physical units of the + # modulated signal) of the sine modulation. + # demodulated_signal: Lock-in>Demodulated signal Current (A) # This is the signal which + # will be demodulated, in order to determine the amplitude and phase at the frequency + # set in the Frequency field (“4”) or harmonics. # order_of_harmonics: - # Lock-in>Harmonic D1 1 # Order of the harmonic oscillation to detect on the demodulated signal (with respect to the modulation frequency). If you work with higher harmonics make sure the frequency does not exceed the analog signal bandwidth (100 kHz). + # Lock-in>Harmonic D1 1 # Order of the harmonic oscillation to detect on the demodulated + # signal (with respect to the modulation frequency). If you work with higher harmonics + # make sure the frequency does not exceed the analog signal bandwidth (100 kHz). # Lock-in>Harmonic D2 2 # See below. # ref_phase: - # Lock-in>Reference phase D1 (deg) 137.597E+0 # Reference phase for the sine on the demodulated signal with respect to the modulation signal. The determined phase (phi) is displayed with respect to the reference phase. + # Lock-in>Reference phase D1 (deg) 137.597E+0 # Reference phase for the sine on the + # demodulated signal with respect to the modulation signal. The determined phase + # (phi) is displayed with respect to the reference phase. # Lock-in>Reference phase D2 (deg) -83.6562E+0 # See below. # items below should go to bias/spectroscopy/...!!! #recorded_channels: - # doc: Select the channels to record. (e.g. Current (A);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A) # Select the channels to record.) + # doc: Select the channels to record. (e.g. Current (A);LI Demod 2 X (A);LI Demod 2 Y (A); + # LI Demod 1 X (A);LI Demod 1 Y (A) # Select the channels to record.) #bias_reset: - # doc: When selected, the Bias voltage returns to the initial value (before starting the sweep) at the end of the spectroscopy measurement (default). When not selected, Bias remains at the last value of the sweep. This is useful e.g. when combining several sweep segments. Example for an automated measurement (using Programming Interface): switch off Z-Controller, start spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, switch on Z-Controller. (e.g. TRUE) + # doc: When selected, the Bias voltage returns to the initial value (before starting the + # sweep) at the end of the spectroscopy measurement (default). When not selected, Bias + # remains at the last value of the sweep. This is useful e.g. when combining several + # sweep segments. Example for an automated measurement (using Programming Interface): + # switch off Z-Controller, start spectroscopy sweep segments (only fwd sweep, no reset + # bias), set bias back to initial value, switch on Z-Controller. (e.g. TRUE) #record_final_z: - # doc: Select whether to record the Z position during Z averaging time at the end of the sweep (after Z control time) and store the average value in the header of the file when saving. Using this option increases the sweep time by Z averaging time. (e.g. FALSE) + # doc: Select whether to record the Z position during Z averaging time at the end of the + # sweep (after Z control time) and store the average value in the header of the file + # when saving. Using this option increases the sweep time by Z averaging time. (e.g. FALSE) #run: - # doc: Bias Spectroscopy>Lock-In run FALSE # Select whether to set the Lock-In to run during the measurement. When using this feature, make sure the Lock-In is configured correctly and settling times are set to twice the Lock-In period at least. This option is ignored when Lock-In is already running. This option is disabled if the Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline segment editor is set. + # doc: Bias Spectroscopy>Lock-In run FALSE # Select whether to set the Lock-In to run + # during the measurement. When using this feature, make sure the Lock-In is configured + # correctly and settling times are set to twice the Lock-In period at least. This + # option is ignored when Lock-In is already running. This option is disabled if the + # Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline + # segment editor is set. sample_bias(NXiv_bias): bias(NX_NUMBER): unit: NX_VOLTAGE doc: Applied a voltage between tip and sample. - # sample_bias(NXbias): - # Tip bias/Sample bias If the spectroscopy V bias is applied to the - # Modulated signal Bias (V) 1E-3 Applied modulation to the bias voltage. - # ModulationBias> Tip bias/Sample bias - # modulated_signal_bias(NX_NUMBER): - # unit: NX_VOLTAGE - # doc: Same directional representation as bias. (e.g. 1E-3) + # sample_bias(NXbias): + # Tip bias/Sample bias If the spectroscopy V bias is applied to the + # Modulated signal Bias (V) 1E-3 Applied modulation to the bias voltage. + # ModulationBias> Tip bias/Sample bias + # modulated_signal_bias(NX_NUMBER): + # unit: NX_VOLTAGE + # doc: Same directional representation as bias. (e.g. 1E-3) stm_head_temp(NX_NUMBER): exists: optional unit: NX_TEMPERATURE doc: | - Temperature of STM head. Temperature 1 (K) (e.g. 4.92997E+0). Note: At least - one field from stm_head_temperature, cryo_bottom_temp and + Temperature of STM head. + Note: At least one field from stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp must be provided. cryo_bottom_temp(NX_NUMBER): exists: optional unit: NX_TEMPERATURE doc: | - Temperature of LHe helium cryostat. Temperature 2 (K) (e.g 4.92997E+0). Note: At - least one field from stm_head_temperature, cryo_bottom_temp and - cryo_sheild_temp must be provided. + Temperature of LHe helium cryostat. Note: At least one field from + stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp must be provided. cryo_shield_temp(NX_NUMBER): exists: optional unit: NX_TEMPERATURE doc: | Temperature of LN2 nitrogen shield. Temperature 3 (K) (e.g 78.00000E+0). Note: At - least one field from stm_head_temperature, cryo_bottom_temp and - cryo_sheild_temp must be provided. - # TODO: after fixing the sxm remove the optional field + least one field from stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp + must be provided. output_cabling(NXcircuit): exists: optional + doc: | + NOte_ no doc. + # Cabling & Config # output_mode: # doc: Number of output channels. (e.g. User Output) @@ -129,6 +161,10 @@ NXiv_sweep2(NXsensor_scan): # output_slew_rate(NX_NUMBER): # doc: The rate at which the one of the signal changes when ramping to the starting point. (V/s) (e.g. Inf) piezo_config(NXcollection): + doc: | + Configuration for piezoelectric scanner used to move tip along X and Y direction. The + material of the Piezoelectric scanner composed of polycrystalline solids and nsensitve to + applied voltage. active_calib: doc: The name of caliberation type. (e.g. LHe) calib_N(NX_NUMBER): @@ -137,44 +173,51 @@ NXiv_sweep2(NXsensor_scan): N denotes X or Y or Z. There are 3 parameters in X, Y, and Z directions and there are 3 controls availables: Calibr. (m/V), Range (m) and HV gain. Two of them are enough to define the calibration, so when changing any value one of the other values - will be updated automatically. (e.g. 3.8E-9) + will be updated automatically. (e.g. 3.8E-9) hv_gain_N(NX_NUMBER): exists: optional doc: N denotes X or Y or Z. For some systems HV gain readout is available, - so for those systems the HV gain should be adjusted automatically when the gain is changed at the high voltage amplifier. (e.g. 14.5) + so for those systems the HV gain should be adjusted automatically when the gain + is changed at the high voltage amplifier. (e.g. 14.5) # (e.g. 0.318343) tilt_N(NX_NUMBER): exists: optional unit: NX_ANGLE - doc: N denotes X or Y. There are 2 parameters in X and Y directions and this tab is used to set the sample tilt (in degrees, first order correction). + doc: | + N denotes X or Y. There are 2 parameters in X and Y directions and this tab + is used to set the sample tilt (in degrees, first order correction). # Inf curvature_radius_N(NX_NUMBER): exists: optional unit: NX_LENGTH - doc: N denotes X or Y. There are 2 parameters in X and Y directions and this tab is used to set a curvature (can be set approximately to the length of the piezotube). + doc: N denotes X or Y. There are 2 parameters in X and Y directions and this tab + is used to set a curvature (can be set approximately to the length of the piezotube). 2nd_order_corr_N(NX_NUMBER): exists: optional doc: | - N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2). (e.g. 0E+0) + N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, + you can enter the 2nd order piezo characteristics to compensate for it. The + following equation shows the interpretation of the 2nd order correction parameter: + For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: + [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx + is the 2nd order correction. (V/m^2). (e.g. 0E+0) drift_N(NX_NUMBER): exists: optional - doc: N denotes X, Y or Z. There are 3 parameters in X, Y and Z directions. Define the drift - speed for all three axes. When the compensation is on, the piezos will start to move at - that speed. (e.g. 0E+0) + doc: | + N denotes X, Y or Z. There are 3 parameters in X, Y and Z directions. Define the + drift speed for all three axes. When the compensation is on, the piezos will start to + move at that speed. (e.g. 0E+0) drift_correction_status(NX_BOOLEAN): doc: Use the button to turn on/off the drift compensation. (e.g. FALSE) (NXenvironment): doc: | Describes an environment setup for a temperature-dependent IV measurement experiment. - The temperature and voltage must be present as independently scanned controllers and the current sensor must also be present with its readings. - # TODO: Bellow command must be removed later. These are commented because we are - # while generation template getting error in this - # voltage_controller(NXsensor): - # exists: optional - # temperature_controller(NXsensor): - # current_sensor(NXsensor): + voltage_controller(NXsensor): + exists: optional + temperature_controller(NXsensor): + current_sensor(NXsensor): position(NXpositioner): doc: Clarify the frame laboratory frame. x(NX_NUMBER): From bcf5b0a0d659461940d3ef0913ee43a40d674538 Mon Sep 17 00:00:00 2001 From: Rubel Date: Tue, 20 Jun 2023 21:18:51 +0200 Subject: [PATCH 0156/1012] Little chages in NXiv_sweep2 and NXlockin. --- contributed_definitions/NXiv_sweep2.nxdl.xml | 1012 ++++++++--------- contributed_definitions/NXlockin.nxdl.xml | 10 +- .../nyaml/NXiv_sweep2.yaml | 789 ++++++------- contributed_definitions/nyaml/NXlockin.yaml | 12 +- 4 files changed, 901 insertions(+), 922 deletions(-) diff --git a/contributed_definitions/NXiv_sweep2.nxdl.xml b/contributed_definitions/NXiv_sweep2.nxdl.xml index 998b9a8849..f33be4eda7 100644 --- a/contributed_definitions/NXiv_sweep2.nxdl.xml +++ b/contributed_definitions/NXiv_sweep2.nxdl.xml @@ -21,10 +21,14 @@ # # For further information, see http://www.nexusformat.org --> - + + - Application definition for temperature-dependent IV curve measurements, #CAP with a focus on bias spectroscopy in scanning tunneling microscopy. + Application definition for temperature-dependent IV curve measurements, + NOTE_: What is CAP + #CAP with a focus on bias spectroscopy in scanning tunneling microscopy. In this application definition, times should be specified always together with an UTC offset. @@ -33,14 +37,16 @@ measurements. For this a temperature is set. After reaching the temperature, a voltage sweep is performed. For each voltage a current is measured. Then, the next desired temperature is set and an IV measurement is performed. - #CAP the X, Y, Z, position of the probes or tip can be defined. #CAP The data can be visualized in a tensor with: - I (NXsensor_C, NXsoftware_Read_offset, NXcircuit) - parameters: - V has (NXsource+offset, NXsoftware_Scan_offset, NXsensor_V, NXcircuit) - T has (NXsource, NXsoftware_Scan_offset, NXsensor_T) - x has (NXsoftware_Scan_offset) - y has (NXsoftware_Scan_offset) - z has (NXsoftware_Scan_offset) + NOTE_ : The text below is not comprehensive Should they be in symbol + #CAP the X, Y, Z, position of the probes or tip can be defined. + #CAP The data can be visualized in a tensor with: + I (NXsensor_C, NXsoftware_Read_offset, NXcircuit) + parameters: + V has (NXsource+offset, NXsoftware_Scan_offset, NXsensor_V, NXcircuit) + T has (NXsource, NXsoftware_Scan_offset, NXsensor_T) + x has (NXsoftware_Scan_offset) + y has (NXsoftware_Scan_offset) + z has (NXsoftware_Scan_offset) @@ -48,11 +54,13 @@ - + - The equipment and techniques as well as the parameter settings and reference signals - are used during the experiments used in the scanning tunneling microscopy. + The equipments and techniques as well as the parameter settings and reference signals + are used during the experiments used in the scanning tunneling microscopy(STM). + @@ -78,532 +86,486 @@ Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711) - + + + Descriptive comments for this experiment, added by the experimenter, coming from the + output file. (e.g. Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, locked Au(111), + 50pA, 100 mV set point, 1mV DCA, 973Hz,138 1st H, -84 2nd H) + + - - - - - - - - - - - - Applied a voltage between tip and sample. - - - - - + + - Temperature of STM head. Temperature 1 (K) (e.g. 4.92997E+0). Note: At least - one field from stm_head_temperature, cryo_bottom_temp and - cryo_sheild_temp must be provided. + Hardware type used in SPM experiment, includes hardware manufacturers and type. + (e.g. Nanonis BP5e) - - + + + - Temperature of LHe helium cryostat. Temperature 2 (K) (e.g 4.92997E+0). Note: At - least one field from stm_head_temperature, cryo_bottom_temp and - cryo_sheild_temp must be provided. + Type of software used in SPM experiments, e.g. software version serial number, UI and + RT probe release method. (e.g. SW Version Generic 5e -- SoftwareMain>UI Release 10771 + -- SoftwareMain>RT Release 10771) + # hardware: Current amplifier> hardware: CreaTec GmbH - - + + + - Temperature of LN2 nitrogen shield. Temperature 3 (K) (e.g 78.00000E+0). Note: At - least one field from stm_head_temperature, cryo_bottom_temp and - cryo_sheild_temp must be provided. + The Amplifier description that improves or helps to determine tunnel current (current between tip and bias). - - - - - - - - The name of caliberation type. (e.g. LHe) - - - - - N denotes X or Y or Z. There are 3 parameters in X, Y, and Z directions and there - are 3 controls availables: Calibr. (m/V), Range (m) and HV gain. Two of them are - enough to define the calibration, so when changing any value one of the other values - will be updated automatically. (e.g. 3.8E-9) - - - - - N denotes X or Y or Z. For some systems HV gain readout is available, so for - those systems the HV gain should be adjusted automatically when the gain is - changed at the high voltage amplifier. (e.g. 14.5) - - - - - - N denotes X or Y. There are 2 parameters in X and Y directions and this tab is - used to set the sample tilt (in degrees, first order correction). - - - - - - N denotes X or Y. There are 2 parameters in X and Y directions and this tab is - used to set a curvature (can be set approximately to the length of the - piezotube). - - - - - N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2). (e.g. 0E+0) - - - + + + + - N denotes X, Y or Z. There are 3 parameters in X, Y and Z directions. Define the - drift speed for all three axes. When the compensation is on, the piezos will - start to move at that speed. (e.g. 0E+0) + Status of Lock-in device whether while ferfoming the experiment - + + + - Use the button to turn on/off the drift compensation. (e.g. FALSE) + The input signal (STS signal) will be demodulated, in order to determine the amplitude + and phase at the frequency set in the Frequency field or harmonics, such as current, + bias, et.al. - - - Describes an environment setup for a temperature-dependent IV measurement experiment. - - The temperature and voltage must be present as independently scanned controllers and - the current sensor must also be present with its readings. - - - - - Clarify the frame laboratory frame. - - - - The scanning area in x position in the frame. (e.g. -890.53E-12) - - - - - The scanning area in y position in the frame. (e.g. 29.6968E-9) - - - - - The scanning area in x position in the frame. (e.g. 130.5E-9) - - - - - Indicate the tip position Z between tip and sample. The tip position can also be - varied when the controller is not running. (e.g. 130.5E-9) - - - - - - - - - Time during which the spectroscopy data are acquired and averaged. (e.g. 150E-6) - - - - - Number of sweeps to measure and average. (e.g. 100) - - - - - The first bias values of the sweep. (e.g. -300E-3) - - - - - The last bias values of the sweep. (e.g. 300E-3) - - - - - Define the sweep number of points, that is, the maximum spectrum resolution eq. - Bias window divide by Num Pixel. (e.g. 4096) - - - - - Duration over which the Z position is recorded and averaged before and after the - sweep (the latter only if Record final Z position is selected in the Advanced - section). After the initial Z averaging time, if Z-Controller to Hold is - selected in the Advanced section, the Z-Controller is set to hold and the tip is - placed at the previously averaged Z position (plus Z offset). (e.g. 100E-3) - - - - - - - The bandwitdh of the Hardware and/or Software (e.g. 20E+3) - - - - - (Signals Periods) The Signals Period is the rate at which the signals are - transferred to the host computer running the control software. This is usually - lower by a factor of 10 than the sampling rate, because an internal oversampling - of the signal is done on the real time engine. You can reduce the oversampling - down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. (e.g. - 10) - - - - - Update rate for several processes like History Graph, Auto-Approach, and for - many Programming Interface functions. This is usually set to 20 ms. All - additional timings (7-9) can only be integer multiples of this value. They can - be set to different values, but the actual timing value will be coerced to a - multiple of the Acquisition Period. (e.g. 20E-3) - - - - - Update rate of animated graphical indicators. These are e.g. some graphs & - sliders. A reasonable value is 40 ms (25 updates per second). Increase this - period to reduce the processor load for the graphical user interface, especially - on slow computers. This value is purely a user interface update rate and does - not affect measurements in any way. (e.g. 20E-3) - - - - - Update rate of digital indicators, e.g. the numbers displayed besides each - slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a - user interface update rate and does not affect measurements in any way. (e.g. - 300E-3) - - - - - The Measurements period is the integration time for precise measurements - (averaging over specified period), mostly used in sweep modules. Examples are - recording of a force-distance curve or a resonance of a cantilever. For fast - measurements with small steps, a value of 40 ms may be reasonable. For normal - use, 300-500 ms is a good value, but for recording a resonance of a high-Q - cantilever, values of several seconds might be necessary. Usually this parameter - doesn’t need to be set from this module; the sweep modules will set this value - according to the sweep timings. (e.g. 500E-3) - - - - - - - - - - Also clarify the frame for the ROI of the scan (should depend on the lab frame) - - - - - - - The scan channels are selected by users. (e.g. (A);Bias (V);Z (m);LI Demod 2 X - (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A)) - - - - - - - Configure the scan frame like x position; y position; width; height. (e.g. - 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0) - - - - - Scan resolution by setting the Lines equal to Pixels. (e.g. 512) - - - - - Define the image resolution. (e.g. 512) - - - - - Define the scan forward speed in the forward direction. (m/s) (e.g. 11.7187E-9) - - - - - Define the scan backward speed in the forward direction. (m/s) (e.g. 11.7187E-9) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. - There should also be two more fields called temperature and voltage containing the setpoint values. - There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension - equal to the number of voltage setpoints. - axes: bias_calc - signals: - li_demod_[1;2]_[X/Y]_[-;bwd;filt;bwd_filt] - current_[-;bwd;filt;bwd_filt] - temperature - x - y - z - - - - - - - - - - + + diff --git a/contributed_definitions/NXlockin.nxdl.xml b/contributed_definitions/NXlockin.nxdl.xml index 1b4c4f2a82..ddf2e8a054 100644 --- a/contributed_definitions/NXlockin.nxdl.xml +++ b/contributed_definitions/NXlockin.nxdl.xml @@ -69,9 +69,9 @@ - The input signal (STS signal) will be demodulated, in order to determine the - amplitude and phase at the frequency set in the Frequency field or harmonics, - such as current, bias, et.al. + The input signal (STS signal) will be demodulated, in order to determine the amplitude + and phase at the frequency set in the Frequency field or harmonics, such as current, + bias, et.al. @@ -125,7 +125,7 @@ (foreach DemodulatorChannels) - + Reference phase for the sine on the demodulated signal with respect to the modulation signal. (foreach DemodulatorChannels) @@ -136,7 +136,7 @@ Time during which the data are acquired and averaged. (for the input filter) - + The order of the harmonic oscillation to detect on the demodulated signals. (with respect to the modulation frequency) diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index f5bd1701a8..73c9d66990 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -66,29 +66,42 @@ NXiv_sweep2(NXsensor_scan): doc: | The Amplifier description that improves or helps to determine tunnel current (current between tip and bias). lock_in(NXlockin): - exists: optional - # status: Lock-in>Lock-in status ON # ON/OFF of Lock-in amplifier + status: + # status: Lock-in>Lock-in status ON # ON/OFF of Lock-in amplifier + doc: | + Status of Lock-in device whether while ferfoming the experiment # amplifier_status: -> amplifier/active_channels - # doc: Lock-in Amplifier>Yes/No # If a lock-in amplifier employed to filter or obtain the electronic derivatives dI/dV of the signal + # Lock-in Amplifier>Yes/No + # doc: Lock-in Amplifier>Yes/No # If a lock-in amplifier employed to filter or obtain + # the electronic derivatives dI/dV of the signal # hardware: Lock-in Amplifier>Hardware: Nanonis + # modulation_signal: # modulate_signal: Lock-in>Modulated signal Bias (V) # This is the signal on which the modulation (sine) will be added. - # frequency: Lock-in>Frequency (Hz) 973E+0 # Sets the frequency of the sine modulation + # modulation_frequency: + # Lock-in>Frequency (Hz) 973E+0 # Sets the frequency of the sine modulation # added to the signal to modulate. The frequency range is from 10 mHz to 40 kHz # (corresponding to the SC5 output filter cut-off). When working with harmonics, make # sure the harmonic frequencies don’t exceed ~100 kHz (SC5 input filter cut-off). # Remember the SC5 hardware filters will affect the amplitude when getting close to # their cut-off frequencies. + # modulation_amplitude: # amplitude: Lock-in>Amplitude 2E-3 # Sets the amplitude (in physical units of the # modulated signal) of the sine modulation. - # demodulated_signal: Lock-in>Demodulated signal Current (A) # This is the signal which + demodulated_signal: + #Lock-in>Demodulated signal Current (A) # This is the signal which # will be demodulated, in order to determine the amplitude and phase at the frequency # set in the Frequency field (“4”) or harmonics. - # order_of_harmonics: + doc: | + The input signal (STS signal) will be demodulated, in order to determine the amplitude + and phase at the frequency set in the Frequency field or harmonics, such as current, + bias, et.al. + + # harmonic_order_N: # Lock-in>Harmonic D1 1 # Order of the harmonic oscillation to detect on the demodulated # signal (with respect to the modulation frequency). If you work with higher harmonics # make sure the frequency does not exceed the analog signal bandwidth (100 kHz). # Lock-in>Harmonic D2 2 # See below. - # ref_phase: + # ref_phase_N: # Lock-in>Reference phase D1 (deg) 137.597E+0 # Reference phase for the sine on the # demodulated signal with respect to the modulation signal. The determined phase # (phi) is displayed with respect to the reference phase. @@ -115,385 +128,385 @@ NXiv_sweep2(NXsensor_scan): # option is ignored when Lock-In is already running. This option is disabled if the # Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline # segment editor is set. - sample_bias(NXiv_bias): - bias(NX_NUMBER): - unit: NX_VOLTAGE - doc: Applied a voltage between tip and sample. - # sample_bias(NXbias): - # Tip bias/Sample bias If the spectroscopy V bias is applied to the - # Modulated signal Bias (V) 1E-3 Applied modulation to the bias voltage. - # ModulationBias> Tip bias/Sample bias - # modulated_signal_bias(NX_NUMBER): - # unit: NX_VOLTAGE - # doc: Same directional representation as bias. (e.g. 1E-3) - stm_head_temp(NX_NUMBER): - exists: optional - unit: NX_TEMPERATURE - doc: | - Temperature of STM head. - Note: At least one field from stm_head_temperature, cryo_bottom_temp and - cryo_sheild_temp must be provided. - cryo_bottom_temp(NX_NUMBER): - exists: optional - unit: NX_TEMPERATURE - doc: | - Temperature of LHe helium cryostat. Note: At least one field from - stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp must be provided. - cryo_shield_temp(NX_NUMBER): - exists: optional - unit: NX_TEMPERATURE - doc: | - Temperature of LN2 nitrogen shield. Temperature 3 (K) (e.g 78.00000E+0). Note: At - least one field from stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp - must be provided. - output_cabling(NXcircuit): - exists: optional - doc: | - NOte_ no doc. + # sample_bias(NXiv_bias): + # bias(NX_NUMBER): + # unit: NX_VOLTAGE + # doc: Applied a voltage between tip and sample. + # # sample_bias(NXbias): + # # Tip bias/Sample bias If the spectroscopy V bias is applied to the + # # Modulated signal Bias (V) 1E-3 Applied modulation to the bias voltage. + # # ModulationBias> Tip bias/Sample bias + # # modulated_signal_bias(NX_NUMBER): + # # unit: NX_VOLTAGE + # # doc: Same directional representation as bias. (e.g. 1E-3) + # stm_head_temp(NX_NUMBER): + # exists: optional + # unit: NX_TEMPERATURE + # doc: | + # Temperature of STM head. + # Note: At least one field from stm_head_temperature, cryo_bottom_temp and + # cryo_sheild_temp must be provided. + # cryo_bottom_temp(NX_NUMBER): + # exists: optional + # unit: NX_TEMPERATURE + # doc: | + # Temperature of LHe helium cryostat. Note: At least one field from + # stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp must be provided. + # cryo_shield_temp(NX_NUMBER): + # exists: optional + # unit: NX_TEMPERATURE + # doc: | + # Temperature of LN2 nitrogen shield. Temperature 3 (K) (e.g 78.00000E+0). Note: At + # least one field from stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp + # must be provided. + # output_cabling(NXcircuit): + # exists: optional + # doc: | + # NOte_ no doc. - # Cabling & Config - # output_mode: - # doc: Number of output channels. (e.g. User Output) - # output_value(NX_NUMBER): - # doc: The user output in each monitor mode. (e.g. 0E+0) - # output_name: - # doc: User outputs whose name can be modified in the corresponding module. (e.g. Input 24 (V)) - # output_slew_rate(NX_NUMBER): - # doc: The rate at which the one of the signal changes when ramping to the starting point. (V/s) (e.g. Inf) - piezo_config(NXcollection): - doc: | - Configuration for piezoelectric scanner used to move tip along X and Y direction. The - material of the Piezoelectric scanner composed of polycrystalline solids and nsensitve to - applied voltage. - active_calib: - doc: The name of caliberation type. (e.g. LHe) - calib_N(NX_NUMBER): - exists: optional - doc: | - N denotes X or Y or Z. There are 3 parameters in X, Y, and Z directions and there - are 3 controls availables: Calibr. (m/V), Range (m) and HV gain. Two of them are - enough to define the calibration, so when changing any value one of the other values - will be updated automatically. (e.g. 3.8E-9) - hv_gain_N(NX_NUMBER): - exists: optional - doc: N denotes X or Y or Z. For some systems HV gain readout is available, - so for those systems the HV gain should be adjusted automatically when the gain - is changed at the high voltage amplifier. (e.g. 14.5) - # (e.g. 0.318343) - tilt_N(NX_NUMBER): - exists: optional - unit: NX_ANGLE - doc: | - N denotes X or Y. There are 2 parameters in X and Y directions and this tab - is used to set the sample tilt (in degrees, first order correction). - # Inf - curvature_radius_N(NX_NUMBER): - exists: optional - unit: NX_LENGTH - doc: N denotes X or Y. There are 2 parameters in X and Y directions and this tab - is used to set a curvature (can be set approximately to the length of the piezotube). - 2nd_order_corr_N(NX_NUMBER): - exists: optional - doc: | - N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, - you can enter the 2nd order piezo characteristics to compensate for it. The - following equation shows the interpretation of the 2nd order correction parameter: - For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: - [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx - is the 2nd order correction. (V/m^2). (e.g. 0E+0) - drift_N(NX_NUMBER): - exists: optional - doc: | - N denotes X, Y or Z. There are 3 parameters in X, Y and Z directions. Define the - drift speed for all three axes. When the compensation is on, the piezos will start to - move at that speed. (e.g. 0E+0) - drift_correction_status(NX_BOOLEAN): - doc: Use the button to turn on/off the drift compensation. (e.g. FALSE) - (NXenvironment): - doc: | - Describes an environment setup for a temperature-dependent IV measurement experiment. - The temperature and voltage must be present as independently scanned controllers and - the current sensor must also be present with its readings. - voltage_controller(NXsensor): - exists: optional - temperature_controller(NXsensor): - current_sensor(NXsensor): - position(NXpositioner): - doc: Clarify the frame laboratory frame. - x(NX_NUMBER): - exists: optional - unit: NX_LENGTH - doc: The scanning area in x position in the frame. (e.g. -890.53E-12) - y(NX_NUMBER): - exists: optional - unit: NX_LENGTH - doc: The scanning area in y position in the frame. (e.g. 29.6968E-9) - z(NX_NUMBER): - exists: optional - unit: NX_LENGTH - doc: The scanning area in x position in the frame. (e.g. 130.5E-9) - z_controller(NX_NUMBER): - unit: NX_LENGTH - doc: Indicate the tip position Z between tip and sample. The tip position can also be varied when the controller is not running. (e.g. 130.5E-9) - # parameters for a measurement at a single location during the scan - sweep_control(NXcollection): - bias_spectroscopy(NXbias_spectroscopy): - integration_time(NX_NUMBER): - unit: NX_TIME - doc: Time during which the spectroscopy data are acquired and averaged. (e.g. 150E-6) - number_of_sweeps(NX_NUMBER): - doc: Number of sweeps to measure and average. (e.g. 100) - sweep_start(NX_NUMBER): - unit: NX_VOLTAGE - doc: The first bias values of the sweep. (e.g. -300E-3) - sweep_end(NX_NUMBER): - unit: NX_VOLTAGE - doc: The last bias values of the sweep. (e.g. 300E-3) - num_pixel(NX_NUMBER): - doc: Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. (e.g. 4096) - z_avg_time(NX_NUMBER): - unit: NX_TIME - doc: Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). (e.g. 100E-3) - circuit(NXcollection): - rt_frequency(NX_NUMBER): - unit: NX_FREQENCY - doc: The bandwitdh of the Hardware and/or Software (e.g. 20E+3) - signals_oversampling(NX_NUMBER): - doc: (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. (e.g. 10) - acquisition_period(NX_NUMBER): - unit: NX_TIME - exists: optional - doc: Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. (e.g. 20E-3) - animations_period(NX_NUMBER): - unit: NX_TIME - exists: optional - doc: Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. (e.g. 20E-3) - indicators_period(NX_NUMBER): - unit: NX_TIME - doc: Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. (e.g. 300E-3) - measurements_period(NX_NUMBER): - exists: optional - unit: NX_TIME - doc: The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. (e.g. 500E-3) - # parameters how to change the location from measurement to measurement during the scan - scan_control(NXcollection): - exists: optional - roi(NXtransformations): - frame: - doc: Also clarify the frame for the ROI of the scan (should depend on the lab frame) - circuit(NXcollection): - channels_current: - doc: The scan channels are selected by users. (e.g. (A);Bias (V);Z (m);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A)) - positioner(NXcollection): - scanfield(NX_NUMBER): - doc: Configure the scan frame like x position; y position; width; height. (e.g. 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0) - pixels_line(NX_NUMBER): - doc: Scan resolution by setting the Lines equal to Pixels. (e.g. 512) - lines(NX_NUMBER): - doc: Define the image resolution. (e.g. 512) - speed_forw(NX_NUMBER): - doc: Define the scan forward speed in the forward direction. (m/s) (e.g. 11.7187E-9) - speed_backw(NX_NUMBER): - doc: Define the scan backward speed in the forward direction. (m/s) (e.g. 11.7187E-9) - # RESOLUTION (calculation input) - # TODO: After fix resolution_indicators back to required - # As all of the bellow are linked - resolution_indicators(NXprocess): - exists: optional - # Temperature 1>link to INSTR/STM/head Temperature 1 (K) (e.g. 4.92997E+0) # Temperature of STM head. - temp_stm_head: - # Temperature 2>link to Temperature 2 (K) - # Temperature of bottom of LHe helium cryostat. - temp_cryo_bottom: - # Temperature 3>link to Temperature 3 (K) - # Temperature of LN2 nitrogen shield. - temp_cryo_shield: - # Lock-in>link to Modulated signal Bias (V) (e.g. 1E-3) # Applied modulation to the bias voltage. - modulated_signal_bias: - # link to Integration time (s) (e.g. 150E-6) # Time during which the spectroscopy data are acquired and averaged. - integration_time: - # link to Bias Spectroscopy>Number of sweeps (e.g. 100) # Number of sweeps to measure and average. - number_of_sweps: - # link to Bias Spectroscopy>Sweep Start (V) (e.g. -300E-3) # The first bias values of the sweep. - sweep_start: - # link to Bias Spectroscopy>Sweep End (V) (e.g. 300E-3) # The last bias values of the sweep. - sweep_end: - # link to Bias Spectroscopy>Num Pixel (e.g. 4096) # Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. - number_of_pixels: - # link to Bias Spectroscopy>Z Avg time (s) (e.g. 100E-3) # Duration over which the Z - # position is recorded and averaged before and after the sweep (the latter only if Record - # final Z position is selected in the Advanced section). After the initial Z averaging - # time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is - # set to hold and the tip is placed at the previously averaged Z position (plus Z offset). - z_avg_time: - # link to SoftwareMain>RT Frequency (Hz) (e.g. 20E+3) # The bandwitdh of the - # Hardware and/or Software - rt_freq: - # link to SoftwareMain>Signals Oversampling (e.g. 10) # (Signals Periods) - # The Signals Period is the rate at which the signals are transferred to the host computer - # running the control software. This is usually lower by a factor of 10 than the sampling - # rate, because an internal oversampling of the signal is done on the real time engine. - # You can reduce the oversampling down to 1 in order to resolve higher frequencies in the - # Spectrum Analyzer. - oversampling: - # link to SoftwareMain>Acquisition Period (s) (e.g. 20E-3) # Update rate for several - # processes like History Graph, Auto-Approach, and for many Programming Interface functions. - # This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples - # of this value. They can be set to different values, but the actual timing value will be - # coerced to a multiple of the Acquisition Period. - acquisition_period: - # link to SoftwareMain>Animations Period (s) (e.g. 20E-3) # Update rate of animated - # graphical indicators. These are e.g. some graphs & sliders. A reasonable value is - # 40 ms (25 updates per second). Increase this period to reduce the processor load - # for the graphical user interface, especially on slow computers. This value is purely a - # user interface update rate and does not affect measurements in any way. - animation_period: - # link to SoftwareMain>Indicators Period (s) (e.g. 300E-3) # Update rate of digital - # indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per - # second, or 300 ms is enough. This value is purely a user interface update rate and - # does not affect measurements in any way. - indicators_period: - # link to SoftwareMain>Measurements Period (s) (e.g. 500E-3) # The Measurements - # period is the integration time for precise measurements (averaging over specified period), - # mostly used in sweep modules. Examples are recording of a force-distance curve or a - # resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be - # reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a - # high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. - measurement_period: - # TODO: Later fix REPRODUCIBILITY_indicator - # as all of the bellow are linked - reproducibility_indicators(NXprocess): - exists: optional - # Bias>Bias(NXBias) (V) (e.g. 100E-3) # Applied bias voltage. - bias: - # Current>Current(NXcircuit) (A) (e.g. -5.3429E-15) # The tunneling current is displayed here. - current: - # Bias>Calibration(NXbias) (V/V) (e.g. 1E+0) Calibration of the Bias output. If you have a Range switch the calibration is stored per range setting. - bias_calibration: - # Bias>Offset(NXbias) (V) (e.g. 0E+0) Allows compensating for an offset in Bias. - bias_offset: - # Current>Calibration(NXcircuit) (A/V) (e.g. 100E-12) - # The signals voltages are converted to real world physical values according to the calibration & offset parameters: - # Physical signal = (Voltage * calibration) + offset. - current_calibration: - # Current>Offset(NXcircuit) (A) (e.g. 16.2897E-15) # The same as "Current>Calibration (A/V)" tag - current_offset: - # Current>Gain(NXcircuit) (e.g. Not switchable) # None - current_gain: - # Z offset(NXpositioner) (m) (e.g. 0E+0) # Offset added to the initial averaged position - # Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is - # deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an - # alternate Z-controller setpoint is enabled. - z_offset: - # Settling time(NXbias) (s) (e.g. 2.1E-3) Time to wait after changing the bias to the next - # level and before starting to acquire data. Adjust this parameter to avoid transient - # effect induced by the bias change. Integration time: time during which the data are - # acquired and averaged. - settling_time: - # Z-Ctrl hold(NXpositioner) (e.g. TRUE) # When selected, the Z-Controller is set to hold - # during the pulse. This means that the controller doesn't control the Z position during the pulse. - z_control_hold: - # Final Z(NXpositioner) (m) (e.g. N/A) - final_z: - # Start time(NXlog) (e.g.23.11.2022 18:55:16) # Timestamp of the moment when the acquisition starts by pressing the Start button. - start_time: - # Bias Spectroscopy>1st Settling time(NXbias) (s) (e.g.2.1E-3) # See the "Settling time (s)" below. - 1st_settling_time: - # Bias Spectroscopy>Integration time(NXbias) (s) (e.g.150E-6) # Time during which the data - # are acquired and averaged. - integration_time: - # Bias Spectroscopy>End Settling time(NXbias) (s) (e.g.4E-3) # Time to wait after the sweep has finished and the bias is ramped to the initial value. - end_settling_time: - # Bias Spectroscopy>Z control time(NXbias) (s) (e.g.200E-3) # Time during which the - # Z-Controller is enabled once a sweep has finished. When averaging multiple sweeps - # (i.e. Sweeps>1), the Z-Controller is enabled for this duration between each sweep. - # After the last sweep, it will wait the specified time before continuing a running scan. - # This ensures each sweep reliably starts from the same position. This parameter is - # disabled when Z-Controller to Hold is deselected in the Advanced section. - z_contro_time: - # Bias Spectroscopy>Max Slew rate(NXbias) (V/s) (e.g.1E+0) # Maximum rate at which - # the bias changes (before, during and after sweeping). - max_slew_rate: - # Bias Spectroscopy>backward sweep(NXbias) (e.g.TRUE) # Select whether to measure - # the backward (return) sweep or the forward only. - backward_sweep: - # Z-Controller>Controller name(NXpositioner) (e.g.log Current) # Controller name. - # This name which will be displayed at places where you can select a controller. - z_control_name: - # Z-Controller>Controller status(NXpositioner) (e.g.OFF) # ON/OFF - z_control_status: - # Z-Controller>Setpoint(NXpositioner) (e.g.50E-12) # Set Point is the desired value - # of the control signal. It can be set by editing the number or using the slider bar. - # Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. - # Z-Controller>Setpoint unit(NXpositioner) (e.g.A) # Angstrom - z_sontrol_setpoint: - # Z-Controller>P gain(NXpid) (e.g.6E-12) # The Type switches controller parameters - # between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). - # The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). - # The integral gain and time constant are related as follows: I = P/T. - z_control_p_gain: - # Z-Controller>I gain(NXpid) (e.g.39.8241E-9) # See "Z-Controller>P gain" below. - z_control_i_gain: - # Z-Controller>Time const(NXpid) (s) (e.g.150.662E-6) # See "Z-Controller>P gain" below. - z_control_time_const: - # Z-Controller>TipLift(NXpositioner) (m) (e.g.0E+0) # Lifts the tip by the specified - # amount when then controller is switched off. This can be a positive or a negative number, - # i.e. the tip can also be moved towards the sample. Be careful with sign and value when - # using this feature. - z_control_tip_lift: - # Z-Controller>Switch off delay(NXpositioner) (s) (e.g.0E+0) # Use this parameter for - # a reproducible position when switching off the Z-controller. When >0 and the Z-controller - # is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. - z_control_switchoff_delay: - # TODO: discuss convertion data to DATA - (NXdata): - doc: | - This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. - There should also be two more fields called temperature and voltage containing the setpoint values. - There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension - equal to the number of voltage setpoints. - axes: bias_calc - signals: - li_demod_[1;2]_[X/Y]_[-;bwd;filt;bwd_filt] - current_[-;bwd;filt;bwd_filt] - temperature - x - y - z - # DATA # multi dimensional array: multi I-V array per scan point; - # doc: The format of the data here is similar to a column matrix. - # Bias calc (V) #scanning parameter - # Current (A) # current during forward direction scanning of bias - original NXsensor - # LI Demod 2 X (A) lockin (NXsensor+lockin) - # LI Demod 2 Y (A) lockin - # LI Demod 1 X (A) lockin - # LI Demod 1 Y (A) lockin - # Current [bwd] (A) #bwd - backward (the positive direction shall be clarified by the reference bias scanning frame. Fwd means from left(neg) to right(pos). In the scannig image, the bottom(neg) to top(pos), the left(neg) to right(pos) - # LI Demod 2 X [bwd] (A) lockin - # LI Demod 2 Y [bwd] (A) lockin - # LI Demod 1 X [bwd] (A) lockin - # LI Demod 1 Y [bwd] (A) lockin - # Current (A) [filt] # forward direction (maybe from lockin#2?) - # LI Demod 2 X (A) [filt] lockin - # LI Demod 2 Y (A) [filt] lockin - # LI Demod 1 X (A) [filt] lockin - # LI Demod 1 Y (A) [filt] lockin - # Current (A) [bwd] [filt] - # LI Demod 2 X (A) [bwd] [filt] lockin - # LI Demod 2 Y (A) [bwd] [filt] lockin - # LI Demod 1 X (A) [bwd] [filt] lockin - # LI Demod 1 Y (A) [bwd] [filt] lockin - # Temperature - # x - # y - # z - # single point default plot # current(I) vs bias(V) - single_point(NXdata): - exists: optional - # line scan default plot # multi I vs. V curves - line_scan(NXdata): - exists: optional - # alternative plot # current(I) curve in the 2D space of (position(x), bias(V)) - alternative_plot(NXdata): - exists: optional - # mesh scan default plot # 2D slices of the above alternative plot - mesh_scan(NXdata): - exists: optional + # # Cabling & Config + # # output_mode: + # # doc: Number of output channels. (e.g. User Output) + # # output_value(NX_NUMBER): + # # doc: The user output in each monitor mode. (e.g. 0E+0) + # # output_name: + # # doc: User outputs whose name can be modified in the corresponding module. (e.g. Input 24 (V)) + # # output_slew_rate(NX_NUMBER): + # # doc: The rate at which the one of the signal changes when ramping to the starting point. (V/s) (e.g. Inf) + # piezo_config(NXcollection): + # doc: | + # Configuration for piezoelectric scanner used to move tip along X and Y direction. The + # material of the Piezoelectric scanner composed of polycrystalline solids and nsensitve to + # applied voltage. + # active_calib: + # doc: The name of caliberation type. (e.g. LHe) + # calib_N(NX_NUMBER): + # exists: optional + # doc: | + # N denotes X or Y or Z. There are 3 parameters in X, Y, and Z directions and there + # are 3 controls availables: Calibr. (m/V), Range (m) and HV gain. Two of them are + # enough to define the calibration, so when changing any value one of the other values + # will be updated automatically. (e.g. 3.8E-9) + # hv_gain_N(NX_NUMBER): + # exists: optional + # doc: N denotes X or Y or Z. For some systems HV gain readout is available, + # so for those systems the HV gain should be adjusted automatically when the gain + # is changed at the high voltage amplifier. (e.g. 14.5) + # # (e.g. 0.318343) + # tilt_N(NX_NUMBER): + # exists: optional + # unit: NX_ANGLE + # doc: | + # N denotes X or Y. There are 2 parameters in X and Y directions and this tab + # is used to set the sample tilt (in degrees, first order correction). + # # Inf + # curvature_radius_N(NX_NUMBER): + # exists: optional + # unit: NX_LENGTH + # doc: N denotes X or Y. There are 2 parameters in X and Y directions and this tab + # is used to set a curvature (can be set approximately to the length of the piezotube). + # 2nd_order_corr_N(NX_NUMBER): + # exists: optional + # doc: | + # N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, + # you can enter the 2nd order piezo characteristics to compensate for it. The + # following equation shows the interpretation of the 2nd order correction parameter: + # For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: + # [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx + # is the 2nd order correction. (V/m^2). (e.g. 0E+0) + # drift_N(NX_NUMBER): + # exists: optional + # doc: | + # N denotes X, Y or Z. There are 3 parameters in X, Y and Z directions. Define the + # drift speed for all three axes. When the compensation is on, the piezos will start to + # move at that speed. (e.g. 0E+0) + # drift_correction_status(NX_BOOLEAN): + # doc: Use the button to turn on/off the drift compensation. (e.g. FALSE) + # (NXenvironment): + # doc: | + # Describes an environment setup for a temperature-dependent IV measurement experiment. + # The temperature and voltage must be present as independently scanned controllers and + # the current sensor must also be present with its readings. + # voltage_controller(NXsensor): + # exists: optional + # temperature_controller(NXsensor): + # current_sensor(NXsensor): + # position(NXpositioner): + # doc: Clarify the frame laboratory frame. + # x(NX_NUMBER): + # exists: optional + # unit: NX_LENGTH + # doc: The scanning area in x position in the frame. (e.g. -890.53E-12) + # y(NX_NUMBER): + # exists: optional + # unit: NX_LENGTH + # doc: The scanning area in y position in the frame. (e.g. 29.6968E-9) + # z(NX_NUMBER): + # exists: optional + # unit: NX_LENGTH + # doc: The scanning area in x position in the frame. (e.g. 130.5E-9) + # z_controller(NX_NUMBER): + # unit: NX_LENGTH + # doc: Indicate the tip position Z between tip and sample. The tip position can also be varied when the controller is not running. (e.g. 130.5E-9) + # # parameters for a measurement at a single location during the scan + # sweep_control(NXcollection): + # bias_spectroscopy(NXbias_spectroscopy): + # integration_time(NX_NUMBER): + # unit: NX_TIME + # doc: Time during which the spectroscopy data are acquired and averaged. (e.g. 150E-6) + # number_of_sweeps(NX_NUMBER): + # doc: Number of sweeps to measure and average. (e.g. 100) + # sweep_start(NX_NUMBER): + # unit: NX_VOLTAGE + # doc: The first bias values of the sweep. (e.g. -300E-3) + # sweep_end(NX_NUMBER): + # unit: NX_VOLTAGE + # doc: The last bias values of the sweep. (e.g. 300E-3) + # num_pixel(NX_NUMBER): + # doc: Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. (e.g. 4096) + # z_avg_time(NX_NUMBER): + # unit: NX_TIME + # doc: Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). (e.g. 100E-3) + # circuit(NXcollection): + # rt_frequency(NX_NUMBER): + # unit: NX_FREQENCY + # doc: The bandwitdh of the Hardware and/or Software (e.g. 20E+3) + # signals_oversampling(NX_NUMBER): + # doc: (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. (e.g. 10) + # acquisition_period(NX_NUMBER): + # unit: NX_TIME + # exists: optional + # doc: Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. (e.g. 20E-3) + # animations_period(NX_NUMBER): + # unit: NX_TIME + # exists: optional + # doc: Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. (e.g. 20E-3) + # indicators_period(NX_NUMBER): + # unit: NX_TIME + # doc: Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. (e.g. 300E-3) + # measurements_period(NX_NUMBER): + # exists: optional + # unit: NX_TIME + # doc: The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. (e.g. 500E-3) + # # parameters how to change the location from measurement to measurement during the scan + # scan_control(NXcollection): + # exists: optional + # roi(NXtransformations): + # frame: + # doc: Also clarify the frame for the ROI of the scan (should depend on the lab frame) + # circuit(NXcollection): + # channels_current: + # doc: The scan channels are selected by users. (e.g. (A);Bias (V);Z (m);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A)) + # positioner(NXcollection): + # scanfield(NX_NUMBER): + # doc: Configure the scan frame like x position; y position; width; height. (e.g. 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0) + # pixels_line(NX_NUMBER): + # doc: Scan resolution by setting the Lines equal to Pixels. (e.g. 512) + # lines(NX_NUMBER): + # doc: Define the image resolution. (e.g. 512) + # speed_forw(NX_NUMBER): + # doc: Define the scan forward speed in the forward direction. (m/s) (e.g. 11.7187E-9) + # speed_backw(NX_NUMBER): + # doc: Define the scan backward speed in the forward direction. (m/s) (e.g. 11.7187E-9) + # # RESOLUTION (calculation input) + # # TODO: After fix resolution_indicators back to required + # # As all of the bellow are linked + # resolution_indicators(NXprocess): + # exists: optional + # # Temperature 1>link to INSTR/STM/head Temperature 1 (K) (e.g. 4.92997E+0) # Temperature of STM head. + # temp_stm_head: + # # Temperature 2>link to Temperature 2 (K) - # Temperature of bottom of LHe helium cryostat. + # temp_cryo_bottom: + # # Temperature 3>link to Temperature 3 (K) - # Temperature of LN2 nitrogen shield. + # temp_cryo_shield: + # # Lock-in>link to Modulated signal Bias (V) (e.g. 1E-3) # Applied modulation to the bias voltage. + # modulated_signal_bias: + # # link to Integration time (s) (e.g. 150E-6) # Time during which the spectroscopy data are acquired and averaged. + # integration_time: + # # link to Bias Spectroscopy>Number of sweeps (e.g. 100) # Number of sweeps to measure and average. + # number_of_sweps: + # # link to Bias Spectroscopy>Sweep Start (V) (e.g. -300E-3) # The first bias values of the sweep. + # sweep_start: + # # link to Bias Spectroscopy>Sweep End (V) (e.g. 300E-3) # The last bias values of the sweep. + # sweep_end: + # # link to Bias Spectroscopy>Num Pixel (e.g. 4096) # Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. + # number_of_pixels: + # # link to Bias Spectroscopy>Z Avg time (s) (e.g. 100E-3) # Duration over which the Z + # # position is recorded and averaged before and after the sweep (the latter only if Record + # # final Z position is selected in the Advanced section). After the initial Z averaging + # # time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is + # # set to hold and the tip is placed at the previously averaged Z position (plus Z offset). + # z_avg_time: + # # link to SoftwareMain>RT Frequency (Hz) (e.g. 20E+3) # The bandwitdh of the + # # Hardware and/or Software + # rt_freq: + # # link to SoftwareMain>Signals Oversampling (e.g. 10) # (Signals Periods) + # # The Signals Period is the rate at which the signals are transferred to the host computer + # # running the control software. This is usually lower by a factor of 10 than the sampling + # # rate, because an internal oversampling of the signal is done on the real time engine. + # # You can reduce the oversampling down to 1 in order to resolve higher frequencies in the + # # Spectrum Analyzer. + # oversampling: + # # link to SoftwareMain>Acquisition Period (s) (e.g. 20E-3) # Update rate for several + # # processes like History Graph, Auto-Approach, and for many Programming Interface functions. + # # This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples + # # of this value. They can be set to different values, but the actual timing value will be + # # coerced to a multiple of the Acquisition Period. + # acquisition_period: + # # link to SoftwareMain>Animations Period (s) (e.g. 20E-3) # Update rate of animated + # # graphical indicators. These are e.g. some graphs & sliders. A reasonable value is + # # 40 ms (25 updates per second). Increase this period to reduce the processor load + # # for the graphical user interface, especially on slow computers. This value is purely a + # # user interface update rate and does not affect measurements in any way. + # animation_period: + # # link to SoftwareMain>Indicators Period (s) (e.g. 300E-3) # Update rate of digital + # # indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per + # # second, or 300 ms is enough. This value is purely a user interface update rate and + # # does not affect measurements in any way. + # indicators_period: + # # link to SoftwareMain>Measurements Period (s) (e.g. 500E-3) # The Measurements + # # period is the integration time for precise measurements (averaging over specified period), + # # mostly used in sweep modules. Examples are recording of a force-distance curve or a + # # resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be + # # reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a + # # high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. + # measurement_period: + # # TODO: Later fix REPRODUCIBILITY_indicator + # # as all of the bellow are linked + # reproducibility_indicators(NXprocess): + # exists: optional + # # Bias>Bias(NXBias) (V) (e.g. 100E-3) # Applied bias voltage. + # bias: + # # Current>Current(NXcircuit) (A) (e.g. -5.3429E-15) # The tunneling current is displayed here. + # current: + # # Bias>Calibration(NXbias) (V/V) (e.g. 1E+0) Calibration of the Bias output. If you have a Range switch the calibration is stored per range setting. + # bias_calibration: + # # Bias>Offset(NXbias) (V) (e.g. 0E+0) Allows compensating for an offset in Bias. + # bias_offset: + # # Current>Calibration(NXcircuit) (A/V) (e.g. 100E-12) + # # The signals voltages are converted to real world physical values according to the calibration & offset parameters: + # # Physical signal = (Voltage * calibration) + offset. + # current_calibration: + # # Current>Offset(NXcircuit) (A) (e.g. 16.2897E-15) # The same as "Current>Calibration (A/V)" tag + # current_offset: + # # Current>Gain(NXcircuit) (e.g. Not switchable) # None + # current_gain: + # # Z offset(NXpositioner) (m) (e.g. 0E+0) # Offset added to the initial averaged position + # # Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is + # # deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an + # # alternate Z-controller setpoint is enabled. + # z_offset: + # # Settling time(NXbias) (s) (e.g. 2.1E-3) Time to wait after changing the bias to the next + # # level and before starting to acquire data. Adjust this parameter to avoid transient + # # effect induced by the bias change. Integration time: time during which the data are + # # acquired and averaged. + # settling_time: + # # Z-Ctrl hold(NXpositioner) (e.g. TRUE) # When selected, the Z-Controller is set to hold + # # during the pulse. This means that the controller doesn't control the Z position during the pulse. + # z_control_hold: + # # Final Z(NXpositioner) (m) (e.g. N/A) + # final_z: + # # Start time(NXlog) (e.g.23.11.2022 18:55:16) # Timestamp of the moment when the acquisition starts by pressing the Start button. + # start_time: + # # Bias Spectroscopy>1st Settling time(NXbias) (s) (e.g.2.1E-3) # See the "Settling time (s)" below. + # 1st_settling_time: + # # Bias Spectroscopy>Integration time(NXbias) (s) (e.g.150E-6) # Time during which the data + # # are acquired and averaged. + # integration_time: + # # Bias Spectroscopy>End Settling time(NXbias) (s) (e.g.4E-3) # Time to wait after the sweep has finished and the bias is ramped to the initial value. + # end_settling_time: + # # Bias Spectroscopy>Z control time(NXbias) (s) (e.g.200E-3) # Time during which the + # # Z-Controller is enabled once a sweep has finished. When averaging multiple sweeps + # # (i.e. Sweeps>1), the Z-Controller is enabled for this duration between each sweep. + # # After the last sweep, it will wait the specified time before continuing a running scan. + # # This ensures each sweep reliably starts from the same position. This parameter is + # # disabled when Z-Controller to Hold is deselected in the Advanced section. + # z_contro_time: + # # Bias Spectroscopy>Max Slew rate(NXbias) (V/s) (e.g.1E+0) # Maximum rate at which + # # the bias changes (before, during and after sweeping). + # max_slew_rate: + # # Bias Spectroscopy>backward sweep(NXbias) (e.g.TRUE) # Select whether to measure + # # the backward (return) sweep or the forward only. + # backward_sweep: + # # Z-Controller>Controller name(NXpositioner) (e.g.log Current) # Controller name. + # # This name which will be displayed at places where you can select a controller. + # z_control_name: + # # Z-Controller>Controller status(NXpositioner) (e.g.OFF) # ON/OFF + # z_control_status: + # # Z-Controller>Setpoint(NXpositioner) (e.g.50E-12) # Set Point is the desired value + # # of the control signal. It can be set by editing the number or using the slider bar. + # # Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. + # # Z-Controller>Setpoint unit(NXpositioner) (e.g.A) # Angstrom + # z_sontrol_setpoint: + # # Z-Controller>P gain(NXpid) (e.g.6E-12) # The Type switches controller parameters + # # between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). + # # The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). + # # The integral gain and time constant are related as follows: I = P/T. + # z_control_p_gain: + # # Z-Controller>I gain(NXpid) (e.g.39.8241E-9) # See "Z-Controller>P gain" below. + # z_control_i_gain: + # # Z-Controller>Time const(NXpid) (s) (e.g.150.662E-6) # See "Z-Controller>P gain" below. + # z_control_time_const: + # # Z-Controller>TipLift(NXpositioner) (m) (e.g.0E+0) # Lifts the tip by the specified + # # amount when then controller is switched off. This can be a positive or a negative number, + # # i.e. the tip can also be moved towards the sample. Be careful with sign and value when + # # using this feature. + # z_control_tip_lift: + # # Z-Controller>Switch off delay(NXpositioner) (s) (e.g.0E+0) # Use this parameter for + # # a reproducible position when switching off the Z-controller. When >0 and the Z-controller + # # is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. + # z_control_switchoff_delay: + # # TODO: discuss convertion data to DATA + # (NXdata): + # doc: | + # This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. + # There should also be two more fields called temperature and voltage containing the setpoint values. + # There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension + # equal to the number of voltage setpoints. + # axes: bias_calc + # signals: + # li_demod_[1;2]_[X/Y]_[-;bwd;filt;bwd_filt] + # current_[-;bwd;filt;bwd_filt] + # temperature + # x + # y + # z + # # DATA # multi dimensional array: multi I-V array per scan point; + # # doc: The format of the data here is similar to a column matrix. + # # Bias calc (V) #scanning parameter + # # Current (A) # current during forward direction scanning of bias - original NXsensor + # # LI Demod 2 X (A) lockin (NXsensor+lockin) + # # LI Demod 2 Y (A) lockin + # # LI Demod 1 X (A) lockin + # # LI Demod 1 Y (A) lockin + # # Current [bwd] (A) #bwd - backward (the positive direction shall be clarified by the reference bias scanning frame. Fwd means from left(neg) to right(pos). In the scannig image, the bottom(neg) to top(pos), the left(neg) to right(pos) + # # LI Demod 2 X [bwd] (A) lockin + # # LI Demod 2 Y [bwd] (A) lockin + # # LI Demod 1 X [bwd] (A) lockin + # # LI Demod 1 Y [bwd] (A) lockin + # # Current (A) [filt] # forward direction (maybe from lockin#2?) + # # LI Demod 2 X (A) [filt] lockin + # # LI Demod 2 Y (A) [filt] lockin + # # LI Demod 1 X (A) [filt] lockin + # # LI Demod 1 Y (A) [filt] lockin + # # Current (A) [bwd] [filt] + # # LI Demod 2 X (A) [bwd] [filt] lockin + # # LI Demod 2 Y (A) [bwd] [filt] lockin + # # LI Demod 1 X (A) [bwd] [filt] lockin + # # LI Demod 1 Y (A) [bwd] [filt] lockin + # # Temperature + # # x + # # y + # # z + # # single point default plot # current(I) vs bias(V) + # single_point(NXdata): + # exists: optional + # # line scan default plot # multi I vs. V curves + # line_scan(NXdata): + # exists: optional + # # alternative plot # current(I) curve in the 2D space of (position(x), bias(V)) + # alternative_plot(NXdata): + # exists: optional + # # mesh scan default plot # 2D slices of the above alternative plot + # mesh_scan(NXdata): + # exists: optional diff --git a/contributed_definitions/nyaml/NXlockin.yaml b/contributed_definitions/nyaml/NXlockin.yaml index cb90dc229c..3c3e1a90ff 100644 --- a/contributed_definitions/nyaml/NXlockin.yaml +++ b/contributed_definitions/nyaml/NXlockin.yaml @@ -14,12 +14,16 @@ NXlockin: doc: A modulation signal (such as bias, current et.al.) is a periodic voltage signal, usually applied to the surface of a sample, which serves to modify the physical properties of the sample surface and generate weak AC current signals that can be detected and analysed by instruments such as lock-in amplifiers. modulation_amplitude(NX_NUMBER): doc: Sets the amplitude (in physical units of the modulated signal) of the sine modulation. - unit: NX_VOLTAGE (For bais modulate signal, it depands on the modulate type) + # (For bais modulate signal, it depands on the modulate type) + unit: NX_VOLTAGE modulation_frequency(NX_NUMBER): doc: Sets the frequency of the sine modulation added to the signal to modulate. unit: NX_FREQUENCY demodulated_signal: - doc: The input signal (STS signal) will be demodulated, in order to determine the amplitude and phase at the frequency set in the Frequency field or harmonics, such as current, bias, et.al. + doc: | + The input signal (STS signal) will be demodulated, in order to determine the amplitude + and phase at the frequency set in the Frequency field or harmonics, such as current, + bias, et.al. #output (demodulated signal) characterisation (foreach channel, like demodulation, a separate sensor output, e.g. X,Y) number_of_demodulator_channels(NX_NUMBER): doc: The number of signals which will be demodulated. @@ -41,13 +45,13 @@ NXlockin: doc: Order and cut-off frequency of the high-pass filter applied on the demodulation signal of D!. This is used mainly to suppress a DC component of the demodulation signal, which would lead to a component at modulation frequency in the demodulated signals. sync(NX_BOOLEAN): doc: Switch on/off the Sync filter on the demodulated signals (X,Y) on or off. (foreach DemodulatorChannels) - ref_phase(NX_NUMBER): + ref_phase_N(NX_NUMBER): doc: Reference phase for the sine on the demodulated signal with respect to the modulation signal. (foreach DemodulatorChannels) unit: NX_FREQUENCY integration_time(NX_NUMBER): doc: Time during which the data are acquired and averaged. (for the input filter) unit: NX_TIME - order_of_harmonics(NX_NUMBER): + harmonic_order_N(NX_NUMBER): doc: The order of the harmonic oscillation to detect on the demodulated signals. (with respect to the modulation frequency) sensitivity_factor(NX_NUMBER): doc: Ratio of output signal amplitude to input signal amplitue (V/V). (input gain) # Not sure about it. From a59530e1f342dc9bea5975332d739591b784aff0 Mon Sep 17 00:00:00 2001 From: Rubel Date: Wed, 21 Jun 2023 13:43:46 +0200 Subject: [PATCH 0157/1012] Correction on iv_sweep and iv_bias --- contributed_definitions/NXiv_bias.nxdl.xml | 131 ++- contributed_definitions/NXiv_sweep2.nxdl.xml | 877 ++++++++++-------- contributed_definitions/nyaml/NXiv_bias.yaml | 40 +- .../nyaml/NXiv_sweep2.yaml | 761 ++++++++------- 4 files changed, 1021 insertions(+), 788 deletions(-) diff --git a/contributed_definitions/NXiv_bias.nxdl.xml b/contributed_definitions/NXiv_bias.nxdl.xml index e766bc786c..8861ca48c2 100644 --- a/contributed_definitions/NXiv_bias.nxdl.xml +++ b/contributed_definitions/NXiv_bias.nxdl.xml @@ -23,14 +23,14 @@ --> - Base classes definition for bias devices. + Application definition for bias devices. Applied a voltage between tip and sample. - + The ratio between the tunneling current at the sample surface and the bias voltage applied between between the sample and the tip. @@ -57,4 +57,131 @@ Bias sweeps while measuring arbitrary channels with I(V) curves. + + + Select the channels to record. + + + + + When selected, the Bias voltage returns to the initial value (before starting the sweep) at the end of the spectroscopy measurement (default). When not selected, Bias remains at the last value of the sweep. This is useful e.g. when combining several sweep segments. Example for an automated measurement (using Programming Interface): switch off Z-Controller, start spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, switch on Z-Controller. + + + + + Select whether to record the Z position during Z averaging time at the end of + the sweep (after Z control time) and store the average value in the header of + the file when saving. Using this option increases the sweep time by Z averaging + time. + + + + + Select whether to set the Lock-In to run during the measurement. When using this + feature, make sure the Lock-In is configured correctly and settling times are + set to twice the Lock-In period at least. This option is ignored when Lock-In is + already running. This option is disabled if the Sweep Mode is MLS and the flag + to configure the Lock-In per segment in the Multiline segment editor is set. + + + + + Time during which the spectroscopy data are acquired and averaged. + + + + + Number of sweeps to measure and average. + + + + + The first bias values of the sweep. + + + + + The last bias values of the sweep. + + + + + Define the sweep number of points, that is, the maximum spectrum resolution eq. + Bias window divide by Num Pixel. + + + + + Duration over which the Z position is recorded and averaged before and after the + sweep (the latter only if Record final Z position is selected in the Advanced + section). After the initial Z averaging time, if Z-Controller to Hold is + selected in the Advanced section, the Z-Controller is set to hold and the tip is + placed at the previously averaged Z position (plus Z offset). + + + + + Select a filter to smooth the displayed data. When saving, if any filter + selected, filtered data are saved to file along with the unfiltered data. + + + + + Filter order of a dynamic filter or width (in number of points) for the gaussian + filter. + + + + + Cutoff frequency for dynamic filters. + + + + + Offset added to the initial averaged position Zaver before starting to sweep. + This parameter is disabled when Z-Controller to Hold is deselected in the + Advanced section. The LED “Alt” next to the Z offset indicates if an alternate + Z-controller setpoint is enabled. + + + + + time to wait after changing the bias to the next level and before starting to + acquire data. + + + + + Time to wait after the sweep has finished and the bias is ramped to the initial + value. + + + + + Time during which the Z-Controller is enabled once a sweep has finished. When + averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled for this + duration between each sweep. After the last sweep, it will wait the specified + time before continuing a running scan. This ensures each sweep reliably starts + from the same position. This parameter is disabled when Z-Controller to Hold is + deselected in the Advanced section. + + + + + Maximum rate at which the bias changes (before, during and after sweeping). + (V/s) + + + + + Select whether to measure the backward (return) sweep or the forward only. + + + + + Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. + It is selected by default. When deselected, Z-offset and Z control time + parameters are disabled. + + diff --git a/contributed_definitions/NXiv_sweep2.nxdl.xml b/contributed_definitions/NXiv_sweep2.nxdl.xml index f33be4eda7..f25d23e7dc 100644 --- a/contributed_definitions/NXiv_sweep2.nxdl.xml +++ b/contributed_definitions/NXiv_sweep2.nxdl.xml @@ -153,9 +153,7 @@ set in the Frequency field (“4”) or harmonics.--> - - - - + segment editor is set.--> + + + + Applied a voltage between tip and sample. + + + + + + + Temperature of STM head. Note: At least one field from stm_head_temperature, + cryo_bottom_temp and cryo_sheild_temp must be provided. + + + + + Temperature of LHe helium cryostat. Note: At least one field from + stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp must be provided. + + + + + Temperature of LN2 nitrogen shield. Temperature 3 (K) (e.g 78.00000E+0). Note: At + least one field from stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp + must be provided. + + + + + Note_ no doc. + + + + + + Configuration for piezoelectric scanner used to move tip along X and Y direction. The + material of the Piezoelectric scanner composed of polycrystalline solids and nsensitve to + applied voltage. + + + + The name of caliberation type. (e.g. LHe) + + + + + N denotes X or Y or Z. There are 3 parameters in X, Y, and Z directions and there + are 3 controls availables: Calibr. (m/V), Range (m) and HV gain. Two of them are + enough to define the calibration, so when changing any value one of the other values + will be updated automatically. (e.g. 3.8E-9) + + + + + N denotes X or Y or Z. For some systems HV gain readout is available, so for + those systems the HV gain should be adjusted automatically when the gain is + changed at the high voltage amplifier. (e.g. 14.5) + + + + + + N denotes X or Y. There are 2 parameters in X and Y directions and this tab + is used to set the sample tilt (in degrees, first order correction). + + + + + + N denotes X or Y. There are 2 parameters in X and Y directions and this tab is + used to set a curvature (can be set approximately to the length of the + piezotube). + + + + + N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, + you can enter the 2nd order piezo characteristics to compensate for it. The + following equation shows the interpretation of the 2nd order correction parameter: + For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: + [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx + is the 2nd order correction. (V/m^2). (e.g. 0E+0) + + + + + N denotes X, Y or Z. There are 3 parameters in X, Y and Z directions. Define the + drift speed for all three axes. When the compensation is on, the piezos will start to + move at that speed. (e.g. 0E+0) + + + + + Use the button to turn on/off the drift compensation. (e.g. FALSE) + + + + + + Describes an environment setup for a temperature-dependent IV measurement experiment. + The temperature and voltage must be present as independently scanned controllers and + the current sensor must also be present with its readings. + + + + + + + Clarify the frame laboratory frame. + + + + The scanning area in x position in the frame. (e.g. -890.53E-12) + + + + + The scanning area in y position in the frame. (e.g. 29.6968E-9) + + + + + The scanning area in x position in the frame. (e.g. 130.5E-9) + + + + + Indicate the tip position Z between tip and sample. The tip position can also be + varied when the controller is not running. (e.g. 130.5E-9) + + + + + + + + + Time during which the spectroscopy data are acquired and averaged. (e.g. 150E-6) + + + + + Number of sweeps to measure and average. (e.g. 100) + + + + + The first bias values of the sweep. (e.g. -300E-3) + + + + + The last bias values of the sweep. (e.g. 300E-3) + + + + + Define the sweep number of points, that is, the maximum spectrum resolution eq. + Bias window divide by Num Pixel. (e.g. 4096) + + + + + Duration over which the Z position is recorded and averaged before and after the + sweep (the latter only if Record final Z position is selected in the Advanced + section). After the initial Z averaging time, if Z-Controller to Hold is + selected in the Advanced section, the Z-Controller is set to hold and the tip is + placed at the previously averaged Z position (plus Z offset). (e.g. 100E-3) + + + + + + + The bandwitdh of the Hardware and/or Software (e.g. 20E+3) + + + + + (Signals Periods) The Signals Period is the rate at which the signals are + transferred to the host computer running the control software. This is usually + lower by a factor of 10 than the sampling rate, because an internal oversampling + of the signal is done on the real time engine. You can reduce the oversampling + down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. (e.g. + 10) + + + + + Update rate for several processes like History Graph, Auto-Approach, and for + many Programming Interface functions. This is usually set to 20 ms. All + additional timings (7-9) can only be integer multiples of this value. They can + be set to different values, but the actual timing value will be coerced to a + multiple of the Acquisition Period. (e.g. 20E-3) + + + + + Update rate of animated graphical indicators. These are e.g. some graphs & + sliders. A reasonable value is 40 ms (25 updates per second). Increase this + period to reduce the processor load for the graphical user interface, especially + on slow computers. This value is purely a user interface update rate and does + not affect measurements in any way. (e.g. 20E-3) + + + + + Update rate of digital indicators, e.g. the numbers displayed besides each + slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a + user interface update rate and does not affect measurements in any way. (e.g. + 300E-3) + + + + + The Measurements period is the integration time for precise measurements + (averaging over specified period), mostly used in sweep modules. Examples are + recording of a force-distance curve or a resonance of a cantilever. For fast + measurements with small steps, a value of 40 ms may be reasonable. For normal + use, 300-500 ms is a good value, but for recording a resonance of a high-Q + cantilever, values of several seconds might be necessary. Usually this parameter + doesn’t need to be set from this module; the sweep modules will set this value + according to the sweep timings. (e.g. 500E-3) + + + + + + + + + + Also clarify the frame for the ROI of the scan (should depend on the lab frame) + + + + + + + The scan channels are selected by users. (e.g. (A);Bias (V);Z (m);LI Demod 2 X + (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A)) + + + + + + + Configure the scan frame like x position; y position; width; height. (e.g. + 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0) + + + + + Scan resolution by setting the Lines equal to Pixels. (e.g. 512) + + + + + Define the image resolution. (e.g. 512) + + + + + Define the scan forward speed in the forward direction. (m/s) (e.g. 11.7187E-9) + + + + + Define the scan backward speed in the forward direction. (m/s) (e.g. 11.7187E-9) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. + There should also be two more fields called temperature and voltage containing the setpoint values. + There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension + equal to the number of voltage setpoints. + axes: bias_calc + signals: + li_demod_[1;2]_[X/Y]_[-;bwd;filt;bwd_filt] + current_[-;bwd;filt;bwd_filt] + temperature + x + y + z + + + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXiv_bias.yaml b/contributed_definitions/nyaml/NXiv_bias.yaml index 5df3566eb4..4bd1bd56be 100644 --- a/contributed_definitions/nyaml/NXiv_bias.yaml +++ b/contributed_definitions/nyaml/NXiv_bias.yaml @@ -7,7 +7,7 @@ NXiv_bias(NXobject): unit: NX_VOLTAGE tunneling_resistor(NX_NUMBER): doc: The ratio between the tunneling current at the sample surface and the bias voltage applied between between the sample and the tip. - unit: NX_ANY (No NX_resistance) + unit: NX_ANY calibration(NX_NUMBER): doc: Calibration of the Bias output (V/V). offset(NX_NUMBER): @@ -18,54 +18,54 @@ NXiv_bias(NXobject): unit: NX_VOLTAGE (NXbias_spectroscopy): doc: Bias sweeps while measuring arbitrary channels with I(V) curves. - Channels(NX_CHAR): + channels(NX_CHAR): doc: Select the channels to record. - Reset Bias(NX_BOOLEAN): + reset_bias(NX_BOOLEAN): doc: | When selected, the Bias voltage returns to the initial value (before starting the sweep) at the end of the spectroscopy measurement (default). When not selected, Bias remains at the last value of the sweep. This is useful e.g. when combining several sweep segments. Example for an automated measurement (using Programming Interface): switch off Z-Controller, start spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, switch on Z-Controller. - Record final Z(NX_BOOLEAN): + record_final_z(NX_BOOLEAN): doc: Select whether to record the Z position during Z averaging time at the end of the sweep (after Z control time) and store the average value in the header of the file when saving. Using this option increases the sweep time by Z averaging time. - Lock-In run(NX_BOOLEAN): + lock_in_run(NX_BOOLEAN): doc: Select whether to set the Lock-In to run during the measurement. When using this feature, make sure the Lock-In is configured correctly and settling times are set to twice the Lock-In period at least. This option is ignored when Lock-In is already running. This option is disabled if the Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline segment editor is set. - Integration time(NX_NUMBER): + integration_time(NX_NUMBER): doc: Time during which the spectroscopy data are acquired and averaged. unit: NX_TIME - Number of sweeps(NX_NUMBER): + number_of_sweeps(NX_NUMBER): doc: Number of sweeps to measure and average. - Sweep Start(NX_NUMBER): + sweep_start(NX_NUMBER): doc: The first bias values of the sweep. unit: NX_VOLTAGE - Sweep End(NX_NUMBER): + sweep_end(NX_NUMBER): doc: The last bias values of the sweep. unit: NX_VOLTAGE - Num Pixel(NX_NUMBER): + num_pixel(NX_NUMBER): doc: Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. - Z Avg time(NX_NUMBER): + z_avg_time(NX_NUMBER): doc: Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). unit: NX_TIME - SW Filter type (NX_CHAR): + sw_filter_type (NX_CHAR): doc: Select a filter to smooth the displayed data. When saving, if any filter selected, filtered data are saved to file along with the unfiltered data. - SW Filter Order(NX_NUMBER): + sw_ilter_order(NX_NUMBER): doc: Filter order of a dynamic filter or width (in number of points) for the gaussian filter. - SW Filter Cutoff frq(NX_NUMBER): + sw_filter_cutoff_frq(NX_NUMBER): doc: Cutoff frequency for dynamic filters. - Z offset(NX_NUMBER): + z_offset(NX_NUMBER): doc: Offset added to the initial averaged position Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an alternate Z-controller setpoint is enabled. unit: NX_LENGTH - Settling time(NX_NUMBER): + settling_time(NX_NUMBER): doc: time to wait after changing the bias to the next level and before starting to acquire data. unit: NX_TIME - End Settling time(NX_NUMBER): + end_settling_time(NX_NUMBER): doc: Time to wait after the sweep has finished and the bias is ramped to the initial value. unit: NX_TIME - Z control time(NX_NUMBER): + z_control_time(NX_NUMBER): doc: Time during which the Z-Controller is enabled once a sweep has finished. When averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled for this duration between each sweep. After the last sweep, it will wait the specified time before continuing a running scan. This ensures each sweep reliably starts from the same position. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. unit: NX_TIME - Max Slew rate(NX_NUMBER): + max_sew_rate(NX_NUMBER): doc: Maximum rate at which the bias changes (before, during and after sweeping). (V/s) backward sweep(NX_BOOLEAN): doc: Select whether to measure the backward (return) sweep or the forward only. - Z-controller hold(NX_BOOLEAN): + z_controller_hold(NX_BOOLEAN): doc: Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index 73c9d66990..78ce2e7a4e 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -128,385 +128,384 @@ NXiv_sweep2(NXsensor_scan): # option is ignored when Lock-In is already running. This option is disabled if the # Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline # segment editor is set. - # sample_bias(NXiv_bias): - # bias(NX_NUMBER): - # unit: NX_VOLTAGE - # doc: Applied a voltage between tip and sample. - # # sample_bias(NXbias): - # # Tip bias/Sample bias If the spectroscopy V bias is applied to the - # # Modulated signal Bias (V) 1E-3 Applied modulation to the bias voltage. - # # ModulationBias> Tip bias/Sample bias - # # modulated_signal_bias(NX_NUMBER): - # # unit: NX_VOLTAGE - # # doc: Same directional representation as bias. (e.g. 1E-3) - # stm_head_temp(NX_NUMBER): - # exists: optional - # unit: NX_TEMPERATURE - # doc: | - # Temperature of STM head. - # Note: At least one field from stm_head_temperature, cryo_bottom_temp and - # cryo_sheild_temp must be provided. - # cryo_bottom_temp(NX_NUMBER): - # exists: optional - # unit: NX_TEMPERATURE - # doc: | - # Temperature of LHe helium cryostat. Note: At least one field from - # stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp must be provided. - # cryo_shield_temp(NX_NUMBER): - # exists: optional - # unit: NX_TEMPERATURE - # doc: | - # Temperature of LN2 nitrogen shield. Temperature 3 (K) (e.g 78.00000E+0). Note: At - # least one field from stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp - # must be provided. - # output_cabling(NXcircuit): - # exists: optional - # doc: | - # NOte_ no doc. + sample_bias(NXiv_bias): + bias(NX_NUMBER): + unit: NX_VOLTAGE + doc: Applied a voltage between tip and sample. + # sample_bias(NXbias): + # Tip bias/Sample bias If the spectroscopy V bias is applied to the + # Modulated signal Bias (V) 1E-3 Applied modulation to the bias voltage. + # ModulationBias> Tip bias/Sample bias + # modulated_signal_bias(NX_NUMBER): + # unit: NX_VOLTAGE + # doc: Same directional representation as bias. (e.g. 1E-3) + stm_head_temp(NX_NUMBER): + exists: optional + unit: NX_TEMPERATURE + doc: | + Temperature of STM head. Note: At least one field from stm_head_temperature, + cryo_bottom_temp and cryo_sheild_temp must be provided. + cryo_bottom_temp(NX_NUMBER): + exists: optional + unit: NX_TEMPERATURE + doc: | + Temperature of LHe helium cryostat. Note: At least one field from + stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp must be provided. + cryo_shield_temp(NX_NUMBER): + exists: optional + unit: NX_TEMPERATURE + doc: | + Temperature of LN2 nitrogen shield. Temperature 3 (K) (e.g 78.00000E+0). Note: At + least one field from stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp + must be provided. + output_cabling(NXcircuit): + exists: optional + doc: | + Note_ no doc. - # # Cabling & Config - # # output_mode: - # # doc: Number of output channels. (e.g. User Output) - # # output_value(NX_NUMBER): - # # doc: The user output in each monitor mode. (e.g. 0E+0) - # # output_name: - # # doc: User outputs whose name can be modified in the corresponding module. (e.g. Input 24 (V)) - # # output_slew_rate(NX_NUMBER): - # # doc: The rate at which the one of the signal changes when ramping to the starting point. (V/s) (e.g. Inf) - # piezo_config(NXcollection): - # doc: | - # Configuration for piezoelectric scanner used to move tip along X and Y direction. The - # material of the Piezoelectric scanner composed of polycrystalline solids and nsensitve to - # applied voltage. - # active_calib: - # doc: The name of caliberation type. (e.g. LHe) - # calib_N(NX_NUMBER): - # exists: optional - # doc: | - # N denotes X or Y or Z. There are 3 parameters in X, Y, and Z directions and there - # are 3 controls availables: Calibr. (m/V), Range (m) and HV gain. Two of them are - # enough to define the calibration, so when changing any value one of the other values - # will be updated automatically. (e.g. 3.8E-9) - # hv_gain_N(NX_NUMBER): - # exists: optional - # doc: N denotes X or Y or Z. For some systems HV gain readout is available, - # so for those systems the HV gain should be adjusted automatically when the gain - # is changed at the high voltage amplifier. (e.g. 14.5) - # # (e.g. 0.318343) - # tilt_N(NX_NUMBER): - # exists: optional - # unit: NX_ANGLE - # doc: | - # N denotes X or Y. There are 2 parameters in X and Y directions and this tab - # is used to set the sample tilt (in degrees, first order correction). - # # Inf - # curvature_radius_N(NX_NUMBER): - # exists: optional - # unit: NX_LENGTH - # doc: N denotes X or Y. There are 2 parameters in X and Y directions and this tab - # is used to set a curvature (can be set approximately to the length of the piezotube). - # 2nd_order_corr_N(NX_NUMBER): - # exists: optional - # doc: | - # N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, - # you can enter the 2nd order piezo characteristics to compensate for it. The - # following equation shows the interpretation of the 2nd order correction parameter: - # For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: - # [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx - # is the 2nd order correction. (V/m^2). (e.g. 0E+0) - # drift_N(NX_NUMBER): - # exists: optional - # doc: | - # N denotes X, Y or Z. There are 3 parameters in X, Y and Z directions. Define the - # drift speed for all three axes. When the compensation is on, the piezos will start to - # move at that speed. (e.g. 0E+0) - # drift_correction_status(NX_BOOLEAN): - # doc: Use the button to turn on/off the drift compensation. (e.g. FALSE) - # (NXenvironment): - # doc: | - # Describes an environment setup for a temperature-dependent IV measurement experiment. - # The temperature and voltage must be present as independently scanned controllers and - # the current sensor must also be present with its readings. - # voltage_controller(NXsensor): - # exists: optional - # temperature_controller(NXsensor): - # current_sensor(NXsensor): - # position(NXpositioner): - # doc: Clarify the frame laboratory frame. - # x(NX_NUMBER): - # exists: optional - # unit: NX_LENGTH - # doc: The scanning area in x position in the frame. (e.g. -890.53E-12) - # y(NX_NUMBER): - # exists: optional - # unit: NX_LENGTH - # doc: The scanning area in y position in the frame. (e.g. 29.6968E-9) - # z(NX_NUMBER): - # exists: optional - # unit: NX_LENGTH - # doc: The scanning area in x position in the frame. (e.g. 130.5E-9) - # z_controller(NX_NUMBER): - # unit: NX_LENGTH - # doc: Indicate the tip position Z between tip and sample. The tip position can also be varied when the controller is not running. (e.g. 130.5E-9) - # # parameters for a measurement at a single location during the scan - # sweep_control(NXcollection): - # bias_spectroscopy(NXbias_spectroscopy): - # integration_time(NX_NUMBER): - # unit: NX_TIME - # doc: Time during which the spectroscopy data are acquired and averaged. (e.g. 150E-6) - # number_of_sweeps(NX_NUMBER): - # doc: Number of sweeps to measure and average. (e.g. 100) - # sweep_start(NX_NUMBER): - # unit: NX_VOLTAGE - # doc: The first bias values of the sweep. (e.g. -300E-3) - # sweep_end(NX_NUMBER): - # unit: NX_VOLTAGE - # doc: The last bias values of the sweep. (e.g. 300E-3) - # num_pixel(NX_NUMBER): - # doc: Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. (e.g. 4096) - # z_avg_time(NX_NUMBER): - # unit: NX_TIME - # doc: Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). (e.g. 100E-3) - # circuit(NXcollection): - # rt_frequency(NX_NUMBER): - # unit: NX_FREQENCY - # doc: The bandwitdh of the Hardware and/or Software (e.g. 20E+3) - # signals_oversampling(NX_NUMBER): - # doc: (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. (e.g. 10) - # acquisition_period(NX_NUMBER): - # unit: NX_TIME - # exists: optional - # doc: Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. (e.g. 20E-3) - # animations_period(NX_NUMBER): - # unit: NX_TIME - # exists: optional - # doc: Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. (e.g. 20E-3) - # indicators_period(NX_NUMBER): - # unit: NX_TIME - # doc: Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. (e.g. 300E-3) - # measurements_period(NX_NUMBER): - # exists: optional - # unit: NX_TIME - # doc: The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. (e.g. 500E-3) - # # parameters how to change the location from measurement to measurement during the scan - # scan_control(NXcollection): - # exists: optional - # roi(NXtransformations): - # frame: - # doc: Also clarify the frame for the ROI of the scan (should depend on the lab frame) - # circuit(NXcollection): - # channels_current: - # doc: The scan channels are selected by users. (e.g. (A);Bias (V);Z (m);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A)) - # positioner(NXcollection): - # scanfield(NX_NUMBER): - # doc: Configure the scan frame like x position; y position; width; height. (e.g. 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0) - # pixels_line(NX_NUMBER): - # doc: Scan resolution by setting the Lines equal to Pixels. (e.g. 512) - # lines(NX_NUMBER): - # doc: Define the image resolution. (e.g. 512) - # speed_forw(NX_NUMBER): - # doc: Define the scan forward speed in the forward direction. (m/s) (e.g. 11.7187E-9) - # speed_backw(NX_NUMBER): - # doc: Define the scan backward speed in the forward direction. (m/s) (e.g. 11.7187E-9) - # # RESOLUTION (calculation input) - # # TODO: After fix resolution_indicators back to required - # # As all of the bellow are linked - # resolution_indicators(NXprocess): - # exists: optional - # # Temperature 1>link to INSTR/STM/head Temperature 1 (K) (e.g. 4.92997E+0) # Temperature of STM head. - # temp_stm_head: - # # Temperature 2>link to Temperature 2 (K) - # Temperature of bottom of LHe helium cryostat. - # temp_cryo_bottom: - # # Temperature 3>link to Temperature 3 (K) - # Temperature of LN2 nitrogen shield. - # temp_cryo_shield: - # # Lock-in>link to Modulated signal Bias (V) (e.g. 1E-3) # Applied modulation to the bias voltage. - # modulated_signal_bias: - # # link to Integration time (s) (e.g. 150E-6) # Time during which the spectroscopy data are acquired and averaged. - # integration_time: - # # link to Bias Spectroscopy>Number of sweeps (e.g. 100) # Number of sweeps to measure and average. - # number_of_sweps: - # # link to Bias Spectroscopy>Sweep Start (V) (e.g. -300E-3) # The first bias values of the sweep. - # sweep_start: - # # link to Bias Spectroscopy>Sweep End (V) (e.g. 300E-3) # The last bias values of the sweep. - # sweep_end: - # # link to Bias Spectroscopy>Num Pixel (e.g. 4096) # Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. - # number_of_pixels: - # # link to Bias Spectroscopy>Z Avg time (s) (e.g. 100E-3) # Duration over which the Z - # # position is recorded and averaged before and after the sweep (the latter only if Record - # # final Z position is selected in the Advanced section). After the initial Z averaging - # # time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is - # # set to hold and the tip is placed at the previously averaged Z position (plus Z offset). - # z_avg_time: - # # link to SoftwareMain>RT Frequency (Hz) (e.g. 20E+3) # The bandwitdh of the - # # Hardware and/or Software - # rt_freq: - # # link to SoftwareMain>Signals Oversampling (e.g. 10) # (Signals Periods) - # # The Signals Period is the rate at which the signals are transferred to the host computer - # # running the control software. This is usually lower by a factor of 10 than the sampling - # # rate, because an internal oversampling of the signal is done on the real time engine. - # # You can reduce the oversampling down to 1 in order to resolve higher frequencies in the - # # Spectrum Analyzer. - # oversampling: - # # link to SoftwareMain>Acquisition Period (s) (e.g. 20E-3) # Update rate for several - # # processes like History Graph, Auto-Approach, and for many Programming Interface functions. - # # This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples - # # of this value. They can be set to different values, but the actual timing value will be - # # coerced to a multiple of the Acquisition Period. - # acquisition_period: - # # link to SoftwareMain>Animations Period (s) (e.g. 20E-3) # Update rate of animated - # # graphical indicators. These are e.g. some graphs & sliders. A reasonable value is - # # 40 ms (25 updates per second). Increase this period to reduce the processor load - # # for the graphical user interface, especially on slow computers. This value is purely a - # # user interface update rate and does not affect measurements in any way. - # animation_period: - # # link to SoftwareMain>Indicators Period (s) (e.g. 300E-3) # Update rate of digital - # # indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per - # # second, or 300 ms is enough. This value is purely a user interface update rate and - # # does not affect measurements in any way. - # indicators_period: - # # link to SoftwareMain>Measurements Period (s) (e.g. 500E-3) # The Measurements - # # period is the integration time for precise measurements (averaging over specified period), - # # mostly used in sweep modules. Examples are recording of a force-distance curve or a - # # resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be - # # reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a - # # high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. - # measurement_period: - # # TODO: Later fix REPRODUCIBILITY_indicator - # # as all of the bellow are linked - # reproducibility_indicators(NXprocess): - # exists: optional - # # Bias>Bias(NXBias) (V) (e.g. 100E-3) # Applied bias voltage. - # bias: - # # Current>Current(NXcircuit) (A) (e.g. -5.3429E-15) # The tunneling current is displayed here. - # current: - # # Bias>Calibration(NXbias) (V/V) (e.g. 1E+0) Calibration of the Bias output. If you have a Range switch the calibration is stored per range setting. - # bias_calibration: - # # Bias>Offset(NXbias) (V) (e.g. 0E+0) Allows compensating for an offset in Bias. - # bias_offset: - # # Current>Calibration(NXcircuit) (A/V) (e.g. 100E-12) - # # The signals voltages are converted to real world physical values according to the calibration & offset parameters: - # # Physical signal = (Voltage * calibration) + offset. - # current_calibration: - # # Current>Offset(NXcircuit) (A) (e.g. 16.2897E-15) # The same as "Current>Calibration (A/V)" tag - # current_offset: - # # Current>Gain(NXcircuit) (e.g. Not switchable) # None - # current_gain: - # # Z offset(NXpositioner) (m) (e.g. 0E+0) # Offset added to the initial averaged position - # # Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is - # # deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an - # # alternate Z-controller setpoint is enabled. - # z_offset: - # # Settling time(NXbias) (s) (e.g. 2.1E-3) Time to wait after changing the bias to the next - # # level and before starting to acquire data. Adjust this parameter to avoid transient - # # effect induced by the bias change. Integration time: time during which the data are - # # acquired and averaged. - # settling_time: - # # Z-Ctrl hold(NXpositioner) (e.g. TRUE) # When selected, the Z-Controller is set to hold - # # during the pulse. This means that the controller doesn't control the Z position during the pulse. - # z_control_hold: - # # Final Z(NXpositioner) (m) (e.g. N/A) - # final_z: - # # Start time(NXlog) (e.g.23.11.2022 18:55:16) # Timestamp of the moment when the acquisition starts by pressing the Start button. - # start_time: - # # Bias Spectroscopy>1st Settling time(NXbias) (s) (e.g.2.1E-3) # See the "Settling time (s)" below. - # 1st_settling_time: - # # Bias Spectroscopy>Integration time(NXbias) (s) (e.g.150E-6) # Time during which the data - # # are acquired and averaged. - # integration_time: - # # Bias Spectroscopy>End Settling time(NXbias) (s) (e.g.4E-3) # Time to wait after the sweep has finished and the bias is ramped to the initial value. - # end_settling_time: - # # Bias Spectroscopy>Z control time(NXbias) (s) (e.g.200E-3) # Time during which the - # # Z-Controller is enabled once a sweep has finished. When averaging multiple sweeps - # # (i.e. Sweeps>1), the Z-Controller is enabled for this duration between each sweep. - # # After the last sweep, it will wait the specified time before continuing a running scan. - # # This ensures each sweep reliably starts from the same position. This parameter is - # # disabled when Z-Controller to Hold is deselected in the Advanced section. - # z_contro_time: - # # Bias Spectroscopy>Max Slew rate(NXbias) (V/s) (e.g.1E+0) # Maximum rate at which - # # the bias changes (before, during and after sweeping). - # max_slew_rate: - # # Bias Spectroscopy>backward sweep(NXbias) (e.g.TRUE) # Select whether to measure - # # the backward (return) sweep or the forward only. - # backward_sweep: - # # Z-Controller>Controller name(NXpositioner) (e.g.log Current) # Controller name. - # # This name which will be displayed at places where you can select a controller. - # z_control_name: - # # Z-Controller>Controller status(NXpositioner) (e.g.OFF) # ON/OFF - # z_control_status: - # # Z-Controller>Setpoint(NXpositioner) (e.g.50E-12) # Set Point is the desired value - # # of the control signal. It can be set by editing the number or using the slider bar. - # # Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. - # # Z-Controller>Setpoint unit(NXpositioner) (e.g.A) # Angstrom - # z_sontrol_setpoint: - # # Z-Controller>P gain(NXpid) (e.g.6E-12) # The Type switches controller parameters - # # between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). - # # The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). - # # The integral gain and time constant are related as follows: I = P/T. - # z_control_p_gain: - # # Z-Controller>I gain(NXpid) (e.g.39.8241E-9) # See "Z-Controller>P gain" below. - # z_control_i_gain: - # # Z-Controller>Time const(NXpid) (s) (e.g.150.662E-6) # See "Z-Controller>P gain" below. - # z_control_time_const: - # # Z-Controller>TipLift(NXpositioner) (m) (e.g.0E+0) # Lifts the tip by the specified - # # amount when then controller is switched off. This can be a positive or a negative number, - # # i.e. the tip can also be moved towards the sample. Be careful with sign and value when - # # using this feature. - # z_control_tip_lift: - # # Z-Controller>Switch off delay(NXpositioner) (s) (e.g.0E+0) # Use this parameter for - # # a reproducible position when switching off the Z-controller. When >0 and the Z-controller - # # is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. - # z_control_switchoff_delay: - # # TODO: discuss convertion data to DATA - # (NXdata): - # doc: | - # This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. - # There should also be two more fields called temperature and voltage containing the setpoint values. - # There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension - # equal to the number of voltage setpoints. - # axes: bias_calc - # signals: - # li_demod_[1;2]_[X/Y]_[-;bwd;filt;bwd_filt] - # current_[-;bwd;filt;bwd_filt] - # temperature - # x - # y - # z - # # DATA # multi dimensional array: multi I-V array per scan point; - # # doc: The format of the data here is similar to a column matrix. - # # Bias calc (V) #scanning parameter - # # Current (A) # current during forward direction scanning of bias - original NXsensor - # # LI Demod 2 X (A) lockin (NXsensor+lockin) - # # LI Demod 2 Y (A) lockin - # # LI Demod 1 X (A) lockin - # # LI Demod 1 Y (A) lockin - # # Current [bwd] (A) #bwd - backward (the positive direction shall be clarified by the reference bias scanning frame. Fwd means from left(neg) to right(pos). In the scannig image, the bottom(neg) to top(pos), the left(neg) to right(pos) - # # LI Demod 2 X [bwd] (A) lockin - # # LI Demod 2 Y [bwd] (A) lockin - # # LI Demod 1 X [bwd] (A) lockin - # # LI Demod 1 Y [bwd] (A) lockin - # # Current (A) [filt] # forward direction (maybe from lockin#2?) - # # LI Demod 2 X (A) [filt] lockin - # # LI Demod 2 Y (A) [filt] lockin - # # LI Demod 1 X (A) [filt] lockin - # # LI Demod 1 Y (A) [filt] lockin - # # Current (A) [bwd] [filt] - # # LI Demod 2 X (A) [bwd] [filt] lockin - # # LI Demod 2 Y (A) [bwd] [filt] lockin - # # LI Demod 1 X (A) [bwd] [filt] lockin - # # LI Demod 1 Y (A) [bwd] [filt] lockin - # # Temperature - # # x - # # y - # # z - # # single point default plot # current(I) vs bias(V) - # single_point(NXdata): - # exists: optional - # # line scan default plot # multi I vs. V curves - # line_scan(NXdata): - # exists: optional - # # alternative plot # current(I) curve in the 2D space of (position(x), bias(V)) - # alternative_plot(NXdata): - # exists: optional - # # mesh scan default plot # 2D slices of the above alternative plot - # mesh_scan(NXdata): - # exists: optional + # Cabling & Config + # output_mode: + # doc: Number of output channels. (e.g. User Output) + # output_value(NX_NUMBER): + # doc: The user output in each monitor mode. (e.g. 0E+0) + # output_name: + # doc: User outputs whose name can be modified in the corresponding module. (e.g. Input 24 (V)) + # output_slew_rate(NX_NUMBER): + # doc: The rate at which the one of the signal changes when ramping to the starting point. (V/s) (e.g. Inf) + piezo_config(NXcollection): + doc: | + Configuration for piezoelectric scanner used to move tip along X and Y direction. The + material of the Piezoelectric scanner composed of polycrystalline solids and nsensitve to + applied voltage. + active_calib: + doc: The name of caliberation type. (e.g. LHe) + calib_N(NX_NUMBER): + exists: optional + doc: | + N denotes X or Y or Z. There are 3 parameters in X, Y, and Z directions and there + are 3 controls availables: Calibr. (m/V), Range (m) and HV gain. Two of them are + enough to define the calibration, so when changing any value one of the other values + will be updated automatically. (e.g. 3.8E-9) + hv_gain_N(NX_NUMBER): + exists: optional + doc: N denotes X or Y or Z. For some systems HV gain readout is available, + so for those systems the HV gain should be adjusted automatically when the gain + is changed at the high voltage amplifier. (e.g. 14.5) + # (e.g. 0.318343) + tilt_N(NX_NUMBER): + exists: optional + unit: NX_ANGLE + doc: | + N denotes X or Y. There are 2 parameters in X and Y directions and this tab + is used to set the sample tilt (in degrees, first order correction). + # Inf + curvature_radius_N(NX_NUMBER): + exists: optional + unit: NX_LENGTH + doc: N denotes X or Y. There are 2 parameters in X and Y directions and this tab + is used to set a curvature (can be set approximately to the length of the piezotube). + 2nd_order_corr_N(NX_NUMBER): + exists: optional + doc: | + N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, + you can enter the 2nd order piezo characteristics to compensate for it. The + following equation shows the interpretation of the 2nd order correction parameter: + For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: + [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx + is the 2nd order correction. (V/m^2). (e.g. 0E+0) + drift_N(NX_NUMBER): + exists: optional + doc: | + N denotes X, Y or Z. There are 3 parameters in X, Y and Z directions. Define the + drift speed for all three axes. When the compensation is on, the piezos will start to + move at that speed. (e.g. 0E+0) + drift_correction_status(NX_BOOLEAN): + doc: Use the button to turn on/off the drift compensation. (e.g. FALSE) + (NXenvironment): + doc: | + Describes an environment setup for a temperature-dependent IV measurement experiment. + The temperature and voltage must be present as independently scanned controllers and + the current sensor must also be present with its readings. + voltage_controller(NXsensor): + exists: optional + temperature_controller(NXsensor): + current_sensor(NXsensor): + position(NXpositioner): + doc: Clarify the frame laboratory frame. + x(NX_NUMBER): + exists: optional + unit: NX_LENGTH + doc: The scanning area in x position in the frame. (e.g. -890.53E-12) + y(NX_NUMBER): + exists: optional + unit: NX_LENGTH + doc: The scanning area in y position in the frame. (e.g. 29.6968E-9) + z(NX_NUMBER): + exists: optional + unit: NX_LENGTH + doc: The scanning area in x position in the frame. (e.g. 130.5E-9) + z_controller(NX_NUMBER): + unit: NX_LENGTH + doc: Indicate the tip position Z between tip and sample. The tip position can also be varied when the controller is not running. (e.g. 130.5E-9) + # parameters for a measurement at a single location during the scan + sweep_control(NXcollection): + bias_spectroscopy(NXbias_spectroscopy): + integration_time(NX_NUMBER): + unit: NX_TIME + doc: Time during which the spectroscopy data are acquired and averaged. (e.g. 150E-6) + number_of_sweeps(NX_NUMBER): + doc: Number of sweeps to measure and average. (e.g. 100) + sweep_start(NX_NUMBER): + unit: NX_VOLTAGE + doc: The first bias values of the sweep. (e.g. -300E-3) + sweep_end(NX_NUMBER): + unit: NX_VOLTAGE + doc: The last bias values of the sweep. (e.g. 300E-3) + num_pixel(NX_NUMBER): + doc: Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. (e.g. 4096) + z_avg_time(NX_NUMBER): + unit: NX_TIME + doc: Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). (e.g. 100E-3) + circuit(NXcollection): + rt_frequency(NX_NUMBER): + unit: NX_FREQENCY + doc: The bandwitdh of the Hardware and/or Software (e.g. 20E+3) + signals_oversampling(NX_NUMBER): + doc: (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. (e.g. 10) + acquisition_period(NX_NUMBER): + unit: NX_TIME + exists: optional + doc: Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. (e.g. 20E-3) + animations_period(NX_NUMBER): + unit: NX_TIME + exists: optional + doc: Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. (e.g. 20E-3) + indicators_period(NX_NUMBER): + unit: NX_TIME + doc: Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. (e.g. 300E-3) + measurements_period(NX_NUMBER): + exists: optional + unit: NX_TIME + doc: The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. (e.g. 500E-3) + # parameters how to change the location from measurement to measurement during the scan + scan_control(NXcollection): + exists: optional + roi(NXtransformations): + frame: + doc: Also clarify the frame for the ROI of the scan (should depend on the lab frame) + circuit(NXcollection): + channels_current: + doc: The scan channels are selected by users. (e.g. (A);Bias (V);Z (m);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A)) + positioner(NXcollection): + scanfield(NX_NUMBER): + doc: Configure the scan frame like x position; y position; width; height. (e.g. 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0) + pixels_line(NX_NUMBER): + doc: Scan resolution by setting the Lines equal to Pixels. (e.g. 512) + lines(NX_NUMBER): + doc: Define the image resolution. (e.g. 512) + speed_forw(NX_NUMBER): + doc: Define the scan forward speed in the forward direction. (m/s) (e.g. 11.7187E-9) + speed_backw(NX_NUMBER): + doc: Define the scan backward speed in the forward direction. (m/s) (e.g. 11.7187E-9) + # RESOLUTION (calculation input) + # TODO: After fix resolution_indicators back to required + # As all of the bellow are linked + resolution_indicators(NXprocess): + exists: optional + # Temperature 1>link to INSTR/STM/head Temperature 1 (K) (e.g. 4.92997E+0) # Temperature of STM head. + temp_stm_head: + # Temperature 2>link to Temperature 2 (K) - # Temperature of bottom of LHe helium cryostat. + temp_cryo_bottom: + # Temperature 3>link to Temperature 3 (K) - # Temperature of LN2 nitrogen shield. + temp_cryo_shield: + # Lock-in>link to Modulated signal Bias (V) (e.g. 1E-3) # Applied modulation to the bias voltage. + modulated_signal_bias: + # link to Integration time (s) (e.g. 150E-6) # Time during which the spectroscopy data are acquired and averaged. + integration_time: + # link to Bias Spectroscopy>Number of sweeps (e.g. 100) # Number of sweeps to measure and average. + number_of_sweps: + # link to Bias Spectroscopy>Sweep Start (V) (e.g. -300E-3) # The first bias values of the sweep. + sweep_start: + # link to Bias Spectroscopy>Sweep End (V) (e.g. 300E-3) # The last bias values of the sweep. + sweep_end: + # link to Bias Spectroscopy>Num Pixel (e.g. 4096) # Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. + number_of_pixels: + # link to Bias Spectroscopy>Z Avg time (s) (e.g. 100E-3) # Duration over which the Z + # position is recorded and averaged before and after the sweep (the latter only if Record + # final Z position is selected in the Advanced section). After the initial Z averaging + # time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is + # set to hold and the tip is placed at the previously averaged Z position (plus Z offset). + z_avg_time: + # link to SoftwareMain>RT Frequency (Hz) (e.g. 20E+3) # The bandwitdh of the + # Hardware and/or Software + rt_freq: + # link to SoftwareMain>Signals Oversampling (e.g. 10) # (Signals Periods) + # The Signals Period is the rate at which the signals are transferred to the host computer + # running the control software. This is usually lower by a factor of 10 than the sampling + # rate, because an internal oversampling of the signal is done on the real time engine. + # You can reduce the oversampling down to 1 in order to resolve higher frequencies in the + # Spectrum Analyzer. + oversampling: + # link to SoftwareMain>Acquisition Period (s) (e.g. 20E-3) # Update rate for several + # processes like History Graph, Auto-Approach, and for many Programming Interface functions. + # This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples + # of this value. They can be set to different values, but the actual timing value will be + # coerced to a multiple of the Acquisition Period. + acquisition_period: + # link to SoftwareMain>Animations Period (s) (e.g. 20E-3) # Update rate of animated + # graphical indicators. These are e.g. some graphs & sliders. A reasonable value is + # 40 ms (25 updates per second). Increase this period to reduce the processor load + # for the graphical user interface, especially on slow computers. This value is purely a + # user interface update rate and does not affect measurements in any way. + animation_period: + # link to SoftwareMain>Indicators Period (s) (e.g. 300E-3) # Update rate of digital + # indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per + # second, or 300 ms is enough. This value is purely a user interface update rate and + # does not affect measurements in any way. + indicators_period: + # link to SoftwareMain>Measurements Period (s) (e.g. 500E-3) # The Measurements + # period is the integration time for precise measurements (averaging over specified period), + # mostly used in sweep modules. Examples are recording of a force-distance curve or a + # resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be + # reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a + # high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. + measurement_period: + # TODO: Later fix REPRODUCIBILITY_indicator + # as all of the bellow are linked + reproducibility_indicators(NXprocess): + exists: optional + # Bias>Bias(NXBias) (V) (e.g. 100E-3) # Applied bias voltage. + bias: + # Current>Current(NXcircuit) (A) (e.g. -5.3429E-15) # The tunneling current is displayed here. + current: + # Bias>Calibration(NXbias) (V/V) (e.g. 1E+0) Calibration of the Bias output. If you have a Range switch the calibration is stored per range setting. + bias_calibration: + # Bias>Offset(NXbias) (V) (e.g. 0E+0) Allows compensating for an offset in Bias. + bias_offset: + # Current>Calibration(NXcircuit) (A/V) (e.g. 100E-12) + # The signals voltages are converted to real world physical values according to the calibration & offset parameters: + # Physical signal = (Voltage * calibration) + offset. + current_calibration: + # Current>Offset(NXcircuit) (A) (e.g. 16.2897E-15) # The same as "Current>Calibration (A/V)" tag + current_offset: + # Current>Gain(NXcircuit) (e.g. Not switchable) # None + current_gain: + # Z offset(NXpositioner) (m) (e.g. 0E+0) # Offset added to the initial averaged position + # Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is + # deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an + # alternate Z-controller setpoint is enabled. + z_offset: + # Settling time(NXbias) (s) (e.g. 2.1E-3) Time to wait after changing the bias to the next + # level and before starting to acquire data. Adjust this parameter to avoid transient + # effect induced by the bias change. Integration time: time during which the data are + # acquired and averaged. + settling_time: + # Z-Ctrl hold(NXpositioner) (e.g. TRUE) # When selected, the Z-Controller is set to hold + # during the pulse. This means that the controller doesn't control the Z position during the pulse. + z_control_hold: + # Final Z(NXpositioner) (m) (e.g. N/A) + final_z: + # Start time(NXlog) (e.g.23.11.2022 18:55:16) # Timestamp of the moment when the acquisition starts by pressing the Start button. + start_time: + # Bias Spectroscopy>1st Settling time(NXbias) (s) (e.g.2.1E-3) # See the "Settling time (s)" below. + 1st_settling_time: + # Bias Spectroscopy>Integration time(NXbias) (s) (e.g.150E-6) # Time during which the data + # are acquired and averaged. + integration_time: + # Bias Spectroscopy>End Settling time(NXbias) (s) (e.g.4E-3) # Time to wait after the sweep has finished and the bias is ramped to the initial value. + end_settling_time: + # Bias Spectroscopy>Z control time(NXbias) (s) (e.g.200E-3) # Time during which the + # Z-Controller is enabled once a sweep has finished. When averaging multiple sweeps + # (i.e. Sweeps>1), the Z-Controller is enabled for this duration between each sweep. + # After the last sweep, it will wait the specified time before continuing a running scan. + # This ensures each sweep reliably starts from the same position. This parameter is + # disabled when Z-Controller to Hold is deselected in the Advanced section. + z_contro_time: + # Bias Spectroscopy>Max Slew rate(NXbias) (V/s) (e.g.1E+0) # Maximum rate at which + # the bias changes (before, during and after sweeping). + max_slew_rate: + # Bias Spectroscopy>backward sweep(NXbias) (e.g.TRUE) # Select whether to measure + # the backward (return) sweep or the forward only. + backward_sweep: + # Z-Controller>Controller name(NXpositioner) (e.g.log Current) # Controller name. + # This name which will be displayed at places where you can select a controller. + z_control_name: + # Z-Controller>Controller status(NXpositioner) (e.g.OFF) # ON/OFF + z_control_status: + # Z-Controller>Setpoint(NXpositioner) (e.g.50E-12) # Set Point is the desired value + # of the control signal. It can be set by editing the number or using the slider bar. + # Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. + # Z-Controller>Setpoint unit(NXpositioner) (e.g.A) # Angstrom + z_sontrol_setpoint: + # Z-Controller>P gain(NXpid) (e.g.6E-12) # The Type switches controller parameters + # between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). + # The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). + # The integral gain and time constant are related as follows: I = P/T. + z_control_p_gain: + # Z-Controller>I gain(NXpid) (e.g.39.8241E-9) # See "Z-Controller>P gain" below. + z_control_i_gain: + # Z-Controller>Time const(NXpid) (s) (e.g.150.662E-6) # See "Z-Controller>P gain" below. + z_control_time_const: + # Z-Controller>TipLift(NXpositioner) (m) (e.g.0E+0) # Lifts the tip by the specified + # amount when then controller is switched off. This can be a positive or a negative number, + # i.e. the tip can also be moved towards the sample. Be careful with sign and value when + # using this feature. + z_control_tip_lift: + # Z-Controller>Switch off delay(NXpositioner) (s) (e.g.0E+0) # Use this parameter for + # a reproducible position when switching off the Z-controller. When >0 and the Z-controller + # is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. + z_control_switchoff_delay: + # TODO: discuss convertion data to DATA + (NXdata): + doc: | + This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. + There should also be two more fields called temperature and voltage containing the setpoint values. + There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension + equal to the number of voltage setpoints. + axes: bias_calc + signals: + li_demod_[1;2]_[X/Y]_[-;bwd;filt;bwd_filt] + current_[-;bwd;filt;bwd_filt] + temperature + x + y + z + # DATA # multi dimensional array: multi I-V array per scan point; + # doc: The format of the data here is similar to a column matrix. + # Bias calc (V) #scanning parameter + # Current (A) # current during forward direction scanning of bias - original NXsensor + # LI Demod 2 X (A) lockin (NXsensor+lockin) + # LI Demod 2 Y (A) lockin + # LI Demod 1 X (A) lockin + # LI Demod 1 Y (A) lockin + # Current [bwd] (A) #bwd - backward (the positive direction shall be clarified by the reference bias scanning frame. Fwd means from left(neg) to right(pos). In the scannig image, the bottom(neg) to top(pos), the left(neg) to right(pos) + # LI Demod 2 X [bwd] (A) lockin + # LI Demod 2 Y [bwd] (A) lockin + # LI Demod 1 X [bwd] (A) lockin + # LI Demod 1 Y [bwd] (A) lockin + # Current (A) [filt] # forward direction (maybe from lockin#2?) + # LI Demod 2 X (A) [filt] lockin + # LI Demod 2 Y (A) [filt] lockin + # LI Demod 1 X (A) [filt] lockin + # LI Demod 1 Y (A) [filt] lockin + # Current (A) [bwd] [filt] + # LI Demod 2 X (A) [bwd] [filt] lockin + # LI Demod 2 Y (A) [bwd] [filt] lockin + # LI Demod 1 X (A) [bwd] [filt] lockin + # LI Demod 1 Y (A) [bwd] [filt] lockin + # Temperature + # x + # y + # z + # single point default plot # current(I) vs bias(V) + single_point(NXdata): + exists: optional + # line scan default plot # multi I vs. V curves + line_scan(NXdata): + exists: optional + # alternative plot # current(I) curve in the 2D space of (position(x), bias(V)) + alternative_plot(NXdata): + exists: optional + # mesh scan default plot # 2D slices of the above alternative plot + mesh_scan(NXdata): + exists: optional From 951b694b2389ef7450449427f3d96e351b2db3d4 Mon Sep 17 00:00:00 2001 From: Rubel Date: Wed, 21 Jun 2023 22:35:38 +0200 Subject: [PATCH 0158/1012] Coorecting all the links but still the concept for all the links are not available. --- .../NXbias_spectroscopy.nxdl.xml | 35 ++-- contributed_definitions/NXiv_sweep2.nxdl.xml | 158 ++++++++------- .../nyaml/NXbias_spectroscopy.yaml | 30 ++- .../nyaml/NXiv_sweep2.yaml | 191 ++++++++++++------ 4 files changed, 266 insertions(+), 148 deletions(-) diff --git a/contributed_definitions/NXbias_spectroscopy.nxdl.xml b/contributed_definitions/NXbias_spectroscopy.nxdl.xml index 8be1269319..715ac6a5ee 100644 --- a/contributed_definitions/NXbias_spectroscopy.nxdl.xml +++ b/contributed_definitions/NXbias_spectroscopy.nxdl.xml @@ -109,31 +109,36 @@ Offset added to the initial averaged position Zaver before starting to sweep. - This parameter is disabled when Z-Controller to Hold is deselected in the - Advanced section. The LED “Alt” next to the Z offset indicates if an alternate + This parameter is disabled when Z-Controller to Hold is deselected in the + Advanced section. The LED “Alt” next to the Z offset indicates if an alternate Z-controller setpoint is enabled. - time to wait after changing the bias to the next level and before starting to - acquire data. + Time to wait after changing the bias to the next level and before + starting to acquire data. + + + + + No doc yet. - Time to wait after the sweep has finished and the bias is ramped to the initial - value. + Time to wait after the sweep has finished and the bias is ramped to + the initial value. - Time during which the Z-Controller is enabled once a sweep has finished. When - averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled for this - duration between each sweep. After the last sweep, it will wait the specified - time before continuing a running scan. This ensures each sweep reliably starts - from the same position. This parameter is disabled when Z-Controller to Hold is - deselected in the Advanced section. + Time during which the Z-Controller is enabled once a sweep has finished. + When averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled + for this duration between each sweep. After the last sweep, it will wait the + specified time before continuing a running scan. This ensures each sweep + reliably starts from the same position. This parameter is disabled when + Z-Controller to Hold is deselected in the Advanced section. @@ -149,9 +154,9 @@ - Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. - It is selected by default. When deselected, Z-offset and Z control time - parameters are disabled. + Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. + It is selected by default. When deselected, Z-offset and Z control time parameters + are disabled. diff --git a/contributed_definitions/NXiv_sweep2.nxdl.xml b/contributed_definitions/NXiv_sweep2.nxdl.xml index f25d23e7dc..f668ea578c 100644 --- a/contributed_definitions/NXiv_sweep2.nxdl.xml +++ b/contributed_definitions/NXiv_sweep2.nxdl.xml @@ -69,8 +69,7 @@ What is about [constant current mode, constand height mode]--> - The name of the output file, with the number of scans at the end.e.g. (e.g. - 221122_Au_5K00014) + The name of the output file, with the number of scans at the end.e.g. (e.g. 221122_Au_5K00014) @@ -81,9 +80,8 @@ What is about [constant current mode, constand height mode]--> - Path to storage of output files. (e.g. Path C:\Users\SPM- - PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis- - Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711) + Path to storage of output files. + (e.g. Path C:\Users\SPM-PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis-Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711) @@ -115,7 +113,8 @@ amplification: Current amplifier> factor (V/V): 1E-10 crosstalk_compensation: Current amplifier> Capacitive cross-talk compensation: Yes/No--> - The Amplifier description that improves or helps to determine tunnel current (current between tip and bias). + The Amplifier description that improves or helps to determine tunnel current (current + between tip and bias). @@ -304,7 +303,20 @@ doc: The rate at which the one of the signal changes when ramping to the startin - + + + + This is set-point of tip current. + + + + + Value of calibration that comes as A/V. + + + + + Clarify the frame laboratory frame. @@ -324,12 +336,14 @@ doc: The rate at which the one of the signal changes when ramping to the startin The scanning area in x position in the frame. (e.g. 130.5E-9) - - - Indicate the tip position Z between tip and sample. The tip position can also be - varied when the controller is not running. (e.g. 130.5E-9) - - + + + + Indicate the tip position Z between tip and sample. The tip position can also be + varied when the controller is not running. (e.g. 130.5E-9) + + + @@ -373,17 +387,18 @@ doc: The rate at which the one of the signal changes when ramping to the startin - The bandwitdh of the Hardware and/or Software (e.g. 20E+3) + The bandwitdh of the Hardware and/or Software which is insturment specific. + For example: Nanonis Generic 5 has 'RT Frequency' 20E-3. - (Signals Periods) The Signals Period is the rate at which the signals are - transferred to the host computer running the control software. This is usually - lower by a factor of 10 than the sampling rate, because an internal oversampling - of the signal is done on the real time engine. You can reduce the oversampling - down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. (e.g. - 10) + (Signals Periods) The Signals Period is the rate at which the signals are + transferred to the host computer running the control software. This is + usually lower by a factor of 10 than the sampling rate, because an internal + oversampling of the signal is done on the real time engine. You can reduce + the oversampling down to 1 in order to resolve higher frequencies in the + Spectrum Analyzer. (e.g. 10) @@ -477,150 +492,157 @@ doc: The rate at which the one of the signal changes when ramping to the startin - + - + - + - + - - - - - + + + + + - + - + - + - + - + - + - + - + - + - + - + - - - + + + - + - + - + - + - + - + - + - - - - - + + + - + - + - + - + - + - + - + - + - + - + - + - + - + diff --git a/contributed_definitions/nyaml/NXbias_spectroscopy.yaml b/contributed_definitions/nyaml/NXbias_spectroscopy.yaml index 6d53631502..529558c799 100644 --- a/contributed_definitions/nyaml/NXbias_spectroscopy.yaml +++ b/contributed_definitions/nyaml/NXbias_spectroscopy.yaml @@ -36,22 +36,42 @@ NXbias_spectroscopy(NXobject): sw_filter_cutoff_frq(NX_NUMBER): doc: Cutoff frequency for dynamic filters. z_offset(NX_NUMBER): - doc: Offset added to the initial averaged position Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an alternate Z-controller setpoint is enabled. + doc: | + Offset added to the initial averaged position Zaver before starting to sweep. + This parameter is disabled when Z-Controller to Hold is deselected in the + Advanced section. The LED “Alt” next to the Z offset indicates if an alternate + Z-controller setpoint is enabled. unit: NX_LENGTH settling_time(NX_NUMBER): - doc: time to wait after changing the bias to the next level and before starting to acquire data. + doc: | + Time to wait after changing the bias to the next level and before + starting to acquire data. unit: NX_TIME + first_settling_time(NX_NUMBER): + doc: | + No doc yet. end_settling_time(NX_NUMBER): - doc: Time to wait after the sweep has finished and the bias is ramped to the initial value. + doc: | + Time to wait after the sweep has finished and the bias is ramped to + the initial value. unit: NX_TIME z_control_time(NX_NUMBER): - doc: Time during which the Z-Controller is enabled once a sweep has finished. When averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled for this duration between each sweep. After the last sweep, it will wait the specified time before continuing a running scan. This ensures each sweep reliably starts from the same position. This parameter is disabled when Z-Controller to Hold is deselected in the Advanced section. + doc: | + Time during which the Z-Controller is enabled once a sweep has finished. + When averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled + for this duration between each sweep. After the last sweep, it will wait the + specified time before continuing a running scan. This ensures each sweep + reliably starts from the same position. This parameter is disabled when + Z-Controller to Hold is deselected in the Advanced section. unit: NX_TIME max_slew_rate(NX_NUMBER): doc: Maximum rate at which the bias changes (before, during and after sweeping). (V/s) backward_sweep(NX_BOOLEAN): doc: Select whether to measure the backward (return) sweep or the forward only. z_ccontroller_hold(NX_BOOLEAN): - doc: Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. + doc: | + Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. + It is selected by default. When deselected, Z-offset and Z control time parameters + are disabled. diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index 78ce2e7a4e..1afbf3c39b 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -34,12 +34,15 @@ NXiv_sweep2(NXsensor_scan): are used during the experiments used in the scanning tunneling microscopy(STM). entry_identifier: exists: optional - doc: The name of the output file, with the number of scans at the end.e.g. (e.g. 221122_Au_5K00014) + doc: | + The name of the output file, with the number of scans at the end.e.g. (e.g. 221122_Au_5K00014) collection_dentifier: doc: The name of the series output file, which represents only the public part of the output file. (e.g. 221122_Au_5K) experiment_identifier: exists: optional - doc: Path to storage of output files. (e.g. Path C:\Users\SPM-PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis-Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711) + doc: | + Path to storage of output files. + (e.g. Path C:\Users\SPM-PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis-Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711) experiment_description: exists: optional doc: | @@ -64,7 +67,8 @@ NXiv_sweep2(NXsensor_scan): current_amplifier(NXamplifier): exists: optional doc: | - The Amplifier description that improves or helps to determine tunnel current (current between tip and bias). + The Amplifier description that improves or helps to determine tunnel current (current + between tip and bias). lock_in(NXlockin): status: # status: Lock-in>Lock-in status ON # ON/OFF of Lock-in amplifier @@ -230,6 +234,17 @@ NXiv_sweep2(NXsensor_scan): exists: optional temperature_controller(NXsensor): current_sensor(NXsensor): + current: + doc: | + This is set-point of tip current. + unit: NX_CURRENT + current_calibration: + doc: | + Value of calibration that comes as A/V. + unit: NX_NUMBER + current_offset: + unit: NX_CURRENT + current_gain: position(NXpositioner): doc: Clarify the frame laboratory frame. x(NX_NUMBER): @@ -244,9 +259,10 @@ NXiv_sweep2(NXsensor_scan): exists: optional unit: NX_LENGTH doc: The scanning area in x position in the frame. (e.g. 130.5E-9) - z_controller(NX_NUMBER): - unit: NX_LENGTH - doc: Indicate the tip position Z between tip and sample. The tip position can also be varied when the controller is not running. (e.g. 130.5E-9) + z_controller(NXcollection): + z: + unit: NX_LENGTH + doc: Indicate the tip position Z between tip and sample. The tip position can also be varied when the controller is not running. (e.g. 130.5E-9) # parameters for a measurement at a single location during the scan sweep_control(NXcollection): bias_spectroscopy(NXbias_spectroscopy): @@ -269,9 +285,17 @@ NXiv_sweep2(NXsensor_scan): circuit(NXcollection): rt_frequency(NX_NUMBER): unit: NX_FREQENCY - doc: The bandwitdh of the Hardware and/or Software (e.g. 20E+3) + doc: | + The bandwitdh of the Hardware and/or Software which is insturment specific. + For example: Nanonis Generic 5 has 'RT Frequency' 20E-3. signals_oversampling(NX_NUMBER): - doc: (Signals Periods) The Signals Period is the rate at which the signals are transferred to the host computer running the control software. This is usually lower by a factor of 10 than the sampling rate, because an internal oversampling of the signal is done on the real time engine. You can reduce the oversampling down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. (e.g. 10) + doc: | + (Signals Periods) The Signals Period is the rate at which the signals are + transferred to the host computer running the control software. This is + usually lower by a factor of 10 than the sampling rate, because an internal + oversampling of the signal is done on the real time engine. You can reduce + the oversampling down to 1 in order to resolve higher frequencies in the + Spectrum Analyzer. (e.g. 10) acquisition_period(NX_NUMBER): unit: NX_TIME exists: optional @@ -311,150 +335,197 @@ NXiv_sweep2(NXsensor_scan): # TODO: After fix resolution_indicators back to required # As all of the bellow are linked resolution_indicators(NXprocess): - exists: optional # Temperature 1>link to INSTR/STM/head Temperature 1 (K) (e.g. 4.92997E+0) # Temperature of STM head. - temp_stm_head: + temp_stm_head(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/stm_head_temp # Temperature 2>link to Temperature 2 (K) - # Temperature of bottom of LHe helium cryostat. - temp_cryo_bottom: + temp_cryo_bottom(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/temp_cryo_bottom # Temperature 3>link to Temperature 3 (K) - # Temperature of LN2 nitrogen shield. - temp_cryo_shield: + temp_cryo_shield(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/temp_cryo_shield # Lock-in>link to Modulated signal Bias (V) (e.g. 1E-3) # Applied modulation to the bias voltage. - modulated_signal_bias: - # link to Integration time (s) (e.g. 150E-6) # Time during which the spectroscopy data are acquired and averaged. - integration_time: - # link to Bias Spectroscopy>Number of sweeps (e.g. 100) # Number of sweeps to measure and average. - number_of_sweps: + modulated_signal_bias(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/lock_in/modulation_signal + # link to Integration time (s) (e.g. 150E-6) + # Time during which the spectroscopy data are acquired and averaged. + integration_time(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/sweep_control/bias_spectroscopy/integration_time + # link to Bias Spectroscopy>Number of sweeps (e.g. 100) + # Number of sweeps to measure and average. + number_of_sweps(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/sweep_control/bias_spectroscopy/number_of_sweeps # link to Bias Spectroscopy>Sweep Start (V) (e.g. -300E-3) # The first bias values of the sweep. - sweep_start: + sweep_start(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/sweep_control/bias_spectroscopy/sweep_start # link to Bias Spectroscopy>Sweep End (V) (e.g. 300E-3) # The last bias values of the sweep. - sweep_end: + sweep_end(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/sweep_control/bias_spectroscopy/sweep_end # link to Bias Spectroscopy>Num Pixel (e.g. 4096) # Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. - number_of_pixels: + num_pixel(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/sweep_control/bias_spectroscopy/num_pixel # link to Bias Spectroscopy>Z Avg time (s) (e.g. 100E-3) # Duration over which the Z # position is recorded and averaged before and after the sweep (the latter only if Record # final Z position is selected in the Advanced section). After the initial Z averaging # time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is # set to hold and the tip is placed at the previously averaged Z position (plus Z offset). - z_avg_time: + z_avg_time(link): + target: /ENTRY[entry]/resolution_indicators/z_avg_time # link to SoftwareMain>RT Frequency (Hz) (e.g. 20E+3) # The bandwitdh of the # Hardware and/or Software - rt_freq: + rt_freq(link): + target: /ENTRY[entry]/resolution_indicators/rt_freq # link to SoftwareMain>Signals Oversampling (e.g. 10) # (Signals Periods) # The Signals Period is the rate at which the signals are transferred to the host computer # running the control software. This is usually lower by a factor of 10 than the sampling # rate, because an internal oversampling of the signal is done on the real time engine. # You can reduce the oversampling down to 1 in order to resolve higher frequencies in the - # Spectrum Analyzer. - oversampling: + # Spectrum Analyzer. + oversampling(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/sweep_control/circuit/signals_oversampling # link to SoftwareMain>Acquisition Period (s) (e.g. 20E-3) # Update rate for several # processes like History Graph, Auto-Approach, and for many Programming Interface functions. # This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples # of this value. They can be set to different values, but the actual timing value will be # coerced to a multiple of the Acquisition Period. - acquisition_period: + acquisition_period(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/sweep_control/circuit/acquisition_period # link to SoftwareMain>Animations Period (s) (e.g. 20E-3) # Update rate of animated # graphical indicators. These are e.g. some graphs & sliders. A reasonable value is # 40 ms (25 updates per second). Increase this period to reduce the processor load # for the graphical user interface, especially on slow computers. This value is purely a - # user interface update rate and does not affect measurements in any way. - animation_period: + # user interface update rate and does not affect measurements in any way. + animation_period(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/sweep_control/circuit/animations_period # link to SoftwareMain>Indicators Period (s) (e.g. 300E-3) # Update rate of digital # indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per # second, or 300 ms is enough. This value is purely a user interface update rate and # does not affect measurements in any way. - indicators_period: + indicators_period(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/sweep_control/circuit/indicators_period # link to SoftwareMain>Measurements Period (s) (e.g. 500E-3) # The Measurements # period is the integration time for precise measurements (averaging over specified period), # mostly used in sweep modules. Examples are recording of a force-distance curve or a # resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be # reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a # high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. - measurement_period: + measurement_period(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/sweep_control/circuit/measurements_period # TODO: Later fix REPRODUCIBILITY_indicator # as all of the bellow are linked reproducibility_indicators(NXprocess): exists: optional # Bias>Bias(NXBias) (V) (e.g. 100E-3) # Applied bias voltage. - bias: + bias(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/sample_bias/bias # Current>Current(NXcircuit) (A) (e.g. -5.3429E-15) # The tunneling current is displayed here. - current: - # Bias>Calibration(NXbias) (V/V) (e.g. 1E+0) Calibration of the Bias output. If you have a Range switch the calibration is stored per range setting. - bias_calibration: - # Bias>Offset(NXbias) (V) (e.g. 0E+0) Allows compensating for an offset in Bias. - bias_offset: + current(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/current_sensor/current + # Bias>Calibration(NXbias) (V/V) (e.g. 1E+0) Calibration of the Bias output. If you have + # a Range switch the calibration is stored per range setting. + bias_calibration(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/sample_bias/calibration + # Bias>Offset(NXbias) (V) (e.g. 0E+0) Allows compensating for an offset in Bias. + bias_offset(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/sample_bias/offset # Current>Calibration(NXcircuit) (A/V) (e.g. 100E-12) # The signals voltages are converted to real world physical values according to the calibration & offset parameters: # Physical signal = (Voltage * calibration) + offset. - current_calibration: + current_calibration(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/current_sensor/current_calibration # Current>Offset(NXcircuit) (A) (e.g. 16.2897E-15) # The same as "Current>Calibration (A/V)" tag - current_offset: + current_offset(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/current_sensor/current_offset # Current>Gain(NXcircuit) (e.g. Not switchable) # None - current_gain: + current_gain(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/current_sensor/current_gain # Z offset(NXpositioner) (m) (e.g. 0E+0) # Offset added to the initial averaged position # Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is # deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an - # alternate Z-controller setpoint is enabled. - z_offset: + # alternate Z-controller setpoint is enabled. + z_offset(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/sweep_control/bias_spectroscopy/z_offset # Settling time(NXbias) (s) (e.g. 2.1E-3) Time to wait after changing the bias to the next # level and before starting to acquire data. Adjust this parameter to avoid transient # effect induced by the bias change. Integration time: time during which the data are # acquired and averaged. - settling_time: + settling_time(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/sweep_control/bias_spectroscopy/settling_time # Z-Ctrl hold(NXpositioner) (e.g. TRUE) # When selected, the Z-Controller is set to hold # during the pulse. This means that the controller doesn't control the Z position during the pulse. - z_control_hold: + z_control_hold(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/sweep_control/bias_spectroscopy/z_ccontroller_hold # Final Z(NXpositioner) (m) (e.g. N/A) - final_z: - # Start time(NXlog) (e.g.23.11.2022 18:55:16) # Timestamp of the moment when the acquisition starts by pressing the Start button. - start_time: - # Bias Spectroscopy>1st Settling time(NXbias) (s) (e.g.2.1E-3) # See the "Settling time (s)" below. - 1st_settling_time: + final_z(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/sweep_control/bias_spectroscopy/record_final_z + # Start time(NXlog) (e.g.23.11.2022 18:55:16) # Timestamp of the moment + # when the acquisition starts by pressing the Start button. + # TODO: no available concept is found for the below link + # start_time(link): + # exists: optional + # target: none + # Bias Spectroscopy>1st Settling time(NXbias) (s) (e.g.2.1E-3) # See the "Settling time (s)" below. + 1st_settling_time(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/sweep_control/bias_spectroscopy/first_settling_time # Bias Spectroscopy>Integration time(NXbias) (s) (e.g.150E-6) # Time during which the data # are acquired and averaged. - integration_time: + integration_time(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/sweep_control/bias_spectroscopy/integration_time # Bias Spectroscopy>End Settling time(NXbias) (s) (e.g.4E-3) # Time to wait after the sweep has finished and the bias is ramped to the initial value. - end_settling_time: + end_settling_time(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/sweep_control/bias_spectroscopy/end_settling_time # Bias Spectroscopy>Z control time(NXbias) (s) (e.g.200E-3) # Time during which the # Z-Controller is enabled once a sweep has finished. When averaging multiple sweeps # (i.e. Sweeps>1), the Z-Controller is enabled for this duration between each sweep. # After the last sweep, it will wait the specified time before continuing a running scan. # This ensures each sweep reliably starts from the same position. This parameter is # disabled when Z-Controller to Hold is deselected in the Advanced section. - z_contro_time: + z_control_time(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/sweep_control/bias_spectroscopy/z_control_time # Bias Spectroscopy>Max Slew rate(NXbias) (V/s) (e.g.1E+0) # Maximum rate at which # the bias changes (before, during and after sweeping). - max_slew_rate: + max_slew_rate(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/sweep_control/bias_spectroscopy/max_slew_rate # Bias Spectroscopy>backward sweep(NXbias) (e.g.TRUE) # Select whether to measure # the backward (return) sweep or the forward only. - backward_sweep: + backward_sweep(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/sweep_control/bias_spectroscopy/backward_sweep # Z-Controller>Controller name(NXpositioner) (e.g.log Current) # Controller name. # This name which will be displayed at places where you can select a controller. - z_control_name: + z_control_name(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/position/z_controller/controller_name # Z-Controller>Controller status(NXpositioner) (e.g.OFF) # ON/OFF - z_control_status: + z_control_status(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/position/z_controller/controller_status # Z-Controller>Setpoint(NXpositioner) (e.g.50E-12) # Set Point is the desired value # of the control signal. It can be set by editing the number or using the slider bar. # Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. # Z-Controller>Setpoint unit(NXpositioner) (e.g.A) # Angstrom - z_sontrol_setpoint: + z_control_setpoint(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/position/z_controller/set_point # Z-Controller>P gain(NXpid) (e.g.6E-12) # The Type switches controller parameters # between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). # The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). # The integral gain and time constant are related as follows: I = P/T. - z_control_p_gain: + z_control_p_gain(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/position/z_controller/p_gain # Z-Controller>I gain(NXpid) (e.g.39.8241E-9) # See "Z-Controller>P gain" below. - z_control_i_gain: + z_control_i_gain(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/position/z_controller/i_gain # Z-Controller>Time const(NXpid) (s) (e.g.150.662E-6) # See "Z-Controller>P gain" below. - z_control_time_const: + z_control_time_const(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/position/z_controller/time_const # Z-Controller>TipLift(NXpositioner) (m) (e.g.0E+0) # Lifts the tip by the specified # amount when then controller is switched off. This can be a positive or a negative number, # i.e. the tip can also be moved towards the sample. Be careful with sign and value when # using this feature. - z_control_tip_lift: + z_control_tip_lift(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/position/z_controller/tip_lift # Z-Controller>Switch off delay(NXpositioner) (s) (e.g.0E+0) # Use this parameter for # a reproducible position when switching off the Z-controller. When >0 and the Z-controller # is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. - z_control_switchoff_delay: + z_control_switchoff_delay(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/position/z_controller/switchoff_delay # TODO: discuss convertion data to DATA (NXdata): doc: | From 94286692d887eeca9cc8c48b0cf89137a22d296e Mon Sep 17 00:00:00 2001 From: Rubel Date: Mon, 26 Jun 2023 16:01:51 +0200 Subject: [PATCH 0159/1012] Some correction on iv_sweep2 app. --- contributed_definitions/NXiv_sweep2.nxdl.xml | 33 ++++++++++--------- .../nyaml/NXiv_sweep2.yaml | 19 ++++++----- 2 files changed, 29 insertions(+), 23 deletions(-) diff --git a/contributed_definitions/NXiv_sweep2.nxdl.xml b/contributed_definitions/NXiv_sweep2.nxdl.xml index f668ea578c..40b1c2f95e 100644 --- a/contributed_definitions/NXiv_sweep2.nxdl.xml +++ b/contributed_definitions/NXiv_sweep2.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -48,7 +48,7 @@ CAP The data can be visualized in a tensor with:--> y has (NXsoftware_Scan_offset) z has (NXsoftware_Scan_offset) - + @@ -69,7 +69,8 @@ What is about [constant current mode, constand height mode]--> - The name of the output file, with the number of scans at the end.e.g. (e.g. 221122_Au_5K00014) + The name of the output file, with the number of scans at the end.e.g. (e.g. + 221122_Au_5K00014) @@ -93,7 +94,6 @@ What is about [constant current mode, constand height mode]--> - Hardware type used in SPM experiment, includes hardware manufacturers and type. (e.g. Nanonis BP5e) @@ -295,14 +295,12 @@ doc: The rate at which the one of the signal changes when ramping to the startin - + Describes an environment setup for a temperature-dependent IV measurement experiment. The temperature and voltage must be present as independently scanned controllers and the current sensor must also be present with its readings. - - @@ -345,7 +343,10 @@ doc: The rate at which the one of the signal changes when ramping to the startin - + @@ -491,8 +492,9 @@ doc: The rate at which the one of the signal changes when ramping to the startin - +As all of the bellow are linked +should be NXcollection not NXprocess--> + @@ -518,10 +520,10 @@ position is recorded and averaged before and after the sweep (the latter only if final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset).--> - + - + - - +are acquired and averaged. + integration_time(link): + target: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/sweep_control/bias_spectroscopy/integration_time +Bias Spectroscopy>End Settling time(NXbias) (s) (e.g.4E-3) # Time to wait after the sweep has finished and the bias is ramped to the initial value.--> - - - - - - - + + + + + + + + diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index df9d3ab660..78c89be52f 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -571,15 +571,15 @@ NXiv_sweep2(NXsensor_scan): # x # y # z - # single point default plot # current(I) vs bias(V) - single_point(NXdata): - exists: optional - # line scan default plot # multi I vs. V curves - line_scan(NXdata): - exists: optional - # alternative plot # current(I) curve in the 2D space of (position(x), bias(V)) - alternative_plot(NXdata): - exists: optional - # mesh scan default plot # 2D slices of the above alternative plot - mesh_scan(NXdata): - exists: optional + # single point default plot # current(I) vs bias(V) + single_point(NXdata): + exists: optional + # line scan default plot # multi I vs. V curves + line_scan(NXdata): + exists: optional + # alternative plot # current(I) curve in the 2D space of (position(x), bias(V)) + alternative_plot(NXdata): + exists: optional + # mesh scan default plot # 2D slices of the above alternative plot + mesh_scan(NXdata): + exists: optional From 0f5b3b51c7e50c52934c686b9df96e918a201348 Mon Sep 17 00:00:00 2001 From: Rubel Date: Wed, 28 Jun 2023 12:15:18 +0200 Subject: [PATCH 0161/1012] Extending harware and woftware versions. --- contributed_definitions/NXiv_sweep2.nxdl.xml | 13 +++++++++---- contributed_definitions/nyaml/NXiv_sweep2.yaml | 8 ++++++-- 2 files changed, 15 insertions(+), 6 deletions(-) diff --git a/contributed_definitions/NXiv_sweep2.nxdl.xml b/contributed_definitions/NXiv_sweep2.nxdl.xml index 0dbc1afa37..5243f9ed1c 100644 --- a/contributed_definitions/NXiv_sweep2.nxdl.xml +++ b/contributed_definitions/NXiv_sweep2.nxdl.xml @@ -93,23 +93,28 @@ What is about [constant current mode, constand height mode]--> - + Hardware type used in SPM experiment, includes hardware manufacturers and type. (e.g. Nanonis BP5e) - + Type of software used in SPM experiments, e.g. software version serial number, UI and RT probe release method. (e.g. SW Version Generic 5e -- SoftwareMain>UI Release 10771 -- SoftwareMain>RT Release 10771) # hardware: Current amplifier> hardware: CreaTec GmbH + + + + Version of the software. + + - diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index 78c89be52f..f4888a048e 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -51,17 +51,21 @@ NXiv_sweep2(NXsensor_scan): output file. (e.g. Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, locked Au(111), 50pA, 100 mV set point, 1mV DCA, 973Hz,138 1st H, -84 2nd H) (NXinstrument): - hardware(NXfabrication): + HARDWARE(NXfabrication): exists: optional doc: Hardware type used in SPM experiment, includes hardware manufacturers and type. (e.g. Nanonis BP5e) # any or specifique 'harware' and 'software'? - software(NXfabrication): + SOFTWARE(NXfabrication): exists: optional doc: | Type of software used in SPM experiments, e.g. software version serial number, UI and RT probe release method. (e.g. SW Version Generic 5e -- SoftwareMain>UI Release 10771 -- SoftwareMain>RT Release 10771) # hardware: Current amplifier> hardware: CreaTec GmbH + version: + exists: required + doc: | + Version of the software. # amplification: Current amplifier> factor (V/V): 1E-10 # crosstalk_compensation: Current amplifier> Capacitive cross-talk compensation: Yes/No current_amplifier(NXamplifier): From 74c62dd50338677a79254022486954f61ac99819 Mon Sep 17 00:00:00 2001 From: Yichen Date: Wed, 28 Jun 2023 18:27:47 +0200 Subject: [PATCH 0162/1012] This a test comm --- contributed_definitions/nyaml/NXiv_sweep2.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index f4888a048e..0b498d3c6f 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -264,7 +264,9 @@ NXiv_sweep2(NXsensor_scan): z_controller(NXcollection): z: unit: NX_LENGTH - doc: Indicate the tip position Z between tip and sample. The tip position can also be varied when the controller is not running. (e.g. 130.5E-9) + doc: | + Indicate the tip position Z between tip and sample. The tip position can also be varied when + the controller is not running. (e.g. 130.5E-9) # TODO: Is if this are uncomment than getting error. # voltage_controller(NXsensor): # temperature_controller(NXsensor): From d0ef7522a9a181d35332a4e83414aa6da2a6a8df Mon Sep 17 00:00:00 2001 From: Rubel Date: Wed, 28 Jun 2023 18:40:59 +0200 Subject: [PATCH 0163/1012] Cleaning the app def in NXiv_sweep2 and NX_iv_bias. --- contributed_definitions/NXiv_bias.nxdl.xml | 13 ++++-- contributed_definitions/NXiv_sweep2.nxdl.xml | 38 +++++++++++------- contributed_definitions/nyaml/NXiv_bias.yaml | 11 ++++- .../nyaml/NXiv_sweep2.yaml | 40 ++++++++++++------- 4 files changed, 68 insertions(+), 34 deletions(-) diff --git a/contributed_definitions/NXiv_bias.nxdl.xml b/contributed_definitions/NXiv_bias.nxdl.xml index 8861ca48c2..d0e54c7853 100644 --- a/contributed_definitions/NXiv_bias.nxdl.xml +++ b/contributed_definitions/NXiv_bias.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -32,8 +32,8 @@ - The ratio between the tunneling current at the sample surface and the bias - voltage applied between between the sample and the tip. + The ratio between the tunneling current at the sample surface and the bias voltage + applied between between the sample and the tip. @@ -64,7 +64,12 @@ - When selected, the Bias voltage returns to the initial value (before starting the sweep) at the end of the spectroscopy measurement (default). When not selected, Bias remains at the last value of the sweep. This is useful e.g. when combining several sweep segments. Example for an automated measurement (using Programming Interface): switch off Z-Controller, start spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, switch on Z-Controller. + When selected, the Bias voltage returns to the initial value (before starting the sweep) at + the end of the spectroscopy measurement (default). When not selected, Bias remains at the + last value of the sweep. This is useful e.g. when combining several sweep segments. Example + for an automated measurement (using Programming Interface): switch off Z-Controller, start + spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, + switch on Z-Controller. diff --git a/contributed_definitions/NXiv_sweep2.nxdl.xml b/contributed_definitions/NXiv_sweep2.nxdl.xml index 5243f9ed1c..37165d6028 100644 --- a/contributed_definitions/NXiv_sweep2.nxdl.xml +++ b/contributed_definitions/NXiv_sweep2.nxdl.xml @@ -26,18 +26,15 @@ CAP The data can be visualized in a tensor with:--> - Application definition for temperature-dependent IV curve measurements, - NOTE_: What is CAP + Application definition for temperature-dependent IV curve measurements, NOTE_: What is CAP #CAP with a focus on bias spectroscopy in scanning tunneling microscopy. - In this application definition, times should be specified always together - with an UTC offset. + In this application definition, times should be specified always together with an UTC offset. This is the application definition describing temperature (T) dependent current voltage (IV) curve - measurements. For this a temperature is set. After reaching the temperature, - a voltage sweep is performed. For each voltage a current is measured. + measurements. For this a temperature is set. After reaching the temperature, a voltage sweep + is performed. For each voltage a current is measured. Then, the next desired temperature is set and an IV measurement is performed. - NOTE_ : The text below is not comprehensive Should they be in symbol #CAP the X, Y, Z, position of the probes or tip can be defined. #CAP The data can be visualized in a tensor with: I (NXsensor_C, NXsoftware_Read_offset, NXcircuit) @@ -73,7 +70,7 @@ What is about [constant current mode, constand height mode]--> 221122_Au_5K00014) - + The name of the series output file, which represents only the public part of the output file. (e.g. 221122_Au_5K) @@ -195,6 +192,8 @@ run: Applied a voltage between tip and sample. + + - Duration over which the Z position is recorded and averaged before and after the - sweep (the latter only if Record final Z position is selected in the Advanced - section). After the initial Z averaging time, if Z-Controller to Hold is - selected in the Advanced section, the Z-Controller is set to hold and the tip is - placed at the previously averaged Z position (plus Z offset). (e.g. 100E-3) + Duration over which the Z position is recorded and averaged before and after the + sweep (the latter only if Record final Z position is selected in the Advanced + section). After the initial Z averaging time, if Z-Controller to Hold is selected + in the Advanced section, the Z-Controller is set to hold and the tip is placed at + the previously averaged Z position (plus Z offset). (e.g. 100E-3) @@ -452,7 +451,8 @@ parameters for a measurement at a single location during the scan--> - Also clarify the frame for the ROI of the scan (should depend on the lab frame) + Also clarify the frame for the ROI of the scan (should depend on the lab frame). + Note_: Need to be reconfirmed?? @@ -652,6 +652,16 @@ a reproducible position when switching off the Z-controller. When >0 and the Z-c is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position.--> + + + To describe sample and other constaints that applied on sample. + + + + At this moment no base class available that can track entire sample preparation. + + + diff --git a/contributed_definitions/nyaml/NXiv_bias.yaml b/contributed_definitions/nyaml/NXiv_bias.yaml index 4bd1bd56be..57636f879a 100644 --- a/contributed_definitions/nyaml/NXiv_bias.yaml +++ b/contributed_definitions/nyaml/NXiv_bias.yaml @@ -6,7 +6,9 @@ NXiv_bias(NXobject): doc: Applied a voltage between tip and sample. unit: NX_VOLTAGE tunneling_resistor(NX_NUMBER): - doc: The ratio between the tunneling current at the sample surface and the bias voltage applied between between the sample and the tip. + doc: | + The ratio between the tunneling current at the sample surface and the bias voltage + applied between between the sample and the tip. unit: NX_ANY calibration(NX_NUMBER): doc: Calibration of the Bias output (V/V). @@ -22,7 +24,12 @@ NXiv_bias(NXobject): doc: Select the channels to record. reset_bias(NX_BOOLEAN): doc: | - When selected, the Bias voltage returns to the initial value (before starting the sweep) at the end of the spectroscopy measurement (default). When not selected, Bias remains at the last value of the sweep. This is useful e.g. when combining several sweep segments. Example for an automated measurement (using Programming Interface): switch off Z-Controller, start spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, switch on Z-Controller. + When selected, the Bias voltage returns to the initial value (before starting the sweep) at + the end of the spectroscopy measurement (default). When not selected, Bias remains at the + last value of the sweep. This is useful e.g. when combining several sweep segments. Example + for an automated measurement (using Programming Interface): switch off Z-Controller, start + spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, + switch on Z-Controller. record_final_z(NX_BOOLEAN): doc: Select whether to record the Z position during Z averaging time at the end of the sweep (after Z control time) and store the average value in the header of the file when saving. Using this option increases the sweep time by Z averaging time. lock_in_run(NX_BOOLEAN): diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index 0b498d3c6f..a17a67f282 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -1,16 +1,13 @@ doc: | - Application definition for temperature-dependent IV curve measurements, - NOTE_: What is CAP + Application definition for temperature-dependent IV curve measurements, NOTE_: What is CAP #CAP with a focus on bias spectroscopy in scanning tunneling microscopy. - In this application definition, times should be specified always together - with an UTC offset. + In this application definition, times should be specified always together with an UTC offset. This is the application definition describing temperature (T) dependent current voltage (IV) curve - measurements. For this a temperature is set. After reaching the temperature, - a voltage sweep is performed. For each voltage a current is measured. + measurements. For this a temperature is set. After reaching the temperature, a voltage sweep + is performed. For each voltage a current is measured. Then, the next desired temperature is set and an IV measurement is performed. - NOTE_ : The text below is not comprehensive Should they be in symbol #CAP the X, Y, Z, position of the probes or tip can be defined. #CAP The data can be visualized in a tensor with: I (NXsensor_C, NXsoftware_Read_offset, NXcircuit) @@ -37,7 +34,7 @@ NXiv_sweep2(NXsensor_scan): exists: optional doc: | The name of the output file, with the number of scans at the end.e.g. (e.g. 221122_Au_5K00014) - collection_dentifier: + collection_identifier: doc: The name of the series output file, which represents only the public part of the output file. (e.g. 221122_Au_5K) experiment_identifier: exists: optional @@ -115,21 +112,21 @@ NXiv_sweep2(NXsensor_scan): # (phi) is displayed with respect to the reference phase. # Lock-in>Reference phase D2 (deg) -83.6562E+0 # See below. # items below should go to bias/spectroscopy/...!!! - #recorded_channels: + # recorded_channels: # doc: Select the channels to record. (e.g. Current (A);LI Demod 2 X (A);LI Demod 2 Y (A); # LI Demod 1 X (A);LI Demod 1 Y (A) # Select the channels to record.) - #bias_reset: + # bias_reset: # doc: When selected, the Bias voltage returns to the initial value (before starting the # sweep) at the end of the spectroscopy measurement (default). When not selected, Bias # remains at the last value of the sweep. This is useful e.g. when combining several # sweep segments. Example for an automated measurement (using Programming Interface): # switch off Z-Controller, start spectroscopy sweep segments (only fwd sweep, no reset # bias), set bias back to initial value, switch on Z-Controller. (e.g. TRUE) - #record_final_z: + # record_final_z: # doc: Select whether to record the Z position during Z averaging time at the end of the # sweep (after Z control time) and store the average value in the header of the file # when saving. Using this option increases the sweep time by Z averaging time. (e.g. FALSE) - #run: + # run: # doc: Bias Spectroscopy>Lock-In run FALSE # Select whether to set the Lock-In to run # during the measurement. When using this feature, make sure the Lock-In is configured # correctly and settling times are set to twice the Lock-In period at least. This @@ -140,6 +137,9 @@ NXiv_sweep2(NXsensor_scan): bias(NX_NUMBER): unit: NX_VOLTAGE doc: Applied a voltage between tip and sample. + bias_calibration(NX_NUMBER): + bias_offset: + unit: NX_VOLTAGE # sample_bias(NXbias): # Tip bias/Sample bias If the spectroscopy V bias is applied to the # Modulated signal Bias (V) 1E-3 Applied modulation to the bias voltage. @@ -288,7 +288,12 @@ NXiv_sweep2(NXsensor_scan): doc: Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. (e.g. 4096) z_avg_time(NX_NUMBER): unit: NX_TIME - doc: Duration over which the Z position is recorded and averaged before and after the sweep (the latter only if Record final Z position is selected in the Advanced section). After the initial Z averaging time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is set to hold and the tip is placed at the previously averaged Z position (plus Z offset). (e.g. 100E-3) + doc: | + Duration over which the Z position is recorded and averaged before and after the + sweep (the latter only if Record final Z position is selected in the Advanced + section). After the initial Z averaging time, if Z-Controller to Hold is selected + in the Advanced section, the Z-Controller is set to hold and the tip is placed at + the previously averaged Z position (plus Z offset). (e.g. 100E-3) circuit(NXcollection): rt_frequency(NX_NUMBER): unit: NX_FREQENCY @@ -323,7 +328,8 @@ NXiv_sweep2(NXsensor_scan): exists: optional roi(NXtransformations): frame: - doc: Also clarify the frame for the ROI of the scan (should depend on the lab frame) + doc: | + Also clarify the frame for the ROI of the scan (should depend on the lab frame). Note_: Need to be reconfirmed?? circuit(NXcollection): channels_current: doc: The scan channels are selected by users. (e.g. (A);Bias (V);Z (m);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A)) @@ -535,6 +541,12 @@ NXiv_sweep2(NXsensor_scan): # is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. z_control_switchoff_delay(link): target: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/position/z_controller/switchoff_delay + sample(NXsample): + doc: + To describe sample and other constaints that applied on sample. + sample_prep_descripton: + doc: | + At this moment no base class available that can track entire sample preparation. # TODO: discuss convertion data to DATA (NXdata): doc: | From c1bdfee2f107058da175efbda42737c70df0494d Mon Sep 17 00:00:00 2001 From: Yichen Date: Wed, 5 Jul 2023 18:44:23 +0200 Subject: [PATCH 0164/1012] Modify the format of description --- .../nyaml/NXiv_sweep2.yaml | 34 ++++++++++++++----- 1 file changed, 26 insertions(+), 8 deletions(-) diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index a17a67f282..0bb28ed2f3 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -265,8 +265,8 @@ NXiv_sweep2(NXsensor_scan): z: unit: NX_LENGTH doc: | - Indicate the tip position Z between tip and sample. The tip position can also be varied when - the controller is not running. (e.g. 130.5E-9) + Indicate the tip position Z between tip and sample. The tip position can also + be varied when the controller is not running. (e.g. 130.5E-9) # TODO: Is if this are uncomment than getting error. # voltage_controller(NXsensor): # temperature_controller(NXsensor): @@ -285,7 +285,8 @@ NXiv_sweep2(NXsensor_scan): unit: NX_VOLTAGE doc: The last bias values of the sweep. (e.g. 300E-3) num_pixel(NX_NUMBER): - doc: Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. (e.g. 4096) + doc: Define the sweep number of points, that is, the maximum spectrum + resolution eq. Bias window divide by Num Pixel. (e.g. 4096) z_avg_time(NX_NUMBER): unit: NX_TIME doc: | @@ -311,18 +312,34 @@ NXiv_sweep2(NXsensor_scan): acquisition_period(NX_NUMBER): unit: NX_TIME exists: optional - doc: Update rate for several processes like History Graph, Auto-Approach, and for many Programming Interface functions. This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples of this value. They can be set to different values, but the actual timing value will be coerced to a multiple of the Acquisition Period. (e.g. 20E-3) + doc: Update rate for several processes like History Graph, Auto-Approach, + and for many Programming Interface functions. This is usually set to 20 ms. + All additional timings (7-9) can only be integer multiples of this value. + They can be set to different values, but the actual timing value will be + coerced to a multiple of the Acquisition Period. (e.g. 20E-3) animations_period(NX_NUMBER): unit: NX_TIME exists: optional - doc: Update rate of animated graphical indicators. These are e.g. some graphs & sliders. A reasonable value is 40 ms (25 updates per second). Increase this period to reduce the processor load for the graphical user interface, especially on slow computers. This value is purely a user interface update rate and does not affect measurements in any way. (e.g. 20E-3) + doc: Update rate of animated graphical indicators. These are e.g. some + graphs & sliders. A reasonable value is 40 ms (25 updates per second). + Increase this period to reduce the processor load for the graphical + user interface, especially on slow computers. This value is purely a user + interface update rate and does not affect measurements in any way. (e.g. 20E-3) indicators_period(NX_NUMBER): unit: NX_TIME - doc: Update rate of digital indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a user interface update rate and does not affect measurements in any way. (e.g. 300E-3) + doc: Update rate of digital indicators, e.g. the numbers displayed besides each slider. + Here, 3 updates per second, or 300 ms is enough. This value is purely a user + interface update rate and does not affect measurements in any way. (e.g. 300E-3) measurements_period(NX_NUMBER): exists: optional unit: NX_TIME - doc: The Measurements period is the integration time for precise measurements (averaging over specified period), mostly used in sweep modules. Examples are recording of a force-distance curve or a resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. (e.g. 500E-3) + doc: The Measurements period is the integration time for precise measurements + (averaging over specified period), mostly used in sweep modules. Examples are recording + of a force-distance curve or a resonance of a cantilever. For fast measurements with small + steps, a value of 40 ms may be reasonable. For normal use, 300-500 ms is a good value, + but for recording a resonance of a high-Q cantilever, values of several seconds might be + necessary. Usually this parameter doesn’t need to be set from this module; the sweep + modules will set this value according to the sweep timings. (e.g. 500E-3) # parameters how to change the location from measurement to measurement during the scan scan_control(NXcollection): exists: optional @@ -332,7 +349,8 @@ NXiv_sweep2(NXsensor_scan): Also clarify the frame for the ROI of the scan (should depend on the lab frame). Note_: Need to be reconfirmed?? circuit(NXcollection): channels_current: - doc: The scan channels are selected by users. (e.g. (A);Bias (V);Z (m);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A)) + doc: The scan channels are selected by users. + (e.g. (A);Bias (V);Z (m);LI Demod 2 X (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A)) positioner(NXcollection): scanfield(NX_NUMBER): doc: Configure the scan frame like x position; y position; width; height. (e.g. 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0) From b30f0dfdc273cbddc7b6409e71e0827773fcf1cd Mon Sep 17 00:00:00 2001 From: Rubel Date: Thu, 13 Jul 2023 09:49:34 +0200 Subject: [PATCH 0165/1012] Removing optional from NXentry. --- contributed_definitions/nyaml/NXiv_sweep2.yaml | 1 - 1 file changed, 1 deletion(-) diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index 0bb28ed2f3..66ed9ffc82 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -20,7 +20,6 @@ doc: | category: application NXiv_sweep2(NXsensor_scan): (NXentry): - exists: optional definition: enumeration: [NXiv_sweep2] type: From 006c3084498a9888d64ccef6dabe4c13e50cae05 Mon Sep 17 00:00:00 2001 From: Rubel Date: Thu, 13 Jul 2023 21:35:02 +0200 Subject: [PATCH 0166/1012] Removing errors for app def. --- contributed_definitions/NXcircuit.nxdl.xml | 4 +- contributed_definitions/NXiv_sweep2.nxdl.xml | 16 +- contributed_definitions/NXlockin.nxdl.xml | 5 +- contributed_definitions/NXpositioner.nxdl.xml | 167 +++++++++++++---- contributed_definitions/NXsensor.nxdl.xml | 38 ++-- contributed_definitions/nyaml/NXcircuit.yaml | 2 +- .../nyaml/NXiv_sweep2.yaml | 12 +- .../nyaml/NXpositioner.yaml | 174 +++++++++++------- contributed_definitions/nyaml/NXsensor.yaml | 7 +- 9 files changed, 284 insertions(+), 141 deletions(-) diff --git a/contributed_definitions/NXcircuit.nxdl.xml b/contributed_definitions/NXcircuit.nxdl.xml index 150a78abe0..ede8976178 100644 --- a/contributed_definitions/NXcircuit.nxdl.xml +++ b/contributed_definitions/NXcircuit.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -25,7 +25,7 @@ Application definition for circuit devices. - + Hardware type used in circuit, includes hardware manufacturers and type diff --git a/contributed_definitions/NXiv_sweep2.nxdl.xml b/contributed_definitions/NXiv_sweep2.nxdl.xml index 37165d6028..49b6bcbbe2 100644 --- a/contributed_definitions/NXiv_sweep2.nxdl.xml +++ b/contributed_definitions/NXiv_sweep2.nxdl.xml @@ -143,7 +143,7 @@ their cut-off frequencies. modulation_amplitude: amplitude: Lock-in>Amplitude 2E-3 # Sets the amplitude (in physical units of the modulated signal) of the sine modulation.--> - + @@ -311,13 +311,15 @@ doc: The rate at which the one of the signal changes when ramping to the startin This is set-point of tip current. - + Value of calibration that comes as A/V. - + + + @@ -341,8 +343,8 @@ doc: The rate at which the one of the signal changes when ramping to the startin - Indicate the tip position Z between tip and sample. The tip position can also be - varied when the controller is not running. (e.g. 130.5E-9) + Indicate the tip position Z between tip and sample. The tip position can also + be varied when the controller is not running. (e.g. 130.5E-9) @@ -390,7 +392,7 @@ parameters for a measurement at a single location during the scan--> - + The bandwitdh of the Hardware and/or Software which is insturment specific. For example: Nanonis Generic 5 has 'RT Frequency' 20E-3. @@ -652,7 +654,7 @@ a reproducible position when switching off the Z-controller. When >0 and the Z-c is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position.--> - + To describe sample and other constaints that applied on sample. diff --git a/contributed_definitions/NXlockin.nxdl.xml b/contributed_definitions/NXlockin.nxdl.xml index ddf2e8a054..2484b5007c 100644 --- a/contributed_definitions/NXlockin.nxdl.xml +++ b/contributed_definitions/NXlockin.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -56,7 +56,8 @@ be detected and analysed by instruments such as lock-in amplifiers. - + + Sets the amplitude (in physical units of the modulated signal) of the sine modulation. diff --git a/contributed_definitions/NXpositioner.nxdl.xml b/contributed_definitions/NXpositioner.nxdl.xml index 094f5611b0..3ba50f6ab0 100644 --- a/contributed_definitions/NXpositioner.nxdl.xml +++ b/contributed_definitions/NXpositioner.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -94,14 +94,14 @@ - .. index':'':' plotting + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + to a :ref:`NXdata` group. It is recommended (as of NIAC2014) to use this attribute to help define the path to the default dataset to be plotted. - See https':'//www.nexusformat.org/2014_How_to_find_default_data.html + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. @@ -114,7 +114,7 @@ string "." if located in the origin. Usually these operations are stored in a NXtransformations group. But NeXus allows them to be stored anywhere. - .. todo':'':' + .. todo:: Add a definition for the reference point of a positioner. @@ -126,15 +126,19 @@ other component groups. - + - To clarify the frame laboratory frame. The scanning area in x, y, and z position - in the frame. + To clarify the frame laboratory frame. The scanning area in x, y, and z position in the + frame. - + + + This controllers task is to continuously adjust the Z position of the stm tip in order + to keep the selected control signal as close as possible to the Set Point. Different control + signals lead to different contronller beahvior. + + Offset added to the initial averaged position Zaver before starting to swepp. @@ -142,65 +146,59 @@ - Indicate the tip position Z between tip and sample. The tip position can also be - varied when the controller is not running. + Indicate the tip position Z between tip and sample. The tip position can also be varied when + the controller is not running. - Controller name. This name which will be displayed at places where you can - select a controller. + Controller name. This name which will be displayed at places where you can select a + controller. - + - Set Point is the desired value of the control signal. It can be set by editing - the number or using the slider bar. Click the "Set" button above the input field - to use the actual value as Set Point. The slider shows the Set Point as well as - the current value. + Set Point is the desired value of the control signal. It can be set by editing the number + or using the slider bar. Click the "Set" button above the input field to use the actual + value as Set Point. The slider shows the Set Point as well as the current value. - - Lifts the tip by the specified amount when then controller is switched off. This - can be a positive or a negative number, i.e. the tip can also be moved towards - the sample. Be careful with sign and value when using this feature. + Lifts the tip by the specified amount when then controller is switched off. This can be + a positive or a negative number, i.e. the tip can also be moved towards the sample. Be + careful with sign and value when using this feature. - Use this parameter for a reproducible position when switching off the - Z-controller. When >0 and the Z-controller is switched off, it doesn't switch - off immediately but continues to run for the specified time and averages the Z - position. + Use this parameter for a reproducible position when switching off the Z-controller. + When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues + to run for the specified time and averages the Z position. - (In bias spectroscopy) Select whether to set the Z-Controller on hold (i.e. - disabled) during the sweep. It is selected by default. When deselected, Z-offset - and Z control time parameters are disabled. + (In bias spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) during + the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters + are disabled. - The final z-position during the bias spectroscopy scan. The availability of - values is related to the mode of scanning. + The final z-position during the bias spectroscopy scan. The availability of values is + related to the mode of scanning. - - - To contron the tip and various scan operations. - - + Configure the scan frame like x position; y position; width; height. - + Scan resolution by setting the Lines equal to Pixels. @@ -220,4 +218,93 @@ doc: The unit of setpoint during the scanning.--> Define the scan backward speed in the forward direction. + + + Piezo calibration module is used to define the X Y Z piezos calibration. + + + + + The name of caliberation type. + + + + + + + The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T + (proportional gain/time constant). The formula for the controller in the frequency domain is: + G(s) = P + I/s = P(1 + 1/(Ts)). + The integral gain and time constant are related as follows: I = P/T. + + + + + The Type switches controller parameters between P/I (proportional gain/integral gain) and + P/T (proportional gain/time constant). The formula for the controller in the frequency + domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related + as follows: I = P/T. + + + + + The Type switches controller parameters between P/I (proportional gain/integral gain) and + P/T (proportional gain/time constant). The formula for the controller in the frequency + domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related + as follows: I = P/T. + + + + + + There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order + piezo characteristics to compensate for it. The following equation shows the interpretation + of the 2nd order correction parameter: For the X-piezo: + "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] + where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2) + + + + + There are 2 parameters in X and Y directions. Define the drift speed for all three axes. + When the compensation is on, the piezos will start to move at that speed. + + + + + Use the button to turn on/off the drift compensation. + + diff --git a/contributed_definitions/NXsensor.nxdl.xml b/contributed_definitions/NXsensor.nxdl.xml index f2d3b01227..b743141b23 100644 --- a/contributed_definitions/NXsensor.nxdl.xml +++ b/contributed_definitions/NXsensor.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -25,7 +25,7 @@ A sensor used to monitor an external condition - The condition itself is described in ':'ref':'`NXenvironment`. + The condition itself is described in :ref:`NXenvironment`. @@ -47,9 +47,10 @@ where sensor is attached to ("sample" | "can") - + - Defines the axes for logged vector quantities if they are not the global instrument axes. + Defines the axes for logged vector quantities if they are not the global + instrument axes. @@ -76,29 +77,29 @@ The type of hardware used for the measurement. - Examples (suggestions but not restrictions)':' + Examples (suggestions but not restrictions): - ':'Temperature':' + :Temperature: J | K | T | E | R | S | Pt100 | Pt1000 | Rh/Fe - ':'pH':' + :pH: Hg/Hg2Cl2 | Ag/AgCl | ISFET - ':'Ion selective electrode':' + :Ion selective electrode: specify species; e.g. Ca2+ - ':'Magnetic field':' + :Magnetic field: Hall - ':'Surface pressure':' + :Surface pressure: wilhelmy plate - + link to second amplifer circuit with 1MOhm - Is data collection controlled or synchronised to this quantity':' + Is data collection controlled or synchronised to this quantity: 1=no, 0=to "value", 1=to "value_deriv1", etc. @@ -177,14 +178,14 @@ - .. index':'':' plotting + .. index:: plotting Declares which child group contains a path leading - to a ':'ref':'`NXdata` group. + to a :ref:`NXdata` group. It is recommended (as of NIAC2014) to use this attribute to help define the path to the default dataset to be plotted. - See https':'//www.nexusformat.org/2014_How_to_find_default_data.html + See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. @@ -197,7 +198,7 @@ string "." if located in the origin. Usually these operations are stored in a NXtransformations group. But NeXus allows them to be stored anywhere. - .. todo':'':' + .. todo:: Add a definition for the reference point of a sensor. @@ -209,7 +210,6 @@ other component groups. - External sensors connected to the device. For example, T1, temperature of STM @@ -217,12 +217,12 @@ nitrogen shield. - + External sensors connected to the device. Pressure of each chamber or ion pump, such as prepare chamber and analysis chamber - + The power present in the signal as a function of frequency. Used to characterise diff --git a/contributed_definitions/nyaml/NXcircuit.yaml b/contributed_definitions/nyaml/NXcircuit.yaml index 8b24e76b9b..c235e9dd36 100644 --- a/contributed_definitions/nyaml/NXcircuit.yaml +++ b/contributed_definitions/nyaml/NXcircuit.yaml @@ -2,7 +2,7 @@ doc: | Application definition for circuit devices. category: base NXcircuit(NXobject): - hardware(NX_FABRICATION): + hardware(NXfabrication): doc: Hardware type used in circuit, includes hardware manufacturers and type tunneling_current(NX_NUMBER): doc: The tunneling current between tip and sample after application of bias voltage. diff --git a/contributed_definitions/nyaml/NXiv_sweep2.yaml b/contributed_definitions/nyaml/NXiv_sweep2.yaml index 66ed9ffc82..1fd2684870 100644 --- a/contributed_definitions/nyaml/NXiv_sweep2.yaml +++ b/contributed_definitions/nyaml/NXiv_sweep2.yaml @@ -20,6 +20,7 @@ doc: | category: application NXiv_sweep2(NXsensor_scan): (NXentry): + exists: optional definition: enumeration: [NXiv_sweep2] type: @@ -92,6 +93,7 @@ NXiv_sweep2(NXsensor_scan): # amplitude: Lock-in>Amplitude 2E-3 # Sets the amplitude (in physical units of the # modulated signal) of the sine modulation. demodulated_signal: + exists: optional #Lock-in>Demodulated signal Current (A) # This is the signal which # will be demodulated, in order to determine the amplitude and phase at the frequency # set in the Frequency field (“4”) or harmonics. @@ -242,10 +244,15 @@ NXiv_sweep2(NXsensor_scan): current_calibration: doc: | Value of calibration that comes as A/V. - unit: NX_NUMBER + unit: NX_CURRENT current_offset: unit: NX_CURRENT current_gain: + unit: NX_UNITLESS + calibration_time(NX_DATE_TIME): + exists: optional + value: + exists: optional position(NXpositioner): doc: Clarify the frame laboratory frame. x(NX_NUMBER): @@ -296,7 +303,7 @@ NXiv_sweep2(NXsensor_scan): the previously averaged Z position (plus Z offset). (e.g. 100E-3) circuit(NXcollection): rt_frequency(NX_NUMBER): - unit: NX_FREQENCY + unit: NX_FREQUENCY doc: | The bandwitdh of the Hardware and/or Software which is insturment specific. For example: Nanonis Generic 5 has 'RT Frequency' 20E-3. @@ -559,6 +566,7 @@ NXiv_sweep2(NXsensor_scan): z_control_switchoff_delay(link): target: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/position/z_controller/switchoff_delay sample(NXsample): + exists: optional doc: To describe sample and other constaints that applied on sample. sample_prep_descripton: diff --git a/contributed_definitions/nyaml/NXpositioner.yaml b/contributed_definitions/nyaml/NXpositioner.yaml index c285b7436e..44a7c0708e 100644 --- a/contributed_definitions/nyaml/NXpositioner.yaml +++ b/contributed_definitions/nyaml/NXpositioner.yaml @@ -86,45 +86,65 @@ NXpositioner(NXobject): the instrument. The dependency chain may however traverse similar groups in other component groups. - Position(NXtransformation): - doc: To clarify the frame laboratory frame. The scanning area in x, y, and z position in the frame. + position(NXtransformations): + doc: | + To clarify the frame laboratory frame. The scanning area in x, y, and z position in the + frame. unit: NX_LENGTH -#(Z_contronller): -# doc: | -# This controllers task is to continuously adjust the Z position of the stm tip in order to keep the selected control signal as close as possible to the Set Point. Different control signals lead to different contronller beahvior. + z_contronller(NX_NUMBER): + doc: | + This controllers task is to continuously adjust the Z position of the stm tip in order + to keep the selected control signal as close as possible to the Set Point. Different control + signals lead to different contronller beahvior. z_offset(NX_NUMBER): doc: Offset added to the initial averaged position Zaver before starting to swepp. unit: NX_LENGTH tip_position_z(NX_NUMBER): - doc: Indicate the tip position Z between tip and sample. The tip position can also be varied when the controller is not running. + doc: | + Indicate the tip position Z between tip and sample. The tip position can also be varied when + the controller is not running. unit: NX_LENGTH controller_name(NX_CHAR): - doc: Controller name. This name which will be displayed at places where you can select a controller. + doc: | + Controller name. This name which will be displayed at places where you can select a + controller. setpoint(NX_NUMBER): - doc: Set Point is the desired value of the control signal. It can be set by editing the number or using the slider bar. Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. - unit: NX_CUTTENT - #setpoint unit(NX_CHAR): - # doc: The unit of setpoint during the scanning. + doc: | + Set Point is the desired value of the control signal. It can be set by editing the number + or using the slider bar. Click the "Set" button above the input field to use the actual + value as Set Point. The slider shows the Set Point as well as the current value. + unit: NX_CURRENT tip_lift(NX_NUMBER): - doc: Lifts the tip by the specified amount when then controller is switched off. This can be a positive or a negative number, i.e. the tip can also be moved towards the sample. Be careful with sign and value when using this feature. + doc: | + Lifts the tip by the specified amount when then controller is switched off. This can be + a positive or a negative number, i.e. the tip can also be moved towards the sample. Be + careful with sign and value when using this feature. unit: NX_LENGTH switch_off_delay(NX_NUMBER): - doc: Use this parameter for a reproducible position when switching off the Z-controller. When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. + doc: | + Use this parameter for a reproducible position when switching off the Z-controller. + When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues + to run for the specified time and averages the Z position. unit: NX_TIME z-controller_hold(NX_BOOLEAN): - doc: (In bias spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. + doc: | + (In bias spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) during + the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters + are disabled. final_z(NX_NUMBER): - doc: The final z-position during the bias spectroscopy scan. The availability of values is related to the mode of scanning. - unit: NX_LENGTH - (Scan contronller): doc: | - To contron the tip and various scan operations. + The final z-position during the bias spectroscopy scan. The availability of values is + related to the mode of scanning. + unit: NX_LENGTH + # scan_control(NXcollection): + # doc: | + # To control the tip and various scan operations. scanfield(NX_NUMBER): doc: Configure the scan frame like x position; y position; width; height. unit: NX_LENGTH - pixels/line(NX_NUMBER): + pixels_line(NX_NUMBER): doc: Scan resolution by setting the Lines equal to Pixels. - unit: NX_ANY + unit: NX_COUNT lines(NX_NUMBER): doc: Define the image resolution. unit: NX_ANY @@ -133,54 +153,80 @@ NXpositioner(NXobject): unit: NX_ANY speed_backw.(NX_NUMBER): doc: Define the scan backward speed in the forward direction. - unit: NX_ANY(NX_SPEED?) - (Piezo_calibration): + unit: NX_ANY + piezo_calibration: doc: | Piezo calibration module is used to define the X Y Z piezos calibration. - Active Calib(NX_CHAR): + active_calib(NX_CHAR): doc: The name of caliberation type. - calibr(NX_NUMBER): + calib_N(NX_NUMBER): - Z_contronller: - name: - doc: | - This controllers task is to continuously adjust the Z position of the stm tip in order to keep the selected control signal as close as possible to the Set Point. Different contro; signals lead to different contronller beahvior. - Z_offset(NX_NUMBER): - doc: Offset added to the initial averaged position Zaver before starting to swepp. - unit: NX_LENGTH - Tip_position_Z(NX_NUMBER): - doc: Indicate the tip position Z between tip and sample. The tip position can also be varied when the controller is not running. - unit: NX_LENGTH - Controller name(NX_CHAR): - doc: Controller name. This name which will be displayed at places where you can select a controller. - Setpoint(NX_NUMBER): - doc: Set Point is the desired value of the control signal. It can be set by editing the number or using the slider bar. Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. - unit: NX_CUTTENT - Setpoint unit(NX_CHAR): - doc: The unit of setpoint during the scanning. - P gain(NX_NUMBER): - doc: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. - unit: NX_LENGTH - I gain(NX_NUMBER): - doc: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. - unit: NX_ANY (NX_SPEED?) - Time const(NX_NUMBER): - dos: The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows: I = P/T. - unit: NX_TIME - TipLift(NX_NUMBER): - doc: Lifts the tip by the specified amount when then controller is switched off. This can be a positive or a negative number, i.e. the tip can also be moved towards the sample. Be careful with sign and value when using this feature. - unit: NX_LENGTH - Switch off delay(NX_NUMBER): - doc: Use this parameter for a reproducible position when switching off the Z-controller. When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. - unit: NX_TIME - Z-controller hold(NX_CHAR): - doc: (In biase spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters are disabled. - Scan contronller: + # z_contronller(NXcollection): + # name: + # doc: | + # This controllers task is to continuously adjust the Z position of the stm tip in order to keep the selected control signal as close as possible to the Set Point. Different contro; signals lead to different contronller beahvior. + # z_offset(NX_NUMBER): + # doc: Offset added to the initial averaged position Zaver before starting to swepp. + # unit: NX_LENGTH + # tip_position_z(NX_NUMBER): + # doc: Indicate the tip position Z between tip and sample. The tip position can also be varied when the controller is not running. + # unit: NX_LENGTH + # controller_name: + # doc: Controller name. This name which will be displayed at places where you can select a controller. + # setpoint(NX_NUMBER): + # doc: Set Point is the desired value of the control signal. It can be set by editing the number or using the slider bar. Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. + # unit: NX_CUTTENT + # setpoint_unit: + # doc: The unit of setpoint during the scanning. + p_gain(NX_NUMBER): + doc: | + The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T + (proportional gain/time constant). The formula for the controller in the frequency domain is: + G(s) = P + I/s = P(1 + 1/(Ts)). + The integral gain and time constant are related as follows: I = P/T. + unit: NX_UNITLESS + i_gain(NX_NUMBER): doc: | - There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order piezo characteristics to compensate for it. The following equation shows the interpretation of the 2nd order correction parameter: For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2) + The Type switches controller parameters between P/I (proportional gain/integral gain) and + P/T (proportional gain/time constant). The formula for the controller in the frequency + domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related + as follows: I = P/T. + unit: NX_UNITLESS + time_const(NX_NUMBER): + doc: | + The Type switches controller parameters between P/I (proportional gain/integral gain) and + P/T (proportional gain/time constant). The formula for the controller in the frequency + domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related + as follows: I = P/T. + unit: NX_TIME + # tip_lift(NX_NUMBER): + # doc: | + # Lifts the tip by the specified amount when then controller is switched off. This + # can be a positive or a negative number, i.e. the tip can also be moved towards the sample. + # Be careful with sign and value when using this feature. + # unit: NX_LENGTH + # switch_off_delay(NX_NUMBER): + # doc: | + # Use this parameter for a reproducible position when switching off the Z-controller. + # When >0 and the Z-controller is switched off, it doesn't switch off immediately but + # continues to run for the specified time and averages the Z position. + # unit: NX_TIME + # z_controller_hold(NX_CHAR): + # doc: | + # (In biase spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) + # during the sweep. It is selected by default. When deselected, Z-offset and Z control time + # parameters are disabled. + scan_contronller(NX_NUMBER): + doc: | + There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order + piezo characteristics to compensate for it. The following equation shows the interpretation + of the 2nd order correction parameter: For the X-piezo: + "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] + where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2) drift(NX_NUMBER): - doc: There are 2 parameters in X and Y directions. Define the drift speed for all three axes. When the compensation is on, the piezos will start to move at that speed. - unit: NX_ANY (need NX_SPEED) - drift correction status(NX_CHAR): + doc: | + There are 2 parameters in X and Y directions. Define the drift speed for all three axes. + When the compensation is on, the piezos will start to move at that speed. + unit: NX_ANY + drift_correction_status(NX_CHAR): doc: Use the button to turn on/off the drift compensation. - diff --git a/contributed_definitions/nyaml/NXsensor.yaml b/contributed_definitions/nyaml/NXsensor.yaml index 6600a6c729..724e6366dc 100644 --- a/contributed_definitions/nyaml/NXsensor.yaml +++ b/contributed_definitions/nyaml/NXsensor.yaml @@ -42,7 +42,7 @@ NXsensor(NXobject): ':'Surface pressure':' wilhelmy plate amplifier(NXamplifier): - second_amplifier(NX_circuit): + second_amplifier(NXcircuit): doc: link to second amplifer circuit with 1MOhm run_control(NX_BOOLEAN): doc: | @@ -128,14 +128,13 @@ NXsensor(NXobject): and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups. - ############## temperature(NX_NUMBER): doc: External sensors connected to the device. For example, T1, temperature of STM head. T2, temperature of bottom of LHe helium cryostat. T3, temperature of LN2 nitrogen shield. unit: NX_TEMPERATURE - pressure(NX_BUMBER): + pressure(NX_NUMBER): doc: External sensors connected to the device. Pressure of each chamber or ion pump, such as prepare chamber and analysis chamber unit: NX_PRESSURE power_spectral_density (NX_NUMBER): doc: The power present in the signal as a function of frequency. Used to characterise the vibration and noise of scanning probes to detect and reduce the impact on resolution during STM imaging - + \ No newline at end of file From 044ecdde64a197508efae496858d379cdf39b395 Mon Sep 17 00:00:00 2001 From: Rubel Date: Sat, 15 Jul 2023 13:29:43 +0200 Subject: [PATCH 0167/1012] Updating some data type in NXiv_sweep2.yaml. --- contributed_definitions/NXiv_sweep2.nxdl.xml | 28 ++++++++----------- .../nyaml/NXiv_sweep2.yaml | 24 ++++++++-------- 2 files changed, 23 insertions(+), 29 deletions(-) diff --git a/contributed_definitions/NXiv_sweep2.nxdl.xml b/contributed_definitions/NXiv_sweep2.nxdl.xml index 49b6bcbbe2..8b230bb88d 100644 --- a/contributed_definitions/NXiv_sweep2.nxdl.xml +++ b/contributed_definitions/NXiv_sweep2.nxdl.xml @@ -90,14 +90,8 @@ What is about [constant current mode, constand height mode]--> - - - Hardware type used in SPM experiment, includes hardware manufacturers and type. - (e.g. Nanonis BP5e) - - - + Type of software used in SPM experiments, e.g. software version serial number, UI and RT probe release method. (e.g. SW Version Generic 5e -- SoftwareMain>UI Release 10771 @@ -143,7 +137,7 @@ their cut-off frequencies. modulation_amplitude: amplitude: Lock-in>Amplitude 2E-3 # Sets the amplitude (in physical units of the modulated signal) of the sine modulation.--> - + @@ -193,7 +187,7 @@ run: - + - +hardware: Lock-in Amplifier>Hardware: Nanonis--> + + + This is the signal on which the modulation (sine) will be added. + + + + + + + The frequency of the sine modulation added to the signal to modulate. The frequency + range is from 10 mHz to 40 kHz (corresponding to the SC5 output filter cut-off). When + working with harmonics, make sure the harmonic frequencies don’t exceed ~100 kHz + (SC5 input filter cut-off). Remember the SC5 hardware filters will affect the amplitude + when getting close to their cut-off frequencies. + + + + + + The amplitude (in physical units of modulated signal) of the sine modulation. + + + @@ -147,18 +157,27 @@ set in the Frequency field (“4”) or harmonics.--> bias, et.al. + + + + Order of the harmonic oscillation to detect on the demodulated signal (with respect + to the modulation frequency). If you work with higher harmonics make sure the + frequency does not exceed the analog signal bandwidth (100 kHz). + + + + + + Reference phase for the sine on the demodulated signal with respect to the + modulation signal. The determined phase (phi) is displayed with respect to the + reference phase. + + + - - - - + + - Application definition for temperature-dependent IV curve measurements, NOTE_: What is CAP - #CAP with a focus on bias spectroscopy in scanning tunneling microscopy. + Application definition for temperature-dependent IV curve measurements + #2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the + STM image mode in the future with a focus on bias spectroscopy in Scanning Tunneling Microscopy. - In this application definition, times should be specified always together with an UTC offset. + In this application definition, times should be specified always together with a UTC offset. This is the application definition describing temperature (T) dependent current voltage (IV) curve - measurements. For this a temperature is set. After reaching the temperature, a voltage sweep - is performed. For each voltage a current is measured. + measurements. For this, a temperature is set. After reaching the temperature, a voltage sweep + is performed. For each voltage, a current is measured. Then, the next desired temperature is set and an IV measurement is performed. - #CAP the X, Y, Z, position of the probes or tip can be defined. - #CAP The data can be visualized in a tensor with: - I (NXsensor_C, NXsoftware_Read_offset, NXcircuit) - parameters: - V has (NXsource+offset, NXsoftware_Scan_offset, NXsensor_V, NXcircuit) - T has (NXsource, NXsoftware_Scan_offset, NXsensor_T) - x has (NXsoftware_Scan_offset) - y has (NXsoftware_Scan_offset) - z has (NXsoftware_Scan_offset) + The data can be visualized in a tensor with: + I (NXsensor_C, NXsoftware_Read_offset, NXcircuit) + parameters: + V has (NXsource+offset, NXsoftware_Scan_offset, NXsensor_V, NXcircuit) + T has (NXsource, NXsoftware_Scan_offset, NXsensor_T) + x has (NXsoftware_Scan_offset) + y has (NXsoftware_Scan_offset) + z has (NXsoftware_Scan_offset) - + - + The equipments and techniques as well as the parameter settings and reference signals - are used during the experiments used in the scanning tunneling microscopy(STM). + are used during the experiments used in Scanning Tunneling Microscopy (STM). +What is about [constant current mode, constant height mode]--> @@ -66,7 +64,7 @@ What is about [constant current mode, constand height mode]--> - The name of the output file, with the number of scans at the end.e.g. (e.g. + The name of the output file, with the number of scans at the end. (e.g. 221122_Au_5K00014) @@ -90,15 +88,19 @@ What is about [constant current mode, constand height mode]--> - + + + Hardware type used in SPM experiment, includes hardware manufacturers and type. + (e.g. Nanonis BP5e) + + + - Type of software used in SPM experiments, e.g. software version serial number, UI and - RT probe release method. (e.g. SW Version Generic 5e -- SoftwareMain>UI Release 10771 - -- SoftwareMain>RT Release 10771) - # hardware: Current amplifier> hardware: CreaTec GmbH + Type of software used in SPM experiments, such as software version serial number, UI and + RT probe release method. (e.g. SW Version Generic 5e -- RT Release 10771) - Version of the software. @@ -117,7 +119,7 @@ crosstalk_compensation: Current amplifier> Capacitive cross-talk compensation: Y - Status of Lock-in device whether while ferfoming the experiment + Status of Lock-in device whether while performing the experiment - + This is the signal on which the modulation (sine) will be added. @@ -134,11 +136,12 @@ hardware: Lock-in Amplifier>Hardware: Nanonis--> - The frequency of the sine modulation added to the signal to modulate. The frequency - range is from 10 mHz to 40 kHz (corresponding to the SC5 output filter cut-off). When - working with harmonics, make sure the harmonic frequencies don’t exceed ~100 kHz - (SC5 input filter cut-off). Remember the SC5 hardware filters will affect the amplitude - when getting close to their cut-off frequencies. + The signal is modulated by adding the frequency of the sine modulation. The + modulation frequency spans can be from 10 mHz to 40 kHz, corresponding to the output filter + cut-off range. When dealing with harmonics, it's essential to ensure that the + harmonic frequencies remain below ~100 kHz, which aligns with the input filter cut-off. + Be mindful that hardware filters might impact the amplitude as the signal approaches + their cut-off frequencies." (e.g. 973E+0) @@ -161,9 +164,10 @@ set in the Frequency field (“4”) or harmonics.--> - Order of the harmonic oscillation to detect on the demodulated signal (with respect - to the modulation frequency). If you work with higher harmonics make sure the - frequency does not exceed the analog signal bandwidth (100 kHz). + N denotes 1 or 2. The order of the harmonic oscillation to be detected in the demodulated + signal should be considered relative to the modulation frequency. When dealing with + higher harmonics, it's essential to ensure that their frequencies do not surpass + the analogue signal bandwidth (e.g. harmonic_order_1). @@ -171,7 +175,7 @@ set in the Frequency field (“4”) or harmonics.--> Lock-in>Reference phase D2 (deg) -83.6562E+0 # See below.--> Reference phase for the sine on the demodulated signal with respect to the - modulation signal. The determined phase (phi) is displayed with respect to the + modulation signal. The determined phase is displayed with respect to the reference phase. @@ -223,22 +227,18 @@ doc: Same directional representation as bias. (e.g. 1E-3)--> - Temperature of LHe helium cryostat. Note: At least one field from + Temperature of liquid helium cryostat. Note: At least one field from stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp must be provided. - Temperature of LN2 nitrogen shield. Temperature 3 (K) (e.g 78.00000E+0). Note: At + Temperature of liquid nitrogen shield. Temperature 3 (K) (e.g 78.00000E+0). Note: At least one field from stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp must be provided. - - - Note_ no doc. - - + - N denotes X or Y. There are 2 parameters in X and Y directions and this tab - is used to set the sample tilt (in degrees, first order correction). + N denotes X or Y. There are 2 parameters in X and Y directions, and tilt needs to be + adjusted according to the actual surface. (in degrees, first order correction). - N denotes X or Y. There are 2 parameters in X and Y directions and this tab is - used to set a curvature (can be set approximately to the length of the - piezotube). + N denotes X or Y. There are 2 parameters in X and Y directions. (can be set + approximately to the length of the piezotube). @@ -308,7 +307,7 @@ doc: The rate at which the one of the signal changes when ramping to the startin - Use the button to turn on/off the drift compensation. (e.g. FALSE) + Use the button to enable or disable the drift compensation. (e.g. FALSE) @@ -321,7 +320,8 @@ doc: The rate at which the one of the signal changes when ramping to the startin - This is set-point of tip current. + This is set-point of tip current (in the constant current mode should be equal to set-point, + in the constant height mode means the real tunnelling current between tip and sample). @@ -350,14 +350,14 @@ doc: The rate at which the one of the signal changes when ramping to the startin - The scanning area in x position in the frame. (e.g. 130.5E-9) + The scanning area in z position in the frame. (e.g. 130.5E-9) - Indicate the tip position Z between tip and sample. The tip position can also - be varied when the controller is not running. (e.g. 130.5E-9) + Indicate the relative tip position z between tip and sample. The tip position can also + be varied when the z_controller is not running. (e.g. 130.5E-9) @@ -380,83 +380,83 @@ parameters for a measurement at a single location during the scan--> - The first bias values of the sweep. (e.g. -300E-3) + The start bias values of the sweep. (e.g. -300E-3) - The last bias values of the sweep. (e.g. 300E-3) + The end bias values of the sweep. (e.g. 300E-3) - Define the sweep number of points, that is, the maximum spectrum resolution eq. - Bias window divide by Num Pixel. (e.g. 4096) + The sweep number of points is defined as the maximum spectrum resolution, which + is equal to the bias sweep window divided by the number of pixels. (e.g. 4096) - Duration over which the Z position is recorded and averaged before and after the - sweep (the latter only if Record final Z position is selected in the Advanced - section). After the initial Z averaging time, if Z-Controller to Hold is selected - in the Advanced section, the Z-Controller is set to hold and the tip is placed at - the previously averaged Z position (plus Z offset). (e.g. 100E-3) + The Z position is recorded and averaged for a certain duration both before and + after the sweep. After the initial Z averaging time, if "Z-Controller to Hold" + is selected, the Z-Controller is set to hold mode, and the tip is positioned at + the previously averaged Z position (adjusted by the Z offset). (e.g. 100E-3) - The bandwitdh of the Hardware and/or Software which is insturment specific. - For example: Nanonis Generic 5 has 'RT Frequency' 20E-3. + The bandwidth of the Hardware and/or Software is instrument specific. + For example, Nanonis Generic 5 has 'RT Frequency' (e.g. 20E+3). - (Signals Periods) The Signals Period is the rate at which the signals are - transferred to the host computer running the control software. This is - usually lower by a factor of 10 than the sampling rate, because an internal - oversampling of the signal is done on the real time engine. You can reduce - the oversampling down to 1 in order to resolve higher frequencies in the - Spectrum Analyzer. (e.g. 10) + The Signals Period represents the rate at which signals are transferred to + the host computer, which operates the control software. This rate may + be 10 times lower than the sampling rate, as the real-time engine internally + oversamples the signal. If desired, you may have the option to reduce the oversampling + to 1, enabling higher frequency resolution in the Spectrum Analyzer. (e.g. 10) - Update rate for several processes like History Graph, Auto-Approach, and for - many Programming Interface functions. This is usually set to 20 ms. All - additional timings (7-9) can only be integer multiples of this value. They can - be set to different values, but the actual timing value will be coerced to a - multiple of the Acquisition Period. (e.g. 20E-3) + The update rate is utilized in various processes, including the History Graph, + Auto-Approach, and multiple Programming Interface functions. It may be + configured to a 20 ms interval. Any additional timings must strictly be integer + multiples of this base value. While it is possible to set these additional + timings to different values, the actual timing value will automatically be + adjusted to become a multiple of the Acquisition Period. (e.g. 20E-3) - Update rate of animated graphical indicators. These are e.g. some graphs & - sliders. A reasonable value is 40 ms (25 updates per second). Increase this - period to reduce the processor load for the graphical user interface, especially - on slow computers. This value is purely a user interface update rate and does - not affect measurements in any way. (e.g. 20E-3) + The update rate of animated graphical indicators, such as graphs and sliders, + can be adjusted. A normal value may be 40 ms, which corresponds to 25 updates + per second. Increasing this period can help reduce the processor load on the + graphical user interface, particularly on slower computers. It is important to + note that this update rate solely impacts the user interface and does not affect + measurements in any manner. (e.g. 20E-3) - Update rate of digital indicators, e.g. the numbers displayed besides each - slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a - user interface update rate and does not affect measurements in any way. (e.g. - 300E-3) + The update rate of digital indicators, such as the numbers displayed, can be set + to 3 updates per second, equivalent to 300 ms. This interval is sufficient for + the user interface and does not impact measurements in any manner. (e.g. 300E-3) - The Measurements period is the integration time for precise measurements - (averaging over specified period), mostly used in sweep modules. Examples are - recording of a force-distance curve or a resonance of a cantilever. For fast - measurements with small steps, a value of 40 ms may be reasonable. For normal - use, 300-500 ms is a good value, but for recording a resonance of a high-Q - cantilever, values of several seconds might be necessary. Usually this parameter - doesn’t need to be set from this module; the sweep modules will set this value - according to the sweep timings. (e.g. 500E-3) + The Measurements period determines the integration time required for precise + measurements, primarily utilized in sweep modules. It is particularly useful for + tasks such as recording force-distance curves or cantilever resonances. For + swift measurements with small steps, a value of 40 ms is often adequate. For + regular use, a range of 300-500 ms may be recommended, but when capturing the + resonance of a high-Q cantilever, longer values in the range of several seconds + might be necessary. Usually, this parameter does not require manual adjustment + within this module, as the sweep modules automatically set this value according + to the sweep timings. (e.g. 500E-3) @@ -466,8 +466,8 @@ parameters for a measurement at a single location during the scan--> - Also clarify the frame for the ROI of the scan (should depend on the lab frame). - Note_: Need to be reconfirmed?? + Also clarify the frame for the ROI of the scan in lab frame, the middle of the lab + frame is (0, 0), and positive in x means right and in y means up. @@ -516,101 +516,101 @@ As all of the bellow are linked should be NXcollection not NXprocess--> - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - To describe sample and other constaints that applied on sample. + To describe sample and other constaints that applied on sample before scanning. @@ -686,12 +686,12 @@ is switched off, it doesn't switch off immediately but continues to run for the equal to the number of voltage setpoints. axes: bias_calc signals: - li_demod_[1;2]_[X/Y]_[-;bwd;filt;bwd_filt] - current_[-;bwd;filt;bwd_filt] - temperature - x - y - z + li_demod_[1;2]_[X/Y]_[-;bwd;filt;bwd_filt] + current_[-;bwd;filt;bwd_filt] + temperature + x + y + z - + A generic positioner such as a motor or piezo-electric transducer. @@ -115,7 +115,7 @@ NXtransformations group. But NeXus allows them to be stored anywhere. .. todo:: - Add a definition for the reference point of a positioner. + Add a definition for the reference point of a positioner. @@ -248,26 +248,26 @@ setpoint_unit: doc: The unit of setpoint during the scanning.--> - The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T + The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and :math:`P/T` (proportional gain/time constant). The formula for the controller in the frequency domain is: - G(s) = P + I/s = P(1 + 1/(Ts)). - The integral gain and time constant are related as follows: I = P/T. + :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. + The integral gain and time constant are related as follows: :math:`I = P/T`. - The Type switches controller parameters between P/I (proportional gain/integral gain) and + The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency - domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related - as follows: I = P/T. + domain is: :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. The integral gain and time constant are related + as follows: `:math:I = P/T`. - The Type switches controller parameters between P/I (proportional gain/integral gain) and - P/T (proportional gain/time constant). The formula for the controller in the frequency - domain is: G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related - as follows: I = P/T. + The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and + :math:`P/T` (proportional gain/time constant). The formula for the controller in the frequency + domain is: :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. The integral gain and time constant are related + as follows: :math:`I = P/T`. - + A sensor used to monitor an external condition @@ -223,7 +223,7 @@ such as prepare chamber and analysis chamber - + The power present in the signal as a function of frequency. Used to characterise the vibration and noise of scanning probes to detect and reduce the impact on diff --git a/contributed_definitions/NXsts.nxdl.xml b/contributed_definitions/NXsts.nxdl.xml index 3188804f0b..d72b8a545c 100644 --- a/contributed_definitions/NXsts.nxdl.xml +++ b/contributed_definitions/NXsts.nxdl.xml @@ -43,7 +43,7 @@ y has (NXsoftware_Scan_offset) z has (NXsoftware_Scan_offset) - + @@ -334,7 +334,7 @@ doc: The rate at which the one of the signal changes when ramping to the startin - + Clarify the frame laboratory frame. @@ -596,7 +596,7 @@ Physical signal = (Voltage * calibration) + offset.--> - @@ -606,10 +606,10 @@ level and before starting to acquire data. Adjust this parameter to avoid transi effect induced by the bias change. Integration time: time during which the data are acquired and averaged.--> - - + - - + - +Z-Controller>Setpoint unit(NXpositioner_sts) (e.g.A) # Angstrom--> - - From db6632204654dcc1f7052a130a85b1fd18b6f137 Mon Sep 17 00:00:00 2001 From: Rubel Date: Sat, 29 Jul 2023 22:33:05 +0200 Subject: [PATCH 0186/1012] Addingexperiment type for sts and stm. Converting NXsensor_scan from 'application' into base class. --- contributed_definitions/NXsensor_scan.nxdl.xml | 2 +- contributed_definitions/NXsts.nxdl.xml | 9 +++++++++ 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/contributed_definitions/NXsensor_scan.nxdl.xml b/contributed_definitions/NXsensor_scan.nxdl.xml index 21a8f317ab..13aaef6794 100644 --- a/contributed_definitions/NXsensor_scan.nxdl.xml +++ b/contributed_definitions/NXsensor_scan.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + Variables used to set a common size for collected sensor data. diff --git a/contributed_definitions/NXsts.nxdl.xml b/contributed_definitions/NXsts.nxdl.xml index d72b8a545c..09bc712196 100644 --- a/contributed_definitions/NXsts.nxdl.xml +++ b/contributed_definitions/NXsts.nxdl.xml @@ -49,6 +49,15 @@ + + + Name of the experiment where the application is applicable. + + + + + + The equipments and techniques as well as the parameter settings and reference signals From ff35ff729aed3054e59c52e487fce3f54a30f1bb Mon Sep 17 00:00:00 2001 From: Rubel Date: Sun, 30 Jul 2023 22:54:19 +0200 Subject: [PATCH 0187/1012] Fixing optionality of NXsts application according to data file from Generic 4.5. --- contributed_definitions/NXsts.nxdl.xml | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/contributed_definitions/NXsts.nxdl.xml b/contributed_definitions/NXsts.nxdl.xml index 09bc712196..f9c817d9d8 100644 --- a/contributed_definitions/NXsts.nxdl.xml +++ b/contributed_definitions/NXsts.nxdl.xml @@ -43,7 +43,7 @@ y has (NXsoftware_Scan_offset) z has (NXsoftware_Scan_offset) - + @@ -124,8 +124,8 @@ crosstalk_compensation: Current amplifier> Capacitive cross-talk compensation: Y between tip and bias). - - + + Status of Lock-in device whether while performing the experiment @@ -179,7 +179,7 @@ set in the Frequency field (“4”) or harmonics.--> the analogue signal bandwidth (e.g. harmonic_order_1). - + @@ -257,7 +257,7 @@ output_name: doc: User outputs whose name can be modified in the corresponding module. (e.g. Input 24 (V)) output_slew_rate(NX_NUMBER): doc: The rate at which the one of the signal changes when ramping to the starting point. (V/s) (e.g. Inf)--> - + Configuration for piezoelectric scanner used to move tip along X and Y direction. The material of the Piezoelectric scanner composed of polycrystalline solids and sensitive to @@ -326,7 +326,7 @@ doc: The rate at which the one of the signal changes when ramping to the startin The temperature and voltage must be present as independently scanned controllers and the current sensor must also be present with its readings. - + This is set-point of tip current (in the constant current mode should be equal to set-point, @@ -376,7 +376,7 @@ voltage_controller(NXsensor): temperature_controller(NXsensor): parameters for a measurement at a single location during the scan--> - + Time during which the spectroscopy data are acquired and averaged. (e.g. 150E-6) @@ -412,7 +412,7 @@ parameters for a measurement at a single location during the scan--> - + The bandwidth of the Hardware and/or Software is instrument specific. @@ -591,7 +591,7 @@ as all of the bellow are linked--> - + @@ -600,11 +600,11 @@ a Range switch the calibration is stored per range setting.--> - + - + - + - - - A beamline aperture. This group is deprecated, use NXslit instead. - - + + + A beamline aperture. This group is deprecated, use NXslit instead. + + - - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - The reference point of the aperture is its center in the x and y axis. The reference point on the z axis is the - surface of the aperture pointing towards the source. - - In complex (asymmetic) geometries an NXoff_geometry group can be used to provide an unambiguous reference. - - .. image:: aperture/aperture.png - :width: 40% - + + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference point of the aperture is its center in the x and y axis. The reference point on the z axis is the + surface of the aperture pointing towards the source. + + In complex (asymmetic) geometries an NXoff_geometry group can be used to provide an unambiguous reference. + + .. image:: aperture/aperture.png + :width: 40% + - - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - + + 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. + + + + + Stores the raw positions of aperture motors. + - location and shape of aperture - - .. TODO: documentation needs improvement, contributions welcome - - * description of terms is poor and leaves much to interpretation - * Describe what is meant by translation _here_ and ... - * Similar throughout base classes - * Some base classes do this much better - * Such as where is the gap written? - + location and shape of aperture + + .. TODO: documentation needs improvement, contributions welcome + + * description of terms is poor and leaves much to interpretation + * Describe what is meant by translation _here_ and ... + * Similar throughout base classes + * Some base classes do this much better + * Such as where is the gap written? - location and shape of each blade + + location and shape of each blade + - - Absorbing material of the aperture + + + + Absorbing material of the aperture + - Description of aperture + + Description of aperture + - Shape of the aperture. - - - - - - - - - - - - - - - - The relevant dimension for the aperture, i.e. slit width, pinhole and iris - diameter - - - describe any additional information in a note* + + Shape of the aperture. + + + + + + + + + + + + + + + + + The relevant dimension for the aperture, i.e. slit width, pinhole and iris + diameter + + + + + describe any additional information in a note* + + - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. diff --git a/base_classes/NXdetector.nxdl.xml b/base_classes/NXdetector.nxdl.xml index a6bb0b8c68..cb017217b2 100644 --- a/base_classes/NXdetector.nxdl.xml +++ b/base_classes/NXdetector.nxdl.xml @@ -1,14 +1,14 @@ - + - - - - - These symbols will be used below to illustrate the coordination of the rank and sizes of datasets and the - preferred ordering of the dimensions. Each of these are optional (so the rank of the datasets - will vary according to the situation) and the general ordering principle is slowest to fastest. - The type of each dimension should follow the order of scan points, detector output (e.g. pixels), - then time-of-flight (i.e. spectroscopy, spectrometry). Note that the output of a detector is not limited - to single values (0D), lists (1D) and images (2), but three or higher dimensional arrays can be produced - by a detector at each trigger. - - - number of scan points (only present in scanning measurements) - number of detector pixels in the first (slowest) direction - number of detector pixels in the second (faster) direction - number of bins in the time-of-flight histogram - - - - A detector, detector bank, or multidetector. - - - - Total time of flight - - - - - - - - - - - - - - - - - - - Total time of flight - - - - - In DAQ clock pulses - - - - - - - Clock frequency in Hz - - - - - - Identifier for detector (pixels) - Can be multidimensional, if needed - - - - - - 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. - - - - - - - - - - - Title of measurement - - - - Integral of data as check of data integrity - - - - - - - The best estimate of the uncertainty in the data value (array size should match the data field). Where - possible, this should be the standard deviation, which has the same units - as the data. The form data_error is deprecated. - - - - - - - - - - - - - - Offset from the detector center in x-direction. - Can be multidimensional when needed. - - - - - - - - - - - - - - - - - - - - - x-axis offset from detector center - - - - - - Offset from the detector center in the y-direction. - Can be multidimensional when different values are required for each pixel. - - - - - - - - - - - - - - - - - - - - - y-axis offset from detector center - - - - - - - Offset from the detector center in the z-direction. - Can be multidimensional when different values are required for each pixel. - - - - - - - - - - - - - - - - - - - - - y-axis offset from detector center - - - - - - This is the distance to the previous component in the - instrument; most often the sample. The usage depends on the - nature of the detector: Most often it is the distance of the - detector assembly. But there are irregular detectors. In this - case the distance must be specified for each detector pixel. - - Note, it is recommended to use NXtransformations instead. - - - - - - - - - - - - This is the polar angle of the detector towards the previous - component in the instrument; most often the sample. - The usage depends on the - nature of the detector. - Most often it is the polar_angle of the detector assembly. - But there are irregular detectors. - In this - case, the polar_angle must be specified for each detector pixel. - - Note, it is recommended to use NXtransformations instead. - - - - - - - - - - - - This is the azimuthal angle angle of the detector towards - the previous component in the instrument; most often the sample. - The usage depends on the - nature of the detector. - Most often it is the azimuthal_angle of the detector assembly. - But there are irregular detectors. - In this - case, the azimuthal_angle must be specified for each detector pixel. - - Note, it is recommended to use NXtransformations instead. - - - - - - - - - - - name/manufacturer/model/etc. information - - - - Serial number for the detector - - - - Local name for the detector - - - - Position and orientation of detector - - - - Solid angle subtended by the detector at the sample - - - - - - - - - - Size of each detector pixel. If it is scalar all pixels are the same size. - - - - - - - - - - Size of each detector pixel. If it is scalar all pixels are the same size - - - - - - - - - Detector dead time - - - - - - - - - - Detector gas pressure - - - - - - - - - maximum drift space dimension - - - - Crate number of detector - - - - - - - - Equivalent local term - - - - - Slot number of detector - - - - - - - - Equivalent local term - - - - - Input number of detector - - - - - - - - Equivalent local term - - - - - - Description of type such as He3 gas cylinder, He3 PSD, scintillator, - fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, - CMOS, ... - - - - - Spectral efficiency of detector with respect to e.g. wavelength - - - - - - - - - - - - - - - - - - - - - - - - efficiency of the detector - - - - - - - - - - This field can be two things: - - #. For a pixel detector it provides the nominal wavelength - for which the detector has been calibrated. - - #. For other detectors this field has to be seen together with - the efficiency field above. - For some detectors, the efficiency is wavelength dependent. - Thus this field provides the wavelength axis for the efficiency field. - In this use case, the efficiency and wavelength arrays must - have the same dimensionality. - - - - - - - - - - - - Real-time of the exposure (use this if exposure time varies for - each array element, otherwise use ``count_time`` field). - - Most often there is a single real time value that is constant across - an entire image frame. In such cases, only a 1-D array is needed. - But there are detectors in which the real time - changes per pixel. In that case, more than one dimension is needed. Therefore - the rank of this field should be less than or equal to (detector rank + 1). - - - - - - - - - - start time for each frame, with the ``start`` attribute as absolute reference - - - - - - - stop time for each frame, with the ``start`` attribute as absolute reference - - - - - - - - - date of last calibration (geometry and/or efficiency) measurements - - - - - - summary of conversion of array data to pixels (e.g. polynomial - approximations) and location of details of the calibrations - - - - - How the detector is represented - - - - - - - - - - Elapsed actual counting time - - - - - - - - - - - Use this group to provide other data related to this NXdetector group. - - - - - - In order to properly sort the order of the images taken in (for - example) a tomography experiment, a sequence number is stored with each - image. - - - - - - - - - - This is the x position where the direct beam would hit the detector. - This is a length and can be outside of the actual - detector. The length can be in physical units or pixels - as documented by the units attribute. - - - - - - This is the y position where the direct beam would hit the detector. - This is a length and can be outside of the actual - detector. The length can be in physical units or pixels - as documented by the units attribute. - - - - - - This is the start number of the first frame of a scan. In protein crystallography measurements one - often scans a couple of frames on a give sample, then does something else, - then returns to the same sample and scans some more frames. Each time with - a new data file. This number helps concatenating such measurements. - - - - - The diameter of a cylindrical detector - - - - The acquisition mode of the detector. - - - - - - - - - - - - True when the angular calibration has been applied in the - electronics, false otherwise. - - - - Angular calibration data. - - - - - - - - True when the flat field correction has been applied in the - electronics, false otherwise. - - - - Flat field correction data. - - - - - - - - Errors of the flat field correction data. - The form flatfield_error is deprecated. - - - - - - - - - True when the pixel mask correction has been applied in the - electronics, false otherwise. - - - - - The 32-bit pixel mask for the detector. Can be either one mask - for the whole dataset (i.e. an array with indices i, j) or - each frame can have its own mask (in which case it would be - an array with indices np, i, j). - - Contains a bit field for each pixel to signal dead, - blind or high or otherwise unwanted or undesirable pixels. - They have the following meaning: - - .. can't make a table here, a bullet list will have to do for now - - * bit 0: gap (pixel with no sensor) - * bit 1: dead - * bit 2: under responding - * bit 3: over responding - * bit 4: noisy - * bit 5: -undefined- - * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) - * bit 7: -undefined- - * bit 8: user defined mask (e.g. around beamstop) - * bits 9-30: -undefined- - * bit 31: virtual pixel (corner pixel with interpolated value) - - Normal data analysis software would - not take pixels into account - when a bit in (mask & 0x0000FFFF) is - set. Tag bit in the upper - two bytes would indicate special pixel - properties that normally - would not be a sole reason to reject the - intensity value (unless - lower bits are set. - - If the full bit depths is not required, providing a - mask with fewer bits is permissible. - - If needed, additional pixel masks can be specified by - including additional entries named pixel_mask_N, where - N is an integer. For example, a general bad pixel mask - could be specified in pixel_mask that indicates noisy - and dead pixels, and an additional pixel mask from - experiment-specific shadowing could be specified in - pixel_mask_2. The cumulative mask is the bitwise OR - of pixel_mask and any pixel_mask_N entries. - - - - - - - - - - This field allow to distinguish different types of exposure to the same detector "data" field. - Some techniques require frequent (re-)calibration inbetween measuremnts and this way of - recording the different measurements preserves the chronological order with is important for - correct processing. - - This is used for example in tomography (`:ref:`NXtomo`) sample projections, - dark and flat images, a magic number is recorded per frame. - - The key is as follows: - - * projection (sample) = 0 - * flat field = 1 - * dark field = 2 - * invalid = 3 - * background (no sample, but buffer where applicable) = 4 - - In cases where the data is of type :ref:`NXlog` this can also be an NXlog. - - - - - - - - - Counting detectors usually are not able to measure all incoming particles, - especially at higher count-rates. Count-rate correction is applied to - account for these errors. - - True when count-rate correction has been applied, false otherwise. - - - - - The countrate_correction_lookup_table defines the LUT used for count-rate - correction. It maps a measured count :math:`c` to its corrected value - :math:`countrate\_correction\_lookup\_table[c]`. - - :math:`m` denotes the length of the table. - - - - - - - - True when virtual pixel interpolation has been applied, false otherwise. - - When virtual pixel interpolation is applied, values of some pixels may - contain interpolated values. For example, to account for space between - readout chips on a module, physical pixels on edges and corners between - chips may have larger sensor areas and counts may be distributed between - their logical pixels. - - - - - How many bits the electronics reads per pixel. - With CCD's and single photon counting detectors, - this must not align with traditional integer sizes. - This can be 4, 8, 12, 14, 16, ... - - - - - Time it takes to read the detector (typically milliseconds). - This is important to know for time resolved experiments. - - - - - Time it takes to start exposure after a trigger signal has been received. - This is the reaction time of the detector firmware after receiving the trigger signal - to when the detector starts to acquire the exposure, including any user set delay.. - This is important to know for time resolved experiments. - - - - - User-specified trigger delay. - - - - - Time it takes to start exposure after a trigger signal has been received. - This is the reaction time of the detector hardware after receiving the - trigger signal to when the detector starts to acquire the exposure. - It forms the lower boundary of the trigger_delay_time when the user - does not request an additional delay. - - - - - Time during which no new trigger signal can be accepted. - Typically this is the - trigger_delay_time + exposure_time + readout_time. - This is important to know for time resolved experiments. - - - - - This is time for each frame. This is exposure_time + readout time. - - - - - - - - The gain setting of the detector. This is a detector-specific value - meant to document the gain setting of the detector during data - collection, for detectors with multiple available gain settings. - - Examples of gain settings include: - - * ``standard`` - * ``fast`` - * ``auto`` - * ``high`` - * ``medium`` - * ``low`` - * ``mixed high to medium`` - * ``mixed medium to low`` - - Developers are encouraged to use one of these terms, or to submit - additional terms to add to the list. - - - - - The value at which the detector goes into saturation. - Especially common to CCD detectors, the data - is known to be invalid above this value. - - For example, given a saturation_value and an underload_value, the valid - pixels are those less than or equal to the saturation_value and greater - than or equal to the underload_value. - - The precise type should match the type of the data. - - - - - The lowest value at which pixels for this detector would be reasonably - measured. The data is known to be invalid below this value. - - For example, given a saturation_value and an underload_value, the valid - pixels are those less than or equal to the saturation_value and greater - than or equal to the underload_value. - - The precise type should match the type of the data. - - - - - CCD images are sometimes constructed by summing - together multiple short exposures in the - electronics. This reduces background etc. - This is the number of short exposures used to sum - images for an image. - - - - - At times, radiation is not directly sensed by the detector. - Rather, the detector might sense the output from some - converter like a scintillator. - This is the name of this converter material. - - - - - At times, radiation is not directly sensed by the detector. - Rather, the detector might sense the output from some - converter like a scintillator. - This is the thickness of this converter material. - - - - - Single photon counter detectors can be adjusted - for a certain energy range in which they - work optimally. This is the energy setting for this. - - - - - For use in special cases where the data in NXdetector - is represented in several parts, each with a separate geometry. - - - - - - Shape description of each pixel. Use only if all pixels in the detector - are of uniform shape. - + + + + These symbols will be used below to illustrate the coordination of the + rank and sizes of datasets and the preferred ordering of the + dimensions. Each of these are optional (so the rank of the datasets + will vary according to the situation) and the general ordering + principle is slowest to fastest. The type of each dimension should + follow the order of scan points, detector output (e.g. pixels), then + time-of-flight (i.e. spectroscopy, spectrometry). Note that the output + of a detector is not limited to single values (0D), lists (1D) and + images (2), but three or higher dimensional arrays can be produced by + a detector at each trigger. + + + + number of scan points (only present in scanning measurements) + + + + + number of detector pixels in the first (slowest) direction + + + + + number of detector pixels in the second (faster) direction + + + + + number of detector pixels in the third (if necessary, fastest) + direction + + + + + number of bins in the time-of-flight histogram + + + + + A detector, detector bank, or multidetector. + + + + Total time of flight + + + + + + + + + + + + + + + + + Total time of flight + + + + + + In DAQ clock pulses + + + + + + + Clock frequency in Hz + + + + + + Identifier for detector (pixels) + Can be multidimensional, if needed + + + + + 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. + + + + + + + + + + Title of measurement + + + + + Integral of data as check of data integrity + + + + + + The best estimate of the uncertainty in the data value (array size should match the data field). Where + possible, this should be the standard deviation, which has the same units + as the data. The form data_error is deprecated. + + + + + + + + + + + Offset from the detector center in x-direction. + Can be multidimensional when needed. + + + + + + + + + + + + + + + + + + x-axis offset from detector center + + + + + + Offset from the detector center in the y-direction. + Can be multidimensional when different values are required for each pixel. + + + + + + + + + + + + + + + + + + y-axis offset from detector center + + + + + + Offset from the detector center in the z-direction. + Can be multidimensional when different values are required for each pixel. + + + + + + + + + + + + + + + + + + y-axis offset from detector center + + + + + + This is the distance to the previous component in the + instrument; most often the sample. The usage depends on the + nature of the detector: Most often it is the distance of the + detector assembly. But there are irregular detectors. In this + case the distance must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. + + + + + + + + + + This is the polar angle of the detector towards the previous + component in the instrument; most often the sample. + The usage depends on the + nature of the detector. + Most often it is the polar_angle of the detector assembly. + But there are irregular detectors. + In this + case, the polar_angle must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. + + + + + + + + + + This is the azimuthal angle angle of the detector towards + the previous component in the instrument; most often the sample. + The usage depends on the + nature of the detector. + Most often it is the azimuthal_angle of the detector assembly. + But there are irregular detectors. + In this + case, the azimuthal_angle must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. + + + + + + + + + + name/manufacturer/model/etc. information + + + + + Serial number for the detector + + + + + Local name for the detector + + + + + Position and orientation of detector + + + + + Solid angle subtended by the detector at the sample + + + + + + + + + Size of each detector pixel. If it is scalar all pixels are the same size. + + + + + + + + + Size of each detector pixel. If it is scalar all pixels are the same size + + + + + + + + + Detector dead time + + + + + + + + + + Detector gas pressure + + + + + + + + + maximum drift space dimension + + + + + Crate number of detector + + + + + + + + Equivalent local term + + + + + + Slot number of detector + + + + + + + + Equivalent local term + + + + + + Input number of detector + + + + + + + + Equivalent local term + + + + + + Description of type such as He3 gas cylinder, He3 PSD, scintillator, + fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, + CMOS, ... + + + + + Spectral efficiency of detector with respect to e.g. wavelength + + + + + + + + + + + + + + + + + + + + + + + + + efficiency of the detector + + + + + + + + + + This field can be two things: + + #. For a pixel detector it provides the nominal wavelength + for which the detector has been calibrated. + + #. For other detectors this field has to be seen together with + the efficiency field above. + For some detectors, the efficiency is wavelength dependent. + Thus this field provides the wavelength axis for the efficiency field. + In this use case, the efficiency and wavelength arrays must + have the same dimensionality. + + + + + + + + + + + + + Real-time of the exposure (use this if exposure time varies for + each array element, otherwise use ``count_time`` field). + + Most often there is a single real time value that is constant across + an entire image frame. In such cases, only a 1-D array is needed. + But there are detectors in which the real time + changes per pixel. In that case, more than one dimension is needed. Therefore + the rank of this field should be less than or equal to (detector rank + 1). + + + + + + + + + + start time for each frame, with the ``start`` attribute as absolute reference + + + + + + + + + stop time for each frame, with the ``start`` attribute as absolute reference + + + + + + + + + date of last calibration (geometry and/or efficiency) measurements + + + + + summary of conversion of array data to pixels (e.g. polynomial + approximations) and location of details of the calibrations + - - - Shape description of each pixel. Use only if all pixels in the detector - are of uniform shape and require being described by cylinders. - + + + How the detector is represented + + + + + + + + + + Elapsed actual counting time + + + + + + + + + Use this group to provide other data related to this NXdetector group. + - - - - - Shape description of the whole detector. Use only if pixels in the - detector are not of uniform shape. - + + + In order to properly sort the order of the images taken in (for + example) a tomography experiment, a sequence number is stored with each + image. + + + + + + + + This is the x position where the direct beam would hit the detector. + This is a length and can be outside of the actual + detector. The length can be in physical units or pixels + as documented by the units attribute. + + + + + This is the y position where the direct beam would hit the detector. + This is a length and can be outside of the actual + detector. The length can be in physical units or pixels + as documented by the units attribute. + + + + + This is the start number of the first frame of a scan. In protein crystallography measurements one + often scans a couple of frames on a give sample, then does something else, + then returns to the same sample and scans some more frames. Each time with + a new data file. This number helps concatenating such measurements. + + + + + The diameter of a cylindrical detector + + + + + The acquisition mode of the detector. + + + + + + + + + + + + + True when the angular calibration has been applied in the + electronics, false otherwise. + + + + + Angular calibration data. + + + + + + + + + True when the flat field correction has been applied in the + electronics, false otherwise. + + + + + Flat field correction data. + + + + + + + + + Errors of the flat field correction data. + The form flatfield_error is deprecated. + + + + + + + + + True when the pixel mask correction has been applied in the + electronics, false otherwise. + + + + + The 32-bit pixel mask for the detector. Can be either one mask + for the whole dataset (i.e. an array with indices i, j) or + each frame can have its own mask (in which case it would be + an array with indices np, i, j). + + Contains a bit field for each pixel to signal dead, + blind or high or otherwise unwanted or undesirable pixels. + They have the following meaning: + + .. can't make a table here, a bullet list will have to do for now + + * bit 0: gap (pixel with no sensor) + * bit 1: dead + * bit 2: under responding + * bit 3: over responding + * bit 4: noisy + * bit 5: -undefined- + * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) + * bit 7: -undefined- + * bit 8: user defined mask (e.g. around beamstop) + * bits 9-30: -undefined- + * bit 31: virtual pixel (corner pixel with interpolated value) + + Normal data analysis software would + not take pixels into account + when a bit in (mask & 0x0000FFFF) is + set. Tag bit in the upper + two bytes would indicate special pixel + properties that normally + would not be a sole reason to reject the + intensity value (unless + lower bits are set. + + If the full bit depths is not required, providing a + mask with fewer bits is permissible. + + If needed, additional pixel masks can be specified by + including additional entries named pixel_mask_N, where + N is an integer. For example, a general bad pixel mask + could be specified in pixel_mask that indicates noisy + and dead pixels, and an additional pixel mask from + experiment-specific shadowing could be specified in + pixel_mask_2. The cumulative mask is the bitwise OR + of pixel_mask and any pixel_mask_N entries. + + + + + + + + + This field allow to distinguish different types of exposure to the same detector "data" field. + Some techniques require frequent (re-)calibration inbetween measuremnts and this way of + recording the different measurements preserves the chronological order with is important for + correct processing. + + This is used for example in tomography (`:ref:`NXtomo`) sample projections, + dark and flat images, a magic number is recorded per frame. + + The key is as follows: + + * projection (sample) = 0 + * flat field = 1 + * dark field = 2 + * invalid = 3 + * background (no sample, but buffer where applicable) = 4 + + In cases where the data is of type :ref:`NXlog` this can also be an NXlog. + + + + + + + + Counting detectors usually are not able to measure all incoming particles, + especially at higher count-rates. Count-rate correction is applied to + account for these errors. + + True when count-rate correction has been applied, false otherwise. + + + + + The countrate_correction_lookup_table defines the LUT used for count-rate + correction. It maps a measured count :math:`c` to its corrected value + :math:`countrate\_correction\_lookup\_table[c]`. + + :math:`m` denotes the length of the table. + + + + + + + + True when virtual pixel interpolation has been applied, false otherwise. + + When virtual pixel interpolation is applied, values of some pixels may + contain interpolated values. For example, to account for space between + readout chips on a module, physical pixels on edges and corners between + chips may have larger sensor areas and counts may be distributed between + their logical pixels. + + + + + How many bits the electronics reads per pixel. + With CCD's and single photon counting detectors, + this must not align with traditional integer sizes. + This can be 4, 8, 12, 14, 16, ... + + + + + Time it takes to read the detector (typically milliseconds). + This is important to know for time resolved experiments. + + + + + Time it takes to start exposure after a trigger signal has been received. + This is the reaction time of the detector firmware after receiving the trigger signal + to when the detector starts to acquire the exposure, including any user set delay.. + This is important to know for time resolved experiments. + + + + + User-specified trigger delay. + + + + + Time it takes to start exposure after a trigger signal has been received. + This is the reaction time of the detector hardware after receiving the + trigger signal to when the detector starts to acquire the exposure. + It forms the lower boundary of the trigger_delay_time when the user + does not request an additional delay. + + + + + Time during which no new trigger signal can be accepted. + Typically this is the + trigger_delay_time + exposure_time + readout_time. + This is important to know for time resolved experiments. + + + + + This is time for each frame. This is exposure_time + readout time. + + + + + + + + The gain setting of the detector. This is a detector-specific value + meant to document the gain setting of the detector during data + collection, for detectors with multiple available gain settings. + + Examples of gain settings include: + + * ``standard`` + * ``fast`` + * ``auto`` + * ``high`` + * ``medium`` + * ``low`` + * ``mixed high to medium`` + * ``mixed medium to low`` + + Developers are encouraged to use one of these terms, or to submit + additional terms to add to the list. + + + + + The value at which the detector goes into saturation. + Especially common to CCD detectors, the data + is known to be invalid above this value. + + For example, given a saturation_value and an underload_value, the valid + pixels are those less than or equal to the saturation_value and greater + than or equal to the underload_value. + + The precise type should match the type of the data. + + + + + The lowest value at which pixels for this detector would be reasonably + measured. The data is known to be invalid below this value. + + For example, given a saturation_value and an underload_value, the valid + pixels are those less than or equal to the saturation_value and greater + than or equal to the underload_value. + + The precise type should match the type of the data. + + + + + CCD images are sometimes constructed by summing + together multiple short exposures in the + electronics. This reduces background etc. + This is the number of short exposures used to sum + images for an image. + + + + + At times, radiation is not directly sensed by the detector. + Rather, the detector might sense the output from some + converter like a scintillator. + This is the name of this converter material. + + + + + At times, radiation is not directly sensed by the detector. + Rather, the detector might sense the output from some + converter like a scintillator. + This is the thickness of this converter material. + + + + + Single photon counter detectors can be adjusted + for a certain energy range in which they + work optimally. This is the energy setting for this. + + + + + For use in special cases where the data in NXdetector + is represented in several parts, each with a separate geometry. + + + + + + Shape description of each pixel. Use only if all pixels in the detector + are of uniform shape. + + + + + Shape description of each pixel. Use only if all pixels in the detector + are of uniform shape and require being described by cylinders. + + + + + + + Shape description of the whole detector. Use only if pixels in the + detector are not of uniform shape. + + + + + Shape description of the whole detector. Use only if pixels in the + detector are not of uniform shape and require being described by cylinders. + + + + + + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + + + + + Type of electron amplifier, MCP, channeltron, etc. + + + + + Description of the detector type, DLD, Phosphor+CCD, CMOS. + + + + + Voltage applied to detector. + + + + + Voltage applied to the amplifier. + + + + + The low voltage of the amplifier migh not be the ground. + + + + + Size of each imaging sensor chip on the detector. + + + + + Number of imaging sensor chips on the detector. + + + + + Physical size of the pixels of the imaging chip on the detector. + + + + + Number of raw active elements in each dimension. Important for swept scans. + + + + + raw data output from the detector + - - - Shape description of the whole detector. Use only if pixels in the - detector are not of uniform shape and require being described by cylinders. - + + + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference point of the detector is the center of the first pixel. + In complex geometries the NXoff_geometry groups can be used to provide an unambiguous reference. + + + + + 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. + - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - - - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - The reference point of the detector is the center of the first pixel. - In complex geometries the NXoff_geometry groups can be used to provide an unambiguous reference. - - - - - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - - diff --git a/contributed_definitions/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXcollectioncolumn.nxdl.xml index d2a5fb8fa5..c8bd717074 100644 --- a/contributed_definitions/NXcollectioncolumn.nxdl.xml +++ b/contributed_definitions/NXcollectioncolumn.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 3 of the License, or (at your option) any later version. +# version 2 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -23,8 +23,8 @@ --> - 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. diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 8a92c050ce..ff13c5e93d 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 3 of the License, or (at your option) any later version. +# version 2 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -22,13 +22,9 @@ # For further information, see http://www.nexusformat.org --> - - This is the most general application definition for multidimensional - photoelectron spectroscopy. + This is the most general application definition for multidimensional + photoelectron spectroscopy. @@ -196,7 +192,6 @@ with higher granularity in the data description.--> - Description of the detector type. @@ -328,11 +323,6 @@ with higher granularity in the data description.--> other metadata file. In the case these are not available, free-text description. - In the case of a fixed temperature measurement this is the scalar temperature of @@ -349,7 +339,6 @@ It seems quite contorted to ask to create a separate timestamp array when we hav - From 7f44baf8b66f12b8ac2404b35679eb25edd10c40 Mon Sep 17 00:00:00 2001 From: Rubel Date: Thu, 17 Aug 2023 17:14:31 +0200 Subject: [PATCH 0192/1012] spliting clean into clean and clean-nyaml --- Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Makefile b/Makefile index f50c7b7514..aeeba6cddb 100644 --- a/Makefile +++ b/Makefile @@ -50,6 +50,8 @@ test :: clean :: $(RM) -rf $(BUILD_DIR) + +clean-nyaml :: for dir in $(NXDL_DIRS); do\ $(RM) -rf $${dir}/nyaml;\ done From da0dda5dd965b6aaaa42250f2efb91d926988199 Mon Sep 17 00:00:00 2001 From: rettigl Date: Tue, 22 Aug 2023 16:02:08 +0200 Subject: [PATCH 0193/1012] add transformations and required 3rd dimension to NXmpes_arpes --- .../nyaml/NXmpes_arpes.yaml | 111 +++++++++++++----- 1 file changed, 80 insertions(+), 31 deletions(-) diff --git a/contributed_definitions/nyaml/NXmpes_arpes.yaml b/contributed_definitions/nyaml/NXmpes_arpes.yaml index 6cb8da8b0b..80007550d5 100644 --- a/contributed_definitions/nyaml/NXmpes_arpes.yaml +++ b/contributed_definitions/nyaml/NXmpes_arpes.yaml @@ -1,6 +1,6 @@ #Pincelli, Rettig, Arora at fhi-berlin.mpg.de, Dobener at hu-berlin.de, 06/2022 #Draft version of a NeXus application definition for angle resolved photoemission. -#This appdef aims to describe data produced from hemispherical anlysers, +#This appdef aims to describe data produced from hemispherical anlysers, #with at least an angular coordinate and one an energy coordinate. #It is designed to be extended by other application definitions #with higher granularity in the data description. @@ -11,9 +11,22 @@ NXmpes_arpes(NXmpes): definition: \@version: enumeration: ["NXmpes_arpes"] + geometries(NXcollection): + arpesgeometry(NXcollection): + depends_on(NX_CHAR): + doc: "Link to transformations defining an APRES base coordinate system, which is defined such that the positive z-axis points towards the analyzer entry, and the x-axis lies within the beam/analyzer plane." + (NXtransformations): + doc: "Set of transformations, describing the orientation of the ARPES coordinate system with respect to the beam coordinate system (.)." (NXinstrument): angular_resolution(NX_FLOAT): unit: NX_ANGLE + depends_on(NX_CHAR): + doc: "Reference to the transformation describing the orientation of the analyzer relative to the beam." + (NXtransformations): + doc: "Set of transformations, describing the relative orientation of the analyzer with respect to the beam coordinate system (.)." + # Do we need to require the existence/use of a particular rotation to determine slit orientation? + analyzer_rotation(NX_NUMBER): + doc: "Rotation about the analyzer axis. This needs to be defined in the transformation chain." (NXelectronanalyser): description: angular_resolution(NX_FLOAT): @@ -30,36 +43,57 @@ NXmpes_arpes(NXmpes): ] (NXenergydispersion): scheme: - enumeration: ["hemispherical"] - pass_energy(NX_NUMBER): - unit: NX_ENERGY + enumeration: ["hemispherical", "tof"] center_energy(NX_NUMBER): + exists: recommended unit: NX_ENERGY diameter(NX_NUMBER): + exists: recommended unit: NX_LENGTH - energy_scan_mode: entrance_slit(NXaperture): shape: - enumeration: [ - "straight slits", - "curved slits", + enumeration: [ + "straight slit", + "curved slit", "open", - "grid", ] - (NXtransformations): # Do we need to require the existence/use of a particular - #rotation to determine slit orientation? - doc: "Set of transformations, describing the relative orientation of the slits with respect to the beam coordinate system (.)." (NXdetector): - (NXdata): # Raw signal without calibrated axes. + data(NX_NUMBER): # Raw signal without calibrated axes. exists: recommended - \@signal: - enumeration: ['raw'] - raw(NX_NUMBER): # There is a block of numbers named raw. - doc: "Raw data before calibration." - depends_on(NX_CHAR): - doc: "Reference to the transformation describing the orientation of the analyzer relative to the beam." - (NXtransformations): - doc: "Set of transformations, describing the relative orientation of the analyzer with respect to the beam coordinate system (.)." + doc: "Raw data before calibration." + (NXprocess): + doc: "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" + energy_calibration(NXcalibration): + exists: optional + applied(NX_BOOLEAN): + doc: "Has an energy calibration been applied?" + calibrated_axis(NX_FLOAT): + exists: recommended + doc: "This is the calibrated energy axis to be used for data plotting." + angular1_calibration(NXcalibration): + exists: optional + applied(NX_BOOLEAN): + doc: "Has an angular calibration been applied to dispersive axis 1?" + calibrated_axis(NX_FLOAT): + exists: recommended + doc: "This is the calibrated angular axis to be used for data plotting." + depends_on(NX_CHAR): + doc: "Reference to the transformation describing the orientation of the first dispersed analyzer angle." + (NXtransformations): + doc: "Set of transformations, describing the relation of the dispersing analyzer angles and analyzer roations with respect to the reference coordinate system (.)." + angular2_calibration(NXcalibration): + exists: optional + applied(NX_BOOLEAN): + doc: "Has an angular calibration been applied to dispersive axis 2?" + calibrated_axis(NX_FLOAT): + exists: recommended + doc: "This is the calibrated angular axis to be used for data plotting." + depends_on(NX_CHAR): + doc: "Reference to the transformation describing the orientation of the second dispersed analyzer angle." + (NXtransformations): + doc: "Set of transformations, describing the relation of the dispersing analyzer angles and analyzer roations with respect to the reference coordinate system (.)." (NXsample): situation: enumeration: ["vacuum"] @@ -71,30 +105,45 @@ NXmpes_arpes(NXmpes): (NXdata): \@signal: enumeration: ["data"] # There is an object named data that contains the signal - \@axes: # There are at least two dimensions, an energy & (at least) an angular coordinate - enumeration: ["[energy, angular1]"] - \@energy_indices: # energy is a 1D array - enumeration: [1] - \@angular1_indices: # angular is a 1D array - enumeration: [1] + \@axes: # There are three dimensions, one energy & two angular coordinates. Any coordinates that do not move, are represented by one point. + enumeration: ["[angular1, angluar2, energy]"] + \@energy_indices: # energy indices have to be provided + \@angular1_indices: # angular1 indices have to be provided + \@angular2_indices: # angular2 indices have to be provided \@angular1_depends(NX_CHAR): # In ARPES, the angular coordinate can be generated in different ways. # It can be a detector axis in a 2D detector, or scanned by changing the angle of a manipulator. # We propose a structure similar to depends_on(NX_CHAR) of NXtransformations to reconstruct the # metadata path that produced the angular coordinate. This allows to reconstruct the geometry programmatically. - doc: "Points to the path to a field defining the axis on which the angular axis depends. + doc: "Points to the path to a field defining the axis on which the angular axis depends. For example: @angular1_depends: '/entry/sample/transformations/rot_phi' for a manipulator angular scan @angular1_depends: '/entry/instrument/detector/sensor_x' for a 2D detector @angular1_depends: '/entry/instrument/collectioncolumn/deflector' for a deflector scan - @angular1_depends: '/entry/process/calibration/angular_calibration/calibrated_axis' for a preprocessed axis." + @angular1_depends: '/entry/process/calibration/angular1_calibration/calibrated_axis' for a preprocessed axis." + \@angular2_depends(NX_CHAR): # In ARPES, the angular coordinate can be generated in different ways. + # It can be a detector axis in a 2D detector, or scanned by changing the angle of a manipulator. + # We propose a structure similar to depends_on(NX_CHAR) of NXtransformations to reconstruct the + # metadata path that produced the angular coordinate. This allows to reconstruct the geometry programmatically. + doc: "Points to the path to a field defining the axis on which the angular axis depends. + For example: + @angular2_depends: '/entry/sample/transformations/rot_tht' for a manipulator angular scan + @angular2_depends: '/entry/instrument/detector/sensor_x' for a 2D detector + @angular2_depends: '/entry/instrument/collectioncolumn/deflector' for a deflector scan + @angular2_depends: '/entry/process/calibration/angular2_calibration/calibrated_axis' for a preprocessed axis." \@energy_depends(NX_CHAR): # Similarly, energy can be dispersed according to different strategies - doc: "Points to the path to a field defining the axis on which the energy axis depends. + doc: "Points to the path to a field defining the axis on which the energy axis depends. For example: @energy_depends: '/entry/instrument/detector/sensor_y' for a 2D detector @energy_depends: '/entry/instrument/energydispersion/center_kinetic_energy' for a swept scan @energy_depends: '/entry/process/calibration/energy_calibration/calibrated_axis' for a preprocessed axis." + energy(NX_NUMBER): + doc: "Trace of the energy axis. Could be linked from the respective 'AXISNAME_depends' field." + angular1(NX_NUMBER): + doc: "Trace of the first angular axis. Could be linked from the respective 'AXISNAME_depends' field." + angular2(NX_NUMBER): + doc: "Trace of the second axis. Could be linked from the respective 'AXISNAME_depends' field." data(NX_NUMBER): # There is a block of numbers named data. - doc: "Represents a measure of two- or more-dimensional photoemission counts, where + doc: "Represents a measure of three-dimensional photoemission counts, where the varied axes are energy, and one or more angular coordinates. Axes traces should be linked to the actual encoder position in NXinstrument or calibrated axes in NXprocess." unit: NX_ANY From 2808ff8f76a3e2978889e0ae515f13289a0104ea Mon Sep 17 00:00:00 2001 From: Rubel Date: Wed, 23 Aug 2023 15:04:58 +0200 Subject: [PATCH 0194/1012] Replacing link by field in NXsts application. --- contributed_definitions/NXsts.nxdl.xml | 249 ++++++++++++++++++++----- 1 file changed, 204 insertions(+), 45 deletions(-) diff --git a/contributed_definitions/NXsts.nxdl.xml b/contributed_definitions/NXsts.nxdl.xml index f9c817d9d8..d6ccdca594 100644 --- a/contributed_definitions/NXsts.nxdl.xml +++ b/contributed_definitions/NXsts.nxdl.xml @@ -525,156 +525,315 @@ As all of the bellow are linked should be NXcollection not NXprocess--> - + + + Link to target:/NXentry/NXinstrument/stm_head_temp + + - + + + Link to target:/NXentry/NXinstrument/cryo_bottom_temp + + - + + + Link to target:/NXentry/NXinstrument/temp_cryo_shield + + - + + + Link to target:/NXentry/NXinstrument/NXlock_in/modulation_signal + + - - - + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/NXintegration_time + + + + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/number_of_sweeps + + - + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/sweep_start + + - + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/sweep_end + + - + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/num_pixel + + - + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_avg_time + + - + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/rt_frequency + + - + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/signals_oversampling + + - + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/acquisition_period + + - + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/animations_period + + - + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/indicators_period + + - + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/measurements_period + + - + + + Link to target:/NXentry/NXinstrument/NXsample_bias/bias + + - + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current + + - - - + + + Link to target:/NXentry/NXnstrument/NXsample_bias/bias_calibration + + + + + Link to target:/NXentry/NXinstrument/NXsample_bias/bias_offset + + - + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_calibration + + - + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_offset + + - + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_gain + + - - + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_offset + + + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/settling_time + + - + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_ccontroller_hold + + - + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/record_final_z + + - + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/first_settling_time + + - + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/end_settling_time + + - + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_control_time + + - + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/max_slew_rate + + - + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/backward_sweep + + - + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/controller_name + + - + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/controller_status + + - + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/set_point + + - + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/p_gain + + - + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/i_gain + + - + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/time_const + + - + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/tip_lift + + + - + + + Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/switchoff_delay + + From e190fdc07a5dc8af4d120c4983ec989a4f2953e4 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 23 Aug 2023 23:02:10 +0200 Subject: [PATCH 0195/1012] Initial draft for major refactoring of NXsample. NXsample can now hold several base classes that split the sample description into 1) description of its components down to the chemical substance level -> NXsample_component, NXsample_component_set, NXsubstance, NXsample_surface_dopant as an example for an NXsubstance 2) any physical process that was performed prior/during the experiment -> NXphysical_process, NXsample_synthesis_step, ... -> can also be stored in NXsample_history 3) a description of the sample history -> NXsample_history, made up of one or more NXphysical_process instances 4) sample environment -> for now still allowed as NXenvironment in NXsample, but should eventually be on the level of the application definitions --- base_classes/NXsample.nxdl.xml | 915 ++++++++++-------- base_classes/NXsample_component.nxdl.xml | 317 +++--- .../NXphysical_process.nxdl.xml | 39 + .../NXsample_component_set.nxdl.xml | 73 ++ .../NXsample_history.nxdl.xml | 44 + .../NXsample_substrate.nxdl.xml | 71 ++ .../NXsample_surface_dopant.nxdl.xml | 38 + .../NXsample_synthesis_step.nxdl.xml | 35 + .../NXsingle_crystal.nxdl.xml | 58 ++ contributed_definitions/NXsubstance.nxdl.xml | 75 ++ contributed_definitions/NXunit_cell.nxdl.xml | 76 ++ 11 files changed, 1232 insertions(+), 509 deletions(-) create mode 100644 contributed_definitions/NXphysical_process.nxdl.xml create mode 100644 contributed_definitions/NXsample_component_set.nxdl.xml create mode 100644 contributed_definitions/NXsample_history.nxdl.xml create mode 100644 contributed_definitions/NXsample_substrate.nxdl.xml create mode 100644 contributed_definitions/NXsample_surface_dopant.nxdl.xml create mode 100644 contributed_definitions/NXsample_synthesis_step.nxdl.xml create mode 100644 contributed_definitions/NXsingle_crystal.nxdl.xml create mode 100644 contributed_definitions/NXsubstance.nxdl.xml create mode 100644 contributed_definitions/NXunit_cell.nxdl.xml diff --git a/base_classes/NXsample.nxdl.xml b/base_classes/NXsample.nxdl.xml index 43bb316334..731c53d612 100755 --- a/base_classes/NXsample.nxdl.xml +++ b/base_classes/NXsample.nxdl.xml @@ -1,9 +1,9 @@ - + - - - - symbolic array lengths to be coordinated between various fields - number of compositions - number of temperatures - number of values in applied electric field - number of values in applied magnetic field - number of values in applied pressure field - number of values in applied stress field - - - - 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. - - - Descriptive name of sample - - - - 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. - - - - Sample temperature. This could be a scanned variable - - - - - - Applied electric field - - - + + + + symbolic array lengths to be coordinated between various fields + + + + number of compositions + + + + + number of temperatures + + + + + number of values in applied electric field + + + + + number of values in applied magnetic field + + + + + number of values in applied pressure field + + + + + number of values in applied stress field + + + + + 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. + However, this information is ideally stored in a dedicated NXenvironment on the application definition level. + + + + Descriptive name of sample + + + + + The chemical formula specified using CIF conventions. + Abbreviated version of CIF standard:107 + + * 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. + + + + + Sample temperature. This could be a scanned variable + + + + + + + + + Applied electric field + + + + + - - - - - + + + + + - - - Applied magnetic field - - - + + + + Applied magnetic field + + + + + - - - - - + + + + + - - - Applied external stress field - - - + + + + Applied external stress field + + + + + - - - - - + + + + + - - - Applied pressure - - - - - - Sample changer position - - - Crystallography unit cell parameters a, b, and c - - - - - - Crystallography unit cell parameters alpha, beta, and gamma - - - - - - Unit cell parameters (lengths and angles) - - - - - - - Volume of the unit cell - - - - - - - This will follow the Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - - - - - - - - Orientation matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - - - - - - - - - - UB matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is - the multiplication of the orientation_matrix, given above, - with the :math:`B` matrix which - can be derived from the lattice constants. - - - - - - - - - Mass of sample - - - - - - Density of sample - - - - - - Relative Molecular Mass of sample - - - - - - - - - - - - - - - - - - - - - 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. - - - - - - - - - - - - - - Description of the sample - - - - Date of preparation of the sample - - - The position and orientation of the center of mass of the sample - - - Details of beam incident on sample - used to calculate sample/beam interaction point - - - - One group per sample component - This is the perferred way of recording per component information over the n_comp arrays - - - - Details of the component of the sample and/or can - - - - - - Type of component - - - - - - - - - - - - Concentration of each component - - - - - - Volume fraction of each component - - - - - - Scattering length density of each component - - - - - - - In case it is all we know and we want to record/document it - - - - - - - - - - - - - Crystallographic space group - - - - - - Crystallographic point group, deprecated if space_group present - - + + + + Applied pressure + + + + + + + + + Sample changer position + Note, it is recommended to use NXpositioner instead. + + + + + Crystallography unit cell parameters a, b, and c + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma + + + + + + + + Unit cell parameters (lengths and angles) + + + + + + + + + Volume of the unit cell + + + + + + + + This will follow the Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + + + + + + + + Orientation matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + + + + + + + + + + UB matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is + the multiplication of the orientation_matrix, given above, + with the :math:`B` matrix which + can be derived from the lattice constants. + + + + + + + + + + Mass of sample + + + + + Density of sample + + + + + Relative Molecular Mass of sample + + + + + + + + + + + + + + + + + + + + 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. + This should be deprecated in the future. + + + + + + + + + + + + + + Description of the sample + + + + + Information about a sample synthesis step. + + + + + Date of preparation of the sample + + + + + The position and orientation of the center of mass of the sample + + + + + Details of beam incident on sample - used to calculate sample/beam interaction + point + + + + + One group per sample component + This is the perferred way of recording per component information over the n_comp arrays + + + + + Set of sample components and their configuration. + + + + + Details of the component of the sample and/or can + + + + + + + + Type of component + + + + + + + + + + + + + + Concentration of each component + + + + + + + + Volume fraction of each component + + + + + + + + Scattering length density of each component + + + + + + + + In case it is all we know and we want to record/document it + + + + + + + + + + + + + + Crystallographic space group + + + + + + + + Crystallographic point group, deprecated if space_group present + + + - - - - Path length through sample/can for simple case when - it does not vary with scattering direction - - - - - Thickness of a beam entry/exit window on the can (mm) - - assumed same for entry and exit - - - - sample thickness - - - As a function of Wavelength - - - temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value - - - Additional sample temperature environment information - - - magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value - - - magnetic_field_log.value is a link to e.g. magnetic_field_env.sensor1.value_log.value - - - Additional sample magnetic environment information - - - value sent to user's sample setup - - - logged value (or logic state) read from user's setup - - - 20 character fixed length sample description for legends - - - - - Optional rotation angle for the case when the powder diagram has - been obtained through an omega-2theta scan like from a traditional - single detector powder diffractometer. - Note, it is recommended to use NXtransformations instead. - - - - - Translation of the sample along the X-direction of the laboratory coordinate system - Note, it is recommended to use NXtransformations instead. - - - - - Translation of the sample along the Z-direction of the laboratory coordinate system. - Note, it is recommended to use NXtransformations instead. - - - - Any positioner (motor, PZT, ...) used to locate the sample - - - - This group describes the shape of the sample - - + + + + Path length through sample/can for simple case when + it does not vary with scattering direction + + + + + Thickness of a beam entry/exit window on the can (mm) + - assumed same for entry and exit + + + + + sample thickness + + + + + Identification number or signatures of the sample used. + + + + + A set of physical processes that occurred to the sample prior/during experiment. + + + + + Physical state of the sample + + + + + Chemical purity of the sample + + + + + Surface termination of the sample (if crystalline) + + + + + Any substance contained in the sample. + + + + + Details about the sample vendor (company or research group) + + + + + Information about the material of the substrate in direct contact with the sample. + Could be a sample holder for example. + + + + + + Any environmental or external stimuli/measurements. + These can include, among others: + applied pressure, surrounding gas phase and gas pressure, + external electric/magnetic/stress fields, temperature, ... + + + + + Further notes. + + + + + As a function of Wavelength + + + + + temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value + + + + + Additional sample temperature environment information + Note, it is recommended to have NXenvironment as a stand-alone in the application definition. + + + + + magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value + + + + + magnetic_field_log.value is a link to e.g. + magnetic_field_env.sensor1.value_log.value + + + + + Additional sample magnetic environment information + Note, it is recommended to have NXenvironment as a stand-alone in the application definition. + + + + + value sent to user's sample setup + + + + + logged value (or logic state) read from user's setup + + + + + 20 character fixed length sample description for legends + + + + + + Optional rotation angle for the case when the powder diagram has + been obtained through an omega-2theta scan like from a traditional + single detector powder diffractometer. + Note, it is recommended to use NXtransformations instead. + + + + + Translation of the sample along the X-direction of the laboratory coordinate system + Note, it is recommended to use NXtransformations instead. + + + + + Translation of the sample along the Z-direction of the laboratory coordinate system. + Note, it is recommended to use NXtransformations instead. + + + + + Any positioner (motor, PZT, ...) used to locate the sample + + + + + This group describes the shape of the sample + + - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. + 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. - 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. - diff --git a/base_classes/NXsample_component.nxdl.xml b/base_classes/NXsample_component.nxdl.xml index 624c09557d..76fbc42f41 100644 --- a/base_classes/NXsample_component.nxdl.xml +++ b/base_classes/NXsample_component.nxdl.xml @@ -1,9 +1,9 @@ - + - - - - symbolic array lengths to be coordinated between various fields - number of temperatures - number of values in applied electric field - number of values in applied magnetic field - number of values in applied pressure field - number of values in applied stress field - - - - One group like this per component can be recorded For a sample consisting of multiple components. - - - Descriptive name of sample component - - - - 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. - - - - Crystallography unit cell parameters a, b, and c - - - - - - Crystallography unit cell parameters alpha, beta, and gamma - - - - - - Volume of the unit cell - - - This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) - - - - - - - Orientation matrix of single crystal sample component. - This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) - - - - - - - - Mass of sample component - - - Density of sample component - - - Relative Molecular Mass of sample component - - - - Description of the sample component - - - - Volume fraction of component - - - Scattering length density of component - - - - In case it is all we know and we want to record/document it - - - - - - - - - - - - - Crystallographic space group - - - Crystallographic point group, deprecated if space_group present - - - As a function of Wavelength - + + + + symbolic array lengths to be coordinated between various fields + + + + number of temperatures + + + + + number of values in applied electric field + + + + + number of values in applied magnetic field + + + + + number of values in applied pressure field + + + + + number of values in applied stress field + + + + + One group like this per component can be recorded For a sample consisting of + multiple components. + + + + Descriptive name of sample component + + + + + 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. + + + + + Crystallography unit cell parameters a, b, and c + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma + + + + + + + + Volume of the unit cell + + + + + This will follow the Busing and Levy convention from Acta.Crysta v22, p457 + (1967) + + + + + + + + Orientation matrix of single crystal sample component. + This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) + + + + + + + + + Mass of sample component + + + + + Density of sample component + + + + + Relative Molecular Mass of sample component + + + + + Description of the sample component + + + + + Volume fraction of component + + + + + Scattering length density of component + + + + + In case it is all we know and we want to record/document it + + + + + + + + + + + + + + Crystallographic space group + + + + + Crystallographic point group, deprecated if space_group present + + + + + As a function of Wavelength + + + + + A set of physical processes that occurred to the sample component prior/during + experiment. + + + + + Any substance contained in the sample component. + + + + + Details about the sample component vendor (company or research group) + + - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. diff --git a/contributed_definitions/NXphysical_process.nxdl.xml b/contributed_definitions/NXphysical_process.nxdl.xml new file mode 100644 index 0000000000..a98b9dd7ab --- /dev/null +++ b/contributed_definitions/NXphysical_process.nxdl.xml @@ -0,0 +1,39 @@ + + + + + + A planned or unplanned process which results in physical changes in a specified material. + Examples include sample preparation, material transformation, or (partially) destrustive measurement. + + + + Datetime when the physical process occured. + + + + + Short description of the physical process. + + + diff --git a/contributed_definitions/NXsample_component_set.nxdl.xml b/contributed_definitions/NXsample_component_set.nxdl.xml new file mode 100644 index 0000000000..e5deef356d --- /dev/null +++ b/contributed_definitions/NXsample_component_set.nxdl.xml @@ -0,0 +1,73 @@ + + + + + + + DOC MISSING. + + + + number of components + + + + + Set of sample components and their configuration. The idea here is to store all descriptors that + cannot be stored on the level of the individual sample component. + + + + Number of layers of the sample (e.g. bulk, monolayer, pentalayer, etc.) + + + + + Concentration of each component + + + + + + + + Volume fraction of each component + + + + + + + + Scattering length density of each component + + + + + + + + One such group per component + + + diff --git a/contributed_definitions/NXsample_history.nxdl.xml b/contributed_definitions/NXsample_history.nxdl.xml new file mode 100644 index 0000000000..a6a181e1c4 --- /dev/null +++ b/contributed_definitions/NXsample_history.nxdl.xml @@ -0,0 +1,44 @@ + + + + + + A set of physical processes that occurred to the sample prior/during experiment. + Ideally, a full report of the previous operations, in the format of NXphysical_process. + Alternatively, notes allows for additional descriptors in any format. + + + + Any process that was performed on the sample prior or during the experiment. + Examples includ + + + + + A descriptor to keep track of the treatment of the sample before or during the + experiment (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + + + diff --git a/contributed_definitions/NXsample_substrate.nxdl.xml b/contributed_definitions/NXsample_substrate.nxdl.xml new file mode 100644 index 0000000000..00bcf4adf1 --- /dev/null +++ b/contributed_definitions/NXsample_substrate.nxdl.xml @@ -0,0 +1,71 @@ + + + + + + Any information on the sample substrate. + + + + Material of the substrate in direct contact with the sample. + + + + + Physical state of the substrate, similar options to sample state + + + + + Further notes. + + + + + Any substance contained in the sample substrate. + + + + + Name of the sample substrate vendor (company or research group) + + + + + 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. + + + + + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups + + + diff --git a/contributed_definitions/NXsample_surface_dopant.nxdl.xml b/contributed_definitions/NXsample_surface_dopant.nxdl.xml new file mode 100644 index 0000000000..d6df21d1f6 --- /dev/null +++ b/contributed_definitions/NXsample_surface_dopant.nxdl.xml @@ -0,0 +1,38 @@ + + + + + + Description of a dopant material embedded in a sample surface. + + + + Element of evaporated surface dopant such as alkali or other + + + + + Nominal thickness of the evaporated dopant. + + + diff --git a/contributed_definitions/NXsample_synthesis_step.nxdl.xml b/contributed_definitions/NXsample_synthesis_step.nxdl.xml new file mode 100644 index 0000000000..17a9f9e398 --- /dev/null +++ b/contributed_definitions/NXsample_synthesis_step.nxdl.xml @@ -0,0 +1,35 @@ + + + + + + A planned or unplanned process which results in physical changes in a specified material. + Examples include sample preparation, material transformation, or (partially) destrustive measurement. + + + + Descriptor of the synthesis method. For sample growth method, this could include e. g. + molecular beam epitaxy, chemical vapor deposition etc. + + + diff --git a/contributed_definitions/NXsingle_crystal.nxdl.xml b/contributed_definitions/NXsingle_crystal.nxdl.xml new file mode 100644 index 0000000000..7981e06460 --- /dev/null +++ b/contributed_definitions/NXsingle_crystal.nxdl.xml @@ -0,0 +1,58 @@ + + + + + + Description of a single crystal material or a single crystalline phase in a + material. + + + + This will follow the Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + + + + + + + + UB matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is + the multiplication of the orientation_matrix, given above, + with the :math:`B` matrix which + can be derived from the lattice constants. + + + + + + + + + + + Unit cell of the material. + + + diff --git a/contributed_definitions/NXsubstance.nxdl.xml b/contributed_definitions/NXsubstance.nxdl.xml new file mode 100644 index 0000000000..6bad47dc4f --- /dev/null +++ b/contributed_definitions/NXsubstance.nxdl.xml @@ -0,0 +1,75 @@ + + + + + + A form of matter with a constant, definite chemical composition. + Examples can be single chemical elements, chemical compunds, or alloys. + + + + Full chemical name of the sample + + + + + Name in the IUPAC system. + + + + + The chemical formula specified using CIF conventions. + Abbreviated version of CIF standard:107 + + * 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. + + + + + Molecular mass of the substance. + + + + + CAS registry number of the sample chemical content. + + + + + inChi identifier. + + + diff --git a/contributed_definitions/NXunit_cell.nxdl.xml b/contributed_definitions/NXunit_cell.nxdl.xml new file mode 100644 index 0000000000..f669f78d55 --- /dev/null +++ b/contributed_definitions/NXunit_cell.nxdl.xml @@ -0,0 +1,76 @@ + + + + + + Description of a unit cell, e.g. of a single crystalline material. + + + + In case it is all we know and we want to record/document it + + + + + + + + + + + + + + Crystallographic space group + + + + + Crystallographic point group, deprecated if space_group presents + + + + + Crystallography unit cell parameters a, b, and c + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma + + + + + + + + Volume of the unit cell + + + + + + From 3224d4db2025b2645d1fb554f2c9dd105434a4ea Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 23 Aug 2023 23:07:51 +0200 Subject: [PATCH 0196/1012] Add new/changed nyaml files for better discussion. This also contains a NXsample_without_deprecated.yaml file that show the new NXsample without the many deprecated fields. --- base_classes/nyaml/NXsample.yaml | 423 ++++++++++++++++++ base_classes/nyaml/NXsample_component.yaml | 148 ++++++ .../nyaml/NXsample_without_deprecated.yaml | 170 +++++++ .../nyaml/NXphysical_process.yaml | 12 + .../nyaml/NXsample_component_set.yaml | 37 ++ .../nyaml/NXsample_history.yaml | 17 + .../nyaml/NXsample_substrate.yaml | 103 +++++ .../nyaml/NXsample_surface_dopant.yaml | 13 + .../nyaml/NXsample_synthesis_step.yaml | 10 + .../nyaml/NXsingle_crystal.yaml | 32 ++ .../nyaml/NXsubstance.yaml | 41 ++ .../nyaml/NXunit_cell.yaml | 35 ++ 12 files changed, 1041 insertions(+) create mode 100644 base_classes/nyaml/NXsample.yaml create mode 100644 base_classes/nyaml/NXsample_component.yaml create mode 100644 base_classes/nyaml/NXsample_without_deprecated.yaml create mode 100644 contributed_definitions/nyaml/NXphysical_process.yaml create mode 100644 contributed_definitions/nyaml/NXsample_component_set.yaml create mode 100644 contributed_definitions/nyaml/NXsample_history.yaml create mode 100644 contributed_definitions/nyaml/NXsample_substrate.yaml create mode 100644 contributed_definitions/nyaml/NXsample_surface_dopant.yaml create mode 100644 contributed_definitions/nyaml/NXsample_synthesis_step.yaml create mode 100644 contributed_definitions/nyaml/NXsingle_crystal.yaml create mode 100644 contributed_definitions/nyaml/NXsubstance.yaml create mode 100644 contributed_definitions/nyaml/NXunit_cell.yaml diff --git a/base_classes/nyaml/NXsample.yaml b/base_classes/nyaml/NXsample.yaml new file mode 100644 index 0000000000..68f5887ad2 --- /dev/null +++ b/base_classes/nyaml/NXsample.yaml @@ -0,0 +1,423 @@ +category: base +doc: | + 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. + However, this information is ideally stored in a dedicated NXenvironment on the application definition level. +symbols: + doc: | + symbolic array lengths to be coordinated between various fields + n_comp: | + number of compositions + n_Temp: | + number of temperatures + n_eField: | + number of values in applied electric field + n_mField: | + number of values in applied magnetic field + n_pField: | + number of values in applied pressure field + n_sField: | + number of values in applied stress field +type: group +NXsample(NXobject): + name: + doc: | + Descriptive name of sample + chemical_formula: + deprecated: | + Use `NXsubstance` instead. + doc: | + The chemical formula specified using CIF conventions. + Abbreviated version of CIF standard:107 + + * 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. + temperature(NX_FLOAT): + deprecated: | + Use `NXenvironment` to log the sample temperature. + unit: NX_TEMPERATURE + doc: | + Sample temperature. This could be a scanned variable + dimensions: + rank: anyRank + # could be any length + dim: [[1, n_Temp]] + electric_field(NX_FLOAT): + deprecated: | + Use `NXenvironment` to log the applied electric field. + unit: NX_VOLTAGE + doc: | + Applied electric field + dimensions: + # could be any length + dim: [[1, n_eField]] + \@direction: + enumeration: [x, y, z] + magnetic_field(NX_FLOAT): + deprecated: | + Use `NXenvironment` to log the applied magnetic field. + unit: NX_ANY + doc: | + Applied magnetic field + dimensions: + # could be any length + dim: [[1, n_mField]] + \@direction: + enumeration: [x, y, z] + stress_field(NX_FLOAT): + deprecated: | + Use `NXenvironment` to log the applied external stress field. + unit: NX_ANY + doc: | + Applied external stress field + dimensions: + # could be any length + dim: [[1, n_sField]] + \@direction: + enumeration: [x, y, z] + pressure(NX_FLOAT): + deprecated: | + Use `NXenvironment` to log the applied pressure. + unit: NX_PRESSURE + doc: | + Applied pressure + dimensions: + # could be any length + dim: [[1, n_pField]] + changer_position(NX_INT): + unit: NX_UNITLESS + doc: | + Sample changer position + Note, it is recommended to use NXpositioner instead. + unit_cell_abc(NX_FLOAT): + deprecated: | + Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. + unit: NX_LENGTH + doc: | + Crystallography unit cell parameters a, b, and c + dimensions: + dim: [[1, 3]] + unit_cell_alphabetagamma(NX_FLOAT): + deprecated: | + Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. unit: NX_ANGLE + doc: | + Crystallography unit cell parameters alpha, beta, and gamma + dimensions: + dim: [[1, 3]] + unit_cell(NX_FLOAT): + deprecated: | + Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. + unit: NX_LENGTH + doc: | + Unit cell parameters (lengths and angles) + dimensions: + rank: 2 + dim: [[1, n_comp], [2, 6]] + unit_cell_volume(NX_FLOAT): + deprecated: | + Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. + unit: NX_VOLUME + doc: | + Volume of the unit cell + dimensions: + rank: 1 + dim: [[1, n_comp]] + sample_orientation(NX_FLOAT): + deprecated: | + Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. + unit: NX_ANGLE + doc: | + This will follow the Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + dimensions: + rank: 1 + dim: [[1, 3]] + orientation_matrix(NX_FLOAT): + deprecated: | + Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. + doc: | + Orientation matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + dimensions: + rank: 3 + dim: [[1, n_comp], [2, 3], [3, 3]] + ub_matrix(NX_FLOAT): + deprecated: | + Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. + doc: | + UB matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is + the multiplication of the orientation_matrix, given above, + with the :math:`B` matrix which + can be derived from the lattice constants. + dimensions: + rank: 3 + dim: [[1, n_comp], [2, 3], [3, 3]] + mass(NX_FLOAT): + unit: NX_MASS + doc: | + Mass of sample + density(NX_FLOAT): + unit: NX_MASS_DENSITY + doc: | + Density of sample + relative_molecular_mass(NX_FLOAT): + unit: NX_MASS + doc: | + Relative Molecular Mass of sample + type: + # This is neither complete nor should all of these enumerate options be here. + enumeration: [sample, sample+can, can, sample+buffer, buffer, calibration sample, normalisation sample, simulated data, none, sample environment] + situation: + deprecated: | + Use `NXenvironment` instead. + doc: | + 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. + This should be deprecated in the future. + enumeration: [air, vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere, sealed can, other] + description: + doc: | + Description of the sample + (NXsample_synthesis_step): + doc: + Information about a sample synthesis step. + preparation_date(NX_DATE_TIME): + deprecated: + Use `NXprocess_sample_prep` instead. + doc: | + Date of preparation of the sample + geometry(NXgeometry): + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the sample and NXoff_geometry to describe its shape instead + doc: | + The position and orientation of the center of mass of the sample + (NXbeam): + doc: | + Details of beam incident on sample - used to calculate sample/beam interaction point + (NXsample_component): + doc: | + One group per sample component + This is the perferred way of recording per component information over the n_comp arrays + (NXsample_component_set): + doc: | + Set of sample components and their configuration. + component: + deprecated: | + Use `NXsample_component_set` for the configuration of the different components. + doc: | + Details of the component of the sample and/or can + dimensions: + rank: 1 + dim: [[1, n_comp]] + sample_component: + deprecated: | + Use `NXsample_component_set` for the configuration of the different components. + doc: | + Type of component + dimensions: + rank: 1 + dim: [[1, n_comp]] + enumeration: [sample, can, atmosphere, kit] + concentration(NX_FLOAT): + deprecated: | + Use `NXsample_component_set` for the configuration of the different components. + unit: NX_MASS_DENSITY + doc: | + Concentration of each component + dimensions: + rank: 1 + dim: [[1, n_comp]] + volume_fraction(NX_FLOAT): + deprecated: | + Use `NXsample_component_set` for the configuration of the different components. + doc: | + Volume fraction of each component + dimensions: + rank: 1 + dim: [[1, n_comp]] + scattering_length_density(NX_FLOAT): + deprecated: | + Use `NXsample_component_set` for the configuration of the different components. + unit: NX_SCATTERING_LENGTH_DENSITY + doc: | + Scattering length density of each component + dimensions: + rank: 1 + dim: [[1, n_comp]] + unit_cell_class: + doc: | + In case it is all we know and we want to record/document it + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + space_group: + deprecated: | + Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. + doc: | + Crystallographic space group + dimensions: + dim: [[1, n_comp]] + point_group: + deprecated: | + Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. + doc: | + Crystallographic point group, deprecated if space_group present + dimensions: + dim: [[1, n_comp]] + path_length(NX_FLOAT): + unit: NX_LENGTH + doc: | + Path length through sample/can for simple case when + it does not vary with scattering direction + path_length_window(NX_FLOAT): + unit: NX_LENGTH + doc: | + Thickness of a beam entry/exit window on the can (mm) + - assumed same for entry and exit + thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + sample thickness + sample_id(NX_CHAR): + doc: | + Identification number or signatures of the sample used. + (NXsample_history): + doc: | + A set of physical processes that occurred to the sample prior/during experiment. + state(NX_CHAR): + doc: | + Physical state of the sample + purity(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Chemical purity of the sample + orientation(NX_CHAR): + deprecated: | + Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. + doc: | + Surface termination of the sample (if crystalline) + (NXsubstance): + doc: | + Any substance contained in the sample. + (NXfabrication): + doc: | + Details about the sample vendor (company or research group) + (NXsample_substrate): + doc: | + Information about the material of the substrate in direct contact with the sample. + Could be a sample holder for example. + (NXenvironment): + # eventually, this should be stored in the application definitions + doc: | + Any environmental or external stimuli/measurements. + These can include, among others: + applied pressure, surrounding gas phase and gas pressure, + external electric/magnetic/stress fields, temperature, ... + notes(NXnote): + doc: | + Further notes. + transmission(NXdata): + doc: | + As a function of Wavelength + temperature_log(NXlog): + deprecated: | + use ``temperature``, see: https://github.com/nexusformat/definitions/issues/816 + doc: | + temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value + temperature_env(NXenvironment): + doc: | + Additional sample temperature environment information + Note, it is recommended to have NXenvironment as a stand-alone in the application definition. + magnetic_field(NXlog): + doc: | + magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value + magnetic_field_log(NXlog): + deprecated: | + use ``magnetic_field``, see: https://github.com/nexusformat/definitions/issues/816 + doc: | + magnetic_field_log.value is a link to e.g. magnetic_field_env.sensor1.value_log.value + magnetic_field_env(NXenvironment): + doc: | + Additional sample magnetic environment information + Note, it is recommended to have NXenvironment as a stand-alone in the application definition. + external_DAC(NX_FLOAT): + deprecated: | + Use `NXenvironment` to log any external DACs. + unit: NX_ANY + doc: | + value sent to user's sample setup + external_ADC(NXlog): + deprecated: | + Use `NXenvironment` to log any external ADCs. + doc: | + logged value (or logic state) read from user's setup + short_title: + doc: | + 20 character fixed length sample description for legends + + # How is the string length limitation imposed by the XSD? + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Optional rotation angle for the case when the powder diagram has + been obtained through an omega-2theta scan like from a traditional + single detector powder diffractometer. + Note, it is recommended to use NXtransformations instead. + x_translation(NX_FLOAT): + unit: NX_LENGTH + doc: | + Translation of the sample along the X-direction of the laboratory coordinate system + Note, it is recommended to use NXtransformations instead. + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + Translation of the sample along the Z-direction of the laboratory coordinate system. + Note, it is recommended to use NXtransformations instead. + (NXpositioner): + doc: | + Any positioner (motor, PZT, ...) used to locate the sample + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the sample + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + 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. + (NXtransformations): + doc: | + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. \ No newline at end of file diff --git a/base_classes/nyaml/NXsample_component.yaml b/base_classes/nyaml/NXsample_component.yaml new file mode 100644 index 0000000000..294b69f2c2 --- /dev/null +++ b/base_classes/nyaml/NXsample_component.yaml @@ -0,0 +1,148 @@ +category: base +doc: | + One group like this per component can be recorded For a sample consisting of multiple components. +symbols: + doc: | + symbolic array lengths to be coordinated between various fields + n_Temp: | + number of temperatures + n_eField: | + number of values in applied electric field + n_mField: | + number of values in applied magnetic field + n_pField: | + number of values in applied pressure field + n_sField: | + number of values in applied stress field +type: group +NXsample_component(NXobject): + name: + doc: | + Descriptive name of sample component + chemical_formula: + deprecated: | + Use `NXsubstance` instead. + doc: | + 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. + unit_cell_abc(NX_FLOAT): + deprecated: | + Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. + unit: NX_LENGTH + doc: | + Crystallography unit cell parameters a, b, and c + dimensions: + dim: [[1, 3]] + unit_cell_alphabetagamma(NX_FLOAT): + deprecated: | + Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. + unit: NX_ANGLE + doc: | + Crystallography unit cell parameters alpha, beta, and gamma + dimensions: + dim: [[1, 3]] + unit_cell_volume(NX_FLOAT): + deprecated: | + Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. + unit: NX_VOLUME + doc: | + Volume of the unit cell + sample_orientation(NX_FLOAT): + deprecated: | + Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. + unit: NX_ANGLE + doc: | + This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) + dimensions: + rank: 1 + dim: [[1, 3]] + orientation_matrix(NX_FLOAT): + deprecated: | + Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. + doc: | + Orientation matrix of single crystal sample component. + This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) + dimensions: + rank: 2 + dim: [[1, 3], [2, 3]] + mass(NX_FLOAT): + unit: NX_MASS + doc: | + Mass of sample component + density(NX_FLOAT): + unit: NX_MASS_DENSITY + doc: | + Density of sample component + relative_molecular_mass(NX_FLOAT): + unit: NX_MASS + doc: | + Relative Molecular Mass of sample component + description: + doc: | + Description of the sample component + volume_fraction(NX_FLOAT): + deprecated: | + Use `NXsample_component_set` for the configuration of the multiple components. + doc: | + Volume fraction of component + scattering_length_density(NX_FLOAT): + deprecated: | + Use `NXsample_component_set` for the configuration of the multiple components. + unit: NX_SCATTERING_LENGTH_DENSITY + doc: | + Scattering length density of component + unit_cell_class: + deprecated: | + Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. + doc: | + In case it is all we know and we want to record/document it + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + space_group: + deprecated: | + Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. + doc: | + Crystallographic space group + point_group: + deprecated: | + Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. + doc: | + Crystallographic point group, deprecated if space_group present + transmission(NXdata): + doc: | + As a function of Wavelength + (NXsample_history): + doc: | + A set of physical processes that occurred to the sample component prior/during experiment. + (NXsubstance): + doc: | + Any substance contained in the sample component. + (NXfabrication): + doc: | + Details about the sample component vendor (company or research group) + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. \ No newline at end of file diff --git a/base_classes/nyaml/NXsample_without_deprecated.yaml b/base_classes/nyaml/NXsample_without_deprecated.yaml new file mode 100644 index 0000000000..36d28018e4 --- /dev/null +++ b/base_classes/nyaml/NXsample_without_deprecated.yaml @@ -0,0 +1,170 @@ +category: base +doc: | + 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. + However, this information is ideally stored in a dedicated NXenvironment on the application definition level. +type: group +NXsample(NXobject): + name: + doc: | + Descriptive name of sample + description: + doc: | + Description of the sample + short_title: + doc: | + 20 character fixed length sample description for legends + # How is the string length limitation imposed by the XSD? + sample_id(NX_CHAR): + doc: | + Identification number or signatures of the sample used. + mass(NX_FLOAT): + unit: NX_MASS + doc: | + Mass of sample + density(NX_FLOAT): + unit: NX_MASS_DENSITY + doc: | + Density of sample + type: + # This is neither complete nor should all of these enumerate options be here. + enumeration: [sample, sample+can, can, sample+buffer, buffer, calibration sample, normalisation sample, simulated data, none, sample environment] + thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + sample thickness + path_length(NX_FLOAT): + unit: NX_LENGTH + doc: | + Path length through sample/can for simple case when + it does not vary with scattering direction + path_length_window(NX_FLOAT): + unit: NX_LENGTH + doc: | + Thickness of a beam entry/exit window on the can (mm) + - assumed same for entry and exit + (NXsample_synthesis_step): + doc: + Information about a sample synthesis step. + (NXbeam): + doc: | + Details of beam incident on sample - used to calculate sample/beam interaction point + (NXsample_component): + doc: | + One group per sample component + This is the perferred way of recording per component information over the n_comp arrays + (NXsample_component_set): + doc: | + Set of sample components and their configuration. + (NXsample_history): + doc: | + A set of physical processes that occurred to the sample prior/during experiment. + (NXsubstance): + doc: | + Any substance contained in the sample. + (NXfabrication): + doc: | + Details about the sample vendor (company or research group) + (NXsample_substrate): + doc: | + Information about the material of the substrate in direct contact with the sample. + Could be a sample holder for example. + (NXenvironment): + # eventually, this should be stored in the application definitions + doc: | + Any environmental or external stimuli/measurements. + These can include, among others: + applied pressure, surrounding gas phase and gas pressure, + external electric/magnetic/stress fields, temperature, ... + notes(NXnote): + doc: | + Further notes. + transmission(NXdata): + doc: | + As a function of Wavelength + (NXpositioner): + doc: | + Any positioner (motor, PZT, ...) used to locate the sample + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the sample + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + 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. + (NXtransformations): + doc: | + 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. + +# Still here, should eventually be deprecated. + relative_molecular_mass(NX_FLOAT): + unit: NX_MASS + doc: | + Relative Molecular Mass of sample + changer_position(NX_INT): + unit: NX_UNITLESS + doc: | + Sample changer position + Note, it is recommended to use NXpositioner instead. + state(NX_CHAR): + doc: | + Physical state of the sample. Should be described in more detail. + purity(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Chemical purity of the sample + temperature_log(NXlog): + deprecated: | + use ``temperature``, see: https://github.com/nexusformat/definitions/issues/816 + doc: | + temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value + temperature_env(NXenvironment): + doc: | + Additional sample temperature environment information + Note, it is recommended to have NXenvironment as a stand-alone in the application definition. + magnetic_field(NXlog): + doc: | + magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value + magnetic_field_env(NXenvironment): + doc: | + Additional sample magnetic environment information + Note, it is recommended to have NXenvironment as a stand-alone in the application definition. + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Optional rotation angle for the case when the powder diagram has + been obtained through an omega-2theta scan like from a traditional + single detector powder diffractometer. + Note, it is recommended to use NXtransformations instead. + x_translation(NX_FLOAT): + unit: NX_LENGTH + doc: | + Translation of the sample along the X-direction of the laboratory coordinate system + Note, it is recommended to use NXtransformations instead. + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + Translation of the sample along the Z-direction of the laboratory coordinate system. + Note, it is recommended to use NXtransformations instead. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXphysical_process.yaml b/contributed_definitions/nyaml/NXphysical_process.yaml new file mode 100644 index 0000000000..2fe4b91040 --- /dev/null +++ b/contributed_definitions/nyaml/NXphysical_process.yaml @@ -0,0 +1,12 @@ +category: base +doc: | + A planned or unplanned process which results in physical changes in a specified material. + Examples include sample preparation, material transformation, or (partially) destrustive measurement. +type: group +NXphysical_process(NXobject): + date(NX_DATE_TIME): + doc: | + Datetime when the physical process occured. + description(NX_CHAR): + doc: | + Short description of the physical process. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXsample_component_set.yaml b/contributed_definitions/nyaml/NXsample_component_set.yaml new file mode 100644 index 0000000000..a388d764a5 --- /dev/null +++ b/contributed_definitions/nyaml/NXsample_component_set.yaml @@ -0,0 +1,37 @@ +category: base +doc: | + Set of sample components and their configuration. The idea here is to store all descriptors that + cannot be stored on the level of the individual sample component. +symbols: + doc: | + DOC MISSING. + n_comp: | + number of components +type: group +NXsample_component_set(NXobject): + layer(NX_CHAR): + doc: | + Number of layers of the sample (e.g. bulk, monolayer, pentalayer, etc.) + concentration(NX_FLOAT): + unit: NX_MASS_DENSITY + doc: | + Concentration of each component + dimensions: + rank: 1 + dim: [[1, n_comp]] + volume_fraction(NX_FLOAT): + doc: | + Volume fraction of each component + dimensions: + rank: 1 + dim: [[1, n_comp]] + scattering_length_density(NX_FLOAT): + unit: NX_SCATTERING_LENGTH_DENSITY + doc: | + Scattering length density of each component + dimensions: + rank: 1 + dim: [[1, n_comp]] + (NXsample_component): + doc: | + One such group per component \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXsample_history.yaml b/contributed_definitions/nyaml/NXsample_history.yaml new file mode 100644 index 0000000000..6051baec49 --- /dev/null +++ b/contributed_definitions/nyaml/NXsample_history.yaml @@ -0,0 +1,17 @@ +category: base +doc: | + A set of physical processes that occurred to the sample prior/during experiment. + Ideally, a full report of the previous operations, in the format of NXphysical_process. + Alternatively, notes allows for additional descriptors in any format. +type: group +NXsample_history(NXobject): + (NXphysical_process): + doc: | + Any process that was performed on the sample prior or during the experiment. + Examples includ + notes(NXnote): + doc: | + A descriptor to keep track of the treatment of the sample before or during the + experiment (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXsample_substrate.yaml b/contributed_definitions/nyaml/NXsample_substrate.yaml new file mode 100644 index 0000000000..3098c26d03 --- /dev/null +++ b/contributed_definitions/nyaml/NXsample_substrate.yaml @@ -0,0 +1,103 @@ +category: base +doc: | + Any information on the sample substrate. +type: group +NXsample_substrate(NXobject): + material(NX_CHAR): + doc: | + Material of the substrate in direct contact with the sample. + state(NX_CHAR): + doc: | + Physical state of the substrate, similar options to sample state + notes(NXnote): + doc: | + Further notes. + (NXsubstance): + doc: | + Any substance contained in the sample substrate. + (NX_fabrication): + doc: | + Name of the sample substrate vendor (company or research group) + depends_on(NX_CHAR): + doc: | + 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. + (NXtransformations): + doc: | + 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 + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 4da1282284e4cb3c7d04a670fbf0d5ac15900ab98e6a70223483376a382954a0 +# +# +# +# +# +# Any information on the sample substrate. +# +# +# +# Material of the substrate in direct contact with the sample. +# +# +# +# +# Physical state of the substrate, similar options to sample_state +# +# +# +# +# Further notes. +# +# +# +# +# Name of the sample substrate vendor (company or research group) +# +# +# +# +# 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. +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups +# +# +# diff --git a/contributed_definitions/nyaml/NXsample_surface_dopant.yaml b/contributed_definitions/nyaml/NXsample_surface_dopant.yaml new file mode 100644 index 0000000000..1e9f2d3f04 --- /dev/null +++ b/contributed_definitions/nyaml/NXsample_surface_dopant.yaml @@ -0,0 +1,13 @@ +category: base +doc: | + Description of a dopant material embedded in a sample surface. +type: group +NXsample_surface_dopant(NXsample_component): + element: + doc: | + Element of evaporated surface dopant such as alkali or other + coverage: + unit: NX_LENGTH + doc: | + Nominal thickness of the evaporated dopant. + \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXsample_synthesis_step.yaml b/contributed_definitions/nyaml/NXsample_synthesis_step.yaml new file mode 100644 index 0000000000..5d97f904ad --- /dev/null +++ b/contributed_definitions/nyaml/NXsample_synthesis_step.yaml @@ -0,0 +1,10 @@ +category: base +doc: | + A planned or unplanned process which results in physical changes in a specified material. + Examples include sample preparation, material transformation, or (partially) destrustive measurement. +type: group +NXsample_synthesis_step(NXphysical_process): + method(NX_CHAR): + doc: | + Descriptor of the synthesis method. For sample growth method, this could include e. g. + molecular beam epitaxy, chemical vapor deposition etc. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXsingle_crystal.yaml b/contributed_definitions/nyaml/NXsingle_crystal.yaml new file mode 100644 index 0000000000..212091cffd --- /dev/null +++ b/contributed_definitions/nyaml/NXsingle_crystal.yaml @@ -0,0 +1,32 @@ +category: base +doc: | + Description of a single crystal material or a single crystalline phase in a material. +type: group +NXsingle_crystal(NXobject): + sample_orientation(NX_FLOAT): + unit: NX_ANGLE + doc: | + This will follow the Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + dimensions: + rank: 1 + dim: [[1, 3]] + orientation_matrix(NX_FLOAT): + doc: | + Orientation matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + dimensions: + rank: 3 + dim: [[1, 3], [2, 3], [3, 3]] + ub_matrix(NX_FLOAT): + doc: | + UB matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is + the multiplication of the orientation_matrix, given above, + with the :math:`B` matrix which + can be derived from the lattice constants. + dimensions: + rank: 3 + dim: [[1, 3], [2, 3], [3, 3]] + (NXunit_cell): + doc: Unit cell of the material. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXsubstance.yaml b/contributed_definitions/nyaml/NXsubstance.yaml new file mode 100644 index 0000000000..d2128546bd --- /dev/null +++ b/contributed_definitions/nyaml/NXsubstance.yaml @@ -0,0 +1,41 @@ +category: base +doc: | + A form of matter with a constant, definite chemical composition. + Examples can be single chemical elements, chemical compunds, or alloys. +type: group +NXsubstance(NXobject): + chemical_name(NX_CHAR): + doc: | + Full chemical name of the sample + iupac_name(NX_CHAR): + doc: | + Name in the IUPAC system. + molecular_formula(NX_CHAR): + doc: | + The chemical formula specified using CIF conventions. + Abbreviated version of CIF standard:107 + + * 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. + molecular_mass(NX_FLOAT): + unit: NX_MASS + doc: | + Molecular mass of the substance. + chem_id_cas(NX_CHAR): + doc: | + CAS registry number of the sample chemical content. + inchi_key(NX_CHAR): + doc: | + inChi identifier. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXunit_cell.yaml b/contributed_definitions/nyaml/NXunit_cell.yaml new file mode 100644 index 0000000000..918b785fef --- /dev/null +++ b/contributed_definitions/nyaml/NXunit_cell.yaml @@ -0,0 +1,35 @@ +category: base +doc: | + Description of a unit cell, e.g. of a single crystalline material. + +type: group +NXunit_cell(NXobject): + class(NX_CHAR): + doc: | + In case it is all we know and we want to record/document it + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + space_group(NX_CHAR): + doc: | + Crystallographic space group + point_group(NX_CHAR): + doc: | + Crystallographic point group, deprecated if space_group presents + abc(NX_FLOAT): + unit: NX_LENGTH + doc: | + Crystallography unit cell parameters a, b, and c + dimensions: + dim: [[1, 3]] + alphabetagamma(NX_FLOAT): + unit: NX_ANGLE + doc: | + Crystallography unit cell parameters alpha, beta, and gamma + dimensions: + dim: [[1, 3]] + volume(NX_FLOAT): + unit: NX_VOLUME + doc: | + Volume of the unit cell + dimensions: + rank: 1 + dim: [[1, 3]] \ No newline at end of file From ddaaebf5ce77e9151617ceb13063b2565d5f32c3 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 24 Aug 2023 12:27:49 +0200 Subject: [PATCH 0197/1012] Fix NXsingle_crystal - Fix small error in intendation in NXsingle_crystal.yaml - Create nxdl once again --- .../NXsingle_crystal.nxdl.xml | 20 +++++++++++++------ .../nyaml/NXsingle_crystal.yaml | 2 +- 2 files changed, 15 insertions(+), 7 deletions(-) diff --git a/contributed_definitions/NXsingle_crystal.nxdl.xml b/contributed_definitions/NXsingle_crystal.nxdl.xml index 7981e06460..61e74b2829 100644 --- a/contributed_definitions/NXsingle_crystal.nxdl.xml +++ b/contributed_definitions/NXsingle_crystal.nxdl.xml @@ -37,19 +37,27 @@ - UB matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is - the multiplication of the orientation_matrix, given above, - with the :math:`B` matrix which - can be derived from the lattice constants. + Orientation matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - + + + UB matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is + the multiplication of the orientation_matrix, given above, + with the :math:`B` matrix which can be derived from the lattice constants. + + + + + + Unit cell of the material. diff --git a/contributed_definitions/nyaml/NXsingle_crystal.yaml b/contributed_definitions/nyaml/NXsingle_crystal.yaml index 212091cffd..76ba115284 100644 --- a/contributed_definitions/nyaml/NXsingle_crystal.yaml +++ b/contributed_definitions/nyaml/NXsingle_crystal.yaml @@ -18,7 +18,7 @@ NXsingle_crystal(NXobject): dimensions: rank: 3 dim: [[1, 3], [2, 3], [3, 3]] - ub_matrix(NX_FLOAT): + ub_matrix(NX_FLOAT): doc: | UB matrix of single crystal sample using Busing-Levy convention: W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is From 870f4559ba6a84c009c1f57f92a43f2a988b1517 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 24 Aug 2023 12:41:18 +0200 Subject: [PATCH 0198/1012] One more fix to NXsingle_crystal There a missing --- .../NXsingle_crystal.nxdl.xml | 17 +++++++++-------- .../nyaml/NXsingle_crystal.yaml | 3 +-- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/contributed_definitions/NXsingle_crystal.nxdl.xml b/contributed_definitions/NXsingle_crystal.nxdl.xml index 61e74b2829..889754b865 100644 --- a/contributed_definitions/NXsingle_crystal.nxdl.xml +++ b/contributed_definitions/NXsingle_crystal.nxdl.xml @@ -37,8 +37,8 @@ - Orientation matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + Orientation matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 @@ -46,18 +46,19 @@ - + - UB matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is - the multiplication of the orientation_matrix, given above, - with the :math:`B` matrix which can be derived from the lattice constants. + UB matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is + the multiplication of the orientation_matrix, given above, + with the :math:`B` matrix which can be derived from the lattice constants. - + + Unit cell of the material. diff --git a/contributed_definitions/nyaml/NXsingle_crystal.yaml b/contributed_definitions/nyaml/NXsingle_crystal.yaml index 76ba115284..ea0731911e 100644 --- a/contributed_definitions/nyaml/NXsingle_crystal.yaml +++ b/contributed_definitions/nyaml/NXsingle_crystal.yaml @@ -23,8 +23,7 @@ NXsingle_crystal(NXobject): UB matrix of single crystal sample using Busing-Levy convention: W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is the multiplication of the orientation_matrix, given above, - with the :math:`B` matrix which - can be derived from the lattice constants. + with the :math:`B` matrix which can be derived from the lattice constants. dimensions: rank: 3 dim: [[1, 3], [2, 3], [3, 3]] From b2521bbc81396f2c8d8ac4a24b7ab6c8005b82e8 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 25 Aug 2023 11:31:14 +0200 Subject: [PATCH 0199/1012] Start and end time in NXphysical_process --- contributed_definitions/nyaml/NXphysical_process.yaml | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/nyaml/NXphysical_process.yaml b/contributed_definitions/nyaml/NXphysical_process.yaml index 2fe4b91040..ecd9ad3a60 100644 --- a/contributed_definitions/nyaml/NXphysical_process.yaml +++ b/contributed_definitions/nyaml/NXphysical_process.yaml @@ -1,12 +1,15 @@ category: base doc: | A planned or unplanned process which results in physical changes in a specified material. - Examples include sample preparation, material transformation, or (partially) destrustive measurement. + Examples include sample preparation, material transformation, or (partially) destructive measurement. type: group NXphysical_process(NXobject): - date(NX_DATE_TIME): + start_time(NX_DATE_TIME): doc: | - Datetime when the physical process occured. + ISO 8601 formatted time code with local time zone offset to UTC information included when this physical process started. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC information included when this physical process ended. description(NX_CHAR): doc: | Short description of the physical process. \ No newline at end of file From 2a5653818edb0cc74a5b64354ad35bfd5a3357f5 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 25 Aug 2023 11:47:21 +0200 Subject: [PATCH 0200/1012] Fix docstring of NXsample_component --- contributed_definitions/nyaml/NXsample_component_set.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/nyaml/NXsample_component_set.yaml b/contributed_definitions/nyaml/NXsample_component_set.yaml index a388d764a5..3557a5303f 100644 --- a/contributed_definitions/nyaml/NXsample_component_set.yaml +++ b/contributed_definitions/nyaml/NXsample_component_set.yaml @@ -1,7 +1,7 @@ category: base doc: | - Set of sample components and their configuration. The idea here is to store all descriptors that - cannot be stored on the level of the individual sample component. + Set of sample components and their configuration. The idea here is to store all descriptors of the individual NXsample_components + that cannot be stored on the level of the individual sample component. symbols: doc: | DOC MISSING. From 3d75d65ab8ea4d435691093402a142102e0589dd Mon Sep 17 00:00:00 2001 From: rettigl Date: Fri, 25 Aug 2023 18:56:25 +0200 Subject: [PATCH 0201/1012] Version of NXmpes_arpes with correct layout, and preset names for axes --- contributed_definitions/NXmpes_arpes.nxdl.xml | 293 ++++++++++++++++++ .../nyaml/NXmpes_arpes.yaml | 103 +++--- 2 files changed, 348 insertions(+), 48 deletions(-) create mode 100644 contributed_definitions/NXmpes_arpes.nxdl.xml diff --git a/contributed_definitions/NXmpes_arpes.nxdl.xml b/contributed_definitions/NXmpes_arpes.nxdl.xml new file mode 100644 index 0000000000..80e8a949c4 --- /dev/null +++ b/contributed_definitions/NXmpes_arpes.nxdl.xml @@ -0,0 +1,293 @@ + + + + + + + This is an general application definition for angle-resolved multidimensional + photoelectron spectroscopy. + + + + + + + + + + + + + Link to transformations defining an APRES base coordinate system, which is + defined such that the positive z-axis points towards the analyzer entry, and the + x-axis lies within the beam/analyzer plane. + + + + + Set of transformations, describing the orientation of the ARPES coordinate + system with respect to the beam coordinate system (.). + + + + + + + + + + + Angular resolution of the electron analyser with the current setting. May be + linked from a NXcalibration. + + + + + Reference to the transformation describing the orientation of the analyzer + relative to the beam. + + + + + Set of transformations, describing the relative orientation of the analyzer with + respect to the beam coordinate system (.). + + + + + Rotation about the analyzer axis. This needs to be defined in the transformation + chain. + + + + + + + Scheme of the electron collection column. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Raw data before calibration. + + + + + + + + Document an event of data processing, reconstruction, or analysis for this data. + Describe the appropriate axis calibrations for your experiment using one or more + of the following NXcalibrations + + + + + Has an energy calibration been applied? + + + + + This is the calibrated energy axis to be used for data plotting. + + + + + + + Has an angular calibration been applied to dispersive axis 1? + + + + + This is the calibrated angular axis to be used for data plotting. + + + + + Reference to the transformation describing the orientation of the first + dispersed analyzer angle. + + + + + Set of transformations, describing the relation of the dispersing analyzer + angles and analyzer roations with respect to the reference coordinate system + (.). + + + + + + + Has an angular calibration been applied to dispersive axis 2? + + + + + This is the calibrated angular axis to be used for data plotting. + + + + + Reference to the transformation describing the orientation of the second + dispersed analyzer angle. + + + + + Set of transformations, describing the relation of the dispersing analyzer + angles and analyzer roations with respect to the reference coordinate system + (.). + + + + + + + + + + + + + + Reference to a transformation describing the orientation of the sample relative + to the beam coordinate system (.). + + + + + Set of transformations, describing the relative orientation of the sample with + respect to the beam coordinate system (.). + + + + + + + + + + + + + + + + + + + + Points to the path to a field defining the axis on which the angular axis + depends. For example: @angular1_depends: '/entry/sample/transformations/rot_phi' + for a manipulator angular scan @angular1_depends: + '/entry/instrument/detector/sensor_x' for a 2D detector @angular1_depends: + '/entry/instrument/collectioncolumn/deflector' for a deflector scan + @angular1_depends: + '/entry/process/calibration/angular1_calibration/calibrated_axis' for a + preprocessed axis. + + + + + Points to the path to a field defining the axis on which the angular axis + depends. For example: @angular2_depends: '/entry/sample/transformations/rot_tht' + for a manipulator angular scan @angular2_depends: + '/entry/instrument/detector/sensor_x' for a 2D detector @angular2_depends: + '/entry/instrument/collectioncolumn/deflector' for a deflector scan + @angular2_depends: + '/entry/process/calibration/angular2_calibration/calibrated_axis' for a + preprocessed axis. + + + + + Points to the path to a field defining the axis on which the energy axis + depends. For example: @energy_depends: '/entry/instrument/detector/sensor_y' for + a 2D detector @energy_depends: + '/entry/instrument/energydispersion/center_kinetic_energy' for a swept scan + @energy_depends: '/entry/process/calibration/energy_calibration/calibrated_axis' + for a preprocessed axis. + + + + + Trace of the energy axis. Could be linked from the respective 'AXISNAME_depends' + field. + + + + + Trace of the first angular axis. Could be linked from the respective + 'AXISNAME_depends' field. + + + + + Trace of the second axis. Could be linked from the respective 'AXISNAME_depends' + field. + + + + + Represents a measure of three-dimensional photoemission counts, where the varied + axes are energy, and one or more angular coordinates. Axes traces should be + linked to the actual encoder position in NXinstrument or calibrated axes in + NXprocess. + + + + + diff --git a/contributed_definitions/nyaml/NXmpes_arpes.yaml b/contributed_definitions/nyaml/NXmpes_arpes.yaml index 80007550d5..9fe34924ad 100644 --- a/contributed_definitions/nyaml/NXmpes_arpes.yaml +++ b/contributed_definitions/nyaml/NXmpes_arpes.yaml @@ -8,6 +8,7 @@ doc: This is an general application definition for angle-resolved multidimensional photoelectron spectroscopy. category: application NXmpes_arpes(NXmpes): + (NXentry): definition: \@version: enumeration: ["NXmpes_arpes"] @@ -19,22 +20,26 @@ NXmpes_arpes(NXmpes): doc: "Set of transformations, describing the orientation of the ARPES coordinate system with respect to the beam coordinate system (.)." (NXinstrument): angular_resolution(NX_FLOAT): + exists: recommended unit: NX_ANGLE - depends_on(NX_CHAR): - doc: "Reference to the transformation describing the orientation of the analyzer relative to the beam." - (NXtransformations): - doc: "Set of transformations, describing the relative orientation of the analyzer with respect to the beam coordinate system (.)." - # Do we need to require the existence/use of a particular rotation to determine slit orientation? - analyzer_rotation(NX_NUMBER): - doc: "Rotation about the analyzer axis. This needs to be defined in the transformation chain." (NXelectronanalyser): description: angular_resolution(NX_FLOAT): exists: recommended doc: "Angular resolution of the electron analyser with the current setting. May be linked from a NXcalibration." unit: NX_ANGLE + depends_on(NX_CHAR): + exists: recommended + doc: "Reference to the transformation describing the orientation of the analyzer relative to the beam." + (NXtransformations): + doc: "Set of transformations, describing the relative orientation of the analyzer with respect to the beam coordinate system (.)." + # Do we need to require the existence/use of a particular rotation to determine slit orientation? + analyzer_rotation(NX_NUMBER): + doc: "Rotation about the analyzer axis. This needs to be defined in the transformation chain." + unit: NX_ANGLE (NXcollectioncolumn): scheme: + exists: recommended doc: "Scheme of the electron collection column." enumeration: [ "Standard", @@ -43,6 +48,7 @@ NXmpes_arpes(NXmpes): ] (NXenergydispersion): scheme: + exists: recommended enumeration: ["hemispherical", "tof"] center_energy(NX_NUMBER): exists: recommended @@ -51,6 +57,7 @@ NXmpes_arpes(NXmpes): exists: recommended unit: NX_LENGTH entrance_slit(NXaperture): + exists: recommended shape: enumeration: [ "straight slit", @@ -61,39 +68,42 @@ NXmpes_arpes(NXmpes): data(NX_NUMBER): # Raw signal without calibrated axes. exists: recommended doc: "Raw data before calibration." - (NXprocess): - doc: "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" - energy_calibration(NXcalibration): - exists: optional - applied(NX_BOOLEAN): - doc: "Has an energy calibration been applied?" - calibrated_axis(NX_FLOAT): - exists: recommended - doc: "This is the calibrated energy axis to be used for data plotting." - angular1_calibration(NXcalibration): - exists: optional - applied(NX_BOOLEAN): - doc: "Has an angular calibration been applied to dispersive axis 1?" - calibrated_axis(NX_FLOAT): - exists: recommended - doc: "This is the calibrated angular axis to be used for data plotting." - depends_on(NX_CHAR): - doc: "Reference to the transformation describing the orientation of the first dispersed analyzer angle." - (NXtransformations): - doc: "Set of transformations, describing the relation of the dispersing analyzer angles and analyzer roations with respect to the reference coordinate system (.)." - angular2_calibration(NXcalibration): - exists: optional - applied(NX_BOOLEAN): - doc: "Has an angular calibration been applied to dispersive axis 2?" - calibrated_axis(NX_FLOAT): - exists: recommended - doc: "This is the calibrated angular axis to be used for data plotting." - depends_on(NX_CHAR): - doc: "Reference to the transformation describing the orientation of the second dispersed analyzer angle." - (NXtransformations): - doc: "Set of transformations, describing the relation of the dispersing analyzer angles and analyzer roations with respect to the reference coordinate system (.)." + (NXprocess): + exists: optional + doc: "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" + energy_calibration(NXcalibration): + exists: optional + applied(NX_BOOLEAN): + doc: "Has an energy calibration been applied?" + calibrated_axis(NX_FLOAT): + exists: recommended + doc: "This is the calibrated energy axis to be used for data plotting." + angular1_calibration(NXcalibration): + exists: optional + applied(NX_BOOLEAN): + doc: "Has an angular calibration been applied to dispersive axis 1?" + calibrated_axis(NX_FLOAT): + exists: recommended + doc: "This is the calibrated angular axis to be used for data plotting." + depends_on(NX_CHAR): + doc: "Reference to the transformation describing the orientation of the first dispersed analyzer angle." + (NXtransformations): + exists: recommended + doc: "Set of transformations, describing the relation of the dispersing analyzer angles and analyzer roations with respect to the reference coordinate system (.)." + angular2_calibration(NXcalibration): + exists: optional + applied(NX_BOOLEAN): + doc: "Has an angular calibration been applied to dispersive axis 2?" + calibrated_axis(NX_FLOAT): + exists: recommended + doc: "This is the calibrated angular axis to be used for data plotting." + depends_on(NX_CHAR): + doc: "Reference to the transformation describing the orientation of the second dispersed analyzer angle." + (NXtransformations): + exists: recommended + doc: "Set of transformations, describing the relation of the dispersing analyzer angles and analyzer roations with respect to the reference coordinate system (.)." (NXsample): situation: enumeration: ["vacuum"] @@ -110,20 +120,14 @@ NXmpes_arpes(NXmpes): \@energy_indices: # energy indices have to be provided \@angular1_indices: # angular1 indices have to be provided \@angular2_indices: # angular2 indices have to be provided - \@angular1_depends(NX_CHAR): # In ARPES, the angular coordinate can be generated in different ways. - # It can be a detector axis in a 2D detector, or scanned by changing the angle of a manipulator. - # We propose a structure similar to depends_on(NX_CHAR) of NXtransformations to reconstruct the - # metadata path that produced the angular coordinate. This allows to reconstruct the geometry programmatically. + \@angular1_depends(NX_CHAR): doc: "Points to the path to a field defining the axis on which the angular axis depends. For example: @angular1_depends: '/entry/sample/transformations/rot_phi' for a manipulator angular scan @angular1_depends: '/entry/instrument/detector/sensor_x' for a 2D detector @angular1_depends: '/entry/instrument/collectioncolumn/deflector' for a deflector scan @angular1_depends: '/entry/process/calibration/angular1_calibration/calibrated_axis' for a preprocessed axis." - \@angular2_depends(NX_CHAR): # In ARPES, the angular coordinate can be generated in different ways. - # It can be a detector axis in a 2D detector, or scanned by changing the angle of a manipulator. - # We propose a structure similar to depends_on(NX_CHAR) of NXtransformations to reconstruct the - # metadata path that produced the angular coordinate. This allows to reconstruct the geometry programmatically. + \@angular2_depends(NX_CHAR): doc: "Points to the path to a field defining the axis on which the angular axis depends. For example: @angular2_depends: '/entry/sample/transformations/rot_tht' for a manipulator angular scan @@ -138,10 +142,13 @@ NXmpes_arpes(NXmpes): @energy_depends: '/entry/process/calibration/energy_calibration/calibrated_axis' for a preprocessed axis." energy(NX_NUMBER): doc: "Trace of the energy axis. Could be linked from the respective 'AXISNAME_depends' field." + unit: NY_ENERGY angular1(NX_NUMBER): doc: "Trace of the first angular axis. Could be linked from the respective 'AXISNAME_depends' field." + unit: NX_ANGLE angular2(NX_NUMBER): doc: "Trace of the second axis. Could be linked from the respective 'AXISNAME_depends' field." + unit: ANX_ANGLE data(NX_NUMBER): # There is a block of numbers named data. doc: "Represents a measure of three-dimensional photoemission counts, where the varied axes are energy, and one or more angular coordinates. Axes traces From 070df544315076bc30cf1815c4253993df877fe9 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 28 Aug 2023 17:40:39 +0200 Subject: [PATCH 0202/1012] Initial commit of new and changed yaml files New base classes: - NXcrystal_structure - NXrotation_set - NXsingle_crystal - NXunit_cell --- base_classes/nyaml/NXsample.yaml | 343 ++++++++++++++++++ base_classes/nyaml/NXsample_component.yaml | 120 ++++++ .../nyaml/NXcrystal_structure.yaml | 156 ++++++++ .../nyaml/NXrotation_set.yaml | 162 +++++++++ .../nyaml/NXsingle_crystal.yaml | 32 ++ .../nyaml/NXunit_cell.yaml | 35 ++ 6 files changed, 848 insertions(+) create mode 100644 base_classes/nyaml/NXsample.yaml create mode 100644 base_classes/nyaml/NXsample_component.yaml create mode 100644 contributed_definitions/nyaml/NXcrystal_structure.yaml create mode 100644 contributed_definitions/nyaml/NXrotation_set.yaml create mode 100644 contributed_definitions/nyaml/NXsingle_crystal.yaml create mode 100644 contributed_definitions/nyaml/NXunit_cell.yaml diff --git a/base_classes/nyaml/NXsample.yaml b/base_classes/nyaml/NXsample.yaml new file mode 100644 index 0000000000..79e0ac80df --- /dev/null +++ b/base_classes/nyaml/NXsample.yaml @@ -0,0 +1,343 @@ +category: base +doc: | + 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. +symbols: + doc: | + symbolic array lengths to be coordinated between various fields + n_comp: | + number of compositions + n_Temp: | + number of temperatures + n_eField: | + number of values in applied electric field + n_mField: | + number of values in applied magnetic field + n_pField: | + number of values in applied pressure field + n_sField: | + number of values in applied stress field +type: group +NXsample(NXobject): + name: + doc: | + Descriptive name of sample + chemical_formula: + doc: | + 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. + temperature(NX_FLOAT): + unit: NX_TEMPERATURE + doc: | + Sample temperature. This could be a scanned variable + dimensions: + rank: anyRank + + # could be any length + dim: [[1, n_Temp]] + electric_field(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Applied electric field + dimensions: + + # could be any length + dim: [[1, n_eField]] + \@direction: + enumeration: [x, y, z] + magnetic_field(NX_FLOAT): + unit: NX_ANY + doc: | + Applied magnetic field + dimensions: + + # could be any length + dim: [[1, n_mField]] + \@direction: + enumeration: [x, y, z] + stress_field(NX_FLOAT): + unit: NX_ANY + doc: | + Applied external stress field + dimensions: + + # could be any length + dim: [[1, n_sField]] + \@direction: + enumeration: [x, y, z] + pressure(NX_FLOAT): + unit: NX_PRESSURE + doc: | + Applied pressure + dimensions: + + # could be any length + dim: [[1, n_pField]] + changer_position(NX_INT): + unit: NX_UNITLESS + doc: | + Sample changer position + unit_cell_abc(NX_FLOAT): + unit: NX_LENGTH + doc: | + Crystallography unit cell parameters a, b, and c + dimensions: + dim: [[1, 3]] + unit_cell_alphabetagamma(NX_FLOAT): + unit: NX_ANGLE + doc: | + Crystallography unit cell parameters alpha, beta, and gamma + dimensions: + dim: [[1, 3]] + unit_cell(NX_FLOAT): + unit: NX_LENGTH + doc: | + Unit cell parameters (lengths and angles) + dimensions: + rank: 2 + dim: [[1, n_comp], [2, 6]] + unit_cell_volume(NX_FLOAT): + unit: NX_VOLUME + doc: | + Volume of the unit cell + dimensions: + rank: 1 + dim: [[1, n_comp]] + sample_orientation(NX_FLOAT): + unit: NX_ANGLE + doc: | + This will follow the Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + dimensions: + rank: 1 + dim: [[1, 3]] + orientation_matrix(NX_FLOAT): + doc: | + Orientation matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + dimensions: + rank: 3 + dim: [[1, n_comp], [2, 3], [3, 3]] + ub_matrix(NX_FLOAT): + doc: | + UB matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is + the multiplication of the orientation_matrix, given above, + with the :math:`B` matrix which + can be derived from the lattice constants. + dimensions: + rank: 3 + dim: [[1, n_comp], [2, 3], [3, 3]] + mass(NX_FLOAT): + unit: NX_MASS + doc: | + Mass of sample + dimensions: + rank: 1 + dim: [[1, n_comp]] + density(NX_FLOAT): + unit: NX_MASS_DENSITY + doc: | + Density of sample + dimensions: + rank: 1 + dim: [[1, n_comp]] + relative_molecular_mass(NX_FLOAT): + unit: NX_MASS + doc: | + Relative Molecular Mass of sample + dimensions: + rank: 1 + dim: [[1, n_comp]] + type: + enumeration: [sample, sample+can, can, sample+buffer, buffer, calibration sample, normalisation sample, simulated data, none, sample environment] + situation: + doc: | + 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. + enumeration: [air, vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere, sealed can, other] + description: + doc: | + Description of the sample + preparation_date(NX_DATE_TIME): + doc: | + Date of preparation of the sample + geometry(NXgeometry): + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the sample and NXoff_geometry to describe its shape instead + doc: | + The position and orientation of the center of mass of the sample + (NXbeam): + doc: | + Details of beam incident on sample - used to calculate sample/beam interaction point + (NXsample_component): + doc: | + One group per sample component + This is the perferred way of recording per component information over the n_comp arrays + component: + doc: | + Details of the component of the sample and/or can + dimensions: + rank: 1 + dim: [[1, n_comp]] + sample_component: + doc: | + Type of component + dimensions: + rank: 1 + dim: [[1, n_comp]] + enumeration: [sample, can, atmosphere, kit] + concentration(NX_FLOAT): + unit: NX_MASS_DENSITY + doc: | + Concentration of each component + dimensions: + rank: 1 + dim: [[1, n_comp]] + volume_fraction(NX_FLOAT): + doc: | + Volume fraction of each component + dimensions: + rank: 1 + dim: [[1, n_comp]] + scattering_length_density(NX_FLOAT): + unit: NX_SCATTERING_LENGTH_DENSITY + doc: | + Scattering length density of each component + dimensions: + rank: 1 + dim: [[1, n_comp]] + unit_cell_class: + doc: | + In case it is all we know and we want to record/document it + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + space_group: + doc: | + Crystallographic space group + dimensions: + dim: [[1, n_comp]] + point_group: + doc: | + Crystallographic point group, deprecated if space_group present + dimensions: + dim: [[1, n_comp]] + path_length(NX_FLOAT): + unit: NX_LENGTH + doc: | + Path length through sample/can for simple case when + it does not vary with scattering direction + path_length_window(NX_FLOAT): + unit: NX_LENGTH + doc: | + Thickness of a beam entry/exit window on the can (mm) + - assumed same for entry and exit + thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + sample thickness + transmission(NXdata): + doc: | + As a function of Wavelength + (NXcrystal_structure): + doc: | + Description of crystal structure of the sample. + temperature_log(NXlog): + deprecated: | + use ``temperature``, see: https://github.com/nexusformat/definitions/issues/816 + doc: | + temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value + temperature_env(NXenvironment): + doc: | + Additional sample temperature environment information + magnetic_field(NXlog): + doc: | + magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value + magnetic_field_log(NXlog): + deprecated: | + use ``magnetic_field``, see: https://github.com/nexusformat/definitions/issues/816 + doc: | + magnetic_field_log.value is a link to e.g. magnetic_field_env.sensor1.value_log.value + magnetic_field_env(NXenvironment): + doc: | + Additional sample magnetic environment information + external_DAC(NX_FLOAT): + unit: NX_ANY + doc: | + value sent to user's sample setup + external_ADC(NXlog): + doc: | + logged value (or logic state) read from user's setup + short_title: + doc: | + 20 character fixed length sample description for legends + + # How is the string length limitation imposed by the XSD? + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Optional rotation angle for the case when the powder diagram has + been obtained through an omega-2theta scan like from a traditional + single detector powder diffractometer. + Note, it is recommended to use NXtransformations instead. + x_translation(NX_FLOAT): + unit: NX_LENGTH + doc: | + Translation of the sample along the X-direction of the laboratory coordinate system + Note, it is recommended to use NXtransformations instead. + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + Translation of the sample along the Z-direction of the laboratory coordinate system. + Note, it is recommended to use NXtransformations instead. + (NXpositioner): + doc: | + Any positioner (motor, PZT, ...) used to locate the sample + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the sample + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + 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. + (NXtransformations): + doc: | + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. \ No newline at end of file diff --git a/base_classes/nyaml/NXsample_component.yaml b/base_classes/nyaml/NXsample_component.yaml new file mode 100644 index 0000000000..154adb6760 --- /dev/null +++ b/base_classes/nyaml/NXsample_component.yaml @@ -0,0 +1,120 @@ +category: base +doc: | + One group like this per component can be recorded For a sample consisting of multiple components. +symbols: + doc: | + symbolic array lengths to be coordinated between various fields + n_Temp: | + number of temperatures + n_eField: | + number of values in applied electric field + n_mField: | + number of values in applied magnetic field + n_pField: | + number of values in applied pressure field + n_sField: | + number of values in applied stress field +type: group +NXsample_component(NXobject): + name: + doc: | + Descriptive name of sample component + chemical_formula: + doc: | + 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. + unit_cell_abc(NX_FLOAT): + unit: NX_LENGTH + doc: | + Crystallography unit cell parameters a, b, and c + dimensions: + dim: [[1, 3]] + unit_cell_alphabetagamma(NX_FLOAT): + unit: NX_ANGLE + doc: | + Crystallography unit cell parameters alpha, beta, and gamma + dimensions: + dim: [[1, 3]] + unit_cell_volume(NX_FLOAT): + unit: NX_VOLUME + doc: | + Volume of the unit cell + sample_orientation(NX_FLOAT): + unit: NX_ANGLE + doc: | + This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) + dimensions: + rank: 1 + dim: [[1, 3]] + orientation_matrix(NX_FLOAT): + doc: | + Orientation matrix of single crystal sample component. + This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) + dimensions: + rank: 2 + dim: [[1, 3], [2, 3]] + mass(NX_FLOAT): + unit: NX_MASS + doc: | + Mass of sample component + density(NX_FLOAT): + unit: NX_MASS_DENSITY + doc: | + Density of sample component + relative_molecular_mass(NX_FLOAT): + unit: NX_MASS + doc: | + Relative Molecular Mass of sample component + description: + doc: | + Description of the sample component + volume_fraction(NX_FLOAT): + doc: | + Volume fraction of component + scattering_length_density(NX_FLOAT): + unit: NX_SCATTERING_LENGTH_DENSITY + doc: | + Scattering length density of component + unit_cell_class: + doc: | + In case it is all we know and we want to record/document it + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + space_group: + doc: | + Crystallographic space group + point_group: + doc: | + Crystallographic point group, deprecated if space_group present + transmission(NXdata): + doc: | + As a function of Wavelength + (NXcrystal_structure): + doc: | + Description of crystal structure of the sample. + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml new file mode 100644 index 0000000000..f9e1f8e848 --- /dev/null +++ b/contributed_definitions/nyaml/NXcrystal_structure.yaml @@ -0,0 +1,156 @@ +# in the long run this base class should be refactored based on feedback from +# other diffraction methods to arrive maybe at an NXem_crystal_structure_model_ebsd_parsed.yaml +category: base +doc: | + Crystal structure phase models used for indexing Kikuchi pattern. + + This base class contains key metadata relevant to every physical + kinematic or dynamic diffraction model which is used for simulating + Kikuchi diffraction pattern. + The actual indexing of Kikuchi patterns may use different algorithms. + Such are used within different workflows where simulated and measured + Kikuchi pattern are compared to rate which phase and orientation is the most + likely candidate describing the pattern measured at that each scan point + respectively. If this evaluation yields scan points without any solutions, + these are represented using the null-phase model phase0, aka n/a aka notIndexed. + + Traditionally, Hough transformation-based indexing has been the most frequently + used algorithm. Dictionary-based alternatives are emerging. +symbols: + n_hkl: | + Number of reflectors (Miller crystallographic plane triplets). + n_pos: | + Number of atom positions. +type: group +NXem_ebsd_crystal_structure_model(NXobject): + # for EBSD specifically we need to know the assumed crystal structure + # with assumed statistically distributed atoms, i.e. structure and atom + # positions + crystallographic_database_identifier: + doc: | + Identifier of an entry resolvable via crystallographic_database + which was used for creating this structure model. + crystallographic_database: + doc: | + Name of the crystallographic database to resolve + crystallographic_database_identifier e.g. COD, ICSD, or others. + + # defined using which convention? + unit_cell_abc(R+): + unit: NX_LENGTH + doc: | + Crystallography unit cell parameters a, b, and c. + dim: (3,) + # defined using which convention? + unit_cell_alphabetagamma(R+): + unit: NX_ANGLE + doc: | + Crystallography unit cell parameters alpha, beta, and gamma. + dim: (3,) + unit_cell_volume(R+): + unit: NX_VOLUME + doc: | + Volume of the unit cell + space_group: + doc: | + Crystallographic space group + # add enumeration of all possible + is_centrosymmetric(NX_BOOLEAN): + doc: | + True if space group is considered a centrosymmetric one. + False if space group is considered a non-centrosymmetric one. + Centrosymmetric has all types and combinations of symmetry elements + (translation, rotational axis, mirror planes, center of inversion) + Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). + Chiral compared to non-centrosymmetric is constrained (no mirror planes). + is_chiral(NX_BOOLEAN): + doc: | + True if space group is considered a chiral one. + False if space group is consider a non-chiral one. + laue_group: + doc: | + Laue group + # add enumeration of all possible + point_group: + doc: | + Point group using International Notation. + # add enumeration all possible + unit_cell_class: + doc: | + Crystal system + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + phase_identifier(N0): + unit: NX_UNITLESS + doc: | + Identifier for each phase. The value 0 is reserved for the unknown phase + which represents the null-model that no phase model was sufficiently + significantly confirmed, i.e. the phase_name is n/a or notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + NXem_ebsd_crystal_structure_model named phase0 and phase1 + should be stored in the HDF5 file. + phase_name: + doc: | + Name of the phase/alias. + In the case that the NXem_ebsd_crystal_structure_model base class is + used with analyzed orientation maps (e.g. NXms_ipf instances or alike) + this field may have the value **n/a** or equivalently **notIndexed** + thereby reporting the null-model the unknown phase. + atom_identifier: + doc: | + Labels for each atom position + dim: (n_pos,) + atom(N0): + unit: NX_UNITLESS + doc: | + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) `_ + dim: (n_pos,) + atom_positions(R): + unit: NX_LENGTH + doc: | + Atom positions x, y, z. + dim: (n_pos, 3) + depends_on: + doc: | + Reference to an instance of NXcoordinate_system + whereby the positions can be resolved. + # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory + # to describe the simulated Kikuchi pattern generated from such a model + atom_occupancy(R+0): + unit: NX_DIMENSIONLESS + doc: | + Relative occupancy of the atom position. + dim: (n_pos,) + number_of_planes(N): + unit: NX_UNITLESS + doc: | + How many reflectors are distinguished. Value has to + match value for symbol n_hkl. + # Miller indices :math:`(hkl)[uvw]`. + plane_miller(R): + unit: NX_UNITLESS + doc: | + Miller indices :math:`(hkl)`. + dim: (n_hkl, 3) + dspacing(R+0): + unit: NX_LENGTH + doc: | + D-spacing. + dim: (n_hkl,) + relative_intensity(R+0): + unit: NX_DIMENSIONLESS + doc: | + Relative intensity of the signal for the plane. + dim: (n_hkl,) + number_of_scan_points(N0): + unit: NX_UNITLESS + doc: | + In case the NXem_ebsd_crystal_structure_model base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + (NXms_ipf): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXrotation_set.yaml b/contributed_definitions/nyaml/NXrotation_set.yaml new file mode 100644 index 0000000000..4f0634d86a --- /dev/null +++ b/contributed_definitions/nyaml/NXrotation_set.yaml @@ -0,0 +1,162 @@ +category: base +doc: | + Base class to detail a set of rotations, orientations, and disorientations. + + For getting a more detailed insight into the discussion of the + parameterized description of orientations in materials science see: + + * `H.-J. Bunge `_ + * `T. B. Britton et al. `_ + * `D. Rowenhorst et al. `_ + * `A. Morawiec `_ + + Once orientations are defined one can continue to characterize the + misorientation and specifically the disorientation which describes the + rotation that is required to register the lattices of two oriented objects + (like crystal lattice) into a crystallographic equivalent orientation: + + * `R. Bonnet `_ + + Based on the idea of this NXorientation_set one could equally formulate + an NXdisorientation_set. + +# This class stores a set of specifically parameterized NXtransformations which describe +# how each object is oriented/rotated with respect to a reference coordinate system. +# we should offer here support for d==2, d==3 +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + c: | + The cardinality of the set, i.e. the number of value tuples. +type: group +NXrotation_set(NXobject): + depends_on: + doc: | + Reference to an instance of NXem_conventions which contextualizes + how the here reported parameterized quantities can be interpreted. + # 2D rotations are a special type of 3D rotations and thus treated in 3D + # just how to rotate the object into the reference frame defined by depends_on + crystal_symmetry: + doc: | + Point group which defines the symmetry of the crystal. + This has to be at least a single string. + In the case that misorientation or disorientation fields are used + and the two crystal sets resolve for phases with a different + crystal symmetry, this field has to encode two string. + In this case the first string is for phase A the second one for phase B. + An example of this most complex case is the description of the + disorientation between crystals adjoining a hetero-phase boundary. + # how to encode the above (2,) string array or single string constraint + sample_symmetry: + doc: | + Point group which defines an assumed symmetry imprinted upon processing + the material/sample which could give rise to or may justify to use a + simplified description of rotations, orientations, misorientations, + and disorientations via numerical procedures known as symmetrization. + + The traditionally used symmetrization operations within the texture + community in Materials Science, though, are thanks to methodology and + software improvements no longer strictly needed. Therefore, users are + encouraged to set the sample_symmetry to 1 (triclinic) and thus assume + there is no implied additional processing symmetry imprinted. + + In practice one often faces situations where indeed these assumed + symmetries are anyway not fully observed and thus an accepting of + eventual inaccuracies just for the sake of reporting a simplified + symmetrized description can be avoided. + rotation_quaternion(R): # H \in SO3 + unit: NX_DIMENSIONLESS + doc: | + The set of rotations expressed in quaternion representation. The assumed + crystal and sample symmetry point group is 1, triclinic. Rotations which + should be interpreted as antipodal are not marked as such. + dim: (c, 4) + rotation_euler(R): + unit: NX_ANGLE + doc: | + The set of rotations expressed in Euler angle representation following + the same applied symmetries as explained for rotation_quaternion. + To interpret Euler angles correctly it is necessary to inspect the + conventions behind depends_on to resolve which of the many Euler-angle + conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. + dim: (c, 3) + # rotation_rodrigues(R): + # rotation_homochoric(R): + # rotation_axis_angle(R): + + # orientation how to rotate the crystal into sample and vice versa obeying crystal and sample symmetry + is_antipodal(NX_BOOLEAN): + doc: | + True for all those values which are considered antipodal, + false for those which are not considered antipodal. + dim: (c,) + orientation_quaternion(R): + unit: NX_DIMENSIONLESS + doc: | + The set of orientations expressed in quaternion representation and + obeying symmetry for equivalent cases as detailed in crystal_symmetry + and sample_symmetry. The supplementary field is_antipodal can be used + to mark orientations which are antipodal. + dim: (c, 4) + orientation_euler(R): + unit: NX_ANGLE + doc: | + The set of orientations expressed in Euler angle representation following + the same assumptions like for orientation_quaternion. + To interpret Euler angles correctly it is necessary to inspect the + conventions behind depends_on to resolve which of the many Euler-angle + conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. + dim: (c, 3) + # orientation_rodrigues(R): + # orientation_homochoric(R): + # orientation_axis_angle(R): + + # misorientation between two orientations, ignoring if the angular argument + # is smallest. + misorientation_quaternion(R): + unit: NX_DIMENSIONLESS + doc: | + The set of misorientations expressed in quaternion representation and + obeying symmetry operations for equivalent misorientations + as defined by crystal_symmetry and sample_symmetry. + dim: (c, 4) + misorientation_angle(R): + unit: NX_ANGLE + doc: | + Misorientation angular argument (eventually signed) following the same + symmetry assumptions as expressed for the field misorientation_quaternion. + dim: (c,) + misorientation_axis(R): + unit: NX_DIMENSIONLESS + doc: | + Misorientation axis (normalized) and signed following the same + symmetry assumptions as expressed for the field misorientation_angle. + dim: (c, 3) + + # disorientation, misorientation with smallest angular argument inside + # fundamental zone of SO3 for given crystal and sample symmetry + disorientation_quaternion(R): + unit: NX_DIMENSIONLESS + doc: | + The set of disorientation expressed in quaternion representation and + obeying symmetry operations for equivalent misorientations + as defined by crystal_symmetry and sample_symmetry. + disorientation_angle(R): + unit: NX_ANGLE + doc: | + Disorientation angular argument (should not be signed, see + `D. Rowenhorst et al. `_) + following the same symmetry assumptions as expressed for the field + disorientation_quaternion. + dim: (c,) + disorientation_axis(R): + unit: NX_DIMENSIONLESS + doc: | + Disorientation axis (normalized) following the same symmetry assumptions + as expressed for the field disorientation_quaternion. + dim: (c, 3) + # e.g. in this way one could easily, efficiently, store and map familiar habits of microscopists + # to store e.g. orientations of measurement points or of grains via a (c := Ngrains, n_p := 3) + # matrix of Bunge-Euler angles, or of (c := Ngrains, n_p := 4) matrix of quaternions. + + # the benefit of such a representation is that with a known NXorientation_set base class one can implement a common parameterization transformation library (of which several already exist) in the microstructure modelling communities so that a program can read the information in the (NXorientation_set) instance and automatically transform/compute between different parameterizations. Super relevant for interoperability e.g. in SEM/EBSD, where this was a long standing issue and right now the most frequently accepted consensus is to report either Bunge-Euler angles or quaternions and then use existent transformation libraries (as implemented by e.g. Marc de Graeff for SEM/EBSD and used by many but not yet the majority of people in the computational materials modelling community within crystal plasticity, crystal growth modeling, DREAM.3D) \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXsingle_crystal.yaml b/contributed_definitions/nyaml/NXsingle_crystal.yaml new file mode 100644 index 0000000000..27a193423a --- /dev/null +++ b/contributed_definitions/nyaml/NXsingle_crystal.yaml @@ -0,0 +1,32 @@ +category: base +doc: | + Description of a single crystal material or a single crystalline phase in a material. +type: group +NXsingle_crystal(NXobject): + sample_orientation(NX_FLOAT): + unit: NX_ANGLE + doc: | + This will follow the Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + dimensions: + rank: 1 + dim: [[1, 3]] + orientation_matrix(NX_FLOAT): + doc: | + Orientation matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + dimensions: + rank: 3 + dim: [[1, 3], [2, 3], [3, 3]] + ub_matrix(NX_FLOAT): + doc: | + UB matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is + the multiplication of the orientation_matrix, given above, + with the :math:`B` matrix which + can be derived from the lattice constants. + dimensions: + rank: 3 + dim: [[1, 3], [2, 3], [3, 3]] + (NXunit_cell): + doc: Unit cell of the material. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXunit_cell.yaml b/contributed_definitions/nyaml/NXunit_cell.yaml new file mode 100644 index 0000000000..e12886486b --- /dev/null +++ b/contributed_definitions/nyaml/NXunit_cell.yaml @@ -0,0 +1,35 @@ +category: base +doc: | + Description of a unit cell, e.g. of a single crystalline material. + +type: group +NXunit_cell(NXobject): + class(NX_CHAR): + doc: | + In case it is all we know and we want to record/document it + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + space_group(NX_CHAR): + doc: | + Crystallographic space group + point_group(NX_CHAR): + doc: | + Crystallographic point group, deprecated if space_group presents + abc(NX_FLOAT): + unit: NX_LENGTH + doc: | + Crystallography unit cell parameters a, b, and c + dimensions: + dim: [[1, 3]] + alphabetagamma(NX_FLOAT): + unit: NX_ANGLE + doc: | + Crystallography unit cell parameters alpha, beta, and gamma + dimensions: + dim: [[1, 3]] + volume(NX_FLOAT): + unit: NX_VOLUME + doc: | + Volume of the unit cell + dimensions: + rank: 1 + dim: [[1, 3]] \ No newline at end of file From 5ef3ee927ce2eb729e88cc3c56cc8536f92b7ad9 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 29 Aug 2023 11:27:15 +0200 Subject: [PATCH 0203/1012] Remove non-needed base classes --- .../nyaml/NXsample_without_deprecated.yaml | 170 ------------------ .../NXphysical_process.nxdl.xml | 39 ---- .../NXsample_component_set.nxdl.xml | 73 -------- .../NXsample_history.nxdl.xml | 44 ----- .../NXsample_substrate.nxdl.xml | 71 -------- .../NXsample_surface_dopant.nxdl.xml | 38 ---- .../NXsample_synthesis_step.nxdl.xml | 35 ---- .../NXsingle_crystal.nxdl.xml | 67 ------- contributed_definitions/NXsubstance.nxdl.xml | 75 -------- contributed_definitions/NXunit_cell.nxdl.xml | 76 -------- .../nyaml/NXsample_substrate.yaml | 103 ----------- .../nyaml/NXsample_surface_dopant.yaml | 13 -- .../nyaml/NXsingle_crystal.yaml | 31 ---- 13 files changed, 835 deletions(-) delete mode 100644 base_classes/nyaml/NXsample_without_deprecated.yaml delete mode 100644 contributed_definitions/NXphysical_process.nxdl.xml delete mode 100644 contributed_definitions/NXsample_component_set.nxdl.xml delete mode 100644 contributed_definitions/NXsample_history.nxdl.xml delete mode 100644 contributed_definitions/NXsample_substrate.nxdl.xml delete mode 100644 contributed_definitions/NXsample_surface_dopant.nxdl.xml delete mode 100644 contributed_definitions/NXsample_synthesis_step.nxdl.xml delete mode 100644 contributed_definitions/NXsingle_crystal.nxdl.xml delete mode 100644 contributed_definitions/NXsubstance.nxdl.xml delete mode 100644 contributed_definitions/NXunit_cell.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXsample_substrate.yaml delete mode 100644 contributed_definitions/nyaml/NXsample_surface_dopant.yaml delete mode 100644 contributed_definitions/nyaml/NXsingle_crystal.yaml diff --git a/base_classes/nyaml/NXsample_without_deprecated.yaml b/base_classes/nyaml/NXsample_without_deprecated.yaml deleted file mode 100644 index 36d28018e4..0000000000 --- a/base_classes/nyaml/NXsample_without_deprecated.yaml +++ /dev/null @@ -1,170 +0,0 @@ -category: base -doc: | - 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. - However, this information is ideally stored in a dedicated NXenvironment on the application definition level. -type: group -NXsample(NXobject): - name: - doc: | - Descriptive name of sample - description: - doc: | - Description of the sample - short_title: - doc: | - 20 character fixed length sample description for legends - # How is the string length limitation imposed by the XSD? - sample_id(NX_CHAR): - doc: | - Identification number or signatures of the sample used. - mass(NX_FLOAT): - unit: NX_MASS - doc: | - Mass of sample - density(NX_FLOAT): - unit: NX_MASS_DENSITY - doc: | - Density of sample - type: - # This is neither complete nor should all of these enumerate options be here. - enumeration: [sample, sample+can, can, sample+buffer, buffer, calibration sample, normalisation sample, simulated data, none, sample environment] - thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - sample thickness - path_length(NX_FLOAT): - unit: NX_LENGTH - doc: | - Path length through sample/can for simple case when - it does not vary with scattering direction - path_length_window(NX_FLOAT): - unit: NX_LENGTH - doc: | - Thickness of a beam entry/exit window on the can (mm) - - assumed same for entry and exit - (NXsample_synthesis_step): - doc: - Information about a sample synthesis step. - (NXbeam): - doc: | - Details of beam incident on sample - used to calculate sample/beam interaction point - (NXsample_component): - doc: | - One group per sample component - This is the perferred way of recording per component information over the n_comp arrays - (NXsample_component_set): - doc: | - Set of sample components and their configuration. - (NXsample_history): - doc: | - A set of physical processes that occurred to the sample prior/during experiment. - (NXsubstance): - doc: | - Any substance contained in the sample. - (NXfabrication): - doc: | - Details about the sample vendor (company or research group) - (NXsample_substrate): - doc: | - Information about the material of the substrate in direct contact with the sample. - Could be a sample holder for example. - (NXenvironment): - # eventually, this should be stored in the application definitions - doc: | - Any environmental or external stimuli/measurements. - These can include, among others: - applied pressure, surrounding gas phase and gas pressure, - external electric/magnetic/stress fields, temperature, ... - notes(NXnote): - doc: | - Further notes. - transmission(NXdata): - doc: | - As a function of Wavelength - (NXpositioner): - doc: | - Any positioner (motor, PZT, ...) used to locate the sample - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the sample - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - 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. - (NXtransformations): - doc: | - 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. - -# Still here, should eventually be deprecated. - relative_molecular_mass(NX_FLOAT): - unit: NX_MASS - doc: | - Relative Molecular Mass of sample - changer_position(NX_INT): - unit: NX_UNITLESS - doc: | - Sample changer position - Note, it is recommended to use NXpositioner instead. - state(NX_CHAR): - doc: | - Physical state of the sample. Should be described in more detail. - purity(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Chemical purity of the sample - temperature_log(NXlog): - deprecated: | - use ``temperature``, see: https://github.com/nexusformat/definitions/issues/816 - doc: | - temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value - temperature_env(NXenvironment): - doc: | - Additional sample temperature environment information - Note, it is recommended to have NXenvironment as a stand-alone in the application definition. - magnetic_field(NXlog): - doc: | - magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value - magnetic_field_env(NXenvironment): - doc: | - Additional sample magnetic environment information - Note, it is recommended to have NXenvironment as a stand-alone in the application definition. - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Optional rotation angle for the case when the powder diagram has - been obtained through an omega-2theta scan like from a traditional - single detector powder diffractometer. - Note, it is recommended to use NXtransformations instead. - x_translation(NX_FLOAT): - unit: NX_LENGTH - doc: | - Translation of the sample along the X-direction of the laboratory coordinate system - Note, it is recommended to use NXtransformations instead. - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Translation of the sample along the Z-direction of the laboratory coordinate system. - Note, it is recommended to use NXtransformations instead. \ No newline at end of file diff --git a/contributed_definitions/NXphysical_process.nxdl.xml b/contributed_definitions/NXphysical_process.nxdl.xml deleted file mode 100644 index a98b9dd7ab..0000000000 --- a/contributed_definitions/NXphysical_process.nxdl.xml +++ /dev/null @@ -1,39 +0,0 @@ - - - - - - A planned or unplanned process which results in physical changes in a specified material. - Examples include sample preparation, material transformation, or (partially) destrustive measurement. - - - - Datetime when the physical process occured. - - - - - Short description of the physical process. - - - diff --git a/contributed_definitions/NXsample_component_set.nxdl.xml b/contributed_definitions/NXsample_component_set.nxdl.xml deleted file mode 100644 index e5deef356d..0000000000 --- a/contributed_definitions/NXsample_component_set.nxdl.xml +++ /dev/null @@ -1,73 +0,0 @@ - - - - - - - DOC MISSING. - - - - number of components - - - - - Set of sample components and their configuration. The idea here is to store all descriptors that - cannot be stored on the level of the individual sample component. - - - - Number of layers of the sample (e.g. bulk, monolayer, pentalayer, etc.) - - - - - Concentration of each component - - - - - - - - Volume fraction of each component - - - - - - - - Scattering length density of each component - - - - - - - - One such group per component - - - diff --git a/contributed_definitions/NXsample_history.nxdl.xml b/contributed_definitions/NXsample_history.nxdl.xml deleted file mode 100644 index a6a181e1c4..0000000000 --- a/contributed_definitions/NXsample_history.nxdl.xml +++ /dev/null @@ -1,44 +0,0 @@ - - - - - - A set of physical processes that occurred to the sample prior/during experiment. - Ideally, a full report of the previous operations, in the format of NXphysical_process. - Alternatively, notes allows for additional descriptors in any format. - - - - Any process that was performed on the sample prior or during the experiment. - Examples includ - - - - - A descriptor to keep track of the treatment of the sample before or during the - experiment (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - - - diff --git a/contributed_definitions/NXsample_substrate.nxdl.xml b/contributed_definitions/NXsample_substrate.nxdl.xml deleted file mode 100644 index 00bcf4adf1..0000000000 --- a/contributed_definitions/NXsample_substrate.nxdl.xml +++ /dev/null @@ -1,71 +0,0 @@ - - - - - - Any information on the sample substrate. - - - - Material of the substrate in direct contact with the sample. - - - - - Physical state of the substrate, similar options to sample state - - - - - Further notes. - - - - - Any substance contained in the sample substrate. - - - - - Name of the sample substrate vendor (company or research group) - - - - - 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. - - - - - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups - - - diff --git a/contributed_definitions/NXsample_surface_dopant.nxdl.xml b/contributed_definitions/NXsample_surface_dopant.nxdl.xml deleted file mode 100644 index d6df21d1f6..0000000000 --- a/contributed_definitions/NXsample_surface_dopant.nxdl.xml +++ /dev/null @@ -1,38 +0,0 @@ - - - - - - Description of a dopant material embedded in a sample surface. - - - - Element of evaporated surface dopant such as alkali or other - - - - - Nominal thickness of the evaporated dopant. - - - diff --git a/contributed_definitions/NXsample_synthesis_step.nxdl.xml b/contributed_definitions/NXsample_synthesis_step.nxdl.xml deleted file mode 100644 index 17a9f9e398..0000000000 --- a/contributed_definitions/NXsample_synthesis_step.nxdl.xml +++ /dev/null @@ -1,35 +0,0 @@ - - - - - - A planned or unplanned process which results in physical changes in a specified material. - Examples include sample preparation, material transformation, or (partially) destrustive measurement. - - - - Descriptor of the synthesis method. For sample growth method, this could include e. g. - molecular beam epitaxy, chemical vapor deposition etc. - - - diff --git a/contributed_definitions/NXsingle_crystal.nxdl.xml b/contributed_definitions/NXsingle_crystal.nxdl.xml deleted file mode 100644 index 889754b865..0000000000 --- a/contributed_definitions/NXsingle_crystal.nxdl.xml +++ /dev/null @@ -1,67 +0,0 @@ - - - - - - Description of a single crystal material or a single crystalline phase in a - material. - - - - This will follow the Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - - - - - - - - Orientation matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - - - - - - - - - - UB matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is - the multiplication of the orientation_matrix, given above, - with the :math:`B` matrix which can be derived from the lattice constants. - - - - - - - - - - Unit cell of the material. - - - diff --git a/contributed_definitions/NXsubstance.nxdl.xml b/contributed_definitions/NXsubstance.nxdl.xml deleted file mode 100644 index 6bad47dc4f..0000000000 --- a/contributed_definitions/NXsubstance.nxdl.xml +++ /dev/null @@ -1,75 +0,0 @@ - - - - - - A form of matter with a constant, definite chemical composition. - Examples can be single chemical elements, chemical compunds, or alloys. - - - - Full chemical name of the sample - - - - - Name in the IUPAC system. - - - - - The chemical formula specified using CIF conventions. - Abbreviated version of CIF standard:107 - - * 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. - - - - - Molecular mass of the substance. - - - - - CAS registry number of the sample chemical content. - - - - - inChi identifier. - - - diff --git a/contributed_definitions/NXunit_cell.nxdl.xml b/contributed_definitions/NXunit_cell.nxdl.xml deleted file mode 100644 index f669f78d55..0000000000 --- a/contributed_definitions/NXunit_cell.nxdl.xml +++ /dev/null @@ -1,76 +0,0 @@ - - - - - - Description of a unit cell, e.g. of a single crystalline material. - - - - In case it is all we know and we want to record/document it - - - - - - - - - - - - - - Crystallographic space group - - - - - Crystallographic point group, deprecated if space_group presents - - - - - Crystallography unit cell parameters a, b, and c - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma - - - - - - - - Volume of the unit cell - - - - - - diff --git a/contributed_definitions/nyaml/NXsample_substrate.yaml b/contributed_definitions/nyaml/NXsample_substrate.yaml deleted file mode 100644 index 3098c26d03..0000000000 --- a/contributed_definitions/nyaml/NXsample_substrate.yaml +++ /dev/null @@ -1,103 +0,0 @@ -category: base -doc: | - Any information on the sample substrate. -type: group -NXsample_substrate(NXobject): - material(NX_CHAR): - doc: | - Material of the substrate in direct contact with the sample. - state(NX_CHAR): - doc: | - Physical state of the substrate, similar options to sample state - notes(NXnote): - doc: | - Further notes. - (NXsubstance): - doc: | - Any substance contained in the sample substrate. - (NX_fabrication): - doc: | - Name of the sample substrate vendor (company or research group) - depends_on(NX_CHAR): - doc: | - 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. - (NXtransformations): - doc: | - 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 - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4da1282284e4cb3c7d04a670fbf0d5ac15900ab98e6a70223483376a382954a0 -# -# -# -# -# -# Any information on the sample substrate. -# -# -# -# Material of the substrate in direct contact with the sample. -# -# -# -# -# Physical state of the substrate, similar options to sample_state -# -# -# -# -# Further notes. -# -# -# -# -# Name of the sample substrate vendor (company or research group) -# -# -# -# -# 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. -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups -# -# -# diff --git a/contributed_definitions/nyaml/NXsample_surface_dopant.yaml b/contributed_definitions/nyaml/NXsample_surface_dopant.yaml deleted file mode 100644 index 1e9f2d3f04..0000000000 --- a/contributed_definitions/nyaml/NXsample_surface_dopant.yaml +++ /dev/null @@ -1,13 +0,0 @@ -category: base -doc: | - Description of a dopant material embedded in a sample surface. -type: group -NXsample_surface_dopant(NXsample_component): - element: - doc: | - Element of evaporated surface dopant such as alkali or other - coverage: - unit: NX_LENGTH - doc: | - Nominal thickness of the evaporated dopant. - \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXsingle_crystal.yaml b/contributed_definitions/nyaml/NXsingle_crystal.yaml deleted file mode 100644 index ea0731911e..0000000000 --- a/contributed_definitions/nyaml/NXsingle_crystal.yaml +++ /dev/null @@ -1,31 +0,0 @@ -category: base -doc: | - Description of a single crystal material or a single crystalline phase in a material. -type: group -NXsingle_crystal(NXobject): - sample_orientation(NX_FLOAT): - unit: NX_ANGLE - doc: | - This will follow the Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - dimensions: - rank: 1 - dim: [[1, 3]] - orientation_matrix(NX_FLOAT): - doc: | - Orientation matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - dimensions: - rank: 3 - dim: [[1, 3], [2, 3], [3, 3]] - ub_matrix(NX_FLOAT): - doc: | - UB matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is - the multiplication of the orientation_matrix, given above, - with the :math:`B` matrix which can be derived from the lattice constants. - dimensions: - rank: 3 - dim: [[1, 3], [2, 3], [3, 3]] - (NXunit_cell): - doc: Unit cell of the material. \ No newline at end of file From 21185ef89e7a8c6d59d5016ecc57de61bc6197fc Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 29 Aug 2023 11:51:21 +0200 Subject: [PATCH 0204/1012] Align descriptors of sample material with Area A base section Change base classes: - NXsample_component_set - NXsubstance - NXunit_cell --- base_classes/nyaml/NXsample.yaml | 134 +++++------------- base_classes/nyaml/NXsample_component.yaml | 35 ++--- .../NXsample_component_set.nxdl.xml | 76 ++++++++++ contributed_definitions/NXsubstance.nxdl.xml | 121 ++++++++++++++++ contributed_definitions/NXunit_cell.nxdl.xml | 76 ++++++++++ .../nyaml/NXsample_component_set.yaml | 16 ++- .../nyaml/NXsubstance.yaml | 54 +++++-- .../nyaml/NXunit_cell.yaml | 4 +- 8 files changed, 367 insertions(+), 149 deletions(-) create mode 100644 contributed_definitions/NXsample_component_set.nxdl.xml create mode 100644 contributed_definitions/NXsubstance.nxdl.xml create mode 100644 contributed_definitions/NXunit_cell.nxdl.xml diff --git a/base_classes/nyaml/NXsample.yaml b/base_classes/nyaml/NXsample.yaml index 68f5887ad2..e0bb46bd40 100644 --- a/base_classes/nyaml/NXsample.yaml +++ b/base_classes/nyaml/NXsample.yaml @@ -5,7 +5,6 @@ doc: | 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. - However, this information is ideally stored in a dedicated NXenvironment on the application definition level. symbols: doc: | symbolic array lengths to be coordinated between various fields @@ -26,12 +25,13 @@ NXsample(NXobject): name: doc: | Descriptive name of sample + sample_id(NX_CHAR): + doc: | + Identification number or signatures of the sample used. chemical_formula: - deprecated: | - Use `NXsubstance` instead. doc: | The chemical formula specified using CIF conventions. - Abbreviated version of CIF standard:107 + 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. @@ -49,80 +49,69 @@ NXsample(NXobject): * This is the *Hill* system used by Chemical Abstracts. temperature(NX_FLOAT): - deprecated: | - Use `NXenvironment` to log the sample temperature. unit: NX_TEMPERATURE doc: | Sample temperature. This could be a scanned variable dimensions: rank: anyRank + # could be any length dim: [[1, n_Temp]] electric_field(NX_FLOAT): - deprecated: | - Use `NXenvironment` to log the applied electric field. unit: NX_VOLTAGE doc: | Applied electric field dimensions: + # could be any length dim: [[1, n_eField]] \@direction: enumeration: [x, y, z] magnetic_field(NX_FLOAT): - deprecated: | - Use `NXenvironment` to log the applied magnetic field. unit: NX_ANY doc: | Applied magnetic field dimensions: + # could be any length dim: [[1, n_mField]] \@direction: enumeration: [x, y, z] stress_field(NX_FLOAT): - deprecated: | - Use `NXenvironment` to log the applied external stress field. unit: NX_ANY doc: | Applied external stress field dimensions: + # could be any length dim: [[1, n_sField]] \@direction: enumeration: [x, y, z] pressure(NX_FLOAT): - deprecated: | - Use `NXenvironment` to log the applied pressure. unit: NX_PRESSURE doc: | Applied pressure dimensions: + # could be any length dim: [[1, n_pField]] changer_position(NX_INT): unit: NX_UNITLESS doc: | Sample changer position - Note, it is recommended to use NXpositioner instead. unit_cell_abc(NX_FLOAT): - deprecated: | - Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. unit: NX_LENGTH doc: | Crystallography unit cell parameters a, b, and c dimensions: dim: [[1, 3]] unit_cell_alphabetagamma(NX_FLOAT): - deprecated: | - Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. unit: NX_ANGLE + unit: NX_ANGLE doc: | Crystallography unit cell parameters alpha, beta, and gamma dimensions: dim: [[1, 3]] unit_cell(NX_FLOAT): - deprecated: | - Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. unit: NX_LENGTH doc: | Unit cell parameters (lengths and angles) @@ -130,8 +119,6 @@ NXsample(NXobject): rank: 2 dim: [[1, n_comp], [2, 6]] unit_cell_volume(NX_FLOAT): - deprecated: | - Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. unit: NX_VOLUME doc: | Volume of the unit cell @@ -139,8 +126,6 @@ NXsample(NXobject): rank: 1 dim: [[1, n_comp]] sample_orientation(NX_FLOAT): - deprecated: | - Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. unit: NX_ANGLE doc: | This will follow the Busing-Levy convention: @@ -149,8 +134,6 @@ NXsample(NXobject): rank: 1 dim: [[1, 3]] orientation_matrix(NX_FLOAT): - deprecated: | - Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. doc: | Orientation matrix of single crystal sample using Busing-Levy convention: W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 @@ -158,8 +141,6 @@ NXsample(NXobject): rank: 3 dim: [[1, n_comp], [2, 3], [3, 3]] ub_matrix(NX_FLOAT): - deprecated: | - Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. doc: | UB matrix of single crystal sample using Busing-Levy convention: W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is @@ -173,35 +154,35 @@ NXsample(NXobject): unit: NX_MASS doc: | Mass of sample + dimensions: + rank: 1 + dim: [[1, n_comp]] density(NX_FLOAT): unit: NX_MASS_DENSITY doc: | Density of sample + dimensions: + rank: 1 + dim: [[1, n_comp]] relative_molecular_mass(NX_FLOAT): unit: NX_MASS doc: | Relative Molecular Mass of sample + dimensions: + rank: 1 + dim: [[1, n_comp]] type: - # This is neither complete nor should all of these enumerate options be here. enumeration: [sample, sample+can, can, sample+buffer, buffer, calibration sample, normalisation sample, simulated data, none, sample environment] situation: - deprecated: | - Use `NXenvironment` instead. doc: | 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. - This should be deprecated in the future. enumeration: [air, vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere, sealed can, other] description: doc: | Description of the sample - (NXsample_synthesis_step): - doc: - Information about a sample synthesis step. preparation_date(NX_DATE_TIME): - deprecated: - Use `NXprocess_sample_prep` instead. doc: | Date of preparation of the sample geometry(NXgeometry): @@ -216,20 +197,13 @@ NXsample(NXobject): doc: | One group per sample component This is the perferred way of recording per component information over the n_comp arrays - (NXsample_component_set): - doc: | - Set of sample components and their configuration. component: - deprecated: | - Use `NXsample_component_set` for the configuration of the different components. doc: | Details of the component of the sample and/or can dimensions: rank: 1 dim: [[1, n_comp]] sample_component: - deprecated: | - Use `NXsample_component_set` for the configuration of the different components. doc: | Type of component dimensions: @@ -237,8 +211,6 @@ NXsample(NXobject): dim: [[1, n_comp]] enumeration: [sample, can, atmosphere, kit] concentration(NX_FLOAT): - deprecated: | - Use `NXsample_component_set` for the configuration of the different components. unit: NX_MASS_DENSITY doc: | Concentration of each component @@ -246,16 +218,12 @@ NXsample(NXobject): rank: 1 dim: [[1, n_comp]] volume_fraction(NX_FLOAT): - deprecated: | - Use `NXsample_component_set` for the configuration of the different components. doc: | Volume fraction of each component dimensions: rank: 1 dim: [[1, n_comp]] scattering_length_density(NX_FLOAT): - deprecated: | - Use `NXsample_component_set` for the configuration of the different components. unit: NX_SCATTERING_LENGTH_DENSITY doc: | Scattering length density of each component @@ -267,15 +235,11 @@ NXsample(NXobject): In case it is all we know and we want to record/document it enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] space_group: - deprecated: | - Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. doc: | Crystallographic space group dimensions: dim: [[1, n_comp]] point_group: - deprecated: | - Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. doc: | Crystallographic point group, deprecated if space_group present dimensions: @@ -294,44 +258,6 @@ NXsample(NXobject): unit: NX_LENGTH doc: | sample thickness - sample_id(NX_CHAR): - doc: | - Identification number or signatures of the sample used. - (NXsample_history): - doc: | - A set of physical processes that occurred to the sample prior/during experiment. - state(NX_CHAR): - doc: | - Physical state of the sample - purity(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Chemical purity of the sample - orientation(NX_CHAR): - deprecated: | - Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. - doc: | - Surface termination of the sample (if crystalline) - (NXsubstance): - doc: | - Any substance contained in the sample. - (NXfabrication): - doc: | - Details about the sample vendor (company or research group) - (NXsample_substrate): - doc: | - Information about the material of the substrate in direct contact with the sample. - Could be a sample holder for example. - (NXenvironment): - # eventually, this should be stored in the application definitions - doc: | - Any environmental or external stimuli/measurements. - These can include, among others: - applied pressure, surrounding gas phase and gas pressure, - external electric/magnetic/stress fields, temperature, ... - notes(NXnote): - doc: | - Further notes. transmission(NXdata): doc: | As a function of Wavelength @@ -343,7 +269,6 @@ NXsample(NXobject): temperature_env(NXenvironment): doc: | Additional sample temperature environment information - Note, it is recommended to have NXenvironment as a stand-alone in the application definition. magnetic_field(NXlog): doc: | magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value @@ -355,16 +280,11 @@ NXsample(NXobject): magnetic_field_env(NXenvironment): doc: | Additional sample magnetic environment information - Note, it is recommended to have NXenvironment as a stand-alone in the application definition. external_DAC(NX_FLOAT): - deprecated: | - Use `NXenvironment` to log any external DACs. unit: NX_ANY doc: | value sent to user's sample setup external_ADC(NXlog): - deprecated: | - Use `NXenvironment` to log any external ADCs. doc: | logged value (or logic state) read from user's setup short_title: @@ -396,6 +316,22 @@ NXsample(NXobject): exists: ['min', '0'] doc: | This group describes the shape of the sample + (NXsample_component_set): + doc: | + Set of sample components and their configuration. + (NXsubstance): + doc: | + Any substance contained in the sample. + (NXfabrication): + doc: | + Details about the sample vendor (company or research group) + (NXenvironment): + # eventually, this should be stored in the application definitions + doc: | + Any environmental or external stimuli/measurements. + These can include, among others: + applied pressure, surrounding gas phase and gas pressure, + external electric/magnetic/stress fields, temperature, ... \@default: doc: | .. index:: plotting diff --git a/base_classes/nyaml/NXsample_component.yaml b/base_classes/nyaml/NXsample_component.yaml index 294b69f2c2..e7528f75b7 100644 --- a/base_classes/nyaml/NXsample_component.yaml +++ b/base_classes/nyaml/NXsample_component.yaml @@ -19,9 +19,10 @@ NXsample_component(NXobject): name: doc: | Descriptive name of sample component + sample_id(NX_CHAR): + doc: | + Identification number or signatures of the sample component used. chemical_formula: - deprecated: | - Use `NXsubstance` instead. doc: | The chemical formula specified using CIF conventions. Abbreviated version of CIF standard: @@ -42,30 +43,22 @@ NXsample_component(NXobject): * This is the *Hill* system used by Chemical Abstracts. unit_cell_abc(NX_FLOAT): - deprecated: | - Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. unit: NX_LENGTH doc: | Crystallography unit cell parameters a, b, and c dimensions: dim: [[1, 3]] unit_cell_alphabetagamma(NX_FLOAT): - deprecated: | - Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. unit: NX_ANGLE doc: | Crystallography unit cell parameters alpha, beta, and gamma dimensions: dim: [[1, 3]] unit_cell_volume(NX_FLOAT): - deprecated: | - Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. unit: NX_VOLUME doc: | Volume of the unit cell sample_orientation(NX_FLOAT): - deprecated: | - Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. unit: NX_ANGLE doc: | This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) @@ -73,8 +66,6 @@ NXsample_component(NXobject): rank: 1 dim: [[1, 3]] orientation_matrix(NX_FLOAT): - deprecated: | - Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. doc: | Orientation matrix of single crystal sample component. This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) @@ -97,44 +88,34 @@ NXsample_component(NXobject): doc: | Description of the sample component volume_fraction(NX_FLOAT): - deprecated: | - Use `NXsample_component_set` for the configuration of the multiple components. doc: | Volume fraction of component scattering_length_density(NX_FLOAT): - deprecated: | - Use `NXsample_component_set` for the configuration of the multiple components. unit: NX_SCATTERING_LENGTH_DENSITY doc: | - Scattering length density of component + Scattering length density of component unit_cell_class: - deprecated: | - Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. doc: | In case it is all we know and we want to record/document it enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] space_group: - deprecated: | - Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. doc: | Crystallographic space group point_group: - deprecated: | - Use `NXsingle_crystal` and `NXunit_cell` to describe single crystalline materials. doc: | Crystallographic point group, deprecated if space_group present transmission(NXdata): doc: | As a function of Wavelength - (NXsample_history): + (NXsample_component_set): doc: | - A set of physical processes that occurred to the sample component prior/during experiment. + Set of sub-components and their configuration. (NXsubstance): doc: | - Any substance contained in the sample component. + Any substance contained in the component. (NXfabrication): doc: | - Details about the sample component vendor (company or research group) + Details about the sample component vendor (company or research group) \@default: doc: | .. index:: plotting diff --git a/contributed_definitions/NXsample_component_set.nxdl.xml b/contributed_definitions/NXsample_component_set.nxdl.xml new file mode 100644 index 0000000000..be10c84275 --- /dev/null +++ b/contributed_definitions/NXsample_component_set.nxdl.xml @@ -0,0 +1,76 @@ + + + + + + + + number of components + + + + + Set of sample components and their configuration. The idea here is to have a united place + for all materials descriptors that are not part of the individual sample components, + but rather their configuration. + + + + Number of layers of the sample (e.g. bulk, monolayer, pentalayer, etc.) + + + + + Concentration of each component + + + + + + + + Volume fraction of each component + + + + + + + + Scattering length density of each component + + + + + + + + Each component set can contain multiple components. + + + + + For description of a sub-component set. Can contain multiple components. + + + diff --git a/contributed_definitions/NXsubstance.nxdl.xml b/contributed_definitions/NXsubstance.nxdl.xml new file mode 100644 index 0000000000..d5a17dbbcb --- /dev/null +++ b/contributed_definitions/NXsubstance.nxdl.xml @@ -0,0 +1,121 @@ + + + + + + A form of matter with a constant, definite chemical composition. + Examples can be single chemical elements, chemical compunds, or alloys. + + + + User-defined chemical name of the substance + + + + + Molecular mass of the substance + + + + + Unique numeric CAS REGISTRY number of the sample chemical content + For further information, see https://www.cas.org/. + + + + + CAS REGISTRY name of the sample chemical content + + + + + CAS REGISTRY URI + + + + + CAS REGISTRY image + + + + + Synonyms in the CAS system. + + + + + String InChi identifier. + The InChI identifier expresses chemical structures in terms of atomic connectivity, + tautomeric state, isotopes, stereochemistry and electronic charge in order to + produce a string of machine-readable characters unique to the respective molecule. + For further information, see https://iupac.org/who-we-are/divisions/division-details/inchi/. + + + + + Condensed, 27 character InChIKey. + Hashed version of the full InChI (using the SHA-256 algorithm). + + + + + Name in the IUPAC system. + + + + + Identifier in the SMILES (Simplified Molecular Input Line Entry System) system + For further information, see https://www.daylight.com/smiles/. + + + + + Canonical version of the smiles identifier + + + + + The chemical formula specified using CIF conventions. + Abbreviated version of CIF standard:107 + This is the *Hill* system used by Chemical Abstracts. + + * Only recognized element symbols may be used. + * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. + * A space or parenthesis must separate each cluster of (element symbol + count). + * Where a group of elements is enclosed in parentheses, the multiplier for the + group must follow the closing parentheses. That is, all element and group + multipliers are assumed to be printed as subscripted numbers. + * Unless the elements are ordered in a manner that corresponds to their chemical + structure, the order of the elements within any group or moiety depends on + whether or not carbon is present. + * If carbon is present, the order should be: + - C, then H, then the other elements in alphabetical order of their symbol. + - If carbon is not present, the elements are listed purely in alphabetic order of their symbol. + + + + + If the substance is crystalline, add description of unit cell. + + + diff --git a/contributed_definitions/NXunit_cell.nxdl.xml b/contributed_definitions/NXunit_cell.nxdl.xml new file mode 100644 index 0000000000..22644ad08d --- /dev/null +++ b/contributed_definitions/NXunit_cell.nxdl.xml @@ -0,0 +1,76 @@ + + + + + + Description of a unit cell, e.g. of a single crystalline material. + + + + In case it is all we know and we want to record/document it + + + + + + + + + + + + + + Crystallographic space group + + + + + Crystallographic point group, deprecated if space_group presents + + + + + Crystallography unit cell parameters a, b, and c + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma + + + + + + + + Volume of the unit cell + + + + + + diff --git a/contributed_definitions/nyaml/NXsample_component_set.yaml b/contributed_definitions/nyaml/NXsample_component_set.yaml index 3557a5303f..4b63109cc4 100644 --- a/contributed_definitions/nyaml/NXsample_component_set.yaml +++ b/contributed_definitions/nyaml/NXsample_component_set.yaml @@ -1,10 +1,9 @@ category: base doc: | - Set of sample components and their configuration. The idea here is to store all descriptors of the individual NXsample_components - that cannot be stored on the level of the individual sample component. + Set of sample components and their configuration. The idea here is to have a united place + for all materials descriptors that are not part of the individual sample components, + but rather their configuration. symbols: - doc: | - DOC MISSING. n_comp: | number of components type: group @@ -13,9 +12,9 @@ NXsample_component_set(NXobject): doc: | Number of layers of the sample (e.g. bulk, monolayer, pentalayer, etc.) concentration(NX_FLOAT): - unit: NX_MASS_DENSITY + unit: NX_UNITLESS doc: | - Concentration of each component + Concentration of each component dimensions: rank: 1 dim: [[1, n_comp]] @@ -34,4 +33,7 @@ NXsample_component_set(NXobject): dim: [[1, n_comp]] (NXsample_component): doc: | - One such group per component \ No newline at end of file + Each component set can contain multiple components. + (NXsample_component_set): + doc: + For description of a sub-component set. Can contain multiple components. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXsubstance.yaml b/contributed_definitions/nyaml/NXsubstance.yaml index d2128546bd..987789e9de 100644 --- a/contributed_definitions/nyaml/NXsubstance.yaml +++ b/contributed_definitions/nyaml/NXsubstance.yaml @@ -4,16 +4,51 @@ doc: | Examples can be single chemical elements, chemical compunds, or alloys. type: group NXsubstance(NXobject): - chemical_name(NX_CHAR): + name(NX_CHAR): + doc: User-defined chemical name of the substance + molecular_mass(NX_FLOAT): + unit: NX_MOLECULAR_WEIGHT + doc: | + Molecular mass of the substance + cas_number(NX_CHAR): + doc: | + Unique numeric CAS REGISTRY number of the sample chemical content + For further information, see https://www.cas.org/. + cas_name(NX_CHAR): + doc: CAS REGISTRY name of the sample chemical content + cas_uri(NX_CHAR): + doc: | + CAS REGISTRY URI + cas_image(NXnote): + doc: CAS REGISTRY image + cas_synonyms(NX_CHAR): + doc: Synonyms in the CAS system. + inchi_str(NX_CHAR): + doc: | + String InChi identifier. + The InChI identifier expresses chemical structures in terms of atomic connectivity, + tautomeric state, isotopes, stereochemistry and electronic charge in order to + produce a string of machine-readable characters unique to the respective molecule. + For further information, see https://iupac.org/who-we-are/divisions/division-details/inchi/. + inchi_key(NX_CHAR): doc: | - Full chemical name of the sample + Condensed, 27 character InChIKey. + Hashed version of the full InChI (using the SHA-256 algorithm). iupac_name(NX_CHAR): doc: | Name in the IUPAC system. - molecular_formula(NX_CHAR): + smile(NX_CHAR): + doc: | + Identifier in the SMILES (Simplified Molecular Input Line Entry System) system + For further information, see https://www.daylight.com/smiles/. + canonical_smile(NX_CHAR): + doc: | + Canonical version of the smiles identifier + molecular_formula_hill(NX_CHAR): doc: | The chemical formula specified using CIF conventions. Abbreviated version of CIF standard:107 + This is the *Hill* system used by Chemical Abstracts. * Only recognized element symbols may be used. * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. @@ -27,15 +62,6 @@ NXsubstance(NXobject): * 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. - molecular_mass(NX_FLOAT): - unit: NX_MASS - doc: | - Molecular mass of the substance. - chem_id_cas(NX_CHAR): - doc: | - CAS registry number of the sample chemical content. - inchi_key(NX_CHAR): + (NXunit_cell): doc: | - inChi identifier. \ No newline at end of file + If the substance is crystalline, add description of unit cell. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXunit_cell.yaml b/contributed_definitions/nyaml/NXunit_cell.yaml index 918b785fef..e13d6aeacb 100644 --- a/contributed_definitions/nyaml/NXunit_cell.yaml +++ b/contributed_definitions/nyaml/NXunit_cell.yaml @@ -14,13 +14,13 @@ NXunit_cell(NXobject): point_group(NX_CHAR): doc: | Crystallographic point group, deprecated if space_group presents - abc(NX_FLOAT): + a_b_c(NX_FLOAT): unit: NX_LENGTH doc: | Crystallography unit cell parameters a, b, and c dimensions: dim: [[1, 3]] - alphabetagamma(NX_FLOAT): + alpha_beta_gamma(NX_FLOAT): unit: NX_ANGLE doc: | Crystallography unit cell parameters alpha, beta, and gamma From 74a79a4cbbf745a714de8f545c532a7c9d4c843b Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 29 Aug 2023 12:50:00 +0200 Subject: [PATCH 0205/1012] Align description of activities and process with Area A's base section New(changed base classes: - NXsample - NXsample_component - NXsample_history - NXactivtiy - NXphysical_process - NXsample_synthesis_step --- base_classes/NXsample.nxdl.xml | 164 ++++++++---------- base_classes/NXsample_component.nxdl.xml | 40 +++-- base_classes/nyaml/NXsample.yaml | 3 + base_classes/nyaml/NXsample_component.yaml | 3 + .../NXsample_history.nxdl.xml | 45 +++++ contributed_definitions/nyaml/NXactivity.yaml | 14 ++ .../nyaml/NXphysical_process.yaml | 12 +- .../nyaml/NXsample_history.yaml | 13 +- .../nyaml/NXsample_synthesis_step.yaml | 10 -- .../nyaml/NXsynthesis_step.yaml | 17 ++ 10 files changed, 189 insertions(+), 132 deletions(-) create mode 100644 contributed_definitions/NXsample_history.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXactivity.yaml delete mode 100644 contributed_definitions/nyaml/NXsample_synthesis_step.yaml create mode 100644 contributed_definitions/nyaml/NXsynthesis_step.yaml diff --git a/base_classes/NXsample.nxdl.xml b/base_classes/NXsample.nxdl.xml index 731c53d612..86849e495b 100755 --- a/base_classes/NXsample.nxdl.xml +++ b/base_classes/NXsample.nxdl.xml @@ -63,17 +63,21 @@ 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. - However, this information is ideally stored in a dedicated NXenvironment on the application definition level. Descriptive name of sample - + + + Identification number or signatures of the sample used. + + + The chemical formula specified using CIF conventions. - Abbreviated version of CIF standard:107 + 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. @@ -92,7 +96,7 @@ * This is the *Hill* system used by Chemical Abstracts. - + Sample temperature. This could be a scanned variable @@ -101,7 +105,7 @@ - + Applied electric field @@ -117,7 +121,7 @@ - + Applied magnetic field @@ -133,7 +137,7 @@ - + Applied external stress field @@ -149,7 +153,7 @@ - + Applied pressure @@ -161,10 +165,9 @@ Sample changer position - Note, it is recommended to use NXpositioner instead. - + Crystallography unit cell parameters a, b, and c @@ -172,7 +175,7 @@ - + Crystallography unit cell parameters alpha, beta, and gamma @@ -180,7 +183,7 @@ - + Unit cell parameters (lengths and angles) @@ -189,7 +192,7 @@ - + Volume of the unit cell @@ -197,7 +200,7 @@ - + This will follow the Busing-Levy convention: W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 @@ -206,7 +209,7 @@ - + Orientation matrix of single crystal sample using Busing-Levy convention: W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 @@ -217,7 +220,7 @@ - + UB matrix of single crystal sample using Busing-Levy convention: W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is @@ -235,19 +238,27 @@ Mass of sample + + + Density of sample + + + Relative Molecular Mass of sample + + + - @@ -261,12 +272,11 @@ - + 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. - This should be deprecated in the future. @@ -283,12 +293,7 @@ Description of the sample - - - Information about a sample synthesis step. - - - + Date of preparation of the sample @@ -310,12 +315,7 @@ This is the perferred way of recording per component information over the n_comp arrays - - - Set of sample components and their configuration. - - - + Details of the component of the sample and/or can @@ -323,7 +323,7 @@ - + Type of component @@ -337,7 +337,7 @@ - + Concentration of each component @@ -345,7 +345,7 @@ - + Volume fraction of each component @@ -353,7 +353,7 @@ - + Scattering length density of each component @@ -375,7 +375,7 @@ - + Crystallographic space group @@ -383,7 +383,7 @@ - + Crystallographic point group, deprecated if space_group present @@ -408,61 +408,6 @@ sample thickness - - - Identification number or signatures of the sample used. - - - - - A set of physical processes that occurred to the sample prior/during experiment. - - - - - Physical state of the sample - - - - - Chemical purity of the sample - - - - - Surface termination of the sample (if crystalline) - - - - - Any substance contained in the sample. - - - - - Details about the sample vendor (company or research group) - - - - - Information about the material of the substrate in direct contact with the sample. - Could be a sample holder for example. - - - - - - Any environmental or external stimuli/measurements. - These can include, among others: - applied pressure, surrounding gas phase and gas pressure, - external electric/magnetic/stress fields, temperature, ... - - - - - Further notes. - - As a function of Wavelength @@ -476,7 +421,6 @@ Additional sample temperature environment information - Note, it is recommended to have NXenvironment as a stand-alone in the application definition. @@ -493,15 +437,14 @@ Additional sample magnetic environment information - Note, it is recommended to have NXenvironment as a stand-alone in the application definition. - + value sent to user's sample setup - + logged value (or logic state) read from user's setup @@ -542,6 +485,35 @@ This group describes the shape of the sample + + + Set of sample components and their configuration. + + + + + Any substance contained in the sample. + + + + + Details about the sample vendor (company or research group) + + + + + + Any environmental or external stimuli/measurements. + These can include, among others: + applied pressure, surrounding gas phase and gas pressure, + external electric/magnetic/stress fields, temperature, ... + + + + + A set of physical processes that occurred to the sample prior/during experiment. + + .. index:: plotting diff --git a/base_classes/NXsample_component.nxdl.xml b/base_classes/NXsample_component.nxdl.xml index 76fbc42f41..db51f0ab64 100644 --- a/base_classes/NXsample_component.nxdl.xml +++ b/base_classes/NXsample_component.nxdl.xml @@ -61,7 +61,12 @@ Descriptive name of sample component - + + + Identification number or signatures of the sample component used. + + + The chemical formula specified using CIF conventions. Abbreviated version of CIF standard: @@ -83,7 +88,7 @@ * This is the *Hill* system used by Chemical Abstracts. - + Crystallography unit cell parameters a, b, and c @@ -91,7 +96,7 @@ - + Crystallography unit cell parameters alpha, beta, and gamma @@ -99,12 +104,12 @@ - + Volume of the unit cell - + This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) @@ -113,7 +118,7 @@ - + Orientation matrix of single crystal sample component. This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) @@ -143,17 +148,17 @@ Description of the sample component - + Volume fraction of component - + Scattering length density of component - + In case it is all we know and we want to record/document it @@ -167,12 +172,12 @@ - + Crystallographic space group - + Crystallographic point group, deprecated if space_group present @@ -182,15 +187,14 @@ As a function of Wavelength - + - A set of physical processes that occurred to the sample component prior/during - experiment. + Set of sub-components and their configuration. - Any substance contained in the sample component. + Any substance contained in the component. @@ -198,6 +202,12 @@ Details about the sample component vendor (company or research group) + + + A set of physical processes that occurred to the sample component prior/during + experiment. + + .. index:: plotting diff --git a/base_classes/nyaml/NXsample.yaml b/base_classes/nyaml/NXsample.yaml index e0bb46bd40..b64f76d66c 100644 --- a/base_classes/nyaml/NXsample.yaml +++ b/base_classes/nyaml/NXsample.yaml @@ -332,6 +332,9 @@ NXsample(NXobject): These can include, among others: applied pressure, surrounding gas phase and gas pressure, external electric/magnetic/stress fields, temperature, ... + (NXsample_history): + doc: | + A set of physical processes that occurred to the sample prior/during experiment. \@default: doc: | .. index:: plotting diff --git a/base_classes/nyaml/NXsample_component.yaml b/base_classes/nyaml/NXsample_component.yaml index e7528f75b7..e874c03c23 100644 --- a/base_classes/nyaml/NXsample_component.yaml +++ b/base_classes/nyaml/NXsample_component.yaml @@ -116,6 +116,9 @@ NXsample_component(NXobject): (NXfabrication): doc: | Details about the sample component vendor (company or research group) + (NXsample_history): + doc: | + A set of physical processes that occurred to the sample component prior/during experiment. \@default: doc: | .. index:: plotting diff --git a/contributed_definitions/NXsample_history.nxdl.xml b/contributed_definitions/NXsample_history.nxdl.xml new file mode 100644 index 0000000000..35351964dc --- /dev/null +++ b/contributed_definitions/NXsample_history.nxdl.xml @@ -0,0 +1,45 @@ + + + + + + A set of activities that occurred to the sample prior/during experiment. + Ideally, a full report of the previous operation, in the format of NXactivity. + Alternatively, notes allows for additional descriptors in any format. + + + + Any activity that was performed on the sample prior or during the experiment. + Examples include measurements or sample treatments. + + + + + A descriptor to keep track of the treatment of the sample before or during the + experiment (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + This should only be used in case that there is no rigorous description using NXactivity. + + + diff --git a/contributed_definitions/nyaml/NXactivity.yaml b/contributed_definitions/nyaml/NXactivity.yaml new file mode 100644 index 0000000000..1c3bf94a1d --- /dev/null +++ b/contributed_definitions/nyaml/NXactivity.yaml @@ -0,0 +1,14 @@ +category: base +doc: | + A planned or unplanned action that has a temporal extension and for some time depends on some entity +type: group +NXactivity(NXobject): + start_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC information included when this activity started. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC information included when this activity ended. + description(NX_CHAR): + doc: | + Short description of the activity. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXphysical_process.yaml b/contributed_definitions/nyaml/NXphysical_process.yaml index ecd9ad3a60..51a32a0170 100644 --- a/contributed_definitions/nyaml/NXphysical_process.yaml +++ b/contributed_definitions/nyaml/NXphysical_process.yaml @@ -1,15 +1,17 @@ category: base doc: | A planned or unplanned process which results in physical changes in a specified material. - Examples include sample preparation, material transformation, or (partially) destructive measurement. + Examples include sample preparation, material transformation, or (partially) destrustive measurement. type: group -NXphysical_process(NXobject): +NXphysical_process(NXactivity): start_time(NX_DATE_TIME): doc: | - ISO 8601 formatted time code with local time zone offset to UTC information included when this physical process started. + ISO 8601 formatted time code with local time zone offset to UTC information included when this process started. end_time(NX_DATE_TIME): doc: | - ISO 8601 formatted time code with local time zone offset to UTC information included when this physical process ended. + ISO 8601 formatted time code with local time zone offset to UTC information included when this process ended. description(NX_CHAR): doc: | - Short description of the physical process. \ No newline at end of file + Short description of the physical process. + method(NX_CHAR): + Method by which this process was performed \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXsample_history.yaml b/contributed_definitions/nyaml/NXsample_history.yaml index 6051baec49..657faf3b7c 100644 --- a/contributed_definitions/nyaml/NXsample_history.yaml +++ b/contributed_definitions/nyaml/NXsample_history.yaml @@ -1,17 +1,18 @@ category: base doc: | - A set of physical processes that occurred to the sample prior/during experiment. - Ideally, a full report of the previous operations, in the format of NXphysical_process. + A set of activities that occurred to the sample prior/during experiment. + Ideally, a full report of the previous operation, in the format of NXactivity. Alternatively, notes allows for additional descriptors in any format. type: group NXsample_history(NXobject): - (NXphysical_process): + (NXactivity): doc: | - Any process that was performed on the sample prior or during the experiment. - Examples includ + Any activity that was performed on the sample prior or during the experiment. + Examples include measurements or sample treatments. notes(NXnote): doc: | A descriptor to keep track of the treatment of the sample before or during the experiment (NXnote allows to add pictures, audio, movies). Alternatively, a reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. \ No newline at end of file + case these are not available, free-text description. + This should only be used in case that there is no rigorous description using NXactivity. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXsample_synthesis_step.yaml b/contributed_definitions/nyaml/NXsample_synthesis_step.yaml deleted file mode 100644 index 5d97f904ad..0000000000 --- a/contributed_definitions/nyaml/NXsample_synthesis_step.yaml +++ /dev/null @@ -1,10 +0,0 @@ -category: base -doc: | - A planned or unplanned process which results in physical changes in a specified material. - Examples include sample preparation, material transformation, or (partially) destrustive measurement. -type: group -NXsample_synthesis_step(NXphysical_process): - method(NX_CHAR): - doc: | - Descriptor of the synthesis method. For sample growth method, this could include e. g. - molecular beam epitaxy, chemical vapor deposition etc. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXsynthesis_step.yaml b/contributed_definitions/nyaml/NXsynthesis_step.yaml new file mode 100644 index 0000000000..dbf7313c92 --- /dev/null +++ b/contributed_definitions/nyaml/NXsynthesis_step.yaml @@ -0,0 +1,17 @@ +category: base +doc: | + A step in a sample synthesis process. For sample growth method, this could include e. g. + molecular beam epitaxy, chemical vapor deposition etc. +type: group +NXsample_synthesis_step(NXphysical_process): + start_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC information included when this step started. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC information included when this step ended. + description(NX_CHAR): + Full description of the sample synthesis step. + method(NX_CHAR): + doc: | + The may be crystal growth, epitaxy, physical vapor deposition, ... From 6580395f00d67073c51a46d3822475cc9cfec116 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 29 Aug 2023 17:59:43 +0200 Subject: [PATCH 0206/1012] Update after TF meeting discussion - Update some links/terms - Remove non-supported base class inheritance wrt. NXactivity --- base_classes/NXsample.nxdl.xml | 2 +- base_classes/nyaml/NXsample.yaml | 2 +- contributed_definitions/NXactivity.nxdl.xml | 47 +++++++++++++++++ .../NXchemical_process.nxdl.xml | 52 +++++++++++++++++++ .../NXphysical_process.nxdl.xml | 52 +++++++++++++++++++ .../NXsample_component_set.nxdl.xml | 7 +-- .../NXsample_history.nxdl.xml | 29 +++++++++-- contributed_definitions/NXsubstance.nxdl.xml | 1 + contributed_definitions/nyaml/NXactivity.yaml | 4 +- .../nyaml/NXchemical_process.yaml | 20 +++++++ .../nyaml/NXphysical_process.yaml | 8 +-- .../nyaml/NXsample_component_set.yaml | 4 +- .../nyaml/NXsample_history.yaml | 23 ++++++-- .../nyaml/NXsubstance.yaml | 1 + .../nyaml/NXsynthesis_step.yaml | 17 ------ 15 files changed, 229 insertions(+), 40 deletions(-) create mode 100644 contributed_definitions/NXactivity.nxdl.xml create mode 100644 contributed_definitions/NXchemical_process.nxdl.xml create mode 100644 contributed_definitions/NXphysical_process.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXchemical_process.yaml delete mode 100644 contributed_definitions/nyaml/NXsynthesis_step.yaml diff --git a/base_classes/NXsample.nxdl.xml b/base_classes/NXsample.nxdl.xml index 86849e495b..59912e98e1 100755 --- a/base_classes/NXsample.nxdl.xml +++ b/base_classes/NXsample.nxdl.xml @@ -506,7 +506,7 @@ Any environmental or external stimuli/measurements. These can include, among others: applied pressure, surrounding gas phase and gas pressure, - external electric/magnetic/stress fields, temperature, ... + external electric/magnetic/mechanical fields, temperature, ... diff --git a/base_classes/nyaml/NXsample.yaml b/base_classes/nyaml/NXsample.yaml index b64f76d66c..1c75c6d36b 100644 --- a/base_classes/nyaml/NXsample.yaml +++ b/base_classes/nyaml/NXsample.yaml @@ -331,7 +331,7 @@ NXsample(NXobject): Any environmental or external stimuli/measurements. These can include, among others: applied pressure, surrounding gas phase and gas pressure, - external electric/magnetic/stress fields, temperature, ... + external electric/magnetic/mechanical fields, temperature, ... (NXsample_history): doc: | A set of physical processes that occurred to the sample prior/during experiment. diff --git a/contributed_definitions/NXactivity.nxdl.xml b/contributed_definitions/NXactivity.nxdl.xml new file mode 100644 index 0000000000..1a7be5f1cb --- /dev/null +++ b/contributed_definitions/NXactivity.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + A planned or unplanned action that has a temporal extension and for some time depends on some entity. + This class is planned be used in the future as the supclass for all other activities if inheritance + in base classes is supported in NeXus. + + + + ISO 8601 formatted time code with local time zone offset to UTC information + included when this activity started. + + + + + ISO 8601 formatted time code with local time zone offset to UTC information + included when this activity ended. + + + + + Short description of the activity. + + + diff --git a/contributed_definitions/NXchemical_process.nxdl.xml b/contributed_definitions/NXchemical_process.nxdl.xml new file mode 100644 index 0000000000..2e344c11f7 --- /dev/null +++ b/contributed_definitions/NXchemical_process.nxdl.xml @@ -0,0 +1,52 @@ + + + + + + A planned or unplanned process which results in chemical changes in a specified material. + A physical change involve changes in the chemical bonds. + Examples include any chemical reactions (addition, subtraction, replacement, ...). + + + + ISO 8601 formatted time code with local time zone offset to UTC information + included when this process started. + + + + + ISO 8601 formatted time code with local time zone offset to UTC information + included when this process ended. + + + + + Short description of the chemical process. + + + + + Method by which this process was performed. + + + diff --git a/contributed_definitions/NXphysical_process.nxdl.xml b/contributed_definitions/NXphysical_process.nxdl.xml new file mode 100644 index 0000000000..87bb6fbb34 --- /dev/null +++ b/contributed_definitions/NXphysical_process.nxdl.xml @@ -0,0 +1,52 @@ + + + + + + A planned or unplanned process which results in physical changes in a specified material. + A physical change involve changes only in intermolecular forces, not in the chemical bonds. + Examples include sample preparation, material transformation, or (partially) destrustive measurement. + + + + ISO 8601 formatted time code with local time zone offset to UTC information + included when this process started. + + + + + ISO 8601 formatted time code with local time zone offset to UTC information + included when this process ended. + + + + + Short description of the activity. + + + + + Method by which this process was performed. + + + diff --git a/contributed_definitions/NXsample_component_set.nxdl.xml b/contributed_definitions/NXsample_component_set.nxdl.xml index be10c84275..eb0f06d094 100644 --- a/contributed_definitions/NXsample_component_set.nxdl.xml +++ b/contributed_definitions/NXsample_component_set.nxdl.xml @@ -34,11 +34,6 @@ for all materials descriptors that are not part of the individual sample components, but rather their configuration. - - - Number of layers of the sample (e.g. bulk, monolayer, pentalayer, etc.) - - Concentration of each component @@ -47,7 +42,7 @@ - + Volume fraction of each component diff --git a/contributed_definitions/NXsample_history.nxdl.xml b/contributed_definitions/NXsample_history.nxdl.xml index 35351964dc..1050b58244 100644 --- a/contributed_definitions/NXsample_history.nxdl.xml +++ b/contributed_definitions/NXsample_history.nxdl.xml @@ -24,22 +24,43 @@ A set of activities that occurred to the sample prior/during experiment. - Ideally, a full report of the previous operation, in the format of NXactivity. + Ideally, a full report of the previous operations. Alternatively, notes allows for additional descriptors in any format. - Any activity that was performed on the sample prior or during the experiment. - Examples include measurements or sample treatments. + Any activity that was performed on the sample prior or during the experiment. In + the future, if there is base class inheritance, this can describe any activity, + including processes and measurements. + + + + Any physical process that was performed on the sample prior or during the + experiment. + + + + + Any chemical process that was performed on the sample prior or during the + experiment. + + + A descriptor to keep track of the treatment of the sample before or during the experiment (NXnote allows to add pictures, audio, movies). Alternatively, a reference to the location or a unique identifier or other metadata file. In the case these are not available, free-text description. - This should only be used in case that there is no rigorous description using NXactivity. + This should only be used in case that there is no rigorous description + using the base classes above. This field can also be used to pull in any activities + that are not well described by an existing base/application definition. diff --git a/contributed_definitions/NXsubstance.nxdl.xml b/contributed_definitions/NXsubstance.nxdl.xml index d5a17dbbcb..2951e4ccf0 100644 --- a/contributed_definitions/NXsubstance.nxdl.xml +++ b/contributed_definitions/NXsubstance.nxdl.xml @@ -25,6 +25,7 @@ A form of matter with a constant, definite chemical composition. Examples can be single chemical elements, chemical compunds, or alloys. + For further information, see https://en.wikipedia.org/wiki/Chemical_substance. diff --git a/contributed_definitions/nyaml/NXactivity.yaml b/contributed_definitions/nyaml/NXactivity.yaml index 1c3bf94a1d..4d8dfa2573 100644 --- a/contributed_definitions/nyaml/NXactivity.yaml +++ b/contributed_definitions/nyaml/NXactivity.yaml @@ -1,6 +1,8 @@ category: base doc: | - A planned or unplanned action that has a temporal extension and for some time depends on some entity + A planned or unplanned action that has a temporal extension and for some time depends on some entity. + This class is planned be used in the future as the supclass for all other activities if inheritance + in base classes is supported in NeXus. type: group NXactivity(NXobject): start_time(NX_DATE_TIME): diff --git a/contributed_definitions/nyaml/NXchemical_process.yaml b/contributed_definitions/nyaml/NXchemical_process.yaml new file mode 100644 index 0000000000..681d693476 --- /dev/null +++ b/contributed_definitions/nyaml/NXchemical_process.yaml @@ -0,0 +1,20 @@ +category: base +doc: | + A planned or unplanned process which results in chemical changes in a specified material. + A physical change involve changes in the chemical bonds. + Examples include any chemical reactions (addition, subtraction, replacement, ...). +type: group +NXphysical_process(NXobject): + start_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC information included when this process started. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC information included when this process ended. + description(NX_CHAR): + doc: | + Short description of the chemical process. + method(NX_CHAR): + doc: | + Method by which this process was performed. + \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXphysical_process.yaml b/contributed_definitions/nyaml/NXphysical_process.yaml index 51a32a0170..7de63b4684 100644 --- a/contributed_definitions/nyaml/NXphysical_process.yaml +++ b/contributed_definitions/nyaml/NXphysical_process.yaml @@ -1,9 +1,10 @@ category: base doc: | A planned or unplanned process which results in physical changes in a specified material. + A physical change involve changes only in intermolecular forces, not in the chemical bonds. Examples include sample preparation, material transformation, or (partially) destrustive measurement. type: group -NXphysical_process(NXactivity): +NXactivity(NXobject): start_time(NX_DATE_TIME): doc: | ISO 8601 formatted time code with local time zone offset to UTC information included when this process started. @@ -12,6 +13,7 @@ NXphysical_process(NXactivity): ISO 8601 formatted time code with local time zone offset to UTC information included when this process ended. description(NX_CHAR): doc: | - Short description of the physical process. + Short description of the activity. method(NX_CHAR): - Method by which this process was performed \ No newline at end of file + doc: | + Method by which this process was performed. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXsample_component_set.yaml b/contributed_definitions/nyaml/NXsample_component_set.yaml index 4b63109cc4..023d21c7cb 100644 --- a/contributed_definitions/nyaml/NXsample_component_set.yaml +++ b/contributed_definitions/nyaml/NXsample_component_set.yaml @@ -8,9 +8,6 @@ symbols: number of components type: group NXsample_component_set(NXobject): - layer(NX_CHAR): - doc: | - Number of layers of the sample (e.g. bulk, monolayer, pentalayer, etc.) concentration(NX_FLOAT): unit: NX_UNITLESS doc: | @@ -19,6 +16,7 @@ NXsample_component_set(NXobject): rank: 1 dim: [[1, n_comp]] volume_fraction(NX_FLOAT): + unit: NX_ANY doc: | Volume fraction of each component dimensions: diff --git a/contributed_definitions/nyaml/NXsample_history.yaml b/contributed_definitions/nyaml/NXsample_history.yaml index 657faf3b7c..668eca39bd 100644 --- a/contributed_definitions/nyaml/NXsample_history.yaml +++ b/contributed_definitions/nyaml/NXsample_history.yaml @@ -1,18 +1,33 @@ category: base doc: | A set of activities that occurred to the sample prior/during experiment. - Ideally, a full report of the previous operation, in the format of NXactivity. + Ideally, a full report of the previous operations. Alternatively, notes allows for additional descriptors in any format. type: group NXsample_history(NXobject): (NXactivity): - doc: | + doc: Any activity that was performed on the sample prior or during the experiment. - Examples include measurements or sample treatments. + In the future, if there is base class inheritance, this can describe any activity, + including processes and measurements. + # For now, one workaround would be to have NXactivity as a application definition with a subentry. + # subentry(NXsuxbentry): + # doc: | + # Any activity that was performed on the sample prior or during the experiment. + # definition: ["NXactivity"] + (NXphysical_process): + doc: | + Any physical process that was performed on the sample prior or during the experiment. + (NXchemical_process): + doc: | + Any chemical process that was performed on the sample prior or during the experiment. + # There should be more activities here, like measurement. notes(NXnote): doc: | A descriptor to keep track of the treatment of the sample before or during the experiment (NXnote allows to add pictures, audio, movies). Alternatively, a reference to the location or a unique identifier or other metadata file. In the case these are not available, free-text description. - This should only be used in case that there is no rigorous description using NXactivity. \ No newline at end of file + This should only be used in case that there is no rigorous description + using the base classes above. This field can also be used to pull in any activities + that are not well described by an existing base/application definition. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXsubstance.yaml b/contributed_definitions/nyaml/NXsubstance.yaml index 987789e9de..6769355c90 100644 --- a/contributed_definitions/nyaml/NXsubstance.yaml +++ b/contributed_definitions/nyaml/NXsubstance.yaml @@ -2,6 +2,7 @@ category: base doc: | A form of matter with a constant, definite chemical composition. Examples can be single chemical elements, chemical compunds, or alloys. + For further information, see https://en.wikipedia.org/wiki/Chemical_substance. type: group NXsubstance(NXobject): name(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXsynthesis_step.yaml b/contributed_definitions/nyaml/NXsynthesis_step.yaml deleted file mode 100644 index dbf7313c92..0000000000 --- a/contributed_definitions/nyaml/NXsynthesis_step.yaml +++ /dev/null @@ -1,17 +0,0 @@ -category: base -doc: | - A step in a sample synthesis process. For sample growth method, this could include e. g. - molecular beam epitaxy, chemical vapor deposition etc. -type: group -NXsample_synthesis_step(NXphysical_process): - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC information included when this step started. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC information included when this step ended. - description(NX_CHAR): - Full description of the sample synthesis step. - method(NX_CHAR): - doc: | - The may be crystal growth, epitaxy, physical vapor deposition, ... From 8474e46881a356f1b0adc1540a68fb4ee0a7c079 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 29 Aug 2023 18:19:38 +0200 Subject: [PATCH 0207/1012] Add notes to activities All activity-related base classes now contain a NXnote for any data or other descriptors acquired during the activity. --- contributed_definitions/NXactivity.nxdl.xml | 8 ++++++++ contributed_definitions/NXchemical_process.nxdl.xml | 8 ++++++++ contributed_definitions/NXphysical_process.nxdl.xml | 8 ++++++++ contributed_definitions/nyaml/NXactivity.yaml | 8 +++++++- contributed_definitions/nyaml/NXchemical_process.yaml | 6 ++++++ contributed_definitions/nyaml/NXphysical_process.yaml | 8 +++++++- 6 files changed, 44 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/NXactivity.nxdl.xml b/contributed_definitions/NXactivity.nxdl.xml index 1a7be5f1cb..b7404289d0 100644 --- a/contributed_definitions/NXactivity.nxdl.xml +++ b/contributed_definitions/NXactivity.nxdl.xml @@ -44,4 +44,12 @@ Short description of the activity. + + + This can be any data or other descriptor acquired during the activity + (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + + diff --git a/contributed_definitions/NXchemical_process.nxdl.xml b/contributed_definitions/NXchemical_process.nxdl.xml index 2e344c11f7..9508c610c0 100644 --- a/contributed_definitions/NXchemical_process.nxdl.xml +++ b/contributed_definitions/NXchemical_process.nxdl.xml @@ -49,4 +49,12 @@ Method by which this process was performed. + + + This can be any data or other descriptor acquired during the chemical process + (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + + diff --git a/contributed_definitions/NXphysical_process.nxdl.xml b/contributed_definitions/NXphysical_process.nxdl.xml index 87bb6fbb34..c774158b5a 100644 --- a/contributed_definitions/NXphysical_process.nxdl.xml +++ b/contributed_definitions/NXphysical_process.nxdl.xml @@ -49,4 +49,12 @@ Method by which this process was performed. + + + This can be any data or other descriptor acquired during the physical process + (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + + diff --git a/contributed_definitions/nyaml/NXactivity.yaml b/contributed_definitions/nyaml/NXactivity.yaml index 4d8dfa2573..a7f19f452e 100644 --- a/contributed_definitions/nyaml/NXactivity.yaml +++ b/contributed_definitions/nyaml/NXactivity.yaml @@ -13,4 +13,10 @@ NXactivity(NXobject): ISO 8601 formatted time code with local time zone offset to UTC information included when this activity ended. description(NX_CHAR): doc: | - Short description of the activity. \ No newline at end of file + Short description of the activity. + notes(NXnote): + doc: | + This can be any data or other descriptor acquired during the activity + (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXchemical_process.yaml b/contributed_definitions/nyaml/NXchemical_process.yaml index 681d693476..20b2f35de4 100644 --- a/contributed_definitions/nyaml/NXchemical_process.yaml +++ b/contributed_definitions/nyaml/NXchemical_process.yaml @@ -17,4 +17,10 @@ NXphysical_process(NXobject): method(NX_CHAR): doc: | Method by which this process was performed. + notes(NXnote): + doc: | + This can be any data or other descriptor acquired during the chemical process + (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXphysical_process.yaml b/contributed_definitions/nyaml/NXphysical_process.yaml index 7de63b4684..9b4855ad3f 100644 --- a/contributed_definitions/nyaml/NXphysical_process.yaml +++ b/contributed_definitions/nyaml/NXphysical_process.yaml @@ -16,4 +16,10 @@ NXactivity(NXobject): Short description of the activity. method(NX_CHAR): doc: | - Method by which this process was performed. \ No newline at end of file + Method by which this process was performed. + notes(NXnote): + doc: | + This can be any data or other descriptor acquired during the physical process + (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. \ No newline at end of file From bbe595019cdbec4949bde7b0fa257666d0ee5673 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 29 Aug 2023 18:20:45 +0200 Subject: [PATCH 0208/1012] Add more links to NXsubstance --- contributed_definitions/NXsubstance.nxdl.xml | 5 +++-- contributed_definitions/nyaml/NXsubstance.yaml | 5 +++-- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/contributed_definitions/NXsubstance.nxdl.xml b/contributed_definitions/NXsubstance.nxdl.xml index 2951e4ccf0..514def8fea 100644 --- a/contributed_definitions/NXsubstance.nxdl.xml +++ b/contributed_definitions/NXsubstance.nxdl.xml @@ -74,13 +74,14 @@ - Condensed, 27 character InChIKey. + Condensed, 27 character InChI key. Hashed version of the full InChI (using the SHA-256 algorithm). - Name in the IUPAC system. + Name according to the IUPAC system (standard). + For further information, see https://iupac.org/. diff --git a/contributed_definitions/nyaml/NXsubstance.yaml b/contributed_definitions/nyaml/NXsubstance.yaml index 6769355c90..05ec4dfbdc 100644 --- a/contributed_definitions/nyaml/NXsubstance.yaml +++ b/contributed_definitions/nyaml/NXsubstance.yaml @@ -33,11 +33,12 @@ NXsubstance(NXobject): For further information, see https://iupac.org/who-we-are/divisions/division-details/inchi/. inchi_key(NX_CHAR): doc: | - Condensed, 27 character InChIKey. + Condensed, 27 character InChI key. Hashed version of the full InChI (using the SHA-256 algorithm). iupac_name(NX_CHAR): doc: | - Name in the IUPAC system. + Name according to the IUPAC system (standard). + For further information, see https://iupac.org/. smile(NX_CHAR): doc: | Identifier in the SMILES (Simplified Molecular Input Line Entry System) system From e503c9dbdf394c9c7c3cc457cfae4ecfccdf9354 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 29 Aug 2023 18:23:09 +0200 Subject: [PATCH 0209/1012] Remove any unit cell or single crystal description These will be addressed by a new PR. --- contributed_definitions/NXsubstance.nxdl.xml | 5 -- contributed_definitions/NXunit_cell.nxdl.xml | 76 ------------------- .../nyaml/NXsubstance.yaml | 5 +- .../nyaml/NXunit_cell.yaml | 35 --------- 4 files changed, 1 insertion(+), 120 deletions(-) delete mode 100644 contributed_definitions/NXunit_cell.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXunit_cell.yaml diff --git a/contributed_definitions/NXsubstance.nxdl.xml b/contributed_definitions/NXsubstance.nxdl.xml index 514def8fea..aa02f85008 100644 --- a/contributed_definitions/NXsubstance.nxdl.xml +++ b/contributed_definitions/NXsubstance.nxdl.xml @@ -115,9 +115,4 @@ - If carbon is not present, the elements are listed purely in alphabetic order of their symbol. - - - If the substance is crystalline, add description of unit cell. - - diff --git a/contributed_definitions/NXunit_cell.nxdl.xml b/contributed_definitions/NXunit_cell.nxdl.xml deleted file mode 100644 index 22644ad08d..0000000000 --- a/contributed_definitions/NXunit_cell.nxdl.xml +++ /dev/null @@ -1,76 +0,0 @@ - - - - - - Description of a unit cell, e.g. of a single crystalline material. - - - - In case it is all we know and we want to record/document it - - - - - - - - - - - - - - Crystallographic space group - - - - - Crystallographic point group, deprecated if space_group presents - - - - - Crystallography unit cell parameters a, b, and c - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma - - - - - - - - Volume of the unit cell - - - - - - diff --git a/contributed_definitions/nyaml/NXsubstance.yaml b/contributed_definitions/nyaml/NXsubstance.yaml index 05ec4dfbdc..565da244cc 100644 --- a/contributed_definitions/nyaml/NXsubstance.yaml +++ b/contributed_definitions/nyaml/NXsubstance.yaml @@ -63,7 +63,4 @@ NXsubstance(NXobject): 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. - (NXunit_cell): - doc: | - If the substance is crystalline, add description of unit cell. \ No newline at end of file + - If carbon is not present, the elements are listed purely in alphabetic order of their symbol. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXunit_cell.yaml b/contributed_definitions/nyaml/NXunit_cell.yaml deleted file mode 100644 index e13d6aeacb..0000000000 --- a/contributed_definitions/nyaml/NXunit_cell.yaml +++ /dev/null @@ -1,35 +0,0 @@ -category: base -doc: | - Description of a unit cell, e.g. of a single crystalline material. - -type: group -NXunit_cell(NXobject): - class(NX_CHAR): - doc: | - In case it is all we know and we want to record/document it - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - space_group(NX_CHAR): - doc: | - Crystallographic space group - point_group(NX_CHAR): - doc: | - Crystallographic point group, deprecated if space_group presents - a_b_c(NX_FLOAT): - unit: NX_LENGTH - doc: | - Crystallography unit cell parameters a, b, and c - dimensions: - dim: [[1, 3]] - alpha_beta_gamma(NX_FLOAT): - unit: NX_ANGLE - doc: | - Crystallography unit cell parameters alpha, beta, and gamma - dimensions: - dim: [[1, 3]] - volume(NX_FLOAT): - unit: NX_VOLUME - doc: | - Volume of the unit cell - dimensions: - rank: 1 - dim: [[1, 3]] \ No newline at end of file From fa8e00b782c836dc978b6846635c82887c540251 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 29 Aug 2023 18:31:14 +0200 Subject: [PATCH 0210/1012] Change units in NXsample_component_set --- contributed_definitions/NXsample_component_set.nxdl.xml | 4 ++-- contributed_definitions/nyaml/NXsample_component_set.yaml | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/contributed_definitions/NXsample_component_set.nxdl.xml b/contributed_definitions/NXsample_component_set.nxdl.xml index eb0f06d094..80c0e4b5e0 100644 --- a/contributed_definitions/NXsample_component_set.nxdl.xml +++ b/contributed_definitions/NXsample_component_set.nxdl.xml @@ -34,7 +34,7 @@ for all materials descriptors that are not part of the individual sample components, but rather their configuration. - + Concentration of each component @@ -50,7 +50,7 @@ - + Scattering length density of each component diff --git a/contributed_definitions/nyaml/NXsample_component_set.yaml b/contributed_definitions/nyaml/NXsample_component_set.yaml index 023d21c7cb..fad1921ce4 100644 --- a/contributed_definitions/nyaml/NXsample_component_set.yaml +++ b/contributed_definitions/nyaml/NXsample_component_set.yaml @@ -9,7 +9,7 @@ symbols: type: group NXsample_component_set(NXobject): concentration(NX_FLOAT): - unit: NX_UNITLESS + unit: NX_ANY doc: | Concentration of each component dimensions: @@ -23,7 +23,7 @@ NXsample_component_set(NXobject): rank: 1 dim: [[1, n_comp]] scattering_length_density(NX_FLOAT): - unit: NX_SCATTERING_LENGTH_DENSITY + unit: NX_ANY doc: | Scattering length density of each component dimensions: From b5f81b74947027b497d984b9babaa21d56c80a30 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 29 Aug 2023 18:51:15 +0200 Subject: [PATCH 0211/1012] Add limits to no. of component sets and substances There can only ever be one NXsample_component_set in any NXsample or NXsample_component. There can only ever be one NXsubstance in any NXsample or NXsample_component -> in this case, we are talking about a pure material --- base_classes/NXsample.nxdl.xml | 8 +++++--- base_classes/NXsample_component.nxdl.xml | 8 +++++--- base_classes/nyaml/NXsample.yaml | 5 ++++- base_classes/nyaml/NXsample_component.yaml | 7 +++++-- 4 files changed, 19 insertions(+), 9 deletions(-) diff --git a/base_classes/NXsample.nxdl.xml b/base_classes/NXsample.nxdl.xml index 59912e98e1..c4d957ac70 100755 --- a/base_classes/NXsample.nxdl.xml +++ b/base_classes/NXsample.nxdl.xml @@ -485,14 +485,16 @@ This group describes the shape of the sample - + Set of sample components and their configuration. + There can only be one NXsample_component_set in one component. - + - Any substance contained in the sample. + If the sample is made from a pure substance and cannot be further divided using + NXsample_component. diff --git a/base_classes/NXsample_component.nxdl.xml b/base_classes/NXsample_component.nxdl.xml index db51f0ab64..4fea17df69 100644 --- a/base_classes/NXsample_component.nxdl.xml +++ b/base_classes/NXsample_component.nxdl.xml @@ -187,14 +187,16 @@ As a function of Wavelength - + Set of sub-components and their configuration. + There can only be one NXsample_component_set in one component. - + - Any substance contained in the component. + If the component is made from a pure substance and cannot be further divided + using NXsample_component. diff --git a/base_classes/nyaml/NXsample.yaml b/base_classes/nyaml/NXsample.yaml index 1c75c6d36b..6e1d014e58 100644 --- a/base_classes/nyaml/NXsample.yaml +++ b/base_classes/nyaml/NXsample.yaml @@ -319,9 +319,12 @@ NXsample(NXobject): (NXsample_component_set): doc: | Set of sample components and their configuration. + There can only be one NXsample_component_set in one component. + exists: [min, 1, max, 1] (NXsubstance): doc: | - Any substance contained in the sample. + If the sample is made from a pure substance and cannot be further divided using NXsample_component. + exists: [min, 1, max, 1] (NXfabrication): doc: | Details about the sample vendor (company or research group) diff --git a/base_classes/nyaml/NXsample_component.yaml b/base_classes/nyaml/NXsample_component.yaml index e874c03c23..96dc17a601 100644 --- a/base_classes/nyaml/NXsample_component.yaml +++ b/base_classes/nyaml/NXsample_component.yaml @@ -110,9 +110,12 @@ NXsample_component(NXobject): (NXsample_component_set): doc: | Set of sub-components and their configuration. + There can only be one NXsample_component_set in one component. + exists: [min, 1, max, 1] (NXsubstance): - doc: | - Any substance contained in the component. + doc: | + If the component is made from a pure substance and cannot be further divided using NXsample_component. + exists: [min, 1, max, 1] (NXfabrication): doc: | Details about the sample component vendor (company or research group) From 7335a14884f82b035690ef5aa2a77682f2c0f276 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 29 Aug 2023 18:53:40 +0200 Subject: [PATCH 0212/1012] Add a depends_on field in NXsample_component Describe the dependancy of the sample_ component to an instance of the NXsample_component_set (at the same level of granularity where the instance of component is located). --- base_classes/NXsample_component.nxdl.xml | 6 ++++++ base_classes/nyaml/NXsample_component.yaml | 4 ++++ 2 files changed, 10 insertions(+) diff --git a/base_classes/NXsample_component.nxdl.xml b/base_classes/NXsample_component.nxdl.xml index 4fea17df69..294933311c 100644 --- a/base_classes/NXsample_component.nxdl.xml +++ b/base_classes/NXsample_component.nxdl.xml @@ -210,6 +210,12 @@ experiment. + + + Any NXsample_component depends on the instance of NXsample_component_set, at the same level of + description granularity where the component is located. + + .. index:: plotting diff --git a/base_classes/nyaml/NXsample_component.yaml b/base_classes/nyaml/NXsample_component.yaml index 96dc17a601..cb3f06c372 100644 --- a/base_classes/nyaml/NXsample_component.yaml +++ b/base_classes/nyaml/NXsample_component.yaml @@ -122,6 +122,10 @@ NXsample_component(NXobject): (NXsample_history): doc: | A set of physical processes that occurred to the sample component prior/during experiment. + depends_on(NX_CHAR): + doc: | + Any NXsample_component depends on the instance of NXsample_component_set, at the same level of + description granularity where the component is located. \@default: doc: | .. index:: plotting From 633344a7a6237fb89f553abfa236b986670cfc1f Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 30 Aug 2023 11:22:47 +0200 Subject: [PATCH 0213/1012] Refactor crystal structure --- base_classes/nyaml/NXsample.yaml | 3 + .../nyaml/NXcrystal_structure.yaml | 129 +----------------- .../nyaml/NXrotation_set.yaml | 45 ++++-- .../nyaml/NXsingle_crystal.yaml | 3 + .../nyaml/NXunit_cell.yaml | 122 ++++++++++++++--- 5 files changed, 144 insertions(+), 158 deletions(-) diff --git a/base_classes/nyaml/NXsample.yaml b/base_classes/nyaml/NXsample.yaml index 79e0ac80df..46d5fa26e4 100644 --- a/base_classes/nyaml/NXsample.yaml +++ b/base_classes/nyaml/NXsample.yaml @@ -316,6 +316,9 @@ NXsample(NXobject): exists: ['min', '0'] doc: | This group describes the shape of the sample + (NXsingle_crystal): + doc: | + If the sample is a single crystal, add description of single crystal and unit cell. \@default: doc: | .. index:: plotting diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml index f9e1f8e848..b9cd234abd 100644 --- a/contributed_definitions/nyaml/NXcrystal_structure.yaml +++ b/contributed_definitions/nyaml/NXcrystal_structure.yaml @@ -1,131 +1,6 @@ -# in the long run this base class should be refactored based on feedback from -# other diffraction methods to arrive maybe at an NXem_crystal_structure_model_ebsd_parsed.yaml -category: base -doc: | - Crystal structure phase models used for indexing Kikuchi pattern. - - This base class contains key metadata relevant to every physical - kinematic or dynamic diffraction model which is used for simulating - Kikuchi diffraction pattern. - The actual indexing of Kikuchi patterns may use different algorithms. - Such are used within different workflows where simulated and measured - Kikuchi pattern are compared to rate which phase and orientation is the most - likely candidate describing the pattern measured at that each scan point - respectively. If this evaluation yields scan points without any solutions, - these are represented using the null-phase model phase0, aka n/a aka notIndexed. - - Traditionally, Hough transformation-based indexing has been the most frequently - used algorithm. Dictionary-based alternatives are emerging. -symbols: - n_hkl: | - Number of reflectors (Miller crystallographic plane triplets). - n_pos: | - Number of atom positions. type: group -NXem_ebsd_crystal_structure_model(NXobject): - # for EBSD specifically we need to know the assumed crystal structure - # with assumed statistically distributed atoms, i.e. structure and atom - # positions - crystallographic_database_identifier: - doc: | - Identifier of an entry resolvable via crystallographic_database - which was used for creating this structure model. - crystallographic_database: - doc: | - Name of the crystallographic database to resolve - crystallographic_database_identifier e.g. COD, ICSD, or others. - - # defined using which convention? - unit_cell_abc(R+): - unit: NX_LENGTH - doc: | - Crystallography unit cell parameters a, b, and c. - dim: (3,) - # defined using which convention? - unit_cell_alphabetagamma(R+): - unit: NX_ANGLE - doc: | - Crystallography unit cell parameters alpha, beta, and gamma. - dim: (3,) - unit_cell_volume(R+): - unit: NX_VOLUME - doc: | - Volume of the unit cell - space_group: - doc: | - Crystallographic space group - # add enumeration of all possible - is_centrosymmetric(NX_BOOLEAN): - doc: | - True if space group is considered a centrosymmetric one. - False if space group is considered a non-centrosymmetric one. - Centrosymmetric has all types and combinations of symmetry elements - (translation, rotational axis, mirror planes, center of inversion) - Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). - Chiral compared to non-centrosymmetric is constrained (no mirror planes). - is_chiral(NX_BOOLEAN): - doc: | - True if space group is considered a chiral one. - False if space group is consider a non-chiral one. - laue_group: - doc: | - Laue group - # add enumeration of all possible - point_group: - doc: | - Point group using International Notation. - # add enumeration all possible - unit_cell_class: - doc: | - Crystal system - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - phase_identifier(N0): - unit: NX_UNITLESS - doc: | - Identifier for each phase. The value 0 is reserved for the unknown phase - which represents the null-model that no phase model was sufficiently - significantly confirmed, i.e. the phase_name is n/a or notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - NXem_ebsd_crystal_structure_model named phase0 and phase1 - should be stored in the HDF5 file. - phase_name: - doc: | - Name of the phase/alias. - In the case that the NXem_ebsd_crystal_structure_model base class is - used with analyzed orientation maps (e.g. NXms_ipf instances or alike) - this field may have the value **n/a** or equivalently **notIndexed** - thereby reporting the null-model the unknown phase. - atom_identifier: - doc: | - Labels for each atom position - dim: (n_pos,) - atom(N0): - unit: NX_UNITLESS - doc: | - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) `_ - dim: (n_pos,) - atom_positions(R): - unit: NX_LENGTH - doc: | - Atom positions x, y, z. - dim: (n_pos, 3) - depends_on: - doc: | - Reference to an instance of NXcoordinate_system - whereby the positions can be resolved. - # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory - # to describe the simulated Kikuchi pattern generated from such a model - atom_occupancy(R+0): - unit: NX_DIMENSIONLESS - doc: | - Relative occupancy of the atom position. - dim: (n_pos,) +NXcrystal_structure(NXobject): + number_of_planes(N): unit: NX_UNITLESS doc: | diff --git a/contributed_definitions/nyaml/NXrotation_set.yaml b/contributed_definitions/nyaml/NXrotation_set.yaml index 4f0634d86a..a6a6cd93d3 100644 --- a/contributed_definitions/nyaml/NXrotation_set.yaml +++ b/contributed_definitions/nyaml/NXrotation_set.yaml @@ -64,14 +64,14 @@ NXrotation_set(NXobject): symmetries are anyway not fully observed and thus an accepting of eventual inaccuracies just for the sake of reporting a simplified symmetrized description can be avoided. - rotation_quaternion(R): # H \in SO3 + rotation_quaternion(NX_FLOAT): # H \in SO3 unit: NX_DIMENSIONLESS doc: | The set of rotations expressed in quaternion representation. The assumed crystal and sample symmetry point group is 1, triclinic. Rotations which should be interpreted as antipodal are not marked as such. dim: (c, 4) - rotation_euler(R): + rotation_euler(NX_FLOAT): unit: NX_ANGLE doc: | The set of rotations expressed in Euler angle representation following @@ -80,9 +80,9 @@ NXrotation_set(NXobject): conventions behind depends_on to resolve which of the many Euler-angle conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. dim: (c, 3) - # rotation_rodrigues(R): - # rotation_homochoric(R): - # rotation_axis_angle(R): + # rotation_rodrigues(NX_FLOAT): + # rotation_homochoric(NX_FLOAT): + # rotation_axis_angle(NX_FLOAT): # orientation how to rotate the crystal into sample and vice versa obeying crystal and sample symmetry is_antipodal(NX_BOOLEAN): @@ -90,7 +90,7 @@ NXrotation_set(NXobject): True for all those values which are considered antipodal, false for those which are not considered antipodal. dim: (c,) - orientation_quaternion(R): + orientation_quaternion(NX_FLOAT): unit: NX_DIMENSIONLESS doc: | The set of orientations expressed in quaternion representation and @@ -98,7 +98,7 @@ NXrotation_set(NXobject): and sample_symmetry. The supplementary field is_antipodal can be used to mark orientations which are antipodal. dim: (c, 4) - orientation_euler(R): + orientation_euler(NX_FLOAT): unit: NX_ANGLE doc: | The set of orientations expressed in Euler angle representation following @@ -107,26 +107,41 @@ NXrotation_set(NXobject): conventions behind depends_on to resolve which of the many Euler-angle conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. dim: (c, 3) - # orientation_rodrigues(R): - # orientation_homochoric(R): - # orientation_axis_angle(R): + orientation_busing_levy(NX_FLOAT): + unit: NX_ANGLE + doc: | + This will follow the Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + ub_matrix(NX_FLOAT): + doc: | + UB matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is + the multiplication of the orientation_matrix, given above, + with the :math:`B` matrix which + can be derived from the lattice constants. + dimensions: + rank: 3 + dim: [[1, 3], [2, 3], [3, 3]] + # orientation_rodrigues(NX_FLOAT): + # orientation_homochoric(NX_FLOAT): + # orientation_axis_angle(NX_FLOAT): # misorientation between two orientations, ignoring if the angular argument # is smallest. - misorientation_quaternion(R): + misorientation_quaternion(NX_FLOAT): unit: NX_DIMENSIONLESS doc: | The set of misorientations expressed in quaternion representation and obeying symmetry operations for equivalent misorientations as defined by crystal_symmetry and sample_symmetry. dim: (c, 4) - misorientation_angle(R): + misorientation_angle(NX_FLOAT): unit: NX_ANGLE doc: | Misorientation angular argument (eventually signed) following the same symmetry assumptions as expressed for the field misorientation_quaternion. dim: (c,) - misorientation_axis(R): + misorientation_axis(NX_FLOAT): unit: NX_DIMENSIONLESS doc: | Misorientation axis (normalized) and signed following the same @@ -135,7 +150,7 @@ NXrotation_set(NXobject): # disorientation, misorientation with smallest angular argument inside # fundamental zone of SO3 for given crystal and sample symmetry - disorientation_quaternion(R): + disorientation_quaternion(NX_FLOAT): unit: NX_DIMENSIONLESS doc: | The set of disorientation expressed in quaternion representation and @@ -149,7 +164,7 @@ NXrotation_set(NXobject): following the same symmetry assumptions as expressed for the field disorientation_quaternion. dim: (c,) - disorientation_axis(R): + disorientation_axis(NX_FLOAT): unit: NX_DIMENSIONLESS doc: | Disorientation axis (normalized) following the same symmetry assumptions diff --git a/contributed_definitions/nyaml/NXsingle_crystal.yaml b/contributed_definitions/nyaml/NXsingle_crystal.yaml index 27a193423a..2c53e04ce3 100644 --- a/contributed_definitions/nyaml/NXsingle_crystal.yaml +++ b/contributed_definitions/nyaml/NXsingle_crystal.yaml @@ -28,5 +28,8 @@ NXsingle_crystal(NXobject): dimensions: rank: 3 dim: [[1, 3], [2, 3], [3, 3]] + rotation_set(NXrotation_set): + doc: | + Detailed description of single crystal orientation and misorientation. (NXunit_cell): doc: Unit cell of the material. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXunit_cell.yaml b/contributed_definitions/nyaml/NXunit_cell.yaml index e12886486b..ffadf9de08 100644 --- a/contributed_definitions/nyaml/NXunit_cell.yaml +++ b/contributed_definitions/nyaml/NXunit_cell.yaml @@ -1,35 +1,125 @@ category: base doc: | - Description of a unit cell, e.g. of a single crystalline material. - + Description of a unit cell, i.e., the crystal structure of a single + thermodynamic phase. +symbols: + n_pos: | + Number of atom positions. type: group NXunit_cell(NXobject): - class(NX_CHAR): + crystallographic_database_identifier(NX_CHAR): doc: | - In case it is all we know and we want to record/document it + Identifier of an entry resolvable via crystallographic_database + which was used for creating this structure model. + crystallographic_database(NX_CHAR): + doc: | + Name of the crystallographic database to resolve + crystallographic_database_identifier e.g. COD, ICSD, or others. + lattice_system(NX_CHAR): + doc: | + A lattice system is a group of lattices with the same set of lattice point groups. + For further information, see https://en.wikipedia.org/wiki/Crystal_system. enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] space_group(NX_CHAR): doc: | - Crystallographic space group + Crystallographic space groups. + International Table for Crystallography. point_group(NX_CHAR): doc: | - Crystallographic point group, deprecated if space_group presents - abc(NX_FLOAT): + Crystallographic point group. + A crystallographic point group is a set of symmetry operations, + corresponding to one of the point groups in three dimensions, + such that each operation (perhaps followed by a translation) + would leave the structure of a crystal unchanged. + Using Schönflies notation. + laue_group(NX_CHAR): + doc: | + Laue group + # defined using which convention? + a_b_c(NX_FLOAT): unit: NX_LENGTH doc: | Crystallography unit cell parameters a, b, and c - dimensions: - dim: [[1, 3]] - alphabetagamma(NX_FLOAT): + dim: (3,) + base_vector_a(NX_FLOAT): + doc: | + Crystallography unit cell vector a + unit: NX_LENGTH + dim: (3,) + \@depends_on: + For definining which coordinate system the unit cell vector is defined in. + base_vector_b(NX_FLOAT): + doc: | + Crystallography unit cell vector b + unit: NX_LENGTH + dim: (3,) + \@depends_on: + For definining which coordinate system the unit cell vector is defined in. + base_vector_c(NX_FLOAT): + doc: | + Crystallography unit cell vector c + unit: NX_LENGTH + dim: (3,) + \@depends_on: + For definining which coordinate system the unit cell vector is defined in. + alpha_beta_gamma(NX_FLOAT): unit: NX_ANGLE doc: | - Crystallography unit cell parameters alpha, beta, and gamma - dimensions: - dim: [[1, 3]] + Crystallography unit cell angles alpha, beta, and gamma + dim: (3,) volume(NX_FLOAT): unit: NX_VOLUME doc: | Volume of the unit cell - dimensions: - rank: 1 - dim: [[1, 3]] \ No newline at end of file + # add enumeration of all possible + is_centrosymmetric(NX_BOOLEAN): + doc: | + True if space group is considered a centrosymmetric one. + False if space group is considered a non-centrosymmetric one. + Centrosymmetric has all types and combinations of symmetry elements + (translation, rotational axis, mirror planes, center of inversion) + Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). + Chiral compared to non-centrosymmetric is constrained (no mirror planes). + is_chiral(NX_BOOLEAN): + doc: | + True if space group is considered a chiral one. + False if space group is consider a non-chiral one. + phase_identifier(NX_UINT): + unit: NX_UNITLESS + doc: | + Identifier for the phase. + The value 0 is reserved for the unknown phase which represents the null-model + that no phase model was sufficiently significantly confirmed. + phase_name: + doc: | + Trivial name of the phase/alias. + atom_identifier: + doc: | + Labels for each atom position + dim: (n_pos,) + atom(NX_UINT): + unit: NX_UNITLESS + doc: | + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) `_ + dim: (n_pos,) + atom_positions(NX_FLOAT): + unit: NX_LENGTH + doc: | + Atom positions x, y, z. + dim: (n_pos, 3) + \@depends_on: + doc: | + Reference to an instance of NXcoordinate_system whereby the positions can + be resolved. + atom_occupancy(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + Relative occupancy of the atom position. + dim: (n_pos,) + depends_on: + doc: | + For definining which coordinate system the unit cell parameters are defined in. + \ No newline at end of file From 90e239138b49b7ed86f3456b58ec01db8774c014 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 30 Aug 2023 12:06:11 +0200 Subject: [PATCH 0214/1012] Error fixing in naming --- contributed_definitions/NXchemical_process.nxdl.xml | 2 +- contributed_definitions/NXphysical_process.nxdl.xml | 2 +- contributed_definitions/nyaml/NXchemical_process.yaml | 5 ++--- contributed_definitions/nyaml/NXphysical_process.yaml | 2 +- 4 files changed, 5 insertions(+), 6 deletions(-) diff --git a/contributed_definitions/NXchemical_process.nxdl.xml b/contributed_definitions/NXchemical_process.nxdl.xml index 9508c610c0..65485a69e9 100644 --- a/contributed_definitions/NXchemical_process.nxdl.xml +++ b/contributed_definitions/NXchemical_process.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + A planned or unplanned process which results in chemical changes in a specified material. A physical change involve changes in the chemical bonds. diff --git a/contributed_definitions/NXphysical_process.nxdl.xml b/contributed_definitions/NXphysical_process.nxdl.xml index c774158b5a..13b5713637 100644 --- a/contributed_definitions/NXphysical_process.nxdl.xml +++ b/contributed_definitions/NXphysical_process.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + A planned or unplanned process which results in physical changes in a specified material. A physical change involve changes only in intermolecular forces, not in the chemical bonds. diff --git a/contributed_definitions/nyaml/NXchemical_process.yaml b/contributed_definitions/nyaml/NXchemical_process.yaml index 20b2f35de4..de42e1ed05 100644 --- a/contributed_definitions/nyaml/NXchemical_process.yaml +++ b/contributed_definitions/nyaml/NXchemical_process.yaml @@ -4,7 +4,7 @@ doc: | A physical change involve changes in the chemical bonds. Examples include any chemical reactions (addition, subtraction, replacement, ...). type: group -NXphysical_process(NXobject): +NXchemical_process(NXobject): start_time(NX_DATE_TIME): doc: | ISO 8601 formatted time code with local time zone offset to UTC information included when this process started. @@ -22,5 +22,4 @@ NXphysical_process(NXobject): This can be any data or other descriptor acquired during the chemical process (NXnote allows to add pictures, audio, movies). Alternatively, a reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - \ No newline at end of file + case these are not available, free-text description. diff --git a/contributed_definitions/nyaml/NXphysical_process.yaml b/contributed_definitions/nyaml/NXphysical_process.yaml index 9b4855ad3f..9f6d271aeb 100644 --- a/contributed_definitions/nyaml/NXphysical_process.yaml +++ b/contributed_definitions/nyaml/NXphysical_process.yaml @@ -4,7 +4,7 @@ doc: | A physical change involve changes only in intermolecular forces, not in the chemical bonds. Examples include sample preparation, material transformation, or (partially) destrustive measurement. type: group -NXactivity(NXobject): +NXphysical_process(NXobject): start_time(NX_DATE_TIME): doc: | ISO 8601 formatted time code with local time zone offset to UTC information included when this process started. From b1f3cc98450a79eb99d72c261a157d056c18ce55 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 30 Aug 2023 12:06:26 +0200 Subject: [PATCH 0215/1012] Add array of components in NXsample_component In order to know the ordering of components in the concentaration, volume_Fraction, ... fields, we need an array of strings refering to the names of the NXsample_components. The order of these components serves as an index (starting at 1). --- contributed_definitions/NXsample_component_set.nxdl.xml | 6 ++++++ contributed_definitions/nyaml/NXsample_component_set.yaml | 4 ++++ 2 files changed, 10 insertions(+) diff --git a/contributed_definitions/NXsample_component_set.nxdl.xml b/contributed_definitions/NXsample_component_set.nxdl.xml index 80c0e4b5e0..0488c3dc5f 100644 --- a/contributed_definitions/NXsample_component_set.nxdl.xml +++ b/contributed_definitions/NXsample_component_set.nxdl.xml @@ -34,6 +34,12 @@ for all materials descriptors that are not part of the individual sample components, but rather their configuration. + + + Array of strings refering to the names of the NXsample_components. + The order of these components serves as an index (starting at 1). + + Concentration of each component diff --git a/contributed_definitions/nyaml/NXsample_component_set.yaml b/contributed_definitions/nyaml/NXsample_component_set.yaml index fad1921ce4..1602badd9e 100644 --- a/contributed_definitions/nyaml/NXsample_component_set.yaml +++ b/contributed_definitions/nyaml/NXsample_component_set.yaml @@ -8,6 +8,10 @@ symbols: number of components type: group NXsample_component_set(NXobject): + \@components: + doc: | + Array of strings refering to the names of the NXsample_components. + The order of these components serves as an index (starting at 1). concentration(NX_FLOAT): unit: NX_ANY doc: | From 209d7e36495e5232bdece8f17b59d858987829f9 Mon Sep 17 00:00:00 2001 From: Rubel Date: Mon, 28 Aug 2023 11:48:16 +0200 Subject: [PATCH 0216/1012] Adding flag for store_nxdl option in nyaml2nxdl converter. Resolving CI error. Replacing link by field in NXsts application. Fix test! Fix test! Extending nyaml2nxdl options by '--do-not-store-nxdl' --- dev_tools/nyaml2nxdl/nyaml2nxdl.py | 46 ++++++++++++++--------- dev_tools/nyaml2nxdl/nyaml2nxdl_helper.py | 5 ++- 2 files changed, 31 insertions(+), 20 deletions(-) diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl.py b/dev_tools/nyaml2nxdl/nyaml2nxdl.py index 29d2db04ff..6aecbe3962 100755 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl.py +++ b/dev_tools/nyaml2nxdl/nyaml2nxdl.py @@ -31,7 +31,7 @@ from .nyaml2nxdl_backward_tools import compare_niac_and_my from .nyaml2nxdl_forward_tools import nyaml2nxdl from .nyaml2nxdl_forward_tools import pretty_print_xml -from .nyaml2nxdl_helper import extend_yamlfile_with_comment +from .nyaml2nxdl_helper import extend_yamlfile_by_nxdl_as_comment from .nyaml2nxdl_helper import get_sha256_hash from .nyaml2nxdl_helper import separate_hash_yaml_and_nxdl @@ -41,16 +41,17 @@ # https://manual.nexusformat.org/nxdl_desc.html?highlight=optional -def generate_nxdl_or_retrieve_nxdl(yaml_file, out_xml_file, verbose): +def generate_nxdl_or_retrieve_nxdl(yaml_in, xml_out, verbose): """ - Generate yaml, nxdl and hash. - if the extracted hash is exactly the same as producd from generated yaml then - retrieve the nxdl part from provided yaml. - Else, generate nxdl from separated yaml with the help of nyaml2nxdl function + Generate yaml, nxdl, and hash. + If the extracted hash is exactly the same as generated from input yaml then + retrieve the nxdl part from provided yaml and return nxdl as output. + Else, generate nxdl from input yaml with the help of nyaml2nxdl function """ - pa_path, rel_file = os.path.split(yaml_file) - sep_yaml = os.path.join(pa_path, f"temp_{rel_file}") - hash_found = separate_hash_yaml_and_nxdl(yaml_file, sep_yaml, out_xml_file) + + file_path, rel_file = os.path.split(yaml_in) + sep_yaml = os.path.join(file_path, f"temp_{rel_file}") + hash_found = separate_hash_yaml_and_nxdl(yaml_in, sep_yaml, xml_out) if hash_found: gen_hash = get_sha256_hash(sep_yaml) @@ -58,7 +59,7 @@ def generate_nxdl_or_retrieve_nxdl(yaml_file, out_xml_file, verbose): os.remove(sep_yaml) return - nyaml2nxdl(sep_yaml, out_xml_file, verbose) + nyaml2nxdl(sep_yaml, xml_out, verbose) os.remove(sep_yaml) @@ -190,6 +191,15 @@ def split_name_and_extension(file_name): "output file of the same extension(*_consistency.yaml or *_consistency.nxdl.xml)" ), ) +@click.option( + "--do-not-store-nxdl", + is_flag=True, + default=True, + help=( + "Whether the input nxdl file will be stored as a comment" + " at the end of output yaml file." + ), +) @click.option( "--verbose", is_flag=True, @@ -197,7 +207,7 @@ def split_name_and_extension(file_name): help="Print in standard output keywords and value types to help \ possible issues in yaml files", ) -def launch_tool(input_file, verbose, append, check_consistency): +def launch_tool(input_file, verbose, append, do_not_store_nxdl, check_consistency): """ Main function that distiguishes the input file format and launches the tools. """ @@ -222,7 +232,7 @@ def launch_tool(input_file, verbose, append, check_consistency): yaml_out_file = raw_name + "_parsed" + ".yaml" converter = Nxdl2yaml([], []) converter.print_yml(input_file, yaml_out_file, verbose) - # Append nxdl.xml file with yaml output file + # Store nxdl.xml file in output yaml file under SHA HASH yaml_hash = get_sha256_hash(yaml_out_file) # Lines as divider between yaml and nxdl top_lines = [ @@ -232,12 +242,12 @@ def launch_tool(input_file, verbose, append, check_consistency): ), f"# {yaml_hash}\n", ] - - extend_yamlfile_with_comment( - yaml_file=yaml_out_file, - file_to_be_appended=input_file, - top_lines_list=top_lines, - ) + if do_not_store_nxdl: + extend_yamlfile_by_nxdl_as_comment( + yaml_file=yaml_out_file, + file_to_be_appended=input_file, + top_lines_list=top_lines, + ) else: append_yml(input_file, append, verbose) # Taking care of consistency running diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl_helper.py b/dev_tools/nyaml2nxdl/nyaml2nxdl_helper.py index c55f5da7a8..8eda728e35 100644 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl_helper.py +++ b/dev_tools/nyaml2nxdl/nyaml2nxdl_helper.py @@ -2,7 +2,6 @@ """Main file of yaml2nxdl tool. Users create NeXus instances by writing a YAML file which details a hierarchy of data/metadata elements - """ # -*- coding: utf-8 -*- # @@ -175,7 +174,9 @@ def get_sha256_hash(file_name): return sha_hash.hexdigest() -def extend_yamlfile_with_comment(yaml_file, file_to_be_appended, top_lines_list=None): +def extend_yamlfile_by_nxdl_as_comment( + yaml_file, file_to_be_appended, top_lines_list=None +): """Extend yaml file by the file_to_be_appended as comment.""" with open(yaml_file, mode="a+", encoding="utf-8") as f1_obj: From ee5baad0d94c49420a25ea7e32a410311a61f315 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 30 Aug 2023 12:22:53 +0200 Subject: [PATCH 0217/1012] Docstring fixes, remove unneeded NX_CHAR types --- base_classes/NXsample.nxdl.xml | 4 ++-- base_classes/NXsample_component.nxdl.xml | 4 ++-- base_classes/nyaml/NXsample.yaml | 4 ++-- base_classes/nyaml/NXsample_component.yaml | 4 ++-- contributed_definitions/NXactivity.nxdl.xml | 12 +++++----- .../NXchemical_process.nxdl.xml | 16 +++++++------- .../NXphysical_process.nxdl.xml | 14 ++++++------ .../NXsample_component_set.nxdl.xml | 4 ++-- .../NXsample_history.nxdl.xml | 6 ++--- contributed_definitions/NXsubstance.nxdl.xml | 22 +++++++++---------- contributed_definitions/nyaml/NXactivity.yaml | 8 +++---- .../nyaml/NXchemical_process.yaml | 12 +++++----- .../nyaml/NXphysical_process.yaml | 10 ++++----- .../nyaml/NXsample_component_set.yaml | 4 ++-- .../nyaml/NXsample_history.yaml | 6 ++--- .../nyaml/NXsubstance.yaml | 22 +++++++++---------- 16 files changed, 76 insertions(+), 76 deletions(-) diff --git a/base_classes/NXsample.nxdl.xml b/base_classes/NXsample.nxdl.xml index c4d957ac70..fbc47994f2 100755 --- a/base_classes/NXsample.nxdl.xml +++ b/base_classes/NXsample.nxdl.xml @@ -69,7 +69,7 @@ Descriptive name of sample - + Identification number or signatures of the sample used. @@ -529,7 +529,7 @@ for a summary of the discussion. - + NeXus positions components by applying a set of translations and rotations to apply to the component starting from 0, 0, 0. The order of these operations diff --git a/base_classes/NXsample_component.nxdl.xml b/base_classes/NXsample_component.nxdl.xml index 294933311c..0690bc6660 100644 --- a/base_classes/NXsample_component.nxdl.xml +++ b/base_classes/NXsample_component.nxdl.xml @@ -61,7 +61,7 @@ Descriptive name of sample component - + Identification number or signatures of the sample component used. @@ -210,7 +210,7 @@ experiment. - + Any NXsample_component depends on the instance of NXsample_component_set, at the same level of description granularity where the component is located. diff --git a/base_classes/nyaml/NXsample.yaml b/base_classes/nyaml/NXsample.yaml index 6e1d014e58..3d49f5151d 100644 --- a/base_classes/nyaml/NXsample.yaml +++ b/base_classes/nyaml/NXsample.yaml @@ -25,7 +25,7 @@ NXsample(NXobject): name: doc: | Descriptive name of sample - sample_id(NX_CHAR): + sample_id: doc: | Identification number or signatures of the sample used. chemical_formula: @@ -349,7 +349,7 @@ NXsample(NXobject): to help define the path to the default dataset to be plotted. See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. - depends_on(NX_CHAR): + depends_on: doc: | 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 diff --git a/base_classes/nyaml/NXsample_component.yaml b/base_classes/nyaml/NXsample_component.yaml index cb3f06c372..750e5c3b6a 100644 --- a/base_classes/nyaml/NXsample_component.yaml +++ b/base_classes/nyaml/NXsample_component.yaml @@ -19,7 +19,7 @@ NXsample_component(NXobject): name: doc: | Descriptive name of sample component - sample_id(NX_CHAR): + sample_id: doc: | Identification number or signatures of the sample component used. chemical_formula: @@ -122,7 +122,7 @@ NXsample_component(NXobject): (NXsample_history): doc: | A set of physical processes that occurred to the sample component prior/during experiment. - depends_on(NX_CHAR): + depends_on: doc: | Any NXsample_component depends on the instance of NXsample_component_set, at the same level of description granularity where the component is located. diff --git a/contributed_definitions/NXactivity.nxdl.xml b/contributed_definitions/NXactivity.nxdl.xml index b7404289d0..ab549c4718 100644 --- a/contributed_definitions/NXactivity.nxdl.xml +++ b/contributed_definitions/NXactivity.nxdl.xml @@ -24,22 +24,22 @@ A planned or unplanned action that has a temporal extension and for some time depends on some entity. - This class is planned be used in the future as the supclass for all other activities if inheritance + This class is planned be used in the future as the super class for all other activities if inheritance in base classes is supported in NeXus. - ISO 8601 formatted time code with local time zone offset to UTC information - included when this activity started. + ISO 8601 formatted time code (with local time zone offset to UTC information + included) when this activity started. - ISO 8601 formatted time code with local time zone offset to UTC information - included when this activity ended. + ISO 8601 formatted time code (with local time zone offset to UTC information + included) when this activity ended. - + Short description of the activity. diff --git a/contributed_definitions/NXchemical_process.nxdl.xml b/contributed_definitions/NXchemical_process.nxdl.xml index 65485a69e9..fe921a95c1 100644 --- a/contributed_definitions/NXchemical_process.nxdl.xml +++ b/contributed_definitions/NXchemical_process.nxdl.xml @@ -23,28 +23,28 @@ --> - A planned or unplanned process which results in chemical changes in a specified material. - A physical change involve changes in the chemical bonds. + A planned or unplanned process which results in chemical changes (i.e., changes in the chemical bonds) + in a specified material. Examples include any chemical reactions (addition, subtraction, replacement, ...). - ISO 8601 formatted time code with local time zone offset to UTC information - included when this process started. + ISO 8601 formatted time code (with local time zone offset to UTC information + included) when this process started. - ISO 8601 formatted time code with local time zone offset to UTC information - included when this process ended. + ISO 8601 formatted time code (with local time zone offset to UTC information + included) when this process ended. - + Short description of the chemical process. - + Method by which this process was performed. diff --git a/contributed_definitions/NXphysical_process.nxdl.xml b/contributed_definitions/NXphysical_process.nxdl.xml index 13b5713637..ddd85fe2c1 100644 --- a/contributed_definitions/NXphysical_process.nxdl.xml +++ b/contributed_definitions/NXphysical_process.nxdl.xml @@ -25,26 +25,26 @@ A planned or unplanned process which results in physical changes in a specified material. A physical change involve changes only in intermolecular forces, not in the chemical bonds. - Examples include sample preparation, material transformation, or (partially) destrustive measurement. + Examples include sample preparation, material transformation, or (partially) destructive measurements. - ISO 8601 formatted time code with local time zone offset to UTC information - included when this process started. + ISO 8601 formatted time code (with local time zone offset to UTC information + included) when this process started. - ISO 8601 formatted time code with local time zone offset to UTC information - included when this process ended. + ISO 8601 formatted time code (with local time zone offset to UTC information + included) when this process ended. - + Short description of the activity. - + Method by which this process was performed. diff --git a/contributed_definitions/NXsample_component_set.nxdl.xml b/contributed_definitions/NXsample_component_set.nxdl.xml index 0488c3dc5f..ce32e131e2 100644 --- a/contributed_definitions/NXsample_component_set.nxdl.xml +++ b/contributed_definitions/NXsample_component_set.nxdl.xml @@ -36,7 +36,7 @@ - Array of strings refering to the names of the NXsample_components. + Array of strings referring to the names of the NXsample_components. The order of these components serves as an index (starting at 1). @@ -71,7 +71,7 @@ - For description of a sub-component set. Can contain multiple components. + For description of a sub-component set. Can contain multiple components itself. diff --git a/contributed_definitions/NXsample_history.nxdl.xml b/contributed_definitions/NXsample_history.nxdl.xml index 1050b58244..f6f21390ff 100644 --- a/contributed_definitions/NXsample_history.nxdl.xml +++ b/contributed_definitions/NXsample_history.nxdl.xml @@ -24,8 +24,8 @@ A set of activities that occurred to the sample prior/during experiment. - Ideally, a full report of the previous operations. - Alternatively, notes allows for additional descriptors in any format. + Ideally, a full report of the previous operations (or links to a chain of operations). + Alternatively, notes allow for additional descriptors in any format. @@ -60,7 +60,7 @@ subentry(NXsuxbentry): case these are not available, free-text description. This should only be used in case that there is no rigorous description using the base classes above. This field can also be used to pull in any activities - that are not well described by an existing base/application definition. + that are not well described by an existing base class definition. diff --git a/contributed_definitions/NXsubstance.nxdl.xml b/contributed_definitions/NXsubstance.nxdl.xml index aa02f85008..1eb39d5ba7 100644 --- a/contributed_definitions/NXsubstance.nxdl.xml +++ b/contributed_definitions/NXsubstance.nxdl.xml @@ -27,7 +27,7 @@ Examples can be single chemical elements, chemical compunds, or alloys. For further information, see https://en.wikipedia.org/wiki/Chemical_substance. - + User-defined chemical name of the substance @@ -37,18 +37,18 @@ Molecular mass of the substance - + Unique numeric CAS REGISTRY number of the sample chemical content For further information, see https://www.cas.org/. - + CAS REGISTRY name of the sample chemical content - + CAS REGISTRY URI @@ -58,12 +58,12 @@ CAS REGISTRY image - + Synonyms in the CAS system. - + String InChi identifier. The InChI identifier expresses chemical structures in terms of atomic connectivity, @@ -72,30 +72,30 @@ For further information, see https://iupac.org/who-we-are/divisions/division-details/inchi/. - + Condensed, 27 character InChI key. Hashed version of the full InChI (using the SHA-256 algorithm). - + Name according to the IUPAC system (standard). For further information, see https://iupac.org/. - + Identifier in the SMILES (Simplified Molecular Input Line Entry System) system For further information, see https://www.daylight.com/smiles/. - + Canonical version of the smiles identifier - + The chemical formula specified using CIF conventions. Abbreviated version of CIF standard:107 diff --git a/contributed_definitions/nyaml/NXactivity.yaml b/contributed_definitions/nyaml/NXactivity.yaml index a7f19f452e..2ae89f4b9f 100644 --- a/contributed_definitions/nyaml/NXactivity.yaml +++ b/contributed_definitions/nyaml/NXactivity.yaml @@ -1,17 +1,17 @@ category: base doc: | A planned or unplanned action that has a temporal extension and for some time depends on some entity. - This class is planned be used in the future as the supclass for all other activities if inheritance + This class is planned be used in the future as the super class for all other activities if inheritance in base classes is supported in NeXus. type: group NXactivity(NXobject): start_time(NX_DATE_TIME): doc: | - ISO 8601 formatted time code with local time zone offset to UTC information included when this activity started. + ISO 8601 formatted time code (with local time zone offset to UTC information included) when this activity started. end_time(NX_DATE_TIME): doc: | - ISO 8601 formatted time code with local time zone offset to UTC information included when this activity ended. - description(NX_CHAR): + ISO 8601 formatted time code (with local time zone offset to UTC information included) when this activity ended. + description: doc: | Short description of the activity. notes(NXnote): diff --git a/contributed_definitions/nyaml/NXchemical_process.yaml b/contributed_definitions/nyaml/NXchemical_process.yaml index de42e1ed05..e146e4a35d 100644 --- a/contributed_definitions/nyaml/NXchemical_process.yaml +++ b/contributed_definitions/nyaml/NXchemical_process.yaml @@ -1,20 +1,20 @@ category: base doc: | - A planned or unplanned process which results in chemical changes in a specified material. - A physical change involve changes in the chemical bonds. + A planned or unplanned process which results in chemical changes (i.e., changes in the chemical bonds) + in a specified material. Examples include any chemical reactions (addition, subtraction, replacement, ...). type: group NXchemical_process(NXobject): start_time(NX_DATE_TIME): doc: | - ISO 8601 formatted time code with local time zone offset to UTC information included when this process started. + ISO 8601 formatted time code (with local time zone offset to UTC information included) when this process started. end_time(NX_DATE_TIME): doc: | - ISO 8601 formatted time code with local time zone offset to UTC information included when this process ended. - description(NX_CHAR): + ISO 8601 formatted time code (with local time zone offset to UTC information included) when this process ended. + description: doc: | Short description of the chemical process. - method(NX_CHAR): + method: doc: | Method by which this process was performed. notes(NXnote): diff --git a/contributed_definitions/nyaml/NXphysical_process.yaml b/contributed_definitions/nyaml/NXphysical_process.yaml index 9f6d271aeb..a2d786f2dc 100644 --- a/contributed_definitions/nyaml/NXphysical_process.yaml +++ b/contributed_definitions/nyaml/NXphysical_process.yaml @@ -2,19 +2,19 @@ category: base doc: | A planned or unplanned process which results in physical changes in a specified material. A physical change involve changes only in intermolecular forces, not in the chemical bonds. - Examples include sample preparation, material transformation, or (partially) destrustive measurement. + Examples include sample preparation, material transformation, or (partially) destructive measurements. type: group NXphysical_process(NXobject): start_time(NX_DATE_TIME): doc: | - ISO 8601 formatted time code with local time zone offset to UTC information included when this process started. + ISO 8601 formatted time code (with local time zone offset to UTC information included) when this process started. end_time(NX_DATE_TIME): doc: | - ISO 8601 formatted time code with local time zone offset to UTC information included when this process ended. - description(NX_CHAR): + ISO 8601 formatted time code (with local time zone offset to UTC information included) when this process ended. + description: doc: | Short description of the activity. - method(NX_CHAR): + method: doc: | Method by which this process was performed. notes(NXnote): diff --git a/contributed_definitions/nyaml/NXsample_component_set.yaml b/contributed_definitions/nyaml/NXsample_component_set.yaml index 1602badd9e..3fa80f33d4 100644 --- a/contributed_definitions/nyaml/NXsample_component_set.yaml +++ b/contributed_definitions/nyaml/NXsample_component_set.yaml @@ -10,7 +10,7 @@ type: group NXsample_component_set(NXobject): \@components: doc: | - Array of strings refering to the names of the NXsample_components. + Array of strings referring to the names of the NXsample_components. The order of these components serves as an index (starting at 1). concentration(NX_FLOAT): unit: NX_ANY @@ -38,4 +38,4 @@ NXsample_component_set(NXobject): Each component set can contain multiple components. (NXsample_component_set): doc: - For description of a sub-component set. Can contain multiple components. \ No newline at end of file + For description of a sub-component set. Can contain multiple components itself. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXsample_history.yaml b/contributed_definitions/nyaml/NXsample_history.yaml index 668eca39bd..1fe595f6fe 100644 --- a/contributed_definitions/nyaml/NXsample_history.yaml +++ b/contributed_definitions/nyaml/NXsample_history.yaml @@ -1,8 +1,8 @@ category: base doc: | A set of activities that occurred to the sample prior/during experiment. - Ideally, a full report of the previous operations. - Alternatively, notes allows for additional descriptors in any format. + Ideally, a full report of the previous operations (or links to a chain of operations). + Alternatively, notes allow for additional descriptors in any format. type: group NXsample_history(NXobject): (NXactivity): @@ -30,4 +30,4 @@ NXsample_history(NXobject): case these are not available, free-text description. This should only be used in case that there is no rigorous description using the base classes above. This field can also be used to pull in any activities - that are not well described by an existing base/application definition. \ No newline at end of file + that are not well described by an existing base class definition. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXsubstance.yaml b/contributed_definitions/nyaml/NXsubstance.yaml index 565da244cc..e7b4354419 100644 --- a/contributed_definitions/nyaml/NXsubstance.yaml +++ b/contributed_definitions/nyaml/NXsubstance.yaml @@ -5,48 +5,48 @@ doc: | For further information, see https://en.wikipedia.org/wiki/Chemical_substance. type: group NXsubstance(NXobject): - name(NX_CHAR): + name: doc: User-defined chemical name of the substance molecular_mass(NX_FLOAT): unit: NX_MOLECULAR_WEIGHT doc: | Molecular mass of the substance - cas_number(NX_CHAR): + cas_number: doc: | Unique numeric CAS REGISTRY number of the sample chemical content For further information, see https://www.cas.org/. - cas_name(NX_CHAR): + cas_name: doc: CAS REGISTRY name of the sample chemical content - cas_uri(NX_CHAR): + cas_uri: doc: | CAS REGISTRY URI cas_image(NXnote): doc: CAS REGISTRY image - cas_synonyms(NX_CHAR): + cas_synonyms: doc: Synonyms in the CAS system. - inchi_str(NX_CHAR): + inchi_str: doc: | String InChi identifier. The InChI identifier expresses chemical structures in terms of atomic connectivity, tautomeric state, isotopes, stereochemistry and electronic charge in order to produce a string of machine-readable characters unique to the respective molecule. For further information, see https://iupac.org/who-we-are/divisions/division-details/inchi/. - inchi_key(NX_CHAR): + inchi_key: doc: | Condensed, 27 character InChI key. Hashed version of the full InChI (using the SHA-256 algorithm). - iupac_name(NX_CHAR): + iupac_name: doc: | Name according to the IUPAC system (standard). For further information, see https://iupac.org/. - smile(NX_CHAR): + smile: doc: | Identifier in the SMILES (Simplified Molecular Input Line Entry System) system For further information, see https://www.daylight.com/smiles/. - canonical_smile(NX_CHAR): + canonical_smile: doc: | Canonical version of the smiles identifier - molecular_formula_hill(NX_CHAR): + molecular_formula_hill: doc: | The chemical formula specified using CIF conventions. Abbreviated version of CIF standard:107 From 1b662d1e904690e7c0ef6cf1511a418fc354621f Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 30 Aug 2023 13:23:18 +0200 Subject: [PATCH 0218/1012] Enhance docs of unit cell --- .../nyaml/NXunit_cell.yaml | 43 ++++++++++--------- 1 file changed, 23 insertions(+), 20 deletions(-) diff --git a/contributed_definitions/nyaml/NXunit_cell.yaml b/contributed_definitions/nyaml/NXunit_cell.yaml index ffadf9de08..30060c017c 100644 --- a/contributed_definitions/nyaml/NXunit_cell.yaml +++ b/contributed_definitions/nyaml/NXunit_cell.yaml @@ -7,34 +7,38 @@ symbols: Number of atom positions. type: group NXunit_cell(NXobject): - crystallographic_database_identifier(NX_CHAR): + crystallographic_database_identifier: doc: | Identifier of an entry resolvable via crystallographic_database which was used for creating this structure model. - crystallographic_database(NX_CHAR): + crystallographic_database: doc: | Name of the crystallographic database to resolve crystallographic_database_identifier e.g. COD, ICSD, or others. - lattice_system(NX_CHAR): + lattice_system: doc: | A lattice system is a group of lattices with the same set of lattice point groups. For further information, see https://en.wikipedia.org/wiki/Crystal_system. enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - space_group(NX_CHAR): + space_group: doc: | - Crystallographic space groups. - International Table for Crystallography. - point_group(NX_CHAR): + Crystallographic space group. + A space group is the symmetry group of a repeating pattern in space. + For further information, see International Table for Crystallography (https://it.iucr.org/). + point_group: doc: | Crystallographic point group. - A crystallographic point group is a set of symmetry operations, - corresponding to one of the point groups in three dimensions, - such that each operation (perhaps followed by a translation) - would leave the structure of a crystal unchanged. - Using Schönflies notation. - laue_group(NX_CHAR): - doc: | - Laue group + A crystallographic point group is a set of symmetry operations, corresponding to one of the point groups in three dimensions, + such that each operation (perhaps followed by a translation) would leave the structure of a crystal unchanged. + This field should use Schoenflies notation (see Schoenflies, A., Krystallsysteme und Krystallstructur, 1891). + For further information, see https://dictionary.iucr.org/Point_group. + laue_group: + doc: | + Laue group (also called Laue class). + The Laue classes are eleven geometric crystal classes containing centrosymmetric crystallographic types of point groups and their subgroups. + When absorption is negligible and Friedel's law applies, it is impossible to distinguish by diffraction between a centrosymmetric point group + and one of its non-centrosymmetric subgroups; only point groups belonging to different Laue classes can then be distinguished. + For further information, see https://dictionary.iucr.org/Laue_class. # defined using which convention? a_b_c(NX_FLOAT): unit: NX_LENGTH @@ -47,21 +51,21 @@ NXunit_cell(NXobject): unit: NX_LENGTH dim: (3,) \@depends_on: - For definining which coordinate system the unit cell vector is defined in. + For definining which coordinate system the unit cell vector a is defined in. base_vector_b(NX_FLOAT): doc: | Crystallography unit cell vector b unit: NX_LENGTH dim: (3,) \@depends_on: - For definining which coordinate system the unit cell vector is defined in. + For definining which coordinate system the unit cell vector b is defined in. base_vector_c(NX_FLOAT): doc: | Crystallography unit cell vector c unit: NX_LENGTH dim: (3,) \@depends_on: - For definining which coordinate system the unit cell vector is defined in. + For definining which coordinate system the unit cell vector c is defined in. alpha_beta_gamma(NX_FLOAT): unit: NX_ANGLE doc: | @@ -112,8 +116,7 @@ NXunit_cell(NXobject): dim: (n_pos, 3) \@depends_on: doc: | - Reference to an instance of NXcoordinate_system whereby the positions can - be resolved. + Reference to an instance of NXcoordinate_system whereby the positions can be resolved. atom_occupancy(NX_FLOAT): unit: NX_DIMENSIONLESS doc: | From 51f1a3cc745989e59362583602910b78304cc21a Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 30 Aug 2023 13:24:58 +0200 Subject: [PATCH 0219/1012] Add more docs to NXsinglecrystal --- contributed_definitions/nyaml/NXsingle_crystal.yaml | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/nyaml/NXsingle_crystal.yaml b/contributed_definitions/nyaml/NXsingle_crystal.yaml index 2c53e04ce3..befb1db5ab 100644 --- a/contributed_definitions/nyaml/NXsingle_crystal.yaml +++ b/contributed_definitions/nyaml/NXsingle_crystal.yaml @@ -1,6 +1,8 @@ category: base doc: | Description of a single crystal material or a single crystalline phase in a material. + There is the option of using Busing-Levy convention (as orginally designed in NXsample) + or using a more detailed description with NXrotation_set. type: group NXsingle_crystal(NXobject): sample_orientation(NX_FLOAT): @@ -23,8 +25,7 @@ NXsingle_crystal(NXobject): UB matrix of single crystal sample using Busing-Levy convention: W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is the multiplication of the orientation_matrix, given above, - with the :math:`B` matrix which - can be derived from the lattice constants. + with the :math:`B` matrix which can be derived from the lattice constants. dimensions: rank: 3 dim: [[1, 3], [2, 3], [3, 3]] @@ -32,4 +33,4 @@ NXsingle_crystal(NXobject): doc: | Detailed description of single crystal orientation and misorientation. (NXunit_cell): - doc: Unit cell of the material. \ No newline at end of file + doc: Unit cell of the single crystal. \ No newline at end of file From 11336e8c5f7f77794b93d98b8c26dfccb1528de9 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 30 Aug 2023 13:25:09 +0200 Subject: [PATCH 0220/1012] Delete NXcrystal_structure.yaml --- .../nyaml/NXcrystal_structure.yaml | 31 ------------------- 1 file changed, 31 deletions(-) delete mode 100644 contributed_definitions/nyaml/NXcrystal_structure.yaml diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml deleted file mode 100644 index b9cd234abd..0000000000 --- a/contributed_definitions/nyaml/NXcrystal_structure.yaml +++ /dev/null @@ -1,31 +0,0 @@ -type: group -NXcrystal_structure(NXobject): - - number_of_planes(N): - unit: NX_UNITLESS - doc: | - How many reflectors are distinguished. Value has to - match value for symbol n_hkl. - # Miller indices :math:`(hkl)[uvw]`. - plane_miller(R): - unit: NX_UNITLESS - doc: | - Miller indices :math:`(hkl)`. - dim: (n_hkl, 3) - dspacing(R+0): - unit: NX_LENGTH - doc: | - D-spacing. - dim: (n_hkl,) - relative_intensity(R+0): - unit: NX_DIMENSIONLESS - doc: | - Relative intensity of the signal for the plane. - dim: (n_hkl,) - number_of_scan_points(N0): - unit: NX_UNITLESS - doc: | - In case the NXem_ebsd_crystal_structure_model base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - (NXms_ipf): \ No newline at end of file From 03d5d3b854ff22eb8786178ae9d42cfdfe3021ec Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 30 Aug 2023 13:25:39 +0200 Subject: [PATCH 0221/1012] Update docs in NXsample_component --- base_classes/nyaml/NXsample_component.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/base_classes/nyaml/NXsample_component.yaml b/base_classes/nyaml/NXsample_component.yaml index 154adb6760..da3c23dcbd 100644 --- a/base_classes/nyaml/NXsample_component.yaml +++ b/base_classes/nyaml/NXsample_component.yaml @@ -104,9 +104,9 @@ NXsample_component(NXobject): transmission(NXdata): doc: | As a function of Wavelength - (NXcrystal_structure): + (NXsingle_crystal): doc: | - Description of crystal structure of the sample. + If the component is a single crystal, add description of single crystal and unit cell. \@default: doc: | .. index:: plotting From 73745029d60aa6a6546410ee005ef63158f4e3f0 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 30 Aug 2023 13:25:59 +0200 Subject: [PATCH 0222/1012] Remove short-hand notation for real numbers --- contributed_definitions/nyaml/NXrotation_set.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributed_definitions/nyaml/NXrotation_set.yaml b/contributed_definitions/nyaml/NXrotation_set.yaml index a6a6cd93d3..d03c9d5237 100644 --- a/contributed_definitions/nyaml/NXrotation_set.yaml +++ b/contributed_definitions/nyaml/NXrotation_set.yaml @@ -156,7 +156,7 @@ NXrotation_set(NXobject): The set of disorientation expressed in quaternion representation and obeying symmetry operations for equivalent misorientations as defined by crystal_symmetry and sample_symmetry. - disorientation_angle(R): + disorientation_angle(NX_FLOAT): unit: NX_ANGLE doc: | Disorientation angular argument (should not be signed, see From 5ea91d77da8dfcc4bb6792c019f65af5898e8ff4 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 30 Aug 2023 14:00:59 +0200 Subject: [PATCH 0223/1012] Add a line break between the first and all following lines --- contributed_definitions/NXactivity.nxdl.xml | 1 + contributed_definitions/NXchemical_process.nxdl.xml | 4 ++-- contributed_definitions/NXphysical_process.nxdl.xml | 1 + contributed_definitions/NXsample_component_set.nxdl.xml | 7 ++++--- contributed_definitions/NXsample_history.nxdl.xml | 1 + contributed_definitions/NXsubstance.nxdl.xml | 1 + contributed_definitions/nyaml/NXactivity.yaml | 1 + contributed_definitions/nyaml/NXchemical_process.yaml | 4 ++-- contributed_definitions/nyaml/NXphysical_process.yaml | 1 + contributed_definitions/nyaml/NXsample_component_set.yaml | 7 ++++--- contributed_definitions/nyaml/NXsample_history.yaml | 1 + contributed_definitions/nyaml/NXsubstance.yaml | 1 + 12 files changed, 20 insertions(+), 10 deletions(-) diff --git a/contributed_definitions/NXactivity.nxdl.xml b/contributed_definitions/NXactivity.nxdl.xml index ab549c4718..5125bebf3b 100644 --- a/contributed_definitions/NXactivity.nxdl.xml +++ b/contributed_definitions/NXactivity.nxdl.xml @@ -24,6 +24,7 @@ A planned or unplanned action that has a temporal extension and for some time depends on some entity. + This class is planned be used in the future as the super class for all other activities if inheritance in base classes is supported in NeXus. diff --git a/contributed_definitions/NXchemical_process.nxdl.xml b/contributed_definitions/NXchemical_process.nxdl.xml index fe921a95c1..437fcf0b6a 100644 --- a/contributed_definitions/NXchemical_process.nxdl.xml +++ b/contributed_definitions/NXchemical_process.nxdl.xml @@ -23,8 +23,8 @@ --> - A planned or unplanned process which results in chemical changes (i.e., changes in the chemical bonds) - in a specified material. + A planned or unplanned process which results in chemical changes (i.e., changes in the chemical bonds) in a specified material. + Examples include any chemical reactions (addition, subtraction, replacement, ...). diff --git a/contributed_definitions/NXphysical_process.nxdl.xml b/contributed_definitions/NXphysical_process.nxdl.xml index ddd85fe2c1..d422e516c6 100644 --- a/contributed_definitions/NXphysical_process.nxdl.xml +++ b/contributed_definitions/NXphysical_process.nxdl.xml @@ -24,6 +24,7 @@ A planned or unplanned process which results in physical changes in a specified material. + A physical change involve changes only in intermolecular forces, not in the chemical bonds. Examples include sample preparation, material transformation, or (partially) destructive measurements. diff --git a/contributed_definitions/NXsample_component_set.nxdl.xml b/contributed_definitions/NXsample_component_set.nxdl.xml index ce32e131e2..aa3a0e794f 100644 --- a/contributed_definitions/NXsample_component_set.nxdl.xml +++ b/contributed_definitions/NXsample_component_set.nxdl.xml @@ -30,9 +30,10 @@ - Set of sample components and their configuration. The idea here is to have a united place - for all materials descriptors that are not part of the individual sample components, - but rather their configuration. + Set of sample components and their configuration. + + The idea here is to have a united place for all materials descriptors that are not + part of the individual sample components, but rather their configuration. diff --git a/contributed_definitions/NXsample_history.nxdl.xml b/contributed_definitions/NXsample_history.nxdl.xml index f6f21390ff..207fc41d5d 100644 --- a/contributed_definitions/NXsample_history.nxdl.xml +++ b/contributed_definitions/NXsample_history.nxdl.xml @@ -24,6 +24,7 @@ A set of activities that occurred to the sample prior/during experiment. + Ideally, a full report of the previous operations (or links to a chain of operations). Alternatively, notes allow for additional descriptors in any format. diff --git a/contributed_definitions/NXsubstance.nxdl.xml b/contributed_definitions/NXsubstance.nxdl.xml index 1eb39d5ba7..7379702133 100644 --- a/contributed_definitions/NXsubstance.nxdl.xml +++ b/contributed_definitions/NXsubstance.nxdl.xml @@ -24,6 +24,7 @@ A form of matter with a constant, definite chemical composition. + Examples can be single chemical elements, chemical compunds, or alloys. For further information, see https://en.wikipedia.org/wiki/Chemical_substance. diff --git a/contributed_definitions/nyaml/NXactivity.yaml b/contributed_definitions/nyaml/NXactivity.yaml index 2ae89f4b9f..28ef84085d 100644 --- a/contributed_definitions/nyaml/NXactivity.yaml +++ b/contributed_definitions/nyaml/NXactivity.yaml @@ -1,6 +1,7 @@ category: base doc: | A planned or unplanned action that has a temporal extension and for some time depends on some entity. + This class is planned be used in the future as the super class for all other activities if inheritance in base classes is supported in NeXus. type: group diff --git a/contributed_definitions/nyaml/NXchemical_process.yaml b/contributed_definitions/nyaml/NXchemical_process.yaml index e146e4a35d..ff5379761a 100644 --- a/contributed_definitions/nyaml/NXchemical_process.yaml +++ b/contributed_definitions/nyaml/NXchemical_process.yaml @@ -1,7 +1,7 @@ category: base doc: | - A planned or unplanned process which results in chemical changes (i.e., changes in the chemical bonds) - in a specified material. + A planned or unplanned process which results in chemical changes (i.e., changes in the chemical bonds) in a specified material. + Examples include any chemical reactions (addition, subtraction, replacement, ...). type: group NXchemical_process(NXobject): diff --git a/contributed_definitions/nyaml/NXphysical_process.yaml b/contributed_definitions/nyaml/NXphysical_process.yaml index a2d786f2dc..7df1aff164 100644 --- a/contributed_definitions/nyaml/NXphysical_process.yaml +++ b/contributed_definitions/nyaml/NXphysical_process.yaml @@ -1,6 +1,7 @@ category: base doc: | A planned or unplanned process which results in physical changes in a specified material. + A physical change involve changes only in intermolecular forces, not in the chemical bonds. Examples include sample preparation, material transformation, or (partially) destructive measurements. type: group diff --git a/contributed_definitions/nyaml/NXsample_component_set.yaml b/contributed_definitions/nyaml/NXsample_component_set.yaml index 3fa80f33d4..a9d657c52b 100644 --- a/contributed_definitions/nyaml/NXsample_component_set.yaml +++ b/contributed_definitions/nyaml/NXsample_component_set.yaml @@ -1,8 +1,9 @@ category: base doc: | - Set of sample components and their configuration. The idea here is to have a united place - for all materials descriptors that are not part of the individual sample components, - but rather their configuration. + Set of sample components and their configuration. + + The idea here is to have a united place for all materials descriptors that are not + part of the individual sample components, but rather their configuration. symbols: n_comp: | number of components diff --git a/contributed_definitions/nyaml/NXsample_history.yaml b/contributed_definitions/nyaml/NXsample_history.yaml index 1fe595f6fe..fa45cd6651 100644 --- a/contributed_definitions/nyaml/NXsample_history.yaml +++ b/contributed_definitions/nyaml/NXsample_history.yaml @@ -1,6 +1,7 @@ category: base doc: | A set of activities that occurred to the sample prior/during experiment. + Ideally, a full report of the previous operations (or links to a chain of operations). Alternatively, notes allow for additional descriptors in any format. type: group diff --git a/contributed_definitions/nyaml/NXsubstance.yaml b/contributed_definitions/nyaml/NXsubstance.yaml index e7b4354419..846f833435 100644 --- a/contributed_definitions/nyaml/NXsubstance.yaml +++ b/contributed_definitions/nyaml/NXsubstance.yaml @@ -1,6 +1,7 @@ category: base doc: | A form of matter with a constant, definite chemical composition. + Examples can be single chemical elements, chemical compunds, or alloys. For further information, see https://en.wikipedia.org/wiki/Chemical_substance. type: group From c7156532fd3f41ee367d94f9dc74817917094af6 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 30 Aug 2023 14:05:35 +0200 Subject: [PATCH 0224/1012] Comment out exists fields in NXsample and NXsample_component currently not possible for base_classes --- base_classes/NXsample.nxdl.xml | 9 ++++++--- base_classes/NXsample_component.nxdl.xml | 6 ++++-- base_classes/nyaml/NXsample.yaml | 6 +++--- base_classes/nyaml/NXsample_component.yaml | 4 ++-- 4 files changed, 15 insertions(+), 10 deletions(-) diff --git a/base_classes/NXsample.nxdl.xml b/base_classes/NXsample.nxdl.xml index fbc47994f2..69d97cb42f 100755 --- a/base_classes/NXsample.nxdl.xml +++ b/base_classes/NXsample.nxdl.xml @@ -480,23 +480,26 @@ Any positioner (motor, PZT, ...) used to locate the sample - + + This group describes the shape of the sample - + Set of sample components and their configuration. There can only be one NXsample_component_set in one component. - + + If the sample is made from a pure substance and cannot be further divided using NXsample_component. + Details about the sample vendor (company or research group) diff --git a/base_classes/NXsample_component.nxdl.xml b/base_classes/NXsample_component.nxdl.xml index 0690bc6660..17dbb1c125 100644 --- a/base_classes/NXsample_component.nxdl.xml +++ b/base_classes/NXsample_component.nxdl.xml @@ -187,18 +187,20 @@ As a function of Wavelength - + Set of sub-components and their configuration. There can only be one NXsample_component_set in one component. - + + If the component is made from a pure substance and cannot be further divided using NXsample_component. + Details about the sample component vendor (company or research group) diff --git a/base_classes/nyaml/NXsample.yaml b/base_classes/nyaml/NXsample.yaml index 3d49f5151d..1aa3de328e 100644 --- a/base_classes/nyaml/NXsample.yaml +++ b/base_classes/nyaml/NXsample.yaml @@ -313,18 +313,18 @@ NXsample(NXobject): doc: | Any positioner (motor, PZT, ...) used to locate the sample (NXoff_geometry): - exists: ['min', '0'] + # exists: ['min', '0'] doc: | This group describes the shape of the sample (NXsample_component_set): doc: | Set of sample components and their configuration. There can only be one NXsample_component_set in one component. - exists: [min, 1, max, 1] + # exists: [max, 1] (NXsubstance): doc: | If the sample is made from a pure substance and cannot be further divided using NXsample_component. - exists: [min, 1, max, 1] + # exists: [max, 1] (NXfabrication): doc: | Details about the sample vendor (company or research group) diff --git a/base_classes/nyaml/NXsample_component.yaml b/base_classes/nyaml/NXsample_component.yaml index 750e5c3b6a..7eb58b30a2 100644 --- a/base_classes/nyaml/NXsample_component.yaml +++ b/base_classes/nyaml/NXsample_component.yaml @@ -111,11 +111,11 @@ NXsample_component(NXobject): doc: | Set of sub-components and their configuration. There can only be one NXsample_component_set in one component. - exists: [min, 1, max, 1] + # exists: [max, 1] (NXsubstance): doc: | If the component is made from a pure substance and cannot be further divided using NXsample_component. - exists: [min, 1, max, 1] + # exists: [max, 1] (NXfabrication): doc: | Details about the sample component vendor (company or research group) From 8cb3479a14771e2de6b1680d08fecf5b1b809a00 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 30 Aug 2023 14:08:35 +0200 Subject: [PATCH 0225/1012] Add a line break between the first and all following lines --- base_classes/nyaml/NXsample_component.yaml | 4 +++- contributed_definitions/nyaml/NXsingle_crystal.yaml | 1 + contributed_definitions/nyaml/NXunit_cell.yaml | 3 +-- 3 files changed, 5 insertions(+), 3 deletions(-) diff --git a/base_classes/nyaml/NXsample_component.yaml b/base_classes/nyaml/NXsample_component.yaml index da3c23dcbd..30e5c38979 100644 --- a/base_classes/nyaml/NXsample_component.yaml +++ b/base_classes/nyaml/NXsample_component.yaml @@ -1,6 +1,8 @@ category: base doc: | - One group like this per component can be recorded For a sample consisting of multiple components. + One group like this per component can be recorded. + + For a sample consisting of multiple components. symbols: doc: | symbolic array lengths to be coordinated between various fields diff --git a/contributed_definitions/nyaml/NXsingle_crystal.yaml b/contributed_definitions/nyaml/NXsingle_crystal.yaml index befb1db5ab..b83bbc43b0 100644 --- a/contributed_definitions/nyaml/NXsingle_crystal.yaml +++ b/contributed_definitions/nyaml/NXsingle_crystal.yaml @@ -1,6 +1,7 @@ category: base doc: | Description of a single crystal material or a single crystalline phase in a material. + There is the option of using Busing-Levy convention (as orginally designed in NXsample) or using a more detailed description with NXrotation_set. type: group diff --git a/contributed_definitions/nyaml/NXunit_cell.yaml b/contributed_definitions/nyaml/NXunit_cell.yaml index 30060c017c..4674ac6f53 100644 --- a/contributed_definitions/nyaml/NXunit_cell.yaml +++ b/contributed_definitions/nyaml/NXunit_cell.yaml @@ -1,7 +1,6 @@ category: base doc: | - Description of a unit cell, i.e., the crystal structure of a single - thermodynamic phase. + Description of a unit cell, i.e., the crystal structure of a single thermodynamic phase. symbols: n_pos: | Number of atom positions. From e8ed764fb7f9a84cf1f903dd2149c264a3109382 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 30 Aug 2023 14:20:06 +0200 Subject: [PATCH 0226/1012] Allow for shorthand, numpy-like dim notation --- .../nyaml2nxdl/nyaml2nxdl_forward_tools.py | 30 +++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py b/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py index 664f687484..03ff1c6b51 100644 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py +++ b/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py @@ -208,6 +208,7 @@ def check_for_skiped_attributes(component, value, allowed_attr=None, verbose=Fal and "\\@" not in attr and attr not in allowed_attr and "NX" not in attr + and attr != "dim" and val ): raise ValueError( @@ -467,6 +468,33 @@ def xml_handle_dimensions(dct, obj, keyword, value: dict): if isinstance(value, dict) and value != {}: recursive_build(dims, value, verbose=None) +def xml_handle_dim(dct, obj, keyword, value): + """ + This function creates a 'dimensions' element instance, and appends it to an existing element. + + Allows for handling numpy tensor notation of dimensions. That is, + dimensions: + rank: 1 + dim: (1, 3) + can be replaced by + dim: (3,) + + """ + if isinstance(value, str) is True: + if value[0] == "(" and value[-1] == ")": + valid_dims = [] + for entry in value[1:-1].replace(" ", "").split(","): + if len(entry) > 0: # ignore trailing comma and empty mnemonics + valid_dims.append(entry) + if len(valid_dims) > 0: + dims = ET.SubElement(obj, "dimensions") + dims.set("rank", str(len(valid_dims))) + dim_idx = 1 + for dim_name in valid_dims: + dim = ET.SubElement(dims, "dim") + dim.set("index", str(dim_idx)) + dim.set("value", str(dim_name)) + dim_idx += 1 # pylint: disable=too-many-locals, too-many-arguments def xml_handle_dim_from_dimension_dict( @@ -1046,6 +1074,8 @@ def recursive_build(obj, dct, verbose): elif keyword == "dimensions": xml_handle_dimensions(dct, obj, keyword, value) + elif keyword == "dim": + xml_handle_dim(dct, obj, keyword, value) elif keyword == "exists": xml_handle_exists(dct, obj, keyword, value) From 3a9f1a504d2c3913bfff80ab0d597f1f1f7343ef Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 30 Aug 2023 14:21:33 +0200 Subject: [PATCH 0227/1012] Docstring fix in NXunit_cell --- contributed_definitions/NXunit_cell.nxdl.xml | 225 ++++++++++++++++++ .../nyaml/NXunit_cell.yaml | 9 +- 2 files changed, 231 insertions(+), 3 deletions(-) create mode 100644 contributed_definitions/NXunit_cell.nxdl.xml diff --git a/contributed_definitions/NXunit_cell.nxdl.xml b/contributed_definitions/NXunit_cell.nxdl.xml new file mode 100644 index 0000000000..7222cfc620 --- /dev/null +++ b/contributed_definitions/NXunit_cell.nxdl.xml @@ -0,0 +1,225 @@ + + + + + + + + Number of atom positions. + + + + + Description of a unit cell, i.e., the crystal structure of a single + thermodynamic phase. + + + + Identifier of an entry resolvable via crystallographic_database + which was used for creating this structure model. + + + + + Name of the crystallographic database to resolve + crystallographic_database_identifier e.g. COD, ICSD, or others. + + + + + A lattice system is a group of lattices with the same set of lattice point groups. + For further information, see https://en.wikipedia.org/wiki/Crystal_system. + + + + + + + + + + + + + + Crystallographic space group. + A space group is the symmetry group of a repeating pattern in space. + For further information, see International Table for Crystallography (https://it.iucr.org/). + + + + + Crystallographic point group. + A crystallographic point group is a set of symmetry operations, corresponding to one of the point groups in three dimensions, + such that each operation (perhaps followed by a translation) would leave the structure of a crystal unchanged. + This field should use Schoenflies notation (see Schoenflies, A., Krystallsysteme und Krystallstructur, 1891). + For further information, see https://dictionary.iucr.org/Point_group. + + + + + Laue group (also called Laue class). + The Laue classes are eleven geometric crystal classes containing centrosymmetric crystallographic types of point groups and their subgroups. + When absorption is negligible and Friedel's law applies, it is impossible to distinguish by diffraction between a centrosymmetric point group + and one of its non-centrosymmetric subgroups; only point groups belonging to different Laue classes can then be distinguished. + For further information, see https://dictionary.iucr.org/Laue_class. + + + + + + Crystallography unit cell parameters a, b, and c + + + + + + + + Crystallography unit cell vector a + + + + + + + For definining which coordinate system the unit cell vector a is defined in. + + + + + + Crystallography unit cell vector b + + + + + + + For definining which coordinate system the unit cell vector b is defined in. + + + + + + Crystallography unit cell vector c + + + + + + + For definining which coordinate system the unit cell vector c is defined in. + + + + + + Crystallography unit cell angles alpha, beta, and gamma + + + + + + + + Volume of the unit cell + + + + + + True if space group is considered a centrosymmetric one. + False if space group is considered a non-centrosymmetric one. + Centrosymmetric has all types and combinations of symmetry elements + (translation, rotational axis, mirror planes, center of inversion) + Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). + Chiral compared to non-centrosymmetric is constrained (no mirror planes). + + + + + True if space group is considered a chiral one. + False if space group is consider a non-chiral one. + + + + + Identifier for the phase. + The value 0 is reserved for the unknown phase which represents the null-model + that no phase model was sufficiently significantly confirmed. + + + + + Trivial name of the phase/alias. + + + + + Labels for each atom position + + + + + + + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + Atom positions x, y, z. + + + + + + + + Reference to an instance of NXcoordinate_system whereby the positions can be + resolved. + + + + + + Relative occupancy of the atom position. + + + + + + + + For definining which coordinate system the unit cell parameters are defined in. + + + diff --git a/contributed_definitions/nyaml/NXunit_cell.yaml b/contributed_definitions/nyaml/NXunit_cell.yaml index 4674ac6f53..aa372af96f 100644 --- a/contributed_definitions/nyaml/NXunit_cell.yaml +++ b/contributed_definitions/nyaml/NXunit_cell.yaml @@ -50,21 +50,24 @@ NXunit_cell(NXobject): unit: NX_LENGTH dim: (3,) \@depends_on: - For definining which coordinate system the unit cell vector a is defined in. + doc: | + For definining which coordinate system the unit cell vector a is defined in. base_vector_b(NX_FLOAT): doc: | Crystallography unit cell vector b unit: NX_LENGTH dim: (3,) \@depends_on: - For definining which coordinate system the unit cell vector b is defined in. + doc: | + For definining which coordinate system the unit cell vector b is defined in. base_vector_c(NX_FLOAT): doc: | Crystallography unit cell vector c unit: NX_LENGTH dim: (3,) \@depends_on: - For definining which coordinate system the unit cell vector c is defined in. + doc: | + For definining which coordinate system the unit cell vector c is defined in. alpha_beta_gamma(NX_FLOAT): unit: NX_ANGLE doc: | From 8e3c466027c648c8a36abb81d52dcbef230bbf6f Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 30 Aug 2023 14:35:18 +0200 Subject: [PATCH 0228/1012] Make NXDLs --- base_classes/NXsample.nxdl.xml | 7 +- base_classes/NXsample_component.nxdl.xml | 6 + .../NXrotation_set.nxdl.xml | 250 ++++++++++++++++++ .../NXsingle_crystal.nxdl.xml | 74 ++++++ 4 files changed, 336 insertions(+), 1 deletion(-) create mode 100644 contributed_definitions/NXrotation_set.nxdl.xml create mode 100644 contributed_definitions/NXsingle_crystal.nxdl.xml diff --git a/base_classes/NXsample.nxdl.xml b/base_classes/NXsample.nxdl.xml index 43bb316334..1f81d94b27 100755 --- a/base_classes/NXsample.nxdl.xml +++ b/base_classes/NXsample.nxdl.xml @@ -378,6 +378,12 @@ Note, it is recommended to use NXtransformations instead. + + + If the sample is a single crystal, add description of single crystal and unit + cell. + + Any positioner (motor, PZT, ...) used to locate the sample @@ -418,4 +424,3 @@ - diff --git a/base_classes/NXsample_component.nxdl.xml b/base_classes/NXsample_component.nxdl.xml index 624c09557d..d0d4e6c3a6 100644 --- a/base_classes/NXsample_component.nxdl.xml +++ b/base_classes/NXsample_component.nxdl.xml @@ -139,6 +139,12 @@ As a function of Wavelength + + + If the component is a single crystal, add description of single crystal and unit + cell. + + .. index:: plotting diff --git a/contributed_definitions/NXrotation_set.nxdl.xml b/contributed_definitions/NXrotation_set.nxdl.xml new file mode 100644 index 0000000000..4956c257b0 --- /dev/null +++ b/contributed_definitions/NXrotation_set.nxdl.xml @@ -0,0 +1,250 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of value tuples. + + + + + Base class to detail a set of rotations, orientations, and disorientations. + + For getting a more detailed insight into the discussion of the + parameterized description of orientations in materials science see: + + * `H.-J. Bunge <https://doi.org/10.1016/C2013-0-11769-2>`_ + * `T. B. Britton et al. <https://doi.org/10.1016/j.matchar.2016.04.008>`_ + * `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_ + * `A. Morawiec <https://doi.org/10.1007/978-3-662-09156-2>`_ + + Once orientations are defined one can continue to characterize the + misorientation and specifically the disorientation which describes the + rotation that is required to register the lattices of two oriented objects + (like crystal lattice) into a crystallographic equivalent orientation: + + * `R. Bonnet <https://doi.org/10.1107/S0567739480000186>`_ + + Based on the idea of this NXorientation_set one could equally formulate + an NXdisorientation_set. + + + + Reference to an instance of NXem_conventions which contextualizes + how the here reported parameterized quantities can be interpreted. + + + + + + Point group which defines the symmetry of the crystal. + This has to be at least a single string. + In the case that misorientation or disorientation fields are used + and the two crystal sets resolve for phases with a different + crystal symmetry, this field has to encode two string. + In this case the first string is for phase A the second one for phase B. + An example of this most complex case is the description of the + disorientation between crystals adjoining a hetero-phase boundary. + + + + + + Point group which defines an assumed symmetry imprinted upon processing + the material/sample which could give rise to or may justify to use a + simplified description of rotations, orientations, misorientations, + and disorientations via numerical procedures known as symmetrization. + + The traditionally used symmetrization operations within the texture + community in Materials Science, though, are thanks to methodology and + software improvements no longer strictly needed. Therefore, users are + encouraged to set the sample_symmetry to 1 (triclinic) and thus assume + there is no implied additional processing symmetry imprinted. + + In practice one often faces situations where indeed these assumed + symmetries are anyway not fully observed and thus an accepting of + eventual inaccuracies just for the sake of reporting a simplified + symmetrized description can be avoided. + + + + + The set of rotations expressed in quaternion representation. The assumed + crystal and sample symmetry point group is 1, triclinic. Rotations which + should be interpreted as antipodal are not marked as such. + + + + + + + + + The set of rotations expressed in Euler angle representation following + the same applied symmetries as explained for rotation_quaternion. + To interpret Euler angles correctly it is necessary to inspect the + conventions behind depends_on to resolve which of the many Euler-angle + conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. + + + + + + + + + + + True for all those values which are considered antipodal, + false for those which are not considered antipodal. + + + + + + + + The set of orientations expressed in quaternion representation and + obeying symmetry for equivalent cases as detailed in crystal_symmetry + and sample_symmetry. The supplementary field is_antipodal can be used + to mark orientations which are antipodal. + + + + + + + + + The set of orientations expressed in Euler angle representation following + the same assumptions like for orientation_quaternion. + To interpret Euler angles correctly it is necessary to inspect the + conventions behind depends_on to resolve which of the many Euler-angle + conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. + + + + + + + + + This will follow the Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + + + + + UB matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is + the multiplication of the orientation_matrix, given above, + with the :math:`B` matrix which + can be derived from the lattice constants. + + + + + + + + + + + + The set of misorientations expressed in quaternion representation and + obeying symmetry operations for equivalent misorientations + as defined by crystal_symmetry and sample_symmetry. + + + + + + + + + Misorientation angular argument (eventually signed) following the same + symmetry assumptions as expressed for the field misorientation_quaternion. + + + + + + + + Misorientation axis (normalized) and signed following the same + symmetry assumptions as expressed for the field misorientation_angle. + + + + + + + + + + The set of disorientation expressed in quaternion representation and + obeying symmetry operations for equivalent misorientations + as defined by crystal_symmetry and sample_symmetry. + + + + + Disorientation angular argument (should not be signed, see + `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_) + following the same symmetry assumptions as expressed for the field + disorientation_quaternion. + + + + + + + + Disorientation axis (normalized) following the same symmetry assumptions + as expressed for the field disorientation_quaternion. + + + + + + + + + diff --git a/contributed_definitions/NXsingle_crystal.nxdl.xml b/contributed_definitions/NXsingle_crystal.nxdl.xml new file mode 100644 index 0000000000..3a0f0d89b9 --- /dev/null +++ b/contributed_definitions/NXsingle_crystal.nxdl.xml @@ -0,0 +1,74 @@ + + + + + + Description of a single crystal material or a single crystalline phase in a material. + + There is the option of using Busing-Levy convention (as orginally designed in NXsample) + or using a more detailed description with NXrotation_set. + + + + This will follow the Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + + + + + + + + Orientation matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + + + + + + + + + + UB matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is + the multiplication of the orientation_matrix, given above, + with the :math:`B` matrix which can be derived from the lattice constants. + + + + + + + + + + Detailed description of single crystal orientation and misorientation. + + + + + Unit cell of the single crystal. + + + From f1cf4ffa86a5280a1825e53cee092da5e595b00e Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 30 Aug 2023 14:50:57 +0200 Subject: [PATCH 0229/1012] Change dimension of matrices --- contributed_definitions/NXrotation_set.nxdl.xml | 9 ++++++--- contributed_definitions/NXsingle_crystal.nxdl.xml | 6 ++---- contributed_definitions/nyaml/NXrotation_set.yaml | 7 +++---- .../nyaml/NXsingle_crystal.yaml | 14 ++++---------- 4 files changed, 15 insertions(+), 21 deletions(-) diff --git a/contributed_definitions/NXrotation_set.nxdl.xml b/contributed_definitions/NXrotation_set.nxdl.xml index 4956c257b0..24e51daff1 100644 --- a/contributed_definitions/NXrotation_set.nxdl.xml +++ b/contributed_definitions/NXrotation_set.nxdl.xml @@ -163,8 +163,12 @@ rotation_axis_angle(NX_FLOAT):--> This will follow the Busing-Levy convention: W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + + + + - + UB matrix of single crystal sample using Busing-Levy convention: W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is @@ -172,10 +176,9 @@ rotation_axis_angle(NX_FLOAT):--> with the :math:`B` matrix which can be derived from the lattice constants. - + - - - - - symbolic array lengths to be coordinated between various fields - number of compositions - number of temperatures - number of values in applied electric field - number of values in applied magnetic field - number of values in applied pressure field - number of values in applied stress field - - - - 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. - - - Descriptive name of sample - - - - 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. - - - - Sample temperature. This could be a scanned variable - - - - - - Applied electric field - - - + + + + symbolic array lengths to be coordinated between various fields + + + + number of compositions + + + + + number of temperatures + + + + + number of values in applied electric field + + + + + number of values in applied magnetic field + + + + + number of values in applied pressure field + + + + + number of values in applied stress field + + + + + 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. + + + + Descriptive name of sample + + + + + 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. + + + + + Sample temperature. This could be a scanned variable + + + + + + + + + Applied electric field + + + + + - - - - - + + + + + - - - Applied magnetic field - - - + + + + Applied magnetic field + + + + + - - - - - + + + + + - - - Applied external stress field - - - + + + + Applied external stress field + + + + + - - - - - + + + + + - - - Applied pressure - - - - - - Sample changer position - - - Crystallography unit cell parameters a, b, and c - - - - - - Crystallography unit cell parameters alpha, beta, and gamma - - - - - - Unit cell parameters (lengths and angles) - - - - - - - Volume of the unit cell - - - - - - - This will follow the Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - - - - - - - - Orientation matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - - - - - - - - - - UB matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is - the multiplication of the orientation_matrix, given above, - with the :math:`B` matrix which - can be derived from the lattice constants. - - - - - - - - - Mass of sample - - - - - - Density of sample - - - - - - Relative Molecular Mass of sample - - - - - - - - - - - - - - - - - - - - - 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. - - - - - - - - - - - - - - Description of the sample - - - - Date of preparation of the sample - - - The position and orientation of the center of mass of the sample - - - Details of beam incident on sample - used to calculate sample/beam interaction point - - - - One group per sample component - This is the perferred way of recording per component information over the n_comp arrays - - - - Details of the component of the sample and/or can - - - - - - Type of component - - - - - - - - - - - - Concentration of each component - - - - - - Volume fraction of each component - - - - - - Scattering length density of each component - - - - - - - In case it is all we know and we want to record/document it - - - - - - - - - - - - - Crystallographic space group - - - - - - Crystallographic point group, deprecated if space_group present - - + + + + Applied pressure + + + + + + + + + Sample changer position + + + + + Crystallography unit cell parameters a, b, and c + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma + + + + + + + + Unit cell parameters (lengths and angles) + + + + + + + + + Volume of the unit cell + + + + + + + + This will follow the Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + + + + + + + + Orientation matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + + + + + + + + + + UB matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is + the multiplication of the orientation_matrix, given above, + with the :math:`B` matrix which + can be derived from the lattice constants. + + + + + + + + + + Mass of sample + + + + + + + + Density of sample + + + + + + + + Relative Molecular Mass of sample + + + + + + + + + + + + + + + + + + + + + + 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. + + + + + + + + + + + + + + Description of the sample + + + + + Date of preparation of the sample + + + + + The position and orientation of the center of mass of the sample + + + + + Details of beam incident on sample - used to calculate sample/beam interaction + point + + + + + One group per sample component + This is the perferred way of recording per component information over the n_comp arrays + + + + + Details of the component of the sample and/or can + + + + + + + + Type of component + + + + + + + + + + + + + + Concentration of each component + + + + + + + + Volume fraction of each component + + + + + + + + Scattering length density of each component + + + + + + + + In case it is all we know and we want to record/document it + + + + + + + + + + + + + + Crystallographic space group + + + - - - - Path length through sample/can for simple case when - it does not vary with scattering direction - - - - - Thickness of a beam entry/exit window on the can (mm) - - assumed same for entry and exit - - - - sample thickness - - - As a function of Wavelength - - - temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value - - - Additional sample temperature environment information - - - magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value - - - magnetic_field_log.value is a link to e.g. magnetic_field_env.sensor1.value_log.value - - - Additional sample magnetic environment information - - - value sent to user's sample setup - - - logged value (or logic state) read from user's setup - - - 20 character fixed length sample description for legends - - - - - Optional rotation angle for the case when the powder diagram has - been obtained through an omega-2theta scan like from a traditional - single detector powder diffractometer. - Note, it is recommended to use NXtransformations instead. - - - - - Translation of the sample along the X-direction of the laboratory coordinate system - Note, it is recommended to use NXtransformations instead. - - - - - Translation of the sample along the Z-direction of the laboratory coordinate system. - Note, it is recommended to use NXtransformations instead. - - - - - If the sample is a single crystal, add description of single crystal and unit - cell. - + + + + Crystallographic point group, deprecated if space_group present + + + + + + + + Path length through sample/can for simple case when + it does not vary with scattering direction + + + + + Thickness of a beam entry/exit window on the can (mm) + - assumed same for entry and exit + + + + + sample thickness + + + + + As a function of Wavelength + + + + + Description of crystal structure of the sample. + + + + + temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value + + + + + Additional sample temperature environment information + + + + + magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value + + + + + magnetic_field_log.value is a link to e.g. + magnetic_field_env.sensor1.value_log.value + + + + + Additional sample magnetic environment information + + + + + value sent to user's sample setup + + + + + logged value (or logic state) read from user's setup + + + + + 20 character fixed length sample description for legends + + + + + + Optional rotation angle for the case when the powder diagram has + been obtained through an omega-2theta scan like from a traditional + single detector powder diffractometer. + Note, it is recommended to use NXtransformations instead. + + + + + Translation of the sample along the X-direction of the laboratory coordinate system + Note, it is recommended to use NXtransformations instead. + + + + + Translation of the sample along the Z-direction of the laboratory coordinate system. + Note, it is recommended to use NXtransformations instead. + + + + + Any positioner (motor, PZT, ...) used to locate the sample + + + + + This group describes the shape of the sample + + + + + If the sample is a single crystal, add description of single crystal and unit + cell. + - - Any positioner (motor, PZT, ...) used to locate the sample - - - - This group describes the shape of the sample - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. + 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. - 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. diff --git a/base_classes/NXsample_component.nxdl.xml b/base_classes/NXsample_component.nxdl.xml index d0d4e6c3a6..fda56c8659 100644 --- a/base_classes/NXsample_component.nxdl.xml +++ b/base_classes/NXsample_component.nxdl.xml @@ -1,9 +1,9 @@ - + - - - - symbolic array lengths to be coordinated between various fields - number of temperatures - number of values in applied electric field - number of values in applied magnetic field - number of values in applied pressure field - number of values in applied stress field - - - - One group like this per component can be recorded For a sample consisting of multiple components. - - - Descriptive name of sample component - - - - 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. - - - - Crystallography unit cell parameters a, b, and c - - - - - - Crystallography unit cell parameters alpha, beta, and gamma - - - - - - Volume of the unit cell - - - This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) - - - - - - - Orientation matrix of single crystal sample component. - This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) - - - - - - - - Mass of sample component - - - Density of sample component - - - Relative Molecular Mass of sample component - - - - Description of the sample component - - - - Volume fraction of component - - - Scattering length density of component - - - - In case it is all we know and we want to record/document it - - - - - - - - - - - - - Crystallographic space group - - - Crystallographic point group, deprecated if space_group present - - - As a function of Wavelength - - - - If the component is a single crystal, add description of single crystal and unit - cell. - + + + + symbolic array lengths to be coordinated between various fields + + + + number of temperatures + + + + + number of values in applied electric field + + + + + number of values in applied magnetic field + + + + + number of values in applied pressure field + + + + + number of values in applied stress field + + + + + One group like this per component can be recorded. + + For a sample consisting of multiple components. + + + + Descriptive name of sample component + + + + + 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. + + + + + Crystallography unit cell parameters a, b, and c + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma + + + + + + + + Volume of the unit cell + + + + + This will follow the Busing and Levy convention from Acta.Crysta v22, p457 + (1967) + + + + + + + + Orientation matrix of single crystal sample component. + This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) + + + + + + + + + Mass of sample component + + + + + Density of sample component + + + + + Relative Molecular Mass of sample component + + + + + Description of the sample component + + + + + Volume fraction of component + + + + + Scattering length density of component + + + + + In case it is all we know and we want to record/document it + + + + + + + + + + + + + + Crystallographic space group + + + + + Crystallographic point group, deprecated if space_group present + + + + + As a function of Wavelength + + + + + If the component is a single crystal, add description of single crystal and unit + cell. + - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. From c30ea9cf789acd1bf5805563f11a9b6face3e547 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 30 Aug 2023 15:17:54 +0200 Subject: [PATCH 0233/1012] Remove unused NXcrystal_structure from NXsample --- base_classes/NXsample.nxdl.xml | 5 ----- 1 file changed, 5 deletions(-) diff --git a/base_classes/NXsample.nxdl.xml b/base_classes/NXsample.nxdl.xml index 661b37e913..a48f602e98 100755 --- a/base_classes/NXsample.nxdl.xml +++ b/base_classes/NXsample.nxdl.xml @@ -408,11 +408,6 @@ As a function of Wavelength - - - Description of crystal structure of the sample. - - temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value From c83104e1880f68e98b3f6797f0de890a8c8476bc Mon Sep 17 00:00:00 2001 From: Rubel Date: Thu, 24 Aug 2023 15:02:08 +0200 Subject: [PATCH 0234/1012] Regeneration of the nexus file for fixing the changes coming from old version of yaml. Removing unintensional comments --- base_classes/NXaperture.nxdl.xml | 2 +- base_classes/NXbeam.nxdl.xml | 427 +++---- base_classes/NXdetector.nxdl.xml | 6 +- base_classes/NXentry.nxdl.xml | 528 ++++---- base_classes/NXinstrument.nxdl.xml | 166 +-- base_classes/NXprocess.nxdl.xml | 91 +- base_classes/NXsample.nxdl.xml | 1071 +++++++++-------- base_classes/NXsource.nxdl.xml | 496 ++++---- .../NXcollectioncolumn.nxdl.xml | 8 +- contributed_definitions/NXmpes.nxdl.xml | 12 +- 10 files changed, 1512 insertions(+), 1295 deletions(-) diff --git a/base_classes/NXaperture.nxdl.xml b/base_classes/NXaperture.nxdl.xml index 7e64513caf..23c325e191 100644 --- a/base_classes/NXaperture.nxdl.xml +++ b/base_classes/NXaperture.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/base_classes/NXbeam.nxdl.xml b/base_classes/NXbeam.nxdl.xml index bde48d654b..9bf36c06be 100644 --- a/base_classes/NXbeam.nxdl.xml +++ b/base_classes/NXbeam.nxdl.xml @@ -1,9 +1,9 @@ - + - + - These symbols coordinate datasets with the same shape. + These symbols coordinate datasets with the same shape. - Number of scan points. + + Number of scan points. + - Number of channels in the incident beam spectrum, if known + + Number of channels in the incident beam spectrum, if known + - Number of moments representing beam divergence (x, y, xy, etc.) + + Number of moments representing beam divergence (x, y, xy, etc.) + - 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. - + 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. + - Distance from sample. Note, it is recommended to use NXtransformations instead. + + Distance from sample. Note, it is recommended to use NXtransformations instead. + - Energy carried by each particle of the beam on entering the beamline component. - - In the case of a monochromatic beam this is the scalar energy. - Several other use cases are permitted, depending on the - presence of other incident_energy_X fields. - - * In the case of a polychromatic beam this is an array of length m of energies, with the relative weights in incident_energy_weights. - * In the case of a monochromatic beam that varies shot-to-shot, this is an array of energies, one for each recorded shot. - Here, incident_energy_weights and incident_energy_spread are not set. - * In the case of a polychromatic beam that varies shot-to-shot, - this is an array of length m with the relative weights in incident_energy_weights as a 2D array. - * In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, - this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_energy_weights as a 2D array. - - Note, variants are a good way to represent several of these use cases in a single dataset, - e.g. if a calibrated, single-value energy value is available along with the original spectrum from which it was calibrated. + Energy carried by each particle of the beam on entering the beamline component. + + 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. @@ -85,90 +89,94 @@ - 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. + The energy spread FWHM for the corresponding energy(ies) in incident_energy. In the case of shot-to-shot variation in + the energy spread, this is a 2D array of dimension nP by m + (slow to fast) of the spreads of the corresponding + wavelength in incident_wavelength. - In the case of a polychromatic beam this is an array of length m of the relative - weights of the corresponding energies in incident_energy. In the case of a - polychromatic beam that varies shot-to-shot, this is a 2D array of dimensions np - by m (slow to fast) of the relative weights of the corresponding energies in - incident_energy. + In the case of a polychromatic beam this is an array of length m of the relative + weights of the corresponding energies in incident_energy. In the case of a + polychromatic beam that varies shot-to-shot, this is a 2D array of dimensions np + by m (slow to fast) of the relative weights of the corresponding energies in + incident_energy. - Energy carried by each particle of the beam on leaving the beamline component + + Energy carried by each particle of the beam on leaving the beamline component + - Change in particle energy caused by the beamline component + + Change in particle energy caused by the 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 <Design-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 <Design-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 polychromatic beam this is an array of - length **m** of the relative weights of the corresponding - wavelengths in ``incident_wavelength``. - - In the case of a polychromatic beam that varies shot-to- - shot, this is a 2D array of dimensions **nP** by **m** - (slow to fast) of the relative weights of the - corresponding wavelengths in ``incident_wavelength``. + In the case of a polychromatic beam this is an array of + length **m** of the relative weights of the corresponding + wavelengths in ``incident_wavelength``. + + In the case of a polychromatic beam that varies shot-to- + shot, this is a 2D array of dimensions **nP** by **m** + (slow to fast) of the relative weights of the + corresponding wavelengths in ``incident_wavelength``. - The wavelength spread FWHM for the corresponding - wavelength(s) in incident_wavelength. - - In the case of shot-to-shot variation in the wavelength - spread, this is a 2D array of dimension **nP** by - **m** (slow to fast) of the spreads of the - corresponding wavelengths in incident_wavelength. + The wavelength spread FWHM for the corresponding + wavelength(s) in incident_wavelength. + + In the case of shot-to-shot variation in the wavelength + spread, this is a 2D array of dimension **nP** by + **m** (slow to fast) of the spreads of the + corresponding wavelengths in incident_wavelength. @@ -176,15 +184,15 @@ - Beam crossfire in degrees parallel to the laboratory X axis - - The dimension **c** is a series of moments of that represent - the standard uncertainty (e.s.d.) of the directions of - of the beam. The first and second moments are in the XZ and YZ - planes around the mean source beam direction, respectively. - - Further moments in **c** characterize co-variance terms, so - the next moment is the product of the first two, and so on. + Beam crossfire in degrees parallel to the laboratory X axis + + The dimension **c** is a series of moments of that represent + the standard uncertainty (e.s.d.) of the directions of + of the beam. The first and second moments are in the XZ and YZ + planes around the mean source beam direction, respectively. + + Further moments in **c** characterize co-variance terms, so + the next moment is the product of the first two, and so on. @@ -193,8 +201,8 @@ - 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 @@ -202,15 +210,17 @@ - Wavelength on leaving beamline component + + Wavelength on leaving beamline component + - Incident polarization as a Stokes vector - on entering beamline component + Incident polarization as a Stokes vector + on entering beamline component @@ -218,26 +228,26 @@ - The units for this observable are not included in the NIAC list. - Responsibility on correct formatting and parsing is handed to the user - by using `NX_ANY`. Correct parsing can still be implemented by using - this attribute. - - | Fill with: - - * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). - * The unit unidata name if the unit has a name (Example: farad for capacitance). - * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and - does not have a name. - - Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). - Here: SI units are V2/m2. + The units for this observable are not included in the NIAC list. + Responsibility on correct formatting and parsing is handed to the user + by using `NX_ANY`. Correct parsing can still be implemented by using + this attribute. + + | Fill with: + + * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). + * The unit unidata name if the unit has a name (Example: farad for capacitance). + * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and + does not have a name. + + Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). + Here: SI units are V2/m2. - Polarization as Stokes vector on leaving beamline component + Polarization as Stokes vector on leaving beamline component @@ -245,45 +255,45 @@ - The units for this observable are not included in the NIAC list. - Responsibility on correct formatting and parsing is handed to the user - by using `NX_ANY`. Correct parsing can still be implemented by using - this attribute. - - | Fill with: - - * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). - * The unit unidata name if the unit has a name (Example: farad for capacitance). - * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and - does not have a name. - - Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). - Here: SI units are V2/m2. + The units for this observable are not included in the NIAC list. + Responsibility on correct formatting and parsing is handed to the user + by using `NX_ANY`. Correct parsing can still be implemented by using + this attribute. + + | Fill with: + + * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). + * The unit unidata name if the unit has a name (Example: farad for capacitance). + * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and + does not have a name. + + Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). + Here: SI units are V2/m2. Polarization vector on entering beamline component using Stokes notation - + The Stokes parameters are four components labelled I,Q,U,V or S_0,S_1,S_2,S_3. These are defined with the standard Nexus coordinate frame unless it is overridden by an NXtransformations field pointed to by a depends_on attribute. The last component, describing the circular polarization state, is positive for a right-hand circular state - that is the electric field vector rotates clockwise at the sample and over time when observed from the source. - - I (S_0) is the beam intensity (often normalized to 1). Q, U, and V scale + + I (S_0) is the beam intensity (often normalized to 1). Q, U, and V scale linearly with the total degree of polarization, and indicate the relative magnitudes of the pure linear and circular orientation contributions. Q (S_1) is linearly polarized along the x axis (Q > 0) or y axis (Q < 0). U (S_2) is linearly polarized along the x==y axis (U > 0) or the - -x==y axis (U < 0). - + -x==y axis (U < 0). + V (S_3) is circularly polarized. V > 0 when the electric field vector rotates - clockwise at the sample with respect to time when observed from the source; + clockwise at the sample with respect to time when observed from the source; V < 0 indicates the opposite rotation. @@ -302,52 +312,58 @@ - Wavelength spread FWHM of beam leaving this component + + Wavelength spread FWHM of beam leaving this component + - Divergence FWHM of beam leaving this component + + Divergence FWHM of beam leaving this component + - flux incident on beam plane area + + flux incident on beam plane area + - Energy of a single pulse at the diagnostic point + Energy of a single pulse at the diagnostic point - Average power at the diagnostic point + Average power at the diagnostic point - Incident fluence at the diagnostic point + Incident fluence at the diagnostic point - Here: SI units are 'J/m2', customary 'mJ/cm2'. + Here: SI units are 'J/m2', customary 'mJ/cm2'. - FWHM duration of the pulses at the diagnostic point + FWHM duration of the pulses at the diagnostic point - FROG trace of the pulse. + FROG trace of the pulse. @@ -356,7 +372,7 @@ - Horizontal axis of a FROG trace, i.e. delay. + Horizontal axis of a FROG trace, i.e. delay. @@ -364,7 +380,7 @@ - Vertical axis of a FROG trace, i.e. frequency. + Vertical axis of a FROG trace, i.e. frequency. @@ -372,104 +388,101 @@ - The type of chirp implemented + The type of chirp implemented - Group delay dispersion of the pulse for linear chirp + Group delay dispersion of the pulse for linear chirp - Distribution of beam with respect to relevant variable e.g. wavelength. This is mainly - useful for simulations which need to store plottable information at each beamline - component. + Distribution of beam with respect to relevant variable e.g. wavelength. This is mainly + useful for simulations which need to store plottable information at each beamline + component. + - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. - - - - - - The NeXus coordinate system defines the Z axis to be along the nominal beam - direction. This is the same as the McStas coordinate system (see :ref:`Design-CoordinateSystem`). - However, the additional transformations needed to represent an altered beam - direction can be provided using this depends_on field that contains the path - to a NXtransformations group. This could represent redirection of the beam, - or a refined beam direction. + + + The NeXus coordinate system defines the Z axis to be along the nominal beam + direction. This is the same as the McStas coordinate system (see :ref:`Design-CoordinateSystem`). + However, the additional transformations needed to represent an altered beam + direction can be provided using this depends_on field that contains the path + to a NXtransformations group. This could represent redirection of the beam, + or a refined beam direction. - - Direction (and location) for the beam. The location of the beam can be given by - any point which it passes through as its offset attribute. + Direction (and location) for the beam. The location of the beam can be given by + any point which it passes through as its offset attribute. - + - Direction of beam vector, its value is ignored. If missing, then the beam direction is defined as [0,0,1] - and passes through the origin + Direction of beam vector, its value is ignored. If missing, then the beam direction is defined as [0,0,1] + and passes through the origin - + - Three values that define the direction of beam vector + Three values that define the direction of beam vector - Three values that define the location of a point through which the beam passes + Three values that define the location of a point through which the beam passes - Points to the path to a field defining the location on which this - depends or the string "." for origin. + Points to the path to a field defining the location on which this + depends or the string "." for origin. - + - Direction of normal to reference plane used to measure azimuth relative to the beam, its value is ignored. - This also defines the parallel and perpendicular components of the beam's polarization. - If missing, then the reference plane normal is defined as [0,1,0] and passes through the origin + Direction of normal to reference plane used to measure azimuth relative to the beam, its value is ignored. + This also defines the parallel and perpendicular components of the beam's polarization. + If missing, then the reference plane normal is defined as [0,1,0] and passes through the origin - + - Three values that define the direction of reference plane normal + Three values that define the direction of reference plane normal - Not required as beam direction offset locates the plane + Not required as beam direction offset locates the plane - Points to the path to a field defining the location on which this - depends or the string "." for origin. + Points to the path to a field defining the location on which this + depends or the string "." for origin. diff --git a/base_classes/NXdetector.nxdl.xml b/base_classes/NXdetector.nxdl.xml index cb017217b2..523f0916f1 100644 --- a/base_classes/NXdetector.nxdl.xml +++ b/base_classes/NXdetector.nxdl.xml @@ -458,18 +458,16 @@ This field can be two things: - #. For a pixel detector it provides the nominal wavelength + 1. For a pixel detector it provides the nominal wavelength for which the detector has been calibrated. - #. For other detectors this field has to be seen together with + 2. For other detectors this field has to be seen together with the efficiency field above. For some detectors, the efficiency is wavelength dependent. Thus this field provides the wavelength axis for the efficiency field. In this use case, the efficiency and wavelength arrays must have the same dimensionality. - - diff --git a/base_classes/NXentry.nxdl.xml b/base_classes/NXentry.nxdl.xml index 1247e68b76..e5865bd60c 100755 --- a/base_classes/NXentry.nxdl.xml +++ b/base_classes/NXentry.nxdl.xml @@ -1,10 +1,10 @@ - + - - - - - .. 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 <validItemName>` 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 <Find-Plottable-Data-v3>` - section. - - - - - (**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. - - - - 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 - - - - - - - ISIS Muon IDF_Version - - - Extended title for entry - - - - Unique identifier for the experiment, - defined by the facility, - possibly linked to the proposals - - - - Brief summary of the experiment, including key objectives. - - - Description of the full experiment (document in pdf, latex, ...) - - - User or Data Acquisition defined group of NeXus files or NXentry - - - Brief summary of the collection, including grouping criteria. - - - unique identifier for the measurement, defined by the facility. - - - UUID identifier for the measurement. - Version of UUID used - - - - Reserved for future use by NIAC. - - See https://github.com/nexusformat/definitions/issues/382 - - - - - (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. - - NXDL version number - URL of NXDL file - - - - Local NXDL schema extended from the entry - specified in the ``definition`` field. - This contains any locally-defined, - additional fields in the entry. - - NXDL version number - URL of NXDL file - - - Starting time of measurement - - - Ending time of measurement - - - Duration of measurement - - - - Time transpired actually collecting data i.e. taking out time when collection was - suspended due to e.g. temperature out of range - - - - Such as "2007-3". Some user facilities organize their beam time into run cycles. - - - Name of program used to generate this file - Program version number - configuration of the program - - - - Revision id of the file due to re-calibration, reprocessing, new analysis, new - instrument definition format, ... - - - - - - This is the flightpath before the sample position. This can be determined by a chopper, - by the moderator or the source itself. In other words: it the distance to the component - which gives the T0 signal to the detector electronics. If another component in the - NXinstrument hierarchy provides this information, this should be a link. - - - - Notes describing entry - - - - A small image that is representative of the entry. An example of this is a 640x480 - jpeg image automatically produced by a low resolution plot of the NXdata. - - - The mime type should be an ``image/*`` - - - - - - - - - City and country where the experiment took place - - - - - Start time of experimental run that includes the current - measurement, for example a beam time. - - - - - End time of experimental run that includes the current - measurement, for example a beam time. - - - - - Name of the institution hosting the facility - - - - - Name of the experimental facility - - - - - Name of the laboratory or beamline - - - - - - - - - - + + + (**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. + + + + .. 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 <validItemName>` 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 <Find-Plottable-Data-v3>` + section. + + + + + 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 + + + + + + ISIS Muon IDF_Version + + + + + Extended title for entry + + + + + Unique identifier for the experiment, + defined by the facility, + possibly linked to the proposals + + + + + Brief summary of the experiment, including key objectives. + + + + + Description of the full experiment (document in pdf, latex, ...) + + + + + User or Data Acquisition defined group of NeXus files or NXentry + + + + + Brief summary of the collection, including grouping criteria. + + + + + unique identifier for the measurement, defined by the facility. + + + + + UUID identifier for the measurement. + + + + Version of UUID used + + + + + + Reserved for future use by NIAC. + + See https://github.com/nexusformat/definitions/issues/382 + + + + + (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. + + + + NXDL version number + + + + + URL of NXDL file + + + + + + Local NXDL schema extended from the entry + specified in the ``definition`` field. + This contains any locally-defined, + additional fields in the entry. + + + + NXDL version number + + + + + URL of NXDL file + + + + + + Starting time of measurement + + + + + Ending time of measurement + + + + + Duration of measurement + + + + + Time transpired actually collecting data i.e. taking out time when collection was + suspended due to e.g. temperature out of range + + + + + Such as "2007-3". Some user facilities organize their beam time into run cycles. + + + + + Name of program used to generate this file + + + + Program version number + + + + + configuration of the program + + + + + + Revision id of the file due to re-calibration, reprocessing, new analysis, new + instrument definition format, ... + + + + + + This is the flightpath before the sample position. This can be determined by a chopper, + by the moderator or the source itself. In other words: it the distance to the component + which gives the T0 signal to the detector electronics. If another component in the + NXinstrument hierarchy provides this information, this should be a link. + + + + + Notes describing entry + + + + + A small image that is representative of the entry. An example of this is a 640x480 + jpeg image automatically produced by a low resolution plot of the NXdata. + + + + The mime type should be an ``image/*`` + + + + + + + + + + City and country where the experiment took place + + + + + Start time of experimental run that includes the current + measurement, for example a beam time. + + + + + End time of experimental run that includes the current + measurement, for example a beam time. + + + + + Name of the institution hosting the facility + + + + + Name of the experimental facility + + + + + Name of the laboratory or beamline + + + + + + + + + + diff --git a/base_classes/NXinstrument.nxdl.xml b/base_classes/NXinstrument.nxdl.xml index 75b73d78f7..7fb369f97d 100644 --- a/base_classes/NXinstrument.nxdl.xml +++ b/base_classes/NXinstrument.nxdl.xml @@ -1,9 +1,9 @@ - + - - - 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. - - - Name of instrument - - short name for instrument, perhaps the acronym - - + + + 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. + + + + Name of instrument + + + + short name for instrument, perhaps the acronym + + + - - Energy resolution of the experiment (FWHM or gaussian broadening) - - - - - Momentum resolution of the experiment (FWHM) - - - - - Angular resolution of the experiment (FWHM) - - - - - Spatial resolution of the experiment (Airy disk radius) - - - - - Temporal resolution of the experiment (FWHM) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + Energy resolution of the experiment (FWHM or gaussian broadening) + + + + + Momentum resolution of the experiment (FWHM) + + + + + Angular resolution of the experiment (FWHM) + + + + + Spatial resolution of the experiment (Airy disk radius) + + + + + Temporal resolution of the experiment (FWHM) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. diff --git a/base_classes/NXprocess.nxdl.xml b/base_classes/NXprocess.nxdl.xml index e76ba6b903..ac5a8b81de 100644 --- a/base_classes/NXprocess.nxdl.xml +++ b/base_classes/NXprocess.nxdl.xml @@ -1,9 +1,9 @@ - + - - Document an event of data processing, reconstruction, or analysis for this data. + + + Document an event of data processing, reconstruction, or analysis for this data. + - Name of the program used + + Name of the program used + - Sequence index of processing, - for determining the order of multiple **NXprocess** steps. - Starts with 1. + Sequence index of processing, + for determining the order of multiple **NXprocess** steps. + Starts with 1. - Version of the program used + + Version of the program used + - Date and time of processing. + + Date and time of processing. + - - Describes the operations of image registration - - - - - Describes the operations of image distortion correction - - - - - Describes the operations of calibration procedures, e.g. axis calibrations. - - + + Describes the operations of image registration + + + + + Describes the operations of image distortion correction + + + + + Describes the operations of calibration procedures, e.g. axis calibrations. + + - The note will contain information about how the data was processed - or anything about the data provenance. - The contents of the note can be anything that the processing code - can understand, or simple text. - - The name will be numbered to allow for ordering of steps. + The note will contain information about how the data was processed + or anything about the data provenance. + The contents of the note can be anything that the processing code + can understand, or simple text. + + The name will be numbered to allow for ordering of steps. - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. - diff --git a/base_classes/NXsample.nxdl.xml b/base_classes/NXsample.nxdl.xml index 5eb528cab6..d2afd196c9 100755 --- a/base_classes/NXsample.nxdl.xml +++ b/base_classes/NXsample.nxdl.xml @@ -1,9 +1,9 @@ - + - - - - symbolic array lengths to be coordinated between various fields - number of compositions - number of temperatures - number of values in applied electric field - number of values in applied magnetic field - number of values in applied pressure field - number of values in applied stress field - - - - 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. - - - Descriptive name of sample - - - - 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. - - - - Sample temperature. This could be a scanned variable - - - - - - Applied electric field - - - + + + + symbolic array lengths to be coordinated between various fields + + + + number of compositions + + + + + number of temperatures + + + + + number of values in applied electric field + + + + + number of values in applied magnetic field + + + + + number of values in applied pressure field + + + + + number of values in applied stress field + + + + + 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. + + + + Descriptive name of sample + + + + + 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. + + + + + Sample temperature. This could be a scanned variable + + + + + + + + + Applied electric field + + + + + - - - - - + + + + + - - - Applied magnetic field - - - + + + + Applied magnetic field + + + + + - - - - - + + + + + - - - Applied external stress field - - - + + + + Applied external stress field + + + + + - - - - - + + + + + - - - Applied pressure - - - - - - Sample changer position - - - Crystallography unit cell parameters a, b, and c - - - - - - Crystallography unit cell parameters alpha, beta, and gamma - - - - - - Unit cell parameters (lengths and angles) - - - - - - - Volume of the unit cell - - - - - - - This will follow the Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - - - - - - - - Orientation matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - - - - - - - - - - UB matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is - the multiplication of the orientation_matrix, given above, - with the :math:`B` matrix which - can be derived from the lattice constants. - - - - - - - - - Mass of sample - - - - - - Density of sample - - - - - - Relative Molecular Mass of sample - - - - - - - - - - - - - - - - - - - - - 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. - - - - - - - - - - - - - - Description of the sample - - - - Date of preparation of the sample - - - The position and orientation of the center of mass of the sample - - - Details of beam incident on sample - used to calculate sample/beam interaction point - - - - One group per sample component - This is the perferred way of recording per component information over the n_comp arrays - - - - Details of the component of the sample and/or can - - - - - - Type of component - - - - - - - - - - - - Concentration of each component - - - - - - Volume fraction of each component - - - - - - Scattering length density of each component - - - - - - In case it is all we know and we want to record/document it - - - - - - - - - - - - Crystallographic space group - - - - - - Crystallographic point group, deprecated if space_group present - - + + + + Applied pressure + + + + + + + + + Sample changer position + + + + + Crystallography unit cell parameters a, b, and c + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma + + + + + + + + Unit cell parameters (lengths and angles) + + + + + + + + + Volume of the unit cell + + + + + + + + This will follow the Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + + + + + + + + Orientation matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + + + + + + + + + + UB matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is + the multiplication of the orientation_matrix, given above, + with the :math:`B` matrix which + can be derived from the lattice constants. + + + + + + + + + + Mass of sample + + + + + + + + Density of sample + + + + + + + + Relative Molecular Mass of sample + + + + + + + + + + + + + + + + + + + + + + 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. + + + + + + + + + + + + + + Description of the sample + + + + + Date of preparation of the sample + + + + + The position and orientation of the center of mass of the sample + + + + + Details of beam incident on sample - used to calculate sample/beam interaction + point + + + + + One group per sample component + This is the perferred way of recording per component information over the n_comp arrays + + + + + Details of the component of the sample and/or can + + + - - - - Path length through sample/can for simple case when - it does not vary with scattering direction - - - - - Thickness of a beam entry/exit window on the can (mm) - - assumed same for entry and exit - - - - sample thickness - - - - Identification number or signatures of the sample used. - - - - - 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 - - - - - Physical state of the sample - - - - - Chemical purity of the sample - - - - - Surface termination of the sample (if crystalline) - - - - - Number of layers of the sample (e.g. bulk, monolayer, pentalayer, etc.) - - - - - Full chemical name of the sample - - - - - CAS registry number of the sample chemical content. - - - - - Gases might be fluxed on the surface for various reasons. Chemical designation, - or residual. - - - - - In the case of a fixed pressure measurement this is the scalar pressure. In the - case of an experiment in which pressure changes, or anyway is recorded, this is - an array of length m of pressures. - - - - - Element of evaporated surface dopant such as alkali or other - - - - - Nominal thickness of the evaporated dopant - - - - - Voltage applied to sample and sample holder. - - - - - Sample growth method (e. g. molecular beam epitaxy, chemical vapor deposition - etc.) - - - - - Name of the sample vendor (company or research group) - - - - - Material of the substrate in direct contact with the sample. - - - - - Physical state of the substrate, similar options to sample_state - - - - - Current to neutralize the photoemission current. This field may also be found in - NXmanpulator if present. - - - - - Possible bias of the sample with respect to analyser ground. This field may also - be found as sample_bias in NXmanipulator if present. - - - - - Further notes. - - - - As a function of Wavelength - - - temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value - - - Additional sample temperature environment information - - - magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value - - - magnetic_field_log.value is a link to e.g. magnetic_field_env.sensor1.value_log.value - - - Additional sample magnetic environment information - - - value sent to user's sample setup - - - logged value (or logic state) read from user's setup - - - 20 character fixed length sample description for legends - - - - - Optional rotation angle for the case when the powder diagram has - been obtained through an omega-2theta scan like from a traditional - single detector powder diffractometer. - Note, it is recommended to use NXtransformations instead. - - - - - Translation of the sample along the X-direction of the laboratory coordinate system - Note, it is recommended to use NXtransformations instead. - - - - - Translation of the sample along the Z-direction of the laboratory coordinate system. - Note, it is recommended to use NXtransformations instead. - - - - Any positioner (motor, PZT, ...) used to locate the sample - - - - This group describes the shape of the sample - - + + + + Type of component + + + + + + + + + + + + + + Concentration of each component + + + + + + + + Volume fraction of each component + + + + + + + + Scattering length density of each component + + + + + + + + In case it is all we know and we want to record/document it + + + + + + + + + + + + + + Crystallographic space group + + + + + + + + Crystallographic point group, deprecated if space_group present + + + + + + + + Path length through sample/can for simple case when + it does not vary with scattering direction + + + + + Thickness of a beam entry/exit window on the can (mm) + - assumed same for entry and exit + + + + + sample thickness + + + + + Identification number or signatures of the sample used. + + + + + 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 + + + + + Physical state of the sample + + + + + Chemical purity of the sample + + + + + Surface termination of the sample (if crystalline) + + + + + Number of layers of the sample (e.g. bulk, monolayer, pentalayer, etc.) + + + + + Full chemical name of the sample + + + + + CAS registry number of the sample chemical content. + + + + + Gases might be fluxed on the surface for various reasons. Chemical designation, + or residual. + + + + + In the case of a fixed pressure measurement this is the scalar pressure. In the + case of an experiment in which pressure changes, or anyway is recorded, this is + an array of length m of pressures. + + + + + Element of evaporated surface dopant such as alkali or other + + + + + Nominal thickness of the evaporated dopant + + + + + Voltage applied to sample and sample holder. + + + + + Sample growth method (e. g. molecular beam epitaxy, chemical vapor deposition + etc.) + + + + + Name of the sample vendor (company or research group) + + + + + Material of the substrate in direct contact with the sample. + + + + + Physical state of the substrate, similar options to sample_state + + + + + Current to neutralize the photoemission current. This field may also be found in + NXmanpulator if present. + + + + + Possible bias of the sample with respect to analyser ground. This field may also + be found as sample_bias in NXmanipulator if present. + + + + + Further notes. + + + + + As a function of Wavelength + + + + + temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value + + + + + Additional sample temperature environment information + + + + + magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value + + + + + magnetic_field_log.value is a link to e.g. + magnetic_field_env.sensor1.value_log.value + + + + + Additional sample magnetic environment information + + + + + value sent to user's sample setup + + + + + logged value (or logic state) read from user's setup + + + + + 20 character fixed length sample description for legends + + + + + + Optional rotation angle for the case when the powder diagram has + been obtained through an omega-2theta scan like from a traditional + single detector powder diffractometer. + Note, it is recommended to use NXtransformations instead. + + + + + Translation of the sample along the X-direction of the laboratory coordinate system + Note, it is recommended to use NXtransformations instead. + + + + + Translation of the sample along the Z-direction of the laboratory coordinate system. + Note, it is recommended to use NXtransformations instead. + + + + + Any positioner (motor, PZT, ...) used to locate the sample + + + + + This group describes the shape of the sample + + - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. + 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. - 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. - diff --git a/base_classes/NXsource.nxdl.xml b/base_classes/NXsource.nxdl.xml index 53946c7660..3fd1f983c7 100644 --- a/base_classes/NXsource.nxdl.xml +++ b/base_classes/NXsource.nxdl.xml @@ -1,9 +1,9 @@ - + - - The neutron or x-ray storage ring/facility. - - - Effective distance from sample - Distance as seen by radiation from sample. This number should be negative - to signify that it is upstream of the sample. - - - - Name of source - - short name for source, perhaps the acronym - - - - type of radiation source (pick one from the enumerated list and spell exactly) - - - - - - - - - - - - - - - - - - type of radiation probe (pick one from the enumerated list and spell exactly) - - - - - - - - - - - - - Source power - - - Source emittance (nm-rad) in X (horizontal) direction. - - - Source emittance (nm-rad) in Y (horizontal) direction. - - - particle beam size in x - - - particle beam size in y - - - Source intensity/area (example: s-1 cm-2) - - - - Source energy. - For storage rings, this would be the particle beam energy. - For X-ray tubes, this would be the excitation voltage. - - - - Accelerator, X-ray tube, or storage ring current - - - Accelerator voltage - - - Frequency of pulsed source - - - Period of pulsed source - - - Pulsed source target material - - - - - - - - - - - - - any source/facility related messages/events that - occurred during the experiment - - - - - For storage rings, description of the bunch pattern. - This is useful to describe irregular bunch patterns. - - name of the bunch pattern - - - For storage rings, the number of bunches in use. - - - For storage rings, temporal length of the bunch - - - For storage rings, time between bunches - - - temporal width of source pulse - - - source pulse shape - - - source operating mode - - for storage rings - for storage rings - - - - - Is the synchrotron operating in top_up mode? - - - For storage rings, the current at the end of the most recent injection. - date and time of the most recent injection. - - - - The center photon energy of the source, before it is - monochromatized or converted - - - - - The center wavelength of the source, before it is - monochromatized or converted - - - - - For pulsed sources, the energy of a single pulse - - - - - For pulsed sources, the pulse energy divided - by the pulse duration - - - - - Some facilities tag each bunch. - First bunch of the measurement - - - - - Last bunch of the measurement - - - - - "Engineering" location of source. - - - - - This group describes the shape of the beam line component + + + The neutron or x-ray storage ring/facility. + + + + Effective distance from sample + Distance as seen by radiation from sample. This number should be negative + to signify that it is upstream of the sample. + + + + + Name of source + + + + short name for source, perhaps the acronym + + + + + + type of radiation source (pick one from the enumerated list and spell exactly) + + + + + + + + + + + + + + + + + + + + type of radiation probe (pick one from the enumerated list and spell exactly) + + + + + + + + + + + + + + + Source power + + + + + Source emittance (nm-rad) in X (horizontal) direction. + + + + + Source emittance (nm-rad) in Y (horizontal) direction. + + + + + particle beam size in x + + + + + particle beam size in y + + + + + Source intensity/area (example: s-1 cm-2) + + + + + Source energy. + For storage rings, this would be the particle beam energy. + For X-ray tubes, this would be the excitation voltage. + + + + + Accelerator, X-ray tube, or storage ring current + + + + + Accelerator voltage + + + + + Frequency of pulsed source + + + + + Period of pulsed source + + + + + Pulsed source target material + + + + + + + + + + + + + + any source/facility related messages/events that + occurred during the experiment + + + + + For storage rings, description of the bunch pattern. + This is useful to describe irregular bunch patterns. + + + + name of the bunch pattern - - - The wavelength or energy distribution of the source - + + + + + For storage rings, the number of bunches in use. + + + + + For storage rings, temporal length of the bunch + + + + + For storage rings, time between bunches + + + + + temporal width of source pulse + + + + + + source pulse shape + + + + + + source operating mode + + + + + for storage rings + + + + + for storage rings + + + + + + + + + Is the synchrotron operating in top_up mode? + + + + + For storage rings, the current at the end of the most recent injection. + + + + date and time of the most recent injection. + + + + + + The center photon energy of the source, before it is + monochromatized or converted + + + + + The center wavelength of the source, before it is + monochromatized or converted + + + + + For pulsed sources, the energy of a single pulse + + + + + For pulsed sources, the pulse energy divided + by the pulse duration + + + + + Some facilities tag each bunch. + First bunch of the measurement + + + + + Last bunch of the measurement + + + + + "Engineering" location of source. + + + + + This group describes the shape of the beam line component + + + + + The wavelength or energy distribution of the source + + - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the - z axis. - - .. image:: source/source.png - :width: 40% - + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the + z axis. + + .. image:: source/source.png + :width: 40% - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. diff --git a/contributed_definitions/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXcollectioncolumn.nxdl.xml index c8bd717074..3117648c3a 100644 --- a/contributed_definitions/NXcollectioncolumn.nxdl.xml +++ b/contributed_definitions/NXcollectioncolumn.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -21,10 +21,10 @@ # # For further information, see http://www.nexusformat.org --> - + - 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. diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index ff13c5e93d..f29e7337f0 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -21,10 +21,10 @@ # # For further information, see http://www.nexusformat.org --> - + - This is the most general application definition for multidimensional - photoelectron spectroscopy. + This is the most general application definition for multidimensional + photoelectron spectroscopy. @@ -303,8 +303,8 @@ List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all + that are contained in the sample. + If the sample substance has multiple components, all elements from each component must be included in `atom_types`. From 4087466dfc5a345df15b3fbc1b617e457e2b0717 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 31 Aug 2023 11:22:51 +0200 Subject: [PATCH 0235/1012] Recreate nxdl files --- base_classes/NXsample.nxdl.xml | 0 1 file changed, 0 insertions(+), 0 deletions(-) mode change 100755 => 100644 base_classes/NXsample.nxdl.xml diff --git a/base_classes/NXsample.nxdl.xml b/base_classes/NXsample.nxdl.xml old mode 100755 new mode 100644 From 71c3c89fb0753607066f5e9af8920c09032c5856 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 31 Aug 2023 14:33:39 +0200 Subject: [PATCH 0236/1012] Regenerate base class yaml files --- base_classes/nyaml/NXsample.yaml | 589 ++++++++++++++++++++- base_classes/nyaml/NXsample_component.yaml | 273 +++++++++- 2 files changed, 844 insertions(+), 18 deletions(-) diff --git a/base_classes/nyaml/NXsample.yaml b/base_classes/nyaml/NXsample.yaml index 1aa3de328e..dd8c7a7890 100644 --- a/base_classes/nyaml/NXsample.yaml +++ b/base_classes/nyaml/NXsample.yaml @@ -192,7 +192,8 @@ NXsample(NXobject): The position and orientation of the center of mass of the sample (NXbeam): doc: | - Details of beam incident on sample - used to calculate sample/beam interaction point + Details of beam incident on sample - used to calculate sample/beam interaction + point (NXsample_component): doc: | One group per sample component @@ -276,7 +277,8 @@ NXsample(NXobject): deprecated: | use ``magnetic_field``, see: https://github.com/nexusformat/definitions/issues/816 doc: | - magnetic_field_log.value is a link to e.g. magnetic_field_env.sensor1.value_log.value + magnetic_field_log.value is a link to e.g. + magnetic_field_env.sensor1.value_log.value magnetic_field_env(NXenvironment): doc: | Additional sample magnetic environment information @@ -290,8 +292,8 @@ NXsample(NXobject): short_title: doc: | 20 character fixed length sample description for legends - - # How is the string length limitation imposed by the XSD? + + # How is the string length limitation imposed by the XSD? rotation_angle(NX_FLOAT): unit: NX_ANGLE doc: | @@ -313,22 +315,31 @@ NXsample(NXobject): doc: | Any positioner (motor, PZT, ...) used to locate the sample (NXoff_geometry): + # exists: ['min', '0'] doc: | This group describes the shape of the sample + (NXsingle_crystal): + doc: | + If the sample is a single crystal, add description of single crystal and unit + cell. (NXsample_component_set): doc: | Set of sample components and their configuration. There can only be one NXsample_component_set in one component. - # exists: [max, 1] + + # exists: [max, 1] (NXsubstance): doc: | - If the sample is made from a pure substance and cannot be further divided using NXsample_component. - # exists: [max, 1] + If the sample is made from a pure substance and cannot be further divided using + NXsample_component. + + # exists: [max, 1] (NXfabrication): doc: | Details about the sample vendor (company or research group) (NXenvironment): + # eventually, this should be stored in the application definitions doc: | Any environmental or external stimuli/measurements. @@ -362,4 +373,566 @@ NXsample(NXobject): This is the group recommended for holding the chain of translation and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in - other component groups. \ No newline at end of file + other component groups. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 359e67b69525d94347bd6db9aa776e2c77b3e87b9a30b4d6a3e90ec29253c59c +# +# +# +# +# +# +# symbolic array lengths to be coordinated between various fields +# +# +# +# number of compositions +# +# +# +# +# number of temperatures +# +# +# +# +# number of values in applied electric field +# +# +# +# +# number of values in applied magnetic field +# +# +# +# +# number of values in applied pressure field +# +# +# +# +# number of values in applied stress field +# +# +# +# +# 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. +# +# +# +# Descriptive name of sample +# +# +# +# +# Identification number or signatures of the sample used. +# +# +# +# +# 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. +# +# +# +# +# Sample temperature. This could be a scanned variable +# +# +# +# +# +# +# +# +# Applied electric field +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Applied magnetic field +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Applied external stress field +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Applied pressure +# +# +# +# +# +# +# +# +# Sample changer position +# +# +# +# +# Crystallography unit cell parameters a, b, and c +# +# +# +# +# +# +# +# Crystallography unit cell parameters alpha, beta, and gamma +# +# +# +# +# +# +# +# Unit cell parameters (lengths and angles) +# +# +# +# +# +# +# +# +# Volume of the unit cell +# +# +# +# +# +# +# +# This will follow the Busing-Levy convention: +# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 +# +# +# +# +# +# +# +# Orientation matrix of single crystal sample using Busing-Levy convention: +# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 +# +# +# +# +# +# +# +# +# +# UB matrix of single crystal sample using Busing-Levy convention: +# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is +# the multiplication of the orientation_matrix, given above, +# with the :math:`B` matrix which +# can be derived from the lattice constants. +# +# +# +# +# +# +# +# +# +# Mass of sample +# +# +# +# +# +# +# +# Density of sample +# +# +# +# +# +# +# +# Relative Molecular Mass of sample +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# 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. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Description of the sample +# +# +# +# +# Date of preparation of the sample +# +# +# +# +# The position and orientation of the center of mass of the sample +# +# +# +# +# Details of beam incident on sample - used to calculate sample/beam interaction +# point +# +# +# +# +# One group per sample component +# This is the perferred way of recording per component information over the n_comp arrays +# +# +# +# +# Details of the component of the sample and/or can +# +# +# +# +# +# +# +# Type of component +# +# +# +# +# +# +# +# +# +# +# +# +# +# Concentration of each component +# +# +# +# +# +# +# +# Volume fraction of each component +# +# +# +# +# +# +# +# Scattering length density of each component +# +# +# +# +# +# +# +# In case it is all we know and we want to record/document it +# +# +# +# +# +# +# +# +# +# +# +# +# +# Crystallographic space group +# +# +# +# +# +# +# +# Crystallographic point group, deprecated if space_group present +# +# +# +# +# +# +# +# Path length through sample/can for simple case when +# it does not vary with scattering direction +# +# +# +# +# Thickness of a beam entry/exit window on the can (mm) +# - assumed same for entry and exit +# +# +# +# +# sample thickness +# +# +# +# +# As a function of Wavelength +# +# +# +# +# temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value +# +# +# +# +# Additional sample temperature environment information +# +# +# +# +# magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value +# +# +# +# +# magnetic_field_log.value is a link to e.g. +# magnetic_field_env.sensor1.value_log.value +# +# +# +# +# Additional sample magnetic environment information +# +# +# +# +# value sent to user's sample setup +# +# +# +# +# logged value (or logic state) read from user's setup +# +# +# +# +# 20 character fixed length sample description for legends +# +# +# +# +# +# Optional rotation angle for the case when the powder diagram has +# been obtained through an omega-2theta scan like from a traditional +# single detector powder diffractometer. +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# Translation of the sample along the X-direction of the laboratory coordinate system +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# Translation of the sample along the Z-direction of the laboratory coordinate system. +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# Any positioner (motor, PZT, ...) used to locate the sample +# +# +# +# +# +# This group describes the shape of the sample +# +# +# +# +# If the sample is a single crystal, add description of single crystal and unit +# cell. +# +# +# +# +# Set of sample components and their configuration. +# There can only be one NXsample_component_set in one component. +# +# +# +# +# +# If the sample is made from a pure substance and cannot be further divided using +# NXsample_component. +# +# +# +# +# +# Details about the sample vendor (company or research group) +# +# +# +# +# +# Any environmental or external stimuli/measurements. +# These can include, among others: +# applied pressure, surrounding gas phase and gas pressure, +# external electric/magnetic/mechanical fields, temperature, ... +# +# +# +# +# A set of physical processes that occurred to the sample prior/during experiment. +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# diff --git a/base_classes/nyaml/NXsample_component.yaml b/base_classes/nyaml/NXsample_component.yaml index 7eb58b30a2..15dc89ad20 100644 --- a/base_classes/nyaml/NXsample_component.yaml +++ b/base_classes/nyaml/NXsample_component.yaml @@ -1,6 +1,7 @@ category: base doc: | - One group like this per component can be recorded For a sample consisting of multiple components. + One group like this per component can be recorded For a sample consisting of + multiple components. symbols: doc: | symbolic array lengths to be coordinated between various fields @@ -61,7 +62,8 @@ NXsample_component(NXobject): sample_orientation(NX_FLOAT): unit: NX_ANGLE doc: | - This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) + This will follow the Busing and Levy convention from Acta.Crysta v22, p457 + (1967) dimensions: rank: 1 dim: [[1, 3]] @@ -93,7 +95,7 @@ NXsample_component(NXobject): scattering_length_density(NX_FLOAT): unit: NX_SCATTERING_LENGTH_DENSITY doc: | - Scattering length density of component + Scattering length density of component unit_cell_class: doc: | In case it is all we know and we want to record/document it @@ -107,24 +109,32 @@ NXsample_component(NXobject): transmission(NXdata): doc: | As a function of Wavelength + (NXsingle_crystal): + doc: | + If the component is a single crystal, add description of single crystal and unit + cell. (NXsample_component_set): doc: | Set of sub-components and their configuration. There can only be one NXsample_component_set in one component. - # exists: [max, 1] + + # exists: [max, 1] (NXsubstance): - doc: | - If the component is made from a pure substance and cannot be further divided using NXsample_component. - # exists: [max, 1] + doc: | + If the component is made from a pure substance and cannot be further divided + using NXsample_component. + + # exists: [max, 1] (NXfabrication): doc: | Details about the sample component vendor (company or research group) (NXsample_history): doc: | - A set of physical processes that occurred to the sample component prior/during experiment. + A set of physical processes that occurred to the sample component prior/during + experiment. depends_on: doc: | - Any NXsample_component depends on the instance of NXsample_component_set, at the same level of + Any NXsample_component depends on the instance of NXsample_component_set, at the same level of description granularity where the component is located. \@default: doc: | @@ -136,4 +146,247 @@ NXsample_component(NXobject): It is recommended (as of NIAC2014) to use this attribute to help define the path to the default dataset to be plotted. See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. \ No newline at end of file + for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 07c4e31c308138182eef1cdddefda26ba6c879da8df45c3f0b03213996fc8fcb +# +# +# +# +# +# +# symbolic array lengths to be coordinated between various fields +# +# +# +# number of temperatures +# +# +# +# +# number of values in applied electric field +# +# +# +# +# number of values in applied magnetic field +# +# +# +# +# number of values in applied pressure field +# +# +# +# +# number of values in applied stress field +# +# +# +# +# One group like this per component can be recorded For a sample consisting of +# multiple components. +# +# +# +# Descriptive name of sample component +# +# +# +# +# Identification number or signatures of the sample component used. +# +# +# +# +# The chemical formula specified using CIF conventions. +# 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. +# +# +# +# +# Crystallography unit cell parameters a, b, and c +# +# +# +# +# +# +# +# Crystallography unit cell parameters alpha, beta, and gamma +# +# +# +# +# +# +# +# Volume of the unit cell +# +# +# +# +# This will follow the Busing and Levy convention from Acta.Crysta v22, p457 +# (1967) +# +# +# +# +# +# +# +# Orientation matrix of single crystal sample component. +# This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) +# +# +# +# +# +# +# +# +# Mass of sample component +# +# +# +# +# Density of sample component +# +# +# +# +# Relative Molecular Mass of sample component +# +# +# +# +# Description of the sample component +# +# +# +# +# Volume fraction of component +# +# +# +# +# Scattering length density of component +# +# +# +# +# In case it is all we know and we want to record/document it +# +# +# +# +# +# +# +# +# +# +# +# +# +# Crystallographic space group +# +# +# +# +# Crystallographic point group, deprecated if space_group present +# +# +# +# +# As a function of Wavelength +# +# +# +# +# If the component is a single crystal, add description of single crystal and unit +# cell. +# +# +# +# +# Set of sub-components and their configuration. +# There can only be one NXsample_component_set in one component. +# +# +# +# +# +# If the component is made from a pure substance and cannot be further divided +# using NXsample_component. +# +# +# +# +# +# Details about the sample component vendor (company or research group) +# +# +# +# +# A set of physical processes that occurred to the sample component prior/during +# experiment. +# +# +# +# +# Any NXsample_component depends on the instance of NXsample_component_set, at the same level of +# description granularity where the component is located. +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# From 45b1bb43d32438ba334815c6205b082b5b056422 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 31 Aug 2023 14:38:22 +0200 Subject: [PATCH 0237/1012] Remove NXDl comments from yaml files --- base_classes/nyaml/NXsample.yaml | 580 +-------------------- base_classes/nyaml/NXsample_component.yaml | 260 +-------- 2 files changed, 12 insertions(+), 828 deletions(-) diff --git a/base_classes/nyaml/NXsample.yaml b/base_classes/nyaml/NXsample.yaml index dd8c7a7890..a457644cd0 100644 --- a/base_classes/nyaml/NXsample.yaml +++ b/base_classes/nyaml/NXsample.yaml @@ -192,8 +192,7 @@ NXsample(NXobject): The position and orientation of the center of mass of the sample (NXbeam): doc: | - Details of beam incident on sample - used to calculate sample/beam interaction - point + Details of beam incident on sample - used to calculate sample/beam interaction point (NXsample_component): doc: | One group per sample component @@ -277,8 +276,7 @@ NXsample(NXobject): deprecated: | use ``magnetic_field``, see: https://github.com/nexusformat/definitions/issues/816 doc: | - magnetic_field_log.value is a link to e.g. - magnetic_field_env.sensor1.value_log.value + magnetic_field_log.value is a link to e.g. magnetic_field_env.sensor1.value_log.value magnetic_field_env(NXenvironment): doc: | Additional sample magnetic environment information @@ -293,7 +291,7 @@ NXsample(NXobject): doc: | 20 character fixed length sample description for legends - # How is the string length limitation imposed by the XSD? + # How is the string length limitation imposed by the XSD? rotation_angle(NX_FLOAT): unit: NX_ANGLE doc: | @@ -315,7 +313,6 @@ NXsample(NXobject): doc: | Any positioner (motor, PZT, ...) used to locate the sample (NXoff_geometry): - # exists: ['min', '0'] doc: | This group describes the shape of the sample @@ -327,19 +324,16 @@ NXsample(NXobject): doc: | Set of sample components and their configuration. There can only be one NXsample_component_set in one component. - - # exists: [max, 1] + # exists: [max, 1] (NXsubstance): doc: | If the sample is made from a pure substance and cannot be further divided using NXsample_component. - - # exists: [max, 1] + # exists: [max, 1] (NXfabrication): doc: | Details about the sample vendor (company or research group) (NXenvironment): - # eventually, this should be stored in the application definitions doc: | Any environmental or external stimuli/measurements. @@ -373,566 +367,4 @@ NXsample(NXobject): 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 359e67b69525d94347bd6db9aa776e2c77b3e87b9a30b4d6a3e90ec29253c59c -# -# -# -# -# -# -# symbolic array lengths to be coordinated between various fields -# -# -# -# number of compositions -# -# -# -# -# number of temperatures -# -# -# -# -# number of values in applied electric field -# -# -# -# -# number of values in applied magnetic field -# -# -# -# -# number of values in applied pressure field -# -# -# -# -# number of values in applied stress field -# -# -# -# -# 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. -# -# -# -# Descriptive name of sample -# -# -# -# -# Identification number or signatures of the sample used. -# -# -# -# -# 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. -# -# -# -# -# Sample temperature. This could be a scanned variable -# -# -# -# -# -# -# -# -# Applied electric field -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Applied magnetic field -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Applied external stress field -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Applied pressure -# -# -# -# -# -# -# -# -# Sample changer position -# -# -# -# -# Crystallography unit cell parameters a, b, and c -# -# -# -# -# -# -# -# Crystallography unit cell parameters alpha, beta, and gamma -# -# -# -# -# -# -# -# Unit cell parameters (lengths and angles) -# -# -# -# -# -# -# -# -# Volume of the unit cell -# -# -# -# -# -# -# -# This will follow the Busing-Levy convention: -# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 -# -# -# -# -# -# -# -# Orientation matrix of single crystal sample using Busing-Levy convention: -# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 -# -# -# -# -# -# -# -# -# -# UB matrix of single crystal sample using Busing-Levy convention: -# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is -# the multiplication of the orientation_matrix, given above, -# with the :math:`B` matrix which -# can be derived from the lattice constants. -# -# -# -# -# -# -# -# -# -# Mass of sample -# -# -# -# -# -# -# -# Density of sample -# -# -# -# -# -# -# -# Relative Molecular Mass of sample -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# 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. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Description of the sample -# -# -# -# -# Date of preparation of the sample -# -# -# -# -# The position and orientation of the center of mass of the sample -# -# -# -# -# Details of beam incident on sample - used to calculate sample/beam interaction -# point -# -# -# -# -# One group per sample component -# This is the perferred way of recording per component information over the n_comp arrays -# -# -# -# -# Details of the component of the sample and/or can -# -# -# -# -# -# -# -# Type of component -# -# -# -# -# -# -# -# -# -# -# -# -# -# Concentration of each component -# -# -# -# -# -# -# -# Volume fraction of each component -# -# -# -# -# -# -# -# Scattering length density of each component -# -# -# -# -# -# -# -# In case it is all we know and we want to record/document it -# -# -# -# -# -# -# -# -# -# -# -# -# -# Crystallographic space group -# -# -# -# -# -# -# -# Crystallographic point group, deprecated if space_group present -# -# -# -# -# -# -# -# Path length through sample/can for simple case when -# it does not vary with scattering direction -# -# -# -# -# Thickness of a beam entry/exit window on the can (mm) -# - assumed same for entry and exit -# -# -# -# -# sample thickness -# -# -# -# -# As a function of Wavelength -# -# -# -# -# temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value -# -# -# -# -# Additional sample temperature environment information -# -# -# -# -# magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value -# -# -# -# -# magnetic_field_log.value is a link to e.g. -# magnetic_field_env.sensor1.value_log.value -# -# -# -# -# Additional sample magnetic environment information -# -# -# -# -# value sent to user's sample setup -# -# -# -# -# logged value (or logic state) read from user's setup -# -# -# -# -# 20 character fixed length sample description for legends -# -# -# -# -# -# Optional rotation angle for the case when the powder diagram has -# been obtained through an omega-2theta scan like from a traditional -# single detector powder diffractometer. -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# Translation of the sample along the X-direction of the laboratory coordinate system -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# Translation of the sample along the Z-direction of the laboratory coordinate system. -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# Any positioner (motor, PZT, ...) used to locate the sample -# -# -# -# -# -# This group describes the shape of the sample -# -# -# -# -# If the sample is a single crystal, add description of single crystal and unit -# cell. -# -# -# -# -# Set of sample components and their configuration. -# There can only be one NXsample_component_set in one component. -# -# -# -# -# -# If the sample is made from a pure substance and cannot be further divided using -# NXsample_component. -# -# -# -# -# -# Details about the sample vendor (company or research group) -# -# -# -# -# -# Any environmental or external stimuli/measurements. -# These can include, among others: -# applied pressure, surrounding gas phase and gas pressure, -# external electric/magnetic/mechanical fields, temperature, ... -# -# -# -# -# A set of physical processes that occurred to the sample prior/during experiment. -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# -# -# -# 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. -# -# -# + other component groups. \ No newline at end of file diff --git a/base_classes/nyaml/NXsample_component.yaml b/base_classes/nyaml/NXsample_component.yaml index 15dc89ad20..0678f30a22 100644 --- a/base_classes/nyaml/NXsample_component.yaml +++ b/base_classes/nyaml/NXsample_component.yaml @@ -1,7 +1,6 @@ category: base doc: | - One group like this per component can be recorded For a sample consisting of - multiple components. + One group like this per component can be recorded For a sample consisting of multiple components. symbols: doc: | symbolic array lengths to be coordinated between various fields @@ -62,8 +61,7 @@ NXsample_component(NXobject): sample_orientation(NX_FLOAT): unit: NX_ANGLE doc: | - This will follow the Busing and Levy convention from Acta.Crysta v22, p457 - (1967) + This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) dimensions: rank: 1 dim: [[1, 3]] @@ -117,21 +115,18 @@ NXsample_component(NXobject): doc: | Set of sub-components and their configuration. There can only be one NXsample_component_set in one component. - - # exists: [max, 1] + # exists: [max, 1] (NXsubstance): doc: | If the component is made from a pure substance and cannot be further divided using NXsample_component. - - # exists: [max, 1] + # exists: [max, 1] (NXfabrication): doc: | Details about the sample component vendor (company or research group) (NXsample_history): doc: | - A set of physical processes that occurred to the sample component prior/during - experiment. + A set of physical processes that occurred to the sample component prior/during experiment. depends_on: doc: | Any NXsample_component depends on the instance of NXsample_component_set, at the same level of @@ -146,247 +141,4 @@ NXsample_component(NXobject): It is recommended (as of NIAC2014) to use this attribute to help define the path to the default dataset to be plotted. See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 07c4e31c308138182eef1cdddefda26ba6c879da8df45c3f0b03213996fc8fcb -# -# -# -# -# -# -# symbolic array lengths to be coordinated between various fields -# -# -# -# number of temperatures -# -# -# -# -# number of values in applied electric field -# -# -# -# -# number of values in applied magnetic field -# -# -# -# -# number of values in applied pressure field -# -# -# -# -# number of values in applied stress field -# -# -# -# -# One group like this per component can be recorded For a sample consisting of -# multiple components. -# -# -# -# Descriptive name of sample component -# -# -# -# -# Identification number or signatures of the sample component used. -# -# -# -# -# The chemical formula specified using CIF conventions. -# 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. -# -# -# -# -# Crystallography unit cell parameters a, b, and c -# -# -# -# -# -# -# -# Crystallography unit cell parameters alpha, beta, and gamma -# -# -# -# -# -# -# -# Volume of the unit cell -# -# -# -# -# This will follow the Busing and Levy convention from Acta.Crysta v22, p457 -# (1967) -# -# -# -# -# -# -# -# Orientation matrix of single crystal sample component. -# This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) -# -# -# -# -# -# -# -# -# Mass of sample component -# -# -# -# -# Density of sample component -# -# -# -# -# Relative Molecular Mass of sample component -# -# -# -# -# Description of the sample component -# -# -# -# -# Volume fraction of component -# -# -# -# -# Scattering length density of component -# -# -# -# -# In case it is all we know and we want to record/document it -# -# -# -# -# -# -# -# -# -# -# -# -# -# Crystallographic space group -# -# -# -# -# Crystallographic point group, deprecated if space_group present -# -# -# -# -# As a function of Wavelength -# -# -# -# -# If the component is a single crystal, add description of single crystal and unit -# cell. -# -# -# -# -# Set of sub-components and their configuration. -# There can only be one NXsample_component_set in one component. -# -# -# -# -# -# If the component is made from a pure substance and cannot be further divided -# using NXsample_component. -# -# -# -# -# -# Details about the sample component vendor (company or research group) -# -# -# -# -# A set of physical processes that occurred to the sample component prior/during -# experiment. -# -# -# -# -# Any NXsample_component depends on the instance of NXsample_component_set, at the same level of -# description granularity where the component is located. -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# + for a summary of the discussion. \ No newline at end of file From be7afafb3f430c3a8469ff4f817ff9d178c2507b Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Thu, 31 Aug 2023 14:48:50 +0200 Subject: [PATCH 0238/1012] Activated collapsible docstrings, change page width, added fairmat corporate design colours, added chopping of too long first lines of docstrings, added acknowledgements of the dfg and the nfdi on the front page --- dev_tools/docs/nxdl.py | 18 ++++++++++++------ manual/source/_static/to_alabaster.css | 3 ++- manual/source/conf.py | 10 ++++++---- manual/source/index.rst | 6 ++++++ 4 files changed, 26 insertions(+), 11 deletions(-) diff --git a/dev_tools/docs/nxdl.py b/dev_tools/docs/nxdl.py index b873e32871..9d23f6ea88 100755 --- a/dev_tools/docs/nxdl.py +++ b/dev_tools/docs/nxdl.py @@ -17,6 +17,10 @@ from ..utils.types import PathLike from .anchor_list import AnchorRegistry +# controlling the length of progressively more indented sub-node +MIN_COLLAPSE_HINT_LINE_LENGTH = 20 +MAX_COLLAPSE_HINT_LINE_LENGTH = 80 + class NXClassDocGenerator: """Generate documentation in reStructuredText markup @@ -519,27 +523,29 @@ def _print_doc(self, indent, ns, node, required=False): self._print(f"{indent}{line}") self._print() - def long_doc(self, ns, node): + def long_doc(self, ns, node, left_margin): length = 0 line = "documentation" fnd = False blocks = self._get_doc_blocks(ns, node) + max_characters = max(MIN_COLLAPSE_HINT_LINE_LENGTH, + (MAX_COLLAPSE_HINT_LINE_LENGTH - left_margin)) for block in blocks: lines = block.splitlines() length += len(lines) for single_line in lines: if len(single_line) > 2 and single_line[0] != "." and not fnd: fnd = True - line = single_line + line = single_line[:max_characters] return (length, line, blocks) def _print_doc_enum(self, indent, ns, node, required=False): collapse_indent = indent node_list = node.xpath("nx:enumeration", namespaces=ns) - (doclen, line, blocks) = self.long_doc(ns, node) - # if len(node_list) + doclen > 1: - # collapse_indent = f"{indent} " - # self._print(f"{indent}{self._INDENTATION_UNIT}.. collapse:: {line} ...\n") + (doclen, line, blocks) = self.long_doc(ns, node, len(indent)) + if len(node_list) + doclen > 1: + collapse_indent = f"{indent} " + self._print(f"{indent}{self._INDENTATION_UNIT}.. collapse:: {line} ...\n") self._print_doc( collapse_indent + self._INDENTATION_UNIT, ns, node, required=required ) diff --git a/manual/source/_static/to_alabaster.css b/manual/source/_static/to_alabaster.css index 32ccc19a69..3518cf2f74 100644 --- a/manual/source/_static/to_alabaster.css +++ b/manual/source/_static/to_alabaster.css @@ -2,8 +2,9 @@ /* Override sidebar background color default (#FFFFFF) */ .sphinxsidebar { - background: #005F73 !important; + background: #283593 !important; } +/* #005F73 is the original NIAC sidebar colour */ /* Control logo positioning */ .sphinxsidebarwrapper p.logo { diff --git a/manual/source/conf.py b/manual/source/conf.py index 0e3cf29dcd..00857a04e9 100755 --- a/manual/source/conf.py +++ b/manual/source/conf.py @@ -35,7 +35,7 @@ # -- General configuration --------------------------------------------------- # https://github.com/nexusformat/definitions/issues/659#issuecomment-577438319 -needs_sphinx = '2.3' +needs_sphinx = '2.5' # Add any Sphinx extension module names here, as strings. They can be # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom @@ -52,6 +52,7 @@ 'contrib_ext' ] + # Show `.. todo` directives in the output # todo_include_todos = True @@ -113,8 +114,9 @@ def setup(app): 'github_repo': 'nexus_definitions/tree/fairmat', 'github_user': 'FAIRmat-Experimental', 'github_count': 'false', # We don't get the cute counter baloon if we want to point to the branch - 'sidebar_width': '235px', - 'page_width': '1000px', + 'sidebar_width': '300px', + 'body_max_width': 'auto', + 'page_width': 'auto', 'font_size': '12pt', 'font_family': 'Arial', 'description': 'Proposal of NeXus expansion for FAIRmat data.', @@ -149,7 +151,7 @@ def setup(app): comments_config = { "hypothesis": True - } +} # -- Options for Latex output ------------------------------------------------- latex_elements = { diff --git a/manual/source/index.rst b/manual/source/index.rst index dfa4d1bcf9..d2d0ee59b8 100644 --- a/manual/source/index.rst +++ b/manual/source/index.rst @@ -36,6 +36,12 @@ https://www.nexusformat.org/ | This commit identifier <>. | This manual built |today|. +.. rubric:: Acknowledgements + +| The FAIRmat project is funded by the Deutsche Forschungsgemeinschaft +| (`DFG `_, German Research Foundation) - project 460197019. +| FAIRmat is a consortium within the `German NFDI `_. + .. seealso:: From 4ef3dbb9a015712b13ebb3a8ebd5c848d3eecaa6 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 31 Aug 2023 14:52:03 +0200 Subject: [PATCH 0239/1012] Remove all nyaml files --- base_classes/nyaml/NXsample.yaml | 370 ------------------ base_classes/nyaml/NXsample_component.yaml | 144 ------- contributed_definitions/nyaml/NXactivity.yaml | 23 -- .../nyaml/NXchemical_process.yaml | 25 -- .../nyaml/NXphysical_process.yaml | 26 -- .../nyaml/NXrotation_set.yaml | 176 --------- .../nyaml/NXsample_component_set.yaml | 42 -- .../nyaml/NXsample_history.yaml | 34 -- .../nyaml/NXsingle_crystal.yaml | 31 -- .../nyaml/NXsubstance.yaml | 67 ---- .../nyaml/NXunit_cell.yaml | 130 ------ 11 files changed, 1068 deletions(-) delete mode 100644 base_classes/nyaml/NXsample.yaml delete mode 100644 base_classes/nyaml/NXsample_component.yaml delete mode 100644 contributed_definitions/nyaml/NXactivity.yaml delete mode 100644 contributed_definitions/nyaml/NXchemical_process.yaml delete mode 100644 contributed_definitions/nyaml/NXphysical_process.yaml delete mode 100644 contributed_definitions/nyaml/NXrotation_set.yaml delete mode 100644 contributed_definitions/nyaml/NXsample_component_set.yaml delete mode 100644 contributed_definitions/nyaml/NXsample_history.yaml delete mode 100644 contributed_definitions/nyaml/NXsingle_crystal.yaml delete mode 100644 contributed_definitions/nyaml/NXsubstance.yaml delete mode 100644 contributed_definitions/nyaml/NXunit_cell.yaml diff --git a/base_classes/nyaml/NXsample.yaml b/base_classes/nyaml/NXsample.yaml deleted file mode 100644 index a457644cd0..0000000000 --- a/base_classes/nyaml/NXsample.yaml +++ /dev/null @@ -1,370 +0,0 @@ -category: base -doc: | - 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. -symbols: - doc: | - symbolic array lengths to be coordinated between various fields - n_comp: | - number of compositions - n_Temp: | - number of temperatures - n_eField: | - number of values in applied electric field - n_mField: | - number of values in applied magnetic field - n_pField: | - number of values in applied pressure field - n_sField: | - number of values in applied stress field -type: group -NXsample(NXobject): - name: - doc: | - Descriptive name of sample - sample_id: - doc: | - Identification number or signatures of the sample used. - chemical_formula: - doc: | - 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. - temperature(NX_FLOAT): - unit: NX_TEMPERATURE - doc: | - Sample temperature. This could be a scanned variable - dimensions: - rank: anyRank - - # could be any length - dim: [[1, n_Temp]] - electric_field(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - Applied electric field - dimensions: - - # could be any length - dim: [[1, n_eField]] - \@direction: - enumeration: [x, y, z] - magnetic_field(NX_FLOAT): - unit: NX_ANY - doc: | - Applied magnetic field - dimensions: - - # could be any length - dim: [[1, n_mField]] - \@direction: - enumeration: [x, y, z] - stress_field(NX_FLOAT): - unit: NX_ANY - doc: | - Applied external stress field - dimensions: - - # could be any length - dim: [[1, n_sField]] - \@direction: - enumeration: [x, y, z] - pressure(NX_FLOAT): - unit: NX_PRESSURE - doc: | - Applied pressure - dimensions: - - # could be any length - dim: [[1, n_pField]] - changer_position(NX_INT): - unit: NX_UNITLESS - doc: | - Sample changer position - unit_cell_abc(NX_FLOAT): - unit: NX_LENGTH - doc: | - Crystallography unit cell parameters a, b, and c - dimensions: - dim: [[1, 3]] - unit_cell_alphabetagamma(NX_FLOAT): - unit: NX_ANGLE - doc: | - Crystallography unit cell parameters alpha, beta, and gamma - dimensions: - dim: [[1, 3]] - unit_cell(NX_FLOAT): - unit: NX_LENGTH - doc: | - Unit cell parameters (lengths and angles) - dimensions: - rank: 2 - dim: [[1, n_comp], [2, 6]] - unit_cell_volume(NX_FLOAT): - unit: NX_VOLUME - doc: | - Volume of the unit cell - dimensions: - rank: 1 - dim: [[1, n_comp]] - sample_orientation(NX_FLOAT): - unit: NX_ANGLE - doc: | - This will follow the Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - dimensions: - rank: 1 - dim: [[1, 3]] - orientation_matrix(NX_FLOAT): - doc: | - Orientation matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - dimensions: - rank: 3 - dim: [[1, n_comp], [2, 3], [3, 3]] - ub_matrix(NX_FLOAT): - doc: | - UB matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is - the multiplication of the orientation_matrix, given above, - with the :math:`B` matrix which - can be derived from the lattice constants. - dimensions: - rank: 3 - dim: [[1, n_comp], [2, 3], [3, 3]] - mass(NX_FLOAT): - unit: NX_MASS - doc: | - Mass of sample - dimensions: - rank: 1 - dim: [[1, n_comp]] - density(NX_FLOAT): - unit: NX_MASS_DENSITY - doc: | - Density of sample - dimensions: - rank: 1 - dim: [[1, n_comp]] - relative_molecular_mass(NX_FLOAT): - unit: NX_MASS - doc: | - Relative Molecular Mass of sample - dimensions: - rank: 1 - dim: [[1, n_comp]] - type: - enumeration: [sample, sample+can, can, sample+buffer, buffer, calibration sample, normalisation sample, simulated data, none, sample environment] - situation: - doc: | - 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. - enumeration: [air, vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere, sealed can, other] - description: - doc: | - Description of the sample - preparation_date(NX_DATE_TIME): - doc: | - Date of preparation of the sample - geometry(NXgeometry): - deprecated: | - Use the field `depends_on` and :ref:`NXtransformations` to position the sample and NXoff_geometry to describe its shape instead - doc: | - The position and orientation of the center of mass of the sample - (NXbeam): - doc: | - Details of beam incident on sample - used to calculate sample/beam interaction point - (NXsample_component): - doc: | - One group per sample component - This is the perferred way of recording per component information over the n_comp arrays - component: - doc: | - Details of the component of the sample and/or can - dimensions: - rank: 1 - dim: [[1, n_comp]] - sample_component: - doc: | - Type of component - dimensions: - rank: 1 - dim: [[1, n_comp]] - enumeration: [sample, can, atmosphere, kit] - concentration(NX_FLOAT): - unit: NX_MASS_DENSITY - doc: | - Concentration of each component - dimensions: - rank: 1 - dim: [[1, n_comp]] - volume_fraction(NX_FLOAT): - doc: | - Volume fraction of each component - dimensions: - rank: 1 - dim: [[1, n_comp]] - scattering_length_density(NX_FLOAT): - unit: NX_SCATTERING_LENGTH_DENSITY - doc: | - Scattering length density of each component - dimensions: - rank: 1 - dim: [[1, n_comp]] - unit_cell_class: - doc: | - In case it is all we know and we want to record/document it - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - space_group: - doc: | - Crystallographic space group - dimensions: - dim: [[1, n_comp]] - point_group: - doc: | - Crystallographic point group, deprecated if space_group present - dimensions: - dim: [[1, n_comp]] - path_length(NX_FLOAT): - unit: NX_LENGTH - doc: | - Path length through sample/can for simple case when - it does not vary with scattering direction - path_length_window(NX_FLOAT): - unit: NX_LENGTH - doc: | - Thickness of a beam entry/exit window on the can (mm) - - assumed same for entry and exit - thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - sample thickness - transmission(NXdata): - doc: | - As a function of Wavelength - temperature_log(NXlog): - deprecated: | - use ``temperature``, see: https://github.com/nexusformat/definitions/issues/816 - doc: | - temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value - temperature_env(NXenvironment): - doc: | - Additional sample temperature environment information - magnetic_field(NXlog): - doc: | - magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value - magnetic_field_log(NXlog): - deprecated: | - use ``magnetic_field``, see: https://github.com/nexusformat/definitions/issues/816 - doc: | - magnetic_field_log.value is a link to e.g. magnetic_field_env.sensor1.value_log.value - magnetic_field_env(NXenvironment): - doc: | - Additional sample magnetic environment information - external_DAC(NX_FLOAT): - unit: NX_ANY - doc: | - value sent to user's sample setup - external_ADC(NXlog): - doc: | - logged value (or logic state) read from user's setup - short_title: - doc: | - 20 character fixed length sample description for legends - - # How is the string length limitation imposed by the XSD? - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Optional rotation angle for the case when the powder diagram has - been obtained through an omega-2theta scan like from a traditional - single detector powder diffractometer. - Note, it is recommended to use NXtransformations instead. - x_translation(NX_FLOAT): - unit: NX_LENGTH - doc: | - Translation of the sample along the X-direction of the laboratory coordinate system - Note, it is recommended to use NXtransformations instead. - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Translation of the sample along the Z-direction of the laboratory coordinate system. - Note, it is recommended to use NXtransformations instead. - (NXpositioner): - doc: | - Any positioner (motor, PZT, ...) used to locate the sample - (NXoff_geometry): - # exists: ['min', '0'] - doc: | - This group describes the shape of the sample - (NXsingle_crystal): - doc: | - If the sample is a single crystal, add description of single crystal and unit - cell. - (NXsample_component_set): - doc: | - Set of sample components and their configuration. - There can only be one NXsample_component_set in one component. - # exists: [max, 1] - (NXsubstance): - doc: | - If the sample is made from a pure substance and cannot be further divided using - NXsample_component. - # exists: [max, 1] - (NXfabrication): - doc: | - Details about the sample vendor (company or research group) - (NXenvironment): - # eventually, this should be stored in the application definitions - doc: | - Any environmental or external stimuli/measurements. - These can include, among others: - applied pressure, surrounding gas phase and gas pressure, - external electric/magnetic/mechanical fields, temperature, ... - (NXsample_history): - doc: | - A set of physical processes that occurred to the sample prior/during experiment. - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on: - doc: | - 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. - (NXtransformations): - doc: | - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. \ No newline at end of file diff --git a/base_classes/nyaml/NXsample_component.yaml b/base_classes/nyaml/NXsample_component.yaml deleted file mode 100644 index 0678f30a22..0000000000 --- a/base_classes/nyaml/NXsample_component.yaml +++ /dev/null @@ -1,144 +0,0 @@ -category: base -doc: | - One group like this per component can be recorded For a sample consisting of multiple components. -symbols: - doc: | - symbolic array lengths to be coordinated between various fields - n_Temp: | - number of temperatures - n_eField: | - number of values in applied electric field - n_mField: | - number of values in applied magnetic field - n_pField: | - number of values in applied pressure field - n_sField: | - number of values in applied stress field -type: group -NXsample_component(NXobject): - name: - doc: | - Descriptive name of sample component - sample_id: - doc: | - Identification number or signatures of the sample component used. - chemical_formula: - doc: | - 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. - unit_cell_abc(NX_FLOAT): - unit: NX_LENGTH - doc: | - Crystallography unit cell parameters a, b, and c - dimensions: - dim: [[1, 3]] - unit_cell_alphabetagamma(NX_FLOAT): - unit: NX_ANGLE - doc: | - Crystallography unit cell parameters alpha, beta, and gamma - dimensions: - dim: [[1, 3]] - unit_cell_volume(NX_FLOAT): - unit: NX_VOLUME - doc: | - Volume of the unit cell - sample_orientation(NX_FLOAT): - unit: NX_ANGLE - doc: | - This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) - dimensions: - rank: 1 - dim: [[1, 3]] - orientation_matrix(NX_FLOAT): - doc: | - Orientation matrix of single crystal sample component. - This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) - dimensions: - rank: 2 - dim: [[1, 3], [2, 3]] - mass(NX_FLOAT): - unit: NX_MASS - doc: | - Mass of sample component - density(NX_FLOAT): - unit: NX_MASS_DENSITY - doc: | - Density of sample component - relative_molecular_mass(NX_FLOAT): - unit: NX_MASS - doc: | - Relative Molecular Mass of sample component - description: - doc: | - Description of the sample component - volume_fraction(NX_FLOAT): - doc: | - Volume fraction of component - scattering_length_density(NX_FLOAT): - unit: NX_SCATTERING_LENGTH_DENSITY - doc: | - Scattering length density of component - unit_cell_class: - doc: | - In case it is all we know and we want to record/document it - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - space_group: - doc: | - Crystallographic space group - point_group: - doc: | - Crystallographic point group, deprecated if space_group present - transmission(NXdata): - doc: | - As a function of Wavelength - (NXsingle_crystal): - doc: | - If the component is a single crystal, add description of single crystal and unit - cell. - (NXsample_component_set): - doc: | - Set of sub-components and their configuration. - There can only be one NXsample_component_set in one component. - # exists: [max, 1] - (NXsubstance): - doc: | - If the component is made from a pure substance and cannot be further divided - using NXsample_component. - # exists: [max, 1] - (NXfabrication): - doc: | - Details about the sample component vendor (company or research group) - (NXsample_history): - doc: | - A set of physical processes that occurred to the sample component prior/during experiment. - depends_on: - doc: | - Any NXsample_component depends on the instance of NXsample_component_set, at the same level of - description granularity where the component is located. - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXactivity.yaml b/contributed_definitions/nyaml/NXactivity.yaml deleted file mode 100644 index 28ef84085d..0000000000 --- a/contributed_definitions/nyaml/NXactivity.yaml +++ /dev/null @@ -1,23 +0,0 @@ -category: base -doc: | - A planned or unplanned action that has a temporal extension and for some time depends on some entity. - - This class is planned be used in the future as the super class for all other activities if inheritance - in base classes is supported in NeXus. -type: group -NXactivity(NXobject): - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code (with local time zone offset to UTC information included) when this activity started. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code (with local time zone offset to UTC information included) when this activity ended. - description: - doc: | - Short description of the activity. - notes(NXnote): - doc: | - This can be any data or other descriptor acquired during the activity - (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXchemical_process.yaml b/contributed_definitions/nyaml/NXchemical_process.yaml deleted file mode 100644 index ff5379761a..0000000000 --- a/contributed_definitions/nyaml/NXchemical_process.yaml +++ /dev/null @@ -1,25 +0,0 @@ -category: base -doc: | - A planned or unplanned process which results in chemical changes (i.e., changes in the chemical bonds) in a specified material. - - Examples include any chemical reactions (addition, subtraction, replacement, ...). -type: group -NXchemical_process(NXobject): - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code (with local time zone offset to UTC information included) when this process started. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code (with local time zone offset to UTC information included) when this process ended. - description: - doc: | - Short description of the chemical process. - method: - doc: | - Method by which this process was performed. - notes(NXnote): - doc: | - This can be any data or other descriptor acquired during the chemical process - (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. diff --git a/contributed_definitions/nyaml/NXphysical_process.yaml b/contributed_definitions/nyaml/NXphysical_process.yaml deleted file mode 100644 index 7df1aff164..0000000000 --- a/contributed_definitions/nyaml/NXphysical_process.yaml +++ /dev/null @@ -1,26 +0,0 @@ -category: base -doc: | - A planned or unplanned process which results in physical changes in a specified material. - - A physical change involve changes only in intermolecular forces, not in the chemical bonds. - Examples include sample preparation, material transformation, or (partially) destructive measurements. -type: group -NXphysical_process(NXobject): - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code (with local time zone offset to UTC information included) when this process started. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code (with local time zone offset to UTC information included) when this process ended. - description: - doc: | - Short description of the activity. - method: - doc: | - Method by which this process was performed. - notes(NXnote): - doc: | - This can be any data or other descriptor acquired during the physical process - (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXrotation_set.yaml b/contributed_definitions/nyaml/NXrotation_set.yaml deleted file mode 100644 index b8bf514473..0000000000 --- a/contributed_definitions/nyaml/NXrotation_set.yaml +++ /dev/null @@ -1,176 +0,0 @@ -category: base -doc: | - Base class to detail a set of rotations, orientations, and disorientations. - - For getting a more detailed insight into the discussion of the - parameterized description of orientations in materials science see: - - * `H.-J. Bunge `_ - * `T. B. Britton et al. `_ - * `D. Rowenhorst et al. `_ - * `A. Morawiec `_ - - Once orientations are defined one can continue to characterize the - misorientation and specifically the disorientation which describes the - rotation that is required to register the lattices of two oriented objects - (like crystal lattice) into a crystallographic equivalent orientation: - - * `R. Bonnet `_ - - Based on the idea of this NXorientation_set one could equally formulate - an NXdisorientation_set. - -# This class stores a set of specifically parameterized NXtransformations which describe -# how each object is oriented/rotated with respect to a reference coordinate system. -# we should offer here support for d==2, d==3 -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - c: | - The cardinality of the set, i.e. the number of value tuples. -type: group -NXrotation_set(NXobject): - depends_on: - doc: | - Reference to an instance of NXem_conventions which contextualizes - how the here reported parameterized quantities can be interpreted. - # 2D rotations are a special type of 3D rotations and thus treated in 3D - # just how to rotate the object into the reference frame defined by depends_on - crystal_symmetry: - doc: | - Point group which defines the symmetry of the crystal. - This has to be at least a single string. - In the case that misorientation or disorientation fields are used - and the two crystal sets resolve for phases with a different - crystal symmetry, this field has to encode two string. - In this case the first string is for phase A the second one for phase B. - An example of this most complex case is the description of the - disorientation between crystals adjoining a hetero-phase boundary. - # how to encode the above (2,) string array or single string constraint - sample_symmetry: - doc: | - Point group which defines an assumed symmetry imprinted upon processing - the material/sample which could give rise to or may justify to use a - simplified description of rotations, orientations, misorientations, - and disorientations via numerical procedures known as symmetrization. - - The traditionally used symmetrization operations within the texture - community in Materials Science, though, are thanks to methodology and - software improvements no longer strictly needed. Therefore, users are - encouraged to set the sample_symmetry to 1 (triclinic) and thus assume - there is no implied additional processing symmetry imprinted. - - In practice one often faces situations where indeed these assumed - symmetries are anyway not fully observed and thus an accepting of - eventual inaccuracies just for the sake of reporting a simplified - symmetrized description can be avoided. - rotation_quaternion(NX_FLOAT): # H \in SO3 - unit: NX_DIMENSIONLESS - doc: | - The set of rotations expressed in quaternion representation. The assumed - crystal and sample symmetry point group is 1, triclinic. Rotations which - should be interpreted as antipodal are not marked as such. - dim: (c, 4) - rotation_euler(NX_FLOAT): - unit: NX_ANGLE - doc: | - The set of rotations expressed in Euler angle representation following - the same applied symmetries as explained for rotation_quaternion. - To interpret Euler angles correctly it is necessary to inspect the - conventions behind depends_on to resolve which of the many Euler-angle - conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. - dim: (c, 3) - # rotation_rodrigues(NX_FLOAT): - # rotation_homochoric(NX_FLOAT): - # rotation_axis_angle(NX_FLOAT): - - # orientation how to rotate the crystal into sample and vice versa obeying crystal and sample symmetry - is_antipodal(NX_BOOLEAN): - doc: | - True for all those values which are considered antipodal, - false for those which are not considered antipodal. - dim: (c,) - orientation_quaternion(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - The set of orientations expressed in quaternion representation and - obeying symmetry for equivalent cases as detailed in crystal_symmetry - and sample_symmetry. The supplementary field is_antipodal can be used - to mark orientations which are antipodal. - dim: (c, 4) - orientation_euler(NX_FLOAT): - unit: NX_ANGLE - doc: | - The set of orientations expressed in Euler angle representation following - the same assumptions like for orientation_quaternion. - To interpret Euler angles correctly it is necessary to inspect the - conventions behind depends_on to resolve which of the many Euler-angle - conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. - dim: (c, 3) - orientation_busing_levy(NX_FLOAT): - unit: NX_ANGLE - doc: | - This will follow the Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - dim: (3, 3) - ub_matrix_busing_levy(NX_FLOAT): - doc: | - UB matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is - the multiplication of the orientation_matrix, given above, - with the :math:`B` matrix which - can be derived from the lattice constants. - dim: (3, 3) - # orientation_rodrigues(NX_FLOAT): - # orientation_homochoric(NX_FLOAT): - # orientation_axis_angle(NX_FLOAT): - - # misorientation between two orientations, ignoring if the angular argument - # is smallest. - misorientation_quaternion(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - The set of misorientations expressed in quaternion representation and - obeying symmetry operations for equivalent misorientations - as defined by crystal_symmetry and sample_symmetry. - dim: (c, 4) - misorientation_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Misorientation angular argument (eventually signed) following the same - symmetry assumptions as expressed for the field misorientation_quaternion. - dim: (c,) - misorientation_axis(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Misorientation axis (normalized) and signed following the same - symmetry assumptions as expressed for the field misorientation_angle. - dim: (c, 3) - - # disorientation, misorientation with smallest angular argument inside - # fundamental zone of SO3 for given crystal and sample symmetry - disorientation_quaternion(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - The set of disorientation expressed in quaternion representation and - obeying symmetry operations for equivalent misorientations - as defined by crystal_symmetry and sample_symmetry. - disorientation_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Disorientation angular argument (should not be signed, see - `D. Rowenhorst et al. `_) - following the same symmetry assumptions as expressed for the field - disorientation_quaternion. - dim: (c,) - disorientation_axis(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Disorientation axis (normalized) following the same symmetry assumptions - as expressed for the field disorientation_quaternion. - dim: (c, 3) - # e.g. in this way one could easily, efficiently, store and map familiar habits of microscopists - # to store e.g. orientations of measurement points or of grains via a (c := Ngrains, n_p := 3) - # matrix of Bunge-Euler angles, or of (c := Ngrains, n_p := 4) matrix of quaternions. - - # the benefit of such a representation is that with a known NXorientation_set base class one can implement a common parameterization transformation library (of which several already exist) in the microstructure modelling communities so that a program can read the information in the (NXorientation_set) instance and automatically transform/compute between different parameterizations. Super relevant for interoperability e.g. in SEM/EBSD, where this was a long standing issue and right now the most frequently accepted consensus is to report either Bunge-Euler angles or quaternions and then use existent transformation libraries (as implemented by e.g. Marc de Graeff for SEM/EBSD and used by many but not yet the majority of people in the computational materials modelling community within crystal plasticity, crystal growth modeling, DREAM.3D) \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXsample_component_set.yaml b/contributed_definitions/nyaml/NXsample_component_set.yaml deleted file mode 100644 index a9d657c52b..0000000000 --- a/contributed_definitions/nyaml/NXsample_component_set.yaml +++ /dev/null @@ -1,42 +0,0 @@ -category: base -doc: | - Set of sample components and their configuration. - - The idea here is to have a united place for all materials descriptors that are not - part of the individual sample components, but rather their configuration. -symbols: - n_comp: | - number of components -type: group -NXsample_component_set(NXobject): - \@components: - doc: | - Array of strings referring to the names of the NXsample_components. - The order of these components serves as an index (starting at 1). - concentration(NX_FLOAT): - unit: NX_ANY - doc: | - Concentration of each component - dimensions: - rank: 1 - dim: [[1, n_comp]] - volume_fraction(NX_FLOAT): - unit: NX_ANY - doc: | - Volume fraction of each component - dimensions: - rank: 1 - dim: [[1, n_comp]] - scattering_length_density(NX_FLOAT): - unit: NX_ANY - doc: | - Scattering length density of each component - dimensions: - rank: 1 - dim: [[1, n_comp]] - (NXsample_component): - doc: | - Each component set can contain multiple components. - (NXsample_component_set): - doc: - For description of a sub-component set. Can contain multiple components itself. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXsample_history.yaml b/contributed_definitions/nyaml/NXsample_history.yaml deleted file mode 100644 index fa45cd6651..0000000000 --- a/contributed_definitions/nyaml/NXsample_history.yaml +++ /dev/null @@ -1,34 +0,0 @@ -category: base -doc: | - A set of activities that occurred to the sample prior/during experiment. - - Ideally, a full report of the previous operations (or links to a chain of operations). - Alternatively, notes allow for additional descriptors in any format. -type: group -NXsample_history(NXobject): - (NXactivity): - doc: - Any activity that was performed on the sample prior or during the experiment. - In the future, if there is base class inheritance, this can describe any activity, - including processes and measurements. - # For now, one workaround would be to have NXactivity as a application definition with a subentry. - # subentry(NXsuxbentry): - # doc: | - # Any activity that was performed on the sample prior or during the experiment. - # definition: ["NXactivity"] - (NXphysical_process): - doc: | - Any physical process that was performed on the sample prior or during the experiment. - (NXchemical_process): - doc: | - Any chemical process that was performed on the sample prior or during the experiment. - # There should be more activities here, like measurement. - notes(NXnote): - doc: | - A descriptor to keep track of the treatment of the sample before or during the - experiment (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - This should only be used in case that there is no rigorous description - using the base classes above. This field can also be used to pull in any activities - that are not well described by an existing base class definition. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXsingle_crystal.yaml b/contributed_definitions/nyaml/NXsingle_crystal.yaml deleted file mode 100644 index afe75c0733..0000000000 --- a/contributed_definitions/nyaml/NXsingle_crystal.yaml +++ /dev/null @@ -1,31 +0,0 @@ -category: base -doc: | - Description of a single crystal material or a single crystalline phase in a material. - - There is the option of using Busing-Levy convention (as orginally designed in NXsample) - or using a more detailed description with NXrotation_set. -type: group -NXsingle_crystal(NXobject): - sample_orientation(NX_FLOAT): - unit: NX_ANGLE - doc: | - This will follow the Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - dim: (3,) - orientation_matrix(NX_FLOAT): - doc: | - Orientation matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - dim: (3, 3) - ub_matrix(NX_FLOAT): - doc: | - UB matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is - the multiplication of the orientation_matrix, given above, - with the :math:`B` matrix which can be derived from the lattice constants. - dim: (3, 3) - rotation_set(NXrotation_set): - doc: | - Detailed description of single crystal orientation and misorientation. - (NXunit_cell): - doc: Unit cell of the single crystal. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXsubstance.yaml b/contributed_definitions/nyaml/NXsubstance.yaml deleted file mode 100644 index 846f833435..0000000000 --- a/contributed_definitions/nyaml/NXsubstance.yaml +++ /dev/null @@ -1,67 +0,0 @@ -category: base -doc: | - A form of matter with a constant, definite chemical composition. - - Examples can be single chemical elements, chemical compunds, or alloys. - For further information, see https://en.wikipedia.org/wiki/Chemical_substance. -type: group -NXsubstance(NXobject): - name: - doc: User-defined chemical name of the substance - molecular_mass(NX_FLOAT): - unit: NX_MOLECULAR_WEIGHT - doc: | - Molecular mass of the substance - cas_number: - doc: | - Unique numeric CAS REGISTRY number of the sample chemical content - For further information, see https://www.cas.org/. - cas_name: - doc: CAS REGISTRY name of the sample chemical content - cas_uri: - doc: | - CAS REGISTRY URI - cas_image(NXnote): - doc: CAS REGISTRY image - cas_synonyms: - doc: Synonyms in the CAS system. - inchi_str: - doc: | - String InChi identifier. - The InChI identifier expresses chemical structures in terms of atomic connectivity, - tautomeric state, isotopes, stereochemistry and electronic charge in order to - produce a string of machine-readable characters unique to the respective molecule. - For further information, see https://iupac.org/who-we-are/divisions/division-details/inchi/. - inchi_key: - doc: | - Condensed, 27 character InChI key. - Hashed version of the full InChI (using the SHA-256 algorithm). - iupac_name: - doc: | - Name according to the IUPAC system (standard). - For further information, see https://iupac.org/. - smile: - doc: | - Identifier in the SMILES (Simplified Molecular Input Line Entry System) system - For further information, see https://www.daylight.com/smiles/. - canonical_smile: - doc: | - Canonical version of the smiles identifier - molecular_formula_hill: - doc: | - The chemical formula specified using CIF conventions. - Abbreviated version of CIF standard:107 - This is the *Hill* system used by Chemical Abstracts. - - * Only recognized element symbols may be used. - * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. - * A space or parenthesis must separate each cluster of (element symbol + count). - * Where a group of elements is enclosed in parentheses, the multiplier for the - group must follow the closing parentheses. That is, all element and group - multipliers are assumed to be printed as subscripted numbers. - * Unless the elements are ordered in a manner that corresponds to their chemical - structure, the order of the elements within any group or moiety depends on - whether or not carbon is present. - * If carbon is present, the order should be: - - C, then H, then the other elements in alphabetical order of their symbol. - - If carbon is not present, the elements are listed purely in alphabetic order of their symbol. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXunit_cell.yaml b/contributed_definitions/nyaml/NXunit_cell.yaml deleted file mode 100644 index aa372af96f..0000000000 --- a/contributed_definitions/nyaml/NXunit_cell.yaml +++ /dev/null @@ -1,130 +0,0 @@ -category: base -doc: | - Description of a unit cell, i.e., the crystal structure of a single thermodynamic phase. -symbols: - n_pos: | - Number of atom positions. -type: group -NXunit_cell(NXobject): - crystallographic_database_identifier: - doc: | - Identifier of an entry resolvable via crystallographic_database - which was used for creating this structure model. - crystallographic_database: - doc: | - Name of the crystallographic database to resolve - crystallographic_database_identifier e.g. COD, ICSD, or others. - lattice_system: - doc: | - A lattice system is a group of lattices with the same set of lattice point groups. - For further information, see https://en.wikipedia.org/wiki/Crystal_system. - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - space_group: - doc: | - Crystallographic space group. - A space group is the symmetry group of a repeating pattern in space. - For further information, see International Table for Crystallography (https://it.iucr.org/). - point_group: - doc: | - Crystallographic point group. - A crystallographic point group is a set of symmetry operations, corresponding to one of the point groups in three dimensions, - such that each operation (perhaps followed by a translation) would leave the structure of a crystal unchanged. - This field should use Schoenflies notation (see Schoenflies, A., Krystallsysteme und Krystallstructur, 1891). - For further information, see https://dictionary.iucr.org/Point_group. - laue_group: - doc: | - Laue group (also called Laue class). - The Laue classes are eleven geometric crystal classes containing centrosymmetric crystallographic types of point groups and their subgroups. - When absorption is negligible and Friedel's law applies, it is impossible to distinguish by diffraction between a centrosymmetric point group - and one of its non-centrosymmetric subgroups; only point groups belonging to different Laue classes can then be distinguished. - For further information, see https://dictionary.iucr.org/Laue_class. - # defined using which convention? - a_b_c(NX_FLOAT): - unit: NX_LENGTH - doc: | - Crystallography unit cell parameters a, b, and c - dim: (3,) - base_vector_a(NX_FLOAT): - doc: | - Crystallography unit cell vector a - unit: NX_LENGTH - dim: (3,) - \@depends_on: - doc: | - For definining which coordinate system the unit cell vector a is defined in. - base_vector_b(NX_FLOAT): - doc: | - Crystallography unit cell vector b - unit: NX_LENGTH - dim: (3,) - \@depends_on: - doc: | - For definining which coordinate system the unit cell vector b is defined in. - base_vector_c(NX_FLOAT): - doc: | - Crystallography unit cell vector c - unit: NX_LENGTH - dim: (3,) - \@depends_on: - doc: | - For definining which coordinate system the unit cell vector c is defined in. - alpha_beta_gamma(NX_FLOAT): - unit: NX_ANGLE - doc: | - Crystallography unit cell angles alpha, beta, and gamma - dim: (3,) - volume(NX_FLOAT): - unit: NX_VOLUME - doc: | - Volume of the unit cell - # add enumeration of all possible - is_centrosymmetric(NX_BOOLEAN): - doc: | - True if space group is considered a centrosymmetric one. - False if space group is considered a non-centrosymmetric one. - Centrosymmetric has all types and combinations of symmetry elements - (translation, rotational axis, mirror planes, center of inversion) - Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). - Chiral compared to non-centrosymmetric is constrained (no mirror planes). - is_chiral(NX_BOOLEAN): - doc: | - True if space group is considered a chiral one. - False if space group is consider a non-chiral one. - phase_identifier(NX_UINT): - unit: NX_UNITLESS - doc: | - Identifier for the phase. - The value 0 is reserved for the unknown phase which represents the null-model - that no phase model was sufficiently significantly confirmed. - phase_name: - doc: | - Trivial name of the phase/alias. - atom_identifier: - doc: | - Labels for each atom position - dim: (n_pos,) - atom(NX_UINT): - unit: NX_UNITLESS - doc: | - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) `_ - dim: (n_pos,) - atom_positions(NX_FLOAT): - unit: NX_LENGTH - doc: | - Atom positions x, y, z. - dim: (n_pos, 3) - \@depends_on: - doc: | - Reference to an instance of NXcoordinate_system whereby the positions can be resolved. - atom_occupancy(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Relative occupancy of the atom position. - dim: (n_pos,) - depends_on: - doc: | - For definining which coordinate system the unit cell parameters are defined in. - \ No newline at end of file From 50fbb1ac3204f111a33ddade77768a1256f015c7 Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Thu, 31 Aug 2023 14:57:53 +0200 Subject: [PATCH 0240/1012] black reformatting --- dev_tools/docs/nxdl.py | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/dev_tools/docs/nxdl.py b/dev_tools/docs/nxdl.py index 9d23f6ea88..c2dda67988 100755 --- a/dev_tools/docs/nxdl.py +++ b/dev_tools/docs/nxdl.py @@ -528,8 +528,9 @@ def long_doc(self, ns, node, left_margin): line = "documentation" fnd = False blocks = self._get_doc_blocks(ns, node) - max_characters = max(MIN_COLLAPSE_HINT_LINE_LENGTH, - (MAX_COLLAPSE_HINT_LINE_LENGTH - left_margin)) + max_characters = max( + MIN_COLLAPSE_HINT_LINE_LENGTH, (MAX_COLLAPSE_HINT_LINE_LENGTH - left_margin) + ) for block in blocks: lines = block.splitlines() length += len(lines) From a093625f7a70f3b70c87900e0aaf243899da7ce5 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 31 Aug 2023 16:20:34 +0200 Subject: [PATCH 0241/1012] Revert changes to NXsample Since we have substantial changes on the NXsample base class now, here we remove any changes to NXsample in this PR. --- base_classes/NXsample.nxdl.xml | 159 ++++++++++----------------------- 1 file changed, 47 insertions(+), 112 deletions(-) mode change 100755 => 100644 base_classes/NXsample.nxdl.xml diff --git a/base_classes/NXsample.nxdl.xml b/base_classes/NXsample.nxdl.xml old mode 100755 new mode 100644 index d2afd196c9..3ac357d261 --- a/base_classes/NXsample.nxdl.xml +++ b/base_classes/NXsample.nxdl.xml @@ -69,6 +69,11 @@ Descriptive name of sample + + + Identification number or signatures of the sample used. + + The chemical formula specified using CIF conventions. @@ -403,116 +408,6 @@ sample thickness - - - Identification number or signatures of the sample used. - - - - - 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 - - - - - Physical state of the sample - - - - - Chemical purity of the sample - - - - - Surface termination of the sample (if crystalline) - - - - - Number of layers of the sample (e.g. bulk, monolayer, pentalayer, etc.) - - - - - Full chemical name of the sample - - - - - CAS registry number of the sample chemical content. - - - - - Gases might be fluxed on the surface for various reasons. Chemical designation, - or residual. - - - - - In the case of a fixed pressure measurement this is the scalar pressure. In the - case of an experiment in which pressure changes, or anyway is recorded, this is - an array of length m of pressures. - - - - - Element of evaporated surface dopant such as alkali or other - - - - - Nominal thickness of the evaporated dopant - - - - - Voltage applied to sample and sample holder. - - - - - Sample growth method (e. g. molecular beam epitaxy, chemical vapor deposition - etc.) - - - - - Name of the sample vendor (company or research group) - - - - - Material of the substrate in direct contact with the sample. - - - - - Physical state of the substrate, similar options to sample_state - - - - - Current to neutralize the photoemission current. This field may also be found in - NXmanpulator if present. - - - - - Possible bias of the sample with respect to analyser ground. This field may also - be found as sample_bias in NXmanipulator if present. - - - - - Further notes. - - As a function of Wavelength @@ -585,11 +480,51 @@ Any positioner (motor, PZT, ...) used to locate the sample - + + This group describes the shape of the sample + + + If the sample is a single crystal, add description of single crystal and unit + cell. + + + + + Set of sample components and their configuration. + There can only be one NXsample_component_set in one component. + + + + + + If the sample is made from a pure substance and cannot be further divided using + NXsample_component. + + + + + + Details about the sample vendor (company or research group) + + + + + + Any environmental or external stimuli/measurements. + These can include, among others: + applied pressure, surrounding gas phase and gas pressure, + external electric/magnetic/mechanical fields, temperature, ... + + + + + A set of physical processes that occurred to the sample prior/during experiment. + + .. index:: plotting @@ -603,7 +538,7 @@ for a summary of the discussion. - + NeXus positions components by applying a set of translations and rotations to apply to the component starting from 0, 0, 0. The order of these operations From 03085665f3d81ffcc473f26e275e722d7eb0cbee Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 31 Aug 2023 16:35:08 +0200 Subject: [PATCH 0242/1012] Typo fix --- base_classes/NXaperture.nxdl.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/base_classes/NXaperture.nxdl.xml b/base_classes/NXaperture.nxdl.xml index 23c325e191..0fe4ec6d76 100644 --- a/base_classes/NXaperture.nxdl.xml +++ b/base_classes/NXaperture.nxdl.xml @@ -38,7 +38,7 @@ The reference point of the aperture is its center in the x and y axis. The reference point on the z axis is the surface of the aperture pointing towards the source. - In complex (asymmetic) geometries an NXoff_geometry group can be used to provide an unambiguous reference. + In complex (asymmetric) geometries an NXoff_geometry group can be used to provide an unambiguous reference. .. image:: aperture/aperture.png :width: 40% From e17ea1b0a924d3b4ceb0d72969040798d50ebf37 Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Mon, 4 Sep 2023 12:28:12 +0200 Subject: [PATCH 0243/1012] Fixed issues with units category in NXsts --- contributed_definitions/NXsts.nxdl.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/NXsts.nxdl.xml b/contributed_definitions/NXsts.nxdl.xml index d6ccdca594..01f14143b6 100644 --- a/contributed_definitions/NXsts.nxdl.xml +++ b/contributed_definitions/NXsts.nxdl.xml @@ -761,14 +761,14 @@ disabled when Z-Controller to Hold is deselected in the Advanced section.--> - + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/max_slew_rate - + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/backward_sweep From ec6d09beacc5798d46b3f382aae23ef450d325f7 Mon Sep 17 00:00:00 2001 From: "markus.kuehbach" Date: Tue, 5 Sep 2023 09:39:41 +0200 Subject: [PATCH 0244/1012] added sample to NXiv_temp for consistency with other fairmat appdefs --- contributed_definitions/NXiv_temp.nxdl.xml | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/contributed_definitions/NXiv_temp.nxdl.xml b/contributed_definitions/NXiv_temp.nxdl.xml index 7805ef4320..d61426c0c3 100644 --- a/contributed_definitions/NXiv_temp.nxdl.xml +++ b/contributed_definitions/NXiv_temp.nxdl.xml @@ -51,6 +51,25 @@ + + + + Descriptive name or ideally (globally) unique persistent identifier. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history or from other data sources. + + + From 860d74307fb21e9935a055e440b8adbbe79c5e36 Mon Sep 17 00:00:00 2001 From: domna Date: Tue, 5 Sep 2023 15:05:15 +0200 Subject: [PATCH 0245/1012] Adds bias to NXmpes --- contributed_definitions/NXmpes.nxdl.xml | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index f29e7337f0..4f3083d251 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -2,9 +2,9 @@ Scheme of the electron collection column. @@ -135,13 +148,14 @@ + - + @@ -206,6 +220,10 @@ + @@ -228,7 +246,7 @@ - + Document an event of data processing, reconstruction, or analysis for this data. Describe the appropriate axis calibrations for your experiment using one or more From 16a97170a7b4ce468371b492882287bf57e4b5f4 Mon Sep 17 00:00:00 2001 From: rettigl Date: Tue, 12 Sep 2023 12:06:55 +0200 Subject: [PATCH 0249/1012] move internal analyzer transformations to named analyzer transformations --- contributed_definitions/NXmpes_arpes.nxdl.xml | 39 +++++++------------ .../nyaml/NXmpes_arpes.yaml | 16 +++----- 2 files changed, 19 insertions(+), 36 deletions(-) diff --git a/contributed_definitions/NXmpes_arpes.nxdl.xml b/contributed_definitions/NXmpes_arpes.nxdl.xml index 80e8a949c4..be4fc6a5ac 100644 --- a/contributed_definitions/NXmpes_arpes.nxdl.xml +++ b/contributed_definitions/NXmpes_arpes.nxdl.xml @@ -84,6 +84,19 @@ with higher granularity in the data description.--> chain. + + + Elevation of the effective analyzer acceptance area, e.g. realized by + deflectors, or as one angle in a TOF detector. If a resolved angle, place the + calibrated axis coordinates here. + + + + + In-plane analyzer coordinate along a dispersive direction, e.g. along an + analyzer slit. If a resolved angle, place the calibrated coordinates here. + + @@ -154,19 +167,6 @@ with higher granularity in the data description.--> This is the calibrated angular axis to be used for data plotting. - - - Reference to the transformation describing the orientation of the first - dispersed analyzer angle. - - - - - Set of transformations, describing the relation of the dispersing analyzer - angles and analyzer roations with respect to the reference coordinate system - (.). - - @@ -179,19 +179,6 @@ with higher granularity in the data description.--> This is the calibrated angular axis to be used for data plotting. - - - Reference to the transformation describing the orientation of the second - dispersed analyzer angle. - - - - - Set of transformations, describing the relation of the dispersing analyzer - angles and analyzer roations with respect to the reference coordinate system - (.). - - diff --git a/contributed_definitions/nyaml/NXmpes_arpes.yaml b/contributed_definitions/nyaml/NXmpes_arpes.yaml index 9fe34924ad..0f06b7697b 100644 --- a/contributed_definitions/nyaml/NXmpes_arpes.yaml +++ b/contributed_definitions/nyaml/NXmpes_arpes.yaml @@ -37,6 +37,12 @@ NXmpes_arpes(NXmpes): analyzer_rotation(NX_NUMBER): doc: "Rotation about the analyzer axis. This needs to be defined in the transformation chain." unit: NX_ANGLE + analyzer_elevation(NX_NUMBER): + doc: "Elevation of the effective analyzer acceptance area, e.g. realized by deflectors, or as one angle in a TOF detector. If a resolved angle, place the calibrated axis coordinates here." + unit: NX_ANGLE + analyzer_dispersion(NX_NUMBER): + doc: "In-plane analyzer coordinate along a dispersive direction, e.g. along an analyzer slit. If a resolved angle, place the calibrated coordinates here." + unit: NX_ANGLE (NXcollectioncolumn): scheme: exists: recommended @@ -87,11 +93,6 @@ NXmpes_arpes(NXmpes): calibrated_axis(NX_FLOAT): exists: recommended doc: "This is the calibrated angular axis to be used for data plotting." - depends_on(NX_CHAR): - doc: "Reference to the transformation describing the orientation of the first dispersed analyzer angle." - (NXtransformations): - exists: recommended - doc: "Set of transformations, describing the relation of the dispersing analyzer angles and analyzer roations with respect to the reference coordinate system (.)." angular2_calibration(NXcalibration): exists: optional applied(NX_BOOLEAN): @@ -99,11 +100,6 @@ NXmpes_arpes(NXmpes): calibrated_axis(NX_FLOAT): exists: recommended doc: "This is the calibrated angular axis to be used for data plotting." - depends_on(NX_CHAR): - doc: "Reference to the transformation describing the orientation of the second dispersed analyzer angle." - (NXtransformations): - exists: recommended - doc: "Set of transformations, describing the relation of the dispersing analyzer angles and analyzer roations with respect to the reference coordinate system (.)." (NXsample): situation: enumeration: ["vacuum"] From 883aa7a475e877c2a850410f1d4b104acfdabb8f Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 13 Sep 2023 10:50:15 +0200 Subject: [PATCH 0250/1012] Incorporates changes from may workshop (#32) --- contributed_definitions/NXmpes.nxdl.xml | 35 ++++++++++++++++++++----- 1 file changed, 29 insertions(+), 6 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index d0fb924cba..2cdc6a0d73 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -38,6 +38,14 @@ Datetime of the end of the measurement. + + + A name of the experimental method according + to the `ISO 18115-1:2023`_ specification. + + .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + + @@ -79,7 +87,11 @@ - + + 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 @@ -99,22 +111,28 @@ + - + + + Specification of type, may also go to name. + + + Type of probe. In photoemission it's always photons, so the full NIAC list is restricted. - - - + - + + + Distance of the point of evaluation of the beam from the sample surface. @@ -125,6 +143,11 @@ + + + + + From 39e0e26ce0f287dbcee52fafc62b3142805a3280 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 13 Sep 2023 18:08:05 +0200 Subject: [PATCH 0251/1012] Adds a reference to PaNET ontology --- contributed_definitions/nyaml/NXmpes.yaml | 263 ++++++++++++++++++++++ 1 file changed, 263 insertions(+) create mode 100644 contributed_definitions/nyaml/NXmpes.yaml diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml new file mode 100644 index 0000000000..8721626809 --- /dev/null +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -0,0 +1,263 @@ +doc: | + This is the most general application definition for multidimensional + photoelectron spectroscopy. +category: application +uri: http://purl.org/pan-science/PaNET/PaNET01269 +NXmpes: + (NXentry): + title: + start_time(NX_DATE_TIME): + doc: | + Datetime of the start of the measurement. + end_time(NX_DATE_TIME): + doc: | + Datetime of the end of the measurement. + method: + doc: | + A name of the experimental method according + to the `ISO 18115-1:2023`_ specification. + + .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + definition: + \@version: + enumeration: [NXmpes] + (NXuser): + exists: recommended + doc: | + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + name: + doc: | + Name 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: | + Full address (street, street number, ZIP, city, country) of the user's + affiliation. + email: + doc: | + Email address of the user. + orcid: + exists: recommended + doc: | + Author ID defined by https://orcid.org/. + (NXinstrument): + energy_resolution(NX_FLOAT): + exists: recommended + unit: NX_ENERGY + source_beam(NXsource): + doc: | + The source used to generate the primary photons. Properties refer strictly to + parameters of the source, not of the output beam. For example, the energy of the + source is not the optical power of the beam, but the energy of the electron beam + in a synchrotron and so on. + type: + enumeration: [Synchrotron X-ray Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, UV Plasma Source, Metal Jet X-ray, HHG laser, UV lamp, Monochromatized electron source, other] + type_other: + doc: | + Specification of type, may also go to name. + name: + exists: recommended + probe: + doc: | + Type of probe. In photoemission it's always photons, so the full NIAC list is + restricted. + enumeration: [photons] + beam_probe(NXbeam): + distance(NX_NUMBER): + exists: recommended + unit: NX_LENGTH + doc: | + Distance of the point of evaluation of the beam from the sample surface. + incident_energy(NX_FLOAT): + unit: NX_ENERGY + incident_energy_spread(NX_NUMBER): + exists: recommended + unit: NX_ENERGY + incident_polarization(NX_NUMBER): + exists: recommended + unit: NX_ANY + (NXelectronanalyser): + model(NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + description: + energy_resolution(NX_FLOAT): + exists: recommended + unit: NX_ENERGY + doc: | + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. + fast_axes(NX_CHAR): + exists: recommended + slow_axes: + exists: recommended + (NXcollectioncolumn): + scheme: + doc: | + Scheme of the electron collection column. + enumeration: [Standard, Angular dispersive, Spatial dispersive, Selective area, Deflector, PEEM, Momentum Microscope] + mode: + exists: recommended + projection: + exists: recommended + field_aperture(NXaperture): + doc: | + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + contrast_aperture(NXaperture): + doc: | + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + (NXenergydispersion): + scheme: + enumeration: [tof, hemispherical, double hemispherical, cylindrical mirror, display mirror, retarding grid] + pass_energy(NX_FLOAT): + unit: NX_ENERGY + energy_scan_mode: + entrance_slit(NXaperture): + doc: | + Size, position and shape of the entrance slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + exit_slit(NXaperture): + doc: | + Size, position and shape of the exit slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + (NXdetector): + amplifier_type: + exists: recommended + doc: | + Type of electron amplifier in the first amplification step. + enumeration: [MCP, channeltron] + detector_type: + exists: recommended + doc: | + Description of the detector type. + enumeration: [DLD, Phosphor+CCD, Phosphor+CMOS, ECMOS, Anode, Multi-anode] + (NXdata): + exists: recommended + \@signal: + enumeration: [raw] + raw(NX_NUMBER): + doc: | + Raw data before calibration. + (NXmanipulator): + doc: | + Manipulator for positioning of the sample. + sample_temperature(NX_FLOAT): + exists: recommended + unit: NX_TEMPERATURE + drain_current(NX_FLOAT): + exists: recommended + unit: NX_CURRENT + sample_bias(NX_FLOAT): + exists: recommended + unit: NX_CURRENT + (NXprocess): + exists: recommended + doc: | + 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 + energy_calibration(NXcalibration): + applied(NX_BOOLEAN): + doc: | + Has an energy calibration been applied? + calibrated_axis(NX_FLOAT): + exists: recommended + doc: | + This is the calibrated energy axis to be used for data plotting. + angular_calibration(NXcalibration): + applied(NX_BOOLEAN): + doc: | + Has an angular calibration been applied? + calibrated_axis(NX_FLOAT): + exists: recommended + doc: | + This is the calibrated angular axis to be used for data plotting. + spatial_calibration(NXcalibration): + applied(NX_BOOLEAN): + doc: | + Has an spatial calibration been applied? + calibrated_axis(NX_FLOAT): + exists: recommended + doc: | + This is the calibrated spatial axis to be used for data plotting. + momentum_calibration(NXcalibration): + applied(NX_BOOLEAN): + doc: | + Has an momentum calibration been applied? + calibrated_axis(NX_FLOAT): + exists: recommended + doc: | + This is the momentum axis to be used for data plotting. + (NXsample): + name: + chemical_formula: + exists: recommended + doc: | + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + sample_history(NXnote): + exists: recommended + doc: | + 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. + atom_types: + exists: recommended + doc: | + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + preparation_date(NX_DATE_TIME): + exists: recommended + doc: | + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). + preparation_description(NXnote): + doc: | + 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. + temperature(NX_FLOAT): + exists: recommended + unit: NX_TEMPERATURE + doc: | + 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. + situation: + enumeration: [vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere] + gas_pressure(NX_FLOAT): + unit: NX_PRESSURE + bias(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Voltage applied to sample and sample holder. + (NXdata): + \@signal: + enumeration: [data] + data(NX_NUMBER): + unit: NX_ANY + doc: | + 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. From 6301658949ad6c06a4aaff29644de3998a34034b Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 20 Sep 2023 17:58:52 +0200 Subject: [PATCH 0252/1012] Change NXsample in NXmpes using the new NXsample_history and NXsubstance --- base_classes/NXentry.nxdl.xml | 0 contributed_definitions/NXmpes.nxdl.xml | 203 ++++---- contributed_definitions/nyaml/NXmpes.yaml | 543 +++++++++++++++++++--- 3 files changed, 585 insertions(+), 161 deletions(-) mode change 100755 => 100644 base_classes/NXentry.nxdl.xml diff --git a/base_classes/NXentry.nxdl.xml b/base_classes/NXentry.nxdl.xml old mode 100755 new mode 100644 diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 2cdc6a0d73..23edbfabb2 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -2,9 +2,9 @@ + + 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 @@ -109,31 +92,23 @@ - - - - - - Specification of type, may also go to name. - - - + Type of probe. In photoemission it's always photons, so the full NIAC list is restricted. - + + + - - - - + + Distance of the point of evaluation of the beam from the sample surface. @@ -143,11 +118,6 @@ - - - - - @@ -158,12 +128,6 @@ - Scheme of the electron collection column. @@ -171,14 +135,13 @@ - - + @@ -243,10 +206,6 @@ - @@ -269,7 +228,7 @@ - + Document an event of data processing, reconstruction, or analysis for this data. Describe the appropriate axis calibrations for your experiment using one or more @@ -326,20 +285,16 @@ - - - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - - - + - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. + For samples containing a single pure substances. For mixtures use the + NXsample_component_set and NXsample_component group in NXsample instead. + + + The chemical formula of the sample. + + @@ -349,30 +304,7 @@ elements from each component must be included in `atom_types`. - - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - - - - - Description of the surface preparation technique for the XPS experiment, i.e. - UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report - of the previous operations, in any format(NXnote allows to add pictures, audio, - movies). Alternatively, a reference to the location or a unique identifier or - other metadata file. In the case these are not available, free-text description. - - - - - In the case of a fixed temperature measurement this is the scalar temperature of - the sample. In the case of an experiment in which the temperature is changed and - recoded, this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. - - - + @@ -380,11 +312,96 @@ - - + - Voltage applied to sample and sample holder. + A set of activities that occurred to the sample prior to/during photoemission experiment. + + Ideally, a full report of the previous operations (or links to a chain of operations). + Alternatively, notes allow for additional descriptors in any format + (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. + + + Details about the sample preparation for the MPES experiment (i.e. cleaving, last + annealing). + + + + + + Details about the method of sample preparation before the MPES experiment. + + + + + + + + Measured sample temperature. + + + + + + + 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 recorded, + this is an array of length m of temperatures. This should be a link to + /entry/instrument/manipulator/sample_temperature. + + + + + + + Gas pressure surrounding the sample. + + + + + + + In the case of a fixed gas pressure measurement, this is the scalar gas pressure around + the sample. + + + + + In the case of an experiment in which the gas pressure is changed and recorded, + this is an array of length m of gas pressures. This should be a link to + /entry/instrument/manipulator/sample_temperature. + + + + + + + Voltage applied to sample and sample holder. + + + + + + + In the case of a fixed applied bias, this is the scalar voltage applied to + sample and sample holder. + + + + + In the case of an experiment in which the bias is changed and recorded, + this is an array of length m of voltages. This should be a link to + /entry/instrument/manipulator/sample_temperature. + + + diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 8721626809..652e623c74 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -1,28 +1,18 @@ -doc: | +category: application +doc: | This is the most general application definition for multidimensional photoelectron spectroscopy. -category: application -uri: http://purl.org/pan-science/PaNET/PaNET01269 -NXmpes: +type: group +NXmpes(NXobject): (NXentry): title: start_time(NX_DATE_TIME): doc: | Datetime of the start of the measurement. - end_time(NX_DATE_TIME): - doc: | - Datetime of the end of the measurement. - method: - doc: | - A name of the experimental method according - to the `ISO 18115-1:2023`_ specification. - - .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html definition: \@version: enumeration: [NXmpes] (NXuser): - exists: recommended doc: | Contact information of at least the user of the instrument or the investigator who performed this experiment. Adding multiple users if relevant is recommended. @@ -48,29 +38,23 @@ NXmpes: Author ID defined by https://orcid.org/. (NXinstrument): energy_resolution(NX_FLOAT): - exists: recommended unit: NX_ENERGY - source_beam(NXsource): + (NXsource): doc: | The source used to generate the primary photons. Properties refer strictly to parameters of the source, not of the output beam. For example, the energy of the source is not the optical power of the beam, but the energy of the electron beam in a synchrotron and so on. type: - enumeration: [Synchrotron X-ray Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, UV Plasma Source, Metal Jet X-ray, HHG laser, UV lamp, Monochromatized electron source, other] - type_other: - doc: | - Specification of type, may also go to name. + enumeration: [Synchrotron X-ray Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, UV Plasma Source, Metal Jet X-ray, HHG laser] name: - exists: recommended probe: doc: | Type of probe. In photoemission it's always photons, so the full NIAC list is restricted. - enumeration: [photons] - beam_probe(NXbeam): + enumeration: [x-ray, ultraviolet, visible light] + (NXbeam): distance(NX_NUMBER): - exists: recommended unit: NX_LENGTH doc: | Distance of the point of evaluation of the beam from the sample surface. @@ -83,14 +67,6 @@ NXmpes: exists: recommended unit: NX_ANY (NXelectronanalyser): - model(NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended description: energy_resolution(NX_FLOAT): exists: recommended @@ -106,16 +82,18 @@ NXmpes: scheme: doc: | Scheme of the electron collection column. - enumeration: [Standard, Angular dispersive, Spatial dispersive, Selective area, Deflector, PEEM, Momentum Microscope] + enumeration: [Standard, Angular dispersive, Selective area, Deflector, PEEM, Momentum Microscope] mode: exists: recommended projection: exists: recommended field_aperture(NXaperture): + exists: optional doc: | The size and position of the field aperture inserted in the column. To add additional or other apertures use the APERTURE group of NXcollectioncolumn. contrast_aperture(NXaperture): + exists: optional doc: | The size and position of the contrast aperture inserted in the column. To add additional or other apertures use the APERTURE group of NXcollectioncolumn. @@ -126,10 +104,12 @@ NXmpes: unit: NX_ENERGY energy_scan_mode: entrance_slit(NXaperture): + exists: optional doc: | Size, position and shape of the entrance slit in dispersive analyzers. To add additional or other slits use the APERTURE group of NXenergydispersion. exit_slit(NXaperture): + exists: optional doc: | Size, position and shape of the exit slit in dispersive analyzers. To add additional or other slits use the APERTURE group of NXenergydispersion. @@ -152,6 +132,7 @@ NXmpes: doc: | Raw data before calibration. (NXmanipulator): + exists: optional doc: | Manipulator for positioning of the sample. sample_temperature(NX_FLOAT): @@ -164,12 +145,12 @@ NXmpes: exists: recommended unit: NX_CURRENT (NXprocess): - exists: recommended doc: | 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 energy_calibration(NXcalibration): + exists: optional applied(NX_BOOLEAN): doc: | Has an energy calibration been applied? @@ -178,6 +159,7 @@ NXmpes: doc: | This is the calibrated energy axis to be used for data plotting. angular_calibration(NXcalibration): + exists: optional applied(NX_BOOLEAN): doc: | Has an angular calibration been applied? @@ -186,6 +168,7 @@ NXmpes: doc: | This is the calibrated angular axis to be used for data plotting. spatial_calibration(NXcalibration): + exists: optional applied(NX_BOOLEAN): doc: | Has an spatial calibration been applied? @@ -194,6 +177,7 @@ NXmpes: doc: | This is the calibrated spatial axis to be used for data plotting. momentum_calibration(NXcalibration): + exists: optional applied(NX_BOOLEAN): doc: | Has an momentum calibration been applied? @@ -203,19 +187,14 @@ NXmpes: This is the momentum axis to be used for data plotting. (NXsample): name: - chemical_formula: - exists: recommended - doc: | - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - sample_history(NXnote): - exists: recommended - doc: | - 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. + (NXsubstance): + doc: + For samples containing a single pure substances. For mixtures use the NXsample_component_set + and NXsample_component group in NXsample instead. + molecular_formula_hill: + exists: recommended + doc: | + The chemical formula of the sample. atom_types: exists: recommended doc: | @@ -223,34 +202,94 @@ NXmpes: that are contained in the sample. If the sample substance has multiple components, all elements from each component must be included in `atom_types`. - preparation_date(NX_DATE_TIME): + situation: + enumeration: [vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere] + (NXsample_history): exists: recommended doc: | - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - preparation_description(NXnote): + A set of activities that occurred to the sample prior to/during photoemission experiment. + + Ideally, a full report of the previous operations (or links to a chain of operations). + Alternatively, notes allow for additional descriptors in any format + (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. + sample_preparation(NXphysical_process): + exists: recommended + doc: | + Details about the sample preparation for the MPES experiment (i.e. cleaving, last + annealing). + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + exists: recommended + method: + exists: optional + doc: | + Details about the method of sample preparation before the MPES experiment. + notes: + exists: optional + temperature(NXenvironment): doc: | - 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. - temperature(NX_FLOAT): - exists: recommended - unit: NX_TEMPERATURE + Measured sample temperature. + exists: recommended + thermocouple(NXsensor): + name: + type: + exists: recommended + value(NX_FLOAT): + exists: recommended + doc: | + In the case of a fixed temperature measurement, this is the scalar temperature of + the sample. + unit: NX_TEMPERATURE + value_log(NXlog): + exists: optional + doc: | + In the case of an experiment in which the temperature is changed and recorded, + this is an array of length m of temperatures. This should be a link to + /entry/instrument/manipulator/sample_temperature. + unit: NX_TEMPERATURE + gas_pressure(NXenvironment): doc: | - 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. - situation: - enumeration: [vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere] - gas_pressure(NX_FLOAT): - unit: NX_PRESSURE + Gas pressure surrounding the sample. + exists: recommended + pressure_gauge(NXsensor): + name: + type: + exists: recommended + value(NX_FLOAT): + exists: recommended + doc: | + In the case of a fixed gas pressure measurement, this is the scalar gas pressure around + the sample. + unit: NX_PRESSURE + value_log(NXlog): + exists: optional + doc: | + In the case of an experiment in which the gas pressure is changed and recorded, + this is an array of length m of gas pressures. This should be a link to + /entry/instrument/manipulator/sample_temperature. + unit: NX_PRESSURE bias(NX_FLOAT): - unit: NX_VOLTAGE doc: | Voltage applied to sample and sample holder. + exists: recommended + voltmeter(NXsensor): + name: + type: + exists: recommended + value(NX_FLOAT): + exists: recommended + doc: | + In the case of a fixed applied bias, this is the scalar voltage applied to sample and sample holder. + unit: NX_VOLTAGE + value_log(NXlog): + exists: optional + doc: | + In the case of an experiment in which the bias is changed and recorded, + this is an array of length m of voltages. This should be a link to + /entry/instrument/manipulator/sample_temperature. + unit: NX_VOLTAGE (NXdata): \@signal: enumeration: [data] @@ -261,3 +300,371 @@ NXmpes: 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e618cc098656aa72e4a5bd743c85c5d9c9caa79cbe85d96b6e06fafd1d165d1b +# +# +# +# +# +# This is the most general application definition for multidimensional +# photoelectron spectroscopy. +# +# +# +# +# +# Datetime of the start of the measurement. +# +# +# +# +# +# +# +# +# +# +# Contact information of at least the user of the instrument or the investigator +# who performed this experiment. Adding multiple users if relevant is recommended. +# +# +# +# Name of the user. +# +# +# +# +# Name of the affiliation of the user at the point in time when the experiment was +# performed. +# +# +# +# +# Full address (street, street number, ZIP, city, country) of the user's +# affiliation. +# +# +# +# +# Email address of the user. +# +# +# +# +# Author ID defined by https://orcid.org/. +# +# +# +# +# +# +# +# The source used to generate the primary photons. Properties refer strictly to +# parameters of the source, not of the output beam. For example, the energy of the +# source is not the optical power of the beam, but the energy of the electron beam +# in a synchrotron and so on. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Type of probe. In photoemission it's always photons, so the full NIAC list is +# restricted. +# +# +# +# +# +# +# +# +# +# +# +# Distance of the point of evaluation of the beam from the sample surface. +# +# +# +# +# +# +# +# +# +# +# Energy resolution of the analyser with the current setting. May be linked from a +# NXcalibration. +# +# +# +# +# +# +# +# Scheme of the electron collection column. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The size and position of the field aperture inserted in the column. To add +# additional or other apertures use the APERTURE group of NXcollectioncolumn. +# +# +# +# +# The size and position of the contrast aperture inserted in the column. To add +# additional or other apertures use the APERTURE group of NXcollectioncolumn. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Size, position and shape of the entrance slit in dispersive analyzers. To add +# additional or other slits use the APERTURE group of NXenergydispersion. +# +# +# +# +# Size, position and shape of the exit slit in dispersive analyzers. To add +# additional or other slits use the APERTURE group of NXenergydispersion. +# +# +# +# +# +# +# Type of electron amplifier in the first amplification step. +# +# +# +# +# +# +# +# +# Description of the detector type. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Raw data before calibration. +# +# +# +# +# +# +# +# Manipulator for positioning of the sample. +# +# +# +# +# +# +# +# +# Document an event of data processing, reconstruction, or analysis for this data. +# Describe the appropriate axis calibrations for your experiment using one or more +# of the following NXcalibrations +# +# +# +# +# Has an energy calibration been applied? +# +# +# +# +# This is the calibrated energy axis to be used for data plotting. +# +# +# +# +# +# +# Has an angular calibration been applied? +# +# +# +# +# This is the calibrated angular axis to be used for data plotting. +# +# +# +# +# +# +# Has an spatial calibration been applied? +# +# +# +# +# This is the calibrated spatial axis to be used for data plotting. +# +# +# +# +# +# +# Has an momentum calibration been applied? +# +# +# +# +# This is the momentum axis to be used for data plotting. +# +# +# +# +# +# +# +# +# The chemical formula of the sample. For mixtures use the NXsample_component +# group in NXsample instead. +# +# +# +# +# A descriptor to keep track of the treatment of the sample before entering the +# photoemission experiment. Ideally, a full report of the previous operations, in +# any format (NXnote allows to add pictures, audio, movies). Alternatively, a +# reference to the location or a unique identifier or other metadata file. In the +# case these are not available, free-text description. +# +# +# +# +# List of comma-separated elements from the periodic table +# that are contained in the sample. +# If the sample substance has multiple components, all +# elements from each component must be included in `atom_types`. +# +# +# +# +# Date of preparation of the sample for the XPS experiment (i.e. cleaving, last +# annealing). +# +# +# +# +# Description of the surface preparation technique for the XPS experiment, i.e. +# UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report +# of the previous operations, in any format(NXnote allows to add pictures, audio, +# movies). Alternatively, a reference to the location or a unique identifier or +# other metadata file. In the case these are not available, free-text description. +# +# +# +# +# In the case of a fixed temperature measurement this is the scalar temperature of +# the sample. In the case of an experiment in which the temperature is changed and +# recoded, this is an array of length m of temperatures. This should be a link to +# /entry/instrument/manipulator/sample_temperature. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Voltage applied to sample and sample holder. +# +# +# +# +# +# +# +# +# +# +# +# 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. +# +# +# +# +# From 99f73635f9938cf3b621d6439a1f73cbffab3eda Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 20 Sep 2023 18:04:01 +0200 Subject: [PATCH 0253/1012] Remove accidental changes to NXentry --- base_classes/NXentry.nxdl.xml | 496 ++++++++++++++-------------------- 1 file changed, 210 insertions(+), 286 deletions(-) mode change 100644 => 100755 base_classes/NXentry.nxdl.xml diff --git a/base_classes/NXentry.nxdl.xml b/base_classes/NXentry.nxdl.xml old mode 100644 new mode 100755 index e5865bd60c..2bb4ca533e --- a/base_classes/NXentry.nxdl.xml +++ b/base_classes/NXentry.nxdl.xml @@ -1,10 +1,10 @@ - + - - - (**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. - - - - .. 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 <validItemName>` 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 <Find-Plottable-Data-v3>` - section. - - - - - 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 - - - - - - ISIS Muon IDF_Version - - - - - Extended title for entry - - - - - Unique identifier for the experiment, - defined by the facility, - possibly linked to the proposals - - - - - Brief summary of the experiment, including key objectives. - - - - - Description of the full experiment (document in pdf, latex, ...) - - - - - User or Data Acquisition defined group of NeXus files or NXentry - - - - - Brief summary of the collection, including grouping criteria. - - - - - unique identifier for the measurement, defined by the facility. - - - - - UUID identifier for the measurement. - - - - Version of UUID used - - - - - - Reserved for future use by NIAC. - - See https://github.com/nexusformat/definitions/issues/382 - - - - - (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. - - - - NXDL version number - - - - - URL of NXDL file - - - - - - Local NXDL schema extended from the entry - specified in the ``definition`` field. - This contains any locally-defined, - additional fields in the entry. - - - - NXDL version number - - - - - URL of NXDL file - - - - - - Starting time of measurement - - - - - Ending time of measurement - - - - - Duration of measurement - - - - - Time transpired actually collecting data i.e. taking out time when collection was - suspended due to e.g. temperature out of range - - - - - Such as "2007-3". Some user facilities organize their beam time into run cycles. - - - - - Name of program used to generate this file - - - - Program version number - - - - - configuration of the program - - - - - - Revision id of the file due to re-calibration, reprocessing, new analysis, new - instrument definition format, ... - - - - - - This is the flightpath before the sample position. This can be determined by a chopper, - by the moderator or the source itself. In other words: it the distance to the component - which gives the T0 signal to the detector electronics. If another component in the - NXinstrument hierarchy provides this information, this should be a link. - - - - - Notes describing entry - - - - - A small image that is representative of the entry. An example of this is a 640x480 - jpeg image automatically produced by a low resolution plot of the NXdata. - - - - The mime type should be an ``image/*`` - - - - - - - - - - City and country where the experiment took place - - - - - Start time of experimental run that includes the current - measurement, for example a beam time. - - - - - End time of experimental run that includes the current - measurement, for example a beam time. - - - - - Name of the institution hosting the facility - - - - - Name of the experimental facility - - - - - Name of the laboratory or beamline - - - - - - - - - - + + + + + .. 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 <validItemName>` 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 <Find-Plottable-Data-v3>` + section. + + + + + (**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. + + + + 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 + + + + + + + ISIS Muon IDF_Version + + + Extended title for entry + + + + Unique identifier for the experiment, + defined by the facility, + possibly linked to the proposals + + + + Brief summary of the experiment, including key objectives. + + + Description of the full experiment (document in pdf, latex, ...) + + + User or Data Acquisition defined group of NeXus files or NXentry + + + Brief summary of the collection, including grouping criteria. + + + unique identifier for the measurement, defined by the facility. + + + UUID identifier for the measurement. + Version of UUID used + + + + Reserved for future use by NIAC. + + See https://github.com/nexusformat/definitions/issues/382 + + + + + (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. + + NXDL version number + URL of NXDL file + + + + Local NXDL schema extended from the entry + specified in the ``definition`` field. + This contains any locally-defined, + additional fields in the entry. + + NXDL version number + URL of NXDL file + + + Starting time of measurement + + + Ending time of measurement + + + Duration of measurement + + + + Time transpired actually collecting data i.e. taking out time when collection was + suspended due to e.g. temperature out of range + + + + Such as "2007-3". Some user facilities organize their beam time into run cycles. + + + Name of program used to generate this file + Program version number + configuration of the program + + + + Revision id of the file due to re-calibration, reprocessing, new analysis, new + instrument definition format, ... + + + + + + This is the flightpath before the sample position. This can be determined by a chopper, + by the moderator or the source itself. In other words: it the distance to the component + which gives the T0 signal to the detector electronics. If another component in the + NXinstrument hierarchy provides this information, this should be a link. + + + + Notes describing entry + + + + A small image that is representative of the entry. An example of this is a 640x480 + jpeg image automatically produced by a low resolution plot of the NXdata. + + + The mime type should be an ``image/*`` + + + + + + + + + + + + + + From 3793763cd95570381a34a1add3c45809ad48180f Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 20 Sep 2023 18:07:53 +0200 Subject: [PATCH 0254/1012] One more fix for NXentry --- base_classes/NXentry.nxdl.xml | 496 ++++++++++++++++++++-------------- 1 file changed, 286 insertions(+), 210 deletions(-) mode change 100755 => 100644 base_classes/NXentry.nxdl.xml diff --git a/base_classes/NXentry.nxdl.xml b/base_classes/NXentry.nxdl.xml old mode 100755 new mode 100644 index 2bb4ca533e..e5865bd60c --- a/base_classes/NXentry.nxdl.xml +++ b/base_classes/NXentry.nxdl.xml @@ -1,10 +1,10 @@ - + - - - - - .. 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 <validItemName>` 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 <Find-Plottable-Data-v3>` - section. - - - - - (**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. - - - - 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 - - - - - - - ISIS Muon IDF_Version - - - Extended title for entry - - - - Unique identifier for the experiment, - defined by the facility, - possibly linked to the proposals - - - - Brief summary of the experiment, including key objectives. - - - Description of the full experiment (document in pdf, latex, ...) - - - User or Data Acquisition defined group of NeXus files or NXentry - - - Brief summary of the collection, including grouping criteria. - - - unique identifier for the measurement, defined by the facility. - - - UUID identifier for the measurement. - Version of UUID used - - - - Reserved for future use by NIAC. - - See https://github.com/nexusformat/definitions/issues/382 - - - - - (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. - - NXDL version number - URL of NXDL file - - - - Local NXDL schema extended from the entry - specified in the ``definition`` field. - This contains any locally-defined, - additional fields in the entry. - - NXDL version number - URL of NXDL file - - - Starting time of measurement - - - Ending time of measurement - - - Duration of measurement - - - - Time transpired actually collecting data i.e. taking out time when collection was - suspended due to e.g. temperature out of range - - - - Such as "2007-3". Some user facilities organize their beam time into run cycles. - - - Name of program used to generate this file - Program version number - configuration of the program - - - - Revision id of the file due to re-calibration, reprocessing, new analysis, new - instrument definition format, ... - - - - - - This is the flightpath before the sample position. This can be determined by a chopper, - by the moderator or the source itself. In other words: it the distance to the component - which gives the T0 signal to the detector electronics. If another component in the - NXinstrument hierarchy provides this information, this should be a link. - - - - Notes describing entry - - - - A small image that is representative of the entry. An example of this is a 640x480 - jpeg image automatically produced by a low resolution plot of the NXdata. - - - The mime type should be an ``image/*`` - - - - - - - - - - - - - - + + + (**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. + + + + .. 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 <validItemName>` 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 <Find-Plottable-Data-v3>` + section. + + + + + 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 + + + + + + ISIS Muon IDF_Version + + + + + Extended title for entry + + + + + Unique identifier for the experiment, + defined by the facility, + possibly linked to the proposals + + + + + Brief summary of the experiment, including key objectives. + + + + + Description of the full experiment (document in pdf, latex, ...) + + + + + User or Data Acquisition defined group of NeXus files or NXentry + + + + + Brief summary of the collection, including grouping criteria. + + + + + unique identifier for the measurement, defined by the facility. + + + + + UUID identifier for the measurement. + + + + Version of UUID used + + + + + + Reserved for future use by NIAC. + + See https://github.com/nexusformat/definitions/issues/382 + + + + + (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. + + + + NXDL version number + + + + + URL of NXDL file + + + + + + Local NXDL schema extended from the entry + specified in the ``definition`` field. + This contains any locally-defined, + additional fields in the entry. + + + + NXDL version number + + + + + URL of NXDL file + + + + + + Starting time of measurement + + + + + Ending time of measurement + + + + + Duration of measurement + + + + + Time transpired actually collecting data i.e. taking out time when collection was + suspended due to e.g. temperature out of range + + + + + Such as "2007-3". Some user facilities organize their beam time into run cycles. + + + + + Name of program used to generate this file + + + + Program version number + + + + + configuration of the program + + + + + + Revision id of the file due to re-calibration, reprocessing, new analysis, new + instrument definition format, ... + + + + + + This is the flightpath before the sample position. This can be determined by a chopper, + by the moderator or the source itself. In other words: it the distance to the component + which gives the T0 signal to the detector electronics. If another component in the + NXinstrument hierarchy provides this information, this should be a link. + + + + + Notes describing entry + + + + + A small image that is representative of the entry. An example of this is a 640x480 + jpeg image automatically produced by a low resolution plot of the NXdata. + + + + The mime type should be an ``image/*`` + + + + + + + + + + City and country where the experiment took place + + + + + Start time of experimental run that includes the current + measurement, for example a beam time. + + + + + End time of experimental run that includes the current + measurement, for example a beam time. + + + + + Name of the institution hosting the facility + + + + + Name of the experimental facility + + + + + Name of the laboratory or beamline + + + + + + + + + + From 17675294d92efcc481145cd97ced54d3b91f9072 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 21 Sep 2023 13:01:50 +0200 Subject: [PATCH 0255/1012] Readd unintentionally removed fields, add drain_current environment --- contributed_definitions/NXmpes.nxdl.xml | 104 ++++-- contributed_definitions/nyaml/NXmpes.yaml | 366 +++++++++++++++++----- 2 files changed, 367 insertions(+), 103 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 23edbfabb2..c355593972 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -33,13 +33,26 @@ Datetime of the start of the measurement. + + + Datetime of the end of the measurement. + + + + + A name of the experimental method according + to the `ISO 18115-1:2023`_ specification. + + .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + + - + Contact information of at least the user of the instrument or the investigator who performed this experiment. Adding multiple users if relevant is recommended. @@ -73,8 +86,11 @@ - - + + + 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 @@ -92,23 +108,31 @@ + + + - + + + Specification of type, may also go to name. + + + Type of probe. In photoemission it's always photons, so the full NIAC list is restricted. - - - + - - + + + + Distance of the point of evaluation of the beam from the sample surface. @@ -118,6 +142,11 @@ + + + + + @@ -128,6 +157,9 @@ + Scheme of the electron collection column. @@ -135,6 +167,7 @@ + @@ -142,6 +175,7 @@ + @@ -206,6 +240,8 @@ + @@ -223,12 +259,13 @@ Manipulator for positioning of the sample. - + + - + Document an event of data processing, reconstruction, or analysis for this data. Describe the appropriate axis calibrations for your experiment using one or more @@ -340,6 +377,9 @@ Measured sample temperature. + + This field may also be found in NXmanipulator if present. + In that case, this should be a link to /entry/instrument/manipulator/sample_temperature. @@ -353,8 +393,7 @@ In the case of an experiment in which the temperature is changed and recorded, - this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. + this is an array of length m of temperatures. @@ -362,6 +401,9 @@ Gas pressure surrounding the sample. + + This field may also be found in NXinstrument if present. + In that case, this should be a link to /entry/instrument/gas_pressure. @@ -375,15 +417,17 @@ In the case of an experiment in which the gas pressure is changed and recorded, - this is an array of length m of gas pressures. This should be a link to - /entry/instrument/manipulator/sample_temperature. + this is an array of length m of gas pressures. - + Voltage applied to sample and sample holder. + + This field may also be found in NXmanipulator if present. + In that case, this should be a link to /entry/instrument/manipulator/sample_bias. @@ -397,12 +441,34 @@ In the case of an experiment in which the bias is changed and recorded, - this is an array of length m of voltages. This should be a link to - /entry/instrument/manipulator/sample_temperature. + this is an array of length m of voltages. - + + + + Drain current of the sample and sample holder. + This field may also be found in NXmanipulator if present. + In that case, this should be a link to /entry/instrument/manipulator/drain_current. + + + + + + + In the case of a fixed current, this is the scalar drain current of the sample + and sample holder. + + + + + In the case of an experiment in which the current changes and is recorded, + this is an array of length m of drain currents. + + + + diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 652e623c74..f5230af7d9 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -9,10 +9,20 @@ NXmpes(NXobject): start_time(NX_DATE_TIME): doc: | Datetime of the start of the measurement. + end_time(NX_DATE_TIME): + doc: | + Datetime of the end of the measurement. + method: + doc: | + A name of the experimental method according + to the `ISO 18115-1:2023`_ specification. + + .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html definition: \@version: enumeration: [NXmpes] (NXuser): + exists: recommended doc: | Contact information of at least the user of the instrument or the investigator who performed this experiment. Adding multiple users if relevant is recommended. @@ -39,23 +49,38 @@ NXmpes(NXobject): (NXinstrument): energy_resolution(NX_FLOAT): unit: NX_ENERGY - (NXsource): + exists: recommended + source_beam(NXsource): + + # Comment from mpes may workshop: + # - Add linking between source and beam + # - There is much more information which can be provided for NXsource doc: | The source used to generate the primary photons. Properties refer strictly to parameters of the source, not of the output beam. For example, the energy of the source is not the optical power of the beam, but the energy of the electron beam in a synchrotron and so on. type: - enumeration: [Synchrotron X-ray Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, UV Plasma Source, Metal Jet X-ray, HHG laser] + enumeration: [Synchrotron X-ray Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, UV Plasma Source, Metal Jet X-ray, HHG laser, UV lamp, Monochromatized electron source, other] + type_other: + exists: optional + doc: | + Specification of type, may also go to name. name: + exists: recommended probe: doc: | Type of probe. In photoemission it's always photons, so the full NIAC list is restricted. - enumeration: [x-ray, ultraviolet, visible light] - (NXbeam): + enumeration: [photons] + beam_probe(NXbeam): + + # Comment from mpes may workshop: Add linking between source and beam + + # Add extent as recommended? distance(NX_NUMBER): unit: NX_LENGTH + exists: recommended doc: | Distance of the point of evaluation of the beam from the sample surface. incident_energy(NX_FLOAT): @@ -67,6 +92,14 @@ NXmpes(NXobject): exists: recommended unit: NX_ANY (NXelectronanalyser): + model(NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended description: energy_resolution(NX_FLOAT): exists: recommended @@ -79,12 +112,18 @@ NXmpes(NXobject): slow_axes: exists: recommended (NXcollectioncolumn): + + # TODO: Comment from Anders Frisk on proposal page + # What is the definition of a collection column? + # Optional constant settings (like lens focusing parameters on the sample: position_x, position_y, working_distance) scheme: doc: | Scheme of the electron collection column. - enumeration: [Standard, Angular dispersive, Selective area, Deflector, PEEM, Momentum Microscope] + enumeration: [Standard, Angular dispersive, Spatial dispersive, Selective area, Deflector, PEEM, Momentum Microscope] mode: exists: recommended + + # TODO: What does this refer to. It is currently not in the collection column base class projection: exists: recommended field_aperture(NXaperture): @@ -126,6 +165,9 @@ NXmpes(NXobject): enumeration: [DLD, Phosphor+CCD, Phosphor+CMOS, ECMOS, Anode, Multi-anode] (NXdata): exists: recommended + + # TODO: Anders Frisk on proposal page + # It could be a lot of raw data from a detector. Shpould be optional. \@signal: enumeration: [raw] raw(NX_NUMBER): @@ -135,7 +177,9 @@ NXmpes(NXobject): exists: optional doc: | Manipulator for positioning of the sample. - sample_temperature(NX_FLOAT): + + # These fields should be NXenvironments and should be changed once NXmanipulator is refactored. + sample_temperature(NXenvironment): exists: recommended unit: NX_TEMPERATURE drain_current(NX_FLOAT): @@ -145,6 +189,7 @@ NXmpes(NXobject): exists: recommended unit: NX_CURRENT (NXprocess): + exists: recommended doc: | Document an event of data processing, reconstruction, or analysis for this data. Describe the appropriate axis calibrations for your experiment using one or more @@ -188,13 +233,13 @@ NXmpes(NXobject): (NXsample): name: (NXsubstance): - doc: - For samples containing a single pure substances. For mixtures use the NXsample_component_set - and NXsample_component group in NXsample instead. + doc: | + For samples containing a single pure substances. For mixtures use the + NXsample_component_set and NXsample_component group in NXsample instead. molecular_formula_hill: exists: recommended doc: | - The chemical formula of the sample. + The chemical formula of the sample. atom_types: exists: recommended doc: | @@ -221,7 +266,7 @@ NXmpes(NXobject): annealing). start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): - exists: recommended + exists: recommended method: exists: optional doc: | @@ -229,67 +274,96 @@ NXmpes(NXobject): notes: exists: optional temperature(NXenvironment): + exists: recommended doc: | Measured sample temperature. - exists: recommended + + This field may also be found in NXmanipulator if present. + In that case, this should be a link to /entry/instrument/manipulator/sample_temperature. thermocouple(NXsensor): name: type: exists: recommended value(NX_FLOAT): exists: recommended + unit: NX_TEMPERATURE doc: | In the case of a fixed temperature measurement, this is the scalar temperature of the sample. - unit: NX_TEMPERATURE value_log(NXlog): exists: optional - doc: | - In the case of an experiment in which the temperature is changed and recorded, - this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. unit: NX_TEMPERATURE + doc: | + In the case of an experiment in which the temperature is changed and recorded, + this is an array of length m of temperatures. gas_pressure(NXenvironment): + exists: recommended doc: | - Gas pressure surrounding the sample. - exists: recommended + Gas pressure surrounding the sample. + + This field may also be found in NXinstrument if present. + In that case, this should be a link to /entry/instrument/gas_pressure. pressure_gauge(NXsensor): name: type: exists: recommended value(NX_FLOAT): exists: recommended + unit: NX_PRESSURE doc: | In the case of a fixed gas pressure measurement, this is the scalar gas pressure around the sample. - unit: NX_PRESSURE value_log(NXlog): exists: optional - doc: | - In the case of an experiment in which the gas pressure is changed and recorded, - this is an array of length m of gas pressures. This should be a link to - /entry/instrument/manipulator/sample_temperature. unit: NX_PRESSURE - bias(NX_FLOAT): + doc: | + In the case of an experiment in which the gas pressure is changed and recorded, + this is an array of length m of gas pressures. + bias(NXenvironment): + exists: recommended doc: | Voltage applied to sample and sample holder. - exists: recommended + + This field may also be found in NXmanipulator if present. + In that case, this should be a link to /entry/instrument/manipulator/sample_bias. voltmeter(NXsensor): name: type: exists: recommended value(NX_FLOAT): exists: recommended + unit: NX_VOLTAGE doc: | - In the case of a fixed applied bias, this is the scalar voltage applied to sample and sample holder. + In the case of a fixed applied bias, this is the scalar voltage applied to + sample and sample holder. + value_log(NXlog): + exists: optional unit: NX_VOLTAGE + doc: | + In the case of an experiment in which the bias is changed and recorded, + this is an array of length m of voltages. + drain_current(NXenvironment): + exists: optional + doc: | + Drain current of the sample and sample holder. + This field may also be found in NXmanipulator if present. + In that case, this should be a link to /entry/instrument/manipulator/drain_current. + amperemeter(NXsensor): + name: + type: + exists: recommended + value(NX_FLOAT): + exists: recommended + unit: NX_CURRENT + doc: | + In the case of a fixed current, this is the scalar drain current of the sample + and sample holder. value_log(NXlog): exists: optional + unit: NX_CURRENT doc: | - In the case of an experiment in which the bias is changed and recorded, - this is an array of length m of voltages. This should be a link to - /entry/instrument/manipulator/sample_temperature. - unit: NX_VOLTAGE + In the case of an experiment in which the current changes and is recorded, + this is an array of length m of drain currents. (NXdata): \@signal: enumeration: [data] @@ -302,14 +376,14 @@ NXmpes(NXobject): actual encoder position in NXinstrument or calibrated axes in NXprocess. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e618cc098656aa72e4a5bd743c85c5d9c9caa79cbe85d96b6e06fafd1d165d1b +# 6deee0a1dfba19577fde9b5db71dbd078b2ea7a8a3f9c35dfc5ae43d6c5af0a6 # # # # # 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 @@ -397,23 +487,31 @@ NXmpes(NXobject): # # # +# +# +# # # -# +# +# +# Specification of type, may also go to name. +# +# +# # # # Type of probe. In photoemission it's always photons, so the full NIAC list is # restricted. # # -# -# -# +# # # # -# -# +# +# +# +# # # Distance of the point of evaluation of the beam from the sample surface. # @@ -423,6 +521,11 @@ NXmpes(NXobject): # # # +# +# +# +# +# # # # @@ -433,6 +536,9 @@ NXmpes(NXobject): # # # +# # # # Scheme of the electron collection column. @@ -440,6 +546,7 @@ NXmpes(NXobject): # # # +# # # # @@ -447,6 +554,7 @@ NXmpes(NXobject): # # # +# # # # @@ -511,6 +619,8 @@ NXmpes(NXobject): # # # +# # # # @@ -528,12 +638,13 @@ NXmpes(NXobject): # # Manipulator for positioning of the sample. # -# +# +# # # # # -# +# # # Document an event of data processing, reconstruction, or analysis for this data. # Describe the appropriate axis calibrations for your experiment using one or more @@ -590,20 +701,16 @@ NXmpes(NXobject): # # # -# +# # -# The chemical formula of the sample. For mixtures use the NXsample_component -# group in NXsample instead. -# -# -# -# -# A descriptor to keep track of the treatment of the sample before entering the -# photoemission experiment. Ideally, a full report of the previous operations, in -# any format (NXnote allows to add pictures, audio, movies). Alternatively, a -# reference to the location or a unique identifier or other metadata file. In the -# case these are not available, free-text description. +# For samples containing a single pure substances. For mixtures use the +# NXsample_component_set and NXsample_component group in NXsample instead. # +# +# +# The chemical formula of the sample. +# +# # # # @@ -613,29 +720,6 @@ NXmpes(NXobject): # elements from each component must be included in `atom_types`. # # -# -# -# Date of preparation of the sample for the XPS experiment (i.e. cleaving, last -# annealing). -# -# -# -# -# Description of the surface preparation technique for the XPS experiment, i.e. -# UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report -# of the previous operations, in any format(NXnote allows to add pictures, audio, -# movies). Alternatively, a reference to the location or a unique identifier or -# other metadata file. In the case these are not available, free-text description. -# -# -# -# -# In the case of a fixed temperature measurement this is the scalar temperature of -# the sample. In the case of an experiment in which the temperature is changed and -# recoded, this is an array of length m of temperatures. This should be a link to -# /entry/instrument/manipulator/sample_temperature. -# -# # # # @@ -644,12 +728,126 @@ NXmpes(NXobject): # # # -# -# +# # -# Voltage applied to sample and sample holder. +# A set of activities that occurred to the sample prior to/during photoemission experiment. +# +# Ideally, a full report of the previous operations (or links to a chain of operations). +# Alternatively, notes allow for additional descriptors in any format +# (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. # -# +# +# +# Details about the sample preparation for the MPES experiment (i.e. cleaving, last +# annealing). +# +# +# +# +# +# Details about the method of sample preparation before the MPES experiment. +# +# +# +# +# +# +# +# Measured sample temperature. +# +# This field may also be found in NXmanipulator if present. +# In that case, this should be a link to /entry/instrument/manipulator/sample_temperature. +# +# +# +# +# +# +# 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 recorded, +# this is an array of length m of temperatures. +# +# +# +# +# +# +# Gas pressure surrounding the sample. +# +# This field may also be found in NXinstrument if present. +# In that case, this should be a link to /entry/instrument/gas_pressure. +# +# +# +# +# +# +# In the case of a fixed gas pressure measurement, this is the scalar gas pressure around +# the sample. +# +# +# +# +# In the case of an experiment in which the gas pressure is changed and recorded, +# this is an array of length m of gas pressures. +# +# +# +# +# +# +# Voltage applied to sample and sample holder. +# +# This field may also be found in NXmanipulator if present. +# In that case, this should be a link to /entry/instrument/manipulator/sample_bias. +# +# +# +# +# +# +# In the case of a fixed applied bias, this is the scalar voltage applied to +# sample and sample holder. +# +# +# +# +# In the case of an experiment in which the bias is changed and recorded, +# this is an array of length m of voltages. +# +# +# +# +# +# +# Drain current of the sample and sample holder. +# This field may also be found in NXmanipulator if present. +# In that case, this should be a link to /entry/instrument/manipulator/drain_current. +# +# +# +# +# +# +# In the case of a fixed current, this is the scalar drain current of the sample +# and sample holder. +# +# +# +# +# In the case of an experiment in which the current changes and is recorded, +# this is an array of length m of drain currents. +# +# +# +# # # # From a546c11e6806fba3feb9c16cd98ebc6786e91c31 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 21 Sep 2023 13:04:15 +0200 Subject: [PATCH 0256/1012] Remove commented nxdl code in nyaml --- contributed_definitions/nyaml/NXmpes.yaml | 492 ---------------------- 1 file changed, 492 deletions(-) diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index f5230af7d9..36d518da24 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -374,495 +374,3 @@ NXmpes(NXobject): 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 6deee0a1dfba19577fde9b5db71dbd078b2ea7a8a3f9c35dfc5ae43d6c5af0a6 -# -# -# -# -# -# This is the most general application definition for multidimensional -# photoelectron spectroscopy. -# -# -# -# -# -# Datetime of the start of the measurement. -# -# -# -# -# Datetime of the end of the measurement. -# -# -# -# -# A name of the experimental method according -# to the `ISO 18115-1:2023`_ specification. -# -# .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html -# -# -# -# -# -# -# -# -# -# -# Contact information of at least the user of the instrument or the investigator -# who performed this experiment. Adding multiple users if relevant is recommended. -# -# -# -# Name of the user. -# -# -# -# -# Name of the affiliation of the user at the point in time when the experiment was -# performed. -# -# -# -# -# Full address (street, street number, ZIP, city, country) of the user's -# affiliation. -# -# -# -# -# Email address of the user. -# -# -# -# -# Author ID defined by https://orcid.org/. -# -# -# -# -# -# -# -# -# The source used to generate the primary photons. Properties refer strictly to -# parameters of the source, not of the output beam. For example, the energy of the -# source is not the optical power of the beam, but the energy of the electron beam -# in a synchrotron and so on. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Specification of type, may also go to name. -# -# -# -# -# -# Type of probe. In photoemission it's always photons, so the full NIAC list is -# restricted. -# -# -# -# -# -# -# -# -# -# -# -# Distance of the point of evaluation of the beam from the sample surface. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Energy resolution of the analyser with the current setting. May be linked from a -# NXcalibration. -# -# -# -# -# -# -# -# -# Scheme of the electron collection column. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The size and position of the field aperture inserted in the column. To add -# additional or other apertures use the APERTURE group of NXcollectioncolumn. -# -# -# -# -# The size and position of the contrast aperture inserted in the column. To add -# additional or other apertures use the APERTURE group of NXcollectioncolumn. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Size, position and shape of the entrance slit in dispersive analyzers. To add -# additional or other slits use the APERTURE group of NXenergydispersion. -# -# -# -# -# Size, position and shape of the exit slit in dispersive analyzers. To add -# additional or other slits use the APERTURE group of NXenergydispersion. -# -# -# -# -# -# -# Type of electron amplifier in the first amplification step. -# -# -# -# -# -# -# -# -# Description of the detector type. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Raw data before calibration. -# -# -# -# -# -# -# -# Manipulator for positioning of the sample. -# -# -# -# -# -# -# -# -# -# Document an event of data processing, reconstruction, or analysis for this data. -# Describe the appropriate axis calibrations for your experiment using one or more -# of the following NXcalibrations -# -# -# -# -# Has an energy calibration been applied? -# -# -# -# -# This is the calibrated energy axis to be used for data plotting. -# -# -# -# -# -# -# Has an angular calibration been applied? -# -# -# -# -# This is the calibrated angular axis to be used for data plotting. -# -# -# -# -# -# -# Has an spatial calibration been applied? -# -# -# -# -# This is the calibrated spatial axis to be used for data plotting. -# -# -# -# -# -# -# Has an momentum calibration been applied? -# -# -# -# -# This is the momentum axis to be used for data plotting. -# -# -# -# -# -# -# -# -# For samples containing a single pure substances. For mixtures use the -# NXsample_component_set and NXsample_component group in NXsample instead. -# -# -# -# The chemical formula of the sample. -# -# -# -# -# -# List of comma-separated elements from the periodic table -# that are contained in the sample. -# If the sample substance has multiple components, all -# elements from each component must be included in `atom_types`. -# -# -# -# -# -# -# -# -# -# -# -# -# A set of activities that occurred to the sample prior to/during photoemission experiment. -# -# Ideally, a full report of the previous operations (or links to a chain of operations). -# Alternatively, notes allow for additional descriptors 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. -# -# -# -# Details about the sample preparation for the MPES experiment (i.e. cleaving, last -# annealing). -# -# -# -# -# -# Details about the method of sample preparation before the MPES experiment. -# -# -# -# -# -# -# -# Measured sample temperature. -# -# This field may also be found in NXmanipulator if present. -# In that case, this should be a link to /entry/instrument/manipulator/sample_temperature. -# -# -# -# -# -# -# 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 recorded, -# this is an array of length m of temperatures. -# -# -# -# -# -# -# Gas pressure surrounding the sample. -# -# This field may also be found in NXinstrument if present. -# In that case, this should be a link to /entry/instrument/gas_pressure. -# -# -# -# -# -# -# In the case of a fixed gas pressure measurement, this is the scalar gas pressure around -# the sample. -# -# -# -# -# In the case of an experiment in which the gas pressure is changed and recorded, -# this is an array of length m of gas pressures. -# -# -# -# -# -# -# Voltage applied to sample and sample holder. -# -# This field may also be found in NXmanipulator if present. -# In that case, this should be a link to /entry/instrument/manipulator/sample_bias. -# -# -# -# -# -# -# In the case of a fixed applied bias, this is the scalar voltage applied to -# sample and sample holder. -# -# -# -# -# In the case of an experiment in which the bias is changed and recorded, -# this is an array of length m of voltages. -# -# -# -# -# -# -# Drain current of the sample and sample holder. -# This field may also be found in NXmanipulator if present. -# In that case, this should be a link to /entry/instrument/manipulator/drain_current. -# -# -# -# -# -# -# In the case of a fixed current, this is the scalar drain current of the sample -# and sample holder. -# -# -# -# -# In the case of an experiment in which the current changes and is recorded, -# this is an array of length m of drain currents. -# -# -# -# -# -# -# -# -# -# -# -# -# -# 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. -# -# -# -# -# From 3de0d9101cf4dd71404d1acee2f9fcb57398fbb7 Mon Sep 17 00:00:00 2001 From: domna Date: Thu, 21 Sep 2023 13:11:19 +0200 Subject: [PATCH 0257/1012] Use NXmpes.yaml generated with correct nyaml2nxdl --- contributed_definitions/nyaml/NXmpes.yaml | 454 +++++++++++++++++++++- 1 file changed, 447 insertions(+), 7 deletions(-) diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 8721626809..3190b0af73 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -1,9 +1,9 @@ -doc: | +category: application +doc: | This is the most general application definition for multidimensional photoelectron spectroscopy. -category: application -uri: http://purl.org/pan-science/PaNET/PaNET01269 -NXmpes: +type: group +NXmpes(NXobject): (NXentry): title: start_time(NX_DATE_TIME): @@ -48,9 +48,13 @@ NXmpes: Author ID defined by https://orcid.org/. (NXinstrument): energy_resolution(NX_FLOAT): - exists: recommended unit: NX_ENERGY + exists: recommended source_beam(NXsource): + + # Comment from mpes may workshop: + # - Add linking between source and beam + # - There is much more information which can be provided for NXsource doc: | 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 @@ -59,6 +63,7 @@ NXmpes: type: enumeration: [Synchrotron X-ray Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, UV Plasma Source, Metal Jet X-ray, HHG laser, UV lamp, Monochromatized electron source, other] type_other: + exists: optional doc: | Specification of type, may also go to name. name: @@ -69,9 +74,13 @@ NXmpes: restricted. enumeration: [photons] beam_probe(NXbeam): + + # Comment from mpes may workshop: Add linking between source and beam + + # Add extent as recommended? distance(NX_NUMBER): - exists: recommended unit: NX_LENGTH + exists: recommended doc: | Distance of the point of evaluation of the beam from the sample surface. incident_energy(NX_FLOAT): @@ -103,19 +112,27 @@ NXmpes: slow_axes: exists: recommended (NXcollectioncolumn): + + # TODO: Comment from Anders Frisk on proposal page + # What is the definition of a collection column? + # Optional constant settings (like lens focusing parameters on the sample: position_x, position_y, working_distance) scheme: doc: | Scheme of the electron collection column. enumeration: [Standard, Angular dispersive, Spatial dispersive, Selective area, Deflector, PEEM, Momentum Microscope] mode: exists: recommended + + # TODO: What does this refer to. It is currently not in the collection column base class projection: exists: recommended field_aperture(NXaperture): + exists: optional doc: | The size and position of the field aperture inserted in the column. To add additional or other apertures use the APERTURE group of NXcollectioncolumn. contrast_aperture(NXaperture): + exists: optional doc: | The size and position of the contrast aperture inserted in the column. To add additional or other apertures use the APERTURE group of NXcollectioncolumn. @@ -126,10 +143,12 @@ NXmpes: unit: NX_ENERGY energy_scan_mode: entrance_slit(NXaperture): + exists: optional doc: | Size, position and shape of the entrance slit in dispersive analyzers. To add additional or other slits use the APERTURE group of NXenergydispersion. exit_slit(NXaperture): + exists: optional doc: | Size, position and shape of the exit slit in dispersive analyzers. To add additional or other slits use the APERTURE group of NXenergydispersion. @@ -146,12 +165,16 @@ NXmpes: enumeration: [DLD, Phosphor+CCD, Phosphor+CMOS, ECMOS, Anode, Multi-anode] (NXdata): exists: recommended + + # TODO: Anders Frisk on proposal page + # It could be a lot of raw data from a detector. Shpould be optional. \@signal: enumeration: [raw] raw(NX_NUMBER): doc: | Raw data before calibration. (NXmanipulator): + exists: optional doc: | Manipulator for positioning of the sample. sample_temperature(NX_FLOAT): @@ -170,6 +193,7 @@ NXmpes: Describe the appropriate axis calibrations for your experiment using one or more of the following NXcalibrations energy_calibration(NXcalibration): + exists: optional applied(NX_BOOLEAN): doc: | Has an energy calibration been applied? @@ -178,6 +202,7 @@ NXmpes: doc: | This is the calibrated energy axis to be used for data plotting. angular_calibration(NXcalibration): + exists: optional applied(NX_BOOLEAN): doc: | Has an angular calibration been applied? @@ -186,6 +211,7 @@ NXmpes: doc: | This is the calibrated angular axis to be used for data plotting. spatial_calibration(NXcalibration): + exists: optional applied(NX_BOOLEAN): doc: | Has an spatial calibration been applied? @@ -194,6 +220,7 @@ NXmpes: doc: | This is the calibrated spatial axis to be used for data plotting. momentum_calibration(NXcalibration): + exists: optional applied(NX_BOOLEAN): doc: | Has an momentum calibration been applied? @@ -229,6 +256,7 @@ NXmpes: Date of preparation of the sample for the XPS experiment (i.e. cleaving, last annealing). preparation_description(NXnote): + exists: optional doc: | Description of the surface preparation technique for the XPS experiment, i.e. UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report @@ -236,19 +264,22 @@ NXmpes: 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. temperature(NX_FLOAT): - exists: recommended unit: NX_TEMPERATURE + exists: recommended doc: | 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. situation: + exists: optional enumeration: [vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere] gas_pressure(NX_FLOAT): unit: NX_PRESSURE + exists: optional bias(NX_FLOAT): unit: NX_VOLTAGE + exists: optional doc: | Voltage applied to sample and sample holder. (NXdata): @@ -261,3 +292,412 @@ NXmpes: 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e18956fa79544e7b4f50e31f3b421e387cab531f4f608e4c9dfc0013fa459429 +# +# +# +# +# +# This is the most general application definition for multidimensional +# photoelectron spectroscopy. +# +# +# +# +# +# Datetime of the start of the measurement. +# +# +# +# +# Datetime of the end of the measurement. +# +# +# +# +# A name of the experimental method according +# to the `ISO 18115-1:2023`_ specification. +# +# .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html +# +# +# +# +# +# +# +# +# +# +# Contact information of at least the user of the instrument or the investigator +# who performed this experiment. Adding multiple users if relevant is recommended. +# +# +# +# Name of the user. +# +# +# +# +# Name of the affiliation of the user at the point in time when the experiment was +# performed. +# +# +# +# +# Full address (street, street number, ZIP, city, country) of the user's +# affiliation. +# +# +# +# +# Email address of the user. +# +# +# +# +# Author ID defined by https://orcid.org/. +# +# +# +# +# +# +# +# +# The source used to generate the primary photons. Properties refer strictly to +# parameters of the source, not of the output beam. For example, the energy of the +# source is not the optical power of the beam, but the energy of the electron beam +# in a synchrotron and so on. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Specification of type, may also go to name. +# +# +# +# +# +# Type of probe. In photoemission it's always photons, so the full NIAC list is +# restricted. +# +# +# +# +# +# +# +# +# +# +# +# Distance of the point of evaluation of the beam from the sample surface. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Energy resolution of the analyser with the current setting. May be linked from a +# NXcalibration. +# +# +# +# +# +# +# +# +# Scheme of the electron collection column. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The size and position of the field aperture inserted in the column. To add +# additional or other apertures use the APERTURE group of NXcollectioncolumn. +# +# +# +# +# The size and position of the contrast aperture inserted in the column. To add +# additional or other apertures use the APERTURE group of NXcollectioncolumn. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Size, position and shape of the entrance slit in dispersive analyzers. To add +# additional or other slits use the APERTURE group of NXenergydispersion. +# +# +# +# +# Size, position and shape of the exit slit in dispersive analyzers. To add +# additional or other slits use the APERTURE group of NXenergydispersion. +# +# +# +# +# +# +# Type of electron amplifier in the first amplification step. +# +# +# +# +# +# +# +# +# Description of the detector type. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Raw data before calibration. +# +# +# +# +# +# +# +# Manipulator for positioning of the sample. +# +# +# +# +# +# +# +# +# Document an event of data processing, reconstruction, or analysis for this data. +# Describe the appropriate axis calibrations for your experiment using one or more +# of the following NXcalibrations +# +# +# +# +# Has an energy calibration been applied? +# +# +# +# +# This is the calibrated energy axis to be used for data plotting. +# +# +# +# +# +# +# Has an angular calibration been applied? +# +# +# +# +# This is the calibrated angular axis to be used for data plotting. +# +# +# +# +# +# +# Has an spatial calibration been applied? +# +# +# +# +# This is the calibrated spatial axis to be used for data plotting. +# +# +# +# +# +# +# Has an momentum calibration been applied? +# +# +# +# +# This is the momentum axis to be used for data plotting. +# +# +# +# +# +# +# +# +# The chemical formula of the sample. For mixtures use the NXsample_component +# group in NXsample instead. +# +# +# +# +# A descriptor to keep track of the treatment of the sample before entering the +# photoemission experiment. Ideally, a full report of the previous operations, in +# any format (NXnote allows to add pictures, audio, movies). Alternatively, a +# reference to the location or a unique identifier or other metadata file. In the +# case these are not available, free-text description. +# +# +# +# +# List of comma-separated elements from the periodic table +# that are contained in the sample. +# If the sample substance has multiple components, all +# elements from each component must be included in `atom_types`. +# +# +# +# +# Date of preparation of the sample for the XPS experiment (i.e. cleaving, last +# annealing). +# +# +# +# +# Description of the surface preparation technique for the XPS experiment, i.e. +# UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report +# of the previous operations, in any format(NXnote allows to add pictures, audio, +# movies). Alternatively, a reference to the location or a unique identifier or +# other metadata file. In the case these are not available, free-text description. +# +# +# +# +# In the case of a fixed temperature measurement this is the scalar temperature of +# the sample. In the case of an experiment in which the temperature is changed and +# recoded, this is an array of length m of temperatures. This should be a link to +# /entry/instrument/manipulator/sample_temperature. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Voltage applied to sample and sample holder. +# +# +# +# +# +# +# +# +# +# +# +# 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. +# +# +# +# +# From 8a4c31384876c32d450ade81dc406da2efe8b2f0 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 22 Sep 2023 12:37:53 +0200 Subject: [PATCH 0258/1012] Store NXsensor on NXinstrument (and NXmanipulator) instead of NXsample --- base_classes/NXinstrument.nxdl.xml | 1 + .../NXmanipulator.nxdl.xml | 46 +- contributed_definitions/NXmpes.nxdl.xml | 194 +++--- contributed_definitions/nyaml/NXmpes.yaml | 612 ++++-------------- 4 files changed, 267 insertions(+), 586 deletions(-) diff --git a/base_classes/NXinstrument.nxdl.xml b/base_classes/NXinstrument.nxdl.xml index 7fb369f97d..dbb60ce5e9 100644 --- a/base_classes/NXinstrument.nxdl.xml +++ b/base_classes/NXinstrument.nxdl.xml @@ -90,6 +90,7 @@ + diff --git a/contributed_definitions/NXmanipulator.nxdl.xml b/contributed_definitions/NXmanipulator.nxdl.xml index ad59e06205..7612aaf133 100644 --- a/contributed_definitions/NXmanipulator.nxdl.xml +++ b/contributed_definitions/NXmanipulator.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + Extension of NXpositioner to include fields to describe the use of manipulators in photoemission experiments. @@ -46,34 +46,42 @@ Is cryocoolant flowing through the manipulator? - + - Temperature of the cryostat (coldest point) + Cryostat for cooling the sample. - - + + - Power in the heater for temperature control. + Device for applying heating power for temperature control. - - + + - Temperature at the closest point to the sample. This field may also be found in - NXsample if present. + Sensor to measure the temperature at the closest point to the sample. + + This field may also be found in NXsample if present. - - + + - Current to neutralize the photoemission current. This field may also be found in - NXsample if present. + Current to neutralize the photoemission current. + + This field may also be found in NXsample if present. - - + + - Possible bias of the sample with trespect to analyser ground. This field may - also be found in NXsample if present. + Device to measure/set possible bias of the sample with respect to analyser ground. + + This field may also be found in NXsample if present. - + + + + Any additional sensors on the manipulator used to monitor an external condition. + + Class to describe the motors that are used in the manipulator diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 1b9a4fb9fc..7393247ada 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -259,10 +259,98 @@ It could be a lot of raw data from a detector. Shpould be optional.--> Manipulator for positioning of the sample. - - - - + + + + + + In the case of a fixed temperature measurement, this is the scalar temperature measured + by the sample thermocouple. + + + + + In the case of an experiment in which the temperature is changed and recorded, + this is an array of length m of temperatures. + + + + + + + + + In the case of a fixed temperature measurement, this is the scalar temperature + setpoint. + + + + + In the case of an experiment in which the temperature is changed and recorded, + this is an array of length m of temperatures. + + + + + + Amperemeter measuring the drain current of the sample and sample holder. + + + + + + + In the case of a fixed current, this is the scalar drain current of the sample + and sample holder. + + + + + + In the case of an experiment in which the current changes and is recorded, + this is an array of length m of drain currents. + + + + + + Sensor setting/measuring the voltage applied to sample and sample holder. + + + + + + In the case of a fixed applied bias, this is the scalar voltage applied to + sample and sample holder. + + + + + In the case of an experiment in which the bias is changed and recorded, + this is an array of length m of voltages. + + + + + + + This field may also be found in NXinstrument if present. + In that case, this should be a link to /entry/instrument/gas_pressure. + + + + + + In the case of a fixed gas pressure measurement, this is the scalar gas pressure around + the sample. + + + + + In the case of an experiment in which the gas pressure is changed and recorded, + this is an array of length m of gas pressures. + + @@ -376,97 +464,57 @@ It could be a lot of raw data from a detector. Shpould be optional.--> - Measured sample temperature. - - This field may also be found in NXmanipulator if present. - In that case, this should be a link to /entry/instrument/manipulator/sample_temperature. + Sample temperature (either controlled or just measured). - - - - - 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 recorded, - this is an array of length m of temperatures. - - + + Thermocouple measuring the sample temperature. + + This should be a link to /entry/instrument/manipulator/sample_thermocouple. + + + + + Device to heat the sample. + + This should be a link to /entry/instrument/manipulator/sample_heater. + Gas pressure surrounding the sample. - - This field may also be found in NXinstrument if present. - In that case, this should be a link to /entry/instrument/gas_pressure. - - - - - In the case of a fixed gas pressure measurement, this is the scalar gas pressure around - the sample. - - - - - In the case of an experiment in which the gas pressure is changed and recorded, - this is an array of length m of gas pressures. - - + + Pressure gauge measuring the gas pressure. + + This should be a link to /entry/instrument/pressure_gauge. + Voltage applied to sample and sample holder. - - This field may also be found in NXmanipulator if present. - In that case, this should be a link to /entry/instrument/manipulator/sample_bias. - - - - - In the case of a fixed applied bias, this is the scalar voltage applied to - sample and sample holder. - - - - - In the case of an experiment in which the bias is changed and recorded, - this is an array of length m of voltages. - - + + Sensor setting/measuring the applied voltage. + + This should be a link to /entry/instrument/manipulator/sample_bias_voltmeter. + - + Drain current of the sample and sample holder. - This field may also be found in NXmanipulator if present. - In that case, this should be a link to /entry/instrument/manipulator/drain_current. - - - - - In the case of a fixed current, this is the scalar drain current of the sample - and sample holder. - - - - - In the case of an experiment in which the current changes and is recorded, - this is an array of length m of drain currents. - - + + Amperemeter measuring the drain current of the sample and sample holder. + + This should be a link to /entry/instrument/manipulator/drain_current_amperemeter. + diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index f17485cc4f..0208a7dc46 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -176,18 +176,100 @@ NXmpes(NXobject): (NXmanipulator): exists: optional doc: | - Manipulator for positioning of the sample. - - # These fields should be NXenvironments and should be changed once NXmanipulator is refactored. - sample_temperature(NXenvironment): - exists: recommended - unit: NX_TEMPERATURE - drain_current(NX_FLOAT): - exists: recommended - unit: NX_CURRENT - sample_bias(NX_FLOAT): + Manipulator for positioning of the sample. + sample_thermocouple(NXsensor): + name: + exists: recommended + type: + exists: recommended + value(NX_FLOAT): + exists: recommended + unit: NX_TEMPERATURE + doc: | + In the case of a fixed temperature measurement, this is the scalar temperature measured + by the sample thermocouple. + value_log(NXlog): + exists: optional + unit: NX_TEMPERATURE + doc: | + In the case of an experiment in which the temperature is changed and recorded, + this is an array of length m of temperatures. + sample_heater(NXsensor): + name: + exists: recommended + type: + exists: recommended + value(NX_FLOAT): + exists: recommended + unit: NX_TEMPERATURE + doc: | + In the case of a fixed temperature measurement, this is the scalar temperature setpoint. + value_log(NXlog): + exists: optional + unit: NX_TEMPERATURE + doc: | + In the case of an experiment in which the temperature is changed and recorded, + this is an array of length m of temperatures. + drain_current_amperemeter(NXsensor): + doc: | + Amperemeter measuring the drain current of the sample and sample holder. exists: recommended - unit: NX_CURRENT + amperemeter(NXsensor): + name: + exists: recommended + type: + exists: recommended + value(NX_FLOAT): + exists: recommended + unit: NX_CURRENT + doc: | + In the case of a fixed current, this is the scalar drain current of the sample + and sample holder. + value_log(NXlog): + exists: optional + unit: NX_CURRENT + doc: | + In the case of an experiment in which the current changes and is recorded, + this is an array of length m of drain currents. + sample_bias_voltmeter(NXsensor): + doc: | + Sensor setting/measuring the voltage applied to sample and sample holder. + name: + exists: recommended + type: + exists: recommended + value(NX_FLOAT): + exists: recommended + unit: NX_VOLTAGE + doc: | + In the case of a fixed applied bias, this is the scalar voltage applied to + sample and sample holder. + value_log(NXlog): + exists: optional + unit: NX_VOLTAGE + doc: | + In the case of an experiment in which the bias is changed and recorded, + this is an array of length m of voltages. + pressure_gauge(NXsensor): + doc: | + This field may also be found in NXinstrument if present. + In that case, this should be a link to /entry/instrument/gas_pressure. + name: + exists: recommended + type: + exists: recommended + value(NX_FLOAT): + exists: recommended + unit: NX_PRESSURE + doc: | + In the case of a fixed gas pressure measurement, this is the scalar gas pressure around + the sample. + value_log(NXlog): + exists: optional + unit: NX_PRESSURE + doc: | + In the case of an experiment in which the gas pressure is changed and recorded, + this is an array of length m of gas pressures. (NXprocess): exists: recommended doc: | @@ -277,94 +359,45 @@ NXmpes(NXobject): temperature(NXenvironment): exists: recommended doc: | - Measured sample temperature. - - This field may also be found in NXmanipulator if present. - In that case, this should be a link to /entry/instrument/manipulator/sample_temperature. + Sample temperature (either controlled or just measured). thermocouple(NXsensor): - name: - type: - exists: recommended - value(NX_FLOAT): - exists: recommended - unit: NX_TEMPERATURE - doc: | - In the case of a fixed temperature measurement, this is the scalar temperature of - the sample. - value_log(NXlog): - exists: optional - unit: NX_TEMPERATURE - doc: | - In the case of an experiment in which the temperature is changed and recorded, - this is an array of length m of temperatures. + doc: | + Thermocouple measuring the sample temperature. + + This should be a link to /entry/instrument/manipulator/sample_thermocouple. + sample_heater(NXsensor): + exists: optional + doc: | + Device to heat the sample. + + This should be a link to /entry/instrument/manipulator/sample_heater. gas_pressure(NXenvironment): exists: recommended doc: | Gas pressure surrounding the sample. - - This field may also be found in NXinstrument if present. - In that case, this should be a link to /entry/instrument/gas_pressure. pressure_gauge(NXsensor): - name: - type: - exists: recommended - value(NX_FLOAT): - exists: recommended - unit: NX_PRESSURE - doc: | - In the case of a fixed gas pressure measurement, this is the scalar gas pressure around - the sample. - value_log(NXlog): - exists: optional - unit: NX_PRESSURE - doc: | - In the case of an experiment in which the gas pressure is changed and recorded, - this is an array of length m of gas pressures. + doc: | + Pressure gauge measuring the gas pressure. + + This should be a link to /entry/instrument/pressure_gauge. bias(NXenvironment): exists: recommended doc: | Voltage applied to sample and sample holder. - - This field may also be found in NXmanipulator if present. - In that case, this should be a link to /entry/instrument/manipulator/sample_bias. voltmeter(NXsensor): - name: - type: - exists: recommended - value(NX_FLOAT): - exists: recommended - unit: NX_VOLTAGE - doc: | - In the case of a fixed applied bias, this is the scalar voltage applied to - sample and sample holder. - value_log(NXlog): - exists: optional - unit: NX_VOLTAGE - doc: | - In the case of an experiment in which the bias is changed and recorded, - this is an array of length m of voltages. + doc: | + Sensor setting/measuring the applied voltage. + + This should be a link to /entry/instrument/manipulator/sample_bias_voltmeter. drain_current(NXenvironment): - exists: optional + exists: recommended doc: | Drain current of the sample and sample holder. - This field may also be found in NXmanipulator if present. - In that case, this should be a link to /entry/instrument/manipulator/drain_current. amperemeter(NXsensor): - name: - type: - exists: recommended - value(NX_FLOAT): - exists: recommended - unit: NX_CURRENT - doc: | - In the case of a fixed current, this is the scalar drain current of the sample - and sample holder. - value_log(NXlog): - exists: optional - unit: NX_CURRENT - doc: | - In the case of an experiment in which the current changes and is recorded, - this is an array of length m of drain currents. + doc: | + Amperemeter measuring the drain current of the sample and sample holder. + + This should be a link to /entry/instrument/manipulator/drain_current_amperemeter. (NXdata): \@signal: enumeration: [data] @@ -374,413 +407,4 @@ NXmpes(NXobject): 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e18956fa79544e7b4f50e31f3b421e387cab531f4f608e4c9dfc0013fa459429 -# -# -# -# -# -# This is the most general application definition for multidimensional -# photoelectron spectroscopy. -# -# -# -# -# -# Datetime of the start of the measurement. -# -# -# -# -# Datetime of the end of the measurement. -# -# -# -# -# A name of the experimental method according -# to the `ISO 18115-1:2023`_ specification. -# -# .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html -# -# -# -# -# -# -# -# -# -# -# Contact information of at least the user of the instrument or the investigator -# who performed this experiment. Adding multiple users if relevant is recommended. -# -# -# -# Name of the user. -# -# -# -# -# Name of the affiliation of the user at the point in time when the experiment was -# performed. -# -# -# -# -# Full address (street, street number, ZIP, city, country) of the user's -# affiliation. -# -# -# -# -# Email address of the user. -# -# -# -# -# Author ID defined by https://orcid.org/. -# -# -# -# -# -# -# -# -# The source used to generate the primary photons. Properties refer strictly to -# parameters of the source, not of the output beam. For example, the energy of the -# source is not the optical power of the beam, but the energy of the electron beam -# in a synchrotron and so on. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Specification of type, may also go to name. -# -# -# -# -# -# Type of probe. In photoemission it's always photons, so the full NIAC list is -# restricted. -# -# -# -# -# -# -# -# -# -# -# -# Distance of the point of evaluation of the beam from the sample surface. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Energy resolution of the analyser with the current setting. May be linked from a -# NXcalibration. -# -# -# -# -# -# -# -# -# Scheme of the electron collection column. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The size and position of the field aperture inserted in the column. To add -# additional or other apertures use the APERTURE group of NXcollectioncolumn. -# -# -# -# -# The size and position of the contrast aperture inserted in the column. To add -# additional or other apertures use the APERTURE group of NXcollectioncolumn. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Size, position and shape of the entrance slit in dispersive analyzers. To add -# additional or other slits use the APERTURE group of NXenergydispersion. -# -# -# -# -# Size, position and shape of the exit slit in dispersive analyzers. To add -# additional or other slits use the APERTURE group of NXenergydispersion. -# -# -# -# -# -# -# Type of electron amplifier in the first amplification step. -# -# -# -# -# -# -# -# -# Description of the detector type. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Raw data before calibration. -# -# -# -# -# -# -# -# Manipulator for positioning of the sample. -# -# -# -# -# -# -# -# -# Document an event of data processing, reconstruction, or analysis for this data. -# Describe the appropriate axis calibrations for your experiment using one or more -# of the following NXcalibrations -# -# -# -# -# Has an energy calibration been applied? -# -# -# -# -# This is the calibrated energy axis to be used for data plotting. -# -# -# -# -# -# -# Has an angular calibration been applied? -# -# -# -# -# This is the calibrated angular axis to be used for data plotting. -# -# -# -# -# -# -# Has an spatial calibration been applied? -# -# -# -# -# This is the calibrated spatial axis to be used for data plotting. -# -# -# -# -# -# -# Has an momentum calibration been applied? -# -# -# -# -# This is the momentum axis to be used for data plotting. -# -# -# -# -# -# -# -# -# The chemical formula of the sample. For mixtures use the NXsample_component -# group in NXsample instead. -# -# -# -# -# A descriptor to keep track of the treatment of the sample before entering the -# photoemission experiment. Ideally, a full report of the previous operations, in -# any format (NXnote allows to add pictures, audio, movies). Alternatively, a -# reference to the location or a unique identifier or other metadata file. In the -# case these are not available, free-text description. -# -# -# -# -# List of comma-separated elements from the periodic table -# that are contained in the sample. -# If the sample substance has multiple components, all -# elements from each component must be included in `atom_types`. -# -# -# -# -# Date of preparation of the sample for the XPS experiment (i.e. cleaving, last -# annealing). -# -# -# -# -# Description of the surface preparation technique for the XPS experiment, i.e. -# UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report -# of the previous operations, in any format(NXnote allows to add pictures, audio, -# movies). Alternatively, a reference to the location or a unique identifier or -# other metadata file. In the case these are not available, free-text description. -# -# -# -# -# In the case of a fixed temperature measurement this is the scalar temperature of -# the sample. In the case of an experiment in which the temperature is changed and -# recoded, this is an array of length m of temperatures. This should be a link to -# /entry/instrument/manipulator/sample_temperature. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Voltage applied to sample and sample holder. -# -# -# -# -# -# -# -# -# -# -# -# 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. -# -# -# -# -# + actual encoder position in NXinstrument or calibrated axes in NXprocess. \ No newline at end of file From 0614f9b43533340486bc432c439f4d1f8117031f Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 22 Sep 2023 12:42:31 +0200 Subject: [PATCH 0259/1012] Add nyamls for NXinstrument and NXmanipulator --- base_classes/nyaml/NXinstrument.yaml | 190 ++++++++++++++++++ .../nyaml/NXmanipulator.yaml | 61 ++++++ 2 files changed, 251 insertions(+) create mode 100644 base_classes/nyaml/NXinstrument.yaml create mode 100644 contributed_definitions/nyaml/NXmanipulator.yaml diff --git a/base_classes/nyaml/NXinstrument.yaml b/base_classes/nyaml/NXinstrument.yaml new file mode 100644 index 0000000000..ba4e234c1f --- /dev/null +++ b/base_classes/nyaml/NXinstrument.yaml @@ -0,0 +1,190 @@ +category: base +doc: | + 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. +type: group +NXinstrument(NXobject): + name: + doc: | + Name of instrument + \@short_name: + doc: | + short name for instrument, perhaps the acronym + energy_resolution(NX_FLOAT): + unit: NX_ENERGY + doc: | + Energy resolution of the experiment (FWHM or gaussian broadening) + momentum_resolution(NX_FLOAT): + unit: NX_WAVENUMBER + doc: | + Momentum resolution of the experiment (FWHM) + angular_resolution(NX_FLOAT): + unit: NX_ANGLE + doc: | + Angular resolution of the experiment (FWHM) + spatial_resolution(NX_FLOAT): + unit: NX_LENGTH + doc: | + Spatial resolution of the experiment (Airy disk radius) + temporal_resolution(NX_FLOAT): + unit: NX_TIME + doc: | + Temporal resolution of the experiment (FWHM) + (NXaperture): + (NXattenuator): + (NXbeam): + (NXbeam_stop): + (NXbending_magnet): + (NXcollimator): + (NXcollection): + (NXcapillary): + (NXcrystal): + (NXdetector): + (NXdetector_group): + (NXdisk_chopper): + (NXevent_data): + (NXfermi_chopper): + (NXfilter): + (NXflipper): + (NXguide): + (NXinsertion_device): + (NXmirror): + (NXmoderator): + (NXmonochromator): + (NXpolarizer): + (NXpositioner): + (NXsensor): + (NXsource): + (NXtransformations)DIFFRACTOMETER: + (NXvelocity_selector): + (NXxraylens): + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 331d6037bd4c05402a42cab90e3df4c3115b21231d57ef54b1221e1ed859584d +# +# +# +# +# +# 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. +# +# +# +# Name of instrument +# +# +# +# short name for instrument, perhaps the acronym +# +# +# +# +# +# Energy resolution of the experiment (FWHM or gaussian broadening) +# +# +# +# +# Momentum resolution of the experiment (FWHM) +# +# +# +# +# Angular resolution of the experiment (FWHM) +# +# +# +# +# Spatial resolution of the experiment (Airy disk radius) +# +# +# +# +# Temporal resolution of the experiment (FWHM) +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# diff --git a/contributed_definitions/nyaml/NXmanipulator.yaml b/contributed_definitions/nyaml/NXmanipulator.yaml new file mode 100644 index 0000000000..60a45ee3f7 --- /dev/null +++ b/contributed_definitions/nyaml/NXmanipulator.yaml @@ -0,0 +1,61 @@ +category: base +doc: | + Extension of NXpositioner to include fields to describe the use of manipulators + in photoemission experiments. +type: group +NXmanipulator(NXobject): + name(NX_CHAR): + doc: | + Name of the manipulator. + description(NX_CHAR): + doc: | + A description of the manipulator. + type(NX_CHAR): + doc: | + Type of manipulator, Hexapod, Rod, etc. + cryocoolant(NX_BOOLEAN): + doc: | + Is cryocoolant flowing through the manipulator? + cryostat(NXsensor): + doc: | + Cryostat for cooling the sample. + sample_heater(NXsensor): + doc: | + Device for applying heating power for temperature control. + sample_thermocouple(NXsensor): + doc: | + Sensor to measure the temperature at the closest point to the sample. + + This field may also be found in NXsample if present. + drain_current_amperemeter(NXsensor): + doc: | + Current to neutralize the photoemission current. + + This field may also be found in NXsample if present. + sample_bias_voltmeter(NXsensor): + doc: | + Device to measure/set possible bias of the sample with respect to analyser ground. + + This field may also be found in NXsample if present. + (NXsensor): + doc: | + Any additional sensors on the manipulator used to monitor an external condition. + (NXpositioner): + doc: | + Class to describe the motors that are used in the manipulator + depends_on(NX_CHAR): + doc: | + Refers to the last transformation specifying the positon of the manipulator in + the NXtransformations chain. + (NXtransformations): + doc: | + 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. + + From be5755baea1878ef835f46668c055bac95a5ed4a Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 22 Sep 2023 16:08:48 +0200 Subject: [PATCH 0260/1012] Add NXactuator base class --- base_classes/NXenvironment.nxdl.xml | 62 +++++++++++-------- base_classes/NXinstrument.nxdl.xml | 1 + base_classes/nyaml/NXinstrument.yaml | 1 + .../NXmanipulator.nxdl.xml | 5 ++ contributed_definitions/NXmpes.nxdl.xml | 4 +- .../nyaml/NXmanipulator.yaml | 3 + contributed_definitions/nyaml/NXmpes.yaml | 4 +- 7 files changed, 51 insertions(+), 29 deletions(-) diff --git a/base_classes/NXenvironment.nxdl.xml b/base_classes/NXenvironment.nxdl.xml index 1b494e345e..1b29320fe2 100644 --- a/base_classes/NXenvironment.nxdl.xml +++ b/base_classes/NXenvironment.nxdl.xml @@ -1,9 +1,9 @@ - + - - Parameters for controlling external conditions + + + Parameters for controlling external conditions + - Apparatus identification code/model number; e.g. OC100 011 + + Apparatus identification code/model number; e.g. OC100 011 + - Alternative short name, perhaps for dashboard display like a present Seblock name + + Alternative short name, perhaps for dashboard display like a present Seblock + name + - Type of apparatus. This could be the SE codes in scheduling database; e.g. OC/100 + + Type of apparatus. This could be the SE codes in scheduling database; e.g. + OC/100 + - Description of the apparatus; e.g. 100mm bore orange cryostat with Roots pump + + Description of the apparatus; e.g. 100mm bore orange cryostat with Roots pump + - Program controlling the apparatus; e.g. LabView VI name + + Program controlling the apparatus; e.g. LabView VI name + @@ -50,25 +60,27 @@ - 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. - 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. - Additional information, LabView logs, digital photographs, etc + + Additional information, LabView logs, digital photographs, etc + + - diff --git a/base_classes/NXinstrument.nxdl.xml b/base_classes/NXinstrument.nxdl.xml index dbb60ce5e9..f60b9c2921 100644 --- a/base_classes/NXinstrument.nxdl.xml +++ b/base_classes/NXinstrument.nxdl.xml @@ -67,6 +67,7 @@ Temporal resolution of the experiment (FWHM) + diff --git a/base_classes/nyaml/NXinstrument.yaml b/base_classes/nyaml/NXinstrument.yaml index ba4e234c1f..1966713b7c 100644 --- a/base_classes/nyaml/NXinstrument.yaml +++ b/base_classes/nyaml/NXinstrument.yaml @@ -36,6 +36,7 @@ NXinstrument(NXobject): unit: NX_TIME doc: | Temporal resolution of the experiment (FWHM) + (NXactuator): (NXaperture): (NXattenuator): (NXbeam): diff --git a/contributed_definitions/NXmanipulator.nxdl.xml b/contributed_definitions/NXmanipulator.nxdl.xml index 7612aaf133..56332ca619 100644 --- a/contributed_definitions/NXmanipulator.nxdl.xml +++ b/contributed_definitions/NXmanipulator.nxdl.xml @@ -77,6 +77,11 @@ This field may also be found in NXsample if present. + + + Any additional sensors on the manipulator used to control an external condition. + + Any additional sensors on the manipulator used to monitor an external condition. diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 7393247ada..9581302746 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -259,7 +259,7 @@ It could be a lot of raw data from a detector. Shpould be optional.--> Manipulator for positioning of the sample. - + @@ -466,7 +466,7 @@ It could be a lot of raw data from a detector. Shpould be optional.--> Sample temperature (either controlled or just measured). - + Thermocouple measuring the sample temperature. diff --git a/contributed_definitions/nyaml/NXmanipulator.yaml b/contributed_definitions/nyaml/NXmanipulator.yaml index 60a45ee3f7..6280c80d70 100644 --- a/contributed_definitions/nyaml/NXmanipulator.yaml +++ b/contributed_definitions/nyaml/NXmanipulator.yaml @@ -37,6 +37,9 @@ NXmanipulator(NXobject): Device to measure/set possible bias of the sample with respect to analyser ground. This field may also be found in NXsample if present. + (NXactuator): + doc: | + Any additional sensors on the manipulator used to control an external condition. (NXsensor): doc: | Any additional sensors on the manipulator used to monitor an external condition. diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 0208a7dc46..0c3af82fdc 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -177,7 +177,7 @@ NXmpes(NXobject): exists: optional doc: | Manipulator for positioning of the sample. - sample_thermocouple(NXsensor): + sample_thermocouple(NXactuator): name: exists: recommended type: @@ -360,7 +360,7 @@ NXmpes(NXobject): exists: recommended doc: | Sample temperature (either controlled or just measured). - thermocouple(NXsensor): + thermocouple(NXactuator): doc: | Thermocouple measuring the sample temperature. From 6020c0f8f985eaf081985555db27f800cda529d4 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 22 Sep 2023 16:10:37 +0200 Subject: [PATCH 0261/1012] Change cryostat and sample_heater to NXactuator --- contributed_definitions/NXmanipulator.nxdl.xml | 4 ++-- contributed_definitions/nyaml/NXmanipulator.yaml | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/contributed_definitions/NXmanipulator.nxdl.xml b/contributed_definitions/NXmanipulator.nxdl.xml index 56332ca619..96aafcbb93 100644 --- a/contributed_definitions/NXmanipulator.nxdl.xml +++ b/contributed_definitions/NXmanipulator.nxdl.xml @@ -46,12 +46,12 @@ Is cryocoolant flowing through the manipulator? - + Cryostat for cooling the sample. - + Device for applying heating power for temperature control. diff --git a/contributed_definitions/nyaml/NXmanipulator.yaml b/contributed_definitions/nyaml/NXmanipulator.yaml index 6280c80d70..60c8159843 100644 --- a/contributed_definitions/nyaml/NXmanipulator.yaml +++ b/contributed_definitions/nyaml/NXmanipulator.yaml @@ -16,10 +16,10 @@ NXmanipulator(NXobject): cryocoolant(NX_BOOLEAN): doc: | Is cryocoolant flowing through the manipulator? - cryostat(NXsensor): + cryostat(NXactuator): doc: | Cryostat for cooling the sample. - sample_heater(NXsensor): + sample_heater(NXactuator): doc: | Device for applying heating power for temperature control. sample_thermocouple(NXsensor): From 32ec656c5f02066847e8b8132e22b10bbcf92beb Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 22 Sep 2023 16:11:16 +0200 Subject: [PATCH 0262/1012] Add nyamls for changed base classes --- base_classes/nyaml/NXenvironment.yaml | 121 +++++++ base_classes/nyaml/NXsensor.yaml | 323 ++++++++++++++++++ contributed_definitions/NXactuator.nxdl.xml | 185 ++++++++++ contributed_definitions/nyaml/NXactuator.yaml | 110 ++++++ 4 files changed, 739 insertions(+) create mode 100644 base_classes/nyaml/NXenvironment.yaml create mode 100644 base_classes/nyaml/NXsensor.yaml create mode 100644 contributed_definitions/NXactuator.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXactuator.yaml diff --git a/base_classes/nyaml/NXenvironment.yaml b/base_classes/nyaml/NXenvironment.yaml new file mode 100644 index 0000000000..407ace0c0f --- /dev/null +++ b/base_classes/nyaml/NXenvironment.yaml @@ -0,0 +1,121 @@ +category: base +doc: | + Parameters for controlling external conditions +type: group +NXenvironment(NXobject): + name: + doc: | + Apparatus identification code/model number; e.g. OC100 011 + short_name: + doc: | + Alternative short name, perhaps for dashboard display like a present Seblock name + type: + doc: | + Type of apparatus. This could be the SE codes in scheduling database; e.g. OC/100 + description: + doc: | + Description of the apparatus; e.g. 100mm bore orange cryostat with Roots pump + program: + doc: | + Program controlling the apparatus; e.g. LabView VI name + position(NXgeometry): + doc: | + The position and orientation of the apparatus. + Note, it is recommended to use NXtransformations instead. + depends_on(NX_CHAR): + doc: | + 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. + (NXtransformations): + exists: ['min', '0'] + doc: | + 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. + (NXnote): + doc: | + Additional information, LabView logs, digital photographs, etc + (NXactuator): + (NXsensor): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 8d95a3f1615f3146244d8f2a05eda98e75a2ca49ffefa97329db446c658f9def +# +# +# +# +# Parameters for controlling external conditions +# +# Apparatus identification code/model number; e.g. OC100 011 +# +# +# Alternative short name, perhaps for dashboard display like a present Seblock name +# +# +# Type of apparatus. This could be the SE codes in scheduling database; e.g. OC/100 +# +# +# Description of the apparatus; e.g. 100mm bore orange cryostat with Roots pump +# +# +# Program controlling the apparatus; e.g. LabView VI name +# +# +# +# The position and orientation of the apparatus. +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# 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. +# +# +# +# +# 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. +# +# +# +# Additional information, LabView logs, digital photographs, etc +# +# +# +# diff --git a/base_classes/nyaml/NXsensor.yaml b/base_classes/nyaml/NXsensor.yaml new file mode 100644 index 0000000000..eeb3c54fe7 --- /dev/null +++ b/base_classes/nyaml/NXsensor.yaml @@ -0,0 +1,323 @@ +category: base +doc: | + A sensor used to monitor an external condition + + The condition itself is described in :ref:`NXenvironment`. +type: group +NXsensor(NXobject): + model: + doc: | + Sensor identification code/model number + name: + doc: | + Name for the sensor + short_name: + doc: | + Short name of sensor used e.g. on monitor display program + attached_to: + doc: | + where sensor is attached to ("sample" | "can") + geometry(NXgeometry): + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the beamstop and NXoff_geometry to describe its shape instead + doc: | + Defines the axes for logged vector quantities if they are not the global instrument axes. + measurement: + doc: | + name for measured signal + enumeration: [temperature, pH, magnetic_field, electric_field, conductivity, resistance, voltage, pressure, flow, stress, strain, shear, surface_pressure] + type: + doc: | + The type of hardware used for the measurement. + Examples (suggestions but not restrictions): + + :Temperature: + J | K | T | E | R | S | Pt100 | Rh/Fe + :pH: + Hg/Hg2Cl2 | Ag/AgCl | ISFET + :Ion selective electrode: + specify species; e.g. Ca2+ + :Magnetic field: + Hall + :Surface pressure: + wilhelmy plate + run_control(NX_BOOLEAN): + doc: | + Is data collection controlled or synchronised to this quantity: + 1=no, 0=to "value", 1=to "value_deriv1", etc. + high_trip_value(NX_FLOAT): + unit: NX_ANY + doc: | + Upper control bound of sensor reading if using run_control + low_trip_value(NX_FLOAT): + unit: NX_ANY + doc: | + Lower control bound of sensor reading if using run_control + value(NX_FLOAT): + unit: NX_ANY + doc: | + nominal setpoint or average value + - need [n] as may be a vector + dimensions: + dim: [[1, n]] + value_deriv1(NX_FLOAT): + unit: NX_ANY + doc: | + Nominal/average first derivative of value + e.g. strain rate + - same dimensions as "value" (may be a vector) + dimensions: + dim: [[1, ]] + dim_parameters: + ref: ['value'] + value_deriv2(NX_FLOAT): + unit: NX_ANY + doc: | + Nominal/average second derivative of value + - same dimensions as "value" (may be a vector) + dimensions: + dim: [[1, ]] + dim_parameters: + ref: ['value'] + value_log(NXlog): + doc: | + Time history of sensor readings + value_deriv1_log(NXlog): + doc: | + Time history of first derivative of sensor readings + value_deriv2_log(NXlog): + doc: | + Time history of second derivative of sensor readings + external_field_brief: + enumeration: [along beam, across beam, transverse, solenoidal, flow shear gradient, flow vorticity] + external_field_full(NXorientation): + doc: | + For complex external fields not satisfied by External_field_brief + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the sensor when necessary. + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a sensor. + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# df8bc397cbcbf114091b84ed357f6312641ca9abbf2d51795c37802450e7e628 +# +# +# +# +# +# A sensor used to monitor an external condition +# +# The condition itself is described in :ref:`NXenvironment`. +# +# +# Sensor identification code/model number +# +# +# Name for the sensor +# +# +# Short name of sensor used e.g. on monitor display program +# +# +# where sensor is attached to ("sample" | "can") +# +# +# +# Defines the axes for logged vector quantities if they are not the global instrument axes. +# +# +# +# name for measured signal +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The type of hardware used for the measurement. +# Examples (suggestions but not restrictions): +# +# :Temperature: +# J | K | T | E | R | S | Pt100 | Rh/Fe +# :pH: +# Hg/Hg2Cl2 | Ag/AgCl | ISFET +# :Ion selective electrode: +# specify species; e.g. Ca2+ +# :Magnetic field: +# Hall +# :Surface pressure: +# wilhelmy plate +# +# +# +# +# Is data collection controlled or synchronised to this quantity: +# 1=no, 0=to "value", 1=to "value_deriv1", etc. +# +# +# +# +# Upper control bound of sensor reading if using run_control +# +# +# +# +# Lower control bound of sensor reading if using run_control +# +# +# +# +# nominal setpoint or average value +# - need [n] as may be a vector +# +# +# +# +# +# +# +# Nominal/average first derivative of value +# e.g. strain rate +# - same dimensions as "value" (may be a vector) +# +# +# +# +# +# +# +# Nominal/average second derivative of value +# - same dimensions as "value" (may be a vector) +# +# +# +# +# +# +# Time history of sensor readings +# +# +# Time history of first derivative of sensor readings +# +# +# Time history of second derivative of sensor readings +# +# +# +# +# +# +# +# +# +# +# +# +# For complex external fields not satisfied by External_field_brief +# +# +# +# This group describes the shape of the sensor when necessary. +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a sensor. +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# diff --git a/contributed_definitions/NXactuator.nxdl.xml b/contributed_definitions/NXactuator.nxdl.xml new file mode 100644 index 0000000000..a48ce36a8d --- /dev/null +++ b/contributed_definitions/NXactuator.nxdl.xml @@ -0,0 +1,185 @@ + + + + + + An actuator used to control an external condition. + + The condition itself is described in :ref:`NXenvironment`. + + + + Actuator identification code/model number + + + + + Name for the actuator + + + + + Short name of actuator used e.g. on monitor display program + + + + + where actuator is attached to ("sample" | "can") + + + + + Defines the axes for logged vector quantities if they are not the global + instrument axes. + + + + + name for measured signal + + + + + + + + + + + + + + + + + + + + The type of hardware used for the actuation. + + Examples (suggestions but not restrictions): + :Temperature: + laser | gas lamp | filament | resistive + :Pressure: + anvil cell + :Voltage: + potentiostat + + + + + Nominal setpoint. Can be a scalar or a vector (of [n] actuations). + + + + + + + + Nominal/average first derivative of value + e.g. strain rate + - same dimensions as "value" (may be a vector) + + + + + + + + Nominal/average second derivative of value + - same dimensions as "value" (may be a vector) + + + + + + + + Time history of actuator outputs. + + + + + Time history of first derivative of actuator outputs + + + + + Time history of second derivative of actuator outputs + + + + + + + + + + + + + + + For complex external fields not satisfied by External_field_brief + + + + + This group describes the shape of the actuator when necessary. + + + + + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + + + + + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a actuator. + + + + + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. + + + diff --git a/contributed_definitions/nyaml/NXactuator.yaml b/contributed_definitions/nyaml/NXactuator.yaml new file mode 100644 index 0000000000..98817a8136 --- /dev/null +++ b/contributed_definitions/nyaml/NXactuator.yaml @@ -0,0 +1,110 @@ +category: base +doc: | + An actuator used to control an external condition. + + The condition itself is described in :ref:`NXenvironment`. +type: group +NXactuator(NXobject): + model: + doc: | + Actuator identification code/model number + name: + doc: | + Name for the actuator + short_name: + doc: | + Short name of actuator used e.g. on monitor display program + attached_to: + doc: | + where actuator is attached to ("sample" | "can") + geometry(NXgeometry): + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the beamstop and NXoff_geometry to describe its shape instead + doc: | + Defines the axes for logged vector quantities if they are not the global instrument axes. + actuation_type: + doc: | + name for measured signal + enumeration: [temperature, pH, magnetic_field, electric_field, conductivity, resistance, voltage, pressure, flow, stress, strain, shear, surface_pressure] + hardware_type: + doc: | + The type of hardware used for the actuation. + + Examples (suggestions but not restrictions): + :Temperature: + laser | gas lamp | filament | resistive + :Pressure: + anvil cell + :Voltage: + potentiostat + value(NX_FLOAT): + unit: NX_ANY + doc: | + Nominal setpoint. Can be a scalar or a vector (of [n] actuations). + dimensions: + dim: [[1, n]] + value_deriv1(NX_FLOAT): + unit: NX_ANY + doc: | + Nominal/average first derivative of value + e.g. strain rate + - same dimensions as "value" (may be a vector) + dimensions: + dim: [[1, ]] + dim_parameters: + ref: ['value'] + value_deriv2(NX_FLOAT): + unit: NX_ANY + doc: | + Nominal/average second derivative of value + - same dimensions as "value" (may be a vector) + dimensions: + dim: [[1, ]] + dim_parameters: + ref: ['value'] + value_log(NXlog): + doc: | + Time history of actuator outputs. + value_deriv1_log(NXlog): + doc: | + Time history of first derivative of actuator outputs + value_deriv2_log(NXlog): + doc: | + Time history of second derivative of actuator outputs + external_field_brief: + enumeration: [along beam, across beam, transverse, solenoidal, flow shear gradient, flow vorticity] + external_field_full(NXorientation): + doc: | + For complex external fields not satisfied by External_field_brief + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the actuator when necessary. + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a actuator. + (NXtransformations): + doc: | + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. \ No newline at end of file From 6b20b100cab5d75adf400fd02fff5f02db6081b5 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 22 Sep 2023 16:12:46 +0200 Subject: [PATCH 0263/1012] remove unchanged nyamls --- base_classes/nyaml/NXsensor.yaml | 323 ------------------------------- 1 file changed, 323 deletions(-) delete mode 100644 base_classes/nyaml/NXsensor.yaml diff --git a/base_classes/nyaml/NXsensor.yaml b/base_classes/nyaml/NXsensor.yaml deleted file mode 100644 index eeb3c54fe7..0000000000 --- a/base_classes/nyaml/NXsensor.yaml +++ /dev/null @@ -1,323 +0,0 @@ -category: base -doc: | - A sensor used to monitor an external condition - - The condition itself is described in :ref:`NXenvironment`. -type: group -NXsensor(NXobject): - model: - doc: | - Sensor identification code/model number - name: - doc: | - Name for the sensor - short_name: - doc: | - Short name of sensor used e.g. on monitor display program - attached_to: - doc: | - where sensor is attached to ("sample" | "can") - geometry(NXgeometry): - deprecated: | - Use the field `depends_on` and :ref:`NXtransformations` to position the beamstop and NXoff_geometry to describe its shape instead - doc: | - Defines the axes for logged vector quantities if they are not the global instrument axes. - measurement: - doc: | - name for measured signal - enumeration: [temperature, pH, magnetic_field, electric_field, conductivity, resistance, voltage, pressure, flow, stress, strain, shear, surface_pressure] - type: - doc: | - The type of hardware used for the measurement. - Examples (suggestions but not restrictions): - - :Temperature: - J | K | T | E | R | S | Pt100 | Rh/Fe - :pH: - Hg/Hg2Cl2 | Ag/AgCl | ISFET - :Ion selective electrode: - specify species; e.g. Ca2+ - :Magnetic field: - Hall - :Surface pressure: - wilhelmy plate - run_control(NX_BOOLEAN): - doc: | - Is data collection controlled or synchronised to this quantity: - 1=no, 0=to "value", 1=to "value_deriv1", etc. - high_trip_value(NX_FLOAT): - unit: NX_ANY - doc: | - Upper control bound of sensor reading if using run_control - low_trip_value(NX_FLOAT): - unit: NX_ANY - doc: | - Lower control bound of sensor reading if using run_control - value(NX_FLOAT): - unit: NX_ANY - doc: | - nominal setpoint or average value - - need [n] as may be a vector - dimensions: - dim: [[1, n]] - value_deriv1(NX_FLOAT): - unit: NX_ANY - doc: | - Nominal/average first derivative of value - e.g. strain rate - - same dimensions as "value" (may be a vector) - dimensions: - dim: [[1, ]] - dim_parameters: - ref: ['value'] - value_deriv2(NX_FLOAT): - unit: NX_ANY - doc: | - Nominal/average second derivative of value - - same dimensions as "value" (may be a vector) - dimensions: - dim: [[1, ]] - dim_parameters: - ref: ['value'] - value_log(NXlog): - doc: | - Time history of sensor readings - value_deriv1_log(NXlog): - doc: | - Time history of first derivative of sensor readings - value_deriv2_log(NXlog): - doc: | - Time history of second derivative of sensor readings - external_field_brief: - enumeration: [along beam, across beam, transverse, solenoidal, flow shear gradient, flow vorticity] - external_field_full(NXorientation): - doc: | - For complex external fields not satisfied by External_field_brief - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the sensor when necessary. - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a sensor. - (NXtransformations): - doc: | - 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# df8bc397cbcbf114091b84ed357f6312641ca9abbf2d51795c37802450e7e628 -# -# -# -# -# -# A sensor used to monitor an external condition -# -# The condition itself is described in :ref:`NXenvironment`. -# -# -# Sensor identification code/model number -# -# -# Name for the sensor -# -# -# Short name of sensor used e.g. on monitor display program -# -# -# where sensor is attached to ("sample" | "can") -# -# -# -# Defines the axes for logged vector quantities if they are not the global instrument axes. -# -# -# -# name for measured signal -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The type of hardware used for the measurement. -# Examples (suggestions but not restrictions): -# -# :Temperature: -# J | K | T | E | R | S | Pt100 | Rh/Fe -# :pH: -# Hg/Hg2Cl2 | Ag/AgCl | ISFET -# :Ion selective electrode: -# specify species; e.g. Ca2+ -# :Magnetic field: -# Hall -# :Surface pressure: -# wilhelmy plate -# -# -# -# -# Is data collection controlled or synchronised to this quantity: -# 1=no, 0=to "value", 1=to "value_deriv1", etc. -# -# -# -# -# Upper control bound of sensor reading if using run_control -# -# -# -# -# Lower control bound of sensor reading if using run_control -# -# -# -# -# nominal setpoint or average value -# - need [n] as may be a vector -# -# -# -# -# -# -# -# Nominal/average first derivative of value -# e.g. strain rate -# - same dimensions as "value" (may be a vector) -# -# -# -# -# -# -# -# Nominal/average second derivative of value -# - same dimensions as "value" (may be a vector) -# -# -# -# -# -# -# Time history of sensor readings -# -# -# Time history of first derivative of sensor readings -# -# -# Time history of second derivative of sensor readings -# -# -# -# -# -# -# -# -# -# -# -# -# For complex external fields not satisfied by External_field_brief -# -# -# -# This group describes the shape of the sensor when necessary. -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a sensor. -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# From ded3b61e6b29470a50f3fd0f398963eda4abd5ca Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 25 Sep 2023 09:50:58 +0200 Subject: [PATCH 0264/1012] Changes two link in FAIRmat-NeXus Proposal cover page --- manual/source/fairmat-cover.rst | 292 ++++++++++++++++---------------- 1 file changed, 146 insertions(+), 146 deletions(-) diff --git a/manual/source/fairmat-cover.rst b/manual/source/fairmat-cover.rst index d86dd303ec..9545073b62 100644 --- a/manual/source/fairmat-cover.rst +++ b/manual/source/fairmat-cover.rst @@ -1,146 +1,146 @@ -.. _FairmatCover: - -======================= -FAIRmat-NeXus Proposal -======================= - -.. index:: - IntroductionCover - OurScope - Outreach - WhichData - WhatIsNew - -Aim -######################### - -Experiments nowadays create a set of very often voluminous and diverse numerical data and metadata. -These pieces of information represent entities of what is effectively a graph of materials data. -This graph can have a very large number of nodes and edges representing the large variety of -relations which scientists ideally want to identify and master -when transforming experimental research into knowledge. - -Experimentalists face the challenge that these pieces of information come at different levels -of granularity and format, of which many need to be better documented. You have very likely experienced -yourself how file and data formats are routinely encountered tasks to master in your daily -research practice and you might have questioned how these formats are currently handled -when you want to produce FAIR research data and publications. - -The NeXus-FAIRmat proposal is an interdisciplinary data science activity initiated by scientists of the -condensed-matter physics community which strives to develop community-maintained open file and data formats -for describing specific experimental techniques, their numerical data and metadata, -and strategies how to exchange these pieces of information. - -.. _IntroductionCover: - -The FAIRmat proposal to NeXus is an effort by the community of scientists of the `FAIRmat consortium `_ -to refine and expand the structure of NeXus. As a project which aims at creating an infrastructure -for experimental data to be findable, accessible, interoperable, and reusable (FAIR) in the fields of -condensed-matter physics and the chemical physics of solids, FAIRmat has adopted NeXus as the common format. - -`NeXus `_ is a common data exchange format which has its origin in the community of -scientists performing neutron, x-ray, and muon experiments. The development of NeXus is coordinated by the -NeXus International Advisory Committee (NIAC). -NeXus defines a schema of data entries with a controlled vocabulary and defined relations between the entries. -NeXus offers not only tools to document these schema definitions in a version-controlled manner but -also tools to check and verify how and if specific instances of NeXus schemata comply with the intended -schema definition when the data are written to files. Although, the Hierarchical Data Format (HDF5) is the -most commonly used file format to write NeXus file to, NeXus can also be used with other file formats. - -NeXus defines domain-specific rules for organizing data in e.g. HDF5 files (:ref:`application.definitions`) -and defines a dictionary of well-defined domain-specific (a vocabulary) of terms (:ref:`base.class.definitions`). -The meta- and numerical data in a NeXus file represent a hierarchical graph which encodes a specifically -granularized representation of relevant pieces of information and results that should be stored with -an experiment. - -Base classes and application definitions are two key components of the NeXus data model. -A base class represents a set of numerical data and metadata which specify details about -scientists, projects, instruments, and other physical devices, including the numerical data -and metadata which are deemed relevant for their description and the associated -computational analyses. Application definitions are constructed from combining such experiment- -and research-question-specifically customized base classes. - -In this combination, an application definition is a data contract between -a producer and a consumer of these scientific data. - -This design has sufficient flexibility to cover any experimental technique and instrumentation, while -ensuring rigorous, application-specific structures that can be processed in an automated manner. - -In cases where base classes or application definitions have not yet been proposed advantage of NeXus can be taken -if the respective scientific community explicitly designs, implements, uses, and continuously evolves -these classes and definitions. Here the role of the NIAC is to support the community with -data modeling and data science technical expertise, thus taking an important role of -cross-disciplinary review. - -The NeXus-FAIRmat proposal represents the results of this development for experiments and use cases which have not yet used NeXus. -Specifically, the proposal includes cases in the materials-science-branch of electron microscopy (EM), photo-emission spectroscopy, -ellipsometry, and the field of atom probe tomography and related field-ion microscopy, here jointly referred to as atom probe microscopy. - - -The documentation available here includes parts of the contents of the NeXus User Manual (also available `here `_), -reported here for the convenience of the user, but is restricted to the parts most pertinent to the our proposal. - -For more extensive information, please visit the original manual. - -.. _OurScope: - -Our scope and perspective -######################### - -Thanks to a cooperative approach across a wide variety of experimental techniques, -the NeXus-FAIRmat proposal of the FAIRmat project has an opportunity -to expand the set of data/metadata accurately described via NeXus. - -With a closely-connected team of domain experts, we will develop such expansion while at the same time maintaining -a consistent structure across different techniques and methods, striving for the maximum simplicity of use. - -Achieving a standardized and FAIR data structure has a wide spectrum of advantages, ranging from radical -progress in scientific transparency to the development of new, far-reaching tools that can be shared across -the whole scientific community. The convenience of such tools can range from guaranteeing data reusability within -a single lab, to enabling open-source availability of ready-to-use advanced analysis software. - -Perhaps the greatest resource, however, is the inclusion of experimental datasets in the `NOMAD Laboratory `_: -a data infrastructure that already hosts the largest computational material science repository in the world, representing a -homogeneous and machine-readable archive, a human-accessible encyclopedia of materials data -with tools for automated artificial intelligence analyses and data access. - -.. _Outreach: - -Outreach to the community -########################## - -A data infrastructure is not effective if it does not integrate seamlessly in the day-to-day workflow of a laboratory. -For this reason, we approach our newly developed NeXus proposal as a community-driven development. -We have drafted an accurate and consistent expansion of NeXus capabilities for a number of lab-based techniques, -but need extensive testing and tweaking of its characteristics by the community. - -If your data is generated with these techniques and you are interested in producing FAIR data and accessing the FAIRmat tools, we -invite you to try out our proposed structure. If you find any conflicts or inconsistencies, please raise them to us using the -comment section. These comments are implemented with `Hypothesis `_, a modern web annotation -tool from the journalism community. The commenting function for each page of the proposal enable you to contribute to the -creation of a more consistent and practical NeXus structure which, in our firm belief, can serve your community and beyond. - -If you do not find your specific experimental technique but would be interested in participating in the development -of a standard using NeXus, feel also very much invited to contact us directly at the `FAIRmat-Team `_. - -.. _WhichData: - -Which data should I convert? -############################ - -You are free to choose at which point in the workflow you wish to convert the data to NeXus, as its flexibility allows to -describe raw data, pre-processed data and fully processed data. As an entry step, we suggest to use a test dataset -that is fully processed and already published (or, alternatively, of negligible scientific content). These datasets, indeed, require often the most -extensive metadata description, but are most easily converted to NeXus, with minimal to no impact on the data processing pipeline. - -In fact, a low barrier (but high yield!) way to participate to FAIRmat consists in converting only fully processed datasets that -are used for a publication, and publishing them via FAIRmat only when your manuscript is in press. This makes the task of -converting to NeXus much more sporadic than fairifying raw data, to the point that it may be even acceptable not to automate it. At the same time, -it guarantees full control on the data until publication. We are confident that if you take this approach, more appetite will come with eating, -and you will be naturally inclined to gradually integrate FAIRmat structures and tools further in your workflow. - - -.. _WhatIsNew: - -.. What is New? -.. ############## +.. _FairmatCover: + +======================= +FAIRmat-NeXus Proposal +======================= + +.. index:: + IntroductionCover + OurScope + Outreach + WhichData + WhatIsNew + +Aim +######################### + +Experiments nowadays create a set of very often voluminous and diverse numerical data and metadata. +These pieces of information represent entities of what is effectively a graph of materials data. +This graph can have a very large number of nodes and edges representing the large variety of +relations which scientists ideally want to identify and master +when transforming experimental research into knowledge. + +Experimentalists face the challenge that these pieces of information come at different levels +of granularity and format, of which many need to be better documented. You have very likely experienced +yourself how file and data formats are routinely encountered tasks to master in your daily +research practice and you might have questioned how these formats are currently handled +when you want to produce FAIR research data and publications. + +The NeXus-FAIRmat proposal is an interdisciplinary data science activity initiated by scientists of the +condensed-matter physics community which strives to develop community-maintained open file and data formats +for describing specific experimental techniques, their numerical data and metadata, +and strategies how to exchange these pieces of information. + +.. _IntroductionCover: + +The FAIRmat proposal to NeXus is an effort by the community of scientists of the `FAIRmat consortium `_ +to refine and expand the structure of NeXus. As a project which aims at creating an infrastructure +for experimental data to be findable, accessible, interoperable, and reusable (FAIR) in the fields of +condensed-matter physics and the chemical physics of solids, FAIRmat has adopted NeXus as the common format. + +`NeXus `_ is a common data exchange format which has its origin in the community of +scientists performing neutron, x-ray, and muon experiments. The development of NeXus is coordinated by the +NeXus International Advisory Committee (NIAC). +NeXus defines a schema of data entries with a controlled vocabulary and defined relations between the entries. +NeXus offers not only tools to document these schema definitions in a version-controlled manner but +also tools to check and verify how and if specific instances of NeXus schemata comply with the intended +schema definition when the data are written to files. Although, the Hierarchical Data Format (HDF5) is the +most commonly used file format to write NeXus file to, NeXus can also be used with other file formats. + +NeXus defines domain-specific rules for organizing data in e.g. HDF5 files (:ref:`application.definitions`) +and defines a dictionary of well-defined domain-specific (a vocabulary) of terms (:ref:`base.class.definitions`). +The meta- and numerical data in a NeXus file represent a hierarchical graph which encodes a specifically +granularized representation of relevant pieces of information and results that should be stored with +an experiment. + +Base classes and application definitions are two key components of the NeXus data model. +A base class represents a set of numerical data and metadata which specify details about +scientists, projects, instruments, and other physical devices, including the numerical data +and metadata which are deemed relevant for their description and the associated +computational analyses. Application definitions are constructed from combining such experiment- +and research-question-specifically customized base classes. + +In this combination, an application definition is a data contract between +a producer and a consumer of these scientific data. + +This design has sufficient flexibility to cover any experimental technique and instrumentation, while +ensuring rigorous, application-specific structures that can be processed in an automated manner. + +In cases where base classes or application definitions have not yet been proposed advantage of NeXus can be taken +if the respective scientific community explicitly designs, implements, uses, and continuously evolves +these classes and definitions. Here the role of the NIAC is to support the community with +data modeling and data science technical expertise, thus taking an important role of +cross-disciplinary review. + +The NeXus-FAIRmat proposal represents the results of this development for experiments and use cases which have not yet used NeXus. +Specifically, the proposal includes cases in the materials-science-branch of electron microscopy (EM), photo-emission spectroscopy, +ellipsometry, and the field of atom probe tomography and related field-ion microscopy, here jointly referred to as atom probe microscopy. + + +The documentation available here includes parts of the contents of the NeXus User Manual (also available `here `_), +reported here for the convenience of the user, but is restricted to the parts most pertinent to the our proposal. + +For more extensive information, please visit the original manual. + +.. _OurScope: + +Our scope and perspective +######################### + +Thanks to a cooperative approach across a wide variety of experimental techniques, +the NeXus-FAIRmat proposal of the FAIRmat project has an opportunity +to expand the set of data/metadata accurately described via NeXus. + +With a closely-connected team of domain experts, we will develop such expansion while at the same time maintaining +a consistent structure across different techniques and methods, striving for the maximum simplicity of use. + +Achieving a standardized and FAIR data structure has a wide spectrum of advantages, ranging from radical +progress in scientific transparency to the development of new, far-reaching tools that can be shared across +the whole scientific community. The convenience of such tools can range from guaranteeing data reusability within +a single lab, to enabling open-source availability of ready-to-use advanced analysis software. + +Perhaps the greatest resource, however, is the inclusion of experimental datasets in the `NOMAD Laboratory `_: +a data infrastructure that already hosts the largest computational material science repository in the world, representing a +homogeneous and machine-readable archive, a human-accessible encyclopedia of materials data +with tools for automated artificial intelligence analyses and data access. + +.. _Outreach: + +Outreach to the community +########################## + +A data infrastructure is not effective if it does not integrate seamlessly in the day-to-day workflow of a laboratory. +For this reason, we approach our newly developed NeXus proposal as a community-driven development. +We have drafted an accurate and consistent expansion of NeXus capabilities for a number of lab-based techniques, +but need extensive testing and tweaking of its characteristics by the community. + +If your data is generated with these techniques and you are interested in producing FAIR data and accessing the FAIRmat tools, we +invite you to try out our proposed structure. If you find any conflicts or inconsistencies, please raise them to us using the +comment section. These comments are implemented with `Hypothesis `_, a modern web annotation +tool from the journalism community. The commenting function for each page of the proposal enable you to contribute to the +creation of a more consistent and practical NeXus structure which, in our firm belief, can serve your community and beyond. + +If you do not find your specific experimental technique but would be interested in participating in the development +of a standard using NeXus, feel also very much invited to contact us directly at the `FAIRmat-Team `_. + +.. _WhichData: + +Which data should I convert? +############################ + +You are free to choose at which point in the workflow you wish to convert the data to NeXus, as its flexibility allows to +describe raw data, pre-processed data and fully processed data. As an entry step, we suggest to use a test dataset +that is fully processed and already published (or, alternatively, of negligible scientific content). These datasets, indeed, require often the most +extensive metadata description, but are most easily converted to NeXus, with minimal to no impact on the data processing pipeline. + +In fact, a low barrier (but high yield!) way to participate to FAIRmat consists in converting only fully processed datasets that +are used for a publication, and publishing them via FAIRmat only when your manuscript is in press. This makes the task of +converting to NeXus much more sporadic than fairifying raw data, to the point that it may be even acceptable not to automate it. At the same time, +it guarantees full control on the data until publication. We are confident that if you take this approach, more appetite will come with eating, +and you will be naturally inclined to gradually integrate FAIRmat structures and tools further in your workflow. + + +.. _WhatIsNew: + +.. What is New? +.. ############## From 149a2b6794d34aabf7522f5298cb8b512885a2f5 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 25 Sep 2023 11:00:50 +0200 Subject: [PATCH 0265/1012] Fix errors in NXmpes - Allows for current as actuation/measurement in NXactuator/NXsensor - Makes many fields related to environmental conditions recommended in NXmpes - Fix existing type errors - Fix docstrings --- base_classes/NXsensor.nxdl.xml | 332 +++++++++--------- base_classes/nyaml/NXsensor.yaml | 323 +++++++++++++++++ contributed_definitions/NXactuator.nxdl.xml | 5 +- contributed_definitions/NXmpes.nxdl.xml | 68 ++-- contributed_definitions/nyaml/NXactuator.yaml | 6 +- contributed_definitions/nyaml/NXmpes.yaml | 77 ++-- 6 files changed, 595 insertions(+), 216 deletions(-) create mode 100644 base_classes/nyaml/NXsensor.yaml diff --git a/base_classes/NXsensor.nxdl.xml b/base_classes/NXsensor.nxdl.xml index cdfc11ab04..3074114e1b 100644 --- a/base_classes/NXsensor.nxdl.xml +++ b/base_classes/NXsensor.nxdl.xml @@ -1,9 +1,9 @@ - + - - - A sensor used to monitor an external condition - - The condition itself is described in :ref:`NXenvironment`. - - - Sensor identification code/model number - - - Name for the sensor - - - Short name of sensor used e.g. on monitor display program - - - where sensor is attached to ("sample" | "can") - - - - Defines the axes for logged vector quantities if they are not the global instrument axes. - - - - name for measured signal - - - - - - - - - - - - - - - - - - - The type of hardware used for the measurement. - Examples (suggestions but not restrictions): - - :Temperature: - J | K | T | E | R | S | Pt100 | Rh/Fe - :pH: - Hg/Hg2Cl2 | Ag/AgCl | ISFET - :Ion selective electrode: - specify species; e.g. Ca2+ - :Magnetic field: - Hall - :Surface pressure: - wilhelmy plate - - - - - Is data collection controlled or synchronised to this quantity: - 1=no, 0=to "value", 1=to "value_deriv1", etc. - - - - - Upper control bound of sensor reading if using run_control - - - - - Lower control bound of sensor reading if using run_control - - - - - nominal setpoint or average value - - need [n] as may be a vector - - - - - - - - Nominal/average first derivative of value - e.g. strain rate - - same dimensions as "value" (may be a vector) - - - - - - - - Nominal/average second derivative of value - - same dimensions as "value" (may be a vector) - - - - - - - Time history of sensor readings - - - Time history of first derivative of sensor readings - - - Time history of second derivative of sensor readings - - - - - - - - - - - - - For complex external fields not satisfied by External_field_brief - - - - This group describes the shape of the sensor when necessary. - - + + + A sensor used to monitor an external condition + + The condition itself is described in :ref:`NXenvironment`. + + + + Sensor identification code/model number + + + + + Name for the sensor + + + + + Short name of sensor used e.g. on monitor display program + + + + + where sensor is attached to ("sample" | "can") + + + + + Defines the axes for logged vector quantities if they are not the global + instrument axes. + + + + + name for measured signal + + + + + + + + + + + + + + + + + + + + + The type of hardware used for the measurement. + Examples (suggestions but not restrictions): + + :Temperature: + J | K | T | E | R | S | Pt100 | Rh/Fe + :pH: + Hg/Hg2Cl2 | Ag/AgCl | ISFET + :Ion selective electrode: + specify species; e.g. Ca2+ + :Magnetic field: + Hall + :Surface pressure: + wilhelmy plate + + + + + Is data collection controlled or synchronised to this quantity: + 1=no, 0=to "value", 1=to "value_deriv1", etc. + + + + + Upper control bound of sensor reading if using run_control + + + + + Lower control bound of sensor reading if using run_control + + + + + nominal setpoint or average value + - need [n] as may be a vector + + + + + + + + Nominal/average first derivative of value + e.g. strain rate + - same dimensions as "value" (may be a vector) + + + + + + + + Nominal/average second derivative of value + - same dimensions as "value" (may be a vector) + + + + + + + + Time history of sensor readings + + + + + Time history of first derivative of sensor readings + + + + + Time history of second derivative of sensor readings + + + + + + + + + + + + + + + For complex external fields not satisfied by External_field_brief + + + + + This group describes the shape of the sensor when necessary. + + - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a sensor. - + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a sensor. - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. - diff --git a/base_classes/nyaml/NXsensor.yaml b/base_classes/nyaml/NXsensor.yaml new file mode 100644 index 0000000000..c3b780d4ea --- /dev/null +++ b/base_classes/nyaml/NXsensor.yaml @@ -0,0 +1,323 @@ +category: base +doc: | + A sensor used to monitor an external condition + + The condition itself is described in :ref:`NXenvironment`. +type: group +NXsensor(NXobject): + model: + doc: | + Sensor identification code/model number + name: + doc: | + Name for the sensor + short_name: + doc: | + Short name of sensor used e.g. on monitor display program + attached_to: + doc: | + where sensor is attached to ("sample" | "can") + geometry(NXgeometry): + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the beamstop and NXoff_geometry to describe its shape instead + doc: | + Defines the axes for logged vector quantities if they are not the global instrument axes. + measurement: + doc: | + name for measured signal + enumeration: [temperature, pH, magnetic_field, electric_field, current, conductivity, resistance, voltage, pressure, flow, stress, strain, shear, surface_pressure] + type: + doc: | + The type of hardware used for the measurement. + Examples (suggestions but not restrictions): + + :Temperature: + J | K | T | E | R | S | Pt100 | Rh/Fe + :pH: + Hg/Hg2Cl2 | Ag/AgCl | ISFET + :Ion selective electrode: + specify species; e.g. Ca2+ + :Magnetic field: + Hall + :Surface pressure: + wilhelmy plate + run_control(NX_BOOLEAN): + doc: | + Is data collection controlled or synchronised to this quantity: + 1=no, 0=to "value", 1=to "value_deriv1", etc. + high_trip_value(NX_FLOAT): + unit: NX_ANY + doc: | + Upper control bound of sensor reading if using run_control + low_trip_value(NX_FLOAT): + unit: NX_ANY + doc: | + Lower control bound of sensor reading if using run_control + value(NX_FLOAT): + unit: NX_ANY + doc: | + nominal setpoint or average value + - need [n] as may be a vector + dimensions: + dim: [[1, n]] + value_deriv1(NX_FLOAT): + unit: NX_ANY + doc: | + Nominal/average first derivative of value + e.g. strain rate + - same dimensions as "value" (may be a vector) + dimensions: + dim: [[1, ]] + dim_parameters: + ref: ['value'] + value_deriv2(NX_FLOAT): + unit: NX_ANY + doc: | + Nominal/average second derivative of value + - same dimensions as "value" (may be a vector) + dimensions: + dim: [[1, ]] + dim_parameters: + ref: ['value'] + value_log(NXlog): + doc: | + Time history of sensor readings + value_deriv1_log(NXlog): + doc: | + Time history of first derivative of sensor readings + value_deriv2_log(NXlog): + doc: | + Time history of second derivative of sensor readings + external_field_brief: + enumeration: [along beam, across beam, transverse, solenoidal, flow shear gradient, flow vorticity] + external_field_full(NXorientation): + doc: | + For complex external fields not satisfied by External_field_brief + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the sensor when necessary. + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a sensor. + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# df8bc397cbcbf114091b84ed357f6312641ca9abbf2d51795c37802450e7e628 +# +# +# +# +# +# A sensor used to monitor an external condition +# +# The condition itself is described in :ref:`NXenvironment`. +# +# +# Sensor identification code/model number +# +# +# Name for the sensor +# +# +# Short name of sensor used e.g. on monitor display program +# +# +# where sensor is attached to ("sample" | "can") +# +# +# +# Defines the axes for logged vector quantities if they are not the global instrument axes. +# +# +# +# name for measured signal +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The type of hardware used for the measurement. +# Examples (suggestions but not restrictions): +# +# :Temperature: +# J | K | T | E | R | S | Pt100 | Rh/Fe +# :pH: +# Hg/Hg2Cl2 | Ag/AgCl | ISFET +# :Ion selective electrode: +# specify species; e.g. Ca2+ +# :Magnetic field: +# Hall +# :Surface pressure: +# wilhelmy plate +# +# +# +# +# Is data collection controlled or synchronised to this quantity: +# 1=no, 0=to "value", 1=to "value_deriv1", etc. +# +# +# +# +# Upper control bound of sensor reading if using run_control +# +# +# +# +# Lower control bound of sensor reading if using run_control +# +# +# +# +# nominal setpoint or average value +# - need [n] as may be a vector +# +# +# +# +# +# +# +# Nominal/average first derivative of value +# e.g. strain rate +# - same dimensions as "value" (may be a vector) +# +# +# +# +# +# +# +# Nominal/average second derivative of value +# - same dimensions as "value" (may be a vector) +# +# +# +# +# +# +# Time history of sensor readings +# +# +# Time history of first derivative of sensor readings +# +# +# Time history of second derivative of sensor readings +# +# +# +# +# +# +# +# +# +# +# +# +# For complex external fields not satisfied by External_field_brief +# +# +# +# This group describes the shape of the sensor when necessary. +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a sensor. +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# diff --git a/contributed_definitions/NXactuator.nxdl.xml b/contributed_definitions/NXactuator.nxdl.xml index a48ce36a8d..6134cf7e6c 100644 --- a/contributed_definitions/NXactuator.nxdl.xml +++ b/contributed_definitions/NXactuator.nxdl.xml @@ -53,7 +53,7 @@ instrument axes. - + name for measured signal @@ -62,6 +62,7 @@ + @@ -73,7 +74,7 @@ - + The type of hardware used for the actuation. diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 9581302746..4f121bdc30 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -259,8 +259,16 @@ It could be a lot of raw data from a detector. Shpould be optional.--> Manipulator for positioning of the sample. - + + + Thermocouple measuring the sample temperature. + + + + + + @@ -275,8 +283,16 @@ It could be a lot of raw data from a detector. Shpould be optional.--> - + + + Device to heat the sample. + + + + + + @@ -295,16 +311,19 @@ It could be a lot of raw data from a detector. Shpould be optional.--> Amperemeter measuring the drain current of the sample and sample holder. - - - - - - In the case of a fixed current, this is the scalar drain current of the sample - and sample holder. - - - + + + + + + + + + + In the case of a fixed current, this is the scalar drain current of the sample + and sample holder. + + In the case of an experiment in which the current changes and is recorded, @@ -312,11 +331,16 @@ It could be a lot of raw data from a detector. Shpould be optional.--> - + Sensor setting/measuring the voltage applied to sample and sample holder. + + + + + @@ -332,12 +356,16 @@ It could be a lot of raw data from a detector. Shpould be optional.--> - + - This field may also be found in NXinstrument if present. - In that case, this should be a link to /entry/instrument/gas_pressure. + Device to measure the gas pressure around the sample. + + + + + @@ -454,7 +482,7 @@ It could be a lot of raw data from a detector. Shpould be optional.--> - + Details about the method of sample preparation before the MPES experiment. @@ -466,14 +494,14 @@ It could be a lot of raw data from a detector. Shpould be optional.--> Sample temperature (either controlled or just measured). - + Thermocouple measuring the sample temperature. This should be a link to /entry/instrument/manipulator/sample_thermocouple. - + Device to heat the sample. @@ -487,7 +515,7 @@ It could be a lot of raw data from a detector. Shpould be optional.--> - Pressure gauge measuring the gas pressure. + Gauge measuring the gas pressure. This should be a link to /entry/instrument/pressure_gauge. diff --git a/contributed_definitions/nyaml/NXactuator.yaml b/contributed_definitions/nyaml/NXactuator.yaml index 98817a8136..f5986111cf 100644 --- a/contributed_definitions/nyaml/NXactuator.yaml +++ b/contributed_definitions/nyaml/NXactuator.yaml @@ -22,11 +22,11 @@ NXactuator(NXobject): Use the field `depends_on` and :ref:`NXtransformations` to position the beamstop and NXoff_geometry to describe its shape instead doc: | Defines the axes for logged vector quantities if they are not the global instrument axes. - actuation_type: + actuation: doc: | name for measured signal - enumeration: [temperature, pH, magnetic_field, electric_field, conductivity, resistance, voltage, pressure, flow, stress, strain, shear, surface_pressure] - hardware_type: + enumeration: [temperature, pH, magnetic_field, electric_field, current, conductivity, resistance, voltage, pressure, flow, stress, strain, shear, surface_pressure] + type: doc: | The type of hardware used for the actuation. diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 0c3af82fdc..753436563b 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -177,9 +177,13 @@ NXmpes(NXobject): exists: optional doc: | Manipulator for positioning of the sample. - sample_thermocouple(NXactuator): + sample_thermocouple(NXsensor): + exists: recommended + doc: Thermocouple measuring the sample temperature. name: exists: recommended + measurement: + enumeration: [temperature] type: exists: recommended value(NX_FLOAT): @@ -194,9 +198,13 @@ NXmpes(NXobject): doc: | In the case of an experiment in which the temperature is changed and recorded, this is an array of length m of temperatures. - sample_heater(NXsensor): + sample_heater(NXactuator): + exists: recommended + doc: Device to heat the sample. name: exists: recommended + actuation: + enumeration: [temperature] type: exists: recommended value(NX_FLOAT): @@ -211,15 +219,15 @@ NXmpes(NXobject): In the case of an experiment in which the temperature is changed and recorded, this is an array of length m of temperatures. drain_current_amperemeter(NXsensor): - doc: | - Amperemeter measuring the drain current of the sample and sample holder. exists: recommended - amperemeter(NXsensor): - name: - exists: recommended - type: - exists: recommended - value(NX_FLOAT): + doc: Amperemeter measuring the drain current of the sample and sample holder. + name: + exists: recommended + measurement: + enumeration: [current] + type: + exists: recommended + value(NX_FLOAT): exists: recommended unit: NX_CURRENT doc: | @@ -232,10 +240,13 @@ NXmpes(NXobject): In the case of an experiment in which the current changes and is recorded, this is an array of length m of drain currents. sample_bias_voltmeter(NXsensor): + exists: recommended doc: | Sensor setting/measuring the voltage applied to sample and sample holder. name: exists: recommended + measurement: + enumeration: [voltage] type: exists: recommended value(NX_FLOAT): @@ -251,25 +262,27 @@ NXmpes(NXobject): In the case of an experiment in which the bias is changed and recorded, this is an array of length m of voltages. pressure_gauge(NXsensor): + exists: recommended + doc: | + Device to measure the gas pressure around the sample. + name: + exists: recommended + measurement: + enumeration: [pressure] + type: + exists: recommended + value(NX_FLOAT): + exists: recommended + unit: NX_PRESSURE doc: | - This field may also be found in NXinstrument if present. - In that case, this should be a link to /entry/instrument/gas_pressure. - name: - exists: recommended - type: - exists: recommended - value(NX_FLOAT): - exists: recommended - unit: NX_PRESSURE - doc: | - In the case of a fixed gas pressure measurement, this is the scalar gas pressure around - the sample. - value_log(NXlog): - exists: optional - unit: NX_PRESSURE - doc: | - In the case of an experiment in which the gas pressure is changed and recorded, - this is an array of length m of gas pressures. + In the case of a fixed gas pressure measurement, this is the scalar gas pressure around + the sample. + value_log(NXlog): + exists: optional + unit: NX_PRESSURE + doc: | + In the case of an experiment in which the gas pressure is changed and recorded, + this is an array of length m of gas pressures. (NXprocess): exists: recommended doc: | @@ -351,7 +364,7 @@ NXmpes(NXobject): end_time(NX_DATE_TIME): exists: recommended method: - exists: optional + exists: recommended doc: | Details about the method of sample preparation before the MPES experiment. notes: @@ -360,12 +373,12 @@ NXmpes(NXobject): exists: recommended doc: | Sample temperature (either controlled or just measured). - thermocouple(NXactuator): + thermocouple(NXsensor): doc: | Thermocouple measuring the sample temperature. This should be a link to /entry/instrument/manipulator/sample_thermocouple. - sample_heater(NXsensor): + sample_heater(NXactuator): exists: optional doc: | Device to heat the sample. @@ -377,7 +390,7 @@ NXmpes(NXobject): Gas pressure surrounding the sample. pressure_gauge(NXsensor): doc: | - Pressure gauge measuring the gas pressure. + Gauge measuring the gas pressure. This should be a link to /entry/instrument/pressure_gauge. bias(NXenvironment): From b6694dca4fecab51b22b5475c848b399df3f21fb Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 25 Sep 2023 11:09:25 +0200 Subject: [PATCH 0266/1012] Add NXpid to NXactuator --- contributed_definitions/NXactuator.nxdl.xml | 6 ++++++ contributed_definitions/nyaml/NXactuator.yaml | 3 +++ 2 files changed, 9 insertions(+) diff --git a/contributed_definitions/NXactuator.nxdl.xml b/contributed_definitions/NXactuator.nxdl.xml index 6134cf7e6c..349146f115 100644 --- a/contributed_definitions/NXactuator.nxdl.xml +++ b/contributed_definitions/NXactuator.nxdl.xml @@ -144,6 +144,12 @@ For complex external fields not satisfied by External_field_brief + + + If the actuator is PID-controlled, the settings of the PID controller can be + stored here. + + This group describes the shape of the actuator when necessary. diff --git a/contributed_definitions/nyaml/NXactuator.yaml b/contributed_definitions/nyaml/NXactuator.yaml index f5986111cf..685981d6f6 100644 --- a/contributed_definitions/nyaml/NXactuator.yaml +++ b/contributed_definitions/nyaml/NXactuator.yaml @@ -76,6 +76,9 @@ NXactuator(NXobject): external_field_full(NXorientation): doc: | For complex external fields not satisfied by External_field_brief + (NXpid): + doc: | + If the actuator is PID-controlled, the settings of the PID controller can be stored here. (NXoff_geometry): exists: ['min', '0'] doc: | From 7bb3acbd4092c2eb208a1f9ca84fef1eebb75724 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 25 Sep 2023 11:19:07 +0200 Subject: [PATCH 0267/1012] Remove old nxdl code from nyamls --- base_classes/nyaml/NXenvironment.yaml | 77 ---------- base_classes/nyaml/NXinstrument.yaml | 114 +-------------- base_classes/nyaml/NXsensor.yaml | 196 -------------------------- 3 files changed, 1 insertion(+), 386 deletions(-) diff --git a/base_classes/nyaml/NXenvironment.yaml b/base_classes/nyaml/NXenvironment.yaml index 407ace0c0f..436554a9ae 100644 --- a/base_classes/nyaml/NXenvironment.yaml +++ b/base_classes/nyaml/NXenvironment.yaml @@ -42,80 +42,3 @@ NXenvironment(NXobject): Additional information, LabView logs, digital photographs, etc (NXactuator): (NXsensor): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8d95a3f1615f3146244d8f2a05eda98e75a2ca49ffefa97329db446c658f9def -# -# -# -# -# Parameters for controlling external conditions -# -# Apparatus identification code/model number; e.g. OC100 011 -# -# -# Alternative short name, perhaps for dashboard display like a present Seblock name -# -# -# Type of apparatus. This could be the SE codes in scheduling database; e.g. OC/100 -# -# -# Description of the apparatus; e.g. 100mm bore orange cryostat with Roots pump -# -# -# Program controlling the apparatus; e.g. LabView VI name -# -# -# -# The position and orientation of the apparatus. -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# 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. -# -# -# -# -# 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. -# -# -# -# Additional information, LabView logs, digital photographs, etc -# -# -# -# diff --git a/base_classes/nyaml/NXinstrument.yaml b/base_classes/nyaml/NXinstrument.yaml index 1966713b7c..d7061f045f 100644 --- a/base_classes/nyaml/NXinstrument.yaml +++ b/base_classes/nyaml/NXinstrument.yaml @@ -76,116 +76,4 @@ NXinstrument(NXobject): to help define the path to the default dataset to be plotted. See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 331d6037bd4c05402a42cab90e3df4c3115b21231d57ef54b1221e1ed859584d -# -# -# -# -# -# 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. -# -# -# -# Name of instrument -# -# -# -# short name for instrument, perhaps the acronym -# -# -# -# -# -# Energy resolution of the experiment (FWHM or gaussian broadening) -# -# -# -# -# Momentum resolution of the experiment (FWHM) -# -# -# -# -# Angular resolution of the experiment (FWHM) -# -# -# -# -# Spatial resolution of the experiment (Airy disk radius) -# -# -# -# -# Temporal resolution of the experiment (FWHM) -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# + \ No newline at end of file diff --git a/base_classes/nyaml/NXsensor.yaml b/base_classes/nyaml/NXsensor.yaml index c3b780d4ea..e60f2bf1bd 100644 --- a/base_classes/nyaml/NXsensor.yaml +++ b/base_classes/nyaml/NXsensor.yaml @@ -125,199 +125,3 @@ NXsensor(NXobject): and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in other component groups. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# df8bc397cbcbf114091b84ed357f6312641ca9abbf2d51795c37802450e7e628 -# -# -# -# -# -# A sensor used to monitor an external condition -# -# The condition itself is described in :ref:`NXenvironment`. -# -# -# Sensor identification code/model number -# -# -# Name for the sensor -# -# -# Short name of sensor used e.g. on monitor display program -# -# -# where sensor is attached to ("sample" | "can") -# -# -# -# Defines the axes for logged vector quantities if they are not the global instrument axes. -# -# -# -# name for measured signal -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The type of hardware used for the measurement. -# Examples (suggestions but not restrictions): -# -# :Temperature: -# J | K | T | E | R | S | Pt100 | Rh/Fe -# :pH: -# Hg/Hg2Cl2 | Ag/AgCl | ISFET -# :Ion selective electrode: -# specify species; e.g. Ca2+ -# :Magnetic field: -# Hall -# :Surface pressure: -# wilhelmy plate -# -# -# -# -# Is data collection controlled or synchronised to this quantity: -# 1=no, 0=to "value", 1=to "value_deriv1", etc. -# -# -# -# -# Upper control bound of sensor reading if using run_control -# -# -# -# -# Lower control bound of sensor reading if using run_control -# -# -# -# -# nominal setpoint or average value -# - need [n] as may be a vector -# -# -# -# -# -# -# -# Nominal/average first derivative of value -# e.g. strain rate -# - same dimensions as "value" (may be a vector) -# -# -# -# -# -# -# -# Nominal/average second derivative of value -# - same dimensions as "value" (may be a vector) -# -# -# -# -# -# -# Time history of sensor readings -# -# -# Time history of first derivative of sensor readings -# -# -# Time history of second derivative of sensor readings -# -# -# -# -# -# -# -# -# -# -# -# -# For complex external fields not satisfied by External_field_brief -# -# -# -# This group describes the shape of the sensor when necessary. -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a sensor. -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# From 5e641fdccce03e7b300efb6408a5f52ca5e4d96e Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Mon, 25 Sep 2023 11:37:28 +0200 Subject: [PATCH 0268/1012] =?UTF-8?q?Convenience=20functions=20for=20nyaml?= =?UTF-8?q?=20=E2=87=84=20nxdl=20and=20gh=20pages=20build=20(#67)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Add appdef/bc yaml files to gitignore * Improve Makefile for nxdl build * Tricking make to avoid circular dependency * Generalization and cleanup * Change chmod 755 to 644 for NXentry * Reintroduce for-loop for make nyaml * Adds push to github pages * Set correct docs dir * Prepare building * Change id to name * Build and deploy * Push pages to fairmat-docs * Adds clean flag * Use docs folder * Target fairmat branch to rebuild live-docs * Removes old workflows * Updates color and logo * Optimise styling * Add logo padding * Run ci on pr * Adds cleanup ci * Removes yaml files from .gitignore --- .github/nexus-fairmat-gen-docs.yml | 94 ------------------ .github/workflows/fairmat-build-pages.yaml | 45 +++++++++ .github/workflows/fairmat-clean-pages.yaml | 24 +++++ .github/workflows/nexus-fairmat-gen-docs.yml | 98 ------------------- .gitignore | 3 +- Makefile | 41 +++++--- base_classes/NXentry.nxdl.xml | 0 manual/source/_static/to_alabaster.css | 13 ++- manual/source/img/FAIRmat_new.png | Bin 24990 -> 10334 bytes 9 files changed, 108 insertions(+), 210 deletions(-) delete mode 100644 .github/nexus-fairmat-gen-docs.yml create mode 100644 .github/workflows/fairmat-build-pages.yaml create mode 100644 .github/workflows/fairmat-clean-pages.yaml delete mode 100644 .github/workflows/nexus-fairmat-gen-docs.yml mode change 100755 => 100644 base_classes/NXentry.nxdl.xml diff --git a/.github/nexus-fairmat-gen-docs.yml b/.github/nexus-fairmat-gen-docs.yml deleted file mode 100644 index 4d7e3813a4..0000000000 --- a/.github/nexus-fairmat-gen-docs.yml +++ /dev/null @@ -1,94 +0,0 @@ -name: Publish Sphinx Docs to GitHub Pages -on: [push] - -# see: https://sphinx-notes.github.io/pages/ -# see: https://github.com/marketplace/actions/sphinx-to-github-pages - -jobs: - - build: - runs-on: ubuntu-latest - - steps: - - name: Checkout - uses: actions/checkout@master - with: - fetch-depth: 0 # otherwise, you will fail to push refs to dest repo - - - name: Install build requirements - run: | - pip install -r requirements.txt - - name: Diagnostic - run: | - pip list - - name: Run the test suite - run: | - # stops publishing when known problems are found - python utils/test_suite.py - - name: Prepare for out-of-source Sphinx build - run: | - rm -rf ./build - mkdir ./build - python ./utils/build_preparation.py . ./build - - name: Diagnostic - run: | - ls -lAFGh - ls -lAFGh ./build - - name: Install LaTeX - run: | - sudo apt-get update -y && \ - sudo apt-get install -y \ - latexmk \ - texlive-latex-recommended \ - texlive-latex-extra \ - texlive-fonts-recommended - - name: Build impatient guide - run: | - make -C ./build/impatient-guide html latexpdf - ls -lAFGh ./build/impatient-guide/_build/latex/*.pdf - # Copy to documentation source directory - cp \ - ./build/impatient-guide/_build/latex/NXImpatient.pdf \ - ./build/manual/source/_static/ - - name: Build PDF of manual - run: | - # expect next make (PDF) to fail (thus exit 0) - # since nexus.ind not found first time - # extra option for "levels nested too deeply" error - ( \ - make latexpdf \ - LATEXOPTS="--interaction=nonstopmode" \ - -C build/manual \ - || exit 0 \ - ) - # make that missing file - makeindex build/manual/build/latex/nexus.idx - # build the PDF, still a failure will be noted - # but we can ignore it without problem - ( \ - make latexpdf \ - LATEXOPTS="--interaction=nonstopmode" \ - -C build/manual \ - || exit 0\ - ) - # Copy to documentation source directory - cp \ - ./build/manual/build/latex/nexus.pdf \ - ./build/manual/source/_static/NeXusManual.pdf - - name: Include other PDFs - run: | - wget https://github.com/nexusformat/code/raw/master/doc/api/NeXusIntern.pdf -O ./build/manual/source/_static/NeXusIntern.pdf - wget https://github.com/nexusformat/code/raw/master/applications/NXtranslate/docs/NXtranslate.pdf -O ./build/manual/source/_static/NXtranslate.pdf - - name: Build (html) and Commit - uses: sphinx-notes/pages@master - with: - # path to conf.py directory - documentation_path: build/manual/source - - - name: Publish if refs/tags - # remove/comment next line to push right away - if: startsWith(github.ref, 'refs/tags') - uses: ad-m/github-push-action@master - with: - github_token: ${{ secrets.GITHUB_TOKEN }} - branch: gh-pages diff --git a/.github/workflows/fairmat-build-pages.yaml b/.github/workflows/fairmat-build-pages.yaml new file mode 100644 index 0000000000..d228e735fa --- /dev/null +++ b/.github/workflows/fairmat-build-pages.yaml @@ -0,0 +1,45 @@ +name: GH pages fairmat proposal + +on: + push: + branches: [fairmat] + pull_request: + branches: [fairmat] + +jobs: + pages: + runs-on: ubuntu-20.04 + steps: + - name: Checkout Repository + uses: actions/checkout@v2 + with: + fetch-depth: 0 + - name: install dependencies + run: pip install -r requirements.txt + - name: Get branch name + id: branch-name + uses: tj-actions/branch-names@v7 + - name: test + run: make test + - name: prepare + run: make prepare + - name: html + run: make html + - name: Deploy + if: steps.branch-name.outputs.is_default == 'true' + uses: JamesIves/github-pages-deploy-action@v4 + with: + token: ${{ secrets.GITHUB_TOKEN }} + folder: build/manual/build/html + branch: fairmat-docs + target-folder: docs + clean: false + - name: Deploy PR + if: steps.branch-name.outputs.is_default == 'false' + uses: JamesIves/github-pages-deploy-action@v4 + with: + token: ${{ secrets.GITHUB_TOKEN }} + folder: build/manual/build/html + branch: fairmat-docs + target-folder: docs/${{ steps.branch-name.outputs.current_branch }} + clean: false \ No newline at end of file diff --git a/.github/workflows/fairmat-clean-pages.yaml b/.github/workflows/fairmat-clean-pages.yaml new file mode 100644 index 0000000000..b70bd52e14 --- /dev/null +++ b/.github/workflows/fairmat-clean-pages.yaml @@ -0,0 +1,24 @@ +name: GH pages cleanup + +on: + delete: + +jobs: + cleanup: + if: github.event.ref_type == 'branch' + runs-on: ubuntu-latest + steps: + - name: Checkout pages + uses: actions/checkout@v2 + with: + ref: fairmat-docs + persist-credentials: false + fetch-depth: 0 + - name: Remove branch directory + run: rm -rf docs/${{ github.event.ref }} + - name: Commit & Push changes + uses: actions-js/push@master + with: + github_token: ${{ secrets.GITHUB_TOKEN }} + branch: fairmat-docs + message: Fairmat docs cleanup ${date} \ No newline at end of file diff --git a/.github/workflows/nexus-fairmat-gen-docs.yml b/.github/workflows/nexus-fairmat-gen-docs.yml deleted file mode 100644 index 53c001e241..0000000000 --- a/.github/workflows/nexus-fairmat-gen-docs.yml +++ /dev/null @@ -1,98 +0,0 @@ -name: NeXus/FAIRmat-Experimental Sphinx Docs to GitHub Pages -on: - #push: - # branches: - # - fairmat - workflow_dispatch: - -# see: https://sphinx-notes.github.io/pages/ -# see: https://github.com/marketplace/actions/sphinx-to-github-pages - -jobs: - - build: - runs-on: ubuntu-latest - - steps: - - name: Checkout - uses: actions/checkout@fairmat - with: - fetch-depth: 0 # otherwise, you will fail to push refs to dest repo - - #- name: Install build requirements - # run: | - # pip install -r requirements.txt - #- name: Diagnostic - # run: | - # pip list - #- name: Run the test suite - # run: | - # # stops publishing when known problems are found - # python utils/test_suite.py - #- name: Prepare for out-of-source Sphinx build - # run: | - # rm -rf ./build - # mkdir ./build - # python ./utils/build_preparation.py . ./build - #- name: Diagnostic - # run: | - # ls -lAFGh - # ls -lAFGh ./build - #- name: Install LaTeX - # run: | - # sudo apt-get update -y && \ - # sudo apt-get install -y \ - # latexmk \ - # texlive-latex-recommended \ - # texlive-latex-extra \ - # texlive-fonts-recommended - #- name: Build impatient guide - # run: | - # make -C ./build/impatient-guide html latexpdf - # ls -lAFGh ./build/impatient-guide/_build/latex/*.pdf - # # Copy to documentation source directory - # cp \ - # ./build/impatient-guide/_build/latex/NXImpatient.pdf \ - # ./build/manual/source/_static/ - #- name: Build PDF of manual - # run: | - # # expect next make (PDF) to fail (thus exit 0) - # # since nexus.ind not found first time - # # extra option for "levels nested too deeply" error - # ( \ - # make latexpdf \ - # LATEXOPTS="--interaction=nonstopmode" \ - # -C build/manual \ - # || exit 0 \ - # ) - # # make that missing file - # makeindex build/manual/build/latex/nexus.idx - # # build the PDF, still a failure will be noted - # # but we can ignore it without problem - # ( \ - # make latexpdf \ - # LATEXOPTS="--interaction=nonstopmode" \ - # -C build/manual \ - # || exit 0\ - # ) - # # Copy to documentation source directory - # cp \ - # ./build/manual/build/latex/nexus.pdf \ - # ./build/manual/source/_static/NeXusManual.pdf - #- name: Include other PDFs - # run: | - # wget https://github.com/nexusformat/code/raw/master/doc/api/NeXusIntern.pdf -O ./build/manual/source/_static/NeXusIntern.pdf - # wget https://github.com/nexusformat/code/raw/master/applications/NXtranslate/docs/NXtranslate.pdf -O ./build/manual/source/_static/NXtranslate.pdf - #- name: Build (html) and Commit - # uses: sphinx-notes/pages@master - # with: - # # path to conf.py directory - # documentation_path: build/manual/source - - - name: Publish if refs/tags - # remove/comment next line to push right away - if: startsWith(github.ref, 'refs/tags') - uses: ad-m/github-push-action@master - with: - github_token: ${{ secrets.GITHUB_TOKEN }} - branch: gh-pages diff --git a/.gitignore b/.gitignore index 7867d76657..a528d74a75 100644 --- a/.gitignore +++ b/.gitignore @@ -1,5 +1,6 @@ # Hidden files .* +!.github # Python byte / compiled / optimized *.py[cod] @@ -27,4 +28,4 @@ share/python-wheels/ *.egg-info/ .installed.cfg *.egg -MANIFEST +MANIFEST \ No newline at end of file diff --git a/Makefile b/Makefile index aeeba6cddb..812d138a04 100644 --- a/Makefile +++ b/Makefile @@ -6,9 +6,18 @@ PYTHON = python3 SPHINX = sphinx-build BUILD_DIR = "build" -NXDL_DIRS := contributed_definitions applications base_classes +BASE_CLASS_DIR := base_classes +CONTRIB_DIR := contributed_definitions +APPDEF_DIR := applications +NXDL_DIRS := $(BASE_CLASS_DIR) $(CONTRIB_DIR) $(APPDEF_DIR) +NYAML_SUBDIR := nyaml +NYAML_APPENDIX := _parsed -.PHONY: help install style autoformat test clean prepare html pdf impatient-guide all local +NXDL_BC := $(wildcard $(BASE_CLASS_DIR)/*.nxdl.xml) +NXDL_CONTRIB := $(wildcard $(CONTRIB_DIR)/*.nxdl.xml) +NXDL_APPDEF := $(wildcard $(APPDEF_DIR)/*.nxdl.xml) + +.PHONY: help install style autoformat test clean prepare html pdf impatient-guide all local nyaml nxdl help :: @echo "" @@ -52,9 +61,9 @@ clean :: $(RM) -rf $(BUILD_DIR) clean-nyaml :: - for dir in $(NXDL_DIRS); do\ - $(RM) -rf $${dir}/nyaml;\ - done + $(RM) -rf $(BASE_CLASS_DIR)/$(NYAML_SUBDIR) + $(RM) -rf $(APPDEF_DIR)/$(NYAML_SUBDIR) + $(RM) -rf $(CONTRIB_DIR)/$(NYAML_SUBDIR) prepare :: $(PYTHON) -m dev_tools manual --prepare --build-root $(BUILD_DIR) @@ -89,6 +98,18 @@ all :: @echo "HTML built: `ls -lAFgh $(BUILD_DIR)/manual/build/html/index.html`" @echo "PDF built: `ls -lAFgh $(BUILD_DIR)/manual/build/latex/nexus-fairmat.pdf`" +$(BASE_CLASS_DIR)/%.nxdl.xml : $(BASE_CLASS_DIR)/$(NYAML_SUBDIR)/%.yaml + nyaml2nxdl --input-file $< + mv $(BASE_CLASS_DIR)/$(NYAML_SUBDIR)/$*.nxdl.xml $@ + +$(CONTRIB_DIR)/%.nxdl.xml : $(CONTRIB_DIR)/$(NYAML_SUBDIR)/%.yaml + nyaml2nxdl --input-file $< + mv $(CONTRIB_DIR)/$(NYAML_SUBDIR)/$*.nxdl.xml $@ + +$(APPDEF_DIR)/%.nxdl.xml : $(APPDEF_DIR)/$(NYAML_SUBDIR)/%.yaml + nyaml2nxdl --input-file $< + mv $(APPDEF_DIR)/$(NYAML_SUBDIR)/$*.nxdl.xml $@ + NXDLS := $(foreach dir,$(NXDL_DIRS),$(wildcard $(dir)/*.nxdl.xml)) nyaml : $(DIRS) $(NXDLS) for file in $^; do\ @@ -98,15 +119,7 @@ nyaml : $(DIRS) $(NXDLS) mv -- "$${file%.nxdl.xml}_parsed.yaml" "$${file%/*}/nyaml/$${FNAME%.nxdl.xml}.yaml";\ done -NYAMLS := $(foreach dir,$(NXDL_DIRS),$(wildcard $(dir)/nyaml/*.yaml)) -nxdl : $(DIRS) $(NYAMLS) - for file in $^; do\ - mkdir -p "$${file%/*}/nyaml";\ - nyaml2nxdl --input-file $${file};\ - FNAME=$${file##*/};\ - mv -- "$${file%.yaml}.nxdl.xml" "$${file%/*}/../$${FNAME%.yaml}.nxdl.xml";\ - done - +nxdl: $(NXDL_APPDEF) $(NXDL_CONTRIB) $(NXDL_BC) # NeXus - Neutron and X-ray Common Data Format # diff --git a/base_classes/NXentry.nxdl.xml b/base_classes/NXentry.nxdl.xml old mode 100755 new mode 100644 diff --git a/manual/source/_static/to_alabaster.css b/manual/source/_static/to_alabaster.css index 3518cf2f74..cf2c82d789 100644 --- a/manual/source/_static/to_alabaster.css +++ b/manual/source/_static/to_alabaster.css @@ -2,14 +2,21 @@ /* Override sidebar background color default (#FFFFFF) */ .sphinxsidebar { - background: #283593 !important; + background: #55af31 !important; } /* #005F73 is the original NIAC sidebar colour */ +div.document { + margin-top: 0 !important; +} + +div.body { + margin-top: 30px !important; +} + /* Control logo positioning */ .sphinxsidebarwrapper p.logo { - margin-top: -8px !important; - margin-bottom: -8px !important; + padding: 15% !important; text-align: center !important; } diff --git a/manual/source/img/FAIRmat_new.png b/manual/source/img/FAIRmat_new.png index eeddabe3400c469ed1619f50d834533d2afc0303..e5b7158a781f014b5c2a7feeacfc72e32fd507f4 100644 GIT binary patch literal 10334 zcmbVy2{@Ep*zk}r_NGQenqk5_b~2W%W1C5XVvv2T(J;eU2HD3FLa($STgfunUt1xO zrGykAvL>SJTh{;aZrAty|Mzd7>%#M#=RWs#?sK1eIk!xV3^>`&uz^4zPAo?EDhR{~ z27aNe%)p4XKamgk2PR{#Q9vMRk)vM*YQCmF2*kAEZf5CgiMy=oMDmm-IFlS*q^X`{ z02%~R)1;CKPB&b9VU8|t?q2G`OD|pu!`z+Kg)J0uvN*Di%XN25kdKRLkdc{F&N|TK;Y@(OMp>5iCz>{s=Dx>cvXStqhT3g*qgxYZ4|r1-zV7QwR+W(n2ndi4P>?41xXH+=sHn)u%FD>hO92p4lt3?E0#(Y3BJvLg zT^EXzk2~4do#X{O!bor=`T42~1Kj>4h9~)7v|g0IRRt(bhDspI$Vtl{iS;L-v(vwD zWIrF`pTwP=WL$_Yo-SU#6aZH4Us&>Wk}rvJo%Fv!{qN`hL;z4P4)-sO|B@F^&woi! zeD(YRG5%J_e+f-73naV9Ty>$4{Cu2T^!x!fMUJE)tLpf;5PV5KW+W2vpT#oyhh><& zqO>eb97k|+_c{{dxBoE3MVH{~qAq;2Zc?%;Qu6XMDM3NW+1XLb)lu0=>VhIlMM}jb+JP#;>Bzp-g`JKT*2P))?_u}B}J?!Uk&Bv;=6f{%-~ z8=$TK2ZNFU*q1rli+@QX^FIsu=ePf`Z~p-YoWarKzn%zq`PY}ZcmWQ~2k=zqm>!@( zAQ5h?uC^I9^XHd0{?nGF$4z!h_73eg1$4_>?wwEQZbYOvilr%DLV>8PNO=tnP0iC2 zMb#=AUg~VF-eHrs4`1wpV1>P>4=-~jZw;!)h|!p~7YB~D>O9dPFbJ`Nmt$FU&n+!h zsfNF#F+CqS$)%>Y!*hmk0y5XFlat-JWn-D62#-kW;RxkU%%UB)fULJ8BOwR9IttzI<+a9mI z-PA}J9436>Y{(FvigD#svG!vvz95V+!L`9{S6)5e$}E1Q`2>b&RtO70pc#KY`sFEkIu#QwxI7V+{qntP=YfoZv2`Ft5V}} z>++XkVtNaK6iRk2_pEC*{Jy}bbP@te>VoJ_^1vhJIlRN8XiVWwOeSwnLgt!f-7YBV zv7;Gn`Q||v!C=rXYvvzt#QR&5T;)+Ipz=pKSP3-a7rs@H0Pt~y^}!z^i1&90y>=ck z_W-MtUuPKOfq+8AOg`L8(Q=E?Y?c9V4>Dn`0Ngz~po!yf2Bza#rldDA#*Jwu*ZcWpUbfi zdPh1MIecB;4{rJF%Q&XW4$dZoeLGXCQZ;PyrE4SmohX4zFIZ+Un;uxz*i&`jzb{sS z*K?_^FoGL_|rbbOm&zCZ1 zM9UB%r*!Zrb{joqJ{k1*PT90{qY}99gX0sYq9-A#3b#w}A$?gV?=L*ZUJv;wP>FXy zymBaw3;Ddc#r6dS?lUEPb)q+CoO3J6uFvajp6gJusZB}Iej(ftq1|i8C@SU04o=TZ z%kAZz|Eg-2!Z^)Ar z)=A!ZZ{y)&zem2@;1ZI?i=z8`v?%2U(E0c32Jv+xUR-w{cOzwe_l8|Ln8f}vU0oDEgj{drMFGJviAMG z_UIPPcwvJz{cn@Lz+yHG6J8}^^)a1p`l-W0i8BO0^}*n0Jqp@VA#lXa!4hRv?nnt= zdcj3jXUgqNZdV-o@Jk3taJ4>DAn{6upL*#foiO$Lg@bDJONx~{Rw8$RjcVWYVNx)l z0=r!lbjO)$i613Xr_UBl`Mon)a@&z_{k1|%S+7D(O+SYaU$>rt>G^wQ$SmtNrI{+EU9yMYF8*87Gs_#Ttl*bj=4uZG z{L12If0OKQV7A?@>{7Y^jiSS8n^7?(7Uxp5QgoxtV~c!k=SwU8=~}5}fX*HG~)(daEkw2&2Umcf`{LLUYk{B`)o{z z>cM4DP-+g=(C!!J zThFm)DaZ2Z$Zbw^D`;+U`P?GFc-~EO>8SYB#kO9&~!q4Yy$Q$!{XR!>L z=P6zTYVbotdmmcU=qu4l^{BY2hVMzUK|c4IMzt_h9D`hXkgBo0e0tDMbT6moZ+xzm z^J@C`@~KTX0q~1aadfK4SdZTna%VLH*K#gC@&z?25NGdmI^>td7A~?Mb83G1TnP5m z&xP_e(cJxRvCKu1OwjLfR$DGxI7Z$672NZYUud>RO5k$|uXKrL#~jvSefY(fwW_f+ zmtO&EoJiqan|V&8x`FRN&|=CWoN!)}$2P4bQb;7~M+ho$9C352LY&KSEhRco?HCZB z^!^6Pdux|5oSdCbi#mPNi`p&5DqM7-d7bx)**yI>B4jL8w%&ARhaP12HRk|TjveY5 z;kKBUZ(fI5EPSxm8AALhXns)QbQ?eRfG6tA#b(h-K9c4;hw$%G?H?_~01b;gl#f*1 zd9&fb1J3yiqX@*J8<*TGId4A0HwEWJ~dpm99$3}3H4vm%)RK6xg-US=yqda(A~+BzEDQhiD( zai&T~=G$x=jTX$x9zu=lp8mW^a2?ad)ZNcpdezF2bb`z4o3YYpZ&@`#bN_0F0}l;{ z7KBhd`Gq{P4U?vypeV9D88j-9x9+o3Ny(w+eEBBRPe>x9xM~0TgCOBg-$@;2 z)wOZ?Q@k6L-#%!j0Zw~7G^rf#a8F%vqyF`GiAEEHyXj|2%x;^rfh7nLor|FpLM6GZ zA^8Ujg%`3d&M#E8%*I$C$I9bx5A>a_R`J-l<{16f6B%YDUNj{-NoOT#J|0Gv4<=gG zKd{}2JLg?Pnd@}gZlB%7kNVV<{PfD8l@XzF4*l8walX9`+Yeg0yn?Bs&=|Qv{%TYe{HHDeocR03OK})0kw49@kHMXwyG%GE|?1G z{$PE-9B`c)p<`dNlg}U2Yka!4KCQkm+%CPVVzEGXDN@?Km;Y)1;agF{ z3l9>7&UP%PMdg{sxr5p$Vq|{2E)IIT&I_GA_sXsD=UnmhDtY*rfRUigeTpK3M1mfQ*J$CJ%q<&j+ zK!GV{qmnkBo7G*bw;z1Y^MqFV?2A@l9~e#wiP)TY1KqG(QDU$tZ+rv)tZ<$Y3zVB`C+1olwHjA%>ZNm%T&ko1kZ`z{sOI@9@<2xg{V zd_)2XffzMh>6joiizs?)uE~MmaOQ5ZCin5URy7VZCQi?(d7r6$mr7vM$HW<=j&`&% zED{!vpGUmTcb^D~oZ5I--%O)z)1q$#Vwx4-)iBX$Y8OtvI}fwdQO4+EI`t^8)PinE zuSvk+aItPw>_YsmX6!=x-Io);DIMOLmE(|Y`d~3VSMrqz@pvECQSaa2Smm2}!vffO zXU9S}<(h})DSZ~!-|3DtS`aOIoZnF}w`}aA^>HxRkKbdQ-yt!lEcAnQ^e-Gbx3`62{N+Sadx9feL$Dg)Mw+P4O3O2BI%54>UUT zQB3dKWw-z#;x3KWpvsw%M$qxMZH*kmUBYx0d?a7vmo@wNb1AAEj{yeqKbl zxfk@F9;sl`Sn2Eg4Pz-Sma{h+r!N~~F>yE%hO~#ISHDJiQrj7xFN1|;0XM_Mlp~Vy zF`NjQdM^kl}2s7w>>`d(^vA#)AF3*=?W1y@Z=F5vA>%=eLd7AUu_=!g_` zq|#_k#fl#)ujjoJ{`A(>%y#3Sc=$3%A_|W`0O0i`^FJDg}n4NQP{0j@u>yE4R_xERv z??|j?77tAELW9c_;wk!42LmCgCKWtL6!A24!CPiLmQslqFQ#A$&EC;JwPjkiS*f)i zF(&@h2^edj-)pnhZ3`02-yj2j0lACvs&T)qD{* z(ku55r!W4I#{OCmm7XK^`7Zd&Qkb;GDLJ=W`Ish<-zad`t0R zD0Lb$0&={2=;L*EGkfIu=MyWzaa$}@bFWs@Ewx~lI zPPpd51c) z%;HalL3@Un?b0bSFYjvcHulGz=kMr_p2Zz3=oShzw(7{0aFllC@hZ^G6T0$*?2r7y zUl`1i=Vc1ms<$vwO>jhmg}ZVYExJK|@NrO=gi~YVV<9CTNKKboru_-t)wk=|%ONvq z`R$t~$ro9{yDn#XtbYNV^+nOs-%5Dk9_0#g^FWerX=Ems<2xlB)r%iz3J<&&_gGELt&v$tEb3Olir3^J;3)_tPGAq-gH`-jp*j_iU9^yHYLXD zqxu3bn|MoC-A)Trr{8AG^R>EGh|@{pvHVa8h?w`*sMJTx_`( zqF3Wqz7X;5VI)-64qKaFCnRV%rh(BB{jvcwmb4=Y5Lpe>nj#P zD*SMGf!ATkaYDo;)s4kVOQPoyUk5w^*WAMR%WrKSz8h2>0LhEN9DQruTpI=U!>sMr*%9-NHoY6!DzKf#I$6`n zmsjJ*RC~;GS>bRc9U{lE+hywm%0Ut;Kxm^wsfn)|8v4Qv z4-&FV?o`=0@15ujJhkkd-L<#i#&hykkecX%Slk7`ne*`Utm*3^sywbdN+vj6yai-r@xBdy z;YkfOG4dx0TUUs@%s^G{v19!0&6tya2Dkfq^chTt{H5x^n*td$3X<1xJ;EEPUiI}R zKNlVxOT7K%3lYj(j#Vzbs!&pS;bWgth2*S(jlqJn;ZGOUPbEmNAQ=(F4~vS4O0Jk^ z9s3#a8`b!GYh$LAYYPes-iM-wA< zi^^hvO!Vp1)MrQ(c9Rlh?gqU@J<*Y0UPZNReh>GzU+&!89+yUDk@BAlz7?H( z5g&cEB6q8kd=R`KJ)Pk{KzT<_R2V{DAfzrE=R4Z}w)wo02<;Jci&=At}8+HOK;&3|bWKF1bPr;#YW!80qU zP&d-B=vOy-%H_5clcH_&^9f}|FBaD3v|jAi73o=G@;=NmXY)F|P~V3Xl?k6^pT%dA z@;&}&5zX!A{6%-1=BY9d3*Nm&ZRj@*q^H>BG_EhUy`xprKx3@4qum=-z<>t= zk6e{H>!-10=j1-&y{l60;ac{e%A?@{P9%NbL}k-M^f-tBuACs08*HTf}95}+}7 zzj1wr3kBY#1{2ti%~|dIF10?xfC6`5@*47_7az+6>e&hcp;eL+pLvXl;Lh)9O=@pM z2^`Tw_iG31M(;PR&%jV%aw5ass1n9Zhg8rmnDrO6>W7~A(aEW!y*Z(sn!U>c9MH>I zWRry5;i&tyK-GWkl%uDRs2`YpIVOdi6mD{#1#@oE&(?Jvi)Oqz8_{=v*Df`O9I43| znAt*aI~M7(Vjwyxkik^Q&r=%Oi4QLPEIx3xL_@|22>K%Fxl=k5J)dn3zoeDYyBSM> zHpi8=+Sk43d!i)YdMBEd*r^s<-v2lZ6uI877Awy^{`9zn@kEGpwTF)?5Xo}HHXylT zI5zm)Tjegb;ZCW!q-yy=V*}e`OS>7b42k}5NG*S)onqKl+sHUU8GJq+5T0nV}9g%QIx?a`k?r9|j_r|($k>+Kl8*~y>!WdR*8v@fD&4bOYV#0%Ul4H=%v zG_1mQE?pCGy|fyP7gU2TeY}QZuXk=Tt^vO+$5KnsA{NNKc#;!zJl%j!4M7g902OQB zQmJ9Y*P48Ws+Wysg7Vjv+H8r?sUlyQdu^!6^BJ^R`3s96ecr2^kwd-J@oi#p`!@8Y zJ=CO322E3*;}@O%lUSUme7}(e>f*?#oVC2kMIa27WQ%Z83tuIdO}&Af`g{`N^WMap zI`MU;slsA69oUecPlGbREQ)o>-qc^%oM23+mdKZ0oqQoeM2XcPb~fexPJ7iY7Hr7k zN@D}l@j(@Yb56wKb!N~vdvFDIDaiyG5jq^~^Jy+5lYb>p!U=6c}cKttPd z2yf|ZzIb609Dav^ay(mkOBIE?zWEw;U{8Y#ECTf7wxPNnZ2_1rW>*bVP6+H@^(`9mO^rp{ZG{WtBS z%CkSJDf`?INYX`9-}ntRoH6hGx?SlZI5d@H2P9^hCC7`% zvt-*_E%z1xFfE`6*BDI4*HMO%WU+nqancCWU>IWtO$9L=Tz_DLYqXsmt_E6{TmLGQz?0DZ+h_<>ztFf?Swy? zadct2>o7?C;LcA~XYk|lj1(g)nT?MX#Zm6fH$4i(hr@_sSod*&egpzp;YJjgPq-*tp-uN6gaW z;c4wOCggY7oGJ}x1HpjywU~YyQ{AUR7Tc%gDKp9j-+9d4(U_cgj;O%)R(T)G2j0Xh zy&G3zf@rnCJlPZ{bu~AZ`O>4n0?mVE_cN`OAG?@p$Ed{zH!>cG_DaW9aVMz-&aN!_zlA&FZ>G)L$q_eYm zMuNa03fx}c;+7Ty*FF(Jq}POKMN# JDcT|Oe*jcWnZN)5 literal 24990 zcmYIwWk6J2v^L!_4Ba&n0!j*!Lk}SWDk+^((%s#yf^o@cE?l)9QCAs!7L3JMCL5<*TB1qBTk{E_2efh+p%c2p=RsG+Z9 zW!05rWtkkEUt7Mivp_-NNb*aPKzxPM^%y-X$|uJbBXjCkr|*7ne@&-M2Lr#Tajlkw3Q<{mV=@H%D@ePGX2QCA&N&=V5?So_s8J-;JlozS9{IYNp9Ax$e70KGAd7b6cYlJw8XShc7YgO&-f~z^K);?P2Htmw{#)Oo#ug0Vex#6 zpCW}Lt%P~9jwGET-`op3&-5J6#fM5c8@OM@xeS;DS%t^id1s5raldWS*)!F8^n8ta zEi&IG_2I@#Es@twTIFt2ZR`OipK>eBzo@y8;c_!ak;(O!6a?SrmU}gc;7cmL`4SP( zefXjOUP?KdLOkX~u8i~bO29$0eyxbaCL88Dd_TrMAQm;qAb0Z9?!MW)Ll(-d)r#`= zx$P6q3?A4TS%DnQEMtoH60epjG|cfbYANtqDJ{ znN$pTmQk=HIy|FlrX`jZrx)kjt>$iSP~v!;tIq<1TEMnonW`wtp+uuZpal7jR^EXt zxQ+;27Zj8StjIr9&mt*za1q;8>4`k{FKjA&EXv2-`+6uSOejin($78Tc3K0}pKG_B zUTv_=#Wv2Jb{oUke^2R0GZawvuBU~2a*NlAM&WoD;-GRB540%q%f4_f7)^h?S>-M8 zinpz6vht{&Z8##rlp@-A1Q)ubG7euQ7L=Gae9DKO4hF&} zzXy0!q3eudEZCa*JzxESE`t)kk*Bbd_o8JaR2>HSD{;F-e0^fSQnP(}cax{UAXd_q z$arr3XZLQtm1t#kwPor`A?5*;BbzqOgb{|>V z`(wIyL838a^810O{P0`#D96UvXW2CCC%(QX=B@bDgEX1$P!+r>YWxrH`?iqkniZ)2 zsyPdkCn1l&hfqiO@G;obP&so8&(pie?-ze{KBc19K01^f=$Mw|d+|)`%aNQbMjt<^ zpW|z~gFA!NvlBv!=!fi3pUWi+LL9KrUMMcxipGEo>4UdNl0EO+-TJ2by@gfP_E?bf zV(B7I>0a>Fy=Y2Bg;#H61X6YK2naO%l_Wv_*vlH`+}`#yy5}8vl%x^En~_n`WKIWn zk$+DP-e{RXQ{9EOQ6;6iugL7fudB17cqu9bKSPnvj!10`-dswKK#lZZ-q-bNd(&s? zton?&V6Qby@^$Ny24bs%&p7pbcVpCYwLdL@&C~0-l0%w;hWG)wnv-thj;V@yU1Dqb z#_BHJ{1fCadw;%Rz{mz}Xddot_(cmExkrA4>Nd7xc=CpwMS*>Xy7{NU=+*h<> zs>77$E64a9n@d~QlC#Z<45yzqlfVNkn55r3WRnxtZ?@-?ZZ2{f&;kbH?ZusQ@&1JZ z8eNU!`loxo;Xd^FSK&yrn$JE#ylcP54=vvrYVGL5G@Z-k{&n=u0JwOJK^%fkx_?RN zuQjzk1JaOx{X|sSG7glep2P<1Q*xcUxb)x|DztsWmK=omhdCa4mA6deM>=FMvK_V} zknX&XE~;_+w*O&5_^Ch}ZY24oQSngg=I!qG2~K-gA7)+#XFG1B14(*P>pXHcrq;Ks zj~k7ae_3??5(NRn%p$w0{R$X2e9)z+)9CKQ)rNzY@27B{1aJ-@r5DmI*E~r%!U_BP zzPqGchfg&(ZU6^;CCy#v9%)J!}wZnr3dYL%OD%GlSv70F@1$&r1>4rkj4f zY-f*s)tk|Xs=59)>{Z`fAUq;M2W5NgykOuAYz6x~VR^1-dAUSy(ZG!2>kY5?a4h*Um5tq`1LYd`aFgFKVf+aChYU&3yM21*$9jgh)?v3CLTCf$-0g~WRl>K z!(P^J7I>26B1Xu*Mk zzkppa|FG56Ha41uA^JTp#J79*o?+X91b|4xAwX@V)QQkJ zd;+gPk$Qh$D>O9pSllb{sb-MCgG+ML{x{|C#)KV{!g3L#j~71##a4E_6dt`J-zKqd z+ktSkkJRemLk-&=ko$)nksot)2QCNbMA2VOudP&jzijkQ$IL^FQnyLw*3lsRNe>93 z1J2w@x1sgKjyVVPzRAkVs8QS@VW#i?9BEyW=XZy-)ovY6p`k48&xUEANhAzEv!|l5 zykYH>n65HvALb9my(7=PNPyp7HQenRJVaAE()obk+rYlnW0(9AHw+vQb{{xkgi!l5 zs<>XS&TpI}Jz0{LkgSGlpNyXP56@zF1x$!yy0b6_z``rD;HTvt6gViKK4@I)f>q!y zSij0t4uYGW(|HHt4|Fl9w9CkCiBG!g2ce)Wb*g>I$dPs%a`4^Ux2pb=xMZ9MMoCKh36*)j7TscZURE=PxTJySXEh!KXQy}9r5X6 zYIvQ{`fOd;nJJC~?)hT7ESgc`ps2gU=~NO&&*#{+>?o5tA(5HB=^&5l?>HwV9%kCn z)xuFijZAD8v0Srl%nrY#K;+S6J0wT8`tUpoED00O$ZV;(b0(ZMSv;V}VFS3=ud7g{ zBCU9WSGWSC{59^(M+25EtJi1iOkt`%p*9Ehlo~w>>jiE-VH_d5mtZIB)XP;@Fa$rUy!bYHZEg-W(+dU6P*!8cQu5_ zZVe49Mo_T_F|Uk9z_t9$0}{TX3GQO3lIk9*BM*;%GrOzgDoD!3k~-{I}xR-Qqh#>~ASv#9afMhAS!j z>ui$F?9ATc6FA~^$~Z5ekBAt``>rIK^KX5Gi}$+nA9H3RpQk;qLLny%v{$slKx6VH zhP9|FVK9`F8NEFd)ggukS$*Si|Hv?02*(ldL#H%jfuQ6z`Qd+_vhR3hMEp85&jX4k zYg)dn!PB>W=zv~<>&wF0`44{ezOMwM_XCucK!MM!%+jU*Wd3l>>N{TmJ-%f{uc%K@ z-VI*wg3>5UrUeOb`=f?y^GLF@_koH>fdSXS{+Q4%mkr3;cC|8ID30^oG;0_fB``tK z_K`2FzSEi8ZuO%G8m4Sh2aP+`G#AY zMrDM3lMnke@^oD-xaL}dsS1p>d!iZ@izTIs_H(z$C}<&z)1eyu#F_z9MzHSZEDM&mS0Ywm7_Nh=B&R52{wQEOF1)E+B? z9eTVbKq7O`Oo>50`0vKY`kA$lS=XBf4|Yvinx;wM*X3eN2Dn?qEi?D0p^+*Nz!okPeG` zvZcN0luYcoy?**aGtTKdLa~=yWd__ng$LR>>hJ%(c7o;`(bMytoBuoe-=lBdzIX@H&OPQ?Y%Ez zY6$~!s1E8bb5JAXm!{v{wINDi&bjiMF5R^N0>|O}>bw72EHSotyWhd4FIaO#y%+kDqkve|R#7M(Z4lCtf=72-Oq?*0s_COoipnPuJI`V5rcS6yV2 za+4eYOsoMXHQ>V?-VMYoC}{$^L>jNjKn%`ALHpjTWmdN**#@Wk;r3pIh%cl)PgQO& z{b{paMsz?NSI~|BSgt_jyVATkZhFh!ux6Wu4{*A>izs`&th@GNT(X&C5UL*aDtq$h ztzt6|@lgf-g|Rx!H=#S-xk1hwE2w~-^-8P`XSc#zlDHErZ{%dW3NqOw(DnFv9bzM# z^$kg!90Lu}N{3RTRYJx2n71T^4A*0&k)Y8ir$Cfn5v5JCgoG72Qxae8^7NHoWh?$FeFTz2SNqiCSq`_M_4i@=1j~OBNxU?N#Qlp7*5s-YSm)4x zt;TtOMV-{&(fHWMXGET*woLu+(#C41||6R^bYb|FAXUbC6RVnUF{ zhBoiA;UBko6>`@MzyakFM3J&))fx2>t-3z``HhW)HmjnzK(eUFbB3aYMM86P6y3iT zgRb7ThcTDzP6s-EqlyqPZOsPpId1pQ;+nA7kW}+VeHIldG|{HsGY?-s_^bK@`sZGo z9|Qa)6SH`6Ys3(J({pQsVM$;&)}w&-a_>x!WuDH+T_hf{5k6=Yi=V4Pe9` zacb+-g>Ie0tBkvayEh;dx()3Ea&hfza$sZsVt+1{PN`B}L@Kkict5x9`8iQpS!#>l z3H#@NHq8>d-EH5d{SrB4=;cAe?Nqy>lZq*m1feO%bH$YYgSrlo*--{6*(I|N7Gkb`+jZZX${GmsSeC)}d7;J4djTl-@Y%3b; z7thf8#-a`jP49B62--2Xh?>;*Xz-pcmVwm|k__M6m@3-ty|nPdE;DY}gMnUR}7{@6E&ZjvJILkqJ*W09++-UMLq5TFu zG+W?&t!kH)sDs$Zz)~u-+}YA<6R)|qmFS+z-zY)*%;Vqa!D;O1*>M#i*&N(t{+KTm z#fNB=B>2Ik-}VNhF$ukCL#H>1%INXMiVo%YiVwgC6MenhE{X zrK|yAOM~TAHW=01H5Q^ozkAwMNKwz4Nw2yyA+Wt8$fXIB%lM%E3Cr8c945rfI;IgS zK%I5mErUF*-6*zb>b2o+qhjEgms2S{>5W(pa7nF+XUQDct?vHbRn{}hjUg`+tFxad zHXRg8|Aw`6U~$YBdv-RQuBhUEdJNty2zL-!Rnnj})hX$F&*KZ(8m!Di0dY<3w5&$1 zL>g^;*DmTg2~ToUK}fwixqWI)7s;>!+jgIn1vuBiFfys{G$oOJtXMxwXq4=q*Wp;j zYidz6^Ca*jkl{j;L{fN??iV=2>c@B;Lu-@zb&~tQ<|BGts4Ig0SSL-~kN4F2FFg*{ zTCP%v8^>EQb3kEV1(TLA3RWCTXq75y=!)z_pbRU&c;$mtF~S3<)IfI09USte!klC+ zb-Qb8AzA&VF&JKuziUUKMZG>;Z^@Q1b$;%kxAr;spNfUFCR)BaNx3%yor;`kCVC|pnbp2nlIPz0U zg1iDLVJ;-l9$WpAWLvr|=Fyt&B*Ny^@;m?Pl&>0t8;_7E>dz^UXMvNzgX1gEXwW72fgdfl! zSO>*MBqdFV2je`9b!3ws2O;L+pPcSavlH>)Tm(+gZB^j7jq%3}1ALfZ9mz;+ArXDf z{!b2zOCkhL%W^Hg{`RBX?FA=_5Ec_UjPTHXYK8 zF0Z|p;5NRz|BtEVgH5WgJFrcWAPF`F&{YSH6$?qo^zi!kuWBumb&I1sDZS*lQ`7|J zEY5lInzT;cwU3n3+t6941sF3UqDa>`pahEJ;>PGF3Qh=j$*qN_EPwT|4)91*CY(&~9qR`yz&jarFDZx>s zs@zx}P=^p9RL48IEpHM>9UWp8;-aFCrvYVm>k)oe9FR!YLUxL^lWSt*oE(K9coHvG z@=w$!VnMxhQ^EbU1)~!fX|A`ZZ{J~iwg&zf@KH7$4yG=zwqNw=H`Fq=UPhId;RUfJ zeJISR)80w~VaM?h`+))4_>Yr^5Wxzq+#0C$Yb!Wu6z-z@TU~o#eOZrhL(*@;K{aE z1uw(edXIyO7KOT2FW>M6g&l<$Ksa3hkRUf6)+erePTn#P)+r2D5-svD0gYJ)N*dJa z14cn!`@kFL1MU~U*9ub<8i%1>1oFVaVLtzNi-;*g^4q&9tWE(<$#OZkU&sa zKyR+2LiYAxd07#%W~aIsmeshg&ZG{bvN&;JO@7asJy~2w zwzXwU&mzx+vNQWtl!JgZ(~LNQ)>KKEe^iiBt7r^ob}FUH2fDgzDo==wT3TB#OI{h! z=Wz8HhYHA}QRC~ugg~m3mk(>H;(?&(=?9fQ3u<%;dzasCv^2eagc=s+TTB*2GE9b> zRJ0Fn7Z)<{I%UD>g652n6xaAa zB*R%B<_`X}{X$~@Jy?Ie<~ByL0~V1l3P$*Z_aCqeA1QxpkJjf_M&D3=Tz=?|WB0k* zZ`S59E+%I6GA;-tYo?Nlq6(WhzwrI64go$Zn{O~anDesus3P%HMoS{GntW?ZbD#dL zAo0u<{|%mZaRv7y{qy(xOk!eRT0+XoGP+o_*uKd|?6qu57b3^0y1oI)kkI2u;DE^e zzQ_KA-~&LcCh)*PI4O0r2c8seG+vcEWc34mXP$C#d3KSogphmM`k z<$moyc2CAN?7L}%?a4m!$a;3rRZY|r5@I_7TLDoECfZs*xFlQOOk381Oo(Fu^_c*q zqA0!{bA7$#N_>14^CrOA`82zahRwwTrxB#?%;sVGzNsd{!E>TmE~p@$ zewa~S{WFR7;74nX+wu(3TTufIb;B`P5lc(khMq|80o4GU`lySpGSY6DHDHrnMD0^V(z}ydFMG%a1j95 z>O*y^i z@s5(a+nvBXB~sPjN6*sC(vOz0Ym8n@SE*k_JF%A16XmuV+%AS1f8Ihz9W&u|E6egeP?(Z~ z6Sc*#I|ZZP6oE{VW5#5H_Bpw7IRGgWO^*uXG@BPY zid5j6w?cbd{~&fVxff7>!kt&j^)Wwn{~R~i%*;PoQi3ZCf@IZ307?F z$$2*|=yyGsu2g7GA{o9f&#L`m5r9r&%bqce4+9wHmS{%4c|PsIfZ_m&07>azGq}@y zECO6%2LxV!Oa;v$MYHuM%hDx`do{in)|DX*F^*bAV!qO3hxlG@Ey^|Byk$X^cPX`r3GQ9tJKWd;Fnb(^VdWsP^ zm=TyW*{pg5FJuMm6rN!$D#1kPWavV-LykI7+3=E`+NSB(tcS?LA8O=0rFyY%J{((v zprRq-;3R7Mdsgt<(_S@!{5b?y+yMv43M^*sm6oE?&~#npHQKzHv$}y@lTk(}GNE)C z>uaL9x+wvFdBS83_+x@&F=CYTzM^IyUW0y};Lpv)xpAr*6n@nChT2|Gkt*Hfd!C#e z*y`i9sy&LY7g{@}$oUM`A3c~fF?J2#`vc{w9Mhwby?3vN_t{@Wq}?J-V~#yPF6#Iw zQ?GbRE-#QB>T=ncHAT4Lv$ZT;>9KKBTE@S}5A3&>2y>niaIkEseOZ+Gq=278{KcI| z(B)&$7v~dx|2vbSx;{L?2LNnmC1b)@o3`9>6RV$T zCi-i##Kmmvl>iL^t+BBJwNWB2jtmEyj|9NZb?(rE<&U)l8eJx+(E>q5F%y|px!QXA zujp8peX7E%Hi^1g)9IJs` zL?Uu4PXZ_J_rginyByx7<^F^8@@S2;$hQVfme2k+*2&v588Ra<4y|1nO<@uPKMdjN zv&3QRGZd(Cvt|y=n@{4m%P3OXlJLBJVDT|zjDxEH9tqX{Xs7@v4X7*S!ADU+ z+ZjEt?8oqwVk3Uwl95N@SV6U#hUpdke$lF0Pf%xmDY>E#kE1)JBSJ$pUY2B% z%Bg2!xj6j&VHS@X3kWf54fYn|TBFqnFw>F$l9!+@2{%2xDNFzpZOpMzF4WV$5|U`X zfUJfPD&9v@SUij@Ak$tghD!6T&7M%KY@12+Mvq{Vk)f29ezRk0V3#t&>7UY?GK~dZ zEG#VN#Qq5@UxPT&U5qYEjrZHY0hfBlUS9TU_oH?>9tHf5zj@fI)!Jn5&w zWxUCkT4<;%TN=YsOnIyB=pz!?-F>wb!vDb7*zTXcUW5(G)*eMUoPjIRQR5kUh0*J+ zw*!D#uO~>{4JbuL$6$CvpBE3}@4OP+^R&u&O2-9bf5wz}0AwmrQ3Czogol}ha9)%J zC3SM-`A08=(eBUP_~(9%FO7$Ziez<6RfgN8Uk@%P07;v`LerByh(%i7W(sASzW0a~ z^di;p@6jc0t-GUVJfh}@ML#A0eHfICn(jagX1YaPH}LTg{$xe0{-WnsVE5Zz1>?#4 zvX|rl$x)c8H?#j%K)u7gW{;YUx2ytjh{+#S-KKJr4eg=GuyrYA2Wt zKe!4S*EHUHiHDJYbXJY-xr%90Cj=p7PXmlGeELWV?#-f~a)RLjb*;Xfv3|MSnI{X^ zqR2tbXTXXt{K;W;vjbCy^{aY`CN>YIwT0aJn zf`M*aHtwhXcrm2!)<7wz#v+*|XyI)yo$(}TtUFsMRq{YevGIEJyHBRZ68`gAy(A;a z9qZvb>z~m|3|QHvp;_8U6r_VA&eQuxJPFru_ z{4zegK*@-6i;UE%M4hT)T((}>b6~#jNk$Shg55APz-%T%dsq>H_ycM&VEc-y zCyUsFGQ=|`2z6U*+c{eQ5N&`vToVeYzu=>qcvvxz7Xun^rM9#I<>P$64`dDaxcF2^ zw@!suwZctJ&;36FQ7~e9=&cge1zIc-oMUCz2V@VR3nVe|&2enDe3-C(b$k^R zjkjcG5H(4Yn7TXwsa0JQkw)7 zG(kcQvtk{sdj{~2M?-(>^yiAG4bw?fS2x@$ICp-;6EId9v1`bZ}|Z(fRU)O}^y!EX*|^uV1n8DeDR?qcUkhsHsimrCph{UdL)K z)p2?Q9eq?mTv%|lDwndXEU?j~$H6q9UGp6vChggGAiz9>g(mgVt%@O(wD#w`eR>9i z+R(EiUto_eJrKn+1^j}d7O5y0UXmXN4`Hh2JaDH(M=b)?`9k-~TlyP3AndGsMmM@v z{*LqO*1uXaP3&D8`eNjy0&>W)eIcF7uBy?=9#))xYo-M4A$8`Z(aS{ZBl{NDP zZ4n&~3N}$BIhr4~C`q|6OQwLp<`F#x5H-`AwJ$r?Q8l0Sd@L~KNkL&P<%IS|1Fj1a zlYHWv9-m75YEjeFnr~p0Cb0V3k}_!T&vDI7JvM4EJg=ybZRkFeLFW-?&eIAM&1a3y zKf-icSBXn22=+NFbjMgqTMgNm|6snuPZNEyqkR9THqh3LUh2xXqsgO%?!#$|D&FsR z>{CWBTNdoYg-z=f?7n{Z0MbLHmQ&sMl3IJPVgDesIVC#Y)Bo|d+a);x7gRw(q+C?l z>(BE`B3D)|*+@sNxKuI)&28KSMFK;Y##H*l>!Fi7lP!{wUQ%4Ziab2Z^tt&{ z-#Y*LjwAR8tz64V=2h&9noJ$_W94+TAc%~DB6tj_JSl){&=slTFq{2%0cbxmIJnq& z$Tv{^dpF`-Lj)YKPMq@_5G;XZATlf=|E6=FpTFy|6cExw6A=ZDFd_M1WnSdZrV;;s z_Ew-R`i2}XO5)#eTev)3=>@5{%yJLN5`eK1v!=Ah#u3Y?%%S}%FW%sMj@!`(cMd^3jkM$HD(+aW@n2dKvX|Um26)Vt@c} zn9J6kqZZfDv5~=>3KMC>NGIe?T_tGDVi`z7o0F7+q9z-Tm z!$}miin9NkIS&W4En)!15c{wVWx-)81R@g~{OGE<2Kq@)mpD39BQgP7SvgR^Dzpp+ zrt?5Z$dvuDL{>d`A9hrf%nKWV4qWEYl8|{G_xPi~-D>=K2%P9+*F1h(8y$QZoG~%A z4>Oz(I7!6%z?#if+43H>g7AXFESCV_RI5*q8XtH-OsiZy$H3s23rx(g1j(ejhj|ky zKp{g-Gg-YLvmb%O{CCYghJK|*eC&@J2Q)u?0QUShp!Z&nx218IYgQa1>6eqCp9Mjg zimH}+rcSA3G8u|ojA>LK>$jguN)?#$!E!p4rncqfF+3@u5UBm&P|xrKq{6G2lG;r& z0xt0=D|f5y6+c00FEZ9|X7Ffe_z{Jins^@GtF4tKj} zn!vain4k0>uK~A^>Di?at4mKuj=_PWC{8NVe~xs=wvZBMMiqz!D4P&rADqqy4i!Bl zXXL@c2Ix!jp`0Hb(TdUSJ@5AYfZL}x1i>yMK%-*=%b|ksB#Uz4b8w-Tm2CukAIn5v zJ<@fF21&MF|5OSp^5@Cl*jmre#^$!-Y|JI~sF$ znn>1vt_|=LR&9FHL@30Jk00r*z~i1+&2ti9hEFzev9gwWVMya>kcY8m`k|w5onCN2 zO`n{+b+=nokN6=Wd9nltH7f;8Qkmy6wEQ0c5xV>HBK31!$L9bktlRB&*8mA+S7Cze z_Hf~>h-%{#f(ourtgA_{{)jt)p|}48cFFj6KxB@izA`s8l8I~K5D>4A_A#<s?jZ2}XQu;m=4bzp*(y473Vak;99?S}R>_i9E+pmxhsu z*e20Uj9_P$)%lT)zlJTB*OG2GcyHdY%!K-5-c)28dZKRaS@OvAAo&MM#uLU``N(mS z;kF>uFYn(c`kwQOPk-d}x=P)3pb`%toYbE??ER@Abc4sq8Cy6-`r-w^4OEcH3>l~+qs^;Zj4x7+)p(%%ZLO+b&;;d`Cni0QUT)dG{Kah)S;{s25Z0dnYO=TG z+8RDPRCZTqUpG%^PAO=;xog4V_pIJ)v^HZJop7D5R{U!e@^@?u<=gK-UB4jr_L0Yq ze3bvLKh8bpK35M>v1whlXxNV5RpRmwvvd9LJ6ND``(buPA2xRL1jC_fd$1(Px&C4C zL?>1C?M6Gf-?E0@DzvIUV|Bm(AUVSjef6c_?i~Zxn506~Rg*{NqCqJS;zPjPCf7QA0(^B@5hy&W& zxpHA!a;{5j$YrBmYoQra_~7BM?^EbN=j_nd$cqPp@r#|*QIA|=komc0#&v)Jil?V( z=R5$Q!&n-Y-qC4hoNU$ybAPGXl~IX}hYuP!Mp(1`B&!8LZ&ENS(hKp>0Mmo z0UXuG$`x~_L@YvQsyMc*HSXbXnsEuUSjacGv$Ia4o<=80dd+UtjY8BPJ9&31#L|cHmiJVbSzlC|w@v9&4c{P@2Y+ zT-MZt!r`IyCsU+jk%gc|Npj#DC>-Y@BFU8%HA!zsqW+anqj+tA(zW6w8|oRLO&ouF z%gv8Z*_r()2a~z_>pIDui)hf=+6ubYwSR77dI~g(>>La0U@zzHTRi3-Y>RRetfUR+ zQSy6|VL2A0N}1poPjS|A6Tr~+@fZG9#pH;r=}0Xz>uX$wNa3S_=578?_RPO9=YJ?8 zZqIIi7jtk>gp)7%%OYKZq=MelEScGXl&0T0j(Xf_1?zdwxkyQ!ad`DZw^x z?C8X@k28Li`+-3b)*WBLZ6dnRX5b1;`A^MJQ-*1d&QC|woVqVQQLdn&!*CT}bQ=3g z4EP%b2ffmhhV?9MIAB9U>ZLd2ZnL05k2$^T}H^%FUaS3I`BYUGbiD!?D=(L(wZT}k!*o{A9A z-FD1zgD2;(;IQ)h18Vu9`)!k- z(E-PI!^jFD3+JO|%%_w^rav<=)(u)luy+;)#=2mi0eUG?A@r*Iw7;RWadv$0I2Xah zZ#Gi9YJ{KNvB8-V>v2d=&oY?^+H3*R2wHeK)@I9l47LG$f?&LW_yb1~aYe{6lR{qs z(BbqB)eqY{&XLWG5|^&HkXH{@zlz0|t_rtgbNrpm8&3kor6bBMR}nYEBE!LMYNA@T z1ATsEz1db@-!|~adF`M?+5`Br@{Ky)lg-4?)GM%WZe{K=W6}q{4Bd<~>VLA7ON&VOpfoZJ+ndkDt$&V#5b8Ha4S-=`YFq7ac_c zPu+8ClF?Ql=zMq*BF2htz@_~cM~3-JO0Ek7PoVM>durfA3nGfr~9?2u9qC|>uNfXb` z*UwqlBm6O=F`(R!#VE{vi8Ue&`7?SV*;-ozhk8V*l023z2=fswv$4tKT#l9}HX=L} z6o3!KV)|qgwqME;y_I^Sx-8Aj!DU7m8$EPS&s6ETk}3iYCaWl}f+vBSYz!vqs&U_P zSjm{rRNj`W6-U8pgkcOiG}Tv-E4HI~K>OeG;2(}i=~^$ODx_OGSRRm)h|sZEW-_bseHFE* zQP!&HP|hLl0no=~mnH_-e%*Ma)@0si`{4QTIvEcC%8^qb^x}aVXt=|G=~h|~eh*_8 zdegI_7JSLurK`DR!@m6C6Xbm0Db*hs>TRU8=`ic;9(Cr02Moh}JMf#lmexb>j6p_ajYXzPz5&=E30U^aC^?!=*FI>ct@V>m=}YJ3TOfd3PPRo zi%nw#XVjS=N!pHsK$B2!H$*D+*|VPGX2kIL2cN81#g@yPq>I_0z!~Wb(KqWIvK`{D zphzL6KZXL?MrKl2NA_tpFgp4m0Dk4$)vDI7Q(A&^H?p$@5wp_Ot$3Zb5(%PE>8Dwq znbRdvJKtAf&TSz87q1O&mRAQbhlQEGnVh3(t6lx;EZJi2`{iZVL&$?9J#{AcZ?J>z zb29NIM2-|ASXhbfm&B0=@-oMOjR5(mQ{9*<%l^Z`pQ9_so`4tGls_FKUuc&Ue~c%p zR*~-a#C5Z40G$IcyGNz`GD|l{IT~~0`I$P#NCv8^Q)|KO-j;&zGv~Ycao070__dvb z9H0mU+3y?)%KBI>X;R-}{nEz42-P>RY-);~&DeL1wtdK%bS9+rB8tA!IJ$th>o_WeGh!nA`N=n`17}+e5_Dby1qx_XglJ13LK09!1MWXHv67R!DT}7L+C*OTtwPSs_YIwPYkcGf2YWqsCKq|! zJ6y+=QkH*&0IWIc{U_BqK`(hSx>Z*f`JPb9j77BReJ!(f6|Mt#i(b$}*&q|T3aM~< z+p~h&sq%LG{t@h&+P*d9}On{wQl2hD-W4?kzLbtmMfGYg8QI2LpCg?XXx$#bAXZwpE&%*2pzT6$Evf`v( zU6^&p1L$@2#z1t$e!5N0$kW8tOc%EBd$lcozKE#!1NxIEYxpn7>#~wtTIP*h96l~| zaY)?__Za|Kzgjcvx;(BUBof*9{X4+4(gB5faI;XaahRRnXM!cSZFPP#to8$dar=;` zd+1K5YJ+1F-|Ff>Pa~wIEhJZJtgM^q{kUds`(5*0WrOw}v0VhZPLpfuW`dG$p8sK3 z+YKI3-;rN%h+Uxb2c1FD73!<9ZH!5UqUae_{MhSCfeE@xE{h0$C_g~BpW?2PQ z!d2hRzb~HeI|N;&Tl#^1h+8=q)E^&WCNteJNXob*##7%cE;um8fjTpul#4=uKW2jB zP9*GJ-0sLjgZpPfO)rJT?15IP_V#C$dg^sH13=Gt07P$oj6Ea37VNbIs-{=DOGDX7=T)Rcl%jzzJcOFV>)-qECEFm}{^M;ozOl7D05%ZQ` zi`laSy^=-6ssK*@fQ`&egfBuuc=^K@mDC@1H4a?l-lCu|h9Lhh!2TKvpdj#`k-1nd z$T8f@%i1VEP^5iih*SYiZAlO4&ZwhEDD%5*j0Amt(C}{b%n_^dgCzS-}B)VPWXL zRc~MUbCO(04U7w~Qb0;MJO{vZ`nxI(XR}zVS6;)y8HG8N~eZc;YO?DMg2r<&Z6=k-p)4$o1Ic*~j`npEISh;^L0;jmyORcY{7 zjy?~5ZAYNC07{?*)%ecr)n?tHs+c7-baH=JzbY$eX0ShzSz1r{+U$@8MzWAYE`f6R zbbx+UwYLo~VPp12hc`X6^I*KF+HW-;Bp^icMt@A##r?(g)s8#S-fCSV1y~gv;3yF>CTMiIPT@VOfvXF1BWCm0ynh_vNLc)`M`guLpwJu@}`{pU3abobl8aDnDuS0Htu&A3IG?pM{h zB0}U*xVXrFt>BSYyGurtngbMDWsxjrd<=L?Tak+Vgi}R=+#bM=cFP}K(~^^rhI-*5 z003RKehtQO#_3$3vxh4MgcGc zJ?0z^9>6`jvp!EhVy!p8P z3n`ZTX~;6>dtO|vVR)2tKU4q~gHW7YVFJ=dL0yr2BgqIE?gqs_qWcJi2>X)_`8MR$ zH%l5S!a&fK0e%xhzS|BW&ag7dJoZtMC1M17VzQb@VQlH2B1{EQ5TVVi;2s-UUi_{H zx(^vScrfig>tjok)Soo`6OpmjTod-^H3qv^#PGleE<^XUT491{sC?(I{yf)sW~u|0 z3WDpu3LUW@CAKEX z5+Vu{lfB83HIy)fvPQN+WGUH_Eo5tuEz9prpI)!;@84&hdG2%XJ@=gRe!tIoYH>eb z7t+77mJF$>ZSB!3)J{Iaug8XuFgomyfXTZ9_CjzyG(5liKspy(b*VT ztpUvzAl-eSbdqc^l*X9SHvS^pr_P<+LT8*x(_d<#_dKPkX}smt4sq(s4cXClqfTUm z;TvI`{8_PlD;p%S9x&|+llEm|hXRqO{zPi^`wx--0UBsQ;f&3;x>xjPPd72l8F)83 z^oOS0BM8YIC8dtSSCF8KD zaoZ*}&>m2pju?lR28kP2bM5o}&m+RV25alY3SFe{$ zObUD(98Xw4cZrF}VjxC@n3fK%D$stDH#H(M8^{t+tdv&oeNJi63lZrh2ye{qx+G z1V}hq`mv_Y1qH7{UlRznsWaWII2W}jB(#gjtVKC-UZCeW?p|$b29juURXj?Mv6g=% zol*_iWGmSuZ3Ct7hswM+H-MG^BsY!IkRr4nE=}G?A}rDkvI;3tI<{i{17WS`upf>+ zhG%fW7UrUY2KpMdYT?<7*7F$=_$&OAkfY(2>wQei0*_8GA#48f`a<-Yw$RYXSegm| zc)!}=20P%;!tNfKI#uyH)F+g`{ppYfCGvCEUPm}wV?VCOW2hf{%URFx!neL=Q=B-C@Xhwour@CNQOdE^^=L(6k3)wEh*Zbi=&cf z>6V?HJ)G>pV&myKfX^Z(y5D!lZ|^ciW#Np9Z-Ib;HnowNSmLzlLXv)Z>o4)l(<@#w zNCtf|o<10$<$IB!a^i~bQ)_~{A@a3bZfM&pi$BBNSi1K_<1z;? zR9zD9zZ7DK$ACun9`+AjNT2VzE>S|JHk z*w}eFf!TEvFr};~`cVYbnMclzoR{9(D1(vv3W`!z%=SaW3)v>`?W|qR54CCm*;Eo3 zqxToY->ZQ)!$1=Lb*<0|2>Ay8yCkF47ba)$$Bp*uyHba;UN19}h1pbQGC>J1Z>G=3 z+Ry_jG%RxKG4~Ue6*cOUlyhCFr8(tmlwV55F+W)J55~&#IoMk z&)yBF2N}ndGA5#9VAwZC3=?<>{-|or;^tORb}xXovn$B%Ah73olG5Lfx;=jR z>u6UB3eKKqO?!Ka7S>3%d1q-@nUU$dbyte-0*1Lw$L;kgLuE6}?ylWWj*HMHbSlZu zGhJCj?I{a2O)lX=Xu|IK2GdFen_vEE=z#)+FtOUcGA`!-1MBE5JfdIWa{YviYvCn} zwD9%cwCvi;|G6atw8qGgDde;BvVL(^9*k7kUggupgJPIXMYbPeZ<;e@xWHLqfYbPW zCkCb;_FnwwB4!dVu;?=j^%);aFPjWzIdQ^yQ%3vW6)a67lKBNpE{dyKmFH@Fk`b%W5pmjk8AnJNcP70q8q0 zkZ3}Uq67o&;t+4}!9Ac--p)4O37n!TvI_kYee&-#;u_H8&@XK6*g6@#(XP2Kh1Yc? z(r6vSIMc=pYX6zPEo>~9hm{$$@wkrqs*N-BQmY%Mc0VOut?~K##+9`@k$;@fi-qia z+V-7FsIcvXf7Xz1`uB-7o8F3rxudYDik?ZH zVzrJdQ8H5je>V9+T9k)kn3mRTmsy>+Qj*pgGH!aIPM_^CO$-97aWA?S9dwZz&D*l$ z(;u`XsPU}Ffjx$I#w@PtWlB=9S(y{5s0Sb21H#w{4r6&N>U~yOCoIAV%jX&0bAC@ zRqJBLk!9o5hNT(pDs^b(?n&;tZX~uN^Q)0LqE}3@Pny(lRx!?MpIgf+b zj@dPNg=3#%^Wr4p-paly$Oohv1m!$9SVh`d1V(QQ@M5q4c1<^4ocht}8M=e7Z$+3A z3nD^A*24UyWE$R(LB5bQQJO^_7&tg^WkT{VWcU>?RVX ztA;&3A(oS9Lo6jTW7BUzzp|U@4_~ggPvhVSj7-I=112V22iSLbp z=S4FgNHkhKd_+*Q<9&H_cE4`f{GI2RB|B88J_T@+$4q(rT5r@#RTA|sr16lMhuV3%%21D$ux zv!$X(yWBj##|PqDOJ9XkK&~L-{s{|}l$u$IdT|L+F$_}CBdPoVcA872=ax0re^*N- zVfS}(h9dsPv0QWnOfn}Vt&W41xQ@y7EXYlW=d%7~=-ecq&Ykt4Ulq?Qi&(W^Unw4V zk?lCC=4|!+Zz%l5()WpHax2;MSPkc|g>xlf|5Xe-j`K5@{{Qb5L32BD%UHy`dyojPm!x zj3qKvgzVb+o@$Bu7ZbIF*zSv2jDW>`p#rtwgLAxJlm*C5*`rQlb041Y04z=V>v=5( zVGuvw^e#TmVvS~WfBc|)w&@zFE^yo|Reb#(JT{Ofkk5Md&fUZvXr1YEm=Sca)q8`w z9p@jX3?SDSJ|j_LDdno0H>n<8K*)oKx>SkUciAz%^S^sPHwo{@0>vRAk@JMH1U}2DV|1UP$G#Xc{U1?t9Tg#cJkAz89Cz=U%6q+-T#4o; z&x9I;@6`@&#@JJCzQ@5$d^C)v^xSmi+FWwJ(1Ht(C(q=;r-&VoPp+iokJ*XpySu_} zJUWsWs2__yWd}}8Lz+8L0otm6br3}kiZt)BEDxsZrQGq4)k7>9C_SQ2JAj1`_Zt>HdPgiw`(A@Y@=jzmD7X>F| zeqOdqJ6fF@u;Axcy;)iBaHSn_s!;;$RW4@EBYGU`};CIIisEJs0feP!8kWMQaBz$8QFw@=M&4RV-6S4!mmT%hq4 z+yxOd8GOh<5mYu>m5IzSP|+SPQ%(&}Ni)l!pi%&mJSca*4Ot&70gv`I5go?}r}%4` zPos2qc0et7t_9tklTP3w|ACTAyK<17th1_RM%}C|XDtuLrg}cB1hh1L|cDwg*$)<)k`lHkR@$j4+lkUl=-%&X49(LKowNoav z-{gJkjAUr)e+k;kL=URoS$C_14mAPCO-dw^% z7p*wRiI+E~xkBeAVxf*Pj6Q^hm5D>_Z2Izt+Mp5mpkxcMbhupZ&W(-jUuhG2_$Mb> z;06vB4h}XQ3-j-5fkqV`++WU_x7dLgxi87c(snpH+HM)aVlx>17`j*a&hq#(U*6keLt*?FDNbWE!6lLy%>!)cuUw4UIkX~l$keo&w@@__^V9$ z3d#hH!PpB@sIJQ6MPumeLVAhOt+ldWHFzU*vX0!Pub@17sveD=^))}7>kUd+bt;l* z2$*2+SxsM8UPa&j{MFxJW&Dq3V9=1mJw<$ZkF2rm7(Y2V$CPdGNqWTnk?+5&I=b~L zM9-GsJ374NDY$<9Vf%__h@hw;sqCCAOl)Y-UHg39ZEd~x@CO6MH*97@XC1k!sQ@W` z>Z_Xvdx`CIB&sNq1D<5_QhX(&N13T>+* zN5B09l_wOSZWN0V5Q?VYCM~PIarWH9reC0M4$#=k{ek!H|p zzQ*E3L87&Z(i47w7}V5Vf9X`YSxuZMJkl|*Bk40FPsgqPk(76 zCC_jgCO&nn?qAM$wwpmt8$t0t&Sc`L(=F7gN4W;->OId7O^zNb?bz73+UMh^A2&3A z>rr?27-MPm?09cYjk(4^dS{g!XDHvoh6|kx@tt4_4j~7z<;w#;TR{RJg5mj!{-4gh z7=FEh$2|>iatv5Qo(T?4{TBHmm`*E$=ERoZc!)lU2`uU`H?-q5QBMo&1(rurOBcf?gE{l(>{t-|Rvgn*003s2+_baV75mrh_$SUu5XAxls}b*OCwF z2>vnTaF$dxUf!vbQXE@vTH3Ej7r&Iv31gJF;`5w+yB-|dpCU*zEi2X5m?xiQh;6ru zc5w3$Cyr(xuoKz;M{0YYRzt~b#l=-oAim?ip5AuSJ0>o=YCMb#Q)3omT=tUvIn%>Y z$yMEAE23u$mUmeLPG4W)NMf6glETEITRawR^ORu$Y-;5s;CH!ayIX*>J?W+Pg#94#$hwNPSdOB z6_Z|^3GFg{brbQf%=+$q;z3OKS%LpB>083Do7dQAxs%Z0>WdB|<0dVn=o-0PGh;L~ z?sPVwrHMUGepZ*~>V!Sb8Dy3)6Lk;*{aSFmZM3>kaCa%Bu6M4s&|77=SV{&NdSUCrV7 z8)q>OC*`~s?HH{DH}dbq+h0Vsbl!xFUkSsO=>wpT)@s zO^(iP_3u@MvIf(fNh>30Gp$9625TN;1d?C5o0`|Ou60pkp9Kno2gx5{1S5H`dTfH| z=#7OLH|_7<)z{PSQ7@3b`@gr}rhMcF96n)kB3_*+c>xmE`KHyE0)_(jocr0wc8umB2_yX?0$&?-I;W3AW_q8`;1507te<#g{*_2fHqt&;1mi3|5?jN&< zY~V4!P)90hBl|VdO0A!b-;f*8gGj*@de0<@aN=khAInDhfB*!i$_znf=3*&JBjdGO zR!(BkgFe+`4f~P)iu&IC#Gk<`>~9MPy!@C0e%v#m45#47nYrCJa8UQ4q~uyNH{A2O zteBRSEhuow;!~4#1r6QJ>}glgj1aMj;0vKkLlsGqlvJ?fW&1nS?eA#y@peA42HHqn zA@T@{?-{u%{xUQe3bG7u6Q-|YWAQFSjw-tf`d*#CJWgPeNYu!FWn;t$#js21bxmS( z!fUt$)WDMCH&R&5xXnWg<11^X!7$OCgFh3<#9;>^hx<=R(pS_IP Date: Mon, 11 Sep 2023 11:54:18 +0200 Subject: [PATCH 0269/1012] Sets preparation, temperature+gas_pressure in NXmpes/NXsample to recommended --- contributed_definitions/NXmpes.nxdl.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 4f3083d251..1d60427997 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -314,7 +314,7 @@ annealing). - + Description of the surface preparation technique for the XPS experiment, i.e. UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report @@ -323,7 +323,7 @@ other metadata file. In the case these are not available, free-text description. - + In the case of a fixed temperature measurement this is the scalar temperature of the sample. In the case of an experiment in which the temperature is changed and @@ -339,7 +339,7 @@ - + Voltage applied to sample and sample holder. From b0c6858a793f4e8fe124ef6992a977e679705980 Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 11 Sep 2023 11:55:55 +0200 Subject: [PATCH 0270/1012] Sets fields to optional --- contributed_definitions/NXmpes.nxdl.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 1d60427997..3acf517c9f 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -314,7 +314,7 @@ annealing). - + Description of the surface preparation technique for the XPS experiment, i.e. UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report @@ -331,7 +331,7 @@ /entry/instrument/manipulator/sample_temperature. - + @@ -339,7 +339,7 @@ - + Voltage applied to sample and sample holder. From 3c314cb2bf651d0621285be0b75371102e05cf67 Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 11 Sep 2023 16:17:45 +0200 Subject: [PATCH 0271/1012] Incorporates comments from proposal page --- contributed_definitions/NXmpes.nxdl.xml | 28 ++++++++++++++++++++----- 1 file changed, 23 insertions(+), 5 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 3acf517c9f..d0fb924cba 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -33,13 +33,18 @@ Datetime of the start of the measurement. + + + Datetime of the end of the measurement. + + - + Contact information of at least the user of the instrument or the investigator who performed this experiment. Adding multiple users if relevant is recommended. @@ -73,7 +78,7 @@ - + The source used to generate the primary photons. Properties refer strictly to @@ -92,6 +97,8 @@ + + @@ -108,7 +115,7 @@ - + Distance of the point of evaluation of the beam from the sample surface. @@ -128,6 +135,12 @@ + Scheme of the electron collection column. @@ -135,13 +148,14 @@ + - + @@ -206,6 +220,10 @@ + @@ -228,7 +246,7 @@ - + Document an event of data processing, reconstruction, or analysis for this data. Describe the appropriate axis calibrations for your experiment using one or more From 5cbdf9bb53fdcdadef23cbe85d842b49aee7509b Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 13 Sep 2023 10:50:15 +0200 Subject: [PATCH 0272/1012] Incorporates changes from may workshop (#32) --- contributed_definitions/NXmpes.nxdl.xml | 35 ++++++++++++++++++++----- 1 file changed, 29 insertions(+), 6 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index d0fb924cba..2cdc6a0d73 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -38,6 +38,14 @@ Datetime of the end of the measurement. + + + A name of the experimental method according + to the `ISO 18115-1:2023`_ specification. + + .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + + @@ -79,7 +87,11 @@ - + + 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 @@ -99,22 +111,28 @@ + - + + + Specification of type, may also go to name. + + + Type of probe. In photoemission it's always photons, so the full NIAC list is restricted. - - - + - + + + Distance of the point of evaluation of the beam from the sample surface. @@ -125,6 +143,11 @@ + + + + + From dab0037216bf4aa46e6aef2b0e7314d0b0b962cd Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 13 Sep 2023 18:08:05 +0200 Subject: [PATCH 0273/1012] Adds a reference to PaNET ontology --- contributed_definitions/nyaml/NXmpes.yaml | 263 ++++++++++++++++++++++ 1 file changed, 263 insertions(+) create mode 100644 contributed_definitions/nyaml/NXmpes.yaml diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml new file mode 100644 index 0000000000..8721626809 --- /dev/null +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -0,0 +1,263 @@ +doc: | + This is the most general application definition for multidimensional + photoelectron spectroscopy. +category: application +uri: http://purl.org/pan-science/PaNET/PaNET01269 +NXmpes: + (NXentry): + title: + start_time(NX_DATE_TIME): + doc: | + Datetime of the start of the measurement. + end_time(NX_DATE_TIME): + doc: | + Datetime of the end of the measurement. + method: + doc: | + A name of the experimental method according + to the `ISO 18115-1:2023`_ specification. + + .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + definition: + \@version: + enumeration: [NXmpes] + (NXuser): + exists: recommended + doc: | + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + name: + doc: | + Name 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: | + Full address (street, street number, ZIP, city, country) of the user's + affiliation. + email: + doc: | + Email address of the user. + orcid: + exists: recommended + doc: | + Author ID defined by https://orcid.org/. + (NXinstrument): + energy_resolution(NX_FLOAT): + exists: recommended + unit: NX_ENERGY + source_beam(NXsource): + doc: | + The source used to generate the primary photons. Properties refer strictly to + parameters of the source, not of the output beam. For example, the energy of the + source is not the optical power of the beam, but the energy of the electron beam + in a synchrotron and so on. + type: + enumeration: [Synchrotron X-ray Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, UV Plasma Source, Metal Jet X-ray, HHG laser, UV lamp, Monochromatized electron source, other] + type_other: + doc: | + Specification of type, may also go to name. + name: + exists: recommended + probe: + doc: | + Type of probe. In photoemission it's always photons, so the full NIAC list is + restricted. + enumeration: [photons] + beam_probe(NXbeam): + distance(NX_NUMBER): + exists: recommended + unit: NX_LENGTH + doc: | + Distance of the point of evaluation of the beam from the sample surface. + incident_energy(NX_FLOAT): + unit: NX_ENERGY + incident_energy_spread(NX_NUMBER): + exists: recommended + unit: NX_ENERGY + incident_polarization(NX_NUMBER): + exists: recommended + unit: NX_ANY + (NXelectronanalyser): + model(NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + description: + energy_resolution(NX_FLOAT): + exists: recommended + unit: NX_ENERGY + doc: | + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. + fast_axes(NX_CHAR): + exists: recommended + slow_axes: + exists: recommended + (NXcollectioncolumn): + scheme: + doc: | + Scheme of the electron collection column. + enumeration: [Standard, Angular dispersive, Spatial dispersive, Selective area, Deflector, PEEM, Momentum Microscope] + mode: + exists: recommended + projection: + exists: recommended + field_aperture(NXaperture): + doc: | + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + contrast_aperture(NXaperture): + doc: | + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + (NXenergydispersion): + scheme: + enumeration: [tof, hemispherical, double hemispherical, cylindrical mirror, display mirror, retarding grid] + pass_energy(NX_FLOAT): + unit: NX_ENERGY + energy_scan_mode: + entrance_slit(NXaperture): + doc: | + Size, position and shape of the entrance slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + exit_slit(NXaperture): + doc: | + Size, position and shape of the exit slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + (NXdetector): + amplifier_type: + exists: recommended + doc: | + Type of electron amplifier in the first amplification step. + enumeration: [MCP, channeltron] + detector_type: + exists: recommended + doc: | + Description of the detector type. + enumeration: [DLD, Phosphor+CCD, Phosphor+CMOS, ECMOS, Anode, Multi-anode] + (NXdata): + exists: recommended + \@signal: + enumeration: [raw] + raw(NX_NUMBER): + doc: | + Raw data before calibration. + (NXmanipulator): + doc: | + Manipulator for positioning of the sample. + sample_temperature(NX_FLOAT): + exists: recommended + unit: NX_TEMPERATURE + drain_current(NX_FLOAT): + exists: recommended + unit: NX_CURRENT + sample_bias(NX_FLOAT): + exists: recommended + unit: NX_CURRENT + (NXprocess): + exists: recommended + doc: | + 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 + energy_calibration(NXcalibration): + applied(NX_BOOLEAN): + doc: | + Has an energy calibration been applied? + calibrated_axis(NX_FLOAT): + exists: recommended + doc: | + This is the calibrated energy axis to be used for data plotting. + angular_calibration(NXcalibration): + applied(NX_BOOLEAN): + doc: | + Has an angular calibration been applied? + calibrated_axis(NX_FLOAT): + exists: recommended + doc: | + This is the calibrated angular axis to be used for data plotting. + spatial_calibration(NXcalibration): + applied(NX_BOOLEAN): + doc: | + Has an spatial calibration been applied? + calibrated_axis(NX_FLOAT): + exists: recommended + doc: | + This is the calibrated spatial axis to be used for data plotting. + momentum_calibration(NXcalibration): + applied(NX_BOOLEAN): + doc: | + Has an momentum calibration been applied? + calibrated_axis(NX_FLOAT): + exists: recommended + doc: | + This is the momentum axis to be used for data plotting. + (NXsample): + name: + chemical_formula: + exists: recommended + doc: | + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + sample_history(NXnote): + exists: recommended + doc: | + 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. + atom_types: + exists: recommended + doc: | + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + preparation_date(NX_DATE_TIME): + exists: recommended + doc: | + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). + preparation_description(NXnote): + doc: | + 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. + temperature(NX_FLOAT): + exists: recommended + unit: NX_TEMPERATURE + doc: | + 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. + situation: + enumeration: [vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere] + gas_pressure(NX_FLOAT): + unit: NX_PRESSURE + bias(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Voltage applied to sample and sample holder. + (NXdata): + \@signal: + enumeration: [data] + data(NX_NUMBER): + unit: NX_ANY + doc: | + 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. From 13e22512ca9011f2271a21c6e6806e929acab73b Mon Sep 17 00:00:00 2001 From: domna Date: Thu, 21 Sep 2023 13:11:19 +0200 Subject: [PATCH 0274/1012] Use NXmpes.yaml generated with correct nyaml2nxdl --- contributed_definitions/nyaml/NXmpes.yaml | 454 +++++++++++++++++++++- 1 file changed, 447 insertions(+), 7 deletions(-) diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 8721626809..3190b0af73 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -1,9 +1,9 @@ -doc: | +category: application +doc: | This is the most general application definition for multidimensional photoelectron spectroscopy. -category: application -uri: http://purl.org/pan-science/PaNET/PaNET01269 -NXmpes: +type: group +NXmpes(NXobject): (NXentry): title: start_time(NX_DATE_TIME): @@ -48,9 +48,13 @@ NXmpes: Author ID defined by https://orcid.org/. (NXinstrument): energy_resolution(NX_FLOAT): - exists: recommended unit: NX_ENERGY + exists: recommended source_beam(NXsource): + + # Comment from mpes may workshop: + # - Add linking between source and beam + # - There is much more information which can be provided for NXsource doc: | 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 @@ -59,6 +63,7 @@ NXmpes: type: enumeration: [Synchrotron X-ray Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, UV Plasma Source, Metal Jet X-ray, HHG laser, UV lamp, Monochromatized electron source, other] type_other: + exists: optional doc: | Specification of type, may also go to name. name: @@ -69,9 +74,13 @@ NXmpes: restricted. enumeration: [photons] beam_probe(NXbeam): + + # Comment from mpes may workshop: Add linking between source and beam + + # Add extent as recommended? distance(NX_NUMBER): - exists: recommended unit: NX_LENGTH + exists: recommended doc: | Distance of the point of evaluation of the beam from the sample surface. incident_energy(NX_FLOAT): @@ -103,19 +112,27 @@ NXmpes: slow_axes: exists: recommended (NXcollectioncolumn): + + # TODO: Comment from Anders Frisk on proposal page + # What is the definition of a collection column? + # Optional constant settings (like lens focusing parameters on the sample: position_x, position_y, working_distance) scheme: doc: | Scheme of the electron collection column. enumeration: [Standard, Angular dispersive, Spatial dispersive, Selective area, Deflector, PEEM, Momentum Microscope] mode: exists: recommended + + # TODO: What does this refer to. It is currently not in the collection column base class projection: exists: recommended field_aperture(NXaperture): + exists: optional doc: | The size and position of the field aperture inserted in the column. To add additional or other apertures use the APERTURE group of NXcollectioncolumn. contrast_aperture(NXaperture): + exists: optional doc: | The size and position of the contrast aperture inserted in the column. To add additional or other apertures use the APERTURE group of NXcollectioncolumn. @@ -126,10 +143,12 @@ NXmpes: unit: NX_ENERGY energy_scan_mode: entrance_slit(NXaperture): + exists: optional doc: | Size, position and shape of the entrance slit in dispersive analyzers. To add additional or other slits use the APERTURE group of NXenergydispersion. exit_slit(NXaperture): + exists: optional doc: | Size, position and shape of the exit slit in dispersive analyzers. To add additional or other slits use the APERTURE group of NXenergydispersion. @@ -146,12 +165,16 @@ NXmpes: enumeration: [DLD, Phosphor+CCD, Phosphor+CMOS, ECMOS, Anode, Multi-anode] (NXdata): exists: recommended + + # TODO: Anders Frisk on proposal page + # It could be a lot of raw data from a detector. Shpould be optional. \@signal: enumeration: [raw] raw(NX_NUMBER): doc: | Raw data before calibration. (NXmanipulator): + exists: optional doc: | Manipulator for positioning of the sample. sample_temperature(NX_FLOAT): @@ -170,6 +193,7 @@ NXmpes: Describe the appropriate axis calibrations for your experiment using one or more of the following NXcalibrations energy_calibration(NXcalibration): + exists: optional applied(NX_BOOLEAN): doc: | Has an energy calibration been applied? @@ -178,6 +202,7 @@ NXmpes: doc: | This is the calibrated energy axis to be used for data plotting. angular_calibration(NXcalibration): + exists: optional applied(NX_BOOLEAN): doc: | Has an angular calibration been applied? @@ -186,6 +211,7 @@ NXmpes: doc: | This is the calibrated angular axis to be used for data plotting. spatial_calibration(NXcalibration): + exists: optional applied(NX_BOOLEAN): doc: | Has an spatial calibration been applied? @@ -194,6 +220,7 @@ NXmpes: doc: | This is the calibrated spatial axis to be used for data plotting. momentum_calibration(NXcalibration): + exists: optional applied(NX_BOOLEAN): doc: | Has an momentum calibration been applied? @@ -229,6 +256,7 @@ NXmpes: Date of preparation of the sample for the XPS experiment (i.e. cleaving, last annealing). preparation_description(NXnote): + exists: optional doc: | Description of the surface preparation technique for the XPS experiment, i.e. UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report @@ -236,19 +264,22 @@ NXmpes: 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. temperature(NX_FLOAT): - exists: recommended unit: NX_TEMPERATURE + exists: recommended doc: | 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. situation: + exists: optional enumeration: [vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere] gas_pressure(NX_FLOAT): unit: NX_PRESSURE + exists: optional bias(NX_FLOAT): unit: NX_VOLTAGE + exists: optional doc: | Voltage applied to sample and sample holder. (NXdata): @@ -261,3 +292,412 @@ NXmpes: 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e18956fa79544e7b4f50e31f3b421e387cab531f4f608e4c9dfc0013fa459429 +# +# +# +# +# +# This is the most general application definition for multidimensional +# photoelectron spectroscopy. +# +# +# +# +# +# Datetime of the start of the measurement. +# +# +# +# +# Datetime of the end of the measurement. +# +# +# +# +# A name of the experimental method according +# to the `ISO 18115-1:2023`_ specification. +# +# .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html +# +# +# +# +# +# +# +# +# +# +# Contact information of at least the user of the instrument or the investigator +# who performed this experiment. Adding multiple users if relevant is recommended. +# +# +# +# Name of the user. +# +# +# +# +# Name of the affiliation of the user at the point in time when the experiment was +# performed. +# +# +# +# +# Full address (street, street number, ZIP, city, country) of the user's +# affiliation. +# +# +# +# +# Email address of the user. +# +# +# +# +# Author ID defined by https://orcid.org/. +# +# +# +# +# +# +# +# +# The source used to generate the primary photons. Properties refer strictly to +# parameters of the source, not of the output beam. For example, the energy of the +# source is not the optical power of the beam, but the energy of the electron beam +# in a synchrotron and so on. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Specification of type, may also go to name. +# +# +# +# +# +# Type of probe. In photoemission it's always photons, so the full NIAC list is +# restricted. +# +# +# +# +# +# +# +# +# +# +# +# Distance of the point of evaluation of the beam from the sample surface. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Energy resolution of the analyser with the current setting. May be linked from a +# NXcalibration. +# +# +# +# +# +# +# +# +# Scheme of the electron collection column. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The size and position of the field aperture inserted in the column. To add +# additional or other apertures use the APERTURE group of NXcollectioncolumn. +# +# +# +# +# The size and position of the contrast aperture inserted in the column. To add +# additional or other apertures use the APERTURE group of NXcollectioncolumn. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Size, position and shape of the entrance slit in dispersive analyzers. To add +# additional or other slits use the APERTURE group of NXenergydispersion. +# +# +# +# +# Size, position and shape of the exit slit in dispersive analyzers. To add +# additional or other slits use the APERTURE group of NXenergydispersion. +# +# +# +# +# +# +# Type of electron amplifier in the first amplification step. +# +# +# +# +# +# +# +# +# Description of the detector type. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Raw data before calibration. +# +# +# +# +# +# +# +# Manipulator for positioning of the sample. +# +# +# +# +# +# +# +# +# Document an event of data processing, reconstruction, or analysis for this data. +# Describe the appropriate axis calibrations for your experiment using one or more +# of the following NXcalibrations +# +# +# +# +# Has an energy calibration been applied? +# +# +# +# +# This is the calibrated energy axis to be used for data plotting. +# +# +# +# +# +# +# Has an angular calibration been applied? +# +# +# +# +# This is the calibrated angular axis to be used for data plotting. +# +# +# +# +# +# +# Has an spatial calibration been applied? +# +# +# +# +# This is the calibrated spatial axis to be used for data plotting. +# +# +# +# +# +# +# Has an momentum calibration been applied? +# +# +# +# +# This is the momentum axis to be used for data plotting. +# +# +# +# +# +# +# +# +# The chemical formula of the sample. For mixtures use the NXsample_component +# group in NXsample instead. +# +# +# +# +# A descriptor to keep track of the treatment of the sample before entering the +# photoemission experiment. Ideally, a full report of the previous operations, in +# any format (NXnote allows to add pictures, audio, movies). Alternatively, a +# reference to the location or a unique identifier or other metadata file. In the +# case these are not available, free-text description. +# +# +# +# +# List of comma-separated elements from the periodic table +# that are contained in the sample. +# If the sample substance has multiple components, all +# elements from each component must be included in `atom_types`. +# +# +# +# +# Date of preparation of the sample for the XPS experiment (i.e. cleaving, last +# annealing). +# +# +# +# +# Description of the surface preparation technique for the XPS experiment, i.e. +# UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report +# of the previous operations, in any format(NXnote allows to add pictures, audio, +# movies). Alternatively, a reference to the location or a unique identifier or +# other metadata file. In the case these are not available, free-text description. +# +# +# +# +# In the case of a fixed temperature measurement this is the scalar temperature of +# the sample. In the case of an experiment in which the temperature is changed and +# recoded, this is an array of length m of temperatures. This should be a link to +# /entry/instrument/manipulator/sample_temperature. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Voltage applied to sample and sample holder. +# +# +# +# +# +# +# +# +# +# +# +# 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. +# +# +# +# +# From 6270604ce2d4761b460382f4b798d8287a80b8f3 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 25 Sep 2023 13:52:48 +0200 Subject: [PATCH 0275/1012] Rename temperature_sensor, make NXsubstance recommended --- .../NXmanipulator.nxdl.xml | 2 +- contributed_definitions/NXmpes.nxdl.xml | 19 +++++++++---------- .../nyaml/NXmanipulator.yaml | 2 +- contributed_definitions/nyaml/NXmpes.yaml | 17 +++++++++-------- 4 files changed, 20 insertions(+), 20 deletions(-) diff --git a/contributed_definitions/NXmanipulator.nxdl.xml b/contributed_definitions/NXmanipulator.nxdl.xml index 96aafcbb93..cd63ba4766 100644 --- a/contributed_definitions/NXmanipulator.nxdl.xml +++ b/contributed_definitions/NXmanipulator.nxdl.xml @@ -56,7 +56,7 @@ Device for applying heating power for temperature control. - + Sensor to measure the temperature at the closest point to the sample. diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 4f121bdc30..84691aa407 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -259,9 +259,9 @@ It could be a lot of raw data from a detector. Shpould be optional.--> Manipulator for positioning of the sample. - + - Thermocouple measuring the sample temperature. + Temperature sensor measuring the sample temperature. @@ -273,7 +273,7 @@ It could be a lot of raw data from a detector. Shpould be optional.--> In the case of a fixed temperature measurement, this is the scalar temperature measured - by the sample thermocouple. + by the sample temperature sensor. @@ -296,14 +296,13 @@ It could be a lot of raw data from a detector. Shpould be optional.--> - In the case of a fixed temperature measurement, this is the scalar temperature - setpoint. + In the case of a fixed temperature, this is the scalar temperature setpoint. In the case of an experiment in which the temperature is changed and recorded, - this is an array of length m of temperatures. + this is an array of length m of temperature setpoints. @@ -438,7 +437,7 @@ It could be a lot of raw data from a detector. Shpould be optional.--> - + For samples containing a single pure substances. For mixtures use the NXsample_component_set and NXsample_component group in NXsample instead. @@ -494,11 +493,11 @@ It could be a lot of raw data from a detector. Shpould be optional.--> Sample temperature (either controlled or just measured). - + - Thermocouple measuring the sample temperature. + Temperature sensor measuring the sample temperature. - This should be a link to /entry/instrument/manipulator/sample_thermocouple. + This should be a link to /entry/instrument/manipulator/temperature_sensor. diff --git a/contributed_definitions/nyaml/NXmanipulator.yaml b/contributed_definitions/nyaml/NXmanipulator.yaml index 60c8159843..ca287c3f06 100644 --- a/contributed_definitions/nyaml/NXmanipulator.yaml +++ b/contributed_definitions/nyaml/NXmanipulator.yaml @@ -22,7 +22,7 @@ NXmanipulator(NXobject): sample_heater(NXactuator): doc: | Device for applying heating power for temperature control. - sample_thermocouple(NXsensor): + temperature_sensor(NXsensor): doc: | Sensor to measure the temperature at the closest point to the sample. diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 753436563b..597762b0bf 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -177,9 +177,9 @@ NXmpes(NXobject): exists: optional doc: | Manipulator for positioning of the sample. - sample_thermocouple(NXsensor): + temperature_sensor(NXsensor): exists: recommended - doc: Thermocouple measuring the sample temperature. + doc: Temperature sensor measuring the sample temperature. name: exists: recommended measurement: @@ -191,7 +191,7 @@ NXmpes(NXobject): unit: NX_TEMPERATURE doc: | In the case of a fixed temperature measurement, this is the scalar temperature measured - by the sample thermocouple. + by the sample temperature sensor. value_log(NXlog): exists: optional unit: NX_TEMPERATURE @@ -211,13 +211,13 @@ NXmpes(NXobject): exists: recommended unit: NX_TEMPERATURE doc: | - In the case of a fixed temperature measurement, this is the scalar temperature setpoint. + In the case of a fixed temperature, this is the scalar temperature setpoint. value_log(NXlog): exists: optional unit: NX_TEMPERATURE doc: | In the case of an experiment in which the temperature is changed and recorded, - this is an array of length m of temperatures. + this is an array of length m of temperature setpoints. drain_current_amperemeter(NXsensor): exists: recommended doc: Amperemeter measuring the drain current of the sample and sample holder. @@ -328,6 +328,7 @@ NXmpes(NXobject): (NXsample): name: (NXsubstance): + exists: recommended doc: | For samples containing a single pure substances. For mixtures use the NXsample_component_set and NXsample_component group in NXsample instead. @@ -373,11 +374,11 @@ NXmpes(NXobject): exists: recommended doc: | Sample temperature (either controlled or just measured). - thermocouple(NXsensor): + temperature_sensor(NXsensor): doc: | - Thermocouple measuring the sample temperature. + Temperature sensor measuring the sample temperature. - This should be a link to /entry/instrument/manipulator/sample_thermocouple. + This should be a link to /entry/instrument/manipulator/temperature_sensor. sample_heater(NXactuator): exists: optional doc: | From 599d1c580c9ab5ec72318234121ceba783607efc Mon Sep 17 00:00:00 2001 From: domna Date: Tue, 26 Sep 2023 09:23:25 +0200 Subject: [PATCH 0276/1012] Addresses some of the comments --- contributed_definitions/NXmpes.nxdl.xml | 78 ++++++++++++------- contributed_definitions/NXresolution.nxdl.xml | 29 +++++++ contributed_definitions/nyaml/NXmpes.yaml | 48 +++++++++--- .../nyaml/NXresolution.yaml | 7 ++ 4 files changed, 123 insertions(+), 39 deletions(-) create mode 100644 contributed_definitions/NXresolution.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXresolution.yaml diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 2cdc6a0d73..8dfa73db49 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -2,9 +2,9 @@ + + + + + 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 @@ -116,7 +117,7 @@ - Specification of type, may also go to name. + Specification of type, may also go to name. @@ -129,10 +130,22 @@ + + + The beam emitted by this source. + Should be named with the same appendix, e.g., + for `source_probe` it should refer to `beam_probe`. + Refers to the same concept as /NXentry/NXinstrument/source_TYPE + and may be linked. + + - - - + + + + Distance of the point of evaluation of the beam from the sample surface. @@ -141,9 +154,19 @@ + + + + The beam emitted by this source. + Should be named with the same appendix, e.g., + for `beam_probe` it should refer to `source_probe`. + Refers to the same concept as /NXentry/NXinstrument/beam_TYPE + and may be linked. + + - + @@ -158,12 +181,9 @@ - + Scheme of the electron collection column. @@ -178,7 +198,11 @@ - + + + Labelling of the lens setting in use. + + @@ -243,10 +267,6 @@ - @@ -380,10 +400,10 @@ - + - Voltage applied to sample and sample holder. + Voltage applied to sample and sample holder. diff --git a/contributed_definitions/NXresolution.nxdl.xml b/contributed_definitions/NXresolution.nxdl.xml new file mode 100644 index 0000000000..0f61043a24 --- /dev/null +++ b/contributed_definitions/NXresolution.nxdl.xml @@ -0,0 +1,29 @@ + + + + + + Describes the resolution of a physical quantity. + + + diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 3190b0af73..496da42fe2 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -12,12 +12,14 @@ NXmpes(NXobject): end_time(NX_DATE_TIME): doc: | Datetime of the end of the measurement. + exists: recommended method: doc: | A name of the experimental method according to the `ISO 18115-1:2023`_ specification. .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + exists: recommended definition: \@version: enumeration: [NXmpes] @@ -47,10 +49,11 @@ NXmpes(NXobject): doc: | Author ID defined by https://orcid.org/. (NXinstrument): - energy_resolution(NX_FLOAT): - unit: NX_ENERGY + energy_resolution(NXresolution): exists: recommended - source_beam(NXsource): + resolution: + unit: NX_ENERGY + source_TYPE(NXsource): # Comment from mpes may workshop: # - Add linking between source and beam @@ -73,7 +76,26 @@ NXmpes(NXobject): Type of probe. In photoemission it's always photons, so the full NIAC list is restricted. enumeration: [photons] - beam_probe(NXbeam): + device_information(NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + associated_beam(NXbeam): + doc: | + The beam emitted by this source. + Should be named with the same appendix, e.g., + for `source_probe` it should refer to `beam_probe`. + Refers to the same concept as /NXentry/NXinstrument/source_TYPE + and may be linked. + + # It would be nice if we had the notion of linking in nexus or if + # we have a subdefinition NXlink to refer to a path. + # This would also be helpful for NXtransformations + beam_TYPE(NXbeam): # Comment from mpes may workshop: Add linking between source and beam @@ -91,8 +113,17 @@ NXmpes(NXobject): incident_polarization(NX_NUMBER): exists: recommended unit: NX_ANY + extent(NX_FLOAT): + exists: recommended + associated_source(NXsource): + doc: | + The beam emitted by this source. + Should be named with the same appendix, e.g., + for `beam_probe` it should refer to `source_probe`. + Refers to the same concept as /NXentry/NXinstrument/beam_TYPE + and may be linked. (NXelectronanalyser): - model(NXfabrication): + device_information(NXfabrication): exists: recommended vendor: exists: recommended @@ -121,9 +152,9 @@ NXmpes(NXobject): Scheme of the electron collection column. enumeration: [Standard, Angular dispersive, Spatial dispersive, Selective area, Deflector, PEEM, Momentum Microscope] mode: + doc: | + Labelling of the lens setting in use. exists: recommended - - # TODO: What does this refer to. It is currently not in the collection column base class projection: exists: recommended field_aperture(NXaperture): @@ -165,9 +196,6 @@ NXmpes(NXobject): enumeration: [DLD, Phosphor+CCD, Phosphor+CMOS, ECMOS, Anode, Multi-anode] (NXdata): exists: recommended - - # TODO: Anders Frisk on proposal page - # It could be a lot of raw data from a detector. Shpould be optional. \@signal: enumeration: [raw] raw(NX_NUMBER): diff --git a/contributed_definitions/nyaml/NXresolution.yaml b/contributed_definitions/nyaml/NXresolution.yaml new file mode 100644 index 0000000000..4dc33f0dca --- /dev/null +++ b/contributed_definitions/nyaml/NXresolution.yaml @@ -0,0 +1,7 @@ +category: base +doc: | + Describes the resolution of a physical quantity. +type: group +NXresolution: + resolution(NX_FLOAT): + unit: NX_ANY \ No newline at end of file From 774b5c0e64af48a51b54c4ec7d553553a2da2c75 Mon Sep 17 00:00:00 2001 From: rettigl Date: Tue, 26 Sep 2023 23:20:42 +0200 Subject: [PATCH 0277/1012] added kinetic_energy and work_function to base classes --- .../NXelectronanalyser.nxdl.xml | 15 ++++++++++----- .../NXenergydispersion.nxdl.xml | 12 +++++++++--- .../nyaml/NXelectronanalyser.yaml | 5 ++++- .../nyaml/NXenergydispersion.yaml | 4 ++++ 4 files changed, 27 insertions(+), 9 deletions(-) diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml index 0ef6f51315..c42a237eb8 100644 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -28,18 +28,18 @@ - Number of fast axes (axes acquired symultaneously, without scanning - a physical quantity) + Number of fast axes (axes acquired symultaneously, without scanning a pysical + quantity) - Number of slow axes (axes acquired scanning a physical quantity) + Number of slow axes (axes acquired scanning a pysical quantity) - Subclass of NXinstrument to describe a photoelectron analyser. + Subclass of NXinstrument to describe a photoelectron analyser. @@ -76,6 +76,11 @@ Spatial resolution of the electron analyser (Airy disk radius) + + + Work function of the electron analyzer + + List of the axes that are acquired simultaneously by the detector. diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml index d408627e24..1abfff805b 100644 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ b/contributed_definitions/NXenergydispersion.nxdl.xml @@ -8,7 +8,7 @@ # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either -# version 2 of the License, or (at your option) any later version. +# version 3 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of @@ -23,8 +23,8 @@ --> - 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. @@ -38,6 +38,12 @@ hemispherics, drift energy for tofs. + + + Kinetic energy set for the dispersive analyzer section. Can be either the set + kinetic energy, or the whole calibrated energy axis of a scan. + + Center of the energy window diff --git a/contributed_definitions/nyaml/NXelectronanalyser.yaml b/contributed_definitions/nyaml/NXelectronanalyser.yaml index 11e8274857..9e66edfac6 100644 --- a/contributed_definitions/nyaml/NXelectronanalyser.yaml +++ b/contributed_definitions/nyaml/NXelectronanalyser.yaml @@ -3,7 +3,7 @@ doc: "Subclass of NXinstrument to describe a photoelectron analyser." symbols: doc: "The symbols used in the schema to specify e.g. dimensions of arrays" nfa: "Number of fast axes (axes acquired symultaneously, without scanning a pysical - quantity)" + quantity)" nsa: "Number of slow axes (axes acquired scanning a pysical quantity)" NXelectronanalyser: description(NX_CHAR): @@ -24,6 +24,9 @@ NXelectronanalyser: spatial_resolution(NX_FLOAT): doc: "Spatial resolution of the electron analyser (Airy disk radius)" unit: NX_LENGTH + work_function(NX_FLOAT): + doc: "Work function of the electron analyzer" + unit: NX_ENERGY fast_axes(NX_CHAR): doc: | List of the axes that are acquired simultaneously by the detector. diff --git a/contributed_definitions/nyaml/NXenergydispersion.yaml b/contributed_definitions/nyaml/NXenergydispersion.yaml index 784abbecbb..1cfc647684 100644 --- a/contributed_definitions/nyaml/NXenergydispersion.yaml +++ b/contributed_definitions/nyaml/NXenergydispersion.yaml @@ -9,6 +9,10 @@ NXenergydispersion: doc: "Energy of the electrons on the mean path of the analyser. Pass energy for hemispherics, drift energy for tofs." unit: NX_ENERGY + kinetic_energy(NX_FLOAT): + doc: "Kinetic energy set for the dispersive analyzer section. Can be either the set kinetic energy, + or the whole calibrated energy axis of a scan." + unit: NX_ENEGRY center_energy(NX_FLOAT): doc: "Center of the energy window" unit: NX_ENERGY From 53d5a85526cba893161a1dbbeaa82e1fcea36da7 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 27 Sep 2023 08:09:17 +0200 Subject: [PATCH 0278/1012] Cleaner docs for NXmpes --- manual/source/mpes-structure.rst | 42 +++++++++++++------------------- 1 file changed, 17 insertions(+), 25 deletions(-) diff --git a/manual/source/mpes-structure.rst b/manual/source/mpes-structure.rst index 3b0fd8394c..dc0e4a75db 100644 --- a/manual/source/mpes-structure.rst +++ b/manual/source/mpes-structure.rst @@ -1,29 +1,21 @@ .. _Mpes-Structure-Fairmat: -============================================== -B2/B3: Photoemission & core-level spectroscopy -============================================== - -.. index:: - IntroductionMpes1 - MpesAppDef1 - -.. _IntroductionMpes1: - -Introduction -############ - -Set of data storage objects to describe photoemission experiments including x-ray photoelectron spectroscopy (XPS), ultraviolet photoelectron spectroscopy (UPS), -hard x-ray photoelectron spectroscopy (HAXPES), angle-resolved photoemission spectroscopy (ARPES), two-photon photoemission (2PPE) -and photoemission electron microscopy (PEEM). We also included descriptors for advanced specializations, such as spin-resolution, time resolution, -near-ambient pressure conditions, dichroism etc. - -.. _MpesAppDef1: - -Application Definitions -####################### - -We created two new application definitions: +======================================= +Photoemission & core-level spectroscopy +======================================= + +The NXmpes application definition aims at describing any possible multidimensional PES setup. +Hence, it is very general and currently the only limitation to the data is that an energy +axis has to be present. +The general experimental techniques described by this application definitions are +photons in and photoelectrons out. +If you want NXmpes for such a techniques, changes are good you find something useful here. + +An example set of techniques covered by this application defintions are x-ray/UV photoelectron spectroscopy (XPS/UPS), +angle-resolved photoemission spectroscopy (ARPES), two-photon photoemission (2PPE) or +photoemission electron microscopy (PEEM). +We also include descriptors for advanced specializations, such as spin- and time-resolution, near-ambient pressure conditions, +dichroism and many more. :ref:`NXmpes`: - A general appdef with minimalistic metadata requirements, apt to describe all photemission experiments. + A general appdef with minimalistic metadata requirements to describe all photemission experiments. From c7b789b79a93a2a224890e53b7de7457b98dfdaa Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 27 Sep 2023 09:09:27 +0200 Subject: [PATCH 0279/1012] Adds proper NXresolution --- contributed_definitions/NXlink.nxdl.xml | 39 ++++++++++++++ contributed_definitions/NXmpes.nxdl.xml | 11 +++- contributed_definitions/NXresolution.nxdl.xml | 54 ++++++++++++++++++- contributed_definitions/nyaml/NXlink.yaml | 12 +++++ contributed_definitions/nyaml/NXmpes.yaml | 7 ++- .../nyaml/NXresolution.yaml | 39 +++++++++++++- 6 files changed, 156 insertions(+), 6 deletions(-) create mode 100644 contributed_definitions/NXlink.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXlink.yaml diff --git a/contributed_definitions/NXlink.nxdl.xml b/contributed_definitions/NXlink.nxdl.xml new file mode 100644 index 0000000000..d9bf2f2149 --- /dev/null +++ b/contributed_definitions/NXlink.nxdl.xml @@ -0,0 +1,39 @@ + + + + + + Describes a link + + + + The symbol by which to refer to this link, e.g., for formulas + + + + + A valid path inside an instance of an application definition, i.e., + of the form /entry/instrument/my_part/my_field + + + diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 8dfa73db49..ad32844635 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -87,7 +87,11 @@ - + + + + + - - - A sensor used to monitor an external condition - - The condition itself is described in :ref:`NXenvironment`. - - - Sensor identification code/model number - - - Name for the sensor - - - Short name of sensor used e.g. on monitor display program - - - where sensor is attached to ("sample" | "can") - - - - Defines the axes for logged vector quantities if they are not the global instrument axes. - - - - name for measured signal - - - - - - - - - - - - - - - - - - - The type of hardware used for the measurement. - Examples (suggestions but not restrictions): - - :Temperature: - J | K | T | E | R | S | Pt100 | Rh/Fe - :pH: - Hg/Hg2Cl2 | Ag/AgCl | ISFET - :Ion selective electrode: - specify species; e.g. Ca2+ - :Magnetic field: - Hall - :Surface pressure: - wilhelmy plate - - - - - Is data collection controlled or synchronised to this quantity: - 1=no, 0=to "value", 1=to "value_deriv1", etc. - - - - - Upper control bound of sensor reading if using run_control - - - - - Lower control bound of sensor reading if using run_control - - - - - nominal setpoint or average value - - need [n] as may be a vector - - - - - - - - Nominal/average first derivative of value - e.g. strain rate - - same dimensions as "value" (may be a vector) - - - - - - - - Nominal/average second derivative of value - - same dimensions as "value" (may be a vector) - - - - - - - Time history of sensor readings - - - Time history of first derivative of sensor readings - - - Time history of second derivative of sensor readings - - - - - - - - - - - - - For complex external fields not satisfied by External_field_brief - - - - This group describes the shape of the sensor when necessary. - - + + + A sensor used to monitor an external condition + + The condition itself is described in :ref:`NXenvironment`. + + + + Sensor identification code/model number + + + + + Name for the sensor + + + + + Short name of sensor used e.g. on monitor display program + + + + + where sensor is attached to ("sample" | "can") + + + + + Defines the axes for logged vector quantities if they are not the global + instrument axes. + + + + + name for measured signal + + + + + + + + + + + + + + + + + + + + The type of hardware used for the measurement. + Examples (suggestions but not restrictions): + + :Temperature: + J | K | T | E | R | S | Pt100 | Rh/Fe + :pH: + Hg/Hg2Cl2 | Ag/AgCl | ISFET + :Ion selective electrode: + specify species; e.g. Ca2+ + :Magnetic field: + Hall + :Surface pressure: + wilhelmy plate + + + + + Is data collection controlled or synchronised to this quantity: + 1=no, 0=to "value", 1=to "value_deriv1", etc. + + + + + Upper control bound of sensor reading if using run_control + + + + + Lower control bound of sensor reading if using run_control + + + + + nominal setpoint or average value + - need [n] as may be a vector + + + + + + + + Nominal/average first derivative of value + e.g. strain rate + - same dimensions as "value" (may be a vector) + + + + + + + + Nominal/average second derivative of value + - same dimensions as "value" (may be a vector) + + + + + + + + Time history of sensor readings + + + + + Time history of first derivative of sensor readings + + + + + Time history of second derivative of sensor readings + + + + + + + + + + + + + + + For complex external fields not satisfied by External_field_brief + + + + + This group describes the shape of the sensor when necessary. + + + - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a sensor. - + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a sensor. - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. - diff --git a/base_classes/NXsource.nxdl.xml b/base_classes/NXsource.nxdl.xml index 3fd1f983c7..a291384d3f 100644 --- a/base_classes/NXsource.nxdl.xml +++ b/base_classes/NXsource.nxdl.xml @@ -265,12 +265,13 @@ "Engineering" location of source. + This group describes the shape of the beam line component - + The wavelength or energy distribution of the source diff --git a/base_classes/nyaml/NXdetector.yaml b/base_classes/nyaml/NXdetector.yaml new file mode 100644 index 0000000000..8fd286fc58 --- /dev/null +++ b/base_classes/nyaml/NXdetector.yaml @@ -0,0 +1,1758 @@ +category: base +doc: | + A detector, detector bank, or multidetector. +symbols: + doc: | + These symbols will be used below to illustrate the coordination of the + rank and sizes of datasets and the preferred ordering of the + dimensions. Each of these are optional (so the rank of the datasets + will vary according to the situation) and the general ordering + principle is slowest to fastest. The type of each dimension should + follow the order of scan points, detector output (e.g. pixels), then + time-of-flight (i.e. spectroscopy, spectrometry). Note that the output + of a detector is not limited to single values (0D), lists (1D) and + images (2), but three or higher dimensional arrays can be produced by + a detector at each trigger. + nP: | + number of scan points (only present in scanning measurements) + i: | + number of detector pixels in the first (slowest) direction + j: | + number of detector pixels in the second (faster) direction + k: | + number of detector pixels in the third (if necessary, fastest) + direction + tof: | + number of bins in the time-of-flight histogram +type: group +(NXobject)NXdetector: + time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + doc: | + Total time of flight + dimensions: + rank: 1 + dim: [[1, tof+1]] + \@axis: + type: NX_POSINT + deprecated: | + see: https://github.com/nexusformat/definitions/issues/436 + enumeration: [3] + \@primary: + type: NX_POSINT + deprecated: | + see: https://github.com/nexusformat/definitions/issues/436 + enumeration: [1] + \@long_name: + doc: | + Total time of flight + raw_time_of_flight(NX_INT): + unit: NX_PULSES + doc: | + In DAQ clock pulses + dimensions: + rank: 1 + dim: [[1, tof+1]] + \@frequency: + type: NX_NUMBER + doc: | + Clock frequency in Hz + detector_number(NX_INT): + doc: | + Identifier for detector (pixels) + Can be multidimensional, if needed + data(NX_NUMBER): + unit: NX_ANY + doc: | + 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. + dimensions: + rank: 4 + dim: [[1, nP], [2, i], [3, j], [4, tof]] + \@long_name: + doc: | + Title of measurement + \@check_sum: + type: NX_INT + doc: | + Integral of data as check of data integrity + data_errors(NX_NUMBER): + unit: NX_ANY + doc: | + The best estimate of the uncertainty in the data value (array size should match the data field). Where + possible, this should be the standard deviation, which has the same units + as the data. The form data_error is deprecated. + dimensions: + rank: 4 + dim: [[1, nP], [2, i], [3, j], [4, tof]] + x_pixel_offset(NX_FLOAT): + unit: NX_LENGTH + doc: | + Offset from the detector center in x-direction. + Can be multidimensional when needed. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + \@axis: + type: NX_POSINT + deprecated: | + see: https://github.com/nexusformat/definitions/issues/436 + enumeration: [1] + \@primary: + type: NX_POSINT + deprecated: | + see: https://github.com/nexusformat/definitions/issues/436 + enumeration: [1] + \@long_name: + doc: | + x-axis offset from detector center + y_pixel_offset(NX_FLOAT): + unit: NX_LENGTH + doc: | + Offset from the detector center in the y-direction. + Can be multidimensional when different values are required for each pixel. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + \@axis: + type: NX_POSINT + deprecated: | + see: https://github.com/nexusformat/definitions/issues/436 + enumeration: [2] + \@primary: + type: NX_POSINT + deprecated: | + see: https://github.com/nexusformat/definitions/issues/436 + enumeration: [1] + \@long_name: + doc: | + y-axis offset from detector center + z_pixel_offset(NX_FLOAT): + unit: NX_LENGTH + doc: | + Offset from the detector center in the z-direction. + Can be multidimensional when different values are required for each pixel. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + \@axis: + type: NX_POSINT + deprecated: | + see: https://github.com/nexusformat/definitions/issues/436 + enumeration: [3] + \@primary: + type: NX_POSINT + deprecated: | + see: https://github.com/nexusformat/definitions/issues/436 + enumeration: [1] + \@long_name: + doc: | + y-axis offset from detector center + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the distance to the previous component in the + instrument; most often the sample. The usage depends on the + nature of the detector: Most often it is the distance of the + detector assembly. But there are irregular detectors. In this + case the distance must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. + dimensions: + rank: 3 + dim: [[1, nP], [2, i], [3, j]] + polar_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + This is the polar angle of the detector towards the previous + component in the instrument; most often the sample. + The usage depends on the + nature of the detector. + Most often it is the polar_angle of the detector assembly. + But there are irregular detectors. + In this + case, the polar_angle must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. + dimensions: + rank: 3 + dim: [[1, nP], [2, i], [3, j]] + azimuthal_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + This is the azimuthal angle angle of the detector towards + the previous component in the instrument; most often the sample. + The usage depends on the + nature of the detector. + Most often it is the azimuthal_angle of the detector assembly. + But there are irregular detectors. + In this + case, the azimuthal_angle must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. + dimensions: + rank: 3 + dim: [[1, nP], [2, i], [3, j]] + description: + doc: | + name/manufacturer/model/etc. information + serial_number: + doc: | + Serial number for the detector + local_name: + doc: | + Local name for the detector + (NXgeometry): + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the detector and NXoff_geometry to describe its shape instead + doc: | + Position and orientation of detector + solid_angle(NX_FLOAT): + unit: NX_SOLID_ANGLE + doc: | + Solid angle subtended by the detector at the sample + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + x_pixel_size(NX_FLOAT): + unit: NX_LENGTH + doc: | + Size of each detector pixel. If it is scalar all pixels are the same size. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + y_pixel_size(NX_FLOAT): + unit: NX_LENGTH + doc: | + Size of each detector pixel. If it is scalar all pixels are the same size + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + dead_time(NX_FLOAT): + unit: NX_TIME + doc: | + Detector dead time + dimensions: + rank: 3 + dim: [[1, nP], [2, i], [3, j]] + gas_pressure(NX_FLOAT): + unit: NX_PRESSURE + doc: | + Detector gas pressure + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + detection_gas_path(NX_FLOAT): + unit: NX_LENGTH + doc: | + maximum drift space dimension + crate(NX_INT): + doc: | + Crate number of detector + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + \@local_name: + doc: | + Equivalent local term + slot(NX_INT): + doc: | + Slot number of detector + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + \@local_name: + doc: | + Equivalent local term + input(NX_INT): + doc: | + Input number of detector + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + \@local_name: + doc: | + Equivalent local term + type: + doc: | + Description of type such as He3 gas cylinder, He3 PSD, scintillator, + fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, + CMOS, ... + efficiency(NXdata): + doc: | + Spectral efficiency of detector with respect to e.g. wavelength + \@signal: + enumeration: [efficiency] + \@axes: + + # TODO: clarify the various use cases + enumeration: [., . ., . . ., . . . ., wavelength] + \@wavelength_indices: + + # TODO: clarify the actual possibilities + enumeration: [0] + efficiency(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + efficiency of the detector + dimensions: + rank: 3 + dim: [[1, i], [2, j], [3, k]] + wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + This field can be two things: + + 1. For a pixel detector it provides the nominal wavelength + for which the detector has been calibrated. + + 2. For other detectors this field has to be seen together with + the efficiency field above. + For some detectors, the efficiency is wavelength dependent. + Thus this field provides the wavelength axis for the efficiency field. + In this use case, the efficiency and wavelength arrays must + have the same dimensionality. + dimensions: + rank: 3 + dim: [[1, i], [2, j], [3, k]] + real_time(NX_NUMBER): + unit: NX_TIME + doc: | + Real-time of the exposure (use this if exposure time varies for + each array element, otherwise use ``count_time`` field). + + Most often there is a single real time value that is constant across + an entire image frame. In such cases, only a 1-D array is needed. + But there are detectors in which the real time + changes per pixel. In that case, more than one dimension is needed. Therefore + the rank of this field should be less than or equal to (detector rank + 1). + dimensions: + rank: 3 + dim: [[1, nP], [2, i], [3, j]] + start_time(NX_FLOAT): + unit: NX_TIME + doc: | + start time for each frame, with the ``start`` attribute as absolute reference + dimensions: + rank: 1 + dim: [[1, nP]] + \@start: + type: NX_DATE_TIME + stop_time(NX_FLOAT): + unit: NX_TIME + doc: | + stop time for each frame, with the ``start`` attribute as absolute reference + dimensions: + rank: 1 + dim: [[1, nP]] + \@start: + type: NX_DATE_TIME + calibration_date(NX_DATE_TIME): + doc: | + date of last calibration (geometry and/or efficiency) measurements + calibration_method(NXnote): + doc: | + summary of conversion of array data to pixels (e.g. polynomial + approximations) and location of details of the calibrations + layout: + doc: | + How the detector is represented + enumeration: [point, linear, area] + count_time(NX_NUMBER): + unit: NX_TIME + doc: | + Elapsed actual counting time + dimensions: + rank: 1 + dim: [[1, nP]] + data_file(NXnote): + (NXcollection): + doc: | + Use this group to provide other data related to this NXdetector group. + sequence_number(NX_INT): + doc: | + In order to properly sort the order of the images taken in (for + example) a tomography experiment, a sequence number is stored with each + image. + dimensions: + rank: 1 + dim: [[1, nBrightFrames]] + beam_center_x(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the x position where the direct beam would hit the detector. + This is a length and can be outside of the actual + detector. The length can be in physical units or pixels + as documented by the units attribute. + beam_center_y(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the y position where the direct beam would hit the detector. + This is a length and can be outside of the actual + detector. The length can be in physical units or pixels + as documented by the units attribute. + frame_start_number(NX_INT): + doc: | + This is the start number of the first frame of a scan. In protein crystallography measurements one + often scans a couple of frames on a give sample, then does something else, + then returns to the same sample and scans some more frames. Each time with + a new data file. This number helps concatenating such measurements. + diameter(NX_FLOAT): + unit: NX_LENGTH + doc: | + The diameter of a cylindrical detector + acquisition_mode(NX_CHAR): + doc: | + The acquisition mode of the detector. + enumeration: [gated, triggered, summed, event, histogrammed, decimated] + angular_calibration_applied(NX_BOOLEAN): + doc: | + True when the angular calibration has been applied in the + electronics, false otherwise. + angular_calibration(NX_FLOAT): + doc: | + Angular calibration data. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + flatfield_applied(NX_BOOLEAN): + doc: | + True when the flat field correction has been applied in the + electronics, false otherwise. + flatfield(NX_FLOAT): + doc: | + Flat field correction data. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + flatfield_errors(NX_FLOAT): + doc: | + Errors of the flat field correction data. + The form flatfield_error is deprecated. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + pixel_mask_applied(NX_BOOLEAN): + doc: | + True when the pixel mask correction has been applied in the + electronics, false otherwise. + pixel_mask(NX_INT): + doc: | + The 32-bit pixel mask for the detector. Can be either one mask + for the whole dataset (i.e. an array with indices i, j) or + each frame can have its own mask (in which case it would be + an array with indices np, i, j). + + Contains a bit field for each pixel to signal dead, + blind or high or otherwise unwanted or undesirable pixels. + They have the following meaning: + + .. can't make a table here, a bullet list will have to do for now + + * bit 0: gap (pixel with no sensor) + * bit 1: dead + * bit 2: under responding + * bit 3: over responding + * bit 4: noisy + * bit 5: -undefined- + * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) + * bit 7: -undefined- + * bit 8: user defined mask (e.g. around beamstop) + * bits 9-30: -undefined- + * bit 31: virtual pixel (corner pixel with interpolated value) + + Normal data analysis software would + not take pixels into account + when a bit in (mask & 0x0000FFFF) is + set. Tag bit in the upper + two bytes would indicate special pixel + properties that normally + would not be a sole reason to reject the + intensity value (unless + lower bits are set. + + If the full bit depths is not required, providing a + mask with fewer bits is permissible. + + If needed, additional pixel masks can be specified by + including additional entries named pixel_mask_N, where + N is an integer. For example, a general bad pixel mask + could be specified in pixel_mask that indicates noisy + and dead pixels, and an additional pixel mask from + experiment-specific shadowing could be specified in + pixel_mask_2. The cumulative mask is the bitwise OR + of pixel_mask and any pixel_mask_N entries. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + image_key(NX_INT): + doc: | + This field allow to distinguish different types of exposure to the same detector "data" field. + Some techniques require frequent (re-)calibration inbetween measuremnts and this way of + recording the different measurements preserves the chronological order with is important for + correct processing. + + This is used for example in tomography (`:ref:`NXtomo`) sample projections, + dark and flat images, a magic number is recorded per frame. + + The key is as follows: + + * projection (sample) = 0 + * flat field = 1 + * dark field = 2 + * invalid = 3 + * background (no sample, but buffer where applicable) = 4 + + In cases where the data is of type :ref:`NXlog` this can also be an NXlog. + dimensions: + rank: 1 + dim: [[1, np]] + countrate_correction_applied(NX_BOOLEAN): + doc: | + Counting detectors usually are not able to measure all incoming particles, + especially at higher count-rates. Count-rate correction is applied to + account for these errors. + + True when count-rate correction has been applied, false otherwise. + countrate_correction_lookup_table(NX_NUMBER): + doc: | + The countrate_correction_lookup_table defines the LUT used for count-rate + correction. It maps a measured count :math:`c` to its corrected value + :math:`countrate\_correction\_lookup\_table[c]`. + + :math:`m` denotes the length of the table. + dimensions: + rank: 1 + dim: [[1, m]] + virtual_pixel_interpolation_applied(NX_BOOLEAN): + doc: | + True when virtual pixel interpolation has been applied, false otherwise. + + When virtual pixel interpolation is applied, values of some pixels may + contain interpolated values. For example, to account for space between + readout chips on a module, physical pixels on edges and corners between + chips may have larger sensor areas and counts may be distributed between + their logical pixels. + bit_depth_readout(NX_INT): + doc: | + How many bits the electronics reads per pixel. + With CCD's and single photon counting detectors, + this must not align with traditional integer sizes. + This can be 4, 8, 12, 14, 16, ... + detector_readout_time(NX_FLOAT): + unit: NX_TIME + doc: | + Time it takes to read the detector (typically milliseconds). + This is important to know for time resolved experiments. + trigger_delay_time(NX_FLOAT): + unit: NX_TIME + doc: | + Time it takes to start exposure after a trigger signal has been received. + This is the reaction time of the detector firmware after receiving the trigger signal + to when the detector starts to acquire the exposure, including any user set delay.. + This is important to know for time resolved experiments. + trigger_delay_time_set(NX_FLOAT): + unit: NX_TIME + doc: | + User-specified trigger delay. + trigger_internal_delay_time(NX_FLOAT): + unit: NX_TIME + doc: | + Time it takes to start exposure after a trigger signal has been received. + This is the reaction time of the detector hardware after receiving the + trigger signal to when the detector starts to acquire the exposure. + It forms the lower boundary of the trigger_delay_time when the user + does not request an additional delay. + trigger_dead_time(NX_FLOAT): + unit: NX_TIME + doc: | + Time during which no new trigger signal can be accepted. + Typically this is the + trigger_delay_time + exposure_time + readout_time. + This is important to know for time resolved experiments. + frame_time(NX_FLOAT): + unit: NX_TIME + doc: | + This is time for each frame. This is exposure_time + readout time. + dimensions: + rank: 1 + dim: [[1, nP]] + gain_setting(NX_CHAR): + doc: | + The gain setting of the detector. This is a detector-specific value + meant to document the gain setting of the detector during data + collection, for detectors with multiple available gain settings. + + Examples of gain settings include: + + * ``standard`` + * ``fast`` + * ``auto`` + * ``high`` + * ``medium`` + * ``low`` + * ``mixed high to medium`` + * ``mixed medium to low`` + + Developers are encouraged to use one of these terms, or to submit + additional terms to add to the list. + saturation_value(NX_NUMBER): + doc: | + The value at which the detector goes into saturation. + Especially common to CCD detectors, the data + is known to be invalid above this value. + + For example, given a saturation_value and an underload_value, the valid + pixels are those less than or equal to the saturation_value and greater + than or equal to the underload_value. + + The precise type should match the type of the data. + underload_value(NX_NUMBER): + doc: | + The lowest value at which pixels for this detector would be reasonably + measured. The data is known to be invalid below this value. + + For example, given a saturation_value and an underload_value, the valid + pixels are those less than or equal to the saturation_value and greater + than or equal to the underload_value. + + The precise type should match the type of the data. + number_of_cycles(NX_INT): + doc: | + CCD images are sometimes constructed by summing + together multiple short exposures in the + electronics. This reduces background etc. + This is the number of short exposures used to sum + images for an image. + sensor_material(NX_CHAR): + doc: | + At times, radiation is not directly sensed by the detector. + Rather, the detector might sense the output from some + converter like a scintillator. + This is the name of this converter material. + sensor_thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + At times, radiation is not directly sensed by the detector. + Rather, the detector might sense the output from some + converter like a scintillator. + This is the thickness of this converter material. + threshold_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + Single photon counter detectors can be adjusted + for a certain energy range in which they + work optimally. This is the energy setting for this. + (NXdetector_module): + doc: | + For use in special cases where the data in NXdetector + is represented in several parts, each with a separate geometry. + pixel_shape(choice): + (NXoff_geometry): + doc: | + Shape description of each pixel. Use only if all pixels in the detector + are of uniform shape. + (NXcylindrical_geometry): + doc: | + Shape description of each pixel. Use only if all pixels in the detector + are of uniform shape and require being described by cylinders. + detector_shape(choice): + (NXoff_geometry): + doc: | + Shape description of the whole detector. Use only if pixels in the + detector are not of uniform shape. + (NXcylindrical_geometry): + doc: | + Shape description of the whole detector. Use only if pixels in the + detector are not of uniform shape and require being described by cylinders. + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + amplifier_type(NX_CHAR): + doc: | + Type of electron amplifier, MCP, channeltron, etc. + detector_type(NX_CHAR): + doc: | + Description of the detector type, DLD, Phosphor+CCD, CMOS. + detector_voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Voltage applied to detector. + amplifier_voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Voltage applied to the amplifier. + amplifier_bias(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + The low voltage of the amplifier migh not be the ground. + sensor_size(NX_FLOAT): + unit: NX_LENGTH + doc: | + Size of each imaging sensor chip on the detector. + sensor_count(NX_INT): + unit: NX_UNITLESS + doc: | + Number of imaging sensor chips on the detector. + sensor_pixel_size(NX_FLOAT): + unit: NX_LENGTH + doc: | + Physical size of the pixels of the imaging chip on the detector. + sensor_pixels(NX_INT): + unit: NX_UNITLESS + doc: | + Number of raw active elements in each dimension. Important for swept scans. + (NXfabrication): + (NXdata): + doc: | + raw data output from the detector + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference point of the detector is the center of the first pixel. + In complex geometries the NXoff_geometry groups can be used to provide an unambiguous reference. + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 6b256ef0615dca7d8faf4a3bc04d3e62f29a1745e9cd35205e5f0bb9e2c6520c +# +# +# +# +# +# +# These symbols will be used below to illustrate the coordination of the +# rank and sizes of datasets and the preferred ordering of the +# dimensions. Each of these are optional (so the rank of the datasets +# will vary according to the situation) and the general ordering +# principle is slowest to fastest. The type of each dimension should +# follow the order of scan points, detector output (e.g. pixels), then +# time-of-flight (i.e. spectroscopy, spectrometry). Note that the output +# of a detector is not limited to single values (0D), lists (1D) and +# images (2), but three or higher dimensional arrays can be produced by +# a detector at each trigger. +# +# +# +# number of scan points (only present in scanning measurements) +# +# +# +# +# number of detector pixels in the first (slowest) direction +# +# +# +# +# number of detector pixels in the second (faster) direction +# +# +# +# +# number of detector pixels in the third (if necessary, fastest) +# direction +# +# +# +# +# number of bins in the time-of-flight histogram +# +# +# +# +# A detector, detector bank, or multidetector. +# +# +# +# Total time of flight +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Total time of flight +# +# +# +# +# +# In DAQ clock pulses +# +# +# +# +# +# +# Clock frequency in Hz +# +# +# +# +# +# Identifier for detector (pixels) +# Can be multidimensional, if needed +# +# +# +# +# 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. +# +# +# +# +# +# +# +# +# +# Title of measurement +# +# +# +# +# Integral of data as check of data integrity +# +# +# +# +# +# The best estimate of the uncertainty in the data value (array size should match the data field). Where +# possible, this should be the standard deviation, which has the same units +# as the data. The form data_error is deprecated. +# +# +# +# +# +# +# +# +# +# +# Offset from the detector center in x-direction. +# Can be multidimensional when needed. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# x-axis offset from detector center +# +# +# +# +# +# Offset from the detector center in the y-direction. +# Can be multidimensional when different values are required for each pixel. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# y-axis offset from detector center +# +# +# +# +# +# Offset from the detector center in the z-direction. +# Can be multidimensional when different values are required for each pixel. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# y-axis offset from detector center +# +# +# +# +# +# This is the distance to the previous component in the +# instrument; most often the sample. The usage depends on the +# nature of the detector: Most often it is the distance of the +# detector assembly. But there are irregular detectors. In this +# case the distance must be specified for each detector pixel. +# +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# +# +# +# +# +# This is the polar angle of the detector towards the previous +# component in the instrument; most often the sample. +# The usage depends on the +# nature of the detector. +# Most often it is the polar_angle of the detector assembly. +# But there are irregular detectors. +# In this +# case, the polar_angle must be specified for each detector pixel. +# +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# +# +# +# +# +# This is the azimuthal angle angle of the detector towards +# the previous component in the instrument; most often the sample. +# The usage depends on the +# nature of the detector. +# Most often it is the azimuthal_angle of the detector assembly. +# But there are irregular detectors. +# In this +# case, the azimuthal_angle must be specified for each detector pixel. +# +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# +# +# +# +# +# name/manufacturer/model/etc. information +# +# +# +# +# Serial number for the detector +# +# +# +# +# Local name for the detector +# +# +# +# +# Position and orientation of detector +# +# +# +# +# Solid angle subtended by the detector at the sample +# +# +# +# +# +# +# +# +# Size of each detector pixel. If it is scalar all pixels are the same size. +# +# +# +# +# +# +# +# +# Size of each detector pixel. If it is scalar all pixels are the same size +# +# +# +# +# +# +# +# +# Detector dead time +# +# +# +# +# +# +# +# +# +# Detector gas pressure +# +# +# +# +# +# +# +# +# maximum drift space dimension +# +# +# +# +# Crate number of detector +# +# +# +# +# +# +# +# Equivalent local term +# +# +# +# +# +# Slot number of detector +# +# +# +# +# +# +# +# Equivalent local term +# +# +# +# +# +# Input number of detector +# +# +# +# +# +# +# +# Equivalent local term +# +# +# +# +# +# Description of type such as He3 gas cylinder, He3 PSD, scintillator, +# fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, +# CMOS, ... +# +# +# +# +# Spectral efficiency of detector with respect to e.g. wavelength +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# efficiency of the detector +# +# +# +# +# +# +# +# +# +# This field can be two things: +# +# 1. For a pixel detector it provides the nominal wavelength +# for which the detector has been calibrated. +# +# 2. For other detectors this field has to be seen together with +# the efficiency field above. +# For some detectors, the efficiency is wavelength dependent. +# Thus this field provides the wavelength axis for the efficiency field. +# In this use case, the efficiency and wavelength arrays must +# have the same dimensionality. +# +# +# +# +# +# +# +# +# +# +# Real-time of the exposure (use this if exposure time varies for +# each array element, otherwise use ``count_time`` field). +# +# Most often there is a single real time value that is constant across +# an entire image frame. In such cases, only a 1-D array is needed. +# But there are detectors in which the real time +# changes per pixel. In that case, more than one dimension is needed. Therefore +# the rank of this field should be less than or equal to (detector rank + 1). +# +# +# +# +# +# +# +# +# +# start time for each frame, with the ``start`` attribute as absolute reference +# +# +# +# +# +# +# +# +# stop time for each frame, with the ``start`` attribute as absolute reference +# +# +# +# +# +# +# +# +# date of last calibration (geometry and/or efficiency) measurements +# +# +# +# +# summary of conversion of array data to pixels (e.g. polynomial +# approximations) and location of details of the calibrations +# +# +# +# +# How the detector is represented +# +# +# +# +# +# +# +# +# +# Elapsed actual counting time +# +# +# +# +# +# +# +# +# Use this group to provide other data related to this NXdetector group. +# +# +# +# +# In order to properly sort the order of the images taken in (for +# example) a tomography experiment, a sequence number is stored with each +# image. +# +# +# +# +# +# +# +# This is the x position where the direct beam would hit the detector. +# This is a length and can be outside of the actual +# detector. The length can be in physical units or pixels +# as documented by the units attribute. +# +# +# +# +# This is the y position where the direct beam would hit the detector. +# This is a length and can be outside of the actual +# detector. The length can be in physical units or pixels +# as documented by the units attribute. +# +# +# +# +# This is the start number of the first frame of a scan. In protein crystallography measurements one +# often scans a couple of frames on a give sample, then does something else, +# then returns to the same sample and scans some more frames. Each time with +# a new data file. This number helps concatenating such measurements. +# +# +# +# +# The diameter of a cylindrical detector +# +# +# +# +# The acquisition mode of the detector. +# +# +# +# +# +# +# +# +# +# +# +# +# True when the angular calibration has been applied in the +# electronics, false otherwise. +# +# +# +# +# Angular calibration data. +# +# +# +# +# +# +# +# +# True when the flat field correction has been applied in the +# electronics, false otherwise. +# +# +# +# +# Flat field correction data. +# +# +# +# +# +# +# +# +# Errors of the flat field correction data. +# The form flatfield_error is deprecated. +# +# +# +# +# +# +# +# +# True when the pixel mask correction has been applied in the +# electronics, false otherwise. +# +# +# +# +# The 32-bit pixel mask for the detector. Can be either one mask +# for the whole dataset (i.e. an array with indices i, j) or +# each frame can have its own mask (in which case it would be +# an array with indices np, i, j). +# +# Contains a bit field for each pixel to signal dead, +# blind or high or otherwise unwanted or undesirable pixels. +# They have the following meaning: +# +# .. can't make a table here, a bullet list will have to do for now +# +# * bit 0: gap (pixel with no sensor) +# * bit 1: dead +# * bit 2: under responding +# * bit 3: over responding +# * bit 4: noisy +# * bit 5: -undefined- +# * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) +# * bit 7: -undefined- +# * bit 8: user defined mask (e.g. around beamstop) +# * bits 9-30: -undefined- +# * bit 31: virtual pixel (corner pixel with interpolated value) +# +# Normal data analysis software would +# not take pixels into account +# when a bit in (mask & 0x0000FFFF) is +# set. Tag bit in the upper +# two bytes would indicate special pixel +# properties that normally +# would not be a sole reason to reject the +# intensity value (unless +# lower bits are set. +# +# If the full bit depths is not required, providing a +# mask with fewer bits is permissible. +# +# If needed, additional pixel masks can be specified by +# including additional entries named pixel_mask_N, where +# N is an integer. For example, a general bad pixel mask +# could be specified in pixel_mask that indicates noisy +# and dead pixels, and an additional pixel mask from +# experiment-specific shadowing could be specified in +# pixel_mask_2. The cumulative mask is the bitwise OR +# of pixel_mask and any pixel_mask_N entries. +# +# +# +# +# +# +# +# +# This field allow to distinguish different types of exposure to the same detector "data" field. +# Some techniques require frequent (re-)calibration inbetween measuremnts and this way of +# recording the different measurements preserves the chronological order with is important for +# correct processing. +# +# This is used for example in tomography (`:ref:`NXtomo`) sample projections, +# dark and flat images, a magic number is recorded per frame. +# +# The key is as follows: +# +# * projection (sample) = 0 +# * flat field = 1 +# * dark field = 2 +# * invalid = 3 +# * background (no sample, but buffer where applicable) = 4 +# +# In cases where the data is of type :ref:`NXlog` this can also be an NXlog. +# +# +# +# +# +# +# +# Counting detectors usually are not able to measure all incoming particles, +# especially at higher count-rates. Count-rate correction is applied to +# account for these errors. +# +# True when count-rate correction has been applied, false otherwise. +# +# +# +# +# The countrate_correction_lookup_table defines the LUT used for count-rate +# correction. It maps a measured count :math:`c` to its corrected value +# :math:`countrate\_correction\_lookup\_table[c]`. +# +# :math:`m` denotes the length of the table. +# +# +# +# +# +# +# +# True when virtual pixel interpolation has been applied, false otherwise. +# +# When virtual pixel interpolation is applied, values of some pixels may +# contain interpolated values. For example, to account for space between +# readout chips on a module, physical pixels on edges and corners between +# chips may have larger sensor areas and counts may be distributed between +# their logical pixels. +# +# +# +# +# How many bits the electronics reads per pixel. +# With CCD's and single photon counting detectors, +# this must not align with traditional integer sizes. +# This can be 4, 8, 12, 14, 16, ... +# +# +# +# +# Time it takes to read the detector (typically milliseconds). +# This is important to know for time resolved experiments. +# +# +# +# +# Time it takes to start exposure after a trigger signal has been received. +# This is the reaction time of the detector firmware after receiving the trigger signal +# to when the detector starts to acquire the exposure, including any user set delay.. +# This is important to know for time resolved experiments. +# +# +# +# +# User-specified trigger delay. +# +# +# +# +# Time it takes to start exposure after a trigger signal has been received. +# This is the reaction time of the detector hardware after receiving the +# trigger signal to when the detector starts to acquire the exposure. +# It forms the lower boundary of the trigger_delay_time when the user +# does not request an additional delay. +# +# +# +# +# Time during which no new trigger signal can be accepted. +# Typically this is the +# trigger_delay_time + exposure_time + readout_time. +# This is important to know for time resolved experiments. +# +# +# +# +# This is time for each frame. This is exposure_time + readout time. +# +# +# +# +# +# +# +# The gain setting of the detector. This is a detector-specific value +# meant to document the gain setting of the detector during data +# collection, for detectors with multiple available gain settings. +# +# Examples of gain settings include: +# +# * ``standard`` +# * ``fast`` +# * ``auto`` +# * ``high`` +# * ``medium`` +# * ``low`` +# * ``mixed high to medium`` +# * ``mixed medium to low`` +# +# Developers are encouraged to use one of these terms, or to submit +# additional terms to add to the list. +# +# +# +# +# The value at which the detector goes into saturation. +# Especially common to CCD detectors, the data +# is known to be invalid above this value. +# +# For example, given a saturation_value and an underload_value, the valid +# pixels are those less than or equal to the saturation_value and greater +# than or equal to the underload_value. +# +# The precise type should match the type of the data. +# +# +# +# +# The lowest value at which pixels for this detector would be reasonably +# measured. The data is known to be invalid below this value. +# +# For example, given a saturation_value and an underload_value, the valid +# pixels are those less than or equal to the saturation_value and greater +# than or equal to the underload_value. +# +# The precise type should match the type of the data. +# +# +# +# +# CCD images are sometimes constructed by summing +# together multiple short exposures in the +# electronics. This reduces background etc. +# This is the number of short exposures used to sum +# images for an image. +# +# +# +# +# At times, radiation is not directly sensed by the detector. +# Rather, the detector might sense the output from some +# converter like a scintillator. +# This is the name of this converter material. +# +# +# +# +# At times, radiation is not directly sensed by the detector. +# Rather, the detector might sense the output from some +# converter like a scintillator. +# This is the thickness of this converter material. +# +# +# +# +# Single photon counter detectors can be adjusted +# for a certain energy range in which they +# work optimally. This is the energy setting for this. +# +# +# +# +# For use in special cases where the data in NXdetector +# is represented in several parts, each with a separate geometry. +# +# +# +# +# +# Shape description of each pixel. Use only if all pixels in the detector +# are of uniform shape. +# +# +# +# +# Shape description of each pixel. Use only if all pixels in the detector +# are of uniform shape and require being described by cylinders. +# +# +# +# +# +# +# Shape description of the whole detector. Use only if pixels in the +# detector are not of uniform shape. +# +# +# +# +# Shape description of the whole detector. Use only if pixels in the +# detector are not of uniform shape and require being described by cylinders. +# +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# Type of electron amplifier, MCP, channeltron, etc. +# +# +# +# +# Description of the detector type, DLD, Phosphor+CCD, CMOS. +# +# +# +# +# Voltage applied to detector. +# +# +# +# +# Voltage applied to the amplifier. +# +# +# +# +# The low voltage of the amplifier migh not be the ground. +# +# +# +# +# Size of each imaging sensor chip on the detector. +# +# +# +# +# Number of imaging sensor chips on the detector. +# +# +# +# +# Physical size of the pixels of the imaging chip on the detector. +# +# +# +# +# Number of raw active elements in each dimension. Important for swept scans. +# +# +# +# +# raw data output from the detector +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# The reference point of the detector is the center of the first pixel. +# In complex geometries the NXoff_geometry groups can be used to provide an unambiguous reference. +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# diff --git a/base_classes/nyaml/NXinstrument.yaml b/base_classes/nyaml/NXinstrument.yaml new file mode 100644 index 0000000000..4607aa5ae5 --- /dev/null +++ b/base_classes/nyaml/NXinstrument.yaml @@ -0,0 +1,190 @@ +category: base +doc: | + 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. +type: group +NXinstrument(NXobject): + name: + doc: | + Name of instrument + \@short_name: + doc: | + short name for instrument, perhaps the acronym + energy_resolution(NX_FLOAT): + unit: NX_ENERGY + doc: | + Energy resolution of the experiment (FWHM or gaussian broadening) + momentum_resolution(NX_FLOAT): + unit: NX_WAVENUMBER + doc: | + Momentum resolution of the experiment (FWHM) + angular_resolution(NX_FLOAT): + unit: NX_ANGLE + doc: | + Angular resolution of the experiment (FWHM) + spatial_resolution(NX_FLOAT): + unit: NX_LENGTH + doc: | + Spatial resolution of the experiment (Airy disk radius) + temporal_resolution(NX_FLOAT): + unit: NX_TIME + doc: | + Temporal resolution of the experiment (FWHM) + (NXaperture): + (NXattenuator): + (NXbeam): + (NXbeam_stop): + (NXbending_magnet): + (NXcollimator): + (NXcollection): + (NXcapillary): + (NXcrystal): + (NXdetector): + (NXdetector_group): + (NXdisk_chopper): + (NXevent_data): + (NXfabrication): + (NXfermi_chopper): + (NXfilter): + (NXflipper): + (NXguide): + (NXinsertion_device): + (NXmirror): + (NXmoderator): + (NXmonochromator): + (NXpolarizer): + (NXpositioner): + (NXsource): + (NXtransformations)DIFFRACTOMETER: + (NXvelocity_selector): + (NXxraylens): + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 331d6037bd4c05402a42cab90e3df4c3115b21231d57ef54b1221e1ed859584d +# +# +# +# +# +# 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. +# +# +# +# Name of instrument +# +# +# +# short name for instrument, perhaps the acronym +# +# +# +# +# +# Energy resolution of the experiment (FWHM or gaussian broadening) +# +# +# +# +# Momentum resolution of the experiment (FWHM) +# +# +# +# +# Angular resolution of the experiment (FWHM) +# +# +# +# +# Spatial resolution of the experiment (Airy disk radius) +# +# +# +# +# Temporal resolution of the experiment (FWHM) +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# diff --git a/base_classes/nyaml/NXsensor.yaml b/base_classes/nyaml/NXsensor.yaml new file mode 100644 index 0000000000..a70f2a533e --- /dev/null +++ b/base_classes/nyaml/NXsensor.yaml @@ -0,0 +1,324 @@ +category: base +doc: | + A sensor used to monitor an external condition + + The condition itself is described in :ref:`NXenvironment`. +type: group +NXsensor(NXobject): + model: + doc: | + Sensor identification code/model number + name: + doc: | + Name for the sensor + short_name: + doc: | + Short name of sensor used e.g. on monitor display program + attached_to: + doc: | + where sensor is attached to ("sample" | "can") + geometry(NXgeometry): + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the beamstop and NXoff_geometry to describe its shape instead + doc: | + Defines the axes for logged vector quantities if they are not the global instrument axes. + measurement: + doc: | + name for measured signal + enumeration: [temperature, pH, magnetic_field, electric_field, conductivity, resistance, voltage, pressure, flow, stress, strain, shear, surface_pressure] + type: + doc: | + The type of hardware used for the measurement. + Examples (suggestions but not restrictions): + + :Temperature: + J | K | T | E | R | S | Pt100 | Rh/Fe + :pH: + Hg/Hg2Cl2 | Ag/AgCl | ISFET + :Ion selective electrode: + specify species; e.g. Ca2+ + :Magnetic field: + Hall + :Surface pressure: + wilhelmy plate + run_control(NX_BOOLEAN): + doc: | + Is data collection controlled or synchronised to this quantity: + 1=no, 0=to "value", 1=to "value_deriv1", etc. + high_trip_value(NX_FLOAT): + unit: NX_ANY + doc: | + Upper control bound of sensor reading if using run_control + low_trip_value(NX_FLOAT): + unit: NX_ANY + doc: | + Lower control bound of sensor reading if using run_control + value(NX_FLOAT): + unit: NX_ANY + doc: | + nominal setpoint or average value + - need [n] as may be a vector + dimensions: + dim: [[1, n]] + value_deriv1(NX_FLOAT): + unit: NX_ANY + doc: | + Nominal/average first derivative of value + e.g. strain rate + - same dimensions as "value" (may be a vector) + dimensions: + dim: [[1, ]] + dim_parameters: + ref: ['value'] + value_deriv2(NX_FLOAT): + unit: NX_ANY + doc: | + Nominal/average second derivative of value + - same dimensions as "value" (may be a vector) + dimensions: + dim: [[1, ]] + dim_parameters: + ref: ['value'] + value_log(NXlog): + doc: | + Time history of sensor readings + value_deriv1_log(NXlog): + doc: | + Time history of first derivative of sensor readings + value_deriv2_log(NXlog): + doc: | + Time history of second derivative of sensor readings + external_field_brief: + enumeration: [along beam, across beam, transverse, solenoidal, flow shear gradient, flow vorticity] + external_field_full(NXorientation): + doc: | + For complex external fields not satisfied by External_field_brief + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the sensor when necessary. + (NXfabrication): + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a sensor. + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# df8bc397cbcbf114091b84ed357f6312641ca9abbf2d51795c37802450e7e628 +# +# +# +# +# +# A sensor used to monitor an external condition +# +# The condition itself is described in :ref:`NXenvironment`. +# +# +# Sensor identification code/model number +# +# +# Name for the sensor +# +# +# Short name of sensor used e.g. on monitor display program +# +# +# where sensor is attached to ("sample" | "can") +# +# +# +# Defines the axes for logged vector quantities if they are not the global instrument axes. +# +# +# +# name for measured signal +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The type of hardware used for the measurement. +# Examples (suggestions but not restrictions): +# +# :Temperature: +# J | K | T | E | R | S | Pt100 | Rh/Fe +# :pH: +# Hg/Hg2Cl2 | Ag/AgCl | ISFET +# :Ion selective electrode: +# specify species; e.g. Ca2+ +# :Magnetic field: +# Hall +# :Surface pressure: +# wilhelmy plate +# +# +# +# +# Is data collection controlled or synchronised to this quantity: +# 1=no, 0=to "value", 1=to "value_deriv1", etc. +# +# +# +# +# Upper control bound of sensor reading if using run_control +# +# +# +# +# Lower control bound of sensor reading if using run_control +# +# +# +# +# nominal setpoint or average value +# - need [n] as may be a vector +# +# +# +# +# +# +# +# Nominal/average first derivative of value +# e.g. strain rate +# - same dimensions as "value" (may be a vector) +# +# +# +# +# +# +# +# Nominal/average second derivative of value +# - same dimensions as "value" (may be a vector) +# +# +# +# +# +# +# Time history of sensor readings +# +# +# Time history of first derivative of sensor readings +# +# +# Time history of second derivative of sensor readings +# +# +# +# +# +# +# +# +# +# +# +# +# For complex external fields not satisfied by External_field_brief +# +# +# +# This group describes the shape of the sensor when necessary. +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a sensor. +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# diff --git a/base_classes/nyaml/NXsource.yaml b/base_classes/nyaml/NXsource.yaml new file mode 100644 index 0000000000..1692b666ea --- /dev/null +++ b/base_classes/nyaml/NXsource.yaml @@ -0,0 +1,521 @@ +category: base +doc: | + The neutron or x-ray storage ring/facility. +type: group +NXsource(NXobject): + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + Effective distance from sample + Distance as seen by radiation from sample. This number should be negative + to signify that it is upstream of the sample. + name: + doc: | + Name of source + \@short_name: + doc: | + short name for source, perhaps the acronym + type: + doc: | + type of radiation source (pick one from the enumerated list and spell exactly) + enumeration: [Spallation Neutron Source, Pulsed Reactor Neutron Source, Reactor Neutron Source, Synchrotron X-ray Source, Pulsed Muon Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, Ion Source, UV Plasma Source, Metal Jet X-ray] + probe: + doc: | + type of radiation probe (pick one from the enumerated list and spell exactly) + enumeration: [neutron, x-ray, muon, electron, ultraviolet, visible light, positron, proton] + power(NX_FLOAT): + unit: NX_POWER + doc: | + Source power + emittance_x(NX_FLOAT): + unit: NX_EMITTANCE + doc: | + Source emittance (nm-rad) in X (horizontal) direction. + emittance_y(NX_FLOAT): + unit: NX_EMITTANCE + doc: | + Source emittance (nm-rad) in Y (horizontal) direction. + sigma_x(NX_FLOAT): + unit: NX_LENGTH + doc: | + particle beam size in x + sigma_y(NX_FLOAT): + unit: NX_LENGTH + doc: | + particle beam size in y + flux(NX_FLOAT): + unit: NX_FLUX + doc: | + Source intensity/area (example: s-1 cm-2) + energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + Source energy. + For storage rings, this would be the particle beam energy. + For X-ray tubes, this would be the excitation voltage. + current(NX_FLOAT): + unit: NX_CURRENT + doc: | + Accelerator, X-ray tube, or storage ring current + voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Accelerator voltage + frequency(NX_FLOAT): + unit: NX_FREQUENCY + doc: | + Frequency of pulsed source + period(NX_FLOAT): + unit: NX_PERIOD + doc: | + Period of pulsed source + target_material: + doc: | + Pulsed source target material + enumeration: [Ta, W, depleted_U, enriched_U, Hg, Pb, C] + notes(NXnote): + doc: | + any source/facility related messages/events that + occurred during the experiment + bunch_pattern(NXdata): + doc: | + For storage rings, description of the bunch pattern. + This is useful to describe irregular bunch patterns. + title: + doc: | + name of the bunch pattern + number_of_bunches(NX_INT): + doc: | + For storage rings, the number of bunches in use. + bunch_length(NX_FLOAT): + unit: NX_TIME + doc: | + For storage rings, temporal length of the bunch + bunch_distance(NX_FLOAT): + unit: NX_TIME + doc: | + For storage rings, time between bunches + pulse_width(NX_FLOAT): + unit: NX_TIME + doc: | + temporal width of source pulse + + # pulsed sources or storage rings could use this + pulse_shape(NXdata): + doc: | + source pulse shape + + # pulsed sources or storage rings could use this + mode: + doc: | + source operating mode + enumeration: + Single Bunch: + doc: | + for storage rings + Multi Bunch: + doc: | + for storage rings + + # other sources could add to this + + # other sources could add to this + top_up(NX_BOOLEAN): + doc: | + Is the synchrotron operating in top_up mode? + last_fill(NX_NUMBER): + unit: NX_CURRENT + doc: | + For storage rings, the current at the end of the most recent injection. + \@time: + type: NX_DATE_TIME + doc: | + date and time of the most recent injection. + photon_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + The center photon energy of the source, before it is + monochromatized or converted + center_wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + The center wavelength of the source, before it is + monochromatized or converted + pulse_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + For pulsed sources, the energy of a single pulse + peak_power(NX_FLOAT): + unit: NX_POWER + doc: | + For pulsed sources, the pulse energy divided + by the pulse duration + bunch_number_start(NX_INT): + doc: | + Some facilities tag each bunch. + First bunch of the measurement + bunch_number_end(NX_INT): + doc: | + Last bunch of the measurement + geometry(NXgeometry): + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the source and NXoff_geometry to describe its shape instead + doc: | + "Engineering" location of source. + (NXfabrication): + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the beam line component + distribution(NXdata): + doc: | + The wavelength or energy distribution of the source + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the + z axis. + + .. image:: source/source.png + :width: 40% + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 19f1ee4e446868766ab035145a5835ce38e26b04d8e8ee50bf641392cb5c3525 +# +# +# +# +# +# The neutron or x-ray storage ring/facility. +# +# +# +# Effective distance from sample +# Distance as seen by radiation from sample. This number should be negative +# to signify that it is upstream of the sample. +# +# +# +# +# Name of source +# +# +# +# short name for source, perhaps the acronym +# +# +# +# +# +# type of radiation source (pick one from the enumerated list and spell exactly) +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# type of radiation probe (pick one from the enumerated list and spell exactly) +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Source power +# +# +# +# +# Source emittance (nm-rad) in X (horizontal) direction. +# +# +# +# +# Source emittance (nm-rad) in Y (horizontal) direction. +# +# +# +# +# particle beam size in x +# +# +# +# +# particle beam size in y +# +# +# +# +# Source intensity/area (example: s-1 cm-2) +# +# +# +# +# Source energy. +# For storage rings, this would be the particle beam energy. +# For X-ray tubes, this would be the excitation voltage. +# +# +# +# +# Accelerator, X-ray tube, or storage ring current +# +# +# +# +# Accelerator voltage +# +# +# +# +# Frequency of pulsed source +# +# +# +# +# Period of pulsed source +# +# +# +# +# Pulsed source target material +# +# +# +# +# +# +# +# +# +# +# +# +# +# any source/facility related messages/events that +# occurred during the experiment +# +# +# +# +# For storage rings, description of the bunch pattern. +# This is useful to describe irregular bunch patterns. +# +# +# +# name of the bunch pattern +# +# +# +# +# +# For storage rings, the number of bunches in use. +# +# +# +# +# For storage rings, temporal length of the bunch +# +# +# +# +# For storage rings, time between bunches +# +# +# +# +# temporal width of source pulse +# +# +# +# +# +# source pulse shape +# +# +# +# +# +# source operating mode +# +# +# +# +# for storage rings +# +# +# +# +# for storage rings +# +# +# +# +# +# +# +# +# Is the synchrotron operating in top_up mode? +# +# +# +# +# For storage rings, the current at the end of the most recent injection. +# +# +# +# date and time of the most recent injection. +# +# +# +# +# +# The center photon energy of the source, before it is +# monochromatized or converted +# +# +# +# +# The center wavelength of the source, before it is +# monochromatized or converted +# +# +# +# +# For pulsed sources, the energy of a single pulse +# +# +# +# +# For pulsed sources, the pulse energy divided +# by the pulse duration +# +# +# +# +# Some facilities tag each bunch. +# First bunch of the measurement +# +# +# +# +# Last bunch of the measurement +# +# +# +# +# "Engineering" location of source. +# +# +# +# +# This group describes the shape of the beam line component +# +# +# +# +# The wavelength or energy distribution of the source +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the +# z axis. +# +# .. image:: source/source.png +# :width: 40% +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# diff --git a/contributed_definitions/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXcollectioncolumn.nxdl.xml index 3117648c3a..862b270c95 100644 --- a/contributed_definitions/NXcollectioncolumn.nxdl.xml +++ b/contributed_definitions/NXcollectioncolumn.nxdl.xml @@ -101,4 +101,5 @@ Individual lenses in the collection column section + diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml index 821edaae2d..3a7ac1db1e 100644 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + The symbols used in the schema to specify e.g. dimensions of arrays @@ -154,4 +154,5 @@ Individual lenses outside the main optics ensambles described by the subclasses + diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml index dd283a570b..6487fdb2ae 100644 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ b/contributed_definitions/NXenergydispersion.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + Subclass of NXelectronanalyser to describe the energy dispersion section of a photoelectron analyser. @@ -87,4 +87,5 @@ Individual lenses in the energy dispersive section + diff --git a/contributed_definitions/NXmanipulator.nxdl.xml b/contributed_definitions/NXmanipulator.nxdl.xml index ad59e06205..52d7330f40 100644 --- a/contributed_definitions/NXmanipulator.nxdl.xml +++ b/contributed_definitions/NXmanipulator.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + Extension of NXpositioner to include fields to describe the use of manipulators in photoemission experiments. @@ -79,6 +79,7 @@ Class to describe the motors that are used in the manipulator + Refers to the last transformation specifying the positon of the manipulator in diff --git a/contributed_definitions/nyaml/NXdetector.yaml b/contributed_definitions/nyaml/NXdetector.yaml new file mode 100644 index 0000000000..8fd286fc58 --- /dev/null +++ b/contributed_definitions/nyaml/NXdetector.yaml @@ -0,0 +1,1758 @@ +category: base +doc: | + A detector, detector bank, or multidetector. +symbols: + doc: | + These symbols will be used below to illustrate the coordination of the + rank and sizes of datasets and the preferred ordering of the + dimensions. Each of these are optional (so the rank of the datasets + will vary according to the situation) and the general ordering + principle is slowest to fastest. The type of each dimension should + follow the order of scan points, detector output (e.g. pixels), then + time-of-flight (i.e. spectroscopy, spectrometry). Note that the output + of a detector is not limited to single values (0D), lists (1D) and + images (2), but three or higher dimensional arrays can be produced by + a detector at each trigger. + nP: | + number of scan points (only present in scanning measurements) + i: | + number of detector pixels in the first (slowest) direction + j: | + number of detector pixels in the second (faster) direction + k: | + number of detector pixels in the third (if necessary, fastest) + direction + tof: | + number of bins in the time-of-flight histogram +type: group +(NXobject)NXdetector: + time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + doc: | + Total time of flight + dimensions: + rank: 1 + dim: [[1, tof+1]] + \@axis: + type: NX_POSINT + deprecated: | + see: https://github.com/nexusformat/definitions/issues/436 + enumeration: [3] + \@primary: + type: NX_POSINT + deprecated: | + see: https://github.com/nexusformat/definitions/issues/436 + enumeration: [1] + \@long_name: + doc: | + Total time of flight + raw_time_of_flight(NX_INT): + unit: NX_PULSES + doc: | + In DAQ clock pulses + dimensions: + rank: 1 + dim: [[1, tof+1]] + \@frequency: + type: NX_NUMBER + doc: | + Clock frequency in Hz + detector_number(NX_INT): + doc: | + Identifier for detector (pixels) + Can be multidimensional, if needed + data(NX_NUMBER): + unit: NX_ANY + doc: | + 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. + dimensions: + rank: 4 + dim: [[1, nP], [2, i], [3, j], [4, tof]] + \@long_name: + doc: | + Title of measurement + \@check_sum: + type: NX_INT + doc: | + Integral of data as check of data integrity + data_errors(NX_NUMBER): + unit: NX_ANY + doc: | + The best estimate of the uncertainty in the data value (array size should match the data field). Where + possible, this should be the standard deviation, which has the same units + as the data. The form data_error is deprecated. + dimensions: + rank: 4 + dim: [[1, nP], [2, i], [3, j], [4, tof]] + x_pixel_offset(NX_FLOAT): + unit: NX_LENGTH + doc: | + Offset from the detector center in x-direction. + Can be multidimensional when needed. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + \@axis: + type: NX_POSINT + deprecated: | + see: https://github.com/nexusformat/definitions/issues/436 + enumeration: [1] + \@primary: + type: NX_POSINT + deprecated: | + see: https://github.com/nexusformat/definitions/issues/436 + enumeration: [1] + \@long_name: + doc: | + x-axis offset from detector center + y_pixel_offset(NX_FLOAT): + unit: NX_LENGTH + doc: | + Offset from the detector center in the y-direction. + Can be multidimensional when different values are required for each pixel. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + \@axis: + type: NX_POSINT + deprecated: | + see: https://github.com/nexusformat/definitions/issues/436 + enumeration: [2] + \@primary: + type: NX_POSINT + deprecated: | + see: https://github.com/nexusformat/definitions/issues/436 + enumeration: [1] + \@long_name: + doc: | + y-axis offset from detector center + z_pixel_offset(NX_FLOAT): + unit: NX_LENGTH + doc: | + Offset from the detector center in the z-direction. + Can be multidimensional when different values are required for each pixel. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + \@axis: + type: NX_POSINT + deprecated: | + see: https://github.com/nexusformat/definitions/issues/436 + enumeration: [3] + \@primary: + type: NX_POSINT + deprecated: | + see: https://github.com/nexusformat/definitions/issues/436 + enumeration: [1] + \@long_name: + doc: | + y-axis offset from detector center + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the distance to the previous component in the + instrument; most often the sample. The usage depends on the + nature of the detector: Most often it is the distance of the + detector assembly. But there are irregular detectors. In this + case the distance must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. + dimensions: + rank: 3 + dim: [[1, nP], [2, i], [3, j]] + polar_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + This is the polar angle of the detector towards the previous + component in the instrument; most often the sample. + The usage depends on the + nature of the detector. + Most often it is the polar_angle of the detector assembly. + But there are irregular detectors. + In this + case, the polar_angle must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. + dimensions: + rank: 3 + dim: [[1, nP], [2, i], [3, j]] + azimuthal_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + This is the azimuthal angle angle of the detector towards + the previous component in the instrument; most often the sample. + The usage depends on the + nature of the detector. + Most often it is the azimuthal_angle of the detector assembly. + But there are irregular detectors. + In this + case, the azimuthal_angle must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. + dimensions: + rank: 3 + dim: [[1, nP], [2, i], [3, j]] + description: + doc: | + name/manufacturer/model/etc. information + serial_number: + doc: | + Serial number for the detector + local_name: + doc: | + Local name for the detector + (NXgeometry): + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the detector and NXoff_geometry to describe its shape instead + doc: | + Position and orientation of detector + solid_angle(NX_FLOAT): + unit: NX_SOLID_ANGLE + doc: | + Solid angle subtended by the detector at the sample + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + x_pixel_size(NX_FLOAT): + unit: NX_LENGTH + doc: | + Size of each detector pixel. If it is scalar all pixels are the same size. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + y_pixel_size(NX_FLOAT): + unit: NX_LENGTH + doc: | + Size of each detector pixel. If it is scalar all pixels are the same size + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + dead_time(NX_FLOAT): + unit: NX_TIME + doc: | + Detector dead time + dimensions: + rank: 3 + dim: [[1, nP], [2, i], [3, j]] + gas_pressure(NX_FLOAT): + unit: NX_PRESSURE + doc: | + Detector gas pressure + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + detection_gas_path(NX_FLOAT): + unit: NX_LENGTH + doc: | + maximum drift space dimension + crate(NX_INT): + doc: | + Crate number of detector + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + \@local_name: + doc: | + Equivalent local term + slot(NX_INT): + doc: | + Slot number of detector + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + \@local_name: + doc: | + Equivalent local term + input(NX_INT): + doc: | + Input number of detector + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + \@local_name: + doc: | + Equivalent local term + type: + doc: | + Description of type such as He3 gas cylinder, He3 PSD, scintillator, + fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, + CMOS, ... + efficiency(NXdata): + doc: | + Spectral efficiency of detector with respect to e.g. wavelength + \@signal: + enumeration: [efficiency] + \@axes: + + # TODO: clarify the various use cases + enumeration: [., . ., . . ., . . . ., wavelength] + \@wavelength_indices: + + # TODO: clarify the actual possibilities + enumeration: [0] + efficiency(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + efficiency of the detector + dimensions: + rank: 3 + dim: [[1, i], [2, j], [3, k]] + wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + This field can be two things: + + 1. For a pixel detector it provides the nominal wavelength + for which the detector has been calibrated. + + 2. For other detectors this field has to be seen together with + the efficiency field above. + For some detectors, the efficiency is wavelength dependent. + Thus this field provides the wavelength axis for the efficiency field. + In this use case, the efficiency and wavelength arrays must + have the same dimensionality. + dimensions: + rank: 3 + dim: [[1, i], [2, j], [3, k]] + real_time(NX_NUMBER): + unit: NX_TIME + doc: | + Real-time of the exposure (use this if exposure time varies for + each array element, otherwise use ``count_time`` field). + + Most often there is a single real time value that is constant across + an entire image frame. In such cases, only a 1-D array is needed. + But there are detectors in which the real time + changes per pixel. In that case, more than one dimension is needed. Therefore + the rank of this field should be less than or equal to (detector rank + 1). + dimensions: + rank: 3 + dim: [[1, nP], [2, i], [3, j]] + start_time(NX_FLOAT): + unit: NX_TIME + doc: | + start time for each frame, with the ``start`` attribute as absolute reference + dimensions: + rank: 1 + dim: [[1, nP]] + \@start: + type: NX_DATE_TIME + stop_time(NX_FLOAT): + unit: NX_TIME + doc: | + stop time for each frame, with the ``start`` attribute as absolute reference + dimensions: + rank: 1 + dim: [[1, nP]] + \@start: + type: NX_DATE_TIME + calibration_date(NX_DATE_TIME): + doc: | + date of last calibration (geometry and/or efficiency) measurements + calibration_method(NXnote): + doc: | + summary of conversion of array data to pixels (e.g. polynomial + approximations) and location of details of the calibrations + layout: + doc: | + How the detector is represented + enumeration: [point, linear, area] + count_time(NX_NUMBER): + unit: NX_TIME + doc: | + Elapsed actual counting time + dimensions: + rank: 1 + dim: [[1, nP]] + data_file(NXnote): + (NXcollection): + doc: | + Use this group to provide other data related to this NXdetector group. + sequence_number(NX_INT): + doc: | + In order to properly sort the order of the images taken in (for + example) a tomography experiment, a sequence number is stored with each + image. + dimensions: + rank: 1 + dim: [[1, nBrightFrames]] + beam_center_x(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the x position where the direct beam would hit the detector. + This is a length and can be outside of the actual + detector. The length can be in physical units or pixels + as documented by the units attribute. + beam_center_y(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the y position where the direct beam would hit the detector. + This is a length and can be outside of the actual + detector. The length can be in physical units or pixels + as documented by the units attribute. + frame_start_number(NX_INT): + doc: | + This is the start number of the first frame of a scan. In protein crystallography measurements one + often scans a couple of frames on a give sample, then does something else, + then returns to the same sample and scans some more frames. Each time with + a new data file. This number helps concatenating such measurements. + diameter(NX_FLOAT): + unit: NX_LENGTH + doc: | + The diameter of a cylindrical detector + acquisition_mode(NX_CHAR): + doc: | + The acquisition mode of the detector. + enumeration: [gated, triggered, summed, event, histogrammed, decimated] + angular_calibration_applied(NX_BOOLEAN): + doc: | + True when the angular calibration has been applied in the + electronics, false otherwise. + angular_calibration(NX_FLOAT): + doc: | + Angular calibration data. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + flatfield_applied(NX_BOOLEAN): + doc: | + True when the flat field correction has been applied in the + electronics, false otherwise. + flatfield(NX_FLOAT): + doc: | + Flat field correction data. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + flatfield_errors(NX_FLOAT): + doc: | + Errors of the flat field correction data. + The form flatfield_error is deprecated. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + pixel_mask_applied(NX_BOOLEAN): + doc: | + True when the pixel mask correction has been applied in the + electronics, false otherwise. + pixel_mask(NX_INT): + doc: | + The 32-bit pixel mask for the detector. Can be either one mask + for the whole dataset (i.e. an array with indices i, j) or + each frame can have its own mask (in which case it would be + an array with indices np, i, j). + + Contains a bit field for each pixel to signal dead, + blind or high or otherwise unwanted or undesirable pixels. + They have the following meaning: + + .. can't make a table here, a bullet list will have to do for now + + * bit 0: gap (pixel with no sensor) + * bit 1: dead + * bit 2: under responding + * bit 3: over responding + * bit 4: noisy + * bit 5: -undefined- + * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) + * bit 7: -undefined- + * bit 8: user defined mask (e.g. around beamstop) + * bits 9-30: -undefined- + * bit 31: virtual pixel (corner pixel with interpolated value) + + Normal data analysis software would + not take pixels into account + when a bit in (mask & 0x0000FFFF) is + set. Tag bit in the upper + two bytes would indicate special pixel + properties that normally + would not be a sole reason to reject the + intensity value (unless + lower bits are set. + + If the full bit depths is not required, providing a + mask with fewer bits is permissible. + + If needed, additional pixel masks can be specified by + including additional entries named pixel_mask_N, where + N is an integer. For example, a general bad pixel mask + could be specified in pixel_mask that indicates noisy + and dead pixels, and an additional pixel mask from + experiment-specific shadowing could be specified in + pixel_mask_2. The cumulative mask is the bitwise OR + of pixel_mask and any pixel_mask_N entries. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + image_key(NX_INT): + doc: | + This field allow to distinguish different types of exposure to the same detector "data" field. + Some techniques require frequent (re-)calibration inbetween measuremnts and this way of + recording the different measurements preserves the chronological order with is important for + correct processing. + + This is used for example in tomography (`:ref:`NXtomo`) sample projections, + dark and flat images, a magic number is recorded per frame. + + The key is as follows: + + * projection (sample) = 0 + * flat field = 1 + * dark field = 2 + * invalid = 3 + * background (no sample, but buffer where applicable) = 4 + + In cases where the data is of type :ref:`NXlog` this can also be an NXlog. + dimensions: + rank: 1 + dim: [[1, np]] + countrate_correction_applied(NX_BOOLEAN): + doc: | + Counting detectors usually are not able to measure all incoming particles, + especially at higher count-rates. Count-rate correction is applied to + account for these errors. + + True when count-rate correction has been applied, false otherwise. + countrate_correction_lookup_table(NX_NUMBER): + doc: | + The countrate_correction_lookup_table defines the LUT used for count-rate + correction. It maps a measured count :math:`c` to its corrected value + :math:`countrate\_correction\_lookup\_table[c]`. + + :math:`m` denotes the length of the table. + dimensions: + rank: 1 + dim: [[1, m]] + virtual_pixel_interpolation_applied(NX_BOOLEAN): + doc: | + True when virtual pixel interpolation has been applied, false otherwise. + + When virtual pixel interpolation is applied, values of some pixels may + contain interpolated values. For example, to account for space between + readout chips on a module, physical pixels on edges and corners between + chips may have larger sensor areas and counts may be distributed between + their logical pixels. + bit_depth_readout(NX_INT): + doc: | + How many bits the electronics reads per pixel. + With CCD's and single photon counting detectors, + this must not align with traditional integer sizes. + This can be 4, 8, 12, 14, 16, ... + detector_readout_time(NX_FLOAT): + unit: NX_TIME + doc: | + Time it takes to read the detector (typically milliseconds). + This is important to know for time resolved experiments. + trigger_delay_time(NX_FLOAT): + unit: NX_TIME + doc: | + Time it takes to start exposure after a trigger signal has been received. + This is the reaction time of the detector firmware after receiving the trigger signal + to when the detector starts to acquire the exposure, including any user set delay.. + This is important to know for time resolved experiments. + trigger_delay_time_set(NX_FLOAT): + unit: NX_TIME + doc: | + User-specified trigger delay. + trigger_internal_delay_time(NX_FLOAT): + unit: NX_TIME + doc: | + Time it takes to start exposure after a trigger signal has been received. + This is the reaction time of the detector hardware after receiving the + trigger signal to when the detector starts to acquire the exposure. + It forms the lower boundary of the trigger_delay_time when the user + does not request an additional delay. + trigger_dead_time(NX_FLOAT): + unit: NX_TIME + doc: | + Time during which no new trigger signal can be accepted. + Typically this is the + trigger_delay_time + exposure_time + readout_time. + This is important to know for time resolved experiments. + frame_time(NX_FLOAT): + unit: NX_TIME + doc: | + This is time for each frame. This is exposure_time + readout time. + dimensions: + rank: 1 + dim: [[1, nP]] + gain_setting(NX_CHAR): + doc: | + The gain setting of the detector. This is a detector-specific value + meant to document the gain setting of the detector during data + collection, for detectors with multiple available gain settings. + + Examples of gain settings include: + + * ``standard`` + * ``fast`` + * ``auto`` + * ``high`` + * ``medium`` + * ``low`` + * ``mixed high to medium`` + * ``mixed medium to low`` + + Developers are encouraged to use one of these terms, or to submit + additional terms to add to the list. + saturation_value(NX_NUMBER): + doc: | + The value at which the detector goes into saturation. + Especially common to CCD detectors, the data + is known to be invalid above this value. + + For example, given a saturation_value and an underload_value, the valid + pixels are those less than or equal to the saturation_value and greater + than or equal to the underload_value. + + The precise type should match the type of the data. + underload_value(NX_NUMBER): + doc: | + The lowest value at which pixels for this detector would be reasonably + measured. The data is known to be invalid below this value. + + For example, given a saturation_value and an underload_value, the valid + pixels are those less than or equal to the saturation_value and greater + than or equal to the underload_value. + + The precise type should match the type of the data. + number_of_cycles(NX_INT): + doc: | + CCD images are sometimes constructed by summing + together multiple short exposures in the + electronics. This reduces background etc. + This is the number of short exposures used to sum + images for an image. + sensor_material(NX_CHAR): + doc: | + At times, radiation is not directly sensed by the detector. + Rather, the detector might sense the output from some + converter like a scintillator. + This is the name of this converter material. + sensor_thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + At times, radiation is not directly sensed by the detector. + Rather, the detector might sense the output from some + converter like a scintillator. + This is the thickness of this converter material. + threshold_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + Single photon counter detectors can be adjusted + for a certain energy range in which they + work optimally. This is the energy setting for this. + (NXdetector_module): + doc: | + For use in special cases where the data in NXdetector + is represented in several parts, each with a separate geometry. + pixel_shape(choice): + (NXoff_geometry): + doc: | + Shape description of each pixel. Use only if all pixels in the detector + are of uniform shape. + (NXcylindrical_geometry): + doc: | + Shape description of each pixel. Use only if all pixels in the detector + are of uniform shape and require being described by cylinders. + detector_shape(choice): + (NXoff_geometry): + doc: | + Shape description of the whole detector. Use only if pixels in the + detector are not of uniform shape. + (NXcylindrical_geometry): + doc: | + Shape description of the whole detector. Use only if pixels in the + detector are not of uniform shape and require being described by cylinders. + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + amplifier_type(NX_CHAR): + doc: | + Type of electron amplifier, MCP, channeltron, etc. + detector_type(NX_CHAR): + doc: | + Description of the detector type, DLD, Phosphor+CCD, CMOS. + detector_voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Voltage applied to detector. + amplifier_voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Voltage applied to the amplifier. + amplifier_bias(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + The low voltage of the amplifier migh not be the ground. + sensor_size(NX_FLOAT): + unit: NX_LENGTH + doc: | + Size of each imaging sensor chip on the detector. + sensor_count(NX_INT): + unit: NX_UNITLESS + doc: | + Number of imaging sensor chips on the detector. + sensor_pixel_size(NX_FLOAT): + unit: NX_LENGTH + doc: | + Physical size of the pixels of the imaging chip on the detector. + sensor_pixels(NX_INT): + unit: NX_UNITLESS + doc: | + Number of raw active elements in each dimension. Important for swept scans. + (NXfabrication): + (NXdata): + doc: | + raw data output from the detector + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference point of the detector is the center of the first pixel. + In complex geometries the NXoff_geometry groups can be used to provide an unambiguous reference. + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 6b256ef0615dca7d8faf4a3bc04d3e62f29a1745e9cd35205e5f0bb9e2c6520c +# +# +# +# +# +# +# These symbols will be used below to illustrate the coordination of the +# rank and sizes of datasets and the preferred ordering of the +# dimensions. Each of these are optional (so the rank of the datasets +# will vary according to the situation) and the general ordering +# principle is slowest to fastest. The type of each dimension should +# follow the order of scan points, detector output (e.g. pixels), then +# time-of-flight (i.e. spectroscopy, spectrometry). Note that the output +# of a detector is not limited to single values (0D), lists (1D) and +# images (2), but three or higher dimensional arrays can be produced by +# a detector at each trigger. +# +# +# +# number of scan points (only present in scanning measurements) +# +# +# +# +# number of detector pixels in the first (slowest) direction +# +# +# +# +# number of detector pixels in the second (faster) direction +# +# +# +# +# number of detector pixels in the third (if necessary, fastest) +# direction +# +# +# +# +# number of bins in the time-of-flight histogram +# +# +# +# +# A detector, detector bank, or multidetector. +# +# +# +# Total time of flight +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Total time of flight +# +# +# +# +# +# In DAQ clock pulses +# +# +# +# +# +# +# Clock frequency in Hz +# +# +# +# +# +# Identifier for detector (pixels) +# Can be multidimensional, if needed +# +# +# +# +# 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. +# +# +# +# +# +# +# +# +# +# Title of measurement +# +# +# +# +# Integral of data as check of data integrity +# +# +# +# +# +# The best estimate of the uncertainty in the data value (array size should match the data field). Where +# possible, this should be the standard deviation, which has the same units +# as the data. The form data_error is deprecated. +# +# +# +# +# +# +# +# +# +# +# Offset from the detector center in x-direction. +# Can be multidimensional when needed. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# x-axis offset from detector center +# +# +# +# +# +# Offset from the detector center in the y-direction. +# Can be multidimensional when different values are required for each pixel. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# y-axis offset from detector center +# +# +# +# +# +# Offset from the detector center in the z-direction. +# Can be multidimensional when different values are required for each pixel. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# y-axis offset from detector center +# +# +# +# +# +# This is the distance to the previous component in the +# instrument; most often the sample. The usage depends on the +# nature of the detector: Most often it is the distance of the +# detector assembly. But there are irregular detectors. In this +# case the distance must be specified for each detector pixel. +# +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# +# +# +# +# +# This is the polar angle of the detector towards the previous +# component in the instrument; most often the sample. +# The usage depends on the +# nature of the detector. +# Most often it is the polar_angle of the detector assembly. +# But there are irregular detectors. +# In this +# case, the polar_angle must be specified for each detector pixel. +# +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# +# +# +# +# +# This is the azimuthal angle angle of the detector towards +# the previous component in the instrument; most often the sample. +# The usage depends on the +# nature of the detector. +# Most often it is the azimuthal_angle of the detector assembly. +# But there are irregular detectors. +# In this +# case, the azimuthal_angle must be specified for each detector pixel. +# +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# +# +# +# +# +# name/manufacturer/model/etc. information +# +# +# +# +# Serial number for the detector +# +# +# +# +# Local name for the detector +# +# +# +# +# Position and orientation of detector +# +# +# +# +# Solid angle subtended by the detector at the sample +# +# +# +# +# +# +# +# +# Size of each detector pixel. If it is scalar all pixels are the same size. +# +# +# +# +# +# +# +# +# Size of each detector pixel. If it is scalar all pixels are the same size +# +# +# +# +# +# +# +# +# Detector dead time +# +# +# +# +# +# +# +# +# +# Detector gas pressure +# +# +# +# +# +# +# +# +# maximum drift space dimension +# +# +# +# +# Crate number of detector +# +# +# +# +# +# +# +# Equivalent local term +# +# +# +# +# +# Slot number of detector +# +# +# +# +# +# +# +# Equivalent local term +# +# +# +# +# +# Input number of detector +# +# +# +# +# +# +# +# Equivalent local term +# +# +# +# +# +# Description of type such as He3 gas cylinder, He3 PSD, scintillator, +# fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, +# CMOS, ... +# +# +# +# +# Spectral efficiency of detector with respect to e.g. wavelength +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# efficiency of the detector +# +# +# +# +# +# +# +# +# +# This field can be two things: +# +# 1. For a pixel detector it provides the nominal wavelength +# for which the detector has been calibrated. +# +# 2. For other detectors this field has to be seen together with +# the efficiency field above. +# For some detectors, the efficiency is wavelength dependent. +# Thus this field provides the wavelength axis for the efficiency field. +# In this use case, the efficiency and wavelength arrays must +# have the same dimensionality. +# +# +# +# +# +# +# +# +# +# +# Real-time of the exposure (use this if exposure time varies for +# each array element, otherwise use ``count_time`` field). +# +# Most often there is a single real time value that is constant across +# an entire image frame. In such cases, only a 1-D array is needed. +# But there are detectors in which the real time +# changes per pixel. In that case, more than one dimension is needed. Therefore +# the rank of this field should be less than or equal to (detector rank + 1). +# +# +# +# +# +# +# +# +# +# start time for each frame, with the ``start`` attribute as absolute reference +# +# +# +# +# +# +# +# +# stop time for each frame, with the ``start`` attribute as absolute reference +# +# +# +# +# +# +# +# +# date of last calibration (geometry and/or efficiency) measurements +# +# +# +# +# summary of conversion of array data to pixels (e.g. polynomial +# approximations) and location of details of the calibrations +# +# +# +# +# How the detector is represented +# +# +# +# +# +# +# +# +# +# Elapsed actual counting time +# +# +# +# +# +# +# +# +# Use this group to provide other data related to this NXdetector group. +# +# +# +# +# In order to properly sort the order of the images taken in (for +# example) a tomography experiment, a sequence number is stored with each +# image. +# +# +# +# +# +# +# +# This is the x position where the direct beam would hit the detector. +# This is a length and can be outside of the actual +# detector. The length can be in physical units or pixels +# as documented by the units attribute. +# +# +# +# +# This is the y position where the direct beam would hit the detector. +# This is a length and can be outside of the actual +# detector. The length can be in physical units or pixels +# as documented by the units attribute. +# +# +# +# +# This is the start number of the first frame of a scan. In protein crystallography measurements one +# often scans a couple of frames on a give sample, then does something else, +# then returns to the same sample and scans some more frames. Each time with +# a new data file. This number helps concatenating such measurements. +# +# +# +# +# The diameter of a cylindrical detector +# +# +# +# +# The acquisition mode of the detector. +# +# +# +# +# +# +# +# +# +# +# +# +# True when the angular calibration has been applied in the +# electronics, false otherwise. +# +# +# +# +# Angular calibration data. +# +# +# +# +# +# +# +# +# True when the flat field correction has been applied in the +# electronics, false otherwise. +# +# +# +# +# Flat field correction data. +# +# +# +# +# +# +# +# +# Errors of the flat field correction data. +# The form flatfield_error is deprecated. +# +# +# +# +# +# +# +# +# True when the pixel mask correction has been applied in the +# electronics, false otherwise. +# +# +# +# +# The 32-bit pixel mask for the detector. Can be either one mask +# for the whole dataset (i.e. an array with indices i, j) or +# each frame can have its own mask (in which case it would be +# an array with indices np, i, j). +# +# Contains a bit field for each pixel to signal dead, +# blind or high or otherwise unwanted or undesirable pixels. +# They have the following meaning: +# +# .. can't make a table here, a bullet list will have to do for now +# +# * bit 0: gap (pixel with no sensor) +# * bit 1: dead +# * bit 2: under responding +# * bit 3: over responding +# * bit 4: noisy +# * bit 5: -undefined- +# * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) +# * bit 7: -undefined- +# * bit 8: user defined mask (e.g. around beamstop) +# * bits 9-30: -undefined- +# * bit 31: virtual pixel (corner pixel with interpolated value) +# +# Normal data analysis software would +# not take pixels into account +# when a bit in (mask & 0x0000FFFF) is +# set. Tag bit in the upper +# two bytes would indicate special pixel +# properties that normally +# would not be a sole reason to reject the +# intensity value (unless +# lower bits are set. +# +# If the full bit depths is not required, providing a +# mask with fewer bits is permissible. +# +# If needed, additional pixel masks can be specified by +# including additional entries named pixel_mask_N, where +# N is an integer. For example, a general bad pixel mask +# could be specified in pixel_mask that indicates noisy +# and dead pixels, and an additional pixel mask from +# experiment-specific shadowing could be specified in +# pixel_mask_2. The cumulative mask is the bitwise OR +# of pixel_mask and any pixel_mask_N entries. +# +# +# +# +# +# +# +# +# This field allow to distinguish different types of exposure to the same detector "data" field. +# Some techniques require frequent (re-)calibration inbetween measuremnts and this way of +# recording the different measurements preserves the chronological order with is important for +# correct processing. +# +# This is used for example in tomography (`:ref:`NXtomo`) sample projections, +# dark and flat images, a magic number is recorded per frame. +# +# The key is as follows: +# +# * projection (sample) = 0 +# * flat field = 1 +# * dark field = 2 +# * invalid = 3 +# * background (no sample, but buffer where applicable) = 4 +# +# In cases where the data is of type :ref:`NXlog` this can also be an NXlog. +# +# +# +# +# +# +# +# Counting detectors usually are not able to measure all incoming particles, +# especially at higher count-rates. Count-rate correction is applied to +# account for these errors. +# +# True when count-rate correction has been applied, false otherwise. +# +# +# +# +# The countrate_correction_lookup_table defines the LUT used for count-rate +# correction. It maps a measured count :math:`c` to its corrected value +# :math:`countrate\_correction\_lookup\_table[c]`. +# +# :math:`m` denotes the length of the table. +# +# +# +# +# +# +# +# True when virtual pixel interpolation has been applied, false otherwise. +# +# When virtual pixel interpolation is applied, values of some pixels may +# contain interpolated values. For example, to account for space between +# readout chips on a module, physical pixels on edges and corners between +# chips may have larger sensor areas and counts may be distributed between +# their logical pixels. +# +# +# +# +# How many bits the electronics reads per pixel. +# With CCD's and single photon counting detectors, +# this must not align with traditional integer sizes. +# This can be 4, 8, 12, 14, 16, ... +# +# +# +# +# Time it takes to read the detector (typically milliseconds). +# This is important to know for time resolved experiments. +# +# +# +# +# Time it takes to start exposure after a trigger signal has been received. +# This is the reaction time of the detector firmware after receiving the trigger signal +# to when the detector starts to acquire the exposure, including any user set delay.. +# This is important to know for time resolved experiments. +# +# +# +# +# User-specified trigger delay. +# +# +# +# +# Time it takes to start exposure after a trigger signal has been received. +# This is the reaction time of the detector hardware after receiving the +# trigger signal to when the detector starts to acquire the exposure. +# It forms the lower boundary of the trigger_delay_time when the user +# does not request an additional delay. +# +# +# +# +# Time during which no new trigger signal can be accepted. +# Typically this is the +# trigger_delay_time + exposure_time + readout_time. +# This is important to know for time resolved experiments. +# +# +# +# +# This is time for each frame. This is exposure_time + readout time. +# +# +# +# +# +# +# +# The gain setting of the detector. This is a detector-specific value +# meant to document the gain setting of the detector during data +# collection, for detectors with multiple available gain settings. +# +# Examples of gain settings include: +# +# * ``standard`` +# * ``fast`` +# * ``auto`` +# * ``high`` +# * ``medium`` +# * ``low`` +# * ``mixed high to medium`` +# * ``mixed medium to low`` +# +# Developers are encouraged to use one of these terms, or to submit +# additional terms to add to the list. +# +# +# +# +# The value at which the detector goes into saturation. +# Especially common to CCD detectors, the data +# is known to be invalid above this value. +# +# For example, given a saturation_value and an underload_value, the valid +# pixels are those less than or equal to the saturation_value and greater +# than or equal to the underload_value. +# +# The precise type should match the type of the data. +# +# +# +# +# The lowest value at which pixels for this detector would be reasonably +# measured. The data is known to be invalid below this value. +# +# For example, given a saturation_value and an underload_value, the valid +# pixels are those less than or equal to the saturation_value and greater +# than or equal to the underload_value. +# +# The precise type should match the type of the data. +# +# +# +# +# CCD images are sometimes constructed by summing +# together multiple short exposures in the +# electronics. This reduces background etc. +# This is the number of short exposures used to sum +# images for an image. +# +# +# +# +# At times, radiation is not directly sensed by the detector. +# Rather, the detector might sense the output from some +# converter like a scintillator. +# This is the name of this converter material. +# +# +# +# +# At times, radiation is not directly sensed by the detector. +# Rather, the detector might sense the output from some +# converter like a scintillator. +# This is the thickness of this converter material. +# +# +# +# +# Single photon counter detectors can be adjusted +# for a certain energy range in which they +# work optimally. This is the energy setting for this. +# +# +# +# +# For use in special cases where the data in NXdetector +# is represented in several parts, each with a separate geometry. +# +# +# +# +# +# Shape description of each pixel. Use only if all pixels in the detector +# are of uniform shape. +# +# +# +# +# Shape description of each pixel. Use only if all pixels in the detector +# are of uniform shape and require being described by cylinders. +# +# +# +# +# +# +# Shape description of the whole detector. Use only if pixels in the +# detector are not of uniform shape. +# +# +# +# +# Shape description of the whole detector. Use only if pixels in the +# detector are not of uniform shape and require being described by cylinders. +# +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# Type of electron amplifier, MCP, channeltron, etc. +# +# +# +# +# Description of the detector type, DLD, Phosphor+CCD, CMOS. +# +# +# +# +# Voltage applied to detector. +# +# +# +# +# Voltage applied to the amplifier. +# +# +# +# +# The low voltage of the amplifier migh not be the ground. +# +# +# +# +# Size of each imaging sensor chip on the detector. +# +# +# +# +# Number of imaging sensor chips on the detector. +# +# +# +# +# Physical size of the pixels of the imaging chip on the detector. +# +# +# +# +# Number of raw active elements in each dimension. Important for swept scans. +# +# +# +# +# raw data output from the detector +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# The reference point of the detector is the center of the first pixel. +# In complex geometries the NXoff_geometry groups can be used to provide an unambiguous reference. +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# diff --git a/contributed_definitions/nyaml/NXinstrument.yaml b/contributed_definitions/nyaml/NXinstrument.yaml new file mode 100644 index 0000000000..4607aa5ae5 --- /dev/null +++ b/contributed_definitions/nyaml/NXinstrument.yaml @@ -0,0 +1,190 @@ +category: base +doc: | + 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. +type: group +NXinstrument(NXobject): + name: + doc: | + Name of instrument + \@short_name: + doc: | + short name for instrument, perhaps the acronym + energy_resolution(NX_FLOAT): + unit: NX_ENERGY + doc: | + Energy resolution of the experiment (FWHM or gaussian broadening) + momentum_resolution(NX_FLOAT): + unit: NX_WAVENUMBER + doc: | + Momentum resolution of the experiment (FWHM) + angular_resolution(NX_FLOAT): + unit: NX_ANGLE + doc: | + Angular resolution of the experiment (FWHM) + spatial_resolution(NX_FLOAT): + unit: NX_LENGTH + doc: | + Spatial resolution of the experiment (Airy disk radius) + temporal_resolution(NX_FLOAT): + unit: NX_TIME + doc: | + Temporal resolution of the experiment (FWHM) + (NXaperture): + (NXattenuator): + (NXbeam): + (NXbeam_stop): + (NXbending_magnet): + (NXcollimator): + (NXcollection): + (NXcapillary): + (NXcrystal): + (NXdetector): + (NXdetector_group): + (NXdisk_chopper): + (NXevent_data): + (NXfabrication): + (NXfermi_chopper): + (NXfilter): + (NXflipper): + (NXguide): + (NXinsertion_device): + (NXmirror): + (NXmoderator): + (NXmonochromator): + (NXpolarizer): + (NXpositioner): + (NXsource): + (NXtransformations)DIFFRACTOMETER: + (NXvelocity_selector): + (NXxraylens): + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 331d6037bd4c05402a42cab90e3df4c3115b21231d57ef54b1221e1ed859584d +# +# +# +# +# +# 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. +# +# +# +# Name of instrument +# +# +# +# short name for instrument, perhaps the acronym +# +# +# +# +# +# Energy resolution of the experiment (FWHM or gaussian broadening) +# +# +# +# +# Momentum resolution of the experiment (FWHM) +# +# +# +# +# Angular resolution of the experiment (FWHM) +# +# +# +# +# Spatial resolution of the experiment (Airy disk radius) +# +# +# +# +# Temporal resolution of the experiment (FWHM) +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# diff --git a/contributed_definitions/nyaml/NXsensor.yaml b/contributed_definitions/nyaml/NXsensor.yaml new file mode 100644 index 0000000000..a70f2a533e --- /dev/null +++ b/contributed_definitions/nyaml/NXsensor.yaml @@ -0,0 +1,324 @@ +category: base +doc: | + A sensor used to monitor an external condition + + The condition itself is described in :ref:`NXenvironment`. +type: group +NXsensor(NXobject): + model: + doc: | + Sensor identification code/model number + name: + doc: | + Name for the sensor + short_name: + doc: | + Short name of sensor used e.g. on monitor display program + attached_to: + doc: | + where sensor is attached to ("sample" | "can") + geometry(NXgeometry): + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the beamstop and NXoff_geometry to describe its shape instead + doc: | + Defines the axes for logged vector quantities if they are not the global instrument axes. + measurement: + doc: | + name for measured signal + enumeration: [temperature, pH, magnetic_field, electric_field, conductivity, resistance, voltage, pressure, flow, stress, strain, shear, surface_pressure] + type: + doc: | + The type of hardware used for the measurement. + Examples (suggestions but not restrictions): + + :Temperature: + J | K | T | E | R | S | Pt100 | Rh/Fe + :pH: + Hg/Hg2Cl2 | Ag/AgCl | ISFET + :Ion selective electrode: + specify species; e.g. Ca2+ + :Magnetic field: + Hall + :Surface pressure: + wilhelmy plate + run_control(NX_BOOLEAN): + doc: | + Is data collection controlled or synchronised to this quantity: + 1=no, 0=to "value", 1=to "value_deriv1", etc. + high_trip_value(NX_FLOAT): + unit: NX_ANY + doc: | + Upper control bound of sensor reading if using run_control + low_trip_value(NX_FLOAT): + unit: NX_ANY + doc: | + Lower control bound of sensor reading if using run_control + value(NX_FLOAT): + unit: NX_ANY + doc: | + nominal setpoint or average value + - need [n] as may be a vector + dimensions: + dim: [[1, n]] + value_deriv1(NX_FLOAT): + unit: NX_ANY + doc: | + Nominal/average first derivative of value + e.g. strain rate + - same dimensions as "value" (may be a vector) + dimensions: + dim: [[1, ]] + dim_parameters: + ref: ['value'] + value_deriv2(NX_FLOAT): + unit: NX_ANY + doc: | + Nominal/average second derivative of value + - same dimensions as "value" (may be a vector) + dimensions: + dim: [[1, ]] + dim_parameters: + ref: ['value'] + value_log(NXlog): + doc: | + Time history of sensor readings + value_deriv1_log(NXlog): + doc: | + Time history of first derivative of sensor readings + value_deriv2_log(NXlog): + doc: | + Time history of second derivative of sensor readings + external_field_brief: + enumeration: [along beam, across beam, transverse, solenoidal, flow shear gradient, flow vorticity] + external_field_full(NXorientation): + doc: | + For complex external fields not satisfied by External_field_brief + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the sensor when necessary. + (NXfabrication): + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a sensor. + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# df8bc397cbcbf114091b84ed357f6312641ca9abbf2d51795c37802450e7e628 +# +# +# +# +# +# A sensor used to monitor an external condition +# +# The condition itself is described in :ref:`NXenvironment`. +# +# +# Sensor identification code/model number +# +# +# Name for the sensor +# +# +# Short name of sensor used e.g. on monitor display program +# +# +# where sensor is attached to ("sample" | "can") +# +# +# +# Defines the axes for logged vector quantities if they are not the global instrument axes. +# +# +# +# name for measured signal +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The type of hardware used for the measurement. +# Examples (suggestions but not restrictions): +# +# :Temperature: +# J | K | T | E | R | S | Pt100 | Rh/Fe +# :pH: +# Hg/Hg2Cl2 | Ag/AgCl | ISFET +# :Ion selective electrode: +# specify species; e.g. Ca2+ +# :Magnetic field: +# Hall +# :Surface pressure: +# wilhelmy plate +# +# +# +# +# Is data collection controlled or synchronised to this quantity: +# 1=no, 0=to "value", 1=to "value_deriv1", etc. +# +# +# +# +# Upper control bound of sensor reading if using run_control +# +# +# +# +# Lower control bound of sensor reading if using run_control +# +# +# +# +# nominal setpoint or average value +# - need [n] as may be a vector +# +# +# +# +# +# +# +# Nominal/average first derivative of value +# e.g. strain rate +# - same dimensions as "value" (may be a vector) +# +# +# +# +# +# +# +# Nominal/average second derivative of value +# - same dimensions as "value" (may be a vector) +# +# +# +# +# +# +# Time history of sensor readings +# +# +# Time history of first derivative of sensor readings +# +# +# Time history of second derivative of sensor readings +# +# +# +# +# +# +# +# +# +# +# +# +# For complex external fields not satisfied by External_field_brief +# +# +# +# This group describes the shape of the sensor when necessary. +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a sensor. +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXsource.yaml b/contributed_definitions/nyaml/NXsource.yaml new file mode 100644 index 0000000000..1692b666ea --- /dev/null +++ b/contributed_definitions/nyaml/NXsource.yaml @@ -0,0 +1,521 @@ +category: base +doc: | + The neutron or x-ray storage ring/facility. +type: group +NXsource(NXobject): + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + Effective distance from sample + Distance as seen by radiation from sample. This number should be negative + to signify that it is upstream of the sample. + name: + doc: | + Name of source + \@short_name: + doc: | + short name for source, perhaps the acronym + type: + doc: | + type of radiation source (pick one from the enumerated list and spell exactly) + enumeration: [Spallation Neutron Source, Pulsed Reactor Neutron Source, Reactor Neutron Source, Synchrotron X-ray Source, Pulsed Muon Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, Ion Source, UV Plasma Source, Metal Jet X-ray] + probe: + doc: | + type of radiation probe (pick one from the enumerated list and spell exactly) + enumeration: [neutron, x-ray, muon, electron, ultraviolet, visible light, positron, proton] + power(NX_FLOAT): + unit: NX_POWER + doc: | + Source power + emittance_x(NX_FLOAT): + unit: NX_EMITTANCE + doc: | + Source emittance (nm-rad) in X (horizontal) direction. + emittance_y(NX_FLOAT): + unit: NX_EMITTANCE + doc: | + Source emittance (nm-rad) in Y (horizontal) direction. + sigma_x(NX_FLOAT): + unit: NX_LENGTH + doc: | + particle beam size in x + sigma_y(NX_FLOAT): + unit: NX_LENGTH + doc: | + particle beam size in y + flux(NX_FLOAT): + unit: NX_FLUX + doc: | + Source intensity/area (example: s-1 cm-2) + energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + Source energy. + For storage rings, this would be the particle beam energy. + For X-ray tubes, this would be the excitation voltage. + current(NX_FLOAT): + unit: NX_CURRENT + doc: | + Accelerator, X-ray tube, or storage ring current + voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Accelerator voltage + frequency(NX_FLOAT): + unit: NX_FREQUENCY + doc: | + Frequency of pulsed source + period(NX_FLOAT): + unit: NX_PERIOD + doc: | + Period of pulsed source + target_material: + doc: | + Pulsed source target material + enumeration: [Ta, W, depleted_U, enriched_U, Hg, Pb, C] + notes(NXnote): + doc: | + any source/facility related messages/events that + occurred during the experiment + bunch_pattern(NXdata): + doc: | + For storage rings, description of the bunch pattern. + This is useful to describe irregular bunch patterns. + title: + doc: | + name of the bunch pattern + number_of_bunches(NX_INT): + doc: | + For storage rings, the number of bunches in use. + bunch_length(NX_FLOAT): + unit: NX_TIME + doc: | + For storage rings, temporal length of the bunch + bunch_distance(NX_FLOAT): + unit: NX_TIME + doc: | + For storage rings, time between bunches + pulse_width(NX_FLOAT): + unit: NX_TIME + doc: | + temporal width of source pulse + + # pulsed sources or storage rings could use this + pulse_shape(NXdata): + doc: | + source pulse shape + + # pulsed sources or storage rings could use this + mode: + doc: | + source operating mode + enumeration: + Single Bunch: + doc: | + for storage rings + Multi Bunch: + doc: | + for storage rings + + # other sources could add to this + + # other sources could add to this + top_up(NX_BOOLEAN): + doc: | + Is the synchrotron operating in top_up mode? + last_fill(NX_NUMBER): + unit: NX_CURRENT + doc: | + For storage rings, the current at the end of the most recent injection. + \@time: + type: NX_DATE_TIME + doc: | + date and time of the most recent injection. + photon_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + The center photon energy of the source, before it is + monochromatized or converted + center_wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + The center wavelength of the source, before it is + monochromatized or converted + pulse_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + For pulsed sources, the energy of a single pulse + peak_power(NX_FLOAT): + unit: NX_POWER + doc: | + For pulsed sources, the pulse energy divided + by the pulse duration + bunch_number_start(NX_INT): + doc: | + Some facilities tag each bunch. + First bunch of the measurement + bunch_number_end(NX_INT): + doc: | + Last bunch of the measurement + geometry(NXgeometry): + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the source and NXoff_geometry to describe its shape instead + doc: | + "Engineering" location of source. + (NXfabrication): + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the beam line component + distribution(NXdata): + doc: | + The wavelength or energy distribution of the source + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the + z axis. + + .. image:: source/source.png + :width: 40% + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 19f1ee4e446868766ab035145a5835ce38e26b04d8e8ee50bf641392cb5c3525 +# +# +# +# +# +# The neutron or x-ray storage ring/facility. +# +# +# +# Effective distance from sample +# Distance as seen by radiation from sample. This number should be negative +# to signify that it is upstream of the sample. +# +# +# +# +# Name of source +# +# +# +# short name for source, perhaps the acronym +# +# +# +# +# +# type of radiation source (pick one from the enumerated list and spell exactly) +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# type of radiation probe (pick one from the enumerated list and spell exactly) +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Source power +# +# +# +# +# Source emittance (nm-rad) in X (horizontal) direction. +# +# +# +# +# Source emittance (nm-rad) in Y (horizontal) direction. +# +# +# +# +# particle beam size in x +# +# +# +# +# particle beam size in y +# +# +# +# +# Source intensity/area (example: s-1 cm-2) +# +# +# +# +# Source energy. +# For storage rings, this would be the particle beam energy. +# For X-ray tubes, this would be the excitation voltage. +# +# +# +# +# Accelerator, X-ray tube, or storage ring current +# +# +# +# +# Accelerator voltage +# +# +# +# +# Frequency of pulsed source +# +# +# +# +# Period of pulsed source +# +# +# +# +# Pulsed source target material +# +# +# +# +# +# +# +# +# +# +# +# +# +# any source/facility related messages/events that +# occurred during the experiment +# +# +# +# +# For storage rings, description of the bunch pattern. +# This is useful to describe irregular bunch patterns. +# +# +# +# name of the bunch pattern +# +# +# +# +# +# For storage rings, the number of bunches in use. +# +# +# +# +# For storage rings, temporal length of the bunch +# +# +# +# +# For storage rings, time between bunches +# +# +# +# +# temporal width of source pulse +# +# +# +# +# +# source pulse shape +# +# +# +# +# +# source operating mode +# +# +# +# +# for storage rings +# +# +# +# +# for storage rings +# +# +# +# +# +# +# +# +# Is the synchrotron operating in top_up mode? +# +# +# +# +# For storage rings, the current at the end of the most recent injection. +# +# +# +# date and time of the most recent injection. +# +# +# +# +# +# The center photon energy of the source, before it is +# monochromatized or converted +# +# +# +# +# The center wavelength of the source, before it is +# monochromatized or converted +# +# +# +# +# For pulsed sources, the energy of a single pulse +# +# +# +# +# For pulsed sources, the pulse energy divided +# by the pulse duration +# +# +# +# +# Some facilities tag each bunch. +# First bunch of the measurement +# +# +# +# +# Last bunch of the measurement +# +# +# +# +# "Engineering" location of source. +# +# +# +# +# This group describes the shape of the beam line component +# +# +# +# +# The wavelength or energy distribution of the source +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the +# z axis. +# +# .. image:: source/source.png +# :width: 40% +# +# +# +# +# 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. +# +# +# From 9f94d68b84ce26d3991b647ef7a0a77e46ef180e Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 27 Sep 2023 14:38:55 +0200 Subject: [PATCH 0283/1012] Add general concepts first defined in NXmpes_xps sub app-def --- base_classes/NXsample.nxdl.xml | 6 + base_classes/nyaml/NXsample.yaml | 944 ++++++++++++++++++ .../NXelectronanalyser.nxdl.xml | 23 +- contributed_definitions/NXmpes.nxdl.xml | 61 +- .../nyaml/NXelectronanalyser.yaml | 277 +++++ contributed_definitions/nyaml/NXmpes.yaml | 52 +- 6 files changed, 1353 insertions(+), 10 deletions(-) create mode 100644 base_classes/nyaml/NXsample.yaml create mode 100644 contributed_definitions/nyaml/NXelectronanalyser.yaml diff --git a/base_classes/NXsample.nxdl.xml b/base_classes/NXsample.nxdl.xml index 3ac357d261..65bd90b83d 100644 --- a/base_classes/NXsample.nxdl.xml +++ b/base_classes/NXsample.nxdl.xml @@ -486,6 +486,12 @@ This group describes the shape of the sample + + + Physical form of the sample material. + Examples include single crystal, foil, pellet, powder, thin film, disc, foam, gas, liquid, amorphous. + + If the sample is a single crystal, add description of single crystal and unit diff --git a/base_classes/nyaml/NXsample.yaml b/base_classes/nyaml/NXsample.yaml new file mode 100644 index 0000000000..51e5ad7245 --- /dev/null +++ b/base_classes/nyaml/NXsample.yaml @@ -0,0 +1,944 @@ +category: base +doc: | + 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. +symbols: + doc: | + symbolic array lengths to be coordinated between various fields + n_comp: | + number of compositions + n_Temp: | + number of temperatures + n_eField: | + number of values in applied electric field + n_mField: | + number of values in applied magnetic field + n_pField: | + number of values in applied pressure field + n_sField: | + number of values in applied stress field +type: group +NXsample(NXobject): + name: + doc: | + Descriptive name of sample + sample_id: + doc: | + Identification number or signatures of the sample used. + chemical_formula: + doc: | + 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. + temperature(NX_FLOAT): + unit: NX_TEMPERATURE + doc: | + Sample temperature. This could be a scanned variable + dimensions: + rank: anyRank + + # could be any length + dim: [[1, n_Temp]] + electric_field(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Applied electric field + dimensions: + + # could be any length + dim: [[1, n_eField]] + \@direction: + enumeration: [x, y, z] + magnetic_field(NX_FLOAT): + unit: NX_ANY + doc: | + Applied magnetic field + dimensions: + + # could be any length + dim: [[1, n_mField]] + \@direction: + enumeration: [x, y, z] + stress_field(NX_FLOAT): + unit: NX_ANY + doc: | + Applied external stress field + dimensions: + + # could be any length + dim: [[1, n_sField]] + \@direction: + enumeration: [x, y, z] + pressure(NX_FLOAT): + unit: NX_PRESSURE + doc: | + Applied pressure + dimensions: + + # could be any length + dim: [[1, n_pField]] + changer_position(NX_INT): + unit: NX_UNITLESS + doc: | + Sample changer position + unit_cell_abc(NX_FLOAT): + unit: NX_LENGTH + doc: | + Crystallography unit cell parameters a, b, and c + dimensions: + dim: [[1, 3]] + unit_cell_alphabetagamma(NX_FLOAT): + unit: NX_ANGLE + doc: | + Crystallography unit cell parameters alpha, beta, and gamma + dimensions: + dim: [[1, 3]] + unit_cell(NX_FLOAT): + unit: NX_LENGTH + doc: | + Unit cell parameters (lengths and angles) + dimensions: + rank: 2 + dim: [[1, n_comp], [2, 6]] + unit_cell_volume(NX_FLOAT): + unit: NX_VOLUME + doc: | + Volume of the unit cell + dimensions: + rank: 1 + dim: [[1, n_comp]] + sample_orientation(NX_FLOAT): + unit: NX_ANGLE + doc: | + This will follow the Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + dimensions: + rank: 1 + dim: [[1, 3]] + orientation_matrix(NX_FLOAT): + doc: | + Orientation matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + dimensions: + rank: 3 + dim: [[1, n_comp], [2, 3], [3, 3]] + ub_matrix(NX_FLOAT): + doc: | + UB matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is + the multiplication of the orientation_matrix, given above, + with the :math:`B` matrix which + can be derived from the lattice constants. + dimensions: + rank: 3 + dim: [[1, n_comp], [2, 3], [3, 3]] + mass(NX_FLOAT): + unit: NX_MASS + doc: | + Mass of sample + dimensions: + rank: 1 + dim: [[1, n_comp]] + density(NX_FLOAT): + unit: NX_MASS_DENSITY + doc: | + Density of sample + dimensions: + rank: 1 + dim: [[1, n_comp]] + relative_molecular_mass(NX_FLOAT): + unit: NX_MASS + doc: | + Relative Molecular Mass of sample + dimensions: + rank: 1 + dim: [[1, n_comp]] + type: + enumeration: [sample, sample+can, can, sample+buffer, buffer, calibration sample, normalisation sample, simulated data, none, sample environment] + situation: + doc: | + 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. + enumeration: [air, vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere, sealed can, other] + description: + doc: | + Description of the sample + preparation_date(NX_DATE_TIME): + doc: | + Date of preparation of the sample + geometry(NXgeometry): + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the sample and NXoff_geometry to describe its shape instead + doc: | + The position and orientation of the center of mass of the sample + (NXbeam): + doc: | + Details of beam incident on sample - used to calculate sample/beam interaction + point + (NXsample_component): + doc: | + One group per sample component + This is the perferred way of recording per component information over the n_comp arrays + component: + doc: | + Details of the component of the sample and/or can + dimensions: + rank: 1 + dim: [[1, n_comp]] + sample_component: + doc: | + Type of component + dimensions: + rank: 1 + dim: [[1, n_comp]] + enumeration: [sample, can, atmosphere, kit] + concentration(NX_FLOAT): + unit: NX_MASS_DENSITY + doc: | + Concentration of each component + dimensions: + rank: 1 + dim: [[1, n_comp]] + volume_fraction(NX_FLOAT): + doc: | + Volume fraction of each component + dimensions: + rank: 1 + dim: [[1, n_comp]] + scattering_length_density(NX_FLOAT): + unit: NX_SCATTERING_LENGTH_DENSITY + doc: | + Scattering length density of each component + dimensions: + rank: 1 + dim: [[1, n_comp]] + unit_cell_class: + doc: | + In case it is all we know and we want to record/document it + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + space_group: + doc: | + Crystallographic space group + dimensions: + dim: [[1, n_comp]] + point_group: + doc: | + Crystallographic point group, deprecated if space_group present + dimensions: + dim: [[1, n_comp]] + path_length(NX_FLOAT): + unit: NX_LENGTH + doc: | + Path length through sample/can for simple case when + it does not vary with scattering direction + path_length_window(NX_FLOAT): + unit: NX_LENGTH + doc: | + Thickness of a beam entry/exit window on the can (mm) + - assumed same for entry and exit + thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + sample thickness + transmission(NXdata): + doc: | + As a function of Wavelength + temperature_log(NXlog): + deprecated: | + use ``temperature``, see: https://github.com/nexusformat/definitions/issues/816 + doc: | + temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value + temperature_env(NXenvironment): + doc: | + Additional sample temperature environment information + magnetic_field(NXlog): + doc: | + magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value + magnetic_field_log(NXlog): + deprecated: | + use ``magnetic_field``, see: https://github.com/nexusformat/definitions/issues/816 + doc: | + magnetic_field_log.value is a link to e.g. + magnetic_field_env.sensor1.value_log.value + magnetic_field_env(NXenvironment): + doc: | + Additional sample magnetic environment information + external_DAC(NX_FLOAT): + unit: NX_ANY + doc: | + value sent to user's sample setup + external_ADC(NXlog): + doc: | + logged value (or logic state) read from user's setup + short_title: + doc: | + 20 character fixed length sample description for legends + + # How is the string length limitation imposed by the XSD? + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Optional rotation angle for the case when the powder diagram has + been obtained through an omega-2theta scan like from a traditional + single detector powder diffractometer. + Note, it is recommended to use NXtransformations instead. + x_translation(NX_FLOAT): + unit: NX_LENGTH + doc: | + Translation of the sample along the X-direction of the laboratory coordinate system + Note, it is recommended to use NXtransformations instead. + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + Translation of the sample along the Z-direction of the laboratory coordinate system. + Note, it is recommended to use NXtransformations instead. + (NXpositioner): + doc: | + Any positioner (motor, PZT, ...) used to locate the sample + (NXoff_geometry): + + # exists: ['min', '0'] + doc: | + This group describes the shape of the sample + physical_form: + doc: + Physical form of the sample material. + + Examples include single crystal, foil, pellet, powder, thin film, disc, foam, gas, + liquid, amorphous. + (NXsingle_crystal): + doc: | + If the sample is a single crystal, add description of single crystal and unit + cell. + (NXsample_component_set): + doc: | + Set of sample components and their configuration. + There can only be one NXsample_component_set in one component. + + # exists: [max, 1] + (NXsubstance): + doc: | + If the sample is made from a pure substance and cannot be further divided using + NXsample_component. + + # exists: [max, 1] + (NXfabrication): + doc: | + Details about the sample vendor (company or research group) + (NXenvironment): + + # eventually, this should be stored in the application definitions + doc: | + Any environmental or external stimuli/measurements. + These can include, among others: + applied pressure, surrounding gas phase and gas pressure, + external electric/magnetic/mechanical fields, temperature, ... + (NXsample_history): + doc: | + A set of physical processes that occurred to the sample prior/during experiment. + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on: + doc: | + 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. + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 359e67b69525d94347bd6db9aa776e2c77b3e87b9a30b4d6a3e90ec29253c59c +# +# +# +# +# +# +# symbolic array lengths to be coordinated between various fields +# +# +# +# number of compositions +# +# +# +# +# number of temperatures +# +# +# +# +# number of values in applied electric field +# +# +# +# +# number of values in applied magnetic field +# +# +# +# +# number of values in applied pressure field +# +# +# +# +# number of values in applied stress field +# +# +# +# +# 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. +# +# +# +# Descriptive name of sample +# +# +# +# +# Identification number or signatures of the sample used. +# +# +# +# +# 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. +# +# +# +# +# Sample temperature. This could be a scanned variable +# +# +# +# +# +# +# +# +# Applied electric field +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Applied magnetic field +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Applied external stress field +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Applied pressure +# +# +# +# +# +# +# +# +# Sample changer position +# +# +# +# +# Crystallography unit cell parameters a, b, and c +# +# +# +# +# +# +# +# Crystallography unit cell parameters alpha, beta, and gamma +# +# +# +# +# +# +# +# Unit cell parameters (lengths and angles) +# +# +# +# +# +# +# +# +# Volume of the unit cell +# +# +# +# +# +# +# +# This will follow the Busing-Levy convention: +# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 +# +# +# +# +# +# +# +# Orientation matrix of single crystal sample using Busing-Levy convention: +# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 +# +# +# +# +# +# +# +# +# +# UB matrix of single crystal sample using Busing-Levy convention: +# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is +# the multiplication of the orientation_matrix, given above, +# with the :math:`B` matrix which +# can be derived from the lattice constants. +# +# +# +# +# +# +# +# +# +# Mass of sample +# +# +# +# +# +# +# +# Density of sample +# +# +# +# +# +# +# +# Relative Molecular Mass of sample +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# 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. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Description of the sample +# +# +# +# +# Date of preparation of the sample +# +# +# +# +# The position and orientation of the center of mass of the sample +# +# +# +# +# Details of beam incident on sample - used to calculate sample/beam interaction +# point +# +# +# +# +# One group per sample component +# This is the perferred way of recording per component information over the n_comp arrays +# +# +# +# +# Details of the component of the sample and/or can +# +# +# +# +# +# +# +# Type of component +# +# +# +# +# +# +# +# +# +# +# +# +# +# Concentration of each component +# +# +# +# +# +# +# +# Volume fraction of each component +# +# +# +# +# +# +# +# Scattering length density of each component +# +# +# +# +# +# +# +# In case it is all we know and we want to record/document it +# +# +# +# +# +# +# +# +# +# +# +# +# +# Crystallographic space group +# +# +# +# +# +# +# +# Crystallographic point group, deprecated if space_group present +# +# +# +# +# +# +# +# Path length through sample/can for simple case when +# it does not vary with scattering direction +# +# +# +# +# Thickness of a beam entry/exit window on the can (mm) +# - assumed same for entry and exit +# +# +# +# +# sample thickness +# +# +# +# +# As a function of Wavelength +# +# +# +# +# temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value +# +# +# +# +# Additional sample temperature environment information +# +# +# +# +# magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value +# +# +# +# +# magnetic_field_log.value is a link to e.g. +# magnetic_field_env.sensor1.value_log.value +# +# +# +# +# Additional sample magnetic environment information +# +# +# +# +# value sent to user's sample setup +# +# +# +# +# logged value (or logic state) read from user's setup +# +# +# +# +# 20 character fixed length sample description for legends +# +# +# +# +# +# Optional rotation angle for the case when the powder diagram has +# been obtained through an omega-2theta scan like from a traditional +# single detector powder diffractometer. +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# Translation of the sample along the X-direction of the laboratory coordinate system +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# Translation of the sample along the Z-direction of the laboratory coordinate system. +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# Any positioner (motor, PZT, ...) used to locate the sample +# +# +# +# +# +# This group describes the shape of the sample +# +# +# +# +# If the sample is a single crystal, add description of single crystal and unit +# cell. +# +# +# +# +# Set of sample components and their configuration. +# There can only be one NXsample_component_set in one component. +# +# +# +# +# +# If the sample is made from a pure substance and cannot be further divided using +# NXsample_component. +# +# +# +# +# +# Details about the sample vendor (company or research group) +# +# +# +# +# +# Any environmental or external stimuli/measurements. +# These can include, among others: +# applied pressure, surrounding gas phase and gas pressure, +# external electric/magnetic/mechanical fields, temperature, ... +# +# +# +# +# A set of physical processes that occurred to the sample prior/during experiment. +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml index 821edaae2d..d829dd38ce 100644 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + The symbols used in the schema to specify e.g. dimensions of arrays @@ -56,6 +56,27 @@ + + + Work function of the instrumeter. + + The work function of a uniform surface of a conductor is defined as + the minimum energy required to remove an electron from the interior of the + conductor to just outside the surface. + + The kinetic energy :math:`E_K` of a photoelectron emitted from an energy-level with + binding energy :math:`E_B` below the Fermi level is given by, :math:`E_K = h\nu - E_B - e \phi_m`, + where :math:`\phi_m`is the work function of the sample material. In PES measurement, + the sample and the spectrometer (with work function :math:`\phi_s`) are electrically connected, + resulting in a contact potential difference :math:`\Delta(\phi) = \phi_m - \phi_s` due to the + difference in local vacuum level between the sample and spectrometer. The measured kinetic energy + of a photoelectron in PES is therefore given by + :math:`E_K^{meas} = h\nu - E_B + \Delta \Phi = h\nu - E_B - e \phi_s`. As a result, the measured + kinetic energy :math:`E_K^{meas}` of a photoelectron is independent of the sample work function. + Nonetheless, the work function :math:`\phi_s` needs to be know to accurately determine the binding + energy scale. + + Energy resolution of the electron analyser (FWHM of gaussian broadening) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index a611ccd8ae..848fb470c3 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -230,6 +230,16 @@ Optional constant settings (like lens focusing parameters on the sample: positio additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + Size, position and shape of the iris inserted in the column. + + The iris is an aperture in the lens with a variable diameter which can reduce the number of + electrons entering the analyzer. + + To add additional or other slits use the APERTURE group of NXcollectioncolumn. + + @@ -251,14 +261,16 @@ Optional constant settings (like lens focusing parameters on the sample: positio - Size, position and shape of the entrance slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. + Size, position and shape of the entrance slit in dispersive analyzers. + + To add additional or other slits use the APERTURE group of NXenergydispersion. - Size, position and shape of the exit slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. + Size, position and shape of the exit slit in dispersive analyzers. + + To add additional or other slits use the APERTURE group of NXenergydispersion. @@ -377,6 +389,37 @@ Optional constant settings (like lens focusing parameters on the sample: positio + + + + Have the energy axes been adjusted (e.g., in cases where samples are not + conductive)? + + + + + Emission line which was used for the calibration + + + + + Offset between measured binding energy and calibrated binding energy of the + emission line." + + + + + The binding energy (in units of eV) that the specified emission line appeared at, + after adjusting the binding energy scale . + + + + + This is the calibrated energy axis to be used for data plotting. + This should be a link to /entry/data/energy." + + + @@ -403,6 +446,7 @@ Optional constant settings (like lens focusing parameters on the sample: positio elements from each component must be included in `atom_types`. + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last @@ -455,6 +499,15 @@ Optional constant settings (like lens focusing parameters on the sample: positio actual encoder position in NXinstrument or calibrated axes in NXprocess. + + + The calibrated energy axis can be either in binding or kinetic energy. + This should be a link to either + /entry/process/energy_calibration/calibrated_axis or + /entry/process/energy_correction/calibrated_axis. + + + diff --git a/contributed_definitions/nyaml/NXelectronanalyser.yaml b/contributed_definitions/nyaml/NXelectronanalyser.yaml new file mode 100644 index 0000000000..8d6a23499f --- /dev/null +++ b/contributed_definitions/nyaml/NXelectronanalyser.yaml @@ -0,0 +1,277 @@ +category: base +doc: | + Subclass of NXinstrument to describe a photoelectron analyser. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays + nfa: | + Number of fast axes (axes acquired simultaneously, without scanning a + physical quantity) + nsa: | + Number of slow axes (axes acquired scanning a physical quantity) +type: group +NXelectronanalyser(NXobject): + description(NX_CHAR): + doc: | + Free text description of the type of the detector + name(NX_CHAR): + doc: | + Name or model of the equipment + \@short_name: + type: NX_CHAR + doc: | + Acronym or other shorthand name + work_function(NX_FLOAT): + doc: | + Work function of the instrumeter. + + The work function of a uniform surface of a conductor is defined as + the minimum energy required to remove an electron from the interior of the + conductor to just outside the surface. + + The kinetic energy :math:`E_K` of a photoelectron emitted from an energy-level with + binding energy :math:`E_B` below the Fermi level is given by, :math:`E_K = h\nu - E_B - e \phi_m`, + where :math:`\phi_m`is the work function of the sample material. In PES measurement, + the sample and the spectrometer (with work function :math:`\phi_s`) are electrically connected, + resulting in a contact potential difference :math:`\Delta(\phi) = \phi_m - \phi_s` due to the + difference in local vacuum level between the sample and spectrometer. The measured kinetic energy + of a photoelectron in PES is therefore given by + :math:`E_K^{meas} = h\nu - E_B + \Delta \Phi = h\nu - E_B - e \phi_s`. As a result, the measured + kinetic energy :math:`E_K^{meas}` of a photoelectron is independent of the sample work function. + Nonetheless, the work function :math:`\phi_s` needs to be know to accurately determine the binding + energy scale. + unit: NX_ENERGY + energy_resolution(NX_FLOAT): + unit: NX_ENERGY + doc: | + Energy resolution of the electron analyser (FWHM of gaussian broadening) + momentum_resolution(NX_FLOAT): + unit: NX_WAVENUMBER + doc: | + Momentum resolution of the electron analyser (FWHM) + angular_resolution(NX_FLOAT): + unit: NX_ANGLE + doc: | + Angular resolution of the electron analyser (FWHM) + spatial_resolution(NX_FLOAT): + unit: NX_LENGTH + doc: | + Spatial resolution of the electron analyser (Airy disk radius) + fast_axes(NX_CHAR): + doc: | + 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. + dimensions: + rank: 1 + dim: [[1, nfa]] + slow_axes(NX_CHAR): + doc: | + List of the axes that are acquired by scanning a physical parameter, listed in + order of decreasing speed. See fast_axes for examples. + dimensions: + rank: 1 + dim: [[1, nsa]] + depends_on(NX_CHAR): + doc: | + Refers to the last transformation specifying the positon of the manipulator in + the NXtransformations chain. + (NXtransformations): + doc: | + 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. + (NXcollectioncolumn): + doc: | + Describes the electron collection (spatial and momentum imaging) column + (NXenergydispersion): + doc: | + Describes the energy dispersion section + (NXspindispersion): + doc: | + Describes the spin dispersion section + (NXdetector): + doc: | + Describes the electron detector + (NXdeflector): + doc: | + Deflectors outside the main optics ensambles described by the subclasses + (NXlens_em): + doc: | + Individual lenses outside the main optics ensambles described by the subclasses + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 4d6adccbc47a79bb1c1a6e54f879331198408c0f0a4503f6aa9093df58cdea12 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays +# +# +# +# Number of fast axes (axes acquired simultaneously, without scanning a +# physical quantity) +# +# +# +# +# Number of slow axes (axes acquired scanning a physical quantity) +# +# +# +# +# Subclass of NXinstrument to describe a photoelectron analyser. +# +# +# +# Free text description of the type of the detector +# +# +# +# +# Name or model of the equipment +# +# +# +# Acronym or other shorthand name +# +# +# +# +# +# Energy resolution of the electron analyser (FWHM of gaussian broadening) +# +# +# +# +# Momentum resolution of the electron analyser (FWHM) +# +# +# +# +# Angular resolution of the electron analyser (FWHM) +# +# +# +# +# Spatial resolution of the electron analyser (Airy disk radius) +# +# +# +# +# List of the axes that are acquired simultaneously by the detector. +# These refer only to the experimental variables recorded by the electron analyser. +# Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. +# +# .. csv-table:: Examples +# :header: "Mode", "fast_axes", "slow_axes" +# +# Hemispherical in ARPES mode, "['energy', 'kx']","" +# "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] +# "Tof", "['energy', 'kx', 'ky']","" +# "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" +# +# Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. +# If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. +# +# +# +# +# +# +# +# List of the axes that are acquired by scanning a physical parameter, listed in +# order of decreasing speed. See fast_axes for examples. +# +# +# +# +# +# +# +# Refers to the last transformation specifying the positon of the manipulator in +# the NXtransformations chain. +# +# +# +# +# Collection of axis-based translations and rotations to describe the location and +# geometry of the electron analyser as a component in the instrument. Conventions +# from the NXtransformations base class are used. In principle, the McStas +# coordinate system is used. The first transformation has to point either to +# another component of the system or . (for pointing to the reference frame) to +# relate it relative to the experimental setup. Typically, the components of a +# system should all be related relative to each other and only one component +# should relate to the reference coordinate system. +# +# +# +# +# Describes the electron collection (spatial and momentum imaging) column +# +# +# +# +# Describes the energy dispersion section +# +# +# +# +# Describes the spin dispersion section +# +# +# +# +# Describes the electron detector +# +# +# +# +# Deflectors outside the main optics ensambles described by the subclasses +# +# +# +# +# Individual lenses outside the main optics ensambles described by the subclasses +# +# +# diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 0dc68fc7f7..919ea0aa7d 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -178,6 +178,15 @@ NXmpes(NXobject): doc: | The size and position of the contrast aperture inserted in the column. To add additional or other apertures use the APERTURE group of NXcollectioncolumn. + iris(NXaperture): + exists: optional + doc: | + Size, position and shape of the iris inserted in the column. + + The iris is an aperture in the lens with a variable diameter which can reduce the number of + electrons entering the analyzer. + + To add additional or other slits use the APERTURE group of NXcollectioncolumn. device_information(NXfabrication): exists: recommended vendor: @@ -195,13 +204,15 @@ NXmpes(NXobject): entrance_slit(NXaperture): exists: optional doc: | - Size, position and shape of the entrance slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. + Size, position and shape of the entrance slit in dispersive analyzers. + + To add additional or other slits use the APERTURE group of NXenergydispersion. exit_slit(NXaperture): exists: optional doc: | - Size, position and shape of the exit slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. + Size, position and shape of the exit slit in dispersive analyzers. + + To add additional or other slits use the APERTURE group of NXenergydispersion. device_information(NXfabrication): exists: recommended vendor: @@ -299,6 +310,27 @@ NXmpes(NXobject): exists: recommended doc: | This is the momentum axis to be used for data plotting. + energy_correction(NXcalibration): + exists: optional + applied(NX_BOOLEAN): + doc: "Have the energy axes been adjusted (e.g., in cases where samples are not conductive)?" + emission_line: + exists: recommended + doc: Emission line which was used for the calibration + offset(NX_FLOAT): + exists: recommended + doc: | + Offset between measured binding energy and calibrated binding energy of the emission line." + binding_energy(NX_FLOAT): + exists: recommended + doc: | + The binding energy (in units of eV) that the specified emission line appeared at, + after adjusting the binding energy scale . + calibrated_axis(NX_FLOAT): + exists: recommended + doc: | + This is the calibrated energy axis to be used for data plotting. + This should be a link to /entry/data/energy." (NXsample): name: chemical_formula: @@ -321,6 +353,8 @@ NXmpes(NXobject): that are contained in the sample. If the sample substance has multiple components, all elements from each component must be included in `atom_types`. + physical_form: + exists: recommended preparation_date(NX_DATE_TIME): exists: recommended doc: | @@ -363,7 +397,15 @@ NXmpes(NXobject): 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. - + energy(NX_NUMBER): + doc: | + The calibrated energy axis can be either in binding or kinetic energy. + This should be a link to either + /entry/process/energy_calibration/calibrated_axis or + /entry/process/energy_correction/calibrated_axis. + \@type(NX_CHAR): + exists: recommended + enumeration: [kinetic, binding] # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ # e18956fa79544e7b4f50e31f3b421e387cab531f4f608e4c9dfc0013fa459429 # From ed9115b3b5f4819a5f4fe12d430479f6faf2824e Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 27 Sep 2023 15:22:47 +0200 Subject: [PATCH 0284/1012] Make energy axis recommended instead of required for now --- contributed_definitions/NXmpes.nxdl.xml | 2 +- contributed_definitions/nyaml/NXmpes.yaml | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 848fb470c3..6ca327b8f5 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -499,7 +499,7 @@ Optional constant settings (like lens focusing parameters on the sample: positio actual encoder position in NXinstrument or calibrated axes in NXprocess. - + The calibrated energy axis can be either in binding or kinetic energy. This should be a link to either diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 919ea0aa7d..5dc1152add 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -398,6 +398,7 @@ NXmpes(NXobject): delay, spin index, temperature, etc. The axes traces should be linked to the actual encoder position in NXinstrument or calibrated axes in NXprocess. energy(NX_NUMBER): + exists: recommended doc: | The calibrated energy axis can be either in binding or kinetic energy. This should be a link to either From dc2d267ee52222b8e6867ff481d637e57107d142 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 27 Sep 2023 15:37:53 +0200 Subject: [PATCH 0285/1012] Add NXnote to NXcalibration to store calibration file --- .../NXcalibration.nxdl.xml | 7 +- .../nyaml/NXcalibration.yaml | 180 ++++++++++++++++++ 2 files changed, 186 insertions(+), 1 deletion(-) create mode 100644 contributed_definitions/nyaml/NXcalibration.yaml diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml index 422c486083..8cd537b8a7 100644 --- a/contributed_definitions/NXcalibration.nxdl.xml +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + The symbols used in the schema to specify e.g. dimensions of arrays @@ -108,4 +108,9 @@ A description of the procedures employed. + + + + + diff --git a/contributed_definitions/nyaml/NXcalibration.yaml b/contributed_definitions/nyaml/NXcalibration.yaml new file mode 100644 index 0000000000..aa4e8751da --- /dev/null +++ b/contributed_definitions/nyaml/NXcalibration.yaml @@ -0,0 +1,180 @@ +category: base +doc: | + Subclass of NXprocess to describe post-processing calibrations. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays + ncoeff: | + Number of coefficients of the calibration function + nfeat: | + Number of features used to fit the calibration function + ncal: | + Number of points of the calibrated and uncalibrated axes +type: group +NXcalibration(NXobject): + last_process(NX_CHAR): + doc: | + Indicates the name of the last operation applied in the NXprocess sequence. + applied(NX_BOOLEAN): + doc: | + Has the calibration been applied? + coefficients(NX_FLOAT): + unit: NX_ANY + doc: | + For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit + to a set of features (peaks) at well defined energy positions to determine + E(TOF). Here we can store the array of fit coefficients. + dimensions: + rank: 1 + dim: [[1, ncoeff]] + fit_function(NX_CHAR): + doc: | + 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. + scaling(NX_FLOAT): + unit: NX_ANY + doc: | + For linear calibration. Scaling parameter. + offset(NX_FLOAT): + unit: NX_ANY + doc: | + For linear calibration. Offset parameter. + calibrated_axis(NX_FLOAT): + unit: NX_ANY + doc: | + A vector representing the axis after calibration, matching the data length + dimensions: + rank: 1 + dim: [[1, ncal]] + original_axis(NX_FLOAT): + unit: NX_ANY + doc: | + Vector containing the data coordinates in the original uncalibrated axis + dimensions: + rank: 1 + dim: [[1, ncal]] + description(NX_CHAR): + doc: | + A description of the procedures employed. + calibration_file(NXnote): + doc: | + File containing the calibration data. +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 7394f6136c95cdee182a96a9aff856eee0285b94b6a3e83a0175949aa9752ae3 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays +# +# +# +# Number of coefficients of the calibration function +# +# +# +# +# Number of features used to fit the calibration function +# +# +# +# +# Number of points of the calibrated and uncalibrated axes +# +# +# +# +# Subclass of NXprocess to describe post-processing calibrations. +# +# +# +# Indicates the name of the last operation applied in the NXprocess sequence. +# +# +# +# +# Has the calibration been applied? +# +# +# +# +# For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit +# to a set of features (peaks) at well defined energy positions to determine +# E(TOF). Here we can store the array of fit coefficients. +# +# +# +# +# +# +# +# For non-linear energy calibrations. Here we can store the formula of the +# fit function. +# +# Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. +# +# Use x0, x1, ..., xn for the variables. +# +# The formula should be numpy compliant. +# +# +# +# +# For linear calibration. Scaling parameter. +# +# +# +# +# For linear calibration. Offset parameter. +# +# +# +# +# A vector representing the axis after calibration, matching the data length +# +# +# +# +# +# +# +# Vector containing the data coordinates in the original uncalibrated axis +# +# +# +# +# +# +# +# A description of the procedures employed. +# +# +# From d39f0182ed01458068fcc8c9f35fc88c6584bd88 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 27 Sep 2023 16:00:00 +0200 Subject: [PATCH 0286/1012] Add transmission function in NXelectronanalyser, intensity calibration in NXmpes --- .../NXelectronanalyser.nxdl.xml | 9 ++++++++- contributed_definitions/NXmpes.nxdl.xml | 19 ++++++++++++++++++- .../nyaml/NXelectronanalyser.yaml | 8 +++++++- contributed_definitions/nyaml/NXmpes.yaml | 18 +++++++++++++++++- 4 files changed, 50 insertions(+), 4 deletions(-) diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml index d829dd38ce..f4606b00b2 100644 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -127,9 +127,16 @@ + + + Transmission function of the electron analyzer. + + The tranmission function is usually energy vs. relative intensity. + + - Refers to the last transformation specifying the positon of the manipulator in + Refers to the last transformation specifying the position of the manipulator in the NXtransformations chain. diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 6ca327b8f5..679654a54d 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -192,8 +192,9 @@ This would also be helpful for NXtransformations--> NXcalibration. - + + by the sample temperature sensor. - + In the case of an experiment in which the temperature is changed and recorded, this is an array of length m of temperatures. + @@ -294,16 +295,11 @@ It could be a lot of raw data from a detector. Shpould be optional.--> - - - In the case of a fixed temperature, this is the scalar temperature setpoint. - - - - - In the case of an experiment in which the temperature is changed and recorded, - this is an array of length m of temperature setpoints. - + + + + + @@ -378,6 +374,24 @@ It could be a lot of raw data from a detector. Shpould be optional.--> this is an array of length m of gas pressures. + + + Device to bring low-energy electrons to the sample for charge neutralization + + + + + + + + + + + + + + + @@ -544,6 +558,18 @@ It could be a lot of raw data from a detector. Shpould be optional.--> + + + Current of ow-energy electrons to the sample for charge neutralization + + + + Flood gun creating a current of low-energy electrons. + + This should be a link to /entry/instrument/flood_gun. + + + diff --git a/contributed_definitions/nyaml/NXactuator.yaml b/contributed_definitions/nyaml/NXactuator.yaml index 685981d6f6..c8d998fe51 100644 --- a/contributed_definitions/nyaml/NXactuator.yaml +++ b/contributed_definitions/nyaml/NXactuator.yaml @@ -16,16 +16,14 @@ NXactuator(NXobject): Short name of actuator used e.g. on monitor display program attached_to: doc: | - where actuator is attached to ("sample" | "can") - geometry(NXgeometry): - deprecated: | - Use the field `depends_on` and :ref:`NXtransformations` to position the beamstop and NXoff_geometry to describe its shape instead - doc: | - Defines the axes for logged vector quantities if they are not the global instrument axes. + where actuator is attached to actuation: doc: | - name for measured signal - enumeration: [temperature, pH, magnetic_field, electric_field, current, conductivity, resistance, voltage, pressure, flow, stress, strain, shear, surface_pressure] + name for quantity effected by actuation + + Examples: + temperature | pH | magnetic_field | electric_field | current | conductivity | resistance | voltage | + pressure | flow | stress | strain | shear | surface_pressure type: doc: | The type of hardware used for the actuation. @@ -37,38 +35,73 @@ NXactuator(NXobject): anvil cell :Voltage: potentiostat - value(NX_FLOAT): + setpoint(NX_FLOAT): unit: NX_ANY doc: | - Nominal setpoint. Can be a scalar or a vector (of [n] actuations). + Nominal setpoint + + Can be a scalar or a vector (of [n] actuations). dimensions: dim: [[1, n]] - value_deriv1(NX_FLOAT): - unit: NX_ANY + setpoint_deriv1(NX_FLOAT): doc: | - Nominal/average first derivative of value + Nominal/average first derivative of setpoint e.g. strain rate - - same dimensions as "value" (may be a vector) + - same dimensions as "setpoint" (may be a vector) + dimensions: + dim: [[1, ]] + dim_parameters: + ref: ['setpoint'] + setpoint_deriv2(NX_FLOAT): + doc: | + Nominal/average second derivative of setpoint + - same dimensions as "setpoint" (may be a vector) dimensions: dim: [[1, ]] dim_parameters: - ref: ['value'] - value_deriv2(NX_FLOAT): + ref: ['setpoint'] + setpoint_log(NXlog): + doc: | + Time history of actuator setpoints. + setpoint_deriv1_log(NXlog): + doc: | + Time history of first derivative of actuator setpoints. + setpoint_deriv2_log(NXlog): + doc: | + Time history of second derivative of actuator setpoints. + output(NX_FLOAT): unit: NX_ANY doc: | - Nominal/average second derivative of value - - same dimensions as "value" (may be a vector) + Actuation output + + Can be a scalar or a vector (of [n] actuations). + nominal setpoint or average value + dimensions: + dim: [[1, n]] + output_deriv1(NX_FLOAT): + doc: | + Nominal/average first derivative of output + e.g. strain rate + - same dimensions as "output" (may be a vector) + dimensions: + dim: [[1, ]] + dim_parameters: + ref: ['output'] + output_deriv2(NX_FLOAT): + doc: | + Nominal/average second derivative of output + - same dimensions as "output" (may be a vector) dimensions: dim: [[1, ]] dim_parameters: - ref: ['value'] - value_log(NXlog): + ref: ['output'] + output_log(NXlog): doc: | Time history of actuator outputs. - value_deriv1_log(NXlog): + output_deriv1_log(NXlog): doc: | Time history of first derivative of actuator outputs - value_deriv2_log(NXlog): + output_deriv2_log(NXlog): doc: | Time history of second derivative of actuator outputs external_field_brief: diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 597762b0bf..d7c173a839 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -194,10 +194,11 @@ NXmpes(NXobject): by the sample temperature sensor. value_log(NXlog): exists: optional - unit: NX_TEMPERATURE doc: | In the case of an experiment in which the temperature is changed and recorded, this is an array of length m of temperatures. + value: + unit: NX_TEMPERATURE sample_heater(NXactuator): exists: recommended doc: Device to heat the sample. @@ -207,17 +208,13 @@ NXmpes(NXobject): enumeration: [temperature] type: exists: recommended - value(NX_FLOAT): + setpoint_log(NXlog): exists: recommended - unit: NX_TEMPERATURE - doc: | - In the case of a fixed temperature, this is the scalar temperature setpoint. - value_log(NXlog): - exists: optional - unit: NX_TEMPERATURE - doc: | - In the case of an experiment in which the temperature is changed and recorded, - this is an array of length m of temperature setpoints. + value: + unit: NX_TEMPERATURE + output_log(NXlog): + value: + unit: NX_TEMPERATURE drain_current_amperemeter(NXsensor): exists: recommended doc: Amperemeter measuring the drain current of the sample and sample holder. @@ -283,6 +280,24 @@ NXmpes(NXobject): doc: | In the case of an experiment in which the gas pressure is changed and recorded, this is an array of length m of gas pressures. + flood_gun(NXactuator): + exists: recommended + doc: Device to bring low-energy electrons to the sample for charge neutralization + name: + exists: recommended + actuation: + enumeration: [current] + type: + exists: recommended + type: + exists: recommended + setpoint_log(NXlog): + exists: recommended + value: + unit: NX_CURRENT + output_log(NXlog): + value: + unit: NX_CURRENT (NXprocess): exists: recommended doc: | @@ -412,6 +427,15 @@ NXmpes(NXobject): Amperemeter measuring the drain current of the sample and sample holder. This should be a link to /entry/instrument/manipulator/drain_current_amperemeter. + flood_gun_current(NXenvironment): + exists: optional + doc: | + Current of ow-energy electrons to the sample for charge neutralization + flood_gun(NXactuator): + doc: | + Flood gun creating a current of low-energy electrons. + + This should be a link to /entry/instrument/flood_gun. (NXdata): \@signal: enumeration: [data] From 5551050010c366c59b324e665cde13fa53c439f5 Mon Sep 17 00:00:00 2001 From: domna Date: Thu, 28 Sep 2023 08:04:18 +0200 Subject: [PATCH 0288/1012] Adds response_function to NXresolution --- contributed_definitions/NXresolution.nxdl.xml | 26 +++++++++++++++---- .../nyaml/NXresolution.yaml | 23 ++++++++++++---- 2 files changed, 39 insertions(+), 10 deletions(-) diff --git a/contributed_definitions/NXresolution.nxdl.xml b/contributed_definitions/NXresolution.nxdl.xml index 458dc57600..0c965bb29e 100644 --- a/contributed_definitions/NXresolution.nxdl.xml +++ b/contributed_definitions/NXresolution.nxdl.xml @@ -47,14 +47,30 @@ Additional details of the estimate or description of the calibration procedure - + - The data describing the resolution in dependency of the experimental axes. + The resolution of the physical quantity. - + + + + The response of the instrument or part to a infinitesimal short input signal + along the physical quantity of this group. + This is also sometimes called instrument response function for time resolution or + point spread function for spatial response. + The resolution is typically determined by taking the FWHM of the response function. + + + + The input axis or grid of the response function. + The unit should match the one of the resolution field. + + + - The magnitude of the resolution at the given point(s) or single value - for a constant resolution throughout the experimental phase-space. + The magnitude of the response function corresponding to the points + in the input axis or grid. + This field should have the same dimensions as `input`. diff --git a/contributed_definitions/nyaml/NXresolution.yaml b/contributed_definitions/nyaml/NXresolution.yaml index ee3fd779ac..9ed5dbf671 100644 --- a/contributed_definitions/nyaml/NXresolution.yaml +++ b/contributed_definitions/nyaml/NXresolution.yaml @@ -15,14 +15,27 @@ NXresolution: note(NXnote): doc: | Additional details of the estimate or description of the calibration procedure - resolution(NXdata): + resolution(NX_FLOAT): doc: | - The data describing the resolution in dependency of the experimental axes. - magnitude(NX_FLOAT): + The resolution of the physical quantity. + unit: NX_ANY + response_function(NXdata): + doc: | + The response of the instrument or part to a infinitesimal short input signal + along the physical quantity of this group. + This is also sometimes called instrument response function for time resolution or + point spread function for spatial response. + The resolution is typically determined by taking the FWHM of the response function. + input(NX_FLOAT): doc: | - The magnitude of the resolution at the given point(s) or single value - for a constant resolution throughout the experimental phase-space. + The input axis or grid of the response function. + The unit should match the one of the resolution field. unit: NX_ANY + magnitude(NX_FLOAT): + doc: | + The magnitude of the response function corresponding to the points + in the input axis or grid. + This field should have the same dimensions as `input`. formula_symbol_LINK(NXlink): doc: | A symbol linking to another path in this appdef From 9c72ceb8789fda20e8de699edeb2370039d79ecc Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 28 Sep 2023 15:46:30 +0200 Subject: [PATCH 0289/1012] Address comments, change transmission function - Change transmission function in NXcalibration and NXelectronanalyser - Extend some docstrings with more information - Docsctring typos --- .../NXcalibration.nxdl.xml | 7 +- .../NXelectronanalyser.nxdl.xml | 75 ++- contributed_definitions/NXmpes.nxdl.xml | 91 +++- .../nyaml/NXcalibration.yaml | 118 +---- .../nyaml/NXelectronanalyser.yaml | 217 ++------ contributed_definitions/nyaml/NXmpes.yaml | 475 ++---------------- 6 files changed, 222 insertions(+), 761 deletions(-) diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml index 8cd537b8a7..3451347074 100644 --- a/contributed_definitions/NXcalibration.nxdl.xml +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -110,7 +110,12 @@ - + File containing the input data for calibration. + + + + + Input data for calibration. diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml index f4606b00b2..624dd5b872 100644 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -37,6 +37,11 @@ Number of slow axes (axes acquired scanning a physical quantity) + + + Number of data points in the transmission function. + + Subclass of NXinstrument to describe a photoelectron analyser. @@ -58,23 +63,21 @@ - Work function of the instrumeter. + Work function of the electron analyser. - The work function of a uniform surface of a conductor is defined as - the minimum energy required to remove an electron from the interior of the - conductor to just outside the surface. + The work function of a uniform surface of a conductor is the minimum energy required to remove + an electron from the interior of the solid to a vacuum level immediately outside the solid surface. The kinetic energy :math:`E_K` of a photoelectron emitted from an energy-level with - binding energy :math:`E_B` below the Fermi level is given by, :math:`E_K = h\nu - E_B - e \phi_m`, - where :math:`\phi_m`is the work function of the sample material. In PES measurement, - the sample and the spectrometer (with work function :math:`\phi_s`) are electrically connected, - resulting in a contact potential difference :math:`\Delta(\phi) = \phi_m - \phi_s` due to the - difference in local vacuum level between the sample and spectrometer. The measured kinetic energy - of a photoelectron in PES is therefore given by - :math:`E_K^{meas} = h\nu - E_B + \Delta \Phi = h\nu - E_B - e \phi_s`. As a result, the measured - kinetic energy :math:`E_K^{meas}` of a photoelectron is independent of the sample work function. - Nonetheless, the work function :math:`\phi_s` needs to be know to accurately determine the binding - energy scale. + binding energy :math:`E_B` below the Fermi level is given by :math:`E_K = h\nu - E_B - e \phi_{sample}`, + where :math:`\phi_{sample}` is the work function of the sample surface. In PES measurements, the sample + and the spectrometer (with work function :math:`\phi_{spectr.}`) are electrically connected and therefore + their Fermi levels are aligned. Due to the difference in local vacuum level between the sample and spectrometer, + there exists an electric potential difference (contact or Volta potential) :math:`\Delta\phi = \phi_{sample} - \phi_{spectr.}`. + The measured kinetic energy of a photoelectron in PES is therefore given by + :math:`E_K^{meas.} = h\nu - E_B + \Delta \phi = h\nu - E_B - e \phi_s`. As a result, the measured + kinetic energy :math:`E_K^{meas}` of a photoelectron is independent of the sample work function. Nonetheless, the work + function :math:`\phi_s` needs to be known to accurately determine the binding energy scale. @@ -127,13 +130,47 @@ - + - Transmission function of the electron analyzer. + Transmission function of the electron analyser. - The tranmission function is usually energy vs. relative intensity. - - + The transmission function (TF) specifies the detection efficiency for electrons of + different kinetic energy passing through the electron analyser. It depends on the spectrometer + geometry as well as operation settings such as lens mode and pass energy. + The transmission function is usually given as kinetic energy vs. relative intensity. + + The TF is used for calibration of the intensity scale in quantitative XPS. Without proper + transmission correction, a comparison of results measured from the same sample using different + operating modes for an instrument would show significant variations in atomic + concentrations. + + + + + + + + + + + + + + Kinetic energy values + + + + + + + + Relative transmission efficiency for the given kinetic energies + + + + + + Refers to the last transformation specifying the position of the manipulator in diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 679654a54d..da22213e1f 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -22,6 +22,16 @@ # For further information, see http://www.nexusformat.org --> + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of data points in the transmission function. + + + This is the most general application definition for multidimensional photoelectron spectroscopy. @@ -354,22 +364,6 @@ Optional constant settings (like lens focusing parameters on the sample: positio - - - - Has an intensity calibration been applied? - - That is, has the transmission function of the analyser been taken into account? - - - - - Transmission function of the electron analyser. - - This can be a link to /entry/instrument/electronanalyser/transmission_function." - - - @@ -415,13 +409,15 @@ Optional constant settings (like lens focusing parameters on the sample: positio - Emission line which was used for the calibration + Emission line which was used for the calibration. + + For example: C1s C-C | Ag 3d5/2 metal | Si 2p3/2 elemental | Fermi edge Offset between measured binding energy and calibrated binding energy of the - emission line." + emission line. @@ -432,10 +428,56 @@ Optional constant settings (like lens focusing parameters on the sample: positio - This is the calibrated energy axis to be used for data plotting. - This should be a link to /entry/data/energy." + This is the calibrated energy axis to be used for data plotting. + + This should link to /entry/data/energy. + + + + + + + Has an intensity calibration been applied? + + That is, has the transmission function of the analyser been taken into account? + + + Transmission function of the electron analyser. + + The transmission function (TF) specifies the detection efficiency for electrons of + different kinetic energy passing through the electron analyser. + + This can be a link to /entry/instrument/electronanalyser/transmission_function. + + + + + + + + + + + + + + Kinetic energy values + + + + + + + + Relative transmission efficiency for the given kinetic energies + + + + + + @@ -518,12 +560,19 @@ Optional constant settings (like lens focusing parameters on the sample: positio + Calibrated energy axis. + The calibrated energy axis can be either in binding or kinetic energy. This should be a link to either /entry/process/energy_calibration/calibrated_axis or /entry/process/energy_correction/calibrated_axis. - + + + + + + diff --git a/contributed_definitions/nyaml/NXcalibration.yaml b/contributed_definitions/nyaml/NXcalibration.yaml index aa4e8751da..387f9b08c2 100644 --- a/contributed_definitions/nyaml/NXcalibration.yaml +++ b/contributed_definitions/nyaml/NXcalibration.yaml @@ -64,117 +64,7 @@ NXcalibration(NXobject): A description of the procedures employed. calibration_file(NXnote): doc: | - File containing the calibration data. -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 7394f6136c95cdee182a96a9aff856eee0285b94b6a3e83a0175949aa9752ae3 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays -# -# -# -# Number of coefficients of the calibration function -# -# -# -# -# Number of features used to fit the calibration function -# -# -# -# -# Number of points of the calibrated and uncalibrated axes -# -# -# -# -# Subclass of NXprocess to describe post-processing calibrations. -# -# -# -# Indicates the name of the last operation applied in the NXprocess sequence. -# -# -# -# -# Has the calibration been applied? -# -# -# -# -# For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit -# to a set of features (peaks) at well defined energy positions to determine -# E(TOF). Here we can store the array of fit coefficients. -# -# -# -# -# -# -# -# For non-linear energy calibrations. Here we can store the formula of the -# fit function. -# -# Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. -# -# Use x0, x1, ..., xn for the variables. -# -# The formula should be numpy compliant. -# -# -# -# -# For linear calibration. Scaling parameter. -# -# -# -# -# For linear calibration. Offset parameter. -# -# -# -# -# A vector representing the axis after calibration, matching the data length -# -# -# -# -# -# -# -# Vector containing the data coordinates in the original uncalibrated axis -# -# -# -# -# -# -# -# A description of the procedures employed. -# -# -# + File containing the input data for calibration. + calibration_input_data(NXdata): + doc: | + Input data for calibration. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXelectronanalyser.yaml b/contributed_definitions/nyaml/NXelectronanalyser.yaml index abb85d9c20..38537d7ac5 100644 --- a/contributed_definitions/nyaml/NXelectronanalyser.yaml +++ b/contributed_definitions/nyaml/NXelectronanalyser.yaml @@ -9,6 +9,8 @@ symbols: physical quantity) nsa: | Number of slow axes (axes acquired scanning a physical quantity) + n_transmission_function: | + Number of data points in the transmission function. type: group NXelectronanalyser(NXobject): description(NX_CHAR): @@ -23,23 +25,21 @@ NXelectronanalyser(NXobject): Acronym or other shorthand name work_function(NX_FLOAT): doc: | - Work function of the instrumeter. + Work function of the electron analyser. - The work function of a uniform surface of a conductor is defined as - the minimum energy required to remove an electron from the interior of the - conductor to just outside the surface. + The work function of a uniform surface of a conductor is the minimum energy required to remove + an electron from the interior of the solid to a vacuum level immediately outside the solid surface. The kinetic energy :math:`E_K` of a photoelectron emitted from an energy-level with - binding energy :math:`E_B` below the Fermi level is given by, :math:`E_K = h\nu - E_B - e \phi_m`, - where :math:`\phi_m`is the work function of the sample material. In PES measurement, - the sample and the spectrometer (with work function :math:`\phi_s`) are electrically connected, - resulting in a contact potential difference :math:`\Delta(\phi) = \phi_m - \phi_s` due to the - difference in local vacuum level between the sample and spectrometer. The measured kinetic energy - of a photoelectron in PES is therefore given by - :math:`E_K^{meas} = h\nu - E_B + \Delta \Phi = h\nu - E_B - e \phi_s`. As a result, the measured - kinetic energy :math:`E_K^{meas}` of a photoelectron is independent of the sample work function. - Nonetheless, the work function :math:`\phi_s` needs to be know to accurately determine the binding - energy scale. + binding energy :math:`E_B` below the Fermi level is given by :math:`E_K = h\nu - E_B - e \phi_{sample}`, + where :math:`\phi_{sample}` is the work function of the sample surface. In PES measurements, the sample + and the spectrometer (with work function :math:`\phi_{spectr.}`) are electrically connected and therefore + their Fermi levels are aligned. Due to the difference in local vacuum level between the sample and spectrometer, + there exists an electric potential difference (contact or Volta potential) :math:`\Delta\phi = \phi_{sample} - \phi_{spectr.}`. + The measured kinetic energy of a photoelectron in PES is therefore given by + :math:`E_K^{meas.} = h\nu - E_B + \Delta \phi = h\nu - E_B - e \phi_s`. As a result, the measured + kinetic energy :math:`E_K^{meas}` of a photoelectron is independent of the sample work function. Nonetheless, the work + function :math:`\phi_s` needs to be known to accurately determine the binding energy scale. unit: NX_ENERGY energy_resolution(NX_FLOAT): unit: NX_ENERGY @@ -83,12 +83,33 @@ NXelectronanalyser(NXobject): dimensions: rank: 1 dim: [[1, nsa]] - transmission_function(NX_FLOAT): + transmission_function(NXdata): doc: | - Transmission function of the electron analyzer. + Transmission function of the electron analyser. - The tranmission function is usually energy vs. relative intensity. - unit: NX_ANY + The transmission function (TF) specifies the detection efficiency for electrons of + different kinetic energy passing through the electron analyser. It depends on the spectrometer + geometry as well as operation settings such as lens mode and pass energy. + The transmission function is usually given as kinetic energy vs. relative intensity. + + The TF is used for calibration of the intensity scale in quantitative XPS. Without proper + transmission correction, a comparison of results measured from the same sample using different + operating modes for an instrument would show significant variations in atomic + concentrations. + \@signal: + enumeration: [relative_intensity] + \@axes: + enumeration: [kinetic_energy] + kinetic_energy(NX_FLOAT): + doc: | + Kinetic energy values + unit: NX_ENERGY + dim: (n_transmission_function,) + relative_intensity(NX_FLOAT): + doc: | + Relative transmission efficiency for the given kinetic energies + unit: NX_UNITLESS + dim: (n_transmission_function,) depends_on(NX_CHAR): doc: | Refers to the last transformation specifying the position of the manipulator in @@ -121,163 +142,3 @@ NXelectronanalyser(NXobject): (NXlens_em): doc: | Individual lenses outside the main optics ensambles described by the subclasses - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4d6adccbc47a79bb1c1a6e54f879331198408c0f0a4503f6aa9093df58cdea12 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays -# -# -# -# Number of fast axes (axes acquired simultaneously, without scanning a -# physical quantity) -# -# -# -# -# Number of slow axes (axes acquired scanning a physical quantity) -# -# -# -# -# Subclass of NXinstrument to describe a photoelectron analyser. -# -# -# -# Free text description of the type of the detector -# -# -# -# -# Name or model of the equipment -# -# -# -# Acronym or other shorthand name -# -# -# -# -# -# Energy resolution of the electron analyser (FWHM of gaussian broadening) -# -# -# -# -# Momentum resolution of the electron analyser (FWHM) -# -# -# -# -# Angular resolution of the electron analyser (FWHM) -# -# -# -# -# Spatial resolution of the electron analyser (Airy disk radius) -# -# -# -# -# List of the axes that are acquired simultaneously by the detector. -# These refer only to the experimental variables recorded by the electron analyser. -# Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. -# -# .. csv-table:: Examples -# :header: "Mode", "fast_axes", "slow_axes" -# -# Hemispherical in ARPES mode, "['energy', 'kx']","" -# "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] -# "Tof", "['energy', 'kx', 'ky']","" -# "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" -# -# Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. -# If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. -# -# -# -# -# -# -# -# List of the axes that are acquired by scanning a physical parameter, listed in -# order of decreasing speed. See fast_axes for examples. -# -# -# -# -# -# -# -# Refers to the last transformation specifying the positon of the manipulator in -# the NXtransformations chain. -# -# -# -# -# Collection of axis-based translations and rotations to describe the location and -# geometry of the electron analyser as a component in the instrument. Conventions -# from the NXtransformations base class are used. In principle, the McStas -# coordinate system is used. The first transformation has to point either to -# another component of the system or . (for pointing to the reference frame) to -# relate it relative to the experimental setup. Typically, the components of a -# system should all be related relative to each other and only one component -# should relate to the reference coordinate system. -# -# -# -# -# Describes the electron collection (spatial and momentum imaging) column -# -# -# -# -# Describes the energy dispersion section -# -# -# -# -# Describes the spin dispersion section -# -# -# -# -# Describes the electron detector -# -# -# -# -# Deflectors outside the main optics ensambles described by the subclasses -# -# -# -# -# Individual lenses outside the main optics ensambles described by the subclasses -# -# -# diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index a084035c50..fef8312184 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -2,6 +2,11 @@ category: application doc: | This is the most general application definition for multidimensional photoelectron spectroscopy. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays + n_transmission_function: | + Number of data points in the transmission function. type: group NXmpes(NXobject): (NXentry): @@ -285,20 +290,6 @@ NXmpes(NXobject): exists: recommended doc: | This is the calibrated energy axis to be used for data plotting. - intensity_calibration(NXcalibration): - exists: optional - applied(NX_BOOLEAN): - doc: | - Has an intensity calibration been applied? - - That is, has the transmission function of the analyser been taken into account? - transmission_function(NX_FLOAT): - exists: recommended - doc: | - Transmission function of the electron analyser. - - This can be a link to /entry/instrument/electronanalyser/transmission_function." - unit: NX_ANY angular_calibration(NXcalibration): exists: optional applied(NX_BOOLEAN): @@ -329,14 +320,17 @@ NXmpes(NXobject): energy_correction(NXcalibration): exists: optional applied(NX_BOOLEAN): - doc: "Have the energy axes been adjusted (e.g., in cases where samples are not conductive)?" + doc: Have the energy axes been adjusted (e.g., in cases where samples are not conductive)? emission_line: exists: recommended - doc: Emission line which was used for the calibration + doc: | + Emission line which was used for the calibration. + + For example: C1s C-C | Ag 3d5/2 metal | Si 2p3/2 elemental | Fermi edge offset(NX_FLOAT): exists: recommended doc: | - Offset between measured binding energy and calibrated binding energy of the emission line." + Offset between measured binding energy and calibrated binding energy of the emission line. binding_energy(NX_FLOAT): exists: recommended doc: | @@ -345,8 +339,39 @@ NXmpes(NXobject): calibrated_axis(NX_FLOAT): exists: recommended doc: | - This is the calibrated energy axis to be used for data plotting. - This should be a link to /entry/data/energy." + This is the calibrated energy axis to be used for data plotting. + + This should link to /entry/data/energy. + transmission_correction(NXcalibration): + exists: optional + applied(NX_BOOLEAN): + doc: | + Has an intensity calibration been applied? + + That is, has the transmission function of the analyser been taken into account? + calibration_input_data(NXdata): + exists: recommended + doc: | + Transmission function of the electron analyser. + + The transmission function (TF) specifies the detection efficiency for electrons of + different kinetic energy passing through the electron analyser. + + This can be a link to /entry/instrument/electronanalyser/transmission_function. + \@signal: + enumeration: [relative_intensity] + \@axes: + enumeration: [kinetic_energy] + kinetic_energy(NX_FLOAT): + doc: | + Kinetic energy values + unit: NX_ENERGY + dim: (n_transmission_function,) + relative_intensity(NX_FLOAT): + doc: | + Relative transmission efficiency for the given kinetic energies + unit: NX_UNITLESS + dim: (n_transmission_function,) (NXsample): name: chemical_formula: @@ -416,418 +441,12 @@ NXmpes(NXobject): energy(NX_NUMBER): exists: recommended doc: | + Calibrated energy axis. + The calibrated energy axis can be either in binding or kinetic energy. This should be a link to either /entry/process/energy_calibration/calibrated_axis or /entry/process/energy_correction/calibrated_axis. \@type(NX_CHAR): exists: recommended - enumeration: [kinetic, binding] -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e18956fa79544e7b4f50e31f3b421e387cab531f4f608e4c9dfc0013fa459429 -# -# -# -# -# -# This is the most general application definition for multidimensional -# photoelectron spectroscopy. -# -# -# -# -# -# Datetime of the start of the measurement. -# -# -# -# -# Datetime of the end of the measurement. -# -# -# -# -# A name of the experimental method according -# to the `ISO 18115-1:2023`_ specification. -# -# .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html -# -# -# -# -# -# -# -# -# -# -# Contact information of at least the user of the instrument or the investigator -# who performed this experiment. Adding multiple users if relevant is recommended. -# -# -# -# Name of the user. -# -# -# -# -# Name of the affiliation of the user at the point in time when the experiment was -# performed. -# -# -# -# -# Full address (street, street number, ZIP, city, country) of the user's -# affiliation. -# -# -# -# -# Email address of the user. -# -# -# -# -# Author ID defined by https://orcid.org/. -# -# -# -# -# -# -# -# -# The source used to generate the primary photons. Properties refer strictly to -# parameters of the source, not of the output beam. For example, the energy of the -# source is not the optical power of the beam, but the energy of the electron beam -# in a synchrotron and so on. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Specification of type, may also go to name. -# -# -# -# -# -# Type of probe. In photoemission it's always photons, so the full NIAC list is -# restricted. -# -# -# -# -# -# -# -# -# -# -# -# Distance of the point of evaluation of the beam from the sample surface. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Energy resolution of the analyser with the current setting. May be linked from a -# NXcalibration. -# -# -# -# -# -# -# -# -# Scheme of the electron collection column. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The size and position of the field aperture inserted in the column. To add -# additional or other apertures use the APERTURE group of NXcollectioncolumn. -# -# -# -# -# The size and position of the contrast aperture inserted in the column. To add -# additional or other apertures use the APERTURE group of NXcollectioncolumn. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Size, position and shape of the entrance slit in dispersive analyzers. To add -# additional or other slits use the APERTURE group of NXenergydispersion. -# -# -# -# -# Size, position and shape of the exit slit in dispersive analyzers. To add -# additional or other slits use the APERTURE group of NXenergydispersion. -# -# -# -# -# -# -# Type of electron amplifier in the first amplification step. -# -# -# -# -# -# -# -# -# Description of the detector type. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Raw data before calibration. -# -# -# -# -# -# -# -# Manipulator for positioning of the sample. -# -# -# -# -# -# -# -# -# Document an event of data processing, reconstruction, or analysis for this data. -# Describe the appropriate axis calibrations for your experiment using one or more -# of the following NXcalibrations -# -# -# -# -# Has an energy calibration been applied? -# -# -# -# -# This is the calibrated energy axis to be used for data plotting. -# -# -# -# -# -# -# Has an angular calibration been applied? -# -# -# -# -# This is the calibrated angular axis to be used for data plotting. -# -# -# -# -# -# -# Has an spatial calibration been applied? -# -# -# -# -# This is the calibrated spatial axis to be used for data plotting. -# -# -# -# -# -# -# Has an momentum calibration been applied? -# -# -# -# -# This is the momentum axis to be used for data plotting. -# -# -# -# -# -# -# -# -# The chemical formula of the sample. For mixtures use the NXsample_component -# group in NXsample instead. -# -# -# -# -# A descriptor to keep track of the treatment of the sample before entering the -# photoemission experiment. Ideally, a full report of the previous operations, in -# any format (NXnote allows to add pictures, audio, movies). Alternatively, a -# reference to the location or a unique identifier or other metadata file. In the -# case these are not available, free-text description. -# -# -# -# -# List of comma-separated elements from the periodic table -# that are contained in the sample. -# If the sample substance has multiple components, all -# elements from each component must be included in `atom_types`. -# -# -# -# -# Date of preparation of the sample for the XPS experiment (i.e. cleaving, last -# annealing). -# -# -# -# -# Description of the surface preparation technique for the XPS experiment, i.e. -# UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report -# of the previous operations, in any format(NXnote allows to add pictures, audio, -# movies). Alternatively, a reference to the location or a unique identifier or -# other metadata file. In the case these are not available, free-text description. -# -# -# -# -# In the case of a fixed temperature measurement this is the scalar temperature of -# the sample. In the case of an experiment in which the temperature is changed and -# recoded, this is an array of length m of temperatures. This should be a link to -# /entry/instrument/manipulator/sample_temperature. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Voltage applied to sample and sample holder. -# -# -# -# -# -# -# -# -# -# -# -# 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. -# -# -# -# -# + enumeration: [kinetic, binding] \ No newline at end of file From 5d9e0cfcb5680aba5cc0004966e08c11563027b6 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 28 Sep 2023 16:18:56 +0200 Subject: [PATCH 0290/1012] Fix typo in work function docstring --- .../NXelectronanalyser.nxdl.xml | 22 ++++++++++--------- .../nyaml/NXelectronanalyser.yaml | 22 ++++++++++--------- 2 files changed, 24 insertions(+), 20 deletions(-) diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml index 624dd5b872..f2d1af0679 100644 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -68,16 +68,18 @@ The work function of a uniform surface of a conductor is the minimum energy required to remove an electron from the interior of the solid to a vacuum level immediately outside the solid surface. - The kinetic energy :math:`E_K` of a photoelectron emitted from an energy-level with - binding energy :math:`E_B` below the Fermi level is given by :math:`E_K = h\nu - E_B - e \phi_{sample}`, - where :math:`\phi_{sample}` is the work function of the sample surface. In PES measurements, the sample - and the spectrometer (with work function :math:`\phi_{spectr.}`) are electrically connected and therefore - their Fermi levels are aligned. Due to the difference in local vacuum level between the sample and spectrometer, - there exists an electric potential difference (contact or Volta potential) :math:`\Delta\phi = \phi_{sample} - \phi_{spectr.}`. - The measured kinetic energy of a photoelectron in PES is therefore given by - :math:`E_K^{meas.} = h\nu - E_B + \Delta \phi = h\nu - E_B - e \phi_s`. As a result, the measured - kinetic energy :math:`E_K^{meas}` of a photoelectron is independent of the sample work function. Nonetheless, the work - function :math:`\phi_s` needs to be known to accurately determine the binding energy scale. + The kinetic energy :math:`E_K` of a photoelectron emitted from an energy-level with binding energy + :math:`E_B` below the Fermi level is given by :math:`E_K = h\nu - E_B - e \phi_{\mathbf{sample}}`, + where :math:`\phi_{\mathbf{sample}}` is the work function of the sample surface. In PES measurements, + the sample and the spectrometer (with work function :math:`\phi_{\mathbf{spectr.}}`) are electrically + connected and therefore their Fermi levels are aligned. Due to the difference in local vacuum level + between the sample and spectrometer, there exists an electric potential difference (contact potential) + :math:`\Delta\phi = \phi_{\mathbf{sample}} - \phi_{\mathbf{spectr.}}`. The measured kinetic energy of + a photoelectron in PES is therefore given by + :math:`E_K^{\mathbf{meas.}} = h\nu - E_B + \Delta \phi = h\nu - E_B - e \phi_{\mathbf{spectr.}}`. + As a result, the measured kinetic energy :math:`E_K^{\mathbf{meas.}}` of a photoelectron is independent + of the sample work function. Nonetheless, the work function :math:`\phi_s` needs to be known to + accurately determine the binding energy scale. diff --git a/contributed_definitions/nyaml/NXelectronanalyser.yaml b/contributed_definitions/nyaml/NXelectronanalyser.yaml index 38537d7ac5..f151f6611b 100644 --- a/contributed_definitions/nyaml/NXelectronanalyser.yaml +++ b/contributed_definitions/nyaml/NXelectronanalyser.yaml @@ -30,16 +30,18 @@ NXelectronanalyser(NXobject): The work function of a uniform surface of a conductor is the minimum energy required to remove an electron from the interior of the solid to a vacuum level immediately outside the solid surface. - The kinetic energy :math:`E_K` of a photoelectron emitted from an energy-level with - binding energy :math:`E_B` below the Fermi level is given by :math:`E_K = h\nu - E_B - e \phi_{sample}`, - where :math:`\phi_{sample}` is the work function of the sample surface. In PES measurements, the sample - and the spectrometer (with work function :math:`\phi_{spectr.}`) are electrically connected and therefore - their Fermi levels are aligned. Due to the difference in local vacuum level between the sample and spectrometer, - there exists an electric potential difference (contact or Volta potential) :math:`\Delta\phi = \phi_{sample} - \phi_{spectr.}`. - The measured kinetic energy of a photoelectron in PES is therefore given by - :math:`E_K^{meas.} = h\nu - E_B + \Delta \phi = h\nu - E_B - e \phi_s`. As a result, the measured - kinetic energy :math:`E_K^{meas}` of a photoelectron is independent of the sample work function. Nonetheless, the work - function :math:`\phi_s` needs to be known to accurately determine the binding energy scale. + The kinetic energy :math:`E_K` of a photoelectron emitted from an energy-level with binding energy + :math:`E_B` below the Fermi level is given by :math:`E_K = h\nu - E_B - e \phi_{\mathbf{sample}}`, + where :math:`\phi_{\mathbf{sample}}` is the work function of the sample surface. In PES measurements, + the sample and the spectrometer (with work function :math:`\phi_{\mathbf{spectr.}}`) are electrically + connected and therefore their Fermi levels are aligned. Due to the difference in local vacuum level + between the sample and spectrometer, there exists an electric potential difference (contact potential) + :math:`\Delta\phi = \phi_{\mathbf{sample}} - \phi_{\mathbf{spectr.}}`. The measured kinetic energy of + a photoelectron in PES is therefore given by + :math:`E_K^{\mathbf{meas.}} = h\nu - E_B + \Delta \phi = h\nu - E_B - e \phi_{\mathbf{spectr.}}`. + As a result, the measured kinetic energy :math:`E_K^{\mathbf{meas.}}` of a photoelectron is independent + of the sample work function. Nonetheless, the work function :math:`\phi_s` needs to be known to + accurately determine the binding energy scale. unit: NX_ENERGY energy_resolution(NX_FLOAT): unit: NX_ENERGY From 01b87df9d8fd4657674d46f2f890bf3858ccff46 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 28 Sep 2023 16:35:42 +0200 Subject: [PATCH 0291/1012] More typo fixes --- contributed_definitions/NXelectronanalyser.nxdl.xml | 12 ++++++------ .../nyaml/NXelectronanalyser.yaml | 12 ++++++------ 2 files changed, 12 insertions(+), 12 deletions(-) diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml index f2d1af0679..c5743a9a2d 100644 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -69,15 +69,15 @@ an electron from the interior of the solid to a vacuum level immediately outside the solid surface. The kinetic energy :math:`E_K` of a photoelectron emitted from an energy-level with binding energy - :math:`E_B` below the Fermi level is given by :math:`E_K = h\nu - E_B - e \phi_{\mathbf{sample}}`, - where :math:`\phi_{\mathbf{sample}}` is the work function of the sample surface. In PES measurements, - the sample and the spectrometer (with work function :math:`\phi_{\mathbf{spectr.}}`) are electrically + :math:`E_B` below the Fermi level is given by :math:`E_K = h\nu - E_B - e \phi_{\mathrm{sample}}`, + where :math:`\phi_{\mathrm{sample}}` is the work function of the sample surface. In PES measurements, + the sample and the spectrometer (with work function :math:`\phi_{\mathrm{spectr.}}`) are electrically connected and therefore their Fermi levels are aligned. Due to the difference in local vacuum level between the sample and spectrometer, there exists an electric potential difference (contact potential) - :math:`\Delta\phi = \phi_{\mathbf{sample}} - \phi_{\mathbf{spectr.}}`. The measured kinetic energy of + :math:`\Delta\phi = \phi_{\mathrm{sample}} - \phi_{\mathrm{spectr.}}`. The measured kinetic energy of a photoelectron in PES is therefore given by - :math:`E_K^{\mathbf{meas.}} = h\nu - E_B + \Delta \phi = h\nu - E_B - e \phi_{\mathbf{spectr.}}`. - As a result, the measured kinetic energy :math:`E_K^{\mathbf{meas.}}` of a photoelectron is independent + :math:`E_K^{\mathrm{meas.}} = h\nu - E_B + \Delta \phi = h\nu - E_B - e \phi_{\mathrm{spectr.}}`. + As a result, the measured kinetic energy :math:`E_K^{\mathrm{meas.}}` of a photoelectron is `independent` of the sample work function. Nonetheless, the work function :math:`\phi_s` needs to be known to accurately determine the binding energy scale. diff --git a/contributed_definitions/nyaml/NXelectronanalyser.yaml b/contributed_definitions/nyaml/NXelectronanalyser.yaml index f151f6611b..55be0e53f2 100644 --- a/contributed_definitions/nyaml/NXelectronanalyser.yaml +++ b/contributed_definitions/nyaml/NXelectronanalyser.yaml @@ -31,15 +31,15 @@ NXelectronanalyser(NXobject): an electron from the interior of the solid to a vacuum level immediately outside the solid surface. The kinetic energy :math:`E_K` of a photoelectron emitted from an energy-level with binding energy - :math:`E_B` below the Fermi level is given by :math:`E_K = h\nu - E_B - e \phi_{\mathbf{sample}}`, - where :math:`\phi_{\mathbf{sample}}` is the work function of the sample surface. In PES measurements, - the sample and the spectrometer (with work function :math:`\phi_{\mathbf{spectr.}}`) are electrically + :math:`E_B` below the Fermi level is given by :math:`E_K = h\nu - E_B - e \phi_{\mathrm{sample}}`, + where :math:`\phi_{\mathrm{sample}}` is the work function of the sample surface. In PES measurements, + the sample and the spectrometer (with work function :math:`\phi_{\mathrm{spectr.}}`) are electrically connected and therefore their Fermi levels are aligned. Due to the difference in local vacuum level between the sample and spectrometer, there exists an electric potential difference (contact potential) - :math:`\Delta\phi = \phi_{\mathbf{sample}} - \phi_{\mathbf{spectr.}}`. The measured kinetic energy of + :math:`\Delta\phi = \phi_{\mathrm{sample}} - \phi_{\mathrm{spectr.}}`. The measured kinetic energy of a photoelectron in PES is therefore given by - :math:`E_K^{\mathbf{meas.}} = h\nu - E_B + \Delta \phi = h\nu - E_B - e \phi_{\mathbf{spectr.}}`. - As a result, the measured kinetic energy :math:`E_K^{\mathbf{meas.}}` of a photoelectron is independent + :math:`E_K^{\mathrm{meas.}} = h\nu - E_B + \Delta \phi = h\nu - E_B - e \phi_{\mathrm{spectr.}}`. + As a result, the measured kinetic energy :math:`E_K^{\mathrm{meas.}}` of a photoelectron is `independent` of the sample work function. Nonetheless, the work function :math:`\phi_s` needs to be known to accurately determine the binding energy scale. unit: NX_ENERGY From 35ab0c6d60bf2a1509c14f7bef64b38d6f961526 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 29 Sep 2023 10:14:02 +0200 Subject: [PATCH 0292/1012] Rename energy correction to energy_referencing - In line with ISO standard --- contributed_definitions/NXmpes.nxdl.xml | 11 ++++++++--- contributed_definitions/nyaml/NXmpes.yaml | 11 +++++++++-- 2 files changed, 17 insertions(+), 5 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index da22213e1f..03a2d92517 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -400,11 +400,16 @@ Optional constant settings (like lens focusing parameters on the sample: positio - + - Have the energy axes been adjusted (e.g., in cases where samples are not - conductive)? + Have the energy axes been adjusted (e.g., in cases where samples are not conductive)? + + For energy referencing, the measured energies are corrected for the charging potential + (i.e., the electrical potential of the surface region of an insulating sample, caused by + irradiation) such that those energies correspond to a sample with no surface charge. + Usually, the energy axis is adjusted by shifting all energies uniformally until one + well-defined emission line peak (or the Fermi edge) is located at a known "correct" energy. diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index fef8312184..947bd8b159 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -317,10 +317,17 @@ NXmpes(NXobject): exists: recommended doc: | This is the momentum axis to be used for data plotting. - energy_correction(NXcalibration): + energy_referencing(NXcalibration): exists: optional applied(NX_BOOLEAN): - doc: Have the energy axes been adjusted (e.g., in cases where samples are not conductive)? + doc: | + Have the energy axes been adjusted (e.g., in cases where samples are not conductive)? + + For energy referencing, the measured energies are corrected for the charging potential + (i.e., the electrical potential of the surface region of an insulating sample, caused by + irradiation) such that those energies correspond to a sample with no surface charge. + Usually, the energy axis is adjusted by shifting all energies uniformally until one + well-defined emission line peak (or the Fermi edge) is located at a known "correct" energy. emission_line: exists: recommended doc: | From c4bbfd1e89824c8494b997ab340d5c85b1785e43 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 29 Sep 2023 12:46:15 +0200 Subject: [PATCH 0293/1012] Add reference to ISO standard --- .../NXelectronanalyser.nxdl.xml | 12 +- .../NXenergydispersion.nxdl.xml | 7 + .../NXmanipulator.nxdl.xml | 2 +- contributed_definitions/NXmpes.nxdl.xml | 56 +++- .../nyaml/NXcollectioncolumn.yaml | 167 +++++++++++ .../nyaml/NXelectronanalyser.yaml | 269 ++++++++++++++++++ .../nyaml/NXenergydispersion.yaml | 151 ++++++++++ .../nyaml/NXmanipulator.yaml | 163 +++++++++++ contributed_definitions/nyaml/NXmpes.yaml | 56 +++- 9 files changed, 862 insertions(+), 21 deletions(-) create mode 100644 contributed_definitions/nyaml/NXcollectioncolumn.yaml create mode 100644 contributed_definitions/nyaml/NXelectronanalyser.yaml create mode 100644 contributed_definitions/nyaml/NXenergydispersion.yaml create mode 100644 contributed_definitions/nyaml/NXmanipulator.yaml diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml index 3a7ac1db1e..4e05984ccf 100644 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -40,6 +40,10 @@ Subclass of NXinstrument to describe a photoelectron analyser. + + Refers to Term `12.59`_ of the ISO 18115-1:2023 specification. + + .. _Term 12.59: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.59 @@ -59,6 +63,9 @@ Energy resolution of the electron analyser (FWHM of gaussian broadening) + + Refers to `Term 10.7`_ ff. of the ISO 18115-1:2023 specification. + .. _Term 10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 @@ -74,6 +81,9 @@ Spatial resolution of the electron analyser (Airy disk radius) + + Refers to `Term 10.15`_ ff. of the ISO 18115-1:2023 specification. + .. _Term 10.15: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.15 @@ -108,7 +118,7 @@ - Refers to the last transformation specifying the positon of the manipulator in + Refers to the last transformation specifying the position of the manipulator in the NXtransformations chain. diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml index 6487fdb2ae..a42550b405 100644 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ b/contributed_definitions/NXenergydispersion.nxdl.xml @@ -36,6 +36,9 @@ Energy of the electrons on the mean path of the analyser. Pass energy for hemispherics, drift energy for tofs. + + Refers to Term `12.63`_ of the ISO 18115-1:2023 specification. + .. _12.63: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.63 @@ -66,6 +69,10 @@ Way of scanning the energy axis (fixed or sweep). + + Refers to Terms `12.65`_ and `12.66`_ of the ISO 18115-1:2023 specification. + .. _12.65: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.65 + .. _12.66: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.66 diff --git a/contributed_definitions/NXmanipulator.nxdl.xml b/contributed_definitions/NXmanipulator.nxdl.xml index 52d7330f40..928bbdd773 100644 --- a/contributed_definitions/NXmanipulator.nxdl.xml +++ b/contributed_definitions/NXmanipulator.nxdl.xml @@ -70,7 +70,7 @@ - Possible bias of the sample with trespect to analyser ground. This field may + Possible bias of the sample with respect to analyser ground. This field may also be found in NXsample if present. diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 1a91ce16c3..1d8b007166 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -25,6 +25,12 @@ This is the most general application definition for multidimensional photoelectron spectroscopy. + + Groups and fields are named according to the + `ISO 18115-1:2023`_ specification as well as the `IUPAC Recommendations 2020`_. + + .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 @@ -40,10 +46,20 @@ - A name of the experimental method according - to the `ISO 18115-1:2023`_ specification. + A name of the experimental method according to `Clause 11`_ of + the `ISO 18115-1:2023`_ specification. + + Examples include: + * X-ray photoelectron spectroscopy (XPS) + * angle-resolved X-ray photoelectron spectroscopy (ARXPS) + * ultraviolet photoelectron spectroscopy (UPS) + * angle-resolved photoelectron spectroscopy (ARPES) + * hard X-ray photoemission spectroscopy (HAXPES) + * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) + * photoelectron emission microscopy (PEEM) .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 @@ -86,7 +102,21 @@ + + MPES spectrometer + + Refers to Term `12.58`_ of the ISO 18115-1:2023 specification. + + .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 + + + Overall energy resolution of the MPES instrument + + Refers to Terms `10.7`_ ff. and `10.24`_ of the ISO 18115-1:2023 specification. + .. _10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 + .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 + @@ -149,7 +179,7 @@ The beam emitted by this source. Should be named with the same appendix, e.g., for `source_probe` it should refer to `beam_probe`. - Refers to the same concept as /NXentry/NXinstrument/source_TYPE + Refers to the same concept as /NXentry/NXinstrument/beam_TYPE and may be linked. @@ -158,8 +188,6 @@ we have a subdefinition NXlink to refer to a path. This would also be helpful for NXtransformations--> - - Distance of the point of evaluation of the beam from the sample surface. @@ -171,10 +199,10 @@ This would also be helpful for NXtransformations--> - The beam emitted by this source. + The source that emitted this beam. Should be named with the same appendix, e.g., for `beam_probe` it should refer to `source_probe`. - Refers to the same concept as /NXentry/NXinstrument/beam_TYPE + Refers to the same concept as /NXentry/NXinstrument/source_TYPE and may be linked. @@ -190,6 +218,9 @@ This would also be helpful for NXtransformations--> Energy resolution of the analyser with the current setting. May be linked from a NXcalibration. + + Refers to Term `10.24` of the ISO 18115-1:2023 specification. + .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 @@ -315,7 +346,16 @@ Optional constant settings (like lens focusing parameters on the sample: positio - + + + Bias of the sample with respect to analyser ground. + + This field may also be found in NXsample if present. + + Refers to Term `8.41`_ of the ISO 18115-1:2023 specification. + .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 + + diff --git a/contributed_definitions/nyaml/NXcollectioncolumn.yaml b/contributed_definitions/nyaml/NXcollectioncolumn.yaml new file mode 100644 index 0000000000..36679468b9 --- /dev/null +++ b/contributed_definitions/nyaml/NXcollectioncolumn.yaml @@ -0,0 +1,167 @@ +category: base +doc: | + Subclass of NXelectronanalyser to describe the electron collection + column of a photoelectron analyser. +type: group +NXcollectioncolumn(NXobject): + scheme(NX_CHAR): + doc: | + Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum + microscope, etc. + extractor_voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Voltage applied to the extractor lens + extractor_current(NX_FLOAT): + unit: NX_CURRENT + doc: | + Current necessary to keep the extractor lens at a set voltage. Variations + indicate leakage, field emission or arc currents to the extractor lens. + working_distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + Distance between sample and detector entrance + mode(NX_CHAR): + doc: | + Labelling of the lens setting in use. + projection(NX_CHAR): + doc: | + The space projected in the angularly dispersive directions, real or reciprocal + enumeration: [real, reciprocal] + magnification(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + The magnification of the electron lens assembly. + depends_on(NX_CHAR): + doc: | + Specifies the position of the collectioncolumn by pointing to the last + transformation in the transformation chain in the NXtransformations group. + (NXtransformations): + doc: | + Collection of axis-based translations and rotations to describe the location and + geometry of the deflector as a component in the instrument. Conventions from the + NXtransformations base class are used. In principle, the McStas coordinate + system is used. The first transformation has to point either to another + component of the system or . (for pointing to the reference frame) to relate it + relative to the experimental setup. Typically, the components of a system should + all be related relative to each other and only one component should relate to + the reference coordinate system. + (NXaperture): + doc: | + The size and position of an aperture inserted in the column, e.g. field aperture + or contrast aperture + (NXdeflector): + doc: | + Deflectors in the collection column section + (NXlens_em): + doc: | + Individual lenses in the collection column section + (NXfabrication): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# ade39e7ed295bf737ba76d73ecd423510887fbdf2e9e101c2248659c79c057f9 +# +# +# +# +# +# Subclass of NXelectronanalyser to describe the electron collection +# column of a photoelectron analyser. +# +# +# +# Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum +# microscope, etc. +# +# +# +# +# Voltage applied to the extractor lens +# +# +# +# +# Current necessary to keep the extractor lens at a set voltage. Variations +# indicate leakage, field emission or arc currents to the extractor lens. +# +# +# +# +# Distance between sample and detector entrance +# +# +# +# +# Labelling of the lens setting in use. +# +# +# +# +# The space projected in the angularly dispersive directions, real or reciprocal +# +# +# +# +# +# +# +# +# The magnification of the electron lens assembly. +# +# +# +# +# Specifies the position of the collectioncolumn by pointing to the last +# transformation in the transformation chain in the NXtransformations group. +# +# +# +# +# Collection of axis-based translations and rotations to describe the location and +# geometry of the deflector as a component in the instrument. Conventions from the +# NXtransformations base class are used. In principle, the McStas coordinate +# system is used. The first transformation has to point either to another +# component of the system or . (for pointing to the reference frame) to relate it +# relative to the experimental setup. Typically, the components of a system should +# all be related relative to each other and only one component should relate to +# the reference coordinate system. +# +# +# +# +# The size and position of an aperture inserted in the column, e.g. field aperture +# or contrast aperture +# +# +# +# +# Deflectors in the collection column section +# +# +# +# +# Individual lenses in the collection column section +# +# +# +# diff --git a/contributed_definitions/nyaml/NXelectronanalyser.yaml b/contributed_definitions/nyaml/NXelectronanalyser.yaml new file mode 100644 index 0000000000..d6a32801cf --- /dev/null +++ b/contributed_definitions/nyaml/NXelectronanalyser.yaml @@ -0,0 +1,269 @@ +category: base +doc: | + Subclass of NXinstrument to describe a photoelectron analyser. + + Refers to Term `12.59`_ of the ISO 18115-1:2023 specification. + + .. _Term 12.59: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.59 +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays + nfa: | + Number of fast axes (axes acquired simultaneously, without scanning a + physical quantity) + nsa: | + Number of slow axes (axes acquired scanning a physical quantity) +type: group +NXelectronanalyser(NXobject): + description(NX_CHAR): + doc: | + Free text description of the type of the detector + name(NX_CHAR): + doc: | + Name or model of the equipment + \@short_name: + type: NX_CHAR + doc: | + Acronym or other shorthand name + energy_resolution(NX_FLOAT): + unit: NX_ENERGY + doc: | + Energy resolution of the electron analyser (FWHM of gaussian broadening) + + Refers to `Term 10.7`_ ff. of the ISO 18115-1:2023 specification. + .. _Term 10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 + momentum_resolution(NX_FLOAT): + unit: NX_WAVENUMBER + doc: | + Momentum resolution of the electron analyser (FWHM) + angular_resolution(NX_FLOAT): + unit: NX_ANGLE + doc: | + Angular resolution of the electron analyser (FWHM) + spatial_resolution(NX_FLOAT): + unit: NX_LENGTH + doc: | + Spatial resolution of the electron analyser (Airy disk radius) + + Refers to `Term 10.15`_ ff. of the ISO 18115-1:2023 specification. + .. _Term 10.15: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.15 + fast_axes(NX_CHAR): + doc: | + 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. + dimensions: + rank: 1 + dim: [[1, nfa]] + slow_axes(NX_CHAR): + doc: | + List of the axes that are acquired by scanning a physical parameter, listed in + order of decreasing speed. See fast_axes for examples. + dimensions: + rank: 1 + dim: [[1, nsa]] + depends_on(NX_CHAR): + doc: | + Refers to the last transformation specifying the position of the manipulator in + the NXtransformations chain. + (NXtransformations): + doc: | + 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. + (NXcollectioncolumn): + doc: | + Describes the electron collection (spatial and momentum imaging) column + (NXenergydispersion): + doc: | + Describes the energy dispersion section + (NXspindispersion): + doc: | + Describes the spin dispersion section + (NXdetector): + doc: | + Describes the electron detector + (NXdeflector): + doc: | + Deflectors outside the main optics ensambles described by the subclasses + (NXlens_em): + doc: | + Individual lenses outside the main optics ensambles described by the subclasses + (NXfabrication): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 8f8507c0c2afbfa0bd1b18e863e8f7c90326769b8ffcc52f48bf88712e1c5b15 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays +# +# +# +# Number of fast axes (axes acquired simultaneously, without scanning a +# physical quantity) +# +# +# +# +# Number of slow axes (axes acquired scanning a physical quantity) +# +# +# +# +# Subclass of NXinstrument to describe a photoelectron analyser. +# +# +# +# Free text description of the type of the detector +# +# +# +# +# Name or model of the equipment +# +# +# +# Acronym or other shorthand name +# +# +# +# +# +# Energy resolution of the electron analyser (FWHM of gaussian broadening) +# +# +# +# +# Momentum resolution of the electron analyser (FWHM) +# +# +# +# +# Angular resolution of the electron analyser (FWHM) +# +# +# +# +# Spatial resolution of the electron analyser (Airy disk radius) +# +# +# +# +# List of the axes that are acquired simultaneously by the detector. +# These refer only to the experimental variables recorded by the electron analyser. +# Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. +# +# .. csv-table:: Examples +# :header: "Mode", "fast_axes", "slow_axes" +# +# Hemispherical in ARPES mode, "['energy', 'kx']","" +# "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] +# "Tof", "['energy', 'kx', 'ky']","" +# "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" +# +# Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. +# If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. +# +# +# +# +# +# +# +# List of the axes that are acquired by scanning a physical parameter, listed in +# order of decreasing speed. See fast_axes for examples. +# +# +# +# +# +# +# +# Refers to the last transformation specifying the positon of the manipulator in +# the NXtransformations chain. +# +# +# +# +# Collection of axis-based translations and rotations to describe the location and +# geometry of the electron analyser as a component in the instrument. Conventions +# from the NXtransformations base class are used. In principle, the McStas +# coordinate system is used. The first transformation has to point either to +# another component of the system or . (for pointing to the reference frame) to +# relate it relative to the experimental setup. Typically, the components of a +# system should all be related relative to each other and only one component +# should relate to the reference coordinate system. +# +# +# +# +# Describes the electron collection (spatial and momentum imaging) column +# +# +# +# +# Describes the energy dispersion section +# +# +# +# +# Describes the spin dispersion section +# +# +# +# +# Describes the electron detector +# +# +# +# +# Deflectors outside the main optics ensambles described by the subclasses +# +# +# +# +# Individual lenses outside the main optics ensambles described by the subclasses +# +# +# +# diff --git a/contributed_definitions/nyaml/NXenergydispersion.yaml b/contributed_definitions/nyaml/NXenergydispersion.yaml new file mode 100644 index 0000000000..8eeced3568 --- /dev/null +++ b/contributed_definitions/nyaml/NXenergydispersion.yaml @@ -0,0 +1,151 @@ +category: base +doc: | + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. +type: group +NXenergydispersion(NXobject): + scheme(NX_CHAR): + doc: | + Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, + mirror, retarding grid, etc. + pass_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + Energy of the electrons on the mean path of the analyser. Pass energy for + hemispherics, drift energy for tofs. + + Refers to Term `12.63`_ of the ISO 18115-1:2023 specification. + .. _12.63: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.63 + center_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + Center of the energy window + energy_interval(NX_FLOAT): + unit: NX_ENERGY + doc: | + The interval of transmitted energies. It can be two different things depending + on whether the scan is fixed or swept. With a fixed scan it is a 2 vector + containing the extrema of the transmitted energy window (smaller number first). + With a swept scan of m steps it is a 2xm array of windows one for each + measurement point. + (NXaperture): + doc: | + Size, position and shape of a slit in dispersive analyzer, e.g. entrance and + exit slits. + diameter(NX_FLOAT): + unit: NX_LENGTH + doc: | + Diameter of the dispersive orbit + energy_scan_mode(NX_CHAR): + doc: | + Way of scanning the energy axis (fixed or sweep). + + Refers to Terms `12.65`_ and `12.66`_ of the ISO 18115-1:2023 specification. + .. _12.65: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.65 + .. _12.66: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.66 + enumeration: [fixed, sweep] + tof_distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + Length of the tof drift electrode + (NXdeflector): + doc: | + Deflectors in the energy dispersive section + (NXlens_em): + doc: | + Individual lenses in the energy dispersive section + (NXfabrication): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 3ea3bbd68a7e09a25fcdb8ce6a677d5a1e8b307138d9cfadd0948158678e35bf +# +# +# +# +# +# Subclass of NXelectronanalyser to describe the energy dispersion section of a +# photoelectron analyser. +# +# +# +# Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, +# mirror, retarding grid, etc. +# +# +# +# +# Energy of the electrons on the mean path of the analyser. Pass energy for +# hemispherics, drift energy for tofs. +# +# +# +# +# Center of the energy window +# +# +# +# +# The interval of transmitted energies. It can be two different things depending +# on whether the scan is fixed or swept. With a fixed scan it is a 2 vector +# containing the extrema of the transmitted energy window (smaller number first). +# With a swept scan of m steps it is a 2xm array of windows one for each +# measurement point. +# +# +# +# +# Size, position and shape of a slit in dispersive analyzer, e.g. entrance and +# exit slits. +# +# +# +# +# Diameter of the dispersive orbit +# +# +# +# +# Way of scanning the energy axis (fixed or sweep). +# +# +# +# +# +# +# +# +# Length of the tof drift electrode +# +# +# +# +# Deflectors in the energy dispersive section +# +# +# +# +# Individual lenses in the energy dispersive section +# +# +# +# diff --git a/contributed_definitions/nyaml/NXmanipulator.yaml b/contributed_definitions/nyaml/NXmanipulator.yaml new file mode 100644 index 0000000000..b247a8eac5 --- /dev/null +++ b/contributed_definitions/nyaml/NXmanipulator.yaml @@ -0,0 +1,163 @@ +category: base +doc: | + Extension of NXpositioner to include fields to describe the use of manipulators + in photoemission experiments. +type: group +NXmanipulator(NXobject): + name(NX_CHAR): + doc: | + Name of the manipulator. + description(NX_CHAR): + doc: | + A description of the manipulator. + type(NX_CHAR): + doc: | + Type of manipulator, Hexapod, Rod, etc. + cryocoolant(NX_BOOLEAN): + doc: | + Is cryocoolant flowing through the manipulator? + cryostat_temperature(NX_FLOAT): + unit: NX_TEMPERATURE + doc: | + Temperature of the cryostat (coldest point) + heater_power(NX_FLOAT): + unit: NX_POWER + doc: | + Power in the heater for temperature control. + sample_temperature(NX_FLOAT): + unit: NX_TEMPERATURE + doc: | + Temperature at the closest point to the sample. This field may also be found in + NXsample if present. + drain_current(NX_FLOAT): + unit: NX_CURRENT + doc: | + Current to neutralize the photoemission current. This field may also be found in + NXsample if present. + sample_bias(NX_FLOAT): + unit: NX_CURRENT + doc: | + Possible bias of the sample with respect to analyser ground. This field may + also be found in NXsample if present. + (NXpositioner): + doc: | + Class to describe the motors that are used in the manipulator + (NXfabrication): + depends_on(NX_CHAR): + doc: | + Refers to the last transformation specifying the positon of the manipulator in + the NXtransformations chain. + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# bf0f034176effed85072715ae95240a10701067bb337ea55c84482351c3d539d +# +# +# +# +# +# Extension of NXpositioner to include fields to describe the use of manipulators +# in photoemission experiments. +# +# +# +# Name of the manipulator. +# +# +# +# +# A description of the manipulator. +# +# +# +# +# Type of manipulator, Hexapod, Rod, etc. +# +# +# +# +# Is cryocoolant flowing through the manipulator? +# +# +# +# +# Temperature of the cryostat (coldest point) +# +# +# +# +# Power in the heater for temperature control. +# +# +# +# +# Temperature at the closest point to the sample. This field may also be found in +# NXsample if present. +# +# +# +# +# Current to neutralize the photoemission current. This field may also be found in +# NXsample if present. +# +# +# +# +# Possible bias of the sample with trespect to analyser ground. This field may +# also be found in NXsample if present. +# +# +# +# +# Class to describe the motors that are used in the manipulator +# +# +# +# +# +# Refers to the last transformation specifying the positon of the manipulator in +# the NXtransformations chain. +# +# +# +# +# Collection of axis-based translations and rotations to describe the location and +# geometry of the manipulator as a component in the instrument. Conventions from +# the NXtransformations base class are used. In principle, the McStas coordinate +# system is used. The first transformation has to point either to another +# component of the system or . (for pointing to the reference frame) to relate it +# relative to the experimental setup. Typically, the components of a system should +# all be related relative to each other and only one component should relate to +# the reference coordinate system. +# +# +# diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index eef22b8046..7ba0571c56 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -2,6 +2,12 @@ category: application doc: | This is the most general application definition for multidimensional photoelectron spectroscopy. + + Groups and fields are named according to the + `ISO 18115-1:2023`_ specification as well as the `IUPAC Recommendations 2020`_. + + .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 type: group NXmpes(NXobject): (NXentry): @@ -14,12 +20,22 @@ NXmpes(NXobject): Datetime of the end of the measurement. exists: recommended method: + exists: recommended doc: | - A name of the experimental method according - to the `ISO 18115-1:2023`_ specification. - + A name of the experimental method according to `Clause 11`_ of + the `ISO 18115-1:2023`_ specification. + + Examples include: + * X-ray photoelectron spectroscopy (XPS) + * angle-resolved X-ray photoelectron spectroscopy (ARXPS) + * ultraviolet photoelectron spectroscopy (UPS) + * angle-resolved photoelectron spectroscopy (ARPES) + * hard X-ray photoemission spectroscopy (HAXPES) + * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) + * photoelectron emission microscopy (PEEM) + .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html - exists: recommended + .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 definition: \@version: enumeration: [NXmpes] @@ -49,7 +65,19 @@ NXmpes(NXobject): doc: | Author ID defined by https://orcid.org/. (NXinstrument): + doc: | + MPES spectrometer + + Refers to Term `12.58`_ of the ISO 18115-1:2023 specification. + + .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 energy_resolution(NXresolution): + doc: | + Overall energy resolution of the MPES instrument + + Refers to Terms `10.7`_ ff. and `10.24`_ of the ISO 18115-1:2023 specification. + .. _10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 + .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 exists: recommended physical_quantity: type: @@ -100,17 +128,13 @@ NXmpes(NXobject): The beam emitted by this source. Should be named with the same appendix, e.g., for `source_probe` it should refer to `beam_probe`. - Refers to the same concept as /NXentry/NXinstrument/source_TYPE + Refers to the same concept as /NXentry/NXinstrument/beam_TYPE and may be linked. # It would be nice if we had the notion of linking in nexus or if # we have a subdefinition NXlink to refer to a path. # This would also be helpful for NXtransformations beam_TYPE(NXbeam): - - # Comment from mpes may workshop: Add linking between source and beam - - # Add extent as recommended? distance(NX_NUMBER): unit: NX_LENGTH exists: recommended @@ -128,10 +152,10 @@ NXmpes(NXobject): exists: recommended associated_source(NXsource): doc: | - The beam emitted by this source. + The source that emitted this beam. Should be named with the same appendix, e.g., for `beam_probe` it should refer to `source_probe`. - Refers to the same concept as /NXentry/NXinstrument/beam_TYPE + Refers to the same concept as /NXentry/NXinstrument/source_TYPE and may be linked. (NXelectronanalyser): device_information(NXfabrication): @@ -149,6 +173,9 @@ NXmpes(NXobject): doc: | Energy resolution of the analyser with the current setting. May be linked from a NXcalibration. + + Refers to Term `10.24` of the ISO 18115-1:2023 specification. + .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 fast_axes(NX_CHAR): exists: recommended slow_axes: @@ -247,6 +274,13 @@ NXmpes(NXobject): exists: recommended unit: NX_CURRENT sample_bias(NX_FLOAT): + doc: | + Bias of the sample with respect to analyser ground. + + This field may also be found in NXsample if present. + + Refers to Term `8.41`_ of the ISO 18115-1:2023 specification. + .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 exists: recommended unit: NX_CURRENT device_information(NXfabrication): From dd3be944fb4dbac1a895bed4965f2d7646375c56 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 29 Sep 2023 14:14:12 +0200 Subject: [PATCH 0294/1012] Add more ISO references to NXmpes --- .../NXelectronanalyser.nxdl.xml | 5 +- contributed_definitions/NXmpes.nxdl.xml | 53 +++++++++++++++---- .../nyaml/NXelectronanalyser.yaml | 14 ++--- contributed_definitions/nyaml/NXmpes.yaml | 47 ++++++++++++---- 4 files changed, 88 insertions(+), 31 deletions(-) diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml index c65bf492e3..0f290084a5 100644 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -146,7 +146,7 @@ Transmission function of the electron analyser. - The transmission function (TF) specifies the detection efficiency for electrons of + The transmission function (TF) specifies the detection efficiency per solid angle for electrons of different kinetic energy passing through the electron analyser. It depends on the spectrometer geometry as well as operation settings such as lens mode and pass energy. The transmission function is usually given as kinetic energy vs. relative intensity. @@ -155,6 +155,9 @@ transmission correction, a comparison of results measured from the same sample using different operating modes for an instrument would show significant variations in atomic concentrations. + + Refers to Term `7.15`_ ff. of the ISO 18115-1:2023 specification + .. _7.15: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:7.15 diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 2413325303..284e3710d9 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -67,6 +67,7 @@ * hard X-ray photoemission spectroscopy (HAXPES) * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) * photoelectron emission microscopy (PEEM) + * electron spectroscopy for chemical analysis (ESCA) .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 @@ -229,7 +230,7 @@ This would also be helpful for NXtransformations--> Energy resolution of the analyser with the current setting. May be linked from a NXcalibration. - Refers to Term `10.24` of the ISO 18115-1:2023 specification. + Refers to Term `10.24`_ of the ISO 18115-1:2023 specification. .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 @@ -393,6 +394,14 @@ Optional constant settings (like lens focusing parameters on the sample: positio of the following NXcalibrations + + Calibration event on the energy axis. + + For XPS, the calibration should ideally be performed according to + `ISO 15472:2010`_ specification. + + .. _ISO 15472:2010: https://www.iso.org/standard/74811.html + Has an energy calibration been applied? @@ -441,15 +450,20 @@ Optional constant settings (like lens focusing parameters on the sample: positio + + For energy referencing, the measured energies are corrected for the charging potential + (i.e., the electrical potential of the surface region of an insulating sample, caused by + irradiation) such that those energies correspond to a sample with no surface charge. + Usually, the energy axis is adjusted by shifting all energies uniformally until one + well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. + + Refers to Term `12.74`_ ff. of the ISO 18115-1:2023 specification + .. _12.74: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 + - Have the energy axes been adjusted (e.g., in cases where samples are not conductive)? - - For energy referencing, the measured energies are corrected for the charging potential - (i.e., the electrical potential of the surface region of an insulating sample, caused by - irradiation) such that those energies correspond to a sample with no surface charge. - Usually, the energy axis is adjusted by shifting all energies uniformally until one - well-defined emission line peak (or the Fermi edge) is located at a known "correct" energy. + Have the energy axes been adjusted (e.g., in cases where samples are not + conductive)? @@ -468,7 +482,10 @@ Optional constant settings (like lens focusing parameters on the sample: positio The binding energy (in units of eV) that the specified emission line appeared at, - after adjusting the binding energy scale . + after adjusting the binding energy scale. + + Refers to Term `12.16`_ ff. of the ISO 18115-1:2023 specification + .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 @@ -614,8 +631,22 @@ Optional constant settings (like lens focusing parameters on the sample: positio - - + + + Kinetic energy axis. + + Refers to Term `3.35`_ ff. of the ISO 18115-1:2023 specification + .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 + + + + + (Calibrated) binding energy axis. + + Refers to Term `12.16`_ ff. of the ISO 18115-1:2023 specification + .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + + diff --git a/contributed_definitions/nyaml/NXelectronanalyser.yaml b/contributed_definitions/nyaml/NXelectronanalyser.yaml index cdee8f809d..01b5962865 100644 --- a/contributed_definitions/nyaml/NXelectronanalyser.yaml +++ b/contributed_definitions/nyaml/NXelectronanalyser.yaml @@ -1,13 +1,10 @@ category: base doc: | Subclass of NXinstrument to describe a photoelectron analyser. -<<<<<<< HEAD -======= Refers to Term `12.59`_ of the ISO 18115-1:2023 specification. .. _Term 12.59: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.59 ->>>>>>> mpes-iso-standard symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays @@ -16,11 +13,8 @@ symbols: physical quantity) nsa: | Number of slow axes (axes acquired scanning a physical quantity) -<<<<<<< HEAD n_transmission_function: | Number of data points in the transmission function. -======= ->>>>>>> mpes-iso-standard type: group NXelectronanalyser(NXobject): description(NX_CHAR): @@ -105,7 +99,7 @@ NXelectronanalyser(NXobject): doc: | Transmission function of the electron analyser. - The transmission function (TF) specifies the detection efficiency for electrons of + The transmission function (TF) specifies the detection efficiency per solid angle for electrons of different kinetic energy passing through the electron analyser. It depends on the spectrometer geometry as well as operation settings such as lens mode and pass energy. The transmission function is usually given as kinetic energy vs. relative intensity. @@ -114,6 +108,9 @@ NXelectronanalyser(NXobject): transmission correction, a comparison of results measured from the same sample using different operating modes for an instrument would show significant variations in atomic concentrations. + + Refers to Term `7.15`_ ff. of the ISO 18115-1:2023 specification + .. _7.15: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:7.15 \@signal: enumeration: [relative_intensity] \@axes: @@ -160,8 +157,6 @@ NXelectronanalyser(NXobject): (NXlens_em): doc: | Individual lenses outside the main optics ensambles described by the subclasses -<<<<<<< HEAD -======= (NXfabrication): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ @@ -324,4 +319,3 @@ NXelectronanalyser(NXobject): # # # ->>>>>>> mpes-iso-standard diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 3e2e0d8866..ac3d2c7942 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -38,6 +38,7 @@ NXmpes(NXobject): * hard X-ray photoemission spectroscopy (HAXPES) * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) * photoelectron emission microscopy (PEEM) + * electron spectroscopy for chemical analysis (ESCA) .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 @@ -179,7 +180,7 @@ NXmpes(NXobject): Energy resolution of the analyser with the current setting. May be linked from a NXcalibration. - Refers to Term `10.24` of the ISO 18115-1:2023 specification. + Refers to Term `10.24`_ of the ISO 18115-1:2023 specification. .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 fast_axes: exists: recommended @@ -316,6 +317,13 @@ NXmpes(NXobject): Describe the appropriate axis calibrations for your experiment using one or more of the following NXcalibrations energy_calibration(NXcalibration): + doc: | + Calibration event on the energy axis. + + For XPS, the calibration should ideally be performed according to + `ISO 15472:2010`_ specification. + + .. _ISO 15472:2010: https://www.iso.org/standard/74811.html exists: optional applied(NX_BOOLEAN): doc: | @@ -353,15 +361,18 @@ NXmpes(NXobject): This is the momentum axis to be used for data plotting. energy_referencing(NXcalibration): exists: optional + doc: | + For energy referencing, the measured energies are corrected for the charging potential + (i.e., the electrical potential of the surface region of an insulating sample, caused by + irradiation) such that those energies correspond to a sample with no surface charge. + Usually, the energy axis is adjusted by shifting all energies uniformally until one + well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. + + Refers to Term `12.74`_ ff. of the ISO 18115-1:2023 specification + .. _12.74: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 applied(NX_BOOLEAN): doc: | Have the energy axes been adjusted (e.g., in cases where samples are not conductive)? - - For energy referencing, the measured energies are corrected for the charging potential - (i.e., the electrical potential of the surface region of an insulating sample, caused by - irradiation) such that those energies correspond to a sample with no surface charge. - Usually, the energy axis is adjusted by shifting all energies uniformally until one - well-defined emission line peak (or the Fermi edge) is located at a known "correct" energy. emission_line: exists: recommended doc: | @@ -376,7 +387,10 @@ NXmpes(NXobject): exists: recommended doc: | The binding energy (in units of eV) that the specified emission line appeared at, - after adjusting the binding energy scale . + after adjusting the binding energy scale. + + Refers to Term `12.16`_ ff. of the ISO 18115-1:2023 specification + .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 calibrated_axis(NX_FLOAT): exists: recommended doc: | @@ -490,4 +504,19 @@ NXmpes(NXobject): /entry/process/energy_correction/calibrated_axis. \@type(NX_CHAR): exists: recommended - enumeration: [kinetic, binding] \ No newline at end of file + enumeration: + kinetic: + doc: | + Kinetic energy axis. + + Refers to Term `3.35`_ ff. of the ISO 18115-1:2023 specification + .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 + binding: + doc: | + (Calibrated) binding energy axis. + + Refers to Term `12.16`_ ff. of the ISO 18115-1:2023 specification + .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + + + From 395fc34d51ca79f34b18eedd4ddf320e4ff6887b Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 29 Sep 2023 14:28:03 +0200 Subject: [PATCH 0295/1012] update data docstring with ISO reference --- contributed_definitions/NXmpes.nxdl.xml | 4 ++-- contributed_definitions/nyaml/NXmpes.yaml | 13 +++++-------- 2 files changed, 7 insertions(+), 10 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 284e3710d9..d5c0b63233 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -635,7 +635,7 @@ Optional constant settings (like lens focusing parameters on the sample: positio Kinetic energy axis. - Refers to Term `3.35`_ ff. of the ISO 18115-1:2023 specification + Refers to Term `3.35`_ of the ISO 18115-1:2023 specification .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 @@ -643,7 +643,7 @@ Optional constant settings (like lens focusing parameters on the sample: positio (Calibrated) binding energy axis. - Refers to Term `12.16`_ ff. of the ISO 18115-1:2023 specification + Refers to Term `12.16`_ of the ISO 18115-1:2023 specification .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index ac3d2c7942..ffec8ba932 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -505,18 +505,15 @@ NXmpes(NXobject): \@type(NX_CHAR): exists: recommended enumeration: - kinetic: + kinetic: doc: | Kinetic energy axis. - Refers to Term `3.35`_ ff. of the ISO 18115-1:2023 specification + Refers to Term `3.35`_ of the ISO 18115-1:2023 specification .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 - binding: + binding: doc: | (Calibrated) binding energy axis. - Refers to Term `12.16`_ ff. of the ISO 18115-1:2023 specification - .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - - - + Refers to Term `12.16`_ of the ISO 18115-1:2023 specification + .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 \ No newline at end of file From cee594017dd98ddfbd9a5faade3c10001fed34b5 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 5 Oct 2023 11:09:59 +0200 Subject: [PATCH 0296/1012] Use mapping in NXcalibration --- contributed_definitions/NXcalibration.nxdl.xml | 10 +++++++--- contributed_definitions/NXmpes.nxdl.xml | 11 ++++++++--- contributed_definitions/nyaml/NXcalibration.yaml | 10 +++++++--- contributed_definitions/nyaml/NXmpes.yaml | 10 +++++++--- 4 files changed, 29 insertions(+), 12 deletions(-) diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml index 3451347074..b55f99dcc4 100644 --- a/contributed_definitions/NXcalibration.nxdl.xml +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -103,7 +103,7 @@ - + A description of the procedures employed. @@ -113,9 +113,13 @@ File containing the input data for calibration. - + - Input data for calibration. + Mapping data for calibration. + + This can be used to map data points from uncalibrated + to calibrated values, e.g., by multiplying each point by the + corresponding point in the mapping data. diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index d5c0b63233..10c3ca8aaf 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -497,6 +497,12 @@ Optional constant settings (like lens focusing parameters on the sample: positio + + In the transmission correction, each intensity measurement for electrons of a given + kinetic energy is multiplied by the corresponding value in the relative_intensity + field of the transmission_function. This calibration procedure is used to account for + the different tranmsission efficiencies when using different lens modes. + Has an intensity calibration been applied? @@ -504,13 +510,12 @@ Optional constant settings (like lens focusing parameters on the sample: positio That is, has the transmission function of the analyser been taken into account? - + Transmission function of the electron analyser. The transmission function (TF) specifies the detection efficiency for electrons of - different kinetic energy passing through the electron analyser. - + different kinetic energy passing through the electron analyser. This can be a link to /entry/instrument/electronanalyser/transmission_function. diff --git a/contributed_definitions/nyaml/NXcalibration.yaml b/contributed_definitions/nyaml/NXcalibration.yaml index 387f9b08c2..e1e651e2d9 100644 --- a/contributed_definitions/nyaml/NXcalibration.yaml +++ b/contributed_definitions/nyaml/NXcalibration.yaml @@ -59,12 +59,16 @@ NXcalibration(NXobject): dimensions: rank: 1 dim: [[1, ncal]] - description(NX_CHAR): + description: doc: | A description of the procedures employed. calibration_file(NXnote): doc: | File containing the input data for calibration. - calibration_input_data(NXdata): + MAPPING(NXdata): doc: | - Input data for calibration. \ No newline at end of file + Mapping data for calibration. + + This can be used to map data points from uncalibrated + to calibrated values, e.g., by multiplying each point by the + corresponding point in the mapping data. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index ffec8ba932..35d059840a 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -398,20 +398,24 @@ NXmpes(NXobject): This should link to /entry/data/energy. transmission_correction(NXcalibration): + doc: | + In the transmission correction, each intensity measurement for electrons of a given + kinetic energy is multiplied by the corresponding value in the relative_intensity + field of the transmission_function. This calibration procedure is used to account for + the different tranmsission efficiencies when using different lens modes. exists: optional applied(NX_BOOLEAN): doc: | Has an intensity calibration been applied? That is, has the transmission function of the analyser been taken into account? - calibration_input_data(NXdata): + transmission_function(NXdata): exists: recommended doc: | Transmission function of the electron analyser. The transmission function (TF) specifies the detection efficiency for electrons of - different kinetic energy passing through the electron analyser. - + different kinetic energy passing through the electron analyser. This can be a link to /entry/instrument/electronanalyser/transmission_function. \@signal: enumeration: [relative_intensity] From fdfcc5461df172fe126139d50e6225f813c01103 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 5 Oct 2023 14:14:47 +0200 Subject: [PATCH 0297/1012] Update ISO links in docs --- .../NXcalibration.nxdl.xml | 2 +- .../NXelectronanalyser.nxdl.xml | 17 ++++++++------ .../NXenergydispersion.nxdl.xml | 2 ++ contributed_definitions/NXmpes.nxdl.xml | 19 ++++++++++----- .../nyaml/NXcalibration.yaml | 2 +- .../nyaml/NXelectronanalyser.yaml | 17 ++++++++------ .../nyaml/NXenergydispersion.yaml | 2 ++ contributed_definitions/nyaml/NXmpes.yaml | 23 ++++++++++++------- 8 files changed, 54 insertions(+), 30 deletions(-) diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml index b55f99dcc4..700506294d 100644 --- a/contributed_definitions/NXcalibration.nxdl.xml +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -113,7 +113,7 @@ File containing the input data for calibration. - + Mapping data for calibration. diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml index 0f290084a5..4189b83d91 100644 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -48,7 +48,7 @@ Refers to Term `12.59`_ of the ISO 18115-1:2023 specification. - .. _Term 12.59: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.59 + .. _12.59: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.59 @@ -90,8 +90,9 @@ Energy resolution of the electron analyser (FWHM of gaussian broadening) - Refers to `Term 10.7`_ ff. of the ISO 18115-1:2023 specification. - .. _Term 10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 + Refers to Term `10.7`_ of the ISO 18115-1:2023 specification. + + .. _10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 @@ -108,8 +109,9 @@ Spatial resolution of the electron analyser (Airy disk radius) - Refers to `Term 10.15`_ ff. of the ISO 18115-1:2023 specification. - .. _Term 10.15: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.15 + Refers to Term `10.15`_ ff. of the ISO 18115-1:2023 specification. + + .. _10.15: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.15 @@ -156,8 +158,9 @@ operating modes for an instrument would show significant variations in atomic concentrations. - Refers to Term `7.15`_ ff. of the ISO 18115-1:2023 specification - .. _7.15: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:7.15 + Refers to Term `7.15`_ ff. of the ISO 18115-1:2023 specification. + + .. _7.15: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:7.15 diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml index a42550b405..ead97311db 100644 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ b/contributed_definitions/NXenergydispersion.nxdl.xml @@ -38,6 +38,7 @@ hemispherics, drift energy for tofs. Refers to Term `12.63`_ of the ISO 18115-1:2023 specification. + .. _12.63: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.63 @@ -71,6 +72,7 @@ Way of scanning the energy axis (fixed or sweep). Refers to Terms `12.65`_ and `12.66`_ of the ISO 18115-1:2023 specification. + .. _12.65: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.65 .. _12.66: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.66 diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 10c3ca8aaf..05f29a7199 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -124,7 +124,8 @@ Overall energy resolution of the MPES instrument - Refers to Terms `10.7`_ ff. and `10.24`_ of the ISO 18115-1:2023 specification. + Refers to Terms `10.7`_ ff. and `10.24`_ of the ISO 18115-1:2023 specification. + .. _10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 @@ -231,6 +232,7 @@ This would also be helpful for NXtransformations--> NXcalibration. Refers to Term `10.24`_ of the ISO 18115-1:2023 specification. + .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 @@ -377,6 +379,7 @@ Optional constant settings (like lens focusing parameters on the sample: positio This field may also be found in NXsample if present. Refers to Term `8.41`_ of the ISO 18115-1:2023 specification. + .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 @@ -457,7 +460,8 @@ Optional constant settings (like lens focusing parameters on the sample: positio Usually, the energy axis is adjusted by shifting all energies uniformally until one well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. - Refers to Term `12.74`_ ff. of the ISO 18115-1:2023 specification + Refers to Term `12.74`_ ff. of the ISO 18115-1:2023 specification. + .. _12.74: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 @@ -484,7 +488,8 @@ Optional constant settings (like lens focusing parameters on the sample: positio The binding energy (in units of eV) that the specified emission line appeared at, after adjusting the binding energy scale. - Refers to Term `12.16`_ ff. of the ISO 18115-1:2023 specification + Refers to Term `12.16`_ ff. of the ISO 18115-1:2023 specification. + .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 @@ -510,7 +515,7 @@ Optional constant settings (like lens focusing parameters on the sample: positio That is, has the transmission function of the analyser been taken into account? - + Transmission function of the electron analyser. @@ -640,7 +645,8 @@ Optional constant settings (like lens focusing parameters on the sample: positio Kinetic energy axis. - Refers to Term `3.35`_ of the ISO 18115-1:2023 specification + Refers to Term `3.35`_ of the ISO 18115-1:2023 specification. + .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 @@ -648,7 +654,8 @@ Optional constant settings (like lens focusing parameters on the sample: positio (Calibrated) binding energy axis. - Refers to Term `12.16`_ of the ISO 18115-1:2023 specification + Refers to Term `12.16`_ of the ISO 18115-1:2023 specification. + .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 diff --git a/contributed_definitions/nyaml/NXcalibration.yaml b/contributed_definitions/nyaml/NXcalibration.yaml index e1e651e2d9..6a1dc86655 100644 --- a/contributed_definitions/nyaml/NXcalibration.yaml +++ b/contributed_definitions/nyaml/NXcalibration.yaml @@ -65,7 +65,7 @@ NXcalibration(NXobject): calibration_file(NXnote): doc: | File containing the input data for calibration. - MAPPING(NXdata): + mapping(NXdata): doc: | Mapping data for calibration. diff --git a/contributed_definitions/nyaml/NXelectronanalyser.yaml b/contributed_definitions/nyaml/NXelectronanalyser.yaml index 01b5962865..723a5cb48d 100644 --- a/contributed_definitions/nyaml/NXelectronanalyser.yaml +++ b/contributed_definitions/nyaml/NXelectronanalyser.yaml @@ -4,7 +4,7 @@ doc: | Refers to Term `12.59`_ of the ISO 18115-1:2023 specification. - .. _Term 12.59: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.59 + .. _12.59: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.59 symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays @@ -52,8 +52,9 @@ NXelectronanalyser(NXobject): doc: | Energy resolution of the electron analyser (FWHM of gaussian broadening) - Refers to `Term 10.7`_ ff. of the ISO 18115-1:2023 specification. - .. _Term 10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 + Refers to Term `10.7`_ of the ISO 18115-1:2023 specification. + + .. _10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 momentum_resolution(NX_FLOAT): unit: NX_WAVENUMBER doc: | @@ -67,8 +68,9 @@ NXelectronanalyser(NXobject): doc: | Spatial resolution of the electron analyser (Airy disk radius) - Refers to `Term 10.15`_ ff. of the ISO 18115-1:2023 specification. - .. _Term 10.15: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.15 + Refers to Term `10.15`_ ff. of the ISO 18115-1:2023 specification. + + .. _10.15: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.15 fast_axes(NX_CHAR): doc: | List of the axes that are acquired simultaneously by the detector. @@ -109,8 +111,9 @@ NXelectronanalyser(NXobject): operating modes for an instrument would show significant variations in atomic concentrations. - Refers to Term `7.15`_ ff. of the ISO 18115-1:2023 specification - .. _7.15: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:7.15 + Refers to Term `7.15`_ ff. of the ISO 18115-1:2023 specification. + + .. _7.15: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:7.15 \@signal: enumeration: [relative_intensity] \@axes: diff --git a/contributed_definitions/nyaml/NXenergydispersion.yaml b/contributed_definitions/nyaml/NXenergydispersion.yaml index 8eeced3568..ed6d2df7da 100644 --- a/contributed_definitions/nyaml/NXenergydispersion.yaml +++ b/contributed_definitions/nyaml/NXenergydispersion.yaml @@ -15,6 +15,7 @@ NXenergydispersion(NXobject): hemispherics, drift energy for tofs. Refers to Term `12.63`_ of the ISO 18115-1:2023 specification. + .. _12.63: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.63 center_energy(NX_FLOAT): unit: NX_ENERGY @@ -41,6 +42,7 @@ NXenergydispersion(NXobject): Way of scanning the energy axis (fixed or sweep). Refers to Terms `12.65`_ and `12.66`_ of the ISO 18115-1:2023 specification. + .. _12.65: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.65 .. _12.66: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.66 enumeration: [fixed, sweep] diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 35d059840a..654f58da84 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -81,7 +81,8 @@ NXmpes(NXobject): doc: | Overall energy resolution of the MPES instrument - Refers to Terms `10.7`_ ff. and `10.24`_ of the ISO 18115-1:2023 specification. + Refers to Terms `10.7`_ ff. and `10.24`_ of the ISO 18115-1:2023 specification. + .. _10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 exists: recommended @@ -181,6 +182,7 @@ NXmpes(NXobject): NXcalibration. Refers to Term `10.24`_ of the ISO 18115-1:2023 specification. + .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 fast_axes: exists: recommended @@ -299,6 +301,7 @@ NXmpes(NXobject): This field may also be found in NXsample if present. Refers to Term `8.41`_ of the ISO 18115-1:2023 specification. + .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 exists: recommended unit: NX_CURRENT @@ -368,7 +371,8 @@ NXmpes(NXobject): Usually, the energy axis is adjusted by shifting all energies uniformally until one well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. - Refers to Term `12.74`_ ff. of the ISO 18115-1:2023 specification + Refers to Term `12.74`_ ff. of the ISO 18115-1:2023 specification. + .. _12.74: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 applied(NX_BOOLEAN): doc: | @@ -389,7 +393,8 @@ NXmpes(NXobject): The binding energy (in units of eV) that the specified emission line appeared at, after adjusting the binding energy scale. - Refers to Term `12.16`_ ff. of the ISO 18115-1:2023 specification + Refers to Term `12.16`_ ff. of the ISO 18115-1:2023 specification. + .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 calibrated_axis(NX_FLOAT): exists: recommended @@ -409,7 +414,7 @@ NXmpes(NXobject): Has an intensity calibration been applied? That is, has the transmission function of the analyser been taken into account? - transmission_function(NXdata): + mapping(NXdata): exists: recommended doc: | Transmission function of the electron analyser. @@ -509,15 +514,17 @@ NXmpes(NXobject): \@type(NX_CHAR): exists: recommended enumeration: - kinetic: + kinetic: doc: | Kinetic energy axis. - Refers to Term `3.35`_ of the ISO 18115-1:2023 specification + Refers to Term `3.35`_ of the ISO 18115-1:2023 specification. + .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 binding: doc: | (Calibrated) binding energy axis. - - Refers to Term `12.16`_ of the ISO 18115-1:2023 specification + + Refers to Term `12.16`_ of the ISO 18115-1:2023 specification. + .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 \ No newline at end of file From 56dabc3fd1c55be60d6655bae703022dc188f04d Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 5 Oct 2023 14:42:15 +0200 Subject: [PATCH 0298/1012] Update doc in type attribute of NXdata --- contributed_definitions/NXmpes.nxdl.xml | 19 +++++++++---------- contributed_definitions/nyaml/NXmpes.yaml | 20 ++++++++++---------- 2 files changed, 19 insertions(+), 20 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 05f29a7199..97568b7b99 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -640,23 +640,22 @@ Optional constant settings (like lens focusing parameters on the sample: positio /entry/process/energy_correction/calibrated_axis. + + The energy can be either stored as kinetic (Term `3.35`_ of the ISO 18115-1:2023 + specification) or as binding (Term `12.16`_) energy. + + .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 + .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + - Kinetic energy axis. - - Refers to Term `3.35`_ of the ISO 18115-1:2023 specification. - - .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 + Calibrated kinetic energy axis. - (Calibrated) binding energy axis. - - Refers to Term `12.16`_ of the ISO 18115-1:2023 specification. - - .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + Calibrated binding energy axis. diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 654f58da84..ada2b880e0 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -513,18 +513,18 @@ NXmpes(NXobject): /entry/process/energy_correction/calibrated_axis. \@type(NX_CHAR): exists: recommended + doc: | + The energy can be either stored as kinetic (Term `3.35`_ of the ISO 18115-1:2023 + specification) or as binding (Term `12.16`_) energy. + + .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 + .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 enumeration: kinetic: doc: | - Kinetic energy axis. - - Refers to Term `3.35`_ of the ISO 18115-1:2023 specification. - - .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 + Calibrated kinetic energy axis. binding: doc: | - (Calibrated) binding energy axis. - - Refers to Term `12.16`_ of the ISO 18115-1:2023 specification. - - .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 \ No newline at end of file + Calibrated binding energy axis. + + \ No newline at end of file From b2dbb48d2fff7a3134d6612ed0ae48d760d7fe80 Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Thu, 5 Oct 2023 15:01:19 +0200 Subject: [PATCH 0299/1012] Fixes makefile pickung up nxdl rules for `make nyaml` (#73) --- Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 812d138a04..829ce857a6 100644 --- a/Makefile +++ b/Makefile @@ -111,8 +111,8 @@ $(APPDEF_DIR)/%.nxdl.xml : $(APPDEF_DIR)/$(NYAML_SUBDIR)/%.yaml mv $(APPDEF_DIR)/$(NYAML_SUBDIR)/$*.nxdl.xml $@ NXDLS := $(foreach dir,$(NXDL_DIRS),$(wildcard $(dir)/*.nxdl.xml)) -nyaml : $(DIRS) $(NXDLS) - for file in $^; do\ +nyaml : $(DIRS) + for file in $(NXDLS); do\ mkdir -p "$${file%/*}/nyaml";\ nyaml2nxdl --input-file $${file};\ FNAME=$${file##*/};\ From 1a694807aaea98cea34240ee60300692a4fb5dc9 Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Thu, 5 Oct 2023 15:01:56 +0200 Subject: [PATCH 0300/1012] CI/CD for yaml/nxdl consistency (#70) * Re-adds yaml files * Adds ci/cd check for yaml files * Fix ci yaml file * Install nyaml2nxdl * Install locally to get correct xsd path * Use python 3.9 and ubuntu-latest * Introduce intentional async between NXmpes.nxdl and NXmpes.yaml for testing * Reverts NXmpes test changes * Sets proper date for cleaning pages * Check request changes token * Don't request changes if not clean * Restore NXmpes sync * Adds _parsed.yaml files to .gitignore * Updates favicon --- .github/workflows/fairmat-clean-pages.yaml | 5 +- .../fairmat-nxdl-yaml-consistency.yaml | 31 + .gitignore | 4 +- applications/nyaml/NXarchive.yaml | 281 + applications/nyaml/NXarpes.yaml | 226 + applications/nyaml/NXcanSAS.yaml | 2422 +++++++++ applications/nyaml/NXdirecttof.yaml | 102 + applications/nyaml/NXfluo.yaml | 165 + applications/nyaml/NXindirecttof.yaml | 111 + applications/nyaml/NXiqproc.yaml | 201 + applications/nyaml/NXlauetof.yaml | 244 + applications/nyaml/NXmonopd.yaml | 223 + applications/nyaml/NXmx.yaml | 1758 +++++++ applications/nyaml/NXrefscan.yaml | 197 + applications/nyaml/NXreftof.yaml | 214 + applications/nyaml/NXsas.yaml | 369 ++ applications/nyaml/NXsastof.yaml | 312 ++ applications/nyaml/NXscan.yaml | 181 + applications/nyaml/NXspe.yaml | 128 + applications/nyaml/NXsqom.yaml | 211 + applications/nyaml/NXstxm.yaml | 366 ++ applications/nyaml/NXtas.yaml | 350 ++ applications/nyaml/NXtofnpd.yaml | 233 + applications/nyaml/NXtofraw.yaml | 255 + applications/nyaml/NXtofsingle.yaml | 244 + applications/nyaml/NXtomo.yaml | 279 + applications/nyaml/NXtomophase.yaml | 292 ++ applications/nyaml/NXtomoproc.yaml | 217 + applications/nyaml/NXxas.yaml | 212 + applications/nyaml/NXxasproc.yaml | 147 + applications/nyaml/NXxbase.yaml | 308 ++ applications/nyaml/NXxeuler.yaml | 173 + applications/nyaml/NXxkappa.yaml | 174 + applications/nyaml/NXxlaue.yaml | 109 + applications/nyaml/NXxlaueplate.yaml | 73 + applications/nyaml/NXxnb.yaml | 160 + applications/nyaml/NXxrot.yaml | 155 + base_classes/nyaml/NXaperture.yaml | 214 + base_classes/nyaml/NXattenuator.yaml | 206 + base_classes/nyaml/NXbeam.yaml | 889 ++++ base_classes/nyaml/NXbeam_stop.yaml | 207 + base_classes/nyaml/NXbending_magnet.yaml | 210 + base_classes/nyaml/NXcapillary.yaml | 163 + base_classes/nyaml/NXcite.yaml | 112 + base_classes/nyaml/NXcollection.yaml | 102 + base_classes/nyaml/NXcollimator.yaml | 196 + base_classes/nyaml/NXcrystal.yaml | 667 +++ .../nyaml/NXcylindrical_geometry.yaml | 169 + base_classes/nyaml/NXdata.yaml | 807 +++ base_classes/nyaml/NXdetector.yaml | 1757 +++++++ base_classes/nyaml/NXdetector_group.yaml | 182 + base_classes/nyaml/NXdetector_module.yaml | 302 ++ base_classes/nyaml/NXdisk_chopper.yaml | 322 ++ base_classes/nyaml/NXentry.yaml | 521 ++ base_classes/nyaml/NXenvironment.yaml | 120 + base_classes/nyaml/NXevent_data.yaml | 220 + base_classes/nyaml/NXfermi_chopper.yaml | 210 + base_classes/nyaml/NXfilter.yaml | 373 ++ base_classes/nyaml/NXflipper.yaml | 159 + base_classes/nyaml/NXfresnel_zone_plate.yaml | 178 + base_classes/nyaml/NXgeometry.yaml | 128 + base_classes/nyaml/NXgrating.yaml | 202 + base_classes/nyaml/NXguide.yaml | 416 ++ base_classes/nyaml/NXinsertion_device.yaml | 203 + base_classes/nyaml/NXinstrument.yaml | 189 + base_classes/nyaml/NXlog.yaml | 252 + base_classes/nyaml/NXmirror.yaml | 346 ++ base_classes/nyaml/NXmoderator.yaml | 193 + base_classes/nyaml/NXmonitor.yaml | 293 ++ base_classes/nyaml/NXmonochromator.yaml | 197 + base_classes/nyaml/NXnote.yaml | 116 + base_classes/nyaml/NXobject.yaml | 44 + base_classes/nyaml/NXoff_geometry.yaml | 197 + base_classes/nyaml/NXorientation.yaml | 111 + base_classes/nyaml/NXparameters.yaml | 75 + base_classes/nyaml/NXpdb.yaml | 329 ++ base_classes/nyaml/NXpinhole.yaml | 125 + base_classes/nyaml/NXpolarizer.yaml | 135 + base_classes/nyaml/NXpositioner.yaml | 200 + base_classes/nyaml/NXprocess.yaml | 138 + base_classes/nyaml/NXreflections.yaml | 1266 +++++ base_classes/nyaml/NXroot.yaml | 180 + base_classes/nyaml/NXsample.yaml | 938 ++++ base_classes/nyaml/NXsample_component.yaml | 392 ++ base_classes/nyaml/NXsensor.yaml | 323 ++ base_classes/nyaml/NXshape.yaml | 143 + base_classes/nyaml/NXslit.yaml | 141 + base_classes/nyaml/NXsource.yaml | 520 ++ base_classes/nyaml/NXsubentry.yaml | 344 ++ base_classes/nyaml/NXtransformations.yaml | 406 ++ base_classes/nyaml/NXtranslation.yaml | 102 + base_classes/nyaml/NXuser.yaml | 145 + base_classes/nyaml/NXvelocity_selector.yaml | 198 + base_classes/nyaml/NXxraylens.yaml | 220 + common/favicon.ico | Bin 2238 -> 15406 bytes .../nyaml/NXaberration.yaml | 86 + .../nyaml/NXaberration_model.yaml | 173 + .../nyaml/NXaberration_model_ceos.yaml | 164 + .../nyaml/NXaberration_model_nion.yaml | 103 + contributed_definitions/nyaml/NXactivity.yaml | 84 + contributed_definitions/nyaml/NXadc.yaml | 53 + .../nyaml/NXamplifier.yaml | 147 + .../nyaml/NXaperture_em.yaml | 92 + contributed_definitions/nyaml/NXapm.yaml | 3303 ++++++++++++ .../NXapm_composition_space_results.yaml | 903 ++++ .../nyaml/NXapm_input_ranging.yaml | 101 + .../nyaml/NXapm_input_reconstruction.yaml | 89 + .../NXapm_paraprobe_config_clusterer.yaml | 860 +++ .../NXapm_paraprobe_config_distancer.yaml | 453 ++ .../NXapm_paraprobe_config_intersector.yaml | 610 +++ .../NXapm_paraprobe_config_nanochem.yaml | 2048 ++++++++ .../nyaml/NXapm_paraprobe_config_ranger.yaml | 531 ++ .../NXapm_paraprobe_config_selector.yaml | 240 + .../NXapm_paraprobe_config_spatstat.yaml | 662 +++ .../NXapm_paraprobe_config_surfacer.yaml | 509 ++ .../NXapm_paraprobe_config_tessellator.yaml | 449 ++ .../NXapm_paraprobe_config_transcoder.yaml | 194 + .../NXapm_paraprobe_results_clusterer.yaml | 960 ++++ .../NXapm_paraprobe_results_distancer.yaml | 730 +++ .../NXapm_paraprobe_results_intersector.yaml | 736 +++ .../NXapm_paraprobe_results_nanochem.yaml | 3752 +++++++++++++ .../nyaml/NXapm_paraprobe_results_ranger.yaml | 809 +++ .../NXapm_paraprobe_results_selector.yaml | 517 ++ .../NXapm_paraprobe_results_spatstat.yaml | 687 +++ .../NXapm_paraprobe_results_surfacer.yaml | 935 ++++ .../NXapm_paraprobe_results_tessellator.yaml | 1284 +++++ .../NXapm_paraprobe_results_transcoder.yaml | 1080 ++++ .../nyaml/NXbeam_path.yaml | 780 +++ .../nyaml/NXbeam_splitter.yaml | 637 +++ .../nyaml/NXbias_spectroscopy.yaml | 282 + .../nyaml/NXcalibration.yaml | 178 + .../nyaml/NXcg_alpha_complex.yaml | 253 + .../nyaml/NXcg_cylinder_set.yaml | 292 ++ .../nyaml/NXcg_ellipsoid_set.yaml | 234 + .../nyaml/NXcg_face_list_data_structure.yaml | 429 ++ .../nyaml/NXcg_geodesic_mesh.yaml | 91 + contributed_definitions/nyaml/NXcg_grid.yaml | 311 ++ .../nyaml/NXcg_half_edge_data_structure.yaml | 307 ++ .../nyaml/NXcg_hexahedron_set.yaml | 435 ++ .../nyaml/NXcg_marching_cubes.yaml | 119 + .../nyaml/NXcg_parallelogram_set.yaml | 330 ++ .../nyaml/NXcg_point_set.yaml | 163 + .../nyaml/NXcg_polygon_set.yaml | 409 ++ .../nyaml/NXcg_polyhedron_set.yaml | 345 ++ .../nyaml/NXcg_polyline_set.yaml | 324 ++ .../nyaml/NXcg_roi_set.yaml | 60 + .../nyaml/NXcg_sphere_set.yaml | 208 + .../nyaml/NXcg_tetrahedron_set.yaml | 313 ++ .../nyaml/NXcg_triangle_set.yaml | 225 + .../nyaml/NXcg_triangulated_surface_mesh.yaml | 89 + .../nyaml/NXcg_unit_normal_set.yaml | 112 + contributed_definitions/nyaml/NXchamber.yaml | 56 + .../nyaml/NXchemical_composition.yaml | 110 + .../nyaml/NXchemical_process.yaml | 90 + contributed_definitions/nyaml/NXcircuit.yaml | 227 + .../nyaml/NXcircuit_board.yaml | 67 + .../nyaml/NXclustering.yaml | 206 + .../nyaml/NXcollectioncolumn.yaml | 165 + .../nyaml/NXcontainer.yaml | 294 ++ .../nyaml/NXcoordinate_system_set.yaml | 257 + .../nyaml/NXcorrector_cs.yaml | 158 + .../nyaml/NXcs_computer.yaml | 124 + contributed_definitions/nyaml/NXcs_cpu.yaml | 54 + .../nyaml/NXcs_filter_boolean_mask.yaml | 172 + contributed_definitions/nyaml/NXcs_gpu.yaml | 54 + .../nyaml/NXcs_io_obj.yaml | 82 + .../nyaml/NXcs_io_sys.yaml | 46 + .../nyaml/NXcs_mm_sys.yaml | 55 + contributed_definitions/nyaml/NXcs_prng.yaml | 137 + .../nyaml/NXcs_profiling.yaml | 263 + .../nyaml/NXcs_profiling_event.yaml | 153 + contributed_definitions/nyaml/NXcsg.yaml | 119 + .../nyaml/NXcxi_ptycho.yaml | 440 ++ contributed_definitions/nyaml/NXdac.yaml | 53 + .../nyaml/NXdeflector.yaml | 143 + .../nyaml/NXdelocalization.yaml | 242 + .../nyaml/NXdispersion.yaml | 52 + .../nyaml/NXdispersion_function.yaml | 205 + .../NXdispersion_repeated_parameter.yaml | 99 + .../nyaml/NXdispersion_single_parameter.yaml | 61 + .../nyaml/NXdispersion_table.yaml | 140 + .../nyaml/NXdispersive_material.yaml | 409 ++ .../nyaml/NXdistortion.yaml | 177 + .../nyaml/NXebeam_column.yaml | 176 + .../nyaml/NXelectronanalyser.yaml | 257 + .../nyaml/NXelectrostatic_kicker.yaml | 105 + .../nyaml/NXellipsometry.yaml | 596 +++ contributed_definitions/nyaml/NXem.yaml | 4659 +++++++++++++++++ contributed_definitions/nyaml/NXem_ebsd.yaml | 3684 +++++++++++++ .../nyaml/NXem_ebsd_conventions.yaml | 940 ++++ .../NXem_ebsd_crystal_structure_model.yaml | 389 ++ .../nyaml/NXenergydispersion.yaml | 142 + .../nyaml/NXevent_data_em.yaml | 425 ++ .../nyaml/NXevent_data_em_set.yaml | 44 + .../nyaml/NXfabrication.yaml | 75 + contributed_definitions/nyaml/NXfiber.yaml | 358 ++ .../nyaml/NXgraph_edge_set.yaml | 191 + .../nyaml/NXgraph_node_set.yaml | 148 + .../nyaml/NXgraph_root.yaml | 51 + .../nyaml/NXibeam_column.yaml | 253 + .../nyaml/NXimage_set.yaml | 202 + .../nyaml/NXimage_set_em_adf.yaml | 257 + .../nyaml/NXimage_set_em_kikuchi.yaml | 362 ++ .../nyaml/NXinteraction_vol_em.yaml | 75 + contributed_definitions/nyaml/NXion.yaml | 289 + .../nyaml/NXisocontour.yaml | 101 + contributed_definitions/nyaml/NXiv_bias.yaml | 324 ++ contributed_definitions/nyaml/NXiv_temp.yaml | 164 + ..._electro_chemo_mechanical_preparation.yaml | 317 ++ .../nyaml/NXlab_sample_mounting.yaml | 151 + contributed_definitions/nyaml/NXlens_em.yaml | 175 + contributed_definitions/nyaml/NXlens_opt.yaml | 307 ++ contributed_definitions/nyaml/NXlockin.yaml | 252 + .../nyaml/NXmagnetic_kicker.yaml | 102 + .../nyaml/NXmanipulator.yaml | 161 + .../nyaml/NXmatch_filter.yaml | 95 + contributed_definitions/nyaml/NXmpes.yaml | 615 +++ contributed_definitions/nyaml/NXms.yaml | 993 ++++ .../nyaml/NXms_feature_set.yaml | 554 ++ .../nyaml/NXms_score_config.yaml | 777 +++ .../nyaml/NXms_score_results.yaml | 1335 +++++ .../nyaml/NXms_snapshot.yaml | 79 + .../nyaml/NXms_snapshot_set.yaml | 98 + contributed_definitions/nyaml/NXopt.yaml | 1502 ++++++ .../nyaml/NXoptical_system_em.yaml | 139 + .../nyaml/NXorientation_set.yaml | 228 + contributed_definitions/nyaml/NXpeak.yaml | 136 + .../nyaml/NXphysical_process.yaml | 92 + contributed_definitions/nyaml/NXpid.yaml | 151 + .../nyaml/NXpolarizer_opt.yaml | 411 ++ .../nyaml/NXpositioner_sts.yaml | 552 ++ contributed_definitions/nyaml/NXprogram.yaml | 76 + .../nyaml/NXpulser_apm.yaml | 281 + contributed_definitions/nyaml/NXpump.yaml | 60 + contributed_definitions/nyaml/NXquadric.yaml | 117 + .../nyaml/NXquadrupole_magnet.yaml | 84 + .../nyaml/NXreflectron.yaml | 87 + contributed_definitions/nyaml/NXregion.yaml | 340 ++ .../nyaml/NXregistration.yaml | 80 + .../nyaml/NXrotation_set.yaml | 461 ++ .../nyaml/NXsample_component_set.yaml | 123 + .../nyaml/NXsample_history.yaml | 108 + .../nyaml/NXscanbox_em.yaml | 83 + .../nyaml/NXsensor_scan.yaml | 335 ++ .../nyaml/NXsensor_sts.yaml | 384 ++ .../nyaml/NXseparator.yaml | 108 + .../nyaml/NXsimilarity_grouping.yaml | 290 + .../nyaml/NXsingle_crystal.yaml | 113 + .../nyaml/NXslip_system_set.yaml | 135 + contributed_definitions/nyaml/NXsnsevent.yaml | 640 +++ contributed_definitions/nyaml/NXsnshisto.yaml | 670 +++ .../nyaml/NXsolenoid_magnet.yaml | 84 + .../nyaml/NXsolid_geometry.yaml | 76 + .../nyaml/NXspatial_filter.yaml | 134 + .../nyaml/NXspectrum_set.yaml | 271 + .../nyaml/NXspectrum_set_em_eels.yaml | 315 ++ .../nyaml/NXspectrum_set_em_xray.yaml | 534 ++ .../nyaml/NXspin_rotator.yaml | 108 + .../nyaml/NXspindispersion.yaml | 154 + .../nyaml/NXstage_lab.yaml | 315 ++ contributed_definitions/nyaml/NXsts.yaml | 1747 ++++++ .../nyaml/NXsubsampling_filter.yaml | 71 + .../nyaml/NXsubstance.yaml | 193 + .../nyaml/NXtransmission.yaml | 607 +++ .../nyaml/NXunit_cell.yaml | 379 ++ .../nyaml/NXwaveplate.yaml | 286 + contributed_definitions/nyaml/NXxpcs.yaml | 1085 ++++ 267 files changed, 98226 insertions(+), 2 deletions(-) create mode 100644 .github/workflows/fairmat-nxdl-yaml-consistency.yaml create mode 100644 applications/nyaml/NXarchive.yaml create mode 100644 applications/nyaml/NXarpes.yaml create mode 100644 applications/nyaml/NXcanSAS.yaml create mode 100644 applications/nyaml/NXdirecttof.yaml create mode 100644 applications/nyaml/NXfluo.yaml create mode 100644 applications/nyaml/NXindirecttof.yaml create mode 100644 applications/nyaml/NXiqproc.yaml create mode 100644 applications/nyaml/NXlauetof.yaml create mode 100644 applications/nyaml/NXmonopd.yaml create mode 100644 applications/nyaml/NXmx.yaml create mode 100644 applications/nyaml/NXrefscan.yaml create mode 100644 applications/nyaml/NXreftof.yaml create mode 100644 applications/nyaml/NXsas.yaml create mode 100644 applications/nyaml/NXsastof.yaml create mode 100644 applications/nyaml/NXscan.yaml create mode 100644 applications/nyaml/NXspe.yaml create mode 100644 applications/nyaml/NXsqom.yaml create mode 100644 applications/nyaml/NXstxm.yaml create mode 100644 applications/nyaml/NXtas.yaml create mode 100644 applications/nyaml/NXtofnpd.yaml create mode 100644 applications/nyaml/NXtofraw.yaml create mode 100644 applications/nyaml/NXtofsingle.yaml create mode 100644 applications/nyaml/NXtomo.yaml create mode 100644 applications/nyaml/NXtomophase.yaml create mode 100644 applications/nyaml/NXtomoproc.yaml create mode 100644 applications/nyaml/NXxas.yaml create mode 100644 applications/nyaml/NXxasproc.yaml create mode 100644 applications/nyaml/NXxbase.yaml create mode 100644 applications/nyaml/NXxeuler.yaml create mode 100644 applications/nyaml/NXxkappa.yaml create mode 100644 applications/nyaml/NXxlaue.yaml create mode 100644 applications/nyaml/NXxlaueplate.yaml create mode 100644 applications/nyaml/NXxnb.yaml create mode 100644 applications/nyaml/NXxrot.yaml create mode 100644 base_classes/nyaml/NXaperture.yaml create mode 100644 base_classes/nyaml/NXattenuator.yaml create mode 100644 base_classes/nyaml/NXbeam.yaml create mode 100644 base_classes/nyaml/NXbeam_stop.yaml create mode 100644 base_classes/nyaml/NXbending_magnet.yaml create mode 100644 base_classes/nyaml/NXcapillary.yaml create mode 100644 base_classes/nyaml/NXcite.yaml create mode 100644 base_classes/nyaml/NXcollection.yaml create mode 100644 base_classes/nyaml/NXcollimator.yaml create mode 100644 base_classes/nyaml/NXcrystal.yaml create mode 100644 base_classes/nyaml/NXcylindrical_geometry.yaml create mode 100644 base_classes/nyaml/NXdata.yaml create mode 100644 base_classes/nyaml/NXdetector.yaml create mode 100644 base_classes/nyaml/NXdetector_group.yaml create mode 100644 base_classes/nyaml/NXdetector_module.yaml create mode 100644 base_classes/nyaml/NXdisk_chopper.yaml create mode 100644 base_classes/nyaml/NXentry.yaml create mode 100644 base_classes/nyaml/NXenvironment.yaml create mode 100644 base_classes/nyaml/NXevent_data.yaml create mode 100644 base_classes/nyaml/NXfermi_chopper.yaml create mode 100644 base_classes/nyaml/NXfilter.yaml create mode 100644 base_classes/nyaml/NXflipper.yaml create mode 100644 base_classes/nyaml/NXfresnel_zone_plate.yaml create mode 100644 base_classes/nyaml/NXgeometry.yaml create mode 100644 base_classes/nyaml/NXgrating.yaml create mode 100644 base_classes/nyaml/NXguide.yaml create mode 100644 base_classes/nyaml/NXinsertion_device.yaml create mode 100644 base_classes/nyaml/NXinstrument.yaml create mode 100644 base_classes/nyaml/NXlog.yaml create mode 100644 base_classes/nyaml/NXmirror.yaml create mode 100644 base_classes/nyaml/NXmoderator.yaml create mode 100644 base_classes/nyaml/NXmonitor.yaml create mode 100644 base_classes/nyaml/NXmonochromator.yaml create mode 100644 base_classes/nyaml/NXnote.yaml create mode 100644 base_classes/nyaml/NXobject.yaml create mode 100644 base_classes/nyaml/NXoff_geometry.yaml create mode 100644 base_classes/nyaml/NXorientation.yaml create mode 100644 base_classes/nyaml/NXparameters.yaml create mode 100644 base_classes/nyaml/NXpdb.yaml create mode 100644 base_classes/nyaml/NXpinhole.yaml create mode 100644 base_classes/nyaml/NXpolarizer.yaml create mode 100644 base_classes/nyaml/NXpositioner.yaml create mode 100644 base_classes/nyaml/NXprocess.yaml create mode 100644 base_classes/nyaml/NXreflections.yaml create mode 100644 base_classes/nyaml/NXroot.yaml create mode 100644 base_classes/nyaml/NXsample.yaml create mode 100644 base_classes/nyaml/NXsample_component.yaml create mode 100644 base_classes/nyaml/NXsensor.yaml create mode 100644 base_classes/nyaml/NXshape.yaml create mode 100644 base_classes/nyaml/NXslit.yaml create mode 100644 base_classes/nyaml/NXsource.yaml create mode 100644 base_classes/nyaml/NXsubentry.yaml create mode 100644 base_classes/nyaml/NXtransformations.yaml create mode 100644 base_classes/nyaml/NXtranslation.yaml create mode 100644 base_classes/nyaml/NXuser.yaml create mode 100644 base_classes/nyaml/NXvelocity_selector.yaml create mode 100644 base_classes/nyaml/NXxraylens.yaml create mode 100644 contributed_definitions/nyaml/NXaberration.yaml create mode 100644 contributed_definitions/nyaml/NXaberration_model.yaml create mode 100644 contributed_definitions/nyaml/NXaberration_model_ceos.yaml create mode 100644 contributed_definitions/nyaml/NXaberration_model_nion.yaml create mode 100644 contributed_definitions/nyaml/NXactivity.yaml create mode 100644 contributed_definitions/nyaml/NXadc.yaml create mode 100644 contributed_definitions/nyaml/NXamplifier.yaml create mode 100644 contributed_definitions/nyaml/NXaperture_em.yaml create mode 100644 contributed_definitions/nyaml/NXapm.yaml create mode 100644 contributed_definitions/nyaml/NXapm_composition_space_results.yaml create mode 100644 contributed_definitions/nyaml/NXapm_input_ranging.yaml create mode 100644 contributed_definitions/nyaml/NXapm_input_reconstruction.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_selector.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_selector.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.yaml create mode 100644 contributed_definitions/nyaml/NXbeam_path.yaml create mode 100644 contributed_definitions/nyaml/NXbeam_splitter.yaml create mode 100644 contributed_definitions/nyaml/NXbias_spectroscopy.yaml create mode 100644 contributed_definitions/nyaml/NXcalibration.yaml create mode 100644 contributed_definitions/nyaml/NXcg_alpha_complex.yaml create mode 100644 contributed_definitions/nyaml/NXcg_cylinder_set.yaml create mode 100644 contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml create mode 100644 contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml create mode 100644 contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml create mode 100644 contributed_definitions/nyaml/NXcg_grid.yaml create mode 100644 contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml create mode 100644 contributed_definitions/nyaml/NXcg_hexahedron_set.yaml create mode 100644 contributed_definitions/nyaml/NXcg_marching_cubes.yaml create mode 100644 contributed_definitions/nyaml/NXcg_parallelogram_set.yaml create mode 100644 contributed_definitions/nyaml/NXcg_point_set.yaml create mode 100644 contributed_definitions/nyaml/NXcg_polygon_set.yaml create mode 100644 contributed_definitions/nyaml/NXcg_polyhedron_set.yaml create mode 100644 contributed_definitions/nyaml/NXcg_polyline_set.yaml create mode 100644 contributed_definitions/nyaml/NXcg_roi_set.yaml create mode 100644 contributed_definitions/nyaml/NXcg_sphere_set.yaml create mode 100644 contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml create mode 100644 contributed_definitions/nyaml/NXcg_triangle_set.yaml create mode 100644 contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml create mode 100644 contributed_definitions/nyaml/NXcg_unit_normal_set.yaml create mode 100644 contributed_definitions/nyaml/NXchamber.yaml create mode 100644 contributed_definitions/nyaml/NXchemical_composition.yaml create mode 100644 contributed_definitions/nyaml/NXchemical_process.yaml create mode 100644 contributed_definitions/nyaml/NXcircuit.yaml create mode 100644 contributed_definitions/nyaml/NXcircuit_board.yaml create mode 100644 contributed_definitions/nyaml/NXclustering.yaml create mode 100644 contributed_definitions/nyaml/NXcollectioncolumn.yaml create mode 100644 contributed_definitions/nyaml/NXcontainer.yaml create mode 100644 contributed_definitions/nyaml/NXcoordinate_system_set.yaml create mode 100644 contributed_definitions/nyaml/NXcorrector_cs.yaml create mode 100644 contributed_definitions/nyaml/NXcs_computer.yaml create mode 100644 contributed_definitions/nyaml/NXcs_cpu.yaml create mode 100644 contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml create mode 100644 contributed_definitions/nyaml/NXcs_gpu.yaml create mode 100644 contributed_definitions/nyaml/NXcs_io_obj.yaml create mode 100644 contributed_definitions/nyaml/NXcs_io_sys.yaml create mode 100644 contributed_definitions/nyaml/NXcs_mm_sys.yaml create mode 100644 contributed_definitions/nyaml/NXcs_prng.yaml create mode 100644 contributed_definitions/nyaml/NXcs_profiling.yaml create mode 100644 contributed_definitions/nyaml/NXcs_profiling_event.yaml create mode 100644 contributed_definitions/nyaml/NXcsg.yaml create mode 100644 contributed_definitions/nyaml/NXcxi_ptycho.yaml create mode 100644 contributed_definitions/nyaml/NXdac.yaml create mode 100644 contributed_definitions/nyaml/NXdeflector.yaml create mode 100644 contributed_definitions/nyaml/NXdelocalization.yaml create mode 100644 contributed_definitions/nyaml/NXdispersion.yaml create mode 100644 contributed_definitions/nyaml/NXdispersion_function.yaml create mode 100644 contributed_definitions/nyaml/NXdispersion_repeated_parameter.yaml create mode 100644 contributed_definitions/nyaml/NXdispersion_single_parameter.yaml create mode 100644 contributed_definitions/nyaml/NXdispersion_table.yaml create mode 100644 contributed_definitions/nyaml/NXdispersive_material.yaml create mode 100644 contributed_definitions/nyaml/NXdistortion.yaml create mode 100644 contributed_definitions/nyaml/NXebeam_column.yaml create mode 100644 contributed_definitions/nyaml/NXelectronanalyser.yaml create mode 100644 contributed_definitions/nyaml/NXelectrostatic_kicker.yaml create mode 100644 contributed_definitions/nyaml/NXellipsometry.yaml create mode 100644 contributed_definitions/nyaml/NXem.yaml create mode 100644 contributed_definitions/nyaml/NXem_ebsd.yaml create mode 100644 contributed_definitions/nyaml/NXem_ebsd_conventions.yaml create mode 100644 contributed_definitions/nyaml/NXem_ebsd_crystal_structure_model.yaml create mode 100644 contributed_definitions/nyaml/NXenergydispersion.yaml create mode 100644 contributed_definitions/nyaml/NXevent_data_em.yaml create mode 100644 contributed_definitions/nyaml/NXevent_data_em_set.yaml create mode 100644 contributed_definitions/nyaml/NXfabrication.yaml create mode 100644 contributed_definitions/nyaml/NXfiber.yaml create mode 100644 contributed_definitions/nyaml/NXgraph_edge_set.yaml create mode 100644 contributed_definitions/nyaml/NXgraph_node_set.yaml create mode 100644 contributed_definitions/nyaml/NXgraph_root.yaml create mode 100644 contributed_definitions/nyaml/NXibeam_column.yaml create mode 100644 contributed_definitions/nyaml/NXimage_set.yaml create mode 100644 contributed_definitions/nyaml/NXimage_set_em_adf.yaml create mode 100644 contributed_definitions/nyaml/NXimage_set_em_kikuchi.yaml create mode 100644 contributed_definitions/nyaml/NXinteraction_vol_em.yaml create mode 100644 contributed_definitions/nyaml/NXion.yaml create mode 100644 contributed_definitions/nyaml/NXisocontour.yaml create mode 100644 contributed_definitions/nyaml/NXiv_bias.yaml create mode 100644 contributed_definitions/nyaml/NXiv_temp.yaml create mode 100644 contributed_definitions/nyaml/NXlab_electro_chemo_mechanical_preparation.yaml create mode 100644 contributed_definitions/nyaml/NXlab_sample_mounting.yaml create mode 100644 contributed_definitions/nyaml/NXlens_em.yaml create mode 100644 contributed_definitions/nyaml/NXlens_opt.yaml create mode 100644 contributed_definitions/nyaml/NXlockin.yaml create mode 100644 contributed_definitions/nyaml/NXmagnetic_kicker.yaml create mode 100644 contributed_definitions/nyaml/NXmanipulator.yaml create mode 100644 contributed_definitions/nyaml/NXmatch_filter.yaml create mode 100644 contributed_definitions/nyaml/NXmpes.yaml create mode 100644 contributed_definitions/nyaml/NXms.yaml create mode 100644 contributed_definitions/nyaml/NXms_feature_set.yaml create mode 100644 contributed_definitions/nyaml/NXms_score_config.yaml create mode 100644 contributed_definitions/nyaml/NXms_score_results.yaml create mode 100644 contributed_definitions/nyaml/NXms_snapshot.yaml create mode 100644 contributed_definitions/nyaml/NXms_snapshot_set.yaml create mode 100644 contributed_definitions/nyaml/NXopt.yaml create mode 100644 contributed_definitions/nyaml/NXoptical_system_em.yaml create mode 100644 contributed_definitions/nyaml/NXorientation_set.yaml create mode 100644 contributed_definitions/nyaml/NXpeak.yaml create mode 100644 contributed_definitions/nyaml/NXphysical_process.yaml create mode 100644 contributed_definitions/nyaml/NXpid.yaml create mode 100644 contributed_definitions/nyaml/NXpolarizer_opt.yaml create mode 100644 contributed_definitions/nyaml/NXpositioner_sts.yaml create mode 100644 contributed_definitions/nyaml/NXprogram.yaml create mode 100644 contributed_definitions/nyaml/NXpulser_apm.yaml create mode 100644 contributed_definitions/nyaml/NXpump.yaml create mode 100644 contributed_definitions/nyaml/NXquadric.yaml create mode 100644 contributed_definitions/nyaml/NXquadrupole_magnet.yaml create mode 100644 contributed_definitions/nyaml/NXreflectron.yaml create mode 100644 contributed_definitions/nyaml/NXregion.yaml create mode 100644 contributed_definitions/nyaml/NXregistration.yaml create mode 100644 contributed_definitions/nyaml/NXrotation_set.yaml create mode 100644 contributed_definitions/nyaml/NXsample_component_set.yaml create mode 100644 contributed_definitions/nyaml/NXsample_history.yaml create mode 100644 contributed_definitions/nyaml/NXscanbox_em.yaml create mode 100644 contributed_definitions/nyaml/NXsensor_scan.yaml create mode 100644 contributed_definitions/nyaml/NXsensor_sts.yaml create mode 100644 contributed_definitions/nyaml/NXseparator.yaml create mode 100644 contributed_definitions/nyaml/NXsimilarity_grouping.yaml create mode 100644 contributed_definitions/nyaml/NXsingle_crystal.yaml create mode 100644 contributed_definitions/nyaml/NXslip_system_set.yaml create mode 100644 contributed_definitions/nyaml/NXsnsevent.yaml create mode 100644 contributed_definitions/nyaml/NXsnshisto.yaml create mode 100644 contributed_definitions/nyaml/NXsolenoid_magnet.yaml create mode 100644 contributed_definitions/nyaml/NXsolid_geometry.yaml create mode 100644 contributed_definitions/nyaml/NXspatial_filter.yaml create mode 100644 contributed_definitions/nyaml/NXspectrum_set.yaml create mode 100644 contributed_definitions/nyaml/NXspectrum_set_em_eels.yaml create mode 100644 contributed_definitions/nyaml/NXspectrum_set_em_xray.yaml create mode 100644 contributed_definitions/nyaml/NXspin_rotator.yaml create mode 100644 contributed_definitions/nyaml/NXspindispersion.yaml create mode 100644 contributed_definitions/nyaml/NXstage_lab.yaml create mode 100644 contributed_definitions/nyaml/NXsts.yaml create mode 100644 contributed_definitions/nyaml/NXsubsampling_filter.yaml create mode 100644 contributed_definitions/nyaml/NXsubstance.yaml create mode 100644 contributed_definitions/nyaml/NXtransmission.yaml create mode 100644 contributed_definitions/nyaml/NXunit_cell.yaml create mode 100644 contributed_definitions/nyaml/NXwaveplate.yaml create mode 100644 contributed_definitions/nyaml/NXxpcs.yaml diff --git a/.github/workflows/fairmat-clean-pages.yaml b/.github/workflows/fairmat-clean-pages.yaml index b70bd52e14..c1cb6db0c5 100644 --- a/.github/workflows/fairmat-clean-pages.yaml +++ b/.github/workflows/fairmat-clean-pages.yaml @@ -16,9 +16,12 @@ jobs: fetch-depth: 0 - name: Remove branch directory run: rm -rf docs/${{ github.event.ref }} + - name: Get current date + id: date + run: echo "::set-output name=date::$(date +'%Y-%m-%d')" - name: Commit & Push changes uses: actions-js/push@master with: github_token: ${{ secrets.GITHUB_TOKEN }} branch: fairmat-docs - message: Fairmat docs cleanup ${date} \ No newline at end of file + message: Fairmat docs cleanup ${{ steps.date.outputs.date }} \ No newline at end of file diff --git a/.github/workflows/fairmat-nxdl-yaml-consistency.yaml b/.github/workflows/fairmat-nxdl-yaml-consistency.yaml new file mode 100644 index 0000000000..7c19584a82 --- /dev/null +++ b/.github/workflows/fairmat-nxdl-yaml-consistency.yaml @@ -0,0 +1,31 @@ +name: Check nxdl/yaml consistency + +on: + push: + branches: [fairmat] + pull_request: + branches: [fairmat] + +jobs: + check_nxdl: + runs-on: ubuntu-latest + steps: + - name: Set up Python 3.9 + uses: actions/setup-python@v4 + with: + python-version: "3.9" + - name: Checkout Repository + uses: actions/checkout@v2 + with: + fetch-depth: 0 + - name: install dependencies + run: pip install -r requirements.txt + - name: install package + run: pip install -e . + - name: make nxdls + run: make nxdl + - uses: CatChen/check-git-status-action@v1 + with: + fail-if-not-clean: true + request-changes-if-not-clean: false + push-if-not-clean: false \ No newline at end of file diff --git a/.gitignore b/.gitignore index a528d74a75..3fd234f70f 100644 --- a/.gitignore +++ b/.gitignore @@ -28,4 +28,6 @@ share/python-wheels/ *.egg-info/ .installed.cfg *.egg -MANIFEST \ No newline at end of file +MANIFEST + +*_parsed.yaml \ No newline at end of file diff --git a/applications/nyaml/NXarchive.yaml b/applications/nyaml/NXarchive.yaml new file mode 100644 index 0000000000..44246f4a25 --- /dev/null +++ b/applications/nyaml/NXarchive.yaml @@ -0,0 +1,281 @@ +category: application +doc: | + This is a definition for data to be archived by ICAT (http://www.icatproject.org/). + + .. text from the icatproject.org site + + the database (with supporting software) that provides an + interface to all ISIS experimental data and will provide + a mechanism to link all aspects of ISIS research from + proposal through to publication. +type: group +NXarchive(NXobject): + (NXentry)entry: + \@index: + title: + experiment_identifier(NX_CHAR): + doc: | + unique identifier for the experiment + experiment_description(NX_CHAR): + doc: | + Brief description of the experiment and its objectives + collection_identifier(NX_CHAR): + doc: | + ID of user or DAQ define group of data files + collection_description(NX_CHAR): + doc: | + Brief summary of the collection, including grouping criteria + entry_identifier(NX_CHAR): + doc: | + unique identifier for this measurement as provided by the facility + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + duration(NX_FLOAT): + unit: NX_TIME + doc: | + TODO: needs documentation + collection_time(NX_FLOAT): + unit: NX_TIME + doc: | + TODO: needs documentation + run_cycle(NX_CHAR): + doc: | + TODO: needs documentation + revision(NX_CHAR): + doc: | + revision ID of this file, may be after recalibration, reprocessing etc. + definition: + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXarchive] + program(NX_CHAR): + doc: | + The program and version used for generating this file + \@version: + release_date(NX_CHAR): + unit: NX_TIME + doc: | + when this file is to be released into PD + (NXuser)user: + name(NX_CHAR): + role(NX_CHAR): + doc: | + role of the user + facility_user_id(NX_CHAR): + doc: | + ID of the user in the facility burocracy database + (NXinstrument)instrument: + (NXsource): + type(NX_CHAR): + + # TODO: suggest changing from enumeration to suggested list + enumeration: [Spallation Neutron Source, Pulsed Reactor Neutron Source, Reactor Neutron Source, Synchrotron X-Ray Source, Pulsed Muon Source, Rotating Anode X-Ray, Fixed Tube X-Ray] + name: + probe: + enumeration: [neutron, x-ray, electron] + name(NX_CHAR): + description(NX_CHAR): + doc: | + Brief description of the instrument + (NXsample)sample: + name: + doc: | + Descriptive name of sample + sample_id(NX_CHAR): + doc: | + Unique database id of the sample + description(NX_CHAR): + type(NX_CHAR): + enumeration: [sample, sample+can, calibration sample, normalisation sample, simulated data, none, sample_environment] + chemical_formula(NX_CHAR): + doc: | + Chemical formula formatted according to CIF conventions + preparation_date(NX_CHAR): + unit: NX_TIME + situation(NX_CHAR): + doc: | + Description of the environment the sample is in: + air, vacuum, oxidizing atmosphere, dehydrated, etc. + temperature(NX_FLOAT): + unit: NX_TEMPERATURE + magnetic_field(NX_FLOAT): + unit: NX_CURRENT + electric_field(NX_FLOAT): + unit: NX_VOLTAGE + stress_field(NX_FLOAT): + unit: NX_UNITLESS + pressure(NX_FLOAT): + unit: NX_PRESSURE + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e5a85aff26bd71392bbe9cc8482e9067d971b4f1af39884f60db7dc0adfe811c +# +# +# +# +# +# This is a definition for data to be archived by ICAT (http://www.icatproject.org/). +# +# .. text from the icatproject.org site +# +# the database (with supporting software) that provides an +# interface to all ISIS experimental data and will provide +# a mechanism to link all aspects of ISIS research from +# proposal through to publication. +# +# +# +# +# +# unique identifier for the experiment +# +# +# Brief description of the experiment and its objectives +# +# +# ID of user or DAQ define group of data files +# +# +# Brief summary of the collection, including grouping criteria +# +# +# unique identifier for this measurement as provided by the facility +# +# +# +# +# TODO: needs documentation +# +# +# TODO: needs documentation +# +# +# TODO: needs documentation +# +# +# revision ID of this file, may be after recalibration, reprocessing etc. +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# The program and version used for generating this file +# +# +# when this file is to be released into PD +# +# +# +# role of the user +# +# ID of the user in the facility burocracy database +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Brief description of the instrument +# +# +# +# +# Descriptive name of sample +# +# +# Unique database id of the sample +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Chemical formula formatted according to CIF conventions +# +# +# +# +# Description of the environment the sample is in: +# air, vacuum, oxidizing atmosphere, dehydrated, etc. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXarpes.yaml b/applications/nyaml/NXarpes.yaml new file mode 100644 index 0000000000..746d91696f --- /dev/null +++ b/applications/nyaml/NXarpes.yaml @@ -0,0 +1,226 @@ +category: application +doc: | + This is an application definition for angular resolved photo electron spectroscopy. + + It has been drawn up with hemispherical electron analysers in mind. +type: group +NXarpes(NXobject): + (NXentry): + \@entry: + doc: | + NeXus convention is to use "entry1", "entry2", ... + for analysis software to locate each entry. + title(NX_CHAR): + start_time(NX_DATE_TIME): + definition: + doc: | + Official NeXus NXDL schema to which this file conforms. + enumeration: [NXarpes] + (NXinstrument): + (NXsource): + type(NX_CHAR): + name(NX_CHAR): + probe: + enumeration: [x-ray] + (NXmonochromator)monochromator: + energy(NX_NUMBER): + unit: NX_ENERGY + (NXdetector)analyser: + data(NX_NUMBER): + lens_mode(NX_CHAR): + doc: | + setting for the electron analyser lens + acquisition_mode: + enumeration: [swept, fixed] + entrance_slit_shape: + enumeration: [curved, straight] + entrance_slit_setting(NX_NUMBER): + unit: NX_ANY + doc: | + dial setting of the entrance slit + entrance_slit_size(NX_NUMBER): + unit: NX_LENGTH + doc: | + size of the entrance slit + pass_energy(NX_NUMBER): + unit: NX_ENERGY + doc: | + energy of the electrons on the mean path of the analyser + time_per_channel(NX_NUMBER): + unit: NX_TIME + doc: | + todo: define more clearly + angles(NX_NUMBER): + unit: NX_ANGLE + doc: | + Angular axis of the analyser data + which dimension the axis applies to is defined + using the normal NXdata methods. + energies(NX_NUMBER): + unit: NX_ENERGY + doc: | + Energy axis of the analyser data + which dimension the axis applies to is defined + using the normal NXdata methods. + sensor_size(NX_INT): + doc: | + number of raw active elements in each dimension + dimensions: + rank: 1 + dim: [[1, 2]] + region_origin(NX_INT): + doc: | + origin of rectangular region selected for readout + dimensions: + rank: 1 + dim: [[1, 2]] + region_size(NX_INT): + doc: | + size of rectangular region selected for readout + dimensions: + rank: 1 + dim: [[1, 2]] + (NXsample): + name(NX_CHAR): + doc: | + Descriptive name of sample + temperature(NX_NUMBER): + unit: NX_TEMPERATURE + (NXdata): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 31232b8eac61f1e491926e74795efc8930591197ca40ea19d78788a866e7c6bf +# +# +# +# +# +# This is an application definition for angular resolved photo electron spectroscopy. +# +# It has been drawn up with hemispherical electron analysers in mind. +# +# +# +# +# NeXus convention is to use "entry1", "entry2", ... +# for analysis software to locate each entry. +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# setting for the electron analyser lens +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# dial setting of the entrance slit +# +# +# size of the entrance slit +# +# +# energy of the electrons on the mean path of the analyser +# +# +# todo: define more clearly +# +# +# +# Angular axis of the analyser data +# which dimension the axis applies to is defined +# using the normal NXdata methods. +# +# +# +# +# Energy axis of the analyser data +# which dimension the axis applies to is defined +# using the normal NXdata methods. +# +# +# +# number of raw active elements in each dimension +# +# +# +# +# +# origin of rectangular region selected for readout +# +# +# +# +# +# size of rectangular region selected for readout +# +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# +# +# diff --git a/applications/nyaml/NXcanSAS.yaml b/applications/nyaml/NXcanSAS.yaml new file mode 100644 index 0000000000..27192a0ea4 --- /dev/null +++ b/applications/nyaml/NXcanSAS.yaml @@ -0,0 +1,2422 @@ +category: application +doc: | + Implementation of the canSAS standard to store reduced small-angle scattering data of any dimension. + + .. index:: canSAS + + For more details, see: + + * http://www.cansas.org/ + * http://www.cansas.org/formats/canSAS1d/1.1/doc/ + * http://cansas-org.github.io/canSAS2012/ + * https://github.com/canSAS-org/NXcanSAS_examples + + The minimum requirements for *reduced* small-angle scattering data + as described by canSAS are summarized in the following figure: + + .. _canSAS_2012_minimum: + + .. figure:: canSAS/2012-minimum.png + :width: 60% + + The minimum requirements for *reduced* small-angle scattering data. + (:download:`full image `) + See :ref:`below ` for the minimum required + information for a NeXus data file + written to the NXcanSAS specification. + + .. rubric:: Implementation of canSAS standard in NeXus + + This application definition is an implementation of the canSAS + standard for storing both one-dimensional and multi-dimensional + *reduced* small-angle scattering data. + + * NXcanSAS is for reduced SAS data and metadata to be stored together in one file. + * *Reduced* SAS data consists of :math:`I(\vec{Q})` or :math:`I(|\vec{Q}|)` + * External file links are not to be used for the reduced data. + * A good practice/practise is, at least, to include a reference to how the data was acquired and processed. Yet this is not a requirement. + * There is no need for NXcanSAS to refer to any raw data. + + The canSAS data format has a structure similar to NeXus, not identical. + To allow canSAS data to be expressed in NeXus, yet identifiable + by the canSAS standard, an additional group attribute ``canSAS_class`` + was introduced. Here is the mapping of some common groups. + + =============== ============ ========================== + group (*) NX_class canSAS_class + =============== ============ ========================== + sasentry NXentry SASentry + sasdata NXdata SASdata + sasdetector NXdetector SASdetector + sasinstrument NXinstrument SASinstrument + sasnote NXnote SASnote + sasprocess NXprocess SASprocess + sasprocessnote NXcollection SASprocessnote + sastransmission NXdata SAStransmission_spectrum + sassample NXsample SASsample + sassource NXsource SASsource + =============== ============ ========================== + + (*) The name of each group is a suggestion, + not a fixed requirement and is chosen as fits each data file. + See the section on defining + :ref:`NXDL group and field names `. + + Refer to the NeXus Coordinate System drawing (:ref:`Design-CoordinateSystem`) + for choice and direction of :math:`x`, :math:`y`, and :math:`z` axes. + + .. _NXcanSAS_minimum: + + .. rubric:: The minimum required information for a NeXus data file + written to the NXcanSAS specification. + + .. literalinclude:: canSAS/minimum-required.txt + :tab-width: 4 + :linenos: + :language: text + +# NOTE: +# This NXDL refers to several image files (.jpg, .png) in its documentation. +# All such related resources are stored in the related subdirectory: ./canSAS/ +# In general, for an NXDL file: NXsomenxdl.nxdl.xml +# all related resources should be stored in subdirectory: ./somenxdl/ +type: group +NXcanSAS(NXobject): + (NXentry): + \@default: + exists: optional + doc: | + .. index:: plotting + + Declares which :ref:`NXdata` group + contains the data to be shown by default. + It is needed to resolve ambiguity when more than one :ref:`NXdata` group exists. + The value is the name of the default :ref:`NXdata` group. + Usually, this will be the name of the first *SASdata* group. + doc: | + .. index:: NXcanSAS (applications); SASentry + + Place the canSAS ``SASentry`` group as a child of a NeXus ``NXentry`` group + (when data from multiple techniques are being stored) + or as a replacement for the ``NXentry`` group. + + Note: It is required for all numerical objects to provide + a *units* attribute that describes the engineering units. + Use the Unidata UDunits [#]_ specification + as this is compatible with various community standards. + + .. [#] The UDunits specification also includes instructions for derived units. + \@canSAS_class: + doc: | + Official canSAS group: **SASentry** + enumeration: [SASentry] + \@version: + doc: | + Describes the version of the canSAS standard used to write this data. + This must be a text (not numerical) representation. Such as:: + + @version="1.1" + enumeration: [1.1] + definition: + doc: | + Official NeXus NXDL schema to which this subentry conforms. + enumeration: [NXcanSAS] + + # ============================ + # SASdata + # ============================ + (NXdata): + doc: | + A *SASData* group contains a single reduced small-angle scattering data set + that can be represented as :math:`I(\vec{Q})` or :math:`I(|\vec{Q}|)`. + + *Q* can be either a vector (:math:`\vec{Q}`) or a vector magnitude (:math:`|\vec{Q}|`) + + The name of each *SASdata* group must be unique within a SASentry group. + Suggest using names such as ``sasdata01``. + + NOTE: For the first *SASdata* group, be sure to write the chosen name + into the `SASentry/@default` attribute, as in:: + + SASentry/@default="sasdata01" + + A *SASdata* group has several attributes: + + * I_axes + * Q_indices + * Mask_indices + + To indicate the dependency relationships of other varied parameters, + use attributes similar to ``@Mask_indices`` (such as ``@Temperature_indices`` + or ``@Pressure_indices``). + \@canSAS_class: + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SASdata` + enumeration: [SASdata] + + # attributes, see: http://www.cansas.org/formats/canSAS2012/1.0/doc/framework.html#terms + \@signal: + type: NX_CHAR + doc: | + Name of the default data field. + enumeration: + I: + doc: | + For canSAS **SASdata**, this is always "I". + \@I_axes: + doc: | + String array that defines the independent data fields used in + the default plot for all of the dimensions of the *signal* field + (the *signal* field is the field in this group that is named by + the ``signal`` attribute of this group). + One entry is provided for every dimension of the ``I`` data object. + Such as:: + + @I_axes="Temperature", "Time", "Pressure", "Q", "Q" + + Since there are five items in the list, the intensity field of this example + ``I`` must be a five-dimensional array (rank=5). + \@Q_indices: + type: NX_INT + doc: | + Integer or integer array that describes which indices + (of the :math:`I` data object) are used to + reference the ``Q`` data object. The items in this array + use zero-based indexing. Such as:: + + @Q_indices=1,3,4 + + which indicates that ``Q`` requires three indices + from the :math:`I` data object: one for time and + two for Q position. Thus, in this example, the + ``Q`` data is time-dependent: :math:`\vec{Q}(t)`. + \@mask: + type: NX_CHAR + doc: | + Name of the data mask field. + + .. see: https://github.com/nexusformat/definitions/issues/533 + + The data *mask* must have the same shape as the *data* field. + Positions in the mask correspond to positions in the *data* field. + The value of the mask field may be either a boolean array + where ``false`` means *no mask* and ``true`` means *mask* + or a more descriptive array as as defined in :ref:`NXdetector`. + \@Mask_indices: + exists: optional + doc: | + Integer or integer array that describes which indices + (of the :math:`I` data object) are used to + reference the ``Mask`` data object. The items in this + array use zero-based indexing. Such as:: + + @Mask_indices=3,4 + + which indicates that Q requires two indices + from the :math:`I` data object for Q position. + \@timestamp: + type: NX_DATE_TIME + exists: optional + doc: | + ISO-8601 time [#iso8601]_ + Q(NX_NUMBER): + unit: NX_PER_LENGTH + + # http://www.cansas.org/formats/canSAS2012/1.0/doc/basics.html#definition-of + doc: | + .. index:: NXcanSAS (applications); Q + + Array of :math:`Q` data to accompany :math:`I`. + + .. figure:: canSAS/Q-geometry.jpg + :width: 60% + + The :math:`\vec{Q}` geometry. + (:download:`full image `) + + :math:`Q` may be represented as either + the three-dimensional scattering vector :math:`\vec{Q}` + or the magnitude of the scattering vector, :math:`|\vec{Q}|`. + + .. math:: |\vec{Q}| = (4\pi/\lambda) sin(\theta) + + When we write :math:`Q`, we may refer to either or both of + :math:`|\vec{Q}|` + or :math:`\vec{Q}`, depending on the context. + \@units: + exists: optional + doc: | + Engineering units to use when expressing + :math:`Q` and related terms. + + Data expressed in other units will generate + a warning from validation software and may not + be processed by some analysis software packages. + enumeration: + 1/m: + 1/nm: + doc: | + preferred + 1/angstrom: + \@uncertainties: + exists: optional + doc: | + (optional: for numerical arrays) + + Names the dataset (in this SASdata group) that provides the + uncertainty to be used for data analysis. + The name of the dataset containing the :math:`Q` uncertainty + is flexible. The name must be unique in the *SASdata* group. + + .. comment + see: https://github.com/canSAS-org/canSAS2012/issues/7 + + Such as:: + + @uncertainties="Q_uncertainties" + + The *uncertainties* field will have the same *shape* (dimensions) + as the Q field. + + These values are the estimates of uncertainty of each Q. By default, + this will be interpreted to be the estimated standard deviation. + In special cases, when a standard deviation cannot possibly be used, + its value can specify another measure of distribution width. + + There may also be a subdirectory (optional) with constituent + components. + + .. note:: To report distribution in reported :math:`Q` values, + use the ``@resolutions`` attribute. It is possible for both + ``@resolutions`` and ``uncertainties`` to be reported. + \@resolutions: + type: NX_CHAR + exists: optional + doc: | + .. index:: NXcanSAS (applications); resolutions + + (optional: for numerical arrays) + + Names the dataset (in this SASdata group) containing the :math:`Q` resolution. + The name of the dataset containing the :math:`Q` resolution + is flexible. The name must be unique in the *SASdata* group. + + .. comment + see: https://github.com/canSAS-org/canSAS2012/issues/7 + + The *resolutions* field will have the same *shape* (dimensions) + as the Q field. + + Generally, this is the principal resolution of each :math:`Q`. + Names the data object (in this SASdata group) that provides the + :math:`Q` resolution to be used for data analysis. Such as:: + + @resolutions="Qdev" + + To specify two-dimensional resolution for slit-smearing geometry, + such as (*dQw*, *dQl*), use a string array, such as:: + + @resolutions="dQw", "dQl" + + There may also be a subdirectory (optional) with constituent + components. + + This pattern will demonstrate how to introduce further as-yet + unanticipated terms related to the data. + + .. comment + see: https://github.com/nexusformat/definitions/issues/492#issuecomment-262813907 + + By default, the values of the resolutions data object are assumed to be + one standard deviation of any function used to approximate the + resolution function. This equates to the width of the gaussian + distribution if a Gaussian is chosen. See the ``@resolutions_description`` + attribute. + + .. note:: To report uncertainty in reported :math:`Q` values, + use the ``@uncertainties`` attribute. It is possible for both + ``@resolutions`` and ``uncertainties`` to be reported. + \@resolutions_description: + type: NX_CHAR + exists: optional + doc: | + (optional) + Generally, this describes the :math:`Q` ``@resolutions`` data object. + By default, the value is assumed to be "Gaussian". These are + suggestions: + + * Gaussian + * Lorentzian + * Square : + note that the full width of the square would be ~2.9 times + the standard deviation specified in the vector + * Triangular + * Sawtooth-outward : vertical edge pointing to larger Q + * Sawtooth-inward vertical edge pointing to smaller Q + * Bin : range of values contributing + (for example, when 2-D detector data have been reduced + to a 1-D :math:`I(|Q|)` dataset) + + For other meanings, it may be necessary to provide further details + such as the function used to assess the resolution. + In such cases, use additional datasets or a :ref:`NXnote` subgroup + to include that detail. + I(NX_NUMBER): + + # http://www.cansas.org/formats/canSAS2012/1.0/doc/basics.html#definition-of-intensity + doc: | + .. index:: NXcanSAS (applications); I + + Array of intensity (:math:`I`) data. + + The intensity may be represented in one of these forms: + + **absolute units**: :math:`d\Sigma/d\Omega(Q)` + differential cross-section + per unit volume per unit solid angle (such as: 1/cm/sr or 1/m/sr) + + **absolute units**: :math:`d\sigma/d\Omega(Q)` + differential cross-section + per unit atom per unit solid angle (such as: cm^2 or m^2) + + **arbitrary units**: :math:`I(Q)` + usually a ratio of two detectors + but units are meaningless (such as: a.u. or counts) + + This presents a few problems + for analysis software to sort out when reading the data. + Fortunately, it is possible to analyze the *units* to determine which type of + intensity is being reported and make choices at the time the file is read. But this is + an area for consideration and possible improvement. + + One problem arises with software that automatically converts data into some canonical + units used by that software. The software should not convert units between these different + types of intensity indiscriminately. + + A second problem is that when arbitrary units are used, then the set of possible + analytical results is restricted. With such units, no meaningful volume fraction + or number density can be determined directly from :math:`I(Q)`. + + In some cases, it is possible to apply a factor to convert the arbitrary + units to an absolute scale. This should be considered as a possibility + of the analysis process. + + Where this documentation says *typical units*, it is possible that small-angle + data may be presented in other units and still be consistent with NeXus. + See the :ref:`design-units` section. + \@units: + exists: optional + doc: | + Engineering units to use when expressing + :math:`I` and intensity-related terms. + + Data expressed in other units (or missing a ``@units`` attribute) + will be treated as ``arbitrary`` by some software packages. + + For software using the UDUNITS-2 library, ``arbitrary`` will be + changed to ``unknown`` for handling with that library. + enumeration: + 1/m: + doc: | + includes m2/m3 and 1/m/sr + 1/cm: + doc: | + includes cm2/cm3 and 1/cm/sr + m2/g: + cm2/g: + arbitrary: + \@uncertainties: + exists: optional + doc: | + (optional: for numerical arrays) + + Names the dataset (in this SASdata group) that provides the + uncertainty of :math:`I` to be used for data analysis. + The name of the dataset containing the :math:`I` uncertainty + is flexible. The name must be unique in the *SASdata* group. + + .. comment + see: https://github.com/canSAS-org/canSAS2012/issues/7 + + Generally, this is the estimate of the uncertainty of each :math:`I`. + Typically the estimated standard deviation. + + *Idev* is the canonical name from the 1D standard. + The NXcanSAS standard allows for the name to be described using this attribute. + Such as:: + + @uncertainties="Idev" + \@scaling_factor: + exists: optional + doc: | + (optional) + Names the field (a.k.a. dataset) that contains a factor + to multiply ``I``. By default, this value is unity. + Should an uncertainty be associated with the scaling factor + field, the field containing that uncertainty would be + designated via the ``uncertainties`` attribute. + Such as:: + + I : NX_NUMBER + @uncertainties="Idev" : NX_CHAR + @scaling_factor="I_scaling" : NX_CHAR + Idev : NX_NUMBER + I_scaling : NX_NUMBER + @uncertainties="I_scaling_dev" : NX_CHAR + I_scaling_dev : NX_NUMBER + + The exact names for ``I_scaling`` and ``I_scaling_dev`` are not + defined by NXcanSAS. The user has the flexibility to use names + different than those shown in this example. + Idev(NX_NUMBER): + exists: ['min', '0'] + doc: | + .. index:: NXcanSAS (applications); Idev + + Estimated **uncertainty** (usually standard deviation) + in :math:`I`. Must have the same units as :math:`I`. + + When present, the name of this field is also + recorded in the *uncertainties* attribute of *I*, as in:: + + I/@uncertainties="Idev" + \@units: + exists: optional + doc: | + Engineering units to use when expressing + :math:`I` and intensity-related terms. + + Data expressed in other units (or missing a ``@units`` attribute) + will generate a warning from any validation process + and will be treated as ``arbitrary`` by some analysis software packages. + + For software using the UDUNITS-2 library, ``arbitrary`` will be + changed to ``unknown`` for handling with that library. + enumeration: + 1/m: + doc: | + includes m2/m3 and 1/m/sr + 1/cm: + doc: | + includes cm2/cm3 and 1/cm/sr + m2/g: + cm2/g: + arbitrary: + Qdev(NX_NUMBER): + unit: NX_PER_LENGTH + exists: ['min', '0'] + doc: | + .. index:: NXcanSAS (applications); Qdev + + Estimated :math:`Q` **resolution** (usually standard deviation). + Must have the same units as :math:`Q`. + + When present, the name of this field is also + recorded in the *resolutions* attribute of *Q*, + as in:: + + Q/@resolutions="Qdev" + + or:: + + Q/@resolutions="dQw", "dQl" + \@units: + exists: optional + doc: | + Engineering units to use when expressing + :math:`Q` and related terms. + + Data expressed in other units may not be processed by some + software packages. + enumeration: + 1/m: + 1/nm: + doc: | + preferred + 1/angstrom: + dQw(NX_NUMBER): + unit: NX_PER_LENGTH + exists: ['min', '0'] + doc: | + .. index:: NXcanSAS (applications); dQw + + :math:`Q` **resolution** along the axis of scanning + (the high-resolution *slit width* direction). + Useful for defining resolution data from + slit-smearing instruments such as Bonse-Hart geometry. + Must have the same units as :math:`Q`. + + When present, the name of this field is also + recorded in the *resolutions* attribute of *Q*, + as in:: + + Q/@resolutions="dQw", "dQl" + \@units: + exists: optional + doc: | + Engineering units to use when expressing + :math:`Q` and related terms. + + Data expressed in other units may not be processed by some + software packages. + enumeration: + 1/m: + 1/nm: + doc: | + preferred + 1/angstrom: + dQl(NX_NUMBER): + unit: NX_PER_LENGTH + exists: ['min', '0'] + doc: | + .. index:: NXcanSAS (applications); dQl + + :math:`Q` **resolution** perpendicular to the axis of scanning + (the low-resolution *slit length* direction). + Useful for defining resolution data from + slit-smearing instruments such as Bonse-Hart geometry. + Must have the same units as :math:`Q`. + + When present, the name of this field is also + recorded in the *resolutions* attribute of *Q*, + as in:: + + Q/@resolutions="dQw", "dQl" + \@units: + exists: optional + doc: | + Engineering units to use when expressing + :math:`Q` and related terms. + + Data expressed in other units may not be processed by some + software packages. + enumeration: + 1/m: + 1/nm: + doc: | + preferred + 1/angstrom: + Qmean(NX_NUMBER): + exists: ['min', '0'] + unit: NX_PER_LENGTH + doc: | + Mean value of :math:`Q` for this data point. + Useful when describing data that has been + binned from higher-resolution data. + + It is expected that ``Q`` is provided + and that both ``Q`` and ``Qmean`` will have the same units. + \@units: + exists: optional + doc: | + Engineering units to use when expressing + :math:`Q` and related terms. + + Data expressed in other units may not be processed by some + software packages. + enumeration: + 1/m: + 1/nm: + doc: | + preferred + 1/angstrom: + ShadowFactor: + exists: ['min', '0'] + unit: NX_DIMENSIONLESS + doc: | + A numerical factor applied to pixels affected by the beam stop penumbra. + Used in data files from NIST/NCNR instruments. + + See: J.G. Barker and J.S. Pedersen (1995) *J. Appl. Cryst.* **28**, 105-114. + + # optional items + title: + exists: ['min', '1', 'max', '1'] + doc: | + Title of this *SASentry*. + Make it so that you can recognize the data by its title. + Could be the name of the sample, + the name for the measured data, or something else representative. + run: + exists: ['min', '1', 'max', 'unbounded'] + nameType: any + doc: | + Run identification for this *SASentry*. + For many facilities, this is an integer, such as en experiment number. + Use multiple instances of ``run`` as needed, keeping + in mind that HDF5 requires unique names for all entities + in a group. + \@name: + exists: optional + doc: | + Optional string attribute to identify this particular *run*. + Could use this to associate (correlate) multiple *SASdata* elements with *run* elements. + (NXinstrument): + exists: ['min', '0'] + \@canSAS_class: + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SASinstrument` + enumeration: [SASinstrument] + doc: | + Description of the small-angle scattering instrument. + + Consider, carefully, the relevance to the SAS data analysis process + when adding subgroups in this **NXinstrument** group. Additional information + can be added but will likely be ignored by standardized data anlysis processes. + + The NeXus :ref:`NXbeam` base class may be added as a subgroup of this **NXinstrument** + group *or* as a subgroup of the **NXsample** group to describe properties of the beam at any + point downstream from the source. + + # =========== + # SASaperture + # =========== + (NXaperture): + exists: ['min', '0'] + doc: | + :ref:`NXaperture` is generic and limits the variation in data files. + + Possible NeXus base class alternatives are: :ref:`NXpinhole` or :ref:`NXslit`. + \@canSAS_class: + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SASaperture` + enumeration: [SASaperture] + shape: + doc: | + describe the type of aperture (pinhole, 4-blade slit, Soller slit, ...) + x_gap(NX_NUMBER): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + doc: | + opening along the :math:`x` axis + y_gap(NX_NUMBER): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + doc: | + opening along the :math:`y` axis + + # ============== + # SAScollimation + # ============== + (NXcollimator): + exists: ['min', '0'] + \@canSAS_class: + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SAScollimation` + enumeration: [SAScollimation] + doc: | + Description of a collimating element (defines the divergence of the beam) in the instrument. + + To document a slit, pinhole, or the beam, refer to the + documentation of the ``NXinstrument`` group above. + length(NX_NUMBER): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + doc: | + Amount/length of collimation inserted (as on a SANS instrument) + distance(NX_NUMBER): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + doc: | + Distance from this collimation element to the sample + + # SAScollimation + + # ============================ + # SASdetector + # ============================ + (NXdetector): + exists: ['min', '0'] + \@canSAS_class: + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SASdetector` + enumeration: [SASdetector] + doc: | + Description of a detector in the instrument. + name: + exists: ['max', '1'] + doc: | + Identifies the name of this detector + SDD(NX_NUMBER): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + doc: | + Distance between sample and detector. + + Note: In NXdetector, the ``distance`` field records the + distance to the previous component ... most often the sample. + This use is the same as ``SDD`` for most SAS + instruments but not all. For example, Bonse-Hart cameras + have one or more crystals between the sample and detector. + + We define here the field ``SDD`` to document without + ambiguity the distance between sample and detector. + slit_length(NX_NUMBER): + unit: NX_PER_LENGTH + exists: ['min', '0', 'max', '1'] + doc: | + Slit length of the instrument for this detector, + expressed in the same units as :math:`Q`. + x_position(NX_NUMBER): + exists: ['min', '0', 'max', '1'] + unit: NX_LENGTH + doc: | + Location of the detector in :math:`x` + y_position(NX_NUMBER): + exists: ['min', '0', 'max', '1'] + unit: NX_LENGTH + doc: | + Location of the detector in :math:`y` + roll(NX_NUMBER): + exists: ['min', '0', 'max', '1'] + unit: NX_ANGLE + doc: | + Rotation of the detector about the :math:`z` axis (roll) + pitch(NX_NUMBER): + exists: ['min', '0', 'max', '1'] + unit: NX_ANGLE + doc: | + Rotation of the detector about the :math:`x` axis (roll) + yaw(NX_NUMBER): + exists: ['min', '0', 'max', '1'] + unit: NX_ANGLE + doc: | + Rotation of the detector about the :math:`y` axis (yaw) + beam_center_x(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + doc: | + Position of the beam center on the detector. + + This is the x position where the direct beam would hit the detector plane. + This is a length and can be outside of the actual + detector. The length can be in physical units or pixels + as documented by the units attribute. The value can be any + real number (positive, zero, or negative). + beam_center_y(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + doc: | + Position of the beam center on the detector. + + This is the y position where the direct beam would hit the detector plane. + This is a length and can be outside of the actual + detector. The length can be in physical units or pixels + as documented by the units attribute. The value can be any + real number (positive, zero, or negative). + x_pixel_size(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + doc: | + Size of each detector pixel. If it is scalar all pixels are the same size + y_pixel_size(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + doc: | + Size of each detector pixel. If it is scalar all pixels are the same size + + # SASdetector + + # ============================ + # SASsource + # ============================ + (NXsource): + exists: ['min', '0'] + \@canSAS_class: + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SASsource` + enumeration: [SASsource] + doc: | + Description of the radiation source. + radiation: + exists: optional + deprecated: Use either (or both) ``probe`` or ``type`` fields from ``NXsource`` (issue #765) + doc: | + Name of the radiation used. + Note that this is **not** the name of the facility! + + This field contains a value from either the + ``probe`` or ``type`` fields in :ref:`NXsource`. Thus, + it is redundant with existing NeXus structure. + + # enumeration values from NXsource/type and NXsource/probe + enumeration: [Spallation Neutron Source, Pulsed Reactor Neutron Source, Reactor Neutron Source, Synchrotron X-ray Source, Pulsed Muon Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, Ion Source, UV Plasma Source, neutron, x-ray, muon, electron, ultraviolet, visible light, positron, proton] + beam_shape: + exists: ['min', '0', 'max', '1'] + doc: | + Text description of the shape of the beam (incident on the sample). + incident_wavelength(NX_NUMBER): + exists: ['min', '0', 'max', '1'] + unit: NX_WAVELENGTH + doc: | + wavelength (:math:`\lambda`) of radiation incident on the sample + wavelength_min(NX_NUMBER): + exists: ['min', '0', 'max', '1'] + unit: NX_WAVELENGTH + doc: | + Some facilities specify wavelength using a range. + This is the lowest wavelength in such a range. + wavelength_max(NX_NUMBER): + exists: ['min', '0', 'max', '1'] + unit: NX_WAVELENGTH + doc: | + Some facilities specify wavelength using a range. + This is the highest wavelength in such a range. + incident_wavelength_spread(NX_NUMBER): + exists: ['min', '0', 'max', '1'] + unit: NX_WAVELENGTH + doc: | + Some facilities specify wavelength using a range. + This is the width (FWHM) of such a range. + beam_size_x(NX_NUMBER): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + doc: | + Size of the incident beam along the x axis. + beam_size_y(NX_NUMBER): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + doc: | + Size of the incident beam along the y axis. + + # SASsource + + # SASinstrument + + # ============== + # SASsample + # ============== + (NXsample): + exists: ['min', '0'] + \@canSAS_class: + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SASsample` + enumeration: [SASsample] + doc: | + Description of the sample. + name: + exists: ['max', '1'] + doc: | + **ID**: Text string that identifies this sample. + thickness(NX_FLOAT): + exists: ['min', '0', 'max', '1'] + unit: NX_LENGTH + doc: | + Thickness of this sample + transmission(NX_NUMBER): + exists: ['min', '0', 'max', '1'] + unit: NX_DIMENSIONLESS + doc: | + Transmission (:math:`I/I_0`) of this sample. + There is no *units* attribute as this number is dimensionless. + + Note: the ability to store a transmission *spectrum*, + instead of a single value, is provided elsewhere in the structure, + in the *SAStransmission_spectrum* element. + temperature(NX_NUMBER): + exists: ['min', '0', 'max', '1'] + unit: NX_TEMPERATURE + doc: | + Temperature of this sample. + details: + exists: ['min', '0', 'max', 'unbounded'] + nameType: any + doc: | + Any additional sample details. + x_position(NX_NUMBER): + exists: ['min', '0', 'max', '1'] + unit: NX_LENGTH + doc: | + Location of the sample in :math:`x` + y_position(NX_NUMBER): + exists: ['min', '0', 'max', '1'] + unit: NX_LENGTH + doc: | + Location of the sample in :math:`y` + roll(NX_NUMBER): + exists: ['min', '0', 'max', '1'] + unit: NX_ANGLE + doc: | + Rotation of the sample about the :math:`z` axis (roll) + pitch(NX_NUMBER): + exists: ['min', '0', 'max', '1'] + unit: NX_ANGLE + doc: | + Rotation of the sample about the :math:`x` axis (roll) + yaw(NX_NUMBER): + exists: ['min', '0', 'max', '1'] + unit: NX_ANGLE + doc: | + Rotation of the sample about the :math:`y` axis (yaw) + + # NXsample + + # ============== + # SASprocess + # ============== + (NXprocess): + exists: ['min', '0', 'max', 'unbounded'] + \@canSAS_class: + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SASprocess` + enumeration: [SASprocess] + doc: | + Description of a processing or analysis step. + + Add additional fields as needed to describe value(s) of any + variable, parameter, or term related to the *SASprocess* step. + Be sure to include *units* attributes for all numerical fields. + name: + exists: ['min', '0', 'max', '1'] + doc: | + Optional name for this data processing or analysis step + date(NX_DATE_TIME): + exists: ['min', '0', 'max', '1'] + doc: | + Optional date for this data processing or analysis step. [#iso8601]_ + + + .. [#iso8601] ISO-8601 standard time representation. + + NeXus dates and times are reported in ISO-8601 + (e.g., ``yyyy-mm-ddThh:mm:ss``) + or modified ISO-8601 (e.g., ``yyyy-mm-dd hh:mm:ss``). + + See: http://www.w3.org/TR/NOTE-datetime + or http://en.wikipedia.org/wiki/ISO_8601 for more details. + description: + exists: ['min', '0', 'max', '1'] + doc: | + Optional description for this data processing or analysis step + term: + exists: ['min', '0', 'max', 'unbounded'] + nameType: any + doc: | + Specifies the value of a single variable, parameter, + or term (while defined here as a string, it could be a number) + related to the *SASprocess* step. + + Note: + The name *term* is not required, it could take any name, + as long as the name is unique within this group. + + # suggested at NIAC2014 + # Isn't this ALWAYS a possibility in any NeXus base class? + # Not needed to define this but it is a good suggestion for usage. + (NXnote): + exists: ['min', '0', 'max', 'unbounded'] + doc: | + Any additional notes or subprocessing steps will be documented here. + + An **NXnote** group can be added to any NeXus group at or below the + **NXentry** group. It is shown here as a suggestion of a good place + to *consider* its use. + (NXcollection): + exists: ['min', '0', 'max', 'unbounded'] + doc: | + Describes anything about *SASprocess* that is not already described. + + Any content not defined in the canSAS standard can be placed at this point. + + Note: + The name of this group is flexible, it could take any name, + as long as it is unique within the **NXprocess** group. + \@canSAS_class: + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SASprocessnote` + enumeration: [SASprocessnote] + + # SASprocessnote + + # SASprocess + + # ============== + # SASnote + # ============== + (NXcollection): + exists: ['min', '0', 'max', 'unbounded'] + \@canSAS_class: + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SASnote` + enumeration: [SASnote] + doc: | + Free form description of anything not covered by other elements. + + # ============================ + # SAStransmission_spectrum + # ============================ + TRANSMISSION_SPECTRUM(NXdata): + exists: ['min', '0'] + doc: | + The *SAStransmission_spectrum* element + + This describes certain data obtained from a variable-wavelength source + such as pulsed-neutron source. + + # requested to be in the 1D format by ISIS + \@canSAS_class: + doc: | + Official canSAS group: :index:`NXcanSAS (applications); SAStransmission_spectrum` + enumeration: [SAStransmission_spectrum] + \@signal: + type: NX_CHAR + doc: | + Name of the default data field. + enumeration: + T: + doc: | + For **SAStransmission_spectrum**, this is always "T". + \@T_axes: + enumeration: + T: + doc: | + the wavelengths field (as a dimension scale) corresponding to this transmission + \@name: + doc: | + Identify what type of spectrum is being described. + It is expected that this value will take either of these two values: + + ====== ============================================== + value meaning + ====== ============================================== + sample measurement with the sample and container + can measurement with just the container + ====== ============================================== + \@timestamp: + type: NX_DATE_TIME + exists: optional + doc: | + ISO-8601 time [#iso8601]_ + lambda(NX_NUMBER): + unit: NX_WAVELENGTH + doc: | + Wavelength of the radiation. + + This array is of the same shape as ``T`` and ``Tdev``. + T(NX_NUMBER): + unit: NX_DIMENSIONLESS + doc: | + Transmission values (:math:`I/I_0`) + as a function of wavelength. + + This array is of the same shape as ``lambda`` and ``Tdev``. + \@uncertainties: + doc: | + Names the dataset (in this SASdata group) that provides the + uncertainty of each transmission :math:`T` to be used for data analysis. + The name of the dataset containing the :math:`T` uncertainty + is expected to be ``Tdev``. + + .. comment + see: https://github.com/canSAS-org/canSAS2012/issues/7 + + Typically: + + @uncertainties="Tdev" + Tdev(NX_NUMBER): + unit: NX_DIMENSIONLESS + doc: | + .. index:: NXcanSAS (applications); Tdev + + Estimated uncertainty (usually standard deviation) + in :math:`T`. Must have the same units as :math:`T`. + + This is the field is named in the *uncertainties* attribute of *T*, as in:: + + T/@uncertainties="Tdev" + + This array is of the same shape as ``lambda`` and ``T``. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 0138726f10e2c6809b373544080966e4d3f5a78d2311b780dcabd6ceeea535fa +# +# +# +# +# +# +# +# +# Implementation of the canSAS standard to store reduced small-angle scattering data of any dimension. +# +# .. index:: canSAS +# +# For more details, see: +# +# * http://www.cansas.org/ +# * http://www.cansas.org/formats/canSAS1d/1.1/doc/ +# * http://cansas-org.github.io/canSAS2012/ +# * https://github.com/canSAS-org/NXcanSAS_examples +# +# The minimum requirements for *reduced* small-angle scattering data +# as described by canSAS are summarized in the following figure: +# +# .. _canSAS_2012_minimum: +# +# .. figure:: canSAS/2012-minimum.png +# :width: 60% +# +# The minimum requirements for *reduced* small-angle scattering data. +# (:download:`full image <canSAS/2012-minimum.png>`) +# See :ref:`below <NXcanSAS_minimum>` for the minimum required +# information for a NeXus data file +# written to the NXcanSAS specification. +# +# .. rubric:: Implementation of canSAS standard in NeXus +# +# This application definition is an implementation of the canSAS +# standard for storing both one-dimensional and multi-dimensional +# *reduced* small-angle scattering data. +# +# * NXcanSAS is for reduced SAS data and metadata to be stored together in one file. +# * *Reduced* SAS data consists of :math:`I(\vec{Q})` or :math:`I(|\vec{Q}|)` +# * External file links are not to be used for the reduced data. +# * A good practice/practise is, at least, to include a reference to how the data was acquired and processed. Yet this is not a requirement. +# * There is no need for NXcanSAS to refer to any raw data. +# +# The canSAS data format has a structure similar to NeXus, not identical. +# To allow canSAS data to be expressed in NeXus, yet identifiable +# by the canSAS standard, an additional group attribute ``canSAS_class`` +# was introduced. Here is the mapping of some common groups. +# +# =============== ============ ========================== +# group (*) NX_class canSAS_class +# =============== ============ ========================== +# sasentry NXentry SASentry +# sasdata NXdata SASdata +# sasdetector NXdetector SASdetector +# sasinstrument NXinstrument SASinstrument +# sasnote NXnote SASnote +# sasprocess NXprocess SASprocess +# sasprocessnote NXcollection SASprocessnote +# sastransmission NXdata SAStransmission_spectrum +# sassample NXsample SASsample +# sassource NXsource SASsource +# =============== ============ ========================== +# +# (*) The name of each group is a suggestion, +# not a fixed requirement and is chosen as fits each data file. +# See the section on defining +# :ref:`NXDL group and field names <RegExpName>`. +# +# Refer to the NeXus Coordinate System drawing (:ref:`Design-CoordinateSystem`) +# for choice and direction of :math:`x`, :math:`y`, and :math:`z` axes. +# +# .. _NXcanSAS_minimum: +# +# .. rubric:: The minimum required information for a NeXus data file +# written to the NXcanSAS specification. +# +# .. literalinclude:: canSAS/minimum-required.txt +# :tab-width: 4 +# :linenos: +# :language: text +# +# +# +# +# +# +# .. index:: plotting +# +# Declares which :ref:`NXdata` group +# contains the data to be shown by default. +# It is needed to resolve ambiguity when more than one :ref:`NXdata` group exists. +# The value is the name of the default :ref:`NXdata` group. +# Usually, this will be the name of the first *SASdata* group. +# +# +# +# .. index:: NXcanSAS (applications); SASentry +# +# Place the canSAS ``SASentry`` group as a child of a NeXus ``NXentry`` group +# (when data from multiple techniques are being stored) +# or as a replacement for the ``NXentry`` group. +# +# Note: It is required for all numerical objects to provide +# a *units* attribute that describes the engineering units. +# Use the Unidata UDunits [#]_ specification +# as this is compatible with various community standards. +# +# .. [#] The UDunits specification also includes instructions for derived units. +# +# +# +# Official canSAS group: **SASentry** +# +# +# +# +# +# +# +# Describes the version of the canSAS standard used to write this data. +# This must be a text (not numerical) representation. Such as:: +# +# @version="1.1" +# +# +# +# +# +# +# +# +# Official NeXus NXDL schema to which this subentry conforms. +# +# +# +# +# +# +# +# +# +# A *SASData* group contains a single reduced small-angle scattering data set +# that can be represented as :math:`I(\vec{Q})` or :math:`I(|\vec{Q}|)`. +# +# *Q* can be either a vector (:math:`\vec{Q}`) or a vector magnitude (:math:`|\vec{Q}|`) +# +# The name of each *SASdata* group must be unique within a SASentry group. +# Suggest using names such as ``sasdata01``. +# +# NOTE: For the first *SASdata* group, be sure to write the chosen name +# into the `SASentry/@default` attribute, as in:: +# +# SASentry/@default="sasdata01" +# +# A *SASdata* group has several attributes: +# +# * I_axes +# * Q_indices +# * Mask_indices +# +# To indicate the dependency relationships of other varied parameters, +# use attributes similar to ``@Mask_indices`` (such as ``@Temperature_indices`` +# or ``@Pressure_indices``). +# +# +# Official canSAS group: :index:`NXcanSAS (applications); SASdata` +# +# +# +# +# +# +# +# Name of the default data field. +# +# +# For canSAS **SASdata**, this is always "I". +# +# +# +# +# String array that defines the independent data fields used in +# the default plot for all of the dimensions of the *signal* field +# (the *signal* field is the field in this group that is named by +# the ``signal`` attribute of this group). +# One entry is provided for every dimension of the ``I`` data object. +# Such as:: +# +# @I_axes="Temperature", "Time", "Pressure", "Q", "Q" +# +# Since there are five items in the list, the intensity field of this example +# ``I`` must be a five-dimensional array (rank=5). +# +# +# +# +# +# Integer or integer array that describes which indices +# (of the :math:`I` data object) are used to +# reference the ``Q`` data object. The items in this array +# use zero-based indexing. Such as:: +# +# @Q_indices=1,3,4 +# +# which indicates that ``Q`` requires three indices +# from the :math:`I` data object: one for time and +# two for Q position. Thus, in this example, the +# ``Q`` data is time-dependent: :math:`\vec{Q}(t)`. +# +# +# +# +# Name of the data mask field. +# +# .. see: https://github.com/nexusformat/definitions/issues/533 +# +# The data *mask* must have the same shape as the *data* field. +# Positions in the mask correspond to positions in the *data* field. +# The value of the mask field may be either a boolean array +# where ``false`` means *no mask* and ``true`` means *mask* +# or a more descriptive array as as defined in :ref:`NXdetector`. +# +# +# +# +# Integer or integer array that describes which indices +# (of the :math:`I` data object) are used to +# reference the ``Mask`` data object. The items in this +# array use zero-based indexing. Such as:: +# +# @Mask_indices=3,4 +# +# which indicates that Q requires two indices +# from the :math:`I` data object for Q position. +# +# +# +# +# ISO-8601 time [#iso8601]_ +# +# +# +# +# +# +# .. index:: NXcanSAS (applications); Q +# +# Array of :math:`Q` data to accompany :math:`I`. +# +# .. figure:: canSAS/Q-geometry.jpg +# :width: 60% +# +# The :math:`\vec{Q}` geometry. +# (:download:`full image <canSAS/Q-geometry.jpg>`) +# +# :math:`Q` may be represented as either +# the three-dimensional scattering vector :math:`\vec{Q}` +# or the magnitude of the scattering vector, :math:`|\vec{Q}|`. +# +# .. math:: |\vec{Q}| = (4\pi/\lambda) sin(\theta) +# +# When we write :math:`Q`, we may refer to either or both of +# :math:`|\vec{Q}|` +# or :math:`\vec{Q}`, depending on the context. +# +# +# +# Engineering units to use when expressing +# :math:`Q` and related terms. +# +# Data expressed in other units will generate +# a warning from validation software and may not +# be processed by some analysis software packages. +# +# +# +# +# preferred +# +# +# +# +# +# +# (optional: for numerical arrays) +# +# Names the dataset (in this SASdata group) that provides the +# uncertainty to be used for data analysis. +# The name of the dataset containing the :math:`Q` uncertainty +# is flexible. The name must be unique in the *SASdata* group. +# +# .. comment +# see: https://github.com/canSAS-org/canSAS2012/issues/7 +# +# Such as:: +# +# @uncertainties="Q_uncertainties" +# +# The *uncertainties* field will have the same *shape* (dimensions) +# as the Q field. +# +# These values are the estimates of uncertainty of each Q. By default, +# this will be interpreted to be the estimated standard deviation. +# In special cases, when a standard deviation cannot possibly be used, +# its value can specify another measure of distribution width. +# +# There may also be a subdirectory (optional) with constituent +# components. +# +# .. note:: To report distribution in reported :math:`Q` values, +# use the ``@resolutions`` attribute. It is possible for both +# ``@resolutions`` and ``uncertainties`` to be reported. +# +# +# +# +# +# .. index:: NXcanSAS (applications); resolutions +# +# (optional: for numerical arrays) +# +# Names the dataset (in this SASdata group) containing the :math:`Q` resolution. +# The name of the dataset containing the :math:`Q` resolution +# is flexible. The name must be unique in the *SASdata* group. +# +# .. comment +# see: https://github.com/canSAS-org/canSAS2012/issues/7 +# +# The *resolutions* field will have the same *shape* (dimensions) +# as the Q field. +# +# Generally, this is the principal resolution of each :math:`Q`. +# Names the data object (in this SASdata group) that provides the +# :math:`Q` resolution to be used for data analysis. Such as:: +# +# @resolutions="Qdev" +# +# To specify two-dimensional resolution for slit-smearing geometry, +# such as (*dQw*, *dQl*), use a string array, such as:: +# +# @resolutions="dQw", "dQl" +# +# There may also be a subdirectory (optional) with constituent +# components. +# +# This pattern will demonstrate how to introduce further as-yet +# unanticipated terms related to the data. +# +# .. comment +# see: https://github.com/nexusformat/definitions/issues/492#issuecomment-262813907 +# +# By default, the values of the resolutions data object are assumed to be +# one standard deviation of any function used to approximate the +# resolution function. This equates to the width of the gaussian +# distribution if a Gaussian is chosen. See the ``@resolutions_description`` +# attribute. +# +# .. note:: To report uncertainty in reported :math:`Q` values, +# use the ``@uncertainties`` attribute. It is possible for both +# ``@resolutions`` and ``uncertainties`` to be reported. +# +# +# +# +# +# (optional) +# Generally, this describes the :math:`Q` ``@resolutions`` data object. +# By default, the value is assumed to be "Gaussian". These are +# suggestions: +# +# * Gaussian +# * Lorentzian +# * Square : +# note that the full width of the square would be ~2.9 times +# the standard deviation specified in the vector +# * Triangular +# * Sawtooth-outward : vertical edge pointing to larger Q +# * Sawtooth-inward vertical edge pointing to smaller Q +# * Bin : range of values contributing +# (for example, when 2-D detector data have been reduced +# to a 1-D :math:`I(|Q|)` dataset) +# +# For other meanings, it may be necessary to provide further details +# such as the function used to assess the resolution. +# In such cases, use additional datasets or a :ref:`NXnote` subgroup +# to include that detail. +# +# +# +# +# +# +# .. index:: NXcanSAS (applications); I +# +# Array of intensity (:math:`I`) data. +# +# The intensity may be represented in one of these forms: +# +# **absolute units**: :math:`d\Sigma/d\Omega(Q)` +# differential cross-section +# per unit volume per unit solid angle (such as: 1/cm/sr or 1/m/sr) +# +# **absolute units**: :math:`d\sigma/d\Omega(Q)` +# differential cross-section +# per unit atom per unit solid angle (such as: cm^2 or m^2) +# +# **arbitrary units**: :math:`I(Q)` +# usually a ratio of two detectors +# but units are meaningless (such as: a.u. or counts) +# +# This presents a few problems +# for analysis software to sort out when reading the data. +# Fortunately, it is possible to analyze the *units* to determine which type of +# intensity is being reported and make choices at the time the file is read. But this is +# an area for consideration and possible improvement. +# +# One problem arises with software that automatically converts data into some canonical +# units used by that software. The software should not convert units between these different +# types of intensity indiscriminately. +# +# A second problem is that when arbitrary units are used, then the set of possible +# analytical results is restricted. With such units, no meaningful volume fraction +# or number density can be determined directly from :math:`I(Q)`. +# +# In some cases, it is possible to apply a factor to convert the arbitrary +# units to an absolute scale. This should be considered as a possibility +# of the analysis process. +# +# Where this documentation says *typical units*, it is possible that small-angle +# data may be presented in other units and still be consistent with NeXus. +# See the :ref:`design-units` section. +# +# +# +# Engineering units to use when expressing +# :math:`I` and intensity-related terms. +# +# Data expressed in other units (or missing a ``@units`` attribute) +# will be treated as ``arbitrary`` by some software packages. +# +# For software using the UDUNITS-2 library, ``arbitrary`` will be +# changed to ``unknown`` for handling with that library. +# +# +# +# includes m2/m3 and 1/m/sr +# +# +# includes cm2/cm3 and 1/cm/sr +# +# +# +# +# +# +# +# +# (optional: for numerical arrays) +# +# Names the dataset (in this SASdata group) that provides the +# uncertainty of :math:`I` to be used for data analysis. +# The name of the dataset containing the :math:`I` uncertainty +# is flexible. The name must be unique in the *SASdata* group. +# +# .. comment +# see: https://github.com/canSAS-org/canSAS2012/issues/7 +# +# Generally, this is the estimate of the uncertainty of each :math:`I`. +# Typically the estimated standard deviation. +# +# *Idev* is the canonical name from the 1D standard. +# The NXcanSAS standard allows for the name to be described using this attribute. +# Such as:: +# +# @uncertainties="Idev" +# +# +# +# +# +# (optional) +# Names the field (a.k.a. dataset) that contains a factor +# to multiply ``I``. By default, this value is unity. +# Should an uncertainty be associated with the scaling factor +# field, the field containing that uncertainty would be +# designated via the ``uncertainties`` attribute. +# Such as:: +# +# I : NX_NUMBER +# @uncertainties="Idev" : NX_CHAR +# @scaling_factor="I_scaling" : NX_CHAR +# Idev : NX_NUMBER +# I_scaling : NX_NUMBER +# @uncertainties="I_scaling_dev" : NX_CHAR +# I_scaling_dev : NX_NUMBER +# +# The exact names for ``I_scaling`` and ``I_scaling_dev`` are not +# defined by NXcanSAS. The user has the flexibility to use names +# different than those shown in this example. +# +# +# +# +# +# +# .. index:: NXcanSAS (applications); Idev +# +# Estimated **uncertainty** (usually standard deviation) +# in :math:`I`. Must have the same units as :math:`I`. +# +# When present, the name of this field is also +# recorded in the *uncertainties* attribute of *I*, as in:: +# +# I/@uncertainties="Idev" +# +# +# +# +# Engineering units to use when expressing +# :math:`I` and intensity-related terms. +# +# Data expressed in other units (or missing a ``@units`` attribute) +# will generate a warning from any validation process +# and will be treated as ``arbitrary`` by some analysis software packages. +# +# For software using the UDUNITS-2 library, ``arbitrary`` will be +# changed to ``unknown`` for handling with that library. +# +# +# +# includes m2/m3 and 1/m/sr +# +# +# includes cm2/cm3 and 1/cm/sr +# +# +# +# +# +# +# +# +# +# +# .. index:: NXcanSAS (applications); Qdev +# +# Estimated :math:`Q` **resolution** (usually standard deviation). +# Must have the same units as :math:`Q`. +# +# When present, the name of this field is also +# recorded in the *resolutions* attribute of *Q*, +# as in:: +# +# Q/@resolutions="Qdev" +# +# or:: +# +# Q/@resolutions="dQw", "dQl" +# +# +# +# +# Engineering units to use when expressing +# :math:`Q` and related terms. +# +# Data expressed in other units may not be processed by some +# software packages. +# +# +# +# +# preferred +# +# +# +# +# +# +# +# +# .. index:: NXcanSAS (applications); dQw +# +# :math:`Q` **resolution** along the axis of scanning +# (the high-resolution *slit width* direction). +# Useful for defining resolution data from +# slit-smearing instruments such as Bonse-Hart geometry. +# Must have the same units as :math:`Q`. +# +# When present, the name of this field is also +# recorded in the *resolutions* attribute of *Q*, +# as in:: +# +# Q/@resolutions="dQw", "dQl" +# +# +# +# +# Engineering units to use when expressing +# :math:`Q` and related terms. +# +# Data expressed in other units may not be processed by some +# software packages. +# +# +# +# +# preferred +# +# +# +# +# +# +# +# +# .. index:: NXcanSAS (applications); dQl +# +# :math:`Q` **resolution** perpendicular to the axis of scanning +# (the low-resolution *slit length* direction). +# Useful for defining resolution data from +# slit-smearing instruments such as Bonse-Hart geometry. +# Must have the same units as :math:`Q`. +# +# When present, the name of this field is also +# recorded in the *resolutions* attribute of *Q*, +# as in:: +# +# Q/@resolutions="dQw", "dQl" +# +# +# +# +# Engineering units to use when expressing +# :math:`Q` and related terms. +# +# Data expressed in other units may not be processed by some +# software packages. +# +# +# +# +# preferred +# +# +# +# +# +# +# +# +# Mean value of :math:`Q` for this data point. +# Useful when describing data that has been +# binned from higher-resolution data. +# +# It is expected that ``Q`` is provided +# and that both ``Q`` and ``Qmean`` will have the same units. +# +# +# +# Engineering units to use when expressing +# :math:`Q` and related terms. +# +# Data expressed in other units may not be processed by some +# software packages. +# +# +# +# +# preferred +# +# +# +# +# +# +# +# A numerical factor applied to pixels affected by the beam stop penumbra. +# Used in data files from NIST/NCNR instruments. +# +# See: J.G. Barker and J.S. Pedersen (1995) *J. Appl. Cryst.* **28**, 105-114. +# +# +# +# +# +# +# +# +# Title of this *SASentry*. +# Make it so that you can recognize the data by its title. +# Could be the name of the sample, +# the name for the measured data, or something else representative. +# +# +# +# +# Run identification for this *SASentry*. +# For many facilities, this is an integer, such as en experiment number. +# Use multiple instances of ``run`` as needed, keeping +# in mind that HDF5 requires unique names for all entities +# in a group. +# +# +# +# Optional string attribute to identify this particular *run*. +# Could use this to associate (correlate) multiple *SASdata* elements with *run* elements. +# +# +# +# +# +# +# Official canSAS group: :index:`NXcanSAS (applications); SASinstrument` +# +# +# +# +# +# Description of the small-angle scattering instrument. +# +# Consider, carefully, the relevance to the SAS data analysis process +# when adding subgroups in this **NXinstrument** group. Additional information +# can be added but will likely be ignored by standardized data anlysis processes. +# +# The NeXus :ref:`NXbeam` base class may be added as a subgroup of this **NXinstrument** +# group *or* as a subgroup of the **NXsample** group to describe properties of the beam at any +# point downstream from the source. +# +# +# +# +# +# +# :ref:`NXaperture` is generic and limits the variation in data files. +# +# Possible NeXus base class alternatives are: :ref:`NXpinhole` or :ref:`NXslit`. +# +# +# Official canSAS group: :index:`NXcanSAS (applications); SASaperture` +# +# +# +# +# +# +# +# describe the type of aperture (pinhole, 4-blade slit, Soller slit, ...) +# +# +# +# opening along the :math:`x` axis +# +# +# opening along the :math:`y` axis +# +# +# +# +# +# +# Official canSAS group: :index:`NXcanSAS (applications); SAScollimation` +# +# +# +# +# +# Description of a collimating element (defines the divergence of the beam) in the instrument. +# +# To document a slit, pinhole, or the beam, refer to the +# documentation of the ``NXinstrument`` group above. +# +# +# +# Amount/length of collimation inserted (as on a SANS instrument) +# +# +# +# Distance from this collimation element to the sample +# +# +# +# +# +# +# +# +# +# +# Official canSAS group: :index:`NXcanSAS (applications); SASdetector` +# +# +# +# +# +# Description of a detector in the instrument. +# +# +# +# Identifies the name of this detector +# +# +# +# Distance between sample and detector. +# +# Note: In NXdetector, the ``distance`` field records the +# distance to the previous component ... most often the sample. +# This use is the same as ``SDD`` for most SAS +# instruments but not all. For example, Bonse-Hart cameras +# have one or more crystals between the sample and detector. +# +# We define here the field ``SDD`` to document without +# ambiguity the distance between sample and detector. +# +# +# +# +# Slit length of the instrument for this detector, +# expressed in the same units as :math:`Q`. +# +# +# +# +# Location of the detector in :math:`x` +# +# +# Location of the detector in :math:`y` +# +# +# Rotation of the detector about the :math:`z` axis (roll) +# +# +# Rotation of the detector about the :math:`x` axis (roll) +# +# +# Rotation of the detector about the :math:`y` axis (yaw) +# +# +# +# +# Position of the beam center on the detector. +# +# This is the x position where the direct beam would hit the detector plane. +# This is a length and can be outside of the actual +# detector. The length can be in physical units or pixels +# as documented by the units attribute. The value can be any +# real number (positive, zero, or negative). +# +# +# +# +# +# Position of the beam center on the detector. +# +# This is the y position where the direct beam would hit the detector plane. +# This is a length and can be outside of the actual +# detector. The length can be in physical units or pixels +# as documented by the units attribute. The value can be any +# real number (positive, zero, or negative). +# +# +# +# +# Size of each detector pixel. If it is scalar all pixels are the same size +# +# +# +# Size of each detector pixel. If it is scalar all pixels are the same size +# +# +# +# +# +# +# +# +# +# Official canSAS group: :index:`NXcanSAS (applications); SASsource` +# +# +# +# +# +# Description of the radiation source. +# +# +# +# +# Name of the radiation used. +# Note that this is **not** the name of the facility! +# +# This field contains a value from either the +# ``probe`` or ``type`` fields in :ref:`NXsource`. Thus, +# it is redundant with existing NeXus structure. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Text description of the shape of the beam (incident on the sample). +# +# +# wavelength (:math:`\lambda`) of radiation incident on the sample +# +# +# +# Some facilities specify wavelength using a range. +# This is the lowest wavelength in such a range. +# +# +# +# +# Some facilities specify wavelength using a range. +# This is the highest wavelength in such a range. +# +# +# +# +# Some facilities specify wavelength using a range. +# This is the width (FWHM) of such a range. +# +# +# +# Size of the incident beam along the x axis. +# +# +# Size of the incident beam along the y axis. +# +# +# +# +# +# +# +# +# +# +# +# +# Official canSAS group: :index:`NXcanSAS (applications); SASsample` +# +# +# +# +# +# Description of the sample. +# +# +# +# **ID**: Text string that identifies this sample. +# +# +# Thickness of this sample +# +# +# +# Transmission (:math:`I/I_0`) of this sample. +# There is no *units* attribute as this number is dimensionless. +# +# Note: the ability to store a transmission *spectrum*, +# instead of a single value, is provided elsewhere in the structure, +# in the *SAStransmission_spectrum* element. +# +# +# +# Temperature of this sample. +# +# +# Any additional sample details. +# +# +# +# Location of the sample in :math:`x` +# +# +# Location of the sample in :math:`y` +# +# +# Rotation of the sample about the :math:`z` axis (roll) +# +# +# Rotation of the sample about the :math:`x` axis (roll) +# +# +# Rotation of the sample about the :math:`y` axis (yaw) +# +# +# +# +# +# +# +# +# +# +# Official canSAS group: :index:`NXcanSAS (applications); SASprocess` +# +# +# +# +# +# Description of a processing or analysis step. +# +# Add additional fields as needed to describe value(s) of any +# variable, parameter, or term related to the *SASprocess* step. +# Be sure to include *units* attributes for all numerical fields. +# +# +# +# Optional name for this data processing or analysis step +# +# +# +# Optional date for this data processing or analysis step. [#iso8601]_ +# +# +# .. [#iso8601] ISO-8601 standard time representation. +# +# NeXus dates and times are reported in ISO-8601 +# (e.g., ``yyyy-mm-ddThh:mm:ss``) +# or modified ISO-8601 (e.g., ``yyyy-mm-dd hh:mm:ss``). +# +# See: http://www.w3.org/TR/NOTE-datetime +# or http://en.wikipedia.org/wiki/ISO_8601 for more details. +# +# +# +# Optional description for this data processing or analysis step +# +# +# +# Specifies the value of a single variable, parameter, +# or term (while defined here as a string, it could be a number) +# related to the *SASprocess* step. +# +# Note: +# The name *term* is not required, it could take any name, +# as long as the name is unique within this group. +# +# +# +# +# +# +# Any additional notes or subprocessing steps will be documented here. +# +# An **NXnote** group can be added to any NeXus group at or below the +# **NXentry** group. It is shown here as a suggestion of a good place +# to *consider* its use. +# +# +# +# +# +# Describes anything about *SASprocess* that is not already described. +# +# Any content not defined in the canSAS standard can be placed at this point. +# +# Note: +# The name of this group is flexible, it could take any name, +# as long as it is unique within the **NXprocess** group. +# +# +# +# Official canSAS group: :index:`NXcanSAS (applications); SASprocessnote` +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Official canSAS group: :index:`NXcanSAS (applications); SASnote` +# +# +# +# +# +# +# Free form description of anything not covered by other elements. +# +# +# +# +# +# +# +# The *SAStransmission_spectrum* element +# +# This describes certain data obtained from a variable-wavelength source +# such as pulsed-neutron source. +# +# +# The name of each *SAStransmission_spectrum* group must be unique within a SASentry group. +# Suggest using names such as ``sastransmission_spectrum01``. +# +# +# Official canSAS group: :index:`NXcanSAS (applications); SAStransmission_spectrum` +# +# +# +# +# +# +# Name of the default data field. +# +# +# For **SAStransmission_spectrum**, this is always "T". +# +# +# +# +# +# the wavelengths field (as a dimension scale) corresponding to this transmission +# +# +# +# +# +# Identify what type of spectrum is being described. +# It is expected that this value will take either of these two values: +# +# ====== ============================================== +# value meaning +# ====== ============================================== +# sample measurement with the sample and container +# can measurement with just the container +# ====== ============================================== +# +# +# +# +# ISO-8601 time [#iso8601]_ +# +# +# +# +# +# Wavelength of the radiation. +# +# This array is of the same shape as ``T`` and ``Tdev``. +# +# +# +# +# Transmission values (:math:`I/I_0`) +# as a function of wavelength. +# +# This array is of the same shape as ``lambda`` and ``Tdev``. +# +# +# +# Names the dataset (in this SASdata group) that provides the +# uncertainty of each transmission :math:`T` to be used for data analysis. +# The name of the dataset containing the :math:`T` uncertainty +# is expected to be ``Tdev``. +# +# .. comment +# see: https://github.com/canSAS-org/canSAS2012/issues/7 +# +# Typically: +# +# @uncertainties="Tdev" +# +# +# +# +# +# +# +# .. index:: NXcanSAS (applications); Tdev +# +# Estimated uncertainty (usually standard deviation) +# in :math:`T`. Must have the same units as :math:`T`. +# +# This is the field is named in the *uncertainties* attribute of *T*, as in:: +# +# T/@uncertainties="Tdev" +# +# This array is of the same shape as ``lambda`` and ``T``. +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXdirecttof.yaml b/applications/nyaml/NXdirecttof.yaml new file mode 100644 index 0000000000..8ced0bc49d --- /dev/null +++ b/applications/nyaml/NXdirecttof.yaml @@ -0,0 +1,102 @@ +category: application +doc: | + This is a application definition for raw data from a direct geometry TOF spectrometer +type: group +NXdirecttof(NXtofraw): + (NXentry)entry: + title: + start_time(NX_DATE_TIME): + definition: + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXdirecttof] + (NXinstrument): + (NXfermi_chopper)fermi_chopper: + exists: ['min', '0'] + rotation_speed(NX_FLOAT): + unit: NX_FREQUENCY + doc: | + chopper rotation speed + energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + energy selected + (NXdisk_chopper)disk_chopper: + exists: ['min', '0'] + rotation_speed(NX_FLOAT): + unit: NX_FREQUENCY + doc: | + chopper rotation speed + energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + energy selected + doc: | + We definitly want the rotation_speed and energy of the chopper. Thus either + a fermi_chopper or a disk_chopper group is required. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 1d47a6d74aba3fd326b8022400cf62c8d44aa409690508a10b91dce0f188c23c +# +# +# +# +# This is a application definition for raw data from a direct geometry TOF spectrometer +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# chopper rotation speed +# +# +# energy selected +# +# +# +# +# chopper rotation speed +# +# +# energy selected +# +# +# +# We definitly want the rotation_speed and energy of the chopper. Thus either +# a fermi_chopper or a disk_chopper group is required. +# +# +# +# diff --git a/applications/nyaml/NXfluo.yaml b/applications/nyaml/NXfluo.yaml new file mode 100644 index 0000000000..34390473a8 --- /dev/null +++ b/applications/nyaml/NXfluo.yaml @@ -0,0 +1,165 @@ +category: application +doc: | + This is an application definition for raw data from an X-ray fluorescence experiment +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nE: | + Number of energies +type: group +NXfluo(NXobject): + (NXentry)entry: + title: + start_time(NX_DATE_TIME): + definition: + doc: | + Official NeXus NXDL schema to which this file conforms. + enumeration: [NXfluo] + (NXinstrument): + (NXsource): + type: + name: + probe: + enumeration: [x-ray] + (NXmonochromator)monochromator: + wavelength(NX_FLOAT): + (NXdetector)fluorescence: + data(NX_INT): + axes: energy + signal: 1 + dimensions: + rank: 1 + dim: [[1, nE]] + energy(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, nE]] + (NXsample): + name: + doc: | + Descriptive name of sample + (NXmonitor): + mode: + doc: | + Count to a preset value based on either clock time (timer) + or received monitor counts (monitor). + enumeration: [monitor, timer] + preset(NX_FLOAT): + doc: | + preset value for time or monitor + data(NX_INT): + (NXdata)data: + energy(link): + target: /entry/instrument/fluorescence/energy + data(link): + target: /entry/instrument/fluorescence/data + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# a29da208a1ae223c660dcd483b2d1f475272c28538ec79fc7f342883ca2cd321 +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of energies +# +# +# +# This is an application definition for raw data from an X-ray fluorescence experiment +# +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# +# +# Count to a preset value based on either clock time (timer) +# or received monitor counts (monitor). +# +# +# +# +# +# +# +# preset value for time or monitor +# +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXindirecttof.yaml b/applications/nyaml/NXindirecttof.yaml new file mode 100644 index 0000000000..ea4502b226 --- /dev/null +++ b/applications/nyaml/NXindirecttof.yaml @@ -0,0 +1,111 @@ +category: application +doc: | + This is a application definition for raw data from a direct geometry TOF spectrometer +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nDet: | + Number of detectors +type: group +NXindirecttof(NXtofraw): + (NXentry)entry: + title: + start_time(NX_DATE_TIME): + definition: + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXindirecttof] + (NXinstrument): + (NXmonochromator)analyser: + energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + analyzed energy + dimensions: + rank: 1 + dim: [[1, nDet]] + polar_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + polar angle towards sample + dimensions: + rank: 1 + dim: [[1, nDet]] + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + distance from sample + dimensions: + rank: 1 + dim: [[1, nDet]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# a8938d31a14f39d6935cd347cc25df7c67207c21c5bd8aab84182f83d2681d6e +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of detectors +# +# +# This is a application definition for raw data from a direct geometry TOF spectrometer +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# analyzed energy +# +# +# +# +# polar angle towards sample +# +# +# +# +# distance from sample +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXiqproc.yaml b/applications/nyaml/NXiqproc.yaml new file mode 100644 index 0000000000..de29062cf5 --- /dev/null +++ b/applications/nyaml/NXiqproc.yaml @@ -0,0 +1,201 @@ +category: application +doc: | + Application definition for any :math:`I(Q)` data. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nVars: | + The number of values taken by the varied variable + nQX: | + Number of values for the first dimension of Q + nQY: | + Number of values for the second dimension of Q +type: group +NXiqproc(NXobject): + (NXentry): + \@entry: + + # TODO documentation string needed here + title: + definition: + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXiqproc] + (NXinstrument)instrument: + (NXsource): + type: + name: + probe: + enumeration: [neutron, x-ray, electron] + name(NX_CHAR): + doc: | + Name of the instrument from which this data was reduced. + (NXsample): + name: + doc: | + Descriptive name of sample + (NXprocess)reduction: + program(NX_CHAR): + version(NX_CHAR): + (NXparameters)input: + filenames(NX_CHAR): + doc: | + Raw data files used to generate this I(Q) + doc: | + Input parameters for the reduction program used + (NXparameters)output: + doc: | + Eventual output parameters from the data reduction program used + (NXdata): + data(NX_INT): + signal: 1 + doc: | + This is I(Q). The client has to analyse the dimensions + of I(Q). Often, multiple I(Q) for various environment + conditions are measured; that would be the first + dimension. Q can be multidimensional, this accounts for + the further dimensions in the data + dimensions: + rank: 3 + dim: [[1, nVars], [2, nQX], [3, nQY]] + variable(NX_NUMBER): + axis: 1 + dimensions: + rank: 1 + dim: [[1, nVars]] + \@varied_variable: + doc: | + The real name of the varied variable in the first dim of data, temperature, P, MF etc... + qx(NX_NUMBER): + axis: 2 + doc: | + Values for the first dimension of Q + dimensions: + rank: 1 + dim: [[1, nQX]] + qy(NX_NUMBER): + axis: 3 + doc: | + Values for the second dimension of Q + dimensions: + rank: 1 + dim: [[1, nQY]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 20d4c942462350f47af152e37e83f320e5814be2b399fc9a4897794d1ce4916e +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# The number of values taken by the varied variable +# +# +# Number of values for the first dimension of Q +# +# +# Number of values for the second dimension of Q +# +# +# Application definition for any :math:`I(Q)` data. +# +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Name of the instrument from which this data was reduced. +# +# +# +# Descriptive name of sample +# +# +# +# +# +# +# +# Raw data files used to generate this I(Q) +# Input parameters for the reduction program used +# +# Eventual output parameters from the data reduction program used +# +# +# +# This is I(Q). The client has to analyse the dimensions +# of I(Q). Often, multiple I(Q) for various environment +# conditions are measured; that would be the first +# dimension. Q can be multidimensional, this accounts for +# the further dimensions in the data +# +# +# +# +# +# +# +# +# +# +# +# +# The real name of the varied variable in the first dim of data, temperature, P, MF etc... +# +# Values for the first dimension of Q +# +# +# +# Values for the second dimension of Q +# +# +# +# +# diff --git a/applications/nyaml/NXlauetof.yaml b/applications/nyaml/NXlauetof.yaml new file mode 100644 index 0000000000..60691e613e --- /dev/null +++ b/applications/nyaml/NXlauetof.yaml @@ -0,0 +1,244 @@ +category: application +doc: | + This is the application definition for a TOF laue diffractometer +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nXPixels: | + Number of X pixels + nYPixels: | + Number of Y pixels + nTOF: | + Time of flight +type: group +NXlauetof(NXobject): + (NXentry)entry: + definition: + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXlauetof] + (NXinstrument)instrument: + (NXdetector)detector: + doc: | + This assumes a planar 2D detector. All angles and distances refer to the center of the + detector. + polar_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + The polar_angle (two theta) where the detector is placed. + azimuthal_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + The azimuthal angle where the detector is placed. + data(NX_INT): + signal: 1 + dimensions: + rank: 3 + dim: [[1, nXPixels], [2, nYPixels], [3, nTOF]] + \@signal: + type: NX_POSINT + enumeration: [1] + x_pixel_size(NX_FLOAT): + unit: NX_LENGTH + y_pixel_size(NX_FLOAT): + unit: NX_LENGTH + distance(NX_FLOAT): + unit: NX_LENGTH + time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + dimensions: + rank: 1 + dim: [[1, nTOF]] + (NXsample)sample: + name: + doc: | + Descriptive name of sample + orientation_matrix(NX_FLOAT): + doc: | + The orientation matrix according to Busing and + Levy conventions. This is not strictly necessary as + the UB can always be derived from the data. But + let us bow to common usage which includes thie + UB nearly always. + dimensions: + rank: 2 + dim: [[1, 3], [2, 3]] + unit_cell(NX_FLOAT): + doc: | + The unit cell, a, b, c, alpha, beta, gamma. + Again, not strictly necessary, but normally written. + dimensions: + rank: 1 + dim: [[1, 6]] + (NXmonitor)control: + mode: + doc: | + Count to a preset value based on either clock time (timer) or received monitor counts + (monitor). + enumeration: [monitor, timer] + preset(NX_FLOAT): + doc: | + preset value for time or monitor + data(NX_INT): + doc: | + use these attributes ``primary=1 signal=1`` + dimensions: + rank: 1 + dim: [[1, nTOF]] + time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + dimensions: + rank: 1 + dim: [[1, nTOF]] + (NXdata)name: + data(link): + target: /NXentry/NXinstrument/NXdetector/data + time_of_flight(link): + target: /NXentry/NXinstrument/NXdetector/time_of_flight + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 9e664cc6cefa2508344073c6ddcac30bdfaa76a7950aaba871bf13b9f6f72be4 +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of X pixels +# +# +# Number of Y pixels +# +# +# Time of flight +# +# +# +# This is the application definition for a TOF laue diffractometer +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# This assumes a planar 2D detector. All angles and distances refer to the center of the +# detector. +# +# +# The polar_angle (two theta) where the detector is placed. +# +# +# The azimuthal angle where the detector is placed. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# The orientation matrix according to Busing and +# Levy conventions. This is not strictly necessary as +# the UB can always be derived from the data. But +# let us bow to common usage which includes thie +# UB nearly always. +# +# +# +# +# +# +# +# +# The unit cell, a, b, c, alpha, beta, gamma. +# Again, not strictly necessary, but normally written. +# +# +# +# +# +# +# +# +# Count to a preset value based on either clock time (timer) or received monitor counts +# (monitor). +# +# +# +# +# +# +# preset value for time or monitor +# +# +# use these attributes ``primary=1 signal=1`` +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXmonopd.yaml b/applications/nyaml/NXmonopd.yaml new file mode 100644 index 0000000000..f6381a17ce --- /dev/null +++ b/applications/nyaml/NXmonopd.yaml @@ -0,0 +1,223 @@ +category: application +doc: | + Monochromatic Neutron and X-Ray Powder diffractometer + + Instrument + definition for a powder diffractometer at a monochromatic neutron + or X-ray beam. This is both suited for a powder diffractometer + with a single detector or a powder diffractometer with a position + sensitive detector. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + i: | + i is the number of wavelengths + nDet: | + Number of detectors +type: group +NXmonopd(NXobject): + (NXentry)entry: + title: + start_time(NX_DATE_TIME): + definition: + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXmonopd] + (NXinstrument): + (NXsource): + type: + name: + probe: + enumeration: [neutron, x-ray, electron] + (NXcrystal): + wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + Optimum diffracted wavelength + dimensions: + rank: 1 + dim: [[1, i]] + (NXdetector): + polar_angle(NX_FLOAT): + axis: 1 + dimensions: + rank: 1 + dim: [[1, nDet]] + data(NX_INT): + signal: 1 + doc: | + detector signal (usually counts) are already + corrected for detector efficiency + dimensions: + rank: 1 + dim: [[1, nDet]] + (NXsample): + name: + doc: | + Descriptive name of sample + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Optional rotation angle for the case when the powder diagram + has been obtained through an omega-2theta scan like from a + traditional single detector powder diffractometer + (NXmonitor): + mode: + doc: | + Count to a preset value based on either clock time (timer) + or received monitor counts (monitor). + enumeration: [monitor, timer] + preset(NX_FLOAT): + doc: | + preset value for time or monitor + integral(NX_FLOAT): + unit: NX_ANY + doc: | + Total integral monitor counts + (NXdata): + polar_angle(link): + target: /NXentry/NXinstrument/NXdetector/polar_angle + doc: | + Link to polar angle in /NXentry/NXinstrument/NXdetector + data(link): + target: /NXentry/NXinstrument/NXdetector/data + doc: | + Link to data in /NXentry/NXinstrument/NXdetector + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# a85a64b0de4e045e8b6275a9ef6309437ba7aaad04f28e31d62f46d4744763c1 +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# i is the number of wavelengths +# +# +# Number of detectors +# +# +# +# Monochromatic Neutron and X-Ray Powder diffractometer +# +# Instrument +# definition for a powder diffractometer at a monochromatic neutron +# or X-ray beam. This is both suited for a powder diffractometer +# with a single detector or a powder diffractometer with a position +# sensitive detector. +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Optimum diffracted wavelength +# +# +# +# +# +# +# +# +# +# +# +# +# +# detector signal (usually counts) are already +# corrected for detector efficiency +# +# +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# Optional rotation angle for the case when the powder diagram +# has been obtained through an omega-2theta scan like from a +# traditional single detector powder diffractometer +# +# +# +# +# +# +# Count to a preset value based on either clock time (timer) +# or received monitor counts (monitor). +# +# +# +# +# +# +# +# preset value for time or monitor +# +# +# Total integral monitor counts +# +# +# +# +# Link to polar angle in /NXentry/NXinstrument/NXdetector +# +# +# Link to data in /NXentry/NXinstrument/NXdetector +# +# +# +# diff --git a/applications/nyaml/NXmx.yaml b/applications/nyaml/NXmx.yaml new file mode 100644 index 0000000000..f6fcb8c76b --- /dev/null +++ b/applications/nyaml/NXmx.yaml @@ -0,0 +1,1758 @@ +category: application +doc: | + functional application definition for macromolecular crystallography +symbols: + doc: | + These symbols will be used below to coordinate datasets + with the same shape. Most MX x-ray detectors will produce + two-dimensional images. Some will produce three-dimensional + images, using one of the indices to select a detector module. + dataRank: | + Rank of the ``data`` field + nP: | + Number of scan points + i: | + Number of detector pixels in the slowest direction + j: | + Number of detector pixels in the second slowest direction + k: | + Number of detector pixels in the third slowest direction + m: | + Number of channels in the incident beam spectrum, if known + groupIndex: | + An array of the hierarchical levels of the parents of detector + elements or groupings of detector elements. + A top-level element or grouping has parent level -1. +type: group +NXmx(NXobject): + (NXentry): + doc: | + Note, it is recommended that ``file_name`` and ``file_time`` are included + as attributes at the root of a file that includes :ref:`NXmx`. See + :ref:`NXroot`. + \@version: + exists: optional + doc: | + Describes the version of the NXmx definition used to write this data. + This must be a text (not numerical) representation. Such as:: + + @version="1.0" + enumeration: [1.0] + title(NX_CHAR): + exists: ['min', '0'] + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time/date of the first data point collected in UTC, + using the Z suffix to avoid confusion with local time. + Note that the time zone of the beamline should be provided in + NXentry/NXinstrument/time_zone. + end_time(NX_DATE_TIME): + exists: ['min', '0'] + doc: | + ISO 8601 time/date of the last data point collected in UTC, + using the Z suffix to avoid confusion with local time. + Note that the time zone of the beamline should be provided in + NXentry/NXinstrument/time_zone. This field should only be + filled when the value is accurately observed. If the data + collection aborts or otherwise prevents accurate recording of + the end_time, this field should be omitted. + end_time_estimated(NX_DATE_TIME): + doc: | + ISO 8601 time/date of the last data point collected in UTC, + using the Z suffix to avoid confusion with local time. + Note that the time zone of the beamline should be provided in + NXentry/NXinstrument/time_zone. This field may be filled + with a value estimated before an observed value is available. + definition: + doc: | + NeXus NXDL schema to which this file conforms + enumeration: [NXmx] + (NXdata): + data(NX_NUMBER): + exists: recommended + doc: | + For a dimension-2 detector, the rank of the data array will be 3. + For a dimension-3 detector, the rank of the data array will be 4. + This allows for the introduction of the frame number as the + first index. + dimensions: + rank: dataRank + dim: [[1, nP], [2, i], [3, j], [4, k]] + dim_parameters: + required: ['false'] + (NXsample): + name(NX_CHAR): + doc: | + Descriptive name of sample + depends_on(NX_CHAR): + + # better type for paths the need to resolve + doc: | + This is a requirement to describe for any scan experiment. + + The axis on which the sample position depends may be stored + anywhere, but is normally stored in the NXtransformations + group within the NXsample group. + + If there is no goniometer, e.g. with a jet, depends_on + should be set to "." + (NXtransformations): + exists: ['min', '0'] + doc: | + This is the recommended location for sample goniometer + and other related axes. + + This is a requirement to describe for any scan experiment. + The reason it is optional is mainly to accommodate XFEL + single shot exposures. + + Use of the depends_on field and the NXtransformations group is + strongly recommended. As noted above this should be an absolute + requirement to have for any scan experiment. + + The reason it is optional is mainly to accommodate XFEL + single shot exposures. + temperature(NX_NUMBER): + unit: NX_TEMPERATURE + exists: ['min', '0'] + (NXinstrument): + name(NX_CHAR): + exists: ['min', '1'] + + # CAUTION: keep URLs all on one line + doc: | + Name of instrument. Consistency with the controlled + vocabulary beamline naming in + https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.pdbx_synchrotron_beamline.html + and + https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.type.html + is highly recommended. + \@short_name: + exists: optional + doc: | + Short name for instrument, perhaps the acronym. + time_zone(NX_DATE_TIME): + exists: recommended + doc: | + ISO 8601 time_zone offset from UTC. + (NXattenuator): + exists: ['min', '0'] + attenuator_transmission(NX_NUMBER): + unit: NX_UNITLESS + exists: ['min', '0'] + (NXdetector_group): + exists: recommended + doc: | + Optional logical grouping of detectors. + + Each detector is represented as an NXdetector + with its own detector data array. Each detector data array + may be further decomposed into array sections by use of + NXdetector_module groups. Detectors can be grouped logically + together using NXdetector_group. Groups can be further grouped + hierarchically in a single NXdetector_group (for example, if + there are multiple detectors at an endstation or multiple + endstations at a facility). Alternatively, multiple + NXdetector_groups can be provided. + + The groups are defined hierarchically, with names given + in the group_names field, unique identifying indices given + in the field group_index, and the level in the hierarchy + given in the group_parent field. For example if an x-ray + detector group, DET, consists of four detectors in a + rectangular array:: + + DTL DTR + DLL DLR + + We could have:: + + group_names: ["DET", "DTL", "DTR", "DLL", "DLR"] + group_index: [1, 2, 3, 4, 5] + group_parent: [-1, 1, 1, 1, 1] + group_names(NX_CHAR): + doc: | + An array of the names of the detectors or the names of + hierarchical groupings of detectors. + group_index(NX_INT): + doc: | + An array of unique identifiers for detectors or groupings + of detectors. + + Each ID is a unique ID for the corresponding detector or group + named in the field group_names. The IDs are positive integers + starting with 1. + dimensions: + rank: 1 + dim: [[1, i]] + group_parent(NX_INT): + doc: | + An array of the hierarchical levels of the parents of detectors + or groupings of detectors. + + A top-level grouping has parent level -1. + dimensions: + rank: 1 + dim: [[1, groupIndex]] + (NXdetector): + doc: | + Normally the detector group will have the name ``detector``. + However, in the case of multiple detectors, each detector + needs a uniquely named NXdetector. + depends_on(NX_CHAR): + exists: ['min', '0'] + doc: | + NeXus path to the detector positioner axis that most directly + supports the detector. In the case of a single-module + detector, the detector axis chain may start here. + (NXtransformations): + exists: ['min', '0'] + doc: | + Location for axes (transformations) to do with the + detector. In the case of a single-module detector, the + axes of the detector axis chain may be stored here. + (NXcollection): + exists: ['min', '0'] + doc: | + Suggested container for detailed non-standard detector + information like corrections applied automatically or + performance settings. + data(NX_NUMBER): + exists: recommended + doc: | + For a dimension-2 detector, the rank of the data array will be 3. + For a dimension-3 detector, the rank of the data array will be 4. + This allows for the introduction of the frame number as the + first index. + dimensions: + rank: dataRank + dim: [[1, nP], [2, i], [3, j], [4, k]] + dim_parameters: + required: ['false'] + description: + exists: recommended + doc: | + name/manufacturer/model/etc. information. + time_per_channel: + unit: NX_TIME + exists: ['min', '0'] + doc: | + For a time-of-flight detector this is the scaling + factor to convert from the numeric value reported to + the flight time for a given measurement. + (NXdetector_module): + exists: ['min', '1', 'max', 'unbounded'] + doc: | + Many detectors consist of multiple smaller modules that are + operated in sync and store their data in a common dataset. + To allow consistent parsing of the experimental geometry, + this application definiton requires all detectors to + define a detector module, even if there is only one. + + This group specifies the hyperslab of data in the data + array associated with the detector that contains the + data for this module. If the module is associated with + a full data array, rather than with a hyperslab within + a larger array, then a single module should be defined, + spanning the entire array. + + Note, the pixel size is given as values in the array + fast_pixel_direction and slow_pixel_direction. + data_origin(NX_INT): + doc: | + A dimension-2 or dimension-3 field which gives the indices + of the origin of the hyperslab of data for this module in the + main area detector image in the parent NXdetector module. + + The data_origin is 0-based. + + The frame number dimension (nP) is omitted. Thus the + data_origin field for a dimension-2 dataset with indices (nP, i, j) + will be an array with indices (i, j), and for a dimension-3 + dataset with indices (nP, i, j, k) will be an array with indices + (i, j, k). + + The :ref:`order ` of indices (i, j + or i, j, k) is slow to fast. + data_size(NX_INT): + doc: | + Two or three values for the size of the module in pixels in + each direction. Dimensionality and order of indices is the + same as for data_origin. + data_stride(NX_INT): + exists: ['min', '0'] + doc: | + Two or three values for the stride of the module in pixels in + each direction. By default the stride is [1,1] or [1,1,1], + and this is the most likely case. This optional field is + included for completeness. + module_offset(NX_NUMBER): + unit: NX_LENGTH + exists: ['min', '0'] + doc: | + Offset of the module in regards to the origin of the detector in an + arbitrary direction. + \@transformation_type: + enumeration: [translation] + \@vector: + type: NX_NUMBER + \@offset: + type: NX_NUMBER + \@depends_on: + fast_pixel_direction(NX_NUMBER): + unit: NX_LENGTH + doc: | + Values along the direction of :ref:`fastest varying ` + pixel direction. The direction itself is given through the vector + attribute. + \@transformation_type: + enumeration: [translation] + \@vector: + type: NX_NUMBER + \@offset: + type: NX_NUMBER + \@depends_on: + slow_pixel_direction(NX_NUMBER): + unit: NX_LENGTH + doc: | + Values along the direction of :ref:`slowest varying ` + pixel direction. The direction itself is given through the vector + attribute. + \@transformation_type: + enumeration: [translation] + \@vector: + type: NX_NUMBER + \@offset: + type: NX_NUMBER + \@depends_on: + distance(NX_FLOAT): + unit: NX_LENGTH + exists: recommended + doc: | + Distance from the sample to the beam center. + Normally this value is for guidance only, the proper + geometry can be found following the depends_on axis chain, + But in appropriate cases where the dectector distance + to the sample is observable independent of the axis + chain, that may take precedence over the axis chain + calculation. + distance_derived(NX_BOOLEAN): + exists: recommended + doc: | + Boolean to indicate if the distance is a derived, rather than + a primary observation. If distance_derived true or is not specified, + the distance is assumed to be derived from detector axis + specifications. + dead_time(NX_FLOAT): + unit: NX_TIME + exists: ['min', '0'] + doc: | + Detector dead time. + count_time(NX_NUMBER): + unit: NX_TIME + exists: recommended + doc: | + Elapsed actual counting time. + beam_center_derived(NX_BOOLEAN): + exists: optional + doc: | + Boolean to indicate if the distance is a derived, rather than + a primary observation. If true or not provided, that value of + beam_center_derived is assumed to be true. + beam_center_x(NX_FLOAT): + unit: NX_LENGTH + exists: recommended + doc: | + This is the x position where the direct beam would hit the + detector. This is a length and can be outside of the actual + detector. The length can be in physical units or pixels as + documented by the units attribute. Normally, this should + be derived from the axis chain, but the direct specification + may take precedence if it is not a derived quantity. + beam_center_y(NX_FLOAT): + unit: NX_LENGTH + exists: recommended + doc: | + This is the y position where the direct beam would hit the + detector. This is a length and can be outside of the actual + detector. The length can be in physical units or pixels as + documented by the units attribute. Normally, this should + be derived from the axis chain, but the direct specification + may take precedence if it is not a derived quantity. + angular_calibration_applied(NX_BOOLEAN): + exists: ['min', '0'] + doc: | + True when the angular calibration has been applied in the + electronics, false otherwise. + angular_calibration(NX_FLOAT): + exists: ['min', '0'] + doc: | + Angular calibration data. + dimensions: + rank: dataRank + dim: [[1, i], [2, j], [3, k]] + dim_parameters: + required: ['false'] + flatfield_applied(NX_BOOLEAN): + exists: ['min', '0'] + doc: | + True when the flat field correction has been applied in the + electronics, false otherwise. + flatfield(NX_NUMBER): + exists: ['min', '0'] + doc: | + Flat field correction data. If provided, it is recommended + that it be compressed. + dimensions: + rank: dataRank + dim: [[1, i], [2, j], [3, k]] + dim_parameters: + required: ['false'] + flatfield_error(NX_NUMBER): + exists: ['min', '0', 'max', '0'] + doc: | + *** Deprecated form. Use plural form *** + Errors of the flat field correction data. If provided, it is recommended + that it be compressed. + dimensions: + rank: dataRank + dim: [[1, i], [2, j], [3, k]] + dim_parameters: + required: ['false'] + flatfield_errors(NX_NUMBER): + exists: ['min', '0'] + doc: | + Errors of the flat field correction data. If provided, it is recommended + that it be compressed. + dimensions: + rank: dataRank + dim: [[1, i], [2, j], [3, k]] + dim_parameters: + required: ['false'] + pixel_mask_applied(NX_BOOLEAN): + exists: ['min', '0'] + doc: | + True when the pixel mask correction has been applied in the + electronics, false otherwise. + pixel_mask(NX_INT): + exists: recommended + doc: | + The 32-bit pixel mask for the detector. Can be either one mask + for the whole dataset (i.e. an array with indices i, j) or + each frame can have its own mask (in which case it would be + an array with indices nP, i, j). + + Contains a bit field for each pixel to signal dead, + blind, high or otherwise unwanted or undesirable pixels. + They have the following meaning: + + * bit 0: gap (pixel with no sensor) + * bit 1: dead + * bit 2: under-responding + * bit 3: over-responding + * bit 4: noisy + * bit 5: -undefined- + * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) + * bit 7: -undefined- + * bit 8: user defined mask (e.g. around beamstop) + * bits 9-30: -undefined- + * bit 31: virtual pixel (corner pixel with interpolated value) + + Normal data analysis software would not take pixels into account + when a bit in (mask & 0x0000FFFF) is set. Tag bit in the upper + two bytes would indicate special pixel properties that normally + would not be a sole reason to reject the intensity value (unless + lower bits are set. + + If the full bit depths is not required, providing a + mask with fewer bits is permissible. + + If needed, additional pixel masks can be specified by + including additional entries named pixel_mask_N, where + N is an integer. For example, a general bad pixel mask + could be specified in pixel_mask that indicates noisy + and dead pixels, and an additional pixel mask from + experiment-specific shadowing could be specified in + pixel_mask_2. The cumulative mask is the bitwise OR + of pixel_mask and any pixel_mask_N entries. + + If provided, it is recommended that it be compressed. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + countrate_correction_applied(NX_BOOLEAN): + exists: ['min', '0'] + doc: | + Counting detectors usually are not able to measure all incoming particles, + especially at higher count-rates. Count-rate correction is applied to + account for these errors. + + True when count-rate correction has been applied, false otherwise. + countrate_correction_lookup_table(NX_NUMBER): + doc: | + The countrate_correction_lookup_table defines the LUT used for count-rate + correction. It maps a measured count :math:`c` to its corrected value + :math:`countrate\_correction\_lookup\_table[c]`. + + :math:`m` denotes the length of the table. + dimensions: + rank: 1 + dim: [[1, m]] + virtual_pixel_interpolation_applied(NX_BOOLEAN): + exists: ['min', '0'] + doc: | + True when virtual pixel interpolation has been applied, false otherwise. + + When virtual pixel interpolation is applied, values of some pixels may + contain interpolated values. For example, to account for space between + readout chips on a module, physical pixels on edges and corners between + chips may have larger sensor areas and counts may be distributed between + their logical pixels. + bit_depth_readout(NX_INT): + exists: recommended + doc: | + How many bits the electronics record per pixel. + detector_readout_time(NX_FLOAT): + unit: NX_TIME + exists: ['min', '0'] + doc: | + Time it takes to read the detector (typically milliseconds). + This is important to know for time resolved experiments. + frame_time(NX_FLOAT): + unit: NX_TIME + exists: ['min', '0'] + doc: | + This is time for each frame. This is exposure_time + readout + time. + gain_setting(NX_CHAR): + exists: ['min', '0'] + doc: | + The gain setting of the detector. This influences + background. This is a detector-specific value meant + to document the gain setting of the detector during + data collection, for detectors with multiple + available gain settings. + + Examples of gain settings include: + + * ``standard`` + * ``fast`` + * ``auto`` + * ``high`` + * ``medium`` + * ``low`` + * ``mixed high to medium`` + * ``mixed medium to low`` + + Developers are encouraged to use one of these terms, or to submit + additional terms to add to the list. + saturation_value(NX_NUMBER): + exists: ['min', '0'] + doc: | + The value at which the detector goes into saturation. + Data above this value is known to be invalid. + + For example, given a saturation_value and an underload_value, + the valid pixels are those less than or equal to the + saturation_value and greater than or equal to the underload_value. + underload_value(NX_NUMBER): + exists: ['min', '0'] + doc: | + The lowest value at which pixels for this detector + would be reasonably be measured. + + For example, given a saturation_value and an underload_value, + the valid pixels are those less than or equal to the + saturation_value and greater than or equal to the underload_value. + sensor_material(NX_CHAR): + exists: ['min', '1'] + doc: | + At times, radiation is not directly sensed by the detector. + Rather, the detector might sense the output from some + converter like a scintillator. + This is the name of this converter material. + sensor_thickness(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '1'] + doc: | + At times, radiation is not directly sensed by the detector. + Rather, the detector might sense the output from some + converter like a scintillator. This is the thickness of this + converter material. + threshold_energy(NX_FLOAT): + unit: NX_ENERGY + exists: ['min', '0'] + doc: | + Single photon counter detectors can be adjusted for a certain + energy range in which they work optimally. This is the energy + setting for this. If the detector supports multiple thresholds, + this is an array. + type: + exists: ['min', '0'] + doc: | + Description of type such as scintillator, + ccd, pixel, image + plate, CMOS, ... + (NXbeam): + exists: ['min', '1'] + \@flux: + exists: optional + doc: | + Which field contains the measured flux. One of ``flux``, + ``total_flux``, ``flux_integrated``, or ``total_flux_integrated``. + + Alternatively, the name being indicated could be a link + to a dataset in an NXmonitor group that records per shot beam data. + incident_wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + exists: ['min', '1'] + doc: | + In the case of a monchromatic 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. + incident_wavelength_weight(NX_FLOAT): + exists: ['min', '0'] + deprecated: | + use incident_wavelength_weights, see https://github.com/nexusformat/definitions/issues/837 + doc: | + In the case of a polychromatic beam this is an array of + length **m** of the relative weights of the corresponding + wavelengths in incident_wavelength. + + In the case of a polychromatic beam that varies shot-to- + shot, this is a 2D array of dimensions **nP** by **m** + (slow to fast) of the relative weights of the + corresponding wavelengths in incident_wavelength. + incident_wavelength_weights(NX_FLOAT): + exists: ['min', '0'] + doc: | + In the case of a polychromatic beam this is an array of + length **m** of the relative weights of the corresponding + wavelengths in ``incident_wavelength``. + + In the case of a polychromatic beam that varies shot-to- + shot, this is a 2D array of dimensions **np** by **m** + (slow to fast) of the relative weights of the + corresponding wavelengths in ``incident_wavelength``. + incident_wavelength_spread(NX_FLOAT): + unit: NX_WAVELENGTH + exists: ['min', '0'] + doc: | + The wavelength spread FWHM for the corresponding + wavelength(s) in incident_wavelength. + + In the case of shot-to-shot variation in the wavelength + spread, this is a 2D array of dimension **nP** by + **m** (slow to fast) of the spreads of the + corresponding wavelengths in incident_wavelength. + incident_wavelength_spectrum(NXdata): + exists: ['min', '0'] + doc: | + This group is intended for use cases that do not fit the + :ref:`incident_wavelength ` + and + :ref:`incident_wavelength_weights ` + fields above, perhaps for example a 2D spectrometer. + flux(NX_FLOAT): + unit: NX_FLUX + exists: ['min', '0'] + doc: | + Flux density incident on beam plane area in photons + per second per unit area. + + In the case of a beam that varies in flux shot-to-shot, + this is an array of values, one for each recorded shot. + total_flux(NX_FLOAT): + unit: NX_FREQUENCY + exists: ['min', '0'] + doc: | + Flux incident on beam plane in photons per second. In other words + this is the :ref:`flux ` integrated + over area. + + Useful where spatial beam profiles are not known. + + In the case of a beam that varies in total flux shot-to-shot, + this is an array of values, one for each recorded shot. + flux_integrated(NX_FLOAT): + unit: NX_PER_AREA + exists: ['min', '0'] + doc: | + Flux density incident on beam plane area in photons + per unit area. In other words this is the :ref:`flux ` + integrated over time. + + Useful where temporal beam profiles of flux are not known. + + In the case of a beam that varies in flux shot-to-shot, + this is an array of values, one for each recorded shot. + total_flux_integrated(NX_FLOAT): + unit: NX_DIMENSIONLESS + exists: ['min', '0'] + doc: | + Flux incident on beam plane in photons. In other words this is the :ref:`flux ` + integrated over time and area. + + Useful where temporal beam profiles of flux are not known. + + In the case of a beam that varies in total flux shot-to-shot, + this is an array of values, one for each recorded shot. + incident_beam_size(NX_FLOAT): + unit: NX_LENGTH + exists: recommended + doc: | + Two-element array of FWHM (if Gaussian or Airy function) or + diameters (if top hat) or widths (if rectangular) of the beam + in the order x, y + dimensions: + rank: 1 + dim: [[1, 2]] + profile(NX_CHAR): + exists: recommended + doc: | + The beam profile, Gaussian, Airy function, top-hat or + rectangular. The profile is given in the plane of + incidence of the beam on the sample. + enumeration: [Gaussian, Airy, top-hat, rectangular] + incident_polarisation_stokes(NX_NUMBER): + exists: optional + deprecated: | + use incident_polarization_stokes, see https://github.com/nexusformat/definitions/issues/708 + doc: | + Polarization vector on entering beamline + component using Stokes notation + dimensions: + rank: 2 + dim: [[1, nP], [2, 4]] + incident_polarization_stokes(NX_NUMBER): + exists: recommended + doc: | + Polarization vector on entering beamline + component using Stokes notation. See + incident_polarization_stokes in :ref:`NXbeam` + dimensions: + rank: 2 + dim: [[1, nP], [2, 4]] + (NXsource): + doc: | + The neutron or x-ray storage ring/facility. Note, the NXsource base class + has many more fields available, but at present we only require the name. + name: + exists: ['min', '1'] + doc: | + Name of source. Consistency with the naming in + https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.pdbx_synchrotron_site.html + controlled vocabulary is highly recommended. + \@short_name: + exists: optional + doc: | + short name for source, perhaps the acronym + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 3fbd4ec8b2d4a32359640fb344fe602982a5bb6a32465e0f51558219b29a3166 +# +# +# +# +# +# +# +# These symbols will be used below to coordinate datasets +# with the same shape. Most MX x-ray detectors will produce +# two-dimensional images. Some will produce three-dimensional +# images, using one of the indices to select a detector module. +# +# +# Rank of the ``data`` field +# +# +# Number of scan points +# +# +# Number of detector pixels in the slowest direction +# +# +# Number of detector pixels in the second slowest direction +# +# +# Number of detector pixels in the third slowest direction +# +# +# Number of channels in the incident beam spectrum, if known +# +# +# +# An array of the hierarchical levels of the parents of detector +# elements or groupings of detector elements. +# A top-level element or grouping has parent level -1. +# +# +# +# +# +# functional application definition for macromolecular crystallography +# +# +# +# +# +# Note, it is recommended that ``file_name`` and ``file_time`` are included +# as attributes at the root of a file that includes :ref:`NXmx`. See +# :ref:`NXroot`. +# +# +# +# +# Describes the version of the NXmx definition used to write this data. +# This must be a text (not numerical) representation. Such as:: +# +# @version="1.0" +# +# +# +# +# +# +# +# +# +# +# ISO 8601 time/date of the first data point collected in UTC, +# using the Z suffix to avoid confusion with local time. +# Note that the time zone of the beamline should be provided in +# NXentry/NXinstrument/time_zone. +# +# +# +# +# +# ISO 8601 time/date of the last data point collected in UTC, +# using the Z suffix to avoid confusion with local time. +# Note that the time zone of the beamline should be provided in +# NXentry/NXinstrument/time_zone. This field should only be +# filled when the value is accurately observed. If the data +# collection aborts or otherwise prevents accurate recording of +# the end_time, this field should be omitted. +# +# +# +# +# +# ISO 8601 time/date of the last data point collected in UTC, +# using the Z suffix to avoid confusion with local time. +# Note that the time zone of the beamline should be provided in +# NXentry/NXinstrument/time_zone. This field may be filled +# with a value estimated before an observed value is available. +# +# +# +# +# NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# +# For a dimension-2 detector, the rank of the data array will be 3. +# For a dimension-3 detector, the rank of the data array will be 4. +# This allows for the introduction of the frame number as the +# first index. +# +# +# +# +# +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# +# +# This is a requirement to describe for any scan experiment. +# +# The axis on which the sample position depends may be stored +# anywhere, but is normally stored in the NXtransformations +# group within the NXsample group. +# +# If there is no goniometer, e.g. with a jet, depends_on +# should be set to "." +# +# +# +# +# +# This is the recommended location for sample goniometer +# and other related axes. +# +# This is a requirement to describe for any scan experiment. +# The reason it is optional is mainly to accommodate XFEL +# single shot exposures. +# +# Use of the depends_on field and the NXtransformations group is +# strongly recommended. As noted above this should be an absolute +# requirement to have for any scan experiment. +# +# The reason it is optional is mainly to accommodate XFEL +# single shot exposures. +# +# +# +# +# +# +# +# +# +# +# +# +# Name of instrument. Consistency with the controlled +# vocabulary beamline naming in +# https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.pdbx_synchrotron_beamline.html +# and +# https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.type.html +# is highly recommended. +# +# +# Short name for instrument, perhaps the acronym. +# +# +# +# +# +# ISO 8601 time_zone offset from UTC. +# +# +# +# +# +# +# +# +# +# Optional logical grouping of detectors. +# +# Each detector is represented as an NXdetector +# with its own detector data array. Each detector data array +# may be further decomposed into array sections by use of +# NXdetector_module groups. Detectors can be grouped logically +# together using NXdetector_group. Groups can be further grouped +# hierarchically in a single NXdetector_group (for example, if +# there are multiple detectors at an endstation or multiple +# endstations at a facility). Alternatively, multiple +# NXdetector_groups can be provided. +# +# The groups are defined hierarchically, with names given +# in the group_names field, unique identifying indices given +# in the field group_index, and the level in the hierarchy +# given in the group_parent field. For example if an x-ray +# detector group, DET, consists of four detectors in a +# rectangular array:: +# +# DTL DTR +# DLL DLR +# +# We could have:: +# +# group_names: ["DET", "DTL", "DTR", "DLL", "DLR"] +# group_index: [1, 2, 3, 4, 5] +# group_parent: [-1, 1, 1, 1, 1] +# +# +# +# +# +# An array of the names of the detectors or the names of +# hierarchical groupings of detectors. +# +# +# +# +# +# An array of unique identifiers for detectors or groupings +# of detectors. +# +# Each ID is a unique ID for the corresponding detector or group +# named in the field group_names. The IDs are positive integers +# starting with 1. +# +# +# +# +# +# +# An array of the hierarchical levels of the parents of detectors +# or groupings of detectors. +# +# A top-level grouping has parent level -1. +# +# +# +# +# +# +# Normally the detector group will have the name ``detector``. +# However, in the case of multiple detectors, each detector +# needs a uniquely named NXdetector. +# +# +# +# +# NeXus path to the detector positioner axis that most directly +# supports the detector. In the case of a single-module +# detector, the detector axis chain may start here. +# +# +# +# +# +# Location for axes (transformations) to do with the +# detector. In the case of a single-module detector, the +# axes of the detector axis chain may be stored here. +# +# +# +# +# +# Suggested container for detailed non-standard detector +# information like corrections applied automatically or +# performance settings. +# +# +# +# +# +# For a dimension-2 detector, the rank of the data array will be 3. +# For a dimension-3 detector, the rank of the data array will be 4. +# This allows for the introduction of the frame number as the +# first index. +# +# +# +# +# +# +# +# +# +# +# +# name/manufacturer/model/etc. information. +# +# +# +# +# +# For a time-of-flight detector this is the scaling +# factor to convert from the numeric value reported to +# the flight time for a given measurement. +# +# +# +# +# +# Many detectors consist of multiple smaller modules that are +# operated in sync and store their data in a common dataset. +# To allow consistent parsing of the experimental geometry, +# this application definiton requires all detectors to +# define a detector module, even if there is only one. +# +# This group specifies the hyperslab of data in the data +# array associated with the detector that contains the +# data for this module. If the module is associated with +# a full data array, rather than with a hyperslab within +# a larger array, then a single module should be defined, +# spanning the entire array. +# +# Note, the pixel size is given as values in the array +# fast_pixel_direction and slow_pixel_direction. +# +# +# +# A dimension-2 or dimension-3 field which gives the indices +# of the origin of the hyperslab of data for this module in the +# main area detector image in the parent NXdetector module. +# +# The data_origin is 0-based. +# +# The frame number dimension (nP) is omitted. Thus the +# data_origin field for a dimension-2 dataset with indices (nP, i, j) +# will be an array with indices (i, j), and for a dimension-3 +# dataset with indices (nP, i, j, k) will be an array with indices +# (i, j, k). +# +# The :ref:`order <Design-ArrayStorageOrder>` of indices (i, j +# or i, j, k) is slow to fast. +# +# +# +# +# Two or three values for the size of the module in pixels in +# each direction. Dimensionality and order of indices is the +# same as for data_origin. +# +# +# +# +# Two or three values for the stride of the module in pixels in +# each direction. By default the stride is [1,1] or [1,1,1], +# and this is the most likely case. This optional field is +# included for completeness. +# +# +# +# +# +# Offset of the module in regards to the origin of the detector in an +# arbitrary direction. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Values along the direction of :ref:`fastest varying <Design-ArrayStorageOrder>` +# pixel direction. The direction itself is given through the vector +# attribute. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Values along the direction of :ref:`slowest varying <Design-ArrayStorageOrder>` +# pixel direction. The direction itself is given through the vector +# attribute. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Distance from the sample to the beam center. +# Normally this value is for guidance only, the proper +# geometry can be found following the depends_on axis chain, +# But in appropriate cases where the dectector distance +# to the sample is observable independent of the axis +# chain, that may take precedence over the axis chain +# calculation. +# +# +# +# +# +# Boolean to indicate if the distance is a derived, rather than +# a primary observation. If distance_derived true or is not specified, +# the distance is assumed to be derived from detector axis +# specifications. +# +# +# +# +# +# Detector dead time. +# +# +# +# +# +# Elapsed actual counting time. +# +# +# +# +# +# Boolean to indicate if the distance is a derived, rather than +# a primary observation. If true or not provided, that value of +# beam_center_derived is assumed to be true. +# +# +# +# +# +# +# +# This is the x position where the direct beam would hit the +# detector. This is a length and can be outside of the actual +# detector. The length can be in physical units or pixels as +# documented by the units attribute. Normally, this should +# be derived from the axis chain, but the direct specification +# may take precedence if it is not a derived quantity. +# +# +# +# +# +# This is the y position where the direct beam would hit the +# detector. This is a length and can be outside of the actual +# detector. The length can be in physical units or pixels as +# documented by the units attribute. Normally, this should +# be derived from the axis chain, but the direct specification +# may take precedence if it is not a derived quantity. +# +# +# +# +# +# True when the angular calibration has been applied in the +# electronics, false otherwise. +# +# +# +# +# Angular calibration data. +# +# +# +# +# +# +# +# +# +# True when the flat field correction has been applied in the +# electronics, false otherwise. +# +# +# +# +# +# Flat field correction data. If provided, it is recommended +# that it be compressed. +# +# +# +# +# +# +# +# +# +# +# +# *** Deprecated form. Use plural form *** +# Errors of the flat field correction data. If provided, it is recommended +# that it be compressed. +# +# +# +# +# +# +# +# +# +# +# Errors of the flat field correction data. If provided, it is recommended +# that it be compressed. +# +# +# +# +# +# +# +# +# +# +# True when the pixel mask correction has been applied in the +# electronics, false otherwise. +# +# +# +# +# +# The 32-bit pixel mask for the detector. Can be either one mask +# for the whole dataset (i.e. an array with indices i, j) or +# each frame can have its own mask (in which case it would be +# an array with indices nP, i, j). +# +# Contains a bit field for each pixel to signal dead, +# blind, high or otherwise unwanted or undesirable pixels. +# They have the following meaning: +# +# * bit 0: gap (pixel with no sensor) +# * bit 1: dead +# * bit 2: under-responding +# * bit 3: over-responding +# * bit 4: noisy +# * bit 5: -undefined- +# * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) +# * bit 7: -undefined- +# * bit 8: user defined mask (e.g. around beamstop) +# * bits 9-30: -undefined- +# * bit 31: virtual pixel (corner pixel with interpolated value) +# +# Normal data analysis software would not take pixels into account +# when a bit in (mask & 0x0000FFFF) is set. Tag bit in the upper +# two bytes would indicate special pixel properties that normally +# would not be a sole reason to reject the intensity value (unless +# lower bits are set. +# +# If the full bit depths is not required, providing a +# mask with fewer bits is permissible. +# +# If needed, additional pixel masks can be specified by +# including additional entries named pixel_mask_N, where +# N is an integer. For example, a general bad pixel mask +# could be specified in pixel_mask that indicates noisy +# and dead pixels, and an additional pixel mask from +# experiment-specific shadowing could be specified in +# pixel_mask_2. The cumulative mask is the bitwise OR +# of pixel_mask and any pixel_mask_N entries. +# +# If provided, it is recommended that it be compressed. +# +# +# +# +# +# +# +# +# Counting detectors usually are not able to measure all incoming particles, +# especially at higher count-rates. Count-rate correction is applied to +# account for these errors. +# +# True when count-rate correction has been applied, false otherwise. +# +# +# +# +# The countrate_correction_lookup_table defines the LUT used for count-rate +# correction. It maps a measured count :math:`c` to its corrected value +# :math:`countrate\_correction\_lookup\_table[c]`. +# +# :math:`m` denotes the length of the table. +# +# +# +# +# +# +# +# True when virtual pixel interpolation has been applied, false otherwise. +# +# When virtual pixel interpolation is applied, values of some pixels may +# contain interpolated values. For example, to account for space between +# readout chips on a module, physical pixels on edges and corners between +# chips may have larger sensor areas and counts may be distributed between +# their logical pixels. +# +# +# +# +# +# How many bits the electronics record per pixel. +# +# +# +# +# +# Time it takes to read the detector (typically milliseconds). +# This is important to know for time resolved experiments. +# +# +# +# +# +# This is time for each frame. This is exposure_time + readout +# time. +# +# +# +# +# +# The gain setting of the detector. This influences +# background. This is a detector-specific value meant +# to document the gain setting of the detector during +# data collection, for detectors with multiple +# available gain settings. +# +# Examples of gain settings include: +# +# * ``standard`` +# * ``fast`` +# * ``auto`` +# * ``high`` +# * ``medium`` +# * ``low`` +# * ``mixed high to medium`` +# * ``mixed medium to low`` +# +# Developers are encouraged to use one of these terms, or to submit +# additional terms to add to the list. +# +# +# +# +# +# The value at which the detector goes into saturation. +# Data above this value is known to be invalid. +# +# For example, given a saturation_value and an underload_value, +# the valid pixels are those less than or equal to the +# saturation_value and greater than or equal to the underload_value. +# +# +# +# +# +# The lowest value at which pixels for this detector +# would be reasonably be measured. +# +# For example, given a saturation_value and an underload_value, +# the valid pixels are those less than or equal to the +# saturation_value and greater than or equal to the underload_value. +# +# +# +# +# +# At times, radiation is not directly sensed by the detector. +# Rather, the detector might sense the output from some +# converter like a scintillator. +# This is the name of this converter material. +# +# +# +# +# +# At times, radiation is not directly sensed by the detector. +# Rather, the detector might sense the output from some +# converter like a scintillator. This is the thickness of this +# converter material. +# +# +# +# +# +# Single photon counter detectors can be adjusted for a certain +# energy range in which they work optimally. This is the energy +# setting for this. If the detector supports multiple thresholds, +# this is an array. +# +# +# +# +# +# Description of type such as scintillator, +# ccd, pixel, image +# plate, CMOS, ... +# +# +# +# +# +# +# Which field contains the measured flux. One of ``flux``, +# ``total_flux``, ``flux_integrated``, or ``total_flux_integrated``. +# +# Alternatively, the name being indicated could be a link +# to a dataset in an NXmonitor group that records per shot beam data. +# +# +# +# +# In the case of a monchromatic 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 <Design-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. +# +# +# +# +# +# In the case of a polychromatic beam this is an array of +# length **m** of the relative weights of the corresponding +# wavelengths in incident_wavelength. +# +# In the case of a polychromatic beam that varies shot-to- +# shot, this is a 2D array of dimensions **nP** by **m** +# (slow to fast) of the relative weights of the +# corresponding wavelengths in incident_wavelength. +# +# +# +# +# In the case of a polychromatic beam this is an array of +# length **m** of the relative weights of the corresponding +# wavelengths in ``incident_wavelength``. +# +# In the case of a polychromatic beam that varies shot-to- +# shot, this is a 2D array of dimensions **np** by **m** +# (slow to fast) of the relative weights of the +# corresponding wavelengths in ``incident_wavelength``. +# +# +# +# +# +# The wavelength spread FWHM for the corresponding +# wavelength(s) in incident_wavelength. +# +# In the case of shot-to-shot variation in the wavelength +# spread, this is a 2D array of dimension **nP** by +# **m** (slow to fast) of the spreads of the +# corresponding wavelengths in incident_wavelength. +# +# +# +# +# +# This group is intended for use cases that do not fit the +# :ref:`incident_wavelength </NXmx/ENTRY/INSTRUMENT/BEAM/incident_wavelength-field>` +# and +# :ref:`incident_wavelength_weights </NXmx/ENTRY/INSTRUMENT/BEAM/incident_wavelength_weights-field>` +# fields above, perhaps for example a 2D spectrometer. +# +# +# +# +# +# Flux density incident on beam plane area in photons +# per second per unit area. +# +# In the case of a beam that varies in flux shot-to-shot, +# this is an array of values, one for each recorded shot. +# +# +# +# +# +# Flux incident on beam plane in photons per second. In other words +# this is the :ref:`flux </NXmx/ENTRY/INSTRUMENT/BEAM/flux-field>` integrated +# over area. +# +# Useful where spatial beam profiles are not known. +# +# In the case of a beam that varies in total flux shot-to-shot, +# this is an array of values, one for each recorded shot. +# +# +# +# +# +# Flux density incident on beam plane area in photons +# per unit area. In other words this is the :ref:`flux </NXmx/ENTRY/INSTRUMENT/BEAM/flux-field>` +# integrated over time. +# +# Useful where temporal beam profiles of flux are not known. +# +# In the case of a beam that varies in flux shot-to-shot, +# this is an array of values, one for each recorded shot. +# +# +# +# +# +# Flux incident on beam plane in photons. In other words this is the :ref:`flux </NXmx/ENTRY/INSTRUMENT/BEAM/flux-field>` +# integrated over time and area. +# +# Useful where temporal beam profiles of flux are not known. +# +# In the case of a beam that varies in total flux shot-to-shot, +# this is an array of values, one for each recorded shot. +# +# +# +# +# +# Two-element array of FWHM (if Gaussian or Airy function) or +# diameters (if top hat) or widths (if rectangular) of the beam +# in the order x, y +# +# +# +# +# +# +# +# +# The beam profile, Gaussian, Airy function, top-hat or +# rectangular. The profile is given in the plane of +# incidence of the beam on the sample. +# +# +# +# +# +# +# +# +# +# +# Polarization vector on entering beamline +# component using Stokes notation +# +# +# +# +# +# +# +# +# Polarization vector on entering beamline +# component using Stokes notation. See +# incident_polarization_stokes in :ref:`NXbeam` +# +# +# +# +# +# +# +# +# +# +# The neutron or x-ray storage ring/facility. Note, the NXsource base class +# has many more fields available, but at present we only require the name. +# +# +# +# Name of source. Consistency with the naming in +# https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.pdbx_synchrotron_site.html +# controlled vocabulary is highly recommended. +# +# +# short name for source, perhaps the acronym +# +# +# +# +# diff --git a/applications/nyaml/NXrefscan.yaml b/applications/nyaml/NXrefscan.yaml new file mode 100644 index 0000000000..545d01fd6e --- /dev/null +++ b/applications/nyaml/NXrefscan.yaml @@ -0,0 +1,197 @@ +category: application +doc: | + This is an application definition for a monochromatic scanning reflectometer. + + It does not have the information to calculate the resolution + since it does not have any apertures. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nP: | + Number of points +type: group +NXrefscan(NXobject): + (NXentry)entry: + title: + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + definition: + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXrefscan] + (NXinstrument)instrument: + (NXsource): + type: + name: + probe: + enumeration: [neutron, x-ray, electron] + (NXmonochromator)monochromator: + wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + (NXdetector): + data(NX_INT): + signal: 1 + dimensions: + rank: 1 + dim: [[1, nP]] + polar_angle(NX_FLOAT): + unit: NX_ANGLE + axis: 1 + dimensions: + rank: 1 + dim: [[1, nP]] + (NXsample)sample: + name: + doc: | + Descriptive name of sample + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + dimensions: + rank: 1 + dim: [[1, nP]] + (NXmonitor)control: + mode: + doc: | + Count to a preset value based on either clock time (timer) + or received monitor counts (monitor). + enumeration: [monitor, timer] + preset(NX_FLOAT): + doc: | + preset value for time or monitor + data(NX_FLOAT): + unit: NX_ANY + doc: | + Monitor counts for each step + dimensions: + rank: 1 + dim: [[1, nP]] + (NXdata)data: + data(link): + target: /NXentry/NXinstrument/NXdetector/data + rotation_angle(link): + target: /NXentry/NXsample/rotation_angle + polar_angle(link): + target: /NXentry/NXinstrument/NXdetector/polar_angle + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 2292093a2a73147dd621497414bfff4f52e5a2103a0c4b1e5a119e15e005b78f +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of points +# +# +# +# This is an application definition for a monochromatic scanning reflectometer. +# +# It does not have the information to calculate the resolution +# since it does not have any apertures. +# +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# +# +# +# +# +# +# +# Count to a preset value based on either clock time (timer) +# or received monitor counts (monitor). +# +# +# +# +# +# +# +# preset value for time or monitor +# +# +# Monitor counts for each step +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXreftof.yaml b/applications/nyaml/NXreftof.yaml new file mode 100644 index 0000000000..760c7023fe --- /dev/null +++ b/applications/nyaml/NXreftof.yaml @@ -0,0 +1,214 @@ +category: application +doc: | + This is an application definition for raw data from a TOF reflectometer. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + xSize: | + xSize description + ySize: | + ySize description + nTOF: | + nTOF description +type: group +NXreftof(NXobject): + (NXentry)entry: + title: + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + definition: + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXreftof] + (NXinstrument)instrument: + name(NX_CHAR): + (NXdisk_chopper)chopper: + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + Distance between chopper and sample + (NXdetector)detector: + data(NX_INT): + signal: 1 + dimensions: + rank: 3 + dim: [[1, xSize], [2, ySize], [3, nTOF]] + time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + axis: 3 + doc: | + Array of time values for each bin in a time-of-flight + measurement + dimensions: + rank: 1 + dim: [[1, nTOF]] + distance(NX_FLOAT): + unit: NX_LENGTH + polar_angle(NX_FLOAT): + unit: NX_ANGLE + x_pixel_size(NX_FLOAT): + unit: NX_LENGTH + y_pixel_size(NX_FLOAT): + unit: NX_LENGTH + (NXsample)sample: + name: + doc: | + Descriptive name of sample + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + (NXmonitor)control: + mode: + doc: | + Count to a preset value based on either clock time (timer) + or received monitor counts (monitor). + enumeration: [monitor, timer] + preset(NX_FLOAT): + unit: NX_ANY + doc: | + preset value for time or monitor + integral(NX_INT): + doc: | + Total integral monitor counts + time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + axis: 1 + doc: | + Time channels + data(NX_INT): + signal: 1 + doc: | + Monitor counts in each time channel + (NXdata)data: + data(link): + target: /NXentry/NXinstrument/NXdetector/data + time_of_flight(link): + target: /NXentry/NXinstrument/NXdetector/time_of_flight + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 11c65854a466d2dce2e11e31861b9d33736ed082b3571645b0c3f1feebd16bbd +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# xSize description +# +# +# ySize description +# +# +# nTOF description +# +# +# This is an application definition for raw data from a TOF reflectometer. +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# Distance between chopper and sample +# +# +# +# +# +# +# +# +# +# +# +# +# Array of time values for each bin in a time-of-flight +# measurement +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# +# +# +# Count to a preset value based on either clock time (timer) +# or received monitor counts (monitor). +# +# +# +# +# +# +# +# preset value for time or monitor +# +# +# Total integral monitor counts +# +# +# Time channels +# +# +# Monitor counts in each time channel +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXsas.yaml b/applications/nyaml/NXsas.yaml new file mode 100644 index 0000000000..2e160f0bbc --- /dev/null +++ b/applications/nyaml/NXsas.yaml @@ -0,0 +1,369 @@ +category: application +doc: | + Raw, monochromatic 2-D SAS data with an area detector. + + This is an application definition for raw data (not processed or reduced data) + from a 2-D small angle scattering instrument collected with a monochromatic + beam and an area detector. It is meant to be suitable both for neutron SANS + and X-ray SAXS data. + + It covers all raw data from any monochromatic SAS techniques that + use an area detector: SAS, WSAS, grazing incidence, GISAS + + It covers all raw data from any SAS techniques that use an area detector and + a monochromatic beam. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate fields with the same shape. + nXPixel: | + Number of pixels in x direction. + nYPixel: | + Number of pixels in y direction. +type: group +NXsas(NXobject): + (NXentry): + title: + exists: ['min', '0'] + start_time(NX_DATE_TIME): + exists: ['min', '0'] + end_time(NX_DATE_TIME): + exists: ['min', '0'] + definition: + doc: | + Official NeXus NXDL schema to which this file conforms. + enumeration: [NXsas] + (NXinstrument): + (NXsource): + type: + doc: | + Type of radiation source. + name: + exists: ['min', '0'] + doc: | + Name of the radiation source. + probe: + doc: | + Name of radiation probe, necessary to compute the sample contrast. + enumeration: [neutron, x-ray] + (NXmonochromator): + wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + The wavelength (:math:`\lambda`) of the radiation. + wavelength_spread(NX_FLOAT): + exists: ['min', '0'] + doc: | + delta_lambda/lambda (:math:`\Delta\lambda/\lambda`): + Important for resolution calculations. + (NXcollimator): + exists: ['min', '0'] + (NXgeometry): + (NXshape): + shape(NX_CHAR): + enumeration: [nxcylinder, nxbox] + size(NX_FLOAT): + unit: NX_LENGTH + doc: | + The collimation length. + (NXdetector): + data(NX_NUMBER): + doc: | + This is area detector data, number of x-pixel versus + number of y-pixels. + + Since the beam center is to be determined as a step of data + reduction, it is not necessary to document or assume the position of + the beam center in acquired data. + + It is necessary to define which are the x and y directions, to coordinate + with the pixel size and compute Q. + dimensions: + rank: 2 + dim: [[1, nXPixel], [2, nYPixel]] + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + The distance between detector and sample. + x_pixel_size(NX_FLOAT): + unit: NX_LENGTH + doc: | + Physical size of a pixel in x-direction. + y_pixel_size(NX_FLOAT): + unit: NX_LENGTH + doc: | + Physical size of a pixel in y-direction. + polar_angle(NX_FLOAT): + unit: NX_ANGLE + exists: ['min', '0'] + azimuthal_angle(NX_FLOAT): + unit: NX_ANGLE + exists: ['min', '0'] + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + exists: ['min', '0'] + aequatorial_angle(NX_FLOAT): + unit: NX_ANGLE + exists: ['min', '0'] + beam_center_x(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '0'] + doc: | + This is the x position where the direct beam would hit the detector. + This is a length, not a pixel position, and can be outside of the + actual detector. + + It is expected that data reduction will determine beam center from + the raw data, thus it is not required here. The instrument can + provide an initial or nominal value to advise data reduction. + beam_center_y(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '0'] + doc: | + This is the y position where the direct beam would hit the detector. + This is a length, not a pixel position, and can be outside of the + actual detector. + + It is expected that data reduction will determine beam center from + the raw data, thus it is not required here. The instrument can + provide an initial or nominal value to advise data reduction. + name(NX_CHAR): + doc: | + Name of the instrument actually used to perform the experiment. + (NXsample): + exists: ['min', '0'] + name: + doc: | + Descriptive name of sample. + aequatorial_angle(NX_FLOAT): + unit: NX_ANGLE + exists: ['min', '0'] + (NXmonitor): + exists: ['min', '0'] + mode: + doc: | + Count to a preset value based on either clock time + (timer) or received monitor counts (monitor). + enumeration: [monitor, timer] + preset(NX_FLOAT): + doc: | + Preset value for time or monitor. + integral(NX_FLOAT): + unit: NX_ANY + doc: | + Total integral monitor counts. + (NXdata): + \@signal: + exists: optional + doc: | + Name the *plottable* field. The link here defines this name as + ``data``. + enumeration: [data] + data(link): + target: /NXentry/NXinstrument/NXdetector/data + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 2aa6302899fe37644b84e8ae5fba65adf3e17563e6bf42afe1beee8007b93ff5 +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate fields with the same shape. +# +# +# Number of pixels in x direction. +# +# +# Number of pixels in y direction. +# +# +# +# Raw, monochromatic 2-D SAS data with an area detector. +# +# This is an application definition for raw data (not processed or reduced data) +# from a 2-D small angle scattering instrument collected with a monochromatic +# beam and an area detector. It is meant to be suitable both for neutron SANS +# and X-ray SAXS data. +# +# It covers all raw data from any monochromatic SAS techniques that +# use an area detector: SAS, WSAS, grazing incidence, GISAS +# +# It covers all raw data from any SAS techniques that use an area detector and +# a monochromatic beam. +# +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms. +# +# +# +# +# +# +# +# Type of radiation source. +# +# +# Name of the radiation source. +# +# +# +# Name of radiation probe, necessary to compute the sample contrast. +# +# +# +# +# +# +# +# +# +# The wavelength (:math:`\lambda`) of the radiation. +# +# +# +# delta_lambda/lambda (:math:`\Delta\lambda/\lambda`): +# Important for resolution calculations. +# +# +# +# +# +# +# +# +# +# +# +# +# +# The collimation length. +# +# +# +# +# +# +# +# This is area detector data, number of x-pixel versus +# number of y-pixels. +# +# Since the beam center is to be determined as a step of data +# reduction, it is not necessary to document or assume the position of +# the beam center in acquired data. +# +# It is necessary to define which are the x and y directions, to coordinate +# with the pixel size and compute Q. +# +# +# +# +# +# +# +# The distance between detector and sample. +# +# +# Physical size of a pixel in x-direction. +# +# +# Physical size of a pixel in y-direction. +# +# +# +# +# +# +# +# This is the x position where the direct beam would hit the detector. +# This is a length, not a pixel position, and can be outside of the +# actual detector. +# +# It is expected that data reduction will determine beam center from +# the raw data, thus it is not required here. The instrument can +# provide an initial or nominal value to advise data reduction. +# +# +# +# +# This is the y position where the direct beam would hit the detector. +# This is a length, not a pixel position, and can be outside of the +# actual detector. +# +# It is expected that data reduction will determine beam center from +# the raw data, thus it is not required here. The instrument can +# provide an initial or nominal value to advise data reduction. +# +# +# +# +# Name of the instrument actually used to perform the experiment. +# +# +# +# +# Descriptive name of sample. +# +# +# +# +# +# +# Count to a preset value based on either clock time +# (timer) or received monitor counts (monitor). +# +# +# +# +# +# +# +# Preset value for time or monitor. +# +# +# Total integral monitor counts. +# +# +# +# +# +# Name the *plottable* field. The link here defines this name as +# ``data``. +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXsastof.yaml b/applications/nyaml/NXsastof.yaml new file mode 100644 index 0000000000..4a3530a29a --- /dev/null +++ b/applications/nyaml/NXsastof.yaml @@ -0,0 +1,312 @@ +category: application +doc: | + raw, 2-D SAS data with an area detector with a time-of-flight source + + It covers all raw data from any SAS techniques + that use an area detector + at a time-of-flight source. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nXPixel: | + nXPixel description + nYPixel: | + nYPixel description + nTOF: | + nTOF description +type: group +NXsastof(NXobject): + (NXentry): + \@entry: + doc: | + NeXus convention is to use "entry1", "entry2", ... for analysis software to locate each entry + title: + start_time(NX_DATE_TIME): + definition: + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXsastof] + (NXinstrument)instrument: + (NXsource)source: + type: + doc: | + type of radiation source + name: + doc: | + Name of the radiation source + probe: + enumeration: [neutron, x-ray] + (NXcollimator)collimator: + (NXgeometry)geometry: + (NXshape)shape: + shape(NX_CHAR): + enumeration: [nxcylinder, nxbox] + size(NX_FLOAT): + unit: NX_LENGTH + doc: | + The collimation length + (NXdetector)detector: + data(NX_NUMBER): + signal: 1 + doc: | + This is area detector data, of number of x-pixel versus + number of y-pixels. Since the beam center is to be + determined as a step of data reduction, it is not necessary + to document or assume the position of the beam center in + acquired data. + dimensions: + rank: 3 + dim: [[1, nXPixel], [2, nYPixel], [3, nTOF]] + time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + dimensions: + rank: 1 + dim: [[1, nTOF]] + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + The distance between detector and sample + x_pixel_size(NX_FLOAT): + unit: NX_LENGTH + doc: | + Physical size of a pixel in x-direction + y_pixel_size(NX_FLOAT): + unit: NX_LENGTH + doc: | + Size of a pixel in y direction + polar_angle(NX_FLOAT): + unit: NX_ANGLE + azimuthal_angle(NX_FLOAT): + unit: NX_ANGLE + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + aequatorial_angle(NX_FLOAT): + unit: NX_ANGLE + beam_center_x(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the x position where the direct beam would hit the detector. This is a + length, not a pixel position, and can be outside of the actual detector. + beam_center_y(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the y position where the direct beam would hit the detector. This is a + length, not a pixel position, and can be outside of the actual detector. + name(NX_CHAR): + doc: | + Name of the instrument actually used to perform the experiment + (NXsample)sample: + name: + doc: | + Descriptive name of sample + aequatorial_angle(NX_FLOAT): + unit: NX_ANGLE + (NXmonitor)control: + mode: + doc: | + Count to a preset value based on either clock time (timer) or received monitor counts (monitor). + enumeration: [monitor, timer] + preset(NX_FLOAT): + doc: | + preset value for time or monitor + data(NX_INT): + primary: 1 + signal: 1 + dimensions: + rank: 1 + dim: [[1, nTOF]] + time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + dimensions: + rank: 1 + dim: [[1, nTOF]] + (NXdata)data: + data(link): + target: /NXentry/NXinstrument/NXdetector/data + time_of_flight(link): + target: /NXentry/NXinstrument/NXdetector/time_of_flight + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 18b43c8a5ad4926ae6e06b953df9d44c87db9e7f47f4f7e99e072f3950620660 +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# nXPixel description +# +# +# nYPixel description +# +# +# nTOF description +# +# +# +# raw, 2-D SAS data with an area detector with a time-of-flight source +# +# It covers all raw data from any SAS techniques +# that use an area detector +# at a time-of-flight source. +# +# +# +# NeXus convention is to use "entry1", "entry2", ... for analysis software to locate each entry +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# type of radiation source +# +# +# Name of the radiation source +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The collimation length +# +# +# +# +# +# +# +# This is area detector data, of number of x-pixel versus +# number of y-pixels. Since the beam center is to be +# determined as a step of data reduction, it is not necessary +# to document or assume the position of the beam center in +# acquired data. +# +# +# +# +# +# +# +# +# +# +# +# +# The distance between detector and sample +# +# +# Physical size of a pixel in x-direction +# +# +# Size of a pixel in y direction +# +# +# +# +# +# +# +# +# +# This is the x position where the direct beam would hit the detector. This is a +# length, not a pixel position, and can be outside of the actual detector. +# +# +# +# +# This is the y position where the direct beam would hit the detector. This is a +# length, not a pixel position, and can be outside of the actual detector. +# +# +# +# +# Name of the instrument actually used to perform the experiment +# +# +# +# +# Descriptive name of sample +# +# +# +# +# +# +# Count to a preset value based on either clock time (timer) or received monitor counts (monitor). +# +# +# +# +# +# +# preset value for time or monitor +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXscan.yaml b/applications/nyaml/NXscan.yaml new file mode 100644 index 0000000000..38f6e0107c --- /dev/null +++ b/applications/nyaml/NXscan.yaml @@ -0,0 +1,181 @@ +category: application +doc: | + Application definition for a generic scan instrument. + + This definition is more an + example then a stringent definition as the content of a given NeXus scan file needs to + differ for different types of scans. This example definition shows a scan like done + on a rotation camera: the sample is rotated and a detector image, the rotation angle + and a monitor value is stored at each step in the scan. In the following, the symbol + ``NP`` is used to represent the number of scan points. These are the rules for + storing scan data in NeXus files which are implemented in this example: + + * Each value varied throughout a scan is stored as an array of + length ``NP`` at its respective location within the NeXus hierarchy. + * For area detectors, ``NP`` is the first dimension, + example for a detector of 256x256: ``data[NP,256,256]`` + * The NXdata group contains links to all variables varied in the scan and the data. + This to give an equivalent to the more familiar classical tabular representation of scans. + + These rules exist for a reason: HDF allows the first dimension of a data set to be + unlimited. This means the data can be appended too. Thus a NeXus file built according + to the rules given above can be used in the following way: + + * At the start of a scan, write all the static information. + * At each scan point, append new data from varied variables + and the detector to the file. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nP: | + Number of points + xDim: | + xDim description + yDim: | + yDim description +type: group +NXscan(NXobject): + (NXentry): + title: + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + definition(NX_CHAR): + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXscan] + (NXinstrument): + (NXdetector): + data(NX_INT): + signal: 1 + dimensions: + rank: 3 + dim: [[1, nP], [2, xDim], [3, yDim]] + (NXsample): + rotation_angle(NX_FLOAT): + axis: 1 + dimensions: + rank: 1 + dim: [[1, nP]] + (NXmonitor): + data(NX_INT): + dimensions: + rank: 1 + dim: [[1, nP]] + (NXdata): + data(link): + target: /NXentry/NXinstrument/NXdetector/data + rotation_angle(link): + target: /NXentry/NXsample/rotation_angle + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 0a6ad9072ad7a42beaa653d148ef9e0187624de64ae1a25be57d67eebe991360 +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of points +# +# +# xDim description +# +# +# yDim description +# +# +# +# Application definition for a generic scan instrument. +# +# This definition is more an +# example then a stringent definition as the content of a given NeXus scan file needs to +# differ for different types of scans. This example definition shows a scan like done +# on a rotation camera: the sample is rotated and a detector image, the rotation angle +# and a monitor value is stored at each step in the scan. In the following, the symbol +# ``NP`` is used to represent the number of scan points. These are the rules for +# storing scan data in NeXus files which are implemented in this example: +# +# * Each value varied throughout a scan is stored as an array of +# length ``NP`` at its respective location within the NeXus hierarchy. +# * For area detectors, ``NP`` is the first dimension, +# example for a detector of 256x256: ``data[NP,256,256]`` +# * The NXdata group contains links to all variables varied in the scan and the data. +# This to give an equivalent to the more familiar classical tabular representation of scans. +# +# These rules exist for a reason: HDF allows the first dimension of a data set to be +# unlimited. This means the data can be appended too. Thus a NeXus file built according +# to the rules given above can be used in the following way: +# +# * At the start of a scan, write all the static information. +# * At each scan point, append new data from varied variables +# and the detector to the file. +# +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXspe.yaml b/applications/nyaml/NXspe.yaml new file mode 100644 index 0000000000..7dfb5be0a6 --- /dev/null +++ b/applications/nyaml/NXspe.yaml @@ -0,0 +1,128 @@ +category: application +doc: | + NXSPE Inelastic Format. Application definition for NXSPE file format. +type: group +NXspe(NXobject): + (NXentry): + program_name: + definition: + doc: | + Official NeXus NXDL schema to which this file conforms. + \@version: + enumeration: [NXspe] + (NXcollection)NXSPE_info: + fixed_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + The fixed energy used for this file. + ki_over_kf_scaling(NX_BOOLEAN): + doc: | + Indicates whether ki/kf scaling has been applied or not. + psi(NX_FLOAT): + unit: NX_ANGLE + doc: | + Orientation angle as expected in DCS-MSlice + (NXdata)data: + azimuthal(NX_FLOAT): + unit: NX_ANGLE + azimuthal_width(NX_FLOAT): + unit: NX_ANGLE + polar(NX_FLOAT): + unit: NX_ANGLE + polar_width(NX_FLOAT): + unit: NX_ANGLE + distance(NX_FLOAT): + unit: NX_LENGTH + data(NX_NUMBER): + error(NX_NUMBER): + energy(NX_FLOAT): + unit: NX_ENERGY + (NXinstrument): + name(NX_CHAR): + (NXfermi_chopper): + energy(NX_NUMBER): + unit: NX_ENERGY + (NXsample): + rotation_angle(NX_NUMBER): + unit: NX_ANGLE + seblock(NX_CHAR): + temperature(NX_NUMBER): + unit: NX_TEMPERATURE + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# eec08fb3a92ba08c09d8ecb18e13c7703abf71c6e532786d2685d1c7979e52b3 +# +# +# +# +# NXSPE Inelastic Format. Application definition for NXSPE file format. +# +# +# +# Official NeXus NXDL schema to which this file conforms. +# +# +# +# +# +# +# +# The fixed energy used for this file. +# +# +# Indicates whether ki/kf scaling has been applied or not. +# +# +# Orientation angle as expected in DCS-MSlice +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXsqom.yaml b/applications/nyaml/NXsqom.yaml new file mode 100644 index 0000000000..c29c5e622c --- /dev/null +++ b/applications/nyaml/NXsqom.yaml @@ -0,0 +1,211 @@ +category: application +doc: | + This is the application definition for S(Q,OM) processed data. + + As this kind of data is in + general not on a rectangular grid after data reduction, it is stored as Q,E positions plus their + intensity, table like. It is the task of a possible visualisation program to regrid this data in + a sensible way. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nP: | + Number of points +type: group +NXsqom(NXobject): + (NXentry): + \@entry: + title: + definition: + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXsqom] + (NXinstrument)instrument: + (NXsource): + type: + name: + probe: + enumeration: [neutron, x-ray, electron] + name(NX_CHAR): + doc: | + Name of the instrument from which this data was reduced. + (NXsample): + name: + doc: | + Descriptive name of sample + (NXprocess)reduction: + program(NX_CHAR): + version(NX_CHAR): + (NXparameters)input: + filenames(NX_CHAR): + doc: | + Raw data files used to generate this I(Q) + doc: | + Input parameters for the reduction program used + (NXparameters)output: + doc: | + Eventual output parameters from the data reduction program used + (NXdata): + data(NX_INT): + signal: 1 + doc: | + This is the intensity for each point in QE + dimensions: + rank: 1 + dim: [[1, nP]] + qx(NX_NUMBER): + axis: 1 + unit: NX_WAVENUMBER + doc: | + Positions for the first dimension of Q + dimensions: + rank: 1 + dim: [[1, nP]] + qy(NX_NUMBER): + axis: 1 + unit: NX_WAVENUMBER + doc: | + Positions for the the second dimension of Q + dimensions: + rank: 1 + dim: [[1, nP]] + qz(NX_NUMBER): + axis: 1 + unit: NX_WAVENUMBER + doc: | + Positions for the the third dimension of Q + dimensions: + rank: 1 + dim: [[1, nP]] + en(NX_FLOAT): + axis: 1 + unit: NX_ENERGY + doc: | + Values for the energy transfer for each point + dimensions: + rank: 1 + dim: [[1, nP]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# c4bc88346556a87d052d23ac72e3681fbbc83804dd30c5cf7656e54595f43e97 +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of points +# +# +# +# This is the application definition for S(Q,OM) processed data. +# +# As this kind of data is in +# general not on a rectangular grid after data reduction, it is stored as Q,E positions plus their +# intensity, table like. It is the task of a possible visualisation program to regrid this data in +# a sensible way. +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Name of the instrument from which this data was reduced. +# +# +# +# +# Descriptive name of sample +# +# +# +# +# +# +# +# Raw data files used to generate this I(Q) +# +# Input parameters for the reduction program used +# +# +# Eventual output parameters from the data reduction program used +# +# +# +# +# This is the intensity for each point in QE +# +# +# +# +# +# Positions for the first dimension of Q +# +# +# +# +# +# Positions for the the second dimension of Q +# +# +# +# +# +# Positions for the the third dimension of Q +# +# +# +# +# +# Values for the energy transfer for each point +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXstxm.yaml b/applications/nyaml/NXstxm.yaml new file mode 100644 index 0000000000..a2a6c1fc8b --- /dev/null +++ b/applications/nyaml/NXstxm.yaml @@ -0,0 +1,366 @@ +category: application +doc: | + Application definition for a STXM instrument. + + The interferometer + position measurements, monochromator photon energy values and + detector measurements are all treated as NXdetectors and stored + within the NXinstrument group as lists of values stored in + chronological order. The NXdata group then holds another version + of the data in a regular 3D array (NumE by NumY by NumX, for a + total of nP points in a sample image stack type scan). The former + data values should be stored with a minimum loss of precision, while + the latter values can be simplified and/or approximated in order to + fit the constraints of a regular 3D array. 'Line scans' and 'point spectra' + are just sample_image scan types with reduced dimensions in the same way + as single images have reduced E dimensions compared to image 'stacks'. +symbols: + doc: | + These symbols will be used below to coordinate the shapes of the datasets. + nP: | + Total number of scan points + nE: | + Number of photon energies scanned + nX: | + Number of pixels in X direction + nY: | + Number of pixels in Y direction + detectorRank: | + Rank of data array provided by the detector for a single measurement +type: group +NXstxm(NXobject): + (NXentry): + title: + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + definition(NX_CHAR): + exists: ['min', '1', 'max', '1'] + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXstxm] + (NXinstrument): + exists: ['min', '1', 'max', '1'] + (NXsource): + exists: ['min', '1', 'max', '1'] + type: + exists: ['min', '1', 'max', '1'] + name: + exists: ['min', '1', 'max', '1'] + probe: + exists: ['min', '1', 'max', '1'] + (NXmonochromator)monochromator: + exists: ['min', '1', 'max', '1'] + energy(NX_FLOAT): + exists: ['min', '1', 'max', '1'] + dimensions: + rank: 1 + dim: [[1, nP]] + (NXdetector): + exists: ['min', '1'] + data(NX_NUMBER): + dimensions: + rank: 1+detectorRank + doc: | + Detector data should be presented with the first dimension corresponding to the + scan point and subsequent dimensions corresponding to the output of the detector. + Detectors that provide more than one value per scan point should have + a data array of rank 1+d, where d is the dimensions of the array provided per + scan point. For example, an area detector should have an NXdetector data array + of 3 dimensions, with the first being the set of scan points and the latter + two being the x- and y- extent of the detector. + NOTE: For each dimension > 1 there must exist a dim section such as: + dim: [[1, nP]] + (NXdetector)sample_x: + exists: ['min', '0', 'max', '1'] + doc: | + Measurements of the sample position from the x-axis interferometer. + data(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, nP]] + (NXdetector)sample_y: + exists: ['min', '0', 'max', '1'] + doc: | + Measurements of the sample position from the y-axis interferometer. + data(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, nP]] + (NXdetector)sample_z: + exists: ['min', '0', 'max', '1'] + doc: | + Measurements of the sample position from the z-axis interferometer. + data(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, nP]] + (NXsample): + rotation_angle(NX_FLOAT): + (NXdata): + stxm_scan_type: + exists: ['min', '1', 'max', '1'] + doc: | + Label for typical scan types as a convenience for humans. + Each label corresponds to a specific set of axes being scanned + to produce a data array of shape: + + * sample point spectrum: (photon_energy,) + * sample line spectrum: (photon_energy, sample_y/sample_x) + * sample image: (sample_y, sample_x) + * sample image stack: (photon_energy, sample_y, sample_x) + * sample focus: (zoneplate_z, sample_y/sample_x) + * osa image: (osa_y, osa_x) + * osa focus: (zoneplate_z, osa_y/osa_x) + * detector image: (detector_y, detector_x) + + The "generic scan" string is to be used when none of the + other choices are appropriate. + enumeration: [sample point spectrum, sample line spectrum, sample image, sample image stack, sample focus, osa image, osa focus, detector image, generic scan] + data(NX_NUMBER): + signal: 1 + doc: | + Detectors that provide more than one value per scan point should be summarised + to a single value per scan point for this array in order to simplify plotting. + + Note that 'Line scans' and focus type scans measure along one spatial dimension + but are not restricted to being parallel to the X or Y axes. Such scans + should therefore use a single dimension for the positions along the spatial + line. The 'sample_x' and 'sample_y' fields should then contain lists of the + x- and y-positions and should both have the 'axis' attribute pointing to the same dimension. + energy(NX_FLOAT): + exists: ['min', '1', 'max', '1'] + doc: | + List of photon energies of the X-ray beam. If scanned through multiple values, + then an 'axis' attribute will be required to link the field to the appropriate data array dimension. + dimensions: + rank: 1 + dim: [[1, nE]] + sample_y(NX_FLOAT): + exists: ['min', '1', 'max', '1'] + doc: | + List of Y positions on the sample. If scanned through multiple values, + then an 'axis' attribute will be required to link the field to the appropriate data array dimension. + dimensions: + rank: 1 + dim: [[1, nY]] + sample_x(NX_FLOAT): + exists: ['min', '1', 'max', '1'] + doc: | + List of X positions on the sample. If scanned through multiple values, + then an 'axis' attribute will be required to link the field to the appropriate data array dimension. + dimensions: + rank: 1 + dim: [[1, nX]] + (NXmonitor)control: + exists: ['min', '0', 'max', '1'] + data(NX_FLOAT): + doc: | + Values to use to normalise for time-variations in photon flux. Typically, the synchrotron storage ring + electron beam current is used as a proxy for the X-ray beam intensity. Array must have same shape as the + NXdata groups. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 4a65935ad78db0a1652d7fceb67425791cfecf0a6a2f24683a5798f866c9d60c +# +# +# +# +# +# +# These symbols will be used below to coordinate the shapes of the datasets. +# +# +# Total number of scan points +# +# +# Number of photon energies scanned +# +# +# Number of pixels in X direction +# +# +# Number of pixels in Y direction +# +# +# Rank of data array provided by the detector for a single measurement +# +# +# +# Application definition for a STXM instrument. +# +# The interferometer +# position measurements, monochromator photon energy values and +# detector measurements are all treated as NXdetectors and stored +# within the NXinstrument group as lists of values stored in +# chronological order. The NXdata group then holds another version +# of the data in a regular 3D array (NumE by NumY by NumX, for a +# total of nP points in a sample image stack type scan). The former +# data values should be stored with a minimum loss of precision, while +# the latter values can be simplified and/or approximated in order to +# fit the constraints of a regular 3D array. 'Line scans' and 'point spectra' +# are just sample_image scan types with reduced dimensions in the same way +# as single images have reduced E dimensions compared to image 'stacks'. +# +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Detector data should be presented with the first dimension corresponding to the +# scan point and subsequent dimensions corresponding to the output of the detector. +# Detectors that provide more than one value per scan point should have +# a data array of rank 1+d, where d is the dimensions of the array provided per +# scan point. For example, an area detector should have an NXdetector data array +# of 3 dimensions, with the first being the set of scan points and the latter +# two being the x- and y- extent of the detector. +# NOTE: For each dimension > 1 there must exist a dim section such as: +# +# +# +# +# +# +# Measurements of the sample position from the x-axis interferometer. +# +# +# +# +# +# +# +# Measurements of the sample position from the y-axis interferometer. +# +# +# +# +# +# +# +# Measurements of the sample position from the z-axis interferometer. +# +# +# +# +# +# +# +# +# +# +# +# +# Label for typical scan types as a convenience for humans. +# Each label corresponds to a specific set of axes being scanned +# to produce a data array of shape: +# +# * sample point spectrum: (photon_energy,) +# * sample line spectrum: (photon_energy, sample_y/sample_x) +# * sample image: (sample_y, sample_x) +# * sample image stack: (photon_energy, sample_y, sample_x) +# * sample focus: (zoneplate_z, sample_y/sample_x) +# * osa image: (osa_y, osa_x) +# * osa focus: (zoneplate_z, osa_y/osa_x) +# * detector image: (detector_y, detector_x) +# +# The "generic scan" string is to be used when none of the +# other choices are appropriate. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Detectors that provide more than one value per scan point should be summarised +# to a single value per scan point for this array in order to simplify plotting. +# +# Note that 'Line scans' and focus type scans measure along one spatial dimension +# but are not restricted to being parallel to the X or Y axes. Such scans +# should therefore use a single dimension for the positions along the spatial +# line. The 'sample_x' and 'sample_y' fields should then contain lists of the +# x- and y-positions and should both have the 'axis' attribute pointing to the same dimension. +# +# +# List of photon energies of the X-ray beam. If scanned through multiple values, +# then an 'axis' attribute will be required to link the field to the appropriate data array dimension. +# +# +# +# +# +# List of Y positions on the sample. If scanned through multiple values, +# then an 'axis' attribute will be required to link the field to the appropriate data array dimension. +# +# +# +# +# +# List of X positions on the sample. If scanned through multiple values, +# then an 'axis' attribute will be required to link the field to the appropriate data array dimension. +# +# +# +# +# +# +# +# Values to use to normalise for time-variations in photon flux. Typically, the synchrotron storage ring +# electron beam current is used as a proxy for the X-ray beam intensity. Array must have same shape as the +# NXdata groups. +# +# +# +# diff --git a/applications/nyaml/NXtas.yaml b/applications/nyaml/NXtas.yaml new file mode 100644 index 0000000000..8e734d65c4 --- /dev/null +++ b/applications/nyaml/NXtas.yaml @@ -0,0 +1,350 @@ +category: application +doc: | + This is an application definition for a triple axis spectrometer. + + It is for the trademark scan of the TAS, the Q-E scan. + For your alignment scans use the rules in :ref:`NXscan`. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nP: | + Number of points +type: group +NXtas(NXobject): + (NXentry)entry: + title(NX_CHAR): + start_time(NX_DATE_TIME): + definition: + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXtas] + (NXinstrument): + (NXsource): + name: + probe: + enumeration: [neutron, x-ray] + (NXcrystal)monochromator: + ei(NX_FLOAT): + unit: NX_ENERGY + axis: 1 + dimensions: + rank: 1 + dim: [[1, nP]] + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + dimensions: + rank: 1 + dim: [[1, nP]] + (NXcrystal)analyser: + ef(NX_FLOAT): + unit: NX_ENERGY + axis: 1 + dimensions: + rank: 1 + dim: [[1, nP]] + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + dimensions: + rank: 1 + dim: [[1, nP]] + polar_angle(NX_FLOAT): + unit: NX_ANGLE + dimensions: + rank: 1 + dim: [[1, nP]] + (NXdetector): + data(NX_INT): + signal: 1 + dimensions: + rank: 1 + dim: [[1, nP]] + polar_angle(NX_FLOAT): + unit: NX_ANGLE + dimensions: + rank: 1 + dim: [[1, nP]] + (NXsample): + name: + doc: | + Descriptive name of sample + qh(NX_FLOAT): + unit: NX_DIMENSIONLESS + axis: 1 + dimensions: + rank: 1 + dim: [[1, nP]] + qk(NX_FLOAT): + unit: NX_DIMENSIONLESS + axis: 1 + dimensions: + rank: 1 + dim: [[1, nP]] + ql(NX_FLOAT): + unit: NX_DIMENSIONLESS + axis: 1 + dimensions: + rank: 1 + dim: [[1, nP]] + en(NX_FLOAT): + unit: NX_ENERGY + axis: 1 + dimensions: + rank: 1 + dim: [[1, nP]] + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + dimensions: + rank: 1 + dim: [[1, nP]] + polar_angle(NX_FLOAT): + unit: NX_ANGLE + dimensions: + rank: 1 + dim: [[1, nP]] + sgu(NX_FLOAT): + unit: NX_ANGLE + dimensions: + rank: 1 + dim: [[1, nP]] + sgl(NX_FLOAT): + unit: NX_ANGLE + dimensions: + rank: 1 + dim: [[1, nP]] + unit_cell(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 6]] + orientation_matrix(NX_FLOAT): + unit: NX_DIMENSIONLESS + dimensions: + rank: 1 + dim: [[1, 9]] + (NXmonitor): + mode: + doc: | + Count to a preset value based on either clock time (timer) + or received monitor counts (monitor). + enumeration: [monitor, timer] + preset(NX_FLOAT): + doc: | + preset value for time or monitor + data(NX_FLOAT): + unit: NX_ANY + doc: | + Total integral monitor counts + dimensions: + rank: 1 + dim: [[1, nP]] + (NXdata): + doc: | + One of the ei,ef,qh,qk,ql,en should get a primary=1 attribute to denote the main scan axis + ei(link): + target: /NXentry/NXinstrument/monochromator:NXcrystal/ei + ef(link): + target: /NXentry/NXinstrument/analyser:NXcrystal/ef + en(link): + target: /NXentry/NXsample/en + qh(link): + target: /NXentry/NXsample/qh + qk(link): + target: /NXentry/NXsample/qk + ql(link): + target: /NXentry/NXsample/ql + data(link): + target: /NXentry/NXinstrument/NXdetector/data + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 3e1396fcfde956ea2d5e48260644bed60a7bf6a088df0c0b5d9928c3fae99fa0 +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of points +# +# +# +# This is an application definition for a triple axis spectrometer. +# +# It is for the trademark scan of the TAS, the Q-E scan. +# For your alignment scans use the rules in :ref:`NXscan`. +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Count to a preset value based on either clock time (timer) +# or received monitor counts (monitor). +# +# +# +# +# +# +# +# preset value for time or monitor +# +# +# Total integral monitor counts +# +# +# +# +# +# One of the ei,ef,qh,qk,ql,en should get a primary=1 attribute to denote the main scan axis +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXtofnpd.yaml b/applications/nyaml/NXtofnpd.yaml new file mode 100644 index 0000000000..29927992f3 --- /dev/null +++ b/applications/nyaml/NXtofnpd.yaml @@ -0,0 +1,233 @@ +category: application +doc: | + This is a application definition for raw data from a TOF neutron powder diffractometer +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nDet: | + Number of detectors + nTimeChan: | + nTimeChan description +type: group +NXtofnpd(NXobject): + (NXentry)entry: + title: + start_time(NX_DATE_TIME): + definition: + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXtofnpd] + pre_sample_flightpath(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the flight path before the sample position. This can be determined by a chopper, + by the moderator or the source itself. In other words: it the distance to the component + which gives the T0 signal to the detector electronics. If another component in the + NXinstrument hierarchy provides this information, this should be a link. + (NXuser)user: + name(NX_CHAR): + (NXinstrument): + (NXdetector)detector: + data(NX_INT): + signal: 1 + dimensions: + rank: 2 + dim: [[1, nDet], [2, nTimeChan]] + detector_number(NX_INT): + axis: 2 + dimensions: + rank: 1 + dim: [[1, nDet]] + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + distance to sample for each detector + dimensions: + rank: 1 + dim: [[1, nDet]] + time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + axis: 1 + dimensions: + rank: 1 + dim: [[1, nTimeChan]] + polar_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + polar angle for each detector element + dimensions: + rank: 1 + dim: [[1, nDet]] + azimuthal_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + azimuthal angle for each detector element + dimensions: + rank: 1 + dim: [[1, nDet]] + (NXsample): + name: + doc: | + Descriptive name of sample + (NXmonitor): + mode: + doc: | + Count to a preset value based on either clock time (timer) + or received monitor counts (monitor). + enumeration: [monitor, timer] + preset(NX_FLOAT): + doc: | + preset value for time or monitor + distance(NX_FLOAT): + unit: NX_LENGTH + data(NX_INT): + signal: 1 + dimensions: + rank: 1 + dim: [[1, nTimeChan]] + time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + axis: 1 + dimensions: + rank: 1 + dim: [[1, nTimeChan]] + (NXdata)data: + data(link): + target: /NXentry/NXinstrument/NXdetector/data + detector_number(link): + target: /NXentry/NXinstrument/NXdetector/detector_number + time_of_flight(link): + target: /NXentry/NXinstrument/NXdetector/time_of_flight + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 76efa47955dd8ce499a361753ff2a4da1b9c9771c4cbfff8d5def96ed4ca69bd +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of detectors +# +# +# nTimeChan description +# +# +# This is a application definition for raw data from a TOF neutron powder diffractometer +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# This is the flight path before the sample position. This can be determined by a chopper, +# by the moderator or the source itself. In other words: it the distance to the component +# which gives the T0 signal to the detector electronics. If another component in the +# NXinstrument hierarchy provides this information, this should be a link. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# distance to sample for each detector +# +# +# +# +# +# +# +# polar angle for each detector element +# +# +# +# +# azimuthal angle for each detector element +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# +# +# Count to a preset value based on either clock time (timer) +# or received monitor counts (monitor). +# +# +# +# +# +# +# +# preset value for time or monitor +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXtofraw.yaml b/applications/nyaml/NXtofraw.yaml new file mode 100644 index 0000000000..0f3547c556 --- /dev/null +++ b/applications/nyaml/NXtofraw.yaml @@ -0,0 +1,255 @@ +category: application +doc: | + This is an application definition for raw data from a generic TOF instrument +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nDet: | + Number of detectors + nTimeChan: | + nTimeChan description +type: group +NXtofraw(NXobject): + (NXentry)entry: + title: + start_time(NX_DATE_TIME): + definition: + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXtofraw] + duration(NX_FLOAT): + run_number(NX_INT): + pre_sample_flightpath(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the flight path before the sample position. This can be determined by a chopper, + by the moderator, or the source itself. In other words: it is the distance to the component + which gives the T0 signal to the detector electronics. If another component in the + NXinstrument hierarchy provides this information, this should be a link. + (NXuser)user: + name(NX_CHAR): + (NXinstrument)instrument: + (NXdetector)detector: + data(NX_INT): + signal: 1 + dimensions: + rank: 2 + dim: [[1, nDet], [2, nTimeChan]] + detector_number(NX_INT): + axis: 2 + dimensions: + rank: 1 + dim: [[1, nDet]] + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + distance to sample for each detector + dimensions: + rank: 1 + dim: [[1, nDet]] + time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + axis: 1 + dimensions: + rank: 1 + dim: [[1, nTimeChan]] + polar_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + polar angle for each detector element + dimensions: + rank: 1 + dim: [[1, nDet]] + azimuthal_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + azimuthal angle for each detector element + dimensions: + rank: 1 + dim: [[1, nDet]] + (NXsample): + name: + doc: | + Descriptive name of sample + nature(NX_CHAR): + enumeration: [powder, liquid, single crystal] + (NXmonitor): + mode: + doc: | + Count to a preset value based on either clock time (timer) + or received monitor counts (monitor). + enumeration: [monitor, timer] + preset(NX_FLOAT): + doc: | + preset value for time or monitor + distance(NX_FLOAT): + unit: NX_LENGTH + data(NX_INT): + signal: 1 + dimensions: + rank: 1 + dim: [[1, nTimeChan]] + time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + axis: 1 + dimensions: + rank: 1 + dim: [[1, nTimeChan]] + integral_counts(NX_INT): + unit: NX_UNITLESS + (NXdata)data: + data(link): + target: /NXentry/NXinstrument/NXdetector/data + detector_number(link): + target: /NXentry/NXinstrument/NXdetector/detector_number + time_of_flight(link): + target: /NXentry/NXinstrument/NXdetector/time_of_flight + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# cf876130ab5b69d23c8694bdbbcb43d81f4121e37e52467668853246ecdbecf4 +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of detectors +# +# +# nTimeChan description +# +# +# This is an application definition for raw data from a generic TOF instrument +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# This is the flight path before the sample position. This can be determined by a chopper, +# by the moderator, or the source itself. In other words: it is the distance to the component +# which gives the T0 signal to the detector electronics. If another component in the +# NXinstrument hierarchy provides this information, this should be a link. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# distance to sample for each detector +# +# +# +# +# +# +# +# +# +# +# polar angle for each detector element +# +# +# +# +# +# azimuthal angle for each detector element +# +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# +# +# +# +# +# +# +# +# Count to a preset value based on either clock time (timer) +# or received monitor counts (monitor). +# +# +# +# +# +# +# +# preset value for time or monitor +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXtofsingle.yaml b/applications/nyaml/NXtofsingle.yaml new file mode 100644 index 0000000000..31eacdc3d2 --- /dev/null +++ b/applications/nyaml/NXtofsingle.yaml @@ -0,0 +1,244 @@ +category: application +doc: | + This is a application definition for raw data from a generic TOF instrument +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + xSize: | + xSize description + ySize: | + ySize description + nDet: | + Number of detectors + nTimeChan: | + nTimeChan description +type: group +NXtofsingle(NXobject): + (NXentry)entry: + title: + start_time(NX_DATE_TIME): + definition: + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXtofsingle] + duration(NX_FLOAT): + pre_sample_flightpath(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the flight path before the sample position. This can be determined by a chopper, + by the moderator or the source itself. In other words: it the distance to the component + which gives the T0 signal to the detector electronics. If another component in the + NXinstrument hierarchy provides this information, this should be a link. + (NXuser)user: + name(NX_CHAR): + (NXinstrument): + (NXdetector)detector: + data(NX_INT): + signal: 1 + dimensions: + rank: 3 + dim: [[1, xSize], [2, ySize], [3, nTimeChan]] + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + Distance to sample for the center of the detector + dimensions: + rank: 1 + dim: [[1, 1]] + time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + axis: 1 + dimensions: + rank: 1 + dim: [[1, nTimeChan]] + polar_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + polar angle for each detector element + dimensions: + rank: 1 + dim: [[1, nDet]] + azimuthal_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + azimuthal angle for each detector element + dimensions: + rank: 1 + dim: [[1, nDet]] + (NXsample): + name: + doc: | + Descriptive name of sample + nature(NX_CHAR): + enumeration: [powder, liquid, single crystal] + (NXmonitor): + mode: + doc: | + Count to a preset value based on either clock time (timer) + or received monitor counts (monitor). + enumeration: [monitor, timer] + preset(NX_FLOAT): + doc: | + preset value for time or monitor + distance(NX_FLOAT): + unit: NX_LENGTH + data(NX_INT): + signal: 1 + dimensions: + rank: 1 + dim: [[1, nTimeChan]] + time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + axis: 1 + dimensions: + rank: 1 + dim: [[1, nTimeChan]] + (NXdata)data: + data(link): + target: /NXentry/NXinstrument/NXdetector/data + time_of_flight(link): + target: /NXentry/NXinstrument/NXdetector/time_of_flight + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 68f4d548d9d5116bbd6e38aa5ed5230e7ac8f1f0dcb70edc3aceb398ea4983d0 +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# xSize description +# +# +# ySize description +# +# +# Number of detectors +# +# +# nTimeChan description +# +# +# This is a application definition for raw data from a generic TOF instrument +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# This is the flight path before the sample position. This can be determined by a chopper, +# by the moderator or the source itself. In other words: it the distance to the component +# which gives the T0 signal to the detector electronics. If another component in the +# NXinstrument hierarchy provides this information, this should be a link. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Distance to sample for the center of the detector +# +# +# +# +# +# +# +# polar angle for each detector element +# +# +# +# +# azimuthal angle for each detector element +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# +# +# +# +# +# +# +# +# Count to a preset value based on either clock time (timer) +# or received monitor counts (monitor). +# +# +# +# +# +# +# +# preset value for time or monitor +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXtomo.yaml b/applications/nyaml/NXtomo.yaml new file mode 100644 index 0000000000..8ec340419e --- /dev/null +++ b/applications/nyaml/NXtomo.yaml @@ -0,0 +1,279 @@ +category: application +doc: | + This is the application definition for x-ray or neutron tomography raw data. + + In tomography + a number of dark field images are measured, some bright field images and, of course the sample. + In order to distinguish between them images carry a image_key. +symbols: + doc: | + These symbols will be used below to coordinate datasets with the same shape. + nFrames: | + Number of frames + xSize: | + Number of pixels in X direction + ySize: | + Number of pixels in Y direction +type: group +NXtomo(NXobject): + (NXentry)entry: + title: + exists: ['min', '0', 'max', '1'] + start_time(NX_DATE_TIME): + exists: ['min', '0', 'max', '1'] + end_time(NX_DATE_TIME): + exists: ['min', '0', 'max', '1'] + definition: + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXtomo] + (NXinstrument)instrument: + (NXsource): + exists: ['min', '0', 'max', '1'] + type: + exists: ['min', '0', 'max', '1'] + name: + exists: ['min', '0', 'max', '1'] + probe: + exists: ['min', '0', 'max', '1'] + enumeration: [neutron, x-ray, electron] + (NXdetector)detector: + data(NX_INT): + signal: 1 + dimensions: + rank: 3 + dim: [[1, nFrames], [2, xSize], [3, ySize]] + image_key(NX_INT): + doc: | + In order + to distinguish between sample projections, dark and flat + images, a magic number is recorded per frame. + The key is as follows: + + * projection = 0 + * flat field = 1 + * dark field = 2 + * invalid = 3 + dimensions: + rank: 1 + dim: [[1, nFrames]] + x_pixel_size(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + y_pixel_size(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + distance(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + doc: | + Distance between detector and sample + x_rotation_axis_pixel_position(NX_FLOAT): + exists: ['min', '0', 'max', '1'] + y_rotation_axis_pixel_position(NX_FLOAT): + exists: ['min', '0', 'max', '1'] + (NXsample)sample: + name: + doc: | + Descriptive name of sample + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + axis: 1 + doc: | + In practice this axis is always aligned along one pixel direction on the detector and usually vertical. + There are experiments with horizontal rotation axes, so this would need to be indicated somehow. + For now the best way for that is an open question. + dimensions: + rank: 1 + dim: [[1, nFrames]] + x_translation(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + dimensions: + rank: 1 + dim: [[1, nFrames]] + y_translation(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + dimensions: + rank: 1 + dim: [[1, nFrames]] + z_translation(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + dimensions: + rank: 1 + dim: [[1, nFrames]] + (NXmonitor)control: + exists: ['min', '0', 'max', '1'] + data(NX_FLOAT): + unit: NX_ANY + doc: | + Total integral monitor counts for each measured frame. Allows a to correction for + fluctuations in the beam between frames. + dimensions: + rank: 1 + dim: [[1, nFrames]] + (NXdata)data: + data(link): + target: /NXentry/NXinstrument/detector:NXdetector/data + rotation_angle(link): + target: /NXentry/NXsample/rotation_angle + image_key(link): + target: /NXentry/NXinstrument/detector:NXdetector/image_key + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 2ddef81db80e94c71e2fd772d74cfdae6cf00b895087e66b9e346d23a86fbc72 +# +# +# +# +# +# +# These symbols will be used below to coordinate datasets with the same shape. +# +# +# Number of frames +# +# +# Number of pixels in X direction +# +# +# Number of pixels in Y direction +# +# +# +# This is the application definition for x-ray or neutron tomography raw data. +# +# In tomography +# a number of dark field images are measured, some bright field images and, of course the sample. +# In order to distinguish between them images carry a image_key. +# +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# In order +# to distinguish between sample projections, dark and flat +# images, a magic number is recorded per frame. +# The key is as follows: +# +# * projection = 0 +# * flat field = 1 +# * dark field = 2 +# * invalid = 3 +# +# +# +# +# +# +# +# +# Distance between detector and sample +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# In practice this axis is always aligned along one pixel direction on the detector and usually vertical. +# There are experiments with horizontal rotation axes, so this would need to be indicated somehow. +# For now the best way for that is an open question. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Total integral monitor counts for each measured frame. Allows a to correction for +# fluctuations in the beam between frames. +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXtomophase.yaml b/applications/nyaml/NXtomophase.yaml new file mode 100644 index 0000000000..7ef44c6a21 --- /dev/null +++ b/applications/nyaml/NXtomophase.yaml @@ -0,0 +1,292 @@ +category: application +doc: | + This is the application definition for x-ray or neutron tomography raw data with phase contrast variation at each point. + + In tomography first + some dark field images are measured, some bright field images and, of course the sample. In order + to properly sort the order of the images taken, a sequence number is stored with each image. +symbols: + doc: | + These symbols will be used below to coordinate datasets with the same shape. + nBrightFrames: | + Number of bright frames + nDarkFrames: | + Number of dark frames + nSampleFrames: | + Number of image (sample) frames + nPhase: | + Number of phase settings + xSize: | + Number of pixels in X direction + ySize: | + Number of pixels in Y direction +type: group +NXtomophase(NXobject): + (NXentry)entry: + title: + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + definition: + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXtomophase] + (NXinstrument)instrument: + (NXsource): + type: + name: + probe: + enumeration: [neutron, x-ray, electron] + (NXdetector)bright_field: + data(NX_INT): + signal: 1 + dimensions: + rank: 3 + dim: [[1, nBrightFrames], [2, xSize], [3, ySize]] + sequence_number(NX_INT): + dimensions: + rank: 1 + dim: [[1, nBrightFrames]] + (NXdetector)dark_field: + data(NX_INT): + signal: 1 + dimensions: + rank: 3 + dim: [[1, nDarkFrames], [2, xSize], [3, ySize]] + sequence_number(NX_INT): + dimensions: + rank: 1 + dim: [[1, nDarkFrames]] + (NXdetector)sample: + data(NX_INT): + signal: 1 + dimensions: + rank: 4 + dim: [[1, nSampleFrames], [2, nPhase], [3, xSize], [4, ySize]] + sequence_number(NX_INT): + dimensions: + rank: 2 + dim: [[1, nSampleFrames], [2, nPhase]] + x_pixel_size(NX_FLOAT): + unit: NX_LENGTH + y_pixel_size(NX_FLOAT): + unit: NX_LENGTH + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + Distance between detector and sample + (NXsample)sample: + name: + doc: | + Descriptive name of sample + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + axis: 1 + dimensions: + rank: 1 + dim: [[1, nSampleFrames]] + x_translation(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, nSampleFrames]] + y_translation(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, nSampleFrames]] + z_translation(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, nSampleFrames]] + (NXmonitor)control: + integral(NX_FLOAT): + unit: NX_ANY + doc: | + Total integral monitor counts for each measured frame. Allows a correction for + fluctuations in the beam between frames. + dimensions: + rank: 1 + + # TODO: nPhase? + dim: [[1, nDarkFrames + nBrightFrames + nSampleFrame]] + (NXdata)data: + data(link): + target: /NXentry/NXinstrument/sample:NXdetector/data + rotation_angle(link): + target: /NXentry/NXsample/rotation_angle + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 61792a668d325a2c70187730d3457c9ee8aba24ca55e9405ee1dd4d29f7d2296 +# +# +# +# +# +# These symbols will be used below to coordinate datasets with the same shape. +# +# Number of bright frames +# +# +# Number of dark frames +# +# +# Number of image (sample) frames +# +# +# Number of phase settings +# +# +# Number of pixels in X direction +# +# +# Number of pixels in Y direction +# +# +# +# This is the application definition for x-ray or neutron tomography raw data with phase contrast variation at each point. +# +# In tomography first +# some dark field images are measured, some bright field images and, of course the sample. In order +# to properly sort the order of the images taken, a sequence number is stored with each image. +# +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Distance between detector and sample +# +# +# +# +# +# Descriptive name of sample +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Total integral monitor counts for each measured frame. Allows a correction for +# fluctuations in the beam between frames. +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXtomoproc.yaml b/applications/nyaml/NXtomoproc.yaml new file mode 100644 index 0000000000..48ba4c9e04 --- /dev/null +++ b/applications/nyaml/NXtomoproc.yaml @@ -0,0 +1,217 @@ +category: application +doc: | + This is an application definition for the final result of a tomography experiment: a 3D construction of some volume of physical properties. +symbols: + doc: | + These symbols will be used below to coordinate datasets with the same shape. + nX: | + Number of voxels in X direction + nY: | + Number of voxels in Y direction + nZ: | + Number of voxels in Z direction +type: group +NXtomoproc(NXobject): + (NXentry)entry: + title: + definition: + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXtomoproc] + (NXinstrument): + (NXsource): + type: + name: + probe: + enumeration: [neutron, x-ray, electron] + (NXsample): + name: + doc: | + Descriptive name of sample + (NXprocess)reconstruction: + program(NX_CHAR): + doc: | + Name of the program used for reconstruction + version(NX_CHAR): + doc: | + Version of the program used + date(NX_DATE_TIME): + doc: | + Date and time of reconstruction processing. + (NXparameters)parameters: + raw_file(NX_CHAR): + doc: | + Original raw data file this data was derived from + (NXdata)data: + data(NX_INT): + signal: 1 + doc: | + This is the reconstructed volume. This can be different + things. Please indicate in the unit attribute what physical + quantity this really is. + dimensions: + rank: 3 + dim: [[1, nX], [2, nX], [3, nZ]] + \@transform: + \@offset: + \@scaling: + x(NX_FLOAT): + unit: NX_ANY + axis: 1 + doc: | + This is an array holding the values to use for the x-axis of + data. The units must be appropriate for the measurement. + dimensions: + rank: 1 + dim: [[1, nX]] + y(NX_FLOAT): + unit: NX_ANY + axis: 2 + doc: | + This is an array holding the values to use for the y-axis of + data. The units must be appropriate for the measurement. + dimensions: + rank: 1 + dim: [[1, nY]] + z(NX_FLOAT): + unit: NX_ANY + axis: 3 + doc: | + This is an array holding the values to use for the z-axis of + data. The units must be appropriate for the measurement. + dimensions: + rank: 1 + dim: [[1, nZ]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# f0f55737027dae413b76cbb267a0d0021482dfdf9d398c0886e5d5b4e8c8bca1 +# +# +# +# +# +# These symbols will be used below to coordinate datasets with the same shape. +# +# Number of voxels in X direction +# +# +# Number of voxels in Y direction +# +# +# Number of voxels in Z direction +# +# +# This is an application definition for the final result of a tomography experiment: a 3D construction of some volume of physical properties. +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# +# Name of the program used for reconstruction +# +# +# Version of the program used +# +# +# Date and time of reconstruction processing. +# +# +# +# Original raw data file this data was derived from +# +# +# +# +# +# +# This is the reconstructed volume. This can be different +# things. Please indicate in the unit attribute what physical +# quantity this really is. +# +# +# +# +# +# +# +# +# +# +# +# +# This is an array holding the values to use for the x-axis of +# data. The units must be appropriate for the measurement. +# +# +# +# +# +# +# +# This is an array holding the values to use for the y-axis of +# data. The units must be appropriate for the measurement. +# +# +# +# +# +# +# +# This is an array holding the values to use for the z-axis of +# data. The units must be appropriate for the measurement. +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXxas.yaml b/applications/nyaml/NXxas.yaml new file mode 100644 index 0000000000..865c953dce --- /dev/null +++ b/applications/nyaml/NXxas.yaml @@ -0,0 +1,212 @@ +category: application +doc: | + This is an application definition for raw data from an X-ray absorption spectroscopy experiment. + + This is essentially a scan on energy versus incoming/ + absorbed beam. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nP: | + Number of points +type: group +NXxas(NXobject): + (NXentry): + \@entry: + doc: | + NeXus convention is to use "entry1", "entry2", ... + for analysis software to locate each entry. + title: + start_time(NX_DATE_TIME): + definition: + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXxas] + (NXinstrument): + (NXsource): + type: + name: + probe: + enumeration: [x-ray] + (NXmonochromator)monochromator: + energy(NX_FLOAT): + axis: 1 + dimensions: + rank: 1 + dim: [[1, nP]] + (NXdetector)incoming_beam: + data(NX_NUMBER): + dimensions: + rank: 1 + dim: [[1, nP]] + (NXdetector)absorbed_beam: + data(NX_NUMBER): + doc: | + This data corresponds to the sample signal. + dimensions: + rank: 1 + dim: [[1, nP]] + (NXsample): + name: + doc: | + Descriptive name of sample + (NXmonitor): + mode: + doc: | + Count to a preset value based on either clock time (timer) + or received monitor counts (monitor). + enumeration: [monitor, timer] + preset(NX_FLOAT): + doc: | + preset value for time or monitor + data(NX_NUMBER): + doc: | + This field could be a link to ``/NXentry/NXinstrument/incoming_beam:NXdetector/data`` + dimensions: + rank: 1 + dim: [[1, nP]] + (NXdata): + energy(link): + target: /NXentry/NXinstrument/monochromator:NXmonochromator/energy + absorbed_beam(link): + target: /NXentry/NXinstrument/absorbed_beam:NXdetector/data + mode: + doc: | + Detection method used for observing the sample absorption (pick one from the enumerated list and spell exactly) + enumeration: [Total Electron Yield, Partial Electron Yield, Auger Electron Yield, Fluorescence Yield, Transmission] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 2d5aaca6043db70d6315aaf4b2fbd9cc9e75ce43f1f2103fd79fdb9c11e36f4d +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of points +# +# +# +# This is an application definition for raw data from an X-ray absorption spectroscopy experiment. +# +# This is essentially a scan on energy versus incoming/ +# absorbed beam. +# +# +# +# +# NeXus convention is to use "entry1", "entry2", ... +# for analysis software to locate each entry. +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# This data corresponds to the sample signal. +# +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# +# +# Count to a preset value based on either clock time (timer) +# or received monitor counts (monitor). +# +# +# +# +# +# +# +# preset value for time or monitor +# +# +# This field could be a link to ``/NXentry/NXinstrument/incoming_beam:NXdetector/data`` +# +# +# +# +# +# +# +# +# +# Detection method used for observing the sample absorption (pick one from the enumerated list and spell exactly) +# +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXxasproc.yaml b/applications/nyaml/NXxasproc.yaml new file mode 100644 index 0000000000..111d6699bc --- /dev/null +++ b/applications/nyaml/NXxasproc.yaml @@ -0,0 +1,147 @@ +category: application +doc: | + Processed data from XAS. This is energy versus I(incoming)/I(absorbed). +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nP: | + Number of points +type: group +NXxasproc(NXobject): + (NXentry): + \@entry: + doc: | + NeXus convention is to use "entry1", "entry2", ... + for analysis software to locate each entry. + title: + definition: + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXxasproc] + (NXsample): + name: + doc: | + Descriptive name of sample + (NXprocess)XAS_data_reduction: + program(NX_CHAR): + doc: | + Name of the program used for reconstruction + version(NX_CHAR): + doc: | + Version of the program used + date(NX_DATE_TIME): + doc: | + Date and time of reconstruction processing. + (NXparameters)parameters: + raw_file(NX_CHAR): + doc: | + Original raw data file this data was derived from + (NXdata): + energy: + axis: 1 + dimensions: + rank: 1 + dim: [[1, nP]] + data(NX_FLOAT): + doc: | + This is corrected and calibrated I(incoming)/I(absorbed). So it is the absorption. + Expect attribute ``signal=1`` + dimensions: + rank: 1 + dim: [[1, nP]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 07a20126249a01bd8a1d5b7cf0796baf16f8dd148bcddc87d976c77baa89e00c +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of points +# +# +# +# Processed data from XAS. This is energy versus I(incoming)/I(absorbed). +# +# +# +# +# NeXus convention is to use "entry1", "entry2", ... +# for analysis software to locate each entry. +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# +# Name of the program used for reconstruction +# +# +# Version of the program used +# +# +# Date and time of reconstruction processing. +# +# +# +# Original raw data file this data was derived from +# +# +# +# +# +# +# +# +# +# +# +# This is corrected and calibrated I(incoming)/I(absorbed). So it is the absorption. +# Expect attribute ``signal=1`` +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXxbase.yaml b/applications/nyaml/NXxbase.yaml new file mode 100644 index 0000000000..46db086841 --- /dev/null +++ b/applications/nyaml/NXxbase.yaml @@ -0,0 +1,308 @@ +category: application +doc: | + This definition covers the common parts of all monochromatic single crystal raw data application definitions. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nP: | + Number of points + nXPixels: | + Number of X pixels + nYPixels: | + Number of Y pixels +type: group +NXxbase(NXobject): + (NXentry)entry: + title: + start_time(NX_DATE_TIME): + definition: + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXxbase] + (NXinstrument)instrument: + (NXsource)source: + type: + name: + probe: + enumeration: [neutron, x-ray, electron] + (NXmonochromator)monochromator: + wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + (NXdetector)detector: + exists: ['max', 'unbounded'] + data(NX_INT): + signal: 1 + doc: | + The area detector data, the first dimension is always the + number of scan points, the second and third are the number + of pixels in x and y. The origin is always assumed to be + in the center of the detector. maxOccurs is limited to the + the number of detectors on your instrument. + dimensions: + rank: 3 + dim: [[1, nP], [2, nXPixels], [3, nYPixels]] + \@signal: + type: NX_POSINT + enumeration: [1] + x_pixel_size(NX_FLOAT): + unit: NX_LENGTH + y_pixel_size(NX_FLOAT): + unit: NX_LENGTH + doc: | + The name of the group is detector if there is only one detector, + if there are several, names have to be detector1, + detector2, ...detectorn. + distance(NX_FLOAT): + unit: NX_LENGTH + frame_start_number(NX_INT): + doc: | + This is the start number of the first frame of a scan. In PX one often scans a couple + of frames on a give sample, then does something else, then returns to the same sample + and scans some more frames. Each time with a new data file. + This number helps concatenating such measurements. + (NXsample)sample: + name(NX_CHAR): + doc: | + Descriptive name of sample + orientation_matrix(NX_FLOAT): + doc: | + The orientation matrix according to Busing and + Levy conventions. This is not strictly necessary as + the UB can always be derived from the data. But + let us bow to common usage which includes the + UB nearly always. + dimensions: + rank: 2 + dim: [[1, 3], [2, 3]] + unit_cell(NX_FLOAT): + doc: | + The unit cell, a, b, c, alpha, beta, gamma. + Again, not strictly necessary, but normally written. + dimensions: + rank: 1 + dim: [[1, 6]] + temperature(NX_FLOAT): + doc: | + The sample temperature or whatever sensor represents this value best + dimensions: + rank: 1 + dim: [[1, nP]] + x_translation(NX_FLOAT): + unit: NX_LENGTH + doc: | + Translation of the sample along the X-direction of the laboratory coordinate system + y_translation(NX_FLOAT): + unit: NX_LENGTH + doc: | + Translation of the sample along the Y-direction of the laboratory coordinate system + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + Translation of the sample along the Z-direction of the laboratory coordinate system + (NXmonitor)control: + mode: + doc: | + Count to a preset value based on either clock time (timer) + or received monitor counts (monitor). + enumeration: [monitor, timer] + preset(NX_FLOAT): + doc: | + preset value for time or monitor + integral(NX_FLOAT): + unit: NX_ANY + doc: | + Total integral monitor counts + (NXdata): + doc: | + The name of this group id data if there is only + one detector; if there are several the names will + be data1, data2, data3 and will point + to the corresponding detector groups in the + instrument hierarchy. + data(link): + target: /NXentry/NXinstrument/NXdetector/data + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 97c93a3c48735ce7430e1e80498bae3276fa68441c19151174bc943af9503be3 +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of points +# +# +# Number of X pixels +# +# +# Number of Y pixels +# +# +# +# This definition covers the common parts of all monochromatic single crystal raw data application definitions. +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The area detector data, the first dimension is always the +# number of scan points, the second and third are the number +# of pixels in x and y. The origin is always assumed to be +# in the center of the detector. maxOccurs is limited to the +# the number of detectors on your instrument. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The name of the group is detector if there is only one detector, +# if there are several, names have to be detector1, +# detector2, ...detectorn. +# +# +# +# This is the start number of the first frame of a scan. In PX one often scans a couple +# of frames on a give sample, then does something else, then returns to the same sample +# and scans some more frames. Each time with a new data file. +# This number helps concatenating such measurements. +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# The orientation matrix according to Busing and +# Levy conventions. This is not strictly necessary as +# the UB can always be derived from the data. But +# let us bow to common usage which includes the +# UB nearly always. +# +# +# +# +# +# +# +# +# The unit cell, a, b, c, alpha, beta, gamma. +# Again, not strictly necessary, but normally written. +# +# +# +# +# +# +# +# The sample temperature or whatever sensor represents this value best +# +# +# +# +# +# +# Translation of the sample along the X-direction of the laboratory coordinate system +# +# +# Translation of the sample along the Y-direction of the laboratory coordinate system +# +# +# Translation of the sample along the Z-direction of the laboratory coordinate system +# +# +# +# +# +# +# Count to a preset value based on either clock time (timer) +# or received monitor counts (monitor). +# +# +# +# +# +# +# +# preset value for time or monitor +# +# +# Total integral monitor counts +# +# +# +# +# The name of this group id data if there is only +# one detector; if there are several the names will +# be data1, data2, data3 and will point +# to the corresponding detector groups in the +# instrument hierarchy. +# +# +# +# +# diff --git a/applications/nyaml/NXxeuler.yaml b/applications/nyaml/NXxeuler.yaml new file mode 100644 index 0000000000..103128c2dc --- /dev/null +++ b/applications/nyaml/NXxeuler.yaml @@ -0,0 +1,173 @@ +category: application +doc: | + raw data from a :index:`four-circle diffractometer` with an :index:`eulerian cradle`, extends :ref:`NXxbase` + + It extends :ref:`NXxbase`, so the full definition is the content + of :ref:`NXxbase` plus the data defined here. All four angles are + logged in order to support arbitrary scans in reciprocal space. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nP: | + Number of points +type: group +NXxeuler(NXxbase): + (NXentry)entry: + definition: + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXxeuler] + (NXinstrument)instrument: + (NXdetector)detector: + polar_angle(NX_FLOAT): + unit: NX_ANGLE + axis: 1 + doc: | + The polar_angle (two theta) where the detector is placed + at each scan point. + dimensions: + rank: 1 + dim: [[1, nP]] + (NXsample)sample: + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + axis: 1 + doc: | + This is an array holding the sample rotation angle at each + scan point + dimensions: + rank: 1 + dim: [[1, nP]] + chi(NX_FLOAT): + unit: NX_ANGLE + axis: 1 + doc: | + This is an array holding the chi angle of the eulerian + cradle at each scan point + dimensions: + rank: 1 + dim: [[1, nP]] + phi(NX_FLOAT): + unit: NX_ANGLE + signal: 1 + doc: | + This is an array holding the phi rotation of the eulerian + cradle at each scan point + dimensions: + rank: 1 + dim: [[1, nP]] + (NXdata)name: + polar_angle(link): + target: /NXentry/NXinstrument/NXdetector/polar_angle + rotation_angle(link): + target: /NXentry/NXsample/rotation_angle + chi(link): + target: /NXentry/NXsample/chi + phi(link): + target: /NXentry/NXsample/phi + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 418ca04c5cb718b73b9fb0a9ba4d7834a39720336466afd0292a376c2e6db6f0 +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of points +# +# +# +# raw data from a :index:`four-circle diffractometer` with an :index:`eulerian cradle`, extends :ref:`NXxbase` +# +# It extends :ref:`NXxbase`, so the full definition is the content +# of :ref:`NXxbase` plus the data defined here. All four angles are +# logged in order to support arbitrary scans in reciprocal space. +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# The polar_angle (two theta) where the detector is placed +# at each scan point. +# +# +# +# +# +# +# +# +# +# +# This is an array holding the sample rotation angle at each +# scan point +# +# +# +# +# +# +# +# This is an array holding the chi angle of the eulerian +# cradle at each scan point +# +# +# +# +# +# +# +# This is an array holding the phi rotation of the eulerian +# cradle at each scan point +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXxkappa.yaml b/applications/nyaml/NXxkappa.yaml new file mode 100644 index 0000000000..11ee96ea7a --- /dev/null +++ b/applications/nyaml/NXxkappa.yaml @@ -0,0 +1,174 @@ +category: application +doc: | + raw data from a kappa geometry (CAD4) single crystal diffractometer, extends :ref:`NXxbase` + + This is the application definition for raw data from a kappa geometry + (CAD4) single crystal + diffractometer. It extends :ref:`NXxbase`, so the full definition is + the content of :ref:`NXxbase` plus the + data defined here. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nP: | + Number of points +type: group +NXxkappa(NXxbase): + (NXentry)entry: + definition: + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXxkappa] + (NXinstrument)instrument: + (NXdetector)detector: + polar_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + The polar_angle (two theta) at each scan point + dimensions: + rank: 1 + dim: [[1, nP]] + (NXsample)sample: + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + axis: 1 + doc: | + This is an array holding the sample rotation angle at each + scan point + dimensions: + rank: 1 + dim: [[1, nP]] + kappa(NX_FLOAT): + unit: NX_ANGLE + axis: 1 + doc: | + This is an array holding the kappa angle at each scan point + dimensions: + rank: 1 + dim: [[1, nP]] + phi(NX_FLOAT): + unit: NX_ANGLE + axis: 1 + doc: | + This is an array holding the phi angle at each scan point + dimensions: + rank: 1 + dim: [[1, nP]] + alpha(NX_FLOAT): + unit: NX_ANGLE + doc: | + This holds the inclination angle of the kappa arm. + (NXdata)name: + polar_angle(link): + target: /NXentry/NXinstrument/NXdetector/polar_angle + rotation_angle(link): + target: /NXentry/NXsample/rotation_angle + kappa(link): + target: /NXentry/NXsample/kappa + phi(link): + target: /NXentry/NXsample/phi + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# ab0a0187da4ac644dd64a38cf2120fa6519200d0c8097d2e33373b66c4e3fab5 +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of points +# +# +# +# raw data from a kappa geometry (CAD4) single crystal diffractometer, extends :ref:`NXxbase` +# +# This is the application definition for raw data from a kappa geometry +# (CAD4) single crystal +# diffractometer. It extends :ref:`NXxbase`, so the full definition is +# the content of :ref:`NXxbase` plus the +# data defined here. +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# The polar_angle (two theta) at each scan point +# +# +# +# +# +# +# +# +# +# This is an array holding the sample rotation angle at each +# scan point +# +# +# +# +# +# +# +# This is an array holding the kappa angle at each scan point +# +# +# +# +# +# +# +# This is an array holding the phi angle at each scan point +# +# +# +# +# +# +# This holds the inclination angle of the kappa arm. +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXxlaue.yaml b/applications/nyaml/NXxlaue.yaml new file mode 100644 index 0000000000..82e1d406ba --- /dev/null +++ b/applications/nyaml/NXxlaue.yaml @@ -0,0 +1,109 @@ +category: application +doc: | + raw data from a single crystal laue camera, extends :ref:`NXxrot` + + This is the application definition for raw data from a single crystal laue + camera. It extends :ref:`NXxrot`. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nE: | + Number of energies +type: group +NXxlaue(NXxrot): + (NXentry)entry: + definition: + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXxlaue] + (NXinstrument)instrument: + (NXsource)source: + (NXdata)distribution: + data: + doc: | + expect ``signal=1 axes="energy"`` + dimensions: + rank: 1 + dim: [[1, nE]] + wavelength: + unit: NX_WAVELENGTH + dimensions: + rank: 1 + dim: [[1, nE]] + doc: | + This is the wavelength distribution of the beam + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 6bd59c0bb31baf46bbacaad01e38b03336b75f5d94468e0689b72386f201e77b +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of energies +# +# +# +# raw data from a single crystal laue camera, extends :ref:`NXxrot` +# +# This is the application definition for raw data from a single crystal laue +# camera. It extends :ref:`NXxrot`. +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# expect ``signal=1 axes="energy"`` +# +# +# +# +# +# +# +# +# +# +# This is the wavelength distribution of the beam +# +# +# +# +# +# diff --git a/applications/nyaml/NXxlaueplate.yaml b/applications/nyaml/NXxlaueplate.yaml new file mode 100644 index 0000000000..bb23a1d29f --- /dev/null +++ b/applications/nyaml/NXxlaueplate.yaml @@ -0,0 +1,73 @@ +category: application +doc: | + raw data from a single crystal Laue camera, extends :ref:`NXxlaue` + + This is the application definition for raw data from a single crystal Laue + camera with an image plate as a detector. It extends :ref:`NXxlaue`. +type: group +NXxlaueplate(NXxlaue): + (NXentry)entry: + definition: + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXxlaueplate] + (NXinstrument)instrument: + (NXdetector)detector: + diameter(NX_FLOAT): + unit: NX_LENGTH + doc: | + The diameter of a cylindrical detector + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 7ad47196c57fedde1c91245a9edd7ff63d278eb1e2fbac3d8059e8f2744c3a80 +# +# +# +# +# +# raw data from a single crystal Laue camera, extends :ref:`NXxlaue` +# +# This is the application definition for raw data from a single crystal Laue +# camera with an image plate as a detector. It extends :ref:`NXxlaue`. +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# The diameter of a cylindrical detector +# +# +# +# +# diff --git a/applications/nyaml/NXxnb.yaml b/applications/nyaml/NXxnb.yaml new file mode 100644 index 0000000000..c5f052d79a --- /dev/null +++ b/applications/nyaml/NXxnb.yaml @@ -0,0 +1,160 @@ +category: application +doc: | + raw data from a single crystal diffractometer, extends :ref:`NXxbase` + + This is the application definition for raw data from + a single crystal diffractometer + measuring in normal beam mode. It extends :ref:`NXxbase`, + so the full definition is the content of + :ref:`NXxbase` plus the data defined here. All angles are + logged in order to support arbitrary scans in + reciprocal space. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nP: | + Number of points +type: group +NXxnb(NXxbase): + (NXentry)entry: + definition: + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXxnb] + (NXinstrument)instrument: + (NXdetector)detector: + polar_angle(NX_FLOAT): + unit: NX_ANGLE + axis: 1 + doc: | + The polar_angle (gamma) of the detector for each scan point. + dimensions: + rank: 1 + dim: [[1, nP]] + tilt_angle(NX_FLOAT): + unit: NX_ANGLE + axis: 1 + doc: | + The angle by which the detector has been tilted out of the + scattering plane. + dimensions: + rank: 1 + dim: [[1, nP]] + (NXsample)sample: + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + axis: 1 + primary: 1 + doc: | + This is an array holding the sample rotation angle at each + scan point + dimensions: + rank: 1 + dim: [[1, nP]] + (NXdata)name: + polar_angle(link): + target: /NXentry/NXinstrument/NXdetector/polar_angle + tilt(link): + target: /NXentry/NXinstrument/NXdetector/tilt + rotation_angle(link): + target: /NXentry/NXsample/rotation_angle + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 08abdab5fcf7054861bd5927b569a05e6d69a55b7ed9b80344a60ede01cc3516 +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of points +# +# +# +# raw data from a single crystal diffractometer, extends :ref:`NXxbase` +# +# This is the application definition for raw data from +# a single crystal diffractometer +# measuring in normal beam mode. It extends :ref:`NXxbase`, +# so the full definition is the content of +# :ref:`NXxbase` plus the data defined here. All angles are +# logged in order to support arbitrary scans in +# reciprocal space. +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# The polar_angle (gamma) of the detector for each scan point. +# +# +# +# +# +# +# +# The angle by which the detector has been tilted out of the +# scattering plane. +# +# +# +# +# +# +# +# +# +# +# This is an array holding the sample rotation angle at each +# scan point +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXxrot.yaml b/applications/nyaml/NXxrot.yaml new file mode 100644 index 0000000000..5aa4e35558 --- /dev/null +++ b/applications/nyaml/NXxrot.yaml @@ -0,0 +1,155 @@ +category: application +doc: | + raw data from a rotation camera, extends :ref:`NXxbase` + + This is the application definition for raw data from a rotation camera. + It extends :ref:`NXxbase`, so the full definition is the content of :ref:`NXxbase` + plus the data defined here. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nP: | + Number of points +type: group +NXxrot(NXxbase): + (NXentry)entry: + definition: + doc: | + Official NeXus NXDL schema to which this file conforms. + enumeration: [NXxrot] + (NXinstrument)instrument: + (NXdetector)detector: + polar_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + The polar_angle (two theta) where the detector is placed. + beam_center_x(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the x position where the direct beam would hit the detector. This is a + length, not a pixel position, and can be outside of the actual detector. + beam_center_y(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the y position where the direct beam would hit the detector. This is a + length, not a pixel position, and can be outside of the actual detector. + (NXattenuator)attenuator: + attenuator_transmission(NX_FLOAT): + unit: NX_ANY + (NXsample)sample: + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + axis: 1 + doc: | + This is an array holding the sample rotation start angle at each scan point + dimensions: + rank: 1 + dim: [[1, nP]] + rotation_angle_step(NX_FLOAT): + unit: NX_ANGLE + axis: 1 + doc: | + This is an array holding the step made for sample rotation angle at each scan point + dimensions: + rank: 1 + dim: [[1, nP]] + (NXdata)name: + rotation_angle(link): + target: /NXentry/NXsample/rotation_angle + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 996ce47ecffe4c4b4e0ffe4014ce8d5db9abb70f109b8508e5124256777ae344 +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of points +# +# +# +# raw data from a rotation camera, extends :ref:`NXxbase` +# +# This is the application definition for raw data from a rotation camera. +# It extends :ref:`NXxbase`, so the full definition is the content of :ref:`NXxbase` +# plus the data defined here. +# +# +# +# Official NeXus NXDL schema to which this file conforms. +# +# +# +# +# +# +# +# The polar_angle (two theta) where the detector is placed. +# +# +# +# This is the x position where the direct beam would hit the detector. This is a +# length, not a pixel position, and can be outside of the actual detector. +# +# +# +# This is the y position where the direct beam would hit the detector. This is a +# length, not a pixel position, and can be outside of the actual detector. +# +# +# +# +# +# +# +# +# +# This is an array holding the sample rotation start angle at each scan point +# +# +# +# +# +# This is an array holding the step made for sample rotation angle at each scan point +# +# +# +# +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXaperture.yaml b/base_classes/nyaml/NXaperture.yaml new file mode 100644 index 0000000000..7b123ba21b --- /dev/null +++ b/base_classes/nyaml/NXaperture.yaml @@ -0,0 +1,214 @@ +category: base +doc: | + A beamline aperture. This group is deprecated, use NXslit instead. +type: group +NXaperture(NXobject): + + # TODO compare with "screens" in SHADOW + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference point of the aperture is its center in the x and y axis. The reference point on the z axis is the + surface of the aperture pointing towards the source. + + In complex (asymmetric) geometries an NXoff_geometry group can be used to provide an unambiguous reference. + + .. image:: aperture/aperture.png + :width: 40% + (NXtransformations): + doc: | + 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. + (NXpositioner): + doc: | + Stores the raw positions of aperture motors. + (NXgeometry): + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the aperture and :ref:`NXoff_geometry` to describe its shape + doc: | + location and shape of aperture + + .. TODO: documentation needs improvement, contributions welcome + + * description of terms is poor and leaves much to interpretation + * Describe what is meant by translation _here_ and ... + * Similar throughout base classes + * Some base classes do this much better + * Such as where is the gap written? + BLADE_GEOMETRY(NXgeometry): + deprecated: | + Use :ref:`NXoff_geometry` instead to describe the shape of the aperture + doc: | + location and shape of each blade + material: + + # TODO Uniformity problem, "type" is used elsewhere for same context + doc: | + Absorbing material of the aperture + description: + doc: | + Description of aperture + shape: + doc: | + Shape of the aperture. + enumeration: [straight slit, curved slit, pinhole, circle, square, hexagon, octagon, bladed, open, grid] + size(NX_NUMBER): + unit: NX_LENGTH + doc: | + The relevant dimension for the aperture, i.e. slit width, pinhole and iris + diameter + (NXnote): + doc: | + describe any additional information in a note* + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 958de5809c55ea9bb7eda83a612cf4e2770cbce001cc16a5944e072279415895 +# +# +# +# +# +# A beamline aperture. This group is deprecated, use NXslit instead. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# The reference point of the aperture is its center in the x and y axis. The reference point on the z axis is the +# surface of the aperture pointing towards the source. +# +# In complex (asymmetric) geometries an NXoff_geometry group can be used to provide an unambiguous reference. +# +# .. image:: aperture/aperture.png +# :width: 40% +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# +# Stores the raw positions of aperture motors. +# +# +# +# +# location and shape of aperture +# +# .. TODO: documentation needs improvement, contributions welcome +# +# * description of terms is poor and leaves much to interpretation +# * Describe what is meant by translation _here_ and ... +# * Similar throughout base classes +# * Some base classes do this much better +# * Such as where is the gap written? +# +# +# +# +# location and shape of each blade +# +# +# +# +# +# Absorbing material of the aperture +# +# +# +# +# Description of aperture +# +# +# +# +# Shape of the aperture. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The relevant dimension for the aperture, i.e. slit width, pinhole and iris +# diameter +# +# +# +# +# describe any additional information in a note* +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# diff --git a/base_classes/nyaml/NXattenuator.yaml b/base_classes/nyaml/NXattenuator.yaml new file mode 100644 index 0000000000..21fc404d16 --- /dev/null +++ b/base_classes/nyaml/NXattenuator.yaml @@ -0,0 +1,206 @@ +category: base +doc: | + A device that reduces the intensity of a beam by attenuation. + + If uncertain whether to use :ref:`NXfilter` (band-pass filter) + or :ref:`NXattenuator` (reduces beam intensity), then choose + :ref:`NXattenuator`. +type: group +NXattenuator(NXobject): + + # TODO compare with SHADOW definition "screen" + # TODO SHADOW: https://github.com/oasys-kit/shadow3 + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + Distance from sample. Note, it is recommended to use NXtransformations instead. + type: + doc: | + Type or composition of attenuator, e.g. polythene + thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + Thickness of attenuator along beam direction + scattering_cross_section(NX_FLOAT): + unit: NX_CROSS_SECTION + doc: | + Scattering cross section (coherent+incoherent) + absorption_cross_section(NX_FLOAT): + unit: NX_CROSS_SECTION + doc: | + Absorption cross section + attenuator_transmission(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + The nominal amount of the beam that gets through + (transmitted intensity)/(incident intensity) + status: + doc: | + In or out or moving of the beam + \@time: + type: NX_DATE_TIME + doc: | + time stamp for this observation + enumeration: [in, out, moving] + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference point of the attenuator is its center in the x and y axis. The reference point on the z axis is the + surface of the attenuator pointing towards the source. + + In complex (asymmetic) geometries an NXoff_geometry group can be used to provide an unambiguous reference. + + .. image:: attenuator/attenuator.png + :width: 40% + (NXtransformations): + doc: | + 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. + shape(NXoff_geometry): + doc: | + Shape of this component. Particulary useful to define the origin for position and orientation in non-standard cases. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 5cb6333d87df9b8f1b009346d2bf55434c7d4ef72f1ce1b62db27caf873c4f7f +# +# +# +# +# +# +# A device that reduces the intensity of a beam by attenuation. +# +# If uncertain whether to use :ref:`NXfilter` (band-pass filter) +# or :ref:`NXattenuator` (reduces beam intensity), then choose +# :ref:`NXattenuator`. +# +# +# +# +# Distance from sample. Note, it is recommended to use NXtransformations instead. +# +# +# Type or composition of attenuator, e.g. polythene +# +# +# Thickness of attenuator along beam direction +# +# +# Scattering cross section (coherent+incoherent) +# +# +# Absorption cross section +# +# +# +# The nominal amount of the beam that gets through +# (transmitted intensity)/(incident intensity) +# +# +# +# In or out or moving of the beam +# +# time stamp for this observation +# +# +# +# +# +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# The reference point of the attenuator is its center in the x and y axis. The reference point on the z axis is the +# surface of the attenuator pointing towards the source. +# +# In complex (asymmetic) geometries an NXoff_geometry group can be used to provide an unambiguous reference. +# +# .. image:: attenuator/attenuator.png +# :width: 40% +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# +# Shape of this component. Particulary useful to define the origin for position and orientation in non-standard cases. +# +# +# diff --git a/base_classes/nyaml/NXbeam.yaml b/base_classes/nyaml/NXbeam.yaml new file mode 100644 index 0000000000..bc5e640d12 --- /dev/null +++ b/base_classes/nyaml/NXbeam.yaml @@ -0,0 +1,889 @@ +category: base +doc: | + 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. +symbols: + doc: | + These symbols coordinate datasets with the same shape. + nP: | + Number of scan points. + m: | + Number of channels in the incident beam spectrum, if known + c: | + Number of moments representing beam divergence (x, y, xy, etc.) +type: group +NXbeam(NXobject): + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + Distance from sample. Note, it is recommended to use NXtransformations instead. + incident_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + 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. + dimensions: + rank: 1 + dim: [[1, m]] + incident_energy_spread(NX_NUMBER): + unit: NX_ENERGY + doc: | + 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. + incident_energy_weights(NX_NUMBER): + unit: NX_ENERGY + doc: | + In the case of a polychromatic beam this is an array of length m of the relative + weights of the corresponding energies in incident_energy. In the case of a + polychromatic beam that varies shot-to-shot, this is a 2D array of dimensions np + by m (slow to fast) of the relative weights of the corresponding energies in + incident_energy. + final_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + Energy carried by each particle of the beam on leaving the beamline component + dimensions: + rank: 1 + dim: [[1, m]] + energy_transfer(NX_FLOAT): + unit: NX_ENERGY + doc: | + Change in particle energy caused by the beamline component + dimensions: + rank: 1 + dim: [[1, m]] + incident_wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + 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 + incident_wavelength_weights(NX_FLOAT): + doc: | + In the case of a polychromatic beam this is an array of + length **m** of the relative weights of the corresponding + wavelengths in ``incident_wavelength``. + + In the case of a polychromatic beam that varies shot-to- + shot, this is a 2D array of dimensions **nP** by **m** + (slow to fast) of the relative weights of the + corresponding wavelengths in ``incident_wavelength``. + incident_wavelength_spread(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + The wavelength spread FWHM for the corresponding + wavelength(s) in incident_wavelength. + + In the case of shot-to-shot variation in the wavelength + spread, this is a 2D array of dimension **nP** by + **m** (slow to fast) of the spreads of the + corresponding wavelengths in incident_wavelength. + dimensions: + rank: 1 + dim: [[1, nP]] + incident_beam_divergence(NX_FLOAT): + unit: NX_ANGLE + doc: | + Beam crossfire in degrees parallel to the laboratory X axis + + The dimension **c** is a series of moments of that represent + the standard uncertainty (e.s.d.) of the directions of + of the beam. The first and second moments are in the XZ and YZ + planes around the mean source beam direction, respectively. + + Further moments in **c** characterize co-variance terms, so + the next moment is the product of the first two, and so on. + dimensions: + rank: 2 + dim: [[1, nP], [2, c]] + extent(NX_FLOAT): + unit: NX_LENGTH + doc: | + Size of the beam entering this component. Note this represents + a rectangular beam aperture, and values represent FWHM + dimensions: + rank: 2 + dim: [[1, nP], [2, 2]] + final_wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + Wavelength on leaving beamline component + dimensions: + rank: 1 + dim: [[1, m]] + incident_polarization(NX_NUMBER): + unit: NX_ANY + doc: | + Incident polarization as a Stokes vector + on entering beamline component + dimensions: + rank: 2 + dim: [[1, nP], [2, 2]] + \@units: + type: NX_CHAR + doc: | + The units for this observable are not included in the NIAC list. + Responsibility on correct formatting and parsing is handed to the user + by using `NX_ANY`. Correct parsing can still be implemented by using + this attribute. + + | Fill with: + + * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). + * The unit unidata name if the unit has a name (Example: farad for capacitance). + * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and + does not have a name. + + Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). + Here: SI units are V2/m2. + final_polarization(NX_NUMBER): + unit: NX_ANY + doc: | + Polarization as Stokes vector on leaving beamline component + dimensions: + rank: 2 + dim: [[1, nP], [2, 2]] + \@units: + type: NX_CHAR + doc: | + The units for this observable are not included in the NIAC list. + Responsibility on correct formatting and parsing is handed to the user + by using `NX_ANY`. Correct parsing can still be implemented by using + this attribute. + + | Fill with: + + * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). + * The unit unidata name if the unit has a name (Example: farad for capacitance). + * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and + does not have a name. + + Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). + Here: SI units are V2/m2. + incident_polarization_stokes(NX_NUMBER): + unit: NX_ANY + doc: | + Polarization vector on entering beamline component using Stokes notation + + The Stokes parameters are four components labelled I,Q,U,V or S_0,S_1,S_2,S_3. + These are defined with the standard Nexus coordinate frame unless it is + overridden by an NXtransformations field pointed to by a depends_on attribute. + The last component, describing the circular polarization state, is positive + for a right-hand circular state - that is the electric field vector rotates + clockwise at the sample and over time when observed from the source. + + I (S_0) is the beam intensity (often normalized to 1). Q, U, and V scale + linearly with the total degree of polarization, and indicate the relative + magnitudes of the pure linear and circular orientation contributions. + + Q (S_1) is linearly polarized along the x axis (Q > 0) or y axis (Q < 0). + + U (S_2) is linearly polarized along the x==y axis (U > 0) or the + -x==y axis (U < 0). + + V (S_3) is circularly polarized. V > 0 when the electric field vector rotates + clockwise at the sample with respect to time when observed from the source; + V < 0 indicates the opposite rotation. + dimensions: + rank: 2 + dim: [[1, nP], [2, 4]] + final_polarization_stokes(NX_NUMBER): + unit: NX_ANY + doc: | + Polarization vector on leaving beamline component using Stokes notation + (see incident_polarization_stokes). + dimensions: + rank: 2 + dim: [[1, nP], [2, 4]] + final_wavelength_spread(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + Wavelength spread FWHM of beam leaving this component + dimensions: + rank: 1 + dim: [[1, m]] + final_beam_divergence(NX_FLOAT): + unit: NX_ANGLE + doc: | + Divergence FWHM of beam leaving this component + dimensions: + rank: 2 + dim: [[1, nP], [2, 2]] + flux(NX_FLOAT): + unit: NX_FLUX + doc: | + flux incident on beam plane area + dimensions: + rank: 1 + dim: [[1, nP]] + pulse_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + Energy of a single pulse at the diagnostic point + average_power(NX_FLOAT): + unit: NX_POWER + doc: | + Average power at the diagnostic point + fluence(NX_FLOAT): + unit: NX_ANY + doc: | + Incident fluence at the diagnostic point + \@units: + type: NX_CHAR + doc: | + Here: SI units are 'J/m2', customary 'mJ/cm2'. + pulse_duration(NX_FLOAT): + unit: NX_TIME + doc: | + FWHM duration of the pulses at the diagnostic point + frog_trace(NX_FLOAT): + doc: | + FROG trace of the pulse. + dimensions: + rank: 2 + dim: [[1, nx], [2, ny]] + frog_delays(NX_FLOAT): + unit: NX_TIME + doc: | + Horizontal axis of a FROG trace, i.e. delay. + dimensions: + rank: 1 + dim: [[1, nx]] + frog_frequencies(NX_FLOAT): + unit: NX_FREQUENCY + doc: | + Vertical axis of a FROG trace, i.e. frequency. + dimensions: + rank: 1 + dim: [[1, ny]] + chirp_type(NX_CHAR): + doc: | + The type of chirp implemented + chirp_GDD(NX_FLOAT): + unit: NX_TIME + doc: | + Group delay dispersion of the pulse for linear chirp + (NXdata): + doc: | + Distribution of beam with respect to relevant variable e.g. wavelength. This is mainly + useful for simulations which need to store plottable information at each beamline + component. + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + exists: ['min', '0'] + doc: | + The NeXus coordinate system defines the Z axis to be along the nominal beam + direction. This is the same as the McStas coordinate system (see :ref:`Design-CoordinateSystem`). + However, the additional transformations needed to represent an altered beam + direction can be provided using this depends_on field that contains the path + to a NXtransformations group. This could represent redirection of the beam, + or a refined beam direction. + (NXtransformations): + exists: ['min', '0'] + doc: | + Direction (and location) for the beam. The location of the beam can be given by + any point which it passes through as its offset attribute. + DIRECTION(NX_NUMBER): + nameType: any + unit: NX_TRANSFORMATION + doc: | + Direction of beam vector, its value is ignored. If missing, then the beam direction is defined as [0,0,1] + and passes through the origin + \@transformation_type: + enumeration: [translation] + \@vector: + type: NX_NUMBER + doc: | + Three values that define the direction of beam vector + \@offset: + type: NX_NUMBER + doc: | + Three values that define the location of a point through which the beam passes + \@depends_on: + type: NX_CHAR + doc: | + Points to the path to a field defining the location on which this + depends or the string "." for origin. + reference_plane(NX_NUMBER): + nameType: any + unit: NX_TRANSFORMATION + doc: | + Direction of normal to reference plane used to measure azimuth relative to the beam, its value is ignored. + This also defines the parallel and perpendicular components of the beam's polarization. + If missing, then the reference plane normal is defined as [0,1,0] and passes through the origin + \@transformation_type: + enumeration: [translation] + \@vector: + type: NX_NUMBER + doc: | + Three values that define the direction of reference plane normal + \@offset: + type: NX_NUMBER + doc: | + Not required as beam direction offset locates the plane + \@depends_on: + type: NX_CHAR + doc: | + Points to the path to a field defining the location on which this + depends or the string "." for origin. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# dbe7fba854b6a29c068ef96a3c8fbe28c8217579d5d8a990ffa730ecd269bf21 +# +# +# +# +# +# +# These symbols coordinate datasets with the same shape. +# +# +# +# Number of scan points. +# +# +# +# +# Number of channels in the incident beam spectrum, if known +# +# +# +# +# Number of moments representing beam divergence (x, y, xy, etc.) +# +# +# +# +# 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. +# +# +# +# Distance from sample. Note, it is recommended to use NXtransformations instead. +# +# +# +# +# Energy carried by each particle of the beam on entering the beamline component. +# +# In the case of a monochromatic beam this is the scalar energy. +# Several other use cases are permitted, depending on the +# presence of other incident_energy_X fields. +# +# * In the case of a polychromatic beam this is an array of length m of energies, with the relative weights in incident_energy_weights. +# * In the case of a monochromatic beam that varies shot-to-shot, this is an array of energies, one for each recorded shot. +# Here, incident_energy_weights and incident_energy_spread are not set. +# * In the case of a polychromatic beam that varies shot-to-shot, +# this is an array of length m with the relative weights in incident_energy_weights as a 2D array. +# * In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, +# this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_energy_weights as a 2D array. +# +# Note, variants are a good way to represent several of these use cases in a single dataset, +# e.g. if a calibrated, single-value energy value is available along with the original spectrum from which it was calibrated. +# +# +# +# +# +# +# +# The energy spread FWHM for the corresponding energy(ies) in incident_energy. In the case of shot-to-shot variation in +# the energy spread, this is a 2D array of dimension nP by m +# (slow to fast) of the spreads of the corresponding +# wavelength in incident_wavelength. +# +# +# +# +# In the case of a polychromatic beam this is an array of length m of the relative +# weights of the corresponding energies in incident_energy. In the case of a +# polychromatic beam that varies shot-to-shot, this is a 2D array of dimensions np +# by m (slow to fast) of the relative weights of the corresponding energies in +# incident_energy. +# +# +# +# +# Energy carried by each particle of the beam on leaving the beamline component +# +# +# +# +# +# +# +# Change in particle energy caused by the 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 <Design-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 polychromatic beam this is an array of +# length **m** of the relative weights of the corresponding +# wavelengths in ``incident_wavelength``. +# +# In the case of a polychromatic beam that varies shot-to- +# shot, this is a 2D array of dimensions **nP** by **m** +# (slow to fast) of the relative weights of the +# corresponding wavelengths in ``incident_wavelength``. +# +# +# +# +# The wavelength spread FWHM for the corresponding +# wavelength(s) in incident_wavelength. +# +# In the case of shot-to-shot variation in the wavelength +# spread, this is a 2D array of dimension **nP** by +# **m** (slow to fast) of the spreads of the +# corresponding wavelengths in incident_wavelength. +# +# +# +# +# +# +# +# Beam crossfire in degrees parallel to the laboratory X axis +# +# The dimension **c** is a series of moments of that represent +# the standard uncertainty (e.s.d.) of the directions of +# of the beam. The first and second moments are in the XZ and YZ +# planes around the mean source beam direction, respectively. +# +# Further moments in **c** characterize co-variance terms, so +# the next moment is the product of the first two, and so on. +# +# +# +# +# +# +# +# +# Size of the beam entering this component. Note this represents +# a rectangular beam aperture, and values represent FWHM +# +# +# +# +# +# +# +# +# Wavelength on leaving beamline component +# +# +# +# +# +# +# +# Incident polarization as a Stokes vector +# on entering beamline component +# +# +# +# +# +# +# +# The units for this observable are not included in the NIAC list. +# Responsibility on correct formatting and parsing is handed to the user +# by using `NX_ANY`. Correct parsing can still be implemented by using +# this attribute. +# +# | Fill with: +# +# * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). +# * The unit unidata name if the unit has a name (Example: farad for capacitance). +# * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and +# does not have a name. +# +# Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). +# Here: SI units are V2/m2. +# +# +# +# +# +# Polarization as Stokes vector on leaving beamline component +# +# +# +# +# +# +# +# The units for this observable are not included in the NIAC list. +# Responsibility on correct formatting and parsing is handed to the user +# by using `NX_ANY`. Correct parsing can still be implemented by using +# this attribute. +# +# | Fill with: +# +# * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). +# * The unit unidata name if the unit has a name (Example: farad for capacitance). +# * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and +# does not have a name. +# +# Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). +# Here: SI units are V2/m2. +# +# +# +# +# +# Polarization vector on entering beamline component using Stokes notation +# +# The Stokes parameters are four components labelled I,Q,U,V or S_0,S_1,S_2,S_3. +# These are defined with the standard Nexus coordinate frame unless it is +# overridden by an NXtransformations field pointed to by a depends_on attribute. +# The last component, describing the circular polarization state, is positive +# for a right-hand circular state - that is the electric field vector rotates +# clockwise at the sample and over time when observed from the source. +# +# I (S_0) is the beam intensity (often normalized to 1). Q, U, and V scale +# linearly with the total degree of polarization, and indicate the relative +# magnitudes of the pure linear and circular orientation contributions. +# +# Q (S_1) is linearly polarized along the x axis (Q > 0) or y axis (Q < 0). +# +# U (S_2) is linearly polarized along the x==y axis (U > 0) or the +# -x==y axis (U < 0). +# +# V (S_3) is circularly polarized. V > 0 when the electric field vector rotates +# clockwise at the sample with respect to time when observed from the source; +# V < 0 indicates the opposite rotation. +# +# +# +# +# +# +# +# +# Polarization vector on leaving beamline component using Stokes notation +# (see incident_polarization_stokes). +# +# +# +# +# +# +# +# +# Wavelength spread FWHM of beam leaving this component +# +# +# +# +# +# +# +# Divergence FWHM of beam leaving this component +# +# +# +# +# +# +# +# +# flux incident on beam plane area +# +# +# +# +# +# +# +# Energy of a single pulse at the diagnostic point +# +# +# +# +# Average power at the diagnostic point +# +# +# +# +# Incident fluence at the diagnostic point +# +# +# +# Here: SI units are 'J/m2', customary 'mJ/cm2'. +# +# +# +# +# +# FWHM duration of the pulses at the diagnostic point +# +# +# +# +# FROG trace of the pulse. +# +# +# +# +# +# +# +# +# Horizontal axis of a FROG trace, i.e. delay. +# +# +# +# +# +# +# +# Vertical axis of a FROG trace, i.e. frequency. +# +# +# +# +# +# +# +# The type of chirp implemented +# +# +# +# +# Group delay dispersion of the pulse for linear chirp +# +# +# +# +# Distribution of beam with respect to relevant variable e.g. wavelength. This is mainly +# useful for simulations which need to store plottable information at each beamline +# component. +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# The NeXus coordinate system defines the Z axis to be along the nominal beam +# direction. This is the same as the McStas coordinate system (see :ref:`Design-CoordinateSystem`). +# However, the additional transformations needed to represent an altered beam +# direction can be provided using this depends_on field that contains the path +# to a NXtransformations group. This could represent redirection of the beam, +# or a refined beam direction. +# +# +# +# +# Direction (and location) for the beam. The location of the beam can be given by +# any point which it passes through as its offset attribute. +# +# +# +# Direction of beam vector, its value is ignored. If missing, then the beam direction is defined as [0,0,1] +# and passes through the origin +# +# +# +# +# +# +# +# +# Three values that define the direction of beam vector +# +# +# +# +# Three values that define the location of a point through which the beam passes +# +# +# +# +# Points to the path to a field defining the location on which this +# depends or the string "." for origin. +# +# +# +# +# +# Direction of normal to reference plane used to measure azimuth relative to the beam, its value is ignored. +# This also defines the parallel and perpendicular components of the beam's polarization. +# If missing, then the reference plane normal is defined as [0,1,0] and passes through the origin +# +# +# +# +# +# +# +# +# Three values that define the direction of reference plane normal +# +# +# +# +# Not required as beam direction offset locates the plane +# +# +# +# +# Points to the path to a field defining the location on which this +# depends or the string "." for origin. +# +# +# +# +# diff --git a/base_classes/nyaml/NXbeam_stop.yaml b/base_classes/nyaml/NXbeam_stop.yaml new file mode 100644 index 0000000000..f2cf05b88b --- /dev/null +++ b/base_classes/nyaml/NXbeam_stop.yaml @@ -0,0 +1,207 @@ +category: base +doc: | + A device that blocks the beam completely, usually to protect a detector. + + Beamstops and their positions are important for SANS + and SAXS experiments. +type: group +NXbeam_stop(NXobject): + (NXgeometry): + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the beamstop and NXoff_geometry to describe its shape instead + doc: | + engineering shape, orientation and position of the beam stop. + description: + doc: | + description of beamstop + enumeration: [circular, rectangular] + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the beam line component + (NXcylindrical_geometry): + exists: ['min', '0'] + doc: | + This group is an alternative to NXoff_geometry for describing the shape + of the beam stop. + size(NX_FLOAT): + unit: NX_LENGTH + doc: | + Size of beamstop. If this is not sufficient to describe the beam stop use + NXoff_geometry instead. + x(NX_FLOAT): + unit: NX_LENGTH + doc: | + x position of the beamstop in relation to the detector. + Note, it is recommended to use NXtransformations instead. + y(NX_FLOAT): + unit: NX_LENGTH + doc: | + y position of the beamstop in relation to the detector. + Note, it is recommended to use NXtransformations instead. + distance_to_detector(NX_FLOAT): + unit: NX_LENGTH + doc: | + distance of the beamstop to the detector. + Note, it is recommended to use NXtransformations instead. + status: + enumeration: [in, out] + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference point of the beam stop is its center in the x and y axis. The reference point on the z axis is the + surface of the beam stop pointing towards the source. + + .. image:: beam_stop/beam_stop.png + :width: 40% + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 8c256286b0040d033d1e37850936cb15fbaf674606ac0e0ffcd7188c2684cb66 +# +# +# +# +# +# +# A device that blocks the beam completely, usually to protect a detector. +# +# Beamstops and their positions are important for SANS +# and SAXS experiments. +# +# +# engineering shape, orientation and position of the beam stop. +# +# +# description of beamstop +# +# +# +# +# +# +# +# This group describes the shape of the beam line component +# +# +# +# +# This group is an alternative to NXoff_geometry for describing the shape +# of the beam stop. +# +# +# +# +# Size of beamstop. If this is not sufficient to describe the beam stop use +# NXoff_geometry instead. +# +# +# +# +# x position of the beamstop in relation to the detector. +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# y position of the beamstop in relation to the detector. +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# distance of the beamstop to the detector. +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# +# +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# The reference point of the beam stop is its center in the x and y axis. The reference point on the z axis is the +# surface of the beam stop pointing towards the source. +# +# .. image:: beam_stop/beam_stop.png +# :width: 40% +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# diff --git a/base_classes/nyaml/NXbending_magnet.yaml b/base_classes/nyaml/NXbending_magnet.yaml new file mode 100644 index 0000000000..8cec9c3336 --- /dev/null +++ b/base_classes/nyaml/NXbending_magnet.yaml @@ -0,0 +1,210 @@ +category: base +doc: | + A bending magnet +type: group +NXbending_magnet(NXobject): + critical_energy(NX_FLOAT): + unit: NX_ENERGY + bending_radius(NX_FLOAT): + unit: NX_LENGTH + magnetic_field(NX_FLOAT): + unit: NX_CURRENT + doc: | + strength of magnetic field of dipole magnets + accepted_photon_beam_divergence(NX_FLOAT): + unit: NX_LENGTH + doc: | + An array of four numbers giving X+, X-, Y+ and Y- half divergence + source_distance_x(NX_FLOAT): + unit: NX_LENGTH + doc: | + Distance of source point from particle beam waist in X (horizontal) direction. + Note, it is recommended to use NXtransformations instead to place component. + source_distance_y(NX_FLOAT): + unit: NX_LENGTH + doc: | + Distance of source point from particle beam waist in Y (vertical) direction. + Note, it is recommended to use NXtransformations instead to place component. + divergence_x_plus(NX_FLOAT): + unit: NX_ANGLE + doc: | + Accepted photon beam divergence in X+ (horizontal outboard) direction. + Note that divergence_x_plus+divergence_x_minus is the total horizontal beam divergence. + divergence_x_minus(NX_FLOAT): + unit: NX_ANGLE + doc: | + Accepted photon beam divergence in X- (horizontal inboard) direction. + Note that divergence_x_plus+divergence_x_minus is the total horizontal beam divergence. + divergence_y_plus(NX_FLOAT): + unit: NX_ANGLE + doc: | + Accepted photon beam divergence in Y+ (vertical upward) direction. + Note that divergence_y_plus+divergence_y_minus is the total vertical beam divergence. + divergence_y_minus(NX_FLOAT): + unit: NX_ANGLE + doc: | + Accepted photon beam divergence in Y- (vertical downward) direction. + Note that divergence_y_plus+divergence_y_minus is the total vertical beam divergence. + spectrum(NXdata): + doc: | + bending magnet spectrum + (NXgeometry): + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the bending magnet and NXoff_geometry to describe its shape instead + doc: | + "Engineering" position of bending magnet + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the beam line component + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a bending magnet. + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 99e6fdaf28f81ce18c473abeb17354d390f7383d1715f41e4cc141dbf447dc65 +# +# +# +# +# +# A bending magnet +# +# +# +# strength of magnetic field of dipole magnets +# +# +# +# An array of four numbers giving X+, X-, Y+ and Y- half divergence +# +# +# +# +# Distance of source point from particle beam waist in X (horizontal) direction. +# Note, it is recommended to use NXtransformations instead to place component. +# +# +# +# +# Distance of source point from particle beam waist in Y (vertical) direction. +# Note, it is recommended to use NXtransformations instead to place component. +# +# +# +# +# Accepted photon beam divergence in X+ (horizontal outboard) direction. +# Note that divergence_x_plus+divergence_x_minus is the total horizontal beam divergence. +# +# +# +# +# Accepted photon beam divergence in X- (horizontal inboard) direction. +# Note that divergence_x_plus+divergence_x_minus is the total horizontal beam divergence. +# +# +# +# +# Accepted photon beam divergence in Y+ (vertical upward) direction. +# Note that divergence_y_plus+divergence_y_minus is the total vertical beam divergence. +# +# +# +# +# Accepted photon beam divergence in Y- (vertical downward) direction. +# Note that divergence_y_plus+divergence_y_minus is the total vertical beam divergence. +# +# +# bending magnet spectrum +# "Engineering" position of bending magnet +# +# +# This group describes the shape of the beam line component +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a bending magnet. +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# diff --git a/base_classes/nyaml/NXcapillary.yaml b/base_classes/nyaml/NXcapillary.yaml new file mode 100644 index 0000000000..aacb021fd6 --- /dev/null +++ b/base_classes/nyaml/NXcapillary.yaml @@ -0,0 +1,163 @@ +category: base +doc: | + A capillary lens to focus the X-ray beam. + + Based on information provided by Gerd Wellenreuther (DESY). +type: group +NXcapillary(NXobject): + type(NX_CHAR): + doc: | + Type of the capillary + enumeration: [single_bounce, polycapillary, conical_capillary] + manufacturer(NX_CHAR): + doc: | + The manufacturer of the capillary. This is actually important as + it may have an impact on performance. + maximum_incident_angle(NX_FLOAT): + unit: NX_ANGLE + accepting_aperture(NX_FLOAT): + unit: NX_ANGLE + (NXdata)gain: + doc: | + The gain of the capillary as a function of energy + (NXdata)transmission: + doc: | + The transmission of the capillary as a function of energy + working_distance(NX_FLOAT): + unit: NX_LENGTH + focal_size(NX_FLOAT): + doc: | + The focal size in FWHM + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a capillary lens. + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 532702bd23065d69a03c9e0b7aaf7136d411799faab901669a8be1f5d007b6c9 +# +# +# +# +# +# +# A capillary lens to focus the X-ray beam. +# +# Based on information provided by Gerd Wellenreuther (DESY). +# +# +# Type of the capillary +# +# +# +# +# +# +# +# +# The manufacturer of the capillary. This is actually important as +# it may have an impact on performance. +# +# +# +# +# +# +# The gain of the capillary as a function of energy +# +# +# +# +# The transmission of the capillary as a function of energy +# +# +# +# +# +# The focal size in FWHM +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a capillary lens. +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# diff --git a/base_classes/nyaml/NXcite.yaml b/base_classes/nyaml/NXcite.yaml new file mode 100644 index 0000000000..d183f1fd89 --- /dev/null +++ b/base_classes/nyaml/NXcite.yaml @@ -0,0 +1,112 @@ +category: base +doc: | + A literature reference + + Definition to include references for example for detectors, + manuals, instruments, acquisition or analysis software used. + + The idea would be to include this in the relevant NeXus object: + :ref:`NXdetector` for detectors, :ref:`NXinstrument` for instruments, etc. +type: group +NXcite(NXobject): + description(NX_CHAR): + doc: | + This should describe the reason for including this reference. + For example: The dataset in this group was normalised using the method + which is described in detail in this reference. + url(NX_CHAR): + doc: | + URL referencing the document or data. + doi(NX_CHAR): + doc: | + DOI referencing the document or data. + endnote(NX_CHAR): + doc: | + Bibliographic reference data in EndNote format. + bibtex(NX_CHAR): + doc: | + Bibliographic reference data in BibTeX format. + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 59929309fbee197465213bc3b923e04782d370b2058f5a970b41ecf71e85ba7a +# +# +# +# +# +# A literature reference +# +# Definition to include references for example for detectors, +# manuals, instruments, acquisition or analysis software used. +# +# The idea would be to include this in the relevant NeXus object: +# :ref:`NXdetector` for detectors, :ref:`NXinstrument` for instruments, etc. +# +# +# +# This should describe the reason for including this reference. +# For example: The dataset in this group was normalised using the method +# which is described in detail in this reference. +# +# +# +# URL referencing the document or data. +# +# +# DOI referencing the document or data. +# +# +# Bibliographic reference data in EndNote format. +# +# +# Bibliographic reference data in BibTeX format. +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# diff --git a/base_classes/nyaml/NXcollection.yaml b/base_classes/nyaml/NXcollection.yaml new file mode 100644 index 0000000000..5b3dd56a28 --- /dev/null +++ b/base_classes/nyaml/NXcollection.yaml @@ -0,0 +1,102 @@ +category: base + +# The ignoreExtra* attributes are used in the definition to +# avoid warning messages that would be generated from +# unexpected groups, fields, and attributes. +# Since no groups or attributes are declared here, _every_ +# child of this class would generate a warning message without this +# attribute being set to "true". +doc: | + An unvalidated set of terms, such as the description of a beam line. + + Use :ref:`NXcollection` to gather together any set of terms. + The original suggestion is to use this as a container + class for the description of a beamline. + + For NeXus validation, :ref:`NXcollection` will always generate + a warning since it is always an optional group. + Anything (groups, fields, or attributes) placed in + an :ref:`NXcollection` group will not be validated. +type: group +ignoreExtraGroups: true +ignoreExtraFields: true +ignoreExtraAttributes: true +NXcollection(NXobject): + + # any content is purely optional + + # NOTE + # ===== + # NXcollection is an unvalidated class, do not add any subgroups. + # See: https://github.com/nexusformat/definitions/issues/259 + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# fdd5367211b59613e74b746761c655ba70f7ae36889538b8eec14fd904748fbf +# +# +# +# +# +# +# +# +# An unvalidated set of terms, such as the description of a beam line. +# +# Use :ref:`NXcollection` to gather together any set of terms. +# The original suggestion is to use this as a container +# class for the description of a beamline. +# +# For NeXus validation, :ref:`NXcollection` will always generate +# a warning since it is always an optional group. +# Anything (groups, fields, or attributes) placed in +# an :ref:`NXcollection` group will not be validated. +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXcollimator.yaml b/base_classes/nyaml/NXcollimator.yaml new file mode 100644 index 0000000000..baab547487 --- /dev/null +++ b/base_classes/nyaml/NXcollimator.yaml @@ -0,0 +1,196 @@ +category: base +doc: | + A beamline collimator. +type: group +NXcollimator(NXobject): + (NXgeometry): + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the collimator and NXoff_geometry to describe its shape instead + doc: | + position, shape and size + type: + enumeration: [Soller, radial, oscillating, honeycomb] + soller_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Angular divergence of Soller collimator + divergence_x(NX_FLOAT): + unit: NX_ANGLE + doc: | + divergence of collimator in local x direction + divergence_y(NX_FLOAT): + unit: NX_ANGLE + doc: | + divergence of collimator in local y direction + frequency(NX_FLOAT): + unit: NX_FREQUENCY + doc: | + Frequency of oscillating collimator + (NXlog)frequency_log: + doc: | + Log of frequency + blade_thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + blade thickness + blade_spacing(NX_FLOAT): + unit: NX_LENGTH + doc: | + blade spacing + absorbing_material: + doc: | + name of absorbing material + transmitting_material: + doc: | + name of transmitting material + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the beam line component + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + 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. + + Assuming a collimator with a "flat" entry surface, the reference plane is the plane which contains this surface. The reference + point of the collimator in the x and y axis is the centre of the collimator entry surface on that plane. The reference plane is orthogonal + to the z axis and the location of this plane is the reference point on the z axis. The collimator faces negative z values. + + .. image:: collimator/collimator.png + :width: 40% + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 00a9964086dc22e6087e2003333b5cff83695a44785b893c6d1604e7052defb2 +# +# +# +# +# +# A beamline collimator. +# +# position, shape and size +# +# +# +# +# +# +# +# +# +# +# Angular divergence of Soller collimator +# +# +# divergence of collimator in local x direction +# +# +# divergence of collimator in local y direction +# +# +# Frequency of oscillating collimator +# +# +# Log of frequency +# +# +# blade thickness +# +# +# blade spacing +# +# +# name of absorbing material +# +# +# name of transmitting material +# +# +# +# This group describes the shape of the beam line component +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# Assuming a collimator with a "flat" entry surface, the reference plane is the plane which contains this surface. The reference +# point of the collimator in the x and y axis is the centre of the collimator entry surface on that plane. The reference plane is orthogonal +# to the z axis and the location of this plane is the reference point on the z axis. The collimator faces negative z values. +# +# .. image:: collimator/collimator.png +# :width: 40% +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# diff --git a/base_classes/nyaml/NXcrystal.yaml b/base_classes/nyaml/NXcrystal.yaml new file mode 100644 index 0000000000..3a1c66c55a --- /dev/null +++ b/base_classes/nyaml/NXcrystal.yaml @@ -0,0 +1,667 @@ +category: base +doc: | + A crystal monochromator or analyzer. + + Permits double bent + monochromator comprised of multiple segments with anisotropic + Gaussian mosaic. + + If curvatures are set to zero or are absent, array + is considered to be flat. + + Scattering vector is perpendicular to surface. Crystal is oriented + parallel to beam incident on crystal before rotation, and lies in + vertical plane. +symbols: + doc: | + These symbols will be used below to coordinate dimensions with the same lengths. + n_comp: | + number of different unit cells to be described + i: | + number of wavelengths +type: group +NXcrystal(NXobject): + (NXgeometry): + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the crystal and NXoff_geometry to describe its shape instead + doc: | + Position of crystal + usage(NX_CHAR): + doc: | + How this crystal is used. Choices are in the list. + enumeration: + Bragg: + doc: | + reflection geometry + Laue: + doc: | + 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. + See, for example: + http://www.iucr.org/__data/iucr/cif/standard/cifstd15.html or + http://www.cas.org/training/stneasytips/subinforformula1.html. + type: + doc: | + Type or material of monochromating substance. + Chemical formula can be specified separately. + Use the "reflection" field to indicate the (hkl) orientation. + Use the "d_spacing" field to record the lattice plane spacing. + + This field was changed (2010-11-17) from an enumeration to + a string since common usage showed a wider variety of use + than a simple list. These are the items in the list at + the time of the change: PG (Highly Oriented Pyrolytic Graphite) | + Ge | Si | Cu | Fe3Si | CoFe | Cu2MnAl (Heusler) | Multilayer | + Diamond. + chemical_formula: + + # copied from NXsample + doc: | + 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. + order_no(NX_INT): + doc: | + A number which describes if this is the first, second,.. + :math:`n^{th}` crystal in a multi crystal monochromator + cut_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Cut angle of reflecting Bragg plane and plane of crystal surface + space_group: + doc: | + Space group of crystal structure + unit_cell(NX_FLOAT): + unit: NX_LENGTH + doc: | + Unit cell parameters (lengths and angles) + dimensions: + rank: 2 + dim: [[1, n_comp], [2, 6]] + + # NXfilter defines each unit cell parameter separately. Let's be consistent. + unit_cell_a(NX_FLOAT): + unit: NX_LENGTH + + # as used in NXfilter + doc: | + Unit cell lattice parameter: length of side a + unit_cell_b(NX_FLOAT): + unit: NX_LENGTH + + # as used in NXfilter + doc: | + Unit cell lattice parameter: length of side b + unit_cell_c(NX_FLOAT): + unit: NX_LENGTH + + # as used in NXfilter + doc: | + Unit cell lattice parameter: length of side c + unit_cell_alpha(NX_FLOAT): + unit: NX_ANGLE + + # as used in NXfilter + doc: | + Unit cell lattice parameter: angle alpha + unit_cell_beta(NX_FLOAT): + unit: NX_ANGLE + + # as used in NXfilter + doc: | + Unit cell lattice parameter: angle beta + unit_cell_gamma(NX_FLOAT): + unit: NX_ANGLE + + # as used in NXfilter + doc: | + Unit cell lattice parameter: angle gamma + unit_cell_volume(NX_FLOAT): + unit: NX_VOLUME + doc: | + Volume of the unit cell + orientation_matrix(NX_FLOAT): + doc: | + Orientation matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + dimensions: + rank: 2 + + # 3,3 + dim: [[1, 3], [2, 3]] + wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + Optimum diffracted wavelength + dimensions: + dim: [[1, i]] + d_spacing(NX_FLOAT): + unit: NX_LENGTH + doc: | + spacing between crystal planes of the reflection + scattering_vector(NX_FLOAT): + unit: NX_WAVENUMBER + doc: | + Scattering vector, Q, of nominal reflection + reflection(NX_INT): + unit: NX_UNITLESS + doc: | + Miller indices (hkl) values of nominal reflection + dimensions: + dim: [[1, 3]] + thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + Thickness of the crystal. (Required for Laue orientations - see "usage" field) + density(NX_NUMBER): + unit: NX_MASS_DENSITY + doc: | + mass density of the crystal + segment_width(NX_FLOAT): + unit: NX_LENGTH + doc: | + Horizontal width of individual segment + segment_height(NX_FLOAT): + unit: NX_LENGTH + doc: | + Vertical height of individual segment + segment_thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + Thickness of individual segment + segment_gap(NX_FLOAT): + unit: NX_LENGTH + doc: | + Typical gap between adjacent segments + segment_columns(NX_FLOAT): + unit: NX_LENGTH + doc: | + number of segment columns in horizontal direction + segment_rows(NX_FLOAT): + unit: NX_LENGTH + doc: | + number of segment rows in vertical direction + mosaic_horizontal(NX_FLOAT): + unit: NX_ANGLE + doc: | + horizontal mosaic Full Width Half Maximum + mosaic_vertical(NX_FLOAT): + unit: NX_ANGLE + doc: | + vertical mosaic Full Width Half Maximum + curvature_horizontal(NX_FLOAT): + unit: NX_ANGLE + doc: | + Horizontal curvature of focusing crystal + curvature_vertical(NX_FLOAT): + unit: NX_ANGLE + doc: | + Vertical curvature of focusing crystal + is_cylindrical(NX_BOOLEAN): + doc: | + Is this crystal bent cylindrically? + cylindrical_orientation_angle(NX_NUMBER): + unit: NX_ANGLE + doc: | + If cylindrical: cylinder orientation angle + polar_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Polar (scattering) angle at which crystal assembly is positioned. + Note: some instrument geometries call this term 2theta. + Note: it is recommended to use NXtransformations instead. + dimensions: + dim: [[1, i]] + azimuthal_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Azimuthal angle at which crystal assembly is positioned. + Note: it is recommended to use NXtransformations instead. + dimensions: + dim: [[1, i]] + bragg_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Bragg angle of nominal reflection + dimensions: + dim: [[1, i]] + temperature(NX_FLOAT): + unit: NX_TEMPERATURE + doc: | + average/nominal crystal temperature + temperature_coefficient(NX_FLOAT): + unit: NX_ANY + doc: | + how lattice parameter changes with temperature + (NXlog)temperature_log: + doc: | + log file of crystal temperature + (NXdata)reflectivity: + doc: | + crystal reflectivity versus wavelength + (NXdata)transmission: + doc: | + crystal transmission versus wavelength + (NXshape)shape: + deprecated: Use NXoff_geometry instead to describe the shape of the monochromator + doc: | + A NXshape group describing the shape of the crystal arrangement + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the beam line component + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a crystal. + (NXtransformations): + doc: | + Transformations used by this component to define its position and orientation. + + # TODO need more parameters here, such as ... + # list from Rainer Gehrke, DESY (some items may already be present) + # Parameters for crystals + # + Field indicating whether it is Bragg or Laue see usage + # + The crystal structure (enumeration, e.g. Zincblende ..) see space_group + # + Lattice constant see unit_cell + # + Miller indices of reflection (h,k,l) see reflection + # + First (or only) element see order_no + # + Second element (if any) see order_no + # + Temperature factor (optional) see temperature_coefficient + # + Asymmetric angle (if applicable) see cut_angle + # + Mosaic angular spread (if applicable) see mosaic_horizontal and mosaic_vertical + # + Thickness (mandatory for Laue, else optional) see thickness + # Figure for crystals and mirrors (to describe curved surfaces) + # + Field indicating whether concave or convex see curvature_horizontal and curvature_vertical + # + Field indicating whether cylindrical or not see is_cylindrical + # + If cylindrical: cylinder orientation angle see cylindrical_orientation_angle + # Now come the different surface figures with the necessary parameters: + # 1. Flat + # 2. Spherical (spherical radius) + # 3. Elliptical and hyperbolical (semi-major axis, semi-minor axis, angle of major axis and pole) + # 4. Toroidal (major radius, minor radius) + # 5. Parabolical (parabolic parameter a) + # 6. Conical (cone half aperture) + # 7. Polynomial (degree of polynom, array with polynom coefficients) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# ff4ce24fb54dfca75794d2f6fcd2b632e90265354d07459acfdd18a8aaaf46a9 +# +# +# +# +# +# +# These symbols will be used below to coordinate dimensions with the same lengths. +# number of different unit cells to be described +# number of wavelengths +# +# +# +# A crystal monochromator or analyzer. +# +# Permits double bent +# monochromator comprised of multiple segments with anisotropic +# Gaussian mosaic. +# +# If curvatures are set to zero or are absent, array +# is considered to be flat. +# +# Scattering vector is perpendicular to surface. Crystal is oriented +# parallel to beam incident on crystal before rotation, and lies in +# vertical plane. +# +# +# +# Position of crystal +# +# +# How this crystal is used. Choices are in the list. +# +# reflection geometry +# +# +# 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. +# See, for example: +# http://www.iucr.org/__data/iucr/cif/standard/cifstd15.html or +# http://www.cas.org/training/stneasytips/subinforformula1.html. +# +# +# +# +# +# +# Type or material of monochromating substance. +# Chemical formula can be specified separately. +# Use the "reflection" field to indicate the (hkl) orientation. +# Use the "d_spacing" field to record the lattice plane spacing. +# +# This field was changed (2010-11-17) from an enumeration to +# a string since common usage showed a wider variety of use +# than a simple list. These are the items in the list at +# the time of the change: PG (Highly Oriented Pyrolytic Graphite) | +# Ge | Si | Cu | Fe3Si | CoFe | Cu2MnAl (Heusler) | Multilayer | +# Diamond. +# +# +# +# +# +# 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. +# +# +# +# +# A number which describes if this is the first, second,.. +# :math:`n^{th}` crystal in a multi crystal monochromator +# +# +# +# Cut angle of reflecting Bragg plane and plane of crystal surface +# +# +# Space group of crystal structure +# +# +# Unit cell parameters (lengths and angles) +# +# +# +# +# +# +# +# Unit cell lattice parameter: length of side a +# +# +# Unit cell lattice parameter: length of side b +# +# +# Unit cell lattice parameter: length of side c +# +# +# Unit cell lattice parameter: angle alpha +# +# +# Unit cell lattice parameter: angle beta +# +# +# Unit cell lattice parameter: angle gamma +# +# +# Volume of the unit cell +# +# +# +# Orientation matrix of single crystal sample using Busing-Levy convention: +# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 +# +# +# +# +# +# +# +# Optimum diffracted wavelength +# +# +# +# spacing between crystal planes of the reflection +# +# +# Scattering vector, Q, of nominal reflection +# +# +# Miller indices (hkl) values of nominal reflection +# +# +# +# Thickness of the crystal. (Required for Laue orientations - see "usage" field) +# +# +# mass density of the crystal +# +# +# Horizontal width of individual segment +# +# +# Vertical height of individual segment +# +# +# Thickness of individual segment +# +# +# Typical gap between adjacent segments +# +# +# number of segment columns in horizontal direction +# +# +# number of segment rows in vertical direction +# +# +# horizontal mosaic Full Width Half Maximum +# +# +# vertical mosaic Full Width Half Maximum +# +# +# Horizontal curvature of focusing crystal +# +# +# Vertical curvature of focusing crystal +# +# +# Is this crystal bent cylindrically? +# +# +# If cylindrical: cylinder orientation angle +# +# +# +# Polar (scattering) angle at which crystal assembly is positioned. +# Note: some instrument geometries call this term 2theta. +# Note: it is recommended to use NXtransformations instead. +# +# +# +# +# +# Azimuthal angle at which crystal assembly is positioned. +# Note: it is recommended to use NXtransformations instead. +# +# +# +# +# Bragg angle of nominal reflection +# +# +# +# average/nominal crystal temperature +# +# +# how lattice parameter changes with temperature +# +# +# log file of crystal temperature +# +# +# crystal reflectivity versus wavelength +# +# +# crystal transmission versus wavelength +# +# +# A NXshape group describing the shape of the crystal arrangement +# +# +# +# This group describes the shape of the beam line component +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a crystal. +# +# +# +# +# Transformations used by this component to define its position and orientation. +# +# +# +# diff --git a/base_classes/nyaml/NXcylindrical_geometry.yaml b/base_classes/nyaml/NXcylindrical_geometry.yaml new file mode 100644 index 0000000000..189ede84aa --- /dev/null +++ b/base_classes/nyaml/NXcylindrical_geometry.yaml @@ -0,0 +1,169 @@ +category: base +doc: | + Geometry description for cylindrical shapes. + This class can be used in place of ``NXoff_geometry`` when an exact + representation for cylinders is preferred. + For example, for Helium-tube, neutron detectors. + It can be used to describe the shape of any beamline component, including detectors. + In the case of detectors it can be used to define the shape of a single pixel, or, + if the pixel shapes are non-uniform, to describe the shape of the whole detector. +symbols: + doc: | + These symbols will be used below. + i: | + number of vertices required to define all cylinders in the shape + j: | + number of cylinders in the shape + k: | + number cylinders which are detectors +type: group +NXcylindrical_geometry(NXobject): + vertices(NX_NUMBER): + unit: NX_LENGTH + doc: | + List of x,y,z coordinates for vertices. + The origin of the coordinates is the position of the parent component, for + example the NXdetector which the geometry describes. + If the shape describes a single pixel for a detector with uniform pixel shape + then the origin is the position of each pixel as described by the + ``x/y/z_pixel_offset`` datasets in ``NXdetector``. + dimensions: + rank: 2 + dim: [[1, i], [2, 3]] + cylinders(NX_INT): + doc: | + List of indices of vertices in the ``vertices`` dataset to form each cylinder. + Each cylinder is described by three vertices A, B, C. + First vertex A lies on the cylinder axis and circular face, second point B + on edge of the same face as A, and third point C at the other face and on axis. + dimensions: + rank: 2 + dim: [[1, j], [2, 3]] + detector_number(NX_INT): + doc: | + Maps cylinders in ``cylinder``, by index, with a detector id. + dimensions: + rank: 1 + dim: [[1, k]] + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 9bbcf1ff2b2841c8960f59949dfb345ca6966cd04ab611c7e9843c1c81d643e6 +# +# +# +# +# +# +# These symbols will be used below. +# +# +# number of vertices required to define all cylinders in the shape +# +# +# number of cylinders in the shape +# number cylinders which are detectors +# +# +# +# Geometry description for cylindrical shapes. +# This class can be used in place of ``NXoff_geometry`` when an exact +# representation for cylinders is preferred. +# For example, for Helium-tube, neutron detectors. +# It can be used to describe the shape of any beamline component, including detectors. +# In the case of detectors it can be used to define the shape of a single pixel, or, +# if the pixel shapes are non-uniform, to describe the shape of the whole detector. +# +# +# +# +# +# List of x,y,z coordinates for vertices. +# The origin of the coordinates is the position of the parent component, for +# example the NXdetector which the geometry describes. +# If the shape describes a single pixel for a detector with uniform pixel shape +# then the origin is the position of each pixel as described by the +# ``x/y/z_pixel_offset`` datasets in ``NXdetector``. +# +# +# +# +# +# +# +# +# +# +# +# +# List of indices of vertices in the ``vertices`` dataset to form each cylinder. +# Each cylinder is described by three vertices A, B, C. +# First vertex A lies on the cylinder axis and circular face, second point B +# on edge of the same face as A, and third point C at the other face and on axis. +# +# +# +# +# +# +# +# +# +# +# +# Maps cylinders in ``cylinder``, by index, with a detector id. +# +# +# +# +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# diff --git a/base_classes/nyaml/NXdata.yaml b/base_classes/nyaml/NXdata.yaml new file mode 100644 index 0000000000..cc56a0676b --- /dev/null +++ b/base_classes/nyaml/NXdata.yaml @@ -0,0 +1,807 @@ +category: base +doc: | + :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) + +# The ignoreExtra* attributes are used in the definition to +# avoid warning messages that would be generated from unexpected fields or attributes. +# Since common use of NXdata indicates field names of any value, _many_ +# instances of this class would generate a warning message during validation +# without this attribute being set to "true". +symbols: + doc: | + These symbols will be used below to coordinate fields with the same shape. + dataRank: | + rank of the ``DATA`` field + n: | + length of the ``AXISNAME`` field + nx: | + length of the ``x`` field + ny: | + length of the ``y`` field + nz: | + length of the ``z`` field +type: group +ignoreExtraFields: true +ignoreExtraAttributes: true +NXdata(NXobject): + \@auxiliary_signals: + doc: | + .. index:: plotting + + Array of strings holding the :ref:`names ` of additional + signals to be plotted with the default :ref:`signal `. + These fields or links *must* exist and be direct children of this NXdata group. + + Each auxiliary signal needs to be of the same shape as the default signal. + + .. NIAC2018: + https://www.nexusformat.org/NIAC2018Minutes.html + \@signal: + doc: | + .. 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. + \@axes: + doc: | + .. 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. + \@AXISNAME_indices: + type: NX_INT + + # nxdl.xsd rules do not allow us to show this as a variable name + # - we'll use ALL CAPS (see #562) + + # AXISNAME_indices documentation copied from datarules.rst + doc: | + Each ``AXISNAME_indices`` attribute indicates the dependency + relationship of the ``AXISNAME`` field (where ``AXISNAME`` + is the name of a field that exists in this ``NXdata`` group) + with one or more dimensions of the plottable data. + + Integer array that defines the indices of the *signal* field + (that field will be a multidimensional array) + which need to be used in the *AXISNAME* field in + order to reference the corresponding axis value. + + The first index of an array is ``0`` (zero). + + Here, *AXISNAME* is to be replaced by the name of each + field described in the ``axes`` attribute. + An example with 2-D data, :math:`d(t,P)`, will illustrate:: + + data_2d:NXdata + @signal="data" + @axes=["time", "pressure"] + @time_indices=0 + @pressure_indices=1 + data: float[1000,20] + time: float[1000] + pressure: float[20] + + This attribute is to be provided in all situations. + However, if the indices attributes are missing + (such as for data files written before this specification), + file readers are encouraged to make their best efforts + to plot the data. + Thus the implementation of the + ``AXISNAME_indices`` attribute is based on the model of + "strict writer, liberal reader". + + .. note:: Attributes potentially containing multiple values + (axes and _indices) are to be written as string or integer arrays, + to avoid string parsing in reading applications. + AXISNAME(NX_NUMBER): + nameType: any + doc: | + 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. + dimensions: + rank: 1 + doc: | + A *dimension scale* must have a rank of 1 and has length ``n``. + dim: [[1, n]] + \@long_name: + doc: | + Axis label + \@distribution: + type: NX_BOOLEAN + doc: | + ``0|false``: single value, + ``1|true``: multiple values + \@first_good: + type: NX_INT + doc: | + Index of first good value + \@last_good: + type: NX_INT + doc: | + Index of last good value + \@axis: + type: NX_POSINT + deprecated: Use the group ``axes`` attribute (NIAC2014) + doc: | + Index (positive integer) identifying this specific set of numbers. + + N.B. The ``axis`` attribute is the old way of designating a link. + Do not use the ``axes`` attribute with the ``axis`` attribute. + The ``axes`` *group* attribute is now preferred. + FIELDNAME_errors(NX_NUMBER): + nameType: any + doc: | + "Errors" (meaning *uncertainties* or *standard deviations*) + associated with any field named ``FIELDNAME`` in this ``NXdata`` + group (e.g. an axis, signal or auxiliary signal). + + The dimensions of the ``FIELDNAME_errors`` field must match + the dimensions of the ``FIELDNAME`` field. + DATA(NX_NUMBER): + nameType: any + doc: | + .. 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. + dimensions: + rank: dataRank + doc: | + The rank (``dataRank``) of the ``data`` must satisfy + ``1 <= dataRank <= NX_MAXRANK=32``. + At least one ``dim`` must have length ``n``. + dim: [] + \@signal: + type: NX_POSINT + deprecated: Use the group ``signal`` attribute (NIAC2014) + doc: | + .. index:: plotting + + Plottable (independent) axis, indicate index number. + Only one field in a :ref:`NXdata` group may have the + ``signal=1`` attribute. + Do not use the ``signal`` attribute with the ``axis`` attribute. + \@axes: + deprecated: Use the group ``axes`` attribute (NIAC2014) + doc: | + Defines the names of the dimension scales + (independent axes) for this data set + as a colon-delimited array. + NOTE: The ``axes`` attribute is the preferred + method of designating a link. + Do not use the ``axes`` attribute with the ``axis`` attribute. + \@long_name: + doc: | + data label + errors(NX_NUMBER): + deprecated: Use ``DATA_errors`` instead (NIAC2018) + doc: | + Standard deviations of data values - + the data array is identified by the group attribute ``signal``. + The ``errors`` array must have the same dimensions as ``DATA``. + Client is responsible for defining the dimensions of the data. + dimensions: + rank: dataRank + doc: | + The ``errors`` must have + the same rank (``dataRank``) + as the ``data``. + At least one ``dim`` must have length "n". + dim: [] + scaling_factor(NX_FLOAT): + doc: | + The elements in data are usually float values really. For + efficiency reasons these are usually stored as integers + after scaling with a scale factor. This value is the scale + factor. It is required to get the actual physical value, + when necessary. + offset(NX_FLOAT): + doc: | + An optional offset to apply to the values in data. + title: + doc: | + Title for the plot. + x(NX_FLOAT): + unit: NX_ANY + doc: | + This is an array holding the values to use for the x-axis of + data. The units must be appropriate for the measurement. + dimensions: + rank: 1 + dim: [[1, nx]] + y(NX_FLOAT): + unit: NX_ANY + doc: | + This is an array holding the values to use for the y-axis of + data. The units must be appropriate for the measurement. + dimensions: + rank: 1 + dim: [[1, ny]] + z(NX_FLOAT): + unit: NX_ANY + doc: | + This is an array holding the values to use for the z-axis of + data. The units must be appropriate for the measurement. + dimensions: + rank: 1 + dim: [[1, nz]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# d6fe670cbf59475c1b29039a0baddf5bfef45444afa616430ef5d73b2465788c +# +# +# +# +# +# +# +# +# These symbols will be used below to coordinate fields with the same shape. +# rank of the ``DATA`` field +# length of the ``AXISNAME`` field +# length of the ``x`` field +# length of the ``y`` field +# length of the ``z`` field +# +# +# +# +# .. index:: plotting +# +# Array of strings holding the :ref:`names <validItemName>` of additional +# signals to be plotted with the default :ref:`signal </NXdata@signal-attribute>`. +# These fields or links *must* exist and be direct children of this NXdata group. +# +# Each auxiliary signal needs to be of the same shape as the default signal. +# +# .. NIAC2018: +# https://www.nexusformat.org/NIAC2018Minutes.html +# +# +# +# +# .. 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 <validItemName>` 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. +# +# +# +# +# .. index:: plotting +# +# Array of strings holding the :ref:`names <validItemName>` of +# the independent data fields used in the default plot for all of +# the dimensions of the :ref:`signal </NXdata@signal-attribute>` +# as well as any :ref:`auxiliary signals </NXdata@auxiliary_signals-attribute>`. +# +# 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. +# +# +# +# +# +# +# Each ``AXISNAME_indices`` attribute indicates the dependency +# relationship of the ``AXISNAME`` field (where ``AXISNAME`` +# is the name of a field that exists in this ``NXdata`` group) +# with one or more dimensions of the plottable data. +# +# Integer array that defines the indices of the *signal* field +# (that field will be a multidimensional array) +# which need to be used in the *AXISNAME* field in +# order to reference the corresponding axis value. +# +# The first index of an array is ``0`` (zero). +# +# Here, *AXISNAME* is to be replaced by the name of each +# field described in the ``axes`` attribute. +# An example with 2-D data, :math:`d(t,P)`, will illustrate:: +# +# data_2d:NXdata +# @signal="data" +# @axes=["time", "pressure"] +# @time_indices=0 +# @pressure_indices=1 +# data: float[1000,20] +# time: float[1000] +# pressure: float[20] +# +# This attribute is to be provided in all situations. +# However, if the indices attributes are missing +# (such as for data files written before this specification), +# file readers are encouraged to make their best efforts +# to plot the data. +# Thus the implementation of the +# ``AXISNAME_indices`` attribute is based on the model of +# "strict writer, liberal reader". +# +# .. note:: Attributes potentially containing multiple values +# (axes and _indices) are to be written as string or integer arrays, +# to avoid string parsing in reading applications. +# +# +# +# +# :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) +# +# +# +# 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. +# +# +# +# A *dimension scale* must have a rank of 1 and has length ``n``. +# +# +# +# Axis label +# +# +# ``0|false``: single value, +# ``1|true``: multiple values +# +# +# Index of first good value +# Index of last good value +# +# +# Index (positive integer) identifying this specific set of numbers. +# +# N.B. The ``axis`` attribute is the old way of designating a link. +# Do not use the ``axes`` attribute with the ``axis`` attribute. +# The ``axes`` *group* attribute is now preferred. +# +# +# +# +# +# "Errors" (meaning *uncertainties* or *standard deviations*) +# associated with any field named ``FIELDNAME`` in this ``NXdata`` +# group (e.g. an axis, signal or auxiliary signal). +# +# The dimensions of the ``FIELDNAME_errors`` field must match +# the dimensions of the ``FIELDNAME`` field. +# +# +# +# +# .. 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. +# +# +# +# The rank (``dataRank``) of the ``data`` must satisfy +# ``1 <= dataRank <= NX_MAXRANK=32``. +# At least one ``dim`` must have length ``n``. +# +# +# +# +# .. index:: plotting +# +# Plottable (independent) axis, indicate index number. +# Only one field in a :ref:`NXdata` group may have the +# ``signal=1`` attribute. +# Do not use the ``signal`` attribute with the ``axis`` attribute. +# +# +# +# +# Defines the names of the dimension scales +# (independent axes) for this data set +# as a colon-delimited array. +# NOTE: The ``axes`` attribute is the preferred +# method of designating a link. +# Do not use the ``axes`` attribute with the ``axis`` attribute. +# +# +# +# data label +# +# +# +# +# Standard deviations of data values - +# the data array is identified by the group attribute ``signal``. +# The ``errors`` array must have the same dimensions as ``DATA``. +# Client is responsible for defining the dimensions of the data. +# +# +# +# The ``errors`` must have +# the same rank (``dataRank``) +# as the ``data``. +# At least one ``dim`` must have length "n". +# +# +# +# +# +# The elements in data are usually float values really. For +# efficiency reasons these are usually stored as integers +# after scaling with a scale factor. This value is the scale +# factor. It is required to get the actual physical value, +# when necessary. +# +# +# +# +# An optional offset to apply to the values in data. +# +# +# +# +# Title for the plot. +# +# +# +# +# This is an array holding the values to use for the x-axis of +# data. The units must be appropriate for the measurement. +# +# +# +# +# +# +# +# This is an array holding the values to use for the y-axis of +# data. The units must be appropriate for the measurement. +# +# +# +# +# +# +# +# This is an array holding the values to use for the z-axis of +# data. The units must be appropriate for the measurement. +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXdetector.yaml b/base_classes/nyaml/NXdetector.yaml new file mode 100644 index 0000000000..4caf8ef6ed --- /dev/null +++ b/base_classes/nyaml/NXdetector.yaml @@ -0,0 +1,1757 @@ +category: base +doc: | + A detector, detector bank, or multidetector. +symbols: + doc: | + These symbols will be used below to illustrate the coordination of the + rank and sizes of datasets and the preferred ordering of the + dimensions. Each of these are optional (so the rank of the datasets + will vary according to the situation) and the general ordering + principle is slowest to fastest. The type of each dimension should + follow the order of scan points, detector output (e.g. pixels), then + time-of-flight (i.e. spectroscopy, spectrometry). Note that the output + of a detector is not limited to single values (0D), lists (1D) and + images (2), but three or higher dimensional arrays can be produced by + a detector at each trigger. + nP: | + number of scan points (only present in scanning measurements) + i: | + number of detector pixels in the first (slowest) direction + j: | + number of detector pixels in the second (faster) direction + k: | + number of detector pixels in the third (if necessary, fastest) + direction + tof: | + number of bins in the time-of-flight histogram +type: group +(NXobject)NXdetector: + time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + doc: | + Total time of flight + dimensions: + rank: 1 + dim: [[1, tof+1]] + \@axis: + type: NX_POSINT + deprecated: | + see: https://github.com/nexusformat/definitions/issues/436 + enumeration: [3] + \@primary: + type: NX_POSINT + deprecated: | + see: https://github.com/nexusformat/definitions/issues/436 + enumeration: [1] + \@long_name: + doc: | + Total time of flight + raw_time_of_flight(NX_INT): + unit: NX_PULSES + doc: | + In DAQ clock pulses + dimensions: + rank: 1 + dim: [[1, tof+1]] + \@frequency: + type: NX_NUMBER + doc: | + Clock frequency in Hz + detector_number(NX_INT): + doc: | + Identifier for detector (pixels) + Can be multidimensional, if needed + data(NX_NUMBER): + unit: NX_ANY + doc: | + 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. + dimensions: + rank: 4 + dim: [[1, nP], [2, i], [3, j], [4, tof]] + \@long_name: + doc: | + Title of measurement + \@check_sum: + type: NX_INT + doc: | + Integral of data as check of data integrity + data_errors(NX_NUMBER): + unit: NX_ANY + doc: | + The best estimate of the uncertainty in the data value (array size should match the data field). Where + possible, this should be the standard deviation, which has the same units + as the data. The form data_error is deprecated. + dimensions: + rank: 4 + dim: [[1, nP], [2, i], [3, j], [4, tof]] + x_pixel_offset(NX_FLOAT): + unit: NX_LENGTH + doc: | + Offset from the detector center in x-direction. + Can be multidimensional when needed. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + \@axis: + type: NX_POSINT + deprecated: | + see: https://github.com/nexusformat/definitions/issues/436 + enumeration: [1] + \@primary: + type: NX_POSINT + deprecated: | + see: https://github.com/nexusformat/definitions/issues/436 + enumeration: [1] + \@long_name: + doc: | + x-axis offset from detector center + y_pixel_offset(NX_FLOAT): + unit: NX_LENGTH + doc: | + Offset from the detector center in the y-direction. + Can be multidimensional when different values are required for each pixel. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + \@axis: + type: NX_POSINT + deprecated: | + see: https://github.com/nexusformat/definitions/issues/436 + enumeration: [2] + \@primary: + type: NX_POSINT + deprecated: | + see: https://github.com/nexusformat/definitions/issues/436 + enumeration: [1] + \@long_name: + doc: | + y-axis offset from detector center + z_pixel_offset(NX_FLOAT): + unit: NX_LENGTH + doc: | + Offset from the detector center in the z-direction. + Can be multidimensional when different values are required for each pixel. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + \@axis: + type: NX_POSINT + deprecated: | + see: https://github.com/nexusformat/definitions/issues/436 + enumeration: [3] + \@primary: + type: NX_POSINT + deprecated: | + see: https://github.com/nexusformat/definitions/issues/436 + enumeration: [1] + \@long_name: + doc: | + y-axis offset from detector center + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the distance to the previous component in the + instrument; most often the sample. The usage depends on the + nature of the detector: Most often it is the distance of the + detector assembly. But there are irregular detectors. In this + case the distance must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. + dimensions: + rank: 3 + dim: [[1, nP], [2, i], [3, j]] + polar_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + This is the polar angle of the detector towards the previous + component in the instrument; most often the sample. + The usage depends on the + nature of the detector. + Most often it is the polar_angle of the detector assembly. + But there are irregular detectors. + In this + case, the polar_angle must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. + dimensions: + rank: 3 + dim: [[1, nP], [2, i], [3, j]] + azimuthal_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + This is the azimuthal angle angle of the detector towards + the previous component in the instrument; most often the sample. + The usage depends on the + nature of the detector. + Most often it is the azimuthal_angle of the detector assembly. + But there are irregular detectors. + In this + case, the azimuthal_angle must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. + dimensions: + rank: 3 + dim: [[1, nP], [2, i], [3, j]] + description: + doc: | + name/manufacturer/model/etc. information + serial_number: + doc: | + Serial number for the detector + local_name: + doc: | + Local name for the detector + (NXgeometry): + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the detector and NXoff_geometry to describe its shape instead + doc: | + Position and orientation of detector + solid_angle(NX_FLOAT): + unit: NX_SOLID_ANGLE + doc: | + Solid angle subtended by the detector at the sample + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + x_pixel_size(NX_FLOAT): + unit: NX_LENGTH + doc: | + Size of each detector pixel. If it is scalar all pixels are the same size. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + y_pixel_size(NX_FLOAT): + unit: NX_LENGTH + doc: | + Size of each detector pixel. If it is scalar all pixels are the same size + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + dead_time(NX_FLOAT): + unit: NX_TIME + doc: | + Detector dead time + dimensions: + rank: 3 + dim: [[1, nP], [2, i], [3, j]] + gas_pressure(NX_FLOAT): + unit: NX_PRESSURE + doc: | + Detector gas pressure + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + detection_gas_path(NX_FLOAT): + unit: NX_LENGTH + doc: | + maximum drift space dimension + crate(NX_INT): + doc: | + Crate number of detector + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + \@local_name: + doc: | + Equivalent local term + slot(NX_INT): + doc: | + Slot number of detector + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + \@local_name: + doc: | + Equivalent local term + input(NX_INT): + doc: | + Input number of detector + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + \@local_name: + doc: | + Equivalent local term + type: + doc: | + Description of type such as He3 gas cylinder, He3 PSD, scintillator, + fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, + CMOS, ... + efficiency(NXdata): + doc: | + Spectral efficiency of detector with respect to e.g. wavelength + \@signal: + enumeration: [efficiency] + \@axes: + + # TODO: clarify the various use cases + enumeration: [., . ., . . ., . . . ., wavelength] + \@wavelength_indices: + + # TODO: clarify the actual possibilities + enumeration: [0] + efficiency(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + efficiency of the detector + dimensions: + rank: 3 + dim: [[1, i], [2, j], [3, k]] + wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + This field can be two things: + + 1. For a pixel detector it provides the nominal wavelength + for which the detector has been calibrated. + + 2. For other detectors this field has to be seen together with + the efficiency field above. + For some detectors, the efficiency is wavelength dependent. + Thus this field provides the wavelength axis for the efficiency field. + In this use case, the efficiency and wavelength arrays must + have the same dimensionality. + dimensions: + rank: 3 + dim: [[1, i], [2, j], [3, k]] + real_time(NX_NUMBER): + unit: NX_TIME + doc: | + Real-time of the exposure (use this if exposure time varies for + each array element, otherwise use ``count_time`` field). + + Most often there is a single real time value that is constant across + an entire image frame. In such cases, only a 1-D array is needed. + But there are detectors in which the real time + changes per pixel. In that case, more than one dimension is needed. Therefore + the rank of this field should be less than or equal to (detector rank + 1). + dimensions: + rank: 3 + dim: [[1, nP], [2, i], [3, j]] + start_time(NX_FLOAT): + unit: NX_TIME + doc: | + start time for each frame, with the ``start`` attribute as absolute reference + dimensions: + rank: 1 + dim: [[1, nP]] + \@start: + type: NX_DATE_TIME + stop_time(NX_FLOAT): + unit: NX_TIME + doc: | + stop time for each frame, with the ``start`` attribute as absolute reference + dimensions: + rank: 1 + dim: [[1, nP]] + \@start: + type: NX_DATE_TIME + calibration_date(NX_DATE_TIME): + doc: | + date of last calibration (geometry and/or efficiency) measurements + calibration_method(NXnote): + doc: | + summary of conversion of array data to pixels (e.g. polynomial + approximations) and location of details of the calibrations + layout: + doc: | + How the detector is represented + enumeration: [point, linear, area] + count_time(NX_NUMBER): + unit: NX_TIME + doc: | + Elapsed actual counting time + dimensions: + rank: 1 + dim: [[1, nP]] + data_file(NXnote): + (NXcollection): + doc: | + Use this group to provide other data related to this NXdetector group. + sequence_number(NX_INT): + doc: | + In order to properly sort the order of the images taken in (for + example) a tomography experiment, a sequence number is stored with each + image. + dimensions: + rank: 1 + dim: [[1, nBrightFrames]] + beam_center_x(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the x position where the direct beam would hit the detector. + This is a length and can be outside of the actual + detector. The length can be in physical units or pixels + as documented by the units attribute. + beam_center_y(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the y position where the direct beam would hit the detector. + This is a length and can be outside of the actual + detector. The length can be in physical units or pixels + as documented by the units attribute. + frame_start_number(NX_INT): + doc: | + This is the start number of the first frame of a scan. In protein crystallography measurements one + often scans a couple of frames on a give sample, then does something else, + then returns to the same sample and scans some more frames. Each time with + a new data file. This number helps concatenating such measurements. + diameter(NX_FLOAT): + unit: NX_LENGTH + doc: | + The diameter of a cylindrical detector + acquisition_mode(NX_CHAR): + doc: | + The acquisition mode of the detector. + enumeration: [gated, triggered, summed, event, histogrammed, decimated] + angular_calibration_applied(NX_BOOLEAN): + doc: | + True when the angular calibration has been applied in the + electronics, false otherwise. + angular_calibration(NX_FLOAT): + doc: | + Angular calibration data. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + flatfield_applied(NX_BOOLEAN): + doc: | + True when the flat field correction has been applied in the + electronics, false otherwise. + flatfield(NX_FLOAT): + doc: | + Flat field correction data. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + flatfield_errors(NX_FLOAT): + doc: | + Errors of the flat field correction data. + The form flatfield_error is deprecated. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + pixel_mask_applied(NX_BOOLEAN): + doc: | + True when the pixel mask correction has been applied in the + electronics, false otherwise. + pixel_mask(NX_INT): + doc: | + The 32-bit pixel mask for the detector. Can be either one mask + for the whole dataset (i.e. an array with indices i, j) or + each frame can have its own mask (in which case it would be + an array with indices np, i, j). + + Contains a bit field for each pixel to signal dead, + blind or high or otherwise unwanted or undesirable pixels. + They have the following meaning: + + .. can't make a table here, a bullet list will have to do for now + + * bit 0: gap (pixel with no sensor) + * bit 1: dead + * bit 2: under responding + * bit 3: over responding + * bit 4: noisy + * bit 5: -undefined- + * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) + * bit 7: -undefined- + * bit 8: user defined mask (e.g. around beamstop) + * bits 9-30: -undefined- + * bit 31: virtual pixel (corner pixel with interpolated value) + + Normal data analysis software would + not take pixels into account + when a bit in (mask & 0x0000FFFF) is + set. Tag bit in the upper + two bytes would indicate special pixel + properties that normally + would not be a sole reason to reject the + intensity value (unless + lower bits are set. + + If the full bit depths is not required, providing a + mask with fewer bits is permissible. + + If needed, additional pixel masks can be specified by + including additional entries named pixel_mask_N, where + N is an integer. For example, a general bad pixel mask + could be specified in pixel_mask that indicates noisy + and dead pixels, and an additional pixel mask from + experiment-specific shadowing could be specified in + pixel_mask_2. The cumulative mask is the bitwise OR + of pixel_mask and any pixel_mask_N entries. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + image_key(NX_INT): + doc: | + This field allow to distinguish different types of exposure to the same detector "data" field. + Some techniques require frequent (re-)calibration inbetween measuremnts and this way of + recording the different measurements preserves the chronological order with is important for + correct processing. + + This is used for example in tomography (`:ref:`NXtomo`) sample projections, + dark and flat images, a magic number is recorded per frame. + + The key is as follows: + + * projection (sample) = 0 + * flat field = 1 + * dark field = 2 + * invalid = 3 + * background (no sample, but buffer where applicable) = 4 + + In cases where the data is of type :ref:`NXlog` this can also be an NXlog. + dimensions: + rank: 1 + dim: [[1, np]] + countrate_correction_applied(NX_BOOLEAN): + doc: | + Counting detectors usually are not able to measure all incoming particles, + especially at higher count-rates. Count-rate correction is applied to + account for these errors. + + True when count-rate correction has been applied, false otherwise. + countrate_correction_lookup_table(NX_NUMBER): + doc: | + The countrate_correction_lookup_table defines the LUT used for count-rate + correction. It maps a measured count :math:`c` to its corrected value + :math:`countrate\_correction\_lookup\_table[c]`. + + :math:`m` denotes the length of the table. + dimensions: + rank: 1 + dim: [[1, m]] + virtual_pixel_interpolation_applied(NX_BOOLEAN): + doc: | + True when virtual pixel interpolation has been applied, false otherwise. + + When virtual pixel interpolation is applied, values of some pixels may + contain interpolated values. For example, to account for space between + readout chips on a module, physical pixels on edges and corners between + chips may have larger sensor areas and counts may be distributed between + their logical pixels. + bit_depth_readout(NX_INT): + doc: | + How many bits the electronics reads per pixel. + With CCD's and single photon counting detectors, + this must not align with traditional integer sizes. + This can be 4, 8, 12, 14, 16, ... + detector_readout_time(NX_FLOAT): + unit: NX_TIME + doc: | + Time it takes to read the detector (typically milliseconds). + This is important to know for time resolved experiments. + trigger_delay_time(NX_FLOAT): + unit: NX_TIME + doc: | + Time it takes to start exposure after a trigger signal has been received. + This is the reaction time of the detector firmware after receiving the trigger signal + to when the detector starts to acquire the exposure, including any user set delay.. + This is important to know for time resolved experiments. + trigger_delay_time_set(NX_FLOAT): + unit: NX_TIME + doc: | + User-specified trigger delay. + trigger_internal_delay_time(NX_FLOAT): + unit: NX_TIME + doc: | + Time it takes to start exposure after a trigger signal has been received. + This is the reaction time of the detector hardware after receiving the + trigger signal to when the detector starts to acquire the exposure. + It forms the lower boundary of the trigger_delay_time when the user + does not request an additional delay. + trigger_dead_time(NX_FLOAT): + unit: NX_TIME + doc: | + Time during which no new trigger signal can be accepted. + Typically this is the + trigger_delay_time + exposure_time + readout_time. + This is important to know for time resolved experiments. + frame_time(NX_FLOAT): + unit: NX_TIME + doc: | + This is time for each frame. This is exposure_time + readout time. + dimensions: + rank: 1 + dim: [[1, nP]] + gain_setting(NX_CHAR): + doc: | + The gain setting of the detector. This is a detector-specific value + meant to document the gain setting of the detector during data + collection, for detectors with multiple available gain settings. + + Examples of gain settings include: + + * ``standard`` + * ``fast`` + * ``auto`` + * ``high`` + * ``medium`` + * ``low`` + * ``mixed high to medium`` + * ``mixed medium to low`` + + Developers are encouraged to use one of these terms, or to submit + additional terms to add to the list. + saturation_value(NX_NUMBER): + doc: | + The value at which the detector goes into saturation. + Especially common to CCD detectors, the data + is known to be invalid above this value. + + For example, given a saturation_value and an underload_value, the valid + pixels are those less than or equal to the saturation_value and greater + than or equal to the underload_value. + + The precise type should match the type of the data. + underload_value(NX_NUMBER): + doc: | + The lowest value at which pixels for this detector would be reasonably + measured. The data is known to be invalid below this value. + + For example, given a saturation_value and an underload_value, the valid + pixels are those less than or equal to the saturation_value and greater + than or equal to the underload_value. + + The precise type should match the type of the data. + number_of_cycles(NX_INT): + doc: | + CCD images are sometimes constructed by summing + together multiple short exposures in the + electronics. This reduces background etc. + This is the number of short exposures used to sum + images for an image. + sensor_material(NX_CHAR): + doc: | + At times, radiation is not directly sensed by the detector. + Rather, the detector might sense the output from some + converter like a scintillator. + This is the name of this converter material. + sensor_thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + At times, radiation is not directly sensed by the detector. + Rather, the detector might sense the output from some + converter like a scintillator. + This is the thickness of this converter material. + threshold_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + Single photon counter detectors can be adjusted + for a certain energy range in which they + work optimally. This is the energy setting for this. + (NXdetector_module): + doc: | + For use in special cases where the data in NXdetector + is represented in several parts, each with a separate geometry. + pixel_shape(choice): + (NXoff_geometry): + doc: | + Shape description of each pixel. Use only if all pixels in the detector + are of uniform shape. + (NXcylindrical_geometry): + doc: | + Shape description of each pixel. Use only if all pixels in the detector + are of uniform shape and require being described by cylinders. + detector_shape(choice): + (NXoff_geometry): + doc: | + Shape description of the whole detector. Use only if pixels in the + detector are not of uniform shape. + (NXcylindrical_geometry): + doc: | + Shape description of the whole detector. Use only if pixels in the + detector are not of uniform shape and require being described by cylinders. + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + amplifier_type(NX_CHAR): + doc: | + Type of electron amplifier, MCP, channeltron, etc. + detector_type(NX_CHAR): + doc: | + Description of the detector type, DLD, Phosphor+CCD, CMOS. + detector_voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Voltage applied to detector. + amplifier_voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Voltage applied to the amplifier. + amplifier_bias(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + The low voltage of the amplifier migh not be the ground. + sensor_size(NX_FLOAT): + unit: NX_LENGTH + doc: | + Size of each imaging sensor chip on the detector. + sensor_count(NX_INT): + unit: NX_UNITLESS + doc: | + Number of imaging sensor chips on the detector. + sensor_pixel_size(NX_FLOAT): + unit: NX_LENGTH + doc: | + Physical size of the pixels of the imaging chip on the detector. + sensor_pixels(NX_INT): + unit: NX_UNITLESS + doc: | + Number of raw active elements in each dimension. Important for swept scans. + (NXdata): + doc: | + raw data output from the detector + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference point of the detector is the center of the first pixel. + In complex geometries the NXoff_geometry groups can be used to provide an unambiguous reference. + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 6b256ef0615dca7d8faf4a3bc04d3e62f29a1745e9cd35205e5f0bb9e2c6520c +# +# +# +# +# +# +# These symbols will be used below to illustrate the coordination of the +# rank and sizes of datasets and the preferred ordering of the +# dimensions. Each of these are optional (so the rank of the datasets +# will vary according to the situation) and the general ordering +# principle is slowest to fastest. The type of each dimension should +# follow the order of scan points, detector output (e.g. pixels), then +# time-of-flight (i.e. spectroscopy, spectrometry). Note that the output +# of a detector is not limited to single values (0D), lists (1D) and +# images (2), but three or higher dimensional arrays can be produced by +# a detector at each trigger. +# +# +# +# number of scan points (only present in scanning measurements) +# +# +# +# +# number of detector pixels in the first (slowest) direction +# +# +# +# +# number of detector pixels in the second (faster) direction +# +# +# +# +# number of detector pixels in the third (if necessary, fastest) +# direction +# +# +# +# +# number of bins in the time-of-flight histogram +# +# +# +# +# A detector, detector bank, or multidetector. +# +# +# +# Total time of flight +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Total time of flight +# +# +# +# +# +# In DAQ clock pulses +# +# +# +# +# +# +# Clock frequency in Hz +# +# +# +# +# +# Identifier for detector (pixels) +# Can be multidimensional, if needed +# +# +# +# +# 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. +# +# +# +# +# +# +# +# +# +# Title of measurement +# +# +# +# +# Integral of data as check of data integrity +# +# +# +# +# +# The best estimate of the uncertainty in the data value (array size should match the data field). Where +# possible, this should be the standard deviation, which has the same units +# as the data. The form data_error is deprecated. +# +# +# +# +# +# +# +# +# +# +# Offset from the detector center in x-direction. +# Can be multidimensional when needed. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# x-axis offset from detector center +# +# +# +# +# +# Offset from the detector center in the y-direction. +# Can be multidimensional when different values are required for each pixel. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# y-axis offset from detector center +# +# +# +# +# +# Offset from the detector center in the z-direction. +# Can be multidimensional when different values are required for each pixel. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# y-axis offset from detector center +# +# +# +# +# +# This is the distance to the previous component in the +# instrument; most often the sample. The usage depends on the +# nature of the detector: Most often it is the distance of the +# detector assembly. But there are irregular detectors. In this +# case the distance must be specified for each detector pixel. +# +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# +# +# +# +# +# This is the polar angle of the detector towards the previous +# component in the instrument; most often the sample. +# The usage depends on the +# nature of the detector. +# Most often it is the polar_angle of the detector assembly. +# But there are irregular detectors. +# In this +# case, the polar_angle must be specified for each detector pixel. +# +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# +# +# +# +# +# This is the azimuthal angle angle of the detector towards +# the previous component in the instrument; most often the sample. +# The usage depends on the +# nature of the detector. +# Most often it is the azimuthal_angle of the detector assembly. +# But there are irregular detectors. +# In this +# case, the azimuthal_angle must be specified for each detector pixel. +# +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# +# +# +# +# +# name/manufacturer/model/etc. information +# +# +# +# +# Serial number for the detector +# +# +# +# +# Local name for the detector +# +# +# +# +# Position and orientation of detector +# +# +# +# +# Solid angle subtended by the detector at the sample +# +# +# +# +# +# +# +# +# Size of each detector pixel. If it is scalar all pixels are the same size. +# +# +# +# +# +# +# +# +# Size of each detector pixel. If it is scalar all pixels are the same size +# +# +# +# +# +# +# +# +# Detector dead time +# +# +# +# +# +# +# +# +# +# Detector gas pressure +# +# +# +# +# +# +# +# +# maximum drift space dimension +# +# +# +# +# Crate number of detector +# +# +# +# +# +# +# +# Equivalent local term +# +# +# +# +# +# Slot number of detector +# +# +# +# +# +# +# +# Equivalent local term +# +# +# +# +# +# Input number of detector +# +# +# +# +# +# +# +# Equivalent local term +# +# +# +# +# +# Description of type such as He3 gas cylinder, He3 PSD, scintillator, +# fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, +# CMOS, ... +# +# +# +# +# Spectral efficiency of detector with respect to e.g. wavelength +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# efficiency of the detector +# +# +# +# +# +# +# +# +# +# This field can be two things: +# +# 1. For a pixel detector it provides the nominal wavelength +# for which the detector has been calibrated. +# +# 2. For other detectors this field has to be seen together with +# the efficiency field above. +# For some detectors, the efficiency is wavelength dependent. +# Thus this field provides the wavelength axis for the efficiency field. +# In this use case, the efficiency and wavelength arrays must +# have the same dimensionality. +# +# +# +# +# +# +# +# +# +# +# Real-time of the exposure (use this if exposure time varies for +# each array element, otherwise use ``count_time`` field). +# +# Most often there is a single real time value that is constant across +# an entire image frame. In such cases, only a 1-D array is needed. +# But there are detectors in which the real time +# changes per pixel. In that case, more than one dimension is needed. Therefore +# the rank of this field should be less than or equal to (detector rank + 1). +# +# +# +# +# +# +# +# +# +# start time for each frame, with the ``start`` attribute as absolute reference +# +# +# +# +# +# +# +# +# stop time for each frame, with the ``start`` attribute as absolute reference +# +# +# +# +# +# +# +# +# date of last calibration (geometry and/or efficiency) measurements +# +# +# +# +# summary of conversion of array data to pixels (e.g. polynomial +# approximations) and location of details of the calibrations +# +# +# +# +# How the detector is represented +# +# +# +# +# +# +# +# +# +# Elapsed actual counting time +# +# +# +# +# +# +# +# +# Use this group to provide other data related to this NXdetector group. +# +# +# +# +# In order to properly sort the order of the images taken in (for +# example) a tomography experiment, a sequence number is stored with each +# image. +# +# +# +# +# +# +# +# This is the x position where the direct beam would hit the detector. +# This is a length and can be outside of the actual +# detector. The length can be in physical units or pixels +# as documented by the units attribute. +# +# +# +# +# This is the y position where the direct beam would hit the detector. +# This is a length and can be outside of the actual +# detector. The length can be in physical units or pixels +# as documented by the units attribute. +# +# +# +# +# This is the start number of the first frame of a scan. In protein crystallography measurements one +# often scans a couple of frames on a give sample, then does something else, +# then returns to the same sample and scans some more frames. Each time with +# a new data file. This number helps concatenating such measurements. +# +# +# +# +# The diameter of a cylindrical detector +# +# +# +# +# The acquisition mode of the detector. +# +# +# +# +# +# +# +# +# +# +# +# +# True when the angular calibration has been applied in the +# electronics, false otherwise. +# +# +# +# +# Angular calibration data. +# +# +# +# +# +# +# +# +# True when the flat field correction has been applied in the +# electronics, false otherwise. +# +# +# +# +# Flat field correction data. +# +# +# +# +# +# +# +# +# Errors of the flat field correction data. +# The form flatfield_error is deprecated. +# +# +# +# +# +# +# +# +# True when the pixel mask correction has been applied in the +# electronics, false otherwise. +# +# +# +# +# The 32-bit pixel mask for the detector. Can be either one mask +# for the whole dataset (i.e. an array with indices i, j) or +# each frame can have its own mask (in which case it would be +# an array with indices np, i, j). +# +# Contains a bit field for each pixel to signal dead, +# blind or high or otherwise unwanted or undesirable pixels. +# They have the following meaning: +# +# .. can't make a table here, a bullet list will have to do for now +# +# * bit 0: gap (pixel with no sensor) +# * bit 1: dead +# * bit 2: under responding +# * bit 3: over responding +# * bit 4: noisy +# * bit 5: -undefined- +# * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) +# * bit 7: -undefined- +# * bit 8: user defined mask (e.g. around beamstop) +# * bits 9-30: -undefined- +# * bit 31: virtual pixel (corner pixel with interpolated value) +# +# Normal data analysis software would +# not take pixels into account +# when a bit in (mask & 0x0000FFFF) is +# set. Tag bit in the upper +# two bytes would indicate special pixel +# properties that normally +# would not be a sole reason to reject the +# intensity value (unless +# lower bits are set. +# +# If the full bit depths is not required, providing a +# mask with fewer bits is permissible. +# +# If needed, additional pixel masks can be specified by +# including additional entries named pixel_mask_N, where +# N is an integer. For example, a general bad pixel mask +# could be specified in pixel_mask that indicates noisy +# and dead pixels, and an additional pixel mask from +# experiment-specific shadowing could be specified in +# pixel_mask_2. The cumulative mask is the bitwise OR +# of pixel_mask and any pixel_mask_N entries. +# +# +# +# +# +# +# +# +# This field allow to distinguish different types of exposure to the same detector "data" field. +# Some techniques require frequent (re-)calibration inbetween measuremnts and this way of +# recording the different measurements preserves the chronological order with is important for +# correct processing. +# +# This is used for example in tomography (`:ref:`NXtomo`) sample projections, +# dark and flat images, a magic number is recorded per frame. +# +# The key is as follows: +# +# * projection (sample) = 0 +# * flat field = 1 +# * dark field = 2 +# * invalid = 3 +# * background (no sample, but buffer where applicable) = 4 +# +# In cases where the data is of type :ref:`NXlog` this can also be an NXlog. +# +# +# +# +# +# +# +# Counting detectors usually are not able to measure all incoming particles, +# especially at higher count-rates. Count-rate correction is applied to +# account for these errors. +# +# True when count-rate correction has been applied, false otherwise. +# +# +# +# +# The countrate_correction_lookup_table defines the LUT used for count-rate +# correction. It maps a measured count :math:`c` to its corrected value +# :math:`countrate\_correction\_lookup\_table[c]`. +# +# :math:`m` denotes the length of the table. +# +# +# +# +# +# +# +# True when virtual pixel interpolation has been applied, false otherwise. +# +# When virtual pixel interpolation is applied, values of some pixels may +# contain interpolated values. For example, to account for space between +# readout chips on a module, physical pixels on edges and corners between +# chips may have larger sensor areas and counts may be distributed between +# their logical pixels. +# +# +# +# +# How many bits the electronics reads per pixel. +# With CCD's and single photon counting detectors, +# this must not align with traditional integer sizes. +# This can be 4, 8, 12, 14, 16, ... +# +# +# +# +# Time it takes to read the detector (typically milliseconds). +# This is important to know for time resolved experiments. +# +# +# +# +# Time it takes to start exposure after a trigger signal has been received. +# This is the reaction time of the detector firmware after receiving the trigger signal +# to when the detector starts to acquire the exposure, including any user set delay.. +# This is important to know for time resolved experiments. +# +# +# +# +# User-specified trigger delay. +# +# +# +# +# Time it takes to start exposure after a trigger signal has been received. +# This is the reaction time of the detector hardware after receiving the +# trigger signal to when the detector starts to acquire the exposure. +# It forms the lower boundary of the trigger_delay_time when the user +# does not request an additional delay. +# +# +# +# +# Time during which no new trigger signal can be accepted. +# Typically this is the +# trigger_delay_time + exposure_time + readout_time. +# This is important to know for time resolved experiments. +# +# +# +# +# This is time for each frame. This is exposure_time + readout time. +# +# +# +# +# +# +# +# The gain setting of the detector. This is a detector-specific value +# meant to document the gain setting of the detector during data +# collection, for detectors with multiple available gain settings. +# +# Examples of gain settings include: +# +# * ``standard`` +# * ``fast`` +# * ``auto`` +# * ``high`` +# * ``medium`` +# * ``low`` +# * ``mixed high to medium`` +# * ``mixed medium to low`` +# +# Developers are encouraged to use one of these terms, or to submit +# additional terms to add to the list. +# +# +# +# +# The value at which the detector goes into saturation. +# Especially common to CCD detectors, the data +# is known to be invalid above this value. +# +# For example, given a saturation_value and an underload_value, the valid +# pixels are those less than or equal to the saturation_value and greater +# than or equal to the underload_value. +# +# The precise type should match the type of the data. +# +# +# +# +# The lowest value at which pixels for this detector would be reasonably +# measured. The data is known to be invalid below this value. +# +# For example, given a saturation_value and an underload_value, the valid +# pixels are those less than or equal to the saturation_value and greater +# than or equal to the underload_value. +# +# The precise type should match the type of the data. +# +# +# +# +# CCD images are sometimes constructed by summing +# together multiple short exposures in the +# electronics. This reduces background etc. +# This is the number of short exposures used to sum +# images for an image. +# +# +# +# +# At times, radiation is not directly sensed by the detector. +# Rather, the detector might sense the output from some +# converter like a scintillator. +# This is the name of this converter material. +# +# +# +# +# At times, radiation is not directly sensed by the detector. +# Rather, the detector might sense the output from some +# converter like a scintillator. +# This is the thickness of this converter material. +# +# +# +# +# Single photon counter detectors can be adjusted +# for a certain energy range in which they +# work optimally. This is the energy setting for this. +# +# +# +# +# For use in special cases where the data in NXdetector +# is represented in several parts, each with a separate geometry. +# +# +# +# +# +# Shape description of each pixel. Use only if all pixels in the detector +# are of uniform shape. +# +# +# +# +# Shape description of each pixel. Use only if all pixels in the detector +# are of uniform shape and require being described by cylinders. +# +# +# +# +# +# +# Shape description of the whole detector. Use only if pixels in the +# detector are not of uniform shape. +# +# +# +# +# Shape description of the whole detector. Use only if pixels in the +# detector are not of uniform shape and require being described by cylinders. +# +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# Type of electron amplifier, MCP, channeltron, etc. +# +# +# +# +# Description of the detector type, DLD, Phosphor+CCD, CMOS. +# +# +# +# +# Voltage applied to detector. +# +# +# +# +# Voltage applied to the amplifier. +# +# +# +# +# The low voltage of the amplifier migh not be the ground. +# +# +# +# +# Size of each imaging sensor chip on the detector. +# +# +# +# +# Number of imaging sensor chips on the detector. +# +# +# +# +# Physical size of the pixels of the imaging chip on the detector. +# +# +# +# +# Number of raw active elements in each dimension. Important for swept scans. +# +# +# +# +# raw data output from the detector +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# The reference point of the detector is the center of the first pixel. +# In complex geometries the NXoff_geometry groups can be used to provide an unambiguous reference. +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# diff --git a/base_classes/nyaml/NXdetector_group.yaml b/base_classes/nyaml/NXdetector_group.yaml new file mode 100644 index 0000000000..c087d3b193 --- /dev/null +++ b/base_classes/nyaml/NXdetector_group.yaml @@ -0,0 +1,182 @@ +category: base +doc: | + Logical grouping of detectors. When used, describes a group of detectors. + + Each detector is represented as an NXdetector + with its own detector data array. Each detector data array + may be further decomposed into array sections by use of + NXdetector_module groups. Detectors can be grouped logically + together using NXdetector_group. Groups can be further grouped + hierarchically in a single NXdetector_group (for example, if + there are multiple detectors at an endstation or multiple + endstations at a facility). Alternatively, multiple + NXdetector_groups can be provided. + + The groups are defined hierarchically, with names given + in the group_names field, unique identifying indices given + in the field group_index, and the level in the hierarchy + given in the group_parent field. For example if an x-ray + detector group, DET, consists of four detectors in a + rectangular array:: + + DTL DTR + DLL DLR + + We could have:: + + group_names: ["DET", "DTL", "DTR", "DLL", "DLR"] + group_index: [1, 2, 3, 4, 5] + group_parent: [-1, 1, 1, 1, 1] +type: group +NXdetector_group(NXobject): + group_names(NX_CHAR): + doc: | + An array of the names of the detectors given in NXdetector + groups or the names of hierarchical groupings of detectors + given as names of NXdetector_group groups or in + NXdetector_group group_names and group_parent fields as + having children. + group_index(NX_INT): + doc: | + An array of unique identifiers for detectors or groupings + of detectors. + + Each ID is a unique ID for the corresponding detector or group + named in the field group_names. The IDs are positive integers + starting with 1. + dimensions: + dim: [[1, i]] + group_parent(NX_INT): + doc: | + An array of the hierarchical levels of the parents of detectors + or groupings of detectors. + + A top-level grouping has parent level -1. + dimensions: + dim: [[1, ]] + dim_parameters: + ref: ['group_index'] + group_type(NX_INT): + doc: | + Code number for group type, e.g. bank=1, tube=2 etc. + dimensions: + dim: [[1, ]] + dim_parameters: + ref: ['group_index'] + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 691ea608a29ca9acf2ea185458c9dc75285438032148ac1529e5ebcf0d96b4b7 +# +# +# +# +# +# Logical grouping of detectors. When used, describes a group of detectors. +# +# Each detector is represented as an NXdetector +# with its own detector data array. Each detector data array +# may be further decomposed into array sections by use of +# NXdetector_module groups. Detectors can be grouped logically +# together using NXdetector_group. Groups can be further grouped +# hierarchically in a single NXdetector_group (for example, if +# there are multiple detectors at an endstation or multiple +# endstations at a facility). Alternatively, multiple +# NXdetector_groups can be provided. +# +# The groups are defined hierarchically, with names given +# in the group_names field, unique identifying indices given +# in the field group_index, and the level in the hierarchy +# given in the group_parent field. For example if an x-ray +# detector group, DET, consists of four detectors in a +# rectangular array:: +# +# DTL DTR +# DLL DLR +# +# We could have:: +# +# group_names: ["DET", "DTL", "DTR", "DLL", "DLR"] +# group_index: [1, 2, 3, 4, 5] +# group_parent: [-1, 1, 1, 1, 1] +# +# +# +# An array of the names of the detectors given in NXdetector +# groups or the names of hierarchical groupings of detectors +# given as names of NXdetector_group groups or in +# NXdetector_group group_names and group_parent fields as +# having children. +# +# +# +# +# An array of unique identifiers for detectors or groupings +# of detectors. +# +# Each ID is a unique ID for the corresponding detector or group +# named in the field group_names. The IDs are positive integers +# starting with 1. +# +# +# +# +# +# An array of the hierarchical levels of the parents of detectors +# or groupings of detectors. +# +# A top-level grouping has parent level -1. +# +# +# +# Code number for group type, e.g. bank=1, tube=2 etc. +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# diff --git a/base_classes/nyaml/NXdetector_module.yaml b/base_classes/nyaml/NXdetector_module.yaml new file mode 100644 index 0000000000..d7e1c35f76 --- /dev/null +++ b/base_classes/nyaml/NXdetector_module.yaml @@ -0,0 +1,302 @@ +category: base +doc: | + Geometry and logical description of a detector module. When used, child group to NXdetector. + + Many detectors consist of multiple + smaller modules. Sometimes it is important to know the exact position of such + modules. + This is the purpose of this group. It is a child group to NXdetector. + + Note, the pixel size is given as values in the array fast_pixel_direction and slow_pixel_direction. +type: group +NXdetector_module(NXobject): + data_origin(NX_INT): + doc: | + A dimension-2 or dimension-3 field which gives the indices + of the origin of the hyperslab of data for this module in the + main area detector image in the parent NXdetector module. + + The data_origin is 0-based. + + The frame number dimension (np) is omitted. Thus the + data_origin field for a dimension-2 dataset with indices (np, i, j) + will be an array with indices (i, j), and for a dimension-3 + dataset with indices (np, i, j, k) will be an array with indices + (i, j, k). + + The :ref:`order ` of indices (i, j or i, j, k) is slow to fast. + data_size(NX_INT): + doc: | + Two or three values for the size of the module in pixels in + each direction. Dimensionality and order of indices is the + same as for data_origin. + module_offset(NX_NUMBER): + unit: NX_LENGTH + doc: | + Offset of the module in regards to the origin of the detector in an + arbitrary direction. + \@transformation_type: + enumeration: [translation] + \@vector: + type: NX_NUMBER + doc: | + Three values that define the axis for this transformation + \@offset: + type: NX_NUMBER + doc: | + A fixed offset applied before the transformation (three vector components). + \@offset_units: + type: NX_CHAR + doc: | + Units of the offset. + \@depends_on: + type: NX_CHAR + doc: | + Points to the path of the next element in the geometry chain. + fast_pixel_direction(NX_NUMBER): + unit: NX_LENGTH + doc: | + Values along the direction of :ref:`fastest varying ` :index:`pixel direction`. Each value in this + array is the size of a pixel in the units specified. Alternatively, if only one + value is given, all pixels in this direction have the same value. The direction + itself is given through the vector attribute. + \@transformation_type: + enumeration: [translation] + \@vector: + type: NX_NUMBER + doc: | + Three values that define the axis for this transformation + \@offset: + type: NX_NUMBER + doc: | + A fixed offset applied before the transformation (three vector components). + \@offset_units: + type: NX_CHAR + doc: | + Units of the offset. + \@depends_on: + type: NX_CHAR + doc: | + Points to the path of the next element in the geometry chain. + slow_pixel_direction(NX_NUMBER): + unit: NX_LENGTH + doc: | + Values along the direction of :ref:`slowest varying` :index:`pixel direction`. Each value in this + array is the size of a pixel in the units specified. Alternatively, if only one + value is given, all pixels in this direction have the same value. The direction + itself is given through the vector attribute. + \@transformation_type: + enumeration: [translation] + \@vector: + type: NX_NUMBER + doc: | + Three values that define the axis for this transformation + \@offset: + type: NX_NUMBER + doc: | + A fixed offset applied before the transformation (three vector components). + \@offset_units: + type: NX_CHAR + doc: | + Units of the offset. + \@depends_on: + type: NX_CHAR + doc: | + Points to the path of the next element in the geometry chain. + depends_on(NX_CHAR): + doc: | + Points to the start of the dependency chain for this module. + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 648bcf7b5b6f0a233d30dfbea9f75968750c251551912aa642fa2172e8d6413a +# +# +# +# +# +# Geometry and logical description of a detector module. When used, child group to NXdetector. +# +# Many detectors consist of multiple +# smaller modules. Sometimes it is important to know the exact position of such +# modules. +# This is the purpose of this group. It is a child group to NXdetector. +# +# Note, the pixel size is given as values in the array fast_pixel_direction and slow_pixel_direction. +# +# +# +# A dimension-2 or dimension-3 field which gives the indices +# of the origin of the hyperslab of data for this module in the +# main area detector image in the parent NXdetector module. +# +# The data_origin is 0-based. +# +# The frame number dimension (np) is omitted. Thus the +# data_origin field for a dimension-2 dataset with indices (np, i, j) +# will be an array with indices (i, j), and for a dimension-3 +# dataset with indices (np, i, j, k) will be an array with indices +# (i, j, k). +# +# The :ref:`order <Design-ArrayStorageOrder>` of indices (i, j or i, j, k) is slow to fast. +# +# +# +# +# Two or three values for the size of the module in pixels in +# each direction. Dimensionality and order of indices is the +# same as for data_origin. +# +# +# +# +# Offset of the module in regards to the origin of the detector in an +# arbitrary direction. +# +# +# +# +# +# +# +# +# Three values that define the axis for this transformation +# +# +# +# +# A fixed offset applied before the transformation (three vector components). +# +# +# +# +# Units of the offset. +# +# +# +# +# Points to the path of the next element in the geometry chain. +# +# +# +# +# +# Values along the direction of :ref:`fastest varying <Design-ArrayStorageOrder>` :index:`pixel direction<dimension; fastest varying>`. Each value in this +# array is the size of a pixel in the units specified. Alternatively, if only one +# value is given, all pixels in this direction have the same value. The direction +# itself is given through the vector attribute. +# +# +# +# +# +# +# +# +# Three values that define the axis for this transformation +# +# +# +# +# A fixed offset applied before the transformation (three vector components). +# +# +# +# +# Units of the offset. +# +# +# +# +# Points to the path of the next element in the geometry chain. +# +# +# +# +# +# Values along the direction of :ref:`slowest varying<Design-ArrayStorageOrder>` :index:`pixel direction<dimension; slowest varying>`. Each value in this +# array is the size of a pixel in the units specified. Alternatively, if only one +# value is given, all pixels in this direction have the same value. The direction +# itself is given through the vector attribute. +# +# +# +# +# +# +# +# +# Three values that define the axis for this transformation +# +# +# +# +# A fixed offset applied before the transformation (three vector components). +# +# +# +# +# Units of the offset. +# +# +# +# +# Points to the path of the next element in the geometry chain. +# +# +# +# +# +# Points to the start of the dependency chain for this module. +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# diff --git a/base_classes/nyaml/NXdisk_chopper.yaml b/base_classes/nyaml/NXdisk_chopper.yaml new file mode 100644 index 0000000000..9d7e271d6a --- /dev/null +++ b/base_classes/nyaml/NXdisk_chopper.yaml @@ -0,0 +1,322 @@ +category: base +doc: | + A device blocking the beam in a temporal periodic pattern. + + A disk which blocks the beam but has one or more slits to periodically + let neutrons through as the disk rotates. Often used in pairs, one + NXdisk_chopper should be defined for each disk. + + The rotation of the disk is commonly monitored by recording a timestamp for + each full rotation of disk, by having a sensor in the stationary disk housing + sensing when it is aligned with a feature (such as a magnet) on the disk. + We refer to this below as the "top-dead-center signal". + + Angles and positive rotation speeds are measured in an anticlockwise + direction when facing away from the source. +symbols: + doc: | + This symbol will be used below to coordinate datasets with the same shape. + n: | + Number of slits in the disk +type: group +NXdisk_chopper(NXobject): + type: + doc: | + Type of the disk-chopper: only one from the enumerated list (match text exactly) + enumeration: [Chopper type single, contra_rotating_pair, synchro_pair] + rotation_speed(NX_FLOAT): + unit: NX_FREQUENCY + doc: | + Chopper rotation speed. Positive for anticlockwise rotation when + facing away from the source, negative otherwise. + slits(NX_INT): + doc: | + Number of slits + slit_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Angular opening + pair_separation(NX_FLOAT): + unit: NX_LENGTH + doc: | + Disk spacing in direction of beam + slit_edges(NX_FLOAT): + unit: NX_ANGLE + doc: | + Angle of each edge of every slit from the position of the + top-dead-center timestamp sensor, anticlockwise when facing + away from the source. + The first edge must be the opening edge of a slit, thus the last edge + may have an angle greater than 360 degrees. + dimensions: + dim: [[1, 2n]] + top_dead_center(NX_NUMBER): + unit: NX_TIME + doc: | + Timestamps of the top-dead-center signal. The times are relative + to the "start" attribute and in the units specified in the "units" + attribute. Please note that absolute + timestamps under unix are relative to ``1970-01-01T00:00:00.0Z``. + \@start: + type: NX_DATE_TIME + beam_position(NX_FLOAT): + unit: NX_ANGLE + doc: | + Angular separation of the center of the beam and the + top-dead-center timestamp sensor, anticlockwise when facing + away from the source. + radius(NX_FLOAT): + unit: NX_LENGTH + doc: | + Radius of the disk + slit_height(NX_FLOAT): + unit: NX_LENGTH + doc: | + Total slit height + phase(NX_FLOAT): + unit: NX_ANGLE + doc: | + Chopper phase angle + delay(NX_NUMBER): + unit: NX_TIME + doc: | + Time difference between timing system t0 and chopper driving clock signal + ratio(NX_INT): + doc: | + Pulse reduction factor of this chopper in relation to other + choppers/fastest pulse in the instrument + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + Effective distance to the origin. + Note, it is recommended to use NXtransformations instead. + wavelength_range(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + Low and high values of wavelength range transmitted + dimensions: + dim: [[1, 2]] + (NXgeometry): + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the chopper and NXoff_geometry to describe its shape instead + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the beam line component + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference plane of the disk chopper includes the surface of the spinning disk which faces + the source. The reference point in the x and y axis is the point on this surface which is the + centre of the axle which the disk is spinning around. The reference plane is orthogonal to + the z axis and its position is the reference point on that axis. + + Note: This reference point in almost all practical cases is not where the beam passes though. + + .. image:: disk_chopper/disk_chopper.png + :width: 40% + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 8746243b86eb8172d6bdcd6ae4e98f815d918d58349a17d67abc02d5af5214f8 +# +# +# +# +# +# +# This symbol will be used below to coordinate datasets with the same shape. +# Number of slits in the disk +# +# +# +# A device blocking the beam in a temporal periodic pattern. +# +# A disk which blocks the beam but has one or more slits to periodically +# let neutrons through as the disk rotates. Often used in pairs, one +# NXdisk_chopper should be defined for each disk. +# +# The rotation of the disk is commonly monitored by recording a timestamp for +# each full rotation of disk, by having a sensor in the stationary disk housing +# sensing when it is aligned with a feature (such as a magnet) on the disk. +# We refer to this below as the "top-dead-center signal". +# +# Angles and positive rotation speeds are measured in an anticlockwise +# direction when facing away from the source. +# +# +# +# Type of the disk-chopper: only one from the enumerated list (match text exactly) +# +# +# +# +# +# +# +# +# Chopper rotation speed. Positive for anticlockwise rotation when +# facing away from the source, negative otherwise. +# +# +# +# Number of slits +# +# +# Angular opening +# +# +# Disk spacing in direction of beam +# +# +# +# Angle of each edge of every slit from the position of the +# top-dead-center timestamp sensor, anticlockwise when facing +# away from the source. +# The first edge must be the opening edge of a slit, thus the last edge +# may have an angle greater than 360 degrees. +# +# +# +# +# +# Timestamps of the top-dead-center signal. The times are relative +# to the "start" attribute and in the units specified in the "units" +# attribute. Please note that absolute +# timestamps under unix are relative to ``1970-01-01T00:00:00.0Z``. +# +# +# +# +# +# Angular separation of the center of the beam and the +# top-dead-center timestamp sensor, anticlockwise when facing +# away from the source. +# +# +# +# Radius of the disk +# +# +# Total slit height +# +# +# Chopper phase angle +# +# +# +# Time difference between timing system t0 and chopper driving clock signal +# +# +# +# +# Pulse reduction factor of this chopper in relation to other +# choppers/fastest pulse in the instrument +# +# +# +# +# Effective distance to the origin. +# Note, it is recommended to use NXtransformations instead. +# +# +# +# Low and high values of wavelength range transmitted +# +# +# +# +# +# +# This group describes the shape of the beam line component +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# The reference plane of the disk chopper includes the surface of the spinning disk which faces +# the source. The reference point in the x and y axis is the point on this surface which is the +# centre of the axle which the disk is spinning around. The reference plane is orthogonal to +# the z axis and its position is the reference point on that axis. +# +# Note: This reference point in almost all practical cases is not where the beam passes though. +# +# .. image:: disk_chopper/disk_chopper.png +# :width: 40% +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# diff --git a/base_classes/nyaml/NXentry.yaml b/base_classes/nyaml/NXentry.yaml new file mode 100644 index 0000000000..a1275a308b --- /dev/null +++ b/base_classes/nyaml/NXentry.yaml @@ -0,0 +1,521 @@ +category: base +doc: | + (**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. +type: group +NXentry(NXobject): + \@default: + doc: | + .. 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. + (NXdata): + doc: | + 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 + \@IDF_Version: + + # as ratified at NIAC2010 + doc: | + ISIS Muon IDF_Version + title: + doc: | + Extended title for entry + experiment_identifier: + doc: | + Unique identifier for the experiment, + defined by the facility, + possibly linked to the proposals + experiment_description: + doc: | + Brief summary of the experiment, including key objectives. + (NXnote)experiment_documentation: + doc: | + Description of the full experiment (document in pdf, latex, ...) + collection_identifier: + doc: | + User or Data Acquisition defined group of NeXus files or NXentry + collection_description: + doc: | + Brief summary of the collection, including grouping criteria. + entry_identifier: + doc: | + unique identifier for the measurement, defined by the facility. + entry_identifier_uuid: + doc: | + UUID identifier for the measurement. + \@version: + doc: | + Version of UUID used + features: + doc: | + Reserved for future use by NIAC. + + See https://github.com/nexusformat/definitions/issues/382 + definition: + doc: | + (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. + \@version: + doc: | + NXDL version number + \@URL: + doc: | + URL of NXDL file + definition_local: + deprecated: | + see same field in :ref:`NXsubentry` for preferred use + doc: | + Local NXDL schema extended from the entry + specified in the ``definition`` field. + This contains any locally-defined, + additional fields in the entry. + \@version: + doc: | + NXDL version number + \@URL: + doc: | + URL of NXDL file + start_time(NX_DATE_TIME): + doc: | + Starting time of measurement + end_time(NX_DATE_TIME): + doc: | + Ending time of measurement + duration(NX_INT): + unit: NX_TIME + doc: | + Duration of measurement + collection_time(NX_FLOAT): + unit: NX_TIME + doc: | + Time transpired actually collecting data i.e. taking out time when collection was + suspended due to e.g. temperature out of range + run_cycle: + doc: | + Such as "2007-3". Some user facilities organize their beam time into run cycles. + program_name: + doc: | + Name of program used to generate this file + \@version: + doc: | + Program version number + \@configuration: + doc: | + configuration of the program + revision: + doc: | + Revision id of the file due to re-calibration, reprocessing, new analysis, new + instrument definition format, ... + \@comment: + pre_sample_flightpath(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the flightpath before the sample position. This can be determined by a chopper, + by the moderator or the source itself. In other words: it the distance to the component + which gives the T0 signal to the detector electronics. If another component in the + NXinstrument hierarchy provides this information, this should be a link. + notes(NXnote): + doc: | + Notes describing entry + thumbnail(NXnote): + doc: | + A small image that is representative of the entry. An example of this is a 640x480 + jpeg image automatically produced by a low resolution plot of the NXdata. + \@type: + doc: | + The mime type should be an ``image/*`` + + # This is not perfect. + # How do we set a default value for the type attribute? + enumeration: [image/*] + experiment_location: + doc: | + City and country where the experiment took place + experiment_start_date(NX_DATE_TIME): + doc: | + Start time of experimental run that includes the current + measurement, for example a beam time. + experiment_end_date(NX_DATE_TIME): + doc: | + End time of experimental run that includes the current + measurement, for example a beam time. + experiment_institution: + doc: | + Name of the institution hosting the facility + experiment_facility: + doc: | + Name of the experimental facility + experiment_laboratory: + doc: | + Name of the laboratory or beamline + (NXuser): + (NXsample): + (NXinstrument): + (NXcollection): + (NXmonitor): + (NXparameters): + (NXprocess): + (NXsubentry): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# c174932eb1ad851dc9e15d607deb596334b909da162638734c332774c77b1c09 +# +# +# +# +# +# (**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. +# +# +# +# .. 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 <validItemName>` 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 <Find-Plottable-Data-v3>` +# section. +# +# +# +# +# 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 +# +# +# +# +# +# ISIS Muon IDF_Version +# +# +# +# +# Extended title for entry +# +# +# +# +# Unique identifier for the experiment, +# defined by the facility, +# possibly linked to the proposals +# +# +# +# +# Brief summary of the experiment, including key objectives. +# +# +# +# +# Description of the full experiment (document in pdf, latex, ...) +# +# +# +# +# User or Data Acquisition defined group of NeXus files or NXentry +# +# +# +# +# Brief summary of the collection, including grouping criteria. +# +# +# +# +# unique identifier for the measurement, defined by the facility. +# +# +# +# +# UUID identifier for the measurement. +# +# +# +# Version of UUID used +# +# +# +# +# +# Reserved for future use by NIAC. +# +# See https://github.com/nexusformat/definitions/issues/382 +# +# +# +# +# (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. +# +# +# +# NXDL version number +# +# +# +# +# URL of NXDL file +# +# +# +# +# +# Local NXDL schema extended from the entry +# specified in the ``definition`` field. +# This contains any locally-defined, +# additional fields in the entry. +# +# +# +# NXDL version number +# +# +# +# +# URL of NXDL file +# +# +# +# +# +# Starting time of measurement +# +# +# +# +# Ending time of measurement +# +# +# +# +# Duration of measurement +# +# +# +# +# Time transpired actually collecting data i.e. taking out time when collection was +# suspended due to e.g. temperature out of range +# +# +# +# +# Such as "2007-3". Some user facilities organize their beam time into run cycles. +# +# +# +# +# Name of program used to generate this file +# +# +# +# Program version number +# +# +# +# +# configuration of the program +# +# +# +# +# +# Revision id of the file due to re-calibration, reprocessing, new analysis, new +# instrument definition format, ... +# +# +# +# +# +# This is the flightpath before the sample position. This can be determined by a chopper, +# by the moderator or the source itself. In other words: it the distance to the component +# which gives the T0 signal to the detector electronics. If another component in the +# NXinstrument hierarchy provides this information, this should be a link. +# +# +# +# +# Notes describing entry +# +# +# +# +# A small image that is representative of the entry. An example of this is a 640x480 +# jpeg image automatically produced by a low resolution plot of the NXdata. +# +# +# +# The mime type should be an ``image/*`` +# +# +# +# +# +# +# +# +# +# City and country where the experiment took place +# +# +# +# +# Start time of experimental run that includes the current +# measurement, for example a beam time. +# +# +# +# +# End time of experimental run that includes the current +# measurement, for example a beam time. +# +# +# +# +# Name of the institution hosting the facility +# +# +# +# +# Name of the experimental facility +# +# +# +# +# Name of the laboratory or beamline +# +# +# +# +# +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXenvironment.yaml b/base_classes/nyaml/NXenvironment.yaml new file mode 100644 index 0000000000..3ba6fd2baf --- /dev/null +++ b/base_classes/nyaml/NXenvironment.yaml @@ -0,0 +1,120 @@ +category: base +doc: | + Parameters for controlling external conditions +type: group +NXenvironment(NXobject): + name: + doc: | + Apparatus identification code/model number; e.g. OC100 011 + short_name: + doc: | + Alternative short name, perhaps for dashboard display like a present Seblock name + type: + doc: | + Type of apparatus. This could be the SE codes in scheduling database; e.g. OC/100 + description: + doc: | + Description of the apparatus; e.g. 100mm bore orange cryostat with Roots pump + program: + doc: | + Program controlling the apparatus; e.g. LabView VI name + position(NXgeometry): + doc: | + The position and orientation of the apparatus. + Note, it is recommended to use NXtransformations instead. + depends_on(NX_CHAR): + doc: | + 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. + (NXtransformations): + exists: ['min', '0'] + doc: | + 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. + (NXnote): + doc: | + Additional information, LabView logs, digital photographs, etc + (NXsensor): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 8d95a3f1615f3146244d8f2a05eda98e75a2ca49ffefa97329db446c658f9def +# +# +# +# +# Parameters for controlling external conditions +# +# Apparatus identification code/model number; e.g. OC100 011 +# +# +# Alternative short name, perhaps for dashboard display like a present Seblock name +# +# +# Type of apparatus. This could be the SE codes in scheduling database; e.g. OC/100 +# +# +# Description of the apparatus; e.g. 100mm bore orange cryostat with Roots pump +# +# +# Program controlling the apparatus; e.g. LabView VI name +# +# +# +# The position and orientation of the apparatus. +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# 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. +# +# +# +# +# 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. +# +# +# +# Additional information, LabView logs, digital photographs, etc +# +# +# +# diff --git a/base_classes/nyaml/NXevent_data.yaml b/base_classes/nyaml/NXevent_data.yaml new file mode 100644 index 0000000000..c75f0ee867 --- /dev/null +++ b/base_classes/nyaml/NXevent_data.yaml @@ -0,0 +1,220 @@ +category: base +doc: | + NXevent_data is a special group for storing data from neutron + detectors in event mode. In this mode, the detector electronics + emits a stream of detectorID, timestamp pairs. With detectorID + describing the detector element in which the neutron was detected + and timestamp the timestamp at which the neutron event was + detected. In NeXus detectorID maps to event_id, event_time_offset + to the timestamp. + + As this kind of data is common at pulsed neutron + sources, the timestamp is almost always relative to the start of a + neutron pulse. Thus the pulse timestamp is recorded too together + with an index in the event_id, event_time_offset pair at which data for + that pulse starts. At reactor source the same pulsed data effect + may be achieved through the use of choppers or in stroboscopic + measurement setups. + + In order to make random access to timestamped data + faster there is an optional array pair of + cue_timestamp_zero and cue_index. The cue_timestamp_zero will + contain courser timestamps then in the time array, say + every five minutes. The cue_index will then contain the + index into the event_id,event_time_offset pair of arrays for that + courser cue_timestamp_zero. +type: group +NXevent_data(NXobject): + event_time_offset(NX_NUMBER): + unit: NX_TIME_OF_FLIGHT + doc: | + A list of timestamps for each event as it comes in. + dimensions: + rank: 1 + dim: [[1, i]] + event_id(NX_INT): + unit: NX_DIMENSIONLESS + doc: | + There will be extra information in the NXdetector to convert + event_id to detector_number. + dimensions: + rank: 1 + dim: [[1, i]] + event_time_zero(NX_NUMBER): + unit: NX_TIME + doc: | + The time that each pulse started with respect to the offset + dimensions: + rank: 1 + dim: [[1, j]] + \@offset: + type: NX_DATE_TIME + doc: | + ISO8601 + event_index(NX_INT): + unit: NX_DIMENSIONLESS + doc: | + The index into the event_time_offset, event_id pair for + the pulse occurring at the matching entry in event_time_zero. + dimensions: + rank: 1 + dim: [[1, j]] + pulse_height(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + If voltages from the ends of the detector are read out this + is where they go. This list is for all events with information + to attach to a particular pulse height. The information to + attach to a particular pulse is located in events_per_pulse. + dimensions: + rank: 2 + + # i,k? + dim: [[1, i], [2, k]] + cue_timestamp_zero(NX_DATE_TIME): + unit: NX_TIME + doc: | + Timestamps matching the corresponding cue_index into the + event_id, event_time_offset pair. + \@start: + type: NX_DATE_TIME + cue_index(NX_INT): + doc: | + Index into the event_id, event_time_offset pair matching the corresponding + cue_timestamp. + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 8ed9dbd7316d38b106211e5be368886684addd89e347b28ec11e7e88d6ca88bb +# +# +# +# +# +# NXevent_data is a special group for storing data from neutron +# detectors in event mode. In this mode, the detector electronics +# emits a stream of detectorID, timestamp pairs. With detectorID +# describing the detector element in which the neutron was detected +# and timestamp the timestamp at which the neutron event was +# detected. In NeXus detectorID maps to event_id, event_time_offset +# to the timestamp. +# +# As this kind of data is common at pulsed neutron +# sources, the timestamp is almost always relative to the start of a +# neutron pulse. Thus the pulse timestamp is recorded too together +# with an index in the event_id, event_time_offset pair at which data for +# that pulse starts. At reactor source the same pulsed data effect +# may be achieved through the use of choppers or in stroboscopic +# measurement setups. +# +# In order to make random access to timestamped data +# faster there is an optional array pair of +# cue_timestamp_zero and cue_index. The cue_timestamp_zero will +# contain courser timestamps then in the time array, say +# every five minutes. The cue_index will then contain the +# index into the event_id,event_time_offset pair of arrays for that +# courser cue_timestamp_zero. +# +# +# +# A list of timestamps for each event as it comes in. +# +# +# +# +# +# There will be extra information in the NXdetector to convert +# event_id to detector_number. +# +# +# +# +# +# The time that each pulse started with respect to the offset +# +# +# +# ISO8601 +# +# +# +# +# The index into the event_time_offset, event_id pair for +# the pulse occurring at the matching entry in event_time_zero. +# +# +# +# +# +# If voltages from the ends of the detector are read out this +# is where they go. This list is for all events with information +# to attach to a particular pulse height. The information to +# attach to a particular pulse is located in events_per_pulse. +# +# +# +# +# +# +# +# +# Timestamps matching the corresponding cue_index into the +# event_id, event_time_offset pair. +# +# +# +# +# +# Index into the event_id, event_time_offset pair matching the corresponding +# cue_timestamp. +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# diff --git a/base_classes/nyaml/NXfermi_chopper.yaml b/base_classes/nyaml/NXfermi_chopper.yaml new file mode 100644 index 0000000000..08073753d0 --- /dev/null +++ b/base_classes/nyaml/NXfermi_chopper.yaml @@ -0,0 +1,210 @@ +category: base +doc: | + A Fermi chopper, possibly with curved slits. +type: group +NXfermi_chopper(NXobject): + type: + doc: | + Fermi chopper type + rotation_speed(NX_FLOAT): + unit: NX_FREQUENCY + doc: | + chopper rotation speed + radius(NX_FLOAT): + unit: NX_LENGTH + doc: | + radius of chopper + slit(NX_FLOAT): + unit: NX_LENGTH + doc: | + width of an individual slit + r_slit(NX_FLOAT): + unit: NX_LENGTH + doc: | + radius of curvature of slits + number(NX_INT): + unit: NX_UNITLESS + doc: | + number of slits + height(NX_FLOAT): + unit: NX_LENGTH + doc: | + input beam height + width(NX_FLOAT): + unit: NX_LENGTH + doc: | + input beam width + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + distance. Note, it is recommended to use NXtransformations instead. + wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + + # should have units of angstroms or nm or pm + doc: | + Wavelength transmitted by chopper + energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + energy selected + (NXgeometry): + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the chopper and NXoff_geometry to describe its shape instead + doc: | + geometry of the fermi chopper + absorbing_material: + doc: | + absorbing material + transmitting_material: + doc: | + transmitting material + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the beam line component + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a fermi chopper. + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 2407282663e1772239751fbb10e88d002cc9382fce57cd6badbaeff0d0c2d7d6 +# +# +# +# +# A Fermi chopper, possibly with curved slits. +# +# Fermi chopper type +# +# +# chopper rotation speed +# +# +# radius of chopper +# +# +# width of an individual slit +# +# +# radius of curvature of slits +# +# +# number of slits +# +# +# input beam height +# +# +# input beam width +# +# +# distance. Note, it is recommended to use NXtransformations instead. +# +# +# +# Wavelength transmitted by chopper +# +# +# energy selected +# +# +# geometry of the fermi chopper +# +# +# absorbing material +# +# +# transmitting material +# +# +# +# This group describes the shape of the beam line component +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a fermi chopper. +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# diff --git a/base_classes/nyaml/NXfilter.yaml b/base_classes/nyaml/NXfilter.yaml new file mode 100644 index 0000000000..7eb6622a69 --- /dev/null +++ b/base_classes/nyaml/NXfilter.yaml @@ -0,0 +1,373 @@ +category: base +doc: | + For band pass beam filters. + + If uncertain whether to use :ref:`NXfilter` (band-pass filter) + or :ref:`NXattenuator` (reduces beam intensity), then use + :ref:`NXattenuator`. +type: group +NXfilter(NXobject): + (NXgeometry): + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to filter the beamstop and NXoff_geometry to describe its shape instead + doc: | + Geometry of the filter + description: + doc: | + Composition of the filter. Chemical formula can be specified separately. + + This field was changed (2010-11-17) from an enumeration to + a string since common usage showed a wider variety of use + than a simple list. These are the items in the list at + the time of the change: Beryllium | Pyrolytic Graphite | + Graphite | Sapphire | Silicon | Supermirror. + status: + doc: | + position with respect to in or out of the beam (choice of only "in" or "out") + enumeration: + in: + doc: | + in the beam + out: + doc: | + out of the beam + transmission(NXdata): + doc: | + Wavelength transmission profile of filter + temperature(NX_FLOAT): + unit: NX_TEMPERATURE + doc: | + average/nominal filter temperature + temperature_log(NXlog): + doc: | + Linked temperature_log for the filter + thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + Thickness of the filter + density(NX_NUMBER): + unit: NX_MASS_DENSITY + doc: | + mass density of the filter + chemical_formula: + + # copied from NXsample + doc: | + 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. + sensor_type(NXsensor): + doc: | + Sensor(s)used to monitor the filter temperature + unit_cell_a(NX_FLOAT): + unit: NX_LENGTH + doc: | + Unit cell lattice parameter: length of side a + unit_cell_b(NX_FLOAT): + unit: NX_LENGTH + doc: | + Unit cell lattice parameter: length of side b + unit_cell_c(NX_FLOAT): + unit: NX_LENGTH + doc: | + Unit cell lattice parameter: length of side c + unit_cell_alpha(NX_FLOAT): + unit: NX_ANGLE + doc: | + Unit cell lattice parameter: angle alpha + unit_cell_beta(NX_FLOAT): + unit: NX_ANGLE + doc: | + Unit cell lattice parameter: angle beta + unit_cell_gamma(NX_FLOAT): + unit: NX_ANGLE + doc: | + Unit cell lattice parameter: angle gamma + unit_cell_volume(NX_FLOAT): + unit: NX_VOLUME + doc: | + Unit cell + dimensions: + rank: 1 + dim: [[1, n_comp]] + orientation_matrix(NX_FLOAT): + doc: | + Orientation matrix of single crystal filter using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + dimensions: + rank: 3 + + # n_comp,3,3 + + # TODO n_comp is number of different compositions? + dim: [[1, n_comp], [2, 3], [3, 3]] + m_value(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + m value of supermirror filter + substrate_material: + doc: | + substrate material of supermirror filter + substrate_thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + substrate thickness of supermirror filter + coating_material: + doc: | + coating material of supermirror filter + substrate_roughness(NX_FLOAT): + unit: NX_LENGTH + doc: | + substrate roughness (RMS) of supermirror filter + coating_roughness(NX_FLOAT): + unit: NX_LENGTH + doc: | + coating roughness (RMS) of supermirror filter + dimensions: + rank: 1 + dim: [[1, nsurf]] + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the beam line component + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a filter. + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# d2cc3057e66871057ddf851fbe725f22606e3a84fa54746d87674d898b0eace0 +# +# +# +# +# +# For band pass beam filters. +# +# If uncertain whether to use :ref:`NXfilter` (band-pass filter) +# or :ref:`NXattenuator` (reduces beam intensity), then use +# :ref:`NXattenuator`. +# +# +# Geometry of the filter +# +# +# +# Composition of the filter. Chemical formula can be specified separately. +# +# This field was changed (2010-11-17) from an enumeration to +# a string since common usage showed a wider variety of use +# than a simple list. These are the items in the list at +# the time of the change: Beryllium | Pyrolytic Graphite | +# Graphite | Sapphire | Silicon | Supermirror. +# +# +# +# position with respect to in or out of the beam (choice of only "in" or "out") +# +# in the beam +# out of the beam +# +# +# +# Wavelength transmission profile of filter +# +# +# average/nominal filter temperature +# +# +# Linked temperature_log for the filter +# +# +# Thickness of the filter +# +# +# mass density of the filter +# +# +# +# +# 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. +# +# +# +# Sensor(s)used to monitor the filter temperature +# +# +# Unit cell lattice parameter: length of side a +# +# +# Unit cell lattice parameter: length of side b +# +# +# Unit cell lattice parameter: length of side c +# +# +# Unit cell lattice parameter: angle alpha +# +# +# Unit cell lattice parameter: angle beta +# +# +# Unit cell lattice parameter: angle gamma +# +# +# Unit cell +# +# +# +# +# Orientation matrix of single crystal filter using Busing-Levy convention: +# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 +# +# +# +# +# +# +# +# +# m value of supermirror filter +# +# +# substrate material of supermirror filter +# +# +# substrate thickness of supermirror filter +# +# +# coating material of supermirror filter +# +# +# substrate roughness (RMS) of supermirror filter +# +# +# coating roughness (RMS) of supermirror filter +# +# +# +# +# This group describes the shape of the beam line component +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a filter. +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# diff --git a/base_classes/nyaml/NXflipper.yaml b/base_classes/nyaml/NXflipper.yaml new file mode 100644 index 0000000000..ea20d1a8d4 --- /dev/null +++ b/base_classes/nyaml/NXflipper.yaml @@ -0,0 +1,159 @@ +category: base +doc: | + A spin flipper. +type: group +NXflipper(NXobject): + type: + enumeration: [coil, current-sheet] + flip_turns(NX_FLOAT): + unit: NX_PER_LENGTH + doc: | + Linear density of turns (such as number of turns/cm) in flipping field coils + comp_turns(NX_FLOAT): + unit: NX_PER_LENGTH + doc: | + Linear density of turns (such as number of turns/cm) in compensating field coils + guide_turns(NX_FLOAT): + unit: NX_PER_LENGTH + doc: | + Linear density of turns (such as number of turns/cm) in guide field coils + flip_current(NX_FLOAT): + unit: NX_CURRENT + doc: | + Flipping field coil current in "on" state" + comp_current(NX_FLOAT): + unit: NX_CURRENT + doc: | + Compensating field coil current in "on" state" + guide_current(NX_FLOAT): + unit: NX_CURRENT + doc: | + Guide field coil current in "on" state + thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + thickness along path of neutron travel + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a spin flipper. + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 62c4f526c364c8ede653c3a19e5aed1dae3a51685eb7137a46a3d906c1cc60bf +# +# +# +# +# A spin flipper. +# +# +# +# +# +# +# +# Linear density of turns (such as number of turns/cm) in flipping field coils +# +# +# Linear density of turns (such as number of turns/cm) in compensating field coils +# +# +# Linear density of turns (such as number of turns/cm) in guide field coils +# +# +# Flipping field coil current in "on" state" +# +# +# Compensating field coil current in "on" state" +# +# +# Guide field coil current in "on" state +# +# +# thickness along path of neutron travel +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a spin flipper. +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# diff --git a/base_classes/nyaml/NXfresnel_zone_plate.yaml b/base_classes/nyaml/NXfresnel_zone_plate.yaml new file mode 100644 index 0000000000..eea7e942f1 --- /dev/null +++ b/base_classes/nyaml/NXfresnel_zone_plate.yaml @@ -0,0 +1,178 @@ +category: base +doc: | + A fresnel zone plate +type: group +NXfresnel_zone_plate(NXobject): + focus_parameters(NX_FLOAT): + doc: | + list of polynomial coefficients describing the focal length of the zone plate, in increasing powers of photon energy, + that describes the focal length of the zone plate (in microns) at an X-ray photon energy (in electron volts). + dimensions: + rank: 1 + dim: [] + outer_diameter(NX_FLOAT): + unit: NX_LENGTH + outermost_zone_width(NX_FLOAT): + unit: NX_LENGTH + central_stop_diameter(NX_FLOAT): + unit: NX_LENGTH + fabrication: + doc: | + how the zone plate was manufactured + enumeration: [etched, plated, zone doubled, other] + zone_height(NX_FLOAT): + unit: NX_LENGTH + zone_material: + doc: | + Material of the zones themselves + zone_support_material: + doc: | + Material present between the zones. This is usually only present for the "zone doubled" fabrication process + central_stop_material: + central_stop_thickness(NX_FLOAT): + unit: NX_LENGTH + mask_thickness(NX_FLOAT): + unit: NX_LENGTH + mask_material: + doc: | + If no mask is present, set mask_thickness to 0 and omit the mask_material field + support_membrane_material: + support_membrane_thickness(NX_FLOAT): + unit: NX_LENGTH + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a fresnel zone plate. + (NXtransformations): + doc: | + "Engineering" position of the fresnel zone plate + + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 53901ea435d088aedb91b2f3fa70e315e6269a25bb0b871d938a2cfd0c5a82ec +# +# +# +# +# +# A fresnel zone plate +# +# +# list of polynomial coefficients describing the focal length of the zone plate, in increasing powers of photon energy, +# that describes the focal length of the zone plate (in microns) at an X-ray photon energy (in electron volts). +# +# +# +# +# +# +# +# +# how the zone plate was manufactured +# +# +# +# +# +# +# +# +# +# Material of the zones themselves +# +# +# Material present between the zones. This is usually only present for the "zone doubled" fabrication process +# +# +# +# +# +# If no mask is present, set mask_thickness to 0 and omit the mask_material field +# +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a fresnel zone plate. +# +# +# +# +# +# "Engineering" position of the fresnel zone plate +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# diff --git a/base_classes/nyaml/NXgeometry.yaml b/base_classes/nyaml/NXgeometry.yaml new file mode 100644 index 0000000000..5c1dfb277f --- /dev/null +++ b/base_classes/nyaml/NXgeometry.yaml @@ -0,0 +1,128 @@ +category: base +doc: | + legacy class - recommend to use :ref:`NXtransformations` now + + It is recommended that instances of :ref:`NXgeometry` be converted to + use :ref:`NXtransformations`. + + This is the description for a general position of a component. + It is recommended to name an instance of :ref:`NXgeometry` as "geometry" + to aid in the use of the definition in simulation codes such as McStas. + Also, in HDF, linked items must share the same name. + However, it might not be possible or practical in all situations. +type: group +deprecated: as decided at 2014 NIAC meeting, convert to use :ref:`NXtransformations` +NXgeometry(NXobject): + (NXshape): + doc: | + shape/size information of component + (NXtranslation): + doc: | + translation of component + (NXorientation): + doc: | + orientation of component + description: + doc: | + Optional description/label. Probably only present if we are + an additional reference point for components rather than the + location of a real component. + component_index(NX_INT): + doc: | + Position of the component along the beam path. The sample is at 0, components upstream + have negative component_index, components downstream have positive + component_index. + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# d7d64aa78775fa8184154f30651e5def6856d4f76f490ba44df0f5a37463b670 +# +# +# +# +# +# legacy class - recommend to use :ref:`NXtransformations` now +# +# It is recommended that instances of :ref:`NXgeometry` be converted to +# use :ref:`NXtransformations`. +# +# This is the description for a general position of a component. +# It is recommended to name an instance of :ref:`NXgeometry` as "geometry" +# to aid in the use of the definition in simulation codes such as McStas. +# Also, in HDF, linked items must share the same name. +# However, it might not be possible or practical in all situations. +# +# +# shape/size information of component +# +# +# translation of component +# +# +# orientation of component +# +# +# +# Optional description/label. Probably only present if we are +# an additional reference point for components rather than the +# location of a real component. +# +# +# +# +# Position of the component along the beam path. The sample is at 0, components upstream +# have negative component_index, components downstream have positive +# component_index. +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# diff --git a/base_classes/nyaml/NXgrating.yaml b/base_classes/nyaml/NXgrating.yaml new file mode 100644 index 0000000000..9603971d7c --- /dev/null +++ b/base_classes/nyaml/NXgrating.yaml @@ -0,0 +1,202 @@ +category: base +doc: | + A diffraction grating, as could be used in a soft X-ray monochromator +type: group +NXgrating(NXobject): + angles(NX_FLOAT): + unit: NX_ANGLE + doc: | + Blaze or trapezoidal angles, with the angle of the upstream facing edge listed first. Blazed gratings can be identified by the low value of the first-listed angle. + dimensions: + rank: 1 + dim: [[1, 2]] + period(NX_FLOAT): + unit: NX_LENGTH + doc: | + List of polynomial coefficients describing the spatial separation of lines/grooves as a function of position along the grating, in increasing powers of position. Gratings which do not have variable line spacing will only have a single coefficient (constant). + dimensions: + rank: 1 + dim: [] + duty_cycle(NX_FLOAT): + unit: NX_UNITLESS + depth(NX_FLOAT): + unit: NX_LENGTH + diffraction_order(NX_INT): + unit: NX_UNITLESS + deflection_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Angle between the incident beam and the utilised outgoing beam. + interior_atmosphere: + enumeration: [vacuum, helium, argon] + substrate_material: + doc: | + substrate_density(NX_FLOAT): + unit: NX_MASS_DENSITY + doc: | + substrate_thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + coating_material: + substrate_roughness(NX_FLOAT): + unit: NX_LENGTH + coating_roughness(NX_FLOAT): + unit: NX_LENGTH + layer_thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + An array describing the thickness of each layer + (NXshape)shape: + deprecated: Use NXoff_geometry to describe the shape of grating + doc: | + A NXshape group describing the shape of the mirror + figure_data(NXdata): + doc: | + Numerical description of the surface figure of the mirror. + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the beam line component + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a bending grating. + (NXtransformations): + doc: | + "Engineering" position of the grating + Transformations used by this component to define its position and orientation. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e3c616b8b6027b862a3946ab63674969147bd291cefbad316bfb6fdb3477305e +# +# +# +# +# +# A diffraction grating, as could be used in a soft X-ray monochromator +# +# Blaze or trapezoidal angles, with the angle of the upstream facing edge listed first. Blazed gratings can be identified by the low value of the first-listed angle. +# +# +# +# +# +# List of polynomial coefficients describing the spatial separation of lines/grooves as a function of position along the grating, in increasing powers of position. Gratings which do not have variable line spacing will only have a single coefficient (constant). +# +# +# +# +# +# +# Angle between the incident beam and the utilised outgoing beam. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# An array describing the thickness of each layer +# +# +# A NXshape group describing the shape of the mirror +# +# +# Numerical description of the surface figure of the mirror. +# +# +# +# This group describes the shape of the beam line component +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a bending grating. +# +# +# +# +# +# "Engineering" position of the grating +# Transformations used by this component to define its position and orientation. +# +# +# diff --git a/base_classes/nyaml/NXguide.yaml b/base_classes/nyaml/NXguide.yaml new file mode 100644 index 0000000000..fd2f276229 --- /dev/null +++ b/base_classes/nyaml/NXguide.yaml @@ -0,0 +1,416 @@ +category: base +doc: | + A neutron optical element to direct the path of the beam. + + :ref:`NXguide` is used by neutron instruments to describe + a guide consists of several mirrors building a shape through which + neutrons can be guided or directed. The simplest such form is box shaped + although elliptical guides are gaining in popularity. + The individual parts of a guide usually have common characteristics + but there are cases where they are different. + For example, a neutron guide might consist of 2 or 4 coated walls or + a supermirror bender with multiple, coated vanes. + + To describe polarizing supermirrors such as used in neutron reflection, + it may be necessary to revise this definition of :ref:`NXguide` + to include :ref:`NXpolarizer` and/or :ref:`NXmirror`. + + When even greater complexity exists in the definition of what + constitutes a *guide*, it has been suggested that :ref:`NXguide` + be redefined as a :ref:`NXcollection` of :ref:`NXmirror` each + having their own :ref:`NXgeometry` describing their location(s). + + For the more general case when describing mirrors, consider using + :ref:`NXmirror`. + + NOTE: The NeXus International Advisory Committee welcomes + comments for revision and improvement of + this definition of :ref:`NXguide`. +symbols: + nsurf: | + number of reflecting surfaces + nwl: | + number of wavelengths +type: group +NXguide(NXobject): + (NXgeometry): + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the guid and NXoff_geometry to describe its shape instead + doc: | + TODO: Explain what this NXgeometry group means. What is intended here? + description: + doc: | + A description of this particular instance of ``NXguide``. + incident_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + TODO: documentation needed + (NXdata)reflectivity: + doc: | + Reflectivity as function of reflecting surface and wavelength + \@signal: + enumeration: [data] + \@axes: + enumeration: [surface wavelength] + \@surface_indices: + enumeration: [0] + \@wavelength_indices: + enumeration: [1] + data(NX_NUMBER): + doc: | + reflectivity of each surface as a function of wavelength + dimensions: + rank: 2 + + # was [nsurf,i] + dim: [[1, nsurf], [2, nwl]] + surface(NX_NUMBER): + unit: NX_ANY + doc: | + List of surfaces. Probably best to use index + numbers but the specification is very loose. + dimensions: + rank: 1 + dim: [[1, nsurf]] + wavelength(NX_NUMBER): + unit: NX_WAVELENGTH + doc: | + wavelengths at which reflectivity was measured + dimensions: + rank: 1 + dim: [[1, nwl]] + bend_angle_x(NX_FLOAT): + unit: NX_ANGLE + doc: | + TODO: documentation needed + bend_angle_y(NX_FLOAT): + unit: NX_ANGLE + doc: | + TODO: documentation needed + interior_atmosphere: + doc: | + + # TODO + enumeration: [vacuum, helium, argon] + external_material: + doc: | + external material outside substrate + m_value(NX_FLOAT): + doc: | + The ``m`` value for a supermirror, which defines the supermirror + regime in multiples of the critical angle of Nickel. + dimensions: + rank: 1 + dim: [[1, nsurf]] + substrate_material(NX_FLOAT): + doc: | + TODO: documentation needed + + # Why is this field a "float"? + dimensions: + rank: 1 + dim: [[1, nsurf]] + substrate_thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + TODO: documentation needed + dimensions: + rank: 1 + dim: [[1, nsurf]] + coating_material(NX_FLOAT): + doc: | + TODO: documentation needed + + # Why is this field a "float"? + dimensions: + rank: 1 + dim: [[1, nsurf]] + substrate_roughness(NX_FLOAT): + unit: NX_LENGTH + doc: | + TODO: documentation needed + dimensions: + rank: 1 + dim: [[1, nsurf]] + coating_roughness(NX_FLOAT): + unit: NX_LENGTH + doc: | + TODO: documentation needed + dimensions: + rank: 1 + dim: [[1, nsurf]] + number_sections(NX_INT): + unit: NX_UNITLESS + doc: | + number of substrate sections (also called ``nsurf`` as an + index in the ``NXguide`` specification) + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the beam line component + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The entry opening of the guide lies on the reference plane. The center of the opening on that plane is + the reference point on the x and y axis. The reference plane is orthogonal to the z axis and is the + reference point along the z axis. Given no bend in the guide, it is parallel with z axis and extends + in the positive direction of the z axis. + + .. image:: guide/guide.png + :width: 40% + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 2896d5121b533db5a14ea0d8e98e1e1f707720fce199691a2c7b85756ffb0d7e +# +# +# +# +# +# +# number of reflecting surfaces +# number of wavelengths +# +# +# +# A neutron optical element to direct the path of the beam. +# +# :ref:`NXguide` is used by neutron instruments to describe +# a guide consists of several mirrors building a shape through which +# neutrons can be guided or directed. The simplest such form is box shaped +# although elliptical guides are gaining in popularity. +# The individual parts of a guide usually have common characteristics +# but there are cases where they are different. +# For example, a neutron guide might consist of 2 or 4 coated walls or +# a supermirror bender with multiple, coated vanes. +# +# To describe polarizing supermirrors such as used in neutron reflection, +# it may be necessary to revise this definition of :ref:`NXguide` +# to include :ref:`NXpolarizer` and/or :ref:`NXmirror`. +# +# When even greater complexity exists in the definition of what +# constitutes a *guide*, it has been suggested that :ref:`NXguide` +# be redefined as a :ref:`NXcollection` of :ref:`NXmirror` each +# having their own :ref:`NXgeometry` describing their location(s). +# +# For the more general case when describing mirrors, consider using +# :ref:`NXmirror`. +# +# NOTE: The NeXus International Advisory Committee welcomes +# comments for revision and improvement of +# this definition of :ref:`NXguide`. +# +# +# +# +# TODO: Explain what this NXgeometry group means. What is intended here? +# +# +# A description of this particular instance of ``NXguide``. +# +# +# TODO: documentation needed +# +# +# Reflectivity as function of reflecting surface and wavelength +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# reflectivity of each surface as a function of wavelength +# +# +# +# +# +# +# +# List of surfaces. Probably best to use index +# numbers but the specification is very loose. +# +# +# +# +# +# +# wavelengths at which reflectivity was measured +# +# +# +# +# +# +# TODO: documentation needed +# +# +# TODO: documentation needed +# +# +# +# +# +# +# +# +# +# +# external material outside substrate +# +# +# +# The ``m`` value for a supermirror, which defines the supermirror +# regime in multiples of the critical angle of Nickel. +# +# +# +# +# +# +# TODO: documentation needed +# +# +# +# +# +# TODO: documentation needed +# +# +# +# +# +# TODO: documentation needed +# +# +# +# +# +# TODO: documentation needed +# +# +# +# +# +# TODO: documentation needed +# +# +# +# +# +# +# number of substrate sections (also called ``nsurf`` as an +# index in the ``NXguide`` specification) +# +# +# +# +# This group describes the shape of the beam line component +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# The entry opening of the guide lies on the reference plane. The center of the opening on that plane is +# the reference point on the x and y axis. The reference plane is orthogonal to the z axis and is the +# reference point along the z axis. Given no bend in the guide, it is parallel with z axis and extends +# in the positive direction of the z axis. +# +# .. image:: guide/guide.png +# :width: 40% +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# diff --git a/base_classes/nyaml/NXinsertion_device.yaml b/base_classes/nyaml/NXinsertion_device.yaml new file mode 100644 index 0000000000..a766eea7f8 --- /dev/null +++ b/base_classes/nyaml/NXinsertion_device.yaml @@ -0,0 +1,203 @@ +category: base +doc: | + An insertion device, as used in a synchrotron light source. +type: group +NXinsertion_device(NXobject): + type: + enumeration: [undulator, wiggler] + gap(NX_FLOAT): + unit: NX_LENGTH + doc: | + separation between opposing pairs of magnetic poles + taper(NX_FLOAT): + unit: NX_ANGLE + doc: | + angular of gap difference between upstream and downstream ends of the insertion device + phase(NX_FLOAT): + unit: NX_ANGLE + poles(NX_INT): + unit: NX_UNITLESS + doc: | + number of poles + magnetic_wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + k(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + beam displacement parameter + length(NX_FLOAT): + unit: NX_LENGTH + doc: | + length of insertion device + power(NX_FLOAT): + unit: NX_POWER + doc: | + total power delivered by insertion device + energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + energy of peak intensity in output spectrum + bandwidth(NX_FLOAT): + unit: NX_ENERGY + doc: | + bandwidth of peak energy + + # What are the best units here? + harmonic(NX_INT): + unit: NX_UNITLESS + doc: | + harmonic number of peak + (NXdata)spectrum: + doc: | + spectrum of insertion device + (NXgeometry): + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the device and NXoff_geometry to describe its shape instead + doc: | + "Engineering" position of insertion device + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the beam line component + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a insertion device. + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 66cc252b3f21c2e74504d10b2f495979e96ee7818751b8cfca5265c900729b97 +# +# +# +# +# An insertion device, as used in a synchrotron light source. +# +# +# +# +# +# +# +# separation between opposing pairs of magnetic poles +# +# +# angular of gap difference between upstream and downstream ends of the insertion device +# +# +# +# number of poles +# +# +# +# beam displacement parameter +# +# +# length of insertion device +# +# +# total power delivered by insertion device +# +# +# energy of peak intensity in output spectrum +# +# +# bandwidth of peak energy +# +# +# harmonic number of peak +# +# +# spectrum of insertion device +# +# +# "Engineering" position of insertion device +# +# +# +# This group describes the shape of the beam line component +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a insertion device. +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# diff --git a/base_classes/nyaml/NXinstrument.yaml b/base_classes/nyaml/NXinstrument.yaml new file mode 100644 index 0000000000..d943f5d625 --- /dev/null +++ b/base_classes/nyaml/NXinstrument.yaml @@ -0,0 +1,189 @@ +category: base +doc: | + 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. +type: group +NXinstrument(NXobject): + name: + doc: | + Name of instrument + \@short_name: + doc: | + short name for instrument, perhaps the acronym + energy_resolution(NX_FLOAT): + unit: NX_ENERGY + doc: | + Energy resolution of the experiment (FWHM or gaussian broadening) + momentum_resolution(NX_FLOAT): + unit: NX_WAVENUMBER + doc: | + Momentum resolution of the experiment (FWHM) + angular_resolution(NX_FLOAT): + unit: NX_ANGLE + doc: | + Angular resolution of the experiment (FWHM) + spatial_resolution(NX_FLOAT): + unit: NX_LENGTH + doc: | + Spatial resolution of the experiment (Airy disk radius) + temporal_resolution(NX_FLOAT): + unit: NX_TIME + doc: | + Temporal resolution of the experiment (FWHM) + (NXaperture): + (NXattenuator): + (NXbeam): + (NXbeam_stop): + (NXbending_magnet): + (NXcollimator): + (NXcollection): + (NXcapillary): + (NXcrystal): + (NXdetector): + (NXdetector_group): + (NXdisk_chopper): + (NXevent_data): + (NXfermi_chopper): + (NXfilter): + (NXflipper): + (NXguide): + (NXinsertion_device): + (NXmirror): + (NXmoderator): + (NXmonochromator): + (NXpolarizer): + (NXpositioner): + (NXsource): + (NXtransformations)DIFFRACTOMETER: + (NXvelocity_selector): + (NXxraylens): + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 331d6037bd4c05402a42cab90e3df4c3115b21231d57ef54b1221e1ed859584d +# +# +# +# +# +# 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. +# +# +# +# Name of instrument +# +# +# +# short name for instrument, perhaps the acronym +# +# +# +# +# +# Energy resolution of the experiment (FWHM or gaussian broadening) +# +# +# +# +# Momentum resolution of the experiment (FWHM) +# +# +# +# +# Angular resolution of the experiment (FWHM) +# +# +# +# +# Spatial resolution of the experiment (Airy disk radius) +# +# +# +# +# Temporal resolution of the experiment (FWHM) +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# diff --git a/base_classes/nyaml/NXlog.yaml b/base_classes/nyaml/NXlog.yaml new file mode 100644 index 0000000000..23c562f8ce --- /dev/null +++ b/base_classes/nyaml/NXlog.yaml @@ -0,0 +1,252 @@ +category: base +doc: | + Information recorded as a function of time. + + Description of information that is recorded against + time. There are two common use cases for this: + + - When logging data such as temperature during a run + - When data is taken in streaming mode data acquisition, + i.e. just timestamp, value pairs are stored and + correlated later in data reduction with other data, + + + In both cases, NXlog contains + the logged or streamed values and the times at which they were measured as elapsed time since a starting + time recorded in ISO8601 format. The time units are + specified in the units attribute. An optional scaling attribute + can be used to accomodate non standard clocks. + + + This method of storing logged data helps to distinguish + instances in which a variable is a dimension scale of the data, in which case it is stored + in an :ref:`NXdata` group, and instances in which it is logged during the + run, when it should be stored in an :ref:`NXlog` group. + + In order to make random access to timestamped data faster there is an optional array pair of + ``cue_timestamp_zero`` and ``cue_index``. The ``cue_timestamp_zero`` will + contain coarser timestamps than in the time array, say + every five minutes. The ``cue_index`` will then contain the + index into the time,value pair of arrays for that + coarser ``cue_timestamp_zero``. +type: group +NXlog(NXobject): + time(NX_NUMBER): + unit: NX_TIME + doc: | + Time of logged entry. The times are relative to the "start" attribute + and in the units specified in the "units" + attribute. Please note that absolute + timestamps under unix are relative to ``1970-01-01T00:00:00.0Z``. + + The scaling_factor, when present, has to be applied to the time values in order + to arrive at the units specified in the units attribute. The scaling_factor allows + for arbitrary time units such as ticks of some hardware clock. + \@start: + type: NX_DATE_TIME + \@scaling_factor: + type: NX_NUMBER + value(NX_NUMBER): + unit: NX_ANY + doc: | + Array of logged value, such as temperature. If this is + a single value the dimensionality is + nEntries. However, NXlog can also be used to store + multi dimensional time stamped data such as images. In + this example the dimensionality of values would be value[nEntries,xdim,ydim]. + raw_value(NX_NUMBER): + unit: NX_ANY + doc: | + Array of raw information, such as thermocouple voltage + description: + doc: | + Description of logged value + average_value(NX_FLOAT): + unit: NX_ANY + average_value_error(NX_FLOAT): + unit: NX_ANY + deprecated: | + see: https://github.com/nexusformat/definitions/issues/639 + doc: | + estimated uncertainty (often used: standard deviation) of average_value + average_value_errors(NX_FLOAT): + unit: NX_ANY + doc: | + estimated uncertainty (often used: standard deviation) of average_value + minimum_value(NX_FLOAT): + unit: NX_ANY + maximum_value(NX_FLOAT): + unit: NX_ANY + duration(NX_FLOAT): + unit: NX_ANY + doc: | + Total time log was taken + cue_timestamp_zero(NX_NUMBER): + unit: NX_TIME + doc: | + Timestamps matching the corresponding cue_index into the + time, value pair. + \@start: + type: NX_DATE_TIME + doc: | + If missing start is assumed to be the same as for "time". + \@scaling_factor: + type: NX_NUMBER + doc: | + If missing start is assumed to be the same as for "time". + cue_index(NX_INT): + doc: | + Index into the time, value pair matching the corresponding + cue_timestamp_zero. + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 775c7adbe6f8bd856db0bf06a7f0f735b669cbd37ac5ff47634f9e5bddc485fe +# +# +# +# +# +# Information recorded as a function of time. +# +# Description of information that is recorded against +# time. There are two common use cases for this: +# +# - When logging data such as temperature during a run +# - When data is taken in streaming mode data acquisition, +# i.e. just timestamp, value pairs are stored and +# correlated later in data reduction with other data, +# +# +# In both cases, NXlog contains +# the logged or streamed values and the times at which they were measured as elapsed time since a starting +# time recorded in ISO8601 format. The time units are +# specified in the units attribute. An optional scaling attribute +# can be used to accomodate non standard clocks. +# +# +# This method of storing logged data helps to distinguish +# instances in which a variable is a dimension scale of the data, in which case it is stored +# in an :ref:`NXdata` group, and instances in which it is logged during the +# run, when it should be stored in an :ref:`NXlog` group. +# +# In order to make random access to timestamped data faster there is an optional array pair of +# ``cue_timestamp_zero`` and ``cue_index``. The ``cue_timestamp_zero`` will +# contain coarser timestamps than in the time array, say +# every five minutes. The ``cue_index`` will then contain the +# index into the time,value pair of arrays for that +# coarser ``cue_timestamp_zero``. +# +# +# +# +# Time of logged entry. The times are relative to the "start" attribute +# and in the units specified in the "units" +# attribute. Please note that absolute +# timestamps under unix are relative to ``1970-01-01T00:00:00.0Z``. +# +# The scaling_factor, when present, has to be applied to the time values in order +# to arrive at the units specified in the units attribute. The scaling_factor allows +# for arbitrary time units such as ticks of some hardware clock. +# +# +# +# +# +# +# Array of logged value, such as temperature. If this is +# a single value the dimensionality is +# nEntries. However, NXlog can also be used to store +# multi dimensional time stamped data such as images. In +# this example the dimensionality of values would be value[nEntries,xdim,ydim]. +# +# +# +# Array of raw information, such as thermocouple voltage +# +# +# Description of logged value +# +# +# +# estimated uncertainty (often used: standard deviation) of average_value +# +# +# estimated uncertainty (often used: standard deviation) of average_value +# +# +# +# +# Total time log was taken +# +# +# +# Timestamps matching the corresponding cue_index into the +# time, value pair. +# +# +# If missing start is assumed to be the same as for "time". +# +# +# If missing start is assumed to be the same as for "time". +# +# +# +# +# Index into the time, value pair matching the corresponding +# cue_timestamp_zero. +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# diff --git a/base_classes/nyaml/NXmirror.yaml b/base_classes/nyaml/NXmirror.yaml new file mode 100644 index 0000000000..1f2d7fde93 --- /dev/null +++ b/base_classes/nyaml/NXmirror.yaml @@ -0,0 +1,346 @@ +category: base +doc: | + A beamline mirror or supermirror. +type: group +NXmirror(NXobject): + (NXgeometry): + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the mirror and NXoff_geometry to describe its shape instead + doc: | + + # TODO explain what this group means + type: + enumeration: + single: + doc: | + mirror with a single material as a reflecting surface + multi: + doc: | + mirror with stacked, multiple layers as a reflecting surface + description: + doc: | + description of this mirror + incident_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + (NXdata)reflectivity: + + # TODO Trac ticket #45 applies here. + # https://github.com/nexusformat/definitions/issues/45 + # TODO Solution of ticket #41 will apply here, as well. + # https://github.com/nexusformat/definitions/issues/41 + doc: | + Reflectivity as function of wavelength + + # TODO need more documentation throughout + bend_angle_x(NX_FLOAT): + unit: NX_ANGLE + doc: | + bend_angle_y(NX_FLOAT): + unit: NX_ANGLE + doc: | + interior_atmosphere: + enumeration: [vacuum, helium, argon] + external_material: + doc: | + external material outside substrate + m_value(NX_FLOAT): + unit: NX_UNITLESS + doc: | + The m value for a supermirror, which defines the supermirror + regime in multiples of the critical angle of Nickel. + substrate_material: + doc: | + substrate_density(NX_FLOAT): + unit: NX_MASS_DENSITY + doc: | + substrate_thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + coating_material: + doc: | + substrate_roughness(NX_FLOAT): + unit: NX_LENGTH + doc: | + coating_roughness(NX_FLOAT): + unit: NX_LENGTH + doc: | + even_layer_material: + doc: | + even_layer_density(NX_FLOAT): + unit: NX_MASS_DENSITY + doc: | + odd_layer_material: + doc: | + odd_layer_density(NX_FLOAT): + unit: NX_MASS_DENSITY + doc: | + layer_thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + An array describing the thickness of each layer + (NXshape)shape: + deprecated: Use NXoff_geometry instead + doc: | + A NXshape group describing the shape of the mirror + figure_data(NXdata): + doc: | + Numerical description of the surface figure of the mirror. + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the beam line component + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + 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. + + Given a flat mirror, the reference plane is the plane which contains the "entry" surface of the mirror. The reference + point of the mirror in the x and y axis is the centre of the mirror on that plane. The reference plane is orthogonal + to the z axis and the location of this plane is the reference point on the z axis. The mirror faces negative z values. + + .. image:: mirror/mirror.png + :width: 40% + (NXtransformations): + doc: | + 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. + + # TODO need more parameters here, such as ... + # list from Rainer Gehrke, DESY (some items may already be present) + # Parameters for mirrors + # Field indicating whether simple or multilayer + # Substrate element or compound + # Substrate density + # In case of multilayer: Even layer material (element or compound) + # Even layer density + # Odd layer material (element or compound) + # Odd layer density + # Number of layer pairs + # Layer thickness (array) + # Figure for crystals and mirrors (to describe curved surfaces) + # Field indicating whether concave or convex + # Field indicating whether cylindrical or not + # If cylindrical: cylinder orientation angle + # Now come the different surface figures with the necessary parameters: + # 1. Flat + # 2. Spherical (spherical radius) + # 3. Elliptical and hyperbolical (semi-major axis, semi-minor axis, angle of major axis and pole) + # 4. Toroidal (major radius, minor radius) + # 5. Parabolical (parabolic parameter a) + # 6. Conical (cone half aperture) + # 7. Polynomial (degree of polynom, array with polynom coefficients) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# a03676b8f4d052897916c9b81795834122a04f213afa50c03aa362eb1386a7c4 +# +# +# +# +# A beamline mirror or supermirror. +# +# +# +# +# +# +# mirror with a single material as a reflecting surface +# mirror with stacked, multiple layers as a reflecting surface +# +# +# +# description of this mirror +# +# +# +# +# +# +# Reflectivity as function of wavelength +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# external material outside substrate +# +# +# +# The m value for a supermirror, which defines the supermirror +# regime in multiples of the critical angle of Nickel. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# An array describing the thickness of each layer +# +# +# A NXshape group describing the shape of the mirror +# +# +# Numerical description of the surface figure of the mirror. +# +# +# +# This group describes the shape of the beam line component +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# Given a flat mirror, the reference plane is the plane which contains the "entry" surface of the mirror. The reference +# point of the mirror in the x and y axis is the centre of the mirror on that plane. The reference plane is orthogonal +# to the z axis and the location of this plane is the reference point on the z axis. The mirror faces negative z values. +# +# .. image:: mirror/mirror.png +# :width: 40% +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXmoderator.yaml b/base_classes/nyaml/NXmoderator.yaml new file mode 100644 index 0000000000..933a5d19eb --- /dev/null +++ b/base_classes/nyaml/NXmoderator.yaml @@ -0,0 +1,193 @@ +category: base +doc: | + A neutron moderator +type: group +NXmoderator(NXobject): + (NXgeometry): + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the moderator and NXoff_geometry to describe its shape instead + doc: | + "Engineering" position of moderator + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + Effective distance as seen by measuring radiation. + Note, it is recommended to use NXtransformations instead. + type: + enumeration: [H20, D20, Liquid H2, Liquid CH4, Liquid D2, Solid D2, C, Solid CH4, Solid H2] + poison_depth(NX_FLOAT): + unit: NX_LENGTH + coupled(NX_BOOLEAN): + doc: | + whether the moderator is coupled + coupling_material: + doc: | + The material used for coupling. Usually Cd. + poison_material: + enumeration: [Gd, Cd] + temperature(NX_FLOAT): + unit: NX_TEMPERATURE + doc: | + average/nominal moderator temperature + (NXlog)temperature_log: + doc: | + log file of moderator temperature + (NXdata)pulse_shape: + doc: | + moderator pulse shape + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the moderator + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference point of the moderator is its center in the x and y axis. The reference point on the z axis is the + surface of the moderator pointing towards the source (the negative part of the z axis). + + .. image:: moderator/moderator.png + :width: 40% + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# ff14aa8ec99692829b7fdf4b0cef94d8ec8835d366dab359d75fdf1754289e8a +# +# +# +# +# A neutron moderator +# +# "Engineering" position of moderator +# +# +# +# Effective distance as seen by measuring radiation. +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# whether the moderator is coupled +# +# +# The material used for coupling. Usually Cd. +# +# +# +# +# +# +# +# +# average/nominal moderator temperature +# +# +# log file of moderator temperature +# +# +# moderator pulse shape +# +# +# +# This group describes the shape of the moderator +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# The reference point of the moderator is its center in the x and y axis. The reference point on the z axis is the +# surface of the moderator pointing towards the source (the negative part of the z axis). +# +# .. image:: moderator/moderator.png +# :width: 40% +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# diff --git a/base_classes/nyaml/NXmonitor.yaml b/base_classes/nyaml/NXmonitor.yaml new file mode 100644 index 0000000000..7135187cd0 --- /dev/null +++ b/base_classes/nyaml/NXmonitor.yaml @@ -0,0 +1,293 @@ +category: base +doc: | + A monitor of incident beam data. + + It is similar to the :ref:`NXdata` groups containing + monitor data and its associated dimension scale, e.g. time_of_flight or + wavelength in pulsed neutron instruments. However, it may also include + integrals, or scalar monitor counts, which are often used in both in both + pulsed and steady-state instrumentation. +type: group +NXmonitor(NXobject): + mode: + doc: | + Count to a preset value based on either clock time (timer) + or received monitor counts (monitor). + enumeration: [monitor, timer] + start_time(NX_DATE_TIME): + doc: | + Starting time of measurement + end_time(NX_DATE_TIME): + doc: | + Ending time of measurement + preset(NX_NUMBER): + unit: NX_ANY + doc: | + preset value for time or monitor + distance(NX_FLOAT): + unit: NX_LENGTH + deprecated: Use transformations/distance instead + doc: | + Distance of monitor from sample + range(NX_FLOAT): + unit: NX_ANY + doc: | + Range (X-axis, Time-of-flight, etc.) over which the integral was calculated + dimensions: + dim: [[1, 2]] + nominal(NX_NUMBER): + unit: NX_ANY + doc: | + Nominal reading to be used for normalisation purposes. + integral(NX_NUMBER): + unit: NX_ANY + doc: | + Total integral monitor counts + integral_log(NXlog): + doc: | + Time variation of monitor counts + type: + enumeration: [Fission Chamber, Scintillator] + time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + doc: | + Time-of-flight + dimensions: + dim: [[1, ]] + dim_parameters: + ref: ['efficiency'] + efficiency(NX_NUMBER): + unit: NX_DIMENSIONLESS + doc: | + Monitor efficiency + dimensions: + dim: [[1, ]] + dim_parameters: + ref: ['i'] + data(NX_NUMBER): + unit: NX_ANY + doc: | + Monitor data + dimensions: + rank: dataRank + doc: | + The rank (``dataRank``) of the ``data`` must satisfy + ``1 <= dataRank <= NX_MAXRANK=32``. + At least one ``dim`` must have length ``n``. + dim: [] + sampled_fraction(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + Proportion of incident beam sampled by the monitor (0 +# +# +# +# +# A monitor of incident beam data. +# +# It is similar to the :ref:`NXdata` groups containing +# monitor data and its associated dimension scale, e.g. time_of_flight or +# wavelength in pulsed neutron instruments. However, it may also include +# integrals, or scalar monitor counts, which are often used in both in both +# pulsed and steady-state instrumentation. +# +# +# +# Count to a preset value based on either clock time (timer) +# or received monitor counts (monitor). +# +# +# +# +# +# +# +# Starting time of measurement +# +# +# Ending time of measurement +# +# +# preset value for time or monitor +# +# +# Distance of monitor from sample +# +# +# Range (X-axis, Time-of-flight, etc.) over which the integral was calculated +# +# +# +# Nominal reading to be used for normalisation purposes. +# +# +# Total integral monitor counts +# +# +# Time variation of monitor counts +# +# +# +# +# +# +# +# +# Time-of-flight +# +# +# +# +# +# Monitor efficiency +# +# +# +# +# Monitor data +# +# +# +# The rank (``dataRank``) of the ``data`` must satisfy +# ``1 <= dataRank <= NX_MAXRANK=32``. +# At least one ``dim`` must have length ``n``. +# +# +# +# +# Proportion of incident beam sampled by the monitor (0<x<1) +# +# +# Geometry of the monitor +# +# +# +# Elapsed actual counting time, can be an array of size ``np`` +# when scanning. This is not the difference of the calendar time +# but the time the instrument was really counting, without +# pauses or times lost due beam unavailability +# +# +# +# +# This group describes the shape of the beam line component +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# The reference plane of the monitor contains the surface of the detector that faces the source +# and is the entry point of the beam. The reference point of the monitor in the x and y axis is +# its centre on this surface. The reference plane is orthogonal to the the z axis and the +# reference point on this z axis is where they intersect. +# +# .. image:: monitor/monitor.png +# :width: 40% +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# diff --git a/base_classes/nyaml/NXmonochromator.yaml b/base_classes/nyaml/NXmonochromator.yaml new file mode 100644 index 0000000000..83a26bf0a6 --- /dev/null +++ b/base_classes/nyaml/NXmonochromator.yaml @@ -0,0 +1,197 @@ +category: base +doc: | + A wavelength defining device. + + This is a base class for everything which + selects a wavelength or energy, be it a + monochromator crystal, a velocity selector, + an undulator or whatever. + + The expected units are: + + * wavelength: angstrom + * energy: eV +type: group +NXmonochromator(NXobject): + wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + wavelength selected + wavelength_error(NX_FLOAT): + unit: NX_WAVELENGTH + deprecated: | + see https://github.com/nexusformat/definitions/issues/820 + doc: | + wavelength standard deviation + wavelength_errors(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + wavelength standard deviation + energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + energy selected + energy_error(NX_FLOAT): + unit: NX_ENERGY + deprecated: | + see https://github.com/nexusformat/definitions/issues/820 + doc: | + energy standard deviation + energy_errors(NX_FLOAT): + unit: NX_ENERGY + doc: | + energy standard deviation + (NXdata)distribution: + (NXgeometry)geometry: + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the monochromator and NXoff_geometry to describe its shape instead + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the beam line component + (NXcrystal): + doc: | + Use as many crystals as necessary to describe + (NXvelocity_selector): + (NXgrating): + doc: | + For diffraction grating based monochromators + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a monochromator. + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 7c8e15a2e9b17a3867e3f0c2b0b16c8a8c70c7b512f1f20340e7a2398b21ab7b +# +# +# +# +# +# A wavelength defining device. +# +# This is a base class for everything which +# selects a wavelength or energy, be it a +# monochromator crystal, a velocity selector, +# an undulator or whatever. +# +# The expected units are: +# +# * wavelength: angstrom +# * energy: eV +# +# +# +# wavelength selected +# +# +# wavelength standard deviation +# +# +# wavelength standard deviation +# +# +# energy selected +# +# +# energy standard deviation +# +# +# energy standard deviation +# +# +# +# +# +# This group describes the shape of the beam line component +# +# +# Use as many crystals as necessary to describe +# +# For diffraction grating based monochromators +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a monochromator. +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# diff --git a/base_classes/nyaml/NXnote.yaml b/base_classes/nyaml/NXnote.yaml new file mode 100644 index 0000000000..229f0c82b0 --- /dev/null +++ b/base_classes/nyaml/NXnote.yaml @@ -0,0 +1,116 @@ +category: base +doc: | + 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 +type: group +NXnote(NXobject): + author: + doc: | + Author or creator of note + date(NX_DATE_TIME): + doc: | + Date note created/added + type: + doc: | + Mime content type of note data field e.g. image/jpeg, text/plain, text/html + file_name: + doc: | + Name of original file name if note was read from an external source + description: + doc: | + Title of an image or other details of the note + sequence_index(NX_POSINT): + doc: | + Sequence index of note, for placing a sequence of + multiple **NXnote** groups in an order. Starts with 1. + data(NX_BINARY): + doc: | + Binary note data - if text, line terminator is [CR][LF]. + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# cac46891aabdb595f69910c7ddb6a496bd16f4e98055ddc5570ef01fbeed1e73 +# +# +# +# +# +# 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 +# +# +# Author or creator of note +# +# +# Date note created/added +# +# +# Mime content type of note data field e.g. image/jpeg, text/plain, text/html +# +# +# Name of original file name if note was read from an external source +# +# +# Title of an image or other details of the note +# +# +# +# Sequence index of note, for placing a sequence of +# multiple **NXnote** groups in an order. Starts with 1. +# +# +# +# Binary note data - if text, line terminator is [CR][LF]. +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# diff --git a/base_classes/nyaml/NXobject.yaml b/base_classes/nyaml/NXobject.yaml new file mode 100644 index 0000000000..cbf07862fb --- /dev/null +++ b/base_classes/nyaml/NXobject.yaml @@ -0,0 +1,44 @@ +category: base +doc: | + This is the base object of NeXus +type: group +NXobject: + + # attribute name="name">name of instance +# +# +# +# +# This is the base object of NeXus +# +# +# +# diff --git a/base_classes/nyaml/NXoff_geometry.yaml b/base_classes/nyaml/NXoff_geometry.yaml new file mode 100644 index 0000000000..abc3de7ede --- /dev/null +++ b/base_classes/nyaml/NXoff_geometry.yaml @@ -0,0 +1,197 @@ +category: base +doc: | + Geometry (shape) description. + The format closely matches the Object File Format (OFF) which can be output + by most CAD software. + It can be used to describe the shape of any beamline component, including detectors. + In the case of detectors it can be used to define the shape of a single pixel, or, + if the pixel shapes are non-uniform, to describe the shape of the whole detector. +symbols: + doc: | + These symbols will be used below. + i: | + number of vertices in the shape + k: | + number of faces in the shape + l: | + number faces which are detecting surfaces or form the boundary of + detecting volumes +type: group +NXoff_geometry(NXobject): + vertices(NX_NUMBER): + unit: NX_LENGTH + doc: | + List of x,y,z coordinates for vertices. + The origin of the coordinates is the position of the parent component, for + example the NXdetector which the geometry describes. + If the shape describes a single pixel for a detector with uniform pixel + shape then the origin is the position of each pixel as described by the + ``x/y/z_pixel_offset`` datasets in ``NXdetector``. + dimensions: + rank: 2 + dim: [[1, i], [2, 3]] + winding_order(NX_INT): + doc: | + List of indices of vertices in the ``vertices`` dataset to form each face, + right-hand rule for face normal. + dimensions: + rank: 1 + dim: [[1, j]] + faces(NX_INT): + doc: | + The start index in ``winding_order`` for each face. + dimensions: + rank: 1 + dim: [[1, k]] + detector_faces(NX_INT): + doc: | + List of pairs of index in the "faces" dataset and detector id. Face IDs in + the first column, and corresponding detector IDs in the second column. + This dataset should only be used only if the ``NXoff_geometry`` group is + describing a detector. + Note, the face indices must be in ascending order but need not be + consecutive as not every face in faces need be a detecting surface or + boundary of detecting volume. + Can use multiple entries with the same detector id to define detector volumes. + dimensions: + rank: 2 + dim: [[1, l], [2, 2]] + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 593884a075055d155060d7a8bb7a8d3b3164efcad905aed084064fc4ae052ead +# +# +# +# +# +# +# These symbols will be used below. +# number of vertices in the shape +# number of faces in the shape +# +# +# number faces which are detecting surfaces or form the boundary of +# detecting volumes +# +# +# +# +# +# Geometry (shape) description. +# The format closely matches the Object File Format (OFF) which can be output +# by most CAD software. +# It can be used to describe the shape of any beamline component, including detectors. +# In the case of detectors it can be used to define the shape of a single pixel, or, +# if the pixel shapes are non-uniform, to describe the shape of the whole detector. +# +# +# +# +# +# List of x,y,z coordinates for vertices. +# The origin of the coordinates is the position of the parent component, for +# example the NXdetector which the geometry describes. +# If the shape describes a single pixel for a detector with uniform pixel +# shape then the origin is the position of each pixel as described by the +# ``x/y/z_pixel_offset`` datasets in ``NXdetector``. +# +# +# +# +# +# +# +# +# +# +# +# +# List of indices of vertices in the ``vertices`` dataset to form each face, +# right-hand rule for face normal. +# +# +# +# +# +# +# +# +# +# +# The start index in ``winding_order`` for each face. +# +# +# +# +# +# +# +# +# +# +# List of pairs of index in the "faces" dataset and detector id. Face IDs in +# the first column, and corresponding detector IDs in the second column. +# This dataset should only be used only if the ``NXoff_geometry`` group is +# describing a detector. +# Note, the face indices must be in ascending order but need not be +# consecutive as not every face in faces need be a detecting surface or +# boundary of detecting volume. +# Can use multiple entries with the same detector id to define detector volumes. +# +# +# +# +# +# +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# diff --git a/base_classes/nyaml/NXorientation.yaml b/base_classes/nyaml/NXorientation.yaml new file mode 100644 index 0000000000..04a28a40cb --- /dev/null +++ b/base_classes/nyaml/NXorientation.yaml @@ -0,0 +1,111 @@ +category: base +doc: | + legacy class - recommend to use :ref:`NXtransformations` now + + Description for a general orientation of a component - used by :ref:`NXgeometry` +type: group +NXorientation(NXobject): + (NXgeometry): + doc: | + Link to another object if we are using relative positioning, else absent + value(NX_FLOAT): + unit: NX_UNITLESS + doc: | + The orientation information is stored as direction cosines. The direction cosines will + be between the local coordinate directions and the reference directions (to origin or + relative NXgeometry). Calling the local unit vectors (x',y',z') and the reference unit + vectors (x,y,z) the six numbers will be [x' dot x, x' dot y, x' dot z, y' dot x, y' dot + y, y' dot z] where "dot" is the scalar dot product (cosine of the angle between the unit + vectors). The unit vectors in both the local and reference coordinates are right-handed + and orthonormal. + + The pair of groups NXtranslation and NXorientation together + describe the position of a component. + dimensions: + + # numobj,6 + dim: [[1, numobj], [2, 6]] + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# b837027cfb5d13fbee2db64988ee3af2d8ea788d712eaf5455b1eba597023f42 +# +# +# +# +# +# legacy class - recommend to use :ref:`NXtransformations` now +# +# Description for a general orientation of a component - used by :ref:`NXgeometry` +# +# +# Link to another object if we are using relative positioning, else absent +# +# +# +# The orientation information is stored as direction cosines. The direction cosines will +# be between the local coordinate directions and the reference directions (to origin or +# relative NXgeometry). Calling the local unit vectors (x',y',z') and the reference unit +# vectors (x,y,z) the six numbers will be [x' dot x, x' dot y, x' dot z, y' dot x, y' dot +# y, y' dot z] where "dot" is the scalar dot product (cosine of the angle between the unit +# vectors). The unit vectors in both the local and reference coordinates are right-handed +# and orthonormal. +# +# The pair of groups NXtranslation and NXorientation together +# describe the position of a component. +# +# +# +# +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# diff --git a/base_classes/nyaml/NXparameters.yaml b/base_classes/nyaml/NXparameters.yaml new file mode 100644 index 0000000000..e81a3b034b --- /dev/null +++ b/base_classes/nyaml/NXparameters.yaml @@ -0,0 +1,75 @@ +category: base +doc: | + Container for parameters, usually used in processing or analysis. +type: group +NXparameters(NXobject): + term(NX_CHAR): + exists: ['min', '0', 'max', 'unbounded'] + + # maxOccurs="unbounded" is intended but is not allowed by current syntax + doc: | + A parameter (also known as a term) that is used in or results from processing. + \@units: + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 4306876a0e67eaf3b38dfb0d8c2236908c7816908082629bdeb23948c1842a87 +# +# +# +# +# Container for parameters, usually used in processing or analysis. +# +# +# A parameter (also known as a term) that is used in or results from processing. +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# diff --git a/base_classes/nyaml/NXpdb.yaml b/base_classes/nyaml/NXpdb.yaml new file mode 100644 index 0000000000..24cfd73920 --- /dev/null +++ b/base_classes/nyaml/NXpdb.yaml @@ -0,0 +1,329 @@ +category: base + +# The ignoreExtra* attributes are used in the definition to +# avoid warning messages that would be generated from +# unexpected groups, fields, and attributes. +# Since no groups or attributes are declared here, _every_ +# child of this class would generate a warning message without this +# attribute being set to "true". +doc: | + A NeXus transliteration of a PDB file, to be validated only as a PDB + rather than in NeXus. + + Use :ref:`NXpdb` to incorporate the information in an arbitrary + PDB into a NeXus file. + + The main suggestion is to use this as a container + class for a PDB entry to describe a sample in NXsample, + but it may be more appropriate to place this higher in the + hierarchy, say in NXentry. + + The structure has to follow the structure of a PDB + with each PDB data block mapped to a NeXus group of class NXpdb, + using a lowercase version of the data block name as the name + of the NeXus group, each PDB category in that data block + mapped to a NeXus group of class NXpdb and with each PDB column + mapped to a NeXus field. Each column in a looped PDB category + should always be presented as a 1-dimensional array. The columns + in an unlooped PDB category should be presented as scalar values. + If a PDB category specifies particular units for columns, the same + units should beused for the corresponding fields. + + A PDB entry is unambigous when all information is carried as text. + All text data should be presented as quoted strings, with the quote + marks except for the null values "." or "?" + + For clarity in NXpdb form, numeric data may be presented using the + numeric types specified in the mmCIF dictionary. In that case, + if a PDB null value, "." or "?", is contained in a numeric column, the + IEEE nan should be used for "?" and the IEEE inf should be used for ".". + + An arbitrary DDL2 CIF file can be represented in NeXus using NXpdb. + However, if save frames are required, an NXpdb_class attribute with the + value "CBF_cbfsf" is required for each NeXus group representing a save + frame. NXpdb attributes are not required for other CIF components, + but may be used to provide internal documentation. + + The nesting of NXpdb groups and datasets that correspond to a CIF with + two categories and one saveframe, including the NXpdb_class attribues is:: + + (datablock1):NXpdb + @NXpdb_class:CBF_cbfdb + (category1):NXpdb + @NXpdb_class:CBF_cbfcat + (column_name1):[...] + (column_name2):[...] + (column_name3):[...] + ... + (category2):NXpdb + @NXpdb_class:CBF_cbfcat + (column_name4):[...] + (column_name5):[...] + (column_name6):[...] + ... + (saveframe1):NXpdb + @NXpdb_class:CBF_cbfsf + (category3):NXpdb + @NXpdb_class:CBF_cbfcat + (column_name7):[...] + (column_name8):[...] + (column_name9):[...] + ... + ... + ... + + + + For example, a PDB entry that begins:: + + data_1YVA + # + _entry.id 1YVA + # + _audit_conform.dict_name mmcif_pdbx.dic + _audit_conform.dict_version 5.279 + _audit_conform.dict_location http://mmcif.pdb.org/dictionaries/ascii/mmcif_pdbx.dic + # + loop_ + _database_2.database_id + _database_2.database_code + PDB 1YVA + RCSB RCSB031959 + WWPDB D_1000031959 + # + + would produce:: + + sample:NXsample + 1yva:NXpdb + entry:NXpdb + id:"1YVA" + audit_conform:NXpdb + dict_name:"mmcif_pdbx.dic" + dict_version:"5.279" + dict_location:"http://mmcif.pdb.org/dictionaries/ascii/mmcif_pdbx.dic" + database_2:NXpdb + database_id:["PDB","RCSB","WWPDB"] + database_code:["1YVA","RCSB031959","D_1000031959"] + + another example is the following excerpt from pdb entry 9ins, giving the sequences + of the two chains:: + + loop_ + _entity_poly.entity_id + _entity_poly.nstd_linkage + _entity_poly.nstd_monomer + _entity_poly.pdbx_seq_one_letter_code + _entity_poly.pdbx_seq_one_letter_code_can + _entity_poly.type + 1 no no GIVEQCCTSICSLYQLENYCN GIVEQCCTSICSLYQLENYCN polypeptide(L) + 2 no no FVNQHLCGSHLVEALYLVCGERGFFYTPKA FVNQHLCGSHLVEALYLVCGERGFFYTPKA + polypeptide(L) + + which converts to:: + + entity_poly:NXpdb + @NXpdb_class:CBF_cbfcat + entity_id:["1", "2"] + nstd_linkage:["no", "no"] + nstd_monomer:["no", "no"] + pdbx_seq_one_letter_code:["GIVEQCCTSICSLYQLENYCN","FVNQHLCGSHLVEALYLVCGERGFFYTPKA"] + pdbx_seq_one_letter_code_can:["GIVEQCCTSICSLYQLENYCN","FVNQHLCGSHLVEALYLVCGERGFFYTPKA"] + type:["polypeptide(L)", "polypeptide(L)"] +type: group +ignoreExtraGroups: true +ignoreExtraFields: true +ignoreExtraAttributes: true +NXpdb(NXobject): + + # NOTE + # ===== + # NXpdb is a class not validated by the NXDL tools. + # Do not add any subgroups in this nxdl file. + # See: https://github.com/nexusformat/definitions/issues/259 + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# a7abffb938a9848149b6d1c2b7f0e7d0f47792f36c6dc44ad9f3831a9c3c0172 +# +# +# +# +# +# +# +# +# A NeXus transliteration of a PDB file, to be validated only as a PDB +# rather than in NeXus. +# +# Use :ref:`NXpdb` to incorporate the information in an arbitrary +# PDB into a NeXus file. +# +# The main suggestion is to use this as a container +# class for a PDB entry to describe a sample in NXsample, +# but it may be more appropriate to place this higher in the +# hierarchy, say in NXentry. +# +# The structure has to follow the structure of a PDB +# with each PDB data block mapped to a NeXus group of class NXpdb, +# using a lowercase version of the data block name as the name +# of the NeXus group, each PDB category in that data block +# mapped to a NeXus group of class NXpdb and with each PDB column +# mapped to a NeXus field. Each column in a looped PDB category +# should always be presented as a 1-dimensional array. The columns +# in an unlooped PDB category should be presented as scalar values. +# If a PDB category specifies particular units for columns, the same +# units should beused for the corresponding fields. +# +# A PDB entry is unambigous when all information is carried as text. +# All text data should be presented as quoted strings, with the quote +# marks except for the null values "." or "?" +# +# For clarity in NXpdb form, numeric data may be presented using the +# numeric types specified in the mmCIF dictionary. In that case, +# if a PDB null value, "." or "?", is contained in a numeric column, the +# IEEE nan should be used for "?" and the IEEE inf should be used for ".". +# +# An arbitrary DDL2 CIF file can be represented in NeXus using NXpdb. +# However, if save frames are required, an NXpdb_class attribute with the +# value "CBF_cbfsf" is required for each NeXus group representing a save +# frame. NXpdb attributes are not required for other CIF components, +# but may be used to provide internal documentation. +# +# The nesting of NXpdb groups and datasets that correspond to a CIF with +# two categories and one saveframe, including the NXpdb_class attribues is:: +# +# (datablock1):NXpdb +# @NXpdb_class:CBF_cbfdb +# (category1):NXpdb +# @NXpdb_class:CBF_cbfcat +# (column_name1):[...] +# (column_name2):[...] +# (column_name3):[...] +# ... +# (category2):NXpdb +# @NXpdb_class:CBF_cbfcat +# (column_name4):[...] +# (column_name5):[...] +# (column_name6):[...] +# ... +# (saveframe1):NXpdb +# @NXpdb_class:CBF_cbfsf +# (category3):NXpdb +# @NXpdb_class:CBF_cbfcat +# (column_name7):[...] +# (column_name8):[...] +# (column_name9):[...] +# ... +# ... +# ... +# +# +# +# For example, a PDB entry that begins:: +# +# data_1YVA +# # +# _entry.id 1YVA +# # +# _audit_conform.dict_name mmcif_pdbx.dic +# _audit_conform.dict_version 5.279 +# _audit_conform.dict_location http://mmcif.pdb.org/dictionaries/ascii/mmcif_pdbx.dic +# # +# loop_ +# _database_2.database_id +# _database_2.database_code +# PDB 1YVA +# RCSB RCSB031959 +# WWPDB D_1000031959 +# # +# +# would produce:: +# +# sample:NXsample +# 1yva:NXpdb +# entry:NXpdb +# id:"1YVA" +# audit_conform:NXpdb +# dict_name:"mmcif_pdbx.dic" +# dict_version:"5.279" +# dict_location:"http://mmcif.pdb.org/dictionaries/ascii/mmcif_pdbx.dic" +# database_2:NXpdb +# database_id:["PDB","RCSB","WWPDB"] +# database_code:["1YVA","RCSB031959","D_1000031959"] +# +# another example is the following excerpt from pdb entry 9ins, giving the sequences +# of the two chains:: +# +# loop_ +# _entity_poly.entity_id +# _entity_poly.nstd_linkage +# _entity_poly.nstd_monomer +# _entity_poly.pdbx_seq_one_letter_code +# _entity_poly.pdbx_seq_one_letter_code_can +# _entity_poly.type +# 1 no no GIVEQCCTSICSLYQLENYCN GIVEQCCTSICSLYQLENYCN polypeptide(L) +# 2 no no FVNQHLCGSHLVEALYLVCGERGFFYTPKA FVNQHLCGSHLVEALYLVCGERGFFYTPKA +# polypeptide(L) +# +# which converts to:: +# +# entity_poly:NXpdb +# @NXpdb_class:CBF_cbfcat +# entity_id:["1", "2"] +# nstd_linkage:["no", "no"] +# nstd_monomer:["no", "no"] +# pdbx_seq_one_letter_code:["GIVEQCCTSICSLYQLENYCN","FVNQHLCGSHLVEALYLVCGERGFFYTPKA"] +# pdbx_seq_one_letter_code_can:["GIVEQCCTSICSLYQLENYCN","FVNQHLCGSHLVEALYLVCGERGFFYTPKA"] +# type:["polypeptide(L)", "polypeptide(L)"] +# +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXpinhole.yaml b/base_classes/nyaml/NXpinhole.yaml new file mode 100644 index 0000000000..69fd2fe2cb --- /dev/null +++ b/base_classes/nyaml/NXpinhole.yaml @@ -0,0 +1,125 @@ +category: base +doc: | + A simple pinhole. + + For more complex geometries, :ref:`NXaperture` should be used. +type: group +NXpinhole(NXobject): + depends_on(NX_CHAR): + doc: | + Points to the path of the last element in the geometry chain that places + this object in space. + When followed through that chain is supposed to end at an element depending + on "." i.e. the origin of the coordinate system. + If desired the location of the slit can also be described relative to + an NXbeam, which will allow a simple description of a non-centred pinhole. + + The reference direction of the pinhole is parallel with the z axis. The reference + point of the pinhole is its center in the x and y axis. The reference point on the z axis is the + plane which overlaps the side of the opening of the pin hole pointing towards the source (minus on the z axis). + + .. image:: pinhole/pinhole.png + :width: 40% + diameter(NX_NUMBER): + unit: NX_LENGTH + doc: | + Size of the circular hole defining the transmitted beam size. + (NXtransformations): + exists: ['min', '0'] + doc: | + 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. + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# c70638ef9748cfd94d36132613305136639cd062a10e8771d7e78ba4f865dd85 +# +# +# +# +# +# A simple pinhole. +# +# For more complex geometries, :ref:`NXaperture` should be used. +# +# +# +# Points to the path of the last element in the geometry chain that places +# this object in space. +# When followed through that chain is supposed to end at an element depending +# on "." i.e. the origin of the coordinate system. +# If desired the location of the slit can also be described relative to +# an NXbeam, which will allow a simple description of a non-centred pinhole. +# +# The reference direction of the pinhole is parallel with the z axis. The reference +# point of the pinhole is its center in the x and y axis. The reference point on the z axis is the +# plane which overlaps the side of the opening of the pin hole pointing towards the source (minus on the z axis). +# +# .. image:: pinhole/pinhole.png +# :width: 40% +# +# +# +# +# Size of the circular hole defining the transmitted beam size. +# +# +# +# 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. +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# diff --git a/base_classes/nyaml/NXpolarizer.yaml b/base_classes/nyaml/NXpolarizer.yaml new file mode 100644 index 0000000000..0380ddb99e --- /dev/null +++ b/base_classes/nyaml/NXpolarizer.yaml @@ -0,0 +1,135 @@ +category: base +doc: | + A spin polarizer. +type: group +NXpolarizer(NXobject): + type: + doc: | + one of these values: "crystal", "supermirror", "3He" + composition: + doc: | + description of the composition of the polarizing material + reflection(NX_INT): + unit: NX_UNITLESS + doc: | + [hkl] values of nominal reflection + dimensions: + dim: [[1, 3]] + efficiency(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + polarizing efficiency + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a polarizer. + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 489a3377a505248d4d66e2c674c112f1eb6f8ca85c6f02fbedbe8b7ba40149d4 +# +# +# +# +# +# A spin polarizer. +# +# +# one of these values: "crystal", "supermirror", "3He" +# +# +# description of the composition of the polarizing material +# +# +# [hkl] values of nominal reflection +# +# +# +# +# +# polarizing efficiency +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a polarizer. +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# diff --git a/base_classes/nyaml/NXpositioner.yaml b/base_classes/nyaml/NXpositioner.yaml new file mode 100644 index 0000000000..36178fda4e --- /dev/null +++ b/base_classes/nyaml/NXpositioner.yaml @@ -0,0 +1,200 @@ +category: base +doc: | + A generic positioner such as a motor or piezo-electric transducer. +type: group +NXpositioner(NXobject): + name: + doc: | + symbolic or mnemonic name (one word) + description: + doc: | + description of positioner + value(NX_NUMBER): + unit: NX_ANY + doc: | + best known value of positioner - need [n] as may be scanned + dimensions: + rank: 1 + dim: [[1, n]] + raw_value(NX_NUMBER): + unit: NX_ANY + doc: | + raw value of positioner - need [n] as may be scanned + dimensions: + rank: 1 + dim: [[1, n]] + target_value(NX_NUMBER): + unit: NX_ANY + doc: | + targeted (commanded) value of positioner - need [n] as may be scanned + dimensions: + rank: 1 + dim: [[1, n]] + tolerance(NX_NUMBER): + unit: NX_ANY + doc: | + maximum allowable difference between target_value and value + dimensions: + rank: 1 + dim: [[1, n]] + soft_limit_min(NX_NUMBER): + unit: NX_ANY + doc: | + minimum allowed limit to set value + soft_limit_max(NX_NUMBER): + unit: NX_ANY + doc: | + maximum allowed limit to set value + velocity(NX_NUMBER): + unit: NX_ANY + doc: | + velocity of the positioner (distance moved per unit time) + acceleration_time(NX_NUMBER): + unit: NX_ANY + doc: | + time to ramp the velocity up to full speed + + # TODO other parameters: settling time, backlash, link to readback channel + controller_record: + doc: | + Hardware device record, e.g. EPICS process variable, taco/tango ... + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a positioner. + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 9e3dc1962303ddef4d403e479bfde3b47cdd8a9fa15c57bf2fadfb6e55ff541f +# +# +# +# +# +# A generic positioner such as a motor or piezo-electric transducer. +# +# +# symbolic or mnemonic name (one word) +# +# +# description of positioner +# +# +# best known value of positioner - need [n] as may be scanned +# +# +# +# raw value of positioner - need [n] as may be scanned +# +# +# +# targeted (commanded) value of positioner - need [n] as may be scanned +# +# +# +# maximum allowable difference between target_value and value +# +# +# +# minimum allowed limit to set value +# +# +# maximum allowed limit to set value +# +# +# velocity of the positioner (distance moved per unit time) +# +# +# time to ramp the velocity up to full speed +# +# +# +# Hardware device record, e.g. EPICS process variable, taco/tango ... +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a positioner. +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# diff --git a/base_classes/nyaml/NXprocess.yaml b/base_classes/nyaml/NXprocess.yaml new file mode 100644 index 0000000000..3dbc4ee78a --- /dev/null +++ b/base_classes/nyaml/NXprocess.yaml @@ -0,0 +1,138 @@ +category: base +doc: | + Document an event of data processing, reconstruction, or analysis for this data. +type: group +NXprocess(NXobject): + program(NX_CHAR): + doc: | + Name of the program used + sequence_index(NX_POSINT): + doc: | + Sequence index of processing, + for determining the order of multiple **NXprocess** steps. + Starts with 1. + version(NX_CHAR): + doc: | + Version of the program used + date(NX_DATE_TIME): + doc: | + Date and time of processing. + (NXregistration): + doc: | + Describes the operations of image registration + (NXdistortion): + doc: | + Describes the operations of image distortion correction + (NXcalibration): + doc: | + Describes the operations of calibration procedures, e.g. axis calibrations. + (NXnote): + doc: | + The note will contain information about how the data was processed + or anything about the data provenance. + The contents of the note can be anything that the processing code + can understand, or simple text. + + The name will be numbered to allow for ordering of steps. + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# efb5f4cc611c1eb8c9de82497bd906c59a237a2ba2cc2bccaa74209af288d5ff +# +# +# +# +# +# Document an event of data processing, reconstruction, or analysis for this data. +# +# +# +# Name of the program used +# +# +# +# +# Sequence index of processing, +# for determining the order of multiple **NXprocess** steps. +# Starts with 1. +# +# +# +# +# Version of the program used +# +# +# +# +# Date and time of processing. +# +# +# +# +# Describes the operations of image registration +# +# +# +# +# Describes the operations of image distortion correction +# +# +# +# +# Describes the operations of calibration procedures, e.g. axis calibrations. +# +# +# +# +# The note will contain information about how the data was processed +# or anything about the data provenance. +# The contents of the note can be anything that the processing code +# can understand, or simple text. +# +# The name will be numbered to allow for ordering of steps. +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# diff --git a/base_classes/nyaml/NXreflections.yaml b/base_classes/nyaml/NXreflections.yaml new file mode 100644 index 0000000000..83523acc75 --- /dev/null +++ b/base_classes/nyaml/NXreflections.yaml @@ -0,0 +1,1266 @@ +category: base +doc: | + Reflection data from diffraction experiments +symbols: + n: | + number of reflections + m: | + number of experiments +type: group +NXreflections(NXobject): + experiments: + exists: ['min', '1'] + doc: | + The experiments from which the reflection data derives + dimensions: + rank: 1 + dim: [[1, m]] + h(NX_NUMBER): + exists: ['min', '1'] + doc: | + The h component of the miller index + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + k(NX_NUMBER): + exists: ['min', '1'] + doc: | + The k component of the miller index + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + l(NX_NUMBER): + exists: ['min', '1'] + doc: | + The l component of the miller index + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + id(NX_INT): + exists: ['min', '1'] + doc: | + The id of the experiment which resulted in the reflection. If the value + is greater than 0, the experiments must link to a multi-experiment NXmx + group + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + reflection_id(NX_INT): + exists: ['min', '1'] + doc: | + The id of the reflection. Multiple partials from the same reflection + should all have the same id + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + entering(NX_BOOLEAN): + exists: ['min', '1'] + doc: | + Is the reflection entering or exiting the Ewald sphere + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + det_module(NX_INT): + exists: ['min', '1'] + doc: | + The detector module on which the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + flags(NX_INT): + exists: ['min', '1'] + doc: | + Status flags describing the reflection. + + This is a bit mask. The bits in the mask follow the convention + used by DIALS, and have the following names: + + === ========================================== + bit name + === ========================================== + 0 ``predicted`` + 1 ``observed`` + 2 ``indexed`` + 3 ``used_in_refinement`` + 4 ``strong`` + 5 ``reference_spot`` + 6 ``dont_integrate`` + 7 ``integrated_sum`` + 8 ``integrated_prf`` + 9 ``integrated`` + 10 ``overloaded`` + 11 ``overlapped`` + 12 ``overlapped_fg`` + 13 ``in_powder_ring`` + 14 ``foreground_includes_bad_pixels`` + 15 ``background_includes_bad_pixels`` + 16 ``includes_bad_pixels`` + 17 ``bad_shoebox`` + 18 ``bad_spot`` + 19 ``used_in_modelling`` + 20 ``centroid_outlier`` + 21 ``failed_during_background_modelling`` + 22 ``failed_during_summation`` + 23 ``failed_during_profile_fitting`` + 24 ``bad_reference`` + === ========================================== + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + d(NX_FLOAT): + exists: ['min', '1'] + doc: | + The resolution of the reflection + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + partiality(NX_FLOAT): + exists: ['min', '1'] + doc: | + The partiality of the reflection. + Dividing by this number will inflate the measured + intensity to the full reflection equivalent. + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + predicted_frame(NX_FLOAT): + unit: NX_UNITLESS + exists: ['min', '1'] + doc: | + The frame on which the bragg peak of the reflection is predicted + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + predicted_x(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '1'] + doc: | + The x position at which the bragg peak of the reflection + is predicted + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + predicted_y(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '1'] + doc: | + The y position at which the bragg peak of the reflection + is predicted + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + predicted_phi(NX_FLOAT): + unit: NX_ANGLE + exists: ['min', '1'] + doc: | + The phi angle at which the bragg peak of the reflection is predicted + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + predicted_px_x(NX_FLOAT): + unit: NX_UNITLESS + exists: ['min', '1'] + doc: | + The x pixel position at which the bragg peak of the reflection is + predicted + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + predicted_px_y(NX_FLOAT): + unit: NX_UNITLESS + exists: ['min', '1'] + doc: | + The y pixel position at which the bragg peak of the reflection is + predicted + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_frame(NX_FLOAT): + unit: NX_UNITLESS + exists: ['min', '1'] + doc: | + The estimate of the frame at which the central impact of the + reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_frame_var(NX_FLOAT): + unit: NX_UNITLESS + exists: ['min', '1'] + doc: | + The variance on the estimate of the frame at which the central + impact of the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_frame_errors(NX_FLOAT): + unit: NX_UNITLESS + exists: ['min', '1'] + doc: | + The standard deviation of the estimate of the frame at which the central + impact of the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_px_x(NX_FLOAT): + unit: NX_UNITLESS + exists: ['min', '1'] + doc: | + The estimate of the pixel x position at which the central impact of + the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_px_x_var(NX_FLOAT): + unit: NX_UNITLESS + exists: ['min', '1'] + doc: | + The variance on the estimate of the pixel x position at which the + central impact of the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_px_x_errors(NX_FLOAT): + unit: NX_UNITLESS + exists: ['min', '1'] + doc: | + The standard deviation of the estimate of the pixel x position at which the + central impact of the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_px_y(NX_FLOAT): + unit: NX_UNITLESS + exists: ['min', '1'] + doc: | + The estimate of the pixel y position at which the central impact of + the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_px_y_var(NX_FLOAT): + unit: NX_UNITLESS + exists: ['min', '1'] + doc: | + The variance on the estimate of the pixel y position at which the + central impact of the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_px_y_errors(NX_FLOAT): + unit: NX_UNITLESS + exists: ['min', '1'] + doc: | + The standard deviation of the estimate of the pixel y position at which the + central impact of the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_phi(NX_FLOAT): + unit: NX_ANGLE + exists: ['min', '1'] + doc: | + The estimate of the phi angle at which the central impact of the + reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_phi_var(NX_FLOAT): + unit: NX_ANGLE + exists: ['min', '1'] + doc: | + The variance on the estimate of the phi angle at which the central + impact of the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_phi_errors(NX_FLOAT): + unit: NX_ANGLE + exists: ['min', '1'] + doc: | + The standard deviation of the estimate of the phi angle at which the central + impact of the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_x(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '1'] + doc: | + The estimate of the x position at which the central + impact of the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_x_var(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '1'] + doc: | + The variance on the estimate of the x position at which + the central impact of the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_x_errors(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '1'] + doc: | + The standard deviation of the estimate of the x position at which + the central impact of the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_y(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '1'] + doc: | + The estimate of the y position at which the central + impact of the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_y_var(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '1'] + doc: | + The variance on the estimate of the y position at which + the central impact of the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + observed_y_errors(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '1'] + doc: | + The standard deviation of the estimate of the y position at which + the central impact of the reflection was recorded + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + bounding_box(NX_INT): + unit: NX_UNITLESS + exists: ['min', '1'] + doc: | + The bounding box around the recorded recorded reflection. + Should be an integer array of length 6, where the 6 values + are pixel positions or frame numbers, as follows: + + ===== =========================== + index meaning + ===== =========================== + 0 The lower pixel x position + 1 The upper pixel x position + 2 The lower pixel y position + 3 The upper pixel y position + 4 The lower frame number + 5 The upper frame number + ===== =========================== + dimensions: + rank: 2 + dim: [[1, n], [2, 6]] + \@description: + doc: | + Describes the dataset + background_mean(NX_FLOAT): + exists: ['min', '1'] + doc: | + The mean background under the reflection peak + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + int_prf(NX_FLOAT): + exists: ['min', '0'] + doc: | + The estimate of the reflection intensity by profile fitting + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + int_prf_var(NX_FLOAT): + exists: ['min', '0'] + doc: | + The variance on the estimate of the reflection intensity by profile + fitting + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + int_prf_errors(NX_FLOAT): + exists: ['min', '0'] + doc: | + The standard deviation of the estimate of the reflection intensity by profile + fitting + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + int_sum(NX_FLOAT): + exists: ['min', '1'] + doc: | + The estimate of the reflection intensity by summation + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + int_sum_var(NX_FLOAT): + exists: ['min', '1'] + doc: | + The variance on the estimate of the reflection intensity by + summation + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + int_sum_errors(NX_FLOAT): + exists: ['min', '1'] + doc: | + The standard deviation of the estimate of the reflection intensity by + summation + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + lp(NX_FLOAT): + exists: ['min', '1'] + doc: | + The LP correction factor to be applied to the reflection intensities + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + prf_cc(NX_FLOAT): + exists: ['min', '0'] + doc: | + The correlation of the reflection profile with the reference profile + used in profile fitting + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + overlaps(NX_INT): + exists: ['min', '0'] + doc: | + An adjacency list specifying the spatial overlaps of reflections. The + adjacency list is specified using an array data type where the elements + of the array are the indices of the adjacent overlapped reflection + \@description: + doc: | + Describes the dataset + polar_angle(NX_FLOAT): + unit: NX_ANGLE + exists: ['min', '0'] + doc: | + Polar angle of reflection centroid, following the NeXus simple (spherical polar) coordinate system + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + azimuthal_angle(NX_FLOAT): + unit: NX_ANGLE + exists: ['min', '0'] + doc: | + Azimuthal angle of reflection centroid, following the NeXus simple (spherical polar) coordinate system + dimensions: + rank: 1 + dim: [[1, n]] + \@description: + doc: | + Describes the dataset + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# f0dd5d59e2726272e3befd4fd88df46f824c4023d04a1a1775153f79260f5b7e +# +# +# +# +# +# number of reflections +# number of experiments +# +# Reflection data from diffraction experiments +# +# The experiments from which the reflection data derives +# +# +# +# +# +# +# The h component of the miller index +# +# +# +# +# Describes the dataset +# +# +# +# +# The k component of the miller index +# +# +# +# +# Describes the dataset +# +# +# +# +# The l component of the miller index +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The id of the experiment which resulted in the reflection. If the value +# is greater than 0, the experiments must link to a multi-experiment NXmx +# group +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The id of the reflection. Multiple partials from the same reflection +# should all have the same id +# +# +# +# +# +# Describes the dataset +# +# +# +# Is the reflection entering or exiting the Ewald sphere +# +# +# +# +# Describes the dataset +# +# +# +# +# The detector module on which the reflection was recorded +# +# +# +# +# Describes the dataset +# +# +# +# +# +# Status flags describing the reflection. +# +# This is a bit mask. The bits in the mask follow the convention +# used by DIALS, and have the following names: +# +# === ========================================== +# bit name +# === ========================================== +# 0 ``predicted`` +# 1 ``observed`` +# 2 ``indexed`` +# 3 ``used_in_refinement`` +# 4 ``strong`` +# 5 ``reference_spot`` +# 6 ``dont_integrate`` +# 7 ``integrated_sum`` +# 8 ``integrated_prf`` +# 9 ``integrated`` +# 10 ``overloaded`` +# 11 ``overlapped`` +# 12 ``overlapped_fg`` +# 13 ``in_powder_ring`` +# 14 ``foreground_includes_bad_pixels`` +# 15 ``background_includes_bad_pixels`` +# 16 ``includes_bad_pixels`` +# 17 ``bad_shoebox`` +# 18 ``bad_spot`` +# 19 ``used_in_modelling`` +# 20 ``centroid_outlier`` +# 21 ``failed_during_background_modelling`` +# 22 ``failed_during_summation`` +# 23 ``failed_during_profile_fitting`` +# 24 ``bad_reference`` +# === ========================================== +# +# +# +# +# +# Describes the dataset +# +# +# +# +# The resolution of the reflection +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The partiality of the reflection. +# Dividing by this number will inflate the measured +# intensity to the full reflection equivalent. +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The frame on which the bragg peak of the reflection is predicted +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The x position at which the bragg peak of the reflection +# is predicted +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The y position at which the bragg peak of the reflection +# is predicted +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The phi angle at which the bragg peak of the reflection is predicted +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The x pixel position at which the bragg peak of the reflection is +# predicted +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The y pixel position at which the bragg peak of the reflection is +# predicted +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The estimate of the frame at which the central impact of the +# reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The variance on the estimate of the frame at which the central +# impact of the reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The standard deviation of the estimate of the frame at which the central +# impact of the reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The estimate of the pixel x position at which the central impact of +# the reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The variance on the estimate of the pixel x position at which the +# central impact of the reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The standard deviation of the estimate of the pixel x position at which the +# central impact of the reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The estimate of the pixel y position at which the central impact of +# the reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The variance on the estimate of the pixel y position at which the +# central impact of the reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The standard deviation of the estimate of the pixel y position at which the +# central impact of the reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The estimate of the phi angle at which the central impact of the +# reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The variance on the estimate of the phi angle at which the central +# impact of the reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The standard deviation of the estimate of the phi angle at which the central +# impact of the reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The estimate of the x position at which the central +# impact of the reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The variance on the estimate of the x position at which +# the central impact of the reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The standard deviation of the estimate of the x position at which +# the central impact of the reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The estimate of the y position at which the central +# impact of the reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The variance on the estimate of the y position at which +# the central impact of the reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The standard deviation of the estimate of the y position at which +# the central impact of the reflection was recorded +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The bounding box around the recorded recorded reflection. +# Should be an integer array of length 6, where the 6 values +# are pixel positions or frame numbers, as follows: +# +# ===== =========================== +# index meaning +# ===== =========================== +# 0 The lower pixel x position +# 1 The upper pixel x position +# 2 The lower pixel y position +# 3 The upper pixel y position +# 4 The lower frame number +# 5 The upper frame number +# ===== =========================== +# +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The mean background under the reflection peak +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The estimate of the reflection intensity by profile fitting +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The variance on the estimate of the reflection intensity by profile +# fitting +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The standard deviation of the estimate of the reflection intensity by profile +# fitting +# +# +# +# +# +# Describes the dataset +# +# +# +# The estimate of the reflection intensity by summation +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The variance on the estimate of the reflection intensity by +# summation +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The standard deviation of the estimate of the reflection intensity by +# summation +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The LP correction factor to be applied to the reflection intensities +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# The correlation of the reflection profile with the reference profile +# used in profile fitting +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# An adjacency list specifying the spatial overlaps of reflections. The +# adjacency list is specified using an array data type where the elements +# of the array are the indices of the adjacent overlapped reflection +# +# +# Describes the dataset +# +# +# +# +# +# Polar angle of reflection centroid, following the NeXus simple (spherical polar) coordinate system +# +# +# +# +# +# Describes the dataset +# +# +# +# +# +# Azimuthal angle of reflection centroid, following the NeXus simple (spherical polar) coordinate system +# +# +# +# +# +# +# Describes the dataset +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# diff --git a/base_classes/nyaml/NXroot.yaml b/base_classes/nyaml/NXroot.yaml new file mode 100644 index 0000000000..bcecfaa0a8 --- /dev/null +++ b/base_classes/nyaml/NXroot.yaml @@ -0,0 +1,180 @@ +category: base +doc: | + Definition of the root NeXus group. +type: group +NXroot(NXobject): + \@NX_class: + doc: | + The root of any NeXus data file is an ``NXroot`` class + (no other choice is allowed for a valid NeXus data file). + This attribute cements that definition. + enumeration: [NXroot] + \@file_time: + type: NX_DATE_TIME + doc: | + Date and time file was originally created + \@file_name: + doc: | + File name of original NeXus file + \@file_update_time: + type: NX_DATE_TIME + doc: | + Date and time of last file change at close + \@NeXus_version: + doc: | + Version of NeXus API used in writing the file. + + Only used when the NAPI has written the file. + Note that this is different from the version of the + base class or application definition version number. + \@HDF_version: + doc: | + Version of HDF (version 4) library used in writing the file + \@HDF5_Version: + doc: | + Version of HDF5 library used in writing the file. + + Note this attribute is spelled with uppercase "V", + different than other version attributes. + \@XML_version: + doc: | + Version of XML support library used in writing the XML file + \@h5py_version: + doc: | + Version of h5py Python package used in writing the file + \@creator: + doc: | + facility or program where file originated + \@creator_version: + doc: | + Version of facility or program used in writing the file + (NXentry): + exists: ['min', '1'] + doc: | + entries + \@default: + doc: | + .. index:: find the default plottable data + .. index:: plotting + .. index:: default attribute value + + Declares which :ref:`NXentry` group contains + the data to be shown by default. + It is used to resolve ambiguity when + more than one :ref:`NXentry` group exists. + The value :ref:`names ` the default :ref:`NXentry` group. The + value must be the name of a child of the current group. The child must be a + NeXus group or a link to a NeXus group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 00ad60c31b3087963764958288477d30afe61c6888f025264db3cfb53f1068c1 +# +# +# +# +# Definition of the root NeXus group. +# +# +# The root of any NeXus data file is an ``NXroot`` class +# (no other choice is allowed for a valid NeXus data file). +# This attribute cements that definition. +# +# +# +# +# +# +# Date and time file was originally created +# +# +# File name of original NeXus file +# +# +# Date and time of last file change at close +# +# +# +# Version of NeXus API used in writing the file. +# +# Only used when the NAPI has written the file. +# Note that this is different from the version of the +# base class or application definition version number. +# +# +# +# Version of HDF (version 4) library used in writing the file +# +# +# +# Version of HDF5 library used in writing the file. +# +# Note this attribute is spelled with uppercase "V", +# different than other version attributes. +# +# +# +# Version of XML support library used in writing the XML file +# +# +# Version of h5py Python package used in writing the file +# +# +# facility or program where file originated +# +# +# Version of facility or program used in writing the file +# +# +# entries +# +# +# +# .. index:: find the default plottable data +# .. index:: plotting +# .. index:: default attribute value +# +# Declares which :ref:`NXentry` group contains +# the data to be shown by default. +# It is used to resolve ambiguity when +# more than one :ref:`NXentry` group exists. +# The value :ref:`names <validItemName>` the default :ref:`NXentry` group. The +# value must be the name of a child of the current group. The child must be a +# NeXus group or a link to a NeXus group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# diff --git a/base_classes/nyaml/NXsample.yaml b/base_classes/nyaml/NXsample.yaml new file mode 100644 index 0000000000..dd8c7a7890 --- /dev/null +++ b/base_classes/nyaml/NXsample.yaml @@ -0,0 +1,938 @@ +category: base +doc: | + 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. +symbols: + doc: | + symbolic array lengths to be coordinated between various fields + n_comp: | + number of compositions + n_Temp: | + number of temperatures + n_eField: | + number of values in applied electric field + n_mField: | + number of values in applied magnetic field + n_pField: | + number of values in applied pressure field + n_sField: | + number of values in applied stress field +type: group +NXsample(NXobject): + name: + doc: | + Descriptive name of sample + sample_id: + doc: | + Identification number or signatures of the sample used. + chemical_formula: + doc: | + 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. + temperature(NX_FLOAT): + unit: NX_TEMPERATURE + doc: | + Sample temperature. This could be a scanned variable + dimensions: + rank: anyRank + + # could be any length + dim: [[1, n_Temp]] + electric_field(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Applied electric field + dimensions: + + # could be any length + dim: [[1, n_eField]] + \@direction: + enumeration: [x, y, z] + magnetic_field(NX_FLOAT): + unit: NX_ANY + doc: | + Applied magnetic field + dimensions: + + # could be any length + dim: [[1, n_mField]] + \@direction: + enumeration: [x, y, z] + stress_field(NX_FLOAT): + unit: NX_ANY + doc: | + Applied external stress field + dimensions: + + # could be any length + dim: [[1, n_sField]] + \@direction: + enumeration: [x, y, z] + pressure(NX_FLOAT): + unit: NX_PRESSURE + doc: | + Applied pressure + dimensions: + + # could be any length + dim: [[1, n_pField]] + changer_position(NX_INT): + unit: NX_UNITLESS + doc: | + Sample changer position + unit_cell_abc(NX_FLOAT): + unit: NX_LENGTH + doc: | + Crystallography unit cell parameters a, b, and c + dimensions: + dim: [[1, 3]] + unit_cell_alphabetagamma(NX_FLOAT): + unit: NX_ANGLE + doc: | + Crystallography unit cell parameters alpha, beta, and gamma + dimensions: + dim: [[1, 3]] + unit_cell(NX_FLOAT): + unit: NX_LENGTH + doc: | + Unit cell parameters (lengths and angles) + dimensions: + rank: 2 + dim: [[1, n_comp], [2, 6]] + unit_cell_volume(NX_FLOAT): + unit: NX_VOLUME + doc: | + Volume of the unit cell + dimensions: + rank: 1 + dim: [[1, n_comp]] + sample_orientation(NX_FLOAT): + unit: NX_ANGLE + doc: | + This will follow the Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + dimensions: + rank: 1 + dim: [[1, 3]] + orientation_matrix(NX_FLOAT): + doc: | + Orientation matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + dimensions: + rank: 3 + dim: [[1, n_comp], [2, 3], [3, 3]] + ub_matrix(NX_FLOAT): + doc: | + UB matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is + the multiplication of the orientation_matrix, given above, + with the :math:`B` matrix which + can be derived from the lattice constants. + dimensions: + rank: 3 + dim: [[1, n_comp], [2, 3], [3, 3]] + mass(NX_FLOAT): + unit: NX_MASS + doc: | + Mass of sample + dimensions: + rank: 1 + dim: [[1, n_comp]] + density(NX_FLOAT): + unit: NX_MASS_DENSITY + doc: | + Density of sample + dimensions: + rank: 1 + dim: [[1, n_comp]] + relative_molecular_mass(NX_FLOAT): + unit: NX_MASS + doc: | + Relative Molecular Mass of sample + dimensions: + rank: 1 + dim: [[1, n_comp]] + type: + enumeration: [sample, sample+can, can, sample+buffer, buffer, calibration sample, normalisation sample, simulated data, none, sample environment] + situation: + doc: | + 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. + enumeration: [air, vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere, sealed can, other] + description: + doc: | + Description of the sample + preparation_date(NX_DATE_TIME): + doc: | + Date of preparation of the sample + geometry(NXgeometry): + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the sample and NXoff_geometry to describe its shape instead + doc: | + The position and orientation of the center of mass of the sample + (NXbeam): + doc: | + Details of beam incident on sample - used to calculate sample/beam interaction + point + (NXsample_component): + doc: | + One group per sample component + This is the perferred way of recording per component information over the n_comp arrays + component: + doc: | + Details of the component of the sample and/or can + dimensions: + rank: 1 + dim: [[1, n_comp]] + sample_component: + doc: | + Type of component + dimensions: + rank: 1 + dim: [[1, n_comp]] + enumeration: [sample, can, atmosphere, kit] + concentration(NX_FLOAT): + unit: NX_MASS_DENSITY + doc: | + Concentration of each component + dimensions: + rank: 1 + dim: [[1, n_comp]] + volume_fraction(NX_FLOAT): + doc: | + Volume fraction of each component + dimensions: + rank: 1 + dim: [[1, n_comp]] + scattering_length_density(NX_FLOAT): + unit: NX_SCATTERING_LENGTH_DENSITY + doc: | + Scattering length density of each component + dimensions: + rank: 1 + dim: [[1, n_comp]] + unit_cell_class: + doc: | + In case it is all we know and we want to record/document it + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + space_group: + doc: | + Crystallographic space group + dimensions: + dim: [[1, n_comp]] + point_group: + doc: | + Crystallographic point group, deprecated if space_group present + dimensions: + dim: [[1, n_comp]] + path_length(NX_FLOAT): + unit: NX_LENGTH + doc: | + Path length through sample/can for simple case when + it does not vary with scattering direction + path_length_window(NX_FLOAT): + unit: NX_LENGTH + doc: | + Thickness of a beam entry/exit window on the can (mm) + - assumed same for entry and exit + thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + sample thickness + transmission(NXdata): + doc: | + As a function of Wavelength + temperature_log(NXlog): + deprecated: | + use ``temperature``, see: https://github.com/nexusformat/definitions/issues/816 + doc: | + temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value + temperature_env(NXenvironment): + doc: | + Additional sample temperature environment information + magnetic_field(NXlog): + doc: | + magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value + magnetic_field_log(NXlog): + deprecated: | + use ``magnetic_field``, see: https://github.com/nexusformat/definitions/issues/816 + doc: | + magnetic_field_log.value is a link to e.g. + magnetic_field_env.sensor1.value_log.value + magnetic_field_env(NXenvironment): + doc: | + Additional sample magnetic environment information + external_DAC(NX_FLOAT): + unit: NX_ANY + doc: | + value sent to user's sample setup + external_ADC(NXlog): + doc: | + logged value (or logic state) read from user's setup + short_title: + doc: | + 20 character fixed length sample description for legends + + # How is the string length limitation imposed by the XSD? + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Optional rotation angle for the case when the powder diagram has + been obtained through an omega-2theta scan like from a traditional + single detector powder diffractometer. + Note, it is recommended to use NXtransformations instead. + x_translation(NX_FLOAT): + unit: NX_LENGTH + doc: | + Translation of the sample along the X-direction of the laboratory coordinate system + Note, it is recommended to use NXtransformations instead. + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + Translation of the sample along the Z-direction of the laboratory coordinate system. + Note, it is recommended to use NXtransformations instead. + (NXpositioner): + doc: | + Any positioner (motor, PZT, ...) used to locate the sample + (NXoff_geometry): + + # exists: ['min', '0'] + doc: | + This group describes the shape of the sample + (NXsingle_crystal): + doc: | + If the sample is a single crystal, add description of single crystal and unit + cell. + (NXsample_component_set): + doc: | + Set of sample components and their configuration. + There can only be one NXsample_component_set in one component. + + # exists: [max, 1] + (NXsubstance): + doc: | + If the sample is made from a pure substance and cannot be further divided using + NXsample_component. + + # exists: [max, 1] + (NXfabrication): + doc: | + Details about the sample vendor (company or research group) + (NXenvironment): + + # eventually, this should be stored in the application definitions + doc: | + Any environmental or external stimuli/measurements. + These can include, among others: + applied pressure, surrounding gas phase and gas pressure, + external electric/magnetic/mechanical fields, temperature, ... + (NXsample_history): + doc: | + A set of physical processes that occurred to the sample prior/during experiment. + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on: + doc: | + 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. + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 359e67b69525d94347bd6db9aa776e2c77b3e87b9a30b4d6a3e90ec29253c59c +# +# +# +# +# +# +# symbolic array lengths to be coordinated between various fields +# +# +# +# number of compositions +# +# +# +# +# number of temperatures +# +# +# +# +# number of values in applied electric field +# +# +# +# +# number of values in applied magnetic field +# +# +# +# +# number of values in applied pressure field +# +# +# +# +# number of values in applied stress field +# +# +# +# +# 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. +# +# +# +# Descriptive name of sample +# +# +# +# +# Identification number or signatures of the sample used. +# +# +# +# +# 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. +# +# +# +# +# Sample temperature. This could be a scanned variable +# +# +# +# +# +# +# +# +# Applied electric field +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Applied magnetic field +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Applied external stress field +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Applied pressure +# +# +# +# +# +# +# +# +# Sample changer position +# +# +# +# +# Crystallography unit cell parameters a, b, and c +# +# +# +# +# +# +# +# Crystallography unit cell parameters alpha, beta, and gamma +# +# +# +# +# +# +# +# Unit cell parameters (lengths and angles) +# +# +# +# +# +# +# +# +# Volume of the unit cell +# +# +# +# +# +# +# +# This will follow the Busing-Levy convention: +# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 +# +# +# +# +# +# +# +# Orientation matrix of single crystal sample using Busing-Levy convention: +# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 +# +# +# +# +# +# +# +# +# +# UB matrix of single crystal sample using Busing-Levy convention: +# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is +# the multiplication of the orientation_matrix, given above, +# with the :math:`B` matrix which +# can be derived from the lattice constants. +# +# +# +# +# +# +# +# +# +# Mass of sample +# +# +# +# +# +# +# +# Density of sample +# +# +# +# +# +# +# +# Relative Molecular Mass of sample +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# 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. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Description of the sample +# +# +# +# +# Date of preparation of the sample +# +# +# +# +# The position and orientation of the center of mass of the sample +# +# +# +# +# Details of beam incident on sample - used to calculate sample/beam interaction +# point +# +# +# +# +# One group per sample component +# This is the perferred way of recording per component information over the n_comp arrays +# +# +# +# +# Details of the component of the sample and/or can +# +# +# +# +# +# +# +# Type of component +# +# +# +# +# +# +# +# +# +# +# +# +# +# Concentration of each component +# +# +# +# +# +# +# +# Volume fraction of each component +# +# +# +# +# +# +# +# Scattering length density of each component +# +# +# +# +# +# +# +# In case it is all we know and we want to record/document it +# +# +# +# +# +# +# +# +# +# +# +# +# +# Crystallographic space group +# +# +# +# +# +# +# +# Crystallographic point group, deprecated if space_group present +# +# +# +# +# +# +# +# Path length through sample/can for simple case when +# it does not vary with scattering direction +# +# +# +# +# Thickness of a beam entry/exit window on the can (mm) +# - assumed same for entry and exit +# +# +# +# +# sample thickness +# +# +# +# +# As a function of Wavelength +# +# +# +# +# temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value +# +# +# +# +# Additional sample temperature environment information +# +# +# +# +# magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value +# +# +# +# +# magnetic_field_log.value is a link to e.g. +# magnetic_field_env.sensor1.value_log.value +# +# +# +# +# Additional sample magnetic environment information +# +# +# +# +# value sent to user's sample setup +# +# +# +# +# logged value (or logic state) read from user's setup +# +# +# +# +# 20 character fixed length sample description for legends +# +# +# +# +# +# Optional rotation angle for the case when the powder diagram has +# been obtained through an omega-2theta scan like from a traditional +# single detector powder diffractometer. +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# Translation of the sample along the X-direction of the laboratory coordinate system +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# Translation of the sample along the Z-direction of the laboratory coordinate system. +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# Any positioner (motor, PZT, ...) used to locate the sample +# +# +# +# +# +# This group describes the shape of the sample +# +# +# +# +# If the sample is a single crystal, add description of single crystal and unit +# cell. +# +# +# +# +# Set of sample components and their configuration. +# There can only be one NXsample_component_set in one component. +# +# +# +# +# +# If the sample is made from a pure substance and cannot be further divided using +# NXsample_component. +# +# +# +# +# +# Details about the sample vendor (company or research group) +# +# +# +# +# +# Any environmental or external stimuli/measurements. +# These can include, among others: +# applied pressure, surrounding gas phase and gas pressure, +# external electric/magnetic/mechanical fields, temperature, ... +# +# +# +# +# A set of physical processes that occurred to the sample prior/during experiment. +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# diff --git a/base_classes/nyaml/NXsample_component.yaml b/base_classes/nyaml/NXsample_component.yaml new file mode 100644 index 0000000000..15dc89ad20 --- /dev/null +++ b/base_classes/nyaml/NXsample_component.yaml @@ -0,0 +1,392 @@ +category: base +doc: | + One group like this per component can be recorded For a sample consisting of + multiple components. +symbols: + doc: | + symbolic array lengths to be coordinated between various fields + n_Temp: | + number of temperatures + n_eField: | + number of values in applied electric field + n_mField: | + number of values in applied magnetic field + n_pField: | + number of values in applied pressure field + n_sField: | + number of values in applied stress field +type: group +NXsample_component(NXobject): + name: + doc: | + Descriptive name of sample component + sample_id: + doc: | + Identification number or signatures of the sample component used. + chemical_formula: + doc: | + 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. + unit_cell_abc(NX_FLOAT): + unit: NX_LENGTH + doc: | + Crystallography unit cell parameters a, b, and c + dimensions: + dim: [[1, 3]] + unit_cell_alphabetagamma(NX_FLOAT): + unit: NX_ANGLE + doc: | + Crystallography unit cell parameters alpha, beta, and gamma + dimensions: + dim: [[1, 3]] + unit_cell_volume(NX_FLOAT): + unit: NX_VOLUME + doc: | + Volume of the unit cell + sample_orientation(NX_FLOAT): + unit: NX_ANGLE + doc: | + This will follow the Busing and Levy convention from Acta.Crysta v22, p457 + (1967) + dimensions: + rank: 1 + dim: [[1, 3]] + orientation_matrix(NX_FLOAT): + doc: | + Orientation matrix of single crystal sample component. + This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) + dimensions: + rank: 2 + dim: [[1, 3], [2, 3]] + mass(NX_FLOAT): + unit: NX_MASS + doc: | + Mass of sample component + density(NX_FLOAT): + unit: NX_MASS_DENSITY + doc: | + Density of sample component + relative_molecular_mass(NX_FLOAT): + unit: NX_MASS + doc: | + Relative Molecular Mass of sample component + description: + doc: | + Description of the sample component + volume_fraction(NX_FLOAT): + doc: | + Volume fraction of component + scattering_length_density(NX_FLOAT): + unit: NX_SCATTERING_LENGTH_DENSITY + doc: | + Scattering length density of component + unit_cell_class: + doc: | + In case it is all we know and we want to record/document it + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + space_group: + doc: | + Crystallographic space group + point_group: + doc: | + Crystallographic point group, deprecated if space_group present + transmission(NXdata): + doc: | + As a function of Wavelength + (NXsingle_crystal): + doc: | + If the component is a single crystal, add description of single crystal and unit + cell. + (NXsample_component_set): + doc: | + Set of sub-components and their configuration. + There can only be one NXsample_component_set in one component. + + # exists: [max, 1] + (NXsubstance): + doc: | + If the component is made from a pure substance and cannot be further divided + using NXsample_component. + + # exists: [max, 1] + (NXfabrication): + doc: | + Details about the sample component vendor (company or research group) + (NXsample_history): + doc: | + A set of physical processes that occurred to the sample component prior/during + experiment. + depends_on: + doc: | + Any NXsample_component depends on the instance of NXsample_component_set, at the same level of + description granularity where the component is located. + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 07c4e31c308138182eef1cdddefda26ba6c879da8df45c3f0b03213996fc8fcb +# +# +# +# +# +# +# symbolic array lengths to be coordinated between various fields +# +# +# +# number of temperatures +# +# +# +# +# number of values in applied electric field +# +# +# +# +# number of values in applied magnetic field +# +# +# +# +# number of values in applied pressure field +# +# +# +# +# number of values in applied stress field +# +# +# +# +# One group like this per component can be recorded For a sample consisting of +# multiple components. +# +# +# +# Descriptive name of sample component +# +# +# +# +# Identification number or signatures of the sample component used. +# +# +# +# +# The chemical formula specified using CIF conventions. +# 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. +# +# +# +# +# Crystallography unit cell parameters a, b, and c +# +# +# +# +# +# +# +# Crystallography unit cell parameters alpha, beta, and gamma +# +# +# +# +# +# +# +# Volume of the unit cell +# +# +# +# +# This will follow the Busing and Levy convention from Acta.Crysta v22, p457 +# (1967) +# +# +# +# +# +# +# +# Orientation matrix of single crystal sample component. +# This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) +# +# +# +# +# +# +# +# +# Mass of sample component +# +# +# +# +# Density of sample component +# +# +# +# +# Relative Molecular Mass of sample component +# +# +# +# +# Description of the sample component +# +# +# +# +# Volume fraction of component +# +# +# +# +# Scattering length density of component +# +# +# +# +# In case it is all we know and we want to record/document it +# +# +# +# +# +# +# +# +# +# +# +# +# +# Crystallographic space group +# +# +# +# +# Crystallographic point group, deprecated if space_group present +# +# +# +# +# As a function of Wavelength +# +# +# +# +# If the component is a single crystal, add description of single crystal and unit +# cell. +# +# +# +# +# Set of sub-components and their configuration. +# There can only be one NXsample_component_set in one component. +# +# +# +# +# +# If the component is made from a pure substance and cannot be further divided +# using NXsample_component. +# +# +# +# +# +# Details about the sample component vendor (company or research group) +# +# +# +# +# A set of physical processes that occurred to the sample component prior/during +# experiment. +# +# +# +# +# Any NXsample_component depends on the instance of NXsample_component_set, at the same level of +# description granularity where the component is located. +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# diff --git a/base_classes/nyaml/NXsensor.yaml b/base_classes/nyaml/NXsensor.yaml new file mode 100644 index 0000000000..eeb3c54fe7 --- /dev/null +++ b/base_classes/nyaml/NXsensor.yaml @@ -0,0 +1,323 @@ +category: base +doc: | + A sensor used to monitor an external condition + + The condition itself is described in :ref:`NXenvironment`. +type: group +NXsensor(NXobject): + model: + doc: | + Sensor identification code/model number + name: + doc: | + Name for the sensor + short_name: + doc: | + Short name of sensor used e.g. on monitor display program + attached_to: + doc: | + where sensor is attached to ("sample" | "can") + geometry(NXgeometry): + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the beamstop and NXoff_geometry to describe its shape instead + doc: | + Defines the axes for logged vector quantities if they are not the global instrument axes. + measurement: + doc: | + name for measured signal + enumeration: [temperature, pH, magnetic_field, electric_field, conductivity, resistance, voltage, pressure, flow, stress, strain, shear, surface_pressure] + type: + doc: | + The type of hardware used for the measurement. + Examples (suggestions but not restrictions): + + :Temperature: + J | K | T | E | R | S | Pt100 | Rh/Fe + :pH: + Hg/Hg2Cl2 | Ag/AgCl | ISFET + :Ion selective electrode: + specify species; e.g. Ca2+ + :Magnetic field: + Hall + :Surface pressure: + wilhelmy plate + run_control(NX_BOOLEAN): + doc: | + Is data collection controlled or synchronised to this quantity: + 1=no, 0=to "value", 1=to "value_deriv1", etc. + high_trip_value(NX_FLOAT): + unit: NX_ANY + doc: | + Upper control bound of sensor reading if using run_control + low_trip_value(NX_FLOAT): + unit: NX_ANY + doc: | + Lower control bound of sensor reading if using run_control + value(NX_FLOAT): + unit: NX_ANY + doc: | + nominal setpoint or average value + - need [n] as may be a vector + dimensions: + dim: [[1, n]] + value_deriv1(NX_FLOAT): + unit: NX_ANY + doc: | + Nominal/average first derivative of value + e.g. strain rate + - same dimensions as "value" (may be a vector) + dimensions: + dim: [[1, ]] + dim_parameters: + ref: ['value'] + value_deriv2(NX_FLOAT): + unit: NX_ANY + doc: | + Nominal/average second derivative of value + - same dimensions as "value" (may be a vector) + dimensions: + dim: [[1, ]] + dim_parameters: + ref: ['value'] + value_log(NXlog): + doc: | + Time history of sensor readings + value_deriv1_log(NXlog): + doc: | + Time history of first derivative of sensor readings + value_deriv2_log(NXlog): + doc: | + Time history of second derivative of sensor readings + external_field_brief: + enumeration: [along beam, across beam, transverse, solenoidal, flow shear gradient, flow vorticity] + external_field_full(NXorientation): + doc: | + For complex external fields not satisfied by External_field_brief + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the sensor when necessary. + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a sensor. + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# df8bc397cbcbf114091b84ed357f6312641ca9abbf2d51795c37802450e7e628 +# +# +# +# +# +# A sensor used to monitor an external condition +# +# The condition itself is described in :ref:`NXenvironment`. +# +# +# Sensor identification code/model number +# +# +# Name for the sensor +# +# +# Short name of sensor used e.g. on monitor display program +# +# +# where sensor is attached to ("sample" | "can") +# +# +# +# Defines the axes for logged vector quantities if they are not the global instrument axes. +# +# +# +# name for measured signal +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The type of hardware used for the measurement. +# Examples (suggestions but not restrictions): +# +# :Temperature: +# J | K | T | E | R | S | Pt100 | Rh/Fe +# :pH: +# Hg/Hg2Cl2 | Ag/AgCl | ISFET +# :Ion selective electrode: +# specify species; e.g. Ca2+ +# :Magnetic field: +# Hall +# :Surface pressure: +# wilhelmy plate +# +# +# +# +# Is data collection controlled or synchronised to this quantity: +# 1=no, 0=to "value", 1=to "value_deriv1", etc. +# +# +# +# +# Upper control bound of sensor reading if using run_control +# +# +# +# +# Lower control bound of sensor reading if using run_control +# +# +# +# +# nominal setpoint or average value +# - need [n] as may be a vector +# +# +# +# +# +# +# +# Nominal/average first derivative of value +# e.g. strain rate +# - same dimensions as "value" (may be a vector) +# +# +# +# +# +# +# +# Nominal/average second derivative of value +# - same dimensions as "value" (may be a vector) +# +# +# +# +# +# +# Time history of sensor readings +# +# +# Time history of first derivative of sensor readings +# +# +# Time history of second derivative of sensor readings +# +# +# +# +# +# +# +# +# +# +# +# +# For complex external fields not satisfied by External_field_brief +# +# +# +# This group describes the shape of the sensor when necessary. +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a sensor. +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# diff --git a/base_classes/nyaml/NXshape.yaml b/base_classes/nyaml/NXshape.yaml new file mode 100644 index 0000000000..f5222b30de --- /dev/null +++ b/base_classes/nyaml/NXshape.yaml @@ -0,0 +1,143 @@ +category: base +doc: | + legacy class - (used by :ref:`NXgeometry`) - the shape and size of a component. + + This is the description of the general shape and size of a + component, which may be made up of ``numobj`` separate + elements - it is used by the :ref:`NXgeometry` class +type: group +NXshape(NXobject): + shape: + doc: | + general shape of a component + enumeration: [nxflat, nxcylinder, nxbox, nxsphere, nxcone, nxelliptical, nxtoroidal, nxparabolic, nxpolynomial] + size(NX_FLOAT): + unit: NX_LENGTH + doc: | + physical extent of the object along its local axes (after NXorientation) + with the center of mass at the local origin (after NXtranslation). + The meaning and location of these axes will vary according to the value + of the "shape" variable. + ``nshapepar`` defines how many parameters: + + - For "nxcylinder" type the parameters are (diameter,height) and a three value orientation vector of the cylinder. + - For the "nxbox" type the parameters are (length,width,height). + - For the "nxsphere" type the parameters are (diameter). + - For nxcone cone half aperture + - For nxelliptical, semi-major axis, semi-minor-axis, angle of major axis and pole + - For nxtoroidal, major radius, minor radius + - For nxparabolic, parabolic parameter a + - For nxpolynomial, an array of polynom coefficients, the dimension of the array + encodes the degree of the polynom + dimensions: + dim: [[1, numobj], [2, nshapepar]] + direction: + enumeration: [concave, convex] + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# c273b2f18be61f791d2fc4da9ecefbb880d180a9f83536ad161f2f685127f209 +# +# +# +# +# +# legacy class - (used by :ref:`NXgeometry`) - the shape and size of a component. +# +# This is the description of the general shape and size of a +# component, which may be made up of ``numobj`` separate +# elements - it is used by the :ref:`NXgeometry` class +# +# +# general shape of a component +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# physical extent of the object along its local axes (after NXorientation) +# with the center of mass at the local origin (after NXtranslation). +# The meaning and location of these axes will vary according to the value +# of the "shape" variable. +# ``nshapepar`` defines how many parameters: +# +# - For "nxcylinder" type the parameters are (diameter,height) and a three value orientation vector of the cylinder. +# - For the "nxbox" type the parameters are (length,width,height). +# - For the "nxsphere" type the parameters are (diameter). +# - For nxcone cone half aperture +# - For nxelliptical, semi-major axis, semi-minor-axis, angle of major axis and pole +# - For nxtoroidal, major radius, minor radius +# - For nxparabolic, parabolic parameter a +# - For nxpolynomial, an array of polynom coefficients, the dimension of the array +# encodes the degree of the polynom +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# diff --git a/base_classes/nyaml/NXslit.yaml b/base_classes/nyaml/NXslit.yaml new file mode 100644 index 0000000000..364a1c539c --- /dev/null +++ b/base_classes/nyaml/NXslit.yaml @@ -0,0 +1,141 @@ +category: base +doc: | + A simple slit. + + For more complex geometries, :ref:`NXaperture` should be used. +type: group +NXslit(NXobject): + depends_on(NX_CHAR): + doc: | + Points to the path of the last element in the geometry chain that places + this object in space. + When followed through that chain is supposed to end at an element depending + on "." i.e. the origin of the coordinate system. + If desired the location of the slit can also be described relative to + an NXbeam, which will allow a simple description of a non-centred slit. + + The reference plane of the slit is orthogonal to the z axis and includes the + surface that is the entry surface of the slit. The reference point of the slit + is the centre of the slit opening in the x and y axis on the reference plane. + The reference point on the z axis is the reference plane. + + .. image:: slit/slit.png + :width: 40% + x_gap(NX_NUMBER): + unit: NX_LENGTH + doc: | + Size of the gap opening in the first dimension of the local + coordinate system. + y_gap(NX_NUMBER): + unit: NX_LENGTH + doc: | + Size of the gap opening in the second dimension of the local + coordinate system. + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 417ccad73271f355d1d59bfad75b0a0622636749a18b54e8d6f71ec54a968203 +# +# +# +# +# +# A simple slit. +# +# For more complex geometries, :ref:`NXaperture` should be used. +# +# +# +# Points to the path of the last element in the geometry chain that places +# this object in space. +# When followed through that chain is supposed to end at an element depending +# on "." i.e. the origin of the coordinate system. +# If desired the location of the slit can also be described relative to +# an NXbeam, which will allow a simple description of a non-centred slit. +# +# The reference plane of the slit is orthogonal to the z axis and includes the +# surface that is the entry surface of the slit. The reference point of the slit +# is the centre of the slit opening in the x and y axis on the reference plane. +# The reference point on the z axis is the reference plane. +# +# .. image:: slit/slit.png +# :width: 40% +# +# +# +# +# +# Size of the gap opening in the first dimension of the local +# coordinate system. +# +# +# +# +# Size of the gap opening in the second dimension of the local +# coordinate system. +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# diff --git a/base_classes/nyaml/NXsource.yaml b/base_classes/nyaml/NXsource.yaml new file mode 100644 index 0000000000..9c4ec8e26d --- /dev/null +++ b/base_classes/nyaml/NXsource.yaml @@ -0,0 +1,520 @@ +category: base +doc: | + The neutron or x-ray storage ring/facility. +type: group +NXsource(NXobject): + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + Effective distance from sample + Distance as seen by radiation from sample. This number should be negative + to signify that it is upstream of the sample. + name: + doc: | + Name of source + \@short_name: + doc: | + short name for source, perhaps the acronym + type: + doc: | + type of radiation source (pick one from the enumerated list and spell exactly) + enumeration: [Spallation Neutron Source, Pulsed Reactor Neutron Source, Reactor Neutron Source, Synchrotron X-ray Source, Pulsed Muon Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, Ion Source, UV Plasma Source, Metal Jet X-ray] + probe: + doc: | + type of radiation probe (pick one from the enumerated list and spell exactly) + enumeration: [neutron, x-ray, muon, electron, ultraviolet, visible light, positron, proton] + power(NX_FLOAT): + unit: NX_POWER + doc: | + Source power + emittance_x(NX_FLOAT): + unit: NX_EMITTANCE + doc: | + Source emittance (nm-rad) in X (horizontal) direction. + emittance_y(NX_FLOAT): + unit: NX_EMITTANCE + doc: | + Source emittance (nm-rad) in Y (horizontal) direction. + sigma_x(NX_FLOAT): + unit: NX_LENGTH + doc: | + particle beam size in x + sigma_y(NX_FLOAT): + unit: NX_LENGTH + doc: | + particle beam size in y + flux(NX_FLOAT): + unit: NX_FLUX + doc: | + Source intensity/area (example: s-1 cm-2) + energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + Source energy. + For storage rings, this would be the particle beam energy. + For X-ray tubes, this would be the excitation voltage. + current(NX_FLOAT): + unit: NX_CURRENT + doc: | + Accelerator, X-ray tube, or storage ring current + voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Accelerator voltage + frequency(NX_FLOAT): + unit: NX_FREQUENCY + doc: | + Frequency of pulsed source + period(NX_FLOAT): + unit: NX_PERIOD + doc: | + Period of pulsed source + target_material: + doc: | + Pulsed source target material + enumeration: [Ta, W, depleted_U, enriched_U, Hg, Pb, C] + notes(NXnote): + doc: | + any source/facility related messages/events that + occurred during the experiment + bunch_pattern(NXdata): + doc: | + For storage rings, description of the bunch pattern. + This is useful to describe irregular bunch patterns. + title: + doc: | + name of the bunch pattern + number_of_bunches(NX_INT): + doc: | + For storage rings, the number of bunches in use. + bunch_length(NX_FLOAT): + unit: NX_TIME + doc: | + For storage rings, temporal length of the bunch + bunch_distance(NX_FLOAT): + unit: NX_TIME + doc: | + For storage rings, time between bunches + pulse_width(NX_FLOAT): + unit: NX_TIME + doc: | + temporal width of source pulse + + # pulsed sources or storage rings could use this + pulse_shape(NXdata): + doc: | + source pulse shape + + # pulsed sources or storage rings could use this + mode: + doc: | + source operating mode + enumeration: + Single Bunch: + doc: | + for storage rings + Multi Bunch: + doc: | + for storage rings + + # other sources could add to this + + # other sources could add to this + top_up(NX_BOOLEAN): + doc: | + Is the synchrotron operating in top_up mode? + last_fill(NX_NUMBER): + unit: NX_CURRENT + doc: | + For storage rings, the current at the end of the most recent injection. + \@time: + type: NX_DATE_TIME + doc: | + date and time of the most recent injection. + photon_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + The center photon energy of the source, before it is + monochromatized or converted + center_wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + The center wavelength of the source, before it is + monochromatized or converted + pulse_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + For pulsed sources, the energy of a single pulse + peak_power(NX_FLOAT): + unit: NX_POWER + doc: | + For pulsed sources, the pulse energy divided + by the pulse duration + bunch_number_start(NX_INT): + doc: | + Some facilities tag each bunch. + First bunch of the measurement + bunch_number_end(NX_INT): + doc: | + Last bunch of the measurement + geometry(NXgeometry): + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the source and NXoff_geometry to describe its shape instead + doc: | + "Engineering" location of source. + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the beam line component + (NXdata)distribution: + doc: | + The wavelength or energy distribution of the source + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the + z axis. + + .. image:: source/source.png + :width: 40% + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 19f1ee4e446868766ab035145a5835ce38e26b04d8e8ee50bf641392cb5c3525 +# +# +# +# +# +# The neutron or x-ray storage ring/facility. +# +# +# +# Effective distance from sample +# Distance as seen by radiation from sample. This number should be negative +# to signify that it is upstream of the sample. +# +# +# +# +# Name of source +# +# +# +# short name for source, perhaps the acronym +# +# +# +# +# +# type of radiation source (pick one from the enumerated list and spell exactly) +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# type of radiation probe (pick one from the enumerated list and spell exactly) +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Source power +# +# +# +# +# Source emittance (nm-rad) in X (horizontal) direction. +# +# +# +# +# Source emittance (nm-rad) in Y (horizontal) direction. +# +# +# +# +# particle beam size in x +# +# +# +# +# particle beam size in y +# +# +# +# +# Source intensity/area (example: s-1 cm-2) +# +# +# +# +# Source energy. +# For storage rings, this would be the particle beam energy. +# For X-ray tubes, this would be the excitation voltage. +# +# +# +# +# Accelerator, X-ray tube, or storage ring current +# +# +# +# +# Accelerator voltage +# +# +# +# +# Frequency of pulsed source +# +# +# +# +# Period of pulsed source +# +# +# +# +# Pulsed source target material +# +# +# +# +# +# +# +# +# +# +# +# +# +# any source/facility related messages/events that +# occurred during the experiment +# +# +# +# +# For storage rings, description of the bunch pattern. +# This is useful to describe irregular bunch patterns. +# +# +# +# name of the bunch pattern +# +# +# +# +# +# For storage rings, the number of bunches in use. +# +# +# +# +# For storage rings, temporal length of the bunch +# +# +# +# +# For storage rings, time between bunches +# +# +# +# +# temporal width of source pulse +# +# +# +# +# +# source pulse shape +# +# +# +# +# +# source operating mode +# +# +# +# +# for storage rings +# +# +# +# +# for storage rings +# +# +# +# +# +# +# +# +# Is the synchrotron operating in top_up mode? +# +# +# +# +# For storage rings, the current at the end of the most recent injection. +# +# +# +# date and time of the most recent injection. +# +# +# +# +# +# The center photon energy of the source, before it is +# monochromatized or converted +# +# +# +# +# The center wavelength of the source, before it is +# monochromatized or converted +# +# +# +# +# For pulsed sources, the energy of a single pulse +# +# +# +# +# For pulsed sources, the pulse energy divided +# by the pulse duration +# +# +# +# +# Some facilities tag each bunch. +# First bunch of the measurement +# +# +# +# +# Last bunch of the measurement +# +# +# +# +# "Engineering" location of source. +# +# +# +# +# This group describes the shape of the beam line component +# +# +# +# +# The wavelength or energy distribution of the source +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the +# z axis. +# +# .. image:: source/source.png +# :width: 40% +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# diff --git a/base_classes/nyaml/NXsubentry.yaml b/base_classes/nyaml/NXsubentry.yaml new file mode 100644 index 0000000000..248111e211 --- /dev/null +++ b/base_classes/nyaml/NXsubentry.yaml @@ -0,0 +1,344 @@ +category: base +doc: | + Group of multiple application definitions for "multi-modal" (e.g. SAXS/WAXS) measurements. + + ``NXsubentry`` is a base class virtually identical to :ref:`NXentry` + and is used as the (overlay) location for application definitions. + Use a separate ``NXsubentry`` for each application definition. + + To use ``NXsubentry`` with a hypothetical application definition + called ``NXmyappdef``: + + * Create a group with attribute ``NX_class="NXsubentry"`` + * Within that group, create a field called ``definition="NXmyappdef"``. + * There are two optional attributes of definition: ``version`` and ``URL`` + + The intended use is to define application definitions for a + multi-modal (a.k.a. multi-technique) :ref:`NXentry`. + Previously, an application definition + replaced :ref:`NXentry` with its own definition. + With the increasing popularity of instruments combining + multiple techniques for data collection (such as SAXS/WAXS instruments), + it was recognized the application definitions must be entered in the NeXus + data file tree as children of :ref:`NXentry`. +type: group +NXsubentry(NXobject): + \@default: + doc: | + .. 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 ` the default :ref:`NXentry` group. The + value must be the name of a child of the current group. The child must be a + NeXus group or a link to a NeXus group. + + For more information about how NeXus identifies the default + plottable data, see the + :ref:`Find Plottable Data, v3 ` + section. + \@IDF_Version: + + # as ratified at NIAC2010 + doc: | + ISIS Muon IDF_Version + title: + doc: | + Extended title for entry + experiment_identifier: + doc: | + Unique identifier for the experiment, defined by + the facility, possibly linked to the proposals + experiment_description: + doc: | + Brief summary of the experiment, including key objectives. + (NXnote)experiment_documentation: + doc: | + Description of the full experiment (document in pdf, latex, ...) + collection_identifier: + doc: | + User or Data Acquisition defined group of NeXus files or :ref:`NXentry` + collection_description: + doc: | + Brief summary of the collection, including grouping criteria. + entry_identifier: + doc: | + unique identifier for the measurement, defined by the facility. + definition: + doc: | + Official NeXus NXDL schema to which this subentry conforms + \@version: + doc: | + NXDL version number + \@URL: + doc: | + URL of NXDL file + definition_local: + doc: | + Local NXDL schema extended from the subentry + specified in the ``definition`` field. + This contains any locally-defined, + additional fields in the subentry. + \@version: + doc: | + NXDL version number + \@URL: + doc: | + URL of NXDL file + start_time(NX_DATE_TIME): + doc: | + Starting time of measurement + end_time(NX_DATE_TIME): + doc: | + Ending time of measurement + duration(NX_INT): + unit: NX_TIME + doc: | + Duration of measurement + collection_time(NX_FLOAT): + unit: NX_TIME + doc: | + Time transpired actually collecting data i.e. taking out time when collection was + suspended due to e.g. temperature out of range + run_cycle: + doc: | + Such as "2007-3". Some user facilities organize their beam time into run cycles. + program_name: + doc: | + Name of program used to generate this file + \@version: + doc: | + Program version number + \@configuration: + doc: | + configuration of the program + revision: + doc: | + Revision id of the file due to re-calibration, reprocessing, new analysis, new + instrument definition format, ... + \@comment: + pre_sample_flightpath(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the flightpath before the sample position. This can be determined by a chopper, + by the moderator or the source itself. In other words: it the distance to the component + which gives the T0 signal to the detector electronics. If another component in the + NXinstrument hierarchy provides this information, this should be a link. + notes(NXnote): + doc: | + Notes describing entry + thumbnail(NXnote): + doc: | + A small image that is representative of the entry. An example of this is a 640x480 + jpeg image automatically produced by a low resolution plot of the NXdata. + \@mime_type: + doc: | + The value should be an ``image/*`` + + # This is not perfect. + # How do we set a default value for the mime_type attribute? + enumeration: [image/*] + (NXuser): + (NXsample): + (NXinstrument): + (NXcollection): + (NXmonitor): + (NXdata): + (NXparameters): + (NXprocess): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 73d58acb9360e8891346fefd2018fc630e5216eb27617d7dc5aec05808025224 +# +# +# +# +# +# +# +# .. 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 <validItemName>` the default :ref:`NXentry` group. The +# value must be the name of a child of the current group. The child must be a +# NeXus group or a link to a NeXus group. +# +# For more information about how NeXus identifies the default +# plottable data, see the +# :ref:`Find Plottable Data, v3 <Find-Plottable-Data-v3>` +# section. +# +# +# +# +# Group of multiple application definitions for "multi-modal" (e.g. SAXS/WAXS) measurements. +# +# ``NXsubentry`` is a base class virtually identical to :ref:`NXentry` +# and is used as the (overlay) location for application definitions. +# Use a separate ``NXsubentry`` for each application definition. +# +# To use ``NXsubentry`` with a hypothetical application definition +# called ``NXmyappdef``: +# +# * Create a group with attribute ``NX_class="NXsubentry"`` +# * Within that group, create a field called ``definition="NXmyappdef"``. +# * There are two optional attributes of definition: ``version`` and ``URL`` +# +# The intended use is to define application definitions for a +# multi-modal (a.k.a. multi-technique) :ref:`NXentry`. +# Previously, an application definition +# replaced :ref:`NXentry` with its own definition. +# With the increasing popularity of instruments combining +# multiple techniques for data collection (such as SAXS/WAXS instruments), +# it was recognized the application definitions must be entered in the NeXus +# data file tree as children of :ref:`NXentry`. +# +# +# +# +# ISIS Muon IDF_Version +# +# +# +# Extended title for entry +# +# +# +# Unique identifier for the experiment, defined by +# the facility, possibly linked to the proposals +# +# +# +# Brief summary of the experiment, including key objectives. +# +# +# Description of the full experiment (document in pdf, latex, ...) +# +# +# User or Data Acquisition defined group of NeXus files or :ref:`NXentry` +# +# +# Brief summary of the collection, including grouping criteria. +# +# +# unique identifier for the measurement, defined by the facility. +# +# +# Official NeXus NXDL schema to which this subentry conforms +# NXDL version number +# URL of NXDL file +# +# +# +# Local NXDL schema extended from the subentry +# specified in the ``definition`` field. +# This contains any locally-defined, +# additional fields in the subentry. +# +# NXDL version number +# URL of NXDL file +# +# +# Starting time of measurement +# +# +# Ending time of measurement +# +# +# Duration of measurement +# +# +# +# Time transpired actually collecting data i.e. taking out time when collection was +# suspended due to e.g. temperature out of range +# +# +# +# Such as "2007-3". Some user facilities organize their beam time into run cycles. +# +# +# Name of program used to generate this file +# Program version number +# configuration of the program +# +# +# +# Revision id of the file due to re-calibration, reprocessing, new analysis, new +# instrument definition format, ... +# +# +# +# +# +# This is the flightpath before the sample position. This can be determined by a chopper, +# by the moderator or the source itself. In other words: it the distance to the component +# which gives the T0 signal to the detector electronics. If another component in the +# NXinstrument hierarchy provides this information, this should be a link. +# +# +# +# Notes describing entry +# +# +# +# A small image that is representative of the entry. An example of this is a 640x480 +# jpeg image automatically produced by a low resolution plot of the NXdata. +# +# +# The value should be an ``image/*`` +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/base_classes/nyaml/NXtransformations.yaml b/base_classes/nyaml/NXtransformations.yaml new file mode 100644 index 0000000000..0a5efe9061 --- /dev/null +++ b/base_classes/nyaml/NXtransformations.yaml @@ -0,0 +1,406 @@ +category: base +doc: | + 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. +type: group +ignoreExtraGroups: true +ignoreExtraFields: true +ignoreExtraAttributes: true +NXtransformations(NXobject): + AXISNAME(NX_NUMBER): + nameType: any + unit: NX_TRANSFORMATION + exists: ['max', 'unbounded'] + doc: | + 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``. + \@transformation_type: + exists: optional + doc: | + 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. + + # + enumeration: [translation, rotation] + \@vector: + exists: optional + type: NX_NUMBER + doc: | + 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. + dimensions: + rank: 1 + dim: [[1, 3]] + \@offset: + type: NX_NUMBER + doc: | + 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. + dimensions: + rank: 1 + dim: [[1, 3]] + \@offset_units: + type: NX_CHAR + doc: | + Units of the offset. Values should be consistent with NX_LENGTH. + \@depends_on: + type: NX_CHAR + doc: | + Points to the path to a field defining the axis on which this + depends or the string ".". + \@equipment_component: + type: NX_CHAR + doc: | + An arbitrary identifier of a component of the equipment to which + the transformation belongs, such as 'detector_arm' or 'detector_module'. + NXtransformations with the same equipment_component label form a logical + grouping which can be combined together into a single change-of-basis + operation. + AXISNAME_end(NX_NUMBER): + unit: NX_TRANSFORMATION + nameType: any + exists: ['min', '0'] + doc: | + ``AXISNAME_end`` is a placeholder for a name constructed from the actual + name of an axis to which ``_end`` has been appended. + + The values in this field are the end points of the motions that start + at the corresponding positions given in the ``AXISNAME`` field. + AXISNAME_increment_set(NX_NUMBER): + unit: NX_TRANSFORMATION + nameType: any + exists: ['min', '0'] + doc: | + ``AXISNAME_increment_set`` is a placeholder for a name constructed from the actual + name of an axis to which ``_increment_set`` has been appended. + + The value of this optional field is the intended average range through which + the corresponding axis moves during the exposure of a frame. Ideally, the + value of this field added to each value of ``AXISNAME`` would agree with the + corresponding values of ``AXISNAME_end``, but there is a possibility of significant + differences. Use of ``AXISNAME_end`` is recommended. + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# f47cb808914aa3b75fb05b4c97d8f4ff4c1c08478e44a502c50e2ca5b50682c3 +# +# +# +# +# +# +# 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. +# +# +# +# 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``. +# +# +# +# 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. +# +# +# +# +# +# +# +# +# +# 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. +# +# +# +# +# +# +# +# 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. +# +# +# +# +# +# +# +# Units of the offset. Values should be consistent with NX_LENGTH. +# +# +# +# +# Points to the path to a field defining the axis on which this +# depends or the string ".". +# +# +# +# +# An arbitrary identifier of a component of the equipment to which +# the transformation belongs, such as 'detector_arm' or 'detector_module'. +# NXtransformations with the same equipment_component label form a logical +# grouping which can be combined together into a single change-of-basis +# operation. +# +# +# +# +# +# ``AXISNAME_end`` is a placeholder for a name constructed from the actual +# name of an axis to which ``_end`` has been appended. +# +# The values in this field are the end points of the motions that start +# at the corresponding positions given in the ``AXISNAME`` field. +# +# +# +# +# ``AXISNAME_increment_set`` is a placeholder for a name constructed from the actual +# name of an axis to which ``_increment_set`` has been appended. +# +# The value of this optional field is the intended average range through which +# the corresponding axis moves during the exposure of a frame. Ideally, the +# value of this field added to each value of ``AXISNAME`` would agree with the +# corresponding values of ``AXISNAME_end``, but there is a possibility of significant +# differences. Use of ``AXISNAME_end`` is recommended. +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# diff --git a/base_classes/nyaml/NXtranslation.yaml b/base_classes/nyaml/NXtranslation.yaml new file mode 100644 index 0000000000..99b08fc4fe --- /dev/null +++ b/base_classes/nyaml/NXtranslation.yaml @@ -0,0 +1,102 @@ +category: base +doc: | + legacy class - (used by :ref:`NXgeometry`) - general spatial location of a component. +type: group +NXtranslation(NXobject): + geometry(NXgeometry): + doc: | + Link to other object if we are relative, else absent + distances(NX_FLOAT): + unit: NX_LENGTH + doc: | + (x,y,z) + This field describes the lateral movement of a component. + The pair of groups NXtranslation and NXorientation together + describe the position of a component. + For absolute position, the origin is the scattering center (where a perfectly + aligned sample would be) with the z-axis pointing downstream and the y-axis + pointing gravitationally up. For a relative position the NXtranslation is + taken into account before the NXorientation. The axes are right-handed and + orthonormal. + dimensions: + dim: [[1, numobj], [2, 3]] + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 3d64610ba1f1776cf277b5aca7e63bf3e504ed9a3f558bf28241565df29d6cc1 +# +# +# +# +# +# legacy class - (used by :ref:`NXgeometry`) - general spatial location of a component. +# +# +# Link to other object if we are relative, else absent +# +# +# +# (x,y,z) +# This field describes the lateral movement of a component. +# The pair of groups NXtranslation and NXorientation together +# describe the position of a component. +# For absolute position, the origin is the scattering center (where a perfectly +# aligned sample would be) with the z-axis pointing downstream and the y-axis +# pointing gravitationally up. For a relative position the NXtranslation is +# taken into account before the NXorientation. The axes are right-handed and +# orthonormal. +# +# +# +# +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# diff --git a/base_classes/nyaml/NXuser.yaml b/base_classes/nyaml/NXuser.yaml new file mode 100644 index 0000000000..383a8e9d17 --- /dev/null +++ b/base_classes/nyaml/NXuser.yaml @@ -0,0 +1,145 @@ +category: base +doc: | + 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. +type: group +NXuser(NXobject): + name: + doc: | + Name of user responsible for this entry + role: + doc: | + Role of user responsible for this entry. + Suggested roles are "local_contact", + "principal_investigator", and "proposer" + affiliation: + doc: | + Affiliation of user + address: + doc: | + Address of user + telephone_number: + doc: | + Telephone number of user + fax_number: + doc: | + Fax number of user + email: + doc: | + Email of user + facility_user_id: + doc: | + facility based unique identifier for this person + e.g. their identification code on the facility + address/contact database + ORCID: + doc: | + an author code, Open Researcher and Contributor ID, + defined by https://orcid.org and expressed as a URI + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 095127b2420c5cc3523306d64ff34d05b413ff6c5aa8b3fcb470cba610d93e6a +# +# +# +# +# +# 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. +# +# +# Name of user responsible for this entry +# +# +# +# Role of user responsible for this entry. +# Suggested roles are "local_contact", +# "principal_investigator", and "proposer" +# +# +# +# Affiliation of user +# +# +# Address of user +# +# +# Telephone number of user +# +# +# Fax number of user +# +# +# Email of user +# +# +# +# facility based unique identifier for this person +# e.g. their identification code on the facility +# address/contact database +# +# +# +# +# an author code, Open Researcher and Contributor ID, +# defined by https://orcid.org and expressed as a URI +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# diff --git a/base_classes/nyaml/NXvelocity_selector.yaml b/base_classes/nyaml/NXvelocity_selector.yaml new file mode 100644 index 0000000000..fdfa162b96 --- /dev/null +++ b/base_classes/nyaml/NXvelocity_selector.yaml @@ -0,0 +1,198 @@ +category: base +doc: | + A neutron velocity selector +type: group +NXvelocity_selector(NXobject): + type: + doc: | + velocity selector type + rotation_speed(NX_FLOAT): + unit: NX_FREQUENCY + doc: | + velocity selector rotation speed + radius(NX_FLOAT): + unit: NX_LENGTH + doc: | + radius at beam centre + spwidth(NX_FLOAT): + unit: NX_LENGTH + doc: | + spoke width at beam centre + length(NX_FLOAT): + unit: NX_LENGTH + doc: | + rotor length + num(NX_INT): + unit: NX_UNITLESS + doc: | + number of spokes/lamella + twist(NX_FLOAT): + unit: NX_ANGLE + doc: | + twist angle along axis + table(NX_FLOAT): + unit: NX_ANGLE + doc: | + offset vertical angle + height(NX_FLOAT): + unit: NX_LENGTH + doc: | + input beam height + width(NX_FLOAT): + unit: NX_LENGTH + doc: | + input beam width + wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + wavelength + wavelength_spread(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + deviation FWHM /Wavelength + (NXgeometry)geometry: + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the velocity selector and NXoff_geometry to describe its shape instead + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the beam line component + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a velocity selector. + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 61472a40691792e17964faecd4c6ebba73b460c2519fe2b0a97f7d46e51d6c08 +# +# +# +# +# A neutron velocity selector +# +# velocity selector type +# +# +# velocity selector rotation speed +# +# +# radius at beam centre +# +# +# spoke width at beam centre +# +# +# rotor length +# +# +# number of spokes/lamella +# +# +# twist angle along axis +# +# +# offset vertical angle +# +# +# input beam height +# +# +# input beam width +# +# +# wavelength +# +# +# deviation FWHM /Wavelength +# +# +# +# +# This group describes the shape of the beam line component +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a velocity selector. +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# diff --git a/base_classes/nyaml/NXxraylens.yaml b/base_classes/nyaml/NXxraylens.yaml new file mode 100644 index 0000000000..f08f4867fc --- /dev/null +++ b/base_classes/nyaml/NXxraylens.yaml @@ -0,0 +1,220 @@ +category: base +doc: | + An X-ray lens, typically at a synchrotron X-ray beam line. + + Based on information provided by Gerd Wellenreuther (DESY). +type: group +NXxraylens(NXobject): + lens_geometry(NX_CHAR): + doc: | + Geometry of the lens + enumeration: [paraboloid, spherical, elliptical, hyperbolical] + symmetric(NX_BOOLEAN): + doc: | + Is the device symmetric? + cylindrical(NX_BOOLEAN): + doc: | + Is the device cylindrical? + cylinder_orientation(NXnote): + doc: | + Orientation of the cylinder axis. + focus_type(NX_CHAR): + doc: | + The type of focus of the lens + enumeration: [line, point] + lens_thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + Thickness of the lens + lens_length(NX_FLOAT): + unit: NX_LENGTH + doc: | + Length of the lens + curvature(NX_FLOAT): + unit: NX_LENGTH + doc: | + Radius of the curvature as measured in the middle of the lens + aperture(NX_FLOAT): + unit: NX_LENGTH + doc: | + Diameter of the lens. + number_of_lenses(NX_INT): + doc: | + Number of lenses that make up the compound lens. + lens_material(NX_CHAR): + doc: | + Material used to make the lens. + gas(NX_CHAR): + doc: | + Gas used to fill the lens + gas_pressure(NX_FLOAT): + unit: NX_PRESSURE + doc: | + Gas pressure in the lens + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the beam line component + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a x-ray lens. + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 289923b77926b2d3ad18298238dbafdbb5bb6f038e6d25947224cd1e39a0c04d +# +# +# +# +# +# +# An X-ray lens, typically at a synchrotron X-ray beam line. +# +# Based on information provided by Gerd Wellenreuther (DESY). +# +# +# Geometry of the lens +# +# +# +# +# +# +# +# +# +# Is the device symmetric? +# +# +# +# +# Is the device cylindrical? +# +# +# +# +# Orientation of the cylinder axis. +# +# +# +# +# The type of focus of the lens +# +# +# +# +# +# +# +# Thickness of the lens +# +# +# Length of the lens +# +# +# Radius of the curvature as measured in the middle of the lens +# +# +# Diameter of the lens. +# +# +# Number of lenses that make up the compound lens. +# +# +# Material used to make the lens. +# +# +# Gas used to fill the lens +# +# +# Gas pressure in the lens +# +# +# +# This group describes the shape of the beam line component +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a x-ray lens. +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# diff --git a/common/favicon.ico b/common/favicon.ico index c8e69d204bec19a03aa349dc8512300568c042ed..20fba88d3ba20159775a13673ecd08e8befdba58 100644 GIT binary patch literal 15406 zcmeI3eSBR-na6Ke3QOIkxK(n2c~tl$C#3az}9mhSgA=ghh1p4@vI zYT+;L=QEi(GxNO6GtWHp%rlcrW>n@~nSJ-okdM!F?UBheWipxZq$n1b5;0?a>g>T}zGZIP-uZ(2+vZ~D0j)hfdt?LWW4VH}4!XU-&Ik69#-MwuX`A2ipie9=Cf}QqCDjK`BlWlDik)?)kMCTQgq_fP!d?x5^EKLD5_~Rj z-hlpU%Hx`@ocUhzhZ_pcHVY50b0+n)?I|4DLg$Q}@BExT^PqKjbMLHu^1j!>_n$~l zG!(q`D(8G}TK&)$_s#m#4mV>8oSSk5&!v1d?W;)38v|!5`Ivm*E+*dr&HG7e+W~(! zsSO^E4(r_q_`X6sG!;Alj`C5Ydq_oSJ`dj8GK<>Y)kcEf+o^vRxeQUhD?iY6Wc@(b zc){vN+c^094EgU!KP9~c{LNvjX}`50a9_yz?# z-qR3xche5f-jW92U8-`v;N3B4u;Xvwzd`c@AIpIGUbfizb;@_phxu!tOg<)G^gad7 z*C=Z~pJ%)(pE#+n`>%4v8Fj$l$oEokofq*xHaFn3Q}+jwnLqMXS#*W`AkrFWy&BG+ z_xpU{oI%}KJ3fOW@UEk7D`_Hq|Cjue^+R3bk3dd2zvFoLxi5sLkMI0A3EQ%$ZEyOo z%N4s1Yeg^fgI!G;AN@l8^_^eCcZ2ktej4N2wEnjCw6coBU%uGYDt>{#jC`)j=<`(D zp6qMuk~zFy0L*z4dS~sWMERS!0r$(vKD(#;p2Fh8t4ck7hEnIs!1c}FrIC0l|#x2sRC*!2&)N~abaW4kTlLF@UR zTwlio@`Pz6h0#2EQsz1#?@c&_HD^Jo- z)IXQ&>paXNqJFaWA=_S&e!+Qz`5$U<-O&~;=L@-*cN~)~tRL=b!mrvSDjsLhtGO(B~QEu3NS)gWfdy-oN6jv zL^Re@p36LG|9gdTT|)kp+SsqJ1;@RD(SAW)8^uvt1NlPNIec$St}XE1uSETWf>#3f zL-nk6;fR0mBORmtW!tYp{vvf_#d{1#fj#)s;FN!0?L{SPKBuLK9a&B*KcD9O)(wznQT_j%cOzDJXc&dN_o;dnCVcTUrO zL;cgqHt;SM-|%smku~xt`61{bK8t9g+n=!GqiziI_BHtes#70ydNugJr|%T~qI@3J z>(_kEtbJIQ*H|86`o7aAdx+m;=omkVJwMY{Zd*ev;a}s+$UiH|^A&h_j_=oP9ed#^ zNf?!L16}g7>>O?t41Bz5>%^1%;51zNoBpSfHdwey`3UG+K9c$4%)zN?diFcodp@ae zXlgFLVfF&-Z2i3U55vE)2N6GCwQx~Bit%1(d8O~|28QzlbuZ$V#PiC$pOjo5QwGlb zpi*7`^g|7N;Qc~p0pZOqnEnCjy~?Ti-@$zUva!#p$6hyqU-l&)t7I)0?C){fH&s?& z`u&o%{zl`%?gK>=nEjJ*aoK0C(H)&}1gjr7XOcF@eW1rT{*KY-m^SU37~`}MN_5-z z!#)jCAMYs^hw#DUYf8vlw#?u$bnsRA9%Jz+&kh>Dy_Wr9f9)>YUnec%Y@oUEOLi-! ziH@4HY`E6PYCPEe1<>7J^zwrpACd2F$_2N;9A6aixQTLX4=DdP^*Yyy|F1JQeS*=M zB;P;dP?f1a2sxk+W^WyB>8ee?NsHR{)HzAzx~sb04^AJL*Q@M*=c*ramd!d*W#lJ$ z*?HJx+O_}d?814&&Sid}qbaF>>SurS9S!eaK~}Qk23IBe@b=iS{nwmnE7G?-JrB-v zTeY{<_~nAGQ|TAmnhNw+Vn>cmqhM_x2b|r*lH)h@@l9llPENz6zoB;~{RE@_FIoD` z+Xl{u($ABy>j3tP4%N$tK-OKrtrcGM?DWVlG2_vErRgQV4_z?*uYrA% z#JSkLP`YgWi@K}Mc(=jHzCpVgXUhN8zGu!Ibyv*}`-bO(arB=joTSG|Wos%)KlHIp zykvd4-&AxG-MA&f6Uwx7{xIKaLoPo{```7Kx9>~aQ=$Hc@qr}WbeXq&ZY1}Z zwEt~*sI)f-z8X%8dn7qHt{{od6ReSqCHXtgP-pfm^lbh}aJ|_+*oLXr*5Vf)D;Y~C zw5LOREV}kjA#ct$#kSro{+;!guA`F+u`^{cjwGDs9v=GZ2D;v#tbeCmT>^40W%S!g zyCY5lnu@<>&KKE1?^x{9rOZ)P8(@KrP8HnC8y2`nC4EiX{&wa~^G&R^2v3`%z3H@S zdzkpL_L=pvMg7s+`DvTB|3K8m*C0#^2X@N&80_yB?MO;q(vS zr`>1z%clC?jk2L{C(mhG@X|(7+*S6EIC$q5u}R-xT)ondBiXxT`>+9XkathikG|eU z*`_qUxBFW>=Kc8mtTAjAkMMhS%zwfCNyN8li`o}P^YT`*Jj(ckwJ6|oz|Xl6f8yVy zD*VUo^gFB8S}`Pd>=+i0sKttHYyDNv9`bLoDFgWd_o8Za>MlLw-SBZSX_)W6bN-zz zxuSbswK<5^`sLuBS5G`9ipN?OYv#ntTA;rcSjlS(`{qY00w5pSC!+7)A%8ULKN9&r zjL###{NQTyi+`z@s(el1Tf-fJiSbqBBURZl7rPSrbm4ploC6oRW2xglXhvPCyL=!M z&tS|2lA&2e{+g#qp2Pihol|sPk-rFhBDUhJ);^P_TkAXW_rviAu41qFSkAge-}#P( zlkJrM(=zuQ6C0sk^KlHc@4`;{cKuRUr0({n1!2rg@YF?jWA1+@@C{J^fX0qJR$Nl@ z`;+3^w$Dg&?JMwiQ)Jh}c>rG-|Gp#t|Npd36wkBw6V#10@s@C2MmG$(lXV6VZN({b z#L}^y0rGf;ac;3ZK~Mb0v?y>0x?K9FG{{J31+y)NqOEJze{tJeG+RR!15A^#% zt^Ks&2d+JHC?;v}?u>tU_*td6a;37c} zM)_H5yIB)Q(8t`d*fCV$Uvl`0WSCe}W5gS%tL|ywB+kJds_!n#4|KN5cM&hL(X{38 z6aGthO&x!zQ#@n^NpVmkQ~0^wydMbtx^2{NWer{@+X(N92U*!aix0Gd`Pdla3!F=! ze;+Wj2B>DBq_WbJf&E4S@$vZ>QqrcuEoC@zF#FH3b;I2ZJC#CHQ zILDy_*MoDIPc@uBPwV9FIEC*)%zaVRS24n0vDdWgEk;sCD)UxH_9>j(VX}9&p-aoq z!TaDx^H^z4US#}E8n4bkzg* zbgydkB#ilXy7n%X^<1dTm-7PSo~?a{_Jc^gIdRJDj)jBHMdF|DvDm6JwZ_bN(5nbu zzIkYK1Kz$6L$>^;;~`ozjQM=}6dQ+1@oJqDS^J-({xRnDVRCa$ufV_FfGkSB)v>Y# zhIdZh&&lI63}wm5@E_gbt)p%Y^Zn`iq0+gsexP0J`bXgYQriAl{C3RIncUa_=_aw! zQ-BlQ$ObSkp}jdfn%`J2n7h@;CcfJ%!_7w{J_&f9AjL4?TEh3)jN?3VY^oX4X4dZw z(Eew>jjZICinlb*YTv*~UN@54v#q7ceX+~E1ZlWlKPVlnhEwwb&h@}qT*|jaxY#Gk zeJ$FaXMD1s2Uo*ct)6w)1wPH^>!c*TTIF5gzdAnM7ZtpRO?qv`sdOn66(FCm|W z@qZWoACJdC+y*`Q346jd%=y~5J{;q&@c*E2;X7XkuH+j39Wwluxu*%w!K3Uxnr7L4 z%TH0vpZ)qITPHupj6-h>!h88gwC>H?@QIt2&yDs_-emdjJmjdoil5LN3Yk#!AK=UfSv9PieJm=LT(1BY7n+J{y4TrqAya{gxxE0nQvNVtl+) zk^QqaL;j3>X<&Pq56#85?K-qD$y~f@&*m=rBeq_)O*R1@?f`y!t@ERNUd@GIqxj=> z@OY(UsXFZPzkoxsv18RcZ5b+B$qenUjB z2LCUkW6Ov;9#;*qbd%V?Z{aJ}p$htA<*yuD=&Zw^K7FKmV`=LS7k=1#%FdtV@xw6w zhX1HDoYSpyg@I=s8ULMJYYIN%w|9Eq(-?SPpl&(yyS*0wj8$_#Py4LpYovMjKNN8s z;dRFH7`R?d$zS`&9OE-bcMbFzL*E|izaQUY2i~RFVe>xS(3fwhxBBKSR`{ku_0js( zxmUD8y$#$a&AaT8GETo}54jZ_b}rZC2D>Nd9R+&zd5ennIF_QgC;D*;d>fyXywd%V zIkP9@vB|gw|J#7hy3N>{DeO&;TKdT2dTSFb?OHkZ^GMcj_--nkL-~{ye|i%Fos&sF zMSfc>%_{sO56;1XbFJv%c%Q4tNTM?GLr;c>hiZ*o=lO=B-mq|9 zFU^&qS)KoAPKmp*W^}eN=febfQ&=;mx2TNu&GBF0|4Y!5U8TFb;Nbfx=GeTg(iqU2>q&Z3 zUABH%PuwZFH`{SiUe7uk@txf6;x~!MtX=sRQQQEY*2>puS#-|c*wi}3JR(~*S!)$L zcnJL4_z8DIPH)vUoFw!XmEmQ7e3btom#x-&;xCiO{&kwH&Tfpchxw9i+eUfui0>xS z$acfG_SVM!>555RjP1V{nVUDYwNPgVXMTt=ugDd;&ewZe>)+Lad8h3i3A|Mj_CpTjW~qLaK8*s8ocGv#AI%lIxHcM((Bu4-6?YYN~Pf zkQu6R_mFCsW|GSoHRMc8OBYH>UN?+TULP-(G9)Z|#{6?BsEGM@DC|oWT|F z78i*?aZUe|g%HY8yAVR`LJ74GBdomvgM$%+qY#47+$NI&J^{bVJZw)k98~E}42aS!5G&MER+}un{OUs|G zuuX64z+ZR3?yocdkHnEmvu^sw1S&lBP&doMDUZ@V5J?|U!q0yUpLKG zpr6EQmKKarJz<#a726f2s)?HB7RAf34IiwAsJhfuE4935);$ diff --git a/contributed_definitions/nyaml/NXaberration.yaml b/contributed_definitions/nyaml/NXaberration.yaml new file mode 100644 index 0000000000..ca5f8ab089 --- /dev/null +++ b/contributed_definitions/nyaml/NXaberration.yaml @@ -0,0 +1,86 @@ +category: base +doc: | + Quantified aberration coefficient in an aberration_model. +type: group +(NXobject)NXaberration: + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + unit: NX_LENGTH + doc: | + Confidence + uncertainty_model: + doc: | + How was the uncertainty quantified e.g. via the 95% confidence interval. + delta_time(NX_FLOAT): + unit: NX_TIME + doc: | + Time elapsed since the last measurement. + angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + For the CEOS definitions the C aberrations are radial-symmetric and have no + angle entry, while the A, B, D, S, or R aberrations are n-fold + symmetric and have an angle entry. + For the NION definitions the coordinate system differs to the one + used in CEOS and instead two aberration coefficients a and b are used. + name: + alias: + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 6166fdd811cd965e72eeecaebb7569e0e8fd19f0eff00f27f9db73ac3c6fe17c +# +# +# +# +# +# Quantified aberration coefficient in an aberration_model. +# +# +# +# +# Confidence +# +# +# +# +# How was the uncertainty quantified e.g. via the 95% confidence interval. +# +# +# +# +# Time elapsed since the last measurement. +# +# +# +# +# For the CEOS definitions the C aberrations are radial-symmetric and have no +# angle entry, while the A, B, D, S, or R aberrations are n-fold +# symmetric and have an angle entry. +# For the NION definitions the coordinate system differs to the one +# used in CEOS and instead two aberration coefficients a and b are used. +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXaberration_model.yaml b/contributed_definitions/nyaml/NXaberration_model.yaml new file mode 100644 index 0000000000..ec37d9fdb8 --- /dev/null +++ b/contributed_definitions/nyaml/NXaberration_model.yaml @@ -0,0 +1,173 @@ +category: base +doc: | + Models for aberrations of electro-magnetic lenses in electron microscopy. + + See `S. J. Pennycock and P. D. Nellist `_ (page 44ff, and page 118ff) + for different definitions available and further details. Table 7-2 of Ibid. + publication (page 305ff) documents how to convert from the NION to the + CEOS definitions. +type: group +(NXobject)NXaberration_model: + model: + enumeration: [ceos, nion] + (NXaberration): + c_1_0(NX_FLOAT): + unit: NX_LENGTH + doc: | + Defocus + c_1_2_a(NX_FLOAT): + unit: NX_LENGTH + doc: | + Two-fold astigmatism + c_1_2_b(NX_FLOAT): + unit: NX_LENGTH + doc: | + Two-fold astigmatism + c_2_1_a(NX_FLOAT): + unit: NX_LENGTH + doc: | + Second-order axial coma + c_2_1_b(NX_FLOAT): + unit: NX_LENGTH + doc: | + Second-order axial coma + c_2_3_a(NX_FLOAT): + unit: NX_LENGTH + doc: | + Threefold astigmatism + c_2_3_b(NX_FLOAT): + unit: NX_LENGTH + doc: | + Threefold astigmatism + c_3_0(NX_FLOAT): + unit: NX_LENGTH + doc: | + Spherical aberration + c_3_2_a(NX_FLOAT): + unit: NX_LENGTH + doc: | + Star aberration + c_3_2_b(NX_FLOAT): + unit: NX_LENGTH + doc: | + Star aberration + c_3_4_a(NX_FLOAT): + unit: NX_LENGTH + doc: | + Fourfold astigmatism + c_3_4_b(NX_FLOAT): + unit: NX_LENGTH + doc: | + Fourfold astigmatism + c_5_0(NX_FLOAT): + unit: NX_LENGTH + doc: | + Fifth-order spherical aberration + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 33b5274f5d8cccafbe9096d8604ecd849699dbf712b932df259eae3c981a99b4 +# +# +# +# +# +# Models for aberrations of electro-magnetic lenses in electron microscopy. +# +# See `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) +# for different definitions available and further details. Table 7-2 of Ibid. +# publication (page 305ff) documents how to convert from the NION to the +# CEOS definitions. +# +# +# +# +# +# +# +# +# +# +# Defocus +# +# +# +# +# Two-fold astigmatism +# +# +# +# +# Two-fold astigmatism +# +# +# +# +# Second-order axial coma +# +# +# +# +# Second-order axial coma +# +# +# +# +# Threefold astigmatism +# +# +# +# +# Threefold astigmatism +# +# +# +# +# Spherical aberration +# +# +# +# +# Star aberration +# +# +# +# +# Star aberration +# +# +# +# +# Fourfold astigmatism +# +# +# +# +# Fourfold astigmatism +# +# +# +# +# Fifth-order spherical aberration +# +# +# diff --git a/contributed_definitions/nyaml/NXaberration_model_ceos.yaml b/contributed_definitions/nyaml/NXaberration_model_ceos.yaml new file mode 100644 index 0000000000..0226b7268e --- /dev/null +++ b/contributed_definitions/nyaml/NXaberration_model_ceos.yaml @@ -0,0 +1,164 @@ +category: base +doc: | + CEOS definitions/model for aberrations of electro-magnetic lenses. + + See `S. J. Pennycock and P. D. Nellist `_ (page 44ff, and page 118ff) + for different definitions available and further details. Table 7-2 of Ibid. + publication (page 305ff) documents how to convert from the NION to the + CEOS definitions. +type: group +(NXobject)NXaberration_model_ceos: + model: + enumeration: [ceos] + c_1(NXaberration): + a_1(NXaberration): + b_2(NXaberration): + a_2(NXaberration): + c_3(NXaberration): + s_3(NXaberration): + a_3(NXaberration): + + # based on feedback from Thilo Remmele the following aberrations could be measured (enhanced mode, tilt angle > 30 mrad) but are not corrected + b_4(NXaberration): + d_4(NXaberration): + a_4(NXaberration): + c_5(NXaberration): + s_5(NXaberration): + r_5(NXaberration): + a_6(NXaberration): + + # further comments from Thilo Remmele (Leibniz-Institut für Kristallzüchtung) + # ThermoFisher uses CEOS correctors but makes customizations to these in their microscopes + # Aberration naming schema: C_order_multiplicity (similar to NXem, but with + # another coordinate system and in addition with a confidence entry. + # Aberrations with multiplicity 0 have no angle entry (C1,C3,C5,.., CEOS notation) + # contrast transferfuntion: ctf = e^(-i*Xi(g)) in Fourier space + # aberration function: + # Xi(g) = 2*pi/lamda{ 1/2 * (lamda*g)^2 (C20 + C22 cos[2(phi-phi_22)] + # +1/3 * (lamda*g)^3 (C31 cos[(phi-phi_31) + C33 cos[3(phi-phi_33) + # +1/4 * (lamda*g)^4 (C40 + C42 cos[2(phi-phi_42)] + C44 cos[4(phi-phi_42)] + # +1/f * (lamda*g)^f Sum (Cfm cos[m(phi-phi_fm)] where m=[0,2,..f] for even f and m=[1,3,..,f] for odd f + + # Thilo Remmele also mentions that there is a mapping of aberration coefficient names: + # C_2_0 -> C1 Defocus + # C_2_2 -> A1 2-fold astigmatism + # C_3_3 -> A2 3-fold astigmatism + # C_3_1 -> B2 axial coma + # C_4_0 -> C3 spherical aberration + # C_4_4 -> A3 4-fold astigmatism + # C_4_2 -> S3 star aberration + # C_5_5 -> A4 5-fold astigmatism + + # C_5_1 -> B4 axial coma + # C_5_3 -> D4 three lobe aberration + # C_6_0 -> C5 spherical aberration + # C_6_2 -> S5 star aberration + # C_6_4 -> R5 rosette aberration + # C_6_6 -> A5 6-fold astigmatism + + # In a session with HRTEM images the corrector is commonly aligned. + # The final measurement with the estimated residual aberrations + # should be saved in a corrector.html file (an example is appended + # at the end of this file. Unfortunately the datetime is not included + # in that html output, nor is the used outer tilt angle and exposure time. + # The datetime may be estimated from the file datetime and the Delta t entry, + # but caution if that datetime is not preserved on file transfers! + # More than one detector entry could occure but is not common. + # A seperate corrector schema, so it can be easily exchanged to other correctors if necessary. + # It might be useful to collect all the corrector entries in one table, for example to analyse the performance of the corrector. + # The corrector entry of the nexus em definition lacks the confidence information and the + # parameter settings for the estimation oft the aberrations. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# ebaf08cdad8e660f423345fc69cd868e7abef455184ce0ed4674b987345a7318 +# +# +# +# +# +# CEOS definitions/model for aberrations of electro-magnetic lenses. +# +# See `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) +# for different definitions available and further details. Table 7-2 of Ibid. +# publication (page 305ff) documents how to convert from the NION to the +# CEOS definitions. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXaberration_model_nion.yaml b/contributed_definitions/nyaml/NXaberration_model_nion.yaml new file mode 100644 index 0000000000..8afc7f6a9c --- /dev/null +++ b/contributed_definitions/nyaml/NXaberration_model_nion.yaml @@ -0,0 +1,103 @@ +category: base +doc: | + NION definitions/model for aberrations of electro-magnetic lenses. + + See `S. J. Pennycock and P. D. Nellist `_ (page 44ff, and page 118ff) + for different definitions available and further details. Table 7-2 of Ibid. + publication (page 305ff) documents how to convert from the NION to the + CEOS definitions. +type: group +(NXobject)NXaberration_model_nion: + model: + enumeration: [nion] + c_1_0(NXaberration): + c_1_2_a(NXaberration): + c_1_2_b(NXaberration): + c_2_1_a(NXaberration): + c_2_1_b(NXaberration): + c_2_3_a(NXaberration): + c_2_3_b(NXaberration): + c_3_0(NXaberration): + c_3_2_a(NXaberration): + c_3_2_b(NXaberration): + c_3_4_a(NXaberration): + c_3_4_b(NXaberration): + c_4_1_a(NXaberration): + c_4_1_b(NXaberration): + c_4_3_a(NXaberration): + c_4_3_b(NXaberration): + c_4_5_a(NXaberration): + c_4_5_b(NXaberration): + c_5_0(NXaberration): + c_5_2_a(NXaberration): + c_5_2_b(NXaberration): + c_5_4_a(NXaberration): + c_5_4_b(NXaberration): + c_5_6_a(NXaberration): + c_5_6_b(NXaberration): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 64006294c6d06a1d3736c1f67e7c2c4b72d055966858d441cef8a40261e4157e +# +# +# +# +# +# NION definitions/model for aberrations of electro-magnetic lenses. +# +# See `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) +# for different definitions available and further details. Table 7-2 of Ibid. +# publication (page 305ff) documents how to convert from the NION to the +# CEOS definitions. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXactivity.yaml b/contributed_definitions/nyaml/NXactivity.yaml new file mode 100644 index 0000000000..0c440d9562 --- /dev/null +++ b/contributed_definitions/nyaml/NXactivity.yaml @@ -0,0 +1,84 @@ +category: base +doc: | + A planned or unplanned action that has a temporal extension and for some time depends on some entity. + + This class is planned be used in the future as the super class for all other activities if inheritance + in base classes is supported in NeXus. +type: group +NXactivity(NXobject): + start_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code (with local time zone offset to UTC information + included) when this activity started. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code (with local time zone offset to UTC information + included) when this activity ended. + description: + doc: | + Short description of the activity. + notes(NXnote): + doc: | + This can be any data or other descriptor acquired during the activity + (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 95b47c73f55c34a19e14162abf2d4cc56bcd3002210e9929947cdd588076202e +# +# +# +# +# +# A planned or unplanned action that has a temporal extension and for some time depends on some entity. +# +# This class is planned be used in the future as the super class for all other activities if inheritance +# in base classes is supported in NeXus. +# +# +# +# ISO 8601 formatted time code (with local time zone offset to UTC information +# included) when this activity started. +# +# +# +# +# ISO 8601 formatted time code (with local time zone offset to UTC information +# included) when this activity ended. +# +# +# +# +# Short description of the activity. +# +# +# +# +# This can be any data or other descriptor acquired during the activity +# (NXnote allows to add pictures, audio, movies). Alternatively, a +# reference to the location or a unique identifier or other metadata file. In the +# case these are not available, free-text description. +# +# +# diff --git a/contributed_definitions/nyaml/NXadc.yaml b/contributed_definitions/nyaml/NXadc.yaml new file mode 100644 index 0000000000..d86bd8d566 --- /dev/null +++ b/contributed_definitions/nyaml/NXadc.yaml @@ -0,0 +1,53 @@ +category: base +doc: | + Analog-to-digital converter component/integrated circuit. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXadc(NXobject): + value(NX_NUMBER): + unit: NX_UNITLESS + doc: | + TBD. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 4804d0b6bf4c31429d0e602b482093871010cb40a4e62da03804396faa54d158 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Analog-to-digital converter component/integrated circuit. +# +# +# +# TBD. +# +# +# diff --git a/contributed_definitions/nyaml/NXamplifier.yaml b/contributed_definitions/nyaml/NXamplifier.yaml new file mode 100644 index 0000000000..2ec3b22a3b --- /dev/null +++ b/contributed_definitions/nyaml/NXamplifier.yaml @@ -0,0 +1,147 @@ +category: base +doc: | + Base classed definition for amplifier devices. +type: group +NXamplifier(NXobject): + hardware(NXfabrication): + doc: | + (IC, device) (NXmanufacturer?) + num_of_channels(NX_NUMBER): + doc: | + The number of preamplifier channels are assgined. + active_channels(NX_NUMBER): + doc: | + The number of preamplifier channels are ready tp to be used. (array for active + channels) + openloop_amplification(NX_NUMBER): + doc: | + The output signal does not go through a feedback loop to adjust the + amplification of the amplifier. (array for active channels) + + # amplification(NX_NUMBER): + # doc: !!! The ratio of the amplitude of the output signal to the amplitude of the input signal. (array for active channels) # From google. + signal_over_noise(NX_NUMBER): + doc: | + The ratio of the amplitue of the useful signal to the amplitude of the noise in + the output signal of the amplifier. S/N=V_signal/V_noise. (array for active + channels) + crosstalk_factor(NX_NUMBER): + doc: | + (if active >1) + crosstalk_compensation(NX_BOOLEAN): + doc: | + for reducing interferences between different signalling pathways + bandwidth(NX_NUMBER): + unit: NX_FREQUENCY + doc: | + The spectrum of frequency it can amplify, from its lowest to highest frequency + limits. + low_pass(NX_NUMBER): + unit: NX_FREQUENCY + doc: | + Order and cut-off frequency of the low-pass filter applied on the demodulated + signals (X,Y). Cut-off frq (low pass filter) (foreach DemodulatorChannels) + hi_pass(NX_NUMBER): + unit: NX_FREQUENCY + doc: | + Order and cut-off frequency of the high-pass filter applied on the demodulation + signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) + + # voltage_amplifier_factor(NX_NUMBER): + # doc: !!! Current Amplifier Factor typically refers to the gain of the probe current amplifier. (V/V) + # current_amplifier_capacitive_cross_talk_compensation(NX_CHAR): + # doc: !!! Reduces the effect of capacitive crosstalk in the circuit on experimental results. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 16ef5b7fc979cc0c049aa7a38d898c3a35b058f98046d7657a43e2cd3fac4c1f +# +# +# +# +# +# Base classed definition for amplifier devices. +# +# +# +# (IC, device) (NXmanufacturer?) +# +# +# +# +# The number of preamplifier channels are assgined. +# +# +# +# +# The number of preamplifier channels are ready tp to be used. (array for active +# channels) +# +# +# +# +# The output signal does not go through a feedback loop to adjust the +# amplification of the amplifier. (array for active channels) +# +# +# +# +# +# The ratio of the amplitue of the useful signal to the amplitude of the noise in +# the output signal of the amplifier. S/N=V_signal/V_noise. (array for active +# channels) +# +# +# +# +# (if active >1) +# +# +# +# +# for reducing interferences between different signalling pathways +# +# +# +# +# The spectrum of frequency it can amplify, from its lowest to highest frequency +# limits. +# +# +# +# +# Order and cut-off frequency of the low-pass filter applied on the demodulated +# signals (X,Y). Cut-off frq (low pass filter) (foreach DemodulatorChannels) +# +# +# +# +# Order and cut-off frequency of the high-pass filter applied on the demodulation +# signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) +# +# +# +# diff --git a/contributed_definitions/nyaml/NXaperture_em.yaml b/contributed_definitions/nyaml/NXaperture_em.yaml new file mode 100644 index 0000000000..6fef9f341f --- /dev/null +++ b/contributed_definitions/nyaml/NXaperture_em.yaml @@ -0,0 +1,92 @@ +category: base + +# extends: NXaperture +doc: | + Details of an individual aperture for beams in electron microscopy. +type: group +NXaperture_em(NXobject): + name: + doc: | + Given name/alias of the aperture. + value(NX_NUMBER): + unit: NX_ANY + doc: | + Relevant value from the control software. + + This is not always just the diameter of (not even in the case) + of a circular aperture. Usually it is a mode setting value which + is selected in the control software. + Which settings are behind the value should be defined + for now in the description field, if these are known + in more detail. + description: + doc: | + Ideally, a (globally) unique persistent identifier, link, or text to a + resource which gives further details. Alternatively a free-text field. + (NXfabrication): + (NXtransformations): + doc: | + Affine transformation which detail the arrangement in the + microscope relative to the optical axis and beam path. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 831a962f213703ac0899f1f42b75ec460081ef736918a7b73c1cf779af3da589 +# +# +# +# +# +# +# Details of an individual aperture for beams in electron microscopy. +# +# +# +# Given name/alias of the aperture. +# +# +# +# +# Relevant value from the control software. +# +# This is not always just the diameter of (not even in the case) +# of a circular aperture. Usually it is a mode setting value which +# is selected in the control software. +# Which settings are behind the value should be defined +# for now in the description field, if these are known +# in more detail. +# +# +# +# +# Ideally, a (globally) unique persistent identifier, link, or text to a +# resource which gives further details. Alternatively a free-text field. +# +# +# +# +# +# Affine transformation which detail the arrangement in the +# microscope relative to the optical axis and beam path. +# +# +# diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml new file mode 100644 index 0000000000..ef2a8c771b --- /dev/null +++ b/contributed_definitions/nyaml/NXapm.yaml @@ -0,0 +1,3303 @@ +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 +type: group +NXapm(NXobject): + (NXentry): + exists: ['min', '1', 'max', 'unbounded'] + \@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', 'unbounded'] + 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', 'unbounded'] + 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 + unit: NX_LENGTH + doc: | + Qualitative information about the grain size, here specifically + described as the equivalent spherical diameter of an assumed + average grain size for the crystal ensemble. + Users of this information should be aware that although the grain + diameter or radius is often referred to as grain size 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. + grain_diameter_error(NX_FLOAT): + exists: optional + unit: NX_LENGTH + doc: | + Magnitude of the standard deviation of the grain_diameter. + heat_treatment_temperature(NX_FLOAT): + exists: optional + unit: NX_TEMPERATURE + doc: | + The temperature of the last heat treatment step before quenching. + Knowledge about this value can give an idea how the sample + was heat treated, however if 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. + heat_treatment_temperature_error(NX_FLOAT): + exists: optional + unit: NX_TEMPERATURE + doc: | + Magnitude of the standard deviation of the heat_treatment_temperature. + heat_treatment_quenching_rate(NX_FLOAT): + exists: optional + unit: NX_ANY + doc: | + Rate of the last quenching step. + Knowledge about this value can give an idea how the 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. + heat_treatment_quenching_rate_error(NX_FLOAT): + exists: optional + unit: NX_ANY + doc: | + Magnitude of the standard deviation of the heat_treatment_quenching_rate. + description: + 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): + unit: NX_DIMENSIONLESS + 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. + composition_error(NX_FLOAT): + exists: optional + unit: NX_DIMENSIONLESS + doc: | + Magnitude of the standard deviation of the composition (value). + 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', 'unbounded'] + + # 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', 'unbounded'] + + # 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): + unit: NX_LENGTH + doc: | + The space inside the atom probe along which ions pass nominally + when they leave the specimen and travel to the detector. + + THIS DOCSTRING NEEDS CLARIFICATION. + + # 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 + unit: NX_LENGTH + 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. + (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 + (NXfabrication): + exists: optional + identifier: + exists: recommended + capabilities: + exists: optional + value(NX_NUMBER): + exists: recommended + (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 + unit: NX_CURRENT + doc: | + Amplitude of the signal detected on the multi-channel plate (MCP). + + This field should be used for storing the signal amplitude quantity + within ATO files. The ATO file format is used primarily by the + atom probe groups of the GPM in Rouen, France. + dimensions: + rank: 1 + dim: [[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 + (NXbeam): + exists: ['min', '0', 'max', 'unbounded'] + pinhole_position(NXcollection): + exists: recommended + spot_position(NXcollection): + 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): + unit: NX_TEMPERATURE + doc: | + Average temperature at the specimen base, i.e. + base_temperature during the measurement. + temperature(NX_FLOAT): + exists: optional + unit: NX_TEMPERATURE + 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). + 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): + unit: NX_PRESSURE + doc: | + Average pressure in the analysis chamber. + (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): + unit: NX_PRESSURE + doc: | + Average pressure in the buffer chamber. + (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): + unit: NX_PRESSURE + doc: | + Average pressure in the load_lock_chamber. + (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): + unit: NX_LENGTH + doc: | + Ideally measured or best elaborated guess of the + initial radius of the specimen. + shank_angle(NX_FLOAT): + unit: NX_ANGLE + 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. + detection_rate(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + Average detection rate over the course of the experiment. + + # 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 + unit: NX_ANY + doc: | + Estimated field at the apex along the evaporation sequence. + 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', 'unbounded'] + 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 + + # NEW ISSUE: check also here the PYCCAPT pipeline from P. Felfer's group + ion_impact_positions(NXprocess): + 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', 'unbounded'] + program: + \@version: + + # NEW ISSUE: discuss with Oxcart developers which + # modifications might be necessary here. + arrival_time_pairs(NX_NUMBER): + exists: recommended + unit: NX_TIME + doc: | + Raw readings from the analog-to-digital-converter + timing circuits of the detector wires. + dimensions: + rank: 3 + dim: [[1, n_ions], [2, n_dld_wires], [3, 2]] + hit_positions(NX_NUMBER): + unit: NX_LENGTH + 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. + 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 + + # NEW ISSUE: use symbols to monitor number of pulses + hit_multiplicity(NXprocess): + 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', 'unbounded'] + program: + \@version: + pulses_since_last_ion(NX_UINT): + exists: recommended + unit: NX_UNITLESS + 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]] + + # 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. + pulse_id(NX_UINT): + exists: optional + unit: NX_UNITLESS + doc: | + Number of pulses since the start of the atom probe + run/evaporation sequence. + dimensions: + rank: 1 + dim: [[1, n_ions]] + hit_multiplicity(NX_UINT): + unit: NX_UNITLESS + + # 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]] + 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', 'unbounded'] + program: + \@version: + evaporation_id_included(NX_BOOLEAN): + doc: | + Bitmask which is set to true if the ion + is considered and false otherwise. + dimensions: + rank: 1 + dim: [[1, n_ions]] + + # NEW ISSUE: add section for propagation_delay(NXprocess) ? + voltage_and_bowl_correction(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', 'unbounded'] + 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 + unit: NX_TIME + doc: | + Raw time-of-flight data as read out from the acquisition software + if these data are available and accessible. + dimensions: + rank: 1 + dim: [[1, n_ions]] + calibrated_tof(NX_FLOAT): + unit: NX_TIME + + # 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. + 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', 'unbounded'] + program: + \@version: + parameter(NXcollection): + exists: recommended + doc: | + Store vendor-specific calibration models here (if available). + mass_to_charge(NX_FLOAT): + unit: NX_ANY + doc: | + Mass-to-charge-state ratio values. + + # \@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', 'unbounded'] + 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): + unit: NX_LENGTH + doc: | + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + dimensions: + rank: 2 + dim: [[1, n_ions], [2, 3]] + visualization(NXprocess): + exists: recommended + xdmf_topology(NX_UINT): + unit: NX_UNITLESS + 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. + dimensions: + rank: 1 + dim: [[1, n_topology]] + + # n_topology == 3*n_ions + xdmf_topology(NX_UINT): + unit: NX_UNITLESS + 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. + 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', 'unbounded'] + 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): + unit: NX_UNITLESS + doc: | + Array of counts for each bin. + dimensions: + rank: 3 + dim: [[1, n_z], [2, n_y], [3, n_x]] + axis_z(NX_FLOAT): + unit: NX_LENGTH + doc: | + Bin center of mass position along the z axis. + dimensions: + rank: 1 + dim: [[1, n_z]] + \@long_name: + axis_y(NX_FLOAT): + unit: NX_LENGTH + doc: | + Bin center of mass position along the y axis. + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + axis_x(NX_FLOAT): + unit: NX_LENGTH + doc: | + Bin center of mass position along the x axis. + 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', 'unbounded'] + program: + \@version: + number_of_ion_types(NX_UINT): + unit: NX_UNITLESS + doc: | + How many ion types are distinguished. + If no ranging was performed each ion is of the special unknown type. + The iontype ID of this unknown type is 0 which is a reserve value. + Consequently, iontypes start counting from 1. + maximum_number_of_atoms_per_molecular_ion(NX_UINT): + unit: NX_UNITLESS + doc: | + Assumed maximum value that suffices to store all relevant + molecular ions, even the most complicated ones. + Currently a value of 32 is used. + 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', 'unbounded'] + program: + \@version: + range_minmax(NX_FLOAT): + unit: NX_ANY + doc: | + Smallest and largest mass-to-charge-state ratio value. + + # \@units: Da + # NEW ISSUE: NX_ATOMIC_MASS_UNIT use Tommasso scheme here Da + dimensions: + rank: 1 + dim: [[1, 2]] + range_increment(NX_FLOAT): + unit: NX_ANY + doc: | + Binning width of the mass-to-charge-state ratio values. + + # \@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): + unit: NX_UNITLESS + doc: | + Array of counts for each bin. + dimensions: + rank: 1 + dim: [[1, n_bins]] + \@long_name: + axis_mass_to_charge(NX_FLOAT): + unit: NX_ANY + doc: | + Right boundary of each mass-to-charge-state ratio value bin. + + # \@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', 'unbounded'] + 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', 'unbounded'] + program: + \@version: + (NXpeak): + exists: ['min', '0', 'max', 'unbounded'] + 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', 'unbounded'] + 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 + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 612ced9157105a0063ebb6500dcdb1852b6094678e7f79eda066ae6b4a8a08ed +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Total number of ions collected. +# +# +# +# +# Total number of independent wires in the delay-line detector. +# +# +# +# +# Number of support points for e.g. modeling peaks. +# +# +# +# +# Maximum number of allowed atoms per (molecular) ion (fragment). +# Needs to match maximum_number_of_atoms_per_molecular_ion. +# +# +# +# +# Number of mass-to-charge-state-ratio intervals of this ion type. +# +# +# +# +# Number of bins in the x direction. +# +# +# +# +# Number of bins in the y direction. +# +# +# +# +# Number of bins in the z direction. +# +# +# +# +# Number of bins. +# +# +# +# +# Total number of integers in the supplementary XDMF topology array. +# +# +# +# +# Application definition for atom probe and field ion microscopy experiments. +# +# This application definition provides a place to document data and metadata to +# an atom probe experiment. Primarily the measurement itself is documented. +# However, as most atom probe experiments are controlled with commercial software +# which does not allow to access the raw detector hits, this application definition +# also includes two key groups of processing steps (reconstruction and ranging). +# +# During tomographic reconstruction measured data are processed into a point cloud +# of reconstructed positions of certain ions. During ranging time-of-flight data +# are identified as representing specific ions to annotate each ion with a label. +# +# Commercial software used in atom probe research is designed as an integrated +# acquisition and instrument control software. For AMETEK/Cameca local electrode +# atom probe (LEAP) instruments the least processed (rawest) numerical results +# and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which +# are proprietary and their file format specifications not publicly documented. +# +# Supplementary metadata are kept in a database (formerly known as the ISDb) +# which is connected to the instrument control software and synced with the +# experiment while ions are detected. In effect, RHIT and HITS files +# store the (rawest) experiment data in a closed manner that is +# practically useless for users unless they have access to the +# commercial software. +# +# To arrive at a state that atom probe microscopy (APM) with LEAP instruments +# delivers a dataset with which users can study reconstructed atomic +# position and do e.g. composition analyses or other post-processing +# analysis tasks, these raw data have to be processed. Therefore, it is +# necessary that for an application definition to be useful, details about +# the physical acquisition of the raw data and all its +# processing steps have to be stored. +# +# With this a user can create derived quantities like ion hit positions +# (on the detector) and calibrated time-of-flight data. These derived +# quantities are also needed to obtain calibrated mass-to-charge-state +# ratios, and finally the tomographic reconstruction of the ion positions. +# +# In most cases, an APM dataset is useful only if it gets post-processed +# via so-called ranging. Ranging defines rules for mapping time-of-flight +# and mass-to-charge-state ratio values on ion species. This is post-processing +# even though in practice it is performed sometimes already (as preview) +# already while data are still being collected. +# +# The ion types decode molecular identities which can very often be +# mapped to elemental identities, and also be used to distinguish isotopes. +# All these steps are in most cases performed using commercial software. +# +# Frequently, though, ranging and post-processing is also performed with +# (open-source) research software. Therefore, there is strictly speaking +# not a single program used throughout an atom probe analysis not even +# for the early stage of data acquisition and processing stages to obtain +# a useful reconstructed and ranged dataset. +# +# This application definition documents not only the measurement but also the +# key post-processing steps which transform the proprietary data into a +# tomographic reconstruction with ranging definitions. +# +# Future guidance by the technology partners like AMETEK/Cameca could improve +# this description to cover a substantial larger number of eventually metadata +# that so far are neither publicly documented nor accessible. +# +# +# +# +# An at least as strong as SHA256 hashvalue of the file +# that specifies the application definition. +# +# +# +# +# +# NeXus NXDL schema to which this file conforms. +# +# +# +# +# +# +# +# Ideally, a (globally) unique persistent identifier +# for referring to this experiment. +# +# The identifier is usually defined/issued by the facility, laboratory, +# or the principle investigator. The identifier enables to link +# experiments to e.g. proposals. +# +# +# +# +# Free-text description about the experiment. +# +# Users are strongly advised to detail the sample history in the +# respective field and fill rather as completely as possible the fields +# of the application definition behind instead of filling in these +# details into the experiment_description free-text description field. +# +# Users are encouraged to add in this field eventual DOIs to papers +# which yield further details to the experiment. +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC information +# included when the microscope session started. +# If the application demands that time codes in this section of the +# application definition should only be used for specifying when the +# experiment was performed - and the exact duration is not relevant +# - this start_time field should be used. +# +# Often though it is useful to specify a time interval with specifying +# both start_time and end_time to allow for more detailed bookkeeping +# and interpretation of the experiment. The user should be aware that +# even with having both dates specified, it may not be possible +# to infer how long the experiment took or for how long data +# were collected. +# +# More detailed timing data over the course of the experiment have to be +# collected to compute this event chain during the experiment. +# +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC included +# when the microscope session ended. +# +# +# +# +# +# +# +# +# +# +# Neither the specimen_name nor the experiment_identifier but the identifier +# through which the experiment is referred to in the control software. +# For LEAP instruments it is recommended to use the IVAS/APSuite +# run_number. For other instruments, such as the one from Stuttgart or +# Oxcart from Erlangen, or the instruments at GPM in Rouen, use the +# identifier which is closest in meaning to the LEAP run number. +# The field does not have to be required if the information is recoverable +# in the dataset which for LEAP instruments is the case when RHIT or HITS +# files are also stored alongside a data artifact instance which is +# generated according to this NXapm application definition. +# +# As a destructive microscopy technique, a run can be performed only once. +# It is possible, however, to interrupt a run and restart data acquisition +# while still using the same specimen. In this case, each evaporation run +# needs to be distinguished with different run numbers. +# We follow this habit of most atom probe groups. +# +# This application definition does currently not allow storing the +# entire set of such interrupted runs. Not because of a technical limitation +# within NeXus but because we have not seen a covering use case based +# on which we could have designed and implemented this case. +# Atom probers are invited to contact the respective people in the +# FAIRmat team to fix this. +# +# +# +# +# Binary container for a file or a compressed collection of files which +# can be used to add further descriptions and details to the experiment. +# The container can hold a compressed archive. +# +# Required for operation_mode apt_fim or other to give further details. +# Users should not abuse this field to provide free-text information. +# Instead, these pieces of information should be mapped to +# respective groups and sections. +# +# +# +# +# A small image that is representative of the entry; this can be an +# image taken from the dataset like a thumbnail of a spectrum. +# A 640 x 480 pixel jpeg image is recommended. +# Adding a scale bar to that image is recommended but not required +# as the main purpose of the thumbnail is to provide e.g. thumbnail +# images for displaying them in data repositories. +# +# +# +# +# +# What type of atom probe microscopy experiment is performed. +# This field is primarily meant to inform materials database systems +# to qualitatively filter experiments: +# +# * apt are experiments where the analysis_chamber has no imaging gas. +# experiment with LEAP instruments are typically performed as apt. +# * fim are experiments where the analysis_chamber has an imaging gas, +# which should be specified with the atmosphere in the analysis_chamber group. +# * apt_fim should be used for combinations of the two imaging modes. +# * other should be used in combination with the user specifying details in the +# experiment_documentation field. +# +# +# +# +# +# +# +# +# +# +# +# Contact information and eventually details person(s) involved in the +# microscope session. This can be the principle investigator who performed +# this experiment. Adding multiple users if relevant is recommended. +# +# +# +# Given (first) name and surname of the user. +# +# +# +# +# Name of the affiliation of the user at the point in time +# when the experiment was performed. +# +# +# +# +# Postal address of the affiliation. +# +# +# +# +# Email address of the user at the point in time when the experiment +# was performed. Writing the most permanently used email is recommended. +# +# +# +# +# Globally unique identifier of the user as offered by services +# like ORCID or ResearcherID. If this field is field the specific +# service should also be written in orcid_platform +# +# +# +# +# Name of the OrcID or ResearcherID where the account +# under orcid is registered. +# +# +# +# +# (Business) (tele)phone number of the user at the point +# in time when the experiment was performed. +# +# +# +# +# Which role does the user have in the place and at the point +# in time when the experiment was performed? Technician operating +# the microscope. Student, postdoc, principle investigator, guest +# are common examples. +# +# +# +# +# Account name that is associated with the user +# in social media platforms. +# +# +# +# +# Name of the social media platform where the account +# under social_media_name is registered. +# +# +# +# +# +# Description of the sample from which the specimen was prepared or +# site-specifically cut out using e.g. a focused-ion beam instrument. +# +# The sample group is currently a place for storing suggestions from +# atom probers about other knowledge they have gained about the sample +# from which they cut the specimen which is field-evaporated during the +# experiment. Typically this is possible because the atom probe specimen +# is usually not heat treated as is but one assumes that one has the sample +# prepared as needed (i.e. with a specific grain diameter) and can thus +# just cut out the specimen from that material. +# +# There are cases though where the specimen is processed further, i.e. the +# specimen is machined further or exposed to external stimuli during the +# experiment. In this case, these details should not be stored in the +# sample group but atom probers should make suggestions how this application +# definition can be improved to find a better place and compromise +# how to improve this application definition. +# +# In the future also details like how the grain_diameter was characterized, +# how the sample was prepared, how the material was heat-treated etc., +# should be stored as using specific application definitions/schemas +# which are then arranged and documented with a description of the workflow +# so that actionable graphs become instantiatable. +# +# +# +# Qualitative information about the grain size, here specifically +# described as the equivalent spherical diameter of an assumed +# average grain size for the crystal ensemble. +# Users of this information should be aware that although the grain +# diameter or radius is often referred to as grain size and used in +# e.g. Hall-Petch-type materials models this is if at all an ensemble +# average whose reporting may be very informative or not if the specimen +# contains a few grains only. In atom probe the latter is often the case +# because grains are measured partially as their diameter can be in the +# order of magnitude of the physical diameter of the specimen. +# +# Reporting a grain size is useful though as it allows judging if +# specific features are expected to be found in the detector hit map. +# +# +# +# +# Magnitude of the standard deviation of the grain_diameter. +# +# +# +# +# The temperature of the last heat treatment step before quenching. +# Knowledge about this value can give an idea how the sample +# was heat treated, however if available a documentation of the +# annealing treatment should be delivered by adding additional files +# which are uploaded alongside an NXapm instance. +# In the future there should better be an own schema used for the +# heat treatment. +# +# +# +# +# Magnitude of the standard deviation of the heat_treatment_temperature. +# +# +# +# +# Rate of the last quenching step. +# Knowledge about this value can give an idea how the specimen +# was heat treated, however there are many situations where one +# can imagine that the scalar value for just the quenching rate, +# i.e. the first derivative of the measured time-temperature profile +# is itself time-dependant. An example is when the specimen was +# left in the furnace after the furnace was switched off. In this case +# the specimen cools down with a specific rate of how this furnace +# cools down in the lab. Processes which in practice are often not +# documented with measuring the time-temperature profile. +# +# This can be problematic because when the furnace door was left open +# or the ambient temperature in the lab changes, i.e. for a series of +# experiments where one is conducted on a hot summer +# day and the next during winter as might have an effect on the +# evolution of the microstructure. There are many cases where this +# has been reported to be an issue in industry, e.g. think about aging +# aluminium samples left on the factory parking lot on a hot summer +# day. +# +# +# +# +# Magnitude of the standard deviation of the heat_treatment_quenching_rate. +# +# +# +# +# +# The chemical composition of the sample. Typically it is assumed that +# this more macroscopic composition is representative for the material +# so that the composition of the typically substantially less voluminous +# specimen probes from the more voluminous sample. +# +# +# +# Reporting compositions as atom and weight percent yields both +# dimensionless quantities but their conceptual interpretation +# differs. A normalization based on atom_percent counts relative to the +# total number of atoms are of a particular type. By contrast, weight_percent +# normalization factorizes in the respective mass of the elements. +# Python libraries like pint are challenged by these differences as +# at.-% and wt.-% both yield fractional quantities. +# +# +# +# +# +# +# +# +# +# Human-readable name of the element/ion (e.g. Fe). +# Name has to be a symbol of an element from the periodic table. +# All symbols in the set of NXion instances inside the group +# chemical_composition need to be disjoint. +# +# +# +# +# Composition value for the element/ion referred to under name. +# The value is normalized based on normalization, i.e. composition +# is either an atom or weight percent quantity. +# +# +# +# +# Magnitude of the standard deviation of the composition (value). +# +# +# +# +# +# +# +# +# +# Descriptive name or ideally (globally) unique persistent identifier. +# The name distinguishes the specimen from all others and especially the +# predecessor/origin (see the sample group) from where this specimen was cut. +# In cases where the specimen was e.g. site-specifically cut from the +# sample referred to in the sample group or in cases of an instrument session +# during which multiple specimens are loaded, the name has to be descriptive +# enough to resolve which specimen on e.g. the microtip array was taken. +# +# The user is advised to store the details how a specimen was cut/prepared +# from a specific sample in the sample_history. The sample_history field +# must not be used for writing an alias of the specimen. Instead, +# use the field alias for this. As an example there may be a specimen/sample +# monitoring system in a lab with bar codes. The bar code is a good +# specimen/sample name. A shorter and more human readable alias like +# A0 can be an example for something to write in the alias field. +# +# In cases where multiple specimens have been loaded into the microscope +# the name has to be the specific one, whose results are stored +# by this NXentry, because a single NXentry is to be used for the +# characterization of a single specimen in a single continuous run. +# +# Details about the specimen preparation should be stored in the +# sample_history or if this is not possible in the sample group. +# +# +# +# +# Ideally, a reference to the location of or a (globally) unique +# persistent identifier of e.g. another file which should document +# ideally as many details as possible of the material, its +# microstructure, and its thermo-chemo-mechanical processing/ +# preparation history. +# +# In the case that such a detailed history of the sample/specimen is not +# available, use this field as a free-text description to specify a +# sub-set of the entire sample history, i.e. what you would consider +# as being the key steps and relevant information about the specimen, +# its material, microstructure, thermo-chemo-mechanical processing +# state and details of the preparation. +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC information +# when the specimen was prepared. +# +# Ideally, report the end of the preparation, i.e. the last known time +# the measured specimen surface was actively prepared. Usually this +# should be a part of the sample history, i.e. the sample is imagined +# handed over for the analysis. At the point it enters the microscope +# the session starts. +# +# Knowing when the specimen was exposed to e.g. specific atmosphere is +# especially required for environmentally sensitive material such as +# hydrogen charged specimens or experiments including tracers with a +# short half time. Further time stamps prior to preparation_date should +# better be placed in resources which describe the sample_history. +# +# +# +# +# Short_name or abbreviation of the specimen name field. +# +# +# +# +# List of comma-separated elements from the periodic table +# that are contained in the sample. +# If the sample substance has multiple components, all +# elements from each component must be included in `atom_types`. +# +# The purpose of the field is to offer materials database systems an +# opportunity to parse the relevant elements without having to interpret +# these from the sample history or from other data sources. +# +# +# +# +# Discouraged free-text field in case properly designed records +# for the sample_history or sample section are not available. +# +# +# +# +# Report if the specimen is polycrystalline, in which case it +# contains a grain or phase boundary, or if the specimen is a +# single crystal. +# +# +# +# +# +# +# Hard link to a location in the hierarchy of the NeXus file +# where the data for default plotting are stored. +# +# +# +# +# Container to hold different coordinate systems conventions. +# +# For the specific idea and conventions to use with the +# NXcoordinate_system_set inspect the description of the +# NXcoordinate_system_set base class. Specific details for application +# in atom probe microscopy follow. +# +# In this research field scientists distinguish usually several +# Euclidean coordinate systems (CS): +# +# * World space; +# a CS specifying a local coordinate system of the planet earth which +# identifies into which direction gravity is pointing such that +# the laboratory space CS can be rotated into this world CS. +# * The laboratory space; +# a CS specifying the room where the instrument is located in or +# a physical landmark on the instrument, e.g. the direction of the +# transfer rod where positive is the direction how the rod +# has to be pushed during loading a specimen into the instrument. +# In summary, this CS is defined by the chassis of the instrument. +# * The specimen space; +# a CS affixed to either the base or the initial apex of the specimen, +# whose z axis points towards the detector. +# * The detector space; +# a CS affixed to the detector plane whose xy plane is usually in the +# detector and whose z axis points towards the specimen. +# This is a distorted space with respect to the reconstructed ion +# positions. +# * The reconstruction space; +# a CS in which the reconstructed ion positions are defined. +# The orientation depends on the analysis software used. +# * Eventually further coordinate systems attached to the +# flight path of individual ions might be defined. +# +# Coordinate systems should be right-handed ones. +# Clockwise rotations should be considered positive rotations. +# +# In atom probe microscopy a frequently used choice for the detector +# space (CS) is discussed with the so-called detector space image +# (stack). This is a stack of two-dimensional histograms of detected ions +# within a predefined evaporation ID interval. Typically, the set of +# ion evaporation sequence IDs is grouped into chunks. +# +# For each chunk a histogram of the ion hit positions on the detector +# is computed. This leaves the possibility for inconsistency between +# the so-called detector space and the e.g. specimen space. +# +# The transformation here resolves this ambiguity by specifying how +# the positive z-axes of either coordinate systems is oriented. +# Consult the work of A. J. Breen and B. Gault and team +# for further details. +# +# +# +# +# +# +# +# +# +# Metadata and numerical data of the atom probe and the lab in which it +# stands. +# +# An atom probe microscope (experiment) is different compared to a large- +# scale facility or electron accelerator experiments in at least two ways: +# +# * First, ionized atoms and molecular ion(s fragments) +# (in the case of atom probe tomography) +# and (primarily) imaging gas ions (in the case of field ion +# microscopy) are accelerated towards a position-sensitive +# and time-of-flight taking detector system. +# Hence, there is no real probe/beam. +# * Second, the specimen is the lens of the microscope. +# +# +# +# +# Given name of the atom probe at the hosting institution. This is an +# alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, +# etc. +# +# +# +# +# Location of the lab or place where the instrument is installed. +# Using GEOREF is preferred. +# +# +# +# +# +# +# +# +# +# +# The space inside the atom probe along which ions pass nominally +# when they leave the specimen and travel to the detector. +# +# THIS DOCSTRING NEEDS CLARIFICATION. +# +# +# +# +# +# The nominal diameter of the specimen ROI which is measured in the +# experiment. It is important to mention that the physical specimen +# cannot be measured completely because ions may launch but not be +# detected or hit elsewhere in the analysis_chamber. +# +# +# +# +# +# +# Is a reflectron installed and was it used? +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# A local electrode guiding the ion flight path. Also called +# counter or extraction electrode. +# +# +# +# Identifier of the local_electrode in an e.g. database. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Detector for taking raw time-of-flight and +# ion/hit impact positions data. +# +# +# +# Description of the detector type. Specify if the detector is +# not the usual type, i.e. not a delay-line detector. +# In the case the detector is a multi-channel plate/ +# delay line detector, use mcp_dld. In the case the detector is +# a phosphor CCD use phosphor_ccd. In other case specify +# the detector type via free-text. +# +# +# +# +# +# Given name/alias. +# +# +# +# +# +# Given brand or model name by the manufacturer. +# +# +# +# +# Given hardware name/serial number or hash identifier +# issued by the manufacturer. +# +# +# +# +# Given name of the manufacturer. +# +# +# +# +# Amplitude of the signal detected on the multi-channel plate (MCP). +# +# This field should be used for storing the signal amplitude quantity +# within ATO files. The ATO file format is used primarily by the +# atom probe groups of the GPM in Rouen, France. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Atom probe microscopes use controlled laser, voltage, or a +# combination of pulsing strategies to trigger the excitation +# and eventual field evaporation/emission of an ion during +# an experiment. +# If pulse_mode is set to laser or laser_and_voltage (e.g. for +# LEAP6000-type instruments) having the group/section laser_gun +# is required and the following of its fields have to be filled: +# +# * name +# * wavelength +# * energy +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Average temperature at the specimen base, i.e. +# base_temperature during the measurement. +# +# +# +# +# The best estimate, at experiment time, for the temperature at the +# sample base (furthest point along sample apex and holding assembly +# that is removable from the sample stage). +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Average pressure in the analysis chamber. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Average pressure in the buffer chamber. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Average pressure in the load_lock_chamber. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# A possible place, which has to be discussed with the atom probe +# community more though, where quantitative details about the calibration +# of the counter electrode could be stored. Work in this direction was +# e.g. reported by the `Erlangen group <https://www.youtube.com/watch?v=99hNEkqdj78t=1876s>`_ +# (see `P. Felfer et al. <http://dx.doi.org/10.1016/j.ultramic.2016.07.008>`_ ) +# +# +# +# +# +# +# A place where details about the initial shape of the specimen +# can be stored. Ideally, here also data about the shape evolution +# of the specimen can be stored. There are currently very few +# techniques which can measure the shape evolution: +# +# * Correlative electron microscopy coupled with modeling +# but this usually takes an interrupted experiment +# in which the specimen is transferred, an image taken, +# and a new evaporation sequence initiated. +# Examples are `I. Mouton et al. <https://doi.org/10.1017/S1431927618016161>`_ +# and `C. Fletcher <https://doi.org/10.1088/1361-6463/abaaa6>`_. +# * Another method, which is less accurate though, is to monitor +# the specimen evolution via the in-built camera system +# (if available) in the instrument. +# * Another method is to use correlated scanning force microscopy +# methods like reported in `C. Fleischmann <https://doi.org/10.1016/j.ultramic.2018.08.010>`_. +# * A continuous monitoring of the specimen in a +# correlative electron microscopy/atom probe experiment +# is planned to be developed by `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_ +# Nothing can be said about the outcome of this research yet but +# here is where such spatio-temporally data could be stored. +# +# +# +# +# Ideally measured or best elaborated guess of the +# initial radius of the specimen. +# +# +# +# +# Ideally measured or best elaborated guess of the shank angle. +# This is a measure of the specimen taper. Define it in such a way +# that the base of the specimen is modelled as a conical frustrum so +# that the shank angle is the (shortest) angle between the specimen +# space z-axis and a vector on the lateral surface of the cone. +# +# +# +# +# Average detection rate over the course of the experiment. +# +# +# +# +# +# Estimated field at the apex along the evaporation sequence. +# +# +# +# +# +# +# +# +# The majority of atom probe microscopes come from a +# single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. +# Their instruments are controlled via an(/a set) of integrated +# instrument control system(s) (APSuite/IVAS/DAVis). +# +# By contrast, instruments which were built by individual +# research groups such as of the French (GPM, Rouen, France), +# the Schmitz (Inspico, Stuttgart, Germany), +# the Felfer (Oxcart, Erlangen, Germany), +# the Northwestern (D. Isheim, Seidman group et al.), +# or the PNNL group (Pacific Northwest National Laborary, +# Portland, Oregon, U.S.) have other solutions +# to control the instrument. +# +# Some of which are modularized and open, +# some of which realize also integrated control units with +# portions of eventually undisclosed source code and +# (so far) lacking (support of)/open APIs. +# +# Currently, there is no accepted/implemented +# community-specific API for getting finely granularized +# access to such control settings. +# +# These considerations motivated the design of the NXapm +# application definition in that it stores quantities in NXcollection. +# groups to begin with. Holding heterogeneous, not yet standardized +# but relevant pieces of information is the purpose of this collection. +# +# +# +# +# +# +# +# +# +# Track time-dependent details over the course of the measurement about the +# buffer_chamber. +# +# +# +# +# Track time-dependent details over the course of the measurement about the +# load_lock_chamber. +# +# +# +# +# Track time-dependent details over the course of the measurement about the +# analysis_chamber. +# +# +# +# +# +# +# +# A statement whether the measurement was successful or failed prematurely. +# +# +# +# +# +# +# +# +# +# +# +# +# Details about where ions hit the ion_detector and data processing +# steps related to analog-to-digital conversion of detector signals +# into ion hit positions. For AMETEK LEAP instruments this processing +# takes place partly in the control unit of the detector partly +# in the software. The process is controlled by the acquisition/ +# instrument control software (IVAS/APSuite/DAVis). +# The exact details are not documented by AMETEK in an open manner. +# For instruments built by individual research groups, +# like the Oxcart instrument, individual timing data from the +# delay-line detector are openly accessible. +# +# +# +# +# +# +# +# +# +# +# Raw readings from the analog-to-digital-converter +# timing circuits of the detector wires. +# +# +# +# +# +# +# +# +# +# Evaluated ion impact coordinates at the detector +# (either as computed from the arrival time data +# or as reported by the control software). +# If the acquisition software enables it one can also store in this +# field the hit_positions, as measured by the detector, without any +# corrections. +# +# +# +# +# +# +# +# +# +# +# This could be a place where currently the publicly undocumented +# algorithmic steps are stored how detected hits are judged for their +# quality. In CamecaRoot this there is something mentioned like +# golden and partial hits, here is where this could be documented. +# +# +# +# +# +# +# Data post-processing step which is, like the impact position analyses, +# usually executed in the integrated control software. This processing +# yields how many ions were detected with each pulse. +# +# It is possible that multiple ions evaporate and hit the same or +# different pixels of the detector on the same pulse. +# These data form the basis to analyses of the so-called +# (hit) multiplicity of an ion. +# +# Multiplicity must not be confused with how many atoms +# f the same element or isotope, respectively, a molecular +# ion contains (which is instead encoded with the +# isotope_vector field of each NXion instance). +# +# +# +# +# +# +# +# +# +# Number of pulses since the last detected ion pulse. +# For multi-hit records, after the first record, this is zero. +# +# +# +# +# +# +# +# +# Number of pulses since the start of the atom probe +# run/evaporation sequence. +# +# +# +# +# +# +# +# +# Hit multiplicity. +# +# +# +# +# +# +# +# +# Like impact position and hit multiplicity computations, +# ion filtering is a data post-processing step with which users +# identify which of the detected ions should be included +# in the voltage-and-bowl correction. +# This post-processing is usually performed via GUI interaction +# in the reconstruction pipeline of IVAS/APSuite. +# +# +# +# +# +# +# +# +# +# Bitmask which is set to true if the ion +# is considered and false otherwise. +# +# +# +# +# +# +# +# +# +# Data post-processing step to correct for ion impact +# position flight path differences, detector biases, +# and nonlinearities. This step is usually performed +# with commercial software. +# +# +# +# +# +# +# +# +# +# +# Raw time-of-flight data as read out from the acquisition software +# if these data are available and accessible. +# +# +# +# +# +# +# +# +# Calibrated time-of-flight. +# +# +# +# +# +# +# +# The key idea and algorithm of the voltage-and-bowl correction is +# qualitatively similar for instruments of different manufacturers +# or research groups. +# +# Specific differences exists though in the form of different +# calibration models. For now we do not wish to resolve or +# generalize these differences. Rather the purpose of this collection +# is to provide a container where model-specific parameters +# and calibration models can be stored if users know these +# for sure. +# +# For AMETEK LEAP instruments this should be the place for +# storing initial calibration values. These values are +# accessible normally only by AMETEK service engineers. +# They use these for calibrating the detector and instrument. +# +# Users can also use this NXcollection for storing the +# iteratively identified calibrations which scientists +# will see displayed in e.g. APSuite while they execute +# the voltage-and-bowl correction as a part of the +# reconstruction pipeline in APSuite. +# +# +# +# +# +# +# Data post-processing step in which calibrated time-of-flight data +# (ToF) are interpreted into mass-to-charge-state ratios. +# +# +# +# +# +# +# +# +# +# Store vendor-specific calibration models here (if available). +# +# +# +# +# Mass-to-charge-state ratio values. +# +# +# +# +# +# +# +# +# +# +# Data post-processing step to create a tomographic reconstruction +# of the specimen based on selected calibrated ion hit positions, +# the evaporation sequence, and voltage curve data. +# Very often scientists use own software scripts according to +# published procedures, so-called reconstruction protocols, +# i.e. numerical recipes how to compute x, y, z atomic positions +# from the input data. +# +# +# +# +# +# +# +# +# +# Qualitative statement about which reconstruction protocol was used. +# +# +# +# +# +# +# +# +# +# +# +# +# Different reconstruction protocols exist. Although these approaches +# are qualitatively similar, each protocol uses different parameters +# (and interprets these differently). The source code to IVAS/APSuite +# is not open. For now users should store reconstruction parameter +# in a collection. +# +# +# +# +# +# Different strategies for crystallographic calibration of the +# reconstruction are possible. The field is required and details +# should be specified in free-text at least. If the not crystallographic +# calibration was performed the field should be filled with the n/a, +# meaning not applied. +# +# +# +# +# Three-dimensional reconstructed positions of the ions. +# Interleaved array of x, y, z positions in the specimen space. +# +# +# +# +# +# +# +# +# +# An array of triplets of integers which can serve as a supplementary +# array for Paraview to display the reconstructed dataset. +# The XDMF primitive type is here 1, the number of primitives 1 per +# triplet, the last integer in each triplet is the identifier of +# each point starting from zero. +# +# +# +# +# +# +# +# +# +# Six equally formatted sextets chained together. For each +# sextett the first entry is an XDMF primitive topology +# key (here 5 for polygon), the second entry the XDMF primitive +# count value (here 4 because each face is a quad). +# The remaining four values are the vertex indices. +# +# +# +# +# +# +# +# To get a first overview of the reconstructed dataset, +# the format conversion computes a simple 3d histogram +# of the ion density using one nanometer cubic bins without +# applying smoothening algorithms on this histogram. +# +# +# +# +# +# +# +# +# A default three-dimensional histogram of the total +# number of ions in each bin obtained via using a rectangular +# transfer function. +# +# +# +# +# +# +# +# +# Array of counts for each bin. +# +# +# +# +# +# +# +# +# +# Bin center of mass position along the z axis. +# +# +# +# +# +# +# +# +# Bin center of mass position along the y axis. +# +# +# +# +# +# +# +# +# Bin center of mass position along the x axis. +# +# +# +# +# +# +# +# +# +# +# +# +# Data post-processing step in which elemental, isotopic, +# and/or molecular identities are assigned to the ions. +# The documentation of these steps is based on ideas +# described in the literature: +# +# * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ +# * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ +# * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ +# +# +# +# +# +# +# +# +# +# How many ion types are distinguished. +# If no ranging was performed each ion is of the special unknown type. +# The iontype ID of this unknown type is 0 which is a reserve value. +# Consequently, iontypes start counting from 1. +# +# +# +# +# Assumed maximum value that suffices to store all relevant +# molecular ions, even the most complicated ones. +# Currently a value of 32 is used. +# +# +# +# +# Specifies the computation of the mass-to-charge histogram. +# Usually mass-to-charge values are studied as an ensemble quantity, +# specifically these values are binned. +# This (NXprocess) stores the settings of this binning. +# +# +# +# +# +# +# +# +# Smallest and largest mass-to-charge-state ratio value. +# +# +# +# +# +# +# +# +# Binning width of the mass-to-charge-state ratio values. +# +# +# +# +# +# A default histogram aka mass spectrum of +# the mass-to-charge-state ratio values. +# +# +# +# +# +# +# +# +# Array of counts for each bin. +# +# +# +# +# +# +# +# +# Right boundary of each mass-to-charge-state ratio value bin. +# +# +# +# +# +# +# +# +# +# +# +# Details of the background model which was used to +# correct the total counts per bin into counts. +# +# +# +# +# +# +# +# +# +# +# How where peaks in the background-corrected in the histogram +# of mass-to-charge-state ratio values identified? +# +# +# +# +# +# +# +# +# +# +# THIS DOCSTRING NEEDS CLARIFICATION. +# +# +# +# +# +# +# Details about how peaks, with taking into account +# error models, were interpreted as ion types or not. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_composition_space_results.yaml b/contributed_definitions/nyaml/NXapm_composition_space_results.yaml new file mode 100644 index 0000000000..30fae546b6 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_composition_space_results.yaml @@ -0,0 +1,903 @@ +category: application +doc: | + Results of a run with Alaukik Saxena's composition space tool. + + This is an initial draft application definition for the common NFDI-MatWerk, + FAIRmat infrastructure use case IUC09 how to improve the organization and + results storage of the composition space tool and make these data at the same + time directly understandable for NOMAD. + + This draft does no contain yet the annotations for how to also store + in the HDF5 file a default visualization whereby the composition grid + could directly be explored using H5Web. I am happy to add this ones the + data have been mapped on this schema, i.e. more discussion needed. + + Also iso-surfaces can be described, for paraprobe, this is a solved problem, + check the respective group in the NXapm_paraprobe_results_nanochem data + schema/application definition. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_voxel: | + Number of voxel of discretized domain for analyzed part of the dataset. + d: | + The dimensionality of the grid. + c: | + The cardinality or total number of cells/grid points. + n_clst_dict: | + Number of terms in the composition clustering dictionary + n_spat_dict: | + Number of terms in the position clustering dictionary +type: group +NXapm_composition_space_results(NXobject): + + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + (NXentry): + exists: ['min', '1', 'max', '1'] + \@version: + doc: | + Version specifier of this application definition. + definition: + doc: | + Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_composition_space_results] + + # can be used for the name of the tool and version but also + # for if desired all the dependencies and libraries + (NXprogram): + exists: ['min', '1', 'max', 'unbounded'] + program: + \@version: + job_pyiron_identifier: + exists: recommended + doc: | + TBD, maybe how to link between pyiron state tracking and app state tracking + description: + exists: optional + doc: | + Disencouraged place for free-text for e.g. comments. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. when composition space tool was started as a process. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and composition space tool exited as a process. + config_filename: + doc: | + The path and name of the config file for this analysis. + TBD, this can be e.g. Alaukik's YAML file for composition space. + + # one could also wrap the entire triple of NXprocess (voxelization, gmm, real space) + # by a parent NXprocess whereby one could store the results of multiple analyses + # runs of the tool in the same individually documented way for as many parameter + # runs as desired... + \@version: + doc: | + At least SHA256 strong hash of the specific config_file for + tracking provenance. + dataset(NXapm_input_reconstruction): + filename: + doc: | + The path and name of the file (technology partner or community format) + from which reconstructed ion positions were loaded. + \@version: + iontypes(NXapm_input_ranging): + filename: + doc: | + The path and name of the file (technology partner or community format + from which ranging definitions, i.e. how to map mass-to- + charge-state ratios on iontypes were loaded. + \@version: + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + status: + doc: | + A statement whether the executable managed to process the analysis + or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + enumeration: [success, failure] + (NXuser): + exists: recommended + doc: | + If used, contact information and eventually details + of at least the person who performed this analysis. + name: + affiliation: + exists: recommended + address: + exists: optional + email: + exists: recommended + orcid: + exists: recommended + orcid_platform: + exists: recommended + telephone_number: + exists: optional + role: + exists: recommended + social_media_name: + exists: optional + social_media_platform: + exists: optional + (NXcoordinate_system_set): + exists: optional + doc: | + Details about the coordinate system conventions used. + (NXtransformations): + exists: ['min', '1', 'max', 'unbounded'] + doc: | + The individual coordinate systems which should be used. + Some suggestions follow, e.g. that field names should be prefixed + with the following controlled terms indicating which individual + coordinate system is described: + + * world + * composition_space + * lab + * specimen + * laser + * leap + * detector + * recon + voxelization(NXprocess): + sequence_index(NX_POSINT): + enumeration: [1] + + # specify the grid your using and for each ion in which cell i.e. voxel it is + # one could also have a more sophisticated data model where there is some + # fuzziness i.e. if an ML/AI model returns multiple values or a probability + # how likely an ion is in which voxel, for this + # inspect the example of the NXem_ebsd application definition + (NXcg_grid): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + enumeration: [1, 2, 3] + cardinality(NX_POSINT): + unit: NX_UNITLESS + + # default behaviour, if no coordinate system defined, unclear + # if one coordinate system is defined the origin is defined in this cs + origin(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, d]] + symmetry: + enumeration: [cubic] + cell_dimensions(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, d]] + extent(NX_POSINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, d]] + (NXtransformations): + exists: recommended + doc: | + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + + position(NX_NUMBER): + unit: NX_LENGTH + doc: | + Position of each cell in Euclidean space. + dimensions: + rank: 2 + dim: [[1, c], [2, d]] + coordinate(NX_INT): + exists: optional + unit: NX_DIMENSIONLESS + dimensions: + rank: 2 + dim: [[1, c], [2, d]] + + # bounding box if needed + voxel_identifier(NX_UINT): + unit: NX_UNITLESS + doc: | + For each ion, the identifier of the voxel in which the ion is located. + dimensions: + rank: 1 + dim: [[1, n_ions]] + (NXion): + exists: ['min', '0', 'max', 'unbounded'] + name: + composition(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, n_voxel]] + clustering_composition_space(NXprocess): + doc: | + In Alaukik's tool the GMM step. + sequence_index(NX_POSINT): + enumeration: [2] + cluster_dict_keyword: + doc: | + The keywords of the dictionary of distinguished compositionally- + defined cluster, e.g. the phases. Examples for keywords could be + phase1, phase2, and so one and so forth. + dimensions: + rank: 1 + dim: [[1, n_clst_dict]] + cluster_dict_value(NX_UINT): + unit: NX_UNITLESS + doc: | + Resolves for each keyword in cluster_dict which integer is used to + label something that it belongs or is assumed to represent this + cluster. + dimensions: + rank: 1 + dim: [[1, n_clst_dict]] + + # again for fuzzy or probabilistic multi solution approaches see NXem_ebsd + cluster_identifier(NX_UINT): + unit: NX_UNITLESS + doc: | + For example if the voxel grid is used to report that there + are voxels which are assumed to represent volume of either phase1 + or phase2, the cluster_dict_keyword would be a list with two names + phase1 and phase2, respectively. The cluster_dict_value would be a + list of e.g. integers 1 and 2. These could be used to build an + array with as many entries as there are voxel and store in this array + the respective value to encode which phase is assumed for each voxel. + dimensions: + rank: 1 + dim: [[1, n_voxel]] + + # use the fact that with e.g. XDMF one can on-the-fly reinterpret + # a 1d array to represent an explicit 3d grid + # default plots would be nice could directly be integrated in the results file + clustering_real_space(NXprocess): + doc: | + In Alaukik's tool the DBScan step after the GMM step. + sequence_index(NX_POSINT): + enumeration: [3] + cluster_dict_keyword: + doc: | + The keywords of the dictionary of distinguished spatially-contiguous + clusters. Examples for keywords could be precipitate1, precipitate2, + and so one and so forth. + dimensions: + rank: 1 + dim: [[1, n_spat_dict]] + cluster_dict_value(NX_UINT): + unit: NX_UNITLESS + doc: | + Resolves for each keyword in cluster_dict which integer is used to + label something that it belongs or is assumed to represent this + cluster. + dimensions: + rank: 1 + dim: [[1, n_spat_dict]] + + # again for fuzzy or probabilistic multi solution approaches see NXem_ebsd + cluster_identifier(NX_UINT): + unit: NX_UNITLESS + doc: | + For example if the voxel grid is used to report that there + are voxels which are assumed to represent volume of certain precipitates, + say we found ten precipitates and consider the rest as matrix. + We could make a list of say matrix, precipitate1, precipitate2, ..., + precipitate10. With cluster_dict_value then running from 0 to 10, + i.e. matrix is flagged special as 0 and the remaining particles + are indexed conveniently as 1, 2, ..., 10 like end users expect. + dimensions: + rank: 1 + dim: [[1, n_voxel]] + + # use the fact that with e.g. XDMF one can on-the-fly reinterpret + # a 1d array to represent an explicit 3d grid + # then the entire visualization just needs a smart XDMF file with + # one section with the coordinates of the voxel center of masses + # one section with the voxel identifier + # one section with the "phase" identifier referring to the clustering_composition_space NXprocess group + # one section with the "precipitate" identifier referring to the clustering_real_space NXprocess group + # technically one should get rid of the unnecessary chunks + # instead define an (nx, ny, nz) C-style array which whose data space + # is reserved by the h5py library upon first call and then (if desired) + # filled incrementally + # the array should be chunked not with an auto-chunking but with a nx, ny, >=1 chunking + # which will make visualization of nx, ny slices naturally fast, making the z-dimension + # chunking as fast as large as possible (needs compromise to remain within chunk cache size) + # will also make the orthogonal section a good compromise fast + # data should be gzip, level 1 compressed and all the redundant parts of the current + # output will collapse substantially + performance(NXcs_profiling): + current_working_directory: + command_line_call: + exists: optional + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + total_elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): + (NXcs_computer): + exists: recommended + name: + exists: recommended + operating_system: + \@version: + uuid: + exists: optional + (NXcs_cpu): + exists: ['min', '0', 'max', 'unbounded'] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_gpu): + exists: ['min', '0', 'max', 'unbounded'] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_mm_sys): + exists: ['min', '0', 'max', '1'] + total_physical_memory(NX_NUMBER): + (NXcs_io_sys): + exists: ['min', '0', 'max', '1'] + (NXcs_io_obj): + exists: ['min', '1', 'max', 'unbounded'] + technology: + max_physical_capacity(NX_NUMBER): + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_profiling_event): + start_time(NX_DATE_TIME): + exists: optional + end_time(NX_DATE_TIME): + exists: optional + description: + elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + number_of_threads(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + number_of_gpus(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + max_virtual_memory_snapshot(NX_NUMBER): + exists: recommended + max_resident_memory_snapshot(NX_NUMBER): + exists: recommended + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# fe3315d020167a5d984295fad8ed2070693508cd60801e40acaac2a61f21f1b4 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of voxel of discretized domain for analyzed part of the dataset. +# +# +# +# +# The dimensionality of the grid. +# +# +# +# +# The cardinality or total number of cells/grid points. +# +# +# +# +# Number of terms in the composition clustering dictionary +# +# +# +# +# Number of terms in the position clustering dictionary +# +# +# +# +# Results of a run with Alaukik Saxena's composition space tool. +# +# This is an initial draft application definition for the common NFDI-MatWerk, +# FAIRmat infrastructure use case IUC09 how to improve the organization and +# results storage of the composition space tool and make these data at the same +# time directly understandable for NOMAD. +# +# This draft does no contain yet the annotations for how to also store +# in the HDF5 file a default visualization whereby the composition grid +# could directly be explored using H5Web. I am happy to add this ones the +# data have been mapped on this schema, i.e. more discussion needed. +# +# Also iso-surfaces can be described, for paraprobe, this is a solved problem, +# check the respective group in the NXapm_paraprobe_results_nanochem data +# schema/application definition. +# +# +# +# +# +# Version specifier of this application definition. +# +# +# +# +# Official NeXus NXDL schema with which this file was written. +# +# +# +# +# +# +# +# +# +# +# +# +# +# TBD, maybe how to link between pyiron state tracking and app state tracking +# +# +# +# +# Disencouraged place for free-text for e.g. comments. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when the analysis behind this results file +# was started, i.e. when composition space tool was started as a process. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when the analysis behind this results file +# were completed and composition space tool exited as a process. +# +# +# +# +# The path and name of the config file for this analysis. +# TBD, this can be e.g. Alaukik's YAML file for composition space. +# +# +# +# +# At least SHA256 strong hash of the specific config_file for +# tracking provenance. +# +# +# +# +# +# +# The path and name of the file (technology partner or community format) +# from which reconstructed ion positions were loaded. +# +# +# +# +# +# +# +# The path and name of the file (technology partner or community format +# from which ranging definitions, i.e. how to map mass-to- +# charge-state ratios on iontypes were loaded. +# +# +# +# +# +# +# Path to the directory where the tool should store NeXus/HDF5 results +# of this analysis. If not specified results will be stored in the +# current working directory. +# +# +# +# +# A statement whether the executable managed to process the analysis +# or failed prematurely. +# +# This status is written to the results file after the end_time +# at which point the executable must not compute any analysis. +# Only when this status message is present and shows `success`, the +# user should consider the results. In all other cases it might be +# that the executable has terminated prematurely or another error +# occurred. +# +# +# +# +# +# +# +# +# If used, contact information and eventually details +# of at least the person who performed this analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Details about the coordinate system conventions used. +# +# +# +# The individual coordinate systems which should be used. +# Some suggestions follow, e.g. that field names should be prefixed +# with the following controlled terms indicating which individual +# coordinate system is described: +# +# * world +# * composition_space +# * lab +# * specimen +# * laser +# * leap +# * detector +# * recon +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Reference to or definition of a coordinate system with +# which the positions and directions are interpretable. +# +# +# +# +# +# +# +# +# +# Position of each cell in Euclidean space. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# For each ion, the identifier of the voxel in which the ion is located. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# In Alaukik's tool the GMM step. +# +# +# +# +# +# +# +# +# The keywords of the dictionary of distinguished compositionally- +# defined cluster, e.g. the phases. Examples for keywords could be +# phase1, phase2, and so one and so forth. +# +# +# +# +# +# +# +# Resolves for each keyword in cluster_dict which integer is used to +# label something that it belongs or is assumed to represent this +# cluster. +# +# +# +# +# +# +# +# +# For example if the voxel grid is used to report that there +# are voxels which are assumed to represent volume of either phase1 +# or phase2, the cluster_dict_keyword would be a list with two names +# phase1 and phase2, respectively. The cluster_dict_value would be a +# list of e.g. integers 1 and 2. These could be used to build an +# array with as many entries as there are voxel and store in this array +# the respective value to encode which phase is assumed for each voxel. +# +# +# +# +# +# +# +# +# +# In Alaukik's tool the DBScan step after the GMM step. +# +# +# +# +# +# +# +# +# The keywords of the dictionary of distinguished spatially-contiguous +# clusters. Examples for keywords could be precipitate1, precipitate2, +# and so one and so forth. +# +# +# +# +# +# +# +# Resolves for each keyword in cluster_dict which integer is used to +# label something that it belongs or is assumed to represent this +# cluster. +# +# +# +# +# +# +# +# +# For example if the voxel grid is used to report that there +# are voxels which are assumed to represent volume of certain precipitates, +# say we found ten precipitates and consider the rest as matrix. +# We could make a list of say matrix, precipitate1, precipitate2, ..., +# precipitate10. With cluster_dict_value then running from 0 to 10, +# i.e. matrix is flagged special as 0 and the remaining particles +# are indexed conveniently as 1, 2, ..., 10 like end users expect. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Specify if it was different from the number_of_processes +# in the NXcs_profiling super class. +# +# +# +# +# +# Specify if it was different from the number_of_threads +# in the NXcs_profiling super class. +# +# +# +# +# +# Specify if it was different from the number_of_threads +# in the NXcs_profiling super class. +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_input_ranging.yaml b/contributed_definitions/nyaml/NXapm_input_ranging.yaml new file mode 100644 index 0000000000..8735f8baa8 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_input_ranging.yaml @@ -0,0 +1,101 @@ +category: base +doc: | + Metadata to ranging definitions made for a dataset in atom probe microscopy. + + Ranging is the process of labeling time-of-flight data with so-called iontypes + which ideally specify the most likely ion/molecular ion evaporated within a + given mass-to-charge-state-ratio value interval. + + The paraprobe-toolbox uses the convention that the so-called UNKNOWNTYPE + iontype (or unranged ions) represents the default iontype. + The ID of this special iontype is always reserved as 0. Each ion + is assigned to the UNKNOWNTYPE by default. Iontypes are assigned + by checking if the mass-to-charge-state-ratio values of an ion matches + to any of the defined mass-to-charge-state-ratio intervals. + +# symbols: +type: group +NXapm_input_ranging(NXobject): + filename: + doc: | + Path and name of the NeXus/HDF5 file which stores ranging definitions. + \@version: + doc: | + Version identifier of the file (representing an at least SHA256 strong) + hash. Such hashes serve reproducibility as they can be used for tracking + provenance metadata in a workflow. + group_name_iontypes: + doc: | + Name of the group (prefix to the individual ranging definitions) inside + the file referred to by filename which points to the specific ranging + definition to use. + An HDF5 file can store multiple ranging definitions. Using an ID is + the mechanism to distinguish which specific ranging (version) will + be processed. Reconstruction and ranging IDs can differ. + They specify different IDs. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 84be754a74580064b6e83b8cc1e513bdcad4ae264f96c9203c5341fc784b2a03 +# +# +# +# +# +# +# Metadata to ranging definitions made for a dataset in atom probe microscopy. +# +# Ranging is the process of labeling time-of-flight data with so-called iontypes +# which ideally specify the most likely ion/molecular ion evaporated within a +# given mass-to-charge-state-ratio value interval. +# +# The paraprobe-toolbox uses the convention that the so-called UNKNOWNTYPE +# iontype (or unranged ions) represents the default iontype. +# The ID of this special iontype is always reserved as 0. Each ion +# is assigned to the UNKNOWNTYPE by default. Iontypes are assigned +# by checking if the mass-to-charge-state-ratio values of an ion matches +# to any of the defined mass-to-charge-state-ratio intervals. +# +# +# +# Path and name of the NeXus/HDF5 file which stores ranging definitions. +# +# +# +# Version identifier of the file (representing an at least SHA256 strong) +# hash. Such hashes serve reproducibility as they can be used for tracking +# provenance metadata in a workflow. +# +# +# +# +# +# Name of the group (prefix to the individual ranging definitions) inside +# the file referred to by filename which points to the specific ranging +# definition to use. +# An HDF5 file can store multiple ranging definitions. Using an ID is +# the mechanism to distinguish which specific ranging (version) will +# be processed. Reconstruction and ranging IDs can differ. +# They specify different IDs. +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_input_reconstruction.yaml b/contributed_definitions/nyaml/NXapm_input_reconstruction.yaml new file mode 100644 index 0000000000..0d3fb996fe --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_input_reconstruction.yaml @@ -0,0 +1,89 @@ +category: base +doc: | + Metadata of a dataset (tomographic reconstruction) in atom probe microscopy. + +# symbols: +type: group +NXapm_input_reconstruction(NXobject): + filename: + doc: | + Name of the (NeXus)/HDF5 file which stores reconstructed ion position + and mass-to-charge-state ratios. Such an HDF5 file can store multiple + reconstructions. Using the information within the dataset_name fields + is the mechanism whereby paraprobe decides which reconstruction to + process. With this design it is possible that the same HDF5 + file can store multiple versions of a reconstruction. + \@version: + doc: | + Version identifier of the file (representing an at least SHA256 strong) + hash. Such hashes serve reproducibility as they can be used for tracking + provenance metadata in a workflow. + dataset_name_reconstruction: + doc: | + Name of the dataset inside the HDF5 file which refers to the + specific reconstructed ion positions to use for this analysis. + dataset_name_mass_to_charge: + doc: | + Name of the dataset inside the HDF5 file which refers to the + specific mass-to-charge-state-ratio values to use for this analysis. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 5f409b194cbe10570c31933903ade8ac14d43cbc05493d52f0494615fe2071d7 +# +# +# +# +# +# +# Metadata of a dataset (tomographic reconstruction) in atom probe microscopy. +# +# +# +# Name of the (NeXus)/HDF5 file which stores reconstructed ion position +# and mass-to-charge-state ratios. Such an HDF5 file can store multiple +# reconstructions. Using the information within the dataset_name fields +# is the mechanism whereby paraprobe decides which reconstruction to +# process. With this design it is possible that the same HDF5 +# file can store multiple versions of a reconstruction. +# +# +# +# Version identifier of the file (representing an at least SHA256 strong) +# hash. Such hashes serve reproducibility as they can be used for tracking +# provenance metadata in a workflow. +# +# +# +# +# +# Name of the dataset inside the HDF5 file which refers to the +# specific reconstructed ion positions to use for this analysis. +# +# +# +# +# Name of the dataset inside the HDF5 file which refers to the +# specific mass-to-charge-state-ratio values to use for this analysis. +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.yaml new file mode 100644 index 0000000000..063f13f3a0 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.yaml @@ -0,0 +1,860 @@ +category: application +doc: | + Configuration of a paraprobe-clusterer tool run in atom probe microscopy. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + + # n_positions: Number of position values. + # n_disjoint_clusters: Number of disjoint cluster. + n_ivecmax: | + Maximum number of atoms per molecular ion. Should be 32 for paraprobe. + n_clust_algos: | + Number of clustering algorithms used. + n_ions: | + Number of different iontypes to distinguish during clustering. +type: group +NXapm_paraprobe_config_clusterer(NXobject): + (NXentry): + + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + \@version: + doc: | + Version specifier of this application definition. + definition: + doc: | + Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_config_clusterer] + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + time_stamp(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + analysis_identifier: + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: | + Possibility for leaving a free-text description about this analysis. + number_of_processes(NX_UINT): + unit: NX_UNITLESS + doc: | + How many tasks to perform? + cameca_to_nexus(NXprocess): + exists: optional + doc: | + This process maps results from cluster analyses performed with IVAS/APSuite + into an interoperable representation. Specifically in this process + paraprobe-clusterer takes results from clustering methods from other tools + of the APM community, like IVAS/APSuite. These results are usually reported + in two ways. Either as an explicit list of reconstructed ion positions. + In the case of IVAS these positions are reported through a text file + with a cluster label for each position. + + Alternatively, the list of positions is reported, as it is the case for + AMETEK (IVAS/AP Suite) but the cluster labels are specified implicitly + only in the following way: The mass-to-charge-state ratio column of a + what is effectively a file formatted like POS is used to assign a hypothetical + mass-to-charge value which resolves a floating point representation + of the cluster ID. + + Another case can occur where all disjoint floating point values, + i.e. here cluster labels, are reported and then a dictionary is created + how each value matches to a cluster ID. + + In general the cluster ID zero is reserved for marking the dataset + as to not be assigned to any cluster. Therefore, indices of disjoint + clusters start at 1. + dataset(NXapm_input_reconstruction): + filename: + \@version: + dataset_name_reconstruction: + dataset_name_mass_to_charge: + doc: | + AMETEK/Cameca results of cluster analyses, like with the maximum- + separation (MS) method clustering algorithm `J. Hyde et al. `_ + are stored as an improper POS file: This is a matrix of floating + point quadruplets, one for each ion and as many quadruplets as + ions were investigated. The first three values encode the position + of the ion. The fourth value is an improper mass-to-charge-state-ratio + value which encodes the integer identifier of the cluster as a floating + point number. + + # mapping_method: + # doc: | + # How should cluster labels be created from the cluster_labels information + # especially when these areNcluste floating point values. + # enumeration: [take_as_is, use_dictionary] + # mapping_dictionary_keyword(NX_NUMBER): + # doc: | + # The list of all keywords of a dictionary which maps implicit cluster + # indices like those from IVAS/APSuite which were0ass-to-charge-state ratios. + # unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, n_disjoint_clusters]] + # mapping_dictionary_value(NX_UINT): + # doc: | + # The list of all values of a dictionary which maps implicit cluster + # indices like those from IVAS/APSuite which were0ass-to-charge-state ratios. + # The sequences of mapping_dictionary_keyword and mapping_dictionary_value + # have to match. + # unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, n_disjoint_clusters]] + recover_evaporation_id(NX_BOOLEAN): + doc: | + Specifies if the tool should try to recover for each position the closest + matching position from dataset/dataset_name_reconstruction (within + floating point accuracy). This can be useful for instance when users + wish to recover the original evaporation ID, which IVAS/AP Suite drops + for instance when writing their *.indexed.* cluster results POS files. + + # recover_bitmask(NX_BOOLEAN): + # doc: | + # Specifies if the tool should try to recover, after a recovery of the + # evaporation IDs a bitmask which identifies which of the positions + # in dataset/dataset/dataset_name_reconstruction where covered + # by the IVAS/APSuite cluster analysis. This can be useful to recover + # the region of interest. + cluster_analysis(NXprocess): + exists: ['min', '0', 'max', '1'] + doc: | + This process performs a cluster analysis on a reconstructed dataset + or a portion of the reconstruction. + dataset(NXapm_input_reconstruction): + filename: + \@version: + dataset_name_reconstruction: + dataset_name_mass_to_charge: + iontypes(NXapm_input_ranging): + filename: + \@version: + group_name_iontypes: + ion_to_edge_distances(NXprocess): + exists: optional + doc: | + The tool enables to inject precomputed distance information for each + point/ion which can be used for further post-processing and analysis. + filename: + doc: | + Name of an HDF5 file which contains the ion distances. + \@version: + doc: | + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + dataset_name: + doc: | + Absolute HDF5 path to the dataset with distance values for each ion. + spatial_filter(NXspatial_filter): + exists: optional + windowing_method: + enumeration: [entire_dataset] + (NXcg_ellipsoid_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + half_axes_radii(NX_NUMBER): + orientation(NX_NUMBER): + (NXcg_cylinder_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + height(NX_NUMBER): + radii(NX_NUMBER): + (NXcg_hexahedron_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + hexahedra(NXcg_face_list_data_structure): + (NXcs_filter_boolean_mask): + exists: optional + number_of_objects(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + identifier(NX_UINT): + evaporation_id_filter(NXsubsampling_filter): + exists: optional + iontype_filter(NXmatch_filter): + exists: optional + hit_multiplicity_filter(NXmatch_filter): + exists: optional + + # clustering_algorithm: + # doc: | + # Name of the clustering algorithm used. + # enumeration: [dbscan] # , optics, hpdbscan] + # dimensions: + # rank: 1 + # dim: [[1, n_clust_algos]] + ion_type_filter: + doc: | + How should iontypes be interpreted/considered during the cluster analysis. + Different options exist how iontypes are interpreted (if considered at all) + given an iontype represents in general a (molecular) ion with different isotopes + that have individually different multiplicity. + + The value resolve_all will set an ion active in the analysis + regardless of which iontype it is. + The value resolve_unknown will set an ion active when it is of the + UNKNOWNTYPE. + The value resolve_ion will set an ion active if it is of the + specific iontype, irregardless of its elemental or isotopic details. + The value resolve_element will set an ion active, and most importantly, + account as many times for it, as the (molecular) ion contains + atoms of elements in the whitelist ion_query_isotope_vector. + The value resolve_isotope will set an ion active, and most importantly, + account as many times for it, as the (molecular) ion contains isotopes + in the whitelist ion_query_isotope_vector. + + In effect, ion_query_isotope_vector acts as a whitelist to filter + which ions are considered as source ions of the correlation statistics + and how the multiplicity of each ion will be factorized. + + This is relevant as in atom probe we have the situation that a ion + of a molecular ion with more than one nuclid, say Ti O for example + is counted such that although there is a single TiO molecular ion + at a position that the cluster has two members. This multiplicity + affects the size of the feature and chemical composition. + + # enumeration: [resolve_all, resolve_unknown, resolve_ion, resolve_element, resolve_isotope] + enumeration: [resolve_element] + ion_query_isotope_vector(NX_UINT): + unit: NX_UNITLESS + doc: | + Matrix of isotope vectors, as many as rows as different candidates + for iontypes should be distinguished as possible source iontypes. + In the simplest case, the matrix contains only the proton number + of the element in the row, all other values set to zero. + Combined with ion_query_type_source set to resolve_element this will + recover usual spatial correlation statistics like the 1NN C-C + spatial statistics. + dimensions: + rank: 2 + dim: [[1, n_ions], [2, n_ivecmax]] + dbscan(NXprocess): + doc: | + Settings for DBScan clustering algorithm. For original details about the + algorithms and (performance-relevant) details consider: + + * `M. Ester et al. `_ + * `M. Götz et al. `_ + + For details about how the DBScan algorithms is the key behind the + specific modification known as the maximum-separation method in the + atom probe community consider `E. Jägle et al. `_ + high_throughput_method: + doc: | + Strategy how runs are performed with different parameter: + + * For tuple as many runs are performed as parameter values. + * For combinatorics individual parameter arrays are looped over. + + As an example we may define eps with ten entries and min_pts with + three entries. If high_throughput_method is tuple the analysis is + invalid as we have an insufficient number of min_pts for the ten + eps values. + By contrast, for combinatorics paraprobe-clusterer will run three + individual min_pts runs for each eps value, resulting in a total + of 30 analyses. + As an example the DBScan analysis reported in `M. Kühbach et al. `_ + would have defined an array of values np.linspace(0.2, 5.0, nums=241, endpoint=True) + eps values, min_pts one, and high_throughput_method set to combinatorics. + enumeration: [tuple, combinatorics] + eps(NX_FLOAT): + unit: NX_LENGTH + doc: | + Array of epsilon (eps) parameter values. + dimensions: + rank: 1 + dim: [[1, i]] + min_pts(NX_UINT): + unit: NX_UNITLESS + doc: | + Array of minimum points (min_pts) parameter values. + dimensions: + rank: 1 + dim: [[1, j]] + + # THE IDEA BEHIND paraprobe-clusterer is that users can run a number of + # cluster analyses on their dataset on exactly the same point cloud and under + # the same conditions + optics(NXprocess): + doc: | + Settings for the OPTICS clustering algorithm. + + * `M. Ankerest et al. `_ + high_throughput_method: + doc: | + Strategy how runs are performed with different parameter: + + * For tuple as many runs are performed as parameter values. + * For combinatorics individual parameter arrays are looped over. + + See the explanation for the corresponding parameter for dbscan + processes above-mentioned for further details. + enumeration: [tuple, combinatorics] + min_pts(NX_UINT): + unit: NX_UNITLESS + doc: | + Array of minimum points (min_pts) parameter values. + dimensions: + rank: 1 + dim: [[1, i]] + max_eps(NX_FLOAT): + unit: NX_LENGTH + doc: | + Array of maximum epsilon (eps) parameter values. + dimensions: + rank: 1 + dim: [[1, j]] + hdbscan(NXprocess): + doc: | + Settings for the HPDBScan clustering algorithm. + + * L. McInnes et al. `_ + * scikit-learn hdbscan library ``_ + + See also this documentation for details about the parameter. + Here we use the terminology of the hdbscan documentation. + high_throughput_method: + doc: | + Strategy how runs are performed with different parameter: + + * For tuple as many runs are performed as parameter values. + * For combinatorics individual parameter arrays are looped over. + + See the explanation for the corresponding parameter for dbscan + processes above-mentioned for further details. + enumeration: [tuple, combinatorics] + min_cluster_size(NX_NUMBER): + unit: NX_ANY + doc: | + Array of min_cluster_size parameter values. + dimensions: + rank: 1 + dim: [[1, i]] + min_samples(NX_NUMBER): + unit: NX_ANY + doc: | + Array of min_samples parameter values. + dimensions: + rank: 1 + dim: [[1, j]] + cluster_selection_epsilon(NX_NUMBER): + unit: NX_ANY + doc: | + Array of cluster_selection parameter values. + dimensions: + rank: 1 + dim: [[1, k]] + alpha(NX_NUMBER): + unit: NX_ANY + doc: | + Array of alpha parameter values. + dimensions: + rank: 1 + dim: [[1, m]] + + # ADD FURTHER ALGORITHMS, see L. Stephenson for further details + # e.g. https://doi.org/10.1017/S1431927607070900 + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 619a54e03721a20d851c9a68159a0166deaa651651c085d15cfcc2593efdefb2 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# +# Maximum number of atoms per molecular ion. Should be 32 for paraprobe. +# +# +# +# +# Number of clustering algorithms used. +# +# +# +# +# Number of different iontypes to distinguish during clustering. +# +# +# +# +# Configuration of a paraprobe-clusterer tool run in atom probe microscopy. +# +# +# +# +# +# Version specifier of this application definition. +# +# +# +# +# Official NeXus NXDL schema with which this file was written. +# +# +# +# +# +# +# +# Given name of the program/software/tool with which this NeXus +# (configuration) file was generated. +# +# +# +# Ideally program version plus build number, or commit hash or description +# of ever persistent resources where the source code of the program and +# build instructions can be found so that the program can be configured +# ideally in such a manner that the result of this computational process +# is recreatable in the same deterministic manner. +# +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when this configuration file was created. +# +# +# +# +# Ideally, a (globally persistent) unique identifier for referring +# to this analysis. +# +# +# +# +# Possibility for leaving a free-text description about this analysis. +# +# +# +# +# How many tasks to perform? +# +# +# +# +# This process maps results from cluster analyses performed with IVAS/APSuite +# into an interoperable representation. Specifically in this process +# paraprobe-clusterer takes results from clustering methods from other tools +# of the APM community, like IVAS/APSuite. These results are usually reported +# in two ways. Either as an explicit list of reconstructed ion positions. +# In the case of IVAS these positions are reported through a text file +# with a cluster label for each position. +# +# Alternatively, the list of positions is reported, as it is the case for +# AMETEK (IVAS/AP Suite) but the cluster labels are specified implicitly +# only in the following way: The mass-to-charge-state ratio column of a +# what is effectively a file formatted like POS is used to assign a hypothetical +# mass-to-charge value which resolves a floating point representation +# of the cluster ID. +# +# Another case can occur where all disjoint floating point values, +# i.e. here cluster labels, are reported and then a dictionary is created +# how each value matches to a cluster ID. +# +# In general the cluster ID zero is reserved for marking the dataset +# as to not be assigned to any cluster. Therefore, indices of disjoint +# clusters start at 1. +# +# +# +# +# +# +# +# +# AMETEK/Cameca results of cluster analyses, like with the maximum- +# separation (MS) method clustering algorithm `J. Hyde et al. <https://doi.org/10.1557/PROC-650-R6.6>`_ +# are stored as an improper POS file: This is a matrix of floating +# point quadruplets, one for each ion and as many quadruplets as +# ions were investigated. The first three values encode the position +# of the ion. The fourth value is an improper mass-to-charge-state-ratio +# value which encodes the integer identifier of the cluster as a floating +# point number. +# +# +# +# +# +# +# Specifies if the tool should try to recover for each position the closest +# matching position from dataset/dataset_name_reconstruction (within +# floating point accuracy). This can be useful for instance when users +# wish to recover the original evaporation ID, which IVAS/AP Suite drops +# for instance when writing their *.indexed.* cluster results POS files. +# +# +# +# +# +# +# This process performs a cluster analysis on a reconstructed dataset +# or a portion of the reconstruction. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The tool enables to inject precomputed distance information for each +# point/ion which can be used for further post-processing and analysis. +# +# +# +# Name of an HDF5 file which contains the ion distances. +# +# +# +# Version identifier of the file such as a secure hash which documents +# the binary state of the file to add an additional layer of +# reproducibility from which file specifically contains these data. +# +# +# +# +# +# Absolute HDF5 path to the dataset with distance values for each ion. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# How should iontypes be interpreted/considered during the cluster analysis. +# Different options exist how iontypes are interpreted (if considered at all) +# given an iontype represents in general a (molecular) ion with different isotopes +# that have individually different multiplicity. +# +# The value resolve_all will set an ion active in the analysis +# regardless of which iontype it is. +# The value resolve_unknown will set an ion active when it is of the +# UNKNOWNTYPE. +# The value resolve_ion will set an ion active if it is of the +# specific iontype, irregardless of its elemental or isotopic details. +# The value resolve_element will set an ion active, and most importantly, +# account as many times for it, as the (molecular) ion contains +# atoms of elements in the whitelist ion_query_isotope_vector. +# The value resolve_isotope will set an ion active, and most importantly, +# account as many times for it, as the (molecular) ion contains isotopes +# in the whitelist ion_query_isotope_vector. +# +# In effect, ion_query_isotope_vector acts as a whitelist to filter +# which ions are considered as source ions of the correlation statistics +# and how the multiplicity of each ion will be factorized. +# +# This is relevant as in atom probe we have the situation that a ion +# of a molecular ion with more than one nuclid, say Ti O for example +# is counted such that although there is a single TiO molecular ion +# at a position that the cluster has two members. This multiplicity +# affects the size of the feature and chemical composition. +# +# +# +# +# +# +# +# +# Matrix of isotope vectors, as many as rows as different candidates +# for iontypes should be distinguished as possible source iontypes. +# In the simplest case, the matrix contains only the proton number +# of the element in the row, all other values set to zero. +# Combined with ion_query_type_source set to resolve_element this will +# recover usual spatial correlation statistics like the 1NN C-C +# spatial statistics. +# +# +# +# +# +# +# +# +# Settings for DBScan clustering algorithm. For original details about the +# algorithms and (performance-relevant) details consider: +# +# * `M. Ester et al. <https://dx.doi.org/10.5555/3001460.3001507>`_ +# * `M. Götz et al. <https://dx.doi.org/10.1145/2834892.2834894>`_ +# +# For details about how the DBScan algorithms is the key behind the +# specific modification known as the maximum-separation method in the +# atom probe community consider `E. Jägle et al. <https://dx.doi.org/10.1017/S1431927614013294>`_ +# +# +# +# Strategy how runs are performed with different parameter: +# +# * For tuple as many runs are performed as parameter values. +# * For combinatorics individual parameter arrays are looped over. +# +# As an example we may define eps with ten entries and min_pts with +# three entries. If high_throughput_method is tuple the analysis is +# invalid as we have an insufficient number of min_pts for the ten +# eps values. +# By contrast, for combinatorics paraprobe-clusterer will run three +# individual min_pts runs for each eps value, resulting in a total +# of 30 analyses. +# As an example the DBScan analysis reported in `M. Kühbach et al. <https://dx.doi.org/10.1038/s41524-020-00486-1>`_ +# would have defined an array of values np.linspace(0.2, 5.0, nums=241, endpoint=True) +# eps values, min_pts one, and high_throughput_method set to combinatorics. +# +# +# +# +# +# +# +# +# Array of epsilon (eps) parameter values. +# +# +# +# +# +# +# +# Array of minimum points (min_pts) parameter values. +# +# +# +# +# +# +# +# +# +# Settings for the OPTICS clustering algorithm. +# +# * `M. Ankerest et al. <https://dx.doi.org/10.1145/304181.304187>`_ +# +# +# +# Strategy how runs are performed with different parameter: +# +# * For tuple as many runs are performed as parameter values. +# * For combinatorics individual parameter arrays are looped over. +# +# See the explanation for the corresponding parameter for dbscan +# processes above-mentioned for further details. +# +# +# +# +# +# +# +# +# Array of minimum points (min_pts) parameter values. +# +# +# +# +# +# +# +# Array of maximum epsilon (eps) parameter values. +# +# +# +# +# +# +# +# +# Settings for the HPDBScan clustering algorithm. +# +# * L. McInnes et al. <https://dx.doi.org/10.21105/joss.00205>`_ +# * scikit-learn hdbscan library `<https://hdbscan.readthedocs.io/en/latest/how_hdbscan_works.html>`_ +# +# See also this documentation for details about the parameter. +# Here we use the terminology of the hdbscan documentation. +# +# +# +# Strategy how runs are performed with different parameter: +# +# * For tuple as many runs are performed as parameter values. +# * For combinatorics individual parameter arrays are looped over. +# +# See the explanation for the corresponding parameter for dbscan +# processes above-mentioned for further details. +# +# +# +# +# +# +# +# +# Array of min_cluster_size parameter values. +# +# +# +# +# +# +# +# Array of min_samples parameter values. +# +# +# +# +# +# +# +# Array of cluster_selection parameter values. +# +# +# +# +# +# +# +# Array of alpha parameter values. +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.yaml new file mode 100644 index 0000000000..3c19b4f50f --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.yaml @@ -0,0 +1,453 @@ +category: application +doc: | + Configuration/settings of a paraprobe-distancer software tool run. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXapm_paraprobe_config_distancer(NXobject): + (NXentry): + \@version: + doc: | + Version specifier of this application definition. + definition: + doc: | + Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_config_distancer] + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + time_stamp(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + analysis_identifier: + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: | + Possibility for leaving a free-text description about this analysis. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + number_of_processes(NX_UINT): + unit: NX_UNITLESS + doc: | + How many individual analyses should the tool execute. + (NXprocess): + dataset(NXapm_input_reconstruction): + filename: + \@version: + dataset_name_reconstruction: + dataset_name_mass_to_charge: + iontypes(NXapm_input_ranging): + filename: + \@version: + group_name_iontypes: + spatial_filter(NXspatial_filter): + exists: optional + windowing_method: + (NXcg_ellipsoid_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + half_axes_radii(NX_NUMBER): + orientation(NX_NUMBER): + (NXcg_cylinder_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + height(NX_NUMBER): + radii(NX_NUMBER): + (NXcg_hexahedron_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + hexahedra(NXcg_face_list_data_structure): + (NXcs_filter_boolean_mask): + exists: optional + number_of_objects(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + identifier(NX_UINT): + evaporation_id_filter(NXsubsampling_filter): + exists: optional + iontype_filter(NXmatch_filter): + exists: optional + hit_multiplicity_filter(NXmatch_filter): + exists: optional + point_to_triangle(NXprocess): + doc: | + Compute for all filtered points, e.g. ions of the point set + the shortest Euclidean distance to the closest triangle of the + set of triangles. The triangles can formed a closed surface mesh. + Distances are not simple distances based on normal projections but + giving an exact solution. + triangle_soup(NXprocess): + + # NEW ISSUE NXtriangle_soup + doc: | + Paraprobe-distancer enables the computation of the Euclidean shortest + distance for each member of a set of points against a set of triangles. + In contrast to comparable methods used in atom probe the here computed + distance is not simply the projected distance to one of the triangles + but the more costly but robust computation of the distance between + a point and a triangle. + + The triangles can represent for instance the facets of a triangulated + surface mesh of a model for the edge of the dataset. Such a model can + be computed with paraprobe-surfacer. Alternatively, the triangles can + be those from the set of all facets for a set of convex hulls, alpha-shapes, + or alpha wrappings about three-dimensional objects like precipitates + (computed with e.g. paraprobe-nanochem). + + Currently, the tool does not check if the respectively specified + triangle sets are consistent, what their topology is, or whether or + not they are consistently oriented. + Each dataset that is referred to in the list_of _dataset_names_vertices + should be an (Nvertices, 3) array of NX_FLOAT. Each dataset referred + to in the list_of_dataset_names_facet_indices should be an + (Nfacets, 3) array of NX_UINT. + Facet indices refer to vertex indices. These need to start at zero + and must not exceed Nvertices - 1, i.e. the identifier_offset is 0 + and vertices are indexed thus implicitly. + Facet normal vectors have to be also an array + of shape (Nfacets, 3) of NX_FLOAT. + number_of_files(NX_UINT): + unit: NX_UNITLESS + doc: | + How many triangle sets to consider. + (NXprocess): + doc: | + List of triangle sets. This design allows users to combine + multiple triangle sets. + filename: + doc: | + Name of the HDF5 file(s) which contain(s) vertex coordinates + and facet indices to describe the desired set of triangles. + \@version: + doc: | + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional + layer of reproducibility. + dataset_name_vertices: + doc: | + Absolute HDF5 path to the dataset which + specifies the array of vertex positions. + dataset_name_facet_indices: + doc: | + Absolute HDF5 path to the dataset which + specifies the array of facet indices. + dataset_name_facet_normals: + exists: optional + doc: | + Absolute HDF5 path to the dataset which + specifies the array of facet normal vectors. + method: + doc: | + Specifies for which ions/points the tool will compute distances. + The purpose of this setting is to avoid unnecessary computations + when the user requests to only compute distances of ions within a + threshold distance to the triangle soup. + + By default the distances are computed for all ions; however + the setting skin enables to compute distances only for those + ions which are not farther away located to a triangle + than threshold_distance. + enumeration: [default, skin] + threshold_distance(NX_FLOAT): + unit: NX_LENGTH + + ##MK::only required when method is skin + doc: | + Maximum distance for which distances are computed when method is skin. + + # \@units: nm + + # point_set_to_polyline_set(NXprocess): + # doc: | + # Compute the shortest Euclidean distance of all filtered points/ions + # of a point set to the closest point on the closest polyline. + # polyhedra_set_to_triangle_set(NXprocess): + # doc: | + # Compute the (shortest Euclidean) distance of all polyhedra of a set + performance(NXcs_profiling): + current_working_directory: + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 0259801d31681cbca8200fa0fc8f653a013001487c419770f15d735970553d91 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Configuration/settings of a paraprobe-distancer software tool run. +# +# +# +# +# Version specifier of this application definition. +# +# +# +# +# Official NeXus NXDL schema with which this file was written. +# +# +# +# +# +# +# +# Given name of the program/software/tool with which this NeXus +# (configuration) file was generated. +# +# +# +# Ideally program version plus build number, or commit hash or description +# of ever persistent resources where the source code of the program and +# build instructions can be found so that the program can be configured +# ideally in such a manner that the result of this computational process +# is recreatable in the same deterministic manner. +# +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when this configuration file was created. +# +# +# +# +# Ideally, a (globally persistent) unique identifier for referring +# to this analysis. +# +# +# +# +# Possibility for leaving a free-text description about this analysis. +# +# +# +# +# Path to the directory where the tool should store NeXus/HDF5 results +# of this analysis. If not specified results will be stored in the +# current working directory. +# +# +# +# +# How many individual analyses should the tool execute. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Compute for all filtered points, e.g. ions of the point set +# the shortest Euclidean distance to the closest triangle of the +# set of triangles. The triangles can formed a closed surface mesh. +# Distances are not simple distances based on normal projections but +# giving an exact solution. +# +# +# +# +# Paraprobe-distancer enables the computation of the Euclidean shortest +# distance for each member of a set of points against a set of triangles. +# In contrast to comparable methods used in atom probe the here computed +# distance is not simply the projected distance to one of the triangles +# but the more costly but robust computation of the distance between +# a point and a triangle. +# +# The triangles can represent for instance the facets of a triangulated +# surface mesh of a model for the edge of the dataset. Such a model can +# be computed with paraprobe-surfacer. Alternatively, the triangles can +# be those from the set of all facets for a set of convex hulls, alpha-shapes, +# or alpha wrappings about three-dimensional objects like precipitates +# (computed with e.g. paraprobe-nanochem). +# +# Currently, the tool does not check if the respectively specified +# triangle sets are consistent, what their topology is, or whether or +# not they are consistently oriented. +# Each dataset that is referred to in the list_of _dataset_names_vertices +# should be an (Nvertices, 3) array of NX_FLOAT. Each dataset referred +# to in the list_of_dataset_names_facet_indices should be an +# (Nfacets, 3) array of NX_UINT. +# Facet indices refer to vertex indices. These need to start at zero +# and must not exceed Nvertices - 1, i.e. the identifier_offset is 0 +# and vertices are indexed thus implicitly. +# Facet normal vectors have to be also an array +# of shape (Nfacets, 3) of NX_FLOAT. +# +# +# +# How many triangle sets to consider. +# +# +# +# +# List of triangle sets. This design allows users to combine +# multiple triangle sets. +# +# +# +# Name of the HDF5 file(s) which contain(s) vertex coordinates +# and facet indices to describe the desired set of triangles. +# +# +# +# Version identifier of the file such as a secure hash which +# documents the binary state of the file to add an additional +# layer of reproducibility. +# +# +# +# +# +# Absolute HDF5 path to the dataset which +# specifies the array of vertex positions. +# +# +# +# +# Absolute HDF5 path to the dataset which +# specifies the array of facet indices. +# +# +# +# +# Absolute HDF5 path to the dataset which +# specifies the array of facet normal vectors. +# +# +# +# +# +# +# Specifies for which ions/points the tool will compute distances. +# The purpose of this setting is to avoid unnecessary computations +# when the user requests to only compute distances of ions within a +# threshold distance to the triangle soup. +# +# By default the distances are computed for all ions; however +# the setting skin enables to compute distances only for those +# ions which are not farther away located to a triangle +# than threshold_distance. +# +# +# +# +# +# +# +# +# +# Maximum distance for which distances are computed when method is skin. +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.yaml new file mode 100644 index 0000000000..1455a60b9b --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.yaml @@ -0,0 +1,610 @@ +category: application +doc: | + Configuration of a paraprobe-intersector tool run in atom probe microscopy. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXapm_paraprobe_config_intersector(NXobject): + (NXentry): + + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + \@version: + doc: | + Version specifier of this application definition. + definition: + doc: | + Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_config_intersector] + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + analysis_identifier: + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: | + Possibility for leaving a free-text description about this analysis. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + time_stamp(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to + UTC information included when this configuration file was created. + number_of_processes(NX_UINT): + unit: NX_UNITLESS + doc: | + For now a support field for the tool to identify how many individual + analyses the tool should execute as part of the analysis. + VOLUME_VOLUME_SPATIAL_CORRELATION(NXprocess): + exists: ['min', '1', 'max', 'unbounded'] + doc: | + Tracking volume_volume_spatial_correlation is the process of building logical + relations between volumetric features based on meshes, their proximity and + eventual intersections. Volumetric overlap and proximity of volumetric + features is identified for members of sets of features to members of + other sets of volumetric features. + Specifically, for each time step k pairs of sets are compared: + Members of a so-called current_set to members of a so-called next_set. + Members can be different types of volumetric features. + In the analysis of M. Kuehbach et al. specifically features can be + so-called objects (closed non-degnerated polyhedra representing watertight + parts of an e.g. iso-surface) and/or proxies. Proxies are computed + doppelganger/replacement meshes for parts of an iso-surface which initially + were not resulting in watertight meshes because objects at the edge + of the dataset or incompletely measured or truncated objects. + intersection_detection_method: + doc: | + Specifies the method whereby to decide if two objects intersect volumetrically. + For reasons which are detailed in the supplementary material of + `M. Kühbach et al. `_, the tool by + default assumes that two objects intersect if they share at least one + ion with the same evaporation ID (shared_ion). + Alternatively, with specifying tetrahedra_intersections, + the tool can perform an intersection analysis which attempts to + tetrahedralize first each polyhedron. If successful, the tool then checks + for at least one pair of intersecting tetrahedra to identify if two objects + intersect or not. + + However, we found that these geometrical analyses can result in corner + cases which the currently used library (TetGen) was not unable to + tetrahedralize successfully. These cases were virtually always + associated with complicated non-convex polyhedra which had portions + of the mesh that were connected by almost point like tubes of triangles. + Finding more robust methods for computing intersections between + not necessarily convex polyhedra might improve the situation in the future. + enumeration: [shared_ion] + analyze_intersection(NX_BOOLEAN): + doc: | + Specifies if the tool evaluates if for each pair the two objects + (and proxies if used) intersect volumetrically. + analyze_proximity(NX_BOOLEAN): + doc: | + Specifies if the tool evaluates if for each pair the two objects + (and proxies if used) lie closer to one another than the + threshold_proximity. + analyze_coprecipitation(NX_BOOLEAN): + doc: | + Specifies if the tool evaluates, ones all tracking tasks were + successfully completed, how intersecting or proximity related + objects build sub-graphs. This is the feature which enabled + M. Kühbach et al. 2022 the high-throughput analyses of how many + objects are coprecipitates in the sense that they are single, + duplet, triplet, or high-order. For these analyses to work + has_object_volume needs to be activated. + threshold_proximity(NX_FLOAT): + unit: NX_LENGTH + doc: | + The maximum Euclidean distance between two objects below which + both objects are still considered within proximity. + + # \@units: nm + has_current_to_next_links(NX_BOOLEAN): + doc: | + Specifies if the tool stores the so-called forward relations between + nodes representing members of the current_set to nodes representing + members of the next_set. + has_next_to_current_links(NX_BOOLEAN): + doc: | + Specifies if the tool stores the so-called backward relations between + nodes representing members of the next_set to nodes representing + members of the current_set. + current_set(NXprocess): + doc: | + Current set stores a set of members, meshes of volumetric features, + which will be checked for proximity and/or volumetric intersection, + to members of the current_set. + The meshes were generated as a result of some other meshing process. + set_identifier(NX_UINT): + unit: NX_ANY + doc: | + This identifier can be used to label the current set. The label + effectively represents (can be interpreted as) the time/iteration + step when the current set was taken. As it is detailed in `M. Kühbach + et al. 2022 `_, this identifier + takes the role of the time variable :math:`k`. + + # number_of_objects(NX_UINT): + # doc: For now a support field to tell the tool how many objects to load. + # unit: NX_UNITLESS + number_of_feature_types(NX_UINT): + unit: NX_UNITLESS + doc: | + The total number of distinguished feature sets FEATURE. + It is assumed that the members within all these FEATURE sets + are representing a set together. As an example this set might represent + all volumetric_features. However, users might have formed + a subset of this set where individuals were regrouped. + For paraprobe-nanochem this is the case for objects and proxies. + Specifically, objects are distinguished further into those far + from and those close to the edge of the dataset. + Similarly, proxies are distinguished further into those far + from and those close to the edge of the dataset. + So while these four sub-sets contain different so-called types of + features key is that they were all generated for one set, here the + current_set. + FEATURE(NXcollection): + exists: ['min', '1', 'max', '4'] + feature_type: + doc: | + Descriptive category explaining what these features are. + enumeration: [objects_far_from_edge, objects_close_to_edge, proxies_far_from_edge, proxies_close_to_edge] + filename: + doc: | + Name of the (NeXus)/HDF5 file which contains triangulated + surface meshes of the members of the set as instances of + NXcg_polyhedron_set. + + # NEW ISSUE: make more robust checks wrt to the consistence of the datasets + \@version: + doc: | + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + groupname_geometry_prefix: + doc: | + String whereby the path to the geometry data can be interferred automatically. + Currently groupname_geometry_prefix/object/polyhedron. + feature_identifier(NX_UINT): + unit: NX_UNITLESS + doc: | + Array of identifier whereby the path to the geometry data + can be interferred automatically. + dimensions: + rank: 1 + dim: [[1, i]] + next_set(NXcollection): + doc: | + Next set stores a set of members, meshes of volumetric features, + which will be checked for proximity and/or volumetric intersection, + to members of the next_set. + The meshes were generated as a result of some other meshing process. + set_identifier(NX_UINT): + unit: NX_ANY + doc: | + This identifier can be used to label the next_set. The label + effectively represents (can be interpreted as) the time/iteration + step when the current set was taken. As it is detailed in `M. Kühbach + et al. 2022 `_, this identifier + takes the role of the time variable :math:`k + 1`. + + # number_of_objects(NX_UINT): + # doc: For now a support field to tell the tool how many objects to load. + # unit: NX_UNITLESS + number_of_feature_types(NX_UINT): + unit: NX_UNITLESS + doc: | + The total number of distinguished feature sets FEATURE. + It is assumed that the members within all these FEATURE sets + are representing a set together. As an example this set might represent + all volumetric_features. However, users might have formed + a subset of this set where individuals were regrouped. + For paraprobe-nanochem this is the case for objects and proxies. + Specifically, objects are distinguished further into those far + from and those close to the edge of the dataset. + Similarly, proxies are distinguished further into those far + from and those close to the edge of the dataset. + So while these four sub-sets contain different so-called types of + features key is that they were all generated for one set, here the + next_set. + FEATURE(NXcollection): + exists: ['min', '1', 'max', '4'] + feature_type: + doc: | + Descriptive category explaining what these features are. + enumeration: [objects_far_from_edge, objects_close_to_edge, proxies_far_from_edge, proxies_close_to_edge] + filename: + doc: | + Name of the (NeXus)/HDF5 file which contains triangulated + surface meshes of the members of the set as instances of + NXcg_polyhedron_set. + + # NEW ISSUE: make more robust checks wrt to the consistence of the datasets + \@version: + doc: | + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + groupname_geometry_prefix: + doc: | + String whereby the path to the geometry data can be interferred automatically. + Currently groupname_geometry_prefix/object/polyhedron. + feature_identifier(NX_UINT): + unit: NX_UNITLESS + doc: | + Array of identifier whereby the path to the geometry data + can be interferred automatically. + dimensions: + rank: 1 + dim: [[1, j]] + + ##MK::tetrahedra volume intersection and tessellation, and Nef polyhedra intersection + ##MK::are considered guru features and therefore currently supported via modifying the C/C++ source code + performance(NXcs_profiling): + current_working_directory: + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 71b282f148e5f311dd9a3f3e1cc87d973706430edb00a844eb901dd5b8812aba +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Configuration of a paraprobe-intersector tool run in atom probe microscopy. +# +# +# +# +# +# Version specifier of this application definition. +# +# +# +# +# Official NeXus NXDL schema with which this file was written. +# +# +# +# +# +# +# +# Given name of the program/software/tool with which this NeXus +# (configuration) file was generated. +# +# +# +# Ideally program version plus build number, or commit hash or description +# of ever persistent resources where the source code of the program and +# build instructions can be found so that the program can be configured +# ideally in such a manner that the result of this computational process +# is recreatable in the same deterministic manner. +# +# +# +# +# +# Ideally, a (globally persistent) unique identifier for referring +# to this analysis. +# +# +# +# +# Possibility for leaving a free-text description about this analysis. +# +# +# +# +# Path to the directory where the tool should store NeXus/HDF5 results +# of this analysis. If not specified results will be stored in the +# current working directory. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to +# UTC information included when this configuration file was created. +# +# +# +# +# For now a support field for the tool to identify how many individual +# analyses the tool should execute as part of the analysis. +# +# +# +# +# Tracking volume_volume_spatial_correlation is the process of building logical +# relations between volumetric features based on meshes, their proximity and +# eventual intersections. Volumetric overlap and proximity of volumetric +# features is identified for members of sets of features to members of +# other sets of volumetric features. +# Specifically, for each time step k pairs of sets are compared: +# Members of a so-called current_set to members of a so-called next_set. +# Members can be different types of volumetric features. +# In the analysis of M. Kuehbach et al. specifically features can be +# so-called objects (closed non-degnerated polyhedra representing watertight +# parts of an e.g. iso-surface) and/or proxies. Proxies are computed +# doppelganger/replacement meshes for parts of an iso-surface which initially +# were not resulting in watertight meshes because objects at the edge +# of the dataset or incompletely measured or truncated objects. +# +# +# +# Specifies the method whereby to decide if two objects intersect volumetrically. +# For reasons which are detailed in the supplementary material of +# `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_, the tool by +# default assumes that two objects intersect if they share at least one +# ion with the same evaporation ID (shared_ion). +# Alternatively, with specifying tetrahedra_intersections, +# the tool can perform an intersection analysis which attempts to +# tetrahedralize first each polyhedron. If successful, the tool then checks +# for at least one pair of intersecting tetrahedra to identify if two objects +# intersect or not. +# +# However, we found that these geometrical analyses can result in corner +# cases which the currently used library (TetGen) was not unable to +# tetrahedralize successfully. These cases were virtually always +# associated with complicated non-convex polyhedra which had portions +# of the mesh that were connected by almost point like tubes of triangles. +# Finding more robust methods for computing intersections between +# not necessarily convex polyhedra might improve the situation in the future. +# +# +# +# +# +# +# +# Specifies if the tool evaluates if for each pair the two objects +# (and proxies if used) intersect volumetrically. +# +# +# +# +# Specifies if the tool evaluates if for each pair the two objects +# (and proxies if used) lie closer to one another than the +# threshold_proximity. +# +# +# +# +# Specifies if the tool evaluates, ones all tracking tasks were +# successfully completed, how intersecting or proximity related +# objects build sub-graphs. This is the feature which enabled +# M. Kühbach et al. 2022 the high-throughput analyses of how many +# objects are coprecipitates in the sense that they are single, +# duplet, triplet, or high-order. For these analyses to work +# has_object_volume needs to be activated. +# +# +# +# +# The maximum Euclidean distance between two objects below which +# both objects are still considered within proximity. +# +# +# +# +# +# Specifies if the tool stores the so-called forward relations between +# nodes representing members of the current_set to nodes representing +# members of the next_set. +# +# +# +# +# Specifies if the tool stores the so-called backward relations between +# nodes representing members of the next_set to nodes representing +# members of the current_set. +# +# +# +# +# Current set stores a set of members, meshes of volumetric features, +# which will be checked for proximity and/or volumetric intersection, +# to members of the current_set. +# The meshes were generated as a result of some other meshing process. +# +# +# +# This identifier can be used to label the current set. The label +# effectively represents (can be interpreted as) the time/iteration +# step when the current set was taken. As it is detailed in `M. Kühbach +# et al. 2022 <https://arxiv.org/abs/2205.13510>`_, this identifier +# takes the role of the time variable :math:`k`. +# +# +# +# +# +# The total number of distinguished feature sets FEATURE. +# It is assumed that the members within all these FEATURE sets +# are representing a set together. As an example this set might represent +# all volumetric_features. However, users might have formed +# a subset of this set where individuals were regrouped. +# For paraprobe-nanochem this is the case for objects and proxies. +# Specifically, objects are distinguished further into those far +# from and those close to the edge of the dataset. +# Similarly, proxies are distinguished further into those far +# from and those close to the edge of the dataset. +# So while these four sub-sets contain different so-called types of +# features key is that they were all generated for one set, here the +# current_set. +# +# +# +# +# +# Descriptive category explaining what these features are. +# +# +# +# +# +# +# +# +# +# +# Name of the (NeXus)/HDF5 file which contains triangulated +# surface meshes of the members of the set as instances of +# NXcg_polyhedron_set. +# +# +# +# +# Version identifier of the file such as a secure hash which documents +# the binary state of the file to add an additional layer of +# reproducibility from which file specifically contains these data. +# +# +# +# +# +# String whereby the path to the geometry data can be interferred automatically. +# Currently groupname_geometry_prefix/object<ID>/polyhedron. +# +# +# +# +# Array of identifier whereby the path to the geometry data +# can be interferred automatically. +# +# +# +# +# +# +# +# +# +# Next set stores a set of members, meshes of volumetric features, +# which will be checked for proximity and/or volumetric intersection, +# to members of the next_set. +# The meshes were generated as a result of some other meshing process. +# +# +# +# This identifier can be used to label the next_set. The label +# effectively represents (can be interpreted as) the time/iteration +# step when the current set was taken. As it is detailed in `M. Kühbach +# et al. 2022 <https://arxiv.org/abs/2205.13510>`_, this identifier +# takes the role of the time variable :math:`k + 1`. +# +# +# +# +# +# The total number of distinguished feature sets FEATURE. +# It is assumed that the members within all these FEATURE sets +# are representing a set together. As an example this set might represent +# all volumetric_features. However, users might have formed +# a subset of this set where individuals were regrouped. +# For paraprobe-nanochem this is the case for objects and proxies. +# Specifically, objects are distinguished further into those far +# from and those close to the edge of the dataset. +# Similarly, proxies are distinguished further into those far +# from and those close to the edge of the dataset. +# So while these four sub-sets contain different so-called types of +# features key is that they were all generated for one set, here the +# next_set. +# +# +# +# +# +# Descriptive category explaining what these features are. +# +# +# +# +# +# +# +# +# +# +# Name of the (NeXus)/HDF5 file which contains triangulated +# surface meshes of the members of the set as instances of +# NXcg_polyhedron_set. +# +# +# +# +# Version identifier of the file such as a secure hash which documents +# the binary state of the file to add an additional layer of +# reproducibility from which file specifically contains these data. +# +# +# +# +# +# String whereby the path to the geometry data can be interferred automatically. +# Currently groupname_geometry_prefix/object<ID>/polyhedron. +# +# +# +# +# Array of identifier whereby the path to the geometry data +# can be interferred automatically. +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml new file mode 100644 index 0000000000..07fab0a79e --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml @@ -0,0 +1,2048 @@ +category: application +doc: | + Configuration of a paraprobe-nanochem tool run in atom probe microscopy. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_ityp_deloc_cand: | + How many iontypes does the delocalization filter specify. + n_control_pts: | + How many disjoint control points are defined. + n_fct_filter_cand: | + How many iontypes does the interface meshing iontype filter specify. + n_fct_iterations: | + How many DCOM iterations. + n_ivec: | + Maximum number of atoms per molecular ion. +type: group +NXapm_paraprobe_config_nanochem(NXobject): + (NXentry): + \@version: + doc: | + Version specifier of this application definition. + definition: + doc: | + Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_config_nanochem] + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + analysis_identifier: + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: | + Possibility for leaving a free-text description about this analysis. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + time_stamp(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to + UTC information included when this configuration file was created. + number_of_processes(NX_UINT): + unit: NX_UNITLESS + doc: | + How many individual analyses should the tool execute as part of the analysis. + (NXprocess): + dataset(NXapm_input_reconstruction): + filename: + \@version: + dataset_name_reconstruction: + dataset_name_mass_to_charge: + iontypes(NXapm_input_ranging): + filename: + \@version: + group_name_iontypes: + spatial_filter(NXspatial_filter): + exists: optional + windowing_method: + (NXcg_ellipsoid_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + half_axes_radii(NX_NUMBER): + orientation(NX_NUMBER): + (NXcg_cylinder_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + height(NX_NUMBER): + radii(NX_NUMBER): + (NXcg_hexahedron_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + hexahedra(NXcg_face_list_data_structure): + (NXcs_filter_boolean_mask): + exists: optional + number_of_objects(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + identifier(NX_UINT): + evaporation_id_filter(NXsubsampling_filter): + exists: optional + iontype_filter(NXmatch_filter): + exists: optional + method: + match(NX_NUMBER): + hit_multiplicity_filter(NXmatch_filter): + exists: optional + edge_of_the_dataset(NXprocess): + doc: | + The tool enables to inject a previously computed triangle soup or + triangulated surface mesh representing a model (of the surface) of + the edge of the dataset. This model can be used to detect and control + various sources of bias in the analyses. + + # NEW ISSUE: exists: optional + filename: + doc: | + Name of the HDF5 file which contains vertex coordinates and facet + indices to describe the desired set of triangles which represents + the edge of the dataset. + \@version: + doc: | + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + dataset_name_vertices: + doc: | + Absolute path to the HDF5 dataset in the respectively specified HDF5 + file under filename which details the array of vertex positions. + dataset_name_facet_indices: + doc: | + Absolute path to the HDF5 dataset in the respective specified HDF5 + file under filename which details the array of facet indices. + ion_to_edge_distances(NXprocess): + exists: optional + doc: | + The tool enables to inject precomputed distance information for each + point/ion which can be used for further post-processing and analysis. + + # NEW ISSUE: is this optional? + filename: + doc: | + Name of an HDF5 file which contains the ion distances. + \@version: + doc: | + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + dataset_name: + doc: | + Absolute HDF5 path to the dataset with distance values for each ion. + + # number_of_delocalizations(NX_UINT): + # doc: | + # For now a support field for the tool to identify how many individual + # delocalization analyses for the above-mentioned dataset and supplementary + # files are executed as part of the high-throughput analysis. + # unit: NX_UNITLESS + + # NEW ISSUE delocalization is all lower case meaning you cannot have right now multiple of these + # even though paraprobe-nanochem triggers a number of delocalizations for each of which triggering again isosurfaces + # currently the principal idea behind this design is that you normally focus iso-surface-based analyses + # on specific elements and for these you may have different discretization and isosurface computation demands + # for instance you might be super interested in analyzing in find details the iso-surfaces of carbon in a dataset + # but in addition you could be interested also to study chromium iso-surfaces but for completely different iso-contour values + # etc. this is what paraprobe-nanochem allows you to do + # you create one process for all your carbon related delocalizations, isosurfaces etc + # plus another process packing all your chromium delocalization and isosurfaces + delocalization(NXprocess): + exists: ['min', '0', 'max', '1'] + doc: | + Discretization of the ion point cloud on a three-dimensional grid. + input: + doc: | + Delocalization in the field of atom probe microscopy is the process + of discretizing a point cloud. By default the tool computes a full + kernel density estimation of decomposed ions to create one discretized + field for each element. + + Although, this uses an efficient multithreaded algorithm, + the computation is costly. Therefore, it can be advantageous for users + to load an already computed delocalization. This can be achieved with + the load_existent option. + When using this option the user is responsible to assure that the + settings which were used for computing this already existent delocalization + are specified in the same manner as they were. + + # NEW ISSUE: improve UX experience + enumeration: [default, load_existent] + + # NEW ISSUE: base class filter + isotope_whitelist(NX_UINT): + unit: NX_UNITLESS + doc: | + Matrix of isotope vectors representing iontypes. + The filter specifies a matrix of isotope_vectors which is the most + general approach to define if and how many times an ion is counted. + Currently, paraprobe_nanochem performs a so-called atomic decomposition + of all iontypes. Specifically, the tool interprets of how many + elements/atoms a molecular ion is composed; and thus determines the + atoms multiplicity with respect to the iontype. + + Let's take the hydroxonium H3O+ molecular ion as an example: + It contains hydrogen and oxygen as atoms. The multiplicity of hydrogen + is three whereas that of oxygen is one. Therefore in an atomic + decomposition computation of the iso-surface each H3O+ ion adds + three hydrogen counts. This is a practical solution which accepts + the situation that during an atom probe experiment not each bond + of each ion/a group of neighboring atoms is broken but molecular + ions get detected. The exact ab-initio details depend on the local + field conditions and thus also the detailed spatial arrangement + of the atoms and their own electronic state and that of the neighbors + before and upon launch. + Being able to measure the information for such sites only as + molecular ions causes an inherent information loss with respect to the + detailed spatial arrangement. This information loss is more relevant + for local electrode atom probe than for field ion microscopy setting + how precisely the atomic positions can be reconstructed. + Accounting for multiplicities assures that at least the + compositional information is analyzed. + dimensions: + rank: 2 + dim: [[1, n_ityp_deloc_cand], [2, n_ivec]] + gridresolutions(NX_FLOAT): + unit: NX_LENGTH + doc: | + List of individual grid resolutions to analyse. + Paraprobe discretizes on a cuboidal 3D grid with cubic cells, with + an edge length of values in gridresolutions. + + # \@units: nm + kernel_size(NX_UINT): + unit: NX_UNITLESS + doc: | + Half the width of a :math:`{(2 \cdot n + 1)}^3` cubic kernel of voxel + beyond which the Gaussian Ansatz function will be truncated. + Intensity beyond the kernel is refactored into the kernel via + a normalization procedure. + kernel_variance(NX_FLOAT): + unit: NX_LENGTH + doc: | + Variance of the Gaussian Ansatz kernel :math:`\sigma_x = \sigma_y = 2 \cdot + \sigma_z`. + + # \@units: nm + normalization: + doc: | + How should the results of the kernel-density estimation be computed + into quantities. By default the tool computes the total number + (intensity) of ions or elements. Alternatively the tool can compute + the total intensity, the composition, or the concentration of the + ions/elements specified by the white list of elements in each voxel. + enumeration: [total, candidates, composition, concentration] + has_scalar_fields(NX_BOOLEAN): + doc: | + Specifies if the tool should report the delocalization 3D field values. + + # number_of_isosurfaces: + # doc: For now a support field for the tool to identify how many individual analyses the tool should execute during the analysis run. + # unit: NX_UNITLESS + + # NEW ISSUE: currently isosurface has to be a child of delocalization because otherwise + # you could construct the incorrect situation that you leave delocalization optional do not add sth there but fill isosurface + # and this does not work because without a delocalization/field quantity you cannot compute iso-surfaces + isosurfacing(NXprocess): + exists: ['min', '0', 'max', '1'] + doc: | + Optional computation of iso-surfaces after each computed delocalization + to identify for instance objects in the microstructure + (line features, interfaces, precipitates). + edge_handling_method: + doc: | + As it is detailed in M. Kühbach et al. 2022 npj Comp. Mat., + the handling of triangles at the edge of the dataset requires + special attention. Especially for composition-normalized + delocalization it is possible that the composition increases + towards the edge of the dataset because the quotient of two numbers + which are both smaller than one is larger instead of smaller than + the counter. By default, the tool uses a modified marching cubes + algorithm of Lewiner et al. which detects if voxels face such a + situation. In this case, no triangles are generated for such voxels. + Alternatively, (via setting keep_edge_triangles) the user can + instruct the tool to not remove these triangles at the cost of bias. + + Specifically, in this case the user should understand that all + objects/microstructural features in contact with the edge of the + dataset get usually artificial enlarged and their surface mesh + often closed during the marching. This closure however is artificial! + It can result in biased shape analyses for those objects. + The reason why this should in general be avoided is a similar + argument as when one analyzes grain shapes in orientation microscopy + via e.g. SEM/EBSD. Namely, these grains, here the objects at the + edge of the dataset, were not fully captured during e.g. limited + field of view. + Therefore, it is questionable if one would like to make + substantiated quantitative statements about them. + + Thanks to collaboration with the V. V. Rielli and S. Primig, though, + paraprobe-nanochem implements a complete pipeline to + process even these objects at the edge of the dataset. Specifically, + the objects are replaced by so-called proxies, i.e. replacement + objects whose holes on the surface mesh have been closed if possible + via iterative mesh and hole-filling procedures with fairing operations. + In the results of each paraprobe-nanochem run, these proxy objects + are listed separately to allow users to quantify and analyze in + detail the differences when accounting for these objects or not. + Especially this is relevant in atom probe microscopy as objects + can contain a few dozen atoms only. + Users should be aware that results from fairing operations should + be compared to results from analyses where all objects at the edge + of the dataset have been removed. + + Also users should be careful with overestimating the statistical + significance of their dataset especially when using atom probe + to compare multiple descriptors: Even though a dataset may give + statistically significant results for compositions, this does not + necessarily mean it will yield also statistically significant + and unbiased results for three-dimensional object analyses. + Being able to quantify these effects and making atom probers + aware of these subtleties was one of the main reasons why the + paraprobe-nanochem tool was implemented. + enumeration: [default, keep_edge_triangles] + edge_threshold(NX_FLOAT): + unit: NX_LENGTH + doc: | + The ion-to-edge-distance that is used in the analyses of objects + (and proxies) to identify whether these are inside the dataset or + close to the edge of the dataset. If an object has at least one ion + with an ion-to-edge-distance below this threshold, the object is + considered as one which lies close to the edge of the dataset. + This implements essentially a distance-based approach to solve + the in general complicated and involved treatment of computing + volumetric intersections between not-necessarily convex + closed 2-manifolds. In fact, such computational geometry analyses + can face numerical robustness issues as a consequence of which a + mesh can be detected as lying completely inside a dataset although + in reality it is epsilon-close only, i.e. almost touching only + the edge (e.g. from inside). + Practically, humans would state in such case that the object is + close to the edge of the dataset; however mathematically the object + is indeed completely inside. + In short, a distance-based approach is rigorous and more flexible. + + # \@units: nm + phi(NX_FLOAT): + unit: NX_ANY + doc: | + Array of iso-contour values. For each value the tool computes + an iso-surface and performs subsequent analyses. + The unit depends on the choice for the normalization of the + accumulated ion intensity values per voxel: + + * total, total number of ions, irrespective their iontype + * candidates, total number of ions with type in the isotope_whitelist. + * composition, candidates but normalized by composition, i.e. at.-% + * concentration, candidates but normalized by voxel volume, i.e. ions/nm^3 + + # NEW ISSUE: details what these options activate need to be described in more detail !!!!! + has_triangle_soup(NX_BOOLEAN): + doc: | + Specifies if the tool should report the triangle soup which represents + each triangle of the iso-surface complex. + Each triangle is reported with an ID specifying to which triangle + cluster (with IDs starting at zero) the triangle belongs. + The clustering is performed with a modified DBScan algorithm. + has_object(NX_BOOLEAN): + doc: | + Specifies if the tool should analyze for each cluster of triangles + how they can be combinatorially processed to describe a closed + polyhedron. Such a closed polyhedron (not-necessarily convex!) + can be used to describe objects with relevance in the microstructure. + Users should be aware that the resulting mesh does not necessarily + represent the original precipitate. In fact, inaccuracies in the + reconstructed positions cause inaccuracies in all downstream + processing operations. Especially the effect on one-dimensional + spatial statistics like nearest neighbor correlation functions these + effects were discussed in the literature + `B. Gault et al. `_ + In continuation of these thoughts this applies also to reconstructed + objects. A well-known example is the discussion of shape deviations + of Al3Sc precipitates in aluminium alloys which in reconstructions + can appear as ellipsoids although they should be almost spherical, + depending on their size. + has_object_geometry(NX_BOOLEAN): + doc: | + Specifies if the tool should report a triangulated surface mesh + for each identified closed polyhedron. It is common that a + marching cubes algorithm creates iso-surfaces with a fraction of very + small sub-complexes (e.g. small isolated tetrahedra). + + These can be for instance be small tetrahedra/polyhedra about the + center of a voxel of the support grid on which marching cubes operates. + When these objects are small, it is possible that they contain no ion; + especially when considering that delocalization procedures smoothen + the positions of the ions. Although these small objects are interesting + from a numerical point of view, scientists may argue they are not worth + to be reported: + Physically a microstructural feature should contain at least a few + atoms to become relevant. Therefore, paraprobe-nanochem by default + does not report closed objects which bound not at least one ion. + has_object_properties(NX_BOOLEAN): + doc: | + Specifies if the tool should report properties of each closed + polyhedron, such as volume and other details. + has_object_obb(NX_BOOLEAN): + doc: | + Specifies if the tool should report for each closed polyhedron an + approximately optimal bounding box fitted to all triangles of the + surface mesh of the object and ion positions inside or on the + surface of the mesh. + This bounding box informs about the closed object's shape + (aspect ratios). + + # NEW ISSUE: Addendum Alternatively it is possible to fit triaxial ellipsoids. + has_object_ions(NX_BOOLEAN): + doc: | + Specifies if the tool should report for each closed polyhedron + all evaporation IDs of those ions which lie inside or on the + boundary of the polyhedron. This information can be used e.g. + in the paraprobe-intersector tool to infer if two objects share + common ions, which can be interpreted as an argument to assume + that the two objects intersect. + + Users should be aware that two arbitrarily closed polyhedra + in three-dimensional space can intersect but not share a common ion. + In fact, the volume bounded by the polyhedron has sharp edges. + When taking two objects, an edge of one object may for instance + pierce into the surface of another object. In this case the + objects partially overlap / intersect volumetrically; + however this piercing might be so small or happening in the volume + between two ion positions and thus sharing ions is a sufficient + but not a necessary condition for object intersections. + + Paraprobe-intersector implements a rigorous alternative to handle + such intersections using a tetrahedralization of closed objects. + However, in many practical cases, we found through examples that there + are polyhedra (especially when they are non-convex and have almost + point-like) connected channels, where tetrahedralization libraries + have challenges dealing with. In this case checking intersections + via shared_ions is a more practical alternative. + has_object_edge_contact(NX_BOOLEAN): + doc: | + Specifies if the tool should report if a (closed) object has + contact with the edge of the dataset. For this the tool currently + inspects if the shortest distance between the set of triangles of the + surface mesh and the triangles of the edge model is larger than the + edge_threshold. If this is the case, the object is assumed to be + deeply embedded in the interior of the dataset. Otherwise, the object + is considered to have an edge contact, i.e. it is likely affected + by the fact that the dataset is finite. + + # the edge_threshold can be decided based on half the length of the diagonal of the delocalization kernel. + # as a consequence of which wider kernels result in larger threshold values causing more objects to become + # qualified as having edge contact. + has_proxy(NX_BOOLEAN): + doc: | + Specifies if the tool should analyze a doppelganger/proxy mesh for + each cluster of triangles whose combinatorial analysis according + to has_object showed that the object is not a closed polyhedron. + Such proxies are closed via iterative hole-filling, mesh refinement, + and fairing operations. + Users should be aware that the resulting mesh does not necessarily + represent the original precipitate. In most cases objects, + like precipitates in atom probe end up as open objects because + they have been clipped by the edge of the dataset. Using a proxy is + then a strategy to still be able to account for these objects. + Nevertheless users should make themselves familiar with the + potential consequences and biases which this can introduce + into the analysis. + has_proxy_geometry(NX_BOOLEAN): + doc: | + Like has_object_geometry but for the proxies. + has_proxy_properties(NX_BOOLEAN): + doc: | + Like has_object_properties but for the proxies. + has_proxy_obb(NX_BOOLEAN): + doc: | + Like has_object_obb but for the proxies. + has_proxy_ions(NX_BOOLEAN): + doc: | + Like has_object_ions but for the proxies. + has_proxy_edge_contact(NX_BOOLEAN): + doc: | + Like has_object_edge_contact but for the proxies. + has_object_auto_proxigram(NX_BOOLEAN): + doc: | + Specifies if the tool should report for each closed object a + (cylindrical) region of interest placed, centered, and align + with the local normal for each triangle of the object. + has_object_auto_proxigram_edge_contact(NX_BOOLEAN): + doc: | + Specifies if the tool should report for each ROI that was placed + at a triangle of each object if this ROI intersects the edge of + the dataset. Currently paraprobe-nanochem supports cylindrical + ROIs. A possible intersection of these with the edge of the + dataset, i.e. the triangulated surface mesh model for the edge + is performed. This test checks if the cylinder intersects with + a triangle of the surface mesh. If this is the case, the ROI is + assumed to make edge contact, else, the ROI is assumed to have + no edge contact. + + This approach does not work if the ROI would be completely + outside the dataset. Also in this case there would be + no intersection. For atom probe this case is practically + irrelevant because for such a ROI there would also be no ion + laying inside the ROI. Clearly it has thus to be assumed that + the edge model culls the entire dataset. Instead, if one would + cut a portion of the dataset, compute an edge model for this + point cloud, it might make sense to place a ROI but in this + case the edge contact detection is not expected to work properly. + + # has_object_mesh_smoothing(NX_BOOLEAN): + # doc: Specifies if the tool should post-process each mesh to improve the mesh quality. + # mesh_smoothing(NXprocess): + # NEW ISSUE: here we need to specify how the meshes were smoothened + ##MK::is this group not at the previous level of the hierarchy? + interfacial_excess(NXprocess): + exists: optional + doc: | + Analyses of interfacial excess. + interface_model: + doc: | + Interfacial excess computations are performed for local regions-of-interests + (ROIs) at selected facets or interface patch. + For instance many scientist compute the interfacial excess for + selected triangle facets of a created iso-surface. In this case, + computed iso-surfaces of paraprobe could be used. An example are triangle + facet sets about closed polyhedra, for instance to compute interfacial + excess related to phase boundaries of second-phase precipitates. + + Another example are free-standing triangle patches of the iso- + surfaces which paraprobe creates. These could be characterized + for interfacial excess. The sub-routines during iso-surface + computations already include a procedure to automatically align + local triangle normals based on the gradients of e.g. composition + fields. In this case, these triangulated surface patches + could also be used as a source for computing interfacial + excess. + + Often scientists face situations, though, in which there is no + immediately evident composition gradient across the interface + (grain or phase boundary) and orientation information about the + adjoining crystal is neither available nor reliable enough. + + In this case `P. Felfer et al. `_ proposed a method + to manually place control points and run an automated tessellation-based + algorithm to create a triangulated surface patch, i.e. a model of the + location of the interface. In a post-processing step this triangle + set can then be used to compute again interfacial excess in an + automated manner by placing ROIs and aligning them with + consistently precomputed triangle normals. + + A similar use case is conceptually the one proposed by `X. Zhou et al. `_ + They used first a deep-learning method to locate planar triangulated + grain boundary patches. These are eventually processed further + with manual editing of the mesh via tools like Blender. + Once the user is satisfied with the mesh, the computations of interfacial + excess reduce again to an automated placing of ROIs, computations + of the distributing of ions to respective ROIs and + reporting the findings via plotting. + + Yet another approach for constructing an triangulated surface patch + of an interface is to use point cloud processing methods which have + been proposed in the laser-scanning, geoinformatics, and CAD community. + Different computational geometry methods are available for fitting + a parameterized surface to a set of points, using e.g. non-uniform + rational B-splines (NURBS) and triangulating these according + to prescribed mesh quality demands. + + The advantage of these methods is that they can be automated and + pick up curved interface segments. The disadvantage is their often + strong sensitivity to parameterization. As a result also such methods + can be post-processed to yield a triangulated surface patch, + and thus enable to run again automated ROI placement methods. + For example like these which were explored for the use case of + iso-surfaces with closed objects and free-standing + surface patches that delineate regions of the dataset with a + pronounced composition gradient normal to the interface. + + This summary of the situations which atom probers can face when + requesting for interfacial excess computations, substantiates there + exists a common set of settings which can describe all of these methods + and, specifically, as here exemplified, the automated placing + and alignment functionalities for ROIs that is an important + step all these workflows. + + Specifically, paraprobe-nanochem operates on an already existent + triangle set. + enumeration: [isosurface, external] + + # NEW ISSUE: how to implement and also check consistently via NeXus that a + # NEW ISSUE: child group is required only when a field has a certain value? + external(NXprocess): + exists: optional + doc: | + The interface model is the result of a previous (set of) processing + steps as a result of which the user has created a triangulated + surface mesh (or a set of, eventually connected such meshes). + These interface models are useful, if not required, in cases when + there is no other independent approach to locate an interface. + + These are cases when insufficient crystallographic latent + information is available and also no consistent concentration + gradient detectable across the interface. It is then the users' + responsibility to deliver a triangle mesh of the interface model. + file_name: + doc: | + Filename to HDF5 file which contain vertex coordinates, facet indices, + facet unit normals. The user is responsible for the triangle + and winding order to be consistent. + Input is expected as a matrix of the coordinates for all disjoint + vertices, a (Nvertices, 3)-shaped array of NX_FLOAT. + Input is expected to include also a matrix of facet indices + referring to these disjoint vertices. This matrix should be a + (Nfacets, 3)-shaped array of NX_UINT. Further required input + is a (Nfacets, 3)-shaped array of NX_FLOAT signed facet unit + normals and a (Nvertices, 3)-shaped array of NX_FLOAT signed + vertex unit normals. Vertex indices need to start at zero and + must not exceed Nvertices - 1, i.e. the identifier_offset is 0 + and facet indices are indexed implicitly, i.e. [0, Nvertices-1]. + \@version: + doc: | + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional + layer of reproducibility from which file specifically + contains these data. + dataset_name_vertices: + doc: | + Absolute HDF5 path to the dataset which specifies the + array of vertex positions. + dataset_name_facet_indices: + doc: | + Absolute HDF5 path to the dataset which specifies the + array of facet indices. + dataset_name_facet_normals: + doc: | + Absolute HDF5 path to the dataset which specifies the + array of facet signed unit normals. + dataset_name_facet_vertices: + doc: | + Absolute HDF5 path to the dataset which specifies the + array of vertex signed unit normals. + + Users should be aware that triangulated surface meshes are + only approximations to a given complex, eventually curved shape. + Consequently, computations of normals show differences between + the vertex and facet normals. Vertex normals have to be + interpolated from normals of neighboring facets. Consequently, + these normals are affected by the underlying parameterization + and curvature estimation algorithms, irrespective of how + contributions from neighboring facets are weighted. By contrast, + facet normals are clearly defined by the associated triangle. + Their disadvantage is that they the normal field has discontinuities + at the edges. In general the coarser an object is triangulated + the more significant the difference becomes between computations + based on facet or vertex normals. + Paraprobe-nanochem works with facet normals as it can use + parts of the numerical performance gained by using cutting + edge libraries to work rather with finer meshes. + interface_meshing(NXprocess): + exists: ['min', '0', 'max', '1'] + doc: | + Create a simple principle component analysis (PCA) to mesh a + free-standing interface patch through a point cloud of decorating solutes. + These models can be useful for quantification of Gibbsian + interfacial excess for interfaces where iso-surface based methods + may fail or closed objects from iso-surfaces are not desired or + when e.g. there are no substantial or consistently oriented + concentration gradients across the interface patch. + + The interface_meshing functionality of paraprobe-nanochem can be useful + when there is also insufficient latent crystallographic information + available that could otherwise support modelling the interface, + via e.g. ion density traces in field-desorption maps, as were used and + discussed by `Y. Wei et al. `_ + or are discussed by `A. Breen et al. `_ + + It is noteworthy that the method here used is conceptually very similar + in implementation to the work by `Z. Peng et al. `_ + Noteworthy, her team uses the DCOM approach originally proposed by P. Felfer et al. + However, both of these previous works neither discuss in detail + nor implement inspection functionalities which enable a detection of + potential geometric inconsistencies or self-interactions of the + resulting DCOM mesh. This is what paraprobe-nanochem implements + via the Computational Geometry Algorithms Library. + initialization: + doc: | + Method how to initialize the PCA: + + * default, means based on segregated solutes in the ROI + * control_point_file, means based on reading an external list of + control points, currently coming from the Leoben APT_Analyzer. + + The control_point_file is currently expected with a specific format. + The Leoben group lead by L. Romaner has developed a GUI tool `A. Reichmann et al. `_ + to create a control_point_file which can be parsed by paraprobe-parmsetup + to match the here required formatting in control_points. + enumeration: [default, control_point_file] + filename: + doc: | + The name of the control point file to use. + \@version: + doc: | + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional + layer of reproducibility from which file specifically + contains these data. + control_points(NX_FLOAT): + unit: NX_LENGTH + doc: | + X, Y, Z coordinates of disjoint control point read from + an HDF5 file named according to control_point_file. + + # \@units: nm + dimensions: + rank: 2 + dim: [[1, N], [2, n_control_pts]] + method: + doc: | + Method used for identifying and refining the location of the + interface. Currently, paraprobe-nanochem implements a PCA followed + by an iterative loop of isotropic mesh refinement and DCOM step(s), + paired with self-intersection detection in a more robust + implementation. + enumeration: [pca_plus_dcom] + decorating_iontypes_filter(NXprocess): + doc: | + Specify the types of those ions which decorate the interface and + can thus be assumed as markers for locating the interface and + refining its local curvature. + candidates(NX_UINT): + unit: NX_UNITLESS + doc: | + Array of iontypes to filter. The list is interpreted as a whitelist, + i.e. ions of these types are considered the decorating species (solutes). + dimensions: + rank: 1 + dim: [[1, n_fct_filter_cand]] + number_of_iterations(NX_UINT): + unit: NX_UNITLESS + doc: | + How many times should the DCOM and mesh refinement be applied? + target_edge_length(NX_FLOAT): + unit: NX_LENGTH + doc: | + Array of decreasing positive not smaller than one nanometer real values + which specify how the initial triangles of the mesh should be iteratively + refined by edge splitting and related mesh refinement operations. + + # \@units: nm + dimensions: + rank: 1 + dim: [[1, n_fct_iterations]] + target_dcom_radius(NX_FLOAT): + unit: NX_LENGTH + doc: | + Array of decreasing positive not smaller than one nanometer real values + which specify the radius of the spherical region of interest within + which the DCOM algorithm decides for each vertex how the vertex will + be eventually relocated. The larger the DCOM radius is relative to + the target_edge_length the more likely it is that vertices will be + relocated so substantially that eventually triangle self-intersections + can occur. If the code detects these it warns and stops in a + controlled manner so that the user can repeat the analyses + with a smaller value. + + # \@units: nm + dimensions: + rank: 1 + dim: [[1, n_fct_iterations]] + target_smoothing_step(NX_UINT): + unit: NX_UNITLESS + doc: | + Array of integers which specify for each DCOM step how many times + the mesh should be iteratively smoothened. + + Users should be aware the three array target_edge_length, + target_dcom_radius, and target_smoothing_step are interpreted in the + same sequence, i.e. the zeroth entry of each array specifies the + values to be used in the first DCOM iteration. The first entry of + each array those for the second DCOM iteration and so on and so forth. + dimensions: + rank: 1 + dim: [[1, n_fct_iterations]] + composition_profiling(NXprocess): + exists: ['min', '0', 'max', '1'] + doc: | + Functionalities for placing regions-of-interest (ROIs) in the dataset + or at specific microstructural features to characterize composition + profiles and cumulated profiles for quantification of interfacial excess. + Paraprobe-nanochem currently places cylindrical ROIs. ROIs are probed + across the triangulated surface of a user-defined mesh. + ROIs are placed at the barycenter of the triangular facet. + + The tool can be instructed to orient the profile for each ROIs with + the positive normal of the triangle facet normals. Profiles are + computed for each ROI and facet triangle. The code will test which + ROIs are completely embedded in the dataset. + Specifically, in this test the tool evaluates if the ROI cuts at least + one triangle of the triangulated surface mesh of the edge of the dataset. + If this is the case the ROI will be considered close to the edge + (of the dataset) and not analyzed further; else the ROI will be + processed further. + Users should be aware that the latter intersection analysis is strictly + speaking not a volumetric intersection analysis as such one is much + more involved because the edge model can be a closed non-convex polyhedron + in which case one would have to test robustly if the cylinder pierces + or is laying completely inside the polyhedron. For this the polyhedron has + to be tessellated into convex polyhedra as otherwise tests like the + Gilbert-Johnson-Keerthi algorithm would not be applicable. + + Specifically, the tool computes atomically decomposed profiles. + This means molecular ions are split into atoms/isotopes with respective + multiplicity. As an example an H3O+ molecular ion contains three + hydrogen and one oxygen atom respectively. The tool then evaluates + how many ions are located inside the ROI or on the surface of the + ROI respectively. All atom types and the unranged ions are distinguished. + As a result, the analyses yield for each ROI a set of sorted lists of + signed distance values. Currently, the distance is the projected + distance of the ion position to the barycenter of the triangle + and triangle plane. + + This will return a one-dimensional profile. Post-processing the set + of atom-type-specific profiles into cumulated profiles enable the + classical Krakauer/Seidman-style interfacial excess analyses. + Furthermore, the tool can be instructed to compute for each + (or a selected sub-set of facet) a set of differently oriented profiles. + + # In the second case, these profiles will be probed in the direction of + # the outer unit surface normal vectors of a sphere. The sphere is + # discretized via a geodesic sphere (according to ideas of M. Kühbach + # et al. Journal of Applied Crystallography 2021) model with 40962 + # directions, some of which are duplicates (for now). This direction + # sampling enables substantially more detailed analyses of the effect + # of aligning the ROI because alignments of ROI based on triangle + # surface normals of the feature mesh can result in larger direction + # differences between neighboring ROIs when the mesh for rough + # surface meshes. + feature_mesh(NXprocess): + doc: | + The feature mesh enables the injection of previously computed triangle + soup or mesh data. Such a mesh can be the model for a grain- or phase + boundary patch (from e.g. interface_meshing) jobs. + filename: + doc: | + Name of the HDF5 file which contains vertex coordinates and facet + indices to describe the desired set of triangles which represents + the feature. + \@version: + doc: | + Version identifier of the file such as a secure hash which documents + the binary state of the file to add an additional layer of + reproducibility from which file specifically contains these data. + dataset_name_vertices: + doc: | + Absolute path to the HDF5 dataset in the respectively specified HDF5 + file under filename which details the array of vertex positions. + dataset_name_facet_indices: + doc: | + Absolute path to the HDF5 dataset in the respective specified HDF5 + file under filename which details the array of facet indices. + dataset_name_facet_normals: + doc: | + Absolute path to the HDF5 dataset in the respective specified HDF5 + file under filename which details consistently oriented facet + normals of the facets. + + # dataset_name_vertex_normals: + # doc: Absolute path to the HDF5 dataset in the respective specified + # HDF5 file under filename which details consistently oriented + # vertex normals of the facets. + # exists: optional + patch_identifier_filter(NXmatch_filter): + exists: optional + method: + match(NX_NUMBER): + ion_to_feature_distances(NXprocess): + exists: optional + doc: | + The tool enables to inject precomputed distance information for each + point which can be used for further post-processing and analysis. + + # NEW ISSUE: is this optional? + filename: + doc: | + Name of an HDF5 file which contains ion distances. + \@version: + doc: | + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional + layer of reproducibility from which file specifically contains + these data. + dataset_name: + doc: | + Absolute HDF5 path to the dataset with distance values for each ion. + distancing_model: + doc: | + Which type of distance should be reported for the profile. + enumeration: [project_to_triangle_plane] + + # NEW ISSUE:, ion_to_feature] + direction_model: + doc: | + In which directions should the tool probe for each ROI. + enumeration: [triangle_outer_unit_normal] + + # NEW ISSUE:, angularly_geodesic_sphere] + roi_cylinder_height(NX_FLOAT): + unit: NX_LENGTH + doc: | + For each ROI, how high (projected on the cylinder axis) + should the cylindrical ROI be. + + # \@units: nm + # all ROIs the same height + # dimensions: + # rank: 1 + # dim: [[1, 1]] + roi_cylinder_radius(NX_FLOAT): + unit: NX_LENGTH + doc: | + For each ROI, how wide (radius) should the cylindrical ROI be. + + # \@units: nm + # all ROIs the same radius + # dimensions: + # rank: 1 + # dim: [[1, 1]] + performance(NXcs_profiling): + current_working_directory: + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 1284c5c27884acb07242d7f237e65ab62a417f86051e12e75d536a4656d03f82 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# How many iontypes does the delocalization filter specify. +# +# +# +# +# How many disjoint control points are defined. +# +# +# +# +# How many iontypes does the interface meshing iontype filter specify. +# +# +# +# +# How many DCOM iterations. +# +# +# +# +# Maximum number of atoms per molecular ion. +# +# +# +# +# Configuration of a paraprobe-nanochem tool run in atom probe microscopy. +# +# +# +# +# Version specifier of this application definition. +# +# +# +# +# Official NeXus NXDL schema with which this file was written. +# +# +# +# +# +# +# +# Given name of the program/software/tool with which this NeXus +# (configuration) file was generated. +# +# +# +# Ideally program version plus build number, or commit hash or description +# of ever persistent resources where the source code of the program and +# build instructions can be found so that the program can be configured +# ideally in such a manner that the result of this computational process +# is recreatable in the same deterministic manner. +# +# +# +# +# +# Ideally, a (globally persistent) unique identifier for referring +# to this analysis. +# +# +# +# +# Possibility for leaving a free-text description about this analysis. +# +# +# +# +# Path to the directory where the tool should store NeXus/HDF5 results +# of this analysis. If not specified results will be stored in the +# current working directory. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to +# UTC information included when this configuration file was created. +# +# +# +# +# How many individual analyses should the tool execute as part of the analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The tool enables to inject a previously computed triangle soup or +# triangulated surface mesh representing a model (of the surface) of +# the edge of the dataset. This model can be used to detect and control +# various sources of bias in the analyses. +# +# +# +# +# Name of the HDF5 file which contains vertex coordinates and facet +# indices to describe the desired set of triangles which represents +# the edge of the dataset. +# +# +# +# Version identifier of the file such as a secure hash which documents +# the binary state of the file to add an additional layer of +# reproducibility from which file specifically contains these data. +# +# +# +# +# +# Absolute path to the HDF5 dataset in the respectively specified HDF5 +# file under filename which details the array of vertex positions. +# +# +# +# +# Absolute path to the HDF5 dataset in the respective specified HDF5 +# file under filename which details the array of facet indices. +# +# +# +# +# +# The tool enables to inject precomputed distance information for each +# point/ion which can be used for further post-processing and analysis. +# +# +# +# +# Name of an HDF5 file which contains the ion distances. +# +# +# +# Version identifier of the file such as a secure hash which documents +# the binary state of the file to add an additional layer of +# reproducibility from which file specifically contains these data. +# +# +# +# +# +# Absolute HDF5 path to the dataset with distance values for each ion. +# +# +# +# +# +# +# +# Discretization of the ion point cloud on a three-dimensional grid. +# +# +# +# Delocalization in the field of atom probe microscopy is the process +# of discretizing a point cloud. By default the tool computes a full +# kernel density estimation of decomposed ions to create one discretized +# field for each element. +# +# Although, this uses an efficient multithreaded algorithm, +# the computation is costly. Therefore, it can be advantageous for users +# to load an already computed delocalization. This can be achieved with +# the load_existent option. +# When using this option the user is responsible to assure that the +# settings which were used for computing this already existent delocalization +# are specified in the same manner as they were. +# +# +# +# +# +# +# +# +# +# +# Matrix of isotope vectors representing iontypes. +# The filter specifies a matrix of isotope_vectors which is the most +# general approach to define if and how many times an ion is counted. +# Currently, paraprobe_nanochem performs a so-called atomic decomposition +# of all iontypes. Specifically, the tool interprets of how many +# elements/atoms a molecular ion is composed; and thus determines the +# atoms multiplicity with respect to the iontype. +# +# Let's take the hydroxonium H3O+ molecular ion as an example: +# It contains hydrogen and oxygen as atoms. The multiplicity of hydrogen +# is three whereas that of oxygen is one. Therefore in an atomic +# decomposition computation of the iso-surface each H3O+ ion adds +# three hydrogen counts. This is a practical solution which accepts +# the situation that during an atom probe experiment not each bond +# of each ion/a group of neighboring atoms is broken but molecular +# ions get detected. The exact ab-initio details depend on the local +# field conditions and thus also the detailed spatial arrangement +# of the atoms and their own electronic state and that of the neighbors +# before and upon launch. +# Being able to measure the information for such sites only as +# molecular ions causes an inherent information loss with respect to the +# detailed spatial arrangement. This information loss is more relevant +# for local electrode atom probe than for field ion microscopy setting +# how precisely the atomic positions can be reconstructed. +# Accounting for multiplicities assures that at least the +# compositional information is analyzed. +# +# +# +# +# +# +# +# +# List of individual grid resolutions to analyse. +# Paraprobe discretizes on a cuboidal 3D grid with cubic cells, with +# an edge length of values in gridresolutions. +# +# +# +# +# +# Half the width of a :math:`{(2 \cdot n + 1)}^3` cubic kernel of voxel +# beyond which the Gaussian Ansatz function will be truncated. +# Intensity beyond the kernel is refactored into the kernel via +# a normalization procedure. +# +# +# +# +# Variance of the Gaussian Ansatz kernel :math:`\sigma_x = \sigma_y = 2 \cdot +# \sigma_z`. +# +# +# +# +# +# How should the results of the kernel-density estimation be computed +# into quantities. By default the tool computes the total number +# (intensity) of ions or elements. Alternatively the tool can compute +# the total intensity, the composition, or the concentration of the +# ions/elements specified by the white list of elements in each voxel. +# +# +# +# +# +# +# +# +# +# +# Specifies if the tool should report the delocalization 3D field values. +# +# +# +# +# +# +# Optional computation of iso-surfaces after each computed delocalization +# to identify for instance objects in the microstructure +# (line features, interfaces, precipitates). +# +# +# +# As it is detailed in M. Kühbach et al. 2022 npj Comp. Mat., +# the handling of triangles at the edge of the dataset requires +# special attention. Especially for composition-normalized +# delocalization it is possible that the composition increases +# towards the edge of the dataset because the quotient of two numbers +# which are both smaller than one is larger instead of smaller than +# the counter. By default, the tool uses a modified marching cubes +# algorithm of Lewiner et al. which detects if voxels face such a +# situation. In this case, no triangles are generated for such voxels. +# Alternatively, (via setting keep_edge_triangles) the user can +# instruct the tool to not remove these triangles at the cost of bias. +# +# Specifically, in this case the user should understand that all +# objects/microstructural features in contact with the edge of the +# dataset get usually artificial enlarged and their surface mesh +# often closed during the marching. This closure however is artificial! +# It can result in biased shape analyses for those objects. +# The reason why this should in general be avoided is a similar +# argument as when one analyzes grain shapes in orientation microscopy +# via e.g. SEM/EBSD. Namely, these grains, here the objects at the +# edge of the dataset, were not fully captured during e.g. limited +# field of view. +# Therefore, it is questionable if one would like to make +# substantiated quantitative statements about them. +# +# Thanks to collaboration with the V. V. Rielli and S. Primig, though, +# paraprobe-nanochem implements a complete pipeline to +# process even these objects at the edge of the dataset. Specifically, +# the objects are replaced by so-called proxies, i.e. replacement +# objects whose holes on the surface mesh have been closed if possible +# via iterative mesh and hole-filling procedures with fairing operations. +# In the results of each paraprobe-nanochem run, these proxy objects +# are listed separately to allow users to quantify and analyze in +# detail the differences when accounting for these objects or not. +# Especially this is relevant in atom probe microscopy as objects +# can contain a few dozen atoms only. +# Users should be aware that results from fairing operations should +# be compared to results from analyses where all objects at the edge +# of the dataset have been removed. +# +# Also users should be careful with overestimating the statistical +# significance of their dataset especially when using atom probe +# to compare multiple descriptors: Even though a dataset may give +# statistically significant results for compositions, this does not +# necessarily mean it will yield also statistically significant +# and unbiased results for three-dimensional object analyses. +# Being able to quantify these effects and making atom probers +# aware of these subtleties was one of the main reasons why the +# paraprobe-nanochem tool was implemented. +# +# +# +# +# +# +# +# +# The ion-to-edge-distance that is used in the analyses of objects +# (and proxies) to identify whether these are inside the dataset or +# close to the edge of the dataset. If an object has at least one ion +# with an ion-to-edge-distance below this threshold, the object is +# considered as one which lies close to the edge of the dataset. +# This implements essentially a distance-based approach to solve +# the in general complicated and involved treatment of computing +# volumetric intersections between not-necessarily convex +# closed 2-manifolds. In fact, such computational geometry analyses +# can face numerical robustness issues as a consequence of which a +# mesh can be detected as lying completely inside a dataset although +# in reality it is epsilon-close only, i.e. almost touching only +# the edge (e.g. from inside). +# Practically, humans would state in such case that the object is +# close to the edge of the dataset; however mathematically the object +# is indeed completely inside. +# In short, a distance-based approach is rigorous and more flexible. +# +# +# +# +# +# Array of iso-contour values. For each value the tool computes +# an iso-surface and performs subsequent analyses. +# The unit depends on the choice for the normalization of the +# accumulated ion intensity values per voxel: +# +# * total, total number of ions, irrespective their iontype +# * candidates, total number of ions with type in the isotope_whitelist. +# * composition, candidates but normalized by composition, i.e. at.-% +# * concentration, candidates but normalized by voxel volume, i.e. ions/nm^3 +# +# +# +# +# +# Specifies if the tool should report the triangle soup which represents +# each triangle of the iso-surface complex. +# Each triangle is reported with an ID specifying to which triangle +# cluster (with IDs starting at zero) the triangle belongs. +# The clustering is performed with a modified DBScan algorithm. +# +# +# +# +# Specifies if the tool should analyze for each cluster of triangles +# how they can be combinatorially processed to describe a closed +# polyhedron. Such a closed polyhedron (not-necessarily convex!) +# can be used to describe objects with relevance in the microstructure. +# Users should be aware that the resulting mesh does not necessarily +# represent the original precipitate. In fact, inaccuracies in the +# reconstructed positions cause inaccuracies in all downstream +# processing operations. Especially the effect on one-dimensional +# spatial statistics like nearest neighbor correlation functions these +# effects were discussed in the literature +# `B. Gault et al. <https://doi.org/10.1017/S1431927621012952>`_ +# In continuation of these thoughts this applies also to reconstructed +# objects. A well-known example is the discussion of shape deviations +# of Al3Sc precipitates in aluminium alloys which in reconstructions +# can appear as ellipsoids although they should be almost spherical, +# depending on their size. +# +# +# +# +# Specifies if the tool should report a triangulated surface mesh +# for each identified closed polyhedron. It is common that a +# marching cubes algorithm creates iso-surfaces with a fraction of very +# small sub-complexes (e.g. small isolated tetrahedra). +# +# These can be for instance be small tetrahedra/polyhedra about the +# center of a voxel of the support grid on which marching cubes operates. +# When these objects are small, it is possible that they contain no ion; +# especially when considering that delocalization procedures smoothen +# the positions of the ions. Although these small objects are interesting +# from a numerical point of view, scientists may argue they are not worth +# to be reported: +# Physically a microstructural feature should contain at least a few +# atoms to become relevant. Therefore, paraprobe-nanochem by default +# does not report closed objects which bound not at least one ion. +# +# +# +# +# Specifies if the tool should report properties of each closed +# polyhedron, such as volume and other details. +# +# +# +# +# Specifies if the tool should report for each closed polyhedron an +# approximately optimal bounding box fitted to all triangles of the +# surface mesh of the object and ion positions inside or on the +# surface of the mesh. +# This bounding box informs about the closed object's shape +# (aspect ratios). +# +# +# +# +# +# Specifies if the tool should report for each closed polyhedron +# all evaporation IDs of those ions which lie inside or on the +# boundary of the polyhedron. This information can be used e.g. +# in the paraprobe-intersector tool to infer if two objects share +# common ions, which can be interpreted as an argument to assume +# that the two objects intersect. +# +# Users should be aware that two arbitrarily closed polyhedra +# in three-dimensional space can intersect but not share a common ion. +# In fact, the volume bounded by the polyhedron has sharp edges. +# When taking two objects, an edge of one object may for instance +# pierce into the surface of another object. In this case the +# objects partially overlap / intersect volumetrically; +# however this piercing might be so small or happening in the volume +# between two ion positions and thus sharing ions is a sufficient +# but not a necessary condition for object intersections. +# +# Paraprobe-intersector implements a rigorous alternative to handle +# such intersections using a tetrahedralization of closed objects. +# However, in many practical cases, we found through examples that there +# are polyhedra (especially when they are non-convex and have almost +# point-like) connected channels, where tetrahedralization libraries +# have challenges dealing with. In this case checking intersections +# via shared_ions is a more practical alternative. +# +# +# +# +# Specifies if the tool should report if a (closed) object has +# contact with the edge of the dataset. For this the tool currently +# inspects if the shortest distance between the set of triangles of the +# surface mesh and the triangles of the edge model is larger than the +# edge_threshold. If this is the case, the object is assumed to be +# deeply embedded in the interior of the dataset. Otherwise, the object +# is considered to have an edge contact, i.e. it is likely affected +# by the fact that the dataset is finite. +# +# +# +# +# +# Specifies if the tool should analyze a doppelganger/proxy mesh for +# each cluster of triangles whose combinatorial analysis according +# to has_object showed that the object is not a closed polyhedron. +# Such proxies are closed via iterative hole-filling, mesh refinement, +# and fairing operations. +# Users should be aware that the resulting mesh does not necessarily +# represent the original precipitate. In most cases objects, +# like precipitates in atom probe end up as open objects because +# they have been clipped by the edge of the dataset. Using a proxy is +# then a strategy to still be able to account for these objects. +# Nevertheless users should make themselves familiar with the +# potential consequences and biases which this can introduce +# into the analysis. +# +# +# +# +# Like has_object_geometry but for the proxies. +# +# +# +# +# Like has_object_properties but for the proxies. +# +# +# +# +# Like has_object_obb but for the proxies. +# +# +# +# +# Like has_object_ions but for the proxies. +# +# +# +# +# Like has_object_edge_contact but for the proxies. +# +# +# +# +# Specifies if the tool should report for each closed object a +# (cylindrical) region of interest placed, centered, and align +# with the local normal for each triangle of the object. +# +# +# +# +# Specifies if the tool should report for each ROI that was placed +# at a triangle of each object if this ROI intersects the edge of +# the dataset. Currently paraprobe-nanochem supports cylindrical +# ROIs. A possible intersection of these with the edge of the +# dataset, i.e. the triangulated surface mesh model for the edge +# is performed. This test checks if the cylinder intersects with +# a triangle of the surface mesh. If this is the case, the ROI is +# assumed to make edge contact, else, the ROI is assumed to have +# no edge contact. +# +# This approach does not work if the ROI would be completely +# outside the dataset. Also in this case there would be +# no intersection. For atom probe this case is practically +# irrelevant because for such a ROI there would also be no ion +# laying inside the ROI. Clearly it has thus to be assumed that +# the edge model culls the entire dataset. Instead, if one would +# cut a portion of the dataset, compute an edge model for this +# point cloud, it might make sense to place a ROI but in this +# case the edge contact detection is not expected to work properly. +# +# +# +# +# +# +# Analyses of interfacial excess. +# +# +# +# Interfacial excess computations are performed for local regions-of-interests +# (ROIs) at selected facets or interface patch. +# For instance many scientist compute the interfacial excess for +# selected triangle facets of a created iso-surface. In this case, +# computed iso-surfaces of paraprobe could be used. An example are triangle +# facet sets about closed polyhedra, for instance to compute interfacial +# excess related to phase boundaries of second-phase precipitates. +# +# Another example are free-standing triangle patches of the iso- +# surfaces which paraprobe creates. These could be characterized +# for interfacial excess. The sub-routines during iso-surface +# computations already include a procedure to automatically align +# local triangle normals based on the gradients of e.g. composition +# fields. In this case, these triangulated surface patches +# could also be used as a source for computing interfacial +# excess. +# +# Often scientists face situations, though, in which there is no +# immediately evident composition gradient across the interface +# (grain or phase boundary) and orientation information about the +# adjoining crystal is neither available nor reliable enough. +# +# In this case `P. Felfer et al. <https://doi.org/10.1016/j.ultramic.2015.06.002>`_ proposed a method +# to manually place control points and run an automated tessellation-based +# algorithm to create a triangulated surface patch, i.e. a model of the +# location of the interface. In a post-processing step this triangle +# set can then be used to compute again interfacial excess in an +# automated manner by placing ROIs and aligning them with +# consistently precomputed triangle normals. +# +# A similar use case is conceptually the one proposed by `X. Zhou et al. <https://doi.org/10.1016/j.actamat.2022.117633>`_ +# They used first a deep-learning method to locate planar triangulated +# grain boundary patches. These are eventually processed further +# with manual editing of the mesh via tools like Blender. +# Once the user is satisfied with the mesh, the computations of interfacial +# excess reduce again to an automated placing of ROIs, computations +# of the distributing of ions to respective ROIs and +# reporting the findings via plotting. +# +# Yet another approach for constructing an triangulated surface patch +# of an interface is to use point cloud processing methods which have +# been proposed in the laser-scanning, geoinformatics, and CAD community. +# Different computational geometry methods are available for fitting +# a parameterized surface to a set of points, using e.g. non-uniform +# rational B-splines (NURBS) and triangulating these according +# to prescribed mesh quality demands. +# +# The advantage of these methods is that they can be automated and +# pick up curved interface segments. The disadvantage is their often +# strong sensitivity to parameterization. As a result also such methods +# can be post-processed to yield a triangulated surface patch, +# and thus enable to run again automated ROI placement methods. +# For example like these which were explored for the use case of +# iso-surfaces with closed objects and free-standing +# surface patches that delineate regions of the dataset with a +# pronounced composition gradient normal to the interface. +# +# This summary of the situations which atom probers can face when +# requesting for interfacial excess computations, substantiates there +# exists a common set of settings which can describe all of these methods +# and, specifically, as here exemplified, the automated placing +# and alignment functionalities for ROIs that is an important +# step all these workflows. +# +# Specifically, paraprobe-nanochem operates on an already existent +# triangle set. +# +# +# +# +# +# +# +# +# +# The interface model is the result of a previous (set of) processing +# steps as a result of which the user has created a triangulated +# surface mesh (or a set of, eventually connected such meshes). +# These interface models are useful, if not required, in cases when +# there is no other independent approach to locate an interface. +# +# These are cases when insufficient crystallographic latent +# information is available and also no consistent concentration +# gradient detectable across the interface. It is then the users' +# responsibility to deliver a triangle mesh of the interface model. +# +# +# +# Filename to HDF5 file which contain vertex coordinates, facet indices, +# facet unit normals. The user is responsible for the triangle +# and winding order to be consistent. +# Input is expected as a matrix of the coordinates for all disjoint +# vertices, a (Nvertices, 3)-shaped array of NX_FLOAT. +# Input is expected to include also a matrix of facet indices +# referring to these disjoint vertices. This matrix should be a +# (Nfacets, 3)-shaped array of NX_UINT. Further required input +# is a (Nfacets, 3)-shaped array of NX_FLOAT signed facet unit +# normals and a (Nvertices, 3)-shaped array of NX_FLOAT signed +# vertex unit normals. Vertex indices need to start at zero and +# must not exceed Nvertices - 1, i.e. the identifier_offset is 0 +# and facet indices are indexed implicitly, i.e. [0, Nvertices-1]. +# +# +# +# Version identifier of the file such as a secure hash which +# documents the binary state of the file to add an additional +# layer of reproducibility from which file specifically +# contains these data. +# +# +# +# +# +# Absolute HDF5 path to the dataset which specifies the +# array of vertex positions. +# +# +# +# +# Absolute HDF5 path to the dataset which specifies the +# array of facet indices. +# +# +# +# +# Absolute HDF5 path to the dataset which specifies the +# array of facet signed unit normals. +# +# +# +# +# Absolute HDF5 path to the dataset which specifies the +# array of vertex signed unit normals. +# +# Users should be aware that triangulated surface meshes are +# only approximations to a given complex, eventually curved shape. +# Consequently, computations of normals show differences between +# the vertex and facet normals. Vertex normals have to be +# interpolated from normals of neighboring facets. Consequently, +# these normals are affected by the underlying parameterization +# and curvature estimation algorithms, irrespective of how +# contributions from neighboring facets are weighted. By contrast, +# facet normals are clearly defined by the associated triangle. +# Their disadvantage is that they the normal field has discontinuities +# at the edges. In general the coarser an object is triangulated +# the more significant the difference becomes between computations +# based on facet or vertex normals. +# Paraprobe-nanochem works with facet normals as it can use +# parts of the numerical performance gained by using cutting +# edge libraries to work rather with finer meshes. +# +# +# +# +# +# +# +# Create a simple principle component analysis (PCA) to mesh a +# free-standing interface patch through a point cloud of decorating solutes. +# These models can be useful for quantification of Gibbsian +# interfacial excess for interfaces where iso-surface based methods +# may fail or closed objects from iso-surfaces are not desired or +# when e.g. there are no substantial or consistently oriented +# concentration gradients across the interface patch. +# +# The interface_meshing functionality of paraprobe-nanochem can be useful +# when there is also insufficient latent crystallographic information +# available that could otherwise support modelling the interface, +# via e.g. ion density traces in field-desorption maps, as were used and +# discussed by `Y. Wei et al. <https://doi.org/10.1371/journal.pone.0225041>`_ +# or are discussed by `A. Breen et al. <https://github.com/breen-aj/detector>`_ +# +# It is noteworthy that the method here used is conceptually very similar +# in implementation to the work by `Z. Peng et al. <https://doi.org/10.1017/S1431927618016112>`_ +# Noteworthy, her team uses the DCOM approach originally proposed by P. Felfer et al. +# However, both of these previous works neither discuss in detail +# nor implement inspection functionalities which enable a detection of +# potential geometric inconsistencies or self-interactions of the +# resulting DCOM mesh. This is what paraprobe-nanochem implements +# via the Computational Geometry Algorithms Library. +# +# +# +# Method how to initialize the PCA: +# +# * default, means based on segregated solutes in the ROI +# * control_point_file, means based on reading an external list of +# control points, currently coming from the Leoben APT_Analyzer. +# +# The control_point_file is currently expected with a specific format. +# The Leoben group lead by L. Romaner has developed a GUI tool `A. Reichmann et al. <https://github.com/areichm/APT_analyzer>`_ +# to create a control_point_file which can be parsed by paraprobe-parmsetup +# to match the here required formatting in control_points. +# +# +# +# +# +# +# +# +# The name of the control point file to use. +# +# +# +# Version identifier of the file such as a secure hash which +# documents the binary state of the file to add an additional +# layer of reproducibility from which file specifically +# contains these data. +# +# +# +# +# +# X, Y, Z coordinates of disjoint control point read from +# an HDF5 file named according to control_point_file. +# +# +# +# +# +# +# +# +# +# Method used for identifying and refining the location of the +# interface. Currently, paraprobe-nanochem implements a PCA followed +# by an iterative loop of isotropic mesh refinement and DCOM step(s), +# paired with self-intersection detection in a more robust +# implementation. +# +# +# +# +# +# +# +# Specify the types of those ions which decorate the interface and +# can thus be assumed as markers for locating the interface and +# refining its local curvature. +# +# +# +# Array of iontypes to filter. The list is interpreted as a whitelist, +# i.e. ions of these types are considered the decorating species (solutes). +# +# +# +# +# +# +# +# +# How many times should the DCOM and mesh refinement be applied? +# +# +# +# +# Array of decreasing positive not smaller than one nanometer real values +# which specify how the initial triangles of the mesh should be iteratively +# refined by edge splitting and related mesh refinement operations. +# +# +# +# +# +# +# +# +# Array of decreasing positive not smaller than one nanometer real values +# which specify the radius of the spherical region of interest within +# which the DCOM algorithm decides for each vertex how the vertex will +# be eventually relocated. The larger the DCOM radius is relative to +# the target_edge_length the more likely it is that vertices will be +# relocated so substantially that eventually triangle self-intersections +# can occur. If the code detects these it warns and stops in a +# controlled manner so that the user can repeat the analyses +# with a smaller value. +# +# +# +# +# +# +# +# +# Array of integers which specify for each DCOM step how many times +# the mesh should be iteratively smoothened. +# +# Users should be aware the three array target_edge_length, +# target_dcom_radius, and target_smoothing_step are interpreted in the +# same sequence, i.e. the zeroth entry of each array specifies the +# values to be used in the first DCOM iteration. The first entry of +# each array those for the second DCOM iteration and so on and so forth. +# +# +# +# +# +# +# +# +# Functionalities for placing regions-of-interest (ROIs) in the dataset +# or at specific microstructural features to characterize composition +# profiles and cumulated profiles for quantification of interfacial excess. +# Paraprobe-nanochem currently places cylindrical ROIs. ROIs are probed +# across the triangulated surface of a user-defined mesh. +# ROIs are placed at the barycenter of the triangular facet. +# +# The tool can be instructed to orient the profile for each ROIs with +# the positive normal of the triangle facet normals. Profiles are +# computed for each ROI and facet triangle. The code will test which +# ROIs are completely embedded in the dataset. +# Specifically, in this test the tool evaluates if the ROI cuts at least +# one triangle of the triangulated surface mesh of the edge of the dataset. +# If this is the case the ROI will be considered close to the edge +# (of the dataset) and not analyzed further; else the ROI will be +# processed further. +# Users should be aware that the latter intersection analysis is strictly +# speaking not a volumetric intersection analysis as such one is much +# more involved because the edge model can be a closed non-convex polyhedron +# in which case one would have to test robustly if the cylinder pierces +# or is laying completely inside the polyhedron. For this the polyhedron has +# to be tessellated into convex polyhedra as otherwise tests like the +# Gilbert-Johnson-Keerthi algorithm would not be applicable. +# +# Specifically, the tool computes atomically decomposed profiles. +# This means molecular ions are split into atoms/isotopes with respective +# multiplicity. As an example an H3O+ molecular ion contains three +# hydrogen and one oxygen atom respectively. The tool then evaluates +# how many ions are located inside the ROI or on the surface of the +# ROI respectively. All atom types and the unranged ions are distinguished. +# As a result, the analyses yield for each ROI a set of sorted lists of +# signed distance values. Currently, the distance is the projected +# distance of the ion position to the barycenter of the triangle +# and triangle plane. +# +# This will return a one-dimensional profile. Post-processing the set +# of atom-type-specific profiles into cumulated profiles enable the +# classical Krakauer/Seidman-style interfacial excess analyses. +# Furthermore, the tool can be instructed to compute for each +# (or a selected sub-set of facet) a set of differently oriented profiles. +# +# +# +# +# The feature mesh enables the injection of previously computed triangle +# soup or mesh data. Such a mesh can be the model for a grain- or phase +# boundary patch (from e.g. interface_meshing) jobs. +# +# +# +# Name of the HDF5 file which contains vertex coordinates and facet +# indices to describe the desired set of triangles which represents +# the feature. +# +# +# +# Version identifier of the file such as a secure hash which documents +# the binary state of the file to add an additional layer of +# reproducibility from which file specifically contains these data. +# +# +# +# +# +# Absolute path to the HDF5 dataset in the respectively specified HDF5 +# file under filename which details the array of vertex positions. +# +# +# +# +# Absolute path to the HDF5 dataset in the respective specified HDF5 +# file under filename which details the array of facet indices. +# +# +# +# +# Absolute path to the HDF5 dataset in the respective specified HDF5 +# file under filename which details consistently oriented facet +# normals of the facets. +# +# +# +# +# +# +# +# +# +# +# The tool enables to inject precomputed distance information for each +# point which can be used for further post-processing and analysis. +# +# +# +# +# Name of an HDF5 file which contains ion distances. +# +# +# +# Version identifier of the file such as a secure hash which +# documents the binary state of the file to add an additional +# layer of reproducibility from which file specifically contains +# these data. +# +# +# +# +# +# Absolute HDF5 path to the dataset with distance values for each ion. +# +# +# +# +# +# Which type of distance should be reported for the profile. +# +# +# +# +# +# +# +# +# In which directions should the tool probe for each ROI. +# +# +# +# +# +# +# +# +# For each ROI, how high (projected on the cylinder axis) +# should the cylindrical ROI be. +# +# +# +# +# +# For each ROI, how wide (radius) should the cylindrical ROI be. +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.yaml new file mode 100644 index 0000000000..cbc879b5c8 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.yaml @@ -0,0 +1,531 @@ +category: application +doc: | + Configuration of a paraprobe-ranger tool run in atom probe microscopy. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_isotopes: | + The number of isotopes to consider as building blocks for searching molecular + ions. + n_composition: | + The number of compositions to consider for molecular ion search tasks. +type: group +NXapm_paraprobe_config_ranger(NXobject): + (NXentry): + + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + \@version: + doc: | + Version specifier of this application definition. + definition: + doc: | + Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_config_ranger] + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + time_stamp(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + analysis_identifier: + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: | + Possibility for leaving a free-text description about this analysis. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + number_of_processes(NX_UINT): + unit: NX_UNITLESS + doc: | + How many task to perform? + (NXprocess): + exists: ['min', '0', 'max', 'unbounded'] + apply_existent_ranging(NXprocess): + exists: ['min', '0', 'max', '1'] + dataset(NXapm_input_reconstruction): + filename: + \@version: + dataset_name_reconstruction: + dataset_name_mass_to_charge: + iontypes(NXapm_input_ranging): + filename: + \@version: + group_name_iontypes: + spatial_filter(NXspatial_filter): + exists: optional + windowing_method: + (NXcg_ellipsoid_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + half_axes_radii(NX_NUMBER): + orientation(NX_NUMBER): + (NXcg_cylinder_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + height(NX_NUMBER): + radii(NX_NUMBER): + (NXcg_hexahedron_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + hexahedra(NXcg_face_list_data_structure): + (NXcs_filter_boolean_mask): + exists: optional + number_of_objects(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + identifier(NX_UINT): + evaporation_id_filter(NXsubsampling_filter): + exists: optional + iontype_filter(NXmatch_filter): + exists: optional + hit_multiplicity_filter(NXmatch_filter): + exists: optional + molecular_ion_search(NXprocess): + exists: ['min', '0', 'max', 'unbounded'] + assumed_composition_isotopes(NX_UINT): + exists: optional + unit: NX_UNITLESS + doc: | + A list of pairs of number of protons and either the value 0 (per row) + or the mass number for all those isotopes which are assumed present + in a virtual specimen. + The purpose of this field is to compute also composition-weighted + products to yield a simple estimation which could potentially help + scientists to judge if certain molecular ions are to be expected. + The corresponding setting store_composition_weighted_product should be + activated. + dimensions: + rank: 2 + dim: [[1, n_composition], [2, 2]] + + # assumed_composition_value(NX_FLOAT): + # doc: | + # A list of atomic (at.-%) ! percent values for the composition of each + # isotope in the virtual specimen following the sequence of + # assumed_composition_isotopes. + # unit: NX_DIMENSIONLESS + # dimensions: + # rank: 1 + # dim: [[1, n_compositions]] + isotope_whitelist(NX_UINT): + unit: NX_UNITLESS + doc: | + A list of pairs of number of protons and mass number for all isotopes + to consider that can be composed into (molecular) ions, during the + recursive molecular_ion_search. + dimensions: + rank: 2 + dim: [[1, n_isotopes], [2, 2]] + mass_to_charge_interval(NX_FLOAT): + unit: NX_ANY + doc: | + The mass-to-charge-state ratio interval in which + all molecular ions are searched. + dimensions: + rank: 1 + dim: [[1, 2]] + maximum_charge(NX_UINT): + unit: NX_UNITLESS + doc: | + The maximum charge that a molecular ion should have. + maximum_number_of_isotopes(NX_UINT): + unit: NX_UNITLESS + doc: | + The maximum number of isotopes of which the molecular ion + should be composed. Currently this must not be larger than 32. + + Users should be warned that the larger the maximum_charge and + especially the larger the maximum_number_of_isotopes is chosen, + the eventually orders of magnitude more costly the search becomes. + + This is because paraprobe-ranger computes really all (at least) + theoretically possible combinations that would have likely a + mass-to-charge-state ratio in the specified mass_to_charge_interval. + It is the challenge in atom probe to judge which of these (molecular) + ions are feasible and also practically possible. This tool does not + answer this question. + + Namely, which specific molecular ion will evaporate, remain stable + during flight and becomes detected is a complicated and in many cases + not yet in detail understood phenomenon. The ab-initio conditions + before and during launch, the local environment, arrangement and field + as well as the flight phase in an evacuated but not analysis chamber + with a complex electrical field, eventual laser pulsing in place, + temperature and remaining atoms or molecules all can have an effect + which iontypes are really physically evaporating and detected. + store_atomic_mass_sum(NX_BOOLEAN): + doc: | + Report the accumulated atomic mass from each isotope building the ion. + Accounts for each identified ion. + Relatistic effects are not accounted for. + store_natural_abundance_product(NX_BOOLEAN): + doc: | + Report the product of the natural abundances from each isotope building + the ion. Accounts for each identified ion. + + The value zero indicates it is not possible to build such molecular ion + from nuclids which are all observationally stable. + Very small values can give an idea/about how likely such a molecular ion + is expected to form assuming equal probabilities. + + However in atom probe experiments this product has to be modified + by the (spatially-correlated) local composition in the region from + which the ions launch because the formation of a molecular ion depends + as summarized under maximum_number_of_isotopes on the specific + quantum-mechanical configuration and field state upon launch + or/and (early state) of flight respectively. + We are aware that this modified product can have a substantially + different value than the natural_abundance_product. + + Natural abundancies folded with the estimated compositions of the + specimen can differ by orders of magnitude. + + # add assumed composition of the specimen + # store_composition_weighted_product(NX_BOOLEAN): + # doc: | + # Report the product of the composition from each isotope building the + # ion. This sets strong constraints on the molecular ions which are + # expected to have at all a noteworthy product value. + # It should not be forgotten though the computation relies on assumptions: + # * The composition is homogeneous within the virtual specimen. + # * It is a priori know which nuclids the specimen is build of. + store_charge_state(NX_BOOLEAN): + doc: | + Report the charge state of the ions. + store_disjoint_isotopes(NX_BOOLEAN): + doc: | + Report if identified ions should be characterized + wrt to their number of disjoint isotopes. + check_existent_ranging(NXprocess): + exists: ['min', '0', 'max', '1'] + iontypes(NXapm_input_ranging): + filename: + \@version: + group_name_iontypes: + performance(NXcs_profiling): + current_working_directory: + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e680aa3be81d3132fa6dbff9ae4d44ae7ca8a610b8660af51c3b67c207961ea0 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The number of isotopes to consider as building blocks for searching molecular +# ions. +# +# +# +# +# The number of compositions to consider for molecular ion search tasks. +# +# +# +# +# Configuration of a paraprobe-ranger tool run in atom probe microscopy. +# +# +# +# +# +# Version specifier of this application definition. +# +# +# +# +# Official NeXus NXDL schema with which this file was written. +# +# +# +# +# +# +# +# Given name of the program/software/tool with which this NeXus +# (configuration) file was generated. +# +# +# +# Ideally program version plus build number, or commit hash or description +# of ever persistent resources where the source code of the program and +# build instructions can be found so that the program can be configured +# ideally in such a manner that the result of this computational process +# is recreatable in the same deterministic manner. +# +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when this configuration file was created. +# +# +# +# +# Ideally, a (globally persistent) unique identifier for referring +# to this analysis. +# +# +# +# +# Possibility for leaving a free-text description about this analysis. +# +# +# +# +# Path to the directory where the tool should store NeXus/HDF5 results +# of this analysis. If not specified results will be stored in the +# current working directory. +# +# +# +# +# How many task to perform? +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# A list of pairs of number of protons and either the value 0 (per row) +# or the mass number for all those isotopes which are assumed present +# in a virtual specimen. +# The purpose of this field is to compute also composition-weighted +# products to yield a simple estimation which could potentially help +# scientists to judge if certain molecular ions are to be expected. +# The corresponding setting store_composition_weighted_product should be +# activated. +# +# +# +# +# +# +# +# +# +# A list of pairs of number of protons and mass number for all isotopes +# to consider that can be composed into (molecular) ions, during the +# recursive molecular_ion_search. +# +# +# +# +# +# +# +# +# The mass-to-charge-state ratio interval in which +# all molecular ions are searched. +# +# +# +# +# +# +# +# The maximum charge that a molecular ion should have. +# +# +# +# +# The maximum number of isotopes of which the molecular ion +# should be composed. Currently this must not be larger than 32. +# +# Users should be warned that the larger the maximum_charge and +# especially the larger the maximum_number_of_isotopes is chosen, +# the eventually orders of magnitude more costly the search becomes. +# +# This is because paraprobe-ranger computes really all (at least) +# theoretically possible combinations that would have likely a +# mass-to-charge-state ratio in the specified mass_to_charge_interval. +# It is the challenge in atom probe to judge which of these (molecular) +# ions are feasible and also practically possible. This tool does not +# answer this question. +# +# Namely, which specific molecular ion will evaporate, remain stable +# during flight and becomes detected is a complicated and in many cases +# not yet in detail understood phenomenon. The ab-initio conditions +# before and during launch, the local environment, arrangement and field +# as well as the flight phase in an evacuated but not analysis chamber +# with a complex electrical field, eventual laser pulsing in place, +# temperature and remaining atoms or molecules all can have an effect +# which iontypes are really physically evaporating and detected. +# +# +# +# +# Report the accumulated atomic mass from each isotope building the ion. +# Accounts for each identified ion. +# Relatistic effects are not accounted for. +# +# +# +# +# Report the product of the natural abundances from each isotope building +# the ion. Accounts for each identified ion. +# +# The value zero indicates it is not possible to build such molecular ion +# from nuclids which are all observationally stable. +# Very small values can give an idea/about how likely such a molecular ion +# is expected to form assuming equal probabilities. +# +# However in atom probe experiments this product has to be modified +# by the (spatially-correlated) local composition in the region from +# which the ions launch because the formation of a molecular ion depends +# as summarized under maximum_number_of_isotopes on the specific +# quantum-mechanical configuration and field state upon launch +# or/and (early state) of flight respectively. +# We are aware that this modified product can have a substantially +# different value than the natural_abundance_product. +# +# Natural abundancies folded with the estimated compositions of the +# specimen can differ by orders of magnitude. +# +# +# +# +# +# Report the charge state of the ions. +# +# +# +# +# Report if identified ions should be characterized +# wrt to their number of disjoint isotopes. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_selector.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_selector.yaml new file mode 100644 index 0000000000..d5c9ac4ed4 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_selector.yaml @@ -0,0 +1,240 @@ +category: application +doc: | + Configuration of a paraprobe-selector tool run in atom probe microscopy. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXapm_paraprobe_config_selector(NXobject): + (NXentry): + + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + \@version: + doc: | + Version specifier of this application definition. + definition: + doc: | + Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_config_selector] + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + analysis_identifier: + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: | + Possibility for leaving a free-text description about this analysis. + time_stamp(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + number_of_processes(NX_UINT): + unit: NX_UNITLESS + doc: | + How many roi_selection processes should the tool execute. + roi_selection(NXprocess): + exists: ['min', '1', 'max', '1'] + doc: | + This process identifies which of the points/ions in the datasets are + inside or on the surface of geometric primitives and meet optionally + specific other filtering constraints. + A typical use case of a roi_selection is to restrict analyses to + specific regions of the dataset, eventually regions with a complicated + shape. + dataset(NXapm_input_reconstruction): + filename: + \@version: + dataset_name_reconstruction: + dataset_name_mass_to_charge: + iontypes(NXapm_input_ranging): + filename: + \@version: + group_name_iontypes: + spatial_filter(NXspatial_filter): + windowing_method: + (NXcg_ellipsoid_set): + exists: optional + cardinality(NX_POSINT): + center(NX_NUMBER): + half_axes_radii(NX_NUMBER): + + # orientation(NX_NUMBER): + (NXcg_cylinder_set): + exists: optional + cardinality(NX_POSINT): + center(NX_NUMBER): + height(NX_NUMBER): + radii(NX_NUMBER): + (NXcg_hexahedron_set): + exists: optional + cardinality(NX_POSINT): + hexahedra(NXcg_face_list_data_structure): + vertices(NX_FLOAT): + evaporation_id_filter(NXsubsampling_filter): + exists: optional + linear_range_min_incr_max(NX_UINT): + iontype_filter(NXmatch_filter): + exists: optional + method: + match(NX_NUMBER): + hit_multiplicity_filter(NXmatch_filter): + exists: optional + method: + match(NX_NUMBER): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# a75891867e7d1bca2385b3439e5cdca146d2036d6ee76fb381c3fac3f0579ecf +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Configuration of a paraprobe-selector tool run in atom probe microscopy. +# +# +# +# +# +# Version specifier of this application definition. +# +# +# +# +# Official NeXus NXDL schema with which this file was written. +# +# +# +# +# +# +# +# Given name of the program/software/tool with which this NeXus +# (configuration) file was generated. +# +# +# +# Ideally program version plus build number, or commit hash or description +# of ever persistent resources where the source code of the program and +# build instructions can be found so that the program can be configured +# ideally in such a manner that the result of this computational process +# is recreatable in the same deterministic manner. +# +# +# +# +# +# Ideally, a (globally persistent) unique identifier for referring +# to this analysis. +# +# +# +# +# Possibility for leaving a free-text description about this analysis. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when this configuration file was created. +# +# +# +# +# How many roi_selection processes should the tool execute. +# +# +# +# +# This process identifies which of the points/ions in the datasets are +# inside or on the surface of geometric primitives and meet optionally +# specific other filtering constraints. +# A typical use case of a roi_selection is to restrict analyses to +# specific regions of the dataset, eventually regions with a complicated +# shape. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml new file mode 100644 index 0000000000..9bcba92551 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml @@ -0,0 +1,662 @@ +category: application +doc: | + Configuration of a paraprobe-spatstat tool run in atom probe microscopy. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_ivecmax: | + Maximum number of atoms per molecular ion. Should be 32 for paraprobe. + n_ion_source: | + Number of different sources iontypes to distinguish. + n_ion_target: | + Number of different target iontypes to distinguish. +type: group +NXapm_paraprobe_config_spatstat(NXobject): + (NXentry): + + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + \@version: + doc: | + Version specifier of this application definition. + definition: + doc: | + Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_config_spatstat] + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + analysis_identifier: + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: | + Possibility for leaving a free-text description about this analysis. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + time_stamp(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + number_of_processes(NX_UINT): + unit: NX_UNITLESS + doc: | + How many range_with_existent_iontypes processes should + the tool execute as part of the analysis. + (NXprocess): + exists: ['min', '1', 'max', '1'] + spatial_statistics(NXprocess): + exists: ['min', '0', 'max', '1'] + dataset(NXapm_input_reconstruction): + filename: + \@version: + dataset_name_reconstruction: + dataset_name_mass_to_charge: + iontypes(NXapm_input_ranging): + filename: + \@version: + group_name_iontypes: + spatial_filter(NXspatial_filter): + exists: optional + windowing_method: + (NXcg_ellipsoid_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + half_axes_radii(NX_NUMBER): + orientation(NX_NUMBER): + (NXcg_cylinder_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + height(NX_NUMBER): + radii(NX_NUMBER): + (NXcg_hexahedron_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + hexahedra(NXcg_face_list_data_structure): + (NXcs_filter_boolean_mask): + exists: optional + number_of_objects(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + identifier(NX_UINT): + evaporation_id_filter(NXsubsampling_filter): + exists: optional + iontype_filter(NXmatch_filter): + exists: optional + hit_multiplicity_filter(NXmatch_filter): + exists: optional + ion_to_edge_distances(NXprocess): + exists: optional + doc: | + The tool enables to inject precomputed distances of each ion to a + representation of the edge of the dataset which can be used to + control and substantially reduce edge effects when computing + spatial statistics. + filename: + doc: | + Name of an HDF5 file which contains ion-to-edge distances. + dataset_name_distances: + doc: | + Absolute HDF5 path to the dataset with the + ion-to-edge distance values for each ion. + The shape of the distance values has to match the length + of the ion positions array in dataset/dataset_name_reconstruction + and dataset_name_mass_to_charge respectively. + edge_distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + Threshold to define how large an ion has to lay at least far away + from the edge of the dataset so that the ion can act as a source, + i.e. that an ROI is placed at the location of the ion and its + neighbors are analyzed how they contribute to the computed statistics. + + The ion_to_edge_distances threshold can be combined with a threshold + for the ion_to_feature_distances. + Specifically, if ion_to_feature_distances are loaded an ion only + acts as a source if both threshold criteria are met. + + The threshold is useful to process the dataset such that ROIs do + not protrude out of the dataset as this would add bias. + ion_to_feature_distances(NXprocess): + exists: optional + doc: | + In addition to spatial filtering, and considering how far ions lie + to the edge of the dataset, it is possible to restrict the analyses + to a sub-set of ions within a distance not farther away to a feature than + a threshold value. + filename: + doc: | + Name of an HDF5 file which contains ion-to-feature distances. + dataset_name_distances: + doc: | + Absolute HDF5 path to the dataset with the + ion-to-feature distance values for each ion. + threshold(NX_FLOAT): + unit: NX_LENGTH + doc: | + Threshold to define how close an ion has to lay to a feature so that + the ion can at all qualify as a source, i.e. that an ROI is placed + at the location of the ion and its neighbors are then analyzed + how they contribute to the computed statistics. + + Recall that the ion_to_feature_distances threshold is combined + with the ion_to_edge_distances threshold. + + ##MK::think about an inversion ruleset for the filter, i.e. + # like discussed in Haley/Stephenson's paper where ions only far enough + # from a feature AND deeply embedded enough in the dataset are chosen. + randomize_ion_types(NX_BOOLEAN): + doc: | + Specifies if the iontypes are randomized for the point cloud or not. + Internally paraprobe uses a sequentially executed deterministic MT19987 + (MersenneTwister) pseudo-random number generator to shuffle the + iontype labels randomly across the entire set of ions. + random_number_generator(NXcs_prng): + exists: recommended + type: + seed(NX_NUMBER): + warmup(NX_NUMBER): + ion_query_type_source: + doc: | + How should the iontype be interpreted on the source-side, i.e. + all these ion positions where a regions-of-interest (ROI) around + so-called source ions will be placed. Different options exist + how iontypes are interpreted given an iontype represents + in general a (molecular) ion with different isotopes that have + individually different multiplicity. + + The value resolve_all will set an ion active in the analysis regardless + of which iontype it is. Each active ion is accounted for once. + + The value resolve_unknown will set an ion active when the ion is + of the UNKNOWNTYPE type. Each active ion is accounted for once. + + The value resolve_ion will set an ion active if it is of the specific + iontype, irregardless of its elemental or isotopic details. + Each active ion is counted once. + + The value resolve_element will set an ion active, and most importantly, + account for each as many times as the (molecular) ion contains + atoms of elements in the whitelist ion_query_isotope_vector. + + The value resolve_isotope will set an ion active, and most importantly, + account for each as many times as the (molecular) ion contains + isotopes in the whitelist ion_query_isotope_vector. + + In effect, ion_query_isotope_vector acts as a whitelist to filter + which ions are considered as source ions of the correlation statistics + and how the multiplicity of each ion will be factorized, i.e. how + often it is accounted for. + enumeration: [resolve_all, resolve_unknown, resolve_ion, resolve_element, resolve_isotope] + ion_query_isotope_vector_source(NX_UINT): + unit: NX_UNITLESS + doc: | + Matrix of isotope vectors, as many as rows as different candidates + for iontypes should be distinguished as possible source iontypes. + In the simplest case, the matrix contains only the proton number + of the element in the row, all other values set to zero. + Combined with ion_query_type_source set to resolve_element this will + recover usual spatial correlation statistics like the 1NN C-C + spatial statistics. + dimensions: + rank: 2 + dim: [[1, n_ion_source], [2, n_ivecmax]] + ion_query_type_target: + doc: | + Similarly as ion_query_type_source how should iontypes be interpreted + on the target-side, i.e. how many counts will be bookkept for ions + which are neighbors of source ions within or on the surface of each + inspection/ROI about each source ion. + Source ion in the center of the ROI are not accounted for during + counting the summary statistics. + For details about the resolve values consider the explanations in + ion_query_type_source. These account for ion_query_type_target as well. + enumeration: [resolve_all, resolve_unknown, resolve_ion, resolve_element, resolve_isotope] + + # NEW ISSUE: conditionally required only when resolve_isotope + ion_query_isotope_vector_target(NX_UINT): + unit: NX_UNITLESS + doc: | + Matrix of isotope vectors, as many as rows as different candidates for + iontypes to distinguish as possible targets. See additional comments + under ion_query_isotope_vector_source. + dimensions: + rank: 2 + dim: [[1, n_ion_target], [2, n_ivecmax]] + statistics(NXprocess): + doc: | + Specifies which spatial statistics to compute. + knn(NXprocess): + exists: optional + doc: | + Compute k-th nearest neighbour statistics. + nth(NX_UINT): + unit: NX_UNITLESS + doc: | + Order k. + histogram_min_incr_max(NX_FLOAT): + unit: NX_LENGTH + doc: | + Minimum value, increment, and maximum value of the histogram binning. + + # \@units: nm + dimensions: + rank: 1 + dim: [[1, 3]] + rdf(NXprocess): + exists: optional + doc: | + Compute radial distribution function. + histogram_min_incr_max(NX_FLOAT): + unit: NX_LENGTH + doc: | + Minimum value, increment, and maximum value of the histogram binning. + + # \@units: nm + dimensions: + rank: 1 + dim: [[1, 3]] + + # NEW ISSUE: ripleyk(NXcollection): + # NEW ISSUE: two_point(NXcollection): + performance(NXcs_profiling): + current_working_directory: + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 58f42334f6d43a13494f1bd0adfd0cac7d533a84f47f47fdd0ba75026a098e1b +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Maximum number of atoms per molecular ion. Should be 32 for paraprobe. +# +# +# +# +# Number of different sources iontypes to distinguish. +# +# +# +# +# Number of different target iontypes to distinguish. +# +# +# +# +# Configuration of a paraprobe-spatstat tool run in atom probe microscopy. +# +# +# +# +# +# Version specifier of this application definition. +# +# +# +# +# Official NeXus NXDL schema with which this file was written. +# +# +# +# +# +# +# +# Given name of the program/software/tool with which this NeXus +# (configuration) file was generated. +# +# +# +# Ideally program version plus build number, or commit hash or description +# of ever persistent resources where the source code of the program and +# build instructions can be found so that the program can be configured +# ideally in such a manner that the result of this computational process +# is recreatable in the same deterministic manner. +# +# +# +# +# +# Ideally, a (globally persistent) unique identifier for referring +# to this analysis. +# +# +# +# +# Possibility for leaving a free-text description about this analysis. +# +# +# +# +# Path to the directory where the tool should store NeXus/HDF5 results +# of this analysis. If not specified results will be stored in the +# current working directory. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when this configuration file was created. +# +# +# +# +# How many range_with_existent_iontypes processes should +# the tool execute as part of the analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The tool enables to inject precomputed distances of each ion to a +# representation of the edge of the dataset which can be used to +# control and substantially reduce edge effects when computing +# spatial statistics. +# +# +# +# Name of an HDF5 file which contains ion-to-edge distances. +# +# +# +# +# Absolute HDF5 path to the dataset with the +# ion-to-edge distance values for each ion. +# The shape of the distance values has to match the length +# of the ion positions array in dataset/dataset_name_reconstruction +# and dataset_name_mass_to_charge respectively. +# +# +# +# +# Threshold to define how large an ion has to lay at least far away +# from the edge of the dataset so that the ion can act as a source, +# i.e. that an ROI is placed at the location of the ion and its +# neighbors are analyzed how they contribute to the computed statistics. +# +# The ion_to_edge_distances threshold can be combined with a threshold +# for the ion_to_feature_distances. +# Specifically, if ion_to_feature_distances are loaded an ion only +# acts as a source if both threshold criteria are met. +# +# The threshold is useful to process the dataset such that ROIs do +# not protrude out of the dataset as this would add bias. +# +# +# +# +# +# In addition to spatial filtering, and considering how far ions lie +# to the edge of the dataset, it is possible to restrict the analyses +# to a sub-set of ions within a distance not farther away to a feature than +# a threshold value. +# +# +# +# Name of an HDF5 file which contains ion-to-feature distances. +# +# +# +# +# Absolute HDF5 path to the dataset with the +# ion-to-feature distance values for each ion. +# +# +# +# +# Threshold to define how close an ion has to lay to a feature so that +# the ion can at all qualify as a source, i.e. that an ROI is placed +# at the location of the ion and its neighbors are then analyzed +# how they contribute to the computed statistics. +# +# Recall that the ion_to_feature_distances threshold is combined +# with the ion_to_edge_distances threshold. +# +# +# +# +# +# +# Specifies if the iontypes are randomized for the point cloud or not. +# Internally paraprobe uses a sequentially executed deterministic MT19987 +# (MersenneTwister) pseudo-random number generator to shuffle the +# iontype labels randomly across the entire set of ions. +# +# +# +# +# +# +# +# +# +# How should the iontype be interpreted on the source-side, i.e. +# all these ion positions where a regions-of-interest (ROI) around +# so-called source ions will be placed. Different options exist +# how iontypes are interpreted given an iontype represents +# in general a (molecular) ion with different isotopes that have +# individually different multiplicity. +# +# The value resolve_all will set an ion active in the analysis regardless +# of which iontype it is. Each active ion is accounted for once. +# +# The value resolve_unknown will set an ion active when the ion is +# of the UNKNOWNTYPE type. Each active ion is accounted for once. +# +# The value resolve_ion will set an ion active if it is of the specific +# iontype, irregardless of its elemental or isotopic details. +# Each active ion is counted once. +# +# The value resolve_element will set an ion active, and most importantly, +# account for each as many times as the (molecular) ion contains +# atoms of elements in the whitelist ion_query_isotope_vector. +# +# The value resolve_isotope will set an ion active, and most importantly, +# account for each as many times as the (molecular) ion contains +# isotopes in the whitelist ion_query_isotope_vector. +# +# In effect, ion_query_isotope_vector acts as a whitelist to filter +# which ions are considered as source ions of the correlation statistics +# and how the multiplicity of each ion will be factorized, i.e. how +# often it is accounted for. +# +# +# +# +# +# +# +# +# +# +# +# Matrix of isotope vectors, as many as rows as different candidates +# for iontypes should be distinguished as possible source iontypes. +# In the simplest case, the matrix contains only the proton number +# of the element in the row, all other values set to zero. +# Combined with ion_query_type_source set to resolve_element this will +# recover usual spatial correlation statistics like the 1NN C-C +# spatial statistics. +# +# +# +# +# +# +# +# +# Similarly as ion_query_type_source how should iontypes be interpreted +# on the target-side, i.e. how many counts will be bookkept for ions +# which are neighbors of source ions within or on the surface of each +# inspection/ROI about each source ion. +# Source ion in the center of the ROI are not accounted for during +# counting the summary statistics. +# For details about the resolve values consider the explanations in +# ion_query_type_source. These account for ion_query_type_target as well. +# +# +# +# +# +# +# +# +# +# +# +# +# Matrix of isotope vectors, as many as rows as different candidates for +# iontypes to distinguish as possible targets. See additional comments +# under ion_query_isotope_vector_source. +# +# +# +# +# +# +# +# +# Specifies which spatial statistics to compute. +# +# +# +# Compute k-th nearest neighbour statistics. +# +# +# +# Order k. +# +# +# +# +# Minimum value, increment, and maximum value of the histogram binning. +# +# +# +# +# +# +# +# +# +# Compute radial distribution function. +# +# +# +# Minimum value, increment, and maximum value of the histogram binning. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml new file mode 100644 index 0000000000..16c2e5a93b --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml @@ -0,0 +1,509 @@ +category: application +doc: | + Configuration of a paraprobe-surfacer tool run in atom probe microscopy. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_alpha_values: | + Number of alpha values (and offset values) to probe. + n_values: | + How many different match values does the filter specify. +type: group +NXapm_paraprobe_config_surfacer(NXobject): + (NXentry): + + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + \@version: + doc: | + Version specifier of this application definition. + definition: + doc: | + Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_config_surfacer] + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + time_stamp(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + analysis_identifier: + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: | + Possibility for leaving a free-text description about this analysis. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + number_of_processes(NX_UINT): + unit: NX_UNITLESS + doc: | + For now a support field for the tool to identify how many individual + analyses the tool should executed as part of the analysis. + (NXprocess): + dataset(NXapm_input_reconstruction): + filename: + \@version: + dataset_name_reconstruction: + dataset_name_mass_to_charge: + iontypes(NXapm_input_ranging): + filename: + \@version: + group_name_iontypes: + spatial_filter(NXspatial_filter): + exists: optional + windowing_method: + (NXcg_ellipsoid_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + half_axes_radii(NX_NUMBER): + orientation(NX_NUMBER): + (NXcg_cylinder_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + height(NX_NUMBER): + radii(NX_NUMBER): + (NXcg_hexahedron_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + hexahedra(NXcg_face_list_data_structure): + (NXcs_filter_boolean_mask): + exists: optional + number_of_objects(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + identifier(NX_UINT): + + ##MK::ion_id_filter(NXcs_filter_boolean_mask): + evaporation_id_filter(NXsubsampling_filter): + exists: optional + linear_range_min_incr_max(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, 3]] + iontype_filter(NXmatch_filter): + exists: optional + method: + match(NX_NUMBER): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_values]] + hit_multiplicity_filter(NXmatch_filter): + exists: optional + method: + match(NX_NUMBER): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_values]] + surface_meshing(NXprocess): + preprocessing_method: + doc: | + Specifies the method that is used to preprocess the point cloud. + The main purpose of this setting is to specify whether the point + cloud should be segmented or not during the preprocessing + to identify which points are more likely lying close to the edge + of the point cloud. These points could be more relevant than the + interior points for certain alpha-shape constructions. + + By default no such filtering is used during pre-processing. + By contrast, the option kuehbach activates a preprocessing + during which a Hoshen-Kopelman percolation analysis is used + to identify which points are closer to the edge of the dataset. + This can reduce the number of points in the alpha-shape + computation and thus improve performance substantially. + Details about the methods are reported in + `M. Kühbach et al. `_. + enumeration: [default, kuehbach] + preprocessing_kernel_width(NX_UINT): + unit: NX_UNITLESS + + # the exists is dependant on the value for preprocessing_method + doc: | + When using the kuehbach preprocessing, this is the width of the + kernel for identifying which ions are in voxels close to the + edge of the point cloud. + alpha_value_choice: + doc: | + Specifies which method to use to define the alpha value. + The value convex_hull_naive is the default. This instructs the tool + to use a fast specialized algorithm for computing only the convex + hull. The resulting triangles can be skinny. + + The value convex_hull_refine computes first also a convex_hull_naive + but refines the mesh by triangle flipping and splitting to improve + the quality of the mesh. + + The value smallest_solid instructs the CGAL library to choose a + value which realizes an alpha-shape that is the smallest solid. + + The value cgal_optimal instructs the library to choose a value + which the library considers as an optimal value. Details are + define in the respective section of the CGAL library on 3D alpha + shapes. + + The value set_of_values instructs to compute a list of + alpha-shapes for the specified alpha-values. + + The value set_of_alpha_wrappings instructs the library to generate + a set of so-called alpha wrappings. These are a method + which is similar to alpha shapes but provide additional guarantees + though such as watertightness and proximity constraints on the + resulting wrapping. + + # NEW ISSUE: further details CGAL documentation + enumeration: [convex_hull_naive, convex_hull_refine, smallest_solid, cgal_optimal, set_of_values, set_of_alpha_wrappings] + alpha_values(NX_FLOAT): + unit: NX_ANY + doc: | + Array of alpha values to use when alpha_value_choice is set_of_values + or when alpha_value_choice is set_of_alpha_wrappings. + + # \@units: nm^2 + dimensions: + rank: 1 + dim: [[1, n_alpha_values]] + offset_values(NX_FLOAT): + unit: NX_LENGTH + doc: | + Array of offset values to use when alpha_value_choice is + set_of_alpha_wrappings. The array of alpha_values and offset_values + define a sequence of (alpha and offset value). + + # \@units: nm + dimensions: + rank: 1 + dim: [[1, n_alpha_values]] + has_exterior_facets(NX_BOOLEAN): + doc: | + Specifies if the tool should compute the set of exterior triangle + facets for each alpha complex (for convex hull, alpha shapes, and wrappings) + has_closure(NX_BOOLEAN): + doc: | + Specifies if the tool should check if the alpha complex of exterior + triangular facets is a closed polyhedron. + has_interior_tetrahedra(NX_BOOLEAN): + doc: | + Specifies if the tool should compute all interior tetrahedra + of the alpha complex (currently only for alpha shapes). + + # NEW ISSUE: has_facet_appearance(NX_BOOLEAN): + performance(NXcs_profiling): + current_working_directory: + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 5a9a515d28f8231740dc213b3a0aa41a35e3121275b016be1d7065eb8c0429ec +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of alpha values (and offset values) to probe. +# +# +# +# +# How many different match values does the filter specify. +# +# +# +# +# Configuration of a paraprobe-surfacer tool run in atom probe microscopy. +# +# +# +# +# +# Version specifier of this application definition. +# +# +# +# +# Official NeXus NXDL schema with which this file was written. +# +# +# +# +# +# +# +# Given name of the program/software/tool with which this NeXus +# (configuration) file was generated. +# +# +# +# Ideally program version plus build number, or commit hash or description +# of ever persistent resources where the source code of the program and +# build instructions can be found so that the program can be configured +# ideally in such a manner that the result of this computational process +# is recreatable in the same deterministic manner. +# +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when this configuration file was created. +# +# +# +# +# Ideally, a (globally persistent) unique identifier for referring +# to this analysis. +# +# +# +# +# Possibility for leaving a free-text description about this analysis. +# +# +# +# +# Path to the directory where the tool should store NeXus/HDF5 results +# of this analysis. If not specified results will be stored in the +# current working directory. +# +# +# +# +# For now a support field for the tool to identify how many individual +# analyses the tool should executed as part of the analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Specifies the method that is used to preprocess the point cloud. +# The main purpose of this setting is to specify whether the point +# cloud should be segmented or not during the preprocessing +# to identify which points are more likely lying close to the edge +# of the point cloud. These points could be more relevant than the +# interior points for certain alpha-shape constructions. +# +# By default no such filtering is used during pre-processing. +# By contrast, the option kuehbach activates a preprocessing +# during which a Hoshen-Kopelman percolation analysis is used +# to identify which points are closer to the edge of the dataset. +# This can reduce the number of points in the alpha-shape +# computation and thus improve performance substantially. +# Details about the methods are reported in +# `M. Kühbach et al. <https://doi.org/10.1038/s41524-020-00486-1>`_. +# +# +# +# +# +# +# +# +# +# When using the kuehbach preprocessing, this is the width of the +# kernel for identifying which ions are in voxels close to the +# edge of the point cloud. +# +# +# +# +# Specifies which method to use to define the alpha value. +# The value convex_hull_naive is the default. This instructs the tool +# to use a fast specialized algorithm for computing only the convex +# hull. The resulting triangles can be skinny. +# +# The value convex_hull_refine computes first also a convex_hull_naive +# but refines the mesh by triangle flipping and splitting to improve +# the quality of the mesh. +# +# The value smallest_solid instructs the CGAL library to choose a +# value which realizes an alpha-shape that is the smallest solid. +# +# The value cgal_optimal instructs the library to choose a value +# which the library considers as an optimal value. Details are +# define in the respective section of the CGAL library on 3D alpha +# shapes. +# +# The value set_of_values instructs to compute a list of +# alpha-shapes for the specified alpha-values. +# +# The value set_of_alpha_wrappings instructs the library to generate +# a set of so-called alpha wrappings. These are a method +# which is similar to alpha shapes but provide additional guarantees +# though such as watertightness and proximity constraints on the +# resulting wrapping. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Array of alpha values to use when alpha_value_choice is set_of_values +# or when alpha_value_choice is set_of_alpha_wrappings. +# +# +# +# +# +# +# +# +# Array of offset values to use when alpha_value_choice is +# set_of_alpha_wrappings. The array of alpha_values and offset_values +# define a sequence of (alpha and offset value). +# +# +# +# +# +# +# +# +# Specifies if the tool should compute the set of exterior triangle +# facets for each alpha complex (for convex hull, alpha shapes, and wrappings) +# +# +# +# +# Specifies if the tool should check if the alpha complex of exterior +# triangular facets is a closed polyhedron. +# +# +# +# +# Specifies if the tool should compute all interior tetrahedra +# of the alpha complex (currently only for alpha shapes). +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml new file mode 100644 index 0000000000..659f5f1894 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml @@ -0,0 +1,449 @@ +category: application +doc: | + Configuration of a paraprobe-tessellator tool run in atom probe microscopy. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + +# n_control_points: The number of control points for tessellating regions instead of tessellating the volume about ion positions. +type: group +NXapm_paraprobe_config_tessellator(NXobject): + (NXentry): + + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + \@version: + doc: | + Version specifier of this application definition. + definition: + doc: | + Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_config_tessellator] + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + analysis_identifier: + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: | + Possibility for leaving a free-text description about this analysis. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + time_stamp(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + number_of_processes(NX_UINT): + unit: NX_UNITLESS + doc: | + How many individual analyses should the tool execute. + (NXprocess): + dataset(NXapm_input_reconstruction): + filename: + \@version: + dataset_name_reconstruction: + dataset_name_mass_to_charge: + iontypes(NXapm_input_ranging): + filename: + \@version: + group_name_iontypes: + spatial_filter(NXspatial_filter): + exists: optional + windowing_method: + (NXcg_ellipsoid_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + half_axes_radii(NX_NUMBER): + orientation(NX_NUMBER): + (NXcg_cylinder_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + height(NX_NUMBER): + radii(NX_NUMBER): + (NXcg_hexahedron_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + hexahedra(NXcg_face_list_data_structure): + (NXcs_filter_boolean_mask): + exists: optional + number_of_objects(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + identifier(NX_UINT): + + # a perfect example for limited conditions in NeXus + # if windowing_method is entire_dataset: no constraint on existence of NXcg and NXcs instances + # if windowing_method is union_of_primitives: sum of cardinality of NXcg >= 0 + # if windowing_method is bitmasked_points: sum cardinality of NXcg := 0 and cardinality of NXcs_filter_boolean_mask == 1 + evaporation_id_filter(NXsubsampling_filter): + exists: optional + iontype_filter(NXmatch_filter): + exists: optional + hit_multiplicity_filter(NXmatch_filter): + exists: optional + ion_to_edge_distances(NXprocess): + exists: optional + doc: | + The tool enables to inject precomputed distance information for + each point which can be used for further post-processing and analysis. + filename: + doc: | + Name of an HDF5 file which contains the ion distances. + Users are responsible this file and referred to dataset under + dataset_name have an ion_distance value for each ion. + \@version: + doc: | + Version identifier of the file such as a secure hash which + documents the binary state of the file to add an additional layer of + reproducibility. + dataset_name: + doc: | + Absolute HDF5 path to the dataset with distance values for each ion. + tessellating(NXprocess): + method: + doc: | + Specifies for which points the tool will compute the tessellation. + By default, a Voronoi tessellation is computed for all ions in the + filtered point cloud. + + # The value control_points will compute the tessellation for the + # provided overlay_control_points irregardless of the ion point cloud. + # This enables for instance computations as proposed by P. Felfer and + # coworkers where, for the purpose of e.g. interfacial excess quantification, + # a tessellation of the dataset into regions about manually-specified + # control points is needed. + # For this option, the overlay_control points. + enumeration: [default] + + # overlay_control_points(NXprocess): + # doc: | + # Overlaying an additional set of control points onto the reconstruction + # can be used as a first step to construct a tessellation of the dataset + # into regions to segment the dataset or construct a model for internal + # structural features in the dataset. Such an approach was suggested + # e.g. by P. Felfer et al. which use a control points to locate + # interfaces (grain/phase boundaries) in atom probe data to perform + # e.g. interfacial excess computations. The control points can be + # imported for example from some manual preprocessing of a dataset + # where the user figured these control points could be of relevance + # for the analysis. + # NEW ISSUE: dislocation lines + # exists: optional + # filename: + # doc: | + # Name of an HDF5 file which contains control point coordinates. + # \@version: + # doc: | + # Version identifier of the file such as a secure hash which + # documents the binary state of the file to add an additional + # layer of reproducibility. + # dataset_name: + # doc: | + # Absolute HDF5 path to the dataset which contains the array of + # control points. This has to be an array of shape + # (n_control_points, 3). + has_cell_volume(NX_BOOLEAN): + doc: | + Specifies if the tool should report the volume of each cell. + has_cell_neighbors(NX_BOOLEAN): + doc: | + Specifies if the tool should report the first-order neighbors of each cell. + has_cell_geometry(NX_BOOLEAN): + doc: | + Specifies if the tool should report the facets and vertices of each cell. + has_cell_edge_detection(NX_BOOLEAN): + doc: | + Specifies if the tool should report if the cell makes contact with + the tight axis-aligned bounding box about the point cloud. + This can be used to identify if the shape of the cell is affected + by the edge of the dataset or if cells are deeply enough embedded + into the point cloud so that the shape of their cells are not affected + by the presence of the boundary. + + # erosion_distance(NX_FLOAT): + # doc: | + # Maximum distance for which cells are eroded. + # unit: NX_LENGTH + # \@units: nm + # minValue: EPSILON + performance(NXcs_profiling): + current_working_directory: + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 7865be535bda4bc76ce207bee2d62dff19d30dcf9c5bb661e5eb5304b271cdfa +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Configuration of a paraprobe-tessellator tool run in atom probe microscopy. +# +# +# +# +# +# Version specifier of this application definition. +# +# +# +# +# Official NeXus NXDL schema with which this file was written. +# +# +# +# +# +# +# +# Given name of the program/software/tool with which this NeXus +# (configuration) file was generated. +# +# +# +# Ideally program version plus build number, or commit hash or description +# of ever persistent resources where the source code of the program and +# build instructions can be found so that the program can be configured +# ideally in such a manner that the result of this computational process +# is recreatable in the same deterministic manner. +# +# +# +# +# +# Ideally, a (globally persistent) unique identifier for referring +# to this analysis. +# +# +# +# +# Possibility for leaving a free-text description about this analysis. +# +# +# +# +# Path to the directory where the tool should store NeXus/HDF5 results +# of this analysis. If not specified results will be stored in the +# current working directory. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when this configuration file was created. +# +# +# +# +# How many individual analyses should the tool execute. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The tool enables to inject precomputed distance information for +# each point which can be used for further post-processing and analysis. +# +# +# +# Name of an HDF5 file which contains the ion distances. +# Users are responsible this file and referred to dataset under +# dataset_name have an ion_distance value for each ion. +# +# +# +# Version identifier of the file such as a secure hash which +# documents the binary state of the file to add an additional layer of +# reproducibility. +# +# +# +# +# +# Absolute HDF5 path to the dataset with distance values for each ion. +# +# +# +# +# +# +# Specifies for which points the tool will compute the tessellation. +# By default, a Voronoi tessellation is computed for all ions in the +# filtered point cloud. +# +# +# +# +# +# +# +# +# +# Specifies if the tool should report the volume of each cell. +# +# +# +# +# Specifies if the tool should report the first-order neighbors of each cell. +# +# +# +# +# Specifies if the tool should report the facets and vertices of each cell. +# +# +# +# +# Specifies if the tool should report if the cell makes contact with +# the tight axis-aligned bounding box about the point cloud. +# This can be used to identify if the shape of the cell is affected +# by the edge of the dataset or if cells are deeply enough embedded +# into the point cloud so that the shape of their cells are not affected +# by the presence of the boundary. +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.yaml new file mode 100644 index 0000000000..54d60db881 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.yaml @@ -0,0 +1,194 @@ +category: application +doc: | + Configurations of a paraprobe-transcoder tool run in atom probe microscopy. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXapm_paraprobe_config_transcoder(NXobject): + (NXentry): + exists: ['min', '1', 'max', '1'] + + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + \@version: + doc: | + Version specifier of this application definition. + definition: + doc: | + Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_config_transcoder] + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ideally an ever persistent resource where the source code of the + program and build instructions can be found so that the program can be + configured ideally in such a manner that the result of this computational + process is recreatable deterministically. + analysis_identifier: + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: | + Possibility for leaving a free-text description about this analysis. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + time_stamp(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + (NXprocess): + + # NXapm_input base classes are specialized here because + # paraprobe-transcoder is the entry point for community data + # which are not necessarily NeXus + dataset(NXapm_input_reconstruction): + filename: + doc: | + The path and name of the file (technology partner or community format) + from which to read the reconstructed ion positions. Currently, POS, + ePOS, APT files from APSuite, and NXS, i.e. NeXus/HDF5 files + are supported. + \@version: + iontypes(NXapm_input_ranging): + filename: + doc: | + The path and name of the file (technology partner or community format + from which to read the ranging definitions, i.e. how to map mass-to- + charge-state ratios on iontypes. Currently, RRNG, RNG, and NXS, i.e. + NeXus/HDF5 files are supported. + \@version: + performance(NXcs_profiling): + current_working_directory: + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# a6bb541ba6bb20a2561dada516be874b81ae4ac0ce0d78d69658da4fe7270f70 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Configurations of a paraprobe-transcoder tool run in atom probe microscopy. +# +# +# +# +# +# Version specifier of this application definition. +# +# +# +# +# Official NeXus NXDL schema with which this file was written. +# +# +# +# +# +# +# +# Given name of the program/software/tool with which this NeXus +# (configuration) file was generated. +# +# +# +# Ideally program version plus build number, or commit hash or description +# of ideally an ever persistent resource where the source code of the +# program and build instructions can be found so that the program can be +# configured ideally in such a manner that the result of this computational +# process is recreatable deterministically. +# +# +# +# +# +# Ideally, a (globally persistent) unique identifier for referring +# to this analysis. +# +# +# +# +# Possibility for leaving a free-text description about this analysis. +# +# +# +# +# Path to the directory where the tool should store NeXus/HDF5 results +# of this analysis. If not specified results will be stored in the +# current working directory. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when this configuration file was created. +# +# +# +# +# +# +# +# The path and name of the file (technology partner or community format) +# from which to read the reconstructed ion positions. Currently, POS, +# ePOS, APT files from APSuite, and NXS, i.e. NeXus/HDF5 files +# are supported. +# +# +# +# +# +# +# +# The path and name of the file (technology partner or community format +# from which to read the ranging definitions, i.e. how to map mass-to- +# charge-state ratios on iontypes. Currently, RRNG, RNG, and NXS, i.e. +# NeXus/HDF5 files are supported. +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.yaml new file mode 100644 index 0000000000..08186843e9 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.yaml @@ -0,0 +1,960 @@ +category: application +doc: | + Results of a paraprobe-clusterer tool run. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_ions: | + The total number of ions in the reconstruction. + n_dict: | + The total number of entries in the restricted_identifier dictionary. +type: group +NXapm_paraprobe_results_clusterer(NXobject): + + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + (NXentry): + exists: ['min', '1', 'max', '1'] + \@version: + doc: | + Version specifier of this application definition. + + ##MK::begin of the tool-specific section + definition: + doc: | + Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_results_clusterer] + + ##MK::end of the tool-specific section + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + analysis_identifier: + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: | + Possibility for leaving a free-text description about this analysis. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + config_filename: + doc: | + The absolute path and name of the config file for this analysis. + \@version: + doc: | + At least SHA256 strong hash of the specific config_file for + tracking provenance. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + status: + doc: | + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must no longer compute analyses. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases, it might be + that the executable has terminated prematurely or another error + occurred. + enumeration: [success, failure] + (NXuser): + exists: optional + doc: | + If used, contact information and eventually details + of at least the person who performed this analysis. + name: + affiliation: + exists: recommended + address: + exists: optional + email: + exists: recommended + orcid: + exists: recommended + orcid_platform: + exists: recommended + telephone_number: + exists: optional + role: + exists: recommended + social_media_name: + exists: optional + social_media_platform: + exists: optional + (NXcoordinate_system_set): + doc: | + Details about the coordinate system conventions used. + If nothing else is specified we assume that there + has to be at least one set of NXtransformations named + paraprobe defined, which specifies the coordinate system. + In which all positions are defined. + + ##MK::define also reconstruction coordinate system and + ##MK::map between the two + (NXtransformations): + exists: ['min', '1', 'max', 'unbounded'] + doc: | + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + ##MK::begin of the tool-specific section + (NXprocess): + exists: ['min', '0', 'max', '1'] + window(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies which of the ions in the dataset were + analyzed during this process. + number_of_ions(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of ions covered by the mask. + The mask value for most may be 0. + bitdepth(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + mask(NX_UINT): + unit: NX_UNITLESS + doc: | + The unsigned integer array representing the content of the mask. + If padding is used, padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe-toolbox executable. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth (padding). + dimensions: + rank: 1 + dim: [[1, n_ions]] + cluster_analysis(NXprocess): + exists: optional + doc: | + The result of a cluster analyses. These include typically the label for + each ion/point documenting to which feature (if any) an ion is assigned. + Typically, each analysis/run yields only a single cluster. + In cases of fuzzy clustering it can be possible that an ion is assigned + to multiple cluster (eventually with different) weight/probability. + dbscanID(NXsimilarity_grouping): + exists: ['min', '0', 'max', 'unbounded'] + doc: | + Results of a DBScan clustering analysis. + eps(NX_FLOAT): + unit: NX_LENGTH + doc: | + The epsilon (eps) parameter. + min_pts(NX_UINT): + unit: NX_UNITLESS + doc: | + The minimum points (min_pts) parameter. + cardinality(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of members in the set which is partitioned into features. + Specifically, this is the total number of targets filtered from the + dataset. Cardinality here is not the total number of ions in the + dataset. + + # number_of_numeric_labels(NX_UINT): + # doc: | + # How many numerical labels does each feature have. + # unit: NX_UNITLESS + # number_of_categorical_labels(NX_UINT): + # doc: | + # How many categorical labels does each feature have. + # unit: NX_UNITLESS + # features: + # doc: | + # Reference to a set of features investigated in a cluster analysis. + # Features need to have disjoint numeric identifier. + identifier_offset(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Which identifier is the first to be used to label a cluster. + + The value should be chosen in such a way that special values can be resolved: + * identifier_offset-1 indicates an object belongs to no cluster. + * identifier_offset-2 indicates an object belongs to the noise category. + Setting for instance identifier_offset to 1 recovers the commonly used + case that objects of the noise category get values to -1 and unassigned points to 0. + Numerical identifier have to be strictly increasing. + + # dimensions: + # rank: 1 + # dim: [[1, n_lbl_num]] + # reserved_identifier_keyword(NX_UINT): + # doc: | + # By default we assume that cluster identifier 0 is reserved to + # mark that ions are not assigned to a cluster and identifier 1 is + # noise. The reserved_identifier_keyword and reserved_identifier_value + # can be used as a dictionary though to define that users + # which to overwrite this default and define own specific categories. + # In every case though cluster_identifier have to be positive integer + # and be consecutive on $[0, maximum_value]$. + # unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, n_dict]] + # reserved_identifier_value: + # doc: | + # The corresponding value of the reserved_identifier dictionary. + # This can give a free-text description what a specific reserved + # ID specifies e.g. ignored, noise. + # unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, n_dict]] + targets(NX_UINT): + unit: NX_UNITLESS + doc: | + The evaporation sequence identifier to figure out which ions + from the reconstruction were considered targets. + dimensions: + rank: 1 + dim: [[1, c]] + + # quantities for debugging purposes + model_labels(NX_INT): + unit: NX_UNITLESS + doc: | + The raw labels from the DBScan clustering backend process. + dimensions: + rank: 1 + dim: [[1, c]] + core_sample_indices(NX_INT): + unit: NX_UNITLESS + doc: | + The raw array of core sample indices which specify which of the + targets are core points. + dimensions: + rank: 1 + dim: [[1, n]] + + # quantities to which these debugging quantities should be transformed + numerical_label(NX_UINT): + unit: NX_UNITLESS + doc: | + Matrix of numerical label for each member in the set. + For classical clustering algorithms this can for instance + encode the cluster_identifier. + dimensions: + rank: 1 + dim: [[1, c]] + + # categorical_label: + # doc: | + # Matrix of categorical attribute data for each member in the set. + # dimensions: + # rank: 2 + # dim: [[1, c], [2, n_lbl_cat]] + weight(NX_NUMBER): + exists: optional + unit: NX_UNITLESS + doc: | + The array of weight which specifies how surely/likely the + cluster is associated/assigned to a specific identifier as + is specified in the cluster_identifier array. + For the DBScan and atom probe tomography the multiplicity + of each ion with respect to the cluster. That is how many times + should the position of the ion be accounted for because the ion + is e.g. a molecular ion with several elements or isotope of + requested type. + dimensions: + rank: 1 + dim: [[1, c]] + is_noise(NX_BOOLEAN): + exists: optional + doc: | + Optional bitmask encoding if members of the set are assigned to as noise or not. + dimensions: + rank: 1 + dim: [[1, c]] + is_core(NX_BOOLEAN): + exists: optional + doc: | + Optional bitmask encoding if member of the set are a core point. + For details to which feature/cluster an ion/point is a core point + consider numerical_label. + dimensions: + rank: 1 + dim: [[1, c]] + statistics(NXprocess): + doc: | + In addition to the detailed storage which members was grouped to + which feature/group summary statistics are stored under this group. + + # at the level of the set + # number_of_unassigned_members(NX_UINT): + # doc: | + # Total number of members in the set which are categorized as unassigned. + # unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, n_lbl_num]] + number_of_noise(NX_UINT): + unit: NX_UNITLESS + doc: | + Total number of members in the set which are categorized as noise. + + # dimensions: + # rank: 1 + # dim: [[1, n_lbl_num]] + number_of_core(NX_UINT): + unit: NX_UNITLESS + doc: | + Total number of members in the set which are categorized as a core point. + + # dimensions: + # rank: 1 + # dim: [[1, n_lbl_num]] + # at the level of the feature set + number_of_features(NX_UINT): + unit: NX_UNITLESS + doc: | + Total number of clusters (excluding noise and unassigned). + feature_identifier(NX_UINT): + unit: NX_UNITLESS + doc: | + Array of numerical identifier of each feature (cluster). + dimensions: + rank: 1 + dim: [[1, n_features]] + feature_member_count(NX_UINT): + unit: NX_UNITLESS + doc: | + Array of number of members for each feature. + dimensions: + rank: 1 + dim: [[1, n_features]] + + # ADD FURTHER RESULTS along the same pattern for e.g. OPTICS and HDBSCAN + + ##MK::end of the tool-specific section + performance(NXcs_profiling): + exists: recommended + current_working_directory: + command_line_call: + exists: optional + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + total_elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): + (NXcs_computer): + exists: recommended + name: + exists: recommended + operating_system: + \@version: + uuid: + exists: optional + (NXcs_cpu): + exists: ['min', '0', 'max', 'unbounded'] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_gpu): + exists: ['min', '0', 'max', 'unbounded'] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_mm_sys): + exists: ['min', '0', 'max', '1'] + total_physical_memory(NX_NUMBER): + (NXcs_io_sys): + exists: ['min', '0', 'max', '1'] + (NXcs_io_obj): + exists: ['min', '1', 'max', 'unbounded'] + technology: + max_physical_capacity(NX_NUMBER): + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_profiling_event): + start_time(NX_DATE_TIME): + exists: optional + end_time(NX_DATE_TIME): + exists: optional + description: + elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + number_of_threads(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + number_of_gpus(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + max_virtual_memory_snapshot(NX_NUMBER): + exists: recommended + max_resident_memory_snapshot(NX_NUMBER): + exists: recommended + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# b3a37df81b97bc33a6f0f18e802898a70c94977a92b2e598360ceb871ee5cd9c +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The total number of ions in the reconstruction. +# +# +# +# +# The total number of entries in the restricted_identifier dictionary. +# +# +# +# +# Results of a paraprobe-clusterer tool run. +# +# +# +# +# +# Version specifier of this application definition. +# +# +# +# +# +# Official NeXus NXDL schema with which this file was written. +# +# +# +# +# +# +# +# +# Given name of the program/software/tool with which this NeXus +# (configuration) file was generated. +# +# +# +# Ideally program version plus build number, or commit hash or description +# of ever persistent resources where the source code of the program and +# build instructions can be found so that the program can be configured +# ideally in such a manner that the result of this computational process +# is recreatable in the same deterministic manner. +# +# +# +# +# +# Ideally, a (globally persistent) unique identifier for referring +# to this analysis. +# +# +# +# +# Possibility for leaving a free-text description about this analysis. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when the analysis behind this results file +# was started, i.e. the paraprobe-tool executable started as a process. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when the analysis behind this results file +# were completed and the paraprobe-tool executable exited as a process. +# +# +# +# +# The absolute path and name of the config file for this analysis. +# +# +# +# At least SHA256 strong hash of the specific config_file for +# tracking provenance. +# +# +# +# +# +# Path to the directory where the tool should store NeXus/HDF5 results +# of this analysis. If not specified results will be stored in the +# current working directory. +# +# +# +# +# A statement whether the paraprobe-tool executable managed to +# process the analysis or failed prematurely. +# +# This status is written to the results file after the end_time +# at which point the executable must no longer compute analyses. +# Only when this status message is present and shows `success`, the +# user should consider the results. In all other cases, it might be +# that the executable has terminated prematurely or another error +# occurred. +# +# +# +# +# +# +# +# +# If used, contact information and eventually details +# of at least the person who performed this analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Details about the coordinate system conventions used. +# If nothing else is specified we assume that there +# has to be at least one set of NXtransformations named +# paraprobe defined, which specifies the coordinate system. +# In which all positions are defined. +# +# +# +# +# The individual coordinate systems which should be used. +# Field names should be prefixed with the following controlled terms +# indicating which individual coordinate system is described: +# +# * paraprobe +# * lab +# * specimen +# * laser +# * leap +# * detector +# * recon +# +# +# +# +# +# +# +# A bitmask which identifies which of the ions in the dataset were +# analyzed during this process. +# +# +# +# Number of ions covered by the mask. +# The mask value for most may be 0. +# +# +# +# +# Number of bits assumed matching on a default datatype. +# (e.g. 8 bits for a C-style uint8). +# +# +# +# +# The unsigned integer array representing the content of the mask. +# If padding is used, padded bits are set to 0. The mask is for +# convenience always as large as the entire dataset as it will +# be stored compressed anyway. The convenience feature with this +# is that then the mask can be decoded with numpy and mirrored +# against the evaporation_id array and one immediately can filter +# out all points that were used by the paraprobe-toolbox executable. +# The length of the array adds to the next unsigned integer +# if the number of ions in the dataset is not an integer +# multiple of the bitdepth (padding). +# +# +# +# +# +# +# +# +# The result of a cluster analyses. These include typically the label for +# each ion/point documenting to which feature (if any) an ion is assigned. +# Typically, each analysis/run yields only a single cluster. +# In cases of fuzzy clustering it can be possible that an ion is assigned +# to multiple cluster (eventually with different) weight/probability. +# +# +# +# Results of a DBScan clustering analysis. +# +# +# +# The epsilon (eps) parameter. +# +# +# +# +# The minimum points (min_pts) parameter. +# +# +# +# +# Number of members in the set which is partitioned into features. +# Specifically, this is the total number of targets filtered from the +# dataset. Cardinality here is not the total number of ions in the +# dataset. +# +# +# +# +# +# Which identifier is the first to be used to label a cluster. +# +# The value should be chosen in such a way that special values can be resolved: +# * identifier_offset-1 indicates an object belongs to no cluster. +# * identifier_offset-2 indicates an object belongs to the noise category. +# Setting for instance identifier_offset to 1 recovers the commonly used +# case that objects of the noise category get values to -1 and unassigned points to 0. +# Numerical identifier have to be strictly increasing. +# +# +# +# +# +# The evaporation sequence identifier to figure out which ions +# from the reconstruction were considered targets. +# +# +# +# +# +# +# +# +# The raw labels from the DBScan clustering backend process. +# +# +# +# +# +# +# +# The raw array of core sample indices which specify which of the +# targets are core points. +# +# +# +# +# +# +# +# +# Matrix of numerical label for each member in the set. +# For classical clustering algorithms this can for instance +# encode the cluster_identifier. +# +# +# +# +# +# +# +# +# The array of weight which specifies how surely/likely the +# cluster is associated/assigned to a specific identifier as +# is specified in the cluster_identifier array. +# For the DBScan and atom probe tomography the multiplicity +# of each ion with respect to the cluster. That is how many times +# should the position of the ion be accounted for because the ion +# is e.g. a molecular ion with several elements or isotope of +# requested type. +# +# +# +# +# +# +# +# Optional bitmask encoding if members of the set are assigned to as noise or not. +# +# +# +# +# +# +# +# Optional bitmask encoding if member of the set are a core point. +# For details to which feature/cluster an ion/point is a core point +# consider numerical_label. +# +# +# +# +# +# +# +# In addition to the detailed storage which members was grouped to +# which feature/group summary statistics are stored under this group. +# +# +# +# +# Total number of members in the set which are categorized as noise. +# +# +# +# +# +# Total number of members in the set which are categorized as a core point. +# +# +# +# +# +# Total number of clusters (excluding noise and unassigned). +# +# +# +# +# Array of numerical identifier of each feature (cluster). +# +# +# +# +# +# +# +# Array of number of members for each feature. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Specify if it was different from the number_of_processes +# in the NXcs_profiling super class. +# +# +# +# +# +# Specify if it was different from the number_of_threads +# in the NXcs_profiling super class. +# +# +# +# +# +# Specify if it was different from the number_of_threads +# in the NXcs_profiling super class. +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.yaml new file mode 100644 index 0000000000..3ca5378087 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.yaml @@ -0,0 +1,730 @@ +category: application +doc: | + Results of a paraprobe-distancer tool run. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_ions: | + The total number of ions in the reconstruction. + n_tris: | + The total number of triangles in the set. +type: group +NXapm_paraprobe_results_distancer(NXobject): + + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + (NXentry): + exists: ['min', '1', 'max', '1'] + \@version: + doc: | + Version specifier of this application definition. + + ##MK::begin of the tool-specific section + definition: + doc: | + Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_results_distancer] + + ##MK::end of the tool-specific section + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + analysis_identifier: + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: | + Possibility for leaving a free-text description about this analysis. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + config_filename: + doc: | + The absolute path and name of the config file for this analysis. + \@version: + doc: | + At least SHA256 strong hash of the specific config_file for + tracking provenance. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + status: + doc: | + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + enumeration: [success, failure] + (NXuser): + exists: recommended + doc: | + If used, contact information and eventually details + of at least the person who performed this analysis. + name: + affiliation: + exists: recommended + address: + exists: optional + email: + exists: recommended + orcid: + exists: recommended + orcid_platform: + exists: recommended + telephone_number: + exists: optional + role: + exists: recommended + social_media_name: + exists: optional + social_media_platform: + exists: optional + (NXcoordinate_system_set): + doc: | + Details about the coordinate system conventions used. + (NXtransformations): + exists: ['min', '1', 'max', 'unbounded'] + doc: | + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + ##MK::begin of the tool-specific section + (NXprocess): + exists: ['min', '0', 'max', '1'] + point_to_triangle_set(NXprocess): + doc: | + The tool can be used to compute the analytical distance of each ion + to a set of triangles. + window(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies which of the ions in the dataset were + analyzed. + number_of_ions(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of ions covered by the mask. + The mask value for most may be 0. + + # which does paraprobe use + bitdepth(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + mask(NX_UINT): + unit: NX_UNITLESS + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + dimensions: + rank: 1 + dim: [[1, n_ions]] + window_triangles(NXcs_filter_boolean_mask): + exists: optional + doc: | + A bitmask which identifies which of the triangles in the set + were considered. Usually these are all but sometimes users may + wish to filter certain portions of the triangles out. + If window_triangles is not provided it means that + all triangles were taken. + number_of_triangles(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of triangles covered by the mask. + The mask value for most may be 0. + bitdepth(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + mask(NX_UINT): + unit: NX_UNITLESS + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + dimensions: + rank: 1 + dim: [[1, n_triangles]] + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + The closest analytical distance of the ions to their respectively + closest triangle from the triangle set. + dimensions: + rank: 1 + dim: [[1, i]] + sign_valid(NXcs_filter_boolean_mask): + exists: optional + doc: | + A bitmask which identifies which of the distance values + can be assumed to have a consistent sign because the closest + triangle had a consistent outer unit normal defined. + For points whose bit is set 0 the distance is correct but the + sign is not reliable. + number_of_points(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of triangles covered by the mask. + The mask value for most may be 0. + + # which does paraprobe use + bitdepth(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + mask(NX_UINT): + unit: NX_UNITLESS + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. + dimensions: + rank: 1 + dim: [[1, i]] + triangle_identifier(NX_UINT): + exists: optional + unit: NX_UNITLESS + doc: | + The identifier of the triangle that is closest for each ion. + dimensions: + rank: 1 + dim: [[1, i]] + xdmf_ion_identifier(NX_UINT): + exists: optional + unit: NX_UNITLESS + doc: | + A support field to visualize each ion and with this the distance + informations using XDMF and e.g. Paraview. + dimensions: + rank: 1 + dim: [[1, i]] + + ##MK::end of the tool-specific section + performance(NXcs_profiling): + exists: recommended + current_working_directory: + command_line_call: + exists: optional + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + total_elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): + (NXcs_computer): + exists: recommended + name: + exists: recommended + operating_system: + \@version: + uuid: + exists: optional + (NXcs_cpu): + exists: ['min', '0', 'max', 'unbounded'] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_gpu): + exists: ['min', '0', 'max', 'unbounded'] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_mm_sys): + exists: ['min', '0', 'max', '1'] + total_physical_memory(NX_NUMBER): + (NXcs_io_sys): + exists: ['min', '0', 'max', '1'] + (NXcs_io_obj): + exists: ['min', '1', 'max', 'unbounded'] + technology: + max_physical_capacity(NX_NUMBER): + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_profiling_event): + start_time(NX_DATE_TIME): + exists: optional + end_time(NX_DATE_TIME): + exists: optional + description: + elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + number_of_threads(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + number_of_gpus(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + max_virtual_memory_snapshot(NX_NUMBER): + exists: recommended + max_resident_memory_snapshot(NX_NUMBER): + exists: recommended + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# db9beb02a1f399f796e0d37bfa5d97ad75aba6c4ba62980e392a3e9b517c1442 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The total number of ions in the reconstruction. +# +# +# +# +# The total number of triangles in the set. +# +# +# +# +# Results of a paraprobe-distancer tool run. +# +# +# +# +# +# Version specifier of this application definition. +# +# +# +# +# +# Official NeXus NXDL schema with which this file was written. +# +# +# +# +# +# +# +# +# Given name of the program/software/tool with which this NeXus +# (configuration) file was generated. +# +# +# +# Ideally program version plus build number, or commit hash or description +# of ever persistent resources where the source code of the program and +# build instructions can be found so that the program can be configured +# ideally in such a manner that the result of this computational process +# is recreatable in the same deterministic manner. +# +# +# +# +# +# Ideally, a (globally persistent) unique identifier for referring +# to this analysis. +# +# +# +# +# Possibility for leaving a free-text description about this analysis. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when the analysis behind this results file +# was started, i.e. the paraprobe-tool executable started as a process. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when the analysis behind this results file +# were completed and the paraprobe-tool executable exited as a process. +# +# +# +# +# The absolute path and name of the config file for this analysis. +# +# +# +# At least SHA256 strong hash of the specific config_file for +# tracking provenance. +# +# +# +# +# +# Path to the directory where the tool should store NeXus/HDF5 results +# of this analysis. If not specified results will be stored in the +# current working directory. +# +# +# +# +# A statement whether the paraprobe-tool executable managed to +# process the analysis or failed prematurely. +# +# This status is written to the results file after the end_time +# at which point the executable must not compute any analysis. +# Only when this status message is present and shows `success`, the +# user should consider the results. In all other cases it might be +# that the executable has terminated prematurely or another error +# occurred. +# +# +# +# +# +# +# +# +# If used, contact information and eventually details +# of at least the person who performed this analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Details about the coordinate system conventions used. +# +# +# +# The individual coordinate systems which should be used. +# Field names should be prefixed with the following controlled terms +# indicating which individual coordinate system is described: +# +# * paraprobe +# * lab +# * specimen +# * laser +# * leap +# * detector +# * recon +# +# +# +# +# +# +# +# The tool can be used to compute the analytical distance of each ion +# to a set of triangles. +# +# +# +# A bitmask which identifies which of the ions in the dataset were +# analyzed. +# +# +# +# Number of ions covered by the mask. +# The mask value for most may be 0. +# +# +# +# +# +# Number of bits assumed matching on a default datatype. +# (e.g. 8 bits for a C-style uint8). +# +# +# +# +# The unsigned integer array representing the content of the mask. +# If padding is used the padded bits are set to 0. The mask is for +# convenience always as large as the entire dataset as it will +# be stored compressed anyway. The convenience feature with this +# is that then the mask can be decoded with numpy and mirrored +# against the evaporation_id array and one immediately can filter +# out all points that were used by the paraprobe. +# The length of the array adds to the next unsigned integer +# if the number of ions in the dataset is not an integer +# multiple of the bitdepth. +# +# +# +# +# +# +# +# +# A bitmask which identifies which of the triangles in the set +# were considered. Usually these are all but sometimes users may +# wish to filter certain portions of the triangles out. +# If window_triangles is not provided it means that +# all triangles were taken. +# +# +# +# Number of triangles covered by the mask. +# The mask value for most may be 0. +# +# +# +# +# Number of bits assumed matching on a default datatype. +# (e.g. 8 bits for a C-style uint8). +# +# +# +# +# The unsigned integer array representing the content of the mask. +# If padding is used the padded bits are set to 0. The mask is for +# convenience always as large as the entire dataset as it will +# be stored compressed anyway. The convenience feature with this +# is that then the mask can be decoded with numpy and mirrored +# against the evaporation_id array and one immediately can filter +# out all points that were used by the paraprobe. +# The length of the array adds to the next unsigned integer +# if the number of ions in the dataset is not an integer +# multiple of the bitdepth. +# +# +# +# +# +# +# +# +# The closest analytical distance of the ions to their respectively +# closest triangle from the triangle set. +# +# +# +# +# +# +# +# A bitmask which identifies which of the distance values +# can be assumed to have a consistent sign because the closest +# triangle had a consistent outer unit normal defined. +# For points whose bit is set 0 the distance is correct but the +# sign is not reliable. +# +# +# +# Number of triangles covered by the mask. +# The mask value for most may be 0. +# +# +# +# +# +# Number of bits assumed matching on a default datatype. +# (e.g. 8 bits for a C-style uint8). +# +# +# +# +# The unsigned integer array representing the content of the mask. +# If padding is used the padded bits are set to 0. +# +# +# +# +# +# +# +# +# The identifier of the triangle that is closest for each ion. +# +# +# +# +# +# +# +# A support field to visualize each ion and with this the distance +# informations using XDMF and e.g. Paraview. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Specify if it was different from the number_of_processes +# in the NXcs_profiling super class. +# +# +# +# +# +# Specify if it was different from the number_of_threads +# in the NXcs_profiling super class. +# +# +# +# +# +# Specify if it was different from the number_of_threads +# in the NXcs_profiling super class. +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.yaml new file mode 100644 index 0000000000..7d93939ffe --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.yaml @@ -0,0 +1,736 @@ +category: application +doc: | + Results of a paraprobe-intersector tool run. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_c2n: | + The total number of links pointing from current to next. + n_n2c: | + The total number of links pointing from next to current. + n_features_curr: | + The total number of members in the current_set. + n_features_next: | + The total number of members in the next_set. + n_cluster: | + The total number of cluster found for coprecipitation analysis. + n_total: | + The number of rows in the table/matrix for coprecipitation stats. +type: group +NXapm_paraprobe_results_intersector(NXobject): + (NXentry): + + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + \@version: + doc: | + Version specifier of this application definition. + + ##MK::begin of the tool-specific section + definition: + doc: | + Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_results_intersector] + + ##MK::end of the tool-specific section + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + analysis_identifier: + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: | + Possibility for leaving a free-text description about this analysis. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + config_filename: + doc: | + The absolute path and name of the config file for this analysis. + \@version: + doc: | + At least SHA256 strong hash of the specific config_file for + tracking provenance. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + (NXuser): + exists: recommended + doc: | + If used, contact information and eventually details + of at least the person who performed this analysis. + name: + affiliation: + exists: recommended + address: + exists: optional + email: + exists: recommended + orcid: + exists: recommended + orcid_platform: + exists: recommended + telephone_number: + exists: optional + role: + exists: recommended + social_media_name: + exists: optional + social_media_platform: + exists: optional + (NXcoordinate_system_set): + exists: optional + doc: | + Details about the coordinate system conventions used. + (NXtransformations): + exists: ['min', '1', 'max', 'unbounded'] + doc: | + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + ##MK::begin of the tool-specific section + (NXprocess): + VOLUME_VOLUME_SPATIAL_CORRELATION(NXprocess): + exists: ['min', '0', 'max', '1'] + doc: | + The results of an overlap/intersection analysis. + current_to_next_link(NX_UINT): + unit: NX_UNITLESS + doc: | + A matrix of feature_identifier which specifies which named features + from the current set have directed link(s) pointing to which named + feature(s) from the next set. + dimensions: + rank: 2 + dim: [[1, n_c2n], [2, 2]] + current_to_next_link_type(NX_UINT): + unit: NX_UNITLESS + doc: | + For each link/pair in current_to_next a characterization + whether the link is due to a volumetric overlap (0x00 == 0), + proximity (0x01 == 1), or something else unknown (0xFF == 255). + dimensions: + rank: 1 + dim: [[1, n_c2n]] + next_to_current_link(NX_UINT): + exists: optional + unit: NX_UNITLESS + doc: | + A matrix of feature_identifier which specifies which named feature(s) + from the next set have directed link(s) pointing to which named + feature(s) from the current set. Only if the mapping whereby the + links is symmetric next_to_current maps the links in current_to_next + in the opposite direction. + dimensions: + rank: 2 + dim: [[1, n2c], [2, 2]] + next_to_current_link_type(NX_UINT): + exists: optional + unit: NX_UNITLESS + doc: | + For each link/pair in next_to_current a characterization + whether the link is due to a volumetric overlap (0x00 == 0), + proximity (0x01 == 1), or something else unknown (0xFF == 255). + dimensions: + rank: 1 + dim: [[1, n_n2c]] + intersection_volume(NX_FLOAT): + exists: optional + unit: NX_VOLUME + doc: | + For each pair of links in current_to_next the volume of the + intersection, i.e. how much volume do the two features share. + If features do not intersect the volume is zero. + dimensions: + rank: 1 + dim: [[1, c2n]] + coprecipitation_analysis(NXprocess): + exists: optional + doc: | + During coprecipitation analysis the current and next set are analyzed + for links in a special way. Three set comparisons are made. Members + of the set in each comparison are analyzed for overlap and proximity: + + The first comparison is the current_set against the current_set. + The second comparison is the next_set against the next_set. + The third comparison is the current_set against the next_set. + + Once the (forward) links for these comparisons are ready the + pair relations are analyzed with respect to which feature identifier + cluster in identifier space. Thereby a logical connection (link) is + established between the features in the current_set and next_set. + Recall that these two set typically represent different features + within an observed system for otherwise the same parameterization. + Examples include two sets of e.g. precipitates with differing + chemical composition that were characterized in the same material + volume representing a snapshot of an e.g. microstructure at the same + point in time. Researchers may have performed two analyses, one to + characterize precipitates A and another one to characterize percipitates + B. Coprecipitation analysis now logically connects these independent + characterization results to establish spatial correlations of e.g. + precipitates spatial arrangement. + current_set_feature_to_cluster(NX_UINT): + unit: NX_UNITLESS + doc: | + Matrix of feature_identifier and cluster_identifier pairs which + encodes the cluster to which each feature_identifier was assigned. + Here for features of the current_set. + dimensions: + rank: 2 + dim: [[1, n_features_curr], [2, 2]] + next_set_feature_to_cluster(NX_UINT): + unit: NX_UNITLESS + doc: | + Matrix of feature_identifier and cluster_identifier pairs which + encodes the cluster to which each feature_identifier was assigned. + Here for features of the next_set. + dimensions: + rank: 2 + dim: [[1, n_features_next], [2, 2]] + cluster_identifier(NX_UINT): + unit: NX_UNITLESS + doc: | + The identifier (names) of the cluster. + dimensions: + rank: 1 + dim: [[1, n_cluster]] + cluster_composition(NX_UINT): + unit: NX_UNITLESS + doc: | + Pivot table as a matrix. The first column encodes how many + members from the current_set are in each cluster, one row per cluster. + The second column encodes how many members from the next_set are + in each cluster, in the same row per cluster respectively. + The last column encodes the total number of members in the cluster. + dimensions: + rank: 2 + dim: [[1, n_cluster], [2, 3]] + cluster_statistics(NX_UINT): + unit: NX_UNITLESS + doc: | + Pivot table as a matrix. The first column encodes the different + types of clusters based on their number of members in the sub-graph. + The second column encodes how many clusters with as many members + exist. + dimensions: + rank: 2 + dim: [[1, n_total], [2, 2]] + + ##MK::add results from NXapm_paraprobe_results_clusterer + + ##MK::end of the tool-specific section + performance(NXcs_profiling): + exists: recommended + current_working_directory: + command_line_call: + exists: optional + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + total_elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): + (NXcs_computer): + exists: recommended + name: + exists: recommended + operating_system: + \@version: + uuid: + exists: optional + (NXcs_cpu): + exists: ['min', '0', 'max', 'unbounded'] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_gpu): + exists: ['min', '0', 'max', 'unbounded'] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_mm_sys): + exists: ['min', '0', 'max', '1'] + total_physical_memory(NX_NUMBER): + (NXcs_io_sys): + exists: ['min', '0', 'max', '1'] + (NXcs_io_obj): + exists: ['min', '1', 'max', 'unbounded'] + technology: + max_physical_capacity(NX_NUMBER): + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_profiling_event): + start_time(NX_DATE_TIME): + exists: optional + end_time(NX_DATE_TIME): + exists: optional + description: + elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + number_of_threads(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + number_of_gpus(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + max_virtual_memory_snapshot(NX_NUMBER): + exists: recommended + max_resident_memory_snapshot(NX_NUMBER): + exists: recommended + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# d2a7c5a6492bf8b6d6196f0b993c4ecefd16301afc3d9924fd1614c05671488d +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The total number of links pointing from current to next. +# +# +# +# +# The total number of links pointing from next to current. +# +# +# +# +# The total number of members in the current_set. +# +# +# +# +# The total number of members in the next_set. +# +# +# +# +# The total number of cluster found for coprecipitation analysis. +# +# +# +# +# The number of rows in the table/matrix for coprecipitation stats. +# +# +# +# +# Results of a paraprobe-intersector tool run. +# +# +# +# +# +# Version specifier of this application definition. +# +# +# +# +# +# Official NeXus NXDL schema with which this file was written. +# +# +# +# +# +# +# +# +# Given name of the program/software/tool with which this NeXus +# (configuration) file was generated. +# +# +# +# Ideally program version plus build number, or commit hash or description +# of ever persistent resources where the source code of the program and +# build instructions can be found so that the program can be configured +# ideally in such a manner that the result of this computational process +# is recreatable in the same deterministic manner. +# +# +# +# +# +# Ideally, a (globally persistent) unique identifier for referring +# to this analysis. +# +# +# +# +# Possibility for leaving a free-text description about this analysis. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when the analysis behind this results file +# was started, i.e. the paraprobe-tool executable started as a process. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when the analysis behind this results file +# were completed and the paraprobe-tool executable exited as a process. +# +# +# +# +# The absolute path and name of the config file for this analysis. +# +# +# +# At least SHA256 strong hash of the specific config_file for +# tracking provenance. +# +# +# +# +# +# Path to the directory where the tool should store NeXus/HDF5 results +# of this analysis. If not specified results will be stored in the +# current working directory. +# +# +# +# +# If used, contact information and eventually details +# of at least the person who performed this analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Details about the coordinate system conventions used. +# +# +# +# The individual coordinate systems which should be used. +# Field names should be prefixed with the following controlled terms +# indicating which individual coordinate system is described: +# +# * paraprobe +# * lab +# * specimen +# * laser +# * leap +# * detector +# * recon +# +# +# +# +# +# +# +# The results of an overlap/intersection analysis. +# +# +# +# A matrix of feature_identifier which specifies which named features +# from the current set have directed link(s) pointing to which named +# feature(s) from the next set. +# +# +# +# +# +# +# +# +# For each link/pair in current_to_next a characterization +# whether the link is due to a volumetric overlap (0x00 == 0), +# proximity (0x01 == 1), or something else unknown (0xFF == 255). +# +# +# +# +# +# +# +# A matrix of feature_identifier which specifies which named feature(s) +# from the next set have directed link(s) pointing to which named +# feature(s) from the current set. Only if the mapping whereby the +# links is symmetric next_to_current maps the links in current_to_next +# in the opposite direction. +# +# +# +# +# +# +# +# +# For each link/pair in next_to_current a characterization +# whether the link is due to a volumetric overlap (0x00 == 0), +# proximity (0x01 == 1), or something else unknown (0xFF == 255). +# +# +# +# +# +# +# +# For each pair of links in current_to_next the volume of the +# intersection, i.e. how much volume do the two features share. +# If features do not intersect the volume is zero. +# +# +# +# +# +# +# +# During coprecipitation analysis the current and next set are analyzed +# for links in a special way. Three set comparisons are made. Members +# of the set in each comparison are analyzed for overlap and proximity: +# +# The first comparison is the current_set against the current_set. +# The second comparison is the next_set against the next_set. +# The third comparison is the current_set against the next_set. +# +# Once the (forward) links for these comparisons are ready the +# pair relations are analyzed with respect to which feature identifier +# cluster in identifier space. Thereby a logical connection (link) is +# established between the features in the current_set and next_set. +# Recall that these two set typically represent different features +# within an observed system for otherwise the same parameterization. +# Examples include two sets of e.g. precipitates with differing +# chemical composition that were characterized in the same material +# volume representing a snapshot of an e.g. microstructure at the same +# point in time. Researchers may have performed two analyses, one to +# characterize precipitates A and another one to characterize percipitates +# B. Coprecipitation analysis now logically connects these independent +# characterization results to establish spatial correlations of e.g. +# precipitates spatial arrangement. +# +# +# +# Matrix of feature_identifier and cluster_identifier pairs which +# encodes the cluster to which each feature_identifier was assigned. +# Here for features of the current_set. +# +# +# +# +# +# +# +# +# Matrix of feature_identifier and cluster_identifier pairs which +# encodes the cluster to which each feature_identifier was assigned. +# Here for features of the next_set. +# +# +# +# +# +# +# +# +# The identifier (names) of the cluster. +# +# +# +# +# +# +# +# Pivot table as a matrix. The first column encodes how many +# members from the current_set are in each cluster, one row per cluster. +# The second column encodes how many members from the next_set are +# in each cluster, in the same row per cluster respectively. +# The last column encodes the total number of members in the cluster. +# +# +# +# +# +# +# +# +# Pivot table as a matrix. The first column encodes the different +# types of clusters based on their number of members in the sub-graph. +# The second column encodes how many clusters with as many members +# exist. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Specify if it was different from the number_of_processes +# in the NXcs_profiling super class. +# +# +# +# +# +# Specify if it was different from the number_of_threads +# in the NXcs_profiling super class. +# +# +# +# +# +# Specify if it was different from the number_of_threads +# in the NXcs_profiling super class. +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml new file mode 100644 index 0000000000..c88d7e63a7 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml @@ -0,0 +1,3752 @@ +category: application +doc: | + Results of a paraprobe-nanochem tool run. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_ions: | + The total number of ions in the reconstruction. + n_atomic: | + The total number of atoms in the atomic_decomposition match filter. + n_isotopic: | + The total number of isotopes in the isotopic_decomposition match filter. + d: | + The dimensionality of the delocalization grid. + c: | + The cardinality/total number of cells/grid points in the delocalization grid. + + # c_tri_soup: | + # The cardinality/total number of triangles in the triangle soup. + n_f_tri_xdmf: | + The total number of XDMF values to represent all faces of triangles via XDMF. + n_feature_dict: | + The total number of entries in a feature dictionary. + n_speci: | + The total number of member distinguished when reporting composition. +type: group +NXapm_paraprobe_results_nanochem(NXobject): + + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + (NXentry): + exists: ['min', '1', 'max', '1'] + \@version: + doc: | + Version specifier of this application definition. + + ##MK::begin of the tool-specific section + definition: + doc: | + Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_results_nanochem] + + ##MK::end of the tool-specific section + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + analysis_identifier: + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: | + Possibility for leaving a free-text description about this analysis. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + config_filename: + doc: | + The absolute path and name of the config file for this analysis. + \@version: + doc: | + At least SHA256 strong hash of the specific config_file for + tracking provenance. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + status: + doc: | + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must no longer compute analyses. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases, it might be + that the executable has terminated prematurely or another error + occurred. + enumeration: [success, failure] + (NXuser): + exists: optional + doc: | + If used, contact information and eventually details + of at least the person who performed this analysis. + name: + affiliation: + exists: recommended + address: + exists: optional + email: + exists: recommended + orcid: + exists: recommended + orcid_platform: + exists: recommended + telephone_number: + exists: optional + role: + exists: recommended + social_media_name: + exists: optional + social_media_platform: + exists: optional + (NXcoordinate_system_set): + doc: | + Details about the coordinate system conventions used. + If nothing else is specified we assume that there + has to be at least one set of NXtransformations named + paraprobe defined, which specifies the coordinate system. + In which all positions are defined. + + ##MK::define also reconstruction coordinate system and + ##MK::map between the two + (NXtransformations): + exists: ['min', '1', 'max', 'unbounded'] + doc: | + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + ##MK::begin of the tool-specific section + (NXprocess): + exists: ['min', '0', 'max', '1'] + window(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies which of the ions in the dataset were + analyzed during this process. + number_of_ions(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of ions covered by the mask. + The mask value for most may be 0. + bitdepth(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + mask(NX_UINT): + unit: NX_UNITLESS + doc: | + The unsigned integer array representing the content of the mask. + If padding is used, padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe-toolbox executable. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth (padding). + dimensions: + rank: 1 + dim: [[1, n_ions]] + iso_surface_analysis(NXprocess): + exists: ['min', '0', 'max', 'unbounded'] + DELOCALIZATION(NXdelocalization): + weighting_model: + doc: | + The weighting model specifies how mark data are mapped to a weight + per point/ion. For atom probe microscopy (APM) mark data are e.g. + which iontype an ion has. As an example, different models are used + which account differently for the multiplicity of a point/ion + during delocalization: + + * unity, all points/ions get the same weight 1. + * atomic_decomposition, points get as much weight as they + have atoms of a type in atomic_decomposition_rule, + * isotope_decomposition, points get as much weight as they have + isotopes of a type in isotopic_decomposition_rule. + enumeration: [unity, atomic_decomposition, isotopic_decomposition] + + # if weighting_model == atomic_decomposition needs atomic_decomposition_rule + # if weighting_model == isotopic_decomposition needs isotopic_decomposition_rule + atomic_decomposition_rule(NXmatch_filter): + exists: optional + doc: | + A list of elements (via proton number) to consider for the + atomic_decomposition weighting model. + Elements must exist in the periodic table of elements and be + specified by their number of protons. + Values in match are isotope hash values using the following + hashing rule $H = Z + 256*N$ with $Z$ the number of protons + and $N$ the number of neutrons of the isotope. + In the case of elements this hashing rule has the advantage + that for elements the proton number is their hash value because + N is zero. + method: + doc: | + Meaning of the filter: + Whitelist specifies which entries with said value to include. + Entries with all other values will be filtered out. + + Blacklist specifies which entries with said value to exclude. + Entries with all other values will be included. + enumeration: [whitelist, blacklist] + match(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Array of values to filter according to method. For example, + if the filter specifies [1, 5, 6] and method is whitelist, + only entries with values matching 1, 5 or 6 will be processed. + All other entries will be filtered out/not considered. + dimensions: + rank: 1 + dim: [[1, n_atomic]] + isotopic_decomposition_rule(NXmatch_filter): + exists: optional + doc: | + A list of isotopes (via proton and neutron number) to consider + for the isotopic_decomposition weighting model. + Isotopes must exist in the nuclid table. + Values in match are isotope hash values using the following + hashing rule $H = Z + 256*N$ with $Z$ the number of protons + and $N$ the number of neutrons of the isotope. + method: + doc: | + Meaning of the filter: + Whitelist specifies which entries with said value to include. + Entries with all other values will be filtered out. + + Blacklist specifies which entries with said value to exclude. + Entries with all other values will be included. + enumeration: [whitelist, blacklist] + match(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Array of values to filter according to method. For example, + if the filter specifies [1, 5, 6] and method is whitelist, + only entries with values matching 1, 5 or 6 will be processed. + All other entries will be filtered out/not considered. + dimensions: + rank: 1 + dim: [[1, n_isotopic]] + normalization: + doc: | + How results of the kernel-density estimation were computed + into quantities. By default the tool computes the total number + (intensity) of ions or elements. Alternatively the tool can compute + the total intensity, the composition, or the concentration of the + ions/elements specified by the white list of elements in each voxel. + enumeration: [total, candidates, composition, concentration] + weight(NX_NUMBER): + exists: optional + unit: NX_DIMENSIONLESS + doc: | + Weighting factor, in atom probe, often termed multiplicity. + The weighting factor is the multiplier with which the integrated + intensity contribution from the point/ion gets multiplied. + The delocalization computes the integrated intensity for each + grid cell. Effectively, this is an explicitly evaluated kernel + method where each specific position of an ion is replaced by a + smoothing kernel. For atom probe weights are positive and integer + specifically the multiplicity of the ion, in accordance with the + respective rulesets as defined by weighting_model. + dimensions: + rank: 1 + dim: [[1, n_ions]] + grid(NXcg_grid): + doc: | + The discretized domain/grid on which the delocalization is applied. + dimensionality(NX_POSINT): + unit: NX_UNITLESS + enumeration: [1, 2, 3] + cardinality(NX_POSINT): + unit: NX_UNITLESS + doc: | + The total number of cells/voxels of the grid. + origin(NX_NUMBER): + dimensions: + rank: 1 + dim: [[1, d]] + symmetry: + doc: | + The symmetry of the lattice defining the shape of the unit cell. + enumeration: [cubic] + cell_dimensions(NX_NUMBER): + unit: NX_LENGTH + doc: | + The unit cell dimensions according to the coordinate system + defined under coordinate_system. + dimensions: + rank: 1 + dim: [[1, d]] + extent(NX_POSINT): + unit: NX_UNITLESS + doc: | + Number of unit cells along each of the d unit vectors. + The total number of cells, or grid points has to be the cardinality. + If the grid has an irregular number of grid positions in each direction, + as it could be for instance the case of a grid where all grid points + outside some masking primitive are removed, this extent field should + not be used. Instead use the coordinate field. + dimensions: + rank: 1 + dim: [[1, d]] + + # (NXtransformations): + coordinate_system: + exists: optional + doc: | + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + If the coordinate system is not specified the paraprobe + coordinate system is used. + + # should constraints on the grid be place here or not + identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for + distinguishing identifiers for cells. Identifiers are defined + either implicitly or explicitly. For implicit indexing the + identifiers are defined on the interval + [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + bounding_box(NXcg_hexahedron_set): + doc: | + A tight axis-aligned bounding box about the grid. + is_axis_aligned(NX_BOOLEAN): + unit: NX_UNITLESS + doc: | + For atom probe should be set to true. + identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + hexahedron(NXcg_face_list_data_structure): + vertex_identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + face_identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + vertices(NX_NUMBER): + unit: NX_LENGTH + doc: | + Positions of the vertices. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + dimensions: + rank: 2 + dim: [[1, 8], [2, 3]] + faces(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + dimensions: + rank: 2 + dim: [[1, 6], [2, 4]] + xdmf_topology(NX_UINT): + unit: NX_UNITLESS + 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. + dimensions: + rank: 1 + dim: [[1, 36]] + number_of_boundaries(NX_POSINT): + exists: optional + unit: NX_UNITLESS + doc: | + How many distinct boundaries are distinguished? + Most grids discretize a cubic or cuboidal region. In this case + six sides can be distinguished, each making an own boundary. + boundaries: + exists: optional + doc: | + Name of the boundaries. E.g. left, right, front, back, bottom, top, + The field must have as many entries as there are number_of_boundaries. + dimensions: + rank: 1 + dim: [[1, 6]] + boundary_conditions(NX_INT): + exists: optional + unit: NX_UNITLESS + doc: | + The boundary conditions for each boundary: + + 0 - undefined + 1 - open + 2 - periodic + 3 - mirror + 4 - von Neumann + 5 - Dirichlet + dimensions: + rank: 1 + dim: [[1, 6]] + + ##MK::how to avoid storing it for once in NeXus for H5Web and + # for XDMF in ParaView ? + scalar_field_magnitude(NXdata): + doc: | + The result of the delocalization based on which subsequent + iso-surfaces will be computed. In commercial software so far + there is not a possibility to export such grid. + + ##MK::math notation + \@long_name: + exists: optional + \@signal: + \@axes: + \@xpos_indices: + \@ypos_indices: + \@zpos_indices: + intensity(NX_FLOAT): + dimensions: + rank: 3 + dim: [[1, n_z], [2, n_y], [3, n_x]] + xpos(NX_FLOAT): + doc: | + Cell center of mass positions along x. + dimensions: + rank: 1 + dim: [[1, n_x]] + + ##MK::how to relate back that this x is paraprobe x? + ypos(NX_FLOAT): + doc: | + Cell center of mass positions along y. + dimensions: + rank: 1 + dim: [[1, n_y]] + zpos(NX_FLOAT): + doc: | + Cell center of mass positions along z. + dimensions: + rank: 1 + dim: [[1, n_z]] + xdmf_intensity(NX_FLOAT): + exists: optional + unit: NX_ANY + doc: | + Intensity of the field at given point + dimensions: + rank: 1 + dim: [[1, n_xyz]] + xdmf_xyz(NX_FLOAT): + exists: optional + unit: NX_UNITLESS + doc: | + Center of mass positions of each voxel for + rendering the scalar field via XDMF in e.g. + Paraview. + dimensions: + rank: 2 + dim: [[1, n_xyz], [2, 3]] + xdmf_topology(NX_NUMBER): + exists: optional + unit: NX_UNITLESS + doc: | + XDMF topology for rendering in combination with + xdmf_xyz the scalar field via XDFM in e.g. Paraview. + dimensions: + rank: 1 + dim: [[1, 3*n_xyz]] + scalar_field_gradient(NXdata): + doc: | + The three-dimensional gradient nabla operator applied to + scalar_field_magnitude. + + ##MK::boundary conditions which type of accuracy + ##MK::math notation + \@signal: + \@axes: + + ##MK::vector_indices, # ##MK: 3 + \@xpos_indices: + \@ypos_indices: + \@zpos_indices: + \@long_name: + exists: optional + intensity(NX_FLOAT): + dimensions: + rank: 4 + dim: [[1, n_z], [2, n_y], [3, n_x], [4, 3]] + xpos(NX_FLOAT): + doc: | + Cell center of mass positions along x. + dimensions: + rank: 1 + dim: [[1, n_x]] + + ##MK::how to relate back that this x is paraprobe x? + ypos(NX_FLOAT): + doc: | + Cell center of mass positions along y. + dimensions: + rank: 1 + dim: [[1, n_y]] + zpos(NX_FLOAT): + doc: | + Cell center of mass positions along z. + dimensions: + rank: 1 + dim: [[1, n_z]] + xdmf_gradient(NX_FLOAT): + exists: optional + unit: NX_ANY + doc: | + The gradient vector. + dimensions: + rank: 2 + dim: [[1, n_xyz], [2, 3]] + xdmf_xyz(NX_FLOAT): + exists: optional + unit: NX_UNITLESS + doc: | + Center of mass positions of each voxel for + rendering the scalar field via XDMF in e.g. + Paraview. + dimensions: + rank: 2 + dim: [[1, n_xyz], [2, 3]] + xdmf_topology(NX_NUMBER): + exists: optional + unit: NX_UNITLESS + doc: | + XDMF topology for rendering in combination with + xdmf_xyz the scalar field via XDFM in e.g. Paraview. + dimensions: + rank: 1 + dim: [[1, 3*n_xyz]] + kernel_size(NX_POSINT): + unit: NX_DIMENSIONLESS + doc: | + Halfwidth of the kernel about the central voxel. + The shape of the kernel is that of a cuboid + of extent 2*kernel_extent[i] + 1 in each dimension i. + + # \@units: pixel + dimensions: + rank: 1 + dim: [[1, 3]] + + # kernel_type: + # doc: | + # Functional form of the kernel (Ansatz function). + kernel_sigma(NX_FLOAT): + unit: NX_LENGTH + doc: | + Sigma of the kernel in each dimension in the paraprobe + coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. + dimensions: + rank: 1 + dim: [[1, 3]] + kernel_mu(NX_FLOAT): + unit: NX_LENGTH + doc: | + Expectation value of the kernel in each dimension in the paraprobe + coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. + dimensions: + rank: 1 + dim: [[1, 3]] + + ##MK:: + iso_surface(NXisocontour): + exists: optional + doc: | + An iso-surface is the boundary between two regions across which + the magnitude of a scalar field falls below/exceeds a threshold + magnitude phi. + For applications in atom probe microscopy the location and shape + of such a boundary (set) is typically approximated by + discretization. + This yields a complex of not necessarily connected geometric + primitives. Paraprobe-nanochem approximates this complex with + a soup of triangles. + dimensionality(NX_POSINT): + unit: NX_UNITLESS + isovalue(NX_NUMBER): + unit: NX_ANY + doc: | + The threshold or iso-contour value. + marching_cubes(NXcg_marching_cubes): + doc: | + Details about the specific marching cubes algorithm + which was taken to compute the iso-surface. + The grid is the delocalization grid. + implementation: + doc: | + Reference to the specific implementation of marching cubes used. + The value placed here should be a DOI. If there are no specific + DOI or details write not_further_specified, or give at least a + free-text description. The program and version used is the + specific paraprobe-nanochem. + triangle_soup(NXcg_triangle_set): + exists: optional + doc: | + The resulting triangle soup computed via marching cubes. + dimensionality(NX_POSINT): + unit: NX_UNITLESS + cardinality(NX_POSINT): + unit: NX_UNITLESS + identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for + distinguishing triangles. Identifiers are defined either + implicitly or explicitly. For implicit indexing the + identifiers are defined on the interval + [identifier_offset, identifier_offset+c-1]. + triangles(NXcg_face_list_data_structure): + number_of_vertices(NX_POSINT): + unit: NX_UNITLESS + doc: | + Number of vertices. + number_of_faces(NX_POSINT): + unit: NX_UNITLESS + doc: | + Number of faces. + vertex_identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + face_identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + vertices(NX_NUMBER): + unit: NX_LENGTH + doc: | + Positions of the vertices. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + dimensions: + rank: 2 + dim: [[1, i], [2, 3]] + faces(NX_INT): + unit: NX_UNITLESS + doc: | + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + dimensions: + rank: 1 + dim: [[1, j]] + xdmf_topology(NX_UINT): + unit: NX_UNITLESS + doc: | + A list of as many tuples of XDMF topology key, XDMF number + of vertices and a triple of vertex indices specifying each + triangle. The total number of entries is n_f_tri * (1+1+3). + dimensions: + rank: 1 + dim: [[1, n_f_tri_xdmf]] + vertex_normal(NXcg_unit_normal_set): + exists: optional + normals(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + Direction of each normal. + dimensions: + rank: 2 + dim: [[1, j], [2, 3]] + orientation(NX_UINT): + exists: optional + unit: NX_UNITLESS + doc: | + Qualifier how which specifically oriented normal to its + primitive each normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + dimensions: + rank: 1 + dim: [[1, j]] + + # edge_normal(NXcg_unit_normal_set): + # exists: optional + face_normal(NXcg_unit_normal_set): + exists: optional + normals(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + Direction of each normal. + dimensions: + rank: 2 + dim: [[1, k], [2, 3]] + orientation(NX_UINT): + exists: optional + unit: NX_UNITLESS + doc: | + Qualifier how which specifically oriented normal to its + primitive each normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + dimensions: + rank: 1 + dim: [[1, k]] + gradient_guide_magnitude(NX_FLOAT): + unit: NX_ANY + doc: | + Triangle normals are oriented in the direction of the + gradient vector of the local delocalized scalar field. + :math:`\sum_{x, y, z} {\nabla{c}_i}^2`. + dimensions: + rank: 1 + dim: [[1, k]] + + # gradient_guide_quality(NX_FLOAT): + # doc: | + # Triangle normals are oriented in the direction of the + # gradient vector of the local delocalized scalar field. + # Sum of squared values of cross product of triangle normal + # construction. + # unit: NX_ANY + # dimensions: + # rank: 1 + # dim: [[1, k]] + gradient_guide_projection(NX_FLOAT): + unit: NX_ANY + doc: | + Triangle normals are oriented in the direction of the + gradient vector of the local delocalized scalar field. + The projection variable here describes the cosine of the + angle between the gradient direction and the normal + direction vector. + This is a descriptor of how parallel the projection is + that is especially useful to document those triangles + for whose projection is almost perpendicular. + dimensions: + rank: 1 + dim: [[1, k]] + area(NX_NUMBER): + exists: optional + unit: NX_AREA + dimensions: + rank: 1 + dim: [[1, j]] + edge_length(NX_NUMBER): + exists: optional + unit: NX_LENGTH + doc: | + Array of edge length values. For each triangle the edge length + is reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + dimensions: + rank: 2 + dim: [[1, k], [2, 3]] + interior_angle(NX_NUMBER): + exists: optional + unit: NX_ANGLE + doc: | + Array of interior angle values. For each triangle the angle + is reported for the angle opposite to the edges which are + traversed according to the sequence in which vertices + are indexed in triangles. + dimensions: + rank: 2 + dim: [[1, j], [2, 4]] + center(NX_NUMBER): + exists: optional + unit: NX_LENGTH + doc: | + The center of mass of each triangle. + dimensions: + rank: 2 + dim: [[1, j], [2, 3]] + volumetric_feature(NXprocess): + exists: optional + doc: | + Iso-surfaces of arbitrary scalar three-dimensional fields + can show a complicated topology. Paraprobe-nanochem can run + a DBScan-like clustering algorithm which performs a + connectivity analysis on the triangle soup. This yields a + set of connected features with their surfaces discretized + by triangles. Currently, the tool distinguishes at most + three types of features: + + 1. So-called objects, i.e. necessarily watertight features + represented polyhedra. + 2. So-called proxies, i.e. features that were replaced by a + proxy mesh and made watertight. + 3. Remaining triangle surface meshes of arbitrary shape and + cardinality. + + These features can be interpreted as microstructural features. + Some of them may be precipitates, some of them may be poles, + some of them may be segments of dislocation lines or other + crystal defects which are decorated (or not) with solutes. + + # Each type of feature needs to be registered in the feature_type + # dictionary. Type identifiers (keywords are integer), values + # are human-readable names like object, proxy, undefined + # NEW ISSUE: refactor using instances of NXms_feature_set + triangle_cluster_identifier(NX_UINT): + unit: NX_UNITLESS + doc: | + The identifier which the triangle_soup connectivity analysis + returned, which constitutes the first step of the + volumetric_feature identification process. + dimensions: + rank: 1 + dim: [[1, k]] + feature_type_dict_keyword(NX_UINT): + exists: optional + unit: NX_UNITLESS + doc: | + The array of keywords of feature_type dictionary. + dimensions: + rank: 1 + dim: [[1, n_feature_dict]] + feature_type_dict_value: + exists: optional + doc: | + The array of values for each keyword of the + feature_type dictionary. + dimensions: + rank: 1 + dim: [[1, n_feature_dict]] + feature_type(NX_UINT): + unit: NX_ANY + doc: | + The array of controlled keywords, need to be from + feature_type_dict_keyword, which specify which type + each feature triangle cluster belongs to. + Keep in mind that not each feature is an object or proxy. + dimensions: + rank: 1 + dim: [[1, j]] + feature_identifier(NX_UINT): + unit: NX_UNITLESS + doc: | + The explicit identifier of features. + dimensions: + rank: 1 + dim: [[1, j]] + + ##MK::a nice example why we need group-overarching symbols + # a symbol for triangles would not work as the analysis can + # hold multiple instances of iso_surface each with a different + # number of triangles and/or features! + # details about specific features + objects(NXprocess): + exists: optional + doc: | + Details for features which are (closed) objects. + Identifier have to exist in feature_identifier. + + ##MK::constraints! + feature_identifier(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + volume(NX_FLOAT): + unit: NX_VOLUME + dimensions: + rank: 1 + dim: [[1, i]] + obb(NXcg_hexahedron_set): + exists: optional + doc: | + An oriented bounding box (OBB) to each object. + size(NX_FLOAT): + exists: optional + unit: NX_LENGTH + doc: | + Edge length of the oriented bounding box from largest + to smallest value. + dimensions: + rank: 2 + dim: [[1, i], [2, 3]] + + ##MK::which is which + aspect(NX_FLOAT): + exists: optional + unit: NX_DIMENSIONLESS + doc: | + Oriented bounding box aspect ratio. YX versus ZY. + dimensions: + rank: 2 + dim: [[1, i], [2, 2]] + center(NX_NUMBER): + exists: optional + unit: NX_LENGTH + doc: | + Position of the geometric center, which often is but + not necessarily has to be the center_of_mass of the + hexahedrally-shaped sample/sample part. + dimensions: + rank: 2 + dim: [[1, i], [2, 3]] + hexahedra(NXcg_face_list_data_structure): + + # exists: [min, 0, max, 1] + doc: | + A simple approach to describe the entire set of hexahedra + when the main intention is to store the shape of the + hexahedra for visualization. + + ##MK::more details needed here + vertices(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, k], [2, 3]] + + ##MK::again we have no effective way to pinpoint the n_rows + ##MK::namely k != i each OBB has eight vertices + xdmf_topology(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, k]] + xdmf_feature_identifier(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, k]] + objects_close_to_edge(NXprocess): + exists: optional + doc: | + Details for all those objects close to edge, i.e. those which + have at least one ion which lays closer to a modelled edge + of the dataset than threshold. + feature_identifier(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + volume(NX_FLOAT): + unit: NX_VOLUME + dimensions: + rank: 1 + dim: [[1, i]] + composition(NXchemical_composition): + exists: optional + total(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Total (count) relevant for normalization. + dimensions: + rank: 1 + dim: [[1, i]] + ION(NXion): + exists: ['min', '0', 'max', 'unbounded'] + charge(NX_INT): + isotope_vector(NX_UINT): + nuclid_list(NX_UINT): + count(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Count or weight which, when divided by total, + yields the composition of this element, isotope, + molecule or ion. + dimensions: + rank: 1 + dim: [[1, i]] + objectID(NXcg_polyhedron_set): + exists: ['min', '0', 'max', 'unbounded'] + polyhedron(NXcg_face_list_data_structure): + + # number_of_vertices(NX_POSINT): + # number_of_faces(NX_POSINT): + # vertex_identifier_offset(NX_UINT): + # face_identifier_offset(NX_UINT): + vertices(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, n_v], [2, 3]] + faces(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_f], [2, 3]] + + # face_normals(NXcg_unit_normal_set): + face_normals(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, n_f], [2, 3]] + xdmf_topology(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, k]] + xdmf_feature_identifier(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, k]] + ion_identifier(NX_UINT): + exists: optional + unit: NX_UNITLESS + doc: | + Array of evaporation_identifier / ion_identifier which + specify ions laying inside or on the surface of the feature. + dimensions: + rank: 1 + dim: [[1, i]] + objects_far_from_edge(NXprocess): + exists: optional + doc: | + Details for all those objects far from edge, i.e. those + whose ions lay all at least threshold distant from a + modelled edge of the dataset. + feature_identifier(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + volume(NX_FLOAT): + unit: NX_VOLUME + dimensions: + rank: 1 + dim: [[1, i]] + composition(NXchemical_composition): + exists: optional + total(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Total (count) relevant for normalization. + dimensions: + rank: 1 + dim: [[1, i]] + ION(NXion): + exists: ['min', '0', 'max', 'unbounded'] + charge(NX_INT): + isotope_vector(NX_UINT): + nuclid_list(NX_UINT): + count(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Count or weight which, when divided by total + yields the composition of this element, isotope, + molecule or ion. + dimensions: + rank: 1 + dim: [[1, i]] + objectID(NXcg_polyhedron_set): + exists: ['min', '0', 'max', 'unbounded'] + polyhedron(NXcg_face_list_data_structure): + + # number_of_vertices(NX_POSINT): + # number_of_faces(NX_POSINT): + # vertex_identifier_offset(NX_UINT): + # face_identifier_offset(NX_UINT): + vertices(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, n_v], [2, 3]] + faces(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_f], [2, 3]] + + # face_normals(NXcg_unit_normal_set): + face_normals(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, n_f], [2, 3]] + xdmf_topology(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, k]] + xdmf_feature_identifier(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, k]] + ion_identifier(NX_UINT): + exists: optional + unit: NX_UNITLESS + doc: | + Array of evaporation_identifier / ion_identifier which + specify ions laying inside or on the surface of the feature. + dimensions: + rank: 1 + dim: [[1, i]] + + # linear_feature_identification(NXprocess): + # these would be polylines etc + proxies(NXprocess): + exists: optional + doc: | + Details for features which are so-called proxies, i.e. objects + which have been reconstructed and combinatorially closed with + processing their partial triangulated_surface_mesh + (hole filling, refinement). + Identifier have to exist in feature_identifier. + + ##MK::constraints feature_identifier are a subset of the parent! + feature_identifier(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + volume(NX_FLOAT): + unit: NX_VOLUME + dimensions: + rank: 1 + dim: [[1, i]] + + # obb ? + proxies_close_to_edge(NXprocess): + exists: optional + doc: | + Details for those proxies close to edge, i.e. those which + have at least one ion which lays closer to a modelled edge + of the dataset than threshold. + Identifier have to exist in feature_identifier. + + ##MK::constraints! + feature_identifier(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + volume(NX_FLOAT): + unit: NX_VOLUME + dimensions: + rank: 1 + dim: [[1, i]] + composition(NXchemical_composition): + exists: optional + total(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Total (count) relevant for normalization. + dimensions: + rank: 1 + dim: [[1, i]] + ION(NXion): + exists: ['min', '0', 'max', 'unbounded'] + + # charge(NX_INT): + # isotope_vector(NX_UINT): + count(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Count or weight which, when divided by total + yields the composition of this element, isotope, + molecule or ion. + dimensions: + rank: 1 + dim: [[1, i]] + objectID(NXcg_polyhedron_set): + exists: ['min', '0', 'max', 'unbounded'] + polyhedron(NXcg_face_list_data_structure): + + # number_of_vertices(NX_POSINT): + # number_of_faces(NX_POSINT): + # vertex_identifier_offset(NX_UINT): + # face_identifier_offset(NX_UINT): + vertices(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, n_v], [2, 3]] + faces(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_f], [2, 3]] + + # face_normals(NXcg_unit_normal_set): + face_normals(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, n_f], [2, 3]] + xdmf_topology(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, k]] + xdmf_feature_identifier(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, k]] + ion_identifier(NX_UINT): + exists: optional + unit: NX_UNITLESS + doc: | + Array of evaporation_identifier / ion_identifier which + specify ions laying inside or on the surface of the feature. + dimensions: + rank: 1 + dim: [[1, i]] + proxies_far_from_edge(NXprocess): + exists: optional + doc: | + Details for those proxies far from edge, i.e. those whose + ions lay all at least threshold distant from a + modelled edge of the dataset. + feature_identifier(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + volume(NX_FLOAT): + unit: NX_VOLUME + dimensions: + rank: 1 + dim: [[1, i]] + composition(NXchemical_composition): + exists: optional + total(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Total (count) relevant for normalization. + dimensions: + rank: 1 + dim: [[1, i]] + ION(NXion): + exists: ['min', '0', 'max', 'unbounded'] + + # charge(NX_INT): + # isotope_vector(NX_UINT): + count(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Count or weight which, when divided by total + yields the composition of this element, isotope, + molecule or ion. + dimensions: + rank: 1 + dim: [[1, i]] + objectID(NXcg_polyhedron_set): + exists: ['min', '0', 'max', 'unbounded'] + polyhedron(NXcg_face_list_data_structure): + + # number_of_vertices(NX_POSINT): + # number_of_faces(NX_POSINT): + # vertex_identifier_offset(NX_UINT): + # face_identifier_offset(NX_UINT): + vertices(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, n_v], [2, 3]] + faces(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_f], [2, 3]] + + # face_normals(NXcg_unit_normal_set): + face_normals(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, n_f], [2, 3]] + xdmf_topology(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, k]] + xdmf_feature_identifier(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, k]] + ion_identifier(NX_UINT): + exists: optional + unit: NX_UNITLESS + doc: | + Array of evaporation_identifier / ion_identifier which + specify ions laying inside or on the surface of the feature. + dimensions: + rank: 1 + dim: [[1, i]] + interface_modelling(NXprocess): + exists: optional + ion_multiplicity(NX_UINT): + exists: optional + unit: NX_UNITLESS + doc: | + The multiplicity whereby the ion position is accounted for + irrespective whether the ion is considered as a decorator + of the interface or not. + As an example, with atom probe it is typically not possible + to resolve the positions of the atoms which arrive at the detector + as molecular ions. Therefore, an exemplar molecular ion of two carbon + atoms can be considered to have a multiplicity of two to account that + this molecular ion contributes two carbon atoms at the reconstructed + location considering that the spatial resolution of atom probe + experiments is limited. + dimensions: + rank: 1 + dim: [[1, n_ions]] + decorator_multiplicity(NX_UINT): + exists: optional + unit: NX_UNITLESS + doc: | + The multiplicity whereby the ion position is accounted for when + the ion is considered one which is a decorator of the interface. + dimensions: + rank: 1 + dim: [[1, n_ions]] + initial_interface(NXprocess): + exists: optional + doc: | + The equation of the plane that is fitted initially. + point_normal_form(NX_FLOAT): + unit: NX_LENGTH + doc: | + The four parameter :math:`ax + by + cz + d = 0` which define the plane. + dimensions: + rank: 1 + dim: [[1, 4]] + MESH_CURR_PRE_DCOM_STEP(NXcg_triangle_set): + exists: ['min', '0', 'max', 'unbounded'] + doc: | + The triangle surface mesh representing the interface model. + Exported at some iteration before the next DCOM step. + dimensionality(NX_POSINT): + unit: NX_UNITLESS + cardinality(NX_POSINT): + unit: NX_UNITLESS + identifier_offset(NX_INT): + unit: NX_UNITLESS + triangles(NXcg_face_list_data_structure): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + number_of_vertices(NX_POSINT): + unit: NX_UNITLESS + number_of_faces(NX_POSINT): + unit: NX_UNITLESS + vertex_identifier_offset(NX_INT): + unit: NX_UNITLESS + edge_identifier_offset(NX_INT): + unit: NX_UNITLESS + face_identifier_offset(NX_INT): + unit: NX_UNITLESS + face_identifier(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, j]] + vertices(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, i], [2, 3]] + faces(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, j], [2, 3]] + xdmf_topology(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, k]] + + ##MK::vertex_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + cardinality(NX_POSINT): + unit: NX_UNITLESS + normals(NX_FLOAT): + unit: NX_LENGTH + doc: | + Direction of each normal + dimensions: + rank: 2 + dim: [[1, j], [2, 3]] + orientation(NX_UINT): + unit: NX_UNITLESS + doc: | + Qualifier how which specifically oriented normal to its primitive each + normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + dimensions: + rank: 1 + dim: [[1, j]] + vertex_normal(NXcg_unit_normal_set): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + cardinality(NX_POSINT): + unit: NX_UNITLESS + normals(NX_FLOAT): + unit: NX_LENGTH + doc: | + Direction of each normal + dimensions: + rank: 2 + dim: [[1, j], [2, 3]] + orientation(NX_UINT): + unit: NX_UNITLESS + doc: | + Qualifier how which specifically oriented normal to its primitive each + normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + dimensions: + rank: 1 + dim: [[1, j]] + area(NX_NUMBER): + unit: NX_AREA + dimensions: + rank: 1 + dim: [[1, c]] + edge_length(NX_NUMBER): + unit: NX_LENGTH + doc: | + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] + interior_angle(NX_NUMBER): + unit: NX_ANGLE + doc: | + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + dimensions: + rank: 2 + dim: [[1, c], [2, 4]] + MESH_CURR_POST_DCOM_STEP(NXcg_triangle_set): + exists: ['min', '0', 'max', 'unbounded'] + doc: | + The triangle surface mesh representing the interface model. + Exported at some iteration after the next DCOM step. + dimensionality(NX_POSINT): + unit: NX_UNITLESS + cardinality(NX_POSINT): + unit: NX_UNITLESS + identifier_offset(NX_INT): + unit: NX_UNITLESS + triangles(NXcg_face_list_data_structure): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + number_of_vertices(NX_POSINT): + unit: NX_UNITLESS + number_of_faces(NX_POSINT): + unit: NX_UNITLESS + vertex_identifier_offset(NX_INT): + unit: NX_UNITLESS + face_identifier_offset(NX_INT): + unit: NX_UNITLESS + face_identifier(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, j]] + vertices(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, i], [2, 3]] + faces(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, j], [2, 3]] + xdmf_topology(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, k]] + + ##MK::vertex_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + cardinality(NX_POSINT): + unit: NX_UNITLESS + normals(NX_FLOAT): + unit: NX_LENGTH + doc: | + Direction of each normal + dimensions: + rank: 2 + dim: [[1, j], [2, 3]] + orientation(NX_UINT): + unit: NX_UNITLESS + doc: | + Qualifier how which specifically oriented normal to its primitive each + normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + dimensions: + rank: 1 + dim: [[1, j]] + vertex_normal(NXcg_unit_normal_set): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + cardinality(NX_POSINT): + unit: NX_UNITLESS + normals(NX_FLOAT): + unit: NX_LENGTH + doc: | + Direction of each normal + dimensions: + rank: 2 + dim: [[1, j], [2, 3]] + orientation(NX_UINT): + unit: NX_UNITLESS + doc: | + Qualifier how which specifically oriented normal to its primitive each + normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + dimensions: + rank: 1 + dim: [[1, j]] + area(NX_NUMBER): + unit: NX_AREA + dimensions: + rank: 1 + dim: [[1, c]] + edge_length(NX_NUMBER): + unit: NX_LENGTH + doc: | + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] + interior_angle(NX_NUMBER): + unit: NX_ANGLE + doc: | + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + dimensions: + rank: 2 + dim: [[1, c], [2, 4]] + composition_analysis(NXprocess): + exists: optional + xdmf_cylinder(NXcg_polyhedron_set): + doc: | + The ROIs are defined as cylinders for the computations. + To visualize these though we discretize them into regular n-gons. + Using for instance a 360-gon, i.e. a regular n-gon with 360 + edges resolves the lateral surface of each cylinder very finely + so that they are rendered smoothly in visualization software. + dimensionality(NX_POSINT): + unit: NX_UNITLESS + cardinality(NX_POSINT): + unit: NX_UNITLESS + center(NX_NUMBER): + unit: NX_LENGTH + doc: | + Position of the geometric center, which often is but not + necessarily has to be the center_of_mass of the polyhedra. + dimensions: + rank: 2 + dim: [[1, i], [2, 3]] + roi_identifier(NX_UINT): + unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for distinguishing + ROI cylinder. Identifiers are defined explicitly. + dimensions: + rank: 1 + dim: [[1, i]] + polyhedra(NXcg_face_list_data_structure): + exists: ['min', '0', 'max', '1'] + edge_contact(NX_UINT): + exists: optional + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, i]] + + ##MK::decomposed? + number_of_atoms(NX_UINT): + exists: optional + unit: NX_UNITLESS + doc: | + The number of atoms in each ROI. + dimensions: + rank: 1 + dim: [[1, i]] + number_of_ions(NX_UINT): + exists: optional + unit: NX_UNITLESS + doc: | + The number of ions in each ROI. + dimensions: + rank: 1 + dim: [[1, i]] + orientation(NX_FLOAT): + exists: optional + unit: NX_LENGTH + doc: | + The orientation of the ROI defined via a vector which points along + the cylinder axis and whose length is the height of the cylinder. + dimensions: + rank: 2 + dim: [[1, i], [2, 3]] + ROI(NXcollection): + exists: ['min', '0', 'max', 'unbounded'] + signed_distance(NX_FLOAT): + doc: | + In the direction of the ROI. + isotope(NX_UINT): + doc: | + Hashvalue + + ##MK::#define MYCHM_DATA_ISRF_TSKS_TSCL_OBJ_ROICYL_ROIID "RoiCylinderID" + ##MK::#define MYCHM_DATA_ISRF_TSKS_TSCL_OBJ_ROICYL_OBJID "RoiCylinderObjectID" + ##MK::end of the tool-specific section + performance(NXcs_profiling): + exists: recommended + current_working_directory: + command_line_call: + exists: optional + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + total_elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): + (NXcs_computer): + exists: recommended + name: + exists: recommended + operating_system: + \@version: + uuid: + exists: optional + (NXcs_cpu): + exists: ['min', '0', 'max', 'unbounded'] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_gpu): + exists: ['min', '0', 'max', 'unbounded'] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_mm_sys): + exists: ['min', '0', 'max', '1'] + total_physical_memory(NX_NUMBER): + (NXcs_io_sys): + exists: ['min', '0', 'max', '1'] + (NXcs_io_obj): + exists: ['min', '1', 'max', 'unbounded'] + technology: + max_physical_capacity(NX_NUMBER): + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_profiling_event): + start_time(NX_DATE_TIME): + exists: optional + end_time(NX_DATE_TIME): + exists: optional + description: + elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + number_of_threads(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + number_of_gpus(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + max_virtual_memory_snapshot(NX_NUMBER): + exists: recommended + max_resident_memory_snapshot(NX_NUMBER): + exists: recommended + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 5c784d761ed7d02effea4621da7b23889984c1486546a5e95e76ac3ec9e1bc68 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The total number of ions in the reconstruction. +# +# +# +# +# The total number of atoms in the atomic_decomposition match filter. +# +# +# +# +# The total number of isotopes in the isotopic_decomposition match filter. +# +# +# +# +# The dimensionality of the delocalization grid. +# +# +# +# +# The cardinality/total number of cells/grid points in the delocalization grid. +# +# +# +# +# +# The total number of XDMF values to represent all faces of triangles via XDMF. +# +# +# +# +# The total number of entries in a feature dictionary. +# +# +# +# +# The total number of member distinguished when reporting composition. +# +# +# +# +# Results of a paraprobe-nanochem tool run. +# +# +# +# +# +# Version specifier of this application definition. +# +# +# +# +# +# Official NeXus NXDL schema with which this file was written. +# +# +# +# +# +# +# +# +# Given name of the program/software/tool with which this NeXus +# (configuration) file was generated. +# +# +# +# Ideally program version plus build number, or commit hash or description +# of ever persistent resources where the source code of the program and +# build instructions can be found so that the program can be configured +# ideally in such a manner that the result of this computational process +# is recreatable in the same deterministic manner. +# +# +# +# +# +# Ideally, a (globally persistent) unique identifier for referring +# to this analysis. +# +# +# +# +# Possibility for leaving a free-text description about this analysis. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when the analysis behind this results file +# was started, i.e. the paraprobe-tool executable started as a process. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when the analysis behind this results file +# were completed and the paraprobe-tool executable exited as a process. +# +# +# +# +# The absolute path and name of the config file for this analysis. +# +# +# +# At least SHA256 strong hash of the specific config_file for +# tracking provenance. +# +# +# +# +# +# Path to the directory where the tool should store NeXus/HDF5 results +# of this analysis. If not specified results will be stored in the +# current working directory. +# +# +# +# +# A statement whether the paraprobe-tool executable managed to +# process the analysis or failed prematurely. +# +# This status is written to the results file after the end_time +# at which point the executable must no longer compute analyses. +# Only when this status message is present and shows `success`, the +# user should consider the results. In all other cases, it might be +# that the executable has terminated prematurely or another error +# occurred. +# +# +# +# +# +# +# +# +# If used, contact information and eventually details +# of at least the person who performed this analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Details about the coordinate system conventions used. +# If nothing else is specified we assume that there +# has to be at least one set of NXtransformations named +# paraprobe defined, which specifies the coordinate system. +# In which all positions are defined. +# +# +# +# +# The individual coordinate systems which should be used. +# Field names should be prefixed with the following controlled terms +# indicating which individual coordinate system is described: +# +# * paraprobe +# * lab +# * specimen +# * laser +# * leap +# * detector +# * recon +# +# +# +# +# +# +# +# A bitmask which identifies which of the ions in the dataset were +# analyzed during this process. +# +# +# +# Number of ions covered by the mask. +# The mask value for most may be 0. +# +# +# +# +# Number of bits assumed matching on a default datatype. +# (e.g. 8 bits for a C-style uint8). +# +# +# +# +# The unsigned integer array representing the content of the mask. +# If padding is used, padded bits are set to 0. The mask is for +# convenience always as large as the entire dataset as it will +# be stored compressed anyway. The convenience feature with this +# is that then the mask can be decoded with numpy and mirrored +# against the evaporation_id array and one immediately can filter +# out all points that were used by the paraprobe-toolbox executable. +# The length of the array adds to the next unsigned integer +# if the number of ions in the dataset is not an integer +# multiple of the bitdepth (padding). +# +# +# +# +# +# +# +# +# +# +# The weighting model specifies how mark data are mapped to a weight +# per point/ion. For atom probe microscopy (APM) mark data are e.g. +# which iontype an ion has. As an example, different models are used +# which account differently for the multiplicity of a point/ion +# during delocalization: +# +# * unity, all points/ions get the same weight 1. +# * atomic_decomposition, points get as much weight as they +# have atoms of a type in atomic_decomposition_rule, +# * isotope_decomposition, points get as much weight as they have +# isotopes of a type in isotopic_decomposition_rule. +# +# +# +# +# +# +# +# +# +# +# A list of elements (via proton number) to consider for the +# atomic_decomposition weighting model. +# Elements must exist in the periodic table of elements and be +# specified by their number of protons. +# Values in match are isotope hash values using the following +# hashing rule $H = Z + 256*N$ with $Z$ the number of protons +# and $N$ the number of neutrons of the isotope. +# In the case of elements this hashing rule has the advantage +# that for elements the proton number is their hash value because +# N is zero. +# +# +# +# Meaning of the filter: +# Whitelist specifies which entries with said value to include. +# Entries with all other values will be filtered out. +# +# Blacklist specifies which entries with said value to exclude. +# Entries with all other values will be included. +# +# +# +# +# +# +# +# +# Array of values to filter according to method. For example, +# if the filter specifies [1, 5, 6] and method is whitelist, +# only entries with values matching 1, 5 or 6 will be processed. +# All other entries will be filtered out/not considered. +# +# +# +# +# +# +# +# +# A list of isotopes (via proton and neutron number) to consider +# for the isotopic_decomposition weighting model. +# Isotopes must exist in the nuclid table. +# Values in match are isotope hash values using the following +# hashing rule $H = Z + 256*N$ with $Z$ the number of protons +# and $N$ the number of neutrons of the isotope. +# +# +# +# Meaning of the filter: +# Whitelist specifies which entries with said value to include. +# Entries with all other values will be filtered out. +# +# Blacklist specifies which entries with said value to exclude. +# Entries with all other values will be included. +# +# +# +# +# +# +# +# +# Array of values to filter according to method. For example, +# if the filter specifies [1, 5, 6] and method is whitelist, +# only entries with values matching 1, 5 or 6 will be processed. +# All other entries will be filtered out/not considered. +# +# +# +# +# +# +# +# +# How results of the kernel-density estimation were computed +# into quantities. By default the tool computes the total number +# (intensity) of ions or elements. Alternatively the tool can compute +# the total intensity, the composition, or the concentration of the +# ions/elements specified by the white list of elements in each voxel. +# +# +# +# +# +# +# +# +# +# +# Weighting factor, in atom probe, often termed multiplicity. +# The weighting factor is the multiplier with which the integrated +# intensity contribution from the point/ion gets multiplied. +# The delocalization computes the integrated intensity for each +# grid cell. Effectively, this is an explicitly evaluated kernel +# method where each specific position of an ion is replaced by a +# smoothing kernel. For atom probe weights are positive and integer +# specifically the multiplicity of the ion, in accordance with the +# respective rulesets as defined by weighting_model. +# +# +# +# +# +# +# +# The discretized domain/grid on which the delocalization is applied. +# +# +# +# +# +# +# +# +# +# +# The total number of cells/voxels of the grid. +# +# +# +# +# +# +# +# +# +# The symmetry of the lattice defining the shape of the unit cell. +# +# +# +# +# +# +# +# The unit cell dimensions according to the coordinate system +# defined under coordinate_system. +# +# +# +# +# +# +# +# Number of unit cells along each of the d unit vectors. +# The total number of cells, or grid points has to be the cardinality. +# If the grid has an irregular number of grid positions in each direction, +# as it could be for instance the case of a grid where all grid points +# outside some masking primitive are removed, this extent field should +# not be used. Instead use the coordinate field. +# +# +# +# +# +# +# +# +# Reference to or definition of a coordinate system with +# which the positions and directions are interpretable. +# If the coordinate system is not specified the paraprobe +# coordinate system is used. +# +# +# +# +# +# Integer which specifies the first index to be used for +# distinguishing identifiers for cells. Identifiers are defined +# either implicitly or explicitly. For implicit indexing the +# identifiers are defined on the interval +# [identifier_offset, identifier_offset+c-1]. +# For explicit indexing the identifier array has to be defined. +# +# +# +# +# A tight axis-aligned bounding box about the grid. +# +# +# +# For atom probe should be set to true. +# +# +# +# +# Integer which specifies the first index to be used for distinguishing +# hexahedra. Identifiers are defined either implicitly +# or explicitly. For implicit indexing the identifiers are defined on the +# interval [identifier_offset, identifier_offset+c-1]. +# For explicit indexing the identifier array has to be defined. +# +# +# +# +# +# Integer which specifies the first index to be used for distinguishing +# identifiers for vertices. Identifiers are defined either implicitly +# or explicitly. For implicit indexing the identifiers are defined on the +# interval [identifier_offset, identifier_offset+c-1]. +# For explicit indexing the identifier array has to be defined. +# +# +# +# +# Integer which specifies the first index to be used for distinguishing +# identifiers for faces. Identifiers are defined either implicitly +# or explicitly. For implicit indexing the identifiers are defined on the +# interval [identifier_offset, identifier_offset+c-1]. +# For explicit indexing the identifier array has to be defined. +# +# +# +# +# Positions of the vertices. +# +# Users are encouraged to reduce the vertices to unique set of positions +# and vertices as this supports a more efficient storage of the geometry data. +# It is also possible though to store the vertex positions naively in which +# case vertices_are_unique is likely False. +# Naively here means that one for example stores each vertex of a triangle +# mesh even though many vertices are shared between triangles and thus +# the positions of these vertices do not have to be duplicated. +# +# +# +# +# +# +# +# +# Array of identifiers from vertices which describe each face. +# +# The first entry is the identifier of the start vertex of the first face, +# followed by the second vertex of the first face, until the last vertex +# of the first face. Thereafter, the start vertex of the second face, the +# second vertex of the second face, and so on and so forth. +# +# Therefore, summating over the number_of_vertices, allows to extract +# the vertex identifiers for the i-th face on the following index interval +# of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. +# +# +# +# +# +# +# +# +# Six equally formatted sextets chained together. For each +# sextett the first entry is an XDMF primitive topology +# key (here 5 for polygon), the second entry the XDMF primitive +# count value (here 4 because each face is a quad). +# The remaining four values are the vertex indices. +# +# +# +# +# +# +# +# How many distinct boundaries are distinguished? +# Most grids discretize a cubic or cuboidal region. In this case +# six sides can be distinguished, each making an own boundary. +# +# +# +# +# +# Name of the boundaries. E.g. left, right, front, back, bottom, top, +# The field must have as many entries as there are number_of_boundaries. +# +# +# +# +# +# +# +# The boundary conditions for each boundary: +# +# 0 - undefined +# 1 - open +# 2 - periodic +# 3 - mirror +# 4 - von Neumann +# 5 - Dirichlet +# +# +# +# +# +# +# +# +# +# The result of the delocalization based on which subsequent +# iso-surfaces will be computed. In commercial software so far +# there is not a possibility to export such grid. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Cell center of mass positions along x. +# +# +# +# +# +# +# +# +# Cell center of mass positions along y. +# +# +# +# +# +# +# +# Cell center of mass positions along z. +# +# +# +# +# +# +# +# Intensity of the field at given point +# +# +# +# +# +# +# +# Center of mass positions of each voxel for +# rendering the scalar field via XDMF in e.g. +# Paraview. +# +# +# +# +# +# +# +# +# XDMF topology for rendering in combination with +# xdmf_xyz the scalar field via XDFM in e.g. Paraview. +# +# +# +# +# +# +# +# +# The three-dimensional gradient nabla operator applied to +# scalar_field_magnitude. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Cell center of mass positions along x. +# +# +# +# +# +# +# +# +# Cell center of mass positions along y. +# +# +# +# +# +# +# +# Cell center of mass positions along z. +# +# +# +# +# +# +# +# The gradient vector. +# +# +# +# +# +# +# +# +# Center of mass positions of each voxel for +# rendering the scalar field via XDMF in e.g. +# Paraview. +# +# +# +# +# +# +# +# +# XDMF topology for rendering in combination with +# xdmf_xyz the scalar field via XDFM in e.g. Paraview. +# +# +# +# +# +# +# +# +# Halfwidth of the kernel about the central voxel. +# The shape of the kernel is that of a cuboid +# of extent 2*kernel_extent[i] + 1 in each dimension i. +# +# +# +# +# +# +# +# +# +# Sigma of the kernel in each dimension in the paraprobe +# coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. +# +# +# +# +# +# +# +# Expectation value of the kernel in each dimension in the paraprobe +# coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. +# +# +# +# +# +# +# +# +# +# An iso-surface is the boundary between two regions across which +# the magnitude of a scalar field falls below/exceeds a threshold +# magnitude phi. +# For applications in atom probe microscopy the location and shape +# of such a boundary (set) is typically approximated by +# discretization. +# This yields a complex of not necessarily connected geometric +# primitives. Paraprobe-nanochem approximates this complex with +# a soup of triangles. +# +# +# +# +# The threshold or iso-contour value. +# +# +# +# +# Details about the specific marching cubes algorithm +# which was taken to compute the iso-surface. +# The grid is the delocalization grid. +# +# +# +# Reference to the specific implementation of marching cubes used. +# The value placed here should be a DOI. If there are no specific +# DOI or details write not_further_specified, or give at least a +# free-text description. The program and version used is the +# specific paraprobe-nanochem. +# +# +# +# +# +# The resulting triangle soup computed via marching cubes. +# +# +# +# +# +# Integer which specifies the first index to be used for +# distinguishing triangles. Identifiers are defined either +# implicitly or explicitly. For implicit indexing the +# identifiers are defined on the interval +# [identifier_offset, identifier_offset+c-1]. +# +# +# +# +# +# Number of vertices. +# +# +# +# +# Number of faces. +# +# +# +# +# Integer which specifies the first index to be used for distinguishing +# identifiers for vertices. Identifiers are defined either implicitly +# or explicitly. For implicit indexing the identifiers are defined on the +# interval [identifier_offset, identifier_offset+c-1]. +# +# +# +# +# Integer which specifies the first index to be used for distinguishing +# identifiers for faces. Identifiers are defined either implicitly +# or explicitly. For implicit indexing the identifiers are defined on the +# interval [identifier_offset, identifier_offset+c-1]. +# +# +# +# +# Positions of the vertices. +# +# Users are encouraged to reduce the vertices to unique set of positions +# and vertices as this supports a more efficient storage of the geometry data. +# It is also possible though to store the vertex positions naively in which +# case vertices_are_unique is likely False. +# Naively here means that one for example stores each vertex of a triangle +# mesh even though many vertices are shared between triangles and thus +# the positions of these vertices do not have to be duplicated. +# +# +# +# +# +# +# +# +# Array of identifiers from vertices which describe each face. +# +# The first entry is the identifier of the start vertex of the first face, +# followed by the second vertex of the first face, until the last vertex +# of the first face. Thereafter, the start vertex of the second face, the +# second vertex of the second face, and so on and so forth. +# +# Therefore, summating over the number_of_vertices, allows to extract +# the vertex identifiers for the i-th face on the following index interval +# of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. +# +# +# +# +# +# +# +# A list of as many tuples of XDMF topology key, XDMF number +# of vertices and a triple of vertex indices specifying each +# triangle. The total number of entries is n_f_tri * (1+1+3). +# +# +# +# +# +# +# +# +# Direction of each normal. +# +# +# +# +# +# +# +# +# Qualifier how which specifically oriented normal to its +# primitive each normal represents. +# +# * 0 - undefined +# * 1 - outer +# * 2 - inner +# +# +# +# +# +# +# +# +# +# +# Direction of each normal. +# +# +# +# +# +# +# +# +# Qualifier how which specifically oriented normal to its +# primitive each normal represents. +# +# * 0 - undefined +# * 1 - outer +# * 2 - inner +# +# +# +# +# +# +# +# Triangle normals are oriented in the direction of the +# gradient vector of the local delocalized scalar field. +# :math:`\sum_{x, y, z} {\nabla{c}_i}^2`. +# +# +# +# +# +# +# +# +# Triangle normals are oriented in the direction of the +# gradient vector of the local delocalized scalar field. +# The projection variable here describes the cosine of the +# angle between the gradient direction and the normal +# direction vector. +# This is a descriptor of how parallel the projection is +# that is especially useful to document those triangles +# for whose projection is almost perpendicular. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Array of edge length values. For each triangle the edge length +# is reported for the edges traversed according to the sequence +# in which vertices are indexed in triangles. +# +# +# +# +# +# +# +# +# Array of interior angle values. For each triangle the angle +# is reported for the angle opposite to the edges which are +# traversed according to the sequence in which vertices +# are indexed in triangles. +# +# +# +# +# +# +# +# +# The center of mass of each triangle. +# +# +# +# +# +# +# +# +# +# Iso-surfaces of arbitrary scalar three-dimensional fields +# can show a complicated topology. Paraprobe-nanochem can run +# a DBScan-like clustering algorithm which performs a +# connectivity analysis on the triangle soup. This yields a +# set of connected features with their surfaces discretized +# by triangles. Currently, the tool distinguishes at most +# three types of features: +# +# 1. So-called objects, i.e. necessarily watertight features +# represented polyhedra. +# 2. So-called proxies, i.e. features that were replaced by a +# proxy mesh and made watertight. +# 3. Remaining triangle surface meshes of arbitrary shape and +# cardinality. +# +# These features can be interpreted as microstructural features. +# Some of them may be precipitates, some of them may be poles, +# some of them may be segments of dislocation lines or other +# crystal defects which are decorated (or not) with solutes. +# +# +# +# +# The identifier which the triangle_soup connectivity analysis +# returned, which constitutes the first step of the +# volumetric_feature identification process. +# +# +# +# +# +# +# +# The array of keywords of feature_type dictionary. +# +# +# +# +# +# +# +# The array of values for each keyword of the +# feature_type dictionary. +# +# +# +# +# +# +# +# The array of controlled keywords, need to be from +# feature_type_dict_keyword, which specify which type +# each feature triangle cluster belongs to. +# Keep in mind that not each feature is an object or proxy. +# +# +# +# +# +# +# +# The explicit identifier of features. +# +# +# +# +# +# +# +# +# Details for features which are (closed) objects. +# Identifier have to exist in feature_identifier. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# An oriented bounding box (OBB) to each object. +# +# +# +# Edge length of the oriented bounding box from largest +# to smallest value. +# +# +# +# +# +# +# +# +# +# Oriented bounding box aspect ratio. YX versus ZY. +# +# +# +# +# +# +# +# +# Position of the geometric center, which often is but +# not necessarily has to be the center_of_mass of the +# hexahedrally-shaped sample/sample part. +# +# +# +# +# +# +# +# +# +# A simple approach to describe the entire set of hexahedra +# when the main intention is to store the shape of the +# hexahedra for visualization. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Details for all those objects close to edge, i.e. those which +# have at least one ion which lays closer to a modelled edge +# of the dataset than threshold. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Total (count) relevant for normalization. +# +# +# +# +# +# +# +# +# +# +# +# Count or weight which, when divided by total, +# yields the composition of this element, isotope, +# molecule or ion. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Array of evaporation_identifier / ion_identifier which +# specify ions laying inside or on the surface of the feature. +# +# +# +# +# +# +# +# +# +# +# Details for all those objects far from edge, i.e. those +# whose ions lay all at least threshold distant from a +# modelled edge of the dataset. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Total (count) relevant for normalization. +# +# +# +# +# +# +# +# +# +# +# +# Count or weight which, when divided by total +# yields the composition of this element, isotope, +# molecule or ion. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Array of evaporation_identifier / ion_identifier which +# specify ions laying inside or on the surface of the feature. +# +# +# +# +# +# +# +# +# +# +# +# +# Details for features which are so-called proxies, i.e. objects +# which have been reconstructed and combinatorially closed with +# processing their partial triangulated_surface_mesh +# (hole filling, refinement). +# Identifier have to exist in feature_identifier. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Details for those proxies close to edge, i.e. those which +# have at least one ion which lays closer to a modelled edge +# of the dataset than threshold. +# Identifier have to exist in feature_identifier. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Total (count) relevant for normalization. +# +# +# +# +# +# +# +# +# +# Count or weight which, when divided by total +# yields the composition of this element, isotope, +# molecule or ion. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Array of evaporation_identifier / ion_identifier which +# specify ions laying inside or on the surface of the feature. +# +# +# +# +# +# +# +# +# +# +# Details for those proxies far from edge, i.e. those whose +# ions lay all at least threshold distant from a +# modelled edge of the dataset. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Total (count) relevant for normalization. +# +# +# +# +# +# +# +# +# +# Count or weight which, when divided by total +# yields the composition of this element, isotope, +# molecule or ion. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Array of evaporation_identifier / ion_identifier which +# specify ions laying inside or on the surface of the feature. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The multiplicity whereby the ion position is accounted for +# irrespective whether the ion is considered as a decorator +# of the interface or not. +# As an example, with atom probe it is typically not possible +# to resolve the positions of the atoms which arrive at the detector +# as molecular ions. Therefore, an exemplar molecular ion of two carbon +# atoms can be considered to have a multiplicity of two to account that +# this molecular ion contributes two carbon atoms at the reconstructed +# location considering that the spatial resolution of atom probe +# experiments is limited. +# +# +# +# +# +# +# +# The multiplicity whereby the ion position is accounted for when +# the ion is considered one which is a decorator of the interface. +# +# +# +# +# +# +# +# The equation of the plane that is fitted initially. +# +# +# +# The four parameter :math:`ax + by + cz + d = 0` which define the plane. +# +# +# +# +# +# +# +# +# The triangle surface mesh representing the interface model. +# Exported at some iteration before the next DCOM step. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of each normal +# +# +# +# +# +# +# +# +# Qualifier how which specifically oriented normal to its primitive each +# normal represents. +# +# * 0 - undefined +# * 1 - outer +# * 2 - inner +# +# +# +# +# +# +# +# +# +# +# +# Direction of each normal +# +# +# +# +# +# +# +# +# Qualifier how which specifically oriented normal to its primitive each +# normal represents. +# +# * 0 - undefined +# * 1 - outer +# * 2 - inner +# +# +# +# +# +# +# +# +# +# +# +# +# +# Array of edge length values. For each triangle the edge length is +# reported for the edges traversed according to the sequence +# in which vertices are indexed in triangles. +# +# +# +# +# +# +# +# +# Array of interior angle values. For each triangle the angle is +# reported for the angle opposite to the edges which are traversed +# according to the sequence in which vertices are indexed in triangles. +# +# +# +# +# +# +# +# +# +# The triangle surface mesh representing the interface model. +# Exported at some iteration after the next DCOM step. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of each normal +# +# +# +# +# +# +# +# +# Qualifier how which specifically oriented normal to its primitive each +# normal represents. +# +# * 0 - undefined +# * 1 - outer +# * 2 - inner +# +# +# +# +# +# +# +# +# +# +# +# Direction of each normal +# +# +# +# +# +# +# +# +# Qualifier how which specifically oriented normal to its primitive each +# normal represents. +# +# * 0 - undefined +# * 1 - outer +# * 2 - inner +# +# +# +# +# +# +# +# +# +# +# +# +# +# Array of edge length values. For each triangle the edge length is +# reported for the edges traversed according to the sequence +# in which vertices are indexed in triangles. +# +# +# +# +# +# +# +# +# Array of interior angle values. For each triangle the angle is +# reported for the angle opposite to the edges which are traversed +# according to the sequence in which vertices are indexed in triangles. +# +# +# +# +# +# +# +# +# +# +# +# The ROIs are defined as cylinders for the computations. +# To visualize these though we discretize them into regular n-gons. +# Using for instance a 360-gon, i.e. a regular n-gon with 360 +# edges resolves the lateral surface of each cylinder very finely +# so that they are rendered smoothly in visualization software. +# +# +# +# +# +# Position of the geometric center, which often is but not +# necessarily has to be the center_of_mass of the polyhedra. +# +# +# +# +# +# +# +# +# Integer which specifies the first index to be used for distinguishing +# ROI cylinder. Identifiers are defined explicitly. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The number of atoms in each ROI. +# +# +# +# +# +# +# +# The number of ions in each ROI. +# +# +# +# +# +# +# +# The orientation of the ROI defined via a vector which points along +# the cylinder axis and whose length is the height of the cylinder. +# +# +# +# +# +# +# +# +# +# In the direction of the ROI. +# +# +# +# +# Hashvalue +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Specify if it was different from the number_of_processes +# in the NXcs_profiling super class. +# +# +# +# +# +# Specify if it was different from the number_of_threads +# in the NXcs_profiling super class. +# +# +# +# +# +# Specify if it was different from the number_of_threads +# in the NXcs_profiling super class. +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.yaml new file mode 100644 index 0000000000..d953ae989d --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.yaml @@ -0,0 +1,809 @@ +category: application +doc: | + Results of a paraprobe-ranger tool run. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_ions: | + The total number of ions in the reconstruction. + n_ivec_max: | + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. +type: group +NXapm_paraprobe_results_ranger(NXobject): + + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + (NXentry): + exists: ['min', '1', 'max', '1'] + \@version: + doc: | + Version specifier of this application definition. + + ##MK::begin of the tool-specific section + definition: + doc: | + Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_results_ranger] + + ##MK::end of the tool-specific section + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + analysis_identifier: + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: | + Possibility for leaving a free-text description about this analysis. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + config_filename: + doc: | + The path and name of the config file for this analysis. + \@version: + doc: | + At least SHA256 strong hash of the specific config_file for + tracking provenance. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + status: + doc: | + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + enumeration: [success, failure] + (NXuser): + exists: recommended + doc: | + If used, contact information and eventually details + of at least the person who performed this analysis. + name: + affiliation: + exists: recommended + address: + exists: optional + email: + exists: recommended + orcid: + exists: recommended + orcid_platform: + exists: recommended + telephone_number: + exists: optional + role: + exists: recommended + social_media_name: + exists: optional + social_media_platform: + exists: optional + (NXcoordinate_system_set): + exists: optional + doc: | + Details about the coordinate system conventions used. + (NXtransformations): + exists: ['min', '1', 'max', 'unbounded'] + doc: | + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + ##MK::begin of the tool-specific section + (NXprocess): + exists: ['min', '0', 'max', '1'] + apply_existent_ranging(NXprocess): + exists: ['min', '0', 'max', '1'] + doc: | + Paraprobe-ranger loads the iontypes and evaluates for each + ion on which iontype it matches. If it matches on none, the + ion is considered of the default unknown type with a 0 as its + respective value in the iontypes array. + + ##MK::number_of_ion_types(NX_POSINT): + maximum_number_of_atoms_per_molecular_ion(NX_POSINT): + unit: NX_UNITLESS + doc: | + The length of the isotope_vector used to describe molecular ions. + ION(NXion): + exists: ['min', '1', 'max', '256'] + isotope_vector(NX_UINT): + nuclid_list(NX_UINT): + exists: recommended + charge_state(NX_INT): + mass_to_charge_range(NX_FLOAT): + iontypes(NX_UINT): + unit: NX_UNITLESS + doc: | + The iontype ID for each ion that was best matching, stored in the + order of the evaporation sequence ID. The here computed iontypes + do not take into account the charge state of the ion which is + equivalent to interpreting a RNG and RRNG range files for each + ion in such a way that only the elements of which a (molecular) ion + is build are considered. By contrast, charged_iontypes takes + into account also the charge state. + dimensions: + rank: 1 + dim: [[1, n_ions]] + window(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies exactly all those ions ranged irrespective + the type they ended up with. + number_of_ions(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of ions covered by the mask. + The mask value for most may be 0. + + # which does paraprobe use + bitdepth(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + mask(NX_UINT): + unit: NX_UNITLESS + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + dimensions: + rank: 1 + dim: [[1, n_ions]] + molecular_ion_search(NXprocess): + exists: ['min', '0', 'max', '1'] + doc: | + Paraprobe-ranger performs a combinatorial search over + all possible or a reduced set of nuclids to identify + into which ions these can be composed. + isotope_vector_matrix(NX_UINT): + unit: NX_UNITLESS + doc: | + The main result is the list of molecular ions, here formatted + according to the definitions of a set of isotope_vectors + as detailed in :ref:`NXion`. + dimensions: + rank: 2 + dim: [[1, i], [2, 32]] + mass_to_charge_state_ratio(NX_FLOAT): + unit: NX_ANY + doc: | + The mass-to-charge-state ratio of each molecular ion + without considering relativistic or quantum effects. + dimensions: + rank: 1 + dim: [[1, i]] + mass(NX_FLOAT): + exists: optional + unit: NX_ANY + doc: | + The mass of each molecular ion without + considering relativistic or quantum effects. + + # \@units: amu + dimensions: + rank: 1 + dim: [[1, i]] + charge_state(NX_UINT): + unit: NX_CHARGE + doc: | + The charge_state of each molecular ion. + dimensions: + rank: 1 + dim: [[1, i]] + natural_abundance_product(NX_FLOAT): + exists: optional + unit: NX_DIMENSIONLESS + doc: | + The product of the natural abundance of the isotopes building + each molecular ion. Further details are available in + :ref:`NXapm_paraprobe_config_ranger`. + dimensions: + rank: 1 + dim: [[1, i]] + composition_product(NX_FLOAT): + exists: optional + unit: NX_DIMENSIONLESS + doc: | + The product of the natural abundance of the isotopes building + each molecular ion. Further details are available in + :ref:`NXapm_paraprobe_config_ranger`. + dimensions: + rank: 1 + dim: [[1, i]] + number_of_disjoint_nuclids(NX_POSINT): + exists: optional + unit: NX_UNITLESS + doc: | + The number of disjoint nuclids for each molecular ion. + dimensions: + rank: 1 + dim: [[1, i]] + number_of_nuclids(NX_POSINT): + exists: optional + unit: NX_UNITLESS + doc: | + The number of nuclids for each molecular ion. + dimensions: + rank: 1 + dim: [[1, i]] + check_existent_ranging(NXprocess): + exists: ['min', '0', 'max', '1'] + doc: | + Paraprobe-ranger loads iontypes and evaluates for each ion on which + iontype it matches. If it matches on none, the ion is considered of + the default unknown type with a 0 as its respective value in the + iontypes array. In contrast to use_existent_ranging this process + does neither needs measured ion position nor mass-to-charge-state + ratio values. + + ##MK::number_of_ion_types(NX_POSINT): + maximum_number_of_atoms_per_molecular_ion(NX_POSINT): + unit: NX_UNITLESS + doc: | + The length of the isotope_vector used to describe molecular ions. + charged_ION(NXion): + exists: ['min', '1', 'max', '256'] + isotope_vector(NX_UINT): + nuclid_list(NX_UINT): + exists: recommended + charge_state(NX_INT): + mass_to_charge_range(NX_FLOAT): + + ##MK::end of the tool-specific section + performance(NXcs_profiling): + current_working_directory: + command_line_call: + exists: optional + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + total_elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): + (NXcs_computer): + exists: recommended + name: + exists: recommended + operating_system: + \@version: + uuid: + exists: optional + (NXcs_cpu): + exists: ['min', '0', 'max', 'unbounded'] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_gpu): + exists: ['min', '0', 'max', 'unbounded'] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_mm_sys): + exists: ['min', '0', 'max', '1'] + total_physical_memory(NX_NUMBER): + (NXcs_io_sys): + exists: ['min', '0', 'max', '1'] + (NXcs_io_obj): + exists: ['min', '1', 'max', 'unbounded'] + technology: + max_physical_capacity(NX_NUMBER): + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_profiling_event): + start_time(NX_DATE_TIME): + exists: optional + end_time(NX_DATE_TIME): + exists: optional + description: + elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + number_of_threads(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + number_of_gpus(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + max_virtual_memory_snapshot(NX_NUMBER): + exists: recommended + max_resident_memory_snapshot(NX_NUMBER): + exists: recommended + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# d12fb5165f6decda506bf81f54410afba9e54f22e83c0682ba82fe68d7ddbeee +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The total number of ions in the reconstruction. +# +# +# +# +# Maximum number of allowed atoms per (molecular) ion (fragment). +# Needs to match maximum_number_of_atoms_per_molecular_ion. +# +# +# +# +# Results of a paraprobe-ranger tool run. +# +# +# +# +# +# Version specifier of this application definition. +# +# +# +# +# +# Official NeXus NXDL schema with which this file was written. +# +# +# +# +# +# +# +# +# Given name of the program/software/tool with which this NeXus +# (configuration) file was generated. +# +# +# +# Ideally program version plus build number, or commit hash or description +# of ever persistent resources where the source code of the program and +# build instructions can be found so that the program can be configured +# ideally in such a manner that the result of this computational process +# is recreatable in the same deterministic manner. +# +# +# +# +# +# Ideally, a (globally persistent) unique identifier for referring +# to this analysis. +# +# +# +# +# Possibility for leaving a free-text description about this analysis. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when the analysis behind this results file +# was started, i.e. the paraprobe-tool executable started as a process. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when the analysis behind this results file +# were completed and the paraprobe-tool executable exited as a process. +# +# +# +# +# The path and name of the config file for this analysis. +# +# +# +# At least SHA256 strong hash of the specific config_file for +# tracking provenance. +# +# +# +# +# +# Path to the directory where the tool should store NeXus/HDF5 results +# of this analysis. If not specified results will be stored in the +# current working directory. +# +# +# +# +# A statement whether the paraprobe-tool executable managed to +# process the analysis or failed prematurely. +# +# This status is written to the results file after the end_time +# at which point the executable must not compute any analysis. +# Only when this status message is present and shows `success`, the +# user should consider the results. In all other cases it might be +# that the executable has terminated prematurely or another error +# occurred. +# +# +# +# +# +# +# +# +# If used, contact information and eventually details +# of at least the person who performed this analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Details about the coordinate system conventions used. +# +# +# +# The individual coordinate systems which should be used. +# Field names should be prefixed with the following controlled terms +# indicating which individual coordinate system is described: +# +# * paraprobe +# * lab +# * specimen +# * laser +# * leap +# * detector +# * recon +# +# +# +# +# +# +# +# Paraprobe-ranger loads the iontypes and evaluates for each +# ion on which iontype it matches. If it matches on none, the +# ion is considered of the default unknown type with a 0 as its +# respective value in the iontypes array. +# +# +# +# +# The length of the isotope_vector used to describe molecular ions. +# +# +# +# +# +# +# +# +# +# +# The iontype ID for each ion that was best matching, stored in the +# order of the evaporation sequence ID. The here computed iontypes +# do not take into account the charge state of the ion which is +# equivalent to interpreting a RNG and RRNG range files for each +# ion in such a way that only the elements of which a (molecular) ion +# is build are considered. By contrast, charged_iontypes takes +# into account also the charge state. +# +# +# +# +# +# +# +# A bitmask which identifies exactly all those ions ranged irrespective +# the type they ended up with. +# +# +# +# Number of ions covered by the mask. +# The mask value for most may be 0. +# +# +# +# +# +# Number of bits assumed matching on a default datatype. +# (e.g. 8 bits for a C-style uint8). +# +# +# +# +# The unsigned integer array representing the content of the mask. +# If padding is used the padded bits are set to 0. The mask is for +# convenience always as large as the entire dataset as it will +# be stored compressed anyway. The convenience feature with this +# is that then the mask can be decoded with numpy and mirrored +# against the evaporation_id array and one immediately can filter +# out all points that were used by the paraprobe. +# The length of the array adds to the next unsigned integer +# if the number of ions in the dataset is not an integer +# multiple of the bitdepth. +# +# +# +# +# +# +# +# +# +# Paraprobe-ranger performs a combinatorial search over +# all possible or a reduced set of nuclids to identify +# into which ions these can be composed. +# +# +# +# The main result is the list of molecular ions, here formatted +# according to the definitions of a set of isotope_vectors +# as detailed in :ref:`NXion`. +# +# +# +# +# +# +# +# +# The mass-to-charge-state ratio of each molecular ion +# without considering relativistic or quantum effects. +# +# +# +# +# +# +# +# The mass of each molecular ion without +# considering relativistic or quantum effects. +# +# +# +# +# +# +# +# +# The charge_state of each molecular ion. +# +# +# +# +# +# +# +# The product of the natural abundance of the isotopes building +# each molecular ion. Further details are available in +# :ref:`NXapm_paraprobe_config_ranger`. +# +# +# +# +# +# +# +# The product of the natural abundance of the isotopes building +# each molecular ion. Further details are available in +# :ref:`NXapm_paraprobe_config_ranger`. +# +# +# +# +# +# +# +# The number of disjoint nuclids for each molecular ion. +# +# +# +# +# +# +# +# The number of nuclids for each molecular ion. +# +# +# +# +# +# +# +# +# Paraprobe-ranger loads iontypes and evaluates for each ion on which +# iontype it matches. If it matches on none, the ion is considered of +# the default unknown type with a 0 as its respective value in the +# iontypes array. In contrast to use_existent_ranging this process +# does neither needs measured ion position nor mass-to-charge-state +# ratio values. +# +# +# +# +# The length of the isotope_vector used to describe molecular ions. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Specify if it was different from the number_of_processes +# in the NXcs_profiling super class. +# +# +# +# +# +# Specify if it was different from the number_of_threads +# in the NXcs_profiling super class. +# +# +# +# +# +# Specify if it was different from the number_of_threads +# in the NXcs_profiling super class. +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_selector.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_selector.yaml new file mode 100644 index 0000000000..01e5d7073c --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_selector.yaml @@ -0,0 +1,517 @@ +category: application +doc: | + Results of a paraprobe-selector tool run. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_ions: | + The total number of ions in the reconstruction. +type: group +NXapm_paraprobe_results_selector(NXobject): + + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + (NXentry): + exists: ['min', '1', 'max', '1'] + \@version: + doc: | + Version specifier of this application definition. + + ##MK::begin of the tool-specific section + definition: + doc: | + Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_results_selector] + + ##MK::end of the tool-specific section + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + analysis_identifier: + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: | + Possibility for leaving a free-text description about this analysis. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + config_filename: + doc: | + The absolute path and name of the config file for this analysis. + \@version: + doc: | + At least SHA256 strong hash of the specific config_file for + tracking provenance. + status: + doc: | + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + enumeration: [success, failure] + (NXuser): + exists: recommended + doc: | + If used, contact information and eventually details + of at least the person who performed this analysis. + name: + affiliation: + exists: recommended + address: + exists: optional + email: + exists: recommended + orcid: + exists: recommended + orcid_platform: + exists: recommended + telephone_number: + exists: optional + role: + exists: recommended + social_media_name: + exists: optional + social_media_platform: + exists: optional + (NXcoordinate_system_set): + exists: optional + doc: | + Details about the coordinate system conventions used. + (NXtransformations): + exists: ['min', '1', 'max', 'unbounded'] + doc: | + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + ##MK::begin of the tool-specific section + (NXprocess): + exists: ['min', '0', 'max', '1'] + window(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies which of the ions in the dataset + were selected to become included in the region-of-interest (ROI). + number_of_ions(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of ions covered by the mask. + The mask value for most may be 0. + + # which does paraprobe use + bitdepth(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + mask(NX_UINT): + unit: NX_UNITLESS + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + dimensions: + rank: 1 + dim: [[1, n_ions]] + + ##MK::end of the tool-specific section + performance(NXcs_profiling): + exists: recommended + command_line_call: + exists: optional + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + total_elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): + (NXcs_computer): + exists: recommended + name: + exists: recommended + operating_system: + \@version: + uuid: + exists: optional + (NXcs_cpu): + exists: ['min', '0', 'max', 'unbounded'] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_gpu): + exists: ['min', '0', 'max', 'unbounded'] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_mm_sys): + exists: ['min', '0', 'max', '1'] + total_physical_memory(NX_NUMBER): + (NXcs_io_sys): + exists: ['min', '0', 'max', '1'] + (NXcs_io_obj): + exists: ['min', '1', 'max', 'unbounded'] + technology: + max_physical_capacity(NX_NUMBER): + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_profiling_event): + start_time(NX_DATE_TIME): + exists: optional + end_time(NX_DATE_TIME): + exists: optional + description: + elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + number_of_threads(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + number_of_gpus(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + max_virtual_memory_snapshot(NX_NUMBER): + exists: recommended + max_resident_memory_snapshot(NX_NUMBER): + exists: recommended + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 2e31b6b35f88d64a75b245dc46eb1d9fb155c7d641a927710b53367d6395394e +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The total number of ions in the reconstruction. +# +# +# +# +# Results of a paraprobe-selector tool run. +# +# +# +# +# +# Version specifier of this application definition. +# +# +# +# +# +# Official NeXus NXDL schema with which this file was written. +# +# +# +# +# +# +# +# +# Given name of the program/software/tool with which this NeXus +# (configuration) file was generated. +# +# +# +# Ideally program version plus build number, or commit hash or description +# of ever persistent resources where the source code of the program and +# build instructions can be found so that the program can be configured +# ideally in such a manner that the result of this computational process +# is recreatable in the same deterministic manner. +# +# +# +# +# +# Ideally, a (globally persistent) unique identifier for referring +# to this analysis. +# +# +# +# +# Possibility for leaving a free-text description about this analysis. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when the analysis behind this results file +# was started, i.e. the paraprobe-tool executable started as a process. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when the analysis behind this results file +# were completed and the paraprobe-tool executable exited as a process. +# +# +# +# +# The absolute path and name of the config file for this analysis. +# +# +# +# At least SHA256 strong hash of the specific config_file for +# tracking provenance. +# +# +# +# +# +# A statement whether the paraprobe-tool executable managed to +# process the analysis or failed prematurely. +# +# This status is written to the results file after the end_time +# at which point the executable must not compute any analysis. +# Only when this status message is present and shows `success`, the +# user should consider the results. In all other cases it might be +# that the executable has terminated prematurely or another error +# occurred. +# +# +# +# +# +# +# +# +# If used, contact information and eventually details +# of at least the person who performed this analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Details about the coordinate system conventions used. +# +# +# +# The individual coordinate systems which should be used. +# Field names should be prefixed with the following controlled terms +# indicating which individual coordinate system is described: +# +# * paraprobe +# * lab +# * specimen +# * laser +# * leap +# * detector +# * recon +# +# +# +# +# +# +# +# A bitmask which identifies which of the ions in the dataset +# were selected to become included in the region-of-interest (ROI). +# +# +# +# Number of ions covered by the mask. +# The mask value for most may be 0. +# +# +# +# +# +# Number of bits assumed matching on a default datatype. +# (e.g. 8 bits for a C-style uint8). +# +# +# +# +# The unsigned integer array representing the content of the mask. +# If padding is used the padded bits are set to 0. The mask is for +# convenience always as large as the entire dataset as it will +# be stored compressed anyway. The convenience feature with this +# is that then the mask can be decoded with numpy and mirrored +# against the evaporation_id array and one immediately can filter +# out all points that were used by the paraprobe. +# The length of the array adds to the next unsigned integer +# if the number of ions in the dataset is not an integer +# multiple of the bitdepth. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Specify if it was different from the number_of_processes +# in the NXcs_profiling super class. +# +# +# +# +# +# Specify if it was different from the number_of_threads +# in the NXcs_profiling super class. +# +# +# +# +# +# Specify if it was different from the number_of_threads +# in the NXcs_profiling super class. +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.yaml new file mode 100644 index 0000000000..5a8d6e697b --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.yaml @@ -0,0 +1,687 @@ +category: application +doc: | + Results of a paraprobe-spatstat tool run. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_ions: | + The total number of ions in the reconstruction. +type: group +NXapm_paraprobe_results_spatstat(NXobject): + + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + (NXentry): + exists: ['min', '1', 'max', '1'] + \@version: + doc: | + Version specifier of this application definition. + + ##MK::begin of the tool-specific section + definition: + doc: | + Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_results_spatstat] + + ##MK::end of the tool-specific section + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + analysis_identifier: + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: | + Possibility for leaving a free-text description about this analysis. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + config_filename: + doc: | + The absolute path and name of the config file for this analysis. + \@version: + doc: | + At least SHA256 strong hash of the specific config_file for + tracking provenance. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + status: + doc: | + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + enumeration: [success, failure] + (NXuser): + exists: recommended + doc: | + If used, contact information and eventually details + of at least the person who performed this analysis. + name: + affiliation: + exists: recommended + address: + exists: optional + email: + exists: recommended + orcid: + exists: recommended + orcid_platform: + exists: recommended + telephone_number: + exists: optional + role: + exists: recommended + social_media_name: + exists: optional + social_media_platform: + exists: optional + (NXcoordinate_system_set): + exists: optional + doc: | + Details about the coordinate system conventions used. + (NXtransformations): + exists: ['min', '1', 'max', 'unbounded'] + doc: | + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + ##MK::begin of the tool-specific section + (NXprocess): + exists: ['min', '0', 'max', '1'] + window(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies which of the ions in the dataset were + analyzed. + number_of_ions(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of ions covered by the mask. + The mask value for most may be 0. + + # which does paraprobe use + bitdepth(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + mask(NX_UINT): + unit: NX_UNITLESS + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + dimensions: + rank: 1 + dim: [[1, n_ions]] + iontypes_randomized(NX_UINT): + unit: NX_UNITLESS + doc: | + The iontype ID for each ion that was assigned to each ion during + the randomization of the ionlabels. Iontype labels are just permuted + but the total number of values for each iontype stay the same. + + The order matches the iontypes array from a given ranging results + as is specified in the configuration settings inside the specific + config_filename that was used for this spatstat analysis. + dimensions: + rank: 1 + dim: [[1, n_ions]] + knn(NXprocess): + exists: optional + doc: | + K-nearest neighbor statistics. + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + Right boundary of the binning. + dimensions: + rank: 1 + dim: [[1, i]] + probability_mass(NX_FLOAT): + unit: NX_DIMENSIONLESS + dimensions: + rank: 1 + dim: [[1, i]] + cumulated(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Cumulated + dimensions: + rank: 1 + dim: [[1, i]] + cumulated_normalized(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + Cumulated and normalized by total counts + dimensions: + rank: 1 + dim: [[1, i]] + rdf(NXprocess): + exists: optional + doc: | + Radial distribution statistics. + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + Right boundary of the binning. + dimensions: + rank: 1 + dim: [[1, i]] + probability_mass(NX_FLOAT): + unit: NX_DIMENSIONLESS + dimensions: + rank: 1 + dim: [[1, i]] + cumulated(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Cumulated + dimensions: + rank: 1 + dim: [[1, i]] + cumulated_normalized(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + Cumulated and normalized by total counts + dimensions: + rank: 1 + dim: [[1, i]] + + ##MK::end of the tool-specific section + performance(NXcs_profiling): + exists: recommended + current_working_directory: + command_line_call: + exists: optional + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + total_elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): + (NXcs_computer): + exists: recommended + name: + exists: recommended + operating_system: + \@version: + uuid: + exists: optional + (NXcs_cpu): + exists: ['min', '0', 'max', 'unbounded'] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_gpu): + exists: ['min', '0', 'max', 'unbounded'] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_mm_sys): + exists: ['min', '0', 'max', '1'] + total_physical_memory(NX_NUMBER): + (NXcs_io_sys): + exists: ['min', '0', 'max', '1'] + (NXcs_io_obj): + exists: ['min', '1', 'max', 'unbounded'] + technology: + max_physical_capacity(NX_NUMBER): + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_profiling_event): + start_time(NX_DATE_TIME): + exists: optional + end_time(NX_DATE_TIME): + exists: optional + description: + elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + number_of_threads(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + number_of_gpus(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + max_virtual_memory_snapshot(NX_NUMBER): + exists: recommended + max_resident_memory_snapshot(NX_NUMBER): + exists: recommended + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 224c4d79678a47bb6e07b21f6ad8592f7f0cd10f4daac6ccd71127d064185b13 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The total number of ions in the reconstruction. +# +# +# +# +# Results of a paraprobe-spatstat tool run. +# +# +# +# +# +# Version specifier of this application definition. +# +# +# +# +# +# Official NeXus NXDL schema with which this file was written. +# +# +# +# +# +# +# +# +# Given name of the program/software/tool with which this NeXus +# (configuration) file was generated. +# +# +# +# Ideally program version plus build number, or commit hash or description +# of ever persistent resources where the source code of the program and +# build instructions can be found so that the program can be configured +# ideally in such a manner that the result of this computational process +# is recreatable in the same deterministic manner. +# +# +# +# +# +# Ideally, a (globally persistent) unique identifier for referring +# to this analysis. +# +# +# +# +# Possibility for leaving a free-text description about this analysis. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when the analysis behind this results file +# was started, i.e. the paraprobe-tool executable started as a process. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when the analysis behind this results file +# were completed and the paraprobe-tool executable exited as a process. +# +# +# +# +# The absolute path and name of the config file for this analysis. +# +# +# +# At least SHA256 strong hash of the specific config_file for +# tracking provenance. +# +# +# +# +# +# Path to the directory where the tool should store NeXus/HDF5 results +# of this analysis. If not specified results will be stored in the +# current working directory. +# +# +# +# +# A statement whether the paraprobe-tool executable managed to +# process the analysis or failed prematurely. +# +# This status is written to the results file after the end_time +# at which point the executable must not compute any analysis. +# Only when this status message is present and shows `success`, the +# user should consider the results. In all other cases it might be +# that the executable has terminated prematurely or another error +# occurred. +# +# +# +# +# +# +# +# +# If used, contact information and eventually details +# of at least the person who performed this analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Details about the coordinate system conventions used. +# +# +# +# The individual coordinate systems which should be used. +# Field names should be prefixed with the following controlled terms +# indicating which individual coordinate system is described: +# +# * paraprobe +# * lab +# * specimen +# * laser +# * leap +# * detector +# * recon +# +# +# +# +# +# +# +# A bitmask which identifies which of the ions in the dataset were +# analyzed. +# +# +# +# Number of ions covered by the mask. +# The mask value for most may be 0. +# +# +# +# +# +# Number of bits assumed matching on a default datatype. +# (e.g. 8 bits for a C-style uint8). +# +# +# +# +# The unsigned integer array representing the content of the mask. +# If padding is used the padded bits are set to 0. The mask is for +# convenience always as large as the entire dataset as it will +# be stored compressed anyway. The convenience feature with this +# is that then the mask can be decoded with numpy and mirrored +# against the evaporation_id array and one immediately can filter +# out all points that were used by the paraprobe. +# The length of the array adds to the next unsigned integer +# if the number of ions in the dataset is not an integer +# multiple of the bitdepth. +# +# +# +# +# +# +# +# +# The iontype ID for each ion that was assigned to each ion during +# the randomization of the ionlabels. Iontype labels are just permuted +# but the total number of values for each iontype stay the same. +# +# The order matches the iontypes array from a given ranging results +# as is specified in the configuration settings inside the specific +# config_filename that was used for this spatstat analysis. +# +# +# +# +# +# +# +# K-nearest neighbor statistics. +# +# +# +# Right boundary of the binning. +# +# +# +# +# +# +# +# +# +# +# +# +# Cumulated +# +# +# +# +# +# +# +# Cumulated and normalized by total counts +# +# +# +# +# +# +# +# +# Radial distribution statistics. +# +# +# +# Right boundary of the binning. +# +# +# +# +# +# +# +# +# +# +# +# +# Cumulated +# +# +# +# +# +# +# +# Cumulated and normalized by total counts +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Specify if it was different from the number_of_processes +# in the NXcs_profiling super class. +# +# +# +# +# +# Specify if it was different from the number_of_threads +# in the NXcs_profiling super class. +# +# +# +# +# +# Specify if it was different from the number_of_threads +# in the NXcs_profiling super class. +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.yaml new file mode 100644 index 0000000000..f865daed53 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.yaml @@ -0,0 +1,935 @@ +category: application +doc: | + Results of a paraprobe-surfacer tool run. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_ions: | + The total number of ions in the reconstruction. + n_v_tri: | + The number of vertices of the alpha complex. + n_f_tri: | + The number of faces of the alpha complex. + n_f_tri_xdmf: | + The total number of XDMF values to represent all faces of triangles via XDMF. + n_f_tet_xdmf: | + The total number of XDMF values to represent all faces of tetrahedra via XDMF. +type: group +NXapm_paraprobe_results_surfacer(NXobject): + + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + (NXentry): + exists: ['min', '1', 'max', '1'] + \@version: + doc: | + Version specifier of this application definition. + + ##MK::begin of the tool-specific section + definition: + doc: | + Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_results_surfacer] + + ##MK::end of the tool-specific section + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + analysis_identifier: + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: | + Possibility for leaving a free-text description about this analysis. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + config_filename: + doc: | + The absolute path and name of the config file for this analysis. + \@version: + doc: | + At least SHA256 strong hash of the specific config_file for + tracking provenance. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + status: + doc: | + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + enumeration: [success, failure] + (NXuser): + exists: recommended + doc: | + If used, contact information and eventually details + of at least the person who performed this analysis. + name: + affiliation: + exists: recommended + address: + exists: optional + email: + exists: recommended + orcid: + exists: recommended + orcid_platform: + exists: recommended + telephone_number: + exists: optional + role: + exists: recommended + social_media_name: + exists: optional + social_media_platform: + exists: optional + (NXcoordinate_system_set): + doc: | + Details about the coordinate system conventions used. + (NXtransformations): + exists: ['min', '1', 'max', 'unbounded'] + doc: | + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + ##MK::begin of the tool-specific section + (NXprocess): + exists: ['min', '0', 'max', '1'] + window(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies which of the ions in the dataset were + analyzed. Computations of alpha complexes may have filtered this + ion set further but this process is deterministic. + number_of_ions(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of ions covered by the mask. The mask may be 0 for most. + bitdepth(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + mask(NX_UINT): + unit: NX_UNITLESS + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + dimensions: + rank: 1 + dim: [[1, i]] + POINT_SET_WRAPPING(NXprocess): + exists: ['min', '0', 'max', 'unbounded'] + doc: | + Paraprobe-surfacer can be used to load a ROI that is the entire or a + sub-set of the ion point cloud. In the point_cloud_wrapping process + the tool computes a triangulated surface mesh which encloses the + ROI/point cloud. This mesh can be seen as a model for the edge of + the dataset. + Different algorithms can be used with paraprobe-surfacer to create + this mesh such as convex hulls, alpha-shapes as their generalization, + or alpha wrappings. + Ideally, the resulting mesh should be a watertight polyhedron. + This polyhedron is not necessarily convex. For some algorithms there + is no guarantee that the resulting mesh yields a watertight mesh. + + # (NXcg_grid): currently we do not store the underlying grid + # for eventually performed preprocessing + alpha_complex(NXcg_alpha_complex): + exists: ['min', '0', 'max', 'unbounded'] + window(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies exactly all those ions whose positions + were considered when defining the filtered point set from which + the alpha complex was then in fact computed. This window + can be different to the entire window as irrelevant ions might + have been filtered out to reduce the computational costs of the + alpha complex analysis. + + # filtered in addition to the ROI or again the entire dataset + number_of_ions(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of ions covered by the mask. + The mask value for most may be 0. + + # which does paraprobe use + bitdepth(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + mask(NX_UINT): + unit: NX_UNITLESS + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + dimensions: + rank: 1 + dim: [[1, n_ions]] + dimensionality(NX_UINT): + unit: NX_UNITLESS + enumeration: [2, 3] + type: + enumeration: [convex_hull, alpha_shape, alpha_wrapping, other, undefined] + mode: + enumeration: [general, regularized] + alpha(NX_NUMBER): + unit: NX_LENGTH + offset(NX_NUMBER): + exists: optional + unit: NX_LENGTH + triangle_set(NXcg_triangle_set): + exists: optional + doc: | + The set of triangles in the coordinate system paraprobe + which discretizes the exterior surface of the alpha complex. + identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for distinguishing + triangles. Identifiers are defined either implicitly or explicitly. + For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + triangles(NXcg_face_list_data_structure): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + number_of_vertices(NX_POSINT): + unit: NX_UNITLESS + doc: | + Number of vertices. + number_of_faces(NX_POSINT): + unit: NX_UNITLESS + doc: | + Number of faces. + vertex_identifier_offset(NX_INT): + unit: NX_UNITLESS + face_identifier_offset(NX_INT): + unit: NX_UNITLESS + vertices(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, n_v_tri], [2, 3]] + faces(NX_UINT): + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_f_tri], [2, 3]] + xdmf_topology(NX_UINT): + unit: NX_UNITLESS + doc: | + A list of as many tuples of XDMF topology key, XDMF number + of vertices and a triple of vertex indices specifying each + triangle. The total number of entries is n_f_tri * (1+1+3). + dimensions: + rank: 1 + dim: [[1, n_f_tri_xdmf]] + is_watertight(NX_BOOLEAN): + exists: optional + doc: | + Do the triangles define a triangulated surface mesh which + is watertight? + volume(NX_FLOAT): + exists: optional + unit: NX_VOLUME + doc: | + The volume which the triangulated surface mesh encloses + provided that the mesh is watertight. + interior_tetrahedra(NXcg_tetrahedron_set): + exists: optional + doc: | + The set of tetrahedra which represent the interior volume of the + complex if that is a closed 2-manifold. + identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for distin- + guishing tetrahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined + on the interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + volume(NX_FLOAT): + exists: optional + unit: NX_VOLUME + doc: | + The accumulated volume of all interior tetrahedra. + tetrahedra(NXcg_face_list_data_structure): + exists: optional + number_of_vertices(NX_POSINT): + unit: NX_UNITLESS + doc: | + Number of vertices. + number_of_faces(NX_POSINT): + unit: NX_UNITLESS + doc: | + Number of faces. + vertex_identifier_offset(NX_INT): + unit: NX_UNITLESS + face_identifier_offset(NX_INT): + unit: NX_UNITLESS + vertices(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, n_v_tet], [2, 3]] + xdmf_topology(NX_UINT): + unit: NX_UNITLESS + doc: | + A list of as many tuples of XDMF topology key, XDMF number + of vertices and a triple of vertex indices specifying each + triangle. The total number of entries is n_f_tet * (1+1+4). + dimensions: + rank: 1 + dim: [[1, n_f_tet_xdmf]] + TRIANGLE_SET_WRAPPING(NXprocess): + exists: ['min', '0', 'max', 'unbounded'] + doc: | + In the future we may want to wrap other primitives + like triangles or polylines. + + ##MK::end of the tool-specific section + performance(NXcs_profiling): + exists: recommended + current_working_directory: + command_line_call: + exists: optional + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + total_elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): + (NXcs_computer): + exists: recommended + name: + exists: recommended + operating_system: + \@version: + uuid: + exists: optional + (NXcs_cpu): + exists: ['min', '0', 'max', 'unbounded'] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_gpu): + exists: ['min', '0', 'max', 'unbounded'] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_mm_sys): + exists: ['min', '0', 'max', '1'] + total_physical_memory(NX_NUMBER): + (NXcs_io_sys): + exists: ['min', '0', 'max', '1'] + (NXcs_io_obj): + exists: ['min', '1', 'max', 'unbounded'] + technology: + max_physical_capacity(NX_NUMBER): + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_profiling_event): + start_time(NX_DATE_TIME): + exists: optional + end_time(NX_DATE_TIME): + exists: optional + description: + elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + number_of_threads(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + number_of_gpus(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + max_virtual_memory_snapshot(NX_NUMBER): + exists: recommended + max_resident_memory_snapshot(NX_NUMBER): + exists: recommended + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 9d0676f28ebba35d9a70595e9c692a6506d83179dc6cf2b8bb5d9dba669ce196 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The total number of ions in the reconstruction. +# +# +# +# +# The number of vertices of the alpha complex. +# +# +# +# +# The number of faces of the alpha complex. +# +# +# +# +# The total number of XDMF values to represent all faces of triangles via XDMF. +# +# +# +# +# The total number of XDMF values to represent all faces of tetrahedra via XDMF. +# +# +# +# +# Results of a paraprobe-surfacer tool run. +# +# +# +# +# +# Version specifier of this application definition. +# +# +# +# +# +# Official NeXus NXDL schema with which this file was written. +# +# +# +# +# +# +# +# +# Given name of the program/software/tool with which this NeXus +# (configuration) file was generated. +# +# +# +# Ideally program version plus build number, or commit hash or description +# of ever persistent resources where the source code of the program and +# build instructions can be found so that the program can be configured +# ideally in such a manner that the result of this computational process +# is recreatable in the same deterministic manner. +# +# +# +# +# +# Ideally, a (globally persistent) unique identifier for referring +# to this analysis. +# +# +# +# +# Possibility for leaving a free-text description about this analysis. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when the analysis behind this results file +# was started, i.e. the paraprobe-tool executable started as a process. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when the analysis behind this results file +# were completed and the paraprobe-tool executable exited as a process. +# +# +# +# +# The absolute path and name of the config file for this analysis. +# +# +# +# At least SHA256 strong hash of the specific config_file for +# tracking provenance. +# +# +# +# +# +# Path to the directory where the tool should store NeXus/HDF5 results +# of this analysis. If not specified results will be stored in the +# current working directory. +# +# +# +# +# A statement whether the paraprobe-tool executable managed to +# process the analysis or failed prematurely. +# +# This status is written to the results file after the end_time +# at which point the executable must not compute any analysis. +# Only when this status message is present and shows `success`, the +# user should consider the results. In all other cases it might be +# that the executable has terminated prematurely or another error +# occurred. +# +# +# +# +# +# +# +# +# If used, contact information and eventually details +# of at least the person who performed this analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Details about the coordinate system conventions used. +# +# +# +# The individual coordinate systems which should be used. +# Field names should be prefixed with the following controlled terms +# indicating which individual coordinate system is described: +# +# * paraprobe +# * lab +# * specimen +# * laser +# * leap +# * detector +# * recon +# +# +# +# +# +# +# +# A bitmask which identifies which of the ions in the dataset were +# analyzed. Computations of alpha complexes may have filtered this +# ion set further but this process is deterministic. +# +# +# +# Number of ions covered by the mask. The mask may be 0 for most. +# +# +# +# +# Number of bits assumed matching on a default datatype. +# (e.g. 8 bits for a C-style uint8). +# +# +# +# +# The unsigned integer array representing the content of the mask. +# If padding is used the padded bits are set to 0. The mask is for +# convenience always as large as the entire dataset as it will +# be stored compressed anyway. The convenience feature with this +# is that then the mask can be decoded with numpy and mirrored +# against the evaporation_id array and one immediately can filter +# out all points that were used by the paraprobe. +# The length of the array adds to the next unsigned integer +# if the number of ions in the dataset is not an integer +# multiple of the bitdepth. +# +# +# +# +# +# +# +# +# Paraprobe-surfacer can be used to load a ROI that is the entire or a +# sub-set of the ion point cloud. In the point_cloud_wrapping process +# the tool computes a triangulated surface mesh which encloses the +# ROI/point cloud. This mesh can be seen as a model for the edge of +# the dataset. +# Different algorithms can be used with paraprobe-surfacer to create +# this mesh such as convex hulls, alpha-shapes as their generalization, +# or alpha wrappings. +# Ideally, the resulting mesh should be a watertight polyhedron. +# This polyhedron is not necessarily convex. For some algorithms there +# is no guarantee that the resulting mesh yields a watertight mesh. +# +# +# +# +# +# A bitmask which identifies exactly all those ions whose positions +# were considered when defining the filtered point set from which +# the alpha complex was then in fact computed. This window +# can be different to the entire window as irrelevant ions might +# have been filtered out to reduce the computational costs of the +# alpha complex analysis. +# +# +# +# +# Number of ions covered by the mask. +# The mask value for most may be 0. +# +# +# +# +# +# Number of bits assumed matching on a default datatype. +# (e.g. 8 bits for a C-style uint8). +# +# +# +# +# The unsigned integer array representing the content of the mask. +# If padding is used the padded bits are set to 0. The mask is for +# convenience always as large as the entire dataset as it will +# be stored compressed anyway. The convenience feature with this +# is that then the mask can be decoded with numpy and mirrored +# against the evaporation_id array and one immediately can filter +# out all points that were used by the paraprobe. +# The length of the array adds to the next unsigned integer +# if the number of ions in the dataset is not an integer +# multiple of the bitdepth. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The set of triangles in the coordinate system paraprobe +# which discretizes the exterior surface of the alpha complex. +# +# +# +# Integer which specifies the first index to be used for distinguishing +# triangles. Identifiers are defined either implicitly or explicitly. +# For implicit indexing the identifiers are defined on the +# interval [identifier_offset, identifier_offset+c-1]. +# +# +# +# +# +# +# Number of vertices. +# +# +# +# +# Number of faces. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# A list of as many tuples of XDMF topology key, XDMF number +# of vertices and a triple of vertex indices specifying each +# triangle. The total number of entries is n_f_tri * (1+1+3). +# +# +# +# +# +# +# +# +# Do the triangles define a triangulated surface mesh which +# is watertight? +# +# +# +# +# The volume which the triangulated surface mesh encloses +# provided that the mesh is watertight. +# +# +# +# +# +# The set of tetrahedra which represent the interior volume of the +# complex if that is a closed 2-manifold. +# +# +# +# Integer which specifies the first index to be used for distin- +# guishing tetrahedra. Identifiers are defined either implicitly +# or explicitly. For implicit indexing the identifiers are defined +# on the interval [identifier_offset, identifier_offset+c-1]. +# For explicit indexing the identifier array has to be defined. +# +# +# +# +# The accumulated volume of all interior tetrahedra. +# +# +# +# +# +# Number of vertices. +# +# +# +# +# Number of faces. +# +# +# +# +# +# +# +# +# +# +# +# +# A list of as many tuples of XDMF topology key, XDMF number +# of vertices and a triple of vertex indices specifying each +# triangle. The total number of entries is n_f_tet * (1+1+4). +# +# +# +# +# +# +# +# +# +# +# +# In the future we may want to wrap other primitives +# like triangles or polylines. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Specify if it was different from the number_of_processes +# in the NXcs_profiling super class. +# +# +# +# +# +# Specify if it was different from the number_of_threads +# in the NXcs_profiling super class. +# +# +# +# +# +# Specify if it was different from the number_of_threads +# in the NXcs_profiling super class. +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.yaml new file mode 100644 index 0000000000..351fd374a5 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.yaml @@ -0,0 +1,1284 @@ +category: application +doc: | + Results of a paraprobe-tessellator tool run. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_ions: | + The total number of ions in the reconstruction. + n_f_xdmf: | + The total number of facets/polygons defining the tessellation. +type: group +NXapm_paraprobe_results_tessellator(NXobject): + + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + (NXentry): + exists: ['min', '1', 'max', '1'] + \@version: + doc: | + Version specifier of this application definition. + + ##MK::begin of the tool-specific section + definition: + doc: | + Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_results_tessellator] + + ##MK::end of the tool-specific section + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + analysis_identifier: + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: | + Possibility for leaving a free-text description about this analysis. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + config_filename: + doc: | + The absolute path and name of the config file for this analysis. + \@version: + doc: | + At least SHA256 strong hash of the specific config_file for + tracking provenance. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + status: + doc: | + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + enumeration: [success, failure] + (NXuser): + exists: recommended + doc: | + If used, contact information and eventually details + of at least the person who performed this analysis. + name: + affiliation: + exists: recommended + address: + exists: optional + email: + exists: recommended + orcid: + exists: recommended + orcid_platform: + exists: recommended + telephone_number: + exists: optional + role: + exists: recommended + social_media_name: + exists: optional + social_media_platform: + exists: optional + (NXcoordinate_system_set): + doc: | + Details about the coordinate system conventions used. + (NXtransformations): + exists: ['min', '1', 'max', 'unbounded'] + doc: | + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + ##MK::begin of the tool-specific section + (NXprocess): + exists: ['min', '0', 'max', '1'] + voronoi_tessellation(NXprocess): + doc: | + The tool can be used to compute a Voronoi tessellation the entire + or a sub-set of the reconstruction. The point cloud in the ROI is + wrapped into a tight axis-aligned bounding box. The tool detects if + Voronoi cells make contact with the walls of this bounding box. + The tessellation is computed without periodic boundary conditions. + window(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies which of the ions in the dataset were + analyzed. + number_of_ions(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of ions covered by the mask. + The mask value for most may be 0. + + # which does paraprobe use + bitdepth(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + mask(NX_UINT): + unit: NX_UNITLESS + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + dimensions: + rank: 1 + dim: [[1, n_ions]] + wall_contact_global(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies which of points have Voronoi cells that + are truncated by the global axis-aligned bounding box, i.e. boundaries + of the threads are ignored. + number_of_ions(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of points covered by the mask. + The mask value for most may be 0. + + # which does paraprobe use + bitdepth(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + mask(NX_UINT): + unit: NX_UNITLESS + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + dimensions: + rank: 1 + dim: [[1, i]] + + ##MK::optional documenting of touching on thread-local boundaries + wall_contact_left(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies which of points have Voronoi cells that + are truncated by a specific wall of the axis-aligned bounding box. + The left wall has the negative x axis of the paraprobe coordinate + system as the outer unit normal. + number_of_ions(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of points covered by the mask. + The mask value for most may be 0. + + # which does paraprobe use + bitdepth(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + mask(NX_UINT): + unit: NX_UNITLESS + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + dimensions: + rank: 1 + dim: [[1, i]] + wall_contact_right(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies which of points have Voronoi cells that + are truncated by a specific wall of the axis-aligned bounding box. + The right wall has the positive x axis of the paraprobe coordinate + system as the outer unit normal. + number_of_ions(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of points covered by the mask. + The mask value for most may be 0. + + # which does paraprobe use + bitdepth(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + mask(NX_UINT): + unit: NX_UNITLESS + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + dimensions: + rank: 1 + dim: [[1, i]] + wall_contact_front(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies which of points have Voronoi cells that + are truncated by a specific wall of the axis-aligned bounding box. + The front wall has the negative y axis of the paraprobe coordinate + system as the outer unit normal. + number_of_ions(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of points covered by the mask. + The mask value for most may be 0. + + # which does paraprobe use + bitdepth(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + mask(NX_UINT): + unit: NX_UNITLESS + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + dimensions: + rank: 1 + dim: [[1, i]] + wall_contact_rear(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies which of points have Voronoi cells that + are truncated by a specific wall of the axis-aligned bounding box. + The rear wall has the positive y axis of the paraprobe coordinate + system as the outer unit normal. + number_of_ions(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of points covered by the mask. + The mask value for most may be 0. + + # which does paraprobe use + bitdepth(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + mask(NX_UINT): + unit: NX_UNITLESS + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + dimensions: + rank: 1 + dim: [[1, i]] + wall_contact_bottom(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies which of points have Voronoi cells that + are truncated by a specific wall of the axis-aligned bounding box. + The left wall has the negative z axis of the paraprobe coordinate + system as the outer unit normal. + number_of_ions(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of points covered by the mask. + The mask value for most may be 0. + + # which does paraprobe use + bitdepth(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + mask(NX_UINT): + unit: NX_UNITLESS + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + dimensions: + rank: 1 + dim: [[1, i]] + wall_contact_top(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies which of points have Voronoi cells that + are truncated by a specific wall of the axis-aligned bounding box. + The left wall has the positive z axis of the paraprobe coordinate + system as the outer unit normal. + number_of_ions(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of points covered by the mask. + The mask value for most may be 0. + + # which does paraprobe use + bitdepth(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + mask(NX_UINT): + unit: NX_UNITLESS + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + dimensions: + rank: 1 + dim: [[1, i]] + voronoi_cells(NXcg_polyhedron_set): + exists: optional + dimensionality(NX_POSINT): + unit: NX_UNITLESS + enumeration: [3] + cardinality(NX_POSINT): + unit: NX_UNITLESS + volume(NX_NUMBER): + unit: NX_VOLUME + doc: | + Interior volume + dimensions: + rank: 1 + dim: [[1, i]] + process_identifier(NX_POSINT): + exists: optional + unit: NX_UNITLESS + doc: | + By which MPI process was the Voronoi cell computed. + dimensions: + rank: 1 + dim: [[1, i]] + thread_identifier(NX_POSINT): + exists: optional + unit: NX_UNITLESS + doc: | + By which OpenMP thread was the Voronoi cell computed. + dimensions: + rank: 1 + dim: [[1, i]] + number_of_faces(NX_POSINT): + exists: optional + unit: NX_UNITLESS + doc: | + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. This field can be used to interpret + the array/field with the individual area values for each face. + dimensions: + rank: 1 + dim: [[1, i]] + + # (NXtransformations): + # exists: optional + # doc: | + # Reference to or definition of a coordinate system with + # which the qualifiers and mesh data are interpretable. + # substantially more detailed descriptors of the shape, the mesh + identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for distinguishing + polyhedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + identifier(NX_INT): + exists: optional + unit: NX_UNITLESS + doc: | + Integer used to distinguish polyhedra for explicit indexing. + dimensions: + rank: 1 + dim: [[1, i]] + polyhedra(NXcg_face_list_data_structure): + exists: ['min', '0', 'max', '1'] + doc: | + A simple approach to describe the entire set of polyhedra when + the main intention is to store the shape of the polyhedra for + visualization. + dimensionality(NX_POSINT): + unit: NX_UNITLESS + number_of_vertices(NX_POSINT): + unit: NX_UNITLESS + doc: | + Number of vertices. + number_of_faces(NX_POSINT): + unit: NX_UNITLESS + doc: | + Number of faces. + vertex_identifier_offset(NX_INT): + unit: NX_UNITLESS + face_identifier_offset(NX_INT): + unit: NX_UNITLESS + vertices(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, i], [2, 3]] + xdmf_topology(NX_UINT): + unit: NX_UNITLESS + doc: | + A sequence of always first an XDMF topology type key, followed + by the XDMF number of vertices of the polygon, followed by + the vertex identifier which define the facet polygon. First + we store the polygon of the first facet of the first cell, then + the second facet of the first cell, until the last facet of the + first cell, followed by the first facet of the second cell, + and so on and so forth. + dimensions: + rank: 1 + dim: [[1, j]] + xdmf_cell_identifier(NX_UINT): + unit: NX_UNITLESS + doc: | + A sequence of cell identifier so that each facet is associated + with its cell because of which it is then possible to segment + out cells three-dimensionally based on cell i.e. evaporation_id. + dimensions: + rank: 1 + dim: [[1, n_f_xdmf]] + + ##MK::end of the tool-specific section + performance(NXcs_profiling): + exists: recommended + current_working_directory: + command_line_call: + exists: optional + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + total_elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): + (NXcs_computer): + exists: recommended + name: + exists: recommended + operating_system: + \@version: + uuid: + exists: optional + (NXcs_cpu): + exists: ['min', '0', 'max', 'unbounded'] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_gpu): + exists: ['min', '0', 'max', 'unbounded'] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_mm_sys): + exists: ['min', '0', 'max', '1'] + total_physical_memory(NX_NUMBER): + (NXcs_io_sys): + exists: ['min', '0', 'max', '1'] + (NXcs_io_obj): + exists: ['min', '1', 'max', 'unbounded'] + technology: + max_physical_capacity(NX_NUMBER): + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_profiling_event): + start_time(NX_DATE_TIME): + exists: optional + end_time(NX_DATE_TIME): + exists: optional + description: + elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + number_of_threads(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + number_of_gpus(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + max_virtual_memory_snapshot(NX_NUMBER): + exists: recommended + max_resident_memory_snapshot(NX_NUMBER): + exists: recommended + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 8ec5c3b4cc5fa3566c8de12c5be7e9e8690840d962a5ee897b491e67196f1ea0 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The total number of ions in the reconstruction. +# +# +# +# +# The total number of facets/polygons defining the tessellation. +# +# +# +# +# Results of a paraprobe-tessellator tool run. +# +# +# +# +# +# Version specifier of this application definition. +# +# +# +# +# +# Official NeXus NXDL schema with which this file was written. +# +# +# +# +# +# +# +# +# Given name of the program/software/tool with which this NeXus +# (configuration) file was generated. +# +# +# +# Ideally program version plus build number, or commit hash or description +# of ever persistent resources where the source code of the program and +# build instructions can be found so that the program can be configured +# ideally in such a manner that the result of this computational process +# is recreatable in the same deterministic manner. +# +# +# +# +# +# Ideally, a (globally persistent) unique identifier for referring +# to this analysis. +# +# +# +# +# Possibility for leaving a free-text description about this analysis. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when the analysis behind this results file +# was started, i.e. the paraprobe-tool executable started as a process. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when the analysis behind this results file +# were completed and the paraprobe-tool executable exited as a process. +# +# +# +# +# The absolute path and name of the config file for this analysis. +# +# +# +# At least SHA256 strong hash of the specific config_file for +# tracking provenance. +# +# +# +# +# +# Path to the directory where the tool should store NeXus/HDF5 results +# of this analysis. If not specified results will be stored in the +# current working directory. +# +# +# +# +# A statement whether the paraprobe-tool executable managed to +# process the analysis or failed prematurely. +# +# This status is written to the results file after the end_time +# at which point the executable must not compute any analysis. +# Only when this status message is present and shows `success`, the +# user should consider the results. In all other cases it might be +# that the executable has terminated prematurely or another error +# occurred. +# +# +# +# +# +# +# +# +# If used, contact information and eventually details +# of at least the person who performed this analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Details about the coordinate system conventions used. +# +# +# +# The individual coordinate systems which should be used. +# Field names should be prefixed with the following controlled terms +# indicating which individual coordinate system is described: +# +# * paraprobe +# * lab +# * specimen +# * laser +# * leap +# * detector +# * recon +# +# +# +# +# +# +# +# The tool can be used to compute a Voronoi tessellation the entire +# or a sub-set of the reconstruction. The point cloud in the ROI is +# wrapped into a tight axis-aligned bounding box. The tool detects if +# Voronoi cells make contact with the walls of this bounding box. +# The tessellation is computed without periodic boundary conditions. +# +# +# +# A bitmask which identifies which of the ions in the dataset were +# analyzed. +# +# +# +# Number of ions covered by the mask. +# The mask value for most may be 0. +# +# +# +# +# +# Number of bits assumed matching on a default datatype. +# (e.g. 8 bits for a C-style uint8). +# +# +# +# +# The unsigned integer array representing the content of the mask. +# If padding is used the padded bits are set to 0. The mask is for +# convenience always as large as the entire dataset as it will +# be stored compressed anyway. The convenience feature with this +# is that then the mask can be decoded with numpy and mirrored +# against the evaporation_id array and one immediately can filter +# out all points that were used by the paraprobe. +# The length of the array adds to the next unsigned integer +# if the number of ions in the dataset is not an integer +# multiple of the bitdepth. +# +# +# +# +# +# +# +# +# A bitmask which identifies which of points have Voronoi cells that +# are truncated by the global axis-aligned bounding box, i.e. boundaries +# of the threads are ignored. +# +# +# +# Number of points covered by the mask. +# The mask value for most may be 0. +# +# +# +# +# +# Number of bits assumed matching on a default datatype. +# (e.g. 8 bits for a C-style uint8). +# +# +# +# +# The unsigned integer array representing the content of the mask. +# If padding is used the padded bits are set to 0. The mask is for +# convenience always as large as the entire dataset as it will +# be stored compressed anyway. The convenience feature with this +# is that then the mask can be decoded with numpy and mirrored +# against the evaporation_id array and one immediately can filter +# out all points that were used by the paraprobe. +# The length of the array adds to the next unsigned integer +# if the number of ions in the dataset is not an integer +# multiple of the bitdepth. +# +# +# +# +# +# +# +# +# +# A bitmask which identifies which of points have Voronoi cells that +# are truncated by a specific wall of the axis-aligned bounding box. +# The left wall has the negative x axis of the paraprobe coordinate +# system as the outer unit normal. +# +# +# +# Number of points covered by the mask. +# The mask value for most may be 0. +# +# +# +# +# +# Number of bits assumed matching on a default datatype. +# (e.g. 8 bits for a C-style uint8). +# +# +# +# +# The unsigned integer array representing the content of the mask. +# If padding is used the padded bits are set to 0. The mask is for +# convenience always as large as the entire dataset as it will +# be stored compressed anyway. The convenience feature with this +# is that then the mask can be decoded with numpy and mirrored +# against the evaporation_id array and one immediately can filter +# out all points that were used by the paraprobe. +# The length of the array adds to the next unsigned integer +# if the number of ions in the dataset is not an integer +# multiple of the bitdepth. +# +# +# +# +# +# +# +# +# A bitmask which identifies which of points have Voronoi cells that +# are truncated by a specific wall of the axis-aligned bounding box. +# The right wall has the positive x axis of the paraprobe coordinate +# system as the outer unit normal. +# +# +# +# Number of points covered by the mask. +# The mask value for most may be 0. +# +# +# +# +# +# Number of bits assumed matching on a default datatype. +# (e.g. 8 bits for a C-style uint8). +# +# +# +# +# The unsigned integer array representing the content of the mask. +# If padding is used the padded bits are set to 0. The mask is for +# convenience always as large as the entire dataset as it will +# be stored compressed anyway. The convenience feature with this +# is that then the mask can be decoded with numpy and mirrored +# against the evaporation_id array and one immediately can filter +# out all points that were used by the paraprobe. +# The length of the array adds to the next unsigned integer +# if the number of ions in the dataset is not an integer +# multiple of the bitdepth. +# +# +# +# +# +# +# +# +# A bitmask which identifies which of points have Voronoi cells that +# are truncated by a specific wall of the axis-aligned bounding box. +# The front wall has the negative y axis of the paraprobe coordinate +# system as the outer unit normal. +# +# +# +# Number of points covered by the mask. +# The mask value for most may be 0. +# +# +# +# +# +# Number of bits assumed matching on a default datatype. +# (e.g. 8 bits for a C-style uint8). +# +# +# +# +# The unsigned integer array representing the content of the mask. +# If padding is used the padded bits are set to 0. The mask is for +# convenience always as large as the entire dataset as it will +# be stored compressed anyway. The convenience feature with this +# is that then the mask can be decoded with numpy and mirrored +# against the evaporation_id array and one immediately can filter +# out all points that were used by the paraprobe. +# The length of the array adds to the next unsigned integer +# if the number of ions in the dataset is not an integer +# multiple of the bitdepth. +# +# +# +# +# +# +# +# +# A bitmask which identifies which of points have Voronoi cells that +# are truncated by a specific wall of the axis-aligned bounding box. +# The rear wall has the positive y axis of the paraprobe coordinate +# system as the outer unit normal. +# +# +# +# Number of points covered by the mask. +# The mask value for most may be 0. +# +# +# +# +# +# Number of bits assumed matching on a default datatype. +# (e.g. 8 bits for a C-style uint8). +# +# +# +# +# The unsigned integer array representing the content of the mask. +# If padding is used the padded bits are set to 0. The mask is for +# convenience always as large as the entire dataset as it will +# be stored compressed anyway. The convenience feature with this +# is that then the mask can be decoded with numpy and mirrored +# against the evaporation_id array and one immediately can filter +# out all points that were used by the paraprobe. +# The length of the array adds to the next unsigned integer +# if the number of ions in the dataset is not an integer +# multiple of the bitdepth. +# +# +# +# +# +# +# +# +# A bitmask which identifies which of points have Voronoi cells that +# are truncated by a specific wall of the axis-aligned bounding box. +# The left wall has the negative z axis of the paraprobe coordinate +# system as the outer unit normal. +# +# +# +# Number of points covered by the mask. +# The mask value for most may be 0. +# +# +# +# +# +# Number of bits assumed matching on a default datatype. +# (e.g. 8 bits for a C-style uint8). +# +# +# +# +# The unsigned integer array representing the content of the mask. +# If padding is used the padded bits are set to 0. The mask is for +# convenience always as large as the entire dataset as it will +# be stored compressed anyway. The convenience feature with this +# is that then the mask can be decoded with numpy and mirrored +# against the evaporation_id array and one immediately can filter +# out all points that were used by the paraprobe. +# The length of the array adds to the next unsigned integer +# if the number of ions in the dataset is not an integer +# multiple of the bitdepth. +# +# +# +# +# +# +# +# +# A bitmask which identifies which of points have Voronoi cells that +# are truncated by a specific wall of the axis-aligned bounding box. +# The left wall has the positive z axis of the paraprobe coordinate +# system as the outer unit normal. +# +# +# +# Number of points covered by the mask. +# The mask value for most may be 0. +# +# +# +# +# +# Number of bits assumed matching on a default datatype. +# (e.g. 8 bits for a C-style uint8). +# +# +# +# +# The unsigned integer array representing the content of the mask. +# If padding is used the padded bits are set to 0. The mask is for +# convenience always as large as the entire dataset as it will +# be stored compressed anyway. The convenience feature with this +# is that then the mask can be decoded with numpy and mirrored +# against the evaporation_id array and one immediately can filter +# out all points that were used by the paraprobe. +# The length of the array adds to the next unsigned integer +# if the number of ions in the dataset is not an integer +# multiple of the bitdepth. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Interior volume +# +# +# +# +# +# +# +# By which MPI process was the Voronoi cell computed. +# +# +# +# +# +# +# +# By which OpenMP thread was the Voronoi cell computed. +# +# +# +# +# +# +# +# The number of faces for each polyhedron. Faces of adjoining polyhedra +# are counted for each polyhedron. This field can be used to interpret +# the array/field with the individual area values for each face. +# +# +# +# +# +# +# +# +# Integer which specifies the first index to be used for distinguishing +# polyhedra. Identifiers are defined either implicitly +# or explicitly. For implicit indexing the identifiers are defined on the +# interval [identifier_offset, identifier_offset+c-1]. +# For explicit indexing the identifier array has to be defined. +# +# +# +# +# Integer used to distinguish polyhedra for explicit indexing. +# +# +# +# +# +# +# +# A simple approach to describe the entire set of polyhedra when +# the main intention is to store the shape of the polyhedra for +# visualization. +# +# +# +# +# Number of vertices. +# +# +# +# +# Number of faces. +# +# +# +# +# +# +# +# +# +# +# +# +# A sequence of always first an XDMF topology type key, followed +# by the XDMF number of vertices of the polygon, followed by +# the vertex identifier which define the facet polygon. First +# we store the polygon of the first facet of the first cell, then +# the second facet of the first cell, until the last facet of the +# first cell, followed by the first facet of the second cell, +# and so on and so forth. +# +# +# +# +# +# +# +# A sequence of cell identifier so that each facet is associated +# with its cell because of which it is then possible to segment +# out cells three-dimensionally based on cell i.e. evaporation_id. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Specify if it was different from the number_of_processes +# in the NXcs_profiling super class. +# +# +# +# +# +# Specify if it was different from the number_of_threads +# in the NXcs_profiling super class. +# +# +# +# +# +# Specify if it was different from the number_of_threads +# in the NXcs_profiling super class. +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.yaml new file mode 100644 index 0000000000..00b4211f2a --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.yaml @@ -0,0 +1,1080 @@ +category: application +doc: | + Results of a paraprobe-transcoder tool run. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_ions: | + The total number of ions in the reconstruction. + 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 mapped on this ion type. + n_topology: | + Total number of integers in the supplementary XDMF topology array. + n_combinatorics: | + Number of ions probed in the combinatorial analysis of the charge states + +# be careful n_comb can vary for every instance of (NXion) ! +type: group +NXapm_paraprobe_results_transcoder(NXobject): + + # by default for appdefs the value of the exists keyword is required + # unless it is explicitly specified differently + (NXentry): + exists: ['min', '1', 'max', '1'] + \@version: + doc: | + Version specifier of this application definition. + + ##MK::begin of the tool-specific section + definition: + doc: | + Official NeXus NXDL schema with which this file was written. + enumeration: [NXapm_paraprobe_results_transcoder] + + ##MK::end of the tool-specific section + program: + doc: | + Given name of the program/software/tool with which this NeXus + (configuration) file was generated. + \@version: + doc: | + Ideally program version plus build number, or commit hash or description + of ever persistent resources where the source code of the program and + build instructions can be found so that the program can be configured + ideally in such a manner that the result of this computational process + is recreatable in the same deterministic manner. + analysis_identifier: + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: | + Possibility for leaving a free-text description about this analysis. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. the paraprobe-tool executable started as a process. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the paraprobe-tool executable exited as a process. + config_filename: + doc: | + The absolute path and name of the config file for this analysis. + \@version: + doc: | + At least SHA256 strong hash of the specific config_file for + tracking provenance. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + status: + doc: | + A statement whether the paraprobe-tool executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + enumeration: [success, failure] + (NXuser): + exists: recommended + doc: | + If used, contact information and eventually details + of at least the person who performed this analysis. + name: + affiliation: + exists: recommended + address: + exists: optional + email: + exists: recommended + orcid: + exists: recommended + orcid_platform: + exists: recommended + telephone_number: + exists: optional + role: + exists: recommended + social_media_name: + exists: optional + social_media_platform: + exists: optional + (NXcoordinate_system_set): + doc: | + Details about the coordinate system conventions used. + (NXtransformations): + exists: ['min', '1', 'max', 'unbounded'] + doc: | + The individual coordinate systems which should be used. + Field names should be prefixed with the following controlled terms + indicating which individual coordinate system is described: + + * paraprobe + * lab + * specimen + * laser + * leap + * detector + * recon + + ##MK::begin of the tool-specific section + visualization(NXprocess): + exists: recommended + xdmf_topology(NX_UINT): + unit: NX_UNITLESS + doc: | + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstruction. The XDMF datatype + is here 1, the number of primitives 1 per triplet, the last integer + in each triplet is the identifier of each point starting from zero. + dimensions: + rank: 1 + dim: [[1, n_topology]] + + # n_topology == 3*n_ions + # not in all cases a PARAPROBE.Transcoder.Results.SimID..h5 is required + # namely when an NXapm-compliant NeXus file is directly used for interacting + # with paraprobe tools in all other cases, the PARAPROBE.Transcoder.Results + # file will get an *.nxs file ending + # the original proposal + # results(NXprocess): + # exists: [min, 1, max, 1] + # doc: | + # Paraprobe-transcoder prepares the data in POS, ePOS, APT files from + # APSuite, RRNG, RNG, and NeXus/HDF5 NXapm in such a way that they can + # be used with the tools of the paraprobe-toolbox. + # reconstruction(NXcg_point_set): + # dimensionality(NX_POSINT): + # cardinality(NX_POSINT): + # identifier_offset(NX_INT): + # position(NX_NUMBER): + # ##MK::number_of_ion_types(NX_POSINT): + # ##MK::maximum_number_of_atoms_per_molecular_ion(NX_POSINT): + # ranging(NXcollection): + # exists: [min, 1, max, 256] + # doc: | + # This is the collection of iontypes distinguished. + # The default unknown iontype always has to map to 0. + # Its non-physical mass_to_charge_state_ratio is [0., 0.001] Da. + # ion_type(NX_UINT): + # exists: optional + # isotope_vector(NX_UINT): + # nuclid_list(NX_UINT): + # exists: recommended + # charge_state(NX_INT): + # name: + # exists: optional + # mass_to_charge_range(NX_FLOAT): + # the key problem still for apm is people use different formats + # when people would like to use paraprobe without nomad and pos, epos, apt + # rrng and rng files the data have to be transcoded, this is the main + # reason for having the transcoder however, when you already have an NXapm + # file (like) in nomad, why should we create yet another format here the + # transcoder is not needed + # namely take e.g. paraprobe-nanochem all it needs to know is the place of + # an HDF5 file where the nanochem tool knows there will be groups in this file + # with entry/atom_probe/reconstruction/reconstructed_positions + # and entry/atom_probe/ranging/peak_identification and a set of NXion + # this suggest the need for three fundamental changes: + # if transcoder config gets an nxs file as input it just checks if + # the above-mentioned groups are available, if yes it accepts and + # guides that no transcoding is needed any longer + # if transcoder config gets other files it creates the above-mentioned + # groups in different places than it does currently + # convenience functions of tools have to be changed in the following way: + # you hunt for PARAPROBE.Transcoder.Config.SimID..h5 + # if the references to dataset files there end with nxs you know + # data are in an NXapm so reconstruction will be in + # entry/atom_probe/reconstruction/reconstructed_positions + # ranging will be in + # entry/atom_probe/ranging/peak_identification + # however if the references to dataset files there end with != nxs + # you point the tool to in fact data inside PARAPROBE.Transcoder.Results + # because in this case transcoding was necessary but also then you + # will find the data in entry/atom_probe/.. respectively + # alternatively: + atom_probe(NXinstrument): + doc: | + On a mid term perspective we would like to evolve the paraprobe-toolbox + to an implementation stage where it works exclusively with completely + provenance-tracked formats for both the configuration of the workflow step + and/or analysis with each tool and also for the output of these analyses + in the form of so-called tool-specific results files. + Currently the Hierarchical Data Format 5 (HDF5) is used to store such data. + + Different file formats can be used to inject reconstructed datasets and + ranging definitions into the toolbox. Traditionally, these are the POS, + ePOS, and APT files with the tomographic reconstruction and other metadata + and RNG and RRNG file formats for the ranging definitions how mass-to-charge + state-ratio values map on (molecular) ion types. Such input should be + injected via specific NeXus/HDF5 files which are documented + in compliance with the NXapm application definition. + + So far the paraprobe-toolbox was used as a standalone tool. Therefore, it + was not relevant during the development to focus on interoperability. + Essentially paraprobe-transcoder was used as a parser to transcode data + in the above-mentioned file formats into a paraprobe-specific + representation. This transcoding should become deprecated. + Here we describe steps we have taken into this direction. + + With the work in the FAIRmat project and the desire to make the paraprobe- + toolbox also accessible as a cloud-computing capable service in the Nomad + Remote Tools Hub (NORTH) the topic of interoperability became more important + and eventually the NXapm application definition was proposed. + NORTH is a GUI and related service in a NOMAD OASIS instance which allows + to spawn preconfigured docker containers via JupyterHub. + Currently, NORTH includes the so-called apm container. A container with + tools specific for analyzing data from atom probe microscopy as well as + processing of point cloud and mesh data. + + The NXapm application definition and related implementation work within + NOMAD OASIS enabled users to parse content of POS, ePOS, APT, RNG, and + RRNG files, surplus key metadata from vendor-agnostic electronic lab notebook + solutions directly into NOMAD OASIS via the uploads section. + The process is automated and yields an NXapm-compliant NeXus/HDF5 file + inside the uploads section in return. + + With these improvements made there is no longer a need for - at least the + users of a NOMAD OASIS and NORTH instance to use the deprecated + PARAPROBE.Transcoder.Results.*.h5 files. Ideally, paraprobe should + automatically detect that the input can now be an NXapm-compliant NeXus/HDF5 + file and in response work with this file directly. + To remain compliant with users however who do not have or do not wish + to use a NOMAD OASIS or NXapm or NeXus at all right now, the solution is + as follows: + + Calling the configuration stage of paraprobe-transcoder is always mandatory. + It is always the first step of working with the toolbox. In this process + the user defines the input files. These can either be nxs i.e. the NXapm/NeXus/ + HDF5 file from e.g. the upload section, or such a file that was obtained from + a colleague with a NOMAD OASIS instance. + In all other cases, users can pass the reconstruction and ranging definitions + using the traditional POS, ePOS, or APT and RNG or RRNG file formats respectively. + + Based on which input the user delivers, the parmsetup-transcoder tool then + creates a configuration file PARAPROBE.Transcoder.Config.SimID.*.nxs and + informs the user whether the input was NeXus (and thus if all relevant + input is already available) or whether the paraprobe-transcoder tool needs + to be executed to convert the content of the vendor files first into a + format which paraprobe can provenance track and understand. + In the latter case, the PARAPROBE.Transcoder.Config.SimID.*.nxs file is + used to communicate to all subsequently used tools from which files + the tools can expect to find the reconstruction and ranging definitions. + + All subsequent analysis steps start also with a tool-specific configuration. + This configuration step reads in (among others) the + PARAPROBE.Transcoder.Config.SimID.*.nxs file from which the configuration + tool identifies automatically whether to read the reconstruction and ranging data + from PARAPROBE.Transcoder.Results.SimID.*.h5 or directly the NXapm-compliant + NeXus/HDF5 file that was created upon preparing the upload or the file shared + from a colleague. This design removes the need for unnecessary copies of the data. + Currently still though users should execute the transcoder step as it will + generate a supplementary XDMF topology field with which the data in either + the NeXus/HDF5 or the transcoded vendor files can be displayed using e.g. + Paraview. For this purpose XDMF is used. + + Of course ideally the APT community would at some point converge to use + a common data exchange file format. To this end, AMETEK/Cameca's APT file format + could be a good starting point but so far it is lacking a consistent way of + how to store generalized ranging definitions and post-processing results. + POS, ePOS, Rouen's ATO, as well as other so far used representations of data + like CSV or text files have, to the best of our current knowledge, no + concept of how to marry reconstruction and (optional) ranging data into + one self-descriptive format. + + This summarizes the rationale behind the current choices of the I/O for + paraprobe. Furthermore, this summarizes also why the fundamental design + of splitting an analysis always into steps of configuration (with parmsetup), + task execution (with the respective C/C++ or Python tool of the toolbox), + and post-processing (e.g. with autoreporter) is useful because it offers + a clear description of provenance tracking. This is a necessary step to make + atom probe microscopy data at all better aligned with the aims of the + FAIR principles. + + The internal organization of the data entries in the atom_probe group + in this application definition for paraprobe-transcoder results files + mirror the definitions of the NXapm for consistency reasons. + + # APSuite, RRNG, RNG, and NeXus/HDF5 NXapm in such a way that they can + # be used with the tools of the paraprobe-toolbox. + mass_to_charge_conversion(NXprocess): + mass_to_charge(NX_FLOAT): + unit: NX_ANY + doc: | + Mass-to-charge-state ratio values. + + # \@units: Da + dimensions: + rank: 1 + dim: [[1, n_ions]] + reconstruction(NXprocess): + + # number_of_ions(NX_UINT): + # doc: | + # For now still a support field to store the total number of ions in the + # dataset. This field will become deprecated when the new HDF5 I/O routines + # come in place which detect the metadata to an entry automatically. + # For now has to be the same value as n_ions. + reconstructed_positions(NX_FLOAT): + unit: NX_LENGTH + doc: | + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + dimensions: + rank: 2 + dim: [[1, n_ions], [2, 3]] + ranging(NXprocess): + peak_identification(NXprocess): + doc: | + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + (NXion): + exists: ['min', '1', 'max', '256'] + isotope_vector(NX_UINT): + nuclid_list(NX_UINT): + exists: recommended + charge_state(NX_INT): + mass_to_charge_range(NX_FLOAT): + charge_model(NXprocess): + doc: | + Details and results of the combinatorial analyses of this + range definition to identify the charge_state for an ion. + charge_vector(NX_UINT): + unit: NX_UNITLESS + doc: | + Currently charge_state not charge! + dimensions: + rank: 1 + dim: [[1, n_combinatorics]] + isotope_matrix(NX_UINT): + unit: NX_UNITLESS + doc: | + Specific isotopes building each candidate matching the range. + dimensions: + rank: 2 + dim: [[1, n_combinatorics], [2, n_ivec_max]] + mass_vector(NX_FLOAT): + unit: NX_ANY + doc: | + Accumulated mass of the isotopes in each candidate. + Not corrected for quantum effects. + dimensions: + rank: 1 + dim: [[1, n_combinatorics]] + + # min_abundance(NX_FLOAT): + # doc: | + # Minimum natural abundance + # unit: NX_DIMENSIONLESS + natural_abundance_product_vector(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + Product of natural abundance of the isotopes per candidate. + dimensions: + rank: 1 + dim: [[1, n_combinatorics]] + min_abundance_product(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + Filter criterion on the product of the natural abundances + computed from each isotope building the (molecular) ion. + Such a filter can be used to reduce the number of possible + molecular ions considered when trying to find a unique solution + to the question which charge_state does a molecular ion + within a given range and given combination of elements have. + min_half_life(NX_FLOAT): + unit: NX_TIME + doc: | + Filter criterion on the minimum half life which all isotopes + building the (molecular) ion need to have to consider the + candidate. + Such a filter can be used to reduce the number of possible + molecular ions considered when trying to find a unique solution + to the question which charge_state does a molecular ion + within a given range and given combination of elements have. + + # NEW ISSUE: value can be the string infinity! + # min_half_life_vector(NX_FLOAT): + # doc: | + # Needs to be documented + # unit: NX_TIME + sacrifice_isotopic_uniqueness(NX_BOOLEAN): + doc: | + If the value is zero/false it means that non-unique solutions + are accepted. These are solutions where multiple candidates + differ in their isotopes but have the same charge. + + # add further fields coming from using the charge state recovery + # workflow from the ifes_apt_tc_data_modeling library + ##MK::end of the tool-specific section + performance(NXcs_profiling): + current_working_directory: + command_line_call: + exists: optional + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + total_elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): + (NXcs_computer): + exists: recommended + name: + exists: recommended + operating_system: + \@version: + uuid: + exists: optional + (NXcs_cpu): + exists: ['min', '0', 'max', 'unbounded'] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_gpu): + exists: ['min', '0', 'max', 'unbounded'] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_mm_sys): + exists: ['min', '0', 'max', '1'] + total_physical_memory(NX_NUMBER): + (NXcs_io_sys): + exists: ['min', '0', 'max', '1'] + (NXcs_io_obj): + exists: ['min', '1', 'max', 'unbounded'] + technology: + max_physical_capacity(NX_NUMBER): + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_profiling_event): + start_time(NX_DATE_TIME): + exists: optional + end_time(NX_DATE_TIME): + exists: optional + description: + elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + number_of_threads(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + number_of_gpus(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + max_virtual_memory_snapshot(NX_NUMBER): + exists: recommended + max_resident_memory_snapshot(NX_NUMBER): + exists: recommended + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# dc03e6cf382ef885356e95ad6889162c3ded9664dea8344499decc097be77690 +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The total number of ions in the reconstruction. +# +# +# +# +# Maximum number of allowed atoms per (molecular) ion (fragment). +# Needs to match maximum_number_of_atoms_per_molecular_ion. +# +# +# +# +# Number of mass-to-charge-state-ratio intervals mapped on this ion type. +# +# +# +# +# Total number of integers in the supplementary XDMF topology array. +# +# +# +# +# Number of ions probed in the combinatorial analysis of the charge states +# +# +# +# +# Results of a paraprobe-transcoder tool run. +# +# +# +# +# +# Version specifier of this application definition. +# +# +# +# +# +# Official NeXus NXDL schema with which this file was written. +# +# +# +# +# +# +# +# +# Given name of the program/software/tool with which this NeXus +# (configuration) file was generated. +# +# +# +# Ideally program version plus build number, or commit hash or description +# of ever persistent resources where the source code of the program and +# build instructions can be found so that the program can be configured +# ideally in such a manner that the result of this computational process +# is recreatable in the same deterministic manner. +# +# +# +# +# +# Ideally, a (globally persistent) unique identifier for referring +# to this analysis. +# +# +# +# +# Possibility for leaving a free-text description about this analysis. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when the analysis behind this results file +# was started, i.e. the paraprobe-tool executable started as a process. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when the analysis behind this results file +# were completed and the paraprobe-tool executable exited as a process. +# +# +# +# +# The absolute path and name of the config file for this analysis. +# +# +# +# At least SHA256 strong hash of the specific config_file for +# tracking provenance. +# +# +# +# +# +# Path to the directory where the tool should store NeXus/HDF5 results +# of this analysis. If not specified results will be stored in the +# current working directory. +# +# +# +# +# A statement whether the paraprobe-tool executable managed to +# process the analysis or failed prematurely. +# +# This status is written to the results file after the end_time +# at which point the executable must not compute any analysis. +# Only when this status message is present and shows `success`, the +# user should consider the results. In all other cases it might be +# that the executable has terminated prematurely or another error +# occurred. +# +# +# +# +# +# +# +# +# If used, contact information and eventually details +# of at least the person who performed this analysis. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Details about the coordinate system conventions used. +# +# +# +# The individual coordinate systems which should be used. +# Field names should be prefixed with the following controlled terms +# indicating which individual coordinate system is described: +# +# * paraprobe +# * lab +# * specimen +# * laser +# * leap +# * detector +# * recon +# +# +# +# +# +# +# +# An array of triplets of integers which can serve as a supplementary +# array for Paraview to display the reconstruction. The XDMF datatype +# is here 1, the number of primitives 1 per triplet, the last integer +# in each triplet is the identifier of each point starting from zero. +# +# +# +# +# +# +# +# +# +# On a mid term perspective we would like to evolve the paraprobe-toolbox +# to an implementation stage where it works exclusively with completely +# provenance-tracked formats for both the configuration of the workflow step +# and/or analysis with each tool and also for the output of these analyses +# in the form of so-called tool-specific results files. +# Currently the Hierarchical Data Format 5 (HDF5) is used to store such data. +# +# Different file formats can be used to inject reconstructed datasets and +# ranging definitions into the toolbox. Traditionally, these are the POS, +# ePOS, and APT files with the tomographic reconstruction and other metadata +# and RNG and RRNG file formats for the ranging definitions how mass-to-charge +# state-ratio values map on (molecular) ion types. Such input should be +# injected via specific NeXus/HDF5 files which are documented +# in compliance with the NXapm application definition. +# +# So far the paraprobe-toolbox was used as a standalone tool. Therefore, it +# was not relevant during the development to focus on interoperability. +# Essentially paraprobe-transcoder was used as a parser to transcode data +# in the above-mentioned file formats into a paraprobe-specific +# representation. This transcoding should become deprecated. +# Here we describe steps we have taken into this direction. +# +# With the work in the FAIRmat project and the desire to make the paraprobe- +# toolbox also accessible as a cloud-computing capable service in the Nomad +# Remote Tools Hub (NORTH) the topic of interoperability became more important +# and eventually the NXapm application definition was proposed. +# NORTH is a GUI and related service in a NOMAD OASIS instance which allows +# to spawn preconfigured docker containers via JupyterHub. +# Currently, NORTH includes the so-called apm container. A container with +# tools specific for analyzing data from atom probe microscopy as well as +# processing of point cloud and mesh data. +# +# The NXapm application definition and related implementation work within +# NOMAD OASIS enabled users to parse content of POS, ePOS, APT, RNG, and +# RRNG files, surplus key metadata from vendor-agnostic electronic lab notebook +# solutions directly into NOMAD OASIS via the uploads section. +# The process is automated and yields an NXapm-compliant NeXus/HDF5 file +# inside the uploads section in return. +# +# With these improvements made there is no longer a need for - at least the +# users of a NOMAD OASIS and NORTH instance to use the deprecated +# PARAPROBE.Transcoder.Results.*.h5 files. Ideally, paraprobe should +# automatically detect that the input can now be an NXapm-compliant NeXus/HDF5 +# file and in response work with this file directly. +# To remain compliant with users however who do not have or do not wish +# to use a NOMAD OASIS or NXapm or NeXus at all right now, the solution is +# as follows: +# +# Calling the configuration stage of paraprobe-transcoder is always mandatory. +# It is always the first step of working with the toolbox. In this process +# the user defines the input files. These can either be nxs i.e. the NXapm/NeXus/ +# HDF5 file from e.g. the upload section, or such a file that was obtained from +# a colleague with a NOMAD OASIS instance. +# In all other cases, users can pass the reconstruction and ranging definitions +# using the traditional POS, ePOS, or APT and RNG or RRNG file formats respectively. +# +# Based on which input the user delivers, the parmsetup-transcoder tool then +# creates a configuration file PARAPROBE.Transcoder.Config.SimID.*.nxs and +# informs the user whether the input was NeXus (and thus if all relevant +# input is already available) or whether the paraprobe-transcoder tool needs +# to be executed to convert the content of the vendor files first into a +# format which paraprobe can provenance track and understand. +# In the latter case, the PARAPROBE.Transcoder.Config.SimID.*.nxs file is +# used to communicate to all subsequently used tools from which files +# the tools can expect to find the reconstruction and ranging definitions. +# +# All subsequent analysis steps start also with a tool-specific configuration. +# This configuration step reads in (among others) the +# PARAPROBE.Transcoder.Config.SimID.*.nxs file from which the configuration +# tool identifies automatically whether to read the reconstruction and ranging data +# from PARAPROBE.Transcoder.Results.SimID.*.h5 or directly the NXapm-compliant +# NeXus/HDF5 file that was created upon preparing the upload or the file shared +# from a colleague. This design removes the need for unnecessary copies of the data. +# Currently still though users should execute the transcoder step as it will +# generate a supplementary XDMF topology field with which the data in either +# the NeXus/HDF5 or the transcoded vendor files can be displayed using e.g. +# Paraview. For this purpose XDMF is used. +# +# Of course ideally the APT community would at some point converge to use +# a common data exchange file format. To this end, AMETEK/Cameca's APT file format +# could be a good starting point but so far it is lacking a consistent way of +# how to store generalized ranging definitions and post-processing results. +# POS, ePOS, Rouen's ATO, as well as other so far used representations of data +# like CSV or text files have, to the best of our current knowledge, no +# concept of how to marry reconstruction and (optional) ranging data into +# one self-descriptive format. +# +# This summarizes the rationale behind the current choices of the I/O for +# paraprobe. Furthermore, this summarizes also why the fundamental design +# of splitting an analysis always into steps of configuration (with parmsetup), +# task execution (with the respective C/C++ or Python tool of the toolbox), +# and post-processing (e.g. with autoreporter) is useful because it offers +# a clear description of provenance tracking. This is a necessary step to make +# atom probe microscopy data at all better aligned with the aims of the +# FAIR principles. +# +# The internal organization of the data entries in the atom_probe group +# in this application definition for paraprobe-transcoder results files +# mirror the definitions of the NXapm for consistency reasons. +# +# +# +# +# +# Mass-to-charge-state ratio values. +# +# +# +# +# +# +# +# +# +# +# +# Three-dimensional reconstructed positions of the ions. +# Interleaved array of x, y, z positions in the specimen space. +# +# +# +# +# +# +# +# +# +# +# Details about how peaks, with taking into account +# error models, were interpreted as ion types or not. +# +# +# +# +# +# +# +# +# Details and results of the combinatorial analyses of this +# range definition to identify the charge_state for an ion. +# +# +# +# Currently charge_state not charge! +# +# +# +# +# +# +# +# Specific isotopes building each candidate matching the range. +# +# +# +# +# +# +# +# +# Accumulated mass of the isotopes in each candidate. +# Not corrected for quantum effects. +# +# +# +# +# +# +# +# +# Product of natural abundance of the isotopes per candidate. +# +# +# +# +# +# +# +# Filter criterion on the product of the natural abundances +# computed from each isotope building the (molecular) ion. +# Such a filter can be used to reduce the number of possible +# molecular ions considered when trying to find a unique solution +# to the question which charge_state does a molecular ion +# within a given range and given combination of elements have. +# +# +# +# +# Filter criterion on the minimum half life which all isotopes +# building the (molecular) ion need to have to consider the +# candidate. +# Such a filter can be used to reduce the number of possible +# molecular ions considered when trying to find a unique solution +# to the question which charge_state does a molecular ion +# within a given range and given combination of elements have. +# +# +# +# +# +# If the value is zero/false it means that non-unique solutions +# are accepted. These are solutions where multiple candidates +# differ in their isotopes but have the same charge. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Specify if it was different from the number_of_processes +# in the NXcs_profiling super class. +# +# +# +# +# +# Specify if it was different from the number_of_threads +# in the NXcs_profiling super class. +# +# +# +# +# +# Specify if it was different from the number_of_threads +# in the NXcs_profiling super class. +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXbeam_path.yaml b/contributed_definitions/nyaml/NXbeam_path.yaml new file mode 100644 index 0000000000..f7651dee2a --- /dev/null +++ b/contributed_definitions/nyaml/NXbeam_path.yaml @@ -0,0 +1,780 @@ +category: base +doc: | + A beam path consisting of one or more optical elements. + + NXbeam_path is used in NXopt to describe the beam path, i.e. the arrangement + of optical elements between the excitation source and the sample, or between + the sample and the detector unit. + + To describe the order of the elements, use 'order(NXtransformations)', where + each element's position points to the preceding element via '@depends_on'. + Special case beam splitter: A beam splitter is a device which separates the + beam into two or more beams. If such a device is part of the beam path use + two or more NXbeam_paths to describe the beam paths after the beam splitter. + In this case, in the dependency chain of the new beam paths, the first + elements each point to the beam splitter, as this is the previous element. + + Describe the relevant optical elements in the beam path by using the + appropriate base classes. You may use as many elements as needed, also + several elements of the same type as long as each element has its own name. + +# 05/2023 +# A draft of a new base class to describe a beam path consisting of one or +# more optical elements (e.g. a beam path in a luminescence setup). + +# To do: +# [ ] Harmonize common fields/classes among base classes used in NXbeam_path, +# e.g. NXshape in NXbeam_splitter and NXpolarizer_opt, or NXsample used for +# describing substrates and coatings etc. +# [ ] How to describe a setup or beam path? Order/sequence defined by +# NXtransformations? => discussion needed +type: group +NXbeam_path(NXobject): + depends_on: + doc: | + Entry point of the dependency chain defined by the NXtransformations + field, i.e. a link to the last element in the beam path. + Example: /entry/instrument/beam_path/detector. + (NXtransformations): + + # Possibilities: + # (1) Modify NXtransformations to include properties that modify the light beam + # (e.g. polarization state) instead (or in addition) to transformations like + # translation and rotation + # (2) Base class similar to NXtransformations but for changes of optical + # properties (e.g. polarization state). + doc: | + Specify the order of the optical elements by defining a dependency chain. + For each element, a '@depends_on' attribute should be used to state the + position of the element in the beam path by pointing to the previous + element. For the very first element, use the string "." instead. + AXISNAME(NX_NUMBER): + unit: NX_TRANSFORMATION + doc: | + For each element in the beam path, one such field must exist with a + '@depends_on' attribute defined to specify its position in the beam + path. Note that also 'NXopt/ENTRY/INSTRUMENT/sample_stage' and windows + ('NXopt/ENTRY/INSTRUMENT/sample_stage/entry_window' and + 'NXopt/ENTRY/INSTRUMENT/sample_stage/exit_window') may be added to the + dependency chain, i.e. may have an entry in this class even if they are + not described in the beam path. + ELEMENT is a place holder for the name of an optical beam path element. + Note that the name of this field must be exactly the same as the + element's field name. + \@depends_on: + doc: | + Add a link to the previous beam path element. + (NXsource): + doc: | + Excitation source. One or more may be needed (e.g. two for a pump-probe + setup with one pump and one probe beam). + Depending on the source type, different properties are relevant, which + are provided through the respective base class (e.g. use NXopt_source for + lamps or lasers, NXchem_source for chemical reaction etc.). + Some base classes are incomplete (NXchem_source, NXbio_source); the + expertise of the respective communities is needed. + depends_on: + doc: | + Use this field to point to the previous optical element. + type: + doc: | + Type of excitation source. + enumeration: [semiconductor laser, gas laser, other laser, lamp, X-rays, silicon carbide globar, super continuum, chemical reaction, ultrasound, sound, living organism, power supply, electron source, other] + + # Spallation Neutron Source + # Pulsed Reactor Neutron Source + # Reactor Neutron Source + # Synchrotron X-ray Source + # Pulsed Muon Source + # Rotating Anode X-ray + # Fixed Tube X-ray + # UV Laser + # Free-Electron Laser + # Optical Laser + # Ion Source + # UV Plasma Source + # Metal Jet X-ray + + # separate base classes for different sources: + # (NXacoustic_source): # needs to be developed + # doc: | + # Acoustic source, e.g. an ultrasonic transducero or a imploding gas + # bubble (sonoluminescence). + # (NXpower_supply): # needs to be developed + # (NXchem_source): # input for experts from that field needed + # (NXbio_source): # input for experts from that field needed + # is NXsource sufficient for x-rays? + # (NXopt_source): + # doc: Specify the properties of the optical source. + lifespan(NX_NUMBER): + unit: NX_TIME + doc: | + Lifespan of the excitation (typically provided in hours). + measure_time(NX_NUMBER): + unit: NX_TIME + doc: | + How many hours has the lamp been used? + excitation_wavelength(NX_FLOAT): + unit: NX_ANY + doc: | + Wavelengths or energy vector of the excitation source. This can be a + single value or a spectrum, depending on the type of experiment. + \@units: + doc: | + Unit of wavelength or energy. + beam_profile: + + # ??? What's the best way to enter this ??? + doc: | + Two- or three-dimensional beam profile. + dimensions: + rank: 2 + dim: [[1, N_beam_profile_dim], [2, N_beam_profile_points]] + peak_power(NX_FLOAT): + unit: NX_POWER + doc: | + Power of one light pulse if the source is a pulsed source. + cw(NX_BOOLEAN): + doc: | + Is the excitation source continuous wave (CW)? + cw_power(NX_FLOAT): + doc: | + Power of CW beam. + bandwidth(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + FWHM bandwidth of the excitation source. + coherence_length(NX_FLOAT): + unit: NX_LENGTH + doc: | + Coherence length. + divergence(NX_FLOAT): + unit: NX_ANGLE + doc: | + Divergence of the excitation beam. + (NXpinhole): + doc: | + Use this field to describe a simple pinhole (round geometry). Define its + dimension using 'diameter'. For more complex geometries, 'NXaperture' + should be used. + (NXslit): + doc: | + Use this field to describe a simple slit (rectangular geometry). Define + its dimensions using 'x_gap' and 'y_gap'. For more complex geometries, + 'NXaperture' should be used. + aperture_NUMBER(NXaperture): + doc: | + Use this field to describe an aperture. To specify a window, use the + field 'window_NUMBER(NXaperture)'. + window_NUMBER(NXaperture): + doc: | + A window, e.g. an entry or exit window of a cryostat. + depends_on: + doc: | + Use this field to point to the previous optical element. + material(NX_CHAR): + doc: | + The material of the window. + enumeration: [quartz, diamond, calcium fluoride, zinc selenide, thallium bromoiodide, alkali halide compound, Mylar, other] + other_material(NX_CHAR): + doc: | + If you specified 'other' as material, decsribe here what it is. + thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + Thickness of the window + orientation_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Angle of the window normal (outer) vs. the substrate normal + (similar to the angle of incidence). + reference_data_link: + doc: | + If reference data were measured add a link to the NeXus file where they + are described. + (NXmirror): + filter_NUMBER(NXfilter): + (NXattenuator): + doc: | + A device that reduces the intensity of a beam by attenuation. + attenuator_transmission(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + The transmitted intensity divided by the incident intensity. + attenuation(NX_FLOAT): + unit: NX_ANY + doc: | + Attenuation of the attenuator in dB. + \@units: + doc: | + Unit of the measured data is not covered by NXDL units state + here which unit was used. + (NXaperture): + doc: | + Input and output aperture of the attenuator. + (NXgeometry): + doc: | + Geometry (shape, size etc.) of the attenuator. + (NXgrating): + doc: | + A diffraction grating. Define relevant parameters in the corresponding + fields, e.g. order of diffration (diffraction_order) or angular + dispersion (angular_dispersion). + type: + doc: | + Define the type of the grating. + angular_dispersion(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Dispersion of the grating in nm/mm (or e.g. nm/mrad). + grooves(NX_FLOAT): + unit: NX_PER_LENGTH + doc: | + Number of grooves per mm. + blaze_wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + Blaze wavelength of the grating. + efficiency(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Efficiency curve versus wavelength or energy. + dimensions: + rank: 1 + dim: [[1, N_spectrum]] + spectrum(NX_FLOAT): + unit: NX_ANY + doc: | + Spectral values, e.g. wavelength or energy. Vector of length + N_spectrum. + \@units: + doc: | + Unit of wavelength array (e.g. nanometer or Angstrom) + (NXdisk_chopper): + doc: | + A device blocking the beam in a temporal periodic pattern, e.g. a optical + chopper wheel. Specify the frequency range using 'min_frequency' and + 'max_frequency'. + min_frequency(NX_FLOAT): + unit: NX_FREQUENCY + doc: | + Minimum frequency in Hertz. + max_frequency(NX_FLOAT): + unit: NX_FREQUENCY + doc: | + Maximum frequency in Hertz. + frequency_resolution(NX_FLOAT): + unit: NX_FREQUENCY + doc: | + Frequency resolution in Hertz. + (NXmonochromator): + doc: | + A monochromator or spectrometer. + spectrum(NX_FLOAT): + unit: NX_ANY + doc: | + Spectral values of the monochromator, e.g. wavelength or energy values + used for the measurement. + \@units: + doc: | + Unit of wavelength array (e.g. nanometer or Angstrom) + (NXgrating): + doc: | + Diffraction grating. If two or more gratings were used, define the + angular dispersion and the wavelength range (min/max wavelength) for + each grating and make sure that the wavelength ranges do not overlap. + The dispersion should be defined for the entire wavelength range of the + experiment. + angular_dispersion(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + Dispersion of the grating in nm/mm. + grating_wavelength_min(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + Minimum wavelength of the grating. + grating_wavelength_max(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + Maximum wavelength of the grating. + spectral_resolution(NX_FLOAT): + unit: NX_WAVENUMBER + doc: | + Spectral resolution of the instrument. + (NXslit): + doc: | + Define the width of the monochromator slit in the subfield x_gap. + fixed_slit(NX_BOOLEAN): + doc: | + Was the slit width fixed? + max_gap(NX_FLOAT): + unit: NX_LENGTH + doc: | + If slit width was not fixed, define the maximum slit width. + + # x-ray optics: + (NXxraylens): + + # what else? + + # ====== New base classes: ====== + (NXpolarizer_opt): + (NXbeam_splitter): + (NXwaveplate): + (NXlens_opt): + (NXfiber): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# f0ed01c487c4175dc723d226e0d33b89fa8107576fe95b4f0b825c1f91244ccc +# +# +# +# +# +# +# +# A beam path consisting of one or more optical elements. +# +# NXbeam_path is used in NXopt to describe the beam path, i.e. the arrangement +# of optical elements between the excitation source and the sample, or between +# the sample and the detector unit. +# +# To describe the order of the elements, use 'order(NXtransformations)', where +# each element's position points to the preceding element via '@depends_on'. +# Special case beam splitter: A beam splitter is a device which separates the +# beam into two or more beams. If such a device is part of the beam path use +# two or more NXbeam_paths to describe the beam paths after the beam splitter. +# In this case, in the dependency chain of the new beam paths, the first +# elements each point to the beam splitter, as this is the previous element. +# +# Describe the relevant optical elements in the beam path by using the +# appropriate base classes. You may use as many elements as needed, also +# several elements of the same type as long as each element has its own name. +# +# +# +# Entry point of the dependency chain defined by the NXtransformations +# field, i.e. a link to the last element in the beam path. +# Example: /entry/instrument/beam_path/detector. +# +# +# +# +# +# Specify the order of the optical elements by defining a dependency chain. +# For each element, a '@depends_on' attribute should be used to state the +# position of the element in the beam path by pointing to the previous +# element. For the very first element, use the string "." instead. +# +# +# +# For each element in the beam path, one such field must exist with a +# '@depends_on' attribute defined to specify its position in the beam +# path. Note that also 'NXopt/ENTRY/INSTRUMENT/sample_stage' and windows +# ('NXopt/ENTRY/INSTRUMENT/sample_stage/entry_window' and +# 'NXopt/ENTRY/INSTRUMENT/sample_stage/exit_window') may be added to the +# dependency chain, i.e. may have an entry in this class even if they are +# not described in the beam path. +# ELEMENT is a place holder for the name of an optical beam path element. +# Note that the name of this field must be exactly the same as the +# element's field name. +# +# +# +# Add a link to the previous beam path element. +# +# +# +# +# +# +# Excitation source. One or more may be needed (e.g. two for a pump-probe +# setup with one pump and one probe beam). +# Depending on the source type, different properties are relevant, which +# are provided through the respective base class (e.g. use NXopt_source for +# lamps or lasers, NXchem_source for chemical reaction etc.). +# Some base classes are incomplete (NXchem_source, NXbio_source); the +# expertise of the respective communities is needed. +# +# +# +# Use this field to point to the previous optical element. +# +# +# +# +# Type of excitation source. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Lifespan of the excitation (typically provided in hours). +# +# +# +# +# How many hours has the lamp been used? +# +# +# +# +# Wavelengths or energy vector of the excitation source. This can be a +# single value or a spectrum, depending on the type of experiment. +# +# +# +# Unit of wavelength or energy. +# +# +# +# +# +# +# Two- or three-dimensional beam profile. +# +# +# +# +# +# +# +# +# Power of one light pulse if the source is a pulsed source. +# +# +# +# +# Is the excitation source continuous wave (CW)? +# +# +# +# +# Power of CW beam. +# +# +# +# +# FWHM bandwidth of the excitation source. +# +# +# +# +# Coherence length. +# +# +# +# +# Divergence of the excitation beam. +# +# +# +# +# +# Use this field to describe a simple pinhole (round geometry). Define its +# dimension using 'diameter'. For more complex geometries, 'NXaperture' +# should be used. +# +# +# +# +# Use this field to describe a simple slit (rectangular geometry). Define +# its dimensions using 'x_gap' and 'y_gap'. For more complex geometries, +# 'NXaperture' should be used. +# +# +# +# +# Use this field to describe an aperture. To specify a window, use the +# field 'window_NUMBER(NXaperture)'. +# +# +# +# +# A window, e.g. an entry or exit window of a cryostat. +# +# +# +# Use this field to point to the previous optical element. +# +# +# +# +# The material of the window. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# If you specified 'other' as material, decsribe here what it is. +# +# +# +# +# Thickness of the window +# +# +# +# +# Angle of the window normal (outer) vs. the substrate normal +# (similar to the angle of incidence). +# +# +# +# +# If reference data were measured add a link to the NeXus file where they +# are described. +# +# +# +# +# +# +# +# A device that reduces the intensity of a beam by attenuation. +# +# +# +# The transmitted intensity divided by the incident intensity. +# +# +# +# +# Attenuation of the attenuator in dB. +# +# +# +# Unit of the measured data is not covered by NXDL units state +# here which unit was used. +# +# +# +# +# +# Input and output aperture of the attenuator. +# +# +# +# +# Geometry (shape, size etc.) of the attenuator. +# +# +# +# +# +# A diffraction grating. Define relevant parameters in the corresponding +# fields, e.g. order of diffration (diffraction_order) or angular +# dispersion (angular_dispersion). +# +# +# +# Define the type of the grating. +# +# +# +# +# Dispersion of the grating in nm/mm (or e.g. nm/mrad). +# +# +# +# +# Number of grooves per mm. +# +# +# +# +# Blaze wavelength of the grating. +# +# +# +# +# Efficiency curve versus wavelength or energy. +# +# +# +# +# +# +# +# Spectral values, e.g. wavelength or energy. Vector of length +# N_spectrum. +# +# +# +# Unit of wavelength array (e.g. nanometer or Angstrom) +# +# +# +# +# +# +# A device blocking the beam in a temporal periodic pattern, e.g. a optical +# chopper wheel. Specify the frequency range using 'min_frequency' and +# 'max_frequency'. +# +# +# +# Minimum frequency in Hertz. +# +# +# +# +# Maximum frequency in Hertz. +# +# +# +# +# Frequency resolution in Hertz. +# +# +# +# +# +# A monochromator or spectrometer. +# +# +# +# Spectral values of the monochromator, e.g. wavelength or energy values +# used for the measurement. +# +# +# +# Unit of wavelength array (e.g. nanometer or Angstrom) +# +# +# +# +# +# Diffraction grating. If two or more gratings were used, define the +# angular dispersion and the wavelength range (min/max wavelength) for +# each grating and make sure that the wavelength ranges do not overlap. +# The dispersion should be defined for the entire wavelength range of the +# experiment. +# +# +# +# Dispersion of the grating in nm/mm. +# +# +# +# +# Minimum wavelength of the grating. +# +# +# +# +# Maximum wavelength of the grating. +# +# +# +# +# +# Spectral resolution of the instrument. +# +# +# +# +# Define the width of the monochromator slit in the subfield x_gap. +# +# +# +# Was the slit width fixed? +# +# +# +# +# If slit width was not fixed, define the maximum slit width. +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXbeam_splitter.yaml b/contributed_definitions/nyaml/NXbeam_splitter.yaml new file mode 100644 index 0000000000..64547668be --- /dev/null +++ b/contributed_definitions/nyaml/NXbeam_splitter.yaml @@ -0,0 +1,637 @@ +category: base +doc: | + A beam splitter, i.e. a device splitting the light into two or more beams. + + Information about types and properties of beam splitters is provided e.g. + [here](https://www.rp-photonics.com/beam_splitters.html). + + Use two or more NXbeam_paths to describe the beam paths after the beam + splitter. In the dependency chain of the new beam paths, the first elements + each point to this beam splitter, as this is the previous element. +symbols: + N_spectrum: | + Length of the spectrum vector (e.g. wavelength or energy) for which the + refractive index of the beam splitter material and/or coating is defined. + N_spectrum_RT: | + Length of the spectrum vector (e.g. wavelength or energy) for which the + reflectance or transmission of the beam splitter is given. + N_shapepar: | + Number of parameters needed do descripe the shape of the beam splitter. + N_objects: | + Number of objects the beam splitter is made up of. + N_outputs: | + Number of outputs, i.e. number of paths the beam takes after being split by + the beam splitter. + +# A draft of a new base class to describe a beam splitting device. +type: group +NXbeam_splitter(NXobject): + type: + doc: | + Specify the beam splitter type (e.g. dielectric mirror, pellicle, + dichroic mirror etc.). Shape (e.g. prism, plate, cube) and dimension + should be described in 'geometry'. Define if the beam splitter is + polarizing or not in the field 'polarizing(NX_BOOLEAN)'. + enumeration: [dichroic mirror, dielectric mirror, metal-coated mirror, Nicol prism, Glan-Thompson prism, pellicle mirror, Polka dot beam splitter, fiber optic splitter, other] + + # ??? Are there any other common types of beam splitters ??? + other_type: + doc: | + If you selected 'other' in 'type' use this field to specify which type of + beam splitter was used. + polarizing(NX_BOOLEAN): + doc: | + Is the beam splitter polarizing? + multiple_outputs(NX_BOOLEAN): + + # ??? Redundant because number of outputs is defined by N_outputs ??? + doc: | + Does the beam splitter have multiple outputs (diffractive optical + element), i.e. more than two outputs? + (NXshape): + exists: recommended + doc: | + Describe the geometry (shape, dimension etc.) of the beam splitter. + Specify the dimensions in 'SHAPE/size'. A sketch of the device should be + provided in the 'sketch(NXdata)' field to clarify (i) the shape and + dimensions of the device, and (ii) the input and outputs (i.e. the + direction of the incoming and outcoming (split) beams). + + # Specify the length and height if the surface facing the incident + # beam is a square or rectangle. Otherwise, if the device has a round + # geometry (disc), sepcify the diameter instead. + # The thickness or depth of the device should be defined in 'depth', + # while the thickness of the substrate and coating should be specified + # in 'substrate/substrate_thickness' and 'coating/coating_thickness'. + shape: + doc: | + Describe the shape (plate, cube, wedged, prism etc.). + enumeration: [cube, cylinder, plate, prism, wedged, other] + other_shape: + doc: | + If you chose 'other' in 'shape' describe what it is. + sketch(NXdata): + doc: | + Sketch of the beam splitter showing its geometry. The paths of the + incoming and split beam should be illustrated and labelled (0 for the + incoming beam, and 1, 2,..., N_outputs for the outputs (i.e. the split + beam paths)). + size: + doc: | + Physical extent of the beam splitter device. The beam splitter might be + made up of one or more objects (NX_objects). The meaning and location + of the axes used will vary according to the value of the 'shape' + variable. 'N_shapepar' defines how many parameters: + + * For 'cube' the parameters are (width, length). + * For 'cylinder' the parameters are (diameter, length). + * For 'plate' the parameters are (width, height, length). + * For 'prism' the parameters are (width, height, length). + * For 'wedged' the parameters are (width, height, shortest length). + The wedge angle should be provided in 'SHAPE/wedge_angle'. + * For 'other' the parameters may be (A, B, C, ...) with the labels + defined in the sketch plotted in 'SHAPE/sketch'. + dimensions: + rank: 2 + dim: [[1, N_objects], [2, N_shapepar]] + wedge_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Wedge angle if 'shape' is 'wedged'. + + # width, height, diameter, depth: Should we use 'size' in NXshape instead? + # width(NX_FLOAT): + # doc: | + # Width of the device's surface facing the incident beam if the surface + # is square or rectangular (e.g. is shape is a cube). + # unit: NX_LENGTH + # height(NX_FLOAT): + # doc: | + # Height of the device's surface facing the incident beam if the surface + # is square or rectangular (e.g. is shape is a cube). + # unit: NX_LENGTH + # diameter(NX_FLOAT): + # doc: | + # Diameter of the device's surface facing the incident beam if the + # surface has circular geometry (e.g. is shape is a cylinder). + # unit: NX_LENGTH + # length(NX_FLOAT): + # doc: | + # Specify the length of the beam splitter. If the device has a wedged + # shape provide the minimum and maximum length of the device. + # Otherwise, if the beam splitter has a homogeneous thickness, the two + # values are equal. + # dimensions: + # rank: 1 + # dim: [[1,2]] + splitting_ratio(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Beam splitting ratio(s) for the various outputs (i.e. the + paths of the beam after being split by the beam splitter). + The order of the ratios must be consistent with the labels + 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting with 1. + dimensions: + rank: 1 + dim: [[1, N_outputs]] + clear_aperture(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Clear aperture of the device (e.g. 90% of diameter for a disc, or 90% of + length and height for square geometry). + + # ??? Would it be better to provide the clear aperture as length ??? + substrate(NXsample): + doc: | + Substrate of the beam splitter. Describe the material of the substrate in + substrate/substrate_material and provide its index of refraction in + substrate/index_of_refraction_substrate, if known. + substrate_material: + doc: | + Specify the material of the beam splitter. If the device has a coating + it should be described in coating/coating_material. Is the material + birefringent? + substrate_thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + Thickness of the beam splitter substrate. Define the minimum and + maximum thickness (for a wedged geomtry). For a homogeneous thickness + (e.g. as in plate beam splitters) the minimum and maximum values are + equal. + dimensions: + rank: 1 + dim: [[1, 2]] + index_of_refration_substrate(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Complex index of refraction of the beam splitter substrate. Specify at + given spectral values (e.g. wavelength, energy, wavenumber etc.). + dimensions: + rank: 2 + dim: [[1, 2], [2, N_spectrum]] + coating(NXsample): + doc: | + Is the beam splitter coated? If yes, specify the type and material of the + coating and the spectral range for which it is designed. If known, you + may also provide its index of refraction. For a beam splitter cube + consisting of two prisms which are glued together, you may want to + specify the the glue and the coatings of each prism. + coating_type: + doc: | + Specify the coating type (e.g. dielectric, anti-reflection (AR), + multilayer coating etc.). + coating_material: + doc: | + Specify the coating material. + coating_thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + Thickness of the coating. + wavelength_range_coating(NX_FLOAT): + exists: recommended + unit: NX_WAVELENGTH + doc: | + Wavelength range for which the coating is designed. Enter the minimum + and maximum values of the wavelength range. + dimensions: + rank: 1 + dim: [[1, 2]] + index_of_refraction_coating(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Complex index of refraction of the coating. Specify at given spectral + values (e.g. wavelength, energy, wavenumber etc.). + dimensions: + rank: 2 + dim: [[1, 2], [2, N_spectrum]] + wavelength_range(NX_FLOAT): + exists: recommended + unit: NX_WAVELENGTH + doc: | + Wavelength range for which the beam splitter is designed. Enter the + minimum and maximum values of the wavelength range. Alternatively, or + additionally, you may define the wavelength range for the coating in + coating/wavelength_range_coating. + dimensions: + rank: 1 + dim: [[1, 2]] + optical_loss(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Optical loss of the beam splitter for the various outputs (i.e. the paths + of the beam after being split by the beam splitter). + The order of the ratios must be consistent with the labels + 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting + with 1. + dimensions: + rank: 1 + dim: [[1, N_outputs]] + incident_angle(NX_NUMBER): + unit: NX_ANGLE + doc: | + Optimized angle of incidence for the desired splitting ratio. + deflection_angle(NX_NUMBER): + unit: NX_ANGLE + + # is this really needed? + doc: | + Angle of deflection corresponding to the optimized angle of incidence + defined in incident_angle. + AOI_range(NX_NUMBER): + unit: NX_ANGLE + doc: | + Range of the angles of incidence (AOI) for which the beam splitter can be + operated. Specify the minimum and maximum angles of the range. + dimensions: + rank: 1 + dim: [[1, 2]] + + # Aren't some beamsplitters defined for specific angles? Should we instead + # use dim: [[1,N_angles]], N_angles being the number of angles for which the + # beam splitter can be operated? + # If this is the case for some devices, we might also have to define a field + # for the corresponding defelction angles... + reflectance(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Reflectance of the beam splitter at given spectral values. + dimensions: + rank: 1 + dim: [[1, N_spectrum_RT]] + transmission(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Transmission at given spectral values for the various outputs (i.e. the + paths of the beam after being split by the beam splitter). + The order of the ratios must be consistent with the labels + 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting + with 1. + dimensions: + rank: 2 + dim: [[1, N_outputs], [2, N_spectrum_RT]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 9c9fd3b4d0c17a3247a3133fbcc1af74f2ccf9c22249019dc21b7f568d8fa3ac +# +# +# +# +# +# +# +# +# Length of the spectrum vector (e.g. wavelength or energy) for which the +# refractive index of the beam splitter material and/or coating is defined. +# +# +# +# +# Length of the spectrum vector (e.g. wavelength or energy) for which the +# reflectance or transmission of the beam splitter is given. +# +# +# +# +# Number of parameters needed do descripe the shape of the beam splitter. +# +# +# +# +# Number of objects the beam splitter is made up of. +# +# +# +# +# Number of outputs, i.e. number of paths the beam takes after being split by +# the beam splitter. +# +# +# +# +# A beam splitter, i.e. a device splitting the light into two or more beams. +# +# Information about types and properties of beam splitters is provided e.g. +# [here](https://www.rp-photonics.com/beam_splitters.html). +# +# Use two or more NXbeam_paths to describe the beam paths after the beam +# splitter. In the dependency chain of the new beam paths, the first elements +# each point to this beam splitter, as this is the previous element. +# +# +# +# Specify the beam splitter type (e.g. dielectric mirror, pellicle, +# dichroic mirror etc.). Shape (e.g. prism, plate, cube) and dimension +# should be described in 'geometry'. Define if the beam splitter is +# polarizing or not in the field 'polarizing(NX_BOOLEAN)'. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# If you selected 'other' in 'type' use this field to specify which type of +# beam splitter was used. +# +# +# +# +# Is the beam splitter polarizing? +# +# +# +# +# +# Does the beam splitter have multiple outputs (diffractive optical +# element), i.e. more than two outputs? +# +# +# +# +# Describe the geometry (shape, dimension etc.) of the beam splitter. +# Specify the dimensions in 'SHAPE/size'. A sketch of the device should be +# provided in the 'sketch(NXdata)' field to clarify (i) the shape and +# dimensions of the device, and (ii) the input and outputs (i.e. the +# direction of the incoming and outcoming (split) beams). +# +# +# +# +# Describe the shape (plate, cube, wedged, prism etc.). +# +# +# +# +# +# +# +# +# +# +# +# +# If you chose 'other' in 'shape' describe what it is. +# +# +# +# +# Sketch of the beam splitter showing its geometry. The paths of the +# incoming and split beam should be illustrated and labelled (0 for the +# incoming beam, and 1, 2,..., N_outputs for the outputs (i.e. the split +# beam paths)). +# +# +# +# +# Physical extent of the beam splitter device. The beam splitter might be +# made up of one or more objects (NX_objects). The meaning and location +# of the axes used will vary according to the value of the 'shape' +# variable. 'N_shapepar' defines how many parameters: +# +# * For 'cube' the parameters are (width, length). +# * For 'cylinder' the parameters are (diameter, length). +# * For 'plate' the parameters are (width, height, length). +# * For 'prism' the parameters are (width, height, length). +# * For 'wedged' the parameters are (width, height, shortest length). +# The wedge angle should be provided in 'SHAPE/wedge_angle'. +# * For 'other' the parameters may be (A, B, C, ...) with the labels +# defined in the sketch plotted in 'SHAPE/sketch'. +# +# +# +# +# +# +# +# +# Wedge angle if 'shape' is 'wedged'. +# +# +# +# +# +# +# Beam splitting ratio(s) for the various outputs (i.e. the +# paths of the beam after being split by the beam splitter). +# The order of the ratios must be consistent with the labels +# 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting with 1. +# +# +# +# +# +# +# +# Clear aperture of the device (e.g. 90% of diameter for a disc, or 90% of +# length and height for square geometry). +# +# +# +# +# +# Substrate of the beam splitter. Describe the material of the substrate in +# substrate/substrate_material and provide its index of refraction in +# substrate/index_of_refraction_substrate, if known. +# +# +# +# Specify the material of the beam splitter. If the device has a coating +# it should be described in coating/coating_material. Is the material +# birefringent? +# +# +# +# +# Thickness of the beam splitter substrate. Define the minimum and +# maximum thickness (for a wedged geomtry). For a homogeneous thickness +# (e.g. as in plate beam splitters) the minimum and maximum values are +# equal. +# +# +# +# +# +# +# +# Complex index of refraction of the beam splitter substrate. Specify at +# given spectral values (e.g. wavelength, energy, wavenumber etc.). +# +# +# +# +# +# +# +# +# +# Is the beam splitter coated? If yes, specify the type and material of the +# coating and the spectral range for which it is designed. If known, you +# may also provide its index of refraction. For a beam splitter cube +# consisting of two prisms which are glued together, you may want to +# specify the the glue and the coatings of each prism. +# +# +# +# Specify the coating type (e.g. dielectric, anti-reflection (AR), +# multilayer coating etc.). +# +# +# +# +# Specify the coating material. +# +# +# +# +# Thickness of the coating. +# +# +# +# +# Wavelength range for which the coating is designed. Enter the minimum +# and maximum values of the wavelength range. +# +# +# +# +# +# +# +# Complex index of refraction of the coating. Specify at given spectral +# values (e.g. wavelength, energy, wavenumber etc.). +# +# +# +# +# +# +# +# +# +# Wavelength range for which the beam splitter is designed. Enter the +# minimum and maximum values of the wavelength range. Alternatively, or +# additionally, you may define the wavelength range for the coating in +# coating/wavelength_range_coating. +# +# +# +# +# +# +# +# Optical loss of the beam splitter for the various outputs (i.e. the paths +# of the beam after being split by the beam splitter). +# The order of the ratios must be consistent with the labels +# 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting +# with 1. +# +# +# +# +# +# +# +# Optimized angle of incidence for the desired splitting ratio. +# +# +# +# +# +# Angle of deflection corresponding to the optimized angle of incidence +# defined in incident_angle. +# +# +# +# +# Range of the angles of incidence (AOI) for which the beam splitter can be +# operated. Specify the minimum and maximum angles of the range. +# +# +# +# +# +# +# +# +# Reflectance of the beam splitter at given spectral values. +# +# +# +# +# +# +# +# Transmission at given spectral values for the various outputs (i.e. the +# paths of the beam after being split by the beam splitter). +# The order of the ratios must be consistent with the labels +# 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting +# with 1. +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXbias_spectroscopy.yaml b/contributed_definitions/nyaml/NXbias_spectroscopy.yaml new file mode 100644 index 0000000000..87971be740 --- /dev/null +++ b/contributed_definitions/nyaml/NXbias_spectroscopy.yaml @@ -0,0 +1,282 @@ +category: base +doc: | + Base classes definition for bias spectroscopy. + + Bias sweeps while measuring arbitrary channels with I(V) curves. +type: group +NXbias_spectroscopy(NXobject): + channels: + doc: | + Select the channels to record. + reset_bias(NX_BOOLEAN): + doc: | + If chosen, the Bias voltage resets to its initial value (before the sweep initiation) at + the conclusion of the spectroscopy measurement. When this option is not selected, the Bias + voltage maintains the last value acquired during the sweep. This functionality proves + beneficial, especially when combining multiple sweep segments. As an illustration of an + automated measurement: turn off the z-Controller, commence spectroscopy sweep segments ( + forward sweep only, without resetting the bias), restore the bias to its initial value, + and then turn on the z-Controller. + record_final_z(NX_BOOLEAN): + doc: | + Select whether to record the Z position during Z averaging time at the end of + the sweep (after Z control time) and store the average value in the header of + the file when saving. Using this option increases the sweep time by Z averaging + time. + lock_in_run(NX_BOOLEAN): + doc: | + Select whether to set the Lock-In to run during the measurement. When using this + feature, make sure the Lock-In is configured correctly and settling times are + set to twice the Lock-In period at least. This option is ignored when Lock-In is + already running. This option is disabled if the Sweep Mode is MLS and the flag + to configure the Lock-In per segment in the Multiline segment editor is set. + integration_time(NX_NUMBER): + unit: NX_TIME + doc: | + Time during which the spectroscopy data are acquired and averaged. + number_of_sweeps(NX_NUMBER): + doc: | + Number of sweeps to measure and average. + sweep_start(NX_NUMBER): + unit: NX_VOLTAGE + doc: | + The first bias values of the sweep. + sweep_end(NX_NUMBER): + unit: NX_VOLTAGE + doc: | + The last bias values of the sweep. + num_pixel(NX_NUMBER): + doc: | + Define the sweep number of points, that is, the maximum spectrum resolution eq. + Bias window divide by Num Pixel. + z_avg_time(NX_NUMBER): + unit: NX_TIME + doc: | + Duration over which the Z position is recorded and averaged before and after the + sweep (the latter only if Record final Z position is selected in the Advanced + section). After the initial z averaging time, if Z-Controller to Hold is + selected in the Advanced section, the z-Controller is set to hold and the tip is + placed at the previously averaged z position (plus z offset). + sw_filter_type(NX_CHAR): + doc: | + Select a filter to smooth the displayed data. When saving, if any filter is selected, + filtered data are saved to file along with the unfiltered data. + sw_filter_order(NX_NUMBER): + doc: | + Filter order of a dynamic filter or width (in number of points) for the Gaussian + filter. + sw_filter_cutoff_frq(NX_NUMBER): + doc: | + Cutoff frequency for dynamic filters. + z_offset(NX_NUMBER): + unit: NX_LENGTH + doc: | + Offset added to the initial averaged position Zaver before starting to sweep. + This parameter is disabled when Z-Controller to Hold is deselected in the + Advanced section. The LED “Alt” next to the Z offset indicates if an alternate + Z-controller setpoint is enabled. + settling_time(NX_NUMBER): + unit: NX_TIME + doc: | + Time to wait after changing the bias to the next level and before + starting to acquire data. + first_settling_time(NX_NUMBER): + doc: | + No doc yet. + end_settling_time(NX_NUMBER): + unit: NX_TIME + doc: | + Time to wait after the sweep has finished and the bias is ramped to + the initial value. + z_control_time(NX_NUMBER): + unit: NX_TIME + doc: | + Time during which the Z-Controller is enabled once a sweep has finished. + When averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled + for this duration between each sweep. After the last sweep, it will wait the + specified time before continuing a running scan. This ensures each sweep + reliably starts from the same position. This parameter is disabled when + Z-Controller to Hold is deselected in the Advanced section. + max_slew_rate(NX_NUMBER): + doc: | + Maximum rate at which the bias changes (before, during and after sweeping). + (V/s) + backward_sweep(NX_BOOLEAN): + doc: | + Select whether to measure the backward (return) sweep or the forward only. + z_ccontroller_hold(NX_BOOLEAN): + doc: | + Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. + It is selected by default. When deselected, Z-offset and Z control time parameters + are disabled. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# a3079d513b63e99022e710b15756f7cd46a7101b306d34339dc6d6b3c7d685b1 +# +# +# +# +# +# Base classes definition for bias spectroscopy. +# +# Bias sweeps while measuring arbitrary channels with I(V) curves. +# +# +# +# Select the channels to record. +# +# +# +# +# If chosen, the Bias voltage resets to its initial value (before the sweep initiation) at +# the conclusion of the spectroscopy measurement. When this option is not selected, the Bias +# voltage maintains the last value acquired during the sweep. This functionality proves +# beneficial, especially when combining multiple sweep segments. As an illustration of an +# automated measurement: turn off the z-Controller, commence spectroscopy sweep segments ( +# forward sweep only, without resetting the bias), restore the bias to its initial value, +# and then turn on the z-Controller. +# +# +# +# +# Select whether to record the Z position during Z averaging time at the end of +# the sweep (after Z control time) and store the average value in the header of +# the file when saving. Using this option increases the sweep time by Z averaging +# time. +# +# +# +# +# Select whether to set the Lock-In to run during the measurement. When using this +# feature, make sure the Lock-In is configured correctly and settling times are +# set to twice the Lock-In period at least. This option is ignored when Lock-In is +# already running. This option is disabled if the Sweep Mode is MLS and the flag +# to configure the Lock-In per segment in the Multiline segment editor is set. +# +# +# +# +# Time during which the spectroscopy data are acquired and averaged. +# +# +# +# +# Number of sweeps to measure and average. +# +# +# +# +# The first bias values of the sweep. +# +# +# +# +# The last bias values of the sweep. +# +# +# +# +# Define the sweep number of points, that is, the maximum spectrum resolution eq. +# Bias window divide by Num Pixel. +# +# +# +# +# Duration over which the Z position is recorded and averaged before and after the +# sweep (the latter only if Record final Z position is selected in the Advanced +# section). After the initial z averaging time, if Z-Controller to Hold is +# selected in the Advanced section, the z-Controller is set to hold and the tip is +# placed at the previously averaged z position (plus z offset). +# +# +# +# +# Select a filter to smooth the displayed data. When saving, if any filter is selected, +# filtered data are saved to file along with the unfiltered data. +# +# +# +# +# Filter order of a dynamic filter or width (in number of points) for the Gaussian +# filter. +# +# +# +# +# Cutoff frequency for dynamic filters. +# +# +# +# +# Offset added to the initial averaged position Zaver before starting to sweep. +# This parameter is disabled when Z-Controller to Hold is deselected in the +# Advanced section. The LED “Alt” next to the Z offset indicates if an alternate +# Z-controller setpoint is enabled. +# +# +# +# +# Time to wait after changing the bias to the next level and before +# starting to acquire data. +# +# +# +# +# No doc yet. +# +# +# +# +# Time to wait after the sweep has finished and the bias is ramped to +# the initial value. +# +# +# +# +# Time during which the Z-Controller is enabled once a sweep has finished. +# When averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled +# for this duration between each sweep. After the last sweep, it will wait the +# specified time before continuing a running scan. This ensures each sweep +# reliably starts from the same position. This parameter is disabled when +# Z-Controller to Hold is deselected in the Advanced section. +# +# +# +# +# Maximum rate at which the bias changes (before, during and after sweeping). +# (V/s) +# +# +# +# +# Select whether to measure the backward (return) sweep or the forward only. +# +# +# +# +# Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. +# It is selected by default. When deselected, Z-offset and Z control time parameters +# are disabled. +# +# +# diff --git a/contributed_definitions/nyaml/NXcalibration.yaml b/contributed_definitions/nyaml/NXcalibration.yaml new file mode 100644 index 0000000000..c8337b5b20 --- /dev/null +++ b/contributed_definitions/nyaml/NXcalibration.yaml @@ -0,0 +1,178 @@ +category: base +doc: | + Subclass of NXprocess to describe post-processing calibrations. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays + ncoeff: | + Number of coefficients of the calibration function + nfeat: | + Number of features used to fit the calibration function + ncal: | + Number of points of the calibrated and uncalibrated axes +type: group +NXcalibration(NXobject): + last_process(NX_CHAR): + doc: | + Indicates the name of the last operation applied in the NXprocess sequence. + applied(NX_BOOLEAN): + doc: | + Has the calibration been applied? + coefficients(NX_FLOAT): + unit: NX_ANY + doc: | + For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit + to a set of features (peaks) at well defined energy positions to determine + E(TOF). Here we can store the array of fit coefficients. + dimensions: + rank: 1 + dim: [[1, ncoeff]] + fit_function(NX_CHAR): + doc: | + 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. + scaling(NX_FLOAT): + unit: NX_ANY + doc: | + For linear calibration. Scaling parameter. + offset(NX_FLOAT): + unit: NX_ANY + doc: | + For linear calibration. Offset parameter. + calibrated_axis(NX_FLOAT): + unit: NX_ANY + doc: | + A vector representing the axis after calibration, matching the data length + dimensions: + rank: 1 + dim: [[1, ncal]] + original_axis(NX_FLOAT): + unit: NX_ANY + doc: | + Vector containing the data coordinates in the original uncalibrated axis + dimensions: + rank: 1 + dim: [[1, ncal]] + description(NX_CHAR): + doc: | + A description of the procedures employed. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 7394f6136c95cdee182a96a9aff856eee0285b94b6a3e83a0175949aa9752ae3 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays +# +# +# +# Number of coefficients of the calibration function +# +# +# +# +# Number of features used to fit the calibration function +# +# +# +# +# Number of points of the calibrated and uncalibrated axes +# +# +# +# +# Subclass of NXprocess to describe post-processing calibrations. +# +# +# +# Indicates the name of the last operation applied in the NXprocess sequence. +# +# +# +# +# Has the calibration been applied? +# +# +# +# +# For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit +# to a set of features (peaks) at well defined energy positions to determine +# E(TOF). Here we can store the array of fit coefficients. +# +# +# +# +# +# +# +# For non-linear energy calibrations. Here we can store the formula of the +# fit function. +# +# Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. +# +# Use x0, x1, ..., xn for the variables. +# +# The formula should be numpy compliant. +# +# +# +# +# For linear calibration. Scaling parameter. +# +# +# +# +# For linear calibration. Offset parameter. +# +# +# +# +# A vector representing the axis after calibration, matching the data length +# +# +# +# +# +# +# +# Vector containing the data coordinates in the original uncalibrated axis +# +# +# +# +# +# +# +# A description of the procedures employed. +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_alpha_complex.yaml b/contributed_definitions/nyaml/NXcg_alpha_complex.yaml new file mode 100644 index 0000000000..c1d9ea91c8 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_alpha_complex.yaml @@ -0,0 +1,253 @@ +category: base +doc: | + Computational geometry description of alpha shapes or wrappings to primitives. + + For details see: + + * https://dx.doi.org/10.1109/TIT.1983.1056714 for 2D, + * https://dx.doi.org/10.1145/174462.156635 for 3D, + * https://dl.acm.org/doi/10.5555/871114 for weighted, and + * https://doc.cgal.org/latest/Alpha_shapes_3 for 3D implementation + * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D wrap + + in CGAL, the Computational Geometry Algorithms Library. + As a starting point, we follow the conventions of the CGAL library. + +# weighted alpha shapes +# The so-called spectrum or sets of (weighted) alpha shapes includes the +# convex hull of a point set. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality of the alpha shape, for now 2 or 3. + + # generalize to d > 3 + n_e: | + The number of edges. + n_f: | + The number of faces. + n_c: | + The number of cells. +type: group +NXcg_alpha_complex(NXobject): + dimensionality(NX_UINT): + unit: NX_UNITLESS + enumeration: [2, 3] + type: + doc: | + Specify which general type of alpha shape is computed. + Using for now the CGAL terminology. Basic means (unweighted) alpha shapes. + Alpha_wrapping means meshes created using alpha wrapping procedures. + enumeration: [convex_hull, alpha_shape, alpha_wrapping] + mode: + doc: | + Specifically when computed with the CGAL, the mode specifies if singular + faces are removed (regularized) of the alpha complex. + + # CHECK THIS AGAIN CAREFULLY + enumeration: [general, regularized] + alpha(NX_NUMBER): + unit: NX_LENGTH + doc: | + The alpha, (radius of the alpha-sphere) parameter to be used for alpha + shapes and alpha wrappings. + offset(NX_NUMBER): + unit: NX_LENGTH + doc: | + The offset distance parameter to be used in addition to alpha + in the case of alpha_wrapping. + + # check again carefully the CGAL documentation talks about, for 3D, the square of the radius! + point_set(NXcg_point_set): + doc: | + Point cloud for which the alpha shape or wrapping should be computed. + + # this could also just be implemented as a link but how would this be possible + # unfold the NXcg_point_set and add a + # weight(NX_NUMBER): + # doc: Weights for each point + # In general, an alpha complex is a disconnected and non-pure complex, + # meaning in particular that the alpha complex may have singular faces. + # so the number of cells, faces and edges depends on how a specific alpha complex, + # i.e. an alpha-shape of S for alpha, is filtrated with respect to k < d-dimensional + # simplices. Here we assume that number_of_cells, number_of_faces, number_of_edges + # are reported assuming one filtrates these simplices according to mode. + # also using the assumption the base class reports the unique vertices + # of the specifically filtrated alpha complex. + triangle_set(NXcg_triangle_set): + doc: | + Triangle soup for which the alpha wrapping should be computed. + triangulation(NXcg_triangle_set): + doc: | + A meshed representation of the resulting shape. + + # should be a mesh + # add for each triangle if desirable a notation of whether the simplex is + # exterior, regular, singular, or interior with respect to the alpha complex + # but a triangulation is more than a triangle (soup)/set because there is + # connectivity information + # customize the NXcg_triangle_set base class members such that connectivity + # information is contained + # we need to find also a better name for this, what people intutive understand + # as the interior, may not even exist for a given alpha value + # more specifically it is the set of filtrated cells acknowledging mode + # e.g. the interior cells of the regularized alpha complex + interior_cells(NXcg_tetrahedron_set): + + # document the alpha status + # https://doc.cgal.org/latest/Alpha_shapes_3/classCGAL_1_1Alpha__status.html + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 9f7873863060d94e12baf1e7de9592761ad41c13677af7af3c0e1f5db6228950 +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality of the alpha shape, for now 2 or 3. +# +# +# +# +# +# The number of edges. +# +# +# +# +# The number of faces. +# +# +# +# +# The number of cells. +# +# +# +# +# Computational geometry description of alpha shapes or wrappings to primitives. +# +# For details see: +# +# * https://dx.doi.org/10.1109/TIT.1983.1056714 for 2D, +# * https://dx.doi.org/10.1145/174462.156635 for 3D, +# * https://dl.acm.org/doi/10.5555/871114 for weighted, and +# * https://doc.cgal.org/latest/Alpha_shapes_3 for 3D implementation +# * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D wrap +# +# in CGAL, the Computational Geometry Algorithms Library. +# As a starting point, we follow the conventions of the CGAL library. +# +# +# +# +# +# +# +# +# +# Specify which general type of alpha shape is computed. +# Using for now the CGAL terminology. Basic means (unweighted) alpha shapes. +# Alpha_wrapping means meshes created using alpha wrapping procedures. +# +# +# +# +# +# +# +# +# +# Specifically when computed with the CGAL, the mode specifies if singular +# faces are removed (regularized) of the alpha complex. +# +# +# +# +# +# +# +# +# +# The alpha, (radius of the alpha-sphere) parameter to be used for alpha +# shapes and alpha wrappings. +# +# +# +# +# The offset distance parameter to be used in addition to alpha +# in the case of alpha_wrapping. +# +# +# +# +# +# Point cloud for which the alpha shape or wrapping should be computed. +# +# +# +# +# +# Triangle soup for which the alpha wrapping should be computed. +# +# +# +# +# A meshed representation of the resulting shape. +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_cylinder_set.yaml b/contributed_definitions/nyaml/NXcg_cylinder_set.yaml new file mode 100644 index 0000000000..157d0a97d8 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_cylinder_set.yaml @@ -0,0 +1,292 @@ +category: base +doc: | + Computational geometry description of a set of cylinders in Euclidean space. + + The members of the set can have different size. For each member the position + of the center and the height is mandatory. The radius can either be defined + in the radius field or by filling both the upper and the lower radius field. + The latter case can be used to represent truncated cones. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + c: | + The cardinality of the set, i.e. the number of cylinders or cones. + +# redundant as there is NXcsg, NXquadric, NXsolid_geometry with which +# cylinder could be constructed, but NXcylinder is easier to understand +type: group +NXcg_cylinder_set(NXobject): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + enumeration: [3] + cardinality(NX_POSINT): + unit: NX_UNITLESS + identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for distinguishing + identifiers for cylinders. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + identifier(NX_INT): + doc: | + Integer used to distinguish members for explicit indexing. + dimensions: + rank: 1 + dim: [[1, c]] + center(NX_NUMBER): + unit: NX_LENGTH + doc: | + The geometric center of each member. + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] + height(NX_NUMBER): + unit: NX_LENGTH + doc: | + A direction vector which is parallel to the cylinder/cone axis and + whose magnitude is the height of the cylinder/cone. + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] + + # alternatively one could store the center of the lower and upper cap but + # these are then no longer necessarily on the same axis + # maybe a future feature for representing skewed cylinder, but then + # one should really better use NXquadric... + radii(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, c]] + upper_cap_radius(NX_NUMBER): + unit: NX_LENGTH + doc: | + The radius of the upper circular cap. + This field, combined with lower_cap_radius can be used to + describe (eventually truncated) circular cones. + dimensions: + rank: 1 + dim: [[1, c]] + lower_cap_radius(NX_NUMBER): + unit: NX_LENGTH + doc: | + The radius of the upper circular cap. + This field, combined with lower_cap_radius can be used to + describe (eventually truncated) circular cones. + dimensions: + rank: 1 + dim: [[1, c]] + (NXtransformations): + doc: | + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + # properties of the cylinder + volume(NX_NUMBER): + unit: NX_VOLUME + doc: | + Interior volume of each cylinder + dimensions: + rank: 1 + dim: [[1, c]] + lateral_surface_area(NX_NUMBER): + unit: NX_AREA + doc: | + Lateral surface area + dimensions: + rank: 1 + dim: [[1, c]] + cap_surface_area(NX_NUMBER): + unit: NX_AREA + doc: | + Area of the upper and the lower cap of each cylinder respectively. + dimensions: + rank: 2 + dim: [[1, c], [2, 2]] + surface_area(NX_NUMBER): + unit: NX_AREA + doc: | + Cap and lateral surface area for each cylinder. + dimensions: + rank: 1 + dim: [[1, c]] + + # again cap, lateral surface area and volume are so trivial to compute + # do we need really storage for this or recompute on-the-fly? + # similarly to hollow sphere discussion, hollow cylinder, cylinder stack + # do wish to define intersections?, if this is the case, one + # should use the NXcsg and NXquadric descriptions? + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 815fb407122ebed44d9cdc549536e85234abe1c87ed7bb357cf6eee85bfc8dd9 +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The cardinality of the set, i.e. the number of cylinders or cones. +# +# +# +# +# Computational geometry description of a set of cylinders in Euclidean space. +# +# The members of the set can have different size. For each member the position +# of the center and the height is mandatory. The radius can either be defined +# in the radius field or by filling both the upper and the lower radius field. +# The latter case can be used to represent truncated cones. +# +# +# +# +# +# +# +# +# +# Integer which specifies the first index to be used for distinguishing +# identifiers for cylinders. Identifiers are defined either implicitly +# or explicitly. For implicit indexing the identifiers are defined on the +# interval [identifier_offset, identifier_offset+c-1]. +# For explicit indexing the identifier array has to be defined. +# +# The identifier_offset field can for example be used to communicate if the +# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) +# or from 0 (referred to as C-, Python-style index notation) respectively. +# +# +# +# +# Integer used to distinguish members for explicit indexing. +# +# +# +# +# +# +# +# The geometric center of each member. +# +# +# +# +# +# +# +# +# A direction vector which is parallel to the cylinder/cone axis and +# whose magnitude is the height of the cylinder/cone. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The radius of the upper circular cap. +# This field, combined with lower_cap_radius can be used to +# describe (eventually truncated) circular cones. +# +# +# +# +# +# +# +# The radius of the upper circular cap. +# This field, combined with lower_cap_radius can be used to +# describe (eventually truncated) circular cones. +# +# +# +# +# +# +# +# Reference to or definition of a coordinate system with +# which the positions and directions are interpretable. +# +# +# +# +# +# Interior volume of each cylinder +# +# +# +# +# +# +# +# Lateral surface area +# +# +# +# +# +# +# +# Area of the upper and the lower cap of each cylinder respectively. +# +# +# +# +# +# +# +# +# Cap and lateral surface area for each cylinder. +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml b/contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml new file mode 100644 index 0000000000..2fdb47e471 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml @@ -0,0 +1,234 @@ +category: base +doc: | + Computational geometry description of a set of ellipsoids in Euclidean space. + + Individual ellipsoids can have different half axes. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality, which has to be at least 2. + c: | + The cardinality of the set, i.e. the number of ellipses, or ellipsoids. + +# redundant as there is NXcsg, and NXquadric but easier to understand +type: group +NXcg_ellipsoid_set(NXobject): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + cardinality(NX_POSINT): + unit: NX_UNITLESS + identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for distinguishing + identifiers for ellipsoids. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + identifier(NX_INT): + unit: NX_UNITLESS + doc: | + Integer used to distinguish ellipsoids for explicit indexing. + dimensions: + rank: 1 + dim: [[1, c]] + center(NX_NUMBER): + unit: NX_LENGTH + doc: | + Geometric center of the ellipsoids. This can be the center of mass. + Dimensionality and cardinality of the point and ellipsoid set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the ellipsoids. + dimensions: + rank: 2 + dim: [[1, c], [2, d]] + half_axes_radius(NX_NUMBER): + unit: NX_LENGTH + doc: | + If all ellipsoids in the set have the same half-axes. + dimensions: + rank: 1 + dim: [[1, d]] + half_axes_radii(NX_NUMBER): + unit: NX_LENGTH + doc: | + In the case that ellipsoids have different radii use this field + instead of half_axes_radius. + dimensions: + rank: 2 + dim: [[1, c], [2, d]] + (NXtransformations): + doc: | + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + # properties of ellipsoids + is_closed(NX_BOOLEAN): + doc: | + Are the ellipsoids closed or hollow? + dimensions: + rank: 1 + dim: [[1, c]] + volume(NX_NUMBER): + unit: NX_ANY + dimensions: + rank: 1 + dim: [[1, c]] + surface_area(NX_NUMBER): + unit: NX_ANY + dimensions: + rank: 1 + dim: [[1, c]] + + # NXcg_orientation_set + orientation(NX_NUMBER): + unit: NX_DIMENSIONLESS + doc: | + Direction unit vector which points along the largest half-axes. + dimensions: + rank: 2 + dim: [[1, c], [2, d]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 62a35f2abe55a465447b99935846b1a3ff9ae13935511d32899a79a49e30c499 +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality, which has to be at least 2. +# +# +# +# +# The cardinality of the set, i.e. the number of ellipses, or ellipsoids. +# +# +# +# +# Computational geometry description of a set of ellipsoids in Euclidean space. +# +# Individual ellipsoids can have different half axes. +# +# +# +# +# +# Integer which specifies the first index to be used for distinguishing +# identifiers for ellipsoids. Identifiers are defined either implicitly +# or explicitly. For implicit indexing the identifiers are defined on the +# interval [identifier_offset, identifier_offset+c-1]. +# For explicit indexing the identifier array has to be defined. +# +# The identifier_offset field can for example be used to communicate if the +# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) +# or from 0 (referred to as C-, Python-style index notation) respectively. +# +# +# +# +# Integer used to distinguish ellipsoids for explicit indexing. +# +# +# +# +# +# +# +# Geometric center of the ellipsoids. This can be the center of mass. +# Dimensionality and cardinality of the point and ellipsoid set have to match. +# The identifier_offset and identifier field of NXcg_point_set do not need +# to be used as they should be same as the identifier_offset and the +# identifier for the ellipsoids. +# +# +# +# +# +# +# +# +# If all ellipsoids in the set have the same half-axes. +# +# +# +# +# +# +# +# In the case that ellipsoids have different radii use this field +# instead of half_axes_radius. +# +# +# +# +# +# +# +# +# Reference to or definition of a coordinate system with +# which the positions and directions are interpretable. +# +# +# +# +# +# Are the ellipsoids closed or hollow? +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction unit vector which points along the largest half-axes. +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml b/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml new file mode 100644 index 0000000000..13442c81c9 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml @@ -0,0 +1,429 @@ +category: base +doc: | + Computational geometry description of geometric primitives via a face and edge list. + + Primitives must not be degenerated or self-intersect. + Such descriptions of primitives are frequently used for triangles and polyhedra + to store them on disk for visualization purposes. Although storage efficient, + such a description is not well suited for topological and neighborhood queries + of especially meshes that are built from primitives. + + In this case, scientists may need a different view on the primitives which + is better represented for instance with a half_edge_data_structure instance. + The reason to split thus the geometric description of primitives, sets, and + specifically meshes of primitives is to keep the structure simple enough for + users without these computational geometry demands but also enable those more + computational geometry savy users the storing of the additionally relevant + data structure. + + This is beneficial and superior over NXoff_geometry because for instance a + half_edge_data_structure instance can be immediately use to reinstantiate + the set without having to recompute the half_edge_structure from the vertex + and face-list based representation and thus offer a more efficient route + to serve applications where topological and graph-based operations are key. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality, which has to be at least 2. + n_v: | + The number of vertices. + n_e: | + The number of edges. + n_f: | + The number of faces. + n_total: | + The total number of vertices of all faces. Faces are polygons. + n_weinberg: | + The total number of Weinberg vector values of all faces. + +# duplicate of an NXoff_geometry ? +type: group +NXcg_face_list_data_structure(NXobject): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + doc: | + Dimensionality. + + # resulting in a design similar to that of NXoff_geometry and the XDMF mixed primitive topology + number_of_vertices(NX_POSINT): + unit: NX_UNITLESS + doc: | + Array which specifies of how many vertices each face is built. + Each entry represent the total number of vertices for face, irrespectively + whether vertices are shared among faces/are unique or not. + dimensions: + rank: 1 + dim: [[1, n_f]] + number_of_edges(NX_POSINT): + unit: NX_UNITLESS + doc: | + Number of edges. + number_of_faces(NX_POSINT): + unit: NX_UNITLESS + doc: | + Number of faces. + vertex_identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + edge_identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for distinguishing + identifiers for edges. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + face_identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + vertex_identifier(NX_INT): + unit: NX_UNITLESS + doc: | + Integer used to distinguish vertices explicitly. + dimensions: + rank: 1 + dim: [[1, n_v]] + edge_identifier(NX_INT): + unit: NX_UNITLESS + doc: | + Integer used to distinguish edges explicitly. + dimensions: + rank: 1 + dim: [[1, n_e]] + face_identifier(NX_INT): + unit: NX_UNITLESS + doc: | + Integer used to distinguish faces explicitly. + dimensions: + rank: 1 + dim: [[1, n_f]] + vertices(NX_NUMBER): + unit: NX_LENGTH + doc: | + Positions of the vertices. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + dimensions: + rank: 2 + dim: [[1, n_v], [2, d]] + edges(NX_INT): + unit: NX_UNITLESS + doc: | + The edges are stored as a pairs of vertex identifier values. + dimensions: + rank: 2 + dim: [[1, n_e], [2, 2]] + faces(NX_INT): + unit: NX_UNITLESS + doc: | + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + dimensions: + rank: 1 + dim: [[1, n_total]] + + # properties + vertices_are_unique(NX_BOOLEAN): + doc: | + If true indicates that the vertices are all placed at different positions + and have different identifiers, i.e. no points overlap or are counted twice. + edges_are_unique(NX_BOOLEAN): + doc: | + If true indicates that no edge is stored twice. Users are encouraged to + consider and use the half_edge_data_structure instead as this will work + towards achieving a cleaner graph-based description if relevant and possible. + faces_are_unique(NX_BOOLEAN): + winding_order(NX_INT): + unit: NX_UNITLESS + doc: | + Specifies for each face which winding order was used if any: + + * 0 - undefined + * 1 - counter-clockwise (CCW) + * 2 - clock-wise (CW) + dimensions: + rank: 1 + dim: [[1, n_f]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 4718c5ea6858b75fb10fcc11ec57c04c5208050e8c7b77fe9177a8f5e4ee7d96 +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality, which has to be at least 2. +# +# +# +# +# The number of vertices. +# +# +# +# +# The number of edges. +# +# +# +# +# The number of faces. +# +# +# +# +# The total number of vertices of all faces. Faces are polygons. +# +# +# +# +# The total number of Weinberg vector values of all faces. +# +# +# +# +# Computational geometry description of geometric primitives via a face and edge list. +# +# Primitives must not be degenerated or self-intersect. +# Such descriptions of primitives are frequently used for triangles and polyhedra +# to store them on disk for visualization purposes. Although storage efficient, +# such a description is not well suited for topological and neighborhood queries +# of especially meshes that are built from primitives. +# +# In this case, scientists may need a different view on the primitives which +# is better represented for instance with a half_edge_data_structure instance. +# The reason to split thus the geometric description of primitives, sets, and +# specifically meshes of primitives is to keep the structure simple enough for +# users without these computational geometry demands but also enable those more +# computational geometry savy users the storing of the additionally relevant +# data structure. +# +# This is beneficial and superior over NXoff_geometry because for instance a +# half_edge_data_structure instance can be immediately use to reinstantiate +# the set without having to recompute the half_edge_structure from the vertex +# and face-list based representation and thus offer a more efficient route +# to serve applications where topological and graph-based operations are key. +# +# +# +# Dimensionality. +# +# +# +# +# +# Array which specifies of how many vertices each face is built. +# Each entry represent the total number of vertices for face, irrespectively +# whether vertices are shared among faces/are unique or not. +# +# +# +# +# +# +# +# Number of edges. +# +# +# +# +# Number of faces. +# +# +# +# +# Integer which specifies the first index to be used for distinguishing +# identifiers for vertices. Identifiers are defined either implicitly +# or explicitly. For implicit indexing the identifiers are defined on the +# interval [identifier_offset, identifier_offset+c-1]. +# For explicit indexing the identifier array has to be defined. +# +# The identifier_offset field can for example be used to communicate if +# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) +# or from 0 (referred to as C-, Python-style index notation) respectively. +# +# +# +# +# Integer which specifies the first index to be used for distinguishing +# identifiers for edges. Identifiers are defined either implicitly +# or explicitly. For implicit indexing the identifiers are defined on the +# interval [identifier_offset, identifier_offset+c-1]. +# For explicit indexing the identifier array has to be defined. +# +# The identifier_offset field can for example be used to communicate if +# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) +# or from 0 (referred to as C-, Python-style index notation) respectively. +# +# +# +# +# Integer which specifies the first index to be used for distinguishing +# identifiers for faces. Identifiers are defined either implicitly +# or explicitly. For implicit indexing the identifiers are defined on the +# interval [identifier_offset, identifier_offset+c-1]. +# For explicit indexing the identifier array has to be defined. +# +# The identifier_offset field can for example be used to communicate if +# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) +# or from 0 (referred to as C-, Python-style index notation) respectively. +# +# +# +# +# Integer used to distinguish vertices explicitly. +# +# +# +# +# +# +# +# Integer used to distinguish edges explicitly. +# +# +# +# +# +# +# +# Integer used to distinguish faces explicitly. +# +# +# +# +# +# +# +# Positions of the vertices. +# +# Users are encouraged to reduce the vertices to unique set of positions +# and vertices as this supports a more efficient storage of the geometry data. +# It is also possible though to store the vertex positions naively in which +# case vertices_are_unique is likely False. +# Naively here means that one for example stores each vertex of a triangle +# mesh even though many vertices are shared between triangles and thus +# the positions of these vertices do not have to be duplicated. +# +# +# +# +# +# +# +# +# The edges are stored as a pairs of vertex identifier values. +# +# +# +# +# +# +# +# +# Array of identifiers from vertices which describe each face. +# +# The first entry is the identifier of the start vertex of the first face, +# followed by the second vertex of the first face, until the last vertex +# of the first face. Thereafter, the start vertex of the second face, the +# second vertex of the second face, and so on and so forth. +# +# Therefore, summating over the number_of_vertices, allows to extract +# the vertex identifiers for the i-th face on the following index interval +# of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. +# +# +# +# +# +# +# +# +# If true indicates that the vertices are all placed at different positions +# and have different identifiers, i.e. no points overlap or are counted twice. +# +# +# +# +# If true indicates that no edge is stored twice. Users are encouraged to +# consider and use the half_edge_data_structure instead as this will work +# towards achieving a cleaner graph-based description if relevant and possible. +# +# +# +# +# +# Specifies for each face which winding order was used if any: +# +# * 0 - undefined +# * 1 - counter-clockwise (CCW) +# * 2 - clock-wise (CW) +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml b/contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml new file mode 100644 index 0000000000..b699a269fb --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml @@ -0,0 +1,91 @@ +category: base +doc: | + Computational geometry description of a geodesic mesh. + + People from geodesic/surveyors will likely have specific demands and + different views about what should be included in such a base class, given + that nested geodesic meshes are a key component of climate modelling tools. + For now we propose to use this base class as a container to organize metadata + and data related to geodesic meshes. + + Specifically an instance of this base class should detail the rule set how + how the geodesic (surface) mesh was instantiated as there are many + possibilities. A geodesic surface mesh is in this sense a triangulated + surface mesh with metadata. For additional details as an introduction + into the topic see e.g.: + + * `E. S. Popko and C. J. Kitrick `_ + + Here, especially the section on subdivision schemes is relevant. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXcg_geodesic_mesh(NXobject): + (NXtransformations): + doc: | + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + (NXcg_triangulated_surface_mesh): + + # Discussions with NFDI-Earth could make this base class more meaty and detailed. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# faf25da56eb05eb830cdd732526a40f09965fa99c410890826ba5a3fc9eb237a +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Computational geometry description of a geodesic mesh. +# +# People from geodesic/surveyors will likely have specific demands and +# different views about what should be included in such a base class, given +# that nested geodesic meshes are a key component of climate modelling tools. +# For now we propose to use this base class as a container to organize metadata +# and data related to geodesic meshes. +# +# Specifically an instance of this base class should detail the rule set how +# how the geodesic (surface) mesh was instantiated as there are many +# possibilities. A geodesic surface mesh is in this sense a triangulated +# surface mesh with metadata. For additional details as an introduction +# into the topic see e.g.: +# +# * `E. S. Popko and C. J. Kitrick <https://doi.org/10.1201/9781003134114>`_ +# +# Here, especially the section on subdivision schemes is relevant. +# +# +# +# Reference to or definition of a coordinate system with +# which the positions and directions are interpretable. +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_grid.yaml b/contributed_definitions/nyaml/NXcg_grid.yaml new file mode 100644 index 0000000000..ba677dd5bf --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_grid.yaml @@ -0,0 +1,311 @@ +category: base +doc: | + Computational geometry description of a Wigner-Seitz cell grid in Euclidean space. + + Frequently convenient three-dimensional grids with cubic cells are used. + Exemplar applications are spectral-solver based crystal plasticity + and stencil methods like phase-field or cellular automata. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality of the grid. + c: | + The cardinality or total number of cells/grid points. + n_b: | + Number of boundaries of the bounding box or primitive to the grid. +type: group +NXcg_grid(NXobject): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + enumeration: [1, 2, 3] + cardinality(NX_POSINT): + unit: NX_UNITLESS + origin(NX_NUMBER): + dimensions: + rank: 1 + dim: [[1, d]] + symmetry: + doc: | + The symmetry of the lattice defining the shape of the unit cell. + enumeration: [cubic] + cell_dimensions(NX_NUMBER): + unit: NX_LENGTH + doc: | + The unit cell dimensions using crystallographic notation. + dimensions: + rank: 1 + dim: [[1, d]] + extent(NX_POSINT): + unit: NX_UNITLESS + doc: | + Number of unit cells along each of the d unit vectors. + The total number of cells, or grid points has to be the cardinality. + If the grid has an irregular number of grid positions in each direction, + as it could be for instance the case of a grid where all grid points + outside some masking primitive are removed, this extent field should + not be used. Instead use the coordinate field. + dimensions: + rank: 1 + dim: [[1, d]] + (NXtransformations): + doc: | + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + # number_of_cells(NX_UINT): maybe already too trivial quantities + # should constraints on the grid be place here or not + identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for distinguishing + identifiers for cells. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + identifier(NX_INT): + unit: NX_UNITLESS + doc: | + Integer used to distinguish cells for explicit indexing. + dimensions: + rank: 1 + dim: [[1, c]] + position(NX_NUMBER): + unit: NX_LENGTH + doc: | + Position of each cell in Euclidean space. + dimensions: + rank: 2 + dim: [[1, c], [2, d]] + coordinate(NX_INT): + unit: NX_DIMENSIONLESS + doc: | + Coordinate of each cell with respect to the discrete grid. + dimensions: + rank: 2 + dim: [[1, c], [2, d]] + + # this should be a ROI + bounding_box(NXcg_polyhedron_set): + doc: | + A tight bounding box or sphere or bounding primitive about the grid. + + # a good example for a general bounding box description for such a grids of triclinic cells + # https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallelepiped + number_of_boundaries(NX_POSINT): + unit: NX_UNITLESS + doc: | + How many distinct boundaries are distinguished? + Most grids discretize a cubic or cuboidal region. In this case + six sides can be distinguished, each making an own boundary. + boundaries: + doc: | + Name of domain boundaries of the simulation box/ROI e.g. left, right, + front, back, bottom, top. + + # The field must have as many entries as there are number_of_boundaries. + dimensions: + rank: 1 + dim: [[1, n_b]] + boundary_conditions(NX_INT): + unit: NX_UNITLESS + doc: | + The boundary conditions for each boundary: + + 0 - undefined + 1 - open + 2 - periodic + 3 - mirror + 4 - von Neumann + 5 - Dirichlet + dimensions: + rank: 1 + dim: [[1, n_b]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 4886eebe9a97fb5801d8ffb55af96f612ba6d26959398324cf07cde6b5aa7e66 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality of the grid. +# +# +# +# +# The cardinality or total number of cells/grid points. +# +# +# +# +# Number of boundaries of the bounding box or primitive to the grid. +# +# +# +# +# Computational geometry description of a Wigner-Seitz cell grid in Euclidean space. +# +# Frequently convenient three-dimensional grids with cubic cells are used. +# Exemplar applications are spectral-solver based crystal plasticity +# and stencil methods like phase-field or cellular automata. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The symmetry of the lattice defining the shape of the unit cell. +# +# +# +# +# +# +# +# The unit cell dimensions using crystallographic notation. +# +# +# +# +# +# +# +# Number of unit cells along each of the d unit vectors. +# The total number of cells, or grid points has to be the cardinality. +# If the grid has an irregular number of grid positions in each direction, +# as it could be for instance the case of a grid where all grid points +# outside some masking primitive are removed, this extent field should +# not be used. Instead use the coordinate field. +# +# +# +# +# +# +# +# Reference to or definition of a coordinate system with +# which the positions and directions are interpretable. +# +# +# +# +# +# Integer which specifies the first index to be used for distinguishing +# identifiers for cells. Identifiers are defined either implicitly +# or explicitly. For implicit indexing the identifiers are defined on the +# interval [identifier_offset, identifier_offset+c-1]. +# For explicit indexing the identifier array has to be defined. +# +# The identifier_offset field can for example be used to communicate if the +# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) +# or from 0 (referred to as C-, Python-style index notation) respectively. +# +# +# +# +# Integer used to distinguish cells for explicit indexing. +# +# +# +# +# +# +# +# Position of each cell in Euclidean space. +# +# +# +# +# +# +# +# +# Coordinate of each cell with respect to the discrete grid. +# +# +# +# +# +# +# +# +# +# A tight bounding box or sphere or bounding primitive about the grid. +# +# +# +# +# +# How many distinct boundaries are distinguished? +# Most grids discretize a cubic or cuboidal region. In this case +# six sides can be distinguished, each making an own boundary. +# +# +# +# +# Name of domain boundaries of the simulation box/ROI e.g. left, right, +# front, back, bottom, top. +# +# +# +# +# +# +# +# +# The boundary conditions for each boundary: +# +# 0 - undefined +# 1 - open +# 2 - periodic +# 3 - mirror +# 4 - von Neumann +# 5 - Dirichlet +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml b/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml new file mode 100644 index 0000000000..0527443d20 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml @@ -0,0 +1,307 @@ +category: base +doc: | + Computational geeometry description of a half-edge data structure. + + Such a data structure can be used to efficiently circulate around faces + and iterate over vertices of a planar graph. + +# holes in the polygon mesh can be handled +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality, which has to be at least 2. + n_v: | + The number of vertices. + n_f: | + The number of faces. + n_he: | + The number of half-edges. +type: group +NXcg_half_edge_data_structure(NXobject): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + number_of_vertices(NX_POSINT): + unit: NX_UNITLESS + number_of_faces(NX_POSINT): + unit: NX_UNITLESS + number_of_half_edges(NX_POSINT): + unit: NX_UNITLESS + vertex_identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + In this half-edge data structure vertex identifiers start at 1. + Vertices are identified with consecutive integers up to number_of_vertices. + This field can be used to document which constant integer has to be + added to another set of vertex_identifier to assure that these other + identifiers also start at 1. + face_identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + In this half-edge data structure face identifiers start at 1. + Faces are identified with consecutive integers up to number_of_faces. + This field can be used to document which constant integer has to be + added to another set of face_identifier to assure that these other + identifiers also start at 1. + + The face identifier zero is reserved for the NULL face ! + half_edge_identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + In this half-edge data structure half-edge identifiers start at 1. + Half-edges are identified with consecutive integers up to number_of_half_edges. + This field can be used to document which constant integer has to be + added to another set of half_edge_identifier to assure that these other + identifiers also start at 1. + + # therefore, vertex_-, face_-, half_edge_-identifier are implicit + position(NX_NUMBER): + unit: NX_LENGTH + doc: | + The position of the vertices. + dimensions: + rank: 2 + dim: [[1, n_v], [2, d]] + vertex_incident_half_edge(NX_UINT): + unit: NX_UNITLESS + doc: | + Identifier of the incident half-edge. + dimensions: + rank: 1 + dim: [[1, n_v]] + face_half_edge(NX_UINT): + unit: NX_UNITLESS + doc: | + Identifier of the (starting)/associated half-edge of the face. + dimensions: + rank: 1 + dim: [[1, n_f]] + half_edge_vertex_origin(NX_UINT): + unit: NX_UNITLESS + doc: | + The identifier of the vertex from which this half-edge is outwards pointing. + dimensions: + rank: 1 + dim: [[1, n_he]] + half_edge_twin(NX_UINT): + unit: NX_UNITLESS + doc: | + Identifier of the associated oppositely pointing half-edge. + dimensions: + rank: 1 + dim: [[1, n_he]] + half_edge_incident_face(NX_UINT): + unit: NX_UNITLESS + doc: | + If the half-edge is a boundary half-edge the + incident face identifier is NULL, i.e. 0. + dimensions: + rank: 1 + dim: [[1, n_he]] + half_edge_next(NX_UINT): + unit: NX_UNITLESS + doc: | + Identifier of the next half-edge. + dimensions: + rank: 1 + dim: [[1, n_he]] + half_edge_prev(NX_UINT): + unit: NX_UNITLESS + doc: | + Identifier of the previous half-edge. + dimensions: + rank: 1 + dim: [[1, n_he]] + weinberg_vector: + doc: | + Users are referred to the literature for the background of L. Weinberg's + work about topological characterization of planar graphs: + + * `L. Weinberg 1966a, `_ + * `L. Weinberg, 1966b, `_ + * `E. A. Lazar et al. `_ + + and how this work can e.g. be applied in space-filling tessellations + of microstructural objects like crystals/grains. + + # eventually store the Weinberg vector as an integer array + # which could be more efficient + # see https://jerryyin.info/geometry-processing-algorithms/half-edge/ + # for an illustrative example of half-edge data structures + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# a1e16e466863d2d22ed742e07e4a687882114b34f9aa0fae785f4d4f24577f62 +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality, which has to be at least 2. +# +# +# +# +# The number of vertices. +# +# +# +# +# The number of faces. +# +# +# +# +# The number of half-edges. +# +# +# +# +# Computational geeometry description of a half-edge data structure. +# +# Such a data structure can be used to efficiently circulate around faces +# and iterate over vertices of a planar graph. +# +# +# +# +# +# +# +# In this half-edge data structure vertex identifiers start at 1. +# Vertices are identified with consecutive integers up to number_of_vertices. +# This field can be used to document which constant integer has to be +# added to another set of vertex_identifier to assure that these other +# identifiers also start at 1. +# +# +# +# +# In this half-edge data structure face identifiers start at 1. +# Faces are identified with consecutive integers up to number_of_faces. +# This field can be used to document which constant integer has to be +# added to another set of face_identifier to assure that these other +# identifiers also start at 1. +# +# The face identifier zero is reserved for the NULL face ! +# +# +# +# +# In this half-edge data structure half-edge identifiers start at 1. +# Half-edges are identified with consecutive integers up to number_of_half_edges. +# This field can be used to document which constant integer has to be +# added to another set of half_edge_identifier to assure that these other +# identifiers also start at 1. +# +# +# +# +# +# The position of the vertices. +# +# +# +# +# +# +# +# +# Identifier of the incident half-edge. +# +# +# +# +# +# +# +# Identifier of the (starting)/associated half-edge of the face. +# +# +# +# +# +# +# +# The identifier of the vertex from which this half-edge is outwards pointing. +# +# +# +# +# +# +# +# Identifier of the associated oppositely pointing half-edge. +# +# +# +# +# +# +# +# If the half-edge is a boundary half-edge the +# incident face identifier is NULL, i.e. 0. +# +# +# +# +# +# +# +# Identifier of the next half-edge. +# +# +# +# +# +# +# +# Identifier of the previous half-edge. +# +# +# +# +# +# +# +# Users are referred to the literature for the background of L. Weinberg's +# work about topological characterization of planar graphs: +# +# * `L. Weinberg 1966a, <https://dx.doi.org/10.1109/TCT.1964.1082216>`_ +# * `L. Weinberg, 1966b, <https://dx.doi.org/10.1137/0114062>`_ +# * `E. A. Lazar et al. <https://doi.org/10.1103/PhysRevLett.109.095505>`_ +# +# and how this work can e.g. be applied in space-filling tessellations +# of microstructural objects like crystals/grains. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_hexahedron_set.yaml b/contributed_definitions/nyaml/NXcg_hexahedron_set.yaml new file mode 100644 index 0000000000..fa57d0ab4a --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_hexahedron_set.yaml @@ -0,0 +1,435 @@ +category: base +doc: | + Computational geometry description of a set of hexahedra in Euclidean space. + + The hexahedra do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe cuboids or cubes, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of specimens. In this case the alignment with axes is not relevant as + eventually the only relevant information to convey is the volume of the + specimen. + * In many cases, take for instance an experiment where a specimen was taken + from a specifically deformed piece of material, e.g. cold-rolled, + channel-die deformed, the orientation of the specimen edges with the + experiment coordinate system can be of very high relevance. + Examples include to know which specimen edge is parallel to the rolling, + the transverse, or the normal direction. + * Sufficient to pinpoint the sample and laboratory/experiment coordinate + system, the above-mentioned descriptions are not detailed enough though + to create a CAD model of the specimen. + * Therefore, groups and fields for an additional, computational-geometry- + based view of the hexahedra is offered which serve different computational + tasks: storage-oriented simple views or detailed topological/graph-based + descriptions. + + Hexahedra are important geometrical primitives, which are among the most + frequently used elements in finite element meshing/modeling. + + Hexahedra have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term hexahedra will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding + box (OBB). + + An axis-aligned bounding box is a common data object in + computational science and codes to represent a cuboid whose edges + are aligned with a coordinate system. As a part of binary trees these + are important data objects for time as well as space efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Exact and substantially faster in practice approximate algorithms + exist for computing optimal or near optimal bounding boxes for point sets. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + c: | + The cardinality of the set, i.e. the number of hexahedra. + +# it is useful to define own base classes for frequently used classes +# a polyhedron is a specific polytope in 3d, do we need +# higher-dimensional polytopes? that could be useful for simplicies though +# as they are used in numerics etc. maybe reach out here to our friends +# from MarDI, for now let's assume we do not need polytopes for d > 3 +type: group +NXcg_hexahedron_set(NXobject): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + enumeration: [3] + cardinality(NX_POSINT): + unit: NX_UNITLESS + + # qualifiers and properties of hexahedra + shape(NX_NUMBER): + unit: NX_LENGTH + doc: | + A qualitative description of each hexahedron/cuboid/cube/box. + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] + length(NX_NUMBER): + unit: NX_LENGTH + doc: | + Qualifier how one edge is longer than all other edges of the hexahedra. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + dimensions: + rank: 1 + dim: [[1, c]] + width(NX_NUMBER): + unit: NX_LENGTH + doc: | + Qualifier often used to describe the length of an edge within + a specific coordinate system. + dimensions: + rank: 1 + dim: [[1, c]] + height(NX_NUMBER): + unit: NX_LENGTH + doc: | + Qualifier often used to describe the length of an edge within + a specific coordinate system. + dimensions: + rank: 1 + dim: [[1, c]] + center(NX_NUMBER): + unit: NX_LENGTH + doc: | + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the hexahedrally-shaped sample/sample part. + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] + volume(NX_NUMBER): + unit: NX_VOLUME + dimensions: + rank: 1 + dim: [[1, c]] + surface_area(NX_NUMBER): + unit: NX_AREA + doc: | + Total area (of all six faces) of each hexahedron. + dimensions: + rank: 1 + dim: [[1, c]] + face_area(NX_NUMBER): + unit: NX_AREA + doc: | + Area of each of the six faces of each hexahedron. + dimensions: + rank: 2 + dim: [[1, c], [2, 6]] + is_box(NX_BOOLEAN): + doc: | + Specifies if the hexahedra represent cuboids or cubes eventually rotated + ones but at least not too exotic six-faced polyhedra. + dimensions: + rank: 1 + dim: [[1, c]] + is_axis_aligned(NX_BOOLEAN): + doc: | + Only to be used if is_box is present. In this case, this field describes + whether hexahedra are boxes whose primary edges are parallel to the + axes of the Cartesian coordinate system. + dimensions: + rank: 1 + dim: [[1, c]] + (NXtransformations): + doc: | + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + identifier(NX_INT): + unit: NX_UNITLESS + doc: | + Integer used to distinguish hexahedra for explicit indexing. + dimensions: + rank: 1 + dim: [[1, c]] + + # substantially more detailed descriptors of the shape, the mesh + orientation(NXorientation_set): + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + + # detailed mesh-based representation + hexahedra(NXcg_face_list_data_structure): + + # exists: [min, 0, max, 1] + doc: | + A simple approach to describe the entire set of hexahedra when the + main intention is to store the shape of the hexahedra for visualization. + hexahedron(NXcg_face_list_data_structure): + + # exists: [min, 0, max, infty] # can this be max, c? + doc: | + Disentangled representations of the mesh of specific hexahedra. + hexahedron_half_edge(NXcg_half_edge_data_structure): + + # exists: [min, 0, max, infty] + doc: | + Disentangled representation of the planar graph that each hexahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e7f1ec6a5d54109c7bc0ba78a22fb2728a91bdd88f3cc2aa9bb8b70d37249c35 +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The cardinality of the set, i.e. the number of hexahedra. +# +# +# +# +# Computational geometry description of a set of hexahedra in Euclidean space. +# +# The hexahedra do not have to be connected, can have different size, +# can intersect, and be rotated. +# This class can also be used to describe cuboids or cubes, axis-aligned or not. +# The class represents different access and description levels to offer both +# applied scientists and computational geometry experts to use the same +# base class but rather their specific view on the data: +# +# * Most simple many experimentalists wish to communicate dimensions/the size +# of specimens. In this case the alignment with axes is not relevant as +# eventually the only relevant information to convey is the volume of the +# specimen. +# * In many cases, take for instance an experiment where a specimen was taken +# from a specifically deformed piece of material, e.g. cold-rolled, +# channel-die deformed, the orientation of the specimen edges with the +# experiment coordinate system can be of very high relevance. +# Examples include to know which specimen edge is parallel to the rolling, +# the transverse, or the normal direction. +# * Sufficient to pinpoint the sample and laboratory/experiment coordinate +# system, the above-mentioned descriptions are not detailed enough though +# to create a CAD model of the specimen. +# * Therefore, groups and fields for an additional, computational-geometry- +# based view of the hexahedra is offered which serve different computational +# tasks: storage-oriented simple views or detailed topological/graph-based +# descriptions. +# +# Hexahedra are important geometrical primitives, which are among the most +# frequently used elements in finite element meshing/modeling. +# +# Hexahedra have to be non-degenerated, closed, and built of polygons +# which are not self-intersecting. +# +# The term hexahedra will be used throughout this base class but includes +# the especially in engineering and more commonly used special cases, +# cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding +# box (OBB). +# +# An axis-aligned bounding box is a common data object in +# computational science and codes to represent a cuboid whose edges +# are aligned with a coordinate system. As a part of binary trees these +# are important data objects for time as well as space efficient queries +# of geometric primitives in techniques like kd-trees. +# +# An optimal bounding box is a common data object which provides the best +# tight fitting box about an arbitrary object. In general such boxes are +# rotated. Exact and substantially faster in practice approximate algorithms +# exist for computing optimal or near optimal bounding boxes for point sets. +# +# +# +# +# +# +# +# +# +# +# A qualitative description of each hexahedron/cuboid/cube/box. +# +# +# +# +# +# +# +# +# Qualifier how one edge is longer than all other edges of the hexahedra. +# Often the term length is associated with one edge being parallel to +# an axis of the coordinate system. +# +# +# +# +# +# +# +# Qualifier often used to describe the length of an edge within +# a specific coordinate system. +# +# +# +# +# +# +# +# Qualifier often used to describe the length of an edge within +# a specific coordinate system. +# +# +# +# +# +# +# +# Position of the geometric center, which often is but not necessarily +# has to be the center_of_mass of the hexahedrally-shaped sample/sample part. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Total area (of all six faces) of each hexahedron. +# +# +# +# +# +# +# +# Area of each of the six faces of each hexahedron. +# +# +# +# +# +# +# +# +# Specifies if the hexahedra represent cuboids or cubes eventually rotated +# ones but at least not too exotic six-faced polyhedra. +# +# +# +# +# +# +# +# Only to be used if is_box is present. In this case, this field describes +# whether hexahedra are boxes whose primary edges are parallel to the +# axes of the Cartesian coordinate system. +# +# +# +# +# +# +# +# Reference to or definition of a coordinate system with +# which the qualifiers and mesh data are interpretable. +# +# +# +# +# Integer which specifies the first index to be used for distinguishing +# hexahedra. Identifiers are defined either implicitly +# or explicitly. For implicit indexing the identifiers are defined on the +# interval [identifier_offset, identifier_offset+c-1]. +# For explicit indexing the identifier array has to be defined. +# +# The identifier_offset field can for example be used to communicate if the +# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) +# or from 0 (referred to as C-, Python-style index notation) respectively. +# +# +# +# +# Integer used to distinguish hexahedra for explicit indexing. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# A simple approach to describe the entire set of hexahedra when the +# main intention is to store the shape of the hexahedra for visualization. +# +# +# +# +# +# Disentangled representations of the mesh of specific hexahedra. +# +# +# +# +# +# Disentangled representation of the planar graph that each hexahedron +# represents. Such a description simplifies topological processing +# or analyses of mesh primitive operations and neighborhood queries. +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_marching_cubes.yaml b/contributed_definitions/nyaml/NXcg_marching_cubes.yaml new file mode 100644 index 0000000000..52190a7907 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_marching_cubes.yaml @@ -0,0 +1,119 @@ +category: base +doc: | + Computational geometry description of the marching cubes algorithm. + + Documenting which specific version was used can help to understand how robust + the results are with respect to the topology of the triangulation. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXcg_marching_cubes(NXobject): + grid(NXcg_grid): + doc: | + Reference/link to and/or details of the grid on which a specific + marching cubes algorithm implementation is operating. + implementation: + doc: | + Reference to the specific implementation of marching cubes used. + + See for example the following papers for details about how to identify a + DOI which specifies the implementation used: + + * `W. E. Lorensen `_ + * `T. S. Newman and H. Yi `_ + + The value placed here should be a DOI. If there are no specific DOI or + details write not_further_specified, or give at least a free-text + description. + program: + doc: | + Commercial or otherwise given name to the program which was used. + \@version: + doc: | + Program version plus build number, commit hash, or description of + an ever persistent resource where the source code of the program + and build instructions can be found so that the program can be + configured in such a manner that the result file is ideally + recreatable yielding the same results. + + # we could also think about storing the rule sets in here explicitly including the + # coordinate system conventions; however, the problem is that many commercial + # tools like Matlab do not expose the rule set. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 3b2f3175033e3606a1be9aa4a65ca8956002ee92cea2600c3c725eb1c3c754eb +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Computational geometry description of the marching cubes algorithm. +# +# Documenting which specific version was used can help to understand how robust +# the results are with respect to the topology of the triangulation. +# +# +# +# Reference/link to and/or details of the grid on which a specific +# marching cubes algorithm implementation is operating. +# +# +# +# +# Reference to the specific implementation of marching cubes used. +# +# See for example the following papers for details about how to identify a +# DOI which specifies the implementation used: +# +# * `W. E. Lorensen <https://doi.org/10.1109/MCG.2020.2971284>`_ +# * `T. S. Newman and H. Yi <https://doi.org/10.1016/j.cag.2006.07.021>`_ +# +# The value placed here should be a DOI. If there are no specific DOI or +# details write not_further_specified, or give at least a free-text +# description. +# +# +# +# +# Commercial or otherwise given name to the program which was used. +# +# +# +# Program version plus build number, commit hash, or description of +# an ever persistent resource where the source code of the program +# and build instructions can be found so that the program can be +# configured in such a manner that the result file is ideally +# recreatable yielding the same results. +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_parallelogram_set.yaml b/contributed_definitions/nyaml/NXcg_parallelogram_set.yaml new file mode 100644 index 0000000000..0b3fca5afa --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_parallelogram_set.yaml @@ -0,0 +1,330 @@ +category: base +doc: | + Computational geometry description of a set of parallelograms in Euclidean space. + + The parallelograms do not have to be connected, can have different size, + can intersect, and be rotated. + This class can also be used to describe rectangles or squares, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts to use the same + base class but rather their specific view on the data: + + * Most simple many experimentalists wish to communicate dimensions/the size + of e.g. a region of interest in the 2D plane. In this case the alignment + with axes is not relevant as eventually relevant is only the area of the ROI. + * In other cases the extent of the parallelogram is relevant though. + * Finally in CAD models we would like to specify the polygon + which is parallelogram represents. + + Parallelograms are important geometrical primitives. Not so much because of their + uses in nowadays, thanks to improvements in computing power, not so frequently + any longer performed 2D simulation. Many scanning experiments probe though + parallelogram-shaped ROIs on the surface of samples. + + Parallelograms have to be non-degenerated, closed, and built of polygons + which are not self-intersecting. + + The term parallelogram will be used throughout this base class but includes + the especially in engineering and more commonly used special cases, + rectangle, square, 2D box, axis-aligned bounding box (AABB), or + optimal bounding box (OBB) but here the analogous 2D cases. + + An axis-aligned bounding box is a common data object in computational science + and codes to represent a rectangle whose edges are aligned with the axes + of a coordinate system. As a part of binary trees these are important data + objects for time- as well as space-efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tight fitting box about an arbitrary object. In general such boxes are + rotated. Other than in 3D dimensions the rotation calipher method offers + a rigorous approach to compute optimal bounding boxes in 2D. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + c: | + The cardinality of the set, i.e. the number of parallelograms. +type: group +NXcg_parallelogram_set(NXobject): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + enumeration: [2] + cardinality(NX_POSINT): + unit: NX_UNITLESS + + # qualifiers and properties of parallelograms + shape(NX_NUMBER): + unit: NX_LENGTH + doc: | + A qualitative description of each parallelogram/rectangle/square/box. + dimensions: + rank: 2 + dim: [[1, c], [2, 2]] + length(NX_NUMBER): + unit: NX_LENGTH + doc: | + Qualifier how one edge is longer than all the other edge of the parallelogam. + Often the term length is associated with one edge being parallel to + an axis of the coordinate system. + dimensions: + rank: 1 + dim: [[1, c]] + width(NX_NUMBER): + unit: NX_LENGTH + doc: | + Qualifier often used to describe the length of an edge within + a specific coordinate system. + dimensions: + rank: 1 + dim: [[1, c]] + center(NX_NUMBER): + unit: NX_LENGTH + doc: | + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the parallelogram. + dimensions: + rank: 2 + dim: [[1, c], [2, 2]] + surface_area(NX_NUMBER): + unit: NX_AREA + dimensions: + rank: 1 + dim: [[1, c]] + is_axis_aligned(NX_BOOLEAN): + doc: | + Only to be used if is_box is present. In this case, this field describes + whether parallelograms are rectangles/squares whose primary edges + are parallel to the axes of the Cartesian coordinate system. + dimensions: + rank: 1 + dim: [[1, c]] + (NXtransformations): + doc: | + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for distinguishing + parallelograms. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + identifier(NX_INT): + unit: NX_UNITLESS + doc: | + Integer used to distinguish parallelograms for explicit indexing. + dimensions: + rank: 1 + dim: [[1, c]] + + # substantially more detailed descriptors of the shape, the mesh + orientation(NXorientation_set): + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + + # detailed mesh-based representation + parallelograms(NXcg_face_list_data_structure): + + # exists: [min, 0, max, 1] + doc: | + A simple approach to describe the entire set of parallelograms when the + main intention is to store the shape of the parallelograms for visualization. + parallelogram(NXcg_face_list_data_structure): + + # exists: [min, 0, max, infty] # can this be max, c? + doc: | + Disentangled representations of the mesh of specific parallelograms. + + ##MK::a half-edge structure would be overkill as this is a simple primitive + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 5d1302fcf7b789f052eacff219eeab4f7d7be114f56b4a59ce5a604a8e867099 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The cardinality of the set, i.e. the number of parallelograms. +# +# +# +# +# Computational geometry description of a set of parallelograms in Euclidean space. +# +# The parallelograms do not have to be connected, can have different size, +# can intersect, and be rotated. +# This class can also be used to describe rectangles or squares, axis-aligned or not. +# The class represents different access and description levels to offer both +# applied scientists and computational geometry experts to use the same +# base class but rather their specific view on the data: +# +# * Most simple many experimentalists wish to communicate dimensions/the size +# of e.g. a region of interest in the 2D plane. In this case the alignment +# with axes is not relevant as eventually relevant is only the area of the ROI. +# * In other cases the extent of the parallelogram is relevant though. +# * Finally in CAD models we would like to specify the polygon +# which is parallelogram represents. +# +# Parallelograms are important geometrical primitives. Not so much because of their +# uses in nowadays, thanks to improvements in computing power, not so frequently +# any longer performed 2D simulation. Many scanning experiments probe though +# parallelogram-shaped ROIs on the surface of samples. +# +# Parallelograms have to be non-degenerated, closed, and built of polygons +# which are not self-intersecting. +# +# The term parallelogram will be used throughout this base class but includes +# the especially in engineering and more commonly used special cases, +# rectangle, square, 2D box, axis-aligned bounding box (AABB), or +# optimal bounding box (OBB) but here the analogous 2D cases. +# +# An axis-aligned bounding box is a common data object in computational science +# and codes to represent a rectangle whose edges are aligned with the axes +# of a coordinate system. As a part of binary trees these are important data +# objects for time- as well as space-efficient queries +# of geometric primitives in techniques like kd-trees. +# +# An optimal bounding box is a common data object which provides the best +# tight fitting box about an arbitrary object. In general such boxes are +# rotated. Other than in 3D dimensions the rotation calipher method offers +# a rigorous approach to compute optimal bounding boxes in 2D. +# +# +# +# +# +# +# +# +# +# +# A qualitative description of each parallelogram/rectangle/square/box. +# +# +# +# +# +# +# +# +# Qualifier how one edge is longer than all the other edge of the parallelogam. +# Often the term length is associated with one edge being parallel to +# an axis of the coordinate system. +# +# +# +# +# +# +# +# Qualifier often used to describe the length of an edge within +# a specific coordinate system. +# +# +# +# +# +# +# +# Position of the geometric center, which often is but not necessarily +# has to be the center_of_mass of the parallelogram. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Only to be used if is_box is present. In this case, this field describes +# whether parallelograms are rectangles/squares whose primary edges +# are parallel to the axes of the Cartesian coordinate system. +# +# +# +# +# +# +# +# Reference to or definition of a coordinate system with +# which the qualifiers and mesh data are interpretable. +# +# +# +# +# Integer which specifies the first index to be used for distinguishing +# parallelograms. Identifiers are defined either implicitly +# or explicitly. For implicit indexing the identifiers are defined on the +# interval [identifier_offset, identifier_offset+c-1]. +# For explicit indexing the identifier array has to be defined. +# +# The identifier_offset field can for example be used to communicate if the +# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) +# or from 0 (referred to as C-, Python-style index notation) respectively. +# +# +# +# +# Integer used to distinguish parallelograms for explicit indexing. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# A simple approach to describe the entire set of parallelograms when the +# main intention is to store the shape of the parallelograms for visualization. +# +# +# +# +# +# Disentangled representations of the mesh of specific parallelograms. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_point_set.yaml b/contributed_definitions/nyaml/NXcg_point_set.yaml new file mode 100644 index 0000000000..d1ab1daab5 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_point_set.yaml @@ -0,0 +1,163 @@ +category: base +doc: | + Computational geometry description of a set of points in Euclidean space. + + The relevant coordinate system should be referred to in the NXtransformations + instance. Points may have an associated time value; however users are advised + to store time data of point sets rather as instances of time events, where + for each point in time there is an NXcg_point_set instance which specifies the + points locations. This is a frequent situation in experiments and computer + simulations, where positions of points are taken at the same point in time; + and therefore an additional time array would demand to store redundant pieces + of information for each point. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality, which has to be at least 1. + c: | + The cardinality of the set, i.e. the number of points. +type: group +NXcg_point_set(NXobject): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + cardinality(NX_POSINT): + unit: NX_UNITLESS + identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for distinguishing + identifiers for points. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + identifier(NX_INT): + unit: NX_UNITLESS + doc: | + Integer used to distinguish points for explicit indexing. + dimensions: + rank: 1 + dim: [[1, c]] + position(NX_NUMBER): + unit: NX_LENGTH + doc: | + The array of point coordinates. + dimensions: + rank: 2 + dim: [[1, c], [2, d]] + time(NX_NUMBER): + unit: NX_TIME + doc: | + The optional array of time for each vertex. + dimensions: + rank: 1 + dim: [[1, c]] + (NXtransformations): + doc: | + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# ba461c2c50dd1946cfc43481d91672fa5fcb318025c70ac45b767965d960de12 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality, which has to be at least 1. +# +# +# +# +# The cardinality of the set, i.e. the number of points. +# +# +# +# +# Computational geometry description of a set of points in Euclidean space. +# +# The relevant coordinate system should be referred to in the NXtransformations +# instance. Points may have an associated time value; however users are advised +# to store time data of point sets rather as instances of time events, where +# for each point in time there is an NXcg_point_set instance which specifies the +# points locations. This is a frequent situation in experiments and computer +# simulations, where positions of points are taken at the same point in time; +# and therefore an additional time array would demand to store redundant pieces +# of information for each point. +# +# +# +# +# +# Integer which specifies the first index to be used for distinguishing +# identifiers for points. Identifiers are defined either implicitly +# or explicitly. For implicit indexing the identifiers are defined on the +# interval [identifier_offset, identifier_offset+c-1]. +# For explicit indexing the identifier array has to be defined. +# +# The identifier_offset field can for example be used to communicate if the +# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) +# or from 0 (referred to as C-, Python-style index notation) respectively. +# +# +# +# +# Integer used to distinguish points for explicit indexing. +# +# +# +# +# +# +# +# The array of point coordinates. +# +# +# +# +# +# +# +# +# The optional array of time for each vertex. +# +# +# +# +# +# +# +# Reference to or definition of a coordinate system with +# which the positions and directions are interpretable. +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_polygon_set.yaml b/contributed_definitions/nyaml/NXcg_polygon_set.yaml new file mode 100644 index 0000000000..9ab3ec4446 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_polygon_set.yaml @@ -0,0 +1,409 @@ +category: base + +# somewhat redundant as there is NXoff_geometry but easier to understand +doc: | + Computational geometry description of a set of polygons in Euclidean space. + + Polygons are related are specialized polylines: + + * A polygon is a geometric primitive that is bounded by a closed polyline + * All vertices of this polyline lay in the d-1 dimensional plane. + whereas vertices of a polyline do not necessarily lay on a plane. + * A polygon has at least three vertices. + + Each polygon is built from a sequence of vertices (points with identifiers). + The members of a set of polygons may have a different number of vertices. + Sometimes a collection/set of polygons is referred to as a soup of polygons. + + As three-dimensional objects, a set of polygons can be used to define the + hull of what is effectively a polyhedron; however users are advised to use + the specific NXcg_polyhedron_set base class if they wish to describe closed + polyhedra. Even more general complexes can be thought, for instance + piecewise-linear complexes, as these can have holes though, polyhedra without + holes are one subclass of such complexes, users should rather design an own + base class e.g. NXcg_polytope_set to describe such even more + complex primitives. + +# Users can take advantage of NXcg_polygon_set to describe such complexes +# when using the defines_plc and related topological and boundary constraint +# descriptors. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality, which has to be either 2 or 3. + c: | + The cardinality of the set, i.e. the number of polygons. + + # n_unique: Number of unique points supporting the polygons. + n_total: | + The total number of vertices when visiting every polygon. +type: group +NXcg_polygon_set(NXobject): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + enumeration: [2, 3] + cardinality(NX_POSINT): + unit: NX_UNITLESS + number_of_total_vertices(NX_POSINT): + unit: NX_UNITLESS + identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for distinguishing + polygons. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + identifier(NX_INT): + unit: NX_UNITLESS + doc: | + Integer used to distinguish polygons for explicit indexing. + dimensions: + rank: 1 + dim: [[1, c]] + polygons(NXcg_face_list_data_structure): + + # exists: [min, 0, max, 1] + doc: | + A simple approach to describe the entire set of polygons when the + main intention is to store the shape of the polygons for visualization. + + # detailed additional information eventually mesh-related data + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + + # triangles_half_edge(NXcg_half_edge_data_structure): + # properties of the polygon primitives + area(NX_NUMBER): + unit: NX_AREA + dimensions: + rank: 1 + dim: [[1, c]] + edge_length(NX_NUMBER): + unit: NX_LENGTH + doc: | + The accumulated length of the polygon edge. + dimensions: + rank: 1 + dim: [[1, c]] + interior_angle(NX_NUMBER): + unit: NX_ANGLE + doc: | + Array of interior angles. There are many values per polygon as number_of_vertices. + The angle is the angle at the specific vertex, i.e. between the adjoining + edges of the vertex according to the sequence in the polygons array. + Usually, the winding_order field is required to interpret the value. + dimensions: + rank: 1 + dim: [[1, n_total]] + shape(NX_INT): + unit: NX_UNITLESS + doc: | + Curvature type: + + * 0 - unspecified, + * 1 - convex, + * 2 - concave + dimensions: + rank: 1 + dim: [[1, c]] + center(NX_NUMBER): + unit: NX_LENGTH + doc: | + The center of mass of each polygon. + dimensions: + rank: 2 + dim: [[1, c], [2, d]] + bounding_box(NXcg_hexahedron_set): + doc: | + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + + ##MK::ROI about the set ? + # a set of polygons can be interpreted as a descriptor for an object + # an, in TetGen terminology, piecewise-linear complex + # defines_plc(NX_BOOLEAN): + # doc: True, if the set describes a piecewise-linear complex. + ##MK::each polygon could be given a role with respect to what the polygon + ##MK::represents of the complex, this would allow to define a complex with + ##MK::holes + # vertices(NXcg_point_set): + # doc: | + # The set of vertices supporting the polygons. + # The dimensionality of the point set and this polygon set are the same. + # The number of vertices is arbitrary because polygons may different in + # their number of edges. + # Like it is the case for NXcg_triangle_set instances, individual + # polygons may make edge contact in which case a lower number of vertices + # suffices than naively expected from a summation of the edges. + # Users are encouraged to reduce the vertex set to a set of unique vertices + # as this can often turn out to allow for a more efficient storage + # of the geometry data. It is also possible though to store + # the vertices naively in which case vertices_are_unique is likely False. + # vertices_are_unique(NX_BOOLEAN): + # doc: | + # If true indicates that the vertices are all placed at different positions + # and have different identifiers, i.e. no points overlap or are counted twice. + # number_of_vertices(NX_POSINT): + # doc: | + # Array which specifies of how many vertices each polygon is built. + # The number of vertices represent the total number of vertices for + # each polygon, irrespectively whether vertices are shared or not. + # See the docstring for polygons for further details about how + # a set with different polyline members should be stored. + # unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dimensions: [[1, c]] + # ##MK::there is nothing like value constraints... or minimum bitdepth + # polygons(NX_INT): + # doc: | + # Array of identifiers from vertices which describe each polygon. + # The first entry is the identifier of the start vertex of the first polyline, + # followed by the second vertex of the first polyline, until the last vertex + # of the polyline. Thereafter, the start vertex of the second polyline, and + # so on and so forth. Using the (cumulated) counts in number_of_vertices, + # the vertices of the n-th polyline can be accessed on the following + # array index interval: + # [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + # Users are advised to store the vertex identifiers, if possible and + # ideally then for all of them, according to and using winding order. + # If the winding_order field is given, it has to report the specific winding + # order used. + # unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, n_total]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# d4221d5954c870bd03fdeca1f3ea6cfacb5ab7ca0647976253c5119e675f4ef7 +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality, which has to be either 2 or 3. +# +# +# +# +# The cardinality of the set, i.e. the number of polygons. +# +# +# +# +# +# The total number of vertices when visiting every polygon. +# +# +# +# +# +# Computational geometry description of a set of polygons in Euclidean space. +# +# Polygons are related are specialized polylines: +# +# * A polygon is a geometric primitive that is bounded by a closed polyline +# * All vertices of this polyline lay in the d-1 dimensional plane. +# whereas vertices of a polyline do not necessarily lay on a plane. +# * A polygon has at least three vertices. +# +# Each polygon is built from a sequence of vertices (points with identifiers). +# The members of a set of polygons may have a different number of vertices. +# Sometimes a collection/set of polygons is referred to as a soup of polygons. +# +# As three-dimensional objects, a set of polygons can be used to define the +# hull of what is effectively a polyhedron; however users are advised to use +# the specific NXcg_polyhedron_set base class if they wish to describe closed +# polyhedra. Even more general complexes can be thought, for instance +# piecewise-linear complexes, as these can have holes though, polyhedra without +# holes are one subclass of such complexes, users should rather design an own +# base class e.g. NXcg_polytope_set to describe such even more +# complex primitives. +# +# +# +# +# +# +# +# +# +# +# +# Integer which specifies the first index to be used for distinguishing +# polygons. Identifiers are defined either implicitly +# or explicitly. For implicit indexing the identifiers are defined on the +# interval [identifier_offset, identifier_offset+c-1]. +# For explicit indexing the identifier array has to be defined. +# +# The identifier_offset field can for example be used to communicate if the +# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) +# or from 0 (referred to as C-, Python-style index notation) respectively. +# +# +# +# +# Integer used to distinguish polygons for explicit indexing. +# +# +# +# +# +# +# +# +# A simple approach to describe the entire set of polygons when the +# main intention is to store the shape of the polygons for visualization. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The accumulated length of the polygon edge. +# +# +# +# +# +# +# +# Array of interior angles. There are many values per polygon as number_of_vertices. +# The angle is the angle at the specific vertex, i.e. between the adjoining +# edges of the vertex according to the sequence in the polygons array. +# Usually, the winding_order field is required to interpret the value. +# +# +# +# +# +# +# +# Curvature type: +# +# * 0 - unspecified, +# * 1 - convex, +# * 2 - concave +# +# +# +# +# +# +# +# The center of mass of each polygon. +# +# +# +# +# +# +# +# +# Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_polyhedron_set.yaml b/contributed_definitions/nyaml/NXcg_polyhedron_set.yaml new file mode 100644 index 0000000000..893e71fb03 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_polyhedron_set.yaml @@ -0,0 +1,345 @@ +category: base +doc: | + Computational geometry description of a polyhedra in Euclidean space. + + Polyhedra, also so-called cells (especially in the convex of tessellations), + here described have to be all non-degenerated, closed, built of and thus + built out of not-self-intersecting polygon meshes. Polyhedra may make contact, + so that this base class can be used for a future description of tessellations. + + For more complicated manifolds and especially for polyhedra with holes, users + are advised to check if their particular needs are described by creating + (eventually customized) instances of an NXcg_polygon_set, which can be + extended for the description of piecewise-linear complexes. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + c: | + The cardinality of the set, i.e. the number of polyhedra. + n_e_total: | + The total number of edges for all polyhedra. + n_f_total: | + The total number of faces for all polyhedra. + +# it is useful to define own base classes for frequently used classes +# a polyhedron is a specific polytope in 3d, do we need +# higher-dimensional polytopes? that could be useful for simplicies though +# as they are used in numerics etc. maybe reach out here to our friends +# from MarDI, for now let's assume we do not need polytopes for d > 3 +# NeXus already supports polyhedra via NXoff_geometry +# the here proposed base class extends the capabilities to qualifiers of +# polyhedra and also half_edge_data_structures that can be useful +# for clean graph-based descriptions of polyhedra. +type: group +NXcg_polyhedron_set(NXobject): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + enumeration: [3] + cardinality(NX_POSINT): + unit: NX_UNITLESS + + # qualifiers and properties of polyhedra + volume(NX_NUMBER): + unit: NX_VOLUME + doc: | + Interior volume + dimensions: + rank: 1 + dim: [[1, c]] + center(NX_NUMBER): + unit: NX_LENGTH + doc: | + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the polyhedra. + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] + surface_area(NX_NUMBER): + unit: NX_AREA + doc: | + Total surface area as the sum of all faces. + dimensions: + rank: 1 + dim: [[1, c]] + number_of_faces(NX_POSINT): + unit: NX_UNITLESS + doc: | + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. This field can be used to interpret + the array/field with the individual area values for each face. + dimensions: + rank: 1 + dim: [[1, c]] + face_area(NX_NUMBER): + unit: NX_AREA + doc: | + Area of each of the four triangular faces of each tetrahedron. + dimensions: + rank: 1 + dim: [[1, n_f_total]] + number_of_edges(NX_POSINT): + doc: | + The number of edges for each polyhedron. Edges of adjoining polyhedra + are counterd for each polyhedron. This field can be used to interpret + the array/field with the individual length for each edge. + edge_length(NX_NUMBER): + unit: NX_LENGTH + doc: | + Length of each edge of each tetrahedron. + dimensions: + rank: 1 + dim: [[1, n_e_total]] + (NXtransformations): + doc: | + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + # substantially more detailed descriptors of the shape, the mesh + identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for distinguishing + polyhedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + identifier(NX_INT): + unit: NX_UNITLESS + doc: | + Integer used to distinguish polyhedra for explicit indexing. + dimensions: + rank: 1 + dim: [[1, c]] + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + + # detailed mesh-based representation + polyhedra(NXcg_face_list_data_structure): + + # exists: [min, 0, max, 1] + doc: | + A simple approach to describe the entire set of polyhedra when the + main intention is to store the shape of the polyhedra for visualization. + polyhedron(NXcg_face_list_data_structure): + + # exists: [min, 0, max, infty] # can this be max, c? + doc: | + Disentangled representations of the mesh of specific polyhedron. + polyhedron_half_edge(NXcg_half_edge_data_structure): + + # exists: [min, 0, max, infty] + doc: | + Disentangled representation of the planar graph that each polyhedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + + # face_type(NX_UINT): #maybe a better name maybe topology, although this is misleading for the above-mentioned reasons + # doc: A concatenated array, for each polygon face the number of vertices. + # unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, nfaces]] + # intersections between members? as a graph + # contact with external primitives like simulation domain etc + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 78849fd106ffb653e79c194e88de9fe74b1e717137b485992c7cde42bf186241 +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The cardinality of the set, i.e. the number of polyhedra. +# +# +# +# +# The total number of edges for all polyhedra. +# +# +# +# +# The total number of faces for all polyhedra. +# +# +# +# +# Computational geometry description of a polyhedra in Euclidean space. +# +# Polyhedra, also so-called cells (especially in the convex of tessellations), +# here described have to be all non-degenerated, closed, built of and thus +# built out of not-self-intersecting polygon meshes. Polyhedra may make contact, +# so that this base class can be used for a future description of tessellations. +# +# For more complicated manifolds and especially for polyhedra with holes, users +# are advised to check if their particular needs are described by creating +# (eventually customized) instances of an NXcg_polygon_set, which can be +# extended for the description of piecewise-linear complexes. +# +# +# +# +# +# +# +# +# +# +# Interior volume +# +# +# +# +# +# +# +# Position of the geometric center, which often is but not necessarily +# has to be the center_of_mass of the polyhedra. +# +# +# +# +# +# +# +# +# Total surface area as the sum of all faces. +# +# +# +# +# +# +# +# The number of faces for each polyhedron. Faces of adjoining polyhedra +# are counted for each polyhedron. This field can be used to interpret +# the array/field with the individual area values for each face. +# +# +# +# +# +# +# +# Area of each of the four triangular faces of each tetrahedron. +# +# +# +# +# +# +# +# The number of edges for each polyhedron. Edges of adjoining polyhedra +# are counterd for each polyhedron. This field can be used to interpret +# the array/field with the individual length for each edge. +# +# +# +# +# Length of each edge of each tetrahedron. +# +# +# +# +# +# +# +# Reference to or definition of a coordinate system with +# which the qualifiers and mesh data are interpretable. +# +# +# +# +# +# Integer which specifies the first index to be used for distinguishing +# polyhedra. Identifiers are defined either implicitly +# or explicitly. For implicit indexing the identifiers are defined on the +# interval [identifier_offset, identifier_offset+c-1]. +# For explicit indexing the identifier array has to be defined. +# +# The identifier_offset field can for example be used to communicate if the +# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) +# or from 0 (referred to as C-, Python-style index notation) respectively. +# +# +# +# +# Integer used to distinguish polyhedra for explicit indexing. +# +# +# +# +# +# +# +# +# +# +# +# +# A simple approach to describe the entire set of polyhedra when the +# main intention is to store the shape of the polyhedra for visualization. +# +# +# +# +# +# Disentangled representations of the mesh of specific polyhedron. +# +# +# +# +# +# Disentangled representation of the planar graph that each polyhedron +# represents. Such a description simplifies topological processing +# or analyses of mesh primitive operations and neighborhood queries. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_polyline_set.yaml b/contributed_definitions/nyaml/NXcg_polyline_set.yaml new file mode 100644 index 0000000000..c54258c4cf --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_polyline_set.yaml @@ -0,0 +1,324 @@ +category: base +doc: | + Computational geometry description of a set of polylines in Euclidean space. + + Each polyline is built from a sequence of vertices (points with identifiers). + Each polyline must have a start and an end point. + The sequence describes the positive traversal along the polyline when walking + from the start vertex to the end/last vertex. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality, which has to be at least 1. + c: | + The cardinality of the set, i.e. the number of polylines. + + # n_unique: The number of unique vertices supporting the polyline. + # multiple vertices possible with the same point coordinates but different names. + n_v: | + The number of vertices, supporting the polylines. + n_total: | + The total number of vertices traversed when visiting every polyline. +type: group +NXcg_polyline_set(NXobject): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + cardinality(NX_POSINT): + unit: NX_UNITLESS + + # number_of_unique_vertices(NX_POSINT): + # unit: NX_UNITLESS + number_of_total_vertices(NX_POSINT): + unit: NX_UNITLESS + doc: | + The total number of vertices, irrespective of their eventual uniqueness, + i.e. the total number of vertices that have to be visited when walking + along each polyline. + number_of_vertices(NX_POSINT): + unit: NX_UNITLESS + doc: | + Array which specifies of how many vertices each polyline is built. + The number of vertices represent the total number of vertices for + each polyline, irrespectively whether vertices are shared or not. + See the docstring for polylines for further details about how + a set with different polyline members should be stored. + dimensions: + rank: 1 + dim: [[1, c]] + (NXtransformations): + doc: | + Reference to or definition of a coordinate system with + which the qualifiers and polyline data are interpretable. + identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for distinguishing + polylines. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + identifier(NX_INT): + unit: NX_UNITLESS + doc: | + Integer used to distinguish polylines for explicit indexing. + dimensions: + rank: 1 + dim: [[1, c]] + + # Users are encouraged to reduce the vertex set to the unique vertices. + # Unique means not necessarily unique in position only but also unique in + # identifier. In fact, it is possible to distinguish two vertices as two when + # they share the same position in space but have different identifiers. + vertices(NX_NUMBER): + unit: NX_LENGTH + doc: | + Positions of the vertices which support the members of the polyline set. + + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + dimensions: + rank: 2 + dim: [[1, n_v], [2, d]] + vertices_are_unique(NX_BOOLEAN): + doc: | + If true indicates that the vertices are all placed at different + positions and have different identifiers, i.e. no points overlap + or are counted twice. + polylines(NX_INT): + unit: NX_UNITLESS + doc: | + Sequence of vertex identifiers which describe each polyline. + + A trivial example is a set with two polylines with three vertices each. + If the polylines meet in a junction, say the second vertex is shared + and marking the junction between the two polylines, it is possible that + there are only five unique positions suggesting five unique vertices. + + A non-trivial example is a set with several polylines, each of which with + eventually different number of vertices. The array stores the vertex + identifiers in the order how the polylines are visited: + + The first entry is the identifier of the start vertex of the first polyline, + followed by the second vertex of the first polyline, until the last vertex + of the polyline. Thereafter, the start vertex of the second polyline, and + so on and so forth. Using the (cumulated) counts in number_of_vertices, + the vertices of the n-th polyline can be accessed on the following + array index interval: + :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. + dimensions: + rank: 1 + dim: [[1, n_total]] + + # properties of the polyline primitives + length(NX_NUMBER): + unit: NX_LENGTH + doc: | + The length of each polyline. + dimensions: + rank: 1 + dim: [[1, c]] + is_closed(NX_BOOLEAN): + doc: | + If true specifies that a polyline is closed, i.e. + its end point is connected to the start point. + dimensions: + rank: 1 + dim: [[1, c]] + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 52bebf6552f880b30a2aaa931230be3a4e1c654b47e00f4f0b6f13d5d9f6c802 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality, which has to be at least 1. +# +# +# +# +# The cardinality of the set, i.e. the number of polylines. +# +# +# +# +# +# The number of vertices, supporting the polylines. +# +# +# +# +# The total number of vertices traversed when visiting every polyline. +# +# +# +# +# Computational geometry description of a set of polylines in Euclidean space. +# +# Each polyline is built from a sequence of vertices (points with identifiers). +# Each polyline must have a start and an end point. +# The sequence describes the positive traversal along the polyline when walking +# from the start vertex to the end/last vertex. +# +# +# +# +# +# +# The total number of vertices, irrespective of their eventual uniqueness, +# i.e. the total number of vertices that have to be visited when walking +# along each polyline. +# +# +# +# +# Array which specifies of how many vertices each polyline is built. +# The number of vertices represent the total number of vertices for +# each polyline, irrespectively whether vertices are shared or not. +# See the docstring for polylines for further details about how +# a set with different polyline members should be stored. +# +# +# +# +# +# +# +# Reference to or definition of a coordinate system with +# which the qualifiers and polyline data are interpretable. +# +# +# +# +# Integer which specifies the first index to be used for distinguishing +# polylines. Identifiers are defined either implicitly +# or explicitly. For implicit indexing the identifiers are defined on the +# interval [identifier_offset, identifier_offset+c-1]. +# For explicit indexing the identifier array has to be defined. +# +# The identifier_offset field can for example be used to communicate if the +# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) +# or from 0 (referred to as C-, Python-style index notation) respectively. +# +# +# +# +# Integer used to distinguish polylines for explicit indexing. +# +# +# +# +# +# +# +# +# Positions of the vertices which support the members of the polyline set. +# +# Users are encouraged to reduce the vertices to unique set of positions +# and vertices as this supports a more efficient storage of the geometry data. +# It is also possible though to store the vertex positions naively in which +# case vertices_are_unique is likely False. +# Naively here means that one for example stores each vertex of a triangle +# mesh even though many vertices are shared between triangles and thus +# the positions of these vertices do not have to be duplicated. +# +# +# +# +# +# +# +# +# If true indicates that the vertices are all placed at different +# positions and have different identifiers, i.e. no points overlap +# or are counted twice. +# +# +# +# +# Sequence of vertex identifiers which describe each polyline. +# +# A trivial example is a set with two polylines with three vertices each. +# If the polylines meet in a junction, say the second vertex is shared +# and marking the junction between the two polylines, it is possible that +# there are only five unique positions suggesting five unique vertices. +# +# A non-trivial example is a set with several polylines, each of which with +# eventually different number of vertices. The array stores the vertex +# identifiers in the order how the polylines are visited: +# +# The first entry is the identifier of the start vertex of the first polyline, +# followed by the second vertex of the first polyline, until the last vertex +# of the polyline. Thereafter, the start vertex of the second polyline, and +# so on and so forth. Using the (cumulated) counts in number_of_vertices, +# the vertices of the n-th polyline can be accessed on the following +# array index interval: +# :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. +# +# +# +# +# +# +# +# +# The length of each polyline. +# +# +# +# +# +# +# +# If true specifies that a polyline is closed, i.e. +# its end point is connected to the start point. +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_roi_set.yaml b/contributed_definitions/nyaml/NXcg_roi_set.yaml new file mode 100644 index 0000000000..be7d0e67b8 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_roi_set.yaml @@ -0,0 +1,60 @@ +category: base +doc: | + Base class to hold geometric primitives. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + +# eventually redundant NXsolid_geometry? +type: group +NXcg_roi_set(NXobject): + CG_SPHERE_SET(NXcg_sphere_set): + CG_ELLIPSOID_SET(NXcg_ellipsoid_set): + CG_CYLINDER_SET(NXcg_cylinder_set): + CG_POLYHEDRON_SET(NXcg_polyhedron_set): + + # doc: An eventually redundant container to hold multiple primitives. + # how to handle cases where multiple primitives should be included? + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 0ec7abc70466dfdba796af5579784b92e5add3c645754d0b1701b56a04708c95 +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Base class to hold geometric primitives. +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_sphere_set.yaml b/contributed_definitions/nyaml/NXcg_sphere_set.yaml new file mode 100644 index 0000000000..6a68132b17 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_sphere_set.yaml @@ -0,0 +1,208 @@ +category: base +doc: | + Computational geometry description of a set of spheres in Euclidean space. + + Each sphere can have a different radius. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality, which has to be at least 2. + c: | + The cardinality of the set, i.e. the number of circles or spheres. + +# redundant as there is NXcsg, and NXquadric but easier to understand +type: group +NXcg_sphere_set(NXobject): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + cardinality(NX_POSINT): + unit: NX_UNITLESS + identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for distinguishing + identifiers for spheres. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + identifier(NX_INT): + unit: NX_UNITLESS + doc: | + Integer used to distinguish spheres for explicit indexing. + dimensions: + rank: 1 + dim: [[1, c]] + center(NX_NUMBER): + unit: NX_LENGTH + doc: | + Geometric center of the spheres. This can be the center of mass. + Dimensionality and cardinality of the point and sphere set have to match. + The identifier_offset and identifier field of NXcg_point_set do not need + to be used as they should be same as the identifier_offset and the + identifier for the spheres. + dimensions: + rank: 2 + dim: [[1, c], [2, d]] + radius(NX_NUMBER): + unit: NX_LENGTH + doc: | + In the case that all spheres have the same radius. + radii(NX_NUMBER): + unit: NX_LENGTH + doc: | + In the case that spheres have different radius use this + instead of the radius field. + dimensions: + rank: 1 + dim: [[1, c]] + (NXtransformations): + doc: | + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + # properties of spheres + is_closed(NX_BOOLEAN): + doc: | + Are the spheres closed or hollow? + dimensions: + rank: 1 + dim: [[1, c]] + volume(NX_NUMBER): + unit: NX_ANY + dimensions: + rank: 1 + dim: [[1, c]] + surface_area(NX_NUMBER): + unit: NX_ANY + dimensions: + rank: 1 + dim: [[1, c]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 8252d8a3382853f5c129870a6ffd8c8c4c79a16da413f1092367ba600a69c6b6 +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality, which has to be at least 2. +# +# +# +# +# The cardinality of the set, i.e. the number of circles or spheres. +# +# +# +# +# Computational geometry description of a set of spheres in Euclidean space. +# +# Each sphere can have a different radius. +# +# +# +# +# +# Integer which specifies the first index to be used for distinguishing +# identifiers for spheres. Identifiers are defined either implicitly +# or explicitly. For implicit indexing the identifiers are defined on the +# interval [identifier_offset, identifier_offset+c-1]. +# For explicit indexing the identifier array has to be defined. +# +# The identifier_offset field can for example be used to communicate if the +# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) +# or from 0 (referred to as C-, Python-style index notation) respectively. +# +# +# +# +# Integer used to distinguish spheres for explicit indexing. +# +# +# +# +# +# +# +# Geometric center of the spheres. This can be the center of mass. +# Dimensionality and cardinality of the point and sphere set have to match. +# The identifier_offset and identifier field of NXcg_point_set do not need +# to be used as they should be same as the identifier_offset and the +# identifier for the spheres. +# +# +# +# +# +# +# +# +# In the case that all spheres have the same radius. +# +# +# +# +# In the case that spheres have different radius use this +# instead of the radius field. +# +# +# +# +# +# +# +# Reference to or definition of a coordinate system with +# which the positions and directions are interpretable. +# +# +# +# +# +# Are the spheres closed or hollow? +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml b/contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml new file mode 100644 index 0000000000..9a9335556a --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml @@ -0,0 +1,313 @@ +category: base +doc: | + Computational geometry description of a set of tetrahedra in Euclidean space. + + The tetrahedra do not have to be connected. + As tetrahedral elements they are among hexahedral elements one of the most + frequently used geometric primitive for meshing and describing volumetric + and surface descriptions of objects at the continuum scale. + + A set of tetrahedra in 3D Euclidean space. + + The tetrahedra do not have to be connected, can have different size, + can intersect, and be rotated. + + Tetrahedra are the simplest and thus important geometrical primitive. + They are frequently used as elements in finite element meshing/modeling. + + Tetrahedra have to be non-degenerated, closed, and built of triangles + which are not self-intersecting. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + c: | + The cardinality of the set, i.e. the number of tetrahedra. + +# it is useful to define own base classes for frequently used classes +# a polyhedron is a specific polytope in 3d, do we need +# higher-dimensional polytopes? that could be useful for simplicies though +# as they are used in numerics etc. maybe reach out here to our friends +# from MarDI, for now let's assume we do not need polytopes for d > 3 +type: group +NXcg_tetrahedron_set(NXobject): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + enumeration: [3] + cardinality(NX_POSINT): + unit: NX_UNITLESS + + # qualifiers and properties of tetrahedra + volume(NX_NUMBER): + unit: NX_VOLUME + doc: | + Interior volume + dimensions: + rank: 1 + dim: [[1, c]] + center(NX_NUMBER): + unit: NX_LENGTH + doc: | + Position of the geometric center, which often is but not necessarily + has to be the center_of_mass of the tetrahedra. + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] + surface_area(NX_NUMBER): + unit: NX_AREA + doc: | + Total surface area as the sum of all four triangular faces. + dimensions: + rank: 1 + dim: [[1, c]] + face_area(NX_NUMBER): + unit: NX_AREA + doc: | + Area of each of the four triangular faces of each tetrahedron. + dimensions: + rank: 2 + dim: [[1, c], [2, 4]] + edge_length(NX_NUMBER): + unit: NX_LENGTH + doc: | + Length of each edge of each tetrahedron. + dimensions: + rank: 2 + dim: [[1, c], [2, 6]] + (NXtransformations): + doc: | + Reference to or definition of a coordinate system with + which the qualifiers and mesh data are interpretable. + + # substantially more detailed descriptors of the shape, the mesh + # interior_angle(NX_NUMBER): + # doc: | + # Array of interior angle values. For each tetrahedron the quadruplet of + # angles is a sequence following the order of the vertices. The angle + # is the angle at the specific vertex. TODO lexiographical order. + # Winding order has to be interpreted to resolve the individual angles + # between edges of adjoining face triangles meeting at each corner/vertex. + # unit: NX_ANGLE + # dimensions: + # rank: 2 + # dim: [[1, c], [2, 12]] + identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for distinguishing + tetrahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + identifier(NX_INT): + unit: NX_UNITLESS + doc: | + Integer used to distinguish tetrahedra for explicit indexing. + dimensions: + rank: 1 + dim: [[1, c]] + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + + # detailed mesh-based representation + tetrahedra(NXcg_face_list_data_structure): + + # exists: [min, 0, max, 1] + doc: | + A simple approach to describe the entire set of tetrahedra when the + main intention is to store the shape of the tetrahedra for visualization. + should take the possibility to describe + tetrahedron(NXcg_face_list_data_structure): + + # exists: [min, 0, max, infty] # can this be max, c? + doc: | + Disentangled representations of the mesh of specific tetrahedra. + tetrahedron_half_edge(NXcg_half_edge_data_structure): + + # exists: [min, 0, max, infty] + doc: | + Disentangled representation of the planar graph that each tetrahedron + represents. Such a description simplifies topological processing + or analyses of mesh primitive operations and neighborhood queries. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# b7e4857da33c0b32cad2f9e3ca84f6170ff76bb57e8a392b49ebbbb19b18cef6 +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The cardinality of the set, i.e. the number of tetrahedra. +# +# +# +# +# Computational geometry description of a set of tetrahedra in Euclidean space. +# +# The tetrahedra do not have to be connected. +# As tetrahedral elements they are among hexahedral elements one of the most +# frequently used geometric primitive for meshing and describing volumetric +# and surface descriptions of objects at the continuum scale. +# +# A set of tetrahedra in 3D Euclidean space. +# +# The tetrahedra do not have to be connected, can have different size, +# can intersect, and be rotated. +# +# Tetrahedra are the simplest and thus important geometrical primitive. +# They are frequently used as elements in finite element meshing/modeling. +# +# Tetrahedra have to be non-degenerated, closed, and built of triangles +# which are not self-intersecting. +# +# +# +# +# +# +# +# +# +# +# Interior volume +# +# +# +# +# +# +# +# Position of the geometric center, which often is but not necessarily +# has to be the center_of_mass of the tetrahedra. +# +# +# +# +# +# +# +# +# Total surface area as the sum of all four triangular faces. +# +# +# +# +# +# +# +# Area of each of the four triangular faces of each tetrahedron. +# +# +# +# +# +# +# +# +# Length of each edge of each tetrahedron. +# +# +# +# +# +# +# +# +# Reference to or definition of a coordinate system with +# which the qualifiers and mesh data are interpretable. +# +# +# +# +# +# Integer which specifies the first index to be used for distinguishing +# tetrahedra. Identifiers are defined either implicitly +# or explicitly. For implicit indexing the identifiers are defined on the +# interval [identifier_offset, identifier_offset+c-1]. +# For explicit indexing the identifier array has to be defined. +# +# The identifier_offset field can for example be used to communicate if the +# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) +# or from 0 (referred to as C-, Python-style index notation) respectively. +# +# +# +# +# Integer used to distinguish tetrahedra for explicit indexing. +# +# +# +# +# +# +# +# +# +# +# +# +# A simple approach to describe the entire set of tetrahedra when the +# main intention is to store the shape of the tetrahedra for visualization. +# should take the possibility to describe +# +# +# +# +# +# Disentangled representations of the mesh of specific tetrahedra. +# +# +# +# +# +# Disentangled representation of the planar graph that each tetrahedron +# represents. Such a description simplifies topological processing +# or analyses of mesh primitive operations and neighborhood queries. +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_triangle_set.yaml b/contributed_definitions/nyaml/NXcg_triangle_set.yaml new file mode 100644 index 0000000000..563d271006 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_triangle_set.yaml @@ -0,0 +1,225 @@ +category: base +doc: | + Computational geometry description of a set of triangles in Euclidean space. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality, which has to be at least 2. + c: | + The cardinality of the set, i.e. the number of triangles. + n_unique: | + The number of unique vertices supporting the triangles. +type: group +NXcg_triangle_set(NXobject): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + cardinality(NX_POSINT): + unit: NX_UNITLESS + number_of_unique_vertices(NX_POSINT): + unit: NX_UNITLESS + (NXtransformations): + doc: | + Reference to or definition of a coordinate system with + which the qualifiers and primitive data are interpretable. + identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for distinguishing + triangles. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + identifier(NX_INT): + unit: NX_UNITLESS + doc: | + Integer used to distinguish triangles for explicit indexing. + dimensions: + rank: 1 + dim: [[1, c]] + triangles(NXcg_face_list_data_structure): + + # exists: [min, 0, max, 1] + doc: | + A simple approach to describe the entire set of triangles when the + main intention is to store the shape of the triangles for visualization. + + # detailed additional information eventually mesh-related data + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + + # triangles_half_edge(NXcg_half_edge_data_structure): + # properties of triangles + area(NX_NUMBER): + unit: NX_AREA + dimensions: + rank: 1 + dim: [[1, c]] + edge_length(NX_NUMBER): + unit: NX_LENGTH + doc: | + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] + interior_angle(NX_NUMBER): + unit: NX_ANGLE + doc: | + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] + center(NX_NUMBER): + unit: NX_LENGTH + doc: | + The center of mass of each polygon. + dimensions: + rank: 2 + dim: [[1, c], [2, d]] + bounding_box(NXcg_hexahedron_set): + doc: | + Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 574e944e837cb00c15434545fb0d6a976d91f0781fb71e85f1c43577bfda6140 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality, which has to be at least 2. +# +# +# +# +# The cardinality of the set, i.e. the number of triangles. +# +# +# +# +# The number of unique vertices supporting the triangles. +# +# +# +# +# Computational geometry description of a set of triangles in Euclidean space. +# +# +# +# +# +# +# Reference to or definition of a coordinate system with +# which the qualifiers and primitive data are interpretable. +# +# +# +# +# Integer which specifies the first index to be used for distinguishing +# triangles. Identifiers are defined either implicitly +# or explicitly. For implicit indexing the identifiers are defined on the +# interval [identifier_offset, identifier_offset+c-1]. +# For explicit indexing the identifier array has to be defined. +# +# The identifier_offset field can for example be used to communicate if the +# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) +# or from 0 (referred to as C-, Python-style index notation) respectively. +# +# +# +# +# Integer used to distinguish triangles for explicit indexing. +# +# +# +# +# +# +# +# +# A simple approach to describe the entire set of triangles when the +# main intention is to store the shape of the triangles for visualization. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Array of edge length values. For each triangle the edge length is +# reported for the edges traversed according to the sequence +# in which vertices are indexed in triangles. +# +# +# +# +# +# +# +# +# Array of interior angle values. For each triangle the angle is +# reported for the angle opposite to the edges which are traversed +# according to the sequence in which vertices are indexed in triangles. +# +# +# +# +# +# +# +# +# The center of mass of each polygon. +# +# +# +# +# +# +# +# +# Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml b/contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml new file mode 100644 index 0000000000..331132a4bf --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml @@ -0,0 +1,89 @@ +category: base +doc: | + Computational geometry description of a mesh of triangles. + + The mesh may be self-intersecting and have holes but the + triangles must not be degenerated. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXcg_triangulated_surface_mesh(NXobject): + + # (NXtransformations): + # doc: | + # Reference to or definition of a coordinate system with + # which the qualifiers and mesh data are interpretable. + # substantially more detailed descriptors of the shape, the mesh + # vertex_normal(NXcg_unit_normal_set): + # edge_normal(NXcg_unit_normal_set): + # face_normal(NXcg_unit_normal_set): + # detailed mesh-based representation + # (NXcg_face_list_data_structure): + # doc: | + # A simple approach to describe the mesh when the main intention is to + # store its triangles for visualization. + (NXcg_triangle_set): + (NXcg_half_edge_data_structure): + doc: | + A graph-based approach to describe the mesh when it is also desired + to perform topological processing or analyses on the mesh. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# f767c4a846ca64e44a4cff7e4b570cc7344eed42484aba4592765cd8709de56c +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Computational geometry description of a mesh of triangles. +# +# The mesh may be self-intersecting and have holes but the +# triangles must not be degenerated. +# +# +# +# +# +# A graph-based approach to describe the mesh when it is also desired +# to perform topological processing or analyses on the mesh. +# +# +# diff --git a/contributed_definitions/nyaml/NXcg_unit_normal_set.yaml b/contributed_definitions/nyaml/NXcg_unit_normal_set.yaml new file mode 100644 index 0000000000..2e71ea3ad1 --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_unit_normal_set.yaml @@ -0,0 +1,112 @@ +category: base +doc: | + Computational geometry description of a set of (oriented) unit normal vectors. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality, which has to be at least 2. + c: | + The cardinality of the set, i.e. the number of unit normals. + +# the benefit of NXcg_point_set is that the origin is 0 by default +# how to resolve the association between the unit normal and its associated primitive? +# rather make this a set of vectors, irrespective whether these are unit or not +type: group +NXcg_unit_normal_set(NXobject): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + cardinality(NX_POSINT): + unit: NX_UNITLESS + normals(NX_FLOAT): + unit: NX_LENGTH + doc: | + Direction of each normal + dimensions: + rank: 2 + dim: [[1, c], [2, d]] + orientation(NX_INT): + unit: NX_UNITLESS + doc: | + Qualifier how which specifically oriented normal to its primitive each + normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + dimensions: + rank: 1 + dim: [[1, c]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 6cdabb3b71835f738286e56c56d5f2f17727ea0c100c482d78d678383c9291e7 +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality, which has to be at least 2. +# +# +# +# +# The cardinality of the set, i.e. the number of unit normals. +# +# +# +# +# Computational geometry description of a set of (oriented) unit normal vectors. +# +# +# +# +# +# Direction of each normal +# +# +# +# +# +# +# +# +# Qualifier how which specifically oriented normal to its primitive each +# normal represents. +# +# * 0 - undefined +# * 1 - outer +# * 2 - inner +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXchamber.yaml b/contributed_definitions/nyaml/NXchamber.yaml new file mode 100644 index 0000000000..d005a94bf4 --- /dev/null +++ b/contributed_definitions/nyaml/NXchamber.yaml @@ -0,0 +1,56 @@ +category: base +doc: | + Component of an instrument to store or place objects and specimens. +type: group +NXchamber(NXobject): + name: + doc: | + Given name/alias. + description: + doc: | + Free-text field for describing details about the chamber. + For example out of which material was the chamber built. + (NXfabrication): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# aac9dc98bb6c764714f7b55ce85e6a46223a6d6d35927540cd47d4a4795cad82 +# +# +# +# +# +# Component of an instrument to store or place objects and specimens. +# +# +# +# Given name/alias. +# +# +# +# +# Free-text field for describing details about the chamber. +# For example out of which material was the chamber built. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXchemical_composition.yaml b/contributed_definitions/nyaml/NXchemical_composition.yaml new file mode 100644 index 0000000000..4656b10dd8 --- /dev/null +++ b/contributed_definitions/nyaml/NXchemical_composition.yaml @@ -0,0 +1,110 @@ +category: base +doc: | + (Chemical) composition of a sample or a set of things. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n: | + The number of samples or things. +type: group +NXchemical_composition(NXobject): + + # molecule descriptor + # chemical_formula: + # doc: | + # IUPAC chemical formula + total(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Total based on which composition information is normalized. + dimensions: + rank: 1 + dim: [[1, n]] + ION(NXion): + count(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Count or weight which, when divided by total yields the composition + of this element, isotope, molecule or ion. + dimensions: + rank: 1 + dim: [[1, n]] + composition(NX_NUMBER): + unit: NX_DIMENSIONLESS + doc: | + Count divided by total in atom percent. + dimensions: + rank: 1 + dim: [[1, n]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# dcbe5c04c6c94a2087662d892db25152b6af759a9841a0a127cf6c3859d10592 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The number of samples or things. +# +# +# +# +# (Chemical) composition of a sample or a set of things. +# +# +# +# +# Total based on which composition information is normalized. +# +# +# +# +# +# +# +# +# Count or weight which, when divided by total yields the composition +# of this element, isotope, molecule or ion. +# +# +# +# +# +# +# +# Count divided by total in atom percent. +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXchemical_process.yaml b/contributed_definitions/nyaml/NXchemical_process.yaml new file mode 100644 index 0000000000..68f117c3f1 --- /dev/null +++ b/contributed_definitions/nyaml/NXchemical_process.yaml @@ -0,0 +1,90 @@ +category: base +doc: | + A planned or unplanned process which results in chemical changes (i.e., changes in the chemical bonds) in a specified material. + + Examples include any chemical reactions (addition, subtraction, replacement, ...). +type: group +NXchemical_process(NXobject): + start_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code (with local time zone offset to UTC information + included) when this process started. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code (with local time zone offset to UTC information + included) when this process ended. + description: + doc: | + Short description of the chemical process. + method: + doc: | + Method by which this process was performed. + notes(NXnote): + doc: | + This can be any data or other descriptor acquired during the chemical process + (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 9ab9d17820c3d4b4853123d5dc1181d8a2a008936a1a67bf83913552bfeaf033 +# +# +# +# +# +# A planned or unplanned process which results in chemical changes (i.e., changes in the chemical bonds) in a specified material. +# +# Examples include any chemical reactions (addition, subtraction, replacement, ...). +# +# +# +# ISO 8601 formatted time code (with local time zone offset to UTC information +# included) when this process started. +# +# +# +# +# ISO 8601 formatted time code (with local time zone offset to UTC information +# included) when this process ended. +# +# +# +# +# Short description of the chemical process. +# +# +# +# +# Method by which this process was performed. +# +# +# +# +# This can be any data or other descriptor acquired during the chemical process +# (NXnote allows to add pictures, audio, movies). Alternatively, a +# reference to the location or a unique identifier or other metadata file. In the +# case these are not available, free-text description. +# +# +# diff --git a/contributed_definitions/nyaml/NXcircuit.yaml b/contributed_definitions/nyaml/NXcircuit.yaml new file mode 100644 index 0000000000..4e4adec032 --- /dev/null +++ b/contributed_definitions/nyaml/NXcircuit.yaml @@ -0,0 +1,227 @@ +category: base +doc: | + Application definition for circuit devices. +type: group +NXcircuit(NXobject): + hardware(NXfabrication): + doc: | + Hardware type used in circuit, includes hardware manufacturers and type + tunneling_current(NX_NUMBER): + unit: NX_CURRENT + doc: | + The tunneling current between tip and sample after application of bias voltage. + calibration(NX_NUMBER): + doc: | + Calibration of the current measurement (A/V). + offset(NX_NUMBER): + unit: NX_CURRENT + doc: | + Offset of the current measurement. + gain(NX_NUMBER): + doc: | + Proportional relationship between the probe output voltage and the actual + tunneling current when measuring the tunneling current. + channels(NX_CHAR): + doc: | + The scan channels are selected by users (in scan contronaller). + rt_frequency(NX_NUMBER): + unit: NX_FREQUENCY + doc: | + The bandwitdh of the Hardware and/or Software + signals_oversampling(NX_NUMBER): + unit: NX_ANY + doc: | + (Signals Periods) The Signals Period is the rate at which the signals are + transferred to the host computer running the control software. This is usually + lower by a factor of 10 than the sampling rate, because an internal oversampling + of the signal is done on the real time engine. You can reduce the oversampling + down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. + acquisition_period(NX_NUMBER): + unit: NX_TIME + doc: | + Update rate for several processes like History Graph, Auto-Approach, and for + many Programming Interface functions. This is usually set to 20 ms. All + additional timings (7-9) can only be integer multiples of this value. They can + be set to different values, but the actual timing value will be coerced to a + multiple of the Acquisition Period. + animations_period(NX_NUMBER): + unit: NX_TIME + doc: | + Update rate of animated graphical indicators. These are e.g. some graphs & + sliders. A reasonable value is 40 ms (25 updates per second). Increase this + period to reduce the processor load for the graphical user interface, especially + on slow computers. This value is purely a user interface update rate and does + not affect measurements in any way. + indicators_period(NX_NUMBER): + unit: NX_TIME + doc: | + Update rate of digital indicators, e.g. the numbers displayed besides each + slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a + user interface update rate and does not affect measurements in any way. + measurements_period(NX_NUMBER): + unit: NX_TIME + doc: | + The Measurements period is the integration time for precise measurements + (averaging over specified period), mostly used in sweep modules. Examples are + recording of a force-distance curve or a resonance of a cantilever. For fast + measurements with small steps, a value of 40 ms may be reasonable. For normal + use, 300-500 ms is a good value, but for recording a resonance of a high-Q + cantilever, values of several seconds might be necessary. Usually this parameter + doesn’t need to be set from this module; the sweep modules will set this value + according to the sweep timings. + number_of_outputs(NX_INT): + doc: | + Number of output channels + output_mode(NX_CHAR): + doc: | + The user output in each monitor mode. + output_value(NX_NUMBER): + unit: NX_ANY + doc: | + The values for each output channel. + output_name(NX_CHAR): + doc: | + User outputs whose name can be modified in the corresponding module. + output_slew_rate(NX_CHAR): + doc: | + The rate at which the one of the signal changes when ramping to the starting + point. (V/s) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 572c9e0f471453e5d17c0e86bde59fde7aef0a8a782b5f0f69ba53b412449a89 +# +# +# +# +# +# Application definition for circuit devices. +# +# +# +# Hardware type used in circuit, includes hardware manufacturers and type +# +# +# +# +# The tunneling current between tip and sample after application of bias voltage. +# +# +# +# +# Calibration of the current measurement (A/V). +# +# +# +# +# Offset of the current measurement. +# +# +# +# +# Proportional relationship between the probe output voltage and the actual +# tunneling current when measuring the tunneling current. +# +# +# +# +# The scan channels are selected by users (in scan contronaller). +# +# +# +# +# The bandwitdh of the Hardware and/or Software +# +# +# +# +# (Signals Periods) The Signals Period is the rate at which the signals are +# transferred to the host computer running the control software. This is usually +# lower by a factor of 10 than the sampling rate, because an internal oversampling +# of the signal is done on the real time engine. You can reduce the oversampling +# down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. +# +# +# +# +# Update rate for several processes like History Graph, Auto-Approach, and for +# many Programming Interface functions. This is usually set to 20 ms. All +# additional timings (7-9) can only be integer multiples of this value. They can +# be set to different values, but the actual timing value will be coerced to a +# multiple of the Acquisition Period. +# +# +# +# +# Update rate of animated graphical indicators. These are e.g. some graphs & +# sliders. A reasonable value is 40 ms (25 updates per second). Increase this +# period to reduce the processor load for the graphical user interface, especially +# on slow computers. This value is purely a user interface update rate and does +# not affect measurements in any way. +# +# +# +# +# Update rate of digital indicators, e.g. the numbers displayed besides each +# slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a +# user interface update rate and does not affect measurements in any way. +# +# +# +# +# The Measurements period is the integration time for precise measurements +# (averaging over specified period), mostly used in sweep modules. Examples are +# recording of a force-distance curve or a resonance of a cantilever. For fast +# measurements with small steps, a value of 40 ms may be reasonable. For normal +# use, 300-500 ms is a good value, but for recording a resonance of a high-Q +# cantilever, values of several seconds might be necessary. Usually this parameter +# doesn’t need to be set from this module; the sweep modules will set this value +# according to the sweep timings. +# +# +# +# +# Number of output channels +# +# +# +# +# The user output in each monitor mode. +# +# +# +# +# The values for each output channel. +# +# +# +# +# User outputs whose name can be modified in the corresponding module. +# +# +# +# +# The rate at which the one of the signal changes when ramping to the starting +# point. (V/s) +# +# +# diff --git a/contributed_definitions/nyaml/NXcircuit_board.yaml b/contributed_definitions/nyaml/NXcircuit_board.yaml new file mode 100644 index 0000000000..c3c3d044e7 --- /dev/null +++ b/contributed_definitions/nyaml/NXcircuit_board.yaml @@ -0,0 +1,67 @@ +category: base +doc: | + Circuit board with e.g. ADC and/or DAC electronic components. + + Currently used to store the settings of the so-called magboards used in + Nion electron microscopes but likely this could be a useful base class for + substantially more use cases where details at a deep technical instrument design + level are relevant or important. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXcircuit_board(NXobject): + relay(NX_NUMBER): + unit: NX_UNITLESS + doc: | + TBD by Nion Co. + (NXdac): + (NXadc): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# b720e7a4089ff6b669d026c44b1d610485fe501d8ebc34ca5f367e65bf99066a +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Circuit board with e.g. ADC and/or DAC electronic components. +# +# Currently used to store the settings of the so-called magboards used in +# Nion electron microscopes but likely this could be a useful base class for +# substantially more use cases where details at a deep technical instrument design +# level are relevant or important. +# +# +# +# TBD by Nion Co. +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXclustering.yaml b/contributed_definitions/nyaml/NXclustering.yaml new file mode 100644 index 0000000000..fe14504583 --- /dev/null +++ b/contributed_definitions/nyaml/NXclustering.yaml @@ -0,0 +1,206 @@ +category: base +doc: | + Metadata to the results of a clustering analysis. + + Clustering algorithms are routine tools to segment a set of objects/primitives + into groups, objects of different type. A plethora of algorithms have been + proposed for geometric primitives as objects, such as points, triangles, + or (abstract) objects. + + This base class considers metadata and results of one clustering + applied to a set in which objects are either categorized as noise + or belonging to a cluster, specifically here only one cluster. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_lbl_num: | + Number of numeral labels per object. + n_lbl_cat: | + Number of categorical labels per object. + n_cluster: | + Total number of clusters detected. +type: group +NXclustering(NXobject): + number_of_numeric_labels(NX_UINT): + unit: NX_UNITLESS + doc: | + How many numeric labels does each object have. + number_of_categorical_labels(NX_UINT): + unit: NX_UNITLESS + doc: | + How many categorical labels does each object have. + objects: + doc: | + Reference to a set of objects investigated in a cluster analysis. + Objects must have clear integer identifier. + numeric_label(NX_NUMBER): + doc: | + Reference to numeric attribute data for each object. + categorical_label: + doc: | + Reference to categorical attribute data for each object. + + # list instances of base classes of an applied cluster algorithm + # e.g. (NXclustering_hdbscan): + identifier_offset(NX_UINT): + unit: NX_UNITLESS + doc: | + Which identifier is the first to be used to label a cluster. + + The value should be chosen in such a way that special values can be resolved: + * identifier_offset-1 indicates an object belongs to no cluster. + * identifier_offset-2 indicates an object belongs to the noise category. + Setting for instance identifier_offset to 1 recovers the commonly used + case that objects of the noise category get values to -1 and unassigned points to 0. + unassigned(NX_UINT): + unit: NX_UNITLESS + doc: | + Total number of objects categorized as unassigned. + noise(NX_UINT): + unit: NX_UNITLESS + doc: | + Total number of objects categorized as noise. + number_of_cluster(NX_UINT): + unit: NX_UNITLESS + doc: | + Total number of clusters (excluding noise and unassigned). + size(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Number of objects associated to each cluster. The labels are implicit, + meaning the zeroth/first entry in the array belongs to the first cluster, + the second entry to the second cluster and so on and so forth. + The first cluster has the value of identifier_offset as its identifier. + The second cluster has identifier_offset + 1, and so on and so forth. + dimensions: + rank: 1 + dim: [[1, n_cluster]] + + # should we handle, and if so how fuzzy assignments or similarly probability + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# bbc782a9d72772178ebeebf1b4e9e199de33a4e111361efeba48cb4b169e051c +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of numeral labels per object. +# +# +# +# +# Number of categorical labels per object. +# +# +# +# +# Total number of clusters detected. +# +# +# +# +# Metadata to the results of a clustering analysis. +# +# Clustering algorithms are routine tools to segment a set of objects/primitives +# into groups, objects of different type. A plethora of algorithms have been +# proposed for geometric primitives as objects, such as points, triangles, +# or (abstract) objects. +# +# This base class considers metadata and results of one clustering +# applied to a set in which objects are either categorized as noise +# or belonging to a cluster, specifically here only one cluster. +# +# +# +# How many numeric labels does each object have. +# +# +# +# +# How many categorical labels does each object have. +# +# +# +# +# Reference to a set of objects investigated in a cluster analysis. +# Objects must have clear integer identifier. +# +# +# +# +# Reference to numeric attribute data for each object. +# +# +# +# +# Reference to categorical attribute data for each object. +# +# +# +# +# +# Which identifier is the first to be used to label a cluster. +# +# The value should be chosen in such a way that special values can be resolved: +# * identifier_offset-1 indicates an object belongs to no cluster. +# * identifier_offset-2 indicates an object belongs to the noise category. +# Setting for instance identifier_offset to 1 recovers the commonly used +# case that objects of the noise category get values to -1 and unassigned points to 0. +# +# +# +# +# Total number of objects categorized as unassigned. +# +# +# +# +# Total number of objects categorized as noise. +# +# +# +# +# Total number of clusters (excluding noise and unassigned). +# +# +# +# +# Number of objects associated to each cluster. The labels are implicit, +# meaning the zeroth/first entry in the array belongs to the first cluster, +# the second entry to the second cluster and so on and so forth. +# The first cluster has the value of identifier_offset as its identifier. +# The second cluster has identifier_offset + 1, and so on and so forth. +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcollectioncolumn.yaml b/contributed_definitions/nyaml/NXcollectioncolumn.yaml new file mode 100644 index 0000000000..102261f111 --- /dev/null +++ b/contributed_definitions/nyaml/NXcollectioncolumn.yaml @@ -0,0 +1,165 @@ +category: base +doc: | + Subclass of NXelectronanalyser to describe the electron collection + column of a photoelectron analyser. +type: group +NXcollectioncolumn(NXobject): + scheme(NX_CHAR): + doc: | + Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum + microscope, etc. + extractor_voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Voltage applied to the extractor lens + extractor_current(NX_FLOAT): + unit: NX_CURRENT + doc: | + Current necessary to keep the extractor lens at a set voltage. Variations + indicate leakage, field emission or arc currents to the extractor lens. + working_distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + Distance between sample and detector entrance + mode(NX_CHAR): + doc: | + Labelling of the lens setting in use. + projection(NX_CHAR): + doc: | + The space projected in the angularly dispersive directions, real or reciprocal + enumeration: [real, reciprocal] + magnification(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + The magnification of the electron lens assembly. + depends_on(NX_CHAR): + doc: | + Specifies the position of the collectioncolumn by pointing to the last + transformation in the transformation chain in the NXtransformations group. + (NXtransformations): + doc: | + Collection of axis-based translations and rotations to describe the location and + geometry of the deflector as a component in the instrument. Conventions from the + NXtransformations base class are used. In principle, the McStas coordinate + system is used. The first transformation has to point either to another + component of the system or . (for pointing to the reference frame) to relate it + relative to the experimental setup. Typically, the components of a system should + all be related relative to each other and only one component should relate to + the reference coordinate system. + (NXaperture): + doc: | + The size and position of an aperture inserted in the column, e.g. field aperture + or contrast aperture + (NXdeflector): + doc: | + Deflectors in the collection column section + (NXlens_em): + doc: | + Individual lenses in the collection column section + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# df7044a190f0f578a393b7b185e0c5068c0f538506f843192e2891a4217077c0 +# +# +# +# +# +# Subclass of NXelectronanalyser to describe the electron collection +# column of a photoelectron analyser. +# +# +# +# Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum +# microscope, etc. +# +# +# +# +# Voltage applied to the extractor lens +# +# +# +# +# Current necessary to keep the extractor lens at a set voltage. Variations +# indicate leakage, field emission or arc currents to the extractor lens. +# +# +# +# +# Distance between sample and detector entrance +# +# +# +# +# Labelling of the lens setting in use. +# +# +# +# +# The space projected in the angularly dispersive directions, real or reciprocal +# +# +# +# +# +# +# +# +# The magnification of the electron lens assembly. +# +# +# +# +# Specifies the position of the collectioncolumn by pointing to the last +# transformation in the transformation chain in the NXtransformations group. +# +# +# +# +# Collection of axis-based translations and rotations to describe the location and +# geometry of the deflector as a component in the instrument. Conventions from the +# NXtransformations base class are used. In principle, the McStas coordinate +# system is used. The first transformation has to point either to another +# component of the system or . (for pointing to the reference frame) to relate it +# relative to the experimental setup. Typically, the components of a system should +# all be related relative to each other and only one component should relate to +# the reference coordinate system. +# +# +# +# +# The size and position of an aperture inserted in the column, e.g. field aperture +# or contrast aperture +# +# +# +# +# Deflectors in the collection column section +# +# +# +# +# Individual lenses in the collection column section +# +# +# diff --git a/contributed_definitions/nyaml/NXcontainer.yaml b/contributed_definitions/nyaml/NXcontainer.yaml new file mode 100644 index 0000000000..2bfbdf7f58 --- /dev/null +++ b/contributed_definitions/nyaml/NXcontainer.yaml @@ -0,0 +1,294 @@ +category: base +doc: | + State of a container holding the sample under investigation. + + A container is any object in the beam path which absorbs the beam and + whose contribution to the overall attenuation/scattering needs to be + determined to process the experimental data. Examples of containers + include glass capillary tubes, vanadium cans, windows in furnaces or + diamonds in a Diamond Anvil Cell. The following figures show a complex + example of a container: + + .. figure:: container/ComplexExampleContainer.png + + A hypothetical capillary furnace. The beam passes from left to right + (blue dashes), passing through window 1, then window 2, before + passing through the downstream wall of the capillary. It is then + scattered by the sample with scattered beams passing through the + upstream wall of the capillary, then windows 4 and 5. As part of the + corrections for a PDF experiment it is necessary to subtract the PDF + of the empty container (i.e. each of the windows and the capillary). + To calculate the PDF of the empty container it is necessary to have + the measured scattering data and to know the nature (e.g. density, + elemental composition, etc.) of the portion of the container which + the beam passed through. + + .. figure:: container/ComplexContainerBeampath.png + + A complete description of the shapes of the container elements with + their orientation relative to the beam and also information on + whether they are upstream or downstream of the sample is also + therefore important. For example, although the windows 2 and 4 have + the same shape, the path taken through them by the beam is very + different and this needs to be modelled. Furthermore, it is not + inconceivable that windows might move during an experiment and thus + the changes to the beampath would need to be accounted for. + + This class encodes the position of the container with respect to the + sample and allows the calculation of the beampath through the container. + It also includes sufficient data to model beam absorption of the + container and a link to a dataset containing a measurement of the + container with nothing inside, to allow data corrections (at a specific + beam energy/measurement time) to be made. +type: group +NXcontainer(NXobject): + name: + doc: | + Descriptive name of container. + description: + doc: | + Verbose description of container and how it fits into the wider + experimental set up. + chemical_formula: + doc: | + Chemical composition of the material the container is made from. + 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. + density(NX_FLOAT): + unit: NX_MASS_DENSITY + doc: | + Density of the material the container is made from. + dimensions: + rank: 1 + dim: [[1, n_comp]] + packing_fraction(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Fraction of the volume of the container occupied by the material + forming the container. + dimensions: + dim: [[1, n_comp]] + relative_molecular_mass(NX_FLOAT): + unit: NX_MASS + doc: | + Relative molecular mass of container. + dimensions: + rank: 1 + dim: [[1, n_comp]] + beam(NXbeam): + doc: | + Details of beam incident on container, including the position + relative to the sample (to determine whether the container is + upstream or downstream of the sample). + shape(NXshape): + doc: | + Shape of the container. In combination with orientation this + should allow the beampath through the container to be modelled to + allow the adsorption to be calculated. + orientation(NXtransformations): + doc: | + The angle the container makes to the beam and how it may change + during the experiment.In combination with shape this should allow + the beampath through the container to be modelled to allow the + adsorption of the container to be calculated. + reference_measurement(link): + target: /NXentry + doc: | + A link to a full data collection which contains the actual + measured data for this container within the experimental set up + (with no sample or inner container(s)). This data set will also + include the wavelength/energy, measurement time and intensity for + which these data are valid. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# fbb634b42fbf75d55158a96329119a770f9ff716d2e3ec127b28b192c5fe872a +# +# +# +# +# +# +# State of a container holding the sample under investigation. +# +# A container is any object in the beam path which absorbs the beam and +# whose contribution to the overall attenuation/scattering needs to be +# determined to process the experimental data. Examples of containers +# include glass capillary tubes, vanadium cans, windows in furnaces or +# diamonds in a Diamond Anvil Cell. The following figures show a complex +# example of a container: +# +# .. figure:: container/ComplexExampleContainer.png +# +# A hypothetical capillary furnace. The beam passes from left to right +# (blue dashes), passing through window 1, then window 2, before +# passing through the downstream wall of the capillary. It is then +# scattered by the sample with scattered beams passing through the +# upstream wall of the capillary, then windows 4 and 5. As part of the +# corrections for a PDF experiment it is necessary to subtract the PDF +# of the empty container (i.e. each of the windows and the capillary). +# To calculate the PDF of the empty container it is necessary to have +# the measured scattering data and to know the nature (e.g. density, +# elemental composition, etc.) of the portion of the container which +# the beam passed through. +# +# .. figure:: container/ComplexContainerBeampath.png +# +# A complete description of the shapes of the container elements with +# their orientation relative to the beam and also information on +# whether they are upstream or downstream of the sample is also +# therefore important. For example, although the windows 2 and 4 have +# the same shape, the path taken through them by the beam is very +# different and this needs to be modelled. Furthermore, it is not +# inconceivable that windows might move during an experiment and thus +# the changes to the beampath would need to be accounted for. +# +# This class encodes the position of the container with respect to the +# sample and allows the calculation of the beampath through the container. +# It also includes sufficient data to model beam absorption of the +# container and a link to a dataset containing a measurement of the +# container with nothing inside, to allow data corrections (at a specific +# beam energy/measurement time) to be made. +# +# +# +# Descriptive name of container. +# +# +# +# +# Verbose description of container and how it fits into the wider +# experimental set up. +# +# +# +# +# Chemical composition of the material the container is made from. +# 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. +# +# +# +# +# Density of the material the container is made from. +# +# +# +# +# +# +# +# Fraction of the volume of the container occupied by the material +# forming the container. +# +# +# +# +# +# +# Relative molecular mass of container. +# +# +# +# +# +# +# Details of beam incident on container, including the position +# relative to the sample (to determine whether the container is +# upstream or downstream of the sample). +# +# +# +# +# Shape of the container. In combination with orientation this +# should allow the beampath through the container to be modelled to +# allow the adsorption to be calculated. +# +# +# +# +# The angle the container makes to the beam and how it may change +# during the experiment.In combination with shape this should allow +# the beampath through the container to be modelled to allow the +# adsorption of the container to be calculated. +# +# +# +# +# A link to a full data collection which contains the actual +# measured data for this container within the experimental set up +# (with no sample or inner container(s)). This data set will also +# include the wavelength/energy, measurement time and intensity for +# which these data are valid. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcoordinate_system_set.yaml b/contributed_definitions/nyaml/NXcoordinate_system_set.yaml new file mode 100644 index 0000000000..c149cc4039 --- /dev/null +++ b/contributed_definitions/nyaml/NXcoordinate_system_set.yaml @@ -0,0 +1,257 @@ +category: base +doc: | + Container to hold different coordinate systems conventions. + + It is the purpose of this base class to define these conventions and + offer a place to store mappings between different coordinate systems + which are relevant for the interpretation of the data described + by the application definition and base class instances. + + For each Cartesian coordinate system users should use a set of + NXtransformations: + + * These should define the three base vectors. + * The location of the origin. + * The affine transformations which bring each axis of this coordinate system + into registration with the McStas coordinate system. + * Equally, affine transformations should be given for the inverse mapping. + + As an example one may take an experiment or computer simulation where + there is a laboratory (lab) coordinate system, a sample/specimen coordinate + system, a crystal coordinate system, and additional coordinate systems, + which are eventually attached to components of the instrument. + + If no additional transformation is specified in this group or if an + instance of an NXcoordinate_system_set is absent it should be assumed + the so-called McStas coordinate system is used. + + Many application definitions in NeXus refer to this `McStas `_ coordinate system. + This is a Cartesian coordinate system whose z axis points along the neutron + propagation axis. The systems y axis is vertical up, while the x axis points + left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. + + Within each NXtransformations a depends_on section is required. The depends_on + field specifies if the coordinate system is the root/reference + (which is indicated by writing "." in the depends_on section.) +type: group +NXcoordinate_system_set(NXobject): + + # implementing a proposal for "a common base table" along thoughts like: + # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations + # similar to a place where all transformations are stored + # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 + (NXtransformations): + doc: | + A group of transformations which specify: + + * Three base vectors of the coordinate system. + * Origin of the coordinate system. + * A depends_on keyword. Its value can be "." or the name of an + NXtransformations instance which needs to exist in the + NXcoordinate_system_set instance. + * If the coordinate system is the reference one it has to be named + reference. + + In case of having more than one NXtransformations there has to be for + each additional coordinate system, i.e. the one not the reference: + + * A set of translations and rotations which map each base vector to the reference. + * A set of translations and rotations which map each reference base vector + to the coordinate system. + + The NXtransformations for these mappings need to be formatted + according to the descriptions in NXtransformations. + + # NEW ISSUE: add an illustrated example + + # thoughts on how to use this + # these user-defined frames could be the sample surface, the detector, + # individual frames attached to specific instruments, for instance in an + # atom probe experiment we usually have a lab, specimen surface/apex, laser (pinhole), detector, reconstruction frames + # in electron/focused ion beam, lab, e-beam, i-beam, sample surface, individual frames for each detector + + # THE REMAINING TEXT IS NOT PART OF THE BASE CLASS + # An example follows how each field under transformations can look like + # I would like to encourage a description where each coordinate system is defined + # and for each coordinate system a transformation written down which maps each + # user-defined Frame_i onto Frame_McStas (and maybe for convenience purposes also vice versa + # Frame_McStas = T_i * Frame_i + # if there would be a small python tool that takes a collection of frames + # and does the mapping automatically and writing the respective NeXus entries + # this would be very useful. + + # \@transformation_type should not be used + # define frame of reference that is understood as the laboratory coordinate system + # x_axis(NX_NUMBER): + # unit: NX_TRANSFORMATION + # \@depends_on: # "." meaning the root coordinate system, i.e. the McStas + # \@vector(NX_NUMBER): # [1, 0, 0] + # \@offset(NX_NUMBER): + # y_axis(NX_NUMBER): + # unit: NX_TRANSFORMATION + # \@depends_on: # "." + # \@vector(NX_NUMBER): # [0, 1, 0] + # \@offset(NX_NUMBER): + # z_axis(NX_NUMBER): + # unit: NX_TRANSFORMATION + # \@depends_on: # "." + # \@vector(NX_NUMBER): # [0, 0, 1] + # \@offset(NX_NUMBER): # is [0, 0, 0] if the origin of the McStas coordinate system and of the laboratory_frame overlap + # \@offset_units: # should be an NX_LENGTH + # and how it translates into the McStas convention + # lab_mcstas(NX_NUMBER): + # doc: Rotation matrix which maps the x_axis of the laboratory_frame to the x_axis of the McStas system. + # BUT as far as I know you cannot define a 3D rotation matrix, you should rather make a chain of transformations + # each about a single axis and thus building a depends_on chain + # for example a 4x4 translation with a more-than-one-value-non-zero/non-identity rotation matrix + # could be you first rotate about Z by R_Z'/R_1 depends_on is x_axis := X, yielding X', Y', Z' + # second you rotate about the X' by R_X/R_2 depends_on is X', yielding X'', Y'', Z'' + # third you rotate about the Z'' by R_Z''/R_3 depends_on is then Z'', yielding X''', Y''', Z''' matching McStas, + # this is the Bunge-Euler way of doing it, but would it also be possible to just define + # the lab_mcstas(NX_NUMBER) value as an 3x3 array and give the offsets and translations as it is discussed in the manual ? + # unit: NX_ANGLE + # \@depends_on: # x_axis + # 3x3 rotation matrices are decoupled into three successive planar rotations + # see https://manual.nexusformat.org/classes/base_classes/NXtransformations.html + # mcstas_to_lab(NX_NUMBER): + # same story but the inverse affine transformation + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 48ed635c5273f21260f9b713c76f685e529d7f26041bea06ddc43e3566ac7916 +# +# +# +# +# +# Container to hold different coordinate systems conventions. +# +# It is the purpose of this base class to define these conventions and +# offer a place to store mappings between different coordinate systems +# which are relevant for the interpretation of the data described +# by the application definition and base class instances. +# +# For each Cartesian coordinate system users should use a set of +# NXtransformations: +# +# * These should define the three base vectors. +# * The location of the origin. +# * The affine transformations which bring each axis of this coordinate system +# into registration with the McStas coordinate system. +# * Equally, affine transformations should be given for the inverse mapping. +# +# As an example one may take an experiment or computer simulation where +# there is a laboratory (lab) coordinate system, a sample/specimen coordinate +# system, a crystal coordinate system, and additional coordinate systems, +# which are eventually attached to components of the instrument. +# +# If no additional transformation is specified in this group or if an +# instance of an NXcoordinate_system_set is absent it should be assumed +# the so-called McStas coordinate system is used. +# +# Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. +# This is a Cartesian coordinate system whose z axis points along the neutron +# propagation axis. The systems y axis is vertical up, while the x axis points +# left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. +# +# Within each NXtransformations a depends_on section is required. The depends_on +# field specifies if the coordinate system is the root/reference +# (which is indicated by writing "." in the depends_on section.) +# +# +# +# +# A group of transformations which specify: +# +# * Three base vectors of the coordinate system. +# * Origin of the coordinate system. +# * A depends_on keyword. Its value can be "." or the name of an +# NXtransformations instance which needs to exist in the +# NXcoordinate_system_set instance. +# * If the coordinate system is the reference one it has to be named +# reference. +# +# In case of having more than one NXtransformations there has to be for +# each additional coordinate system, i.e. the one not the reference: +# +# * A set of translations and rotations which map each base vector to the reference. +# * A set of translations and rotations which map each reference base vector +# to the coordinate system. +# +# The NXtransformations for these mappings need to be formatted +# according to the descriptions in NXtransformations. +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcorrector_cs.yaml b/contributed_definitions/nyaml/NXcorrector_cs.yaml new file mode 100644 index 0000000000..632aaf5c9f --- /dev/null +++ b/contributed_definitions/nyaml/NXcorrector_cs.yaml @@ -0,0 +1,158 @@ +category: base +doc: | + Corrector for aberrations in an electron microscope. + + Different technology partners use different naming schemes and models + for quantifying the aberration coefficients. + + The corrector in an electron microscope is composed of multiple lenses and + multipole stigmators with vendor-specific details which are often undisclosed. +type: group +NXcorrector_cs(NXobject): + applied(NX_BOOLEAN): + doc: | + Was the corrector used? + name: + doc: | + Given name/alias. + (NXfabrication): + description: + doc: | + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. If this does not exist + a free-text field to report further details about the corrector. + + # NEW ISSUE: clarify the mathematical details behind the + # NEW ISSUE: following parameters of the these constants and how they are useful + ZEMLIN_TABLEAU(NXprocess): + doc: | + Specific information about the concrete alignment procedure which is a + process during which the corrector is configured to enable a calibrated + usage of the microscope. + description: + doc: | + Discouraged free-text field to add further details about the alignment + procedure. + tilt_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + The outer tilt angle of the beam in tableau aquisition. + exposure_time(NX_FLOAT): + unit: NX_TIME + doc: | + The exposure time of the single tilt images. + magnification(NX_NUMBER): + unit: NX_DIMENSIONLESS + doc: | + The factor of enlargement of the apparent size, + not physical size, of an object. + (NXprocess): + doc: | + Place for storing measured or estimated aberrations (for each image or final). + ceos(NXaberration_model_ceos): + nion(NXaberration_model_nion): + + # technical components of the corrector + (NXlens_em): + (NXtransformations): + + # NEW ISSUE: add the reference to the conversion table between + # NEW ISSUE: Haider and Krivanek The table [##MK]() is here used for reference. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 34f8ac6822123ec86d01f9aeb8ac349941959381695dba1e7c9f5f55d2e720f1 +# +# +# +# +# +# Corrector for aberrations in an electron microscope. +# +# Different technology partners use different naming schemes and models +# for quantifying the aberration coefficients. +# +# The corrector in an electron microscope is composed of multiple lenses and +# multipole stigmators with vendor-specific details which are often undisclosed. +# +# +# +# Was the corrector used? +# +# +# +# +# Given name/alias. +# +# +# +# +# +# Ideally, a (globally) unique persistent identifier, link, +# or text to a resource which gives further details. If this does not exist +# a free-text field to report further details about the corrector. +# +# +# +# +# +# Specific information about the concrete alignment procedure which is a +# process during which the corrector is configured to enable a calibrated +# usage of the microscope. +# +# +# +# Discouraged free-text field to add further details about the alignment +# procedure. +# +# +# +# +# The outer tilt angle of the beam in tableau aquisition. +# +# +# +# +# The exposure time of the single tilt images. +# +# +# +# +# The factor of enlargement of the apparent size, +# not physical size, of an object. +# +# +# +# +# Place for storing measured or estimated aberrations (for each image or final). +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcs_computer.yaml b/contributed_definitions/nyaml/NXcs_computer.yaml new file mode 100644 index 0000000000..21e3b37b9b --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_computer.yaml @@ -0,0 +1,124 @@ +category: base +doc: | + Computer science description of a set of computing nodes. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXcs_computer(NXobject): + name: + doc: | + Given name/alias to the computing system, e.g. MyDesktop. + operating_system: + doc: | + Name of the operating system, e.g. Windows, Linux, Mac, Android. + \@version: + doc: | + Version plus build number, commit hash, or description of an ever + persistent resource where the source code of the program and build + instructions can be found so that the program can be configured in + such a manner that the result file is ideally recreatable yielding + the same results. + + # difference e.g. in Win11 between hardware ID, UUID, and device ID + uuid: + doc: | + Ideally a (globally) unique persistent identifier of the computer, i.e. + the Universally Unique Identifier (UUID) of the computing node. + + # when it comes to performance monitoring + (NXcs_cpu): + doc: | + A list of physical processing units (can be multi-core chips). + (NXcs_gpu): + doc: | + A list of physical coprocessor/graphic cards/accelerator units. + (NXcs_mm_sys): + doc: | + Details about the memory sub-system. + (NXcs_io_sys): + doc: | + Details about the I/O sub-system. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# beec5bb34324307ff1f1b659caccb0bbf28e67f8280065b68a948bd7e0dc795b +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Computer science description of a set of computing nodes. +# +# +# +# Given name/alias to the computing system, e.g. MyDesktop. +# +# +# +# +# Name of the operating system, e.g. Windows, Linux, Mac, Android. +# +# +# +# Version plus build number, commit hash, or description of an ever +# persistent resource where the source code of the program and build +# instructions can be found so that the program can be configured in +# such a manner that the result file is ideally recreatable yielding +# the same results. +# +# +# +# +# +# +# Ideally a (globally) unique persistent identifier of the computer, i.e. +# the Universally Unique Identifier (UUID) of the computing node. +# +# +# +# +# +# A list of physical processing units (can be multi-core chips). +# +# +# +# +# A list of physical coprocessor/graphic cards/accelerator units. +# +# +# +# +# Details about the memory sub-system. +# +# +# +# +# Details about the I/O sub-system. +# +# +# diff --git a/contributed_definitions/nyaml/NXcs_cpu.yaml b/contributed_definitions/nyaml/NXcs_cpu.yaml new file mode 100644 index 0000000000..2160aa3dd4 --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_cpu.yaml @@ -0,0 +1,54 @@ +category: base +doc: | + Computer science description of a central processing unit (CPU) of a computer. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXcs_cpu(NXobject): + name: + doc: | + Given name of the CPU. Users should be as specific as possible. + (NXfabrication): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 7acc57d7e709c31f39bfe27c48566ae19f040f70c491c764259dab65ee1a36b2 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Computer science description of a central processing unit (CPU) of a computer. +# +# +# +# Given name of the CPU. Users should be as specific as possible. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml b/contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml new file mode 100644 index 0000000000..8a2df5e7e5 --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml @@ -0,0 +1,172 @@ +category: base +doc: | + Computer science base class for packing and unpacking booleans. + + One use case is processing of object sets (like point cloud data). + When one applies e.g. a spatial filter to a set of points to define which + points are analyzed and which not, it is useful to document which points were + taken. One can store this information in a compact manner with an array of + boolean values. If the value is True the point is taken, else it is not. + + If the points are identified by an array of integer identifiers and an + arbitrary spatial filtering, the boolean array will be filled with True and False + values in an arbitrary manner. Especially when the number of points is large, + for instance several thousands and more, some situations can be more efficiently + stored if one would not store the boolean array but just list the identifiers + of the points taken. For instance if within a set of 1000 points only one point is + taken, it would take (naively) 4000 bits to store the array but only 32 bits + to store e.g. the ID of that taken point. Of course the 4000 bit field is so + sparse that it could be compressed resulting also in a substantial reduction + of the storage demands. Therefore boolean masks are useful compact descriptions + to store information about set memberships in a compact manner. + In general it is true, though, that which representation is best, i.e. + most compact (especially when compressed) depends strongly on occupation of + the array. + + This base class just bookkeeps metadata to inform software about necessary + modulo operations to decode the set membership of each object. This is useful + because the number of objects not necessarily is an integer multiple of the bit depth. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_objs: | + Number of entries (e.g. number of points or objects). + bitdepth: | + Number of bits assumed for the container datatype used. + n_total: | + Length of mask considering the eventual need for padding. +type: group +NXcs_filter_boolean_mask(NXobject): + number_of_objects(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of objects represented by the mask. + bitdepth(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of bits assumed matching on a default datatype. + (e.g. 8 bits for a C-style uint8). + mask(NX_UINT): + unit: NX_UNITLESS + doc: | + The unsigned integer array representing the content of the mask. + If padding is used the padded bits have to be set to 0. + dimensions: + rank: 1 + dim: [[1, n_total]] + identifier(NX_UINT): + doc: | + Link to/or array of identifiers for the objects. The decoded mask is + interpreted consecutively, i.e. the first bit in the mask matches + to the first identifier, the second bit in the mask to the second + identifier and so on and so forth. + dimensions: + rank: 1 + dim: [[1, n_object]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 1ec0c27c39c4e904f1d117f958a1fa5c4d70795c7eb7d0579bf2268728651b4a +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of entries (e.g. number of points or objects). +# +# +# +# +# Number of bits assumed for the container datatype used. +# +# +# +# +# Length of mask considering the eventual need for padding. +# +# +# +# +# Computer science base class for packing and unpacking booleans. +# +# One use case is processing of object sets (like point cloud data). +# When one applies e.g. a spatial filter to a set of points to define which +# points are analyzed and which not, it is useful to document which points were +# taken. One can store this information in a compact manner with an array of +# boolean values. If the value is True the point is taken, else it is not. +# +# If the points are identified by an array of integer identifiers and an +# arbitrary spatial filtering, the boolean array will be filled with True and False +# values in an arbitrary manner. Especially when the number of points is large, +# for instance several thousands and more, some situations can be more efficiently +# stored if one would not store the boolean array but just list the identifiers +# of the points taken. For instance if within a set of 1000 points only one point is +# taken, it would take (naively) 4000 bits to store the array but only 32 bits +# to store e.g. the ID of that taken point. Of course the 4000 bit field is so +# sparse that it could be compressed resulting also in a substantial reduction +# of the storage demands. Therefore boolean masks are useful compact descriptions +# to store information about set memberships in a compact manner. +# In general it is true, though, that which representation is best, i.e. +# most compact (especially when compressed) depends strongly on occupation of +# the array. +# +# This base class just bookkeeps metadata to inform software about necessary +# modulo operations to decode the set membership of each object. This is useful +# because the number of objects not necessarily is an integer multiple of the bit depth. +# +# +# +# Number of objects represented by the mask. +# +# +# +# +# Number of bits assumed matching on a default datatype. +# (e.g. 8 bits for a C-style uint8). +# +# +# +# +# The unsigned integer array representing the content of the mask. +# If padding is used the padded bits have to be set to 0. +# +# +# +# +# +# +# +# Link to/or array of identifiers for the objects. The decoded mask is +# interpreted consecutively, i.e. the first bit in the mask matches +# to the first identifier, the second bit in the mask to the second +# identifier and so on and so forth. +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcs_gpu.yaml b/contributed_definitions/nyaml/NXcs_gpu.yaml new file mode 100644 index 0000000000..573f14f29c --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_gpu.yaml @@ -0,0 +1,54 @@ +category: base +doc: | + Computer science description of a graphic processing unit (GPU) of a computer. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXcs_gpu(NXobject): + name: + doc: | + Given name of the GPU. Users should be as specific as possible. + (NXfabrication): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 739989c53a5e4fe43a63035920aab39528e8933c2ec9e35465e04e40d69d9a7c +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Computer science description of a graphic processing unit (GPU) of a computer. +# +# +# +# Given name of the GPU. Users should be as specific as possible. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcs_io_obj.yaml b/contributed_definitions/nyaml/NXcs_io_obj.yaml new file mode 100644 index 0000000000..1fd6b1376a --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_io_obj.yaml @@ -0,0 +1,82 @@ +category: base +doc: | + Computer science description of a storage object in an input/output system. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXcs_io_obj(NXobject): + technology: + doc: | + Qualifier for the type of storage medium used. + enumeration: [solid_state_disk, hard_disk, tape] + + # recording technique etc. + max_physical_capacity(NX_NUMBER): + doc: | + Total amount of data which the medium can hold. + + # unit: NX_BIT + name: + doc: | + Given name to the I/O unit. + (NXfabrication): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# d04482bdb2e7dae35847392cb0040f9cbf17c7539a18bbdb8e74abd68d1b9bac +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Computer science description of a storage object in an input/output system. +# +# +# +# Qualifier for the type of storage medium used. +# +# +# +# +# +# +# +# +# +# +# Total amount of data which the medium can hold. +# +# +# +# +# +# Given name to the I/O unit. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcs_io_sys.yaml b/contributed_definitions/nyaml/NXcs_io_sys.yaml new file mode 100644 index 0000000000..46a0989d11 --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_io_sys.yaml @@ -0,0 +1,46 @@ +category: base +doc: | + Computer science description of system of a computer. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXcs_io_sys(NXobject): + (NXcs_io_obj): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 4eb7454d7630187a5e90178a64ced543987d62f60368344c81c3ef8652f77f2c +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Computer science description of system of a computer. +# +# +# diff --git a/contributed_definitions/nyaml/NXcs_mm_sys.yaml b/contributed_definitions/nyaml/NXcs_mm_sys.yaml new file mode 100644 index 0000000000..376a8ffbf9 --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_mm_sys.yaml @@ -0,0 +1,55 @@ +category: base +doc: | + Computer science description of a main memory system of a computer. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXcs_mm_sys(NXobject): + total_physical_memory(NX_NUMBER): + doc: | + How much physical memory does the system provide. + + # unit: NX_BIT + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 3121e939a6f8764585bdda1ee024eddf80bf37d885af6ee8f5ce1a7d04d791ef +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Computer science description of a main memory system of a computer. +# +# +# +# How much physical memory does the system provide. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcs_prng.yaml b/contributed_definitions/nyaml/NXcs_prng.yaml new file mode 100644 index 0000000000..8e5a642638 --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_prng.yaml @@ -0,0 +1,137 @@ +category: base +doc: | + Computer science description of pseudo-random number generator. + + The purpose of such metadata is to identify if exactly the same sequence + can be reproduced, like for a PRNG or not (for a true physically random source). +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXcs_prng(NXobject): + type: + doc: | + Different approaches for generating random numbers with a computer exists. + Some use a dedicated physical device where the state is unpredictable (physically). + Some use a mangling of the system clock (system_clock), where also without + additional pieces of information the sequence is not reproducible. + Some use so-called pseudo-random number generator (PRNG) are used. + These are algorithms which yield a deterministic sequence of practically + randomly appearing numbers. These algorithms different in their quality in + how close the resulting sequences are random. + Nowadays one of the most commonly used algorithm is + the MersenneTwister (mt19937). + enumeration: [physical, system_clock, mt19937, other] + program: + doc: | + Name of the PRNG implementation and version. If such information is not + available or if the PRNG type was set to other the DOI to the publication + or the source code should be given. + \@version: + doc: | + Version and build number, or commit hash. + seed(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Parameter of the PRNG controlling its initialization and thus the specific + sequence of numbers it generates. + + # reformulate last part of the first sentence. + warmup(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Number of initial draws from the PRNG which are discarded in an effort + to equilibrate the sequence and make it thus to statistically more random. + If no warmup was performed or if warmup procedures are unclear, + users should set the value to zero. + + # one could add spectral properties but this is usually well documented in the PRNG literature + # one could also think about making reference to the NIST PRNG test suite to qualify the PRNG + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 01b28e5d73597c33b6d795d41b35d3b1c4f07caaa3fc58b784789f7f04a59a77 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Computer science description of pseudo-random number generator. +# +# The purpose of such metadata is to identify if exactly the same sequence +# can be reproduced, like for a PRNG or not (for a true physically random source). +# +# +# +# Different approaches for generating random numbers with a computer exists. +# Some use a dedicated physical device where the state is unpredictable (physically). +# Some use a mangling of the system clock (system_clock), where also without +# additional pieces of information the sequence is not reproducible. +# Some use so-called pseudo-random number generator (PRNG) are used. +# These are algorithms which yield a deterministic sequence of practically +# randomly appearing numbers. These algorithms different in their quality in +# how close the resulting sequences are random. +# Nowadays one of the most commonly used algorithm is +# the MersenneTwister (mt19937). +# +# +# +# +# +# +# +# +# +# +# Name of the PRNG implementation and version. If such information is not +# available or if the PRNG type was set to other the DOI to the publication +# or the source code should be given. +# +# +# +# Version and build number, or commit hash. +# +# +# +# +# +# Parameter of the PRNG controlling its initialization and thus the specific +# sequence of numbers it generates. +# +# +# +# +# +# Number of initial draws from the PRNG which are discarded in an effort +# to equilibrate the sequence and make it thus to statistically more random. +# If no warmup was performed or if warmup procedures are unclear, +# users should set the value to zero. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcs_profiling.yaml b/contributed_definitions/nyaml/NXcs_profiling.yaml new file mode 100644 index 0000000000..2b869d4a37 --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_profiling.yaml @@ -0,0 +1,263 @@ +category: base +doc: | + Computer science description for summary performance/profiling data of an application. + + Performance monitoring and benchmarking of software is a task where questions + can be asked at various levels of detail. In general, there are three main + contributions to performance: + + * Hardware capabilities and configuration + * Software configuration and capabilities + * Dynamic effects of the system in operation and the system working together + with eventually multiple computers, especially when these have to exchange + information across a network. + + At the most basic level users may wish to document how long e.g. a data + analysis with a scientific software (app). + A frequent idea is here to judge how critical the effect is on the workflow + of the scientists, i.e. is the analysis possible in a few seconds or would it + take days if I were to run this analysis on a comparable machine. In this case, + mainly the order of magnitude is relevant, as well as how this can be achieved + with using parallelization (i.e. reporting the number of CPU and GPU resources + used, the number of processes and/or threads, and basic details about the + computing node/computer. + + At more advanced levels benchmarks may go as deep as detailed temporal tracking + of individual processor instructions, their relation to other instructions, the + state of call stacks, in short eventually the entire app execution history + and hardware state history. Such analyses are mainly used for performance + optimization as well as for tracking bugs and other development purposes. + Specialized software exists which documents such performance data in + specifically-formatted event log files or databases. + + This base class cannot and should not replace these specific solutions. + Instead, the intention of the base class is to serve scientists at the + basic level to enable simple monitoring of performance data and log profiling + data of key algorithmic steps or parts of computational workflows, so that + these pieces of information can guide users which order of magnitude differences + should be expected or not. + + Developers of application definitions should add additional fields and + references to e.g. more detailed performance data to which they wish to link + the metadata in this base class. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXcs_profiling(NXobject): + + # details about queuing systems etc + current_working_directory: + doc: | + Path to the directory from which the tool was called. + command_line_call: + doc: | + Command line call with arguments if applicable. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + included when the app was started. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + included when the app terminated or crashed. + total_elapsed_time(NX_NUMBER): + unit: NX_TIME + doc: | + Wall-clock time how long the app execution took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + number_of_processes(NX_POSINT): + unit: NX_UNITLESS + doc: | + Qualifier which specifies with how many nominal processes the app was + invoked. The main idea behind this field, for instance for app using a + Message Passing Interface parallelization is to communicate how many + processes were used. + + For sequentially running apps number_of_processes and number_of_threads + is 1. If the app uses exclusively GPU parallelization number_of_gpus + can be larger than 1. If no GPU is used number_of_gpus is 0 even though + the hardware may have GPUs installed, thus indicating these were not + used though. + number_of_threads(NX_POSINT): + unit: NX_UNITLESS + doc: | + Qualifier with how many nominal threads were accessible to the app at + runtime. Specifically here the maximum number of threads used for the + high-level threading library used (e.g. OMP_NUM_THREADS), posix. + number_of_gpus(NX_POSINT): + unit: NX_UNITLESS + doc: | + Qualifier with how many nominal GPUs the app was invoked at runtime. + + # there are more complicated usage models, where GPUs are activated in + # between runs etc, but here application definition and base class developers + # should feel free to suggest customizations wrt to if and how such more + # complicated models should be captured. + # how can you have an empty list? + (NXcs_computer): + doc: | + A collection with one or more computing nodes each with own resources. + This can be as simple as a laptop or the nodes of a cluster computer. + (NXcs_profiling_event): + doc: | + A collection of individual profiling event data which detail e.g. how + much time the app took for certain computational steps and/or how much + memory was consumed during these operations. + + # how to retrieve UUID for cloud computing instances + # https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/identify_ec2_instances.html + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 4f8f75e03907b18215d89efcc2968066971248a838a1b3e6d3b9727da3cbde78 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Computer science description for summary performance/profiling data of an application. +# +# Performance monitoring and benchmarking of software is a task where questions +# can be asked at various levels of detail. In general, there are three main +# contributions to performance: +# +# * Hardware capabilities and configuration +# * Software configuration and capabilities +# * Dynamic effects of the system in operation and the system working together +# with eventually multiple computers, especially when these have to exchange +# information across a network. +# +# At the most basic level users may wish to document how long e.g. a data +# analysis with a scientific software (app). +# A frequent idea is here to judge how critical the effect is on the workflow +# of the scientists, i.e. is the analysis possible in a few seconds or would it +# take days if I were to run this analysis on a comparable machine. In this case, +# mainly the order of magnitude is relevant, as well as how this can be achieved +# with using parallelization (i.e. reporting the number of CPU and GPU resources +# used, the number of processes and/or threads, and basic details about the +# computing node/computer. +# +# At more advanced levels benchmarks may go as deep as detailed temporal tracking +# of individual processor instructions, their relation to other instructions, the +# state of call stacks, in short eventually the entire app execution history +# and hardware state history. Such analyses are mainly used for performance +# optimization as well as for tracking bugs and other development purposes. +# Specialized software exists which documents such performance data in +# specifically-formatted event log files or databases. +# +# This base class cannot and should not replace these specific solutions. +# Instead, the intention of the base class is to serve scientists at the +# basic level to enable simple monitoring of performance data and log profiling +# data of key algorithmic steps or parts of computational workflows, so that +# these pieces of information can guide users which order of magnitude differences +# should be expected or not. +# +# Developers of application definitions should add additional fields and +# references to e.g. more detailed performance data to which they wish to link +# the metadata in this base class. +# +# +# +# +# Path to the directory from which the tool was called. +# +# +# +# +# Command line call with arguments if applicable. +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC information +# included when the app was started. +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC information +# included when the app terminated or crashed. +# +# +# +# +# Wall-clock time how long the app execution took. This may be in principle +# end_time minus start_time; however usage of eventually more precise timers +# may warrant to use a finer temporal discretization, +# and thus demand a more precise record of the wall-clock time. +# +# +# +# +# Qualifier which specifies with how many nominal processes the app was +# invoked. The main idea behind this field, for instance for app using a +# Message Passing Interface parallelization is to communicate how many +# processes were used. +# +# For sequentially running apps number_of_processes and number_of_threads +# is 1. If the app uses exclusively GPU parallelization number_of_gpus +# can be larger than 1. If no GPU is used number_of_gpus is 0 even though +# the hardware may have GPUs installed, thus indicating these were not +# used though. +# +# +# +# +# Qualifier with how many nominal threads were accessible to the app at +# runtime. Specifically here the maximum number of threads used for the +# high-level threading library used (e.g. OMP_NUM_THREADS), posix. +# +# +# +# +# Qualifier with how many nominal GPUs the app was invoked at runtime. +# +# +# +# +# +# A collection with one or more computing nodes each with own resources. +# This can be as simple as a laptop or the nodes of a cluster computer. +# +# +# +# +# A collection of individual profiling event data which detail e.g. how +# much time the app took for certain computational steps and/or how much +# memory was consumed during these operations. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcs_profiling_event.yaml b/contributed_definitions/nyaml/NXcs_profiling_event.yaml new file mode 100644 index 0000000000..6f6f7a5ab8 --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_profiling_event.yaml @@ -0,0 +1,153 @@ +category: base +doc: | + Computer science description of a profiling event. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_processes: | + Number of processes. +type: group +NXcs_profiling_event(NXobject): + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking started. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + included when the event tracking ended. + description: + doc: | + Free-text description what was monitored/executed during the event. + elapsed_time(NX_NUMBER): + unit: NX_TIME + doc: | + Wall-clock time how long the event took. This may be in principle + end_time minus start_time; however usage of eventually more precise timers + may warrant to use a finer temporal discretization, + and thus demand a more precise record of the wall-clock time. + Elapsed time may contain time portions where resources were idling. + number_of_processes(NX_POSINT): + unit: NX_UNITLESS + doc: | + Number of processes used (max) during the execution of this event. + number_of_threads(NX_POSINT): + unit: NX_UNITLESS + doc: | + Number of threads used (max) during the execution of this event. + number_of_gpus(NX_POSINT): + unit: NX_UNITLESS + doc: | + Number of GPUs used (max) during the execution of this event. + max_virtual_memory_snapshot(NX_NUMBER): + unit: NX_ANY + doc: | + Maximum amount of virtual memory allocated per process during the event. + dimensions: + rank: 1 + dim: [[1, n_processes]] + max_resident_memory_snapshot(NX_NUMBER): + unit: NX_ANY + doc: | + Maximum amount of resident memory allocated per process during the event. + dimensions: + rank: 1 + dim: [[1, n_processes]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e8b200086f4231ee711a2a4e13cd93c016c5291518d3a255e0bb9348da3d96b1 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of processes. +# +# +# +# +# Computer science description of a profiling event. +# +# +# +# ISO 8601 time code with local time zone offset to UTC information +# included when the event tracking started. +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC information +# included when the event tracking ended. +# +# +# +# +# Free-text description what was monitored/executed during the event. +# +# +# +# +# Wall-clock time how long the event took. This may be in principle +# end_time minus start_time; however usage of eventually more precise timers +# may warrant to use a finer temporal discretization, +# and thus demand a more precise record of the wall-clock time. +# Elapsed time may contain time portions where resources were idling. +# +# +# +# +# Number of processes used (max) during the execution of this event. +# +# +# +# +# Number of threads used (max) during the execution of this event. +# +# +# +# +# Number of GPUs used (max) during the execution of this event. +# +# +# +# +# Maximum amount of virtual memory allocated per process during the event. +# +# +# +# +# +# +# +# Maximum amount of resident memory allocated per process during the event. +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXcsg.yaml b/contributed_definitions/nyaml/NXcsg.yaml new file mode 100644 index 0000000000..e7f408c7a2 --- /dev/null +++ b/contributed_definitions/nyaml/NXcsg.yaml @@ -0,0 +1,119 @@ +category: base +doc: | + Constructive Solid Geometry base class, using :ref:`NXquadric` and :ref:`NXoff_geometry` +type: group +NXcsg(NXobject): + operation: + doc: | + One of the standard construction solid geometry set operations, + or if the CSG is a pointer to the geometry provided by an + :ref:`NXquadric` or an :ref:`NXoff_geometry`. Takes values: + enumeration: [UNION, INTERSECTION, DIFFERENCE, COMPLEMENT, IS_QUADRIC, IS_MESH] + a(NXcsg): + exists: ['min', '0', 'max', '1'] + doc: | + The first operand of constructive solid geometry + operation. Compulsory if 'operation' is UNION, INTERSECTION, + DIFFERENCE or COMPLEMENT. + b(NXcsg): + exists: ['min', '0', 'max', '1'] + doc: | + The second operand of constructive solid geometry + operation. Compulsory if 'operation' is UNION, INTERSECTION or + DIFFERENCE. + geometry(NX_CHAR): + exists: ['min', '0', 'max', '1'] + doc: | + Path to a field that is either an :ref:`NXquadric` (if + 'operation' = IS_QUADRIC) or an :ref:`NXoff_geometry` (if + 'operation' = IS_MESH) that defines the surface making up the + constructive solid geometry component. Compulsory if 'operation' + is IS_QUADRIC or IS_MESH. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 26b9cbb33ac382f8758dc8bda210c12a550d888e5d33c1a0e662e9671d2788db +# +# +# +# +# +# Constructive Solid Geometry base class, using :ref:`NXquadric` and :ref:`NXoff_geometry` +# +# +# One of the standard construction solid geometry set operations, +# or if the CSG is a pointer to the geometry provided by an +# :ref:`NXquadric` or an :ref:`NXoff_geometry`. Takes values: +# +# +# +# +# +# +# +# +# +# +# +# +# The first operand of constructive solid geometry +# operation. Compulsory if 'operation' is UNION, INTERSECTION, +# DIFFERENCE or COMPLEMENT. +# +# +# +# +# The second operand of constructive solid geometry +# operation. Compulsory if 'operation' is UNION, INTERSECTION or +# DIFFERENCE. +# +# +# +# +# Path to a field that is either an :ref:`NXquadric` (if +# 'operation' = IS_QUADRIC) or an :ref:`NXoff_geometry` (if +# 'operation' = IS_MESH) that defines the surface making up the +# constructive solid geometry component. Compulsory if 'operation' +# is IS_QUADRIC or IS_MESH. +# +# +# diff --git a/contributed_definitions/nyaml/NXcxi_ptycho.yaml b/contributed_definitions/nyaml/NXcxi_ptycho.yaml new file mode 100644 index 0000000000..1b68b54452 --- /dev/null +++ b/contributed_definitions/nyaml/NXcxi_ptycho.yaml @@ -0,0 +1,440 @@ +category: application +doc: | + Application definition for a ptychography experiment, compatible with CXI from version 1.6. + + This is compatible with CXI from version 1.6 if this application definition + is put at the top "entry" level. Above this a "cxi_version" field should be defined. The CXI format is name based, rather than class based, and so it is important + to pay attention to the naming convention to be CXI compatible. There are duplications due to the format merger. These should be achieved by linking, + with hdf5 Virtual Dataset being used to restructure any data that needs to be remapped. To be fully CXI compatible, all units (including energy) must be in SI units. + + An example here is that CXI expects the data to always to have shape (npts_x*npts_y, frame_size_x, frame_size_y). For nexus this is only true for arbitrary scan paths + with raster format scans taking shape (npts_x, npts_y, frame_size_x, frame_size_y). +symbols: + doc: | + These symbols will be used below to coordinate the shapes of the datasets. + npts_x: | + The number of points in the x direction + npts_y: | + Number of points in the y direction. + frame_size_x: | + Number of detector pixels in x + frame_size_y: | + Number of detector pixels in y +type: group +NXcxi_ptycho(NXobject): + (NXentry)entry_1: + title: + exists: ['min', '0', 'max', '1'] + start_time(NX_DATE_TIME): + exists: ['min', '0', 'max', '1'] + end_time(NX_DATE_TIME): + exists: ['min', '0', 'max', '1'] + definition(NX_CHAR): + exists: ['min', '1', 'max', '1'] + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXcxi_ptycho] + (NXinstrument)instrument_1: + exists: ['min', '1', 'max', '1'] + (NXsource)source_1: + exists: ['min', '1', 'max', '1'] + name(NX_CHAR): + exists: ['min', '1', 'max', '1'] + energy(NX_FLOAT): + exists: ['min', '1', 'max', '1'] + doc: | + This is the energy of the machine, not the beamline. + probe(NX_FLOAT): + exists: ['min', '1', 'max', '1'] + type(NX_FLOAT): + exists: ['min', '1', 'max', '1'] + (NXbeam)beam_1: + exists: ['min', '1', 'max', '1'] + energy(NX_FLOAT): + exists: ['min', '1', 'max', '1'] + \@units: + type: NX_CHAR + exists: optional + extent(NX_FLOAT): + exists: ['min', '0', 'max', '1'] + \@units: + type: NX_CHAR + exists: optional + incident_beam_divergence(NX_FLOAT): + exists: ['min', '0', 'max', '1'] + \@units: + type: NX_CHAR + exists: optional + incident_beam_energy(NX_FLOAT): + exists: ['min', '1', 'max', '1'] + \@units: + type: NX_CHAR + exists: optional + incident_energy_spread(NX_FLOAT): + exists: ['min', '1', 'max', '1'] + \@units: + type: NX_CHAR + exists: optional + (NXdetector)detector_1: + exists: ['min', '1', 'max', '1'] + \@axes: + type: NX_CHAR + doc: | + should have value "[, data]" + \@signal: + type: NX_CHAR + doc: | + should have value "data" + (NXtransformations)transformations: + vector(NX_NUMBER): + exists: ['min', '1', 'max', '1'] + translation(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '1', 'max', '1'] + doc: | + This is an array of shape (npts_x*npts_y, 3) and can be a Virtual Dataset of x and y + \@units: + type: NX_CHAR + exists: optional + \@axes: + exists: optional + type: NX_CHAR + doc: | + this should take the value "translation:$slowaxisname:$fastaxisname" + \@interpretation: + exists: optional + type: NX_CHAR + doc: | + This should be "image" + data(NX_INT): + signal: 1 + exists: ['min', '1', 'max', '1'] + dimensions: + rank: 3 for arbitrary scan, 4 for raster + dim: [[1, npts_x], [2, npts_y], [3, frame_size_x], [4, frame_size_y]] + data_1(link): + target: /NXentry/NXinstrument/NXdetector/data + doc: | + This data must always have shape (npts_x*npts_y, frame_size_x, frame_size_y) regardless + of the scan pattern. Use hdf5 virtual dataset to achieve this. + x_pixel_size(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '1', 'max', '1'] + \@units: + type: NX_CHAR + exists: optional + y_pixel_size(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '1', 'max', '1'] + \@units: + type: NX_CHAR + exists: optional + distance(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '1', 'max', '1'] + doc: | + The distance between the detector and the sample + \@units: + type: NX_CHAR + exists: optional + beam_center_x(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + \@units: + type: NX_CHAR + exists: optional + beam_center_y(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + \@units: + type: NX_CHAR + exists: optional + (NXmonitor): + exists: ['min', '0', 'max', '1'] + data(NX_FLOAT): + dimensions: + rank: 1 for arbitrary scan, 2 for raster + dim: [[1, npts_x], [2, npts_y]] + (NXdata): + exists: ['min', '1', 'max', '1'] + \@axes: + type: NX_CHAR + exists: optional + doc: | + This should be "[x,.]" for arbitrary scanning patterns, and "[x,.,.]" for raster + \@signal: + type: NX_CHAR + exists: optional + doc: | + This should be "data" + data(link): + target: /NXentry/NXinstrument/NXdetector/data + x(link): + target: /NXentry/NXsample/NXtransformations/x + y(link): + target: /NXentry/NXsample/NXtransformations/y + x_indices(NX_CHAR): + y_indices(NX_CHAR): + (NXcollection)data_1: + exists: ['min', '1', 'max', '1'] + doc: | + To ensure CXI compatibility the data in this group must always have shape that is + (npts_x*npts_y, frame_size_x, frame_size_y). For nexus-style raster scans it is proposed that + hdf5 virtual dataset is used. + data(link): + target: /NXentry/NXinstrument/NXdetector/data + translation(link): + target: /NXentry/NXinstrument/NXdetector/translation + (NXsample)sample_1: + exists: ['min', '1', 'max', '1'] + name(NX_CHAR): + exists: ['min', '0', 'max', '1'] + transformations(NXtransformations): + doc: | + This must contain two fields with the x and y motors that are linked via the + dependency tree according to the real-life motor layout dependency. + For raster scans x and y will have shape (npts_x, npts_y) + For arbitrary scans x and y will be (npts_x*npts_y,) + An attribute with the units for each motor is required. + \@vector: + exists: optional + type: NX_NUMBER + (NXcollection)geometry_1: + exists: ['min', '1', 'max', '1'] + translation(link): + target: /NXentry/NXinstrument/NXdetector/translation + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# cc83e17501fdd8eab38f6229fd41422c15a196db1698921004af9d9736c9cb83 +# +# +# +# +# +# +# These symbols will be used below to coordinate the shapes of the datasets. +# +# +# +# +# The number of points in the x direction +# +# +# +# +# +# Number of points in the y direction. +# +# +# +# +# Number of detector pixels in x +# +# +# +# +# +# Number of detector pixels in y +# +# +# +# +# +# Application definition for a ptychography experiment, compatible with CXI from version 1.6. +# +# This is compatible with CXI from version 1.6 if this application definition +# is put at the top "entry" level. Above this a "cxi_version" field should be defined. The CXI format is name based, rather than class based, and so it is important +# to pay attention to the naming convention to be CXI compatible. There are duplications due to the format merger. These should be achieved by linking, +# with hdf5 Virtual Dataset being used to restructure any data that needs to be remapped. To be fully CXI compatible, all units (including energy) must be in SI units. +# +# An example here is that CXI expects the data to always to have shape (npts_x*npts_y, frame_size_x, frame_size_y). For nexus this is only true for arbitrary scan paths +# with raster format scans taking shape (npts_x, npts_y, frame_size_x, frame_size_y). +# +# +# +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# +# +# +# +# This is the energy of the machine, not the beamline. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# should have value "[, data]" +# +# +# +# +# should have value "data" +# +# +# +# +# +# +# +# This is an array of shape (npts_x*npts_y, 3) and can be a Virtual Dataset of x and y +# +# +# +# +# this should take the value "translation:$slowaxisname:$fastaxisname" +# +# +# +# +# This should be "image" +# +# +# +# +# +# +# +# +# +# +# +# +# +# This data must always have shape (npts_x*npts_y, frame_size_x, frame_size_y) regardless +# of the scan pattern. Use hdf5 virtual dataset to achieve this. +# +# +# +# +# +# +# +# +# +# +# The distance between the detector and the sample +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# This should be "[x,.]" for arbitrary scanning patterns, and "[x,.,.]" for raster +# +# +# +# +# This should be "data" +# +# +# +# +# +# +# +# +# +# +# To ensure CXI compatibility the data in this group must always have shape that is +# (npts_x*npts_y, frame_size_x, frame_size_y). For nexus-style raster scans it is proposed that +# hdf5 virtual dataset is used. +# +# +# +# +# +# +# +# +# +# This must contain two fields with the x and y motors that are linked via the +# dependency tree according to the real-life motor layout dependency. +# For raster scans x and y will have shape (npts_x, npts_y) +# For arbitrary scans x and y will be (npts_x*npts_y,) +# An attribute with the units for each motor is required. +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXdac.yaml b/contributed_definitions/nyaml/NXdac.yaml new file mode 100644 index 0000000000..f0b09372b2 --- /dev/null +++ b/contributed_definitions/nyaml/NXdac.yaml @@ -0,0 +1,53 @@ +category: base +doc: | + Digital-to-analog converter component/integrated circuit. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXdac(NXobject): + value(NX_NUMBER): + unit: NX_UNITLESS + doc: | + TBD. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 3126ae3b0a957ca0a5ab3d91942ccee0c849665d53ec3cf085dee4f2fc420899 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Digital-to-analog converter component/integrated circuit. +# +# +# +# TBD. +# +# +# diff --git a/contributed_definitions/nyaml/NXdeflector.yaml b/contributed_definitions/nyaml/NXdeflector.yaml new file mode 100644 index 0000000000..48bbdea64f --- /dev/null +++ b/contributed_definitions/nyaml/NXdeflector.yaml @@ -0,0 +1,143 @@ +category: base +doc: | + Deflectors as they are used e.g. in an electron analyser. +type: group +NXdeflector(NXobject): + type: + doc: | + Qualitative type of deflector with respect to the number of pole pieces + enumeration: [dipole, quadrupole, hexapole, octupole] + name: + doc: | + Colloquial or short name for the deflector. For manufacturer names and + identifiers use respective manufacturer fields. + manufacturer_name: + doc: | + Name of the manufacturer who built/constructed the deflector. + manufacturer_model: + doc: | + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the deflector. + description: + doc: | + Ideally an identifier, persistent link, or free text which gives further details + about the deflector. + voltage(NX_NUMBER): + unit: NX_VOLTAGE + doc: | + Excitation voltage of the deflector. For dipoles it is a single number. For + higher orders, it is an array. + current(NX_NUMBER): + unit: NX_CURRENT + doc: | + Excitation current of the deflector. For dipoles it is a single number. For + higher orders, it is an array. + depends_on(NX_CHAR): + doc: | + Specifies the position of the deflector by pointing to the last transformation + in the transformation chain in the NXtransformations group. + (NXtransformations): + doc: | + Collection of axis-based translations and rotations to describe the location and + geometry of the deflector as a component in the instrument. Conventions from the + NXtransformations base class are used. In principle, the McStas coordinate + system is used. The first transformation has to point either to another + component of the system or . (for pointing to the reference frame) to relate it + relative to the experimental setup. Typically, the components of a system should + all be related relative to each other and only one component should relate to + the reference coordinate system. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# cc60e5e60fa6b89b66dcf4a780b213a0001d8fba76a73032bdd0f2bdada410a7 +# +# +# +# +# +# Deflectors as they are used e.g. in an electron analyser. +# +# +# +# Qualitative type of deflector with respect to the number of pole pieces +# +# +# +# +# +# +# +# +# +# +# Colloquial or short name for the deflector. For manufacturer names and +# identifiers use respective manufacturer fields. +# +# +# +# +# Name of the manufacturer who built/constructed the deflector. +# +# +# +# +# Hardware name, hash identifier, or serial number that was given by the +# manufacturer to identify the deflector. +# +# +# +# +# Ideally an identifier, persistent link, or free text which gives further details +# about the deflector. +# +# +# +# +# Excitation voltage of the deflector. For dipoles it is a single number. For +# higher orders, it is an array. +# +# +# +# +# Excitation current of the deflector. For dipoles it is a single number. For +# higher orders, it is an array. +# +# +# +# +# Specifies the position of the deflector by pointing to the last transformation +# in the transformation chain in the NXtransformations group. +# +# +# +# +# Collection of axis-based translations and rotations to describe the location and +# geometry of the deflector as a component in the instrument. Conventions from the +# NXtransformations base class are used. In principle, the McStas coordinate +# system is used. The first transformation has to point either to another +# component of the system or . (for pointing to the reference frame) to relate it +# relative to the experimental setup. Typically, the components of a system should +# all be related relative to each other and only one component should relate to +# the reference coordinate system. +# +# +# diff --git a/contributed_definitions/nyaml/NXdelocalization.yaml b/contributed_definitions/nyaml/NXdelocalization.yaml new file mode 100644 index 0000000000..77bdadd6ea --- /dev/null +++ b/contributed_definitions/nyaml/NXdelocalization.yaml @@ -0,0 +1,242 @@ +category: base +doc: | + Base class to describe the delocalization of point-like objects on a grid. + + Such a procedure is for instance used in image processing and e.g. atom probe + microscopy (APM) to discretize a point cloud onto a grid to enable e.g. + computing of point density, composition, or concentration values, obtain + scalar fields, and compute gradients of these fields. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_p: | + Number of points/objects. + n_m: | + Number of mark data per point/object. + n_atoms: | + Number of atoms in the whitelist. + n_isotopes: | + Number of isotopes in the whitelist. +type: group +NXdelocalization(NXobject): + grid: + doc: | + Reference or link to the grid on which the delocalization is applied. + objects: + doc: | + Reference or link to the points which are delocalized on the grid. + + # for APM the speciality is nothing but: + # each point marks the location of an ion (object) in the tomographic reconstruction + # there is a boolean mask which filters which ions, i.e. points are considered + # plus there is a weight interpretation model, specifically in atom probe + # if a (molecular) ion is decomposed into its atoms or isotopes + # plus, given there is such a weight interpretation model, there is a weight + # associated, specifically an integer >= 1 with each considered ion and 0 for + # all ions which are not considered, + # this weight is the multiplicity with respect to the interpretation model + # i.e. a C:2 molecular ion has a multiplicity of 2 if the ion is considered + # and the interpretation model that to consider carbon atoms or carbon ions + weighting_model: + doc: | + The weighting model specifies how mark data are mapped to a weight per point. + For atom probe microscopy (APM) as an example, different models are used which + account differently for the multiplicity of an ion/atom: + + * default, points all get the same weight 1.; + for APM this is equivalent to ion species + * atomic_decomposition, points get as much weight as they have atoms + of a type in element_whitelist, + * isotope_decomposition, points get as much weight as they have + isotopes of a type in isotope_whitelist. + + This description shows an example that could be reinterpreted for + similar such data processing steps in other fields of science. + enumeration: [default, atomic_decomposition, isotope_decomposition] + + # other + # can one conditionally set a field required if a weighting_model has a + # specific value, + # i.e. if atomic_decomposition is set element_whitelist t is required + # i.e. if isotope_decomposition is set isotope_whitelist is required? + element_whitelist(NX_UINT): + unit: NX_UNITLESS + doc: | + A list of elements (via proton number) to consider for the atomic_decomposition + weighting model. Elements must exist in the periodic table of elements. + dimensions: + rank: 1 + dim: [[1, n_atoms]] + isotope_whitelist(NX_UINT): + unit: NX_UNITLESS + doc: | + A list of isotopes to consider for the isotope_decomposition weighting model. + Isotopes must exist in the nuclid table. Entries in the fastest changing + dimension should be the pair of proton (first entry) and neutron number + (second entry). + dimensions: + rank: 2 + dim: [[1, n_isotopes], [2, 2]] + mark(NX_NUMBER): + doc: | + Attribute data for each member of the point cloud. For APM these are the + ion species labels generated via ranging. The number of mark data per + point is 1 in the case for atom probe. + dimensions: + rank: 2 + dim: [[1, n_p], [2, n_m]] + weight(NX_NUMBER): + doc: | + Weighting factor with which the integrated intensity per grid cell is + multiplied specifically for each point. For APM the weight are positive + integer values, specifically the multiplicity of the ion, + according to the details of the weighting_model. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 38d91286faad0b8ce9904853bb66690d59cd3f393af678be595bd38812c6845d +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of points/objects. +# +# +# +# +# Number of mark data per point/object. +# +# +# +# +# Number of atoms in the whitelist. +# +# +# +# +# Number of isotopes in the whitelist. +# +# +# +# +# Base class to describe the delocalization of point-like objects on a grid. +# +# Such a procedure is for instance used in image processing and e.g. atom probe +# microscopy (APM) to discretize a point cloud onto a grid to enable e.g. +# computing of point density, composition, or concentration values, obtain +# scalar fields, and compute gradients of these fields. +# +# +# +# Reference or link to the grid on which the delocalization is applied. +# +# +# +# +# Reference or link to the points which are delocalized on the grid. +# +# +# +# +# +# The weighting model specifies how mark data are mapped to a weight per point. +# For atom probe microscopy (APM) as an example, different models are used which +# account differently for the multiplicity of an ion/atom: +# +# * default, points all get the same weight 1.; +# for APM this is equivalent to ion species +# * atomic_decomposition, points get as much weight as they have atoms +# of a type in element_whitelist, +# * isotope_decomposition, points get as much weight as they have +# isotopes of a type in isotope_whitelist. +# +# This description shows an example that could be reinterpreted for +# similar such data processing steps in other fields of science. +# +# +# +# +# +# +# +# +# +# +# A list of elements (via proton number) to consider for the atomic_decomposition +# weighting model. Elements must exist in the periodic table of elements. +# +# +# +# +# +# +# +# A list of isotopes to consider for the isotope_decomposition weighting model. +# Isotopes must exist in the nuclid table. Entries in the fastest changing +# dimension should be the pair of proton (first entry) and neutron number +# (second entry). +# +# +# +# +# +# +# +# +# Attribute data for each member of the point cloud. For APM these are the +# ion species labels generated via ranging. The number of mark data per +# point is 1 in the case for atom probe. +# +# +# +# +# +# +# +# +# Weighting factor with which the integrated intensity per grid cell is +# multiplied specifically for each point. For APM the weight are positive +# integer values, specifically the multiplicity of the ion, +# according to the details of the weighting_model. +# +# +# diff --git a/contributed_definitions/nyaml/NXdispersion.yaml b/contributed_definitions/nyaml/NXdispersion.yaml new file mode 100644 index 0000000000..cd0be114f2 --- /dev/null +++ b/contributed_definitions/nyaml/NXdispersion.yaml @@ -0,0 +1,52 @@ +category: base +doc: | + A dispersion denoting a sum of different dispersions. + All NXdispersion_table and NXdispersion_function groups will be added together + to form a single dispersion. +type: group +NXdispersion(NXobject): + model_name(NX_CHAR): + doc: | + The name of the composite model. + (NXdispersion_table): + (NXdispersion_function): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 5382258a260b96c72eca642ef6d4c506d5a29926787e0cd5f66dafc96f75fef2 +# +# +# +# +# +# A dispersion denoting a sum of different dispersions. +# All NXdispersion_table and NXdispersion_function groups will be added together +# to form a single dispersion. +# +# +# +# The name of the composite model. +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXdispersion_function.yaml b/contributed_definitions/nyaml/NXdispersion_function.yaml new file mode 100644 index 0000000000..da0740742a --- /dev/null +++ b/contributed_definitions/nyaml/NXdispersion_function.yaml @@ -0,0 +1,205 @@ +category: base +doc: | + This describes a dispersion function for a material or layer +symbols: + n_repetitions: | + The number of repetitions for the repeated parameters +type: group +NXdispersion_function(NXobject): + model_name(NX_CHAR): + doc: | + The name of this dispersion model. + formula(NX_CHAR): + doc: | + This should be a python parsable function. + Here we should provide which keywords are available + and a BNF of valid grammar. + convention(NX_CHAR): + doc: | + The sign convention being used (n + or - ik) + enumeration: [n + ik, n - ik] + energy_identifier(NX_CHAR): + doc: | + The identifier used to represent energy + in the formula. It is recommended to use `E`. + energy_min(NX_NUMBER): + unit: NX_ENERGY + doc: | + The minimum energy value at which this formula is valid. + energy_max(NX_NUMBER): + unit: NX_ENERGY + doc: | + The maximum energy value at which this formula is valid. + energy_unit(NX_NUMBER): + unit: NX_ENERGY + doc: | + The energy unit used in the formula. + The field value is a scaling factor for the units attribute. + It is recommeded to set the field value to 1 and carry all the unit + scaling information in the units attribute. + wavelength_identifier(NX_CHAR): + doc: | + The identifier useed to represent wavelength + in the formula. It is recommended to use `lambda`. + wavelength_unit(NX_NUMBER): + unit: NX_LENGTH + doc: | + The wavelength unit used in the formula. + The field value is a scaling factor for the units attribute. + It is recommeded to set the field value to 1 and carry all the unit + scaling information in the units attribute. + wavelength_min(NX_NUMBER): + unit: NX_LENGTH + doc: | + The minimum wavelength value at which this formula is valid. + wavelength_max(NX_NUMBER): + unit: NX_LENGTH + doc: | + The maximum wavelength value at which this formula is valid. + representation(NX_CHAR): + doc: | + Which representation does the formula evaluate to. + This may either be n for refractive index or eps for dielectric function. + The appropriate token is then to be used inside the formula. + enumeration: [n, eps] + (NXdispersion_single_parameter): + (NXdispersion_repeated_parameter): + parameter_units: + dimensions: + rank: 1 + dim: [[1, n_repetitions]] + values(NX_NUMBER): + dimensions: + rank: 1 + dim: [[1, n_repetitions]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# c0b64c8c239e3f7d61b847ae27ab22bb5aa9c642e5ad6f3439cbacfde217e996 +# +# +# +# +# +# +# +# The number of repetitions for the repeated parameters +# +# +# +# +# This describes a dispersion function for a material or layer +# +# +# +# The name of this dispersion model. +# +# +# +# +# This should be a python parsable function. +# Here we should provide which keywords are available +# and a BNF of valid grammar. +# +# +# +# +# The sign convention being used (n + or - ik) +# +# +# +# +# +# +# +# +# The identifier used to represent energy +# in the formula. It is recommended to use `E`. +# +# +# +# +# The minimum energy value at which this formula is valid. +# +# +# +# +# The maximum energy value at which this formula is valid. +# +# +# +# +# The energy unit used in the formula. +# The field value is a scaling factor for the units attribute. +# It is recommeded to set the field value to 1 and carry all the unit +# scaling information in the units attribute. +# +# +# +# +# The identifier useed to represent wavelength +# in the formula. It is recommended to use `lambda`. +# +# +# +# +# The wavelength unit used in the formula. +# The field value is a scaling factor for the units attribute. +# It is recommeded to set the field value to 1 and carry all the unit +# scaling information in the units attribute. +# +# +# +# +# The minimum wavelength value at which this formula is valid. +# +# +# +# +# The maximum wavelength value at which this formula is valid. +# +# +# +# +# Which representation does the formula evaluate to. +# This may either be n for refractive index or eps for dielectric function. +# The appropriate token is then to be used inside the formula. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXdispersion_repeated_parameter.yaml b/contributed_definitions/nyaml/NXdispersion_repeated_parameter.yaml new file mode 100644 index 0000000000..409661bce9 --- /dev/null +++ b/contributed_definitions/nyaml/NXdispersion_repeated_parameter.yaml @@ -0,0 +1,99 @@ +category: base +doc: | + A repeated parameter for a dispersion function +symbols: + n_repetitions: | + The number of parameter repetitions +type: group +NXdispersion_repeated_parameter(NXobject): + name(NX_CHAR): + doc: | + The name of the parameter + description(NX_CHAR): + doc: | + A description of what this parameter represents + parameter_units(NX_CHAR): + doc: | + A unit array associating a unit with each parameter. + The first element should be equal to values/@unit. + The values should be SI interpretable standard units + with common prefixes (e.g. mikro, nano etc.) or their + short-hand notation (e.g. nm, mm, kHz etc.). + dimensions: + rank: 1 + dim: [[1, n_repetitions]] + values(NX_NUMBER): + unit: NX_ANY + doc: | + The value of the parameter + dimensions: + rank: 1 + dim: [[1, n_repetitions]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 3333e10082e0d2c7f774ca993b5f12377856ab5887a0b088ab8b1a064991ab80 +# +# +# +# +# +# +# +# The number of parameter repetitions +# +# +# +# +# A repeated parameter for a dispersion function +# +# +# +# The name of the parameter +# +# +# +# +# A description of what this parameter represents +# +# +# +# +# A unit array associating a unit with each parameter. +# The first element should be equal to values/@unit. +# The values should be SI interpretable standard units +# with common prefixes (e.g. mikro, nano etc.) or their +# short-hand notation (e.g. nm, mm, kHz etc.). +# +# +# +# +# +# +# +# The value of the parameter +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXdispersion_single_parameter.yaml b/contributed_definitions/nyaml/NXdispersion_single_parameter.yaml new file mode 100644 index 0000000000..7a06de9bfe --- /dev/null +++ b/contributed_definitions/nyaml/NXdispersion_single_parameter.yaml @@ -0,0 +1,61 @@ +category: base +doc: | + A single parameter for a dispersion function +type: group +NXdispersion_single_parameter(NXobject): + name(NX_CHAR): + doc: | + The name of the parameter + description(NX_CHAR): + doc: | + A description of what this parameter represents + value(NX_NUMBER): + unit: NX_ANY + doc: | + The value of the parameter + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# f6f6c5dec785743e0c0f8b5fb70942367b1a4a0ccfe010705015f22bd95c204c +# +# +# +# +# +# A single parameter for a dispersion function +# +# +# +# The name of the parameter +# +# +# +# +# A description of what this parameter represents +# +# +# +# +# The value of the parameter +# +# +# diff --git a/contributed_definitions/nyaml/NXdispersion_table.yaml b/contributed_definitions/nyaml/NXdispersion_table.yaml new file mode 100644 index 0000000000..862c88718a --- /dev/null +++ b/contributed_definitions/nyaml/NXdispersion_table.yaml @@ -0,0 +1,140 @@ +category: base +doc: | + A dispersion table denoting energy, dielectric function tabulated values. +symbols: + doc: | + The symbols in this schema to denote the dimensions + n_points: | + The number of energy and dielectric function points +type: group +NXdispersion_table(NXobject): + model_name(NX_CHAR): + doc: | + The name of this dispersion model. + convention(NX_CHAR): + doc: | + The sign convention being used (n + or - ik) + enumeration: [n + ik, n - ik] + wavelength(NX_NUMBER): + unit: NX_LENGTH + doc: | + The wavelength array of the tabulated dataset. + This is essentially a duplicate of the energy field. + There should be one or both of them present. + dimensions: + rank: 1 + dim: [[1, n_points]] + energy(NX_NUMBER): + unit: NX_ENERGY + doc: | + The energy array of the tabulated dataset. + This is essentially a duplicate of the wavelength field. + There should be one or both of them present. + dimensions: + rank: 1 + dim: [[1, n_points]] + refractive_index(NX_COMPLEX): + unit: NX_DIMENSIONLESS + doc: | + The refractive index array of the tabulated dataset. + dimensions: + rank: 1 + dim: [[1, n_points]] + dielectric_function(NX_COMPLEX): + unit: NX_DIMENSIONLESS + doc: | + The dielectric function of the tabulated dataset. + dimensions: + rank: 1 + dim: [[1, n_points]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 48116286e10a8ebd5f05be03756160d199447b78a8e587616d23061a3e1c8c50 +# +# +# +# +# +# +# The symbols in this schema to denote the dimensions +# +# +# +# The number of energy and dielectric function points +# +# +# +# +# A dispersion table denoting energy, dielectric function tabulated values. +# +# +# +# The name of this dispersion model. +# +# +# +# +# The sign convention being used (n + or - ik) +# +# +# +# +# +# +# +# +# The wavelength array of the tabulated dataset. +# This is essentially a duplicate of the energy field. +# There should be one or both of them present. +# +# +# +# +# +# +# +# The energy array of the tabulated dataset. +# This is essentially a duplicate of the wavelength field. +# There should be one or both of them present. +# +# +# +# +# +# +# +# The refractive index array of the tabulated dataset. +# +# +# +# +# +# +# +# The dielectric function of the tabulated dataset. +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXdispersive_material.yaml b/contributed_definitions/nyaml/NXdispersive_material.yaml new file mode 100644 index 0000000000..8a62ad66f1 --- /dev/null +++ b/contributed_definitions/nyaml/NXdispersive_material.yaml @@ -0,0 +1,409 @@ +category: application +doc: | + NXdispersion +type: group +NXdispersive_material(NXobject): + (NXentry): + definition: + doc: | + An application definition for a dispersive material. + \@version: + doc: | + Version number to identify which definition of this application definition was + used for this entry/data. + \@url: + doc: | + URL where to find further material (documentation, examples) relevant to the + application definition + enumeration: [NXdispersive_material] + sample(NXsample): + chemical_formula(NX_CHAR): + atom_types(NX_CHAR): + exists: optional + doc: | + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + colloquial_name(NX_CHAR): + exists: optional + doc: | + The colloquial name of the material, e.g. graphite or diamond for carbon. + material_phase(NX_CHAR): + exists: optional + doc: | + The phase of the material + enumeration: [gas, liquid, solid, other] + material_phase_comment(NX_CHAR): + exists: optional + doc: | + Additional information about the phase if the + material phase is other. + additional_phase_information(NX_CHAR): + exists: recommended + doc: | + This field may be used to denote additional phase information, + such as crystalin phase of a crystal (e.g. 4H or 6H for SiC) or + if a measurement was done on a thin film or bulk material. + dispersion_type(NX_CHAR): + exists: recommended + doc: | + Denotes whether the dispersion is calculated or derived from an experiment + enumeration: [measured, simulated] + REFERENCES(NXcite): + exists: recommended + text: + doc: | + A text description of this reference, e.g. + `E. Example et al, The mighty example, An example journal 50 (2023), 100` + doi: + dispersion_x(NXdispersion): + doc: | + The dispersion along the optical axis of the material. + This should be the only dispersion available for isotropic materials. + For uniaxial materials this denotes the ordinary axis. + For biaxial materials this denotes the x axis or epsilon 11 tensor element + of the diagionalized permittivity tensor. + model_name(NX_CHAR): + doc: | + The name of this dispersion model. + (NXdispersion_table): + exists: recommended + model_name: + convention: + wavelength(NX_NUMBER): + dielectric_function(NX_COMPLEX): + exists: recommended + refractive_index(NX_COMPLEX): + exists: recommended + (NXdispersion_function): + exists: recommended + model_name: + formula: + convention: + energy_identifier: + exists: recommended + energy_unit(NX_NUMBER): + exists: recommended + wavelength_identifier: + exists: recommended + wavelength_unit(NX_NUMBER): + exists: recommended + representation: + (NXdispersion_single_parameter): + name: + value(NX_NUMBER): + (NXdispersion_repeated_parameter): + name: + values(NX_NUMBER): + plot(NXdata): + exists: recommended + dispersion_y(NXdispersion): + exists: optional + doc: | + This should only be filled for biaxial materials. + It denotes the epsilon 22 direction of the diagionalized + permittivity tensor. + model_name(NX_CHAR): + doc: | + The name of this dispersion model. + (NXdispersion_table): + exists: recommended + model_name: + convention: + wavelength(NX_NUMBER): + dielectric_function(NX_COMPLEX): + exists: recommended + refractive_index(NX_COMPLEX): + exists: recommended + (NXdispersion_function): + exists: recommended + model_name: + formula: + convention: + energy_identifier: + exists: recommended + energy_unit(NX_NUMBER): + exists: recommended + wavelength_identifier: + exists: recommended + wavelength_unit(NX_NUMBER): + exists: recommended + representation: + (NXdispersion_single_parameter): + name: + value(NX_NUMBER): + (NXdispersion_repeated_parameter): + name: + values(NX_NUMBER): + plot(NXdata): + exists: recommended + dispersion_z(NXdispersion): + exists: optional + doc: | + This should only be filled for uniaxial or biaxial materials. + For uniaxial materials this denotes the extraordinary axis. + For biaxial materials this denotes the epsilon 33 tensor element + of the diagionalized perimittivty tensor. + model_name(NX_CHAR): + doc: | + The name of this dispersion model. + (NXdispersion_table): + exists: recommended + model_name: + convention: + wavelength(NX_NUMBER): + dielectric_function(NX_COMPLEX): + exists: recommended + refractive_index(NX_COMPLEX): + exists: recommended + (NXdispersion_function): + exists: recommended + model_name: + formula: + convention: + energy_identifier: + exists: recommended + energy_unit(NX_NUMBER): + exists: recommended + wavelength_identifier: + exists: recommended + wavelength_unit(NX_NUMBER): + exists: recommended + representation: + (NXdispersion_single_parameter): + name: + value(NX_NUMBER): + (NXdispersion_repeated_parameter): + name: + values(NX_NUMBER): + plot(NXdata): + exists: recommended + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 4f3fc95aec07d53a2d94428b85e9d688d916fc69844200218b2202ad3fb0f5b0 +# +# +# +# +# +# NXdispersion +# +# +# +# +# An application definition for a dispersive material. +# +# +# +# Version number to identify which definition of this application definition was +# used for this entry/data. +# +# +# +# +# URL where to find further material (documentation, examples) relevant to the +# application definition +# +# +# +# +# +# +# +# +# +# +# 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 colloquial name of the material, e.g. graphite or diamond for carbon. +# +# +# +# +# The phase of the material +# +# +# +# +# +# +# +# +# +# +# Additional information about the phase if the +# material phase is other. +# +# +# +# +# This field may be used to denote additional phase information, +# such as crystalin phase of a crystal (e.g. 4H or 6H for SiC) or +# if a measurement was done on a thin film or bulk material. +# +# +# +# +# +# Denotes whether the dispersion is calculated or derived from an experiment +# +# +# +# +# +# +# +# +# +# A text description of this reference, e.g. +# `E. Example et al, The mighty example, An example journal 50 (2023), 100` +# +# +# +# +# +# +# The dispersion along the optical axis of the material. +# This should be the only dispersion available for isotropic materials. +# For uniaxial materials this denotes the ordinary axis. +# For biaxial materials this denotes the x axis or epsilon 11 tensor element +# of the diagionalized permittivity tensor. +# +# +# +# The name of this dispersion model. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# This should only be filled for biaxial materials. +# It denotes the epsilon 22 direction of the diagionalized +# permittivity tensor. +# +# +# +# The name of this dispersion model. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# This should only be filled for uniaxial or biaxial materials. +# For uniaxial materials this denotes the extraordinary axis. +# For biaxial materials this denotes the epsilon 33 tensor element +# of the diagionalized perimittivty tensor. +# +# +# +# The name of this dispersion model. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXdistortion.yaml b/contributed_definitions/nyaml/NXdistortion.yaml new file mode 100644 index 0000000000..94c3d6b0a1 --- /dev/null +++ b/contributed_definitions/nyaml/NXdistortion.yaml @@ -0,0 +1,177 @@ +category: base +doc: | + Subclass of NXprocess to describe post-processing distortion correction. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays + nsym: | + Number of symmetry points used for distortion correction + ndx: | + Number of points of the matrix distortion field (x direction) + ndy: | + Number of points of the matrix distortion field (y direction) +type: group +NXdistortion(NXobject): + last_process(NX_CHAR): + doc: | + Indicates the name of the last operation applied in the NXprocess sequence. + applied(NX_BOOLEAN): + doc: | + Has the distortion correction been applied? + symmetry(NX_INT): + unit: NX_UNITLESS + doc: | + 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 + original_centre(NX_FLOAT): + unit: NX_UNITLESS + doc: | + For symmetry-guided distortion correction. Here we record the coordinates of the + symmetry centre point. + dimensions: + rank: 1 + dim: [[1, 2]] + original_points(NX_FLOAT): + unit: NX_UNITLESS + doc: | + For symmetry-guided distortion correction. Here we record the coordinates of the + relevant symmetry points. + dimensions: + rank: 2 + dim: [[1, nsym], [2, 2]] + cdeform_field(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Column deformation field for general non-rigid distortion corrections. 2D matrix + holding the column information of the mapping of each original coordinate. + dimensions: + rank: 2 + dim: [[1, ndx], [2, ndy]] + rdeform_field(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Row deformation field for general non-rigid distortion corrections. 2D matrix + holding the row information of the mapping of each original coordinate. + dimensions: + rank: 2 + dim: [[1, ndx], [2, ndy]] + description(NX_CHAR): + doc: | + Description of the procedures employed. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 8d4b961fbf0bfa0b579d13fcab264f3fba21c80b001620180e08bd4991d19fb1 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays +# +# +# +# Number of symmetry points used for distortion correction +# +# +# +# +# Number of points of the matrix distortion field (x direction) +# +# +# +# +# Number of points of the matrix distortion field (y direction) +# +# +# +# +# Subclass of NXprocess to describe post-processing distortion correction. +# +# +# +# Indicates the name of the last operation applied in the NXprocess sequence. +# +# +# +# +# Has the distortion correction been applied? +# +# +# +# +# For `symmetry-guided distortion correction`_, +# where a pattern of features is mapped to the regular geometric structure expected +# from the symmetry. Here we record the number of elementary symmetry operations. +# +# .. _symmetry-guided distortion correction: https://www.sciencedirect.com/science/article/abs/pii/S0304399118303474?via%3Dihub +# +# +# +# +# For symmetry-guided distortion correction. Here we record the coordinates of the +# symmetry centre point. +# +# +# +# +# +# +# +# For symmetry-guided distortion correction. Here we record the coordinates of the +# relevant symmetry points. +# +# +# +# +# +# +# +# +# Column deformation field for general non-rigid distortion corrections. 2D matrix +# holding the column information of the mapping of each original coordinate. +# +# +# +# +# +# +# +# +# Row deformation field for general non-rigid distortion corrections. 2D matrix +# holding the row information of the mapping of each original coordinate. +# +# +# +# +# +# +# +# +# Description of the procedures employed. +# +# +# diff --git a/contributed_definitions/nyaml/NXebeam_column.yaml b/contributed_definitions/nyaml/NXebeam_column.yaml new file mode 100644 index 0000000000..4ad5912c90 --- /dev/null +++ b/contributed_definitions/nyaml/NXebeam_column.yaml @@ -0,0 +1,176 @@ +category: base +doc: | + Container for components to form a controlled beam in electron microscopy. + +# symbols: +# doc: The symbols used in the schema to specify e.g. variables. +type: group +NXebeam_column(NXobject): + (NXfabrication): + electron_source(NXsource): + doc: | + The source which creates the electron beam. + name: + doc: | + Given name/alias. + (NXfabrication): + voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Voltage relevant to compute the energy of the electrons + immediately after they left the gun. + probe: + doc: | + Type of radiation. + enumeration: [electron] + emitter_type: + doc: | + Emitter type used to create the beam. + + If the emitter type is other, give further details + in the description field. + enumeration: [filament, schottky, cold_cathode_field_emitter, other] + emitter_material: + doc: | + Material of which the emitter is build, e.g. the filament material. + + #MK could be made an instance of NXsample + description: + doc: | + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + # NEW ISSUE: details about the life/up-time of the source + # relevant from maintenance point of view + (NXtransformations): + doc: | + Affine transformation which detail the arrangement in the + microscope relative to the optical axis and beam path. + (NXaperture_em): + (NXlens_em): + (NXcorrector_cs): + + # ebeam_deflector(NXscan_box_em): + (NXstage_lab): + (NXsensor): + doc: | + A sensor used to monitor an external or internal condition. + (NXbeam): + doc: | + Individual ocharacterization results for the position, shape, + and characteristics of the electron beam. + + NXtransformations should be used to specify the location + of the position at which the beam was probed. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 57dfa98a20b124029e11cfeaa6706766b0be01360a2157da1e4a60f463330f93 +# +# +# +# +# +# +# Container for components to form a controlled beam in electron microscopy. +# +# +# +# +# The source which creates the electron beam. +# +# +# +# Given name/alias. +# +# +# +# +# +# Voltage relevant to compute the energy of the electrons +# immediately after they left the gun. +# +# +# +# +# Type of radiation. +# +# +# +# +# +# +# +# Emitter type used to create the beam. +# +# If the emitter type is other, give further details +# in the description field. +# +# +# +# +# +# +# +# +# +# +# Material of which the emitter is build, e.g. the filament material. +# +# +# +# +# +# Ideally, a (globally) unique persistent identifier, link, +# or text to a resource which gives further details. +# +# +# +# +# +# Affine transformation which detail the arrangement in the +# microscope relative to the optical axis and beam path. +# +# +# +# +# +# +# +# +# +# +# A sensor used to monitor an external or internal condition. +# +# +# +# +# Individual ocharacterization results for the position, shape, +# and characteristics of the electron beam. +# +# NXtransformations should be used to specify the location +# of the position at which the beam was probed. +# +# +# diff --git a/contributed_definitions/nyaml/NXelectronanalyser.yaml b/contributed_definitions/nyaml/NXelectronanalyser.yaml new file mode 100644 index 0000000000..32c99bfb1a --- /dev/null +++ b/contributed_definitions/nyaml/NXelectronanalyser.yaml @@ -0,0 +1,257 @@ +category: base +doc: | + Subclass of NXinstrument to describe a photoelectron analyser. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays + nfa: | + Number of fast axes (axes acquired simultaneously, without scanning a + physical quantity) + nsa: | + Number of slow axes (axes acquired scanning a physical quantity) +type: group +NXelectronanalyser(NXobject): + description(NX_CHAR): + doc: | + Free text description of the type of the detector + name(NX_CHAR): + doc: | + Name or model of the equipment + \@short_name: + type: NX_CHAR + doc: | + Acronym or other shorthand name + energy_resolution(NX_FLOAT): + unit: NX_ENERGY + doc: | + Energy resolution of the electron analyser (FWHM of gaussian broadening) + momentum_resolution(NX_FLOAT): + unit: NX_WAVENUMBER + doc: | + Momentum resolution of the electron analyser (FWHM) + angular_resolution(NX_FLOAT): + unit: NX_ANGLE + doc: | + Angular resolution of the electron analyser (FWHM) + spatial_resolution(NX_FLOAT): + unit: NX_LENGTH + doc: | + Spatial resolution of the electron analyser (Airy disk radius) + fast_axes(NX_CHAR): + doc: | + 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. + dimensions: + rank: 1 + dim: [[1, nfa]] + slow_axes(NX_CHAR): + doc: | + List of the axes that are acquired by scanning a physical parameter, listed in + order of decreasing speed. See fast_axes for examples. + dimensions: + rank: 1 + dim: [[1, nsa]] + depends_on(NX_CHAR): + doc: | + Refers to the last transformation specifying the positon of the manipulator in + the NXtransformations chain. + (NXtransformations): + doc: | + 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. + (NXcollectioncolumn): + doc: | + Describes the electron collection (spatial and momentum imaging) column + (NXenergydispersion): + doc: | + Describes the energy dispersion section + (NXspindispersion): + doc: | + Describes the spin dispersion section + (NXdetector): + doc: | + Describes the electron detector + (NXdeflector): + doc: | + Deflectors outside the main optics ensambles described by the subclasses + (NXlens_em): + doc: | + Individual lenses outside the main optics ensambles described by the subclasses + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 4d6adccbc47a79bb1c1a6e54f879331198408c0f0a4503f6aa9093df58cdea12 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays +# +# +# +# Number of fast axes (axes acquired simultaneously, without scanning a +# physical quantity) +# +# +# +# +# Number of slow axes (axes acquired scanning a physical quantity) +# +# +# +# +# Subclass of NXinstrument to describe a photoelectron analyser. +# +# +# +# Free text description of the type of the detector +# +# +# +# +# Name or model of the equipment +# +# +# +# Acronym or other shorthand name +# +# +# +# +# +# Energy resolution of the electron analyser (FWHM of gaussian broadening) +# +# +# +# +# Momentum resolution of the electron analyser (FWHM) +# +# +# +# +# Angular resolution of the electron analyser (FWHM) +# +# +# +# +# Spatial resolution of the electron analyser (Airy disk radius) +# +# +# +# +# List of the axes that are acquired simultaneously by the detector. +# These refer only to the experimental variables recorded by the electron analyser. +# Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. +# +# .. csv-table:: Examples +# :header: "Mode", "fast_axes", "slow_axes" +# +# Hemispherical in ARPES mode, "['energy', 'kx']","" +# "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] +# "Tof", "['energy', 'kx', 'ky']","" +# "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" +# +# Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. +# If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. +# +# +# +# +# +# +# +# List of the axes that are acquired by scanning a physical parameter, listed in +# order of decreasing speed. See fast_axes for examples. +# +# +# +# +# +# +# +# Refers to the last transformation specifying the positon of the manipulator in +# the NXtransformations chain. +# +# +# +# +# Collection of axis-based translations and rotations to describe the location and +# geometry of the electron analyser as a component in the instrument. Conventions +# from the NXtransformations base class are used. In principle, the McStas +# coordinate system is used. The first transformation has to point either to +# another component of the system or . (for pointing to the reference frame) to +# relate it relative to the experimental setup. Typically, the components of a +# system should all be related relative to each other and only one component +# should relate to the reference coordinate system. +# +# +# +# +# Describes the electron collection (spatial and momentum imaging) column +# +# +# +# +# Describes the energy dispersion section +# +# +# +# +# Describes the spin dispersion section +# +# +# +# +# Describes the electron detector +# +# +# +# +# Deflectors outside the main optics ensambles described by the subclasses +# +# +# +# +# Individual lenses outside the main optics ensambles described by the subclasses +# +# +# diff --git a/contributed_definitions/nyaml/NXelectrostatic_kicker.yaml b/contributed_definitions/nyaml/NXelectrostatic_kicker.yaml new file mode 100644 index 0000000000..821e7c9324 --- /dev/null +++ b/contributed_definitions/nyaml/NXelectrostatic_kicker.yaml @@ -0,0 +1,105 @@ +category: base +doc: | + definition for a electrostatic kicker. +type: group +NXelectrostatic_kicker(NXobject): + description(NX_CHAR): + doc: | + extended description of the kicker. + beamline_distance(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + doc: | + define position of beamline element relative to production target + timing(NX_FLOAT): + unit: NX_TIME + exists: ['min', '0', 'max', '1'] + doc: | + kicker timing as defined by ``description`` attribute + \@description: + type: NX_CHAR + set_current(NX_FLOAT): + unit: NX_CURRENT + exists: ['min', '0', 'max', '1'] + doc: | + current set on supply. + read_current(NXlog): + exists: ['min', '0', 'max', '1'] + doc: | + current read from supply. + value: + unit: NX_CURRENT + set_voltage(NX_FLOAT): + unit: NX_VOLTAGE + exists: ['min', '0', 'max', '1'] + doc: | + volage set on supply. + read_voltage(NXlog): + exists: ['min', '0', 'max', '1'] + doc: | + voltage read from supply. + value: + unit: NX_VOLTAGE + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 8bc323e93c7d175eab0c362d716d4ca617041ffaf2f420a386d92ab7cb75d595 +# +# +# +# +# definition for a electrostatic kicker. +# +# extended description of the kicker. +# +# +# define position of beamline element relative to production target +# +# +# kicker timing as defined by ``description`` attribute +# +# +# +# current set on supply. +# +# +# current read from supply. +# +# +# +# volage set on supply. +# +# +# voltage read from supply. +# +# +# diff --git a/contributed_definitions/nyaml/NXellipsometry.yaml b/contributed_definitions/nyaml/NXellipsometry.yaml new file mode 100644 index 0000000000..9e6d9d0c10 --- /dev/null +++ b/contributed_definitions/nyaml/NXellipsometry.yaml @@ -0,0 +1,596 @@ +category: application +doc: | + Ellipsometry, complex systems, up to variable angle spectroscopy. + + Information on ellipsometry is provided, e.g. in: + + * H. Fujiwara, Spectroscopic ellipsometry: principles and applications, + John Wiley & Sons, 2007. + * R. M. A. Azzam and N. M. Bashara, Ellipsometry and Polarized Light, + North-Holland Publishing Company, 1977. + * H. G. Tompkins and E. A. Irene, Handbook of Ellipsometry, + William Andrew, 2005. + + Open access sources: + + * https://www.angstromadvanced.com/resource.asp + * https://pypolar.readthedocs.io/en/latest/ + + Review articles: + + * T. E. Jenkins, "Multiple-angle-of-incidence ellipsometry", + J. Phys. D: Appl. Phys. 32, R45 (1999), + https://doi.org/10.1088/0022-3727/32/9/201 + * D. E. Aspnes, "Spectroscopic ellipsometry - Past, present, and future", + Thin Solid Films 571, 334-344 (2014), + https://doi.org/10.1016/j.tsf.2014.03.056 + * R. M. A. Azzam, "Mueller-matrix ellipsometry: a review", + Proc. SPIE 3121, Polarization: Measurement, Analysis, and Remote Sensing, + (3 October 1997), + https://doi.org/10.1117/12.283870 + * E. A. Irene, "Applications of spectroscopic ellipsometry to microelectronics", + Thin Solid Films 233, 96-111 (1993), + https://doi.org/10.1016/0040-6090(93)90069-2 + * S. Zollner et al., "Spectroscopic ellipsometry from 10 to 700 K", + Adv. Opt. Techn., (2022), + https://doi.org/10.1515/aot-2022-0016 + +# N_p1: +# "Number of sample parameters scanned, if you varied any of the parameters +# such as temperature, pressure, or pH, the maximal length of the arrays +# specified by NXsample/environment_conditions/SENSOR/value if it exists." +# N_time: "Number of time points measured, the length of NXsample/time_points" +symbols: + doc: | + Variables used throughout the document, e.g. dimensions or parameters. + N_spectrum: | + Length of the spectrum array (e.g. wavelength or energy) of the measured + data. + N_sensors: | + Number of sensors used to measure parameters that influence the sample, + such as temperature or pressure. + N_measurements: | + Number of measurements (1st dimension of measured_data array). This is + equal to the number of parameters scanned. For example, if the experiment + was performed at three different temperatures and two different pressures + N_measurements = 2*3 = 6. + N_detection_angles: | + Number of detection angles of the beam reflected or scattered off the + sample. + N_incident_angles: | + Number of angles of incidence of the incident beam. + N_observables: | + Number of observables that are saved in a measurement. e.g. one for + intensity, reflectivity or transmittance, two for Psi and Delta etc. This + is equal to the second dimension of the data array 'measured_data' and the + number of column names. + N_time: | + Number of time points measured, the length of NXsample/time_points + +# 06/2022 +# A draft version of a NeXus application definition for ellipsometry. + +# The document has the following main elements: +# - Instrument used and is characteristics +# - Sample: Properties of the sample +# - Data: measured data, data errors +# - Derived parameters: e.g. extra parameters derived in the measurement software +type: group +NXellipsometry(NXopt): + + # symbols: + # doc: "Variables used throughout the document, e.g. dimensions and important parameters" + # N_wavelength: "Size of the energy or wavelength vector used, the length of + # NXinstrument/spectrometer/wavelength array" + # N_variables: "How many variables are saved in a measurement. e.g. 2 for Psi + # and Delta, 16 for Mueller matrix elements, 15 for normalized + # Mueller matrix, 3 for NCS, the length of NXsample/column_names" + # N_angles: "Number of incident angles used, the length of + # NXinstrument/angle_of_incidence array" + (NXentry): + doc: | + This is the application definition describing ellipsometry experiments. + + Such experiments may be as simple as identifying how a reflected + beam of light with a single wavelength changes its polarization state, + to a variable angle spectroscopic ellipsometry experiment. + + The application definition defines: + + * elements of the experimental instrument + * calibration information if available + * parameters used to tune the state of the sample + * sample description + definition: + doc: | + An application definition for ellipsometry. + \@version: + doc: | + Version number to identify which definition of this application + definition was used for this entry/data. + \@url: + doc: | + URL where to find further material (documentation, examples) relevant + to the application definition. + enumeration: [NXellipsometry] + experiment_description: + doc: | + An optional free-text description of the experiment. + + However, details of the experiment should be defined in the specific + fields of this application definition rather than in this experiment + description. + experiment_type: + doc: | + Specify the type of ellipsometry. + enumeration: [in situ spectroscopic ellipsometry, THz spectroscopic ellipsometry, infrared spectroscopic ellipsometry, ultraviolet spectroscopic ellipsometry, uv-vis spectroscopic ellipsometry, NIR-Vis-UV spectroscopic ellipsometry, imaging ellipsometry] + (NXinstrument): + doc: | + Properties of the ellipsometry equipment. + company: + exists: optional + doc: | + Name of the company which build the instrument. + construction_year(NX_DATE_TIME): + exists: optional + doc: | + ISO8601 date when the instrument was constructed. + UTC offset should be specified. + software(NXprocess): + program: + doc: | + Commercial or otherwise defined given name of the program that was + used to generate the result file(s) with measured data and metadata. + This program converts the measured signals to ellipsometry data. If + home written, one can provide the actual steps in the NOTE subfield + here. + ellipsometer_type: + doc: | + What type of ellipsometry was used? See Fujiwara Table 4.2. + enumeration: [rotating analyzer, rotating analyzer with analyzer compensator, rotating analyzer with polarizer compensator, rotating polarizer, rotating compensator on polarizer side, rotating compensator on analyzer side, modulator on polarizer side, modulator on analyzer side, dual compensator, phase modulation, imaging ellipsometry, null ellipsometry] + rotating_element_type: + doc: | + Define which element rotates, e.g. polarizer or analyzer. + enumeration: [polarizer (source side), analyzer (detector side), compensator (source side), compensator (detector side)] + (NXbeam_path): + light_source(NXsource): + doc: | + Specify the used light source. Multiple selection possible. + source_type: + enumeration: [arc lamp, halogen lamp, LED, other] + focussing_probes(NXlens_opt): + exists: optional + doc: | + If focussing probes (lenses) were used, please state if the data + were corrected for the window effects. + data_correction(NX_BOOLEAN): + doc: | + Were the recorded data corrected by the window effects of the + focussing probes (lenses)? + angular_spread(NX_NUMBER): + exists: recommended + unit: NX_ANGLE + doc: | + Specify the angular spread caused by the focussing probes. + (NXdetector): + doc: | + Properties of the detector used. Integration time is the count time + field, or the real time field. See their definition. + rotating_element(NXwaveplate): + exists: optional + doc: | + Properties of the rotating element defined in + 'instrument/rotating_element_type'. + revolutions(NX_NUMBER): + exists: optional + unit: NX_COUNT + doc: | + Define how many revolutions of the rotating element were averaged + for each measurement. If the number of revolutions was fixed to a + certain value use the field 'fixed_revolutions' instead. + fixed_revolutions(NX_NUMBER): + exists: optional + unit: NX_COUNT + doc: | + Define how many revolutions of the rotating element were taken + into account for each measurement (if number of revolutions was + fixed to a certain value, i.e. not averaged). + max_revolutions(NX_NUMBER): + exists: optional + unit: NX_COUNT + doc: | + Specify the maximum value of revolutions of the rotating element + for each measurement. + spectrometer(NXmonochromator): + exists: optional + doc: | + The spectroscope element of the ellipsometer before the detector, + but often integrated to form one closed unit. Information on the + dispersive element can be specified in the subfield GRATING. Note + that different gratings might be used for different wavelength + ranges. The dispersion of the grating for each wavelength range can + be stored in grating_dispersion. + (NXsample): + backside_roughness(NX_BOOLEAN): + doc: | + Was the backside of the sample roughened? Relevant for infrared + ellipsometry. + data_collection(NXprocess): + data_type: + doc: | + Select which type of data was recorded, for example Psi and Delta + (see: https://en.wikipedia.org/wiki/Ellipsometry#Data_acquisition). + It is possible to have multiple selections. Data types may also be + converted to each other, e.g. a Mueller matrix contains N,C,S data + as well. This selection defines how many columns (N_observables) are + stored in the data array. + enumeration: [Psi/Delta, tan(Psi)/cos(Delta), Mueller matrix, Jones matrix, N/C/S, raw data] + + # column_names: + # doc: | + # Please list in this array the column names used in your actual data. + # That is ['Psi', 'Delta'] or ['MM1', 'MM2', 'MM3', ..., 'MM16] for + # a full Mueller matrix, etc. + # dimensions: + # rank: 1 + # dim: [[1, N_observables]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e5c086ad7e50f420614c5465adc29a57a2b25cc1be09659435b3f1592c0f941a +# +# +# +# +# +# +# +# +# +# +# Variables used throughout the document, e.g. dimensions or parameters. +# +# +# +# Length of the spectrum array (e.g. wavelength or energy) of the measured +# data. +# +# +# +# +# Number of sensors used to measure parameters that influence the sample, +# such as temperature or pressure. +# +# +# +# +# Number of measurements (1st dimension of measured_data array). This is +# equal to the number of parameters scanned. For example, if the experiment +# was performed at three different temperatures and two different pressures +# N_measurements = 2*3 = 6. +# +# +# +# +# Number of detection angles of the beam reflected or scattered off the +# sample. +# +# +# +# +# Number of angles of incidence of the incident beam. +# +# +# +# +# Number of observables that are saved in a measurement. e.g. one for +# intensity, reflectivity or transmittance, two for Psi and Delta etc. This +# is equal to the second dimension of the data array 'measured_data' and the +# number of column names. +# +# +# +# +# Number of time points measured, the length of NXsample/time_points +# +# +# +# +# Ellipsometry, complex systems, up to variable angle spectroscopy. +# +# Information on ellipsometry is provided, e.g. in: +# +# * H. Fujiwara, Spectroscopic ellipsometry: principles and applications, +# John Wiley & Sons, 2007. +# * R. M. A. Azzam and N. M. Bashara, Ellipsometry and Polarized Light, +# North-Holland Publishing Company, 1977. +# * H. G. Tompkins and E. A. Irene, Handbook of Ellipsometry, +# William Andrew, 2005. +# +# Open access sources: +# +# * https://www.angstromadvanced.com/resource.asp +# * https://pypolar.readthedocs.io/en/latest/ +# +# Review articles: +# +# * T. E. Jenkins, "Multiple-angle-of-incidence ellipsometry", +# J. Phys. D: Appl. Phys. 32, R45 (1999), +# https://doi.org/10.1088/0022-3727/32/9/201 +# * D. E. Aspnes, "Spectroscopic ellipsometry - Past, present, and future", +# Thin Solid Films 571, 334-344 (2014), +# https://doi.org/10.1016/j.tsf.2014.03.056 +# * R. M. A. Azzam, "Mueller-matrix ellipsometry: a review", +# Proc. SPIE 3121, Polarization: Measurement, Analysis, and Remote Sensing, +# (3 October 1997), +# https://doi.org/10.1117/12.283870 +# * E. A. Irene, "Applications of spectroscopic ellipsometry to microelectronics", +# Thin Solid Films 233, 96-111 (1993), +# https://doi.org/10.1016/0040-6090(93)90069-2 +# * S. Zollner et al., "Spectroscopic ellipsometry from 10 to 700 K", +# Adv. Opt. Techn., (2022), +# https://doi.org/10.1515/aot-2022-0016 +# +# +# +# This is the application definition describing ellipsometry experiments. +# +# Such experiments may be as simple as identifying how a reflected +# beam of light with a single wavelength changes its polarization state, +# to a variable angle spectroscopic ellipsometry experiment. +# +# The application definition defines: +# +# * elements of the experimental instrument +# * calibration information if available +# * parameters used to tune the state of the sample +# * sample description +# +# +# +# An application definition for ellipsometry. +# +# +# +# Version number to identify which definition of this application +# definition was used for this entry/data. +# +# +# +# +# URL where to find further material (documentation, examples) relevant +# to the application definition. +# +# +# +# +# +# +# +# +# An optional free-text description of the experiment. +# +# However, details of the experiment should be defined in the specific +# fields of this application definition rather than in this experiment +# description. +# +# +# +# +# Specify the type of ellipsometry. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Properties of the ellipsometry equipment. +# +# +# +# Name of the company which build the instrument. +# +# +# +# +# ISO8601 date when the instrument was constructed. +# UTC offset should be specified. +# +# +# +# +# +# Commercial or otherwise defined given name of the program that was +# used to generate the result file(s) with measured data and metadata. +# This program converts the measured signals to ellipsometry data. If +# home written, one can provide the actual steps in the NOTE subfield +# here. +# +# +# +# +# +# What type of ellipsometry was used? See Fujiwara Table 4.2. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Define which element rotates, e.g. polarizer or analyzer. +# +# +# +# +# +# +# +# +# +# +# +# Specify the used light source. Multiple selection possible. +# +# +# +# +# +# +# +# +# +# +# +# +# If focussing probes (lenses) were used, please state if the data +# were corrected for the window effects. +# +# +# +# Were the recorded data corrected by the window effects of the +# focussing probes (lenses)? +# +# +# +# +# Specify the angular spread caused by the focussing probes. +# +# +# +# +# +# Properties of the detector used. Integration time is the count time +# field, or the real time field. See their definition. +# +# +# +# +# Properties of the rotating element defined in +# 'instrument/rotating_element_type'. +# +# +# +# Define how many revolutions of the rotating element were averaged +# for each measurement. If the number of revolutions was fixed to a +# certain value use the field 'fixed_revolutions' instead. +# +# +# +# +# Define how many revolutions of the rotating element were taken +# into account for each measurement (if number of revolutions was +# fixed to a certain value, i.e. not averaged). +# +# +# +# +# Specify the maximum value of revolutions of the rotating element +# for each measurement. +# +# +# +# +# +# The spectroscope element of the ellipsometer before the detector, +# but often integrated to form one closed unit. Information on the +# dispersive element can be specified in the subfield GRATING. Note +# that different gratings might be used for different wavelength +# ranges. The dispersion of the grating for each wavelength range can +# be stored in grating_dispersion. +# +# +# +# +# +# +# +# Was the backside of the sample roughened? Relevant for infrared +# ellipsometry. +# +# +# +# +# +# +# Select which type of data was recorded, for example Psi and Delta +# (see: https://en.wikipedia.org/wiki/Ellipsometry#Data_acquisition). +# It is possible to have multiple selections. Data types may also be +# converted to each other, e.g. a Mueller matrix contains N,C,S data +# as well. This selection defines how many columns (N_observables) are +# stored in the data array. +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml new file mode 100644 index 0000000000..b3b53b5cb9 --- /dev/null +++ b/contributed_definitions/nyaml/NXem.yaml @@ -0,0 +1,4659 @@ +category: application +doc: | + Characterization of a sample during a session on an electron microscope. + + **The idea and aim of NXem**: + Electron microscopy (EM) research, whether it be performed with scanning electron + microscope (SEM) or transmission electron microscope (TEM) instruments, uses + versatile tools for preparing and characterizing samples and specimens. + The term specimen is considered a synonym for sample in this application definition. + A specimen is a physical portion of material that is studied/characterized during + the microscope session, eventually in different places on the specimen surface, + illuminating the surface layers or shining through thin specimens. + These places are named regions of interest (ROIs). + + Fundamentally, an electron microscope is an electron accelerator. + Experimentalists use it in sessions during which they characterize as well as + prepare specimens. This application definition describes data and metadata about + processes and characterization tasks applied to one specimen. + The application definition focuses on the usage of EM in materials research. + The application definition design makes it in principle applicable also in + cryo-EM on biomaterials. + + Multiple specimens have to be described with multiple :ref:`NXentry` instances. + + **Electron microscopes motivate the development of an embracing data schema:** + There are research groups who use an EM in a manner where it is exclusively + operated by a single, instrument-responsible scientists or a team of scientists. + These users may perform analyses for other users as a service task, especially + in large research facility settings. Oftentimes, though, and especially for + cutting-edge instruments, the scientists guide the process maybe even control + the microscope. Instruments are usually controlled on-premises but also more + and more functionalities for remote control have become available. + Scientists oftentimes can ask technicians for support. In all cases, + these people are considered users. Users might have different + roles though. + + The rational behind a common EM schema rather than making separate schemas + for SEM or TEM are primarily the key similarities of SEM and TEM + instruments: + + Both type of instruments have electro-magnetic lenses. These may differ in + design, alignment, number, and level of corrected for aberrations. + As an obvious difference, a TEM is mainly used for measuring the transmitted + electron beam. This calls for using a different lens setup and relative + placement of the specimen in the lens setup. Also TEM specimens are + substantially thinner than specimens characterized with SEM to enable an + illumination through the specimen. This offers capabilities for probing of + additional physical mechanisms of electron-matter interaction which are + unavailable in SEMs. + + Nevertheless, both types of electron microscopes use detector systems which + measure different types of signals that originate from the same set of + radiation/specimen interactions. Often these detectors have a similar design + and technology or are even used both in SEMs and TEMs. + + **An embracing schema instead of specific SEM or TEM schemas**: + Given these physical and technical differences, different instruments have + been developed. This led to a coexistence of two broad interacting + communities: SEM and TEM users. From a data science perspective, we + acknowledge that the more specific a research question is and the narrower it + is the addressed circle of users which develops or uses schemas for research + data management (RDM) with EM, the more understandable it is that scientists + of either community (or sub-community) ask for designing method-specific schemas. + + Researchers who have a single (main) microscope of some vendor in their lab, + may argue they need an NXem_vendor_name schema or an NXem_microscope_name or + an NXem_sem or a NXem_tem schema. + Scientists exclusively working with one technique or type of signal probed + (X-rays, electrons) may argue they wish to be pragmatic and store only + what is immediately relevant for their particular technique and + research questions. In effect, they may advocate for method-specific + schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. + + However, the history of electron microscopy has shown that these activities led + to a zoo of schemas and especially vocabulary in use with implementations of these + into many data and file formats. There is nothing which prevents the communities + to make these schemas open and interoperable. Open here means not that all + data stored according to such schemas have to end up in the open-source domain. + There can be embargo periods first of all. + + Open means that the metadata and associated schemata are documented in a manner + that as many details are open as possible in the sense that others can understand + what the (meta)data mean conceptually. Instead of trying of maintain a zoo + of eventually difficult to make interoperable formats and schema we would like + to advocate that the `FAIR principles `_ + should guide all decisions how data and metadata should be stored. + + EM instruments, software, and research are moving targets. Consequently, + there is a key challenge and inconvenience with having many different schemas + with associated representations of data and metadata: Each combination of + schemas or an interoperable-made handshake between two file formats or software + packages has to be maintained by software developers. This counts especially + when data should be processed interoperably between software packages. + + This brings two problems: Many software tools and parsers for the handshaking + between tools have to be maintained. This can result in usage of different + terminology, which in turn results in representations and connections made + between different data representations and workflows that are not + machine-actionable. + `There are community efforts to harmonize the terminology. `_ + + **The advantage of working towards a common vocabulary and representation**: + A common vocabulary can serve interoperability as developers of schemas and + scientists can reuse for instance these terms, thus supporting interoperability. + Ideally, scientists specialize an application definition only for the few very + specific additional quantities of their instruments and techniques. This is + better than reimplementing the wheel for descriptions of EM instruments. + This route of more standardization can support the EM community in that it + removes the necessity for having to maintain a very large number of schemas. + + Aiming for more standardization, i.e. a lower number of schemas rather than + a single standard for electron microscopy is a compromise that can serve + academia and industry as it enables a focusing of software development + efforts on those schemas, on fixing and discussing them, and on harmonizing + their common vocabulary. These activities can be specifically relevant also + for technology partners building EM hard- and software as it improves the + longevity of certain schemas; and thus can help with incentivizing them to support + the community with implementing support for such schemas into their applications. + + In effect, everybody can gain from this as it will likely reduce the cases + in which scientists have to fix bugs in making their own tools compliant and + interoperable with tools of their colleagues and the wider community. + + The here proposed NXem application definition offers modular components + (EM-research specific base classes) for defining schemas for EM research. + Thereby, NXem can be useful to extends top-level ontologies towards a domain- + and method-specific ontology for electron microscopy as it is used for + materials research. + + Working towards a common vocabulary is a community activity that profits from + everybody reflecting in detail whether certain terms they have used in the past + are not eventually conceptually similar if not the same as what this application + definition and its base classes provide. We are happy for receiving your feedback. + + **Addressing the generality versus specificity challenge**: + It is noteworthy to understand that (not only for NeXus), schemas differ + already if at least one field is required in one version of the schema, + but it is set optional in another schema. If group(s), field(s), or + attributes are removed or added, or even a docstring is changed, schemas can + become inconsistent. It is noteworthy to mention that the idea of a NeXus application + definition serves as a contract between a data provider and a data consumer. + Providers can be the software of a specific microscopes or users with specific + analysis needs. Consumers can be again specific software tools, like vendor + software for controlling the instrument or a scientific software for doing + artificial intelligence analyses on EM data). Such changes of a schema lead + to new versions. Strictly speaking an application definition can only be + fully general if it does not make a single entry required, in which case however + it would also not offer much value as even empty datasets would be compliant + with such a schema. + + **Verification of constraints and conditions**: + Tools like NeXus so far do not avoid or protect against all such possible + inconsistencies; however NeXus offers a mechanism and toolset, through which + schemas can be documented and defined. In effect, having an openly documented + (at a case-specific level of technical detail) schema is a necessary but alone + not a sufficient step to take EM research on a route of machine-actionable + and interoperable FAIR data. + + This stresses again the fundamental and necessary role of working towards + a common vocabulary and, with a longer perspective in mind, a machine-actionable + knowledge representation and verification engine. So far many conditions and + requirements are formulated in the docstrings of the respective entries of + the application definition. + + **NXem takes a key step towards standardization of EM data schemas**. + It offers a controlled vocabulary and set of relations between concepts and + enables the description of the data which are collected for research with + electron microscopes. To be most efficient and offering reusability, the NXem + application definition should be understood as a template that one should + ideally use as is. NXem can be considered a base for designing more specialized + definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). + + **The use of NXem should be as follows:** + Offspring application definitions should not remove groups but leave these + optional or, even better, propose changes to NXem. + + A particular challenge with electron microscopes as physical instruments are + their dynamics. To make EM data understandable, repeatable, and eventually + corresponding experiments reproducible in general requires a documentation + of the spatio-temporal dynamics of the instrument in its environment. + It is questionable to which level such a reproducibility is possible with EM + at all considering beam damage, effects of the environment, and other not + exactly quantifiable influences. + While this points to the physical limitations there are also practical and + economical constraints on how completely EM research can be documented: + For most commercial systems there is a specific accessibility beyond which + detailed settings like lens excitations and low-level hardware settings + may not be retrievable as technology partners have a substantiated interest in + finding a compromise between being open to their users and securing their + business models. + + By design, EM experiments illuminate the specimen with electrons as a + consequence of which the specimen changes if not may get destroyed. + As such, repeatability of numerical processing and clear descriptions of + procedures and system setups should be addressed first. + + If especially a certain simulation package needs a detailed view of the + geometry of the lens system and its excitations during the course of the + experiment, it is difficult to fully abstract the technical details of the + hardware into a set of names for fields and groups that make for a compromise + between clarity but being system-agnostic at the same time. + Settings of apertures are an example where aperture modes are in most cases + aliases behind which there is a set of very detailed settings specific to the + software and control units used. These settings are difficult to retrieve, + are not fully documented by technology partners. This simplification for + users of microscopes makes experiments easier understandable. + On the flipside these subtilities limit the opportunities of especially open- + source developments to make data schemas covering enough for general usage and + specific enough and sufficiently detailed to remain useful for + research by electron microscopy domain experts. + + Instead, currently it is for the docstring to specify what is conceptually + eventually behind such aliases. The design rule we followed while drafting + this NXem application definition and base classes is that there are numerous + (technical) details about an EM which may warrant a very detailed technical + disentangling of settings and reflection of numerous settings as deeply + nested groups, fields and attributes. An application definition can offer a + place to hold these nested representations; however as discussed + at the cost of generality. + + Which specific details matter for answering scientific research questions is + a difficult question to answer by a single team of scientists, especially + if the application definition is to speak for a number of vendors. What makes + it especially challenging is when the application definition is expected to + hold all data that might be of relevance for future questions. + + We are skeptical if there is one such representation that can fulfill all these + aims and interest, while remaining at the same time approachable and executable + by a large number of scientists in a community. However, we are also convinced + that this is not a reason to accept the status quo of having a very large set + of oftentimes strongly overlapping and redundant schemas. + + NXem is our proposal to motivate the EM community to work towards more + standardization and discussion of what constitutes data, i.e. metadata, + numerical and categorical data in research with electron microscopes. We found + that existent terminology can be encoded into a more controlled vocabulary. + + We have concluded that despite all these details of current EM research with + SEM, TEM, and focused-ion beam instruments, there a clearly identifiable + common components and generalizable settings of EM research use cases. + Therefore, + + **This application definition has the following components at the top-level:** + + * Generic experimental details (time-zone-aware timestamp, identifiers, name); + conceptually these are session details. A session at a microscope may + involve the characterization of multiple specimens. For each specimen + an instance of an (NXentry) is created. Details of the instrument have to + be stored at least in an entry. Other entries should refer to these + metadata via links to reduce redundancies. + * Each signal, such as a spectrum or image taken at the microscope, should + have an associated time-zone-aware time stamp and report of the specific + settings of the microscope at that point in time when the image was taken. + This is why instances of :ref:`NXevent_data_em` have an own em_lab section. + The reason is that EMs can be highly dynamic, be used to illuminate the specimen + differently or show drift during signal acquisition, to name but a few effects. + What constitutes a single EM experiment/measurement? + This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), + taking of a secondary electron image for fracture analysis, taking a set of + EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a + specimen in preparation for e.g. an atom probe experiment. + * :ref:`NXmonitor`; + instances to keep track of time-dependent quantities + pertaining to specific components of the instrument. + Alternatively, NXevent_data_em instances can be used to store + time-zone-aware dates of the components, which is + relevant for documenting as exactly as practically possible settings + when images and spectra were taken. + * :ref:`NXinstrument`; + conceptually this is a container to store arbitrary level of detail of the + technical components of the microscope as a device and the lab in which + the microscope is operated. + * :ref:`NXuser`; + conceptually, this is a set with at least one NXuser instance which details + who operated or performed the measurement. Additional NXusers can be + referred to in an NXevent_data_em instance to store + individualized details who executed an event of data acquisition or processing. + * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; + each NXevent_data_em instance is a container to group specific details + about the state of the microscope when a measurement was taken and + relevant data and eventual processing steps were taken (on-the-fly). + * :ref:`NXdata`; at the top-level, conceptually, this is a place for documenting + available default plottable data. A default plottable can be useful for + research data management systems to show a visual representation of some + aspect of the content of the EM session. + Default plottables not intended to serve every possible analysis and + visualization demand but be a preview. We made this choice because what + constitutes a useful default plot is often a matter of interpretation, + somewhat of personal taste, and community standards. In effect, default + plottables are case- and method-specific. + + Usually a session at a microscope is used to collect multiple signals. + Examples for possible default plottables could be arbitrarily taken secondary, + back-scattered, electron image, diffraction pattern, EELS spectra, composition, + or orientation mappings to name but a few. + + **There are a few design choices to consider with sub-ordinate groups:** + + * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` + instances to hold data at the earliest possible step in the computational + processing (which is usually performed with the microscope control and or + integrated analysis software). The formatting of the NXdata groups enables to + display image and spectra with web technology visualization software. + NeXus specifies only the data model, i.e. the terms and their relations. + These descriptions can be implemented and stored in JSON, HDF5, XML, or HSDS, + file storage, or even other formats, although HDF5 is often used. + * When two- and three-dimensional geometric primitive data are stored, it is useful + to write additional optional XDMF fields which support additional plotting of + the data with visualization software like Paraview or Blender. + * Consumable results of EM characterization tasks are usually a sub-set of + data artifacts, as there is not an infinite amount of possible + electron/ion beam-specimen interactions. + * Images of electron counts detected in specific operation modes (bright + field, dark field in TEM, secondary/back-scattered, Kikuchi). + * Spectra (X-ray quanta or Auger electron counts) + * These data are in virtually all cases a result of some numerical processing. + These data and processing steps are modelled as instances of :ref:`NXprocess` + which use terms from a controlled vocabulary e.g. SE (secondary electron), + BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). + + **A key question often asked with EM experiments is how the actual (meta)data + should be stored (in memory or on disk)**. To this end the schema here makes no + specific assumptions, not even that all the fields/group of a schema instance + have to be stored at all into a single file. Instead, the schema specifies the + relations between metadata, some of the constraints and conditions on how the + data should be formatted, what the data conceptually represent, and which terms + (controlled vocabulary) is practical to store to index specific quantities. + + In effect, the application definition is a graph which describes how + numerical data and (meta)data for EM research are related to one another. + + Electron microscopy experiments are usually controlled/performed via + commercial integrated acquisition and instrument control software. + In many cases, an EM dataset is useful only if it gets post-processed + already during the acquisition, i.e. while the scientist is sitting + at the microscope. + Many of these processes are automated, while some demand GUI + interactions with the control software. Examples include collecting + of diffraction pattern and on-the-fly indexing of these. + + It is possible that different types of programs might be used to + perform these processing steps whether on-the-fly or not. If this is + the case the processing should be structured with individual :ref:`NXprocess` + instances. If the program and/or version used for processing referred + to in an NXprocess group is different to the program and version + mentioned in this field, the NXprocess needs + to hold an own program and version. + +# While an important +# step this will still need in the future a mechains +# So far Essentially when the docstrings are no longer needed +# but can be replaced by a connection to an automated tool which understands +# what a specific field represents conceptually, EM data have become more +# generally interoperable EM data. +# NEW ISSUE: see duration and collection time, duty cycle +# NEW ISSUE: duration and collection_time needs a clearer description and +# definition by the community +# NEW ISSUE: should version always be an enumeration? +# NEW ISSUE: filter keywords \(.*?\) +# NEW ISSUE: NXdetector adding only those fields which have changed or not? +# symbols: +# the NeXus default for application definitions wrt to the exists keyword is +# that it is required +type: group +NXem(NXobject): + (NXentry): + exists: ['min', '1', 'max', 'unbounded'] + + # NEW ISSUE: the definition field and its version attribute enumeration + # NEW ISSUE: will be added by yaml2nxdl automatically + \@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: [NXem] + 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 this + application definition rather than write details about the experiment + into this free-text description field. + start_time(NX_DATE_TIME): + exists: recommended + 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 by specifying both + a start_time and an end_time to allow for more detailed bookkeeping and + interpretation of the experiment. The user should be aware that even + with having both time instances specified, it may not be possible + to infer how long the experiment took or for how long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps in NXevent_data_em instances to + provide additional pieces of information. + 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. + (NXprogram): + exists: ['min', '1', 'max', 'unbounded'] + program: + \@version: + 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. + 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: + (NXuser): + exists: ['min', '1', 'max', 'unbounded'] + doc: | + Contact information and eventually details of at least one person + involved in the taking of the microscope session. This can be the + principle investigator who performed this experiment. + Adding multiple users if relevant is recommended. + 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): + + # NEW ISSUE: inject the conclusion from the discussion with Andrea + # according to SAMPLE.yaml 0f8df14 2022/06/15 + # ID: -> maps to name + # name: -> short_title + # user: -> not matched right now + # citation: doi ->why relevant, should be solved by RDMS + doc: | + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + method: + doc: | + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + enumeration: [experiment, simulation] + + # MK:: declared_by_vendor I would rather expect this for a substance + # COMPONENT.yaml + # SUBSTANCE: + # QUANTIFY + name: + doc: | + Ideally (globally) unique persistent identifier. The name distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias of the sample. + Instead, use short_title for this, more convenient alias name. + + In cases where multiple specimens have been loaded into the microscope + the name has to identify the specific one, whose results are stored + by this NXentry, because a single NXentry should be used only for + the characterization of a single specimen. + + Details about the specimen preparation should be stored in the + sample history. + sample_history: + doc: | + Ideally, a reference to a (globally) unique persistent identifier, + representing a data artifact which documents ideally as many details + of the material, its microstructure, and its thermo-chemo-mechanical + processing/preparation history as possible. + + The sample_history is the record what happened before the specimen + was placed into the microscope at the beginning of the session. + + In the case that such a detailed history of the sample/specimen is not + available, use this field as a free-text description to specify a + sub-set of the entire sample history, i.e. what you would consider are + the key steps and relevant information about the specimen, + its material, microstructure, thermo-chemo-mechanical processing state, + and the details of the preparation. + + Specific details about eventual physically-connected material like + embedding resin should be documented ideally also in the sample_history. + If all fails, the description field can be used but it is strongly + discouraged because it leads to eventually non-machine-actionable + data. + preparation_date(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Usually this should + be a part of the sample history, i.e. the sample is imagined handed over + for analysis. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments + including tracers with a short half time. Further time stamps prior + to preparation_date should better be placed in resources which + describe the sample_history. + short_title: + exists: optional + doc: | + Possibility to give an abbreviation or alias 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. + + # NEW ISSUE: use Andrea and MarkusK groups for describing the geometry of the sample + thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + (Measured) sample thickness. The information is recorded to qualify + if the beam used was likely able to shine through the specimen. + For scanning electron microscopy, in many cases the specimen is much + thicker than what is illuminatable by the electron beam. + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. + + # \@units: nm + # NEW ISSUE: error estimates of the thickness and origin, i.e. how the value was obtained would be useful + # NEW ISSUE: error model + # NEW ISSUE: the KIT/SCC SEM, TEM schemata further qualify samples whether they are conductive e/ibeam sensitive + # etc. The problem with this is that beam sensitivity is too vague, spatio-temporal electron dose integral dependent + # KIT/SCC distinguish further conductivity and magnetic properties. While the motivation is clear, making + # simple could be problematic or not decision, it is also these descriptors if remaining vague are also not useful + # what are good or bad properties, it would make sense though to quantify these values + # this includes the description of eventual plasma cleaning steps, + # just knowing that a sample was plasma cleaned is insufficient, maybe it was not cleaned long enough + # if plasma cleaning is done outside the EM than its certainly history, if it happens inside the EM + # are the ibeam description capabilities not sufficient enough? + density(NX_FLOAT): + exists: optional + unit: NX_ANY + doc: | + (Measured) density of the specimen. For multi-layered specimens this + field should only be used to describe the density of the excited + volume. For scanning electron microscopy the usage of this field is + discouraged and instead an instance of an :ref:`NXinteraction_vol_em` + within individual :ref:`NXevent_data_em` instances can provide a much + better description of the relevant details why one may wish to store + the density of the specimen. + + # \@units: g/cm^3 + description: + exists: optional + doc: | + Discouraged free-text field in case properly designed records + for the sample_history are not available. + (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 + TRANSFORMATIONS(NXtransformations): + exists: ['min', '0', 'max', 'unbounded'] + + # in what follows each component of the instrument might be equipped with an NXmonitor + (NXmonitor): + exists: optional + + # NEW ISSUE ADD AS MANY MONITORS AS NEEDED, also for pressure etc. + + # in what follows, an as-detailed as desired collection of components + # making up the instrument follows at this level of the hierarchy + em_lab(NXinstrument): + doc: | + Metadata and numerical data of the microscope and the lab in which it stands. + + The em_lab section contains a description of the instrument and its components. + The component descriptions in this section differ from those inside individual + NXevent_data_em sections. These event instances take the role of time snapshot. + For an NXevent_data_em instance users should store only those settings for a + component which are relevant to understand the current state of the component. + Here, current means at the point in time, i.e. the time interval, + which the event represents. + + For example it is not relevant to store in each event's electron_source + group again the details of the gun type and manufacturer but only the + high-voltage if for that event the high-voltage was different. If for all + events the high-voltage was the same it is not even necessary to include + an electron_source section in the event. + + Individual sections of specific type should have the following names: + + * NXaperture: the name should match with the name of the lens + * NXlens_em: condenser_lens, objective_lens are commonly used names + * NXcorrector_cs: device for correcting spherical aberrations + * NXstage_lab: a collection of component for holding the specimen and + eventual additional component for applying external stimuli on the sample + * NXdetector: several possible names like secondary_electron, + backscattered_electron, direct_electron, ebsd, edx, wds, auger, + cathodoluminescence, camera, ronchigram + instrument_name: + doc: | + Given name of the microscope at the hosting institution. This is an alias. + Examples could be NionHermes, Titan, JEOL, Gemini, etc. + location: + exists: optional + doc: | + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + (NXfabrication): + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + capabilities: + exists: optional + (NXchamber): + exists: optional + (NXebeam_column): + exists: ['min', '1', 'max', '1'] + (NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + (NXchamber): + exists: optional + electron_source(NXsource): + name: + exists: recommended + (NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + voltage(NX_FLOAT): + emitter_type: + exists: recommended + enumeration: [thermionic, schottky, field_emission] + (NXaperture_em): + exists: ['min', '0', 'max', 'unbounded'] + (NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + value(NX_NUMBER): + name: + description: + exists: optional + (NXlens_em): + exists: ['min', '0', 'max', 'unbounded'] + doc: | + If the lens is described at least one of the fields + voltage, current, or value should be defined. + + # a classical case where we want at least one field of multiple to exist + (NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + voltage(NX_NUMBER): + exists: recommended + current(NX_NUMBER): + exists: recommended + value(NX_NUMBER): + exists: recommended + aberration_correction(NXcorrector_cs): + exists: recommended + applied(NX_BOOLEAN): + name: + exists: optional + (NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + ZEMLIN_TABLEAU(NXprocess): + exists: recommended + description: + exists: optional + tilt_angle(NX_FLOAT): + exists: recommended + unit: NX_ANGLE + exposure_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + magnification(NX_NUMBER): + exists: optional + unit: NX_DIMENSIONLESS + (NXprocess): + exists: ['min', '0', 'max', 'unbounded'] + ceos(NXaberration_model_ceos): + exists: optional + c_1(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + a_1(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + b_2(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + a_2(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + c_3(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + s_3(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + a_3(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + + # based on feedback from Thilo Remmele the following aberrations could be measured + b_4(NXaberration): + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + d_4(NXaberration): + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + a_4(NXaberration): + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + c_5(NXaberration): + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + s_5(NXaberration): + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + r_5(NXaberration): + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + a_6(NXaberration): + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + nion(NXaberration_model_nion): + exists: optional + c_1_0(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_1_2_a(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_1_2_b(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_2_1_a(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_2_1_b(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_2_3_a(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_2_3_b(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_3_0(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_3_2_a(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_3_2_b(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_3_4_a(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_3_4_b(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_4_1_a(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_4_1_b(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_4_3_a(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_4_3_b(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_4_5_a(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_4_5_b(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_5_0(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_5_2_a(NXaberration): + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_5_2_b(NXaberration): + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_5_4_a(NXaberration): + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_5_4_b(NXaberration): + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_5_6_a(NXaberration): + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_5_6_b(NXaberration): + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + (NXibeam_column): + exists: ['min', '0', 'max', '2'] + (NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + (NXchamber): + exists: optional + ion_source(NXsource): + name: + exists: recommended + (NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + emitter_type: + probe(NXion): + charge_state(NX_INT): + exists: recommended + isotope_vector(NX_UINT): + exists: recommended + name: + exists: recommended + voltage(NX_FLOAT): + current(NX_FLOAT): + (NXaperture_em): + exists: recommended + (NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + value(NX_NUMBER): + (NXlens_em): + exists: recommended + doc: | + If the lens is described at least one of the fields + voltage, current, or value should be defined. + (NXfabrication): + exists: recommended + identifier: + exists: recommended + voltage(NX_NUMBER): + exists: recommended + current(NX_NUMBER): + exists: recommended + value(NX_NUMBER): + exists: recommended + EBEAM_DEFLECTOR(NXscanbox_em): + exists: ['min', '0', 'max', 'unbounded'] + (NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + pixel_time(NX_FLOAT): + exists: recommended + IBEAM_DEFLECTOR(NXscanbox_em): + exists: ['min', '0', 'max', 'unbounded'] + (NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + (NXoptical_system_em): + exists: recommended + camera_length(NX_NUMBER): + exists: optional + magnification(NX_NUMBER): + exists: optional + defocus(NX_NUMBER): + exists: recommended + + # this is c_1_0 of aberration_correction + semi_convergence_angle(NX_NUMBER): + exists: recommended + working_distance(NX_FLOAT): + exists: recommended + beam_current(NX_FLOAT): + exists: recommended + beam_current_description: + exists: recommended + + # vendor/instrument-specific data currently case-by-case dependent + # e.g. Nion Co. magboard settings + # instances of NXoptical system can be placed here and specific for + # each NXevent_data_em instance if desired + + ##MK::eventually only adding (NXfabrication) and the new docstring + # is needed, will the rest be inferred automatically? + DETECTOR(NXdetector): + exists: ['min', '1', 'max', 'unbounded'] + doc: | + Description of the type of the detector. + + Electron microscopes have typically multiple detectors. + Different technologies are in use like CCD, scintillator, + direct electron, CMOS, or image plate to name but a few. + local_name: + doc: | + Instrument-specific alias/name + + # it is unfortunate that for NXdetector there are already many places + # how one can specify details which could equally end up in fabrications + # we should give better guidance which option to use + (NXfabrication): + exists: recommended + identifier: + exists: recommended + (NXpump): + exists: ['min', '0', 'max', 'unbounded'] + + # NEW ISSUE: do we consider the EELS spectrometer an own detector or an own functional unit i.e. NXeels + stage_lab(NXstage_lab): + name: + (NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + capabilities: + exists: optional + design: + exists: recommended + description: + exists: optional + + # tricky for arbitrary design we cannot enforce all the below to exist at all + position(NX_FLOAT): + exists: recommended + rotation(NX_FLOAT): + exists: recommended + tilt_1(NX_FLOAT): + exists: recommended + tilt_2(NX_FLOAT): + exists: recommended + measurement(NXevent_data_em_set): + exists: ['min', '0', 'max', '1'] + + #MK because it should be possible to use the application definition + #MK to store e.g. just some descriptions about the instrument + #MK:with which then no measurements are attached + # this would enable to use nxs file also for instrument inventory + # system like offer through ELNs/or LIMS + doc: | + A container for storing a set of NXevent_data_em instances. + + An event is a time interval during which the microscope was configured + in a specific way. The microscope is considered as stable enough during + this interval that a measurement with one or multiple detectors is + possible. What constitutes such time interval depends on how the + microscope is used and which measurements the user would like to perform. + + Each NXevent_data_em instance holds one acquisition task with detectors. + Each NXevent_data_em section contains an em_lab group in which specific + settings and states of the microscope during the time interval + can be stored to document the history of states of the microscope over + the course of the session. + + The NXem application definition offers maximal flexibility. + One extreme could be that the only one NXevent_data_em instance is used + and this covers the time interval of the entire session at the microscope. + The other extreme case is that each collection of an image or even + single spot measurement is defined as an NXevent_data_em instance. + In this case the em_lab group inside the NXevent_data_em also holds + the specific time-dependent state of the microscope with which in theory + all dynamics of the system (if measured) can be captured and documented. + + Nowadays microscopes exists for which hard- and software solutions + enable a tracking of the dynamics of the microscope and the actions + of the user (such as with solution like AXONSynchronicity from Protochips). + The NXem application definition can however also be used for less + complex interaction and lower demands wrt to time tracking activities. + + An NXevent_data_em instance holds specific details about how raw data from + a detector were processed. Raw data may already be post-processed as + they are accessible only by the control software with after some internal + processing happened. Nevertheless, these data have to be distinguished from + post-processed data where e.g. raw data are converted to interpreted + spectra, or orientation mappings. + + This post-processing tasks can be performed (on-the-fly, i.e. during + acquisition for sure during the microscope session) or afterwards. + Post-processing is performed with commercial software or various + types and scripts. + + Currently, several specializations of NXimage_set and Nspectrum_set + are used which store some details of this processing. However, as post- + processing tasks can be substantially more advanced and involved it + is clear that data artifacts from the measurement and data artifacts + generated during post-processing are weakly connected only, maybe + exclusively by the fact that a complex numerical post-processing workflow + just takes one raw dataset from an NXevent_data_em instance but generates + multiple derived data artifacts from this. All these should be described + as own application definitions and only weak connections should be made + to an instance of NXem. Instances of NXsubentry is one mechanism in + NeXus how this can be achieved in the future. + (NXevent_data_em): + exists: ['min', '1', 'max', 'unbounded'] + doc: | + A container holding a specific result of the measurement and + eventually metadata how that result was obtained numerically. + + NXevent_data_em instances can hold several specific NXimage_em or + NXspectrum_em instances taken and considered as one event, i.e. + a point in time when the microscope had the settings specified + either in NXinstrument or in this NXevent_data_em instance. + + The application definition is designed without an explicit need for + having an NXevent_data_em instance that contains an NXimage_em or + NXspectra_em instance. Thereby, an NXevent_data_em can also be used + for just documentation about the specific state of the microscope + irrespective whether data have been collected during this time interval. + + In other words the NXinstrument group details primarily the more + static settings and components of the microscope as they are found + by the operator during the session. The NXevent_data_em samples + the dynamics. + + It is not necessary to store data in NXebeam, NXibeam instances + of NXevent_data_em but in this case it is assumed that the settings + were constant over the entire course of the microscope session + and thus all relevant metadata inside the NXinstrument groups + are sufficient to understand the session. + + So far there exists no standard which a majority of the technology + partners and the materials science electron microscopy community + have accepted which could be used for a very generic documentation, + storage and exchange of electron microscope data. Therefore, it is + still a frequent case that specific files have many fields which cannot + safely be mapped or interpreted. + **Therefore, users are always given the advice to keep the vendor files.** + Working however with these vendor files inside specific software, + like materials databases, demands for parsers which extract pieces of + information from the vendor representation (numerical data and metadata) + and map them on a schema with which the database and its associated + software tools can work with. + + Currently, one would loose immediately track of e.g. provenance and + the origin of certain data in NXevent_data_em instances unless really + all data are safely and reliably copied over into an instance of the + schema. Currently, though, this is sadly effectively prevented in many + cases as vendors indeed implemented often sophisticated provenance + and commercial software state tracking tools but these are not yet + documented covering enough in our opinion so that it is safe to assume + all vendor field names are known, logically understood, interpretable, + and thus mappable on a common schema using a controlled common + vocabulary. + + Therefore we encourage user for now to store for each NXimage_set + or NXspectra_set instance to supply the so-called source of the data. + This can for instance be the name and hashvalue of the original + file which was acquired during the microscope session and from which then + certain details like numerical data and metadata were copied into an + instance of this schema for the purpose of working with the data in + e.g. tools offered by research data management (RDM) systems or + materials database. + + During our work on implementing file format/metadata parsers and + developing this application definition, we realized that **several + software tools currently do not consistently format critical metadata + like time-zone-aware timestamps** when events of data collection or + processing happened. + + We would like to encourage the community and especially the vendors + to work towards a standardization, or at least an open documentation + of the way how time-zone-aware time data are collected and stored how + and where during a microscope session and how they end up in files + and databases with which users interact. + This would enable to supplement instances of this schema with specific + time data and assure that these time data can be used to reliably + contextualize individual datasets and processing steps in materials + information systems. + + For the reason that these measures have not yet been fully taken, + the start_time and end_time is a recommended option. + The idea behind these time-zone-aware dates is to identify when + the data were collected at the microscope but NOT when they were + transcoded by some software tool(s) while storing the data in an + instance of this schema. + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + event_identifier: + exists: recommended + event_type: + exists: recommended + + # a collection of images take and group under this event + # NEW ISSUE: should this only be one instance for a given event? + IMAGE_SET(NXimage_set): + exists: optional + (NXprocess): + source: + \@version: + mode: + exists: recommended + detector_identifier: + (NXprogram): + exists: ['min', '0', 'max', 'unbounded'] + program: + \@version: + stack(NXdata): + exists: recommended + \@signal: + \@axes: + \@AXISNAME_indices: + title: + data_counts(NX_NUMBER): + \@long_name: + + # dimensions: + # rank: 3 + # dim: [[1, n_images], [2, n_y], [3, n_x]] + axis_image_identifier(NX_UINT): + \@long_name: + + # dimensions: + # rank: 1 + # dim: [[1, n_images]] + axis_y(NX_NUMBER): + \@long_name: + + # dimensions: + # rank: 1 + # dim: [[1, n_y]] + axis_x(NX_NUMBER): + \@long_name: + + # dimensions: + # rank: 1 + # dim: [[1, n_x]] + SPECTRUM_SET(NXspectrum_set): + exists: optional + (NXprocess): + source: + \@version: + mode: + exists: recommended + detector_identifier: + (NXprogram): + exists: ['min', '0', 'max', 'unbounded'] + program: + \@version: + stack(NXdata): + exists: recommended + data_counts(NX_NUMBER): + unit: NX_UNITLESS + dimensions: + rank: 3 + dim: [[1, n_y], [2, n_x], [3, n_energy]] + \@long_name: + + # \@signal: counts + # \@axes: [ypos, xpos, energy] + # \@ypos_indices: 0 + # \@xpos_indices: 1 + # \@energy_indices: 2 + axis_y(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + axis_x(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: + axis_energy(NX_NUMBER): + unit: NX_ENERGY + dimensions: + rank: 1 + dim: [[1, n_energy]] + \@long_name: + summary(NXdata): + exists: recommended + data_counts(NX_NUMBER): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_energy]] + \@long_name: + + # \@signal: counts + # \@axes: [energy] + # \@energy_indices: 0 + axis_energy(NX_NUMBER): + unit: NX_ENERGY + dimensions: + rank: 1 + dim: [[1, n_energy]] + \@long_name: + adf(NXimage_set): + exists: optional + (NXprocess): + source: + \@version: + mode: + exists: recommended + detector_identifier: + (NXprogram): + exists: ['min', '0', 'max', 'unbounded'] + program: + \@version: + inner_half_angle(NX_FLOAT): + exists: recommended + unit: NX_ANGLE + doc: | + Annulus inner half angle + outer_half_angle(NX_FLOAT): + exists: recommended + unit: NX_ANGLE + doc: | + Annulus outer half angle + stack(NXdata): + exists: recommended + \@signal: + \@axes: + \@AXISNAME_indices: + + # \@long_name: + title: + data_counts(NX_NUMBER): + \@long_name: + axis_image_identifier(NX_UINT): + \@long_name: + + # dimensions: + # rank: 3 + # dim: [[1, n_images], [2, n_y], [3, n_x]] + axis_y(NX_NUMBER): + \@long_name: + + # dimensions: + # rank: 1 + # dim: [[1, n_y]] + axis_x(NX_NUMBER): + \@long_name: + + # dimensions: + # rank: 1 + # dim: [[1, n_x]] + xray(NXspectrum_set): + exists: optional + (NXprocess): + source: + \@version: + mode: + exists: recommended + detector_identifier: + (NXprogram): + exists: ['min', '0', 'max', 'unbounded'] + program: + \@version: + stack(NXdata): + \@signal: + \@axes: + \@AXISNAME_indices: + + # \@long_name: + title: + data_counts(NX_NUMBER): + \@long_name: + + # dimensions: + # rank: 3 + # dim: [[1, n_y], [2, n_x], [3, n_photon_energy]] + axis_y(NX_NUMBER): + \@long_name: + + # dimensions: + # rank: 1 + # dim: [[1, n_y]] + axis_x(NX_NUMBER): + \@long_name: + + # dimensions: + # rank: 1 + # dim: [[1, n_x]] + axis_photon_energy(NX_NUMBER): + \@long_name: + + # dimensions: + # rank: 1 + # dim: [[1, n_photon_energy]] + summary(NXdata): + \@signal: + \@axes: + \@AXISNAME_indices: + + # \@long_name: + title: + data_counts(NX_NUMBER): + \@long_name: + + # dimensions: + # rank: 1 + # dim: [[1, n_photon_energy]] + axis_photon_energy(NX_NUMBER): + \@long_name: + + # dimensions: + # rank: 1 + # dim: [[1, n_photon_energy]] + # NEW ISSUE: all of this should be offloaded to NXem_edx -\-> + indexing(NXprocess): + exists: optional + + ##MK:: much content of the base class has not been added although + # should be considered and made recommended at least + ELEMENTNAME(NXprocess): + exists: ['min', '1', 'max', '256'] + summary(NXdata): + \@signal: + \@axes: + \@AXISNAME_indices: + + # \@long_name: + title: + data_counts(NX_NUMBER): + \@long_name: + + # dimensions: + # rank: 2 + # dim: [[1, n_y], [2, n_x]] + axis_y(NX_NUMBER): + \@long_name: + + # dimensions: + # rank: 1 + # dim: [[1, n_y]] + axis_x(NX_NUMBER): + \@long_name: + + # dimensions: + # rank: 1 + # dim: [[1, n_x]] + # NEW ISSUE: all of this should be offloaded to NXem_edx -\-> + eels(NXspectrum_set): + exists: optional + (NXprocess): + source: + \@version: + mode: + exists: recommended + detector_identifier: + (NXprogram): + exists: ['min', '0', 'max', 'unbounded'] + program: + \@version: + stack(NXdata): + \@signal: + \@axes: + \@AXISNAME_indices: + + # \@long_name: + title: + data_counts(NX_NUMBER): + \@long_name: + + # dimensions: + # rank: 3 + # dim: [[1, n_y], [2, n_x], [3, n_energy_loss]] + axis_y(NX_NUMBER): + \@long_name: + + # dimensions: + # rank: 1 + # dim: [[1, n_y]] + axis_x(NX_NUMBER): + \@long_name: + + # dimensions: + # rank: 1 + # dim: [[1, n_x]] + axis_energy_loss(NX_NUMBER): + \@long_name: + + # dimensions: + # rank: 1 + # dim: [[1, n_energy_loss]] + summary(NXdata): + \@signal: + \@axes: + \@AXISNAME_indices: + + # \@long_name: + title: + data_counts(NX_NUMBER): + \@long_name: + + # dimensions: + # rank: 1 + # dim: [[1, n_energy_loss]] + axis_energy_loss(NX_NUMBER): + + # dimensions: + # rank: 1 + # dim: [[1, n_energy_loss]] + \@long_name: + + # base classes for which we have at the moment no example implemented + # consider to replace se, bse, bf, df, chamber, ronchigram, by generic NXimage_set + # NEW ISSUE: all of this should be offloaded to NXem_eels -\-> + kikuchi(NXimage_set): + exists: optional + (NXprocess): + source: + \@version: + mode: + exists: recommended + detector_identifier: + (NXprogram): + exists: ['min', '0', 'max', 'unbounded'] + program: + \@version: + stack(NXdata): + \@signal: + \@axes: + \@AXISNAME_indices: + + # \@long_name: + title: + data_counts(NX_NUMBER): + \@long_name: + + # dimensions: + # rank: 3 + # dim: [[1, n_p], [2, n_y], [3, n_x]] + pattern_identifier(NX_UINT): + \@long_name: + + # dimensions: + # rank: 1 + # dim: [[1, n_p]] + axis_y(NX_NUMBER): + \@long_name: + + # dimensions: + # rank: 1 + # dim: [[1, n_y]] + axis_x(NX_NUMBER): + \@long_name: + + # dimensions: + # rank: 1 + # dim: [[1, n_x]] + scan_point_identifier(NX_UINT): + + # \@long_name: + # dimensions: + # rank: 1 + # dim: [[1, n_p]] + # no summary because this will be handled by EBSD + + # (NXimage_set_em_se): + # exists: optional + # (NXimage_set_em_bse): + # exists: optional + # (NXimage_set_em_bf): + # exists: optional + # (NXimage_set_em_df): + # exists: optional + # (NXspectrum_set_em_auger): + # exists: optional + # (NXspectrum_set_em_cathodolum): + # exists: optional + # (NXimage_set_em_ecci): + # exists: optional + # (NXimage_set_em_diffrac): + # exists: optional + # (NXimage_set_em_ronchigram): + # exists: optional + # (NXimage_set_em_chamber): + # exists: optional + # a collection of specific details about state of the microscope + em_lab(NXinstrument): + exists: optional + (NXchamber): + exists: optional + (NXebeam_column): + exists: ['min', '0', 'max', '1'] + (NXchamber): + exists: optional + electron_source(NXsource): + exists: optional + voltage(NX_FLOAT): + (NXaperture_em): + exists: optional + value(NX_NUMBER): + (NXlens_em): + exists: optional + voltage(NX_NUMBER): + exists: recommended + current(NX_NUMBER): + exists: recommended + value(NX_NUMBER): + exists: recommended + aberration_correction(NXcorrector_cs): + exists: recommended + applied(NX_BOOLEAN): + name: + exists: optional + (NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + ZEMLIN_TABLEAU(NXprocess): + exists: recommended + description: + exists: optional + tilt_angle(NX_FLOAT): + exists: recommended + unit: NX_ANGLE + exposure_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + magnification(NX_NUMBER): + exists: optional + unit: NX_DIMENSIONLESS + (NXprocess): + exists: ['min', '0', 'max', 'unbounded'] + ceos(NXaberration_model_ceos): + exists: optional + c_1(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + a_1(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + b_2(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + a_2(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + c_3(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + s_3(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + a_3(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + + # based on feedback from Thilo Remmele the following aberrations could be measured + b_4(NXaberration): + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + d_4(NXaberration): + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + a_4(NXaberration): + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + c_5(NXaberration): + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + s_5(NXaberration): + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + r_5(NXaberration): + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + a_6(NXaberration): + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + angle(NX_FLOAT): + unit: NX_ANGLE + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: recommended + unit: NX_TIME + nion(NXaberration_model_nion): + exists: optional + c_1_0(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_1_2_a(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_1_2_b(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_2_1_a(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_2_1_b(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_2_3_a(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_2_3_b(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_3_0(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_3_2_a(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_3_2_b(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_3_4_a(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_3_4_b(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_4_1_a(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_4_1_b(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_4_3_a(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_4_3_b(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_4_5_a(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_4_5_b(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_5_0(NXaberration): + exists: recommended + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_5_2_a(NXaberration): + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_5_2_b(NXaberration): + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_5_4_a(NXaberration): + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_5_4_b(NXaberration): + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_5_6_a(NXaberration): + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + c_5_6_b(NXaberration): + exists: optional + magnitude(NX_FLOAT): + unit: NX_LENGTH + uncertainty(NX_FLOAT): + exists: recommended + unit: NX_LENGTH + uncertainty_model: + exists: recommended + delta_time(NX_FLOAT): + exists: optional + unit: NX_TIME + (NXibeam_column): + exists: ['min', '0', 'max', '2'] + (NXchamber): + exists: optional + ion_source(NXsource): + exists: optional + probe(NXion): + exists: recommended + charge_state(NX_INT): + exists: recommended + isotope_vector(NX_UINT): + exists: recommended + name: + exists: recommended + voltage(NX_FLOAT): + exists: recommended + current(NX_FLOAT): + exists: recommended + (NXaperture_em): + exists: optional + value(NX_NUMBER): + exists: recommended + (NXlens_em): + exists: optional + voltage(NX_NUMBER): + exists: recommended + current(NX_NUMBER): + exists: recommended + value(NX_NUMBER): + exists: recommended + ebeam_deflector(NXscanbox_em): + exists: optional + pixel_time(NX_FLOAT): + exists: recommended + ibeam_deflector(NXscanbox_em): + exists: optional + + # NEW ISSUE: how to handle situations where we wish to describe multiple deflectors? + (NXoptical_system_em): + exists: optional + camera_length(NX_NUMBER): + exists: optional + magnification(NX_NUMBER): + exists: optional + defocus(NX_NUMBER): + exists: recommended + semi_convergence_angle(NX_NUMBER): + exists: recommended + working_distance(NX_FLOAT): + exists: recommended + beam_current(NX_FLOAT): + exists: recommended + beam_current_description: + exists: recommended + (NXdetector): + exists: optional + + # dynamically changing detector settings uses only during this NXevent_data_em + (NXpump): + exists: optional + (NXstage_lab): + exists: optional + position(NX_FLOAT): + exists: recommended + rotation(NX_FLOAT): + exists: recommended + tilt_1(NX_FLOAT): + exists: recommended + tilt_2(NX_FLOAT): + exists: recommended + (NXuser): + exists: ['min', '0', 'max', 'unbounded'] + name: + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 14203c50c2c3841dc7955b2b7b911e389f613155078bb310415ec84cd5bf7487 +# +# +# +# +# +# +# Characterization of a sample during a session on an electron microscope. +# +# **The idea and aim of NXem**: +# Electron microscopy (EM) research, whether it be performed with scanning electron +# microscope (SEM) or transmission electron microscope (TEM) instruments, uses +# versatile tools for preparing and characterizing samples and specimens. +# The term specimen is considered a synonym for sample in this application definition. +# A specimen is a physical portion of material that is studied/characterized during +# the microscope session, eventually in different places on the specimen surface, +# illuminating the surface layers or shining through thin specimens. +# These places are named regions of interest (ROIs). +# +# Fundamentally, an electron microscope is an electron accelerator. +# Experimentalists use it in sessions during which they characterize as well as +# prepare specimens. This application definition describes data and metadata about +# processes and characterization tasks applied to one specimen. +# The application definition focuses on the usage of EM in materials research. +# The application definition design makes it in principle applicable also in +# cryo-EM on biomaterials. +# +# Multiple specimens have to be described with multiple :ref:`NXentry` instances. +# +# **Electron microscopes motivate the development of an embracing data schema:** +# There are research groups who use an EM in a manner where it is exclusively +# operated by a single, instrument-responsible scientists or a team of scientists. +# These users may perform analyses for other users as a service task, especially +# in large research facility settings. Oftentimes, though, and especially for +# cutting-edge instruments, the scientists guide the process maybe even control +# the microscope. Instruments are usually controlled on-premises but also more +# and more functionalities for remote control have become available. +# Scientists oftentimes can ask technicians for support. In all cases, +# these people are considered users. Users might have different +# roles though. +# +# The rational behind a common EM schema rather than making separate schemas +# for SEM or TEM are primarily the key similarities of SEM and TEM +# instruments: +# +# Both type of instruments have electro-magnetic lenses. These may differ in +# design, alignment, number, and level of corrected for aberrations. +# As an obvious difference, a TEM is mainly used for measuring the transmitted +# electron beam. This calls for using a different lens setup and relative +# placement of the specimen in the lens setup. Also TEM specimens are +# substantially thinner than specimens characterized with SEM to enable an +# illumination through the specimen. This offers capabilities for probing of +# additional physical mechanisms of electron-matter interaction which are +# unavailable in SEMs. +# +# Nevertheless, both types of electron microscopes use detector systems which +# measure different types of signals that originate from the same set of +# radiation/specimen interactions. Often these detectors have a similar design +# and technology or are even used both in SEMs and TEMs. +# +# **An embracing schema instead of specific SEM or TEM schemas**: +# Given these physical and technical differences, different instruments have +# been developed. This led to a coexistence of two broad interacting +# communities: SEM and TEM users. From a data science perspective, we +# acknowledge that the more specific a research question is and the narrower it +# is the addressed circle of users which develops or uses schemas for research +# data management (RDM) with EM, the more understandable it is that scientists +# of either community (or sub-community) ask for designing method-specific schemas. +# +# Researchers who have a single (main) microscope of some vendor in their lab, +# may argue they need an NXem_vendor_name schema or an NXem_microscope_name or +# an NXem_sem or a NXem_tem schema. +# Scientists exclusively working with one technique or type of signal probed +# (X-rays, electrons) may argue they wish to be pragmatic and store only +# what is immediately relevant for their particular technique and +# research questions. In effect, they may advocate for method-specific +# schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. +# +# However, the history of electron microscopy has shown that these activities led +# to a zoo of schemas and especially vocabulary in use with implementations of these +# into many data and file formats. There is nothing which prevents the communities +# to make these schemas open and interoperable. Open here means not that all +# data stored according to such schemas have to end up in the open-source domain. +# There can be embargo periods first of all. +# +# Open means that the metadata and associated schemata are documented in a manner +# that as many details are open as possible in the sense that others can understand +# what the (meta)data mean conceptually. Instead of trying of maintain a zoo +# of eventually difficult to make interoperable formats and schema we would like +# to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ +# should guide all decisions how data and metadata should be stored. +# +# EM instruments, software, and research are moving targets. Consequently, +# there is a key challenge and inconvenience with having many different schemas +# with associated representations of data and metadata: Each combination of +# schemas or an interoperable-made handshake between two file formats or software +# packages has to be maintained by software developers. This counts especially +# when data should be processed interoperably between software packages. +# +# This brings two problems: Many software tools and parsers for the handshaking +# between tools have to be maintained. This can result in usage of different +# terminology, which in turn results in representations and connections made +# between different data representations and workflows that are not +# machine-actionable. +# `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ +# +# **The advantage of working towards a common vocabulary and representation**: +# A common vocabulary can serve interoperability as developers of schemas and +# scientists can reuse for instance these terms, thus supporting interoperability. +# Ideally, scientists specialize an application definition only for the few very +# specific additional quantities of their instruments and techniques. This is +# better than reimplementing the wheel for descriptions of EM instruments. +# This route of more standardization can support the EM community in that it +# removes the necessity for having to maintain a very large number of schemas. +# +# Aiming for more standardization, i.e. a lower number of schemas rather than +# a single standard for electron microscopy is a compromise that can serve +# academia and industry as it enables a focusing of software development +# efforts on those schemas, on fixing and discussing them, and on harmonizing +# their common vocabulary. These activities can be specifically relevant also +# for technology partners building EM hard- and software as it improves the +# longevity of certain schemas; and thus can help with incentivizing them to support +# the community with implementing support for such schemas into their applications. +# +# In effect, everybody can gain from this as it will likely reduce the cases +# in which scientists have to fix bugs in making their own tools compliant and +# interoperable with tools of their colleagues and the wider community. +# +# The here proposed NXem application definition offers modular components +# (EM-research specific base classes) for defining schemas for EM research. +# Thereby, NXem can be useful to extends top-level ontologies towards a domain- +# and method-specific ontology for electron microscopy as it is used for +# materials research. +# +# Working towards a common vocabulary is a community activity that profits from +# everybody reflecting in detail whether certain terms they have used in the past +# are not eventually conceptually similar if not the same as what this application +# definition and its base classes provide. We are happy for receiving your feedback. +# +# **Addressing the generality versus specificity challenge**: +# It is noteworthy to understand that (not only for NeXus), schemas differ +# already if at least one field is required in one version of the schema, +# but it is set optional in another schema. If group(s), field(s), or +# attributes are removed or added, or even a docstring is changed, schemas can +# become inconsistent. It is noteworthy to mention that the idea of a NeXus application +# definition serves as a contract between a data provider and a data consumer. +# Providers can be the software of a specific microscopes or users with specific +# analysis needs. Consumers can be again specific software tools, like vendor +# software for controlling the instrument or a scientific software for doing +# artificial intelligence analyses on EM data). Such changes of a schema lead +# to new versions. Strictly speaking an application definition can only be +# fully general if it does not make a single entry required, in which case however +# it would also not offer much value as even empty datasets would be compliant +# with such a schema. +# +# **Verification of constraints and conditions**: +# Tools like NeXus so far do not avoid or protect against all such possible +# inconsistencies; however NeXus offers a mechanism and toolset, through which +# schemas can be documented and defined. In effect, having an openly documented +# (at a case-specific level of technical detail) schema is a necessary but alone +# not a sufficient step to take EM research on a route of machine-actionable +# and interoperable FAIR data. +# +# This stresses again the fundamental and necessary role of working towards +# a common vocabulary and, with a longer perspective in mind, a machine-actionable +# knowledge representation and verification engine. So far many conditions and +# requirements are formulated in the docstrings of the respective entries of +# the application definition. +# +# **NXem takes a key step towards standardization of EM data schemas**. +# It offers a controlled vocabulary and set of relations between concepts and +# enables the description of the data which are collected for research with +# electron microscopes. To be most efficient and offering reusability, the NXem +# application definition should be understood as a template that one should +# ideally use as is. NXem can be considered a base for designing more specialized +# definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). +# +# **The use of NXem should be as follows:** +# Offspring application definitions should not remove groups but leave these +# optional or, even better, propose changes to NXem. +# +# A particular challenge with electron microscopes as physical instruments are +# their dynamics. To make EM data understandable, repeatable, and eventually +# corresponding experiments reproducible in general requires a documentation +# of the spatio-temporal dynamics of the instrument in its environment. +# It is questionable to which level such a reproducibility is possible with EM +# at all considering beam damage, effects of the environment, and other not +# exactly quantifiable influences. +# While this points to the physical limitations there are also practical and +# economical constraints on how completely EM research can be documented: +# For most commercial systems there is a specific accessibility beyond which +# detailed settings like lens excitations and low-level hardware settings +# may not be retrievable as technology partners have a substantiated interest in +# finding a compromise between being open to their users and securing their +# business models. +# +# By design, EM experiments illuminate the specimen with electrons as a +# consequence of which the specimen changes if not may get destroyed. +# As such, repeatability of numerical processing and clear descriptions of +# procedures and system setups should be addressed first. +# +# If especially a certain simulation package needs a detailed view of the +# geometry of the lens system and its excitations during the course of the +# experiment, it is difficult to fully abstract the technical details of the +# hardware into a set of names for fields and groups that make for a compromise +# between clarity but being system-agnostic at the same time. +# Settings of apertures are an example where aperture modes are in most cases +# aliases behind which there is a set of very detailed settings specific to the +# software and control units used. These settings are difficult to retrieve, +# are not fully documented by technology partners. This simplification for +# users of microscopes makes experiments easier understandable. +# On the flipside these subtilities limit the opportunities of especially open- +# source developments to make data schemas covering enough for general usage and +# specific enough and sufficiently detailed to remain useful for +# research by electron microscopy domain experts. +# +# Instead, currently it is for the docstring to specify what is conceptually +# eventually behind such aliases. The design rule we followed while drafting +# this NXem application definition and base classes is that there are numerous +# (technical) details about an EM which may warrant a very detailed technical +# disentangling of settings and reflection of numerous settings as deeply +# nested groups, fields and attributes. An application definition can offer a +# place to hold these nested representations; however as discussed +# at the cost of generality. +# +# Which specific details matter for answering scientific research questions is +# a difficult question to answer by a single team of scientists, especially +# if the application definition is to speak for a number of vendors. What makes +# it especially challenging is when the application definition is expected to +# hold all data that might be of relevance for future questions. +# +# We are skeptical if there is one such representation that can fulfill all these +# aims and interest, while remaining at the same time approachable and executable +# by a large number of scientists in a community. However, we are also convinced +# that this is not a reason to accept the status quo of having a very large set +# of oftentimes strongly overlapping and redundant schemas. +# +# NXem is our proposal to motivate the EM community to work towards more +# standardization and discussion of what constitutes data, i.e. metadata, +# numerical and categorical data in research with electron microscopes. We found +# that existent terminology can be encoded into a more controlled vocabulary. +# +# We have concluded that despite all these details of current EM research with +# SEM, TEM, and focused-ion beam instruments, there a clearly identifiable +# common components and generalizable settings of EM research use cases. +# Therefore, +# +# **This application definition has the following components at the top-level:** +# +# * Generic experimental details (time-zone-aware timestamp, identifiers, name); +# conceptually these are session details. A session at a microscope may +# involve the characterization of multiple specimens. For each specimen +# an instance of an (NXentry) is created. Details of the instrument have to +# be stored at least in an entry. Other entries should refer to these +# metadata via links to reduce redundancies. +# * Each signal, such as a spectrum or image taken at the microscope, should +# have an associated time-zone-aware time stamp and report of the specific +# settings of the microscope at that point in time when the image was taken. +# This is why instances of :ref:`NXevent_data_em` have an own em_lab section. +# The reason is that EMs can be highly dynamic, be used to illuminate the specimen +# differently or show drift during signal acquisition, to name but a few effects. +# What constitutes a single EM experiment/measurement? +# This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), +# taking of a secondary electron image for fracture analysis, taking a set of +# EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a +# specimen in preparation for e.g. an atom probe experiment. +# * :ref:`NXmonitor`; +# instances to keep track of time-dependent quantities +# pertaining to specific components of the instrument. +# Alternatively, NXevent_data_em instances can be used to store +# time-zone-aware dates of the components, which is +# relevant for documenting as exactly as practically possible settings +# when images and spectra were taken. +# * :ref:`NXinstrument`; +# conceptually this is a container to store arbitrary level of detail of the +# technical components of the microscope as a device and the lab in which +# the microscope is operated. +# * :ref:`NXuser`; +# conceptually, this is a set with at least one NXuser instance which details +# who operated or performed the measurement. Additional NXusers can be +# referred to in an NXevent_data_em instance to store +# individualized details who executed an event of data acquisition or processing. +# * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; +# each NXevent_data_em instance is a container to group specific details +# about the state of the microscope when a measurement was taken and +# relevant data and eventual processing steps were taken (on-the-fly). +# * :ref:`NXdata`; at the top-level, conceptually, this is a place for documenting +# available default plottable data. A default plottable can be useful for +# research data management systems to show a visual representation of some +# aspect of the content of the EM session. +# Default plottables not intended to serve every possible analysis and +# visualization demand but be a preview. We made this choice because what +# constitutes a useful default plot is often a matter of interpretation, +# somewhat of personal taste, and community standards. In effect, default +# plottables are case- and method-specific. +# +# Usually a session at a microscope is used to collect multiple signals. +# Examples for possible default plottables could be arbitrarily taken secondary, +# back-scattered, electron image, diffraction pattern, EELS spectra, composition, +# or orientation mappings to name but a few. +# +# **There are a few design choices to consider with sub-ordinate groups:** +# +# * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` +# instances to hold data at the earliest possible step in the computational +# processing (which is usually performed with the microscope control and or +# integrated analysis software). The formatting of the NXdata groups enables to +# display image and spectra with web technology visualization software. +# NeXus specifies only the data model, i.e. the terms and their relations. +# These descriptions can be implemented and stored in JSON, HDF5, XML, or HSDS, +# file storage, or even other formats, although HDF5 is often used. +# * When two- and three-dimensional geometric primitive data are stored, it is useful +# to write additional optional XDMF fields which support additional plotting of +# the data with visualization software like Paraview or Blender. +# * Consumable results of EM characterization tasks are usually a sub-set of +# data artifacts, as there is not an infinite amount of possible +# electron/ion beam-specimen interactions. +# * Images of electron counts detected in specific operation modes (bright +# field, dark field in TEM, secondary/back-scattered, Kikuchi). +# * Spectra (X-ray quanta or Auger electron counts) +# * These data are in virtually all cases a result of some numerical processing. +# These data and processing steps are modelled as instances of :ref:`NXprocess` +# which use terms from a controlled vocabulary e.g. SE (secondary electron), +# BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). +# +# **A key question often asked with EM experiments is how the actual (meta)data +# should be stored (in memory or on disk)**. To this end the schema here makes no +# specific assumptions, not even that all the fields/group of a schema instance +# have to be stored at all into a single file. Instead, the schema specifies the +# relations between metadata, some of the constraints and conditions on how the +# data should be formatted, what the data conceptually represent, and which terms +# (controlled vocabulary) is practical to store to index specific quantities. +# +# In effect, the application definition is a graph which describes how +# numerical data and (meta)data for EM research are related to one another. +# +# Electron microscopy experiments are usually controlled/performed via +# commercial integrated acquisition and instrument control software. +# In many cases, an EM dataset is useful only if it gets post-processed +# already during the acquisition, i.e. while the scientist is sitting +# at the microscope. +# Many of these processes are automated, while some demand GUI +# interactions with the control software. Examples include collecting +# of diffraction pattern and on-the-fly indexing of these. +# +# It is possible that different types of programs might be used to +# perform these processing steps whether on-the-fly or not. If this is +# the case the processing should be structured with individual :ref:`NXprocess` +# instances. If the program and/or version used for processing referred +# to in an NXprocess group is different to the program and version +# mentioned in this field, the NXprocess needs +# to hold an own program and version. +# +# +# +# +# +# An at least as strong as SHA256 hashvalue of the file +# that specifies the application definition. +# +# +# +# +# +# NeXus NXDL schema to which this file conforms. +# +# +# +# +# +# +# +# Ideally, a (globally) unique persistent identifier +# for referring to this experiment. +# +# The identifier is usually defined/issued by the facility, +# laboratory, or the principle investigator. +# The identifier enables to link experiments to e.g. proposals. +# +# +# +# +# Free-text description about the experiment. +# +# Users are strongly advised to detail the sample history in the respective +# field and fill rather as completely as possible the fields of this +# application definition rather than write details about the experiment +# into this free-text description field. +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC information included +# when the microscope session started. If the application demands that time +# codes in this section of the application definition should only be used +# for specifying when the experiment was performed - and the exact +# duration is not relevant - this start_time field should be used. +# +# Often though it is useful to specify a time interval by specifying both +# a start_time and an end_time to allow for more detailed bookkeeping and +# interpretation of the experiment. The user should be aware that even +# with having both time instances specified, it may not be possible +# to infer how long the experiment took or for how long data were acquired. +# +# More detailed timing data over the course of the experiment have +# to be collected to compute this. These computations can take +# advantage of individual time stamps in NXevent_data_em instances to +# provide additional pieces of information. +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC included when +# the microscope session ended. +# +# +# +# +# +# +# +# +# +# Binary container for a file or a compressed collection of files which +# can be used to add further descriptions and details to the experiment. +# The container can hold a compressed archive. +# +# +# +# +# A small image that is representative of the entry; this can be an +# image taken from the dataset like a thumbnail of a spectrum. +# A 640 x 480 pixel jpeg image is recommended. +# Adding a scale bar to that image is recommended but not required +# as the main purpose of the thumbnail is to provide e.g. thumbnail +# images for displaying them in data repositories. +# +# +# +# +# +# Contact information and eventually details of at least one person +# involved in the taking of the microscope session. This can be the +# principle investigator who performed this experiment. +# Adding multiple users if relevant is recommended. +# +# +# +# Given (first) name and surname of the user. +# +# +# +# +# Name of the affiliation of the user at the point in time +# when the experiment was performed. +# +# +# +# +# Postal address of the affiliation. +# +# +# +# +# Email address of the user at the point in time when the experiment +# was performed. Writing the most permanently used email is recommended. +# +# +# +# +# Globally unique identifier of the user as offered by services +# like ORCID or ResearcherID. If this field is field the specific service +# should also be written in orcid_platform +# +# +# +# +# Name of the OrcID or ResearcherID where the account +# under orcid is registered. +# +# +# +# +# (Business) (tele)phone number of the user at the point +# in time when the experiment was performed. +# +# +# +# +# Which role does the user have in the place and at the point +# in time when the experiment was performed? Technician operating +# the microscope. Student, postdoc, principle investigator, guest +# are common examples. +# +# +# +# +# Account name that is associated with the user in social media platforms. +# +# +# +# +# Name of the social media platform where the account +# under social_media_name is registered. +# +# +# +# +# +# +# A description of the material characterized in the experiment. +# Sample and specimen are threaded as de facto synonyms. +# +# +# +# A qualifier whether the sample is a real one or a +# virtual one (in a computer simulation) +# +# +# +# +# +# +# +# +# +# Ideally (globally) unique persistent identifier. The name distinguishes +# the specimen from all others and especially the predecessor/origin +# from where the specimen was cut. +# +# This field must not be used for an alias of the sample. +# Instead, use short_title for this, more convenient alias name. +# +# In cases where multiple specimens have been loaded into the microscope +# the name has to identify the specific one, whose results are stored +# by this NXentry, because a single NXentry should be used only for +# the characterization of a single specimen. +# +# Details about the specimen preparation should be stored in the +# sample history. +# +# +# +# +# Ideally, a reference to a (globally) unique persistent identifier, +# representing a data artifact which documents ideally as many details +# of the material, its microstructure, and its thermo-chemo-mechanical +# processing/preparation history as possible. +# +# The sample_history is the record what happened before the specimen +# was placed into the microscope at the beginning of the session. +# +# In the case that such a detailed history of the sample/specimen is not +# available, use this field as a free-text description to specify a +# sub-set of the entire sample history, i.e. what you would consider are +# the key steps and relevant information about the specimen, +# its material, microstructure, thermo-chemo-mechanical processing state, +# and the details of the preparation. +# +# Specific details about eventual physically-connected material like +# embedding resin should be documented ideally also in the sample_history. +# If all fails, the description field can be used but it is strongly +# discouraged because it leads to eventually non-machine-actionable +# data. +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC information +# when the specimen was prepared. +# +# Ideally report the end of the preparation, i.e. the last known time +# the measured specimen surface was actively prepared. Usually this should +# be a part of the sample history, i.e. the sample is imagined handed over +# for analysis. +# +# Knowing when the specimen was exposed to e.g. specific atmosphere is +# especially required for environmentally sensitive material such as +# hydrogen charged specimens or experiments +# including tracers with a short half time. Further time stamps prior +# to preparation_date should better be placed in resources which +# describe the sample_history. +# +# +# +# +# Possibility to give an abbreviation or alias of the specimen name field. +# +# +# +# +# List of comma-separated elements from the periodic table that are +# contained in the sample. If the sample substance has multiple +# components, all elements from each component must be included in +# `atom_types`. +# +# The purpose of the field is to offer materials database systems an +# opportunity to parse the relevant elements without having to interpret +# these from the sample history. +# +# +# +# +# +# (Measured) sample thickness. The information is recorded to qualify +# if the beam used was likely able to shine through the specimen. +# For scanning electron microscopy, in many cases the specimen is much +# thicker than what is illuminatable by the electron beam. +# In this case the value should be set to the actual thickness of +# the specimen viewed for an illumination situation where the nominal +# surface normal of the specimen is parallel to the optical axis. +# +# +# +# +# +# (Measured) density of the specimen. For multi-layered specimens this +# field should only be used to describe the density of the excited +# volume. For scanning electron microscopy the usage of this field is +# discouraged and instead an instance of an :ref:`NXinteraction_vol_em` +# within individual :ref:`NXevent_data_em` instances can provide a much +# better description of the relevant details why one may wish to store +# the density of the specimen. +# +# +# +# +# +# Discouraged free-text field in case properly designed records +# for the sample_history are not available. +# +# +# +# +# +# Hard link to a location in the hierarchy of the NeXus file +# where the data for default plotting are stored. +# +# +# +# +# +# +# +# +# +# +# +# Metadata and numerical data of the microscope and the lab in which it stands. +# +# The em_lab section contains a description of the instrument and its components. +# The component descriptions in this section differ from those inside individual +# NXevent_data_em sections. These event instances take the role of time snapshot. +# For an NXevent_data_em instance users should store only those settings for a +# component which are relevant to understand the current state of the component. +# Here, current means at the point in time, i.e. the time interval, +# which the event represents. +# +# For example it is not relevant to store in each event's electron_source +# group again the details of the gun type and manufacturer but only the +# high-voltage if for that event the high-voltage was different. If for all +# events the high-voltage was the same it is not even necessary to include +# an electron_source section in the event. +# +# Individual sections of specific type should have the following names: +# +# * NXaperture: the name should match with the name of the lens +# * NXlens_em: condenser_lens, objective_lens are commonly used names +# * NXcorrector_cs: device for correcting spherical aberrations +# * NXstage_lab: a collection of component for holding the specimen and +# eventual additional component for applying external stimuli on the sample +# * NXdetector: several possible names like secondary_electron, +# backscattered_electron, direct_electron, ebsd, edx, wds, auger, +# cathodoluminescence, camera, ronchigram +# +# +# +# Given name of the microscope at the hosting institution. This is an alias. +# Examples could be NionHermes, Titan, JEOL, Gemini, etc. +# +# +# +# +# Location of the lab or place where the instrument is installed. +# Using GEOREF is preferred. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# If the lens is described at least one of the fields +# voltage, current, or value should be defined. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# If the lens is described at least one of the fields +# voltage, current, or value should be defined. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Description of the type of the detector. +# +# Electron microscopes have typically multiple detectors. +# Different technologies are in use like CCD, scintillator, +# direct electron, CMOS, or image plate to name but a few. +# +# +# +# Instrument-specific alias/name +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# A container for storing a set of NXevent_data_em instances. +# +# An event is a time interval during which the microscope was configured +# in a specific way. The microscope is considered as stable enough during +# this interval that a measurement with one or multiple detectors is +# possible. What constitutes such time interval depends on how the +# microscope is used and which measurements the user would like to perform. +# +# Each NXevent_data_em instance holds one acquisition task with detectors. +# Each NXevent_data_em section contains an em_lab group in which specific +# settings and states of the microscope during the time interval +# can be stored to document the history of states of the microscope over +# the course of the session. +# +# The NXem application definition offers maximal flexibility. +# One extreme could be that the only one NXevent_data_em instance is used +# and this covers the time interval of the entire session at the microscope. +# The other extreme case is that each collection of an image or even +# single spot measurement is defined as an NXevent_data_em instance. +# In this case the em_lab group inside the NXevent_data_em also holds +# the specific time-dependent state of the microscope with which in theory +# all dynamics of the system (if measured) can be captured and documented. +# +# Nowadays microscopes exists for which hard- and software solutions +# enable a tracking of the dynamics of the microscope and the actions +# of the user (such as with solution like AXONSynchronicity from Protochips). +# The NXem application definition can however also be used for less +# complex interaction and lower demands wrt to time tracking activities. +# +# An NXevent_data_em instance holds specific details about how raw data from +# a detector were processed. Raw data may already be post-processed as +# they are accessible only by the control software with after some internal +# processing happened. Nevertheless, these data have to be distinguished from +# post-processed data where e.g. raw data are converted to interpreted +# spectra, or orientation mappings. +# +# This post-processing tasks can be performed (on-the-fly, i.e. during +# acquisition for sure during the microscope session) or afterwards. +# Post-processing is performed with commercial software or various +# types and scripts. +# +# Currently, several specializations of NXimage_set and Nspectrum_set +# are used which store some details of this processing. However, as post- +# processing tasks can be substantially more advanced and involved it +# is clear that data artifacts from the measurement and data artifacts +# generated during post-processing are weakly connected only, maybe +# exclusively by the fact that a complex numerical post-processing workflow +# just takes one raw dataset from an NXevent_data_em instance but generates +# multiple derived data artifacts from this. All these should be described +# as own application definitions and only weak connections should be made +# to an instance of NXem. Instances of NXsubentry is one mechanism in +# NeXus how this can be achieved in the future. +# +# +# +# A container holding a specific result of the measurement and +# eventually metadata how that result was obtained numerically. +# +# NXevent_data_em instances can hold several specific NXimage_em or +# NXspectrum_em instances taken and considered as one event, i.e. +# a point in time when the microscope had the settings specified +# either in NXinstrument or in this NXevent_data_em instance. +# +# The application definition is designed without an explicit need for +# having an NXevent_data_em instance that contains an NXimage_em or +# NXspectra_em instance. Thereby, an NXevent_data_em can also be used +# for just documentation about the specific state of the microscope +# irrespective whether data have been collected during this time interval. +# +# In other words the NXinstrument group details primarily the more +# static settings and components of the microscope as they are found +# by the operator during the session. The NXevent_data_em samples +# the dynamics. +# +# It is not necessary to store data in NXebeam, NXibeam instances +# of NXevent_data_em but in this case it is assumed that the settings +# were constant over the entire course of the microscope session +# and thus all relevant metadata inside the NXinstrument groups +# are sufficient to understand the session. +# +# So far there exists no standard which a majority of the technology +# partners and the materials science electron microscopy community +# have accepted which could be used for a very generic documentation, +# storage and exchange of electron microscope data. Therefore, it is +# still a frequent case that specific files have many fields which cannot +# safely be mapped or interpreted. +# **Therefore, users are always given the advice to keep the vendor files.** +# Working however with these vendor files inside specific software, +# like materials databases, demands for parsers which extract pieces of +# information from the vendor representation (numerical data and metadata) +# and map them on a schema with which the database and its associated +# software tools can work with. +# +# Currently, one would loose immediately track of e.g. provenance and +# the origin of certain data in NXevent_data_em instances unless really +# all data are safely and reliably copied over into an instance of the +# schema. Currently, though, this is sadly effectively prevented in many +# cases as vendors indeed implemented often sophisticated provenance +# and commercial software state tracking tools but these are not yet +# documented covering enough in our opinion so that it is safe to assume +# all vendor field names are known, logically understood, interpretable, +# and thus mappable on a common schema using a controlled common +# vocabulary. +# +# Therefore we encourage user for now to store for each NXimage_set +# or NXspectra_set instance to supply the so-called source of the data. +# This can for instance be the name and hashvalue of the original +# file which was acquired during the microscope session and from which then +# certain details like numerical data and metadata were copied into an +# instance of this schema for the purpose of working with the data in +# e.g. tools offered by research data management (RDM) systems or +# materials database. +# +# During our work on implementing file format/metadata parsers and +# developing this application definition, we realized that **several +# software tools currently do not consistently format critical metadata +# like time-zone-aware timestamps** when events of data collection or +# processing happened. +# +# We would like to encourage the community and especially the vendors +# to work towards a standardization, or at least an open documentation +# of the way how time-zone-aware time data are collected and stored how +# and where during a microscope session and how they end up in files +# and databases with which users interact. +# This would enable to supplement instances of this schema with specific +# time data and assure that these time data can be used to reliably +# contextualize individual datasets and processing steps in materials +# information systems. +# +# For the reason that these measures have not yet been fully taken, +# the start_time and end_time is a recommended option. +# The idea behind these time-zone-aware dates is to identify when +# the data were collected at the microscope but NOT when they were +# transcoded by some software tool(s) while storing the data in an +# instance of this schema. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Annulus inner half angle +# +# +# +# +# Annulus outer half angle +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXem_ebsd.yaml b/contributed_definitions/nyaml/NXem_ebsd.yaml new file mode 100644 index 0000000000..f2636ed87e --- /dev/null +++ b/contributed_definitions/nyaml/NXem_ebsd.yaml @@ -0,0 +1,3684 @@ +category: application + +# what to do when multiple pattern are averaged into one before the beam moves further? +doc: | + Application definition for collecting and indexing Kikuchi pattern into orientation maps. + + This NXem_ebsd application is a proposal how to represent data, metadata, and + connections between these for the research field of electron microscopy. + More specifically, exemplified here for electron backscatter diffraction (EBSD). + The application definition solves two key documentation issues which are missing + so far to document provenance of data and metadata in the field of EBSD. + The application definition can be an example that is relevant for related + workflows in orientation microscopy. + + Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted + according to the NXem_ebsd application definition) stores the connection between + the microscope session and the key datasets which are considered typically results + of the various processing steps involved when working with EBSD data. + + Different groups in this application definition make connections to data artifacts + which were collected when working with electron microscopes via the NXem partner + application definition. Using a file which stores information according to the + NXem application definition has the benefit that it connects the sample, references + to the sample processing, the user operating the microscope, details about the + microscope session, and details about the acquistion and eventual indexing of + Kikuchi pattern, associated overview images, like secondary electron or + backscattered electron images of the region-of-interest probed and many + more pieces of information. + + Secondly, this NXem_ebsd application definition connects and stores the conventions + and reference frames which were used and are the key to mathematically correctly + interpret every EBSD result. Otherwise, results would be ripped out of their + context, as it is the situation with many traditional studies where EBSD data were + indexed on-the-fly and shared with the community only via sharing the results file + with some technology-partner-specific file but leaving important conventions out + or relying on the assumptions that colleagues know these even though multiple + definitions are possible. + + This application definition covers experiments with one-, two-dimensional, and + so-called three-dimensional EBSD datasets. The third dimension is either time + (in the case of quasi in-situ experiments) or space (in the case of serial- + sectioning) methods where a combination of mechanical or ion milling is used + repetitively to measure the same region-of-interest at different depth increments. + Material removal can be achieved with electron or ion polishing, using manual + steps or using automated equipment like a robot system. + + Three-dimensional experiments require to follow a sequence of specimen, surface + preparation, and data collection steps. By nature these methods are destructive + in that they either require the removal of the previously measured material region + or that the sample surface can degrade due to e.g. contamination or other + electron-matter interaction. + + For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are + combined into one reconstructed stack. That is serial-sectioning is mainly a + computational workflow. Users collect data for each serial sectioning step + via an experiment. This assures that data for associated microscope sessions + and steps of data processing stay connected and contextualized. + + Eventual tomography methods also use such a workflow because first diffraction + images are collected (e.g. with X-ray) and then these imagres are indexed and + computed into a 3D orientation mapping. The here proposed NXem_ebsd application + definition contains conceptual ideas how this splitting between measurement and + post-processing can be granularized also for such X-ray-based techniques, whether + it be 3DXRD or HEDM. +symbols: + n_op: | + Number of arguments per orientation for given parameterization. + n_sc: | + Number of scan points. + n_z: | + Number of pixel along the slowest changing dimension for a rediscretized, i.e. + standardized default orientation mapping. + n_y: | + Number of pixel along slow changing dimension for a rediscretized i.e. + standardized default orientation mapping. + n_x: | + Number of pixel along fast changing dimension for a rediscretized i.e. + standardized default orientation mapping. + +# The respective partner application definition NXxray_fourd +# can be used for storing data and post-processing results of X-ray diffraction +# experiments which can yield also orientation maps in one, two- or three-dimensions. +# These complementary techniques and associated application definitions can be used +# to inform NXms, another partner application definition to NXem_ebsd. NXms describes +# the connection between measured or simulated structural features with a focus of +# the length and time-scale coarser then the atomic scale. The term microstructure +# is used here but is not restricted to features at the micron scale. + +# the IUCr DMI should work on an e.g. NXhedm +# NXem_tkd is not needed as it can be covered by NXem_ebsd as well. +# if we think of the metadata/data graph collected from the microscope session +# documented in NXem there may be only a few relations between nodes of an instance +# of NXem_ebsd and NXem. Key data from NXem which many users would expect to find +# also enumerated in NXem_ebsd could be settings of the microscope, timestamp data +# when tasks were performed at the microscope using which specimen, operated +# and prepared by whom. These latter pieces of information are all available +# in NXem but if we were to make fields in NXem deep inside an instance +# of NXem_event_data required than we factually more and more granularize and +# pull in steps of detailed numerical post-processing which arguably is not +# any longer at all necessarily related to the microscope session. +# We know many cases in EBSD community, see the work of e.g. Marc de Graef's group +# or of Hakon Wiik Anes and Knut Marthinsen who spent much longer with a collected +# dataset in post-processing than collecting it at the microscope. Therefore, we +# need to have the flexibility that documentation of the actual microscope session +# and the post-processing of some of the data therein collected remain coupled +# but not too repetively and with too stiff constraints on the existence of specific +# fields as otherwise there can be contradictions for which NXem_ebsd would no longer +# be applicable when one wishes to remain at the same time conformant with the data +# scheme. +# The idea used here is to use a reference to another NeXus file in the NXem_ebsd +# file instance and the NXem file instance. So far we acknowledge that exporting +# data as an NXem application definition is limited and scientists currently have +# specific file formats from commercial or open-source tools to work with. +# Therefore, we so far model the connections between the application definitions +# as NXprocesses. As soon as NXem is more supported these NXclasses should become +# NXem e.g. though. +# Details about scan positions should not be reproduced unless needed for +# interpolating between results of neighboring scan positions. +# Currently, we suggest to leave the scan positions as closely to where they are +# collected, i.e. inside NXem. +# What this exampe of linking information rather than duplicating shows is that +# somewhat a culture change is needed: Instead of packing everything in one file +# we just need to assure that we have a tool whereby we can follow and inspect a +# set of linked objects if you would like to say so, also having multiple files +# is okay. +# Finally, this application definition makes any assumptions about +# gridding, this enables to handle all sort of scan schemes. +# We follow the argumentation of MTex, in certain cases data will not yield +# fully occupied grids anyway. +# NXem_ebsd could also be useful/used for storing generic simulations of EBSD pattern +# which is one example for simulations of diffractions patterns as they may be observed +# with electron microscopes. In this case, there should be simulation(NXprocess) under this +# the simulation group where one can store the minimum required set of pieces of information +# which comes with every diffraction pattern simulation. +# The main problem is in this case that the simulation group is required but then there must +# either be no measurement group and on_the_fly_indexing group, and eventually calibration ? +# or these groups should be created but remain empty. +# Using the current NeXus appdef design and rules for setting constraints demands that then the +# same appdef should be used for post-processing measured data. So there is a conflict: +# The simulation must not be required and measurement must not be optional. +# Arguably one may call for two application definitions in this case but most constraints and +# concepts would then match those of NXem_ebsd which works again standardization and +# reducing the total number of ontologies. +type: group +NXem_ebsd(NXobject): + (NXentry): + exists: ['min', '1', 'max', 'unbounded'] + \@version: + doc: | + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + # NEW ISSUE: FILE or ARTIFACT? + # enumeration: [sha_256_hash] + definition: + doc: | + NeXus NXDL schema to which this file conforms. + enumeration: [NXem_ebsd] + workflow_identifier: + doc: | + Ideally, a (globally) unique persistent identifier + for referring to this workflow. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + workflows/experiments to e.g. proposals. + workflow_description: + exists: optional + doc: | + Free-text description about the workflow. + + Users are strongly advised to detail the sample history in the respective + field and fill rather as completely as possible the fields of the application + definition behind instead of filling in these details into the experiment_description + free-text description field. + start_time(NX_DATE_TIME): + exists: recommended + doc: | + ISO 8601 time code with local time zone offset to UTC information + included when the processing of the workflow started. + If the application demands that time codes in this section of the + application definition should only be used for specifying when the + workflow was executed - and the exact duration is not relevant + - this start_time field should be used. + + Often though it is useful to specify a time interval with specifying + both start_time and end_time to allow for more detailed bookkeeping + and interpretation of the workflow. + end_time(NX_DATE_TIME): + exists: recommended + doc: | + ISO 8601 time code with local time zone offset to UTC included + when the processing of the workflow ended. + (NXprogram): + exists: ['min', '1', 'max', 'unbounded'] + doc: | + Program which was used for creating the file instance which is + formatted according to the NXem_ebsd application definition. + program: + \@version: + (NXuser): + exists: ['min', '0', 'max', 'unbounded'] + doc: | + Contact information and eventually details of at least one person + involved in performing the workflow. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is + recommended. + 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. + + # rotation and reference frame conventions + # we assume that the conventions are the same across all experiments and/or + # simulations which this application definition captures + conventions(NXem_ebsd_conventions): + rotation_conventions(NXprocess): + three_dimensional_rotation_handedness: + rotation_convention: + euler_angle_convention: + axis_angle_convention: + orientation_parameterization_sign_convention: + processing_reference_frame(NXprocess): + reference_frame_type: + xaxis_direction: + xaxis_alias: + yaxis_direction: + yaxis_alias: + zaxis_direction: + zaxis_alias: + origin: + sample_reference_frame(NXprocess): + reference_frame_type: + xaxis_direction: + yaxis_direction: + zaxis_direction: + origin: + detector_reference_frame(NXprocess): + reference_frame_type: + xaxis_direction: + yaxis_direction: + zaxis_direction: + origin: + gnomonic_projection_reference_frame(NXprocess): + reference_frame_type: + xaxis_direction: + yaxis_direction: + zaxis_direction: + origin: + pattern_centre(NXprocess): + xaxis_boundary_convention: + xaxis_normalization_direction: + yaxis_boundary_convention: + yaxis_normalization_direction: + + # either we have simulated data or we have a set of measured data + # in every case data are Kikuchi diffraction pattern and their metadata + simulation(NXprocess): + exists: recommended + doc: | + Details about simulations for Kikuchi pattern using kinematic or dynamic + diffraction theory. Usually, the output of such computer simulations are + spherical Kikuchi images which only when projected or observed in some + region-of-interest will represent a set of rectangular Kikuchi pattern + with the same rectangular shape and image size. + + Therefore, these pattern should be stored. The spherical diffraction + pattern can be stored as a set of triangulated geodesic meshes. + The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. + + Do not store pattern in the simulation group if they + have been measured are not simulated. + sequence_index(NX_POSINT): + (NXprogram): + exists: ['min', '0', 'max', 'unbounded'] + program: + \@version: + (NXcg_geodesic_mesh): + exists: ['min', '0', 'max', 'unbounded'] + (NXimage_set_em_kikuchi): + stack(NXdata): + \@signal: + \@axes: + \@AXISNAME_indices: + + # \@long_name: + title: + data_counts(NX_NUMBER): + \@long_name: + + # dimensions: + # rank: 3 + # dim: [[1, n_p], [2, n_y], [3, n_x]] + pattern_identifier(NX_UINT): + \@long_name: + + # dimensions: + # rank: 1 + # dim: [[1, n_p]] + axis_y(NX_NUMBER): + \@long_name: + + # dimensions: + # rank: 1 + # dim: [[1, n_y]] + axis_x(NX_NUMBER): + \@long_name: + + # dimensions: + # rank: 1 + # dim: [[1, n_x]] + experiment(NXprocess): + exists: ['min', '0', 'max', 'unbounded'] + doc: | + The experiment group captures relevant details about the conditions of + and the tools used for collecting the Kikuchi diffraction pattern. + + The most frequently collected EBSD data are captured as rectangular ROIs + composed from square or hexagonally-shaped pixels. Substantially less + frequently, because such experiments are more costly and technically + demanding, correlated experiments are performed. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. Here the same or nearly the same ROI is + analyzed via a cycles of thermomechanical treatment, sample preparation, + measurement, on-the-fly-indexing. Phenomena investigated like this are + recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is repetitively measured + and polished to create a stack of orientation data which can be reconstructed + to a three-dimensional volume ROI. + time(NX_NUMBER): + unit: NX_TIME + exists: optional + doc: | + Physical time since the beginning of a timestamp that is required to be + same for all experiments in the set. The purpose of this marker is + to identify how all experiments in the set have have to be arranged + sequentially based on the time elapsed. + The time is relevant to sort e.g. experiments of consecutive quasi + in-situ experiments where a measurement was e.g. taken after 0 minutes + of annealing, 30 minutes, 6 hours, or 24 hours of annealing. + (NXtransformations): + exists: optional + doc: | + Transformation which details where the region-of-interest described under + indexing is located in absolute coordinates and rotation with respect + to which coordinate system. + calibration(NXprocess): + exists: recommended + + # although one could simulate spherical Kikuchi pattern without modeling the detector system + doc: | + The EBSD system, including components like the electron gun, pole-piece, + stage tilting, EBSD detector, and the gnomonic projection have to be + calibrated to achieve reliable results. Specifically, the gnomonic projection + has to be calibrated. + + In most practical cases, especially in engineering, there is a substantially + larger number of sessions where such a calibrated system is used assuming + that somebody has properly calibrated the system rather than that the user + actively recalibrates it or is even allowed to do so. + Especially the projection geometry has to calibrated which is usually + achieved with measuring silicon, quartz or standards, and comparing + against simulated diffraction pattern. + + In the first case, the user assumes that the principle geometry of the + hardware components and the settings in the control and EBSD pattern + acquisition software are calibrated. Consequently, users pick from an + existent library of phase candidates. One example are the CRY or CIF + files of the classical HKL/Channel 5/Flamenco software products. + Each entry of the library of such phase candidates in this NeXus proposal + is represented by one NXem_ebsd_crystal_structure_model base class. + For each phase an instance of this base class is to be used to store + crystallographic and simulation-relevant data. + + Indexing is a data processing step performed after/during the beam scans + the specimen (depends on configuration). Users load the specimen, and first + collect a coarse image of the surface. Next, an approximate value for the + calibrated working distance is chosen and the stage tilted. + Users then may configure the microscope for collecting higher quality data + and push in the EBSD detector. Subsequently, they fine tune the illumination + and aberration settings and select one or multiple ROIs to machine off. + The on-the-fly indexing parameter are defined and usually the automated + measurement queue started. + + Nowadays, this is usually an automated/unsupervised process. The pattern + collection runs during the allocated session time slot which the user has + booked ends or when the queue finishes prematurely. Kikuchi pattern surplus + eventually multi-modal detector signals are collected and usually indexed + on-the-fly. The Kikuchi patterns may or not be deleted directly after a + solution was found (on-the-fly) so Kikuchi pattern are not always stored. + + Results files are in many labs afterwards copied automatically + for archival purposes to certain storage locations. The result of such an + EBSD measurement/experiment is a set of usually proprietary or open files + from technology partners (microscope and EBSD detector manufacturers). + + In the second case, the system is being calibrated during the session + using standards (silicon, quartz, or other common specimens). + There is usually one person in each lab responsible for doing such + calibrations. Important is that often this person or technician(s) are also + in charge of configuring the graphical user interface and software + with which most users control and perform their analyses. + For EBSD this has key implications because, taking TSL OIM/EDAX as an example, + the conventions how orientations are stored is affected by how reference frames + are set up and this setup is made at the level of the GUI software. + Unfortunately, these pieces of information are not necessarily stored + in the results files. In effect, key conventions become disconnected + from the data so it remains the users personal obligation to remember these + settings, write them down in the lab notebook, or these metadata get lost. + All these issues are a motivation and problem which NXem_ebsd solves. + sequence_index(NX_POSINT): + origin: + doc: | + A link/cross reference to an existent instance of NXem_ebsd with ideally + an associated instance of NXem detailed under measurement which informs + about the calibration procedures. + \@version: + doc: | + Commit identifying this resource. + path: + doc: | + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to the EBSD data (post)-processing workflow + when performing the calibration. + acquisition(NXprocess): + exists: recommended + + # data come from e.g. a Kikuchi pattern simulation! + doc: | + Relevant result of the session at the microscope for this experiment + which enables to connect the measurement of the Kikuchi pattern and + their processing into orientation microscopy maps. + sequence_index(NX_POSINT): + origin: + doc: | + Name or link to an existent instance of an EBSD raw dataset ideally + as an instance of an NXem application definition which has at least + one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. + The path to this instance in the origin has to be specified under path. + + When NXem is not used or the aim is to rather explore first how + community-specific files with EBSD data, such as ANG, CPR, or HDF5- + based formats can be parsed from, inject here the name of that file. + + The em_om parser will currently not interpret the majority of the + many system- and technique-specific metadata which come with the + files from e.g. technology partners. This is because the current + culture in the EBSD community is that many of the metadata fields + are neither in all cases fully documented nor use a standardized + vocabulary although many people understand terms from different + implementations and how these metadata can likely be compared to + one another. + + In addition, it is common practice in the research field of EBSD that + users transcode their raw data into other (often text-based or HDF5) + files with custom formatting to realize an information transfer + between specific software tools including commercial software from + technology partner, custom scripts in Matlab using tools like MTex, + or Python scripting with tools like hyperspy, pyxem, orix, diffsims, + kikuchipy, or EBSD data stack alignment tools like DREAM.3D. + We have opted that in the first iteration this implementation of a + RDMS-agnostic FAIR data schema for EBSD that we discard these metadata + because these ad hoc file formats are not designed to communicate + also specifically and most importantly the eventually different context + of the metadata. + Another reason for this choice was also to emphasize that in fact such + challenges do exist in the community and thus pointing them out may + support the discussion to arrive at eventually more complete solutions. + As developing these solutions should not be our authority and necessarily + demands feedback from the technology partners, we have opted for this + intermediate approach to stimulate discussion. + \@version: + doc: | + Commit or e.g. at least SHA256 checksum identifying this resource. + path: + doc: | + Path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow. + + # base class for indexing methods with relevant vocabulary + indexing(NXprocess): + exists: recommended + + # IPF default plots in this case we need to use simulated Kikuchi pattern as a fallback + doc: | + OIM, orientation imaging microscopy. Post-processing of the Kikuchi + patterns to obtain orientation per phase model and scan point. + Fundamentally different algorithms can be used to index EBSD/EBSP pattern. + + Common is that pattern indexing is a computational step of comparing + simulated with measured diffraction pattern. Quality descriptors are defined + based on which an indexing algorithm yields a quantitative measure of + how similar measured and assumed/simulated pattern are, and thus if + no, one, or multiple so-called solutions were found. + + Assumed or simulated pattern use kinematical or dynamical electron + diffraction theory. Hough transform (which is essentially a discretized + Radon transform, for details see e.g A short introduction to the Radon + and Hough transforms and how they relate by M. van Ginkel et al.). + Recently, dictionary-based indexing methods are increasingly becoming used + partly driven by the move to use artificial intelligence algorithms. + + An inspection of publicly available EBSD datasets with an open-source + license which are available on Zenodo was performed prior to implementing + of the associated em_om parser for NXem_ebsd. This analysis revealed that + EBSD data are in most cases stored in two ways: Case one was via a file in + formats from technology partners. Examples are binary formats like OSC, + H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, + CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. + + These files contain some result and metadata to the numerical steps and the + computational workflow which was performed to index Kikuchi pattern + on-the-fly. Examples of metadata include scan point positions, indexing + solutions per scan point, some quality descriptors for the solutions, + as well as crystal structure and phase metadata. + + Case two were raw pattern in some custom format, often text-based with + some but in general no conclusive and interoperable representation of all + relevant metadata. + Often it remains unclear what individual fields and data arrays of these + fields resolve and/or mean conceptually. For some fields, publications were + referred to. However, software tools change over time and thus which specific + data end in a file and which specific conceptual information is behind + these data can change with software versions. + + Other cases were storing results of custom post-processing steps and + associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry + resolving methods, i.e. any sort of prototyping or alternative indexing + strategies so far seem to require some flexibility for implementing + rapid prototypic capabilities. The drawback of this is that such results + come formatted on a case-by-case basis and are thus not interoperable. + + Therefore, we first need to collect how these files have been generated + and which metadata in these files (or database entries) represent + which pieces of information conceptually. Ideally, one would do so by + creating a complete set of information in e.g. an NXem application definition, + such as a log of timestamped events and processing steps, metadata and data. + Eventually even interactions with the graphical user interface of commercial + software during the microscope session should be stored and become a + part of the application definition. + + Such a set of pieces of information could then be used via reading directly + for the NXem application definition. However, in most cases such a data + representation is not available yet. + sequence_index(NX_POSINT): + on_the_fly_indexing(NXprocess): + exists: optional + doc: | + Therefore, the on_the_fly_indexing group stores which source_file contains + the results of the on-the-fly indexing. For commercial systems these files + can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or + database entry which is referred to under origin is the same as the one + under a given acquisition/origin in one of the experiment groups. + This is because some commercial file formats make no clear distinction + between which metadata are acquisition and/or indexing metadata. + (NXprogram): + exists: ['min', '1', 'max', 'unbounded'] + doc: | + Commercial program which was used to index the EBSD data + incrementally after they have been captured and while the + microscope was capturing (on-the-fly). This is the usual + production workflow how EBSD data are collected in + materials engineering, in industry, and academia. + program: + \@version: + origin: + doc: | + Name of the file from which data relevant for creating default plots + were taken in the case that the data in the experiment group were + indexed on-the-fly. + \@version: + doc: | + Hash of that file. + path: + doc: | + TBD, path which resolves which specific NXimage_set_em_kikuchi instance + was used as the raw data to this EBSD data (post)-processing workflow + when performing the calibration. + method: + doc: | + Principal algorithm used for indexing. + enumeration: [undefined, hough_transform, dictionary, radon_transform, other] + background_correction(NXprocess): + exists: optional + doc: | + Details about the background correction applied to each Kikuchi pattern. + sequence_index(NX_POSINT): + + # for each process the program used + # auto_background_correction: + # static_or_dynamic: + # pattern_averaging(NXprocess): + # doc: | + # Details about how patterns of each scan point are average or how + # pattern from scan points and neighboring scan points are spatially + # averaged (using weighting schemes and e.g. kernels) before these + # patterns are passed to the indexing algorithm. + binning(NXprocess): + exists: optional + doc: | + Binning i.e. downsampling of the pattern. + sequence_index(NX_POSINT): + + # for each process the program used + # mode: + # doc: Free-text description for instrument specific settings + # binning(NX_UINT): ##MK equivalent to pattern height and width? + # doc: | + # How is the camera signal binned. + # First the number of pixel along the slow direction. + # Second the number of pixel along the fast direction. + # unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, 2]] + parameter(NXprocess): + exists: optional + doc: | + Specific parameter relevant only for certain algorithms used + sequence_index(NX_POSINT): + + # mode: + # doc: Which method used to index pattern? + # enumeration: [optimize_bd] # what does optimize_bd mean Oxford? + (NXem_ebsd_crystal_structure_model): + exists: ['min', '1', 'max', 'unbounded'] + crystallographic_database_identifier: + exists: recommended + crystallographic_database: + exists: recommended + unit_cell_abc(NX_FLOAT): + unit_cell_alphabetagamma(NX_FLOAT): + space_group: + exists: recommended + phase_identifier(NX_UINT): + phase_name: + exists: recommended + atom_identifier: + exists: recommended + atom(NX_UINT): + exists: recommended + atom_positions(NX_FLOAT): + exists: recommended + atom_occupancy(NX_FLOAT): + exists: recommended + number_of_planes(NX_UINT): + exists: recommended + plane_miller(NX_NUMBER): + exists: recommended + dspacing(NX_FLOAT): + exists: recommended + relative_intensity(NX_FLOAT): + exists: recommended + + # connection to data collected using kinematic or + # NEW ISSUE: dynamic diffraction theory simulations + + # individual mappings + # (scientists in EBSD consult all sorts of mappings) + # like image_quality map, orientation mapping, ipf mapping, grain mapping + # etc. in fact these could be all the possible mappings which one can + # create with the famous commercial software solutions + # the problem a RDMS cannot understand these mappings unless they + # are standardized in the sense, one has an exchange format whereby + # these mappings can be exported/transcoded from their representation + # in the commercial software, e.g. + # keep in mind, everybody uses the TSL OIM or Bruker AZTec OIM mapping + # but even these two are not directly interoperable, which is why + # they are also not interoperable in some RDMS if one does not come + # up with a way how to go about standardizing their description + # summary(NXdata): + # doc: | + + # data(NX_UINT): + # doc: | + # Status value of each pixel of the orientation mapping. + status(NX_UINT): + exists: optional + unit: NX_UNITLESS + doc: | + Which return value did the indexing algorithm yield for each scan point. + Practically useful is to use an uint8 mask. + + * 0 - Not analyzed + * 1 - Too high angular deviation + * 2 - No solution + * 100 - Success + * 255 - Unexpected errors + dimensions: + rank: 1 + dim: [[1, n_sc]] + + # axis_y(NX_NUMBER): + # doc: | + # Coordinate along the slow direction. + # axis_x(NX_NUMBER): + # doc: | + # Coordinate along the fast direction. + n_phases_per_scan_point(NX_UINT): + exists: recommended + unit: NX_UNITLESS + doc: | + How many phases i.e. crystal structure models were used to index each + scan point if any? Let's assume an example to explain how this field + should be used: In the simplest case users collected one pattern for + each scan point and have indexed using one phase, i.e. one instance + of an NXem_ebsd_crystal_structure_model. + + In another example users may have skipped some scan points (not indexed) + them at all) and/or used differing numbers of phases for different scan + points. + + The cumulated of this array decodes how phase_identifier and phase_matching + arrays have to be interpreted. In the simplest case (one pattern per scan + point, and all scan points indexed using that same single phase model), + phase_identifier has as many entries as scan points + and phase_matching has also as many entries as scan points. + dimensions: + rank: 1 + dim: [[1, n_sc]] + phase_identifier(NX_UINT): + exists: recommended + unit: NX_UNITLESS + doc: | + The array n_phases_per_scan_point details how the phase_identifier + and the phase_matching arrays have to be interpreted. + + For the example with a single phase phase_identifier has trivial + values either 0 (no solution) or 1 (solution matching + sufficiently significant with the model for phase 1). + + When there are multiple phases, it is possible (although not frequently + needed) that a pattern matches eventually (not equally well) sufficiently + significant with multiple pattern. This can especially happen in cases of + pseudosymmetry and more frequently with an improperly calibrated system + or false or inaccurate phase models e.g. (ferrite, austenite). + Having such field is especially relevant for recent machine learning + or dictionary based indexing schemes because in combination with + phase_matching these fields communicate the results in a model-agnostic + way. + + Depending on the n_phases_per_scan_point value phase_identifier and + phase_matching arrays represent a collection of concatenated tuples, + which are organized in sequence: The solutions for the 0-th scan point, + the 1-th scan point, the n_sc - 1 th scan point and omitting tuples + for those scan points with no phases according to n_phases_per_scan_point + dimensions: + rank: 1 + dim: [[1, i]] + phase_matching(NX_NUMBER): + exists: recommended + unit: NX_UNITLESS + doc: | + One-dimensional array, pattern by pattern labelling the solutions found. + The array n_phases_per_scan_point has to be specified because it details + how the phase_identifier and the phase_matching arrays have to be interpreted. + See documentation of phase_identifier for further details. + dimensions: + rank: 1 + dim: [[1, i]] + phase_matching_descriptor: + exists: recommended + doc: | + Phase_matching is a descriptor for how well the solution matches or not. + Examples can be confidence index (ci), mean angular deviation (mad), + some AI-based matching probability (other), i.e. the details are implementation-specific. + enumeration: [undefined, ci, mad, other] + orientation_parameterization: + exists: recommended + doc: | + How are orientations parameterized? Inspect euler_angle_convention + in case of using euler to clarify the sequence of rotations assumed. + enumeration: [euler, axis_angle, rodrigues, quaternion, homochoric] + orientation(NX_NUMBER): + exists: recommended + unit: NX_ANY + doc: | + Matrix of parameterized orientations identified. The slow dimension + iterates of the individual solutions as defined by n_phases_per_scan_point. + Values for phases without a solution should be correctly identified as + IEEE NaN. + dimensions: + rank: 2 + dim: [[1, i], [2, n_op]] + scan_point_positions(NX_NUMBER): + exists: recommended + unit: NX_LENGTH + + # we make this only required as people may not yet be so happy with + # having to walk a graph from measurement -> path -> NXevent_data_em + # -> em_lab/ebeam_deflector to retrieve the actual scan positions + # although this would be much cleaner + doc: | + Matrix of calibrated centre positions of each scan point + in the sample surface reference system. + dimensions: + rank: 2 + dim: [[1, n_sc], [2, 2]] + + # EW ISSUE: this is in fact a duplicate because if we know th + # path to the measurement we would have available all ebeam_deflector + # settings and thus could identify where the beam was scanning for each + # NXevent_data_em instance, we have even more + + # NEW ISSUE: replace by a more generic pivot table + hit_rate(NX_NUMBER): + exists: optional + unit: NX_DIMENSIONLESS + doc: | + Fraction of successfully indexed pattern + of the set averaged over entire set. + + # candidate for default plot + region_of_interest(NXprocess): + exists: ['min', '1', 'max', '1'] + doc: | + An overview of the entire area which was scanned. + For details about what defines the image contrast + inspect descriptor. + descriptor: + doc: | + Descriptor representing the image contrast. + + # taking two examples (CTF and H5OINA choked completely of possibility to find s.th. conceptually common to plot + enumeration: [normalized_band_contrast, normalized_confidence_index] + roi(NXdata): + doc: | + Container holding a default plot of the region on the sample + investigated with EBSD. + + # \@signal: # data + # \@axes: # [axis_y, axis_x] + # \@axis_x_indices: # 0 + # \@axis_y_indices: # 1 + \@signal: + \@axes: + \@AXISNAME_indices: + + # \@long_name: + title: + data(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Descriptor values displaying the ROI. + dimensions: + rank: 2 + dim: [[1, n_y], [2, n_x]] + + # n_0 slow 2, n_1 fast 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: | + Signal + axis_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated center of mass of the pixel along the slow axis. + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + doc: | + Label for the y axis + axis_x(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated center of mass of the pixel along the fast axis. + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: + doc: | + Label for the x axis + (NXprocess): + exists: ['min', '0', 'max', 'unbounded'] + doc: | + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + + The IPF mapping is interpolated from the scan point data mapping + onto a rectangular domain with square pixels and the + orientations colored according to the coloring scheme used in the + respective ipf_color_modelID/program. + + The main purpose of the ipf_mapID group is not to keep raw data or + scan point related data but offer a default way how a research data + management system can display a preview of the dataset so that users + working with the RDMS can get an overview of the dataset. + + This matches the first aim of NXem_ebsd which is foremost to bring + colleagues and users of EBSD together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging + data from EBSD between different tools and research data management + systems (RDMS). + + With this design the individual RDMS solutions and tools can still continue + to support specific custom data analyses workflow and routes but at least + there is then one common notation of understanding whereby also users + not necessarily expert in all the details of the EBSD story can understand + better these data and thus eventually this can motivate data reuse and + repurposing. + + It is important to mention that we cannot assume, at least for now, + that the parser which writes to an NXem_ebsd-compliant file is also + responsible or capable at all of computing the inverse pole figure + color keys and maps itself. This cannot be assumed working because + this mapping of orientation data uses involved mathematical algorithms + and functions which not every tools used in the EBSD community is capable + of using or is for sure not using in exactly the same way. + + Currently, we assume it is the responsibilty of the tool used which + generated the data under on_the_fly_indexing to compute these + plots and deliver these to the parser. + + Specific case studies have been explored by the experiment team of + Area B of the FAIRmat project to realize and implement such mapping. + + The first case study uses the H5OINA format and the pyxem/orix library. + As orix is a Python library, the coloring is performed by the em_om parser. + + The second case study uses MTex and its EBSD color coding model. + As MTex is a Matlab tool, an intermediate format is written from MTex + first which stores these pieces of information. The parser then pulls + these data from the intermediate Matlab-agnostic representation and + supplements the file with missing pieces of information as it is + required by NXem_ebsd. + + The third case study shows how a generic set of Kikuchi pattern + can be loaded with the em_om parser. The pattern are loaded directly + from a ZIP file and mapped to an simulation image section for now. + + The fourth case study uses the DREAM.3D package which provides an own + set of EBSD data post-processing procedures. DREAM.3D documents the + processing steps with a pipeline file which is stored inside DREAM.3D + output files. In this case study, the parser reads the DREAM.3D file + and maps data relevant from the perspective of NXem_ebsd plus adds + relevant IPF color maps as they were computed by DREAM.3D. + Given that in this case the origin of the data is the DREAM.3D file + again provenance is kept and more details can be followed upon when + resolving origin. + + These examples offer a first set of suggestions on how to make EBSD + data injectable into research data management system using schemes + which themselves are agnostic to the specific RDMS and interoperable. + Steps of collecting the raw data and post-processing these with custom + scripts like MTex or commercial tools so far are mainly undocumented. + The limitation is that a program which consumes results or dump files + from these tools may not have necessarily all the sufficient information + available to check if the injected orientation data and color models + are matching the conventions which a user or automated system has + injected into an electronic lab notebook from which currently the em_om + parser collects the conventions and stores them into this NXem_ebsd instance. + The immediate benefit of the here presented NXem_ebsd concept though + is that the conventions and reference frame definitions are expected + in an ELN-agnostic representation to make NXem_ebsd a generally useful + data scheme for EBSD. + + Ideally, the em_om parser would load convention-compliant EBSD data + and use subsequently a community library to transcode/convert orientation + conventions and parameterized orientation values. Thereafter, convention- + compliant default plot(s) could be created that would be truely interoperable. + + However, given the variety of post-processing tools available surplus + the fact that these are not usually executed along standardized + post-processing workflows which perform exactly the same algorithmic steps, + this is currently not a practically implementable option. Indeed, first + developers who wish to implement this would first have to create a library + for performing such tasks, mapping generally between conventions, + i.e. map and rotate coordinate systems at the parser level. + + The unfortunate situation in EBSD is that due to historical reasons + and competitive strategies, different players in the field have + implemented (slightly) different approaches each of which misses + some part of a complete workflow description which is behind EBSD analyses: + Sample preparation, measurement, indexing, post-processing, paper... + + The here exemplified default plot do not so far apply relevant rotations + but takes the orientation values as they come from the origin and using + coloring them as they come. It is thus the scientists responsibility to + enter and check if the respective dataset is rotation-conventions-wise + consistent and fit for a particular task. + + Ideally, with all conventions defined it can be possible to develop + a converter which rotates the input data. This application definition + does not assume this and users should be aware of this limitation. + + The key point is that the conventions however are captured and this is + the most important step to the development of such a generic transcoder + for creating interoperable EBSD datasets. + + Currently the conventions remain in the mind or manual lab book of the + respective scientists or technicians instead of getting stored and + communicated with research papers that are written based on + specific dataset, i.e. database entries. + + The default gridded representation of the data should not be + misinterpreted as the only possible way how EBSD data and OIM + maps can be created! + + Indeed, the most general case is that patterns are collected for + scan points. The scan generator of an electron microscope is instructed + to steer the beam in such a way across the specimen surface that the + beam illuminates certain positions for a certain amount time (usually + equally-spaced and spending about the same amount of time at each + position). + + Therefore, scan positions can be due to such regular flight plans and + represent sampling on lines, line stacks, rectangular regions-of- + interests, but also could instruct spiral, random, or adaptive scans + instead of tessellations with square or hexagonal pixels. + + The majority of EBSD maps is though is reporting results for a regular + grid (square, hexagon). What matters though in terms of damage induced + by the electron beam and signal quality is the real electron dose + history, i.e. for how long the beam exposed which location of the + specimen. Especially when electron charging occurs (i.e. an excess + amount of charge accumulates due to e.g. poor conducting away of this + charge or an improper mounting, too high dose, etc. such details are + relevant. + + Specifically, the default visualization is an inverse pole-figure (IPF) + map with the usual RGB color coding. Different strategies and + normalization schemes are in use to define such color coding. + + Finally, we should mention that each ipf_map represents data for + scan points indexed as one phase. The alias/name of this phase should + be stored in phase_name, the phase_identifier give an ID which must + not be zero as this value is reserved for non-indexed / null model scan + points. + phase_identifier(NX_UINT): + unit: NX_UNITLESS + doc: | + Specifying which phase this IPF mapping visualizes. + phase_name: + doc: | + Alias/name for the phase whose indexed scan points are displayed. + description: + exists: optional + doc: | + Which IPF definition computation according to backend. + + # AS THE FIRST STEP WE DO NOT IMPLEMENT A GENERIC ORIENTATION AND REFERENCE + # FRAME LIBRARY WHICH CAN TRANSLATE BETWEEN ALL POSSIBLE CONVENTIONS. + # INSTEAD WE TAKE THE RESULTS COMPUTED FROM THE BACKEND THAT IS + # For cpr/crc/ang the pythonEBSD backend + # For other file either MTex or kikuchipy + # For DREAM.3D this is DREAM.3D + # For pyxem following the orix library (which has some, though not yet in + # all details checked links and usage of the orix library because kikuchipy + # is somehow connected to pyxem. NEED TO TALK TO DEVELOPERS HERE! + + # NEW ISSUE: [0, 0, 1] is defined in which coordinate system? + projection_direction(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Along which axis to project? Typically [0, 0, 1] is chosen. + dimensions: + rank: 1 + dim: [[1, 3]] + bitdepth(NX_UINT): + unit: NX_UNITLESS + doc: | + Bitdepth used for the RGB color model. Usually 8 bit. + + # can an NX_UINT have an enumeration? + (NXprogram): + exists: ['min', '1', 'max', 'unbounded'] + doc: | + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + program: + \@version: + + # enumeration: [brinckmann, mtex, kikuchipy, dream3d, orix, tsl] + ipf_rgb_map(NXdata): + doc: | + The RGB image which represents the IPF map. + + # \@signal: # rgb + # \@axes: # [zpos, ypos, xpos] # rgb + # \@rgb_indices: 0 + # \@axis_x_indices: 0 + # \@axis_y_indices: 1 + # \@zpos_indices: 2 + \@signal: + \@axes: + \@AXISNAME_indices: + + # \@long_name: + title: + data(NX_UINT): + unit: NX_UNITLESS + doc: | + RGB array, with resolution per fastest changing value + defined by bitdepth. + dimensions: + rank: 3 + dim: [[1, n_y], [2, n_x], [3, 3]] + + # n_p_or_z slow 3, n_y fast 2, n_x faster 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: | + IPF color-coded orientation mapping + axis_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated center of mass of the pixel along the slow axis. + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + doc: | + Label for the y axis + + # but for h5web RGB we need n_y + 1, was an issue in v6.6.1 + axis_x(NX_NUMBER): + doc: | + Calibrated center of mass of the pixel along the fast axis. + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: + doc: | + Label for the x axis + ipf_rgb_color_model(NXdata): + doc: | + For each stereographic standard triangle (SST), i.e. a rendering of + the fundamental zone of the crystal-symmetry-reduced orientation space SO3, + it is possible to define a color model which assigns each point in + the fundamental zone a color. + Different mapping models are in use and implement (slightly) different + scaling relations. Differences are which base colors of the RGB + color model are placed in which extremal position of the SST + and where the white point is located. For further details see: + + * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the em_om + parsers takes a rasterized image which is rendered by the backend + tool. + + # \@signal: # rgb + # \@axes: # [ypos, xpos] # rgb + # \@rgb_indices: 0 + # \@axis_x_indices: # 0 + # \@axis_y_indices: # 1 + \@signal: + \@axes: + \@AXISNAME_indices: + + # \@long_name: + title: + data(NX_UINT): + unit: NX_UNITLESS + doc: | + RGB array, with resolution per fastest changing value defined by bitdepth. + dimensions: + rank: 3 + dim: [[1, n_y], [2, n_x], [3, 3]] + + # n_0 slow 2, n_1 fast 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: | + IPF color key in stereographic standard triangle (SST) + axis_y(NX_NUMBER): + unit: NX_ANY + doc: | + Pixel coordinate along the slow axis. + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + doc: | + Label for the y axis + axis_x(NX_NUMBER): + unit: NX_ANY + doc: | + Pixel coordinate along the fast axis. + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: + doc: | + Label for the x axis + correlation(NXprocess): + exists: optional + doc: | + This application definition also enables to describe a workflow where several + EBSD datasets are not only documented but also correlated based on time, + position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + # NEW ISSUE: implement support for filters eventually many of them + # NEW ISSUE: for now only show that data from DREAM3D can be loaded. + # NEW ISSUE: how to handle landmarks + # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid + # image registration etc. + sequence_index(NX_POSINT): + (NXem_ebsd_crystal_structure_model): + exists: ['min', '1', 'max', 'unbounded'] + crystallographic_database_identifier: + exists: recommended + crystallographic_database: + exists: recommended + unit_cell_abc(NX_FLOAT): + unit_cell_alphabetagamma(NX_FLOAT): + space_group: + exists: recommended + phase_identifier(NX_UINT): + phase_name: + exists: recommended + + # candidate for default plot + region_of_interest(NXprocess): + exists: ['min', '1', 'max', '1'] + doc: | + An overview of the entire reconstructed volume. For details about + what defines the image contrast inspect descriptor. + descriptor: + doc: | + Descriptor representing the image contrast. + + # enumeration: ["normalized_band_contrast", "normalized_confidence_index"] + roi(NXdata): + doc: | + Container holding a default plot of the reconstructed volume. + + # \@signal: # data + # \@axes: # [axis_z, axis_y, axis_x] + # \@axis_x_indices: # 0 + # \@axis_y_indices: # 1 + # \@axis_z_indices: # 2 + \@signal: + \@axes: + \@AXISNAME_indices: + + # \@long_name: + title: + data(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Descriptor values displaying the ROI. + dimensions: + rank: 3 + dim: [[1, n_z], [2, n_y], [3, n_x]] + + # n_0 slow 2, n_1 fast 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: | + Signal + axis_z(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated center of mass of the pixel along the slow axis. + dimensions: + rank: 1 + dim: [[1, n_z]] + \@long_name: + doc: | + Label for the z axis + axis_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated center of mass of the pixel along the fast axis. + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + doc: | + Label for the y axis + axis_x(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated center of mass of the pixel along the fastest axis. + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: + doc: | + Label for the x axis + (NXprocess): + exists: ['min', '0', 'max', 'unbounded'] + doc: | + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + The same comments apply as to the two-dimensional representation. + phase_identifier(NX_UINT): + unit: NX_UNITLESS + doc: | + Specifying which phase this IPF mapping visualizes. + phase_name: + doc: | + Alias/name for the phase whose indexed scan points are displayed. + description: + exists: optional + doc: | + Which IPF definition computation according to backend. + + # NEW ISSUE: [0, 0, 1] is defined in which coordinate system? + projection_direction(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Along which axis to project? Typically [0, 0, 1] is chosen. + dimensions: + rank: 1 + dim: [[1, 3]] + bitdepth(NX_UINT): + unit: NX_UNITLESS + doc: | + Bitdepth used for the RGB color model. Usually 8 bit. + (NXprogram): + exists: ['min', '1', 'max', 'unbounded'] + doc: | + The tool/implementation used for creating the IPF color map from + the orientation data. Effectively, this program is the backend + which performs the computation of the inverse pole figure mappings + which can be for some use cases the parser. + Consider the explanations in the docstring of the ipf_mapID group. + program: + \@version: + + # enumeration: [brinckmann, mtex, kikuchipy, dream3d, orix, tsl] + ipf_rgb_map(NXdata): + doc: | + The RGB image which represents the IPF map. + + # \@signal: # rgb + # \@axes: # [zpos, ypos, xpos] # rgb + # \@rgb_indices: 0 + # \@axis_x_indices: 0 + # \@axis_y_indices: 1 + # \@axis_z_indices: 2 + \@signal: + \@axes: + \@AXISNAME_indices: + + # \@long_name: + title: + data(NX_UINT): + unit: NX_UNITLESS + doc: | + RGB array, with resolution per fastest changing value + defined by bitdepth. + dimensions: + rank: 4 + dim: [[1, n_z], [2, n_y], [3, n_x], [4, 3]] + + # n_p_or_z slow 3, n_y fast 2, n_x faster 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: | + IPF color-coded orientation mapping + axis_z(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated center of mass of the pixel along the slow axis. + dimensions: + rank: 1 + dim: [[1, n_z]] + \@long_name: + doc: | + Label for the z axis + + # but for h5web RGB we need n_z + 1, was an issue in v6.6.1 + axis_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated center of mass of the pixel along the faster axis. + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + doc: | + Label for the y axis + + # but for h5web RGB we need n_y + 1, was an issue in v6.6.1 + axis_x(NX_NUMBER): + doc: | + Calibrated center of mass of the pixel along the fastest axis. + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: + doc: | + Label for the x axis + ipf_rgb_color_model(NXdata): + doc: | + Same comments as for the two-dimensional case apply. + + # \@signal: # rgb + # \@axes: # [ypos, xpos] # rgb + # \@rgb_indices: 0 + # \@axis_x_indices: # 0 + # \@axis_y_indices: # 1 + \@signal: + \@axes: + \@AXISNAME_indices: + + # \@long_name: + title: + data(NX_UINT): + unit: NX_UNITLESS + doc: | + RGB array, with resolution per fastest changing value defined by bitdepth. + dimensions: + rank: 3 + dim: [[1, n_y], [2, n_x], [3, 3]] + + # n_0 slow 2, n_1 fast 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: | + IPF color key in stereographic standard triangle (SST) + axis_y(NX_NUMBER): + unit: NX_ANY + doc: | + Pixel coordinate along the slow axis. + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + doc: | + Label for the y axis + axis_x(NX_NUMBER): + unit: NX_ANY + doc: | + Pixel coordinate along the fast axis. + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: + doc: | + Label for the x axis + + # NEW ISSUE: frame averaging + # NEW ISSUE: going towards the level of suggestions what would all be immediately possible + # ebsd_mapping(NXprocess): + # doc: | + # An EBSD mapping is the result of a collecting and indexing of Kikuchi + # pattern, so that for each pattern there is either an associated + # phase_identifier or a status marker stating that no solution was found + # (NXsst_color_model): ##MK + # doc: | + # For each stereographic standard triangle, (fundamental zone) of + # the orientation space, it is possible to define a color model which + # associates an orientation in the fundamental zone to a color. + # For details see: + # * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + # * Srikanth Patala and coworkers"'" work and of others. + # (NXorientation_set): + # doc: | + # Collection of quaternions in the SO3 fundamental zone with colors and + # rgb(NX_NUMBER): + # doc: RGB colors. + # unit: NX_UNITLESS + # dimensions: [[1, n_oris], [2, 3]] + # hsv and other models + # (NXcg_point_set): + # rgb(NX_NUMBER): + # dimensions: [[1, n_points], [2, 3]] + # mapping(NX_NUMBER): + # doc: | + # The EBSD mapping with colors outlined + # unit: NX_UNITLESS + # dimensions: [[1, n_y], [2, n_x], [3, 3]] + # NEW ISSUE: it would also be possible to define additional color models to overlay + # check n_p vs n_sc vs n_p_or_z + + # confidence_index(NX_FLOAT): + # doc: | + # Is a technology-partner-specific (TSL OIM) AMETEK phase_matching descriptor. + # unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, i]] + # mean_angular_deviation(NX_FLOAT): + # doc: | + # The mean angular deviation is also a technology-partner-specific + # (HKL Channel5) solution-to-reflector matching descriptor. + # unit: NX_ANGLE + # dimensions: + # rank: 1 + # dim: [[1, i]] + # there are many other type of descriptor especially for new machine learning + # type and dictionary type indexing methods + # some descriptors are relevant only for Hough based indexing and technology-partner-specific + # band_count(NX_UINT): + # doc: | + # How many bands were detected in the pattern. + # unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, n_p]] + # band_minimum(NX_UINT): + # doc: | + # Minimum number of bands required to index the pattern + # unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, n_p]] + # band_maximum(NX_UINT): + # doc: | + # Maximum number of bands required to index the pattern + # unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, n_p]] + # resolution(NX_NUMBER): + # doc: | + # Resolution in Hough space. + # unit: NX_ANGLE # or NX_ANY + # band_detection(NXprocess): # for hough_transform + # mode: + # doc: | + # How are Kikuchi bands detected + # enumeration: [center] + # band_contrast(NX_NUMBER): + # doc: | + # Value for band contrast descriptor. + # unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, n_p]] + # band_slope(NX_NUMBER): + # doc: | + # Value for band slope descriptor. + # unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, n_p]] + # centre(NX_FLOAT): + # doc: | + # Pattern centre location used for analyzing each pattern. + # unit: NX_LENGTH + # dimensions: + # rank: 2 + # dim: [[1, n_p], [2, 2]] # what to do when a different one for each pattern seldom but possible + # distance(NX_FLOAT): + # doc: | + # Pattern centre distance used for analyzing each pattern. + # unit: NX_LENGTH + # dimensions: + # rank: 2 + # dim: [[1, n_p], [2, 2]] + # vh_ratio(NX_FLOAT): + # doc: | + # TBD Oxford/HKL Channel 5 CPR files + # unit: NX_DIMENSIONLESS + # how to parameterize a group with value, and descriptor type or a + # field with descriptor type as attribute? + # pattern_quality(NXprocess): + # value(NX_NUMBER): + # doc: | + # Pattern quality descriptor + # unit: NX_UNITLESS + # dimensions: + # rank: 1 + # dim: [[1, n_p]] + # model: + # doc: | + # Model used to describe some aspect of the pattern. + # enumeration: [band_contrast, mean_angular_deviation] + # tilt_angle(NX_FLOAT): + # maybe better make this integrated into the NXtransformations of the stage_lab, a stage_lab event? + # beam_position(NXcg_point_set): + # (NXdetector): + # exposure_time(NX_FLOAT): + # unit: NX_TIME + # gain(NX_FLOAT): + ##MK how does a gain translate mathematically an input signal into an intensity signal? + # insertion_distance(NX_FLOAT): + # unit: NX_LENGTH + ##MK a coordinate system for the detector in the NXcoordinate_system_set + # drift_correction(NX_BOOLEAN): ##MK?? + # move the next two rather to detector + # acquisition_speed(NX_FLOAT): + # doc: | + # Average number of patterns taken per second averaged over entire set. + # unit: NX_FREQUENCY + # acquisition_time(NX_FLOAT): + # doc: Wall-clock time the acquisition took. + # unit: NX_TIME + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 3d31f77ef9a9a8c48c488eef9eb254679ea68be9c7076fec76bc2c700ddfd63b +# +# +# +# +# +# +# +# +# +# Number of arguments per orientation for given parameterization. +# +# +# +# +# Number of scan points. +# +# +# +# +# Number of pixel along the slowest changing dimension for a rediscretized, i.e. +# standardized default orientation mapping. +# +# +# +# +# Number of pixel along slow changing dimension for a rediscretized i.e. +# standardized default orientation mapping. +# +# +# +# +# Number of pixel along fast changing dimension for a rediscretized i.e. +# standardized default orientation mapping. +# +# +# +# +# +# Application definition for collecting and indexing Kikuchi pattern into orientation maps. +# +# This NXem_ebsd application is a proposal how to represent data, metadata, and +# connections between these for the research field of electron microscopy. +# More specifically, exemplified here for electron backscatter diffraction (EBSD). +# The application definition solves two key documentation issues which are missing +# so far to document provenance of data and metadata in the field of EBSD. +# The application definition can be an example that is relevant for related +# workflows in orientation microscopy. +# +# Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted +# according to the NXem_ebsd application definition) stores the connection between +# the microscope session and the key datasets which are considered typically results +# of the various processing steps involved when working with EBSD data. +# +# Different groups in this application definition make connections to data artifacts +# which were collected when working with electron microscopes via the NXem partner +# application definition. Using a file which stores information according to the +# NXem application definition has the benefit that it connects the sample, references +# to the sample processing, the user operating the microscope, details about the +# microscope session, and details about the acquistion and eventual indexing of +# Kikuchi pattern, associated overview images, like secondary electron or +# backscattered electron images of the region-of-interest probed and many +# more pieces of information. +# +# Secondly, this NXem_ebsd application definition connects and stores the conventions +# and reference frames which were used and are the key to mathematically correctly +# interpret every EBSD result. Otherwise, results would be ripped out of their +# context, as it is the situation with many traditional studies where EBSD data were +# indexed on-the-fly and shared with the community only via sharing the results file +# with some technology-partner-specific file but leaving important conventions out +# or relying on the assumptions that colleagues know these even though multiple +# definitions are possible. +# +# This application definition covers experiments with one-, two-dimensional, and +# so-called three-dimensional EBSD datasets. The third dimension is either time +# (in the case of quasi in-situ experiments) or space (in the case of serial- +# sectioning) methods where a combination of mechanical or ion milling is used +# repetitively to measure the same region-of-interest at different depth increments. +# Material removal can be achieved with electron or ion polishing, using manual +# steps or using automated equipment like a robot system. +# +# Three-dimensional experiments require to follow a sequence of specimen, surface +# preparation, and data collection steps. By nature these methods are destructive +# in that they either require the removal of the previously measured material region +# or that the sample surface can degrade due to e.g. contamination or other +# electron-matter interaction. +# +# For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are +# combined into one reconstructed stack. That is serial-sectioning is mainly a +# computational workflow. Users collect data for each serial sectioning step +# via an experiment. This assures that data for associated microscope sessions +# and steps of data processing stay connected and contextualized. +# +# Eventual tomography methods also use such a workflow because first diffraction +# images are collected (e.g. with X-ray) and then these imagres are indexed and +# computed into a 3D orientation mapping. The here proposed NXem_ebsd application +# definition contains conceptual ideas how this splitting between measurement and +# post-processing can be granularized also for such X-ray-based techniques, whether +# it be 3DXRD or HEDM. +# +# +# +# +# An at least as strong as SHA256 hashvalue of the file +# that specifies the application definition. +# +# +# +# +# +# NeXus NXDL schema to which this file conforms. +# +# +# +# +# +# +# +# Ideally, a (globally) unique persistent identifier +# for referring to this workflow. +# +# The identifier is usually defined/issued by the facility, laboratory, +# or the principle investigator. The identifier enables to link +# workflows/experiments to e.g. proposals. +# +# +# +# +# Free-text description about the workflow. +# +# Users are strongly advised to detail the sample history in the respective +# field and fill rather as completely as possible the fields of the application +# definition behind instead of filling in these details into the experiment_description +# free-text description field. +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC information +# included when the processing of the workflow started. +# If the application demands that time codes in this section of the +# application definition should only be used for specifying when the +# workflow was executed - and the exact duration is not relevant +# - this start_time field should be used. +# +# Often though it is useful to specify a time interval with specifying +# both start_time and end_time to allow for more detailed bookkeeping +# and interpretation of the workflow. +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC included +# when the processing of the workflow ended. +# +# +# +# +# Program which was used for creating the file instance which is +# formatted according to the NXem_ebsd application definition. +# +# +# +# +# +# +# +# Contact information and eventually details of at least one person +# involved in performing the workflow. This can be the principle investigator +# who performed this experiment. Adding multiple users if relevant is +# recommended. +# +# +# +# Given (first) name and surname of the user. +# +# +# +# +# Name of the affiliation of the user at the point in time +# when the experiment was performed. +# +# +# +# +# Postal address of the affiliation. +# +# +# +# +# Email address of the user at the point in time when the experiment +# was performed. Writing the most permanently used email is recommended. +# +# +# +# +# Globally unique identifier of the user as offered by services +# like ORCID or ResearcherID. If this field is field the specific +# service should also be written in orcid_platform +# +# +# +# +# Name of the OrcID or ResearcherID where the account +# under orcid is registered. +# +# +# +# +# (Business) (tele)phone number of the user at the point +# in time when the experiment was performed. +# +# +# +# +# Which role does the user have in the place and at the point +# in time when the experiment was performed? Technician operating +# the microscope. Student, postdoc, principle investigator, guest +# are common examples. +# +# +# +# +# Account name that is associated with the user +# in social media platforms. +# +# +# +# +# Name of the social media platform where the account +# under social_media_name is registered. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Details about simulations for Kikuchi pattern using kinematic or dynamic +# diffraction theory. Usually, the output of such computer simulations are +# spherical Kikuchi images which only when projected or observed in some +# region-of-interest will represent a set of rectangular Kikuchi pattern +# with the same rectangular shape and image size. +# +# Therefore, these pattern should be stored. The spherical diffraction +# pattern can be stored as a set of triangulated geodesic meshes. +# The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. +# +# Do not store pattern in the simulation group if they +# have been measured are not simulated. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The experiment group captures relevant details about the conditions of +# and the tools used for collecting the Kikuchi diffraction pattern. +# +# The most frequently collected EBSD data are captured as rectangular ROIs +# composed from square or hexagonally-shaped pixels. Substantially less +# frequently, because such experiments are more costly and technically +# demanding, correlated experiments are performed. +# +# One important class of such correlated experiments are the so-called +# (quasi) in-situ experiments. Here the same or nearly the same ROI is +# analyzed via a cycles of thermomechanical treatment, sample preparation, +# measurement, on-the-fly-indexing. Phenomena investigated like this are +# recrystallization, strain accumulation, material damage. +# Post-processing is required to correlate and reidentify eventual +# features or local ROIs across several orientation maps. +# +# Another important class of correlated experiments are the so-called +# serial-sectioning experiments. Here the same sample is repetitively measured +# and polished to create a stack of orientation data which can be reconstructed +# to a three-dimensional volume ROI. +# +# +# +# Physical time since the beginning of a timestamp that is required to be +# same for all experiments in the set. The purpose of this marker is +# to identify how all experiments in the set have have to be arranged +# sequentially based on the time elapsed. +# The time is relevant to sort e.g. experiments of consecutive quasi +# in-situ experiments where a measurement was e.g. taken after 0 minutes +# of annealing, 30 minutes, 6 hours, or 24 hours of annealing. +# +# +# +# +# Transformation which details where the region-of-interest described under +# indexing is located in absolute coordinates and rotation with respect +# to which coordinate system. +# +# +# +# +# +# The EBSD system, including components like the electron gun, pole-piece, +# stage tilting, EBSD detector, and the gnomonic projection have to be +# calibrated to achieve reliable results. Specifically, the gnomonic projection +# has to be calibrated. +# +# In most practical cases, especially in engineering, there is a substantially +# larger number of sessions where such a calibrated system is used assuming +# that somebody has properly calibrated the system rather than that the user +# actively recalibrates it or is even allowed to do so. +# Especially the projection geometry has to calibrated which is usually +# achieved with measuring silicon, quartz or standards, and comparing +# against simulated diffraction pattern. +# +# In the first case, the user assumes that the principle geometry of the +# hardware components and the settings in the control and EBSD pattern +# acquisition software are calibrated. Consequently, users pick from an +# existent library of phase candidates. One example are the CRY or CIF +# files of the classical HKL/Channel 5/Flamenco software products. +# Each entry of the library of such phase candidates in this NeXus proposal +# is represented by one NXem_ebsd_crystal_structure_model base class. +# For each phase an instance of this base class is to be used to store +# crystallographic and simulation-relevant data. +# +# Indexing is a data processing step performed after/during the beam scans +# the specimen (depends on configuration). Users load the specimen, and first +# collect a coarse image of the surface. Next, an approximate value for the +# calibrated working distance is chosen and the stage tilted. +# Users then may configure the microscope for collecting higher quality data +# and push in the EBSD detector. Subsequently, they fine tune the illumination +# and aberration settings and select one or multiple ROIs to machine off. +# The on-the-fly indexing parameter are defined and usually the automated +# measurement queue started. +# +# Nowadays, this is usually an automated/unsupervised process. The pattern +# collection runs during the allocated session time slot which the user has +# booked ends or when the queue finishes prematurely. Kikuchi pattern surplus +# eventually multi-modal detector signals are collected and usually indexed +# on-the-fly. The Kikuchi patterns may or not be deleted directly after a +# solution was found (on-the-fly) so Kikuchi pattern are not always stored. +# +# Results files are in many labs afterwards copied automatically +# for archival purposes to certain storage locations. The result of such an +# EBSD measurement/experiment is a set of usually proprietary or open files +# from technology partners (microscope and EBSD detector manufacturers). +# +# In the second case, the system is being calibrated during the session +# using standards (silicon, quartz, or other common specimens). +# There is usually one person in each lab responsible for doing such +# calibrations. Important is that often this person or technician(s) are also +# in charge of configuring the graphical user interface and software +# with which most users control and perform their analyses. +# For EBSD this has key implications because, taking TSL OIM/EDAX as an example, +# the conventions how orientations are stored is affected by how reference frames +# are set up and this setup is made at the level of the GUI software. +# Unfortunately, these pieces of information are not necessarily stored +# in the results files. In effect, key conventions become disconnected +# from the data so it remains the users personal obligation to remember these +# settings, write them down in the lab notebook, or these metadata get lost. +# All these issues are a motivation and problem which NXem_ebsd solves. +# +# +# +# +# A link/cross reference to an existent instance of NXem_ebsd with ideally +# an associated instance of NXem detailed under measurement which informs +# about the calibration procedures. +# +# +# +# Commit identifying this resource. +# +# +# +# +# +# Path which resolves which specific NXimage_set_em_kikuchi instance +# was used as the raw data to the EBSD data (post)-processing workflow +# when performing the calibration. +# +# +# +# +# +# +# Relevant result of the session at the microscope for this experiment +# which enables to connect the measurement of the Kikuchi pattern and +# their processing into orientation microscopy maps. +# +# +# +# +# Name or link to an existent instance of an EBSD raw dataset ideally +# as an instance of an NXem application definition which has at least +# one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. +# The path to this instance in the origin has to be specified under path. +# +# When NXem is not used or the aim is to rather explore first how +# community-specific files with EBSD data, such as ANG, CPR, or HDF5- +# based formats can be parsed from, inject here the name of that file. +# +# The em_om parser will currently not interpret the majority of the +# many system- and technique-specific metadata which come with the +# files from e.g. technology partners. This is because the current +# culture in the EBSD community is that many of the metadata fields +# are neither in all cases fully documented nor use a standardized +# vocabulary although many people understand terms from different +# implementations and how these metadata can likely be compared to +# one another. +# +# In addition, it is common practice in the research field of EBSD that +# users transcode their raw data into other (often text-based or HDF5) +# files with custom formatting to realize an information transfer +# between specific software tools including commercial software from +# technology partner, custom scripts in Matlab using tools like MTex, +# or Python scripting with tools like hyperspy, pyxem, orix, diffsims, +# kikuchipy, or EBSD data stack alignment tools like DREAM.3D. +# We have opted that in the first iteration this implementation of a +# RDMS-agnostic FAIR data schema for EBSD that we discard these metadata +# because these ad hoc file formats are not designed to communicate +# also specifically and most importantly the eventually different context +# of the metadata. +# Another reason for this choice was also to emphasize that in fact such +# challenges do exist in the community and thus pointing them out may +# support the discussion to arrive at eventually more complete solutions. +# As developing these solutions should not be our authority and necessarily +# demands feedback from the technology partners, we have opted for this +# intermediate approach to stimulate discussion. +# +# +# +# Commit or e.g. at least SHA256 checksum identifying this resource. +# +# +# +# +# +# Path which resolves which specific NXimage_set_em_kikuchi instance +# was used as the raw data to this EBSD data (post)-processing workflow. +# +# +# +# +# +# +# +# OIM, orientation imaging microscopy. Post-processing of the Kikuchi +# patterns to obtain orientation per phase model and scan point. +# Fundamentally different algorithms can be used to index EBSD/EBSP pattern. +# +# Common is that pattern indexing is a computational step of comparing +# simulated with measured diffraction pattern. Quality descriptors are defined +# based on which an indexing algorithm yields a quantitative measure of +# how similar measured and assumed/simulated pattern are, and thus if +# no, one, or multiple so-called solutions were found. +# +# Assumed or simulated pattern use kinematical or dynamical electron +# diffraction theory. Hough transform (which is essentially a discretized +# Radon transform, for details see e.g A short introduction to the Radon +# and Hough transforms and how they relate by M. van Ginkel et al.). +# Recently, dictionary-based indexing methods are increasingly becoming used +# partly driven by the move to use artificial intelligence algorithms. +# +# An inspection of publicly available EBSD datasets with an open-source +# license which are available on Zenodo was performed prior to implementing +# of the associated em_om parser for NXem_ebsd. This analysis revealed that +# EBSD data are in most cases stored in two ways: Case one was via a file in +# formats from technology partners. Examples are binary formats like OSC, +# H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, +# CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. +# +# These files contain some result and metadata to the numerical steps and the +# computational workflow which was performed to index Kikuchi pattern +# on-the-fly. Examples of metadata include scan point positions, indexing +# solutions per scan point, some quality descriptors for the solutions, +# as well as crystal structure and phase metadata. +# +# Case two were raw pattern in some custom format, often text-based with +# some but in general no conclusive and interoperable representation of all +# relevant metadata. +# Often it remains unclear what individual fields and data arrays of these +# fields resolve and/or mean conceptually. For some fields, publications were +# referred to. However, software tools change over time and thus which specific +# data end in a file and which specific conceptual information is behind +# these data can change with software versions. +# +# Other cases were storing results of custom post-processing steps and +# associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry +# resolving methods, i.e. any sort of prototyping or alternative indexing +# strategies so far seem to require some flexibility for implementing +# rapid prototypic capabilities. The drawback of this is that such results +# come formatted on a case-by-case basis and are thus not interoperable. +# +# Therefore, we first need to collect how these files have been generated +# and which metadata in these files (or database entries) represent +# which pieces of information conceptually. Ideally, one would do so by +# creating a complete set of information in e.g. an NXem application definition, +# such as a log of timestamped events and processing steps, metadata and data. +# Eventually even interactions with the graphical user interface of commercial +# software during the microscope session should be stored and become a +# part of the application definition. +# +# Such a set of pieces of information could then be used via reading directly +# for the NXem application definition. However, in most cases such a data +# representation is not available yet. +# +# +# +# +# Therefore, the on_the_fly_indexing group stores which source_file contains +# the results of the on-the-fly indexing. For commercial systems these files +# can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or +# database entry which is referred to under origin is the same as the one +# under a given acquisition/origin in one of the experiment groups. +# This is because some commercial file formats make no clear distinction +# between which metadata are acquisition and/or indexing metadata. +# +# +# +# Commercial program which was used to index the EBSD data +# incrementally after they have been captured and while the +# microscope was capturing (on-the-fly). This is the usual +# production workflow how EBSD data are collected in +# materials engineering, in industry, and academia. +# +# +# +# +# +# +# +# Name of the file from which data relevant for creating default plots +# were taken in the case that the data in the experiment group were +# indexed on-the-fly. +# +# +# +# Hash of that file. +# +# +# +# +# +# TBD, path which resolves which specific NXimage_set_em_kikuchi instance +# was used as the raw data to this EBSD data (post)-processing workflow +# when performing the calibration. +# +# +# +# +# +# Principal algorithm used for indexing. +# +# +# +# +# +# +# +# +# +# +# +# Details about the background correction applied to each Kikuchi pattern. +# +# +# +# +# +# +# Binning i.e. downsampling of the pattern. +# +# +# +# +# +# +# Specific parameter relevant only for certain algorithms used +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Which return value did the indexing algorithm yield for each scan point. +# Practically useful is to use an uint8 mask. +# +# * 0 - Not analyzed +# * 1 - Too high angular deviation +# * 2 - No solution +# * 100 - Success +# * 255 - Unexpected errors +# +# +# +# +# +# +# +# +# How many phases i.e. crystal structure models were used to index each +# scan point if any? Let's assume an example to explain how this field +# should be used: In the simplest case users collected one pattern for +# each scan point and have indexed using one phase, i.e. one instance +# of an NXem_ebsd_crystal_structure_model. +# +# In another example users may have skipped some scan points (not indexed) +# them at all) and/or used differing numbers of phases for different scan +# points. +# +# The cumulated of this array decodes how phase_identifier and phase_matching +# arrays have to be interpreted. In the simplest case (one pattern per scan +# point, and all scan points indexed using that same single phase model), +# phase_identifier has as many entries as scan points +# and phase_matching has also as many entries as scan points. +# +# +# +# +# +# +# +# The array n_phases_per_scan_point details how the phase_identifier +# and the phase_matching arrays have to be interpreted. +# +# For the example with a single phase phase_identifier has trivial +# values either 0 (no solution) or 1 (solution matching +# sufficiently significant with the model for phase 1). +# +# When there are multiple phases, it is possible (although not frequently +# needed) that a pattern matches eventually (not equally well) sufficiently +# significant with multiple pattern. This can especially happen in cases of +# pseudosymmetry and more frequently with an improperly calibrated system +# or false or inaccurate phase models e.g. (ferrite, austenite). +# Having such field is especially relevant for recent machine learning +# or dictionary based indexing schemes because in combination with +# phase_matching these fields communicate the results in a model-agnostic +# way. +# +# Depending on the n_phases_per_scan_point value phase_identifier and +# phase_matching arrays represent a collection of concatenated tuples, +# which are organized in sequence: The solutions for the 0-th scan point, +# the 1-th scan point, the n_sc - 1 th scan point and omitting tuples +# for those scan points with no phases according to n_phases_per_scan_point +# +# +# +# +# +# +# +# One-dimensional array, pattern by pattern labelling the solutions found. +# The array n_phases_per_scan_point has to be specified because it details +# how the phase_identifier and the phase_matching arrays have to be interpreted. +# See documentation of phase_identifier for further details. +# +# +# +# +# +# +# +# Phase_matching is a descriptor for how well the solution matches or not. +# Examples can be confidence index (ci), mean angular deviation (mad), +# some AI-based matching probability (other), i.e. the details are implementation-specific. +# +# +# +# +# +# +# +# +# +# +# How are orientations parameterized? Inspect euler_angle_convention +# in case of using euler to clarify the sequence of rotations assumed. +# +# +# +# +# +# +# +# +# +# +# +# Matrix of parameterized orientations identified. The slow dimension +# iterates of the individual solutions as defined by n_phases_per_scan_point. +# Values for phases without a solution should be correctly identified as +# IEEE NaN. +# +# +# +# +# +# +# +# +# +# Matrix of calibrated centre positions of each scan point +# in the sample surface reference system. +# +# +# +# +# +# +# +# +# +# +# Fraction of successfully indexed pattern +# of the set averaged over entire set. +# +# +# +# +# +# An overview of the entire area which was scanned. +# For details about what defines the image contrast +# inspect descriptor. +# +# +# +# Descriptor representing the image contrast. +# +# +# +# +# +# +# +# +# +# Container holding a default plot of the region on the sample +# investigated with EBSD. +# +# +# +# +# +# +# +# +# +# Descriptor values displaying the ROI. +# +# +# +# +# +# +# +# +# Signal +# +# +# +# +# +# Calibrated center of mass of the pixel along the slow axis. +# +# +# +# +# +# +# Label for the y axis +# +# +# +# +# +# Calibrated center of mass of the pixel along the fast axis. +# +# +# +# +# +# +# Label for the x axis +# +# +# +# +# +# +# +# Default inverse pole figure (IPF) plot of the data specific for each +# phase. No ipf_mapID instances for non-indexed scan points as these are +# by definition assigned the null phase with phase_identifier 0. +# +# The IPF mapping is interpolated from the scan point data mapping +# onto a rectangular domain with square pixels and the +# orientations colored according to the coloring scheme used in the +# respective ipf_color_modelID/program. +# +# The main purpose of the ipf_mapID group is not to keep raw data or +# scan point related data but offer a default way how a research data +# management system can display a preview of the dataset so that users +# working with the RDMS can get an overview of the dataset. +# +# This matches the first aim of NXem_ebsd which is foremost to bring +# colleagues and users of EBSD together to discuss which pieces of information +# need to be stored together. We are convinced a step-by-step design and +# community-driven discussion about which pieces of information should +# and/or need to be included is a practical strategy to work towards an +# interoperable description and data model for exchanging +# data from EBSD between different tools and research data management +# systems (RDMS). +# +# With this design the individual RDMS solutions and tools can still continue +# to support specific custom data analyses workflow and routes but at least +# there is then one common notation of understanding whereby also users +# not necessarily expert in all the details of the EBSD story can understand +# better these data and thus eventually this can motivate data reuse and +# repurposing. +# +# It is important to mention that we cannot assume, at least for now, +# that the parser which writes to an NXem_ebsd-compliant file is also +# responsible or capable at all of computing the inverse pole figure +# color keys and maps itself. This cannot be assumed working because +# this mapping of orientation data uses involved mathematical algorithms +# and functions which not every tools used in the EBSD community is capable +# of using or is for sure not using in exactly the same way. +# +# Currently, we assume it is the responsibilty of the tool used which +# generated the data under on_the_fly_indexing to compute these +# plots and deliver these to the parser. +# +# Specific case studies have been explored by the experiment team of +# Area B of the FAIRmat project to realize and implement such mapping. +# +# The first case study uses the H5OINA format and the pyxem/orix library. +# As orix is a Python library, the coloring is performed by the em_om parser. +# +# The second case study uses MTex and its EBSD color coding model. +# As MTex is a Matlab tool, an intermediate format is written from MTex +# first which stores these pieces of information. The parser then pulls +# these data from the intermediate Matlab-agnostic representation and +# supplements the file with missing pieces of information as it is +# required by NXem_ebsd. +# +# The third case study shows how a generic set of Kikuchi pattern +# can be loaded with the em_om parser. The pattern are loaded directly +# from a ZIP file and mapped to an simulation image section for now. +# +# The fourth case study uses the DREAM.3D package which provides an own +# set of EBSD data post-processing procedures. DREAM.3D documents the +# processing steps with a pipeline file which is stored inside DREAM.3D +# output files. In this case study, the parser reads the DREAM.3D file +# and maps data relevant from the perspective of NXem_ebsd plus adds +# relevant IPF color maps as they were computed by DREAM.3D. +# Given that in this case the origin of the data is the DREAM.3D file +# again provenance is kept and more details can be followed upon when +# resolving origin. +# +# These examples offer a first set of suggestions on how to make EBSD +# data injectable into research data management system using schemes +# which themselves are agnostic to the specific RDMS and interoperable. +# Steps of collecting the raw data and post-processing these with custom +# scripts like MTex or commercial tools so far are mainly undocumented. +# The limitation is that a program which consumes results or dump files +# from these tools may not have necessarily all the sufficient information +# available to check if the injected orientation data and color models +# are matching the conventions which a user or automated system has +# injected into an electronic lab notebook from which currently the em_om +# parser collects the conventions and stores them into this NXem_ebsd instance. +# The immediate benefit of the here presented NXem_ebsd concept though +# is that the conventions and reference frame definitions are expected +# in an ELN-agnostic representation to make NXem_ebsd a generally useful +# data scheme for EBSD. +# +# Ideally, the em_om parser would load convention-compliant EBSD data +# and use subsequently a community library to transcode/convert orientation +# conventions and parameterized orientation values. Thereafter, convention- +# compliant default plot(s) could be created that would be truely interoperable. +# +# However, given the variety of post-processing tools available surplus +# the fact that these are not usually executed along standardized +# post-processing workflows which perform exactly the same algorithmic steps, +# this is currently not a practically implementable option. Indeed, first +# developers who wish to implement this would first have to create a library +# for performing such tasks, mapping generally between conventions, +# i.e. map and rotate coordinate systems at the parser level. +# +# The unfortunate situation in EBSD is that due to historical reasons +# and competitive strategies, different players in the field have +# implemented (slightly) different approaches each of which misses +# some part of a complete workflow description which is behind EBSD analyses: +# Sample preparation, measurement, indexing, post-processing, paper... +# +# The here exemplified default plot do not so far apply relevant rotations +# but takes the orientation values as they come from the origin and using +# coloring them as they come. It is thus the scientists responsibility to +# enter and check if the respective dataset is rotation-conventions-wise +# consistent and fit for a particular task. +# +# Ideally, with all conventions defined it can be possible to develop +# a converter which rotates the input data. This application definition +# does not assume this and users should be aware of this limitation. +# +# The key point is that the conventions however are captured and this is +# the most important step to the development of such a generic transcoder +# for creating interoperable EBSD datasets. +# +# Currently the conventions remain in the mind or manual lab book of the +# respective scientists or technicians instead of getting stored and +# communicated with research papers that are written based on +# specific dataset, i.e. database entries. +# +# The default gridded representation of the data should not be +# misinterpreted as the only possible way how EBSD data and OIM +# maps can be created! +# +# Indeed, the most general case is that patterns are collected for +# scan points. The scan generator of an electron microscope is instructed +# to steer the beam in such a way across the specimen surface that the +# beam illuminates certain positions for a certain amount time (usually +# equally-spaced and spending about the same amount of time at each +# position). +# +# Therefore, scan positions can be due to such regular flight plans and +# represent sampling on lines, line stacks, rectangular regions-of- +# interests, but also could instruct spiral, random, or adaptive scans +# instead of tessellations with square or hexagonal pixels. +# +# The majority of EBSD maps is though is reporting results for a regular +# grid (square, hexagon). What matters though in terms of damage induced +# by the electron beam and signal quality is the real electron dose +# history, i.e. for how long the beam exposed which location of the +# specimen. Especially when electron charging occurs (i.e. an excess +# amount of charge accumulates due to e.g. poor conducting away of this +# charge or an improper mounting, too high dose, etc. such details are +# relevant. +# +# Specifically, the default visualization is an inverse pole-figure (IPF) +# map with the usual RGB color coding. Different strategies and +# normalization schemes are in use to define such color coding. +# +# Finally, we should mention that each ipf_map represents data for +# scan points indexed as one phase. The alias/name of this phase should +# be stored in phase_name, the phase_identifier give an ID which must +# not be zero as this value is reserved for non-indexed / null model scan +# points. +# +# +# +# Specifying which phase this IPF mapping visualizes. +# +# +# +# +# Alias/name for the phase whose indexed scan points are displayed. +# +# +# +# +# Which IPF definition computation according to backend. +# +# +# +# +# +# +# Along which axis to project? Typically [0, 0, 1] is chosen. +# +# +# +# +# +# +# +# Bitdepth used for the RGB color model. Usually 8 bit. +# +# +# +# +# +# The tool/implementation used for creating the IPF color map from +# the orientation data. Effectively, this program is the backend +# which performs the computation of the inverse pole figure mappings +# which can be for some use cases the parser. +# Consider the explanations in the docstring of the ipf_mapID group. +# +# +# +# +# +# +# +# +# The RGB image which represents the IPF map. +# +# +# +# +# +# +# +# +# +# RGB array, with resolution per fastest changing value +# defined by bitdepth. +# +# +# +# +# +# +# +# +# +# IPF color-coded orientation mapping +# +# +# +# +# +# Calibrated center of mass of the pixel along the slow axis. +# +# +# +# +# +# +# Label for the y axis +# +# +# +# +# +# +# Calibrated center of mass of the pixel along the fast axis. +# +# +# +# +# +# +# Label for the x axis +# +# +# +# +# +# +# For each stereographic standard triangle (SST), i.e. a rendering of +# the fundamental zone of the crystal-symmetry-reduced orientation space SO3, +# it is possible to define a color model which assigns each point in +# the fundamental zone a color. +# Different mapping models are in use and implement (slightly) different +# scaling relations. Differences are which base colors of the RGB +# color model are placed in which extremal position of the SST +# and where the white point is located. For further details see: +# +# * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) +# * Srikanth Patala and coworkers"'" work and of others. +# +# Details are implementation-specific and not standardized yet. +# Given that the SST has a complicated geometry, it cannot yet be +# visualized using tools like H5Web, which is why for now the em_om +# parsers takes a rasterized image which is rendered by the backend +# tool. +# +# +# +# +# +# +# +# +# +# RGB array, with resolution per fastest changing value defined by bitdepth. +# +# +# +# +# +# +# +# +# +# IPF color key in stereographic standard triangle (SST) +# +# +# +# +# +# Pixel coordinate along the slow axis. +# +# +# +# +# +# +# Label for the y axis +# +# +# +# +# +# Pixel coordinate along the fast axis. +# +# +# +# +# +# +# Label for the x axis +# +# +# +# +# +# +# +# +# +# This application definition also enables to describe a workflow where several +# EBSD datasets are not only documented but also correlated based on time, +# position (spatial), or both (spatiotemporal). +# +# Spatial correlations between repetitively characterized regions-of-interests +# are typically correlated using image registration and alignment algorithms. +# For this typically so-called landmarks are used. These can be grains with +# a very large size or specific shape, i.e. grains which are qualitatively +# different enough to be used as a guide how images are shifted relative to +# one another. Other commonly used landmarks are fiducial marks which are +# milled into the specimen surface using focus-ion beam milling and/or various +# types of indentation methods. +# +# As far as the same physical region-of-interest is just measured several times, +# the additional issue of the depth increment is not a concern. However, correct +# assumptions for the depth increment, amount of material removed along the milling +# direction is relevant for accurate and precise three-dimensional (serial-sectioning) +# correlations. For these studies it can be tricky though to assume or estimate +# useful depth increments. Different strategies have been proposed like +# calibrations, wedged-shaped landmarks and computer simulation assisted +# assumption making. +# +# Despite the use of landmarks, there are many practical issues which make the +# processing of correlations imprecise and inaccurate. Among these are drift +# and shift of the specimen, instabilities of the holder, the beam, irrespective +# of the source of the drift, charging effects, here specifically causing local +# image distortions and rotations which may require special processing algorithms +# to reduce such imprecisions. +# +# Time correlations face all of the above-mentioned issues surplus the challenge +# that specific experimental protocols have to be used to ensure the material state +# is observed at specific physical time. The example of quasi in-situ characterization +# of crystal growth phenomena, a common topic in engineering or modern catalysis research +# makes it necessary to consider that e.g. the target value for the desired annealing +# temperature is not just gauged based on macroscopic arguments but considers +# that transient effects take place. Heating or quenching a sample might thus might +# not have been executed under conditions in the interaction volume as they are +# documented and/or assumed. +# +# These issue cause that correlations have an error margin as to how accurately +# respective datasets were not only just synced based on the geometry of the +# region-of-interests and the time markers but also to asssure which physical +# conditions the specimen experienced over the course of the measurements. +# +# The fourth example of the em_om reference implementation explores the use of the +# correlation group with a serial-sectioning datasets that was collected by the +# classical Inconel 100 dataset collected by M. D. Uchic and colleagues +# (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and +# characterization of polycrystalline microstructures using a fib-sem system data set. +# Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). +# +# This dataset was specifically relevant in driving forward the implementation +# of the DREAM.3D software. DREAM.3D is an open-source software project for +# post-processing and reconstructing, i.e. correlating sets of orientation +# microscopy data foremost spatially. One focus of the software is the +# (post-)processing of EBSD datasets. Another cutting edge tool with similar +# scope but a commercial solution by Bruker is QUBE which was developed by +# P. Konijnenberg and coworkers. +# +# Conceptually, software like DREAM.3D supports users with creating linear +# workflows of post-processing tasks. Workflows can be instructed via the +# graphical user interface or via so-called pipeline processing via command line +# calls. DREAM.3D is especially useful because its internal system documents all +# input, output, and parameter of the processing steps. This makes DREAM.3D a +# good candidate to interface with tools like em_om parser. Specifically, DREAM.3D +# documents numerical results via a customized HDF5 file format called DREAM3D. +# Workflow steps and settings are stored as nested dictionaries in JSON syntax +# inside a supplementary JSON file or alongside the data in the DREAM3D file. +# DREAM.3D has a few hundred algorithms implemented. These are called filters +# in DREAM.3D terminology. +# +# Users configure a workflow which instructs DREAM.3D to send the data through +# a chain of predefined and configured filters. Given that for each analysis +# the filter is documented via its version tags surplus its parameter and setting +# via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file +# is possible in an automated manner using a parser. This makes DREAM.3D analyses +# repeatable and self-descriptive. A key limitation though is that most frequently +# the initial set of input data come from commercial files like ANG. +# This missing link between the provenance of these input files, their associated +# creation as electron microscope session, is also what NXem_ebsd solves. +# +# Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that +# the DREAM.3D and the em_om parser can work productively together to realize +# RDMS-agnostic parsing of serial-section analyses. +# +# The internal documentation of the DREAM.3D workflow also simplifies the +# provenance tracking represented by an instance of NXem_ebsd as not every +# intermediate results has to be stored. Therefore, the fourth example +# focuses on the key result obtained from DREAM.3D - the reconstructed +# and aligned three-dimensional orientation map. +# +# Usually, this result is the starting point for further post-processing +# and characterization of structural features. As here orientation microscopy +# is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should +# be useful for different characterization methods, such as EBSD, Transmission +# Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), +# Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) +# or open-source implementations of these techniques (such as via pyxem/orix). +# +# The result of orientation microscopy methods are maps of local orientation +# and thermodynamic phase (crystal structure) pieces of information. Virtually +# all post-processing of such results for structural features includes again +# a workflow of steps which are covered though by the NXms partner application +# definition. The respective source of the data in an instance of NXms can +# again be a link or reference to an instance of NXem_ebsd to complete the +# chain of provenance. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# An overview of the entire reconstructed volume. For details about +# what defines the image contrast inspect descriptor. +# +# +# +# Descriptor representing the image contrast. +# +# +# +# +# +# Container holding a default plot of the reconstructed volume. +# +# +# +# +# +# +# +# +# +# Descriptor values displaying the ROI. +# +# +# +# +# +# +# +# +# +# Signal +# +# +# +# +# +# Calibrated center of mass of the pixel along the slow axis. +# +# +# +# +# +# +# Label for the z axis +# +# +# +# +# +# Calibrated center of mass of the pixel along the fast axis. +# +# +# +# +# +# +# Label for the y axis +# +# +# +# +# +# Calibrated center of mass of the pixel along the fastest axis. +# +# +# +# +# +# +# Label for the x axis +# +# +# +# +# +# +# +# Default inverse pole figure (IPF) plot of the data specific for each +# phase. No ipf_mapID instances for non-indexed scan points as these are +# by definition assigned the null phase with phase_identifier 0. +# The same comments apply as to the two-dimensional representation. +# +# +# +# Specifying which phase this IPF mapping visualizes. +# +# +# +# +# Alias/name for the phase whose indexed scan points are displayed. +# +# +# +# +# Which IPF definition computation according to backend. +# +# +# +# +# +# Along which axis to project? Typically [0, 0, 1] is chosen. +# +# +# +# +# +# +# +# Bitdepth used for the RGB color model. Usually 8 bit. +# +# +# +# +# The tool/implementation used for creating the IPF color map from +# the orientation data. Effectively, this program is the backend +# which performs the computation of the inverse pole figure mappings +# which can be for some use cases the parser. +# Consider the explanations in the docstring of the ipf_mapID group. +# +# +# +# +# +# +# +# +# The RGB image which represents the IPF map. +# +# +# +# +# +# +# +# +# +# RGB array, with resolution per fastest changing value +# defined by bitdepth. +# +# +# +# +# +# +# +# +# +# +# IPF color-coded orientation mapping +# +# +# +# +# +# Calibrated center of mass of the pixel along the slow axis. +# +# +# +# +# +# +# Label for the z axis +# +# +# +# +# +# +# Calibrated center of mass of the pixel along the faster axis. +# +# +# +# +# +# +# Label for the y axis +# +# +# +# +# +# +# Calibrated center of mass of the pixel along the fastest axis. +# +# +# +# +# +# +# Label for the x axis +# +# +# +# +# +# +# Same comments as for the two-dimensional case apply. +# +# +# +# +# +# +# +# +# +# RGB array, with resolution per fastest changing value defined by bitdepth. +# +# +# +# +# +# +# +# +# +# IPF color key in stereographic standard triangle (SST) +# +# +# +# +# +# Pixel coordinate along the slow axis. +# +# +# +# +# +# +# Label for the y axis +# +# +# +# +# +# Pixel coordinate along the fast axis. +# +# +# +# +# +# +# Label for the x axis +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXem_ebsd_conventions.yaml b/contributed_definitions/nyaml/NXem_ebsd_conventions.yaml new file mode 100644 index 0000000000..45696360d2 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_ebsd_conventions.yaml @@ -0,0 +1,940 @@ +category: base + +# symbols: +doc: | + Conventions for rotations and coordinate systems to interpret EBSD data. + + This is the main issue which currently is not in all cases documented + and thus limits the interoperability and value of collected EBSD data. + Not communicating EBSD data with such contextual pieces of information + and the use of file formats which do not store this information is the + key unsolved problem. +type: group +NXem_ebsd_conventions(NXobject): + + # mandatory information about used or + # assumed reference frame and rotation conventions + rotation_conventions(NXprocess): + doc: | + Mathematical conventions and materials-science-specific conventions + required for interpreting every collection of orientation data. + three_dimensional_rotation_handedness: + doc: | + Convention how a positive rotation angle is defined when viewing + from the end of the rotation unit vector towards its origin, + i.e. in accordance with convention 2 of + DOI: 10.1088/0965-0393/23/8/083501. + Counter_clockwise is equivalent to a right-handed choice. + Clockwise is equivalent to a left-handed choice. + enumeration: [undefined, counter_clockwise, clockwise] + rotation_convention: + doc: | + How are rotations interpreted into an orientation + according to convention 3 of + DOI: 10.1088/0965-0393/23/8/083501. + enumeration: [undefined, passive, active] + euler_angle_convention: + doc: | + How are Euler angles interpreted given that there are several + choices (e.g. ZXZ, XYZ, etc.) according to convention 4 of + DOI: 10.1088/0965-0393/23/8/083501. + The most frequently used convention is ZXZ which is based on + the work of H.-J. Bunge but other conventions are possible. + enumeration: [undefined, zxz] + axis_angle_convention: + doc: | + To which angular range is the rotation angle argument of an + axis-angle pair parameterization constrained according to + convention 5 of DOI: 10.1088/0965-0393/23/8/083501. + enumeration: [undefined, rotation_angle_on_interval_zero_to_pi] + orientation_parameterization_sign_convention: + doc: | + Which sign convention is followed when converting orientations + between different parameterizations/representations according + to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. + enumeration: [undefined, p_plus_one, p_minus_one] + processing_reference_frame(NXprocess): + doc: | + Details about eventually relevant named directions that may + give reasons for anisotropies. The classical example is cold-rolling + where one has to specify which directions (rolling, transverse, and normal) + align how with the direction of the base vectors of the sample_reference_frame. + reference_frame_type: + doc: | + Type of coordinate system and reference frame according to + convention 1 of DOI: 10.1088/0965-0393/23/8/083501. + enumeration: [undefined, right_handed_cartesian, left_handed_cartesian] + xaxis_direction: + doc: | + Direction of the positively pointing x-axis base vector of + the processing_reference_frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. + enumeration: [undefined, north, east, south, west, in, out] + xaxis_alias: + doc: | + Name or alias assigned to the x-axis base vector, e.g. rolling direction. + yaxis_direction: + doc: | + Direction of the positively pointing y-axis base vector of + the processing_reference_frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + yaxis_alias: + doc: | + Name or alias assigned to the y-axis base vector, e.g. transverse direction. + zaxis_direction: + doc: | + Direction of the positively pointing z-axis base vector of + the processing_reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + zaxis_alias: + doc: | + Name or alias assigned to the z-axis base vector, e.g. normal direction. + origin: + doc: | + Location of the origin of the processing_reference_frame. + This specifies the location Xp = 0, Yp = 0, Zp = 0. + Assume regions-of-interest in this reference frame form a + rectangle or cuboid. + Edges are interpreted by inspecting the direction of their + outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] + sample_reference_frame(NXprocess): + doc: | + Details about the sample/specimen reference frame. + reference_frame_type: + doc: | + Type of coordinate system and reference frame according to + convention 1 of DOI: 10.1088/0965-0393/23/8/083501. + The reference frame for the sample surface reference is used for + identifying positions on a (virtual) image which is formed by + information collected from an electron beam scanning the + sample surface. We assume the configuration is inspected by + looking towards the sample surface from a position that is + located behind the detector. + Reference DOI: 10.1016/j.matchar.2016.04.008 + The sample surface reference frame has coordinates Xs, Ys, Zs. + In three dimensions these coordinates are not necessarily + located on the surface of the sample as there are multiple + faces/sides of the sample. Most frequently though the coordinate + system here is used to define the surface which the electron + beam scans. + enumeration: [undefined, right_handed_cartesian, left_handed_cartesian] + xaxis_direction: + doc: | + Direction of the positively pointing x-axis base vector of + the sample surface reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + enumeration: [undefined, north, east, south, west, in, out] + yaxis_direction: + doc: | + Direction of the positively pointing y-axis base vector of + the sample surface reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + zaxis_direction: + doc: | + Direction of the positively pointing z-axis base vector of + the sample surface reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + origin: + doc: | + Location of the origin of the sample surface reference frame. + This specifies the location Xs = 0, Ys = 0, Zs = 0. + Assume regions-of-interest in this reference frame form a + rectangle or cuboid. + Edges are interpreted by inspecting the direction of their + outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] + detector_reference_frame(NXprocess): + doc: | + Details about the detector reference frame. + reference_frame_type: + doc: | + Type of coordinate system/reference frame used for + identifying positions in detector space Xd, Yd, Zd, + according to DOI: 10.1016/j.matchar.2016.04.008. + enumeration: [undefined, right_handed_cartesian, left_handed_cartesian] + xaxis_direction: + doc: | + Direction of the positively pointing x-axis base vector of + the detector space reference frame. We assume the configuration + is inspected by looking towards the sample surface from a + position that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + enumeration: [undefined, north, east, south, west, in, out] + yaxis_direction: + doc: | + Direction of the positively pointing y-axis base vector of + the detector space reference frame. We assume the configuration + is inspected by looking towards the sample surface from a + position that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + zaxis_direction: + doc: | + Direction of the positively pointing z-axis base vector of + the detector space reference frame. We assume the configuration + is inspected by looking towards the sample surface from a + position that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + origin: + doc: | + Where is the origin of the detector space reference + frame located. This is the location of Xd = 0, Yd = 0, Zd = 0. + Assume regions-of-interest in this reference frame form a + rectangle or cuboid. + Edges are interpreted by inspecting the direction of their + outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] + gnomonic_projection_reference_frame(NXprocess): + doc: | + Details about the gnomonic projection reference frame. + reference_frame_type: + doc: | + Type of coordinate system/reference frame used for identifying + positions in the gnomonic projection space Xg, Yg, Zg + according to DOI: 10.1016/j.matchar.2016.04.008. + enumeration: [undefined, right_handed_cartesian, left_handed_cartesian] + xaxis_direction: + doc: | + Direction of the positively pointing "gnomomic" x-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + enumeration: [undefined, north, east, south, west, in, out] + yaxis_direction: + doc: | + Direction of the positively pointing "gnomomic" y-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + zaxis_direction: + doc: | + Direction of the positively pointing "gnomomic" z-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + origin: + doc: | + Is the origin of the gnomonic coordinate system located + where we assume the location of the pattern centre. + This is the location Xg = 0, Yg = 0, Zg = 0 according to + reference DOI: 10.1016/j.matchar.2016.04.008. + enumeration: [undefined, in_the_pattern_centre] + pattern_centre(NXprocess): + doc: | + Details about the definition of the pattern centre + as a special point in the gnomonic projection reference frame. + xaxis_boundary_convention: + doc: | + From which border of the EBSP (in the detector reference frame) + is the pattern centre's x-position (PCx) measured? + Keywords assume the region-of-interest is defined by + a rectangle. We observe this rectangle and inspect the + direction of the outer-unit normals to the edges of + this rectangle. + enumeration: [undefined, top, right, bottom, left] + xaxis_normalization_direction: + doc: | + In which direction are positive values for PCx measured from + the specified boundary. Keep in mind that the gnomonic space + is in virtually all cases embedded in the detector space. + Specifically, the XgYg plane is defined such that it is + embedded/laying inside the XdYd plane (of the detector + reference frame). + When the normalization direction is the same as e.g. the + detector x-axis direction, we state that we effectively + normalize in fractions of the width of the detector. + + The issue with terms like width and height is that these + degenerate if the detector region-of-interest is square-shaped. + This is why we should better avoid talking about width and height but + state how we would measure distances practically with a ruler and + how we then measure positive distances. + enumeration: [undefined, north, east, south, west] + yaxis_boundary_convention: + doc: | + From which border of the EBSP (in the detector reference + frame) is the pattern centre's y-position (PCy) measured? + For further details inspect the help button of + xaxis_boundary_convention. + enumeration: [undefined, top, right, bottom, left] + yaxis_normalization_direction: + doc: | + In which direction are positive values for PCy measured from + the specified boundary. + For further details inspect the help button of + xaxis_normalization_direction. + enumeration: [undefined, north, east, south, west] + + # distance_convention: + # doc: | + # How is the third of the three pattern centre parameter values, + # the (distance) parameter DD, normalized. Which convention + # is followed. We are aware that specifying one of the options here + # also implicitly comes with conventions for some of the parameter + # requested in this ELN. For now we would rather like to ask + # the users though to be specific also to learn how such an ELN + # will be used in practice. + # enumeration: [undefined, Bruker, JEOL, FEI, Oxford] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 619b2761b3b57179eeb33499b763adc93d4074004e936dc4460168d914fe9502 +# +# +# +# +# +# +# Conventions for rotations and coordinate systems to interpret EBSD data. +# +# This is the main issue which currently is not in all cases documented +# and thus limits the interoperability and value of collected EBSD data. +# Not communicating EBSD data with such contextual pieces of information +# and the use of file formats which do not store this information is the +# key unsolved problem. +# +# +# +# +# Mathematical conventions and materials-science-specific conventions +# required for interpreting every collection of orientation data. +# +# +# +# Convention how a positive rotation angle is defined when viewing +# from the end of the rotation unit vector towards its origin, +# i.e. in accordance with convention 2 of +# DOI: 10.1088/0965-0393/23/8/083501. +# Counter_clockwise is equivalent to a right-handed choice. +# Clockwise is equivalent to a left-handed choice. +# +# +# +# +# +# +# +# +# +# How are rotations interpreted into an orientation +# according to convention 3 of +# DOI: 10.1088/0965-0393/23/8/083501. +# +# +# +# +# +# +# +# +# +# How are Euler angles interpreted given that there are several +# choices (e.g. ZXZ, XYZ, etc.) according to convention 4 of +# DOI: 10.1088/0965-0393/23/8/083501. +# The most frequently used convention is ZXZ which is based on +# the work of H.-J. Bunge but other conventions are possible. +# +# +# +# +# +# +# +# +# To which angular range is the rotation angle argument of an +# axis-angle pair parameterization constrained according to +# convention 5 of DOI: 10.1088/0965-0393/23/8/083501. +# +# +# +# +# +# +# +# +# Which sign convention is followed when converting orientations +# between different parameterizations/representations according +# to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. +# +# +# +# +# +# +# +# +# +# +# Details about eventually relevant named directions that may +# give reasons for anisotropies. The classical example is cold-rolling +# where one has to specify which directions (rolling, transverse, and normal) +# align how with the direction of the base vectors of the sample_reference_frame. +# +# +# +# Type of coordinate system and reference frame according to +# convention 1 of DOI: 10.1088/0965-0393/23/8/083501. +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing x-axis base vector of +# the processing_reference_frame. We assume the configuration +# is inspected by looking towards the sample surface from a position +# that is located behind the detector. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Name or alias assigned to the x-axis base vector, e.g. rolling direction. +# +# +# +# +# Direction of the positively pointing y-axis base vector of +# the processing_reference_frame. We assume the configuration +# is inspected by looking towards the sample surface from a position +# that is located behind the detector. For further information consult +# also the help info for the xaxis_direction field. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Name or alias assigned to the y-axis base vector, e.g. transverse direction. +# +# +# +# +# Direction of the positively pointing z-axis base vector of +# the processing_reference frame. We assume the configuration +# is inspected by looking towards the sample surface from a position +# that is located behind the detector. For further information consult +# also the help info for the xaxis_direction field. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Name or alias assigned to the z-axis base vector, e.g. normal direction. +# +# +# +# +# Location of the origin of the processing_reference_frame. +# This specifies the location Xp = 0, Yp = 0, Zp = 0. +# Assume regions-of-interest in this reference frame form a +# rectangle or cuboid. +# Edges are interpreted by inspecting the direction of their +# outer unit normals (which point either parallel or antiparallel) +# along respective base vector direction of the reference frame. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Details about the sample/specimen reference frame. +# +# +# +# Type of coordinate system and reference frame according to +# convention 1 of DOI: 10.1088/0965-0393/23/8/083501. +# The reference frame for the sample surface reference is used for +# identifying positions on a (virtual) image which is formed by +# information collected from an electron beam scanning the +# sample surface. We assume the configuration is inspected by +# looking towards the sample surface from a position that is +# located behind the detector. +# Reference DOI: 10.1016/j.matchar.2016.04.008 +# The sample surface reference frame has coordinates Xs, Ys, Zs. +# In three dimensions these coordinates are not necessarily +# located on the surface of the sample as there are multiple +# faces/sides of the sample. Most frequently though the coordinate +# system here is used to define the surface which the electron +# beam scans. +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing x-axis base vector of +# the sample surface reference frame. We assume the configuration +# is inspected by looking towards the sample surface from a position +# that is located behind the detector. +# Different tools assume that different strategies can be used +# and are perceived as differently convenient to enter +# details about coordinate system definitions. In this ELN users +# have to possibility to fill in what they assume is sufficient to +# define the coordinate system directions unambiguously. +# Software which works with this user input needs to offer parsing +# capabilities which detect conflicting input and warn accordingly. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing y-axis base vector of +# the sample surface reference frame. We assume the configuration +# is inspected by looking towards the sample surface from a position +# that is located behind the detector. For further information consult +# also the help info for the xaxis_direction field. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing z-axis base vector of +# the sample surface reference frame. We assume the configuration +# is inspected by looking towards the sample surface from a position +# that is located behind the detector. For further information consult +# also the help info for the xaxis_direction field. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Location of the origin of the sample surface reference frame. +# This specifies the location Xs = 0, Ys = 0, Zs = 0. +# Assume regions-of-interest in this reference frame form a +# rectangle or cuboid. +# Edges are interpreted by inspecting the direction of their +# outer unit normals (which point either parallel or antiparallel) +# along respective base vector direction of the reference frame. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Details about the detector reference frame. +# +# +# +# Type of coordinate system/reference frame used for +# identifying positions in detector space Xd, Yd, Zd, +# according to DOI: 10.1016/j.matchar.2016.04.008. +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing x-axis base vector of +# the detector space reference frame. We assume the configuration +# is inspected by looking towards the sample surface from a +# position that is located behind the detector. +# Different tools assume that different strategies can be used +# and are perceived as differently convenient to enter +# details about coordinate system definitions. In this ELN users +# have to possibility to fill in what they assume is sufficient to +# define the coordinate system directions unambiguously. +# Software which works with this user input needs to offer parsing +# capabilities which detect conflicting input and warn accordingly. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing y-axis base vector of +# the detector space reference frame. We assume the configuration +# is inspected by looking towards the sample surface from a +# position that is located behind the detector. +# For further information consult also the help info for the +# xaxis_direction field. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing z-axis base vector of +# the detector space reference frame. We assume the configuration +# is inspected by looking towards the sample surface from a +# position that is located behind the detector. +# For further information consult also the help info for the +# xaxis_direction field. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Where is the origin of the detector space reference +# frame located. This is the location of Xd = 0, Yd = 0, Zd = 0. +# Assume regions-of-interest in this reference frame form a +# rectangle or cuboid. +# Edges are interpreted by inspecting the direction of their +# outer unit normals (which point either parallel or antiparallel) +# along respective base vector direction of the reference frame. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Details about the gnomonic projection reference frame. +# +# +# +# Type of coordinate system/reference frame used for identifying +# positions in the gnomonic projection space Xg, Yg, Zg +# according to DOI: 10.1016/j.matchar.2016.04.008. +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing "gnomomic" x-axis base +# vector when viewing how the diffraction pattern looks on the +# detector screen. We assume the configuration is inspected by +# looking towards the sample surface from a position +# that is located behind the detector. +# Different tools assume that different strategies can be used +# and are perceived as differently convenient to enter +# details about coordinate system definitions. In this ELN users +# have to possibility to fill in what they assume is sufficient to +# define the coordinate system directions unambiguously. +# Software which works with this user input needs to offer parsing +# capabilities which detect conflicting input and warn accordingly. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing "gnomomic" y-axis base +# vector when viewing how the diffraction pattern looks on the +# detector screen. We assume the configuration is inspected by +# looking towards the sample surface from a position +# that is located behind the detector. +# For further information consult also the help info for the +# xaxis_direction field. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Direction of the positively pointing "gnomomic" z-axis base +# vector when viewing how the diffraction pattern looks on the +# detector screen. We assume the configuration is inspected by +# looking towards the sample surface from a position +# that is located behind the detector. +# For further information consult also the help info for the +# xaxis_direction field. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Is the origin of the gnomonic coordinate system located +# where we assume the location of the pattern centre. +# This is the location Xg = 0, Yg = 0, Zg = 0 according to +# reference DOI: 10.1016/j.matchar.2016.04.008. +# +# +# +# +# +# +# +# +# +# Details about the definition of the pattern centre +# as a special point in the gnomonic projection reference frame. +# +# +# +# From which border of the EBSP (in the detector reference frame) +# is the pattern centre's x-position (PCx) measured? +# Keywords assume the region-of-interest is defined by +# a rectangle. We observe this rectangle and inspect the +# direction of the outer-unit normals to the edges of +# this rectangle. +# +# +# +# +# +# +# +# +# +# +# +# In which direction are positive values for PCx measured from +# the specified boundary. Keep in mind that the gnomonic space +# is in virtually all cases embedded in the detector space. +# Specifically, the XgYg plane is defined such that it is +# embedded/laying inside the XdYd plane (of the detector +# reference frame). +# When the normalization direction is the same as e.g. the +# detector x-axis direction, we state that we effectively +# normalize in fractions of the width of the detector. +# +# The issue with terms like width and height is that these +# degenerate if the detector region-of-interest is square-shaped. +# This is why we should better avoid talking about width and height but +# state how we would measure distances practically with a ruler and +# how we then measure positive distances. +# +# +# +# +# +# +# +# +# +# +# +# From which border of the EBSP (in the detector reference +# frame) is the pattern centre's y-position (PCy) measured? +# For further details inspect the help button of +# xaxis_boundary_convention. +# +# +# +# +# +# +# +# +# +# +# +# In which direction are positive values for PCy measured from +# the specified boundary. +# For further details inspect the help button of +# xaxis_normalization_direction. +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXem_ebsd_crystal_structure_model.yaml b/contributed_definitions/nyaml/NXem_ebsd_crystal_structure_model.yaml new file mode 100644 index 0000000000..4efc224d88 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_ebsd_crystal_structure_model.yaml @@ -0,0 +1,389 @@ +category: base +doc: | + Crystal structure phase models used for indexing Kikuchi pattern. + + This base class contains key metadata relevant to every physical + kinematic or dynamic diffraction model to be used for simulating + Kikuchi diffraction pattern. + The actual indexing of Kikuchi pattern however maybe use different + algorithms which build on these simulation results but evaluate different + workflows of comparing simulated and measured Kikuchi pattern to make + suggestions which orientation is the most likely (if any) for each + scan point investigated. + + Traditionally Hough transform based indexing has been the most frequently + used algorithm. More and more dictionary based alternatives are used. + Either way both algorithm need a crystal structure model. +symbols: + n_hkl: | + Number of reflectors (Miller crystallographic plane triplets). + n_pos: | + Number of atom positions. +type: group +NXem_ebsd_crystal_structure_model(NXobject): + + # for EBSD specifically we need to know the assumed crystal structure + # with assumed statistically distributed atoms, i.e. structure and atom + # positions + crystallographic_database_identifier: + doc: | + Identifier of an entry from crystallographic_database which was used + for creating this structure model. + crystallographic_database: + doc: | + Name of the crystallographic database to resolve + crystallographic_database_identifier e.g. COD or others. + + # defined using which convention? + unit_cell_abc(NX_FLOAT): + unit: NX_LENGTH + doc: | + Crystallography unit cell parameters a, b, and c. + dimensions: + rank: 1 + dim: [[1, 3]] + + # defined using which convention? + unit_cell_alphabetagamma(NX_FLOAT): + unit: NX_ANGLE + doc: | + Crystallography unit cell parameters alpha, beta, and gamma. + dimensions: + rank: 1 + dim: [[1, 3]] + unit_cell_volume(NX_FLOAT): + unit: NX_VOLUME + doc: | + Volume of the unit cell + space_group: + doc: | + Crystallographic space group + + # add enumeration all possible + is_centrosymmetric(NX_BOOLEAN): + doc: | + True if space group is considered a centrosymmetric one. + False if space group is considered a non-centrosymmetric one. + Centrosymmetric has all types and combinations of symmetry elements + (translation, rotational axis, mirror planes, center of inversion) + Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). + Chiral compared to non-centrosymmetric is constrained (no mirror planes). + is_chiral(NX_BOOLEAN): + doc: | + True if space group is considered a chiral one. + False if space group is consider a non-chiral one. + laue_group: + doc: | + Laue group + + # add enumeration all possible + point_group: + doc: | + Point group using International Notation. + + # add enumeration all possible + unit_cell_class: + doc: | + Crystal system + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + phase_identifier(NX_UINT): + unit: NX_UNITLESS + doc: | + Numeric identifier for each phase. + The value 0 is reserved for the unknown phase essentially representing the + null-model that no phase model was sufficiently significantly confirmed. + Consequently, the value 0 must not be used as a phase_identifier. + phase_name: + doc: | + Name of the phase/alias. + atom_identifier: + doc: | + Labels for each atom position + dimensions: + rank: 1 + dim: [[1, n_pos]] + atom(NX_UINT): + unit: NX_UNITLESS + doc: | + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) `_ + dimensions: + rank: 1 + dim: [[1, n_pos]] + atom_positions(NX_FLOAT): + unit: NX_LENGTH + doc: | + Atom positions x, y, z. + dimensions: + rank: 2 + dim: [[1, n_pos], [2, 3]] + + # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory + # to describe the simulated Kikuchi pattern generated from such a model + atom_occupancy(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + Relative occupancy of the atom position. + dimensions: + rank: 1 + dim: [[1, n_pos]] + number_of_planes(NX_UINT): + unit: NX_UNITLESS + doc: | + How many reflectors are distinguished. Value has to be n_hkl. + + # Miller indices :math:`(hkl)[uvw]`. + plane_miller(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Miller indices :math:`(hkl)`. + dimensions: + rank: 2 + dim: [[1, n_hkl], [2, 3]] + dspacing(NX_FLOAT): + unit: NX_LENGTH + doc: | + D-spacing. + dimensions: + rank: 1 + dim: [[1, n_hkl]] + relative_intensity(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + Relative intensity of the signal for the plane. + dimensions: + rank: 1 + dim: [[1, n_hkl]] + + # here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) + # can give some good suggestions on how to improve and ideally make even + # more general this section + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 8e34c264fb504d9b2c1da81927f6e381567238ced8ce6e0ac8a540b33d348599 +# +# +# +# +# +# +# +# Number of reflectors (Miller crystallographic plane triplets). +# +# +# +# +# Number of atom positions. +# +# +# +# +# Crystal structure phase models used for indexing Kikuchi pattern. +# +# This base class contains key metadata relevant to every physical +# kinematic or dynamic diffraction model to be used for simulating +# Kikuchi diffraction pattern. +# The actual indexing of Kikuchi pattern however maybe use different +# algorithms which build on these simulation results but evaluate different +# workflows of comparing simulated and measured Kikuchi pattern to make +# suggestions which orientation is the most likely (if any) for each +# scan point investigated. +# +# Traditionally Hough transform based indexing has been the most frequently +# used algorithm. More and more dictionary based alternatives are used. +# Either way both algorithm need a crystal structure model. +# +# +# +# +# Identifier of an entry from crystallographic_database which was used +# for creating this structure model. +# +# +# +# +# Name of the crystallographic database to resolve +# crystallographic_database_identifier e.g. COD or others. +# +# +# +# +# +# Crystallography unit cell parameters a, b, and c. +# +# +# +# +# +# +# +# +# Crystallography unit cell parameters alpha, beta, and gamma. +# +# +# +# +# +# +# +# Volume of the unit cell +# +# +# +# +# Crystallographic space group +# +# +# +# +# +# True if space group is considered a centrosymmetric one. +# False if space group is considered a non-centrosymmetric one. +# Centrosymmetric has all types and combinations of symmetry elements +# (translation, rotational axis, mirror planes, center of inversion) +# Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). +# Chiral compared to non-centrosymmetric is constrained (no mirror planes). +# +# +# +# +# True if space group is considered a chiral one. +# False if space group is consider a non-chiral one. +# +# +# +# +# Laue group +# +# +# +# +# +# Point group using International Notation. +# +# +# +# +# +# Crystal system +# +# +# +# +# +# +# +# +# +# +# +# +# +# Numeric identifier for each phase. +# The value 0 is reserved for the unknown phase essentially representing the +# null-model that no phase model was sufficiently significantly confirmed. +# Consequently, the value 0 must not be used as a phase_identifier. +# +# +# +# +# Name of the phase/alias. +# +# +# +# +# Labels for each atom position +# +# +# +# +# +# +# +# The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` +# the number of protons and :math:`N` the number of neutrons +# of each isotope respectively. Z and N have to be 8-bit unsigned integers. +# For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ +# +# +# +# +# +# +# +# Atom positions x, y, z. +# +# +# +# +# +# +# +# +# +# Relative occupancy of the atom position. +# +# +# +# +# +# +# +# How many reflectors are distinguished. Value has to be n_hkl. +# +# +# +# +# +# Miller indices :math:`(hkl)`. +# +# +# +# +# +# +# +# +# D-spacing. +# +# +# +# +# +# +# +# Relative intensity of the signal for the plane. +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXenergydispersion.yaml b/contributed_definitions/nyaml/NXenergydispersion.yaml new file mode 100644 index 0000000000..476e8af2b3 --- /dev/null +++ b/contributed_definitions/nyaml/NXenergydispersion.yaml @@ -0,0 +1,142 @@ +category: base +doc: | + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. +type: group +NXenergydispersion(NXobject): + scheme(NX_CHAR): + doc: | + Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, + mirror, retarding grid, etc. + pass_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + Energy of the electrons on the mean path of the analyser. Pass energy for + hemispherics, drift energy for tofs. + center_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + Center of the energy window + energy_interval(NX_FLOAT): + unit: NX_ENERGY + doc: | + The interval of transmitted energies. It can be two different things depending + on whether the scan is fixed or swept. With a fixed scan it is a 2 vector + containing the extrema of the transmitted energy window (smaller number first). + With a swept scan of m steps it is a 2xm array of windows one for each + measurement point. + (NXaperture): + doc: | + Size, position and shape of a slit in dispersive analyzer, e.g. entrance and + exit slits. + diameter(NX_FLOAT): + unit: NX_LENGTH + doc: | + Diameter of the dispersive orbit + energy_scan_mode(NX_CHAR): + doc: | + Way of scanning the energy axis (fixed or sweep). + enumeration: [fixed, sweep] + tof_distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + Length of the tof drift electrode + (NXdeflector): + doc: | + Deflectors in the energy dispersive section + (NXlens_em): + doc: | + Individual lenses in the energy dispersive section + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 165eadae7ad3081364c89bc4229eb2a01d197b0706e2c663e07201dc088a5069 +# +# +# +# +# +# Subclass of NXelectronanalyser to describe the energy dispersion section of a +# photoelectron analyser. +# +# +# +# Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, +# mirror, retarding grid, etc. +# +# +# +# +# Energy of the electrons on the mean path of the analyser. Pass energy for +# hemispherics, drift energy for tofs. +# +# +# +# +# Center of the energy window +# +# +# +# +# The interval of transmitted energies. It can be two different things depending +# on whether the scan is fixed or swept. With a fixed scan it is a 2 vector +# containing the extrema of the transmitted energy window (smaller number first). +# With a swept scan of m steps it is a 2xm array of windows one for each +# measurement point. +# +# +# +# +# Size, position and shape of a slit in dispersive analyzer, e.g. entrance and +# exit slits. +# +# +# +# +# Diameter of the dispersive orbit +# +# +# +# +# Way of scanning the energy axis (fixed or sweep). +# +# +# +# +# +# +# +# +# Length of the tof drift electrode +# +# +# +# +# Deflectors in the energy dispersive section +# +# +# +# +# Individual lenses in the energy dispersive section +# +# +# diff --git a/contributed_definitions/nyaml/NXevent_data_em.yaml b/contributed_definitions/nyaml/NXevent_data_em.yaml new file mode 100644 index 0000000000..3866f3e424 --- /dev/null +++ b/contributed_definitions/nyaml/NXevent_data_em.yaml @@ -0,0 +1,425 @@ +category: base +doc: | + Metadata and settings of an electron microscope for scans and images. + + The need for such a structuring of data is evident from the fact that + electron microscopes are dynamic. Oftentimes it suffices to calibrate the + instrument at the start of the session. Subsequently, data (images, spectra, etc.) + can be collected. Users may wish to take only a single scan or image and + complete their microscope session; however + + frequently users are working much longer at the microscope, recalibrate and take + multiple data items (scans, images, spectra). Each item comes with own detector + and eventually on-the-fly processing settings and calibrations. + + For the single data item use case one may argue that the need for an additional + grouping is redundant. Instead, the metadata could equally be stored inside + the respective groups of the top-level mandatory NXinstrument group. + On the flip side, even for a session with a single image, it would also not + harm to nest the data. + + In fact, oftentimes scientists feel that there is a need to store details + about eventual drift of the specimen in its holder (if such data is available) + or record changes to the lens excitations or apertures used and/or changed. + Although current microscopes are usually equipped with stabilization + systems for many of the individual components, it can still be useful + to store time-dependent data in detail. + + Another reason if not a need for having more finely granularizable options for + storing time-dependent data, is that over the course of a session one may + reconfigure the microscope. What is a reconfiguration? This could be the + change of an aperture mode because a scientist may first collect an image + with some aperture and then pick a different value and continue. + As the aperture affects the electron beam, it will affect the system. + + Let aside for a moment the technology and business models, an EM could be + monitored (and will likely become so more in the future) for streaming out + spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied + and the specimen repositioned. + + Some snapshot or integrated data from this stream are relevant for understanding + signal genesis and electron/ion-beam-sample interaction (paths). In such a generic + case it might be necessary to sync these streaming data with those intervals + in time when specific measurements are taken (spectra collected, + images taken, diffraction images indexed on-the-fly). + + Therefore, both the instrument and specimen should always be considered as dynamic. + Scientists often report or feel (difficult to quantify) observations that + microscopes *perform differently* across sessions, without sometimes being + able to identify clear root causes. Users of the instrument may consider + such conditions impractical, or *too poor* and thus either abort their session + or try to bring the microscope first into a state where conditions are considered + more stable, better, or of some whatever high enough quality to reuse + data collection. + + In all these cases it is practical to have a mechanism how time-dependent data + of the instrument state can be stored and documented in a interoperable way. + Where should these data be stored? With NeXus these data should not only be + stored in the respective instrument component groups of the top-level NXinstrument. + The reason is that this group should be reserved for as stable as possible + quantities which do not change over the session. Thereby we can avoid to store + repetitively that there is a certain gun or detector available but just store + the changes. This is exactly what the em_lab group is for inside NXevent_data_em. + + Ideally, NXevent_data_em are equipped with a start_time and end_time + to represent a time interval (remind the idea of the instrument state stream) + during which the scientist considered (or practically has to consider) + the microscope (especially ebeam and specimen) as stable enough. + + Arguably it is oftentimes tricky to specify a clear time interval when the + microscope is stable enough. Take for instance the acquisition of an image + or spectra stack. It is not fully possible (technically) to avoid that even + within a single image instabilities of the beam are faced and drift occurs. + Maybe in many cases this these instabilities are irrelevant but does this + warrant to create a data schema where either the microscope state can only + be stored very coarsely or one is forced to store it very finely? + + This is a question of how one wishes to granularize pieces of information. + A possible solution is to consider each probed position, i.e. point in time + when the beam was not blanked and thus when the beam illuminates a portion of + the material, i.e. the interaction volume, whose signal contributions are then + counted by the one or multiple detector(s) as per pixel- or per voxel signal + in the region-of-interest. + NXevent_data_em in combination with the NXem application definition + allows researchers to document this. Noteworty to mention is that we understand + that in many cases realizing such a fine temporal and logical granularization + and data collection is hard to achieve in practice. + + A frequently made choice, mainly for convenience, is that drift and scan distortions + are considered a feature or inaccuracy of the image and/or spectrum and thus + one de facto accepts that the microscope was not as stable as expected during + the acquisition of the image. We learn that the idea of a time interval + during the microscope session may be interpreted differently by different + users. Here we consider the choice to focus on images and spectra, and eventually + single position measurements as the smallest granularization level. + Which eventually may require to add optional NXprocess instances for respectively + collected data to describe the relevant distortions. Nevertheless, the distortions + are typically corrected for by numerical protocols. This fact warrants to + consider the distortion correction a computational workflow which can be + modelled as a chain of NXprocess instances each with own parameters. an own + A more detailed overview of such computational steps to cope with scan distortions + is available in the literature: + + * `C. Ophus et al. `_ + * `B. Berkels et al. `_ + * `L. Jones et al. `_ + + For specific simulation purposes, mainly in an effort to digitally repeat + or simulate the experiment, it is tempting to consider dynamics of the + instrument, implemented as time-dependent functional descriptions of + e.g. lens excitations, beam shape functions, trajectories of groups of + electrons, or detector noise models. + + For now the preferred strategy to handle these cases is through + customizations of the specific fields within NXevent_data_em instances. + + Another alternative could be to sample finer, eventually dissimilarly along + the time axi; however this may cause situations where an NXevent_data_em + instance does not contain specific measurements (i.e. images, spectra of + scientific relevance). + + In this case one should better go for a customized application definition + with a functional property description inside members (fields or groups) + in NXevent_data_em instances; or resort to a specific offspring application + definition of NXem which documents metadata for tracking explicitly electrons + (with ray-tracing based descriptors/computational geometry descriptors) + or tracking of wave bundles. + + This perspective on much more subtle time-dependent considerations of electron + microscopy can be advantageous also for storing details of time-dependent + additional components that are coupled to and/or synced with a microscope. + + Examples include cutting-edge experiments where the electron beam gets + coupled/excited by e.g. lasers. In this case, the laser unit should be + registered under the top-level NXinstrument section. Its spatio-temporal + details could be stored inside respective additional groups of the NXinstrument + though inside instances of here detailed NXevent_data_em. +type: group +NXevent_data_em(NXobject): + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval started. If the user wishes to specify an + interval of time that the snapshot should represent during which the instrument + was stable and configured using specific settings and calibrations, + the start_time is the start (left bound of the time interval) while + the end_time specifies the end (right bound) of the time interval. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval ended. + event_identifier: + doc: | + Reference to a specific state and setting of the microscope. + event_type: + doc: | + Which specific event/measurement type. Examples are: + + * In-lens/backscattered electron, usually has quadrants + * Secondary_electron, image, topography, fractography, overview images + * Backscattered_electron, image, Z or channeling contrast (ECCI) + * Bright_field, image, TEM + * Dark_field, image, crystal defects + * Annular dark field, image (medium- or high-angle), TEM + * Diffraction, image, TEM, or a comparable technique in the SEM + * Kikuchi, image, SEM EBSD and TEM diffraction + * X-ray spectra (point, line, surface, volume), composition EDS/EDX(S) + * Electron energy loss spectra for points, lines, surfaces, TEM + * Auger, spectrum, (low Z contrast element composition) + * Cathodoluminescence (optical spectra) + * Ronchigram, image, alignment utility specifically in TEM + * Chamber, e.g. TV camera inside the chamber, education purposes. + + This field may also be used for storing additional information about the event. + (NXimage_set): + (NXspectrum_set): + (NXinstrument): + (NXuser): + (NXinteraction_vol_em): + + # a collection of images take and group under this event + # NEW ISSUE: should this only be one instance for a given event? + # (NXimage_set_em_se): + # (NXimage_set_em_bse): + # (NXimage_set_em_ecci): + # (NXimage_set_em_bf): + # (NXimage_set_em_df): + # (NXimage_set_em_adf): + # (NXimage_set_em_kikuchi): + # (NXimage_set_em_diffrac): + # (NXspectrum_set_em_xray): + # (NXspectrum_set_em_eels): + # (NXspectrum_set_em_auger): + # (NXspectrum_set_em_cathodolum): + # (NXimage_set_em_ronchigram): + # (NXimage_set_em_chamber): + # a collection of specific details about state of the microscope + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e1f920846240b7fcddcb72c7ff92d370528612c709b0ca59c2bb0d8df5897dc6 +# +# +# +# +# +# Metadata and settings of an electron microscope for scans and images. +# +# The need for such a structuring of data is evident from the fact that +# electron microscopes are dynamic. Oftentimes it suffices to calibrate the +# instrument at the start of the session. Subsequently, data (images, spectra, etc.) +# can be collected. Users may wish to take only a single scan or image and +# complete their microscope session; however +# +# frequently users are working much longer at the microscope, recalibrate and take +# multiple data items (scans, images, spectra). Each item comes with own detector +# and eventually on-the-fly processing settings and calibrations. +# +# For the single data item use case one may argue that the need for an additional +# grouping is redundant. Instead, the metadata could equally be stored inside +# the respective groups of the top-level mandatory NXinstrument group. +# On the flip side, even for a session with a single image, it would also not +# harm to nest the data. +# +# In fact, oftentimes scientists feel that there is a need to store details +# about eventual drift of the specimen in its holder (if such data is available) +# or record changes to the lens excitations or apertures used and/or changed. +# Although current microscopes are usually equipped with stabilization +# systems for many of the individual components, it can still be useful +# to store time-dependent data in detail. +# +# Another reason if not a need for having more finely granularizable options for +# storing time-dependent data, is that over the course of a session one may +# reconfigure the microscope. What is a reconfiguration? This could be the +# change of an aperture mode because a scientist may first collect an image +# with some aperture and then pick a different value and continue. +# As the aperture affects the electron beam, it will affect the system. +# +# Let aside for a moment the technology and business models, an EM could be +# monitored (and will likely become so more in the future) for streaming out +# spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied +# and the specimen repositioned. +# +# Some snapshot or integrated data from this stream are relevant for understanding +# signal genesis and electron/ion-beam-sample interaction (paths). In such a generic +# case it might be necessary to sync these streaming data with those intervals +# in time when specific measurements are taken (spectra collected, +# images taken, diffraction images indexed on-the-fly). +# +# Therefore, both the instrument and specimen should always be considered as dynamic. +# Scientists often report or feel (difficult to quantify) observations that +# microscopes *perform differently* across sessions, without sometimes being +# able to identify clear root causes. Users of the instrument may consider +# such conditions impractical, or *too poor* and thus either abort their session +# or try to bring the microscope first into a state where conditions are considered +# more stable, better, or of some whatever high enough quality to reuse +# data collection. +# +# In all these cases it is practical to have a mechanism how time-dependent data +# of the instrument state can be stored and documented in a interoperable way. +# Where should these data be stored? With NeXus these data should not only be +# stored in the respective instrument component groups of the top-level NXinstrument. +# The reason is that this group should be reserved for as stable as possible +# quantities which do not change over the session. Thereby we can avoid to store +# repetitively that there is a certain gun or detector available but just store +# the changes. This is exactly what the em_lab group is for inside NXevent_data_em. +# +# Ideally, NXevent_data_em are equipped with a start_time and end_time +# to represent a time interval (remind the idea of the instrument state stream) +# during which the scientist considered (or practically has to consider) +# the microscope (especially ebeam and specimen) as stable enough. +# +# Arguably it is oftentimes tricky to specify a clear time interval when the +# microscope is stable enough. Take for instance the acquisition of an image +# or spectra stack. It is not fully possible (technically) to avoid that even +# within a single image instabilities of the beam are faced and drift occurs. +# Maybe in many cases this these instabilities are irrelevant but does this +# warrant to create a data schema where either the microscope state can only +# be stored very coarsely or one is forced to store it very finely? +# +# This is a question of how one wishes to granularize pieces of information. +# A possible solution is to consider each probed position, i.e. point in time +# when the beam was not blanked and thus when the beam illuminates a portion of +# the material, i.e. the interaction volume, whose signal contributions are then +# counted by the one or multiple detector(s) as per pixel- or per voxel signal +# in the region-of-interest. +# NXevent_data_em in combination with the NXem application definition +# allows researchers to document this. Noteworty to mention is that we understand +# that in many cases realizing such a fine temporal and logical granularization +# and data collection is hard to achieve in practice. +# +# A frequently made choice, mainly for convenience, is that drift and scan distortions +# are considered a feature or inaccuracy of the image and/or spectrum and thus +# one de facto accepts that the microscope was not as stable as expected during +# the acquisition of the image. We learn that the idea of a time interval +# during the microscope session may be interpreted differently by different +# users. Here we consider the choice to focus on images and spectra, and eventually +# single position measurements as the smallest granularization level. +# Which eventually may require to add optional NXprocess instances for respectively +# collected data to describe the relevant distortions. Nevertheless, the distortions +# are typically corrected for by numerical protocols. This fact warrants to +# consider the distortion correction a computational workflow which can be +# modelled as a chain of NXprocess instances each with own parameters. an own +# A more detailed overview of such computational steps to cope with scan distortions +# is available in the literature: +# +# * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ +# * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ +# * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ +# +# For specific simulation purposes, mainly in an effort to digitally repeat +# or simulate the experiment, it is tempting to consider dynamics of the +# instrument, implemented as time-dependent functional descriptions of +# e.g. lens excitations, beam shape functions, trajectories of groups of +# electrons, or detector noise models. +# +# For now the preferred strategy to handle these cases is through +# customizations of the specific fields within NXevent_data_em instances. +# +# Another alternative could be to sample finer, eventually dissimilarly along +# the time axi; however this may cause situations where an NXevent_data_em +# instance does not contain specific measurements (i.e. images, spectra of +# scientific relevance). +# +# In this case one should better go for a customized application definition +# with a functional property description inside members (fields or groups) +# in NXevent_data_em instances; or resort to a specific offspring application +# definition of NXem which documents metadata for tracking explicitly electrons +# (with ray-tracing based descriptors/computational geometry descriptors) +# or tracking of wave bundles. +# +# This perspective on much more subtle time-dependent considerations of electron +# microscopy can be advantageous also for storing details of time-dependent +# additional components that are coupled to and/or synced with a microscope. +# +# Examples include cutting-edge experiments where the electron beam gets +# coupled/excited by e.g. lasers. In this case, the laser unit should be +# registered under the top-level NXinstrument section. Its spatio-temporal +# details could be stored inside respective additional groups of the NXinstrument +# though inside instances of here detailed NXevent_data_em. +# +# +# +# ISO 8601 time code with local time zone offset to UTC information included +# when the snapshot time interval started. If the user wishes to specify an +# interval of time that the snapshot should represent during which the instrument +# was stable and configured using specific settings and calibrations, +# the start_time is the start (left bound of the time interval) while +# the end_time specifies the end (right bound) of the time interval. +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC information included +# when the snapshot time interval ended. +# +# +# +# +# Reference to a specific state and setting of the microscope. +# +# +# +# +# Which specific event/measurement type. Examples are: +# +# * In-lens/backscattered electron, usually has quadrants +# * Secondary_electron, image, topography, fractography, overview images +# * Backscattered_electron, image, Z or channeling contrast (ECCI) +# * Bright_field, image, TEM +# * Dark_field, image, crystal defects +# * Annular dark field, image (medium- or high-angle), TEM +# * Diffraction, image, TEM, or a comparable technique in the SEM +# * Kikuchi, image, SEM EBSD and TEM diffraction +# * X-ray spectra (point, line, surface, volume), composition EDS/EDX(S) +# * Electron energy loss spectra for points, lines, surfaces, TEM +# * Auger, spectrum, (low Z contrast element composition) +# * Cathodoluminescence (optical spectra) +# * Ronchigram, image, alignment utility specifically in TEM +# * Chamber, e.g. TV camera inside the chamber, education purposes. +# +# This field may also be used for storing additional information about the event. +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXevent_data_em_set.yaml b/contributed_definitions/nyaml/NXevent_data_em_set.yaml new file mode 100644 index 0000000000..70147d8b36 --- /dev/null +++ b/contributed_definitions/nyaml/NXevent_data_em_set.yaml @@ -0,0 +1,44 @@ +category: base +doc: | + Container to hold NXevent_data_em instances of an electron microscope session. + + An event is a time interval during which the microscope was configured, + considered stable, and used for characterization. +type: group +NXevent_data_em_set(NXobject): + (NXevent_data_em): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 43012f9bcf4070d297318882afa6bb8afb9bd3e3c7c1b847c489bdb73ca7472c +# +# +# +# +# +# Container to hold NXevent_data_em instances of an electron microscope session. +# +# An event is a time interval during which the microscope was configured, +# considered stable, and used for characterization. +# +# +# diff --git a/contributed_definitions/nyaml/NXfabrication.yaml b/contributed_definitions/nyaml/NXfabrication.yaml new file mode 100644 index 0000000000..62e2fedcb9 --- /dev/null +++ b/contributed_definitions/nyaml/NXfabrication.yaml @@ -0,0 +1,75 @@ +category: base +doc: | + Details about a component as defined by its manufacturer. +type: group +NXfabrication(NXobject): + vendor: + doc: | + Company name of the manufacturer. + model: + doc: | + Version or model of the component named by the manufacturer. + identifier: + doc: | + Ideally, (globally) unique persistent identifier, i.e. + a serial number or hash identifier of the component. + capability: + doc: | + Free-text list with eventually multiple terms of + functionalities which the component offers. + + # NEW ISSUE: Define a bag of controlled words and use only these. Examples are Feg, Astar, OmegaFilter. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 133eb1373b25af6bd05ca17ceeab4a0de2cf663af86b16420411f38bcedc59ab +# +# +# +# +# +# Details about a component as defined by its manufacturer. +# +# +# +# Company name of the manufacturer. +# +# +# +# +# Version or model of the component named by the manufacturer. +# +# +# +# +# Ideally, (globally) unique persistent identifier, i.e. +# a serial number or hash identifier of the component. +# +# +# +# +# Free-text list with eventually multiple terms of +# functionalities which the component offers. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXfiber.yaml b/contributed_definitions/nyaml/NXfiber.yaml new file mode 100644 index 0000000000..d3f686f9d9 --- /dev/null +++ b/contributed_definitions/nyaml/NXfiber.yaml @@ -0,0 +1,358 @@ +category: base +doc: | + An optical fiber, e.g. glass fiber. + + Specify the quantities that define the fiber. Fiber optics are described in + detail [here](https://www.photonics.com/Article.aspx?AID=25151&PID=4), for + example. +symbols: + N_spectrum_core: | + Length of the spectrum vector (e.g. wavelength or energy) for which the + refractive index of the core material is given. + N_spectrum_clad: | + Length of the spectrum vector (e.g. wavelength or energy) for which the + refractive index of the cladding material is given. + N_spectrum_attenuation: | + Length of the spectrum vector (e.g. wavelength or energy) for which the + attenuation curve is given. + +# A draft of a new base class to describe an optical fiber (e.g. glass fiber) +type: group +NXfiber(NXobject): + description: + exists: recommended + doc: | + Descriptive name or brief description of the fiber, e.g. by stating its + dimension. The dimension of a fiber can be given as 60/100/200 which + refers to a core diameter of 60 micron, a clad diameter of 100 micron, + and a coating diameter of 200 micron. + type: + doc: | + Type/mode of the fiber. Modes of fiber transmission are shown in + Fig. 5 [here](https://www.photonics.com/Article.aspx?AID=25151&PID=4). + enumeration: [single mode, multimode graded index, multimode step index] + dispersion_type: + doc: | + Type of dispersion. + enumeration: [modal, material, chromatic] + dispersion(NX_FLOAT): + unit: NX_TIME + doc: | + Spectrum-dependent (or refractive index-dependent) dispersion of the + fiber. Specify in ps/nm*km. + dimensions: + rank: 1 + dim: [[1, N_spectrum_core]] + core(NXsample): + doc: | + Core of the fiber, i.e. the part of the fiber which transmits the light. + core_material: + doc: | + Specify the material of the core of the fiber. + core_diameter(NX_FLOAT): + unit: NX_LENGTH + doc: | + Core diameter of the fiber (e.g. given in micrometer). + core_index_of_refraction(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Complex index of refraction of the fiber. Specify at given wavelength + (or energy, wavenumber etc.) values. + dimensions: + rank: 2 + dim: [[1, 2], [2, N_spectrum_core]] + cladding(NXsample): + doc: | + Core of the fiber, i.e. the part of the fiber which transmits the light. + clad_material: + doc: | + Specify the material of the core of the fiber. + clad_diameter(NX_FLOAT): + unit: NX_LENGTH + doc: | + Clad diameter of the fiber (e.g. given in micrometer). + clad_index_of_refraction(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Complex index of refraction of the fiber. Specify at given wavelength + (or energy, wavenumber etc.) values. + dimensions: + rank: 2 + dim: [[1, 2], [2, N_spectrum_clad]] + coating(NXsample): + doc: | + Coating of the fiber. + coating_material: + doc: | + Specify the material of the coating of the fiber. + coating_diameter(NX_FLOAT): + unit: NX_LENGTH + doc: | + Outer diameter of the fiber (e.g. given in micrometer). + length(NX_FLOAT): + unit: NX_LENGTH + doc: | + Length of the fiber. + spectral_range(NX_FLOAT): + exists: recommended + unit: NX_ANY + doc: | + Spectral range for which the fiber is designed. Enter the minimum and + maximum values (lower and upper limit) of the wavelength range. + dimensions: + rank: 1 + dim: [[1, 2]] + \@units: + doc: | + Unit of spectral array (e.g. nanometer or angstrom for wavelength, or + electronvolt for energy etc.). + transfer_rate(NX_FLOAT): + unit: NX_ANY + doc: | + Transfer rate of the fiber (in GB per second). + \@units: + doc: | + GB/s + numerical_aperture(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Numerical aperture (NA) of the fiber. + attenuation(NX_FLOAT): + unit: NX_ANY + doc: | + Wavelength-dependent attenuation of the fiber (specify in dB/km). + dimensions: + rank: 1 + dim: [[1, N_spectrum_attenuation]] + \@units: + doc: | + Use dB/km. + enumeration: [dB/km] + power_loss(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Power loss of the fiber in percentage. + acceptance_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Acceptance angle of the fiber. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 32ddd32d6ce2c9dc1924d91bda357df9aa98cff120802974177c6095be862466 +# +# +# +# +# +# +# +# +# Length of the spectrum vector (e.g. wavelength or energy) for which the +# refractive index of the core material is given. +# +# +# +# +# Length of the spectrum vector (e.g. wavelength or energy) for which the +# refractive index of the cladding material is given. +# +# +# +# +# Length of the spectrum vector (e.g. wavelength or energy) for which the +# attenuation curve is given. +# +# +# +# +# An optical fiber, e.g. glass fiber. +# +# Specify the quantities that define the fiber. Fiber optics are described in +# detail [here](https://www.photonics.com/Article.aspx?AID=25151&PID=4), for +# example. +# +# +# +# Descriptive name or brief description of the fiber, e.g. by stating its +# dimension. The dimension of a fiber can be given as 60/100/200 which +# refers to a core diameter of 60 micron, a clad diameter of 100 micron, +# and a coating diameter of 200 micron. +# +# +# +# +# Type/mode of the fiber. Modes of fiber transmission are shown in +# Fig. 5 [here](https://www.photonics.com/Article.aspx?AID=25151&PID=4). +# +# +# +# +# +# +# +# +# +# Type of dispersion. +# +# +# +# +# +# +# +# +# +# Spectrum-dependent (or refractive index-dependent) dispersion of the +# fiber. Specify in ps/nm*km. +# +# +# +# +# +# +# +# Core of the fiber, i.e. the part of the fiber which transmits the light. +# +# +# +# Specify the material of the core of the fiber. +# +# +# +# +# Core diameter of the fiber (e.g. given in micrometer). +# +# +# +# +# Complex index of refraction of the fiber. Specify at given wavelength +# (or energy, wavenumber etc.) values. +# +# +# +# +# +# +# +# +# +# Core of the fiber, i.e. the part of the fiber which transmits the light. +# +# +# +# Specify the material of the core of the fiber. +# +# +# +# +# Clad diameter of the fiber (e.g. given in micrometer). +# +# +# +# +# Complex index of refraction of the fiber. Specify at given wavelength +# (or energy, wavenumber etc.) values. +# +# +# +# +# +# +# +# +# +# Coating of the fiber. +# +# +# +# Specify the material of the coating of the fiber. +# +# +# +# +# Outer diameter of the fiber (e.g. given in micrometer). +# +# +# +# +# +# Length of the fiber. +# +# +# +# +# Spectral range for which the fiber is designed. Enter the minimum and +# maximum values (lower and upper limit) of the wavelength range. +# +# +# +# +# +# +# Unit of spectral array (e.g. nanometer or angstrom for wavelength, or +# electronvolt for energy etc.). +# +# +# +# +# +# Transfer rate of the fiber (in GB per second). +# +# +# +# GB/s +# +# +# +# +# +# Numerical aperture (NA) of the fiber. +# +# +# +# +# Wavelength-dependent attenuation of the fiber (specify in dB/km). +# +# +# +# +# +# +# Use dB/km. +# +# +# +# +# +# +# +# +# Power loss of the fiber in percentage. +# +# +# +# +# Acceptance angle of the fiber. +# +# +# diff --git a/contributed_definitions/nyaml/NXgraph_edge_set.yaml b/contributed_definitions/nyaml/NXgraph_edge_set.yaml new file mode 100644 index 0000000000..4dacb8e595 --- /dev/null +++ b/contributed_definitions/nyaml/NXgraph_edge_set.yaml @@ -0,0 +1,191 @@ +category: base +doc: | + A set of (eventually directed) edges which connect nodes/vertices of a graph. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_edges: | + The number of edges. +type: group +NXgraph_edge_set(NXobject): + number_of_edges(NX_POSINT): + unit: NX_UNITLESS + doc: | + Total number of edges, counting eventual bidirectional edges only once. + identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for distinguishing + edges. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + identifier(NX_INT): + unit: NX_UNITLESS + doc: | + Integer used to distinguish edges for explicit indexing. + dimensions: + rank: 1 + dim: [[1, n_edges]] + directionality(NX_INT): + unit: NX_UNITLESS + doc: | + Specifier whether each edge is non-directional, one-directional, + or bidirectional. Use the smallest available binary representation + which can store three different states: + + * 0 / state 0x00 is non-directional + * 1 / state 0x01 is one-directional + * 2 / state 0x02 is bi-directional + dimensions: + rank: 1 + dim: [[1, n_edges]] + node_pair(NX_INT): + unit: NX_UNITLESS + doc: | + Pairs of node/vertex identifier. Each pair represents the connection + between two nodes. + + In the case that the edge is non- or bi-directional + node identifier should be stored in ascending order is preferred. + + In the case of one-directional, for each pair the identifier of the source + node is the first entry in the pair. The identifier of the target is the + second entry in the pair, i.e. the pair encodes the information as + if one traverses the edge from the source node walking to the target node. + dimensions: + rank: 2 + dim: [[1, n_edges], [2, 2]] + is_a: + doc: | + A human-readable qualifier which type or e.g. class instance the + edge is an instance of. + dimensions: + rank: 1 + dim: [[1, c]] + label: + doc: | + A human-readable label/caption/tag for the edge. + dimensions: + rank: 1 + dim: [[1, n_edges]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 628c4419049ea786aefca290c517b78ee5da3b581ab73c1b4b8052c1184b1fda +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The number of edges. +# +# +# +# +# A set of (eventually directed) edges which connect nodes/vertices of a graph. +# +# +# +# Total number of edges, counting eventual bidirectional edges only once. +# +# +# +# +# Integer which specifies the first index to be used for distinguishing +# edges. Identifiers are defined either implicitly +# or explicitly. For implicit indexing the identifiers are defined on the +# interval [identifier_offset, identifier_offset+c-1]. +# For explicit indexing the identifier array has to be defined. +# +# The identifier_offset field can for example be used to communicate if the +# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) +# or from 0 (referred to as C-, Python-style index notation) respectively. +# +# +# +# +# Integer used to distinguish edges for explicit indexing. +# +# +# +# +# +# +# +# Specifier whether each edge is non-directional, one-directional, +# or bidirectional. Use the smallest available binary representation +# which can store three different states: +# +# * 0 / state 0x00 is non-directional +# * 1 / state 0x01 is one-directional +# * 2 / state 0x02 is bi-directional +# +# +# +# +# +# +# +# Pairs of node/vertex identifier. Each pair represents the connection +# between two nodes. +# +# In the case that the edge is non- or bi-directional +# node identifier should be stored in ascending order is preferred. +# +# In the case of one-directional, for each pair the identifier of the source +# node is the first entry in the pair. The identifier of the target is the +# second entry in the pair, i.e. the pair encodes the information as +# if one traverses the edge from the source node walking to the target node. +# +# +# +# +# +# +# +# +# A human-readable qualifier which type or e.g. class instance the +# edge is an instance of. +# +# +# +# +# +# +# +# A human-readable label/caption/tag for the edge. +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXgraph_node_set.yaml b/contributed_definitions/nyaml/NXgraph_node_set.yaml new file mode 100644 index 0000000000..3612252002 --- /dev/null +++ b/contributed_definitions/nyaml/NXgraph_node_set.yaml @@ -0,0 +1,148 @@ +category: base +doc: | + A set of nodes/vertices in space representing members of a graph. + +# a graph in which space d-dimensional, categorical, at all a metric one? +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality of the graph. Eventually use one for categorical. + c: | + The cardinality of the set, i.e. the number of nodes/vertices of the graph. +type: group +NXgraph_node_set(NXobject): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + cardinality(NX_POSINT): + unit: NX_UNITLESS + identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for distinguishing + nodes. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + identifier(NX_INT): + unit: NX_UNITLESS + doc: | + Integer used to distinguish nodes for explicit indexing. + dimensions: + rank: 1 + dim: [[1, c]] + is_a: + doc: | + A human-readable qualifier which type or e.g. class instance the + node is an instance of. As e.g. a NeXus application definition is a + graph, more specifically a hierarchical directed labelled property graph, + instances which are groups like NXgraph_node_set could have an is_a + qualifier reading NXgraph_node_set. + dimensions: + rank: 1 + dim: [[1, c]] + label: + doc: | + A human-readable label/caption/tag of the graph. + dimensions: + rank: 1 + dim: [[1, c]] + + # how to handle arrays which are compressed? This can be useful for instance + # if there are substantially fewer disjoint labels than c + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 29e94d3fcf2b74e364c91e7b6b9ee36949726aaf5fb1623e42b3c7a688fda6bc +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality of the graph. Eventually use one for categorical. +# +# +# +# +# The cardinality of the set, i.e. the number of nodes/vertices of the graph. +# +# +# +# +# A set of nodes/vertices in space representing members of a graph. +# +# +# +# +# +# Integer which specifies the first index to be used for distinguishing +# nodes. Identifiers are defined either implicitly +# or explicitly. For implicit indexing the identifiers are defined on the +# interval [identifier_offset, identifier_offset+c-1]. +# For explicit indexing the identifier array has to be defined. +# +# The identifier_offset field can for example be used to communicate if the +# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) +# or from 0 (referred to as C-, Python-style index notation) respectively. +# +# +# +# +# Integer used to distinguish nodes for explicit indexing. +# +# +# +# +# +# +# +# A human-readable qualifier which type or e.g. class instance the +# node is an instance of. As e.g. a NeXus application definition is a +# graph, more specifically a hierarchical directed labelled property graph, +# instances which are groups like NXgraph_node_set could have an is_a +# qualifier reading NXgraph_node_set. +# +# +# +# +# +# +# +# A human-readable label/caption/tag of the graph. +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXgraph_root.yaml b/contributed_definitions/nyaml/NXgraph_root.yaml new file mode 100644 index 0000000000..6cce442e79 --- /dev/null +++ b/contributed_definitions/nyaml/NXgraph_root.yaml @@ -0,0 +1,51 @@ +category: base +doc: | + An instance of a graph. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXgraph_root(NXobject): + nodes(NXgraph_node_set): + relation(NXgraph_edge_set): + + # further attributes + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 1ebca361ac2a2c0e291dc0ddcf551de225aa9ac98375468ff58bb0d98ef5542d +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# An instance of a graph. +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXibeam_column.yaml b/contributed_definitions/nyaml/NXibeam_column.yaml new file mode 100644 index 0000000000..8532c7ecb5 --- /dev/null +++ b/contributed_definitions/nyaml/NXibeam_column.yaml @@ -0,0 +1,253 @@ +category: base +doc: | + Container for components of a focused-ion-beam (FIB) system. + + FIB capabilities turn especially scanning electron microscopes + into specimen preparation labs. FIB is a material preparation + technique whereby portions of the sample are illuminated with a + focused ion beam with controlled intensity intense enough and with + sufficient ion momentum to remove material in a controllable manner. + + The fact that an electron microscope with FIB capabilities has needs a + second gun with own relevant control circuits, focusing lenses, and + other components, warrants an own base class to group these components + and distinguish them from the lenses and components for creating and + shaping the electron beam. + + For more details about the relevant physics and application examples + consult the literature, for example: + + * `L. A. Giannuzzi et al. `_ + * `E. I. Preiß et al. `_ + * `J. F. Ziegler et al. `_ + * `J. Lili `_ + +# symbols: +# doc: The symbols used in the schema to specify e.g. variables. +type: group +NXibeam_column(NXobject): + (NXfabrication): + ion_source(NXsource): + doc: | + The source which creates the ion beam. + name: + doc: | + Given name/alias for the ion gun. + emitter_type: + doc: | + Emitter type used to create the ion beam. + + If the emitter type is other, give further + details in the description field. + enumeration: [liquid_metal, plasma, gas_field, other] + description: + doc: | + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + probe(NXion): + doc: | + Which ionized elements or molecular ions form the beam. + Examples are gallium, helium, neon, argon, krypton, + or xenon, O2+. + + # NEW ISSUE: use NXion instead + brightness(NX_FLOAT): + unit: NX_ANY + doc: | + Average/nominal brightness + + # \@units: A/cm*sr + # NEW ISSUE: (at which location?). + current(NX_FLOAT): + unit: NX_CURRENT + doc: | + Charge current + voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Ion acceleration voltage upon source exit and entering the vacuum flight path. + ion_energy_profile(NX_NUMBER): + unit: NX_ENERGY + (NXtransformations): + doc: | + Affine transformation which detail the arrangement in the microscope relative to + the optical axis and beam path. + + # NEW ISSUE: details about the life/up-time of the source + # relevant from maintenance point of view + (NXaperture_em): + (NXlens_em): + + # ibeam_deflector(NXscanbox_em): + (NXsensor): + (NXbeam): + doc: | + Individual characterization results for the position, shape, + and characteristics of the ion beam. + + NXtransformations should be used to specify the location or position + at which details about the ion beam are probed. + + # all these components of the FIB system are usually controlled via an + # instrment control software that is often part of the e.g. microscope control # software or at least linked to this software. + # NEW ISSUE: scan_align(NXprocess): + # NEW ISSUE: milling_plan(NXprocess): + # doc: Description of the program and sequence of sample positions sputtered. + # in here we can store time-dependent quantities + # NEW ISSUE: for documentation of charge compensation + # (NXtransformation): + # doc: | + # A right-handed Cartesian coordinate system is used whose positive + # z-axis points in the direction of the ion beam, i.e. towards the + # sample. For modelling ion milling it is relevant to document the + # illumination vector. NXtransformations offers a place to store how the + # ion gun coordinate system has to be rotated to align its positive z-axis + # with the positive z-axis of e.g. the electron beam and ion beam + # respectively. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 48d294299188b58b704f5def9752b4f13ada376f461333073b0a6f861066d480 +# +# +# +# +# +# +# Container for components of a focused-ion-beam (FIB) system. +# +# FIB capabilities turn especially scanning electron microscopes +# into specimen preparation labs. FIB is a material preparation +# technique whereby portions of the sample are illuminated with a +# focused ion beam with controlled intensity intense enough and with +# sufficient ion momentum to remove material in a controllable manner. +# +# The fact that an electron microscope with FIB capabilities has needs a +# second gun with own relevant control circuits, focusing lenses, and +# other components, warrants an own base class to group these components +# and distinguish them from the lenses and components for creating and +# shaping the electron beam. +# +# For more details about the relevant physics and application examples +# consult the literature, for example: +# +# * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ +# * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ +# * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ +# * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ +# +# +# +# +# The source which creates the ion beam. +# +# +# +# Given name/alias for the ion gun. +# +# +# +# +# Emitter type used to create the ion beam. +# +# If the emitter type is other, give further +# details in the description field. +# +# +# +# +# +# +# +# +# +# +# Ideally, a (globally) unique persistent identifier, link, +# or text to a resource which gives further details. +# +# +# +# +# Which ionized elements or molecular ions form the beam. +# Examples are gallium, helium, neon, argon, krypton, +# or xenon, O2+. +# +# +# +# +# +# Average/nominal brightness +# +# +# +# +# +# Charge current +# +# +# +# +# Ion acceleration voltage upon source exit and entering the vacuum flight path. +# +# +# +# +# +# Affine transformation which detail the arrangement in the microscope relative to +# the optical axis and beam path. +# +# +# +# +# +# +# +# +# +# +# Individual characterization results for the position, shape, +# and characteristics of the ion beam. +# +# NXtransformations should be used to specify the location or position +# at which details about the ion beam are probed. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXimage_set.yaml b/contributed_definitions/nyaml/NXimage_set.yaml new file mode 100644 index 0000000000..289682d827 --- /dev/null +++ b/contributed_definitions/nyaml/NXimage_set.yaml @@ -0,0 +1,202 @@ +category: base +doc: | + Container for reporting a set of images taken. +symbols: + n_images: | + Number of images in the stack. + n_y: | + Number of pixel per image in the slow direction. + n_x: | + Number of pixel per image in the fast direction. +type: group +NXimage_set(NXobject): + (NXprocess): + doc: | + Details how images were processed from the detector readings. + source: + doc: | + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXimage_set were loaded during parsing. + \@version: + doc: | + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + mode: + doc: | + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXimage_set instance. + detector_identifier: + doc: | + Link or name of an NXdetector instance with which the data were collected. + (NXprogram): + stack(NXdata): + doc: | + Image (stack). + data_counts(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Image intensity values. + dimensions: + rank: 3 + dim: [[1, n_images], [2, n_y], [3, n_x]] + axis_image_identifier(NX_UINT): + unit: NX_UNITLESS + doc: | + Image identifier + dimensions: + rank: 1 + dim: [[1, n_images]] + \@long_name: + doc: | + Image identifier. + axis_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Pixel coordinate center of mass along y direction. + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + doc: | + Coordinate along y direction. + axis_x(NX_NUMBER): + unit: NX_LENGTH + doc: | + Pixel coordinate center of mass along x direction. + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: + doc: | + Coordinate along x direction. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# d8a2ad749b0efcaf144af79af9d4ea222dc72b0d946125be13563dd6d5ccb4c2 +# +# +# +# +# +# +# +# Number of images in the stack. +# +# +# +# +# Number of pixel per image in the slow direction. +# +# +# +# +# Number of pixel per image in the fast direction. +# +# +# +# +# Container for reporting a set of images taken. +# +# +# +# Details how images were processed from the detector readings. +# +# +# +# Resolvable data artifact (e.g. filename) from which the all values in +# the NXdata instances in this NXimage_set were loaded during parsing. +# +# +# +# An at least as strong as SHA256 hashvalue of the data artifact which +# source represents digitally to support provenance tracking. +# +# +# +# +# +# Imaging (data collection) mode of the instrument during acquisition +# of the data in this NXimage_set instance. +# +# +# +# +# Link or name of an NXdetector instance with which the data were collected. +# +# +# +# +# +# +# Image (stack). +# +# +# +# Image intensity values. +# +# +# +# +# +# +# +# +# +# Image identifier +# +# +# +# +# +# +# Image identifier. +# +# +# +# +# +# Pixel coordinate center of mass along y direction. +# +# +# +# +# +# +# Coordinate along y direction. +# +# +# +# +# +# Pixel coordinate center of mass along x direction. +# +# +# +# +# +# +# Coordinate along x direction. +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXimage_set_em_adf.yaml b/contributed_definitions/nyaml/NXimage_set_em_adf.yaml new file mode 100644 index 0000000000..ca8673f6de --- /dev/null +++ b/contributed_definitions/nyaml/NXimage_set_em_adf.yaml @@ -0,0 +1,257 @@ +category: base +doc: | + Container for reporting a set of annular dark field images. + + Virtually the most important case is that spectra are collected in + a scanning microscope (SEM or STEM) for a collection of points. + The majority of cases use simple d-dimensional regular scan pattern, + such as single point, line profiles, or (rectangular) surface mappings. + The latter pattern is the most frequently used. + + For now the base class provides for scans for which the settings, + binning, and energy resolution is the same for each scan point. +symbols: + n_images: | + Number of images in the stack. + n_y: | + Number of pixel per image in the slow direction. + n_x: | + Number of pixel per image in the fast direction. +type: group +NXimage_set_em_adf(NXobject): + (NXprocess): + doc: | + Details how (HA)ADF images were processed from the detector readings. + source: + doc: | + Typically the name of the input, (vendor) file from which all + the NXdata instances in this NXimage_set_em_adf were loaded during + parsing to represent them in e.g. databases. + \@version: + doc: | + An at least as strong as SHA256 hashvalue of the dataset/file + which represents the source digitally to support provenance tracking. + program: + doc: | + Commercial or otherwise given name to the program which was used + to process detector data into the adf image(s). + \@version: + doc: | + Program version plus build number, commit hash, or description + of an ever persistent resource where the source code of the program + and build instructions can be found so that the program + can be configured in such a manner that the result file + is ideally recreatable yielding the same results. + adf_inner_half_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Annulus inner half angle + adf_outer_half_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Annulus outer half angle + stack(NXdata): + doc: | + Annular dark field image stack. + + # \@signal: intensity + # \@axes: [image_id, ypos, xpos] + # \@xpos_indices: 2 + # \@ypos_indices: 1 + # \@image_indices: 0 + data_counts(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Image intensity values. + dimensions: + rank: 3 + dim: [[1, n_images], [2, n_y], [3, n_x]] + axis_image_identifier(NX_UINT): + unit: NX_UNITLESS + doc: | + Image identifier + dimensions: + rank: 1 + dim: [[1, n_images]] + \@long_name: + doc: | + Image ID. + axis_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Pixel center of mass along y direction. + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + doc: | + Coordinate along y direction. + axis_x(NX_NUMBER): + unit: NX_LENGTH + doc: | + Pixel center of mass along x direction. + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: + doc: | + Coordinate along x direction. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 4af28c1f529beba15afbed5d28bccfaecc08b2c46e956fcaa3fe2e08ca4669e9 +# +# +# +# +# +# +# +# Number of images in the stack. +# +# +# +# +# Number of pixel per image in the slow direction. +# +# +# +# +# Number of pixel per image in the fast direction. +# +# +# +# +# Container for reporting a set of annular dark field images. +# +# Virtually the most important case is that spectra are collected in +# a scanning microscope (SEM or STEM) for a collection of points. +# The majority of cases use simple d-dimensional regular scan pattern, +# such as single point, line profiles, or (rectangular) surface mappings. +# The latter pattern is the most frequently used. +# +# For now the base class provides for scans for which the settings, +# binning, and energy resolution is the same for each scan point. +# +# +# +# Details how (HA)ADF images were processed from the detector readings. +# +# +# +# Typically the name of the input, (vendor) file from which all +# the NXdata instances in this NXimage_set_em_adf were loaded during +# parsing to represent them in e.g. databases. +# +# +# +# An at least as strong as SHA256 hashvalue of the dataset/file +# which represents the source digitally to support provenance tracking. +# +# +# +# +# +# Commercial or otherwise given name to the program which was used +# to process detector data into the adf image(s). +# +# +# +# Program version plus build number, commit hash, or description +# of an ever persistent resource where the source code of the program +# and build instructions can be found so that the program +# can be configured in such a manner that the result file +# is ideally recreatable yielding the same results. +# +# +# +# +# +# Annulus inner half angle +# +# +# +# +# Annulus outer half angle +# +# +# +# +# +# Annular dark field image stack. +# +# +# +# +# Image intensity values. +# +# +# +# +# +# +# +# +# +# Image identifier +# +# +# +# +# +# +# Image ID. +# +# +# +# +# +# Pixel center of mass along y direction. +# +# +# +# +# +# +# Coordinate along y direction. +# +# +# +# +# +# Pixel center of mass along x direction. +# +# +# +# +# +# +# Coordinate along x direction. +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXimage_set_em_kikuchi.yaml b/contributed_definitions/nyaml/NXimage_set_em_kikuchi.yaml new file mode 100644 index 0000000000..91fae48349 --- /dev/null +++ b/contributed_definitions/nyaml/NXimage_set_em_kikuchi.yaml @@ -0,0 +1,362 @@ +category: base +doc: | + Measured set of electron backscatter diffraction data, aka Kikuchi pattern. + Kikuchi pattern are the raw data for computational workflows in the field + of orientation (imaging) microscopy. The technique is especially used in + materials science and materials engineering. + + Based on a fuse of the `M. A. Jackson et al. `_ + of the DREAM.3D community and the open H5OINA format of Oxford Instruments + `P. Pinard et al. `_ + + EBSD can be used, usually with FIB/SEM microscopes, for three-dimensional + orientation microscopy. So-called serial section analyses. For a detailed + overview of these techniques see e.g. + + * `M. A. Groeber et al. `_ + * `A. J. Schwartz et al. `_ + * `P. A. Rottman et al. `_ + + With serial-sectioning this involves however always a sequence of measuring, + milling. In this regard, each serial section (measuring) and milling + is an own NXevent_data_em instance and thus there such a three-dimensional + characterization should be stored as a set of two-dimensional data, + with as many NXevent_data_em instances as sections were measured. + + These measured serial sectioning images need virtually always post-processing + to arrive at the aligned and cleaned image stack before a respective digital + model of the inspected microstructure can be analyzed. The resulting volume + is often termed a so-called (representative) volume element (RVE). + Several software packages are available for performing this post-processing. + For now we do not consider metadata of these post-processing steps + as a part of this base class because the connection between the large variety + of such post-processing steps and the measured electron microscopy data + is usually very small. + + If we envision a (knowledge) graph for EBSD it consists of individual + sub-graphs which convey information about the specimen preparation, + the measurement of the specimen in the electron microscope, + the indexing of the collected Kikuchi pattern stack, + eventual post-processing of the indexed orientation image + via similarity grouping algorithms to yield (grains, texture). + Conceptually these post-processing steps are most frequently + serving the idea to reconstruct quantitatively so-called + microstructural features (grains, phases, interfaces). Materials scientists + use these features according to the multi-scale materials modeling paradigm + to infer material properties. They do so by quantifying correlations between + the spatial arrangement of the features, their individual properties, + and (macroscopic) properties of materials. +symbols: + n_sc: | + Number of scanned points. Scan point may have none, one, or more pattern. + n_p: | + Number of diffraction pattern. + n_y: | + Number of pixel per Kikuchi pattern in the slow direction. + n_x: | + Number of pixel per Kikuchi pattern in the fast direction. +type: group +NXimage_set_em_kikuchi(NXobject): + + # a collection of pattern-related metadata + (NXprocess): + doc: | + Details how Kikuchi pattern were processed from the detector readings. + Scientists interested in EBSD should inspect the respective NXem_ebsd + application definition which can be used as a partner application definition + to detail substantially more details to this processing. + stack(NXdata): + doc: | + Collected Kikuchi pattern as an image stack. As raw and closest to the + first retrievable measured data as possible, i.e. do not use this + container to store already averaged, filtered or whatever post-processed + pattern unless these are generated unmodifiably by the instrument + given the way how the instrument and control software was configured + for your microscope session. + scan_point_identifier(NX_UINT): + unit: NX_UNITLESS + doc: | + Array which resolves the scan point to which each pattern belongs. + Scan points are evaluated in sequence starting from scan point zero + until scan point n_sc - 1. Evaluating the cumulated of this array + decodes which pattern in intensity belong to which scan point. + In an example we may assume we collected three scan points. For the first + we measure one pattern, for the second we measure three pattern, + for the last we measure no pattern. + The values of scan_point_identifier will be 0, 1, 1, 1, as we have + measured four pattern in total. + + In most cases usually one pattern is averaged by the detector for + some amount of time and then reported as one pattern. Use compressed + arrays allows to store the scan_point_identifier efficiently. + dimensions: + rank: 1 + dim: [[1, n_p]] + data_counts(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Signal intensity. For so-called three-dimensional or serial sectioning + EBSD it is necessary to follow a sequence of specimen surface preparation + and data collection. In this case users should collect the data for each + serial sectioning step in an own instance of NXimage_set_em_kikuchi. + All eventual post-processing of these measured data should be documented + via NXebsd, resulting microstructure representations should be stored + as NXms. + dimensions: + rank: 3 + dim: [[1, n_p], [2, n_y], [3, n_x]] + + # n_p fast 2, n_y faster 1, n_x fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: | + Kikuchi pattern intensity + + # \@signal: intensity + # \@axes: [pattern_identifier, ypos, xpos] + # \@xpos_indices: 0 + # \@ypos_indices: 1 + # \@pattern_identifier_indices: 2 + pattern_identifier(NX_UINT): + unit: NX_UNITLESS + doc: | + Pattern are enumerated starting from 0 to n_p - 1. + dimensions: + rank: 1 + dim: [[1, n_p]] + \@long_name: + doc: | + Kikuchi pattern identifier + axis_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Pixel coordinate along the y direction. + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + doc: | + Label for the y axis + axis_x(NX_NUMBER): + unit: NX_LENGTH + doc: | + Pixel coordinate along the x direction. + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: + doc: | + Label for the x axis + + # maybe time code data when the pattern were taken? + # key is it all happened in between the time defined in NXevent_data_em + # optionally link to NXebsd instance? + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 7710451cb8d41d7552e7016a888b69786627788a4659d2928852090ea22d302d +# +# +# +# +# +# +# +# Number of scanned points. Scan point may have none, one, or more pattern. +# +# +# +# +# Number of diffraction pattern. +# +# +# +# +# Number of pixel per Kikuchi pattern in the slow direction. +# +# +# +# +# Number of pixel per Kikuchi pattern in the fast direction. +# +# +# +# +# Measured set of electron backscatter diffraction data, aka Kikuchi pattern. +# Kikuchi pattern are the raw data for computational workflows in the field +# of orientation (imaging) microscopy. The technique is especially used in +# materials science and materials engineering. +# +# Based on a fuse of the `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ +# of the DREAM.3D community and the open H5OINA format of Oxford Instruments +# `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ +# +# EBSD can be used, usually with FIB/SEM microscopes, for three-dimensional +# orientation microscopy. So-called serial section analyses. For a detailed +# overview of these techniques see e.g. +# +# * `M. A. Groeber et al. <https://doi.org/10.1186/2193-9772-3-5>`_ +# * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ +# * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ +# +# With serial-sectioning this involves however always a sequence of measuring, +# milling. In this regard, each serial section (measuring) and milling +# is an own NXevent_data_em instance and thus there such a three-dimensional +# characterization should be stored as a set of two-dimensional data, +# with as many NXevent_data_em instances as sections were measured. +# +# These measured serial sectioning images need virtually always post-processing +# to arrive at the aligned and cleaned image stack before a respective digital +# model of the inspected microstructure can be analyzed. The resulting volume +# is often termed a so-called (representative) volume element (RVE). +# Several software packages are available for performing this post-processing. +# For now we do not consider metadata of these post-processing steps +# as a part of this base class because the connection between the large variety +# of such post-processing steps and the measured electron microscopy data +# is usually very small. +# +# If we envision a (knowledge) graph for EBSD it consists of individual +# sub-graphs which convey information about the specimen preparation, +# the measurement of the specimen in the electron microscope, +# the indexing of the collected Kikuchi pattern stack, +# eventual post-processing of the indexed orientation image +# via similarity grouping algorithms to yield (grains, texture). +# Conceptually these post-processing steps are most frequently +# serving the idea to reconstruct quantitatively so-called +# microstructural features (grains, phases, interfaces). Materials scientists +# use these features according to the multi-scale materials modeling paradigm +# to infer material properties. They do so by quantifying correlations between +# the spatial arrangement of the features, their individual properties, +# and (macroscopic) properties of materials. +# +# +# +# +# Details how Kikuchi pattern were processed from the detector readings. +# Scientists interested in EBSD should inspect the respective NXem_ebsd +# application definition which can be used as a partner application definition +# to detail substantially more details to this processing. +# +# +# +# +# Collected Kikuchi pattern as an image stack. As raw and closest to the +# first retrievable measured data as possible, i.e. do not use this +# container to store already averaged, filtered or whatever post-processed +# pattern unless these are generated unmodifiably by the instrument +# given the way how the instrument and control software was configured +# for your microscope session. +# +# +# +# Array which resolves the scan point to which each pattern belongs. +# Scan points are evaluated in sequence starting from scan point zero +# until scan point n_sc - 1. Evaluating the cumulated of this array +# decodes which pattern in intensity belong to which scan point. +# In an example we may assume we collected three scan points. For the first +# we measure one pattern, for the second we measure three pattern, +# for the last we measure no pattern. +# The values of scan_point_identifier will be 0, 1, 1, 1, as we have +# measured four pattern in total. +# +# In most cases usually one pattern is averaged by the detector for +# some amount of time and then reported as one pattern. Use compressed +# arrays allows to store the scan_point_identifier efficiently. +# +# +# +# +# +# +# +# Signal intensity. For so-called three-dimensional or serial sectioning +# EBSD it is necessary to follow a sequence of specimen surface preparation +# and data collection. In this case users should collect the data for each +# serial sectioning step in an own instance of NXimage_set_em_kikuchi. +# All eventual post-processing of these measured data should be documented +# via NXebsd, resulting microstructure representations should be stored +# as NXms. +# +# +# +# +# +# +# +# +# +# Kikuchi pattern intensity +# +# +# +# +# +# +# Pattern are enumerated starting from 0 to n_p - 1. +# +# +# +# +# +# +# Kikuchi pattern identifier +# +# +# +# +# +# Pixel coordinate along the y direction. +# +# +# +# +# +# +# Label for the y axis +# +# +# +# +# +# Pixel coordinate along the x direction. +# +# +# +# +# +# +# Label for the x axis +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXinteraction_vol_em.yaml b/contributed_definitions/nyaml/NXinteraction_vol_em.yaml new file mode 100644 index 0000000000..916ca1dacc --- /dev/null +++ b/contributed_definitions/nyaml/NXinteraction_vol_em.yaml @@ -0,0 +1,75 @@ +category: base +doc: | + Base class for storing details about a modelled shape of interaction volume. + + The interaction volume is mainly relevant in scanning electron microscopy + when the sample is thick enough so that the beam is unable to illuminate + through the specimen. + Computer models like Monte Carlo or molecular dynamics / electron beam + interaction simulations can be used to qualify and/or quantify the shape of + the interaction volume. + + Explicit or implicit descriptions are possible. + + * An implicit description is via a set of electron/specimen interactions + represented ideally as trajectory data from the computer simulation. + * An explicit description is via an iso-contour surface using either + a simulation grid or a triangulated surface mesh of the approximated + iso-contour surface evaluated at specific threshold values. + Iso-contours could be computed from electron or particle fluxes through + an imaginary control surface (the iso-surface). + Threshold values can be defined by particles passing through a unit control + volume (electrons) or energy-levels (e.g. the case of X-rays). + Details depend on the model. + * Another explicit description is via theoretical models which may + be relevant e.g. for X-ray spectroscopy + + Further details on how the interaction volume can be quantified + is available in the literature for example: + + * `S. Richter et al. `_ + * `J. Bünger et al. `_ +type: group +(NXobject)NXinteraction_vol_em: + (NXdata): + (NXprocess): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 29b6daff56a280c88764ab6e66b9b4e67228cd110dbb825726104e01550aeeb7 +# +# +# +# +# Base class for storing details about a modelled shape of interaction volume. +# +# The interaction volume is mainly relevant in scanning electron microscopy +# when the sample is thick enough so that the beam is unable to illuminate +# through the specimen. +# Computer models like Monte Carlo or molecular dynamics / electron beam +# interaction simulations can be used to qualify and/or quantify the shape of +# the interaction volume. +# +# Explicit or implicit descriptions are possible. +# +# * An implicit description is via a set of electron/specimen interactions +# represented ideally as trajectory data from the computer simulation. +# * An explicit description is via an iso-contour surface using either +# a simulation grid or a triangulated surface mesh of the approximated +# iso-contour surface evaluated at specific threshold values. +# Iso-contours could be computed from electron or particle fluxes through +# an imaginary control surface (the iso-surface). +# Threshold values can be defined by particles passing through a unit control +# volume (electrons) or energy-levels (e.g. the case of X-rays). +# Details depend on the model. +# * Another explicit description is via theoretical models which may +# be relevant e.g. for X-ray spectroscopy +# +# Further details on how the interaction volume can be quantified +# is available in the literature for example: +# +# * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ +# * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ +# +# +# +# diff --git a/contributed_definitions/nyaml/NXion.yaml b/contributed_definitions/nyaml/NXion.yaml new file mode 100644 index 0000000000..c6adffce71 --- /dev/null +++ b/contributed_definitions/nyaml/NXion.yaml @@ -0,0 +1,289 @@ +category: base +doc: | + Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_ivecmax: | + Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). + n_ranges: | + Number of mass-to-charge-state-ratio range intervals for ion type. +type: group +NXion(NXobject): + identifier: + doc: | + A unique identifier whereby such an ion can be referred to + via the service offered as described in identifier_type. + identifier_type: + doc: | + How can the identifier be resolved? + enumeration: [inchi] + ion_type(NX_UINT): + unit: NX_UNITLESS + doc: | + Ion type (ion species) identifier. The identifier zero + is reserved for the special unknown ion type. + isotope_vector(NX_UINT): + unit: NX_UNITLESS + doc: | + A vector of isotope hash values. + These values have to be stored in an array, sorted in decreasing order. + The array is filled with zero hash values indicating unused places. + The individual hash values are built with the following hash function: + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. + + Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) `_ + dimensions: + rank: 2 + dim: [[1, 1], [2, n_ivecmax]] + nuclid_list(NX_UINT): + unit: NX_UNITLESS + doc: | + A supplementary row vector which decodes the isotope_vector into + a human-readable matrix of nuclids with the following formatting: + + The first row specifies the isotope mass number, i.e. using the hashvalues + from the isotope_vector this is :math:`Z + N`. As an example for a + carbon-14 isotope the number is 14. + The second row specifies the number of protons :math:`Z`, e.g. 6 for the + carbon-14 example. This row matrix is thus a mapping the notation of + using superscribed isotope mass and subscripted number of protons to + identify isotopes. + Unused places filling up to n_ivecmax need to be filled with zero. + dimensions: + rank: 2 + dim: [[1, 2], [2, n_ivecmax]] + color: + doc: | + Color code used for visualizing such ions. + volume(NX_FLOAT): + unit: NX_VOLUME + doc: | + Assumed volume of the ion. + + In atom probe microscopy this field can be used to store the reconstructed + volume per ion (average) which is typically stored in range files and will + be used when building a tomographic reconstruction of an atom probe + dataset. + charge(NX_FLOAT): + unit: NX_CHARGE + doc: | + Charge of the ion. + charge_state(NX_INT): + unit: NX_UNITLESS + doc: | + Signed charge state of the ion in multiples of electron charge. + + Only positive values will be measured in atom probe microscopy as the + ions are accelerated by a negatively signed bias electric field. + In the case that the charge state is not explicitly recoverable, + the value should be set to zero. + + In atom probe microscopy this is for example the case when using + classical range file formats like RNG, RRNG for atom probe data. + These file formats do not document the charge state explicitly. + They report the number of atoms of each element per molecular ion + surplus the mass-to-charge-state-ratio interval. + With this it is possible to recover the charge state only for + specific molecular ions as the accumulated mass of the molecular ion + is defined by the isotopes, which without knowing the charge leads + to an underconstrained problem. + Details on ranging can be found in the literature: `M. K. Miller `_ + name: + doc: | + Human-readable ion type name (e.g. Al +++) + The string should consists of ASCII UTF-8 characters, + ideally using LaTeX notation to specify the isotopes, ions, and charge + state. Examples are 12C + or Al +++. + Although this name may be human-readable and intuitive, parsing such + names becomes impractical for more complicated cases. Therefore, for the + field of atom probe microscopy the isotope_vector should be the + preferred machine-readable format to use. + mass_to_charge_range(NX_FLOAT): + unit: NX_ANY + doc: | + Associated lower (mqmin) and upper (mqmax) bounds of + mass-to-charge-state ratio interval(s) [mqmin, mqmax] + (boundaries included) for which the respective ion is one to be labelled + with ion_identifier. The field is primarily of interest to document the + result of indexing a ToF/mass spectrum. + + # \@units: Da + dimensions: + rank: 2 + dim: [[1, n_ranges], [2, 2]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 46239655be8d46576203e9210fb3529fb5d8490df4826298dbe207b24470ddd7 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). +# +# +# +# +# Number of mass-to-charge-state-ratio range intervals for ion type. +# +# +# +# +# Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. +# +# +# +# A unique identifier whereby such an ion can be referred to +# via the service offered as described in identifier_type. +# +# +# +# +# How can the identifier be resolved? +# +# +# +# +# +# +# +# Ion type (ion species) identifier. The identifier zero +# is reserved for the special unknown ion type. +# +# +# +# +# A vector of isotope hash values. +# These values have to be stored in an array, sorted in decreasing order. +# The array is filled with zero hash values indicating unused places. +# The individual hash values are built with the following hash function: +# +# The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` +# the number of protons and :math:`N` the number of neutrons +# of each isotope respectively. +# +# Z and N have to be 8-bit unsigned integers. +# For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ +# +# +# +# +# +# +# +# +# A supplementary row vector which decodes the isotope_vector into +# a human-readable matrix of nuclids with the following formatting: +# +# The first row specifies the isotope mass number, i.e. using the hashvalues +# from the isotope_vector this is :math:`Z + N`. As an example for a +# carbon-14 isotope the number is 14. +# The second row specifies the number of protons :math:`Z`, e.g. 6 for the +# carbon-14 example. This row matrix is thus a mapping the notation of +# using superscribed isotope mass and subscripted number of protons to +# identify isotopes. +# Unused places filling up to n_ivecmax need to be filled with zero. +# +# +# +# +# +# +# +# +# Color code used for visualizing such ions. +# +# +# +# +# Assumed volume of the ion. +# +# In atom probe microscopy this field can be used to store the reconstructed +# volume per ion (average) which is typically stored in range files and will +# be used when building a tomographic reconstruction of an atom probe +# dataset. +# +# +# +# +# Charge of the ion. +# +# +# +# +# Signed charge state of the ion in multiples of electron charge. +# +# Only positive values will be measured in atom probe microscopy as the +# ions are accelerated by a negatively signed bias electric field. +# In the case that the charge state is not explicitly recoverable, +# the value should be set to zero. +# +# In atom probe microscopy this is for example the case when using +# classical range file formats like RNG, RRNG for atom probe data. +# These file formats do not document the charge state explicitly. +# They report the number of atoms of each element per molecular ion +# surplus the mass-to-charge-state-ratio interval. +# With this it is possible to recover the charge state only for +# specific molecular ions as the accumulated mass of the molecular ion +# is defined by the isotopes, which without knowing the charge leads +# to an underconstrained problem. +# Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ +# +# +# +# +# Human-readable ion type name (e.g. Al +++) +# The string should consists of ASCII UTF-8 characters, +# ideally using LaTeX notation to specify the isotopes, ions, and charge +# state. Examples are 12C + or Al +++. +# Although this name may be human-readable and intuitive, parsing such +# names becomes impractical for more complicated cases. Therefore, for the +# field of atom probe microscopy the isotope_vector should be the +# preferred machine-readable format to use. +# +# +# +# +# Associated lower (mqmin) and upper (mqmax) bounds of +# mass-to-charge-state ratio interval(s) [mqmin, mqmax] +# (boundaries included) for which the respective ion is one to be labelled +# with ion_identifier. The field is primarily of interest to document the +# result of indexing a ToF/mass spectrum. +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXisocontour.yaml b/contributed_definitions/nyaml/NXisocontour.yaml new file mode 100644 index 0000000000..7dd7476a71 --- /dev/null +++ b/contributed_definitions/nyaml/NXisocontour.yaml @@ -0,0 +1,101 @@ +category: base +doc: | + Computational geometry description of isocontouring/phase-fields in Euclidean space. + + Iso-contouring algorithms such as MarchingCubes and others are frequently + used to segment d-dimensional regions into regions where intensities are + lower or higher than a threshold value, the so-called isovalue. + + Frequently in computational materials science phase-field methods are + used which generate data on discretized grids. Isocontour algorithms + are often used in such context to pinpoint the locations of microstructural + features from this implicit phase-field-variable-based description. + + One of the key intentions of this base class is to provide a starting point + for scientists from the phase-field community (condensed matter physicists, + and materials engineers) to incentivize that also phase-field simulation + data could be described with NeXus, provided base classes such as the this one + get further extend according to the liking of the phase-field community. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality of the description. +type: group +NXisocontour(NXobject): + dimensionality(NX_POSINT): + unit: NX_UNITLESS + grid(NXcg_grid): + doc: | + The discretized grid on which the iso-contour algorithm operates. + isovalue(NX_NUMBER): + unit: NX_ANY + doc: | + The threshold or iso-contour value. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# b300a7c96b0af0dc9017c870a9758dc2c5e0b922c869ae76458457db04fdcb8d +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality of the description. +# +# +# +# +# Computational geometry description of isocontouring/phase-fields in Euclidean space. +# +# Iso-contouring algorithms such as MarchingCubes and others are frequently +# used to segment d-dimensional regions into regions where intensities are +# lower or higher than a threshold value, the so-called isovalue. +# +# Frequently in computational materials science phase-field methods are +# used which generate data on discretized grids. Isocontour algorithms +# are often used in such context to pinpoint the locations of microstructural +# features from this implicit phase-field-variable-based description. +# +# One of the key intentions of this base class is to provide a starting point +# for scientists from the phase-field community (condensed matter physicists, +# and materials engineers) to incentivize that also phase-field simulation +# data could be described with NeXus, provided base classes such as the this one +# get further extend according to the liking of the phase-field community. +# +# +# +# +# The discretized grid on which the iso-contour algorithm operates. +# +# +# +# +# The threshold or iso-contour value. +# +# +# diff --git a/contributed_definitions/nyaml/NXiv_bias.yaml b/contributed_definitions/nyaml/NXiv_bias.yaml new file mode 100644 index 0000000000..8f53ae52fc --- /dev/null +++ b/contributed_definitions/nyaml/NXiv_bias.yaml @@ -0,0 +1,324 @@ +category: base +doc: | + Application definition for bias devices. +type: group +NXiv_bias(NXobject): + bias(NX_NUMBER): + unit: NX_VOLTAGE + doc: | + Applied a voltage between tip and sample. + tunneling_resistor(NX_NUMBER): + unit: NX_ANY + doc: | + The ratio between the tunneling current at the sample surface and the bias voltage + applied between the sample and the tip. + calibration(NX_NUMBER): + doc: | + Calibration of the Bias output (V/V). + offset(NX_NUMBER): + unit: NX_VOLTAGE + doc: | + Allows compensating for an offset in Bias. Hardware parameter offset. + modulated_signal_bias(NX_NUMBER): + unit: NX_VOLTAGE + doc: | + Sets the amplitude (in physical units of the modulated signal) of the sine + modulation. + (NXbias_spectroscopy): + doc: | + Bias sweeps while measuring arbitrary channels with I(V) curves. + channels(NX_CHAR): + doc: | + Select the channels to record. + reset_bias(NX_BOOLEAN): + doc: | + When selected, the Bias voltage returns to the initial value (before starting the sweep) at + the end of the spectroscopy measurement (default). When not selected, Bias remains at the + last value of the sweep. This is useful e.g. when combining several sweep segments. Example + for an automated measurement (using Programming Interface): switch off Z-Controller, start + spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, + switch on Z-Controller. + record_final_z(NX_BOOLEAN): + doc: | + Select whether to record the Z position during Z averaging time at the end of + the sweep (after Z control time) and store the average value in the header of + the file when saving. Using this option increases the sweep time by Z averaging + time. + lock_in_run(NX_BOOLEAN): + doc: | + Select whether to set the Lock-In to run during the measurement. When using this + feature, make sure the Lock-In is configured correctly and settling times are + set to twice the Lock-In period at least. This option is ignored when Lock-In is + already running. This option is disabled if the Sweep Mode is MLS and the flag + to configure the Lock-In per segment in the Multiline segment editor is set. + integration_time(NX_NUMBER): + unit: NX_TIME + doc: | + Time during which the spectroscopy data are acquired and averaged. + number_of_sweeps(NX_NUMBER): + doc: | + Number of sweeps to measure and average. + sweep_start(NX_NUMBER): + unit: NX_VOLTAGE + doc: | + The first bias values of the sweep. + sweep_end(NX_NUMBER): + unit: NX_VOLTAGE + doc: | + The last bias values of the sweep. + num_pixel(NX_NUMBER): + doc: | + Define the sweep number of points, that is, the maximum spectrum resolution eq. + Bias window divide by Num Pixel. + z_avg_time(NX_NUMBER): + unit: NX_TIME + doc: | + Duration over which the Z position is recorded and averaged before and after the + sweep (the latter only if Record final Z position is selected in the Advanced + section). After the initial Z averaging time, if Z-Controller to Hold is + selected in the Advanced section, the Z-Controller is set to hold and the tip is + placed at the previously averaged Z position (plus Z offset). + sw_filter_type(NX_CHAR): + doc: | + Select a filter to smooth the displayed data. When saving, if any filter + selected, filtered data are saved to file along with the unfiltered data. + sw_ilter_order(NX_NUMBER): + doc: | + Filter order of a dynamic filter or width (in number of points) for the gaussian + filter. + sw_filter_cutoff_frq(NX_NUMBER): + doc: | + Cutoff frequency for dynamic filters. + z_offset(NX_NUMBER): + unit: NX_LENGTH + doc: | + Offset added to the initial averaged position Zaver before starting to sweep. + This parameter is disabled when Z-Controller to Hold is deselected in the + Advanced section. The LED “Alt” next to the Z offset indicates if an alternate + Z-controller setpoint is enabled. + settling_time(NX_NUMBER): + unit: NX_TIME + doc: | + time to wait after changing the bias to the next level and before starting to + acquire data. + end_settling_time(NX_NUMBER): + unit: NX_TIME + doc: | + Time to wait after the sweep has finished and the bias is ramped to the initial + value. + z_control_time(NX_NUMBER): + unit: NX_TIME + doc: | + Time during which the Z-Controller is enabled once a sweep has finished. When + averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled for this + duration between each sweep. After the last sweep, it will wait the specified + time before continuing a running scan. This ensures each sweep reliably starts + from the same position. This parameter is disabled when Z-Controller to Hold is + deselected in the Advanced section. + max_sew_rate(NX_NUMBER): + doc: | + Maximum rate at which the bias changes (before, during and after sweeping). + (V/s) + backward_sweep(NX_BOOLEAN): + doc: | + Select whether to measure the backward (return) sweep or the forward only. + z_controller_hold(NX_BOOLEAN): + doc: | + Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. + It is selected by default. When deselected, Z-offset and Z-control time + parameters are disabled. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# a6b94f019c914824a8a0ec5b134141063c65e973450f5b7ec9ac852e29aac455 +# +# +# +# +# +# Application definition for bias devices. +# +# +# +# Applied a voltage between tip and sample. +# +# +# +# +# The ratio between the tunneling current at the sample surface and the bias voltage +# applied between the sample and the tip. +# +# +# +# +# Calibration of the Bias output (V/V). +# +# +# +# +# Allows compensating for an offset in Bias. Hardware parameter offset. +# +# +# +# +# Sets the amplitude (in physical units of the modulated signal) of the sine +# modulation. +# +# +# +# +# Bias sweeps while measuring arbitrary channels with I(V) curves. +# +# +# +# +# Select the channels to record. +# +# +# +# +# When selected, the Bias voltage returns to the initial value (before starting the sweep) at +# the end of the spectroscopy measurement (default). When not selected, Bias remains at the +# last value of the sweep. This is useful e.g. when combining several sweep segments. Example +# for an automated measurement (using Programming Interface): switch off Z-Controller, start +# spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, +# switch on Z-Controller. +# +# +# +# +# Select whether to record the Z position during Z averaging time at the end of +# the sweep (after Z control time) and store the average value in the header of +# the file when saving. Using this option increases the sweep time by Z averaging +# time. +# +# +# +# +# Select whether to set the Lock-In to run during the measurement. When using this +# feature, make sure the Lock-In is configured correctly and settling times are +# set to twice the Lock-In period at least. This option is ignored when Lock-In is +# already running. This option is disabled if the Sweep Mode is MLS and the flag +# to configure the Lock-In per segment in the Multiline segment editor is set. +# +# +# +# +# Time during which the spectroscopy data are acquired and averaged. +# +# +# +# +# Number of sweeps to measure and average. +# +# +# +# +# The first bias values of the sweep. +# +# +# +# +# The last bias values of the sweep. +# +# +# +# +# Define the sweep number of points, that is, the maximum spectrum resolution eq. +# Bias window divide by Num Pixel. +# +# +# +# +# Duration over which the Z position is recorded and averaged before and after the +# sweep (the latter only if Record final Z position is selected in the Advanced +# section). After the initial Z averaging time, if Z-Controller to Hold is +# selected in the Advanced section, the Z-Controller is set to hold and the tip is +# placed at the previously averaged Z position (plus Z offset). +# +# +# +# +# Select a filter to smooth the displayed data. When saving, if any filter +# selected, filtered data are saved to file along with the unfiltered data. +# +# +# +# +# Filter order of a dynamic filter or width (in number of points) for the gaussian +# filter. +# +# +# +# +# Cutoff frequency for dynamic filters. +# +# +# +# +# Offset added to the initial averaged position Zaver before starting to sweep. +# This parameter is disabled when Z-Controller to Hold is deselected in the +# Advanced section. The LED “Alt” next to the Z offset indicates if an alternate +# Z-controller setpoint is enabled. +# +# +# +# +# time to wait after changing the bias to the next level and before starting to +# acquire data. +# +# +# +# +# Time to wait after the sweep has finished and the bias is ramped to the initial +# value. +# +# +# +# +# Time during which the Z-Controller is enabled once a sweep has finished. When +# averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled for this +# duration between each sweep. After the last sweep, it will wait the specified +# time before continuing a running scan. This ensures each sweep reliably starts +# from the same position. This parameter is disabled when Z-Controller to Hold is +# deselected in the Advanced section. +# +# +# +# +# Maximum rate at which the bias changes (before, during and after sweeping). +# (V/s) +# +# +# +# +# Select whether to measure the backward (return) sweep or the forward only. +# +# +# +# +# Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. +# It is selected by default. When deselected, Z-offset and Z-control time +# parameters are disabled. +# +# +# diff --git a/contributed_definitions/nyaml/NXiv_temp.yaml b/contributed_definitions/nyaml/NXiv_temp.yaml new file mode 100644 index 0000000000..732b36f25a --- /dev/null +++ b/contributed_definitions/nyaml/NXiv_temp.yaml @@ -0,0 +1,164 @@ +category: application +doc: | + Application definition for temperature-dependent IV curve measurements. + + In this application definition, times should be specified always together + with an UTC offset. + + This is the application definition describing temperature dependent IV curve + measurements. For this a temperature is set. After reaching the temperature, + a voltage sweep is performed. For each voltage a current is measured. + Then, the next desired temperature is set and an IV measurement is performed. +symbols: + n_different_temperatures: | + Number of different temperature setpoints used in the experiment. + n_different_voltages: | + Number of different voltage setpoints used in the experiment. +type: group +NXiv_temp(NXsensor_scan): + (NXentry): + definition: + enumeration: [NXiv_temp] + (NXsample): + exists: recommended + name: + doc: | + Descriptive name or ideally (globally) unique persistent identifier. + 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. + (NXinstrument): + (NXenvironment): + doc: | + Describes an environment setup for a temperature-dependent IV measurement experiment. + + The temperature and voltage must be present as independently scanned controllers and + the current sensor must also be present with its readings. + voltage_controller(NXsensor): + temperature_controller(NXsensor): + current_sensor(NXsensor): + (NXdata): + doc: | + This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. + There should also be two more fields called temperature and voltage containing the setpoint values. + There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension + equal to the number of voltage setpoints. + temperature(NX_NUMBER): + voltage(NX_NUMBER): + current(NX_NUMBER): + dimensions: + rank: 2 + dim: [[1, n_different_temperatures], [2, n_different_voltages]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# d0ebd176fc6c8eb6b9ba8d1a766808a44ac9777a307638e6a22714cdecbda7f9 +# +# +# +# +# +# +# +# Number of different temperature setpoints used in the experiment. +# +# +# +# +# Number of different voltage setpoints used in the experiment. +# +# +# +# +# Application definition for temperature-dependent IV curve measurements. +# +# In this application definition, times should be specified always together +# with an UTC offset. +# +# This is the application definition describing temperature dependent IV curve +# measurements. For this a temperature is set. After reaching the temperature, +# a voltage sweep is performed. For each voltage a current is measured. +# Then, the next desired temperature is set and an IV measurement is performed. +# +# +# +# +# +# +# +# +# +# +# Descriptive name or ideally (globally) unique persistent identifier. +# +# +# +# +# List of comma-separated elements from the periodic table +# that are contained in the sample. +# If the sample substance has multiple components, all +# elements from each component must be included in `atom_types`. +# +# The purpose of the field is to offer materials database systems an +# opportunity to parse the relevant elements without having to interpret +# these from the sample history or from other data sources. +# +# +# +# +# +# +# Describes an environment setup for a temperature-dependent IV measurement experiment. +# +# The temperature and voltage must be present as independently scanned controllers and +# the current sensor must also be present with its readings. +# +# +# +# +# +# +# +# +# This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. +# There should also be two more fields called temperature and voltage containing the setpoint values. +# There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension +# equal to the number of voltage setpoints. +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXlab_electro_chemo_mechanical_preparation.yaml b/contributed_definitions/nyaml/NXlab_electro_chemo_mechanical_preparation.yaml new file mode 100644 index 0000000000..bbc1a500c3 --- /dev/null +++ b/contributed_definitions/nyaml/NXlab_electro_chemo_mechanical_preparation.yaml @@ -0,0 +1,317 @@ +category: application +doc: | + Grinding and polishing of a sample using abrasives in a wet lab. + Manual procedures, electro-chemical, vibropolishing. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXlab_electro_chemo_mechanical_preparation(NXobject): + (NXentry): + + # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently + \@version: + doc: | + Version specifier of this application definition. + definition: + doc: | + Official NeXus NXDL schema with which this file was written. + enumeration: [NXlab_electro_chemo_mechanical_preparation] + workflow_step_identifier(NX_UINT): + workflow_step_description: + SAMPLE(NXsample): + exists: ['min', '1', 'max', '1'] + USER(NXuser): + exists: ['min', '1', 'max', 'unbounded'] + + # (NXlab_grinding_machine): + grinding_machine(NXfabrication): + vendor: + model: + identifier: + exists: recommended + GRINDING_STEP(NXprocess): + doc: | + A preparation step performed by a human or a robot/automated system. + + # maybe a user per step as sometimes samples are prepared by more than + # one person or not each person performs all polishing steps + sequence_index(NX_POSINT): + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + abrasive_medium_carrier: + doc: | + Carrier/plate used on which the abrasive/(lubricant) mixture was applied. + + # enumeration: [plate] + # controlled vocabulary items + abrasive_medium: + doc: | + Medium on the abrasive_medium_carrier (cloth or grinding plate) + whereby material is abrasively weared. + + # enumeration: [SiC180] + # controlled vocabulary items or instance of chemical, need for free-text? + # also need for free-text in subsequent files? + lubricant: + doc: | + Lubricant + + # enumeration: [none, water, ethanol, oil] + # from a list of controlled vocabulary items, or instance of chemical + # etching/corrosive attack, tracking the environment, what can we + # learn from our colleagues within NFDI4Cat, NFDI4Chem, and NFDI-MatWerk? + rotation_control: + doc: | + Qualitative statement how the revelation of the machine was configured. + If the rotation was controlled manually, e.g. by turning knobs + choose manual and estimate the nominal average rotation. + If the rotation was controlled via choosing from a fixed set + of options offered by the machine choose fixed and + specify the nominal rotation. + If programmed use rotation_history (e.g. for automated/robot systems). + enumeration: [undefined, manual, fixed, programmed] + force_control: + doc: | + Qualitative statement how the (piston) force with which the sample + was pressed into/against the abrasive medium was controlled if at all. + If the force was controlled manually e.g. by turning knobs + choose manual and estimate nominal average force. + If the force was controlled via choosing from a fixed set + of options offered by the machine choose fixed and + specify the nominal force. + If programmed use force_history (e.g. for automated/robot systems). + enumeration: [undefined, manual, fixed, programmed] + time_control: + doc: | + Qualitative statement for how long (assuming regular uninterrupted) + preparation at the specified conditions the preparation step was + applied. + enumeration: [undefined, manual, fixed, programmed] + rotation(NX_NUMBER): + unit: NX_FREQUENCY + doc: | + Turns per unit time. + + # rotation_history(NX_NUMBER): + force(NX_NUMBER): + unit: NX_ANY + doc: | + Force exerted on the sample to press it into the abrasive. + + # force-history(NX_NUMBER): + time(NX_NUMBER): + unit: NX_TIME + doc: | + Seconds + removal: + doc: | + Qualitative statement how the material removal was characterized. + enumeration: [undefined, estimated, measured] + thickness_reduction(NX_NUMBER): + unit: NX_LENGTH + doc: | + How thick a layer was removed. + + # time_history(NX_NUMBER): + # SENSOR_SCAN(NXsensor_scan): + # electro-chemical preparation is nothing but an I(V) curve within + # a corrosive medium, eventually some wet lab steps have characteristics + # of pure grinding, mechanical polishing, or a mixture with corrosive + # attack + CLEANING_STEP(NXprocess): + doc: | + A preparation step performed by a human or a robot/automated system + with the aim to remove residual abrasive medium from the specimen surface. + sequence_index(NX_POSINT): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# a2826c4a9cb1e0eb52d77a18d6ef8832462f14f6b96c118099419f8603362bac +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Grinding and polishing of a sample using abrasives in a wet lab. +# Manual procedures, electro-chemical, vibropolishing. +# +# +# +# +# +# Version specifier of this application definition. +# +# +# +# +# Official NeXus NXDL schema with which this file was written. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# A preparation step performed by a human or a robot/automated system. +# +# +# +# +# +# +# +# Carrier/plate used on which the abrasive/(lubricant) mixture was applied. +# +# +# +# +# +# Medium on the abrasive_medium_carrier (cloth or grinding plate) +# whereby material is abrasively weared. +# +# +# +# +# +# Lubricant +# +# +# +# +# +# Qualitative statement how the revelation of the machine was configured. +# If the rotation was controlled manually, e.g. by turning knobs +# choose manual and estimate the nominal average rotation. +# If the rotation was controlled via choosing from a fixed set +# of options offered by the machine choose fixed and +# specify the nominal rotation. +# If programmed use rotation_history (e.g. for automated/robot systems). +# +# +# +# +# +# +# +# +# +# +# Qualitative statement how the (piston) force with which the sample +# was pressed into/against the abrasive medium was controlled if at all. +# If the force was controlled manually e.g. by turning knobs +# choose manual and estimate nominal average force. +# If the force was controlled via choosing from a fixed set +# of options offered by the machine choose fixed and +# specify the nominal force. +# If programmed use force_history (e.g. for automated/robot systems). +# +# +# +# +# +# +# +# +# +# +# Qualitative statement for how long (assuming regular uninterrupted) +# preparation at the specified conditions the preparation step was +# applied. +# +# +# +# +# +# +# +# +# +# +# Turns per unit time. +# +# +# +# +# +# Force exerted on the sample to press it into the abrasive. +# +# +# +# +# +# Seconds +# +# +# +# +# Qualitative statement how the material removal was characterized. +# +# +# +# +# +# +# +# +# +# How thick a layer was removed. +# +# +# +# +# +# +# A preparation step performed by a human or a robot/automated system +# with the aim to remove residual abrasive medium from the specimen surface. +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXlab_sample_mounting.yaml b/contributed_definitions/nyaml/NXlab_sample_mounting.yaml new file mode 100644 index 0000000000..3963b841f5 --- /dev/null +++ b/contributed_definitions/nyaml/NXlab_sample_mounting.yaml @@ -0,0 +1,151 @@ +category: application +doc: | + Embedding of a sample in a medium for easing processability. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXlab_sample_mounting(NXobject): + (NXentry): + + # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently + \@version: + doc: | + Version specifier of this application definition. + definition: + doc: | + Official NeXus NXDL schema with which this file was written. + enumeration: [NXlab_sample_mounting] + SAMPLE(NXsample): + exists: ['min', '1', 'max', '1'] + USER(NXuser): + exists: ['min', '1', 'max', 'unbounded'] + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + + # (NXlab_mounting_machine): + mounting_machine(NXfabrication): + vendor: + model: + identifier: + exists: recommended + mounting_method: + doc: | + Qualitative statement how the sample was mounted. + enumeration: [cold_mounting, hot_mounting] + embedding_medium: + doc: | + Type of material. + enumeration: [resin, epoxy] + electrical_conductivity(NX_FLOAT): + unit: NX_ANY + doc: | + Electrical conductivity of the embedding medium. + + # temperature control of the mounting (e.g. relevant when hot_mounting Al) + # cleaning procedures + # a descriptor of the shape of the specimen + # borrow from NXlab_thermo_mechanical_processing to document the external + # stimuli (eventually) applied during mounting + # temperature, mechanical, magnetic, electro-magnetic, are externally + # applied stimuli on the sample, can we use one master schema? + # e.g. one can even store NXcg_polyhedron_set and NXcg_face_list_data_structure + # instances to keep track of the geometry of specific instrument and how + # the samples were arranged in these + # key question is which steps has the sample experienced? + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 1edd9800a540016328456efebddc4ba62635309c1b0a8d7722d35ac79279ff05 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Embedding of a sample in a medium for easing processability. +# +# +# +# +# +# Version specifier of this application definition. +# +# +# +# +# Official NeXus NXDL schema with which this file was written. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Qualitative statement how the sample was mounted. +# +# +# +# +# +# +# +# +# Type of material. +# +# +# +# +# +# +# +# +# Electrical conductivity of the embedding medium. +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXlens_em.yaml b/contributed_definitions/nyaml/NXlens_em.yaml new file mode 100644 index 0000000000..36a48e9154 --- /dev/null +++ b/contributed_definitions/nyaml/NXlens_em.yaml @@ -0,0 +1,175 @@ +category: base +doc: | + 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 `_ +type: group +NXlens_em(NXobject): + type: + doc: | + Qualitative type of lens with respect to the number of pole pieces. + enumeration: [single, double, quadrupole, hexapole, octupole] + name: + doc: | + Given name, alias, colloquial, or short name for the lens. + For manufacturer names and identifiers use respective manufacturer fields. + manufacturer_name: + doc: | + Name of the manufacturer who built/constructed the lens. + (NXfabrication): + model: + doc: | + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the lens. + description: + doc: | + Ideally an identifier, persistent link, or free text which gives further details + about the lens. + voltage(NX_NUMBER): + unit: NX_VOLTAGE + doc: | + Excitation voltage of the lens. For dipoles it is a single number. For higher + orders, it is an array. + current(NX_NUMBER): + unit: NX_CURRENT + doc: | + Excitation current of the lens. For dipoles it is a single number. For higher + orders, it is an array. + value(NX_NUMBER): + unit: NX_ANY + doc: | + This field should be used when the exact voltage or current of the lens is not directly controllable + as the control software of the microscope does not enable users/or is was not configured to enable + the user to retrieve these values. In this case this field should be used to specify the value as + read from the control software. Although consumers of the application definition should not expect + this value to represent the exact physical voltage or excitation, it is still useful to know though + as it allows other users to reuse this lens setting, which, provided a properly working instrument + and software should bring the lenses into a similar state. + depends_on: + doc: | + Specifies the position of the lens by pointing to the last transformation in the + transformation chain in the NXtransformations group. + (NXtransformations): + doc: | + Collection of axis-based translations and rotations to describe the + location and geometry of the lens as a component in the instrument. + Typically, the components of a system should all be related relative to + each other and only one component should relate to the reference + coordinate system. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 8d5e9bc3e4abc9080a281a455f74761c9bdcd71e4d81cb4aaa7b25f182419500 +# +# +# +# +# +# Description of an electro-magnetic lens or a compound lens. +# +# For NXtransformations the origin of the coordinate system is placed +# in the center of the lens +# (its polepiece, pinhole, or another point of reference). +# The origin should be specified in the NXtransformations. +# +# For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ +# +# +# +# Qualitative type of lens with respect to the number of pole pieces. +# +# +# +# +# +# +# +# +# +# +# +# Given name, alias, colloquial, or short name for the lens. +# For manufacturer names and identifiers use respective manufacturer fields. +# +# +# +# +# Name of the manufacturer who built/constructed the lens. +# +# +# +# +# +# Hardware name, hash identifier, or serial number that was given by the +# manufacturer to identify the lens. +# +# +# +# +# Ideally an identifier, persistent link, or free text which gives further details +# about the lens. +# +# +# +# +# Excitation voltage of the lens. For dipoles it is a single number. For higher +# orders, it is an array. +# +# +# +# +# Excitation current of the lens. For dipoles it is a single number. For higher +# orders, it is an array. +# +# +# +# +# This field should be used when the exact voltage or current of the lens is not directly controllable +# as the control software of the microscope does not enable users/or is was not configured to enable +# the user to retrieve these values. In this case this field should be used to specify the value as +# read from the control software. Although consumers of the application definition should not expect +# this value to represent the exact physical voltage or excitation, it is still useful to know though +# as it allows other users to reuse this lens setting, which, provided a properly working instrument +# and software should bring the lenses into a similar state. +# +# +# +# +# Specifies the position of the lens by pointing to the last transformation in the +# transformation chain in the NXtransformations group. +# +# +# +# +# Collection of axis-based translations and rotations to describe the +# location and geometry of the lens as a component in the instrument. +# Typically, the components of a system should all be related relative to +# each other and only one component should relate to the reference +# coordinate system. +# +# +# diff --git a/contributed_definitions/nyaml/NXlens_opt.yaml b/contributed_definitions/nyaml/NXlens_opt.yaml new file mode 100644 index 0000000000..625aa9c40b --- /dev/null +++ b/contributed_definitions/nyaml/NXlens_opt.yaml @@ -0,0 +1,307 @@ +category: base +doc: | + Description of an optical lens. +symbols: + N_spectrum: | + Size of the wavelength array for which the refractive index of the material + is given. + N_spectrum_coating: | + Size of the wavelength array for which the refractive index of the coating + is given. + N_spectrum_RT: | + Size of the wavelength array for which the reflectance or transmission of + the lens is given. + +# A draft of a new base class describing an optical lens +# (Note: NXlens_em describes an electro-magnetic lens or a compound lens) +type: group +NXlens_opt(NXobject): + type: + doc: | + Type of the lens (e.g. concave, convex etc.). + enumeration: [biconcave, plano-concave, convexo-concave, biconvex, plano-convex, concavo-convex, Fresnel lens, other] + other_type: + doc: | + If you chose 'other' as type specify what it is. + chromatic(NX_BOOLEAN): + doc: | + Is it a chromatic lens? + lens_diameter(NX_NUMBER): + unit: NX_LENGTH + doc: | + Diameter of the lens. + substrate(NXsample): + doc: | + Properties of the substrate material of the lens. If the lens has a + coating specify the coating material and its properties in 'coating'. + substrate_material: + doc: | + Specify the substrate material of the lens. + substrate_thickness(NX_NUMBER): + unit: NX_LENGTH + doc: | + Thickness of the lens substrate at the optical axis. + index_of_refraction(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Complex index of refraction of the lens material. Specify at given + wavelength (or energy, wavenumber etc.) values. + dimensions: + rank: 2 + dim: [[1, 2], [2, N_spectrum]] + COATING(NXsample): + + # Used captial letters for COATING so that more than one can be defined if + # the lens has different coatings on the front and back side. + doc: | + If the lens has a coating describe the material and its properties. + Some basic information can be found e.g. [here] + (https://www.opto-e.com/basics/reflection-transmission-and-coatings). + If the back and front side of the lens are coated with different + materials, use separate COATING(NXsample) fields to describe the coatings + on the front and back side, respectively. For example: + coating_front(NXsample) and coating_back(NXsample). + coating_type: + doc: | + Specify the coating type (e.g. dielectric, anti-reflection (AR), + multilayer coating etc.). + coating_material: + doc: | + Describe the coating material (e.g. MgF2). + coating_thickness(NX_NUMBER): + unit: NX_LENGTH + doc: | + Thickness of the coating. + index_of_refraction_coating(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Complex index of refraction of the coating. Specify at given spectral + values (wavelength, energy, wavenumber etc.). + dimensions: + rank: 2 + dim: [[1, 2], [2, N_spectrum_coating]] + reflectance: + unit: NX_UNITLESS + doc: | + Reflectance of the lens at given spectral values. + dimensions: + rank: 1 + dim: [[1, N_spectrum_RT]] + transmission: + unit: NX_UNITLESS + doc: | + Transmission of the lens at given spectral values. + dimensions: + rank: 1 + dim: [[1, N_spectrum_RT]] + focal_length(NX_NUMBER): + exists: recommended + unit: NX_LENGTH + doc: | + Focal length of the lens on the front side (first value), i.e. where the + beam is incident, and on the back side (second value). + dimensions: + rank: 1 + dim: [[1, 2]] + curvature_radius_FACE(NX_NUMBER): + exists: recommended + unit: NX_LENGTH + doc: | + Curvature radius of the lens. + Instead of 'FACE' in the name of this field, the user is advised to + specify for which surface (e.g. front or back) the curvature is provided: + e.g. curvature_front or curvature_back. The front face is the surface on + which the light beam is incident, while the back face is the one from + which the light beam exits the lens. + Abbe_number(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Abbe number (or V-number) of the lens. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 691e29df6cdccccbeb03000ebbd435adb2c77135939ffb1d329d7da9d11c6539 +# +# +# +# +# +# +# +# +# Size of the wavelength array for which the refractive index of the material +# is given. +# +# +# +# +# Size of the wavelength array for which the refractive index of the coating +# is given. +# +# +# +# +# Size of the wavelength array for which the reflectance or transmission of +# the lens is given. +# +# +# +# +# Description of an optical lens. +# +# +# +# Type of the lens (e.g. concave, convex etc.). +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# If you chose 'other' as type specify what it is. +# +# +# +# +# Is it a chromatic lens? +# +# +# +# +# Diameter of the lens. +# +# +# +# +# Properties of the substrate material of the lens. If the lens has a +# coating specify the coating material and its properties in 'coating'. +# +# +# +# Specify the substrate material of the lens. +# +# +# +# +# Thickness of the lens substrate at the optical axis. +# +# +# +# +# Complex index of refraction of the lens material. Specify at given +# wavelength (or energy, wavenumber etc.) values. +# +# +# +# +# +# +# +# +# +# +# If the lens has a coating describe the material and its properties. +# Some basic information can be found e.g. [here] +# (https://www.opto-e.com/basics/reflection-transmission-and-coatings). +# If the back and front side of the lens are coated with different +# materials, use separate COATING(NXsample) fields to describe the coatings +# on the front and back side, respectively. For example: +# coating_front(NXsample) and coating_back(NXsample). +# +# +# +# Specify the coating type (e.g. dielectric, anti-reflection (AR), +# multilayer coating etc.). +# +# +# +# +# Describe the coating material (e.g. MgF2). +# +# +# +# +# Thickness of the coating. +# +# +# +# +# Complex index of refraction of the coating. Specify at given spectral +# values (wavelength, energy, wavenumber etc.). +# +# +# +# +# +# +# +# +# +# Reflectance of the lens at given spectral values. +# +# +# +# +# +# +# +# Transmission of the lens at given spectral values. +# +# +# +# +# +# +# +# Focal length of the lens on the front side (first value), i.e. where the +# beam is incident, and on the back side (second value). +# +# +# +# +# +# +# +# Curvature radius of the lens. +# Instead of 'FACE' in the name of this field, the user is advised to +# specify for which surface (e.g. front or back) the curvature is provided: +# e.g. curvature_front or curvature_back. The front face is the surface on +# which the light beam is incident, while the back face is the one from +# which the light beam exits the lens. +# +# +# +# +# Abbe number (or V-number) of the lens. +# +# +# diff --git a/contributed_definitions/nyaml/NXlockin.yaml b/contributed_definitions/nyaml/NXlockin.yaml new file mode 100644 index 0000000000..b59b69a916 --- /dev/null +++ b/contributed_definitions/nyaml/NXlockin.yaml @@ -0,0 +1,252 @@ +category: base +doc: | + Base classes definition for lock in devices. +type: group +NXlockin(NXobject): + hardware(NXfabrication): + doc: | + Hardware manufacturers and type of lockin amplifier. + (NXamplifier): + doc: | + By mixing the input signal (STS signal) with the modulated signal (such as Bias) + and comparing it with the reference signal, they are enhanced and the effects of + noise interference are reduced, resulting in more accurate measurements. + bias_divider: + doc: | + if Lock-in -- Bias Divider 1/10 or 1/100, Bias divider = + V(ref)/[V(ref)+V(input)] + modulation_status(NX_BOOLEAN): + doc: | + Switch the lock-in moulation on or off. + modulation_signal: + doc: | + A modulation signal (such as bias, current et.al.) is a periodic voltage signal, + usually applied to the surface of a sample, which serves to modify the physical + properties of the sample surface and generate weak AC current signals that can + be detected and analysed by instruments such as lock-in amplifiers. + + # (For bais modulate signal, it depands on the modulate type) + modulation_amplitude(NX_NUMBER): + unit: NX_VOLTAGE + doc: | + Sets the amplitude (in physical units of the modulated signal) of the sine + modulation. + modulation_frequency(NX_NUMBER): + unit: NX_FREQUENCY + doc: | + Sets the frequency of the sine modulation added to the signal to modulate. + demodulated_signal: + doc: | + The input signal (STS signal) will be demodulated, in order to determine the amplitude + and phase at the frequency set in the Frequency field or harmonics, such as current, + bias, et.al. + + # output (demodulated signal) characterisation (foreach channel, like demodulation, a separate sensor output, e.g. X,Y) + number_of_demodulator_channels(NX_NUMBER): + doc: | + The number of signals which will be demodulated. + low_pass(NX_NUMBER): + unit: NX_FREQUENCY + doc: | + Order and cut-off frequency of the low-pass filter applied on the demodulated + signals (X,Y). Cut-off frq (low pass filter) (foreach DemodulatorChannels) + hi_pass(NX_NUMBER): + unit: NX_FREQUENCY + doc: | + Order and cut-off frequency of the high-pass filter applied on the demodulation + signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) + lp_filter_cutoff(NX_NUMBER): + unit: NX_FREQUENCY + doc: | + Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) + value) for D1. The filter is applied to the demodulated signals (X,Y). + lp_filter_order(NX_NUMBER): + doc: | + Order and cut-off frequency of the low-pass filter applied on the demodulated + signals (X,Y). Reducing the bandwidth or increasing the order reduces noise on + the demodulated signals, but will require longer settling and measurement times. + hp_filter_cutoff(NX_NUMBER): + unit: NX_FREQUENCY + doc: | + Sets the cut-off frequency of the high-pass filter (affects the displayed TC (s) + value) for D1. The filter is applied to the demodulated signals (X,Y). + hp_filter_order(NX_NUMBER): + doc: | + Order and cut-off frequency of the high-pass filter applied on the demodulation + signal of D!. This is used mainly to suppress a DC component of the demodulation + signal, which would lead to a component at modulation frequency in the + demodulated signals. + sync(NX_BOOLEAN): + doc: | + Switch on/off the Sync filter on the demodulated signals (X,Y) on or off. + (foreach DemodulatorChannels) + ref_phase_N(NX_NUMBER): + unit: NX_FREQUENCY + doc: | + Reference phase for the sine on the demodulated signal with respect to the + modulation signal. (foreach DemodulatorChannels) + integration_time(NX_NUMBER): + unit: NX_TIME + doc: | + Time during which the data are acquired and averaged. (for the input filter) + harmonic_order_N(NX_NUMBER): + doc: | + The order of the harmonic oscillation to detect on the demodulated signals. + (with respect to the modulation frequency) + sensitivity_factor(NX_NUMBER): + doc: | + Ratio of output signal amplitude to input signal amplitue (V/V). (input gain) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# c73589fddbb7b57d065748d989ab0d3d9e421b9163f8a4b4ab305b1b18bf82a8 +# +# +# +# +# +# Base classes definition for lock in devices. +# +# +# +# Hardware manufacturers and type of lockin amplifier. +# +# +# +# +# By mixing the input signal (STS signal) with the modulated signal (such as Bias) +# and comparing it with the reference signal, they are enhanced and the effects of +# noise interference are reduced, resulting in more accurate measurements. +# +# +# +# +# if Lock-in -- Bias Divider 1/10 or 1/100, Bias divider = +# V(ref)/[V(ref)+V(input)] +# +# +# +# +# Switch the lock-in moulation on or off. +# +# +# +# +# A modulation signal (such as bias, current et.al.) is a periodic voltage signal, +# usually applied to the surface of a sample, which serves to modify the physical +# properties of the sample surface and generate weak AC current signals that can +# be detected and analysed by instruments such as lock-in amplifiers. +# +# +# +# +# +# Sets the amplitude (in physical units of the modulated signal) of the sine +# modulation. +# +# +# +# +# Sets the frequency of the sine modulation added to the signal to modulate. +# +# +# +# +# The input signal (STS signal) will be demodulated, in order to determine the amplitude +# and phase at the frequency set in the Frequency field or harmonics, such as current, +# bias, et.al. +# +# +# +# +# +# The number of signals which will be demodulated. +# +# +# +# +# Order and cut-off frequency of the low-pass filter applied on the demodulated +# signals (X,Y). Cut-off frq (low pass filter) (foreach DemodulatorChannels) +# +# +# +# +# Order and cut-off frequency of the high-pass filter applied on the demodulation +# signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) +# +# +# +# +# Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) +# value) for D1. The filter is applied to the demodulated signals (X,Y). +# +# +# +# +# Order and cut-off frequency of the low-pass filter applied on the demodulated +# signals (X,Y). Reducing the bandwidth or increasing the order reduces noise on +# the demodulated signals, but will require longer settling and measurement times. +# +# +# +# +# Sets the cut-off frequency of the high-pass filter (affects the displayed TC (s) +# value) for D1. The filter is applied to the demodulated signals (X,Y). +# +# +# +# +# Order and cut-off frequency of the high-pass filter applied on the demodulation +# signal of D!. This is used mainly to suppress a DC component of the demodulation +# signal, which would lead to a component at modulation frequency in the +# demodulated signals. +# +# +# +# +# Switch on/off the Sync filter on the demodulated signals (X,Y) on or off. +# (foreach DemodulatorChannels) +# +# +# +# +# Reference phase for the sine on the demodulated signal with respect to the +# modulation signal. (foreach DemodulatorChannels) +# +# +# +# +# Time during which the data are acquired and averaged. (for the input filter) +# +# +# +# +# The order of the harmonic oscillation to detect on the demodulated signals. +# (with respect to the modulation frequency) +# +# +# +# +# Ratio of output signal amplitude to input signal amplitue (V/V). (input gain) +# +# +# diff --git a/contributed_definitions/nyaml/NXmagnetic_kicker.yaml b/contributed_definitions/nyaml/NXmagnetic_kicker.yaml new file mode 100644 index 0000000000..317325e62a --- /dev/null +++ b/contributed_definitions/nyaml/NXmagnetic_kicker.yaml @@ -0,0 +1,102 @@ +category: base +doc: | + definition for a magnetic kicker. +type: group +NXmagnetic_kicker(NXobject): + description(NX_CHAR): + doc: | + extended description of the kicker. + beamline_distance(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + doc: | + define position of beamline element relative to production target + timing(NX_FLOAT): + unit: NX_TIME + exists: ['min', '0', 'max', '1'] + doc: | + kicker timing as defined by ``description`` attribute + \@description: + type: NX_CHAR + set_current(NX_FLOAT): + unit: NX_CURRENT + exists: ['min', '0', 'max', '1'] + doc: | + current set on supply. + read_current(NXlog): + exists: ['min', '0', 'max', '1'] + doc: | + current read from supply. + value: + unit: NX_CURRENT + set_voltage(NX_FLOAT): + unit: NX_VOLTAGE + exists: ['min', '0', 'max', '1'] + doc: | + voltage set on supply. + read_voltage(NXlog): + exists: ['min', '0', 'max', '1'] + doc: | + voltage read from supply. + value: + unit: NX_VOLTAGE + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 34b7476f76592e9226269d3b02886646193836d024fce656135de8c230c8119c +# +# +# +# +# definition for a magnetic kicker. +# +# extended description of the kicker. +# +# +# define position of beamline element relative to production target +# +# +# kicker timing as defined by ``description`` attribute +# +# +# +# current set on supply. +# +# +# current read from supply. +# +# +# +# voltage set on supply. +# +# +# voltage read from supply. +# +# +# diff --git a/contributed_definitions/nyaml/NXmanipulator.yaml b/contributed_definitions/nyaml/NXmanipulator.yaml new file mode 100644 index 0000000000..bbdbc71ff7 --- /dev/null +++ b/contributed_definitions/nyaml/NXmanipulator.yaml @@ -0,0 +1,161 @@ +category: base +doc: | + Extension of NXpositioner to include fields to describe the use of manipulators + in photoemission experiments. +type: group +NXmanipulator(NXobject): + name(NX_CHAR): + doc: | + Name of the manipulator. + description(NX_CHAR): + doc: | + A description of the manipulator. + type(NX_CHAR): + doc: | + Type of manipulator, Hexapod, Rod, etc. + cryocoolant(NX_BOOLEAN): + doc: | + Is cryocoolant flowing through the manipulator? + cryostat_temperature(NX_FLOAT): + unit: NX_TEMPERATURE + doc: | + Temperature of the cryostat (coldest point) + heater_power(NX_FLOAT): + unit: NX_POWER + doc: | + Power in the heater for temperature control. + sample_temperature(NX_FLOAT): + unit: NX_TEMPERATURE + doc: | + Temperature at the closest point to the sample. This field may also be found in + NXsample if present. + drain_current(NX_FLOAT): + unit: NX_CURRENT + doc: | + Current to neutralize the photoemission current. This field may also be found in + NXsample if present. + sample_bias(NX_FLOAT): + unit: NX_CURRENT + doc: | + Possible bias of the sample with trespect to analyser ground. This field may + also be found in NXsample if present. + (NXpositioner): + doc: | + Class to describe the motors that are used in the manipulator + depends_on(NX_CHAR): + doc: | + Refers to the last transformation specifying the positon of the manipulator in + the NXtransformations chain. + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# c527776b537badfe6de69128070ba851dfa9252963bb6cbb98c4af20298483ac +# +# +# +# +# +# Extension of NXpositioner to include fields to describe the use of manipulators +# in photoemission experiments. +# +# +# +# Name of the manipulator. +# +# +# +# +# A description of the manipulator. +# +# +# +# +# Type of manipulator, Hexapod, Rod, etc. +# +# +# +# +# Is cryocoolant flowing through the manipulator? +# +# +# +# +# Temperature of the cryostat (coldest point) +# +# +# +# +# Power in the heater for temperature control. +# +# +# +# +# Temperature at the closest point to the sample. This field may also be found in +# NXsample if present. +# +# +# +# +# Current to neutralize the photoemission current. This field may also be found in +# NXsample if present. +# +# +# +# +# Possible bias of the sample with trespect to analyser ground. This field may +# also be found in NXsample if present. +# +# +# +# +# Class to describe the motors that are used in the manipulator +# +# +# +# +# Refers to the last transformation specifying the positon of the manipulator in +# the NXtransformations chain. +# +# +# +# +# Collection of axis-based translations and rotations to describe the location and +# geometry of the manipulator as a component in the instrument. Conventions from +# the NXtransformations base class are used. In principle, the McStas coordinate +# system is used. The first transformation has to point either to another +# component of the system or . (for pointing to the reference frame) to relate it +# relative to the experimental setup. Typically, the components of a system should +# all be related relative to each other and only one component should relate to +# the reference coordinate system. +# +# +# diff --git a/contributed_definitions/nyaml/NXmatch_filter.yaml b/contributed_definitions/nyaml/NXmatch_filter.yaml new file mode 100644 index 0000000000..d42df74cdc --- /dev/null +++ b/contributed_definitions/nyaml/NXmatch_filter.yaml @@ -0,0 +1,95 @@ +category: base +doc: | + Settings of a filter to select or remove entries based on their value. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_values: | + How many different match values does the filter specify. +type: group +NXmatch_filter(NXobject): + method: + doc: | + Meaning of the filter: + Whitelist specifies which entries with said value to include. + Entries with all other values will be filtered out. + + Blacklist specifies which entries with said value to exclude. + Entries with all other values will be included. + enumeration: [whitelist, blacklist] + match(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Array of values to filter according to method. For example if the filter + specifies [1, 5, 6] and method is whitelist, only entries with values + matching 1, 5 or 6 will be processed. All other entries will be filtered + out. + dimensions: + rank: 1 + dim: [[1, n_values]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 658011327c521407a34c26bfa9eae3d21d763c4d975f4a8d514fcedf8ed18b36 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# How many different match values does the filter specify. +# +# +# +# +# Settings of a filter to select or remove entries based on their value. +# +# +# +# Meaning of the filter: +# Whitelist specifies which entries with said value to include. +# Entries with all other values will be filtered out. +# +# Blacklist specifies which entries with said value to exclude. +# Entries with all other values will be included. +# +# +# +# +# +# +# +# +# Array of values to filter according to method. For example if the filter +# specifies [1, 5, 6] and method is whitelist, only entries with values +# matching 1, 5 or 6 will be processed. All other entries will be filtered +# out. +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml new file mode 100644 index 0000000000..75af9af646 --- /dev/null +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -0,0 +1,615 @@ +category: application +doc: | + This is the most general application definition for multidimensional + photoelectron spectroscopy. +type: group +NXmpes(NXobject): + (NXentry): + title: + start_time(NX_DATE_TIME): + doc: | + Datetime of the start of the measurement. + definition: + \@version: + enumeration: [NXmpes] + (NXuser): + doc: | + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + name: + doc: | + Name 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: | + Full address (street, street number, ZIP, city, country) of the user's + affiliation. + email: + doc: | + Email address of the user. + orcid: + exists: recommended + doc: | + Author ID defined by https://orcid.org/. + (NXinstrument): + energy_resolution(NX_FLOAT): + unit: NX_ENERGY + (NXsource): + doc: | + The source used to generate the primary photons. Properties refer strictly to + parameters of the source, not of the output beam. For example, the energy of the + source is not the optical power of the beam, but the energy of the electron beam + in a synchrotron and so on. + type: + enumeration: [Synchrotron X-ray Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, UV Plasma Source, Metal Jet X-ray, HHG laser] + name: + probe: + doc: | + Type of probe. In photoemission it's always photons, so the full NIAC list is + restricted. + enumeration: [x-ray, ultraviolet, visible light] + (NXbeam): + distance(NX_NUMBER): + unit: NX_LENGTH + doc: | + Distance of the point of evaluation of the beam from the sample surface. + incident_energy(NX_FLOAT): + unit: NX_ENERGY + incident_energy_spread(NX_NUMBER): + exists: recommended + unit: NX_ENERGY + incident_polarization(NX_NUMBER): + exists: recommended + unit: NX_ANY + (NXelectronanalyser): + description: + energy_resolution(NX_FLOAT): + exists: recommended + unit: NX_ENERGY + doc: | + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. + fast_axes(NX_CHAR): + exists: recommended + slow_axes: + exists: recommended + (NXcollectioncolumn): + scheme: + doc: | + Scheme of the electron collection column. + enumeration: [Standard, Angular dispersive, Selective area, Deflector, PEEM, Momentum Microscope] + mode: + exists: recommended + projection: + exists: recommended + field_aperture(NXaperture): + exists: optional + doc: | + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + contrast_aperture(NXaperture): + exists: optional + doc: | + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + (NXenergydispersion): + scheme: + enumeration: [tof, hemispherical, double hemispherical, cylindrical mirror, display mirror, retarding grid] + pass_energy(NX_FLOAT): + unit: NX_ENERGY + energy_scan_mode: + entrance_slit(NXaperture): + exists: optional + doc: | + Size, position and shape of the entrance slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + exit_slit(NXaperture): + exists: optional + doc: | + Size, position and shape of the exit slit in dispersive analyzers. To add + additional or other slits use the APERTURE group of NXenergydispersion. + (NXdetector): + amplifier_type: + exists: recommended + doc: | + Type of electron amplifier in the first amplification step. + enumeration: [MCP, channeltron] + detector_type: + exists: recommended + doc: | + Description of the detector type. + enumeration: [DLD, Phosphor+CCD, Phosphor+CMOS, ECMOS, Anode, Multi-anode] + (NXdata): + exists: recommended + \@signal: + enumeration: [raw] + raw(NX_NUMBER): + doc: | + Raw data before calibration. + (NXmanipulator): + exists: optional + doc: | + Manipulator for positioning of the sample. + sample_temperature(NX_FLOAT): + exists: recommended + unit: NX_TEMPERATURE + drain_current(NX_FLOAT): + exists: recommended + unit: NX_CURRENT + sample_bias(NX_FLOAT): + exists: recommended + unit: NX_CURRENT + (NXprocess): + doc: | + 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 + energy_calibration(NXcalibration): + exists: optional + applied(NX_BOOLEAN): + doc: | + Has an energy calibration been applied? + calibrated_axis(NX_FLOAT): + exists: recommended + doc: | + This is the calibrated energy axis to be used for data plotting. + angular_calibration(NXcalibration): + exists: optional + applied(NX_BOOLEAN): + doc: | + Has an angular calibration been applied? + calibrated_axis(NX_FLOAT): + exists: recommended + doc: | + This is the calibrated angular axis to be used for data plotting. + spatial_calibration(NXcalibration): + exists: optional + applied(NX_BOOLEAN): + doc: | + Has an spatial calibration been applied? + calibrated_axis(NX_FLOAT): + exists: recommended + doc: | + This is the calibrated spatial axis to be used for data plotting. + momentum_calibration(NXcalibration): + exists: optional + applied(NX_BOOLEAN): + doc: | + Has an momentum calibration been applied? + calibrated_axis(NX_FLOAT): + exists: recommended + doc: | + This is the momentum axis to be used for data plotting. + (NXsample): + name: + chemical_formula: + exists: recommended + doc: | + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + sample_history(NXnote): + exists: recommended + doc: | + 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. + atom_types: + exists: recommended + doc: | + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + preparation_date(NX_DATE_TIME): + exists: recommended + doc: | + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). + preparation_description(NXnote): + doc: | + 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. + temperature(NX_FLOAT): + unit: NX_TEMPERATURE + doc: | + 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. + situation: + enumeration: [vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere] + gas_pressure(NX_FLOAT): + unit: NX_PRESSURE + bias(NX_FLOAT): + unit: NX_VOLTAGE + exists: optional + doc: | + Voltage applied to sample and sample holder. + (NXdata): + \@signal: + enumeration: [data] + data(NX_NUMBER): + unit: NX_ANY + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e618cc098656aa72e4a5bd743c85c5d9c9caa79cbe85d96b6e06fafd1d165d1b +# +# +# +# +# +# This is the most general application definition for multidimensional +# photoelectron spectroscopy. +# +# +# +# +# +# Datetime of the start of the measurement. +# +# +# +# +# +# +# +# +# +# +# Contact information of at least the user of the instrument or the investigator +# who performed this experiment. Adding multiple users if relevant is recommended. +# +# +# +# Name of the user. +# +# +# +# +# Name of the affiliation of the user at the point in time when the experiment was +# performed. +# +# +# +# +# Full address (street, street number, ZIP, city, country) of the user's +# affiliation. +# +# +# +# +# Email address of the user. +# +# +# +# +# Author ID defined by https://orcid.org/. +# +# +# +# +# +# +# +# The source used to generate the primary photons. Properties refer strictly to +# parameters of the source, not of the output beam. For example, the energy of the +# source is not the optical power of the beam, but the energy of the electron beam +# in a synchrotron and so on. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Type of probe. In photoemission it's always photons, so the full NIAC list is +# restricted. +# +# +# +# +# +# +# +# +# +# +# +# Distance of the point of evaluation of the beam from the sample surface. +# +# +# +# +# +# +# +# +# +# +# Energy resolution of the analyser with the current setting. May be linked from a +# NXcalibration. +# +# +# +# +# +# +# +# Scheme of the electron collection column. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The size and position of the field aperture inserted in the column. To add +# additional or other apertures use the APERTURE group of NXcollectioncolumn. +# +# +# +# +# The size and position of the contrast aperture inserted in the column. To add +# additional or other apertures use the APERTURE group of NXcollectioncolumn. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Size, position and shape of the entrance slit in dispersive analyzers. To add +# additional or other slits use the APERTURE group of NXenergydispersion. +# +# +# +# +# Size, position and shape of the exit slit in dispersive analyzers. To add +# additional or other slits use the APERTURE group of NXenergydispersion. +# +# +# +# +# +# +# Type of electron amplifier in the first amplification step. +# +# +# +# +# +# +# +# +# Description of the detector type. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Raw data before calibration. +# +# +# +# +# +# +# +# Manipulator for positioning of the sample. +# +# +# +# +# +# +# +# +# Document an event of data processing, reconstruction, or analysis for this data. +# Describe the appropriate axis calibrations for your experiment using one or more +# of the following NXcalibrations +# +# +# +# +# Has an energy calibration been applied? +# +# +# +# +# This is the calibrated energy axis to be used for data plotting. +# +# +# +# +# +# +# Has an angular calibration been applied? +# +# +# +# +# This is the calibrated angular axis to be used for data plotting. +# +# +# +# +# +# +# Has an spatial calibration been applied? +# +# +# +# +# This is the calibrated spatial axis to be used for data plotting. +# +# +# +# +# +# +# Has an momentum calibration been applied? +# +# +# +# +# This is the momentum axis to be used for data plotting. +# +# +# +# +# +# +# +# +# The chemical formula of the sample. For mixtures use the NXsample_component +# group in NXsample instead. +# +# +# +# +# A descriptor to keep track of the treatment of the sample before entering the +# photoemission experiment. Ideally, a full report of the previous operations, in +# any format (NXnote allows to add pictures, audio, movies). Alternatively, a +# reference to the location or a unique identifier or other metadata file. In the +# case these are not available, free-text description. +# +# +# +# +# List of comma-separated elements from the periodic table +# that are contained in the sample. +# If the sample substance has multiple components, all +# elements from each component must be included in `atom_types`. +# +# +# +# +# Date of preparation of the sample for the XPS experiment (i.e. cleaving, last +# annealing). +# +# +# +# +# Description of the surface preparation technique for the XPS experiment, i.e. +# UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report +# of the previous operations, in any format(NXnote allows to add pictures, audio, +# movies). Alternatively, a reference to the location or a unique identifier or +# other metadata file. In the case these are not available, free-text description. +# +# +# +# +# In the case of a fixed temperature measurement this is the scalar temperature of +# the sample. In the case of an experiment in which the temperature is changed and +# recoded, this is an array of length m of temperatures. This should be a link to +# /entry/instrument/manipulator/sample_temperature. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Voltage applied to sample and sample holder. +# +# +# +# +# +# +# +# +# +# +# +# Represents a measure of one- or more-dimensional photoemission counts, where the +# varied axis may be for example energy, momentum, spatial coordinate, pump-probe +# delay, spin index, temperature, etc. The axes traces should be linked to the +# actual encoder position in NXinstrument or calibrated axes in NXprocess. +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXms.yaml b/contributed_definitions/nyaml/NXms.yaml new file mode 100644 index 0000000000..d21ed3f3fe --- /dev/null +++ b/contributed_definitions/nyaml/NXms.yaml @@ -0,0 +1,993 @@ +category: application +doc: | + Application definition, spatiotemporal characterization of a microstructure. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_b: | + Number of boundaries of the bounding box or primitive to domain. + n_p: | + Number of parameter required for the chosen orientation parameterization. + c: | + Number of texture components identified. + +# key points to keep in mind when thinking about a general enough description for coarse-graining systems of atoms into +# so-called microstructural features of interest for which we may store also thermodynamic properties or other feature-specific descriptors +# several viewpoints how to coarse-grain are equally justified: grains are useful when there are crystallites with adjoining interfaces and # none, or only some statistical populations of defects and/or some spatially-well defined defects inside these +# however, if grains are build almost only from defects like dislocation walls, it might no longer be useful to define the grains +# as a well identifiable region whose majority volume shows long-range atomic periodicity (so that defining an orientation makes) sense. +# one could then rather describe the set of defects. Alternatively one could describe a material volume by sampling individual so-called +# material points (e.g. in continuum-scale plasticity models) or describe the material volume really from the atoms up +# but there are many terms used in materials engineering which people may want to distinguish which stand however between the scales e.g. +# lattice curvature, this is jargon with some truth in it but curvature has to be build from atoms and defects need to build the curvature +# dislocations are another good example where different research questions demand differently granularized descriptions e.g. +# average density, total line length, per character, per family, line length, curvature, jog, kink density, +# coarse-grainable structural motifs in the dislocation core, atomic structure +# also different scales one would like to distinguish as this is relevant when defects couple/show spatiotemporal correlations +# to specific mechanisms (e.g. phonons) or when defect affect the properties of other defects +# ambiguous choices: is the grain boundary part of the grain or is it an own defect? +# i.e. can/should we store grains as childs of their grain boundary set vs the interface the childs of the grains? +# Depending on the use case we need to have a flexible description which can address a continuum of descriptors: +# important is that one can logically map different features +# Length scale of homogeneity: With the reality of a multi-parameter space of all possible methods and effects and +# different external stimuli applied for real materials, simulations in computational materials science typically focus +# their analysis on a few individual, spatiotemporally constrained effects and boundary conditions for which the simulation +# is formulated, useful, interpretable, and comparable to experiment. +# Data structures for multi-scale materials modeling IMM/ICME are currently diverse because they reflect the above-mentioned needs +# and different views which researchers have on their simulations e.g. DFT (time, length-scale, which electronic effects) +# RVE annealing phenomena at the micrometer scale (pressure, temperature, length scale, interactions considered or not) +# Some regions are well separated spatially (although it can be non-trivial to quantify the distance in a multi-dim parameter space) +# Some simulations are cross-scale (classical MD at the cutting edge with micrometer crystal plasticity microsecond and/or annealing at +# ns time scale) MD with classical vs abinitio-informed potential for studying evolution of mechanisms and phenomena at different length scales +type: group +NXms(NXobject): + (NXentry): + \@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: [NXms] + workflow_identifier: + doc: | + Ideally, a (globally) unique persistent identifier + for referring to this experiment or computer simulation. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + workflow_description: + exists: optional + doc: | + Free-text description about the workflow (experiment/analysis/simulation). + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of this application definition rather than write details about the + experiment into this free-text description field. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + included when the characterization started. + end_time(NX_DATE_TIME): + exists: recommended + doc: | + ISO 8601 time code with local time zone offset to UTC included + when the characterization ended. + PROGRAM(NXprogram): + exists: ['min', '1', 'max', 'unbounded'] + program_name: + \@version: + experiment_or_simulation: + doc: | + Specify if the (characterization) results/data of this instance of an + application definition are based on the results of a simulation or the + results of a post-processing of measured data to describe + a microstructure. + + The term microstructure is used to describe the spatial arrangement of + crystal defects inside a sample/specimen without demanding necessarily + that this structure is mainly at the micron length scale. + Nanostructure and macrostructure are close synonyms. + Material architecture is a narrow synonym. + + Given that microstructure simulations nowadays more and more consider + the atomic arrangement, this application definition can also be used + to describe features at the scale of atoms. + enumeration: [experiment, simulation] + USER(NXuser): + exists: ['min', '0', 'max', 'unbounded'] + doc: | + Contact information and eventually details of at least one person + involved in creating this result. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is recommended. + 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. + specimen(NXsample): + + # NEW ISSUE: inject the conclusion from the discussion with Andrea + # according to SAMPLE.yaml 0f8df14 2022/06/15 + name: + doc: | + Descriptive name or ideally (globally) unique persistent identifier. + + # sample_history: + # 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. + # preparation_date(NX_DATE_TIME): + # doc: | + # ISO 8601 time code with local time zone offset to UTC information + # when the specimen was prepared. + (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): + doc: | + Container to hold different coordinate systems conventions. + A least a right-handed Cartesian coordinate system with base vectors + named x, y, and z has to be specified. Each base vector of the + coordinate system should be described with an NXtransformations instance. + TRANSFORMATIONS(NXtransformations): + exists: ['min', '3', 'max', 'unbounded'] + conventions(NXem_ebsd_conventions): + rotation_conventions(NXprocess): + three_dimensional_rotation_handedness: + rotation_convention: + euler_angle_convention: + axis_angle_convention: + orientation_parameterization_sign_convention: + processing_reference_frame(NXprocess): + reference_frame_type: + xaxis_direction: + xaxis_alias: + yaxis_direction: + yaxis_alias: + zaxis_direction: + zaxis_alias: + origin: + sample_reference_frame(NXprocess): + reference_frame_type: + xaxis_direction: + yaxis_direction: + zaxis_direction: + origin: + ROI_SET(NXcg_roi_set): + exists: ['min', '1', 'max', 'unbounded'] + + # however for solitary unit models (i.e. ensembles of volume elements/simulation domains) and for replica methods + # we may need more than one domain + # the volume element is not called representative because for what a volume element is representative is a matter of + # interpretation (fundamentally this is an assumption) and can differ for different descriptors + doc: | + The simulated or characterized material volume element aka domain. + At least one instance of geometry required either NXcg_grid, + NXcg_polyhedron_set, or NXcg_point_set. This geometry group needs + to contain details about the boundary conditions. + grid(NXcg_grid): + exists: optional + + # specific application definitions can use these fields to specialize + point_set(NXcg_point_set): + exists: optional + polyhedron_set(NXcg_polyhedron_set): + exists: optional + boundary(NXcg_polyhedron_set): + exists: optional + doc: | + A boundary to the volume element. + Either an instance of NXcg_hexahedron_set or of NXcg_ellipsoid_set. + + # a good example for a general bounding box description for such a grids of triclinic cells + # https://docs.lammps.org/Howto_triclinic.html NXcg_hexahedron_set because can be a parallelepiped + number_of_boundaries(NX_POSINT): + unit: NX_UNITLESS + doc: | + How many distinct boundaries are distinguished. Value required equal to n_b. + boundaries: + doc: | + Name of the boundaries. E.g. left, right, front, back, bottom, top, + dimensions: + rank: 1 + dim: [[1, n_b]] + boundary_conditions(NX_UINT): + unit: NX_UNITLESS + doc: | + The boundary conditions for each boundary: + + 0 - undefined + 1 - open + 2 - periodic + 3 - mirror + 4 - von Neumann + 5 - Dirichlet + dimensions: + rank: 1 + dim: [[1, n_b]] + snapshot_set(NXms_snapshot_set): + doc: | + Collection of microstructural data observed/simulated. + identifier_offset(NX_UINT): + unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for distinguishing + snapshots. Identifiers are defined either implicitly or explicitly. + For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate + if the identifiers are expected to start from 1 (referred to as + Fortran-/Matlab-) or from 0 (referred to as C-, Python-style index + notation) respectively. + + # essentially NXmonitor instances for evolution of ensemble summary statistics + evolution(NXprocess): + exists: optional + doc: | + Summary quantities which are the result of some post-processing of + the snapshot data (averaging, integrating, interpolating). + Frequently used descriptors from continuum mechanics and thermodynamics + can be used here. A few examples are given. Each descriptor is currently + modelled as an instance of an NXprocess because it is relevant to + understand how the descriptors are computed. + temperature(NXprocess): + exists: optional + pressure(NXprocess): + exists: optional + stress(NXprocess): + exists: optional + strain(NXprocess): + exists: optional + deformation_gradient(NXprocess): + exists: optional + magnetic_field(NXprocess): + exists: optional + electric_field(NXprocess): + exists: optional + + # time-resolved results for individual snapshots + # virtually all computer simulations and all experiments always probe + # snapshots + MS_SNAPSHOT(NXms_snapshot): + time(NX_NUMBER): + unit: NX_TIME + doc: | + Measured or simulated physical time stamp for this snapshot. + Not to be confused with wall-clock timing or profiling data. + iteration(NX_UINT): + unit: NX_UNITLESS + doc: | + Iteration or increment counter. + + # optional places to store the grid for instance if it changes + grid(NXcg_grid): + exists: optional + polyhedron_set(NXcg_polyhedron_set): + exists: optional + point_set(NXcg_point_set): + exists: optional + + # homogenization: + # constituent: + # constitutive: + # ROI(NXcg_roi_set): #multiple rois, for each geometry, connectivity/topology, cellType... + # see that the materialpoint that is tracked conceptually in tools like DAMASK is a ROI (which is currently scale-invariant), isnt a coarse-graining of atom configurations a homogenization + # several "results" homogenized quantities at (eventually different length scales + # continuum-scale view thermodynamic(NXview) + # mechanical + # damage + # thermal + # composition + MS_FEATURE_SET(NXms_feature_set): + exists: ['min', '0', 'max', 'unbounded'] + doc: | + Conceptually distinguished object/feature in the ROI/ + system with some relevance. Instances of NXms_feature_set can + be nested to build a hierarchy of logically-related objects. + + A typical example for MD simulations is to have one + ms_feature_set for the atoms which is the parent to another + ms_feature_set for monomers/molecules/proteins which is then the + parent to another ms_feature_set for the secondary, another feature_set + for the tertiary, and the parent for another feature_set for the + quaternary structure. + + Another typical example from materials engineering is to have + one ms_feature_set for crystals (grains/phases) which serves as + the parent to another ms_feature_set for interfaces between these + crystals which then is the parent for another ms_feature_set to + describe the triple junctions which is then the parent for the + quadruple/higher-order junctions between which connect the + triple lines. + + Another example from discrete dislocation dynamics could be to + have one ms_feature_set for the dislocations (maybe separate + sets for each dislocation type or family) which are then + parents to other ms_feature_set which describe junctions between + dislocations or features along the dislocation line network. + + # respective application definitions based on NXms should add and + # specialize + odf(NXprocess): + exists: optional + doc: | + Details about the orientation distribution function + within the entire domain. + computation_method: + doc: | + With which method was the ODF approximated? + + # add approximation parameter + texture_index(NX_NUMBER): + exists: optional + unit: NX_ANY + doc: | + TO BE DEFINED + texture_strength(NX_NUMBER): + exists: optional + unit: NX_ANY + doc: | + TO BE DEFINED + volume_statistics(NXorientation_set): + exists: optional + doc: | + Collection of texture components commonly referred to. + TRANSFORMATIONS(NXtransformations): + doc: | + Reference to or definition of a coordinate system with + which the definitions are interpretable. + parameterization: + enumeration: [bunge-euler (ZXZ), quaternion] + orientation(NX_NUMBER): + unit: NX_ANY + doc: | + Parameterized orientations. + dimensions: + rank: 2 + dim: [[1, c], [2, n_p]] + name: + doc: | + Name of each texture component, e.g. Cube, Dillamore, Y. + dimensions: + rank: 1 + dim: [[1, c]] + integration_radius(NX_NUMBER): + unit: NX_ANGLE + doc: | + The portion of orientation space integrated over + to compute the volume fraction. + dimensions: + rank: 1 + dim: [[1, c]] + volume_fraction(NX_NUMBER): + unit: NX_DIMENSIONLESS + doc: | + The volume fraction of each texture component. + dimensions: + rank: 1 + dim: [[1, c]] + + # a grain-boundary character distribution + # is again a spatial correlation statistics, GBCD can be understood like an ODF in that the entire surface Of a grain boundary (interface) network is partitioned into regions between grains in specific disorientation relationships, and boundary plane inclination so that one can again ask for the "texture" i.e. which fraction of the area network is of specific disorientation and nominal plane inclination relationship + modf(NXprocess): + exists: optional + doc: | + Details about the disorientation distribution function + within the entire domain. + gbcd(NXprocess): + exists: optional + doc: | + Details about the grain boundary character distribution + within the entire domain. + + # add descriptions for the state of each cell + # e.g. values of phase field variables if desired + temperature(NXprocess): + exists: optional + pressure(NXprocess): + exists: optional + stress(NXprocess): + exists: optional + strain(NXprocess): + exists: optional + deformation_gradient(NXprocess): + exists: optional + magnetic_field(NXprocess): + exists: optional + electric_field(NXprocess): + exists: optional + recrystallization_kinetics(NXprocess): + exists: optional + grain_size_distribution(NXprocess): + exists: optional + recrystallization_front(NXprocess): + exists: optional + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 0210bb99907cdf3b9d534b45bd656fa8f6874bb33fbdda923582a60ede380b06 +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of boundaries of the bounding box or primitive to domain. +# +# +# +# +# Number of parameter required for the chosen orientation parameterization. +# +# +# +# +# Number of texture components identified. +# +# +# +# +# Application definition, spatiotemporal characterization of a microstructure. +# +# +# +# +# An at least as strong as SHA256 hashvalue of the file +# that specifies the application definition. +# +# +# +# +# +# NeXus NXDL schema to which this file conforms. +# +# +# +# +# +# +# +# Ideally, a (globally) unique persistent identifier +# for referring to this experiment or computer simulation. +# +# The identifier is usually defined/issued by the facility, laboratory, +# or the principle investigator. The identifier enables to link +# experiments to e.g. proposals. +# +# +# +# +# Free-text description about the workflow (experiment/analysis/simulation). +# +# Users are strongly advised to detail the sample history in the +# respective field and fill rather as completely as possible the fields +# of this application definition rather than write details about the +# experiment into this free-text description field. +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC information +# included when the characterization started. +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC included +# when the characterization ended. +# +# +# +# +# +# +# +# +# +# Specify if the (characterization) results/data of this instance of an +# application definition are based on the results of a simulation or the +# results of a post-processing of measured data to describe +# a microstructure. +# +# The term microstructure is used to describe the spatial arrangement of +# crystal defects inside a sample/specimen without demanding necessarily +# that this structure is mainly at the micron length scale. +# Nanostructure and macrostructure are close synonyms. +# Material architecture is a narrow synonym. +# +# Given that microstructure simulations nowadays more and more consider +# the atomic arrangement, this application definition can also be used +# to describe features at the scale of atoms. +# +# +# +# +# +# +# +# +# Contact information and eventually details of at least one person +# involved in creating this result. This can be the principle investigator +# who performed this experiment. Adding multiple users if relevant is recommended. +# +# +# +# Given (first) name and surname of the user. +# +# +# +# +# Name of the affiliation of the user at the point in time +# when the experiment was performed. +# +# +# +# +# Postal address of the affiliation. +# +# +# +# +# Email address of the user at the point in time when the experiment +# was performed. Writing the most permanently used email is recommended. +# +# +# +# +# Globally unique identifier of the user as offered by services +# like ORCID or ResearcherID. If this field is field the specific service +# should also be written in orcid_platform +# +# +# +# +# Name of the OrcID or ResearcherID where the account +# under orcid is registered. +# +# +# +# +# (Business) (tele)phone number of the user at the point +# in time when the experiment was performed. +# +# +# +# +# Which role does the user have in the place and at the point +# in time when the experiment was performed? Technician operating +# the microscope. Student, postdoc, principle investigator, guest +# are common examples. +# +# +# +# +# Account name that is associated with the user in social media platforms. +# +# +# +# +# Name of the social media platform where the account +# under social_media_name is registered. +# +# +# +# +# +# +# +# Descriptive name or ideally (globally) unique persistent identifier. +# +# +# +# +# +# +# Hard link to a location in the hierarchy of the NeXus file +# where the data for default plotting are stored. +# +# +# +# +# Container to hold different coordinate systems conventions. +# A least a right-handed Cartesian coordinate system with base vectors +# named x, y, and z has to be specified. Each base vector of the +# coordinate system should be described with an NXtransformations instance. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The simulated or characterized material volume element aka domain. +# At least one instance of geometry required either NXcg_grid, +# NXcg_polyhedron_set, or NXcg_point_set. This geometry group needs +# to contain details about the boundary conditions. +# +# +# +# +# +# +# +# A boundary to the volume element. +# Either an instance of NXcg_hexahedron_set or of NXcg_ellipsoid_set. +# +# +# +# +# How many distinct boundaries are distinguished. Value required equal to n_b. +# +# +# +# +# Name of the boundaries. E.g. left, right, front, back, bottom, top, +# +# +# +# +# +# +# +# The boundary conditions for each boundary: +# +# 0 - undefined +# 1 - open +# 2 - periodic +# 3 - mirror +# 4 - von Neumann +# 5 - Dirichlet +# +# +# +# +# +# +# +# +# Collection of microstructural data observed/simulated. +# +# +# +# Integer which specifies the first index to be used for distinguishing +# snapshots. Identifiers are defined either implicitly or explicitly. +# For implicit indexing the identifiers are defined on the +# interval [identifier_offset, identifier_offset+c-1]. +# For explicit indexing the identifier array has to be defined. +# +# The identifier_offset field can for example be used to communicate +# if the identifiers are expected to start from 1 (referred to as +# Fortran-/Matlab-) or from 0 (referred to as C-, Python-style index +# notation) respectively. +# +# +# +# +# +# Summary quantities which are the result of some post-processing of +# the snapshot data (averaging, integrating, interpolating). +# Frequently used descriptors from continuum mechanics and thermodynamics +# can be used here. A few examples are given. Each descriptor is currently +# modelled as an instance of an NXprocess because it is relevant to +# understand how the descriptors are computed. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Measured or simulated physical time stamp for this snapshot. +# Not to be confused with wall-clock timing or profiling data. +# +# +# +# +# Iteration or increment counter. +# +# +# +# +# +# +# +# +# +# Conceptually distinguished object/feature in the ROI/ +# system with some relevance. Instances of NXms_feature_set can +# be nested to build a hierarchy of logically-related objects. +# +# A typical example for MD simulations is to have one +# ms_feature_set for the atoms which is the parent to another +# ms_feature_set for monomers/molecules/proteins which is then the +# parent to another ms_feature_set for the secondary, another feature_set +# for the tertiary, and the parent for another feature_set for the +# quaternary structure. +# +# Another typical example from materials engineering is to have +# one ms_feature_set for crystals (grains/phases) which serves as +# the parent to another ms_feature_set for interfaces between these +# crystals which then is the parent for another ms_feature_set to +# describe the triple junctions which is then the parent for the +# quadruple/higher-order junctions between which connect the +# triple lines. +# +# Another example from discrete dislocation dynamics could be to +# have one ms_feature_set for the dislocations (maybe separate +# sets for each dislocation type or family) which are then +# parents to other ms_feature_set which describe junctions between +# dislocations or features along the dislocation line network. +# +# +# +# +# +# Details about the orientation distribution function +# within the entire domain. +# +# +# +# With which method was the ODF approximated? +# +# +# +# +# +# TO BE DEFINED +# +# +# +# +# TO BE DEFINED +# +# +# +# +# Collection of texture components commonly referred to. +# +# +# +# Reference to or definition of a coordinate system with +# which the definitions are interpretable. +# +# +# +# +# +# +# +# +# +# +# Parameterized orientations. +# +# +# +# +# +# +# +# +# Name of each texture component, e.g. Cube, Dillamore, Y. +# +# +# +# +# +# +# +# The portion of orientation space integrated over +# to compute the volume fraction. +# +# +# +# +# +# +# +# The volume fraction of each texture component. +# +# +# +# +# +# +# +# +# +# +# Details about the disorientation distribution function +# within the entire domain. +# +# +# +# +# Details about the grain boundary character distribution +# within the entire domain. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXms_feature_set.yaml b/contributed_definitions/nyaml/NXms_feature_set.yaml new file mode 100644 index 0000000000..b44ad17461 --- /dev/null +++ b/contributed_definitions/nyaml/NXms_feature_set.yaml @@ -0,0 +1,554 @@ +category: base +doc: | + Set of topological/spatial features in materials build from other features. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + Dimensionality + c: | + Cardinality/number of members/features in the feature set. + n_type_dict: | + Number of types in the dictionary of human-readable types of features. + n_parent_ids: | + Total number of parent identifier. + +# NXms_feature_set can be used e.g. as groups inside instances of NXms_snapshot +# for an MD simulation each timestep is such snapshot all snapshot for a set +# which is the parent group that has all these NXms_snapshot instances as childs +# time_stamp: # simulated, physical + +# Thea, Joseph, Lauri, Dinga (TJLD) just for comparison for each group and field to what this would map in their model for the MDTutorial 2 +type: group +NXms_feature_set(NXobject): + + # TJLD: this class represents a generalization of AtomGroups + # TJLD: one such for atoms(NXms_feature_set) + # TJLD: one such for atom_groups(NXms_feature_set) + # TJLD: but not one for every molecule, i.e. all molecules and how their atoms with ids are related to atoms ids is concatenated + # TJLD: clearly there are two possibilities: either concatenate or make one NXms_feature_set for each molecule or component in the topology hierarchy + # TJLD: however the here proposed design generalizes the arbitrary (microstructural) features and computational geometry based coarse-grained representations + \@depends_on: + + # TJLD: not required it is currently assumed that features are always build from atoms and this relation is shown using their ids, integers on [0, n_atoms-1] + doc: | + Name (or link?) to another NXms_feature_set which defines features what are + assumed as the parents/super_features of all members in this feature set. + If depends_on is set to "." or this attribute is not defined in an instance + of this application definition, assume that this feature_set instance + represents the root feature_set of the feature tree/graph. + + # the design of this base class makes it possible to have Joseph's suggestion + # but it has the additional benefit that as it defines the set one also + # bundle the description for all features at this hierarchy level into combined + # arrays to make the eventual storage of this for instances with millions of features + # more efficient as in the current design each molecule would again be a group + # and having millions of groups comes with e.g. HDF5 with substantial overlap + # I faced this when storing grains from micro-scale continuum crystal growth simulations + # TJLD: is_molecule(NX_BOOLEAN): not used, could however be added in an appdef which uses instances of NXms_feature_set + # TJLD: the key point we can use NXms_feature_set in the same way as currently TJLD use atoms and atoms/atom_groups/molecule0, */molecule1, ... + # but with the additional benefit of a much richer geometrical description and the details about the uncertainty of these descriptions + # I can also imagine that materials engineers e.g. can reuse NXms_feature_set in an application definition by just then naming + # their group e.g. grains(NXms_feature_set) and use in the application definition either only the (material point), interface network, or volumetric description + dimensionality(NX_UINT): + + # TJLD: not needed because they assume everything is 3d + doc: | + What is the best matching description how dimensional the feature is. + enumeration: [0, 1, 2, 3] + cardinality(NX_UINT): + unit: NX_UNITLESS + + # TJLD: equivalent to the number of AtomGroups class instance childs + doc: | + How many features/members are in this set? + type_dict_keyword: + + # TJLD: equivalent to the controlled vocabulary term monomer or molecule, i.e. label + # TJLD: but with the difference that in this NeXus design here different features can take different roles + # TJLD: and do not conceptually have to be atoms, alternatively one could also create an NXms_interface_set which + # TJLD: inherits from NXms_feature_set but would need to have no dimensionality + doc: | + The keywords of the dictionary of human-readable types of features. + Using terms from a community-agreed upon controlled vocabulary, e.g. + atom, solute, vacancy, monomer, molecule, anti-site, crowd_ion, + quadruple junction, triple line, disconnection, dislocation, + kink, jog, stacking_fault, homo_phase_boundary, hetero_phase_boundary, + surface, thermal_groove_root, precipitate, dispersoid, pore, crack + is recommended. + dimensions: + rank: 1 + dim: [[1, n_type_dict]] + type_dict_value(NX_UINT): + unit: NX_UNITLESS + + # TJLD: equivalent to the AtomGroups index + doc: | + The integer identifier used to resolve of which type each feature is, + i.e. the values of the dictionary of human-readable types of features. + dimensions: + rank: 1 + dim: [[1, n_type_dict]] + number_of_parent_identifier(NX_UINT): + unit: NX_UNITLESS + doc: | + For each feature in the set specify the associated number of identifier + to parent features as are resolvable via depends_on. + This array enables to compute the array interval from which details for + specific features can be extracted as if they would be stored in an own + group. + dimensions: + rank: 1 + dim: [[1, c]] + parent_identifier(NX_UINT): + unit: NX_UNITLESS + doc: | + Concatenated array of parent identifier for each feature (in the sequence) + according to identifier and how the identifier of features in the here + described feature set are defined (implicitly from 0, to c-1 or via explicit + identifier. + dimensions: + rank: 1 + dim: [[1, n_parent_ids]] + + # description of the geometry of the features + # MK::how can be define that inside lines(NXprocess) we assure that there is either no geometry or only one geometry but then this geometry can be either an NXcg_polyline_set or NXcg_spline_set? + # the key problem is that at least for an implementation in HDF5 we are not allowed to have two groups named geometry even if their attributes are different because + # HDF5 implements no conceptual understanding of the relations between elements in the underlying graph which holds the data, these elements are either attributes, fields, groups, all of which + # end up as links + identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for distinguishing + features. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + identifier(NX_INT): + unit: NX_UNITLESS + doc: | + Integer used to distinguish features for explicit indexing. + dimensions: + rank: 1 + dim: [[1, c]] + points(NXprocess): + + # TJLD: this design here is different, TJLD give atom positions only (at least as of now) for the root of an object + # TJLD: while all higher-order features that are connected through their assumed topology just refer to the atoms in the root + # TJLD: via their IDs, TJLD design is ideal for systems build from atoms but would create unnecessary copies for higher-dimensional-type features + # TJLD: in fact initially I also thought it is useful to create an NXms_dislocation_set, and an NXms_atom_set but overall these are just + # specializations of NXms_feature_set. Instead I like the key approach in TJLD which is to nest instances of the same class in TJLD's case AtomGroups + # but here NXms_feature_set instances + doc: | + Assumptions and parameter to arrive at geometric primitives + to locate zero-dimensional/point-(like) features which are + discretized/represented by points. + geometry(NXcg_point_set): + uncertainty(NXprocess): + doc: | + Assumptions, parameters, and details how positional uncertainty + of the geometry is quantified. + lines(NXprocess): + + # TJLD: not conceptualized, see comments for points and what the benefit of using NeXus would be + doc: | + Assumptions and parameters to arrive at geometric primitives + to locate one-dimensional/line-like features which are + discretized by polylines. + + # MK::geometry(NXcg_spline_set) + geometry(NXcg_polyline_set): + uncertainty(NXprocess): + doc: | + Assumptions, parameters, and details how positional uncertainty + of the geometry is quantified. + interfaces(NXprocess): + doc: | + Assumptions and parameters to arrive at geometric primitives + to locate two-dimensional/interface features which are + discretized by triangulated surface meshes. + + # MK::geometry(NXcg_nurbs_set): + geometry(NXcg_triangle_set): + uncertainty(NXprocess): + doc: | + Assumptions, parameters, and details how positional uncertainty + of the geometry is quantified. + volumes(NXprocess): + doc: | + Assumptions and parameters to arrive at geometric primitives + to locate three-dimensional/volumetric features which are + discretized by triangulated surface meshes of polyhedra. + + # MK::geometry(NXcg_nurbs_set): + geometry(NXcg_polyhedron_set): + uncertainty(NXprocess): + doc: | + Assumptions, parameters, and details how positional uncertainty + of the geometry is quantified. + + # Sandor and Markus agree that how trajectories are extracted should be stored in instances of NXprocess at respective places + # Sandor suggested it can be useful to also describe how one could transform system-specific atom positions from the system-focused coordinate system to a molecule- or atom-focused local coordinate system + + # how to map results from MD simulations was already sketched by the comments from TJLD + # but ones more here stating it explicitly + # atoms(NXms_feature_set): + # no \@depends_on: as everything is build spatiotemporally coarse-grained from the sampled atom positions and/or their trajectories + # dislocations(NXms_feature_set): + # \@depends_on: <>/atoms + # is trivially the same case as was described already for the DDD simulation + + # how to map from DREAM.3D to NXms_feature_set + # material_points(NXms_feature_set): # material points can be voxels of a grid (which should be specified with an instance of NXcg_grid) or real material points + # no \@depends_on: "." required or value can be "." as material_points are considered the root + # grains(NXms_feature_set): + # \@depends_on: <>/material_points + # boundaries(NXms_feature_set): + # \@depends_on: <>/grains + # triple_lines(NXms_feature_set): + # \@depends_on: <>/boundaries + # quadruple_junctions(NXms_feature_set): + # \@depends_on: <>/triple_lines + + # how to map from e.g. DDD codes like ParaDis to NXms_feature_set + # dislocations(NXms_feature_set): + # either all types of dislocations are specified via the type_dict dictionary or by making several named instances of NXms_feature_set classes, i.e. groups + # multi_junctions(NXms_feature_set): + # \@depends_on: <>/dislocations + + # how to describe e.g. 3D cracks + # cracks(NXms_feature_set): + # you can use volumes and interfaces to describe explicitly the 3D geometry + # alternatively you can + + # how to map from an MTex v5.8.2 @grain2d object + # grains.poly is a cell of list of vertex indices referring to grains.V + # grains.id + # grains.phaseId to which phase does each grain belong why is it different to phase? + # grains.prop (mean and gos) + # grains.boundary + # F, list of minmax-hashed vertex indices building the facet + # grainId, list of pairs of grains incident at facet special value 0 marks grains with boundary contact + # ebsdId, list of interpolated scan points incident + # phaseId, homo/heterophase information list of pairs of phases incident at facet + # V, list of facet support vertices, the support of the polyline + # midPoint, list of facet midPoint coordinates + # direction 3d vector (V(F(i, 1),:) - V(F(i, 2), :)) and with z = 0 and then normalized, so not respecting winding order + # grains.triplePoints + # id, list of vertex id for the location of the triple point referring to grains.V or grains.boundary.V as these lists are equivalent + # grainid, triplet of adjoining grain ids + # boundaryId, triplet of adjoining boundary facets from grains.boundary.F + # nextVertexId, next vertex hit when walking from the triple point + # phaseId, is it a triple point between homophases or heterophases + # V, list of x, y coordinates for the triple points + # angles, trivial nextVertexId to triplePoint vertex angles + # grains(NXms_feature_set): + # boundaries(NXms_feature_set): + # alternatively one NXms_feature_set for homophase boundaries + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 15f205ec24e25536f17046f9540798e889bf21046d3e1e2a63ab9434e3f6ffa9 +# +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Dimensionality +# +# +# +# +# Cardinality/number of members/features in the feature set. +# +# +# +# +# Number of types in the dictionary of human-readable types of features. +# +# +# +# +# Total number of parent identifier. +# +# +# +# +# Set of topological/spatial features in materials build from other features. +# +# +# +# +# +# Name (or link?) to another NXms_feature_set which defines features what are +# assumed as the parents/super_features of all members in this feature set. +# If depends_on is set to "." or this attribute is not defined in an instance +# of this application definition, assume that this feature_set instance +# represents the root feature_set of the feature tree/graph. +# +# +# +# +# +# +# What is the best matching description how dimensional the feature is. +# +# +# +# +# +# +# +# +# +# +# +# How many features/members are in this set? +# +# +# +# +# +# The keywords of the dictionary of human-readable types of features. +# Using terms from a community-agreed upon controlled vocabulary, e.g. +# atom, solute, vacancy, monomer, molecule, anti-site, crowd_ion, +# quadruple junction, triple line, disconnection, dislocation, +# kink, jog, stacking_fault, homo_phase_boundary, hetero_phase_boundary, +# surface, thermal_groove_root, precipitate, dispersoid, pore, crack +# is recommended. +# +# +# +# +# +# +# +# +# The integer identifier used to resolve of which type each feature is, +# i.e. the values of the dictionary of human-readable types of features. +# +# +# +# +# +# +# +# For each feature in the set specify the associated number of identifier +# to parent features as are resolvable via depends_on. +# This array enables to compute the array interval from which details for +# specific features can be extracted as if they would be stored in an own +# group. +# +# +# +# +# +# +# +# Concatenated array of parent identifier for each feature (in the sequence) +# according to identifier and how the identifier of features in the here +# described feature set are defined (implicitly from 0, to c-1 or via explicit +# identifier. +# +# +# +# +# +# +# +# +# Integer which specifies the first index to be used for distinguishing +# features. Identifiers are defined either implicitly +# or explicitly. For implicit indexing the identifiers are defined on the +# interval [identifier_offset, identifier_offset+c-1]. +# For explicit indexing the identifier array has to be defined. +# +# The identifier_offset field can for example be used to communicate if the +# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) +# or from 0 (referred to as C-, Python-style index notation) respectively. +# +# +# +# +# Integer used to distinguish features for explicit indexing. +# +# +# +# +# +# +# +# +# Assumptions and parameter to arrive at geometric primitives +# to locate zero-dimensional/point-(like) features which are +# discretized/represented by points. +# +# +# +# +# Assumptions, parameters, and details how positional uncertainty +# of the geometry is quantified. +# +# +# +# +# +# +# Assumptions and parameters to arrive at geometric primitives +# to locate one-dimensional/line-like features which are +# discretized by polylines. +# +# +# +# +# +# Assumptions, parameters, and details how positional uncertainty +# of the geometry is quantified. +# +# +# +# +# +# Assumptions and parameters to arrive at geometric primitives +# to locate two-dimensional/interface features which are +# discretized by triangulated surface meshes. +# +# +# +# +# +# Assumptions, parameters, and details how positional uncertainty +# of the geometry is quantified. +# +# +# +# +# +# Assumptions and parameters to arrive at geometric primitives +# to locate three-dimensional/volumetric features which are +# discretized by triangulated surface meshes of polyhedra. +# +# +# +# +# +# Assumptions, parameters, and details how positional uncertainty +# of the geometry is quantified. +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXms_score_config.yaml b/contributed_definitions/nyaml/NXms_score_config.yaml new file mode 100644 index 0000000000..3e5bbba0e8 --- /dev/null +++ b/contributed_definitions/nyaml/NXms_score_config.yaml @@ -0,0 +1,777 @@ +category: application +doc: | + Application definition to control a simulation with the SCORE model. +symbols: + n_dg_ori: | + Number of Bunge-Euler angle triplets for deformed grains. + n_rx_ori: | + Number of Bunge-Euler angle triplets for recrystallization nuclei. + n_su: | + Number of solitary unit domains to export. +type: group +NXms_score_config(NXobject): + (NXentry): + \@version: + doc: | + Version specifier of this application definition. + definition: + doc: | + Official NeXus NXDL schema with which this file was written. + enumeration: [NXms_score_config] + PROGRAM(NXprogram): + program_name: + \@version: + analysis_identifier: + doc: | + Ideally, a (globally persistent) unique identifier for referring + to this analysis. + analysis_description: + exists: optional + doc: | + Possibility for leaving a free-text description about this analysis. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + time_stamp(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + initial_microstructure(NXprocess): + doc: | + Relevant data to instantiate a starting configuration that is typically + a microstructure in deformed conditions where stored (elastic) energy + is stored in the form of crystal defects, which in the SCORE model are + is considered as mean-field dislocation content. + type: + doc: | + Which model should be used to generate a starting microstructure. + enumeration: [cuboidal, poisson_voronoi, ebsd, damask] + cell_size(NX_FLOAT): + unit: NX_LENGTH + doc: | + Edge length of the cubic cells of each CA domain. + domain_size(NX_UINT): + unit: NX_UNITLESS + doc: | + Extend of each CA domain in voxel along the x, y, and z direction. + Deformation of sheet material is assumed. + The x axis is assumed pointing along the rolling direction. + The y axis is assumed pointing along the transverse direction. + The z axis is assumed pointing along the normal direction. + dimensions: + rank: 1 + dim: [[1, 3]] + grain_size(NX_FLOAT): + unit: NX_LENGTH + doc: | + Extent of each deformed grain along the x, y, and z direction when type is + cuboidal. + dimensions: + rank: 1 + dim: [[1, 3]] + grain_diameter(NX_FLOAT): + unit: NX_LENGTH + doc: | + Average spherical diameter when type is poisson_voronoi. + grain_euler(NX_FLOAT): + unit: NX_ANGLE + doc: | + Set of Bunge-Euler angles to sample orientations randomly from. + dimensions: + rank: 2 + dim: [[1, n_dg_ori], [2, 3]] + ebsd(NXprocess): + exists: optional + doc: | + The EBSD dataset from which the initial microstructure is instantiated + if initial_microstructure/type has value ebsd. + filename: + doc: | + Path and name of the EBSD dataset from which to generate the starting + microstructure. + \@version: + doc: | + SHA256 checksum of the file which contains the EBSD dataset. + stepsize(NX_FLOAT): + unit: NX_LENGTH + doc: | + Size of the EBSD. The EBSD orientation mapping has to be on a + regular grid of square-shaped pixels. + dimensions: + rank: 1 + dim: [[1, 2]] + nucleation_model(NXprocess): + doc: | + Phenomenological model according to which it nuclei are placed + into the domain and assumed growing. + spatial_distribution_model: + doc: | + According to which model will the nuclei become distributed spatially. + CSR means complete spatial randomness. + Custom is implementation specific. + GB places nuclei at grain boundaries. + enumeration: [csr, custom, gb] + incubation_time_model: + doc: | + According to which model will the nuclei start to grow. + enumeration: [site_saturation] + orientation_model: + doc: | + According to which model will the nuclei get their orientation assigned. + enumeration: [sample_from_nucleus_euler] + nucleus_euler(NX_FLOAT): + unit: NX_ANGLE + doc: | + Set of Bunge-Euler angles to sample orientations of nuclei randomly from. + dimensions: + rank: 2 + dim: [[1, n_rx_ori], [2, 3]] + material_properties(NXprocess): + doc: | + (Mechanical) properties of the material which scale the amount + of stored (elastic) energy in the ROI/system. + reference_shear_modulus(NX_FLOAT): + unit: NX_PRESSURE + doc: | + Shear modulus at zero Kelvin. + reference_burgers_magnitude(NX_FLOAT): + unit: NX_LENGTH + doc: | + Magnitude at the Burgers vector at zero Kelvin. + + # firstOrderdG0dT + # alloyConstantThermalExpCoeff + # FirstOrderThermalExpCoeff + # SecondOrderThermalExpCoeff + melting_temperature(NX_FLOAT): + unit: NX_TEMPERATURE + doc: | + Melting temperature in degrees Celsius. + grain_boundary_mobility_model(NXprocess): + doc: | + Model for the assumed mobility of grain boundaries with different + disorientation. + model: + doc: | + Which type of fundamental model for the grain boundary mobility: + For the Sebald-Gottstein model the following equation is used. + For the Rollett-Holm model the following equation is used. + enumeration: [sebald_gottstein, rollett_holm] + sebald_gottstein_parameters(NXcollection): + lagb_pre_factor(NX_FLOAT): + unit: NX_ANY + lagb_enthalpy(NX_FLOAT): + unit: NX_ANY + hagb_pre_factor(NX_FLOAT): + unit: NX_ANY + hagb_enthalpy(NX_FLOAT): + unit: NX_ANY + special_pre_factor(NX_FLOAT): + unit: NX_ANY + special_enthalpy(NX_FLOAT): + unit: NX_ANY + rollett_holm_parameters(NXcollection): + hagb_pre_factor(NX_FLOAT): + unit: NX_ANY + hagb_enthalpy(NX_FLOAT): + unit: NX_ANY + lagb_to_hagb_cut(NX_FLOAT): + unit: NX_ANY + lagb_to_hagb_transition(NX_FLOAT): + unit: NX_ANY + lagb_to_hagb_exponent(NX_FLOAT): + unit: NX_ANY + stored_energy_recovery_model(NXprocess): + doc: | + Simulated evolution of the dislocation density as the stored + (elastic) energy assumed stored in each grain. + model: + doc: | + Which type of recovery model. + enumeration: [none] + dispersoid_drag_model(NXprocess): + doc: | + Simulated reduction of the grain boundary speed due to + the presence of dispersoids through which the total grain boundary + area of the recrystallization front can be reduced. + model: + doc: | + Which type of drag model. + enumeration: [none, zener_smith] + zener_smith_parameter(NXcollection): + pre_factor(NX_FLOAT): + surface_energy_density(NX_FLOAT): + time(NX_FLOAT): + unit: NX_TIME + doc: | + Support point of the linearized curve of simulated time matching + a specific support point of the average dispersoid radius. + dimensions: + rank: 1 + dim: [[1, i]] + radius(NX_FLOAT): + unit: NX_LENGTH + doc: | + Support point of the linearized curve of the average dispersoid radius. + dimensions: + rank: 1 + dim: [[1, i]] + time_temperature_history(NXprocess): + doc: | + Simulated time temperature profile + time(NX_FLOAT): + unit: NX_TIME + doc: | + Support point of the linearized curve of simulated time matching + a specific support point of the temperature. + dimensions: + rank: 1 + dim: [[1, j]] + temperature(NX_FLOAT): + unit: NX_LENGTH + doc: | + Support point of the linearized curve of the temperature. + dimensions: + rank: 1 + dim: [[1, j]] + stop_criteria(NXprocess): + doc: | + Criteria which enable to stop the simulation in a controlled manner. + Whichever criterion is fulfilled first stops the simulation. + max_x(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + Maximum recrystallized volume fraction. + max_time(NX_NUMBER): + unit: NX_TIME + doc: | + Maximum simulated physical time. + max_iteration(NX_UINT): + unit: NX_UNITLESS + doc: | + Maximum number of iteration steps. + numerics(NXprocess): + doc: | + Settings relevant for stable numerical integration. + max_delta_x(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + Maximum fraction equivalent to the migration of the + fastest grain boundary in the system how much a cell + may be consumed in a single iteration. + initial_cell_cache(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Fraction of the total number of cells in the CA which + should initially be allocated for offering cells in the + recrystallization front. + realloc_cell_cache(NX_FLOAT): + unit: NX_UNITLESS + doc: | + By how much more times should the already allocated memory + be is increased to offer space for storing states of cells + in the recrystallization front. + defragment_cell_cache(NX_BOOLEAN): + doc: | + Should the cache for cells in the recrystallization front + be defragmented on-the-fly. + defragment_x(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + Heuristic recrystallized volume target values at which + the cache for cells in the recrystallization front + will be defragmented on-the-fly. + dimensions: + rank: 1 + dim: [[1, i]] + snapshot_x(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + List of recrystallized volume target values at which a + snapshot of the CA state should be exported for. + dimensions: + rank: 1 + dim: [[1, j]] + solitary_unit_model(NXprocess): + apply(NX_BOOLEAN): + doc: | + Perform a statistical analyses of the results as it was + proposed by M. Kühbach (solitary unit model ensemble approach). + number_of_domains(NX_UINT): + unit: NX_UNITLESS + doc: | + How many independent cellular automaton domains + should be instantiated. + rediscretization(NX_UINT): + unit: NX_UNITLESS + doc: | + Into how many time steps should the real time interval be discretized upon + during post-processing the results with the solitary unit modeling approach. + domain_identifier(NX_UINT): + unit: NX_UNITLESS + doc: | + List of identifier for those domain which should be rendered. + Identifier start from 0. + dimensions: + rank: 1 + dim: [[1, n_su]] + performance(NXcs_profiling): + current_working_directory: + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 6142d3475f379790762453cd32f9330b04fd40950389a8c7322331e405008183 +# +# +# +# +# +# +# +# Number of Bunge-Euler angle triplets for deformed grains. +# +# +# +# +# Number of Bunge-Euler angle triplets for recrystallization nuclei. +# +# +# +# +# Number of solitary unit domains to export. +# +# +# +# +# Application definition to control a simulation with the SCORE model. +# +# +# +# +# Version specifier of this application definition. +# +# +# +# +# Official NeXus NXDL schema with which this file was written. +# +# +# +# +# +# +# +# +# +# +# +# +# Ideally, a (globally persistent) unique identifier for referring +# to this analysis. +# +# +# +# +# Possibility for leaving a free-text description about this analysis. +# +# +# +# +# Path to the directory where the tool should store NeXus/HDF5 results +# of this analysis. If not specified results will be stored in the +# current working directory. +# +# +# +# +# ISO 8601 formatted time code with local time zone offset to UTC +# information included when this configuration file was created. +# +# +# +# +# Relevant data to instantiate a starting configuration that is typically +# a microstructure in deformed conditions where stored (elastic) energy +# is stored in the form of crystal defects, which in the SCORE model are +# is considered as mean-field dislocation content. +# +# +# +# Which model should be used to generate a starting microstructure. +# +# +# +# +# +# +# +# +# +# +# Edge length of the cubic cells of each CA domain. +# +# +# +# +# Extend of each CA domain in voxel along the x, y, and z direction. +# Deformation of sheet material is assumed. +# The x axis is assumed pointing along the rolling direction. +# The y axis is assumed pointing along the transverse direction. +# The z axis is assumed pointing along the normal direction. +# +# +# +# +# +# +# +# Extent of each deformed grain along the x, y, and z direction when type is +# cuboidal. +# +# +# +# +# +# +# +# Average spherical diameter when type is poisson_voronoi. +# +# +# +# +# Set of Bunge-Euler angles to sample orientations randomly from. +# +# +# +# +# +# +# +# +# The EBSD dataset from which the initial microstructure is instantiated +# if initial_microstructure/type has value ebsd. +# +# +# +# Path and name of the EBSD dataset from which to generate the starting +# microstructure. +# +# +# +# SHA256 checksum of the file which contains the EBSD dataset. +# +# +# +# +# +# Size of the EBSD. The EBSD orientation mapping has to be on a +# regular grid of square-shaped pixels. +# +# +# +# +# +# +# +# +# +# Phenomenological model according to which it nuclei are placed +# into the domain and assumed growing. +# +# +# +# According to which model will the nuclei become distributed spatially. +# CSR means complete spatial randomness. +# Custom is implementation specific. +# GB places nuclei at grain boundaries. +# +# +# +# +# +# +# +# +# +# According to which model will the nuclei start to grow. +# +# +# +# +# +# +# +# According to which model will the nuclei get their orientation assigned. +# +# +# +# +# +# +# +# Set of Bunge-Euler angles to sample orientations of nuclei randomly from. +# +# +# +# +# +# +# +# +# +# (Mechanical) properties of the material which scale the amount +# of stored (elastic) energy in the ROI/system. +# +# +# +# Shear modulus at zero Kelvin. +# +# +# +# +# Magnitude at the Burgers vector at zero Kelvin. +# +# +# +# +# +# Melting temperature in degrees Celsius. +# +# +# +# +# +# Model for the assumed mobility of grain boundaries with different +# disorientation. +# +# +# +# Which type of fundamental model for the grain boundary mobility: +# For the Sebald-Gottstein model the following equation is used. +# For the Rollett-Holm model the following equation is used. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Simulated evolution of the dislocation density as the stored +# (elastic) energy assumed stored in each grain. +# +# +# +# Which type of recovery model. +# +# +# +# +# +# +# +# +# Simulated reduction of the grain boundary speed due to +# the presence of dispersoids through which the total grain boundary +# area of the recrystallization front can be reduced. +# +# +# +# Which type of drag model. +# +# +# +# +# +# +# +# +# +# +# +# Support point of the linearized curve of simulated time matching +# a specific support point of the average dispersoid radius. +# +# +# +# +# +# +# +# Support point of the linearized curve of the average dispersoid radius. +# +# +# +# +# +# +# +# +# +# Simulated time temperature profile +# +# +# +# Support point of the linearized curve of simulated time matching +# a specific support point of the temperature. +# +# +# +# +# +# +# +# Support point of the linearized curve of the temperature. +# +# +# +# +# +# +# +# +# Criteria which enable to stop the simulation in a controlled manner. +# Whichever criterion is fulfilled first stops the simulation. +# +# +# +# Maximum recrystallized volume fraction. +# +# +# +# +# Maximum simulated physical time. +# +# +# +# +# Maximum number of iteration steps. +# +# +# +# +# +# Settings relevant for stable numerical integration. +# +# +# +# Maximum fraction equivalent to the migration of the +# fastest grain boundary in the system how much a cell +# may be consumed in a single iteration. +# +# +# +# +# Fraction of the total number of cells in the CA which +# should initially be allocated for offering cells in the +# recrystallization front. +# +# +# +# +# By how much more times should the already allocated memory +# be is increased to offer space for storing states of cells +# in the recrystallization front. +# +# +# +# +# Should the cache for cells in the recrystallization front +# be defragmented on-the-fly. +# +# +# +# +# Heuristic recrystallized volume target values at which +# the cache for cells in the recrystallization front +# will be defragmented on-the-fly. +# +# +# +# +# +# +# +# List of recrystallized volume target values at which a +# snapshot of the CA state should be exported for. +# +# +# +# +# +# +# +# +# +# Perform a statistical analyses of the results as it was +# proposed by M. Kühbach (solitary unit model ensemble approach). +# +# +# +# +# How many independent cellular automaton domains +# should be instantiated. +# +# +# +# +# Into how many time steps should the real time interval be discretized upon +# during post-processing the results with the solitary unit modeling approach. +# +# +# +# +# List of identifier for those domain which should be rendered. +# Identifier start from 0. +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXms_score_results.yaml b/contributed_definitions/nyaml/NXms_score_results.yaml new file mode 100644 index 0000000000..0feed8437a --- /dev/null +++ b/contributed_definitions/nyaml/NXms_score_results.yaml @@ -0,0 +1,1335 @@ +category: application +doc: | + Application definition for storing results of the SCORE cellular automaton. + + The SCORE cellular automaton model for primary recrystallization is an + example of typical materials engineering applications used within the field + of so-called Integral Computational Materials Engineering (ICME) whereby + one can simulate the evolution of microstructures. + + Specifically the SCORE model can be used to simulate the growth of static + recrystallization nuclei. The model is described in the literature: + + * `M. Kühbach et al. `_ + * `C. Haase et al. `_ + * `M. Diehl et al. `_ +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_b: | + Number of boundaries of the bounding box or primitive to domain. + n_p: | + Number of parameter required for chosen orientation parameterization. + n_tex: | + Number of texture components identified. + d: | + Dimensionality. + c: | + Cardinality. + n_front: | + Number of active cells in the (recrystallization) front. + n_grains: | + Number of grains in the computer simulation. + +# inspect comments behind NXms +type: group +NXms_score_results(NXobject): + (NXentry): + \@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: [NXms_score_results] + analysis_identifier: + doc: | + Ideally, a (globally) unique persistent identifier + for referring to this computer simulation. + + The identifier is usually defined/issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments to e.g. proposals. + analysis_description: + exists: optional + doc: | + Free-text description about the workflow (analysis/simulation). + + Users are strongly advised to detail the sample history in the + respective field and fill rather as completely as possible the fields + of this application definition rather than write details about the + experiment into this free-text description field. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + included when the characterization started. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC included + when the characterization ended. + PROGRAM(NXprogram): + exists: ['min', '1', 'max', 'unbounded'] + program_name: + \@version: + experiment_or_simulation: + doc: | + Specify if the (characterization) results/data of this instance of an + application definition are based on the results of a simulation or the + results of a post-processing of measured data to describe a microstructure. + The term microstructure is used to describe the spatial arrangement of + crystal defects inside a sample/specimen without demanding necessarily + that this structure is mainly at the micron length scale. + Nanostructure and macrostructure are close synonyms. + Material architecture is a narrow synonym. + enumeration: [experiment, simulation] + + # always a simulation! + config_filename: + doc: | + The path and name of the config file for this analysis. + \@version: + doc: | + At least SHA256 strong hash of the specific config_file for + tracking provenance. + results_path: + exists: optional + doc: | + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + status: + doc: | + A statement whether the SCORE executable managed to + process the analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + enumeration: [success, failure] + USER(NXuser): + exists: ['min', '0', 'max', 'unbounded'] + doc: | + Contact information and eventually details of at least one person + involved in creating this result. This can be the principle investigator + who performed this experiment. Adding multiple users if relevant is recommended. + 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. + specimen(NXsample): + + # NEW ISSUE: inject the conclusion from the discussion with Andrea + # according to SAMPLE.yaml 0f8df14 2022/06/15 + name: + doc: | + Descriptive name or ideally (globally) unique persistent identifier. + + # sample_history: + # 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. + # preparation_date(NX_DATE_TIME): + # doc: | + # ISO 8601 time code with local time zone offset to UTC information + # when the specimen was prepared. + (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): + doc: | + Container to hold different coordinate systems conventions. + A least a right-handed Cartesian coordinate system with base vectors + named x, y, and z has to be specified. Each base vector of the + coordinate system should be described with an NXtransformations instance. + TRANSFORMATIONS(NXtransformations): + exists: ['min', '3', 'max', 'unbounded'] + conventions(NXem_ebsd_conventions): + rotation_conventions(NXprocess): + three_dimensional_rotation_handedness: + rotation_convention: + euler_angle_convention: + axis_angle_convention: + orientation_parameterization_sign_convention: + processing_reference_frame(NXprocess): + reference_frame_type: + xaxis_direction: + xaxis_alias: + yaxis_direction: + yaxis_alias: + zaxis_direction: + zaxis_alias: + origin: + sample_reference_frame(NXprocess): + reference_frame_type: + xaxis_direction: + yaxis_direction: + zaxis_direction: + origin: + ROI_SET(NXcg_roi_set): + exists: ['min', '1', 'max', 'unbounded'] + + # however for solitary unit models aka volume element ensemble, replica methods we may need more than one domain + # the volume element is not called representative because for what we consider the volume element to be representative + # for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors + doc: | + The simulated or characterized material volume element aka domain. + At least one instance of geometry required either NXcg_grid, + NXcg_polyhedron_set, or NXcg_point_set. This geometry group needs + to contain details about the boundary conditions. + grid(NXcg_grid): + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + origin(NX_NUMBER): + symmetry: + cell_dimensions(NX_NUMBER): + extent(NX_POSINT): + identifier_offset(NX_INT): + boundary(NXcg_polyhedron_set): + doc: | + A tight bounding box or sphere or bounding primitive about the grid. + + # a good example for a general bounding box description for such a grids of triclinic cells + # https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallelepiped + number_of_boundaries(NX_POSINT): + unit: NX_UNITLESS + doc: | + How many distinct boundaries are distinguished? + Most grids discretize a cubic or cuboidal region. In this case + six sides can be distinguished, each making an own boundary. + boundaries: + exists: ['min', '0'] + doc: | + Name of the boundaries. E.g. left, right, front, back, bottom, top, + The field must have as many entries as there are number_of_boundaries. + boundary_conditions(NX_INT): + unit: NX_UNITLESS + doc: | + The boundary conditions for each boundary: + + 0 - undefined + 1 - open + 2 - periodic + 3 - mirror + 4 - von Neumann + 5 - Dirichlet + dimensions: + rank: 1 + dim: [[1, n_b]] + snapshot_set(NXms_snapshot_set): + doc: | + Collection of microstructural data observed/simulated. + identifier_offset(NX_UINT): + unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for distinguishing + snapshots. Identifiers are defined either implicitly or explicitly. + For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate + if the identifiers are expected to start from 1 (referred to as + Fortran-/Matlab-) or from 0 (referred to as C-, Python-style index + notation) respectively. + + # essentially NXmonitor instances for evolution of ensemble summary statistics + evolution(NXprocess): + exists: optional + doc: | + Summary quantities which are the result of some post-processing of + the snapshot data (averaging, integrating, interpolating). + Frequently used descriptors from continuum mechanics and thermodynamics + can be used here. A few examples are given. Each descriptor is currently + modelled as an instance of an NXprocess because it is relevant to + understand how the descriptors are computed. + time(NXprocess): + exists: optional + doc: | + Evolution of the physical time. + temperature(NXprocess): + exists: optional + doc: | + Evolution of the simulated temperature over time. + + # pressure(NXprocess): + # exists: optional + # stress(NXprocess): + # exists: optional + # strain(NXprocess): + # exists: optional + # deformation_gradient(NXprocess): + # exists: optional + # magnetic_field(NXprocess): + # exists: optional + # electric_field(NXprocess): + # exists: optional + kinetics(NXprocess): + exists: optional + doc: | + Evolution of the recrystallized volume fraction over time. + + # recrystallization_front(NXprocess): + # exists: optional + # time-resolved results for individual snapshots + # virtually all computer simulations and all experiments always probe + # snapshots + MS_SNAPSHOT(NXms_snapshot): + time(NX_NUMBER): + unit: NX_TIME + doc: | + Measured or simulated physical time stamp for this snapshot. + Not to be confused with wall-clock timing or profiling data. + temperature(NX_NUMBER): + unit: NX_TEMPERATURE + doc: | + Simulated temperature. + iteration(NX_UINT): + unit: NX_UNITLESS + doc: | + Iteration or increment counter. + + # optional places to store the grid for instance if it changes + grid(NXcg_grid): + exists: recommended + grain_identifier(NX_UINT): + exists: recommended + unit: NX_UNITLESS + doc: | + Grain identifier for each cell. + dimensions: + rank: 3 + dim: [[1, n_x], [2, n_y], [3, n_z]] + thread_identifier(NX_UINT): + exists: optional + unit: NX_UNITLESS + doc: | + Identifier of the OpenMP thread which processed this part of the grid. + dimensions: + rank: 3 + dim: [[1, n_x], [2, n_y], [3, n_z]] + + # check comments behind NXms + recrystallization_front(NXprocess): + exists: recommended + doc: | + Details about those cells which in this time step represent + the discretized recrystallization front. + halo_region(NX_UINT): + exists: optional + unit: NX_UNITLESS + doc: | + Which cells are currently in a halo region of threads. + dimensions: + rank: 1 + dim: [[1, n_front]] + mobility_weight(NX_NUMBER): + exists: recommended + unit: NX_UNITLESS + doc: | + So-called mobility weight which is a scaling factor to + control the mobility of the grain boundary which is assumed + to sweep currently this volume. + dimensions: + rank: 1 + dim: [[1, n_front]] + coordinate(NX_NUMBER): + exists: recommended + unit: NX_LENGTH + doc: | + Grid coordinates of each cell in the recrystallization front. + dimensions: + rank: 2 + dim: [[1, n_front], [2, 3]] + deformed_grain_identifier(NX_UINT): + exists: recommended + unit: NX_UNITLESS + doc: | + Grain identifier assigned to each cell in the recrystallization front. + dimensions: + rank: 1 + dim: [[1, n_front]] + recrystallized_grain_identifier(NX_UINT): + exists: recommended + unit: NX_UNITLESS + doc: | + Grain identifier assigned to each nucleus which affected that cell in the + recrystallization front. + dimensions: + rank: 1 + dim: [[1, n_front]] + recrystallized_volume_fraction(NX_NUMBER): + exists: recommended + unit: NX_DIMENSIONLESS + doc: | + Relative volume transformed as a measure of infection progress. + dimensions: + rank: 1 + dim: [[1, n_front]] + thread_identifier(NX_UINT): + exists: optional + unit: NX_UNITLESS + doc: | + Identifier of the OpenMP thread processing each cell in the recrystallization + front. + dimensions: + rank: 1 + dim: [[1, n_front]] + infection_direction(NX_UINT): + exists: optional + unit: NX_UNITLESS + doc: | + Hint about the direction from which the cell was infected. + dimensions: + rank: 1 + dim: [[1, n_front]] + grain_ensemble(NXprocess): + exists: recommended + doc: | + Current grain-related quantities. + euler(NX_NUMBER): + exists: optional + unit: NX_ANGLE + doc: | + Bunge-Euler angle triplets for each grain. + dimensions: + rank: 2 + dim: [[1, n_grains], [2, 3]] + volume(NX_NUMBER): + unit: NX_VOLUME + doc: | + Discrete volume of each grain accounting also for partially + transformed cells. + dimensions: + rank: 1 + dim: [[1, n_grains]] + dislocation_density(NX_NUMBER): + exists: recommended + unit: NX_ANY + doc: | + Current value for the dislocation density as a measure of + the remaining stored energy in assumed crystal defects inside + each grain. The difference between these values scales the + driving force of grain boundary migration. + dimensions: + rank: 1 + dim: [[1, n_grains]] + is_deformed(NX_BOOLEAN): + exists: recommended + doc: | + Is the grain deformed. + dimensions: + rank: 1 + dim: [[1, n_grains]] + is_recrystallized(NX_BOOLEAN): + exists: recommended + doc: | + Is the grain recrystallized. + dimensions: + rank: 1 + dim: [[1, n_grains]] + recrystallized_kinetics(NXprocess): + doc: | + Current recrystallized volume fraction. + value(NX_NUMBER): + unit: NX_DIMENSIONLESS + doc: | + Currently evaluated actual recrystallized volume fraction. + This takes into account partially recrystallized cells. + target(NX_NUMBER): + unit: NX_DIMENSIONLESS + doc: | + Currently desired target recrystallized volume fraction at + which the user requested to log a snapshot. + + # pressure(NXprocess): + # exists: optional + stress(NXprocess): + exists: optional + value(NX_NUMBER): + unit: NX_ANY + doc: | + Currently assumed globally applied Cauchy stress tensor on the ROI. + dimensions: + rank: 2 + dim: [[1, 3], [2, 3]] + strain(NXprocess): + exists: optional + value(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Currently assumed globally applied Cauchy strain tensor on the ROI. + dimensions: + rank: 2 + dim: [[1, 3], [2, 3]] + + # deformation_gradient(NXprocess): + # exists: optional + # magnetic_field(NXprocess): + # exists: optional + # electric_field(NXprocess): + # exists: optional + performance(NXcs_profiling): + current_working_directory: + command_line_call: + exists: optional + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + total_elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): + (NXcs_computer): + exists: recommended + name: + exists: recommended + operating_system: + \@version: + uuid: + exists: optional + (NXcs_cpu): + exists: ['min', '0', 'max', 'unbounded'] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_gpu): + exists: ['min', '0', 'max', 'unbounded'] + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_mm_sys): + exists: ['min', '0', 'max', '1'] + total_physical_memory(NX_NUMBER): + (NXcs_io_sys): + exists: ['min', '0', 'max', '1'] + (NXcs_io_obj): + exists: ['min', '1', 'max', 'unbounded'] + technology: + max_physical_capacity(NX_NUMBER): + name: + exists: optional + (NXfabrication): + exists: recommended + identifier: + exists: optional + capabilities: + exists: optional + (NXcs_profiling_event): + start_time(NX_DATE_TIME): + exists: optional + end_time(NX_DATE_TIME): + exists: optional + description: + elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + number_of_threads(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + number_of_gpus(NX_POSINT): + + # exists: recommended + doc: | + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + max_virtual_memory_snapshot(NX_NUMBER): + exists: recommended + max_resident_memory_snapshot(NX_NUMBER): + exists: recommended + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# d3f6e7e4ebdd514db8e3fc3047a050c89e77760f7d6642a66e77d4958f71737d +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of boundaries of the bounding box or primitive to domain. +# +# +# +# +# Number of parameter required for chosen orientation parameterization. +# +# +# +# +# Number of texture components identified. +# +# +# +# +# Dimensionality. +# +# +# +# +# Cardinality. +# +# +# +# +# Number of active cells in the (recrystallization) front. +# +# +# +# +# Number of grains in the computer simulation. +# +# +# +# +# Application definition for storing results of the SCORE cellular automaton. +# +# The SCORE cellular automaton model for primary recrystallization is an +# example of typical materials engineering applications used within the field +# of so-called Integral Computational Materials Engineering (ICME) whereby +# one can simulate the evolution of microstructures. +# +# Specifically the SCORE model can be used to simulate the growth of static +# recrystallization nuclei. The model is described in the literature: +# +# * `M. Kühbach et al. <https://doi.org/10.1016/j.actamat.2016.01.068>`_ +# * `C. Haase et al. <https://doi.org/10.1016/j.actamat.2015.08.057>`_ +# * `M. Diehl et al. <https://doi.org/10.1088/1361-651X/ab51bd>`_ +# +# +# +# +# An at least as strong as SHA256 hashvalue of the file +# that specifies the application definition. +# +# +# +# +# +# NeXus NXDL schema to which this file conforms. +# +# +# +# +# +# +# +# Ideally, a (globally) unique persistent identifier +# for referring to this computer simulation. +# +# The identifier is usually defined/issued by the facility, laboratory, +# or the principle investigator. The identifier enables to link +# experiments to e.g. proposals. +# +# +# +# +# Free-text description about the workflow (analysis/simulation). +# +# Users are strongly advised to detail the sample history in the +# respective field and fill rather as completely as possible the fields +# of this application definition rather than write details about the +# experiment into this free-text description field. +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC information +# included when the characterization started. +# +# +# +# +# ISO 8601 time code with local time zone offset to UTC included +# when the characterization ended. +# +# +# +# +# +# +# +# +# +# Specify if the (characterization) results/data of this instance of an +# application definition are based on the results of a simulation or the +# results of a post-processing of measured data to describe a microstructure. +# The term microstructure is used to describe the spatial arrangement of +# crystal defects inside a sample/specimen without demanding necessarily +# that this structure is mainly at the micron length scale. +# Nanostructure and macrostructure are close synonyms. +# Material architecture is a narrow synonym. +# +# +# +# +# +# +# +# +# +# The path and name of the config file for this analysis. +# +# +# +# At least SHA256 strong hash of the specific config_file for +# tracking provenance. +# +# +# +# +# +# Path to the directory where the tool should store NeXus/HDF5 results +# of this analysis. If not specified results will be stored in the +# current working directory. +# +# +# +# +# A statement whether the SCORE executable managed to +# process the analysis or failed prematurely. +# +# This status is written to the results file after the end_time +# at which point the executable must not compute any analysis. +# Only when this status message is present and shows `success`, the +# user should consider the results. In all other cases it might be +# that the executable has terminated prematurely or another error +# occurred. +# +# +# +# +# +# +# +# +# Contact information and eventually details of at least one person +# involved in creating this result. This can be the principle investigator +# who performed this experiment. Adding multiple users if relevant is recommended. +# +# +# +# Given (first) name and surname of the user. +# +# +# +# +# Name of the affiliation of the user at the point in time +# when the experiment was performed. +# +# +# +# +# Postal address of the affiliation. +# +# +# +# +# Email address of the user at the point in time when the experiment +# was performed. Writing the most permanently used email is recommended. +# +# +# +# +# Globally unique identifier of the user as offered by services +# like ORCID or ResearcherID. If this field is field the specific service +# should also be written in orcid_platform +# +# +# +# +# Name of the OrcID or ResearcherID where the account +# under orcid is registered. +# +# +# +# +# (Business) (tele)phone number of the user at the point +# in time when the experiment was performed. +# +# +# +# +# Which role does the user have in the place and at the point +# in time when the experiment was performed? Technician operating +# the microscope. Student, postdoc, principle investigator, guest +# are common examples. +# +# +# +# +# Account name that is associated with the user in social media platforms. +# +# +# +# +# Name of the social media platform where the account +# under social_media_name is registered. +# +# +# +# +# +# +# +# Descriptive name or ideally (globally) unique persistent identifier. +# +# +# +# +# +# +# Hard link to a location in the hierarchy of the NeXus file +# where the data for default plotting are stored. +# +# +# +# +# Container to hold different coordinate systems conventions. +# A least a right-handed Cartesian coordinate system with base vectors +# named x, y, and z has to be specified. Each base vector of the +# coordinate system should be described with an NXtransformations instance. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The simulated or characterized material volume element aka domain. +# At least one instance of geometry required either NXcg_grid, +# NXcg_polyhedron_set, or NXcg_point_set. This geometry group needs +# to contain details about the boundary conditions. +# +# +# +# +# +# +# +# +# +# +# +# +# A tight bounding box or sphere or bounding primitive about the grid. +# +# +# +# +# How many distinct boundaries are distinguished? +# Most grids discretize a cubic or cuboidal region. In this case +# six sides can be distinguished, each making an own boundary. +# +# +# +# +# Name of the boundaries. E.g. left, right, front, back, bottom, top, +# The field must have as many entries as there are number_of_boundaries. +# +# +# +# +# The boundary conditions for each boundary: +# +# 0 - undefined +# 1 - open +# 2 - periodic +# 3 - mirror +# 4 - von Neumann +# 5 - Dirichlet +# +# +# +# +# +# +# +# +# Collection of microstructural data observed/simulated. +# +# +# +# Integer which specifies the first index to be used for distinguishing +# snapshots. Identifiers are defined either implicitly or explicitly. +# For implicit indexing the identifiers are defined on the +# interval [identifier_offset, identifier_offset+c-1]. +# For explicit indexing the identifier array has to be defined. +# +# The identifier_offset field can for example be used to communicate +# if the identifiers are expected to start from 1 (referred to as +# Fortran-/Matlab-) or from 0 (referred to as C-, Python-style index +# notation) respectively. +# +# +# +# +# +# Summary quantities which are the result of some post-processing of +# the snapshot data (averaging, integrating, interpolating). +# Frequently used descriptors from continuum mechanics and thermodynamics +# can be used here. A few examples are given. Each descriptor is currently +# modelled as an instance of an NXprocess because it is relevant to +# understand how the descriptors are computed. +# +# +# +# Evolution of the physical time. +# +# +# +# +# Evolution of the simulated temperature over time. +# +# +# +# +# +# Evolution of the recrystallized volume fraction over time. +# +# +# +# +# +# +# +# Measured or simulated physical time stamp for this snapshot. +# Not to be confused with wall-clock timing or profiling data. +# +# +# +# +# Simulated temperature. +# +# +# +# +# Iteration or increment counter. +# +# +# +# +# +# +# Grain identifier for each cell. +# +# +# +# +# +# +# +# +# +# Identifier of the OpenMP thread which processed this part of the grid. +# +# +# +# +# +# +# +# +# +# +# +# Details about those cells which in this time step represent +# the discretized recrystallization front. +# +# +# +# Which cells are currently in a halo region of threads. +# +# +# +# +# +# +# +# So-called mobility weight which is a scaling factor to +# control the mobility of the grain boundary which is assumed +# to sweep currently this volume. +# +# +# +# +# +# +# +# Grid coordinates of each cell in the recrystallization front. +# +# +# +# +# +# +# +# +# Grain identifier assigned to each cell in the recrystallization front. +# +# +# +# +# +# +# +# Grain identifier assigned to each nucleus which affected that cell in the +# recrystallization front. +# +# +# +# +# +# +# +# Relative volume transformed as a measure of infection progress. +# +# +# +# +# +# +# +# Identifier of the OpenMP thread processing each cell in the recrystallization +# front. +# +# +# +# +# +# +# +# Hint about the direction from which the cell was infected. +# +# +# +# +# +# +# +# +# Current grain-related quantities. +# +# +# +# Bunge-Euler angle triplets for each grain. +# +# +# +# +# +# +# +# +# Discrete volume of each grain accounting also for partially +# transformed cells. +# +# +# +# +# +# +# +# Current value for the dislocation density as a measure of +# the remaining stored energy in assumed crystal defects inside +# each grain. The difference between these values scales the +# driving force of grain boundary migration. +# +# +# +# +# +# +# +# Is the grain deformed. +# +# +# +# +# +# +# +# Is the grain recrystallized. +# +# +# +# +# +# +# +# +# Current recrystallized volume fraction. +# +# +# +# Currently evaluated actual recrystallized volume fraction. +# This takes into account partially recrystallized cells. +# +# +# +# +# Currently desired target recrystallized volume fraction at +# which the user requested to log a snapshot. +# +# +# +# +# +# +# +# Currently assumed globally applied Cauchy stress tensor on the ROI. +# +# +# +# +# +# +# +# +# +# +# Currently assumed globally applied Cauchy strain tensor on the ROI. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Specify if it was different from the number_of_processes +# in the NXcs_profiling super class. +# +# +# +# +# +# Specify if it was different from the number_of_threads +# in the NXcs_profiling super class. +# +# +# +# +# +# Specify if it was different from the number_of_threads +# in the NXcs_profiling super class. +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXms_snapshot.yaml b/contributed_definitions/nyaml/NXms_snapshot.yaml new file mode 100644 index 0000000000..2c668ddd21 --- /dev/null +++ b/contributed_definitions/nyaml/NXms_snapshot.yaml @@ -0,0 +1,79 @@ +category: base +doc: | + Base class for data on the state of the microstructure at a given + time/iteration. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXms_snapshot(NXobject): + comment: + doc: | + Is this time for a measurement or a simulation. + enumeration: [measurement, simulation] + time(NX_NUMBER): + unit: NX_TIME + doc: | + Measured or simulated physical time stamp for this snapshot. + Not to be confused with wall-clock timing or profiling data. + iteration(NX_INT): + unit: NX_UNITLESS + doc: | + Iteration or increment counter. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 727c20950297820e1d9da8230bb0ccaaeb162693eb09c7c72f831029a038bf23 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Base class for data on the state of the microstructure at a given +# time/iteration. +# +# +# +# Is this time for a measurement or a simulation. +# +# +# +# +# +# +# +# +# Measured or simulated physical time stamp for this snapshot. +# Not to be confused with wall-clock timing or profiling data. +# +# +# +# +# Iteration or increment counter. +# +# +# diff --git a/contributed_definitions/nyaml/NXms_snapshot_set.yaml b/contributed_definitions/nyaml/NXms_snapshot_set.yaml new file mode 100644 index 0000000000..6ce3b20223 --- /dev/null +++ b/contributed_definitions/nyaml/NXms_snapshot_set.yaml @@ -0,0 +1,98 @@ +category: base +doc: | + A collection of spatiotemporal microstructure data. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXms_snapshot_set(NXobject): + comment: + doc: | + Is this set describing a measurement or a simulation? + enumeration: [measurement, simulation] + identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for distinguishing + snapshots. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + + # should we rather name snapshots explicitly always snapshot_1, snapshot_2 + # in which case identifier fields are not required, on the other hand + # if we give the names of the snapshots free via making them all capital + # how can we assure that snapshots are numbered consecutively? + # MS_SNAPSHOT + (NXms_snapshot): + + # exists: [min, 0, max, infty] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e9c6e090a782d50af20f1b70f91cd7299a386e1ad829ab70fea2cc1fbadff262 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# A collection of spatiotemporal microstructure data. +# +# +# +# Is this set describing a measurement or a simulation? +# +# +# +# +# +# +# +# +# Integer which specifies the first index to be used for distinguishing +# snapshots. Identifiers are defined either implicitly +# or explicitly. For implicit indexing the identifiers are defined on the +# interval [identifier_offset, identifier_offset+c-1]. +# For explicit indexing the identifier array has to be defined. +# +# The identifier_offset field can for example be used to communicate if the +# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) +# or from 0 (referred to as C-, Python-style index notation) respectively. +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXopt.yaml b/contributed_definitions/nyaml/NXopt.yaml new file mode 100644 index 0000000000..777076ff78 --- /dev/null +++ b/contributed_definitions/nyaml/NXopt.yaml @@ -0,0 +1,1502 @@ +category: application +doc: | + An application definition for optical spectroscopy experiments. +symbols: + doc: | + Variables used throughout the document, e.g. dimensions or parameters. + N_spectrum: | + Length of the spectrum array (e.g. wavelength or energy) of the measured + data. + N_sensors: | + Number of sensors used to measure parameters that influence the sample, + such as temperature or pressure. + N_measurements: | + Number of measurements (1st dimension of measured_data array). This is + equal to the number of parameters scanned. For example, if the experiment + was performed at three different temperatures and two different pressures + N_measurements = 2*3 = 6. + N_detection_angles: | + Number of detection angles of the beam reflected or scattered off the + sample. + N_incident_angles: | + Number of angles of incidence of the incident beam. + N_observables: | + Number of observables that are saved in a measurement. e.g. one for + intensity, reflectivity or transmittance, two for Psi and Delta etc. This + is equal to the second dimension of the data array 'measured_data' and the + number of column names. + +# 05/2023 +# Draft of a NeXus application definition which serves as a template for various +# optical spectroscopy experiments + +# To do: +# [ ] Check base classes (NXbeam_path + base classes used by it) +# [ ] Harmonize NXopt and NXellipsometry +# [ ] Fix dimensions and ranks +type: group +NXopt(NXobject): + (NXentry): + doc: | + An application definition template for optical spectroscopy experiments. + + A general optical experiment consists of a light or excitation source, a + beam path, a sample + its stage + its environment, and a detection unit. + Examples are reflection or transmission measurements, photoluminescence, + Raman spectroscopy, ellipsometry etc. + definition: + doc: | + An application definition describing a general optical experiment. + \@version: + doc: | + Version number to identify which definition of this application + definition was used for this entry/data. + \@url: + doc: | + URL where to find further material (documentation, examples) relevant + to the application definition. + enumeration: [NXopt] + experiment_identifier: + doc: | + A (globally persistent) unique identifier of the experiment. + (i) The identifier is usually defined by the facility or principle + investigator. + (ii) The identifier enables to link experiments to e.g. proposals. + experiment_description: + exists: optional + doc: | + An optional free-text description of the experiment. + + However, details of the experiment should be defined in the specific + fields of this application definition rather than in this experiment + description. + experiment_type: + doc: | + Specify the type of the optical experiment. + start_time(NX_DATE_TIME): + doc: | + Start time of the experiment. UTC offset should be specified. + (NXuser): + doc: | + Contact information of at least the user of the instrument or the + investigator who performed this experiment. + Adding multiple users, if relevant, is recommended. + name(NX_CHAR): + doc: | + Name of the user. + affiliation(NX_CHAR): + exists: recommended + doc: | + Name of the affiliation of the user at the point in time when the + experiment was performed. + address(NX_CHAR): + exists: recommended + doc: | + Street address of the user's affiliation. + email(NX_CHAR): + doc: | + Email address of the user. + orcid(NX_CHAR): + exists: recommended + doc: | + Author ID defined by https://orcid.org/. + telephone_number(NX_CHAR): + exists: recommended + doc: | + Telephone number of the user. + (NXinstrument): + doc: | + Properties of the experimental setup. This includes general information + about the instrument (such as model, company etc.), information about + the calibration of the instrument, elements of the beam path including + the excitation or light source and the detector unit, the sample stage + (plus the sample environment, which also includes sensors used to + monitor external conditions) and elements of the beam path. + + Meta data describing the sample should be specified in ENTRY/SAMPLE + outside of ENTRY/INSTRUMENT. + model: + doc: | + The name of the instrument. + \@version: + doc: | + The used version of the hardware if available. If not a commercial + instrument use date of completion of the hardware. + company: + exists: optional + doc: | + Name of the company which build the instrument. + construction_year(NX_DATE_TIME): + exists: optional + doc: | + ISO8601 date when the instrument was constructed. + UTC offset should be specified. + software(NXprocess): + program: + doc: | + Commercial or otherwise defined given name of the program that was + used to measure the data, i.e. the software used to start and + record the measured data and/or metadata. + If home written, one can provide the actual steps in the NOTE + subfield here. + version: + doc: | + Either version with build number, commit hash, or description of a + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + \@url: + exists: optional + doc: | + Website of the software. + firmware(NXprogram): + exists: recommended + doc: | + Commercial or otherwise defined name of the firmware that was used + for the measurement - if available. + \@version: + doc: | + Version and build number or commit hash of the software source code. + \@url: + exists: optional + doc: | + Website of the software. + calibration_status(NX_CHAR): + doc: | + Was a calibration performed? If yes, when was it done? If the + calibration time is provided, it should be specified in + ENTRY/INSTRUMENT/calibration/calibration_time. + enumeration: [calibration time provided, no calibration, within 1 hour, within 1 day, within 1 week] + calibration(NXsubentry): + exists: recommended + doc: | + The calibration data and metadata should be described in a separate NeXus file + with the link provided in 'calibration_link'. + calibration_time(NX_DATE_TIME): + exists: optional + doc: | + If calibtration status is 'calibration time provided', specify the + ISO8601 date when calibration was last performed before this + measurement. UTC offset should be specified. + calibration_data_link: + doc: | + Link to the NeXus file containing the calibration data and metadata. + (NXbeam_path): + doc: | + Describes an arrangement of optical or other elements, e.g. the beam + path between the light source and the sample, or between the sample + and the detector unit (including the sources and detectors + themselves). + + If a beam splitter (i.e. a device that splits the incoming beam into + two or more beams) is part of the beam path, two or more NXbeam_path + fields may be needed to fully describe the beam paths and the correct + sequence of the beam path elements. + Use as many beam paths as needed to describe the setup. + angle_of_incidence(NX_NUMBER): + unit: NX_ANGLE + doc: | + Angle(s) of the incident beam vs. the normal of the bottom reflective + (substrate) surface in the sample. + dimensions: + rank: 1 + dim: [[1, N_incident_angles]] + \@units: + detection_angle(NX_NUMBER): + exists: optional + unit: NX_ANGLE + doc: | + Detection angle(s) of the beam reflected or scattered off the sample + vs. the normal of the bottom reflective (substrate) surface in the + sample if not equal to the angle(s) of incidence. + dimensions: + rank: 1 + dim: [[1, N_detection_angles]] + sample_stage(NXsubentry): + doc: | + Sample stage, holding the sample at a specific position in X,Y,Z + (Cartesian) coordinate system and at an orientation defined + by three Euler angles (alpha, beta, gamma). + stage_type: + doc: | + Specify the type of the sample stage. + enumeration: [manual stage, scanning stage, liquid stage, gas cell, cryostat] + alternative: + exists: optional + doc: | + If there is no motorized stage, we should at least qualify where + the beam hits the sample and in what direction the sample stands + in a free-text description, e.g. 'center of sample, long edge + parallel to the plane of incidence'. + environment_conditions(NXenvironment): + doc: | + Specify external parameters that have influenced the sample, such + as the surrounding medium, and varied parameters e.g. temperature, + pressure, pH value, optical excitation etc. + medium: + doc: | + Describe what was the medium above or around the sample. The + common model is built up from the substrate to the medium on the + other side. Both boundaries are assumed infinite in the model. + Here, define the name of the medium (e.g. water, air, UHV, etc.). + medium_refractive_indices(NX_FLOAT): + exists: optional + unit: NX_UNITLESS + doc: | + Array of pairs of complex refractive indices n + ik of the medium + for every measured spectral point/wavelength/energy. + Only necessary if the measurement was performed not in air, or + something very well known, e.g. high purity water. + dimensions: + rank: 2 + dim: [[1, 2], [2, N_spectrum]] + PARAMETER(NXsensor): + exists: optional + doc: | + A sensor used to monitor an external condition influencing the + sample, such as temperature or pressure. It is suggested to + replace 'PARAMETER' by the type of the varied parameter defined + in 'parameter_type'. + The measured parameter values should be provided in 'values'. + For each parameter, a 'PARAMETER(NXsensor)' field needs to exist. + In other words, there are N_sensors 'PARAMETER(NXsensor)' fields. + parameter_type: + doc: | + Indicates which parameter was changed. Its definition must exist + below. The specified variable has to be N_measurements long, + providing the parameters for each data set. If you vary more than + one parameter simultaneously. + If the measured parameter is not contained in the list `other` + should be specified and the `parameter_type_name` should be provided. + enumeration: [conductivity, detection_angle, electric_field, flow, incident_angle, magnetic_field, optical_excitation, pH, pressure, resistance, shear, stage_positions, strain, stress, surface_pressure, temperature, voltage, other] + parameter_type_name: + exists: optional + doc: | + If the parameter_type is `other` a name should be specified here. + number_of_parameters(NX_POSINT): + unit: NX_UNITLESS + doc: | + Number of different parameter values at which the measurement + was performed. For example, if the measurement was performed at + temperatures of 4, 77 and 300 K, then number_of_parameters = 3. + values(NX_FLOAT): + unit: NX_ANY + doc: | + Vector containing the values of the varied parameter. Its + length is equal to N_measurements. The order of the values + should be as follows: + + * Order the sensors according to number_of_parameters starting + with the lowest number. If number_of_parameters is equal for + two sensors order them alphabetically (sensor/parameter name). + * The first sensor's j parameters should be ordered in the + following way. The first N_measurements/number_of_parameters + entries of the vector contain the first parameter (a1), the + second N_measurements/number_of_parameters contain the second + parameter (a2) etc., so the vector looks like: + [ + a1,a1,...,a1, + a2,a2,...,a2, + ... + aj,aj,...aj + ] + * The kth sensor's m parameters should be ordered in the + following way: + [ + p1,...p1,p2,...,p2,...pm,...,pm, + p1,...p1,p2,...,p2,...pm,...,pm, + ... + p1,...p1,p2,...,p2,...pm,...,pm + ] + * The last sensor's n parameters should be ordered in the + following way: + [ + z1,z2,...,zn, + z1,z2,...,zn, + ... + z1,z2,...,zn] + + For example, if the experiment was performed at three different + temperatures (T1, T2, T3), two different pressures (p1, p2) and + two different angles of incidence (a1, a2), then + N_measurements = 12 and the order of the values for the various + parameter vectors is: + + * angle_of_incidence: [a1,a1,a1,a1,a1,a1,a2,a2,a2,a2,a2,a2] + * pressure: [p1,p1,p1,p2,p2,p2,p1,p1,p1,p2,p2,p2] + * temperature: [T1,T2,T3,T1,T2,T3,T1,T2,T3,T1,T2,T3] + dimensions: + rank: 1 + dim: [[1, N_measurements]] + WINDOW(NXaperture): + exists: optional + doc: | + For environmental measurements, the environment (liquid, vapor + etc.) is enclosed in a cell, which has windows both in the + direction of the source (entry window) and the detector (exit + window) (looking from the sample). In case that the entry and exit + windows are not the same type and do not have the same properties, + use a second 'WINDOW(MXaperture)' field. + + The windows also add a phase shift to the light altering the + measured signal. This shift has to be corrected based on measuring + a known sample (reference sample) or the actual sample of interest + in the environmental cell. State if a window correction has been + performed in 'window_effects_corrected'. Reference data should be + considered as a separate experiment, and a link to the NeXus file + should be added in reference_data_link in measured_data. + + The window is considered to be a part of the sample stage but also + beam path. Hence, its position within the beam path should be + defined by the 'depends_on' field. + depends_on: + exists: recommended + doc: | + Specify the position of the window in the beam path by pointing + to the preceding element in the sequence of beam path elements. + window_effects_corrected(NX_BOOLEAN): + doc: | + Was a window correction performed? If 'True' describe the window + correction procedure in 'window_correction/procedure'. + window_correction(NXprocess): + exists: optional + doc: | + Was a window correction performed? If 'True' describe the + window correction procedure in '' + procedure: + doc: | + Describe when (before or after the main measurement + time + stamp in 'date') and how the window effects have been + corrected, i.e. either mathematically or by performing a + reference measurement. In the latter case, provide the link to + to the reference data in 'reference_data_link'. + reference_data_link: + exists: optional + doc: | + Link to the NeXus file which describes the reference data if a + reference measurement for window correction was performed. + Ideally, the reference measurement was performed on a reference + sample and on the same sample, and using the same conditions as + for the actual measurement with and without windows. It should + have been conducted as close in time to the actual measurement + as possible. + material(NX_CHAR): + doc: | + The material of the window. + enumeration: [quartz, diamond, calcium fluoride, zinc selenide, thallium bromoiodide, alkali halide compound, Mylar, other] + other_material(NX_CHAR): + exists: optional + doc: | + If you specified 'other' as material, decsribe here what it is. + thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + Thickness of the window. + orientation_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Angle of the window normal (outer) vs. the substrate normal + (similar to the angle of incidence). + (NXsample): + doc: | + Properties of the sample, such as sample type, layer structure, + chemical formula, atom types, its history etc. + Information about the sample stage and sample environment should be + described in ENTRY/INSTRUMENT/sample_stage. + sample_name: + doc: | + Descriptive name of the sample + sample_type: + doc: | + Specify the type of sample, e.g. thin film, single crystal etc. + enumeration: [thin film, single crystal, poly crystal, single layer, multi layer] + layer_structure: + doc: | + Qualitative description of the layer structure for the sample, + starting with the top layer (i.e. the one on the front surface, on + which the light incident), e.g. native oxide/bulk substrate, or + Si/native oxide/thermal oxide/polymer/peptide. + chemical_formula: + doc: | + Chemical formula of the sample. Use the Hill system (explained here: + https://en.wikipedia.org/wiki/Chemical_formula#Hill_system) to write + the chemical formula. In case the sample consists of several layers, + this should be a list of the chemical formulas of the individual + layers, where the first entry is the chemical formula of the top + layer (the one on the front surface, on which the light incident). + The order must be consistent with layer_structure + atom_types: + 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'. + sample_history: + doc: | + Ideally, a reference to the location or a unique (globally + persistent) identifier (e.g.) of e.g. another file which gives + as many as possible details of the material, its microstructure, + and its thermo-chemo-mechanical processing/preparation history. + In the case that such a detailed history of the sample is not + available, use this field as a free-text description to specify + details of the sample and its preparation. + preparation_date(NX_DATE_TIME): + exists: recommended + doc: | + ISO8601 date with time zone (UTC offset) specified. + substrate: + exists: recommended + doc: | + Description of the substrate. + sample_orientation: + exists: optional + doc: | + Specify the sample orientation. + data_collection(NXprocess): + doc: | + Measured data, data errors, and varied parameters. If reference data + were measured they should be considered a separate experiment and a + link to its NeXus file should be added in reference_data_link. + data_identifier(NX_NUMBER): + doc: | + An identifier to correlate data to the experimental conditions, + if several were used in this measurement; typically an index of 0-N. + data_type: + doc: | + Select which type of data was recorded, for example intensity, + reflectivity, transmittance, Psi and Delta etc. + It is possible to have multiple selections. The enumeration list + depends on the type of experiment and may differ for different + application definitions. + enumeration: [intensity, reflectivity, transmittance, Psi/Delta, tan(Psi)/cos(Delta), Mueller matrix, Jones matrix, N/C/S, raw data] + + # This should be a required field, but is set to 'optional' for the moment + NAME_spectrum(NX_FLOAT): + exists: optional + unit: NX_ANY + doc: | + Spectral values (e.g. wavelength or energy) used for the measurement. + An array of 1 or more elements. Length defines N_spectrum. Replace + 'SPECTRUM' by the physical quantity that is used, e.g. wavelength. + dimensions: + rank: 1 + dim: [[1, N_spectrum]] + \@units: + exists: optional + doc: | + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. + measured_data(NX_FLOAT): + unit: NX_ANY + doc: | + Resulting data from the measurement, described by 'data_type'. + + The first dimension is defined by the number of measurements taken, + (N_measurements). The instructions on how to order the values + contained in the parameter vectors given in the doc string of + INSTRUMENT/sample_stage/environment_conditions/PARAMETER/values, + define the N_measurements parameter sets. For example, if the + experiment was performed at three different temperatures + (T1, T2, T3), two different pressures (p1, p2) and two different + angles of incidence (a1, a2), the first measurement was taken at the + parameters {a1,p1,T1}, the second measurement at {a1,p1,T2} etc. + dimensions: + rank: 3 + dim: [[1, N_measurements], [2, N_observables], [3, N_spectrum]] + \@units: + exists: optional + doc: | + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. + measured_data_errors(NX_FLOAT): + exists: optional + unit: NX_ANY + doc: | + Specified uncertainties (errors) of the data described by 'data_type' + and provided in 'measured_data'. + dimensions: + rank: 3 + dim: [[1, N_measurements], [2, N_observables], [3, N_spectrum]] + \@units: + exists: optional + doc: | + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. + varied_parameter_link: + exists: optional + doc: | + List of links to the values of the sensors. Add a link for each + varied parameter (i.e. for each sensor). + dimensions: + rank: 1 + dim: [[1, N_sensors]] + reference_data_link: + exists: optional + doc: | + Link to the NeXus file which describes the reference data if a + reference measurement was performed. Ideally, the reference + measurement was performed using the same conditions as the actual + measurement and should be as close in time to the actual measurement + as possible. + data_software(NXprocess): + exists: optional + program: + doc: | + Commercial or otherwise defined given name of the program that was + used to generate the result file(s) with measured data and/or + metadata (in most cases, this is the same as INSTRUMENT/software). + If home written, one can provide the actual steps in the NOTE + subfield here. + version: + doc: | + Either version with build number, commit hash, or description of a + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + \@url: + exists: optional + doc: | + Website of the software. + (NXdata): + exists: optional + doc: | + A plot of the multi-dimensional data array provided in + ENTRY/data/measured_data. + \@axes: + doc: | + Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) + derived_parameters(NXprocess): + exists: optional + doc: | + Parameters that are derived from the measured data. + depolarization(NX_NUMBER): + exists: optional + unit: NX_UNITLESS + doc: | + Light loss due to depolarization as a value in [0-1]. + dimensions: + rank: 3 + dim: [[1, N_measurements], [2, 1], [3, N_spectrum]] + Jones_quality_factor(NX_NUMBER): + exists: optional + unit: NX_UNITLESS + doc: | + Jones quality factor. + dimensions: + rank: 3 + dim: [[1, N_measurements], [2, 1], [3, N_spectrum]] + reflectivity(NX_NUMBER): + exists: optional + unit: NX_UNITLESS + doc: | + Reflectivity. + dimensions: + rank: 3 + dim: [[1, N_measurements], [2, 1], [3, N_spectrum]] + transmittance(NX_NUMBER): + exists: optional + unit: NX_UNITLESS + doc: | + Transmittance. + dimensions: + rank: 3 + dim: [[1, N_measurements], [2, 1], [3, N_spectrum]] + ANALYSIS_program(NXprocess): + exists: optional + program: + doc: | + Commercial or otherwise defined given name of the program that was + used to generate or calculate the derived parameters. + If home written, one can provide the actual steps in the NOTE + subfield here. + version: + doc: | + Either version with build number, commit hash, or description of a + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + plot(NXdata): + doc: | + A default view of the data provided in ENTRY/data_collection/measured_data. This + should be the part of the data set which provides the most suitable + representation of the data. + \@axes: + doc: | + Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 7d68d553b6c55f5cdd8fe8d92c325b137c71c875c2bd742f5cf2150df56f4398 +# +# +# +# +# +# +# +# +# Variables used throughout the document, e.g. dimensions or parameters. +# +# +# +# Length of the spectrum array (e.g. wavelength or energy) of the measured +# data. +# +# +# +# +# Number of sensors used to measure parameters that influence the sample, +# such as temperature or pressure. +# +# +# +# +# Number of measurements (1st dimension of measured_data array). This is +# equal to the number of parameters scanned. For example, if the experiment +# was performed at three different temperatures and two different pressures +# N_measurements = 2*3 = 6. +# +# +# +# +# Number of detection angles of the beam reflected or scattered off the +# sample. +# +# +# +# +# Number of angles of incidence of the incident beam. +# +# +# +# +# Number of observables that are saved in a measurement. e.g. one for +# intensity, reflectivity or transmittance, two for Psi and Delta etc. This +# is equal to the second dimension of the data array 'measured_data' and the +# number of column names. +# +# +# +# +# An application definition for optical spectroscopy experiments. +# +# +# +# An application definition template for optical spectroscopy experiments. +# +# A general optical experiment consists of a light or excitation source, a +# beam path, a sample + its stage + its environment, and a detection unit. +# Examples are reflection or transmission measurements, photoluminescence, +# Raman spectroscopy, ellipsometry etc. +# +# +# +# An application definition describing a general optical experiment. +# +# +# +# Version number to identify which definition of this application +# definition was used for this entry/data. +# +# +# +# +# URL where to find further material (documentation, examples) relevant +# to the application definition. +# +# +# +# +# +# +# +# +# A (globally persistent) unique identifier of the experiment. +# (i) The identifier is usually defined by the facility or principle +# investigator. +# (ii) The identifier enables to link experiments to e.g. proposals. +# +# +# +# +# An optional free-text description of the experiment. +# +# However, details of the experiment should be defined in the specific +# fields of this application definition rather than in this experiment +# description. +# +# +# +# +# Specify the type of the optical experiment. +# +# +# +# +# Start time of the experiment. UTC offset should be specified. +# +# +# +# +# Contact information of at least the user of the instrument or the +# investigator who performed this experiment. +# Adding multiple users, if relevant, is recommended. +# +# +# +# Name of the user. +# +# +# +# +# Name of the affiliation of the user at the point in time when the +# experiment was performed. +# +# +# +# +# Street address of the user's affiliation. +# +# +# +# +# Email address of the user. +# +# +# +# +# Author ID defined by https://orcid.org/. +# +# +# +# +# Telephone number of the user. +# +# +# +# +# +# Properties of the experimental setup. This includes general information +# about the instrument (such as model, company etc.), information about +# the calibration of the instrument, elements of the beam path including +# the excitation or light source and the detector unit, the sample stage +# (plus the sample environment, which also includes sensors used to +# monitor external conditions) and elements of the beam path. +# +# Meta data describing the sample should be specified in ENTRY/SAMPLE +# outside of ENTRY/INSTRUMENT. +# +# +# +# The name of the instrument. +# +# +# +# The used version of the hardware if available. If not a commercial +# instrument use date of completion of the hardware. +# +# +# +# +# +# Name of the company which build the instrument. +# +# +# +# +# ISO8601 date when the instrument was constructed. +# UTC offset should be specified. +# +# +# +# +# +# Commercial or otherwise defined given name of the program that was +# used to measure the data, i.e. the software used to start and +# record the measured data and/or metadata. +# If home written, one can provide the actual steps in the NOTE +# subfield here. +# +# +# +# +# Either version with build number, commit hash, or description of a +# (online) repository where the source code of the program and build +# instructions can be found so that the program can be configured in +# such a way that result files can be created ideally in a +# deterministic manner. +# +# +# +# +# Website of the software. +# +# +# +# +# +# Commercial or otherwise defined name of the firmware that was used +# for the measurement - if available. +# +# +# +# Version and build number or commit hash of the software source code. +# +# +# +# +# Website of the software. +# +# +# +# +# +# Was a calibration performed? If yes, when was it done? If the +# calibration time is provided, it should be specified in +# ENTRY/INSTRUMENT/calibration/calibration_time. +# +# +# +# +# +# +# +# +# +# +# +# The calibration data and metadata should be described in a separate NeXus file +# with the link provided in 'calibration_link'. +# +# +# +# If calibtration status is 'calibration time provided', specify the +# ISO8601 date when calibration was last performed before this +# measurement. UTC offset should be specified. +# +# +# +# +# Link to the NeXus file containing the calibration data and metadata. +# +# +# +# +# +# Describes an arrangement of optical or other elements, e.g. the beam +# path between the light source and the sample, or between the sample +# and the detector unit (including the sources and detectors +# themselves). +# +# If a beam splitter (i.e. a device that splits the incoming beam into +# two or more beams) is part of the beam path, two or more NXbeam_path +# fields may be needed to fully describe the beam paths and the correct +# sequence of the beam path elements. +# Use as many beam paths as needed to describe the setup. +# +# +# +# +# Angle(s) of the incident beam vs. the normal of the bottom reflective +# (substrate) surface in the sample. +# +# +# +# +# +# +# +# +# Detection angle(s) of the beam reflected or scattered off the sample +# vs. the normal of the bottom reflective (substrate) surface in the +# sample if not equal to the angle(s) of incidence. +# +# +# +# +# +# +# +# Sample stage, holding the sample at a specific position in X,Y,Z +# (Cartesian) coordinate system and at an orientation defined +# by three Euler angles (alpha, beta, gamma). +# +# +# +# Specify the type of the sample stage. +# +# +# +# +# +# +# +# +# +# +# +# If there is no motorized stage, we should at least qualify where +# the beam hits the sample and in what direction the sample stands +# in a free-text description, e.g. 'center of sample, long edge +# parallel to the plane of incidence'. +# +# +# +# +# Specify external parameters that have influenced the sample, such +# as the surrounding medium, and varied parameters e.g. temperature, +# pressure, pH value, optical excitation etc. +# +# +# +# Describe what was the medium above or around the sample. The +# common model is built up from the substrate to the medium on the +# other side. Both boundaries are assumed infinite in the model. +# Here, define the name of the medium (e.g. water, air, UHV, etc.). +# +# +# +# +# Array of pairs of complex refractive indices n + ik of the medium +# for every measured spectral point/wavelength/energy. +# Only necessary if the measurement was performed not in air, or +# something very well known, e.g. high purity water. +# +# +# +# +# +# +# +# +# A sensor used to monitor an external condition influencing the +# sample, such as temperature or pressure. It is suggested to +# replace 'PARAMETER' by the type of the varied parameter defined +# in 'parameter_type'. +# The measured parameter values should be provided in 'values'. +# For each parameter, a 'PARAMETER(NXsensor)' field needs to exist. +# In other words, there are N_sensors 'PARAMETER(NXsensor)' fields. +# +# +# +# Indicates which parameter was changed. Its definition must exist +# below. The specified variable has to be N_measurements long, +# providing the parameters for each data set. If you vary more than +# one parameter simultaneously. +# If the measured parameter is not contained in the list `other` +# should be specified and the `parameter_type_name` should be provided. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# If the parameter_type is `other` a name should be specified here. +# +# +# +# +# Number of different parameter values at which the measurement +# was performed. For example, if the measurement was performed at +# temperatures of 4, 77 and 300 K, then number_of_parameters = 3. +# +# +# +# +# Vector containing the values of the varied parameter. Its +# length is equal to N_measurements. The order of the values +# should be as follows: +# +# * Order the sensors according to number_of_parameters starting +# with the lowest number. If number_of_parameters is equal for +# two sensors order them alphabetically (sensor/parameter name). +# * The first sensor's j parameters should be ordered in the +# following way. The first N_measurements/number_of_parameters +# entries of the vector contain the first parameter (a1), the +# second N_measurements/number_of_parameters contain the second +# parameter (a2) etc., so the vector looks like: +# [ +# a1,a1,...,a1, +# a2,a2,...,a2, +# ... +# aj,aj,...aj +# ] +# * The kth sensor's m parameters should be ordered in the +# following way: +# [ +# p1,...p1,p2,...,p2,...pm,...,pm, +# p1,...p1,p2,...,p2,...pm,...,pm, +# ... +# p1,...p1,p2,...,p2,...pm,...,pm +# ] +# * The last sensor's n parameters should be ordered in the +# following way: +# [ +# z1,z2,...,zn, +# z1,z2,...,zn, +# ... +# z1,z2,...,zn] +# +# For example, if the experiment was performed at three different +# temperatures (T1, T2, T3), two different pressures (p1, p2) and +# two different angles of incidence (a1, a2), then +# N_measurements = 12 and the order of the values for the various +# parameter vectors is: +# +# * angle_of_incidence: [a1,a1,a1,a1,a1,a1,a2,a2,a2,a2,a2,a2] +# * pressure: [p1,p1,p1,p2,p2,p2,p1,p1,p1,p2,p2,p2] +# * temperature: [T1,T2,T3,T1,T2,T3,T1,T2,T3,T1,T2,T3] +# +# +# +# +# +# +# +# +# +# For environmental measurements, the environment (liquid, vapor +# etc.) is enclosed in a cell, which has windows both in the +# direction of the source (entry window) and the detector (exit +# window) (looking from the sample). In case that the entry and exit +# windows are not the same type and do not have the same properties, +# use a second 'WINDOW(MXaperture)' field. +# +# The windows also add a phase shift to the light altering the +# measured signal. This shift has to be corrected based on measuring +# a known sample (reference sample) or the actual sample of interest +# in the environmental cell. State if a window correction has been +# performed in 'window_effects_corrected'. Reference data should be +# considered as a separate experiment, and a link to the NeXus file +# should be added in reference_data_link in measured_data. +# +# The window is considered to be a part of the sample stage but also +# beam path. Hence, its position within the beam path should be +# defined by the 'depends_on' field. +# +# +# +# Specify the position of the window in the beam path by pointing +# to the preceding element in the sequence of beam path elements. +# +# +# +# +# Was a window correction performed? If 'True' describe the window +# correction procedure in 'window_correction/procedure'. +# +# +# +# +# Was a window correction performed? If 'True' describe the +# window correction procedure in '' +# +# +# +# Describe when (before or after the main measurement + time +# stamp in 'date') and how the window effects have been +# corrected, i.e. either mathematically or by performing a +# reference measurement. In the latter case, provide the link to +# to the reference data in 'reference_data_link'. +# +# +# +# +# Link to the NeXus file which describes the reference data if a +# reference measurement for window correction was performed. +# Ideally, the reference measurement was performed on a reference +# sample and on the same sample, and using the same conditions as +# for the actual measurement with and without windows. It should +# have been conducted as close in time to the actual measurement +# as possible. +# +# +# +# +# +# The material of the window. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# If you specified 'other' as material, decsribe here what it is. +# +# +# +# +# Thickness of the window. +# +# +# +# +# Angle of the window normal (outer) vs. the substrate normal +# (similar to the angle of incidence). +# +# +# +# +# +# +# +# Properties of the sample, such as sample type, layer structure, +# chemical formula, atom types, its history etc. +# Information about the sample stage and sample environment should be +# described in ENTRY/INSTRUMENT/sample_stage. +# +# +# +# Descriptive name of the sample +# +# +# +# +# Specify the type of sample, e.g. thin film, single crystal etc. +# +# +# +# +# +# +# +# +# +# +# +# Qualitative description of the layer structure for the sample, +# starting with the top layer (i.e. the one on the front surface, on +# which the light incident), e.g. native oxide/bulk substrate, or +# Si/native oxide/thermal oxide/polymer/peptide. +# +# +# +# +# Chemical formula of the sample. Use the Hill system (explained here: +# https://en.wikipedia.org/wiki/Chemical_formula#Hill_system) to write +# the chemical formula. In case the sample consists of several layers, +# this should be a list of the chemical formulas of the individual +# layers, where the first entry is the chemical formula of the top +# layer (the one on the front surface, on which the light incident). +# The order must be consistent with layer_structure +# +# +# +# +# List of comma-separated elements from the periodic table that are +# contained in the sample. If the sample substance has multiple +# components, all elements from each component must be included in +# 'atom_types'. +# +# +# +# +# Ideally, a reference to the location or a unique (globally +# persistent) identifier (e.g.) of e.g. another file which gives +# as many as possible details of the material, its microstructure, +# and its thermo-chemo-mechanical processing/preparation history. +# In the case that such a detailed history of the sample is not +# available, use this field as a free-text description to specify +# details of the sample and its preparation. +# +# +# +# +# ISO8601 date with time zone (UTC offset) specified. +# +# +# +# +# Description of the substrate. +# +# +# +# +# Specify the sample orientation. +# +# +# +# +# +# Measured data, data errors, and varied parameters. If reference data +# were measured they should be considered a separate experiment and a +# link to its NeXus file should be added in reference_data_link. +# +# +# +# An identifier to correlate data to the experimental conditions, +# if several were used in this measurement; typically an index of 0-N. +# +# +# +# +# Select which type of data was recorded, for example intensity, +# reflectivity, transmittance, Psi and Delta etc. +# It is possible to have multiple selections. The enumeration list +# depends on the type of experiment and may differ for different +# application definitions. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Spectral values (e.g. wavelength or energy) used for the measurement. +# An array of 1 or more elements. Length defines N_spectrum. Replace +# 'SPECTRUM' by the physical quantity that is used, e.g. wavelength. +# +# +# +# +# +# +# If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. +# If the unit of the measured data is not covered by NXDL units state +# here which unit was used. +# +# +# +# +# +# Resulting data from the measurement, described by 'data_type'. +# +# The first dimension is defined by the number of measurements taken, +# (N_measurements). The instructions on how to order the values +# contained in the parameter vectors given in the doc string of +# INSTRUMENT/sample_stage/environment_conditions/PARAMETER/values, +# define the N_measurements parameter sets. For example, if the +# experiment was performed at three different temperatures +# (T1, T2, T3), two different pressures (p1, p2) and two different +# angles of incidence (a1, a2), the first measurement was taken at the +# parameters {a1,p1,T1}, the second measurement at {a1,p1,T2} etc. +# +# +# +# +# +# +# +# +# If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. +# If the unit of the measured data is not covered by NXDL units state +# here which unit was used. +# +# +# +# +# +# Specified uncertainties (errors) of the data described by 'data_type' +# and provided in 'measured_data'. +# +# +# +# +# +# +# +# +# If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. +# If the unit of the measured data is not covered by NXDL units state +# here which unit was used. +# +# +# +# +# +# List of links to the values of the sensors. Add a link for each +# varied parameter (i.e. for each sensor). +# +# +# +# +# +# +# +# Link to the NeXus file which describes the reference data if a +# reference measurement was performed. Ideally, the reference +# measurement was performed using the same conditions as the actual +# measurement and should be as close in time to the actual measurement +# as possible. +# +# +# +# +# +# Commercial or otherwise defined given name of the program that was +# used to generate the result file(s) with measured data and/or +# metadata (in most cases, this is the same as INSTRUMENT/software). +# If home written, one can provide the actual steps in the NOTE +# subfield here. +# +# +# +# +# Either version with build number, commit hash, or description of a +# (online) repository where the source code of the program and build +# instructions can be found so that the program can be configured in +# such a way that result files can be created ideally in a +# deterministic manner. +# +# +# +# +# Website of the software. +# +# +# +# +# +# A plot of the multi-dimensional data array provided in +# ENTRY/data/measured_data. +# +# +# +# Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) +# +# +# +# +# +# +# Parameters that are derived from the measured data. +# +# +# +# Light loss due to depolarization as a value in [0-1]. +# +# +# +# +# +# +# +# +# +# Jones quality factor. +# +# +# +# +# +# +# +# +# +# Reflectivity. +# +# +# +# +# +# +# +# +# +# Transmittance. +# +# +# +# +# +# +# +# +# +# +# Commercial or otherwise defined given name of the program that was +# used to generate or calculate the derived parameters. +# If home written, one can provide the actual steps in the NOTE +# subfield here. +# +# +# +# +# Either version with build number, commit hash, or description of a +# (online) repository where the source code of the program and build +# instructions can be found so that the program can be configured in +# such a way that result files can be created ideally in a +# deterministic manner. +# +# +# +# +# +# +# A default view of the data provided in ENTRY/data_collection/measured_data. This +# should be the part of the data set which provides the most suitable +# representation of the data. +# +# +# +# Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXoptical_system_em.yaml b/contributed_definitions/nyaml/NXoptical_system_em.yaml new file mode 100644 index 0000000000..adb28a6bbf --- /dev/null +++ b/contributed_definitions/nyaml/NXoptical_system_em.yaml @@ -0,0 +1,139 @@ +category: base +doc: | + A container for qualifying an electron optical system. +type: group +NXoptical_system_em(NXobject): + + # NEW ISSUE: for now used to store difficult to place entries + # NEW ISSUE: all the definitions here should better be backed up by the + # work of the HMC EM glossary activities + camera_length(NX_NUMBER): + unit: NX_LENGTH + doc: | + Citing the JEOL TEM glossary this is *an effective distance from a specimen + to a plane where an observed diffraction pattern is formed*. + magnification(NX_NUMBER): + unit: NX_DIMENSIONLESS + doc: | + The factor of enlargement of the apparent size, not physical size, of an object. + defocus(NX_NUMBER): + unit: NX_LENGTH + doc: | + The defocus aberration constant oftentimes taken as the C_1_0 which + is described in more details in NXaberration. + semi_convergence_angle(NX_NUMBER): + unit: NX_ANGLE + doc: | + Citing the JEOL TEM glosssary this is the value *when a cone shaped, + convergent electron beam illuminates a specimen, the semi-angle of the cone + is termed convergence angle.* + field_of_view(NX_NUMBER): + unit: NX_LENGTH + doc: | + The extent of the observable parts of the specimen given the current + magnification and other settings of the instrument. + working_distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + Citing `Globalsino `_ this is + *a distance between the specimen and the lower pole piece in SEM system*. + beam_current(NX_FLOAT): + unit: NX_CURRENT + doc: | + Beam current as measured relevant for the illumination of the specimen. + Users should specify further details like how the beam current was measured + using the beam_current_description field. + beam_current_description: + doc: | + Specify further details how the beam current was measured or estimated. + + # NEW ISSUE: the KIT/SCC propose: + # adding of the image_mode or field mode + # imageMode: enum: [normal_image, sad, eds, nbd, cbed] + # fieldMode: enum: [dark_field, bright_field] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# c81cab49c10f4d26c4c1c8834c33cc1fbd7e6d4cce5ff838cd22e482d2114a6b +# +# +# +# +# +# A container for qualifying an electron optical system. +# +# +# +# +# Citing the JEOL TEM glossary this is *an effective distance from a specimen +# to a plane where an observed diffraction pattern is formed*. +# +# +# +# +# The factor of enlargement of the apparent size, not physical size, of an object. +# +# +# +# +# The defocus aberration constant oftentimes taken as the C_1_0 which +# is described in more details in NXaberration. +# +# +# +# +# Citing the JEOL TEM glosssary this is the value *when a cone shaped, +# convergent electron beam illuminates a specimen, the semi-angle of the cone +# is termed convergence angle.* +# +# +# +# +# The extent of the observable parts of the specimen given the current +# magnification and other settings of the instrument. +# +# +# +# +# Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is +# *a distance between the specimen and the lower pole piece in SEM system*. +# +# +# +# +# Beam current as measured relevant for the illumination of the specimen. +# Users should specify further details like how the beam current was measured +# using the beam_current_description field. +# +# +# +# +# Specify further details how the beam current was measured or estimated. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXorientation_set.yaml b/contributed_definitions/nyaml/NXorientation_set.yaml new file mode 100644 index 0000000000..1973be4684 --- /dev/null +++ b/contributed_definitions/nyaml/NXorientation_set.yaml @@ -0,0 +1,228 @@ +category: base +doc: | + Details about individual orientations of a set of objects. + + For a more detailed insight into the discussion of parameterizing + orientations in materials science see: + + * https://doi.org/10.1016/j.matchar.2016.04.008 + * https://doi.org/10.1088/0965-0393/23/8/083501 + * https://doi.org/10.1007/978-3-662-09156-2 group-theory of rotations + * https://doi.org/10.1016/C2013-0-11769-2 the classical book of H.-J. Bunge + +# This class stores a set of specifically parameterized NXtransformations which describe +# how each object is oriented/rotated with respect to a reference coordinate system. +# we should offer here support for d==2, d==3 +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality of the reference space/coordinate system. + c: | + The cardinality of the set, i.e. the number of orientations. + n_p: | + Number of parameters for the chosen parameterization. +type: group +NXorientation_set(NXobject): + + # depending on the dimensionality n_p is correlated but not necessarily, e.g. for d==3 one can store quaternions (n_p==4) or Bunge-Euler angles (n_p==3) + # clearly one could think about a single best approach that everybody should use, and indeed quaternions could be a candidate but this conflicts with the + # expectations understanding and in fact habit by very many materials engineers who know and report their values in Euler angles so at least one would need to + # have a system in place which converts... + (NXtransformations): + doc: | + Reference to or definition of a coordinate system with + which the definitions are interpretable. + parameterization: + enumeration: [bunge-euler (ZXZ), quaternion] + + # how to take into account the reduction to two-d? just list these cases XY, XZ, ... also in the enumeration? + # an instance of an NXorientation_set is useful as attribute (meta)data to a set of microstructural objects e.g. crystals, grains when the base class is stored as a sub-ordinate of the grain_set + # one may argue we expect that for each grain there is an orientation value, in this case the indexing is implicit and this is often used in computer simulations + # without making a specific statement that e.g. the 0-th value of the array gives the volume of the 0-th grain but that 0-th grain might not necessarily be named as grain 0 but e.g. grain 23 + # because many computer simulations deal with ensemble where the number of objects changes over time, e.g. molecular dynamics simulation treat always the same set of atoms but post-processing + # of the data may reveal these atoms are grouped/labelled as different microstructural features (grains, dislocations, vacancies) and then the names/identifiers of the objects may change over time + # therefore the idea to specify if we use implicit or explicit indexing and listing of the indices because I know of colleagues where even that went havoc! + objects: + doc: | + A link or reference to the objects whose identifier are referred to in + identifier to resolve which row tuple is the orientation of each object + by reading orientations. + identifier_offset(NX_INT): + unit: NX_UNITLESS + doc: | + Integer which specifies which orientation (row of array orientation) matches + to which object.e first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly + or explicitly. For implicit indexing the identifiers are defined on the + interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + The identifier_offset field can for example be used to communicate if the + identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) + or from 0 (referred to as C-, Python-style index notation) respectively. + identifier(NX_INT): + unit: NX_UNITLESS + doc: | + Integer used to distinguish how a row in orientation describes a specific + object with an explicit identifier that can be queried via inspecting the + list of available objects in objects. + + The rational behind having such a more complicated pattern is that not + all objects referred when following the link in objects may still exists + or are still tracked when the orientation set was characterized. + + This design enables to also use NXorientation_set in situations where + the orientation of objects change as a function in time. + dimensions: + rank: 1 + dim: [[1, c]] + orientation(NX_NUMBER): + unit: NX_ANY + doc: | + Parameterized orientations. + dimensions: + rank: 2 + dim: [[1, c], [2, n_p]] + + # e.g. in this way one could easily, efficiently, store and map familiar habits of microscopists + # to store e.g. orientations of measurement points or of grains via a (c := Ngrains, n_p := 3) + # matrix of Bunge-Euler angles, or of (c := Ngrains, n_p := 4) matrix of quaternions. + + # the benefit of such a representation is that with a known NXorientation_set base class one can implement a common parameterization transformation library (of which several already exist) in the microstructure modelling communities so that a program can read the information in the (NXorientation_set) instance and automatically transform/compute between different parameterizations. Super relevant for interoperability e.g. in SEM/EBSD, where this was a long standing issue and right now the most frequently accepted consensus is to report either Bunge-Euler angles or quaternions and then use existent transformation libraries (as implemented by e.g. Marc de Graeff for SEM/EBSD and used by many but not yet the majority of people in the computational materials modelling community within crystal plasticity, crystal growth modeling, DREAM.3D) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 7a4adc6ee268ebf58286cf4baf9b25c5b8a808a01404292c31390f4f3f0a0ad0 +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The dimensionality of the reference space/coordinate system. +# +# +# +# +# The cardinality of the set, i.e. the number of orientations. +# +# +# +# +# Number of parameters for the chosen parameterization. +# +# +# +# +# Details about individual orientations of a set of objects. +# +# For a more detailed insight into the discussion of parameterizing +# orientations in materials science see: +# +# * https://doi.org/10.1016/j.matchar.2016.04.008 +# * https://doi.org/10.1088/0965-0393/23/8/083501 +# * https://doi.org/10.1007/978-3-662-09156-2 group-theory of rotations +# * https://doi.org/10.1016/C2013-0-11769-2 the classical book of H.-J. Bunge +# +# +# +# +# Reference to or definition of a coordinate system with +# which the definitions are interpretable. +# +# +# +# +# +# +# +# +# +# +# +# A link or reference to the objects whose identifier are referred to in +# identifier to resolve which row tuple is the orientation of each object +# by reading orientations. +# +# +# +# +# Integer which specifies which orientation (row of array orientation) matches +# to which object.e first index to be used for distinguishing +# hexahedra. Identifiers are defined either implicitly +# or explicitly. For implicit indexing the identifiers are defined on the +# interval [identifier_offset, identifier_offset+c-1]. +# For explicit indexing the identifier array has to be defined. +# +# The identifier_offset field can for example be used to communicate if the +# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) +# or from 0 (referred to as C-, Python-style index notation) respectively. +# +# +# +# +# Integer used to distinguish how a row in orientation describes a specific +# object with an explicit identifier that can be queried via inspecting the +# list of available objects in objects. +# +# The rational behind having such a more complicated pattern is that not +# all objects referred when following the link in objects may still exists +# or are still tracked when the orientation set was characterized. +# +# This design enables to also use NXorientation_set in situations where +# the orientation of objects change as a function in time. +# +# +# +# +# +# +# +# Parameterized orientations. +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXpeak.yaml b/contributed_definitions/nyaml/NXpeak.yaml new file mode 100644 index 0000000000..401c3b497d --- /dev/null +++ b/contributed_definitions/nyaml/NXpeak.yaml @@ -0,0 +1,136 @@ +category: base +doc: | + Description of peaks, their functional form or measured support. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_support: | + Number of support points +type: group +NXpeak(NXobject): + label: + doc: | + Human-readable identifier to specify which concept/entity + the peak represents/identifies. + peak_model: + doc: | + Is the peak described analytically via a functional form + or is it empirically defined via measured/reported + intensity/counts as a function of an independent variable. + + If the functional form is not empirical or gaussian, users + should enter other for the peak_model and add relevant details + in the NXcollection. + enumeration: [empirical, gaussian, lorentzian, other] + position(NX_NUMBER): + unit: NX_ANY + doc: | + In the case of an empirical description of the peak and its shoulders, + this array holds the position values for the independent variable. + dimensions: + rank: 1 + dim: [[1, n_support]] + intensity(NX_NUMBER): + unit: NX_ANY + doc: | + In the case of an empirical description of the peak and its shoulders, + this array holds the intensity/count values at each position. + dimensions: + rank: 1 + dim: [[1, n_support]] + (NXcollection): + doc: | + In the case of an analytical description (or if peak_model is other) this + collection holds parameter of (and eventually) the functional form. + For example in the case of Gaussians mu, sigma, cut-off values, + and background intensity are relevant parameter. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 40c5d1ea859b17085a2dacf79ad49f540f43ddf2d8e2374a0adb1ef5cd9434ea +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of support points +# +# +# +# +# Description of peaks, their functional form or measured support. +# +# +# +# Human-readable identifier to specify which concept/entity +# the peak represents/identifies. +# +# +# +# +# Is the peak described analytically via a functional form +# or is it empirically defined via measured/reported +# intensity/counts as a function of an independent variable. +# +# If the functional form is not empirical or gaussian, users +# should enter other for the peak_model and add relevant details +# in the NXcollection. +# +# +# +# +# +# +# +# +# +# +# In the case of an empirical description of the peak and its shoulders, +# this array holds the position values for the independent variable. +# +# +# +# +# +# +# +# In the case of an empirical description of the peak and its shoulders, +# this array holds the intensity/count values at each position. +# +# +# +# +# +# +# +# In the case of an analytical description (or if peak_model is other) this +# collection holds parameter of (and eventually) the functional form. +# For example in the case of Gaussians mu, sigma, cut-off values, +# and background intensity are relevant parameter. +# +# +# diff --git a/contributed_definitions/nyaml/NXphysical_process.yaml b/contributed_definitions/nyaml/NXphysical_process.yaml new file mode 100644 index 0000000000..24a515e973 --- /dev/null +++ b/contributed_definitions/nyaml/NXphysical_process.yaml @@ -0,0 +1,92 @@ +category: base +doc: | + A planned or unplanned process which results in physical changes in a specified material. + + A physical change involve changes only in intermolecular forces, not in the chemical bonds. + Examples include sample preparation, material transformation, or (partially) destructive measurements. +type: group +NXphysical_process(NXobject): + start_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code (with local time zone offset to UTC information + included) when this process started. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code (with local time zone offset to UTC information + included) when this process ended. + description: + doc: | + Short description of the activity. + method: + doc: | + Method by which this process was performed. + notes(NXnote): + doc: | + This can be any data or other descriptor acquired during the physical process + (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 5792f0ac3cb2c2b5c936e7046ea9dc831875bc6ab9e674c6f705fe2e252c08ce +# +# +# +# +# +# A planned or unplanned process which results in physical changes in a specified material. +# +# A physical change involve changes only in intermolecular forces, not in the chemical bonds. +# Examples include sample preparation, material transformation, or (partially) destructive measurements. +# +# +# +# ISO 8601 formatted time code (with local time zone offset to UTC information +# included) when this process started. +# +# +# +# +# ISO 8601 formatted time code (with local time zone offset to UTC information +# included) when this process ended. +# +# +# +# +# Short description of the activity. +# +# +# +# +# Method by which this process was performed. +# +# +# +# +# This can be any data or other descriptor acquired during the physical process +# (NXnote allows to add pictures, audio, movies). Alternatively, a +# reference to the location or a unique identifier or other metadata file. In the +# case these are not available, free-text description. +# +# +# diff --git a/contributed_definitions/nyaml/NXpid.yaml b/contributed_definitions/nyaml/NXpid.yaml new file mode 100644 index 0000000000..8ba001de93 --- /dev/null +++ b/contributed_definitions/nyaml/NXpid.yaml @@ -0,0 +1,151 @@ +category: base +doc: | + Contains the settings of a PID controller. +type: group +NXpid(NXobject): + description: + doc: | + Description of how the Process Value for the PID controller is produced by sensor(s) in the setup. + + For example, a set of sensors could be averaged over before feeding it back into the loop. + pv_sensor(NXsensor): + doc: | + The sensor representing the Process Value used in the feedback loop for the PID. + + In case multiple sensors were used, this NXsensor should contain the proper calculated/aggregated value. + value_log(NXlog): + value(NX_NUMBER): + doc: | + The actual timeseries data fed back to the PID loop. + setpoint(NX_FLOAT): + unit: NX_ANY + doc: | + The Setpoint(s) used as an input for the PID controller. + + It can also be a link to an NXsensor.value field. + K_p_value(NX_NUMBER): + doc: | + Proportional term. The proportional term produces an output value + that is proportional to the current error value. + The proportional response can be adjusted by multiplying the error + by a constant Kp, called the proportional gain constant. + The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows I = P/T. + K_i_value(NX_NUMBER): + doc: | + The contribution from the integral term is proportional to both + the magnitude of the error and the duration of the error. + The integral in a PID controller is the sum of the instantaneous + error over time and gives the accumulated offset that should have + been corrected previously. The accumulated error is then + multiplied by the integral gain (Ki) and added to the + controller output. + K_d_value(NX_NUMBER): + doc: | + The derivative of the process error is calculated by determining + the slope of the error over time and multiplying this rate of + change by the derivative gain K_d. The magnitude of the + contribution of the derivative term to the overall control + action is termed the derivative gain, K_d + K_t_const(NX_NUMBER): + unit: NX_TIME + doc: | + The Type switches controller parameters between P/I (proportional gain/integral + gain) and P/T (proportional gain/time constant). The formula for the controller + in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and + time constant are related as follows I = P/T. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 4968f689bb36aeb5edc3b4ec8880134bb1d4fb6735709e32b482405c511409d5 +# +# +# +# +# +# Contains the settings of a PID controller. +# +# +# +# Description of how the Process Value for the PID controller is produced by sensor(s) in the setup. +# +# For example, a set of sensors could be averaged over before feeding it back into the loop. +# +# +# +# +# The sensor representing the Process Value used in the feedback loop for the PID. +# +# In case multiple sensors were used, this NXsensor should contain the proper calculated/aggregated value. +# +# +# +# +# The actual timeseries data fed back to the PID loop. +# +# +# +# +# +# +# The Setpoint(s) used as an input for the PID controller. +# +# It can also be a link to an NXsensor.value field. +# +# +# +# +# Proportional term. The proportional term produces an output value +# that is proportional to the current error value. +# The proportional response can be adjusted by multiplying the error +# by a constant Kp, called the proportional gain constant. +# The Type switches controller parameters between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). The formula for the controller in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time constant are related as follows I = P/T. +# +# +# +# +# The contribution from the integral term is proportional to both +# the magnitude of the error and the duration of the error. +# The integral in a PID controller is the sum of the instantaneous +# error over time and gives the accumulated offset that should have +# been corrected previously. The accumulated error is then +# multiplied by the integral gain (Ki) and added to the +# controller output. +# +# +# +# +# The derivative of the process error is calculated by determining +# the slope of the error over time and multiplying this rate of +# change by the derivative gain K_d. The magnitude of the +# contribution of the derivative term to the overall control +# action is termed the derivative gain, K_d +# +# +# +# +# The Type switches controller parameters between P/I (proportional gain/integral +# gain) and P/T (proportional gain/time constant). The formula for the controller +# in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and +# time constant are related as follows I = P/T. +# +# +# diff --git a/contributed_definitions/nyaml/NXpolarizer_opt.yaml b/contributed_definitions/nyaml/NXpolarizer_opt.yaml new file mode 100644 index 0000000000..71a1505e66 --- /dev/null +++ b/contributed_definitions/nyaml/NXpolarizer_opt.yaml @@ -0,0 +1,411 @@ +category: base +doc: | + An optical polarizer. + + Information on the properties of polarizer is provided e.g. + [here](https://www.rp-photonics.com/polarizers.html). +symbols: + N_spectrum: | + Size of the wavelength array for which the refractive index of the material + and/or coating is given. + N_spectrum_RT: | + Size of the wavelength array for which the reflectance or transmission of + the polarizer is given. + +# A draft of a new base class to describe an optical polarizer +# (NXpolarizer describes a spin polarizer) +type: group +NXpolarizer_opt(NXobject): + type: + doc: | + Type of the polarizer (e.g. dichroic, linear, circular etc.) + enumeration: [dichroic, linear, circular, Glan-Thompson prism, Nicol prism, Glan-Taylor prism, Glan-Focault prism, Wollaston prism, Normarski prism, Senarmont prism, thin-film polarizer, wire grid polarizer, other] + + # ??? Any other common polarizer types ??? + type_other: + doc: | + If you selected 'other' in type specify what it is. + polarizer_angle(NX_NUMBER): + exists: recommended + unit: NX_ANGLE + doc: | + Angle of the polarizer. + acceptance_angle(NX_NUMBER): + exists: recommended + unit: NX_ANGLE + doc: | + Acceptance angle of the polarizer (range). + dimensions: + rank: 1 + dim: [[1, 2]] + (NXshape): + exists: recommended + doc: | + Describe the geometry (shape, dimension etc.) of the device. + Specify the dimensions in 'SHAPE/size'. A sketch of the device should be + provided in the 'sketch(NXdata)' field to clarify (i) the shape and + dimensions of the device, and (ii) the input and outputs (i.e. the + direction of the incoming and outcoming (split) beams). + + # !!! NOTE: this class is the same as for NXbeam_path !!! + shape: + doc: | + Describe the shape (plate, cube, wedged, prism etc.). + enumeration: [cube, cylinder, plate, prism, wedged, other] + other_shape: + doc: | + If you chose 'other' in 'shape' describe what it is. + sketch(NXdata): + doc: | + Sketch of thedevice showing its geometry. The paths of the + incoming and outgoing beam should be illustrated and labelled (0 for + the incoming beam, and 1, 2,..., N_outputs for the outputs). + size: + doc: | + Physical extent of the device. The device might be made up of one or + more objects (NX_objects). The meaning and location of the axes used + will vary according to the value of the 'shape' variable. 'N_shapepar' + defines how many parameters: + + * For 'cube' the parameters are (width, length). + * For 'cylinder' the parameters are (diameter, length). + * For 'plate' the parameters are (width, height, length). + * For 'prism' the parameters are (width, height, length). + * For 'wedged' the parameters are (width, height, shortest length). + The wedge angle should be provided in 'SHAPE/wedge_angle'. + * For 'other' the parameters may be (A, B, C, ...) with the labels + defined in the sketch plotted in 'SHAPE/sketch'. + dimensions: + rank: 2 + dim: [[1, N_objects], [2, N_shapepar]] + wedge_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Wedge angle if 'shape' is 'wedged'. + wavelength_range(NX_FLOAT): + exists: recommended + unit: NX_WAVELENGTH + doc: | + Wavelength range for which the polarizer is designed. Enter the minimum + and maximum wavelength (lower and upper limit) of the range. + dimensions: + rank: 1 + dim: [[1, 2]] + substrate(NXsample): + doc: | + Properties of the substrate material of the polarizer. If the device has + a coating specify the coating material and its properties in 'coating'. + substrate_material: + doc: | + Specify the substrate material of the polarizer. + substrate_thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + Thickness of the polarizer substrate. + index_of_refraction(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Complex index of refraction of the polarizer material. Specify at given + spectral values (wavelength, energy, wavenumber etc.). + dimensions: + rank: 2 + dim: [[1, 2], [2, N_spectrum]] + COATING(NXsample): + + # Used captial letters for COATING so that more than one can be defined if + # the device has different coatings on the front and back side. + doc: | + If the device has a coating describe the material and its properties. + Some basic information can be found e.g. [here] + (https://www.opto-e.com/basics/reflection-transmission-and-coatings). + If the back and front side of the polarizer are coated with different + materials, you may define two coatings (e.g. COATING1 and COATING2). + coating_type: + doc: | + Specify the coating type (e.g. dielectric, anti-reflection (AR), + multilayer coating etc.). + coating_material: + doc: | + Describe the coating material (e.g. MgF2). + coating_thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + Thickness of the coating. + index_of_refraction_coating(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Complex index of refraction of the coating. Specify at given spectral + values (wavelength, energy, wavenumber etc.). + dimensions: + rank: 2 + dim: [[1, 2], [2, N_spectrum_coating]] + extinction_ratio(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Extinction ratio (maximum to minimum transmission). + dimensions: + rank: 1 + dim: [[1, N_spectrum]] + reflection(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Reflection of the polarizer at given wavelength values. + dimensions: + rank: 1 + dim: [[1, N_spectrum_RT]] + transmission(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Transmission of the polarizer at given wavelength values. + dimensions: + rank: 1 + dim: [[1, N_spectrum_RT]] + + # anything missing? + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 10666a419359fcc1d8eddc125ec51a4e8f41584fa36eaffc0c4e01cab6fc3704 +# +# +# +# +# +# +# +# +# Size of the wavelength array for which the refractive index of the material +# and/or coating is given. +# +# +# +# +# Size of the wavelength array for which the reflectance or transmission of +# the polarizer is given. +# +# +# +# +# An optical polarizer. +# +# Information on the properties of polarizer is provided e.g. +# [here](https://www.rp-photonics.com/polarizers.html). +# +# +# +# Type of the polarizer (e.g. dichroic, linear, circular etc.) +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# If you selected 'other' in type specify what it is. +# +# +# +# +# Angle of the polarizer. +# +# +# +# +# Acceptance angle of the polarizer (range). +# +# +# +# +# +# +# +# Describe the geometry (shape, dimension etc.) of the device. +# Specify the dimensions in 'SHAPE/size'. A sketch of the device should be +# provided in the 'sketch(NXdata)' field to clarify (i) the shape and +# dimensions of the device, and (ii) the input and outputs (i.e. the +# direction of the incoming and outcoming (split) beams). +# +# +# +# +# Describe the shape (plate, cube, wedged, prism etc.). +# +# +# +# +# +# +# +# +# +# +# +# +# If you chose 'other' in 'shape' describe what it is. +# +# +# +# +# Sketch of thedevice showing its geometry. The paths of the +# incoming and outgoing beam should be illustrated and labelled (0 for +# the incoming beam, and 1, 2,..., N_outputs for the outputs). +# +# +# +# +# Physical extent of the device. The device might be made up of one or +# more objects (NX_objects). The meaning and location of the axes used +# will vary according to the value of the 'shape' variable. 'N_shapepar' +# defines how many parameters: +# +# * For 'cube' the parameters are (width, length). +# * For 'cylinder' the parameters are (diameter, length). +# * For 'plate' the parameters are (width, height, length). +# * For 'prism' the parameters are (width, height, length). +# * For 'wedged' the parameters are (width, height, shortest length). +# The wedge angle should be provided in 'SHAPE/wedge_angle'. +# * For 'other' the parameters may be (A, B, C, ...) with the labels +# defined in the sketch plotted in 'SHAPE/sketch'. +# +# +# +# +# +# +# +# +# Wedge angle if 'shape' is 'wedged'. +# +# +# +# +# +# Wavelength range for which the polarizer is designed. Enter the minimum +# and maximum wavelength (lower and upper limit) of the range. +# +# +# +# +# +# +# +# Properties of the substrate material of the polarizer. If the device has +# a coating specify the coating material and its properties in 'coating'. +# +# +# +# Specify the substrate material of the polarizer. +# +# +# +# +# Thickness of the polarizer substrate. +# +# +# +# +# Complex index of refraction of the polarizer material. Specify at given +# spectral values (wavelength, energy, wavenumber etc.). +# +# +# +# +# +# +# +# +# +# +# If the device has a coating describe the material and its properties. +# Some basic information can be found e.g. [here] +# (https://www.opto-e.com/basics/reflection-transmission-and-coatings). +# If the back and front side of the polarizer are coated with different +# materials, you may define two coatings (e.g. COATING1 and COATING2). +# +# +# +# Specify the coating type (e.g. dielectric, anti-reflection (AR), +# multilayer coating etc.). +# +# +# +# +# Describe the coating material (e.g. MgF2). +# +# +# +# +# Thickness of the coating. +# +# +# +# +# Complex index of refraction of the coating. Specify at given spectral +# values (wavelength, energy, wavenumber etc.). +# +# +# +# +# +# +# +# +# +# Extinction ratio (maximum to minimum transmission). +# +# +# +# +# +# +# +# Reflection of the polarizer at given wavelength values. +# +# +# +# +# +# +# +# Transmission of the polarizer at given wavelength values. +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXpositioner_sts.yaml b/contributed_definitions/nyaml/NXpositioner_sts.yaml new file mode 100644 index 0000000000..5fc0546f75 --- /dev/null +++ b/contributed_definitions/nyaml/NXpositioner_sts.yaml @@ -0,0 +1,552 @@ +category: base +doc: | + A generic positioner such as a motor or piezo-electric transducer. +type: group +NXpositioner_sts(NXobject): + name: + doc: | + symbolic or mnemonic name (one word) + description: + doc: | + description of positioner + value(NX_NUMBER): + unit: NX_ANY + doc: | + best known value of positioner - need [n] as may be scanned + dimensions: + rank: 1 + dim: [[1, n]] + raw_value(NX_NUMBER): + unit: NX_ANY + doc: | + raw value of positioner - need [n] as may be scanned + dimensions: + rank: 1 + dim: [[1, n]] + target_value(NX_NUMBER): + unit: NX_ANY + doc: | + targeted (commanded) value of positioner - need [n] as may be scanned + dimensions: + rank: 1 + dim: [[1, n]] + tolerance(NX_NUMBER): + unit: NX_ANY + doc: | + maximum allowable difference between target_value and value + dimensions: + rank: 1 + dim: [[1, n]] + soft_limit_min(NX_NUMBER): + unit: NX_ANY + doc: | + minimum allowed limit to set value + soft_limit_max(NX_NUMBER): + unit: NX_ANY + doc: | + maximum allowed limit to set value + velocity(NX_NUMBER): + unit: NX_ANY + doc: | + velocity of the positioner (distance moved per unit time) + acceleration_time(NX_NUMBER): + unit: NX_ANY + doc: | + time to ramp the velocity up to full speed + controller_record: + doc: | + Hardware device record, e.g. EPICS process variable, taco/tango ... + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a positioner. + (NXtransformations): + doc: | + 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. + position(NXtransformations): + doc: | + To clarify the frame laboratory frame. The scanning area in x, y, and z position in the + frame. + z_contronller(NX_NUMBER): + doc: | + This controllers task is to continuously adjust the Z position of the stm tip in order + to keep the selected control signal as close as possible to the Set Point. Different control + signals lead to different contronller beahvior. + z_offset(NX_NUMBER): + unit: NX_LENGTH + doc: | + Offset added to the initial averaged position Zaver before starting to swepp. + tip_position_z(NX_NUMBER): + unit: NX_LENGTH + doc: | + Indicate the tip position Z between tip and sample. The tip position can also be varied when + the controller is not running. + controller_name(NX_CHAR): + doc: | + Controller name. This name which will be displayed at places where you can select a + controller. + setpoint(NX_NUMBER): + unit: NX_CURRENT + doc: | + Set Point is the desired value of the control signal. It can be set by editing the number + or using the slider bar. Click the "Set" button above the input field to use the actual + value as Set Point. The slider shows the Set Point as well as the current value. + tip_lift(NX_NUMBER): + unit: NX_LENGTH + doc: | + Lifts the tip by the specified amount when then controller is switched off. This can be + a positive or a negative number, i.e. the tip can also be moved towards the sample. Be + careful with sign and value when using this feature. + switch_off_delay(NX_NUMBER): + unit: NX_TIME + doc: | + Use this parameter for a reproducible position when switching off the Z-controller. + When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues + to run for the specified time and averages the Z position. + z_controller_hold(NX_BOOLEAN): + doc: | + (In bias spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) during + the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters + are disabled. + final_z(NX_NUMBER): + unit: NX_LENGTH + doc: | + The final z-position during the bias spectroscopy scan. The availability of values is + related to the mode of scanning. + + # scan_control(NXcollection): + # doc: | + # To control the tip and various scan operations. + scanfield(NX_NUMBER): + unit: NX_LENGTH + doc: | + Configure the scan frame like x position; y position; width; height. + pixels_line(NX_NUMBER): + unit: NX_COUNT + doc: | + Scan resolution by setting the Lines equal to Pixels. + lines(NX_NUMBER): + unit: NX_ANY + doc: | + Define the image resolution. + speed_forw(NX_NUMBER): + unit: NX_ANY + doc: | + Define the scan forward speed in the forward direction. + speed_backw(NX_NUMBER): + unit: NX_ANY + doc: | + Define the scan backward speed in the forward direction. + piezo_calibration: + doc: | + Piezo calibration module is used to define the X Y Z piezos calibration. + active_calib(NX_CHAR): + doc: | + The name of caliberation type. + calib_N(NX_NUMBER): + + # z_contronller(NXcollection): + # name: + # doc: | + # This controllers task is to continuously adjust the Z position of the stm tip in order to keep the selected control signal as close as possible to the Set Point. Different contro; signals lead to different contronller beahvior. + # z_offset(NX_NUMBER): + # doc: Offset added to the initial averaged position Zaver before starting to swepp. + # unit: NX_LENGTH + # tip_position_z(NX_NUMBER): + # doc: Indicate the tip position Z between tip and sample. The tip position can also be varied when the controller is not running. + # unit: NX_LENGTH + # controller_name: + # doc: Controller name. This name which will be displayed at places where you can select a controller. + # setpoint(NX_NUMBER): + # doc: Set Point is the desired value of the control signal. It can be set by editing the number or using the slider bar. Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. + # unit: NX_CUTTENT + # setpoint_unit: + # doc: The unit of setpoint during the scanning. + p_gain(NX_NUMBER): + unit: NX_UNITLESS + doc: | + The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and :math:`P/T` + (proportional gain/time constant). The formula for the controller in the frequency domain is: + :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. + The integral gain and time constant are related as follows: :math:`I = P/T`. + i_gain(NX_NUMBER): + unit: NX_UNITLESS + doc: | + The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and + P/T (proportional gain/time constant). The formula for the controller in the frequency + domain is: :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. The integral gain and time constant are related + as follows: `:math:I = P/T`. + time_const(NX_NUMBER): + unit: NX_TIME + doc: | + The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and + :math:`P/T` (proportional gain/time constant). The formula for the controller in the frequency + domain is: :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. The integral gain and time constant are related + as follows: :math:`I = P/T`. + + # tip_lift(NX_NUMBER): + # doc: | + # Lifts the tip by the specified amount when then controller is switched off. This + # can be a positive or a negative number, i.e. the tip can also be moved towards the sample. + # Be careful with sign and value when using this feature. + # unit: NX_LENGTH + # switch_off_delay(NX_NUMBER): + # doc: | + # Use this parameter for a reproducible position when switching off the Z-controller. + # When >0 and the Z-controller is switched off, it doesn't switch off immediately but + # continues to run for the specified time and averages the Z position. + # unit: NX_TIME + # z_controller_hold(NX_CHAR): + # doc: | + # (In biase spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) + # during the sweep. It is selected by default. When deselected, Z-offset and Z control time + # parameters are disabled. + scan_contronller(NX_NUMBER): + doc: | + There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order + piezo characteristics to compensate for it. The following equation shows the interpretation + of the 2nd order correction parameter: For the X-piezo: + :math:`Ux = 1/cx · X + cxx · X2`; with units: :math:`[V] = [V/m] · [m] + [V/m2] · [m2]` + where cx is the calibration of the piezo X and cxx is the 2nd order correction. :math:`(V/m^2)` + drift(NX_NUMBER): + unit: NX_ANY + doc: | + There are 2 parameters in X and Y directions. Define the drift speed for all three axes. + When the compensation is on, the piezos will start to move at that speed. + drift_correction_status(NX_CHAR): + doc: | + Use the button to turn on/off the drift compensation. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 83beb3d0c95691e16420919cb753190e06479f7298b3d660ea515fc999f6dd53 +# +# +# +# +# +# A generic positioner such as a motor or piezo-electric transducer. +# +# +# +# symbolic or mnemonic name (one word) +# +# +# +# +# description of positioner +# +# +# +# +# best known value of positioner - need [n] as may be scanned +# +# +# +# +# +# +# +# raw value of positioner - need [n] as may be scanned +# +# +# +# +# +# +# +# targeted (commanded) value of positioner - need [n] as may be scanned +# +# +# +# +# +# +# +# maximum allowable difference between target_value and value +# +# +# +# +# +# +# +# minimum allowed limit to set value +# +# +# +# +# maximum allowed limit to set value +# +# +# +# +# velocity of the positioner (distance moved per unit time) +# +# +# +# +# time to ramp the velocity up to full speed +# +# +# +# +# Hardware device record, e.g. EPICS process variable, taco/tango ... +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a positioner. +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# +# To clarify the frame laboratory frame. The scanning area in x, y, and z position in the +# frame. +# +# +# +# +# This controllers task is to continuously adjust the Z position of the stm tip in order +# to keep the selected control signal as close as possible to the Set Point. Different control +# signals lead to different contronller beahvior. +# +# +# +# +# Offset added to the initial averaged position Zaver before starting to swepp. +# +# +# +# +# Indicate the tip position Z between tip and sample. The tip position can also be varied when +# the controller is not running. +# +# +# +# +# Controller name. This name which will be displayed at places where you can select a +# controller. +# +# +# +# +# Set Point is the desired value of the control signal. It can be set by editing the number +# or using the slider bar. Click the "Set" button above the input field to use the actual +# value as Set Point. The slider shows the Set Point as well as the current value. +# +# +# +# +# Lifts the tip by the specified amount when then controller is switched off. This can be +# a positive or a negative number, i.e. the tip can also be moved towards the sample. Be +# careful with sign and value when using this feature. +# +# +# +# +# Use this parameter for a reproducible position when switching off the Z-controller. +# When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues +# to run for the specified time and averages the Z position. +# +# +# +# +# (In bias spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) during +# the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters +# are disabled. +# +# +# +# +# The final z-position during the bias spectroscopy scan. The availability of values is +# related to the mode of scanning. +# +# +# +# +# +# Configure the scan frame like x position; y position; width; height. +# +# +# +# +# Scan resolution by setting the Lines equal to Pixels. +# +# +# +# +# Define the image resolution. +# +# +# +# +# Define the scan forward speed in the forward direction. +# +# +# +# +# Define the scan backward speed in the forward direction. +# +# +# +# +# Piezo calibration module is used to define the X Y Z piezos calibration. +# +# +# +# +# The name of caliberation type. +# +# +# +# +# +# +# The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and :math:`P/T` +# (proportional gain/time constant). The formula for the controller in the frequency domain is: +# :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. +# The integral gain and time constant are related as follows: :math:`I = P/T`. +# +# +# +# +# The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and +# P/T (proportional gain/time constant). The formula for the controller in the frequency +# domain is: :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. The integral gain and time constant are related +# as follows: `:math:I = P/T`. +# +# +# +# +# The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and +# :math:`P/T` (proportional gain/time constant). The formula for the controller in the frequency +# domain is: :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. The integral gain and time constant are related +# as follows: :math:`I = P/T`. +# +# +# +# +# +# There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order +# piezo characteristics to compensate for it. The following equation shows the interpretation +# of the 2nd order correction parameter: For the X-piezo: +# :math:`Ux = 1/cx · X + cxx · X2`; with units: :math:`[V] = [V/m] · [m] + [V/m2] · [m2]` +# where cx is the calibration of the piezo X and cxx is the 2nd order correction. :math:`(V/m^2)` +# +# +# +# +# There are 2 parameters in X and Y directions. Define the drift speed for all three axes. +# When the compensation is on, the piezos will start to move at that speed. +# +# +# +# +# Use the button to turn on/off the drift compensation. +# +# +# diff --git a/contributed_definitions/nyaml/NXprogram.yaml b/contributed_definitions/nyaml/NXprogram.yaml new file mode 100644 index 0000000000..a0dd2567bd --- /dev/null +++ b/contributed_definitions/nyaml/NXprogram.yaml @@ -0,0 +1,76 @@ +category: base +doc: | + Base class to describe a software tool or library. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXprogram(NXobject): + program: + doc: | + Given name of the program. Program can be a commercial one a script, + or a library or a library component. + \@version: + doc: | + Program version plus build number, or commit hash. + \@url: + doc: | + Description of an ideally ever persistent resource where the source code + of the program or this specific compiled version of the program can be + found so that the program yields repeatably exactly the same numerical + and categorical results. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e508f9d472f579d40e1573a0b3cdde6c70892cc9579735c5e3121cdf075554f8 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Base class to describe a software tool or library. +# +# +# +# Given name of the program. Program can be a commercial one a script, +# or a library or a library component. +# +# +# +# Program version plus build number, or commit hash. +# +# +# +# +# Description of an ideally ever persistent resource where the source code +# of the program or this specific compiled version of the program can be +# found so that the program yields repeatably exactly the same numerical +# and categorical results. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXpulser_apm.yaml b/contributed_definitions/nyaml/NXpulser_apm.yaml new file mode 100644 index 0000000000..0660ad266b --- /dev/null +++ b/contributed_definitions/nyaml/NXpulser_apm.yaml @@ -0,0 +1,281 @@ +category: base +doc: | + Metadata for laser- and/or voltage-pulsing in atom probe microscopy. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_ions: | + Total number of ions collected. +type: group +NXpulser_apm(NXobject): + (NXfabrication): + pulse_mode: + doc: | + How is field evaporation physically triggered. + enumeration: [laser, voltage, laser_and_voltage] + pulse_frequency(NX_FLOAT): + unit: NX_FREQUENCY + doc: | + Frequency with which the high voltage or laser pulser fires. + + # This can change over the course of the experiment, APT HDF defines it therefore as follows: "PulseFrequency : Real array, 2xn (Hz) This is the frequency of the high voltage or laser pulser. first entry : first pulse number where the spacing between this and all subsequent pulses are considered to be at the selected frequency. Each first entry must be strictly increasing in value. The second entry contains the frequency value" as data can be compressed in this case very efficiently we go for with an array of length 1xn_ions + dimensions: + rank: 1 + dim: [[1, n_ions]] + pulse_fraction(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + Fraction of the pulse_voltage that is applied in addition + to the standing_voltage at peak voltage of a pulse. + + If a standing voltage is applied, this gives nominal pulse fraction + (as a function of standing voltage). Otherwise this field should not be + present. + dimensions: + rank: 1 + dim: [[1, n_ions]] + pulsed_voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + In laser pulsing mode the values will be zero so the this field is recommended. + However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. + dimensions: + rank: 1 + dim: [[1, n_ions]] + pulse_number(NX_UINT): + unit: NX_UNITLESS + doc: | + Absolute number of pulses starting from the beginning of the experiment. + dimensions: + rank: 1 + dim: [[1, n_ions]] + standing_voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Direct current voltage between the specimen and the (local electrode) in + the case of local electrode atom probe (LEAP) instrument. + The standing voltage applied to the sample, relative to system ground. + dimensions: + rank: 1 + dim: [[1, n_ions]] + (NXsource): + 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. + name: + doc: | + Given name/alias. + (NXfabrication): + wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + Nominal wavelength of the laser radiation. + power(NX_FLOAT): + unit: NX_POWER + doc: | + Nominal power of the laser source while illuminating the specimen. + + # NEW ISSUE: needs clearer specification/definition + pulse_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + Average energy of the laser at peak of each pulse. + (NXbeam): + doc: | + Details about specific positions along the focused laser beam + which illuminates the (atom probe) specimen. + incidence_vector(NXcollection): + doc: | + Track time-dependent settings over the course of the + measurement how the laser beam in tip space/reconstruction space + laser impinges on the sample, i.e. the mean vector is parallel to + the laser propagation direction. + pinhole_position(NXcollection): + doc: | + Track time-dependent settings over the course of the + measurement where the laser beam exits the + focusing optics. + spot_position(NXcollection): + doc: | + Track time-dependent settings over the course of the + measurement where the laser hits the specimen. + (NXtransformations): + doc: | + Affine transformations which describe the geometry how the + laser focusing optics/pinhole-attached coordinate system is + defined, how it has to be transformed so that it aligns with + the specimen coordinate system. + A right-handed Cartesian coordinate system, the so-called laser space, + should be assumed, whose positive z-axis points + into the direction of the propagating laser beam. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 84fa67d6c1df34589f01c80d3eb014e43f7ba7a6cdfab06afba597d89f3e8377 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Total number of ions collected. +# +# +# +# +# Metadata for laser- and/or voltage-pulsing in atom probe microscopy. +# +# +# +# +# How is field evaporation physically triggered. +# +# +# +# +# +# +# +# +# +# Frequency with which the high voltage or laser pulser fires. +# +# +# +# +# +# +# +# +# Fraction of the pulse_voltage that is applied in addition +# to the standing_voltage at peak voltage of a pulse. +# +# If a standing voltage is applied, this gives nominal pulse fraction +# (as a function of standing voltage). Otherwise this field should not be +# present. +# +# +# +# +# +# +# +# In laser pulsing mode the values will be zero so the this field is recommended. +# However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. +# +# +# +# +# +# +# +# Absolute number of pulses starting from the beginning of the experiment. +# +# +# +# +# +# +# +# Direct current voltage between the specimen and the (local electrode) in +# the case of local electrode atom probe (LEAP) instrument. +# The standing voltage applied to the sample, relative to system ground. +# +# +# +# +# +# +# +# Atom probe microscopes use controlled laser, voltage, +# or a combination of pulsing strategies to trigger the +# excitation and eventual field evaporation/emission of +# an ion during an experiment. +# +# +# +# Given name/alias. +# +# +# +# +# +# Nominal wavelength of the laser radiation. +# +# +# +# +# Nominal power of the laser source while illuminating the specimen. +# +# +# +# +# +# Average energy of the laser at peak of each pulse. +# +# +# +# +# Details about specific positions along the focused laser beam +# which illuminates the (atom probe) specimen. +# +# +# +# Track time-dependent settings over the course of the +# measurement how the laser beam in tip space/reconstruction space +# laser impinges on the sample, i.e. the mean vector is parallel to +# the laser propagation direction. +# +# +# +# +# Track time-dependent settings over the course of the +# measurement where the laser beam exits the +# focusing optics. +# +# +# +# +# Track time-dependent settings over the course of the +# measurement where the laser hits the specimen. +# +# +# +# +# +# Affine transformations which describe the geometry how the +# laser focusing optics/pinhole-attached coordinate system is +# defined, how it has to be transformed so that it aligns with +# the specimen coordinate system. +# A right-handed Cartesian coordinate system, the so-called laser space, +# should be assumed, whose positive z-axis points +# into the direction of the propagating laser beam. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXpump.yaml b/contributed_definitions/nyaml/NXpump.yaml new file mode 100644 index 0000000000..95a28d0ddc --- /dev/null +++ b/contributed_definitions/nyaml/NXpump.yaml @@ -0,0 +1,60 @@ +category: base +doc: | + Device to reduce an atmosphere to a controlled remaining pressure level. +type: group +NXpump(NXobject): + (NXfabrication): + design: + doc: | + Principle type of the pump. + enumeration: [membrane, rotary_vane, roots, turbo_molecular] + + # NEW ISSUE: take community input and work further to store what is relevant to report about pumps + # NEW ISSUE: see e.g. https://www.youtube.com/watch?v=Nsr_AdTiIIA for a discussion about + # NEW ISSUE: the role, pros and cons of pump used for atom probe microscopy + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 4a8252499c1361c758a51abb01fb92bead035ff00ce3c67966c7eb63ea4837df +# +# +# +# +# +# Device to reduce an atmosphere to a controlled remaining pressure level. +# +# +# +# +# Principle type of the pump. +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXquadric.yaml b/contributed_definitions/nyaml/NXquadric.yaml new file mode 100644 index 0000000000..f220b55003 --- /dev/null +++ b/contributed_definitions/nyaml/NXquadric.yaml @@ -0,0 +1,117 @@ +category: base +doc: | + definition of a quadric surface. +type: group +NXquadric(NXobject): + parameters(NX_NUMBER): + unit: NX_PER_LENGTH + doc: | + Ten real values of the matrix that defines the quadric surface + in projective space. Ordered Q11, Q12, Q13, Q22, Q23, Q33, P1, + P2, P3, R. Takes a units attribute of dimension reciprocal + length. R is scalar. P has dimension reciprocal length, and the + given units. Q has dimension reciprocal length squared, and + units the square of those given. + dimensions: + dim: [[1, 10]] + surface_type: + exists: ['min', '0', 'max', '1'] + doc: | + An optional description of the form of the quadric surface: + enumeration: [ELLIPSOID, ELLIPTIC_PARABOLOID, HYPERBOLIC_PARABOLOID, ELLIPTIC_HYPERBOLOID_OF_1_SHEET, ELLIPTIC_HYPERBOLOID_OF_2_SHEETS, ELLIPTIC_CONE, ELLIPTIC_CYLINDER, HYPERBOLIC_CYLINDER, PARABOLIC_CYLINDER, SPHEROID, SPHERE, PARABOLOID, HYPERBOLOID_1_SHEET, HYPERBOLOID_2_SHEET, CONE, CYLINDER, PLANE, IMAGINARY, UNKNOWN] + depends_on(NX_CHAR): + exists: ['min', '0', 'max', '1'] + doc: | + Path to an :ref:`NXtransformations` that defining the axis on + which the orientation of the surface depends. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 267b94fd8c62dec6dbb2c835d40cda184ec544f98b054c545c067c0206a6680f +# +# +# +# +# definition of a quadric surface. +# +# +# Ten real values of the matrix that defines the quadric surface +# in projective space. Ordered Q11, Q12, Q13, Q22, Q23, Q33, P1, +# P2, P3, R. Takes a units attribute of dimension reciprocal +# length. R is scalar. P has dimension reciprocal length, and the +# given units. Q has dimension reciprocal length squared, and +# units the square of those given. +# +# +# +# +# +# +# +# An optional description of the form of the quadric surface: +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Path to an :ref:`NXtransformations` that defining the axis on +# which the orientation of the surface depends. +# +# +# diff --git a/contributed_definitions/nyaml/NXquadrupole_magnet.yaml b/contributed_definitions/nyaml/NXquadrupole_magnet.yaml new file mode 100644 index 0000000000..62bec22844 --- /dev/null +++ b/contributed_definitions/nyaml/NXquadrupole_magnet.yaml @@ -0,0 +1,84 @@ +category: base +doc: | + definition for a quadrupole magnet. +type: group +NXquadrupole_magnet(NXobject): + description(NX_CHAR): + doc: | + extended description of the magnet. + beamline_distance(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + doc: | + define position of beamline element relative to production target + set_current(NX_FLOAT): + unit: NX_CURRENT + exists: ['min', '0', 'max', '1'] + doc: | + current set on supply. + read_current(NXlog): + exists: ['min', '0', 'max', '1'] + doc: | + current read from supply. + value: + unit: NX_CURRENT + read_voltage(NXlog): + exists: ['min', '0', 'max', '1'] + doc: | + voltage read from supply. + value: + unit: NX_VOLTAGE + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 87dac0535ae7038f0b632b817a8a67683a20a6257cea6283e449a7b8bd0f3587 +# +# +# +# +# definition for a quadrupole magnet. +# +# extended description of the magnet. +# +# +# define position of beamline element relative to production target +# +# +# current set on supply. +# +# +# current read from supply. +# +# +# +# voltage read from supply. +# +# +# diff --git a/contributed_definitions/nyaml/NXreflectron.yaml b/contributed_definitions/nyaml/NXreflectron.yaml new file mode 100644 index 0000000000..85174758ce --- /dev/null +++ b/contributed_definitions/nyaml/NXreflectron.yaml @@ -0,0 +1,87 @@ +category: base +doc: | + Device for reducing flight time differences of ions in ToF experiments. + For atom probe the reflectron can be considered an energy_compensation + device, which can e.g. be realized technically as via a Poschenrieder lens + (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). +type: group +NXreflectron(NXobject): + name: + doc: | + Given name/alias. + (NXfabrication): + description: + doc: | + Free-text field to specify further details about the reflectron. + The field can be used to inform e. g. if the reflectron is flat or curved. + + # IFES_APT_TC "ReflectronVoltage: Real, 1xn array (V) Must be present if ReflectronInfo is not “None” The maximum voltage applied to the reflectron, relative to system ground." + (NXtransformations): + doc: | + Affine transformation(s) which detail where the reflectron + is located relative to e.g. the origin of the specimen space + reference coordinate system. + This group can also be used for specifying how the reflectron + is rotated relative to the specimen axis. + The purpose of these more detailed instrument descriptions + is to support the creation of a digital twin of the instrument + for computational science. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 6f932a14554bc463bc83d9d2da179443e89636ee2de15fce04bcf8c8950669ee +# +# +# +# +# +# Device for reducing flight time differences of ions in ToF experiments. +# For atom probe the reflectron can be considered an energy_compensation +# device, which can e.g. be realized technically as via a Poschenrieder lens +# (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). +# +# +# +# Given name/alias. +# +# +# +# +# +# Free-text field to specify further details about the reflectron. +# The field can be used to inform e. g. if the reflectron is flat or curved. +# +# +# +# +# +# Affine transformation(s) which detail where the reflectron +# is located relative to e.g. the origin of the specimen space +# reference coordinate system. +# This group can also be used for specifying how the reflectron +# is rotated relative to the specimen axis. +# The purpose of these more detailed instrument descriptions +# is to support the creation of a digital twin of the instrument +# for computational science. +# +# +# diff --git a/contributed_definitions/nyaml/NXregion.yaml b/contributed_definitions/nyaml/NXregion.yaml new file mode 100644 index 0000000000..b074a5f157 --- /dev/null +++ b/contributed_definitions/nyaml/NXregion.yaml @@ -0,0 +1,340 @@ +category: base +doc: | + Geometry and logical description of a region of data in a parent group. When used, it could be a child group to, say, :ref:`NXdetector`. + + This can be used to describe a subset of data used to create downsampled data or to derive + some data from that subset. + + Note, the fields for the rectangular region specifiers follow HDF5’s dataspace hyperslab parameters + (see https://portal.hdfgroup.org/display/HDF5/H5S_SELECT_HYPERSLAB). Note when **block** :math:`= 1`, + then **stride** :math:`\equiv` **step** in Python slicing. + + For example, a ROI sum of an area starting at index of [20,50] and shape [220,120] in image data:: + + detector:NXdetector/ + data[60,256,512] + region:NXregion/ + @region_type = "rectangular" + parent = "data" + start = [20,50] + count = [220,120] + statistics:NXdata/ + @signal = "sum" + sum[60] + + the ``sum`` dataset contains the summed areas in each frame. + Another example, a hyperspectral image downsampled 16-fold in energy:: + + detector:NXdetector/ + data[128,128,4096] + region:NXregion/ + @region_type = "rectangular" + parent = "data" + start = [2] + count = [20] + stride = [32] + block = [16] + downsampled:NXdata/ + @signal = "maximum" + @auxiliary_signals = "copy" + maximum[128,128,20] + copy[128,128,320] + + the ``copy`` dataset selects 20 16-channel blocks that start 32 channels apart, + the ``maximum`` dataset will show maximum values in each 16-channel block + in every spectra. +symbols: + doc: | + These symbols will denote how the shape of the parent group's data field, + + .. math:: (D_0, ..., D_{\mathbf{O}-1}, d_0, ..., d_{\mathbf{R}-1}) + + could be split into a left set of **O** outer dimensions, :math:`\boldsymbol{D}`, + and a right set of **R** region dimensions, :math:`\boldsymbol{d}`, + where the data field has rank **O** + **R**. Note **O** :math:`>= 0`. + O: | + Outer rank + R: | + Region rank +type: group +NXregion(NXobject): + \@region_type: + exists: optional + doc: | + This is ``rectangular`` to describe the region as a hyper-rectangle in + the index space of its parent group's data field. + enumeration: [rectangular] + parent: + doc: | + The name of data field in the parent group or the path of a data field relative + to the parent group (so it could be a field in a subgroup of the parent group) + parent_mask: + doc: | + The name of an optional mask field in the parent group with rank :math:`\boldsymbol{R}` and + dimensions :math:`\boldsymbol{d}`. For example, this could be ``pixel_mask`` of an + :ref:`NXdetector`. + start(NX_NUMBER): + exists: recommended + doc: | + The starting position for region in detector data field array. + This is recommended as it also defines the region rank. + If omitted then defined as an array of zeros. + dimensions: + rank: 1 + dim: [[1, R]] + count(NX_INT): + exists: recommended + doc: | + The number of blocks or items in the hyperslab selection. + If omitted then defined as an array of dimensions that take into account + the other hyperslab selection fields to span the parent data field's shape. + dimensions: + rank: 1 + dim: [[1, R]] + stride(NX_INT): + doc: | + An optional field to define striding used to downsample data. + If omitted then defined as an array of ones. + dimensions: + rank: 1 + dim: [[1, R]] + block(NX_INT): + doc: | + An optional field to define the block size used to copy or downsample data. In the + :math:`i`-th dimension, if :math:`\mathbf{block}[i] < \mathbf{stride}[i]` + then the downsampling blocks have gaps between them; when ``block`` matches ``stride`` + then the blocks are contiguous; otherwise the blocks overlap. + If omitted then defined as an array of ones. + dimensions: + rank: 1 + dim: [[1, R]] + scale(NX_NUMBER): + doc: | + An optional field to define a divisor for scaling of reduced data. For example, in a + downsampled sum, it can reduce the maximum values to fit in the domain of the result + data type. In an image that is downsampled by summing 2x2 blocks, using + :math:`\mathrm{scale}=4` allows the result to fit in the same integer type dataset as + the parent dataset. + If omitted then no scaling occurs. + dimensions: + rank: 1 + dim: [[1, R]] + downsampled(NXdata): + doc: | + An optional group containing data copied/downsampled from parent group’s data. Its dataset name + must reflect how the downsampling is done over each block. So it could be a reduction operation + such as sum, minimum, maximum, mean, mode, median, etc. If downsampling is merely copying each + block then use "copy" as the name. Where more than one downsample dataset is written + (specified with ``@signal``) then add ``@auxiliary_signals`` listing the others. In the copy case, + the field should have a shape of :math:`(D_0, ..., D_{\mathbf{O}-1}, \mathbf{block}[0] * \mathbf{count}[0], ..., \mathbf{block}[\mathbf{R}-1] * \mathbf{count}[\mathbf{R}-1])`, + otherwise the expected shape is :math:`(D_0, ..., D_{\mathbf{O}-1}, \mathbf{count}[0], ..., \mathbf{count}[\mathbf{R}-1])`. + + The following figure shows how blocks are used in downsampling: + + .. figure:: region/NXregion-example.png + :width: 60% + + A selection with :math:`\mathbf{start}=2, \mathbf{count}=4, \mathbf{stride}=3, \mathbf{block}=2` from + a dataset with shape [13] will result in the ``reduce`` dataset of shape [4] and a ``copy`` dataset of shape [8]. + statistics(NXdata): + doc: | + An optional group containing any statistics derived from the region in parent group’s data + such as sum, minimum, maximum, mean, mode, median, rms, variance, etc. Where more than one + statistical dataset is written (specified with ``@signal``) then add ``@auxiliary_signals`` + listing the others. All data fields should have shapes of :math:`\boldsymbol{D}`. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 8426e78db8c7bfc828d27cea0e29c7cc255b78f1ca7e809672cb6b0174497dd0 +# +# +# +# +# +# +# These symbols will denote how the shape of the parent group's data field, +# +# .. math:: (D_0, ..., D_{\mathbf{O}-1}, d_0, ..., d_{\mathbf{R}-1}) +# +# could be split into a left set of **O** outer dimensions, :math:`\boldsymbol{D}`, +# and a right set of **R** region dimensions, :math:`\boldsymbol{d}`, +# where the data field has rank **O** + **R**. Note **O** :math:`>= 0`. +# +# Outer rank +# Region rank +# +# +# Geometry and logical description of a region of data in a parent group. When used, it could be a child group to, say, :ref:`NXdetector`. +# +# This can be used to describe a subset of data used to create downsampled data or to derive +# some data from that subset. +# +# Note, the fields for the rectangular region specifiers follow HDF5’s dataspace hyperslab parameters +# (see https://portal.hdfgroup.org/display/HDF5/H5S_SELECT_HYPERSLAB). Note when **block** :math:`= 1`, +# then **stride** :math:`\equiv` **step** in Python slicing. +# +# For example, a ROI sum of an area starting at index of [20,50] and shape [220,120] in image data:: +# +# detector:NXdetector/ +# data[60,256,512] +# region:NXregion/ +# @region_type = "rectangular" +# parent = "data" +# start = [20,50] +# count = [220,120] +# statistics:NXdata/ +# @signal = "sum" +# sum[60] +# +# the ``sum`` dataset contains the summed areas in each frame. +# Another example, a hyperspectral image downsampled 16-fold in energy:: +# +# detector:NXdetector/ +# data[128,128,4096] +# region:NXregion/ +# @region_type = "rectangular" +# parent = "data" +# start = [2] +# count = [20] +# stride = [32] +# block = [16] +# downsampled:NXdata/ +# @signal = "maximum" +# @auxiliary_signals = "copy" +# maximum[128,128,20] +# copy[128,128,320] +# +# the ``copy`` dataset selects 20 16-channel blocks that start 32 channels apart, +# the ``maximum`` dataset will show maximum values in each 16-channel block +# in every spectra. +# +# +# +# This is ``rectangular`` to describe the region as a hyper-rectangle in +# the index space of its parent group's data field. +# +# +# +# +# +# +# +# The name of data field in the parent group or the path of a data field relative +# to the parent group (so it could be a field in a subgroup of the parent group) +# +# +# +# +# The name of an optional mask field in the parent group with rank :math:`\boldsymbol{R}` and +# dimensions :math:`\boldsymbol{d}`. For example, this could be ``pixel_mask`` of an +# :ref:`NXdetector`. +# +# +# +# +# The starting position for region in detector data field array. +# This is recommended as it also defines the region rank. +# If omitted then defined as an array of zeros. +# +# +# +# +# +# +# +# The number of blocks or items in the hyperslab selection. +# If omitted then defined as an array of dimensions that take into account +# the other hyperslab selection fields to span the parent data field's shape. +# +# +# +# +# +# +# +# An optional field to define striding used to downsample data. +# If omitted then defined as an array of ones. +# +# +# +# +# +# +# +# An optional field to define the block size used to copy or downsample data. In the +# :math:`i`-th dimension, if :math:`\mathbf{block}[i] < \mathbf{stride}[i]` +# then the downsampling blocks have gaps between them; when ``block`` matches ``stride`` +# then the blocks are contiguous; otherwise the blocks overlap. +# If omitted then defined as an array of ones. +# +# +# +# +# +# +# +# An optional field to define a divisor for scaling of reduced data. For example, in a +# downsampled sum, it can reduce the maximum values to fit in the domain of the result +# data type. In an image that is downsampled by summing 2x2 blocks, using +# :math:`\mathrm{scale}=4` allows the result to fit in the same integer type dataset as +# the parent dataset. +# If omitted then no scaling occurs. +# +# +# +# +# +# +# +# An optional group containing data copied/downsampled from parent group’s data. Its dataset name +# must reflect how the downsampling is done over each block. So it could be a reduction operation +# such as sum, minimum, maximum, mean, mode, median, etc. If downsampling is merely copying each +# block then use "copy" as the name. Where more than one downsample dataset is written +# (specified with ``@signal``) then add ``@auxiliary_signals`` listing the others. In the copy case, +# the field should have a shape of :math:`(D_0, ..., D_{\mathbf{O}-1}, \mathbf{block}[0] * \mathbf{count}[0], ..., \mathbf{block}[\mathbf{R}-1] * \mathbf{count}[\mathbf{R}-1])`, +# otherwise the expected shape is :math:`(D_0, ..., D_{\mathbf{O}-1}, \mathbf{count}[0], ..., \mathbf{count}[\mathbf{R}-1])`. +# +# The following figure shows how blocks are used in downsampling: +# +# .. figure:: region/NXregion-example.png +# :width: 60% +# +# A selection with :math:`\mathbf{start}=2, \mathbf{count}=4, \mathbf{stride}=3, \mathbf{block}=2` from +# a dataset with shape [13] will result in the ``reduce`` dataset of shape [4] and a ``copy`` dataset of shape [8]. +# +# +# +# +# +# An optional group containing any statistics derived from the region in parent group’s data +# such as sum, minimum, maximum, mean, mode, median, rms, variance, etc. Where more than one +# statistical dataset is written (specified with ``@signal``) then add ``@auxiliary_signals`` +# listing the others. All data fields should have shapes of :math:`\boldsymbol{D}`. +# +# +# diff --git a/contributed_definitions/nyaml/NXregistration.yaml b/contributed_definitions/nyaml/NXregistration.yaml new file mode 100644 index 0000000000..a2c1e12cc5 --- /dev/null +++ b/contributed_definitions/nyaml/NXregistration.yaml @@ -0,0 +1,80 @@ +category: base +doc: | + Describes image registration procedures. +type: group +NXregistration(NXobject): + applied(NX_BOOLEAN): + doc: | + Has the registration been applied? + last_process(NX_CHAR): + doc: | + Indicates the name of the last operation applied in the NXprocess sequence. + depends_on(NX_CHAR): + doc: | + Specifies the position by pointing to the last transformation in the + transformation chain in the NXtransformations group. + (NXtransformations): + doc: | + To describe the operations of image registration (combinations of rigid + translations and rotations) + description(NX_CHAR): + doc: | + Description of the procedures employed. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# cc7ade75e51e97bb8a6cb9c2f6b233cca38c45fb8ebcead76a3014a6653d731a +# +# +# +# +# +# Describes image registration procedures. +# +# +# +# Has the registration been applied? +# +# +# +# +# Indicates the name of the last operation applied in the NXprocess sequence. +# +# +# +# +# Specifies the position by pointing to the last transformation in the +# transformation chain in the NXtransformations group. +# +# +# +# +# To describe the operations of image registration (combinations of rigid +# translations and rotations) +# +# +# +# +# Description of the procedures employed. +# +# +# diff --git a/contributed_definitions/nyaml/NXrotation_set.yaml b/contributed_definitions/nyaml/NXrotation_set.yaml new file mode 100644 index 0000000000..2106c935ab --- /dev/null +++ b/contributed_definitions/nyaml/NXrotation_set.yaml @@ -0,0 +1,461 @@ +category: base +doc: | + Base class to detail a set of rotations, orientations, and disorientations. + + For getting a more detailed insight into the discussion of the + parameterized description of orientations in materials science see: + + * `H.-J. Bunge `_ + * `T. B. Britton et al. `_ + * `D. Rowenhorst et al. `_ + * `A. Morawiec `_ + + Once orientations are defined one can continue to characterize the + misorientation and specifically the disorientation which describes the + rotation that is required to register the lattices of two oriented objects + (like crystal lattice) into a crystallographic equivalent orientation: + + * `R. Bonnet `_ + + Based on the idea of this NXorientation_set one could equally formulate + an NXdisorientation_set. + +# This class stores a set of specifically parameterized NXtransformations which describe +# how each object is oriented/rotated with respect to a reference coordinate system. +# we should offer here support for d==2, d==3 +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + c: | + The cardinality of the set, i.e. the number of value tuples. +type: group +NXrotation_set(NXobject): + depends_on: + doc: | + Reference to an instance of NXem_conventions which contextualizes + how the here reported parameterized quantities can be interpreted. + + # 2D rotations are a special type of 3D rotations and thus treated in 3D + # just how to rotate the object into the reference frame defined by depends_on + crystal_symmetry: + doc: | + Point group which defines the symmetry of the crystal. + This has to be at least a single string. + In the case that misorientation or disorientation fields are used + and the two crystal sets resolve for phases with a different + crystal symmetry, this field has to encode two string. + In this case the first string is for phase A the second one for phase B. + An example of this most complex case is the description of the + disorientation between crystals adjoining a hetero-phase boundary. + + # how to encode the above (2,) string array or single string constraint + sample_symmetry: + doc: | + Point group which defines an assumed symmetry imprinted upon processing + the material/sample which could give rise to or may justify to use a + simplified description of rotations, orientations, misorientations, + and disorientations via numerical procedures known as symmetrization. + + The traditionally used symmetrization operations within the texture + community in Materials Science, though, are thanks to methodology and + software improvements no longer strictly needed. Therefore, users are + encouraged to set the sample_symmetry to 1 (triclinic) and thus assume + there is no implied additional processing symmetry imprinted. + + In practice one often faces situations where indeed these assumed + symmetries are anyway not fully observed and thus an accepting of + eventual inaccuracies just for the sake of reporting a simplified + symmetrized description can be avoided. + rotation_quaternion(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + The set of rotations expressed in quaternion representation. The assumed + crystal and sample symmetry point group is 1, triclinic. Rotations which + should be interpreted as antipodal are not marked as such. + dimensions: + rank: 2 + dim: [[1, c], [2, 4]] + rotation_euler(NX_FLOAT): + unit: NX_ANGLE + doc: | + The set of rotations expressed in Euler angle representation following + the same applied symmetries as explained for rotation_quaternion. + To interpret Euler angles correctly it is necessary to inspect the + conventions behind depends_on to resolve which of the many Euler-angle + conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] + + # rotation_rodrigues(NX_FLOAT): + # rotation_homochoric(NX_FLOAT): + # rotation_axis_angle(NX_FLOAT): + + # orientation how to rotate the crystal into sample and vice versa obeying crystal and sample symmetry + is_antipodal(NX_BOOLEAN): + doc: | + True for all those values which are considered antipodal, + false for those which are not considered antipodal. + dimensions: + rank: 1 + dim: [[1, c]] + orientation_quaternion(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + The set of orientations expressed in quaternion representation and + obeying symmetry for equivalent cases as detailed in crystal_symmetry + and sample_symmetry. The supplementary field is_antipodal can be used + to mark orientations which are antipodal. + dimensions: + rank: 2 + dim: [[1, c], [2, 4]] + orientation_euler(NX_FLOAT): + unit: NX_ANGLE + doc: | + The set of orientations expressed in Euler angle representation following + the same assumptions like for orientation_quaternion. + To interpret Euler angles correctly it is necessary to inspect the + conventions behind depends_on to resolve which of the many Euler-angle + conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] + orientation_busing_levy(NX_FLOAT): + unit: NX_ANGLE + doc: | + This will follow the Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + dimensions: + rank: 2 + dim: [[1, 3], [2, 3]] + ub_matrix_busing_levy(NX_FLOAT): + doc: | + UB matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is + the multiplication of the orientation_matrix, given above, + with the :math:`B` matrix which + can be derived from the lattice constants. + dimensions: + rank: 2 + dim: [[1, 3], [2, 3]] + + # orientation_rodrigues(NX_FLOAT): + # orientation_homochoric(NX_FLOAT): + # orientation_axis_angle(NX_FLOAT): + + # misorientation between two orientations, ignoring if the angular argument + # is smallest. + misorientation_quaternion(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + The set of misorientations expressed in quaternion representation and + obeying symmetry operations for equivalent misorientations + as defined by crystal_symmetry and sample_symmetry. + dimensions: + rank: 2 + dim: [[1, c], [2, 4]] + misorientation_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Misorientation angular argument (eventually signed) following the same + symmetry assumptions as expressed for the field misorientation_quaternion. + dimensions: + rank: 1 + dim: [[1, c]] + misorientation_axis(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + Misorientation axis (normalized) and signed following the same + symmetry assumptions as expressed for the field misorientation_angle. + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] + + # disorientation, misorientation with smallest angular argument inside + # fundamental zone of SO3 for given crystal and sample symmetry + disorientation_quaternion(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + The set of disorientation expressed in quaternion representation and + obeying symmetry operations for equivalent misorientations + as defined by crystal_symmetry and sample_symmetry. + disorientation_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Disorientation angular argument (should not be signed, see + `D. Rowenhorst et al. `_) + following the same symmetry assumptions as expressed for the field + disorientation_quaternion. + dimensions: + rank: 1 + dim: [[1, c]] + disorientation_axis(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + Disorientation axis (normalized) following the same symmetry assumptions + as expressed for the field disorientation_quaternion. + dimensions: + rank: 2 + dim: [[1, c], [2, 3]] + + # e.g. in this way one could easily, efficiently, store and map familiar habits of microscopists + # to store e.g. orientations of measurement points or of grains via a (c := Ngrains, n_p := 3) + # matrix of Bunge-Euler angles, or of (c := Ngrains, n_p := 4) matrix of quaternions. + + # the benefit of such a representation is that with a known NXorientation_set base class one can implement a common parameterization transformation library (of which several already exist) in the microstructure modelling communities so that a program can read the information in the (NXorientation_set) instance and automatically transform/compute between different parameterizations. Super relevant for interoperability e.g. in SEM/EBSD, where this was a long standing issue and right now the most frequently accepted consensus is to report either Bunge-Euler angles or quaternions and then use existent transformation libraries (as implemented by e.g. Marc de Graeff for SEM/EBSD and used by many but not yet the majority of people in the computational materials modelling community within crystal plasticity, crystal growth modeling, DREAM.3D) + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 39983e83f102efd5c6004455b450a87d7fde97e4c7a2ed00d9b68eae8b0a92d6 +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# The cardinality of the set, i.e. the number of value tuples. +# +# +# +# +# Base class to detail a set of rotations, orientations, and disorientations. +# +# For getting a more detailed insight into the discussion of the +# parameterized description of orientations in materials science see: +# +# * `H.-J. Bunge <https://doi.org/10.1016/C2013-0-11769-2>`_ +# * `T. B. Britton et al. <https://doi.org/10.1016/j.matchar.2016.04.008>`_ +# * `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_ +# * `A. Morawiec <https://doi.org/10.1007/978-3-662-09156-2>`_ +# +# Once orientations are defined one can continue to characterize the +# misorientation and specifically the disorientation which describes the +# rotation that is required to register the lattices of two oriented objects +# (like crystal lattice) into a crystallographic equivalent orientation: +# +# * `R. Bonnet <https://doi.org/10.1107/S0567739480000186>`_ +# +# Based on the idea of this NXorientation_set one could equally formulate +# an NXdisorientation_set. +# +# +# +# Reference to an instance of NXem_conventions which contextualizes +# how the here reported parameterized quantities can be interpreted. +# +# +# +# +# +# Point group which defines the symmetry of the crystal. +# This has to be at least a single string. +# In the case that misorientation or disorientation fields are used +# and the two crystal sets resolve for phases with a different +# crystal symmetry, this field has to encode two string. +# In this case the first string is for phase A the second one for phase B. +# An example of this most complex case is the description of the +# disorientation between crystals adjoining a hetero-phase boundary. +# +# +# +# +# +# Point group which defines an assumed symmetry imprinted upon processing +# the material/sample which could give rise to or may justify to use a +# simplified description of rotations, orientations, misorientations, +# and disorientations via numerical procedures known as symmetrization. +# +# The traditionally used symmetrization operations within the texture +# community in Materials Science, though, are thanks to methodology and +# software improvements no longer strictly needed. Therefore, users are +# encouraged to set the sample_symmetry to 1 (triclinic) and thus assume +# there is no implied additional processing symmetry imprinted. +# +# In practice one often faces situations where indeed these assumed +# symmetries are anyway not fully observed and thus an accepting of +# eventual inaccuracies just for the sake of reporting a simplified +# symmetrized description can be avoided. +# +# +# +# +# The set of rotations expressed in quaternion representation. The assumed +# crystal and sample symmetry point group is 1, triclinic. Rotations which +# should be interpreted as antipodal are not marked as such. +# +# +# +# +# +# +# +# +# The set of rotations expressed in Euler angle representation following +# the same applied symmetries as explained for rotation_quaternion. +# To interpret Euler angles correctly it is necessary to inspect the +# conventions behind depends_on to resolve which of the many Euler-angle +# conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. +# +# +# +# +# +# +# +# +# +# +# True for all those values which are considered antipodal, +# false for those which are not considered antipodal. +# +# +# +# +# +# +# +# The set of orientations expressed in quaternion representation and +# obeying symmetry for equivalent cases as detailed in crystal_symmetry +# and sample_symmetry. The supplementary field is_antipodal can be used +# to mark orientations which are antipodal. +# +# +# +# +# +# +# +# +# The set of orientations expressed in Euler angle representation following +# the same assumptions like for orientation_quaternion. +# To interpret Euler angles correctly it is necessary to inspect the +# conventions behind depends_on to resolve which of the many Euler-angle +# conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. +# +# +# +# +# +# +# +# +# This will follow the Busing-Levy convention: +# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 +# +# +# +# +# +# +# +# +# UB matrix of single crystal sample using Busing-Levy convention: +# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is +# the multiplication of the orientation_matrix, given above, +# with the :math:`B` matrix which +# can be derived from the lattice constants. +# +# +# +# +# +# +# +# +# +# +# The set of misorientations expressed in quaternion representation and +# obeying symmetry operations for equivalent misorientations +# as defined by crystal_symmetry and sample_symmetry. +# +# +# +# +# +# +# +# +# Misorientation angular argument (eventually signed) following the same +# symmetry assumptions as expressed for the field misorientation_quaternion. +# +# +# +# +# +# +# +# Misorientation axis (normalized) and signed following the same +# symmetry assumptions as expressed for the field misorientation_angle. +# +# +# +# +# +# +# +# +# +# The set of disorientation expressed in quaternion representation and +# obeying symmetry operations for equivalent misorientations +# as defined by crystal_symmetry and sample_symmetry. +# +# +# +# +# Disorientation angular argument (should not be signed, see +# `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_) +# following the same symmetry assumptions as expressed for the field +# disorientation_quaternion. +# +# +# +# +# +# +# +# Disorientation axis (normalized) following the same symmetry assumptions +# as expressed for the field disorientation_quaternion. +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXsample_component_set.yaml b/contributed_definitions/nyaml/NXsample_component_set.yaml new file mode 100644 index 0000000000..2567b25d49 --- /dev/null +++ b/contributed_definitions/nyaml/NXsample_component_set.yaml @@ -0,0 +1,123 @@ +category: base +doc: | + Set of sample components and their configuration. + + The idea here is to have a united place for all materials descriptors that are not + part of the individual sample components, but rather their configuration. +symbols: + n_comp: | + number of components +type: group +NXsample_component_set(NXobject): + \@components: + doc: | + Array of strings referring to the names of the NXsample_components. + The order of these components serves as an index (starting at 1). + concentration(NX_FLOAT): + unit: NX_ANY + doc: | + Concentration of each component + dimensions: + rank: 1 + dim: [[1, n_comp]] + volume_fraction(NX_FLOAT): + unit: NX_ANY + doc: | + Volume fraction of each component + dimensions: + rank: 1 + dim: [[1, n_comp]] + scattering_length_density(NX_FLOAT): + unit: NX_ANY + doc: | + Scattering length density of each component + dimensions: + rank: 1 + dim: [[1, n_comp]] + (NXsample_component): + doc: | + Each component set can contain multiple components. + (NXsample_component_set): + doc: | + For description of a sub-component set. Can contain multiple components itself. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e4d79347fce002e76308abff05f0abadc367858578fa4b9429ebff02d069f395 +# +# +# +# +# +# +# +# number of components +# +# +# +# +# Set of sample components and their configuration. +# +# The idea here is to have a united place for all materials descriptors that are not +# part of the individual sample components, but rather their configuration. +# +# +# +# Array of strings referring to the names of the NXsample_components. +# The order of these components serves as an index (starting at 1). +# +# +# +# +# Concentration of each component +# +# +# +# +# +# +# +# Volume fraction of each component +# +# +# +# +# +# +# +# Scattering length density of each component +# +# +# +# +# +# +# +# Each component set can contain multiple components. +# +# +# +# +# For description of a sub-component set. Can contain multiple components itself. +# +# +# diff --git a/contributed_definitions/nyaml/NXsample_history.yaml b/contributed_definitions/nyaml/NXsample_history.yaml new file mode 100644 index 0000000000..779dfd02aa --- /dev/null +++ b/contributed_definitions/nyaml/NXsample_history.yaml @@ -0,0 +1,108 @@ +category: base +doc: | + A set of activities that occurred to the sample prior/during experiment. + + Ideally, a full report of the previous operations (or links to a chain of operations). + Alternatively, notes allow for additional descriptors in any format. +type: group +NXsample_history(NXobject): + (NXactivity): + doc: | + Any activity that was performed on the sample prior or during the experiment. In + the future, if there is base class inheritance, this can describe any activity, + including processes and measurements. + + # For now, one workaround would be to have NXactivity as a application definition with a subentry. + # subentry(NXsuxbentry): + # doc: | + # Any activity that was performed on the sample prior or during the experiment. + # definition: ["NXactivity"] + (NXphysical_process): + doc: | + Any physical process that was performed on the sample prior or during the + experiment. + (NXchemical_process): + doc: | + Any chemical process that was performed on the sample prior or during the + experiment. + + # There should be more activities here, like measurement. + notes(NXnote): + doc: | + A descriptor to keep track of the treatment of the sample before or during the + experiment (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + This should only be used in case that there is no rigorous description + using the base classes above. This field can also be used to pull in any activities + that are not well described by an existing base class definition. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# bbf87f9c949f2f8af78e20e6f7b447ef3c970fa8d5c142863c3416a5826c4893 +# +# +# +# +# +# A set of activities that occurred to the sample prior/during experiment. +# +# Ideally, a full report of the previous operations (or links to a chain of operations). +# Alternatively, notes allow for additional descriptors in any format. +# +# +# +# Any activity that was performed on the sample prior or during the experiment. In +# the future, if there is base class inheritance, this can describe any activity, +# including processes and measurements. +# +# +# +# +# +# Any physical process that was performed on the sample prior or during the +# experiment. +# +# +# +# +# Any chemical process that was performed on the sample prior or during the +# experiment. +# +# +# +# +# +# A descriptor to keep track of the treatment of the sample before or during the +# experiment (NXnote allows to add pictures, audio, movies). Alternatively, a +# reference to the location or a unique identifier or other metadata file. In the +# case these are not available, free-text description. +# This should only be used in case that there is no rigorous description +# using the base classes above. This field can also be used to pull in any activities +# that are not well described by an existing base class definition. +# +# +# diff --git a/contributed_definitions/nyaml/NXscanbox_em.yaml b/contributed_definitions/nyaml/NXscanbox_em.yaml new file mode 100644 index 0000000000..000477d7cc --- /dev/null +++ b/contributed_definitions/nyaml/NXscanbox_em.yaml @@ -0,0 +1,83 @@ +category: base +doc: | + Scan box and coils which deflect an electron beam in a controlled manner. + + In electron microscopy, the scan box is instructed by the microscope + control software. This component directs the probe to controlled + locations according to a scan scheme and plan. +type: group +NXscanbox_em(NXobject): + calibration_style: + center(NX_NUMBER): + unit: NX_ANY + + # \@units: + # enumeration: nm + flyback_time(NX_FLOAT): + unit: NX_TIME + line_time(NX_FLOAT): + unit: NX_TIME + + # pixel_dwell_time? + pixel_time(NX_FLOAT): + unit: NX_TIME + requested_pixel_time(NX_FLOAT): + unit: NX_TIME + rotation(NX_FLOAT): + unit: NX_ANGLE + ac_line_sync(NX_BOOLEAN): + (NXfabrication): + + # (NXcg_point_set): + # NEW ISSUE: build on work of EMglossary with HMC and use duty cycle instead + # NEW ISSUE: make use of and define duty cycle + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# b0cf038d9e5a98cef1fc709b5ba7eeb0ab97cad439c564353ea7ec522b414727 +# +# +# +# +# +# Scan box and coils which deflect an electron beam in a controlled manner. +# +# In electron microscopy, the scan box is instructed by the microscope +# control software. This component directs the probe to controlled +# locations according to a scan scheme and plan. +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXsensor_scan.yaml b/contributed_definitions/nyaml/NXsensor_scan.yaml new file mode 100644 index 0000000000..fd0237e7c7 --- /dev/null +++ b/contributed_definitions/nyaml/NXsensor_scan.yaml @@ -0,0 +1,335 @@ +category: base +doc: | + Application definition for a generic scan using sensors. + + In this application definition, times should be specified always together + with an UTC offset. +symbols: + doc: | + Variables used to set a common size for collected sensor data. + N_scanpoints: | + The number of scan points measured in this scan. +type: group +NXsensor_scan(NXobject): + (NXentry): + definition(NX_CHAR): + \@version: + enumeration: [NXsensor_scan] + experiment_identifier(NX_CHAR): + exists: recommended + experiment_description(NX_CHAR): + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + (NXprocess): + doc: | + Define the program that was used to generate the results file(s) + with measured data and metadata. + program(NX_CHAR): + doc: | + Commercial or otherwise defined given name of the program + (or a link to the instrument software). + \@version: + doc: | + Either version with build number, commit hash, or description of an + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + \@program_url: + doc: | + Website of the software. + (NXuser): + doc: | + Contact information of at least the user of the instrument or the + investigator who performed this experiment. Adding multiple users if + relevant is recommended. + name(NX_CHAR): + doc: | + Name of the user. + affiliation(NX_CHAR): + exists: recommended + doc: | + Name of the affiliation of the user at the point in time when + the experiment was performed. + address(NX_CHAR): + exists: recommended + doc: | + Full address (street, street number, ZIP, city, country) + of the user's affiliation. + email(NX_CHAR): + exists: recommended + doc: | + Email address of the user. + orcid(NX_CHAR): + exists: recommended + doc: | + Author ID defined by https://orcid.org/. + telephone_number(NX_CHAR): + exists: recommended + doc: | + Official telephone number of the user. + (NXinstrument): + (NXenvironment): + doc: | + Describes an environment setup for the experiment. + + All the setting values of the independently scanned controllers are listed under corresponding + NXsensor groups. Similarly, seperate NXsensor groups are used to store the readings from each + measurement sensor. + + For example, in a temperature-dependent IV measurement, the temperature and voltage must be + present as independently scanned controllers and the current sensor must also be present with + its readings. + (NXsensor): + (NXdata): + exists: recommended + doc: | + Plot of measured signal as a function of the timestamp of when they have been + acquired is also possible. + value(NX_FLOAT): + unit: NX_ANY + doc: | + For each point in the scan space, either the nominal setpoint of an independently scanned controller + or a representative average value of a measurement sensor is registered. + + The length of each sensor's data value array stored in this group should be equal to the number of scan points + probed in this scan. For every scan point [N], the corresponding sensor value can be picked from index [N]. + This allows the scan to be made in any order as the user describes above in the experiment. We get matching + values simply using the index of the scan point. + dimensions: + rank: 1 + dim: [[1, N_scanpoints]] + value_timestamp(NX_DATE_TIME): + exists: recommended + doc: | + Timestamp for when the values provided in the value field were registered. + + Individual readings can be stored with their timestamps under value_log. This is to timestamp + the nominal setpoint or average reading values listed above in the value field. + run_control(NX_CHAR): + exists: recommended + \@description: + doc: | + Free-text describing the data acquisition control: an internal + sweep using the built-in functionality of the controller device, + or a set/wait/read/repeat mechanism. + calibration_time(NX_DATE_TIME): + doc: | + ISO8601 datum when calibration was last performed + before this measurement. UTC offset should be specified. + (NXpid): + independent_controllers: + doc: | + A list of names of NXsensor groups used as independently scanned controllers. + measurement_sensors: + doc: | + A list of names of NXsensor groups used as measurement sensors. + (NXsample): + name(NX_CHAR): + (NXdata): + doc: | + A scan specific representation of the measured signals as a function of the independently controlled environment settings. + Plot of every measured signal as a function of the timestamp of when they have been acquired is also possible. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 5eb0510291ac6f2adfa9fae7ce4425bfb6c9b9a584bbca2d28d32d7beb291a58 +# +# +# +# +# +# +# Variables used to set a common size for collected sensor data. +# +# +# +# The number of scan points measured in this scan. +# +# +# +# +# Application definition for a generic scan using sensors. +# +# In this application definition, times should be specified always together +# with an UTC offset. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Define the program that was used to generate the results file(s) +# with measured data and metadata. +# +# +# +# Commercial or otherwise defined given name of the program +# (or a link to the instrument software). +# +# +# +# Either version with build number, commit hash, or description of an +# (online) repository where the source code of the program and build +# instructions can be found so that the program can be configured in +# such a way that result files can be created ideally in a +# deterministic manner. +# +# +# +# +# Website of the software. +# +# +# +# +# +# +# Contact information of at least the user of the instrument or the +# investigator who performed this experiment. Adding multiple users if +# relevant is recommended. +# +# +# +# Name of the user. +# +# +# +# +# Name of the affiliation of the user at the point in time when +# the experiment was performed. +# +# +# +# +# Full address (street, street number, ZIP, city, country) +# of the user's affiliation. +# +# +# +# +# Email address of the user. +# +# +# +# +# Author ID defined by https://orcid.org/. +# +# +# +# +# Official telephone number of the user. +# +# +# +# +# +# +# Describes an environment setup for the experiment. +# +# All the setting values of the independently scanned controllers are listed under corresponding +# NXsensor groups. Similarly, seperate NXsensor groups are used to store the readings from each +# measurement sensor. +# +# For example, in a temperature-dependent IV measurement, the temperature and voltage must be +# present as independently scanned controllers and the current sensor must also be present with +# its readings. +# +# +# +# +# Plot of measured signal as a function of the timestamp of when they have been +# acquired is also possible. +# +# +# +# +# For each point in the scan space, either the nominal setpoint of an independently scanned controller +# or a representative average value of a measurement sensor is registered. +# +# The length of each sensor's data value array stored in this group should be equal to the number of scan points +# probed in this scan. For every scan point [N], the corresponding sensor value can be picked from index [N]. +# This allows the scan to be made in any order as the user describes above in the experiment. We get matching +# values simply using the index of the scan point. +# +# +# +# +# +# +# +# Timestamp for when the values provided in the value field were registered. +# +# Individual readings can be stored with their timestamps under value_log. This is to timestamp +# the nominal setpoint or average reading values listed above in the value field. +# +# +# +# +# +# Free-text describing the data acquisition control: an internal +# sweep using the built-in functionality of the controller device, +# or a set/wait/read/repeat mechanism. +# +# +# +# +# +# ISO8601 datum when calibration was last performed +# before this measurement. UTC offset should be specified. +# +# +# +# +# +# +# A list of names of NXsensor groups used as independently scanned controllers. +# +# +# +# +# A list of names of NXsensor groups used as measurement sensors. +# +# +# +# +# +# +# +# +# +# A scan specific representation of the measured signals as a function of the independently controlled environment settings. +# Plot of every measured signal as a function of the timestamp of when they have been acquired is also possible. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXsensor_sts.yaml b/contributed_definitions/nyaml/NXsensor_sts.yaml new file mode 100644 index 0000000000..9403c62f77 --- /dev/null +++ b/contributed_definitions/nyaml/NXsensor_sts.yaml @@ -0,0 +1,384 @@ +category: base +doc: | + A sensor used to monitor an external condition + + The condition itself is described in :ref:`NXenvironment`. +type: group +NXsensor_sts(NXobject): + model: + doc: | + Sensor identification code/model number + name: + doc: | + Name for the sensor + short_name: + doc: | + Short name of sensor used e.g. on monitor display program + attached_to: + doc: | + where sensor is attached to ("sample" | "can") + geometry(NXgeometry): + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the beamstop and NXoff_geometry to describe its shape instead + doc: | + Defines the axes for logged vector quantities if they are not the global + instrument axes. + measurement: + doc: | + name for measured signal + enumeration: [temperature, pH, magnetic_field, electric_field, conductivity, resistance, voltage, current, pressure, flow, stress, strain, shear, surface_pressure] + type: + doc: | + The type of hardware used for the measurement. + Examples (suggestions but not restrictions): + + :Temperature: + J | K | T | E | R | S | Pt100 | Pt1000 | Rh/Fe + :pH: + Hg/Hg2Cl2 | Ag/AgCl | ISFET + :Ion selective electrode: + specify species; e.g. Ca2+ + :Magnetic field: + Hall + :Surface pressure: + wilhelmy plate + amplifier(NXamplifier): + second_amplifier(NXcircuit): + doc: | + link to second amplifer circuit with 1MOhm + run_control(NX_BOOLEAN): + doc: | + Is data collection controlled or synchronised to this quantity: + 1=no, 0=to "value", 1=to "value_deriv1", etc. + high_trip_value(NX_FLOAT): + unit: NX_ANY + doc: | + Upper control bound of sensor reading if using run_control + low_trip_value(NX_FLOAT): + unit: NX_ANY + doc: | + Lower control bound of sensor reading if using run_control + value(NX_FLOAT): + unit: NX_ANY + doc: | + nominal setpoint or average value + - need [n] as may be a vector + dimensions: + dim: [[1, n]] + value_deriv1(NX_FLOAT): + unit: NX_ANY + doc: | + Nominal/average first derivative of value + e.g. strain rate + - same dimensions as "value" (may be a vector) + dimensions: + dim: [[1, ]] + dim_parameters: + ref: ['value'] + value_deriv2(NX_FLOAT): + unit: NX_ANY + doc: | + Nominal/average second derivative of value + - same dimensions as "value" (may be a vector) + dimensions: + dim: [[1, ]] + dim_parameters: + ref: ['value'] + value_log(NXlog): + doc: | + Time history of sensor readings + value_deriv1_log(NXlog): + doc: | + Time history of first derivative of sensor readings + value_deriv2_log(NXlog): + doc: | + Time history of second derivative of sensor readings + external_field_brief: + enumeration: [along beam, across beam, transverse, solenoidal, flow shear gradient, flow vorticity] + external_field_full(NXorientation): + doc: | + For complex external fields not satisfied by External_field_brief + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the sensor when necessary. + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a sensor. + (NXtransformations): + doc: | + 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. + temperature(NX_NUMBER): + unit: NX_TEMPERATURE + doc: | + External sensors connected to the device. For example, T1, temperature of STM + head. T2, temperature of bottom of LHe helium cryostat. T3, temperature of LN2 + nitrogen shield. + pressure(NX_NUMBER): + unit: NX_PRESSURE + doc: | + External sensors connected to the device. Pressure of each chamber or ion pump, + such as prepare chamber and analysis chamber + power_spectral_density(NX_NUMBER): + doc: | + The power present in the signal as a function of frequency. Used to characterise + the vibration and noise of scanning probes to detect and reduce the impact on + resolution during STM imaging + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e9d1c4dfb1ffa31931d46320db4e37890c8876331bee6ecc729f3ac844d23a01 +# +# +# +# +# +# A sensor used to monitor an external condition +# +# The condition itself is described in :ref:`NXenvironment`. +# +# +# +# Sensor identification code/model number +# +# +# +# +# Name for the sensor +# +# +# +# +# Short name of sensor used e.g. on monitor display program +# +# +# +# +# where sensor is attached to ("sample" | "can") +# +# +# +# +# Defines the axes for logged vector quantities if they are not the global +# instrument axes. +# +# +# +# +# name for measured signal +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The type of hardware used for the measurement. +# Examples (suggestions but not restrictions): +# +# :Temperature: +# J | K | T | E | R | S | Pt100 | Pt1000 | Rh/Fe +# :pH: +# Hg/Hg2Cl2 | Ag/AgCl | ISFET +# :Ion selective electrode: +# specify species; e.g. Ca2+ +# :Magnetic field: +# Hall +# :Surface pressure: +# wilhelmy plate +# +# +# +# +# +# link to second amplifer circuit with 1MOhm +# +# +# +# +# Is data collection controlled or synchronised to this quantity: +# 1=no, 0=to "value", 1=to "value_deriv1", etc. +# +# +# +# +# Upper control bound of sensor reading if using run_control +# +# +# +# +# Lower control bound of sensor reading if using run_control +# +# +# +# +# nominal setpoint or average value +# - need [n] as may be a vector +# +# +# +# +# +# +# +# Nominal/average first derivative of value +# e.g. strain rate +# - same dimensions as "value" (may be a vector) +# +# +# +# +# +# +# +# Nominal/average second derivative of value +# - same dimensions as "value" (may be a vector) +# +# +# +# +# +# +# +# Time history of sensor readings +# +# +# +# +# Time history of first derivative of sensor readings +# +# +# +# +# Time history of second derivative of sensor readings +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# For complex external fields not satisfied by External_field_brief +# +# +# +# +# This group describes the shape of the sensor when necessary. +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a sensor. +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# +# External sensors connected to the device. For example, T1, temperature of STM +# head. T2, temperature of bottom of LHe helium cryostat. T3, temperature of LN2 +# nitrogen shield. +# +# +# +# +# External sensors connected to the device. Pressure of each chamber or ion pump, +# such as prepare chamber and analysis chamber +# +# +# +# +# The power present in the signal as a function of frequency. Used to characterise +# the vibration and noise of scanning probes to detect and reduce the impact on +# resolution during STM imaging +# +# +# diff --git a/contributed_definitions/nyaml/NXseparator.yaml b/contributed_definitions/nyaml/NXseparator.yaml new file mode 100644 index 0000000000..f3d94ab6ac --- /dev/null +++ b/contributed_definitions/nyaml/NXseparator.yaml @@ -0,0 +1,108 @@ +category: base +doc: | + definition for an electrostatic separator. +type: group +NXseparator(NXobject): + description(NX_CHAR): + doc: | + extended description of the separator. + beamline_distance(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + doc: | + define position of beamline element relative to production target + set_Bfield_current(NX_FLOAT): + unit: NX_CURRENT + exists: ['min', '0', 'max', '1'] + doc: | + current set on magnet supply. + read_Bfield_current(NXlog): + exists: ['min', '0', 'max', '1'] + doc: | + current read from magnet supply. + value: + unit: NX_CURRENT + read_Bfield_voltage(NXlog): + exists: ['min', '0', 'max', '1'] + doc: | + voltage read from magnet supply. + value: + unit: NX_VOLTAGE + set_Efield_voltage(NX_FLOAT): + unit: NX_VOLTAGE + exists: ['min', '0', 'max', '1'] + doc: | + current set on HT supply. + read_Efield_current(NXlog): + exists: ['min', '0', 'max', '1'] + doc: | + current read from HT supply. + value: + unit: NX_CURRENT + read_Efield_voltage(NXlog): + exists: ['min', '0', 'max', '1'] + doc: | + voltage read from HT supply. + value: + unit: NX_VOLTAGE + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 0221be104fb3192c4a5b942ad422bee251f3519e222030df39dbc3acf85b4fc4 +# +# +# +# +# definition for an electrostatic separator. +# +# extended description of the separator. +# +# +# define position of beamline element relative to production target +# +# +# current set on magnet supply. +# +# +# current read from magnet supply. +# +# +# +# voltage read from magnet supply. +# +# +# +# current set on HT supply. +# +# +# current read from HT supply. +# +# +# +# voltage read from HT supply. +# +# +# diff --git a/contributed_definitions/nyaml/NXsimilarity_grouping.yaml b/contributed_definitions/nyaml/NXsimilarity_grouping.yaml new file mode 100644 index 0000000000..36c2607eb5 --- /dev/null +++ b/contributed_definitions/nyaml/NXsimilarity_grouping.yaml @@ -0,0 +1,290 @@ +category: base +doc: | + Metadata to the results of a similarity grouping analysis. + + Similarity grouping analyses can be supervised segmentation or machine learning + clustering algorithms. These are routine methods which partition the member of + a set of objects/geometric primitives into (sub-)groups, features of + different type. A plethora of algorithms have been proposed which can be applied + also on geometric primitives like points, triangles, or (abstract) features aka + objects (including categorical sub-groups). + + This base class considers metadata and results of one similarity grouping + analysis applied to a set in which objects are either categorized as noise + or belonging to a cluster. + As the results of the analysis each similarity group, here called feature + aka object can get a number of numerical and/or categorical labels. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + c: | + Cardinality of the set. + n_lbl_num: | + Number of numerical labels per object. + n_lbl_cat: | + Number of categorical labels per object. + n_features: | + Total number of similarity groups aka features, objects, clusters. +type: group +NXsimilarity_grouping(NXobject): + cardinality(NX_UINT): + unit: NX_UNITLESS + doc: | + Number of members in the set which is partitioned into features. + number_of_numeric_labels(NX_UINT): + unit: NX_UNITLESS + doc: | + How many numerical labels does each feature have. + number_of_categorical_labels(NX_UINT): + unit: NX_UNITLESS + doc: | + How many categorical labels does each feature have. + + # features: + # doc: | + # Reference to a set of features investigated in a cluster analysis. + # Features need to have disjoint numeric identifier. + identifier_offset(NX_UINT): + unit: NX_UNITLESS + doc: | + Which identifier is the first to be used to label a cluster. + + The value should be chosen in such a way that special values can be resolved: + * identifier_offset-1 indicates an object belongs to no cluster. + * identifier_offset-2 indicates an object belongs to the noise category. + Setting for instance identifier_offset to 1 recovers the commonly used + case that objects of the noise category get values to -1 and unassigned points to 0. + Numerical identifier have to be strictly increasing. + dimensions: + rank: 1 + dim: [[1, n_lbl_num]] + numerical_label(NX_UINT): + unit: NX_UNITLESS + doc: | + Matrix of numerical label for each member in the set. + For classical clustering algorithms this can for instance + encode the cluster_identifier. + dimensions: + rank: 2 + dim: [[1, c], [2, n_lbl_num]] + categorical_label(NX_CHAR): + doc: | + Matrix of categorical attribute data for each member in the set. + + # list instances of base classes of an applied cluster algorithm + # e.g. (NXclustering_hdbscan): + dimensions: + rank: 2 + dim: [[1, c], [2, n_lbl_cat]] + statistics(NXprocess): + doc: | + In addition to the detailed storage which members was grouped to which + feature/group summary statistics are stored under this group. + + # at the level of the set + number_of_unassigned_members(NX_UINT): + unit: NX_UNITLESS + doc: | + Total number of members in the set which are categorized as unassigned. + dimensions: + rank: 1 + dim: [[1, n_lbl_num]] + noise(NX_UINT): + unit: NX_UNITLESS + doc: | + Total number of members in the set which are categorized as noise. + dimensions: + rank: 1 + dim: [[1, n_lbl_num]] + + # at the level of the feature set + number_of_features(NX_UINT): + unit: NX_UNITLESS + doc: | + Total number of clusters (excluding noise and unassigned). + feature_identifier(NX_UINT): + unit: NX_UNITLESS + doc: | + Array of numerical identifier of each feature (cluster). + dimensions: + rank: 2 + dim: [[1, n_features], [2, n_lbl_num]] + feature_member_count(NX_UINT): + unit: NX_UNITLESS + doc: | + Array of number of members for each feature. + dimensions: + rank: 2 + dim: [[1, n_features], [2, n_lbl_num]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# b6a955e00d978d62e58fa73c93c262a104d7b49152e2a9cf054abbc8eaa1d46b +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Cardinality of the set. +# +# +# +# +# Number of numerical labels per object. +# +# +# +# +# Number of categorical labels per object. +# +# +# +# +# Total number of similarity groups aka features, objects, clusters. +# +# +# +# +# Metadata to the results of a similarity grouping analysis. +# +# Similarity grouping analyses can be supervised segmentation or machine learning +# clustering algorithms. These are routine methods which partition the member of +# a set of objects/geometric primitives into (sub-)groups, features of +# different type. A plethora of algorithms have been proposed which can be applied +# also on geometric primitives like points, triangles, or (abstract) features aka +# objects (including categorical sub-groups). +# +# This base class considers metadata and results of one similarity grouping +# analysis applied to a set in which objects are either categorized as noise +# or belonging to a cluster. +# As the results of the analysis each similarity group, here called feature +# aka object can get a number of numerical and/or categorical labels. +# +# +# +# Number of members in the set which is partitioned into features. +# +# +# +# +# How many numerical labels does each feature have. +# +# +# +# +# How many categorical labels does each feature have. +# +# +# +# +# +# Which identifier is the first to be used to label a cluster. +# +# The value should be chosen in such a way that special values can be resolved: +# * identifier_offset-1 indicates an object belongs to no cluster. +# * identifier_offset-2 indicates an object belongs to the noise category. +# Setting for instance identifier_offset to 1 recovers the commonly used +# case that objects of the noise category get values to -1 and unassigned points to 0. +# Numerical identifier have to be strictly increasing. +# +# +# +# +# +# +# +# Matrix of numerical label for each member in the set. +# For classical clustering algorithms this can for instance +# encode the cluster_identifier. +# +# +# +# +# +# +# +# +# Matrix of categorical attribute data for each member in the set. +# +# +# +# +# +# +# +# +# +# In addition to the detailed storage which members was grouped to which +# feature/group summary statistics are stored under this group. +# +# +# +# +# Total number of members in the set which are categorized as unassigned. +# +# +# +# +# +# +# +# Total number of members in the set which are categorized as noise. +# +# +# +# +# +# +# +# +# Total number of clusters (excluding noise and unassigned). +# +# +# +# +# Array of numerical identifier of each feature (cluster). +# +# +# +# +# +# +# +# +# Array of number of members for each feature. +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXsingle_crystal.yaml b/contributed_definitions/nyaml/NXsingle_crystal.yaml new file mode 100644 index 0000000000..c249281bcd --- /dev/null +++ b/contributed_definitions/nyaml/NXsingle_crystal.yaml @@ -0,0 +1,113 @@ +category: base +doc: | + Description of a single crystal material or a single crystalline phase in a material. + + There is the option of using Busing-Levy convention (as orginally designed in NXsample) + or using a more detailed description with NXrotation_set. +type: group +NXsingle_crystal(NXobject): + sample_orientation(NX_FLOAT): + unit: NX_ANGLE + doc: | + This will follow the Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + dimensions: + rank: 1 + dim: [[1, 3]] + orientation_matrix(NX_FLOAT): + doc: | + Orientation matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + dimensions: + rank: 2 + dim: [[1, 3], [2, 3]] + ub_matrix(NX_FLOAT): + doc: | + UB matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is + the multiplication of the orientation_matrix, given above, + with the :math:`B` matrix which can be derived from the lattice constants. + dimensions: + rank: 2 + dim: [[1, 3], [2, 3]] + rotation_set(NXrotation_set): + doc: | + Detailed description of single crystal orientation and misorientation. + (NXunit_cell): + doc: | + Unit cell of the single crystal. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# ece5215b46fffec7506fe8a5894f26facb19f44a56424615404f4cf3bd2f6334 +# +# +# +# +# +# Description of a single crystal material or a single crystalline phase in a material. +# +# There is the option of using Busing-Levy convention (as orginally designed in NXsample) +# or using a more detailed description with NXrotation_set. +# +# +# +# This will follow the Busing-Levy convention: +# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 +# +# +# +# +# +# +# +# Orientation matrix of single crystal sample using Busing-Levy convention: +# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 +# +# +# +# +# +# +# +# +# UB matrix of single crystal sample using Busing-Levy convention: +# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is +# the multiplication of the orientation_matrix, given above, +# with the :math:`B` matrix which can be derived from the lattice constants. +# +# +# +# +# +# +# +# +# Detailed description of single crystal orientation and misorientation. +# +# +# +# +# Unit cell of the single crystal. +# +# +# diff --git a/contributed_definitions/nyaml/NXslip_system_set.yaml b/contributed_definitions/nyaml/NXslip_system_set.yaml new file mode 100644 index 0000000000..6eb2bdf13e --- /dev/null +++ b/contributed_definitions/nyaml/NXslip_system_set.yaml @@ -0,0 +1,135 @@ +category: base +doc: | + Base class for describing a set of crystallographic slip systems. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n: | + Number of slip systems. +type: group +NXslip_system_set(NXobject): + + # number_of_objects(NX_UINT): + # identifier_offset(NX_UINT): + # identifier(NX_UINT): + lattice_type: + + # doc: Array of lattice types. + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, trigonal, hexagonal, cubic] + + # dimensions: + # rank: 1 + # dim: [[1, n]] + miller_plane(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Array of Miller indices which describe the crystallographic plane. + dimensions: + rank: 2 + dim: [[1, n], [2, i]] + + # fastest changing dimension needs to be i because for instance for hexagonal hkil is needed + miller_direction(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Array of Miller indices which describe the crystallographic direction. + dimensions: + rank: 2 + dim: [[1, n], [2, i]] + is_specific(NX_BOOLEAN): + unit: NX_UNITLESS + doc: | + For each slip system a marker whether the specified Miller indices + refer to the specific slip system or the set of crystallographic equivalent + slip systems of the respective family of slip systems. + dimensions: + rank: 1 + dim: [[1, n]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e8cb089ac11808b81d9b8ee99ffc53037c3b26e4ded58f03a4053e327d5e68af +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of slip systems. +# +# +# +# +# Base class for describing a set of crystallographic slip systems. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Array of Miller indices which describe the crystallographic plane. +# +# +# +# +# +# +# +# +# +# Array of Miller indices which describe the crystallographic direction. +# +# +# +# +# +# +# +# +# For each slip system a marker whether the specified Miller indices +# refer to the specific slip system or the set of crystallographic equivalent +# slip systems of the respective family of slip systems. +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXsnsevent.yaml b/contributed_definitions/nyaml/NXsnsevent.yaml new file mode 100644 index 0000000000..759031086d --- /dev/null +++ b/contributed_definitions/nyaml/NXsnsevent.yaml @@ -0,0 +1,640 @@ +category: application +doc: | + This is a definition for event data from Spallation Neutron Source (SNS) at ORNL. +type: group +NXsnsevent(NXobject): + (NXentry): + exists: ['min', '1'] + (NXcollection)DASlogs: + doc: | + Details of all logs, both from cvinfo file and from HistoTool (frequency and proton_charge). + (NXlog): + exists: ['min', '1'] + average_value(NX_FLOAT): + average_value_error(NX_FLOAT): + exists: optional + deprecated: | + see https://github.com/nexusformat/definitions/issues/821 + average_value_errors(NX_FLOAT): + description: + duration(NX_FLOAT): + maximum_value(NX_FLOAT): + minimum_value(NX_FLOAT): + time(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, nvalue]] + value(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, nvalue]] + (NXpositioner): + exists: ['min', '0'] + doc: | + Motor logs from cvinfo file. + average_value(NX_FLOAT): + average_value_error(NX_FLOAT): + exists: optional + deprecated: | + see https://github.com/nexusformat/definitions/issues/821 + average_value_errors(NX_FLOAT): + description: + duration(NX_FLOAT): + maximum_value(NX_FLOAT): + minimum_value(NX_FLOAT): + time(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, numvalue]] + value(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, numvalue]] + (NXnote)SNSHistoTool: + SNSbanking_file_name: + SNSmapping_file_name: + author: + command1: + doc: | + Command string for event2nxl. + date: + description: + version: + (NXdata): + exists: ['min', '1'] + + # for all NXdata/banks + data_x_y(link): + target: /NXentry/NXinstrument/NXdetector/data_x_y + x_pixel_offset(link): + target: /NXentry/NXinstrument/NXdetector/x_pixel_offset + y_pixel_offset(link): + target: /NXentry/NXinstrument/NXdetector/y_pixel_offset + (NXevent_data): + exists: ['min', '1'] + + # for all NXdata/banks + event_index(link): + target: /NXentry/NXinstrument/NXdetector/event_index + event_pixel_id(link): + target: /NXentry/NXinstrument/NXdetector/event_pixel_id + event_time_of_flight(link): + target: /NXentry/NXinstrument/NXdetector/event_time_of_flight + pulse_time(link): + target: /NXentry/NXinstrument/NXdetector/pulse_time + collection_identifier: + collection_title: + definition: + doc: | + Official NXDL schema after this file goes to applications. + enumeration: [NXsnsevent] + duration(NX_FLOAT): + unit: NX_TIME + end_time(NX_DATE_TIME): + entry_identifier: + experiment_identifier: + (NXinstrument)instrument: + (NXsource)SNS: + frequency(NX_FLOAT): + unit: NX_FREQUENCY + name: + probe: + type: + SNSdetector_calibration_id: + doc: | + Detector calibration id from DAS. + SNSgeometry_file_name: + + # SNSnxtranslate + SNStranslation_service: + (NXdetector): + exists: ['min', '1'] + + # for all NXdetector/banks + azimuthal_angle(NX_FLOAT): + unit: NX_ANGLE + dimensions: + rank: 2 + dim: [[1, numx], [2, numy]] + data_x_y(NX_UINT): + doc: | + expect ``signal=2 axes="x_pixel_offset,y_pixel_offset``" + + # axes are set in data files + dimensions: + rank: 2 + dim: [[1, numx], [2, numy]] + distance(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, numx], [2, numy]] + event_index(NX_UINT): + dimensions: + rank: 1 + dim: [[1, numpulses]] + event_pixel_id(NX_UINT): + dimensions: + rank: 1 + dim: [[1, numevents]] + event_time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + dimensions: + rank: 1 + dim: [[1, numevents]] + (NXgeometry)origin: + (NXorientation)orientation: + value(NX_FLOAT): + doc: | + Six out of nine rotation parameters. + dimensions: + rank: 1 + dim: [[1, 6]] + (NXshape)shape: + description: + shape: + size(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 3]] + (NXtranslation)translation: + distance(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 3]] + pixel_id(NX_UINT): + dimensions: + rank: 2 + dim: [[1, numx], [2, numy]] + polar_angle(NX_FLOAT): + unit: NX_ANGLE + dimensions: + rank: 2 + dim: [[1, numx], [2, numy]] + pulse_time(NX_FLOAT): + unit: NX_TIME + dimensions: + rank: 1 + dim: [[1, numpulses]] + total_counts(NX_UINT): + x_pixel_offset(NX_FLOAT): + axis: 1 + primary: 1 + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, numx]] + y_pixel_offset(NX_FLOAT): + axis: 2 + primary: 1 + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, numy]] + beamline: + (NXdisk_chopper): + exists: ['min', '0'] + distance(NX_FLOAT): + unit: NX_LENGTH + (NXmoderator)moderator: + coupling_material: + distance(NX_FLOAT): + unit: NX_LENGTH + temperature(NX_FLOAT): + unit: NX_TEMPERATURE + type: + name: + (NXaperture): + exists: ['min', '0'] + (NXgeometry)origin: + (NXorientation)orientation: + value(NX_FLOAT): + doc: | + Six out of nine rotation parameters. + dimensions: + rank: 1 + dim: [[1, 6]] + (NXshape)shape: + description: + shape: + size(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 3]] + (NXtranslation)translation: + distance(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 3]] + x_pixel_offset(NX_FLOAT): + unit: NX_LENGTH + (NXattenuator): + exists: ['min', '0'] + distance(NX_FLOAT): + unit: NX_LENGTH + + # motor links from DASlogs when exist + (NXpolarizer): + exists: ['min', '0'] + + # motor links from DASlogs when exist + (NXcrystal): + exists: ['min', '0'] + (NXgeometry)origin: + description: + (NXorientation)orientation: + value(NX_FLOAT): + doc: | + Six out of nine rotation parameters. + dimensions: + rank: 1 + dim: [[1, 6]] + (NXshape)shape: + description: + shape: + size(NX_FLOAT): + unit: NX_LENGTH + (NXtranslation)translation: + distance(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 3]] + type: + wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + (NXmonitor): + exists: ['min', '0'] + data(NX_UINT): + doc: | + expect ``signal=1 axes="time_of_flight"`` + dimensions: + rank: 1 + dim: [[1, numtimechannels]] + distance(NX_FLOAT): + unit: NX_LENGTH + mode: + time_of_flight(NX_FLOAT): + unit: NX_TIME + dimensions: + rank: 1 + dim: [[1, numtimechannels + 1]] + notes: + proton_charge(NX_FLOAT): + unit: NX_CHARGE + raw_frames(NX_INT): + run_number: + (NXsample)sample: + changer_position: + holder: + identifier: + name: + doc: | + Descriptive name of sample + nature: + start_time(NX_DATE_TIME): + title: + total_counts(NX_UINT): + unit: NX_UNITLESS + total_uncounted_counts(NX_UINT): + unit: NX_UNITLESS + (NXuser): + exists: ['min', '1'] + facility_user_id: + name: + role: + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# d0da2705c1153ff2021e04b4c5abe571adccba0be8c90abb9ff59fdca205ea53 +# +# +# +# +# This is a definition for event data from Spallation Neutron Source (SNS) at ORNL. +# +# +# +# Details of all logs, both from cvinfo file and from HistoTool (frequency and proton_charge). +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Motor logs from cvinfo file. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Command string for event2nxl. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Official NXDL schema after this file goes to applications. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Detector calibration id from DAS. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# expect ``signal=2 axes="x_pixel_offset,y_pixel_offset``" +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Six out of nine rotation parameters. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Six out of nine rotation parameters. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Six out of nine rotation parameters. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# expect ``signal=1 axes="time_of_flight"`` +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXsnshisto.yaml b/contributed_definitions/nyaml/NXsnshisto.yaml new file mode 100644 index 0000000000..ba06411749 --- /dev/null +++ b/contributed_definitions/nyaml/NXsnshisto.yaml @@ -0,0 +1,670 @@ +category: application +doc: | + This is a definition for histogram data from Spallation Neutron Source (SNS) at ORNL. +type: group +NXsnshisto(NXobject): + (NXentry): + exists: ['min', '1'] + (NXcollection)DASlogs: + doc: | + Details of all logs, both from cvinfo file and from HistoTool (frequency and proton_charge). + (NXlog): + exists: ['min', '1'] + average_value(NX_FLOAT): + average_value_error(NX_FLOAT): + exists: optional + deprecated: | + see https://github.com/nexusformat/definitions/issues/821 + average_value_errors(NX_FLOAT): + description: + duration(NX_FLOAT): + maximum_value(NX_FLOAT): + minimum_value(NX_FLOAT): + time(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, nvalue]] + value(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, nvalue]] + (NXpositioner): + exists: ['min', '0'] + doc: | + Motor logs from cvinfo file. + average_value(NX_FLOAT): + average_value_error(NX_FLOAT): + exists: optional + deprecated: | + see https://github.com/nexusformat/definitions/issues/821 + average_value_errors(NX_FLOAT): + description: + duration(NX_FLOAT): + maximum_value(NX_FLOAT): + minimum_value(NX_FLOAT): + time(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, numvalue]] + value(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, numvalue]] + (NXnote)SNSHistoTool: + SNSbanking_file_name: + SNSmapping_file_name: + author: + command1: + doc: | + Command string for event2histo_nxl. + date: + description: + version: + (NXdata): + exists: ['min', '1'] + + # for all NXdata/banks + data(link): + target: /NXentry/NXinstrument/NXdetector/data + data_x_time_of_flight(link): + target: /NXentry/NXinstrument/NXdetector/data_x_time_of_flight + data_x_y(link): + target: /NXentry/NXinstrument/NXdetector/data_x_y + data_y_time_of_flight(link): + target: /NXentry/NXinstrument/NXdetector/data_y_time_of_flight + pixel_id(link): + target: /NXentry/NXinstrument/NXdetector/pixel_id + time_of_flight(link): + target: /NXentry/NXinstrument/NXdetector/time_of_flight + total_counts(link): + target: /NXentry/NXinstrument/NXdetector/total_counts + x_pixel_offset(link): + target: /NXentry/NXinstrument/NXdetector/x_pixel_offset + y_pixel_offset(link): + target: /NXentry/NXinstrument/NXdetector/y_pixel_offset + collection_identifier: + collection_title: + definition: + doc: | + Official NXDL schema after this file goes to applications. + enumeration: [NXsnshisto] + duration(NX_FLOAT): + unit: NX_TIME + end_time(NX_DATE_TIME): + entry_identifier: + experiment_identifier: + (NXinstrument)instrument: + (NXsource)SNS: + frequency(NX_FLOAT): + unit: NX_FREQUENCY + name: + probe: + type: + SNSdetector_calibration_id: + doc: | + Detector calibration id from DAS. + SNSgeometry_file_name: + + # SNSnxtranslate + SNStranslation_service: + (NXdetector): + exists: ['min', '1'] + + # for all NXdetector/banks + azimuthal_angle(NX_FLOAT): + unit: NX_ANGLE + dimensions: + rank: 2 + dim: [[1, numx], [2, numy]] + data(NX_UINT): + signal: 1 + axes: x_pixel_offset,y_pixel_offset,time_of_flight + dimensions: + rank: 3 + dim: [[1, numx], [2, numy], [3, numtof]] + data_x_time_of_flight(NX_UINT): + signal: 3 + axes: x_pixel_offset,time_of_flight + dimensions: + rank: 2 + dim: [[1, numx], [2, numtof]] + data_x_y(NX_UINT): + signal: 2 + axes: x_pixel_offset,y_pixel_offset + dimensions: + rank: 2 + dim: [[1, numx], [2, numy]] + data_y_time_of_flight(NX_UINT): + signal: 4 + axes: y_pixel_offset,time_of_flight + dimensions: + rank: 2 + dim: [[1, numy], [2, numtof]] + distance(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 2 + dim: [[1, numx], [2, numy]] + (NXgeometry)origin: + (NXorientation)orientation: + value(NX_FLOAT): + doc: | + Six out of nine rotation parameters. + dimensions: + rank: 1 + dim: [[1, 6]] + (NXshape)shape: + description: + shape: + size(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 3]] + (NXtranslation)translation: + distance(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 3]] + pixel_id(NX_UINT): + dimensions: + rank: 2 + dim: [[1, numx], [2, numy]] + polar_angle(NX_FLOAT): + unit: NX_ANGLE + dimensions: + rank: 2 + dim: [[1, numx], [2, numy]] + time_of_flight(NX_FLOAT): + axis: 3 + primary: 1 + unit: NX_TIME_OF_FLIGHT + dimensions: + rank: 1 + dim: [[1, numtof + 1]] + total_counts(NX_UINT): + x_pixel_offset(NX_FLOAT): + axis: 1 + primary: 1 + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, numx]] + y_pixel_offset(NX_FLOAT): + axis: 2 + primary: 1 + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, numy]] + beamline: + (NXdisk_chopper): + exists: ['min', '0'] + doc: | + Original specification called for NXchopper, + which is not a valid NeXus base class. + Select either NXdisk_chopper or NXfermi_chopper, as appropriate. + distance(NX_FLOAT): + unit: NX_LENGTH + (NXfermi_chopper): + exists: ['min', '0'] + doc: | + Original specification called for NXchopper, + which is not a valid NeXus base class. + Select either NXdisk_chopper or NXfermi_chopper, as appropriate. + distance(NX_FLOAT): + unit: NX_LENGTH + (NXmoderator)moderator: + coupling_material: + distance(NX_FLOAT): + unit: NX_LENGTH + temperature(NX_FLOAT): + unit: NX_TEMPERATURE + type: + name: + (NXaperture): + exists: ['min', '0'] + (NXgeometry)origin: + (NXorientation)orientation: + value(NX_FLOAT): + doc: | + Six out of nine rotation parameters. + dimensions: + rank: 1 + dim: [[1, 6]] + (NXshape)shape: + description: + shape: + size(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 3]] + (NXtranslation)translation: + distance(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 3]] + x_pixel_offset(NX_FLOAT): + unit: NX_LENGTH + (NXattenuator): + exists: ['min', '0'] + distance(NX_FLOAT): + unit: NX_LENGTH + + # motor links from DASlogs when exist + (NXpolarizer): + exists: ['min', '0'] + + # motor links from DASlogs when exist + (NXcrystal): + exists: ['min', '0'] + (NXgeometry)origin: + description: + (NXorientation)orientation: + value(NX_FLOAT): + doc: | + Six out of nine rotation parameters. + dimensions: + rank: 1 + dim: [[1, 6]] + (NXshape)shape: + description: + shape: + size(NX_FLOAT): + unit: NX_LENGTH + (NXtranslation)translation: + distance(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 3]] + type: + wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + (NXmonitor): + exists: ['min', '0'] + data(NX_UINT): + signal: 1 + axes: time_of_flight + dimensions: + rank: 1 + dim: [[1, numtimechannels]] + distance(NX_FLOAT): + unit: NX_LENGTH + mode: + time_of_flight(NX_FLOAT): + unit: NX_TIME + dimensions: + rank: 1 + dim: [[1, numtimechannels + 1]] + notes: + proton_charge(NX_FLOAT): + unit: NX_CHARGE + raw_frames(NX_INT): + run_number: + (NXsample)sample: + changer_position: + holder: + identifier: + name: + doc: | + Descriptive name of sample + nature: + start_time(NX_DATE_TIME): + title: + total_counts(NX_UINT): + unit: NX_UNITLESS + total_uncounted_counts(NX_UINT): + unit: NX_UNITLESS + (NXuser): + exists: ['min', '1'] + facility_user_id: + name: + role: + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# aeae16f4bdba7aa9f6f48be75c35f0024eec1adb3900b632d04b4abb50670053 +# +# +# +# +# This is a definition for histogram data from Spallation Neutron Source (SNS) at ORNL. +# +# +# +# Details of all logs, both from cvinfo file and from HistoTool (frequency and proton_charge). +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Motor logs from cvinfo file. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Command string for event2histo_nxl. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Official NXDL schema after this file goes to applications. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Detector calibration id from DAS. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Six out of nine rotation parameters. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Original specification called for NXchopper, +# which is not a valid NeXus base class. +# Select either NXdisk_chopper or NXfermi_chopper, as appropriate. +# +# +# +# +# +# Original specification called for NXchopper, +# which is not a valid NeXus base class. +# Select either NXdisk_chopper or NXfermi_chopper, as appropriate. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Six out of nine rotation parameters. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Six out of nine rotation parameters. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Descriptive name of sample +# +# +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXsolenoid_magnet.yaml b/contributed_definitions/nyaml/NXsolenoid_magnet.yaml new file mode 100644 index 0000000000..ae5f355fa5 --- /dev/null +++ b/contributed_definitions/nyaml/NXsolenoid_magnet.yaml @@ -0,0 +1,84 @@ +category: base +doc: | + definition for a solenoid magnet. +type: group +NXsolenoid_magnet(NXobject): + description(NX_CHAR): + doc: | + extended description of the magnet. + beamline_distance(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + doc: | + define position of beamline element relative to production target + set_current(NX_FLOAT): + unit: NX_CURRENT + exists: ['min', '0', 'max', '1'] + doc: | + current set on supply. + read_current(NXlog): + exists: ['min', '0', 'max', '1'] + doc: | + current read from supply. + value: + unit: NX_CURRENT + read_voltage(NXlog): + exists: ['min', '0', 'max', '1'] + doc: | + voltage read from supply. + value: + unit: NX_VOLTAGE + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 1364b1b892354a667957c67d8d4d7b6ebb5f1a1bd7fc2dc5876622ed45239995 +# +# +# +# +# definition for a solenoid magnet. +# +# extended description of the magnet. +# +# +# define position of beamline element relative to production target +# +# +# current set on supply. +# +# +# current read from supply. +# +# +# +# voltage read from supply. +# +# +# diff --git a/contributed_definitions/nyaml/NXsolid_geometry.yaml b/contributed_definitions/nyaml/NXsolid_geometry.yaml new file mode 100644 index 0000000000..3d752e4626 --- /dev/null +++ b/contributed_definitions/nyaml/NXsolid_geometry.yaml @@ -0,0 +1,76 @@ +category: base +doc: | + the head node for constructively defined geometry +type: group +NXsolid_geometry(NXobject): + (NXquadric): + exists: ['min', '0'] + doc: | + Instances of :ref:`NXquadric` making up elements of the geometry. + (NXoff_geometry): + exists: ['min', '0'] + doc: | + Instances of :ref:`NXoff_geometry` making up elements of the geometry. + (NXcsg): + exists: ['min', '0'] + doc: | + The geometries defined, made up of instances of :ref:`NXquadric` and :ref:`NXoff_geometry`. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 71a1b3ca39b88fdae9499a10284ddc6fd89423b5d2e3e1d544bacfa3793bb5c0 +# +# +# +# +# +# the head node for constructively defined geometry +# +# +# +# Instances of :ref:`NXquadric` making up elements of the geometry. +# +# +# +# +# Instances of :ref:`NXoff_geometry` making up elements of the geometry. +# +# +# +# +# The geometries defined, made up of instances of :ref:`NXquadric` and :ref:`NXoff_geometry`. +# +# +# diff --git a/contributed_definitions/nyaml/NXspatial_filter.yaml b/contributed_definitions/nyaml/NXspatial_filter.yaml new file mode 100644 index 0000000000..f78214d27f --- /dev/null +++ b/contributed_definitions/nyaml/NXspatial_filter.yaml @@ -0,0 +1,134 @@ +category: base +doc: | + Spatial filter to filter entries within a region-of-interest based on their + position. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_ellipsoids: | + Number of ellipsoids. + n_hexahedra: | + Number of hexahedra. + n_cylinders: | + Number of cylinders. + +# n_polyhedra: Number of polyhedra. +# n_vertices: Number of vertices for polyhedra. +# n_facets: Number of facets for polyhedra. +type: group +NXspatial_filter(NXobject): + windowing_method: + doc: | + Qualitative statement which specifies which spatial filtering with respective + geometric primitives or bitmask is used. These settings are possible: + + * entire_dataset, no filter is applied, the entire dataset is used. + * union_of_primitives, a filter with (rotated) geometric primitives. + All ions in or on the surface of the primitives are considered + while all other ions are ignored. + * bitmasked_points, a boolean array whose bits encode with 1 + which ions should be included. Those ions whose bit is set to 0 + will be excluded. Users of python can use the bitfield operations + of the numpy package to define such bitfields. + + Conditions: + In the case that windowing_method is entire_dataset all entries are processed. + In the case that windowing_method is union_of_primitives, + it is possible to specify none or all types of primitives + (ellipsoids, cylinder, hexahedra). If no primitives are specified + the filter falls back to entire_dataset. + In the case that windowing_method is bitmask, the bitmask has to be defined; + otherwise the filter falls back to entire dataset. + enumeration: [entire_dataset, union_of_primitives, bitmask] + (NXcg_ellipsoid_set): + (NXcg_cylinder_set): + (NXcg_hexahedron_set): + (NXcs_filter_boolean_mask): + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 791b662f16e375b77792d796be1d1f955b3d65c46016e3ecde10353845d23079 +# +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Number of ellipsoids. +# +# +# +# +# Number of hexahedra. +# +# +# +# +# Number of cylinders. +# +# +# +# +# Spatial filter to filter entries within a region-of-interest based on their +# position. +# +# +# +# Qualitative statement which specifies which spatial filtering with respective +# geometric primitives or bitmask is used. These settings are possible: +# +# * entire_dataset, no filter is applied, the entire dataset is used. +# * union_of_primitives, a filter with (rotated) geometric primitives. +# All ions in or on the surface of the primitives are considered +# while all other ions are ignored. +# * bitmasked_points, a boolean array whose bits encode with 1 +# which ions should be included. Those ions whose bit is set to 0 +# will be excluded. Users of python can use the bitfield operations +# of the numpy package to define such bitfields. +# +# Conditions: +# In the case that windowing_method is entire_dataset all entries are processed. +# In the case that windowing_method is union_of_primitives, +# it is possible to specify none or all types of primitives +# (ellipsoids, cylinder, hexahedra). If no primitives are specified +# the filter falls back to entire_dataset. +# In the case that windowing_method is bitmask, the bitmask has to be defined; +# otherwise the filter falls back to entire dataset. +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXspectrum_set.yaml b/contributed_definitions/nyaml/NXspectrum_set.yaml new file mode 100644 index 0000000000..3b70f6c2c6 --- /dev/null +++ b/contributed_definitions/nyaml/NXspectrum_set.yaml @@ -0,0 +1,271 @@ +category: base +doc: | + Container for reporting a set of spectra. +symbols: + + # n_p: Number of scan points + n_y: | + Number of pixel in the slow direction. + n_x: | + Number of pixel in the fast direction. + n_energy: | + Number of energy bins. +type: group +NXspectrum_set(NXobject): + (NXprocess): + doc: | + Details how spectra were processed from the detector readings. + source: + doc: | + Resolvable data artifact (e.g. filename) from which the all values in + the NXdata instances in this NXspectrum_set were loaded during parsing. + \@version: + doc: | + An at least as strong as SHA256 hashvalue of the data artifact which + source represents digitally to support provenance tracking. + mode: + doc: | + Imaging (data collection) mode of the instrument during acquisition + of the data in this NXspectrum_set instance. + detector_identifier: + doc: | + Link or name of an NXdetector instance with which the data were collected. + (NXprogram): + + ##MK::feel free to contact us when you would like to include more complicated scan pattern than rectangular ones. + stack(NXdata): + doc: | + Collected spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + data_counts(NX_NUMBER): + unit: NX_UNITLESS + dimensions: + rank: 3 + dim: [[1, n_y], [2, n_x], [3, n_energy]] + \@long_name: + doc: | + Counts + + # \@signal: counts + # \@axes: [ypos, xpos, energy] + # \@ypos_indices: 0 + # \@xpos_indices: 1 + # \@energy_indices: 2 + axis_y(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + doc: | + Coordinate along y direction + axis_x(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: + doc: | + Coordinate along x direction + axis_energy(NX_NUMBER): + unit: NX_ENERGY + dimensions: + rank: 1 + dim: [[1, n_energy]] + \@long_name: + doc: | + Energy + + # in the majority of cases rectangular or line scans are performed + # if there is interest to support arbitrary scan pattern one should use + # scan points and contact us to generalize this base class and related + # base classes + summary(NXdata): + doc: | + Accumulated counts over all pixels of the region-of-interest. + This representation supports rectangular scan pattern. + data_counts(NX_NUMBER): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_energy]] + \@long_name: + doc: | + Counts + + # \@signal: counts + # \@axes: [energy] + # \@energy_indices: 0 + axis_energy(NX_NUMBER): + unit: NX_ENERGY + dimensions: + rank: 1 + dim: [[1, n_energy]] + \@long_name: + doc: | + Energy + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# d3297ed4c9fb7b26cc057812a358e3f143c762535d90c5d5adced47ed949e703 +# +# +# +# +# +# +# +# +# Number of pixel in the slow direction. +# +# +# +# +# Number of pixel in the fast direction. +# +# +# +# +# Number of energy bins. +# +# +# +# +# Container for reporting a set of spectra. +# +# +# +# Details how spectra were processed from the detector readings. +# +# +# +# Resolvable data artifact (e.g. filename) from which the all values in +# the NXdata instances in this NXspectrum_set were loaded during parsing. +# +# +# +# An at least as strong as SHA256 hashvalue of the data artifact which +# source represents digitally to support provenance tracking. +# +# +# +# +# +# Imaging (data collection) mode of the instrument during acquisition +# of the data in this NXspectrum_set instance. +# +# +# +# +# Link or name of an NXdetector instance with which the data were collected. +# +# +# +# +# +# +# +# Collected spectra for all pixels of a rectangular region-of-interest. +# This representation supports rectangular scan pattern. +# +# +# +# +# +# +# +# +# +# Counts +# +# +# +# +# +# +# +# +# +# +# Coordinate along y direction +# +# +# +# +# +# +# +# +# +# Coordinate along x direction +# +# +# +# +# +# +# +# +# +# Energy +# +# +# +# +# +# +# +# Accumulated counts over all pixels of the region-of-interest. +# This representation supports rectangular scan pattern. +# +# +# +# +# +# +# +# Counts +# +# +# +# +# +# +# +# +# +# +# Energy +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXspectrum_set_em_eels.yaml b/contributed_definitions/nyaml/NXspectrum_set_em_eels.yaml new file mode 100644 index 0000000000..431c1dacd4 --- /dev/null +++ b/contributed_definitions/nyaml/NXspectrum_set_em_eels.yaml @@ -0,0 +1,315 @@ +category: base +doc: | + Container for reporting a set of electron energy loss (EELS) spectra. + + Virtually the most important case is that spectra are collected in + a scanning microscope (SEM or STEM) for a collection of points. + The majority of cases use simple d-dimensional regular scan pattern, + such as single point, line profiles, or (rectangular) surface mappings. + + The latter pattern is the most frequently used. + For now the base class provides for scans for which the settings, + binning, and energy resolution is the same for each scan point. +symbols: + + # n_p: Number of scan points + n_y: | + Number of pixel per EELS mapping in the slow direction. + n_x: | + Number of pixel per EELS mapping in the fast direction. + n_energy_loss: | + Number of electron energy loss bins. +type: group +NXspectrum_set_em_eels(NXobject): + (NXprocess): + doc: | + Details how EELS spectra were processed from the detector readings. + source: + doc: | + Typically the name of the input, (vendor) file from which all + the NXdata instances in this NXspectrum_set_em_eels were loaded during + parsing to represent them in e.g. databases. + \@version: + doc: | + An at least as strong as SHA256 hashvalue of the dataset/file + which represents the source digitally to support provenance tracking. + program: + doc: | + Commercial or otherwise given name to the program which was used + to process detector data into the EELS spectra stack and summary. + \@version: + doc: | + Program version plus build number, commit hash, or description + of an ever persistent resource where the source code of the program + and build instructions can be found so that the program + can be configured in such a manner that the result file + is ideally recreatable yielding the same results. + stack(NXdata): + doc: | + Collected EELS spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + data_counts(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Counts for one spectrum per each pixel. + dimensions: + rank: 3 + dim: [[1, n_y], [2, n_x], [3, n_energy_loss]] + \@long_name: + doc: | + EELS counts + + # \@signal: counts + # \@axes: [ypos, xpos, energy_loss] + # \@energy_loss_indices: 2 + # \@xpos_indices: 1 + # \@ypos_indices: 0 + axis_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Pixel center of mass position y-coordinates. + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + doc: | + Coordinate along y direction. + axis_x(NX_NUMBER): + unit: NX_LENGTH + doc: | + Pixel center of mass position x-coordinates. + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: + doc: | + Coordinate along x direction. + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + doc: | + Pixel center of mass energy loss bins. + dimensions: + rank: 1 + dim: [[1, n_energy_loss]] + \@long_name: + doc: | + Coordinate along energy loss axis. + summary(NXdata): + doc: | + Accumulated EELS spectrum over all pixels of a rectangular + region-of-interest. This representation supports rectangular scan pattern. + data_counts(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Counts for specific energy losses. + dimensions: + rank: 1 + dim: [[1, n_energy_loss]] + \@long_name: + doc: | + Counts electrons with an energy loss within binned range. + + # \@signal: counts + # \@axes: [energy_loss] + # \@energy_loss_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + doc: | + Pixel center of mass energy loss bins. + dimensions: + rank: 1 + dim: [[1, n_energy_loss]] + \@long_name: + doc: | + Coordinate along energy loss axis. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# d8d7b516bc82a0490225a0f879f17753b30a7c182c8d13b7a972a6533847b21f +# +# +# +# +# +# +# +# +# Number of pixel per EELS mapping in the slow direction. +# +# +# +# +# Number of pixel per EELS mapping in the fast direction. +# +# +# +# +# Number of electron energy loss bins. +# +# +# +# +# Container for reporting a set of electron energy loss (EELS) spectra. +# +# Virtually the most important case is that spectra are collected in +# a scanning microscope (SEM or STEM) for a collection of points. +# The majority of cases use simple d-dimensional regular scan pattern, +# such as single point, line profiles, or (rectangular) surface mappings. +# +# The latter pattern is the most frequently used. +# For now the base class provides for scans for which the settings, +# binning, and energy resolution is the same for each scan point. +# +# +# +# Details how EELS spectra were processed from the detector readings. +# +# +# +# Typically the name of the input, (vendor) file from which all +# the NXdata instances in this NXspectrum_set_em_eels were loaded during +# parsing to represent them in e.g. databases. +# +# +# +# An at least as strong as SHA256 hashvalue of the dataset/file +# which represents the source digitally to support provenance tracking. +# +# +# +# +# +# Commercial or otherwise given name to the program which was used +# to process detector data into the EELS spectra stack and summary. +# +# +# +# Program version plus build number, commit hash, or description +# of an ever persistent resource where the source code of the program +# and build instructions can be found so that the program +# can be configured in such a manner that the result file +# is ideally recreatable yielding the same results. +# +# +# +# +# +# +# Collected EELS spectra for all pixels of a rectangular region-of-interest. +# This representation supports rectangular scan pattern. +# +# +# +# Counts for one spectrum per each pixel. +# +# +# +# +# +# +# +# +# EELS counts +# +# +# +# +# +# +# Pixel center of mass position y-coordinates. +# +# +# +# +# +# +# Coordinate along y direction. +# +# +# +# +# +# Pixel center of mass position x-coordinates. +# +# +# +# +# +# +# Coordinate along x direction. +# +# +# +# +# +# Pixel center of mass energy loss bins. +# +# +# +# +# +# +# Coordinate along energy loss axis. +# +# +# +# +# +# +# Accumulated EELS spectrum over all pixels of a rectangular +# region-of-interest. This representation supports rectangular scan pattern. +# +# +# +# Counts for specific energy losses. +# +# +# +# +# +# +# Counts electrons with an energy loss within binned range. +# +# +# +# +# +# +# Pixel center of mass energy loss bins. +# +# +# +# +# +# +# Coordinate along energy loss axis. +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXspectrum_set_em_xray.yaml b/contributed_definitions/nyaml/NXspectrum_set_em_xray.yaml new file mode 100644 index 0000000000..7183b1f975 --- /dev/null +++ b/contributed_definitions/nyaml/NXspectrum_set_em_xray.yaml @@ -0,0 +1,534 @@ +category: base +doc: | + Container for reporting a set of energy-dispersive X-ray spectra. + + Virtually the most important case is that spectra are collected in + a scanning microscope (SEM or STEM) for a collection of points. + The majority of cases use simple d-dimensional regular scan pattern, + such as single point, line profiles, or (rectangular) surface mappings. + The latter pattern is the most frequently used. + + For now the base class provides for scans for which the settings, + binning, and energy resolution is the same for each scan point. + + `IUPAC instead of Siegbahn notation `_ + should be used. + +# NEW ISSUE: use computational geometry to offer arbitrary scan pattern +# NEW ISSUE: make the binning flexible per scan point +symbols: + + # n_p: Number of scan points + n_y: | + Number of pixel per X-ray mapping in the slow direction + n_x: | + Number of pixel per X-ray mapping in the fast direction + n_photon_energy: | + Number of X-ray photon energy (bins) + n_elements: | + Number of identified elements + n_peaks: | + Number of peaks +type: group +NXspectrum_set_em_xray(NXobject): + (NXprocess): + doc: | + Details how X-ray spectra were processed from the detector readings. + source: + doc: | + Typically the name of the input, (vendor) file from which all + the NXdata instances in this NXspectrum_set_em_xray were loaded during + parsing to represent them in e.g. databases. + \@version: + doc: | + An at least as strong as SHA256 hashvalue of the dataset/file + which represents the source digitally to support provenance tracking. + program: + doc: | + Commercial or otherwise given name to the program which was used + to process detector data into the X-ray spectra stack and summary. + \@version: + doc: | + Program version plus build number, commit hash, or description + of an ever persistent resource where the source code of the program + and build instructions can be found so that the program + can be configured in such a manner that the result file + is ideally recreatable yielding the same results. + + ##MK::for supporting arbitrary scan pattern we need a good example first + ##MK::feel free to contact us in this regard! + stack(NXdata): + doc: | + Collected X-ray spectra for all pixels of a rectangular region-of-interest. + This representation supports rectangular scan pattern. + data_counts(NX_NUMBER): + unit: NX_UNITLESS + dimensions: + rank: 3 + dim: [[1, n_y], [2, n_x], [3, n_photon_energy]] + \@long_name: + doc: | + X-ray photon counts + + # \@signal: counts + # \@axes: [ypos, xpos, photon_energy] + # \@ypos_indices: 0 + # \@xpos_indices: 1 + # \@photon_energy_indices: 2 + axis_y(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + doc: | + Coordinate along y direction. + axis_x(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: + doc: | + Coordinate along x direction. + axis_photon_energy(NX_NUMBER): + unit: NX_ENERGY + dimensions: + rank: 1 + dim: [[1, n_photon_energy]] + \@long_name: + doc: | + Photon energy. + summary(NXdata): + doc: | + Accumulated X-ray spectrum over all pixels of a rectangular + region-of-interest. This representation supports rectangular scan pattern. + data_counts(NX_NUMBER): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_photon_energy]] + \@long_name: + doc: | + X-ray photon counts + + # \@signal: counts + # \@axes: [photon_energy] + # \@photon_energy_indices: 0 + axis_photon_energy(NX_NUMBER): + unit: NX_ENERGY + dimensions: + rank: 1 + dim: [[1, n_photon_energy]] + \@long_name: + doc: | + Photon energy + + # for post-processing of/with the above-defined data entries + indexing(NXprocess): + doc: | + Details about computational steps how peaks were indexed as elements. + program: + doc: | + Given name of the program that was used to perform this computation. + \@version: + doc: | + Program version plus build number, commit hash, or description of an + ever persistent resource where the source code of the program and + build instructions can be found so that the program can be configured + in such a manner that the result file is ideally recreatable yielding + the same results. + (NXpeak): + doc: | + Name and location of each X-ray line which was indexed as a known ion. + For each ion an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + (NXion): + iupac_line_names: + doc: | + IUPAC notation identifier of the line which the peak represents. + + This can be a list of IUPAC notations for (the seldom) case that + multiple lines are group with the same peak. + element_names: + doc: | + List of the names of identified elements. + dimensions: + rank: 1 + dim: [[1, n_elements]] + ELEMENTNAME(NXprocess): + doc: | + Individual element-specific EDX/EDS/EDXS/SXES mapping + + A composition map is an image whose intensities for each pixel are the + accumulated X-ray quanta *under the curve(s)* of a set of peaks. + program: + doc: | + Given name of the program that was used to perform this computation. + \@version: + doc: | + Program version plus build number, commit hash, or description of an + ever persistent resource where the source code of the program and + build instructions can be found so that the program can be configured + in such a manner that the result file is ideally recreatable yielding + the same results. + peaks: + doc: | + A list of strings of named instances of NXpeak from indexing + whose X-ray quanta where accumulated for each pixel. + dimensions: + rank: 1 + dim: [[1, n_peaks]] + name: + doc: | + Human-readable, given name to the image. + + # example how an element-specific pattern could be stored + summary(NXdata): + doc: | + Individual element-specific maps. Individual maps should + each be a group and be named according to element_names. + data_counts(NX_NUMBER): + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, n_y], [2, n_x]] + \@long_name: + doc: | + Accumulated photon counts for observed element. + + # \@signal: counts + # \@axes: [ypos, xpos] + # \@xpos_indices: 1 + # \@ypos_indices: 0 + axis_y(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + doc: | + Coordinate along y direction. + axis_x(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: + doc: | + Coordinate along x direction. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 6d33f28eb5adb076b4551f108d8825f9dde6549b8b705d56009b2968c89b9e13 +# +# +# +# +# +# +# +# +# +# Number of pixel per X-ray mapping in the slow direction +# +# +# +# +# Number of pixel per X-ray mapping in the fast direction +# +# +# +# +# Number of X-ray photon energy (bins) +# +# +# +# +# Number of identified elements +# +# +# +# +# Number of peaks +# +# +# +# +# Container for reporting a set of energy-dispersive X-ray spectra. +# +# Virtually the most important case is that spectra are collected in +# a scanning microscope (SEM or STEM) for a collection of points. +# The majority of cases use simple d-dimensional regular scan pattern, +# such as single point, line profiles, or (rectangular) surface mappings. +# The latter pattern is the most frequently used. +# +# For now the base class provides for scans for which the settings, +# binning, and energy resolution is the same for each scan point. +# +# `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ +# should be used. +# +# +# +# Details how X-ray spectra were processed from the detector readings. +# +# +# +# Typically the name of the input, (vendor) file from which all +# the NXdata instances in this NXspectrum_set_em_xray were loaded during +# parsing to represent them in e.g. databases. +# +# +# +# An at least as strong as SHA256 hashvalue of the dataset/file +# which represents the source digitally to support provenance tracking. +# +# +# +# +# +# Commercial or otherwise given name to the program which was used +# to process detector data into the X-ray spectra stack and summary. +# +# +# +# Program version plus build number, commit hash, or description +# of an ever persistent resource where the source code of the program +# and build instructions can be found so that the program +# can be configured in such a manner that the result file +# is ideally recreatable yielding the same results. +# +# +# +# +# +# +# +# Collected X-ray spectra for all pixels of a rectangular region-of-interest. +# This representation supports rectangular scan pattern. +# +# +# +# +# +# +# +# +# +# X-ray photon counts +# +# +# +# +# +# +# +# +# +# +# Coordinate along y direction. +# +# +# +# +# +# +# +# +# +# Coordinate along x direction. +# +# +# +# +# +# +# +# +# +# Photon energy. +# +# +# +# +# +# +# Accumulated X-ray spectrum over all pixels of a rectangular +# region-of-interest. This representation supports rectangular scan pattern. +# +# +# +# +# +# +# +# X-ray photon counts +# +# +# +# +# +# +# +# +# +# +# Photon energy +# +# +# +# +# +# +# +# Details about computational steps how peaks were indexed as elements. +# +# +# +# Given name of the program that was used to perform this computation. +# +# +# +# Program version plus build number, commit hash, or description of an +# ever persistent resource where the source code of the program and +# build instructions can be found so that the program can be configured +# in such a manner that the result file is ideally recreatable yielding +# the same results. +# +# +# +# +# +# Name and location of each X-ray line which was indexed as a known ion. +# For each ion an NXion instance should be created which specifies +# the origin of the signal. For each ion also the relevant IUPAC notation +# X-ray lines should be specified. +# +# +# +# +# IUPAC notation identifier of the line which the peak represents. +# +# This can be a list of IUPAC notations for (the seldom) case that +# multiple lines are group with the same peak. +# +# +# +# +# +# +# List of the names of identified elements. +# +# +# +# +# +# +# +# Individual element-specific EDX/EDS/EDXS/SXES mapping +# +# A composition map is an image whose intensities for each pixel are the +# accumulated X-ray quanta *under the curve(s)* of a set of peaks. +# +# +# +# Given name of the program that was used to perform this computation. +# +# +# +# Program version plus build number, commit hash, or description of an +# ever persistent resource where the source code of the program and +# build instructions can be found so that the program can be configured +# in such a manner that the result file is ideally recreatable yielding +# the same results. +# +# +# +# +# +# A list of strings of named instances of NXpeak from indexing +# whose X-ray quanta where accumulated for each pixel. +# +# +# +# +# +# +# +# Human-readable, given name to the image. +# +# +# +# +# +# Individual element-specific maps. Individual maps should +# each be a group and be named according to element_names. +# +# +# +# +# +# +# +# +# Accumulated photon counts for observed element. +# +# +# +# +# +# +# +# +# +# +# Coordinate along y direction. +# +# +# +# +# +# +# +# +# +# Coordinate along x direction. +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXspin_rotator.yaml b/contributed_definitions/nyaml/NXspin_rotator.yaml new file mode 100644 index 0000000000..8cdf66348c --- /dev/null +++ b/contributed_definitions/nyaml/NXspin_rotator.yaml @@ -0,0 +1,108 @@ +category: base +doc: | + definition for a spin rotator. +type: group +NXspin_rotator(NXobject): + description(NX_CHAR): + doc: | + extended description of the spin rotator. + beamline_distance(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + doc: | + define position of beamline element relative to production target + set_Bfield_current(NX_FLOAT): + unit: NX_CURRENT + exists: ['min', '0', 'max', '1'] + doc: | + current set on magnet supply. + read_Bfield_current(NXlog): + exists: ['min', '0', 'max', '1'] + doc: | + current read from magnet supply. + value: + unit: NX_CURRENT + read_Bfield_voltage(NXlog): + exists: ['min', '0', 'max', '1'] + doc: | + voltage read from magnet supply. + value: + unit: NX_VOLTAGE + set_Efield_voltage(NX_FLOAT): + unit: NX_VOLTAGE + exists: ['min', '0', 'max', '1'] + doc: | + current set on HT supply. + read_Efield_current(NXlog): + exists: ['min', '0', 'max', '1'] + doc: | + current read from HT supply. + value: + unit: NX_CURRENT + read_Efield_voltage(NXlog): + exists: ['min', '0', 'max', '1'] + doc: | + voltage read from HT supply. + value: + unit: NX_VOLTAGE + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 260f697bca7fcdb6e806e85e0cb1459de350eab0f1eb633c5b15ac31d38c1572 +# +# +# +# +# definition for a spin rotator. +# +# extended description of the spin rotator. +# +# +# define position of beamline element relative to production target +# +# +# current set on magnet supply. +# +# +# current read from magnet supply. +# +# +# +# voltage read from magnet supply. +# +# +# +# current set on HT supply. +# +# +# current read from HT supply. +# +# +# +# voltage read from HT supply. +# +# +# diff --git a/contributed_definitions/nyaml/NXspindispersion.yaml b/contributed_definitions/nyaml/NXspindispersion.yaml new file mode 100644 index 0000000000..7b37920b94 --- /dev/null +++ b/contributed_definitions/nyaml/NXspindispersion.yaml @@ -0,0 +1,154 @@ +category: base +doc: | + Subclass of NXelectronanalyser to describe the spin filters in photoemission + experiments. +type: group +NXspindispersion(NXobject): + type(NX_CHAR): + doc: | + Type of spin detector, VLEED, SPLEED, Mott, etc. + figure_of_merit(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + Figure of merit of the spin detector + shermann_function(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + Effective Shermann function, calibrated spin selectivity factor + scattering_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + Energy of the spin-selective scattering + scattering_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Angle of the spin-selective scattering + target(NX_CHAR): + doc: | + Name of the target + target_preparation(NX_CHAR): + doc: | + Preparation procedure of the spin target + target_preparation_date(NX_DATE_TIME): + doc: | + Date of last preparation of the spin target + depends_on(NX_CHAR): + doc: | + Specifies the position of the lens by pointing to the last transformation in the + transformation chain in the NXtransformations group. + (NXtransformations): + doc: | + Collection of axis-based translations and rotations to describe the location and + geometry of the deflector as a component in the instrument. Conventions from the + NXtransformations base class are used. In principle, the McStas coordinate + system is used. The first transformation has to point either to another + component of the system or . (for pointing to the reference frame) to relate it + relative to the experimental setup. Typically, the components of a system should + all be related relative to each other and only one component should relate to + the reference coordinate system. + (NXdeflector): + doc: | + Deflectors in the spin dispersive section + (NXlens_em): + doc: | + Individual lenses in the spin dispersive section + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 5f68e83a10b4fa836b7ab5fafa790e5d55657315050706de79f99356f2b01872 +# +# +# +# +# +# Subclass of NXelectronanalyser to describe the spin filters in photoemission +# experiments. +# +# +# +# Type of spin detector, VLEED, SPLEED, Mott, etc. +# +# +# +# +# Figure of merit of the spin detector +# +# +# +# +# Effective Shermann function, calibrated spin selectivity factor +# +# +# +# +# Energy of the spin-selective scattering +# +# +# +# +# Angle of the spin-selective scattering +# +# +# +# +# Name of the target +# +# +# +# +# Preparation procedure of the spin target +# +# +# +# +# Date of last preparation of the spin target +# +# +# +# +# Specifies the position of the lens by pointing to the last transformation in the +# transformation chain in the NXtransformations group. +# +# +# +# +# Collection of axis-based translations and rotations to describe the location and +# geometry of the deflector as a component in the instrument. Conventions from the +# NXtransformations base class are used. In principle, the McStas coordinate +# system is used. The first transformation has to point either to another +# component of the system or . (for pointing to the reference frame) to relate it +# relative to the experimental setup. Typically, the components of a system should +# all be related relative to each other and only one component should relate to +# the reference coordinate system. +# +# +# +# +# Deflectors in the spin dispersive section +# +# +# +# +# Individual lenses in the spin dispersive section +# +# +# diff --git a/contributed_definitions/nyaml/NXstage_lab.yaml b/contributed_definitions/nyaml/NXstage_lab.yaml new file mode 100644 index 0000000000..2584d06c90 --- /dev/null +++ b/contributed_definitions/nyaml/NXstage_lab.yaml @@ -0,0 +1,315 @@ +category: base +doc: | + A stage lab can be used to hold, align, orient, and prepare a specimen. + + Modern stages are multi-functional devices. Many of which offer a controlled + environment around (a part) of the specimen. Stages enable experimentalists + to apply stimuli. A stage_lab is a multi-purpose/-functional tools which + can have multiple actuators, sensors, and other components. + + With such stages comes the need for storing various (meta)data + that are generated while manipulating the sample. + + Modern stages realize a hierarchy of components: For example the specimen + might be mounted on a multi-axial tilt rotation holder. This holder is + fixed in the support unit which connects the holder to the rest of the + microscope. + + In other examples, taken from atom probe microscopy, researchers may work + with wire samples which are clipped into a larger fixing unit for + convenience and enable for a more careful specimen handling. + This fixture unit is known in atom probe jargon as a stub. + Stubs in turn are positioned onto pucks. + Pucks are then loaded onto carousels. + A carousel is a carrier unit with which eventually entire sets of specimens + can be moved in between parts of the microscope. + + An NXstage_lab instance reflects this hierarchical design. The stage is the + root of the hierarchy. A stage carries the holder. + In the case that it is not practical to distinguish these two layers, + the holder should be given preference. + + Some examples for stage_labs in applications: + + * A nanoparticle on a copper grid. The copper grid is the holder. + The grid itself is fixed to the stage. + * An atom probe specimen fixed in a stub. In this case the stub can be + considered the holder, while the cryostat temperature control unit is + a component of the stage. + * Samples with arrays of specimens, like a microtip on a microtip array + is an example of a three-layer hierarchy commonly employed for + efficient sequential processing of atom probe experiments. + * With one entry of an application definition only one microtip should be + described. Therefore, the microtip is the specimen, + the array is the holder and the remaining mounting unit + that is attached to the cryo-controller is the stage. + * For in-situ experiments with e.g. chips with read-out electronics + as actuators, the chips are again placed in a larger unit. + * Other examples are (quasi) in-situ experiments where experimentalists + anneal or deform the specimen via e.g. in-situ tensile testing machines + which are mounted on the specimen holder. + + To cover for an as flexible design of complex stages, users should nest + multiple instances of NXstage_lab objects according to their needs to reflect + the differences between what they consider as the holder and what + they consider is the stage. + + Instances should be named with integers starting from 1 as the top level unit. + In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder + (microtip array), stage_lab_3 for the microtip specimen, respectively. + The depends_on keyword should be used with relative or absolute naming inside + the file to specify how different stage_lab instances build a hierarchy + if this is not obvious from numbered identifiers like the stage_lab_1 to + stage_lab 3 example. The lower it is the number the higher it is the + rank in the hierarchy. + + For specific details and inspiration about stages in electron microscopes: + + * `Holders with multiple axes `_ + * `Chip-based designs `_ + * `Further chip-based designs `_ + * `Stages in transmission electron microscopy `_ (page 103, table 4.2) + * `Further stages in transmission electron microscopy `_ (page 124ff) + * `Specimens in atom probe `_ (page 47ff) + * `Exemplar micro-manipulators `_ +type: group +NXstage_lab(NXobject): + design: + doc: | + Principal design of the stage. + + Exemplar terms could be side_entry, top_entry, + single_tilt, quick_change, multiple_specimen, + bulk_specimen, double_tilt, tilt_rotate, + heating_chip, atmosphere_chip, + electrical_biasing_chip, liquid_cell_chip + name: + doc: | + Given name/alias for the components making the stage. + (NXfabrication): + description: + doc: | + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + tilt_1(NX_FLOAT): + unit: NX_ANGLE + doc: | + Should be defined by the application definition. + tilt_2(NX_FLOAT): + unit: NX_ANGLE + doc: | + Should be defined by the application definition. + rotation(NX_FLOAT): + unit: NX_ANGLE + doc: | + Should be defined by the application definition. + position(NX_FLOAT): + unit: NX_LENGTH + doc: | + Should be defined by the application definition. + dimensions: + rank: 1 + dim: [[1, 3]] + bias_voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Voltage applied to the stage to decelerate electrons. + + # NEW ISSUE: rather the field if possible should be specified + (NXtransformations): + doc: | + The rotation, tilt and position of stage components can be specified + either via NXtransformations or via the tilt_1, tilt_2, rotation, + and position fields. + (NXpositioner): + + # see for complicated positioning tools like an eucentric five-axis table stage in an SEM + # https://www.nanotechnik.com/e5as.html + # shipswing_tilt(NXpositioner): + # normal_rotate(NXpositioner): + # normal_height(NXpositioner): + # inplane_translate1(NXpositioner): + # inplane_translate2(NXpositioner): + # NEW ISSUE: add temperature control units and components to apply external stimuli + # NEW ISSUE: on the specimen such as NXmech_testing_unit and NXfurnace, NXreaction_cell + # NEW ISSUE: by contrast, the purpose and design of so-called nano/or micromanipulators, + # i.e. automatable devices to perform e.g. site-specific lift out, procedures warrants + # to define an own class NXspecimen_manipulator given this is nothing else than + # miniature robot arm essential one could also think about creating an own NXrobotarm class, + # below are two examples of such tools as they are used in FIB and SEMs + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 60517924e592d79ca277016453672f5211f31215284fc66cebd97852197ee39a +# +# +# +# +# +# A stage lab can be used to hold, align, orient, and prepare a specimen. +# +# Modern stages are multi-functional devices. Many of which offer a controlled +# environment around (a part) of the specimen. Stages enable experimentalists +# to apply stimuli. A stage_lab is a multi-purpose/-functional tools which +# can have multiple actuators, sensors, and other components. +# +# With such stages comes the need for storing various (meta)data +# that are generated while manipulating the sample. +# +# Modern stages realize a hierarchy of components: For example the specimen +# might be mounted on a multi-axial tilt rotation holder. This holder is +# fixed in the support unit which connects the holder to the rest of the +# microscope. +# +# In other examples, taken from atom probe microscopy, researchers may work +# with wire samples which are clipped into a larger fixing unit for +# convenience and enable for a more careful specimen handling. +# This fixture unit is known in atom probe jargon as a stub. +# Stubs in turn are positioned onto pucks. +# Pucks are then loaded onto carousels. +# A carousel is a carrier unit with which eventually entire sets of specimens +# can be moved in between parts of the microscope. +# +# An NXstage_lab instance reflects this hierarchical design. The stage is the +# root of the hierarchy. A stage carries the holder. +# In the case that it is not practical to distinguish these two layers, +# the holder should be given preference. +# +# Some examples for stage_labs in applications: +# +# * A nanoparticle on a copper grid. The copper grid is the holder. +# The grid itself is fixed to the stage. +# * An atom probe specimen fixed in a stub. In this case the stub can be +# considered the holder, while the cryostat temperature control unit is +# a component of the stage. +# * Samples with arrays of specimens, like a microtip on a microtip array +# is an example of a three-layer hierarchy commonly employed for +# efficient sequential processing of atom probe experiments. +# * With one entry of an application definition only one microtip should be +# described. Therefore, the microtip is the specimen, +# the array is the holder and the remaining mounting unit +# that is attached to the cryo-controller is the stage. +# * For in-situ experiments with e.g. chips with read-out electronics +# as actuators, the chips are again placed in a larger unit. +# * Other examples are (quasi) in-situ experiments where experimentalists +# anneal or deform the specimen via e.g. in-situ tensile testing machines +# which are mounted on the specimen holder. +# +# To cover for an as flexible design of complex stages, users should nest +# multiple instances of NXstage_lab objects according to their needs to reflect +# the differences between what they consider as the holder and what +# they consider is the stage. +# +# Instances should be named with integers starting from 1 as the top level unit. +# In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder +# (microtip array), stage_lab_3 for the microtip specimen, respectively. +# The depends_on keyword should be used with relative or absolute naming inside +# the file to specify how different stage_lab instances build a hierarchy +# if this is not obvious from numbered identifiers like the stage_lab_1 to +# stage_lab 3 example. The lower it is the number the higher it is the +# rank in the hierarchy. +# +# For specific details and inspiration about stages in electron microscopes: +# +# * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ +# * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ +# * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ +# * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) +# * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) +# * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) +# * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ +# +# +# +# Principal design of the stage. +# +# Exemplar terms could be side_entry, top_entry, +# single_tilt, quick_change, multiple_specimen, +# bulk_specimen, double_tilt, tilt_rotate, +# heating_chip, atmosphere_chip, +# electrical_biasing_chip, liquid_cell_chip +# +# +# +# +# Given name/alias for the components making the stage. +# +# +# +# +# +# Ideally, a (globally) unique persistent identifier, link, +# or text to a resource which gives further details. +# +# +# +# +# Should be defined by the application definition. +# +# +# +# +# Should be defined by the application definition. +# +# +# +# +# Should be defined by the application definition. +# +# +# +# +# Should be defined by the application definition. +# +# +# +# +# +# +# +# Voltage applied to the stage to decelerate electrons. +# +# +# +# +# +# The rotation, tilt and position of stage components can be specified +# either via NXtransformations or via the tilt_1, tilt_2, rotation, +# and position fields. +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXsts.yaml b/contributed_definitions/nyaml/NXsts.yaml new file mode 100644 index 0000000000..03e16760e9 --- /dev/null +++ b/contributed_definitions/nyaml/NXsts.yaml @@ -0,0 +1,1747 @@ +category: application +doc: | + Application definition for temperature-dependent IV curve measurements + #2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the + STM image mode in the future with a focus on bias spectroscopy in Scanning Tunneling Microscopy. + + In this application definition, times should be specified always together with a UTC offset. + + This is the application definition describing temperature (T) dependent current voltage (IV) curve + measurements. For this, a temperature is set. After reaching the temperature, a voltage sweep + is performed. For each voltage, a current is measured. + Then, the next desired temperature is set and an IV measurement is performed. + The data can be visualized in a tensor with: + I (NXsensor_C, NXsoftware_Read_offset, NXcircuit) + parameters: + V has (NXsource+offset, NXsoftware_Scan_offset, NXsensor_V, NXcircuit) + T has (NXsource, NXsoftware_Scan_offset, NXsensor_T) + x has (NXsoftware_Scan_offset) + y has (NXsoftware_Scan_offset) + z has (NXsoftware_Scan_offset) + +# 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the +type: group +NXsts(NXsensor_scan): + (NXentry): + definition: + enumeration: [NXsts] + experiment_type: + doc: | + Name of the experiment where the application is applicable. + enumeration: [sts, stm] + type: + doc: | + The equipments and techniques as well as the parameter settings and reference signals + are used during the experiments used in Scanning Tunneling Microscopy (STM). + + # NOTE_: What does the enum refer, scan could be forward or backward. (not in data file) + # What is about [constant current mode, constant height mode] + enumeration: [background, reference, sample] + entry_identifier: + exists: optional + doc: | + The name of the output file, with the number of scans at the end. (e.g. + 221122_Au_5K00014) + collection_identifier: + doc: | + The name of the series output file, which represents only the public part of the + output file. (e.g. 221122_Au_5K) + experiment_identifier: + exists: optional + doc: | + Path to storage of output files. + (e.g. Path C:\Users\SPM-PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis-Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711) + experiment_description: + exists: optional + doc: | + Descriptive comments for this experiment, added by the experimenter, coming from the + output file. (e.g. Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, locked Au(111), + 50pA, 100 mV set point, 1mV DCA, 973Hz,138 1st H, -84 2nd H) + (NXinstrument): + hardware(NXfabrication): + exists: optional + doc: | + Hardware type used in SPM experiment, includes hardware manufacturers and type. + (e.g. Nanonis BP5e) + + # hardware: Current amplifier> hardware: CreaTec GmbH + # any or specifique 'harware' and 'software'? + software(NXfabrication): + exists: optional + doc: | + Type of software used in SPM experiments, such as software version serial number, UI and + RT probe release method. (e.g. SW Version Generic 5e -- RT Release 10771) + version: + exists: optional + doc: | + Version of the software. + + # amplification: Current amplifier> factor (V/V): 1E-10 + # crosstalk_compensation: Current amplifier> Capacitive cross-talk compensation: Yes/No + current_amplifier(NXamplifier): + exists: optional + doc: | + The Amplifier description that improves or helps to determine tunnel current (current + between tip and bias). + lock_in(NXlockin): + exists: optional + status: + exists: optional + + # status: Lock-in>Lock-in status ON # ON/OFF of Lock-in amplifier + doc: | + Status of Lock-in device whether while performing the experiment + + # amplifier_status: -> amplifier/active_channels + # Lock-in Amplifier>Yes/No + # doc: Lock-in Amplifier>Yes/No # If a lock-in amplifier employed to filter or obtain + # the electronic derivatives dI/dV of the signal + # hardware: Lock-in Amplifier>Hardware: Nanonis + modulation_signal: + exists: optional + unit: NX_VOLTAGE + doc: | + This is the signal on which the modulation (sine) will be added. + + # modulate_signal: Lock-in>Modulated signal Bias (V) + modulation_frequency(NX_NUMBER): + unit: NX_FREQUENCY + + # Lock-in>Frequency (Hz) 973E+0 + doc: | + The signal is modulated by adding the frequency of the sine modulation. The + modulation frequency spans can be from 10 mHz to 40 kHz, corresponding to the output filter + cut-off range. When dealing with harmonics, it's essential to ensure that the + harmonic frequencies remain below ~100 kHz, which aligns with the input filter cut-off. + Be mindful that hardware filters might impact the amplitude as the signal approaches + their cut-off frequencies." (e.g. 973E+0) + modulation_amplitude(NX_NUMBER): + + # amplitude: Lock-in>Amplitude 2E-3 + doc: | + The amplitude (in physical units of modulated signal) of the sine modulation. + demodulated_signal: + exists: optional + + # Lock-in>Demodulated signal Current (A) # This is the signal which + # will be demodulated, in order to determine the amplitude and phase at the frequency + # set in the Frequency field (“4”) or harmonics. + doc: | + The input signal (STS signal) will be demodulated, in order to determine the amplitude + and phase at the frequency set in the Frequency field or harmonics, such as current, + bias, et.al. + harmonic_order_N(NX_NUMBER): + + # Lock-in>Harmonic D1 1 + # Lock-in>Harmonic D2 2 # See below. + doc: | + N denotes 1 or 2. The order of the harmonic oscillation to be detected in the demodulated + signal should be considered relative to the modulation frequency. When dealing with + higher harmonics, it's essential to ensure that their frequencies do not surpass + the analogue signal bandwidth (e.g. harmonic_order_1). + ref_phase_N(NX_NUMBER): + exists: optional + + # Lock-in>Reference phase D1 (deg) 137.597E+0 + # Lock-in>Reference phase D2 (deg) -83.6562E+0 # See below. + doc: | + Reference phase for the sine on the demodulated signal with respect to the + modulation signal. The determined phase is displayed with respect to the + reference phase. + lock_in_data_flip_number(NX_NUMBER): + + # items below should go to bias/spectroscopy/...!!! + # recorded_channels: + # doc: Select the channels to record. (e.g. Current (A);LI Demod 2 X (A);LI Demod 2 Y (A); + # LI Demod 1 X (A);LI Demod 1 Y (A) # Select the channels to record.) + # bias_reset: + # doc: When selected, the Bias voltage returns to the initial value (before starting the + # sweep) at the end of the spectroscopy measurement (default). When not selected, Bias + # remains at the last value of the sweep. This is useful e.g. when combining several + # sweep segments. Example for an automated measurement (using Programming Interface): + # switch off Z-Controller, start spectroscopy sweep segments (only fwd sweep, no reset + # bias), set bias back to initial value, switch on Z-Controller. (e.g. TRUE) + # record_final_z: + # doc: Select whether to record the Z position during Z averaging time at the end of the + # sweep (after Z control time) and store the average value in the header of the file + # when saving. Using this option increases the sweep time by Z averaging time. (e.g. FALSE) + # run: + # doc: Bias Spectroscopy>Lock-In run FALSE # Select whether to set the Lock-In to run + # during the measurement. When using this feature, make sure the Lock-In is configured + # correctly and settling times are set to twice the Lock-In period at least. This + # option is ignored when Lock-In is already running. This option is disabled if the + # Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline + # segment editor is set. + sample_bias(NXiv_bias): + bias(NX_NUMBER): + unit: NX_VOLTAGE + doc: | + Applied a voltage between tip and sample. + bias_calibration(NX_NUMBER): + bias_offset(NX_NUMBER): + unit: NX_VOLTAGE + + # sample_bias(NXbias): + # Tip bias/Sample bias If the spectroscopy V bias is applied to the + # Modulated signal Bias (V) 1E-3 Applied modulation to the bias voltage. + # ModulationBias> Tip bias/Sample bias + # modulated_signal_bias(NX_NUMBER): + # unit: NX_VOLTAGE + # doc: Same directional representation as bias. (e.g. 1E-3) + stm_head_temp(NX_NUMBER): + exists: optional + unit: NX_TEMPERATURE + doc: | + Temperature of STM head. Note: At least one field from stm_head_temperature, + cryo_bottom_temp and cryo_sheild_temp must be provided. + cryo_bottom_temp(NX_NUMBER): + exists: optional + unit: NX_TEMPERATURE + doc: | + Temperature of liquid helium cryostat. Note: At least one field from + stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp must be provided. + cryo_shield_temp(NX_NUMBER): + exists: optional + unit: NX_TEMPERATURE + doc: | + Temperature of liquid nitrogen shield. Temperature 3 (K) (e.g 78.00000E+0). Note: At + least one field from stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp + must be provided. + output_cabling(NXcircuit): + exists: optional + + # Cabling & Config + # output_mode: + # doc: Number of output channels. (e.g. User Output) + # output_value(NX_NUMBER): + # doc: The user output in each monitor mode. (e.g. 0E+0) + # output_name: + # doc: User outputs whose name can be modified in the corresponding module. (e.g. Input 24 (V)) + # output_slew_rate(NX_NUMBER): + # doc: The rate at which the one of the signal changes when ramping to the starting point. (V/s) (e.g. Inf) + piezo_config(NXcollection): + exists: optional + doc: | + Configuration for piezoelectric scanner used to move tip along X and Y direction. The + material of the Piezoelectric scanner composed of polycrystalline solids and sensitive to + applied voltage. + active_calib: + doc: | + The name of calibration type. (e.g. LHe) + calib_N(NX_NUMBER): + exists: optional + doc: | + N denotes X or Y or Z. There are three parameters in the X, Y, and Z directions, + along with three available controls: Calibration (m/V), Range (m), and HV gain. Only + two of these parameters are required to define the calibration. Consequently, when any + value is changed, one of the other values will be automatically updated. (e.g. calib_X = 3.8E-9) + hv_gain_N(NX_NUMBER): + exists: optional + doc: | + N denotes X or Y or Z. In some systems, there is an HV gain readout feature. For + these systems, the HV gain should be automatically adjusted whenever the gain is + changed at the high voltage amplifier. (e.g. 14.5) + + # (e.g. 0.318343) + tilt_N(NX_NUMBER): + exists: optional + unit: NX_ANGLE + doc: | + N denotes X or Y. There are 2 parameters in X and Y directions, and tilt needs to be + adjusted according to the actual surface. (in degrees, first order correction). + + # Inf + curvature_radius_N(NX_NUMBER): + exists: optional + unit: NX_LENGTH + doc: | + N denotes X or Y. There are 2 parameters in X and Y directions. (can be set + approximately to the length of the piezotube). + 2nd_order_corr_N(NX_NUMBER): + exists: optional + doc: | + N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, + you can enter the 2nd order piezo characteristics to compensate for it. The + following equation shows the interpretation of the 2nd order correction parameter: + For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: + [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx + is the 2nd order correction. (V/m^2). (e.g. 0E+0) + drift_N(NX_NUMBER): + exists: optional + doc: | + N denotes X, Y or Z. There are 3 parameters in X, Y and Z directions. Define the + drift speed for all three axes. When the compensation is on, the piezos will start to + move at that speed. (e.g. 0E+0) + drift_correction_status(NX_BOOLEAN): + doc: | + Use the button to enable or disable the drift compensation. (e.g. FALSE) + (NXenvironment): + exists: optional + doc: | + Describes an environment setup for a temperature-dependent IV measurement experiment. + The temperature and voltage must be present as independently scanned controllers and + the current sensor must also be present with its readings. + current_sensor(NXsensor): + exists: optional + current(NX_NUMBER): + unit: NX_CURRENT + doc: | + This is set-point of tip current (in the constant current mode should be equal to set-point, + in the constant height mode means the real tunnelling current between tip and sample). + current_calibration(NX_NUMBER): + unit: NX_CURRENT + doc: | + Value of calibration that comes as A/V. + current_offset(NX_NUMBER): + unit: NX_CURRENT + current_gain: + unit: NX_UNITLESS + calibration_time(NX_DATE_TIME): + exists: optional + value(NX_NUMBER): + exists: optional + position(NXpositioner_sts): + doc: | + Clarify the frame laboratory frame. + x(NX_NUMBER): + exists: optional + unit: NX_LENGTH + doc: | + The scanning area in x position in the frame. (e.g. -890.53E-12) + y(NX_NUMBER): + exists: optional + unit: NX_LENGTH + doc: | + The scanning area in y position in the frame. (e.g. 29.6968E-9) + z(NX_NUMBER): + exists: optional + unit: NX_LENGTH + doc: | + The scanning area in z position in the frame. (e.g. 130.5E-9) + z_controller(NXcollection): + z(NX_NUMBER): + unit: NX_LENGTH + doc: | + Indicate the relative tip position z between tip and sample. The tip position can also + be varied when the z_controller is not running. (e.g. 130.5E-9) + + # TODO: Is if this are uncomment than getting error. + # voltage_controller(NXsensor): + # temperature_controller(NXsensor): + # parameters for a measurement at a single location during the scan + sweep_control(NXcollection): + bias_spectroscopy(NXbias_spectroscopy): + exists: optional + integration_time(NX_NUMBER): + unit: NX_TIME + doc: | + Time during which the spectroscopy data are acquired and averaged. (e.g. 150E-6) + number_of_sweeps(NX_NUMBER): + doc: | + Number of sweeps to measure and average. (e.g. 100) + sweep_start(NX_NUMBER): + unit: NX_VOLTAGE + doc: | + The start bias values of the sweep. (e.g. -300E-3) + sweep_end(NX_NUMBER): + unit: NX_VOLTAGE + doc: | + The end bias values of the sweep. (e.g. 300E-3) + num_pixel(NX_NUMBER): + doc: | + The sweep number of points is defined as the maximum spectrum resolution, which + is equal to the bias sweep window divided by the number of pixels. (e.g. 4096) + z_avg_time(NX_NUMBER): + unit: NX_TIME + doc: | + The Z position is recorded and averaged for a certain duration both before and + after the sweep. After the initial Z averaging time, if "Z-Controller to Hold" + is selected, the Z-Controller is set to hold mode, and the tip is positioned at + the previously averaged Z position (adjusted by the Z offset). (e.g. 100E-3) + circuit(NXcollection): + exists: optional + rt_frequency(NX_NUMBER): + unit: NX_FREQUENCY + doc: | + The bandwidth of the Hardware and/or Software is instrument specific. + For example, Nanonis Generic 5 has 'RT Frequency' (e.g. 20E+3). + signals_oversampling(NX_NUMBER): + doc: | + The Signals Period represents the rate at which signals are transferred to + the host computer, which operates the control software. This rate may + be 10 times lower than the sampling rate, as the real-time engine internally + oversamples the signal. If desired, you may have the option to reduce the oversampling + to 1, enabling higher frequency resolution in the Spectrum Analyzer. (e.g. 10) + acquisition_period(NX_NUMBER): + unit: NX_TIME + exists: optional + doc: | + The update rate is utilized in various processes, including the History Graph, + Auto-Approach, and multiple Programming Interface functions. It may be + configured to a 20 ms interval. Any additional timings must strictly be integer + multiples of this base value. While it is possible to set these additional + timings to different values, the actual timing value will automatically be + adjusted to become a multiple of the Acquisition Period. (e.g. 20E-3) + animations_period(NX_NUMBER): + unit: NX_TIME + exists: optional + doc: | + The update rate of animated graphical indicators, such as graphs and sliders, + can be adjusted. A normal value may be 40 ms, which corresponds to 25 updates + per second. Increasing this period can help reduce the processor load on the + graphical user interface, particularly on slower computers. It is important to + note that this update rate solely impacts the user interface and does not affect + measurements in any manner. (e.g. 20E-3) + indicators_period(NX_NUMBER): + unit: NX_TIME + doc: | + The update rate of digital indicators, such as the numbers displayed, can be set + to 3 updates per second, equivalent to 300 ms. This interval is sufficient for + the user interface and does not impact measurements in any manner. (e.g. 300E-3) + measurements_period(NX_NUMBER): + exists: optional + unit: NX_TIME + doc: | + The Measurements period determines the integration time required for precise + measurements, primarily utilized in sweep modules. It is particularly useful for + tasks such as recording force-distance curves or cantilever resonances. For + swift measurements with small steps, a value of 40 ms is often adequate. For + regular use, a range of 300-500 ms may be recommended, but when capturing the + resonance of a high-Q cantilever, longer values in the range of several seconds + might be necessary. Usually, this parameter does not require manual adjustment + within this module, as the sweep modules automatically set this value according + to the sweep timings. (e.g. 500E-3) + + # parameters how to change the location from measurement to measurement during the scan + scan_control(NXcollection): + exists: optional + roi(NXtransformations): + frame: + doc: | + Also clarify the frame for the ROI of the scan in lab frame, the middle of the lab + frame is (0, 0), and positive in x means right and in y means up. + circuit(NXcollection): + channels_current: + doc: | + The scan channels are selected by users. (e.g. (A);Bias (V);Z (m);LI Demod 2 X + (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A)) + positioner(NXcollection): + scanfield(NX_NUMBER): + doc: | + Configure the scan frame like x position; y position; width; height. (e.g. + 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0) + pixels_line(NX_NUMBER): + doc: | + Scan resolution by setting the Lines equal to Pixels. (e.g. 512) + lines(NX_NUMBER): + doc: | + Define the image resolution. (e.g. 512) + speed_forw(NX_NUMBER): + doc: | + Define the scan forward speed in the forward direction. (m/s) (e.g. 11.7187E-9) + speed_backw(NX_NUMBER): + doc: | + Define the scan backward speed in the forward direction. (m/s) (e.g. 11.7187E-9) + + # RESOLUTION (calculation input) + # TODO: After fix resolution_indicators back to required + # As all of the bellow are linked + # should be NXcollection not NXprocess + resolution_indicators(NXprocess): + exists: optional + + # Temperature 1>link to INSTR/STM/head Temperature 1 (K) (e.g. 4.92997E+0) # Temperature of STM head. + stm_head_temp(NX_NUMBER): + exists: optional + unit: NX_TEMPERATURE + doc: | + Link to target:/NXentry/NXinstrument/stm_head_temp + + # Temperature 2>link to Temperature 2 (K) - # Temperature of bottom of LHe helium cryostat. + cryo_bottom_temp(NX_NUMBER): + exists: optional + unit: NX_TEMPERATURE + doc: | + Link to target:/NXentry/NXinstrument/cryo_bottom_temp + + # Temperature 3>link to Temperature 3 (K) - # Temperature of LN2 nitrogen shield. + cryo_shield_temp(NX_NUMBER): + exists: optional + unit: NX_TEMPERATURE + doc: | + Link to target:/NXentry/NXinstrument/temp_cryo_shield + + # Lock-in>link to Modulated signal Bias (V) (e.g. 1E-3) # Applied modulation to the bias voltage. + modulation_signal: + exists: optional + unit: NX_VOLTAGE + doc: | + Link to target:/NXentry/NXinstrument/NXlock_in/modulation_signal + + # link to Integration time (s) (e.g. 150E-6) + # Time during which the spectroscopy data are acquired and averaged. + integration_time(NX_NUMBER): + unit: NX_TIME + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/NXintegration_time + + # link to Bias Spectroscopy>Number of sweeps (e.g. 100) Number of sweeps to measure and average. + number_of_sweeps(NX_NUMBER): + unit: NX_UNITLESS + exists: optional + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/number_of_sweeps + + # link to Bias Spectroscopy>Sweep Start (V) (e.g. -300E-3) # The first bias values of the sweep. + sweep_start(NX_NUMBER): + unit: NX_VOLTAGE + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/sweep_start + + # link to Bias Spectroscopy>Sweep End (V) (e.g. 300E-3) # The last bias values of the sweep. + sweep_end(NX_NUMBER): + unit: NX_VOLTAGE + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/sweep_end + + # link to Bias Spectroscopy>Num Pixel (e.g. 4096) # Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. + num_pixel(NX_NUMBER): + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/num_pixel + + # link to Bias Spectroscopy>Z Avg time (s) (e.g. 100E-3) # Duration over which the Z + # position is recorded and averaged before and after the sweep (the latter only if Record + # final Z position is selected in the Advanced section). After the initial Z averaging + # time, if Z-Controller to Hold is selected in the Advanced section, the Z-Controller is + # set to hold and the tip is placed at the previously averaged Z position (plus Z offset). + z_avg_time(NX_NUMBER): + unit: NX_TIME + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_avg_time + + # link to SoftwareMain>RT Frequency (Hz) (e.g. 20E+3) # The bandwitdh of the + # Hardware and/or Software + rt_frequency(NX_NUMBER): + unit: NX_FREQUENCY + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/rt_frequency + + # link to SoftwareMain>Signals Oversampling (e.g. 10) # (Signals Periods) + # The Signals Period is the rate at which the signals are transferred to the host computer + # running the control software. This is usually lower by a factor of 10 than the sampling + # rate, because an internal oversampling of the signal is done on the real time engine. + # You can reduce the oversampling down to 1 in order to resolve higher frequencies in the + # Spectrum Analyzer. + signals_oversampling(NX_NUMBER): + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/signals_oversampling + + # link to SoftwareMain>Acquisition Period (s) (e.g. 20E-3) # Update rate for several + # processes like History Graph, Auto-Approach, and for many Programming Interface functions. + # This is usually set to 20 ms. All additional timings (7-9) can only be integer multiples + # of this value. They can be set to different values, but the actual timing value will be + # coerced to a multiple of the Acquisition Period. + acquisition_period(NX_NUMBER): + unit: NX_TIME + exists: optional + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/acquisition_period + + # link to SoftwareMain>Animations Period (s) (e.g. 20E-3) # Update rate of animated + # graphical indicators. These are e.g. some graphs & sliders. A reasonable value is + # 40 ms (25 updates per second). Increase this period to reduce the processor load + # for the graphical user interface, especially on slow computers. This value is purely a + # user interface update rate and does not affect measurements in any way. + animations_period(NX_NUMBER): + unit: NX_TIME + exists: optional + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/animations_period + + # link to SoftwareMain>Indicators Period (s) (e.g. 300E-3) # Update rate of digital + # indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per + # second, or 300 ms is enough. This value is purely a user interface update rate and + # does not affect measurements in any way. + indicators_period(NX_NUMBER): + unit: NX_TIME + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/indicators_period + + # link to SoftwareMain>Measurements Period (s) (e.g. 500E-3) # The Measurements + # period is the integration time for precise measurements (averaging over specified period), + # mostly used in sweep modules. Examples are recording of a force-distance curve or a + # resonance of a cantilever. For fast measurements with small steps, a value of 40 ms may be + # reasonable. For normal use, 300-500 ms is a good value, but for recording a resonance of a + # high-Q cantilever, values of several seconds might be necessary. Usually this parameter doesn’t need to be set from this module; the sweep modules will set this value according to the sweep timings. + measurements_period(NX_NUMBER): + exists: optional + unit: NX_TIME + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/measurements_period + + # TODO: Later fix REPRODUCIBILITY_indicator + # as all of the bellow are linked + reproducibility_indicators(NXprocess): + exists: optional + + # Bias>Bias(NXBias) (V) (e.g. 100E-3) # Applied bias voltage. + bias(NX_NUMBER): + unit: NX_VOLTAGE + doc: | + Link to target:/NXentry/NXinstrument/NXsample_bias/bias + + # Current>Current(NXcircuit) (A) (e.g. -5.3429E-15) # The tunneling current is displayed here. + current(NX_NUMBER): + unit: NX_CURRENT + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current + + # Bias>Calibration(NXbias) (V/V) (e.g. 1E+0) Calibration of the Bias output. If you have + # a Range switch the calibration is stored per range setting. + bias_calibration(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Link to target:/NXentry/NXnstrument/NXsample_bias/bias_calibration + bias_offset(NX_NUMBER): + unit: NX_VOLTAGE + doc: | + Link to target:/NXentry/NXinstrument/NXsample_bias/bias_offset + + # Current>Calibration(NXcircuit) (A/V) (e.g. 100E-12) + # The signals voltages are converted to real world physical values according to the calibration & offset parameters: + # Physical signal = (Voltage * calibration) + offset. + current_calibration(NX_NUMBER): + unit: NX_CURRENT + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_calibration + + # Current>Offset(NXcircuit) (A) (e.g. 16.2897E-15) # The same as "Current>Calibration (A/V)" tag + current_offset(NX_NUMBER): + unit: NX_CURRENT + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_offset + + # Current>Gain(NXcircuit) (e.g. Not switchable) # None + current_gain(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_gain + + # Z offset(NXpositioner_sts) (m) (e.g. 0E+0) # Offset added to the initial averaged position + # Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is + # deselected in the Advanced section. The LED “Alt” next to the Z offset indicates if an + # alternate Z-controller setpoint is enabled. + + # Settling time(NXbias) (s) (e.g. 2.1E-3) Time to wait after changing the bias to the next + # level and before starting to acquire data. Adjust this parameter to avoid transient + # effect induced by the bias change. Integration time: time during which the data are + # acquired and averaged. + z_offset(NX_NUMBER): + unit: NX_LENGTH + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_offset + settling_time(NX_NUMBER): + unit: NX_TIME + exists: optional + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/settling_time + + # Z-Ctrl hold(NXpositioner_sts) (e.g. TRUE) # When selected, the Z-Controller is set to hold + # during the pulse. This means that the controller doesn't control the Z position during the pulse. + z_control_hold(NX_BOOLEAN): + exists: optional + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_ccontroller_hold + + # Final Z(NXpositioner_sts) (m) (e.g. N/A) + final_z(NX_NUMBER): + unit: NX_LENGTH + exists: optional + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/record_final_z + + # Start time(NXlog) (e.g.23.11.2022 18:55:16) # Timestamp of the moment + # when the acquisition starts by pressing the Start button. + # TODO: no available concept is found for the below link + # start_time(link): + # exists: optional + # Link to t target: none + # Bias Spectroscopy>1st Settling time(NXbias) (s) (e.g.2.1E-3) # See the "Settling time (s)" below. + first_settling_time(NX_NUMBER): + unit: NX_TIME + exists: optional + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/first_settling_time + + # Bias Spectroscopy>Integration time(NXbias) (s) (e.g.150E-6) # Time during which the data + # are acquired and averaged. + # integration_time(link): + # Link to ttarget: /ENTRY[entry]/INSTRUMENT[instrument]/ENVIRONMENT[environment]/sweep_control/bias_spectroscopy/integration_time + # Bias Spectroscopy>End Settling time(NXbias) (s) (e.g.4E-3) # Time to wait after the sweep has finished and the bias is ramped to the initial value. + end_settling_time(NX_NUMBER): + unit: NX_TIME + exists: optional + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/end_settling_time + + # Bias Spectroscopy>Z control time(NXbias) (s) (e.g.200E-3) # Time during which the + # Z-Controller is enabled once a sweep has finished. When averaging multiple sweeps + # (i.e. Sweeps>1), the Z-Controller is enabled for this duration between each sweep. + # After the last sweep, it will wait the specified time before continuing a running scan. + # This ensures each sweep reliably starts from the same position. This parameter is + # disabled when Z-Controller to Hold is deselected in the Advanced section. + z_control_time(NX_NUMBER): + unit: NX_TIME + exists: optional + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_control_time + + # Bias Spectroscopy>Max Slew rate(NXbias) (V/s) (e.g.1E+0) # Maximum rate at which + # the bias changes (before, during and after sweeping). + max_slew_rate(NX_NUMBER): + unit: NX_ANY + exists: optional + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/max_slew_rate + + # Bias Spectroscopy>backward sweep(NXbias) (e.g.TRUE) # Select whether to measure + # the backward (return) sweep or the forward only. + backward_sweep(NX_NUMBER): + unit: NX_ANY + exists: optional + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/backward_sweep + + # Z-Controller>Controller name(NXpositioner_sts) (e.g.log Current) # Controller name. + # This name which will be displayed at places where you can select a controller. + z_controller_name: + exists: optional + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/controller_name + + # Z-Controller>Controller status(NXpositioner_sts) (e.g.OFF) # ON/OFF + z_controller_status(NX_BOOLEAN): + exists: optional + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/controller_status + + # Z-Controller>Setpoint(NXpositioner_sts) (e.g.50E-12) # Set Point is the desired value + # of the control signal. It can be set by editing the number or using the slider bar. + # Click the "Set" button above the input field to use the actual value as Set Point. The slider shows the Set Point as well as the current value. + # Z-Controller>Setpoint unit(NXpositioner_sts) (e.g.A) # Angstrom + z_controller_setpoint(NX_NUMBER): + unit: NX_CURRENT + exists: optional + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/set_point + + # Z-Controller>P gain(NXpid) (e.g.6E-12) # The Type switches controller parameters + # between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). + # The formula for the controller in the frequency domain is: G(s) = P + I/s = P(1 + 1/(Ts)). + # The integral gain and time constant are related as follows: I = P/T. + y_control_p_gain(NX_NUMBER): + exists: optional + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/p_gain + + # Z-Controller>I gain(NXpid) (e.g.39.8241E-9) # See "Z-Controller>P gain" below. + z_control_i_gain(NX_NUMBER): + exists: optional + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/i_gain + + # Z-Controller>Time const(NXpid) (s) (e.g.150.662E-6) # See "Z-Controller>P gain" below. + z_control_time_const(NX_NUMBER): + unit: NX_TIME + exists: optional + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/time_const + + # Z-Controller>TipLift(NXpositioner_sts) (m) (e.g.0E+0) # Lifts the tip by the specified + # amount when then controller is switched off. This can be a positive or a negative number, + # i.e. the tip can also be moved towards the sample. Be careful with sign and value when + # using this feature. + z_control_tip_lift(NX_NUMBER): + unit: NX_LENGTH + exists: optional + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/tip_lift + + # Z-Controller>Switch off delay(NXpositioner_sts) (s) (e.g.0E+0) # Use this parameter for + # a reproducible position when switching off the Z-controller. When >0 and the Z-controller + # is switched off, it doesn't switch off immediately but continues to run for the specified time and averages the Z position. + z_control_switchoff_delay(NX_NUMBER): + unit: NX_TIME + exists: optional + doc: | + Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/switchoff_delay + sample(NXsample): + exists: optional + doc: | + To describe sample and other constaints that applied on sample before scanning. + sample_prep_descripton: + doc: | + At this moment no base class available that can track entire sample preparation. + + # TODO: discuss convertion data to DATA + (NXdata): + doc: | + This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. + There should also be two more fields called temperature and voltage containing the setpoint values. + There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension + equal to the number of voltage setpoints. + axes: bias_calc + signals: + li_demod_[1;2]_[X/Y]_[-;bwd;filt;bwd_filt] + current_[-;bwd;filt;bwd_filt] + temperature + x + y + z + + # DATA # multi dimensional array: multi I-V array per scan point; + # doc: The format of the data here is similar to a column matrix. + # Bias calc (V) #scanning parameter + # Current (A) # current during forward direction scanning of bias - original NXsensor + # LI Demod 2 X (A) lockin (NXsensor+lockin) + # LI Demod 2 Y (A) lockin + # LI Demod 1 X (A) lockin + # LI Demod 1 Y (A) lockin + # Current [bwd] (A) #bwd - backward (the positive direction shall be clarified by the reference bias scanning frame. Fwd means from left(neg) to right(pos). In the scannig image, the bottom(neg) to top(pos), the left(neg) to right(pos) + # LI Demod 2 X [bwd] (A) lockin + # LI Demod 2 Y [bwd] (A) lockin + # LI Demod 1 X [bwd] (A) lockin + # LI Demod 1 Y [bwd] (A) lockin + # Current (A) [filt] # forward direction (maybe from lockin#2?) + # LI Demod 2 X (A) [filt] lockin + # LI Demod 2 Y (A) [filt] lockin + # LI Demod 1 X (A) [filt] lockin + # LI Demod 1 Y (A) [filt] lockin + # Current (A) [bwd] [filt] + # LI Demod 2 X (A) [bwd] [filt] lockin + # LI Demod 2 Y (A) [bwd] [filt] lockin + # LI Demod 1 X (A) [bwd] [filt] lockin + # LI Demod 1 Y (A) [bwd] [filt] lockin + # Temperature + # x + # y + # z + # single point default plot # current(I) vs bias(V) + single_point(NXdata): + exists: optional + + # line scan default plot # multi I vs. V curves + line_scan(NXdata): + exists: optional + + # alternative plot # current(I) curve in the 2D space of (position(x), bias(V)) + alternative_plot(NXdata): + exists: optional + + # mesh scan default plot # 2D slices of the above alternative plot + mesh_scan(NXdata): + exists: optional + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 39a08f3d1a71d0ce3410e2ed1aed76a7250f94c8681a93d063c95f5966f79b9d +# +# +# +# +# +# +# Application definition for temperature-dependent IV curve measurements +# #2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the +# STM image mode in the future with a focus on bias spectroscopy in Scanning Tunneling Microscopy. +# +# In this application definition, times should be specified always together with a UTC offset. +# +# This is the application definition describing temperature (T) dependent current voltage (IV) curve +# measurements. For this, a temperature is set. After reaching the temperature, a voltage sweep +# is performed. For each voltage, a current is measured. +# Then, the next desired temperature is set and an IV measurement is performed. +# The data can be visualized in a tensor with: +# I (NXsensor_C, NXsoftware_Read_offset, NXcircuit) +# parameters: +# V has (NXsource+offset, NXsoftware_Scan_offset, NXsensor_V, NXcircuit) +# T has (NXsource, NXsoftware_Scan_offset, NXsensor_T) +# x has (NXsoftware_Scan_offset) +# y has (NXsoftware_Scan_offset) +# z has (NXsoftware_Scan_offset) +# +# +# +# +# +# +# +# +# +# Name of the experiment where the application is applicable. +# +# +# +# +# +# +# +# +# The equipments and techniques as well as the parameter settings and reference signals +# are used during the experiments used in Scanning Tunneling Microscopy (STM). +# +# +# +# +# +# +# +# +# +# +# The name of the output file, with the number of scans at the end. (e.g. +# 221122_Au_5K00014) +# +# +# +# +# The name of the series output file, which represents only the public part of the +# output file. (e.g. 221122_Au_5K) +# +# +# +# +# Path to storage of output files. +# (e.g. Path C:\Users\SPM-PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis-Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711) +# +# +# +# +# Descriptive comments for this experiment, added by the experimenter, coming from the +# output file. (e.g. Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, locked Au(111), +# 50pA, 100 mV set point, 1mV DCA, 973Hz,138 1st H, -84 2nd H) +# +# +# +# +# +# Hardware type used in SPM experiment, includes hardware manufacturers and type. +# (e.g. Nanonis BP5e) +# +# +# +# +# +# Type of software used in SPM experiments, such as software version serial number, UI and +# RT probe release method. (e.g. SW Version Generic 5e -- RT Release 10771) +# +# +# +# Version of the software. +# +# +# +# +# +# +# The Amplifier description that improves or helps to determine tunnel current (current +# between tip and bias). +# +# +# +# +# +# +# Status of Lock-in device whether while performing the experiment +# +# +# +# +# +# This is the signal on which the modulation (sine) will be added. +# +# +# +# +# +# +# The signal is modulated by adding the frequency of the sine modulation. The +# modulation frequency spans can be from 10 mHz to 40 kHz, corresponding to the output filter +# cut-off range. When dealing with harmonics, it's essential to ensure that the +# harmonic frequencies remain below ~100 kHz, which aligns with the input filter cut-off. +# Be mindful that hardware filters might impact the amplitude as the signal approaches +# their cut-off frequencies." (e.g. 973E+0) +# +# +# +# +# +# The amplitude (in physical units of modulated signal) of the sine modulation. +# +# +# +# +# +# The input signal (STS signal) will be demodulated, in order to determine the amplitude +# and phase at the frequency set in the Frequency field or harmonics, such as current, +# bias, et.al. +# +# +# +# +# +# N denotes 1 or 2. The order of the harmonic oscillation to be detected in the demodulated +# signal should be considered relative to the modulation frequency. When dealing with +# higher harmonics, it's essential to ensure that their frequencies do not surpass +# the analogue signal bandwidth (e.g. harmonic_order_1). +# +# +# +# +# +# Reference phase for the sine on the demodulated signal with respect to the +# modulation signal. The determined phase is displayed with respect to the +# reference phase. +# +# +# +# +# +# +# +# +# Applied a voltage between tip and sample. +# +# +# +# +# +# +# +# +# Temperature of STM head. Note: At least one field from stm_head_temperature, +# cryo_bottom_temp and cryo_sheild_temp must be provided. +# +# +# +# +# Temperature of liquid helium cryostat. Note: At least one field from +# stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp must be provided. +# +# +# +# +# Temperature of liquid nitrogen shield. Temperature 3 (K) (e.g 78.00000E+0). Note: At +# least one field from stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp +# must be provided. +# +# +# +# +# +# +# Configuration for piezoelectric scanner used to move tip along X and Y direction. The +# material of the Piezoelectric scanner composed of polycrystalline solids and sensitive to +# applied voltage. +# +# +# +# The name of calibration type. (e.g. LHe) +# +# +# +# +# N denotes X or Y or Z. There are three parameters in the X, Y, and Z directions, +# along with three available controls: Calibration (m/V), Range (m), and HV gain. Only +# two of these parameters are required to define the calibration. Consequently, when any +# value is changed, one of the other values will be automatically updated. (e.g. calib_X = 3.8E-9) +# +# +# +# +# N denotes X or Y or Z. In some systems, there is an HV gain readout feature. For +# these systems, the HV gain should be automatically adjusted whenever the gain is +# changed at the high voltage amplifier. (e.g. 14.5) +# +# +# +# +# +# N denotes X or Y. There are 2 parameters in X and Y directions, and tilt needs to be +# adjusted according to the actual surface. (in degrees, first order correction). +# +# +# +# +# +# N denotes X or Y. There are 2 parameters in X and Y directions. (can be set +# approximately to the length of the piezotube). +# +# +# +# +# N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, +# you can enter the 2nd order piezo characteristics to compensate for it. The +# following equation shows the interpretation of the 2nd order correction parameter: +# For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: +# [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx +# is the 2nd order correction. (V/m^2). (e.g. 0E+0) +# +# +# +# +# N denotes X, Y or Z. There are 3 parameters in X, Y and Z directions. Define the +# drift speed for all three axes. When the compensation is on, the piezos will start to +# move at that speed. (e.g. 0E+0) +# +# +# +# +# Use the button to enable or disable the drift compensation. (e.g. FALSE) +# +# +# +# +# +# Describes an environment setup for a temperature-dependent IV measurement experiment. +# The temperature and voltage must be present as independently scanned controllers and +# the current sensor must also be present with its readings. +# +# +# +# +# This is set-point of tip current (in the constant current mode should be equal to set-point, +# in the constant height mode means the real tunnelling current between tip and sample). +# +# +# +# +# Value of calibration that comes as A/V. +# +# +# +# +# +# +# +# +# +# Clarify the frame laboratory frame. +# +# +# +# The scanning area in x position in the frame. (e.g. -890.53E-12) +# +# +# +# +# The scanning area in y position in the frame. (e.g. 29.6968E-9) +# +# +# +# +# The scanning area in z position in the frame. (e.g. 130.5E-9) +# +# +# +# +# +# Indicate the relative tip position z between tip and sample. The tip position can also +# be varied when the z_controller is not running. (e.g. 130.5E-9) +# +# +# +# +# +# +# +# +# +# Time during which the spectroscopy data are acquired and averaged. (e.g. 150E-6) +# +# +# +# +# Number of sweeps to measure and average. (e.g. 100) +# +# +# +# +# The start bias values of the sweep. (e.g. -300E-3) +# +# +# +# +# The end bias values of the sweep. (e.g. 300E-3) +# +# +# +# +# The sweep number of points is defined as the maximum spectrum resolution, which +# is equal to the bias sweep window divided by the number of pixels. (e.g. 4096) +# +# +# +# +# The Z position is recorded and averaged for a certain duration both before and +# after the sweep. After the initial Z averaging time, if "Z-Controller to Hold" +# is selected, the Z-Controller is set to hold mode, and the tip is positioned at +# the previously averaged Z position (adjusted by the Z offset). (e.g. 100E-3) +# +# +# +# +# +# +# The bandwidth of the Hardware and/or Software is instrument specific. +# For example, Nanonis Generic 5 has 'RT Frequency' (e.g. 20E+3). +# +# +# +# +# The Signals Period represents the rate at which signals are transferred to +# the host computer, which operates the control software. This rate may +# be 10 times lower than the sampling rate, as the real-time engine internally +# oversamples the signal. If desired, you may have the option to reduce the oversampling +# to 1, enabling higher frequency resolution in the Spectrum Analyzer. (e.g. 10) +# +# +# +# +# The update rate is utilized in various processes, including the History Graph, +# Auto-Approach, and multiple Programming Interface functions. It may be +# configured to a 20 ms interval. Any additional timings must strictly be integer +# multiples of this base value. While it is possible to set these additional +# timings to different values, the actual timing value will automatically be +# adjusted to become a multiple of the Acquisition Period. (e.g. 20E-3) +# +# +# +# +# The update rate of animated graphical indicators, such as graphs and sliders, +# can be adjusted. A normal value may be 40 ms, which corresponds to 25 updates +# per second. Increasing this period can help reduce the processor load on the +# graphical user interface, particularly on slower computers. It is important to +# note that this update rate solely impacts the user interface and does not affect +# measurements in any manner. (e.g. 20E-3) +# +# +# +# +# The update rate of digital indicators, such as the numbers displayed, can be set +# to 3 updates per second, equivalent to 300 ms. This interval is sufficient for +# the user interface and does not impact measurements in any manner. (e.g. 300E-3) +# +# +# +# +# The Measurements period determines the integration time required for precise +# measurements, primarily utilized in sweep modules. It is particularly useful for +# tasks such as recording force-distance curves or cantilever resonances. For +# swift measurements with small steps, a value of 40 ms is often adequate. For +# regular use, a range of 300-500 ms may be recommended, but when capturing the +# resonance of a high-Q cantilever, longer values in the range of several seconds +# might be necessary. Usually, this parameter does not require manual adjustment +# within this module, as the sweep modules automatically set this value according +# to the sweep timings. (e.g. 500E-3) +# +# +# +# +# +# +# +# +# +# Also clarify the frame for the ROI of the scan in lab frame, the middle of the lab +# frame is (0, 0), and positive in x means right and in y means up. +# +# +# +# +# +# +# The scan channels are selected by users. (e.g. (A);Bias (V);Z (m);LI Demod 2 X +# (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A)) +# +# +# +# +# +# +# Configure the scan frame like x position; y position; width; height. (e.g. +# 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0) +# +# +# +# +# Scan resolution by setting the Lines equal to Pixels. (e.g. 512) +# +# +# +# +# Define the image resolution. (e.g. 512) +# +# +# +# +# Define the scan forward speed in the forward direction. (m/s) (e.g. 11.7187E-9) +# +# +# +# +# Define the scan backward speed in the forward direction. (m/s) (e.g. 11.7187E-9) +# +# +# +# +# +# +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/stm_head_temp +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/cryo_bottom_temp +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/temp_cryo_shield +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXlock_in/modulation_signal +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/NXintegration_time +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/number_of_sweeps +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/sweep_start +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/sweep_end +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/num_pixel +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_avg_time +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/rt_frequency +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/signals_oversampling +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/acquisition_period +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/animations_period +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/indicators_period +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/measurements_period +# +# +# +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXsample_bias/bias +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current +# +# +# +# +# +# Link to target:/NXentry/NXnstrument/NXsample_bias/bias_calibration +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXsample_bias/bias_offset +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_calibration +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_offset +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_gain +# +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_offset +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/settling_time +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_ccontroller_hold +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/record_final_z +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/first_settling_time +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/end_settling_time +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_control_time +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/max_slew_rate +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/backward_sweep +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/controller_name +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/controller_status +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/set_point +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/p_gain +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/i_gain +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/time_const +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/tip_lift +# +# +# +# +# +# +# Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/switchoff_delay +# +# +# +# +# +# To describe sample and other constaints that applied on sample before scanning. +# +# +# +# At this moment no base class available that can track entire sample preparation. +# +# +# +# +# +# +# This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. +# There should also be two more fields called temperature and voltage containing the setpoint values. +# There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension +# equal to the number of voltage setpoints. +# axes: bias_calc +# signals: +# li_demod_[1;2]_[X/Y]_[-;bwd;filt;bwd_filt] +# current_[-;bwd;filt;bwd_filt] +# temperature +# x +# y +# z +# +# +# +# +# +# +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXsubsampling_filter.yaml b/contributed_definitions/nyaml/NXsubsampling_filter.yaml new file mode 100644 index 0000000000..bd41ca04ff --- /dev/null +++ b/contributed_definitions/nyaml/NXsubsampling_filter.yaml @@ -0,0 +1,71 @@ +category: base +doc: | + Settings of a filter to sample entries based on their value. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXsubsampling_filter(NXobject): + linear_range_min_incr_max(NX_UINT): + unit: NX_UNITLESS + doc: | + Triplet of the minimum, increment, and maximum value which will + be included in the analysis. The increment controls which n-th entry to take. + + Take as an example a dataset with 100 entries (their indices start at zero) + and the filter set to 0, 1, 99. This will process each entry. + 0, 2, 99 will take each second entry. 90, 3, 99 will take only each third + entry beginning from entry 90 up to 99. + dimensions: + rank: 1 + dim: [[1, 3]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 8b2ae0d8e8fbb65aa0b1e6f7cf5ea78417bf28ad83373f3401b159c41ef7c24c +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays. +# +# +# +# Settings of a filter to sample entries based on their value. +# +# +# +# Triplet of the minimum, increment, and maximum value which will +# be included in the analysis. The increment controls which n-th entry to take. +# +# Take as an example a dataset with 100 entries (their indices start at zero) +# and the filter set to 0, 1, 99. This will process each entry. +# 0, 2, 99 will take each second entry. 90, 3, 99 will take only each third +# entry beginning from entry 90 up to 99. +# +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXsubstance.yaml b/contributed_definitions/nyaml/NXsubstance.yaml new file mode 100644 index 0000000000..49995f8ab4 --- /dev/null +++ b/contributed_definitions/nyaml/NXsubstance.yaml @@ -0,0 +1,193 @@ +category: base +doc: | + A form of matter with a constant, definite chemical composition. + + Examples can be single chemical elements, chemical compunds, or alloys. + For further information, see https://en.wikipedia.org/wiki/Chemical_substance. +type: group +NXsubstance(NXobject): + name: + doc: | + User-defined chemical name of the substance + molecular_mass(NX_FLOAT): + unit: NX_MOLECULAR_WEIGHT + doc: | + Molecular mass of the substance + cas_number: + doc: | + Unique numeric CAS REGISTRY number of the sample chemical content + For further information, see https://www.cas.org/. + cas_name: + doc: | + CAS REGISTRY name of the sample chemical content + cas_uri: + doc: | + CAS REGISTRY URI + cas_image(NXnote): + doc: | + CAS REGISTRY image + cas_synonyms: + doc: | + Synonyms in the CAS system. + inchi_str: + doc: | + String InChi identifier. + The InChI identifier expresses chemical structures in terms of atomic connectivity, + tautomeric state, isotopes, stereochemistry and electronic charge in order to + produce a string of machine-readable characters unique to the respective molecule. + For further information, see https://iupac.org/who-we-are/divisions/division-details/inchi/. + inchi_key: + doc: | + Condensed, 27 character InChI key. + Hashed version of the full InChI (using the SHA-256 algorithm). + iupac_name: + doc: | + Name according to the IUPAC system (standard). + For further information, see https://iupac.org/. + smile: + doc: | + Identifier in the SMILES (Simplified Molecular Input Line Entry System) system + For further information, see https://www.daylight.com/smiles/. + canonical_smile: + doc: | + Canonical version of the smiles identifier + molecular_formula_hill: + doc: | + The chemical formula specified using CIF conventions. + Abbreviated version of CIF standard:107 + This is the *Hill* system used by Chemical Abstracts. + + * Only recognized element symbols may be used. + * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. + * A space or parenthesis must separate each cluster of (element symbol + count). + * Where a group of elements is enclosed in parentheses, the multiplier for the + group must follow the closing parentheses. That is, all element and group + multipliers are assumed to be printed as subscripted numbers. + * Unless the elements are ordered in a manner that corresponds to their chemical + structure, the order of the elements within any group or moiety depends on + whether or not carbon is present. + * If carbon is present, the order should be: + - C, then H, then the other elements in alphabetical order of their symbol. + - If carbon is not present, the elements are listed purely in alphabetic order of their symbol. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# edfde06a5e9cb004cef553235a02e7a35aac1e9609544c7238f3cffdc3664760 +# +# +# +# +# +# A form of matter with a constant, definite chemical composition. +# +# Examples can be single chemical elements, chemical compunds, or alloys. +# For further information, see https://en.wikipedia.org/wiki/Chemical_substance. +# +# +# +# User-defined chemical name of the substance +# +# +# +# +# Molecular mass of the substance +# +# +# +# +# Unique numeric CAS REGISTRY number of the sample chemical content +# For further information, see https://www.cas.org/. +# +# +# +# +# CAS REGISTRY name of the sample chemical content +# +# +# +# +# CAS REGISTRY URI +# +# +# +# +# CAS REGISTRY image +# +# +# +# +# Synonyms in the CAS system. +# +# +# +# +# String InChi identifier. +# The InChI identifier expresses chemical structures in terms of atomic connectivity, +# tautomeric state, isotopes, stereochemistry and electronic charge in order to +# produce a string of machine-readable characters unique to the respective molecule. +# For further information, see https://iupac.org/who-we-are/divisions/division-details/inchi/. +# +# +# +# +# Condensed, 27 character InChI key. +# Hashed version of the full InChI (using the SHA-256 algorithm). +# +# +# +# +# Name according to the IUPAC system (standard). +# For further information, see https://iupac.org/. +# +# +# +# +# Identifier in the SMILES (Simplified Molecular Input Line Entry System) system +# For further information, see https://www.daylight.com/smiles/. +# +# +# +# +# Canonical version of the smiles identifier +# +# +# +# +# The chemical formula specified using CIF conventions. +# Abbreviated version of CIF standard:107 +# This is the *Hill* system used by Chemical Abstracts. +# +# * Only recognized element symbols may be used. +# * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. +# * A space or parenthesis must separate each cluster of (element symbol + count). +# * Where a group of elements is enclosed in parentheses, the multiplier for the +# group must follow the closing parentheses. That is, all element and group +# multipliers are assumed to be printed as subscripted numbers. +# * Unless the elements are ordered in a manner that corresponds to their chemical +# structure, the order of the elements within any group or moiety depends on +# whether or not carbon is present. +# * If carbon is present, the order should be: +# - C, then H, then the other elements in alphabetical order of their symbol. +# - If carbon is not present, the elements are listed purely in alphabetic order of their symbol. +# +# +# diff --git a/contributed_definitions/nyaml/NXtransmission.yaml b/contributed_definitions/nyaml/NXtransmission.yaml new file mode 100644 index 0000000000..b4ec2b439b --- /dev/null +++ b/contributed_definitions/nyaml/NXtransmission.yaml @@ -0,0 +1,607 @@ +category: application +doc: | + Application definition for transmission experiments +symbols: + doc: | + Variables used throughout the experiment + N_wavelengths: | + Number of wavelength points + N_scans: | + Number of scans + +# FAIRmat consortium 21.07.2022 +# Draft NeXus application definition for transmission experiments +type: group +NXtransmission(NXobject): + (NXentry): + doc: | + This application definition + definition: + doc: | + An application definition for transmission. + \@version: + doc: | + Version number to identify which definition of this application definition was + used for this entry/data. + \@url: + doc: | + URL where to find further material (documentation, examples) relevant to the + application definition. + enumeration: [NXtransmission] + start_time(NX_DATE_TIME): + doc: | + Start time of the experiment. + experiment_identifier(NX_CHAR): + doc: | + Unique identifier of the experiment, such as a (globally persistent) + unique identifier. + + * The identifier is usually defined by the facility or principle + investigator. + * The identifier enables to link experiments to e.g. proposals. + experiment_description(NX_CHAR): + exists: optional + doc: | + An optional free-text description of the experiment. However, details of the + experiment should be defined in the specific fields of this application + definition rather than in this experiment description. + + # TODO: Just used a NXmanufacturer, maybe + # it is nicer to introduce a general NXprogram class? + # However, a program may also be viewed as some sort + # of instrument. + acquisition_program(NXfabrication): + exists: optional + model(NX_CHAR): + doc: | + Commercial or otherwise defined given name to the program that was + used to generate the result file(s) with measured data and metadata. + identifier(NX_CHAR): + doc: | + Version number of the program that was used to generate the result + file(s) with measured data and metadata. + \@url: + type: NX_CHAR + exists: recommended + doc: | + Website of the software + operator(NXuser): + exists: ['min', '1'] + doc: | + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + name: + doc: | + Name of the user. + affiliation: + doc: | + Name of the affiliation of the user at the point in time when the experiment was + performed. + address: + doc: | + Street address of the user's affiliation. + email: + doc: | + Email address of the user. + url: + exists: recommended + doc: | + Author ID defined by reasearch id services, e.g. orcid (https://orcid.org/). + telephone_number: + exists: recommended + doc: | + Telephone number of the user. + instrument(NXinstrument): + manufacturer(NXfabrication): + exists: recommended + doc: | + Manufacturer of the instrument. + common_beam_mask(NXslit): + doc: | + Common beam mask to shape the incident beam + y_gap(NX_NUMBER): + unit: NX_UNITLESS + doc: | + The height of the common beam in percentage of the beam + common_beam_depolarizer(NX_BOOLEAN): + doc: | + If true, the incident beam is depolarized. + polarizer(NX_NUMBER): + unit: NX_ANGLE + doc: | + Polarizer value inside the beam path + ref_attenuator(NXattenuator): + doc: | + Attenuator in the reference beam + attenuator_transmission(NX_FLOAT): + sample_attenuator(NXattenuator): + doc: | + Attenuator in the sample beam + attenuator_transmission(NX_FLOAT): + spectrometer(NXmonochromator): + wavelength(NX_NUMBER): + unit: NX_LENGTH + doc: | + Wavelength value(s) used for the measurement. + An array of 1 or more elements. Length defines N_wavelenghts + dimensions: + rank: 1 + dim: [[1, N_wavelengths]] + spectral_resolution(NX_NUMBER): + exists: optional + unit: NX_WAVENUMBER + doc: | + Overall spectral resolution of this spectrometer. + If several gratings are employed the spectral resoultion + should rather be specified for each grating inside the + NXgrating group of this spectrometer. + (NXgrating): + exists: optional + doc: | + Diffraction grating, as could be used in a monochromator. + If two or more gratings were used, define the angular + dispersion and the wavelength range (min/max wavelength) + for each grating and make sure that the wavelength ranges + do not overlap. The dispersion should be defined for the + entire wavelength range of the experiment. + angular_dispersion(NX_NUMBER): + exists: optional + doc: | + Dispersion of the grating in nm/mm used. + blaze_wavelength(NX_NUMBER): + exists: optional + unit: NX_LENGTH + doc: | + The blaze wavelength of the grating used. + spectral_resolution(NX_NUMBER): + exists: optional + unit: NX_WAVENUMBER + doc: | + Overall spectral resolution of the instrument + when this grating is used. + wavelength_range(NX_NUMBER): + unit: NX_LENGTH + doc: | + Wavelength range in which this grating was used + dimensions: + rank: 1 + dim: [[1, 2]] + (NXdetector): + wavelength_range(NX_NUMBER): + unit: NX_LENGTH + doc: | + Wavelength range in which this detector was used + dimensions: + rank: 1 + dim: [[1, 2]] + type(NX_CHAR): + doc: | + Detector type + enumeration: [PMT, PbS, InGaAs] + response_time(NX_NUMBER): + exists: optional + unit: NX_TIME + doc: | + Response time of the detector + gain(NX_NUMBER): + exists: optional + doc: | + Detector gain + slit(NXslit): + doc: | + Slit setting used for measurement with this detector + type(NX_CHAR): + enumeration: [fixed, servo] + time_points(NX_NUMBER): + exists: optional + unit: NX_TIME + doc: | + An array of relative scan start time points. + dimensions: + rank: 1 + dim: [[1, N_scans]] + measured_data(NX_NUMBER): + doc: | + Resulting data from the measurement. + The length of the 2nd dimension is + the number of time points. + If it has length one the time_points + may be empty. + dimensions: + rank: 2 + dim: [[1, N_scans], [2, N_wavelengths]] + (NXsource): + doc: | + The lamp used for illumination + type(NX_CHAR): + doc: | + The type of lamp, e.g. halogen, D2 etc. + enumeration: [halogen, D2] + spectrum(NX_NUMBER): + exists: optional + doc: | + The spectrum of the lamp used + dimensions: + rank: 1 + dim: [[1, N_wavelengths]] + wavelength_range(NX_NUMBER): + unit: NX_LENGTH + doc: | + Wavelength range in which the lamp was used + dimensions: + rank: 1 + dim: [[1, 2]] + (NXsample): + + # TODO: This should be extended by a generic + # NXsample class. + doc: | + Properties of the sample measured + name(NX_CHAR): + data(NXdata): + doc: | + A default view of the data emitted intensity vs. wavelength. + From measured_data plot intensity and wavelength. + \@axes: + doc: | + We recommend to use wavelength as a default attribute, but it can be + replaced by any suitable parameter along the X-axis. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 8e44140527b6ce26fe9832c663c9074067ec6c8ecfdb137c8740677c772749f8 +# +# +# +# +# +# +# +# Variables used throughout the experiment +# +# +# +# Number of wavelength points +# +# +# +# +# Number of scans +# +# +# +# +# Application definition for transmission experiments +# +# +# +# This application definition +# +# +# +# An application definition for transmission. +# +# +# +# Version number to identify which definition of this application definition was +# used for this entry/data. +# +# +# +# +# URL where to find further material (documentation, examples) relevant to the +# application definition. +# +# +# +# +# +# +# +# +# Start time of the experiment. +# +# +# +# +# Unique identifier of the experiment, such as a (globally persistent) +# unique identifier. +# +# * The identifier is usually defined by the facility or principle +# investigator. +# * The identifier enables to link experiments to e.g. proposals. +# +# +# +# +# An optional free-text description of the experiment. However, details of the +# experiment should be defined in the specific fields of this application +# definition rather than in this experiment description. +# +# +# +# +# +# +# Commercial or otherwise defined given name to the program that was +# used to generate the result file(s) with measured data and metadata. +# +# +# +# +# Version number of the program that was used to generate the result +# file(s) with measured data and metadata. +# +# +# +# +# Website of the software +# +# +# +# +# +# Contact information of at least the user of the instrument or the investigator +# who performed this experiment. Adding multiple users if relevant is recommended. +# +# +# +# Name of the user. +# +# +# +# +# Name of the affiliation of the user at the point in time when the experiment was +# performed. +# +# +# +# +# Street address of the user's affiliation. +# +# +# +# +# Email address of the user. +# +# +# +# +# Author ID defined by reasearch id services, e.g. orcid (https://orcid.org/). +# +# +# +# +# Telephone number of the user. +# +# +# +# +# +# +# Manufacturer of the instrument. +# +# +# +# +# Common beam mask to shape the incident beam +# +# +# +# The height of the common beam in percentage of the beam +# +# +# +# +# +# If true, the incident beam is depolarized. +# +# +# +# +# Polarizer value inside the beam path +# +# +# +# +# Attenuator in the reference beam +# +# +# +# +# +# Attenuator in the sample beam +# +# +# +# +# +# +# Wavelength value(s) used for the measurement. +# An array of 1 or more elements. Length defines N_wavelenghts +# +# +# +# +# +# +# +# Overall spectral resolution of this spectrometer. +# If several gratings are employed the spectral resoultion +# should rather be specified for each grating inside the +# NXgrating group of this spectrometer. +# +# +# +# +# Diffraction grating, as could be used in a monochromator. +# If two or more gratings were used, define the angular +# dispersion and the wavelength range (min/max wavelength) +# for each grating and make sure that the wavelength ranges +# do not overlap. The dispersion should be defined for the +# entire wavelength range of the experiment. +# +# +# +# Dispersion of the grating in nm/mm used. +# +# +# +# +# The blaze wavelength of the grating used. +# +# +# +# +# Overall spectral resolution of the instrument +# when this grating is used. +# +# +# +# +# Wavelength range in which this grating was used +# +# +# +# +# +# +# +# +# +# +# Wavelength range in which this detector was used +# +# +# +# +# +# +# +# Detector type +# +# +# +# +# +# +# +# +# +# Response time of the detector +# +# +# +# +# Detector gain +# +# +# +# +# Slit setting used for measurement with this detector +# +# +# +# +# +# +# +# +# +# +# +# An array of relative scan start time points. +# +# +# +# +# +# +# +# Resulting data from the measurement. +# The length of the 2nd dimension is +# the number of time points. +# If it has length one the time_points +# may be empty. +# +# +# +# +# +# +# +# +# The lamp used for illumination +# +# +# +# The type of lamp, e.g. halogen, D2 etc. +# +# +# +# +# +# +# +# +# The spectrum of the lamp used +# +# +# +# +# +# +# +# Wavelength range in which the lamp was used +# +# +# +# +# +# +# +# +# +# +# Properties of the sample measured +# +# +# +# +# +# A default view of the data emitted intensity vs. wavelength. +# From measured_data plot intensity and wavelength. +# +# +# +# We recommend to use wavelength as a default attribute, but it can be +# replaced by any suitable parameter along the X-axis. +# +# +# +# +# diff --git a/contributed_definitions/nyaml/NXunit_cell.yaml b/contributed_definitions/nyaml/NXunit_cell.yaml new file mode 100644 index 0000000000..4109b2333b --- /dev/null +++ b/contributed_definitions/nyaml/NXunit_cell.yaml @@ -0,0 +1,379 @@ +category: base +doc: | + Description of a unit cell, i.e., the crystal structure of a single + thermodynamic phase. +symbols: + n_pos: | + Number of atom positions. +type: group +NXunit_cell(NXobject): + crystallographic_database_identifier: + doc: | + Identifier of an entry resolvable via crystallographic_database + which was used for creating this structure model. + crystallographic_database: + doc: | + Name of the crystallographic database to resolve + crystallographic_database_identifier e.g. COD, ICSD, or others. + lattice_system: + doc: | + A lattice system is a group of lattices with the same set of lattice point groups. + For further information, see https://en.wikipedia.org/wiki/Crystal_system. + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + space_group: + doc: | + Crystallographic space group. + A space group is the symmetry group of a repeating pattern in space. + For further information, see International Table for Crystallography (https://it.iucr.org/). + point_group: + doc: | + Crystallographic point group. + A crystallographic point group is a set of symmetry operations, corresponding to one of the point groups in three dimensions, + such that each operation (perhaps followed by a translation) would leave the structure of a crystal unchanged. + This field should use Schoenflies notation (see Schoenflies, A., Krystallsysteme und Krystallstructur, 1891). + For further information, see https://dictionary.iucr.org/Point_group. + laue_group: + doc: | + Laue group (also called Laue class). + The Laue classes are eleven geometric crystal classes containing centrosymmetric crystallographic types of point groups and their subgroups. + When absorption is negligible and Friedel's law applies, it is impossible to distinguish by diffraction between a centrosymmetric point group + and one of its non-centrosymmetric subgroups; only point groups belonging to different Laue classes can then be distinguished. + For further information, see https://dictionary.iucr.org/Laue_class. + + # defined using which convention? + a_b_c(NX_FLOAT): + unit: NX_LENGTH + doc: | + Crystallography unit cell parameters a, b, and c + dimensions: + rank: 1 + dim: [[1, 3]] + base_vector_a(NX_FLOAT): + unit: NX_LENGTH + doc: | + Crystallography unit cell vector a + dimensions: + rank: 1 + dim: [[1, 3]] + \@depends_on: + doc: | + For definining which coordinate system the unit cell vector a is defined in. + base_vector_b(NX_FLOAT): + unit: NX_LENGTH + doc: | + Crystallography unit cell vector b + dimensions: + rank: 1 + dim: [[1, 3]] + \@depends_on: + doc: | + For definining which coordinate system the unit cell vector b is defined in. + base_vector_c(NX_FLOAT): + unit: NX_LENGTH + doc: | + Crystallography unit cell vector c + dimensions: + rank: 1 + dim: [[1, 3]] + \@depends_on: + doc: | + For definining which coordinate system the unit cell vector c is defined in. + alpha_beta_gamma(NX_FLOAT): + unit: NX_ANGLE + doc: | + Crystallography unit cell angles alpha, beta, and gamma + dimensions: + rank: 1 + dim: [[1, 3]] + volume(NX_FLOAT): + unit: NX_VOLUME + doc: | + Volume of the unit cell + + # add enumeration of all possible + is_centrosymmetric(NX_BOOLEAN): + doc: | + True if space group is considered a centrosymmetric one. + False if space group is considered a non-centrosymmetric one. + Centrosymmetric has all types and combinations of symmetry elements + (translation, rotational axis, mirror planes, center of inversion) + Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). + Chiral compared to non-centrosymmetric is constrained (no mirror planes). + is_chiral(NX_BOOLEAN): + doc: | + True if space group is considered a chiral one. + False if space group is consider a non-chiral one. + phase_identifier(NX_UINT): + unit: NX_UNITLESS + doc: | + Identifier for the phase. + The value 0 is reserved for the unknown phase which represents the null-model + that no phase model was sufficiently significantly confirmed. + phase_name: + doc: | + Trivial name of the phase/alias. + atom_identifier: + doc: | + Labels for each atom position + dimensions: + rank: 1 + dim: [[1, n_pos]] + atom(NX_UINT): + unit: NX_UNITLESS + doc: | + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) `_ + dimensions: + rank: 1 + dim: [[1, n_pos]] + atom_positions(NX_FLOAT): + unit: NX_LENGTH + doc: | + Atom positions x, y, z. + dimensions: + rank: 2 + dim: [[1, n_pos], [2, 3]] + \@depends_on: + doc: | + Reference to an instance of NXcoordinate_system whereby the positions can be + resolved. + atom_occupancy(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + Relative occupancy of the atom position. + dimensions: + rank: 1 + dim: [[1, n_pos]] + depends_on: + doc: | + For definining which coordinate system the unit cell parameters are defined in. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 4921c2e1993393e8f5cb0b44e3470cba5cf59b6d1a88c15ef3cec4f60ccee8f3 +# +# +# +# +# +# +# +# Number of atom positions. +# +# +# +# +# Description of a unit cell, i.e., the crystal structure of a single +# thermodynamic phase. +# +# +# +# Identifier of an entry resolvable via crystallographic_database +# which was used for creating this structure model. +# +# +# +# +# Name of the crystallographic database to resolve +# crystallographic_database_identifier e.g. COD, ICSD, or others. +# +# +# +# +# A lattice system is a group of lattices with the same set of lattice point groups. +# For further information, see https://en.wikipedia.org/wiki/Crystal_system. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Crystallographic space group. +# A space group is the symmetry group of a repeating pattern in space. +# For further information, see International Table for Crystallography (https://it.iucr.org/). +# +# +# +# +# Crystallographic point group. +# A crystallographic point group is a set of symmetry operations, corresponding to one of the point groups in three dimensions, +# such that each operation (perhaps followed by a translation) would leave the structure of a crystal unchanged. +# This field should use Schoenflies notation (see Schoenflies, A., Krystallsysteme und Krystallstructur, 1891). +# For further information, see https://dictionary.iucr.org/Point_group. +# +# +# +# +# Laue group (also called Laue class). +# The Laue classes are eleven geometric crystal classes containing centrosymmetric crystallographic types of point groups and their subgroups. +# When absorption is negligible and Friedel's law applies, it is impossible to distinguish by diffraction between a centrosymmetric point group +# and one of its non-centrosymmetric subgroups; only point groups belonging to different Laue classes can then be distinguished. +# For further information, see https://dictionary.iucr.org/Laue_class. +# +# +# +# +# +# Crystallography unit cell parameters a, b, and c +# +# +# +# +# +# +# +# Crystallography unit cell vector a +# +# +# +# +# +# +# For definining which coordinate system the unit cell vector a is defined in. +# +# +# +# +# +# Crystallography unit cell vector b +# +# +# +# +# +# +# For definining which coordinate system the unit cell vector b is defined in. +# +# +# +# +# +# Crystallography unit cell vector c +# +# +# +# +# +# +# For definining which coordinate system the unit cell vector c is defined in. +# +# +# +# +# +# Crystallography unit cell angles alpha, beta, and gamma +# +# +# +# +# +# +# +# Volume of the unit cell +# +# +# +# +# +# True if space group is considered a centrosymmetric one. +# False if space group is considered a non-centrosymmetric one. +# Centrosymmetric has all types and combinations of symmetry elements +# (translation, rotational axis, mirror planes, center of inversion) +# Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). +# Chiral compared to non-centrosymmetric is constrained (no mirror planes). +# +# +# +# +# True if space group is considered a chiral one. +# False if space group is consider a non-chiral one. +# +# +# +# +# Identifier for the phase. +# The value 0 is reserved for the unknown phase which represents the null-model +# that no phase model was sufficiently significantly confirmed. +# +# +# +# +# Trivial name of the phase/alias. +# +# +# +# +# Labels for each atom position +# +# +# +# +# +# +# +# The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` +# the number of protons and :math:`N` the number of neutrons +# of each isotope respectively. Z and N have to be 8-bit unsigned integers. +# For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ +# +# +# +# +# +# +# +# Atom positions x, y, z. +# +# +# +# +# +# +# +# Reference to an instance of NXcoordinate_system whereby the positions can be +# resolved. +# +# +# +# +# +# Relative occupancy of the atom position. +# +# +# +# +# +# +# +# For definining which coordinate system the unit cell parameters are defined in. +# +# +# diff --git a/contributed_definitions/nyaml/NXwaveplate.yaml b/contributed_definitions/nyaml/NXwaveplate.yaml new file mode 100644 index 0000000000..b23d9de71f --- /dev/null +++ b/contributed_definitions/nyaml/NXwaveplate.yaml @@ -0,0 +1,286 @@ +category: base +doc: | + A waveplate or retarder. +symbols: + N_spectrum: | + Size of the wavelength array for which the refractive index of the material + and/or coating is given. + N_wavelengths: | + Number of discrete wavelengths for which the waveplate is designed. If it + operates for a range of wavelengths then N_wavelengths = 2 and the minimum + and maximum values of the range should be provided. + +# A draft of a new base class to describe a waveplate +type: group +NXwaveplate(NXobject): + type: + doc: | + Type of waveplate (e.g. achromatic waveplate or zero-order waveplate). + + # A waveplate can be e.g. a dual-wavelength multi-order plate + # => multiple selection needs to be possible + enumeration: [zero-order waveplate, achromatic waveplate, multiple-order waveplate, dual-wavelength waveplate, other] + + # Are there any other common wave plate types? + other_type: + doc: | + If you selected 'other' in type describe what it is. + retardance: + doc: | + Specify the retardance of the waveplate (e.g. full-wave, half-wave + (lambda/2), quarter-wave (lambda/4) plate). + enumeration: [full-wave plate, half-wave plate, quarter-wave plate] + wavelengths(NX_NUMBER): + exists: recommended + doc: | + Discrete wavelengths for which the waveplate is designed. If the + waveplate operates over an entire range of wavelengths, enter the minimum + and maximum values of the wavelength range (in this case + N_wavelengths = 2). + dimensions: + rank: 1 + dim: [[1, N_wavelengths]] + diameter(NX_FLOAT): + unit: NX_LENGTH + doc: | + Diameter of the waveplate. + clear_aperture(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Clear aperture of the device (e.g. 90% of diameter for a disc or 90% of + length/height for square geometry). + + # Would it be better to provide the clear aperture as length? + substrate(NXsample): + doc: | + Describe the material of the substrate of the wave plate in + substrate/substrate_material and provide its index of refraction in + substrate/index_of_refraction_substrate, if known. + substrate_material: + doc: | + Specify the material of the wave plate. If the device has a + coating it should be described in coating/coating_material. + substrate_thickness(NX_NUMBER): + unit: NX_LENGTH + doc: | + Thickness of the wave plate substrate. + index_of_refration_substrate(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Complex index of refraction of the wave plate substrate. Specify at + given wavelength (or energy, wavenumber etc.) values. + dimensions: + rank: 2 + dim: [[1, 2], [2, N_spectrum]] + coating(NXsample): + doc: | + Is the wave plate coated? If yes, specify the type and material of the + coating and the wavelength range for which it is designed. If known, you + may also provide its index of refraction. + coating_type: + doc: | + Specify the coating type (e.g. dielectric, anti-reflection (AR), + multilayer coating etc.). + coating_material: + doc: | + Specify the coating material. + coating_thickness(NX_NUMBER): + unit: NX_LENGTH + doc: | + Thickness of the coating. + wavelength_range_coating(NX_NUMBER): + exists: recommended + doc: | + Wavelength range for which the coating is designed. Enter the minimum + and maximum values of the wavelength range. + dimensions: + rank: 1 + dim: [[1, 2]] + index_of_refraction_coating(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Complex index of refraction of the coating. Specify at given spectral + values (wavelength, energy, wavenumber etc.). + dimensions: + rank: 2 + dim: [[1, 2], [2, N_spectrum]] + reflectance(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Average reflectance of the waveplate in percentage. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 1084311acf55f71d1555553d11d9c7d6ec2c8339916f54dd2ab1cc6aeabcf603 +# +# +# +# +# +# +# +# +# Size of the wavelength array for which the refractive index of the material +# and/or coating is given. +# +# +# +# +# Number of discrete wavelengths for which the waveplate is designed. If it +# operates for a range of wavelengths then N_wavelengths = 2 and the minimum +# and maximum values of the range should be provided. +# +# +# +# +# A waveplate or retarder. +# +# +# +# Type of waveplate (e.g. achromatic waveplate or zero-order waveplate). +# +# +# +# +# +# +# +# +# +# +# +# +# +# If you selected 'other' in type describe what it is. +# +# +# +# +# Specify the retardance of the waveplate (e.g. full-wave, half-wave +# (lambda/2), quarter-wave (lambda/4) plate). +# +# +# +# +# +# +# +# +# +# Discrete wavelengths for which the waveplate is designed. If the +# waveplate operates over an entire range of wavelengths, enter the minimum +# and maximum values of the wavelength range (in this case +# N_wavelengths = 2). +# +# +# +# +# +# +# +# Diameter of the waveplate. +# +# +# +# +# Clear aperture of the device (e.g. 90% of diameter for a disc or 90% of +# length/height for square geometry). +# +# +# +# +# +# Describe the material of the substrate of the wave plate in +# substrate/substrate_material and provide its index of refraction in +# substrate/index_of_refraction_substrate, if known. +# +# +# +# Specify the material of the wave plate. If the device has a +# coating it should be described in coating/coating_material. +# +# +# +# +# Thickness of the wave plate substrate. +# +# +# +# +# Complex index of refraction of the wave plate substrate. Specify at +# given wavelength (or energy, wavenumber etc.) values. +# +# +# +# +# +# +# +# +# +# Is the wave plate coated? If yes, specify the type and material of the +# coating and the wavelength range for which it is designed. If known, you +# may also provide its index of refraction. +# +# +# +# Specify the coating type (e.g. dielectric, anti-reflection (AR), +# multilayer coating etc.). +# +# +# +# +# Specify the coating material. +# +# +# +# +# Thickness of the coating. +# +# +# +# +# Wavelength range for which the coating is designed. Enter the minimum +# and maximum values of the wavelength range. +# +# +# +# +# +# +# +# Complex index of refraction of the coating. Specify at given spectral +# values (wavelength, energy, wavenumber etc.). +# +# +# +# +# +# +# +# +# +# Average reflectance of the waveplate in percentage. +# +# +# diff --git a/contributed_definitions/nyaml/NXxpcs.yaml b/contributed_definitions/nyaml/NXxpcs.yaml new file mode 100644 index 0000000000..20dd211c91 --- /dev/null +++ b/contributed_definitions/nyaml/NXxpcs.yaml @@ -0,0 +1,1085 @@ +category: application +doc: | + X-ray Photon Correlation Spectroscopy (XPCS) data (results). + + The purpose of ``NXxpcs`` is to document and communicate an accepted vernacular for various XPCS results data + in order to support development of community software tools. The definition presented here only + represents a starting point and contains fields that a common software tool should support for + community acceptance. + + Additional fields may be added to XPCS results file (either formally or informally). It is expected + that this XPCS data will be part of multi-modal data set that could involve e.g., :ref:`NXcanSAS` or + 1D and/or 2D data. +symbols: + doc: | + The symbol(s) listed here will be used below to coordinate datasets with the same shape. + nP: | + Number of points +type: group +NXxpcs(NXobject): + (NXentry)entry: + definition: + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXxpcs] + entry_identifier: + doc: | + **Locally** unique identifier for the experiment (a.k.a. run or scan). + + * For bluesky users, this is the run's `"scan_id"`. + * For SPEC users, this is the scan number (``SCAN_N``). + entry_identifier_uuid: + exists: ['min', '0', 'max', '1'] + doc: | + (optional) UUID identifier for this entry. + + See the `UUID standard `__ (or + `wikipedia `__) + for more information. + + * For `bluesky `__ users, this is the + run's `"uid"` and is expected for that application. + * Typically, `SPEC `__ users will + not use this field without further engineering. + scan_number(NX_INT): + deprecated: Use the ``entry_identifier`` field. + + # Use of "deprecated" is to advise the XPCS authors of this change. + # The `scan_number` field will be removed by 2022-12-31. + doc: | + Scan number (must be an integer). + + NOTE: Link to collection_identifier. + start_time(NX_DATE_TIME): + doc: | + Starting time of experiment, such as "2021-02-11 11:22:33.445566Z". + end_time(NX_DATE_TIME): + exists: ['min', '0', 'max', '1'] + doc: | + Ending time of experiment, such as "2021-02-11 11:23:45Z". + (NXdata)data: + doc: | + The results data captured here are most commonly required for high throughput, equilibrium dynamics experiments. Data (results) + describing on-equilibrium dynamics consume more memory resources so these data are separated. + frame_sum(NX_NUMBER): + unit: NX_COUNT + exists: ['min', '0', 'max', '1'] + doc: | + Two-dimensional summation along the frames stack. + + sum of intensity v. time (in the units of "frames") + frame_average(NX_NUMBER): + unit: NX_COUNT + exists: ['min', '0', 'max', '1'] + doc: | + Two-dimensional average along the frames stack. + + average intensity v. time (in the units of "frames") + g2(NX_NUMBER): + unit: NX_DIMENSIONLESS + exists: ['min', '0', 'max', '1'] + doc: | + normalized intensity auto-correlation function, see Lumma, Rev. Sci. Instr. (2000), Eq 1 + + .. math:: g_2(\boldsymbol Q,t) = \frac{ \langle I(\boldsymbol Q,t\prime) I(\boldsymbol Q,t\prime + t) \rangle }{ \langle I(\boldsymbol Q,t\prime)\rangle^2 }; t > 0 + + Typically, :math:`g_2` is a quantity calculated for a group of pixels representing a specific + region of reciprocal space. These groupings, or bins, are generically described as :math:`q`. Some + open-source XPCS libraries refer to these bins as "rois", which are not to be confused with + EPICS AreaDetector ROI. See usage guidelines for q_lists and roi_maps within a mask. [#]_ + + In short, :math:`g_2` should be ordered according to the roi_map value. In principle, any format is acceptable if + the data and its axes are self-describing as per NeXus recommendations. However, the data is preferred in one + of the following two formats: + + * iterable list of linked files (or keys) for each :math:`g_2` with 1 file (key) per :math:`q`, where `q` is called by the nth roi_map value + * 2D array [#]_ with shape (:math:`g_2`, :math:`q`), where `q` is represented by the nth roi_map value, not the value `q` value + + Note it is expected that "g2" and all quantities following it will be of the same length. + + Other formats are acceptable with sufficient axes description. + + See references below for related implementation information: + + .. [#] mask: ``NXxpcs:/entry/instrument/masks-group`` + .. [#] NeXus 2-D data and axes: https://manual.nexusformat.org/classes/base_classes/NXdata.html#nxdata + \@storage_mode: + type: NX_CHAR + doc: | + storage_mode describes the format of the data to be loaded + + We encourage the documentation of other formats not represented here. + + * one array representing entire data set ("one_array") + * data exchange format with each key representing one ``q`` by its corresponding roi_map value ("data_exchange_keys") + enumeration: [one_array, data_exchange_keys, other] + g2_derr(NX_NUMBER): + unit: NX_DIMENSIONLESS + exists: ['min', '0', 'max', '1'] + doc: | + error values for the :math:`g_2` values. + + The derivation of the error is left up to the implemented code. Symmetric error will be + expected (:math:`\pm` error). The data should be in the same format as ``g2``. + \@storage_mode: + type: NX_CHAR + enumeration: [one_array, data_exchange_keys, other] + G2_unnormalized(NX_NUMBER): + unit: NX_ANY + exists: ['min', '0', 'max', '1'] + doc: | + unnormalized intensity auto-correlation function. + + Specifically, ``g2`` without the denominator. The data should be in the same format as ``g2``. + \@storage_mode: + type: NX_CHAR + enumeration: [one_array, data_exchange_keys, other] + delay_difference(NX_INT): + unit: NX_COUNT + exists: ['min', '0', 'max', '1'] + doc: | + delay_difference (also known as delay or lag step) + + This is quantized difference so that the "step" between two consecutive + frames is one frame (or step ``= dt = 1 frame``) + + It is the "quantized" delay time corresponding to the ``g2`` values. + + The unit of delay_differences is ``NX_INT`` for units of frames (i.e., integers) preferred, + refer to :ref:`NXdetector` for conversion to time units. + \@storage_mode: + type: NX_CHAR + enumeration: [one_array, data_exchange_keys, other] + (NXdata)twotime: + exists: ['min', '0'] + doc: | + The data (results) in this section are based on the two-time intensity correlation function derived from a time series of scattering images. + two_time_corr_func(NX_NUMBER): + unit: NX_ANY + exists: ['min', '0', 'max', '1'] + doc: | + two-time correlation of speckle intensity for a given q-bin or roi (represented by the nth roi_map value) + + See Fluerasu, Phys Rev E (2007), Eq 1 and Sutton, Optics Express (2003) for an early + description applied to X-ray scattering: + + .. math:: C(\boldsymbol Q, t_1, t_2) = \frac{ \langle I(\boldsymbol Q, t_1)I(\boldsymbol Q, t_2)\rangle }{ \langle I(\boldsymbol Q,t_1)\rangle \langle I(\boldsymbol Q,t_2)\rangle } + + in which time is quantized by frames. In principle, any data format is acceptable if + the data and its axes are self-describing as per NeXus recommendations. However, the data is preferred in one + of the following two formats: + + * iterable list of linked files (or keys) for each q-bin called by the nth roi_map value. data for each bin is a 2D array + * 3D array with shape (frames, frames, q) or (q, frames, frames), where :math:`q` is represented by the nth roi_map value, not the value `q` value + + + The computation of this result can be customized. These customizations can affect subsequently derived results (below). The + following attributes will be used to manage the customization. + + * Other normalization methods may be applied, but the method will not be specified in this + definition. Some of these normalization methods result in a baseline value of ``0``, not ``1``. + + * The various software libraries use different programming languages. Therefore, we need to + specify the ``time = 0`` origin location of the 2D array for each :math:`q`. + + * A method to reduce data storage needs is to only record half of the 2D array by populating + array elements above or below the array diagonal. + \@storage_mode: + type: NX_CHAR + doc: | + storage_mode describes the format of the data to be loaded + + We encourage the documention of other formats represented here. + enumeration: [one_array_q_first, one_array_q_last, data_exchange_keys, other] + \@baseline_reference: + type: NX_INT + doc: | + baseline is the expected value of a full decorrelation + + The baseline is a constant value added to the functional form of the auto-correlation + function. This value is required. + enumeration: [0, 1] + \@time_origin_location: + type: NX_CHAR + doc: | + time_origin_location is the location of the origin + enumeration: [upper_left, lower_left] + \@populated_elements: + type: NX_CHAR + doc: | + populated_elements describe the elements of the 2D array that are populated with data + enumeration: [all, upper_half, lower_half] + g2_from_two_time_corr_func(NX_NUMBER): + unit: NX_DIMENSIONLESS + exists: ['min', '0', 'max', '1'] + doc: | + frame weighted average along the diagonal direction in ``two_time_corr_func`` + + The data format and description should be consistent with that found in "/NXxpcs/entry/data/g2" + + * iterable list of linked files for each :math:`g_2` with 1 file per :math:`q` + * 2D array with shape (:math:`g_2`, :math:`q`) + + Note that delay_difference is not included here because it is derived from the shape of + extracted :math:`g_2` because all frames are considered, which is not necessarily the case for :math:`g_2`. + + The computation of this result can be customized. The customization can affect the fitting required to extract quantitative results. The + following attributes will be used to manage the customization. + \@storage_mode: + type: NX_CHAR + enumeration: [one_array_q_first, one_array_q_last, data_exchange_keys, other] + \@baseline_reference: + type: NX_INT + enumeration: [0, 1] + \@first_point_for_fit: + type: NX_INT + doc: | + first_point_for_fit describes if the first point should or should not be used in fitting the functional form of the dynamics to extract quantitative time-scale information. + + The first_point_for_fit is True ("1") or False ("0"). This value is required. + enumeration: [0, 1] + g2_err_from_two_time_corr_func(NX_NUMBER): + unit: NX_DIMENSIONLESS + exists: ['min', '0', 'max', '1'] + doc: | + error values for the :math:`g_2` values. + + The derivation of the error is left up to the implemented code. Symmetric error will be + expected (:math:`\pm` error). + \@storage_mode: + type: NX_CHAR + enumeration: [one_array_q_first, one_array_q_last, data_exchange_keys, other] + g2_from_two_time_corr_func_partials(NX_NUMBER): + unit: NX_DIMENSIONLESS + exists: ['min', '0', 'max', '1'] + doc: | + subset of frame weighted average along the diagonal direction in ``two_time_corr_func`` + + Time slicing along the diagonal can be very sophisticated. This entry currently assumes + equal frame-binning. The data formats are highly dependent on the implantation of various analysis libraries. + In principle, any data format is acceptable if the data and its axes are self describing as per NeXus + recommendations. However, the data is preferred in one of the following two formats: + + * iterable list of linked files (or keys) for each partial :math:`g_2` of each q-bin represented by the roi_map value + * 3D array with shape (:math:`g_2`, :math:`q`, nth_partial) + + Note that delay_difference is not included here because it is derived from the shape of + extracted :math:`g_2`. + \@storage_mode: + type: NX_CHAR + enumeration: [one_array, data_exchange_keys, other] + \@baseline_reference: + type: NX_INT + enumeration: [0, 1] + g2_err_from_two_time_corr_func_partials(NX_NUMBER): + unit: NX_DIMENSIONLESS + exists: ['min', '0', 'max', '1'] + doc: | + error values for the :math:`g_2` values. + + The derivation of the error is left up to the implemented code. Symmetric error will be + expected (:math:`\pm` error). + (NXinstrument)instrument: + doc: | + XPCS instrument Metadata. + + Objects can be entered here directly or linked from other + objects in the NeXus file (such as within ``/entry/instrument``). + (NXbeam)incident_beam: + incident_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + Incident beam line energy (either keV or eV). + incident_energy_spread(NX_FLOAT): + unit: NX_ENERGY + exists: ['min', '0', 'max', '1'] + doc: | + Spread of incident beam line energy (either keV or eV). This quantity is otherwise known + as the energy resolution, which is related to the longitudinal coherence length. + incident_polarization_type: + exists: ['min', '0', 'max', '1'] + doc: | + Terse description of the incident beam polarization. + + The value can be plain text, such as ``vertical``, ``C+``, + ``circular left``. + extent(NX_FLOAT): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + doc: | + Size (2-D) of the beam at this position. + + # FIXME: (h, v) or (v, h)? State this in the docs FOR EPICS AD, likeky v, h. But seems CSX is (h,v) if looking + # from the source's perspective at the face of the detector - see fig 11 and fig 12 of cxidb documentation. this + # is also relevant for the next section, which is just describing the 2D array V, H is python/bluesky + (NXdetector): + doc: | + XPCS data is typically produced by area detector (likely EPICS AreaDetector) as a stack of 2D images. Sometimes + this data is represented in different ways (sparse arrays or photon event list), but this detail + is left to the analysis software. Therefore, we only include requirements based on full array data. + + We note that the image origin (pixel coordinates (0,0)) are found at the top left of a single 2D image array. This + is the standard expected by Coherent X-ray Imaging Data Bank. [#]_ + See CXI version 1.6 and Maia, Nature Methods (2012). This seems to be consistent with matplotlib and + the practiced implementation of EPICS AreaDetector. However, some exceptions may exists in the CXI + documentation (See Fig 11 vs Fig 12). + + Additionally, not all :ref:`NXdetector` dependencies are inherited from AreaDetector or other control systems. ``frame_time`` is used to + convert ``delay_difference`` to seconds. ``frame_time`` field could be missing from AreaDetector or may + either be `acquire_period` or `acquire_time`, depending on the detector model and the local implementation. + + .. [#] Coherent X-ray Imaging Data Bank: https://cxidb.org/cxi.html + description: + exists: ['min', '0', 'max', '1'] + doc: | + Detector name. + distance(NX_NUMBER): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + doc: | + Distance between sample and detector. + count_time(NX_NUMBER): + unit: NX_TIME + doc: | + Exposure time of frames, s. + frame_time(NX_NUMBER): + unit: NX_TIME + doc: | + Exposure period (time between frame starts) of frames, s + beam_center_x(NX_NUMBER): + unit: NX_LENGTH + doc: | + Position of beam center, x axis, in detector's coordinates. + beam_center_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Position of beam center, y axis, in detector's coordinates. + x_pixel_size(NX_NUMBER): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + + # made this optional in case of single photon xy-time lists + doc: | + Length of pixel in x direction. + y_pixel_size(NX_NUMBER): + unit: NX_LENGTH + exists: ['min', '0', 'max', '1'] + doc: | + Length of pixel in y direction. + (NXnote)masks: + exists: ['min', '0', 'max', '1'] + doc: | + Data masks or mappings to regions of interest (roi) for specific :math:`Q` values + + Fields in this ``masks`` group describe regions of interest + in the data by either a mask to select pixels or to associate + a *map* of rois with a (one-dimensional) *list* of values. + + "roi_maps" provide for representation of pixel binning that are arbitrary and irregular, + which is geometry scattering agnostic and most flexible. The maps work as a labeled array for N rois. + + "Dynamic" represents quantities directly related to XPCS and NXxcps/entry/data and + NXxpcs/entry/two_time. + + "Static" refers to finer binning used for computation not strictly used for the final + XPCS results. Implementation of _static_ binning is left for individual libraries to + document. We encourage usage of :ref:`NXcanSAS` to represent standard SAXS results or + development of new NeXus definitions for GI-SAXS or other reciprocal space + intensity mapping. + dynamic_roi_map(NX_NUMBER): + unit: NX_DIMENSIONLESS + doc: | + roi index array or labeled array + + The values of this mask index (or map to) the :math:`Q` value from the + the ``dynamic_q_list`` field. Not that the value of ``0`` represents in-action. XPCS computations + are performed on all pixels with a value > 0. + + The ``units`` attribute should be set to ``"au"`` + indicating arbitrary units. + dynamic_q_list(NX_NUMBER): + unit: NX_PER_LENGTH + exists: ['min', '0'] + doc: | + 1-D list of :math:`Q` values, one for each roi index value. + + List order is determined by the index value of the associated roi map starting at ``1``. + + The only requirement for the list is that it may be iterable. Some expected formats are: + + * iterable list of floats (i.e., :math:`Q(r)`) + * iterable list of tuples (i.e., :math:`Q(r)`, :math:`\varphi`), but preferable use the seperate :math:`\varphi` field below + * iterable list of tuples (e.g., (H, K, L); (qx, qy, qz); (horizontal_pixel, vertical_pixel)) + * iterable list of integers (for Nth roi_map value) or strings + + This format is chosen because results plotting packages are not common and simple I/O is required by end user. + The lists can be accessed as lists, arrays or via keys + dynamic_phi_list(NX_NUMBER): + unit: NX_PER_LENGTH + exists: ['min', '0'] + doc: | + Array of :math:`\varphi` value for each pixel. + + List order is determined by the index value of the associated roi map starting at ``1``. + static_roi_map(NX_NUMBER): + unit: NX_DIMENSIONLESS + exists: ['min', '0'] + doc: | + roi index array. + + The values of this mask index the :math:`|Q|` value from the + the ``static_q_list`` field. + + The ``units`` attribute should be set to ``"au"`` + indicating arbitrary units. + static_q_list(NX_NUMBER): + unit: NX_PER_LENGTH + exists: ['min', '0'] + doc: | + 1-D list of :math:`|Q|` values, 1 for each roi. + (NXsample)sample: + exists: ['min', '0'] + + # Describes the minimum requirements regarding equilibrium sample conditions. NXsample + # permits other quantities (e.g., applied fields, crystallographic information, name, etc) that + # may optionally be include for equilibrium conditions (which is not exclusively equilibrium + # dynamics from XPCS analysis). + # For non-equilibrium sample conditions (i.e., changing sample or process conditions + # during the XPCS measurement) will require either a new entry or an additional atttribute. + temperature_set(NX_NUMBER): + unit: NX_TEMPERATURE + exists: ['min', '0'] + doc: | + Sample temperature setpoint, (C or K). + temperature(NX_NUMBER): + unit: NX_TEMPERATURE + exists: ['min', '0'] + doc: | + Sample temperature actual, (C or K). + (NXpositioner)position_x: + exists: ['min', '0'] + (NXpositioner)position_y: + exists: ['min', '0'] + (NXpositioner)position_z: + exists: ['min', '0'] + (NXnote)NOTE: + exists: ['min', '0', 'max', 'unbounded'] + doc: | + Any other notes. + + NAME: The NeXus convention, to use all upper case + to indicate the name (here ``NOTE``), is left to the file + writer. In our case, follow the suggested name + pattern and sequence: note_1, note_2, note_3, ... + Start with ``note_1`` if the first one, otherwise + pick the next number in this sequence. + (NXprocess): + doc: | + Describe the computation process that produced these results. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 24b656b7be7f0c85955748deed904585a8136c312327d128d6a4a377760052c8 +# +# +# +# +# +# +# The symbol(s) listed here will be used below to coordinate datasets with the same shape. +# +# +# Number of points +# +# +# +# X-ray Photon Correlation Spectroscopy (XPCS) data (results). +# +# The purpose of ``NXxpcs`` is to document and communicate an accepted vernacular for various XPCS results data +# in order to support development of community software tools. The definition presented here only +# represents a starting point and contains fields that a common software tool should support for +# community acceptance. +# +# Additional fields may be added to XPCS results file (either formally or informally). It is expected +# that this XPCS data will be part of multi-modal data set that could involve e.g., :ref:`NXcanSAS` or +# 1D and/or 2D data. +# +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# +# +# **Locally** unique identifier for the experiment (a.k.a. run or scan). +# +# * For bluesky users, this is the run's `"scan_id"`. +# * For SPEC users, this is the scan number (``SCAN_N``). +# +# +# +# +# (optional) UUID identifier for this entry. +# +# See the `UUID standard <https://www.rfc-editor.org/rfc/rfc4122.html>`__ (or +# `wikipedia <https://en.wikipedia.org/wiki/Universally_unique_identifier>`__) +# for more information. +# +# * For `bluesky <https://blueskyproject.io/>`__ users, this is the +# run's `"uid"` and is expected for that application. +# * Typically, `SPEC <https://certif.com/content/spec/>`__ users will +# not use this field without further engineering. +# +# +# +# +# +# Scan number (must be an integer). +# +# NOTE: Link to collection_identifier. +# +# +# +# +# Starting time of experiment, such as "2021-02-11 11:22:33.445566Z". +# +# +# +# +# Ending time of experiment, such as "2021-02-11 11:23:45Z". +# +# +# +# +# +# The results data captured here are most commonly required for high throughput, equilibrium dynamics experiments. Data (results) +# describing on-equilibrium dynamics consume more memory resources so these data are separated. +# +# +# +# Two-dimensional summation along the frames stack. +# +# sum of intensity v. time (in the units of "frames") +# +# +# +# +# Two-dimensional average along the frames stack. +# +# average intensity v. time (in the units of "frames") +# +# +# +# +# normalized intensity auto-correlation function, see Lumma, Rev. Sci. Instr. (2000), Eq 1 +# +# .. math:: g_2(\boldsymbol Q,t) = \frac{ \langle I(\boldsymbol Q,t\prime) I(\boldsymbol Q,t\prime + t) \rangle }{ \langle I(\boldsymbol Q,t\prime)\rangle^2 }; t > 0 +# +# Typically, :math:`g_2` is a quantity calculated for a group of pixels representing a specific +# region of reciprocal space. These groupings, or bins, are generically described as :math:`q`. Some +# open-source XPCS libraries refer to these bins as "rois", which are not to be confused with +# EPICS AreaDetector ROI. See usage guidelines for q_lists and roi_maps within a mask. [#]_ +# +# In short, :math:`g_2` should be ordered according to the roi_map value. In principle, any format is acceptable if +# the data and its axes are self-describing as per NeXus recommendations. However, the data is preferred in one +# of the following two formats: +# +# * iterable list of linked files (or keys) for each :math:`g_2` with 1 file (key) per :math:`q`, where `q` is called by the nth roi_map value +# * 2D array [#]_ with shape (:math:`g_2`, :math:`q`), where `q` is represented by the nth roi_map value, not the value `q` value +# +# Note it is expected that "g2" and all quantities following it will be of the same length. +# +# Other formats are acceptable with sufficient axes description. +# +# See references below for related implementation information: +# +# .. [#] mask: ``NXxpcs:/entry/instrument/masks-group`` +# .. [#] NeXus 2-D data and axes: https://manual.nexusformat.org/classes/base_classes/NXdata.html#nxdata +# +# +# +# storage_mode describes the format of the data to be loaded +# +# We encourage the documentation of other formats not represented here. +# +# * one array representing entire data set ("one_array") +# * data exchange format with each key representing one ``q`` by its corresponding roi_map value ("data_exchange_keys") +# +# +# +# +# +# +# +# +# +# +# error values for the :math:`g_2` values. +# +# The derivation of the error is left up to the implemented code. Symmetric error will be +# expected (:math:`\pm` error). The data should be in the same format as ``g2``. +# +# +# +# +# +# +# +# +# +# +# +# unnormalized intensity auto-correlation function. +# +# Specifically, ``g2`` without the denominator. The data should be in the same format as ``g2``. +# +# +# +# +# +# +# +# +# +# +# +# +# delay_difference (also known as delay or lag step) +# +# This is quantized difference so that the "step" between two consecutive +# frames is one frame (or step ``= dt = 1 frame``) +# +# It is the "quantized" delay time corresponding to the ``g2`` values. +# +# The unit of delay_differences is ``NX_INT`` for units of frames (i.e., integers) preferred, +# refer to :ref:`NXdetector` for conversion to time units. +# +# +# +# +# +# +# +# +# +# +# +# +# +# The data (results) in this section are based on the two-time intensity correlation function derived from a time series of scattering images. +# +# +# +# two-time correlation of speckle intensity for a given q-bin or roi (represented by the nth roi_map value) +# +# See Fluerasu, Phys Rev E (2007), Eq 1 and Sutton, Optics Express (2003) for an early +# description applied to X-ray scattering: +# +# .. math:: C(\boldsymbol Q, t_1, t_2) = \frac{ \langle I(\boldsymbol Q, t_1)I(\boldsymbol Q, t_2)\rangle }{ \langle I(\boldsymbol Q,t_1)\rangle \langle I(\boldsymbol Q,t_2)\rangle } +# +# in which time is quantized by frames. In principle, any data format is acceptable if +# the data and its axes are self-describing as per NeXus recommendations. However, the data is preferred in one +# of the following two formats: +# +# * iterable list of linked files (or keys) for each q-bin called by the nth roi_map value. data for each bin is a 2D array +# * 3D array with shape (frames, frames, q) or (q, frames, frames), where :math:`q` is represented by the nth roi_map value, not the value `q` value +# +# +# The computation of this result can be customized. These customizations can affect subsequently derived results (below). The +# following attributes will be used to manage the customization. +# +# * Other normalization methods may be applied, but the method will not be specified in this +# definition. Some of these normalization methods result in a baseline value of ``0``, not ``1``. +# +# * The various software libraries use different programming languages. Therefore, we need to +# specify the ``time = 0`` origin location of the 2D array for each :math:`q`. +# +# * A method to reduce data storage needs is to only record half of the 2D array by populating +# array elements above or below the array diagonal. +# +# +# +# +# +# storage_mode describes the format of the data to be loaded +# +# We encourage the documention of other formats represented here. +# +# +# +# +# +# +# +# +# +# +# baseline is the expected value of a full decorrelation +# +# The baseline is a constant value added to the functional form of the auto-correlation +# function. This value is required. +# +# +# +# +# +# +# +# +# time_origin_location is the location of the origin +# +# +# +# +# +# +# +# +# populated_elements describe the elements of the 2D array that are populated with data +# +# +# +# +# +# +# +# +# +# +# frame weighted average along the diagonal direction in ``two_time_corr_func`` +# +# The data format and description should be consistent with that found in "/NXxpcs/entry/data/g2" +# +# * iterable list of linked files for each :math:`g_2` with 1 file per :math:`q` +# * 2D array with shape (:math:`g_2`, :math:`q`) +# +# Note that delay_difference is not included here because it is derived from the shape of +# extracted :math:`g_2` because all frames are considered, which is not necessarily the case for :math:`g_2`. +# +# The computation of this result can be customized. The customization can affect the fitting required to extract quantitative results. The +# following attributes will be used to manage the customization. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# first_point_for_fit describes if the first point should or should not be used in fitting the functional form of the dynamics to extract quantitative time-scale information. +# +# The first_point_for_fit is True ("1") or False ("0"). This value is required. +# +# +# +# +# +# +# +# +# +# error values for the :math:`g_2` values. +# +# The derivation of the error is left up to the implemented code. Symmetric error will be +# expected (:math:`\pm` error). +# +# +# +# +# +# +# +# +# +# +# +# +# subset of frame weighted average along the diagonal direction in ``two_time_corr_func`` +# +# Time slicing along the diagonal can be very sophisticated. This entry currently assumes +# equal frame-binning. The data formats are highly dependent on the implantation of various analysis libraries. +# In principle, any data format is acceptable if the data and its axes are self describing as per NeXus +# recommendations. However, the data is preferred in one of the following two formats: +# +# * iterable list of linked files (or keys) for each partial :math:`g_2` of each q-bin represented by the roi_map value +# * 3D array with shape (:math:`g_2`, :math:`q`, nth_partial) +# +# Note that delay_difference is not included here because it is derived from the shape of +# extracted :math:`g_2`. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# error values for the :math:`g_2` values. +# +# The derivation of the error is left up to the implemented code. Symmetric error will be +# expected (:math:`\pm` error). +# +# +# +# +# +# +# XPCS instrument Metadata. +# +# Objects can be entered here directly or linked from other +# objects in the NeXus file (such as within ``/entry/instrument``). +# +# +# +# Incident beam line energy (either keV or eV). +# +# +# +# Spread of incident beam line energy (either keV or eV). This quantity is otherwise known +# as the energy resolution, which is related to the longitudinal coherence length. +# +# +# +# +# Terse description of the incident beam polarization. +# +# The value can be plain text, such as ``vertical``, ``C+``, +# ``circular left``. +# +# +# +# Size (2-D) of the beam at this position. +# +# +# +# +# +# +# XPCS data is typically produced by area detector (likely EPICS AreaDetector) as a stack of 2D images. Sometimes +# this data is represented in different ways (sparse arrays or photon event list), but this detail +# is left to the analysis software. Therefore, we only include requirements based on full array data. +# +# We note that the image origin (pixel coordinates (0,0)) are found at the top left of a single 2D image array. This +# is the standard expected by Coherent X-ray Imaging Data Bank. [#]_ +# See CXI version 1.6 and Maia, Nature Methods (2012). This seems to be consistent with matplotlib and +# the practiced implementation of EPICS AreaDetector. However, some exceptions may exists in the CXI +# documentation (See Fig 11 vs Fig 12). +# +# Additionally, not all :ref:`NXdetector` dependencies are inherited from AreaDetector or other control systems. ``frame_time`` is used to +# convert ``delay_difference`` to seconds. ``frame_time`` field could be missing from AreaDetector or may +# either be `acquire_period` or `acquire_time`, depending on the detector model and the local implementation. +# +# .. [#] Coherent X-ray Imaging Data Bank: https://cxidb.org/cxi.html +# +# +# Detector name. +# +# +# Distance between sample and detector. +# +# +# Exposure time of frames, s. +# +# +# +# Exposure period (time between frame starts) of frames, s +# +# +# +# +# Position of beam center, x axis, in detector's coordinates. +# +# +# +# +# Position of beam center, y axis, in detector's coordinates. +# +# +# +# +# +# Length of pixel in x direction. +# +# +# +# +# Length of pixel in y direction. +# +# +# +# +# +# +# Data masks or mappings to regions of interest (roi) for specific :math:`Q` values +# +# Fields in this ``masks`` group describe regions of interest +# in the data by either a mask to select pixels or to associate +# a *map* of rois with a (one-dimensional) *list* of values. +# +# "roi_maps" provide for representation of pixel binning that are arbitrary and irregular, +# which is geometry scattering agnostic and most flexible. The maps work as a labeled array for N rois. +# +# "Dynamic" represents quantities directly related to XPCS and NXxcps/entry/data and +# NXxpcs/entry/two_time. +# +# "Static" refers to finer binning used for computation not strictly used for the final +# XPCS results. Implementation of _static_ binning is left for individual libraries to +# document. We encourage usage of :ref:`NXcanSAS` to represent standard SAXS results or +# development of new NeXus definitions for GI-SAXS or other reciprocal space +# intensity mapping. +# +# +# +# roi index array or labeled array +# +# The values of this mask index (or map to) the :math:`Q` value from the +# the ``dynamic_q_list`` field. Not that the value of ``0`` represents in-action. XPCS computations +# are performed on all pixels with a value > 0. +# +# The ``units`` attribute should be set to ``"au"`` +# indicating arbitrary units. +# +# +# +# +# 1-D list of :math:`Q` values, one for each roi index value. +# +# List order is determined by the index value of the associated roi map starting at ``1``. +# +# The only requirement for the list is that it may be iterable. Some expected formats are: +# +# * iterable list of floats (i.e., :math:`Q(r)`) +# * iterable list of tuples (i.e., :math:`Q(r)`, :math:`\varphi`), but preferable use the seperate :math:`\varphi` field below +# * iterable list of tuples (e.g., (H, K, L); (qx, qy, qz); (horizontal_pixel, vertical_pixel)) +# * iterable list of integers (for Nth roi_map value) or strings +# +# This format is chosen because results plotting packages are not common and simple I/O is required by end user. +# The lists can be accessed as lists, arrays or via keys +# +# +# +# +# Array of :math:`\varphi` value for each pixel. +# +# List order is determined by the index value of the associated roi map starting at ``1``. +# +# +# +# +# roi index array. +# +# The values of this mask index the :math:`|Q|` value from the +# the ``static_q_list`` field. +# +# The ``units`` attribute should be set to ``"au"`` +# indicating arbitrary units. +# +# +# +# +# 1-D list of :math:`|Q|` values, 1 for each roi. +# +# +# +# +# +# +# +# +# +# Sample temperature setpoint, (C or K). +# +# +# +# +# Sample temperature actual, (C or K). +# +# +# +# +# +# +# +# +# +# Any other notes. +# +# NAME: The NeXus convention, to use all upper case +# to indicate the name (here ``NOTE``), is left to the file +# writer. In our case, follow the suggested name +# pattern and sequence: note_1, note_2, note_3, ... +# Start with ``note_1`` if the first one, otherwise +# pick the next number in this sequence. +# +# +# +# +# +# +# Describe the computation process that produced these results. +# +# +# From 269a84600896da680888f3330ff00813cb2d6946 Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 11 Sep 2023 11:54:18 +0200 Subject: [PATCH 0301/1012] Sets preparation, temperature+gas_pressure in NXmpes/NXsample to recommended --- contributed_definitions/NXmpes.nxdl.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 4f3083d251..1d60427997 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -314,7 +314,7 @@ annealing). - + Description of the surface preparation technique for the XPS experiment, i.e. UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report @@ -323,7 +323,7 @@ other metadata file. In the case these are not available, free-text description. - + In the case of a fixed temperature measurement this is the scalar temperature of the sample. In the case of an experiment in which the temperature is changed and @@ -339,7 +339,7 @@ - + Voltage applied to sample and sample holder. From 38f33d3458fa57992ee3fab8d1adc81541e06841 Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 11 Sep 2023 11:55:55 +0200 Subject: [PATCH 0302/1012] Sets fields to optional --- contributed_definitions/NXmpes.nxdl.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 1d60427997..3acf517c9f 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -314,7 +314,7 @@ annealing). - + Description of the surface preparation technique for the XPS experiment, i.e. UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report @@ -331,7 +331,7 @@ /entry/instrument/manipulator/sample_temperature. - + @@ -339,7 +339,7 @@ - + Voltage applied to sample and sample holder. From a3cba75c95dd71ef8065c9a99bc904a6a076825f Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 11 Sep 2023 16:17:45 +0200 Subject: [PATCH 0303/1012] Incorporates comments from proposal page --- contributed_definitions/NXmpes.nxdl.xml | 28 ++++++++++++++++++++----- 1 file changed, 23 insertions(+), 5 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 3acf517c9f..d0fb924cba 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -33,13 +33,18 @@ Datetime of the start of the measurement. + + + Datetime of the end of the measurement. + + - + Contact information of at least the user of the instrument or the investigator who performed this experiment. Adding multiple users if relevant is recommended. @@ -73,7 +78,7 @@ - + The source used to generate the primary photons. Properties refer strictly to @@ -92,6 +97,8 @@ + + @@ -108,7 +115,7 @@ - + Distance of the point of evaluation of the beam from the sample surface. @@ -128,6 +135,12 @@ + Scheme of the electron collection column. @@ -135,13 +148,14 @@ + - + @@ -206,6 +220,10 @@ + @@ -228,7 +246,7 @@ - + Document an event of data processing, reconstruction, or analysis for this data. Describe the appropriate axis calibrations for your experiment using one or more From 57171a15e02227e82819c2470c676f835b080878 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 13 Sep 2023 10:50:15 +0200 Subject: [PATCH 0304/1012] Incorporates changes from may workshop (#32) --- contributed_definitions/NXmpes.nxdl.xml | 35 ++++++++++++++++++++----- 1 file changed, 29 insertions(+), 6 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index d0fb924cba..2cdc6a0d73 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -38,6 +38,14 @@ Datetime of the end of the measurement. + + + A name of the experimental method according + to the `ISO 18115-1:2023`_ specification. + + .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + + @@ -79,7 +87,11 @@ - + + 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 @@ -99,22 +111,28 @@ + - + + + Specification of type, may also go to name. + + + Type of probe. In photoemission it's always photons, so the full NIAC list is restricted. - - - + - + + + Distance of the point of evaluation of the beam from the sample surface. @@ -125,6 +143,11 @@ + + + + + From 52e2bdd38abd69d96285f30f01ef9664452a7e98 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 13 Sep 2023 18:08:05 +0200 Subject: [PATCH 0305/1012] Adds a reference to PaNET ontology --- contributed_definitions/nyaml/NXmpes.yaml | 422 ++-------------------- 1 file changed, 35 insertions(+), 387 deletions(-) diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 75af9af646..8721626809 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -1,18 +1,28 @@ -category: application -doc: | +doc: | This is the most general application definition for multidimensional photoelectron spectroscopy. -type: group -NXmpes(NXobject): +category: application +uri: http://purl.org/pan-science/PaNET/PaNET01269 +NXmpes: (NXentry): title: start_time(NX_DATE_TIME): doc: | Datetime of the start of the measurement. + end_time(NX_DATE_TIME): + doc: | + Datetime of the end of the measurement. + method: + doc: | + A name of the experimental method according + to the `ISO 18115-1:2023`_ specification. + + .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html definition: \@version: enumeration: [NXmpes] (NXuser): + exists: recommended doc: | Contact information of at least the user of the instrument or the investigator who performed this experiment. Adding multiple users if relevant is recommended. @@ -38,23 +48,29 @@ NXmpes(NXobject): Author ID defined by https://orcid.org/. (NXinstrument): energy_resolution(NX_FLOAT): + exists: recommended unit: NX_ENERGY - (NXsource): + source_beam(NXsource): doc: | The source used to generate the primary photons. Properties refer strictly to parameters of the source, not of the output beam. For example, the energy of the source is not the optical power of the beam, but the energy of the electron beam in a synchrotron and so on. type: - enumeration: [Synchrotron X-ray Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, UV Plasma Source, Metal Jet X-ray, HHG laser] + enumeration: [Synchrotron X-ray Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, UV Plasma Source, Metal Jet X-ray, HHG laser, UV lamp, Monochromatized electron source, other] + type_other: + doc: | + Specification of type, may also go to name. name: + exists: recommended probe: doc: | Type of probe. In photoemission it's always photons, so the full NIAC list is restricted. - enumeration: [x-ray, ultraviolet, visible light] - (NXbeam): + enumeration: [photons] + beam_probe(NXbeam): distance(NX_NUMBER): + exists: recommended unit: NX_LENGTH doc: | Distance of the point of evaluation of the beam from the sample surface. @@ -67,6 +83,14 @@ NXmpes(NXobject): exists: recommended unit: NX_ANY (NXelectronanalyser): + model(NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended description: energy_resolution(NX_FLOAT): exists: recommended @@ -82,18 +106,16 @@ NXmpes(NXobject): scheme: doc: | Scheme of the electron collection column. - enumeration: [Standard, Angular dispersive, Selective area, Deflector, PEEM, Momentum Microscope] + enumeration: [Standard, Angular dispersive, Spatial dispersive, Selective area, Deflector, PEEM, Momentum Microscope] mode: exists: recommended projection: exists: recommended field_aperture(NXaperture): - exists: optional doc: | The size and position of the field aperture inserted in the column. To add additional or other apertures use the APERTURE group of NXcollectioncolumn. contrast_aperture(NXaperture): - exists: optional doc: | The size and position of the contrast aperture inserted in the column. To add additional or other apertures use the APERTURE group of NXcollectioncolumn. @@ -104,12 +126,10 @@ NXmpes(NXobject): unit: NX_ENERGY energy_scan_mode: entrance_slit(NXaperture): - exists: optional doc: | Size, position and shape of the entrance slit in dispersive analyzers. To add additional or other slits use the APERTURE group of NXenergydispersion. exit_slit(NXaperture): - exists: optional doc: | Size, position and shape of the exit slit in dispersive analyzers. To add additional or other slits use the APERTURE group of NXenergydispersion. @@ -132,7 +152,6 @@ NXmpes(NXobject): doc: | Raw data before calibration. (NXmanipulator): - exists: optional doc: | Manipulator for positioning of the sample. sample_temperature(NX_FLOAT): @@ -145,12 +164,12 @@ NXmpes(NXobject): exists: recommended unit: NX_CURRENT (NXprocess): + exists: recommended doc: | 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 energy_calibration(NXcalibration): - exists: optional applied(NX_BOOLEAN): doc: | Has an energy calibration been applied? @@ -159,7 +178,6 @@ NXmpes(NXobject): doc: | This is the calibrated energy axis to be used for data plotting. angular_calibration(NXcalibration): - exists: optional applied(NX_BOOLEAN): doc: | Has an angular calibration been applied? @@ -168,7 +186,6 @@ NXmpes(NXobject): doc: | This is the calibrated angular axis to be used for data plotting. spatial_calibration(NXcalibration): - exists: optional applied(NX_BOOLEAN): doc: | Has an spatial calibration been applied? @@ -177,7 +194,6 @@ NXmpes(NXobject): doc: | This is the calibrated spatial axis to be used for data plotting. momentum_calibration(NXcalibration): - exists: optional applied(NX_BOOLEAN): doc: | Has an momentum calibration been applied? @@ -220,6 +236,7 @@ NXmpes(NXobject): 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. temperature(NX_FLOAT): + exists: recommended unit: NX_TEMPERATURE doc: | In the case of a fixed temperature measurement this is the scalar temperature of @@ -232,7 +249,6 @@ NXmpes(NXobject): unit: NX_PRESSURE bias(NX_FLOAT): unit: NX_VOLTAGE - exists: optional doc: | Voltage applied to sample and sample holder. (NXdata): @@ -245,371 +261,3 @@ NXmpes(NXobject): 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e618cc098656aa72e4a5bd743c85c5d9c9caa79cbe85d96b6e06fafd1d165d1b -# -# -# -# -# -# This is the most general application definition for multidimensional -# photoelectron spectroscopy. -# -# -# -# -# -# Datetime of the start of the measurement. -# -# -# -# -# -# -# -# -# -# -# Contact information of at least the user of the instrument or the investigator -# who performed this experiment. Adding multiple users if relevant is recommended. -# -# -# -# Name of the user. -# -# -# -# -# Name of the affiliation of the user at the point in time when the experiment was -# performed. -# -# -# -# -# Full address (street, street number, ZIP, city, country) of the user's -# affiliation. -# -# -# -# -# Email address of the user. -# -# -# -# -# Author ID defined by https://orcid.org/. -# -# -# -# -# -# -# -# The source used to generate the primary photons. Properties refer strictly to -# parameters of the source, not of the output beam. For example, the energy of the -# source is not the optical power of the beam, but the energy of the electron beam -# in a synchrotron and so on. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Type of probe. In photoemission it's always photons, so the full NIAC list is -# restricted. -# -# -# -# -# -# -# -# -# -# -# -# Distance of the point of evaluation of the beam from the sample surface. -# -# -# -# -# -# -# -# -# -# -# Energy resolution of the analyser with the current setting. May be linked from a -# NXcalibration. -# -# -# -# -# -# -# -# Scheme of the electron collection column. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The size and position of the field aperture inserted in the column. To add -# additional or other apertures use the APERTURE group of NXcollectioncolumn. -# -# -# -# -# The size and position of the contrast aperture inserted in the column. To add -# additional or other apertures use the APERTURE group of NXcollectioncolumn. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Size, position and shape of the entrance slit in dispersive analyzers. To add -# additional or other slits use the APERTURE group of NXenergydispersion. -# -# -# -# -# Size, position and shape of the exit slit in dispersive analyzers. To add -# additional or other slits use the APERTURE group of NXenergydispersion. -# -# -# -# -# -# -# Type of electron amplifier in the first amplification step. -# -# -# -# -# -# -# -# -# Description of the detector type. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Raw data before calibration. -# -# -# -# -# -# -# -# Manipulator for positioning of the sample. -# -# -# -# -# -# -# -# -# Document an event of data processing, reconstruction, or analysis for this data. -# Describe the appropriate axis calibrations for your experiment using one or more -# of the following NXcalibrations -# -# -# -# -# Has an energy calibration been applied? -# -# -# -# -# This is the calibrated energy axis to be used for data plotting. -# -# -# -# -# -# -# Has an angular calibration been applied? -# -# -# -# -# This is the calibrated angular axis to be used for data plotting. -# -# -# -# -# -# -# Has an spatial calibration been applied? -# -# -# -# -# This is the calibrated spatial axis to be used for data plotting. -# -# -# -# -# -# -# Has an momentum calibration been applied? -# -# -# -# -# This is the momentum axis to be used for data plotting. -# -# -# -# -# -# -# -# -# The chemical formula of the sample. For mixtures use the NXsample_component -# group in NXsample instead. -# -# -# -# -# A descriptor to keep track of the treatment of the sample before entering the -# photoemission experiment. Ideally, a full report of the previous operations, in -# any format (NXnote allows to add pictures, audio, movies). Alternatively, a -# reference to the location or a unique identifier or other metadata file. In the -# case these are not available, free-text description. -# -# -# -# -# List of comma-separated elements from the periodic table -# that are contained in the sample. -# If the sample substance has multiple components, all -# elements from each component must be included in `atom_types`. -# -# -# -# -# Date of preparation of the sample for the XPS experiment (i.e. cleaving, last -# annealing). -# -# -# -# -# Description of the surface preparation technique for the XPS experiment, i.e. -# UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report -# of the previous operations, in any format(NXnote allows to add pictures, audio, -# movies). Alternatively, a reference to the location or a unique identifier or -# other metadata file. In the case these are not available, free-text description. -# -# -# -# -# In the case of a fixed temperature measurement this is the scalar temperature of -# the sample. In the case of an experiment in which the temperature is changed and -# recoded, this is an array of length m of temperatures. This should be a link to -# /entry/instrument/manipulator/sample_temperature. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Voltage applied to sample and sample holder. -# -# -# -# -# -# -# -# -# -# -# -# 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. -# -# -# -# -# From be014ac30524672d39814ba61ee2094608408927 Mon Sep 17 00:00:00 2001 From: domna Date: Thu, 21 Sep 2023 13:11:19 +0200 Subject: [PATCH 0306/1012] Use NXmpes.yaml generated with correct nyaml2nxdl --- contributed_definitions/nyaml/NXmpes.yaml | 454 +++++++++++++++++++++- 1 file changed, 447 insertions(+), 7 deletions(-) diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 8721626809..3190b0af73 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -1,9 +1,9 @@ -doc: | +category: application +doc: | This is the most general application definition for multidimensional photoelectron spectroscopy. -category: application -uri: http://purl.org/pan-science/PaNET/PaNET01269 -NXmpes: +type: group +NXmpes(NXobject): (NXentry): title: start_time(NX_DATE_TIME): @@ -48,9 +48,13 @@ NXmpes: Author ID defined by https://orcid.org/. (NXinstrument): energy_resolution(NX_FLOAT): - exists: recommended unit: NX_ENERGY + exists: recommended source_beam(NXsource): + + # Comment from mpes may workshop: + # - Add linking between source and beam + # - There is much more information which can be provided for NXsource doc: | 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 @@ -59,6 +63,7 @@ NXmpes: type: enumeration: [Synchrotron X-ray Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, UV Plasma Source, Metal Jet X-ray, HHG laser, UV lamp, Monochromatized electron source, other] type_other: + exists: optional doc: | Specification of type, may also go to name. name: @@ -69,9 +74,13 @@ NXmpes: restricted. enumeration: [photons] beam_probe(NXbeam): + + # Comment from mpes may workshop: Add linking between source and beam + + # Add extent as recommended? distance(NX_NUMBER): - exists: recommended unit: NX_LENGTH + exists: recommended doc: | Distance of the point of evaluation of the beam from the sample surface. incident_energy(NX_FLOAT): @@ -103,19 +112,27 @@ NXmpes: slow_axes: exists: recommended (NXcollectioncolumn): + + # TODO: Comment from Anders Frisk on proposal page + # What is the definition of a collection column? + # Optional constant settings (like lens focusing parameters on the sample: position_x, position_y, working_distance) scheme: doc: | Scheme of the electron collection column. enumeration: [Standard, Angular dispersive, Spatial dispersive, Selective area, Deflector, PEEM, Momentum Microscope] mode: exists: recommended + + # TODO: What does this refer to. It is currently not in the collection column base class projection: exists: recommended field_aperture(NXaperture): + exists: optional doc: | The size and position of the field aperture inserted in the column. To add additional or other apertures use the APERTURE group of NXcollectioncolumn. contrast_aperture(NXaperture): + exists: optional doc: | The size and position of the contrast aperture inserted in the column. To add additional or other apertures use the APERTURE group of NXcollectioncolumn. @@ -126,10 +143,12 @@ NXmpes: unit: NX_ENERGY energy_scan_mode: entrance_slit(NXaperture): + exists: optional doc: | Size, position and shape of the entrance slit in dispersive analyzers. To add additional or other slits use the APERTURE group of NXenergydispersion. exit_slit(NXaperture): + exists: optional doc: | Size, position and shape of the exit slit in dispersive analyzers. To add additional or other slits use the APERTURE group of NXenergydispersion. @@ -146,12 +165,16 @@ NXmpes: enumeration: [DLD, Phosphor+CCD, Phosphor+CMOS, ECMOS, Anode, Multi-anode] (NXdata): exists: recommended + + # TODO: Anders Frisk on proposal page + # It could be a lot of raw data from a detector. Shpould be optional. \@signal: enumeration: [raw] raw(NX_NUMBER): doc: | Raw data before calibration. (NXmanipulator): + exists: optional doc: | Manipulator for positioning of the sample. sample_temperature(NX_FLOAT): @@ -170,6 +193,7 @@ NXmpes: Describe the appropriate axis calibrations for your experiment using one or more of the following NXcalibrations energy_calibration(NXcalibration): + exists: optional applied(NX_BOOLEAN): doc: | Has an energy calibration been applied? @@ -178,6 +202,7 @@ NXmpes: doc: | This is the calibrated energy axis to be used for data plotting. angular_calibration(NXcalibration): + exists: optional applied(NX_BOOLEAN): doc: | Has an angular calibration been applied? @@ -186,6 +211,7 @@ NXmpes: doc: | This is the calibrated angular axis to be used for data plotting. spatial_calibration(NXcalibration): + exists: optional applied(NX_BOOLEAN): doc: | Has an spatial calibration been applied? @@ -194,6 +220,7 @@ NXmpes: doc: | This is the calibrated spatial axis to be used for data plotting. momentum_calibration(NXcalibration): + exists: optional applied(NX_BOOLEAN): doc: | Has an momentum calibration been applied? @@ -229,6 +256,7 @@ NXmpes: Date of preparation of the sample for the XPS experiment (i.e. cleaving, last annealing). preparation_description(NXnote): + exists: optional doc: | Description of the surface preparation technique for the XPS experiment, i.e. UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report @@ -236,19 +264,22 @@ NXmpes: 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. temperature(NX_FLOAT): - exists: recommended unit: NX_TEMPERATURE + exists: recommended doc: | 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. situation: + exists: optional enumeration: [vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere] gas_pressure(NX_FLOAT): unit: NX_PRESSURE + exists: optional bias(NX_FLOAT): unit: NX_VOLTAGE + exists: optional doc: | Voltage applied to sample and sample holder. (NXdata): @@ -261,3 +292,412 @@ NXmpes: 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e18956fa79544e7b4f50e31f3b421e387cab531f4f608e4c9dfc0013fa459429 +# +# +# +# +# +# This is the most general application definition for multidimensional +# photoelectron spectroscopy. +# +# +# +# +# +# Datetime of the start of the measurement. +# +# +# +# +# Datetime of the end of the measurement. +# +# +# +# +# A name of the experimental method according +# to the `ISO 18115-1:2023`_ specification. +# +# .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html +# +# +# +# +# +# +# +# +# +# +# Contact information of at least the user of the instrument or the investigator +# who performed this experiment. Adding multiple users if relevant is recommended. +# +# +# +# Name of the user. +# +# +# +# +# Name of the affiliation of the user at the point in time when the experiment was +# performed. +# +# +# +# +# Full address (street, street number, ZIP, city, country) of the user's +# affiliation. +# +# +# +# +# Email address of the user. +# +# +# +# +# Author ID defined by https://orcid.org/. +# +# +# +# +# +# +# +# +# The source used to generate the primary photons. Properties refer strictly to +# parameters of the source, not of the output beam. For example, the energy of the +# source is not the optical power of the beam, but the energy of the electron beam +# in a synchrotron and so on. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Specification of type, may also go to name. +# +# +# +# +# +# Type of probe. In photoemission it's always photons, so the full NIAC list is +# restricted. +# +# +# +# +# +# +# +# +# +# +# +# Distance of the point of evaluation of the beam from the sample surface. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Energy resolution of the analyser with the current setting. May be linked from a +# NXcalibration. +# +# +# +# +# +# +# +# +# Scheme of the electron collection column. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The size and position of the field aperture inserted in the column. To add +# additional or other apertures use the APERTURE group of NXcollectioncolumn. +# +# +# +# +# The size and position of the contrast aperture inserted in the column. To add +# additional or other apertures use the APERTURE group of NXcollectioncolumn. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Size, position and shape of the entrance slit in dispersive analyzers. To add +# additional or other slits use the APERTURE group of NXenergydispersion. +# +# +# +# +# Size, position and shape of the exit slit in dispersive analyzers. To add +# additional or other slits use the APERTURE group of NXenergydispersion. +# +# +# +# +# +# +# Type of electron amplifier in the first amplification step. +# +# +# +# +# +# +# +# +# Description of the detector type. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Raw data before calibration. +# +# +# +# +# +# +# +# Manipulator for positioning of the sample. +# +# +# +# +# +# +# +# +# Document an event of data processing, reconstruction, or analysis for this data. +# Describe the appropriate axis calibrations for your experiment using one or more +# of the following NXcalibrations +# +# +# +# +# Has an energy calibration been applied? +# +# +# +# +# This is the calibrated energy axis to be used for data plotting. +# +# +# +# +# +# +# Has an angular calibration been applied? +# +# +# +# +# This is the calibrated angular axis to be used for data plotting. +# +# +# +# +# +# +# Has an spatial calibration been applied? +# +# +# +# +# This is the calibrated spatial axis to be used for data plotting. +# +# +# +# +# +# +# Has an momentum calibration been applied? +# +# +# +# +# This is the momentum axis to be used for data plotting. +# +# +# +# +# +# +# +# +# The chemical formula of the sample. For mixtures use the NXsample_component +# group in NXsample instead. +# +# +# +# +# A descriptor to keep track of the treatment of the sample before entering the +# photoemission experiment. Ideally, a full report of the previous operations, in +# any format (NXnote allows to add pictures, audio, movies). Alternatively, a +# reference to the location or a unique identifier or other metadata file. In the +# case these are not available, free-text description. +# +# +# +# +# List of comma-separated elements from the periodic table +# that are contained in the sample. +# If the sample substance has multiple components, all +# elements from each component must be included in `atom_types`. +# +# +# +# +# Date of preparation of the sample for the XPS experiment (i.e. cleaving, last +# annealing). +# +# +# +# +# Description of the surface preparation technique for the XPS experiment, i.e. +# UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report +# of the previous operations, in any format(NXnote allows to add pictures, audio, +# movies). Alternatively, a reference to the location or a unique identifier or +# other metadata file. In the case these are not available, free-text description. +# +# +# +# +# In the case of a fixed temperature measurement this is the scalar temperature of +# the sample. In the case of an experiment in which the temperature is changed and +# recoded, this is an array of length m of temperatures. This should be a link to +# /entry/instrument/manipulator/sample_temperature. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Voltage applied to sample and sample holder. +# +# +# +# +# +# +# +# +# +# +# +# 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. +# +# +# +# +# From 2175e35a7013b87d23bd1aceed25e17a9ba4ae52 Mon Sep 17 00:00:00 2001 From: domna Date: Tue, 26 Sep 2023 09:23:25 +0200 Subject: [PATCH 0307/1012] Addresses some of the comments --- contributed_definitions/NXmpes.nxdl.xml | 78 ++++++++++++------- contributed_definitions/NXresolution.nxdl.xml | 29 +++++++ contributed_definitions/nyaml/NXmpes.yaml | 48 +++++++++--- .../nyaml/NXresolution.yaml | 7 ++ 4 files changed, 123 insertions(+), 39 deletions(-) create mode 100644 contributed_definitions/NXresolution.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXresolution.yaml diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 2cdc6a0d73..8dfa73db49 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -2,9 +2,9 @@ + + + + + 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 @@ -116,7 +117,7 @@ - Specification of type, may also go to name. + Specification of type, may also go to name. @@ -129,10 +130,22 @@ + + + The beam emitted by this source. + Should be named with the same appendix, e.g., + for `source_probe` it should refer to `beam_probe`. + Refers to the same concept as /NXentry/NXinstrument/source_TYPE + and may be linked. + + - - - + + + + Distance of the point of evaluation of the beam from the sample surface. @@ -141,9 +154,19 @@ + + + + The beam emitted by this source. + Should be named with the same appendix, e.g., + for `beam_probe` it should refer to `source_probe`. + Refers to the same concept as /NXentry/NXinstrument/beam_TYPE + and may be linked. + + - + @@ -158,12 +181,9 @@ - + Scheme of the electron collection column. @@ -178,7 +198,11 @@ - + + + Labelling of the lens setting in use. + + @@ -243,10 +267,6 @@ - @@ -380,10 +400,10 @@ - + - Voltage applied to sample and sample holder. + Voltage applied to sample and sample holder. diff --git a/contributed_definitions/NXresolution.nxdl.xml b/contributed_definitions/NXresolution.nxdl.xml new file mode 100644 index 0000000000..0f61043a24 --- /dev/null +++ b/contributed_definitions/NXresolution.nxdl.xml @@ -0,0 +1,29 @@ + + + + + + Describes the resolution of a physical quantity. + + + diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 3190b0af73..496da42fe2 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -12,12 +12,14 @@ NXmpes(NXobject): end_time(NX_DATE_TIME): doc: | Datetime of the end of the measurement. + exists: recommended method: doc: | A name of the experimental method according to the `ISO 18115-1:2023`_ specification. .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + exists: recommended definition: \@version: enumeration: [NXmpes] @@ -47,10 +49,11 @@ NXmpes(NXobject): doc: | Author ID defined by https://orcid.org/. (NXinstrument): - energy_resolution(NX_FLOAT): - unit: NX_ENERGY + energy_resolution(NXresolution): exists: recommended - source_beam(NXsource): + resolution: + unit: NX_ENERGY + source_TYPE(NXsource): # Comment from mpes may workshop: # - Add linking between source and beam @@ -73,7 +76,26 @@ NXmpes(NXobject): Type of probe. In photoemission it's always photons, so the full NIAC list is restricted. enumeration: [photons] - beam_probe(NXbeam): + device_information(NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + associated_beam(NXbeam): + doc: | + The beam emitted by this source. + Should be named with the same appendix, e.g., + for `source_probe` it should refer to `beam_probe`. + Refers to the same concept as /NXentry/NXinstrument/source_TYPE + and may be linked. + + # It would be nice if we had the notion of linking in nexus or if + # we have a subdefinition NXlink to refer to a path. + # This would also be helpful for NXtransformations + beam_TYPE(NXbeam): # Comment from mpes may workshop: Add linking between source and beam @@ -91,8 +113,17 @@ NXmpes(NXobject): incident_polarization(NX_NUMBER): exists: recommended unit: NX_ANY + extent(NX_FLOAT): + exists: recommended + associated_source(NXsource): + doc: | + The beam emitted by this source. + Should be named with the same appendix, e.g., + for `beam_probe` it should refer to `source_probe`. + Refers to the same concept as /NXentry/NXinstrument/beam_TYPE + and may be linked. (NXelectronanalyser): - model(NXfabrication): + device_information(NXfabrication): exists: recommended vendor: exists: recommended @@ -121,9 +152,9 @@ NXmpes(NXobject): Scheme of the electron collection column. enumeration: [Standard, Angular dispersive, Spatial dispersive, Selective area, Deflector, PEEM, Momentum Microscope] mode: + doc: | + Labelling of the lens setting in use. exists: recommended - - # TODO: What does this refer to. It is currently not in the collection column base class projection: exists: recommended field_aperture(NXaperture): @@ -165,9 +196,6 @@ NXmpes(NXobject): enumeration: [DLD, Phosphor+CCD, Phosphor+CMOS, ECMOS, Anode, Multi-anode] (NXdata): exists: recommended - - # TODO: Anders Frisk on proposal page - # It could be a lot of raw data from a detector. Shpould be optional. \@signal: enumeration: [raw] raw(NX_NUMBER): diff --git a/contributed_definitions/nyaml/NXresolution.yaml b/contributed_definitions/nyaml/NXresolution.yaml new file mode 100644 index 0000000000..4dc33f0dca --- /dev/null +++ b/contributed_definitions/nyaml/NXresolution.yaml @@ -0,0 +1,7 @@ +category: base +doc: | + Describes the resolution of a physical quantity. +type: group +NXresolution: + resolution(NX_FLOAT): + unit: NX_ANY \ No newline at end of file From 8274c7dcedf647020fa40d78f11591eb1015e9df Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 27 Sep 2023 08:09:17 +0200 Subject: [PATCH 0308/1012] Cleaner docs for NXmpes --- manual/source/mpes-structure.rst | 42 +++++++++++++------------------- 1 file changed, 17 insertions(+), 25 deletions(-) diff --git a/manual/source/mpes-structure.rst b/manual/source/mpes-structure.rst index 3b0fd8394c..dc0e4a75db 100644 --- a/manual/source/mpes-structure.rst +++ b/manual/source/mpes-structure.rst @@ -1,29 +1,21 @@ .. _Mpes-Structure-Fairmat: -============================================== -B2/B3: Photoemission & core-level spectroscopy -============================================== - -.. index:: - IntroductionMpes1 - MpesAppDef1 - -.. _IntroductionMpes1: - -Introduction -############ - -Set of data storage objects to describe photoemission experiments including x-ray photoelectron spectroscopy (XPS), ultraviolet photoelectron spectroscopy (UPS), -hard x-ray photoelectron spectroscopy (HAXPES), angle-resolved photoemission spectroscopy (ARPES), two-photon photoemission (2PPE) -and photoemission electron microscopy (PEEM). We also included descriptors for advanced specializations, such as spin-resolution, time resolution, -near-ambient pressure conditions, dichroism etc. - -.. _MpesAppDef1: - -Application Definitions -####################### - -We created two new application definitions: +======================================= +Photoemission & core-level spectroscopy +======================================= + +The NXmpes application definition aims at describing any possible multidimensional PES setup. +Hence, it is very general and currently the only limitation to the data is that an energy +axis has to be present. +The general experimental techniques described by this application definitions are +photons in and photoelectrons out. +If you want NXmpes for such a techniques, changes are good you find something useful here. + +An example set of techniques covered by this application defintions are x-ray/UV photoelectron spectroscopy (XPS/UPS), +angle-resolved photoemission spectroscopy (ARPES), two-photon photoemission (2PPE) or +photoemission electron microscopy (PEEM). +We also include descriptors for advanced specializations, such as spin- and time-resolution, near-ambient pressure conditions, +dichroism and many more. :ref:`NXmpes`: - A general appdef with minimalistic metadata requirements, apt to describe all photemission experiments. + A general appdef with minimalistic metadata requirements to describe all photemission experiments. From ad12285a49cc26fca4d5a1d6871958451adcbd3e Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 27 Sep 2023 09:09:27 +0200 Subject: [PATCH 0309/1012] Adds proper NXresolution --- contributed_definitions/NXlink.nxdl.xml | 39 ++++++++++++++ contributed_definitions/NXmpes.nxdl.xml | 11 +++- contributed_definitions/NXresolution.nxdl.xml | 54 ++++++++++++++++++- contributed_definitions/nyaml/NXlink.yaml | 12 +++++ contributed_definitions/nyaml/NXmpes.yaml | 7 ++- .../nyaml/NXresolution.yaml | 39 +++++++++++++- 6 files changed, 156 insertions(+), 6 deletions(-) create mode 100644 contributed_definitions/NXlink.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXlink.yaml diff --git a/contributed_definitions/NXlink.nxdl.xml b/contributed_definitions/NXlink.nxdl.xml new file mode 100644 index 0000000000..d9bf2f2149 --- /dev/null +++ b/contributed_definitions/NXlink.nxdl.xml @@ -0,0 +1,39 @@ + + + + + + Describes a link + + + + The symbol by which to refer to this link, e.g., for formulas + + + + + A valid path inside an instance of an application definition, i.e., + of the form /entry/instrument/my_part/my_field + + + diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 8dfa73db49..ad32844635 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -87,7 +87,11 @@ - + + + + + - - - A sensor used to monitor an external condition - - The condition itself is described in :ref:`NXenvironment`. - - - Sensor identification code/model number - - - Name for the sensor - - - Short name of sensor used e.g. on monitor display program - - - where sensor is attached to ("sample" | "can") - - - - Defines the axes for logged vector quantities if they are not the global instrument axes. - - - - name for measured signal - - - - - - - - - - - - - - - - - - - The type of hardware used for the measurement. - Examples (suggestions but not restrictions): - - :Temperature: - J | K | T | E | R | S | Pt100 | Rh/Fe - :pH: - Hg/Hg2Cl2 | Ag/AgCl | ISFET - :Ion selective electrode: - specify species; e.g. Ca2+ - :Magnetic field: - Hall - :Surface pressure: - wilhelmy plate - - - - - Is data collection controlled or synchronised to this quantity: - 1=no, 0=to "value", 1=to "value_deriv1", etc. - - - - - Upper control bound of sensor reading if using run_control - - - - - Lower control bound of sensor reading if using run_control - - - - - nominal setpoint or average value - - need [n] as may be a vector - - - - - - - - Nominal/average first derivative of value - e.g. strain rate - - same dimensions as "value" (may be a vector) - - - - - - - - Nominal/average second derivative of value - - same dimensions as "value" (may be a vector) - - - - - - - Time history of sensor readings - - - Time history of first derivative of sensor readings - - - Time history of second derivative of sensor readings - - - - - - - - - - - - - For complex external fields not satisfied by External_field_brief - - - - This group describes the shape of the sensor when necessary. - - + + + A sensor used to monitor an external condition + + The condition itself is described in :ref:`NXenvironment`. + + + + Sensor identification code/model number + + + + + Name for the sensor + + + + + Short name of sensor used e.g. on monitor display program + + + + + where sensor is attached to ("sample" | "can") + + + + + Defines the axes for logged vector quantities if they are not the global + instrument axes. + + + + + name for measured signal + + + + + + + + + + + + + + + + + + + + The type of hardware used for the measurement. + Examples (suggestions but not restrictions): + + :Temperature: + J | K | T | E | R | S | Pt100 | Rh/Fe + :pH: + Hg/Hg2Cl2 | Ag/AgCl | ISFET + :Ion selective electrode: + specify species; e.g. Ca2+ + :Magnetic field: + Hall + :Surface pressure: + wilhelmy plate + + + + + Is data collection controlled or synchronised to this quantity: + 1=no, 0=to "value", 1=to "value_deriv1", etc. + + + + + Upper control bound of sensor reading if using run_control + + + + + Lower control bound of sensor reading if using run_control + + + + + nominal setpoint or average value + - need [n] as may be a vector + + + + + + + + Nominal/average first derivative of value + e.g. strain rate + - same dimensions as "value" (may be a vector) + + + + + + + + Nominal/average second derivative of value + - same dimensions as "value" (may be a vector) + + + + + + + + Time history of sensor readings + + + + + Time history of first derivative of sensor readings + + + + + Time history of second derivative of sensor readings + + + + + + + + + + + + + + + For complex external fields not satisfied by External_field_brief + + + + + This group describes the shape of the sensor when necessary. + + + - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a sensor. - + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a sensor. - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. - diff --git a/base_classes/NXsource.nxdl.xml b/base_classes/NXsource.nxdl.xml index 3fd1f983c7..a291384d3f 100644 --- a/base_classes/NXsource.nxdl.xml +++ b/base_classes/NXsource.nxdl.xml @@ -265,12 +265,13 @@ "Engineering" location of source. + This group describes the shape of the beam line component - + The wavelength or energy distribution of the source diff --git a/base_classes/nyaml/NXdetector.yaml b/base_classes/nyaml/NXdetector.yaml index 4caf8ef6ed..8fd286fc58 100644 --- a/base_classes/nyaml/NXdetector.yaml +++ b/base_classes/nyaml/NXdetector.yaml @@ -730,6 +730,7 @@ type: group unit: NX_UNITLESS doc: | Number of raw active elements in each dimension. Important for swept scans. + (NXfabrication): (NXdata): doc: | raw data output from the detector diff --git a/base_classes/nyaml/NXinstrument.yaml b/base_classes/nyaml/NXinstrument.yaml index d943f5d625..4607aa5ae5 100644 --- a/base_classes/nyaml/NXinstrument.yaml +++ b/base_classes/nyaml/NXinstrument.yaml @@ -49,6 +49,7 @@ NXinstrument(NXobject): (NXdetector_group): (NXdisk_chopper): (NXevent_data): + (NXfabrication): (NXfermi_chopper): (NXfilter): (NXflipper): diff --git a/base_classes/nyaml/NXsensor.yaml b/base_classes/nyaml/NXsensor.yaml index eeb3c54fe7..a70f2a533e 100644 --- a/base_classes/nyaml/NXsensor.yaml +++ b/base_classes/nyaml/NXsensor.yaml @@ -97,6 +97,7 @@ NXsensor(NXobject): exists: ['min', '0'] doc: | This group describes the shape of the sensor when necessary. + (NXfabrication): \@default: doc: | .. index:: plotting diff --git a/base_classes/nyaml/NXsource.yaml b/base_classes/nyaml/NXsource.yaml index 9c4ec8e26d..1692b666ea 100644 --- a/base_classes/nyaml/NXsource.yaml +++ b/base_classes/nyaml/NXsource.yaml @@ -162,11 +162,12 @@ NXsource(NXobject): Use the field `depends_on` and :ref:`NXtransformations` to position the source and NXoff_geometry to describe its shape instead doc: | "Engineering" location of source. + (NXfabrication): (NXoff_geometry): exists: ['min', '0'] doc: | This group describes the shape of the beam line component - (NXdata)distribution: + distribution(NXdata): doc: | The wavelength or energy distribution of the source \@default: diff --git a/contributed_definitions/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXcollectioncolumn.nxdl.xml index 3117648c3a..862b270c95 100644 --- a/contributed_definitions/NXcollectioncolumn.nxdl.xml +++ b/contributed_definitions/NXcollectioncolumn.nxdl.xml @@ -101,4 +101,5 @@ Individual lenses in the collection column section + diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml index 821edaae2d..3a7ac1db1e 100644 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + The symbols used in the schema to specify e.g. dimensions of arrays @@ -154,4 +154,5 @@ Individual lenses outside the main optics ensambles described by the subclasses + diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml index dd283a570b..6487fdb2ae 100644 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ b/contributed_definitions/NXenergydispersion.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + Subclass of NXelectronanalyser to describe the energy dispersion section of a photoelectron analyser. @@ -87,4 +87,5 @@ Individual lenses in the energy dispersive section + diff --git a/contributed_definitions/NXmanipulator.nxdl.xml b/contributed_definitions/NXmanipulator.nxdl.xml index ad59e06205..52d7330f40 100644 --- a/contributed_definitions/NXmanipulator.nxdl.xml +++ b/contributed_definitions/NXmanipulator.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + Extension of NXpositioner to include fields to describe the use of manipulators in photoemission experiments. @@ -79,6 +79,7 @@ Class to describe the motors that are used in the manipulator + Refers to the last transformation specifying the positon of the manipulator in diff --git a/contributed_definitions/nyaml/NXdetector.yaml b/contributed_definitions/nyaml/NXdetector.yaml new file mode 100644 index 0000000000..8fd286fc58 --- /dev/null +++ b/contributed_definitions/nyaml/NXdetector.yaml @@ -0,0 +1,1758 @@ +category: base +doc: | + A detector, detector bank, or multidetector. +symbols: + doc: | + These symbols will be used below to illustrate the coordination of the + rank and sizes of datasets and the preferred ordering of the + dimensions. Each of these are optional (so the rank of the datasets + will vary according to the situation) and the general ordering + principle is slowest to fastest. The type of each dimension should + follow the order of scan points, detector output (e.g. pixels), then + time-of-flight (i.e. spectroscopy, spectrometry). Note that the output + of a detector is not limited to single values (0D), lists (1D) and + images (2), but three or higher dimensional arrays can be produced by + a detector at each trigger. + nP: | + number of scan points (only present in scanning measurements) + i: | + number of detector pixels in the first (slowest) direction + j: | + number of detector pixels in the second (faster) direction + k: | + number of detector pixels in the third (if necessary, fastest) + direction + tof: | + number of bins in the time-of-flight histogram +type: group +(NXobject)NXdetector: + time_of_flight(NX_FLOAT): + unit: NX_TIME_OF_FLIGHT + doc: | + Total time of flight + dimensions: + rank: 1 + dim: [[1, tof+1]] + \@axis: + type: NX_POSINT + deprecated: | + see: https://github.com/nexusformat/definitions/issues/436 + enumeration: [3] + \@primary: + type: NX_POSINT + deprecated: | + see: https://github.com/nexusformat/definitions/issues/436 + enumeration: [1] + \@long_name: + doc: | + Total time of flight + raw_time_of_flight(NX_INT): + unit: NX_PULSES + doc: | + In DAQ clock pulses + dimensions: + rank: 1 + dim: [[1, tof+1]] + \@frequency: + type: NX_NUMBER + doc: | + Clock frequency in Hz + detector_number(NX_INT): + doc: | + Identifier for detector (pixels) + Can be multidimensional, if needed + data(NX_NUMBER): + unit: NX_ANY + doc: | + 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. + dimensions: + rank: 4 + dim: [[1, nP], [2, i], [3, j], [4, tof]] + \@long_name: + doc: | + Title of measurement + \@check_sum: + type: NX_INT + doc: | + Integral of data as check of data integrity + data_errors(NX_NUMBER): + unit: NX_ANY + doc: | + The best estimate of the uncertainty in the data value (array size should match the data field). Where + possible, this should be the standard deviation, which has the same units + as the data. The form data_error is deprecated. + dimensions: + rank: 4 + dim: [[1, nP], [2, i], [3, j], [4, tof]] + x_pixel_offset(NX_FLOAT): + unit: NX_LENGTH + doc: | + Offset from the detector center in x-direction. + Can be multidimensional when needed. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + \@axis: + type: NX_POSINT + deprecated: | + see: https://github.com/nexusformat/definitions/issues/436 + enumeration: [1] + \@primary: + type: NX_POSINT + deprecated: | + see: https://github.com/nexusformat/definitions/issues/436 + enumeration: [1] + \@long_name: + doc: | + x-axis offset from detector center + y_pixel_offset(NX_FLOAT): + unit: NX_LENGTH + doc: | + Offset from the detector center in the y-direction. + Can be multidimensional when different values are required for each pixel. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + \@axis: + type: NX_POSINT + deprecated: | + see: https://github.com/nexusformat/definitions/issues/436 + enumeration: [2] + \@primary: + type: NX_POSINT + deprecated: | + see: https://github.com/nexusformat/definitions/issues/436 + enumeration: [1] + \@long_name: + doc: | + y-axis offset from detector center + z_pixel_offset(NX_FLOAT): + unit: NX_LENGTH + doc: | + Offset from the detector center in the z-direction. + Can be multidimensional when different values are required for each pixel. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + \@axis: + type: NX_POSINT + deprecated: | + see: https://github.com/nexusformat/definitions/issues/436 + enumeration: [3] + \@primary: + type: NX_POSINT + deprecated: | + see: https://github.com/nexusformat/definitions/issues/436 + enumeration: [1] + \@long_name: + doc: | + y-axis offset from detector center + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the distance to the previous component in the + instrument; most often the sample. The usage depends on the + nature of the detector: Most often it is the distance of the + detector assembly. But there are irregular detectors. In this + case the distance must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. + dimensions: + rank: 3 + dim: [[1, nP], [2, i], [3, j]] + polar_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + This is the polar angle of the detector towards the previous + component in the instrument; most often the sample. + The usage depends on the + nature of the detector. + Most often it is the polar_angle of the detector assembly. + But there are irregular detectors. + In this + case, the polar_angle must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. + dimensions: + rank: 3 + dim: [[1, nP], [2, i], [3, j]] + azimuthal_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + This is the azimuthal angle angle of the detector towards + the previous component in the instrument; most often the sample. + The usage depends on the + nature of the detector. + Most often it is the azimuthal_angle of the detector assembly. + But there are irregular detectors. + In this + case, the azimuthal_angle must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. + dimensions: + rank: 3 + dim: [[1, nP], [2, i], [3, j]] + description: + doc: | + name/manufacturer/model/etc. information + serial_number: + doc: | + Serial number for the detector + local_name: + doc: | + Local name for the detector + (NXgeometry): + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the detector and NXoff_geometry to describe its shape instead + doc: | + Position and orientation of detector + solid_angle(NX_FLOAT): + unit: NX_SOLID_ANGLE + doc: | + Solid angle subtended by the detector at the sample + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + x_pixel_size(NX_FLOAT): + unit: NX_LENGTH + doc: | + Size of each detector pixel. If it is scalar all pixels are the same size. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + y_pixel_size(NX_FLOAT): + unit: NX_LENGTH + doc: | + Size of each detector pixel. If it is scalar all pixels are the same size + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + dead_time(NX_FLOAT): + unit: NX_TIME + doc: | + Detector dead time + dimensions: + rank: 3 + dim: [[1, nP], [2, i], [3, j]] + gas_pressure(NX_FLOAT): + unit: NX_PRESSURE + doc: | + Detector gas pressure + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + detection_gas_path(NX_FLOAT): + unit: NX_LENGTH + doc: | + maximum drift space dimension + crate(NX_INT): + doc: | + Crate number of detector + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + \@local_name: + doc: | + Equivalent local term + slot(NX_INT): + doc: | + Slot number of detector + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + \@local_name: + doc: | + Equivalent local term + input(NX_INT): + doc: | + Input number of detector + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + \@local_name: + doc: | + Equivalent local term + type: + doc: | + Description of type such as He3 gas cylinder, He3 PSD, scintillator, + fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, + CMOS, ... + efficiency(NXdata): + doc: | + Spectral efficiency of detector with respect to e.g. wavelength + \@signal: + enumeration: [efficiency] + \@axes: + + # TODO: clarify the various use cases + enumeration: [., . ., . . ., . . . ., wavelength] + \@wavelength_indices: + + # TODO: clarify the actual possibilities + enumeration: [0] + efficiency(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + efficiency of the detector + dimensions: + rank: 3 + dim: [[1, i], [2, j], [3, k]] + wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + This field can be two things: + + 1. For a pixel detector it provides the nominal wavelength + for which the detector has been calibrated. + + 2. For other detectors this field has to be seen together with + the efficiency field above. + For some detectors, the efficiency is wavelength dependent. + Thus this field provides the wavelength axis for the efficiency field. + In this use case, the efficiency and wavelength arrays must + have the same dimensionality. + dimensions: + rank: 3 + dim: [[1, i], [2, j], [3, k]] + real_time(NX_NUMBER): + unit: NX_TIME + doc: | + Real-time of the exposure (use this if exposure time varies for + each array element, otherwise use ``count_time`` field). + + Most often there is a single real time value that is constant across + an entire image frame. In such cases, only a 1-D array is needed. + But there are detectors in which the real time + changes per pixel. In that case, more than one dimension is needed. Therefore + the rank of this field should be less than or equal to (detector rank + 1). + dimensions: + rank: 3 + dim: [[1, nP], [2, i], [3, j]] + start_time(NX_FLOAT): + unit: NX_TIME + doc: | + start time for each frame, with the ``start`` attribute as absolute reference + dimensions: + rank: 1 + dim: [[1, nP]] + \@start: + type: NX_DATE_TIME + stop_time(NX_FLOAT): + unit: NX_TIME + doc: | + stop time for each frame, with the ``start`` attribute as absolute reference + dimensions: + rank: 1 + dim: [[1, nP]] + \@start: + type: NX_DATE_TIME + calibration_date(NX_DATE_TIME): + doc: | + date of last calibration (geometry and/or efficiency) measurements + calibration_method(NXnote): + doc: | + summary of conversion of array data to pixels (e.g. polynomial + approximations) and location of details of the calibrations + layout: + doc: | + How the detector is represented + enumeration: [point, linear, area] + count_time(NX_NUMBER): + unit: NX_TIME + doc: | + Elapsed actual counting time + dimensions: + rank: 1 + dim: [[1, nP]] + data_file(NXnote): + (NXcollection): + doc: | + Use this group to provide other data related to this NXdetector group. + sequence_number(NX_INT): + doc: | + In order to properly sort the order of the images taken in (for + example) a tomography experiment, a sequence number is stored with each + image. + dimensions: + rank: 1 + dim: [[1, nBrightFrames]] + beam_center_x(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the x position where the direct beam would hit the detector. + This is a length and can be outside of the actual + detector. The length can be in physical units or pixels + as documented by the units attribute. + beam_center_y(NX_FLOAT): + unit: NX_LENGTH + doc: | + This is the y position where the direct beam would hit the detector. + This is a length and can be outside of the actual + detector. The length can be in physical units or pixels + as documented by the units attribute. + frame_start_number(NX_INT): + doc: | + This is the start number of the first frame of a scan. In protein crystallography measurements one + often scans a couple of frames on a give sample, then does something else, + then returns to the same sample and scans some more frames. Each time with + a new data file. This number helps concatenating such measurements. + diameter(NX_FLOAT): + unit: NX_LENGTH + doc: | + The diameter of a cylindrical detector + acquisition_mode(NX_CHAR): + doc: | + The acquisition mode of the detector. + enumeration: [gated, triggered, summed, event, histogrammed, decimated] + angular_calibration_applied(NX_BOOLEAN): + doc: | + True when the angular calibration has been applied in the + electronics, false otherwise. + angular_calibration(NX_FLOAT): + doc: | + Angular calibration data. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + flatfield_applied(NX_BOOLEAN): + doc: | + True when the flat field correction has been applied in the + electronics, false otherwise. + flatfield(NX_FLOAT): + doc: | + Flat field correction data. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + flatfield_errors(NX_FLOAT): + doc: | + Errors of the flat field correction data. + The form flatfield_error is deprecated. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + pixel_mask_applied(NX_BOOLEAN): + doc: | + True when the pixel mask correction has been applied in the + electronics, false otherwise. + pixel_mask(NX_INT): + doc: | + The 32-bit pixel mask for the detector. Can be either one mask + for the whole dataset (i.e. an array with indices i, j) or + each frame can have its own mask (in which case it would be + an array with indices np, i, j). + + Contains a bit field for each pixel to signal dead, + blind or high or otherwise unwanted or undesirable pixels. + They have the following meaning: + + .. can't make a table here, a bullet list will have to do for now + + * bit 0: gap (pixel with no sensor) + * bit 1: dead + * bit 2: under responding + * bit 3: over responding + * bit 4: noisy + * bit 5: -undefined- + * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) + * bit 7: -undefined- + * bit 8: user defined mask (e.g. around beamstop) + * bits 9-30: -undefined- + * bit 31: virtual pixel (corner pixel with interpolated value) + + Normal data analysis software would + not take pixels into account + when a bit in (mask & 0x0000FFFF) is + set. Tag bit in the upper + two bytes would indicate special pixel + properties that normally + would not be a sole reason to reject the + intensity value (unless + lower bits are set. + + If the full bit depths is not required, providing a + mask with fewer bits is permissible. + + If needed, additional pixel masks can be specified by + including additional entries named pixel_mask_N, where + N is an integer. For example, a general bad pixel mask + could be specified in pixel_mask that indicates noisy + and dead pixels, and an additional pixel mask from + experiment-specific shadowing could be specified in + pixel_mask_2. The cumulative mask is the bitwise OR + of pixel_mask and any pixel_mask_N entries. + dimensions: + rank: 2 + dim: [[1, i], [2, j]] + image_key(NX_INT): + doc: | + This field allow to distinguish different types of exposure to the same detector "data" field. + Some techniques require frequent (re-)calibration inbetween measuremnts and this way of + recording the different measurements preserves the chronological order with is important for + correct processing. + + This is used for example in tomography (`:ref:`NXtomo`) sample projections, + dark and flat images, a magic number is recorded per frame. + + The key is as follows: + + * projection (sample) = 0 + * flat field = 1 + * dark field = 2 + * invalid = 3 + * background (no sample, but buffer where applicable) = 4 + + In cases where the data is of type :ref:`NXlog` this can also be an NXlog. + dimensions: + rank: 1 + dim: [[1, np]] + countrate_correction_applied(NX_BOOLEAN): + doc: | + Counting detectors usually are not able to measure all incoming particles, + especially at higher count-rates. Count-rate correction is applied to + account for these errors. + + True when count-rate correction has been applied, false otherwise. + countrate_correction_lookup_table(NX_NUMBER): + doc: | + The countrate_correction_lookup_table defines the LUT used for count-rate + correction. It maps a measured count :math:`c` to its corrected value + :math:`countrate\_correction\_lookup\_table[c]`. + + :math:`m` denotes the length of the table. + dimensions: + rank: 1 + dim: [[1, m]] + virtual_pixel_interpolation_applied(NX_BOOLEAN): + doc: | + True when virtual pixel interpolation has been applied, false otherwise. + + When virtual pixel interpolation is applied, values of some pixels may + contain interpolated values. For example, to account for space between + readout chips on a module, physical pixels on edges and corners between + chips may have larger sensor areas and counts may be distributed between + their logical pixels. + bit_depth_readout(NX_INT): + doc: | + How many bits the electronics reads per pixel. + With CCD's and single photon counting detectors, + this must not align with traditional integer sizes. + This can be 4, 8, 12, 14, 16, ... + detector_readout_time(NX_FLOAT): + unit: NX_TIME + doc: | + Time it takes to read the detector (typically milliseconds). + This is important to know for time resolved experiments. + trigger_delay_time(NX_FLOAT): + unit: NX_TIME + doc: | + Time it takes to start exposure after a trigger signal has been received. + This is the reaction time of the detector firmware after receiving the trigger signal + to when the detector starts to acquire the exposure, including any user set delay.. + This is important to know for time resolved experiments. + trigger_delay_time_set(NX_FLOAT): + unit: NX_TIME + doc: | + User-specified trigger delay. + trigger_internal_delay_time(NX_FLOAT): + unit: NX_TIME + doc: | + Time it takes to start exposure after a trigger signal has been received. + This is the reaction time of the detector hardware after receiving the + trigger signal to when the detector starts to acquire the exposure. + It forms the lower boundary of the trigger_delay_time when the user + does not request an additional delay. + trigger_dead_time(NX_FLOAT): + unit: NX_TIME + doc: | + Time during which no new trigger signal can be accepted. + Typically this is the + trigger_delay_time + exposure_time + readout_time. + This is important to know for time resolved experiments. + frame_time(NX_FLOAT): + unit: NX_TIME + doc: | + This is time for each frame. This is exposure_time + readout time. + dimensions: + rank: 1 + dim: [[1, nP]] + gain_setting(NX_CHAR): + doc: | + The gain setting of the detector. This is a detector-specific value + meant to document the gain setting of the detector during data + collection, for detectors with multiple available gain settings. + + Examples of gain settings include: + + * ``standard`` + * ``fast`` + * ``auto`` + * ``high`` + * ``medium`` + * ``low`` + * ``mixed high to medium`` + * ``mixed medium to low`` + + Developers are encouraged to use one of these terms, or to submit + additional terms to add to the list. + saturation_value(NX_NUMBER): + doc: | + The value at which the detector goes into saturation. + Especially common to CCD detectors, the data + is known to be invalid above this value. + + For example, given a saturation_value and an underload_value, the valid + pixels are those less than or equal to the saturation_value and greater + than or equal to the underload_value. + + The precise type should match the type of the data. + underload_value(NX_NUMBER): + doc: | + The lowest value at which pixels for this detector would be reasonably + measured. The data is known to be invalid below this value. + + For example, given a saturation_value and an underload_value, the valid + pixels are those less than or equal to the saturation_value and greater + than or equal to the underload_value. + + The precise type should match the type of the data. + number_of_cycles(NX_INT): + doc: | + CCD images are sometimes constructed by summing + together multiple short exposures in the + electronics. This reduces background etc. + This is the number of short exposures used to sum + images for an image. + sensor_material(NX_CHAR): + doc: | + At times, radiation is not directly sensed by the detector. + Rather, the detector might sense the output from some + converter like a scintillator. + This is the name of this converter material. + sensor_thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + At times, radiation is not directly sensed by the detector. + Rather, the detector might sense the output from some + converter like a scintillator. + This is the thickness of this converter material. + threshold_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + Single photon counter detectors can be adjusted + for a certain energy range in which they + work optimally. This is the energy setting for this. + (NXdetector_module): + doc: | + For use in special cases where the data in NXdetector + is represented in several parts, each with a separate geometry. + pixel_shape(choice): + (NXoff_geometry): + doc: | + Shape description of each pixel. Use only if all pixels in the detector + are of uniform shape. + (NXcylindrical_geometry): + doc: | + Shape description of each pixel. Use only if all pixels in the detector + are of uniform shape and require being described by cylinders. + detector_shape(choice): + (NXoff_geometry): + doc: | + Shape description of the whole detector. Use only if pixels in the + detector are not of uniform shape. + (NXcylindrical_geometry): + doc: | + Shape description of the whole detector. Use only if pixels in the + detector are not of uniform shape and require being described by cylinders. + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + amplifier_type(NX_CHAR): + doc: | + Type of electron amplifier, MCP, channeltron, etc. + detector_type(NX_CHAR): + doc: | + Description of the detector type, DLD, Phosphor+CCD, CMOS. + detector_voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Voltage applied to detector. + amplifier_voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Voltage applied to the amplifier. + amplifier_bias(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + The low voltage of the amplifier migh not be the ground. + sensor_size(NX_FLOAT): + unit: NX_LENGTH + doc: | + Size of each imaging sensor chip on the detector. + sensor_count(NX_INT): + unit: NX_UNITLESS + doc: | + Number of imaging sensor chips on the detector. + sensor_pixel_size(NX_FLOAT): + unit: NX_LENGTH + doc: | + Physical size of the pixels of the imaging chip on the detector. + sensor_pixels(NX_INT): + unit: NX_UNITLESS + doc: | + Number of raw active elements in each dimension. Important for swept scans. + (NXfabrication): + (NXdata): + doc: | + raw data output from the detector + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference point of the detector is the center of the first pixel. + In complex geometries the NXoff_geometry groups can be used to provide an unambiguous reference. + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 6b256ef0615dca7d8faf4a3bc04d3e62f29a1745e9cd35205e5f0bb9e2c6520c +# +# +# +# +# +# +# These symbols will be used below to illustrate the coordination of the +# rank and sizes of datasets and the preferred ordering of the +# dimensions. Each of these are optional (so the rank of the datasets +# will vary according to the situation) and the general ordering +# principle is slowest to fastest. The type of each dimension should +# follow the order of scan points, detector output (e.g. pixels), then +# time-of-flight (i.e. spectroscopy, spectrometry). Note that the output +# of a detector is not limited to single values (0D), lists (1D) and +# images (2), but three or higher dimensional arrays can be produced by +# a detector at each trigger. +# +# +# +# number of scan points (only present in scanning measurements) +# +# +# +# +# number of detector pixels in the first (slowest) direction +# +# +# +# +# number of detector pixels in the second (faster) direction +# +# +# +# +# number of detector pixels in the third (if necessary, fastest) +# direction +# +# +# +# +# number of bins in the time-of-flight histogram +# +# +# +# +# A detector, detector bank, or multidetector. +# +# +# +# Total time of flight +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Total time of flight +# +# +# +# +# +# In DAQ clock pulses +# +# +# +# +# +# +# Clock frequency in Hz +# +# +# +# +# +# Identifier for detector (pixels) +# Can be multidimensional, if needed +# +# +# +# +# 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. +# +# +# +# +# +# +# +# +# +# Title of measurement +# +# +# +# +# Integral of data as check of data integrity +# +# +# +# +# +# The best estimate of the uncertainty in the data value (array size should match the data field). Where +# possible, this should be the standard deviation, which has the same units +# as the data. The form data_error is deprecated. +# +# +# +# +# +# +# +# +# +# +# Offset from the detector center in x-direction. +# Can be multidimensional when needed. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# x-axis offset from detector center +# +# +# +# +# +# Offset from the detector center in the y-direction. +# Can be multidimensional when different values are required for each pixel. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# y-axis offset from detector center +# +# +# +# +# +# Offset from the detector center in the z-direction. +# Can be multidimensional when different values are required for each pixel. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# y-axis offset from detector center +# +# +# +# +# +# This is the distance to the previous component in the +# instrument; most often the sample. The usage depends on the +# nature of the detector: Most often it is the distance of the +# detector assembly. But there are irregular detectors. In this +# case the distance must be specified for each detector pixel. +# +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# +# +# +# +# +# This is the polar angle of the detector towards the previous +# component in the instrument; most often the sample. +# The usage depends on the +# nature of the detector. +# Most often it is the polar_angle of the detector assembly. +# But there are irregular detectors. +# In this +# case, the polar_angle must be specified for each detector pixel. +# +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# +# +# +# +# +# This is the azimuthal angle angle of the detector towards +# the previous component in the instrument; most often the sample. +# The usage depends on the +# nature of the detector. +# Most often it is the azimuthal_angle of the detector assembly. +# But there are irregular detectors. +# In this +# case, the azimuthal_angle must be specified for each detector pixel. +# +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# +# +# +# +# +# name/manufacturer/model/etc. information +# +# +# +# +# Serial number for the detector +# +# +# +# +# Local name for the detector +# +# +# +# +# Position and orientation of detector +# +# +# +# +# Solid angle subtended by the detector at the sample +# +# +# +# +# +# +# +# +# Size of each detector pixel. If it is scalar all pixels are the same size. +# +# +# +# +# +# +# +# +# Size of each detector pixel. If it is scalar all pixels are the same size +# +# +# +# +# +# +# +# +# Detector dead time +# +# +# +# +# +# +# +# +# +# Detector gas pressure +# +# +# +# +# +# +# +# +# maximum drift space dimension +# +# +# +# +# Crate number of detector +# +# +# +# +# +# +# +# Equivalent local term +# +# +# +# +# +# Slot number of detector +# +# +# +# +# +# +# +# Equivalent local term +# +# +# +# +# +# Input number of detector +# +# +# +# +# +# +# +# Equivalent local term +# +# +# +# +# +# Description of type such as He3 gas cylinder, He3 PSD, scintillator, +# fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, +# CMOS, ... +# +# +# +# +# Spectral efficiency of detector with respect to e.g. wavelength +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# efficiency of the detector +# +# +# +# +# +# +# +# +# +# This field can be two things: +# +# 1. For a pixel detector it provides the nominal wavelength +# for which the detector has been calibrated. +# +# 2. For other detectors this field has to be seen together with +# the efficiency field above. +# For some detectors, the efficiency is wavelength dependent. +# Thus this field provides the wavelength axis for the efficiency field. +# In this use case, the efficiency and wavelength arrays must +# have the same dimensionality. +# +# +# +# +# +# +# +# +# +# +# Real-time of the exposure (use this if exposure time varies for +# each array element, otherwise use ``count_time`` field). +# +# Most often there is a single real time value that is constant across +# an entire image frame. In such cases, only a 1-D array is needed. +# But there are detectors in which the real time +# changes per pixel. In that case, more than one dimension is needed. Therefore +# the rank of this field should be less than or equal to (detector rank + 1). +# +# +# +# +# +# +# +# +# +# start time for each frame, with the ``start`` attribute as absolute reference +# +# +# +# +# +# +# +# +# stop time for each frame, with the ``start`` attribute as absolute reference +# +# +# +# +# +# +# +# +# date of last calibration (geometry and/or efficiency) measurements +# +# +# +# +# summary of conversion of array data to pixels (e.g. polynomial +# approximations) and location of details of the calibrations +# +# +# +# +# How the detector is represented +# +# +# +# +# +# +# +# +# +# Elapsed actual counting time +# +# +# +# +# +# +# +# +# Use this group to provide other data related to this NXdetector group. +# +# +# +# +# In order to properly sort the order of the images taken in (for +# example) a tomography experiment, a sequence number is stored with each +# image. +# +# +# +# +# +# +# +# This is the x position where the direct beam would hit the detector. +# This is a length and can be outside of the actual +# detector. The length can be in physical units or pixels +# as documented by the units attribute. +# +# +# +# +# This is the y position where the direct beam would hit the detector. +# This is a length and can be outside of the actual +# detector. The length can be in physical units or pixels +# as documented by the units attribute. +# +# +# +# +# This is the start number of the first frame of a scan. In protein crystallography measurements one +# often scans a couple of frames on a give sample, then does something else, +# then returns to the same sample and scans some more frames. Each time with +# a new data file. This number helps concatenating such measurements. +# +# +# +# +# The diameter of a cylindrical detector +# +# +# +# +# The acquisition mode of the detector. +# +# +# +# +# +# +# +# +# +# +# +# +# True when the angular calibration has been applied in the +# electronics, false otherwise. +# +# +# +# +# Angular calibration data. +# +# +# +# +# +# +# +# +# True when the flat field correction has been applied in the +# electronics, false otherwise. +# +# +# +# +# Flat field correction data. +# +# +# +# +# +# +# +# +# Errors of the flat field correction data. +# The form flatfield_error is deprecated. +# +# +# +# +# +# +# +# +# True when the pixel mask correction has been applied in the +# electronics, false otherwise. +# +# +# +# +# The 32-bit pixel mask for the detector. Can be either one mask +# for the whole dataset (i.e. an array with indices i, j) or +# each frame can have its own mask (in which case it would be +# an array with indices np, i, j). +# +# Contains a bit field for each pixel to signal dead, +# blind or high or otherwise unwanted or undesirable pixels. +# They have the following meaning: +# +# .. can't make a table here, a bullet list will have to do for now +# +# * bit 0: gap (pixel with no sensor) +# * bit 1: dead +# * bit 2: under responding +# * bit 3: over responding +# * bit 4: noisy +# * bit 5: -undefined- +# * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) +# * bit 7: -undefined- +# * bit 8: user defined mask (e.g. around beamstop) +# * bits 9-30: -undefined- +# * bit 31: virtual pixel (corner pixel with interpolated value) +# +# Normal data analysis software would +# not take pixels into account +# when a bit in (mask & 0x0000FFFF) is +# set. Tag bit in the upper +# two bytes would indicate special pixel +# properties that normally +# would not be a sole reason to reject the +# intensity value (unless +# lower bits are set. +# +# If the full bit depths is not required, providing a +# mask with fewer bits is permissible. +# +# If needed, additional pixel masks can be specified by +# including additional entries named pixel_mask_N, where +# N is an integer. For example, a general bad pixel mask +# could be specified in pixel_mask that indicates noisy +# and dead pixels, and an additional pixel mask from +# experiment-specific shadowing could be specified in +# pixel_mask_2. The cumulative mask is the bitwise OR +# of pixel_mask and any pixel_mask_N entries. +# +# +# +# +# +# +# +# +# This field allow to distinguish different types of exposure to the same detector "data" field. +# Some techniques require frequent (re-)calibration inbetween measuremnts and this way of +# recording the different measurements preserves the chronological order with is important for +# correct processing. +# +# This is used for example in tomography (`:ref:`NXtomo`) sample projections, +# dark and flat images, a magic number is recorded per frame. +# +# The key is as follows: +# +# * projection (sample) = 0 +# * flat field = 1 +# * dark field = 2 +# * invalid = 3 +# * background (no sample, but buffer where applicable) = 4 +# +# In cases where the data is of type :ref:`NXlog` this can also be an NXlog. +# +# +# +# +# +# +# +# Counting detectors usually are not able to measure all incoming particles, +# especially at higher count-rates. Count-rate correction is applied to +# account for these errors. +# +# True when count-rate correction has been applied, false otherwise. +# +# +# +# +# The countrate_correction_lookup_table defines the LUT used for count-rate +# correction. It maps a measured count :math:`c` to its corrected value +# :math:`countrate\_correction\_lookup\_table[c]`. +# +# :math:`m` denotes the length of the table. +# +# +# +# +# +# +# +# True when virtual pixel interpolation has been applied, false otherwise. +# +# When virtual pixel interpolation is applied, values of some pixels may +# contain interpolated values. For example, to account for space between +# readout chips on a module, physical pixels on edges and corners between +# chips may have larger sensor areas and counts may be distributed between +# their logical pixels. +# +# +# +# +# How many bits the electronics reads per pixel. +# With CCD's and single photon counting detectors, +# this must not align with traditional integer sizes. +# This can be 4, 8, 12, 14, 16, ... +# +# +# +# +# Time it takes to read the detector (typically milliseconds). +# This is important to know for time resolved experiments. +# +# +# +# +# Time it takes to start exposure after a trigger signal has been received. +# This is the reaction time of the detector firmware after receiving the trigger signal +# to when the detector starts to acquire the exposure, including any user set delay.. +# This is important to know for time resolved experiments. +# +# +# +# +# User-specified trigger delay. +# +# +# +# +# Time it takes to start exposure after a trigger signal has been received. +# This is the reaction time of the detector hardware after receiving the +# trigger signal to when the detector starts to acquire the exposure. +# It forms the lower boundary of the trigger_delay_time when the user +# does not request an additional delay. +# +# +# +# +# Time during which no new trigger signal can be accepted. +# Typically this is the +# trigger_delay_time + exposure_time + readout_time. +# This is important to know for time resolved experiments. +# +# +# +# +# This is time for each frame. This is exposure_time + readout time. +# +# +# +# +# +# +# +# The gain setting of the detector. This is a detector-specific value +# meant to document the gain setting of the detector during data +# collection, for detectors with multiple available gain settings. +# +# Examples of gain settings include: +# +# * ``standard`` +# * ``fast`` +# * ``auto`` +# * ``high`` +# * ``medium`` +# * ``low`` +# * ``mixed high to medium`` +# * ``mixed medium to low`` +# +# Developers are encouraged to use one of these terms, or to submit +# additional terms to add to the list. +# +# +# +# +# The value at which the detector goes into saturation. +# Especially common to CCD detectors, the data +# is known to be invalid above this value. +# +# For example, given a saturation_value and an underload_value, the valid +# pixels are those less than or equal to the saturation_value and greater +# than or equal to the underload_value. +# +# The precise type should match the type of the data. +# +# +# +# +# The lowest value at which pixels for this detector would be reasonably +# measured. The data is known to be invalid below this value. +# +# For example, given a saturation_value and an underload_value, the valid +# pixels are those less than or equal to the saturation_value and greater +# than or equal to the underload_value. +# +# The precise type should match the type of the data. +# +# +# +# +# CCD images are sometimes constructed by summing +# together multiple short exposures in the +# electronics. This reduces background etc. +# This is the number of short exposures used to sum +# images for an image. +# +# +# +# +# At times, radiation is not directly sensed by the detector. +# Rather, the detector might sense the output from some +# converter like a scintillator. +# This is the name of this converter material. +# +# +# +# +# At times, radiation is not directly sensed by the detector. +# Rather, the detector might sense the output from some +# converter like a scintillator. +# This is the thickness of this converter material. +# +# +# +# +# Single photon counter detectors can be adjusted +# for a certain energy range in which they +# work optimally. This is the energy setting for this. +# +# +# +# +# For use in special cases where the data in NXdetector +# is represented in several parts, each with a separate geometry. +# +# +# +# +# +# Shape description of each pixel. Use only if all pixels in the detector +# are of uniform shape. +# +# +# +# +# Shape description of each pixel. Use only if all pixels in the detector +# are of uniform shape and require being described by cylinders. +# +# +# +# +# +# +# Shape description of the whole detector. Use only if pixels in the +# detector are not of uniform shape. +# +# +# +# +# Shape description of the whole detector. Use only if pixels in the +# detector are not of uniform shape and require being described by cylinders. +# +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# Type of electron amplifier, MCP, channeltron, etc. +# +# +# +# +# Description of the detector type, DLD, Phosphor+CCD, CMOS. +# +# +# +# +# Voltage applied to detector. +# +# +# +# +# Voltage applied to the amplifier. +# +# +# +# +# The low voltage of the amplifier migh not be the ground. +# +# +# +# +# Size of each imaging sensor chip on the detector. +# +# +# +# +# Number of imaging sensor chips on the detector. +# +# +# +# +# Physical size of the pixels of the imaging chip on the detector. +# +# +# +# +# Number of raw active elements in each dimension. Important for swept scans. +# +# +# +# +# raw data output from the detector +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# The reference point of the detector is the center of the first pixel. +# In complex geometries the NXoff_geometry groups can be used to provide an unambiguous reference. +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# diff --git a/contributed_definitions/nyaml/NXinstrument.yaml b/contributed_definitions/nyaml/NXinstrument.yaml new file mode 100644 index 0000000000..4607aa5ae5 --- /dev/null +++ b/contributed_definitions/nyaml/NXinstrument.yaml @@ -0,0 +1,190 @@ +category: base +doc: | + 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. +type: group +NXinstrument(NXobject): + name: + doc: | + Name of instrument + \@short_name: + doc: | + short name for instrument, perhaps the acronym + energy_resolution(NX_FLOAT): + unit: NX_ENERGY + doc: | + Energy resolution of the experiment (FWHM or gaussian broadening) + momentum_resolution(NX_FLOAT): + unit: NX_WAVENUMBER + doc: | + Momentum resolution of the experiment (FWHM) + angular_resolution(NX_FLOAT): + unit: NX_ANGLE + doc: | + Angular resolution of the experiment (FWHM) + spatial_resolution(NX_FLOAT): + unit: NX_LENGTH + doc: | + Spatial resolution of the experiment (Airy disk radius) + temporal_resolution(NX_FLOAT): + unit: NX_TIME + doc: | + Temporal resolution of the experiment (FWHM) + (NXaperture): + (NXattenuator): + (NXbeam): + (NXbeam_stop): + (NXbending_magnet): + (NXcollimator): + (NXcollection): + (NXcapillary): + (NXcrystal): + (NXdetector): + (NXdetector_group): + (NXdisk_chopper): + (NXevent_data): + (NXfabrication): + (NXfermi_chopper): + (NXfilter): + (NXflipper): + (NXguide): + (NXinsertion_device): + (NXmirror): + (NXmoderator): + (NXmonochromator): + (NXpolarizer): + (NXpositioner): + (NXsource): + (NXtransformations)DIFFRACTOMETER: + (NXvelocity_selector): + (NXxraylens): + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 331d6037bd4c05402a42cab90e3df4c3115b21231d57ef54b1221e1ed859584d +# +# +# +# +# +# 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. +# +# +# +# Name of instrument +# +# +# +# short name for instrument, perhaps the acronym +# +# +# +# +# +# Energy resolution of the experiment (FWHM or gaussian broadening) +# +# +# +# +# Momentum resolution of the experiment (FWHM) +# +# +# +# +# Angular resolution of the experiment (FWHM) +# +# +# +# +# Spatial resolution of the experiment (Airy disk radius) +# +# +# +# +# Temporal resolution of the experiment (FWHM) +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# diff --git a/contributed_definitions/nyaml/NXsensor.yaml b/contributed_definitions/nyaml/NXsensor.yaml new file mode 100644 index 0000000000..a70f2a533e --- /dev/null +++ b/contributed_definitions/nyaml/NXsensor.yaml @@ -0,0 +1,324 @@ +category: base +doc: | + A sensor used to monitor an external condition + + The condition itself is described in :ref:`NXenvironment`. +type: group +NXsensor(NXobject): + model: + doc: | + Sensor identification code/model number + name: + doc: | + Name for the sensor + short_name: + doc: | + Short name of sensor used e.g. on monitor display program + attached_to: + doc: | + where sensor is attached to ("sample" | "can") + geometry(NXgeometry): + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the beamstop and NXoff_geometry to describe its shape instead + doc: | + Defines the axes for logged vector quantities if they are not the global instrument axes. + measurement: + doc: | + name for measured signal + enumeration: [temperature, pH, magnetic_field, electric_field, conductivity, resistance, voltage, pressure, flow, stress, strain, shear, surface_pressure] + type: + doc: | + The type of hardware used for the measurement. + Examples (suggestions but not restrictions): + + :Temperature: + J | K | T | E | R | S | Pt100 | Rh/Fe + :pH: + Hg/Hg2Cl2 | Ag/AgCl | ISFET + :Ion selective electrode: + specify species; e.g. Ca2+ + :Magnetic field: + Hall + :Surface pressure: + wilhelmy plate + run_control(NX_BOOLEAN): + doc: | + Is data collection controlled or synchronised to this quantity: + 1=no, 0=to "value", 1=to "value_deriv1", etc. + high_trip_value(NX_FLOAT): + unit: NX_ANY + doc: | + Upper control bound of sensor reading if using run_control + low_trip_value(NX_FLOAT): + unit: NX_ANY + doc: | + Lower control bound of sensor reading if using run_control + value(NX_FLOAT): + unit: NX_ANY + doc: | + nominal setpoint or average value + - need [n] as may be a vector + dimensions: + dim: [[1, n]] + value_deriv1(NX_FLOAT): + unit: NX_ANY + doc: | + Nominal/average first derivative of value + e.g. strain rate + - same dimensions as "value" (may be a vector) + dimensions: + dim: [[1, ]] + dim_parameters: + ref: ['value'] + value_deriv2(NX_FLOAT): + unit: NX_ANY + doc: | + Nominal/average second derivative of value + - same dimensions as "value" (may be a vector) + dimensions: + dim: [[1, ]] + dim_parameters: + ref: ['value'] + value_log(NXlog): + doc: | + Time history of sensor readings + value_deriv1_log(NXlog): + doc: | + Time history of first derivative of sensor readings + value_deriv2_log(NXlog): + doc: | + Time history of second derivative of sensor readings + external_field_brief: + enumeration: [along beam, across beam, transverse, solenoidal, flow shear gradient, flow vorticity] + external_field_full(NXorientation): + doc: | + For complex external fields not satisfied by External_field_brief + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the sensor when necessary. + (NXfabrication): + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a sensor. + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# df8bc397cbcbf114091b84ed357f6312641ca9abbf2d51795c37802450e7e628 +# +# +# +# +# +# A sensor used to monitor an external condition +# +# The condition itself is described in :ref:`NXenvironment`. +# +# +# Sensor identification code/model number +# +# +# Name for the sensor +# +# +# Short name of sensor used e.g. on monitor display program +# +# +# where sensor is attached to ("sample" | "can") +# +# +# +# Defines the axes for logged vector quantities if they are not the global instrument axes. +# +# +# +# name for measured signal +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The type of hardware used for the measurement. +# Examples (suggestions but not restrictions): +# +# :Temperature: +# J | K | T | E | R | S | Pt100 | Rh/Fe +# :pH: +# Hg/Hg2Cl2 | Ag/AgCl | ISFET +# :Ion selective electrode: +# specify species; e.g. Ca2+ +# :Magnetic field: +# Hall +# :Surface pressure: +# wilhelmy plate +# +# +# +# +# Is data collection controlled or synchronised to this quantity: +# 1=no, 0=to "value", 1=to "value_deriv1", etc. +# +# +# +# +# Upper control bound of sensor reading if using run_control +# +# +# +# +# Lower control bound of sensor reading if using run_control +# +# +# +# +# nominal setpoint or average value +# - need [n] as may be a vector +# +# +# +# +# +# +# +# Nominal/average first derivative of value +# e.g. strain rate +# - same dimensions as "value" (may be a vector) +# +# +# +# +# +# +# +# Nominal/average second derivative of value +# - same dimensions as "value" (may be a vector) +# +# +# +# +# +# +# Time history of sensor readings +# +# +# Time history of first derivative of sensor readings +# +# +# Time history of second derivative of sensor readings +# +# +# +# +# +# +# +# +# +# +# +# +# For complex external fields not satisfied by External_field_brief +# +# +# +# This group describes the shape of the sensor when necessary. +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a sensor. +# +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXsource.yaml b/contributed_definitions/nyaml/NXsource.yaml new file mode 100644 index 0000000000..1692b666ea --- /dev/null +++ b/contributed_definitions/nyaml/NXsource.yaml @@ -0,0 +1,521 @@ +category: base +doc: | + The neutron or x-ray storage ring/facility. +type: group +NXsource(NXobject): + distance(NX_FLOAT): + unit: NX_LENGTH + doc: | + Effective distance from sample + Distance as seen by radiation from sample. This number should be negative + to signify that it is upstream of the sample. + name: + doc: | + Name of source + \@short_name: + doc: | + short name for source, perhaps the acronym + type: + doc: | + type of radiation source (pick one from the enumerated list and spell exactly) + enumeration: [Spallation Neutron Source, Pulsed Reactor Neutron Source, Reactor Neutron Source, Synchrotron X-ray Source, Pulsed Muon Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, Ion Source, UV Plasma Source, Metal Jet X-ray] + probe: + doc: | + type of radiation probe (pick one from the enumerated list and spell exactly) + enumeration: [neutron, x-ray, muon, electron, ultraviolet, visible light, positron, proton] + power(NX_FLOAT): + unit: NX_POWER + doc: | + Source power + emittance_x(NX_FLOAT): + unit: NX_EMITTANCE + doc: | + Source emittance (nm-rad) in X (horizontal) direction. + emittance_y(NX_FLOAT): + unit: NX_EMITTANCE + doc: | + Source emittance (nm-rad) in Y (horizontal) direction. + sigma_x(NX_FLOAT): + unit: NX_LENGTH + doc: | + particle beam size in x + sigma_y(NX_FLOAT): + unit: NX_LENGTH + doc: | + particle beam size in y + flux(NX_FLOAT): + unit: NX_FLUX + doc: | + Source intensity/area (example: s-1 cm-2) + energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + Source energy. + For storage rings, this would be the particle beam energy. + For X-ray tubes, this would be the excitation voltage. + current(NX_FLOAT): + unit: NX_CURRENT + doc: | + Accelerator, X-ray tube, or storage ring current + voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Accelerator voltage + frequency(NX_FLOAT): + unit: NX_FREQUENCY + doc: | + Frequency of pulsed source + period(NX_FLOAT): + unit: NX_PERIOD + doc: | + Period of pulsed source + target_material: + doc: | + Pulsed source target material + enumeration: [Ta, W, depleted_U, enriched_U, Hg, Pb, C] + notes(NXnote): + doc: | + any source/facility related messages/events that + occurred during the experiment + bunch_pattern(NXdata): + doc: | + For storage rings, description of the bunch pattern. + This is useful to describe irregular bunch patterns. + title: + doc: | + name of the bunch pattern + number_of_bunches(NX_INT): + doc: | + For storage rings, the number of bunches in use. + bunch_length(NX_FLOAT): + unit: NX_TIME + doc: | + For storage rings, temporal length of the bunch + bunch_distance(NX_FLOAT): + unit: NX_TIME + doc: | + For storage rings, time between bunches + pulse_width(NX_FLOAT): + unit: NX_TIME + doc: | + temporal width of source pulse + + # pulsed sources or storage rings could use this + pulse_shape(NXdata): + doc: | + source pulse shape + + # pulsed sources or storage rings could use this + mode: + doc: | + source operating mode + enumeration: + Single Bunch: + doc: | + for storage rings + Multi Bunch: + doc: | + for storage rings + + # other sources could add to this + + # other sources could add to this + top_up(NX_BOOLEAN): + doc: | + Is the synchrotron operating in top_up mode? + last_fill(NX_NUMBER): + unit: NX_CURRENT + doc: | + For storage rings, the current at the end of the most recent injection. + \@time: + type: NX_DATE_TIME + doc: | + date and time of the most recent injection. + photon_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + The center photon energy of the source, before it is + monochromatized or converted + center_wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + The center wavelength of the source, before it is + monochromatized or converted + pulse_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + For pulsed sources, the energy of a single pulse + peak_power(NX_FLOAT): + unit: NX_POWER + doc: | + For pulsed sources, the pulse energy divided + by the pulse duration + bunch_number_start(NX_INT): + doc: | + Some facilities tag each bunch. + First bunch of the measurement + bunch_number_end(NX_INT): + doc: | + Last bunch of the measurement + geometry(NXgeometry): + deprecated: | + Use the field `depends_on` and :ref:`NXtransformations` to position the source and NXoff_geometry to describe its shape instead + doc: | + "Engineering" location of source. + (NXfabrication): + (NXoff_geometry): + exists: ['min', '0'] + doc: | + This group describes the shape of the beam line component + distribution(NXdata): + doc: | + The wavelength or energy distribution of the source + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + depends_on(NX_CHAR): + doc: | + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the + z axis. + + .. image:: source/source.png + :width: 40% + (NXtransformations): + doc: | + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 19f1ee4e446868766ab035145a5835ce38e26b04d8e8ee50bf641392cb5c3525 +# +# +# +# +# +# The neutron or x-ray storage ring/facility. +# +# +# +# Effective distance from sample +# Distance as seen by radiation from sample. This number should be negative +# to signify that it is upstream of the sample. +# +# +# +# +# Name of source +# +# +# +# short name for source, perhaps the acronym +# +# +# +# +# +# type of radiation source (pick one from the enumerated list and spell exactly) +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# type of radiation probe (pick one from the enumerated list and spell exactly) +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Source power +# +# +# +# +# Source emittance (nm-rad) in X (horizontal) direction. +# +# +# +# +# Source emittance (nm-rad) in Y (horizontal) direction. +# +# +# +# +# particle beam size in x +# +# +# +# +# particle beam size in y +# +# +# +# +# Source intensity/area (example: s-1 cm-2) +# +# +# +# +# Source energy. +# For storage rings, this would be the particle beam energy. +# For X-ray tubes, this would be the excitation voltage. +# +# +# +# +# Accelerator, X-ray tube, or storage ring current +# +# +# +# +# Accelerator voltage +# +# +# +# +# Frequency of pulsed source +# +# +# +# +# Period of pulsed source +# +# +# +# +# Pulsed source target material +# +# +# +# +# +# +# +# +# +# +# +# +# +# any source/facility related messages/events that +# occurred during the experiment +# +# +# +# +# For storage rings, description of the bunch pattern. +# This is useful to describe irregular bunch patterns. +# +# +# +# name of the bunch pattern +# +# +# +# +# +# For storage rings, the number of bunches in use. +# +# +# +# +# For storage rings, temporal length of the bunch +# +# +# +# +# For storage rings, time between bunches +# +# +# +# +# temporal width of source pulse +# +# +# +# +# +# source pulse shape +# +# +# +# +# +# source operating mode +# +# +# +# +# for storage rings +# +# +# +# +# for storage rings +# +# +# +# +# +# +# +# +# Is the synchrotron operating in top_up mode? +# +# +# +# +# For storage rings, the current at the end of the most recent injection. +# +# +# +# date and time of the most recent injection. +# +# +# +# +# +# The center photon energy of the source, before it is +# monochromatized or converted +# +# +# +# +# The center wavelength of the source, before it is +# monochromatized or converted +# +# +# +# +# For pulsed sources, the energy of a single pulse +# +# +# +# +# For pulsed sources, the pulse energy divided +# by the pulse duration +# +# +# +# +# Some facilities tag each bunch. +# First bunch of the measurement +# +# +# +# +# Last bunch of the measurement +# +# +# +# +# "Engineering" location of source. +# +# +# +# +# This group describes the shape of the beam line component +# +# +# +# +# The wavelength or energy distribution of the source +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the +# z axis. +# +# .. image:: source/source.png +# :width: 40% +# +# +# +# +# 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. +# +# +# From 5169ca519db458aef5653325a7afe4df9434974e Mon Sep 17 00:00:00 2001 From: domna Date: Thu, 28 Sep 2023 08:04:18 +0200 Subject: [PATCH 0313/1012] Adds response_function to NXresolution --- contributed_definitions/NXresolution.nxdl.xml | 26 +++++++++++++++---- .../nyaml/NXresolution.yaml | 23 ++++++++++++---- 2 files changed, 39 insertions(+), 10 deletions(-) diff --git a/contributed_definitions/NXresolution.nxdl.xml b/contributed_definitions/NXresolution.nxdl.xml index 458dc57600..0c965bb29e 100644 --- a/contributed_definitions/NXresolution.nxdl.xml +++ b/contributed_definitions/NXresolution.nxdl.xml @@ -47,14 +47,30 @@ Additional details of the estimate or description of the calibration procedure - + - The data describing the resolution in dependency of the experimental axes. + The resolution of the physical quantity. - + + + + The response of the instrument or part to a infinitesimal short input signal + along the physical quantity of this group. + This is also sometimes called instrument response function for time resolution or + point spread function for spatial response. + The resolution is typically determined by taking the FWHM of the response function. + + + + The input axis or grid of the response function. + The unit should match the one of the resolution field. + + + - The magnitude of the resolution at the given point(s) or single value - for a constant resolution throughout the experimental phase-space. + The magnitude of the response function corresponding to the points + in the input axis or grid. + This field should have the same dimensions as `input`. diff --git a/contributed_definitions/nyaml/NXresolution.yaml b/contributed_definitions/nyaml/NXresolution.yaml index ee3fd779ac..9ed5dbf671 100644 --- a/contributed_definitions/nyaml/NXresolution.yaml +++ b/contributed_definitions/nyaml/NXresolution.yaml @@ -15,14 +15,27 @@ NXresolution: note(NXnote): doc: | Additional details of the estimate or description of the calibration procedure - resolution(NXdata): + resolution(NX_FLOAT): doc: | - The data describing the resolution in dependency of the experimental axes. - magnitude(NX_FLOAT): + The resolution of the physical quantity. + unit: NX_ANY + response_function(NXdata): + doc: | + The response of the instrument or part to a infinitesimal short input signal + along the physical quantity of this group. + This is also sometimes called instrument response function for time resolution or + point spread function for spatial response. + The resolution is typically determined by taking the FWHM of the response function. + input(NX_FLOAT): doc: | - The magnitude of the resolution at the given point(s) or single value - for a constant resolution throughout the experimental phase-space. + The input axis or grid of the response function. + The unit should match the one of the resolution field. unit: NX_ANY + magnitude(NX_FLOAT): + doc: | + The magnitude of the response function corresponding to the points + in the input axis or grid. + This field should have the same dimensions as `input`. formula_symbol_LINK(NXlink): doc: | A symbol linking to another path in this appdef From 0f013af739c526d312a8d46c6a6b4f112effd70e Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 2 Oct 2023 18:58:03 +0200 Subject: [PATCH 0314/1012] Updates distance field according to @Tommaso-Pincelli s comments --- contributed_definitions/NXmpes.nxdl.xml | 4 +++- contributed_definitions/nyaml/NXmpes.yaml | 4 +++- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 1a91ce16c3..09f63d7559 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -162,7 +162,9 @@ This would also be helpful for NXtransformations--> - Distance of the point of evaluation of the beam from the sample surface. + Distance between the point where this NXbeam instance is evaluating the beam properties + and the intersection point of the beam and the sample. + For photoemission, this intersection point is where the centre of the beam touches the sample surface. diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index eef22b8046..5f92c70199 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -115,7 +115,9 @@ NXmpes(NXobject): unit: NX_LENGTH exists: recommended doc: | - Distance of the point of evaluation of the beam from the sample surface. + Distance between the point where this NXbeam instance is evaluating the beam properties + and the intersection point of the beam and the sample. + For photoemission, this intersection point is where the centre of the beam touches the sample surface. incident_energy(NX_FLOAT): unit: NX_ENERGY incident_energy_spread(NX_NUMBER): From c16d6a27f0686a7bf6c59230405b557dd38f1dcf Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 5 Oct 2023 15:35:42 +0200 Subject: [PATCH 0315/1012] Add base class for electronic core levels --- .../NXelectron_level.nxdl.xml | 913 ++++++++++++++++++ contributed_definitions/NXmpes.nxdl.xml | 21 +- .../nyaml/NXelectron_level.yaml | 495 ++++++++++ contributed_definitions/nyaml/NXmpes.yaml | 17 +- 4 files changed, 1431 insertions(+), 15 deletions(-) create mode 100644 contributed_definitions/NXelectron_level.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXelectron_level.yaml diff --git a/contributed_definitions/NXelectron_level.nxdl.xml b/contributed_definitions/NXelectron_level.nxdl.xml new file mode 100644 index 0000000000..1550d9e094 --- /dev/null +++ b/contributed_definitions/NXelectron_level.nxdl.xml @@ -0,0 +1,913 @@ + + + + + + Electronic level probed in X-ray spectroscopy or resonance experiments. + + + + Symbol of the absorbing or resonant element. + + For each, the atomic number, common English name, and standard atomic weight are also given. + + + + + Z=1, name="hydrogen", standard_atomic_weight=1.0078 + + + + + Z=2, name="helium", standard_atomic_weight=4.0026 + + + + + Z=3, name="lithium", standard_atomic_weight=6.94 + + + + + Z=4, name="beryllium", standard_atomic_weight=9.0122 + + + + + Z=5, name="boron", standard_atomic_weight=10.81 + + + + + Z=6, name="carbon", standard_atomic_weight=12.011 + + + + + Z=7, name="nitrogen", standard_atomic_weight=14.007 + + + + + Z=8, name="oxygen", standard_atomic_weight=15.999 + + + + + Z=9, name="fluorine", standard_atomic_weight=18.9984 + + + + + Z=10, name="neon", standard_atomic_weight=20.1797 + + + + + Z=11, name="sodium", standard_atomic_weight=22.9898 + + + + + Z=12, name="magnesium", standard_atomic_weight=24.305 + + + + + Z=13, name="aluminum", standard_atomic_weight=26.9815 + + + + + Z=14, name="silicon", standard_atomic_weight=28.085 + + + + + Z=15, name="phosphorus", standard_atomic_weight=30.9738 + + + + + Z=16, name="sulfur", standard_atomic_weight=32.06 + + + + + Z=17, name="chlorine", standard_atomic_weight=35.453 + + + + + Z=18, name="argon", standard_atomic_weight=39.948 + + + + + Z=19, name="potassium", standard_atomic_weight=39.0983 + + + + + Z=20, name="calcium", standard_atomic_weight=40.078 + + + + + Z=21, name="scandium", standard_atomic_weight=44.9559 + + + + + Z=22, name="titanium", standard_atomic_weight=47.867 + + + + + Z=23, name="vanadium", standard_atomic_weight=50.9415 + + + + + Z=24, name="chromium", standard_atomic_weight=51.996 + + + + + Z=25, name="manganese", standard_atomic_weight=54.938 + + + + + Z=26, name="iron", standard_atomic_weight=55.845 + + + + + Z=27, name="cobalt", standard_atomic_weight=58.9332 + + + + + Z=28, name="nickel", standard_atomic_weight=58.6934 + + + + + Z=29, name="copper", standard_atomic_weight=63.546 + + + + + Z=30, name="zinc", standard_atomic_weight=65.38 + + + + + Z=31, name="gallium", standard_atomic_weight=69.72 + + + + + Z=32, name="germanium", standard_atomic_weight=72.63 + + + + + Z=33, name="arsenic", standard_atomic_weight=74.9216 + + + + + Z=34, name="selenium", standard_atomic_weight=78.971 + + + + + Z=35, name="bromine", standard_atomic_weight=79.904 + + + + + Z=36, name="krypton", standard_atomic_weight=83.798 + + + + + Z=37, name="rubidium", standard_atomic_weight=85.4678 + + + + + Z=38, name="strontium", standard_atomic_weight=87.62 + + + + + Z=39, name="yttrium", standard_atomic_weight=88.9058 + + + + + Z=40, name="zirconium", standard_atomic_weight=91.224 + + + + + Z=41, name="niobium", standard_atomic_weight=92.9064 + + + + + Z=42, name="molybdenum", standard_atomic_weight=95.95 + + + + + Z=43, name="technetium", standard_atomic_weight=97.907 + + + + + Z=44, name="ruthenium", standard_atomic_weight=101.07 + + + + + Z=45, name="rhodium", standard_atomic_weight=102.906 + + + + + Z=46, name="palladium", standard_atomic_weight=106.42 + + + + + Z=47, name="silver", standard_atomic_weight=107.868 + + + + + Z=48, name="cadmium", standard_atomic_weight=112.414 + + + + + Z=49, name="indium", standard_atomic_weight=114.818 + + + + + Z=50, name="tin", standard_atomic_weight=118.71 + + + + + Z=51, name="antimony", standard_atomic_weight=121.76 + + + + + Z=52, name="tellurium", standard_atomic_weight=127.6 + + + + + Z=53, name="iodine", standard_atomic_weight=126.905 + + + + + Z=54, name="xenon", standard_atomic_weight=131.293 + + + + + Z=55, name="cesium", standard_atomic_weight=132.905 + + + + + Z=56, name="barium", standard_atomic_weight=137.327 + + + + + Z=57, name="lanthanum", standard_atomic_weight=138.905 + + + + + Z=58, name="cerium", standard_atomic_weight=140.116 + + + + + Z=59, name="praseodymium", standard_atomic_weight=140.908 + + + + + Z=60, name="neodymium", standard_atomic_weight=144.242 + + + + + Z=61, name="promethium", standard_atomic_weight=145.0 + + + + + Z=62, name="samarium", standard_atomic_weight=150.36 + + + + + Z=63, name="europium", standard_atomic_weight=151.96 + + + + + Z=64, name="gadolinium", standard_atomic_weight=157.25 + + + + + Z=65, name="terbium", standard_atomic_weight=158.925 + + + + + Z=66, name="dysprosium", standard_atomic_weight=162.5 + + + + + Z=67, name="holmium", standard_atomic_weight=164.93 + + + + + Z=68, name="erbium", standard_atomic_weight=167.259 + + + + + Z=69, name="thulium", standard_atomic_weight=168.934 + + + + + Z=70, name="ytterbium", standard_atomic_weight=173.045 + + + + + Z=71, name="lutetium", standard_atomic_weight=174.967 + + + + + Z=72, name="hafnium", standard_atomic_weight=178.49 + + + + + Z=73, name="tantalum", standard_atomic_weight=180.948 + + + + + Z=74, name="tungsten", standard_atomic_weight=183.84 + + + + + Z=75, name="rhenium", standard_atomic_weight=186.207 + + + + + Z=76, name="osmium", standard_atomic_weight=190.23 + + + + + Z=77, name="iridium", standard_atomic_weight=192.217 + + + + + Z=78, name="platinum", standard_atomic_weight=195.084 + + + + + Z=79, name="gold", standard_atomic_weight=196.967 + + + + + Z=80, name="mercury", standard_atomic_weight=200.592 + + + + + Z=81, name="thallium", standard_atomic_weight=204.383 + + + + + Z=82, name="lead", standard_atomic_weight=207.2 + + + + + Z=83, name="bismuth", standard_atomic_weight=208.98 + + + + + Z=84, name="polonium", standard_atomic_weight=209.0 + + + + + Z=85, name="astatine", standard_atomic_weight=210.0 + + + + + Z=86, name="radon", standard_atomic_weight=222.0 + + + + + Z=87, name="francium", standard_atomic_weight=223.0 + + + + + Z=88, name="radium", standard_atomic_weight=226.0 + + + + + Z=89, name="actinium", standard_atomic_weight=227.0 + + + + + Z=90, name="thorium", standard_atomic_weight=232.038 + + + + + Z=91, name="protactinium", standard_atomic_weight=231.036 + + + + + Z=92, name="uranium", standard_atomic_weight=238.029 + + + + + Z=93, name="neptunium", standard_atomic_weight=237.048 + + + + + Z=94, name="plutonium", standard_atomic_weight=239.052 + + + + + Z=95, name="americium", standard_atomic_weight=243.0 + + + + + Z=96, name="curium", standard_atomic_weight=247.0 + + + + + Z=97, name="berkelium", standard_atomic_weight=247.0 + + + + + Z=98, name="californium", standard_atomic_weight=251.0 + + + + + Z=99, name="einsteinium", standard_atomic_weight=252 + + + + + Z=100, name="fermium", standard_atomic_weight=257 + + + + + Z=101, name="mendelevium", standard_atomic_weight=258 + + + + + Z=103, name="lawrencium", standard_atomic_weight=266 + + + + + Z=104, name="rutherfordium", standard_atomic_weight=267 + + + + + Z=105, name="dubnium", standard_atomic_weight=268 + + + + + Z=106, name="seaborgium", standard_atomic_weight=269 + + + + + Z=107, name="bohrium", standard_atomic_weight=270 + + + + + Z=108, name="hassium", standard_atomic_weight=269 + + + + + Z=109, name="meitnerium", standard_atomic_weight=278 + + + + + Z=110, name="darmstadtium", standard_atomic_weight=281 + + + + + Z=111, name="roentgenium", standard_atomic_weight=282 + + + + + Z=112, name="copernicium", standard_atomic_weight=285 + + + + + Z=113, name="nihonium", standard_atomic_weight=286 + + + + + Z=114, name="flerovium", standard_atomic_weight=289 + + + + + Z=115, name="moscovium", standard_atomic_weight=290 + + + + + Z=116, name="livermorium", standard_atomic_weight=293 + + + + + Z=117, name="tennessine", standard_atomic_weight=294 + + + + + Z=118, name="oganesson", standard_atomic_weight=294 + + + + + + + IUPAC symbol of the electronic level. + For each level, the electronic orbital configuration is also given + + For reference, see Jenkins, R., Manne, R., Robin, R., & Senemaud, C. (1991). + IUPAC—nomenclature system for x-ray spectroscopy. X-Ray Spectrometry, 20(3), 149-155. + + + + + same as 1s in level_xray + + + + + 2s + + + + + 2p_{1/2} + + + + + 2p_{3/2} + + + + + 3s + + + + + 3p_{1/2} + + + + + 3p_{3/2} + + + + + 3d_{3/2} + + + + + 3d_{5/2} + + + + + 4s + + + + + 4p_{1/2} + + + + + 4p_{3/2} + + + + + 4d_{3/2} + + + + + 4d_{5/2} + + + + + 4f_{5/2} + + + + + 4f_{7/2} + + + + + 5s + + + + + 5p_{1/2} + + + + + 5p_{3/2} + + + + + 5d_{3/2} + + + + + 5d_{5/2} + + + + + 5f_{5/2} + + + + + 5f_{7/2} + + + + + 6s + + + + + 6p_{1/2} + + + + + 6p_{3/2} + + + + + + + Electronic orbital configuration of the electronic level. + + + + + same as K in level_xray + + + + + L1 + + + + + L3 + + + + + M1 + + + + + M2 + + + + + M3 + + + + + M4 + + + + + M5 + + + + + N1 + + + + + N2 + + + + + N3 + + + + + N4 + + + + + N5 + + + + + N6 + + + + + N7 + + + + + O1 + + + + + O2 + + + + + O3 + + + + + O4 + + + + + O5 + + + + + O6 + + + + + O7 + + + + + P1 + + + + + P2 + + + + + P3 + + + + + + + description of X-ray electronic level + + + + + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + + + diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 97568b7b99..9ce0e03639 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -470,17 +470,16 @@ Optional constant settings (like lens focusing parameters on the sample: positio conductive)? - + - Emission line which was used for the calibration. - - For example: C1s C-C | Ag 3d5/2 metal | Si 2p3/2 elemental | Fermi edge + Electronic core or valence level that was used for the calibration. - - + + - Offset between measured binding energy and calibrated binding energy of the - emission line. + Reference peak that was used for the calibration. + + For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge @@ -493,6 +492,12 @@ Optional constant settings (like lens focusing parameters on the sample: positio .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + + + Offset between measured binding energy and calibrated binding energy of the + emission line. + + This is the calibrated energy axis to be used for data plotting. diff --git a/contributed_definitions/nyaml/NXelectron_level.yaml b/contributed_definitions/nyaml/NXelectron_level.yaml new file mode 100644 index 0000000000..b7cd04dc7f --- /dev/null +++ b/contributed_definitions/nyaml/NXelectron_level.yaml @@ -0,0 +1,495 @@ +category: base +doc: | + Electronic level probed in X-ray spectroscopy or resonance experiments. +type: group +NXelectron_level: + element: + doc: | + Symbol of the absorbing or resonant element. + + For each, the atomic number, common English name, and standard atomic weight are also given. + enumeration: + H: + doc: | + Z=1, name="hydrogen", standard_atomic_weight=1.0078 + He: + doc: | + Z=2, name="helium", standard_atomic_weight=4.0026 + Li: + doc: | + Z=3, name="lithium", standard_atomic_weight=6.94 + Be: + doc: | + Z=4, name="beryllium", standard_atomic_weight=9.0122 + B: + doc: | + Z=5, name="boron", standard_atomic_weight=10.81 + C: + doc: | + Z=6, name="carbon", standard_atomic_weight=12.011 + N: + doc: | + Z=7, name="nitrogen", standard_atomic_weight=14.007 + O: + doc: | + Z=8, name="oxygen", standard_atomic_weight=15.999 + F: + doc: | + Z=9, name="fluorine", standard_atomic_weight=18.9984 + Ne: + doc: | + Z=10, name="neon", standard_atomic_weight=20.1797 + Na: + doc: | + Z=11, name="sodium", standard_atomic_weight=22.9898 + Mg: + doc: | + Z=12, name="magnesium", standard_atomic_weight=24.305 + Al: + doc: | + Z=13, name="aluminum", standard_atomic_weight=26.9815 + Si: + doc: | + Z=14, name="silicon", standard_atomic_weight=28.085 + P: + doc: | + Z=15, name="phosphorus", standard_atomic_weight=30.9738 + S: + doc: | + Z=16, name="sulfur", standard_atomic_weight=32.06 + Cl: + doc: | + Z=17, name="chlorine", standard_atomic_weight=35.453 + Ar: + doc: | + Z=18, name="argon", standard_atomic_weight=39.948 + K: + doc: | + Z=19, name="potassium", standard_atomic_weight=39.0983 + Ca: + doc: | + Z=20, name="calcium", standard_atomic_weight=40.078 + Sc: + doc: | + Z=21, name="scandium", standard_atomic_weight=44.9559 + Ti: + doc: | + Z=22, name="titanium", standard_atomic_weight=47.867 + V: + doc: | + Z=23, name="vanadium", standard_atomic_weight=50.9415 + Cr: + doc: | + Z=24, name="chromium", standard_atomic_weight=51.996 + Mn: + doc: | + Z=25, name="manganese", standard_atomic_weight=54.938 + Fe: + doc: | + Z=26, name="iron", standard_atomic_weight=55.845 + Co: + doc: | + Z=27, name="cobalt", standard_atomic_weight=58.9332 + Ni: + doc: | + Z=28, name="nickel", standard_atomic_weight=58.6934 + Cu: + doc: | + Z=29, name="copper", standard_atomic_weight=63.546 + Zn: + doc: | + Z=30, name="zinc", standard_atomic_weight=65.38 + Ga: + doc: | + Z=31, name="gallium", standard_atomic_weight=69.72 + Ge: + doc: | + Z=32, name="germanium", standard_atomic_weight=72.63 + As: + doc: | + Z=33, name="arsenic", standard_atomic_weight=74.9216 + Se: + doc: | + Z=34, name="selenium", standard_atomic_weight=78.971 + Br: + doc: | + Z=35, name="bromine", standard_atomic_weight=79.904 + Kr: + doc: | + Z=36, name="krypton", standard_atomic_weight=83.798 + Rb: + doc: | + Z=37, name="rubidium", standard_atomic_weight=85.4678 + Sr: + doc: | + Z=38, name="strontium", standard_atomic_weight=87.62 + Y: + doc: | + Z=39, name="yttrium", standard_atomic_weight=88.9058 + Zr: + doc: | + Z=40, name="zirconium", standard_atomic_weight=91.224 + Nb: + doc: | + Z=41, name="niobium", standard_atomic_weight=92.9064 + Mo: + doc: | + Z=42, name="molybdenum", standard_atomic_weight=95.95 + Tc: + doc: | + Z=43, name="technetium", standard_atomic_weight=97.907 + Ru: + doc: | + Z=44, name="ruthenium", standard_atomic_weight=101.07 + Rh: + doc: | + Z=45, name="rhodium", standard_atomic_weight=102.906 + Pd: + doc: | + Z=46, name="palladium", standard_atomic_weight=106.42 + Ag: + doc: | + Z=47, name="silver", standard_atomic_weight=107.868 + Cd: + doc: | + Z=48, name="cadmium", standard_atomic_weight=112.414 + In: + doc: | + Z=49, name="indium", standard_atomic_weight=114.818 + Sn: + doc: | + Z=50, name="tin", standard_atomic_weight=118.71 + Sb: + doc: | + Z=51, name="antimony", standard_atomic_weight=121.76 + Te: + doc: | + Z=52, name="tellurium", standard_atomic_weight=127.6 + I: + doc: | + Z=53, name="iodine", standard_atomic_weight=126.905 + Xe: + doc: | + Z=54, name="xenon", standard_atomic_weight=131.293 + Cs: + doc: | + Z=55, name="cesium", standard_atomic_weight=132.905 + Ba: + doc: | + Z=56, name="barium", standard_atomic_weight=137.327 + La: + doc: | + Z=57, name="lanthanum", standard_atomic_weight=138.905 + Ce: + doc: | + Z=58, name="cerium", standard_atomic_weight=140.116 + Pr: + doc: | + Z=59, name="praseodymium", standard_atomic_weight=140.908 + Nd: + doc: | + Z=60, name="neodymium", standard_atomic_weight=144.242 + Pm: + doc: | + Z=61, name="promethium", standard_atomic_weight=145.0 + Sm: + doc: | + Z=62, name="samarium", standard_atomic_weight=150.36 + Eu: + doc: | + Z=63, name="europium", standard_atomic_weight=151.96 + Gd: + doc: | + Z=64, name="gadolinium", standard_atomic_weight=157.25 + Tb: + doc: | + Z=65, name="terbium", standard_atomic_weight=158.925 + Dy: + doc: | + Z=66, name="dysprosium", standard_atomic_weight=162.5 + Ho: + doc: | + Z=67, name="holmium", standard_atomic_weight=164.93 + Er: + doc: | + Z=68, name="erbium", standard_atomic_weight=167.259 + Tm: + doc: | + Z=69, name="thulium", standard_atomic_weight=168.934 + Yb: + doc: | + Z=70, name="ytterbium", standard_atomic_weight=173.045 + Lu: + doc: | + Z=71, name="lutetium", standard_atomic_weight=174.967 + Hf: + doc: | + Z=72, name="hafnium", standard_atomic_weight=178.49 + Ta: + doc: | + Z=73, name="tantalum", standard_atomic_weight=180.948 + W: + doc: | + Z=74, name="tungsten", standard_atomic_weight=183.84 + Re: + doc: | + Z=75, name="rhenium", standard_atomic_weight=186.207 + Os: + doc: | + Z=76, name="osmium", standard_atomic_weight=190.23 + Ir: + doc: | + Z=77, name="iridium", standard_atomic_weight=192.217 + Pt: + doc: | + Z=78, name="platinum", standard_atomic_weight=195.084 + Au: + doc: | + Z=79, name="gold", standard_atomic_weight=196.967 + Hg: + doc: | + Z=80, name="mercury", standard_atomic_weight=200.592 + Tl: + doc: | + Z=81, name="thallium", standard_atomic_weight=204.383 + Pb: + doc: | + Z=82, name="lead", standard_atomic_weight=207.2 + Bi: + doc: | + Z=83, name="bismuth", standard_atomic_weight=208.98 + Po: + doc: | + Z=84, name="polonium", standard_atomic_weight=209.0 + At: + doc: | + Z=85, name="astatine", standard_atomic_weight=210.0 + Rn: + doc: | + Z=86, name="radon", standard_atomic_weight=222.0 + Fr: + doc: | + Z=87, name="francium", standard_atomic_weight=223.0 + Ra: + doc: | + Z=88, name="radium", standard_atomic_weight=226.0 + Ac: + doc: | + Z=89, name="actinium", standard_atomic_weight=227.0 + Th: + doc: | + Z=90, name="thorium", standard_atomic_weight=232.038 + Pa: + doc: | + Z=91, name="protactinium", standard_atomic_weight=231.036 + U: + doc: | + Z=92, name="uranium", standard_atomic_weight=238.029 + Np: + doc: | + Z=93, name="neptunium", standard_atomic_weight=237.048 + Pu: + doc: | + Z=94, name="plutonium", standard_atomic_weight=239.052 + Am: + doc: | + Z=95, name="americium", standard_atomic_weight=243.0 + Cm: + doc: | + Z=96, name="curium", standard_atomic_weight=247.0 + Bk: + doc: | + Z=97, name="berkelium", standard_atomic_weight=247.0 + Cf: + doc: | + Z=98, name="californium", standard_atomic_weight=251.0 + Es: + doc: | + Z=99, name="einsteinium", standard_atomic_weight=252 + Fm: + doc: | + Z=100, name="fermium", standard_atomic_weight=257 + Md: + doc: | + Z=101, name="mendelevium", standard_atomic_weight=258 + # No: + # doc: | + # Z=102, name="nobelium", standard_atomic_weight=259 + Lr: + doc: | + Z=103, name="lawrencium", standard_atomic_weight=266 + Rf: + doc: | + Z=104, name="rutherfordium", standard_atomic_weight=267 + Db: + doc: | + Z=105, name="dubnium", standard_atomic_weight=268 + Sg: + doc: | + Z=106, name="seaborgium", standard_atomic_weight=269 + Bh: + doc: | + Z=107, name="bohrium", standard_atomic_weight=270 + Hs: + doc: | + Z=108, name="hassium", standard_atomic_weight=269 + Mt: + doc: | + Z=109, name="meitnerium", standard_atomic_weight=278 + Ds: + doc: | + Z=110, name="darmstadtium", standard_atomic_weight=281 + Rg: + doc: | + Z=111, name="roentgenium", standard_atomic_weight=282 + Cn: + doc: | + Z=112, name="copernicium", standard_atomic_weight=285 + Nh: + doc: | + Z=113, name="nihonium", standard_atomic_weight=286 + Fl: + doc: | + Z=114, name="flerovium", standard_atomic_weight=289 + Mc: + doc: | + Z=115, name="moscovium", standard_atomic_weight=290 + Lv: + doc: | + Z=116, name="livermorium", standard_atomic_weight=293 + Ts: + doc: | + Z=117, name="tennessine", standard_atomic_weight=294 + Og: + doc: | + Z=118, name="oganesson", standard_atomic_weight=294 + level_iupac: + doc: | + IUPAC symbol of the electronic level. + For each level, the electronic orbital configuration is also given + + For reference, see Jenkins, R., Manne, R., Robin, R., & Senemaud, C. (1991). + IUPAC—nomenclature system for x-ray spectroscopy. X-Ray Spectrometry, 20(3), 149-155. + enumeration: + K: + doc: same as 1s in level_xray + L1: + doc: 2s + L2: + doc: 2p_{1/2} + L3: + doc: 2p_{3/2} + M1: + doc: 3s + M2: + doc: 3p_{1/2} + M3: + doc: 3p_{3/2} + M4: + doc: 3d_{3/2} + M5: + doc: 3d_{5/2} + N1: + doc: 4s + N2: + doc: 4p_{1/2} + N3: + doc: 4p_{3/2} + N4: + doc: 4d_{3/2} + N5: + doc: 4d_{5/2} + N6: + doc: 4f_{5/2} + N7: + doc: 4f_{7/2} + O1: + doc: 5s + O2: + doc: 5p_{1/2} + O3: + doc: 5p_{3/2} + O4: + doc: 5d_{3/2} + O5: + doc: 5d_{5/2} + O6: + doc: 5f_{5/2} + O7: + doc: 5f_{7/2} + P1: + doc: 6s + P2: + doc: 6p_{1/2} + P3: + doc: 6p_{3/2} + level_electron_config: + doc: | + Electronic orbital configuration of the electronic level. + enumeration: + 1s: + doc: same as K in level_xray + 2s: + doc: L1 + 2p1/2: + doc: L2 + 2p1/2: + doc: L3 + 3s: + doc: M1 + 3p1/2: + doc: M2 + 3p3/2: + doc: M3 + 3d3/2: + doc: M4 + 3d5/2: + doc: M5 + 4s: + doc: N1 + 4p1/2: + doc: N2 + 4p3/2: + doc: N3 + 4d3/2: + doc: N4 + 4d5/2: + doc: N5 + 4f5/2: + doc: N6 + 4f7/2: + doc: N7 + 5s: + doc: O1 + 5p1/2: + doc: O2 + 5p3/2: + doc: O3 + 5d3/2: + doc: O4 + 5d5/2: + doc: O5 + 5f5/2: + doc: O6 + 5f7/2: + doc: O7 + 6s: + doc: P1 + 6p1/2: + doc: P2 + 6p3/2: + doc: P3 + \@description: + doc: | + description of X-ray electronic level + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index ada2b880e0..a4a64fbf66 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -377,16 +377,15 @@ NXmpes(NXobject): applied(NX_BOOLEAN): doc: | Have the energy axes been adjusted (e.g., in cases where samples are not conductive)? - emission_line: + level(NXelectron_level): exists: recommended doc: | - Emission line which was used for the calibration. - - For example: C1s C-C | Ag 3d5/2 metal | Si 2p3/2 elemental | Fermi edge - offset(NX_FLOAT): - exists: recommended + Electronic core or valence level that was used for the calibration. + reference_peak: doc: | - Offset between measured binding energy and calibrated binding energy of the emission line. + Reference peak that was used for the calibration. + + For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge binding_energy(NX_FLOAT): exists: recommended doc: | @@ -396,6 +395,10 @@ NXmpes(NXobject): Refers to Term `12.16`_ ff. of the ISO 18115-1:2023 specification. .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + offset(NX_FLOAT): + exists: recommended + doc: | + Offset between measured binding energy and calibrated binding energy of the emission line. calibrated_axis(NX_FLOAT): exists: recommended doc: | From 19bcd9d76379ef66706ddb1b81cc522310e0a02a Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 5 Oct 2023 16:25:23 +0200 Subject: [PATCH 0316/1012] Add single strings for 'No' option in enum --- .../NXelectron_level.nxdl.xml | 7 +- .../nyaml/NXelectron_level.yaml | 1100 ++++++++++++++++- 2 files changed, 1041 insertions(+), 66 deletions(-) diff --git a/contributed_definitions/NXelectron_level.nxdl.xml b/contributed_definitions/NXelectron_level.nxdl.xml index 1550d9e094..1bc63a6035 100644 --- a/contributed_definitions/NXelectron_level.nxdl.xml +++ b/contributed_definitions/NXelectron_level.nxdl.xml @@ -27,7 +27,7 @@ - Symbol of the absorbing or resonant element. + Symbol of the chemical element. For each, the atomic number, common English name, and standard atomic weight are also given. @@ -537,6 +537,11 @@ Z=101, name="mendelevium", standard_atomic_weight=258 + + + Z=102, name="nobelium", standard_atomic_weight=259 + + Z=103, name="lawrencium", standard_atomic_weight=266 diff --git a/contributed_definitions/nyaml/NXelectron_level.yaml b/contributed_definitions/nyaml/NXelectron_level.yaml index b7cd04dc7f..ef58f4c74c 100644 --- a/contributed_definitions/nyaml/NXelectron_level.yaml +++ b/contributed_definitions/nyaml/NXelectron_level.yaml @@ -2,11 +2,11 @@ category: base doc: | Electronic level probed in X-ray spectroscopy or resonance experiments. type: group -NXelectron_level: +NXelectron_level(NXobject): element: doc: | - Symbol of the absorbing or resonant element. - + Symbol of the chemical element. + For each, the atomic number, common English name, and standard atomic weight are also given. enumeration: H: @@ -312,9 +312,9 @@ NXelectron_level: Md: doc: | Z=101, name="mendelevium", standard_atomic_weight=258 - # No: - # doc: | - # Z=102, name="nobelium", standard_atomic_weight=259 + 'No': + doc: | + Z=102, name="nobelium", standard_atomic_weight=259 Lr: doc: | Z=103, name="lawrencium", standard_atomic_weight=266 @@ -367,118 +367,167 @@ NXelectron_level: doc: | IUPAC symbol of the electronic level. For each level, the electronic orbital configuration is also given - + For reference, see Jenkins, R., Manne, R., Robin, R., & Senemaud, C. (1991). IUPAC—nomenclature system for x-ray spectroscopy. X-Ray Spectrometry, 20(3), 149-155. - enumeration: + enumeration: K: - doc: same as 1s in level_xray - L1: - doc: 2s + doc: | + same as 1s in level_xray + L1: + doc: | + 2s L2: - doc: 2p_{1/2} + doc: | + 2p_{1/2} L3: - doc: 2p_{3/2} + doc: | + 2p_{3/2} M1: - doc: 3s + doc: | + 3s M2: - doc: 3p_{1/2} + doc: | + 3p_{1/2} M3: - doc: 3p_{3/2} + doc: | + 3p_{3/2} M4: - doc: 3d_{3/2} + doc: | + 3d_{3/2} M5: - doc: 3d_{5/2} + doc: | + 3d_{5/2} N1: - doc: 4s + doc: | + 4s N2: - doc: 4p_{1/2} + doc: | + 4p_{1/2} N3: - doc: 4p_{3/2} + doc: | + 4p_{3/2} N4: - doc: 4d_{3/2} + doc: | + 4d_{3/2} N5: - doc: 4d_{5/2} + doc: | + 4d_{5/2} N6: - doc: 4f_{5/2} + doc: | + 4f_{5/2} N7: - doc: 4f_{7/2} + doc: | + 4f_{7/2} O1: - doc: 5s + doc: | + 5s O2: - doc: 5p_{1/2} + doc: | + 5p_{1/2} O3: - doc: 5p_{3/2} + doc: | + 5p_{3/2} O4: - doc: 5d_{3/2} + doc: | + 5d_{3/2} O5: - doc: 5d_{5/2} + doc: | + 5d_{5/2} O6: - doc: 5f_{5/2} + doc: | + 5f_{5/2} O7: - doc: 5f_{7/2} + doc: | + 5f_{7/2} P1: - doc: 6s + doc: | + 6s P2: - doc: 6p_{1/2} + doc: | + 6p_{1/2} P3: - doc: 6p_{3/2} + doc: | + 6p_{3/2} level_electron_config: doc: | Electronic orbital configuration of the electronic level. - enumeration: + enumeration: 1s: - doc: same as K in level_xray - 2s: - doc: L1 - 2p1/2: - doc: L2 + doc: | + same as K in level_xray + 2s: + doc: | + L1 2p1/2: - doc: L3 + doc: | + L3 3s: - doc: M1 + doc: | + M1 3p1/2: - doc: M2 + doc: | + M2 3p3/2: - doc: M3 + doc: | + M3 3d3/2: - doc: M4 + doc: | + M4 3d5/2: - doc: M5 + doc: | + M5 4s: - doc: N1 + doc: | + N1 4p1/2: - doc: N2 + doc: | + N2 4p3/2: - doc: N3 + doc: | + N3 4d3/2: - doc: N4 + doc: | + N4 4d5/2: - doc: N5 + doc: | + N5 4f5/2: - doc: N6 + doc: | + N6 4f7/2: - doc: N7 + doc: | + N7 5s: - doc: O1 + doc: | + O1 5p1/2: - doc: O2 + doc: | + O2 5p3/2: - doc: O3 + doc: | + O3 5d3/2: - doc: O4 + doc: | + O4 5d5/2: - doc: O5 + doc: | + O5 5f5/2: - doc: O6 + doc: | + O6 5f7/2: - doc: O7 + doc: | + O7 6s: - doc: P1 + doc: | + P1 6p1/2: - doc: P2 + doc: | + P2 6p3/2: - doc: P3 + doc: | + P3 \@description: doc: | description of X-ray electronic level @@ -492,4 +541,925 @@ NXelectron_level: It is recommended (as of NIAC2014) to use this attribute to help define the path to the default dataset to be plotted. See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. \ No newline at end of file + for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 8919676091ceb7a94610690c2099e84bf653e60cc5bc669c9d1e562151e1f904 +# +# +# +# +# +# Electronic level probed in X-ray spectroscopy or resonance experiments. +# +# +# +# Symbol of the absorbing or resonant element. +# +# For each, the atomic number, common English name, and standard atomic weight are also given. +# +# +# +# +# Z=1, name="hydrogen", standard_atomic_weight=1.0078 +# +# +# +# +# Z=2, name="helium", standard_atomic_weight=4.0026 +# +# +# +# +# Z=3, name="lithium", standard_atomic_weight=6.94 +# +# +# +# +# Z=4, name="beryllium", standard_atomic_weight=9.0122 +# +# +# +# +# Z=5, name="boron", standard_atomic_weight=10.81 +# +# +# +# +# Z=6, name="carbon", standard_atomic_weight=12.011 +# +# +# +# +# Z=7, name="nitrogen", standard_atomic_weight=14.007 +# +# +# +# +# Z=8, name="oxygen", standard_atomic_weight=15.999 +# +# +# +# +# Z=9, name="fluorine", standard_atomic_weight=18.9984 +# +# +# +# +# Z=10, name="neon", standard_atomic_weight=20.1797 +# +# +# +# +# Z=11, name="sodium", standard_atomic_weight=22.9898 +# +# +# +# +# Z=12, name="magnesium", standard_atomic_weight=24.305 +# +# +# +# +# Z=13, name="aluminum", standard_atomic_weight=26.9815 +# +# +# +# +# Z=14, name="silicon", standard_atomic_weight=28.085 +# +# +# +# +# Z=15, name="phosphorus", standard_atomic_weight=30.9738 +# +# +# +# +# Z=16, name="sulfur", standard_atomic_weight=32.06 +# +# +# +# +# Z=17, name="chlorine", standard_atomic_weight=35.453 +# +# +# +# +# Z=18, name="argon", standard_atomic_weight=39.948 +# +# +# +# +# Z=19, name="potassium", standard_atomic_weight=39.0983 +# +# +# +# +# Z=20, name="calcium", standard_atomic_weight=40.078 +# +# +# +# +# Z=21, name="scandium", standard_atomic_weight=44.9559 +# +# +# +# +# Z=22, name="titanium", standard_atomic_weight=47.867 +# +# +# +# +# Z=23, name="vanadium", standard_atomic_weight=50.9415 +# +# +# +# +# Z=24, name="chromium", standard_atomic_weight=51.996 +# +# +# +# +# Z=25, name="manganese", standard_atomic_weight=54.938 +# +# +# +# +# Z=26, name="iron", standard_atomic_weight=55.845 +# +# +# +# +# Z=27, name="cobalt", standard_atomic_weight=58.9332 +# +# +# +# +# Z=28, name="nickel", standard_atomic_weight=58.6934 +# +# +# +# +# Z=29, name="copper", standard_atomic_weight=63.546 +# +# +# +# +# Z=30, name="zinc", standard_atomic_weight=65.38 +# +# +# +# +# Z=31, name="gallium", standard_atomic_weight=69.72 +# +# +# +# +# Z=32, name="germanium", standard_atomic_weight=72.63 +# +# +# +# +# Z=33, name="arsenic", standard_atomic_weight=74.9216 +# +# +# +# +# Z=34, name="selenium", standard_atomic_weight=78.971 +# +# +# +# +# Z=35, name="bromine", standard_atomic_weight=79.904 +# +# +# +# +# Z=36, name="krypton", standard_atomic_weight=83.798 +# +# +# +# +# Z=37, name="rubidium", standard_atomic_weight=85.4678 +# +# +# +# +# Z=38, name="strontium", standard_atomic_weight=87.62 +# +# +# +# +# Z=39, name="yttrium", standard_atomic_weight=88.9058 +# +# +# +# +# Z=40, name="zirconium", standard_atomic_weight=91.224 +# +# +# +# +# Z=41, name="niobium", standard_atomic_weight=92.9064 +# +# +# +# +# Z=42, name="molybdenum", standard_atomic_weight=95.95 +# +# +# +# +# Z=43, name="technetium", standard_atomic_weight=97.907 +# +# +# +# +# Z=44, name="ruthenium", standard_atomic_weight=101.07 +# +# +# +# +# Z=45, name="rhodium", standard_atomic_weight=102.906 +# +# +# +# +# Z=46, name="palladium", standard_atomic_weight=106.42 +# +# +# +# +# Z=47, name="silver", standard_atomic_weight=107.868 +# +# +# +# +# Z=48, name="cadmium", standard_atomic_weight=112.414 +# +# +# +# +# Z=49, name="indium", standard_atomic_weight=114.818 +# +# +# +# +# Z=50, name="tin", standard_atomic_weight=118.71 +# +# +# +# +# Z=51, name="antimony", standard_atomic_weight=121.76 +# +# +# +# +# Z=52, name="tellurium", standard_atomic_weight=127.6 +# +# +# +# +# Z=53, name="iodine", standard_atomic_weight=126.905 +# +# +# +# +# Z=54, name="xenon", standard_atomic_weight=131.293 +# +# +# +# +# Z=55, name="cesium", standard_atomic_weight=132.905 +# +# +# +# +# Z=56, name="barium", standard_atomic_weight=137.327 +# +# +# +# +# Z=57, name="lanthanum", standard_atomic_weight=138.905 +# +# +# +# +# Z=58, name="cerium", standard_atomic_weight=140.116 +# +# +# +# +# Z=59, name="praseodymium", standard_atomic_weight=140.908 +# +# +# +# +# Z=60, name="neodymium", standard_atomic_weight=144.242 +# +# +# +# +# Z=61, name="promethium", standard_atomic_weight=145.0 +# +# +# +# +# Z=62, name="samarium", standard_atomic_weight=150.36 +# +# +# +# +# Z=63, name="europium", standard_atomic_weight=151.96 +# +# +# +# +# Z=64, name="gadolinium", standard_atomic_weight=157.25 +# +# +# +# +# Z=65, name="terbium", standard_atomic_weight=158.925 +# +# +# +# +# Z=66, name="dysprosium", standard_atomic_weight=162.5 +# +# +# +# +# Z=67, name="holmium", standard_atomic_weight=164.93 +# +# +# +# +# Z=68, name="erbium", standard_atomic_weight=167.259 +# +# +# +# +# Z=69, name="thulium", standard_atomic_weight=168.934 +# +# +# +# +# Z=70, name="ytterbium", standard_atomic_weight=173.045 +# +# +# +# +# Z=71, name="lutetium", standard_atomic_weight=174.967 +# +# +# +# +# Z=72, name="hafnium", standard_atomic_weight=178.49 +# +# +# +# +# Z=73, name="tantalum", standard_atomic_weight=180.948 +# +# +# +# +# Z=74, name="tungsten", standard_atomic_weight=183.84 +# +# +# +# +# Z=75, name="rhenium", standard_atomic_weight=186.207 +# +# +# +# +# Z=76, name="osmium", standard_atomic_weight=190.23 +# +# +# +# +# Z=77, name="iridium", standard_atomic_weight=192.217 +# +# +# +# +# Z=78, name="platinum", standard_atomic_weight=195.084 +# +# +# +# +# Z=79, name="gold", standard_atomic_weight=196.967 +# +# +# +# +# Z=80, name="mercury", standard_atomic_weight=200.592 +# +# +# +# +# Z=81, name="thallium", standard_atomic_weight=204.383 +# +# +# +# +# Z=82, name="lead", standard_atomic_weight=207.2 +# +# +# +# +# Z=83, name="bismuth", standard_atomic_weight=208.98 +# +# +# +# +# Z=84, name="polonium", standard_atomic_weight=209.0 +# +# +# +# +# Z=85, name="astatine", standard_atomic_weight=210.0 +# +# +# +# +# Z=86, name="radon", standard_atomic_weight=222.0 +# +# +# +# +# Z=87, name="francium", standard_atomic_weight=223.0 +# +# +# +# +# Z=88, name="radium", standard_atomic_weight=226.0 +# +# +# +# +# Z=89, name="actinium", standard_atomic_weight=227.0 +# +# +# +# +# Z=90, name="thorium", standard_atomic_weight=232.038 +# +# +# +# +# Z=91, name="protactinium", standard_atomic_weight=231.036 +# +# +# +# +# Z=92, name="uranium", standard_atomic_weight=238.029 +# +# +# +# +# Z=93, name="neptunium", standard_atomic_weight=237.048 +# +# +# +# +# Z=94, name="plutonium", standard_atomic_weight=239.052 +# +# +# +# +# Z=95, name="americium", standard_atomic_weight=243.0 +# +# +# +# +# Z=96, name="curium", standard_atomic_weight=247.0 +# +# +# +# +# Z=97, name="berkelium", standard_atomic_weight=247.0 +# +# +# +# +# Z=98, name="californium", standard_atomic_weight=251.0 +# +# +# +# +# Z=99, name="einsteinium", standard_atomic_weight=252 +# +# +# +# +# Z=100, name="fermium", standard_atomic_weight=257 +# +# +# +# +# Z=101, name="mendelevium", standard_atomic_weight=258 +# +# +# +# +# Z=102, name="nobelium", standard_atomic_weight=259 +# +# +# +# +# Z=103, name="lawrencium", standard_atomic_weight=266 +# +# +# +# +# Z=104, name="rutherfordium", standard_atomic_weight=267 +# +# +# +# +# Z=105, name="dubnium", standard_atomic_weight=268 +# +# +# +# +# Z=106, name="seaborgium", standard_atomic_weight=269 +# +# +# +# +# Z=107, name="bohrium", standard_atomic_weight=270 +# +# +# +# +# Z=108, name="hassium", standard_atomic_weight=269 +# +# +# +# +# Z=109, name="meitnerium", standard_atomic_weight=278 +# +# +# +# +# Z=110, name="darmstadtium", standard_atomic_weight=281 +# +# +# +# +# Z=111, name="roentgenium", standard_atomic_weight=282 +# +# +# +# +# Z=112, name="copernicium", standard_atomic_weight=285 +# +# +# +# +# Z=113, name="nihonium", standard_atomic_weight=286 +# +# +# +# +# Z=114, name="flerovium", standard_atomic_weight=289 +# +# +# +# +# Z=115, name="moscovium", standard_atomic_weight=290 +# +# +# +# +# Z=116, name="livermorium", standard_atomic_weight=293 +# +# +# +# +# Z=117, name="tennessine", standard_atomic_weight=294 +# +# +# +# +# Z=118, name="oganesson", standard_atomic_weight=294 +# +# +# +# +# +# +# IUPAC symbol of the electronic level. +# For each level, the electronic orbital configuration is also given +# +# For reference, see Jenkins, R., Manne, R., Robin, R., & Senemaud, C. (1991). +# IUPAC—nomenclature system for x-ray spectroscopy. X-Ray Spectrometry, 20(3), 149-155. +# +# +# +# +# same as 1s in level_xray +# +# +# +# +# 2s +# +# +# +# +# 2p_{1/2} +# +# +# +# +# 2p_{3/2} +# +# +# +# +# 3s +# +# +# +# +# 3p_{1/2} +# +# +# +# +# 3p_{3/2} +# +# +# +# +# 3d_{3/2} +# +# +# +# +# 3d_{5/2} +# +# +# +# +# 4s +# +# +# +# +# 4p_{1/2} +# +# +# +# +# 4p_{3/2} +# +# +# +# +# 4d_{3/2} +# +# +# +# +# 4d_{5/2} +# +# +# +# +# 4f_{5/2} +# +# +# +# +# 4f_{7/2} +# +# +# +# +# 5s +# +# +# +# +# 5p_{1/2} +# +# +# +# +# 5p_{3/2} +# +# +# +# +# 5d_{3/2} +# +# +# +# +# 5d_{5/2} +# +# +# +# +# 5f_{5/2} +# +# +# +# +# 5f_{7/2} +# +# +# +# +# 6s +# +# +# +# +# 6p_{1/2} +# +# +# +# +# 6p_{3/2} +# +# +# +# +# +# +# Electronic orbital configuration of the electronic level. +# +# +# +# +# same as K in level_xray +# +# +# +# +# L1 +# +# +# +# +# L3 +# +# +# +# +# M1 +# +# +# +# +# M2 +# +# +# +# +# M3 +# +# +# +# +# M4 +# +# +# +# +# M5 +# +# +# +# +# N1 +# +# +# +# +# N2 +# +# +# +# +# N3 +# +# +# +# +# N4 +# +# +# +# +# N5 +# +# +# +# +# N6 +# +# +# +# +# N7 +# +# +# +# +# O1 +# +# +# +# +# O2 +# +# +# +# +# O3 +# +# +# +# +# O4 +# +# +# +# +# O5 +# +# +# +# +# O6 +# +# +# +# +# O7 +# +# +# +# +# P1 +# +# +# +# +# P2 +# +# +# +# +# P3 +# +# +# +# +# +# +# description of X-ray electronic level +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# From 39e57bddcbbc88d1fcbcc85f47dd949b9059db16 Mon Sep 17 00:00:00 2001 From: domna Date: Thu, 5 Oct 2023 17:44:34 +0200 Subject: [PATCH 0317/1012] Sync yaml files to nxdl --- base_classes/nyaml/NXdetector.yaml | 45 +-- base_classes/nyaml/NXinstrument.yaml | 3 +- base_classes/nyaml/NXsensor.yaml | 337 +++++++++--------- base_classes/nyaml/NXsource.yaml | 5 +- .../nyaml/NXcollectioncolumn.yaml | 4 +- .../nyaml/NXelectronanalyser.yaml | 6 +- .../nyaml/NXenergydispersion.yaml | 6 +- contributed_definitions/nyaml/NXlink.yaml | 46 ++- .../nyaml/NXmanipulator.yaml | 6 +- contributed_definitions/nyaml/NXmpes.yaml | 142 +++++--- .../nyaml/NXresolution.yaml | 116 +++++- 11 files changed, 466 insertions(+), 250 deletions(-) diff --git a/base_classes/nyaml/NXdetector.yaml b/base_classes/nyaml/NXdetector.yaml index 8fd286fc58..12df646e15 100644 --- a/base_classes/nyaml/NXdetector.yaml +++ b/base_classes/nyaml/NXdetector.yaml @@ -36,12 +36,12 @@ type: group \@axis: type: NX_POSINT deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 + see: https://github.com/nexusformat/definitions/issues/436 enumeration: [3] \@primary: type: NX_POSINT deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 + see: https://github.com/nexusformat/definitions/issues/436 enumeration: [1] \@long_name: doc: | @@ -116,12 +116,12 @@ type: group \@axis: type: NX_POSINT deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 + see: https://github.com/nexusformat/definitions/issues/436 enumeration: [1] \@primary: type: NX_POSINT deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 + see: https://github.com/nexusformat/definitions/issues/436 enumeration: [1] \@long_name: doc: | @@ -137,12 +137,12 @@ type: group \@axis: type: NX_POSINT deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 + see: https://github.com/nexusformat/definitions/issues/436 enumeration: [2] \@primary: type: NX_POSINT deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 + see: https://github.com/nexusformat/definitions/issues/436 enumeration: [1] \@long_name: doc: | @@ -158,12 +158,12 @@ type: group \@axis: type: NX_POSINT deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 + see: https://github.com/nexusformat/definitions/issues/436 enumeration: [3] \@primary: type: NX_POSINT deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 + see: https://github.com/nexusformat/definitions/issues/436 enumeration: [1] \@long_name: doc: | @@ -753,7 +753,7 @@ type: group other component groups. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 6b256ef0615dca7d8faf4a3bc04d3e62f29a1745e9cd35205e5f0bb9e2c6520c +# cf337a792e12304ca6fa5767928b3a58b6527152c48a24d0406e227efc050cb7 # # # -# -# -# A sensor used to monitor an external condition -# -# The condition itself is described in :ref:`NXenvironment`. -# -# -# Sensor identification code/model number -# -# -# Name for the sensor -# -# -# Short name of sensor used e.g. on monitor display program -# -# -# where sensor is attached to ("sample" | "can") -# -# -# -# Defines the axes for logged vector quantities if they are not the global instrument axes. -# -# -# -# name for measured signal -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The type of hardware used for the measurement. -# Examples (suggestions but not restrictions): -# -# :Temperature: -# J | K | T | E | R | S | Pt100 | Rh/Fe -# :pH: -# Hg/Hg2Cl2 | Ag/AgCl | ISFET -# :Ion selective electrode: -# specify species; e.g. Ca2+ -# :Magnetic field: -# Hall -# :Surface pressure: -# wilhelmy plate -# -# -# -# -# Is data collection controlled or synchronised to this quantity: -# 1=no, 0=to "value", 1=to "value_deriv1", etc. -# -# -# -# -# Upper control bound of sensor reading if using run_control -# -# -# -# -# Lower control bound of sensor reading if using run_control -# -# -# -# -# nominal setpoint or average value -# - need [n] as may be a vector -# -# -# -# -# -# -# -# Nominal/average first derivative of value -# e.g. strain rate -# - same dimensions as "value" (may be a vector) -# -# -# -# -# -# -# -# Nominal/average second derivative of value -# - same dimensions as "value" (may be a vector) -# -# -# -# -# -# -# Time history of sensor readings -# -# -# Time history of first derivative of sensor readings -# -# -# Time history of second derivative of sensor readings -# -# -# -# -# -# -# -# -# -# -# -# -# For complex external fields not satisfied by External_field_brief -# -# -# -# This group describes the shape of the sensor when necessary. -# -# +# +# +# A sensor used to monitor an external condition +# +# The condition itself is described in :ref:`NXenvironment`. +# +# +# +# Sensor identification code/model number +# +# +# +# +# Name for the sensor +# +# +# +# +# Short name of sensor used e.g. on monitor display program +# +# +# +# +# where sensor is attached to ("sample" | "can") +# +# +# +# +# Defines the axes for logged vector quantities if they are not the global +# instrument axes. +# +# +# +# +# name for measured signal +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The type of hardware used for the measurement. +# Examples (suggestions but not restrictions): +# +# :Temperature: +# J | K | T | E | R | S | Pt100 | Rh/Fe +# :pH: +# Hg/Hg2Cl2 | Ag/AgCl | ISFET +# :Ion selective electrode: +# specify species; e.g. Ca2+ +# :Magnetic field: +# Hall +# :Surface pressure: +# wilhelmy plate +# +# +# +# +# Is data collection controlled or synchronised to this quantity: +# 1=no, 0=to "value", 1=to "value_deriv1", etc. +# +# +# +# +# Upper control bound of sensor reading if using run_control +# +# +# +# +# Lower control bound of sensor reading if using run_control +# +# +# +# +# nominal setpoint or average value +# - need [n] as may be a vector +# +# +# +# +# +# +# +# Nominal/average first derivative of value +# e.g. strain rate +# - same dimensions as "value" (may be a vector) +# +# +# +# +# +# +# +# Nominal/average second derivative of value +# - same dimensions as "value" (may be a vector) +# +# +# +# +# +# +# +# Time history of sensor readings +# +# +# +# +# Time history of first derivative of sensor readings +# +# +# +# +# Time history of second derivative of sensor readings +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# For complex external fields not satisfied by External_field_brief +# +# +# +# +# This group describes the shape of the sensor when necessary. +# +# +# # # -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. # # # # -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a sensor. -# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a sensor. # # # # -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. # # # -# diff --git a/base_classes/nyaml/NXsource.yaml b/base_classes/nyaml/NXsource.yaml index 1692b666ea..6e275f7535 100644 --- a/base_classes/nyaml/NXsource.yaml +++ b/base_classes/nyaml/NXsource.yaml @@ -203,7 +203,7 @@ NXsource(NXobject): other component groups. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 19f1ee4e446868766ab035145a5835ce38e26b04d8e8ee50bf641392cb5c3525 +# 248872a89ab8cb9c738d47d23b9cf7fa50bac04b2beb1428f677ec9ec23fc29b # # # -# +# # # # The symbols used in the schema to specify e.g. dimensions of arrays @@ -254,4 +255,5 @@ NXelectronanalyser(NXobject): # Individual lenses outside the main optics ensambles described by the subclasses # # +# # diff --git a/contributed_definitions/nyaml/NXenergydispersion.yaml b/contributed_definitions/nyaml/NXenergydispersion.yaml index 476e8af2b3..da8e301248 100644 --- a/contributed_definitions/nyaml/NXenergydispersion.yaml +++ b/contributed_definitions/nyaml/NXenergydispersion.yaml @@ -47,9 +47,10 @@ NXenergydispersion(NXobject): (NXlens_em): doc: | Individual lenses in the energy dispersive section + (NXfabrication): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 165eadae7ad3081364c89bc4229eb2a01d197b0706e2c663e07201dc088a5069 +# 3ea3bbd68a7e09a25fcdb8ce6a677d5a1e8b307138d9cfadd0948158678e35bf # # # -# +# # # Subclass of NXelectronanalyser to describe the energy dispersion section of a # photoelectron analyser. @@ -139,4 +140,5 @@ NXenergydispersion(NXobject): # Individual lenses in the energy dispersive section # # +# # diff --git a/contributed_definitions/nyaml/NXlink.yaml b/contributed_definitions/nyaml/NXlink.yaml index c702fbf3c1..fb365783dc 100644 --- a/contributed_definitions/nyaml/NXlink.yaml +++ b/contributed_definitions/nyaml/NXlink.yaml @@ -2,11 +2,53 @@ category: base doc: | Describes a link type: group -NXlink: +NXlink(NXobject): symbol: doc: | The symbol by which to refer to this link, e.g., for formulas path: doc: | A valid path inside an instance of an application definition, i.e., - of the form /entry/instrument/my_part/my_field \ No newline at end of file + of the form /entry/instrument/my_part/my_field + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# c176f19b15aeea095850727a438a8ab87c5ff5dc7c99dd25ace497391130dcf6 +# +# +# +# +# +# Describes a link +# +# +# +# The symbol by which to refer to this link, e.g., for formulas +# +# +# +# +# A valid path inside an instance of an application definition, i.e., +# of the form /entry/instrument/my_part/my_field +# +# +# diff --git a/contributed_definitions/nyaml/NXmanipulator.yaml b/contributed_definitions/nyaml/NXmanipulator.yaml index bbdbc71ff7..d18c3351ee 100644 --- a/contributed_definitions/nyaml/NXmanipulator.yaml +++ b/contributed_definitions/nyaml/NXmanipulator.yaml @@ -42,6 +42,7 @@ NXmanipulator(NXobject): (NXpositioner): doc: | Class to describe the motors that are used in the manipulator + (NXfabrication): depends_on(NX_CHAR): doc: | Refers to the last transformation specifying the positon of the manipulator in @@ -58,7 +59,7 @@ NXmanipulator(NXobject): the reference coordinate system. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# c527776b537badfe6de69128070ba851dfa9252963bb6cbb98c4af20298483ac +# bf0f034176effed85072715ae95240a10701067bb337ea55c84482351c3d539d # # # -# +# # # Extension of NXpositioner to include fields to describe the use of manipulators # in photoemission experiments. @@ -140,6 +141,7 @@ NXmanipulator(NXobject): # Class to describe the motors that are used in the manipulator # # +# # # # Refers to the last transformation specifying the positon of the manipulator in diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 5f92c70199..a3a75c5654 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -10,16 +10,16 @@ NXmpes(NXobject): doc: | Datetime of the start of the measurement. end_time(NX_DATE_TIME): + exists: recommended doc: | Datetime of the end of the measurement. - exists: recommended method: + exists: recommended doc: | A name of the experimental method according to the `ISO 18115-1:2023`_ specification. .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html - exists: recommended definition: \@version: enumeration: [NXmpes] @@ -63,7 +63,7 @@ NXmpes(NXobject): model: exists: recommended identifier: - exists: recommended + exists: recommended source_TYPE(NXsource): # Comment from mpes may workshop: @@ -102,10 +102,10 @@ NXmpes(NXobject): for `source_probe` it should refer to `beam_probe`. Refers to the same concept as /NXentry/NXinstrument/source_TYPE and may be linked. - - # It would be nice if we had the notion of linking in nexus or if - # we have a subdefinition NXlink to refer to a path. - # This would also be helpful for NXtransformations + + # It would be nice if we had the notion of linking in nexus or if + # we have a subdefinition NXlink to refer to a path. + # This would also be helpful for NXtransformations beam_TYPE(NXbeam): # Comment from mpes may workshop: Add linking between source and beam @@ -165,9 +165,9 @@ NXmpes(NXobject): Scheme of the electron collection column. enumeration: [Standard, Angular dispersive, Spatial dispersive, Selective area, Deflector, PEEM, Momentum Microscope] mode: + exists: recommended doc: | Labelling of the lens setting in use. - exists: recommended projection: exists: recommended field_aperture(NXaperture): @@ -187,7 +187,7 @@ NXmpes(NXobject): model: exists: recommended identifier: - exists: recommended + exists: recommended (NXenergydispersion): scheme: enumeration: [tof, hemispherical, double hemispherical, cylindrical mirror, display mirror, retarding grid] @@ -211,7 +211,7 @@ NXmpes(NXobject): model: exists: recommended identifier: - exists: recommended + exists: recommended (NXdetector): amplifier_type: exists: recommended @@ -230,7 +230,7 @@ NXmpes(NXobject): model: exists: recommended identifier: - exists: recommended + exists: recommended (NXdata): exists: recommended \@signal: @@ -258,7 +258,7 @@ NXmpes(NXobject): model: exists: recommended identifier: - exists: recommended + exists: recommended (NXprocess): exists: recommended doc: | @@ -367,14 +367,14 @@ NXmpes(NXobject): actual encoder position in NXinstrument or calibrated axes in NXprocess. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e18956fa79544e7b4f50e31f3b421e387cab531f4f608e4c9dfc0013fa459429 +# a27df77488bce51e7711d410341e677babaca36bda5762cb28b074b1438b4a1a # # # +# +# +# +# +# +# +# +# +# +# +# +# +# +# # # 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 @@ -486,7 +496,7 @@ NXmpes(NXobject): # # # -# Specification of type, may also go to name. +# Specification of type, may also go to name. # # # @@ -499,21 +509,50 @@ NXmpes(NXobject): # # # +# +# +# +# +# +# +# +# The beam emitted by this source. +# Should be named with the same appendix, e.g., +# for `source_probe` it should refer to `beam_probe`. +# Refers to the same concept as /NXentry/NXinstrument/source_TYPE +# and may be linked. +# +# # -# -# -# +# +# +# +# # # -# Distance of the point of evaluation of the beam from the sample surface. +# Distance between the point where this NXbeam instance is evaluating the beam properties +# and the intersection point of the beam and the sample. +# For photoemission, this intersection point is where the centre of the beam touches the sample surface. # # # # # +# +# +# +# The beam emitted by this source. +# Should be named with the same appendix, e.g., +# for `beam_probe` it should refer to `source_probe`. +# Refers to the same concept as /NXentry/NXinstrument/beam_TYPE +# and may be linked. +# +# # # -# +# # # # @@ -528,12 +567,9 @@ NXmpes(NXobject): # # # -# +# # # # Scheme of the electron collection column. @@ -548,7 +584,11 @@ NXmpes(NXobject): # # # -# +# +# +# Labelling of the lens setting in use. +# +# # # # @@ -562,6 +602,11 @@ NXmpes(NXobject): # additional or other apertures use the APERTURE group of NXcollectioncolumn. # # +# +# +# +# +# # # # @@ -588,6 +633,11 @@ NXmpes(NXobject): # additional or other slits use the APERTURE group of NXenergydispersion. # # +# +# +# +# +# # # # @@ -612,11 +662,12 @@ NXmpes(NXobject): # # # +# +# +# +# +# # -# # # # @@ -637,6 +688,11 @@ NXmpes(NXobject): # # # +# +# +# +# +# # # # @@ -750,10 +806,10 @@ NXmpes(NXobject): # # # -# +# # # -# Voltage applied to sample and sample holder. +# Voltage applied to sample and sample holder. # # # diff --git a/contributed_definitions/nyaml/NXresolution.yaml b/contributed_definitions/nyaml/NXresolution.yaml index 9ed5dbf671..aedf6436f6 100644 --- a/contributed_definitions/nyaml/NXresolution.yaml +++ b/contributed_definitions/nyaml/NXresolution.yaml @@ -2,12 +2,12 @@ category: base doc: | Describes the resolution of a physical quantity. type: group -NXresolution: +NXresolution(NXobject): physical_quantity: + unit: NX_ANY doc: | The physical quantity of the resolution, e.g., energy, momentum, time, etc. - unit: NX_ANY type: doc: | The process by which the resolution was determined. @@ -16,9 +16,9 @@ NXresolution: doc: | Additional details of the estimate or description of the calibration procedure resolution(NX_FLOAT): + unit: NX_ANY doc: | The resolution of the physical quantity. - unit: NX_ANY response_function(NXdata): doc: | The response of the instrument or part to a infinitesimal short input signal @@ -27,10 +27,10 @@ NXresolution: point spread function for spatial response. The resolution is typically determined by taking the FWHM of the response function. input(NX_FLOAT): + unit: NX_ANY doc: | The input axis or grid of the response function. The unit should match the one of the resolution field. - unit: NX_ANY magnitude(NX_FLOAT): doc: | The magnitude of the response function corresponding to the points @@ -41,15 +41,115 @@ NXresolution: A symbol linking to another path in this appdef to be referred to from the `resolution_formula` field. symbol: - exists: required + exists: optional path: - exists: required + exists: optional resolution_formula: + unit: NX_ANY doc: | A resolution formula to determine the resolution from a set of symbols as entered by the `formula_symbol_...` fields. The output unit should match the provided unit of this field. - unit: NX_ANY (NXcalibration): doc: | - For storing details and data of a calibration to derive a resolution from data \ No newline at end of file + For storing details and data of a calibration to derive a resolution from data + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 19a4cbcbcc4acbb38b8752aaf11bbc6114977960e60e85542492ddc28743ba19 +# +# +# +# +# +# Describes the resolution of a physical quantity. +# +# +# +# The physical quantity of the resolution, e.g., +# energy, momentum, time, etc. +# +# +# +# +# The process by which the resolution was determined. +# +# +# +# +# +# +# +# +# +# +# Additional details of the estimate or description of the calibration procedure +# +# +# +# +# The resolution of the physical quantity. +# +# +# +# +# The response of the instrument or part to a infinitesimal short input signal +# along the physical quantity of this group. +# This is also sometimes called instrument response function for time resolution or +# point spread function for spatial response. +# The resolution is typically determined by taking the FWHM of the response function. +# +# +# +# The input axis or grid of the response function. +# The unit should match the one of the resolution field. +# +# +# +# +# The magnitude of the response function corresponding to the points +# in the input axis or grid. +# This field should have the same dimensions as `input`. +# +# +# +# +# +# A symbol linking to another path in this appdef +# to be referred to from the `resolution_formula` field. +# +# +# +# +# +# +# A resolution formula to determine the resolution from a set of symbols as +# entered by the `formula_symbol_...` fields. +# The output unit should match the provided unit of this field. +# +# +# +# +# For storing details and data of a calibration to derive a resolution from data +# +# +# From d8d4c7e3aad67296f03c922f11cdc6e9e8fa7409 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 6 Oct 2023 11:25:13 +0200 Subject: [PATCH 0318/1012] Fix merge conflicts in NXdetector, remove NXdetector.yaml from contributed --- base_classes/nyaml/NXdetector.yaml | 85 - contributed_definitions/nyaml/NXdetector.yaml | 1758 ----------------- 2 files changed, 1843 deletions(-) delete mode 100644 contributed_definitions/nyaml/NXdetector.yaml diff --git a/base_classes/nyaml/NXdetector.yaml b/base_classes/nyaml/NXdetector.yaml index ad93246f15..e59ff28e13 100644 --- a/base_classes/nyaml/NXdetector.yaml +++ b/base_classes/nyaml/NXdetector.yaml @@ -36,20 +36,12 @@ type: group \@axis: type: NX_POSINT deprecated: | -<<<<<<< HEAD see: https://github.com/nexusformat/definitions/issues/436 -======= - see: https://github.com/nexusformat/definitions/issues/436 ->>>>>>> mpes-refactor enumeration: [3] \@primary: type: NX_POSINT deprecated: | -<<<<<<< HEAD see: https://github.com/nexusformat/definitions/issues/436 -======= - see: https://github.com/nexusformat/definitions/issues/436 ->>>>>>> mpes-refactor enumeration: [1] \@long_name: doc: | @@ -124,20 +116,12 @@ type: group \@axis: type: NX_POSINT deprecated: | -<<<<<<< HEAD see: https://github.com/nexusformat/definitions/issues/436 -======= - see: https://github.com/nexusformat/definitions/issues/436 ->>>>>>> mpes-refactor enumeration: [1] \@primary: type: NX_POSINT deprecated: | -<<<<<<< HEAD see: https://github.com/nexusformat/definitions/issues/436 -======= - see: https://github.com/nexusformat/definitions/issues/436 ->>>>>>> mpes-refactor enumeration: [1] \@long_name: doc: | @@ -153,20 +137,12 @@ type: group \@axis: type: NX_POSINT deprecated: | -<<<<<<< HEAD see: https://github.com/nexusformat/definitions/issues/436 -======= - see: https://github.com/nexusformat/definitions/issues/436 ->>>>>>> mpes-refactor enumeration: [2] \@primary: type: NX_POSINT deprecated: | -<<<<<<< HEAD see: https://github.com/nexusformat/definitions/issues/436 -======= - see: https://github.com/nexusformat/definitions/issues/436 ->>>>>>> mpes-refactor enumeration: [1] \@long_name: doc: | @@ -182,20 +158,12 @@ type: group \@axis: type: NX_POSINT deprecated: | -<<<<<<< HEAD - see: https://github.com/nexusformat/definitions/issues/436 -======= see: https://github.com/nexusformat/definitions/issues/436 ->>>>>>> mpes-refactor enumeration: [3] \@primary: type: NX_POSINT deprecated: | -<<<<<<< HEAD - see: https://github.com/nexusformat/definitions/issues/436 -======= see: https://github.com/nexusformat/definitions/issues/436 ->>>>>>> mpes-refactor enumeration: [1] \@long_name: doc: | @@ -785,11 +753,7 @@ type: group other component groups. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -<<<<<<< HEAD -# 6b256ef0615dca7d8faf4a3bc04d3e62f29a1745e9cd35205e5f0bb9e2c6520c -======= # cf337a792e12304ca6fa5767928b3a58b6527152c48a24d0406e227efc050cb7 ->>>>>>> mpes-refactor # # # -# -# -# -# These symbols will be used below to illustrate the coordination of the -# rank and sizes of datasets and the preferred ordering of the -# dimensions. Each of these are optional (so the rank of the datasets -# will vary according to the situation) and the general ordering -# principle is slowest to fastest. The type of each dimension should -# follow the order of scan points, detector output (e.g. pixels), then -# time-of-flight (i.e. spectroscopy, spectrometry). Note that the output -# of a detector is not limited to single values (0D), lists (1D) and -# images (2), but three or higher dimensional arrays can be produced by -# a detector at each trigger. -# -# -# -# number of scan points (only present in scanning measurements) -# -# -# -# -# number of detector pixels in the first (slowest) direction -# -# -# -# -# number of detector pixels in the second (faster) direction -# -# -# -# -# number of detector pixels in the third (if necessary, fastest) -# direction -# -# -# -# -# number of bins in the time-of-flight histogram -# -# -# -# -# A detector, detector bank, or multidetector. -# -# -# -# Total time of flight -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Total time of flight -# -# -# -# -# -# In DAQ clock pulses -# -# -# -# -# -# -# Clock frequency in Hz -# -# -# -# -# -# Identifier for detector (pixels) -# Can be multidimensional, if needed -# -# -# -# -# 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. -# -# -# -# -# -# -# -# -# -# Title of measurement -# -# -# -# -# Integral of data as check of data integrity -# -# -# -# -# -# The best estimate of the uncertainty in the data value (array size should match the data field). Where -# possible, this should be the standard deviation, which has the same units -# as the data. The form data_error is deprecated. -# -# -# -# -# -# -# -# -# -# -# Offset from the detector center in x-direction. -# Can be multidimensional when needed. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# x-axis offset from detector center -# -# -# -# -# -# Offset from the detector center in the y-direction. -# Can be multidimensional when different values are required for each pixel. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# y-axis offset from detector center -# -# -# -# -# -# Offset from the detector center in the z-direction. -# Can be multidimensional when different values are required for each pixel. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# y-axis offset from detector center -# -# -# -# -# -# This is the distance to the previous component in the -# instrument; most often the sample. The usage depends on the -# nature of the detector: Most often it is the distance of the -# detector assembly. But there are irregular detectors. In this -# case the distance must be specified for each detector pixel. -# -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# -# -# -# -# -# This is the polar angle of the detector towards the previous -# component in the instrument; most often the sample. -# The usage depends on the -# nature of the detector. -# Most often it is the polar_angle of the detector assembly. -# But there are irregular detectors. -# In this -# case, the polar_angle must be specified for each detector pixel. -# -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# -# -# -# -# -# This is the azimuthal angle angle of the detector towards -# the previous component in the instrument; most often the sample. -# The usage depends on the -# nature of the detector. -# Most often it is the azimuthal_angle of the detector assembly. -# But there are irregular detectors. -# In this -# case, the azimuthal_angle must be specified for each detector pixel. -# -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# -# -# -# -# -# name/manufacturer/model/etc. information -# -# -# -# -# Serial number for the detector -# -# -# -# -# Local name for the detector -# -# -# -# -# Position and orientation of detector -# -# -# -# -# Solid angle subtended by the detector at the sample -# -# -# -# -# -# -# -# -# Size of each detector pixel. If it is scalar all pixels are the same size. -# -# -# -# -# -# -# -# -# Size of each detector pixel. If it is scalar all pixels are the same size -# -# -# -# -# -# -# -# -# Detector dead time -# -# -# -# -# -# -# -# -# -# Detector gas pressure -# -# -# -# -# -# -# -# -# maximum drift space dimension -# -# -# -# -# Crate number of detector -# -# -# -# -# -# -# -# Equivalent local term -# -# -# -# -# -# Slot number of detector -# -# -# -# -# -# -# -# Equivalent local term -# -# -# -# -# -# Input number of detector -# -# -# -# -# -# -# -# Equivalent local term -# -# -# -# -# -# Description of type such as He3 gas cylinder, He3 PSD, scintillator, -# fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, -# CMOS, ... -# -# -# -# -# Spectral efficiency of detector with respect to e.g. wavelength -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# efficiency of the detector -# -# -# -# -# -# -# -# -# -# This field can be two things: -# -# 1. For a pixel detector it provides the nominal wavelength -# for which the detector has been calibrated. -# -# 2. For other detectors this field has to be seen together with -# the efficiency field above. -# For some detectors, the efficiency is wavelength dependent. -# Thus this field provides the wavelength axis for the efficiency field. -# In this use case, the efficiency and wavelength arrays must -# have the same dimensionality. -# -# -# -# -# -# -# -# -# -# -# Real-time of the exposure (use this if exposure time varies for -# each array element, otherwise use ``count_time`` field). -# -# Most often there is a single real time value that is constant across -# an entire image frame. In such cases, only a 1-D array is needed. -# But there are detectors in which the real time -# changes per pixel. In that case, more than one dimension is needed. Therefore -# the rank of this field should be less than or equal to (detector rank + 1). -# -# -# -# -# -# -# -# -# -# start time for each frame, with the ``start`` attribute as absolute reference -# -# -# -# -# -# -# -# -# stop time for each frame, with the ``start`` attribute as absolute reference -# -# -# -# -# -# -# -# -# date of last calibration (geometry and/or efficiency) measurements -# -# -# -# -# summary of conversion of array data to pixels (e.g. polynomial -# approximations) and location of details of the calibrations -# -# -# -# -# How the detector is represented -# -# -# -# -# -# -# -# -# -# Elapsed actual counting time -# -# -# -# -# -# -# -# -# Use this group to provide other data related to this NXdetector group. -# -# -# -# -# In order to properly sort the order of the images taken in (for -# example) a tomography experiment, a sequence number is stored with each -# image. -# -# -# -# -# -# -# -# This is the x position where the direct beam would hit the detector. -# This is a length and can be outside of the actual -# detector. The length can be in physical units or pixels -# as documented by the units attribute. -# -# -# -# -# This is the y position where the direct beam would hit the detector. -# This is a length and can be outside of the actual -# detector. The length can be in physical units or pixels -# as documented by the units attribute. -# -# -# -# -# This is the start number of the first frame of a scan. In protein crystallography measurements one -# often scans a couple of frames on a give sample, then does something else, -# then returns to the same sample and scans some more frames. Each time with -# a new data file. This number helps concatenating such measurements. -# -# -# -# -# The diameter of a cylindrical detector -# -# -# -# -# The acquisition mode of the detector. -# -# -# -# -# -# -# -# -# -# -# -# -# True when the angular calibration has been applied in the -# electronics, false otherwise. -# -# -# -# -# Angular calibration data. -# -# -# -# -# -# -# -# -# True when the flat field correction has been applied in the -# electronics, false otherwise. -# -# -# -# -# Flat field correction data. -# -# -# -# -# -# -# -# -# Errors of the flat field correction data. -# The form flatfield_error is deprecated. -# -# -# -# -# -# -# -# -# True when the pixel mask correction has been applied in the -# electronics, false otherwise. -# -# -# -# -# The 32-bit pixel mask for the detector. Can be either one mask -# for the whole dataset (i.e. an array with indices i, j) or -# each frame can have its own mask (in which case it would be -# an array with indices np, i, j). -# -# Contains a bit field for each pixel to signal dead, -# blind or high or otherwise unwanted or undesirable pixels. -# They have the following meaning: -# -# .. can't make a table here, a bullet list will have to do for now -# -# * bit 0: gap (pixel with no sensor) -# * bit 1: dead -# * bit 2: under responding -# * bit 3: over responding -# * bit 4: noisy -# * bit 5: -undefined- -# * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) -# * bit 7: -undefined- -# * bit 8: user defined mask (e.g. around beamstop) -# * bits 9-30: -undefined- -# * bit 31: virtual pixel (corner pixel with interpolated value) -# -# Normal data analysis software would -# not take pixels into account -# when a bit in (mask & 0x0000FFFF) is -# set. Tag bit in the upper -# two bytes would indicate special pixel -# properties that normally -# would not be a sole reason to reject the -# intensity value (unless -# lower bits are set. -# -# If the full bit depths is not required, providing a -# mask with fewer bits is permissible. -# -# If needed, additional pixel masks can be specified by -# including additional entries named pixel_mask_N, where -# N is an integer. For example, a general bad pixel mask -# could be specified in pixel_mask that indicates noisy -# and dead pixels, and an additional pixel mask from -# experiment-specific shadowing could be specified in -# pixel_mask_2. The cumulative mask is the bitwise OR -# of pixel_mask and any pixel_mask_N entries. -# -# -# -# -# -# -# -# -# This field allow to distinguish different types of exposure to the same detector "data" field. -# Some techniques require frequent (re-)calibration inbetween measuremnts and this way of -# recording the different measurements preserves the chronological order with is important for -# correct processing. -# -# This is used for example in tomography (`:ref:`NXtomo`) sample projections, -# dark and flat images, a magic number is recorded per frame. -# -# The key is as follows: -# -# * projection (sample) = 0 -# * flat field = 1 -# * dark field = 2 -# * invalid = 3 -# * background (no sample, but buffer where applicable) = 4 -# -# In cases where the data is of type :ref:`NXlog` this can also be an NXlog. -# -# -# -# -# -# -# -# Counting detectors usually are not able to measure all incoming particles, -# especially at higher count-rates. Count-rate correction is applied to -# account for these errors. -# -# True when count-rate correction has been applied, false otherwise. -# -# -# -# -# The countrate_correction_lookup_table defines the LUT used for count-rate -# correction. It maps a measured count :math:`c` to its corrected value -# :math:`countrate\_correction\_lookup\_table[c]`. -# -# :math:`m` denotes the length of the table. -# -# -# -# -# -# -# -# True when virtual pixel interpolation has been applied, false otherwise. -# -# When virtual pixel interpolation is applied, values of some pixels may -# contain interpolated values. For example, to account for space between -# readout chips on a module, physical pixels on edges and corners between -# chips may have larger sensor areas and counts may be distributed between -# their logical pixels. -# -# -# -# -# How many bits the electronics reads per pixel. -# With CCD's and single photon counting detectors, -# this must not align with traditional integer sizes. -# This can be 4, 8, 12, 14, 16, ... -# -# -# -# -# Time it takes to read the detector (typically milliseconds). -# This is important to know for time resolved experiments. -# -# -# -# -# Time it takes to start exposure after a trigger signal has been received. -# This is the reaction time of the detector firmware after receiving the trigger signal -# to when the detector starts to acquire the exposure, including any user set delay.. -# This is important to know for time resolved experiments. -# -# -# -# -# User-specified trigger delay. -# -# -# -# -# Time it takes to start exposure after a trigger signal has been received. -# This is the reaction time of the detector hardware after receiving the -# trigger signal to when the detector starts to acquire the exposure. -# It forms the lower boundary of the trigger_delay_time when the user -# does not request an additional delay. -# -# -# -# -# Time during which no new trigger signal can be accepted. -# Typically this is the -# trigger_delay_time + exposure_time + readout_time. -# This is important to know for time resolved experiments. -# -# -# -# -# This is time for each frame. This is exposure_time + readout time. -# -# -# -# -# -# -# -# The gain setting of the detector. This is a detector-specific value -# meant to document the gain setting of the detector during data -# collection, for detectors with multiple available gain settings. -# -# Examples of gain settings include: -# -# * ``standard`` -# * ``fast`` -# * ``auto`` -# * ``high`` -# * ``medium`` -# * ``low`` -# * ``mixed high to medium`` -# * ``mixed medium to low`` -# -# Developers are encouraged to use one of these terms, or to submit -# additional terms to add to the list. -# -# -# -# -# The value at which the detector goes into saturation. -# Especially common to CCD detectors, the data -# is known to be invalid above this value. -# -# For example, given a saturation_value and an underload_value, the valid -# pixels are those less than or equal to the saturation_value and greater -# than or equal to the underload_value. -# -# The precise type should match the type of the data. -# -# -# -# -# The lowest value at which pixels for this detector would be reasonably -# measured. The data is known to be invalid below this value. -# -# For example, given a saturation_value and an underload_value, the valid -# pixels are those less than or equal to the saturation_value and greater -# than or equal to the underload_value. -# -# The precise type should match the type of the data. -# -# -# -# -# CCD images are sometimes constructed by summing -# together multiple short exposures in the -# electronics. This reduces background etc. -# This is the number of short exposures used to sum -# images for an image. -# -# -# -# -# At times, radiation is not directly sensed by the detector. -# Rather, the detector might sense the output from some -# converter like a scintillator. -# This is the name of this converter material. -# -# -# -# -# At times, radiation is not directly sensed by the detector. -# Rather, the detector might sense the output from some -# converter like a scintillator. -# This is the thickness of this converter material. -# -# -# -# -# Single photon counter detectors can be adjusted -# for a certain energy range in which they -# work optimally. This is the energy setting for this. -# -# -# -# -# For use in special cases where the data in NXdetector -# is represented in several parts, each with a separate geometry. -# -# -# -# -# -# Shape description of each pixel. Use only if all pixels in the detector -# are of uniform shape. -# -# -# -# -# Shape description of each pixel. Use only if all pixels in the detector -# are of uniform shape and require being described by cylinders. -# -# -# -# -# -# -# Shape description of the whole detector. Use only if pixels in the -# detector are not of uniform shape. -# -# -# -# -# Shape description of the whole detector. Use only if pixels in the -# detector are not of uniform shape and require being described by cylinders. -# -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# Type of electron amplifier, MCP, channeltron, etc. -# -# -# -# -# Description of the detector type, DLD, Phosphor+CCD, CMOS. -# -# -# -# -# Voltage applied to detector. -# -# -# -# -# Voltage applied to the amplifier. -# -# -# -# -# The low voltage of the amplifier migh not be the ground. -# -# -# -# -# Size of each imaging sensor chip on the detector. -# -# -# -# -# Number of imaging sensor chips on the detector. -# -# -# -# -# Physical size of the pixels of the imaging chip on the detector. -# -# -# -# -# Number of raw active elements in each dimension. Important for swept scans. -# -# -# -# -# raw data output from the detector -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# The reference point of the detector is the center of the first pixel. -# In complex geometries the NXoff_geometry groups can be used to provide an unambiguous reference. -# -# -# -# -# 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. -# -# -# From 65c6b9a371b277c534402dd27e7fa3a51aacca43 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 6 Oct 2023 11:28:08 +0200 Subject: [PATCH 0319/1012] typo fix in NXdetector --- base_classes/nyaml/NXdetector.yaml | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/base_classes/nyaml/NXdetector.yaml b/base_classes/nyaml/NXdetector.yaml index e59ff28e13..c296bd1062 100644 --- a/base_classes/nyaml/NXdetector.yaml +++ b/base_classes/nyaml/NXdetector.yaml @@ -36,12 +36,12 @@ type: group \@axis: type: NX_POSINT deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 + see: https://github.com/nexusformat/definitions/issues/436 enumeration: [3] \@primary: type: NX_POSINT deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 + see: https://github.com/nexusformat/definitions/issues/436 enumeration: [1] \@long_name: doc: | @@ -116,12 +116,12 @@ type: group \@axis: type: NX_POSINT deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 + see: https://github.com/nexusformat/definitions/issues/436 enumeration: [1] \@primary: type: NX_POSINT deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 + see: https://github.com/nexusformat/definitions/issues/436 enumeration: [1] \@long_name: doc: | @@ -137,12 +137,12 @@ type: group \@axis: type: NX_POSINT deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 + see: https://github.com/nexusformat/definitions/issues/436 enumeration: [2] \@primary: type: NX_POSINT deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 + see: https://github.com/nexusformat/definitions/issues/436 enumeration: [1] \@long_name: doc: | From e400ca896a0630febf879f0262560e4f4df3947a Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 6 Oct 2023 11:35:18 +0200 Subject: [PATCH 0320/1012] more merge conflict fixes --- base_classes/nyaml/NXinstrument.yaml | 7 - base_classes/nyaml/NXsensor.yaml | 181 ------------------ base_classes/nyaml/NXsource.yaml | 11 -- .../nyaml/NXelectronanalyser.yaml | 3 - contributed_definitions/nyaml/NXmpes.yaml | 18 +- .../nyaml/NXresolution.yaml | 6 +- 6 files changed, 12 insertions(+), 214 deletions(-) diff --git a/base_classes/nyaml/NXinstrument.yaml b/base_classes/nyaml/NXinstrument.yaml index 769324e33e..cd0d59b9ac 100644 --- a/base_classes/nyaml/NXinstrument.yaml +++ b/base_classes/nyaml/NXinstrument.yaml @@ -77,11 +77,7 @@ NXinstrument(NXobject): for a summary of the discussion. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -<<<<<<< HEAD -# 331d6037bd4c05402a42cab90e3df4c3115b21231d57ef54b1221e1ed859584d -======= # 4819502714f5d1f330e53573dbfcbce7b66fafa5c5f8241e3f56c3dbbf3fd5d7 ->>>>>>> mpes-refactor # # # -<<<<<<< HEAD -# -# -# A sensor used to monitor an external condition -# -# The condition itself is described in :ref:`NXenvironment`. -# -# -# Sensor identification code/model number -# -# -# Name for the sensor -# -# -# Short name of sensor used e.g. on monitor display program -# -# -# where sensor is attached to ("sample" | "can") -# -# -# -# Defines the axes for logged vector quantities if they are not the global instrument axes. -# -# -# -# name for measured signal -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The type of hardware used for the measurement. -# Examples (suggestions but not restrictions): -# -# :Temperature: -# J | K | T | E | R | S | Pt100 | Rh/Fe -# :pH: -# Hg/Hg2Cl2 | Ag/AgCl | ISFET -# :Ion selective electrode: -# specify species; e.g. Ca2+ -# :Magnetic field: -# Hall -# :Surface pressure: -# wilhelmy plate -# -# -# -# -# Is data collection controlled or synchronised to this quantity: -# 1=no, 0=to "value", 1=to "value_deriv1", etc. -# -# -# -# -# Upper control bound of sensor reading if using run_control -# -# -# -# -# Lower control bound of sensor reading if using run_control -# -# -# -# -# nominal setpoint or average value -# - need [n] as may be a vector -# -# -# -# -# -# -# -# Nominal/average first derivative of value -# e.g. strain rate -# - same dimensions as "value" (may be a vector) -# -# -# -# -# -# -# -# Nominal/average second derivative of value -# - same dimensions as "value" (may be a vector) -# -# -# -# -# -# -# Time history of sensor readings -# -# -# Time history of first derivative of sensor readings -# -# -# Time history of second derivative of sensor readings -# -# -# -# -# -# -# -# -# -# -# -# -# For complex external fields not satisfied by External_field_brief -# -# -# -# This group describes the shape of the sensor when necessary. -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -======= # # # A sensor used to monitor an external condition @@ -468,23 +312,10 @@ NXsensor(NXobject): # to help define the path to the default dataset to be plotted. # See https://www.nexusformat.org/2014_How_to_find_default_data.html # for a summary of the discussion. ->>>>>>> mpes-refactor # # # # -<<<<<<< HEAD -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a sensor. -# -======= # 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 @@ -494,21 +325,10 @@ NXsensor(NXobject): # # .. todo:: # Add a definition for the reference point of a sensor. ->>>>>>> mpes-refactor # # # # -<<<<<<< HEAD -# 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 @@ -516,4 +336,3 @@ NXsensor(NXobject): # # # ->>>>>>> mpes-refactor diff --git a/base_classes/nyaml/NXsource.yaml b/base_classes/nyaml/NXsource.yaml index 49f773bc37..6e275f7535 100644 --- a/base_classes/nyaml/NXsource.yaml +++ b/base_classes/nyaml/NXsource.yaml @@ -203,11 +203,7 @@ NXsource(NXobject): other component groups. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -<<<<<<< HEAD -# 19f1ee4e446868766ab035145a5835ce38e26b04d8e8ee50bf641392cb5c3525 -======= # 248872a89ab8cb9c738d47d23b9cf7fa50bac04b2beb1428f677ec9ec23fc29b ->>>>>>> mpes-refactor # # # Refers to the same concept as /NXentry/NXinstrument/source_TYPE and may be linked. - + +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays +# +# +# +# Number of coefficients of the calibration function +# +# +# +# +# Number of features used to fit the calibration function +# +# +# +# +# Number of points of the calibrated and uncalibrated axes +# +# +# +# +# Subclass of NXprocess to describe post-processing calibrations. +# +# +# +# Indicates the name of the last operation applied in the NXprocess sequence. +# +# +# +# +# Has the calibration been applied? +# +# +# +# +# For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit +# to a set of features (peaks) at well defined energy positions to determine +# E(TOF). Here we can store the array of fit coefficients. +# +# +# +# +# +# +# +# For non-linear energy calibrations. Here we can store the formula of the +# fit function. +# +# Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. +# +# Use x0, x1, ..., xn for the variables. +# +# The formula should be numpy compliant. +# +# +# +# +# For linear calibration. Scaling parameter. +# +# +# +# +# For linear calibration. Offset parameter. +# +# +# +# +# A vector representing the axis after calibration, matching the data length +# +# +# +# +# +# +# +# Vector containing the data coordinates in the original uncalibrated axis +# +# +# +# +# +# +# +# A description of the procedures employed. +# +# +# +# +# File containing the input data for calibration. +# +# +# +# +# Mapping data for calibration. +# +# This can be used to map data points from uncalibrated +# to calibrated values, e.g., by multiplying each point by the +# corresponding point in the mapping data. +# +# +# diff --git a/contributed_definitions/nyaml/NXelectron_level.yaml b/contributed_definitions/nyaml/NXelectron_level.yaml index ef58f4c74c..0b5c8143d0 100644 --- a/contributed_definitions/nyaml/NXelectron_level.yaml +++ b/contributed_definitions/nyaml/NXelectron_level.yaml @@ -1,1465 +1,1465 @@ -category: base -doc: | - Electronic level probed in X-ray spectroscopy or resonance experiments. -type: group -NXelectron_level(NXobject): - element: - doc: | - Symbol of the chemical element. - - For each, the atomic number, common English name, and standard atomic weight are also given. - enumeration: - H: - doc: | - Z=1, name="hydrogen", standard_atomic_weight=1.0078 - He: - doc: | - Z=2, name="helium", standard_atomic_weight=4.0026 - Li: - doc: | - Z=3, name="lithium", standard_atomic_weight=6.94 - Be: - doc: | - Z=4, name="beryllium", standard_atomic_weight=9.0122 - B: - doc: | - Z=5, name="boron", standard_atomic_weight=10.81 - C: - doc: | - Z=6, name="carbon", standard_atomic_weight=12.011 - N: - doc: | - Z=7, name="nitrogen", standard_atomic_weight=14.007 - O: - doc: | - Z=8, name="oxygen", standard_atomic_weight=15.999 - F: - doc: | - Z=9, name="fluorine", standard_atomic_weight=18.9984 - Ne: - doc: | - Z=10, name="neon", standard_atomic_weight=20.1797 - Na: - doc: | - Z=11, name="sodium", standard_atomic_weight=22.9898 - Mg: - doc: | - Z=12, name="magnesium", standard_atomic_weight=24.305 - Al: - doc: | - Z=13, name="aluminum", standard_atomic_weight=26.9815 - Si: - doc: | - Z=14, name="silicon", standard_atomic_weight=28.085 - P: - doc: | - Z=15, name="phosphorus", standard_atomic_weight=30.9738 - S: - doc: | - Z=16, name="sulfur", standard_atomic_weight=32.06 - Cl: - doc: | - Z=17, name="chlorine", standard_atomic_weight=35.453 - Ar: - doc: | - Z=18, name="argon", standard_atomic_weight=39.948 - K: - doc: | - Z=19, name="potassium", standard_atomic_weight=39.0983 - Ca: - doc: | - Z=20, name="calcium", standard_atomic_weight=40.078 - Sc: - doc: | - Z=21, name="scandium", standard_atomic_weight=44.9559 - Ti: - doc: | - Z=22, name="titanium", standard_atomic_weight=47.867 - V: - doc: | - Z=23, name="vanadium", standard_atomic_weight=50.9415 - Cr: - doc: | - Z=24, name="chromium", standard_atomic_weight=51.996 - Mn: - doc: | - Z=25, name="manganese", standard_atomic_weight=54.938 - Fe: - doc: | - Z=26, name="iron", standard_atomic_weight=55.845 - Co: - doc: | - Z=27, name="cobalt", standard_atomic_weight=58.9332 - Ni: - doc: | - Z=28, name="nickel", standard_atomic_weight=58.6934 - Cu: - doc: | - Z=29, name="copper", standard_atomic_weight=63.546 - Zn: - doc: | - Z=30, name="zinc", standard_atomic_weight=65.38 - Ga: - doc: | - Z=31, name="gallium", standard_atomic_weight=69.72 - Ge: - doc: | - Z=32, name="germanium", standard_atomic_weight=72.63 - As: - doc: | - Z=33, name="arsenic", standard_atomic_weight=74.9216 - Se: - doc: | - Z=34, name="selenium", standard_atomic_weight=78.971 - Br: - doc: | - Z=35, name="bromine", standard_atomic_weight=79.904 - Kr: - doc: | - Z=36, name="krypton", standard_atomic_weight=83.798 - Rb: - doc: | - Z=37, name="rubidium", standard_atomic_weight=85.4678 - Sr: - doc: | - Z=38, name="strontium", standard_atomic_weight=87.62 - Y: - doc: | - Z=39, name="yttrium", standard_atomic_weight=88.9058 - Zr: - doc: | - Z=40, name="zirconium", standard_atomic_weight=91.224 - Nb: - doc: | - Z=41, name="niobium", standard_atomic_weight=92.9064 - Mo: - doc: | - Z=42, name="molybdenum", standard_atomic_weight=95.95 - Tc: - doc: | - Z=43, name="technetium", standard_atomic_weight=97.907 - Ru: - doc: | - Z=44, name="ruthenium", standard_atomic_weight=101.07 - Rh: - doc: | - Z=45, name="rhodium", standard_atomic_weight=102.906 - Pd: - doc: | - Z=46, name="palladium", standard_atomic_weight=106.42 - Ag: - doc: | - Z=47, name="silver", standard_atomic_weight=107.868 - Cd: - doc: | - Z=48, name="cadmium", standard_atomic_weight=112.414 - In: - doc: | - Z=49, name="indium", standard_atomic_weight=114.818 - Sn: - doc: | - Z=50, name="tin", standard_atomic_weight=118.71 - Sb: - doc: | - Z=51, name="antimony", standard_atomic_weight=121.76 - Te: - doc: | - Z=52, name="tellurium", standard_atomic_weight=127.6 - I: - doc: | - Z=53, name="iodine", standard_atomic_weight=126.905 - Xe: - doc: | - Z=54, name="xenon", standard_atomic_weight=131.293 - Cs: - doc: | - Z=55, name="cesium", standard_atomic_weight=132.905 - Ba: - doc: | - Z=56, name="barium", standard_atomic_weight=137.327 - La: - doc: | - Z=57, name="lanthanum", standard_atomic_weight=138.905 - Ce: - doc: | - Z=58, name="cerium", standard_atomic_weight=140.116 - Pr: - doc: | - Z=59, name="praseodymium", standard_atomic_weight=140.908 - Nd: - doc: | - Z=60, name="neodymium", standard_atomic_weight=144.242 - Pm: - doc: | - Z=61, name="promethium", standard_atomic_weight=145.0 - Sm: - doc: | - Z=62, name="samarium", standard_atomic_weight=150.36 - Eu: - doc: | - Z=63, name="europium", standard_atomic_weight=151.96 - Gd: - doc: | - Z=64, name="gadolinium", standard_atomic_weight=157.25 - Tb: - doc: | - Z=65, name="terbium", standard_atomic_weight=158.925 - Dy: - doc: | - Z=66, name="dysprosium", standard_atomic_weight=162.5 - Ho: - doc: | - Z=67, name="holmium", standard_atomic_weight=164.93 - Er: - doc: | - Z=68, name="erbium", standard_atomic_weight=167.259 - Tm: - doc: | - Z=69, name="thulium", standard_atomic_weight=168.934 - Yb: - doc: | - Z=70, name="ytterbium", standard_atomic_weight=173.045 - Lu: - doc: | - Z=71, name="lutetium", standard_atomic_weight=174.967 - Hf: - doc: | - Z=72, name="hafnium", standard_atomic_weight=178.49 - Ta: - doc: | - Z=73, name="tantalum", standard_atomic_weight=180.948 - W: - doc: | - Z=74, name="tungsten", standard_atomic_weight=183.84 - Re: - doc: | - Z=75, name="rhenium", standard_atomic_weight=186.207 - Os: - doc: | - Z=76, name="osmium", standard_atomic_weight=190.23 - Ir: - doc: | - Z=77, name="iridium", standard_atomic_weight=192.217 - Pt: - doc: | - Z=78, name="platinum", standard_atomic_weight=195.084 - Au: - doc: | - Z=79, name="gold", standard_atomic_weight=196.967 - Hg: - doc: | - Z=80, name="mercury", standard_atomic_weight=200.592 - Tl: - doc: | - Z=81, name="thallium", standard_atomic_weight=204.383 - Pb: - doc: | - Z=82, name="lead", standard_atomic_weight=207.2 - Bi: - doc: | - Z=83, name="bismuth", standard_atomic_weight=208.98 - Po: - doc: | - Z=84, name="polonium", standard_atomic_weight=209.0 - At: - doc: | - Z=85, name="astatine", standard_atomic_weight=210.0 - Rn: - doc: | - Z=86, name="radon", standard_atomic_weight=222.0 - Fr: - doc: | - Z=87, name="francium", standard_atomic_weight=223.0 - Ra: - doc: | - Z=88, name="radium", standard_atomic_weight=226.0 - Ac: - doc: | - Z=89, name="actinium", standard_atomic_weight=227.0 - Th: - doc: | - Z=90, name="thorium", standard_atomic_weight=232.038 - Pa: - doc: | - Z=91, name="protactinium", standard_atomic_weight=231.036 - U: - doc: | - Z=92, name="uranium", standard_atomic_weight=238.029 - Np: - doc: | - Z=93, name="neptunium", standard_atomic_weight=237.048 - Pu: - doc: | - Z=94, name="plutonium", standard_atomic_weight=239.052 - Am: - doc: | - Z=95, name="americium", standard_atomic_weight=243.0 - Cm: - doc: | - Z=96, name="curium", standard_atomic_weight=247.0 - Bk: - doc: | - Z=97, name="berkelium", standard_atomic_weight=247.0 - Cf: - doc: | - Z=98, name="californium", standard_atomic_weight=251.0 - Es: - doc: | - Z=99, name="einsteinium", standard_atomic_weight=252 - Fm: - doc: | - Z=100, name="fermium", standard_atomic_weight=257 - Md: - doc: | - Z=101, name="mendelevium", standard_atomic_weight=258 - 'No': - doc: | - Z=102, name="nobelium", standard_atomic_weight=259 - Lr: - doc: | - Z=103, name="lawrencium", standard_atomic_weight=266 - Rf: - doc: | - Z=104, name="rutherfordium", standard_atomic_weight=267 - Db: - doc: | - Z=105, name="dubnium", standard_atomic_weight=268 - Sg: - doc: | - Z=106, name="seaborgium", standard_atomic_weight=269 - Bh: - doc: | - Z=107, name="bohrium", standard_atomic_weight=270 - Hs: - doc: | - Z=108, name="hassium", standard_atomic_weight=269 - Mt: - doc: | - Z=109, name="meitnerium", standard_atomic_weight=278 - Ds: - doc: | - Z=110, name="darmstadtium", standard_atomic_weight=281 - Rg: - doc: | - Z=111, name="roentgenium", standard_atomic_weight=282 - Cn: - doc: | - Z=112, name="copernicium", standard_atomic_weight=285 - Nh: - doc: | - Z=113, name="nihonium", standard_atomic_weight=286 - Fl: - doc: | - Z=114, name="flerovium", standard_atomic_weight=289 - Mc: - doc: | - Z=115, name="moscovium", standard_atomic_weight=290 - Lv: - doc: | - Z=116, name="livermorium", standard_atomic_weight=293 - Ts: - doc: | - Z=117, name="tennessine", standard_atomic_weight=294 - Og: - doc: | - Z=118, name="oganesson", standard_atomic_weight=294 - level_iupac: - doc: | - IUPAC symbol of the electronic level. - For each level, the electronic orbital configuration is also given - - For reference, see Jenkins, R., Manne, R., Robin, R., & Senemaud, C. (1991). - IUPAC—nomenclature system for x-ray spectroscopy. X-Ray Spectrometry, 20(3), 149-155. - enumeration: - K: - doc: | - same as 1s in level_xray - L1: - doc: | - 2s - L2: - doc: | - 2p_{1/2} - L3: - doc: | - 2p_{3/2} - M1: - doc: | - 3s - M2: - doc: | - 3p_{1/2} - M3: - doc: | - 3p_{3/2} - M4: - doc: | - 3d_{3/2} - M5: - doc: | - 3d_{5/2} - N1: - doc: | - 4s - N2: - doc: | - 4p_{1/2} - N3: - doc: | - 4p_{3/2} - N4: - doc: | - 4d_{3/2} - N5: - doc: | - 4d_{5/2} - N6: - doc: | - 4f_{5/2} - N7: - doc: | - 4f_{7/2} - O1: - doc: | - 5s - O2: - doc: | - 5p_{1/2} - O3: - doc: | - 5p_{3/2} - O4: - doc: | - 5d_{3/2} - O5: - doc: | - 5d_{5/2} - O6: - doc: | - 5f_{5/2} - O7: - doc: | - 5f_{7/2} - P1: - doc: | - 6s - P2: - doc: | - 6p_{1/2} - P3: - doc: | - 6p_{3/2} - level_electron_config: - doc: | - Electronic orbital configuration of the electronic level. - enumeration: - 1s: - doc: | - same as K in level_xray - 2s: - doc: | - L1 - 2p1/2: - doc: | - L3 - 3s: - doc: | - M1 - 3p1/2: - doc: | - M2 - 3p3/2: - doc: | - M3 - 3d3/2: - doc: | - M4 - 3d5/2: - doc: | - M5 - 4s: - doc: | - N1 - 4p1/2: - doc: | - N2 - 4p3/2: - doc: | - N3 - 4d3/2: - doc: | - N4 - 4d5/2: - doc: | - N5 - 4f5/2: - doc: | - N6 - 4f7/2: - doc: | - N7 - 5s: - doc: | - O1 - 5p1/2: - doc: | - O2 - 5p3/2: - doc: | - O3 - 5d3/2: - doc: | - O4 - 5d5/2: - doc: | - O5 - 5f5/2: - doc: | - O6 - 5f7/2: - doc: | - O7 - 6s: - doc: | - P1 - 6p1/2: - doc: | - P2 - 6p3/2: - doc: | - P3 - \@description: - doc: | - description of X-ray electronic level - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8919676091ceb7a94610690c2099e84bf653e60cc5bc669c9d1e562151e1f904 -# -# -# -# -# -# Electronic level probed in X-ray spectroscopy or resonance experiments. -# -# -# -# Symbol of the absorbing or resonant element. -# -# For each, the atomic number, common English name, and standard atomic weight are also given. -# -# -# -# -# Z=1, name="hydrogen", standard_atomic_weight=1.0078 -# -# -# -# -# Z=2, name="helium", standard_atomic_weight=4.0026 -# -# -# -# -# Z=3, name="lithium", standard_atomic_weight=6.94 -# -# -# -# -# Z=4, name="beryllium", standard_atomic_weight=9.0122 -# -# -# -# -# Z=5, name="boron", standard_atomic_weight=10.81 -# -# -# -# -# Z=6, name="carbon", standard_atomic_weight=12.011 -# -# -# -# -# Z=7, name="nitrogen", standard_atomic_weight=14.007 -# -# -# -# -# Z=8, name="oxygen", standard_atomic_weight=15.999 -# -# -# -# -# Z=9, name="fluorine", standard_atomic_weight=18.9984 -# -# -# -# -# Z=10, name="neon", standard_atomic_weight=20.1797 -# -# -# -# -# Z=11, name="sodium", standard_atomic_weight=22.9898 -# -# -# -# -# Z=12, name="magnesium", standard_atomic_weight=24.305 -# -# -# -# -# Z=13, name="aluminum", standard_atomic_weight=26.9815 -# -# -# -# -# Z=14, name="silicon", standard_atomic_weight=28.085 -# -# -# -# -# Z=15, name="phosphorus", standard_atomic_weight=30.9738 -# -# -# -# -# Z=16, name="sulfur", standard_atomic_weight=32.06 -# -# -# -# -# Z=17, name="chlorine", standard_atomic_weight=35.453 -# -# -# -# -# Z=18, name="argon", standard_atomic_weight=39.948 -# -# -# -# -# Z=19, name="potassium", standard_atomic_weight=39.0983 -# -# -# -# -# Z=20, name="calcium", standard_atomic_weight=40.078 -# -# -# -# -# Z=21, name="scandium", standard_atomic_weight=44.9559 -# -# -# -# -# Z=22, name="titanium", standard_atomic_weight=47.867 -# -# -# -# -# Z=23, name="vanadium", standard_atomic_weight=50.9415 -# -# -# -# -# Z=24, name="chromium", standard_atomic_weight=51.996 -# -# -# -# -# Z=25, name="manganese", standard_atomic_weight=54.938 -# -# -# -# -# Z=26, name="iron", standard_atomic_weight=55.845 -# -# -# -# -# Z=27, name="cobalt", standard_atomic_weight=58.9332 -# -# -# -# -# Z=28, name="nickel", standard_atomic_weight=58.6934 -# -# -# -# -# Z=29, name="copper", standard_atomic_weight=63.546 -# -# -# -# -# Z=30, name="zinc", standard_atomic_weight=65.38 -# -# -# -# -# Z=31, name="gallium", standard_atomic_weight=69.72 -# -# -# -# -# Z=32, name="germanium", standard_atomic_weight=72.63 -# -# -# -# -# Z=33, name="arsenic", standard_atomic_weight=74.9216 -# -# -# -# -# Z=34, name="selenium", standard_atomic_weight=78.971 -# -# -# -# -# Z=35, name="bromine", standard_atomic_weight=79.904 -# -# -# -# -# Z=36, name="krypton", standard_atomic_weight=83.798 -# -# -# -# -# Z=37, name="rubidium", standard_atomic_weight=85.4678 -# -# -# -# -# Z=38, name="strontium", standard_atomic_weight=87.62 -# -# -# -# -# Z=39, name="yttrium", standard_atomic_weight=88.9058 -# -# -# -# -# Z=40, name="zirconium", standard_atomic_weight=91.224 -# -# -# -# -# Z=41, name="niobium", standard_atomic_weight=92.9064 -# -# -# -# -# Z=42, name="molybdenum", standard_atomic_weight=95.95 -# -# -# -# -# Z=43, name="technetium", standard_atomic_weight=97.907 -# -# -# -# -# Z=44, name="ruthenium", standard_atomic_weight=101.07 -# -# -# -# -# Z=45, name="rhodium", standard_atomic_weight=102.906 -# -# -# -# -# Z=46, name="palladium", standard_atomic_weight=106.42 -# -# -# -# -# Z=47, name="silver", standard_atomic_weight=107.868 -# -# -# -# -# Z=48, name="cadmium", standard_atomic_weight=112.414 -# -# -# -# -# Z=49, name="indium", standard_atomic_weight=114.818 -# -# -# -# -# Z=50, name="tin", standard_atomic_weight=118.71 -# -# -# -# -# Z=51, name="antimony", standard_atomic_weight=121.76 -# -# -# -# -# Z=52, name="tellurium", standard_atomic_weight=127.6 -# -# -# -# -# Z=53, name="iodine", standard_atomic_weight=126.905 -# -# -# -# -# Z=54, name="xenon", standard_atomic_weight=131.293 -# -# -# -# -# Z=55, name="cesium", standard_atomic_weight=132.905 -# -# -# -# -# Z=56, name="barium", standard_atomic_weight=137.327 -# -# -# -# -# Z=57, name="lanthanum", standard_atomic_weight=138.905 -# -# -# -# -# Z=58, name="cerium", standard_atomic_weight=140.116 -# -# -# -# -# Z=59, name="praseodymium", standard_atomic_weight=140.908 -# -# -# -# -# Z=60, name="neodymium", standard_atomic_weight=144.242 -# -# -# -# -# Z=61, name="promethium", standard_atomic_weight=145.0 -# -# -# -# -# Z=62, name="samarium", standard_atomic_weight=150.36 -# -# -# -# -# Z=63, name="europium", standard_atomic_weight=151.96 -# -# -# -# -# Z=64, name="gadolinium", standard_atomic_weight=157.25 -# -# -# -# -# Z=65, name="terbium", standard_atomic_weight=158.925 -# -# -# -# -# Z=66, name="dysprosium", standard_atomic_weight=162.5 -# -# -# -# -# Z=67, name="holmium", standard_atomic_weight=164.93 -# -# -# -# -# Z=68, name="erbium", standard_atomic_weight=167.259 -# -# -# -# -# Z=69, name="thulium", standard_atomic_weight=168.934 -# -# -# -# -# Z=70, name="ytterbium", standard_atomic_weight=173.045 -# -# -# -# -# Z=71, name="lutetium", standard_atomic_weight=174.967 -# -# -# -# -# Z=72, name="hafnium", standard_atomic_weight=178.49 -# -# -# -# -# Z=73, name="tantalum", standard_atomic_weight=180.948 -# -# -# -# -# Z=74, name="tungsten", standard_atomic_weight=183.84 -# -# -# -# -# Z=75, name="rhenium", standard_atomic_weight=186.207 -# -# -# -# -# Z=76, name="osmium", standard_atomic_weight=190.23 -# -# -# -# -# Z=77, name="iridium", standard_atomic_weight=192.217 -# -# -# -# -# Z=78, name="platinum", standard_atomic_weight=195.084 -# -# -# -# -# Z=79, name="gold", standard_atomic_weight=196.967 -# -# -# -# -# Z=80, name="mercury", standard_atomic_weight=200.592 -# -# -# -# -# Z=81, name="thallium", standard_atomic_weight=204.383 -# -# -# -# -# Z=82, name="lead", standard_atomic_weight=207.2 -# -# -# -# -# Z=83, name="bismuth", standard_atomic_weight=208.98 -# -# -# -# -# Z=84, name="polonium", standard_atomic_weight=209.0 -# -# -# -# -# Z=85, name="astatine", standard_atomic_weight=210.0 -# -# -# -# -# Z=86, name="radon", standard_atomic_weight=222.0 -# -# -# -# -# Z=87, name="francium", standard_atomic_weight=223.0 -# -# -# -# -# Z=88, name="radium", standard_atomic_weight=226.0 -# -# -# -# -# Z=89, name="actinium", standard_atomic_weight=227.0 -# -# -# -# -# Z=90, name="thorium", standard_atomic_weight=232.038 -# -# -# -# -# Z=91, name="protactinium", standard_atomic_weight=231.036 -# -# -# -# -# Z=92, name="uranium", standard_atomic_weight=238.029 -# -# -# -# -# Z=93, name="neptunium", standard_atomic_weight=237.048 -# -# -# -# -# Z=94, name="plutonium", standard_atomic_weight=239.052 -# -# -# -# -# Z=95, name="americium", standard_atomic_weight=243.0 -# -# -# -# -# Z=96, name="curium", standard_atomic_weight=247.0 -# -# -# -# -# Z=97, name="berkelium", standard_atomic_weight=247.0 -# -# -# -# -# Z=98, name="californium", standard_atomic_weight=251.0 -# -# -# -# -# Z=99, name="einsteinium", standard_atomic_weight=252 -# -# -# -# -# Z=100, name="fermium", standard_atomic_weight=257 -# -# -# -# -# Z=101, name="mendelevium", standard_atomic_weight=258 -# -# -# -# -# Z=102, name="nobelium", standard_atomic_weight=259 -# -# -# -# -# Z=103, name="lawrencium", standard_atomic_weight=266 -# -# -# -# -# Z=104, name="rutherfordium", standard_atomic_weight=267 -# -# -# -# -# Z=105, name="dubnium", standard_atomic_weight=268 -# -# -# -# -# Z=106, name="seaborgium", standard_atomic_weight=269 -# -# -# -# -# Z=107, name="bohrium", standard_atomic_weight=270 -# -# -# -# -# Z=108, name="hassium", standard_atomic_weight=269 -# -# -# -# -# Z=109, name="meitnerium", standard_atomic_weight=278 -# -# -# -# -# Z=110, name="darmstadtium", standard_atomic_weight=281 -# -# -# -# -# Z=111, name="roentgenium", standard_atomic_weight=282 -# -# -# -# -# Z=112, name="copernicium", standard_atomic_weight=285 -# -# -# -# -# Z=113, name="nihonium", standard_atomic_weight=286 -# -# -# -# -# Z=114, name="flerovium", standard_atomic_weight=289 -# -# -# -# -# Z=115, name="moscovium", standard_atomic_weight=290 -# -# -# -# -# Z=116, name="livermorium", standard_atomic_weight=293 -# -# -# -# -# Z=117, name="tennessine", standard_atomic_weight=294 -# -# -# -# -# Z=118, name="oganesson", standard_atomic_weight=294 -# -# -# -# -# -# -# IUPAC symbol of the electronic level. -# For each level, the electronic orbital configuration is also given -# -# For reference, see Jenkins, R., Manne, R., Robin, R., & Senemaud, C. (1991). -# IUPAC—nomenclature system for x-ray spectroscopy. X-Ray Spectrometry, 20(3), 149-155. -# -# -# -# -# same as 1s in level_xray -# -# -# -# -# 2s -# -# -# -# -# 2p_{1/2} -# -# -# -# -# 2p_{3/2} -# -# -# -# -# 3s -# -# -# -# -# 3p_{1/2} -# -# -# -# -# 3p_{3/2} -# -# -# -# -# 3d_{3/2} -# -# -# -# -# 3d_{5/2} -# -# -# -# -# 4s -# -# -# -# -# 4p_{1/2} -# -# -# -# -# 4p_{3/2} -# -# -# -# -# 4d_{3/2} -# -# -# -# -# 4d_{5/2} -# -# -# -# -# 4f_{5/2} -# -# -# -# -# 4f_{7/2} -# -# -# -# -# 5s -# -# -# -# -# 5p_{1/2} -# -# -# -# -# 5p_{3/2} -# -# -# -# -# 5d_{3/2} -# -# -# -# -# 5d_{5/2} -# -# -# -# -# 5f_{5/2} -# -# -# -# -# 5f_{7/2} -# -# -# -# -# 6s -# -# -# -# -# 6p_{1/2} -# -# -# -# -# 6p_{3/2} -# -# -# -# -# -# -# Electronic orbital configuration of the electronic level. -# -# -# -# -# same as K in level_xray -# -# -# -# -# L1 -# -# -# -# -# L3 -# -# -# -# -# M1 -# -# -# -# -# M2 -# -# -# -# -# M3 -# -# -# -# -# M4 -# -# -# -# -# M5 -# -# -# -# -# N1 -# -# -# -# -# N2 -# -# -# -# -# N3 -# -# -# -# -# N4 -# -# -# -# -# N5 -# -# -# -# -# N6 -# -# -# -# -# N7 -# -# -# -# -# O1 -# -# -# -# -# O2 -# -# -# -# -# O3 -# -# -# -# -# O4 -# -# -# -# -# O5 -# -# -# -# -# O6 -# -# -# -# -# O7 -# -# -# -# -# P1 -# -# -# -# -# P2 -# -# -# -# -# P3 -# -# -# -# -# -# -# description of X-ray electronic level -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# +category: base +doc: | + Electronic level probed in X-ray spectroscopy or resonance experiments. +type: group +NXelectron_level(NXobject): + element: + doc: | + Symbol of the chemical element. + + For each, the atomic number, common English name, and standard atomic weight are also given. + enumeration: + H: + doc: | + Z=1, name="hydrogen", standard_atomic_weight=1.0078 + He: + doc: | + Z=2, name="helium", standard_atomic_weight=4.0026 + Li: + doc: | + Z=3, name="lithium", standard_atomic_weight=6.94 + Be: + doc: | + Z=4, name="beryllium", standard_atomic_weight=9.0122 + B: + doc: | + Z=5, name="boron", standard_atomic_weight=10.81 + C: + doc: | + Z=6, name="carbon", standard_atomic_weight=12.011 + N: + doc: | + Z=7, name="nitrogen", standard_atomic_weight=14.007 + O: + doc: | + Z=8, name="oxygen", standard_atomic_weight=15.999 + F: + doc: | + Z=9, name="fluorine", standard_atomic_weight=18.9984 + Ne: + doc: | + Z=10, name="neon", standard_atomic_weight=20.1797 + Na: + doc: | + Z=11, name="sodium", standard_atomic_weight=22.9898 + Mg: + doc: | + Z=12, name="magnesium", standard_atomic_weight=24.305 + Al: + doc: | + Z=13, name="aluminum", standard_atomic_weight=26.9815 + Si: + doc: | + Z=14, name="silicon", standard_atomic_weight=28.085 + P: + doc: | + Z=15, name="phosphorus", standard_atomic_weight=30.9738 + S: + doc: | + Z=16, name="sulfur", standard_atomic_weight=32.06 + Cl: + doc: | + Z=17, name="chlorine", standard_atomic_weight=35.453 + Ar: + doc: | + Z=18, name="argon", standard_atomic_weight=39.948 + K: + doc: | + Z=19, name="potassium", standard_atomic_weight=39.0983 + Ca: + doc: | + Z=20, name="calcium", standard_atomic_weight=40.078 + Sc: + doc: | + Z=21, name="scandium", standard_atomic_weight=44.9559 + Ti: + doc: | + Z=22, name="titanium", standard_atomic_weight=47.867 + V: + doc: | + Z=23, name="vanadium", standard_atomic_weight=50.9415 + Cr: + doc: | + Z=24, name="chromium", standard_atomic_weight=51.996 + Mn: + doc: | + Z=25, name="manganese", standard_atomic_weight=54.938 + Fe: + doc: | + Z=26, name="iron", standard_atomic_weight=55.845 + Co: + doc: | + Z=27, name="cobalt", standard_atomic_weight=58.9332 + Ni: + doc: | + Z=28, name="nickel", standard_atomic_weight=58.6934 + Cu: + doc: | + Z=29, name="copper", standard_atomic_weight=63.546 + Zn: + doc: | + Z=30, name="zinc", standard_atomic_weight=65.38 + Ga: + doc: | + Z=31, name="gallium", standard_atomic_weight=69.72 + Ge: + doc: | + Z=32, name="germanium", standard_atomic_weight=72.63 + As: + doc: | + Z=33, name="arsenic", standard_atomic_weight=74.9216 + Se: + doc: | + Z=34, name="selenium", standard_atomic_weight=78.971 + Br: + doc: | + Z=35, name="bromine", standard_atomic_weight=79.904 + Kr: + doc: | + Z=36, name="krypton", standard_atomic_weight=83.798 + Rb: + doc: | + Z=37, name="rubidium", standard_atomic_weight=85.4678 + Sr: + doc: | + Z=38, name="strontium", standard_atomic_weight=87.62 + Y: + doc: | + Z=39, name="yttrium", standard_atomic_weight=88.9058 + Zr: + doc: | + Z=40, name="zirconium", standard_atomic_weight=91.224 + Nb: + doc: | + Z=41, name="niobium", standard_atomic_weight=92.9064 + Mo: + doc: | + Z=42, name="molybdenum", standard_atomic_weight=95.95 + Tc: + doc: | + Z=43, name="technetium", standard_atomic_weight=97.907 + Ru: + doc: | + Z=44, name="ruthenium", standard_atomic_weight=101.07 + Rh: + doc: | + Z=45, name="rhodium", standard_atomic_weight=102.906 + Pd: + doc: | + Z=46, name="palladium", standard_atomic_weight=106.42 + Ag: + doc: | + Z=47, name="silver", standard_atomic_weight=107.868 + Cd: + doc: | + Z=48, name="cadmium", standard_atomic_weight=112.414 + In: + doc: | + Z=49, name="indium", standard_atomic_weight=114.818 + Sn: + doc: | + Z=50, name="tin", standard_atomic_weight=118.71 + Sb: + doc: | + Z=51, name="antimony", standard_atomic_weight=121.76 + Te: + doc: | + Z=52, name="tellurium", standard_atomic_weight=127.6 + I: + doc: | + Z=53, name="iodine", standard_atomic_weight=126.905 + Xe: + doc: | + Z=54, name="xenon", standard_atomic_weight=131.293 + Cs: + doc: | + Z=55, name="cesium", standard_atomic_weight=132.905 + Ba: + doc: | + Z=56, name="barium", standard_atomic_weight=137.327 + La: + doc: | + Z=57, name="lanthanum", standard_atomic_weight=138.905 + Ce: + doc: | + Z=58, name="cerium", standard_atomic_weight=140.116 + Pr: + doc: | + Z=59, name="praseodymium", standard_atomic_weight=140.908 + Nd: + doc: | + Z=60, name="neodymium", standard_atomic_weight=144.242 + Pm: + doc: | + Z=61, name="promethium", standard_atomic_weight=145.0 + Sm: + doc: | + Z=62, name="samarium", standard_atomic_weight=150.36 + Eu: + doc: | + Z=63, name="europium", standard_atomic_weight=151.96 + Gd: + doc: | + Z=64, name="gadolinium", standard_atomic_weight=157.25 + Tb: + doc: | + Z=65, name="terbium", standard_atomic_weight=158.925 + Dy: + doc: | + Z=66, name="dysprosium", standard_atomic_weight=162.5 + Ho: + doc: | + Z=67, name="holmium", standard_atomic_weight=164.93 + Er: + doc: | + Z=68, name="erbium", standard_atomic_weight=167.259 + Tm: + doc: | + Z=69, name="thulium", standard_atomic_weight=168.934 + Yb: + doc: | + Z=70, name="ytterbium", standard_atomic_weight=173.045 + Lu: + doc: | + Z=71, name="lutetium", standard_atomic_weight=174.967 + Hf: + doc: | + Z=72, name="hafnium", standard_atomic_weight=178.49 + Ta: + doc: | + Z=73, name="tantalum", standard_atomic_weight=180.948 + W: + doc: | + Z=74, name="tungsten", standard_atomic_weight=183.84 + Re: + doc: | + Z=75, name="rhenium", standard_atomic_weight=186.207 + Os: + doc: | + Z=76, name="osmium", standard_atomic_weight=190.23 + Ir: + doc: | + Z=77, name="iridium", standard_atomic_weight=192.217 + Pt: + doc: | + Z=78, name="platinum", standard_atomic_weight=195.084 + Au: + doc: | + Z=79, name="gold", standard_atomic_weight=196.967 + Hg: + doc: | + Z=80, name="mercury", standard_atomic_weight=200.592 + Tl: + doc: | + Z=81, name="thallium", standard_atomic_weight=204.383 + Pb: + doc: | + Z=82, name="lead", standard_atomic_weight=207.2 + Bi: + doc: | + Z=83, name="bismuth", standard_atomic_weight=208.98 + Po: + doc: | + Z=84, name="polonium", standard_atomic_weight=209.0 + At: + doc: | + Z=85, name="astatine", standard_atomic_weight=210.0 + Rn: + doc: | + Z=86, name="radon", standard_atomic_weight=222.0 + Fr: + doc: | + Z=87, name="francium", standard_atomic_weight=223.0 + Ra: + doc: | + Z=88, name="radium", standard_atomic_weight=226.0 + Ac: + doc: | + Z=89, name="actinium", standard_atomic_weight=227.0 + Th: + doc: | + Z=90, name="thorium", standard_atomic_weight=232.038 + Pa: + doc: | + Z=91, name="protactinium", standard_atomic_weight=231.036 + U: + doc: | + Z=92, name="uranium", standard_atomic_weight=238.029 + Np: + doc: | + Z=93, name="neptunium", standard_atomic_weight=237.048 + Pu: + doc: | + Z=94, name="plutonium", standard_atomic_weight=239.052 + Am: + doc: | + Z=95, name="americium", standard_atomic_weight=243.0 + Cm: + doc: | + Z=96, name="curium", standard_atomic_weight=247.0 + Bk: + doc: | + Z=97, name="berkelium", standard_atomic_weight=247.0 + Cf: + doc: | + Z=98, name="californium", standard_atomic_weight=251.0 + Es: + doc: | + Z=99, name="einsteinium", standard_atomic_weight=252 + Fm: + doc: | + Z=100, name="fermium", standard_atomic_weight=257 + Md: + doc: | + Z=101, name="mendelevium", standard_atomic_weight=258 + No: + doc: | + Z=102, name="nobelium", standard_atomic_weight=259 + Lr: + doc: | + Z=103, name="lawrencium", standard_atomic_weight=266 + Rf: + doc: | + Z=104, name="rutherfordium", standard_atomic_weight=267 + Db: + doc: | + Z=105, name="dubnium", standard_atomic_weight=268 + Sg: + doc: | + Z=106, name="seaborgium", standard_atomic_weight=269 + Bh: + doc: | + Z=107, name="bohrium", standard_atomic_weight=270 + Hs: + doc: | + Z=108, name="hassium", standard_atomic_weight=269 + Mt: + doc: | + Z=109, name="meitnerium", standard_atomic_weight=278 + Ds: + doc: | + Z=110, name="darmstadtium", standard_atomic_weight=281 + Rg: + doc: | + Z=111, name="roentgenium", standard_atomic_weight=282 + Cn: + doc: | + Z=112, name="copernicium", standard_atomic_weight=285 + Nh: + doc: | + Z=113, name="nihonium", standard_atomic_weight=286 + Fl: + doc: | + Z=114, name="flerovium", standard_atomic_weight=289 + Mc: + doc: | + Z=115, name="moscovium", standard_atomic_weight=290 + Lv: + doc: | + Z=116, name="livermorium", standard_atomic_weight=293 + Ts: + doc: | + Z=117, name="tennessine", standard_atomic_weight=294 + Og: + doc: | + Z=118, name="oganesson", standard_atomic_weight=294 + level_iupac: + doc: | + IUPAC symbol of the electronic level. + For each level, the electronic orbital configuration is also given + + For reference, see Jenkins, R., Manne, R., Robin, R., & Senemaud, C. (1991). + IUPAC—nomenclature system for x-ray spectroscopy. X-Ray Spectrometry, 20(3), 149-155. + enumeration: + K: + doc: | + same as 1s in level_xray + L1: + doc: | + 2s + L2: + doc: | + 2p_{1/2} + L3: + doc: | + 2p_{3/2} + M1: + doc: | + 3s + M2: + doc: | + 3p_{1/2} + M3: + doc: | + 3p_{3/2} + M4: + doc: | + 3d_{3/2} + M5: + doc: | + 3d_{5/2} + N1: + doc: | + 4s + N2: + doc: | + 4p_{1/2} + N3: + doc: | + 4p_{3/2} + N4: + doc: | + 4d_{3/2} + N5: + doc: | + 4d_{5/2} + N6: + doc: | + 4f_{5/2} + N7: + doc: | + 4f_{7/2} + O1: + doc: | + 5s + O2: + doc: | + 5p_{1/2} + O3: + doc: | + 5p_{3/2} + O4: + doc: | + 5d_{3/2} + O5: + doc: | + 5d_{5/2} + O6: + doc: | + 5f_{5/2} + O7: + doc: | + 5f_{7/2} + P1: + doc: | + 6s + P2: + doc: | + 6p_{1/2} + P3: + doc: | + 6p_{3/2} + level_electron_config: + doc: | + Electronic orbital configuration of the electronic level. + enumeration: + 1s: + doc: | + same as K in level_xray + 2s: + doc: | + L1 + 2p1/2: + doc: | + L3 + 3s: + doc: | + M1 + 3p1/2: + doc: | + M2 + 3p3/2: + doc: | + M3 + 3d3/2: + doc: | + M4 + 3d5/2: + doc: | + M5 + 4s: + doc: | + N1 + 4p1/2: + doc: | + N2 + 4p3/2: + doc: | + N3 + 4d3/2: + doc: | + N4 + 4d5/2: + doc: | + N5 + 4f5/2: + doc: | + N6 + 4f7/2: + doc: | + N7 + 5s: + doc: | + O1 + 5p1/2: + doc: | + O2 + 5p3/2: + doc: | + O3 + 5d3/2: + doc: | + O4 + 5d5/2: + doc: | + O5 + 5f5/2: + doc: | + O6 + 5f7/2: + doc: | + O7 + 6s: + doc: | + P1 + 6p1/2: + doc: | + P2 + 6p3/2: + doc: | + P3 + \@description: + doc: | + description of X-ray electronic level + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# f15a465a52ff8afca9ae40f5a19eaaa00cf0defe098ab7a0b76a3692acd4bc29 +# +# +# +# +# +# Electronic level probed in X-ray spectroscopy or resonance experiments. +# +# +# +# Symbol of the chemical element. +# +# For each, the atomic number, common English name, and standard atomic weight are also given. +# +# +# +# +# Z=1, name="hydrogen", standard_atomic_weight=1.0078 +# +# +# +# +# Z=2, name="helium", standard_atomic_weight=4.0026 +# +# +# +# +# Z=3, name="lithium", standard_atomic_weight=6.94 +# +# +# +# +# Z=4, name="beryllium", standard_atomic_weight=9.0122 +# +# +# +# +# Z=5, name="boron", standard_atomic_weight=10.81 +# +# +# +# +# Z=6, name="carbon", standard_atomic_weight=12.011 +# +# +# +# +# Z=7, name="nitrogen", standard_atomic_weight=14.007 +# +# +# +# +# Z=8, name="oxygen", standard_atomic_weight=15.999 +# +# +# +# +# Z=9, name="fluorine", standard_atomic_weight=18.9984 +# +# +# +# +# Z=10, name="neon", standard_atomic_weight=20.1797 +# +# +# +# +# Z=11, name="sodium", standard_atomic_weight=22.9898 +# +# +# +# +# Z=12, name="magnesium", standard_atomic_weight=24.305 +# +# +# +# +# Z=13, name="aluminum", standard_atomic_weight=26.9815 +# +# +# +# +# Z=14, name="silicon", standard_atomic_weight=28.085 +# +# +# +# +# Z=15, name="phosphorus", standard_atomic_weight=30.9738 +# +# +# +# +# Z=16, name="sulfur", standard_atomic_weight=32.06 +# +# +# +# +# Z=17, name="chlorine", standard_atomic_weight=35.453 +# +# +# +# +# Z=18, name="argon", standard_atomic_weight=39.948 +# +# +# +# +# Z=19, name="potassium", standard_atomic_weight=39.0983 +# +# +# +# +# Z=20, name="calcium", standard_atomic_weight=40.078 +# +# +# +# +# Z=21, name="scandium", standard_atomic_weight=44.9559 +# +# +# +# +# Z=22, name="titanium", standard_atomic_weight=47.867 +# +# +# +# +# Z=23, name="vanadium", standard_atomic_weight=50.9415 +# +# +# +# +# Z=24, name="chromium", standard_atomic_weight=51.996 +# +# +# +# +# Z=25, name="manganese", standard_atomic_weight=54.938 +# +# +# +# +# Z=26, name="iron", standard_atomic_weight=55.845 +# +# +# +# +# Z=27, name="cobalt", standard_atomic_weight=58.9332 +# +# +# +# +# Z=28, name="nickel", standard_atomic_weight=58.6934 +# +# +# +# +# Z=29, name="copper", standard_atomic_weight=63.546 +# +# +# +# +# Z=30, name="zinc", standard_atomic_weight=65.38 +# +# +# +# +# Z=31, name="gallium", standard_atomic_weight=69.72 +# +# +# +# +# Z=32, name="germanium", standard_atomic_weight=72.63 +# +# +# +# +# Z=33, name="arsenic", standard_atomic_weight=74.9216 +# +# +# +# +# Z=34, name="selenium", standard_atomic_weight=78.971 +# +# +# +# +# Z=35, name="bromine", standard_atomic_weight=79.904 +# +# +# +# +# Z=36, name="krypton", standard_atomic_weight=83.798 +# +# +# +# +# Z=37, name="rubidium", standard_atomic_weight=85.4678 +# +# +# +# +# Z=38, name="strontium", standard_atomic_weight=87.62 +# +# +# +# +# Z=39, name="yttrium", standard_atomic_weight=88.9058 +# +# +# +# +# Z=40, name="zirconium", standard_atomic_weight=91.224 +# +# +# +# +# Z=41, name="niobium", standard_atomic_weight=92.9064 +# +# +# +# +# Z=42, name="molybdenum", standard_atomic_weight=95.95 +# +# +# +# +# Z=43, name="technetium", standard_atomic_weight=97.907 +# +# +# +# +# Z=44, name="ruthenium", standard_atomic_weight=101.07 +# +# +# +# +# Z=45, name="rhodium", standard_atomic_weight=102.906 +# +# +# +# +# Z=46, name="palladium", standard_atomic_weight=106.42 +# +# +# +# +# Z=47, name="silver", standard_atomic_weight=107.868 +# +# +# +# +# Z=48, name="cadmium", standard_atomic_weight=112.414 +# +# +# +# +# Z=49, name="indium", standard_atomic_weight=114.818 +# +# +# +# +# Z=50, name="tin", standard_atomic_weight=118.71 +# +# +# +# +# Z=51, name="antimony", standard_atomic_weight=121.76 +# +# +# +# +# Z=52, name="tellurium", standard_atomic_weight=127.6 +# +# +# +# +# Z=53, name="iodine", standard_atomic_weight=126.905 +# +# +# +# +# Z=54, name="xenon", standard_atomic_weight=131.293 +# +# +# +# +# Z=55, name="cesium", standard_atomic_weight=132.905 +# +# +# +# +# Z=56, name="barium", standard_atomic_weight=137.327 +# +# +# +# +# Z=57, name="lanthanum", standard_atomic_weight=138.905 +# +# +# +# +# Z=58, name="cerium", standard_atomic_weight=140.116 +# +# +# +# +# Z=59, name="praseodymium", standard_atomic_weight=140.908 +# +# +# +# +# Z=60, name="neodymium", standard_atomic_weight=144.242 +# +# +# +# +# Z=61, name="promethium", standard_atomic_weight=145.0 +# +# +# +# +# Z=62, name="samarium", standard_atomic_weight=150.36 +# +# +# +# +# Z=63, name="europium", standard_atomic_weight=151.96 +# +# +# +# +# Z=64, name="gadolinium", standard_atomic_weight=157.25 +# +# +# +# +# Z=65, name="terbium", standard_atomic_weight=158.925 +# +# +# +# +# Z=66, name="dysprosium", standard_atomic_weight=162.5 +# +# +# +# +# Z=67, name="holmium", standard_atomic_weight=164.93 +# +# +# +# +# Z=68, name="erbium", standard_atomic_weight=167.259 +# +# +# +# +# Z=69, name="thulium", standard_atomic_weight=168.934 +# +# +# +# +# Z=70, name="ytterbium", standard_atomic_weight=173.045 +# +# +# +# +# Z=71, name="lutetium", standard_atomic_weight=174.967 +# +# +# +# +# Z=72, name="hafnium", standard_atomic_weight=178.49 +# +# +# +# +# Z=73, name="tantalum", standard_atomic_weight=180.948 +# +# +# +# +# Z=74, name="tungsten", standard_atomic_weight=183.84 +# +# +# +# +# Z=75, name="rhenium", standard_atomic_weight=186.207 +# +# +# +# +# Z=76, name="osmium", standard_atomic_weight=190.23 +# +# +# +# +# Z=77, name="iridium", standard_atomic_weight=192.217 +# +# +# +# +# Z=78, name="platinum", standard_atomic_weight=195.084 +# +# +# +# +# Z=79, name="gold", standard_atomic_weight=196.967 +# +# +# +# +# Z=80, name="mercury", standard_atomic_weight=200.592 +# +# +# +# +# Z=81, name="thallium", standard_atomic_weight=204.383 +# +# +# +# +# Z=82, name="lead", standard_atomic_weight=207.2 +# +# +# +# +# Z=83, name="bismuth", standard_atomic_weight=208.98 +# +# +# +# +# Z=84, name="polonium", standard_atomic_weight=209.0 +# +# +# +# +# Z=85, name="astatine", standard_atomic_weight=210.0 +# +# +# +# +# Z=86, name="radon", standard_atomic_weight=222.0 +# +# +# +# +# Z=87, name="francium", standard_atomic_weight=223.0 +# +# +# +# +# Z=88, name="radium", standard_atomic_weight=226.0 +# +# +# +# +# Z=89, name="actinium", standard_atomic_weight=227.0 +# +# +# +# +# Z=90, name="thorium", standard_atomic_weight=232.038 +# +# +# +# +# Z=91, name="protactinium", standard_atomic_weight=231.036 +# +# +# +# +# Z=92, name="uranium", standard_atomic_weight=238.029 +# +# +# +# +# Z=93, name="neptunium", standard_atomic_weight=237.048 +# +# +# +# +# Z=94, name="plutonium", standard_atomic_weight=239.052 +# +# +# +# +# Z=95, name="americium", standard_atomic_weight=243.0 +# +# +# +# +# Z=96, name="curium", standard_atomic_weight=247.0 +# +# +# +# +# Z=97, name="berkelium", standard_atomic_weight=247.0 +# +# +# +# +# Z=98, name="californium", standard_atomic_weight=251.0 +# +# +# +# +# Z=99, name="einsteinium", standard_atomic_weight=252 +# +# +# +# +# Z=100, name="fermium", standard_atomic_weight=257 +# +# +# +# +# Z=101, name="mendelevium", standard_atomic_weight=258 +# +# +# +# +# Z=102, name="nobelium", standard_atomic_weight=259 +# +# +# +# +# Z=103, name="lawrencium", standard_atomic_weight=266 +# +# +# +# +# Z=104, name="rutherfordium", standard_atomic_weight=267 +# +# +# +# +# Z=105, name="dubnium", standard_atomic_weight=268 +# +# +# +# +# Z=106, name="seaborgium", standard_atomic_weight=269 +# +# +# +# +# Z=107, name="bohrium", standard_atomic_weight=270 +# +# +# +# +# Z=108, name="hassium", standard_atomic_weight=269 +# +# +# +# +# Z=109, name="meitnerium", standard_atomic_weight=278 +# +# +# +# +# Z=110, name="darmstadtium", standard_atomic_weight=281 +# +# +# +# +# Z=111, name="roentgenium", standard_atomic_weight=282 +# +# +# +# +# Z=112, name="copernicium", standard_atomic_weight=285 +# +# +# +# +# Z=113, name="nihonium", standard_atomic_weight=286 +# +# +# +# +# Z=114, name="flerovium", standard_atomic_weight=289 +# +# +# +# +# Z=115, name="moscovium", standard_atomic_weight=290 +# +# +# +# +# Z=116, name="livermorium", standard_atomic_weight=293 +# +# +# +# +# Z=117, name="tennessine", standard_atomic_weight=294 +# +# +# +# +# Z=118, name="oganesson", standard_atomic_weight=294 +# +# +# +# +# +# +# IUPAC symbol of the electronic level. +# For each level, the electronic orbital configuration is also given +# +# For reference, see Jenkins, R., Manne, R., Robin, R., & Senemaud, C. (1991). +# IUPAC—nomenclature system for x-ray spectroscopy. X-Ray Spectrometry, 20(3), 149-155. +# +# +# +# +# same as 1s in level_xray +# +# +# +# +# 2s +# +# +# +# +# 2p_{1/2} +# +# +# +# +# 2p_{3/2} +# +# +# +# +# 3s +# +# +# +# +# 3p_{1/2} +# +# +# +# +# 3p_{3/2} +# +# +# +# +# 3d_{3/2} +# +# +# +# +# 3d_{5/2} +# +# +# +# +# 4s +# +# +# +# +# 4p_{1/2} +# +# +# +# +# 4p_{3/2} +# +# +# +# +# 4d_{3/2} +# +# +# +# +# 4d_{5/2} +# +# +# +# +# 4f_{5/2} +# +# +# +# +# 4f_{7/2} +# +# +# +# +# 5s +# +# +# +# +# 5p_{1/2} +# +# +# +# +# 5p_{3/2} +# +# +# +# +# 5d_{3/2} +# +# +# +# +# 5d_{5/2} +# +# +# +# +# 5f_{5/2} +# +# +# +# +# 5f_{7/2} +# +# +# +# +# 6s +# +# +# +# +# 6p_{1/2} +# +# +# +# +# 6p_{3/2} +# +# +# +# +# +# +# Electronic orbital configuration of the electronic level. +# +# +# +# +# same as K in level_xray +# +# +# +# +# L1 +# +# +# +# +# L3 +# +# +# +# +# M1 +# +# +# +# +# M2 +# +# +# +# +# M3 +# +# +# +# +# M4 +# +# +# +# +# M5 +# +# +# +# +# N1 +# +# +# +# +# N2 +# +# +# +# +# N3 +# +# +# +# +# N4 +# +# +# +# +# N5 +# +# +# +# +# N6 +# +# +# +# +# N7 +# +# +# +# +# O1 +# +# +# +# +# O2 +# +# +# +# +# O3 +# +# +# +# +# O4 +# +# +# +# +# O5 +# +# +# +# +# O6 +# +# +# +# +# O7 +# +# +# +# +# P1 +# +# +# +# +# P2 +# +# +# +# +# P3 +# +# +# +# +# +# +# description of X-ray electronic level +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# diff --git a/contributed_definitions/nyaml/NXelectronanalyser.yaml b/contributed_definitions/nyaml/NXelectronanalyser.yaml index 723a5cb48d..d576ffd6f4 100644 --- a/contributed_definitions/nyaml/NXelectronanalyser.yaml +++ b/contributed_definitions/nyaml/NXelectronanalyser.yaml @@ -1,7 +1,7 @@ category: base doc: | Subclass of NXinstrument to describe a photoelectron analyser. - + Refers to Term `12.59`_ of the ISO 18115-1:2023 specification. .. _12.59: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.59 @@ -28,32 +28,32 @@ NXelectronanalyser(NXobject): doc: | Acronym or other shorthand name work_function(NX_FLOAT): + unit: NX_ENERGY doc: | Work function of the electron analyser. - - The work function of a uniform surface of a conductor is the minimum energy required to remove + + The work function of a uniform surface of a conductor is the minimum energy required to remove an electron from the interior of the solid to a vacuum level immediately outside the solid surface. - The kinetic energy :math:`E_K` of a photoelectron emitted from an energy-level with binding energy + The kinetic energy :math:`E_K` of a photoelectron emitted from an energy-level with binding energy :math:`E_B` below the Fermi level is given by :math:`E_K = h\nu - E_B - e \phi_{\mathrm{sample}}`, where :math:`\phi_{\mathrm{sample}}` is the work function of the sample surface. In PES measurements, the sample and the spectrometer (with work function :math:`\phi_{\mathrm{spectr.}}`) are electrically - connected and therefore their Fermi levels are aligned. Due to the difference in local vacuum level - between the sample and spectrometer, there exists an electric potential difference (contact potential) - :math:`\Delta\phi = \phi_{\mathrm{sample}} - \phi_{\mathrm{spectr.}}`. The measured kinetic energy of - a photoelectron in PES is therefore given by - :math:`E_K^{\mathrm{meas.}} = h\nu - E_B + \Delta \phi = h\nu - E_B - e \phi_{\mathrm{spectr.}}`. + connected and therefore their Fermi levels are aligned. Due to the difference in local vacuum level + between the sample and spectrometer, there exists an electric potential difference (contact potential) + :math:`\Delta\phi = \phi_{\mathrm{sample}} - \phi_{\mathrm{spectr.}}`. The measured kinetic energy of + a photoelectron in PES is therefore given by + :math:`E_K^{\mathrm{meas.}} = h\nu - E_B + \Delta \phi = h\nu - E_B - e \phi_{\mathrm{spectr.}}`. As a result, the measured kinetic energy :math:`E_K^{\mathrm{meas.}}` of a photoelectron is `independent` - of the sample work function. Nonetheless, the work function :math:`\phi_s` needs to be known to + of the sample work function. Nonetheless, the work function :math:`\phi_s` needs to be known to accurately determine the binding energy scale. - unit: NX_ENERGY energy_resolution(NX_FLOAT): unit: NX_ENERGY doc: | Energy resolution of the electron analyser (FWHM of gaussian broadening) Refers to Term `10.7`_ of the ISO 18115-1:2023 specification. - + .. _10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 momentum_resolution(NX_FLOAT): unit: NX_WAVENUMBER @@ -67,9 +67,9 @@ NXelectronanalyser(NXobject): unit: NX_LENGTH doc: | Spatial resolution of the electron analyser (Airy disk radius) - + Refers to Term `10.15`_ ff. of the ISO 18115-1:2023 specification. - + .. _10.15: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.15 fast_axes(NX_CHAR): doc: | @@ -100,34 +100,38 @@ NXelectronanalyser(NXobject): transmission_function(NXdata): doc: | Transmission function of the electron analyser. - - The transmission function (TF) specifies the detection efficiency per solid angle for electrons of + + The transmission function (TF) specifies the detection efficiency per solid angle for electrons of different kinetic energy passing through the electron analyser. It depends on the spectrometer geometry as well as operation settings such as lens mode and pass energy. The transmission function is usually given as kinetic energy vs. relative intensity. - - The TF is used for calibration of the intensity scale in quantitative XPS. Without proper + + The TF is used for calibration of the intensity scale in quantitative XPS. Without proper transmission correction, a comparison of results measured from the same sample using different operating modes for an instrument would show significant variations in atomic concentrations. - + Refers to Term `7.15`_ ff. of the ISO 18115-1:2023 specification. - + .. _7.15: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:7.15 \@signal: enumeration: [relative_intensity] \@axes: - enumeration: [kinetic_energy] + enumeration: [kinetic_energy] kinetic_energy(NX_FLOAT): + unit: NX_ENERGY doc: | Kinetic energy values - unit: NX_ENERGY - dim: (n_transmission_function,) + dimensions: + rank: 1 + dim: [[1, n_transmission_function]] relative_intensity(NX_FLOAT): - doc: | - Relative transmission efficiency for the given kinetic energies unit: NX_UNITLESS - dim: (n_transmission_function,) + doc: | + Relative transmission efficiency for the given kinetic energies + dimensions: + rank: 1 + dim: [[1, n_transmission_function]] depends_on(NX_CHAR): doc: | Refers to the last transformation specifying the position of the manipulator in @@ -163,7 +167,7 @@ NXelectronanalyser(NXobject): (NXfabrication): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8f8507c0c2afbfa0bd1b18e863e8f7c90326769b8ffcc52f48bf88712e1c5b15 +# 9c03d1de4220953d6aaa62a9a36d641e38a166d3f5ca2f4e2e990c8ab9f9c7f8 # # # # +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays +# +# +# +# Number of data points in the transmission function. +# +# +# # # This is the most general application definition for multidimensional # photoelectron spectroscopy. +# +# Groups and fields are named according to the +# `ISO 18115-1:2023`_ specification as well as the `IUPAC Recommendations 2020`_. +# +# .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html +# .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 # # # @@ -578,10 +617,21 @@ NXmpes(NXobject): # # # -# A name of the experimental method according -# to the `ISO 18115-1:2023`_ specification. +# A name of the experimental method according to `Clause 11`_ of +# the `ISO 18115-1:2023`_ specification. +# +# Examples include: +# * X-ray photoelectron spectroscopy (XPS) +# * angle-resolved X-ray photoelectron spectroscopy (ARXPS) +# * ultraviolet photoelectron spectroscopy (UPS) +# * angle-resolved photoelectron spectroscopy (ARPES) +# * hard X-ray photoemission spectroscopy (HAXPES) +# * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) +# * photoelectron emission microscopy (PEEM) +# * electron spectroscopy for chemical analysis (ESCA) # # .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html +# .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 # # # @@ -624,7 +674,22 @@ NXmpes(NXobject): # # # +# +# MPES spectrometer +# +# Refers to Term `12.58`_ of the ISO 18115-1:2023 specification. +# +# .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 +# # +# +# Overall energy resolution of the MPES instrument +# +# Refers to Terms `10.7`_ ff. and `10.24`_ of the ISO 18115-1:2023 specification. +# +# .. _10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 +# .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 +# # # # @@ -687,7 +752,7 @@ NXmpes(NXobject): # The beam emitted by this source. # Should be named with the same appendix, e.g., # for `source_probe` it should refer to `beam_probe`. -# Refers to the same concept as /NXentry/NXinstrument/source_TYPE +# Refers to the same concept as /NXentry/NXinstrument/beam_TYPE # and may be linked. # # @@ -696,6 +761,20 @@ NXmpes(NXobject): # we have a subdefinition NXlink to refer to a path. # This would also be helpful for NXtransformations--> # +# +# +# The beam emitted by this source. +# Should be named with the same appendix, e.g., +# for `source_probe` it should refer to `beam_probe`. +# Refers to the same concept as /NXentry/NXinstrument/source_TYPE +# and may be linked. +# +# +# +# +# # # # @@ -711,10 +790,10 @@ NXmpes(NXobject): # # # -# The beam emitted by this source. +# The source that emitted this beam. # Should be named with the same appendix, e.g., # for `beam_probe` it should refer to `source_probe`. -# Refers to the same concept as /NXentry/NXinstrument/beam_TYPE +# Refers to the same concept as /NXentry/NXinstrument/source_TYPE # and may be linked. # # @@ -730,10 +809,15 @@ NXmpes(NXobject): # # Energy resolution of the analyser with the current setting. May be linked from a # NXcalibration. +# +# Refers to Term `10.24`_ of the ISO 18115-1:2023 specification. +# +# .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 # # -# +# # +# # # The source used to generate the primary photons. Properties refer strictly to @@ -209,20 +208,6 @@ This would also be helpful for NXtransformations--> and may be linked. - - - - - - - - Distance between the point where this NXbeam instance is evaluating the beam properties - and the intersection point of the beam and the sample. - For photoemission, this intersection point is where the centre of the beam touches the sample surface. - - @@ -295,10 +280,10 @@ Optional constant settings (like lens focusing parameters on the sample: positio - Size, position and shape of the iris inserted in the column. + Size, position and shape of the iris inserted in the column. - The iris is an aperture in the lens with a variable diameter which can reduce the number of - electrons entering the analyzer. + The iris is an aperture in the lens with a variable diameter which can reduce the number of + electrons entering the analyzer. To add additional or other slits use the APERTURE group of NXcollectioncolumn. @@ -472,10 +457,10 @@ Optional constant settings (like lens focusing parameters on the sample: positio - For energy referencing, the measured energies are corrected for the charging potential + For energy referencing, the measured energies are corrected for the charging potential (i.e., the electrical potential of the surface region of an insulating sample, caused by irradiation) such that those energies correspond to a sample with no surface charge. - Usually, the energy axis is adjusted by shifting all energies uniformally until one + Usually, the energy axis is adjusted by shifting all energies uniformally until one well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. Refers to Term `12.74`_ ff. of the ISO 18115-1:2023 specification. @@ -495,14 +480,14 @@ Optional constant settings (like lens focusing parameters on the sample: positio - Reference peak that was used for the calibration. + Reference peak that was used for the calibration. For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge - The binding energy (in units of eV) that the specified emission line appeared at, + The binding energy (in units of eV) that the specified emission line appeared at, after adjusting the binding energy scale. Refers to Term `12.16`_ ff. of the ISO 18115-1:2023 specification. @@ -533,7 +518,7 @@ Optional constant settings (like lens focusing parameters on the sample: positio - Has an intensity calibration been applied? + Has an intensity calibration been applied? That is, has the transmission function of the analyser been taken into account? @@ -542,8 +527,8 @@ Optional constant settings (like lens focusing parameters on the sample: positio Transmission function of the electron analyser. - The transmission function (TF) specifies the detection efficiency for electrons of - different kinetic energy passing through the electron analyser. + The transmission function (TF) specifies the detection efficiency for electrons of + different kinetic energy passing through the electron analyser. This can be a link to /entry/instrument/electronanalyser/transmission_function. @@ -659,7 +644,7 @@ Optional constant settings (like lens focusing parameters on the sample: positio The calibrated energy axis can be either in binding or kinetic energy. This should be a link to either - /entry/process/energy_calibration/calibrated_axis or + /entry/process/energy_calibration/calibrated_axis or /entry/process/energy_correction/calibrated_axis. diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 5c8fad7e5e..bb4fb6609c 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -16,6 +16,9 @@ symbols: type: group NXmpes(NXobject): (NXentry): + definition: + \@version: + enumeration: [NXmpes] title: start_time(NX_DATE_TIME): doc: | @@ -42,9 +45,6 @@ NXmpes(NXobject): .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 - definition: - \@version: - enumeration: [NXmpes] (NXuser): exists: recommended doc: | @@ -102,7 +102,6 @@ NXmpes(NXobject): source_TYPE(NXsource): # Comment from mpes may workshop: - # - Add linking between source and beam # - There is much more information which can be provided for NXsource doc: | The source used to generate the primary photons. Properties refer strictly to @@ -151,22 +150,6 @@ NXmpes(NXobject): for `source_probe` it should refer to `beam_probe`. Refers to the same concept as /NXentry/NXinstrument/source_TYPE and may be linked. - - # It would be nice if we had the notion of linking in nexus or if - # we have a subdefinition NXlink to refer to a path. - # This would also be helpful for NXtransformations - beam_TYPE(NXbeam): - - # Comment from mpes may workshop: Add linking between source and beam - - # Add extent as recommended? - distance(NX_NUMBER): - unit: NX_LENGTH - exists: recommended - doc: | - Distance between the point where this NXbeam instance is evaluating the beam properties - and the intersection point of the beam and the sample. - For photoemission, this intersection point is where the centre of the beam touches the sample surface. incident_energy(NX_FLOAT): unit: NX_ENERGY incident_energy_spread(NX_NUMBER): @@ -558,7 +541,7 @@ NXmpes(NXobject): Calibrated binding energy axis. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e4c02e8635396d39409adbb7b08092cd7f47f441cafa00b2fc587745d09504ac +# 83b124ee2d429df9b9b06b36c540fc64a4d9340e74cfebf03c9fc450257b6eb0 # # # # # The source used to generate the primary photons. Properties refer strictly to @@ -770,20 +752,6 @@ NXmpes(NXobject): # and may be linked. # # -# -# -# -# -# -# -# -# Distance between the point where this NXbeam instance is evaluating the beam properties -# and the intersection point of the beam and the sample. -# For photoemission, this intersection point is where the centre of the beam touches the sample surface. -# -# # # # @@ -856,10 +824,10 @@ NXmpes(NXobject): # # # -# Size, position and shape of the iris inserted in the column. +# Size, position and shape of the iris inserted in the column. # -# The iris is an aperture in the lens with a variable diameter which can reduce the number of -# electrons entering the analyzer. +# The iris is an aperture in the lens with a variable diameter which can reduce the number of +# electrons entering the analyzer. # # To add additional or other slits use the APERTURE group of NXcollectioncolumn. # @@ -1033,10 +1001,10 @@ NXmpes(NXobject): # # # -# For energy referencing, the measured energies are corrected for the charging potential +# For energy referencing, the measured energies are corrected for the charging potential # (i.e., the electrical potential of the surface region of an insulating sample, caused by # irradiation) such that those energies correspond to a sample with no surface charge. -# Usually, the energy axis is adjusted by shifting all energies uniformally until one +# Usually, the energy axis is adjusted by shifting all energies uniformally until one # well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. # # Refers to Term `12.74`_ ff. of the ISO 18115-1:2023 specification. @@ -1056,14 +1024,14 @@ NXmpes(NXobject): # # # -# Reference peak that was used for the calibration. +# Reference peak that was used for the calibration. # # For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge # # # # -# The binding energy (in units of eV) that the specified emission line appeared at, +# The binding energy (in units of eV) that the specified emission line appeared at, # after adjusting the binding energy scale. # # Refers to Term `12.16`_ ff. of the ISO 18115-1:2023 specification. @@ -1094,7 +1062,7 @@ NXmpes(NXobject): # # # -# Has an intensity calibration been applied? +# Has an intensity calibration been applied? # # That is, has the transmission function of the analyser been taken into account? # @@ -1103,8 +1071,8 @@ NXmpes(NXobject): # # Transmission function of the electron analyser. # -# The transmission function (TF) specifies the detection efficiency for electrons of -# different kinetic energy passing through the electron analyser. +# The transmission function (TF) specifies the detection efficiency for electrons of +# different kinetic energy passing through the electron analyser. # This can be a link to /entry/instrument/electronanalyser/transmission_function. # # @@ -1220,7 +1188,7 @@ NXmpes(NXobject): # # The calibrated energy axis can be either in binding or kinetic energy. # This should be a link to either -# /entry/process/energy_calibration/calibrated_axis or +# /entry/process/energy_calibration/calibrated_axis or # /entry/process/energy_correction/calibrated_axis. # # From 4f4fabcd9701a964c19a6d213647f292a13d4c9b Mon Sep 17 00:00:00 2001 From: domna Date: Tue, 10 Oct 2023 09:14:26 +0200 Subject: [PATCH 0325/1012] Sets user affilliation and name to required and remove any other fields in user --- contributed_definitions/NXmpes.nxdl.xml | 18 +----------------- contributed_definitions/nyaml/NXmpes.yaml | 13 ------------- 2 files changed, 1 insertion(+), 30 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 289ac2c9e4..6b4f315974 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -89,28 +89,12 @@ Name of the user. - + Name of the affiliation of the user at the point in time when the experiment was performed. - - - Full address (street, street number, ZIP, city, country) of the user's - affiliation. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index bb4fb6609c..3e5577321f 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -54,22 +54,9 @@ NXmpes(NXobject): doc: | Name 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: | - Full address (street, street number, ZIP, city, country) of the user's - affiliation. - email: - doc: | - Email address of the user. - orcid: - exists: recommended - doc: | - Author ID defined by https://orcid.org/. (NXinstrument): doc: | MPES spectrometer From 278ff9525c6879ece343f9ec25d34d6f88baa18d Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 11 Oct 2023 10:51:35 +0200 Subject: [PATCH 0326/1012] Adds NXphotoemission --- contributed_definitions/NXmpes.nxdl.xml | 625 +-------- .../NXphotoemission.nxdl.xml | 658 +++++++++ contributed_definitions/nyaml/NXmpes.yaml | 1195 +--------------- .../nyaml/NXphotoemission.yaml | 1205 +++++++++++++++++ 4 files changed, 1865 insertions(+), 1818 deletions(-) create mode 100644 contributed_definitions/NXphotoemission.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXphotoemission.yaml diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 6b4f315974..6a4cedf1da 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -21,17 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of data points in the transmission function. - - - + This is the most general application definition for multidimensional photoelectron spectroscopy. @@ -42,617 +32,4 @@ .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 - - - - - - - - - - - Datetime of the start of the measurement. - - - - - Datetime of the end of the measurement. - - - - - A name of the experimental method according to `Clause 11`_ of - the `ISO 18115-1:2023`_ specification. - - Examples include: - * X-ray photoelectron spectroscopy (XPS) - * angle-resolved X-ray photoelectron spectroscopy (ARXPS) - * ultraviolet photoelectron spectroscopy (UPS) - * angle-resolved photoelectron spectroscopy (ARPES) - * hard X-ray photoemission spectroscopy (HAXPES) - * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) - * photoelectron emission microscopy (PEEM) - * electron spectroscopy for chemical analysis (ESCA) - - .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html - .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 - - - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when the experiment was - performed. - - - - - - MPES spectrometer - - Refers to Term `12.58`_ of the ISO 18115-1:2023 specification. - - .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 - - - - Overall energy resolution of the MPES instrument - - Refers to Terms `10.7`_ ff. and `10.24`_ of the ISO 18115-1:2023 specification. - - .. _10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 - .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 - - - - - - - - - - - - - - - - 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. - - - - - - - - - - - - - - - - - - - - Specification of type, may also go to name. - - - - - - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - - - - - - - - - - - - - The beam emitted by this source. - Should be named with the same appendix, e.g., - for `source_probe` it should refer to `beam_probe`. - Refers to the same concept as /NXentry/NXinstrument/beam_TYPE - and may be linked. - - - - - - - - The beam emitted by this source. - Should be named with the same appendix, e.g., - for `source_probe` it should refer to `beam_probe`. - Refers to the same concept as /NXentry/NXinstrument/source_TYPE - and may be linked. - - - - - - - - - The source that emitted this beam. - Should be named with the same appendix, e.g., - for `beam_probe` it should refer to `source_probe`. - Refers to the same concept as /NXentry/NXinstrument/source_TYPE - and may be linked. - - - - - - - - - - - - - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - Refers to Term `10.24`_ of the ISO 18115-1:2023 specification. - - .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 - - - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - Labelling of the lens setting in use. - - - - - - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - Size, position and shape of the iris inserted in the column. - - The iris is an aperture in the lens with a variable diameter which can reduce the number of - electrons entering the analyzer. - - To add additional or other slits use the APERTURE group of NXcollectioncolumn. - - - - - - - - - - - - - - - - - - - - - - - - Size, position and shape of the entrance slit in dispersive analyzers. - - To add additional or other slits use the APERTURE group of NXenergydispersion. - - - - - Size, position and shape of the exit slit in dispersive analyzers. - - To add additional or other slits use the APERTURE group of NXenergydispersion. - - - - - - - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - - - - - - - - Raw data before calibration. - - - - - - - - Manipulator for positioning of the sample. - - - - - - Bias of the sample with respect to analyser ground. - - This field may also be found in NXsample if present. - - Refers to Term `8.41`_ of the ISO 18115-1:2023 specification. - - .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 - - - - - - - - - - - - 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 - - - - Calibration event on the energy axis. - - For XPS, the calibration should ideally be performed according to - `ISO 15472:2010`_ specification. - - .. _ISO 15472:2010: https://www.iso.org/standard/74811.html - - - - Has an energy calibration been applied? - - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - - Has an angular calibration been applied? - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - - Has an spatial calibration been applied? - - - - - This is the calibrated spatial axis to be used for data plotting. - - - - - - - Has an momentum calibration been applied? - - - - - This is the momentum axis to be used for data plotting. - - - - - - For energy referencing, the measured energies are corrected for the charging potential - (i.e., the electrical potential of the surface region of an insulating sample, caused by - irradiation) such that those energies correspond to a sample with no surface charge. - Usually, the energy axis is adjusted by shifting all energies uniformally until one - well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. - - Refers to Term `12.74`_ ff. of the ISO 18115-1:2023 specification. - - .. _12.74: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 - - - - Have the energy axes been adjusted (e.g., in cases where samples are not - conductive)? - - - - - Electronic core or valence level that was used for the calibration. - - - - - Reference peak that was used for the calibration. - - For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge - - - - - The binding energy (in units of eV) that the specified emission line appeared at, - after adjusting the binding energy scale. - - Refers to Term `12.16`_ ff. of the ISO 18115-1:2023 specification. - - .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - - - - - Offset between measured binding energy and calibrated binding energy of the - emission line. - - - - - This is the calibrated energy axis to be used for data plotting. - - This should link to /entry/data/energy. - - - - - - In the transmission correction, each intensity measurement for electrons of a given - kinetic energy is multiplied by the corresponding value in the relative_intensity - field of the transmission_function. This calibration procedure is used to account for - the different tranmsission efficiencies when using different lens modes. - - - - Has an intensity calibration been applied? - - That is, has the transmission function of the analyser been taken into account? - - - - - Transmission function of the electron analyser. - - The transmission function (TF) specifies the detection efficiency for electrons of - different kinetic energy passing through the electron analyser. - This can be a link to /entry/instrument/electronanalyser/transmission_function. - - - - - - - - - - - - - - Kinetic energy values - - - - - - - - Relative transmission efficiency for the given kinetic energies - - - - - - - - - - - - - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - - - - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - - - - - Description of the surface preparation technique for the XPS experiment, i.e. - UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report - of the previous operations, in any format(NXnote allows to add pictures, audio, - movies). Alternatively, a reference to the location or a unique identifier or - other metadata file. In the case these are not available, free-text description. - - - - - In the case of a fixed temperature measurement this is the scalar temperature of - the sample. In the case of an experiment in which the temperature is changed and - recoded, this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. - - - - - - - - - - - - - - Voltage applied to sample and sample holder. - - - - - - - - - - - - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, momentum, spatial coordinate, pump-probe - delay, spin index, temperature, etc. The axes traces should be linked to the - actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - Calibrated energy axis. - - The calibrated energy axis can be either in binding or kinetic energy. - This should be a link to either - /entry/process/energy_calibration/calibrated_axis or - /entry/process/energy_correction/calibrated_axis. - - - - The energy can be either stored as kinetic (Term `3.35`_ of the ISO 18115-1:2023 - specification) or as binding (Term `12.16`_) energy. - - .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 - .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - - - - - Calibrated kinetic energy axis. - - - - - Calibrated binding energy axis. - - - - - - - diff --git a/contributed_definitions/NXphotoemission.nxdl.xml b/contributed_definitions/NXphotoemission.nxdl.xml new file mode 100644 index 0000000000..2e95d71b31 --- /dev/null +++ b/contributed_definitions/NXphotoemission.nxdl.xml @@ -0,0 +1,658 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of data points in the transmission function. + + + + + This is the most general application definition for + photoemission experiments. + + Groups and fields are named according to the + `ISO 18115-1:2023`_ specification as well as the `IUPAC Recommendations 2020`_. + + .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 + + + + + + + + + + + + Datetime of the start of the measurement. + + + + + Datetime of the end of the measurement. + + + + + A name of the experimental method according to `Clause 11`_ of + the `ISO 18115-1:2023`_ specification. + + Examples include: + * X-ray photoelectron spectroscopy (XPS) + * angle-resolved X-ray photoelectron spectroscopy (ARXPS) + * ultraviolet photoelectron spectroscopy (UPS) + * angle-resolved photoelectron spectroscopy (ARPES) + * hard X-ray photoemission spectroscopy (HAXPES) + * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) + * photoelectron emission microscopy (PEEM) + * electron spectroscopy for chemical analysis (ESCA) + + .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 + + + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + + + MPES spectrometer + + Refers to Term `12.58`_ of the ISO 18115-1:2023 specification. + + .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 + + + + Overall energy resolution of the MPES instrument + + Refers to Terms `10.7`_ ff. and `10.24`_ of the ISO 18115-1:2023 specification. + + .. _10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 + .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 + + + + + + + + + + + + + + + + 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. + + + + + + + + + + + + + + + + + + + + Specification of type, may also go to name. + + + + + + Type of probe. In photoemission it's always photons, so the full NIAC list is + restricted. + + + + + + + + + + + + + The beam emitted by this source. + Should be named with the same appendix, e.g., + for `source_probe` it should refer to `beam_probe`. + Refers to the same concept as /NXentry/NXinstrument/beam_TYPE + and may be linked. + + + + + + + + The beam emitted by this source. + Should be named with the same appendix, e.g., + for `source_probe` it should refer to `beam_probe`. + Refers to the same concept as /NXentry/NXinstrument/source_TYPE + and may be linked. + + + + + + + + + The source that emitted this beam. + Should be named with the same appendix, e.g., + for `beam_probe` it should refer to `source_probe`. + Refers to the same concept as /NXentry/NXinstrument/source_TYPE + and may be linked. + + + + + + + + + + + + + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. + + Refers to Term `10.24`_ of the ISO 18115-1:2023 specification. + + .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 + + + + + + + + + + Scheme of the electron collection column. + + + + + + + + + + + + + + Labelling of the lens setting in use. + + + + + + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + Size, position and shape of the iris inserted in the column. + + The iris is an aperture in the lens with a variable diameter which can reduce the number of + electrons entering the analyzer. + + To add additional or other slits use the APERTURE group of NXcollectioncolumn. + + + + + + + + + + + + + + + + + + + + + + + + Size, position and shape of the entrance slit in dispersive analyzers. + + To add additional or other slits use the APERTURE group of NXenergydispersion. + + + + + Size, position and shape of the exit slit in dispersive analyzers. + + To add additional or other slits use the APERTURE group of NXenergydispersion. + + + + + + + + + + + + Type of electron amplifier in the first amplification step. + + + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + + + + + + + + + Raw data before calibration. + + + + + + + + Manipulator for positioning of the sample. + + + + + + Bias of the sample with respect to analyser ground. + + This field may also be found in NXsample if present. + + Refers to Term `8.41`_ of the ISO 18115-1:2023 specification. + + .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 + + + + + + + + + + + + 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 + + + + Calibration event on the energy axis. + + For XPS, the calibration should ideally be performed according to + `ISO 15472:2010`_ specification. + + .. _ISO 15472:2010: https://www.iso.org/standard/74811.html + + + + Has an energy calibration been applied? + + + + + This is the calibrated energy axis to be used for data plotting. + + + + + + + Has an angular calibration been applied? + + + + + This is the calibrated angular axis to be used for data plotting. + + + + + + + Has an spatial calibration been applied? + + + + + This is the calibrated spatial axis to be used for data plotting. + + + + + + + Has an momentum calibration been applied? + + + + + This is the momentum axis to be used for data plotting. + + + + + + For energy referencing, the measured energies are corrected for the charging potential + (i.e., the electrical potential of the surface region of an insulating sample, caused by + irradiation) such that those energies correspond to a sample with no surface charge. + Usually, the energy axis is adjusted by shifting all energies uniformally until one + well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. + + Refers to Term `12.74`_ ff. of the ISO 18115-1:2023 specification. + + .. _12.74: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 + + + + Have the energy axes been adjusted (e.g., in cases where samples are not + conductive)? + + + + + Electronic core or valence level that was used for the calibration. + + + + + Reference peak that was used for the calibration. + + For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge + + + + + The binding energy (in units of eV) that the specified emission line appeared at, + after adjusting the binding energy scale. + + Refers to Term `12.16`_ ff. of the ISO 18115-1:2023 specification. + + .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + + + + + Offset between measured binding energy and calibrated binding energy of the + emission line. + + + + + This is the calibrated energy axis to be used for data plotting. + + This should link to /entry/data/energy. + + + + + + In the transmission correction, each intensity measurement for electrons of a given + kinetic energy is multiplied by the corresponding value in the relative_intensity + field of the transmission_function. This calibration procedure is used to account for + the different tranmsission efficiencies when using different lens modes. + + + + Has an intensity calibration been applied? + + That is, has the transmission function of the analyser been taken into account? + + + + + Transmission function of the electron analyser. + + The transmission function (TF) specifies the detection efficiency for electrons of + different kinetic energy passing through the electron analyser. + This can be a link to /entry/instrument/electronanalyser/transmission_function. + + + + + + + + + + + + + + Kinetic energy values + + + + + + + + Relative transmission efficiency for the given kinetic energies + + + + + + + + + + + + + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + + + + + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + + + + + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). + + + + + Description of the surface preparation technique for the XPS experiment, i.e. + UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report + of the previous operations, in any format(NXnote allows to add pictures, audio, + movies). Alternatively, a reference to the location or a unique identifier or + other metadata file. In the case these are not available, free-text description. + + + + + In the case of a fixed temperature measurement this is the scalar temperature of + the sample. In the case of an experiment in which the temperature is changed and + recoded, this is an array of length m of temperatures. This should be a link to + /entry/instrument/manipulator/sample_temperature. + + + + + + + + + + + + + + Voltage applied to sample and sample holder. + + + + + + + + + + + + Represents a measure of one- or more-dimensional photoemission counts, where the + varied axis may be for example energy, momentum, spatial coordinate, pump-probe + delay, spin index, temperature, etc. The axes traces should be linked to the + actual encoder position in NXinstrument or calibrated axes in NXprocess. + + + + + Calibrated energy axis. + + The calibrated energy axis can be either in binding or kinetic energy. + This should be a link to either + /entry/process/energy_calibration/calibrated_axis or + /entry/process/energy_correction/calibrated_axis. + + + + The energy can be either stored as kinetic (Term `3.35`_ of the ISO 18115-1:2023 + specification) or as binding (Term `12.16`_) energy. + + .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 + .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + + + + + Calibrated kinetic energy axis. + + + + + Calibrated binding energy axis. + + + + + + + + diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 3e5577321f..9f4bba9bca 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -8,1198 +8,5 @@ doc: | .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays - n_transmission_function: | - Number of data points in the transmission function. type: group -NXmpes(NXobject): - (NXentry): - definition: - \@version: - enumeration: [NXmpes] - title: - start_time(NX_DATE_TIME): - doc: | - Datetime of the start of the measurement. - end_time(NX_DATE_TIME): - exists: recommended - doc: | - Datetime of the end of the measurement. - method: - exists: recommended - doc: | - A name of the experimental method according to `Clause 11`_ of - the `ISO 18115-1:2023`_ specification. - - Examples include: - * X-ray photoelectron spectroscopy (XPS) - * angle-resolved X-ray photoelectron spectroscopy (ARXPS) - * ultraviolet photoelectron spectroscopy (UPS) - * angle-resolved photoelectron spectroscopy (ARPES) - * hard X-ray photoemission spectroscopy (HAXPES) - * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) - * photoelectron emission microscopy (PEEM) - * electron spectroscopy for chemical analysis (ESCA) - - .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html - .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 - (NXuser): - exists: recommended - doc: | - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - name: - doc: | - Name of the user. - affiliation: - doc: | - Name of the affiliation of the user at the point in time when the experiment was - performed. - (NXinstrument): - doc: | - MPES spectrometer - - Refers to Term `12.58`_ of the ISO 18115-1:2023 specification. - - .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 - energy_resolution(NXresolution): - exists: recommended - doc: | - Overall energy resolution of the MPES instrument - - Refers to Terms `10.7`_ ff. and `10.24`_ of the ISO 18115-1:2023 specification. - - .. _10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 - .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 - physical_quantity: - type: - resolution(NXdata): - magnitude(NX_FLOAT): - unit: NX_ENERGY - device_information(NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - source_TYPE(NXsource): - - # Comment from mpes may workshop: - # - There is much more information which can be provided for NXsource - doc: | - The source used to generate the primary photons. Properties refer strictly to - parameters of the source, not of the output beam. For example, the energy of the - source is not the optical power of the beam, but the energy of the electron beam - in a synchrotron and so on. - type: - enumeration: [Synchrotron X-ray Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, UV Plasma Source, Metal Jet X-ray, HHG laser, UV lamp, Monochromatized electron source, other] - type_other: - exists: optional - doc: | - Specification of type, may also go to name. - name: - exists: recommended - probe: - doc: | - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - enumeration: [photons] - device_information(NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - associated_beam(NXbeam): - doc: | - The beam emitted by this source. - Should be named with the same appendix, e.g., - for `source_probe` it should refer to `beam_probe`. - Refers to the same concept as /NXentry/NXinstrument/beam_TYPE - and may be linked. - - # It would be nice if we had the notion of linking in nexus or if - # we have a subdefinition NXlink to refer to a path. - # This would also be helpful for NXtransformations - beam_TYPE(NXbeam): - distance(NX_NUMBER): - unit: NX_LENGTH - exists: recommended - doc: | - The beam emitted by this source. - Should be named with the same appendix, e.g., - for `source_probe` it should refer to `beam_probe`. - Refers to the same concept as /NXentry/NXinstrument/source_TYPE - and may be linked. - incident_energy(NX_FLOAT): - unit: NX_ENERGY - incident_energy_spread(NX_NUMBER): - exists: recommended - unit: NX_ENERGY - incident_polarization(NX_NUMBER): - exists: recommended - unit: NX_ANY - extent(NX_FLOAT): - exists: recommended - associated_source(NXsource): - doc: | - The source that emitted this beam. - Should be named with the same appendix, e.g., - for `beam_probe` it should refer to `source_probe`. - Refers to the same concept as /NXentry/NXinstrument/source_TYPE - and may be linked. - (NXelectronanalyser): - device_information(NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - description: - energy_resolution(NX_FLOAT): - exists: recommended - unit: NX_ENERGY - doc: | - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - Refers to Term `10.24`_ of the ISO 18115-1:2023 specification. - - .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 - fast_axes: - exists: recommended - slow_axes: - exists: recommended - transmission_function(NX_FLOAT): - exists: optional - (NXcollectioncolumn): - - # TODO: Comment from Anders Frisk on proposal page - # What is the definition of a collection column? - # Optional constant settings (like lens focusing parameters on the sample: position_x, position_y, working_distance) - scheme: - doc: | - Scheme of the electron collection column. - enumeration: [Standard, Angular dispersive, Spatial dispersive, Selective area, Deflector, PEEM, Momentum Microscope] - mode: - exists: recommended - doc: | - Labelling of the lens setting in use. - projection: - exists: recommended - field_aperture(NXaperture): - exists: optional - doc: | - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - contrast_aperture(NXaperture): - exists: optional - doc: | - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - iris(NXaperture): - exists: optional - doc: | - Size, position and shape of the iris inserted in the column. - - The iris is an aperture in the lens with a variable diameter which can reduce the number of - electrons entering the analyzer. - - To add additional or other slits use the APERTURE group of NXcollectioncolumn. - device_information(NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - (NXenergydispersion): - scheme: - enumeration: [tof, hemispherical, double hemispherical, cylindrical mirror, display mirror, retarding grid] - pass_energy(NX_FLOAT): - unit: NX_ENERGY - energy_scan_mode: - entrance_slit(NXaperture): - exists: optional - doc: | - Size, position and shape of the entrance slit in dispersive analyzers. - - To add additional or other slits use the APERTURE group of NXenergydispersion. - exit_slit(NXaperture): - exists: optional - doc: | - Size, position and shape of the exit slit in dispersive analyzers. - - To add additional or other slits use the APERTURE group of NXenergydispersion. - device_information(NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - (NXdetector): - amplifier_type: - exists: recommended - doc: | - Type of electron amplifier in the first amplification step. - enumeration: [MCP, channeltron] - detector_type: - exists: recommended - doc: | - Description of the detector type. - enumeration: [DLD, Phosphor+CCD, Phosphor+CMOS, ECMOS, Anode, Multi-anode] - device_information(NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - (NXdata): - exists: recommended - \@signal: - enumeration: [raw] - raw(NX_NUMBER): - doc: | - Raw data before calibration. - (NXmanipulator): - exists: optional - doc: | - Manipulator for positioning of the sample. - sample_temperature(NX_FLOAT): - exists: recommended - unit: NX_TEMPERATURE - drain_current(NX_FLOAT): - exists: recommended - unit: NX_CURRENT - sample_bias(NX_FLOAT): - exists: recommended - unit: NX_CURRENT - doc: | - Bias of the sample with respect to analyser ground. - - This field may also be found in NXsample if present. - - Refers to Term `8.41`_ of the ISO 18115-1:2023 specification. - - .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 - device_information(NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - (NXprocess): - exists: recommended - doc: | - 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 - energy_calibration(NXcalibration): - exists: optional - doc: | - Calibration event on the energy axis. - - For XPS, the calibration should ideally be performed according to - `ISO 15472:2010`_ specification. - - .. _ISO 15472:2010: https://www.iso.org/standard/74811.html - applied(NX_BOOLEAN): - doc: | - Has an energy calibration been applied? - calibrated_axis(NX_FLOAT): - exists: recommended - doc: | - This is the calibrated energy axis to be used for data plotting. - angular_calibration(NXcalibration): - exists: optional - applied(NX_BOOLEAN): - doc: | - Has an angular calibration been applied? - calibrated_axis(NX_FLOAT): - exists: recommended - doc: | - This is the calibrated angular axis to be used for data plotting. - spatial_calibration(NXcalibration): - exists: optional - applied(NX_BOOLEAN): - doc: | - Has an spatial calibration been applied? - calibrated_axis(NX_FLOAT): - exists: recommended - doc: | - This is the calibrated spatial axis to be used for data plotting. - momentum_calibration(NXcalibration): - exists: optional - applied(NX_BOOLEAN): - doc: | - Has an momentum calibration been applied? - calibrated_axis(NX_FLOAT): - exists: recommended - doc: | - This is the momentum axis to be used for data plotting. - energy_referencing(NXcalibration): - exists: optional - doc: | - For energy referencing, the measured energies are corrected for the charging potential - (i.e., the electrical potential of the surface region of an insulating sample, caused by - irradiation) such that those energies correspond to a sample with no surface charge. - Usually, the energy axis is adjusted by shifting all energies uniformally until one - well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. - - Refers to Term `12.74`_ ff. of the ISO 18115-1:2023 specification. - - .. _12.74: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 - applied(NX_BOOLEAN): - doc: | - Have the energy axes been adjusted (e.g., in cases where samples are not - conductive)? - level(NXelectron_level): - exists: recommended - doc: | - Electronic core or valence level that was used for the calibration. - reference_peak: - doc: | - Reference peak that was used for the calibration. - - For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge - binding_energy(NX_FLOAT): - exists: recommended - doc: | - The binding energy (in units of eV) that the specified emission line appeared at, - after adjusting the binding energy scale. - - Refers to Term `12.16`_ ff. of the ISO 18115-1:2023 specification. - - .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - offset(NX_FLOAT): - exists: recommended - doc: | - Offset between measured binding energy and calibrated binding energy of the - emission line. - calibrated_axis(NX_FLOAT): - exists: recommended - doc: | - This is the calibrated energy axis to be used for data plotting. - - This should link to /entry/data/energy. - transmission_correction(NXcalibration): - exists: optional - doc: | - In the transmission correction, each intensity measurement for electrons of a given - kinetic energy is multiplied by the corresponding value in the relative_intensity - field of the transmission_function. This calibration procedure is used to account for - the different tranmsission efficiencies when using different lens modes. - applied(NX_BOOLEAN): - doc: | - Has an intensity calibration been applied? - - That is, has the transmission function of the analyser been taken into account? - mapping(NXdata): - exists: recommended - doc: | - Transmission function of the electron analyser. - - The transmission function (TF) specifies the detection efficiency for electrons of - different kinetic energy passing through the electron analyser. - This can be a link to /entry/instrument/electronanalyser/transmission_function. - \@signal: - enumeration: [relative_intensity] - \@axes: - enumeration: [kinetic_energy] - kinetic_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - Kinetic energy values - dimensions: - rank: 1 - dim: [[1, n_transmission_function]] - relative_intensity(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Relative transmission efficiency for the given kinetic energies - dimensions: - rank: 1 - dim: [[1, n_transmission_function]] - (NXsample): - name: - chemical_formula: - exists: recommended - doc: | - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - sample_history(NXnote): - exists: recommended - doc: | - 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. - atom_types: - exists: recommended - 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`. - physical_form: - exists: recommended - preparation_date(NX_DATE_TIME): - exists: recommended - doc: | - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - preparation_description(NXnote): - exists: optional - doc: | - 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. - temperature(NX_FLOAT): - unit: NX_TEMPERATURE - exists: recommended - doc: | - 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. - situation: - exists: optional - enumeration: [vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere] - gas_pressure(NX_FLOAT): - unit: NX_PRESSURE - exists: optional - bias(NX_FLOAT): - unit: NX_VOLTAGE - exists: optional - doc: | - Voltage applied to sample and sample holder. - (NXdata): - \@signal: - enumeration: [data] - data(NX_NUMBER): - unit: NX_ANY - doc: | - 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. - energy(NX_NUMBER): - exists: recommended - doc: | - Calibrated energy axis. - - The calibrated energy axis can be either in binding or kinetic energy. - This should be a link to either - /entry/process/energy_calibration/calibrated_axis or - /entry/process/energy_correction/calibrated_axis. - \@type: - type: NX_CHAR - exists: recommended - doc: | - The energy can be either stored as kinetic (Term `3.35`_ of the ISO 18115-1:2023 - specification) or as binding (Term `12.16`_) energy. - - .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 - .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - enumeration: - kinetic: - doc: | - Calibrated kinetic energy axis. - binding: - doc: | - Calibrated binding energy axis. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 83b124ee2d429df9b9b06b36c540fc64a4d9340e74cfebf03c9fc450257b6eb0 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays -# -# -# -# Number of data points in the transmission function. -# -# -# -# -# This is the most general application definition for multidimensional -# photoelectron spectroscopy. -# -# Groups and fields are named according to the -# `ISO 18115-1:2023`_ specification as well as the `IUPAC Recommendations 2020`_. -# -# .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html -# .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 -# -# -# -# -# -# -# -# -# -# -# -# Datetime of the start of the measurement. -# -# -# -# -# Datetime of the end of the measurement. -# -# -# -# -# A name of the experimental method according to `Clause 11`_ of -# the `ISO 18115-1:2023`_ specification. -# -# Examples include: -# * X-ray photoelectron spectroscopy (XPS) -# * angle-resolved X-ray photoelectron spectroscopy (ARXPS) -# * ultraviolet photoelectron spectroscopy (UPS) -# * angle-resolved photoelectron spectroscopy (ARPES) -# * hard X-ray photoemission spectroscopy (HAXPES) -# * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) -# * photoelectron emission microscopy (PEEM) -# * electron spectroscopy for chemical analysis (ESCA) -# -# .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html -# .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 -# -# -# -# -# Contact information of at least the user of the instrument or the investigator -# who performed this experiment. Adding multiple users if relevant is recommended. -# -# -# -# Name of the user. -# -# -# -# -# Name of the affiliation of the user at the point in time when the experiment was -# performed. -# -# -# -# -# Full address (street, street number, ZIP, city, country) of the user's -# affiliation. -# -# -# -# -# Email address of the user. -# -# -# -# -# Author ID defined by https://orcid.org/. -# -# -# -# -# -# MPES spectrometer -# -# Refers to Term `12.58`_ of the ISO 18115-1:2023 specification. -# -# .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 -# -# -# -# Overall energy resolution of the MPES instrument -# -# Refers to Terms `10.7`_ ff. and `10.24`_ of the ISO 18115-1:2023 specification. -# -# .. _10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 -# .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# 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. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Specification of type, may also go to name. -# -# -# -# -# -# Type of probe. In photoemission it's always photons, so the full NIAC list is -# restricted. -# -# -# -# -# -# -# -# -# -# -# -# -# The beam emitted by this source. -# Should be named with the same appendix, e.g., -# for `source_probe` it should refer to `beam_probe`. -# Refers to the same concept as /NXentry/NXinstrument/beam_TYPE -# and may be linked. -# -# -# -# -# -# -# -# The beam emitted by this source. -# Should be named with the same appendix, e.g., -# for `source_probe` it should refer to `beam_probe`. -# Refers to the same concept as /NXentry/NXinstrument/source_TYPE -# and may be linked. -# -# -# -# -# -# -# -# -# The source that emitted this beam. -# Should be named with the same appendix, e.g., -# for `beam_probe` it should refer to `source_probe`. -# Refers to the same concept as /NXentry/NXinstrument/source_TYPE -# and may be linked. -# -# -# -# -# -# -# -# -# -# -# -# -# Energy resolution of the analyser with the current setting. May be linked from a -# NXcalibration. -# -# Refers to Term `10.24`_ of the ISO 18115-1:2023 specification. -# -# .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 -# -# -# -# -# -# -# -# -# -# Scheme of the electron collection column. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Labelling of the lens setting in use. -# -# -# -# -# -# The size and position of the field aperture inserted in the column. To add -# additional or other apertures use the APERTURE group of NXcollectioncolumn. -# -# -# -# -# The size and position of the contrast aperture inserted in the column. To add -# additional or other apertures use the APERTURE group of NXcollectioncolumn. -# -# -# -# -# Size, position and shape of the iris inserted in the column. -# -# The iris is an aperture in the lens with a variable diameter which can reduce the number of -# electrons entering the analyzer. -# -# To add additional or other slits use the APERTURE group of NXcollectioncolumn. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Size, position and shape of the entrance slit in dispersive analyzers. -# -# To add additional or other slits use the APERTURE group of NXenergydispersion. -# -# -# -# -# Size, position and shape of the exit slit in dispersive analyzers. -# -# To add additional or other slits use the APERTURE group of NXenergydispersion. -# -# -# -# -# -# -# -# -# -# -# -# Type of electron amplifier in the first amplification step. -# -# -# -# -# -# -# -# -# Description of the detector type. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Raw data before calibration. -# -# -# -# -# -# -# -# Manipulator for positioning of the sample. -# -# -# -# -# -# Bias of the sample with respect to analyser ground. -# -# This field may also be found in NXsample if present. -# -# Refers to Term `8.41`_ of the ISO 18115-1:2023 specification. -# -# .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 -# -# -# -# -# -# -# -# -# -# -# -# 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 -# -# -# -# Calibration event on the energy axis. -# -# For XPS, the calibration should ideally be performed according to -# `ISO 15472:2010`_ specification. -# -# .. _ISO 15472:2010: https://www.iso.org/standard/74811.html -# -# -# -# Has an energy calibration been applied? -# -# -# -# -# This is the calibrated energy axis to be used for data plotting. -# -# -# -# -# -# -# Has an angular calibration been applied? -# -# -# -# -# This is the calibrated angular axis to be used for data plotting. -# -# -# -# -# -# -# Has an spatial calibration been applied? -# -# -# -# -# This is the calibrated spatial axis to be used for data plotting. -# -# -# -# -# -# -# Has an momentum calibration been applied? -# -# -# -# -# This is the momentum axis to be used for data plotting. -# -# -# -# -# -# For energy referencing, the measured energies are corrected for the charging potential -# (i.e., the electrical potential of the surface region of an insulating sample, caused by -# irradiation) such that those energies correspond to a sample with no surface charge. -# Usually, the energy axis is adjusted by shifting all energies uniformally until one -# well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. -# -# Refers to Term `12.74`_ ff. of the ISO 18115-1:2023 specification. -# -# .. _12.74: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 -# -# -# -# Have the energy axes been adjusted (e.g., in cases where samples are not -# conductive)? -# -# -# -# -# Electronic core or valence level that was used for the calibration. -# -# -# -# -# Reference peak that was used for the calibration. -# -# For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge -# -# -# -# -# The binding energy (in units of eV) that the specified emission line appeared at, -# after adjusting the binding energy scale. -# -# Refers to Term `12.16`_ ff. of the ISO 18115-1:2023 specification. -# -# .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 -# -# -# -# -# Offset between measured binding energy and calibrated binding energy of the -# emission line. -# -# -# -# -# This is the calibrated energy axis to be used for data plotting. -# -# This should link to /entry/data/energy. -# -# -# -# -# -# In the transmission correction, each intensity measurement for electrons of a given -# kinetic energy is multiplied by the corresponding value in the relative_intensity -# field of the transmission_function. This calibration procedure is used to account for -# the different tranmsission efficiencies when using different lens modes. -# -# -# -# Has an intensity calibration been applied? -# -# That is, has the transmission function of the analyser been taken into account? -# -# -# -# -# Transmission function of the electron analyser. -# -# The transmission function (TF) specifies the detection efficiency for electrons of -# different kinetic energy passing through the electron analyser. -# This can be a link to /entry/instrument/electronanalyser/transmission_function. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Kinetic energy values -# -# -# -# -# -# -# -# Relative transmission efficiency for the given kinetic energies -# -# -# -# -# -# -# -# -# -# -# -# -# The chemical formula of the sample. For mixtures use the NXsample_component -# group in NXsample instead. -# -# -# -# -# A descriptor to keep track of the treatment of the sample before entering the -# photoemission experiment. Ideally, a full report of the previous operations, in -# any format (NXnote allows to add pictures, audio, movies). Alternatively, a -# reference to the location or a unique identifier or other metadata file. In the -# case these are not available, free-text description. -# -# -# -# -# List of comma-separated elements from the periodic table -# that are contained in the sample. -# If the sample substance has multiple components, all -# elements from each component must be included in `atom_types`. -# -# -# -# -# -# Date of preparation of the sample for the XPS experiment (i.e. cleaving, last -# annealing). -# -# -# -# -# Description of the surface preparation technique for the XPS experiment, i.e. -# UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report -# of the previous operations, in any format(NXnote allows to add pictures, audio, -# movies). Alternatively, a reference to the location or a unique identifier or -# other metadata file. In the case these are not available, free-text description. -# -# -# -# -# In the case of a fixed temperature measurement this is the scalar temperature of -# the sample. In the case of an experiment in which the temperature is changed and -# recoded, this is an array of length m of temperatures. This should be a link to -# /entry/instrument/manipulator/sample_temperature. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Voltage applied to sample and sample holder. -# -# -# -# -# -# -# -# -# -# -# -# Represents a measure of one- or more-dimensional photoemission counts, where the -# varied axis may be for example energy, momentum, spatial coordinate, pump-probe -# delay, spin index, temperature, etc. The axes traces should be linked to the -# actual encoder position in NXinstrument or calibrated axes in NXprocess. -# -# -# -# -# Calibrated energy axis. -# -# The calibrated energy axis can be either in binding or kinetic energy. -# This should be a link to either -# /entry/process/energy_calibration/calibrated_axis or -# /entry/process/energy_correction/calibrated_axis. -# -# -# -# The energy can be either stored as kinetic (Term `3.35`_ of the ISO 18115-1:2023 -# specification) or as binding (Term `12.16`_) energy. -# -# .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 -# .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 -# -# -# -# -# Calibrated kinetic energy axis. -# -# -# -# -# Calibrated binding energy axis. -# -# -# -# -# -# -# -# +NXmpes(NXphotoemission): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXphotoemission.yaml b/contributed_definitions/nyaml/NXphotoemission.yaml new file mode 100644 index 0000000000..a2a13259e4 --- /dev/null +++ b/contributed_definitions/nyaml/NXphotoemission.yaml @@ -0,0 +1,1205 @@ +category: application +doc: | + This is the most general application definition for + photoemission experiments. + + Groups and fields are named according to the + `ISO 18115-1:2023`_ specification as well as the `IUPAC Recommendations 2020`_. + + .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays + n_transmission_function: | + Number of data points in the transmission function. +type: group +NXmpes(NXobject): + (NXentry): + definition: + \@version: + enumeration: [NXmpes] + title: + start_time(NX_DATE_TIME): + doc: | + Datetime of the start of the measurement. + end_time(NX_DATE_TIME): + exists: recommended + doc: | + Datetime of the end of the measurement. + method: + exists: recommended + doc: | + A name of the experimental method according to `Clause 11`_ of + the `ISO 18115-1:2023`_ specification. + + Examples include: + * X-ray photoelectron spectroscopy (XPS) + * angle-resolved X-ray photoelectron spectroscopy (ARXPS) + * ultraviolet photoelectron spectroscopy (UPS) + * angle-resolved photoelectron spectroscopy (ARPES) + * hard X-ray photoemission spectroscopy (HAXPES) + * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) + * photoelectron emission microscopy (PEEM) + * electron spectroscopy for chemical analysis (ESCA) + + .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 + (NXuser): + exists: recommended + doc: | + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + name: + doc: | + Name of the user. + affiliation: + doc: | + Name of the affiliation of the user at the point in time when the experiment was + performed. + (NXinstrument): + doc: | + MPES spectrometer + + Refers to Term `12.58`_ of the ISO 18115-1:2023 specification. + + .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 + energy_resolution(NXresolution): + exists: recommended + doc: | + Overall energy resolution of the MPES instrument + + Refers to Terms `10.7`_ ff. and `10.24`_ of the ISO 18115-1:2023 specification. + + .. _10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 + .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 + physical_quantity: + type: + resolution(NXdata): + magnitude(NX_FLOAT): + unit: NX_ENERGY + device_information(NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + source_TYPE(NXsource): + + # Comment from mpes may workshop: + # - There is much more information which can be provided for NXsource + doc: | + The source used to generate the primary photons. Properties refer strictly to + parameters of the source, not of the output beam. For example, the energy of the + source is not the optical power of the beam, but the energy of the electron beam + in a synchrotron and so on. + type: + enumeration: [Synchrotron X-ray Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, UV Plasma Source, Metal Jet X-ray, HHG laser, UV lamp, Monochromatized electron source, other] + type_other: + exists: optional + doc: | + Specification of type, may also go to name. + name: + exists: recommended + probe: + doc: | + Type of probe. In photoemission it's always photons, so the full NIAC list is + restricted. + enumeration: [photons] + device_information(NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + associated_beam(NXbeam): + doc: | + The beam emitted by this source. + Should be named with the same appendix, e.g., + for `source_probe` it should refer to `beam_probe`. + Refers to the same concept as /NXentry/NXinstrument/beam_TYPE + and may be linked. + + # It would be nice if we had the notion of linking in nexus or if + # we have a subdefinition NXlink to refer to a path. + # This would also be helpful for NXtransformations + beam_TYPE(NXbeam): + distance(NX_NUMBER): + unit: NX_LENGTH + exists: recommended + doc: | + The beam emitted by this source. + Should be named with the same appendix, e.g., + for `source_probe` it should refer to `beam_probe`. + Refers to the same concept as /NXentry/NXinstrument/source_TYPE + and may be linked. + incident_energy(NX_FLOAT): + unit: NX_ENERGY + incident_energy_spread(NX_NUMBER): + exists: recommended + unit: NX_ENERGY + incident_polarization(NX_NUMBER): + exists: recommended + unit: NX_ANY + extent(NX_FLOAT): + exists: recommended + associated_source(NXsource): + doc: | + The source that emitted this beam. + Should be named with the same appendix, e.g., + for `beam_probe` it should refer to `source_probe`. + Refers to the same concept as /NXentry/NXinstrument/source_TYPE + and may be linked. + (NXelectronanalyser): + device_information(NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + description: + energy_resolution(NX_FLOAT): + exists: recommended + unit: NX_ENERGY + doc: | + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. + + Refers to Term `10.24`_ of the ISO 18115-1:2023 specification. + + .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 + fast_axes: + exists: recommended + slow_axes: + exists: recommended + transmission_function(NX_FLOAT): + exists: optional + (NXcollectioncolumn): + + # TODO: Comment from Anders Frisk on proposal page + # What is the definition of a collection column? + # Optional constant settings (like lens focusing parameters on the sample: position_x, position_y, working_distance) + scheme: + doc: | + Scheme of the electron collection column. + enumeration: [Standard, Angular dispersive, Spatial dispersive, Selective area, Deflector, PEEM, Momentum Microscope] + mode: + exists: recommended + doc: | + Labelling of the lens setting in use. + projection: + exists: recommended + field_aperture(NXaperture): + exists: optional + doc: | + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + contrast_aperture(NXaperture): + exists: optional + doc: | + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + iris(NXaperture): + exists: optional + doc: | + Size, position and shape of the iris inserted in the column. + + The iris is an aperture in the lens with a variable diameter which can reduce the number of + electrons entering the analyzer. + + To add additional or other slits use the APERTURE group of NXcollectioncolumn. + device_information(NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + (NXenergydispersion): + scheme: + enumeration: [tof, hemispherical, double hemispherical, cylindrical mirror, display mirror, retarding grid] + pass_energy(NX_FLOAT): + unit: NX_ENERGY + energy_scan_mode: + entrance_slit(NXaperture): + exists: optional + doc: | + Size, position and shape of the entrance slit in dispersive analyzers. + + To add additional or other slits use the APERTURE group of NXenergydispersion. + exit_slit(NXaperture): + exists: optional + doc: | + Size, position and shape of the exit slit in dispersive analyzers. + + To add additional or other slits use the APERTURE group of NXenergydispersion. + device_information(NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + (NXdetector): + amplifier_type: + exists: recommended + doc: | + Type of electron amplifier in the first amplification step. + enumeration: [MCP, channeltron] + detector_type: + exists: recommended + doc: | + Description of the detector type. + enumeration: [DLD, Phosphor+CCD, Phosphor+CMOS, ECMOS, Anode, Multi-anode] + device_information(NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + (NXdata): + exists: recommended + \@signal: + enumeration: [raw] + raw(NX_NUMBER): + doc: | + Raw data before calibration. + (NXmanipulator): + exists: optional + doc: | + Manipulator for positioning of the sample. + sample_temperature(NX_FLOAT): + exists: recommended + unit: NX_TEMPERATURE + drain_current(NX_FLOAT): + exists: recommended + unit: NX_CURRENT + sample_bias(NX_FLOAT): + exists: recommended + unit: NX_CURRENT + doc: | + Bias of the sample with respect to analyser ground. + + This field may also be found in NXsample if present. + + Refers to Term `8.41`_ of the ISO 18115-1:2023 specification. + + .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 + device_information(NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + (NXprocess): + exists: recommended + doc: | + 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 + energy_calibration(NXcalibration): + exists: optional + doc: | + Calibration event on the energy axis. + + For XPS, the calibration should ideally be performed according to + `ISO 15472:2010`_ specification. + + .. _ISO 15472:2010: https://www.iso.org/standard/74811.html + applied(NX_BOOLEAN): + doc: | + Has an energy calibration been applied? + calibrated_axis(NX_FLOAT): + exists: recommended + doc: | + This is the calibrated energy axis to be used for data plotting. + angular_calibration(NXcalibration): + exists: optional + applied(NX_BOOLEAN): + doc: | + Has an angular calibration been applied? + calibrated_axis(NX_FLOAT): + exists: recommended + doc: | + This is the calibrated angular axis to be used for data plotting. + spatial_calibration(NXcalibration): + exists: optional + applied(NX_BOOLEAN): + doc: | + Has an spatial calibration been applied? + calibrated_axis(NX_FLOAT): + exists: recommended + doc: | + This is the calibrated spatial axis to be used for data plotting. + momentum_calibration(NXcalibration): + exists: optional + applied(NX_BOOLEAN): + doc: | + Has an momentum calibration been applied? + calibrated_axis(NX_FLOAT): + exists: recommended + doc: | + This is the momentum axis to be used for data plotting. + energy_referencing(NXcalibration): + exists: optional + doc: | + For energy referencing, the measured energies are corrected for the charging potential + (i.e., the electrical potential of the surface region of an insulating sample, caused by + irradiation) such that those energies correspond to a sample with no surface charge. + Usually, the energy axis is adjusted by shifting all energies uniformally until one + well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. + + Refers to Term `12.74`_ ff. of the ISO 18115-1:2023 specification. + + .. _12.74: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 + applied(NX_BOOLEAN): + doc: | + Have the energy axes been adjusted (e.g., in cases where samples are not + conductive)? + level(NXelectron_level): + exists: recommended + doc: | + Electronic core or valence level that was used for the calibration. + reference_peak: + doc: | + Reference peak that was used for the calibration. + + For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge + binding_energy(NX_FLOAT): + exists: recommended + doc: | + The binding energy (in units of eV) that the specified emission line appeared at, + after adjusting the binding energy scale. + + Refers to Term `12.16`_ ff. of the ISO 18115-1:2023 specification. + + .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + offset(NX_FLOAT): + exists: recommended + doc: | + Offset between measured binding energy and calibrated binding energy of the + emission line. + calibrated_axis(NX_FLOAT): + exists: recommended + doc: | + This is the calibrated energy axis to be used for data plotting. + + This should link to /entry/data/energy. + transmission_correction(NXcalibration): + exists: optional + doc: | + In the transmission correction, each intensity measurement for electrons of a given + kinetic energy is multiplied by the corresponding value in the relative_intensity + field of the transmission_function. This calibration procedure is used to account for + the different tranmsission efficiencies when using different lens modes. + applied(NX_BOOLEAN): + doc: | + Has an intensity calibration been applied? + + That is, has the transmission function of the analyser been taken into account? + mapping(NXdata): + exists: recommended + doc: | + Transmission function of the electron analyser. + + The transmission function (TF) specifies the detection efficiency for electrons of + different kinetic energy passing through the electron analyser. + This can be a link to /entry/instrument/electronanalyser/transmission_function. + \@signal: + enumeration: [relative_intensity] + \@axes: + enumeration: [kinetic_energy] + kinetic_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + Kinetic energy values + dimensions: + rank: 1 + dim: [[1, n_transmission_function]] + relative_intensity(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Relative transmission efficiency for the given kinetic energies + dimensions: + rank: 1 + dim: [[1, n_transmission_function]] + (NXsample): + name: + chemical_formula: + exists: recommended + doc: | + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + sample_history(NXnote): + exists: recommended + doc: | + 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. + atom_types: + exists: recommended + 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`. + physical_form: + exists: recommended + preparation_date(NX_DATE_TIME): + exists: recommended + doc: | + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). + preparation_description(NXnote): + exists: optional + doc: | + 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. + temperature(NX_FLOAT): + unit: NX_TEMPERATURE + exists: recommended + doc: | + 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. + situation: + exists: optional + enumeration: [vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere] + gas_pressure(NX_FLOAT): + unit: NX_PRESSURE + exists: optional + bias(NX_FLOAT): + unit: NX_VOLTAGE + exists: optional + doc: | + Voltage applied to sample and sample holder. + (NXdata): + \@signal: + enumeration: [data] + data(NX_NUMBER): + unit: NX_ANY + doc: | + 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. + energy(NX_NUMBER): + exists: recommended + doc: | + Calibrated energy axis. + + The calibrated energy axis can be either in binding or kinetic energy. + This should be a link to either + /entry/process/energy_calibration/calibrated_axis or + /entry/process/energy_correction/calibrated_axis. + \@type: + type: NX_CHAR + exists: recommended + doc: | + The energy can be either stored as kinetic (Term `3.35`_ of the ISO 18115-1:2023 + specification) or as binding (Term `12.16`_) energy. + + .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 + .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + enumeration: + kinetic: + doc: | + Calibrated kinetic energy axis. + binding: + doc: | + Calibrated binding energy axis. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 83b124ee2d429df9b9b06b36c540fc64a4d9340e74cfebf03c9fc450257b6eb0 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays +# +# +# +# Number of data points in the transmission function. +# +# +# +# +# This is the most general application definition for multidimensional +# photoelectron spectroscopy. +# +# Groups and fields are named according to the +# `ISO 18115-1:2023`_ specification as well as the `IUPAC Recommendations 2020`_. +# +# .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html +# .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 +# +# +# +# +# +# +# +# +# +# +# +# Datetime of the start of the measurement. +# +# +# +# +# Datetime of the end of the measurement. +# +# +# +# +# A name of the experimental method according to `Clause 11`_ of +# the `ISO 18115-1:2023`_ specification. +# +# Examples include: +# * X-ray photoelectron spectroscopy (XPS) +# * angle-resolved X-ray photoelectron spectroscopy (ARXPS) +# * ultraviolet photoelectron spectroscopy (UPS) +# * angle-resolved photoelectron spectroscopy (ARPES) +# * hard X-ray photoemission spectroscopy (HAXPES) +# * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) +# * photoelectron emission microscopy (PEEM) +# * electron spectroscopy for chemical analysis (ESCA) +# +# .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html +# .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 +# +# +# +# +# Contact information of at least the user of the instrument or the investigator +# who performed this experiment. Adding multiple users if relevant is recommended. +# +# +# +# Name of the user. +# +# +# +# +# Name of the affiliation of the user at the point in time when the experiment was +# performed. +# +# +# +# +# Full address (street, street number, ZIP, city, country) of the user's +# affiliation. +# +# +# +# +# Email address of the user. +# +# +# +# +# Author ID defined by https://orcid.org/. +# +# +# +# +# +# MPES spectrometer +# +# Refers to Term `12.58`_ of the ISO 18115-1:2023 specification. +# +# .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 +# +# +# +# Overall energy resolution of the MPES instrument +# +# Refers to Terms `10.7`_ ff. and `10.24`_ of the ISO 18115-1:2023 specification. +# +# .. _10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 +# .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# 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. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Specification of type, may also go to name. +# +# +# +# +# +# Type of probe. In photoemission it's always photons, so the full NIAC list is +# restricted. +# +# +# +# +# +# +# +# +# +# +# +# +# The beam emitted by this source. +# Should be named with the same appendix, e.g., +# for `source_probe` it should refer to `beam_probe`. +# Refers to the same concept as /NXentry/NXinstrument/beam_TYPE +# and may be linked. +# +# +# +# +# +# +# +# The beam emitted by this source. +# Should be named with the same appendix, e.g., +# for `source_probe` it should refer to `beam_probe`. +# Refers to the same concept as /NXentry/NXinstrument/source_TYPE +# and may be linked. +# +# +# +# +# +# +# +# +# The source that emitted this beam. +# Should be named with the same appendix, e.g., +# for `beam_probe` it should refer to `source_probe`. +# Refers to the same concept as /NXentry/NXinstrument/source_TYPE +# and may be linked. +# +# +# +# +# +# +# +# +# +# +# +# +# Energy resolution of the analyser with the current setting. May be linked from a +# NXcalibration. +# +# Refers to Term `10.24`_ of the ISO 18115-1:2023 specification. +# +# .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 +# +# +# +# +# +# +# +# +# +# Scheme of the electron collection column. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Labelling of the lens setting in use. +# +# +# +# +# +# The size and position of the field aperture inserted in the column. To add +# additional or other apertures use the APERTURE group of NXcollectioncolumn. +# +# +# +# +# The size and position of the contrast aperture inserted in the column. To add +# additional or other apertures use the APERTURE group of NXcollectioncolumn. +# +# +# +# +# Size, position and shape of the iris inserted in the column. +# +# The iris is an aperture in the lens with a variable diameter which can reduce the number of +# electrons entering the analyzer. +# +# To add additional or other slits use the APERTURE group of NXcollectioncolumn. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Size, position and shape of the entrance slit in dispersive analyzers. +# +# To add additional or other slits use the APERTURE group of NXenergydispersion. +# +# +# +# +# Size, position and shape of the exit slit in dispersive analyzers. +# +# To add additional or other slits use the APERTURE group of NXenergydispersion. +# +# +# +# +# +# +# +# +# +# +# +# Type of electron amplifier in the first amplification step. +# +# +# +# +# +# +# +# +# Description of the detector type. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Raw data before calibration. +# +# +# +# +# +# +# +# Manipulator for positioning of the sample. +# +# +# +# +# +# Bias of the sample with respect to analyser ground. +# +# This field may also be found in NXsample if present. +# +# Refers to Term `8.41`_ of the ISO 18115-1:2023 specification. +# +# .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 +# +# +# +# +# +# +# +# +# +# +# +# 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 +# +# +# +# Calibration event on the energy axis. +# +# For XPS, the calibration should ideally be performed according to +# `ISO 15472:2010`_ specification. +# +# .. _ISO 15472:2010: https://www.iso.org/standard/74811.html +# +# +# +# Has an energy calibration been applied? +# +# +# +# +# This is the calibrated energy axis to be used for data plotting. +# +# +# +# +# +# +# Has an angular calibration been applied? +# +# +# +# +# This is the calibrated angular axis to be used for data plotting. +# +# +# +# +# +# +# Has an spatial calibration been applied? +# +# +# +# +# This is the calibrated spatial axis to be used for data plotting. +# +# +# +# +# +# +# Has an momentum calibration been applied? +# +# +# +# +# This is the momentum axis to be used for data plotting. +# +# +# +# +# +# For energy referencing, the measured energies are corrected for the charging potential +# (i.e., the electrical potential of the surface region of an insulating sample, caused by +# irradiation) such that those energies correspond to a sample with no surface charge. +# Usually, the energy axis is adjusted by shifting all energies uniformally until one +# well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. +# +# Refers to Term `12.74`_ ff. of the ISO 18115-1:2023 specification. +# +# .. _12.74: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 +# +# +# +# Have the energy axes been adjusted (e.g., in cases where samples are not +# conductive)? +# +# +# +# +# Electronic core or valence level that was used for the calibration. +# +# +# +# +# Reference peak that was used for the calibration. +# +# For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge +# +# +# +# +# The binding energy (in units of eV) that the specified emission line appeared at, +# after adjusting the binding energy scale. +# +# Refers to Term `12.16`_ ff. of the ISO 18115-1:2023 specification. +# +# .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 +# +# +# +# +# Offset between measured binding energy and calibrated binding energy of the +# emission line. +# +# +# +# +# This is the calibrated energy axis to be used for data plotting. +# +# This should link to /entry/data/energy. +# +# +# +# +# +# In the transmission correction, each intensity measurement for electrons of a given +# kinetic energy is multiplied by the corresponding value in the relative_intensity +# field of the transmission_function. This calibration procedure is used to account for +# the different tranmsission efficiencies when using different lens modes. +# +# +# +# Has an intensity calibration been applied? +# +# That is, has the transmission function of the analyser been taken into account? +# +# +# +# +# Transmission function of the electron analyser. +# +# The transmission function (TF) specifies the detection efficiency for electrons of +# different kinetic energy passing through the electron analyser. +# This can be a link to /entry/instrument/electronanalyser/transmission_function. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Kinetic energy values +# +# +# +# +# +# +# +# Relative transmission efficiency for the given kinetic energies +# +# +# +# +# +# +# +# +# +# +# +# +# The chemical formula of the sample. For mixtures use the NXsample_component +# group in NXsample instead. +# +# +# +# +# A descriptor to keep track of the treatment of the sample before entering the +# photoemission experiment. Ideally, a full report of the previous operations, in +# any format (NXnote allows to add pictures, audio, movies). Alternatively, a +# reference to the location or a unique identifier or other metadata file. In the +# case these are not available, free-text description. +# +# +# +# +# List of comma-separated elements from the periodic table +# that are contained in the sample. +# If the sample substance has multiple components, all +# elements from each component must be included in `atom_types`. +# +# +# +# +# +# Date of preparation of the sample for the XPS experiment (i.e. cleaving, last +# annealing). +# +# +# +# +# Description of the surface preparation technique for the XPS experiment, i.e. +# UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report +# of the previous operations, in any format(NXnote allows to add pictures, audio, +# movies). Alternatively, a reference to the location or a unique identifier or +# other metadata file. In the case these are not available, free-text description. +# +# +# +# +# In the case of a fixed temperature measurement this is the scalar temperature of +# the sample. In the case of an experiment in which the temperature is changed and +# recoded, this is an array of length m of temperatures. This should be a link to +# /entry/instrument/manipulator/sample_temperature. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Voltage applied to sample and sample holder. +# +# +# +# +# +# +# +# +# +# +# +# Represents a measure of one- or more-dimensional photoemission counts, where the +# varied axis may be for example energy, momentum, spatial coordinate, pump-probe +# delay, spin index, temperature, etc. The axes traces should be linked to the +# actual encoder position in NXinstrument or calibrated axes in NXprocess. +# +# +# +# +# Calibrated energy axis. +# +# The calibrated energy axis can be either in binding or kinetic energy. +# This should be a link to either +# /entry/process/energy_calibration/calibrated_axis or +# /entry/process/energy_correction/calibrated_axis. +# +# +# +# The energy can be either stored as kinetic (Term `3.35`_ of the ISO 18115-1:2023 +# specification) or as binding (Term `12.16`_) energy. +# +# .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 +# .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 +# +# +# +# +# Calibrated kinetic energy axis. +# +# +# +# +# Calibrated binding energy axis. +# +# +# +# +# +# +# +# From c5c7427829810e61e8c1fd67dc95aea8e878e644 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 11 Oct 2023 12:52:41 +0200 Subject: [PATCH 0327/1012] Change name to NXphotoemission --- contributed_definitions/NXphotoemission.nxdl.xml | 2 +- contributed_definitions/nyaml/NXphotoemission.yaml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/NXphotoemission.nxdl.xml b/contributed_definitions/NXphotoemission.nxdl.xml index 2e95d71b31..db8a2bac10 100644 --- a/contributed_definitions/NXphotoemission.nxdl.xml +++ b/contributed_definitions/NXphotoemission.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + The symbols used in the schema to specify e.g. dimensions of arrays diff --git a/contributed_definitions/nyaml/NXphotoemission.yaml b/contributed_definitions/nyaml/NXphotoemission.yaml index a2a13259e4..a6d934cbde 100644 --- a/contributed_definitions/nyaml/NXphotoemission.yaml +++ b/contributed_definitions/nyaml/NXphotoemission.yaml @@ -14,7 +14,7 @@ symbols: n_transmission_function: | Number of data points in the transmission function. type: group -NXmpes(NXobject): +NXphotoemission(NXobject): (NXentry): definition: \@version: From bd6b13afd6c8938eaf9780d2d5c1dc9031a6e8d7 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 18 Oct 2023 15:55:46 +0200 Subject: [PATCH 0328/1012] Adds photon to NXsource and make probe in NXsource optional --- base_classes/nyaml/NXsource.yaml | 2 +- contributed_definitions/nyaml/NXmpes.yaml | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/base_classes/nyaml/NXsource.yaml b/base_classes/nyaml/NXsource.yaml index 6e275f7535..cfd70ed2b3 100644 --- a/base_classes/nyaml/NXsource.yaml +++ b/base_classes/nyaml/NXsource.yaml @@ -22,7 +22,7 @@ NXsource(NXobject): probe: doc: | type of radiation probe (pick one from the enumerated list and spell exactly) - enumeration: [neutron, x-ray, muon, electron, ultraviolet, visible light, positron, proton] + enumeration: [neutron, photon, x-ray, muon, electron, ultraviolet, visible light, positron, proton] power(NX_FLOAT): unit: NX_POWER doc: | diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 3e5577321f..a038824adf 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -107,7 +107,8 @@ NXmpes(NXobject): doc: | Type of probe. In photoemission it's always photons, so the full NIAC list is restricted. - enumeration: [photons] + exists: optional + enumeration: [photon, x-ray, visible light, ultraviolet] device_information(NXfabrication): exists: recommended vendor: From cc3b9a6712eddf531c1d38b7b35ea0d69f8d2272 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 18 Oct 2023 15:57:52 +0200 Subject: [PATCH 0329/1012] Adds partial to NXroot --- base_classes/nyaml/NXroot.yaml | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/base_classes/nyaml/NXroot.yaml b/base_classes/nyaml/NXroot.yaml index bcecfaa0a8..b585885ac8 100644 --- a/base_classes/nyaml/NXroot.yaml +++ b/base_classes/nyaml/NXroot.yaml @@ -27,6 +27,12 @@ NXroot(NXobject): Only used when the NAPI has written the file. Note that this is different from the version of the base class or application definition version number. + \@partial: + doc: | + A list of concepts in an application definition this file describes. + This is for partially filling an application definition. + If this attribute is not present the application definition is assumed + to be valid, if not the specified concepts/paths are assumed to be valid. \@HDF_version: doc: | Version of HDF (version 4) library used in writing the file From b874c61522b1378867397f8078859d282a827a35 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 18 Oct 2023 15:59:44 +0200 Subject: [PATCH 0330/1012] Create nxdls --- base_classes/NXroot.nxdl.xml | 123 ++++++++++++++---------- base_classes/NXsource.nxdl.xml | 1 + contributed_definitions/NXmpes.nxdl.xml | 7 +- 3 files changed, 79 insertions(+), 52 deletions(-) diff --git a/base_classes/NXroot.nxdl.xml b/base_classes/NXroot.nxdl.xml index 54c432c794..75a3753796 100644 --- a/base_classes/NXroot.nxdl.xml +++ b/base_classes/NXroot.nxdl.xml @@ -1,10 +1,10 @@ - + - - Definition of the root NeXus group. + + + Definition of the root NeXus group. + - The root of any NeXus data file is an ``NXroot`` class - (no other choice is allowed for a valid NeXus data file). - This attribute cements that definition. + The root of any NeXus data file is an ``NXroot`` class + (no other choice is allowed for a valid NeXus data file). + This attribute cements that definition. - + - Date and time file was originally created + + Date and time file was originally created + - File name of original NeXus file + + File name of original NeXus file + - Date and time of last file change at close + + Date and time of last file change at close + - Version of NeXus API used in writing the file. - - Only used when the NAPI has written the file. - Note that this is different from the version of the - base class or application definition version number. + Version of NeXus API used in writing the file. + + Only used when the NAPI has written the file. + Note that this is different from the version of the + base class or application definition version number. + + + + + A list of concepts in an application definition this file describes. + This is for partially filling an application definition. + If this attribute is not present the application definition is assumed + to be valid, if not the specified concepts/paths are assumed to be valid. - Version of HDF (version 4) library used in writing the file + + Version of HDF (version 4) library used in writing the file + - Version of HDF5 library used in writing the file. - - Note this attribute is spelled with uppercase "V", - different than other version attributes. + Version of HDF5 library used in writing the file. + + Note this attribute is spelled with uppercase "V", + different than other version attributes. - Version of XML support library used in writing the XML file + + Version of XML support library used in writing the XML file + - Version of h5py Python package used in writing the file + + Version of h5py Python package used in writing the file + - facility or program where file originated + + facility or program where file originated + - Version of facility or program used in writing the file + + Version of facility or program used in writing the file + - - entries + + + entries + - .. index:: find the default plottable data - .. index:: plotting - .. index:: default attribute value - - Declares which :ref:`NXentry` group contains - the data to be shown by default. - It is used to resolve ambiguity when - more than one :ref:`NXentry` group exists. - The value :ref:`names <validItemName>` the default :ref:`NXentry` group. The - value must be the name of a child of the current group. The child must be a - NeXus group or a link to a NeXus group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: find the default plottable data + .. index:: plotting + .. index:: default attribute value + + Declares which :ref:`NXentry` group contains + the data to be shown by default. + It is used to resolve ambiguity when + more than one :ref:`NXentry` group exists. + The value :ref:`names <validItemName>` the default :ref:`NXentry` group. The + value must be the name of a child of the current group. The child must be a + NeXus group or a link to a NeXus group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. - diff --git a/base_classes/NXsource.nxdl.xml b/base_classes/NXsource.nxdl.xml index a291384d3f..e25ad34d21 100644 --- a/base_classes/NXsource.nxdl.xml +++ b/base_classes/NXsource.nxdl.xml @@ -68,6 +68,7 @@ + diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 6b4f315974..f7282a58a5 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -155,13 +155,16 @@ - + Type of probe. In photoemission it's always photons, so the full NIAC list is restricted. - + + + + From cd74ec848c046b2e96265e14b02322abd5385c76 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 24 Oct 2023 11:56:40 +0200 Subject: [PATCH 0331/1012] Use all capital MAPPING in NXcalibration for now This should be refactored once we have a SAME_AS field. --- contributed_definitions/NXcalibration.nxdl.xml | 4 ++-- contributed_definitions/nyaml/NXcalibration.yaml | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml index 700506294d..5c4aa73f84 100644 --- a/contributed_definitions/NXcalibration.nxdl.xml +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -113,11 +113,11 @@ File containing the input data for calibration. - + Mapping data for calibration. - This can be used to map data points from uncalibrated + This can be used to map data points from uncalibrated to calibrated values, e.g., by multiplying each point by the corresponding point in the mapping data. diff --git a/contributed_definitions/nyaml/NXcalibration.yaml b/contributed_definitions/nyaml/NXcalibration.yaml index 6c4266cb2b..99fc6246fc 100644 --- a/contributed_definitions/nyaml/NXcalibration.yaml +++ b/contributed_definitions/nyaml/NXcalibration.yaml @@ -65,7 +65,7 @@ NXcalibration(NXobject): calibration_file(NXnote): doc: | File containing the input data for calibration. - mapping(NXdata): + MAPPING(NXdata): doc: | Mapping data for calibration. From 06ed85da02be0efa68c9e16de18a3ad4202e60c0 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 25 Oct 2023 17:44:18 +0200 Subject: [PATCH 0332/1012] Add to NXmpes_instrument (issue #85) - Add an NXtransformation to NXenergydispersion - Allow for torroidal analyzers - Allow for multiple angular resolutions -> solved by resolution(NXdata) in NXresolution. --- .../nyaml/NXenergydispersion.yaml | 16 ++++++++++++++++ contributed_definitions/nyaml/NXmpes.yaml | 2 +- 2 files changed, 17 insertions(+), 1 deletion(-) diff --git a/contributed_definitions/nyaml/NXenergydispersion.yaml b/contributed_definitions/nyaml/NXenergydispersion.yaml index d8f8928b20..321e2b5921 100644 --- a/contributed_definitions/nyaml/NXenergydispersion.yaml +++ b/contributed_definitions/nyaml/NXenergydispersion.yaml @@ -57,6 +57,22 @@ NXenergydispersion(NXobject): doc: | Individual lenses in the energy dispersive section (NXfabrication): + (NXtransformations): + depends_on(NX_CHAR): + doc: | + Refers to the last transformation specifying the positon of the energy dispersive + element in the NXtransformations chain. + (NXtransformations): + doc: | + Collection of axis-based translations and rotations to describe the location and + geometry of the energy dispersive element as a component in the instrument. + Conventions from the NXtransformations base class are used. In principle, + the McStas coordinate system is used. The first transformation has to point + either to another component of the system or . (for pointing to the reference frame) + to relate it relative to the experimental setup. Typically, the components of a system + should all be related relative to each other and only one component should relate to + the reference coordinate system. + # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ # a7c091a51010429013f48d991cc94b512185629c0261c3188f4692ba3fbaf8b4 diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index a038824adf..1a6ecededc 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -189,7 +189,7 @@ NXmpes(NXobject): scheme: doc: | Scheme of the electron collection column. - enumeration: [Standard, Angular dispersive, Spatial dispersive, Selective area, Deflector, PEEM, Momentum Microscope] + enumeration: [Standard, Angular dispersive, Spatial dispersive, Selective area, Deflector, PEEM, Momentum Microscope, torroidal] mode: exists: recommended doc: | From 2900715e05bf22095428a00a1a0ce4d103bf96ae Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 25 Oct 2023 17:46:46 +0200 Subject: [PATCH 0333/1012] Modify NXsource base class docstring --- base_classes/nyaml/NXsource.yaml | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/base_classes/nyaml/NXsource.yaml b/base_classes/nyaml/NXsource.yaml index cfd70ed2b3..4bcbc1f640 100644 --- a/base_classes/nyaml/NXsource.yaml +++ b/base_classes/nyaml/NXsource.yaml @@ -1,6 +1,9 @@ category: base doc: | - The neutron or x-ray storage ring/facility. + Radiation source emitting a beam. + + Examples include particle sources (electrons, neutrons, protons) or sources for electromagnetic radation (photons). + type: group NXsource(NXobject): distance(NX_FLOAT): From 58affe316ee7bc7d297d717af1917645402cd378 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 25 Oct 2023 17:48:52 +0200 Subject: [PATCH 0334/1012] Make NXDLs --- base_classes/NXsource.nxdl.xml | 4 +++- contributed_definitions/NXenergydispersion.nxdl.xml | 12 ++++++++++++ contributed_definitions/NXmpes.nxdl.xml | 1 + 3 files changed, 16 insertions(+), 1 deletion(-) diff --git a/base_classes/NXsource.nxdl.xml b/base_classes/NXsource.nxdl.xml index e25ad34d21..dede03ed1d 100644 --- a/base_classes/NXsource.nxdl.xml +++ b/base_classes/NXsource.nxdl.xml @@ -23,7 +23,9 @@ --> - The neutron or x-ray storage ring/facility. + Radiation source emitting a beam. + + Examples include particle sources (electrons, neutrons, protons) or sources for electromagnetic radation (photons). diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml index ead97311db..2624251597 100644 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ b/contributed_definitions/NXenergydispersion.nxdl.xml @@ -97,4 +97,16 @@ + + + Collection of axis-based translations and rotations to describe the location and + geometry of the energy dispersive element as a component in the instrument. + Conventions from the NXtransformations base class are used. In principle, + the McStas coordinate system is used. The first transformation has to point + either to another component of the system or . (for pointing to the reference frame) + to relate it relative to the experimental setup. Typically, the components of a system + should all be related relative to each other and only one component should relate to + the reference coordinate system. + + diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index f7282a58a5..93286339e6 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -245,6 +245,7 @@ Optional constant settings (like lens focusing parameters on the sample: positio + From 710c3208c70fc6ea545ffe88ff91cc3a3ee97f18 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 25 Oct 2023 17:52:41 +0200 Subject: [PATCH 0335/1012] make nyamls --- base_classes/nyaml/NXroot.yaml | 125 +++++++++++------- base_classes/nyaml/NXsource.yaml | 10 +- .../nyaml/NXcalibration.yaml | 6 +- .../nyaml/NXenergydispersion.yaml | 28 ++-- contributed_definitions/nyaml/NXmpes.yaml | 30 ++--- 5 files changed, 109 insertions(+), 90 deletions(-) diff --git a/base_classes/nyaml/NXroot.yaml b/base_classes/nyaml/NXroot.yaml index b585885ac8..efdb9971ff 100644 --- a/base_classes/nyaml/NXroot.yaml +++ b/base_classes/nyaml/NXroot.yaml @@ -78,14 +78,14 @@ NXroot(NXobject): for a summary of the discussion. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 00ad60c31b3087963764958288477d30afe61c6888f025264db3cfb53f1068c1 +# 076e6c02e65767061d84e6f18bdef2d2caaf1c555f8ce414fd5744e68cc3685c # -# +# # -# -# Definition of the root NeXus group. +# +# +# Definition of the root NeXus group. +# # # -# The root of any NeXus data file is an ``NXroot`` class -# (no other choice is allowed for a valid NeXus data file). -# This attribute cements that definition. +# The root of any NeXus data file is an ``NXroot`` class +# (no other choice is allowed for a valid NeXus data file). +# This attribute cements that definition. # # -# +# # # # -# Date and time file was originally created +# +# Date and time file was originally created +# # # -# File name of original NeXus file +# +# File name of original NeXus file +# # # -# Date and time of last file change at close +# +# Date and time of last file change at close +# # # # -# Version of NeXus API used in writing the file. -# -# Only used when the NAPI has written the file. -# Note that this is different from the version of the -# base class or application definition version number. +# Version of NeXus API used in writing the file. +# +# Only used when the NAPI has written the file. +# Note that this is different from the version of the +# base class or application definition version number. +# +# +# +# +# A list of concepts in an application definition this file describes. +# This is for partially filling an application definition. +# If this attribute is not present the application definition is assumed +# to be valid, if not the specified concepts/paths are assumed to be valid. # # # -# Version of HDF (version 4) library used in writing the file +# +# Version of HDF (version 4) library used in writing the file +# # # # -# Version of HDF5 library used in writing the file. -# -# Note this attribute is spelled with uppercase "V", -# different than other version attributes. +# Version of HDF5 library used in writing the file. +# +# Note this attribute is spelled with uppercase "V", +# different than other version attributes. # # # -# Version of XML support library used in writing the XML file +# +# Version of XML support library used in writing the XML file +# # # -# Version of h5py Python package used in writing the file +# +# Version of h5py Python package used in writing the file +# # # -# facility or program where file originated +# +# facility or program where file originated +# # # -# Version of facility or program used in writing the file +# +# Version of facility or program used in writing the file +# # -# -# entries +# +# +# entries +# # # # -# .. index:: find the default plottable data -# .. index:: plotting -# .. index:: default attribute value -# -# Declares which :ref:`NXentry` group contains -# the data to be shown by default. -# It is used to resolve ambiguity when -# more than one :ref:`NXentry` group exists. -# The value :ref:`names <validItemName>` the default :ref:`NXentry` group. The -# value must be the name of a child of the current group. The child must be a -# NeXus group or a link to a NeXus group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. +# .. index:: find the default plottable data +# .. index:: plotting +# .. index:: default attribute value +# +# Declares which :ref:`NXentry` group contains +# the data to be shown by default. +# It is used to resolve ambiguity when +# more than one :ref:`NXentry` group exists. +# The value :ref:`names <validItemName>` the default :ref:`NXentry` group. The +# value must be the name of a child of the current group. The child must be a +# NeXus group or a link to a NeXus group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. # # # -# diff --git a/base_classes/nyaml/NXsource.yaml b/base_classes/nyaml/NXsource.yaml index 4bcbc1f640..a9a6035c4c 100644 --- a/base_classes/nyaml/NXsource.yaml +++ b/base_classes/nyaml/NXsource.yaml @@ -1,9 +1,8 @@ category: base doc: | Radiation source emitting a beam. - + Examples include particle sources (electrons, neutrons, protons) or sources for electromagnetic radation (photons). - type: group NXsource(NXobject): distance(NX_FLOAT): @@ -206,7 +205,7 @@ NXsource(NXobject): other component groups. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 248872a89ab8cb9c738d47d23b9cf7fa50bac04b2beb1428f677ec9ec23fc29b +# 81bbad2d2d7f3bbecb78610a117d3a40a45be96101c9d07cbb30d30d58eeaf45 # # # # # -# The neutron or x-ray storage ring/facility. +# Radiation source emitting a beam. +# +# Examples include particle sources (electrons, neutrons, protons) or sources for electromagnetic radation (photons). # # # @@ -277,6 +278,7 @@ NXsource(NXobject): # # # +# # # # diff --git a/contributed_definitions/nyaml/NXcalibration.yaml b/contributed_definitions/nyaml/NXcalibration.yaml index 99fc6246fc..73e8cc3c7e 100644 --- a/contributed_definitions/nyaml/NXcalibration.yaml +++ b/contributed_definitions/nyaml/NXcalibration.yaml @@ -74,7 +74,7 @@ NXcalibration(NXobject): corresponding point in the mapping data. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 307fdbe810f63da8d54f0ba5281847e4809c5f4e9baaa07994793462797acdf6 +# 21c19234fb652a2b69a595f90b67aaf60b48369b8dfa378bb4440e516c389dc4 # # # + Calibrated energy axis. - The calibrated energy axis can be either in binding or kinetic energy. - This should be a link to either + This could be a link to either /entry/process/energy_calibration/calibrated_axis or /entry/process/energy_correction/calibrated_axis. - + The energy can be either stored as kinetic (Term `3.35`_ of the ISO 18115-1:2023 specification) or as binding (Term `12.16`_) energy. @@ -649,11 +723,49 @@ Optional constant settings (like lens focusing parameters on the sample: positio Calibrated kinetic energy axis. - - - Calibrated binding energy axis. - - + + + + Calibrated binding energy axis. + + + + + + + Calibrated x axis in k-space. + Units are 1/Angström. + + + + + Calibrated y axis in k-space. + Units are 1/Angström + + + + + Calibrated k axis in k-space. + Units are 1/Angström. + + + + + Calibrated delay time. + + + + + Polarization of the incoming beam. + + Can be any of linear polarization angle (degrees), ellipticity (arb. units). + Could be a link to /entry/instrument/beam/incident_polarization or + /entry/instrument/beam/final_polarization if they exist. + + + + + diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index b057c02035..22d1afc364 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -275,6 +275,54 @@ NXmpes(NXobject): raw(NX_NUMBER): doc: | Raw data before calibration. + energy_raw(NX_NUMBER): + exists: recommended + unit: NX_ANY + doc: | + Raw, uncalibrated energy axis. Can be any of detector_pixel (arb. units), + TOF_ADC (arb. units), voltage (V), TOF (ns). + \@type: + enumeration: [detector_pixel, TOF_ADC, voltage, TOF] + kx_raw(NX_NUMBER): + exists: optional + unit: NX_ANY + doc: | + Raw, uncalibrated x axis in k-space. Can be any of detector_pixel (arb. units), + manipulator_angle (degrees) + \@type: + enumeration: [detector_pixel, manipulator_angle] + ky_raw(NX_NUMBER): + exists: optional + unit: NX_ANY + doc: | + Raw, uncalibrated y axis in k-space. Can be any of detector_pixel (arb. units), + manipulator_angle (degrees) + \@type: + enumeration: [detector_pixel, manipulator_angle] + kz_raw(NX_NUMBER): + exists: optional + unit: NX_ANY + doc: | + Raw, uncalibrated z axis in k-space. Can be any of photon energy (eV), + monochromator_step (arb. units) + \@type: + enumeration: [detector_pixel, manipulator_angle] + delay_raw(NX_NUMBER): + exists: optional + unit: NX_ANY + doc: | + Raw, uncalibrated z axis in k-space. Can be any of delay_ADC (arb. units), + delay_position (mm) + \@type: + enumeration: [delay_ADC, delay_position] + spin_raw(NX_NUMBER): + exists: optional + unit: NX_ANY + doc: | + Raw, uncalibrated spin axes. Can be any of magnetization (NX_CHAR), + scattering_direction (NX_CHAR) + \@type: + enumeration: [magnetization, scattering_direction] (NXmanipulator): exists: optional doc: | @@ -502,18 +550,18 @@ NXmpes(NXobject): 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. + + # in NXmpes, we should require an energy axis energy(NX_NUMBER): - exists: recommended + unit: NX_ENERGY doc: | Calibrated energy axis. - The calibrated energy axis can be either in binding or kinetic energy. - This should be a link to either + This could be a link to either /entry/process/energy_calibration/calibrated_axis or /entry/process/energy_correction/calibrated_axis. \@type: type: NX_CHAR - exists: recommended doc: | The energy can be either stored as kinetic (Term `3.35`_ of the ISO 18115-1:2023 specification) or as binding (Term `12.16`_) energy. @@ -524,12 +572,46 @@ NXmpes(NXobject): kinetic: doc: | Calibrated kinetic energy axis. - binding: - doc: | - Calibrated binding energy axis. + binding: + doc: | + Calibrated binding energy axis. + kx(NX_NUMBER): + exists: optional + unit: NX_ANY + doc: | + Calibrated x axis in k-space. + Units are 1/Angström. + ky(NX_NUMBER): + exists: optional + unit: NX_ANY + doc: | + Calibrated y axis in k-space. + Units are 1/Angström + kz(NX_NUMBER): + exists: optional + unit: NX_ANY + doc: | + Calibrated k axis in k-space. + Units are 1/Angström. + delay(NX_NUMBER): + exists: optional + unit: NX_TIME + doc: | + Calibrated delay time. + polarization: + exists: optional + unit: NX_ANY + doc: | + Polarization of the incoming beam. + + Can be any of linear polarization angle (degrees), ellipticity (arb. units). + Could be a link to /entry/instrument/beam/incident_polarization or + /entry/instrument/beam/final_polarization if they exist. + \@type: + enumeration: [linear polarization angle, ellipticity] # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 75917877eb699fd52182f562910ebb9fc44a699aced8a0c2a71725fffdec89ae +# 25d4207cd8d9745330b291d20386f0673c192ecb54fe4bc68e60117ece1b06ba # # # +# # # Calibrated energy axis. # -# The calibrated energy axis can be either in binding or kinetic energy. -# This should be a link to either +# This could be a link to either # /entry/process/energy_calibration/calibrated_axis or # /entry/process/energy_correction/calibrated_axis. # -# +# # # The energy can be either stored as kinetic (Term `3.35`_ of the ISO 18115-1:2023 # specification) or as binding (Term `12.16`_) energy. @@ -1181,11 +1337,49 @@ NXmpes(NXobject): # Calibrated kinetic energy axis. # # -# -# -# Calibrated binding energy axis. -# -# +# +# +# +# Calibrated binding energy axis. +# +# +# +# +# +# +# Calibrated x axis in k-space. +# Units are 1/Angström. +# +# +# +# +# Calibrated y axis in k-space. +# Units are 1/Angström +# +# +# +# +# Calibrated k axis in k-space. +# Units are 1/Angström. +# +# +# +# +# Calibrated delay time. +# +# +# +# +# Polarization of the incoming beam. +# +# Can be any of linear polarization angle (degrees), ellipticity (arb. units). +# Could be a link to /entry/instrument/beam/incident_polarization or +# /entry/instrument/beam/final_polarization if they exist. +# +# +# +# +# # # # From b0a216c3d2b2616ba88123bb7890ea35de2e6c21 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 26 Oct 2023 14:09:52 +0200 Subject: [PATCH 0337/1012] use @target in NXresolution --- contributed_definitions/NXresolution.nxdl.xml | 18 +++++++++-- .../nyaml/NXresolution.yaml | 32 +++++++++++++++---- 2 files changed, 41 insertions(+), 9 deletions(-) diff --git a/contributed_definitions/NXresolution.nxdl.xml b/contributed_definitions/NXresolution.nxdl.xml index 13bab958f4..b11c253a2b 100644 --- a/contributed_definitions/NXresolution.nxdl.xml +++ b/contributed_definitions/NXresolution.nxdl.xml @@ -74,14 +74,26 @@ - + A symbol linking to another path in this appdef to be referred to from the `resolution_formula` field. - - + + + A valid path inside this application definition, i.e., + of the form /entry/instrument/my_part/my_field + + + + + + A resolution formula to determine the resolution from a set of symbols as + entered by the `formula_symbol_...` fields. + The output unit should match the provided unit of this field. + + A resolution formula to determine the resolution from a set of symbols as diff --git a/contributed_definitions/nyaml/NXresolution.yaml b/contributed_definitions/nyaml/NXresolution.yaml index 22a6bfdce1..edc0e2db09 100644 --- a/contributed_definitions/nyaml/NXresolution.yaml +++ b/contributed_definitions/nyaml/NXresolution.yaml @@ -36,14 +36,22 @@ NXresolution(NXobject): The magnitude of the response function corresponding to the points in the input axis or grid. This field should have the same dimensions as `input`. - formula_symbol_LINK(NXlink): + formula_symbol_LINK(NX_CHAR): doc: | A symbol linking to another path in this appdef to be referred to from the `resolution_formula` field. symbol: exists: optional - path: + \@target: exists: optional + doc: | + A valid path inside this application definition, i.e., + of the form /entry/instrument/my_part/my_field + resolution_formula(NX_CHAR): + doc: | + A resolution formula to determine the resolution from a set of symbols as + entered by the `formula_symbol_...` fields. + The output unit should match the provided unit of this field. resolution_formula: doc: | A resolution formula to determine the resolution from a set of symbols as @@ -54,7 +62,7 @@ NXresolution(NXobject): For storing details and data of a calibration to derive a resolution from data # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 234db054d09b94441d581d54d7d4bd4d5d4a7b01fcd4ac752eda4400f3b27502 +# c447717fe53174bc5906b3b26ea58a96665de1472a2ad6b6221b7dc07f748250 # # # - - - Describes a link - - - - The symbol by which to refer to this link, e.g., for formulas - - - - - A valid path inside an instance of an application definition, i.e., - of the form /entry/instrument/my_part/my_field - - - diff --git a/contributed_definitions/NXresolution.nxdl.xml b/contributed_definitions/NXresolution.nxdl.xml index b11c253a2b..70eac45a43 100644 --- a/contributed_definitions/NXresolution.nxdl.xml +++ b/contributed_definitions/NXresolution.nxdl.xml @@ -74,30 +74,17 @@ - + - A symbol linking to another path in this appdef - to be referred to from the `resolution_formula` field. + A symbol linking to another path in this appdef to be referred to from the + `resolution_formula` field. This should be a valid path inside this application + definition, i.e., of the form /entry/instrument/my_part/my_field - - - - A valid path inside this application definition, i.e., - of the form /entry/instrument/my_part/my_field - - A resolution formula to determine the resolution from a set of symbols as - entered by the `formula_symbol_...` fields. - The output unit should match the provided unit of this field. - - - - - A resolution formula to determine the resolution from a set of symbols as - entered by the `formula_symbol_...` fields. + entered by the `formula_...` fields. The output unit should match the provided unit of this field. diff --git a/contributed_definitions/nyaml/NXlink.yaml b/contributed_definitions/nyaml/NXlink.yaml deleted file mode 100644 index fb365783dc..0000000000 --- a/contributed_definitions/nyaml/NXlink.yaml +++ /dev/null @@ -1,54 +0,0 @@ -category: base -doc: | - Describes a link -type: group -NXlink(NXobject): - symbol: - doc: | - The symbol by which to refer to this link, e.g., for formulas - path: - doc: | - A valid path inside an instance of an application definition, i.e., - of the form /entry/instrument/my_part/my_field - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# c176f19b15aeea095850727a438a8ab87c5ff5dc7c99dd25ace497391130dcf6 -# -# -# -# -# -# Describes a link -# -# -# -# The symbol by which to refer to this link, e.g., for formulas -# -# -# -# -# A valid path inside an instance of an application definition, i.e., -# of the form /entry/instrument/my_part/my_field -# -# -# diff --git a/contributed_definitions/nyaml/NXresolution.yaml b/contributed_definitions/nyaml/NXresolution.yaml index edc0e2db09..03fd711761 100644 --- a/contributed_definitions/nyaml/NXresolution.yaml +++ b/contributed_definitions/nyaml/NXresolution.yaml @@ -36,33 +36,22 @@ NXresolution(NXobject): The magnitude of the response function corresponding to the points in the input axis or grid. This field should have the same dimensions as `input`. - formula_symbol_LINK(NX_CHAR): + formula_SYMBOL(NX_CHAR): doc: | - A symbol linking to another path in this appdef - to be referred to from the `resolution_formula` field. - symbol: - exists: optional - \@target: - exists: optional - doc: | - A valid path inside this application definition, i.e., - of the form /entry/instrument/my_part/my_field + A symbol linking to another path in this appdef to be referred to from the + `resolution_formula` field. This should be a valid path inside this application + definition, i.e., of the form /entry/instrument/my_part/my_field resolution_formula(NX_CHAR): doc: | A resolution formula to determine the resolution from a set of symbols as - entered by the `formula_symbol_...` fields. - The output unit should match the provided unit of this field. - resolution_formula: - doc: | - A resolution formula to determine the resolution from a set of symbols as - entered by the `formula_symbol_...` fields. + entered by the `formula_...` fields. The output unit should match the provided unit of this field. (NXcalibration): doc: | For storing details and data of a calibration to derive a resolution from data # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# c447717fe53174bc5906b3b26ea58a96665de1472a2ad6b6221b7dc07f748250 +# 16dd07ac4d686000037772aa28146a800c2dbce278dc8d66f0962bab4847c751 # # # - + The symbols used in the schema to specify e.g. dimensions of arrays @@ -45,6 +45,36 @@ Subclass of NXprocess to describe post-processing calibrations. + + + A description of the procedures employed. + + + + + A digital persistent identifier (e.g., doi, ISO standard) referring to a detailed description of a + calibration method but no actual calibration data. + + + + + A digital persistent identifier (e.g., a doi) referring to a + publicly available calibration measurement used for this instrument + , e.g., a measurement of a known standard containing calibration information. + The axis values may be copied or linked in the appropriate NXcalibration fields for reference. + + + + + A file serialisation of a calibration which may not be publicly available (externally from the nexus file). + + This metadata can be a documentation of the source (file) or database (entry) from which pieces + of information have been extracted for consumption in e.g. a research data management system (RDMS). + It is also possible to include the actual file by using the `file` field. + + The axis values may be copied or linked in the appropriate NXcalibration fields for reference. + + Indicates the name of the last operation applied in the NXprocess sequence. @@ -55,6 +85,47 @@ Has the calibration been applied? + + + Vector containing the data coordinates in the original uncalibrated axis + + + + + + + The symbol of the axis to be used in the fit_function, e.g., `energy`, `E`. + This should comply to the following naming rules (similar to python's naming rules): + + * A variable name must start with a letter or the underscore character + * A variable name cannot start with a number + * A variable name can only contain alpha-numeric characters and underscores (A-z, 0-9, and _ ) + * Variable names are case-sensitive (age, Age and AGE are three different variables) + + + + + The path from which this data is derived, e.g., raw detector axis. + Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. + + + + + + Additional input axis to be used in the formula. + The part after `input_` is used as the symbol to be used in the `fit_function`, i.e., + if the field name is `input_my_field` you should refer to this axis by `my_field` in the `fit_function`. + + + + + + + The path from which this data is derived, e.g., raw detector axis. + Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. + + + For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit @@ -72,7 +143,13 @@ Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - Use x0, x1, ..., xn for the variables. + Use x0, x1, ..., xn for the nth position in the `original_axis` field. + If there is the symbol attribute specified for the `original_axis` this may be used instead of x. + If you want to use the whole axis use `x`. + Alternate axis can also be available as specified by the `input_SYMBOL` field. + The data should then be referred here by the `SYMBOL` name, e.g., for a field + name `input_my_field` it should be referred here by `my_field` or `my_field0` if + you want to read the zeroth element of the array. The formula should be numpy compliant. @@ -80,32 +157,35 @@ For linear calibration. Scaling parameter. + This is should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. For linear calibration. Offset parameter. + This is should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. - + - A vector representing the axis after calibration, matching the data length + Mapping data for calibration. + + This can be used to map data points from uncalibrated to calibrated values, + i.e., by multiplying each point in the input axis by the corresponding point in the mapping data. - - - - + - Vector containing the data coordinates in the original uncalibrated axis + A vector representing the axis after calibration, matching the data length - - - - A description of the procedures employed. - + + + The path to which this data is written, e.g., the calibrated energy. + Should be a valid NeXus path name, e.g., /entry/data/energy. + + diff --git a/contributed_definitions/NXidentifier.nxdl.xml b/contributed_definitions/NXidentifier.nxdl.xml new file mode 100644 index 0000000000..00c5eeafed --- /dev/null +++ b/contributed_definitions/NXidentifier.nxdl.xml @@ -0,0 +1,59 @@ + + + + + + An identifier for a (persistent) resource, e.g., a DOI or orcid. + + + + The service by which the resouce can be resolved. + If the service is not in the list a simple `url` may be used. + The `url` can either be a resolving service for the `identifier` + or a fully qualified identification in itself. + + + + + + + + + + + + + + The unique code, IRI or hash to resolve this reference. + Typically, this is stated by the service which is considered a complete + identifier, e.g., for a DOI it's something of the form `10.1107/S1600576714027575` + or `https://doi.org/10.1107/S1600576714027575`, which are both resolvable. + + + + + True if the identifier is persistent (i.e., unique and available indefinetely), + False otherwise. + + + diff --git a/contributed_definitions/NXserialized.nxdl.xml b/contributed_definitions/NXserialized.nxdl.xml new file mode 100644 index 0000000000..fd587c6655 --- /dev/null +++ b/contributed_definitions/NXserialized.nxdl.xml @@ -0,0 +1,76 @@ + + + + + + Metadata to a set of pieces of information of a resource that has been serialized. + + A typical use case is the documentation of the source (file) or database (entry) + from which pieces of information have been extracted for consumption in e.g. a + research data management system (RDMS). This may be for reasons of enabling + services such as providing access to normalized information for which reading + again from the resource may not be desired, possibe, or feasible. + + Possible reasons could be the extraction of specific information for caching, + performance reasons, or re-evaluate given pieces of information based on other + views and interaction patterns with the data where information has been formatted + differently by tools than how these pieces of information were originally + serialized. + + + + Answers into what resource the information was serialized. + + + + + + + + + Path to the resource. + + E.g. the name of a file or its absolute or relative path, or the + identifier to a resource in another database. + + + + + Value of the checksum obtain when running algorithm on the resource. + + + + + Name of the algorithm whereby the checksum was computed. + + + + + + + + + Extracted file containing the serialized information. + + + diff --git a/contributed_definitions/nyaml/NXcalibration.yaml b/contributed_definitions/nyaml/NXcalibration.yaml index c8337b5b20..005281ed63 100644 --- a/contributed_definitions/nyaml/NXcalibration.yaml +++ b/contributed_definitions/nyaml/NXcalibration.yaml @@ -12,21 +12,70 @@ symbols: Number of points of the calibrated and uncalibrated axes type: group NXcalibration(NXobject): + description(NX_CHAR): + doc: | + A description of the procedures employed. + calibration_method(NXidentifier): + doc: | + A digital persistent identifier (e.g., doi, ISO standard) referring to a detailed description of a + calibration method but no actual calibration data. + calibration_reference(NXidentifier): + doc: | + A digital persistent identifier (e.g., a doi) referring to a + publicly available calibration measurement used for this instrument + , e.g., a measurement of a known standard containing calibration information. + The axis values may be copied or linked in the appropriate NXcalibration fields for reference. + calibration_object(NXserialized): + doc: | + A file serialisation of a calibration which may not be publicly available (externally from the nexus file). + + This metadata can be a documentation of the source (file) or database (entry) from which pieces + of information have been extracted for consumption in e.g. a research data management system (RDMS). + It is also possible to include the actual file by using the `file` field. + + The axis values may be copied or linked in the appropriate NXcalibration fields for reference. last_process(NX_CHAR): doc: | Indicates the name of the last operation applied in the NXprocess sequence. applied(NX_BOOLEAN): doc: | Has the calibration been applied? + original_axis(NX_FLOAT): + unit: NX_ANY + doc: | + Vector containing the data coordinates in the original uncalibrated axis + dim: (ncal, ) + \@symbol: + doc: | + The symbol of the axis to be used in the fit_function, e.g., `energy`, `E`. + This should comply to the following naming rules (similar to python's naming rules): + + * A variable name must start with a letter or the underscore character + * A variable name cannot start with a number + * A variable name can only contain alpha-numeric characters and underscores (A-z, 0-9, and _ ) + * Variable names are case-sensitive (age, Age and AGE are three different variables) + \@input_path: + doc: | + The path from which this data is derived, e.g., raw detector axis. + Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. + input_SYMBOL(NX_FLOAT): + unit: NX_ANY + doc: | + Additional input axis to be used in the formula. + The part after `input_` is used as the symbol to be used in the `fit_function`, i.e., + if the field name is `input_my_field` you should refer to this axis by `my_field` in the `fit_function`. + dim: (ncal, ) + \@input_path: + doc: | + The path from which this data is derived, e.g., raw detector axis. + Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. coefficients(NX_FLOAT): unit: NX_ANY doc: | For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit to a set of features (peaks) at well defined energy positions to determine E(TOF). Here we can store the array of fit coefficients. - dimensions: - rank: 1 - dim: [[1, ncoeff]] + dim: (ncoeff, ) fit_function(NX_CHAR): doc: | For non-linear energy calibrations. Here we can store the formula of the @@ -34,34 +83,40 @@ NXcalibration(NXobject): Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - Use x0, x1, ..., xn for the variables. + Use x0, x1, ..., xn for the nth position in the `original_axis` field. + If there is the symbol attribute specified for the `original_axis` this may be used instead of x. + If you want to use the whole axis use `x`. + Alternate axis can also be available as specified by the `input_SYMBOL` field. + The data should then be referred here by the `SYMBOL` name, e.g., for a field + name `input_my_field` it should be referred here by `my_field` or `my_field0` if + you want to read the zeroth element of the array. The formula should be numpy compliant. scaling(NX_FLOAT): unit: NX_ANY doc: | For linear calibration. Scaling parameter. + This is should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. offset(NX_FLOAT): unit: NX_ANY doc: | For linear calibration. Offset parameter. + This is should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. + MAPPING(NX_FLOAT): + doc: | + Mapping data for calibration. + + This can be used to map data points from uncalibrated to calibrated values, + i.e., by multiplying each point in the input axis by the corresponding point in the mapping data. calibrated_axis(NX_FLOAT): unit: NX_ANY doc: | A vector representing the axis after calibration, matching the data length - dimensions: - rank: 1 - dim: [[1, ncal]] - original_axis(NX_FLOAT): - unit: NX_ANY - doc: | - Vector containing the data coordinates in the original uncalibrated axis - dimensions: - rank: 1 - dim: [[1, ncal]] - description(NX_CHAR): - doc: | - A description of the procedures employed. + dim: (ncal, ) + \@output_path: + doc: | + The path to which this data is written, e.g., the calibrated energy. + Should be a valid NeXus path name, e.g., /entry/data/energy. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ # 7394f6136c95cdee182a96a9aff856eee0285b94b6a3e83a0175949aa9752ae3 diff --git a/contributed_definitions/nyaml/NXidentifier.yaml b/contributed_definitions/nyaml/NXidentifier.yaml new file mode 100644 index 0000000000..4fc57a0589 --- /dev/null +++ b/contributed_definitions/nyaml/NXidentifier.yaml @@ -0,0 +1,21 @@ +category: base +doc: | + An identifier for a (persistent) resource, e.g., a DOI or orcid. +type: group +NXidentifier(NXobject): + service(NX_CHAR): + doc: | + The service by which the resouce can be resolved. + If the service is not in the list a simple `url` may be used. + The `url` can either be a resolving service for the `identifier` + or a fully qualified identification in itself. + enumeration: [doi, urn, hdl, purl, orcid, iso, url] + identifier(NX_CHAR): + doc: | + The unique code, IRI or hash to resolve this reference. + Typically, this is stated by the service which is considered a complete + identifier, e.g., for a DOI it's something of the form `10.1107/S1600576714027575` + or `https://doi.org/10.1107/S1600576714027575`, which are both resolvable. + is_persistent(NX_BOOLEAN): + doc: | + True if the identifier is persistent (i.e., unique and available indefinetely), False otherwise. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXserialized.yaml b/contributed_definitions/nyaml/NXserialized.yaml new file mode 100644 index 0000000000..6aa90f4b45 --- /dev/null +++ b/contributed_definitions/nyaml/NXserialized.yaml @@ -0,0 +1,37 @@ +category: base +doc: | + Metadata to a set of pieces of information of a resource that has been serialized. + + A typical use case is the documentation of the source (file) or database (entry) + from which pieces of information have been extracted for consumption in e.g. a + research data management system (RDMS). This may be for reasons of enabling + services such as providing access to normalized information for which reading + again from the resource may not be desired, possibe, or feasible. + + Possible reasons could be the extraction of specific information for caching, + performance reasons, or re-evaluate given pieces of information based on other + views and interaction patterns with the data where information has been formatted + differently by tools than how these pieces of information were originally + serialized. +type: group +NXserialized(NXobject): + type(NX_CHAR): + doc: | + Answers into what resource the information was serialized. + enumeration: [file, database] + path(NX_CHAR): + doc: | + Path to the resource. + + E.g. the name of a file or its absolute or relative path, or the + identifier to a resource in another database. + checksum(NX_CHAR): + doc: | + Value of the checksum obtain when running algorithm on the resource. + algorithm(NX_CHAR): + doc: | + Name of the algorithm whereby the checksum was computed. + enumeration: [md5, sha256] + file(NXnote): + doc: | + Extracted file containing the serialized information. \ No newline at end of file From 3bd3791e21574cf87f5baeaed583a49af6a810c8 Mon Sep 17 00:00:00 2001 From: domna Date: Thu, 2 Nov 2023 16:06:26 +0100 Subject: [PATCH 0340/1012] Updates calibration nxdl file --- contributed_definitions/NXcalibration.nxdl.xml | 14 -------------- 1 file changed, 14 deletions(-) diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml index 822a21effe..ec4dc423ca 100644 --- a/contributed_definitions/NXcalibration.nxdl.xml +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -188,18 +188,4 @@ - - - File containing the input data for calibration. - - - - - Mapping data for calibration. - - This can be used to map data points from uncalibrated - to calibrated values, e.g., by multiplying each point by the - corresponding point in the mapping data. - - From f0d7e06241585543bd49699face4ac0ff76cc662 Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Fri, 3 Nov 2023 11:38:02 +0100 Subject: [PATCH 0341/1012] Add nyaml2nxdl updates from NIAC PR1303 (#102) * fixing imports * Modification for changes request from 1303 PR. * changes from Peter and Pete. * Change request in nyaml2nxdl_backward_tools.py * nyaml2nxdl backward tools: fixing requested changes in that file. * Updating nyaml2nxdl.py with '--do-not-store-nxdl' * Removed unused and not functioned functions ('append_yaml', 'compaire_niac_and_my'), and CLI options. * Updating nyaml_forward_tools.py. * Improved Makefile from fairmat branch * Removes unused code * Addresses some review comments in nxdl_utils * Addresses comments in nxdl_utils * Fixes typo in readme * Updating nyam2nxdl converter files. * Fix typo in setuptools_scm * Resolving requested changes. * Fixing attributes for nxdl and yaml separately. * REsolving PR comments * Fixes Makefile pickung up nxdl rules for `make nyaml` * Updating PR comments. * updating PR comments. * updating PR comments. * updating PR comments. * Replacing os, and xml from dependencies and add lxml and pathlib as dependencies. * updating PR comments. * Implementing black on nyal2nxdl converter files. * Fixing test. * Fixing build errors. * Remove pyproject.toml and adapt makefile * Remove $(DIRS) from nyaml command * Updates a warning for using make nxdl * Fix codestyle * Build nxdl names from existing variables * Fixing indentation miss alignment in comments commeing from nxdl to nyaml. * Remove multiple build targets in Makefile * Remove duplicate --do-not-store-nxdl * Adjust variable names in generate_nxdl_or_retrieve_nxdl * Update long_doc * Align with nyaml2nxdl-migration branch * Rename parameters to generate_nxdl_or_retrieve * Align docstring * Adds python setup step for ci/cd * Fix test * Skip package install in ci/cd * Adds setup of python to build pages ci/cd * Fix dimensions notation in NXcalibration.yaml * Adapt NXidentifer and NXserialized to new nyaml2nxdl --------- Co-authored-by: Sandor Brockhauser Co-authored-by: Rubel --- .github/workflows/ci.yaml | 5 + .github/workflows/fairmat-build-pages.yaml | 4 + .../fairmat-nxdl-yaml-consistency.yaml | 2 - Makefile | 12 +- README.md | 5 +- .../NXcalibration.nxdl.xml | 332 ++++----- contributed_definitions/NXidentifier.nxdl.xml | 68 +- contributed_definitions/NXserialized.nxdl.xml | 100 +-- .../nyaml/NXcalibration.yaml | 16 +- dev_tools/docs/nxdl.py | 28 +- dev_tools/nyaml2nxdl/README.md | 18 +- dev_tools/nyaml2nxdl/__init__.py | 1 - dev_tools/nyaml2nxdl/comment_collector.py | 135 ++-- dev_tools/nyaml2nxdl/nyaml2nxdl.py | 219 ++---- .../nyaml2nxdl/nyaml2nxdl_backward_tools.py | 688 ++++++++---------- .../nyaml2nxdl/nyaml2nxdl_forward_tools.py | 593 +++++++-------- dev_tools/nyaml2nxdl/nyaml2nxdl_helper.py | 199 +++-- dev_tools/tests/test_nyaml2nxdl.py | 10 +- dev_tools/utils/nxdl_utils.py | 271 +++---- pyproject.toml | 43 -- 20 files changed, 1221 insertions(+), 1528 deletions(-) delete mode 100644 pyproject.toml diff --git a/.github/workflows/ci.yaml b/.github/workflows/ci.yaml index 42740b7301..09bc967f55 100755 --- a/.github/workflows/ci.yaml +++ b/.github/workflows/ci.yaml @@ -44,6 +44,11 @@ jobs: with: fetch-depth: 0 + - name: Set up Python ${{ matrix.python-version }} + uses: actions/setup-python@v4 + with: + python-version: ${{ matrix.python-version }} + - name: Deploy Information if: ${{ github.event.inputs.deploy && env.python_version == env.python_deploy_version }} run: | diff --git a/.github/workflows/fairmat-build-pages.yaml b/.github/workflows/fairmat-build-pages.yaml index d228e735fa..3335017b1c 100644 --- a/.github/workflows/fairmat-build-pages.yaml +++ b/.github/workflows/fairmat-build-pages.yaml @@ -14,6 +14,10 @@ jobs: uses: actions/checkout@v2 with: fetch-depth: 0 + - name: Set up Python 3.9 + uses: actions/setup-python@v4 + with: + python-version: "3.9" - name: install dependencies run: pip install -r requirements.txt - name: Get branch name diff --git a/.github/workflows/fairmat-nxdl-yaml-consistency.yaml b/.github/workflows/fairmat-nxdl-yaml-consistency.yaml index 7c19584a82..64a78fc19e 100644 --- a/.github/workflows/fairmat-nxdl-yaml-consistency.yaml +++ b/.github/workflows/fairmat-nxdl-yaml-consistency.yaml @@ -20,8 +20,6 @@ jobs: fetch-depth: 0 - name: install dependencies run: pip install -r requirements.txt - - name: install package - run: pip install -e . - name: make nxdls run: make nxdl - uses: CatChen/check-git-status-action@v1 diff --git a/Makefile b/Makefile index 829ce857a6..37aa544f5d 100644 --- a/Makefile +++ b/Makefile @@ -99,22 +99,22 @@ all :: @echo "PDF built: `ls -lAFgh $(BUILD_DIR)/manual/build/latex/nexus-fairmat.pdf`" $(BASE_CLASS_DIR)/%.nxdl.xml : $(BASE_CLASS_DIR)/$(NYAML_SUBDIR)/%.yaml - nyaml2nxdl --input-file $< + $(PYTHON) -m dev_tools.nyaml2nxdl.nyaml2nxdl --input-file $< mv $(BASE_CLASS_DIR)/$(NYAML_SUBDIR)/$*.nxdl.xml $@ $(CONTRIB_DIR)/%.nxdl.xml : $(CONTRIB_DIR)/$(NYAML_SUBDIR)/%.yaml - nyaml2nxdl --input-file $< + $(PYTHON) -m dev_tools.nyaml2nxdl.nyaml2nxdl --input-file $< mv $(CONTRIB_DIR)/$(NYAML_SUBDIR)/$*.nxdl.xml $@ $(APPDEF_DIR)/%.nxdl.xml : $(APPDEF_DIR)/$(NYAML_SUBDIR)/%.yaml - nyaml2nxdl --input-file $< + $(PYTHON) -m dev_tools.nyaml2nxdl.nyaml2nxdl --input-file $< mv $(APPDEF_DIR)/$(NYAML_SUBDIR)/$*.nxdl.xml $@ -NXDLS := $(foreach dir,$(NXDL_DIRS),$(wildcard $(dir)/*.nxdl.xml)) -nyaml : $(DIRS) +NXDLS := $(NXDL_APPDEF) + $(NXDL_CONTRIB) + $(NXDL_BC) +nyaml : for file in $(NXDLS); do\ mkdir -p "$${file%/*}/nyaml";\ - nyaml2nxdl --input-file $${file};\ + $(PYTHON) -m dev_tools.nyaml2nxdl.nyaml2nxdl --input-file $${file};\ FNAME=$${file##*/};\ mv -- "$${file%.nxdl.xml}_parsed.yaml" "$${file%/*}/nyaml/$${FNAME%.nxdl.xml}.yaml";\ done diff --git a/README.md b/README.md index 4f4020aa6f..68d3af845c 100755 --- a/README.md +++ b/README.md @@ -29,7 +29,7 @@ Open the HTML manual in a web brower for visual verification firefox build/manual/build/html/index.html -Convenient editting of definitions is available in nyaml format. For this, definitions need to be converted first from xml to yaml format by the command +Convenient editing of definitions is available in nyaml format. For this, definitions need to be converted first from xml to yaml format by the command make nyaml @@ -37,6 +37,9 @@ After editing the definitions in nyaml format in the nyaml subdirectories, the f make nxdl +> [!WARNING] +> Please be aware that your nyaml files might be out of sync with the nxdl files when you update your repo. So it's best practice to stash your changes to the nyaml files and regenerate the files with `make nyaml` before adding any changes. + ### HTML pages with contributor information To build the html pages that contains contributor information on the sidebar set a github access token to an environment variable called GH_TOKEN. diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml index ec4dc423ca..d74a053e0f 100644 --- a/contributed_definitions/NXcalibration.nxdl.xml +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -1,9 +1,9 @@ - + - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of coefficients of the calibration function - - - - - Number of features used to fit the calibration function - - - - - Number of points of the calibrated and uncalibrated axes - - - + - Subclass of NXprocess to describe post-processing calibrations. + The symbols used in the schema to specify e.g. dimensions of arrays - - - A description of the procedures employed. - - - - - A digital persistent identifier (e.g., doi, ISO standard) referring to a detailed description of a - calibration method but no actual calibration data. - - - - - A digital persistent identifier (e.g., a doi) referring to a - publicly available calibration measurement used for this instrument - , e.g., a measurement of a known standard containing calibration information. - The axis values may be copied or linked in the appropriate NXcalibration fields for reference. - - - - - A file serialisation of a calibration which may not be publicly available (externally from the nexus file). - - This metadata can be a documentation of the source (file) or database (entry) from which pieces - of information have been extracted for consumption in e.g. a research data management system (RDMS). - It is also possible to include the actual file by using the `file` field. - - The axis values may be copied or linked in the appropriate NXcalibration fields for reference. - - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the calibration been applied? - - - - - Vector containing the data coordinates in the original uncalibrated axis - - - - - - - The symbol of the axis to be used in the fit_function, e.g., `energy`, `E`. - This should comply to the following naming rules (similar to python's naming rules): - - * A variable name must start with a letter or the underscore character - * A variable name cannot start with a number - * A variable name can only contain alpha-numeric characters and underscores (A-z, 0-9, and _ ) - * Variable names are case-sensitive (age, Age and AGE are three different variables) - - - - - The path from which this data is derived, e.g., raw detector axis. - Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. - - - - - - Additional input axis to be used in the formula. - The part after `input_` is used as the symbol to be used in the `fit_function`, i.e., - if the field name is `input_my_field` you should refer to this axis by `my_field` in the `fit_function`. - - - - - - - The path from which this data is derived, e.g., raw detector axis. - Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. - - - - - - For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit - to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the array of fit coefficients. - - - - - - - - For non-linear energy calibrations. Here we can store the formula of the - fit function. - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - - Use x0, x1, ..., xn for the nth position in the `original_axis` field. - If there is the symbol attribute specified for the `original_axis` this may be used instead of x. - If you want to use the whole axis use `x`. - Alternate axis can also be available as specified by the `input_SYMBOL` field. - The data should then be referred here by the `SYMBOL` name, e.g., for a field - name `input_my_field` it should be referred here by `my_field` or `my_field0` if - you want to read the zeroth element of the array. - - The formula should be numpy compliant. - - - - - For linear calibration. Scaling parameter. - This is should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. - - - - - For linear calibration. Offset parameter. - This is should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. - - - - - Mapping data for calibration. - - This can be used to map data points from uncalibrated to calibrated values, - i.e., by multiplying each point in the input axis by the corresponding point in the mapping data. - - - - - A vector representing the axis after calibration, matching the data length - - - - - - - The path to which this data is written, e.g., the calibrated energy. - Should be a valid NeXus path name, e.g., /entry/data/energy. - - - + + + Number of coefficients of the calibration function + + + + + Number of features used to fit the calibration function + + + + + Number of points of the calibrated and uncalibrated axes + + + + + Subclass of NXprocess to describe post-processing calibrations. + + + + A description of the procedures employed. + + + + + A digital persistent identifier (e.g., doi, ISO standard) referring to a detailed description of a + calibration method but no actual calibration data. + + + + + A digital persistent identifier (e.g., a doi) referring to a + publicly available calibration measurement used for this instrument + , e.g., a measurement of a known standard containing calibration information. + The axis values may be copied or linked in the appropriate NXcalibration fields for reference. + + + + + A file serialisation of a calibration which may not be publicly available (externally from the nexus file). + + This metadata can be a documentation of the source (file) or database (entry) from which pieces + of information have been extracted for consumption in e.g. a research data management system (RDMS). + It is also possible to include the actual file by using the `file` field. + + The axis values may be copied or linked in the appropriate NXcalibration fields for reference. + + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Has the calibration been applied? + + + + + Vector containing the data coordinates in the original uncalibrated axis + + + + + + + The symbol of the axis to be used in the fit_function, e.g., `energy`, `E`. + This should comply to the following naming rules (similar to python's naming rules): + + * A variable name must start with a letter or the underscore character + * A variable name cannot start with a number + * A variable name can only contain alpha-numeric characters and underscores (A-z, 0-9, and _ ) + * Variable names are case-sensitive (age, Age and AGE are three different variables) + + + + + The path from which this data is derived, e.g., raw detector axis. + Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. + + + + + + Additional input axis to be used in the formula. + The part after `input_` is used as the symbol to be used in the `fit_function`, i.e., + if the field name is `input_my_field` you should refer to this axis by `my_field` in the `fit_function`. + + + + + + + The path from which this data is derived, e.g., raw detector axis. + Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. + + + + + + For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit + to a set of features (peaks) at well defined energy positions to determine + E(TOF). Here we can store the array of fit coefficients. + + + + + + + + For non-linear energy calibrations. Here we can store the formula of the + fit function. + + Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. + + Use x0, x1, ..., xn for the nth position in the `original_axis` field. + If there is the symbol attribute specified for the `original_axis` this may be used instead of x. + If you want to use the whole axis use `x`. + Alternate axis can also be available as specified by the `input_SYMBOL` field. + The data should then be referred here by the `SYMBOL` name, e.g., for a field + name `input_my_field` it should be referred here by `my_field` or `my_field0` if + you want to read the zeroth element of the array. + + The formula should be numpy compliant. + + + + + For linear calibration. Scaling parameter. + This is should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. + + + + + For linear calibration. Offset parameter. + This is should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. + + + + + Mapping data for calibration. + + This can be used to map data points from uncalibrated to calibrated values, + i.e., by multiplying each point in the input axis by the corresponding point in the mapping data. + + + + + A vector representing the axis after calibration, matching the data length + + + + + + + The path to which this data is written, e.g., the calibrated energy. + Should be a valid NeXus path name, e.g., /entry/data/energy. + + + diff --git a/contributed_definitions/NXidentifier.nxdl.xml b/contributed_definitions/NXidentifier.nxdl.xml index 00c5eeafed..cd9689f133 100644 --- a/contributed_definitions/NXidentifier.nxdl.xml +++ b/contributed_definitions/NXidentifier.nxdl.xml @@ -1,9 +1,9 @@ - + + + An identifier for a (persistent) resource, e.g., a DOI or orcid. + + - An identifier for a (persistent) resource, e.g., a DOI or orcid. + The service by which the resouce can be resolved. + If the service is not in the list a simple `url` may be used. + The `url` can either be a resolving service for the `identifier` + or a fully qualified identification in itself. - - - The service by which the resouce can be resolved. - If the service is not in the list a simple `url` may be used. - The `url` can either be a resolving service for the `identifier` - or a fully qualified identification in itself. - - - - - - - - - - - - - - The unique code, IRI or hash to resolve this reference. - Typically, this is stated by the service which is considered a complete - identifier, e.g., for a DOI it's something of the form `10.1107/S1600576714027575` - or `https://doi.org/10.1107/S1600576714027575`, which are both resolvable. - - - - - True if the identifier is persistent (i.e., unique and available indefinetely), - False otherwise. - - + + + + + + + + + + + + + The unique code, IRI or hash to resolve this reference. + Typically, this is stated by the service which is considered a complete + identifier, e.g., for a DOI it's something of the form `10.1107/S1600576714027575` + or `https://doi.org/10.1107/S1600576714027575`, which are both resolvable. + + + + + True if the identifier is persistent (i.e., unique and available indefinetely), + False otherwise. + + diff --git a/contributed_definitions/NXserialized.nxdl.xml b/contributed_definitions/NXserialized.nxdl.xml index fd587c6655..70bf4e8424 100644 --- a/contributed_definitions/NXserialized.nxdl.xml +++ b/contributed_definitions/NXserialized.nxdl.xml @@ -1,9 +1,9 @@ - + + + Metadata to a set of pieces of information of a resource that has been serialized. + + A typical use case is the documentation of the source (file) or database (entry) + from which pieces of information have been extracted for consumption in e.g. a + research data management system (RDMS). This may be for reasons of enabling + services such as providing access to normalized information for which reading + again from the resource may not be desired, possibe, or feasible. + + Possible reasons could be the extraction of specific information for caching, + performance reasons, or re-evaluate given pieces of information based on other + views and interaction patterns with the data where information has been formatted + differently by tools than how these pieces of information were originally + serialized. + + - Metadata to a set of pieces of information of a resource that has been serialized. - - A typical use case is the documentation of the source (file) or database (entry) - from which pieces of information have been extracted for consumption in e.g. a - research data management system (RDMS). This may be for reasons of enabling - services such as providing access to normalized information for which reading - again from the resource may not be desired, possibe, or feasible. + Answers into what resource the information was serialized. + + + + + + + + + Path to the resource. - Possible reasons could be the extraction of specific information for caching, - performance reasons, or re-evaluate given pieces of information based on other - views and interaction patterns with the data where information has been formatted - differently by tools than how these pieces of information were originally - serialized. + E.g. the name of a file or its absolute or relative path, or the + identifier to a resource in another database. + + + + + Value of the checksum obtain when running algorithm on the resource. + + + + + Name of the algorithm whereby the checksum was computed. + + + + + + + + + Extracted file containing the serialized information. - - - Answers into what resource the information was serialized. - - - - - - - - - Path to the resource. - - E.g. the name of a file or its absolute or relative path, or the - identifier to a resource in another database. - - - - - Value of the checksum obtain when running algorithm on the resource. - - - - - Name of the algorithm whereby the checksum was computed. - - - - - - - - - Extracted file containing the serialized information. - - + diff --git a/contributed_definitions/nyaml/NXcalibration.yaml b/contributed_definitions/nyaml/NXcalibration.yaml index 005281ed63..434cf2eec4 100644 --- a/contributed_definitions/nyaml/NXcalibration.yaml +++ b/contributed_definitions/nyaml/NXcalibration.yaml @@ -44,7 +44,9 @@ NXcalibration(NXobject): unit: NX_ANY doc: | Vector containing the data coordinates in the original uncalibrated axis - dim: (ncal, ) + dimensions: + rank: 1 + dim: [[1, ncal]] \@symbol: doc: | The symbol of the axis to be used in the fit_function, e.g., `energy`, `E`. @@ -64,7 +66,9 @@ NXcalibration(NXobject): Additional input axis to be used in the formula. The part after `input_` is used as the symbol to be used in the `fit_function`, i.e., if the field name is `input_my_field` you should refer to this axis by `my_field` in the `fit_function`. - dim: (ncal, ) + dimensions: + rank: 1 + dim: [[1, ncal]] \@input_path: doc: | The path from which this data is derived, e.g., raw detector axis. @@ -75,7 +79,9 @@ NXcalibration(NXobject): For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit to a set of features (peaks) at well defined energy positions to determine E(TOF). Here we can store the array of fit coefficients. - dim: (ncoeff, ) + dimensions: + rank: 1 + dim: [[1, ncoeff]] fit_function(NX_CHAR): doc: | For non-linear energy calibrations. Here we can store the formula of the @@ -112,7 +118,9 @@ NXcalibration(NXobject): unit: NX_ANY doc: | A vector representing the axis after calibration, matching the data length - dim: (ncal, ) + dimensions: + rank: 1 + dim: [[1, ncal]] \@output_path: doc: | The path to which this data is written, e.g., the calibrated energy. diff --git a/dev_tools/docs/nxdl.py b/dev_tools/docs/nxdl.py index c2dda67988..c9e3ebed1c 100755 --- a/dev_tools/docs/nxdl.py +++ b/dev_tools/docs/nxdl.py @@ -17,10 +17,6 @@ from ..utils.types import PathLike from .anchor_list import AnchorRegistry -# controlling the length of progressively more indented sub-node -MIN_COLLAPSE_HINT_LINE_LENGTH = 20 -MAX_COLLAPSE_HINT_LINE_LENGTH = 80 - class NXClassDocGenerator: """Generate documentation in reStructuredText markup @@ -523,30 +519,24 @@ def _print_doc(self, indent, ns, node, required=False): self._print(f"{indent}{line}") self._print() - def long_doc(self, ns, node, left_margin): + def long_doc(self, ns, node): length = 0 line = "documentation" fnd = False blocks = self._get_doc_blocks(ns, node) - max_characters = max( - MIN_COLLAPSE_HINT_LINE_LENGTH, (MAX_COLLAPSE_HINT_LINE_LENGTH - left_margin) - ) for block in blocks: lines = block.splitlines() length += len(lines) for single_line in lines: if len(single_line) > 2 and single_line[0] != "." and not fnd: fnd = True - line = single_line[:max_characters] + line = single_line return (length, line, blocks) def _print_doc_enum(self, indent, ns, node, required=False): collapse_indent = indent node_list = node.xpath("nx:enumeration", namespaces=ns) - (doclen, line, blocks) = self.long_doc(ns, node, len(indent)) - if len(node_list) + doclen > 1: - collapse_indent = f"{indent} " - self._print(f"{indent}{self._INDENTATION_UNIT}.. collapse:: {line} ...\n") + (doclen, line, blocks) = self.long_doc(ns, node) self._print_doc( collapse_indent + self._INDENTATION_UNIT, ns, node, required=required ) @@ -677,8 +667,9 @@ def _print(self, *args, end="\n"): self._rst_lines.append(" ".join(args) + end) def get_first_parent_ref(self, path, tag): - nx_name = path[1 : path.find("/", 1)] - path = path[path.find("/", 1) :] + spliter = path.find("/", 1) + nx_name = path[1:spliter] + path = path[spliter:] try: parents = pynxtools_nxlib.get_inherited_nodes(path, nx_name)[2] @@ -688,11 +679,8 @@ def get_first_parent_ref(self, path, tag): parent = parents[1] parent_path = parent_display_name = parent.attrib["nxdlpath"] parent_path_segments = parent_path[1:].split("/") - parent_def_name = parent.attrib["nxdlbase"][ - parent.attrib["nxdlbase"] - .rfind("/") : parent.attrib["nxdlbase"] - .rfind(".nxdl") - ] + nxdl_attr = parent.attrib["nxdlbase"] + parent_def_name = nxdl_attr[nxdl_attr.rfind("/") : nxdl_attr.rfind(".nxdl")] # Case where the first parent is a base_class if parent_path_segments[0] == "": diff --git a/dev_tools/nyaml2nxdl/README.md b/dev_tools/nyaml2nxdl/README.md index ec69275c25..4b316fc5d0 100644 --- a/dev_tools/nyaml2nxdl/README.md +++ b/dev_tools/nyaml2nxdl/README.md @@ -30,7 +30,7 @@ Options: --check-consistency Check consistency by generating another version of the input file. E.g. for input file: NXexample.nxdl.xml the output file NXexample_consistency.nxdl.xml. - --verbose Addictional std output info is printed to help debugging. + --verbose Additional std output info is printed to help debugging. --help Show this message and exit. ``` @@ -40,18 +40,18 @@ Options: **Rule set**: From transcoding YAML files we need to follow several rules. * Named NeXus groups, which are instances of NeXus classes especially base or contributed classes. Creating (NXbeam) is a simple example of a request to define a group named according to NeXus default rules. mybeam1(NXbeam) or mybeam2(NXbeam) are examples how to create multiple named instances at the same hierarchy level. * Members of groups so-called fields or attributes. A simple example of a member is voltage. Here the datatype is implied automatically as the default NeXus NX_CHAR type. By contrast, voltage(NX_FLOAT) can be used to instantiate a member of class which should be of NeXus type NX_FLOAT. -* And attributes of either groups or fields. Names of attributes have to be preceeded by \@ to mark them as attributes. +* And attributes of either groups or fields. The mark '\@' have to precede the name of attributes. * Optionality: For all fields, groups and attributes in `application definitions` are `required` by default, except anything (`recommended` or `optional`) mentioned. **Special keywords**: Several keywords can be used as childs of groups, fields, and attributes to specify the members of these. Groups, fields and attributes are nodes of the XML tree. * **doc**: A human-readable description/docstring -* **exists** Options are recommended, required, [min, 1, max, infty] numbers like here 1 can be replaced by any uint, or infty to indicate no restriction on how frequently the entry can occur inside the NXDL schema at the same hierarchy level. +* **exists** Options are recommended, required, [min, 1, max, `infty`] numbers like here 1 can be replaced by any `uint` (unsigned integer), or `infty` to indicate no restriction on how frequently the entry can occur inside the NXDL schema at the same hierarchy level. * **link** Define links between nodes. * **units** A statement introducing NeXus-compliant NXDL units arguments, like NX_VOLTAGE * **dimensions** Details which dimensional arrays to expect * **enumeration** Python list of strings which are considered as recommended entries to choose from. * **dim_parameters** `dim` which is a child of `dimension` and the `dim` might have several attributes `ref`, -`incr` including `index` and `value`. So while writting `yaml` file schema definition please following structure: +`incr` including `index` and `value`. So while writing `yaml` file schema definition please following structure: ``` dimensions: rank: integer value @@ -60,13 +60,9 @@ dimensions: ref: [ref_value_1, ref_value_2, ...] incr: [incr_value_1, incr_value_2, ...] ``` -Keep in mind that length of all the lists must be same. +Keep in mind that length of all the lists must have the **same size**. +**Important Note**: The attributes `ref`, `incr`, `index` are deprecated. ## Next steps -The NOMAD team is currently working on the establishing of a one-to-one mapping between -NeXus definitions and the NOMAD MetaInfo. As soon as this is in place the YAML files will -be annotated with further metadata so that they can serve two purposes. -On the one hand they can serve as an instance for a schema to create a GUI representation -of a NOMAD Oasis ELN schema. On the other hand the YAML to NXDL converter will skip all -those pieces of information which are irrelevant from a NeXus perspective. +The NOMAD team is currently working to establish a one-to-one mapping between NeXus definitions and the NOMAD MetaInfo(scientific data model in nomad). As soon as this is in place the YAML files will be annotated with further metadata so that they can serve two purposes. On the one hand they can serve as an instance for a schema to create a GUI representation of a NOMAD Oasis ELN schema. On the other hand the YAML to NXDL converter will skip all those pieces of information which are irrelevant from a NeXus perspective. diff --git a/dev_tools/nyaml2nxdl/__init__.py b/dev_tools/nyaml2nxdl/__init__.py index 22eb35f68d..d0f7a80f2f 100644 --- a/dev_tools/nyaml2nxdl/__init__.py +++ b/dev_tools/nyaml2nxdl/__init__.py @@ -1,4 +1,3 @@ -#!/usr/bin/env python3 """ # Load paths """ diff --git a/dev_tools/nyaml2nxdl/comment_collector.py b/dev_tools/nyaml2nxdl/comment_collector.py index 0041c14ec4..6ded2f3720 100644 --- a/dev_tools/nyaml2nxdl/comment_collector.py +++ b/dev_tools/nyaml2nxdl/comment_collector.py @@ -19,15 +19,12 @@ # """ -Collect comments in a list by CommentCollector class. Comment is a instance of Comment, -where each comment includes comment text and line info or neighbour info where the -comment must be assinged. +Collect comments in a list by CommentCollector class and each comment is an instance of Comment +class. Each `Comment` instance(sometimes refered as 'comment block') consists of text and line +info or neighbours info where the comment must be placed. The class Comment is an abstract class for general functions or method to be implemented XMLComment and YAMLComment class. - -NOTE: Here comment block mainly stands for (comment text + line or element for what comment is -intended.) """ @@ -62,13 +59,15 @@ def __init__(self, input_file: str = None, loaded_obj: Union[object, Dict] = Non self._comment_hash: Dict[Tuple, Type[Comment]] = {} self.comment: Type[Comment] if self.file and not loaded_obj: - if self.file.split(".")[-1] == "xml": + if self.file.endswith(".xml"): self.comment = XMLComment - if self.file.split(".")[-1] == "yaml": + elif self.file.split(".")[-1] == "yaml": self.comment = YAMLComment with open(self.file, "r", encoding="utf-8") as plain_text_yaml: loader = LineLoader(plain_text_yaml) self.comment.__yaml_dict__ = loader.get_single_data() + else: + raise ValueError("Input file must be a 'yaml' or 'nxdl.xml' type.") elif self.file and loaded_obj: if self.file.split(".")[-1] == "yaml" and isinstance(loaded_obj, dict): self.comment = YAMLComment @@ -82,8 +81,9 @@ def __init__(self, input_file: str = None, loaded_obj: Union[object, Dict] = Non raise ValueError("Incorrect inputs for CommentCollector") def extract_all_comment_blocks(self): - """ - Collect all comments. Note that here comment means (comment text + element or line info + """Collect all comments. + + Note here that comment means (comment text + element or line info intended for comment. """ id_ = 0 @@ -93,18 +93,16 @@ def extract_all_comment_blocks(self): # Make an empty line for last comment if no empty lines in original file if lines[-1] != "": lines.append("") + end_line_num = len(lines) - 1 for line_num, line in enumerate(lines): if single_comment.is_storing_single_comment(): # If the last comment comes without post nxdl fields, groups and attributes if "++ SHA HASH ++" in line: # Handle with stored nxdl.xml file that is not part of yaml - line = "" - single_comment.process_each_line( - line + "post_comment", (line_num + 1) - ) + single_comment.process_each_line("post_comment", (line_num + 1)) self._comment_chain.append(single_comment) break - if line_num < (len(lines) - 1): + if line_num < end_line_num: # Processing file from Line number 1 single_comment.process_each_line(line, (line_num + 1)) else: @@ -118,13 +116,13 @@ def extract_all_comment_blocks(self): single_comment = self.comment(last_comment=single_comment) single_comment.process_each_line(line, (line_num + 1)) - def get_comment(self): + def get_next_comment(self): """ Return comment from comment_chain that must come earlier in order. """ return self._comment_chain[self._comment_tracker] - def get_coment_by_line_info(self, comment_locs: Tuple[str, Union[int, str]]): + def get_comment_by_line_info(self, comment_locs: Tuple[str, Union[int, str]]): """ Get comment using line information. """ @@ -202,7 +200,7 @@ def __init__(self, comment_id: int = -1, last_comment: "Comment" = None) -> None """Comment object can be considered as a block element that includes document element (an entity for what the comment is written). """ - self._elemt: Any = None + self._elemt: Dict[str, Any] = {} self._elemt_text: str = None self._is_elemt_found: bool = None self._is_elemt_stored: bool = None @@ -228,7 +226,7 @@ def __init__(self, comment_id: int = -1, last_comment: "Comment" = None) -> None self._comnt_end_found and self._is_elemt_stored ) - def get_comment_text(self) -> Union[List, str]: + def get_comment_text_list(self) -> Union[List, str]: """ Extract comment text from entrire comment (comment text + elment or line for what comment is intended) @@ -292,39 +290,39 @@ def store_element(self, text) -> None: def collect_xml_attributes(text_part): for part in text_part: part = part.strip() - if part and '">' == "".join(part[-2:]): + if part and part.endswith('">'): self._is_elemt_stored = True self._is_elemt_found = False - part = "".join(part[0:-2]) - elif part and '"/>' == "".join(part[-3:]): + part = part[0:-2] + elif part and part.endswith('"/>'): self._is_elemt_stored = True self._is_elemt_found = False - part = "".join(part[0:-3]) - elif part and "/>" == "".join(part[-2:]): + part = part[0:-3] + elif part and part.endswith("/>"): self._is_elemt_stored = True self._is_elemt_found = False - part = "".join(part[0:-2]) - elif part and ">" == part[-1]: + part = part[0:-2] + elif part and part.endswith(">"): self._is_elemt_stored = True self._is_elemt_found = False - part = "".join(part[0:-1]) - elif part and '"' == part[-1]: - part = "".join(part[0:-1]) + part = part[0:-1] + elif part and part.endswith('"'): + part = part[0:-1] if '="' in part: lf_prt, rt_prt = part.split('="') + if ":" in lf_prt: + continue else: continue - if ":" in lf_prt: - continue self._elemt[lf_prt] = str(rt_prt) if not self._elemt: self._elemt = {} # First check for comment part has been collected prefectly - if " Union[List, str]: + def get_comment_text_list(self) -> Union[List, str]: """ This method returns list of commnent text. As some xml element might have multiple separated comment intended for a single element. @@ -354,10 +352,10 @@ def get_comment_text(self) -> Union[List, str]: class YAMLComment(Comment): """ - This class for stroing comment text as well as location of the comment e.g. line + This class for storing comment text as well as location of the comment e.g. line number of other in the file. NOTE: - 1. Do not delete any element form yaml dictionary (for loaded_obj. check: Comment_collector + 1. Do not delete any element from yaml dictionary (for loaded_obj. check: Comment_collector class. because this loaded file has been exploited in nyaml2nxdl forward tools.) """ @@ -375,7 +373,9 @@ def __init__(self, comment_id: int = -1, last_comment: "Comment" = None) -> None ) def process_each_line(self, text, line_num): - """Take care of each line of text. Through which function the text + """Process each line. + + Take care of each line of text. Through which function the text must be passed should be decide here. """ text = text.strip() @@ -387,9 +387,9 @@ def process_each_line(self, text, line_num): if self._comnt_end_found: line_key = "" - if ":" in text: - ind = text.index(":") - line_key = "__line__" + "".join(text[0:ind]) + ind = text.find(":") + if ind > 0: + line_key = "__line__" + text[0:ind] for l_num, l_key in self.__yaml_line_info.items(): if line_num == int(l_num) and line_key == l_key: @@ -401,10 +401,10 @@ def process_each_line(self, text, line_num): self.store_element(line_key, line_num) def has_post_comment(self): - """ - Ensure is this a post coment or not. - Post comment means the comment that come at the very end without having any - nxdl element(class, group, filed and attribute.) + """Ensure if this is a post comment or not. + + Post comment means the comment that comes at the very end without having any + nxdl element(class, group, filed and attribute.). """ for key, _ in self._elemt.items(): if "__line__post_comment" == key: @@ -412,12 +412,13 @@ def has_post_comment(self): return False def append_comment(self, text: str) -> None: - """ + """Append comment texts to the associated comment. + Collects all the line of the same comment and append them with that single comment. """ # check for escape char - text = self.replace_scape_char(text) + text = self.replace_escape_char(text) # Empty line after last line of comment if not text and self._comnt_start_found: self._comnt_end_found = True @@ -425,16 +426,16 @@ def append_comment(self, text: str) -> None: # For empty line inside doc or yaml file. elif not text: return - elif "# " == "".join(text[0:2]): + elif text.startswith("# "): self._comnt_start_found = True self._comnt_end_found = False self._comnt = "" if not self._comnt else self._comnt + "\n" - self._comnt = self._comnt + "".join(text[2:]) - elif "#" == text[0]: + self._comnt = self._comnt + text[2:] + elif text.startswith("#"): self._comnt_start_found = True self._comnt_end_found = False self._comnt = "" if not self._comnt else self._comnt + "\n" - self._comnt = self._comnt + "".join(text[1:]) + self._comnt = self._comnt + text[1:] elif "post_comment" == text: self._comnt_end_found = True self._comnt_start_found = False @@ -445,24 +446,21 @@ def append_comment(self, text: str) -> None: # pylint: disable=arguments-differ def store_element(self, line_key, line_number): - """ - Store comment content and information of commen location (for what comment is - created.). - """ + """Store comment contents and information of comment location.""" self._elemt = {} self._elemt[line_key] = int(line_number) self._is_elemt_found = False self._is_elemt_stored = True - def get_comment_text(self): + def get_comment_text_list(self): """ - Return list of comments if there are multiple comment for same yaml line. + Return list of comments. """ return self._comnt_list def get_line_number(self, line_key): """ - Retrun line number for what line the comment is created + Return line no for which line the comment is created. """ return self._elemt[line_key] @@ -473,22 +471,19 @@ def get_line_info(self): for line_anno, line_loc in self._elemt.items(): return line_anno, line_loc - def replace_scape_char(self, text): + def replace_escape_char(self, text): """Replace escape char according to __comment_escape_char dict""" for ecp_char, ecp_alt in YAMLComment.__comment_escape_char.items(): - if ecp_char in text: - text = text.replace(ecp_char, ecp_alt) + text = text.replace(ecp_char, ecp_alt) return text def get_element_location(self): - """ - Retrun yaml line '__line__KEY' info and and line numner - """ - if len(self._elemt) > 1: - raise ValueError(f"Comment element should be one but got " f"{self._elemt}") - - for key, val in self._elemt.items(): - yield key, val + """Return yaml line '__line__' info and and line numner""" + if len(self._elemt) == 0: + raise ValueError( + f"Comment element should be one or more but got {self._elemt}" + ) + return next(self._elemt.items()) def collect_yaml_line_info(self, yaml_dict, line_info_dict): """Collect __line__key and corresponding value from @@ -503,11 +498,13 @@ def collect_yaml_line_info(self, yaml_dict, line_info_dict): self.collect_yaml_line_info(val, line_info_dict) def __contains__(self, line_key): - """For Checking whether __line__NAME is in _elemt dict or not.""" + """For checking whether __line__ is in _elemt dict or not.""" return line_key in self._elemt def __eq__(self, comment_obj): """Check the self has same value as right comment.""" + if not isinstance(comment_obj, Comment): + raise TypeError(f"Expecting comment_obj as a instance of {Comment}") if len(self._comnt_list) != len(comment_obj._comnt_list): return False for left_cmnt, right_cmnt in zip(self._comnt_list, comment_obj._comnt_list): diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl.py b/dev_tools/nyaml2nxdl/nyaml2nxdl.py index 6aecbe3962..4031d6bbdf 100755 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl.py +++ b/dev_tools/nyaml2nxdl/nyaml2nxdl.py @@ -1,8 +1,10 @@ #!/usr/bin/env python3 -"""Main file of nyaml2nxdl tool. -Users create NeXus instances by writing a YAML file -which details a hierarchy of data/metadata elements +""" +Main file of nyaml2nxdl tool. +To write a definition for a instrument, experiment and/or process in nxdl.xml file from a YAML +file which details a hierarchy of data/metadata elements. It also allows both wa +conversion beteen YAML and nxdl.xml files that follows rules of NeXus ontology or data format. """ # -*- coding: utf-8 -*- # @@ -22,150 +24,56 @@ # See the License for the specific language governing permissions and # limitations under the License. # -import os -import xml.etree.ElementTree as ET +from pathlib import Path import click from .nyaml2nxdl_backward_tools import Nxdl2yaml -from .nyaml2nxdl_backward_tools import compare_niac_and_my from .nyaml2nxdl_forward_tools import nyaml2nxdl -from .nyaml2nxdl_forward_tools import pretty_print_xml from .nyaml2nxdl_helper import extend_yamlfile_by_nxdl_as_comment from .nyaml2nxdl_helper import get_sha256_hash from .nyaml2nxdl_helper import separate_hash_yaml_and_nxdl DEPTH_SIZE = 4 * " " +_nxdl = ".nxdl.xml" # NOTE: Some handful links for nyaml2nxdl converter: # https://manual.nexusformat.org/nxdl_desc.html?highlight=optional -def generate_nxdl_or_retrieve_nxdl(yaml_in, xml_out, verbose): - """ - Generate yaml, nxdl, and hash. - If the extracted hash is exactly the same as generated from input yaml then - retrieve the nxdl part from provided yaml and return nxdl as output. - Else, generate nxdl from input yaml with the help of nyaml2nxdl function +def generate_nxdl_or_retrieve_nxdl(yaml_file, out_xml_file, verbose): """ + Generate yaml, nxdl and hash. - file_path, rel_file = os.path.split(yaml_in) - sep_yaml = os.path.join(file_path, f"temp_{rel_file}") - hash_found = separate_hash_yaml_and_nxdl(yaml_in, sep_yaml, xml_out) + If the extracted hash is exactly the same as produced from generated yaml then + retrieve the nxdl part from provided yaml. + Else, generate nxdl from separated yaml with the help of nyaml2nxdl function + """ + file_path = Path(yaml_file) + pa_path, rel_file = file_path.parent, file_path.name + sep_yaml = (pa_path / f"temp_{rel_file}").as_posix() + hash_found = separate_hash_yaml_and_nxdl(yaml_file, sep_yaml, out_xml_file) if hash_found: gen_hash = get_sha256_hash(sep_yaml) if hash_found == gen_hash: - os.remove(sep_yaml) + Path(sep_yaml).unlink() return - nyaml2nxdl(sep_yaml, xml_out, verbose) - os.remove(sep_yaml) + nyaml2nxdl(sep_yaml, out_xml_file, verbose) + Path(sep_yaml).unlink() -# pylint: disable=too-many-locals -def append_yml(input_file, append, verbose): - """Append to an existing NeXus base class new elements provided in YML input file \ -and print both an XML and YML file of the extended base class. - -""" - nexus_def_path = os.path.join( - os.path.abspath(os.path.dirname(__file__)), "../../definitions" - ) - assert [ - s - for s in os.listdir(os.path.join(nexus_def_path, "base_classes")) - if append.strip() == s.replace(".nxdl.xml", "") - ], "Your base class extension does not match any existing NeXus base classes" - tree = ET.parse( - os.path.join(nexus_def_path + "/base_classes", append + ".nxdl.xml") - ) - root = tree.getroot() - # warning: tmp files are printed on disk and removed at the ends!! - pretty_print_xml(root, "tmp.nxdl.xml") - input_tmp_xml = "tmp.nxdl.xml" - out_tmp_yml = "tmp_parsed.yaml" - converter = Nxdl2yaml([], []) - converter.print_yml(input_tmp_xml, out_tmp_yml, verbose) - nyaml2nxdl(input_file=out_tmp_yml, out_file="tmp_parsed.nxdl.xml", verbose=verbose) - tree = ET.parse("tmp_parsed.nxdl.xml") - tree2 = ET.parse(input_file) - root_no_duplicates = ET.Element( - "definition", - { - "xmlns": "http://definition.nexusformat.org/nxdl/3.1", - "xmlns:xsi": "http://www.w3.org/2001/XMLSchema-instance", - "xsi:schemaLocation": "http://www.w3.org/2001/XMLSchema-instance", - }, - ) - for attribute_keys in root.attrib.keys(): - if ( - attribute_keys - != "{http://www.w3.org/2001/XMLSchema-instance}schemaLocation" - ): - attribute_value = root.attrib[attribute_keys] - root_no_duplicates.set(attribute_keys, attribute_value) - for elems in root.iter(): - if "doc" in elems.tag: - root_doc = ET.SubElement(root_no_duplicates, "doc") - root_doc.text = elems.text - break - group = "{http://definition.nexusformat.org/nxdl/3.1}group" - root_no_duplicates = compare_niac_and_my( - tree, tree2, verbose, group, root_no_duplicates - ) - field = "{http://definition.nexusformat.org/nxdl/3.1}field" - root_no_duplicates = compare_niac_and_my( - tree, tree2, verbose, field, root_no_duplicates - ) - attribute = "{http://definition.nexusformat.org/nxdl/3.1}attribute" - root_no_duplicates = compare_niac_and_my( - tree, tree2, verbose, attribute, root_no_duplicates - ) - pretty_print_xml( - root_no_duplicates, - f"{input_file.replace('.nxdl.xml', '')}" f"_appended.nxdl.xml", - ) - - input_file_xml = input_file.replace(".nxdl.xml", "_appended.nxdl.xml") - out_file_yml = input_file.replace(".nxdl.xml", "_appended_parsed.yaml") - converter = Nxdl2yaml([], []) - converter.print_yml(input_file_xml, out_file_yml, verbose) - nyaml2nxdl( - input_file=out_file_yml, - out_file=out_file_yml.replace(".yaml", ".nxdl.xml"), - verbose=verbose, - ) - os.rename( - f"{input_file.replace('.nxdl.xml', '_appended_parsed.yaml')}", - f"{input_file.replace('.nxdl.xml', '_appended.yaml')}", - ) - os.rename( - f"{input_file.replace('.nxdl.xml', '_appended_parsed.nxdl.xml')}", - f"{input_file.replace('.nxdl.xml', '_appended.nxdl.xml')}", - ) - os.remove("tmp.nxdl.xml") - os.remove("tmp_parsed.yaml") - os.remove("tmp_parsed.nxdl.xml") - - -def split_name_and_extension(file_name): +def split_name_and_extension(file_path): """ Split file name into extension and rest of the file name. - return file raw nam and extension - """ - path = file_name.rsplit("/", 1) - (pathn, filen) = ["", path[0]] if len(path) == 1 else [path[0] + "/", path[1]] - parts = filen.rsplit(".", 2) - raw = ext = "" - if len(parts) == 2: - raw = parts[0] - ext = parts[1] - elif len(parts) == 3: - raw = parts[0] - ext = ".".join(parts[1:]) - return pathn + raw, ext + return file raw name and extension + """ + path = Path(file_path) + ext = "".join(path.suffixes) + full_path_stem = file_path[0 : file_path.index(ext)] + return full_path_stem, ext[1:] @click.command() @@ -176,25 +84,19 @@ def split_name_and_extension(file_name): help="The path to the XML or YAML input data file to read and create \ a YAML or XML file from, respectively.", ) -@click.option( - "--append", - help="Parse xml file and append to base class, given that the xml file has same name \ -of an existing base class", -) @click.option( "--check-consistency", is_flag=True, default=False, help=( - "Check wether yaml or nxdl has followed general rules of scema or not" - "check whether your comment in the right place or not. The option render an " - "output file of the same extension(*_consistency.yaml or *_consistency.nxdl.xml)" + "Check if yaml and nxdl can be converted from one to another version recursively and" + " get the same version of file. E.g. from NXexample.nxdl.xml to NXexample_consistency.nxdl.xml." ), ) @click.option( "--do-not-store-nxdl", is_flag=True, - default=True, + default=False, help=( "Whether the input nxdl file will be stored as a comment" " at the end of output yaml file." @@ -207,54 +109,53 @@ def split_name_and_extension(file_name): help="Print in standard output keywords and value types to help \ possible issues in yaml files", ) -def launch_tool(input_file, verbose, append, do_not_store_nxdl, check_consistency): +# def launch_tool(input_file, verbose, check_consistency): +def launch_tool(input_file, verbose, do_not_store_nxdl, check_consistency): """ - Main function that distiguishes the input file format and launches the tools. + Main function that distinguishes the input file format and launches the tools. """ - if os.path.isfile(input_file): + + if Path(input_file).is_file(): raw_name, ext = split_name_and_extension(input_file) else: raise ValueError("Need a valid input file.") - if ext == "yaml": - xml_out_file = raw_name + ".nxdl.xml" + xml_out_file = raw_name + _nxdl generate_nxdl_or_retrieve_nxdl(input_file, xml_out_file, verbose) - if append: - append_yml(raw_name + ".nxdl.xml", append, verbose) + # For consistency running if check_consistency: yaml_out_file = raw_name + "_consistency." + ext converter = Nxdl2yaml([], []) converter.print_yml(xml_out_file, yaml_out_file, verbose) - os.remove(xml_out_file) + Path(xml_out_file).unlink() elif ext == "nxdl.xml": - if not append: - yaml_out_file = raw_name + "_parsed" + ".yaml" - converter = Nxdl2yaml([], []) - converter.print_yml(input_file, yaml_out_file, verbose) - # Store nxdl.xml file in output yaml file under SHA HASH - yaml_hash = get_sha256_hash(yaml_out_file) - # Lines as divider between yaml and nxdl - top_lines = [ - ( - "\n# ++++++++++++++++++++++++++++++++++ SHA HASH" - " ++++++++++++++++++++++++++++++++++\n" - ), - f"# {yaml_hash}\n", - ] - if do_not_store_nxdl: - extend_yamlfile_by_nxdl_as_comment( - yaml_file=yaml_out_file, - file_to_be_appended=input_file, - top_lines_list=top_lines, - ) - else: - append_yml(input_file, append, verbose) + # if not append: + yaml_out_file = raw_name + "_parsed" + ".yaml" + converter = Nxdl2yaml([], []) + converter.print_yml(input_file, yaml_out_file, verbose) + # Store nxdl.xml file in output yaml file under SHA HASH + yaml_hash = get_sha256_hash(yaml_out_file) + # Lines as divider between yaml and nxdl + top_lines = [ + ( + "\n# ++++++++++++++++++++++++++++++++++ SHA HASH" + " ++++++++++++++++++++++++++++++++++\n" + ), + f"# {yaml_hash}\n", + ] + if not do_not_store_nxdl: + extend_yamlfile_by_nxdl_as_comment( + yaml_file=yaml_out_file, + file_to_be_appended=input_file, + top_lines_list=top_lines, + ) + # Taking care of consistency running if check_consistency: xml_out_file = raw_name + "_consistency." + ext generate_nxdl_or_retrieve_nxdl(yaml_out_file, xml_out_file, verbose) - os.remove(yaml_out_file) + Path.unlink(yaml_out_file) else: raise ValueError("Provide correct file with extension '.yaml or '.nxdl.xml") diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py b/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py index dcf56b998d..f6f543713d 100755 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py +++ b/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py @@ -1,8 +1,6 @@ #!/usr/bin/env python3 -"""This file collects the function used in the reverse tool nxdl2yaml. - +"""This file collects the functions for conversion from nxdl.xml to yaml version. """ -import os # -*- coding: utf-8 -*- # @@ -22,82 +20,91 @@ # See the License for the specific language governing permissions and # limitations under the License. # -import sys -import xml.etree.ElementTree as ET + +from pathlib import Path +from typing import Callable from typing import Dict from typing import List -from .nyaml2nxdl_helper import cleaning_empty_lines +import lxml.etree as ET + +from .nyaml2nxdl_helper import NXDL_ATTRIBUTES_ATTRIBUTES +from .nyaml2nxdl_helper import NXDL_FIELD_ATTRIBUTES +from .nyaml2nxdl_helper import NXDL_GROUP_ATTRIBUTES +from .nyaml2nxdl_helper import NXDL_LINK_ATTRIBUTES +from .nyaml2nxdl_helper import clean_empty_lines from .nyaml2nxdl_helper import get_node_parent_info from .nyaml2nxdl_helper import get_yaml_escape_char_dict +from .nyaml2nxdl_helper import is_dom_comment from .nyaml2nxdl_helper import remove_namespace_from_tag DEPTH_SIZE = " " CMNT_TAG = "!--" +CMNT_TAG_END = "--" +CMNT_START = "" +DEFINITION_CATEGORIES = ("category: application", "category: base") def separate_pi_comments(input_file): - """ - Separate PI comments from ProcessesInstruction (pi) + """Separate PI comments from ProcessesInstruction (PI). + + ProcessesInstruction refers xml element process and version + Separate the comments that comes immediately after XML process instruction part, + i.e. copyright comment part. """ comments_list = [] comment = [] - xml_lines = [] with open(input_file, "r", encoding="utf-8") as file: lines = file.readlines() - has_pi = True + def_tag = " 0 and has_pi: - comment.append(line.replace(cmnt_end, "")) + elif CMNT_END in line and len(comment) > 0: + comment.append(line.replace(CMNT_END, "")) comments_list.append("".join(comment)) - comment = [] - elif def_tag in line or not has_pi: - has_pi = False - xml_lines.append(line) - elif len(comment) > 0 and has_pi: + comment.clear() + elif len(comment) > 0: comment.append(line) - else: - xml_lines.append(line) - return comments_list, "".join(xml_lines) + elif def_tag in line: + break + return comments_list # Collected: https://dustinoprea.com/2019/01/22/python-parsing-xml-and-retaining-the-comments/ class _CommentedTreeBuilder(ET.TreeBuilder): - def comment(self, text): - """ - defining comment builder in TreeBuilder - """ - self.start("!--", {}) + def start(self, tag, attrs): + super().start(tag=tag, attrs=attrs) + + def Comment(self, text): + """Defining comment builder in TreeBuilder""" + self.start(CMNT_TAG, {}) self.data(text) - self.end("--") + self.end(CMNT_TAG_END) def parse(filepath): - """ - Construct parse function for modified tree builder for including modified TreeBuilder + """Parse xml function. + + Construct parser function for modified tree builder for including modified TreeBuilder and rebuilding XMLParser. """ - comments, xml_str = separate_pi_comments(filepath) + comments = separate_pi_comments(filepath) ctb = _CommentedTreeBuilder() - xp_parser = ET.XMLParser(target=ctb) - root = ET.fromstring(xml_str, parser=xp_parser) + xp_parser = ET.XMLParser(target=ctb, encoding="UTF-8") + root = ET.parse(filepath, xp_parser) return comments, root def handle_mapping_char(text, depth=-1, skip_n_line_on_top=False): - """Check for ":" char and replace it by "':'".""" + """Check for escape character and replace by alternative character.""" escape_char = get_yaml_escape_char_dict() for esc_key, val in escape_char.items(): @@ -112,22 +119,19 @@ def handle_mapping_char(text, depth=-1, skip_n_line_on_top=False): def add_new_line_with_pipe_on_top(text, depth): + """Design docs block. + + Restructure the text by adding pipe '|' and '\n' char if ':' is found in text. """ - Return modified text for what we get error in converter, such as ':'. After adding a - new line at the start of text the error is solved. - """ - char_list_to_add_new_line_on_top_of_text = [":"] - for char in char_list_to_add_new_line_on_top_of_text: - if char in text: - return "|" + "\n" + depth * DEPTH_SIZE + text + char = ":" + if char in text: + return "|" + "\n" + depth * DEPTH_SIZE + text return text # pylint: disable=too-many-instance-attributes class Nxdl2yaml: - """ - Parse XML file and print a YML file - """ + """Parse XML file and print a YML file.""" def __init__( self, @@ -142,7 +146,6 @@ def __init__( self.root_level_symbols = root_level_symbols self.root_level_definition = root_level_definition self.symbol_list = symbol_list - self.is_last_element_comment = False self.include_comment = True self.pi_comments = None # NOTE: Here is how root_level_comments organised for storing comments @@ -155,12 +158,21 @@ def __init__( # 'symbol_comments': [comments]} self.root_level_comment: Dict[str, str] = {} + self.optionality_keys = ( + "minOccurs", + "maxOccurs", + "optional", + "recommended", + "required", + ) + # "Take care of general attributes. Note other choices may be allowed in the future" + self.choice_allowed_attr = () + def print_yml(self, input_file, output_yml, verbose): - """ - Parse an XML file provided as input and print a YML file - """ - if os.path.isfile(output_yml): - os.remove(output_yml) + """Parse an XML file provided as input and print a YML file.""" + output_file_path = Path(output_yml) + if output_file_path.is_file(): + output_file_path.unlink() depth = 0 @@ -171,7 +183,6 @@ def print_yml(self, input_file, output_yml, verbose): def handle_symbols(self, depth, node): """Handle symbols field and its childs symbol""" - # pylint: disable=consider-using-f-string self.root_level_symbols = ( f"{remove_namespace_from_tag(node.tag)}: " f"{node.text.strip() if node.text else ''}" @@ -184,14 +195,12 @@ def handle_symbols(self, depth, node): for child in list(node): tag = remove_namespace_from_tag(child.tag) if tag == CMNT_TAG and self.include_comment: - last_comment = self.comvert_to_ymal_comment( - depth * DEPTH_SIZE, child.text - ) + last_comment = self.convert_to_yaml_comment(depth, child.text) if tag == "doc": symbol_cmnt_list.append(last_comment) - # The bellow line is for handling lenth of 'symbol_comments' and + # The line below is for handling length of 'symbol_comments' and # 'symbol_doc_comments'. Otherwise print_root_level_info() gets inconsistency - # over for the loop while writting comment on file + # over for the loop while writing comment on file sbl_doc_cmnt_list.append("") last_comment = "" self.symbol_list.append( @@ -211,8 +220,8 @@ def handle_symbols(self, depth, node): for symbol_doc in list(child): tag = remove_namespace_from_tag(symbol_doc.tag) if tag == CMNT_TAG and self.include_comment: - last_comment = self.comvert_to_ymal_comment( - depth * DEPTH_SIZE, symbol_doc.text + last_comment = self.convert_to_yaml_comment( + depth, symbol_doc.text ) if tag == "doc": sbl_doc_cmnt_list.append(last_comment) @@ -233,13 +242,11 @@ def store_root_level_comments(self, holder, comment): self.root_level_comment[holder] = comment def handle_definition(self, node): + """Handle definition group and its attributes. + + NOTE: Here we try to store the order of the xml element attributes, so that we get + the same order in nxdl from yaml. """ - Handle definition group and its attributes - NOTE: Here we tried to store the order of the xml element attributes. So that we get - exactly the same file in nxdl from yaml. - """ - # pylint: disable=consider-using-f-string - # self.root_level_definition[0] = '' keyword = "" # tmp_word for reseving the location tmp_word = "#xx#" @@ -247,12 +254,12 @@ def handle_definition(self, node): # for tracking the order of name and type keyword_order = -1 for item in attribs: - if "name" in item: + if "name" == item: keyword = keyword + attribs[item] if keyword_order == -1: self.root_level_definition.append(tmp_word) keyword_order = self.root_level_definition.index(tmp_word) - elif "extends" in item: + elif "extends" == item: keyword = f"{keyword}({attribs[item]})" if keyword_order == -1: self.root_level_definition.append(tmp_word) @@ -266,65 +273,51 @@ def handle_root_level_doc(self, node): """ Handle the documentation field found at root level. """ - # tag = remove_namespace_from_tag(node.tag) text = node.text text = self.handle_not_root_level_doc(depth=0, text=text) self.root_level_doc = text - # pylint: disable=too-many-branches - def handle_not_root_level_doc(self, depth, text, tag="doc", file_out=None): - """ - Handle docs field along the yaml file. In this function we also tried to keep - the track of intended indentation. E.g. the bollow doc block. - * Topic name - Description of topic - """ + def clean_and_organise_text(self, text, depth): + """Reconstruct text from doc and comment. + Cleaninig up unintentional and accidental empty lines and spaces. + """ # Handling empty doc if not text: text = "" else: text = handle_mapping_char(text, -1, True) if "\n" in text: - # To remove '\n' character as it will be added before text. - text = cleaning_empty_lines(text.split("\n")) + # To remove '\n' with non-space character as it will be added before text. + text = clean_empty_lines(text.split("\n")) text_tmp = [] yaml_indent_n = len((depth + 1) * DEPTH_SIZE) - # Find indentaion in the first text line with alphabet - tmp_i = 0 - while tmp_i != -1: - first_line_indent_n = 0 - # Taking care of empty text whitout any character - if len(text) == 1 and text[0] == "": + + # Find indentation in the first line of text having alphabet + first_line_indent_n = 0 + for line in text: + # Consider only the lines that has at least one non-space character + # and skip starting lines of a text block are empty + if len(line.lstrip()) != 0: + first_line_indent_n = len(line) - len(line.lstrip()) break - for ch_ in text[tmp_i]: - if ch_ == " ": - first_line_indent_n = first_line_indent_n + 1 - elif ch_ != "": - tmp_i = -2 - break - tmp_i = tmp_i + 1 - # Taking care of doc like bellow: - # Text liness + # Taking care of doc like below: + # Text lines # text continues - # So no indentaion at the staring or doc. So doc group will come along general + # So no indentation at the start of doc. So doc group will come along general # alignment if first_line_indent_n == 0: first_line_indent_n = yaml_indent_n - # for indent_diff -ve all lines will move left by the same ammout - # for indect_diff +ve all lines will move right the same amount + # for indent_diff -ve all lines will move left by the same amount + # for indent_diff +ve all lines will move right by the same amount indent_diff = yaml_indent_n - first_line_indent_n # CHeck for first line empty if not keep first line empty - for _, line in enumerate(text): + for line in text: line_indent_n = 0 - # Collect first empty space without alphabate - for ch_ in line: - if ch_ == " ": - line_indent_n = line_indent_n + 1 - else: - break + # count first empty spaces without alphabet + line_indent_n = len(line) - len(line.lstrip()) line_indent_n = line_indent_n + indent_diff if line_indent_n < yaml_indent_n: # if line still under yaml identation @@ -333,19 +326,26 @@ def handle_not_root_level_doc(self, depth, text, tag="doc", file_out=None): text_tmp.append(line_indent_n * " " + line.strip()) text = "\n" + "\n".join(text_tmp) - if "}" in tag: - tag = remove_namespace_from_tag(tag) - indent = depth * DEPTH_SIZE + elif text: text = "\n" + (depth + 1) * DEPTH_SIZE + text.strip() - if "}" in tag: - tag = remove_namespace_from_tag(tag) - indent = depth * DEPTH_SIZE - else: - text = "" - if "}" in tag: - tag = remove_namespace_from_tag(tag) - indent = depth * DEPTH_SIZE + + return text + + # pylint: disable=too-many-branches + def handle_not_root_level_doc(self, depth, text, tag="doc", file_out=None): + """Handle docs field of group and field but not root. + + Handle docs field along the yaml file. In this function we also tried to keep + the track of indentation. E.g. the below doc block. + * Topic name + Description of topic + """ + + text = self.clean_and_organise_text(text, depth) + if "}" in tag: + tag = remove_namespace_from_tag(tag) + indent = depth * DEPTH_SIZE doc_str = f"{indent}{tag}: |{text}\n" if file_out: @@ -361,67 +361,56 @@ def write_out(self, indent, text, file_out): file_out.write(line_string) def print_root_level_doc(self, file_out): - """ - Print at the root level of YML file \ - the general documentation field found in XML file - """ + """Print at the root level of YML file the general documentation field found in XML file""" indent = 0 * DEPTH_SIZE - if ( - "root_doc" in self.root_level_comment - and self.root_level_comment["root_doc"] != "" - ): - text = self.root_level_comment["root_doc"] + text = self.root_level_comment.get("root_doc") + if text: self.write_out(indent, text, file_out) text = self.root_level_doc self.write_out(indent, text, file_out) self.root_level_doc = "" - def comvert_to_ymal_comment(self, indent, text): + def convert_to_yaml_comment(self, depth, text): """ Convert into yaml comment by adding exta '#' char in front of comment lines """ - lines = text.split("\n") + # To store indentation text from comment + lines = self.clean_and_organise_text(text, depth).split("\n") + indent = DEPTH_SIZE * depth mod_lines = [] for line in lines: line = line.strip() - if line and line[0] != "#": - line = indent + "# " + line - mod_lines.append(line) - elif line: - line = indent + line + if line: + if line[0] != "#": + line = "# " + line mod_lines.append(line) # The starting '\n' to keep multiple comments separate - return "\n" + "\n".join(mod_lines) + return "\n" + indent + "\n".join(mod_lines) def print_root_level_info(self, depth, file_out): """ Print at the root level of YML file \ the information stored as definition attributes in the XML file """ - # pylint: disable=consider-using-f-string if depth < 0: - raise ValueError("Somthing wrong with indentaion in root level.") + raise ValueError("Somthing wrong with indentation in root level.") - has_categoty = False + has_category = False for def_line in self.root_level_definition: - if def_line in ("category: application", "category: base"): + if def_line in DEFINITION_CATEGORIES: self.write_out(indent=0 * DEPTH_SIZE, text=def_line, file_out=file_out) - # file_out.write(f"{def_line}\n") - has_categoty = True + has_category = True - if not has_categoty: + if not has_category: raise ValueError( "Definition dose not get any category from 'base or application'." ) self.print_root_level_doc(file_out) - if ( - "symbols" in self.root_level_comment - and self.root_level_comment["symbols"] != "" - ): + text = self.root_level_comment.get("symbols", "") + if text: indent = depth * DEPTH_SIZE - text = self.root_level_comment["symbols"] self.write_out(indent, text, file_out) if self.root_level_symbols: self.write_out( @@ -429,7 +418,7 @@ def print_root_level_info(self, depth, file_out): ) # symbol_list include 'symbols doc', and all 'symbol' for ind, symbol in enumerate(self.symbol_list): - # Taking care of comments that come on to of 'symbols doc' and 'symbol' + # Taking care of comments that come on top of 'symbols doc' and 'symbol' if ( "symbol_comments" in self.root_level_comment and self.root_level_comment["symbol_comments"][ind] != "" @@ -452,15 +441,15 @@ def print_root_level_info(self, depth, file_out): ) self.write_out(indent=(0 * DEPTH_SIZE), text=symbol, file_out=file_out) - if len(self.pi_comments) > 1: - indent = DEPTH_SIZE * depth - # The first comment is top level copy-right doc string - for comment in self.pi_comments[1:]: + indent = depth * DEPTH_SIZE + # Take care copyright doc string + for comment in self.pi_comments: + if comment and not is_dom_comment(comment): self.write_out( - indent, self.comvert_to_ymal_comment(indent, comment), file_out + indent, self.convert_to_yaml_comment(depth, comment), file_out ) if self.root_level_definition: - # Soring NXname for writting end of the definition attributes + # Store NXname for writing at end of definition attributes nx_name = "" for defs in self.root_level_definition: if "NX" in defs and defs[-1] == ":": @@ -488,42 +477,19 @@ def handle_exists(self, exists_dict, key, val): val = str(val) if "minOccurs" == key: exists_dict["minOccurs"] = ["min", val] - if "maxOccurs" == key: + elif "maxOccurs" == key: exists_dict["maxOccurs"] = ["max", val] - if "optional" == key: + elif "optional" == key: exists_dict["optional"] = ["optional", val] - if "recommended" == key: + elif "recommended" == key: exists_dict["recommended"] = ["recommended", val] - if "required" == key: + elif "required" == key: exists_dict["required"] = ["required", val] - # pylint: disable=too-many-branches, consider-using-f-string + # pylint: disable=too-many-branches def handle_group_or_field(self, depth, node, file_out): """Handle all the possible attributes that come along a field or group""" - allowed_attr = [ - "optional", - "recommended", - "name", - "type", - "axes", - "axis", - "data_offset", - "interpretation", - "long_name", - "maxOccurs", - "minOccurs", - "nameType", - "optional", - "primary", - "signal", - "stride", - "units", - "required", - "deprecated", - "exists", - ] - name_type = "" node_attr = node.attrib rm_key_list = [] @@ -532,29 +498,28 @@ def handle_group_or_field(self, depth, node, file_out): if key == "name": name_type = name_type + val rm_key_list.append(key) - if key == "type": - name_type = name_type + "(%s)" % val + elif key == "type": + name_type = f"{name_type}({val})" rm_key_list.append(key) if not name_type: raise ValueError( - f"No 'name' or 'type' hase been found. But, 'group' or 'field' " - f"must have at list a nme.We got attributes: {node_attr}" - ) - file_out.write( - "{indent}{name_type}:\n".format( - indent=depth * DEPTH_SIZE, name_type=name_type + f"No 'name' or 'type' has been found. But, 'group' or 'field' " + f"must have at least a name.We have attributes: {node_attr}" ) - ) + indent = depth * DEPTH_SIZE + file_out.write(f"{indent}{name_type}:\n") for key in rm_key_list: del node_attr[key] - # tmp_dict intended to persevere order of attribnutes + # tmp_dict intended to preserve order of attributes tmp_dict = {} exists_dict = {} for key, val in node_attr.items(): + # Check for any unwanted attributes + self.check_for_unwanted_attributes(node=node) # As both 'minOccurs', 'maxOccurs' and optionality move to the 'exists' - if key in ["minOccurs", "maxOccurs", "optional", "recommended", "required"]: + if key in self.optionality_keys: if "exists" not in tmp_dict: tmp_dict["exists"] = [] self.handle_exists(exists_dict, key, val) @@ -562,11 +527,6 @@ def handle_group_or_field(self, depth, node, file_out): tmp_dict["unit"] = str(val) else: tmp_dict[key] = str(val) - if key not in allowed_attr: - raise ValueError( - f"An attribute ({key}) in 'field' or 'group' has been found " - f"that is not allowed. The allowed attr is {allowed_attr}." - ) if exists_dict: for key, val in exists_dict.items(): @@ -577,43 +537,64 @@ def handle_group_or_field(self, depth, node, file_out): depth_ = depth + 1 for key, val in tmp_dict.items(): - # Increase depth size inside handle_map...() for writting text with one + # Increase depth size inside handle_map...() for writing text with one # more indentation. file_out.write( f"{depth_ * DEPTH_SIZE}{key}: " f"{handle_mapping_char(val, depth_ + 1, False)}\n" ) + def check_for_unwanted_attributes(self, node, allowed_attributes_li=None, tag=None): + """Check for any attributes that NeXus does not allow.""" + node_tag = remove_namespace_from_tag(node.tag) + if node_tag == "field": + for key in node.attrib.keys(): + if key not in NXDL_FIELD_ATTRIBUTES: + raise ValueError( + f"Field has an unwanted attribute {key}." + f"NeXus field allows attributes from {NXDL_FIELD_ATTRIBUTES}" + ) + elif node_tag == "group": + for key in node.attrib.keys(): + if key not in NXDL_GROUP_ATTRIBUTES: + raise ValueError( + f"Attribute has an unwanted attribute {key}." + f"NeXus attribute allows attributes from {NXDL_GROUP_ATTRIBUTES}" + ) + elif node_tag == tag: + for key in node.attrib.keys(): + if key not in allowed_attributes_li: + raise ValueError( + f"{tag.capitalized()} has an unwanted attribute {key}." + f"NeXus {tag.capitalized()} allows attributes from {allowed_attributes_li}" + ) + # pylint: disable=too-many-branches, too-many-locals def handle_dimension(self, depth, node, file_out): - """ - Handle the dimension field. + """Handle the dimension field. + NOTE: Usually we take care of any xml element in xmlparse(...) and - recursion_in_xml_tree(...) functions. But Here it is a bit different. The doc dimension + recursion_in_xml_tree(...) functions. But here it is a bit different: the doc dimension and attributes of dim has been handled inside this function here. """ - # pylint: disable=consider-using-f-string possible_dim_attrs = ["ref", "required", "incr", "refindex"] possible_dimemsion_attrs = ["rank"] # taking care of Dimension tag - file_out.write( - "{indent}{tag}:\n".format( - indent=depth * DEPTH_SIZE, tag=node.tag.split("}", 1)[1] - ) - ) - # Taking care of dimension attributes + indent = depth * DEPTH_SIZE + tag = remove_namespace_from_tag(node.tag) + file_out.write(f"{indent}{tag}:\n") for attr, value in node.attrib.items(): if attr in possible_dimemsion_attrs and not isinstance(value, dict): indent = (depth + 1) * DEPTH_SIZE file_out.write(f"{indent}{attr}: {value}\n") else: raise ValueError( - f"Dimension has got an attribute {attr} that is not valid." + f"Dimension has an attribute {attr} that is not valid." f"Current the allowd atributes are {possible_dimemsion_attrs}." f" Please have a look" ) - # taking carew of dimension doc + # taking care of dimension doc for child in list(node): tag = remove_namespace_from_tag(child.tag) if tag == "doc": @@ -624,21 +605,16 @@ def handle_dimension(self, depth, node, file_out): dim_index_value = "" dim_other_parts = {} dim_cmnt_node = [] - # taking care of dim and doc childs of dimension + # taking care of dim and doc children of dimension for child in list(node): tag = remove_namespace_from_tag(child.tag) child_attrs = child.attrib # taking care of index and value attributes - if tag == ("dim"): + if tag == "dim": # taking care of index and value in format [[index, value]] - dim_index_value = dim_index_value + "[{index}, {value}], ".format( - index=child_attrs["index"] if "index" in child_attrs else "", - value=child_attrs["value"] if "value" in child_attrs else "", - ) - if "index" in child_attrs: - del child_attrs["index"] - if "value" in child_attrs: - del child_attrs["value"] + index = child_attrs.pop("index", "") + value = child_attrs.pop("value", "") + dim_index_value = f"{dim_index_value}[{index}, {value}], " # Taking care of doc comes as child of dim for cchild in list(child): @@ -665,20 +641,18 @@ def handle_dimension(self, depth, node, file_out): # All 'dim' element comments on top of 'dim' yaml key if dim_cmnt_node: for ch_nd in dim_cmnt_node: - self.handel_comment(depth + 1, ch_nd, file_out) + self.handle_comment(depth + 1, ch_nd, file_out) # index and value attributes of dim elements - file_out.write( - "{indent}dim: [{value}]\n".format( - indent=(depth + 1) * DEPTH_SIZE, value=dim_index_value[:-2] or "" - ) - ) + indent = (depth + 1) * DEPTH_SIZE + value = dim_index_value[:-2] or "" + file_out.write(f"{indent}dim: [{value}]\n") + # Write the attributes, except index and value, and doc of dim as child of dim_parameter. - # But tthe doc or attributes for each dim come inside list according to the order of dim. + # But the doc or attributes for each dim come inside list according to the order of dim. if dim_other_parts: - file_out.write( - "{indent}dim_parameters:\n".format(indent=(depth + 1) * DEPTH_SIZE) - ) - # depth = depth + 2 dim_paramerter has child such as doc of dim + indent = (depth + 1) * DEPTH_SIZE + file_out.write(f"{indent}dim_parameters:\n") + # depth = depth + 2 dim_parameter has child such as doc of dim indent = (depth + 2) * DEPTH_SIZE for key, value in dim_other_parts.items(): if key == "doc": @@ -686,7 +660,7 @@ def handle_dimension(self, depth, node, file_out): depth + 2, str(value), key, file_out ) else: - # Increase depth size inside handle_map...() for writting text with one + # Increase depth size inside handle_map...() for writing text with one # more indentation. file_out.write( f"{indent}{key}: " @@ -704,31 +678,28 @@ def handle_enumeration(self, depth, node, file_out): enumeration list. """ - # pylint: disable=consider-using-f-string - check_doc = [] - for child in list(node): + check_doc = False + node_children = list(node) + for child in node_children: if list(child): - check_doc.append(list(child)) + check_doc = True + break # pylint: disable=too-many-nested-blocks if check_doc: - file_out.write( - "{indent}{tag}: \n".format( - indent=depth * DEPTH_SIZE, tag=node.tag.split("}", 1)[1] - ) - ) - for child in list(node): + indent = depth * DEPTH_SIZE + tag = remove_namespace_from_tag(node.tag) + file_out.write(f"{indent}{tag}: \n") + for child in node_children: tag = remove_namespace_from_tag(child.tag) itm_depth = depth + 1 - if tag == ("item"): - file_out.write( - "{indent}{value}: \n".format( - indent=(itm_depth) * DEPTH_SIZE, value=child.attrib["value"] - ) - ) - - if list(child): - for item_doc in list(child): + if tag == "item": + indent = itm_depth * DEPTH_SIZE + value = child.attrib["value"] + file_out.write(f"{indent}{value}: \n") + child_children = list(child) + if child_children: + for item_doc in child_children: if remove_namespace_from_tag(item_doc.tag) == "doc": item_doc_depth = itm_depth + 1 self.handle_not_root_level_doc( @@ -741,74 +712,53 @@ def handle_enumeration(self, depth, node, file_out): remove_namespace_from_tag(item_doc.tag) == CMNT_TAG and self.include_comment ): - self.handel_comment(itm_depth + 1, item_doc, file_out) + self.handle_comment(itm_depth + 1, item_doc, file_out) if tag == CMNT_TAG and self.include_comment: - self.handel_comment(itm_depth + 1, child, file_out) + self.handle_comment(itm_depth + 1, child, file_out) else: - enum_list = "" + enum_list = [] remove_nodes = [] - for item_child in list(node): + for item_child in node_children: tag = remove_namespace_from_tag(item_child.tag) - if tag == ("item"): - enum_list = enum_list + "{value}, ".format( - value=item_child.attrib["value"] - ) + if tag == "item": + value = item_child.attrib["value"] + enum_list.append(value) if tag == CMNT_TAG and self.include_comment: - self.handel_comment(depth, item_child, file_out) + self.handle_comment(depth, item_child, file_out) remove_nodes.append(item_child) for ch_node in remove_nodes: node.remove(ch_node) - file_out.write( - "{indent}{tag}: [{enum_list}]\n".format( - indent=depth * DEPTH_SIZE, - tag=remove_namespace_from_tag(node.tag), - enum_list=enum_list[:-2] or "", - ) - ) + indent = depth * DEPTH_SIZE + tag = remove_namespace_from_tag(node.tag) + enum_list = ", ".join(enum_list) + file_out.write(f"{indent}{tag}: [{enum_list}]\n") def handle_attributes(self, depth, node, file_out): """Handle the attributes parsed from the xml file""" - allowed_attr = [ - "name", - "type", - "units", - "nameType", - "recommended", - "optional", - "minOccurs", - "maxOccurs", - "deprecated", - ] - name = "" + nm_attr = "name" node_attr = node.attrib - if "name" in node_attr: - pass - else: - raise ValueError("Attribute must have an name key.") - rm_key_list = [] # Maintain order: name and type in form name(type) or (type)name that come first - for key, val in node_attr.items(): - if key == "name": - name = val - rm_key_list.append(key) - - for key in rm_key_list: - del node_attr[key] + name = node_attr.pop(nm_attr, "") + if not name: + raise ValueError("Attribute must have an name key.") - file_out.write( - "{indent}{escapesymbol}{name}:\n".format( - indent=depth * DEPTH_SIZE, escapesymbol=r"\@", name=name - ) - ) + indent = depth * DEPTH_SIZE + escapesymbol = r"\@" + file_out.write(f"{indent}{escapesymbol}{name}:\n") tmp_dict = {} exists_dict = {} for key, val in node_attr.items(): + if key not in NXDL_ATTRIBUTES_ATTRIBUTES: + raise ValueError( + f"An attribute ({key}) has been found that is not allowed." + f"The allowed attr is {NXDL_ATTRIBUTES_ATTRIBUTES}." + ) # As both 'minOccurs', 'maxOccurs' and optionality move to the 'exists' - if key in ["minOccurs", "maxOccurs", "optional", "recommended", "required"]: + if key in self.optionality_keys: if "exists" not in tmp_dict: tmp_dict["exists"] = [] self.handle_exists(exists_dict, key, val) @@ -816,11 +766,6 @@ def handle_attributes(self, depth, node, file_out): tmp_dict["unit"] = val else: tmp_dict[key] = val - if key not in allowed_attr: - raise ValueError( - f"An attribute ({key}) has been found that is not allowed." - f"The allowed attr is {allowed_attr}." - ) has_min_max = False has_opt_reco_requ = False @@ -842,94 +787,72 @@ def handle_attributes(self, depth, node, file_out): depth_ = depth + 1 for key, val in tmp_dict.items(): - # Increase depth size inside handle_map...() for writting text with one + # Increase depth size inside handle_map...() for writing text with one # more indentation. file_out.write( f"{depth_ * DEPTH_SIZE}{key}: " f"{handle_mapping_char(val, depth_ + 1, False)}\n" ) - def handel_link(self, depth, node, file_out): - """ - Handle link elements of nxdl - """ + def handle_link(self, depth, node, file_out): + """Handle link elements of nxdl""" - possible_link_attrs = ["name", "target", "napimount"] node_attr = node.attrib # Handle special cases - if "name" in node_attr: - file_out.write( - "{indent}{name}(link):\n".format( - indent=depth * DEPTH_SIZE, name=node_attr["name"] or "" - ) - ) - del node_attr["name"] + name = node_attr.pop("name", "") + if name: + indent = depth * DEPTH_SIZE + file_out.write(f"{indent}{name}(link):\n") depth_ = depth + 1 # Handle general cases for attr_key, val in node_attr.items(): - if attr_key in possible_link_attrs: - file_out.write( - "{indent}{attr}: {value}\n".format( - indent=depth_ * DEPTH_SIZE, attr=attr_key, value=val - ) - ) + if attr_key in NXDL_LINK_ATTRIBUTES: + indent = depth_ * DEPTH_SIZE + file_out.write(f"{indent}{attr_key}: {val}\n") else: raise ValueError( - f"An anexpected attribute '{attr_key}' of link has found." - f"At this moment the alloed keys are {possible_link_attrs}" + f"An unexpected attribute '{attr_key}' of link has found." + f"At this moment the allowed keys are {NXDL_LINK_ATTRIBUTES}" ) - def handel_choice(self, depth, node, file_out): + def handle_choice(self, depth, node, file_out): """ Handle choice element which is a parent node of group. """ - possible_attr = [] - node_attr = node.attrib + name = node_attr.pop("name", "") # Handle special casees - if "name" in node_attr: - file_out.write( - "{indent}{attr}(choice): \n".format( - indent=depth * DEPTH_SIZE, attr=node_attr["name"] - ) - ) - del node_attr["name"] + if name: + indent = depth * DEPTH_SIZE + file_out.write(f"{indent}{name}(choice): \n") depth_ = depth + 1 - # Taking care of general attrinutes. Though, still no attrinutes have found, - # but could be used for future + # Take care of attributes of choice element, attributes may come in future. for attr in node_attr.items(): - if attr in possible_attr: - file_out.write( - "{indent}{attr}: {value}\n".format( - indent=depth_ * DEPTH_SIZE, attr=attr, value=node_attr[attr] - ) - ) + if attr in self.choice_allowed_attr: + indent = depth_ * DEPTH_SIZE + value = node_attr[attr] + file_out.write(f"{indent}{attr}: {value}\n") else: raise ValueError( f"An unexpected attribute '{attr}' of 'choice' has been found." - f"At this moment attributes for choice {possible_attr}" + f"At this moment allowed attributes for choice {self.choice_allowed_attr}" ) - def handel_comment(self, depth, node, file_out): + def handle_comment(self, depth, node, file_out): """ Collect comment element and pass to write_out function """ indent = depth * DEPTH_SIZE - if self.is_last_element_comment: - text = self.comvert_to_ymal_comment(indent, node.text) - self.write_out(indent, text, file_out) - else: - text = self.comvert_to_ymal_comment(indent, node.text) - self.write_out(indent, text, file_out) - self.is_last_element_comment = True + text = self.convert_to_yaml_comment(depth, node.text) + self.write_out(indent, text, file_out) def recursion_in_xml_tree(self, depth, xml_tree, output_yml, verbose): """ Descend lower level in xml tree. If we are in the symbols branch, the recursive - behaviour is not triggered as we already handled the symbols' childs. + behaviour is not triggered as we already handled the symbols' children. """ tree = xml_tree["tree"] @@ -941,14 +864,18 @@ def recursion_in_xml_tree(self, depth, xml_tree, output_yml, verbose): # pylint: disable=too-many-branches, too-many-statements def xmlparse(self, output_yml, xml_tree, depth, verbose): """ - Main of the nxdl2yaml converter. + Main method of the nxdl2yaml converter. It parses XML tree, then prints recursively each level of the tree """ tree = xml_tree["tree"] node = xml_tree["node"] if verbose: - sys.stdout.write(f"Node tag: {remove_namespace_from_tag(node.tag)}\n") - sys.stdout.write(f"Attributes: {node.attrib}\n") + if isinstance(node.tag, Callable): + print(f"Node tag: {node.tag}\n") + print(f"Node text: {node.text}\n") + else: + print(f"Node tag: {remove_namespace_from_tag(node.tag)}\n") + print(f"Attributes: {node.attrib}\n") with open(output_yml, "a", encoding="utf-8") as file_out: tag = remove_namespace_from_tag(node.tag) if tag == "definition": @@ -957,12 +884,10 @@ def xmlparse(self, output_yml, xml_tree, depth, verbose): # Taking care of root level doc and symbols remove_cmnt_n = None last_comment = "" - for child in list(node): + for child in node: tag_tmp = remove_namespace_from_tag(child.tag) if tag_tmp == CMNT_TAG and self.include_comment: - last_comment = self.comvert_to_ymal_comment( - depth * DEPTH_SIZE, child.text - ) + last_comment = self.convert_to_yaml_comment(depth, child.text) remove_cmnt_n = child if tag_tmp == "doc": self.store_root_level_comments("root_doc", last_comment) @@ -981,7 +906,7 @@ def xmlparse(self, output_yml, xml_tree, depth, verbose): node.remove(remove_cmnt_n) remove_cmnt_n = None - if tag == ("doc") and depth != 1: + if tag == "doc" and depth != 1: parent = get_node_parent_info(tree, node)[0] doc_parent = remove_namespace_from_tag(parent.tag) if doc_parent != "item": @@ -1001,46 +926,11 @@ def xmlparse(self, output_yml, xml_tree, depth, verbose): if tag == ("dimensions"): self.handle_dimension(depth, node, file_out) if tag == ("link"): - self.handel_link(depth, node, file_out) + self.handle_link(depth, node, file_out) if tag == ("choice"): - self.handel_choice(depth, node, file_out) + self.handle_choice(depth, node, file_out) if tag == CMNT_TAG and self.include_comment: - self.handel_comment(depth, node, file_out) + self.handle_comment(depth, node, file_out) depth += 1 # Write nested nodes self.recursion_in_xml_tree(depth, xml_tree, output_yml, verbose) - - -def compare_niac_and_my(tree, tree2, verbose, node, root_no_duplicates): - """This function creates two trees with Niac XML file and My XML file. - The main aim is to compare the two trees and create a new one that is the - union of the two initial trees. - """ - root = tree.getroot() - root2 = tree2.getroot() - attrs_list_niac = [] - for nodo in root.iter(node): - attrs_list_niac.append(nodo.attrib) - if verbose: - sys.stdout.write("Attributes found in Niac file: \n") - sys.stdout.write(str(attrs_list_niac) + "\n") - sys.stdout.write(" \n") - sys.stdout.write("Started merging of Niac and My file... \n") - for elem in root.iter(node): - if verbose: - sys.stdout.write("- Niac element inserted: \n") - sys.stdout.write(str(elem.attrib) + "\n") - index = get_node_parent_info(tree, elem)[1] - root_no_duplicates.insert(index, elem) - - for elem2 in root2.iter(node): - index = get_node_parent_info(tree2, elem2)[1] - if elem2.attrib not in attrs_list_niac: - if verbose: - sys.stdout.write("- My element inserted: \n") - sys.stdout.write(str(elem2.attrib) + "\n") - root_no_duplicates.insert(index, elem2) - - if verbose: - sys.stdout.write(" \n") - return root_no_duplicates diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py b/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py index ce14a6d0a1..600c1978a3 100644 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py +++ b/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py @@ -21,44 +21,49 @@ # limitations under the License. # -import os -import sys +import datetime +import pathlib import textwrap -import xml.etree.ElementTree as ET -from xml.dom import minidom +import warnings +from urllib.parse import unquote +import lxml.etree as ET import yaml from ..utils import nxdl_utils as pynxtools_nxlib from .comment_collector import CommentCollector +from .nyaml2nxdl_helper import YAML_ATTRIBUTES_ATTRIBUTES +from .nyaml2nxdl_helper import YAML_FIELD_ATTRIBUTES +from .nyaml2nxdl_helper import YAML_GROUP_ATTRIBUTES +from .nyaml2nxdl_helper import YAML_LINK_ATTRIBUTES from .nyaml2nxdl_helper import LineLoader -from .nyaml2nxdl_helper import cleaning_empty_lines +from .nyaml2nxdl_helper import clean_empty_lines from .nyaml2nxdl_helper import get_yaml_escape_char_reverter_dict +from .nyaml2nxdl_helper import is_dom_comment from .nyaml2nxdl_helper import nx_name_type_resolving from .nyaml2nxdl_helper import remove_namespace_from_tag # pylint: disable=too-many-lines, global-statement, invalid-name DOM_COMMENT = ( - "\n" - "# NeXus - Neutron and X-ray Common Data Format\n" - "# \n" - "# Copyright (C) 2014-2022 NeXus International Advisory Committee (NIAC)\n" - "# \n" - "# This library is free software; you can redistribute it and/or\n" - "# modify it under the terms of the GNU Lesser General Public\n" - "# License as published by the Free Software Foundation; either\n" - "# version 3 of the License, or (at your option) any later version.\n" - "#\n" - "# This library is distributed in the hope that it will be useful,\n" - "# but WITHOUT ANY WARRANTY; without even the implied warranty of\n" - "# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU\n" - "# Lesser General Public License for more details.\n" - "#\n" - "# You should have received a copy of the GNU Lesser General Public\n" - "# License along with this library; if not, write to the Free Software\n" - "# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA\n" - "#\n" - "# For further information, see http://www.nexusformat.org\n" + f"# NeXus - Neutron and X-ray Common Data Format\n" + f"# \n" + f"# Copyright (C) 2014-{datetime.date.today().year} NeXus International Advisory Committee (NIAC)\n" + f"# \n" + f"# This library is free software; you can redistribute it and/or\n" + f"# modify it under the terms of the GNU Lesser General Public\n" + f"# License as published by the Free Software Foundation; either\n" + f"# version 3 of the License, or (at your option) any later version.\n" + f"#\n" + f"# This library is distributed in the hope that it will be useful,\n" + f"# but WITHOUT ANY WARRANTY; without even the implied warranty of\n" + f"# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU\n" + f"# Lesser General Public License for more details.\n" + f"#\n" + f"# You should have received a copy of the GNU Lesser General Public\n" + f"# License along with this library; if not, write to the Free Software\n" + f"# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA\n" + f"#\n" + f"# For further information, see http://www.nexusformat.org\n" ) NX_CLSS = pynxtools_nxlib.get_nx_classes() NX_NEW_DEFINED_CLASSES = ["NX_COMPLEX"] @@ -67,36 +72,26 @@ NX_UNIT_IDNT = "unit" DEPTH_SIZE = " " NX_UNIT_TYPES = pynxtools_nxlib.get_nx_units() +# Initialised in yml_reader() funtion COMMENT_BLOCKS: CommentCollector CATEGORY = "" # Definition would be either 'base' or 'application' def check_for_dom_comment_in_yaml(): """Check the yaml file has dom comment or dom comment needed to be hard coded.""" - dignature_keyword_list = [ - "NeXus", - "GNU Lesser General Public", - "Free Software Foundation", - "Copyright (C)", - "WITHOUT ANY WARRANTY", - ] - # Check for dom comments in first three comments + # Check for dom comments in first five comments dom_comment = "" dom_comment_ind = 1 for ind, comnt in enumerate(COMMENT_BLOCKS[0:5]): - cmnt_list = comnt.get_comment_text() + cmnt_list = comnt.get_comment_text_list() if len(cmnt_list) == 1: text = cmnt_list[0] else: continue - dom_comment = text - dom_comment_ind = ind - for keyword in dignature_keyword_list: - if keyword not in text: - dom_comment = "" - break - if dom_comment: + if is_dom_comment(text): + dom_comment = text + dom_comment_ind = ind break # deactivate the root dom_comment, So that the corresponding comment would not be @@ -134,11 +129,11 @@ def yml_reader(inputfile): def check_for_default_attribute_and_value(xml_element): - """NeXus Groups, fields and attributes might have xml default attributes and valuesthat must + """NeXus Groups, fields and attributes might have xml default attributes and values that must come. For example: 'optional' which is 'true' by default for base class and false otherwise. """ - # base:Default attributes and value for all elements of base class except dimension element + # base: Default attributes and value for all elements of base class except dimension element base_attr_to_val = {"optional": "true"} # application: Default attributes and value for all elements of application class except @@ -150,7 +145,7 @@ def check_for_default_attribute_and_value(xml_element): application_dim_attr_to_val = {"required": "true"} # Eligible tag for default attr and value - elegible_tag = ["group", "field", "attribute"] + eligible_tag = ["group", "field", "attribute"] def set_default_attribute(xml_elem, default_attr_to_val): for deflt_attr, deflt_val in default_attr_to_val.items(): @@ -163,7 +158,7 @@ def set_default_attribute(xml_elem, default_attr_to_val): xml_elem.set(deflt_attr, deflt_val) for child in list(xml_element): - # skiping comment 'function' that mainly collect comment from yaml file. + # skipping comment 'function' that mainly collect comment from yaml file. if not isinstance(child.tag, str): continue tag = remove_namespace_from_tag(child.tag) @@ -172,9 +167,9 @@ def set_default_attribute(xml_elem, default_attr_to_val): set_default_attribute(child, base_dim_attr_to_val) if tag == "dim" and CATEGORY == "application": set_default_attribute(child, application_dim_attr_to_val) - if tag in elegible_tag and CATEGORY == "base": + if tag in eligible_tag and CATEGORY == "base": set_default_attribute(child, base_attr_to_val) - if tag in elegible_tag and CATEGORY == "application": + if tag in eligible_tag and CATEGORY == "application": set_default_attribute(child, application_attr_to_val) check_for_default_attribute_and_value(child) @@ -188,7 +183,7 @@ def yml_reader_nolinetag(inputfile): return parsed_yaml -def check_for_skiped_attributes(component, value, allowed_attr=None, verbose=False): +def check_for_skipped_attributes(component, value, allowed_attr=None, verbose=False): """ Check for any attributes have been skipped or not. NOTE: We should keep in mind about 'doc' @@ -196,7 +191,7 @@ def check_for_skiped_attributes(component, value, allowed_attr=None, verbose=Fal block_tag = ["enumeration"] if value: for attr, val in value.items(): - if attr in ["doc"]: + if attr == "doc": continue if "__line__" in attr or attr in block_tag: continue @@ -208,31 +203,30 @@ def check_for_skiped_attributes(component, value, allowed_attr=None, verbose=Fal and "\\@" not in attr and attr not in allowed_attr and "NX" not in attr - and attr != "dim" and val ): raise ValueError( f"An attribute '{attr}' in part '{component}' has been found" - f". Please check arround line '{value[line_number]}. At this " - f"moment. The allowed attrbutes are {allowed_attr}" + f". Please check around line '{value[line_number]}. At this " + f"time, the allowed attrbutes are {allowed_attr}." ) def format_nxdl_doc(string): """NeXus format for doc string""" string = check_for_mapping_char_other(string) - formatted_doc = "" + string_len = 80 if "\n" not in string: - if len(string) > 80: + if len(string) > string_len: wrapped = textwrap.TextWrapper( - width=80, break_long_words=False, replace_whitespace=False + width=string_len, break_long_words=False, replace_whitespace=False ) string = "\n".join(wrapped.wrap(string)) formatted_doc = "\n" + f"{string}" else: text_lines = string.split("\n") - text_lines = cleaning_empty_lines(text_lines) - formatted_doc += "\n" + "\n".join(text_lines) + text_lines = clean_empty_lines(text_lines) + formatted_doc = "\n" + "\n".join(text_lines) if not formatted_doc.endswith("\n"): formatted_doc += "\n" return formatted_doc @@ -250,13 +244,13 @@ def check_for_mapping_char_other(text): text = "true" if text == "False": text = "false" - # Some escape char is not valid in yaml libray which is written while writting - # yaml file. In the time of writting nxdl revert to that escape char. + # Some escape char is not valid in yaml libray which is written while writing + # yaml file. In the time of writing nxdl revert to that escape char. escape_reverter = get_yaml_escape_char_reverter_dict() for key, val in escape_reverter.items(): if key in text: text = text.replace(key, val) - return str(text).strip() + return text.strip() def xml_handle_doc(obj, value: str, line_number=None, line_loc=None): @@ -285,29 +279,30 @@ def xml_handle_exists(dct, obj, keyword, value): value is not None ), f"Line {dct[line_number]}: exists argument must not be None !" if isinstance(value, list): - if len(value) == 4 and value[0] == "min" and value[2] == "max": - obj.set("minOccurs", str(value[1])) - if str(value[3]) != "infty": - obj.set("maxOccurs", str(value[3])) + if len(value) == 4: + if value[0] == "min" and value[2] == "max": + obj.set("minOccurs", str(value[1])) + if str(value[3]) != "infty": + obj.set("maxOccurs", str(value[3])) + else: + obj.set("maxOccurs", "unbounded") + elif value[0] == "max" and value[2] == "min": + if str(value[1]) != "infty": + obj.set("maxOccurs", str(value[1])) + else: + obj.set("maxOccurs", "unbounded") + obj.set("minOccurs", str(value[3])) else: - obj.set("maxOccurs", "unbounded") + raise ValueError( + f"Line {dct[line_number]}: exists keyword" + f"needs to go either with an optional [recommended] list with two " + f"entries either [min, ] or [max, ], or a list of four " + f"entries [min, , max, ] !" + ) elif len(value) == 2 and value[0] == "min": obj.set("minOccurs", str(value[1])) elif len(value) == 2 and value[0] == "max": obj.set("maxOccurs", str(value[1])) - elif len(value) == 4 and value[0] == "max" and value[2] == "min": - obj.set("minOccurs", str(value[3])) - if str(value[1]) != "infty": - obj.set("maxOccurs", str(value[3])) - else: - obj.set("maxOccurs", "unbounded") - elif len(value) == 4 and (value[0] != "min" or value[2] != "max"): - raise ValueError( - f"Line {dct[line_number]}: exists keyword" - f"needs to go either with an optional [recommended] list with two " - f"entries either [min, ] or [max, ], or a list of four " - f"entries [min, , max, ] !" - ) else: raise ValueError( f"Line {dct[line_number]}: exists keyword " @@ -316,7 +311,7 @@ def xml_handle_exists(dct, obj, keyword, value): f"entries [min, , max, ] !" ) else: - # This clause take optional in all concept except dimension where 'required' key is allowed + # This clause take optional in all cases except dimension where 'required' key is allowed # not the 'optional' key. if value == "optional": obj.set("optional", "true") @@ -328,81 +323,6 @@ def xml_handle_exists(dct, obj, keyword, value): obj.set("minOccurs", "0") -# pylint: disable=too-many-branches, too-many-locals, too-many-statements -def xml_handle_group(dct, obj, keyword, value, verbose=False): - """ - The function deals with group instances - """ - line_number = f"__line__{keyword}" - line_loc = dct[line_number] - xml_handle_comment(obj, line_number, line_loc) - list_of_attr = [ - "name", - "type", - "nameType", - "deprecated", - "optional", - "recommended", - "exists", - "unit", - ] - l_bracket = -1 - r_bracket = -1 - if keyword.count("(") == 1: - l_bracket = keyword.index("(") - if keyword.count(")") == 1: - r_bracket = keyword.index(")") - - keyword_name, keyword_type = nx_name_type_resolving(keyword) - if not keyword_name and not keyword_type: - raise ValueError("A group must have both value and name. Check for group.") - grp = ET.SubElement(obj, "group") - - if l_bracket == 0 and r_bracket > 0: - grp.set("type", keyword_type) - if keyword_name: - grp.set("name", keyword_name) - elif l_bracket > 0: - grp.set("name", keyword_name) - if keyword_type: - grp.set("type", keyword_type) - else: - grp.set("name", keyword_name) - - if value: - rm_key_list = [] - for attr, vval in value.items(): - if "__line__" in attr: - continue - line_number = f"__line__{attr}" - line_loc = value[line_number] - if attr == "doc": - xml_handle_doc(grp, vval, line_number, line_loc) - rm_key_list.append(attr) - rm_key_list.append(line_number) - elif attr == "exists" and vval: - xml_handle_exists(value, grp, attr, vval) - rm_key_list.append(attr) - rm_key_list.append(line_number) - xml_handle_comment(obj, line_number, line_loc, grp) - elif attr == "unit": - xml_handle_units(grp, vval) - xml_handle_comment(obj, line_number, line_loc, grp) - elif attr in list_of_attr and not isinstance(vval, dict) and vval: - validate_field_attribute_and_value(attr, vval, list_of_attr, value) - grp.set(attr, check_for_mapping_char_other(vval)) - rm_key_list.append(attr) - rm_key_list.append(line_number) - xml_handle_comment(obj, line_number, line_loc, grp) - - for key in rm_key_list: - del value[key] - # Check for skipped attrinutes - check_for_skiped_attributes("group", value, list_of_attr, verbose) - if isinstance(value, dict) and value != {}: - recursive_build(grp, value, verbose) - - def xml_handle_dimensions(dct, obj, keyword, value: dict): """ This function creates a 'dimensions' element instance, and appends it to an existing element @@ -423,12 +343,12 @@ def xml_handle_dimensions(dct, obj, keyword, value: dict): possible_dimension_attrs = ["rank"] # nxdl attributes line_number = f"__line__{keyword}" line_loc = dct[line_number] - assert "dim" in value.keys(), ( - f"Line {line_loc}: No dim as child of dimension has " f"been found." - ) + assert ( + "dim" in value.keys() + ), f"Line {line_loc}: No dim as child of dimension has been found." xml_handle_comment(obj, line_number, line_loc) dims = ET.SubElement(obj, "dimensions") - # Consider all the childs under dimension is dim element and + # Consider all the children under dimension is dim element and # its attributes rm_key_list = [] @@ -443,7 +363,7 @@ def xml_handle_dimensions(dct, obj, keyword, value: dict): if isinstance(rank, int) and rank < 0: raise ValueError( f"Dimension must have some info about rank which is not " - f"available. Please check arround Line: {dct[line_number]}" + f"available. Please check around Line: {dct[line_number]}" ) dims.set(key, str(val)) rm_key_list.append(key) @@ -469,35 +389,6 @@ def xml_handle_dimensions(dct, obj, keyword, value: dict): recursive_build(dims, value, verbose=None) -def xml_handle_dim(dct, obj, keyword, value): - """ - This function creates a 'dimensions' element instance, and appends it to an existing element. - - Allows for handling numpy tensor notation of dimensions. That is, - dimensions: - rank: 1 - dim: (1, 3) - can be replaced by - dim: (3,) - - """ - if isinstance(value, str) is True: - if value[0] == "(" and value[-1] == ")": - valid_dims = [] - for entry in value[1:-1].replace(" ", "").split(","): - if len(entry) > 0: # ignore trailing comma and empty mnemonics - valid_dims.append(entry) - if len(valid_dims) > 0: - dims = ET.SubElement(obj, "dimensions") - dims.set("rank", str(len(valid_dims))) - dim_idx = 1 - for dim_name in valid_dims: - dim = ET.SubElement(dims, "dim") - dim.set("index", str(dim_idx)) - dim.set("value", str(dim_name)) - dim_idx += 1 - - # pylint: disable=too-many-locals, too-many-arguments def xml_handle_dim_from_dimension_dict( dct, dims_obj, keyword, value, rank, verbose=False @@ -507,8 +398,8 @@ def xml_handle_dim_from_dimension_dict( NOTE: The inputs 'keyword' and 'value' are as input for xml_handle_dimensions function. please also read note in xml_handle_dimensions. """ - - possible_dim_attrs = ["ref", "incr", "refindex", "required"] + deprecated_dim_attrs = ["ref", "incr", "refindex"] + possible_dim_attrs = [*deprecated_dim_attrs, "required"] # Some attributes might have equivalent name e.g. 'required' is correct one and # 'optional' could be another name. Then change attribute to the correct one. @@ -529,11 +420,11 @@ def xml_handle_dim_from_dimension_dict( line_loc = value[line_number] # dim comes in precedence if attr == "dim": - # dim consists of list of [index, value] + # dim consists of [index, value] list llist_ind_value = vvalue - assert isinstance(llist_ind_value, list), ( - f"Line {value[line_number]}: dim" f"argument not a list !" - ) + assert isinstance( + llist_ind_value, list + ), f"Line {value[line_number]}: dim argument not a list !" xml_handle_comment(dims_obj, line_number, line_loc) if isinstance(rank, int) and rank > 0: assert rank == len(llist_ind_value), ( @@ -578,6 +469,12 @@ def xml_handle_dim_from_dimension_dict( elif isinstance(vvval, list) and i >= len(vvval): pass else: + if kkkey in deprecated_dim_attrs: + dep_text = ( + f"Attrbute {kkkey} is deprecated. " + f"Check attributes after line {cmnt_loc}" + ) + warnings.warn(dep_text, DeprecationWarning) for i, dim in enumerate(dim_list): # all atribute of dims comes as list if isinstance(vvval, list) and i < len(vvval): @@ -596,13 +493,13 @@ def xml_handle_dim_from_dimension_dict( else: raise ValueError( f"Got unexpected block except 'dim' and 'dim_parameters'." - f"Please check arround line {line_number}" + f"Please check around line {line_number}" ) for key in rm_key_list: del value[key] - check_for_skiped_attributes("dim", value, possible_dim_attrs, verbose) + check_for_skipped_attributes("dim", value, possible_dim_attrs, verbose) def xml_handle_enumeration(dct, obj, keyword, value, verbose): @@ -646,7 +543,6 @@ def xml_handle_link(dct, obj, keyword, value, verbose): line_number = f"__line__{keyword}" line_loc = dct[line_number] xml_handle_comment(obj, line_number, line_loc) - possible_attrs = ["name", "target", "napimount"] name = keyword[:-6] link_obj = ET.SubElement(obj, "link") link_obj.set("name", str(name)) @@ -662,7 +558,7 @@ def xml_handle_link(dct, obj, keyword, value, verbose): xml_handle_doc(link_obj, vval, line_number, line_loc) rm_key_list.append(attr) rm_key_list.append(line_number) - elif attr in possible_attrs and not isinstance(vval, dict): + elif attr in YAML_LINK_ATTRIBUTES and not isinstance(vval, dict): if vval: link_obj.set(attr, str(vval)) rm_key_list.append(attr) @@ -671,8 +567,8 @@ def xml_handle_link(dct, obj, keyword, value, verbose): for key in rm_key_list: del value[key] - # Check for skipped attrinutes - check_for_skiped_attributes("link", value, possible_attrs, verbose) + # Check for skipped attributes + check_for_skipped_attributes("link", value, YAML_LINK_ATTRIBUTES, verbose) if isinstance(value, dict) and value != {}: recursive_build(link_obj, value, verbose=None) @@ -685,8 +581,8 @@ def xml_handle_choice(dct, obj, keyword, value, verbose=False): line_number = f"__line__{keyword}" line_loc = dct[line_number] xml_handle_comment(obj, line_number, line_loc) - # Add attributes in possible if new attributs have been added nexus definition. - possible_attr = [] + # Add to this tuple if new attributes have been added to nexus definition. + possible_attr = () choice_obj = ET.SubElement(obj, "choice") # take care of special attributes name = keyword[:-8] @@ -712,8 +608,8 @@ def xml_handle_choice(dct, obj, keyword, value, verbose=False): for key in rm_key_list: del value[key] - # Check for skipped attrinutes - check_for_skiped_attributes("choice", value, possible_attr, verbose) + # Check for skipped attributes + check_for_skipped_attributes("choice", value, possible_attr, verbose) if isinstance(value, dict) and value != {}: recursive_build(choice_obj, value, verbose=None) @@ -724,7 +620,7 @@ def xml_handle_symbols(dct, obj, keyword, value: dict): line_number = f"__line__{keyword}" line_loc = dct[line_number] assert ( - len(list(value.keys())) >= 1 + len(list(value.keys())) > 0 ), f"Line {line_loc}: symbols table must not be empty !" xml_handle_comment(obj, line_number, line_loc) syms = ET.SubElement(obj, "symbols") @@ -746,12 +642,10 @@ def xml_handle_symbols(dct, obj, keyword, value: dict): vvalue, str ), f"Line {line_loc}: put a comment in doc string !" sym = ET.SubElement(syms, "symbol") - sym.set("name", str(kkeyword)) - # sym_doc = ET.SubElement(sym, 'doc') + sym.set("name", kkeyword) xml_handle_doc(sym, vvalue) rm_key_list.append(kkeyword) rm_key_list.append(line_number) - # sym_doc.text = '\n' + textwrap.fill(vvalue, width=70) + '\n' for key in rm_key_list: del value[key] @@ -763,9 +657,7 @@ def check_keyword_variable(verbose, dct, keyword, value): """ keyword_name, keyword_type = nx_name_type_resolving(keyword) if verbose: - sys.stdout.write( - f"{keyword_name}({keyword_type}): value type is {type(value)}\n" - ) + print(f"{keyword_name}({keyword_type}): value type is {type(value)}\n") if keyword_name == "" and keyword_type == "": line_number = f"__line__{keyword}" raise ValueError(f"Line {dct[line_number]}: found an improper yaml key !") @@ -773,7 +665,7 @@ def check_keyword_variable(verbose, dct, keyword, value): def helper_keyword_type(kkeyword_type): """ - This function is returning a value of keyword_type if it belong to NX_TYPE_KEYS + Return a value of keyword_type if it belong to NX_TYPE_KEYS """ if kkeyword_type in NX_TYPE_KEYS: return kkeyword_type @@ -785,7 +677,7 @@ def verbose_flag(verbose, keyword, value): Verbose stdout printing for nested levels of yaml file, if verbose flag is active """ if verbose: - sys.stdout.write(f" key:{keyword}; value type is {type(value)}\n") + print(f"key:{keyword}; value type is {type(value)}\n") def xml_handle_attributes(dct, obj, keyword, value, verbose): @@ -794,19 +686,6 @@ def xml_handle_attributes(dct, obj, keyword, value, verbose): line_number = f"__line__{keyword}" line_loc = dct[line_number] xml_handle_comment(obj, line_number, line_loc) - # list of possible attribute of xml attribute elementsa - attr_attr_list = [ - "name", - "type", - "unit", - "nameType", - "optional", - "recommended", - "minOccurs", - "maxOccurs", - "deprecated", - "exists", - ] # as an attribute identifier keyword_name, keyword_typ = nx_name_type_resolving(keyword) line_number = f"__line__{keyword}" @@ -827,7 +706,9 @@ def xml_handle_attributes(dct, obj, keyword, value, verbose): continue line_number = f"__line__{attr}" line_loc = value[line_number] - if attr in ["doc", *attr_attr_list] and not isinstance(attr_val, dict): + if attr in ["doc", *YAML_ATTRIBUTES_ATTRIBUTES] and not isinstance( + attr_val, dict + ): if attr == "unit": elemt_obj.set(f"{attr}s", str(value[attr])) rm_key_list.append(attr) @@ -852,8 +733,10 @@ def xml_handle_attributes(dct, obj, keyword, value, verbose): for key in rm_key_list: del value[key] - # Check cor skiped attribute - check_for_skiped_attributes("Attribute", value, attr_attr_list, verbose) + # Check cor skipped attribute + check_for_skipped_attributes( + "Attribute", value, YAML_ATTRIBUTES_ATTRIBUTES, verbose + ) if value: recursive_build(elemt_obj, value, verbose) @@ -864,15 +747,14 @@ def validate_field_attribute_and_value(v_attr, vval, allowed_attribute, value): and invalid value. """ - # check for empty val if not isinstance(vval, dict) and not str(vval): # check for empty value line_number = f"__line__{v_attr}" raise ValueError( f"In a field a valid attrbute ('{v_attr}') found that is not stored." - f" Please check arround line {value[line_number]}" + f" Please check around line {value[line_number]}" ) - # The bellow elements might come as child element + # The below elements might come as child element skipped_child_name = ["doc", "dimension", "enumeration", "choice", "exists"] # check for invalid key or attributes if ( @@ -885,46 +767,16 @@ def validate_field_attribute_and_value(v_attr, vval, allowed_attribute, value): line_number = f"__line__{v_attr}" raise ValueError( f"In a field or group a invalid attribute ('{v_attr}') or child has found." - f" Please check arround line {value[line_number]}." + f" Please check around line {value[line_number]}." ) -def xml_handle_fields(obj, keyword, value, line_annot, line_loc, verbose=False): - """ - Handle a field in yaml file. - When a keyword is NOT: - symbol, - NX baseclass member, - attribute (\\@), - doc, - enumerations, - dimension, - exists, - then the not empty keyword_name is a field! - This simple function will define a new node of xml tree - """ - # List of possible attributes of xml elements - allowed_attr = [ - "name", - "type", - "nameType", - "unit", - "minOccurs", - "long_name", - "axis", - "signal", - "deprecated", - "axes", - "exists", - "data_offset", - "interpretation", - "maxOccurs", - "primary", - "recommended", - "optional", - "stride", - ] - +def xml_handle_fields_or_group( + dct, obj, keyword, value, ele_type, allowed_attr, verbose=False +): + """Handle a field or group in yaml file.""" + line_annot = f"__line__{keyword}" + line_loc = dct[line_annot] xml_handle_comment(obj, line_annot, line_loc) l_bracket = -1 r_bracket = -1 @@ -934,9 +786,18 @@ def xml_handle_fields(obj, keyword, value, line_annot, line_loc, verbose=False): r_bracket = keyword.index(")") keyword_name, keyword_type = nx_name_type_resolving(keyword) - if not keyword_type and not keyword_name: - raise ValueError("Check for name or type in field.") - elemt_obj = ET.SubElement(obj, "field") + if ele_type == "field" and not keyword_name: + raise ValueError( + f"No name for NeXus {ele_type} has been found." + f"Check around line:{line_loc}" + ) + elif not keyword_type and not keyword_name: + raise ValueError( + f"No name or type for NeXus {ele_type} has been found." + f"Check around line: {line_loc}" + ) + + elemt_obj = ET.SubElement(obj, ele_type) # type come first if l_bracket == 0 and r_bracket > 0: @@ -973,7 +834,7 @@ def xml_handle_fields(obj, keyword, value, line_annot, line_loc, verbose=False): rm_key_list.append(attr) rm_key_list.append(line_number) xml_handle_comment(obj, line_number, line_loc, elemt_obj) - elif attr == "unit": + elif ele_type == "field" and attr == "unit": xml_handle_units(elemt_obj, vval) xml_handle_comment(obj, line_number, line_loc, elemt_obj) elif attr in allowed_attr and not isinstance(vval, dict) and vval: @@ -985,8 +846,8 @@ def xml_handle_fields(obj, keyword, value, line_annot, line_loc, verbose=False): for key in rm_key_list: del value[key] - # Check for skipped attrinutes - check_for_skiped_attributes("field", value, allowed_attr, verbose) + # Check for skipped attributes + check_for_skipped_attributes(ele_type, value, allowed_attr, verbose) if isinstance(value, dict) and value != {}: recursive_build(elemt_obj, value, verbose) @@ -999,44 +860,50 @@ def xml_handle_comment( xml_ele: ET.Element = None, is_def_cmnt: bool = False, ): - """ - Add xml comment: check for comments that has the same 'line_annotation' - (e.g. __line__data) and the same line_loc_no (e.g. 30). After that, i - does of three tasks: - 1. Returns list of comments texts (multiple members if element has multiple comments) - 2. Rearrange comment element and xml_ele where comment comes first. - 3. Append comment element when no xml_ele will no be provided. + """Handle comment. + + Add xml comment: check for comments searched by 'line_annotation' + (e.g. __line__data) and line_loc_no (e.g. 30). It + does following tasks: + + 1. Rearrange comment elements of xml_ele and xml_ele where comment comes first. + 2. Append comment element when no xml_ele found as general comments. """ line_info = (line_annotation, int(line_loc_no)) if line_info in COMMENT_BLOCKS: # noqa: F821 - cmnt = COMMENT_BLOCKS.get_coment_by_line_info(line_info) # noqa: F821 - cmnt_text = cmnt.get_comment_text() + cmnt = COMMENT_BLOCKS.get_comment_by_line_info(line_info) # noqa: F821 + cmnt_text = cmnt.get_comment_text_list() + # Check comment for definition element and return if is_def_cmnt: return cmnt_text if xml_ele is not None: obj.remove(xml_ele) for string in cmnt_text: - si_comnt = ET.Comment(string) - obj.append(si_comnt) + # Format comment string to preserve text nxdl to yaml and vice versa + string = format_nxdl_doc(string) + obj.append(ET.Comment(string)) obj.append(xml_ele) elif not is_def_cmnt and xml_ele is None: for string in cmnt_text: - si_comnt = ET.Comment(string) - obj.append(si_comnt) - else: - raise ValueError("Provied correct parameter values.") - return "" + obj.append(ET.Comment(string)) + # The searched comment is not related with definition element + return [] -def recursive_build(obj, dct, verbose): - """obj is the current node of the XML tree where we want to append to, - dct is a dictionary object which represents the content of a child to obj - dct may contain further dictionary nests, representing NXDL groups, - which trigger recursive processing - NXDL fields may contain attributes but trigger no recursion so attributes are leafs. +def recursive_build(obj, dct, verbose): + """Walk through nested dictionary. + Parameters: + ----------- + obj : ET.Element + Obj is the current node of the XML tree where we want to append to. + dct : dict + dct is the nested python dictionary which represents the content of a child and + its successors. + + Note: NXDL fields may contain attributes but trigger no recursion so attributes are leafs. """ for keyword, value in iter(dct.items()): if "__line__" in keyword: @@ -1046,15 +913,13 @@ def recursive_build(obj, dct, verbose): keyword_name, keyword_type = nx_name_type_resolving(keyword) check_keyword_variable(verbose, dct, keyword, value) if verbose: - sys.stdout.write( - f"keyword_name:{keyword_name} keyword_type {keyword_type}\n" - ) + print(f"keyword_name:{keyword_name} keyword_type {keyword_type}\n") if keyword[-6:] == "(link)": xml_handle_link(dct, obj, keyword, value, verbose) elif keyword[-8:] == "(choice)": xml_handle_choice(dct, obj, keyword, value) - # The bellow xml_symbol clause is for the symbols that come ubde filed or attributes + # The below xml_symbol clause is for the symbols that come ubde filed or attributes # Root level symbols has been inside nyaml2nxdl() elif keyword_type == "" and keyword_name == "symbols": xml_handle_symbols(dct, obj, keyword, value) @@ -1062,8 +927,17 @@ def recursive_build(obj, dct, verbose): elif (keyword_type in NX_CLSS) or ( keyword_type not in [*NX_TYPE_KEYS, "", *NX_NEW_DEFINED_CLASSES] ): + elem_type = "group" # we can be sure we need to instantiate a new group - xml_handle_group(dct, obj, keyword, value, verbose) + xml_handle_fields_or_group( + dct, + obj, + keyword, + value, + elem_type, + YAML_GROUP_ATTRIBUTES, + verbose=False, + ) elif keyword_name[0:2] == NX_ATTR_IDNT: # check if obj qualifies xml_handle_attributes(dct, obj, keyword, value, verbose) @@ -1073,50 +947,72 @@ def recursive_build(obj, dct, verbose): xml_handle_units(obj, value) elif keyword == "enumeration": xml_handle_enumeration(dct, obj, keyword, value, verbose) - elif keyword == "dimensions": xml_handle_dimensions(dct, obj, keyword, value) - elif keyword == "dim": - xml_handle_dim(dct, obj, keyword, value) - elif keyword == "exists": xml_handle_exists(dct, obj, keyword, value) # Handles fileds e.g. AXISNAME elif keyword_name != "" and "__line__" not in keyword_name: - xml_handle_fields(obj, keyword, value, line_number, line_loc, verbose) + elem_type = "field" + xml_handle_fields_or_group( + dct, + obj, + keyword, + value, + elem_type, + YAML_FIELD_ATTRIBUTES, + verbose=False, + ) else: raise ValueError( - f"An unfamiliar type of element {keyword} has been found which is " - f"not be able to be resolved. Chekc arround line {dct[line_number]}" + f"An unknown type of element {keyword} has been found which is " + f"not be able to be resolved. Check around line {dct[line_number]}" ) -def pretty_print_xml(xml_root, output_xml, def_comments=None): +def extend_doc_type(doc_type, new_component, comment=False): + """Extend doc type for etree.tostring function + + Extend doc type to build DOM and process instruction comments. """ + start_sym = "" + if comment: + start_sym = "" + return doc_type + "\n" + start_sym + new_component + end_sym + + +def pretty_print_xml(xml_root, output_xml, def_comments=None): + """Print in nxdl.xml file. + Print better human-readable indented and formatted xml file using built-in libraries and preceding XML processing instruction """ - dom = minidom.parseString(ET.tostring(xml_root, encoding="utf-8", method="xml")) - proc_instractionn = dom.createProcessingInstruction( - "xml-stylesheet", 'type="text/xsl" href="nxdlformat.xsl"' - ) - dom_comment = dom.createComment(DOM_COMMENT) - root = dom.firstChild - dom.insertBefore(proc_instractionn, root) - dom.insertBefore(dom_comment, root) + # Handle DOM as doc_type + doc_type = '' + if DOM_COMMENT: + doc_type = extend_doc_type(doc_type, DOM_COMMENT, comment=True) if def_comments: for string in def_comments: - def_comt_ele = dom.createComment(string) - dom.insertBefore(def_comt_ele, root) - - xml_string = dom.toprettyxml(indent=1 * DEPTH_SIZE, newl="\n", encoding="UTF-8") - with open("tmp.xml", "wb") as file_tmp: + doc_type = extend_doc_type(doc_type, string, comment=True) + + tmp_xml = "tmp.xml" + xml_string = ET.tostring( + xml_root, + pretty_print=True, + encoding="UTF-8", + xml_declaration=True, + doctype=doc_type, + ) + with open(tmp_xml, "wb") as file_tmp: file_tmp.write(xml_string) flag = False - with open("tmp.xml", "r", encoding="utf-8") as file_out: + with open(tmp_xml, "r", encoding="utf-8") as file_out: with open(output_xml, "w", encoding="utf-8") as file_out_mod: for i in file_out.readlines(): + i = unquote(i.encode()) if "" not in i and "" not in i and flag is False: file_out_mod.write(i) elif "" in i and "" in i: @@ -1130,17 +1026,17 @@ def pretty_print_xml(xml_root, output_xml, def_comments=None): elif "" not in i and "" in i and flag is True: file_out_mod.write(white_spaces * " " + i) flag = False - os.remove("tmp.xml") + tmp_xml_path = pathlib.Path(tmp_xml) + pathlib.Path.unlink(tmp_xml_path) # pylint: disable=too-many-statements def nyaml2nxdl(input_file: str, out_file, verbose: bool): """ Main of the nyaml2nxdl converter, creates XML tree, namespace and - schema, definitions then evaluates a dictionary nest of groups recursively and - fields or (their) attributes as childs of the groups + schema, definitions then evaluates a nested dictionary of groups recursively and + fields or (their) attributes as children of the groups """ - def_attributes = [ "deprecated", "ignoreExtraGroups", @@ -1153,12 +1049,15 @@ def nyaml2nxdl(input_file: str, out_file, verbose: bool): yml_appdef = yml_reader(input_file) def_cmnt_text = [] if verbose: - sys.stdout.write(f"input-file: {input_file}\n") - sys.stdout.write( - "application/base contains the following root-level entries:\n" - ) - sys.stdout.write(str(yml_appdef.keys())) - xml_root = ET.Element("definition", {}) + print(f"input-file: {input_file}\n") + print("application/base contains the following root-level entries:\n") + print(str(yml_appdef.keys())) + # etree does not allow to set namespace-map after root creation + # So, mimic a nsmap and fill it later as dict has hash property + nsmap = { + None: "http://definition.nexusformat.org/nxdl/3.1", + } + xml_root = ET.Element("definition", attrib={}, nsmap=nsmap) assert ( "category" in yml_appdef.keys() ), "Required root-level keyword category is missing!" @@ -1181,13 +1080,13 @@ def nyaml2nxdl(input_file: str, out_file, verbose: bool): cmnt_text = xml_handle_comment( xml_root, line_number, line_loc_no, is_def_cmnt=True ) - def_cmnt_text += cmnt_text if cmnt_text else [] + def_cmnt_text += cmnt_text del yml_appdef[line_number] del yml_appdef[kkey] - # Taking care or name and extends + # Taking care of name and extends elif "NX" in kkey: - # Tacking the attribute order but the correct value will be stored later + # Taking the attribute order but the correct value will be stored later # check for name first or type first if (NXobject)NXname then type first l_bracket_ind = kkey.rfind("(") r_bracket_ind = kkey.rfind(")") @@ -1216,23 +1115,23 @@ def nyaml2nxdl(input_file: str, out_file, verbose: bool): xml_root.set("type", "group") # Taking care of namespaces namespaces = { - "xmlns": "http://definition.nexusformat.org/nxdl/3.1", - "xmlns:xsi": "http://www.w3.org/2001/XMLSchema-instance", - "xsi:schemaLocation": "http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd", + "xsi": "http://www.w3.org/2001/XMLSchema-instance", } - for key, ns_ in namespaces.items(): - xml_root.attrib[key] = ns_ + # Fill nsmap variable here + nsmap.update(namespaces) + xml_root.attrib[ + "{http://www.w3.org/2001/XMLSchema-instance}schemaLocation" + ] = "http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd".replace(" ", "%20") + # Taking care of Symbols elements if "symbols" in yml_appdef.keys(): xml_handle_symbols(yml_appdef, xml_root, "symbols", yml_appdef["symbols"]) del yml_appdef["symbols"] del yml_appdef["__line__symbols"] - assert ( isinstance(yml_appdef["doc"], str) and yml_appdef["doc"] != "" - ), "Doc \ -has to be a non-empty string!" + ), "Doc has to be a non-empty string!" line_number = "__line__doc" line_loc_no = yml_appdef[line_number] @@ -1265,10 +1164,10 @@ def nyaml2nxdl(input_file: str, out_file, verbose: bool): (lin_annot, line_loc) = post_comment.get_line_info() xml_handle_comment(xml_root, lin_annot, line_loc) - # Note: Just to keep the functionality if we need this functionality later. + # Note: Just to keep the functionality if we need this later. default_attr = False if default_attr: check_for_default_attribute_and_value(xml_root) pretty_print_xml(xml_root, out_file, def_cmnt_text) if verbose: - sys.stdout.write("Parsed YAML to NXDL successfully\n") + print("Parsed YAML to NXDL successfully\n") diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl_helper.py b/dev_tools/nyaml2nxdl/nyaml2nxdl_helper.py index 8eda728e35..7587df1de1 100644 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl_helper.py +++ b/dev_tools/nyaml2nxdl/nyaml2nxdl_helper.py @@ -1,7 +1,8 @@ #!/usr/bin/env python3 -"""Main file of yaml2nxdl tool. -Users create NeXus instances by writing a YAML file -which details a hierarchy of data/metadata elements +"""File consists of helping functions and variables. + +The functions and variables are utilised in the converting tool +to convert from nyaml to nxdl and vice versa. """ # -*- coding: utf-8 -*- # @@ -22,11 +23,8 @@ # limitations under the License. # - -# Yaml library does not except the keys (escapechar "\t" and yaml separator ":") -# So the corresponding value is to skip them and -# and also carefull about this order import hashlib +from typing import Callable from yaml.composer import Composer from yaml.constructor import Constructor @@ -34,35 +32,94 @@ from yaml.nodes import ScalarNode from yaml.resolver import BaseResolver -# NOTE: If any one change one of the bellow dict please change it for both -ESCAPE_CHAR_DICT_IN_YAML = {"\t": " ", "':'": ":"} - -ESCAPE_CHAR_DICT_IN_XML = {" ": "\t", "':'": ":"} +# Yaml library does not except the keys (escape char "\t" and yaml separator ":") +ESCAPE_CHAR_DICT_IN_YAML = {"\t": " "} +ESCAPE_CHAR_DICT_IN_XML = {val: key for key, val in ESCAPE_CHAR_DICT_IN_YAML.items()} + +# Set up attributes for nxdl version +NXDL_GROUP_ATTRIBUTES = ( + "optional", + "recommended", + "name", + "type", + "maxOccurs", + "minOccurs", + "deprecated", +) +NXDL_FIELD_ATTRIBUTES = ( + "optional", + "recommended", + "name", + "type", + "axes", + "axis", + "data_offset", + "interpretation", + "long_name", + "maxOccurs", + "minOccurs", + "nameType", + "primary", + "signal", + "stride", + "required", + "deprecated", + "units", +) + +NXDL_ATTRIBUTES_ATTRIBUTES = ( + "name", + "type", + "recommended", + "optional", + "deprecated", +) + +NXDL_LINK_ATTRIBUTES = ("name", "target", "napimount") + +# Set up attributes for yaml version +YAML_GROUP_ATTRIBUTES = (*NXDL_GROUP_ATTRIBUTES, "exists") + +YAML_FIELD_ATTRIBUTES = (*NXDL_FIELD_ATTRIBUTES[0:-1], "unit", "exists") + +YAML_ATTRIBUTES_ATTRIBUTES = ( + *NXDL_ATTRIBUTES_ATTRIBUTES, + "minOccurs", + "maxOccurs", + "exists", +) + +YAML_LINK_ATTRIBUTES = NXDL_LINK_ATTRIBUTES def remove_namespace_from_tag(tag): """Helper function to remove the namespace from an XML tag.""" - - return tag.split("}")[-1] + if isinstance(tag, Callable) and tag.__name__ == "Comment": + return "!--" + else: + return tag.split("}")[-1] class LineLoader(Loader): # pylint: disable=too-many-ancestors - """ + """Class to load yaml file with extra non yaml items. + LineLoader parses a yaml into a python dictionary extended with extra items. The new items have as keys __line__ and as values the yaml file line number """ def compose_node(self, parent, index): + """Compose node and return node.""" # the line number where the previous token has ended (plus empty lines) node = Composer.compose_node(self, parent, index) node.__line__ = self.line + 1 return node def construct_mapping(self, node, deep=False): - node_pair_lst = node.value + """Construct mapping between node info and line info.""" node_pair_lst_for_appending = [] - for key_node in node_pair_lst: + # Visit through node-pair list + for key_node in node.value: shadow_key_node = ScalarNode( tag=BaseResolver.DEFAULT_SCALAR_TAG, value="__line__" + key_node[0].value, @@ -72,7 +129,7 @@ def construct_mapping(self, node, deep=False): ) node_pair_lst_for_appending.append((shadow_key_node, shadow_value_node)) - node.value = node_pair_lst + node_pair_lst_for_appending + node.value = node.value + node_pair_lst_for_appending return Constructor.construct_mapping(self, node, deep=deep) @@ -88,9 +145,7 @@ def get_yaml_escape_char_reverter_dict(): def type_check(nx_type): - """ - Check for nexus type if type is NX_CHAR get '' or get as it is. - """ + """Check for nexus type if type is NX_CHAR get '' or get as it is.""" if nx_type in ["NX_CHAR", ""]: nx_type = "" @@ -100,48 +155,46 @@ def type_check(nx_type): def get_node_parent_info(tree, node): - """ - Return tuple of (parent, index) where: - parent = node of parent within tree - index = index of node under parent + """Return tuple of (parent, index). + + parent = parent node is the first level node under tree node + index = index of grand child node of tree """ + # map from grand child to parent which is child of tree parent_map = {c: p for p in tree.iter() for c in p} parent = parent_map[node] return parent, list(parent).index(node) -def cleaning_empty_lines(line_list): - """ - Cleaning up empty lines on top and bottom. - """ +def clean_empty_lines(line_list): + """Clean up empty lines by top part and bottom and part.""" if not isinstance(line_list, list): line_list = line_list.split("\n") if "\n" in line_list else [""] - # Clining up top empty lines - while True: - if line_list[0].strip(): + start_non_empty_line = -1 + ends_non_empty_line = None + # Find the index of first non-empty line + for ind, line in enumerate(line_list): + if len(line.strip()) > 1: + start_non_empty_line = ind break - line_list = line_list[1:] - if len(line_list) == 0: - line_list.append("") - return line_list - - # Clining bottom empty lines - while True: - if line_list[-1].strip(): + + # Find the index of the last non-empty line + for ind, line in enumerate(reversed(line_list)): + if len(line.strip()) > 1: + ends_non_empty_line = -ind break - line_list = line_list[0:-1] - if len(line_list) == 0: - line_list.append("") - return line_list - return line_list + if ends_non_empty_line == 0: + ends_non_empty_line = None + return line_list[start_non_empty_line:ends_non_empty_line] def nx_name_type_resolving(tmp): - """ - extracts the eventually custom name {optional_string} + """Separate name and NeXus type + + Extracts the eventual custom name {optional_string} and type {nexus_type} from a YML section string. YML section string syntax: optional_string(nexus_type) """ @@ -150,6 +203,14 @@ def nx_name_type_resolving(tmp): # either an nx_ (type, base, candidate) class contains only 1 '(' and ')' index_start = tmp.index("(") index_end = tmp.index(")", index_start + 1) + if index_start > index_end: + raise ValueError( + f"Check name and type combination {tmp} which can not be resolved." + ) + if index_end - index_start == 1: + raise ValueError( + f"Check name(type) combination {tmp}, properly not defined." + ) typ = tmp[index_start + 1 : index_end] nam = tmp.replace("(" + typ + ")", "") return nam, typ @@ -185,17 +246,21 @@ def extend_yamlfile_by_nxdl_as_comment( f1_obj.write(line) with open(file_to_be_appended, mode="r", encoding="utf-8") as f2_obj: - lines = f2_obj.readlines() - for line in lines: + for line in f2_obj: f1_obj.write(f"# {line}") def separate_hash_yaml_and_nxdl(yaml_file, sep_yaml, sep_xml): - """Separate the provided yaml file into yaml, nxdl and hash if yaml was extended with - nxdl at the end of yaml by + """Separate yaml, SHA hash and nxdl parts. + + Separate the provided yaml file into yaml, nxdl and hash if yaml was extended with + nxdl at the end of yaml as + + '\n# ++++++++++++++++++++++++++++++++++ SHA HASH \ ++++++++++++++++++++++++++++++++++\n' # ' + """ sha_hash = "" with open(yaml_file, "r", encoding="utf-8") as inp_file: @@ -204,20 +269,19 @@ def separate_hash_yaml_and_nxdl(yaml_file, sep_yaml, sep_xml): with open(sep_yaml, "w", encoding="utf-8") as yml_f_ob, open( sep_xml, "w", encoding="utf-8" ) as xml_f_ob: - last_line = "" write_on_yaml = True - for ind, line in enumerate(lines): - if ind == 0: - last_line = line - # Write in file when ensured that the nest line is not with '++ SHA HASH ++' - elif "++ SHA HASH ++" not in line and write_on_yaml: + + last_line = lines[0] + for line in lines[1:]: + # Write in file when ensured that the next line is not with '++ SHA HASH ++' + if "++ SHA HASH ++" not in line and write_on_yaml: yml_f_ob.write(last_line) last_line = line elif "++ SHA HASH ++" in line: write_on_yaml = False last_line = "" elif not write_on_yaml and not last_line: - # The first line of xml file has been found. Onward write lines directly + # The first line of xml file has been found so in future write lines directly # into xml file. if not sha_hash: sha_hash = line.split("# ", 1)[-1].strip() @@ -228,3 +292,24 @@ def separate_hash_yaml_and_nxdl(yaml_file, sep_yaml, sep_xml): yml_f_ob.write(last_line) return sha_hash + + +def is_dom_comment(text): + """Analyze a comment, whether it is a dom comment or not. + + Return true if dom comment. + """ + + # some signature keywords to distingush dom comments from other comments. + signature_keyword_list = [ + "NeXus", + "GNU Lesser General Public", + "Free Software Foundation", + "Copyright (C)", + "WITHOUT ANY WARRANTY", + ] + for keyword in signature_keyword_list: + if keyword not in text: + return False + + return True diff --git a/dev_tools/tests/test_nyaml2nxdl.py b/dev_tools/tests/test_nyaml2nxdl.py index 792d8d4626..1a5350db4a 100755 --- a/dev_tools/tests/test_nyaml2nxdl.py +++ b/dev_tools/tests/test_nyaml2nxdl.py @@ -1,23 +1,21 @@ import os +from pathlib import Path from click.testing import CliRunner from ..nyaml2nxdl import nyaml2nxdl as conv from ..utils.nxdl_utils import find_definition_file -# import subprocess - def test_conversion(): root = find_definition_file("NXentry") - # subprocess.run(["python3","-m","dev_tools.nyaml2nxdl.nyaml2nxdl","--input-file",root]) result = CliRunner().invoke(conv.launch_tool, ["--input-file", root]) assert result.exit_code == 0 - yaml = root[:-9] + "_parsed.yaml" - # subprocess.run(["python3","-m","dev_tools.nyaml2nxdl.nyaml2nxdl","--input-file",yaml]) + # Replace suffixes + yaml = root.parent / Path(root.with_suffix("").stem + "_parsed.yaml") result = CliRunner().invoke(conv.launch_tool, ["--input-file", yaml]) assert result.exit_code == 0 - new_root = yaml[:-4] + "nxdl.xml" + new_root = yaml.with_suffix(".nxdl.xml") with open(root, encoding="utf-8", mode="r") as tmp_f: root_content = tmp_f.readlines() with open(new_root, encoding="utf-8", mode="r") as tmp_f: diff --git a/dev_tools/utils/nxdl_utils.py b/dev_tools/utils/nxdl_utils.py index efba439bec..5c6d3db458 100644 --- a/dev_tools/utils/nxdl_utils.py +++ b/dev_tools/utils/nxdl_utils.py @@ -4,26 +4,48 @@ import os import textwrap -import xml.etree.ElementTree as ET from functools import lru_cache from glob import glob +from pathlib import Path +import lxml.etree as ET +from lxml.etree import ParseError as xmlER -class NxdlAttributeError(Exception): - """An exception for throwing an error when an Nxdl attribute is not found.""" +from ..nyaml2nxdl.nyaml2nxdl_helper import remove_namespace_from_tag + + +class NxdlAttributeNotFoundError(Exception): + """An exception to throw when an Nxdl attribute is not found.""" + + +def get_nexus_definitions_path(): + """Check NEXUS_DEF_PATH variable. + If it is empty, this function is filling it""" + try: # either given by sys env + return os.environ["NEXUS_DEF_PATH"] + except KeyError: # or it should be available locally under the dir 'definitions' + local_dir = Path(__file__).resolve().parent + for _ in range(2): + local_dir = local_dir.parent + return local_dir + + +nexus_def_path = get_nexus_definitions_path() def get_app_defs_names(): """Returns all the AppDef names without their extension: .nxdl.xml""" - app_def_path_glob = ( - f"{get_nexus_definitions_path()}{os.sep}applications{os.sep}*.nxdl*" - ) - contrib_def_path_glob = ( - f"{get_nexus_definitions_path()}{os.sep}" - f"contributed_definitions{os.sep}*.nxdl*" - ) - files = sorted(glob(app_def_path_glob)) + sorted(glob(contrib_def_path_glob)) - return [os.path.basename(file).split(".")[0] for file in files] + ["NXroot"] + app_def_path_glob = nexus_def_path / "applications" / "*.nxdl*" + + contrib_def_path_glob = Path(nexus_def_path) / "contributed_definitions" / "*.nxdl*" + + files = sorted(glob(app_def_path_glob)) + for nexus_file in sorted(contrib_def_path_glob): + root = get_xml_root(nexus_file) + if root.attrib["category"] == "application": + files.append(nexus_file) + + return [Path(file).stem for file in files] + ["NXroot"] @lru_cache(maxsize=None) @@ -33,16 +55,6 @@ def get_xml_root(file_path): return ET.parse(file_path).getroot() -def get_nexus_definitions_path(): - """Check NEXUS_DEF_PATH variable. - If it is empty, this function is filling it""" - try: # either given by sys env - return os.environ["NEXUS_DEF_PATH"] - except KeyError: # or it should be available locally under the dir 'definitions' - local_dir = os.path.abspath(os.path.dirname(__file__)) - return os.path.join(local_dir, f"..{os.sep}..") - - def get_hdf_root(hdf_node): """Get the root HDF5 node""" node = hdf_node @@ -67,43 +79,34 @@ def get_hdf_parent(hdf_info): def get_parent_path(hdf_name): """Get parent path""" - return "/".join(hdf_name.split("/")[:-1]) + return hdf_name.rsplit("/", 1)[0] def get_hdf_info_parent(hdf_info): """Get the hdf_info for the parent of an hdf_node in an hdf_info""" if "hdf_path" not in hdf_info: return {"hdf_node": hdf_info["hdf_node"].parent} - node = ( - get_hdf_root(hdf_info["hdf_node"]) - if "hdf_root" not in hdf_info - else hdf_info["hdf_root"] - ) - for child_name in hdf_info["hdf_path"].split("/")[1:-1]: - node = node[child_name] + node = get_hdf_parent(hdf_info) return {"hdf_node": node, "hdf_path": get_parent_path(hdf_info["hdf_path"])} def get_nx_class(nxdl_elem): """Get the nexus class for a NXDL node""" - if "category" in nxdl_elem.attrib.keys(): - return None - try: - return nxdl_elem.attrib["type"] - except KeyError: - return "NX_CHAR" + if "category" in nxdl_elem.attrib: + return "" + return nxdl_elem.attrib.get("type", "NX_CHAR") def get_nx_namefit(hdf_name, name, name_any=False): """Checks if an HDF5 node name corresponds to a child of the NXDL element - uppercase letters in front can be replaced by arbitraty name, but + uppercase letters in front can be replaced by arbitrary name, but uppercase to lowercase match is preferred, so such match is counted as a measure of the fit""" if name == hdf_name: return len(name) * 2 # count leading capitals counting = 0 - while counting < len(name) and name[counting].upper() == name[counting]: + while counting < len(name) and name[counting].isupper(): counting += 1 if ( name_any @@ -127,63 +130,56 @@ def get_nx_classes(): """Read base classes from the NeXus definition folder. Check each file in base_classes, applications, contributed_definitions. If its category attribute is 'base', then it is added to the list.""" - base_classes = sorted( - glob(os.path.join(get_nexus_definitions_path(), "base_classes", "*.nxdl.xml")) - ) - applications = sorted( - glob(os.path.join(get_nexus_definitions_path(), "applications", "*.nxdl.xml")) - ) + nexus_definition_path = nexus_def_path + base_classes = sorted(nexus_definition_path.glob("base_classes/*.nxdl.xml")) + applications = sorted(nexus_definition_path.glob("applications/*.nxdl.xml")) contributed = sorted( - glob( - os.path.join( - get_nexus_definitions_path(), "contributed_definitions", "*.nxdl.xml" - ) - ) + nexus_definition_path.glob("contributed_definitions/*.nxdl.xml") ) - nx_clss = [] + nx_class = [] for nexus_file in base_classes + applications + contributed: - root = get_xml_root(nexus_file) + try: + root = get_xml_root(nexus_file) + except xmlER as e: + raise ValueError(f"Getting an issue while parsing file {nexus_file}") from e if root.attrib["category"] == "base": - nx_clss.append(str(nexus_file[nexus_file.rindex(os.sep) + 1 :])[:-9]) - nx_clss = sorted(nx_clss) - return nx_clss + nx_class.append(nexus_file.stem) + return sorted(nx_class) def get_nx_units(): """Read unit kinds from the NeXus definition/nxdlTypes.xsd file""" - filepath = f"{get_nexus_definitions_path()}{os.sep}nxdlTypes.xsd" + filepath = nexus_def_path / "nxdlTypes.xsd" root = get_xml_root(filepath) units_and_type_list = [] for child in root: - for i in child.attrib.values(): - units_and_type_list.append(i) + units_and_type_list.extend(child.attrib.values()) flag = False + nx_units = [] for line in units_and_type_list: if line == "anyUnitsAttr": flag = True - nx_units = [] - elif "NX" in line and flag is True: + elif "NX" in line and flag: nx_units.append(line) elif line == "primitiveType": flag = False - else: - pass + return nx_units def get_nx_attribute_type(): """Read attribute types from the NeXus definition/nxdlTypes.xsd file""" - filepath = get_nexus_definitions_path() + "/nxdlTypes.xsd" + filepath = nexus_def_path / "nxdlTypes.xsd" + root = get_xml_root(filepath) units_and_type_list = [] for child in root: - for i in child.attrib.values(): - units_and_type_list.append(i) + units_and_type_list.extend(child.attrib.values()) flag = False + nx_types = [] for line in units_and_type_list: if line == "primitiveType": flag = True - nx_types = [] elif "NX" in line and flag is True: nx_types.append(line) elif line == "anyUnitsAttr": @@ -198,7 +194,7 @@ def get_node_name(node): Either as specified by the 'name' or taken from the type (nx_class). Note that if only class name is available, the NX prefix is removed and the string is converted to UPPER case.""" - if "name" in node.attrib.keys(): + if "name" in node.attrib: name = node.attrib["name"] else: name = node.attrib["type"] @@ -232,7 +228,7 @@ def belongs_to_capital(params): (act_htmlname, chk_name, name_any, nxdl_elem, child, name) = params # or starts with capital and no reserved words used if ( - (name_any or "A" <= act_htmlname[0] <= "Z") + (act_htmlname[0].isalpha() and act_htmlname[0].isupper()) and name != "doc" and name != "enumeration" ): @@ -246,10 +242,7 @@ def belongs_to_capital(params): ): continue # check if the name of another sibling fits better - name_any2 = ( - "nameType" in child2.attrib.keys() - and child2.attrib["nameType"] == "any" - ) + name_any2 = child2.attrib.get("nameType") == "any" fit2 = get_nx_namefit(chk_name, get_node_name(child2), name_any2) if fit2 > fit: return False @@ -260,59 +253,35 @@ def belongs_to_capital(params): def get_local_name_from_xml(element): """Helper function to extract the element tag without the namespace.""" - return element.tag[element.tag.rindex("}") + 1 :] + return remove_namespace_from_tag(element.tag) def get_own_nxdl_child_reserved_elements(child, name, nxdl_elem): """checking reserved elements, like doc, enumeration""" - if get_local_name_from_xml(child) == "doc" and name == "doc": - if nxdl_elem.get("nxdlbase"): - child.set("nxdlbase", nxdl_elem.get("nxdlbase")) - child.set("nxdlbase_class", nxdl_elem.get("nxdlbase_class")) - child.set("nxdlpath", nxdl_elem.get("nxdlpath") + "/doc") - return child - if get_local_name_from_xml(child) == "enumeration" and name == "enumeration": - if nxdl_elem.get("nxdlbase"): - child.set("nxdlbase", nxdl_elem.get("nxdlbase")) - child.set("nxdlbase_class", nxdl_elem.get("nxdlbase_class")) - child.set("nxdlpath", nxdl_elem.get("nxdlpath") + "/enumeration") - return child + local_name = get_local_name_from_xml(child) + if local_name == "doc" and name == "doc": + return set_nxdlpath(child, nxdl_elem, tag_name=name) + + if local_name == "enumeration" and name == "enumeration": + return set_nxdlpath(child, nxdl_elem, tag_name=name) return False def get_own_nxdl_child_base_types(child, class_type, nxdl_elem, name, hdf_name): - """checking base types of group, field,m attribute""" + """checking base types of group, field, attribute""" if get_local_name_from_xml(child) == "group": if ( class_type is None or (class_type and get_nx_class(child) == class_type) ) and belongs_to(nxdl_elem, child, name, class_type, hdf_name): - if nxdl_elem.get("nxdlbase"): - child.set("nxdlbase", nxdl_elem.get("nxdlbase")) - child.set("nxdlbase_class", nxdl_elem.get("nxdlbase_class")) - child.set( - "nxdlpath", nxdl_elem.get("nxdlpath") + "/" + get_node_name(child) - ) - return child + return set_nxdlpath(child, nxdl_elem) if get_local_name_from_xml(child) == "field" and belongs_to( nxdl_elem, child, name, None, hdf_name ): - if nxdl_elem.get("nxdlbase"): - child.set("nxdlbase", nxdl_elem.get("nxdlbase")) - child.set("nxdlbase_class", nxdl_elem.get("nxdlbase_class")) - child.set( - "nxdlpath", nxdl_elem.get("nxdlpath") + "/" + get_node_name(child) - ) - return child + return set_nxdlpath(child, nxdl_elem) if get_local_name_from_xml(child) == "attribute" and belongs_to( nxdl_elem, child, name, None, hdf_name ): - if nxdl_elem.get("nxdlbase"): - child.set("nxdlbase", nxdl_elem.get("nxdlbase")) - child.set("nxdlbase_class", nxdl_elem.get("nxdlbase_class")) - child.set( - "nxdlpath", nxdl_elem.get("nxdlpath") + "/" + get_node_name(child) - ) - return child + return set_nxdlpath(child, nxdl_elem) return False @@ -324,16 +293,10 @@ def get_own_nxdl_child( class_type - nxdl type or hdf classname (for groups, it is obligatory) hdf_name - hdf name""" for child in nxdl_elem: - if "name" in child.attrib and child.attrib["name"] == name: - if nxdl_elem.get("nxdlbase"): - child.set("nxdlbase", nxdl_elem.get("nxdlbase")) - child.set("nxdlbase_class", nxdl_elem.get("nxdlbase_class")) - child.set( - "nxdlpath", nxdl_elem.get("nxdlpath") + "/" + get_node_name(child) - ) - return child + if child.attrib.get("name") == name: + return set_nxdlpath(child, nxdl_elem) for child in nxdl_elem: - if "name" in child.attrib and child.attrib["name"] == name: + if child.attrib.get("name") == name: child.set("nxdlbase", nxdl_elem.get("nxdlbase")) return child @@ -357,14 +320,9 @@ def find_definition_file(bc_name): """ bc_filename = None for nxdl_folder in ["contributed_definitions", "base_classes", "applications"]: - if os.path.exists( - f"{get_nexus_definitions_path()}{os.sep}" - f"{nxdl_folder}{os.sep}{bc_name}.nxdl.xml" - ): - bc_filename = ( - f"{get_nexus_definitions_path()}{os.sep}" - f"{nxdl_folder}{os.sep}{bc_name}.nxdl.xml" - ) + nxdl_file = nexus_def_path / nxdl_folder / f"{bc_name}.nxdl.xml" + if nxdl_file.exists(): + bc_filename = nexus_def_path / nxdl_folder / f"{bc_name}.nxdl.xml" break return bc_filename @@ -420,11 +378,8 @@ def get_required_string(nxdl_elem): if is_optional or is_minoccurs: return "<>" # default optionality: in BASE CLASSES is true; in APPLICATIONS is false - try: - if nxdl_elem.get("nxdlbase_class") == "base": - return "<>" - except TypeError: - return "<>" + if nxdl_elem.get("nxdlbase_class") == "base": + return "<>" return "<>" @@ -432,7 +387,7 @@ def get_required_string(nxdl_elem): def write_doc_string(logger, doc, attr): """Simple function that prints a line in the logger if doc exists""" if doc: - logger.debug("@" + attr + " [NX_CHAR]") + logger.debug("@%s [NX_CHAR]", attr) return logger, doc, attr @@ -565,7 +520,7 @@ def other_attrs( def get_node_concept_path(elem): """get the short version of nxdlbase:nxdlpath""" - return str(elem.get("nxdlbase").split("/")[-1] + ":" + elem.get("nxdlpath")) + return f'{elem.get("nxdlbase").split("/")[-1]}:{elem.get("nxdlpath")}' def get_doc(node, ntype, nxhtml, nxpath): @@ -588,7 +543,7 @@ def get_doc(node, ntype, nxhtml, nxpath): if index: enum_str = ( "\n " - + ("Possible values:" if len(enums.split(",")) > 1 else "Obligatory value:") + + ("Possible values:" if enums.count(",") else "Obligatory value:") + "\n " + enums + "\n" @@ -637,8 +592,9 @@ def get_enums(node): def add_base_classes(elist, nx_name=None, elem: ET.Element = None): - """Add the base classes corresponding to the last eleme in elist to the list. Note that if - elist is empty, a nxdl file with the name of nx_name or a rather room elem is used if provided + """ + Add the base classes corresponding to the last element in elist to the list. Note that if + elist is empty, a nxdl file with the name of nx_name or a placeholder elem is used if provided """ if elist and nx_name is None: nx_name = get_nx_class(elist[-1]) @@ -651,7 +607,16 @@ def add_base_classes(elist, nx_name=None, elem: ET.Element = None): nxdl_file_path = find_definition_file(nx_name) if nxdl_file_path is None: nxdl_file_path = f"{nx_name}.nxdl.xml" - elem = ET.parse(nxdl_file_path).getroot() + + try: + elem = ET.parse(os.path.abspath(nxdl_file_path)).getroot() + # elem = ET.parse(nxdl_file_path).getroot() + except OSError: + with open(nxdl_file_path, "r") as f: + elem = ET.parse(f).getroot() + + if not isinstance(nxdl_file_path, str): + nxdl_file_path = str(nxdl_file_path) elem.set("nxdlbase", nxdl_file_path) else: elem.set("nxdlbase", "") @@ -666,20 +631,25 @@ def add_base_classes(elist, nx_name=None, elem: ET.Element = None): add_base_classes(elist) -def set_nxdlpath(child, nxdl_elem): - """ - Setting up child nxdlbase, nxdlpath and nxdlbase_class from nxdl_element. - """ +def set_nxdlpath(child, nxdl_elem, tag_name=None): + """Setting up child nxdlbase, nxdlpath and nxdlbase_class from nxdl_element.""" if nxdl_elem.get("nxdlbase"): child.set("nxdlbase", nxdl_elem.get("nxdlbase")) child.set("nxdlbase_class", nxdl_elem.get("nxdlbase_class")) - child.set("nxdlpath", nxdl_elem.get("nxdlpath") + "/" + get_node_name(child)) + # Handle element that does not has 'name' attr e.g. doc, enumeration + if tag_name: + child.set("nxdlpath", nxdl_elem.get("nxdlpath") + "/" + tag_name) + else: + child.set( + "nxdlpath", nxdl_elem.get("nxdlpath") + "/" + get_node_name(child) + ) + return child def get_direct_child(nxdl_elem, html_name): """returns the child of nxdl_elem which has a name - corresponding to the the html documentation name html_name""" + corresponding to the html documentation name html_name""" for child in nxdl_elem: if get_local_name_from_xml(child) in ( "group", @@ -734,7 +704,7 @@ def get_best_nxdata_child(nxdl_elem, hdf_node, hdf_name): def get_best_child(nxdl_elem, hdf_node, hdf_name, hdf_class_name, nexus_type): """returns the child of nxdl_elem which has a name - corresponding to the the html documentation name html_name""" + corresponding to the html documentation name html_name""" bestfit = -1 bestchild = None if ( @@ -783,9 +753,7 @@ def walk_elist(elist, html_name): if fitting_child is not None: child = fitting_child break - elist[ind] = child - if elist[ind] is None: - del elist[ind] + if child is None: continue # override: remove low priority inheritance classes if class_type is overriden if len(elist) > ind + 1 and get_nx_class(elist[ind]) != get_nx_class( @@ -793,7 +761,7 @@ def walk_elist(elist, html_name): ): del elist[ind + 1 :] # add new base class(es) if new element brings such (and not a primitive type) - if len(elist) == ind + 1 and get_nx_class(elist[ind])[0:3] != "NX_": + if len(elist) == ind + 1 and get_nx_class(elist[ind]).startswith("NX_"): add_base_classes(elist) return elist, html_name @@ -803,7 +771,6 @@ def get_inherited_nodes( nxdl_path: str = None, # pylint: disable=too-many-arguments,too-many-locals nx_name: str = None, elem: ET.Element = None, - attr=False, ): """Returns a list of ET.Element for the given path.""" # let us start with the given definition file @@ -812,11 +779,9 @@ def get_inherited_nodes( nxdl_elem_path = [elist[0]] class_path = [] # type: ignore[var-annotated] - html_path = nxdl_path.split("/")[1:] - path = html_path - for pind in range(len(path)): - html_name = html_path[pind] - elist, html_name = walk_elist(elist, html_name) + html_paths = nxdl_path.split("/")[1:] + for html_name in html_paths: + elist, _ = walk_elist(elist, html_name) if elist: class_path.append(get_nx_class(elist[0])) nxdl_elem_path.append(elist[0]) @@ -837,7 +802,7 @@ def get_node_at_nxdl_path( (class_path, nxdlpath, elist) = get_inherited_nodes(nxdl_path, nx_name, elem) except ValueError as value_error: if exc: - raise NxdlAttributeError( + raise NxdlAttributeNotFoundError( f"Attributes were not found for {nxdl_path}. " "Please check this entry in the template dictionary." ) from value_error @@ -847,7 +812,7 @@ def get_node_at_nxdl_path( else: elem = None if exc: - raise NxdlAttributeError( + raise NxdlAttributeNotFoundError( f"Attributes were not found for {nxdl_path}. " "Please check this entry in the template dictionary." ) diff --git a/pyproject.toml b/pyproject.toml deleted file mode 100644 index 70bad9e3a1..0000000000 --- a/pyproject.toml +++ /dev/null @@ -1,43 +0,0 @@ -[build-system] -requires = ["setuptools>=64.0.1", "setuptools-scm[toml]>=6.2"] -build-backend = "setuptools.build_meta" - -[project] -name = "nexusdefinitions" -dynamic = ["version"] -authors = [ - { name = "NIAC" } -] -description = "Nexus definitions" -readme = "README.md" -license = { file = "LGPL.txt" } -requires-python = "" -classifiers = [ - "Operating System :: OS Independent" -] -dependencies = [ - "lxml", - "pyyaml", - "click>=7.1.2", - "sphinx>=5", - "sphinx-tabs", - "sphinx-toolbox", - "sphinx_comments", - "pytest", - "black>=22.3", - "flake8>=4", - "isort>=5.10", -] - -[project.urls] -"Homepage" = "https://nexusformat.org" - -[project.scripts] -nyaml2nxdl = "dev_tools.nyaml2nxdl.nyaml2nxdl:launch_tool" - -[tools.setuptools_scm] -version_scheme = "guess-next-dev" -local_scheme = "node-and-date" - -[tool.setuptools] -packages = ["dev_tools"] From 08020ac543c77e117c4c142dec6f40dd9bde9ff3 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 3 Nov 2023 14:16:02 +0100 Subject: [PATCH 0342/1012] Rename raw axis name in NXdetector/NXdata, split polarization --- contributed_definitions/NXmpes.nxdl.xml | 143 ++++++------ contributed_definitions/nyaml/NXmpes.yaml | 263 +++++++++++++--------- 2 files changed, 234 insertions(+), 172 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 0f68df10d7..37ee8863e2 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -354,79 +354,88 @@ Optional constant settings (like lens focusing parameters on the sample: positio Raw data before calibration. - + + - Raw, uncalibrated energy axis. Can be any of detector_pixel (arb. units), - TOF_ADC (arb. units), voltage (V), TOF (ns). + Detector pixel in x direction. - - - - - - - - - + - Raw, uncalibrated x axis in k-space. Can be any of detector_pixel (arb. units), - manipulator_angle (degrees) + Detector pixel in y direction. - - - - - - - + + - Raw, uncalibrated y axis in k-space. Can be any of detector_pixel (arb. units), - manipulator_angle (degrees) + In DAQ clock pulses - - - - - - - + + - Raw, uncalibrated z axis in k-space. Can be any of photon energy (eV), - monochromator_step (arb. units) + Total time of flight - - - - - - - + - Raw, uncalibrated z axis in k-space. Can be any of delay_ADC (arb. units), - delay_position (mm) + Time-of-flight values, analog-to-digital converted. - - - - - - - + - Raw, uncalibrated spin axes. Can be any of magnetization (NX_CHAR), - scattering_direction (NX_CHAR) + Polar rotation angle of the manipulator. + + + + + Azimuthal rotation angle of the manipulator. + + + + + Delay position of delay line detector. + + + + + Delay position of delay line detector, analog-to-digital converted. + + + + + Time delay of delay line detector. + + + + + Time delay of delay line detector. + + + + + Measured detector voltage + + + + + Describes an axis which is coming from outside the detectors scope. + + Think of a detector just being triggered for readout by the rest of the experimental setup - + it would just know that it collected N images, which would flatten the external parameters to one axis, too. + This can then be linked, e.g. with NXcalibration, to the appropriate fields in the instrument and write it to the + top-level NXdata. + + + + + missing + + + + + missing - - - - - - @@ -754,20 +763,22 @@ Optional constant settings (like lens focusing parameters on the sample: positio Calibrated delay time. - + + + Linear polarization angle of the incoming or outgoing beam. + + Could be a link to /entry/instrument/beam/incident_polarization_angle or + /entry/instrument/beam/final_polarization_angle if they exist. + + + - Polarization of the incoming beam. + Ellipticity of the incoming or outgoing beam. Can be any of linear polarization angle (degrees), ellipticity (arb. units). - Could be a link to /entry/instrument/beam/incident_polarization or - /entry/instrument/beam/final_polarization if they exist. + Could be a link to /entry/instrument/beam/incident_ellipticity or + /entry/instrument/beam/final_ellipticity if they exist. - - - - - - diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 22d1afc364..9e77e7a477 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -275,54 +275,88 @@ NXmpes(NXobject): raw(NX_NUMBER): doc: | Raw data before calibration. - energy_raw(NX_NUMBER): - exists: recommended + pixel_x(NX_FLOAT): + exists: optional unit: NX_ANY + + # there is also x_pixel_offset in NXdetector base class doc: | - Raw, uncalibrated energy axis. Can be any of detector_pixel (arb. units), - TOF_ADC (arb. units), voltage (V), TOF (ns). - \@type: - enumeration: [detector_pixel, TOF_ADC, voltage, TOF] - kx_raw(NX_NUMBER): + Detector pixel in x direction. + pixel_y(NX_FLOAT): exists: optional unit: NX_ANY doc: | - Raw, uncalibrated x axis in k-space. Can be any of detector_pixel (arb. units), - manipulator_angle (degrees) - \@type: - enumeration: [detector_pixel, manipulator_angle] - ky_raw(NX_NUMBER): + Detector pixel in y direction. + + # exists in NXdetector base class + raw_time_of_flight(NX_INT): + exists: optional + unit: NX_PULSES + doc: | + In DAQ clock pulses + + # exists in NXdetector base class + time_of_flight(NX_FLOAT): exists: optional - unit: NX_ANY + unit: NX_TIME_OF_FLIGHT doc: | - Raw, uncalibrated y axis in k-space. Can be any of detector_pixel (arb. units), - manipulator_angle (degrees) - \@type: - enumeration: [detector_pixel, manipulator_angle] - kz_raw(NX_NUMBER): + Total time of flight + time_of_flight_adc(NX_FLOAT): exists: optional unit: NX_ANY doc: | - Raw, uncalibrated z axis in k-space. Can be any of photon energy (eV), - monochromator_step (arb. units) - \@type: - enumeration: [detector_pixel, manipulator_angle] - delay_raw(NX_NUMBER): + Time-of-flight values, analog-to-digital converted. + polar_angle_manipulator(NX_FLOAT): + exists: optional + unit: NX_ANGLE + doc: | + Polar rotation angle of the manipulator. + azimuthal_angle_manipulator(NX_FLOAT): + exists: optional + unit: NX_ANGLE + doc: | + Azimuthal rotation angle of the manipulator. + delay_position(NX_FLOAT): + exists: optional + unit: NX_LENGTH + doc: | + Delay position of delay line detector. + delay_position_ADC(NX_FLOAT): exists: optional unit: NX_ANY doc: | - Raw, uncalibrated z axis in k-space. Can be any of delay_ADC (arb. units), - delay_position (mm) - \@type: - enumeration: [delay_ADC, delay_position] - spin_raw(NX_NUMBER): + Delay position of delay line detector, analog-to-digital converted. + time_delay_x(NX_FLOAT): + exists: optional + unit: NX_TIME + doc: | + Time delay of delay line detector. + time_delay_y(NX_FLOAT): + exists: optional + unit: NX_TIME + doc: | + Time delay of delay line detector. + voltage(NX_FLOAT): + exists: optional + unit: NX_VOLTAGE + doc: | + Measured detector voltage + external_AXIS(NX_NUMBER): exists: optional unit: NX_ANY doc: | - Raw, uncalibrated spin axes. Can be any of magnetization (NX_CHAR), - scattering_direction (NX_CHAR) - \@type: - enumeration: [magnetization, scattering_direction] + Describes an axis which is coming from outside the detectors scope. + + Think of a detector just being triggered for readout by the rest of the experimental setup - + it would just know that it collected N images, which would flatten the external parameters to one axis, too. + This can then be linked, e.g. with NXcalibration, to the appropriate fields in the instrument and write it to the + top-level NXdata. + magnetization(NX_CHAR): + doc: | + missing + scattering_direction(NX_CHAR): + doc: | + missing (NXmanipulator): exists: optional doc: | @@ -598,20 +632,26 @@ NXmpes(NXobject): unit: NX_TIME doc: | Calibrated delay time. - polarization: + polarization_angle(NX_FLOAT): exists: optional - unit: NX_ANY + unit: NX_ANGLE doc: | - Polarization of the incoming beam. + Linear polarization angle of the incoming or outgoing beam. + + Could be a link to /entry/instrument/beam/incident_polarization_angle or + /entry/instrument/beam/final_polarization_angle if they exist. + ellipticity(NX_FLOAT): + exists: optional + unit: NX_ANGLE + doc: | + Ellipticity of the incoming or outgoing beam. Can be any of linear polarization angle (degrees), ellipticity (arb. units). - Could be a link to /entry/instrument/beam/incident_polarization or - /entry/instrument/beam/final_polarization if they exist. - \@type: - enumeration: [linear polarization angle, ellipticity] + Could be a link to /entry/instrument/beam/incident_ellipticity or + /entry/instrument/beam/final_ellipticity if they exist. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 25d4207cd8d9745330b291d20386f0673c192ecb54fe4bc68e60117ece1b06ba +# 576bc8ae6b6e2395aca8c6297bf482fc68d82068637a9f9c895567547d4794f7 # # # # -# Raw, uncalibrated energy axis. Can be any of detector_pixel (arb. units), -# TOF_ADC (arb. units), voltage (V), TOF (ns). +# Detector pixel in x direction. # -# -# -# -# -# -# -# -# # -# +# # -# Raw, uncalibrated x axis in k-space. Can be any of detector_pixel (arb. units), -# manipulator_angle (degrees) +# Detector pixel in y direction. # -# -# -# -# -# -# # -# +# +# # -# Raw, uncalibrated y axis in k-space. Can be any of detector_pixel (arb. units), -# manipulator_angle (degrees) +# In DAQ clock pulses # -# -# -# -# -# -# # -# +# +# # -# Raw, uncalibrated z axis in k-space. Can be any of photon energy (eV), -# monochromator_step (arb. units) +# Total time of flight # -# -# -# -# -# -# # -# +# # -# Raw, uncalibrated z axis in k-space. Can be any of delay_ADC (arb. units), -# delay_position (mm) +# Time-of-flight values, analog-to-digital converted. # -# -# -# -# -# -# # -# +# # -# Raw, uncalibrated spin axes. Can be any of magnetization (NX_CHAR), -# scattering_direction (NX_CHAR) +# Polar rotation angle of the manipulator. +# +# +# +# +# Azimuthal rotation angle of the manipulator. +# +# +# +# +# Delay position of delay line detector. +# +# +# +# +# Delay position of delay line detector, analog-to-digital converted. +# +# +# +# +# Time delay of delay line detector. +# +# +# +# +# Time delay of delay line detector. +# +# +# +# +# Measured detector voltage +# +# +# +# +# Describes an axis which is coming from outside the detectors scope. +# +# Think of a detector just being triggered for readout by the rest of the experimental setup - +# it would just know that it collected N images, which would flatten the external parameters to one axis, too. +# This can then be linked, e.g. with NXcalibration, to the appropriate fields in the instrument and write it to the +# top-level NXdata. +# +# +# +# +# missing +# +# +# +# +# missing # -# -# -# -# -# -# # # # @@ -1368,20 +1417,22 @@ NXmpes(NXobject): # Calibrated delay time. # # -# +# # -# Polarization of the incoming beam. +# Linear polarization angle of the incoming or outgoing beam. +# +# Could be a link to /entry/instrument/beam/incident_polarization_angle or +# /entry/instrument/beam/final_polarization_angle if they exist. +# +# +# +# +# Ellipticity of the incoming or outgoing beam. # # Can be any of linear polarization angle (degrees), ellipticity (arb. units). -# Could be a link to /entry/instrument/beam/incident_polarization or -# /entry/instrument/beam/final_polarization if they exist. +# Could be a link to /entry/instrument/beam/incident_ellipticity or +# /entry/instrument/beam/final_ellipticity if they exist. # -# -# -# -# -# -# # # # From be9a9d930001050490c36271a45d5011161be551 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 3 Nov 2023 14:33:26 +0100 Subject: [PATCH 0343/1012] split NXphotoemission and NXmpes --- base_classes/NXroot.nxdl.xml | 123 +-- base_classes/NXsource.nxdl.xml | 5 +- base_classes/nyaml/NXroot.yaml | 131 ++-- base_classes/nyaml/NXsource.yaml | 13 +- .../NXcalibration.nxdl.xml | 120 ++- .../NXenergydispersion.nxdl.xml | 12 + contributed_definitions/NXidentifier.nxdl.xml | 59 ++ contributed_definitions/NXlink.nxdl.xml | 39 - contributed_definitions/NXmpes.nxdl.xml | 620 +++++++++++++++ contributed_definitions/NXresolution.nxdl.xml | 15 +- contributed_definitions/NXserialized.nxdl.xml | 76 ++ .../nyaml/NXcalibration.yaml | 105 ++- .../nyaml/NXenergydispersion.yaml | 24 +- .../nyaml/NXidentifier.yaml | 21 + contributed_definitions/nyaml/NXlink.yaml | 54 -- contributed_definitions/nyaml/NXmpes.yaml | 48 +- .../nyaml/NXphotoemission.yaml | 706 +----------------- .../nyaml/NXresolution.yaml | 32 +- .../nyaml/NXserialized.yaml | 37 + 19 files changed, 1264 insertions(+), 976 deletions(-) create mode 100644 contributed_definitions/NXidentifier.nxdl.xml delete mode 100644 contributed_definitions/NXlink.nxdl.xml create mode 100644 contributed_definitions/NXserialized.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXidentifier.yaml delete mode 100644 contributed_definitions/nyaml/NXlink.yaml create mode 100644 contributed_definitions/nyaml/NXserialized.yaml diff --git a/base_classes/NXroot.nxdl.xml b/base_classes/NXroot.nxdl.xml index 54c432c794..75a3753796 100644 --- a/base_classes/NXroot.nxdl.xml +++ b/base_classes/NXroot.nxdl.xml @@ -1,10 +1,10 @@ - + - - Definition of the root NeXus group. + + + Definition of the root NeXus group. + - The root of any NeXus data file is an ``NXroot`` class - (no other choice is allowed for a valid NeXus data file). - This attribute cements that definition. + The root of any NeXus data file is an ``NXroot`` class + (no other choice is allowed for a valid NeXus data file). + This attribute cements that definition. - + - Date and time file was originally created + + Date and time file was originally created + - File name of original NeXus file + + File name of original NeXus file + - Date and time of last file change at close + + Date and time of last file change at close + - Version of NeXus API used in writing the file. - - Only used when the NAPI has written the file. - Note that this is different from the version of the - base class or application definition version number. + Version of NeXus API used in writing the file. + + Only used when the NAPI has written the file. + Note that this is different from the version of the + base class or application definition version number. + + + + + A list of concepts in an application definition this file describes. + This is for partially filling an application definition. + If this attribute is not present the application definition is assumed + to be valid, if not the specified concepts/paths are assumed to be valid. - Version of HDF (version 4) library used in writing the file + + Version of HDF (version 4) library used in writing the file + - Version of HDF5 library used in writing the file. - - Note this attribute is spelled with uppercase "V", - different than other version attributes. + Version of HDF5 library used in writing the file. + + Note this attribute is spelled with uppercase "V", + different than other version attributes. - Version of XML support library used in writing the XML file + + Version of XML support library used in writing the XML file + - Version of h5py Python package used in writing the file + + Version of h5py Python package used in writing the file + - facility or program where file originated + + facility or program where file originated + - Version of facility or program used in writing the file + + Version of facility or program used in writing the file + - - entries + + + entries + - .. index:: find the default plottable data - .. index:: plotting - .. index:: default attribute value - - Declares which :ref:`NXentry` group contains - the data to be shown by default. - It is used to resolve ambiguity when - more than one :ref:`NXentry` group exists. - The value :ref:`names <validItemName>` the default :ref:`NXentry` group. The - value must be the name of a child of the current group. The child must be a - NeXus group or a link to a NeXus group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: find the default plottable data + .. index:: plotting + .. index:: default attribute value + + Declares which :ref:`NXentry` group contains + the data to be shown by default. + It is used to resolve ambiguity when + more than one :ref:`NXentry` group exists. + The value :ref:`names <validItemName>` the default :ref:`NXentry` group. The + value must be the name of a child of the current group. The child must be a + NeXus group or a link to a NeXus group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. - diff --git a/base_classes/NXsource.nxdl.xml b/base_classes/NXsource.nxdl.xml index a291384d3f..dede03ed1d 100644 --- a/base_classes/NXsource.nxdl.xml +++ b/base_classes/NXsource.nxdl.xml @@ -23,7 +23,9 @@ --> - The neutron or x-ray storage ring/facility. + Radiation source emitting a beam. + + Examples include particle sources (electrons, neutrons, protons) or sources for electromagnetic radation (photons). @@ -68,6 +70,7 @@ + diff --git a/base_classes/nyaml/NXroot.yaml b/base_classes/nyaml/NXroot.yaml index bcecfaa0a8..efdb9971ff 100644 --- a/base_classes/nyaml/NXroot.yaml +++ b/base_classes/nyaml/NXroot.yaml @@ -27,6 +27,12 @@ NXroot(NXobject): Only used when the NAPI has written the file. Note that this is different from the version of the base class or application definition version number. + \@partial: + doc: | + A list of concepts in an application definition this file describes. + This is for partially filling an application definition. + If this attribute is not present the application definition is assumed + to be valid, if not the specified concepts/paths are assumed to be valid. \@HDF_version: doc: | Version of HDF (version 4) library used in writing the file @@ -72,14 +78,14 @@ NXroot(NXobject): for a summary of the discussion. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 00ad60c31b3087963764958288477d30afe61c6888f025264db3cfb53f1068c1 +# 076e6c02e65767061d84e6f18bdef2d2caaf1c555f8ce414fd5744e68cc3685c # -# +# # -# -# Definition of the root NeXus group. +# +# +# Definition of the root NeXus group. +# # # -# The root of any NeXus data file is an ``NXroot`` class -# (no other choice is allowed for a valid NeXus data file). -# This attribute cements that definition. +# The root of any NeXus data file is an ``NXroot`` class +# (no other choice is allowed for a valid NeXus data file). +# This attribute cements that definition. # # -# +# # # # -# Date and time file was originally created +# +# Date and time file was originally created +# # # -# File name of original NeXus file +# +# File name of original NeXus file +# # # -# Date and time of last file change at close +# +# Date and time of last file change at close +# # # # -# Version of NeXus API used in writing the file. -# -# Only used when the NAPI has written the file. -# Note that this is different from the version of the -# base class or application definition version number. +# Version of NeXus API used in writing the file. +# +# Only used when the NAPI has written the file. +# Note that this is different from the version of the +# base class or application definition version number. +# +# +# +# +# A list of concepts in an application definition this file describes. +# This is for partially filling an application definition. +# If this attribute is not present the application definition is assumed +# to be valid, if not the specified concepts/paths are assumed to be valid. # # # -# Version of HDF (version 4) library used in writing the file +# +# Version of HDF (version 4) library used in writing the file +# # # # -# Version of HDF5 library used in writing the file. -# -# Note this attribute is spelled with uppercase "V", -# different than other version attributes. +# Version of HDF5 library used in writing the file. +# +# Note this attribute is spelled with uppercase "V", +# different than other version attributes. # # # -# Version of XML support library used in writing the XML file +# +# Version of XML support library used in writing the XML file +# # # -# Version of h5py Python package used in writing the file +# +# Version of h5py Python package used in writing the file +# # # -# facility or program where file originated +# +# facility or program where file originated +# # # -# Version of facility or program used in writing the file +# +# Version of facility or program used in writing the file +# # -# -# entries +# +# +# entries +# # # # -# .. index:: find the default plottable data -# .. index:: plotting -# .. index:: default attribute value -# -# Declares which :ref:`NXentry` group contains -# the data to be shown by default. -# It is used to resolve ambiguity when -# more than one :ref:`NXentry` group exists. -# The value :ref:`names <validItemName>` the default :ref:`NXentry` group. The -# value must be the name of a child of the current group. The child must be a -# NeXus group or a link to a NeXus group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. +# .. index:: find the default plottable data +# .. index:: plotting +# .. index:: default attribute value +# +# Declares which :ref:`NXentry` group contains +# the data to be shown by default. +# It is used to resolve ambiguity when +# more than one :ref:`NXentry` group exists. +# The value :ref:`names <validItemName>` the default :ref:`NXentry` group. The +# value must be the name of a child of the current group. The child must be a +# NeXus group or a link to a NeXus group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. # # # -# diff --git a/base_classes/nyaml/NXsource.yaml b/base_classes/nyaml/NXsource.yaml index 6e275f7535..a9a6035c4c 100644 --- a/base_classes/nyaml/NXsource.yaml +++ b/base_classes/nyaml/NXsource.yaml @@ -1,6 +1,8 @@ category: base doc: | - The neutron or x-ray storage ring/facility. + Radiation source emitting a beam. + + Examples include particle sources (electrons, neutrons, protons) or sources for electromagnetic radation (photons). type: group NXsource(NXobject): distance(NX_FLOAT): @@ -22,7 +24,7 @@ NXsource(NXobject): probe: doc: | type of radiation probe (pick one from the enumerated list and spell exactly) - enumeration: [neutron, x-ray, muon, electron, ultraviolet, visible light, positron, proton] + enumeration: [neutron, photon, x-ray, muon, electron, ultraviolet, visible light, positron, proton] power(NX_FLOAT): unit: NX_POWER doc: | @@ -203,7 +205,7 @@ NXsource(NXobject): other component groups. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 248872a89ab8cb9c738d47d23b9cf7fa50bac04b2beb1428f677ec9ec23fc29b +# 81bbad2d2d7f3bbecb78610a117d3a40a45be96101c9d07cbb30d30d58eeaf45 # # # # # -# The neutron or x-ray storage ring/facility. +# Radiation source emitting a beam. +# +# Examples include particle sources (electrons, neutrons, protons) or sources for electromagnetic radation (photons). # # # @@ -274,6 +278,7 @@ NXsource(NXobject): # # # +# # # # diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml index 700506294d..ec4dc423ca 100644 --- a/contributed_definitions/NXcalibration.nxdl.xml +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -45,6 +45,36 @@ Subclass of NXprocess to describe post-processing calibrations. + + + A description of the procedures employed. + + + + + A digital persistent identifier (e.g., doi, ISO standard) referring to a detailed description of a + calibration method but no actual calibration data. + + + + + A digital persistent identifier (e.g., a doi) referring to a + publicly available calibration measurement used for this instrument + , e.g., a measurement of a known standard containing calibration information. + The axis values may be copied or linked in the appropriate NXcalibration fields for reference. + + + + + A file serialisation of a calibration which may not be publicly available (externally from the nexus file). + + This metadata can be a documentation of the source (file) or database (entry) from which pieces + of information have been extracted for consumption in e.g. a research data management system (RDMS). + It is also possible to include the actual file by using the `file` field. + + The axis values may be copied or linked in the appropriate NXcalibration fields for reference. + + Indicates the name of the last operation applied in the NXprocess sequence. @@ -55,6 +85,47 @@ Has the calibration been applied? + + + Vector containing the data coordinates in the original uncalibrated axis + + + + + + + The symbol of the axis to be used in the fit_function, e.g., `energy`, `E`. + This should comply to the following naming rules (similar to python's naming rules): + + * A variable name must start with a letter or the underscore character + * A variable name cannot start with a number + * A variable name can only contain alpha-numeric characters and underscores (A-z, 0-9, and _ ) + * Variable names are case-sensitive (age, Age and AGE are three different variables) + + + + + The path from which this data is derived, e.g., raw detector axis. + Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. + + + + + + Additional input axis to be used in the formula. + The part after `input_` is used as the symbol to be used in the `fit_function`, i.e., + if the field name is `input_my_field` you should refer to this axis by `my_field` in the `fit_function`. + + + + + + + The path from which this data is derived, e.g., raw detector axis. + Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. + + + For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit @@ -72,7 +143,13 @@ Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - Use x0, x1, ..., xn for the variables. + Use x0, x1, ..., xn for the nth position in the `original_axis` field. + If there is the symbol attribute specified for the `original_axis` this may be used instead of x. + If you want to use the whole axis use `x`. + Alternate axis can also be available as specified by the `input_SYMBOL` field. + The data should then be referred here by the `SYMBOL` name, e.g., for a field + name `input_my_field` it should be referred here by `my_field` or `my_field0` if + you want to read the zeroth element of the array. The formula should be numpy compliant. @@ -80,46 +157,35 @@ For linear calibration. Scaling parameter. + This is should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. For linear calibration. Offset parameter. + This is should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. - + - A vector representing the axis after calibration, matching the data length + Mapping data for calibration. + + This can be used to map data points from uncalibrated to calibrated values, + i.e., by multiplying each point in the input axis by the corresponding point in the mapping data. - - - - + - Vector containing the data coordinates in the original uncalibrated axis + A vector representing the axis after calibration, matching the data length + + + The path to which this data is written, e.g., the calibrated energy. + Should be a valid NeXus path name, e.g., /entry/data/energy. + + - - - A description of the procedures employed. - - - - - File containing the input data for calibration. - - - - - Mapping data for calibration. - - This can be used to map data points from uncalibrated - to calibrated values, e.g., by multiplying each point by the - corresponding point in the mapping data. - - diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml index ead97311db..2624251597 100644 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ b/contributed_definitions/NXenergydispersion.nxdl.xml @@ -97,4 +97,16 @@ + + + Collection of axis-based translations and rotations to describe the location and + geometry of the energy dispersive element as a component in the instrument. + Conventions from the NXtransformations base class are used. In principle, + the McStas coordinate system is used. The first transformation has to point + either to another component of the system or . (for pointing to the reference frame) + to relate it relative to the experimental setup. Typically, the components of a system + should all be related relative to each other and only one component should relate to + the reference coordinate system. + + diff --git a/contributed_definitions/NXidentifier.nxdl.xml b/contributed_definitions/NXidentifier.nxdl.xml new file mode 100644 index 0000000000..00c5eeafed --- /dev/null +++ b/contributed_definitions/NXidentifier.nxdl.xml @@ -0,0 +1,59 @@ + + + + + + An identifier for a (persistent) resource, e.g., a DOI or orcid. + + + + The service by which the resouce can be resolved. + If the service is not in the list a simple `url` may be used. + The `url` can either be a resolving service for the `identifier` + or a fully qualified identification in itself. + + + + + + + + + + + + + + The unique code, IRI or hash to resolve this reference. + Typically, this is stated by the service which is considered a complete + identifier, e.g., for a DOI it's something of the form `10.1107/S1600576714027575` + or `https://doi.org/10.1107/S1600576714027575`, which are both resolvable. + + + + + True if the identifier is persistent (i.e., unique and available indefinetely), + False otherwise. + + + diff --git a/contributed_definitions/NXlink.nxdl.xml b/contributed_definitions/NXlink.nxdl.xml deleted file mode 100644 index d9bf2f2149..0000000000 --- a/contributed_definitions/NXlink.nxdl.xml +++ /dev/null @@ -1,39 +0,0 @@ - - - - - - Describes a link - - - - The symbol by which to refer to this link, e.g., for formulas - - - - - A valid path inside an instance of an application definition, i.e., - of the form /entry/instrument/my_part/my_field - - - diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 6a4cedf1da..393bfc0f1b 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -32,4 +32,624 @@ .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 +<<<<<<< HEAD +======= + + + + + + + + + + + Datetime of the start of the measurement. + + + + + Datetime of the end of the measurement. + + + + + A name of the experimental method according to `Clause 11`_ of + the `ISO 18115-1:2023`_ specification. + + Examples include: + * X-ray photoelectron spectroscopy (XPS) + * angle-resolved X-ray photoelectron spectroscopy (ARXPS) + * ultraviolet photoelectron spectroscopy (UPS) + * angle-resolved photoelectron spectroscopy (ARPES) + * hard X-ray photoemission spectroscopy (HAXPES) + * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) + * photoelectron emission microscopy (PEEM) + * electron spectroscopy for chemical analysis (ESCA) + + .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 + + + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + + + MPES spectrometer + + Refers to Term `12.58`_ of the ISO 18115-1:2023 specification. + + .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 + + + + Overall energy resolution of the MPES instrument + + Refers to Terms `10.7`_ ff. and `10.24`_ of the ISO 18115-1:2023 specification. + + .. _10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 + .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 + + + + + + + + + + + + + + + + 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. + + + + + + + + + + + + + + + + + + + + Specification of type, may also go to name. + + + + + + Type of probe. In photoemission it's always photons, so the full NIAC list is + restricted. + + + + + + + + + + + + + + + + The beam emitted by this source. + Should be named with the same appendix, e.g., + for `source_probe` it should refer to `beam_probe`. + Refers to the same concept as /NXentry/NXinstrument/beam_TYPE + and may be linked. + + + + + + + + The beam emitted by this source. + Should be named with the same appendix, e.g., + for `source_probe` it should refer to `beam_probe`. + Refers to the same concept as /NXentry/NXinstrument/source_TYPE + and may be linked. + + + + + + + + + The source that emitted this beam. + Should be named with the same appendix, e.g., + for `beam_probe` it should refer to `source_probe`. + Refers to the same concept as /NXentry/NXinstrument/source_TYPE + and may be linked. + + + + + + + + + + + + + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. + + Refers to Term `10.24`_ of the ISO 18115-1:2023 specification. + + .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 + + + + + + + + + + Scheme of the electron collection column. + + + + + + + + + + + + + + + Labelling of the lens setting in use. + + + + + + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + Size, position and shape of the iris inserted in the column. + + The iris is an aperture in the lens with a variable diameter which can reduce the number of + electrons entering the analyzer. + + To add additional or other slits use the APERTURE group of NXcollectioncolumn. + + + + + + + + + + + + + + + + + + + + + + + + Size, position and shape of the entrance slit in dispersive analyzers. + + To add additional or other slits use the APERTURE group of NXenergydispersion. + + + + + Size, position and shape of the exit slit in dispersive analyzers. + + To add additional or other slits use the APERTURE group of NXenergydispersion. + + + + + + + + + + + + Type of electron amplifier in the first amplification step. + + + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + + + + + + + + + Raw data before calibration. + + + + + + + + Manipulator for positioning of the sample. + + + + + + Bias of the sample with respect to analyser ground. + + This field may also be found in NXsample if present. + + Refers to Term `8.41`_ of the ISO 18115-1:2023 specification. + + .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 + + + + + + + + + + + + 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 + + + + Calibration event on the energy axis. + + For XPS, the calibration should ideally be performed according to + `ISO 15472:2010`_ specification. + + .. _ISO 15472:2010: https://www.iso.org/standard/74811.html + + + + Has an energy calibration been applied? + + + + + This is the calibrated energy axis to be used for data plotting. + + + + + + + Has an angular calibration been applied? + + + + + This is the calibrated angular axis to be used for data plotting. + + + + + + + Has an spatial calibration been applied? + + + + + This is the calibrated spatial axis to be used for data plotting. + + + + + + + Has an momentum calibration been applied? + + + + + This is the momentum axis to be used for data plotting. + + + + + + For energy referencing, the measured energies are corrected for the charging potential + (i.e., the electrical potential of the surface region of an insulating sample, caused by + irradiation) such that those energies correspond to a sample with no surface charge. + Usually, the energy axis is adjusted by shifting all energies uniformally until one + well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. + + Refers to Term `12.74`_ ff. of the ISO 18115-1:2023 specification. + + .. _12.74: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 + + + + Have the energy axes been adjusted (e.g., in cases where samples are not + conductive)? + + + + + Electronic core or valence level that was used for the calibration. + + + + + Reference peak that was used for the calibration. + + For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge + + + + + The binding energy (in units of eV) that the specified emission line appeared at, + after adjusting the binding energy scale. + + Refers to Term `12.16`_ ff. of the ISO 18115-1:2023 specification. + + .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + + + + + Offset between measured binding energy and calibrated binding energy of the + emission line. + + + + + This is the calibrated energy axis to be used for data plotting. + + This should link to /entry/data/energy. + + + + + + In the transmission correction, each intensity measurement for electrons of a given + kinetic energy is multiplied by the corresponding value in the relative_intensity + field of the transmission_function. This calibration procedure is used to account for + the different tranmsission efficiencies when using different lens modes. + + + + Has an intensity calibration been applied? + + That is, has the transmission function of the analyser been taken into account? + + + + + Transmission function of the electron analyser. + + The transmission function (TF) specifies the detection efficiency for electrons of + different kinetic energy passing through the electron analyser. + This can be a link to /entry/instrument/electronanalyser/transmission_function. + + + + + + + + + + + + + + Kinetic energy values + + + + + + + + Relative transmission efficiency for the given kinetic energies + + + + + + + + + + + + + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + + + + + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + + + + + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). + + + + + Description of the surface preparation technique for the XPS experiment, i.e. + UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report + of the previous operations, in any format(NXnote allows to add pictures, audio, + movies). Alternatively, a reference to the location or a unique identifier or + other metadata file. In the case these are not available, free-text description. + + + + + In the case of a fixed temperature measurement this is the scalar temperature of + the sample. In the case of an experiment in which the temperature is changed and + recoded, this is an array of length m of temperatures. This should be a link to + /entry/instrument/manipulator/sample_temperature. + + + + + + + + + + + + + + Voltage applied to sample and sample holder. + + + + + + + + + + + + Represents a measure of one- or more-dimensional photoemission counts, where the + varied axis may be for example energy, momentum, spatial coordinate, pump-probe + delay, spin index, temperature, etc. The axes traces should be linked to the + actual encoder position in NXinstrument or calibrated axes in NXprocess. + + + + + Calibrated energy axis. + + The calibrated energy axis can be either in binding or kinetic energy. + This should be a link to either + /entry/process/energy_calibration/calibrated_axis or + /entry/process/energy_correction/calibrated_axis. + + + + The energy can be either stored as kinetic (Term `3.35`_ of the ISO 18115-1:2023 + specification) or as binding (Term `12.16`_) energy. + + .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 + .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + + + + + Calibrated kinetic energy axis. + + + + + Calibrated binding energy axis. + + + + + + + +>>>>>>> mpes-refactor diff --git a/contributed_definitions/NXresolution.nxdl.xml b/contributed_definitions/NXresolution.nxdl.xml index 13bab958f4..70eac45a43 100644 --- a/contributed_definitions/NXresolution.nxdl.xml +++ b/contributed_definitions/NXresolution.nxdl.xml @@ -74,18 +74,17 @@ - + - A symbol linking to another path in this appdef - to be referred to from the `resolution_formula` field. + A symbol linking to another path in this appdef to be referred to from the + `resolution_formula` field. This should be a valid path inside this application + definition, i.e., of the form /entry/instrument/my_part/my_field - - - - + + A resolution formula to determine the resolution from a set of symbols as - entered by the `formula_symbol_...` fields. + entered by the `formula_...` fields. The output unit should match the provided unit of this field. diff --git a/contributed_definitions/NXserialized.nxdl.xml b/contributed_definitions/NXserialized.nxdl.xml new file mode 100644 index 0000000000..fd587c6655 --- /dev/null +++ b/contributed_definitions/NXserialized.nxdl.xml @@ -0,0 +1,76 @@ + + + + + + Metadata to a set of pieces of information of a resource that has been serialized. + + A typical use case is the documentation of the source (file) or database (entry) + from which pieces of information have been extracted for consumption in e.g. a + research data management system (RDMS). This may be for reasons of enabling + services such as providing access to normalized information for which reading + again from the resource may not be desired, possibe, or feasible. + + Possible reasons could be the extraction of specific information for caching, + performance reasons, or re-evaluate given pieces of information based on other + views and interaction patterns with the data where information has been formatted + differently by tools than how these pieces of information were originally + serialized. + + + + Answers into what resource the information was serialized. + + + + + + + + + Path to the resource. + + E.g. the name of a file or its absolute or relative path, or the + identifier to a resource in another database. + + + + + Value of the checksum obtain when running algorithm on the resource. + + + + + Name of the algorithm whereby the checksum was computed. + + + + + + + + + Extracted file containing the serialized information. + + + diff --git a/contributed_definitions/nyaml/NXcalibration.yaml b/contributed_definitions/nyaml/NXcalibration.yaml index 6c4266cb2b..0c033a1611 100644 --- a/contributed_definitions/nyaml/NXcalibration.yaml +++ b/contributed_definitions/nyaml/NXcalibration.yaml @@ -12,21 +12,70 @@ symbols: Number of points of the calibrated and uncalibrated axes type: group NXcalibration(NXobject): + description(NX_CHAR): + doc: | + A description of the procedures employed. + calibration_method(NXidentifier): + doc: | + A digital persistent identifier (e.g., doi, ISO standard) referring to a detailed description of a + calibration method but no actual calibration data. + calibration_reference(NXidentifier): + doc: | + A digital persistent identifier (e.g., a doi) referring to a + publicly available calibration measurement used for this instrument + , e.g., a measurement of a known standard containing calibration information. + The axis values may be copied or linked in the appropriate NXcalibration fields for reference. + calibration_object(NXserialized): + doc: | + A file serialisation of a calibration which may not be publicly available (externally from the nexus file). + + This metadata can be a documentation of the source (file) or database (entry) from which pieces + of information have been extracted for consumption in e.g. a research data management system (RDMS). + It is also possible to include the actual file by using the `file` field. + + The axis values may be copied or linked in the appropriate NXcalibration fields for reference. last_process(NX_CHAR): doc: | Indicates the name of the last operation applied in the NXprocess sequence. applied(NX_BOOLEAN): doc: | Has the calibration been applied? + original_axis(NX_FLOAT): + unit: NX_ANY + doc: | + Vector containing the data coordinates in the original uncalibrated axis + dim: (ncal, ) + \@symbol: + doc: | + The symbol of the axis to be used in the fit_function, e.g., `energy`, `E`. + This should comply to the following naming rules (similar to python's naming rules): + + * A variable name must start with a letter or the underscore character + * A variable name cannot start with a number + * A variable name can only contain alpha-numeric characters and underscores (A-z, 0-9, and _ ) + * Variable names are case-sensitive (age, Age and AGE are three different variables) + \@input_path: + doc: | + The path from which this data is derived, e.g., raw detector axis. + Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. + input_SYMBOL(NX_FLOAT): + unit: NX_ANY + doc: | + Additional input axis to be used in the formula. + The part after `input_` is used as the symbol to be used in the `fit_function`, i.e., + if the field name is `input_my_field` you should refer to this axis by `my_field` in the `fit_function`. + dim: (ncal, ) + \@input_path: + doc: | + The path from which this data is derived, e.g., raw detector axis. + Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. coefficients(NX_FLOAT): unit: NX_ANY doc: | For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit to a set of features (peaks) at well defined energy positions to determine E(TOF). Here we can store the array of fit coefficients. - dimensions: - rank: 1 - dim: [[1, ncoeff]] + dim: (ncoeff, ) fit_function(NX_CHAR): doc: | For non-linear energy calibrations. Here we can store the formula of the @@ -34,47 +83,43 @@ NXcalibration(NXobject): Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - Use x0, x1, ..., xn for the variables. + Use x0, x1, ..., xn for the nth position in the `original_axis` field. + If there is the symbol attribute specified for the `original_axis` this may be used instead of x. + If you want to use the whole axis use `x`. + Alternate axis can also be available as specified by the `input_SYMBOL` field. + The data should then be referred here by the `SYMBOL` name, e.g., for a field + name `input_my_field` it should be referred here by `my_field` or `my_field0` if + you want to read the zeroth element of the array. The formula should be numpy compliant. scaling(NX_FLOAT): unit: NX_ANY doc: | For linear calibration. Scaling parameter. + This is should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. offset(NX_FLOAT): unit: NX_ANY doc: | For linear calibration. Offset parameter. + This is should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. + MAPPING(NX_FLOAT): + doc: | + Mapping data for calibration. + + This can be used to map data points from uncalibrated to calibrated values, + i.e., by multiplying each point in the input axis by the corresponding point in the mapping data. calibrated_axis(NX_FLOAT): unit: NX_ANY doc: | A vector representing the axis after calibration, matching the data length - dimensions: - rank: 1 - dim: [[1, ncal]] - original_axis(NX_FLOAT): - unit: NX_ANY - doc: | - Vector containing the data coordinates in the original uncalibrated axis - dimensions: - rank: 1 - dim: [[1, ncal]] - description: - doc: | - A description of the procedures employed. - calibration_file(NXnote): - doc: | - File containing the input data for calibration. - mapping(NXdata): - doc: | - Mapping data for calibration. - - This can be used to map data points from uncalibrated - to calibrated values, e.g., by multiplying each point by the - corresponding point in the mapping data. + dim: (ncal, ) + \@output_path: + doc: | + The path to which this data is written, e.g., the calibrated energy. + Should be a valid NeXus path name, e.g., /entry/data/energy. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 307fdbe810f63da8d54f0ba5281847e4809c5f4e9baaa07994793462797acdf6 +# 21c19234fb652a2b69a595f90b67aaf60b48369b8dfa378bb4440e516c389dc4 # # # -# -# -# Describes a link -# -# -# -# The symbol by which to refer to this link, e.g., for formulas -# -# -# -# -# A valid path inside an instance of an application definition, i.e., -# of the form /entry/instrument/my_part/my_field -# -# -# diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 9f4bba9bca..bf72377c90 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -9,4 +9,50 @@ doc: | .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 type: group -NXmpes(NXphotoemission): \ No newline at end of file +NXmpes(NXphotoemission): + (NXentry): + definition: + \@version: + enumeration: [NXmpes] + method: + exists: recommended + doc: | + A name of the experimental method according to `Clause 11`_ of + the `ISO 18115-1:2023`_ specification. + + Examples include: + * X-ray photoelectron spectroscopy (XPS) + * angle-resolved X-ray photoelectron spectroscopy (ARXPS) + * ultraviolet photoelectron spectroscopy (UPS) + * angle-resolved photoelectron spectroscopy (ARPES) + * hard X-ray photoemission spectroscopy (HAXPES) + * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) + * electron spectroscopy for chemical analysis (ESCA) + + .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 + (NXinstrument): + doc: | + MPES spectrometer + + Refers to Term `12.58`_ of the ISO 18115-1:2023 specification. + + .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 + energy_resolution(NXresolution): + exists: recommended + doc: | + Overall energy resolution of the MPES instrument. + + Refers to Terms `10.7`_ ff. and `10.24`_ of the ISO 18115-1:2023 specification. + + .. _10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 + .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 + (NXelectronanalyser): + energy_resolution(NX_FLOAT): + exists: recommended + (NXcollectioncolumn): + scheme: + enumeration: [Standard, Angular dispersive, Spatial dispersive, Selective area, Deflector, torroidal] + (NXenergydispersion): + (NXdata): + energy(NX_NUMBER): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXphotoemission.yaml b/contributed_definitions/nyaml/NXphotoemission.yaml index a6d934cbde..fb220eb02a 100644 --- a/contributed_definitions/nyaml/NXphotoemission.yaml +++ b/contributed_definitions/nyaml/NXphotoemission.yaml @@ -18,7 +18,7 @@ NXphotoemission(NXobject): (NXentry): definition: \@version: - enumeration: [NXmpes] + enumeration: [NXphotoemission] title: start_time(NX_DATE_TIME): doc: | @@ -59,15 +59,12 @@ NXphotoemission(NXobject): performed. (NXinstrument): doc: | - MPES spectrometer - - Refers to Term `12.58`_ of the ISO 18115-1:2023 specification. - - .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 + Photoemission instrument energy_resolution(NXresolution): - exists: recommended + exists: optional doc: | - Overall energy resolution of the MPES instrument + Overall energy resolution of the instrument in case the energy of the electrons + is resolved. Refers to Terms `10.7`_ ff. and `10.24`_ of the ISO 18115-1:2023 specification. @@ -104,10 +101,11 @@ NXphotoemission(NXobject): name: exists: recommended probe: + exists: optional doc: | Type of probe. In photoemission it's always photons, so the full NIAC list is restricted. - enumeration: [photons] + enumeration: [photon, x-ray, visible light, ultraviolet] device_information(NXfabrication): exists: recommended vendor: @@ -165,7 +163,7 @@ NXphotoemission(NXobject): exists: recommended description: energy_resolution(NX_FLOAT): - exists: recommended + exists: optional unit: NX_ENERGY doc: | Energy resolution of the analyser with the current setting. May be linked from a @@ -188,7 +186,7 @@ NXphotoemission(NXobject): scheme: doc: | Scheme of the electron collection column. - enumeration: [Standard, Angular dispersive, Spatial dispersive, Selective area, Deflector, PEEM, Momentum Microscope] + enumeration: [Standard, Angular dispersive, Spatial dispersive, Selective area, Deflector, PEEM, Momentum Microscope, torroidal] mode: exists: recommended doc: | @@ -223,6 +221,7 @@ NXphotoemission(NXobject): identifier: exists: recommended (NXenergydispersion): + exists: optional scheme: enumeration: [tof, hemispherical, double hemispherical, cylindrical mirror, display mirror, retarding grid] pass_energy(NX_FLOAT): @@ -462,12 +461,12 @@ NXphotoemission(NXobject): preparation_date(NX_DATE_TIME): exists: recommended doc: | - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + Date of preparation of the sample for the photoemission experiment (i.e. cleaving, last annealing). preparation_description(NXnote): exists: optional doc: | - Description of the surface preparation technique for the XPS experiment, i.e. + Description of the surface preparation technique for the photoemission 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 @@ -502,7 +501,7 @@ NXphotoemission(NXobject): delay, spin index, temperature, etc. The axes traces should be linked to the actual encoder position in NXinstrument or calibrated axes in NXprocess. energy(NX_NUMBER): - exists: recommended + exists: optional doc: | Calibrated energy axis. @@ -525,681 +524,4 @@ NXphotoemission(NXobject): Calibrated kinetic energy axis. binding: doc: | - Calibrated binding energy axis. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 83b124ee2d429df9b9b06b36c540fc64a4d9340e74cfebf03c9fc450257b6eb0 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays -# -# -# -# Number of data points in the transmission function. -# -# -# -# -# This is the most general application definition for multidimensional -# photoelectron spectroscopy. -# -# Groups and fields are named according to the -# `ISO 18115-1:2023`_ specification as well as the `IUPAC Recommendations 2020`_. -# -# .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html -# .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 -# -# -# -# -# -# -# -# -# -# -# -# Datetime of the start of the measurement. -# -# -# -# -# Datetime of the end of the measurement. -# -# -# -# -# A name of the experimental method according to `Clause 11`_ of -# the `ISO 18115-1:2023`_ specification. -# -# Examples include: -# * X-ray photoelectron spectroscopy (XPS) -# * angle-resolved X-ray photoelectron spectroscopy (ARXPS) -# * ultraviolet photoelectron spectroscopy (UPS) -# * angle-resolved photoelectron spectroscopy (ARPES) -# * hard X-ray photoemission spectroscopy (HAXPES) -# * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) -# * photoelectron emission microscopy (PEEM) -# * electron spectroscopy for chemical analysis (ESCA) -# -# .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html -# .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 -# -# -# -# -# Contact information of at least the user of the instrument or the investigator -# who performed this experiment. Adding multiple users if relevant is recommended. -# -# -# -# Name of the user. -# -# -# -# -# Name of the affiliation of the user at the point in time when the experiment was -# performed. -# -# -# -# -# Full address (street, street number, ZIP, city, country) of the user's -# affiliation. -# -# -# -# -# Email address of the user. -# -# -# -# -# Author ID defined by https://orcid.org/. -# -# -# -# -# -# MPES spectrometer -# -# Refers to Term `12.58`_ of the ISO 18115-1:2023 specification. -# -# .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 -# -# -# -# Overall energy resolution of the MPES instrument -# -# Refers to Terms `10.7`_ ff. and `10.24`_ of the ISO 18115-1:2023 specification. -# -# .. _10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 -# .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# 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. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Specification of type, may also go to name. -# -# -# -# -# -# Type of probe. In photoemission it's always photons, so the full NIAC list is -# restricted. -# -# -# -# -# -# -# -# -# -# -# -# -# The beam emitted by this source. -# Should be named with the same appendix, e.g., -# for `source_probe` it should refer to `beam_probe`. -# Refers to the same concept as /NXentry/NXinstrument/beam_TYPE -# and may be linked. -# -# -# -# -# -# -# -# The beam emitted by this source. -# Should be named with the same appendix, e.g., -# for `source_probe` it should refer to `beam_probe`. -# Refers to the same concept as /NXentry/NXinstrument/source_TYPE -# and may be linked. -# -# -# -# -# -# -# -# -# The source that emitted this beam. -# Should be named with the same appendix, e.g., -# for `beam_probe` it should refer to `source_probe`. -# Refers to the same concept as /NXentry/NXinstrument/source_TYPE -# and may be linked. -# -# -# -# -# -# -# -# -# -# -# -# -# Energy resolution of the analyser with the current setting. May be linked from a -# NXcalibration. -# -# Refers to Term `10.24`_ of the ISO 18115-1:2023 specification. -# -# .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 -# -# -# -# -# -# -# -# -# -# Scheme of the electron collection column. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Labelling of the lens setting in use. -# -# -# -# -# -# The size and position of the field aperture inserted in the column. To add -# additional or other apertures use the APERTURE group of NXcollectioncolumn. -# -# -# -# -# The size and position of the contrast aperture inserted in the column. To add -# additional or other apertures use the APERTURE group of NXcollectioncolumn. -# -# -# -# -# Size, position and shape of the iris inserted in the column. -# -# The iris is an aperture in the lens with a variable diameter which can reduce the number of -# electrons entering the analyzer. -# -# To add additional or other slits use the APERTURE group of NXcollectioncolumn. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Size, position and shape of the entrance slit in dispersive analyzers. -# -# To add additional or other slits use the APERTURE group of NXenergydispersion. -# -# -# -# -# Size, position and shape of the exit slit in dispersive analyzers. -# -# To add additional or other slits use the APERTURE group of NXenergydispersion. -# -# -# -# -# -# -# -# -# -# -# -# Type of electron amplifier in the first amplification step. -# -# -# -# -# -# -# -# -# Description of the detector type. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Raw data before calibration. -# -# -# -# -# -# -# -# Manipulator for positioning of the sample. -# -# -# -# -# -# Bias of the sample with respect to analyser ground. -# -# This field may also be found in NXsample if present. -# -# Refers to Term `8.41`_ of the ISO 18115-1:2023 specification. -# -# .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 -# -# -# -# -# -# -# -# -# -# -# -# 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 -# -# -# -# Calibration event on the energy axis. -# -# For XPS, the calibration should ideally be performed according to -# `ISO 15472:2010`_ specification. -# -# .. _ISO 15472:2010: https://www.iso.org/standard/74811.html -# -# -# -# Has an energy calibration been applied? -# -# -# -# -# This is the calibrated energy axis to be used for data plotting. -# -# -# -# -# -# -# Has an angular calibration been applied? -# -# -# -# -# This is the calibrated angular axis to be used for data plotting. -# -# -# -# -# -# -# Has an spatial calibration been applied? -# -# -# -# -# This is the calibrated spatial axis to be used for data plotting. -# -# -# -# -# -# -# Has an momentum calibration been applied? -# -# -# -# -# This is the momentum axis to be used for data plotting. -# -# -# -# -# -# For energy referencing, the measured energies are corrected for the charging potential -# (i.e., the electrical potential of the surface region of an insulating sample, caused by -# irradiation) such that those energies correspond to a sample with no surface charge. -# Usually, the energy axis is adjusted by shifting all energies uniformally until one -# well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. -# -# Refers to Term `12.74`_ ff. of the ISO 18115-1:2023 specification. -# -# .. _12.74: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 -# -# -# -# Have the energy axes been adjusted (e.g., in cases where samples are not -# conductive)? -# -# -# -# -# Electronic core or valence level that was used for the calibration. -# -# -# -# -# Reference peak that was used for the calibration. -# -# For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge -# -# -# -# -# The binding energy (in units of eV) that the specified emission line appeared at, -# after adjusting the binding energy scale. -# -# Refers to Term `12.16`_ ff. of the ISO 18115-1:2023 specification. -# -# .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 -# -# -# -# -# Offset between measured binding energy and calibrated binding energy of the -# emission line. -# -# -# -# -# This is the calibrated energy axis to be used for data plotting. -# -# This should link to /entry/data/energy. -# -# -# -# -# -# In the transmission correction, each intensity measurement for electrons of a given -# kinetic energy is multiplied by the corresponding value in the relative_intensity -# field of the transmission_function. This calibration procedure is used to account for -# the different tranmsission efficiencies when using different lens modes. -# -# -# -# Has an intensity calibration been applied? -# -# That is, has the transmission function of the analyser been taken into account? -# -# -# -# -# Transmission function of the electron analyser. -# -# The transmission function (TF) specifies the detection efficiency for electrons of -# different kinetic energy passing through the electron analyser. -# This can be a link to /entry/instrument/electronanalyser/transmission_function. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Kinetic energy values -# -# -# -# -# -# -# -# Relative transmission efficiency for the given kinetic energies -# -# -# -# -# -# -# -# -# -# -# -# -# The chemical formula of the sample. For mixtures use the NXsample_component -# group in NXsample instead. -# -# -# -# -# A descriptor to keep track of the treatment of the sample before entering the -# photoemission experiment. Ideally, a full report of the previous operations, in -# any format (NXnote allows to add pictures, audio, movies). Alternatively, a -# reference to the location or a unique identifier or other metadata file. In the -# case these are not available, free-text description. -# -# -# -# -# List of comma-separated elements from the periodic table -# that are contained in the sample. -# If the sample substance has multiple components, all -# elements from each component must be included in `atom_types`. -# -# -# -# -# -# Date of preparation of the sample for the XPS experiment (i.e. cleaving, last -# annealing). -# -# -# -# -# Description of the surface preparation technique for the XPS experiment, i.e. -# UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report -# of the previous operations, in any format(NXnote allows to add pictures, audio, -# movies). Alternatively, a reference to the location or a unique identifier or -# other metadata file. In the case these are not available, free-text description. -# -# -# -# -# In the case of a fixed temperature measurement this is the scalar temperature of -# the sample. In the case of an experiment in which the temperature is changed and -# recoded, this is an array of length m of temperatures. This should be a link to -# /entry/instrument/manipulator/sample_temperature. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Voltage applied to sample and sample holder. -# -# -# -# -# -# -# -# -# -# -# -# Represents a measure of one- or more-dimensional photoemission counts, where the -# varied axis may be for example energy, momentum, spatial coordinate, pump-probe -# delay, spin index, temperature, etc. The axes traces should be linked to the -# actual encoder position in NXinstrument or calibrated axes in NXprocess. -# -# -# -# -# Calibrated energy axis. -# -# The calibrated energy axis can be either in binding or kinetic energy. -# This should be a link to either -# /entry/process/energy_calibration/calibrated_axis or -# /entry/process/energy_correction/calibrated_axis. -# -# -# -# The energy can be either stored as kinetic (Term `3.35`_ of the ISO 18115-1:2023 -# specification) or as binding (Term `12.16`_) energy. -# -# .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 -# .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 -# -# -# -# -# Calibrated kinetic energy axis. -# -# -# -# -# Calibrated binding energy axis. -# -# -# -# -# -# -# -# + Calibrated binding energy axis. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXresolution.yaml b/contributed_definitions/nyaml/NXresolution.yaml index 22a6bfdce1..03fd711761 100644 --- a/contributed_definitions/nyaml/NXresolution.yaml +++ b/contributed_definitions/nyaml/NXresolution.yaml @@ -36,25 +36,22 @@ NXresolution(NXobject): The magnitude of the response function corresponding to the points in the input axis or grid. This field should have the same dimensions as `input`. - formula_symbol_LINK(NXlink): + formula_SYMBOL(NX_CHAR): doc: | - A symbol linking to another path in this appdef - to be referred to from the `resolution_formula` field. - symbol: - exists: optional - path: - exists: optional - resolution_formula: + A symbol linking to another path in this appdef to be referred to from the + `resolution_formula` field. This should be a valid path inside this application + definition, i.e., of the form /entry/instrument/my_part/my_field + resolution_formula(NX_CHAR): doc: | A resolution formula to determine the resolution from a set of symbols as - entered by the `formula_symbol_...` fields. + entered by the `formula_...` fields. The output unit should match the provided unit of this field. (NXcalibration): doc: | For storing details and data of a calibration to derive a resolution from data # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 234db054d09b94441d581d54d7d4bd4d5d4a7b01fcd4ac752eda4400f3b27502 +# 16dd07ac4d686000037772aa28146a800c2dbce278dc8d66f0962bab4847c751 # # # - - Definition of the root NeXus group. + + + Definition of the root NeXus group. + - The root of any NeXus data file is an ``NXroot`` class - (no other choice is allowed for a valid NeXus data file). - This attribute cements that definition. + The root of any NeXus data file is an ``NXroot`` class + (no other choice is allowed for a valid NeXus data file). + This attribute cements that definition. - + - Date and time file was originally created + + Date and time file was originally created + - File name of original NeXus file + + File name of original NeXus file + - Date and time of last file change at close + + Date and time of last file change at close + + + + + A repository containing the application definitions + used for creating this file. + If the NeXus_version attribute contains a commit distance and hash + this should refer to this repository. + - Version of NeXus API used in writing the file. - - Only used when the NAPI has written the file. - Note that this is different from the version of the - base class or application definition version number. + Version of NeXus definitions used in writing the file. + This may either be a date based version tag of the form `vYYYY.MM` + or a version tag with a commit distance and source control (e.g., git) hash of + the form `vYYYY.MM.post1.dev<commit-distance>.g<git-hash>`. + It may contain an additional `.dYYYYMMDD` timestamp appendix + for dirty repositories. + If the version contains a commit distance and hash the + NeXus_repository attribute should be written with the + repository url containing this version. + + Only used when the NAPI or pynxtools has written the file. + Note that this is different from the version of the + base class or application definition version number. + + + + + A list of concepts in an application definition this file describes. + This is for partially filling an application definition. + If this attribute is not present the application definition is assumed + to be valid, if not only the specified concepts/paths are assumed to be valid. - Version of HDF (version 4) library used in writing the file + + Version of HDF (version 4) library used in writing the file + - Version of HDF5 library used in writing the file. - - Note this attribute is spelled with uppercase "V", - different than other version attributes. + Version of HDF5 library used in writing the file. + + Note this attribute is spelled with uppercase "V", + different than other version attributes. - Version of XML support library used in writing the XML file + + Version of XML support library used in writing the XML file + - Version of h5py Python package used in writing the file + + Version of h5py Python package used in writing the file + - facility or program where file originated + + facility or program where file originated + - Version of facility or program used in writing the file + + Version of facility or program used in writing the file + - - entries + + + entries + - .. index:: find the default plottable data - .. index:: plotting - .. index:: default attribute value - - Declares which :ref:`NXentry` group contains - the data to be shown by default. - It is used to resolve ambiguity when - more than one :ref:`NXentry` group exists. - The value :ref:`names <validItemName>` the default :ref:`NXentry` group. The - value must be the name of a child of the current group. The child must be a - NeXus group or a link to a NeXus group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: find the default plottable data + .. index:: plotting + .. index:: default attribute value + + Declares which :ref:`NXentry` group contains + the data to be shown by default. + It is used to resolve ambiguity when + more than one :ref:`NXentry` group exists. + The value :ref:`names <validItemName>` the default :ref:`NXentry` group. The + value must be the name of a child of the current group. The child must be a + NeXus group or a link to a NeXus group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. - diff --git a/base_classes/nyaml/NXroot.yaml b/base_classes/nyaml/NXroot.yaml index bcecfaa0a8..fbb03c947e 100644 --- a/base_classes/nyaml/NXroot.yaml +++ b/base_classes/nyaml/NXroot.yaml @@ -20,13 +20,33 @@ NXroot(NXobject): type: NX_DATE_TIME doc: | Date and time of last file change at close + \@NeXus_repository: + doc: | + A repository containing the application definitions + used for creating this file. + If the NeXus_version attribute contains a commit distance and hash + this should refer to this repository. \@NeXus_version: doc: | - Version of NeXus API used in writing the file. + Version of NeXus definitions used in writing the file. + This may either be a date based version tag of the form `vYYYY.MM` + or a version tag with a commit distance and source control (e.g., git) hash of + the form `vYYYY.MM.post1.dev.g`. + It may contain an additional `.dYYYYMMDD` timestamp appendix + for dirty repositories. + If the version contains a commit distance and hash the + NeXus_repository attribute should be written with the + repository url containing this version. - Only used when the NAPI has written the file. + Only used when the NAPI or pynxtools has written the file. Note that this is different from the version of the base class or application definition version number. + \@partial: + doc: | + A list of concepts in an application definition this file describes. + This is for partially filling an application definition. + If this attribute is not present the application definition is assumed + to be valid, if not only the specified concepts/paths are assumed to be valid. \@HDF_version: doc: | Version of HDF (version 4) library used in writing the file From d5bf3c54b6b1078fcae970727bcd6c30597cff22 Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Wed, 8 Nov 2023 09:06:52 +0100 Subject: [PATCH 0351/1012] Fix NXroot nxdl (#112) --- base_classes/NXroot.nxdl.xml | 238 +++++++++++++++++------------------ 1 file changed, 119 insertions(+), 119 deletions(-) diff --git a/base_classes/NXroot.nxdl.xml b/base_classes/NXroot.nxdl.xml index cc488469d5..a480f82d41 100644 --- a/base_classes/NXroot.nxdl.xml +++ b/base_classes/NXroot.nxdl.xml @@ -1,9 +1,9 @@ - + + + Definition of the root NeXus group. + + - Definition of the root NeXus group. + The root of any NeXus data file is an ``NXroot`` class + (no other choice is allowed for a valid NeXus data file). + This attribute cements that definition. - - - The root of any NeXus data file is an ``NXroot`` class - (no other choice is allowed for a valid NeXus data file). - This attribute cements that definition. - - - - - - - - Date and time file was originally created - - - - - File name of original NeXus file - - - - - Date and time of last file change at close - - - - - A repository containing the application definitions - used for creating this file. - If the NeXus_version attribute contains a commit distance and hash - this should refer to this repository. - - - - - Version of NeXus definitions used in writing the file. - This may either be a date based version tag of the form `vYYYY.MM` - or a version tag with a commit distance and source control (e.g., git) hash of - the form `vYYYY.MM.post1.dev<commit-distance>.g<git-hash>`. - It may contain an additional `.dYYYYMMDD` timestamp appendix - for dirty repositories. - If the version contains a commit distance and hash the - NeXus_repository attribute should be written with the - repository url containing this version. - - Only used when the NAPI or pynxtools has written the file. - Note that this is different from the version of the - base class or application definition version number. - - - - - A list of concepts in an application definition this file describes. - This is for partially filling an application definition. - If this attribute is not present the application definition is assumed - to be valid, if not only the specified concepts/paths are assumed to be valid. - - - - - Version of HDF (version 4) library used in writing the file - - - - - Version of HDF5 library used in writing the file. - - Note this attribute is spelled with uppercase "V", - different than other version attributes. - - - - - Version of XML support library used in writing the XML file - - - - - Version of h5py Python package used in writing the file - - - - - facility or program where file originated - - - - - Version of facility or program used in writing the file - - - - - entries - - - - - .. index:: find the default plottable data - .. index:: plotting - .. index:: default attribute value - - Declares which :ref:`NXentry` group contains - the data to be shown by default. - It is used to resolve ambiguity when - more than one :ref:`NXentry` group exists. - The value :ref:`names <validItemName>` the default :ref:`NXentry` group. The - value must be the name of a child of the current group. The child must be a - NeXus group or a link to a NeXus group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - + + + + + + + Date and time file was originally created + + + + + File name of original NeXus file + + + + + Date and time of last file change at close + + + + + A repository containing the application definitions + used for creating this file. + If the NeXus_version attribute contains a commit distance and hash + this should refer to this repository. + + + + + Version of NeXus definitions used in writing the file. + This may either be a date based version tag of the form `vYYYY.MM` + or a version tag with a commit distance and source control (e.g., git) hash of + the form `vYYYY.MM.post1.dev<commit-distance>.g<git-hash>`. + It may contain an additional `.dYYYYMMDD` timestamp appendix + for dirty repositories. + If the version contains a commit distance and hash the + NeXus_repository attribute should be written with the + repository url containing this version. + + Only used when the NAPI or pynxtools has written the file. + Note that this is different from the version of the + base class or application definition version number. + + + + + A list of concepts in an application definition this file describes. + This is for partially filling an application definition. + If this attribute is not present the application definition is assumed + to be valid, if not only the specified concepts/paths are assumed to be valid. + + + + + Version of HDF (version 4) library used in writing the file + + + + + Version of HDF5 library used in writing the file. + + Note this attribute is spelled with uppercase "V", + different than other version attributes. + + + + + Version of XML support library used in writing the XML file + + + + + Version of h5py Python package used in writing the file + + + + + facility or program where file originated + + + + + Version of facility or program used in writing the file + + + + + entries + + + + + .. index:: find the default plottable data + .. index:: plotting + .. index:: default attribute value + + Declares which :ref:`NXentry` group contains + the data to be shown by default. + It is used to resolve ambiguity when + more than one :ref:`NXentry` group exists. + The value :ref:`names <validItemName>` the default :ref:`NXentry` group. The + value must be the name of a child of the current group. The child must be a + NeXus group or a link to a NeXus group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + + From 7aeffc38295a9adcf3f83a24809a9c33da820f39 Mon Sep 17 00:00:00 2001 From: Rubel Date: Mon, 6 Nov 2023 12:08:53 +0100 Subject: [PATCH 0352/1012] Fix rebase conflict and PR change request. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fix rebase conflict. Fix rebase conflict. Disable fail-fast to check which versions work Actually *disable* fail-fast 🙈 Fix rebase conflict. Fix rebase conflict. Fix rebase conflict. Fix rebase conflict. Fix rebase conflict. Fix rebase conflict. Responding on PR review comments. Changes for PR review. Changes for PR review. Changes for PR review. Changes for PR review. Changes for PR review. Changes for PR review. Changes for PR revie. --- Makefile | 5 +- dev_tools/nyaml2nxdl/README.md | 41 +++++- dev_tools/nyaml2nxdl/comment_collector.py | 35 ----- dev_tools/nyaml2nxdl/nyaml2nxdl.py | 3 +- .../nyaml2nxdl/nyaml2nxdl_backward_tools.py | 130 ++++++++++-------- .../nyaml2nxdl/nyaml2nxdl_forward_tools.py | 72 +++++++++- dev_tools/nyaml2nxdl/nyaml2nxdl_helper.py | 1 + dev_tools/tests/data/doc_nxdl2yaml.nxdl.xml | 72 ++++++++++ dev_tools/tests/data/doc_yaml2nxdl.yaml | 48 +++++++ dev_tools/tests/data/ref_doc_nxdl2yaml.yaml | 47 +++++++ .../tests/data/ref_doc_yaml2nxdl.nxdl.xml | 72 ++++++++++ dev_tools/tests/test_nyaml2nxdl.py | 80 +++++++++-- dev_tools/utils/nxdl_utils.py | 123 ----------------- 13 files changed, 499 insertions(+), 230 deletions(-) create mode 100644 dev_tools/tests/data/doc_nxdl2yaml.nxdl.xml create mode 100644 dev_tools/tests/data/doc_yaml2nxdl.yaml create mode 100644 dev_tools/tests/data/ref_doc_nxdl2yaml.yaml create mode 100644 dev_tools/tests/data/ref_doc_yaml2nxdl.nxdl.xml diff --git a/Makefile b/Makefile index 0d2cf9d647..ee24b8c7a4 100644 --- a/Makefile +++ b/Makefile @@ -9,6 +9,7 @@ BUILD_DIR = "build" BASE_CLASS_DIR := base_classes CONTRIB_DIR := contributed_definitions APPDEF_DIR := applications +NXDL_DIRS := $(BASE_CLASS_DIR) $(CONTRIB_DIR) $(APPDEF_DIR) NYAML_SUBDIR := nyaml NYAML_APPENDIX := _parsed @@ -58,6 +59,8 @@ test :: clean :: $(RM) -rf $(BUILD_DIR) + +clean-nyaml :: $(RM) -rf $(BASE_CLASS_DIR)/$(NYAML_SUBDIR) $(RM) -rf $(APPDEF_DIR)/$(NYAML_SUBDIR) $(RM) -rf $(CONTRIB_DIR)/$(NYAML_SUBDIR) @@ -136,4 +139,4 @@ nxdl: $(NXDL_APPDEF) $(NXDL_CONTRIB) $(NXDL_BC) # License along with this library; if not, write to the Free Software # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA # -# For further information, see http://www.nexusformat.org +# For further information, see http://www.nexusformat.org \ No newline at end of file diff --git a/dev_tools/nyaml2nxdl/README.md b/dev_tools/nyaml2nxdl/README.md index 4b316fc5d0..da1b93d923 100644 --- a/dev_tools/nyaml2nxdl/README.md +++ b/dev_tools/nyaml2nxdl/README.md @@ -44,7 +44,44 @@ Options: * Optionality: For all fields, groups and attributes in `application definitions` are `required` by default, except anything (`recommended` or `optional`) mentioned. **Special keywords**: Several keywords can be used as childs of groups, fields, and attributes to specify the members of these. Groups, fields and attributes are nodes of the XML tree. -* **doc**: A human-readable description/docstring +* **doc**: + - A human-readable description/docstring + - Doc string may also come as a list of doc parts when user wants to add `reference` for a concept. Or doc string could be a single doc block. + ```yaml + energy: # field + doc: + - | + Part1 of the entire doc. + part1 of the entire doc. + - | # Reference for concept + "xref: + spec: + term: + url: " + - | + Rest of the doc + rest of the doc + velocity: # field + doc: | + A single block of doc string. + ``` + Such structure of doc would be appreared in `nxdl` as + ```xml + ... + + Part1 of the entire doc. + part1 of the entire doc. + + This concept is related to term ``_ of the standard. + .. : . + + Rest of the doc. + rest of the doc. + + ``` + + + * **exists** Options are recommended, required, [min, 1, max, `infty`] numbers like here 1 can be replaced by any `uint` (unsigned integer), or `infty` to indicate no restriction on how frequently the entry can occur inside the NXDL schema at the same hierarchy level. * **link** Define links between nodes. * **units** A statement introducing NeXus-compliant NXDL units arguments, like NX_VOLTAGE @@ -52,7 +89,7 @@ Options: * **enumeration** Python list of strings which are considered as recommended entries to choose from. * **dim_parameters** `dim` which is a child of `dimension` and the `dim` might have several attributes `ref`, `incr` including `index` and `value`. So while writing `yaml` file schema definition please following structure: -``` +```yaml dimensions: rank: integer value dim: [[ind_1, val_1], [ind_2, val_2], ...] diff --git a/dev_tools/nyaml2nxdl/comment_collector.py b/dev_tools/nyaml2nxdl/comment_collector.py index 250ec63955..6ded2f3720 100644 --- a/dev_tools/nyaml2nxdl/comment_collector.py +++ b/dev_tools/nyaml2nxdl/comment_collector.py @@ -19,18 +19,8 @@ # """ -<<<<<<< HEAD -<<<<<<< HEAD Collect comments in a list by CommentCollector class and each comment is an instance of Comment class. Each `Comment` instance(sometimes refered as 'comment block') consists of text and line -======= -Collect comments in a list by CommentCollector class and each comment is an instance of Comment -class. Each `Comment` instance(sometimes refered as 'comment block') consists of text and line ->>>>>>> 3ef8b382 (Resolving requested changes.) -======= -Collect comments in a list by CommentCollector class and each comment is an instance of Comment -class. Each `Comment` instance(sometimes refered as 'comment block') consists of text and line ->>>>>>> 8cfbb6f3 (Fix codestyle) info or neighbours info where the comment must be placed. The class Comment is an abstract class for general functions or method to be implemented @@ -91,18 +81,8 @@ def __init__(self, input_file: str = None, loaded_obj: Union[object, Dict] = Non raise ValueError("Incorrect inputs for CommentCollector") def extract_all_comment_blocks(self): -<<<<<<< HEAD -<<<<<<< HEAD - """Collect all comments. - -======= - """Collect all comments. - ->>>>>>> 3ef8b382 (Resolving requested changes.) -======= """Collect all comments. ->>>>>>> 8cfbb6f3 (Fix codestyle) Note here that comment means (comment text + element or line info intended for comment. """ @@ -498,26 +478,11 @@ def replace_escape_char(self, text): return text def get_element_location(self): -<<<<<<< HEAD -<<<<<<< HEAD - """Return yaml line '__line__' info and and line numner""" - if len(self._elemt) == 0: - raise ValueError( - f"Comment element should be one or more but got {self._elemt}" - ) -======= - """Return yaml line '__line__' info and and line numner - """ - if len(self._elemt) == 0: - raise ValueError(f"Comment element should be one or more but got {self._elemt}") ->>>>>>> 3ef8b382 (Resolving requested changes.) -======= """Return yaml line '__line__' info and and line numner""" if len(self._elemt) == 0: raise ValueError( f"Comment element should be one or more but got {self._elemt}" ) ->>>>>>> 8cfbb6f3 (Fix codestyle) return next(self._elemt.items()) def collect_yaml_line_info(self, yaml_dict, line_info_dict): diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl.py b/dev_tools/nyaml2nxdl/nyaml2nxdl.py index e3393447c3..4031d6bbdf 100755 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl.py +++ b/dev_tools/nyaml2nxdl/nyaml2nxdl.py @@ -3,7 +3,7 @@ Main file of nyaml2nxdl tool. To write a definition for a instrument, experiment and/or process in nxdl.xml file from a YAML -file which details a hierarchy of data/metadata elements. It also allows both way +file which details a hierarchy of data/metadata elements. It also allows both wa conversion beteen YAML and nxdl.xml files that follows rules of NeXus ontology or data format. """ # -*- coding: utf-8 -*- @@ -122,6 +122,7 @@ def launch_tool(input_file, verbose, do_not_store_nxdl, check_consistency): if ext == "yaml": xml_out_file = raw_name + _nxdl generate_nxdl_or_retrieve_nxdl(input_file, xml_out_file, verbose) + # For consistency running if check_consistency: yaml_out_file = raw_name + "_consistency." + ext diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py b/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py index 25a5d92351..314c565ad0 100755 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py +++ b/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py @@ -21,17 +21,8 @@ # limitations under the License. # -<<<<<<< HEAD -<<<<<<< HEAD -from pathlib import Path -from typing import Callable -from typing import Dict -======= -from typing import Dict, Callable ->>>>>>> 3ef8b382 (Resolving requested changes.) -from typing import List -======= ->>>>>>> 8cfbb6f3 (Fix codestyle) +import re +import textwrap from pathlib import Path from typing import Callable from typing import Dict @@ -39,42 +30,15 @@ import lxml.etree as ET -<<<<<<< HEAD -<<<<<<< HEAD -import lxml.etree as ET - -======= ->>>>>>> 8cfbb6f3 (Fix codestyle) from .nyaml2nxdl_helper import NXDL_ATTRIBUTES_ATTRIBUTES from .nyaml2nxdl_helper import NXDL_FIELD_ATTRIBUTES from .nyaml2nxdl_helper import NXDL_GROUP_ATTRIBUTES from .nyaml2nxdl_helper import NXDL_LINK_ATTRIBUTES -<<<<<<< HEAD -======= ->>>>>>> ad17b64e (rebase ...) from .nyaml2nxdl_helper import clean_empty_lines from .nyaml2nxdl_helper import get_node_parent_info from .nyaml2nxdl_helper import get_yaml_escape_char_dict -<<<<<<< HEAD from .nyaml2nxdl_helper import is_dom_comment from .nyaml2nxdl_helper import remove_namespace_from_tag -======= -from .nyaml2nxdl_helper import remove_namespace_from_tag, is_dom_comment -from .nyaml2nxdl_helper import ( - NXDL_FIELD_ATTRIBUTES, - NXDL_GROUP_ATTRIBUTES, - NXDL_ATTRIBUTES_ATTRIBUTES, - NXDL_LINK_ATTRIBUTES, -) - ->>>>>>> 3ef8b382 (Resolving requested changes.) -======= -from .nyaml2nxdl_helper import clean_empty_lines -from .nyaml2nxdl_helper import get_node_parent_info -from .nyaml2nxdl_helper import get_yaml_escape_char_dict -from .nyaml2nxdl_helper import is_dom_comment -from .nyaml2nxdl_helper import remove_namespace_from_tag ->>>>>>> 8cfbb6f3 (Fix codestyle) DEPTH_SIZE = " " CMNT_TAG = "!--" @@ -206,16 +170,6 @@ def __init__( # "Take care of general attributes. Note other choices may be allowed in the future" self.choice_allowed_attr = () - self.optionality_keys = ( - "minOccurs", - "maxOccurs", - "optional", - "recommended", - "required", - ) - # "Take care of general attributes. Note other choices may be allowed in the future" - self.choice_allowed_attr = () - def print_yml(self, input_file, output_yml, verbose): """Parse an XML file provided as input and print a YML file.""" output_file_path = Path(output_yml) @@ -379,6 +333,51 @@ def clean_and_organise_text(self, text, depth): return text + def check_and_handle_doc_xref_and_other_doc(self, text, indent): + """Check for xref doc which comes as a block of text. + + The doc part bellow is the example how xref comes: + ''' + This concept is related to term ``_ of the standard. + .. _: + ''' + converter as + ''' + "xref: + xpec: + erm: + url: " + ''' + + Parameters + ---------- + text: str + plain text. + Returns + ------- + str + return part of doc as formatted + """ + + xref_key, spec_key, term_key, url_key = ("xref", "spec", "term", "url") + spec, term, url = (None, None, None) + matches = re.search( + r"This concept is related to term `([^`]+)`_ of the" + r" ([^\s]+) standard\.\s*\.\. _([^:]+): ([^\s]+)", + text, + ) + if matches: + term = matches.group(1) + spec = matches.group(2) + url = matches.group(4) + indent = indent + DEPTH_SIZE # see example in func doc + return ( + f'{indent}"{xref_key}:\n{indent + DEPTH_SIZE}{spec_key}: {spec}' + f"\n{indent + DEPTH_SIZE}{term_key}" + f': {term}\n{indent + DEPTH_SIZE}{url_key}: {url}"' + ) + return text + # pylint: disable=too-many-branches def handle_not_root_level_doc(self, depth, text, tag="doc", file_out=None): """Handle docs field of group and field but not root. @@ -388,13 +387,39 @@ def handle_not_root_level_doc(self, depth, text, tag="doc", file_out=None): * Topic name Description of topic """ - - text = self.clean_and_organise_text(text, depth) if "}" in tag: tag = remove_namespace_from_tag(tag) indent = depth * DEPTH_SIZE + text = self.clean_and_organise_text(text, depth) # starts with '\n' + docs = re.split(r"\n\s*\n", text) + modified_docs = [] + for doc_part in docs: + if not doc_part.isspace(): + modified_docs.append( + self.check_and_handle_doc_xref_and_other_doc(doc_part, indent) + ) + # doc example: + # doc: + # - | + # text + # - | + # xref: + # spec: + # term: + if len(modified_docs) > 1: + doc_str = f"{indent}{tag}:\n" + for mod_doc in modified_docs: + if not re.match( + r"^\s*\n", mod_doc + ): # if not starts with 'spaces and/or \n' + mod_doc = "\n" + mod_doc + # doc_str = f"{doc_str}{indent} - |\n{textwrap.indent(mod_doc, indent+' ')}\n" + doc_str = f"{doc_str}{indent} - |{textwrap.indent(mod_doc, '')}\n" + elif len(modified_docs) == 1: + doc_str = f"{indent}{tag}: |{modified_docs[0]}\n" + else: + doc_str = f"{indent}{tag}: |{text}\n" - doc_str = f"{indent}{tag}: |{text}\n" if file_out: file_out.write(doc_str) return None @@ -425,10 +450,7 @@ def convert_to_yaml_comment(self, depth, text): """ # To store indentation text from comment lines = self.clean_and_organise_text(text, depth).split("\n") -<<<<<<< HEAD indent = DEPTH_SIZE * depth -======= ->>>>>>> 3ef8b382 (Resolving requested changes.) mod_lines = [] for line in lines: line = line.strip() diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py b/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py index e8cee49cd0..fe50de62c0 100644 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py +++ b/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py @@ -23,8 +23,10 @@ import datetime import pathlib +import re import textwrap import warnings +from typing import Union from urllib.parse import unquote import lxml.etree as ET @@ -129,7 +131,9 @@ def yml_reader(inputfile): def check_for_default_attribute_and_value(xml_element): - """NeXus Groups, fields and attributes might have xml default attributes and values that must + """Check for default attribute for NeXus concepts. + + NeXus Groups, fields and attributes might have xml default attributes and values that must come. For example: 'optional' which is 'true' by default for base class and false otherwise. """ @@ -253,13 +257,70 @@ def check_for_mapping_char_other(text): return text.strip() -def xml_handle_doc(obj, value: str, line_number=None, line_loc=None): +def handle_each_part_doc(text): + """Check and handle if the text is corresponds to xref or plain doc. + + In nyaml doc the entire documentation may come in list of small docs. + one doc string might be as follows: + ''' + xref: + spec: + term: + url: + ''' + + which has to be formatted as + ''' + This concept is related to term ``_ of the standard. + .. _: + + + Parameters + ---------- + text : string + String that looks like yaml notaion. + + return + ------ + Formated text + """ + if re.match(r"^\s*\"", text): + text = text.split('"', 1)[-1] + if re.search(r"\"[^\n\s]*$", text): + text = text.rsplit('"', 1)[0] + + search_keys = ("xref:", "spec:", "term:", "url:") + spec, term, url = ("NO SPECIFICATION", "NO TERM", "NO URL") + # Check with the signiture keys + if all(key in text for key in search_keys): + lines = text.split("\n") + if len(lines) > 0: + # key combination could be in any order + for line in lines: + if search_keys[1] in line: # spec + spec = line.split(search_keys[1])[-1].strip() + elif search_keys[2] in line: # term + term = line.split(search_keys[2])[-1].strip() + elif search_keys[3] in line: # url + url = line.split(search_keys[3])[-1].strip() + return f""" This concept is related to term `{term}`_ of the {spec} standard. +.. _{term}: {url}""" + else: + return format_nxdl_doc(check_for_mapping_char_other(text)).strip() + + +def xml_handle_doc(obj, value: Union[str, list], line_number=None, line_loc=None): """This function creates a 'doc' element instance, and appends it to an existing element""" # global comment_bolcks doc_elemt = ET.SubElement(obj, "doc") - text = format_nxdl_doc(check_for_mapping_char_other(value)).strip() + text = "" + if isinstance(value, list): + for doc_part in value: + text = text + "\n" + handle_each_part_doc(doc_part) + "\n" + else: + text = text + "\n" + handle_each_part_doc(value) + "\n" # To keep the doc middle of doc tag. - doc_elemt.text = f"\n{text}\n" + doc_elemt.text = text if line_loc is not None and line_number is not None: xml_handle_comment(obj, line_number, line_loc, doc_elemt) @@ -895,7 +956,6 @@ def xml_handle_comment( def recursive_build(obj, dct, verbose): """Walk through nested dictionary. - Parameters: ----------- obj : ET.Element @@ -1013,7 +1073,7 @@ def pretty_print_xml(xml_root, output_xml, def_comments=None): with open(tmp_xml, "r", encoding="utf-8") as file_out: with open(output_xml, "w", encoding="utf-8") as file_out_mod: for i in file_out.readlines(): - i = unquote(i.encode()) + i = unquote(i) if "" not in i and "" not in i and flag is False: file_out_mod.write(i) elif "" in i and "" in i: diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl_helper.py b/dev_tools/nyaml2nxdl/nyaml2nxdl_helper.py index ea41dd910f..7587df1de1 100644 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl_helper.py +++ b/dev_tools/nyaml2nxdl/nyaml2nxdl_helper.py @@ -270,6 +270,7 @@ def separate_hash_yaml_and_nxdl(yaml_file, sep_yaml, sep_xml): sep_xml, "w", encoding="utf-8" ) as xml_f_ob: write_on_yaml = True + last_line = lines[0] for line in lines[1:]: # Write in file when ensured that the next line is not with '++ SHA HASH ++' diff --git a/dev_tools/tests/data/doc_nxdl2yaml.nxdl.xml b/dev_tools/tests/data/doc_nxdl2yaml.nxdl.xml new file mode 100644 index 0000000000..ad75b96ea8 --- /dev/null +++ b/dev_tools/tests/data/doc_nxdl2yaml.nxdl.xml @@ -0,0 +1,72 @@ + + + + + + This is a definition for data to be archived by ICAT (http://www.icatproject.org/). + + .. text from the icatproject.org site + + the database (with supporting software) that provides an + interface to all ISIS experimental data and will provide + a mechanism to link all aspects of ISIS research from + proposal through to publication. + + + + + + + unique identifier for the experimenta + lkokö + sddfdfd + + This concept is related to term `term`_ of the spec standard. + .. _term: url + + This is test doc. + + + + + Part1: Text line 1. + part1: Text line 2 + + This concept is related to term `term`_ of the spec standard. + .. _term: url + + + + + ID of user or DAQ define group of data files + Brief summary of the collection, including grouping criteria + + + + + unique identifier for this measurement as provided by the facility + + + + + diff --git a/dev_tools/tests/data/doc_yaml2nxdl.yaml b/dev_tools/tests/data/doc_yaml2nxdl.yaml new file mode 100644 index 0000000000..df25dbb91b --- /dev/null +++ b/dev_tools/tests/data/doc_yaml2nxdl.yaml @@ -0,0 +1,48 @@ +category: application +doc: | + This is a definition for data to be archived by ICAT (http://www.icatproject.org/). + + .. text from the icatproject.org site + + the database (with supporting software) that provides an + interface to all ISIS experimental data and will provide + a mechanism to link all aspects of ISIS research from + proposal through to publication. +type: group +NXarchive(NXobject): + (NXentry)entry: + \@index: + title: + experiment_identifier(NX_CHAR): + doc: + - | + "unique identifier for the experimenta + lkokö + sddfdfd" + - | + "xref: + spec: spec + term: term + url: url" + - | + "This is test doc." + experiment_description(NX_CHAR): + doc: + - | + Part1: Text line 1. + part1: Text line 2 + + - | + xref: + spec: spec + term: term + url: url" + + collection_identifier(NX_CHAR): + doc: | + ID of user or DAQ define group of data files + Brief summary of the collection, including grouping criteria + entry_identifier(NX_CHAR): + doc: | + unique identifier for this measurement as provided by the facility + start_time(NX_DATE_TIME): diff --git a/dev_tools/tests/data/ref_doc_nxdl2yaml.yaml b/dev_tools/tests/data/ref_doc_nxdl2yaml.yaml new file mode 100644 index 0000000000..75e867198a --- /dev/null +++ b/dev_tools/tests/data/ref_doc_nxdl2yaml.yaml @@ -0,0 +1,47 @@ +category: application +doc: + - | + This is a definition for data to be archived by ICAT (http://www.icatproject.org/). + - | + .. text from the icatproject.org site + - | + the database (with supporting software) that provides an + interface to all ISIS experimental data and will provide + a mechanism to link all aspects of ISIS research from + proposal through to publication. +type: group +NXarchive(NXobject): + (NXentry)entry: + \@index: + title: + experiment_identifier(NX_CHAR): + doc: + - | + unique identifier for the experimenta + lkokö + sddfdfd + - | + "xref: + spec: spec + term: term + url: url" + - | + This is test doc. + experiment_description(NX_CHAR): + doc: + - | + Part1: Text line 1. + part1: Text line 2 + - | + "xref: + spec: spec + term: term + url: url" + collection_identifier(NX_CHAR): + doc: | + ID of user or DAQ define group of data files + Brief summary of the collection, including grouping criteria + entry_identifier(NX_CHAR): + doc: | + unique identifier for this measurement as provided by the facility + start_time(NX_DATE_TIME): diff --git a/dev_tools/tests/data/ref_doc_yaml2nxdl.nxdl.xml b/dev_tools/tests/data/ref_doc_yaml2nxdl.nxdl.xml new file mode 100644 index 0000000000..ad75b96ea8 --- /dev/null +++ b/dev_tools/tests/data/ref_doc_yaml2nxdl.nxdl.xml @@ -0,0 +1,72 @@ + + + + + + This is a definition for data to be archived by ICAT (http://www.icatproject.org/). + + .. text from the icatproject.org site + + the database (with supporting software) that provides an + interface to all ISIS experimental data and will provide + a mechanism to link all aspects of ISIS research from + proposal through to publication. + + + + + + + unique identifier for the experimenta + lkokö + sddfdfd + + This concept is related to term `term`_ of the spec standard. + .. _term: url + + This is test doc. + + + + + Part1: Text line 1. + part1: Text line 2 + + This concept is related to term `term`_ of the spec standard. + .. _term: url + + + + + ID of user or DAQ define group of data files + Brief summary of the collection, including grouping criteria + + + + + unique identifier for this measurement as provided by the facility + + + + + diff --git a/dev_tools/tests/test_nyaml2nxdl.py b/dev_tools/tests/test_nyaml2nxdl.py index 2c95f1351c..a056487e2d 100755 --- a/dev_tools/tests/test_nyaml2nxdl.py +++ b/dev_tools/tests/test_nyaml2nxdl.py @@ -1,9 +1,11 @@ -import os from pathlib import Path +import lxml.etree as ET from click.testing import CliRunner from ..nyaml2nxdl import nyaml2nxdl as conv +from ..nyaml2nxdl.nyaml2nxdl_helper import LineLoader +from ..nyaml2nxdl.nyaml2nxdl_helper import remove_namespace_from_tag from ..utils.nxdl_utils import find_definition_file @@ -12,12 +14,7 @@ def test_conversion(): result = CliRunner().invoke(conv.launch_tool, ["--input-file", root]) assert result.exit_code == 0 # Replace suffixes -<<<<<<< HEAD yaml = root.parent / Path(root.with_suffix("").stem + "_parsed.yaml") -======= - yaml = root.with_suffix("").with_suffix(".yaml") - yaml = yaml.with_stem(yaml.stem + "_parsed") ->>>>>>> 8cfbb6f3 (Fix codestyle) result = CliRunner().invoke(conv.launch_tool, ["--input-file", yaml]) assert result.exit_code == 0 new_root = yaml.with_suffix(".nxdl.xml") @@ -26,5 +23,72 @@ def test_conversion(): with open(new_root, encoding="utf-8", mode="r") as tmp_f: new_root_content = tmp_f.readlines() assert root_content == new_root_content - os.remove(yaml) - os.remove(new_root) + Path.unlink(yaml) + Path.unlink(new_root) + + +def test_yaml2nxdl_doc(): + """To test the doc style from yaml to nxdl.""" + pwd = Path(__file__).parent + + doc_file = pwd / "data/doc_yaml2nxdl.yaml" + ref_doc_file = pwd / "data/ref_doc_yaml2nxdl.nxdl.xml" + out_doc_file = ( + pwd / "data/doc_yaml2nxdl.nxdl.xml" + ) # doc_file.with_suffix('.nxdl.xml') + # Test yaml2nxdl + # Generates '../data/doc_text.nxdl.xml' + result = CliRunner().invoke(conv.launch_tool, ["--input-file", str(doc_file)]) + + assert result.exit_code == 0, f"Error: Having issue running input file {doc_file}." + + ref_nxdl = ET.parse(str(ref_doc_file)).getroot() + out_nxdl = ET.parse(str(out_doc_file)).getroot() + + def compare_nxdl_doc(parent1, parent2): + if len(parent1) > 0 and len(parent2) > 0: + for par1, par2 in zip(parent1, parent2): + compare_nxdl_doc(par1, par2) + + elif ( + remove_namespace_from_tag(parent1.tag) == "doc" + and remove_namespace_from_tag(parent2.tag) == "doc" + ): + assert ( + parent1.text == parent2.text + ), f"DOCS ARE NOT SAME: node {parent1}, node {parent2}" + + compare_nxdl_doc(ref_nxdl, out_nxdl) + + Path.unlink(out_doc_file) + + +def test_nxdl2yaml_doc(): + """To test the doc style from nxdl to yaml.""" + + pwd = Path(__file__).parent + nxdl_file = pwd / "data/doc_nxdl2yaml.nxdl.xml" + ref_yaml = pwd / "data/ref_doc_nxdl2yaml.yaml" + parsed_yaml_file = pwd / "data/doc_nxdl2yaml_parsed.yaml" + + result = CliRunner().invoke( + conv.launch_tool, ["--input-file", str(nxdl_file), "--do-not-store-nxdl"] + ) + assert result.exit_code == 0, "Error in converter execuation." + with open(ref_yaml, mode="r", encoding="utf-8") as yaml1, open( + parsed_yaml_file, mode="r", encoding="utf-8" + ) as yaml2: + yaml_dict1 = LineLoader(yaml1).get_single_data() + yaml_dict2 = LineLoader(yaml2).get_single_data() + + def compare_yaml_doc(yaml_dict1, yaml_dict2): + for k_val1, k_val2 in zip(yaml_dict1.items(), yaml_dict2.items()): + key1, val1 = k_val1 + key2, val2 = k_val2 + if key1 == "doc" and key2 == "doc": + assert val1 == val2, "Doc text was not produced properly." + elif isinstance(val1, dict) and isinstance(val2, dict): + compare_yaml_doc(val1, val2) + + compare_yaml_doc(yaml_dict1, yaml_dict2) + Path.unlink(parsed_yaml_file) diff --git a/dev_tools/utils/nxdl_utils.py b/dev_tools/utils/nxdl_utils.py index b9ef629c9a..5c6d3db458 100644 --- a/dev_tools/utils/nxdl_utils.py +++ b/dev_tools/utils/nxdl_utils.py @@ -4,15 +4,6 @@ import os import textwrap -<<<<<<< HEAD -<<<<<<< HEAD -======= -import lxml.etree as ET -from lxml.etree import ParseError as xmlER -from ..nyaml2nxdl.nyaml2nxdl_helper import remove_namespace_from_tag ->>>>>>> 3ef8b382 (Resolving requested changes.) -======= ->>>>>>> 8cfbb6f3 (Fix codestyle) from functools import lru_cache from glob import glob from pathlib import Path @@ -27,10 +18,6 @@ class NxdlAttributeNotFoundError(Exception): """An exception to throw when an Nxdl attribute is not found.""" -<<<<<<< HEAD -<<<<<<< HEAD -======= -======= def get_nexus_definitions_path(): """Check NEXUS_DEF_PATH variable. If it is empty, this function is filling it""" @@ -45,11 +32,7 @@ def get_nexus_definitions_path(): nexus_def_path = get_nexus_definitions_path() -<<<<<<< HEAD ->>>>>>> 3ef8b382 (Resolving requested changes.) -======= ->>>>>>> 8cfbb6f3 (Fix codestyle) def get_app_defs_names(): """Returns all the AppDef names without their extension: .nxdl.xml""" app_def_path_glob = nexus_def_path / "applications" / "*.nxdl*" @@ -72,47 +55,6 @@ def get_xml_root(file_path): return ET.parse(file_path).getroot() -<<<<<<< HEAD ->>>>>>> 9866fa5f (Addresses comments in nxdl_utils) -def get_nexus_definitions_path(): - """Check NEXUS_DEF_PATH variable. - If it is empty, this function is filling it""" - try: # either given by sys env - return os.environ["NEXUS_DEF_PATH"] - except KeyError: # or it should be available locally under the dir 'definitions' - local_dir = Path(__file__).resolve().parent - for _ in range(2): - local_dir = local_dir.parent - return local_dir - - -nexus_def_path = get_nexus_definitions_path() - - -def get_app_defs_names(): - """Returns all the AppDef names without their extension: .nxdl.xml""" - app_def_path_glob = nexus_def_path / "applications" / "*.nxdl*" - - contrib_def_path_glob = Path(nexus_def_path) / "contributed_definitions" / "*.nxdl*" - - files = sorted(glob(app_def_path_glob)) - for nexus_file in sorted(contrib_def_path_glob): - root = get_xml_root(nexus_file) - if root.attrib["category"] == "application": - files.append(nexus_file) - - return [Path(file).stem for file in files] + ["NXroot"] - - -@lru_cache(maxsize=None) -def get_xml_root(file_path): - """Reducing I/O time by caching technique""" - - return ET.parse(file_path).getroot() - - -======= ->>>>>>> 3ef8b382 (Resolving requested changes.) def get_hdf_root(hdf_node): """Get the root HDF5 node""" node = hdf_node @@ -201,15 +143,7 @@ def get_nx_classes(): except xmlER as e: raise ValueError(f"Getting an issue while parsing file {nexus_file}") from e if root.attrib["category"] == "base": -<<<<<<< HEAD -<<<<<<< HEAD - nx_class.append(nexus_file.stem) -======= - nx_class.append(os.path.basename(nexus_file).split(".")[0]) ->>>>>>> 9866fa5f (Addresses comments in nxdl_utils) -======= nx_class.append(nexus_file.stem) ->>>>>>> 3ef8b382 (Resolving requested changes.) return sorted(nx_class) @@ -319,46 +253,17 @@ def belongs_to_capital(params): def get_local_name_from_xml(element): """Helper function to extract the element tag without the namespace.""" -<<<<<<< HEAD -<<<<<<< HEAD - return remove_namespace_from_tag(element.tag) -======= - return element.tag.rsplit("}")[-1] ->>>>>>> 9866fa5f (Addresses comments in nxdl_utils) -======= return remove_namespace_from_tag(element.tag) ->>>>>>> 3ef8b382 (Resolving requested changes.) def get_own_nxdl_child_reserved_elements(child, name, nxdl_elem): """checking reserved elements, like doc, enumeration""" local_name = get_local_name_from_xml(child) if local_name == "doc" and name == "doc": -<<<<<<< HEAD -<<<<<<< HEAD return set_nxdlpath(child, nxdl_elem, tag_name=name) if local_name == "enumeration" and name == "enumeration": return set_nxdlpath(child, nxdl_elem, tag_name=name) -======= - if nxdl_elem.get("nxdlbase"): - child.set("nxdlbase", nxdl_elem.get("nxdlbase")) - child.set("nxdlbase_class", nxdl_elem.get("nxdlbase_class")) - child.set("nxdlpath", nxdl_elem.get("nxdlpath") + "/doc") - return child - if local_name == "enumeration" and name == "enumeration": - if nxdl_elem.get("nxdlbase"): - child.set("nxdlbase", nxdl_elem.get("nxdlbase")) - child.set("nxdlbase_class", nxdl_elem.get("nxdlbase_class")) - child.set("nxdlpath", nxdl_elem.get("nxdlpath") + "/enumeration") - return child ->>>>>>> 9866fa5f (Addresses comments in nxdl_utils) -======= - return set_nxdlpath(child, nxdl_elem, tag_name=name) - - if local_name == "enumeration" and name == "enumeration": - return set_nxdlpath(child, nxdl_elem, tag_name=name) ->>>>>>> 3ef8b382 (Resolving requested changes.) return False @@ -376,18 +281,6 @@ def get_own_nxdl_child_base_types(child, class_type, nxdl_elem, name, hdf_name): if get_local_name_from_xml(child) == "attribute" and belongs_to( nxdl_elem, child, name, None, hdf_name ): -<<<<<<< HEAD -<<<<<<< HEAD -======= - if nxdl_elem.get("nxdlbase"): - child.set("nxdlbase", nxdl_elem.get("nxdlbase")) - child.set("nxdlbase_class", nxdl_elem.get("nxdlbase_class")) - child.set( - "nxdlpath", nxdl_elem.get("nxdlpath") + "/" + get_node_name(child) - ) ->>>>>>> 9866fa5f (Addresses comments in nxdl_utils) -======= ->>>>>>> 3ef8b382 (Resolving requested changes.) return set_nxdlpath(child, nxdl_elem) return False @@ -700,15 +593,7 @@ def get_enums(node): def add_base_classes(elist, nx_name=None, elem: ET.Element = None): """ -<<<<<<< HEAD -<<<<<<< HEAD - Add the base classes corresponding to the last element in elist to the list. Note that if -======= - Add the base classes corresponding to the last elemenent in elist to the list. Note that if ->>>>>>> 9866fa5f (Addresses comments in nxdl_utils) -======= Add the base classes corresponding to the last element in elist to the list. Note that if ->>>>>>> 3ef8b382 (Resolving requested changes.) elist is empty, a nxdl file with the name of nx_name or a placeholder elem is used if provided """ if elist and nx_name is None: @@ -727,15 +612,7 @@ def add_base_classes(elist, nx_name=None, elem: ET.Element = None): elem = ET.parse(os.path.abspath(nxdl_file_path)).getroot() # elem = ET.parse(nxdl_file_path).getroot() except OSError: -<<<<<<< HEAD -<<<<<<< HEAD - with open(nxdl_file_path, "r") as f: -======= - with open(nxdl_file_path, 'r') as f: ->>>>>>> 3ef8b382 (Resolving requested changes.) -======= with open(nxdl_file_path, "r") as f: ->>>>>>> 8cfbb6f3 (Fix codestyle) elem = ET.parse(f).getroot() if not isinstance(nxdl_file_path, str): From f33b868e2d21364151dcfb00468cea2ae235c054 Mon Sep 17 00:00:00 2001 From: Rubel Date: Thu, 9 Nov 2023 20:02:30 +0100 Subject: [PATCH 0353/1012] PR comment resolve. --- Makefile | 2 +- dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py | 6 +++--- dev_tools/tests/test_nyaml2nxdl.py | 10 ++++++++-- 3 files changed, 12 insertions(+), 6 deletions(-) diff --git a/Makefile b/Makefile index ee24b8c7a4..37aa544f5d 100644 --- a/Makefile +++ b/Makefile @@ -139,4 +139,4 @@ nxdl: $(NXDL_APPDEF) $(NXDL_CONTRIB) $(NXDL_BC) # License along with this library; if not, write to the Free Software # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA # -# For further information, see http://www.nexusformat.org \ No newline at end of file +# For further information, see http://www.nexusformat.org diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py b/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py index 314c565ad0..0150466e0f 100755 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py +++ b/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py @@ -362,14 +362,14 @@ def check_and_handle_doc_xref_and_other_doc(self, text, indent): xref_key, spec_key, term_key, url_key = ("xref", "spec", "term", "url") spec, term, url = (None, None, None) matches = re.search( - r"This concept is related to term `([^`]+)`_ of the" - r" ([^\s]+) standard\.\s*\.\. _([^:]+): ([^\s]+)", + r"This concept is related to term `([^`:]+)`_ of the" + r" ([^\s]+) standard\.\s+\.\. _\1: ([^\s]+)", text, ) if matches: term = matches.group(1) spec = matches.group(2) - url = matches.group(4) + url = matches.group(3) indent = indent + DEPTH_SIZE # see example in func doc return ( f'{indent}"{xref_key}:\n{indent + DEPTH_SIZE}{spec_key}: {spec}' diff --git a/dev_tools/tests/test_nyaml2nxdl.py b/dev_tools/tests/test_nyaml2nxdl.py index a056487e2d..ce7bdc064a 100755 --- a/dev_tools/tests/test_nyaml2nxdl.py +++ b/dev_tools/tests/test_nyaml2nxdl.py @@ -39,7 +39,8 @@ def test_yaml2nxdl_doc(): # Test yaml2nxdl # Generates '../data/doc_text.nxdl.xml' result = CliRunner().invoke(conv.launch_tool, ["--input-file", str(doc_file)]) - + if result.exit_code != 0: + Path.unlink(out_doc_file) assert result.exit_code == 0, f"Error: Having issue running input file {doc_file}." ref_nxdl = ET.parse(str(ref_doc_file)).getroot() @@ -74,7 +75,12 @@ def test_nxdl2yaml_doc(): result = CliRunner().invoke( conv.launch_tool, ["--input-file", str(nxdl_file), "--do-not-store-nxdl"] ) + + if result.exit_code != 0: + Path.unlink(parsed_yaml_file) + assert result.exit_code == 0, "Error in converter execuation." + with open(ref_yaml, mode="r", encoding="utf-8") as yaml1, open( parsed_yaml_file, mode="r", encoding="utf-8" ) as yaml2: @@ -86,7 +92,7 @@ def compare_yaml_doc(yaml_dict1, yaml_dict2): key1, val1 = k_val1 key2, val2 = k_val2 if key1 == "doc" and key2 == "doc": - assert val1 == val2, "Doc text was not produced properly." + assert val1 == val2, "Doc texts are not the same." elif isinstance(val1, dict) and isinstance(val2, dict): compare_yaml_doc(val1, val2) From 101d1df8ab19e1e9bebd9b6d54ae785c19cd2bf5 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 10 Nov 2023 10:20:13 +0100 Subject: [PATCH 0354/1012] update mpes-structure.rst --- manual/source/mpes-structure.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/manual/source/mpes-structure.rst b/manual/source/mpes-structure.rst index dc0e4a75db..a251bdc097 100644 --- a/manual/source/mpes-structure.rst +++ b/manual/source/mpes-structure.rst @@ -4,14 +4,14 @@ Photoemission & core-level spectroscopy ======================================= -The NXmpes application definition aims at describing any possible multidimensional PES setup. +The NXmpes application definition aims at describing data and metadata obtained with any possible multidimensional PES setup. Hence, it is very general and currently the only limitation to the data is that an energy axis has to be present. The general experimental techniques described by this application definitions are photons in and photoelectrons out. If you want NXmpes for such a techniques, changes are good you find something useful here. -An example set of techniques covered by this application defintions are x-ray/UV photoelectron spectroscopy (XPS/UPS), +Example techniques covered by this application definition include x-ray/UV photoelectron spectroscopy (XPS/UPS), angle-resolved photoemission spectroscopy (ARPES), two-photon photoemission (2PPE) or photoemission electron microscopy (PEEM). We also include descriptors for advanced specializations, such as spin- and time-resolution, near-ambient pressure conditions, From 4f88fa94adcea90fcfd8c24239570387e34d78d9 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 10 Nov 2023 10:25:54 +0100 Subject: [PATCH 0355/1012] Add depends on in NXenergydispersion --- .../NXenergydispersion.nxdl.xml | 175 +++++++++--------- .../nyaml/NXenergydispersion.yaml | 1 + 2 files changed, 89 insertions(+), 87 deletions(-) diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml index 2624251597..72062faf59 100644 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ b/contributed_definitions/NXenergydispersion.nxdl.xml @@ -1,9 +1,9 @@ - + + + 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. + Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, + mirror, retarding grid, etc. - - - Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, - mirror, retarding grid, etc. - - - - - Energy of the electrons on the mean path of the analyser. Pass energy for - hemispherics, drift energy for tofs. - - Refers to Term `12.63`_ of the ISO 18115-1:2023 specification. - - .. _12.63: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.63 - - - - - Center of the energy window - - - - - The interval of transmitted energies. It can be two different things depending - on whether the scan is fixed or swept. With a fixed scan it is a 2 vector - containing the extrema of the transmitted energy window (smaller number first). - With a swept scan of m steps it is a 2xm array of windows one for each - measurement point. - - - - - Size, position and shape of a slit in dispersive analyzer, e.g. entrance and - exit slits. - - - - - Diameter of the dispersive orbit - - - - - Way of scanning the energy axis (fixed or sweep). - - Refers to Terms `12.65`_ and `12.66`_ of the ISO 18115-1:2023 specification. - - .. _12.65: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.65 - .. _12.66: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.66 - - - - - - - - - Length of the tof drift electrode - - - - - Deflectors in the energy dispersive section - - - - - Individual lenses in the energy dispersive section - - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the energy dispersive element as a component in the instrument. - Conventions from the NXtransformations base class are used. In principle, - the McStas coordinate system is used. The first transformation has to point - either to another component of the system or . (for pointing to the reference frame) - to relate it relative to the experimental setup. Typically, the components of a system - should all be related relative to each other and only one component should relate to - the reference coordinate system. - - + + + + Energy of the electrons on the mean path of the analyser. Pass energy for + hemispherics, drift energy for tofs. + + Refers to Term `12.63`_ of the ISO 18115-1:2023 specification. + + .. _12.63: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.63 + + + + + Center of the energy window + + + + + The interval of transmitted energies. It can be two different things depending + on whether the scan is fixed or swept. With a fixed scan it is a 2 vector + containing the extrema of the transmitted energy window (smaller number first). + With a swept scan of m steps it is a 2xm array of windows one for each + measurement point. + + + + + Size, position and shape of a slit in dispersive analyzer, e.g. entrance and + exit slits. + + + + + Diameter of the dispersive orbit + + + + + Way of scanning the energy axis (fixed or sweep). + + Refers to Terms `12.65`_ and `12.66`_ of the ISO 18115-1:2023 specification. + + .. _12.65: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.65 + .. _12.66: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.66 + + + + + + + + + Length of the tof drift electrode + + + + + Deflectors in the energy dispersive section + + + + + Individual lenses in the energy dispersive section + + + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the energy dispersive element as a component in the instrument. + Conventions from the NXtransformations base class are used. In principle, + the McStas coordinate system is used. The first transformation has to point + either to another component of the system or . (for pointing to the reference frame) + to relate it relative to the experimental setup. Typically, the components of a system + should all be related relative to each other and only one component should relate to + the reference coordinate system. + + diff --git a/contributed_definitions/nyaml/NXenergydispersion.yaml b/contributed_definitions/nyaml/NXenergydispersion.yaml index e97e9f0721..cfd5cc9e60 100644 --- a/contributed_definitions/nyaml/NXenergydispersion.yaml +++ b/contributed_definitions/nyaml/NXenergydispersion.yaml @@ -57,6 +57,7 @@ NXenergydispersion(NXobject): doc: | Individual lenses in the energy dispersive section (NXfabrication): + depends_on(NX_CHAR): (NXtransformations): doc: | Collection of axis-based translations and rotations to describe the location and From 191749c5f6ea2f1dcf05c0f5d738d8b868918610 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 10 Nov 2023 10:55:39 +0100 Subject: [PATCH 0356/1012] Update manual/source/mpes-structure.rst Co-authored-by: Florian Dobener --- manual/source/mpes-structure.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/manual/source/mpes-structure.rst b/manual/source/mpes-structure.rst index a251bdc097..809dd34018 100644 --- a/manual/source/mpes-structure.rst +++ b/manual/source/mpes-structure.rst @@ -8,7 +8,7 @@ The NXmpes application definition aims at describing data and metadata obtained Hence, it is very general and currently the only limitation to the data is that an energy axis has to be present. The general experimental techniques described by this application definitions are -photons in and photoelectrons out. +photon-in and photoelectron-out. If you want NXmpes for such a techniques, changes are good you find something useful here. Example techniques covered by this application definition include x-ray/UV photoelectron spectroscopy (XPS/UPS), From 15624c0be77be13aceac64025bd09b742be5e412 Mon Sep 17 00:00:00 2001 From: RubelMozumder <32923026+RubelMozumder@users.noreply.github.com> Date: Fri, 10 Nov 2023 17:28:56 +0100 Subject: [PATCH 0357/1012] Resolving xref issue 115-nyaml2nxdl-xref-edge-cases (#116) * Resolving xref issue 115-nyaml2nxdl-xref-edge-cases * Suggestion for new xref function * Remove unused re * Adds test for xref handling * Use strip short notation * Adds tests for invalid xref * update nyaml2nxdl readme * Add edge cases for xref * Re-introduce removal of starting " * Remove unused import * Remove support for " in xref docstring --------- Co-authored-by: domna Co-authored-by: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> --- dev_tools/nyaml2nxdl/README.md | 41 +++++---- .../nyaml2nxdl/nyaml2nxdl_backward_tools.py | 2 +- .../nyaml2nxdl/nyaml2nxdl_forward_tools.py | 58 +++++++------ dev_tools/tests/data/doc_nxdl2yaml.nxdl.xml | 4 +- dev_tools/tests/data/doc_yaml2nxdl.yaml | 16 ++-- dev_tools/tests/data/ref_doc_nxdl2yaml.yaml | 6 +- .../tests/data/ref_doc_yaml2nxdl.nxdl.xml | 10 +-- dev_tools/tests/test_nyaml2nxdl.py | 85 +++++++++++++++++++ 8 files changed, 162 insertions(+), 60 deletions(-) diff --git a/dev_tools/nyaml2nxdl/README.md b/dev_tools/nyaml2nxdl/README.md index da1b93d923..51d9c2d862 100644 --- a/dev_tools/nyaml2nxdl/README.md +++ b/dev_tools/nyaml2nxdl/README.md @@ -43,7 +43,7 @@ Options: * And attributes of either groups or fields. The mark '\@' have to precede the name of attributes. * Optionality: For all fields, groups and attributes in `application definitions` are `required` by default, except anything (`recommended` or `optional`) mentioned. -**Special keywords**: Several keywords can be used as childs of groups, fields, and attributes to specify the members of these. Groups, fields and attributes are nodes of the XML tree. +**Special keywords**: Several keywords can be used as children of groups, fields, and attributes to specify the members of these. Groups, fields and attributes are nodes of the XML tree. * **doc**: - A human-readable description/docstring - Doc string may also come as a list of doc parts when user wants to add `reference` for a concept. Or doc string could be a single doc block. @@ -51,33 +51,40 @@ Options: energy: # field doc: - | - Part1 of the entire doc. - part1 of the entire doc. + Part1 of the entire doc. + part1 of the entire doc. - | # Reference for concept - "xref: - spec: - term: - url: " + xref: + spec: + term: + url: " - | - Rest of the doc - rest of the doc + Rest of the doc + rest of the doc velocity: # field doc: | A single block of doc string. ``` - Such structure of doc would be appreared in `nxdl` as + Such structure of doc would appear in `nxdl` as ```xml ... - + + Part1 of the entire doc. part1 of the entire doc. - - This concept is related to term ``_ of the standard. - .. : . - Rest of the doc. - rest of the doc. - + This concept is related to term `<term>`_ of the <spec> standard. + .. _<term>: <url> + + Rest of the doc + rest of the doc + + + + + A single block of doc string. + + ``` diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py b/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py index 0150466e0f..dfae600e15 100755 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py +++ b/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py @@ -363,7 +363,7 @@ def check_and_handle_doc_xref_and_other_doc(self, text, indent): spec, term, url = (None, None, None) matches = re.search( r"This concept is related to term `([^`:]+)`_ of the" - r" ([^\s]+) standard\.\s+\.\. _\1: ([^\s]+)", + r" (.*?) standard\.\s+\.\. _\1: ([^\s]+)", text, ) if matches: diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py b/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py index fe50de62c0..fa78b82929 100644 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py +++ b/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py @@ -23,7 +23,6 @@ import datetime import pathlib -import re import textwrap import warnings from typing import Union @@ -31,6 +30,7 @@ import lxml.etree as ET import yaml +from yaml.scanner import ScannerError from ..utils import nxdl_utils as pynxtools_nxlib from .comment_collector import CommentCollector @@ -284,29 +284,39 @@ def handle_each_part_doc(text): ------ Formated text """ - if re.match(r"^\s*\"", text): - text = text.split('"', 1)[-1] - if re.search(r"\"[^\n\s]*$", text): - text = text.rsplit('"', 1)[0] - - search_keys = ("xref:", "spec:", "term:", "url:") - spec, term, url = ("NO SPECIFICATION", "NO TERM", "NO URL") - # Check with the signiture keys - if all(key in text for key in search_keys): - lines = text.split("\n") - if len(lines) > 0: - # key combination could be in any order - for line in lines: - if search_keys[1] in line: # spec - spec = line.split(search_keys[1])[-1].strip() - elif search_keys[2] in line: # term - term = line.split(search_keys[2])[-1].strip() - elif search_keys[3] in line: # url - url = line.split(search_keys[3])[-1].strip() - return f""" This concept is related to term `{term}`_ of the {spec} standard. -.. _{term}: {url}""" - else: - return format_nxdl_doc(check_for_mapping_char_other(text)).strip() + + clean_txt = text.strip() + + if not clean_txt.startswith("xref:"): + return format_nxdl_doc(check_for_mapping_char_other(clean_txt)).strip() + + no_lines = len(clean_txt.splitlines()) + try: + xref_dict = yaml.safe_load(clean_txt) + except ScannerError as scan_err: + raise ValueError( + "Found invalid xref. Please make sure that your xref entries are valid yaml." + ) from scan_err + xref_entries = xref_dict.get("xref", {}) + + if no_lines != len(xref_entries) + 1: + raise ValueError("Invalid xref. It contains nested or duplicate keys.") + + if no_lines > 4: + raise ValueError("Invalid xref. Too many keys.") + + for key in xref_entries: + if key not in ("term", "spec", "url"): + raise ValueError( + f"Invalid xref key `{key}`. Must be one of `term`, `spec` or `url`." + ) + + return ( + f" This concept is related to term `{xref_entries.get('term', 'NO TERM')}`_ " + f"of the {xref_entries.get('spec', 'NO TERM')} standard.\n" + f".. _{xref_entries.get('term', 'NO SPECIFICATION')}: " + f"{xref_entries.get('url', 'NO URL')}" + ) def xml_handle_doc(obj, value: Union[str, list], line_number=None, line_loc=None): diff --git a/dev_tools/tests/data/doc_nxdl2yaml.nxdl.xml b/dev_tools/tests/data/doc_nxdl2yaml.nxdl.xml index ad75b96ea8..54e539153c 100644 --- a/dev_tools/tests/data/doc_nxdl2yaml.nxdl.xml +++ b/dev_tools/tests/data/doc_nxdl2yaml.nxdl.xml @@ -41,8 +41,8 @@ lkokö sddfdfd - This concept is related to term `term`_ of the spec standard. - .. _term: url + This concept is related to term `12.58`_ of the ISO 18115-1:2023 standard. + .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 This is test doc. diff --git a/dev_tools/tests/data/doc_yaml2nxdl.yaml b/dev_tools/tests/data/doc_yaml2nxdl.yaml index df25dbb91b..5129c3a9dd 100644 --- a/dev_tools/tests/data/doc_yaml2nxdl.yaml +++ b/dev_tools/tests/data/doc_yaml2nxdl.yaml @@ -19,16 +19,16 @@ NXarchive(NXobject): "unique identifier for the experimenta lkokö sddfdfd" - - | - "xref: - spec: spec - term: term - url: url" - - | + - | + xref: + spec: ISO 18115-1:2023 + term: 12.58 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 + - | "This is test doc." experiment_description(NX_CHAR): doc: - - | + - | Part1: Text line 1. part1: Text line 2 @@ -36,7 +36,7 @@ NXarchive(NXobject): xref: spec: spec term: term - url: url" + url: url collection_identifier(NX_CHAR): doc: | diff --git a/dev_tools/tests/data/ref_doc_nxdl2yaml.yaml b/dev_tools/tests/data/ref_doc_nxdl2yaml.yaml index 75e867198a..8ad3bb82b9 100644 --- a/dev_tools/tests/data/ref_doc_nxdl2yaml.yaml +++ b/dev_tools/tests/data/ref_doc_nxdl2yaml.yaml @@ -22,9 +22,9 @@ NXarchive(NXobject): sddfdfd - | "xref: - spec: spec - term: term - url: url" + spec: ISO 18115-1:2023 + term: 12.58 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58" - | This is test doc. experiment_description(NX_CHAR): diff --git a/dev_tools/tests/data/ref_doc_yaml2nxdl.nxdl.xml b/dev_tools/tests/data/ref_doc_yaml2nxdl.nxdl.xml index ad75b96ea8..983cd8a84a 100644 --- a/dev_tools/tests/data/ref_doc_yaml2nxdl.nxdl.xml +++ b/dev_tools/tests/data/ref_doc_yaml2nxdl.nxdl.xml @@ -37,14 +37,14 @@ - unique identifier for the experimenta + "unique identifier for the experimenta lkokö - sddfdfd + sddfdfd" - This concept is related to term `term`_ of the spec standard. - .. _term: url + This concept is related to term `12.58`_ of the ISO 18115-1:2023 standard. + .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 - This is test doc. + "This is test doc." diff --git a/dev_tools/tests/test_nyaml2nxdl.py b/dev_tools/tests/test_nyaml2nxdl.py index ce7bdc064a..559a382cce 100755 --- a/dev_tools/tests/test_nyaml2nxdl.py +++ b/dev_tools/tests/test_nyaml2nxdl.py @@ -1,9 +1,11 @@ from pathlib import Path import lxml.etree as ET +import pytest from click.testing import CliRunner from ..nyaml2nxdl import nyaml2nxdl as conv +from ..nyaml2nxdl.nyaml2nxdl_forward_tools import handle_each_part_doc from ..nyaml2nxdl.nyaml2nxdl_helper import LineLoader from ..nyaml2nxdl.nyaml2nxdl_helper import remove_namespace_from_tag from ..utils.nxdl_utils import find_definition_file @@ -98,3 +100,86 @@ def compare_yaml_doc(yaml_dict1, yaml_dict2): compare_yaml_doc(yaml_dict1, yaml_dict2) Path.unlink(parsed_yaml_file) + + +@pytest.mark.parametrize( + "test_input,output,is_valid", + [ + ( + """ + xref: + spec: + term: + url: + """, + " This concept is related to term ``_ " + "of the standard.\n.. _: ", + True, + ), + ( + """ + xref: + spec: + term: + url: + """, + "Found invalid xref. Please make sure that your xref entries are valid yaml.", + False, + ), + ( + """ + xref: + spec: + term: + url: + term: + """, + "Invalid xref. It contains nested or duplicate keys.", + False, + ), + ( + """ + xref: + spec: + term: + url: + hallo: + """, + "Invalid xref. Too many keys.", + False, + ), + ( + """ + xref: + spec: + my_key: + url: + """, + "Invalid xref key `my_key`. Must be one of `term`, `spec` or `url`.", + False, + ), + ( + """ + xref: + spec: + term: + test: + url: + """, + "Invalid xref. It contains nested or duplicate keys.", + False, + ), + ], +) +def test_handle_xref(test_input, output, is_valid): + """ + Tests whether the xref generates a correct docstring. + """ + if is_valid: + assert handle_each_part_doc(test_input) == output + return + + with pytest.raises(ValueError) as err: + handle_each_part_doc(test_input) + + assert output == err.value.args[0] From 80e695e65fd98a400f24cf7d011613cd3e338860 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 13 Nov 2023 10:25:45 +0100 Subject: [PATCH 0358/1012] Use xref in NXmpes and related base classes --- .../nyaml/NXelectronanalyser.yaml | 51 +++++---- .../nyaml/NXenergydispersion.yaml | 18 ++- contributed_definitions/nyaml/NXmpes.yaml | 104 +++++++++++------- 3 files changed, 106 insertions(+), 67 deletions(-) diff --git a/contributed_definitions/nyaml/NXelectronanalyser.yaml b/contributed_definitions/nyaml/NXelectronanalyser.yaml index d576ffd6f4..cee3c5875a 100644 --- a/contributed_definitions/nyaml/NXelectronanalyser.yaml +++ b/contributed_definitions/nyaml/NXelectronanalyser.yaml @@ -1,10 +1,12 @@ category: base -doc: | - Subclass of NXinstrument to describe a photoelectron analyser. - - Refers to Term `12.59`_ of the ISO 18115-1:2023 specification. - - .. _12.59: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.59 +doc: + - | + Subclass of NXinstrument to describe a photoelectron analyser. + - | + xref: + spec: ISO 18115-1:2023 + term: 12.59 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.59 symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays @@ -49,12 +51,14 @@ NXelectronanalyser(NXobject): accurately determine the binding energy scale. energy_resolution(NX_FLOAT): unit: NX_ENERGY - doc: | - Energy resolution of the electron analyser (FWHM of gaussian broadening) - - Refers to Term `10.7`_ of the ISO 18115-1:2023 specification. - - .. _10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 + doc: + - | + Energy resolution of the electron analyser (FWHM of gaussian broadening). + - | + xref: + spec: 18115-1:2023 + term: 10.7 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 momentum_resolution(NX_FLOAT): unit: NX_WAVENUMBER doc: | @@ -65,12 +69,14 @@ NXelectronanalyser(NXobject): Angular resolution of the electron analyser (FWHM) spatial_resolution(NX_FLOAT): unit: NX_LENGTH - doc: | + doc: + - | Spatial resolution of the electron analyser (Airy disk radius) - - Refers to Term `10.15`_ ff. of the ISO 18115-1:2023 specification. - - .. _10.15: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.15 + - | + xref: + spec: ISO 18115-1:2023 + term: 10.15 ff. + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.15 fast_axes(NX_CHAR): doc: | List of the axes that are acquired simultaneously by the detector. @@ -98,7 +104,8 @@ NXelectronanalyser(NXobject): rank: 1 dim: [[1, nsa]] transmission_function(NXdata): - doc: | + doc: + - | Transmission function of the electron analyser. The transmission function (TF) specifies the detection efficiency per solid angle for electrons of @@ -111,9 +118,11 @@ NXelectronanalyser(NXobject): operating modes for an instrument would show significant variations in atomic concentrations. - Refers to Term `7.15`_ ff. of the ISO 18115-1:2023 specification. - - .. _7.15: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:7.15 + - | + xref: + spec: ISO 18115-1:2023 + term: 7.15 ff. + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:7.15 \@signal: enumeration: [relative_intensity] \@axes: diff --git a/contributed_definitions/nyaml/NXenergydispersion.yaml b/contributed_definitions/nyaml/NXenergydispersion.yaml index cfd5cc9e60..02c1d1d117 100644 --- a/contributed_definitions/nyaml/NXenergydispersion.yaml +++ b/contributed_definitions/nyaml/NXenergydispersion.yaml @@ -38,13 +38,19 @@ NXenergydispersion(NXobject): doc: | Diameter of the dispersive orbit energy_scan_mode(NX_CHAR): - doc: | + doc: + - | Way of scanning the energy axis (fixed or sweep). - - Refers to Terms `12.65`_ and `12.66`_ of the ISO 18115-1:2023 specification. - - .. _12.65: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.65 - .. _12.66: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.66 + - | + xref: + spec: ISO 18115-1:2023 + term: 12.65 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.65 + - | + xref: + spec: ISO 18115-1:2023 + term: 12.66 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.66 enumeration: [fixed, sweep] tof_distance(NX_FLOAT): unit: NX_LENGTH diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index b057c02035..4232f80f38 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -58,21 +58,29 @@ NXmpes(NXobject): Name of the affiliation of the user at the point in time when the experiment was performed. (NXinstrument): - doc: | + doc: + - | MPES spectrometer - - Refers to Term `12.58`_ of the ISO 18115-1:2023 specification. - - .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 + - | + xref: + spec: ISO 18115-1:2023 + term: 12.58 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 energy_resolution(NXresolution): exists: recommended - doc: | + doc: + - | Overall energy resolution of the MPES instrument - - Refers to Terms `10.7`_ ff. and `10.24`_ of the ISO 18115-1:2023 specification. - - .. _10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 - .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 + - | + xref: + spec: ISO 18115-1:2023 + term: 10.7 ff. + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 + - | + xref: + spec: ISO 18115-1:2023 + term: 10.24 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 physical_quantity: type: resolution(NXdata): @@ -168,13 +176,15 @@ NXmpes(NXobject): energy_resolution(NX_FLOAT): exists: recommended unit: NX_ENERGY - doc: | + doc: + - | Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - Refers to Term `10.24`_ of the ISO 18115-1:2023 specification. - - .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 + NXcalibration. + - | + xref: + spec: ISO 18115-1:2023 + term: 10.24 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 fast_axes: exists: recommended slow_axes: @@ -288,14 +298,16 @@ NXmpes(NXobject): sample_bias(NX_FLOAT): exists: recommended unit: NX_CURRENT - doc: | + doc: + - | Bias of the sample with respect to analyser ground. This field may also be found in NXsample if present. - - Refers to Term `8.41`_ of the ISO 18115-1:2023 specification. - - .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 + - | + xref: + spec: ISO 18115-1:2023 + term: 8.41 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 device_information(NXfabrication): exists: recommended vendor: @@ -355,16 +367,18 @@ NXmpes(NXobject): This is the momentum axis to be used for data plotting. energy_referencing(NXcalibration): exists: optional - doc: | + doc: + - | For energy referencing, the measured energies are corrected for the charging potential (i.e., the electrical potential of the surface region of an insulating sample, caused by irradiation) such that those energies correspond to a sample with no surface charge. Usually, the energy axis is adjusted by shifting all energies uniformally until one well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. - - Refers to Term `12.74`_ ff. of the ISO 18115-1:2023 specification. - - .. _12.74: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 + - | + xref: + spec: ISO 18115-1:2023 + term: 12.74 ff. + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 applied(NX_BOOLEAN): doc: | Have the energy axes been adjusted (e.g., in cases where samples are not @@ -380,13 +394,15 @@ NXmpes(NXobject): For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge binding_energy(NX_FLOAT): exists: recommended - doc: | + doc: + - | The binding energy (in units of eV) that the specified emission line appeared at, - after adjusting the binding energy scale. - - Refers to Term `12.16`_ ff. of the ISO 18115-1:2023 specification. - - .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + after adjusting the binding energy scale. + - | + xref: + spec: ISO 18115-1:2023 + term: 12.16_ ff. + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 offset(NX_FLOAT): exists: recommended doc: | @@ -515,18 +531,26 @@ NXmpes(NXobject): type: NX_CHAR exists: recommended doc: | - The energy can be either stored as kinetic (Term `3.35`_ of the ISO 18115-1:2023 - specification) or as binding (Term `12.16`_) energy. - - .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 - .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + The energy can be either stored as kinetic or as binding energy. enumeration: kinetic: - doc: | + doc: + - | Calibrated kinetic energy axis. + - | + xref: + spec: ISO 18115-1:2023 + term: 3.35 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 binding: - doc: | + doc: + - | Calibrated binding energy axis. + - | + xref: + spec: ISO 18115-1:2023 + term: 12.16 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ # 75917877eb699fd52182f562910ebb9fc44a699aced8a0c2a71725fffdec89ae From d5f6b0ff00d8ad371fa893262243e1d6e31b06b9 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 13 Nov 2023 11:23:27 +0100 Subject: [PATCH 0359/1012] Make NXDLs with xrefs --- .../NXelectronanalyser.nxdl.xml | 426 +++--- .../NXenergydispersion.nxdl.xml | 5 +- contributed_definitions/NXmpes.nxdl.xml | 1224 ++++++++--------- .../nyaml/NXelectronanalyser.yaml | 30 +- 4 files changed, 843 insertions(+), 842 deletions(-) diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml index 4189b83d91..17957c8519 100644 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -1,9 +1,9 @@ - + - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of fast axes (axes acquired simultaneously, without scanning a - physical quantity) - - - - - Number of slow axes (axes acquired scanning a physical quantity) - - - - - Number of data points in the transmission function. - - - - - Subclass of NXinstrument to describe a photoelectron analyser. + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of fast axes (axes acquired simultaneously, without scanning a + physical quantity) + + + + + Number of slow axes (axes acquired scanning a physical quantity) + + + + + Number of data points in the transmission function. + + + + + Subclass of NXinstrument to describe a photoelectron analyser. + + + + Free text description of the type of the detector + + + + + Name or model of the equipment + + + + Acronym or other shorthand name + + + + + + Work function of the electron analyser. - Refers to Term `12.59`_ of the ISO 18115-1:2023 specification. + The work function of a uniform surface of a conductor is the minimum energy required to remove + an electron from the interior of the solid to a vacuum level immediately outside the solid surface. - .. _12.59: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.59 + The kinetic energy :math:`E_K` of a photoelectron emitted from an energy-level with binding energy + :math:`E_B` below the Fermi level is given by :math:`E_K = h\nu - E_B - e \phi_{\mathrm{sample}}`, + where :math:`\phi_{\mathrm{sample}}` is the work function of the sample surface. In PES measurements, + the sample and the spectrometer (with work function :math:`\phi_{\mathrm{spectr.}}`) are electrically + connected and therefore their Fermi levels are aligned. Due to the difference in local vacuum level + between the sample and spectrometer, there exists an electric potential difference (contact potential) + :math:`\Delta\phi = \phi_{\mathrm{sample}} - \phi_{\mathrm{spectr.}}`. The measured kinetic energy of + a photoelectron in PES is therefore given by + :math:`E_K^{\mathrm{meas.}} = h\nu - E_B + \Delta \phi = h\nu - E_B - e \phi_{\mathrm{spectr.}}`. + As a result, the measured kinetic energy :math:`E_K^{\mathrm{meas.}}` of a photoelectron is `independent` + of the sample work function. Nonetheless, the work function :math:`\phi_s` needs to be known to + accurately determine the binding energy scale. - - - Free text description of the type of the detector - - - - - Name or model of the equipment - - - - Acronym or other shorthand name - - - - - - Work function of the electron analyser. - - The work function of a uniform surface of a conductor is the minimum energy required to remove - an electron from the interior of the solid to a vacuum level immediately outside the solid surface. - - The kinetic energy :math:`E_K` of a photoelectron emitted from an energy-level with binding energy - :math:`E_B` below the Fermi level is given by :math:`E_K = h\nu - E_B - e \phi_{\mathrm{sample}}`, - where :math:`\phi_{\mathrm{sample}}` is the work function of the sample surface. In PES measurements, - the sample and the spectrometer (with work function :math:`\phi_{\mathrm{spectr.}}`) are electrically - connected and therefore their Fermi levels are aligned. Due to the difference in local vacuum level - between the sample and spectrometer, there exists an electric potential difference (contact potential) - :math:`\Delta\phi = \phi_{\mathrm{sample}} - \phi_{\mathrm{spectr.}}`. The measured kinetic energy of - a photoelectron in PES is therefore given by - :math:`E_K^{\mathrm{meas.}} = h\nu - E_B + \Delta \phi = h\nu - E_B - e \phi_{\mathrm{spectr.}}`. - As a result, the measured kinetic energy :math:`E_K^{\mathrm{meas.}}` of a photoelectron is `independent` - of the sample work function. Nonetheless, the work function :math:`\phi_s` needs to be known to - accurately determine the binding energy scale. - - - - - Energy resolution of the electron analyser (FWHM of gaussian broadening) - - Refers to Term `10.7`_ of the ISO 18115-1:2023 specification. - - .. _10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 - - - - - Momentum resolution of the electron analyser (FWHM) - - - - - Angular resolution of the electron analyser (FWHM) - - - - - Spatial resolution of the electron analyser (Airy disk radius) - - Refers to Term `10.15`_ ff. of the ISO 18115-1:2023 specification. - - .. _10.15: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.15 - - - - - List of the axes that are acquired simultaneously by the detector. - These refer only to the experimental variables recorded by the electron analyser. - Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. - - .. csv-table:: Examples - :header: "Mode", "fast_axes", "slow_axes" - - Hemispherical in ARPES mode, "['energy', 'kx']","" - "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] - "Tof", "['energy', 'kx', 'ky']","" - "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" - - Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. - If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. - - - - - - - - List of the axes that are acquired by scanning a physical parameter, listed in - order of decreasing speed. See fast_axes for examples. - - - - + + + + Energy resolution of the electron analyser (FWHM of gaussian broadening). + + This concept is related to term `10.7`_ of the 18115-1:2023 standard. + .. _10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 + + + + + Momentum resolution of the electron analyser (FWHM) + + + + + Angular resolution of the electron analyser (FWHM) + + + + + Spatial resolution of the electron analyser (Airy disk radius) + + This concept is related to term `10.15 ff.`_ of the ISO 18115-1:2023 standard. + .. _10.15 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.15 + + + + + List of the axes that are acquired simultaneously by the detector. + These refer only to the experimental variables recorded by the electron analyser. + Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. + + .. csv-table:: Examples + :header: "Mode", "fast_axes", "slow_axes" + + Hemispherical in ARPES mode, "['energy', 'kx']","" + "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] + "Tof", "['energy', 'kx', 'ky']","" + "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" + + Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. + If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. + + + + + + + + List of the axes that are acquired by scanning a physical parameter, listed in + order of decreasing speed. See fast_axes for examples. + + + + + + + + Transmission function of the electron analyser. + + The transmission function (TF) specifies the detection efficiency per solid angle for electrons of + different kinetic energy passing through the electron analyser. It depends on the spectrometer + geometry as well as operation settings such as lens mode and pass energy. + The transmission function is usually given as kinetic energy vs. relative intensity. + + The TF is used for calibration of the intensity scale in quantitative XPS. Without proper + transmission correction, a comparison of results measured from the same sample using different + operating modes for an instrument would show significant variations in atomic + concentrations. + + This concept is related to term `7.15 ff.`_ of the ISO 18115-1:2023 standard. + .. _7.15 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:7.15 + + + + + + + + + + + + + + Kinetic energy values + + + + - - - Transmission function of the electron analyser. - - The transmission function (TF) specifies the detection efficiency per solid angle for electrons of - different kinetic energy passing through the electron analyser. It depends on the spectrometer - geometry as well as operation settings such as lens mode and pass energy. - The transmission function is usually given as kinetic energy vs. relative intensity. - - The TF is used for calibration of the intensity scale in quantitative XPS. Without proper - transmission correction, a comparison of results measured from the same sample using different - operating modes for an instrument would show significant variations in atomic - concentrations. - - Refers to Term `7.15`_ ff. of the ISO 18115-1:2023 specification. - - .. _7.15: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:7.15 - - - - - - - - - - - - - - Kinetic energy values - - - - - - - - Relative transmission efficiency for the given kinetic energies - - - - - - - - - Refers to the last transformation specifying the position of the manipulator in - the NXtransformations chain. - + + + Relative transmission efficiency for the given kinetic energies + + + + - - - Collection of axis-based translations and rotations to describe the location and - geometry of the electron analyser as a component in the instrument. Conventions - from the NXtransformations base class are used. In principle, the McStas - coordinate system is used. The first transformation has to point either to - another component of the system or . (for pointing to the reference frame) to - relate it relative to the experimental setup. Typically, the components of a - system should all be related relative to each other and only one component - should relate to the reference coordinate system. - - - - - Describes the electron collection (spatial and momentum imaging) column - - - - - Describes the energy dispersion section - - - - - Describes the spin dispersion section - - - - - Describes the electron detector - - - - - Deflectors outside the main optics ensambles described by the subclasses - - - - - Individual lenses outside the main optics ensambles described by the subclasses - - - + + + + Refers to the last transformation specifying the position of the manipulator in + the NXtransformations chain. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the electron analyser as a component in the instrument. Conventions + from the NXtransformations base class are used. In principle, the McStas + coordinate system is used. The first transformation has to point either to + another component of the system or . (for pointing to the reference frame) to + relate it relative to the experimental setup. Typically, the components of a + system should all be related relative to each other and only one component + should relate to the reference coordinate system. + + + + + Describes the electron collection (spatial and momentum imaging) column + + + + + Describes the energy dispersion section + + + + + Describes the spin dispersion section + + + + + Describes the electron detector + + + + + Deflectors outside the main optics ensambles described by the subclasses + + + + + Individual lenses outside the main optics ensambles described by the subclasses + + + diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml index 72062faf59..bd421bde80 100644 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ b/contributed_definitions/NXenergydispersion.nxdl.xml @@ -71,9 +71,10 @@ Way of scanning the energy axis (fixed or sweep). - Refers to Terms `12.65`_ and `12.66`_ of the ISO 18115-1:2023 specification. - + This concept is related to term `12.65`_ of the ISO 18115-1:2023 standard. .. _12.65: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.65 + + This concept is related to term `12.66`_ of the ISO 18115-1:2023 standard. .. _12.66: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.66 diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 93286339e6..2e3922eb25 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -1,9 +1,9 @@ - + - + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of data points in the transmission function. + + + + + This is the most general application definition for multidimensional + photoelectron spectroscopy. + + Groups and fields are named according to the + `ISO 18115-1:2023`_ specification as well as the `IUPAC Recommendations 2020`_. + + .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 + + + + + + + + + + + + Datetime of the start of the measurement. + + + + + Datetime of the end of the measurement. + + + + + A name of the experimental method according to `Clause 11`_ of + the `ISO 18115-1:2023`_ specification. + + Examples include: + * X-ray photoelectron spectroscopy (XPS) + * angle-resolved X-ray photoelectron spectroscopy (ARXPS) + * ultraviolet photoelectron spectroscopy (UPS) + * angle-resolved photoelectron spectroscopy (ARPES) + * hard X-ray photoemission spectroscopy (HAXPES) + * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) + * photoelectron emission microscopy (PEEM) + * electron spectroscopy for chemical analysis (ESCA) + + .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 + + + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + - The symbols used in the schema to specify e.g. dimensions of arrays + Name of the affiliation of the user at the point in time when the experiment was + performed. - + + + + + MPES spectrometer + + This concept is related to term `12.58`_ of the ISO 18115-1:2023 standard. + .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 + + + + Overall energy resolution of the MPES instrument + + This concept is related to term `10.7 ff.`_ of the ISO 18115-1:2023 standard. + .. _10.7 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 + + This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. + .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 + + + + + + + + + + + + + + + + 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. + + + + + + + + + + + + + + + + + + + + Specification of type, may also go to name. + + + + + + Type of probe. In photoemission it's always photons, so the full NIAC list is + restricted. + + + + + + + + + + + + + + + + The beam emitted by this source. + Should be named with the same appendix, e.g., + for `source_probe` it should refer to `beam_probe`. + Refers to the same concept as /NXentry/NXinstrument/beam_TYPE + and may be linked. + + + + + + + + The beam emitted by this source. + Should be named with the same appendix, e.g., + for `source_probe` it should refer to `beam_probe`. + Refers to the same concept as /NXentry/NXinstrument/source_TYPE + and may be linked. + + + + + + + + + The source that emitted this beam. + Should be named with the same appendix, e.g., + for `beam_probe` it should refer to `source_probe`. + Refers to the same concept as /NXentry/NXinstrument/source_TYPE + and may be linked. + + + + + + + + + + + + + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. + + This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. + .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 + + + + + + + + - Number of data points in the transmission function. + Scheme of the electron collection column. - - - - This is the most general application definition for multidimensional - photoelectron spectroscopy. - - Groups and fields are named according to the - `ISO 18115-1:2023`_ specification as well as the `IUPAC Recommendations 2020`_. - - .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html - .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 - - - - - + + + + + + + + - - - + + - Datetime of the start of the measurement. + Labelling of the lens setting in use. - - + + + - Datetime of the end of the measurement. + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. - - + + - A name of the experimental method according to `Clause 11`_ of - the `ISO 18115-1:2023`_ specification. - - Examples include: - * X-ray photoelectron spectroscopy (XPS) - * angle-resolved X-ray photoelectron spectroscopy (ARXPS) - * ultraviolet photoelectron spectroscopy (UPS) - * angle-resolved photoelectron spectroscopy (ARPES) - * hard X-ray photoemission spectroscopy (HAXPES) - * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) - * photoelectron emission microscopy (PEEM) - * electron spectroscopy for chemical analysis (ESCA) - - .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html - .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. - - + + - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. + Size, position and shape of the iris inserted in the column. + + The iris is an aperture in the lens with a variable diameter which can reduce the number of + electrons entering the analyzer. + + To add additional or other slits use the APERTURE group of NXcollectioncolumn. - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when the experiment was - performed. - - + + + + + + - + + + + + + + + + + + + + + - MPES spectrometer + Size, position and shape of the entrance slit in dispersive analyzers. - Refers to Term `12.58`_ of the ISO 18115-1:2023 specification. + To add additional or other slits use the APERTURE group of NXenergydispersion. + + + + + Size, position and shape of the exit slit in dispersive analyzers. - .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 + To add additional or other slits use the APERTURE group of NXenergydispersion. - - - Overall energy resolution of the MPES instrument - - Refers to Terms `10.7`_ ff. and `10.24`_ of the ISO 18115-1:2023 specification. - - .. _10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 - .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 - - - - - - - - - - - - - - - - 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. - - - - - - - - - - - - - - - - - - - - Specification of type, may also go to name. - - - - - - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - - - - - - - - - - - - - - - - The beam emitted by this source. - Should be named with the same appendix, e.g., - for `source_probe` it should refer to `beam_probe`. - Refers to the same concept as /NXentry/NXinstrument/beam_TYPE - and may be linked. - - - - - - - - The beam emitted by this source. - Should be named with the same appendix, e.g., - for `source_probe` it should refer to `beam_probe`. - Refers to the same concept as /NXentry/NXinstrument/source_TYPE - and may be linked. - - - - - - - - - The source that emitted this beam. - Should be named with the same appendix, e.g., - for `beam_probe` it should refer to `source_probe`. - Refers to the same concept as /NXentry/NXinstrument/source_TYPE - and may be linked. - - - - - - - - - - - - - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - Refers to Term `10.24`_ of the ISO 18115-1:2023 specification. - - .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 - - - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - - Labelling of the lens setting in use. - - - - - - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - Size, position and shape of the iris inserted in the column. - - The iris is an aperture in the lens with a variable diameter which can reduce the number of - electrons entering the analyzer. - - To add additional or other slits use the APERTURE group of NXcollectioncolumn. - - - - - - - - - - - - - - - - - - - - - - - - Size, position and shape of the entrance slit in dispersive analyzers. - - To add additional or other slits use the APERTURE group of NXenergydispersion. - - - - - Size, position and shape of the exit slit in dispersive analyzers. - - To add additional or other slits use the APERTURE group of NXenergydispersion. - - - - - - - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - - - - - - - - Raw data before calibration. - - - - - - - - Manipulator for positioning of the sample. - - - - - - Bias of the sample with respect to analyser ground. - - This field may also be found in NXsample if present. - - Refers to Term `8.41`_ of the ISO 18115-1:2023 specification. - - .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 - - - - - - - - + + + + + + - + + - 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 + Type of electron amplifier in the first amplification step. - - - Calibration event on the energy axis. - - For XPS, the calibration should ideally be performed according to - `ISO 15472:2010`_ specification. - - .. _ISO 15472:2010: https://www.iso.org/standard/74811.html - - - - Has an energy calibration been applied? - - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - - Has an angular calibration been applied? - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - - Has an spatial calibration been applied? - - - - - This is the calibrated spatial axis to be used for data plotting. - - - - - - - Has an momentum calibration been applied? - - - - - This is the momentum axis to be used for data plotting. - - - - - - For energy referencing, the measured energies are corrected for the charging potential - (i.e., the electrical potential of the surface region of an insulating sample, caused by - irradiation) such that those energies correspond to a sample with no surface charge. - Usually, the energy axis is adjusted by shifting all energies uniformally until one - well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. - - Refers to Term `12.74`_ ff. of the ISO 18115-1:2023 specification. - - .. _12.74: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 - - - - Have the energy axes been adjusted (e.g., in cases where samples are not - conductive)? - - - - - Electronic core or valence level that was used for the calibration. - - - - - Reference peak that was used for the calibration. - - For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge - - - - - The binding energy (in units of eV) that the specified emission line appeared at, - after adjusting the binding energy scale. - - Refers to Term `12.16`_ ff. of the ISO 18115-1:2023 specification. - - .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - - - - - Offset between measured binding energy and calibrated binding energy of the - emission line. - - - - - This is the calibrated energy axis to be used for data plotting. - - This should link to /entry/data/energy. - - - - - - In the transmission correction, each intensity measurement for electrons of a given - kinetic energy is multiplied by the corresponding value in the relative_intensity - field of the transmission_function. This calibration procedure is used to account for - the different tranmsission efficiencies when using different lens modes. - - - - Has an intensity calibration been applied? - - That is, has the transmission function of the analyser been taken into account? - - - - - Transmission function of the electron analyser. - - The transmission function (TF) specifies the detection efficiency for electrons of - different kinetic energy passing through the electron analyser. - This can be a link to /entry/instrument/electronanalyser/transmission_function. - - - - - - - - - - - - - - Kinetic energy values - - - - - - - - Relative transmission efficiency for the given kinetic energies - - - - - - - - - - - - - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - - - - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - - - - - Description of the surface preparation technique for the XPS experiment, i.e. - UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report - of the previous operations, in any format(NXnote allows to add pictures, audio, - movies). Alternatively, a reference to the location or a unique identifier or - other metadata file. In the case these are not available, free-text description. - - - - - In the case of a fixed temperature measurement this is the scalar temperature of - the sample. In the case of an experiment in which the temperature is changed and - recoded, this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. - - - - - - - - - - - - - - Voltage applied to sample and sample holder. - - - - + + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + - - - + + + - - - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, momentum, spatial coordinate, pump-probe - delay, spin index, temperature, etc. The axes traces should be linked to the - actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - Calibrated energy axis. - - The calibrated energy axis can be either in binding or kinetic energy. - This should be a link to either - /entry/process/energy_calibration/calibrated_axis or - /entry/process/energy_correction/calibrated_axis. - - - - The energy can be either stored as kinetic (Term `3.35`_ of the ISO 18115-1:2023 - specification) or as binding (Term `12.16`_) energy. - - .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 - .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - - - - - Calibrated kinetic energy axis. - - - - - Calibrated binding energy axis. - - - - + + + Raw data before calibration. + + + + + + + Manipulator for positioning of the sample. + + + + + + Bias of the sample with respect to analyser ground. + + This field may also be found in NXsample if present. + + This concept is related to term `8.41`_ of the ISO 18115-1:2023 standard. + .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 + + + + + + + + + + + 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 + + + + Calibration event on the energy axis. + + For XPS, the calibration should ideally be performed according to + `ISO 15472:2010`_ specification. + + .. _ISO 15472:2010: https://www.iso.org/standard/74811.html + + + + Has an energy calibration been applied? + + + + + This is the calibrated energy axis to be used for data plotting. + + + + + + + Has an angular calibration been applied? + + + + + This is the calibrated angular axis to be used for data plotting. + + + + + + + Has an spatial calibration been applied? + + + + + This is the calibrated spatial axis to be used for data plotting. + + + + + + + Has an momentum calibration been applied? + + + + + This is the momentum axis to be used for data plotting. + + + + + + For energy referencing, the measured energies are corrected for the charging potential + (i.e., the electrical potential of the surface region of an insulating sample, caused by + irradiation) such that those energies correspond to a sample with no surface charge. + Usually, the energy axis is adjusted by shifting all energies uniformally until one + well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. + + This concept is related to term `12.74 ff.`_ of the ISO 18115-1:2023 standard. + .. _12.74 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 + + + + Have the energy axes been adjusted (e.g., in cases where samples are not + conductive)? + + + + + Electronic core or valence level that was used for the calibration. + + + + + Reference peak that was used for the calibration. + + For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge + + + + + The binding energy (in units of eV) that the specified emission line appeared at, + after adjusting the binding energy scale. + + This concept is related to term `12.16_ ff.`_ of the ISO 18115-1:2023 standard. + .. _12.16_ ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + + + + + Offset between measured binding energy and calibrated binding energy of the + emission line. + + + + + This is the calibrated energy axis to be used for data plotting. + + This should link to /entry/data/energy. + + + + + + In the transmission correction, each intensity measurement for electrons of a given + kinetic energy is multiplied by the corresponding value in the relative_intensity + field of the transmission_function. This calibration procedure is used to account for + the different tranmsission efficiencies when using different lens modes. + + + + Has an intensity calibration been applied? + + That is, has the transmission function of the analyser been taken into account? + + + + + Transmission function of the electron analyser. + + The transmission function (TF) specifies the detection efficiency for electrons of + different kinetic energy passing through the electron analyser. + This can be a link to /entry/instrument/electronanalyser/transmission_function. + + + + + + + + + + + + + + Kinetic energy values + + + + + + + + Relative transmission efficiency for the given kinetic energies + + + + + + + + + + + + + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + + + + + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + + + + + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). + + + + + Description of the surface preparation technique for the XPS experiment, i.e. + UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report + of the previous operations, in any format(NXnote allows to add pictures, audio, + movies). Alternatively, a reference to the location or a unique identifier or + other metadata file. In the case these are not available, free-text description. + + + + + In the case of a fixed temperature measurement this is the scalar temperature of + the sample. In the case of an experiment in which the temperature is changed and + recoded, this is an array of length m of temperatures. This should be a link to + /entry/instrument/manipulator/sample_temperature. + + + + + + + + + + + + + + Voltage applied to sample and sample holder. + + + + + + + + + + + + Represents a measure of one- or more-dimensional photoemission counts, where the + varied axis may be for example energy, momentum, spatial coordinate, pump-probe + delay, spin index, temperature, etc. The axes traces should be linked to the + actual encoder position in NXinstrument or calibrated axes in NXprocess. + + + + + Calibrated energy axis. + + The calibrated energy axis can be either in binding or kinetic energy. + This should be a link to either + /entry/process/energy_calibration/calibrated_axis or + /entry/process/energy_correction/calibrated_axis. + + + + The energy can be either stored as kinetic or as binding energy. + + + + + Calibrated kinetic energy axis. + + This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. + .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 + + + + + Calibrated binding energy axis. + + This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. + .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + + + + + + diff --git a/contributed_definitions/nyaml/NXelectronanalyser.yaml b/contributed_definitions/nyaml/NXelectronanalyser.yaml index cee3c5875a..49d41125a9 100644 --- a/contributed_definitions/nyaml/NXelectronanalyser.yaml +++ b/contributed_definitions/nyaml/NXelectronanalyser.yaml @@ -1,12 +1,12 @@ category: base -doc: - - | - Subclass of NXinstrument to describe a photoelectron analyser. - - | - xref: - spec: ISO 18115-1:2023 - term: 12.59 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.59 +doc: Subclass of NXinstrument to describe a photoelectron analyser. +# - | +# Subclass of NXinstrument to describe a photoelectron analyser. +# - | +# xref: +# spec: ISO 18115-1:2023 +# term: 12.59 +# url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.59 symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays @@ -52,13 +52,13 @@ NXelectronanalyser(NXobject): energy_resolution(NX_FLOAT): unit: NX_ENERGY doc: - - | - Energy resolution of the electron analyser (FWHM of gaussian broadening). - - | - xref: - spec: 18115-1:2023 - term: 10.7 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 + - | + Energy resolution of the electron analyser (FWHM of gaussian broadening). + - | + xref: + spec: 18115-1:2023 + term: 10.7 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 momentum_resolution(NX_FLOAT): unit: NX_WAVENUMBER doc: | From 2ee5d51f66fe32871fccc428ee6210e1f60cf88c Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 15 Nov 2023 18:33:18 +0100 Subject: [PATCH 0360/1012] Use xref in NXelectronanalyser --- .../NXelectronanalyser.nxdl.xml | 10 +++------- .../nyaml/NXelectronanalyser.yaml | 16 ++++++++-------- 2 files changed, 11 insertions(+), 15 deletions(-) diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml index 17957c8519..356a0b6df1 100644 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -22,13 +22,6 @@ # For further information, see http://www.nexusformat.org --> - The symbols used in the schema to specify e.g. dimensions of arrays @@ -52,6 +45,9 @@ Subclass of NXinstrument to describe a photoelectron analyser. + + This concept is related to term `12.59`_ of the ISO 18115-1:2023 standard. + .. _12.59: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.59 diff --git a/contributed_definitions/nyaml/NXelectronanalyser.yaml b/contributed_definitions/nyaml/NXelectronanalyser.yaml index 49d41125a9..3ed3e4fc7d 100644 --- a/contributed_definitions/nyaml/NXelectronanalyser.yaml +++ b/contributed_definitions/nyaml/NXelectronanalyser.yaml @@ -1,12 +1,12 @@ category: base -doc: Subclass of NXinstrument to describe a photoelectron analyser. -# - | -# Subclass of NXinstrument to describe a photoelectron analyser. -# - | -# xref: -# spec: ISO 18115-1:2023 -# term: 12.59 -# url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.59 +doc: +- | + Subclass of NXinstrument to describe a photoelectron analyser. +- | + xref: + spec: ISO 18115-1:2023 + term: 12.59 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.59 symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays From 7f8ac5de02f7a527c10b8a0a61536c25792e348b Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 15 Nov 2023 18:39:57 +0100 Subject: [PATCH 0361/1012] Allow xref in root-level docstring --- .../nyaml2nxdl/nyaml2nxdl_backward_tools.py | 2 +- .../nyaml2nxdl/nyaml2nxdl_forward_tools.py | 7 +++--- dev_tools/tests/data/doc_yaml2nxdl.yaml | 24 ++++++++++++------- .../tests/data/ref_doc_yaml2nxdl.nxdl.xml | 3 +++ 4 files changed, 23 insertions(+), 13 deletions(-) diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py b/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py index dfae600e15..e30ddcf3f0 100755 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py +++ b/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py @@ -336,7 +336,7 @@ def clean_and_organise_text(self, text, depth): def check_and_handle_doc_xref_and_other_doc(self, text, indent): """Check for xref doc which comes as a block of text. - The doc part bellow is the example how xref comes: + The doc part below is the example how xref comes: ''' This concept is related to term ``_ of the standard. .. _: diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py b/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py index fa78b82929..1083d73ee2 100644 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py +++ b/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py @@ -1200,9 +1200,10 @@ def nyaml2nxdl(input_file: str, out_file, verbose: bool): del yml_appdef["symbols"] del yml_appdef["__line__symbols"] - assert ( - isinstance(yml_appdef["doc"], str) and yml_appdef["doc"] != "" - ), "Doc has to be a non-empty string!" + if isinstance(yml_appdef["doc"], str): + assert (yml_appdef["doc"] != ""), "Doc has to be a non-empty string!" + elif isinstance(yml_appdef["doc"], list): + assert (any(yml_appdef["doc"])), "One of the doc elements has to be a non-empty string!" line_number = "__line__doc" line_loc_no = yml_appdef[line_number] diff --git a/dev_tools/tests/data/doc_yaml2nxdl.yaml b/dev_tools/tests/data/doc_yaml2nxdl.yaml index 5129c3a9dd..94b3763256 100644 --- a/dev_tools/tests/data/doc_yaml2nxdl.yaml +++ b/dev_tools/tests/data/doc_yaml2nxdl.yaml @@ -1,13 +1,19 @@ category: application -doc: | - This is a definition for data to be archived by ICAT (http://www.icatproject.org/). - - .. text from the icatproject.org site - - the database (with supporting software) that provides an - interface to all ISIS experimental data and will provide - a mechanism to link all aspects of ISIS research from - proposal through to publication. +doc: + - | + This is a definition for data to be archived by ICAT (http://www.icatproject.org/). + + .. text from the icatproject.org site + + the database (with supporting software) that provides an + interface to all ISIS experimental data and will provide + a mechanism to link all aspects of ISIS research from + proposal through to publication. + - | + xref: + spec: ISO 18115-1:2023 + term: 1.1 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:1.1 type: group NXarchive(NXobject): (NXentry)entry: diff --git a/dev_tools/tests/data/ref_doc_yaml2nxdl.nxdl.xml b/dev_tools/tests/data/ref_doc_yaml2nxdl.nxdl.xml index 983cd8a84a..854447e26d 100644 --- a/dev_tools/tests/data/ref_doc_yaml2nxdl.nxdl.xml +++ b/dev_tools/tests/data/ref_doc_yaml2nxdl.nxdl.xml @@ -31,6 +31,9 @@ interface to all ISIS experimental data and will provide a mechanism to link all aspects of ISIS research from proposal through to publication. + + This concept is related to term `1.1`_ of the ISO 18115-1:2023 standard. + .. _1.1: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:1.1 From 7e7fb57a954b4e489e63a8fd664140af42b6bf1d Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 15 Nov 2023 18:55:17 +0100 Subject: [PATCH 0362/1012] Black codestyle --- dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py b/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py index 1083d73ee2..45c5a4c754 100644 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py +++ b/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py @@ -1201,9 +1201,11 @@ def nyaml2nxdl(input_file: str, out_file, verbose: bool): del yml_appdef["symbols"] del yml_appdef["__line__symbols"] if isinstance(yml_appdef["doc"], str): - assert (yml_appdef["doc"] != ""), "Doc has to be a non-empty string!" + assert yml_appdef["doc"] != "", "Doc has to be a non-empty string!" elif isinstance(yml_appdef["doc"], list): - assert (any(yml_appdef["doc"])), "One of the doc elements has to be a non-empty string!" + assert any( + yml_appdef["doc"] + ), "One of the doc elements has to be a non-empty string!" line_number = "__line__doc" line_loc_no = yml_appdef[line_number] From 57c263542b15b9f332d57a26343c5c5395d42f8b Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 27 Nov 2023 16:44:41 +0100 Subject: [PATCH 0363/1012] remove NXsource nyaml from contributed definitions --- contributed_definitions/nyaml/NXsource.yaml | 521 -------------------- 1 file changed, 521 deletions(-) delete mode 100644 contributed_definitions/nyaml/NXsource.yaml diff --git a/contributed_definitions/nyaml/NXsource.yaml b/contributed_definitions/nyaml/NXsource.yaml deleted file mode 100644 index 1692b666ea..0000000000 --- a/contributed_definitions/nyaml/NXsource.yaml +++ /dev/null @@ -1,521 +0,0 @@ -category: base -doc: | - The neutron or x-ray storage ring/facility. -type: group -NXsource(NXobject): - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Effective distance from sample - Distance as seen by radiation from sample. This number should be negative - to signify that it is upstream of the sample. - name: - doc: | - Name of source - \@short_name: - doc: | - short name for source, perhaps the acronym - type: - doc: | - type of radiation source (pick one from the enumerated list and spell exactly) - enumeration: [Spallation Neutron Source, Pulsed Reactor Neutron Source, Reactor Neutron Source, Synchrotron X-ray Source, Pulsed Muon Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, Ion Source, UV Plasma Source, Metal Jet X-ray] - probe: - doc: | - type of radiation probe (pick one from the enumerated list and spell exactly) - enumeration: [neutron, x-ray, muon, electron, ultraviolet, visible light, positron, proton] - power(NX_FLOAT): - unit: NX_POWER - doc: | - Source power - emittance_x(NX_FLOAT): - unit: NX_EMITTANCE - doc: | - Source emittance (nm-rad) in X (horizontal) direction. - emittance_y(NX_FLOAT): - unit: NX_EMITTANCE - doc: | - Source emittance (nm-rad) in Y (horizontal) direction. - sigma_x(NX_FLOAT): - unit: NX_LENGTH - doc: | - particle beam size in x - sigma_y(NX_FLOAT): - unit: NX_LENGTH - doc: | - particle beam size in y - flux(NX_FLOAT): - unit: NX_FLUX - doc: | - Source intensity/area (example: s-1 cm-2) - energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - Source energy. - For storage rings, this would be the particle beam energy. - For X-ray tubes, this would be the excitation voltage. - current(NX_FLOAT): - unit: NX_CURRENT - doc: | - Accelerator, X-ray tube, or storage ring current - voltage(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - Accelerator voltage - frequency(NX_FLOAT): - unit: NX_FREQUENCY - doc: | - Frequency of pulsed source - period(NX_FLOAT): - unit: NX_PERIOD - doc: | - Period of pulsed source - target_material: - doc: | - Pulsed source target material - enumeration: [Ta, W, depleted_U, enriched_U, Hg, Pb, C] - notes(NXnote): - doc: | - any source/facility related messages/events that - occurred during the experiment - bunch_pattern(NXdata): - doc: | - For storage rings, description of the bunch pattern. - This is useful to describe irregular bunch patterns. - title: - doc: | - name of the bunch pattern - number_of_bunches(NX_INT): - doc: | - For storage rings, the number of bunches in use. - bunch_length(NX_FLOAT): - unit: NX_TIME - doc: | - For storage rings, temporal length of the bunch - bunch_distance(NX_FLOAT): - unit: NX_TIME - doc: | - For storage rings, time between bunches - pulse_width(NX_FLOAT): - unit: NX_TIME - doc: | - temporal width of source pulse - - # pulsed sources or storage rings could use this - pulse_shape(NXdata): - doc: | - source pulse shape - - # pulsed sources or storage rings could use this - mode: - doc: | - source operating mode - enumeration: - Single Bunch: - doc: | - for storage rings - Multi Bunch: - doc: | - for storage rings - - # other sources could add to this - - # other sources could add to this - top_up(NX_BOOLEAN): - doc: | - Is the synchrotron operating in top_up mode? - last_fill(NX_NUMBER): - unit: NX_CURRENT - doc: | - For storage rings, the current at the end of the most recent injection. - \@time: - type: NX_DATE_TIME - doc: | - date and time of the most recent injection. - photon_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - The center photon energy of the source, before it is - monochromatized or converted - center_wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - The center wavelength of the source, before it is - monochromatized or converted - pulse_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - For pulsed sources, the energy of a single pulse - peak_power(NX_FLOAT): - unit: NX_POWER - doc: | - For pulsed sources, the pulse energy divided - by the pulse duration - bunch_number_start(NX_INT): - doc: | - Some facilities tag each bunch. - First bunch of the measurement - bunch_number_end(NX_INT): - doc: | - Last bunch of the measurement - geometry(NXgeometry): - deprecated: | - Use the field `depends_on` and :ref:`NXtransformations` to position the source and NXoff_geometry to describe its shape instead - doc: | - "Engineering" location of source. - (NXfabrication): - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the beam line component - distribution(NXdata): - doc: | - The wavelength or energy distribution of the source - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the - z axis. - - .. image:: source/source.png - :width: 40% - (NXtransformations): - doc: | - 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 19f1ee4e446868766ab035145a5835ce38e26b04d8e8ee50bf641392cb5c3525 -# -# -# -# -# -# The neutron or x-ray storage ring/facility. -# -# -# -# Effective distance from sample -# Distance as seen by radiation from sample. This number should be negative -# to signify that it is upstream of the sample. -# -# -# -# -# Name of source -# -# -# -# short name for source, perhaps the acronym -# -# -# -# -# -# type of radiation source (pick one from the enumerated list and spell exactly) -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# type of radiation probe (pick one from the enumerated list and spell exactly) -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Source power -# -# -# -# -# Source emittance (nm-rad) in X (horizontal) direction. -# -# -# -# -# Source emittance (nm-rad) in Y (horizontal) direction. -# -# -# -# -# particle beam size in x -# -# -# -# -# particle beam size in y -# -# -# -# -# Source intensity/area (example: s-1 cm-2) -# -# -# -# -# Source energy. -# For storage rings, this would be the particle beam energy. -# For X-ray tubes, this would be the excitation voltage. -# -# -# -# -# Accelerator, X-ray tube, or storage ring current -# -# -# -# -# Accelerator voltage -# -# -# -# -# Frequency of pulsed source -# -# -# -# -# Period of pulsed source -# -# -# -# -# Pulsed source target material -# -# -# -# -# -# -# -# -# -# -# -# -# -# any source/facility related messages/events that -# occurred during the experiment -# -# -# -# -# For storage rings, description of the bunch pattern. -# This is useful to describe irregular bunch patterns. -# -# -# -# name of the bunch pattern -# -# -# -# -# -# For storage rings, the number of bunches in use. -# -# -# -# -# For storage rings, temporal length of the bunch -# -# -# -# -# For storage rings, time between bunches -# -# -# -# -# temporal width of source pulse -# -# -# -# -# -# source pulse shape -# -# -# -# -# -# source operating mode -# -# -# -# -# for storage rings -# -# -# -# -# for storage rings -# -# -# -# -# -# -# -# -# Is the synchrotron operating in top_up mode? -# -# -# -# -# For storage rings, the current at the end of the most recent injection. -# -# -# -# date and time of the most recent injection. -# -# -# -# -# -# The center photon energy of the source, before it is -# monochromatized or converted -# -# -# -# -# The center wavelength of the source, before it is -# monochromatized or converted -# -# -# -# -# For pulsed sources, the energy of a single pulse -# -# -# -# -# For pulsed sources, the pulse energy divided -# by the pulse duration -# -# -# -# -# Some facilities tag each bunch. -# First bunch of the measurement -# -# -# -# -# Last bunch of the measurement -# -# -# -# -# "Engineering" location of source. -# -# -# -# -# This group describes the shape of the beam line component -# -# -# -# -# The wavelength or energy distribution of the source -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the -# z axis. -# -# .. image:: source/source.png -# :width: 40% -# -# -# -# -# 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. -# -# -# From 12dbd8539a0369319e5496b858654ea3679025f5 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 27 Nov 2023 17:21:25 +0100 Subject: [PATCH 0364/1012] initial fix in nyaml files --- .../nyaml/NXelectronanalyser.yaml | 37 +++++++++++++------ contributed_definitions/nyaml/NXmpes.yaml | 21 ++++------- 2 files changed, 33 insertions(+), 25 deletions(-) diff --git a/contributed_definitions/nyaml/NXelectronanalyser.yaml b/contributed_definitions/nyaml/NXelectronanalyser.yaml index 3ed3e4fc7d..fee1b62beb 100644 --- a/contributed_definitions/nyaml/NXelectronanalyser.yaml +++ b/contributed_definitions/nyaml/NXelectronanalyser.yaml @@ -49,26 +49,35 @@ NXelectronanalyser(NXobject): As a result, the measured kinetic energy :math:`E_K^{\mathrm{meas.}}` of a photoelectron is `independent` of the sample work function. Nonetheless, the work function :math:`\phi_s` needs to be known to accurately determine the binding energy scale. - energy_resolution(NX_FLOAT): - unit: NX_ENERGY + energy_resolution(NXresolution): doc: - | - Energy resolution of the electron analyser (FWHM of gaussian broadening). + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. - | xref: - spec: 18115-1:2023 - term: 10.7 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 - momentum_resolution(NX_FLOAT): - unit: NX_WAVENUMBER + spec: ISO 18115-1:2023 + term: 10.24 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 + physical_quantity: + enumeration: [energy] + resolution(NXdata): + unit: NX_ENERGY + momentum_resolution(NXresolution): doc: | Momentum resolution of the electron analyser (FWHM) - angular_resolution(NX_FLOAT): - unit: NX_ANGLE + physical_quantity: + enumeration: [momentum] + resolution(NXdata): + unit: NX_WAVENUMBER + angular_resolution(NXresolution): doc: | Angular resolution of the electron analyser (FWHM) - spatial_resolution(NX_FLOAT): - unit: NX_LENGTH + physical_quantity: + enumeration: [angle] + resolution(NXdata): + unit: NX_ANGLE + spatial_resolution(NXresolution): doc: - | Spatial resolution of the electron analyser (Airy disk radius) @@ -77,6 +86,10 @@ NXelectronanalyser(NXobject): spec: ISO 18115-1:2023 term: 10.15 ff. url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.15 + physical_quantity: + enumeration: [length] + resolution(NXdata): + unit: NX_LENGTH fast_axes(NX_CHAR): doc: | List of the axes that are acquired simultaneously by the detector. diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 4232f80f38..8123d498e8 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -82,10 +82,10 @@ NXmpes(NXobject): term: 10.24 url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 physical_quantity: + enumeration: [energy] type: resolution(NXdata): - magnitude(NX_FLOAT): - unit: NX_ENERGY + unit: NX_ENERGY device_information(NXfabrication): exists: recommended vendor: @@ -173,18 +173,13 @@ NXmpes(NXobject): identifier: exists: recommended description: - energy_resolution(NX_FLOAT): + energy_resolution(NXresolution): exists: recommended - unit: NX_ENERGY - doc: - - | - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - | - xref: - spec: ISO 18115-1:2023 - term: 10.24 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 + type: + physical_quantity: + enumeration: [energy] + resolution(NXdata): + unit: NX_ENERGY fast_axes: exists: recommended slow_axes: From a74768b36da66b0f68202c16a71d54e9664941b2 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 27 Nov 2023 17:39:54 +0100 Subject: [PATCH 0365/1012] named resolution in instrument and analyser base class --- .../nyaml/NXelectronanalyser.yaml | 3 ++ .../nyaml/NXinstrument.yaml | 42 +++++++++++++------ 2 files changed, 32 insertions(+), 13 deletions(-) diff --git a/contributed_definitions/nyaml/NXelectronanalyser.yaml b/contributed_definitions/nyaml/NXelectronanalyser.yaml index fee1b62beb..7dc8b0a4c5 100644 --- a/contributed_definitions/nyaml/NXelectronanalyser.yaml +++ b/contributed_definitions/nyaml/NXelectronanalyser.yaml @@ -187,6 +187,9 @@ NXelectronanalyser(NXobject): doc: | Individual lenses outside the main optics ensambles described by the subclasses (NXfabrication): + (NXresolution): + doc: | + Any other resolution not explictily named in this base class. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ # 9c03d1de4220953d6aaa62a9a36d641e38a166d3f5ca2f4e2e990c8ab9f9c7f8 diff --git a/contributed_definitions/nyaml/NXinstrument.yaml b/contributed_definitions/nyaml/NXinstrument.yaml index 4607aa5ae5..e9f83eeaf7 100644 --- a/contributed_definitions/nyaml/NXinstrument.yaml +++ b/contributed_definitions/nyaml/NXinstrument.yaml @@ -16,26 +16,41 @@ NXinstrument(NXobject): \@short_name: doc: | short name for instrument, perhaps the acronym - energy_resolution(NX_FLOAT): - unit: NX_ENERGY + energy_resolution(NXresolution): doc: | - Energy resolution of the experiment (FWHM or gaussian broadening) - momentum_resolution(NX_FLOAT): - unit: NX_WAVENUMBER + Energy resolution of the experiment (FWHM or gaussian broadening). + physical_quantity: + enumeration: [energy] + resolution(NXdata): + unit: NX_ENERGY + momentum_resolution(NXresolution): doc: | - Momentum resolution of the experiment (FWHM) - angular_resolution(NX_FLOAT): - unit: NX_ANGLE + Momentum resolution of the experiment (FWHM or gaussian broadening). + physical_quantity: + enumeration: [momentum] + resolution(NXdata): + unit: NX_WAVENUMBER + angular_resolution(NXresolution): doc: | - Angular resolution of the experiment (FWHM) - spatial_resolution(NX_FLOAT): - unit: NX_LENGTH + Angular resolution of the experiment (FWHM or gaussian broadening). + physical_quantity: + enumeration: [angle] + resolution(NXdata): + unit: NX_ANGLE + spatial_resolution(NXresolution): doc: | Spatial resolution of the experiment (Airy disk radius) - temporal_resolution(NX_FLOAT): - unit: NX_TIME + physical_quantity: + enumeration: [length] + resolution(NXdata): + unit: NX_LENGTH + temporal_resolution(NXresolution): doc: | Temporal resolution of the experiment (FWHM) + physical_quantity: + enumeration: [time] + resolution(NXdata): + unit: NX_TIME (NXaperture): (NXattenuator): (NXbeam): @@ -60,6 +75,7 @@ NXinstrument(NXobject): (NXmonochromator): (NXpolarizer): (NXpositioner): + (NXresolution): (NXsource): (NXtransformations)DIFFRACTOMETER: (NXvelocity_selector): From 3a7ecc89900fdbf152d8b0f9e1bc27b5e79c7262 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 28 Nov 2023 10:23:34 +0100 Subject: [PATCH 0366/1012] Rename torrodial to Torrodial to align with other options. --- contributed_definitions/NXcollectioncolumn.nxdl.xml | 4 ++-- contributed_definitions/nyaml/NXmpes.yaml | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXcollectioncolumn.nxdl.xml index 862b270c95..dce7795612 100644 --- a/contributed_definitions/NXcollectioncolumn.nxdl.xml +++ b/contributed_definitions/NXcollectioncolumn.nxdl.xml @@ -1,9 +1,9 @@ - + - - Subclass of NXelectronanalyser to describe the energy dispersion section of a - photoelectron analyser. - - - Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, - mirror, retarding grid, etc. + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. - - - - Energy of the electrons on the mean path of the analyser. Pass energy for - hemispherics, drift energy for tofs. - - Refers to Term `12.63`_ of the ISO 18115-1:2023 specification. - - .. _12.63: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.63 - - - - - Center of the energy window - - - - - The interval of transmitted energies. It can be two different things depending - on whether the scan is fixed or swept. With a fixed scan it is a 2 vector - containing the extrema of the transmitted energy window (smaller number first). - With a swept scan of m steps it is a 2xm array of windows one for each - measurement point. - - - - - Size, position and shape of a slit in dispersive analyzer, e.g. entrance and - exit slits. - - - - - Diameter of the dispersive orbit - - - - - Way of scanning the energy axis (fixed or sweep). - - This concept is related to term `12.65`_ of the ISO 18115-1:2023 standard. - .. _12.65: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.65 - - This concept is related to term `12.66`_ of the ISO 18115-1:2023 standard. - .. _12.66: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.66 - - - - - - - - - Length of the tof drift electrode - - - - - Deflectors in the energy dispersive section - - - - - Individual lenses in the energy dispersive section - - - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the energy dispersive element as a component in the instrument. - Conventions from the NXtransformations base class are used. In principle, - the McStas coordinate system is used. The first transformation has to point - either to another component of the system or . (for pointing to the reference frame) - to relate it relative to the experimental setup. Typically, the components of a system - should all be related relative to each other and only one component should relate to - the reference coordinate system. - - + + + Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, + mirror, retarding grid, etc. + + + + + Energy of the electrons on the mean path of the analyser. Pass energy for + hemispherics, drift energy for tofs. + + Refers to Term `12.63`_ of the ISO 18115-1:2023 specification. + + .. _12.63: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.63 + + + + + Center of the energy window + + + + + The interval of transmitted energies. It can be two different things depending + on whether the scan is fixed or swept. With a fixed scan it is a 2 vector + containing the extrema of the transmitted energy window (smaller number first). + With a swept scan of m steps it is a 2xm array of windows one for each + measurement point. + + + + + Size, position and shape of a slit in dispersive analyzer, e.g. entrance and + exit slits. + + + + + Diameter of the dispersive orbit + + + + + Way of scanning the energy axis + + + + + constant ΔE mode, where the electron retardation (i.e., the fraction of pass energy to + kinetic energy, R = (EK - WF/Ep)) is scanned, but the pass energy Ep is kept constant. + Here, WF is the spectrometer work function. + This mode is often used in XPS/UPS because the energy resolution does not change with + changing energy (due to the constant pass energy). + + Synonyms: constant ΔE mode, constant analyser energy mode, CAE mode, FAT mode + + This concept is related to term `12.64`_ of the ISO 18115-1:2023 standard. + .. _12.64: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.64 + + + + + constant ΔE/E mode, where the pass energy is scanned such that the electron retardation + ratio is constant. In this mode, electrons of all energies are decelerated with this same + fixed factor. Thus, the pass energy is proportional to the kinetic energy. This mode is often + used in Auger electron spectroscopy (AES) to improve S/N for high-KE electrons, but this + leads to a changing energy resolution (∆E ~ Ep) at different kinetic energies. It can however + also be used in XPS. + + Synonyms: constant ΔE/E mode, constant retardation ratio mode, CRR mode, FRR mode + + This concept is related to term `12.66`_ of the ISO 18115-1:2023 standard. + .. _12.66: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.66 + + + + + In the fixed energy (FE) mode, the intensity for one single kinetic energy is measured for a + specified time. This mode is particulary useful during setup or alignment of the + electron analyzer, for analysis of stability of the excitation source or for sample + alignment. + + Since the mode measures intensity as a function of time, the difference in channel signals + is not of interest. Threfore, the signals from all channels are summed. + + Synonyms: FE mode + + + + + Snapshot mode does not involve an energy scan and instead collects data from all channels of + the detector without averaging. The resulting spectrum reflects the energy distribution of + particles passing through the analyzer using the current settings. This mode is commonly used + to position the detection energy at the peak of a peak and record the signal, enabling faster + data acquisition within a limited energy range compared to FAT. Snapshot measurements are + particularly suitable for CCD and DLD detectors, which have multiple channels and can accurately + display the peak shape. While five or nine-channel detectors can also be used for snapshot + measurements, their energy resolution is relatively lower. + + + + + MISSING DOC. + + This concept is related to term `<term>`_ of the <spec> standard. + .. _<term>: <url> + + + + + MISSING DOC. + + This concept is related to term `<term>`_ of the <spec> standard. + .. _<term>: <url> + + + + + + + Length of the tof drift electrode + + + + + Deflectors in the energy dispersive section + + + + + Individual lenses in the energy dispersive section + + + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the energy dispersive element as a component in the instrument. + Conventions from the NXtransformations base class are used. In principle, + the McStas coordinate system is used. The first transformation has to point + either to another component of the system or . (for pointing to the reference frame) + to relate it relative to the experimental setup. Typically, the components of a system + should all be related relative to each other and only one component should relate to + the reference coordinate system. + + diff --git a/contributed_definitions/nyaml/NXenergydispersion.yaml b/contributed_definitions/nyaml/NXenergydispersion.yaml index 02c1d1d117..97368f62fd 100644 --- a/contributed_definitions/nyaml/NXenergydispersion.yaml +++ b/contributed_definitions/nyaml/NXenergydispersion.yaml @@ -13,9 +13,9 @@ NXenergydispersion(NXobject): doc: | Energy of the electrons on the mean path of the analyser. Pass energy for hemispherics, drift energy for tofs. - + Refers to Term `12.63`_ of the ISO 18115-1:2023 specification. - + .. _12.63: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.63 center_energy(NX_FLOAT): unit: NX_ENERGY @@ -40,18 +40,78 @@ NXenergydispersion(NXobject): energy_scan_mode(NX_CHAR): doc: - | - Way of scanning the energy axis (fixed or sweep). - - | - xref: - spec: ISO 18115-1:2023 - term: 12.65 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.65 - - | - xref: - spec: ISO 18115-1:2023 - term: 12.66 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.66 - enumeration: [fixed, sweep] + Way of scanning the energy axis + enumeration: + fixed_analyser_transmission: + doc: + - | + constant ΔE mode, where the electron retardation (i.e., the fraction of pass energy to + kinetic energy, R = (EK - WF/Ep)) is scanned, but the pass energy Ep is kept constant. + Here, WF is the spectrometer work function. + This mode is often used in XPS/UPS because the energy resolution does not change with + changing energy (due to the constant pass energy). + + Synonyms: constant ΔE mode, constant analyser energy mode, CAE mode, FAT mode + - | + xref: + spec: ISO 18115-1:2023 + term: 12.64 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.64 + fixed_retardation_ratio: + doc: + - | + constant ΔE/E mode, where the pass energy is scanned such that the electron retardation + ratio is constant. In this mode, electrons of all energies are decelerated with this same + fixed factor. Thus, the pass energy is proportional to the kinetic energy. This mode is often + used in Auger electron spectroscopy (AES) to improve S/N for high-KE electrons, but this + leads to a changing energy resolution (∆E ~ Ep) at different kinetic energies. It can however + also be used in XPS. + + Synonyms: constant ΔE/E mode, constant retardation ratio mode, CRR mode, FRR mode + - | + xref: + spec: ISO 18115-1:2023 + term: 12.66 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.66 + fixed_energy: + doc: | + In the fixed energy (FE) mode, the intensity for one single kinetic energy is measured for a + specified time. This mode is particulary useful during setup or alignment of the + electron analyzer, for analysis of stability of the excitation source or for sample + alignment. + + Since the mode measures intensity as a function of time, the difference in channel signals + is not of interest. Threfore, the signals from all channels are summed. + + Synonyms: FE mode + snapshot: + doc: | + Snapshot mode does not involve an energy scan and instead collects data from all channels of + the detector without averaging. The resulting spectrum reflects the energy distribution of + particles passing through the analyzer using the current settings. This mode is commonly used + to position the detection energy at the peak of a peak and record the signal, enabling faster + data acquisition within a limited energy range compared to FAT. Snapshot measurements are + particularly suitable for CCD and DLD detectors, which have multiple channels and can accurately + display the peak shape. While five or nine-channel detectors can also be used for snapshot + measurements, their energy resolution is relatively lower. + transmission: + doc: + - | + MISSING DOC. + - | + xref: + spec: + term: + url: + jittered: + doc: + - | + MISSING DOC. + - | + xref: + spec: + term: + url: tof_distance(NX_FLOAT): unit: NX_LENGTH doc: | From 14f0c69f4cf3ddfc5293cc4a53fe5b1bbf2c4bd5 Mon Sep 17 00:00:00 2001 From: rettigl Date: Tue, 28 Nov 2023 14:45:11 +0100 Subject: [PATCH 0368/1012] remove WL changes --- .../NXelectronanalyser.nxdl.xml | 26 ++-- .../nyaml/NXelectronanalyser.yaml | 70 +++++------ contributed_definitions/nyaml/NXmpes.yaml | 116 +++++++++--------- 3 files changed, 106 insertions(+), 106 deletions(-) diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml index a075b94233..356a0b6df1 100644 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -2,9 +2,9 @@ - - Definition of the root NeXus group. - - - The root of any NeXus data file is an ``NXroot`` class - (no other choice is allowed for a valid NeXus data file). - This attribute cements that definition. + Definition of the root NeXus group. - - - - - - - Date and time file was originally created - - - - - File name of original NeXus file - - - - - Date and time of last file change at close - - - - - A repository containing the application definitions - used for creating this file. - If the NeXus_version attribute contains a commit distance and hash - this should refer to this repository. - - - - - Version of NeXus definitions used in writing the file. - This may either be a date based version tag of the form `vYYYY.MM` - or a version tag with a commit distance and source control (e.g., git) hash of - the form `vYYYY.MM.post1.dev<commit-distance>.g<git-hash>`. - It may contain an additional `.dYYYYMMDD` timestamp appendix - for dirty repositories. - If the version contains a commit distance and hash the - NeXus_repository attribute should be written with the - repository url containing this version. - - Only used when the NAPI or pynxtools has written the file. - Note that this is different from the version of the - base class or application definition version number. - - - - - A list of concepts in an application definition this file describes. - This is for partially filling an application definition. - If this attribute is not present the application definition is assumed - to be valid, if not only the specified concepts/paths are assumed to be valid. - - - - - Version of HDF (version 4) library used in writing the file - - - - - Version of HDF5 library used in writing the file. - - Note this attribute is spelled with uppercase "V", - different than other version attributes. - - - - - Version of XML support library used in writing the XML file - - - - - Version of h5py Python package used in writing the file - - - - - facility or program where file originated - - - - - Version of facility or program used in writing the file - - - - - entries - - - - - .. index:: find the default plottable data - .. index:: plotting - .. index:: default attribute value - - Declares which :ref:`NXentry` group contains - the data to be shown by default. - It is used to resolve ambiguity when - more than one :ref:`NXentry` group exists. - The value :ref:`names <validItemName>` the default :ref:`NXentry` group. The - value must be the name of a child of the current group. The child must be a - NeXus group or a link to a NeXus group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - + + + The root of any NeXus data file is an ``NXroot`` class + (no other choice is allowed for a valid NeXus data file). + This attribute cements that definition. + + + + + + + + Date and time file was originally created + + + + + File name of original NeXus file + + + + + Date and time of last file change at close + + + + + A repository containing the application definitions + used for creating this file. + If the NeXus_version attribute contains a commit distance and hash + this should refer to this repository. + + + + + Version of NeXus definitions used in writing the file. + This may either be a date based version tag of the form `vYYYY.MM` + or a version tag with a commit distance and source control (e.g., git) hash of + the form `vYYYY.MM.post1.dev<commit-distance>.g<git-hash>`. + It may contain an additional `.dYYYYMMDD` timestamp appendix + for dirty repositories. + If the version contains a commit distance and hash the + NeXus_repository attribute should be written with the + repository url containing this version. + + Only used when the NAPI or pynxtools has written the file. + Note that this is different from the version of the + base class or application definition version number. + + + + + A list of concepts in an application definition this file describes. + This is for partially filling an application definition. + If this attribute is not present the application definition is assumed + to be valid, if not only the specified concepts/paths are assumed to be valid. + + + + + Version of HDF (version 4) library used in writing the file + + + + + Version of HDF5 library used in writing the file. + + Note this attribute is spelled with uppercase "V", + different than other version attributes. + + + + + Version of XML support library used in writing the XML file + + + + + Version of h5py Python package used in writing the file + + + + + facility or program where file originated + + + + + Version of facility or program used in writing the file + + + + + entries + + + + + .. index:: find the default plottable data + .. index:: plotting + .. index:: default attribute value + + Declares which :ref:`NXentry` group contains + the data to be shown by default. + It is used to resolve ambiguity when + more than one :ref:`NXentry` group exists. + The value :ref:`names <validItemName>` the default :ref:`NXentry` group. The + value must be the name of a child of the current group. The child must be a + NeXus group or a link to a NeXus group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + + diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml index d74a053e0f..9a99d11165 100644 --- a/contributed_definitions/NXcalibration.nxdl.xml +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -22,170 +22,170 @@ # For further information, see http://www.nexusformat.org --> - + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of coefficients of the calibration function + + + + + Number of features used to fit the calibration function + + + + + Number of points of the calibrated and uncalibrated axes + + + - The symbols used in the schema to specify e.g. dimensions of arrays + Subclass of NXprocess to describe post-processing calibrations. - - - Number of coefficients of the calibration function - - - - - Number of features used to fit the calibration function - - - - - Number of points of the calibrated and uncalibrated axes - - - - - Subclass of NXprocess to describe post-processing calibrations. - - - - A description of the procedures employed. - - - - - A digital persistent identifier (e.g., doi, ISO standard) referring to a detailed description of a - calibration method but no actual calibration data. - - - - - A digital persistent identifier (e.g., a doi) referring to a - publicly available calibration measurement used for this instrument - , e.g., a measurement of a known standard containing calibration information. - The axis values may be copied or linked in the appropriate NXcalibration fields for reference. - - - - - A file serialisation of a calibration which may not be publicly available (externally from the nexus file). - - This metadata can be a documentation of the source (file) or database (entry) from which pieces - of information have been extracted for consumption in e.g. a research data management system (RDMS). - It is also possible to include the actual file by using the `file` field. - - The axis values may be copied or linked in the appropriate NXcalibration fields for reference. - - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the calibration been applied? - - - - - Vector containing the data coordinates in the original uncalibrated axis - - - - - - - The symbol of the axis to be used in the fit_function, e.g., `energy`, `E`. - This should comply to the following naming rules (similar to python's naming rules): - - * A variable name must start with a letter or the underscore character - * A variable name cannot start with a number - * A variable name can only contain alpha-numeric characters and underscores (A-z, 0-9, and _ ) - * Variable names are case-sensitive (age, Age and AGE are three different variables) - - - - - The path from which this data is derived, e.g., raw detector axis. - Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. - - - - - - Additional input axis to be used in the formula. - The part after `input_` is used as the symbol to be used in the `fit_function`, i.e., - if the field name is `input_my_field` you should refer to this axis by `my_field` in the `fit_function`. - - - - - - - The path from which this data is derived, e.g., raw detector axis. - Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. - - - - - - For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit - to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the array of fit coefficients. - - - - - - - - For non-linear energy calibrations. Here we can store the formula of the - fit function. - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - - Use x0, x1, ..., xn for the nth position in the `original_axis` field. - If there is the symbol attribute specified for the `original_axis` this may be used instead of x. - If you want to use the whole axis use `x`. - Alternate axis can also be available as specified by the `input_SYMBOL` field. - The data should then be referred here by the `SYMBOL` name, e.g., for a field - name `input_my_field` it should be referred here by `my_field` or `my_field0` if - you want to read the zeroth element of the array. - - The formula should be numpy compliant. - - - - - For linear calibration. Scaling parameter. - This is should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. - - - - - For linear calibration. Offset parameter. - This is should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. - - - - - Mapping data for calibration. - - This can be used to map data points from uncalibrated to calibrated values, - i.e., by multiplying each point in the input axis by the corresponding point in the mapping data. - - - - - A vector representing the axis after calibration, matching the data length - - - - - - - The path to which this data is written, e.g., the calibrated energy. - Should be a valid NeXus path name, e.g., /entry/data/energy. - - - + + + A description of the procedures employed. + + + + + A digital persistent identifier (e.g., doi, ISO standard) referring to a detailed description of a + calibration method but no actual calibration data. + + + + + A digital persistent identifier (e.g., a doi) referring to a + publicly available calibration measurement used for this instrument + , e.g., a measurement of a known standard containing calibration information. + The axis values may be copied or linked in the appropriate NXcalibration fields for reference. + + + + + A file serialisation of a calibration which may not be publicly available (externally from the nexus file). + + This metadata can be a documentation of the source (file) or database (entry) from which pieces + of information have been extracted for consumption in e.g. a research data management system (RDMS). + It is also possible to include the actual file by using the `file` field. + + The axis values may be copied or linked in the appropriate NXcalibration fields for reference. + + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Has the calibration been applied? + + + + + Vector containing the data coordinates in the original uncalibrated axis + + + + + + + The symbol of the axis to be used in the fit_function, e.g., `energy`, `E`. + This should comply to the following naming rules (similar to python's naming rules): + + * A variable name must start with a letter or the underscore character + * A variable name cannot start with a number + * A variable name can only contain alpha-numeric characters and underscores (A-z, 0-9, and _ ) + * Variable names are case-sensitive (age, Age and AGE are three different variables) + + + + + The path from which this data is derived, e.g., raw detector axis. + Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. + + + + + + Additional input axis to be used in the formula. + The part after `input_` is used as the symbol to be used in the `fit_function`, i.e., + if the field name is `input_my_field` you should refer to this axis by `my_field` in the `fit_function`. + + + + + + + The path from which this data is derived, e.g., raw detector axis. + Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. + + + + + + For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit + to a set of features (peaks) at well defined energy positions to determine + E(TOF). Here we can store the array of fit coefficients. + + + + + + + + For non-linear energy calibrations. Here we can store the formula of the + fit function. + + Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. + + Use x0, x1, ..., xn for the nth position in the `original_axis` field. + If there is the symbol attribute specified for the `original_axis` this may be used instead of x. + If you want to use the whole axis use `x`. + Alternate axis can also be available as specified by the `input_SYMBOL` field. + The data should then be referred here by the `SYMBOL` name, e.g., for a field + name `input_my_field` it should be referred here by `my_field` or `my_field0` if + you want to read the zeroth element of the array. + + The formula should be numpy compliant. + + + + + For linear calibration. Scaling parameter. + This is should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. + + + + + For linear calibration. Offset parameter. + This is should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. + + + + + Mapping data for calibration. + + This can be used to map data points from uncalibrated to calibrated values, + i.e., by multiplying each point in the input axis by the corresponding point in the mapping data. + + + + + A vector representing the axis after calibration, matching the data length + + + + + + + The path to which this data is written, e.g., the calibrated energy. + Should be a valid NeXus path name, e.g., /entry/data/energy. + + + diff --git a/contributed_definitions/NXidentifier.nxdl.xml b/contributed_definitions/NXidentifier.nxdl.xml index cd9689f133..ef77f87101 100644 --- a/contributed_definitions/NXidentifier.nxdl.xml +++ b/contributed_definitions/NXidentifier.nxdl.xml @@ -22,38 +22,38 @@ # For further information, see http://www.nexusformat.org --> - - An identifier for a (persistent) resource, e.g., a DOI or orcid. - - - The service by which the resouce can be resolved. - If the service is not in the list a simple `url` may be used. - The `url` can either be a resolving service for the `identifier` - or a fully qualified identification in itself. + An identifier for a (persistent) resource, e.g., a DOI or orcid. - - - - - - - - - - - - - The unique code, IRI or hash to resolve this reference. - Typically, this is stated by the service which is considered a complete - identifier, e.g., for a DOI it's something of the form `10.1107/S1600576714027575` - or `https://doi.org/10.1107/S1600576714027575`, which are both resolvable. - - - - - True if the identifier is persistent (i.e., unique and available indefinetely), - False otherwise. - - + + + The service by which the resouce can be resolved. + If the service is not in the list a simple `url` may be used. + The `url` can either be a resolving service for the `identifier` + or a fully qualified identification in itself. + + + + + + + + + + + + + + The unique code, IRI or hash to resolve this reference. + Typically, this is stated by the service which is considered a complete + identifier, e.g., for a DOI it's something of the form `10.1107/S1600576714027575` + or `https://doi.org/10.1107/S1600576714027575`, which are both resolvable. + + + + + True if the identifier is persistent (i.e., unique and available indefinetely), + False otherwise. + + diff --git a/contributed_definitions/NXserialized.nxdl.xml b/contributed_definitions/NXserialized.nxdl.xml index 70bf4e8424..50788ed914 100644 --- a/contributed_definitions/NXserialized.nxdl.xml +++ b/contributed_definitions/NXserialized.nxdl.xml @@ -22,55 +22,55 @@ # For further information, see http://www.nexusformat.org --> - - Metadata to a set of pieces of information of a resource that has been serialized. - - A typical use case is the documentation of the source (file) or database (entry) - from which pieces of information have been extracted for consumption in e.g. a - research data management system (RDMS). This may be for reasons of enabling - services such as providing access to normalized information for which reading - again from the resource may not be desired, possibe, or feasible. - - Possible reasons could be the extraction of specific information for caching, - performance reasons, or re-evaluate given pieces of information based on other - views and interaction patterns with the data where information has been formatted - differently by tools than how these pieces of information were originally - serialized. - - - Answers into what resource the information was serialized. - - - - - - - - - Path to the resource. + Metadata to a set of pieces of information of a resource that has been serialized. - E.g. the name of a file or its absolute or relative path, or the - identifier to a resource in another database. - - - - - Value of the checksum obtain when running algorithm on the resource. - - - - - Name of the algorithm whereby the checksum was computed. - - - - - - - - - Extracted file containing the serialized information. + A typical use case is the documentation of the source (file) or database (entry) + from which pieces of information have been extracted for consumption in e.g. a + research data management system (RDMS). This may be for reasons of enabling + services such as providing access to normalized information for which reading + again from the resource may not be desired, possibe, or feasible. + + Possible reasons could be the extraction of specific information for caching, + performance reasons, or re-evaluate given pieces of information based on other + views and interaction patterns with the data where information has been formatted + differently by tools than how these pieces of information were originally + serialized. - + + + Answers into what resource the information was serialized. + + + + + + + + + Path to the resource. + + E.g. the name of a file or its absolute or relative path, or the + identifier to a resource in another database. + + + + + Value of the checksum obtain when running algorithm on the resource. + + + + + Name of the algorithm whereby the checksum was computed. + + + + + + + + + Extracted file containing the serialized information. + + diff --git a/dev_tools/docs/nxdl.py b/dev_tools/docs/nxdl.py index c9e3ebed1c..c2dda67988 100755 --- a/dev_tools/docs/nxdl.py +++ b/dev_tools/docs/nxdl.py @@ -17,6 +17,10 @@ from ..utils.types import PathLike from .anchor_list import AnchorRegistry +# controlling the length of progressively more indented sub-node +MIN_COLLAPSE_HINT_LINE_LENGTH = 20 +MAX_COLLAPSE_HINT_LINE_LENGTH = 80 + class NXClassDocGenerator: """Generate documentation in reStructuredText markup @@ -519,24 +523,30 @@ def _print_doc(self, indent, ns, node, required=False): self._print(f"{indent}{line}") self._print() - def long_doc(self, ns, node): + def long_doc(self, ns, node, left_margin): length = 0 line = "documentation" fnd = False blocks = self._get_doc_blocks(ns, node) + max_characters = max( + MIN_COLLAPSE_HINT_LINE_LENGTH, (MAX_COLLAPSE_HINT_LINE_LENGTH - left_margin) + ) for block in blocks: lines = block.splitlines() length += len(lines) for single_line in lines: if len(single_line) > 2 and single_line[0] != "." and not fnd: fnd = True - line = single_line + line = single_line[:max_characters] return (length, line, blocks) def _print_doc_enum(self, indent, ns, node, required=False): collapse_indent = indent node_list = node.xpath("nx:enumeration", namespaces=ns) - (doclen, line, blocks) = self.long_doc(ns, node) + (doclen, line, blocks) = self.long_doc(ns, node, len(indent)) + if len(node_list) + doclen > 1: + collapse_indent = f"{indent} " + self._print(f"{indent}{self._INDENTATION_UNIT}.. collapse:: {line} ...\n") self._print_doc( collapse_indent + self._INDENTATION_UNIT, ns, node, required=required ) @@ -667,9 +677,8 @@ def _print(self, *args, end="\n"): self._rst_lines.append(" ".join(args) + end) def get_first_parent_ref(self, path, tag): - spliter = path.find("/", 1) - nx_name = path[1:spliter] - path = path[spliter:] + nx_name = path[1 : path.find("/", 1)] + path = path[path.find("/", 1) :] try: parents = pynxtools_nxlib.get_inherited_nodes(path, nx_name)[2] @@ -679,8 +688,11 @@ def get_first_parent_ref(self, path, tag): parent = parents[1] parent_path = parent_display_name = parent.attrib["nxdlpath"] parent_path_segments = parent_path[1:].split("/") - nxdl_attr = parent.attrib["nxdlbase"] - parent_def_name = nxdl_attr[nxdl_attr.rfind("/") : nxdl_attr.rfind(".nxdl")] + parent_def_name = parent.attrib["nxdlbase"][ + parent.attrib["nxdlbase"] + .rfind("/") : parent.attrib["nxdlbase"] + .rfind(".nxdl") + ] # Case where the first parent is a base_class if parent_path_segments[0] == "": diff --git a/dev_tools/nyaml2nxdl/README.md b/dev_tools/nyaml2nxdl/README.md deleted file mode 100644 index 51d9c2d862..0000000000 --- a/dev_tools/nyaml2nxdl/README.md +++ /dev/null @@ -1,112 +0,0 @@ -# YAML to NXDL converter and NXDL to YAML converter - -**NOTE: Please use python3.8 or above to run this converter** - -**Tools purpose**: Offer a simple YAML-based schema and a XML-based schema to describe NeXus instances. These can be NeXus application definitions or classes -such as base or contributed classes. Users either create NeXus instances by writing a YAML file or a XML file which details a hierarchy of data/metadata elements. -The forward (YAML -> NXDL.XML) and backward (NXDL.XML -> YAML) conversions are implemented. - -**How the tool works**: -- nyaml2nxdl.py -1. Reads the user-specified NeXus instance, either in YML or XML format. -2. If input is in YAML, creates an instantiated NXDL schema XML tree by walking the dictionary nest. - If input is in XML, creates a YML file walking the dictionary nest. -3. Write the tree into a YAML file or a properly formatted NXDL XML schema file to disk. -4. Optionally, if --append argument is given, - the XML or YAML input file is interpreted as an extension of a base class and the entries contained in it - are appended below a standard NeXus base class. - You need to specify both your input file (with YAML or XML extension) and NeXus class (with no extension). - Both .yaml and .nxdl.xml file of the extended class are printed. - -```console -user@box:~$ python nyaml2nxdl.py - -Usage: python nyaml2nxdl.py [OPTIONS] - -Options: - --input-file TEXT The path to the input data file to read. - --append TEXT Parse xml NeXus file and append to specified base class, - write the base class name with no extension. - --check-consistency Check consistency by generating another version of the input file. - E.g. for input file: NXexample.nxdl.xml the output file - NXexample_consistency.nxdl.xml. - --verbose Additional std output info is printed to help debugging. - --help Show this message and exit. - -``` - -## Documentation - -**Rule set**: From transcoding YAML files we need to follow several rules. -* Named NeXus groups, which are instances of NeXus classes especially base or contributed classes. Creating (NXbeam) is a simple example of a request to define a group named according to NeXus default rules. mybeam1(NXbeam) or mybeam2(NXbeam) are examples how to create multiple named instances at the same hierarchy level. -* Members of groups so-called fields or attributes. A simple example of a member is voltage. Here the datatype is implied automatically as the default NeXus NX_CHAR type. By contrast, voltage(NX_FLOAT) can be used to instantiate a member of class which should be of NeXus type NX_FLOAT. -* And attributes of either groups or fields. The mark '\@' have to precede the name of attributes. -* Optionality: For all fields, groups and attributes in `application definitions` are `required` by default, except anything (`recommended` or `optional`) mentioned. - -**Special keywords**: Several keywords can be used as children of groups, fields, and attributes to specify the members of these. Groups, fields and attributes are nodes of the XML tree. -* **doc**: - - A human-readable description/docstring - - Doc string may also come as a list of doc parts when user wants to add `reference` for a concept. Or doc string could be a single doc block. - ```yaml - energy: # field - doc: - - | - Part1 of the entire doc. - part1 of the entire doc. - - | # Reference for concept - xref: - spec: - term: - url: " - - | - Rest of the doc - rest of the doc - velocity: # field - doc: | - A single block of doc string. - ``` - Such structure of doc would appear in `nxdl` as - ```xml - ... - - - Part1 of the entire doc. - part1 of the entire doc. - - This concept is related to term `<term>`_ of the <spec> standard. - .. _<term>: <url> - - Rest of the doc - rest of the doc - - - - - A single block of doc string. - - - ``` - - - -* **exists** Options are recommended, required, [min, 1, max, `infty`] numbers like here 1 can be replaced by any `uint` (unsigned integer), or `infty` to indicate no restriction on how frequently the entry can occur inside the NXDL schema at the same hierarchy level. -* **link** Define links between nodes. -* **units** A statement introducing NeXus-compliant NXDL units arguments, like NX_VOLTAGE -* **dimensions** Details which dimensional arrays to expect -* **enumeration** Python list of strings which are considered as recommended entries to choose from. -* **dim_parameters** `dim` which is a child of `dimension` and the `dim` might have several attributes `ref`, -`incr` including `index` and `value`. So while writing `yaml` file schema definition please following structure: -```yaml -dimensions: - rank: integer value - dim: [[ind_1, val_1], [ind_2, val_2], ...] - dim_parameters: - ref: [ref_value_1, ref_value_2, ...] - incr: [incr_value_1, incr_value_2, ...] -``` -Keep in mind that length of all the lists must have the **same size**. -**Important Note**: The attributes `ref`, `incr`, `index` are deprecated. - -## Next steps - -The NOMAD team is currently working to establish a one-to-one mapping between NeXus definitions and the NOMAD MetaInfo(scientific data model in nomad). As soon as this is in place the YAML files will be annotated with further metadata so that they can serve two purposes. On the one hand they can serve as an instance for a schema to create a GUI representation of a NOMAD Oasis ELN schema. On the other hand the YAML to NXDL converter will skip all those pieces of information which are irrelevant from a NeXus perspective. diff --git a/dev_tools/nyaml2nxdl/__init__.py b/dev_tools/nyaml2nxdl/__init__.py deleted file mode 100644 index d0f7a80f2f..0000000000 --- a/dev_tools/nyaml2nxdl/__init__.py +++ /dev/null @@ -1,21 +0,0 @@ -""" -# Load paths -""" -# -*- coding: utf-8 -*- -# -# 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. -# diff --git a/dev_tools/nyaml2nxdl/comment_collector.py b/dev_tools/nyaml2nxdl/comment_collector.py deleted file mode 100644 index 6ded2f3720..0000000000 --- a/dev_tools/nyaml2nxdl/comment_collector.py +++ /dev/null @@ -1,516 +0,0 @@ -#!usr/bin/env python3 -# -*- coding: utf-8 -*- -# -# 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. -# - -""" -Collect comments in a list by CommentCollector class and each comment is an instance of Comment -class. Each `Comment` instance(sometimes refered as 'comment block') consists of text and line -info or neighbours info where the comment must be placed. - -The class Comment is an abstract class for general functions or method to be implemented -XMLComment and YAMLComment class. -""" - - -from typing import Any -from typing import Dict -from typing import List -from typing import Tuple -from typing import Type -from typing import Union - -from .nyaml2nxdl_helper import LineLoader - -__all__ = ["Comment", "CommentCollector", "XMLComment", "YAMLComment"] - - -# pylint: disable=inconsistent-return-statements -class CommentCollector: - """CommentCollector will store a full comment ('Comment') object in - _comment_chain. - """ - - def __init__(self, input_file: str = None, loaded_obj: Union[object, Dict] = None): - """ - Initialise CommentCollector - parameters: - input_file: raw input file (xml, yml) - loaded_obj: file loaded by third party library - """ - self._comment_chain: List = [] - self.file = input_file - self._comment_tracker = 0 - self._comment_hash: Dict[Tuple, Type[Comment]] = {} - self.comment: Type[Comment] - if self.file and not loaded_obj: - if self.file.endswith(".xml"): - self.comment = XMLComment - elif self.file.split(".")[-1] == "yaml": - self.comment = YAMLComment - with open(self.file, "r", encoding="utf-8") as plain_text_yaml: - loader = LineLoader(plain_text_yaml) - self.comment.__yaml_dict__ = loader.get_single_data() - else: - raise ValueError("Input file must be a 'yaml' or 'nxdl.xml' type.") - elif self.file and loaded_obj: - if self.file.split(".")[-1] == "yaml" and isinstance(loaded_obj, dict): - self.comment = YAMLComment - self.comment.__yaml_dict__ = loaded_obj - else: - raise ValueError( - "Incorrect inputs for CommentCollector e.g. Wrong file extension." - ) - - else: - raise ValueError("Incorrect inputs for CommentCollector") - - def extract_all_comment_blocks(self): - """Collect all comments. - - Note here that comment means (comment text + element or line info - intended for comment. - """ - id_ = 0 - single_comment = self.comment(comment_id=id_) - with open(self.file, mode="r", encoding="UTF-8") as enc_f: - lines = enc_f.readlines() - # Make an empty line for last comment if no empty lines in original file - if lines[-1] != "": - lines.append("") - end_line_num = len(lines) - 1 - for line_num, line in enumerate(lines): - if single_comment.is_storing_single_comment(): - # If the last comment comes without post nxdl fields, groups and attributes - if "++ SHA HASH ++" in line: - # Handle with stored nxdl.xml file that is not part of yaml - single_comment.process_each_line("post_comment", (line_num + 1)) - self._comment_chain.append(single_comment) - break - if line_num < end_line_num: - # Processing file from Line number 1 - single_comment.process_each_line(line, (line_num + 1)) - else: - # For processing last line of file - single_comment.process_each_line( - line + "post_comment", (line_num + 1) - ) - self._comment_chain.append(single_comment) - else: - self._comment_chain.append(single_comment) - single_comment = self.comment(last_comment=single_comment) - single_comment.process_each_line(line, (line_num + 1)) - - def get_next_comment(self): - """ - Return comment from comment_chain that must come earlier in order. - """ - return self._comment_chain[self._comment_tracker] - - def get_comment_by_line_info(self, comment_locs: Tuple[str, Union[int, str]]): - """ - Get comment using line information. - """ - if comment_locs in self._comment_hash: - return self._comment_hash[comment_locs] - - line_annot, line_loc = comment_locs - for cmnt in self._comment_chain: - if line_annot in cmnt: - line_loc_ = cmnt.get_line_number(line_annot) - if line_loc == line_loc_: - self._comment_hash[comment_locs] = cmnt - return cmnt - - def remove_comment(self, ind): - """Remove a comment from comment list.""" - if ind < len(self._comment_chain): - del self._comment_chain[ind] - else: - raise ValueError("Oops! Index is out of range.") - - def reload_comment(self): - """ - Update self._comment_tracker after done with last comment. - """ - self._comment_tracker += 1 - - def __contains__(self, comment_locs: tuple): - """ - Confirm wether the comment corresponds to key_line and line_loc - is exist or not. - comment_locs is equvalant to (line_annotation, line_loc) e.g. - (__line__doc and 35) - """ - if not isinstance(comment_locs, tuple): - raise TypeError( - "Comment_locs should be 'tuple' containing line annotation " - "(e.g.__line__doc) and line_loc (e.g. 35)." - ) - line_annot, line_loc = comment_locs - for cmnt in self._comment_chain: - if line_annot in cmnt: - line_loc_ = cmnt.get_line_number(line_annot) - if line_loc == line_loc_: - self._comment_hash[comment_locs] = cmnt - return True - return False - - def __getitem__(self, ind): - """Get comment from self.obj._comment_chain by index.""" - if isinstance(ind, int): - if ind >= len(self._comment_chain): - raise IndexError( - f"Oops! Comment index {ind} in {__class__} is out of range!" - ) - return self._comment_chain[ind] - - if isinstance(ind, slice): - start_n = ind.start or 0 - end_n = ind.stop or len(self._comment_chain) - return self._comment_chain[start_n:end_n] - - def __iter__(self): - """get comment ieratively""" - return iter(self._comment_chain) - - -# pylint: disable=too-many-instance-attributes -class Comment: - """ - This class is building yaml comment and the intended line for what comment is written. - """ - - def __init__(self, comment_id: int = -1, last_comment: "Comment" = None) -> None: - """Comment object can be considered as a block element that includes - document element (an entity for what the comment is written). - """ - self._elemt: Dict[str, Any] = {} - self._elemt_text: str = None - self._is_elemt_found: bool = None - self._is_elemt_stored: bool = None - - self._comnt: str = "" - # If Multiple comments for one element or entity - self._comnt_list: List[str] = [] - self.last_comment: "Comment" = last_comment if last_comment else None - if comment_id >= 0 and last_comment: - self.cid = comment_id - self.last_comment = last_comment - elif comment_id == 0 and not last_comment: - self.cid = comment_id - self.last_comment = None - elif last_comment: - self.cid = self.last_comment.cid + 1 - self.last_comment = last_comment - else: - raise ValueError("Neither last comment nor comment id dound") - self._comnt_start_found: bool = False - self._comnt_end_found: bool = False - self.is_storing_single_comment = lambda: not ( - self._comnt_end_found and self._is_elemt_stored - ) - - def get_comment_text_list(self) -> Union[List, str]: - """ - Extract comment text from entrire comment (comment text + elment or - line for what comment is intended) - """ - - def append_comment(self, text: str) -> None: - """ - Append lines of the same comment. - """ - - def store_element(self, args) -> None: - """ - Strore comment text and line or element that is intended for comment. - """ - - -class XMLComment(Comment): - """ - XMLComment to store xml comment element. - """ - - def __init__(self, comment_id: int = -1, last_comment: "Comment" = None) -> None: - super().__init__(comment_id, last_comment) - - def process_each_line(self, text, line_num): - """Take care of each line of text. Through which function the text - must be passed should be decide here. - """ - text = text.strip() - if text and line_num: - self.append_comment(text) - if self._comnt_end_found and not self._is_elemt_found: - # for multiple comment if exist - if self._comnt: - self._comnt_list.append(self._comnt) - self._comnt = "" - - if self._comnt_end_found: - self.store_element(text) - - def append_comment(self, text: str) -> None: - # Comment in single line - if "" == text[-4:]: - self._comnt_end_found = True - self._comnt_start_found = False - self._comnt = self._comnt.replace("-->", "") - - elif "-->" == text[0:4] and self._comnt_start_found: - self._comnt_end_found = True - self._comnt_start_found = False - self._comnt = self._comnt + "\n" + text.replace("-->", "") - elif self._comnt_start_found: - self._comnt = self._comnt + "\n" + text - - # pylint: disable=arguments-differ, arguments-renamed - def store_element(self, text) -> None: - def collect_xml_attributes(text_part): - for part in text_part: - part = part.strip() - if part and part.endswith('">'): - self._is_elemt_stored = True - self._is_elemt_found = False - part = part[0:-2] - elif part and part.endswith('"/>'): - self._is_elemt_stored = True - self._is_elemt_found = False - part = part[0:-3] - elif part and part.endswith("/>"): - self._is_elemt_stored = True - self._is_elemt_found = False - part = part[0:-2] - elif part and part.endswith(">"): - self._is_elemt_stored = True - self._is_elemt_found = False - part = part[0:-1] - elif part and part.endswith('"'): - part = part[0:-1] - - if '="' in part: - lf_prt, rt_prt = part.split('="') - if ":" in lf_prt: - continue - else: - continue - self._elemt[lf_prt] = str(rt_prt) - - if not self._elemt: - self._elemt = {} - # First check for comment part has been collected prefectly - if text.startswith(" Union[List, str]: - """ - This method returns list of commnent text. As some xml element might have - multiple separated comment intended for a single element. - """ - return self._comnt_list - - -class YAMLComment(Comment): - """ - This class for storing comment text as well as location of the comment e.g. line - number of other in the file. - NOTE: - 1. Do not delete any element from yaml dictionary (for loaded_obj. check: Comment_collector - class. because this loaded file has been exploited in nyaml2nxdl forward tools.) - """ - - # Class level variable. The main reason behind that to follow structure of - # abstract class 'Comment' - __yaml_dict__: dict = {} - __yaml_line_info: dict = {} - __comment_escape_char = {"--": "-\\-"} - - def __init__(self, comment_id: int = -1, last_comment: "Comment" = None) -> None: - """Initialization of YAMLComment follow Comment class.""" - super().__init__(comment_id, last_comment) - self.collect_yaml_line_info( - YAMLComment.__yaml_dict__, YAMLComment.__yaml_line_info - ) - - def process_each_line(self, text, line_num): - """Process each line. - - Take care of each line of text. Through which function the text - must be passed should be decide here. - """ - text = text.strip() - self.append_comment(text) - if self._comnt_end_found and not self._is_elemt_found: - if self._comnt: - self._comnt_list.append(self._comnt) - self._comnt = "" - - if self._comnt_end_found: - line_key = "" - ind = text.find(":") - if ind > 0: - line_key = "__line__" + text[0:ind] - - for l_num, l_key in self.__yaml_line_info.items(): - if line_num == int(l_num) and line_key == l_key: - self.store_element(line_key, line_num) - break - # Comment comes very end of the file - if text == "post_comment" and line_key == "": - line_key = "__line__post_comment" - self.store_element(line_key, line_num) - - def has_post_comment(self): - """Ensure if this is a post comment or not. - - Post comment means the comment that comes at the very end without having any - nxdl element(class, group, filed and attribute.). - """ - for key, _ in self._elemt.items(): - if "__line__post_comment" == key: - return True - return False - - def append_comment(self, text: str) -> None: - """Append comment texts to the associated comment. - - Collects all the line of the same comment and - append them with that single comment. - """ - # check for escape char - text = self.replace_escape_char(text) - # Empty line after last line of comment - if not text and self._comnt_start_found: - self._comnt_end_found = True - self._comnt_start_found = False - # For empty line inside doc or yaml file. - elif not text: - return - elif text.startswith("# "): - self._comnt_start_found = True - self._comnt_end_found = False - self._comnt = "" if not self._comnt else self._comnt + "\n" - self._comnt = self._comnt + text[2:] - elif text.startswith("#"): - self._comnt_start_found = True - self._comnt_end_found = False - self._comnt = "" if not self._comnt else self._comnt + "\n" - self._comnt = self._comnt + text[1:] - elif "post_comment" == text: - self._comnt_end_found = True - self._comnt_start_found = False - # for any line after 'comment block' found - elif self._comnt_start_found: - self._comnt_start_found = False - self._comnt_end_found = True - - # pylint: disable=arguments-differ - def store_element(self, line_key, line_number): - """Store comment contents and information of comment location.""" - self._elemt = {} - self._elemt[line_key] = int(line_number) - self._is_elemt_found = False - self._is_elemt_stored = True - - def get_comment_text_list(self): - """ - Return list of comments. - """ - return self._comnt_list - - def get_line_number(self, line_key): - """ - Return line no for which line the comment is created. - """ - return self._elemt[line_key] - - def get_line_info(self): - """ - Return line annotation and line number from a comment. - """ - for line_anno, line_loc in self._elemt.items(): - return line_anno, line_loc - - def replace_escape_char(self, text): - """Replace escape char according to __comment_escape_char dict""" - for ecp_char, ecp_alt in YAMLComment.__comment_escape_char.items(): - text = text.replace(ecp_char, ecp_alt) - return text - - def get_element_location(self): - """Return yaml line '__line__' info and and line numner""" - if len(self._elemt) == 0: - raise ValueError( - f"Comment element should be one or more but got {self._elemt}" - ) - return next(self._elemt.items()) - - def collect_yaml_line_info(self, yaml_dict, line_info_dict): - """Collect __line__key and corresponding value from - a yaml file dictonary in another dictionary. - """ - for line_key, line_n in yaml_dict.items(): - if "__line__" in line_key: - line_info_dict[line_n] = line_key - - for _, val in yaml_dict.items(): - if isinstance(val, dict): - self.collect_yaml_line_info(val, line_info_dict) - - def __contains__(self, line_key): - """For checking whether __line__ is in _elemt dict or not.""" - return line_key in self._elemt - - def __eq__(self, comment_obj): - """Check the self has same value as right comment.""" - if not isinstance(comment_obj, Comment): - raise TypeError(f"Expecting comment_obj as a instance of {Comment}") - if len(self._comnt_list) != len(comment_obj._comnt_list): - return False - for left_cmnt, right_cmnt in zip(self._comnt_list, comment_obj._comnt_list): - left_cmnt = left_cmnt.split("\n") - right_cmnt = right_cmnt.split("\n") - for left_line, right_line in zip(left_cmnt, right_cmnt): - if left_line.strip() != right_line.strip(): - return False - return True diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl.py b/dev_tools/nyaml2nxdl/nyaml2nxdl.py deleted file mode 100755 index 4031d6bbdf..0000000000 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl.py +++ /dev/null @@ -1,164 +0,0 @@ -#!/usr/bin/env python3 -""" -Main file of nyaml2nxdl tool. - -To write a definition for a instrument, experiment and/or process in nxdl.xml file from a YAML -file which details a hierarchy of data/metadata elements. It also allows both wa -conversion beteen YAML and nxdl.xml files that follows rules of NeXus ontology or data format. -""" -# -*- coding: utf-8 -*- -# -# 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. -# -from pathlib import Path - -import click - -from .nyaml2nxdl_backward_tools import Nxdl2yaml -from .nyaml2nxdl_forward_tools import nyaml2nxdl -from .nyaml2nxdl_helper import extend_yamlfile_by_nxdl_as_comment -from .nyaml2nxdl_helper import get_sha256_hash -from .nyaml2nxdl_helper import separate_hash_yaml_and_nxdl - -DEPTH_SIZE = 4 * " " -_nxdl = ".nxdl.xml" - -# NOTE: Some handful links for nyaml2nxdl converter: -# https://manual.nexusformat.org/nxdl_desc.html?highlight=optional - - -def generate_nxdl_or_retrieve_nxdl(yaml_file, out_xml_file, verbose): - """ - Generate yaml, nxdl and hash. - - If the extracted hash is exactly the same as produced from generated yaml then - retrieve the nxdl part from provided yaml. - Else, generate nxdl from separated yaml with the help of nyaml2nxdl function - """ - file_path = Path(yaml_file) - pa_path, rel_file = file_path.parent, file_path.name - sep_yaml = (pa_path / f"temp_{rel_file}").as_posix() - hash_found = separate_hash_yaml_and_nxdl(yaml_file, sep_yaml, out_xml_file) - - if hash_found: - gen_hash = get_sha256_hash(sep_yaml) - if hash_found == gen_hash: - Path(sep_yaml).unlink() - return - - nyaml2nxdl(sep_yaml, out_xml_file, verbose) - Path(sep_yaml).unlink() - - -def split_name_and_extension(file_path): - """ - Split file name into extension and rest of the file name. - - return file raw name and extension - """ - path = Path(file_path) - ext = "".join(path.suffixes) - full_path_stem = file_path[0 : file_path.index(ext)] - return full_path_stem, ext[1:] - - -@click.command() -@click.option( - "--input-file", - required=True, - prompt=True, - help="The path to the XML or YAML input data file to read and create \ -a YAML or XML file from, respectively.", -) -@click.option( - "--check-consistency", - is_flag=True, - default=False, - help=( - "Check if yaml and nxdl can be converted from one to another version recursively and" - " get the same version of file. E.g. from NXexample.nxdl.xml to NXexample_consistency.nxdl.xml." - ), -) -@click.option( - "--do-not-store-nxdl", - is_flag=True, - default=False, - help=( - "Whether the input nxdl file will be stored as a comment" - " at the end of output yaml file." - ), -) -@click.option( - "--verbose", - is_flag=True, - default=False, - help="Print in standard output keywords and value types to help \ -possible issues in yaml files", -) -# def launch_tool(input_file, verbose, check_consistency): -def launch_tool(input_file, verbose, do_not_store_nxdl, check_consistency): - """ - Main function that distinguishes the input file format and launches the tools. - """ - - if Path(input_file).is_file(): - raw_name, ext = split_name_and_extension(input_file) - else: - raise ValueError("Need a valid input file.") - if ext == "yaml": - xml_out_file = raw_name + _nxdl - generate_nxdl_or_retrieve_nxdl(input_file, xml_out_file, verbose) - - # For consistency running - if check_consistency: - yaml_out_file = raw_name + "_consistency." + ext - converter = Nxdl2yaml([], []) - converter.print_yml(xml_out_file, yaml_out_file, verbose) - Path(xml_out_file).unlink() - elif ext == "nxdl.xml": - # if not append: - yaml_out_file = raw_name + "_parsed" + ".yaml" - converter = Nxdl2yaml([], []) - converter.print_yml(input_file, yaml_out_file, verbose) - # Store nxdl.xml file in output yaml file under SHA HASH - yaml_hash = get_sha256_hash(yaml_out_file) - # Lines as divider between yaml and nxdl - top_lines = [ - ( - "\n# ++++++++++++++++++++++++++++++++++ SHA HASH" - " ++++++++++++++++++++++++++++++++++\n" - ), - f"# {yaml_hash}\n", - ] - if not do_not_store_nxdl: - extend_yamlfile_by_nxdl_as_comment( - yaml_file=yaml_out_file, - file_to_be_appended=input_file, - top_lines_list=top_lines, - ) - - # Taking care of consistency running - if check_consistency: - xml_out_file = raw_name + "_consistency." + ext - generate_nxdl_or_retrieve_nxdl(yaml_out_file, xml_out_file, verbose) - Path.unlink(yaml_out_file) - else: - raise ValueError("Provide correct file with extension '.yaml or '.nxdl.xml") - - -if __name__ == "__main__": - launch_tool().parse() # pylint: disable=no-value-for-parameter diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py b/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py deleted file mode 100755 index e30ddcf3f0..0000000000 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl_backward_tools.py +++ /dev/null @@ -1,1008 +0,0 @@ -#!/usr/bin/env python3 -"""This file collects the functions for conversion from nxdl.xml to yaml version. -""" - -# -*- coding: utf-8 -*- -# -# 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. -# - -import re -import textwrap -from pathlib import Path -from typing import Callable -from typing import Dict -from typing import List - -import lxml.etree as ET - -from .nyaml2nxdl_helper import NXDL_ATTRIBUTES_ATTRIBUTES -from .nyaml2nxdl_helper import NXDL_FIELD_ATTRIBUTES -from .nyaml2nxdl_helper import NXDL_GROUP_ATTRIBUTES -from .nyaml2nxdl_helper import NXDL_LINK_ATTRIBUTES -from .nyaml2nxdl_helper import clean_empty_lines -from .nyaml2nxdl_helper import get_node_parent_info -from .nyaml2nxdl_helper import get_yaml_escape_char_dict -from .nyaml2nxdl_helper import is_dom_comment -from .nyaml2nxdl_helper import remove_namespace_from_tag - -DEPTH_SIZE = " " -CMNT_TAG = "!--" -CMNT_TAG_END = "--" -CMNT_START = "" -DEFINITION_CATEGORIES = ("category: application", "category: base") - - -def separate_pi_comments(input_file): - """Separate PI comments from ProcessesInstruction (PI). - - ProcessesInstruction refers xml element process and version - Separate the comments that comes immediately after XML process instruction part, - i.e. copyright comment part. - """ - comments_list = [] - comment = [] - - with open(input_file, "r", encoding="utf-8") as file: - lines = file.readlines() - def_tag = " 0: - comment.append(line.replace(CMNT_END, "")) - comments_list.append("".join(comment)) - comment.clear() - elif len(comment) > 0: - comment.append(line) - elif def_tag in line: - break - return comments_list - - -# Collected: https://dustinoprea.com/2019/01/22/python-parsing-xml-and-retaining-the-comments/ -class _CommentedTreeBuilder(ET.TreeBuilder): - def start(self, tag, attrs): - super().start(tag=tag, attrs=attrs) - - def Comment(self, text): - """Defining comment builder in TreeBuilder""" - self.start(CMNT_TAG, {}) - self.data(text) - self.end(CMNT_TAG_END) - - -def parse(filepath): - """Parse xml function. - - Construct parser function for modified tree builder for including modified TreeBuilder - and rebuilding XMLParser. - """ - comments = separate_pi_comments(filepath) - ctb = _CommentedTreeBuilder() - xp_parser = ET.XMLParser(target=ctb, encoding="UTF-8") - root = ET.parse(filepath, xp_parser) - return comments, root - - -def handle_mapping_char(text, depth=-1, skip_n_line_on_top=False): - """Check for escape character and replace by alternative character.""" - - escape_char = get_yaml_escape_char_dict() - for esc_key, val in escape_char.items(): - if esc_key in text: - text = text.replace(esc_key, val) - if not skip_n_line_on_top: - if depth > 0: - text = add_new_line_with_pipe_on_top(text, depth) - else: - raise ValueError("Need depth size to co-ordinate text line in yaml file.") - return text - - -def add_new_line_with_pipe_on_top(text, depth): - """Design docs block. - - Restructure the text by adding pipe '|' and '\n' char if ':' is found in text. - """ - char = ":" - if char in text: - return "|" + "\n" + depth * DEPTH_SIZE + text - return text - - -# pylint: disable=too-many-instance-attributes -class Nxdl2yaml: - """Parse XML file and print a YML file.""" - - def __init__( - self, - symbol_list: List[str], - root_level_definition: List[str], - root_level_doc="", - root_level_symbols="", - ): - # updated part of yaml_dict - self.found_definition = False - self.root_level_doc = root_level_doc - self.root_level_symbols = root_level_symbols - self.root_level_definition = root_level_definition - self.symbol_list = symbol_list - self.include_comment = True - self.pi_comments = None - # NOTE: Here is how root_level_comments organised for storing comments - # root_level_comment= {'root_doc': comment, - # 'symbols': comment, - # The 'symbol_doc_comments' list is for comments from all 'symbol doc' - # 'symbol_doc_comments' : [comments] - # 'symbol_list': [symbols], - # The 'symbol_comments' contains comments for 'symbols doc' and all 'symbol' - # 'symbol_comments': [comments]} - self.root_level_comment: Dict[str, str] = {} - - self.optionality_keys = ( - "minOccurs", - "maxOccurs", - "optional", - "recommended", - "required", - ) - # "Take care of general attributes. Note other choices may be allowed in the future" - self.choice_allowed_attr = () - - def print_yml(self, input_file, output_yml, verbose): - """Parse an XML file provided as input and print a YML file.""" - output_file_path = Path(output_yml) - if output_file_path.is_file(): - output_file_path.unlink() - - depth = 0 - - self.pi_comments, root = parse(input_file) - xml_tree = {"tree": root, "node": root} - self.xmlparse(output_yml, xml_tree, depth, verbose) - - def handle_symbols(self, depth, node): - """Handle symbols field and its childs symbol""" - - self.root_level_symbols = ( - f"{remove_namespace_from_tag(node.tag)}: " - f"{node.text.strip() if node.text else ''}" - ) - depth += 1 - last_comment = "" - sbl_doc_cmnt_list = [] - # Comments that come above symbol tag - symbol_cmnt_list = [] - for child in list(node): - tag = remove_namespace_from_tag(child.tag) - if tag == CMNT_TAG and self.include_comment: - last_comment = self.convert_to_yaml_comment(depth, child.text) - if tag == "doc": - symbol_cmnt_list.append(last_comment) - # The line below is for handling length of 'symbol_comments' and - # 'symbol_doc_comments'. Otherwise print_root_level_info() gets inconsistency - # over for the loop while writing comment on file - sbl_doc_cmnt_list.append("") - last_comment = "" - self.symbol_list.append( - self.handle_not_root_level_doc(depth, text=child.text) - ) - elif tag == "symbol": - # place holder is symbol name - symbol_cmnt_list.append(last_comment) - last_comment = "" - if "doc" in child.attrib: - self.symbol_list.append( - self.handle_not_root_level_doc( - depth, tag=child.attrib["name"], text=child.attrib["doc"] - ) - ) - else: - for symbol_doc in list(child): - tag = remove_namespace_from_tag(symbol_doc.tag) - if tag == CMNT_TAG and self.include_comment: - last_comment = self.convert_to_yaml_comment( - depth, symbol_doc.text - ) - if tag == "doc": - sbl_doc_cmnt_list.append(last_comment) - last_comment = "" - self.symbol_list.append( - self.handle_not_root_level_doc( - depth, - tag=child.attrib["name"], - text=symbol_doc.text, - ) - ) - self.store_root_level_comments("symbol_doc_comments", sbl_doc_cmnt_list) - self.store_root_level_comments("symbol_comments", symbol_cmnt_list) - - def store_root_level_comments(self, holder, comment): - """Store yaml text or section line and the comments inteded for that lines or section""" - - self.root_level_comment[holder] = comment - - def handle_definition(self, node): - """Handle definition group and its attributes. - - NOTE: Here we try to store the order of the xml element attributes, so that we get - the same order in nxdl from yaml. - """ - keyword = "" - # tmp_word for reseving the location - tmp_word = "#xx#" - attribs = node.attrib - # for tracking the order of name and type - keyword_order = -1 - for item in attribs: - if "name" == item: - keyword = keyword + attribs[item] - if keyword_order == -1: - self.root_level_definition.append(tmp_word) - keyword_order = self.root_level_definition.index(tmp_word) - elif "extends" == item: - keyword = f"{keyword}({attribs[item]})" - if keyword_order == -1: - self.root_level_definition.append(tmp_word) - keyword_order = self.root_level_definition.index(tmp_word) - elif "schemaLocation" not in item and "extends" != item: - text = f"{item}: {attribs[item]}" - self.root_level_definition.append(text) - self.root_level_definition[keyword_order] = f"{keyword}:" - - def handle_root_level_doc(self, node): - """ - Handle the documentation field found at root level. - """ - text = self.handle_not_root_level_doc(depth=0, text=node.text) - self.root_level_doc = text - - def clean_and_organise_text(self, text, depth): - """Reconstruct text from doc and comment. - - Cleaninig up unintentional and accidental empty lines and spaces. - """ - # Handling empty doc - if not text: - text = "" - else: - text = handle_mapping_char(text, -1, True) - if "\n" in text: - # To remove '\n' with non-space character as it will be added before text. - text = clean_empty_lines(text.split("\n")) - text_tmp = [] - yaml_indent_n = len((depth + 1) * DEPTH_SIZE) - - # Find indentation in the first line of text having alphabet - first_line_indent_n = 0 - for line in text: - # Consider only the lines that has at least one non-space character - # and skip starting lines of a text block are empty - if len(line.lstrip()) != 0: - first_line_indent_n = len(line) - len(line.lstrip()) - break - # Taking care of doc like below: - # Text lines - # text continues - # So no indentation at the start of doc. So doc group will come along general - # alignment - if first_line_indent_n == 0: - first_line_indent_n = yaml_indent_n - - # for indent_diff -ve all lines will move left by the same amount - # for indent_diff +ve all lines will move right by the same amount - indent_diff = yaml_indent_n - first_line_indent_n - # CHeck for first line empty if not keep first line empty - - for line in text: - line_indent_n = 0 - # count first empty spaces without alphabet - line_indent_n = len(line) - len(line.lstrip()) - line_indent_n = line_indent_n + indent_diff - if line_indent_n < yaml_indent_n: - # if line still under yaml identation - text_tmp.append(yaml_indent_n * " " + line.strip()) - else: - text_tmp.append(line_indent_n * " " + line.strip()) - - text = "\n" + "\n".join(text_tmp) - - elif text: - text = "\n" + (depth + 1) * DEPTH_SIZE + text.strip() - - return text - - def check_and_handle_doc_xref_and_other_doc(self, text, indent): - """Check for xref doc which comes as a block of text. - - The doc part below is the example how xref comes: - ''' - This concept is related to term ``_ of the standard. - .. _: - ''' - converter as - ''' - "xref: - xpec: - erm: - url: " - ''' - - Parameters - ---------- - text: str - plain text. - Returns - ------- - str - return part of doc as formatted - """ - - xref_key, spec_key, term_key, url_key = ("xref", "spec", "term", "url") - spec, term, url = (None, None, None) - matches = re.search( - r"This concept is related to term `([^`:]+)`_ of the" - r" (.*?) standard\.\s+\.\. _\1: ([^\s]+)", - text, - ) - if matches: - term = matches.group(1) - spec = matches.group(2) - url = matches.group(3) - indent = indent + DEPTH_SIZE # see example in func doc - return ( - f'{indent}"{xref_key}:\n{indent + DEPTH_SIZE}{spec_key}: {spec}' - f"\n{indent + DEPTH_SIZE}{term_key}" - f': {term}\n{indent + DEPTH_SIZE}{url_key}: {url}"' - ) - return text - - # pylint: disable=too-many-branches - def handle_not_root_level_doc(self, depth, text, tag="doc", file_out=None): - """Handle docs field of group and field but not root. - - Handle docs field along the yaml file. In this function we also tried to keep - the track of indentation. E.g. the below doc block. - * Topic name - Description of topic - """ - if "}" in tag: - tag = remove_namespace_from_tag(tag) - indent = depth * DEPTH_SIZE - text = self.clean_and_organise_text(text, depth) # starts with '\n' - docs = re.split(r"\n\s*\n", text) - modified_docs = [] - for doc_part in docs: - if not doc_part.isspace(): - modified_docs.append( - self.check_and_handle_doc_xref_and_other_doc(doc_part, indent) - ) - # doc example: - # doc: - # - | - # text - # - | - # xref: - # spec: - # term: - if len(modified_docs) > 1: - doc_str = f"{indent}{tag}:\n" - for mod_doc in modified_docs: - if not re.match( - r"^\s*\n", mod_doc - ): # if not starts with 'spaces and/or \n' - mod_doc = "\n" + mod_doc - # doc_str = f"{doc_str}{indent} - |\n{textwrap.indent(mod_doc, indent+' ')}\n" - doc_str = f"{doc_str}{indent} - |{textwrap.indent(mod_doc, '')}\n" - elif len(modified_docs) == 1: - doc_str = f"{indent}{tag}: |{modified_docs[0]}\n" - else: - doc_str = f"{indent}{tag}: |{text}\n" - - if file_out: - file_out.write(doc_str) - return None - return doc_str - - def write_out(self, indent, text, file_out): - """ - Write text line in output file. - """ - line_string = f"{indent}{text.rstrip()}\n" - file_out.write(line_string) - - def print_root_level_doc(self, file_out): - """Print at the root level of YML file the general documentation field found in XML file""" - indent = 0 * DEPTH_SIZE - - text = self.root_level_comment.get("root_doc") - if text: - self.write_out(indent, text, file_out) - - text = self.root_level_doc - self.write_out(indent, text, file_out) - self.root_level_doc = "" - - def convert_to_yaml_comment(self, depth, text): - """ - Convert into yaml comment by adding exta '#' char in front of comment lines - """ - # To store indentation text from comment - lines = self.clean_and_organise_text(text, depth).split("\n") - indent = DEPTH_SIZE * depth - mod_lines = [] - for line in lines: - line = line.strip() - if line: - if line[0] != "#": - line = "# " + line - mod_lines.append(line) - # The starting '\n' to keep multiple comments separate - return "\n" + indent + "\n".join(mod_lines) - - def print_root_level_info(self, depth, file_out): - """ - Print at the root level of YML file \ - the information stored as definition attributes in the XML file - """ - if depth < 0: - raise ValueError("Somthing wrong with indentation in root level.") - - has_category = False - for def_line in self.root_level_definition: - if def_line in DEFINITION_CATEGORIES: - self.write_out(indent=0 * DEPTH_SIZE, text=def_line, file_out=file_out) - has_category = True - - if not has_category: - raise ValueError( - "Definition dose not get any category from 'base or application'." - ) - self.print_root_level_doc(file_out) - text = self.root_level_comment.get("symbols", "") - if text: - indent = depth * DEPTH_SIZE - self.write_out(indent, text, file_out) - if self.root_level_symbols: - self.write_out( - indent=0 * DEPTH_SIZE, text=self.root_level_symbols, file_out=file_out - ) - # symbol_list include 'symbols doc', and all 'symbol' - for ind, symbol in enumerate(self.symbol_list): - # Taking care of comments that come on top of 'symbols doc' and 'symbol' - if ( - "symbol_comments" in self.root_level_comment - and self.root_level_comment["symbol_comments"][ind] != "" - ): - indent = depth * DEPTH_SIZE - self.write_out( - indent, - self.root_level_comment["symbol_comments"][ind], - file_out, - ) - if ( - "symbol_doc_comments" in self.root_level_comment - and self.root_level_comment["symbol_doc_comments"][ind] != "" - ): - indent = depth * DEPTH_SIZE - self.write_out( - indent, - self.root_level_comment["symbol_doc_comments"][ind], - file_out, - ) - - self.write_out(indent=(0 * DEPTH_SIZE), text=symbol, file_out=file_out) - indent = depth * DEPTH_SIZE - # Take care copyright doc string - for comment in self.pi_comments: - if comment and not is_dom_comment(comment): - self.write_out( - indent, self.convert_to_yaml_comment(depth, comment), file_out - ) - if self.root_level_definition: - # Store NXname for writing at end of definition attributes - nx_name = "" - for defs in self.root_level_definition: - if "NX" in defs and defs[-1] == ":": - nx_name = defs - continue - if defs in ("category: application", "category: base"): - continue - self.write_out(indent=0 * DEPTH_SIZE, text=defs, file_out=file_out) - self.write_out(indent=0 * DEPTH_SIZE, text=nx_name, file_out=file_out) - self.found_definition = False - - def handle_exists(self, exists_dict, key, val): - """ - Create exist component as folows: - - {'min' : value for min, - 'max' : value for max, - 'optional' : value for optional} - - This is created separately so that the keys stays in order. - """ - if not val: - val = "" - else: - val = str(val) - if "minOccurs" == key: - exists_dict["minOccurs"] = ["min", val] - elif "maxOccurs" == key: - exists_dict["maxOccurs"] = ["max", val] - elif "optional" == key: - exists_dict["optional"] = ["optional", val] - elif "recommended" == key: - exists_dict["recommended"] = ["recommended", val] - elif "required" == key: - exists_dict["required"] = ["required", val] - - # pylint: disable=too-many-branches - def handle_group_or_field(self, depth, node, file_out): - """Handle all the possible attributes that come along a field or group""" - - name_type = "" - node_attr = node.attrib - rm_key_list = [] - # Maintain order: name and type in form name(type) or (type)name that come first - for key, val in node_attr.items(): - if key == "name": - name_type = name_type + val - rm_key_list.append(key) - elif key == "type": - name_type = f"{name_type}({val})" - rm_key_list.append(key) - if not name_type: - raise ValueError( - f"No 'name' or 'type' has been found. But, 'group' or 'field' " - f"must have at least a name.We have attributes: {node_attr}" - ) - indent = depth * DEPTH_SIZE - file_out.write(f"{indent}{name_type}:\n") - - for key in rm_key_list: - del node_attr[key] - - # tmp_dict intended to preserve order of attributes - tmp_dict = {} - exists_dict = {} - for key, val in node_attr.items(): - # Check for any unwanted attributes - self.check_for_unwanted_attributes(node=node) - # As both 'minOccurs', 'maxOccurs' and optionality move to the 'exists' - if key in self.optionality_keys: - if "exists" not in tmp_dict: - tmp_dict["exists"] = [] - self.handle_exists(exists_dict, key, val) - elif key == "units": - tmp_dict["unit"] = str(val) - else: - tmp_dict[key] = str(val) - - if exists_dict: - for key, val in exists_dict.items(): - if key in ["minOccurs", "maxOccurs"]: - tmp_dict["exists"] = tmp_dict["exists"] + val - elif key in ["optional", "recommended", "required"]: - tmp_dict["exists"] = key - - depth_ = depth + 1 - for key, val in tmp_dict.items(): - # Increase depth size inside handle_map...() for writing text with one - # more indentation. - file_out.write( - f"{depth_ * DEPTH_SIZE}{key}: " - f"{handle_mapping_char(val, depth_ + 1, False)}\n" - ) - - def check_for_unwanted_attributes(self, node, allowed_attributes_li=None, tag=None): - """Check for any attributes that NeXus does not allow.""" - node_tag = remove_namespace_from_tag(node.tag) - if node_tag == "field": - for key in node.attrib.keys(): - if key not in NXDL_FIELD_ATTRIBUTES: - raise ValueError( - f"Field has an unwanted attribute {key}." - f"NeXus field allows attributes from {NXDL_FIELD_ATTRIBUTES}" - ) - elif node_tag == "group": - for key in node.attrib.keys(): - if key not in NXDL_GROUP_ATTRIBUTES: - raise ValueError( - f"Attribute has an unwanted attribute {key}." - f"NeXus attribute allows attributes from {NXDL_GROUP_ATTRIBUTES}" - ) - elif node_tag == tag: - for key in node.attrib.keys(): - if key not in allowed_attributes_li: - raise ValueError( - f"{tag.capitalized()} has an unwanted attribute {key}." - f"NeXus {tag.capitalized()} allows attributes from {allowed_attributes_li}" - ) - - # pylint: disable=too-many-branches, too-many-locals - def handle_dimension(self, depth, node, file_out): - """Handle the dimension field. - - NOTE: Usually we take care of any xml element in xmlparse(...) and - recursion_in_xml_tree(...) functions. But here it is a bit different: the doc dimension - and attributes of dim has been handled inside this function here. - """ - possible_dim_attrs = ["ref", "required", "incr", "refindex"] - possible_dimemsion_attrs = ["rank"] - - # taking care of Dimension tag - indent = depth * DEPTH_SIZE - tag = remove_namespace_from_tag(node.tag) - file_out.write(f"{indent}{tag}:\n") - for attr, value in node.attrib.items(): - if attr in possible_dimemsion_attrs and not isinstance(value, dict): - indent = (depth + 1) * DEPTH_SIZE - file_out.write(f"{indent}{attr}: {value}\n") - else: - raise ValueError( - f"Dimension has an attribute {attr} that is not valid." - f"Current the allowd atributes are {possible_dimemsion_attrs}." - f" Please have a look" - ) - # taking care of dimension doc - for child in list(node): - tag = remove_namespace_from_tag(child.tag) - if tag == "doc": - text = self.handle_not_root_level_doc(depth + 1, child.text) - file_out.write(text) - node.remove(child) - - dim_index_value = "" - dim_other_parts = {} - dim_cmnt_node = [] - # taking care of dim and doc children of dimension - for child in list(node): - tag = remove_namespace_from_tag(child.tag) - child_attrs = child.attrib - # taking care of index and value attributes - if tag == "dim": - # taking care of index and value in format [[index, value]] - index = child_attrs.pop("index", "") - value = child_attrs.pop("value", "") - dim_index_value = f"{dim_index_value}[{index}, {value}], " - - # Taking care of doc comes as child of dim - for cchild in list(child): - ttag = cchild.tag.split("}", 1)[1] - if ttag == ("doc"): - if ttag not in dim_other_parts: - dim_other_parts[ttag] = [] - text = cchild.text - dim_other_parts[ttag].append(text.strip()) - child.remove(cchild) - continue - # taking care of other attributes except index and value - for attr, value in child_attrs.items(): - if attr in possible_dim_attrs: - if attr not in dim_other_parts: - dim_other_parts[attr] = [] - dim_other_parts[attr].append(value) - if tag == CMNT_TAG and self.include_comment: - # Store and remove node so that comment nodes from dim node so - # that it does not call in xmlparser function - dim_cmnt_node.append(child) - node.remove(child) - - # All 'dim' element comments on top of 'dim' yaml key - if dim_cmnt_node: - for ch_nd in dim_cmnt_node: - self.handle_comment(depth + 1, ch_nd, file_out) - # index and value attributes of dim elements - indent = (depth + 1) * DEPTH_SIZE - value = dim_index_value[:-2] or "" - file_out.write(f"{indent}dim: [{value}]\n") - - # Write the attributes, except index and value, and doc of dim as child of dim_parameter. - # But the doc or attributes for each dim come inside list according to the order of dim. - if dim_other_parts: - indent = (depth + 1) * DEPTH_SIZE - file_out.write(f"{indent}dim_parameters:\n") - # depth = depth + 2 dim_parameter has child such as doc of dim - indent = (depth + 2) * DEPTH_SIZE - for key, value in dim_other_parts.items(): - if key == "doc": - value = self.handle_not_root_level_doc( - depth + 2, str(value), key, file_out - ) - else: - # Increase depth size inside handle_map...() for writing text with one - # more indentation. - file_out.write( - f"{indent}{key}: " - f"{handle_mapping_char(value, depth + 3, False)}\n" - ) - - def handle_enumeration(self, depth, node, file_out): - """ - Handle the enumeration field parsed from the xml file. - - If the enumeration items contain a doc field, the yaml file will contain items as child - fields of the enumeration field. - - If no doc are inherited in the enumeration items, a list of the items is given for the - enumeration list. - - """ - - check_doc = False - node_children = list(node) - for child in node_children: - if list(child): - check_doc = True - break - # pylint: disable=too-many-nested-blocks - if check_doc: - indent = depth * DEPTH_SIZE - tag = remove_namespace_from_tag(node.tag) - file_out.write(f"{indent}{tag}: \n") - for child in node_children: - tag = remove_namespace_from_tag(child.tag) - itm_depth = depth + 1 - if tag == "item": - indent = itm_depth * DEPTH_SIZE - value = child.attrib["value"] - file_out.write(f"{indent}{value}: \n") - child_children = list(child) - if child_children: - for item_doc in child_children: - if remove_namespace_from_tag(item_doc.tag) == "doc": - item_doc_depth = itm_depth + 1 - self.handle_not_root_level_doc( - item_doc_depth, - item_doc.text, - item_doc.tag, - file_out, - ) - if ( - remove_namespace_from_tag(item_doc.tag) == CMNT_TAG - and self.include_comment - ): - self.handle_comment(itm_depth + 1, item_doc, file_out) - if tag == CMNT_TAG and self.include_comment: - self.handle_comment(itm_depth + 1, child, file_out) - else: - enum_list = [] - remove_nodes = [] - for item_child in node_children: - tag = remove_namespace_from_tag(item_child.tag) - if tag == "item": - value = item_child.attrib["value"] - enum_list.append(value) - if tag == CMNT_TAG and self.include_comment: - self.handle_comment(depth, item_child, file_out) - remove_nodes.append(item_child) - for ch_node in remove_nodes: - node.remove(ch_node) - - indent = depth * DEPTH_SIZE - tag = remove_namespace_from_tag(node.tag) - enum_list = ", ".join(enum_list) - file_out.write(f"{indent}{tag}: [{enum_list}]\n") - - def handle_attributes(self, depth, node, file_out): - """Handle the attributes parsed from the xml file""" - - name = "" - nm_attr = "name" - node_attr = node.attrib - # Maintain order: name and type in form name(type) or (type)name that come first - name = node_attr.pop(nm_attr, "") - if not name: - raise ValueError("Attribute must have an name key.") - - indent = depth * DEPTH_SIZE - escapesymbol = r"\@" - file_out.write(f"{indent}{escapesymbol}{name}:\n") - - tmp_dict = {} - exists_dict = {} - for key, val in node_attr.items(): - if key not in NXDL_ATTRIBUTES_ATTRIBUTES: - raise ValueError( - f"An attribute ({key}) has been found that is not allowed." - f"The allowed attr is {NXDL_ATTRIBUTES_ATTRIBUTES}." - ) - # As both 'minOccurs', 'maxOccurs' and optionality move to the 'exists' - if key in self.optionality_keys: - if "exists" not in tmp_dict: - tmp_dict["exists"] = [] - self.handle_exists(exists_dict, key, val) - elif key == "units": - tmp_dict["unit"] = val - else: - tmp_dict[key] = val - - has_min_max = False - has_opt_reco_requ = False - if exists_dict: - for key, val in exists_dict.items(): - if key in ["minOccurs", "maxOccurs"]: - tmp_dict["exists"] = tmp_dict["exists"] + val - has_min_max = True - elif key in ["optional", "recommended", "required"]: - tmp_dict["exists"] = key - has_opt_reco_requ = True - if has_min_max and has_opt_reco_requ: - raise ValueError( - "Optionality 'exists' can take only either from ['minOccurs'," - " 'maxOccurs'] or from ['optional', 'recommended', 'required']" - ". But not from both of the groups together. Please check in" - " attributes" - ) - - depth_ = depth + 1 - for key, val in tmp_dict.items(): - # Increase depth size inside handle_map...() for writing text with one - # more indentation. - file_out.write( - f"{depth_ * DEPTH_SIZE}{key}: " - f"{handle_mapping_char(val, depth_ + 1, False)}\n" - ) - - def handle_link(self, depth, node, file_out): - """Handle link elements of nxdl""" - - node_attr = node.attrib - # Handle special cases - name = node_attr.pop("name", "") - if name: - indent = depth * DEPTH_SIZE - file_out.write(f"{indent}{name}(link):\n") - - depth_ = depth + 1 - # Handle general cases - for attr_key, val in node_attr.items(): - if attr_key in NXDL_LINK_ATTRIBUTES: - indent = depth_ * DEPTH_SIZE - file_out.write(f"{indent}{attr_key}: {val}\n") - else: - raise ValueError( - f"An unexpected attribute '{attr_key}' of link has found." - f"At this moment the allowed keys are {NXDL_LINK_ATTRIBUTES}" - ) - - def handle_choice(self, depth, node, file_out): - """ - Handle choice element which is a parent node of group. - """ - - node_attr = node.attrib - name = node_attr.pop("name", "") - # Handle special casees - if name: - indent = depth * DEPTH_SIZE - file_out.write(f"{indent}{name}(choice): \n") - - depth_ = depth + 1 - # Take care of attributes of choice element, attributes may come in future. - for attr in node_attr.items(): - if attr in self.choice_allowed_attr: - indent = depth_ * DEPTH_SIZE - value = node_attr[attr] - file_out.write(f"{indent}{attr}: {value}\n") - else: - raise ValueError( - f"An unexpected attribute '{attr}' of 'choice' has been found." - f"At this moment allowed attributes for choice {self.choice_allowed_attr}" - ) - - def handle_comment(self, depth, node, file_out): - """ - Collect comment element and pass to write_out function - """ - indent = depth * DEPTH_SIZE - text = self.convert_to_yaml_comment(depth, node.text) - self.write_out(indent, text, file_out) - - def recursion_in_xml_tree(self, depth, xml_tree, output_yml, verbose): - """ - Descend lower level in xml tree. If we are in the symbols branch, the recursive - behaviour is not triggered as we already handled the symbols' children. - """ - - tree = xml_tree["tree"] - node = xml_tree["node"] - for child in list(node): - xml_tree_children = {"tree": tree, "node": child} - self.xmlparse(output_yml, xml_tree_children, depth, verbose) - - # pylint: disable=too-many-branches, too-many-statements - def xmlparse(self, output_yml, xml_tree, depth, verbose): - """ - Main method of the nxdl2yaml converter. - It parses XML tree, then prints recursively each level of the tree - """ - tree = xml_tree["tree"] - node = xml_tree["node"] - if verbose: - if isinstance(node.tag, Callable): - print(f"Node tag: {node.tag}\n") - print(f"Node text: {node.text}\n") - else: - print(f"Node tag: {remove_namespace_from_tag(node.tag)}\n") - print(f"Attributes: {node.attrib}\n") - with open(output_yml, "a", encoding="utf-8") as file_out: - tag = remove_namespace_from_tag(node.tag) - if tag == "definition": - self.found_definition = True - self.handle_definition(node) - # Taking care of root level doc and symbols - remove_cmnt_n = None - last_comment = "" - for child in node: - tag_tmp = remove_namespace_from_tag(child.tag) - if tag_tmp == CMNT_TAG and self.include_comment: - last_comment = self.convert_to_yaml_comment(depth, child.text) - remove_cmnt_n = child - if tag_tmp == "doc": - self.store_root_level_comments("root_doc", last_comment) - last_comment = "" - self.handle_root_level_doc(child) - node.remove(child) - if remove_cmnt_n is not None: - node.remove(remove_cmnt_n) - remove_cmnt_n = None - if tag_tmp == "symbols": - self.store_root_level_comments("symbols", last_comment) - last_comment = "" - self.handle_symbols(depth, child) - node.remove(child) - if remove_cmnt_n is not None: - node.remove(remove_cmnt_n) - remove_cmnt_n = None - - if tag == "doc" and depth != 1: - parent = get_node_parent_info(tree, node)[0] - doc_parent = remove_namespace_from_tag(parent.tag) - if doc_parent != "item": - self.handle_not_root_level_doc( - depth, text=node.text, tag=node.tag, file_out=file_out - ) - - if self.found_definition is True and self.root_level_doc: - self.print_root_level_info(depth, file_out) - # End of print root-level definitions in file - if tag in ("field", "group") and depth != 0: - self.handle_group_or_field(depth, node, file_out) - if tag == ("enumeration"): - self.handle_enumeration(depth, node, file_out) - if tag == ("attribute"): - self.handle_attributes(depth, node, file_out) - if tag == ("dimensions"): - self.handle_dimension(depth, node, file_out) - if tag == ("link"): - self.handle_link(depth, node, file_out) - if tag == ("choice"): - self.handle_choice(depth, node, file_out) - if tag == CMNT_TAG and self.include_comment: - self.handle_comment(depth, node, file_out) - depth += 1 - # Write nested nodes - self.recursion_in_xml_tree(depth, xml_tree, output_yml, verbose) diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py b/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py deleted file mode 100644 index 45c5a4c754..0000000000 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl_forward_tools.py +++ /dev/null @@ -1,1247 +0,0 @@ -#!/usr/bin/env python3 -"""Creates an instantiated NXDL schema XML tree by walking the dictionary nest - -""" -# -*- coding: utf-8 -*- -# -# 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. -# - -import datetime -import pathlib -import textwrap -import warnings -from typing import Union -from urllib.parse import unquote - -import lxml.etree as ET -import yaml -from yaml.scanner import ScannerError - -from ..utils import nxdl_utils as pynxtools_nxlib -from .comment_collector import CommentCollector -from .nyaml2nxdl_helper import YAML_ATTRIBUTES_ATTRIBUTES -from .nyaml2nxdl_helper import YAML_FIELD_ATTRIBUTES -from .nyaml2nxdl_helper import YAML_GROUP_ATTRIBUTES -from .nyaml2nxdl_helper import YAML_LINK_ATTRIBUTES -from .nyaml2nxdl_helper import LineLoader -from .nyaml2nxdl_helper import clean_empty_lines -from .nyaml2nxdl_helper import get_yaml_escape_char_reverter_dict -from .nyaml2nxdl_helper import is_dom_comment -from .nyaml2nxdl_helper import nx_name_type_resolving -from .nyaml2nxdl_helper import remove_namespace_from_tag - -# pylint: disable=too-many-lines, global-statement, invalid-name -DOM_COMMENT = ( - f"# NeXus - Neutron and X-ray Common Data Format\n" - f"# \n" - f"# Copyright (C) 2014-{datetime.date.today().year} NeXus International Advisory Committee (NIAC)\n" - f"# \n" - f"# This library is free software; you can redistribute it and/or\n" - f"# modify it under the terms of the GNU Lesser General Public\n" - f"# License as published by the Free Software Foundation; either\n" - f"# version 3 of the License, or (at your option) any later version.\n" - f"#\n" - f"# This library is distributed in the hope that it will be useful,\n" - f"# but WITHOUT ANY WARRANTY; without even the implied warranty of\n" - f"# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU\n" - f"# Lesser General Public License for more details.\n" - f"#\n" - f"# You should have received a copy of the GNU Lesser General Public\n" - f"# License along with this library; if not, write to the Free Software\n" - f"# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA\n" - f"#\n" - f"# For further information, see http://www.nexusformat.org\n" -) -NX_CLSS = pynxtools_nxlib.get_nx_classes() -NX_NEW_DEFINED_CLASSES = ["NX_COMPLEX"] -NX_TYPE_KEYS = pynxtools_nxlib.get_nx_attribute_type() -NX_ATTR_IDNT = "\\@" -NX_UNIT_IDNT = "unit" -DEPTH_SIZE = " " -NX_UNIT_TYPES = pynxtools_nxlib.get_nx_units() -# Initialised in yml_reader() funtion -COMMENT_BLOCKS: CommentCollector -CATEGORY = "" # Definition would be either 'base' or 'application' - - -def check_for_dom_comment_in_yaml(): - """Check the yaml file has dom comment or dom comment needed to be hard coded.""" - - # Check for dom comments in first five comments - dom_comment = "" - dom_comment_ind = 1 - for ind, comnt in enumerate(COMMENT_BLOCKS[0:5]): - cmnt_list = comnt.get_comment_text_list() - if len(cmnt_list) == 1: - text = cmnt_list[0] - else: - continue - if is_dom_comment(text): - dom_comment = text - dom_comment_ind = ind - break - - # deactivate the root dom_comment, So that the corresponding comment would not be - # considered as comment for definition xml element. - if dom_comment: - COMMENT_BLOCKS.remove_comment(dom_comment_ind) - - return dom_comment - - -def yml_reader(inputfile): - """ - This function launches the LineLoader class. - It parses the yaml in a dict and extends it with line tag keys for each key of the dict. - """ - global COMMENT_BLOCKS - with open(inputfile, "r", encoding="utf-8") as plain_text_yaml: - loader = LineLoader(plain_text_yaml) - loaded_yaml = loader.get_single_data() - COMMENT_BLOCKS = CommentCollector(inputfile, loaded_yaml) - COMMENT_BLOCKS.extract_all_comment_blocks() - dom_cmnt_frm_yaml = check_for_dom_comment_in_yaml() - global DOM_COMMENT - if dom_cmnt_frm_yaml: - DOM_COMMENT = dom_cmnt_frm_yaml - - if "category" not in loaded_yaml.keys(): - raise ValueError( - "All definitions should be either 'base' or 'application' category. " - "No category has been found." - ) - global CATEGORY - CATEGORY = loaded_yaml["category"] - return loaded_yaml - - -def check_for_default_attribute_and_value(xml_element): - """Check for default attribute for NeXus concepts. - - NeXus Groups, fields and attributes might have xml default attributes and values that must - come. For example: 'optional' which is 'true' by default for base class and false otherwise. - """ - - # base: Default attributes and value for all elements of base class except dimension element - base_attr_to_val = {"optional": "true"} - - # application: Default attributes and value for all elements of application class except - # dimension element - application_attr_to_val = {"optional": "false"} - - # Default attributes and value for dimension element - base_dim_attr_to_val = {"required": "false"} - application_dim_attr_to_val = {"required": "true"} - - # Eligible tag for default attr and value - eligible_tag = ["group", "field", "attribute"] - - def set_default_attribute(xml_elem, default_attr_to_val): - for deflt_attr, deflt_val in default_attr_to_val.items(): - if ( - deflt_attr not in xml_elem.attrib - and "maxOccurs" not in xml_elem.attrib - and "minOccurs" not in xml_elem.attrib - and "recommended" not in xml_elem.attrib - ): - xml_elem.set(deflt_attr, deflt_val) - - for child in list(xml_element): - # skipping comment 'function' that mainly collect comment from yaml file. - if not isinstance(child.tag, str): - continue - tag = remove_namespace_from_tag(child.tag) - - if tag == "dim" and CATEGORY == "base": - set_default_attribute(child, base_dim_attr_to_val) - if tag == "dim" and CATEGORY == "application": - set_default_attribute(child, application_dim_attr_to_val) - if tag in eligible_tag and CATEGORY == "base": - set_default_attribute(child, base_attr_to_val) - if tag in eligible_tag and CATEGORY == "application": - set_default_attribute(child, application_attr_to_val) - check_for_default_attribute_and_value(child) - - -def yml_reader_nolinetag(inputfile): - """ - pyyaml based parsing of yaml file in python dict - """ - with open(inputfile, "r", encoding="utf-8") as stream: - parsed_yaml = yaml.safe_load(stream) - return parsed_yaml - - -def check_for_skipped_attributes(component, value, allowed_attr=None, verbose=False): - """ - Check for any attributes have been skipped or not. - NOTE: We should keep in mind about 'doc' - """ - block_tag = ["enumeration"] - if value: - for attr, val in value.items(): - if attr == "doc": - continue - if "__line__" in attr or attr in block_tag: - continue - line_number = f"__line__{attr}" - if verbose: - print(f"__line__ : {value[line_number]}") - if ( - not isinstance(val, dict) - and "\\@" not in attr - and attr not in allowed_attr - and "NX" not in attr - and val - ): - raise ValueError( - f"An attribute '{attr}' in part '{component}' has been found" - f". Please check around line '{value[line_number]}. At this " - f"time, the allowed attrbutes are {allowed_attr}." - ) - - -def format_nxdl_doc(string): - """NeXus format for doc string""" - string = check_for_mapping_char_other(string) - string_len = 80 - if "\n" not in string: - if len(string) > string_len: - wrapped = textwrap.TextWrapper( - width=string_len, break_long_words=False, replace_whitespace=False - ) - string = "\n".join(wrapped.wrap(string)) - formatted_doc = "\n" + f"{string}" - else: - text_lines = string.split("\n") - text_lines = clean_empty_lines(text_lines) - formatted_doc = "\n" + "\n".join(text_lines) - if not formatted_doc.endswith("\n"): - formatted_doc += "\n" - return formatted_doc - - -def check_for_mapping_char_other(text): - """ - Check for mapping char \':\' which does not be passed through yaml library. - Then replace it by ':'. - """ - if not text: - text = "" - text = str(text) - if text == "True": - text = "true" - if text == "False": - text = "false" - # Some escape char is not valid in yaml libray which is written while writing - # yaml file. In the time of writing nxdl revert to that escape char. - escape_reverter = get_yaml_escape_char_reverter_dict() - for key, val in escape_reverter.items(): - if key in text: - text = text.replace(key, val) - return text.strip() - - -def handle_each_part_doc(text): - """Check and handle if the text is corresponds to xref or plain doc. - - In nyaml doc the entire documentation may come in list of small docs. - one doc string might be as follows: - ''' - xref: - spec: - term: - url: - ''' - - which has to be formatted as - ''' - This concept is related to term ``_ of the standard. - .. _: - - - Parameters - ---------- - text : string - String that looks like yaml notaion. - - return - ------ - Formated text - """ - - clean_txt = text.strip() - - if not clean_txt.startswith("xref:"): - return format_nxdl_doc(check_for_mapping_char_other(clean_txt)).strip() - - no_lines = len(clean_txt.splitlines()) - try: - xref_dict = yaml.safe_load(clean_txt) - except ScannerError as scan_err: - raise ValueError( - "Found invalid xref. Please make sure that your xref entries are valid yaml." - ) from scan_err - xref_entries = xref_dict.get("xref", {}) - - if no_lines != len(xref_entries) + 1: - raise ValueError("Invalid xref. It contains nested or duplicate keys.") - - if no_lines > 4: - raise ValueError("Invalid xref. Too many keys.") - - for key in xref_entries: - if key not in ("term", "spec", "url"): - raise ValueError( - f"Invalid xref key `{key}`. Must be one of `term`, `spec` or `url`." - ) - - return ( - f" This concept is related to term `{xref_entries.get('term', 'NO TERM')}`_ " - f"of the {xref_entries.get('spec', 'NO TERM')} standard.\n" - f".. _{xref_entries.get('term', 'NO SPECIFICATION')}: " - f"{xref_entries.get('url', 'NO URL')}" - ) - - -def xml_handle_doc(obj, value: Union[str, list], line_number=None, line_loc=None): - """This function creates a 'doc' element instance, and appends it to an existing element""" - # global comment_bolcks - doc_elemt = ET.SubElement(obj, "doc") - text = "" - if isinstance(value, list): - for doc_part in value: - text = text + "\n" + handle_each_part_doc(doc_part) + "\n" - else: - text = text + "\n" + handle_each_part_doc(value) + "\n" - # To keep the doc middle of doc tag. - doc_elemt.text = text - if line_loc is not None and line_number is not None: - xml_handle_comment(obj, line_number, line_loc, doc_elemt) - - -def xml_handle_units(obj, value): - """This function creates a 'units' element instance, and appends it to an existing element""" - obj.set("units", str(value)) - - -# pylint: disable=too-many-branches -def xml_handle_exists(dct, obj, keyword, value): - """ - This function creates an 'exists' element instance, and appends it to an existing element - """ - line_number = f"__line__{keyword}" - assert ( - value is not None - ), f"Line {dct[line_number]}: exists argument must not be None !" - if isinstance(value, list): - if len(value) == 4: - if value[0] == "min" and value[2] == "max": - obj.set("minOccurs", str(value[1])) - if str(value[3]) != "infty": - obj.set("maxOccurs", str(value[3])) - else: - obj.set("maxOccurs", "unbounded") - elif value[0] == "max" and value[2] == "min": - if str(value[1]) != "infty": - obj.set("maxOccurs", str(value[1])) - else: - obj.set("maxOccurs", "unbounded") - obj.set("minOccurs", str(value[3])) - else: - raise ValueError( - f"Line {dct[line_number]}: exists keyword" - f"needs to go either with an optional [recommended] list with two " - f"entries either [min, ] or [max, ], or a list of four " - f"entries [min, , max, ] !" - ) - elif len(value) == 2 and value[0] == "min": - obj.set("minOccurs", str(value[1])) - elif len(value) == 2 and value[0] == "max": - obj.set("maxOccurs", str(value[1])) - else: - raise ValueError( - f"Line {dct[line_number]}: exists keyword " - f"needs to go either with optional, recommended, a list with two " - f"entries either [min, ] or [max, ], or a list of four " - f"entries [min, , max, ] !" - ) - else: - # This clause take optional in all cases except dimension where 'required' key is allowed - # not the 'optional' key. - if value == "optional": - obj.set("optional", "true") - elif value == "recommended": - obj.set("recommended", "true") - elif value == "required": - obj.set("optional", "false") - else: - obj.set("minOccurs", "0") - - -def xml_handle_dimensions(dct, obj, keyword, value: dict): - """ - This function creates a 'dimensions' element instance, and appends it to an existing element - - NOTE: we could create xml_handle_dim() function. - But, the dim elements in yaml file is defined as 'dim =[[index, value]]' - but dim has other attributes such as 'ref' and also might have doc as chlid. - so in that sense 'dim' should have come as dict keeping attributes and child as members of - dict. - Regarding this situation all the attributes of 'dimensions' and child 'doc' has been - included here. - - Other attributes, except 'index' and 'value', of 'dim' comes under nested dict named - 'dim_parameter: - incr:[...]' - """ - - possible_dimension_attrs = ["rank"] # nxdl attributes - line_number = f"__line__{keyword}" - line_loc = dct[line_number] - assert ( - "dim" in value.keys() - ), f"Line {line_loc}: No dim as child of dimension has been found." - xml_handle_comment(obj, line_number, line_loc) - dims = ET.SubElement(obj, "dimensions") - # Consider all the children under dimension is dim element and - # its attributes - - rm_key_list = [] - rank = "" - for key, val in value.items(): - if "__line__" in key: - continue - line_number = f"__line__{key}" - line_loc = value[line_number] - if key == "rank": - rank = val or "" - if isinstance(rank, int) and rank < 0: - raise ValueError( - f"Dimension must have some info about rank which is not " - f"available. Please check around Line: {dct[line_number]}" - ) - dims.set(key, str(val)) - rm_key_list.append(key) - rm_key_list.append(line_number) - xml_handle_comment(obj, line_number, line_loc, dims) - # Check dimension doc and handle it - elif key == "doc" and isinstance(val, str): - xml_handle_doc(dims, val, line_number, line_loc) - rm_key_list.append(key) - rm_key_list.append(line_number) - elif key in possible_dimension_attrs and not isinstance(val, dict): - dims.set(key, str(val)) - rm_key_list.append(key) - rm_key_list.append(line_number) - xml_handle_comment(obj, line_number, line_loc, dims) - - for key in rm_key_list: - del value[key] - - xml_handle_dim_from_dimension_dict(dct, dims, keyword, value, rank=False) - - if isinstance(value, dict) and value != {}: - recursive_build(dims, value, verbose=None) - - -# pylint: disable=too-many-locals, too-many-arguments -def xml_handle_dim_from_dimension_dict( - dct, dims_obj, keyword, value, rank, verbose=False -): - """ - Handling dim element. - NOTE: The inputs 'keyword' and 'value' are as input for xml_handle_dimensions - function. please also read note in xml_handle_dimensions. - """ - deprecated_dim_attrs = ["ref", "incr", "refindex"] - possible_dim_attrs = [*deprecated_dim_attrs, "required"] - - # Some attributes might have equivalent name e.g. 'required' is correct one and - # 'optional' could be another name. Then change attribute to the correct one. - wrong_to_correct_attr = [("optional", "required")] - header_line_number = f"__line__{keyword}" - dim_list = [] - rm_key_list = [] - # NOTE: dim doc and other attributes except 'index' and 'value' will come as list of value - # under dim_parameters - if not value: - return - rank = "" - # pylint: disable=too-many-nested-blocks - for attr, vvalue in value.items(): - if "__line__" in attr: - continue - line_number = f"__line__{attr}" - line_loc = value[line_number] - # dim comes in precedence - if attr == "dim": - # dim consists of [index, value] list - llist_ind_value = vvalue - assert isinstance( - llist_ind_value, list - ), f"Line {value[line_number]}: dim argument not a list !" - xml_handle_comment(dims_obj, line_number, line_loc) - if isinstance(rank, int) and rank > 0: - assert rank == len(llist_ind_value), ( - f"Wrong dimension rank check around Line {dct[header_line_number]}.\n" - f"Line {[dct[header_line_number]]} rank value {rank} " - f"is not the same as dim array = " - f"{len(llist_ind_value)}." - ) - # Taking care of ind and value that comes as list of list - for dim_ind_val in llist_ind_value: - dim = ET.SubElement(dims_obj, "dim") - - # Taking care of multidimensions or rank - if len(dim_ind_val) >= 1 and dim_ind_val[0]: - dim.set("index", str(dim_ind_val[0])) - if len(dim_ind_val) == 2 and dim_ind_val[1]: - dim.set("value", str(dim_ind_val[1])) - dim_list.append(dim) - rm_key_list.append(attr) - rm_key_list.append(line_number) - elif attr == "dim_parameters" and isinstance(vvalue, dict): - xml_handle_comment(dims_obj, line_number, line_loc) - for kkkey, vvval in vvalue.items(): - if "__line__" in kkkey: - continue - cmnt_number = f"__line__{kkkey}" - cmnt_loc = vvalue[cmnt_number] - # Check whether any optional attributes added - for tuple_wng_crt in wrong_to_correct_attr: - if kkkey == tuple_wng_crt[0]: - raise ValueError( - f"{cmnt_loc}: Attribute '{kkkey}' is prohibited, use " - f"'{tuple_wng_crt[1]}" - ) - if kkkey == "doc" and dim_list: - # doc comes as list of doc - for i, dim in enumerate(dim_list): - if isinstance(vvval, list) and i < len(vvval): - tmp_val = vvval[i] - xml_handle_doc(dim, vvval[i], cmnt_number, cmnt_loc) - # Check all the dim have doc if not skip - elif isinstance(vvval, list) and i >= len(vvval): - pass - else: - if kkkey in deprecated_dim_attrs: - dep_text = ( - f"Attrbute {kkkey} is deprecated. " - f"Check attributes after line {cmnt_loc}" - ) - warnings.warn(dep_text, DeprecationWarning) - for i, dim in enumerate(dim_list): - # all atribute of dims comes as list - if isinstance(vvval, list) and i < len(vvval): - tmp_val = vvval[i] - dim.set(kkkey, str(tmp_val)) - - # Check all the dim have doc if not skip - elif isinstance(vvval, list) and i >= len(vvval): - pass - # All dim might have the same value for the same attribute - elif not isinstance(vvval, list): - tmp_val = value - dim.set(kkkey, str(tmp_val)) - rm_key_list.append(attr) - rm_key_list.append(line_number) - else: - raise ValueError( - f"Got unexpected block except 'dim' and 'dim_parameters'." - f"Please check around line {line_number}" - ) - - for key in rm_key_list: - del value[key] - - check_for_skipped_attributes("dim", value, possible_dim_attrs, verbose) - - -def xml_handle_enumeration(dct, obj, keyword, value, verbose): - """This function creates an 'enumeration' element instance. - - Two cases are handled: - 1) the items are in a list - 2) the items are dictionaries and may contain a nested doc - """ - line_number = f"__line__{keyword}" - line_loc = dct[line_number] - xml_handle_comment(obj, line_number, line_loc) - enum = ET.SubElement(obj, "enumeration") - - assert ( - value is not None - ), f"Line {line_loc}: enumeration must \ -bear at least an argument !" - assert ( - len(value) >= 1 - ), f"Line {dct[line_number]}: enumeration must not be an empty list!" - if isinstance(value, list): - for element in value: - itm = ET.SubElement(enum, "item") - itm.set("value", str(element)) - if isinstance(value, dict) and value != {}: - for element in value.keys(): - if "__line__" not in element: - itm = ET.SubElement(enum, "item") - itm.set("value", str(element)) - if isinstance(value[element], dict): - recursive_build(itm, value[element], verbose) - - -# pylint: disable=unused-argument -def xml_handle_link(dct, obj, keyword, value, verbose): - """ - If we have an NXDL link we decode the name attribute from (link)[:-6] - """ - - line_number = f"__line__{keyword}" - line_loc = dct[line_number] - xml_handle_comment(obj, line_number, line_loc) - name = keyword[:-6] - link_obj = ET.SubElement(obj, "link") - link_obj.set("name", str(name)) - - if value: - rm_key_list = [] - for attr, vval in value.items(): - if "__line__" in attr: - continue - line_number = f"__line__{attr}" - line_loc = value[line_number] - if attr == "doc": - xml_handle_doc(link_obj, vval, line_number, line_loc) - rm_key_list.append(attr) - rm_key_list.append(line_number) - elif attr in YAML_LINK_ATTRIBUTES and not isinstance(vval, dict): - if vval: - link_obj.set(attr, str(vval)) - rm_key_list.append(attr) - rm_key_list.append(line_number) - xml_handle_comment(obj, line_number, line_loc, link_obj) - - for key in rm_key_list: - del value[key] - # Check for skipped attributes - check_for_skipped_attributes("link", value, YAML_LINK_ATTRIBUTES, verbose) - - if isinstance(value, dict) and value != {}: - recursive_build(link_obj, value, verbose=None) - - -def xml_handle_choice(dct, obj, keyword, value, verbose=False): - """ - Build choice xml elements. That consists of groups. - """ - line_number = f"__line__{keyword}" - line_loc = dct[line_number] - xml_handle_comment(obj, line_number, line_loc) - # Add to this tuple if new attributes have been added to nexus definition. - possible_attr = () - choice_obj = ET.SubElement(obj, "choice") - # take care of special attributes - name = keyword[:-8] - choice_obj.set("name", name) - - if value: - rm_key_list = [] - for attr, vval in value.items(): - if "__line__" in attr: - continue - line_number = f"__line__{attr}" - line_loc = value[line_number] - if attr == "doc": - xml_handle_doc(choice_obj, vval, line_number, line_loc) - rm_key_list.append(attr) - rm_key_list.append(line_number) - elif attr in possible_attr and not isinstance(vval, dict): - if vval: - choice_obj.set(attr, str(vval)) - rm_key_list.append(attr) - rm_key_list.append(line_number) - xml_handle_comment(obj, line_number, line_loc, choice_obj) - - for key in rm_key_list: - del value[key] - # Check for skipped attributes - check_for_skipped_attributes("choice", value, possible_attr, verbose) - - if isinstance(value, dict) and value != {}: - recursive_build(choice_obj, value, verbose=None) - - -def xml_handle_symbols(dct, obj, keyword, value: dict): - """Handle a set of NXDL symbols as a child to obj""" - line_number = f"__line__{keyword}" - line_loc = dct[line_number] - assert ( - len(list(value.keys())) > 0 - ), f"Line {line_loc}: symbols table must not be empty !" - xml_handle_comment(obj, line_number, line_loc) - syms = ET.SubElement(obj, "symbols") - if "doc" in value.keys(): - line_number = "__line__doc" - line_loc = value[line_number] - xml_handle_comment(syms, line_number, line_loc) - doctag = ET.SubElement(syms, "doc") - doctag.text = "\n" + textwrap.fill(value["doc"], width=70) + "\n" - rm_key_list = [] - for kkeyword, vvalue in value.items(): - if "__line__" in kkeyword: - continue - if kkeyword != "doc": - line_number = f"__line__{kkeyword}" - line_loc = value[line_number] - xml_handle_comment(syms, line_number, line_loc) - assert vvalue is not None and isinstance( - vvalue, str - ), f"Line {line_loc}: put a comment in doc string !" - sym = ET.SubElement(syms, "symbol") - sym.set("name", kkeyword) - xml_handle_doc(sym, vvalue) - rm_key_list.append(kkeyword) - rm_key_list.append(line_number) - for key in rm_key_list: - del value[key] - - -def check_keyword_variable(verbose, dct, keyword, value): - """ - Check whether both keyword_name and keyword_type are empty, - and complains if it is the case - """ - keyword_name, keyword_type = nx_name_type_resolving(keyword) - if verbose: - print(f"{keyword_name}({keyword_type}): value type is {type(value)}\n") - if keyword_name == "" and keyword_type == "": - line_number = f"__line__{keyword}" - raise ValueError(f"Line {dct[line_number]}: found an improper yaml key !") - - -def helper_keyword_type(kkeyword_type): - """ - Return a value of keyword_type if it belong to NX_TYPE_KEYS - """ - if kkeyword_type in NX_TYPE_KEYS: - return kkeyword_type - return None - - -def verbose_flag(verbose, keyword, value): - """ - Verbose stdout printing for nested levels of yaml file, if verbose flag is active - """ - if verbose: - print(f"key:{keyword}; value type is {type(value)}\n") - - -def xml_handle_attributes(dct, obj, keyword, value, verbose): - """Handle the attributes found connected to attribute field""" - - line_number = f"__line__{keyword}" - line_loc = dct[line_number] - xml_handle_comment(obj, line_number, line_loc) - # as an attribute identifier - keyword_name, keyword_typ = nx_name_type_resolving(keyword) - line_number = f"__line__{keyword}" - if verbose: - print(f"__line__ : {dct[line_number]}") - if keyword_name == "" and keyword_typ == "": - raise ValueError(f"Line {dct[line_number]}: found an improper yaml key !") - elemt_obj = ET.SubElement(obj, "attribute") - elemt_obj.set("name", keyword_name[2:]) - if keyword_typ: - elemt_obj.set("type", keyword_typ) - - rm_key_list = [] - if value and value: - # taking care of attributes of attributes - for attr, attr_val in value.items(): - if "__line__" in attr: - continue - line_number = f"__line__{attr}" - line_loc = value[line_number] - if attr in ["doc", *YAML_ATTRIBUTES_ATTRIBUTES] and not isinstance( - attr_val, dict - ): - if attr == "unit": - elemt_obj.set(f"{attr}s", str(value[attr])) - rm_key_list.append(attr) - rm_key_list.append(line_number) - xml_handle_comment(obj, line_number, line_loc, elemt_obj) - elif attr == "exists" and attr_val: - xml_handle_exists(value, elemt_obj, attr, attr_val) - rm_key_list.append(attr) - rm_key_list.append(line_number) - xml_handle_comment(obj, line_number, line_loc, elemt_obj) - elif attr == "doc": - xml_handle_doc( - elemt_obj, format_nxdl_doc(attr_val), line_number, line_loc - ) - rm_key_list.append(attr) - rm_key_list.append(line_number) - else: - elemt_obj.set(attr, check_for_mapping_char_other(attr_val)) - rm_key_list.append(attr) - rm_key_list.append(line_number) - xml_handle_comment(obj, line_number, line_loc, elemt_obj) - - for key in rm_key_list: - del value[key] - # Check cor skipped attribute - check_for_skipped_attributes( - "Attribute", value, YAML_ATTRIBUTES_ATTRIBUTES, verbose - ) - if value: - recursive_build(elemt_obj, value, verbose) - - -def validate_field_attribute_and_value(v_attr, vval, allowed_attribute, value): - """ - Check for any attributes that comes with invalid name, - and invalid value. - """ - - if not isinstance(vval, dict) and not str(vval): # check for empty value - line_number = f"__line__{v_attr}" - raise ValueError( - f"In a field a valid attrbute ('{v_attr}') found that is not stored." - f" Please check around line {value[line_number]}" - ) - - # The below elements might come as child element - skipped_child_name = ["doc", "dimension", "enumeration", "choice", "exists"] - # check for invalid key or attributes - if ( - v_attr not in [*skipped_child_name, *allowed_attribute] - and "__line__" not in v_attr - and not isinstance(vval, dict) - and "(" not in v_attr # skip only groups and field that has name and type - and "\\@" not in v_attr - ): # skip nexus attributes - line_number = f"__line__{v_attr}" - raise ValueError( - f"In a field or group a invalid attribute ('{v_attr}') or child has found." - f" Please check around line {value[line_number]}." - ) - - -def xml_handle_fields_or_group( - dct, obj, keyword, value, ele_type, allowed_attr, verbose=False -): - """Handle a field or group in yaml file.""" - line_annot = f"__line__{keyword}" - line_loc = dct[line_annot] - xml_handle_comment(obj, line_annot, line_loc) - l_bracket = -1 - r_bracket = -1 - if keyword.count("(") == 1: - l_bracket = keyword.index("(") - if keyword.count(")") == 1: - r_bracket = keyword.index(")") - - keyword_name, keyword_type = nx_name_type_resolving(keyword) - if ele_type == "field" and not keyword_name: - raise ValueError( - f"No name for NeXus {ele_type} has been found." - f"Check around line:{line_loc}" - ) - elif not keyword_type and not keyword_name: - raise ValueError( - f"No name or type for NeXus {ele_type} has been found." - f"Check around line: {line_loc}" - ) - - elemt_obj = ET.SubElement(obj, ele_type) - - # type come first - if l_bracket == 0 and r_bracket > 0: - elemt_obj.set("type", keyword_type) - if keyword_name: - elemt_obj.set("name", keyword_name) - elif l_bracket > 0: - elemt_obj.set("name", keyword_name) - if keyword_type: - elemt_obj.set("type", keyword_type) - else: - elemt_obj.set("name", keyword_name) - - if value: - rm_key_list = [] - # In each each if clause apply xml_handle_comment(), to collect - # comments on that yaml line. - for attr, vval in value.items(): - if "__line__" in attr: - continue - line_number = f"__line__{attr}" - line_loc = value[line_number] - if attr == "doc": - xml_handle_doc( - elemt_obj, - vval, - line_number, - line_loc, - ) - rm_key_list.append(attr) - rm_key_list.append(line_number) - elif attr == "exists" and vval: - xml_handle_exists(value, elemt_obj, attr, vval) - rm_key_list.append(attr) - rm_key_list.append(line_number) - xml_handle_comment(obj, line_number, line_loc, elemt_obj) - elif ele_type == "field" and attr == "unit": - xml_handle_units(elemt_obj, vval) - xml_handle_comment(obj, line_number, line_loc, elemt_obj) - elif attr in allowed_attr and not isinstance(vval, dict) and vval: - validate_field_attribute_and_value(attr, vval, allowed_attr, value) - elemt_obj.set(attr, check_for_mapping_char_other(vval)) - rm_key_list.append(attr) - rm_key_list.append(line_number) - xml_handle_comment(obj, line_number, line_loc, elemt_obj) - - for key in rm_key_list: - del value[key] - # Check for skipped attributes - check_for_skipped_attributes(ele_type, value, allowed_attr, verbose) - - if isinstance(value, dict) and value != {}: - recursive_build(elemt_obj, value, verbose) - - -def xml_handle_comment( - obj: ET.Element, - line_annotation: str, - line_loc_no: int, - xml_ele: ET.Element = None, - is_def_cmnt: bool = False, -): - """Handle comment. - - Add xml comment: check for comments searched by 'line_annotation' - (e.g. __line__data) and line_loc_no (e.g. 30). It - does following tasks: - - 1. Rearrange comment elements of xml_ele and xml_ele where comment comes first. - 2. Append comment element when no xml_ele found as general comments. - """ - - line_info = (line_annotation, int(line_loc_no)) - if line_info in COMMENT_BLOCKS: # noqa: F821 - cmnt = COMMENT_BLOCKS.get_comment_by_line_info(line_info) # noqa: F821 - cmnt_text = cmnt.get_comment_text_list() - - # Check comment for definition element and return - if is_def_cmnt: - return cmnt_text - if xml_ele is not None: - obj.remove(xml_ele) - for string in cmnt_text: - # Format comment string to preserve text nxdl to yaml and vice versa - string = format_nxdl_doc(string) - obj.append(ET.Comment(string)) - obj.append(xml_ele) - elif not is_def_cmnt and xml_ele is None: - for string in cmnt_text: - obj.append(ET.Comment(string)) - - # The searched comment is not related with definition element - return [] - - -def recursive_build(obj, dct, verbose): - """Walk through nested dictionary. - Parameters: - ----------- - obj : ET.Element - Obj is the current node of the XML tree where we want to append to. - dct : dict - dct is the nested python dictionary which represents the content of a child and - its successors. - - Note: NXDL fields may contain attributes but trigger no recursion so attributes are leafs. - """ - for keyword, value in iter(dct.items()): - if "__line__" in keyword: - continue - line_number = f"__line__{keyword}" - line_loc = dct[line_number] - keyword_name, keyword_type = nx_name_type_resolving(keyword) - check_keyword_variable(verbose, dct, keyword, value) - if verbose: - print(f"keyword_name:{keyword_name} keyword_type {keyword_type}\n") - - if keyword[-6:] == "(link)": - xml_handle_link(dct, obj, keyword, value, verbose) - elif keyword[-8:] == "(choice)": - xml_handle_choice(dct, obj, keyword, value) - # The below xml_symbol clause is for the symbols that come ubde filed or attributes - # Root level symbols has been inside nyaml2nxdl() - elif keyword_type == "" and keyword_name == "symbols": - xml_handle_symbols(dct, obj, keyword, value) - - elif (keyword_type in NX_CLSS) or ( - keyword_type not in [*NX_TYPE_KEYS, "", *NX_NEW_DEFINED_CLASSES] - ): - elem_type = "group" - # we can be sure we need to instantiate a new group - xml_handle_fields_or_group( - dct, - obj, - keyword, - value, - elem_type, - YAML_GROUP_ATTRIBUTES, - verbose=False, - ) - - elif keyword_name[0:2] == NX_ATTR_IDNT: # check if obj qualifies - xml_handle_attributes(dct, obj, keyword, value, verbose) - elif keyword == "doc": - xml_handle_doc(obj, value, line_number, line_loc) - elif keyword == NX_UNIT_IDNT: - xml_handle_units(obj, value) - elif keyword == "enumeration": - xml_handle_enumeration(dct, obj, keyword, value, verbose) - elif keyword == "dimensions": - xml_handle_dimensions(dct, obj, keyword, value) - elif keyword == "exists": - xml_handle_exists(dct, obj, keyword, value) - # Handles fileds e.g. AXISNAME - elif keyword_name != "" and "__line__" not in keyword_name: - elem_type = "field" - xml_handle_fields_or_group( - dct, - obj, - keyword, - value, - elem_type, - YAML_FIELD_ATTRIBUTES, - verbose=False, - ) - else: - raise ValueError( - f"An unknown type of element {keyword} has been found which is " - f"not be able to be resolved. Check around line {dct[line_number]}" - ) - - -def extend_doc_type(doc_type, new_component, comment=False): - """Extend doc type for etree.tostring function - - Extend doc type to build DOM and process instruction comments. - """ - start_sym = "" - if comment: - start_sym = "" - return doc_type + "\n" + start_sym + new_component + end_sym - - -def pretty_print_xml(xml_root, output_xml, def_comments=None): - """Print in nxdl.xml file. - - Print better human-readable indented and formatted xml file using - built-in libraries and preceding XML processing instruction - """ - # Handle DOM as doc_type - doc_type = '' - - if DOM_COMMENT: - doc_type = extend_doc_type(doc_type, DOM_COMMENT, comment=True) - if def_comments: - for string in def_comments: - doc_type = extend_doc_type(doc_type, string, comment=True) - - tmp_xml = "tmp.xml" - xml_string = ET.tostring( - xml_root, - pretty_print=True, - encoding="UTF-8", - xml_declaration=True, - doctype=doc_type, - ) - with open(tmp_xml, "wb") as file_tmp: - file_tmp.write(xml_string) - flag = False - with open(tmp_xml, "r", encoding="utf-8") as file_out: - with open(output_xml, "w", encoding="utf-8") as file_out_mod: - for i in file_out.readlines(): - i = unquote(i) - if "" not in i and "" not in i and flag is False: - file_out_mod.write(i) - elif "" in i and "" in i: - file_out_mod.write(i) - elif "" in i and "" not in i: - flag = True - white_spaces = len(i) - len(i.lstrip()) - file_out_mod.write(i) - elif "" not in i and "" not in i and flag is True: - file_out_mod.write((white_spaces + 5) * " " + i) - elif "" not in i and "" in i and flag is True: - file_out_mod.write(white_spaces * " " + i) - flag = False - tmp_xml_path = pathlib.Path(tmp_xml) - pathlib.Path.unlink(tmp_xml_path) - - -# pylint: disable=too-many-statements -def nyaml2nxdl(input_file: str, out_file, verbose: bool): - """ - Main of the nyaml2nxdl converter, creates XML tree, namespace and - schema, definitions then evaluates a nested dictionary of groups recursively and - fields or (their) attributes as children of the groups - """ - def_attributes = [ - "deprecated", - "ignoreExtraGroups", - "category", - "type", - "ignoreExtraFields", - "ignoreExtraAttributes", - "restricts", - ] - yml_appdef = yml_reader(input_file) - def_cmnt_text = [] - if verbose: - print(f"input-file: {input_file}\n") - print("application/base contains the following root-level entries:\n") - print(str(yml_appdef.keys())) - # etree does not allow to set namespace-map after root creation - # So, mimic a nsmap and fill it later as dict has hash property - nsmap = { - None: "http://definition.nexusformat.org/nxdl/3.1", - } - xml_root = ET.Element("definition", attrib={}, nsmap=nsmap) - assert ( - "category" in yml_appdef.keys() - ), "Required root-level keyword category is missing!" - assert yml_appdef["category"] in [ - "application", - "base", - ], "Only \ -application and base are valid categories!" - assert "doc" in yml_appdef.keys(), "Required root-level keyword doc is missing!" - - name_extends = "" - yml_appdef_copy = yml_appdef.copy() - for kkey, vvalue in yml_appdef_copy.items(): - if "__line__" in kkey: - continue - line_number = f"__line__{kkey}" - line_loc_no = yml_appdef[line_number] - if not isinstance(vvalue, dict) and kkey in def_attributes: - xml_root.set(kkey, str(vvalue) or "") - cmnt_text = xml_handle_comment( - xml_root, line_number, line_loc_no, is_def_cmnt=True - ) - def_cmnt_text += cmnt_text - - del yml_appdef[line_number] - del yml_appdef[kkey] - # Taking care of name and extends - elif "NX" in kkey: - # Taking the attribute order but the correct value will be stored later - # check for name first or type first if (NXobject)NXname then type first - l_bracket_ind = kkey.rfind("(") - r_bracket_ind = kkey.rfind(")") - if l_bracket_ind == 0: - extend = kkey[1:r_bracket_ind] - name = kkey[r_bracket_ind + 1 :] - xml_root.set("extends", extend) - xml_root.set("name", name) - elif l_bracket_ind > 0: - name = kkey[0:l_bracket_ind] - extend = kkey[l_bracket_ind + 1 : r_bracket_ind] - xml_root.set("name", name) - xml_root.set("extends", extend) - else: - name = kkey - xml_root.set("name", name) - xml_root.set("extends", "NXobject") - cmnt_text = xml_handle_comment( - xml_root, line_number, line_loc_no, is_def_cmnt=True - ) - def_cmnt_text += cmnt_text if cmnt_text else [] - - name_extends = kkey - - if "type" not in xml_root.attrib: - xml_root.set("type", "group") - # Taking care of namespaces - namespaces = { - "xsi": "http://www.w3.org/2001/XMLSchema-instance", - } - # Fill nsmap variable here - nsmap.update(namespaces) - xml_root.attrib[ - "{http://www.w3.org/2001/XMLSchema-instance}schemaLocation" - ] = "http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd".replace(" ", "%20") - - # Taking care of Symbols elements - if "symbols" in yml_appdef.keys(): - xml_handle_symbols(yml_appdef, xml_root, "symbols", yml_appdef["symbols"]) - - del yml_appdef["symbols"] - del yml_appdef["__line__symbols"] - if isinstance(yml_appdef["doc"], str): - assert yml_appdef["doc"] != "", "Doc has to be a non-empty string!" - elif isinstance(yml_appdef["doc"], list): - assert any( - yml_appdef["doc"] - ), "One of the doc elements has to be a non-empty string!" - - line_number = "__line__doc" - line_loc_no = yml_appdef[line_number] - xml_handle_doc(xml_root, yml_appdef["doc"], line_number, line_loc_no) - - del yml_appdef["doc"] - - root_keys = 0 - for key in yml_appdef.keys(): - if "__line__" not in key: - root_keys += 1 - extra_key = key - - assert root_keys == 1, ( - f"Accepting at most keywords: category, doc, symbols, and NX... " - f"at root-level! check key at root level {extra_key}" - ) - - assert ( - "NX" in name_extends and len(name_extends) > 2 - ), "NX \ -keyword has an invalid pattern, or is too short!" - # Taking care if definition has empty content - if yml_appdef[name_extends]: - recursive_build(xml_root, yml_appdef[name_extends], verbose) - # Taking care of comments that comes at the end of file that is might not be intended for - # any nxdl elements. - if COMMENT_BLOCKS[-1].has_post_comment: # noqa: F821 - post_comment = COMMENT_BLOCKS[-1] # noqa: F821 - (lin_annot, line_loc) = post_comment.get_line_info() - xml_handle_comment(xml_root, lin_annot, line_loc) - - # Note: Just to keep the functionality if we need this later. - default_attr = False - if default_attr: - check_for_default_attribute_and_value(xml_root) - pretty_print_xml(xml_root, out_file, def_cmnt_text) - if verbose: - print("Parsed YAML to NXDL successfully\n") diff --git a/dev_tools/nyaml2nxdl/nyaml2nxdl_helper.py b/dev_tools/nyaml2nxdl/nyaml2nxdl_helper.py deleted file mode 100644 index 7587df1de1..0000000000 --- a/dev_tools/nyaml2nxdl/nyaml2nxdl_helper.py +++ /dev/null @@ -1,315 +0,0 @@ -#!/usr/bin/env python3 -"""File consists of helping functions and variables. - -The functions and variables are utilised in the converting tool -to convert from nyaml to nxdl and vice versa. -""" -# -*- coding: utf-8 -*- -# -# 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. -# - -import hashlib -from typing import Callable - -from yaml.composer import Composer -from yaml.constructor import Constructor -from yaml.loader import Loader -from yaml.nodes import ScalarNode -from yaml.resolver import BaseResolver - -# Yaml library does not except the keys (escape char "\t" and yaml separator ":") -ESCAPE_CHAR_DICT_IN_YAML = {"\t": " "} -ESCAPE_CHAR_DICT_IN_XML = {val: key for key, val in ESCAPE_CHAR_DICT_IN_YAML.items()} - -# Set up attributes for nxdl version -NXDL_GROUP_ATTRIBUTES = ( - "optional", - "recommended", - "name", - "type", - "maxOccurs", - "minOccurs", - "deprecated", -) -NXDL_FIELD_ATTRIBUTES = ( - "optional", - "recommended", - "name", - "type", - "axes", - "axis", - "data_offset", - "interpretation", - "long_name", - "maxOccurs", - "minOccurs", - "nameType", - "primary", - "signal", - "stride", - "required", - "deprecated", - "units", -) - -NXDL_ATTRIBUTES_ATTRIBUTES = ( - "name", - "type", - "recommended", - "optional", - "deprecated", -) - -NXDL_LINK_ATTRIBUTES = ("name", "target", "napimount") - -# Set up attributes for yaml version -YAML_GROUP_ATTRIBUTES = (*NXDL_GROUP_ATTRIBUTES, "exists") - -YAML_FIELD_ATTRIBUTES = (*NXDL_FIELD_ATTRIBUTES[0:-1], "unit", "exists") - -YAML_ATTRIBUTES_ATTRIBUTES = ( - *NXDL_ATTRIBUTES_ATTRIBUTES, - "minOccurs", - "maxOccurs", - "exists", -) - -YAML_LINK_ATTRIBUTES = NXDL_LINK_ATTRIBUTES - - -def remove_namespace_from_tag(tag): - """Helper function to remove the namespace from an XML tag.""" - if isinstance(tag, Callable) and tag.__name__ == "Comment": - return "!--" - else: - return tag.split("}")[-1] - - -class LineLoader(Loader): # pylint: disable=too-many-ancestors - """Class to load yaml file with extra non yaml items. - - LineLoader parses a yaml into a python dictionary extended with extra items. - The new items have as keys __line__ and as values the yaml file line number - """ - - def compose_node(self, parent, index): - """Compose node and return node.""" - # the line number where the previous token has ended (plus empty lines) - node = Composer.compose_node(self, parent, index) - node.__line__ = self.line + 1 - return node - - def construct_mapping(self, node, deep=False): - """Construct mapping between node info and line info.""" - node_pair_lst_for_appending = [] - - # Visit through node-pair list - for key_node in node.value: - shadow_key_node = ScalarNode( - tag=BaseResolver.DEFAULT_SCALAR_TAG, - value="__line__" + key_node[0].value, - ) - shadow_value_node = ScalarNode( - tag=BaseResolver.DEFAULT_SCALAR_TAG, value=key_node[0].__line__ - ) - node_pair_lst_for_appending.append((shadow_key_node, shadow_value_node)) - - node.value = node.value + node_pair_lst_for_appending - return Constructor.construct_mapping(self, node, deep=deep) - - -def get_yaml_escape_char_dict(): - """Get escape char and the way to skip them in yaml.""" - return ESCAPE_CHAR_DICT_IN_YAML - - -def get_yaml_escape_char_reverter_dict(): - """To revert yaml escape char in xml constructor from yaml.""" - - return ESCAPE_CHAR_DICT_IN_XML - - -def type_check(nx_type): - """Check for nexus type if type is NX_CHAR get '' or get as it is.""" - - if nx_type in ["NX_CHAR", ""]: - nx_type = "" - else: - nx_type = f"({nx_type})" - return nx_type - - -def get_node_parent_info(tree, node): - """Return tuple of (parent, index). - - parent = parent node is the first level node under tree node - index = index of grand child node of tree - """ - - # map from grand child to parent which is child of tree - parent_map = {c: p for p in tree.iter() for c in p} - parent = parent_map[node] - return parent, list(parent).index(node) - - -def clean_empty_lines(line_list): - """Clean up empty lines by top part and bottom and part.""" - if not isinstance(line_list, list): - line_list = line_list.split("\n") if "\n" in line_list else [""] - - start_non_empty_line = -1 - ends_non_empty_line = None - # Find the index of first non-empty line - for ind, line in enumerate(line_list): - if len(line.strip()) > 1: - start_non_empty_line = ind - break - - # Find the index of the last non-empty line - for ind, line in enumerate(reversed(line_list)): - if len(line.strip()) > 1: - ends_non_empty_line = -ind - break - - if ends_non_empty_line == 0: - ends_non_empty_line = None - return line_list[start_non_empty_line:ends_non_empty_line] - - -def nx_name_type_resolving(tmp): - """Separate name and NeXus type - - Extracts the eventual custom name {optional_string} - and type {nexus_type} from a YML section string. - YML section string syntax: optional_string(nexus_type) - """ - if tmp.count("(") == 1 and tmp.count(")") == 1: - # we can safely assume that every valid YML key resolves - # either an nx_ (type, base, candidate) class contains only 1 '(' and ')' - index_start = tmp.index("(") - index_end = tmp.index(")", index_start + 1) - if index_start > index_end: - raise ValueError( - f"Check name and type combination {tmp} which can not be resolved." - ) - if index_end - index_start == 1: - raise ValueError( - f"Check name(type) combination {tmp}, properly not defined." - ) - typ = tmp[index_start + 1 : index_end] - nam = tmp.replace("(" + typ + ")", "") - return nam, typ - - # or a name for a member - typ = "" - nam = tmp - return nam, typ - - -def get_sha256_hash(file_name): - """Generate a sha256_hash for a given file.""" - sha_hash = hashlib.sha256() - - with open( - file=file_name, - mode="rb", - ) as file_obj: - # Update hash for each 4k block of bytes - for b_line in iter(lambda: file_obj.read(4096), b""): - sha_hash.update(b_line) - return sha_hash.hexdigest() - - -def extend_yamlfile_by_nxdl_as_comment( - yaml_file, file_to_be_appended, top_lines_list=None -): - """Extend yaml file by the file_to_be_appended as comment.""" - - with open(yaml_file, mode="a+", encoding="utf-8") as f1_obj: - if top_lines_list: - for line in top_lines_list: - f1_obj.write(line) - - with open(file_to_be_appended, mode="r", encoding="utf-8") as f2_obj: - for line in f2_obj: - f1_obj.write(f"# {line}") - - -def separate_hash_yaml_and_nxdl(yaml_file, sep_yaml, sep_xml): - """Separate yaml, SHA hash and nxdl parts. - - Separate the provided yaml file into yaml, nxdl and hash if yaml was extended with - nxdl at the end of yaml as - - - '\n# ++++++++++++++++++++++++++++++++++ SHA HASH \ - ++++++++++++++++++++++++++++++++++\n' - # ' - - """ - sha_hash = "" - with open(yaml_file, "r", encoding="utf-8") as inp_file: - lines = inp_file.readlines() - # file to write yaml part - with open(sep_yaml, "w", encoding="utf-8") as yml_f_ob, open( - sep_xml, "w", encoding="utf-8" - ) as xml_f_ob: - write_on_yaml = True - - last_line = lines[0] - for line in lines[1:]: - # Write in file when ensured that the next line is not with '++ SHA HASH ++' - if "++ SHA HASH ++" not in line and write_on_yaml: - yml_f_ob.write(last_line) - last_line = line - elif "++ SHA HASH ++" in line: - write_on_yaml = False - last_line = "" - elif not write_on_yaml and not last_line: - # The first line of xml file has been found so in future write lines directly - # into xml file. - if not sha_hash: - sha_hash = line.split("# ", 1)[-1].strip() - else: - xml_f_ob.write(line[2:]) - # If the yaml fiile does not contain any hash for nxdl then we may have last line. - if last_line: - yml_f_ob.write(last_line) - - return sha_hash - - -def is_dom_comment(text): - """Analyze a comment, whether it is a dom comment or not. - - Return true if dom comment. - """ - - # some signature keywords to distingush dom comments from other comments. - signature_keyword_list = [ - "NeXus", - "GNU Lesser General Public", - "Free Software Foundation", - "Copyright (C)", - "WITHOUT ANY WARRANTY", - ] - for keyword in signature_keyword_list: - if keyword not in text: - return False - - return True diff --git a/dev_tools/tests/data/doc_nxdl2yaml.nxdl.xml b/dev_tools/tests/data/doc_nxdl2yaml.nxdl.xml deleted file mode 100644 index 54e539153c..0000000000 --- a/dev_tools/tests/data/doc_nxdl2yaml.nxdl.xml +++ /dev/null @@ -1,72 +0,0 @@ - - - - - - This is a definition for data to be archived by ICAT (http://www.icatproject.org/). - - .. text from the icatproject.org site - - the database (with supporting software) that provides an - interface to all ISIS experimental data and will provide - a mechanism to link all aspects of ISIS research from - proposal through to publication. - - - - - - - unique identifier for the experimenta - lkokö - sddfdfd - - This concept is related to term `12.58`_ of the ISO 18115-1:2023 standard. - .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 - - This is test doc. - - - - - Part1: Text line 1. - part1: Text line 2 - - This concept is related to term `term`_ of the spec standard. - .. _term: url - - - - - ID of user or DAQ define group of data files - Brief summary of the collection, including grouping criteria - - - - - unique identifier for this measurement as provided by the facility - - - - - diff --git a/dev_tools/tests/data/doc_yaml2nxdl.yaml b/dev_tools/tests/data/doc_yaml2nxdl.yaml deleted file mode 100644 index 94b3763256..0000000000 --- a/dev_tools/tests/data/doc_yaml2nxdl.yaml +++ /dev/null @@ -1,54 +0,0 @@ -category: application -doc: - - | - This is a definition for data to be archived by ICAT (http://www.icatproject.org/). - - .. text from the icatproject.org site - - the database (with supporting software) that provides an - interface to all ISIS experimental data and will provide - a mechanism to link all aspects of ISIS research from - proposal through to publication. - - | - xref: - spec: ISO 18115-1:2023 - term: 1.1 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:1.1 -type: group -NXarchive(NXobject): - (NXentry)entry: - \@index: - title: - experiment_identifier(NX_CHAR): - doc: - - | - "unique identifier for the experimenta - lkokö - sddfdfd" - - | - xref: - spec: ISO 18115-1:2023 - term: 12.58 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 - - | - "This is test doc." - experiment_description(NX_CHAR): - doc: - - | - Part1: Text line 1. - part1: Text line 2 - - - | - xref: - spec: spec - term: term - url: url - - collection_identifier(NX_CHAR): - doc: | - ID of user or DAQ define group of data files - Brief summary of the collection, including grouping criteria - entry_identifier(NX_CHAR): - doc: | - unique identifier for this measurement as provided by the facility - start_time(NX_DATE_TIME): diff --git a/dev_tools/tests/data/ref_doc_nxdl2yaml.yaml b/dev_tools/tests/data/ref_doc_nxdl2yaml.yaml deleted file mode 100644 index 8ad3bb82b9..0000000000 --- a/dev_tools/tests/data/ref_doc_nxdl2yaml.yaml +++ /dev/null @@ -1,47 +0,0 @@ -category: application -doc: - - | - This is a definition for data to be archived by ICAT (http://www.icatproject.org/). - - | - .. text from the icatproject.org site - - | - the database (with supporting software) that provides an - interface to all ISIS experimental data and will provide - a mechanism to link all aspects of ISIS research from - proposal through to publication. -type: group -NXarchive(NXobject): - (NXentry)entry: - \@index: - title: - experiment_identifier(NX_CHAR): - doc: - - | - unique identifier for the experimenta - lkokö - sddfdfd - - | - "xref: - spec: ISO 18115-1:2023 - term: 12.58 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58" - - | - This is test doc. - experiment_description(NX_CHAR): - doc: - - | - Part1: Text line 1. - part1: Text line 2 - - | - "xref: - spec: spec - term: term - url: url" - collection_identifier(NX_CHAR): - doc: | - ID of user or DAQ define group of data files - Brief summary of the collection, including grouping criteria - entry_identifier(NX_CHAR): - doc: | - unique identifier for this measurement as provided by the facility - start_time(NX_DATE_TIME): diff --git a/dev_tools/tests/data/ref_doc_yaml2nxdl.nxdl.xml b/dev_tools/tests/data/ref_doc_yaml2nxdl.nxdl.xml deleted file mode 100644 index 854447e26d..0000000000 --- a/dev_tools/tests/data/ref_doc_yaml2nxdl.nxdl.xml +++ /dev/null @@ -1,75 +0,0 @@ - - - - - - This is a definition for data to be archived by ICAT (http://www.icatproject.org/). - - .. text from the icatproject.org site - - the database (with supporting software) that provides an - interface to all ISIS experimental data and will provide - a mechanism to link all aspects of ISIS research from - proposal through to publication. - - This concept is related to term `1.1`_ of the ISO 18115-1:2023 standard. - .. _1.1: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:1.1 - - - - - - - "unique identifier for the experimenta - lkokö - sddfdfd" - - This concept is related to term `12.58`_ of the ISO 18115-1:2023 standard. - .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 - - "This is test doc." - - - - - Part1: Text line 1. - part1: Text line 2 - - This concept is related to term `term`_ of the spec standard. - .. _term: url - - - - - ID of user or DAQ define group of data files - Brief summary of the collection, including grouping criteria - - - - - unique identifier for this measurement as provided by the facility - - - - - diff --git a/dev_tools/tests/test_nyaml2nxdl.py b/dev_tools/tests/test_nyaml2nxdl.py deleted file mode 100755 index 559a382cce..0000000000 --- a/dev_tools/tests/test_nyaml2nxdl.py +++ /dev/null @@ -1,185 +0,0 @@ -from pathlib import Path - -import lxml.etree as ET -import pytest -from click.testing import CliRunner - -from ..nyaml2nxdl import nyaml2nxdl as conv -from ..nyaml2nxdl.nyaml2nxdl_forward_tools import handle_each_part_doc -from ..nyaml2nxdl.nyaml2nxdl_helper import LineLoader -from ..nyaml2nxdl.nyaml2nxdl_helper import remove_namespace_from_tag -from ..utils.nxdl_utils import find_definition_file - - -def test_conversion(): - root = find_definition_file("NXentry") - result = CliRunner().invoke(conv.launch_tool, ["--input-file", root]) - assert result.exit_code == 0 - # Replace suffixes - yaml = root.parent / Path(root.with_suffix("").stem + "_parsed.yaml") - result = CliRunner().invoke(conv.launch_tool, ["--input-file", yaml]) - assert result.exit_code == 0 - new_root = yaml.with_suffix(".nxdl.xml") - with open(root, encoding="utf-8", mode="r") as tmp_f: - root_content = tmp_f.readlines() - with open(new_root, encoding="utf-8", mode="r") as tmp_f: - new_root_content = tmp_f.readlines() - assert root_content == new_root_content - Path.unlink(yaml) - Path.unlink(new_root) - - -def test_yaml2nxdl_doc(): - """To test the doc style from yaml to nxdl.""" - pwd = Path(__file__).parent - - doc_file = pwd / "data/doc_yaml2nxdl.yaml" - ref_doc_file = pwd / "data/ref_doc_yaml2nxdl.nxdl.xml" - out_doc_file = ( - pwd / "data/doc_yaml2nxdl.nxdl.xml" - ) # doc_file.with_suffix('.nxdl.xml') - # Test yaml2nxdl - # Generates '../data/doc_text.nxdl.xml' - result = CliRunner().invoke(conv.launch_tool, ["--input-file", str(doc_file)]) - if result.exit_code != 0: - Path.unlink(out_doc_file) - assert result.exit_code == 0, f"Error: Having issue running input file {doc_file}." - - ref_nxdl = ET.parse(str(ref_doc_file)).getroot() - out_nxdl = ET.parse(str(out_doc_file)).getroot() - - def compare_nxdl_doc(parent1, parent2): - if len(parent1) > 0 and len(parent2) > 0: - for par1, par2 in zip(parent1, parent2): - compare_nxdl_doc(par1, par2) - - elif ( - remove_namespace_from_tag(parent1.tag) == "doc" - and remove_namespace_from_tag(parent2.tag) == "doc" - ): - assert ( - parent1.text == parent2.text - ), f"DOCS ARE NOT SAME: node {parent1}, node {parent2}" - - compare_nxdl_doc(ref_nxdl, out_nxdl) - - Path.unlink(out_doc_file) - - -def test_nxdl2yaml_doc(): - """To test the doc style from nxdl to yaml.""" - - pwd = Path(__file__).parent - nxdl_file = pwd / "data/doc_nxdl2yaml.nxdl.xml" - ref_yaml = pwd / "data/ref_doc_nxdl2yaml.yaml" - parsed_yaml_file = pwd / "data/doc_nxdl2yaml_parsed.yaml" - - result = CliRunner().invoke( - conv.launch_tool, ["--input-file", str(nxdl_file), "--do-not-store-nxdl"] - ) - - if result.exit_code != 0: - Path.unlink(parsed_yaml_file) - - assert result.exit_code == 0, "Error in converter execuation." - - with open(ref_yaml, mode="r", encoding="utf-8") as yaml1, open( - parsed_yaml_file, mode="r", encoding="utf-8" - ) as yaml2: - yaml_dict1 = LineLoader(yaml1).get_single_data() - yaml_dict2 = LineLoader(yaml2).get_single_data() - - def compare_yaml_doc(yaml_dict1, yaml_dict2): - for k_val1, k_val2 in zip(yaml_dict1.items(), yaml_dict2.items()): - key1, val1 = k_val1 - key2, val2 = k_val2 - if key1 == "doc" and key2 == "doc": - assert val1 == val2, "Doc texts are not the same." - elif isinstance(val1, dict) and isinstance(val2, dict): - compare_yaml_doc(val1, val2) - - compare_yaml_doc(yaml_dict1, yaml_dict2) - Path.unlink(parsed_yaml_file) - - -@pytest.mark.parametrize( - "test_input,output,is_valid", - [ - ( - """ - xref: - spec: - term: - url: - """, - " This concept is related to term ``_ " - "of the standard.\n.. _: ", - True, - ), - ( - """ - xref: - spec: - term: - url: - """, - "Found invalid xref. Please make sure that your xref entries are valid yaml.", - False, - ), - ( - """ - xref: - spec: - term: - url: - term: - """, - "Invalid xref. It contains nested or duplicate keys.", - False, - ), - ( - """ - xref: - spec: - term: - url: - hallo: - """, - "Invalid xref. Too many keys.", - False, - ), - ( - """ - xref: - spec: - my_key: - url: - """, - "Invalid xref key `my_key`. Must be one of `term`, `spec` or `url`.", - False, - ), - ( - """ - xref: - spec: - term: - test: - url: - """, - "Invalid xref. It contains nested or duplicate keys.", - False, - ), - ], -) -def test_handle_xref(test_input, output, is_valid): - """ - Tests whether the xref generates a correct docstring. - """ - if is_valid: - assert handle_each_part_doc(test_input) == output - return - - with pytest.raises(ValueError) as err: - handle_each_part_doc(test_input) - - assert output == err.value.args[0] diff --git a/dev_tools/utils/nxdl_utils.py b/dev_tools/utils/nxdl_utils.py index 5c6d3db458..efba439bec 100644 --- a/dev_tools/utils/nxdl_utils.py +++ b/dev_tools/utils/nxdl_utils.py @@ -4,48 +4,26 @@ import os import textwrap +import xml.etree.ElementTree as ET from functools import lru_cache from glob import glob -from pathlib import Path -import lxml.etree as ET -from lxml.etree import ParseError as xmlER -from ..nyaml2nxdl.nyaml2nxdl_helper import remove_namespace_from_tag - - -class NxdlAttributeNotFoundError(Exception): - """An exception to throw when an Nxdl attribute is not found.""" - - -def get_nexus_definitions_path(): - """Check NEXUS_DEF_PATH variable. - If it is empty, this function is filling it""" - try: # either given by sys env - return os.environ["NEXUS_DEF_PATH"] - except KeyError: # or it should be available locally under the dir 'definitions' - local_dir = Path(__file__).resolve().parent - for _ in range(2): - local_dir = local_dir.parent - return local_dir - - -nexus_def_path = get_nexus_definitions_path() +class NxdlAttributeError(Exception): + """An exception for throwing an error when an Nxdl attribute is not found.""" def get_app_defs_names(): """Returns all the AppDef names without their extension: .nxdl.xml""" - app_def_path_glob = nexus_def_path / "applications" / "*.nxdl*" - - contrib_def_path_glob = Path(nexus_def_path) / "contributed_definitions" / "*.nxdl*" - - files = sorted(glob(app_def_path_glob)) - for nexus_file in sorted(contrib_def_path_glob): - root = get_xml_root(nexus_file) - if root.attrib["category"] == "application": - files.append(nexus_file) - - return [Path(file).stem for file in files] + ["NXroot"] + app_def_path_glob = ( + f"{get_nexus_definitions_path()}{os.sep}applications{os.sep}*.nxdl*" + ) + contrib_def_path_glob = ( + f"{get_nexus_definitions_path()}{os.sep}" + f"contributed_definitions{os.sep}*.nxdl*" + ) + files = sorted(glob(app_def_path_glob)) + sorted(glob(contrib_def_path_glob)) + return [os.path.basename(file).split(".")[0] for file in files] + ["NXroot"] @lru_cache(maxsize=None) @@ -55,6 +33,16 @@ def get_xml_root(file_path): return ET.parse(file_path).getroot() +def get_nexus_definitions_path(): + """Check NEXUS_DEF_PATH variable. + If it is empty, this function is filling it""" + try: # either given by sys env + return os.environ["NEXUS_DEF_PATH"] + except KeyError: # or it should be available locally under the dir 'definitions' + local_dir = os.path.abspath(os.path.dirname(__file__)) + return os.path.join(local_dir, f"..{os.sep}..") + + def get_hdf_root(hdf_node): """Get the root HDF5 node""" node = hdf_node @@ -79,34 +67,43 @@ def get_hdf_parent(hdf_info): def get_parent_path(hdf_name): """Get parent path""" - return hdf_name.rsplit("/", 1)[0] + return "/".join(hdf_name.split("/")[:-1]) def get_hdf_info_parent(hdf_info): """Get the hdf_info for the parent of an hdf_node in an hdf_info""" if "hdf_path" not in hdf_info: return {"hdf_node": hdf_info["hdf_node"].parent} - node = get_hdf_parent(hdf_info) + node = ( + get_hdf_root(hdf_info["hdf_node"]) + if "hdf_root" not in hdf_info + else hdf_info["hdf_root"] + ) + for child_name in hdf_info["hdf_path"].split("/")[1:-1]: + node = node[child_name] return {"hdf_node": node, "hdf_path": get_parent_path(hdf_info["hdf_path"])} def get_nx_class(nxdl_elem): """Get the nexus class for a NXDL node""" - if "category" in nxdl_elem.attrib: - return "" - return nxdl_elem.attrib.get("type", "NX_CHAR") + if "category" in nxdl_elem.attrib.keys(): + return None + try: + return nxdl_elem.attrib["type"] + except KeyError: + return "NX_CHAR" def get_nx_namefit(hdf_name, name, name_any=False): """Checks if an HDF5 node name corresponds to a child of the NXDL element - uppercase letters in front can be replaced by arbitrary name, but + uppercase letters in front can be replaced by arbitraty name, but uppercase to lowercase match is preferred, so such match is counted as a measure of the fit""" if name == hdf_name: return len(name) * 2 # count leading capitals counting = 0 - while counting < len(name) and name[counting].isupper(): + while counting < len(name) and name[counting].upper() == name[counting]: counting += 1 if ( name_any @@ -130,56 +127,63 @@ def get_nx_classes(): """Read base classes from the NeXus definition folder. Check each file in base_classes, applications, contributed_definitions. If its category attribute is 'base', then it is added to the list.""" - nexus_definition_path = nexus_def_path - base_classes = sorted(nexus_definition_path.glob("base_classes/*.nxdl.xml")) - applications = sorted(nexus_definition_path.glob("applications/*.nxdl.xml")) + base_classes = sorted( + glob(os.path.join(get_nexus_definitions_path(), "base_classes", "*.nxdl.xml")) + ) + applications = sorted( + glob(os.path.join(get_nexus_definitions_path(), "applications", "*.nxdl.xml")) + ) contributed = sorted( - nexus_definition_path.glob("contributed_definitions/*.nxdl.xml") + glob( + os.path.join( + get_nexus_definitions_path(), "contributed_definitions", "*.nxdl.xml" + ) + ) ) - nx_class = [] + nx_clss = [] for nexus_file in base_classes + applications + contributed: - try: - root = get_xml_root(nexus_file) - except xmlER as e: - raise ValueError(f"Getting an issue while parsing file {nexus_file}") from e + root = get_xml_root(nexus_file) if root.attrib["category"] == "base": - nx_class.append(nexus_file.stem) - return sorted(nx_class) + nx_clss.append(str(nexus_file[nexus_file.rindex(os.sep) + 1 :])[:-9]) + nx_clss = sorted(nx_clss) + return nx_clss def get_nx_units(): """Read unit kinds from the NeXus definition/nxdlTypes.xsd file""" - filepath = nexus_def_path / "nxdlTypes.xsd" + filepath = f"{get_nexus_definitions_path()}{os.sep}nxdlTypes.xsd" root = get_xml_root(filepath) units_and_type_list = [] for child in root: - units_and_type_list.extend(child.attrib.values()) + for i in child.attrib.values(): + units_and_type_list.append(i) flag = False - nx_units = [] for line in units_and_type_list: if line == "anyUnitsAttr": flag = True - elif "NX" in line and flag: + nx_units = [] + elif "NX" in line and flag is True: nx_units.append(line) elif line == "primitiveType": flag = False - + else: + pass return nx_units def get_nx_attribute_type(): """Read attribute types from the NeXus definition/nxdlTypes.xsd file""" - filepath = nexus_def_path / "nxdlTypes.xsd" - + filepath = get_nexus_definitions_path() + "/nxdlTypes.xsd" root = get_xml_root(filepath) units_and_type_list = [] for child in root: - units_and_type_list.extend(child.attrib.values()) + for i in child.attrib.values(): + units_and_type_list.append(i) flag = False - nx_types = [] for line in units_and_type_list: if line == "primitiveType": flag = True + nx_types = [] elif "NX" in line and flag is True: nx_types.append(line) elif line == "anyUnitsAttr": @@ -194,7 +198,7 @@ def get_node_name(node): Either as specified by the 'name' or taken from the type (nx_class). Note that if only class name is available, the NX prefix is removed and the string is converted to UPPER case.""" - if "name" in node.attrib: + if "name" in node.attrib.keys(): name = node.attrib["name"] else: name = node.attrib["type"] @@ -228,7 +232,7 @@ def belongs_to_capital(params): (act_htmlname, chk_name, name_any, nxdl_elem, child, name) = params # or starts with capital and no reserved words used if ( - (act_htmlname[0].isalpha() and act_htmlname[0].isupper()) + (name_any or "A" <= act_htmlname[0] <= "Z") and name != "doc" and name != "enumeration" ): @@ -242,7 +246,10 @@ def belongs_to_capital(params): ): continue # check if the name of another sibling fits better - name_any2 = child2.attrib.get("nameType") == "any" + name_any2 = ( + "nameType" in child2.attrib.keys() + and child2.attrib["nameType"] == "any" + ) fit2 = get_nx_namefit(chk_name, get_node_name(child2), name_any2) if fit2 > fit: return False @@ -253,35 +260,59 @@ def belongs_to_capital(params): def get_local_name_from_xml(element): """Helper function to extract the element tag without the namespace.""" - return remove_namespace_from_tag(element.tag) + return element.tag[element.tag.rindex("}") + 1 :] def get_own_nxdl_child_reserved_elements(child, name, nxdl_elem): """checking reserved elements, like doc, enumeration""" - local_name = get_local_name_from_xml(child) - if local_name == "doc" and name == "doc": - return set_nxdlpath(child, nxdl_elem, tag_name=name) - - if local_name == "enumeration" and name == "enumeration": - return set_nxdlpath(child, nxdl_elem, tag_name=name) + if get_local_name_from_xml(child) == "doc" and name == "doc": + if nxdl_elem.get("nxdlbase"): + child.set("nxdlbase", nxdl_elem.get("nxdlbase")) + child.set("nxdlbase_class", nxdl_elem.get("nxdlbase_class")) + child.set("nxdlpath", nxdl_elem.get("nxdlpath") + "/doc") + return child + if get_local_name_from_xml(child) == "enumeration" and name == "enumeration": + if nxdl_elem.get("nxdlbase"): + child.set("nxdlbase", nxdl_elem.get("nxdlbase")) + child.set("nxdlbase_class", nxdl_elem.get("nxdlbase_class")) + child.set("nxdlpath", nxdl_elem.get("nxdlpath") + "/enumeration") + return child return False def get_own_nxdl_child_base_types(child, class_type, nxdl_elem, name, hdf_name): - """checking base types of group, field, attribute""" + """checking base types of group, field,m attribute""" if get_local_name_from_xml(child) == "group": if ( class_type is None or (class_type and get_nx_class(child) == class_type) ) and belongs_to(nxdl_elem, child, name, class_type, hdf_name): - return set_nxdlpath(child, nxdl_elem) + if nxdl_elem.get("nxdlbase"): + child.set("nxdlbase", nxdl_elem.get("nxdlbase")) + child.set("nxdlbase_class", nxdl_elem.get("nxdlbase_class")) + child.set( + "nxdlpath", nxdl_elem.get("nxdlpath") + "/" + get_node_name(child) + ) + return child if get_local_name_from_xml(child) == "field" and belongs_to( nxdl_elem, child, name, None, hdf_name ): - return set_nxdlpath(child, nxdl_elem) + if nxdl_elem.get("nxdlbase"): + child.set("nxdlbase", nxdl_elem.get("nxdlbase")) + child.set("nxdlbase_class", nxdl_elem.get("nxdlbase_class")) + child.set( + "nxdlpath", nxdl_elem.get("nxdlpath") + "/" + get_node_name(child) + ) + return child if get_local_name_from_xml(child) == "attribute" and belongs_to( nxdl_elem, child, name, None, hdf_name ): - return set_nxdlpath(child, nxdl_elem) + if nxdl_elem.get("nxdlbase"): + child.set("nxdlbase", nxdl_elem.get("nxdlbase")) + child.set("nxdlbase_class", nxdl_elem.get("nxdlbase_class")) + child.set( + "nxdlpath", nxdl_elem.get("nxdlpath") + "/" + get_node_name(child) + ) + return child return False @@ -293,10 +324,16 @@ def get_own_nxdl_child( class_type - nxdl type or hdf classname (for groups, it is obligatory) hdf_name - hdf name""" for child in nxdl_elem: - if child.attrib.get("name") == name: - return set_nxdlpath(child, nxdl_elem) + if "name" in child.attrib and child.attrib["name"] == name: + if nxdl_elem.get("nxdlbase"): + child.set("nxdlbase", nxdl_elem.get("nxdlbase")) + child.set("nxdlbase_class", nxdl_elem.get("nxdlbase_class")) + child.set( + "nxdlpath", nxdl_elem.get("nxdlpath") + "/" + get_node_name(child) + ) + return child for child in nxdl_elem: - if child.attrib.get("name") == name: + if "name" in child.attrib and child.attrib["name"] == name: child.set("nxdlbase", nxdl_elem.get("nxdlbase")) return child @@ -320,9 +357,14 @@ def find_definition_file(bc_name): """ bc_filename = None for nxdl_folder in ["contributed_definitions", "base_classes", "applications"]: - nxdl_file = nexus_def_path / nxdl_folder / f"{bc_name}.nxdl.xml" - if nxdl_file.exists(): - bc_filename = nexus_def_path / nxdl_folder / f"{bc_name}.nxdl.xml" + if os.path.exists( + f"{get_nexus_definitions_path()}{os.sep}" + f"{nxdl_folder}{os.sep}{bc_name}.nxdl.xml" + ): + bc_filename = ( + f"{get_nexus_definitions_path()}{os.sep}" + f"{nxdl_folder}{os.sep}{bc_name}.nxdl.xml" + ) break return bc_filename @@ -378,8 +420,11 @@ def get_required_string(nxdl_elem): if is_optional or is_minoccurs: return "<>" # default optionality: in BASE CLASSES is true; in APPLICATIONS is false - if nxdl_elem.get("nxdlbase_class") == "base": - return "<>" + try: + if nxdl_elem.get("nxdlbase_class") == "base": + return "<>" + except TypeError: + return "<>" return "<>" @@ -387,7 +432,7 @@ def get_required_string(nxdl_elem): def write_doc_string(logger, doc, attr): """Simple function that prints a line in the logger if doc exists""" if doc: - logger.debug("@%s [NX_CHAR]", attr) + logger.debug("@" + attr + " [NX_CHAR]") return logger, doc, attr @@ -520,7 +565,7 @@ def other_attrs( def get_node_concept_path(elem): """get the short version of nxdlbase:nxdlpath""" - return f'{elem.get("nxdlbase").split("/")[-1]}:{elem.get("nxdlpath")}' + return str(elem.get("nxdlbase").split("/")[-1] + ":" + elem.get("nxdlpath")) def get_doc(node, ntype, nxhtml, nxpath): @@ -543,7 +588,7 @@ def get_doc(node, ntype, nxhtml, nxpath): if index: enum_str = ( "\n " - + ("Possible values:" if enums.count(",") else "Obligatory value:") + + ("Possible values:" if len(enums.split(",")) > 1 else "Obligatory value:") + "\n " + enums + "\n" @@ -592,9 +637,8 @@ def get_enums(node): def add_base_classes(elist, nx_name=None, elem: ET.Element = None): - """ - Add the base classes corresponding to the last element in elist to the list. Note that if - elist is empty, a nxdl file with the name of nx_name or a placeholder elem is used if provided + """Add the base classes corresponding to the last eleme in elist to the list. Note that if + elist is empty, a nxdl file with the name of nx_name or a rather room elem is used if provided """ if elist and nx_name is None: nx_name = get_nx_class(elist[-1]) @@ -607,16 +651,7 @@ def add_base_classes(elist, nx_name=None, elem: ET.Element = None): nxdl_file_path = find_definition_file(nx_name) if nxdl_file_path is None: nxdl_file_path = f"{nx_name}.nxdl.xml" - - try: - elem = ET.parse(os.path.abspath(nxdl_file_path)).getroot() - # elem = ET.parse(nxdl_file_path).getroot() - except OSError: - with open(nxdl_file_path, "r") as f: - elem = ET.parse(f).getroot() - - if not isinstance(nxdl_file_path, str): - nxdl_file_path = str(nxdl_file_path) + elem = ET.parse(nxdl_file_path).getroot() elem.set("nxdlbase", nxdl_file_path) else: elem.set("nxdlbase", "") @@ -631,25 +666,20 @@ def add_base_classes(elist, nx_name=None, elem: ET.Element = None): add_base_classes(elist) -def set_nxdlpath(child, nxdl_elem, tag_name=None): - """Setting up child nxdlbase, nxdlpath and nxdlbase_class from nxdl_element.""" +def set_nxdlpath(child, nxdl_elem): + """ + Setting up child nxdlbase, nxdlpath and nxdlbase_class from nxdl_element. + """ if nxdl_elem.get("nxdlbase"): child.set("nxdlbase", nxdl_elem.get("nxdlbase")) child.set("nxdlbase_class", nxdl_elem.get("nxdlbase_class")) - # Handle element that does not has 'name' attr e.g. doc, enumeration - if tag_name: - child.set("nxdlpath", nxdl_elem.get("nxdlpath") + "/" + tag_name) - else: - child.set( - "nxdlpath", nxdl_elem.get("nxdlpath") + "/" + get_node_name(child) - ) - + child.set("nxdlpath", nxdl_elem.get("nxdlpath") + "/" + get_node_name(child)) return child def get_direct_child(nxdl_elem, html_name): """returns the child of nxdl_elem which has a name - corresponding to the html documentation name html_name""" + corresponding to the the html documentation name html_name""" for child in nxdl_elem: if get_local_name_from_xml(child) in ( "group", @@ -704,7 +734,7 @@ def get_best_nxdata_child(nxdl_elem, hdf_node, hdf_name): def get_best_child(nxdl_elem, hdf_node, hdf_name, hdf_class_name, nexus_type): """returns the child of nxdl_elem which has a name - corresponding to the html documentation name html_name""" + corresponding to the the html documentation name html_name""" bestfit = -1 bestchild = None if ( @@ -753,7 +783,9 @@ def walk_elist(elist, html_name): if fitting_child is not None: child = fitting_child break - if child is None: + elist[ind] = child + if elist[ind] is None: + del elist[ind] continue # override: remove low priority inheritance classes if class_type is overriden if len(elist) > ind + 1 and get_nx_class(elist[ind]) != get_nx_class( @@ -761,7 +793,7 @@ def walk_elist(elist, html_name): ): del elist[ind + 1 :] # add new base class(es) if new element brings such (and not a primitive type) - if len(elist) == ind + 1 and get_nx_class(elist[ind]).startswith("NX_"): + if len(elist) == ind + 1 and get_nx_class(elist[ind])[0:3] != "NX_": add_base_classes(elist) return elist, html_name @@ -771,6 +803,7 @@ def get_inherited_nodes( nxdl_path: str = None, # pylint: disable=too-many-arguments,too-many-locals nx_name: str = None, elem: ET.Element = None, + attr=False, ): """Returns a list of ET.Element for the given path.""" # let us start with the given definition file @@ -779,9 +812,11 @@ def get_inherited_nodes( nxdl_elem_path = [elist[0]] class_path = [] # type: ignore[var-annotated] - html_paths = nxdl_path.split("/")[1:] - for html_name in html_paths: - elist, _ = walk_elist(elist, html_name) + html_path = nxdl_path.split("/")[1:] + path = html_path + for pind in range(len(path)): + html_name = html_path[pind] + elist, html_name = walk_elist(elist, html_name) if elist: class_path.append(get_nx_class(elist[0])) nxdl_elem_path.append(elist[0]) @@ -802,7 +837,7 @@ def get_node_at_nxdl_path( (class_path, nxdlpath, elist) = get_inherited_nodes(nxdl_path, nx_name, elem) except ValueError as value_error: if exc: - raise NxdlAttributeNotFoundError( + raise NxdlAttributeError( f"Attributes were not found for {nxdl_path}. " "Please check this entry in the template dictionary." ) from value_error @@ -812,7 +847,7 @@ def get_node_at_nxdl_path( else: elem = None if exc: - raise NxdlAttributeNotFoundError( + raise NxdlAttributeError( f"Attributes were not found for {nxdl_path}. " "Please check this entry in the template dictionary." ) diff --git a/requirements.txt b/requirements.txt index 3303e068ca..4c7ac61237 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1,7 +1,7 @@ # Prepare for Documentation -lxml +lxml pyyaml -click +git+https://github.com/FAIRmat-NFDI/nyaml.git # Documentation building sphinx>=5 From 829d882bd128fc619c1eb26209f4fd4d77933c64 Mon Sep 17 00:00:00 2001 From: sanbrock <45483558+sanbrock@users.noreply.github.com> Date: Wed, 29 Nov 2023 16:33:10 +0100 Subject: [PATCH 0370/1012] pytest and related test file added for checking nxdl_utils functionality (#130) * pytest and related test file added for checking nxdl_utils functionality * linting * linting * use optional false instead of required true * use optional false instead of required true --- dev_tools/tests/NXtest.nxdl.xml | 65 +++++++++++++ dev_tools/tests/test_nxdl_utils.py | 150 +++++++++++++++++++++++++++++ 2 files changed, 215 insertions(+) create mode 100644 dev_tools/tests/NXtest.nxdl.xml create mode 100644 dev_tools/tests/test_nxdl_utils.py diff --git a/dev_tools/tests/NXtest.nxdl.xml b/dev_tools/tests/NXtest.nxdl.xml new file mode 100644 index 0000000000..767733e948 --- /dev/null +++ b/dev_tools/tests/NXtest.nxdl.xml @@ -0,0 +1,65 @@ + + + + This is a dummy NXDL to test out the dataconverter. + + + + This is a dummy NXDL to test out the dataconverter. + + + + + + + + + A dummy entry for a float value. + + + A dummy entry for a bool value. + + + A dummy entry for an int value. + + + A dummy entry for a positive int value. + + + A dummy entry for a char value. + + + A dummy entry for a date value. + + + + + + + + + + + + This is a required yet empty group. + + + This is a second required yet empty group. + + + + A dummy entry to test optional parent check for required child. + + + A dummy entry to test optional parent check for required child. + + + + diff --git a/dev_tools/tests/test_nxdl_utils.py b/dev_tools/tests/test_nxdl_utils.py new file mode 100644 index 0000000000..fcc3322929 --- /dev/null +++ b/dev_tools/tests/test_nxdl_utils.py @@ -0,0 +1,150 @@ +"""This is a code that performs several tests on nexus tool + +""" +# +# 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. +# + +import os +import xml.etree.ElementTree as ET + +from ..utils import nxdl_utils as nexus + + +def test_get_nexus_classes_units_attributes(): + """Check the correct parsing of a separate list for: + Nexus classes (base_classes) + Nexus units (memberTypes) + Nexus attribute type (primitiveTypes) + the tested functions can be found in nexus.py file""" + + # Test 1 + nexus_classes_list = nexus.get_nx_classes() + + assert "NXbeam" in nexus_classes_list + + # Test 2 + nexus_units_list = nexus.get_nx_units() + assert "NX_TEMPERATURE" in nexus_units_list + + # Test 3 + nexus_attribute_list = nexus.get_nx_attribute_type() + assert "NX_FLOAT" in nexus_attribute_list + + +def test_get_node_at_nxdl_path(): + """Test to verify if we receive the right XML element for a given NXDL path""" + local_dir = os.path.abspath(os.path.dirname(__file__)) + nxdl_file_path = os.path.join(local_dir, "./NXtest.nxdl.xml") + elem = ET.parse(nxdl_file_path).getroot() + node = nexus.get_node_at_nxdl_path("/ENTRY/NXODD_name", elem=elem) + assert node.attrib["type"] == "NXdata" + assert node.attrib["name"] == "NXODD_name" + + node = nexus.get_node_at_nxdl_path("/ENTRY/NXODD_name/float_value", elem=elem) + assert node.attrib["type"] == "NX_FLOAT" + assert node.attrib["name"] == "float_value" + + node = nexus.get_node_at_nxdl_path( + "/ENTRY/NXODD_name/AXISNAME/long_name", elem=elem + ) + assert node.attrib["name"] == "long_name" + + nxdl_file_path = os.path.join( + local_dir, "../../contributed_definitions/NXem.nxdl.xml" + ) + elem = ET.parse(nxdl_file_path).getroot() + node = nexus.get_node_at_nxdl_path( + "/ENTRY/measurement/EVENT_DATA_EM/USER/affiliation", elem=elem + ) + assert node.attrib["name"] == "affiliation" + + node = nexus.get_node_at_nxdl_path("/ENTRY/measurement", elem=elem) + assert node.attrib["type"] == "NXevent_data_em_set" + + node = nexus.get_node_at_nxdl_path( + "/ENTRY/measurement/EVENT_DATA_EM/SPECTRUM_SET/summary", elem=elem + ) + assert node.attrib["type"] == "NXdata" + + node = nexus.get_node_at_nxdl_path( + "/ENTRY/measurement/EVENT_DATA_EM/SPECTRUM_SET/summary/DATA", elem=elem + ) + assert node.attrib["type"] == "NX_NUMBER" + + node = nexus.get_node_at_nxdl_path( + "/ENTRY/measurement/EVENT_DATA_EM/SPECTRUM_SET/summary/AXISNAME_indices", + elem=elem, + ) + assert node.attrib["name"] == "AXISNAME_indices" + + node = nexus.get_node_at_nxdl_path("/ENTRY/COORDINATE_SYSTEM_SET", elem=elem) + assert node.attrib["type"] == "NXcoordinate_system_set" + + node = nexus.get_node_at_nxdl_path( + "/ENTRY/COORDINATE_SYSTEM_SET/TRANSFORMATIONS", elem=elem + ) + assert node.attrib["type"] == "NXtransformations" + + node = nexus.get_node_at_nxdl_path( + "/ENTRY/COORDINATE_SYSTEM_SET/TRANSFORMATIONS/AXISNAME", elem=elem + ) + assert node.attrib["type"] == "NX_NUMBER" + + node = nexus.get_node_at_nxdl_path( + "/ENTRY/COORDINATE_SYSTEM_SET/TRANSFORMATIONS/AXISNAME/transformation_type", + elem=elem, + ) + assert node.attrib["name"] == "transformation_type" + + nxdl_file_path = os.path.join( + local_dir, "../../contributed_definitions/NXiv_temp.nxdl.xml" + ) + elem = ET.parse(nxdl_file_path).getroot() + node = nexus.get_node_at_nxdl_path( + "/ENTRY/INSTRUMENT/ENVIRONMENT/voltage_controller", elem=elem + ) + assert node.attrib["name"] == "voltage_controller" + + node = nexus.get_node_at_nxdl_path( + "/ENTRY/INSTRUMENT/ENVIRONMENT/voltage_controller/calibration_time", elem=elem + ) + assert node.attrib["name"] == "calibration_time" + + +def test_get_inherited_nodes(): + """Test to verify if we receive the right XML element list for a given NXDL path.""" + local_dir = os.path.abspath(os.path.dirname(__file__)) + nxdl_file_path = os.path.join( + local_dir, "../../contributed_definitions/NXiv_temp.nxdl.xml" + ) + elem = ET.parse(nxdl_file_path).getroot() + (_, _, elist) = nexus.get_inherited_nodes( + nxdl_path="/ENTRY/INSTRUMENT/ENVIRONMENT", elem=elem + ) + assert len(elist) == 3 + + (_, _, elist) = nexus.get_inherited_nodes( + nxdl_path="/ENTRY/INSTRUMENT/ENVIRONMENT/voltage_controller", elem=elem + ) + assert len(elist) == 4 + + (_, _, elist) = nexus.get_inherited_nodes( + nxdl_path="/ENTRY/INSTRUMENT/ENVIRONMENT/voltage_controller", + nx_name="NXiv_temp", + ) + assert len(elist) == 4 From ddd8cec1b4607236a345822f99a9677ea0ad9553 Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Thu, 30 Nov 2023 13:26:15 +0100 Subject: [PATCH 0371/1012] Update dev_tools files (#129) * Adds reviewed files from PR1303 * Consolidated nxdl.py * Fix whitespace * Fix broken reference to function remove_namespace_from_tag by temporarily defining the function in plain here as nyaml is not yet a pypi package * isort dependencies in nxdl_utils.py * Use `remove_namespace_from_tag` from nyaml * Install nyaml from pypi * Removes callable import * removing unnecesary dependency * fix for the misuse of stem be3cause the suffixes are .nxdl.xml * fix restructuring bugs, mainly xml.ET -> lxml.etree migration issues * linting * fix for the use of NEXUS_DEF_PATH, and the use of name_any --------- Co-authored-by: atomprobe-tc Co-authored-by: Sandor Brockhauser --- dev_tools/tests/test_nxdl_utils.py | 3 +- dev_tools/utils/nxdl_utils.py | 287 ++++++++++++++--------------- requirements.txt | 2 +- 3 files changed, 139 insertions(+), 153 deletions(-) diff --git a/dev_tools/tests/test_nxdl_utils.py b/dev_tools/tests/test_nxdl_utils.py index fcc3322929..f49db9db41 100644 --- a/dev_tools/tests/test_nxdl_utils.py +++ b/dev_tools/tests/test_nxdl_utils.py @@ -20,7 +20,8 @@ # import os -import xml.etree.ElementTree as ET + +import lxml.etree as ET from ..utils import nxdl_utils as nexus diff --git a/dev_tools/utils/nxdl_utils.py b/dev_tools/utils/nxdl_utils.py index efba439bec..be8262fdfc 100644 --- a/dev_tools/utils/nxdl_utils.py +++ b/dev_tools/utils/nxdl_utils.py @@ -4,43 +4,59 @@ import os import textwrap -import xml.etree.ElementTree as ET from functools import lru_cache from glob import glob +from pathlib import Path +import lxml.etree as ET +from lxml.etree import ParseError as xmlER -class NxdlAttributeError(Exception): - """An exception for throwing an error when an Nxdl attribute is not found.""" +def remove_namespace_from_tag(tag): + """Helper function to remove the namespace from an XML tag.""" -def get_app_defs_names(): - """Returns all the AppDef names without their extension: .nxdl.xml""" - app_def_path_glob = ( - f"{get_nexus_definitions_path()}{os.sep}applications{os.sep}*.nxdl*" - ) - contrib_def_path_glob = ( - f"{get_nexus_definitions_path()}{os.sep}" - f"contributed_definitions{os.sep}*.nxdl*" - ) - files = sorted(glob(app_def_path_glob)) + sorted(glob(contrib_def_path_glob)) - return [os.path.basename(file).split(".")[0] for file in files] + ["NXroot"] + return tag.split("}")[-1] -@lru_cache(maxsize=None) -def get_xml_root(file_path): - """Reducing I/O time by caching technique""" - - return ET.parse(file_path).getroot() +class NxdlAttributeNotFoundError(Exception): + """An exception to throw when an Nxdl attribute is not found.""" def get_nexus_definitions_path(): """Check NEXUS_DEF_PATH variable. If it is empty, this function is filling it""" try: # either given by sys env - return os.environ["NEXUS_DEF_PATH"] + return Path(os.environ["NEXUS_DEF_PATH"]) except KeyError: # or it should be available locally under the dir 'definitions' - local_dir = os.path.abspath(os.path.dirname(__file__)) - return os.path.join(local_dir, f"..{os.sep}..") + local_dir = Path(__file__).resolve().parent + for _ in range(2): + local_dir = local_dir.parent + return local_dir + + +nexus_def_path = get_nexus_definitions_path() + + +def get_app_defs_names(): + """Returns all the AppDef names without their extension: .nxdl.xml""" + app_def_path_glob = nexus_def_path / "applications" / "*.nxdl*" + + contrib_def_path_glob = Path(nexus_def_path) / "contributed_definitions" / "*.nxdl*" + + files = sorted(glob(app_def_path_glob)) + for nexus_file in sorted(contrib_def_path_glob): + root = get_xml_root(nexus_file) + if root.attrib["category"] == "application": + files.append(nexus_file) + + return [Path(file).name[:-9] for file in files] + ["NXroot"] + + +@lru_cache(maxsize=None) +def get_xml_root(file_path): + """Reducing I/O time by caching technique""" + + return ET.parse(file_path).getroot() def get_hdf_root(hdf_node): @@ -67,43 +83,34 @@ def get_hdf_parent(hdf_info): def get_parent_path(hdf_name): """Get parent path""" - return "/".join(hdf_name.split("/")[:-1]) + return hdf_name.rsplit("/", 1)[0] def get_hdf_info_parent(hdf_info): """Get the hdf_info for the parent of an hdf_node in an hdf_info""" if "hdf_path" not in hdf_info: return {"hdf_node": hdf_info["hdf_node"].parent} - node = ( - get_hdf_root(hdf_info["hdf_node"]) - if "hdf_root" not in hdf_info - else hdf_info["hdf_root"] - ) - for child_name in hdf_info["hdf_path"].split("/")[1:-1]: - node = node[child_name] + node = get_hdf_parent(hdf_info) return {"hdf_node": node, "hdf_path": get_parent_path(hdf_info["hdf_path"])} def get_nx_class(nxdl_elem): """Get the nexus class for a NXDL node""" if "category" in nxdl_elem.attrib.keys(): - return None - try: - return nxdl_elem.attrib["type"] - except KeyError: - return "NX_CHAR" + return "" + return nxdl_elem.attrib.get("type", "NX_CHAR") def get_nx_namefit(hdf_name, name, name_any=False): """Checks if an HDF5 node name corresponds to a child of the NXDL element - uppercase letters in front can be replaced by arbitraty name, but + uppercase letters in front can be replaced by arbitrary name, but uppercase to lowercase match is preferred, so such match is counted as a measure of the fit""" if name == hdf_name: return len(name) * 2 # count leading capitals counting = 0 - while counting < len(name) and name[counting].upper() == name[counting]: + while counting < len(name) and name[counting].isupper(): counting += 1 if ( name_any @@ -127,63 +134,56 @@ def get_nx_classes(): """Read base classes from the NeXus definition folder. Check each file in base_classes, applications, contributed_definitions. If its category attribute is 'base', then it is added to the list.""" - base_classes = sorted( - glob(os.path.join(get_nexus_definitions_path(), "base_classes", "*.nxdl.xml")) - ) - applications = sorted( - glob(os.path.join(get_nexus_definitions_path(), "applications", "*.nxdl.xml")) - ) + nexus_definition_path = nexus_def_path + base_classes = sorted(nexus_definition_path.glob("base_classes/*.nxdl.xml")) + applications = sorted(nexus_definition_path.glob("applications/*.nxdl.xml")) contributed = sorted( - glob( - os.path.join( - get_nexus_definitions_path(), "contributed_definitions", "*.nxdl.xml" - ) - ) + nexus_definition_path.glob("contributed_definitions/*.nxdl.xml") ) - nx_clss = [] + nx_class = [] for nexus_file in base_classes + applications + contributed: - root = get_xml_root(nexus_file) + try: + root = get_xml_root(nexus_file) + except xmlER as e: + raise ValueError(f"Getting an issue while parsing file {nexus_file}") from e if root.attrib["category"] == "base": - nx_clss.append(str(nexus_file[nexus_file.rindex(os.sep) + 1 :])[:-9]) - nx_clss = sorted(nx_clss) - return nx_clss + nx_class.append(nexus_file.name[:-9]) + return sorted(nx_class) def get_nx_units(): """Read unit kinds from the NeXus definition/nxdlTypes.xsd file""" - filepath = f"{get_nexus_definitions_path()}{os.sep}nxdlTypes.xsd" + filepath = nexus_def_path / "nxdlTypes.xsd" root = get_xml_root(filepath) units_and_type_list = [] for child in root: - for i in child.attrib.values(): - units_and_type_list.append(i) + units_and_type_list.extend(child.attrib.values()) flag = False + nx_units = [] for line in units_and_type_list: if line == "anyUnitsAttr": flag = True - nx_units = [] - elif "NX" in line and flag is True: + elif "NX" in line and flag: nx_units.append(line) elif line == "primitiveType": flag = False - else: - pass + return nx_units def get_nx_attribute_type(): """Read attribute types from the NeXus definition/nxdlTypes.xsd file""" - filepath = get_nexus_definitions_path() + "/nxdlTypes.xsd" + filepath = nexus_def_path / "nxdlTypes.xsd" + root = get_xml_root(filepath) units_and_type_list = [] for child in root: - for i in child.attrib.values(): - units_and_type_list.append(i) + units_and_type_list.extend(child.attrib.values()) flag = False + nx_types = [] for line in units_and_type_list: if line == "primitiveType": flag = True - nx_types = [] elif "NX" in line and flag is True: nx_types.append(line) elif line == "anyUnitsAttr": @@ -198,7 +198,7 @@ def get_node_name(node): Either as specified by the 'name' or taken from the type (nx_class). Note that if only class name is available, the NX prefix is removed and the string is converted to UPPER case.""" - if "name" in node.attrib.keys(): + if "name" in node.attrib: name = node.attrib["name"] else: name = node.attrib["type"] @@ -232,7 +232,7 @@ def belongs_to_capital(params): (act_htmlname, chk_name, name_any, nxdl_elem, child, name) = params # or starts with capital and no reserved words used if ( - (name_any or "A" <= act_htmlname[0] <= "Z") + (name_any or (act_htmlname[0].isalpha() and act_htmlname[0].isupper())) and name != "doc" and name != "enumeration" ): @@ -240,16 +240,15 @@ def belongs_to_capital(params): if fit < 0: return False for child2 in nxdl_elem: + if not isinstance(child2.tag, str): + continue if ( get_local_name_from_xml(child) != get_local_name_from_xml(child2) or get_node_name(child2) == act_htmlname ): continue # check if the name of another sibling fits better - name_any2 = ( - "nameType" in child2.attrib.keys() - and child2.attrib["nameType"] == "any" - ) + name_any2 = child2.attrib.get("nameType") == "any" fit2 = get_nx_namefit(chk_name, get_node_name(child2), name_any2) if fit2 > fit: return False @@ -260,59 +259,35 @@ def belongs_to_capital(params): def get_local_name_from_xml(element): """Helper function to extract the element tag without the namespace.""" - return element.tag[element.tag.rindex("}") + 1 :] + return remove_namespace_from_tag(element.tag) def get_own_nxdl_child_reserved_elements(child, name, nxdl_elem): """checking reserved elements, like doc, enumeration""" - if get_local_name_from_xml(child) == "doc" and name == "doc": - if nxdl_elem.get("nxdlbase"): - child.set("nxdlbase", nxdl_elem.get("nxdlbase")) - child.set("nxdlbase_class", nxdl_elem.get("nxdlbase_class")) - child.set("nxdlpath", nxdl_elem.get("nxdlpath") + "/doc") - return child - if get_local_name_from_xml(child) == "enumeration" and name == "enumeration": - if nxdl_elem.get("nxdlbase"): - child.set("nxdlbase", nxdl_elem.get("nxdlbase")) - child.set("nxdlbase_class", nxdl_elem.get("nxdlbase_class")) - child.set("nxdlpath", nxdl_elem.get("nxdlpath") + "/enumeration") - return child + local_name = get_local_name_from_xml(child) + if local_name == "doc" and name == "doc": + return set_nxdlpath(child, nxdl_elem, tag_name=name) + + if local_name == "enumeration" and name == "enumeration": + return set_nxdlpath(child, nxdl_elem, tag_name=name) return False def get_own_nxdl_child_base_types(child, class_type, nxdl_elem, name, hdf_name): - """checking base types of group, field,m attribute""" + """checking base types of group, field, attribute""" if get_local_name_from_xml(child) == "group": if ( class_type is None or (class_type and get_nx_class(child) == class_type) ) and belongs_to(nxdl_elem, child, name, class_type, hdf_name): - if nxdl_elem.get("nxdlbase"): - child.set("nxdlbase", nxdl_elem.get("nxdlbase")) - child.set("nxdlbase_class", nxdl_elem.get("nxdlbase_class")) - child.set( - "nxdlpath", nxdl_elem.get("nxdlpath") + "/" + get_node_name(child) - ) - return child + return set_nxdlpath(child, nxdl_elem) if get_local_name_from_xml(child) == "field" and belongs_to( nxdl_elem, child, name, None, hdf_name ): - if nxdl_elem.get("nxdlbase"): - child.set("nxdlbase", nxdl_elem.get("nxdlbase")) - child.set("nxdlbase_class", nxdl_elem.get("nxdlbase_class")) - child.set( - "nxdlpath", nxdl_elem.get("nxdlpath") + "/" + get_node_name(child) - ) - return child + return set_nxdlpath(child, nxdl_elem) if get_local_name_from_xml(child) == "attribute" and belongs_to( nxdl_elem, child, name, None, hdf_name ): - if nxdl_elem.get("nxdlbase"): - child.set("nxdlbase", nxdl_elem.get("nxdlbase")) - child.set("nxdlbase_class", nxdl_elem.get("nxdlbase_class")) - child.set( - "nxdlpath", nxdl_elem.get("nxdlpath") + "/" + get_node_name(child) - ) - return child + return set_nxdlpath(child, nxdl_elem) return False @@ -324,20 +299,20 @@ def get_own_nxdl_child( class_type - nxdl type or hdf classname (for groups, it is obligatory) hdf_name - hdf name""" for child in nxdl_elem: - if "name" in child.attrib and child.attrib["name"] == name: - if nxdl_elem.get("nxdlbase"): - child.set("nxdlbase", nxdl_elem.get("nxdlbase")) - child.set("nxdlbase_class", nxdl_elem.get("nxdlbase_class")) - child.set( - "nxdlpath", nxdl_elem.get("nxdlpath") + "/" + get_node_name(child) - ) - return child + if not isinstance(child.tag, str): + continue + if child.attrib.get("name") == name: + return set_nxdlpath(child, nxdl_elem) for child in nxdl_elem: - if "name" in child.attrib and child.attrib["name"] == name: + if not isinstance(child.tag, str): + continue + if child.attrib.get("name") == name: child.set("nxdlbase", nxdl_elem.get("nxdlbase")) return child for child in nxdl_elem: + if not isinstance(child.tag, str): + continue result = get_own_nxdl_child_reserved_elements(child, name, nxdl_elem) if result is not False: return result @@ -357,14 +332,9 @@ def find_definition_file(bc_name): """ bc_filename = None for nxdl_folder in ["contributed_definitions", "base_classes", "applications"]: - if os.path.exists( - f"{get_nexus_definitions_path()}{os.sep}" - f"{nxdl_folder}{os.sep}{bc_name}.nxdl.xml" - ): - bc_filename = ( - f"{get_nexus_definitions_path()}{os.sep}" - f"{nxdl_folder}{os.sep}{bc_name}.nxdl.xml" - ) + nxdl_file = nexus_def_path / nxdl_folder / f"{bc_name}.nxdl.xml" + if nxdl_file.exists(): + bc_filename = nexus_def_path / nxdl_folder / f"{bc_name}.nxdl.xml" break return bc_filename @@ -420,11 +390,8 @@ def get_required_string(nxdl_elem): if is_optional or is_minoccurs: return "<>" # default optionality: in BASE CLASSES is true; in APPLICATIONS is false - try: - if nxdl_elem.get("nxdlbase_class") == "base": - return "<>" - except TypeError: - return "<>" + if nxdl_elem.get("nxdlbase_class") == "base": + return "<>" return "<>" @@ -432,7 +399,7 @@ def get_required_string(nxdl_elem): def write_doc_string(logger, doc, attr): """Simple function that prints a line in the logger if doc exists""" if doc: - logger.debug("@" + attr + " [NX_CHAR]") + logger.debug("@%s [NX_CHAR]", attr) return logger, doc, attr @@ -565,7 +532,7 @@ def other_attrs( def get_node_concept_path(elem): """get the short version of nxdlbase:nxdlpath""" - return str(elem.get("nxdlbase").split("/")[-1] + ":" + elem.get("nxdlpath")) + return f'{elem.get("nxdlbase").split("/")[-1]}:{elem.get("nxdlpath")}' def get_doc(node, ntype, nxhtml, nxpath): @@ -588,7 +555,7 @@ def get_doc(node, ntype, nxhtml, nxpath): if index: enum_str = ( "\n " - + ("Possible values:" if len(enums.split(",")) > 1 else "Obligatory value:") + + ("Possible values:" if enums.count(",") else "Obligatory value:") + "\n " + enums + "\n" @@ -637,8 +604,9 @@ def get_enums(node): def add_base_classes(elist, nx_name=None, elem: ET.Element = None): - """Add the base classes corresponding to the last eleme in elist to the list. Note that if - elist is empty, a nxdl file with the name of nx_name or a rather room elem is used if provided + """ + Add the base classes corresponding to the last element in elist to the list. Note that if + elist is empty, a nxdl file with the name of nx_name or a placeholder elem is used if provided """ if elist and nx_name is None: nx_name = get_nx_class(elist[-1]) @@ -651,7 +619,16 @@ def add_base_classes(elist, nx_name=None, elem: ET.Element = None): nxdl_file_path = find_definition_file(nx_name) if nxdl_file_path is None: nxdl_file_path = f"{nx_name}.nxdl.xml" - elem = ET.parse(nxdl_file_path).getroot() + + try: + elem = ET.parse(os.path.abspath(nxdl_file_path)).getroot() + # elem = ET.parse(nxdl_file_path).getroot() + except OSError: + with open(nxdl_file_path, "r") as f: + elem = ET.parse(f).getroot() + + if not isinstance(nxdl_file_path, str): + nxdl_file_path = str(nxdl_file_path) elem.set("nxdlbase", nxdl_file_path) else: elem.set("nxdlbase", "") @@ -666,21 +643,28 @@ def add_base_classes(elist, nx_name=None, elem: ET.Element = None): add_base_classes(elist) -def set_nxdlpath(child, nxdl_elem): - """ - Setting up child nxdlbase, nxdlpath and nxdlbase_class from nxdl_element. - """ - if nxdl_elem.get("nxdlbase"): +def set_nxdlpath(child, nxdl_elem, tag_name=None): + """Setting up child nxdlbase, nxdlpath and nxdlbase_class from nxdl_element.""" + if nxdl_elem.get("nxdlbase") is not None: child.set("nxdlbase", nxdl_elem.get("nxdlbase")) child.set("nxdlbase_class", nxdl_elem.get("nxdlbase_class")) - child.set("nxdlpath", nxdl_elem.get("nxdlpath") + "/" + get_node_name(child)) + # Handle element that does not has 'name' attr e.g. doc, enumeration + if tag_name: + child.set("nxdlpath", nxdl_elem.get("nxdlpath") + "/" + tag_name) + else: + child.set( + "nxdlpath", nxdl_elem.get("nxdlpath") + "/" + get_node_name(child) + ) + return child def get_direct_child(nxdl_elem, html_name): """returns the child of nxdl_elem which has a name - corresponding to the the html documentation name html_name""" + corresponding to the html documentation name html_name""" for child in nxdl_elem: + if not isinstance(child.tag, str): + continue if get_local_name_from_xml(child) in ( "group", "field", @@ -696,6 +680,8 @@ def get_field_child(nxdl_elem, html_name): corresponding to the html documentation name html_name""" data_child = None for child in nxdl_elem: + if not isinstance(child.tag, str): + continue if get_local_name_from_xml(child) != "field": continue if get_node_name(child) == html_name: @@ -734,7 +720,7 @@ def get_best_nxdata_child(nxdl_elem, hdf_node, hdf_name): def get_best_child(nxdl_elem, hdf_node, hdf_name, hdf_class_name, nexus_type): """returns the child of nxdl_elem which has a name - corresponding to the the html documentation name html_name""" + corresponding to the html documentation name html_name""" bestfit = -1 bestchild = None if ( @@ -748,6 +734,8 @@ def get_best_child(nxdl_elem, hdf_node, hdf_name, hdf_class_name, nexus_type): if fnd_child is not None: return (fnd_child, fit) for child in nxdl_elem: + if not isinstance(child.tag, str): + continue fit = -2 if get_local_name_from_xml(child) == nexus_type and ( nexus_type != "group" or get_nx_class(child) == hdf_class_name @@ -784,7 +772,7 @@ def walk_elist(elist, html_name): child = fitting_child break elist[ind] = child - if elist[ind] is None: + if child is None: del elist[ind] continue # override: remove low priority inheritance classes if class_type is overriden @@ -793,7 +781,7 @@ def walk_elist(elist, html_name): ): del elist[ind + 1 :] # add new base class(es) if new element brings such (and not a primitive type) - if len(elist) == ind + 1 and get_nx_class(elist[ind])[0:3] != "NX_": + if len(elist) == ind + 1 and not get_nx_class(elist[ind]).startswith("NX_"): add_base_classes(elist) return elist, html_name @@ -803,7 +791,6 @@ def get_inherited_nodes( nxdl_path: str = None, # pylint: disable=too-many-arguments,too-many-locals nx_name: str = None, elem: ET.Element = None, - attr=False, ): """Returns a list of ET.Element for the given path.""" # let us start with the given definition file @@ -812,11 +799,9 @@ def get_inherited_nodes( nxdl_elem_path = [elist[0]] class_path = [] # type: ignore[var-annotated] - html_path = nxdl_path.split("/")[1:] - path = html_path - for pind in range(len(path)): - html_name = html_path[pind] - elist, html_name = walk_elist(elist, html_name) + html_paths = nxdl_path.split("/")[1:] + for html_name in html_paths: + elist, _ = walk_elist(elist, html_name) if elist: class_path.append(get_nx_class(elist[0])) nxdl_elem_path.append(elist[0]) @@ -837,7 +822,7 @@ def get_node_at_nxdl_path( (class_path, nxdlpath, elist) = get_inherited_nodes(nxdl_path, nx_name, elem) except ValueError as value_error: if exc: - raise NxdlAttributeError( + raise NxdlAttributeNotFoundError( f"Attributes were not found for {nxdl_path}. " "Please check this entry in the template dictionary." ) from value_error @@ -847,7 +832,7 @@ def get_node_at_nxdl_path( else: elem = None if exc: - raise NxdlAttributeError( + raise NxdlAttributeNotFoundError( f"Attributes were not found for {nxdl_path}. " "Please check this entry in the template dictionary." ) diff --git a/requirements.txt b/requirements.txt index 4c7ac61237..f628ca805f 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1,7 +1,7 @@ # Prepare for Documentation lxml pyyaml -git+https://github.com/FAIRmat-NFDI/nyaml.git +nyaml # Documentation building sphinx>=5 From 1d0d045c2edda05cba80ace1684ab200871e6db7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20K=C3=BChbach?= Date: Thu, 30 Nov 2023 20:19:51 +0100 Subject: [PATCH 0372/1012] Base class templates (#51) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Refactored cg_primitive base classes for two key aspects: i) make all primitives inherit from new base class NXcg_primitive_set which makes a substantial number of repeated properties of specialized primitive base classes unnecessary, ii) introducing a rigorous mathematical set theoretical approach to describe the number type N, N0, Z, R, R+, R, iii) introduce short hand notation to reduce writing costs for shape/dimensions of arrays: now numpy syntax is used, for scalars (), (1, can be omitted, experience in FAIRmat has shown that in almost all cases the optional doc string to a dimension was almost never used and thus yaml based descriptions can be written more succinct, iv) proof-read docstrings and shortened them, introduced the suggestion to use info: as a keyword which should for now be just appended to the docstring as usual but in the future should be treated as a comment, i.e. only meant for human contextualization but ignored for semantic interpretation of concepts, a key difference that I hope this will bring is to reduce also the length of base classes and appdef as they show up in html pages, specifically for appdefs like NXem many of the conceptual ideas which these docstrings currently contain would be much better placed in a proper documentation instead of the actual class definition in the hope that the overall appearance of classes becomes easier and faster for people to power read; maybe this also works against some criticism that NeXus is considered complex, I have to say with the outsourcing of NXcg_primitive_set I feel it is damn simple now * Refactoring of NXcs base classes * First lot of refactoring EM base classes, the rest tomorrow, NXapm will not be refactored before the APT&M2023 conference in Sept2023, also because feedback from Leoben was positive enough that no immediate changes wrt to appdefs and base classes were required * Summarize the current state of the discussion about coordinate systems with the proposed NXcoordinate_system and NXcoordinate_system_set base classes and best practice recommendations how they should be used including feedback from discussions with Florian Dobner and Tamás Haraszti * Summary of the discussion how to handle conventions and method-specific conventions for EM and methods used in EM * Base classes for implemented examples for pole figures, orientation distribution function, event_data, stage_lab, and ebsd_crystal_structure_model * NXms_ipf base class and dos2unix to correct newlines * Introducing NXem_method base class as a template how to write method-specific deep base classes to describe the terms and taxononmy of method-specific branches to be hooked into appdefs like NXem * Base class inheritance proposal for a now even stronger modularized schema set for electron microscopy research, two tasks remain: i) refactor what is now a method-specific instance rather than an appdef (NXem_ebsd) (mainly to be able to fuse all examples of em-specific data converters including new ebsd examples into one em parser for pynxtools), ii) refactor NXem which is now clearly a specific appdef specializing the NXem_base deep base class, specialization work needs to define which fields and groups from all the possible ones now composable via base classes (inheritance) are required in an appdef NXem for NOMAD OASIS * NXem_ebsd refactored into a base class to use it as a method-specific group inside the NXem application definition, next step: i) refactor NXem_sim, ii) finalize refactoring of NXem appdef (for Nomad oasis) * finished draft of NXem_ebsd, NXem_correlation, and NXem appdef, cleaning the branch * Add proposal for storing mtx cfg, fixed nxtime datatypes * 2d microstructure projection * Inspection how proposed, info, N0, N, R, Z value type abbreviations, and dimensions could be added to nyamlforward * A likely too simplistic but at least working nyaml2nxdl forward mapping to explore further usage of refactored EM base classes. Info keyword has to be a child of doc or the respective text be removed from the standard and put into proposal-specific documentation, how to store what and where so that the schema docstring remain succinct and slim but all these conceptual ideas get not forgotten, typically the would be part of a tech report, i.e. in my opinion all what is under info: sections of a docstring should move to some documentation to tell the story to humans, next test these NXDLs with the NeXus documentation system * Minor fix to handle info keyword spotted while compiling the documentation * Fixes to compile with NeXus documentation test suite and sphinx * Deactivated the annoying clean yaml via make clean for dev purposes * Minor fix in em_base, this completes the appdef/base class work for now on the refactored EM, there are still some spurious info fields now, which should be removed when a decision has been made wrt to how to deal with info: keyword fields in general, next steps: i) make decision on info, ii) test refactored EM proposal with pynxtools em-parser v2, iii) implement backwards * Styling via black * Added yaml2nxdl-forward-converted NXDL files to all refactored base classes and the refactored NXem * Added NXroot header for the em appdef and its base template appdef * Continuing the refactoring of EM and APM plus related base classes for CG and MS based on suggestions from user meetings, discussions with Sandor, represents work with the MPES sprint #83 * Continuing on #83 * Continuing #83, NXcs_* * Continuing #83, ipf, pf, odf * Continuing on #83, support classes for EM * Continued on #83, coordinate system, further base classes supporting EM * Continuing #83, event_data_set and event_data description substantially condensed amongst other points * Added cross-references to base classes for rst, continuing #83 * Aligned old NXem_ebsd_conventions with NXcoordinate_system for #83 * Reviewed method-specific base classes, ebsd, eds, eels, #83 * #83, NXms_recon * #83, composed constraints on the NXem appdef * Consolidated with changes that happened in between on the fairmat branch based on 1016aa0, NXms_recon has still an issue and is therefore deactivated currently, method-specific landing pages need to be updated * Consolidated further with fairmat 15624c0be77be13a * Fixing some missing references * Fixed syntax error to compile NXms_recon, docs building also now, reviewing intro pages remains * Consistencies of dimensionality to use NX_POSINT and an enumeration * Recompiled NXDL files using new nyaml module 3d500ced7e4ca57683957c1d61a8d0cb62eccf53, removed, modified by taking the one from fairmat, and synced all files which were binarily different between this feature branch and the fairmat branch specifically commit a15798bab795d92b587527f2cff0819e26f550ee of the fairmat branch * Deactivated em-based tests which because of a refactoring of em are not expected to work anymore * Fix improper Latex notation in math environment for polyline, face_list, nanochem * Added recompiled NXidentifier, NXserialized NXDLs which triggered pipeline errors in CatChen gh action * Some round of proof-reading * Fixed test_nxdl_utils to reflect and use refactored locations of refactored NXem * Added feedback from @phyy-nx, @PeterC-DLS, and @prjemian from discussed here https://github.com/nexusformat/definitions PR #1271 * Black formatting * Reactivated data type check for e.g. NXem NX_NUMBER * Implementing NX_DATE_TIME suggestion of @sanbrock --------- Co-authored-by: markus.kuehbach --- contributed_definitions/NXaberration.nxdl.xml | 42 +- .../NXaberration_model.nxdl.xml | 73 +- .../NXaberration_model_ceos.nxdl.xml | 17 +- .../NXaberration_model_nion.nxdl.xml | 10 +- .../NXaperture_em.nxdl.xml | 43 +- contributed_definitions/NXapm.nxdl.xml | 190 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 116 +- .../NXcg_alpha_complex.nxdl.xml | 111 +- .../NXcg_cylinder_set.nxdl.xml | 128 +- .../NXcg_ellipsoid_set.nxdl.xml | 94 +- .../NXcg_face_list_data_structure.nxdl.xml | 146 +- .../NXcg_geodesic_mesh.nxdl.xml | 40 +- contributed_definitions/NXcg_grid.nxdl.xml | 90 +- .../NXcg_half_edge_data_structure.nxdl.xml | 105 +- .../NXcg_hexahedron_set.nxdl.xml | 152 +- .../NXcg_marching_cubes.nxdl.xml | 31 +- .../NXcg_parallelogram_set.nxdl.xml | 159 +- .../NXcg_point_set.nxdl.xml | 71 +- .../NXcg_polygon_set.nxdl.xml | 156 +- .../NXcg_polyhedron_set.nxdl.xml | 126 +- .../NXcg_polyline_set.nxdl.xml | 124 +- .../NXcg_primitive_set.nxdl.xml | 212 + contributed_definitions/NXcg_roi_set.nxdl.xml | 39 +- .../NXcg_sphere_set.nxdl.xml | 74 +- .../NXcg_tetrahedron_set.nxdl.xml | 125 +- .../NXcg_triangle_set.nxdl.xml | 91 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 22 +- .../NXcg_unit_normal_set.nxdl.xml | 29 +- contributed_definitions/NXchamber.nxdl.xml | 15 +- .../NXcomponent_em.nxdl.xml | 69 + .../NXcoordinate_system.nxdl.xml | 143 + .../NXcoordinate_system_set.nxdl.xml | 195 +- .../NXcorrector_cs.nxdl.xml | 89 +- .../NXcrystal_structure.nxdl.xml | 280 + .../NXcs_computer.nxdl.xml | 22 +- contributed_definitions/NXcs_cpu_obj.nxdl.xml | 39 + contributed_definitions/NXcs_cpu_sys.nxdl.xml | 48 + .../NXcs_filter_boolean_mask.nxdl.xml | 72 +- contributed_definitions/NXcs_gpu_obj.nxdl.xml | 39 + contributed_definitions/NXcs_gpu_sys.nxdl.xml | 47 + contributed_definitions/NXcs_io_obj.nxdl.xml | 15 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 12 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 51 + contributed_definitions/NXcs_mm_sys.nxdl.xml | 16 +- contributed_definitions/NXcs_prng.nxdl.xml | 56 +- .../NXcs_profiling.nxdl.xml | 66 +- .../NXcs_profiling_event.nxdl.xml | 25 +- contributed_definitions/NXdeflector.nxdl.xml | 41 +- .../NXebeam_column.nxdl.xml | 48 +- contributed_definitions/NXem.nxdl.xml | 2342 ++------ contributed_definitions/NXem_adf.nxdl.xml | 65 + contributed_definitions/NXem_base.nxdl.xml | 389 ++ ...ons.nxdl.xml => NXem_conventions.nxdl.xml} | 476 +- .../NXem_conventions_ebsd.nxdl.xml | 230 + .../NXem_correlation.nxdl.xml | 245 + contributed_definitions/NXem_ebsd.nxdl.xml | 2221 ++------ ...NXem_ebsd_crystal_structure_model.nxdl.xml | 224 - contributed_definitions/NXem_eds.nxdl.xml | 144 + contributed_definitions/NXem_eels.nxdl.xml | 79 + contributed_definitions/NXem_img.nxdl.xml | 63 + contributed_definitions/NXem_method.nxdl.xml | 47 + contributed_definitions/NXem_msr.nxdl.xml | 96 + contributed_definitions/NXem_sim.nxdl.xml | 60 + .../NXevent_data_em.nxdl.xml | 283 +- .../NXevent_data_em_set.nxdl.xml | 29 +- .../NXfabrication.nxdl.xml | 17 +- .../NXgraph_edge_set.nxdl.xml | 58 +- .../NXgraph_node_set.nxdl.xml | 83 +- contributed_definitions/NXgraph_root.nxdl.xml | 7 +- .../NXibeam_column.nxdl.xml | 98 +- .../NXimage_c_set.nxdl.xml | 247 + .../NXimage_r_set.nxdl.xml | 100 + .../NXimage_r_set_diff.nxdl.xml | 179 + contributed_definitions/NXimage_set.nxdl.xml | 91 +- .../NXimage_set_em_adf.nxdl.xml | 156 - .../NXimage_set_em_kikuchi.nxdl.xml | 205 - .../NXinteraction_vol_em.nxdl.xml | 66 +- contributed_definitions/NXion.nxdl.xml | 67 +- contributed_definitions/NXisocontour.nxdl.xml | 16 +- contributed_definitions/NXlens_em.nxdl.xml | 84 +- contributed_definitions/NXms.nxdl.xml | 93 +- .../NXms_feature_set.nxdl.xml | 116 +- contributed_definitions/NXms_ipf.nxdl.xml | 383 ++ contributed_definitions/NXms_ipf_set.nxdl.xml | 33 + .../NXms_mtex_config.nxdl.xml | 310 + contributed_definitions/NXms_odf.nxdl.xml | 171 + contributed_definitions/NXms_odf_set.nxdl.xml | 33 + contributed_definitions/NXms_pf.nxdl.xml | 111 + contributed_definitions/NXms_pf_set.nxdl.xml | 33 + contributed_definitions/NXms_recon.nxdl.xml | 454 ++ .../NXms_score_results.nxdl.xml | 77 +- .../NXoptical_system_em.nxdl.xml | 31 +- .../NXorientation_set.nxdl.xml | 133 - contributed_definitions/NXpump.nxdl.xml | 10 +- contributed_definitions/NXroi.nxdl.xml | 34 + .../NXrotation_set.nxdl.xml | 159 +- contributed_definitions/NXscanbox_em.nxdl.xml | 71 +- .../NXspectrum_set.nxdl.xml | 140 +- .../NXspectrum_set_em_eels.nxdl.xml | 188 - .../NXspectrum_set_em_xray.nxdl.xml | 311 - contributed_definitions/NXstage_lab.nxdl.xml | 170 +- .../nyaml/NXaberration.yaml | 96 +- .../nyaml/NXaberration_model.yaml | 164 +- .../nyaml/NXaberration_model_ceos.yaml | 99 +- .../nyaml/NXaberration_model_nion.yaml | 72 +- .../nyaml/NXaperture_em.yaml | 100 +- contributed_definitions/nyaml/NXapm.yaml | 4 +- .../NXapm_paraprobe_results_nanochem.yaml | 4 +- .../nyaml/NXcg_alpha_complex.yaml | 243 +- .../nyaml/NXcg_cylinder_set.yaml | 311 +- .../nyaml/NXcg_ellipsoid_set.yaml | 230 +- .../nyaml/NXcg_face_list_data_structure.yaml | 430 +- .../nyaml/NXcg_geodesic_mesh.yaml | 92 +- contributed_definitions/nyaml/NXcg_grid.yaml | 301 +- .../nyaml/NXcg_half_edge_data_structure.yaml | 291 +- .../nyaml/NXcg_hexahedron_set.yaml | 425 +- .../nyaml/NXcg_marching_cubes.yaml | 96 +- .../nyaml/NXcg_parallelogram_set.yaml | 341 +- .../nyaml/NXcg_point_set.yaml | 174 +- .../nyaml/NXcg_polygon_set.yaml | 386 +- .../nyaml/NXcg_polyhedron_set.yaml | 333 +- .../nyaml/NXcg_polyline_set.yaml | 321 +- .../nyaml/NXcg_primitive_set.yaml | 136 + .../nyaml/NXcg_roi_set.yaml | 75 +- .../nyaml/NXcg_sphere_set.yaml | 195 +- .../nyaml/NXcg_tetrahedron_set.yaml | 309 +- .../nyaml/NXcg_triangle_set.yaml | 233 +- .../nyaml/NXcg_triangulated_surface_mesh.yaml | 78 +- .../nyaml/NXcg_unit_normal_set.yaml | 107 +- contributed_definitions/nyaml/NXchamber.yaml | 52 +- .../nyaml/NXcomponent_em.yaml | 39 + .../nyaml/NXcoordinate_system.yaml | 86 + .../nyaml/NXcoordinate_system_set.yaml | 331 +- .../nyaml/NXcorrector_cs.yaml | 170 +- .../nyaml/NXcrystal_structure.yaml | 178 + .../nyaml/NXcs_computer.yaml | 99 +- .../nyaml/NXcs_cpu_obj.yaml | 12 + .../nyaml/NXcs_cpu_sys.yaml | 21 + .../nyaml/NXcs_filter_boolean_mask.yaml | 184 +- .../nyaml/NXcs_gpu_obj.yaml | 12 + .../nyaml/NXcs_gpu_sys.yaml | 20 + .../nyaml/NXcs_io_obj.yaml | 69 +- .../nyaml/NXcs_io_sys.yaml | 43 +- .../nyaml/NXcs_mm_obj.yaml | 21 + .../nyaml/NXcs_mm_sys.yaml | 52 +- contributed_definitions/nyaml/NXcs_prng.yaml | 138 +- .../nyaml/NXcs_profiling.yaml | 214 +- .../nyaml/NXcs_profiling_event.yaml | 133 +- .../nyaml/NXdeflector.yaml | 128 +- .../nyaml/NXebeam_column.yaml | 148 +- contributed_definitions/nyaml/NXem.yaml | 4985 ++--------------- contributed_definitions/nyaml/NXem_adf.yaml | 28 + contributed_definitions/nyaml/NXem_base.yaml | 297 + .../nyaml/NXem_conventions.yaml | 296 + .../nyaml/NXem_conventions_ebsd.yaml | 125 + .../nyaml/NXem_correlation.yaml | 191 + contributed_definitions/nyaml/NXem_ebsd.yaml | 3987 ++----------- .../nyaml/NXem_ebsd_conventions.yaml | 940 ---- .../NXem_ebsd_crystal_structure_model.yaml | 389 -- contributed_definitions/nyaml/NXem_eds.yaml | 80 + contributed_definitions/nyaml/NXem_eels.yaml | 39 + contributed_definitions/nyaml/NXem_img.yaml | 25 + .../nyaml/NXem_method.yaml | 21 + contributed_definitions/nyaml/NXem_msr.yaml | 63 + contributed_definitions/nyaml/NXem_sim.yaml | 34 + .../nyaml/NXevent_data_em.yaml | 472 +- .../nyaml/NXevent_data_em_set.yaml | 53 +- .../nyaml/NXfabrication.yaml | 66 +- .../nyaml/NXgraph_edge_set.yaml | 189 +- .../nyaml/NXgraph_node_set.yaml | 167 +- .../nyaml/NXgraph_root.yaml | 41 - .../nyaml/NXibeam_column.yaml | 213 +- .../nyaml/NXimage_c_set.yaml | 140 + .../nyaml/NXimage_r_set.yaml | 45 + .../nyaml/NXimage_r_set_diff.yaml | 123 + .../nyaml/NXimage_set.yaml | 197 +- .../nyaml/NXimage_set_em_adf.yaml | 257 - .../nyaml/NXimage_set_em_kikuchi.yaml | 362 -- .../nyaml/NXinteraction_vol_em.yaml | 55 +- contributed_definitions/nyaml/NXion.yaml | 259 +- .../nyaml/NXisocontour.yaml | 3 + contributed_definitions/nyaml/NXlens_em.yaml | 189 +- contributed_definitions/nyaml/NXms.yaml | 536 +- .../nyaml/NXms_feature_set.yaml | 58 +- contributed_definitions/nyaml/NXms_ipf.yaml | 299 + .../nyaml/NXms_ipf_set.yaml | 9 + .../nyaml/NXms_mtex_config.yaml | 187 + contributed_definitions/nyaml/NXms_odf.yaml | 99 + .../nyaml/NXms_odf_set.yaml | 9 + contributed_definitions/nyaml/NXms_pf.yaml | 59 + .../nyaml/NXms_pf_set.yaml | 9 + contributed_definitions/nyaml/NXms_recon.yaml | 315 ++ .../nyaml/NXms_score_results.yaml | 725 +-- .../nyaml/NXoptical_system_em.yaml | 122 +- .../nyaml/NXorientation_set.yaml | 228 - contributed_definitions/nyaml/NXpump.yaml | 50 +- contributed_definitions/nyaml/NXroi.yaml | 9 + .../nyaml/NXrotation_set.yaml | 456 +- .../nyaml/NXscanbox_em.yaml | 101 +- .../nyaml/NXspectrum_set.yaml | 294 +- .../nyaml/NXspectrum_set_em_eels.yaml | 315 -- .../nyaml/NXspectrum_set_em_xray.yaml | 534 -- .../nyaml/NXstage_lab.yaml | 309 +- dev_tools/tests/test_nxdl_utils.py | 34 +- .../cgms-structure.rst | 20 +- .../contributed_definitions/em-structure.rst | 37 +- .../icme-structure.rst | 11 +- 207 files changed, 12953 insertions(+), 29531 deletions(-) create mode 100644 contributed_definitions/NXcg_primitive_set.nxdl.xml create mode 100644 contributed_definitions/NXcomponent_em.nxdl.xml create mode 100644 contributed_definitions/NXcoordinate_system.nxdl.xml create mode 100644 contributed_definitions/NXcrystal_structure.nxdl.xml create mode 100644 contributed_definitions/NXcs_cpu_obj.nxdl.xml create mode 100644 contributed_definitions/NXcs_cpu_sys.nxdl.xml create mode 100644 contributed_definitions/NXcs_gpu_obj.nxdl.xml create mode 100644 contributed_definitions/NXcs_gpu_sys.nxdl.xml create mode 100644 contributed_definitions/NXcs_mm_obj.nxdl.xml create mode 100644 contributed_definitions/NXem_adf.nxdl.xml create mode 100644 contributed_definitions/NXem_base.nxdl.xml rename contributed_definitions/{NXem_ebsd_conventions.nxdl.xml => NXem_conventions.nxdl.xml} (64%) create mode 100644 contributed_definitions/NXem_conventions_ebsd.nxdl.xml create mode 100644 contributed_definitions/NXem_correlation.nxdl.xml delete mode 100644 contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml create mode 100644 contributed_definitions/NXem_eds.nxdl.xml create mode 100644 contributed_definitions/NXem_eels.nxdl.xml create mode 100644 contributed_definitions/NXem_img.nxdl.xml create mode 100644 contributed_definitions/NXem_method.nxdl.xml create mode 100644 contributed_definitions/NXem_msr.nxdl.xml create mode 100644 contributed_definitions/NXem_sim.nxdl.xml create mode 100644 contributed_definitions/NXimage_c_set.nxdl.xml create mode 100644 contributed_definitions/NXimage_r_set.nxdl.xml create mode 100644 contributed_definitions/NXimage_r_set_diff.nxdl.xml delete mode 100644 contributed_definitions/NXimage_set_em_adf.nxdl.xml delete mode 100644 contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml create mode 100644 contributed_definitions/NXms_ipf.nxdl.xml create mode 100644 contributed_definitions/NXms_ipf_set.nxdl.xml create mode 100644 contributed_definitions/NXms_mtex_config.nxdl.xml create mode 100644 contributed_definitions/NXms_odf.nxdl.xml create mode 100644 contributed_definitions/NXms_odf_set.nxdl.xml create mode 100644 contributed_definitions/NXms_pf.nxdl.xml create mode 100644 contributed_definitions/NXms_pf_set.nxdl.xml create mode 100644 contributed_definitions/NXms_recon.nxdl.xml delete mode 100644 contributed_definitions/NXorientation_set.nxdl.xml create mode 100644 contributed_definitions/NXroi.nxdl.xml delete mode 100644 contributed_definitions/NXspectrum_set_em_eels.nxdl.xml delete mode 100644 contributed_definitions/NXspectrum_set_em_xray.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXcg_primitive_set.yaml create mode 100644 contributed_definitions/nyaml/NXcomponent_em.yaml create mode 100644 contributed_definitions/nyaml/NXcoordinate_system.yaml create mode 100644 contributed_definitions/nyaml/NXcrystal_structure.yaml create mode 100644 contributed_definitions/nyaml/NXcs_cpu_obj.yaml create mode 100644 contributed_definitions/nyaml/NXcs_cpu_sys.yaml create mode 100644 contributed_definitions/nyaml/NXcs_gpu_obj.yaml create mode 100644 contributed_definitions/nyaml/NXcs_gpu_sys.yaml create mode 100644 contributed_definitions/nyaml/NXcs_mm_obj.yaml create mode 100644 contributed_definitions/nyaml/NXem_adf.yaml create mode 100644 contributed_definitions/nyaml/NXem_base.yaml create mode 100644 contributed_definitions/nyaml/NXem_conventions.yaml create mode 100644 contributed_definitions/nyaml/NXem_conventions_ebsd.yaml create mode 100644 contributed_definitions/nyaml/NXem_correlation.yaml delete mode 100644 contributed_definitions/nyaml/NXem_ebsd_conventions.yaml delete mode 100644 contributed_definitions/nyaml/NXem_ebsd_crystal_structure_model.yaml create mode 100644 contributed_definitions/nyaml/NXem_eds.yaml create mode 100644 contributed_definitions/nyaml/NXem_eels.yaml create mode 100644 contributed_definitions/nyaml/NXem_img.yaml create mode 100644 contributed_definitions/nyaml/NXem_method.yaml create mode 100644 contributed_definitions/nyaml/NXem_msr.yaml create mode 100644 contributed_definitions/nyaml/NXem_sim.yaml create mode 100644 contributed_definitions/nyaml/NXimage_c_set.yaml create mode 100644 contributed_definitions/nyaml/NXimage_r_set.yaml create mode 100644 contributed_definitions/nyaml/NXimage_r_set_diff.yaml delete mode 100644 contributed_definitions/nyaml/NXimage_set_em_adf.yaml delete mode 100644 contributed_definitions/nyaml/NXimage_set_em_kikuchi.yaml create mode 100644 contributed_definitions/nyaml/NXms_ipf.yaml create mode 100644 contributed_definitions/nyaml/NXms_ipf_set.yaml create mode 100644 contributed_definitions/nyaml/NXms_mtex_config.yaml create mode 100644 contributed_definitions/nyaml/NXms_odf.yaml create mode 100644 contributed_definitions/nyaml/NXms_odf_set.yaml create mode 100644 contributed_definitions/nyaml/NXms_pf.yaml create mode 100644 contributed_definitions/nyaml/NXms_pf_set.yaml create mode 100644 contributed_definitions/nyaml/NXms_recon.yaml delete mode 100644 contributed_definitions/nyaml/NXorientation_set.yaml create mode 100644 contributed_definitions/nyaml/NXroi.yaml delete mode 100644 contributed_definitions/nyaml/NXspectrum_set_em_eels.yaml delete mode 100644 contributed_definitions/nyaml/NXspectrum_set_em_xray.yaml diff --git a/contributed_definitions/NXaberration.nxdl.xml b/contributed_definitions/NXaberration.nxdl.xml index be1835cc39..008fc157aa 100644 --- a/contributed_definitions/NXaberration.nxdl.xml +++ b/contributed_definitions/NXaberration.nxdl.xml @@ -1,9 +1,9 @@ - + - + Quantified aberration coefficient in an aberration_model. - - + - Confidence + Value of the aberration coefficient. - + - How was the uncertainty quantified e.g. via the 95% confidence interval. + Uncertainty of the value of the aberration coefficient + according to uncertainty_model. - + + + How was the uncertainty quantified e.g. via the 95% confidence interval + and using which algorithm or statistical model. + + + Time elapsed since the last measurement. - + - For the CEOS definitions the C aberrations are radial-symmetric and have no - angle entry, while the A, B, D, S, or R aberrations are n-fold + For the CEOS definitions the C aberrations are radial-symmetric and have + no angle entry, while the A, B, D, S, or R aberrations are n-fold symmetric and have an angle entry. For the NION definitions the coordinate system differs to the one used in CEOS and instead two aberration coefficients a and b are used. - - + + + Given name to this aberration. + + + + + Alias also used to name and refer to this specific type of aberration. + + diff --git a/contributed_definitions/NXaberration_model.nxdl.xml b/contributed_definitions/NXaberration_model.nxdl.xml index 42a2a7eab1..e1f223187e 100644 --- a/contributed_definitions/NXaberration_model.nxdl.xml +++ b/contributed_definitions/NXaberration_model.nxdl.xml @@ -1,9 +1,9 @@ - + - + Models for aberrations of electro-magnetic lenses in electron microscopy. See `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) for different definitions available and further details. Table 7-2 of Ibid. - publication (page 305ff) documents how to convert from the NION to the + publication (page 305ff) documents how to convert from the Nion to the CEOS definitions. @@ -37,69 +37,4 @@ - - - Defocus - - - - - Two-fold astigmatism - - - - - Two-fold astigmatism - - - - - Second-order axial coma - - - - - Second-order axial coma - - - - - Threefold astigmatism - - - - - Threefold astigmatism - - - - - Spherical aberration - - - - - Star aberration - - - - - Star aberration - - - - - Fourfold astigmatism - - - - - Fourfold astigmatism - - - - - Fifth-order spherical aberration - - diff --git a/contributed_definitions/NXaberration_model_ceos.nxdl.xml b/contributed_definitions/NXaberration_model_ceos.nxdl.xml index de6804487a..43419530ec 100644 --- a/contributed_definitions/NXaberration_model_ceos.nxdl.xml +++ b/contributed_definitions/NXaberration_model_ceos.nxdl.xml @@ -1,9 +1,9 @@ - + - + CEOS definitions/model for aberrations of electro-magnetic lenses. See `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) for different definitions available and further details. Table 7-2 of Ibid. - publication (page 305ff) documents how to convert from the NION to the + publication (page 305ff) documents how to convert from the NION to the CEOS definitions. @@ -42,7 +42,8 @@ - + @@ -58,9 +59,9 @@ Aberrations with multiplicity 0 have no angle entry (C1,C3,C5,.., CEOS notation) contrast transferfuntion: ctf = e^(-i*Xi(g)) in Fourier space aberration function: Xi(g) = 2*pi/lamda{ 1/2 * (lamda*g)^2 (C20 + C22 cos[2(phi-phi_22)] - +1/3 * (lamda*g)^3 (C31 cos[(phi-phi_31) + C33 cos[3(phi-phi_33) - +1/4 * (lamda*g)^4 (C40 + C42 cos[2(phi-phi_42)] + C44 cos[4(phi-phi_42)] - +1/f * (lamda*g)^f Sum (Cfm cos[m(phi-phi_fm)] where m=[0,2,..f] for even f and m=[1,3,..,f] for odd f--> ++1/3 * (lamda*g)^3 (C31 cos[(phi-phi_31) + C33 cos[3(phi-phi_33) ++1/4 * (lamda*g)^4 (C40 + C42 cos[2(phi-phi_42)] + C44 cos[4(phi-phi_42)] ++1/f * (lamda*g)^f Sum (Cfm cos[m(phi-phi_fm)] where m=[0,2,..f] for even f and m=[1,3,..,f] for odd f--> - + - NION definitions/model for aberrations of electro-magnetic lenses. + Nion definitions/model for aberrations of electro-magnetic lenses. See `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) for different definitions available and further details. Table 7-2 of Ibid. - publication (page 305ff) documents how to convert from the NION to the + publication (page 305ff) documents how to convert from the Nion to the CEOS definitions. diff --git a/contributed_definitions/NXaperture_em.nxdl.xml b/contributed_definitions/NXaperture_em.nxdl.xml index a382ec143b..ceb76620d8 100644 --- a/contributed_definitions/NXaperture_em.nxdl.xml +++ b/contributed_definitions/NXaperture_em.nxdl.xml @@ -1,9 +1,9 @@ - + - - + - Details of an individual aperture for beams in electron microscopy. + Base class for an individual aperture for beams in electron microscopy. - - - Given name/alias of the aperture. - - Relevant value from the control software. - This is not always just the diameter of (not even in the case) - of a circular aperture. Usually it is a mode setting value which - is selected in the control software. - Which settings are behind the value should be defined - for now in the description field, if these are known - in more detail. + This is not always just the diameter of the aperture (not even in the case) + of a circular aperture. Usually, it is a value that is set in the control + software whereby a specific configuration of an aperture is selected by the + software. + + The control software of commercial microscope typically offers the user + access at a high abstraction level because of which many details about + the actual settings of the electrical components are typically unknown. + + However, if more details are known or should be documented one should + use the description field for this. - + Ideally, a (globally) unique persistent identifier, link, or text to a - resource which gives further details. Alternatively a free-text field. + resource which gives further details. Alternatively a free-text field to + store details noteworthy for contextualization or more detail. - - - - Affine transformation which detail the arrangement in the - microscope relative to the optical axis and beam path. - - diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index 0ae0d98094..fc138d22e9 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -1,9 +1,9 @@ - + - - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -184,7 +185,7 @@ to describe also the upcoming technique of atomic scale analytical tomography ht Free-text description about the experiment. - Users are strongly advised to detail the sample history in the + 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. @@ -213,8 +214,8 @@ to describe also the upcoming technique of atomic scale analytical tomography ht collected to compute this event chain during the experiment. - + ISO 8601 time code with local time zone offset to UTC included @@ -256,7 +257,7 @@ are required LAS root version camecaroot version analysis software--> 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. + 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. @@ -277,7 +278,7 @@ are required LAS root version camecaroot version analysis software--> 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. + 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. @@ -290,12 +291,12 @@ are required LAS root version camecaroot version analysis software--> 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 + * 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. @@ -306,8 +307,8 @@ are required LAS root version camecaroot version analysis software--> +exists: optional +doc: |--> Contact information and eventually details person(s) involved in the @@ -339,7 +340,7 @@ are required LAS root version camecaroot version analysis software--> Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific + like ORCID or ResearcherID. If this field is field the specific service should also be written in orcid_platform @@ -357,7 +358,7 @@ are required LAS root version camecaroot version analysis software--> - Which role does the user have in the place and at the point + 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. @@ -533,7 +534,7 @@ NEW ISSUE: it would be good to have an application definition NXicp for chemical 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 + 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 @@ -542,7 +543,7 @@ NEW ISSUE: it would be good to have an application definition NXicp for chemical 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 + 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 @@ -591,9 +592,9 @@ NEW ISSUE: it would be good to have an application definition NXicp for chemical 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`. + 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 @@ -635,29 +636,29 @@ describing the geometry of the sample--> In this research field scientists distinguish usually several Euclidean coordinate systems (CS): - * World space; + * 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. + * 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. + * 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. @@ -690,18 +691,18 @@ in what follows each component of the instrument might be equipped with an NXmon add a default plot V = f(time/evaporation_id), essentially for each quantity--> - Metadata and numerical data of the atom probe and the lab in which it + 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. + * 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. @@ -768,8 +769,8 @@ MK::NEW ISSUE--> - + Atom probe microscopes use controlled laser, voltage, or a combination of pulsing strategies to trigger the excitation @@ -875,8 +878,8 @@ laser_gun and laser_beam exists: [min, 0, max, 2]--> LEAP6000-type instruments) having the group/section laser_gun is required and the following of its fields have to be filled: - * name - * wavelength + * name + * wavelength * energy @@ -1003,7 +1006,7 @@ NEW ISSUE: add NXapm_energy_analyzer, a voltage grid like done in Rouen/GPM--> 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>`_ + 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>`_ ) @@ -1013,29 +1016,32 @@ 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)--> - + 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. + * 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 spatiotemporally data could be stored. @@ -1197,7 +1203,7 @@ modifications might be necessary here.--> @@ -1220,7 +1226,7 @@ NEW ISSUE: discuss how to handle cases when we would like to store ideally an ar 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 + 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). @@ -1253,8 +1259,10 @@ term with epos files.--> - + Hit multiplicity. @@ -1280,7 +1288,7 @@ is required to clarify this field and what it means--> - Bitmask which is set to true if the ion + Bitmask which is set to true if the ion is considered and false otherwise. @@ -1316,8 +1324,10 @@ Relevant for ranging are the calibrated data, thats why only these - + Calibrated time-of-flight. @@ -1410,10 +1420,12 @@ numerically the same voltage-and-bowl correction results are obtained - +is needed how to document the reconstruction parameter. +--> Different reconstruction protocols exist. Although these approaches are qualitatively similar, each protocol uses different parameters @@ -1423,11 +1435,11 @@ is needed how to document the reconstruction parameter.--> 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. 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>`_ diff --git a/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml index 2dd4f6bfff..09dc6d2f3c 100644 --- a/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml @@ -1,9 +1,9 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -52,7 +52,7 @@ +The cardinality/total number of triangles in the triangle soup.--> The total number of XDMF values to represent all faces of triangles via XDMF. @@ -80,7 +80,7 @@ unless it is explicitly specified differently--> Version specifier of this application definition. - + Official NeXus NXDL schema with which this file was written. @@ -89,7 +89,7 @@ unless it is explicitly specified differently--> - + Given name of the program/software/tool with which this NeXus @@ -189,8 +189,8 @@ unless it is explicitly specified differently--> paraprobe defined, which specifies the coordinate system. In which all positions are defined. - + The individual coordinate systems which should be used. @@ -207,7 +207,7 @@ unless it is explicitly specified differently--> - + @@ -509,7 +509,7 @@ if weighting_model == isotopic_decomposition needs isotopic_decomposition_rule-- Therefore, summating over the number_of_vertices, allows to extract the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. @@ -561,7 +561,7 @@ if weighting_model == isotopic_decomposition needs isotopic_decomposition_rule-- - @@ -569,7 +569,7 @@ for XDMF in ParaView ?--> iso-surfaces will be computed. In commercial software so far there is not a possibility to export such grid. - + @@ -591,7 +591,7 @@ for XDMF in ParaView ?--> - + Cell center of mass positions along y. @@ -642,11 +642,11 @@ for XDMF in ParaView ?--> The three-dimensional gradient nabla operator applied to scalar_field_magnitude. - + - + @@ -667,7 +667,7 @@ for XDMF in ParaView ?--> - + Cell center of mass positions along y. @@ -726,8 +726,8 @@ for XDMF in ParaView ?--> +doc: | +Functional form of the kernel (Ansatz function).--> Sigma of the kernel in each dimension in the paraprobe @@ -747,7 +747,7 @@ for XDMF in ParaView ?--> - + An iso-surface is the boundary between two regions across which @@ -852,7 +852,7 @@ for XDMF in ParaView ?--> Therefore, summating over the number_of_vertices, allows to extract the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. @@ -893,7 +893,7 @@ for XDMF in ParaView ?--> +exists: optional--> @@ -928,15 +928,15 @@ for XDMF in ParaView ?--> +doc: | +Triangle normals are oriented in the direction of the +gradient vector of the local delocalized scalar field. +Sum of squared values of cross product of triangle normal +construction. +unit: NX_ANY +dimensions: +rank: 1 +dim: [[1, k]]--> Triangle normals are oriented in the direction of the @@ -1013,9 +1013,9 @@ for XDMF in ParaView ?--> some of them may be segments of dislocation lines or other crystal defects which are decorated (or not) with solutes. - @@ -1063,7 +1063,7 @@ NEW ISSUE: refactor using instances of NXms_feature_set--> - Details for features which are (closed) objects. Identifier have to exist in feature_identifier. - + @@ -1098,7 +1098,7 @@ details about specific features--> - + Oriented bounding box aspect ratio. YX versus ZY. @@ -1120,21 +1120,23 @@ details about specific features--> - + A simple approach to describe the entire set of hexahedra - when the main intention is to store the shape of the + when the main intention is to store the shape of the hexahedra for visualization. - + - + @@ -1334,7 +1336,7 @@ these would be polylines etc--> (hole filling, refinement). Identifier have to exist in feature_identifier. - + @@ -1353,7 +1355,7 @@ these would be polylines etc--> of the dataset than threshold. Identifier have to exist in feature_identifier. - + @@ -1606,7 +1608,7 @@ face_identifier_offset(NX_UINT):--> - + @@ -1724,7 +1726,7 @@ face_identifier_offset(NX_UINT):--> - + @@ -1819,7 +1821,7 @@ face_identifier_offset(NX_UINT):--> - Position of the geometric center, which often is but not + Position of the geometric center, which often is but not necessarily has to be the center_of_mass of the polyhedra. @@ -1842,7 +1844,7 @@ face_identifier_offset(NX_UINT):--> - + The number of atoms in each ROI. @@ -1884,9 +1886,9 @@ face_identifier_offset(NX_UINT):--> - + @@ -1936,21 +1938,27 @@ face_identifier_offset(NX_UINT):--> - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXcg_alpha_complex.nxdl.xml b/contributed_definitions/NXcg_alpha_complex.nxdl.xml index b1def2e9a5..edf367ba06 100644 --- a/contributed_definitions/NXcg_alpha_complex.nxdl.xml +++ b/contributed_definitions/NXcg_alpha_complex.nxdl.xml @@ -1,9 +1,9 @@ - + - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the alpha shape, for now 2 or 3. - - - - - - The number of edges. - - - - - The number of faces. - - - - - The number of cells. - - - + + - Computational geometry description of alpha shapes or wrappings to primitives. + Computational geometry of alpha shapes or alpha wrappings about primitives. For details see: @@ -60,22 +33,17 @@ convex hull of a point set.--> * https://dx.doi.org/10.1145/174462.156635 for 3D, * https://dl.acm.org/doi/10.5555/871114 for weighted, and * https://doc.cgal.org/latest/Alpha_shapes_3 for 3D implementation - * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D wrap + * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D wrappings in CGAL, the Computational Geometry Algorithms Library. As a starting point, we follow the conventions of the CGAL library. - - - - - - - Specify which general type of alpha shape is computed. - Using for now the CGAL terminology. Basic means (unweighted) alpha shapes. - Alpha_wrapping means meshes created using alpha wrapping procedures. + Type of alpha complex following the terminology used by CGAL for now. + + Basic means (unweighted) alpha shapes. Alpha_wrapping means meshes + created using the alpha_wrapping algorithm. @@ -83,69 +51,72 @@ convex hull of a point set.--> - + - Specifically when computed with the CGAL, the mode specifies if singular - faces are removed (regularized) of the alpha complex. + Are singular faces removed, i.e. has the alpha complex + been regularized or not. - - - - - + - The alpha, (radius of the alpha-sphere) parameter to be used for alpha - shapes and alpha wrappings. + The alpha parameter, i.e. the radius of the alpha-sphere that + is used when computing the alpha complex. + - The offset distance parameter to be used in addition to alpha - in the case of alpha_wrapping. + The offset distance parameter used when computing alpha_wrappings. - + + - Point cloud for which the alpha shape or wrapping should be computed. + Point cloud for which the alpha shape or wrapping has been computed. - + - Triangle soup for which the alpha wrapping should be computed. + Triangle soup for which the alpha wrapping has been computed. - + - A meshed representation of the resulting shape. + Triangle mesh representing the alpha complex. - - + + + Set of tetrahedra representing the volume inside the alpha complex. + + diff --git a/contributed_definitions/NXcg_cylinder_set.nxdl.xml b/contributed_definitions/NXcg_cylinder_set.nxdl.xml index ae36e40bf4..acf97b44e7 100644 --- a/contributed_definitions/NXcg_cylinder_set.nxdl.xml +++ b/contributed_definitions/NXcg_cylinder_set.nxdl.xml @@ -1,9 +1,9 @@ - + - - + The symbols used in the schema to specify e.g. dimensions of arrays. + + + The dimensionality of the space in which the members are assumed embedded. + + - The cardinality of the set, i.e. the number of cylinders or cones. + The cardinality of the set, i.e. the number of members. - Computational geometry description of a set of cylinders in Euclidean space. + Computational geometry description of a set of cylinders. - The members of the set can have different size. For each member the position - of the center and the height is mandatory. The radius can either be defined - in the radius field or by filling both the upper and the lower radius field. - The latter case can be used to represent truncated cones. + The radius can either be defined in the radii field or by filling both + the upper_cap_radii or lower_cap_radii field. The latter field case can + thus be used to represent truncated cones. - - - - - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for cylinders. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish members for explicit indexing. - - - - - - - - The geometric center of each member. - - - - - - - A direction vector which is parallel to the cylinder/cone axis and - whose magnitude is the height of the cylinder/cone. + A direction vector which is parallel to the cylinder/cone axis + and whose magnitude is the height of the cylinder/cone. - + - + + + Radius of the cylinder if all have the same radius. + + + + Radii of the cylinder. + - + - The radius of the upper circular cap. - This field, combined with lower_cap_radius can be used to - describe (eventually truncated) circular cones. + Radii of the upper circular cap. + + This field, combined with lower_cap_radius can be used to describe + (eventually truncated) circular cones. - + - The radius of the upper circular cap. - This field, combined with lower_cap_radius can be used to - describe (eventually truncated) circular cones. + Radii of the upper circular cap. + + This field, combined with upper_cap_radius can be used to describe + (eventually truncated) circular cones. - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - + - Interior volume of each cylinder + Lateral surface area - + - Lateral surface area + Area of the upper cap of each cylinder. - + - Area of the upper and the lower cap of each cylinder respectively. + Area of the lower cap of each cylinder. - + - - + - Cap and lateral surface area for each cylinder. + Sum of upper and lower cap areas and lateral surface area + of each cylinder. diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml index 6d0e1886e4..32d2c636be 100644 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -1,9 +1,9 @@ - + - - + + The symbols used in the schema to specify e.g. dimensions of arrays. - The dimensionality, which has to be at least 2. + The dimensionality of the space in which the members are assumed embedded. - The cardinality of the set, i.e. the number of ellipses, or ellipsoids. + The cardinality of the set, i.e. the number of members. - Computational geometry description of a set of ellipsoids in Euclidean space. - - Individual ellipsoids can have different half axes. + Computational geometry description of a set of ellipsoids. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for ellipsoids. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish ellipsoids for explicit indexing. - - - - - - - - Geometric center of the ellipsoids. This can be the center of mass. - Dimensionality and cardinality of the point and ellipsoid set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the ellipsoids. - - - - - - - If all ellipsoids in the set have the same half-axes. + Radius of the half axes. + + Use if all ellipsoids in the set have the same half-axes. @@ -89,47 +54,12 @@ - In the case that ellipsoids have different radii use this field - instead of half_axes_radius. + Half-axes radii of each ellipsoid. - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - Are the ellipsoids closed or hollow? - - - - - - - - - - - - - - - - - - - Direction unit vector which points along the largest half-axes. - - - - - - diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml index 6118e2ea03..54cce12794 100644 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -1,9 +1,9 @@ - + - - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -59,96 +60,90 @@ - Computational geometry description of geometric primitives via a face and edge list. + Computational geometry of primitives via a face-and-edge-list data structure. - Primitives must not be degenerated or self-intersect. - Such descriptions of primitives are frequently used for triangles and polyhedra - to store them on disk for visualization purposes. Although storage efficient, - such a description is not well suited for topological and neighborhood queries - of especially meshes that are built from primitives. + Primitives must neither be degenerated nor self-intersect but can differ in + their properties. A face-and-edge-list-based description of primitives is + frequently used for triangles and polyhedra to store them on disk for + visualization purposes (see OFF, PLY, VTK, or STL file formats). - In this case, scientists may need a different view on the primitives which - is better represented for instance with a half_edge_data_structure instance. - The reason to split thus the geometric description of primitives, sets, and - specifically meshes of primitives is to keep the structure simple enough for - users without these computational geometry demands but also enable those more - computational geometry savy users the storing of the additionally relevant - data structure. + Although this description is storage efficient it is not well suited for + topological analyses though. In this case, scientists may need a different + view on the primitives which is better represented with e.g. a + half_edge_data_structure. - This is beneficial and superior over NXoff_geometry because for instance a - half_edge_data_structure instance can be immediately use to reinstantiate - the set without having to recompute the half_edge_structure from the vertex - and face-list based representation and thus offer a more efficient route - to serve applications where topological and graph-based operations are key. + Having an own base class for the data structure how primitives are stored is + useful to embrace both users with small or very detailed specification demands. + + + Hint to help resolve in which Euclidean coordinate system + field values vertices are defined. + + - Dimensionality. + Dimensionality of the primitives described. - + - Array which specifies of how many vertices each face is built. - Each entry represent the total number of vertices for face, irrespectively - whether vertices are shared among faces/are unique or not. + Number of vertices for each face. + + Each entry represents the total number of vertices for that face, + irrespectively whether vertices are shared among faces or not. - + - Number of edges. + Number of edges for each face. + + Each entry represents the total number of edges for that face, + irrespectively whether edges are shared across faces or not. + + + - + - Number of faces. + Number of faces of the primitives. - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. + Integer offset whereby the identifier of the first member + of the vertices differs from zero. - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. + Identifier can be defined explicitly or implicitly. + Inspect the definition of NXcg_primitive_set for further details. - Integer which specifies the first index to be used for distinguishing - identifiers for edges. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. + Integer offset whereby the identifier of the first member + of the edges differs from zero. - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. + Identifier can be defined explicitly or implicitly. + Inspect the definition of NXcg_primitive_set for further details. - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. + Integer offset whereby the identifier of the first member + of the faces differs from zero. - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. + Identifier can be defined explicitly or implicitly. + Inspect the definition of NXcg_primitive_set for further details. - Integer used to distinguish vertices explicitly. + Integer identifier to distinguish all vertices explicitly. @@ -156,7 +151,7 @@ - Integer used to distinguish edges explicitly. + Integer used to distinguish all edges explicitly. @@ -164,23 +159,21 @@ - Integer used to distinguish faces explicitly. + Integer used to distinguish all faces explicitly. - + Positions of the vertices. - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. + Users are encouraged to reduce the vertices to a unique set as this may + result in a more efficient storage of the geometry data. It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. + case vertices_are_unique is likely False. Naively here means that each + vertex is stored even though many share the same positions. @@ -189,7 +182,7 @@ - The edges are stored as a pairs of vertex identifier values. + The edges are stored as pairs of vertex identifier. @@ -198,7 +191,7 @@ - Array of identifiers from vertices which describe each face. + The faces are stored as a concatenated array of vertex identifier tuples. The first entry is the identifier of the start vertex of the first face, followed by the second vertex of the first face, until the last vertex @@ -207,7 +200,7 @@ Therefore, summating over the number_of_vertices, allows to extract the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. @@ -216,18 +209,23 @@ - If true indicates that the vertices are all placed at different positions - and have different identifiers, i.e. no points overlap or are counted twice. + If true, indicates that the vertices are all placed at different positions + and have different identifiers, i.e. no points overlap or are counted more + than once. - If true indicates that no edge is stored twice. Users are encouraged to - consider and use the half_edge_data_structure instead as this will work - towards achieving a cleaner graph-based description if relevant and possible. + If true, indicates that no edge is stored more than once. + + Users are encouraged to consider using a half_edge_data_structure instead. + + + + + If true, indicates that no face is stored more than once. - Specifies for each face which winding order was used if any: diff --git a/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml b/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml index 29f4fef9d0..244290a81b 100644 --- a/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml +++ b/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml @@ -1,9 +1,9 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -30,28 +30,26 @@ Computational geometry description of a geodesic mesh. - People from geodesic/surveyors will likely have specific demands and - different views about what should be included in such a base class, given - that nested geodesic meshes are a key component of climate modelling tools. - For now we propose to use this base class as a container to organize metadata - and data related to geodesic meshes. + A geodesic surface mesh is a triangulated surface mesh with metadata which + can be used as an approximation to describe the surface of a sphere. + Triangulation of spheres are commonly used in Materials Science + for quantifying texture of materials, i.e. the relative rotation of + crystals to sample directions. - Specifically an instance of this base class should detail the rule set how - how the geodesic (surface) mesh was instantiated as there are many - possibilities. A geodesic surface mesh is in this sense a triangulated - surface mesh with metadata. For additional details as an introduction - into the topic see e.g.: + For additional details or an introduction into the topic of geodesic meshes + see (from which specifically the section on subdivision schemes is relevant). + + * `E. S. Popko and C. J. Kitrick <https://doi.org/10.1201/9781003134114>`_ - * `E. S. Popko and C. J. Kitrick <https://doi.org/10.1201/9781003134114>`_ + Earth scientists have specific demands and different views about what should + be included in such a base class, given that nested geodesic meshes are a key + component of climate modelling software. For now we propose to use this + base class as a container for organizing data related to geodesic meshes. - Here, especially the section on subdivision schemes is relevant. + Specifically an instance of this base class should detail the rule set how + e.g. a geodesic (surface) mesh was instantiated as there are many + possibilities to do so. - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - diff --git a/contributed_definitions/NXcg_grid.nxdl.xml b/contributed_definitions/NXcg_grid.nxdl.xml index 2893cf2a50..b827fe1e9f 100644 --- a/contributed_definitions/NXcg_grid.nxdl.xml +++ b/contributed_definitions/NXcg_grid.nxdl.xml @@ -1,9 +1,9 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -33,36 +33,35 @@ - The cardinality or total number of cells/grid points. + The cardinality or total number of cells aka grid points. - Number of boundaries of the bounding box or primitive to the grid. + Number of boundaries of the bounding box or primitive housing the grid. - Computational geometry description of a Wigner-Seitz cell grid in Euclidean space. + Computational geometry description of a grid of Wigner-Seitz cells in Euclidean space. - Frequently convenient three-dimensional grids with cubic cells are used. - Exemplar applications are spectral-solver based crystal plasticity - and stencil methods like phase-field or cellular automata. + Three-dimensional grids with cubic cells are if not the most frequently used + example of such grids. Examples of numerical methods where grids are used + are spectral-solver based crystal plasticity or other stencil methods like + phase-field or cellular automata. - - - - - - - - - + + + Location of the origin of the grid. + + Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` + class to specify the coordinate system in which the origin location is defined. + - + The symmetry of the lattice defining the shape of the unit cell. @@ -78,49 +77,23 @@ - + Number of unit cells along each of the d unit vectors. - The total number of cells, or grid points has to be the cardinality. + + The total number of cells or grid points has to be the cardinality. If the grid has an irregular number of grid positions in each direction, as it could be for instance the case of a grid where all grid points outside some masking primitive are removed, this extent field should - not be used. Instead use the coordinate field. + not be used. Instead, use the coordinate field. - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for cells. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish cells for explicit indexing. - - - - - - + Position of each cell in Euclidean space. @@ -141,24 +114,25 @@ should constraints on the grid be place here or not--> - A tight bounding box or sphere or bounding primitive about the grid. + A tight bounding box about the grid. - - + - How many distinct boundaries are distinguished? + Number of boundaries distinguished + Most grids discretize a cubic or cuboidal region. In this case six sides can be distinguished, each making an own boundary. - + - Name of domain boundaries of the simulation box/ROI e.g. left, right, - front, back, bottom, top. + Name of domain boundaries of the simulation box/ROI + e.g. left, right, front, back, bottom, top. - diff --git a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml index fd003dfc68..260f16e1bc 100644 --- a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml @@ -1,9 +1,9 @@ - + - + @@ -54,41 +54,74 @@ Such a data structure can be used to efficiently circulate around faces and iterate over vertices of a planar graph. - - - - + + + Hint to help resolve in which Euclidean coordinate system + field values vertices are defined. + + + + + Dimensionality of the primitives described. + + + + + + Number of vertices for each face. + + Each entry represents the total number of vertices for that face, + irrespectively whether vertices are shared among faces or not. + + + + + + + + Number of edges for each face. + + Each entry represents the total number of edges for that face, + irrespectively whether edges are shared across faces or not. + + + + + + + + Number of faces of the primitives. + + - In this half-edge data structure vertex identifiers start at 1. - Vertices are identified with consecutive integers up to number_of_vertices. - This field can be used to document which constant integer has to be - added to another set of vertex_identifier to assure that these other - identifiers also start at 1. + Integer offset whereby the identifier of the first member + of the vertices differs from zero. + + Identifier can be defined explicitly or implicitly. + Inspect the definition of :ref:`NXcg_primitive_set` for further details. - + - In this half-edge data structure face identifiers start at 1. - Faces are identified with consecutive integers up to number_of_faces. - This field can be used to document which constant integer has to be - added to another set of face_identifier to assure that these other - identifiers also start at 1. + Integer offset whereby the identifier of the first member + of the edges differs from zero. - The face identifier zero is reserved for the NULL face ! + Identifier can be defined explicitly or implicitly. + Inspect the definition of :ref:`NXcg_primitive_set` for further details. - + - In this half-edge data structure half-edge identifiers start at 1. - Half-edges are identified with consecutive integers up to number_of_half_edges. - This field can be used to document which constant integer has to be - added to another set of half_edge_identifier to assure that these other - identifiers also start at 1. + Integer offset whereby the identifier of the first member + of the faces differs from zero. + + Identifier can be defined explicitly or implicitly. + Inspect the definition of :ref:`NXcg_primitive_set` for further details. - + The position of the vertices. @@ -97,7 +130,7 @@ - + Identifier of the incident half-edge. @@ -105,7 +138,7 @@ - + Identifier of the (starting)/associated half-edge of the face. @@ -113,7 +146,7 @@ - + The identifier of the vertex from which this half-edge is outwards pointing. @@ -121,7 +154,7 @@ - + Identifier of the associated oppositely pointing half-edge. @@ -129,7 +162,7 @@ - + If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. @@ -138,7 +171,7 @@ - + Identifier of the next half-edge. @@ -146,7 +179,7 @@ - + Identifier of the previous half-edge. @@ -159,9 +192,9 @@ Users are referred to the literature for the background of L. Weinberg's work about topological characterization of planar graphs: - * `L. Weinberg 1966a, <https://dx.doi.org/10.1109/TCT.1964.1082216>`_ - * `L. Weinberg, 1966b, <https://dx.doi.org/10.1137/0114062>`_ - * `E. A. Lazar et al. <https://doi.org/10.1103/PhysRevLett.109.095505>`_ + * `L. Weinberg 1966a, <https://dx.doi.org/10.1109/TCT.1964.1082216>`_ + * `L. Weinberg, 1966b, <https://dx.doi.org/10.1137/0114062>`_ + * `E. A. Lazar et al. <https://doi.org/10.1103/PhysRevLett.109.095505>`_ and how this work can e.g. be applied in space-filling tessellations of microstructural objects like crystals/grains. diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml index a604913d9b..57ec8a8e08 100644 --- a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -1,9 +1,9 @@ - + - - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -40,63 +41,53 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Computational geometry description of a set of hexahedra in Euclidean space. - The hexahedra do not have to be connected, can have different size, - can intersect, and be rotated. This class can also be used to describe cuboids or cubes, axis-aligned or not. The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: + applied scientists and computational geometry experts an approach whereby + different specific views can be implemented using the same base class: - * Most simple many experimentalists wish to communicate dimensions/the size - of specimens. In this case the alignment with axes is not relevant as - eventually the only relevant information to convey is the volume of the - specimen. - * In many cases, take for instance an experiment where a specimen was taken - from a specifically deformed piece of material, e.g. cold-rolled, - channel-die deformed, the orientation of the specimen edges with the - experiment coordinate system can be of very high relevance. - Examples include to know which specimen edge is parallel to the rolling, - the transverse, or the normal direction. - * Sufficient to pinpoint the sample and laboratory/experiment coordinate - system, the above-mentioned descriptions are not detailed enough though - to create a CAD model of the specimen. + * In the simplest case experimentalists may use this base class to describe + the dimensions or size of a specimen. In this case the alignment with axes + is not relevant as eventually only the volume of the specimen is of interest. + * In many cases, take for example an experiment where a specimen was cut out + from a specifically deformed piece of material, the orientation of the + specimen's edges with the experiment coordinate system is of high relevance. + Examples include knowledge about the specimen edge, whether it is + parallel to the rolling, the transverse, or the normal direction. + * While the above-mentioned use cases are sufficient to pinpoint the sample + within a known laboratory/experiment coordinate system, these descriptions + are not detailed enough to specify e.g. a CAD model of the specimen. * Therefore, groups and fields for an additional, computational-geometry- - based view of the hexahedra is offered which serve different computational + based view of hexahedra is offered to serve additional computational tasks: storage-oriented simple views or detailed topological/graph-based descriptions. Hexahedra are important geometrical primitives, which are among the most frequently used elements in finite element meshing/modeling. - Hexahedra have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. + As a specialization of the :ref:`NXcg_primitive_set` base class hexahedra + are assumed non-degenerated, closed, and built of polygons that are + not self-intersecting. The term hexahedra will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding - box (OBB). + the special cases cuboid, cube, box, axis-aligned bounding box (AABB), + and optimal bounding box (OBB). - An axis-aligned bounding box is a common data object in - computational science and codes to represent a cuboid whose edges - are aligned with a coordinate system. As a part of binary trees these - are important data objects for time as well as space efficient queries + An axis-aligned bounding box is a common data object in computational science + and simulation codes to represent a cuboid whose edges are aligned with the + base vectors of a coordinate system. As a part of binary trees, these data + objects are important for making time- as well as space-efficient queries of geometric primitives in techniques like kd-trees. An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are + tightly fitting box about an arbitrary object. In general, such boxes are rotated. Exact and substantially faster in practice approximate algorithms - exist for computing optimal or near optimal bounding boxes for point sets. + exist to compute optimal or near optimal bounding boxes for sets of points. - - - - - - - A qualitative description of each hexahedron/cuboid/cube/box. + Qualifier for the shape of each hexahedron. @@ -105,9 +96,9 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> - Qualifier how one edge is longer than all other edges of the hexahedra. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. + Qualifier that is useful in cases when one edge is longer than all other + edges of the hexahedra. Often the term length is associated with the + assumption that one edge is parallel to an axis of the coordinate system. @@ -115,8 +106,11 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> - Qualifier often used to describe the length of an edge within - a specific coordinate system. + Qualifier often used to describe the extent of an object in the horizontal + direction assuming a specific coordinate system. + + For the sake of explicitness quantities like length, width, and height + should not be reported without specifying also the assumed reference frame. @@ -124,31 +118,24 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> - Qualifier often used to describe the length of an edge within - a specific coordinate system. + Qualifier often used to describe the extent of an object in the vertical + direction assuming a specific coordinate system. - + - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the hexahedrally-shaped sample/sample part. + Volume of each hexahedron. - - - - - - - + - Total area (of all six faces) of each hexahedron. + Total (surface) area (of all six faces) of each hexahedron. @@ -176,64 +163,31 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Only to be used if is_box is present. In this case, this field describes whether hexahedra are boxes whose primary edges are parallel to the - axes of the Cartesian coordinate system. - - - - - - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish hexahedra for explicit indexing. + axes of the coordinate system. - - + - - A simple approach to describe the entire set of hexahedra when the - main intention is to store the shape of the hexahedra for visualization. + Combined storage of all primitives of all hexahedra. - - + - Disentangled representations of the mesh of specific hexahedra. + Individual storage of each hexahedron. - - + - Disentangled representation of the planar graph that each hexahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. + Individual storage of each hexahedron as a graph. diff --git a/contributed_definitions/NXcg_marching_cubes.nxdl.xml b/contributed_definitions/NXcg_marching_cubes.nxdl.xml index 4f3f1e008c..f04bdaad8a 100644 --- a/contributed_definitions/NXcg_marching_cubes.nxdl.xml +++ b/contributed_definitions/NXcg_marching_cubes.nxdl.xml @@ -1,9 +1,9 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -30,8 +30,8 @@ Computational geometry description of the marching cubes algorithm. - Documenting which specific version was used can help to understand how robust - the results are with respect to the topology of the triangulation. + Documenting which specific version was used helps with understanding how + robust the results are with respect to the topology of the triangulation. @@ -39,35 +39,22 @@ marching cubes algorithm implementation is operating. - + Reference to the specific implementation of marching cubes used. See for example the following papers for details about how to identify a DOI which specifies the implementation used: - * `W. E. Lorensen <https://doi.org/10.1109/MCG.2020.2971284>`_ - * `T. S. Newman and H. Yi <https://doi.org/10.1016/j.cag.2006.07.021>`_ + * `W. E. Lorensen <https://doi.org/10.1109/MCG.2020.2971284>`_ + * `T. S. Newman and H. Yi <https://doi.org/10.1016/j.cag.2006.07.021>`_ The value placed here should be a DOI. If there are no specific DOI or details write not_further_specified, or give at least a free-text description. - - - Commercial or otherwise given name to the program which was used. - - - - Program version plus build number, commit hash, or description of - an ever persistent resource where the source code of the program - and build instructions can be found so that the program can be - configured in such a manner that the result file is ideally - recreatable yielding the same results. - - - + diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml index 2fadb8df7f..f20cc47770 100644 --- a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml +++ b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml @@ -1,9 +1,9 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -33,151 +33,74 @@ - Computational geometry description of a set of parallelograms in Euclidean space. + Computational geometry description of a set of parallelograms. - The parallelograms do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe rectangles or squares, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: + This class can also be used to describe rectangles or squares, irrespective + whether these are axis-aligned or not. The class represents different + access and description levels to embrace applied scientists and computational + geometry experts with their different views: - * Most simple many experimentalists wish to communicate dimensions/the size - of e.g. a region of interest in the 2D plane. In this case the alignment - with axes is not relevant as eventually relevant is only the area of the ROI. + * The simplest case is the communication of dimensions aka the size of a + region of interest in the 2D plane. In this case, communicating the + alignment with axes is maybe not as relevant as it is to report the area + of the ROI. * In other cases the extent of the parallelogram is relevant though. - * Finally in CAD models we would like to specify the polygon - which is parallelogram represents. + * Finally, in CAD models it should be possible to specify the polygons + which the parallelograms represent with exact numerical details. - Parallelograms are important geometrical primitives. Not so much because of their - uses in nowadays, thanks to improvements in computing power, not so frequently - any longer performed 2D simulation. Many scanning experiments probe though - parallelogram-shaped ROIs on the surface of samples. + Parallelograms are important geometrical primitives as their usage for + describing many scanning experiments shows where typically parallelogram-shaped + ROIs are scanned across the surface of a sample. - Parallelograms have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term parallelogram will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - rectangle, square, 2D box, axis-aligned bounding box (AABB), or - optimal bounding box (OBB) but here the analogous 2D cases. + The term parallelogram will be used throughout this base class thus including + the important special cases rectangle, square, 2D box, axis-aligned bounding box + (AABB), or optimal bounding box (OBB) as analogous 2D variants to their 3D + counterparts. See :ref:`NXcg_hexahedron_set` for the generalization in 3D. An axis-aligned bounding box is a common data object in computational science - and codes to represent a rectangle whose edges are aligned with the axes - of a coordinate system. As a part of binary trees these are important data - objects for time- as well as space-efficient queries + and simulation codes to represent a rectangle whose edges are aligned with the + axes of a coordinate system. As a part of binary trees AABBs are important data + objects for executing time- as well as space-efficient queries of geometric primitives in techniques like kd-trees. - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Other than in 3D dimensions the rotation calipher method offers - a rigorous approach to compute optimal bounding boxes in 2D. + An optimal bounding box is a common data object which provides the best, i.e. + most tightly fitting box about an arbitrary object. In general such boxes are + rotated. Other than in 3D dimensions, the rotation calipher method offers + a rigorous approach to compute an optimal bounding box to a point set in 2D. - - - - - - - - - A qualitative description of each parallelogram/rectangle/square/box. - - - - - - - - - Qualifier how one edge is longer than all the other edge of the parallelogam. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - - - - - - + - Qualifier often used to describe the length of an edge within - a specific coordinate system. + To specify which parallelogram is a rectangle. - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the parallelogram. - - - - - - - - - - - - Only to be used if is_box is present. In this case, this field describes - whether parallelograms are rectangles/squares whose primary edges - are parallel to the axes of the Cartesian coordinate system. + Only to be used if is_rectangle is present. In this case, this field + describes whether parallelograms are rectangles whose primary edges + are parallel to the axes of the coordinate system. - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - parallelograms. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish parallelograms for explicit indexing. - - - - - - - - - - - + - A simple approach to describe the entire set of parallelograms when the - main intention is to store the shape of the parallelograms for visualization. + Combined storage of all primitives of all parallelograms. - - + - Disentangled representations of the mesh of specific parallelograms. + Individual storage of each parallelogram. - + diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml index 78367f5ae2..bea36a1a98 100644 --- a/contributed_definitions/NXcg_point_set.nxdl.xml +++ b/contributed_definitions/NXcg_point_set.nxdl.xml @@ -1,9 +1,9 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. - The dimensionality, which has to be at least 1. + The dimensionality. @@ -38,61 +38,50 @@ - Computational geometry description of a set of points in Euclidean space. + Computational geometry description of a set of points. - The relevant coordinate system should be referred to in the NXtransformations - instance. Points may have an associated time value; however users are advised - to store time data of point sets rather as instances of time events, where - for each point in time there is an NXcg_point_set instance which specifies the - points locations. This is a frequent situation in experiments and computer - simulations, where positions of points are taken at the same point in time; - and therefore an additional time array would demand to store redundant pieces - of information for each point. + Points may have an associated time value. Users are advised though to store + time data of point sets rather as instances of time events, where for each + point in time there is an :ref:`NXcg_point_set` instance which specifies the + points' locations. + + This is a frequent situation in experiments and computer simulations, where + positions of points are taken at the same point in time (real time or + simulated physical time). Thereby, the storage of redundant time stamp + information per point is considered as obsolete. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for points. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - + - Integer used to distinguish points for explicit indexing. + Coordinates of the points. - + + - + - The array of point coordinates. + (Elapsed) time for each point. + + If the field time is needed contextualize the time_offset relative to which + time values are defined. Alternative store timestamp. - + - - + - The optional array of time for each vertex. + ISO8601 with local time zone offset for each point. - + - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. + ISO8601 with local time zone offset that serves as the reference + for values in the field time. - + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 6bf48cad49..6f6cf68e64 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -1,9 +1,9 @@ - + - + @@ -46,11 +46,13 @@ descriptors.--> - + Computational geometry description of a set of polygons in Euclidean space. - Polygons are related are specialized polylines: + Polygons are specialized polylines: * A polygon is a geometric primitive that is bounded by a closed polyline * All vertices of this polyline lay in the d-1 dimensional plane. @@ -63,63 +65,40 @@ descriptors.--> As three-dimensional objects, a set of polygons can be used to define the hull of what is effectively a polyhedron; however users are advised to use - the specific NXcg_polyhedron_set base class if they wish to describe closed - polyhedra. Even more general complexes can be thought, for instance - piecewise-linear complexes, as these can have holes though, polyhedra without - holes are one subclass of such complexes, users should rather design an own + the specific :ref:`NXcg_polyhedron_set` base class if they wish to describe closed + polyhedra. Even more general complexes can be thought of. An example are the + so-called piecewise-linear complexes used in the TetGen library. + + As these complexes can have holes though, polyhedra without holes are one + subclass of such complexes, users should rather design an own base class e.g. NXcg_polytope_set to describe such even more - complex primitives. + complex primitives instead of abusing this base class for such purposes. - - - - - - - - - + - Integer which specifies the first index to be used for distinguishing - polygons. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. + The total number of vertices in the set. - + + - Integer used to distinguish polygons for explicit indexing. + Combined storage of all primitives of all polygons. - - - - - - + + - A simple approach to describe the entire set of polygons when the - main intention is to store the shape of the polygons for visualization. + Individual storage of the mesh of each polygon. - - - - - - - - - - + + + Individual storage of each polygon as a graph. + + + - The accumulated length of the polygon edge. + For each polygon its accumulated length along its edges. @@ -127,7 +106,8 @@ properties of the polygon primitives--> - Array of interior angles. There are many values per polygon as number_of_vertices. + Interior angles for each polygon. There are as many values per polygon + as the are number_of_vertices. The angle is the angle at the specific vertex, i.e. between the adjoining edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. @@ -148,78 +128,4 @@ properties of the polygon primitives--> - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - - diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index 57fffc68db..af373d8212 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -1,9 +1,9 @@ - + - - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -52,56 +53,21 @@ for clean graph-based descriptions of polyhedra.--> - Computational geometry description of a polyhedra in Euclidean space. + Computational geometry description of a set of polyhedra in Euclidean space. - Polyhedra, also so-called cells (especially in the convex of tessellations), - here described have to be all non-degenerated, closed, built of and thus - built out of not-self-intersecting polygon meshes. Polyhedra may make contact, - so that this base class can be used for a future description of tessellations. + Polyhedra or so-called cells (especially in the convex of tessellations) are + constructed from polygon meshes. Polyhedra may make contact to allow a usage + of this base class for a description of tessellations. - For more complicated manifolds and especially for polyhedra with holes, users - are advised to check if their particular needs are described by creating - (eventually customized) instances of an NXcg_polygon_set, which can be - extended for the description of piecewise-linear complexes. + For the description of more complicated manifolds and especially for polyhedra + with holes, users are advised to check if their particular needs are described + by creating customized instances of an :ref:`NXcg_polygon_set`. - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the polyhedra. - - - - - - - - - Total surface area as the sum of all faces. - - - - - - + The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. This field can be used to interpret - the array/field with the individual area values for each face. + are counted for each polyhedron. @@ -109,86 +75,40 @@ for clean graph-based descriptions of polyhedra.--> - Area of each of the four triangular faces of each tetrahedron. + Area of each of faces. - + The number of edges for each polyhedron. Edges of adjoining polyhedra - are counterd for each polyhedron. This field can be used to interpret - the array/field with the individual length for each edge. + are counterd for each polyhedron. - Length of each edge of each tetrahedron. + Length of each edge. - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - - Integer which specifies the first index to be used for distinguishing - polyhedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish polyhedra for explicit indexing. - - - - - - - - - - A simple approach to describe the entire set of polyhedra when the - main intention is to store the shape of the polyhedra for visualization. + Combined storage of all primitives of all polyhedra. - - + - Disentangled representations of the mesh of specific polyhedron. + Individual storage of each polyhedron. - - + - Disentangled representation of the planar graph that each polyhedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. + Individual storage of each polygon as a graph. - diff --git a/contributed_definitions/NXcg_polyline_set.nxdl.xml b/contributed_definitions/NXcg_polyline_set.nxdl.xml index 5235f93211..898a56acde 100644 --- a/contributed_definitions/NXcg_polyline_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyline_set.nxdl.xml @@ -1,9 +1,9 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -50,58 +50,36 @@ multiple vertices possible with the same point coordinates but different names.- - Computational geometry description of a set of polylines in Euclidean space. + Computational geometry description of a set of polylines. Each polyline is built from a sequence of vertices (points with identifiers). Each polyline must have a start and an end point. - The sequence describes the positive traversal along the polyline when walking - from the start vertex to the end/last vertex. + The sequence describes the positive traversal along the polyline when + walking from the first to the last vertex. - - - - + - The total number of vertices, irrespective of their eventual uniqueness, - i.e. the total number of vertices that have to be visited when walking - along each polyline. + Reference to an instance of :ref:`NXcg_point_set` which defines + the location of the vertices that are referred to in the + NXcg_polyline_set instance. - - + + - Array which specifies of how many vertices each polyline is built. - The number of vertices represent the total number of vertices for - each polyline, irrespectively whether vertices are shared or not. - See the docstring for polylines for further details about how - a set with different polyline members should be stored. + The total number of vertices that have different positions. - - - - + - Reference to or definition of a coordinate system with - which the qualifiers and polyline data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - polylines. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. + The total number of vertices, irrespective of their eventual uniqueness. - + - Integer used to distinguish polylines for explicit indexing. + The total number of vertices of each polyline, irrespectively + whether vertices are shared by vertices or not. + See the docstring for polylines for further details about how + a set with different polyline members should be stored. @@ -111,73 +89,57 @@ multiple vertices possible with the same point coordinates but different names.- Unique means not necessarily unique in position only but also unique in identifier. In fact, it is possible to distinguish two vertices as two when they share the same position in space but have different identifiers.--> - + Positions of the vertices which support the members of the polyline set. - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. + Users are encouraged to reduce the vertices to unique positions and vertices + as this often supports with storing geometry data more efficiently. + It is also possible though to store the vertex positions naively + in which case vertices_are_unique is likely False. + Naively, here means that one stores each vertex of a triangle mesh + even though many vertices are shared between triangles and thus + storing multiple copies of their positions is redundant. + If true indicates that the vertices are all placed at different positions and have different identifiers, i.e. no points overlap - or are counted twice. + or are counted several times. - Sequence of vertex identifiers which describe each polyline. + Sequence of identifier for vertices how they build each polyline. A trivial example is a set with two polylines with three vertices each. If the polylines meet in a junction, say the second vertex is shared and marking the junction between the two polylines, it is possible that - there are only five unique positions suggesting five unique vertices. + there are only five unique positions. This suggests to store five + unique vertices. - A non-trivial example is a set with several polylines, each of which with - eventually different number of vertices. The array stores the vertex - identifiers in the order how the polylines are visited: + A non-trivial example is a set with several polylines. Assume that each + has a different number of vertices. The array stores the identifier of + the vertices in the sequence how the polylines are visited: - The first entry is the identifier of the start vertex of the first polyline, + The first entry is the identifier of the first vertex of the first polyline, followed by the second vertex of the first polyline, until the last vertex - of the polyline. Thereafter, the start vertex of the second polyline, and - so on and so forth. Using the (cumulated) counts in number_of_vertices, - the vertices of the n-th polyline can be accessed on the following - array index interval: + of the first polyline. + Thereafter, the first vertex of the second polyline, and so on and so forth. + Using the (cumulated) counts in number_of_vertices, the vertices of the + n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - - - - The length of each polyline. - - - - - - - - If true specifies that a polyline is closed, i.e. - its end point is connected to the start point. - - - - - - - diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml new file mode 100644 index 0000000000..ac451bdc66 --- /dev/null +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -0,0 +1,212 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the space. + + + + + The cardinality of the set, i.e. the number of members. + + + + + Computational geometry description of a set of primitives in Euclidean space. + + Primitives must neither be degenerated nor self-intersect. + Individual primitives can differ in their properties (e.g. size, shape, rotation). + + + + + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + + + + + The dimensionality of the primitive set. + + + + + + + + + + The cardinality of the primitive set. + + + + + Integer offset whereby the identifier of the first member + of the set differs from zero. + + Identifiers can be defined either implicitly or explicitly. + For implicit indexing identifiers are defined on the interval + :math:`[identifier_offset, identifier_offset + c - 1]`. + + Therefore, implicit identifier are completely defined by the value of + identifier_offset and cardinality. For example if identifier run from + -2 to 3 the value for identifier_offset is -2. + + For explicit indexing the field identifier has to be used. + Fortran-/Matlab- and C-/Python-style indexing have specific implicit + identifier conventions where identifier_offset is 1 and 0 respectively. + + + + + Identifier of each member for explicit indexing. + + + + + + + + The center of mass position of each primitive. + + + + + + + + + + True if the center is a center of mass. + + + + + + + + A qualitative description of the shape of each primitive. + + + + + + + + + Qualifier for the length of characteristic features of the primitive. + + Often the term length is associated with the assumption that one + edge is parallel to an axis of the coordinate system. + + + + + + + + Qualifier often used to describe the length of one characteristic edge + within the coordinate system. + + + + + + + + True if primitive is closed such that it has properties like area or volume. + + + + + + + + Volume of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + + + + + + + + Alias for surface_area of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + + + + + + + + Direction unit vector which points along the + longest principal axis of each primitive. + + Use the depends_on attribute to specify in which coordinate system + these direction unit vectors are defined. + + + + + + + + + + + diff --git a/contributed_definitions/NXcg_roi_set.nxdl.xml b/contributed_definitions/NXcg_roi_set.nxdl.xml index 13c2608cd4..edbd5b2a53 100644 --- a/contributed_definitions/NXcg_roi_set.nxdl.xml +++ b/contributed_definitions/NXcg_roi_set.nxdl.xml @@ -1,9 +1,9 @@ - + - - + + The symbols used in the schema to specify e.g. dimensions of arrays. + Use the depends_on fields of the respective specialized + :ref:`NXcg_primitive_set` base class surplus + :ref:`NXcoordinate_system_set` with at least one instance of + :ref:`NXcoordinate_system` to define explicitly the reference frame in + which the primitives are defined. Alternatively, although + disencouraged, one may use one :ref:`NXcoordinate_system_set` with + with only one :ref:`NXcoordinate_system` in the application definition + to specify implicitly in which reference frame the primitives are + defined. If none of these two possibilities is used all primitives + are assumed defined in the McStas coordinate system. - Base class to hold geometric primitives. + Base class for a region-of-interest (ROI) bound by geometric primitives. + + So-called region-of-interest(s) (ROIs) are typically used to describe a + region in space (and time) where an observation is made or for which + a computer simulation is performed with given boundary conditions. - - - - - + + + + + + + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index 716715f892..b676aedf90 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -1,9 +1,9 @@ - + - - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -39,46 +40,10 @@ - Computational geometry description of a set of spheres in Euclidean space. + Computational geometry description of a set of spheres. - Each sphere can have a different radius. + Each sphere can have a different radius but all need to have finite volume. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for spheres. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish spheres for explicit indexing. - - - - - - - - Geometric center of the spheres. This can be the center of mass. - Dimensionality and cardinality of the point and sphere set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the spheres. - - - - - - In the case that all spheres have the same radius. @@ -93,29 +58,4 @@ - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - Are the spheres closed or hollow? - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index 62796fd9f1..bc8b3e301e 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -1,9 +1,9 @@ - + - - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -38,57 +33,13 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> - Computational geometry description of a set of tetrahedra in Euclidean space. + Computational geometry description of a set of tetrahedra. - The tetrahedra do not have to be connected. - As tetrahedral elements they are among hexahedral elements one of the most + Among hexahedral elements, tetrahedral elements are one of the most frequently used geometric primitive for meshing and describing volumetric - and surface descriptions of objects at the continuum scale. - - A set of tetrahedra in 3D Euclidean space. - - The tetrahedra do not have to be connected, can have different size, - can intersect, and be rotated. - - Tetrahedra are the simplest and thus important geometrical primitive. - They are frequently used as elements in finite element meshing/modeling. - - Tetrahedra have to be non-degenerated, closed, and built of triangles - which are not self-intersecting. + objects in continuum-field simulations. - - - - - - - - - Interior volume - - - - - - - - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the tetrahedra. - - - - - - - - - Total surface area as the sum of all four triangular faces. - - - - - Area of each of the four triangular faces of each tetrahedron. @@ -107,69 +58,29 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> - - - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - tetrahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish tetrahedra for explicit indexing. - - - - - - - - - + Interior angle values for each tetrahedron. + The quadruplet of angles is a sequence following the order of the vertices. + The angle is the angle at the specific vertex. + + The sequence of the vertices follows their definition in tetrahedra. +detailed mesh-based representation--> - - A simple approach to describe the entire set of tetrahedra when the - main intention is to store the shape of the tetrahedra for visualization. - should take the possibility to describe + Combined storage of all primitives of all tetrahedra. - - + - Disentangled representations of the mesh of specific tetrahedra. + Individual storage of each tetrahedron. - - + - Disentangled representation of the planar graph that each tetrahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. + Individual storage of each tetrahedron as a graph. diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index b6165ebc45..092b43c08b 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -1,9 +1,9 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -43,61 +43,39 @@ - Computational geometry description of a set of triangles in Euclidean space. + Computational geometry description of a set of triangles. - - - - + - Reference to or definition of a coordinate system with - which the qualifiers and primitive data are interpretable. - - - - - Integer which specifies the first index to be used for distinguishing - triangles. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. + Number of unique vertices in the triangle set. - + - Integer used to distinguish triangles for explicit indexing. + Combined storage of all primitives of all triangles. + + This description resembles the typical representation of primitives + in file formats such as OFF, PLY, VTK, or STL. - - - - - - + + - A simple approach to describe the entire set of triangles when the - main intention is to store the shape of the triangles for visualization. + Individual storage of each triangle. + Users are advised that using such individual storage of primitives + may be less storage efficient than creating a combined storage. - - - - - - - - - - - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. + Length of the edges of each triangle. + + For each triangle values are reported via traversing + the vertices in the sequence as these are defined. @@ -106,27 +84,14 @@ properties of triangles--> - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. + Interior angles of each triangle. + + For each triangle values are reported for the angle opposite + to the respective edges in the sequence how vertices are defined. - - - The center of mass of each polygon. - - - - - - - - - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - diff --git a/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml b/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml index 6b8adf5262..5aebe0d789 100644 --- a/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml +++ b/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml @@ -1,9 +1,9 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -31,22 +31,8 @@ Computational geometry description of a mesh of triangles. The mesh may be self-intersecting and have holes but the - triangles must not be degenerated. + triangles used must not be degenerated. - - A graph-based approach to describe the mesh when it is also desired diff --git a/contributed_definitions/NXcg_unit_normal_set.nxdl.xml b/contributed_definitions/NXcg_unit_normal_set.nxdl.xml index 26b49c145a..0f7df7c879 100644 --- a/contributed_definitions/NXcg_unit_normal_set.nxdl.xml +++ b/contributed_definitions/NXcg_unit_normal_set.nxdl.xml @@ -1,9 +1,9 @@ - + - - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -42,12 +44,14 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Computational geometry description of a set of (oriented) unit normal vectors. + + Store normal vector information as properties of primitives. + Use only only as a child of an instance of :ref:`NXcg_primitive_set` + so that this instance acts as the parent to define a context. - - - + - Direction of each normal + Direction of each normal - a unit normal. @@ -56,12 +60,13 @@ rather make this a set of vectors, irrespective whether these are unit or not--> - Qualifier how which specifically oriented normal to its primitive each - normal represents. + Qualifier which details the orientation of each normal vector + in relation to its primitive, assuming the object is viewed + from a position outside the object. * 0 - undefined - * 1 - outer - * 2 - inner + * 1 - outer unit normal vector + * 2 - inner unit normal vector diff --git a/contributed_definitions/NXchamber.nxdl.xml b/contributed_definitions/NXchamber.nxdl.xml index fec3864684..b0712af128 100644 --- a/contributed_definitions/NXchamber.nxdl.xml +++ b/contributed_definitions/NXchamber.nxdl.xml @@ -1,9 +1,9 @@ - + - + - Component of an instrument to store or place objects and specimens. + Base class for a chamber in an instrument that stores real or simulated objects. - + - Given name/alias. + Given name for the chamber of this component e.g. analysis chamber + or buffer chamber, load-lock chamber, microscope column, glove box. - + Free-text field for describing details about the chamber. For example out of which material was the chamber built. diff --git a/contributed_definitions/NXcomponent_em.nxdl.xml b/contributed_definitions/NXcomponent_em.nxdl.xml new file mode 100644 index 0000000000..bedba8b6f6 --- /dev/null +++ b/contributed_definitions/NXcomponent_em.nxdl.xml @@ -0,0 +1,69 @@ + + + + + + + Base class for components used in an electron microscope. + + The electron microscope can be a real one or a simulated microscope. + The key motivation behind this generalization is the observation that in all + cases a controlled electron beam is generated in reality or that beam is simulated + and this beam is then used or modified in a controlled manner for the purpose + of studying physical interaction mechanisms of the beam with matter. + Here it does not matter whether one considers a real specimen or a simulated one. + + Using a common description for the real experiment in the lab and - what is + typically a simplification of it - via a computer simulation, has the benefit + that many pieces of information can be stored in the same way. In effect, + users are guided with finding information and unnecessary descriptive + variety for what are exactly the same concept is avoided to work towards + more interoperability. + + Another motivation to make no fundamental distinction between a scanning and + a transmission electron microscope is that both are electron microscopes whose + components are often very similar. + + + + Given name to the component e.g stage, lens C1, etc. + + + + + Ideally, a (globally) unique persistent identifier, link, or text to a + resource which gives further details to this component. + If such resource does not exist, a free-text field to report + further details about the component is possible. + + + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the component in the instrument. + + + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml new file mode 100644 index 0000000000..a8dcb83694 --- /dev/null +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -0,0 +1,143 @@ + + + + + + Base class to detail a coordinate system (CS). + + Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as + a member in an :ref:`NXcoordinate_system_set` and the name of the instance + should be this alias. This may support a process whereby jargon when talking + about coordinate systems and conventions may become cleaner for users + because it is not evident for people outside a lab that terms like e.g. + tip space or specimen space refer to the same coordinate system. + This is an example of jargon used in e.g. the field of atom + probe tomography. + + + + Human-readable field telling where the origin of this CS is. + Exemplar values could be *left corner of the lab bench*, *door-handle* + *pinhole through which the electron beam exists the pole piece*. + *barycenter of the triangle*, *center of mass of the stone*. + + + + + + An alternative name given to that coordinate system. + + + + + Coordinate system type. + + + + + + + + Handedness of the coordinate system if it is a Cartesian. + + + + + + + + + Possibility to define an alias for the name of the x-axis. + + + + + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + + + + + Base unit vector along the first axis which spans the coordinate system. + This axis is frequently referred to as the x-axis in real space and + the i-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the y-axis. + + + + + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second axis which spans the coordinate system. + This axis is frequently referred to as the y-axis in real space and + the j-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the z-axis. + + + + + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second axis which spans the coordinate system. + This axis is frequently referred to as the z-axis in real space and + the k-axis in reciprocal space. + + + + + + diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/contributed_definitions/NXcoordinate_system_set.nxdl.xml index 7f32f0c7ed..2952ccb2ab 100644 --- a/contributed_definitions/NXcoordinate_system_set.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system_set.nxdl.xml @@ -1,9 +1,9 @@ - + - + - Container to hold different coordinate systems conventions. + Base class to hold different coordinate systems and representation conversions. - It is the purpose of this base class to define these conventions and - offer a place to store mappings between different coordinate systems - which are relevant for the interpretation of the data described - by the application definition and base class instances. + How many nodes of type :ref:`NXcoordinate_system_set` should be used in an appdef? - For each Cartesian coordinate system users should use a set of - NXtransformations: + * 0; if no instance of :ref:`NXcoordinate_system_set` and therein or elsewhere across + the appdef an instance of NXcoordinate_system is defined, + the default NeXus `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ + coordinate system is assumed. This makes :ref:`NXcoordinate_system_set` and + NXcoordinate_system base classes backwards compatible to older + NeXus conventions and classes. + * 1; if only one :ref:`NXcoordinate_system_set` is defined, it should be placed + as high up in the node hierarchy (ideally right below an instance of NXentry) + of the application definition tree as possible. + This :ref:`NXcoordinate_system_set` should at least define one NXcoordinate_system + instance which should be called mcstas for the sake of improved clarity. + Alternatively, at least one NXcoordinate_system member of the set should be + defined and named such that it is clear how this coordinate system is + typically referred to in a community. Additional NXcoordinate_system instances + should be specified if possible in that same :ref:`NXcoordinate_system_set` instead + of cluttering them across the tree. + + If this is the case, it is assumed that the NXcoordinate_system_members + overwrite the NeXus default McStas coordinate system, i.e. users can thereby + conveniently and explicitly specify the coordinate system(s) that + they wish to use. + + Users are encouraged to write also explicit and clean depends_on fields in + all groups that encode information about where the interpretation of coordinate + systems is relevant. If these depends_on hints are not provided, it is + automatically assumed that all children (to arbitrary depth) + of that branch and sub-branches below the one in which that + :ref:`NXcoordinate_system_set` is defined use either the only NXcoordinate_system_set + instance in that set or the application definition is considered + underconstrained which should at all costs be avoided and in which case + again McStas is assumed. + * 2 and more; as soon as more than one :ref:`NXcoordinate_system_set` is specified + somewhere in the tree, different interpretations are possible as to which + of these coordinate system sets and instances apply or take preference. + We realize that such ambiguities should at all costs be avoided. + However, the opportunity for multiple sets and their instances enables to + have branch-specific coordinate system conventions which could especially + be useful for deep classes where multiple scientific methods are combined or + cases where having a definition of global translation and conversion tables + how to convert between representations in different coordinate systems + is not desired or available for now. + We argue that having 2 or more :ref:`NXcoordinate_system_set` instances and respective + NXcoordinate_system instances makes the interpretation eventually unnecessary + complicated. Instead, developers of application definitions should always try + to work for clarity and thus use only one top-level coordinate system set. - * These should define the three base vectors. - * The location of the origin. - * The affine transformations which bring each axis of this coordinate system - into registration with the McStas coordinate system. - * Equally, affine transformations should be given for the inverse mapping. + For these reasons we conclude that the option with one top-level + :ref:`NXcoordinate_system_set` instance is the preferred choice. - As an example one may take an experiment or computer simulation where - there is a laboratory (lab) coordinate system, a sample/specimen coordinate - system, a crystal coordinate system, and additional coordinate systems, - which are eventually attached to components of the instrument. + McStas is used if neither an instance of :ref:`NXcoordinate_system_set` nor an instance + of NXcoordinate_system is specified. However, even in this case it is better + to be explicit like for every other coordinate system definition to support + users with interpreting the content and logic behind every instance of the tree. - If no additional transformation is specified in this group or if an - instance of an NXcoordinate_system_set is absent it should be assumed - the so-called McStas coordinate system is used. + How to store coordinate systems inside :ref:`NXcoordinate_system_set`? + Individual coordinate systems should be specified as members of the + :ref:`NXcoordinate_system_set` instance using instances of NXcoordinate_system. - Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. - This is a Cartesian coordinate system whose z axis points along the neutron - propagation axis. The systems y axis is vertical up, while the x axis points - left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. + How many individual instances of NXcoordinate_system to allow within one + instance of :ref:`NXcoordinate_system_set`? - Within each NXtransformations a depends_on section is required. The depends_on - field specifies if the coordinate system is the root/reference - (which is indicated by writing "." in the depends_on section.) + * 0; This case should be avoided for the sake of clarity but this case could + mean the authors of the definition meant that McStas is used. We conclude, + McStas is used in this case. + * 1; Like above-mentioned this case has the advantage that it is explicit + and faces no ambiguities. However, in reality typically multiple + coordinate systems have to be mastered especially for complex + multi-signal modality experiments. + * 2 or more; If this case is realized, the best practice is that in every + case where a coordinate system should be referred to the respective class + has a depends_on field which resolves the possible ambiguities which specific + coordinate systems is referred to. The benefit of this explicit and clear + specifying of the coordinate system used in every case is that especially + in combination with having coordinate systems inside deeper branches + makes up for a very versatile, backwards compatible, but powerful system + to express different types of coordinate systems using NeXus. + + In effect, 1 should be the preferred choice. However, if more than one coordinate + system is defined for practical purposes, explicit depends_on fields should + always guide the user for each group and field which of the coordinate system + one refers to. - - - - A group of transformations which specify: - - * Three base vectors of the coordinate system. - * Origin of the coordinate system. - * A depends_on keyword. Its value can be "." or the name of an - NXtransformations instance which needs to exist in the - NXcoordinate_system_set instance. - * If the coordinate system is the reference one it has to be named - reference. - - In case of having more than one NXtransformations there has to be for - each additional coordinate system, i.e. the one not the reference: - - * A set of translations and rotations which map each base vector to the reference. - * A set of translations and rotations which map each reference base vector - to the coordinate system. - - The NXtransformations for these mappings need to be formatted - according to the descriptions in NXtransformations. - - - - - - + + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index c2e8f7c678..34d1d54e13 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -1,9 +1,9 @@ - + - + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of images taken, at least one. + + + Corrector for aberrations in an electron microscope. - Different technology partners use different naming schemes and models - for quantifying the aberration coefficients. + Different technology partners use different naming schemes and + models for quantifying the aberration coefficients. - The corrector in an electron microscope is composed of multiple lenses and - multipole stigmators with vendor-specific details which are often undisclosed. + The corrector in an electron microscope is composed of multiple lenses + and multipole stigmators with details specific for the technology partner + and microscope. Many of their technical details is proprietary knowledge. Was the corrector used? - - - Given name/alias. - - - - - - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. If this does not exist - a free-text field to report further details about the corrector. - - - + Specific information about the concrete alignment procedure which is a process during which the corrector is configured to enable a calibrated - usage of the microscope. + usage of the instrument. + + This :ref:`NXprocess` group should also be used when one describes in a computer + simulation the specific details about the modelled or assumed aberration + corrections. In effect, this base class can also be used for harmonizing + the description of such simulation details across different computer codes + to enable that a research data management system can find these information + in a common place - formatted in a normalized representation. + This reduces the necessity to include substantial case-dependent verification + code in the research data management system. - + - Discouraged free-text field to add further details about the alignment - procedure. + Discouraged free-text field to add further details about + the alignment procedure. - + - The outer tilt angle of the beam in tableau aquisition. + The outer tilt angle of the beam in tableau acquisition. + + TODO: The relevant axes which span the tilt_angle need a + cleaner description. + + + - + - The exposure time of the single tilt images. + The exposure time of single tilt images. + + + The factor of enlargement of the apparent size, - not physical size, of an object. + not the physical size, of an object. + + + + + + The images taken during the alignment procedure. + + Place for storing measured or estimated aberrations (for each image or final). @@ -89,7 +112,5 @@ NEW ISSUE: following parameters of the these constants and how they are useful-- - - + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml new file mode 100644 index 0000000000..4baccda138 --- /dev/null +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -0,0 +1,280 @@ + + + + + + + + + Number of reflectors (Miller crystallographic plane triplets). + + + + + Number of atom positions. + + + + + Dimensionality of the lattice. + + + + + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. + + + + Detail in which reference frame the unit cell is defined. + + + + + Dimensionality of the lattice. + + + + + + + + + + Reference to another resource that was used for + instantiating this structure model. + + + + + Crystallography unit cell parameters a, b, and c. + + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma. + + + + + + + + Area of the unit cell considering that d = 2. + + + + + Volume of the unit cell considering that d = 3. + + + + + Crystal system + + + + + + + + + + + + + + + Laue group using International Table of Crystallography Notation. + + + + + + Point group using International Table of Crystallography Notation. + + + + + + Space group from the International Table of Crystallography Notation. + + + + + + True if space group is considered a centrosymmetric one. + False if space group is considered a non-centrosymmetric one. + Centrosymmetric has all types and combinations of symmetry elements + (translation, rotational axis, mirror planes, center of inversion) + Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). + Chiral compared to non-centrosymmetric is constrained (no mirror planes). + + + + + True if space group is considered a chiral one. + False if space group is consider a non-chiral one. + + + + + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + + + + + + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + + + + + Label for each atom position. + + + + + + + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + + Atom positions. + + + + + + + + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + + + + + + + Relative occupancy of the atom position. + + + + + + + + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + + + + + + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + + + + + + + + + Spacing between crystallographic planes as defined by field miller. + + + + + + + + Relative intensity of the signal for the plane. + + + + + + + + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + + + + + + + diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/contributed_definitions/NXcs_computer.nxdl.xml index 4f05228e90..d9444aaff8 100644 --- a/contributed_definitions/NXcs_computer.nxdl.xml +++ b/contributed_definitions/NXcs_computer.nxdl.xml @@ -1,9 +1,9 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -30,18 +30,18 @@ Computer science description of a set of computing nodes. - + Given name/alias to the computing system, e.g. MyDesktop. - + Name of the operating system, e.g. Windows, Linux, Mac, Android. - Version plus build number, commit hash, or description of an ever + Version plus build number, commit hash, or description of an ever persistent resource where the source code of the program and build instructions can be found so that the program can be configured in such a manner that the result file is ideally recreatable yielding @@ -50,21 +50,21 @@ - + Ideally a (globally) unique persistent identifier of the computer, i.e. the Universally Unique Identifier (UUID) of the computing node. - + - A list of physical processing units (can be multi-core chips). + Details about (classical) processing units (CPUs) or a system thereof. - + - A list of physical coprocessor/graphic cards/accelerator units. + Details about coprocessor/graphic cards/accelerator units or a system thereof. diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml new file mode 100644 index 0000000000..6ce5370a30 --- /dev/null +++ b/contributed_definitions/NXcs_cpu_obj.nxdl.xml @@ -0,0 +1,39 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a (central) processing unit (C)PU of a computer. + + + + Given name of the CPU. Users should be as specific as possible. + + + + diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml new file mode 100644 index 0000000000..0de162c661 --- /dev/null +++ b/contributed_definitions/NXcs_cpu_sys.nxdl.xml @@ -0,0 +1,48 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a system of classical central processing units. + + For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. + + + + Granularizing at the socket level. + + Typical examples follow: A desktop computer with a single CPU one + could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of + :ref:`NXcs_cpu_sys`. + A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` + inside one instance of :ref:`NXcs_cpu_sys`. + A server with two dual-socket server nodes one could describe + with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. + + + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 0e1aec63c8..60033d7a6b 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -1,9 +1,9 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -45,37 +45,47 @@ Computer science base class for packing and unpacking booleans. - One use case is processing of object sets (like point cloud data). - When one applies e.g. a spatial filter to a set of points to define which - points are analyzed and which not, it is useful to document which points were - taken. One can store this information in a compact manner with an array of - boolean values. If the value is True the point is taken, else it is not. + This base class bookkeeps metadata to inform software about necessary modulo + operations to decode e.g. set membership of objects in sets which are encoded + as a packed array of boolean values. - If the points are identified by an array of integer identifiers and an - arbitrary spatial filtering, the boolean array will be filled with True and False - values in an arbitrary manner. Especially when the number of points is large, - for instance several thousands and more, some situations can be more efficiently - stored if one would not store the boolean array but just list the identifiers - of the points taken. For instance if within a set of 1000 points only one point is - taken, it would take (naively) 4000 bits to store the array but only 32 bits - to store e.g. the ID of that taken point. Of course the 4000 bit field is so - sparse that it could be compressed resulting also in a substantial reduction - of the storage demands. Therefore boolean masks are useful compact descriptions - to store information about set memberships in a compact manner. - In general it is true, though, that which representation is best, i.e. - most compact (especially when compressed) depends strongly on occupation of - the array. + One use case is processing of object sets (point cloud data). When one applies + e.g. a spatial filter to a set of points to define which points are analyzed + and which not, one can store this information in a compact manner using an array + of boolean values. If the value is True the point is taken, otherwise the point + is not taken. - This base class just bookkeeps metadata to inform software about necessary - modulo operations to decode the set membership of each object. This is useful - because the number of objects not necessarily is an integer multiple of the bit depth. + The resulting boolean array will be filled with True and False in a manner + that is often arbitrary and in general case-dependent. + + Especially when the number of points is large, for instance several thousands + or more, some situations can be more efficiently stored if one would not store + the boolean array but just list the identifiers of the points taken. + + For example, if within a set of 1000 points only one point is taken, it would + take (naively) 4000 bits to store the array but only 32 bits to store e.g. the + ID of the single point that is taken. Of course the 4000 bit field is so + sparse that it could be compressed resulting also in a substantial reduction + of the storage demands. Therefore, boolean masks are useful in that + they store compact representation of set memberships. + + The number of encoded pieces of information is not necessarily + an integer multiple of the bit depth. - + + + Possibility to refer to which set this mask applies. + + If depends_on is not provided, it is assumed that the mask + applies to its direct parent. + + + Number of objects represented by the mask. - + Number of bits assumed matching on a default datatype. (e.g. 8 bits for a C-style uint8). @@ -83,19 +93,19 @@ - The unsigned integer array representing the content of the mask. - If padding is used the padded bits have to be set to 0. + The content of the mask. If padding is used, padding bits have to be set to 0. - + Link to/or array of identifiers for the objects. The decoded mask is interpreted consecutively, i.e. the first bit in the mask matches to the first identifier, the second bit in the mask to the second - identifier and so on and so forth. + identifier and so on and so forth. Resolving of identifier follows + the conventions made for depends_on, so consult the also its description. diff --git a/contributed_definitions/NXcs_gpu_obj.nxdl.xml b/contributed_definitions/NXcs_gpu_obj.nxdl.xml new file mode 100644 index 0000000000..3c5b6c26ab --- /dev/null +++ b/contributed_definitions/NXcs_gpu_obj.nxdl.xml @@ -0,0 +1,39 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a graphic processing unit (GPU) of a computer. + + + + Given name of the GPU. Users should be as specific as possible. + + + + diff --git a/contributed_definitions/NXcs_gpu_sys.nxdl.xml b/contributed_definitions/NXcs_gpu_sys.nxdl.xml new file mode 100644 index 0000000000..217f1adb2f --- /dev/null +++ b/contributed_definitions/NXcs_gpu_sys.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a system of coprocessor or graphics processors. + + + + Granularizing at the socket level. + + Typical examples follow: A desktop computer with a single GPU one + could describe using one instance of :ref:`NXcs_gpu_obj` inside one instance of + :ref:`NXcs_gpu_sys`. + A desktop computer with two GPUs one could describe using two instances + of :ref:`NXcs_gpu_obj` inside one instance of :ref:`NXcs_gpu_sys`. + A GPU server like nowadays used for artificial intelligence + one could describe as a system with n instances of :ref:`NXcs_gpu_obj` + in one :ref:`NXcs_gpu_sys` or :ref:`NXcs_cpu_sys`. + + + diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml index 294e033ffc..a418c088fc 100644 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -1,9 +1,9 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -30,7 +30,7 @@ Computer science description of a storage object in an input/output system. - + Qualifier for the type of storage medium used. @@ -40,14 +40,13 @@ - - + Total amount of data which the medium can hold. - - + + Given name to the I/O unit. diff --git a/contributed_definitions/NXcs_io_sys.nxdl.xml b/contributed_definitions/NXcs_io_sys.nxdl.xml index 82bae62a9a..2b6f2fb3b4 100644 --- a/contributed_definitions/NXcs_io_sys.nxdl.xml +++ b/contributed_definitions/NXcs_io_sys.nxdl.xml @@ -1,9 +1,9 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -29,6 +29,10 @@ Computer science description of system of a computer. + + In the same way how a hierarchy of instances of :ref:`NXcs_cpu_obj` or :ref:`NXcs_gpu_obj` + can be defined one can also define a hierarchy of :ref:`NXcs_mm_obj` and :ref:`NXcs_io_obj` + instances. - + diff --git a/contributed_definitions/NXcs_mm_obj.nxdl.xml b/contributed_definitions/NXcs_mm_obj.nxdl.xml new file mode 100644 index 0000000000..e2b247079c --- /dev/null +++ b/contributed_definitions/NXcs_mm_obj.nxdl.xml @@ -0,0 +1,51 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Computer science description of a memory in a memory system. + + + + Qualifier for the type of random access memory. + + + + + + Total amount of data which the medium can hold. + + + + + + Given name to the I/O unit. + + + + diff --git a/contributed_definitions/NXcs_mm_sys.nxdl.xml b/contributed_definitions/NXcs_mm_sys.nxdl.xml index b06478a53a..69e66e7856 100644 --- a/contributed_definitions/NXcs_mm_sys.nxdl.xml +++ b/contributed_definitions/NXcs_mm_sys.nxdl.xml @@ -1,9 +1,9 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computer science description of a main memory system of a computer. + Computer science description of a memory system of a computer. + + In the same way how a hierarchy of instances of :ref:`NXcs_cpu_obj` or :ref:`NXcs_gpu_obj` + can be defined one can also define a hierarchy of :ref:`NXcs_mm_obj` and :ref:`NXcs_io_obj` + instances. - + How much physical memory does the system provide. - + diff --git a/contributed_definitions/NXcs_prng.nxdl.xml b/contributed_definitions/NXcs_prng.nxdl.xml index f288e15092..debbb10753 100644 --- a/contributed_definitions/NXcs_prng.nxdl.xml +++ b/contributed_definitions/NXcs_prng.nxdl.xml @@ -1,9 +1,9 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -30,21 +30,25 @@ Computer science description of pseudo-random number generator. - The purpose of such metadata is to identify if exactly the same sequence + The purpose of this base class is to identify if exactly the same sequence can be reproduced, like for a PRNG or not (for a true physically random source). - + + Physical approach or algorithm whereby random numbers are generated. + Different approaches for generating random numbers with a computer exists. - Some use a dedicated physical device where the state is unpredictable (physically). - Some use a mangling of the system clock (system_clock), where also without - additional pieces of information the sequence is not reproducible. - Some use so-called pseudo-random number generator (PRNG) are used. - These are algorithms which yield a deterministic sequence of practically - randomly appearing numbers. These algorithms different in their quality in - how close the resulting sequences are random. - Nowadays one of the most commonly used algorithm is - the MersenneTwister (mt19937). + Some use a dedicated physical device whose the state is unpredictable + (physically). Some use a strategy of mangling information from the system + clock. Also in this case the sequence is not reproducible without having + additional pieces of information. + + In most cases though so-called pseudo-random number generator (PRNG) + algorithms are used. These yield a deterministic sequence of practically + randomly appearing numbers. These algorithms differ in their quality in + how close the resulting sequences are random, i.e. sequentially + uncorrelated. Nowadays one of the most commonly used algorithm is the + MersenneTwister (mt19937). @@ -53,30 +57,24 @@ - + Name of the PRNG implementation and version. If such information is not available or if the PRNG type was set to other the DOI to the publication or the source code should be given. - - - Version and build number, or commit hash. - - - - + + - Parameter of the PRNG controlling its initialization and thus the specific - sequence of numbers it generates. + Parameter of the PRNG controlling its initialization + and thus controlling the specific sequence generated. - - + - Number of initial draws from the PRNG which are discarded in an effort - to equilibrate the sequence and make it thus to statistically more random. - If no warmup was performed or if warmup procedures are unclear, + Number of initial draws from the PRNG after its initialized with the seed. + These initial draws are typically discarded in an effort to equilibrate the + sequence. If no warmup was performed or if warmup procedures are unclear, users should set the value to zero. diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/contributed_definitions/NXcs_profiling.nxdl.xml index 9e1e7798c6..ef2b03b3ce 100644 --- a/contributed_definitions/NXcs_profiling.nxdl.xml +++ b/contributed_definitions/NXcs_profiling.nxdl.xml @@ -1,9 +1,9 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. - Computer science description for summary performance/profiling data of an application. + Computer science description for performance and profiling data of an application. Performance monitoring and benchmarking of software is a task where questions can be asked at various levels of detail. In general, there are three main @@ -38,28 +38,29 @@ * Software configuration and capabilities * Dynamic effects of the system in operation and the system working together with eventually multiple computers, especially when these have to exchange - information across a network. + information across a network and these are used usually by multiple users. At the most basic level users may wish to document how long e.g. a data - analysis with a scientific software (app). - A frequent idea is here to judge how critical the effect is on the workflow - of the scientists, i.e. is the analysis possible in a few seconds or would it - take days if I were to run this analysis on a comparable machine. In this case, - mainly the order of magnitude is relevant, as well as how this can be achieved - with using parallelization (i.e. reporting the number of CPU and GPU resources - used, the number of processes and/or threads, and basic details about the - computing node/computer. + analysis with a scientific software (app) took. + A frequent idea is here to answer practical questions like how critical is the + effect on the workflow of the scientists, i.e. is the analysis possible in + a few seconds or would it take days if I were to run this analysis on a + comparable machine? + For this more qualitative performance monitoring, mainly the order of + magnitude is relevant, as well as how this was achieved using parallelization + (i.e. reporting the number of CPU and GPU resources used, the number of + processes and threads configured, and providing basic details about the computer). At more advanced levels benchmarks may go as deep as detailed temporal tracking of individual processor instructions, their relation to other instructions, the - state of call stacks, in short eventually the entire app execution history + state of call stacks; in short eventually the entire app execution history and hardware state history. Such analyses are mainly used for performance - optimization as well as for tracking bugs and other development purposes. - Specialized software exists which documents such performance data in - specifically-formatted event log files or databases. + optimization, i.e. by software and hardware developers as well as for + tracking bugs. Specialized software exists which documents such performance + data in specifically-formatted event log files or databases. - This base class cannot and should not replace these specific solutions. - Instead, the intention of the base class is to serve scientists at the + This base class cannot and should not replace these specific solutions for now. + Instead, the intention of the base class is to serve scientists at the basic level to enable simple monitoring of performance data and log profiling data of key algorithmic steps or parts of computational workflows, so that these pieces of information can guide users which order of magnitude differences @@ -70,12 +71,12 @@ the metadata in this base class. - + Path to the directory from which the tool was called. - + Command line call with arguments if applicable. @@ -97,15 +98,15 @@ Wall-clock time how long the app execution took. This may be in principle end_time minus start_time; however usage of eventually more precise timers may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. + and thus demands a more precise record of the wall-clock time. - + - Qualifier which specifies with how many nominal processes the app was - invoked. The main idea behind this field, for instance for app using a - Message Passing Interface parallelization is to communicate how many - processes were used. + Qualifier which specifies with how many nominal processes the app was + invoked. The main idea behind this field e.g. for apps which use e.g. MPI + (Message Passing Interface) parallelization is to communicate + how many processes were used. For sequentially running apps number_of_processes and number_of_threads is 1. If the app uses exclusively GPU parallelization number_of_gpus @@ -114,14 +115,14 @@ used though. - + - Qualifier with how many nominal threads were accessible to the app at - runtime. Specifically here the maximum number of threads used for the + Qualifier how many nominal threads were used at runtime. + Specifically here the maximum number of threads used for the high-level threading library used (e.g. OMP_NUM_THREADS), posix. - + Qualifier with how many nominal GPUs the app was invoked at runtime. @@ -129,8 +130,7 @@ +complicated models should be captured.--> A collection with one or more computing nodes each with own resources. diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 02c06b97d1..90f3f59080 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -1,9 +1,9 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -47,31 +47,34 @@ included when the event tracking ended. - + Free-text description what was monitored/executed during the event. - Wall-clock time how long the event took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. + Wall-clock time how long the event took. + + This may be in principle end_time minus start_time; however usage of + eventually more precise timers may warrant to use a finer temporal + discretization, and thus demand for a more precise record of the + wall-clock time. + Elapsed time may contain time portions where resources were idling. - + Number of processes used (max) during the execution of this event. - + Number of threads used (max) during the execution of this event. - + Number of GPUs used (max) during the execution of this event. diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/contributed_definitions/NXdeflector.nxdl.xml index f1774a1ba5..d8ec4bc959 100644 --- a/contributed_definitions/NXdeflector.nxdl.xml +++ b/contributed_definitions/NXdeflector.nxdl.xml @@ -1,9 +1,9 @@ - + - + Deflectors as they are used e.g. in an electron analyser. - + - Qualitative type of deflector with respect to the number of pole pieces + Qualitative type of deflector with respect to the number of pole pieces. @@ -36,33 +36,23 @@ - + Colloquial or short name for the deflector. For manufacturer names and identifiers use respective manufacturer fields. - + + - Name of the manufacturer who built/constructed the deflector. - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the deflector. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the deflector. + Ideally an identifier, persistent link, or free text which gives + further details about the deflector. - Excitation voltage of the deflector. For dipoles it is a single number. For - higher orders, it is an array. + Excitation voltage of the deflector. For dipoles it is a single number. + For higher order multipoles, it is an array. @@ -71,17 +61,18 @@ higher orders, it is an array. - + Specifies the position of the deflector by pointing to the last transformation in the transformation chain in the NXtransformations group. - + + Collection of axis-based translations and rotations to describe the location and geometry of the deflector as a component in the instrument. Conventions from the - NXtransformations base class are used. In principle, the McStas coordinate + :ref:`NXtransformations` base class are used. In principle, the McStas coordinate system is used. The first transformation has to point either to another component of the system or . (for pointing to the reference frame) to relate it relative to the experimental setup. Typically, the components of a system should diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml index 3ac4b15ae9..18b77feef8 100644 --- a/contributed_definitions/NXebeam_column.nxdl.xml +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -1,9 +1,9 @@ - + - - + + + - Container for components to form a controlled beam in electron microscopy. + Base class for a set of components providing a controllable electron beam. + The source which creates the electron beam. - + Given name/alias. - + Voltage relevant to compute the energy of the electrons immediately after they left the gun. - + Type of radiation. @@ -52,7 +57,7 @@ - + Emitter type used to create the beam. @@ -66,13 +71,13 @@ - + Material of which the emitter is build, e.g. the filament material. - - + + Ideally, a (globally) unique persistent identifier, link, or text to a resource which gives further details. @@ -82,27 +87,22 @@ relevant from maintenance point of view--> - Affine transformation which detail the arrangement in the - microscope relative to the optical axis and beam path. + Collection of axis-based translations and rotations to describe the + location and geometry of the component in the instrument. - - - - - A sensor used to monitor an external or internal condition. - - + + - Individual ocharacterization results for the position, shape, + Individual characterization results for the position, shape, and characteristics of the electron beam. - NXtransformations should be used to specify the location + :ref:`NXtransformations` should be used to specify the location of the position at which the beam was probed. diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 5b2eceb134..317d5e44a5 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -1,9 +1,9 @@ - + - - + - Characterization of a sample during a session on an electron microscope. - - **The idea and aim of NXem**: - Electron microscopy (EM) research, whether it be performed with scanning electron - microscope (SEM) or transmission electron microscope (TEM) instruments, uses - versatile tools for preparing and characterizing samples and specimens. - The term specimen is considered a synonym for sample in this application definition. - A specimen is a physical portion of material that is studied/characterized during - the microscope session, eventually in different places on the specimen surface, - illuminating the surface layers or shining through thin specimens. - These places are named regions of interest (ROIs). - - Fundamentally, an electron microscope is an electron accelerator. - Experimentalists use it in sessions during which they characterize as well as - prepare specimens. This application definition describes data and metadata about - processes and characterization tasks applied to one specimen. - The application definition focuses on the usage of EM in materials research. - The application definition design makes it in principle applicable also in - cryo-EM on biomaterials. - - Multiple specimens have to be described with multiple :ref:`NXentry` instances. - - **Electron microscopes motivate the development of an embracing data schema:** - There are research groups who use an EM in a manner where it is exclusively - operated by a single, instrument-responsible scientists or a team of scientists. - These users may perform analyses for other users as a service task, especially - in large research facility settings. Oftentimes, though, and especially for - cutting-edge instruments, the scientists guide the process maybe even control - the microscope. Instruments are usually controlled on-premises but also more - and more functionalities for remote control have become available. - Scientists oftentimes can ask technicians for support. In all cases, - these people are considered users. Users might have different - roles though. - - The rational behind a common EM schema rather than making separate schemas - for SEM or TEM are primarily the key similarities of SEM and TEM - instruments: - - Both type of instruments have electro-magnetic lenses. These may differ in - design, alignment, number, and level of corrected for aberrations. - As an obvious difference, a TEM is mainly used for measuring the transmitted - electron beam. This calls for using a different lens setup and relative - placement of the specimen in the lens setup. Also TEM specimens are - substantially thinner than specimens characterized with SEM to enable an - illumination through the specimen. This offers capabilities for probing of - additional physical mechanisms of electron-matter interaction which are - unavailable in SEMs. - - Nevertheless, both types of electron microscopes use detector systems which - measure different types of signals that originate from the same set of - radiation/specimen interactions. Often these detectors have a similar design - and technology or are even used both in SEMs and TEMs. - - **An embracing schema instead of specific SEM or TEM schemas**: - Given these physical and technical differences, different instruments have - been developed. This led to a coexistence of two broad interacting - communities: SEM and TEM users. From a data science perspective, we - acknowledge that the more specific a research question is and the narrower it - is the addressed circle of users which develops or uses schemas for research - data management (RDM) with EM, the more understandable it is that scientists - of either community (or sub-community) ask for designing method-specific schemas. - - Researchers who have a single (main) microscope of some vendor in their lab, - may argue they need an NXem_vendor_name schema or an NXem_microscope_name or - an NXem_sem or a NXem_tem schema. - Scientists exclusively working with one technique or type of signal probed - (X-rays, electrons) may argue they wish to be pragmatic and store only - what is immediately relevant for their particular technique and - research questions. In effect, they may advocate for method-specific - schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. - - However, the history of electron microscopy has shown that these activities led - to a zoo of schemas and especially vocabulary in use with implementations of these - into many data and file formats. There is nothing which prevents the communities - to make these schemas open and interoperable. Open here means not that all - data stored according to such schemas have to end up in the open-source domain. - There can be embargo periods first of all. - - Open means that the metadata and associated schemata are documented in a manner - that as many details are open as possible in the sense that others can understand - what the (meta)data mean conceptually. Instead of trying of maintain a zoo - of eventually difficult to make interoperable formats and schema we would like - to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ - should guide all decisions how data and metadata should be stored. - - EM instruments, software, and research are moving targets. Consequently, - there is a key challenge and inconvenience with having many different schemas - with associated representations of data and metadata: Each combination of - schemas or an interoperable-made handshake between two file formats or software - packages has to be maintained by software developers. This counts especially - when data should be processed interoperably between software packages. - - This brings two problems: Many software tools and parsers for the handshaking - between tools have to be maintained. This can result in usage of different - terminology, which in turn results in representations and connections made - between different data representations and workflows that are not - machine-actionable. - `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ - - **The advantage of working towards a common vocabulary and representation**: - A common vocabulary can serve interoperability as developers of schemas and - scientists can reuse for instance these terms, thus supporting interoperability. - Ideally, scientists specialize an application definition only for the few very - specific additional quantities of their instruments and techniques. This is - better than reimplementing the wheel for descriptions of EM instruments. - This route of more standardization can support the EM community in that it - removes the necessity for having to maintain a very large number of schemas. - - Aiming for more standardization, i.e. a lower number of schemas rather than - a single standard for electron microscopy is a compromise that can serve - academia and industry as it enables a focusing of software development - efforts on those schemas, on fixing and discussing them, and on harmonizing - their common vocabulary. These activities can be specifically relevant also - for technology partners building EM hard- and software as it improves the - longevity of certain schemas; and thus can help with incentivizing them to support - the community with implementing support for such schemas into their applications. - - In effect, everybody can gain from this as it will likely reduce the cases - in which scientists have to fix bugs in making their own tools compliant and - interoperable with tools of their colleagues and the wider community. - - The here proposed NXem application definition offers modular components - (EM-research specific base classes) for defining schemas for EM research. - Thereby, NXem can be useful to extends top-level ontologies towards a domain- - and method-specific ontology for electron microscopy as it is used for - materials research. - - Working towards a common vocabulary is a community activity that profits from - everybody reflecting in detail whether certain terms they have used in the past - are not eventually conceptually similar if not the same as what this application - definition and its base classes provide. We are happy for receiving your feedback. - - **Addressing the generality versus specificity challenge**: - It is noteworthy to understand that (not only for NeXus), schemas differ - already if at least one field is required in one version of the schema, - but it is set optional in another schema. If group(s), field(s), or - attributes are removed or added, or even a docstring is changed, schemas can - become inconsistent. It is noteworthy to mention that the idea of a NeXus application - definition serves as a contract between a data provider and a data consumer. - Providers can be the software of a specific microscopes or users with specific - analysis needs. Consumers can be again specific software tools, like vendor - software for controlling the instrument or a scientific software for doing - artificial intelligence analyses on EM data). Such changes of a schema lead - to new versions. Strictly speaking an application definition can only be - fully general if it does not make a single entry required, in which case however - it would also not offer much value as even empty datasets would be compliant - with such a schema. - - **Verification of constraints and conditions**: - Tools like NeXus so far do not avoid or protect against all such possible - inconsistencies; however NeXus offers a mechanism and toolset, through which - schemas can be documented and defined. In effect, having an openly documented - (at a case-specific level of technical detail) schema is a necessary but alone - not a sufficient step to take EM research on a route of machine-actionable - and interoperable FAIR data. - - This stresses again the fundamental and necessary role of working towards - a common vocabulary and, with a longer perspective in mind, a machine-actionable - knowledge representation and verification engine. So far many conditions and - requirements are formulated in the docstrings of the respective entries of - the application definition. - - **NXem takes a key step towards standardization of EM data schemas**. - It offers a controlled vocabulary and set of relations between concepts and - enables the description of the data which are collected for research with - electron microscopes. To be most efficient and offering reusability, the NXem - application definition should be understood as a template that one should - ideally use as is. NXem can be considered a base for designing more specialized - definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). - - **The use of NXem should be as follows:** - Offspring application definitions should not remove groups but leave these - optional or, even better, propose changes to NXem. - - A particular challenge with electron microscopes as physical instruments are - their dynamics. To make EM data understandable, repeatable, and eventually - corresponding experiments reproducible in general requires a documentation - of the spatio-temporal dynamics of the instrument in its environment. - It is questionable to which level such a reproducibility is possible with EM - at all considering beam damage, effects of the environment, and other not - exactly quantifiable influences. - While this points to the physical limitations there are also practical and - economical constraints on how completely EM research can be documented: - For most commercial systems there is a specific accessibility beyond which - detailed settings like lens excitations and low-level hardware settings - may not be retrievable as technology partners have a substantiated interest in - finding a compromise between being open to their users and securing their - business models. - - By design, EM experiments illuminate the specimen with electrons as a - consequence of which the specimen changes if not may get destroyed. - As such, repeatability of numerical processing and clear descriptions of - procedures and system setups should be addressed first. - - If especially a certain simulation package needs a detailed view of the - geometry of the lens system and its excitations during the course of the - experiment, it is difficult to fully abstract the technical details of the - hardware into a set of names for fields and groups that make for a compromise - between clarity but being system-agnostic at the same time. - Settings of apertures are an example where aperture modes are in most cases - aliases behind which there is a set of very detailed settings specific to the - software and control units used. These settings are difficult to retrieve, - are not fully documented by technology partners. This simplification for - users of microscopes makes experiments easier understandable. - On the flipside these subtilities limit the opportunities of especially open- - source developments to make data schemas covering enough for general usage and - specific enough and sufficiently detailed to remain useful for - research by electron microscopy domain experts. - - Instead, currently it is for the docstring to specify what is conceptually - eventually behind such aliases. The design rule we followed while drafting - this NXem application definition and base classes is that there are numerous - (technical) details about an EM which may warrant a very detailed technical - disentangling of settings and reflection of numerous settings as deeply - nested groups, fields and attributes. An application definition can offer a - place to hold these nested representations; however as discussed - at the cost of generality. - - Which specific details matter for answering scientific research questions is - a difficult question to answer by a single team of scientists, especially - if the application definition is to speak for a number of vendors. What makes - it especially challenging is when the application definition is expected to - hold all data that might be of relevance for future questions. - - We are skeptical if there is one such representation that can fulfill all these - aims and interest, while remaining at the same time approachable and executable - by a large number of scientists in a community. However, we are also convinced - that this is not a reason to accept the status quo of having a very large set - of oftentimes strongly overlapping and redundant schemas. - - NXem is our proposal to motivate the EM community to work towards more - standardization and discussion of what constitutes data, i.e. metadata, - numerical and categorical data in research with electron microscopes. We found - that existent terminology can be encoded into a more controlled vocabulary. - - We have concluded that despite all these details of current EM research with - SEM, TEM, and focused-ion beam instruments, there a clearly identifiable - common components and generalizable settings of EM research use cases. - Therefore, - - **This application definition has the following components at the top-level:** - - * Generic experimental details (time-zone-aware timestamp, identifiers, name); - conceptually these are session details. A session at a microscope may - involve the characterization of multiple specimens. For each specimen - an instance of an (NXentry) is created. Details of the instrument have to - be stored at least in an entry. Other entries should refer to these - metadata via links to reduce redundancies. - * Each signal, such as a spectrum or image taken at the microscope, should - have an associated time-zone-aware time stamp and report of the specific - settings of the microscope at that point in time when the image was taken. - This is why instances of :ref:`NXevent_data_em` have an own em_lab section. - The reason is that EMs can be highly dynamic, be used to illuminate the specimen - differently or show drift during signal acquisition, to name but a few effects. - What constitutes a single EM experiment/measurement? - This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), - taking of a secondary electron image for fracture analysis, taking a set of - EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a - specimen in preparation for e.g. an atom probe experiment. - * :ref:`NXmonitor`; - instances to keep track of time-dependent quantities - pertaining to specific components of the instrument. - Alternatively, NXevent_data_em instances can be used to store - time-zone-aware dates of the components, which is - relevant for documenting as exactly as practically possible settings - when images and spectra were taken. - * :ref:`NXinstrument`; - conceptually this is a container to store arbitrary level of detail of the - technical components of the microscope as a device and the lab in which - the microscope is operated. - * :ref:`NXuser`; - conceptually, this is a set with at least one NXuser instance which details - who operated or performed the measurement. Additional NXusers can be - referred to in an NXevent_data_em instance to store - individualized details who executed an event of data acquisition or processing. - * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; - each NXevent_data_em instance is a container to group specific details - about the state of the microscope when a measurement was taken and - relevant data and eventual processing steps were taken (on-the-fly). - * :ref:`NXdata`; at the top-level, conceptually, this is a place for documenting - available default plottable data. A default plottable can be useful for - research data management systems to show a visual representation of some - aspect of the content of the EM session. - Default plottables not intended to serve every possible analysis and - visualization demand but be a preview. We made this choice because what - constitutes a useful default plot is often a matter of interpretation, - somewhat of personal taste, and community standards. In effect, default - plottables are case- and method-specific. - - Usually a session at a microscope is used to collect multiple signals. - Examples for possible default plottables could be arbitrarily taken secondary, - back-scattered, electron image, diffraction pattern, EELS spectra, composition, - or orientation mappings to name but a few. - - **There are a few design choices to consider with sub-ordinate groups:** - - * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` - instances to hold data at the earliest possible step in the computational - processing (which is usually performed with the microscope control and or - integrated analysis software). The formatting of the NXdata groups enables to - display image and spectra with web technology visualization software. - NeXus specifies only the data model, i.e. the terms and their relations. - These descriptions can be implemented and stored in JSON, HDF5, XML, or HSDS, - file storage, or even other formats, although HDF5 is often used. - * When two- and three-dimensional geometric primitive data are stored, it is useful - to write additional optional XDMF fields which support additional plotting of - the data with visualization software like Paraview or Blender. - * Consumable results of EM characterization tasks are usually a sub-set of - data artifacts, as there is not an infinite amount of possible - electron/ion beam-specimen interactions. - * Images of electron counts detected in specific operation modes (bright - field, dark field in TEM, secondary/back-scattered, Kikuchi). - * Spectra (X-ray quanta or Auger electron counts) - * These data are in virtually all cases a result of some numerical processing. - These data and processing steps are modelled as instances of :ref:`NXprocess` - which use terms from a controlled vocabulary e.g. SE (secondary electron), - BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). - - **A key question often asked with EM experiments is how the actual (meta)data - should be stored (in memory or on disk)**. To this end the schema here makes no - specific assumptions, not even that all the fields/group of a schema instance - have to be stored at all into a single file. Instead, the schema specifies the - relations between metadata, some of the constraints and conditions on how the - data should be formatted, what the data conceptually represent, and which terms - (controlled vocabulary) is practical to store to index specific quantities. - - In effect, the application definition is a graph which describes how - numerical data and (meta)data for EM research are related to one another. - - Electron microscopy experiments are usually controlled/performed via - commercial integrated acquisition and instrument control software. - In many cases, an EM dataset is useful only if it gets post-processed - already during the acquisition, i.e. while the scientist is sitting - at the microscope. - Many of these processes are automated, while some demand GUI - interactions with the control software. Examples include collecting - of diffraction pattern and on-the-fly indexing of these. - - It is possible that different types of programs might be used to - perform these processing steps whether on-the-fly or not. If this is - the case the processing should be structured with individual :ref:`NXprocess` - instances. If the program and/or version used for processing referred - to in an NXprocess group is different to the program and version - mentioned in this field, the NXprocess needs - to hold an own program and version. + Application definition for normalized representation of electron microscopy research. + + In line with the idea of NeXus application definitions, this schema is a + specialized version of NXem_base in that fields and groups are specifically + constrained. This has the effect that some quantities are required, so + that a research data management system (RDMS) can rely on the existence of + these pieces of information without demanding that RDMS to implement further + verification in its own source code or further harmonization or normalization + what each piece of information means conceptually. + + This application definition is thus an example of a general description + with which to normalize specific pieces of information and data collected + within electron microscopy research. + + This application definition is also a blueprint which shows how users + can build specific application definitions by reusing - instead of completely + reimplementing the wheel from scratch - em-specific base classes - and thus + represent electron-microscopy-specific content. + + The constraints of all these application definitions might be different + than for the here exemplified application definition NXem. + + Nevertheless, the key benefit remains: Many pieces of information are still + conceptually the same, named in the same way and found in the same place + in the hierarchy. This supports interoperability of electron microscopy data + and is advantageous compared to having everybody using own formatting and + conceptually not harmonized terms for describing their electron microscopy + research. + + For the detailed rationale and explanation of the concept behind the + NeXus electron microscopy class definitions please consult the preamble + of the NXem_base base class. + + + + + + + + + + + + A collection of all programs and libraries which are considered relevant + to understand with which software tools this NeXus file instance was + generated. Ideally, to enable a binary recreation from the input data. + + Examples include the name and version of the libraries used to write the + instance. Ideally, the software which writes these NXprogram instances + also includes the version of the set of NeXus classes i.e. the specific + set of base classes, application definitions, and contributed definitions + with which the here described concepts can be resolved. + + For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ + which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ + research data management system, it makes sense to store e.g. the GitHub + repository commit and respective submodule references used. + + + + + + The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) + which was used to generate this NeXus file instance. + + + - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - + + - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - The identifier is usually defined/issued by the facility, - laboratory, or the principle investigator. - The identifier enables to link experiments to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of this - application definition rather than write details about the experiment - into this free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval by specifying both - a start_time and an end_time to allow for more detailed bookkeeping and - interpretation of the experiment. The user should be aware that even - with having both time instances specified, it may not be possible - to infer how long the experiment took or for how long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps in NXevent_data_em instances to - provide additional pieces of information. - - - + + + + + + - ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. + Either an identifier or an alias that is human-friendly so that + scientist find that experiment again + + + + - - + + - - - Binary container for a file or a compressed collection of files which - can be used to add further descriptions and details to the experiment. - The container can hold a compressed archive. - - - - - A small image that is representative of the entry; this can be an - image taken from the dataset like a thumbnail of a spectrum. - A 640 x 480 pixel jpeg image is recommended. - Adding a scale bar to that image is recommended but not required - as the main purpose of the thumbnail is to provide e.g. thumbnail - images for displaying them in data repositories. - - + + + + + + - - Contact information and eventually details of at least one person - involved in the taking of the microscope session. This can be the - principle investigator who performed this experiment. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service - should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - + + + + + + + - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally (globally) unique persistent identifier. The name distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias of the sample. - Instead, use short_title for this, more convenient alias name. - - In cases where multiple specimens have been loaded into the microscope - the name has to identify the specific one, whose results are stored - by this NXentry, because a single NXentry should be used only for - the characterization of a single specimen. - - Details about the specimen preparation should be stored in the - sample history. - - - - - Ideally, a reference to a (globally) unique persistent identifier, - representing a data artifact which documents ideally as many details - of the material, its microstructure, and its thermo-chemo-mechanical - processing/preparation history as possible. - - The sample_history is the record what happened before the specimen - was placed into the microscope at the beginning of the session. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider are - the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing state, - and the details of the preparation. - - Specific details about eventual physically-connected material like - embedding resin should be documented ideally also in the sample_history. - If all fails, the description field can be used but it is strongly - discouraged because it leads to eventually non-machine-actionable - data. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this should - be a part of the sample history, i.e. the sample is imagined handed over - for analysis. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments - including tracers with a short half time. Further time stamps prior - to preparation_date should better be placed in resources which - describe the sample_history. - - - - - Possibility to give an abbreviation or alias of the specimen name field. - - - - - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer materials database systems an - opportunity to parse the relevant elements without having to interpret - these from the sample history. - - - - - - (Measured) sample thickness. The information is recorded to qualify - if the beam used was likely able to shine through the specimen. - For scanning electron microscopy, in many cases the specimen is much - thicker than what is illuminatable by the electron beam. - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - - - - - - (Measured) density of the specimen. For multi-layered specimens this - field should only be used to describe the density of the excited - volume. For scanning electron microscopy the usage of this field is - discouraged and instead an instance of an :ref:`NXinteraction_vol_em` - within individual :ref:`NXevent_data_em` instances can provide a much - better description of the relevant details why one may wish to store - the density of the specimen. - - - - - - Discouraged free-text field in case properly designed records - for the sample_history are not available. - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - + + + + + + + + + + + + + + - - - - - - - Metadata and numerical data of the microscope and the lab in which it stands. - - The em_lab section contains a description of the instrument and its components. - The component descriptions in this section differ from those inside individual - NXevent_data_em sections. These event instances take the role of time snapshot. - For an NXevent_data_em instance users should store only those settings for a - component which are relevant to understand the current state of the component. - Here, current means at the point in time, i.e. the time interval, - which the event represents. - - For example it is not relevant to store in each event's electron_source - group again the details of the gun type and manufacturer but only the - high-voltage if for that event the high-voltage was different. If for all - events the high-voltage was the same it is not even necessary to include - an electron_source section in the event. - - Individual sections of specific type should have the following names: - - * NXaperture: the name should match with the name of the lens - * NXlens_em: condenser_lens, objective_lens are commonly used names - * NXcorrector_cs: device for correcting spherical aberrations - * NXstage_lab: a collection of component for holding the specimen and - eventual additional component for applying external stimuli on the sample - * NXdetector: several possible names like secondary_electron, - backscattered_electron, direct_electron, ebsd, edx, wds, auger, - cathodoluminescence, camera, ronchigram - - - - Given name of the microscope at the hosting institution. This is an alias. - Examples could be NionHermes, Titan, JEOL, Gemini, etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - + + + + + + + + + + - - - - - - + + + + + + + + + - - - - - - - + + + + - - - - - - - - - - - - - + + + + - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Description of the type of the detector. - - Electron microscopes have typically multiple detectors. - Different technologies are in use like CCD, scintillator, - direct electron, CMOS, or image plate to name but a few. - - - - Instrument-specific alias/name - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A container for storing a set of NXevent_data_em instances. - - An event is a time interval during which the microscope was configured - in a specific way. The microscope is considered as stable enough during - this interval that a measurement with one or multiple detectors is - possible. What constitutes such time interval depends on how the - microscope is used and which measurements the user would like to perform. - - Each NXevent_data_em instance holds one acquisition task with detectors. - Each NXevent_data_em section contains an em_lab group in which specific - settings and states of the microscope during the time interval - can be stored to document the history of states of the microscope over - the course of the session. - - The NXem application definition offers maximal flexibility. - One extreme could be that the only one NXevent_data_em instance is used - and this covers the time interval of the entire session at the microscope. - The other extreme case is that each collection of an image or even - single spot measurement is defined as an NXevent_data_em instance. - In this case the em_lab group inside the NXevent_data_em also holds - the specific time-dependent state of the microscope with which in theory - all dynamics of the system (if measured) can be captured and documented. - - Nowadays microscopes exists for which hard- and software solutions - enable a tracking of the dynamics of the microscope and the actions - of the user (such as with solution like AXONSynchronicity from Protochips). - The NXem application definition can however also be used for less - complex interaction and lower demands wrt to time tracking activities. - - An NXevent_data_em instance holds specific details about how raw data from - a detector were processed. Raw data may already be post-processed as - they are accessible only by the control software with after some internal - processing happened. Nevertheless, these data have to be distinguished from - post-processed data where e.g. raw data are converted to interpreted - spectra, or orientation mappings. - - This post-processing tasks can be performed (on-the-fly, i.e. during - acquisition for sure during the microscope session) or afterwards. - Post-processing is performed with commercial software or various - types and scripts. - - Currently, several specializations of NXimage_set and Nspectrum_set - are used which store some details of this processing. However, as post- - processing tasks can be substantially more advanced and involved it - is clear that data artifacts from the measurement and data artifacts - generated during post-processing are weakly connected only, maybe - exclusively by the fact that a complex numerical post-processing workflow - just takes one raw dataset from an NXevent_data_em instance but generates - multiple derived data artifacts from this. All these should be described - as own application definitions and only weak connections should be made - to an instance of NXem. Instances of NXsubentry is one mechanism in - NeXus how this can be achieved in the future. - - - - A container holding a specific result of the measurement and - eventually metadata how that result was obtained numerically. - - NXevent_data_em instances can hold several specific NXimage_em or - NXspectrum_em instances taken and considered as one event, i.e. - a point in time when the microscope had the settings specified - either in NXinstrument or in this NXevent_data_em instance. - - The application definition is designed without an explicit need for - having an NXevent_data_em instance that contains an NXimage_em or - NXspectra_em instance. Thereby, an NXevent_data_em can also be used - for just documentation about the specific state of the microscope - irrespective whether data have been collected during this time interval. - - In other words the NXinstrument group details primarily the more - static settings and components of the microscope as they are found - by the operator during the session. The NXevent_data_em samples - the dynamics. - - It is not necessary to store data in NXebeam, NXibeam instances - of NXevent_data_em but in this case it is assumed that the settings - were constant over the entire course of the microscope session - and thus all relevant metadata inside the NXinstrument groups - are sufficient to understand the session. - - So far there exists no standard which a majority of the technology - partners and the materials science electron microscopy community - have accepted which could be used for a very generic documentation, - storage and exchange of electron microscope data. Therefore, it is - still a frequent case that specific files have many fields which cannot - safely be mapped or interpreted. - **Therefore, users are always given the advice to keep the vendor files.** - Working however with these vendor files inside specific software, - like materials databases, demands for parsers which extract pieces of - information from the vendor representation (numerical data and metadata) - and map them on a schema with which the database and its associated - software tools can work with. - - Currently, one would loose immediately track of e.g. provenance and - the origin of certain data in NXevent_data_em instances unless really - all data are safely and reliably copied over into an instance of the - schema. Currently, though, this is sadly effectively prevented in many - cases as vendors indeed implemented often sophisticated provenance - and commercial software state tracking tools but these are not yet - documented covering enough in our opinion so that it is safe to assume - all vendor field names are known, logically understood, interpretable, - and thus mappable on a common schema using a controlled common - vocabulary. - - Therefore we encourage user for now to store for each NXimage_set - or NXspectra_set instance to supply the so-called source of the data. - This can for instance be the name and hashvalue of the original - file which was acquired during the microscope session and from which then - certain details like numerical data and metadata were copied into an - instance of this schema for the purpose of working with the data in - e.g. tools offered by research data management (RDM) systems or - materials database. - - During our work on implementing file format/metadata parsers and - developing this application definition, we realized that **several - software tools currently do not consistently format critical metadata - like time-zone-aware timestamps** when events of data collection or - processing happened. - - We would like to encourage the community and especially the vendors - to work towards a standardization, or at least an open documentation - of the way how time-zone-aware time data are collected and stored how - and where during a microscope session and how they end up in files - and databases with which users interact. - This would enable to supplement instances of this schema with specific - time data and assure that these time data can be used to reliably - contextualize individual datasets and processing steps in materials - information systems. - - For the reason that these measures have not yet been fully taken, - the start_time and end_time is a recommended option. - The idea behind these time-zone-aware dates is to identify when - the data were collected at the microscope but NOT when they were - transcoded by some software tool(s) while storing the data in an - instance of this schema. - - - - - - - - - - - - - - - - + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + - - - - - Annulus inner half angle - - - - - Annulus outer half angle - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + - - - - + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + - - - - - - - + + + + - - - - - - - - - + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + A region-of-interest analyzed either during or after the session. + For which specific processed data of the measured or simulated + data are available. + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_adf.nxdl.xml new file mode 100644 index 0000000000..64534699cd --- /dev/null +++ b/contributed_definitions/NXem_adf.nxdl.xml @@ -0,0 +1,65 @@ + + + + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Base class method-specific for annular dark field imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). Examples can be single point aka spot + measurements, line profiles, or (rectangular) surface mappings. + The latter pattern is the most frequently used. + + For now the base class provides for scans for which the settings, + binning, and energy resolution is the same for each scan point. + + + + + Annulus inner (first value) and outer (second value) half angle. + + + + + + + + diff --git a/contributed_definitions/NXem_base.nxdl.xml b/contributed_definitions/NXem_base.nxdl.xml new file mode 100644 index 0000000000..479819893b --- /dev/null +++ b/contributed_definitions/NXem_base.nxdl.xml @@ -0,0 +1,389 @@ + + + + + + + + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. + + + + A collection of all programs and libraries which are considered relevant + to understand with which software tools this NeXus file instance was + generated. Ideally, to enable a binary recreation from the input data. + + Examples include the name and version of the libraries used to write the + instance. Ideally, the software that writes these :ref:`NXprogram` instances + also includes the version of the set of NeXus classes i.e. the specific + set of base classes, application definitions, and contributed definitions + with which the here described concepts can be resolved. + + For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ + which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ + research data management system, it makes sense to store e.g. the GitHub + repository commit and respective submodule references used. + + + + + + The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) + which was used to generate this NeXus file instance. + + + + + + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + + + + + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective base classes instead of writing prose + into this field. + + The reason is that such free-text field is difficult to machine-interpret. + The motivation behind keeping this field for now is to learn through + the information entered in this field in how far the current base + classes are incomplete. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval via setting both + a start_time and an end_time because this enables software tools and + users to collect a more detailed bookkeeping of the experiment. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :ref:`NXevent_data_em` instances. + + + + + ISO 8601 time code with local time zone offset to UTC included when + the microscope session ended. See docstring of the start_time field + to see how the start_time and end_time should be used together. + + + + + + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + + + + + + Possibility to store a collection of data artifacts + associated with the experiment. + + + + + + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + + + + + + + + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! Instead, use name. + + In cases where multiple specimens were loaded into the microscope, + the identifier has to resolve the specific sample, whose results are + stored by this :ref:`NXentry` instance, because a single NXentry should be + used only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + + + + + Identifier of the sample from which the sample was cut or the string + *None*. The purpose of this field is to support functionalities + for tracking sample provenance via a research data management system. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Ideally, this + matches the last timestamp that is mentioned in the digital resource + pointed to by parent_identifier. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments including tracers with a + short half time. Additional time stamps prior to preparation_date + should better be placed in resources which describe but which do not pollute + the description here with prose. Resolving these connected pieces of information + is considered within the responsibility of the research data management + system. + + + + + An alias used to refer to the specimen to please readability for humans. + + + + + List of comma-separated elements from the periodic table that are + contained in the sample. If the sample substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer research data management systems an + opportunity to parse the relevant elements without having to interpret + these from the resources pointed to by parent_identifier or walk through + eventually deeply nested groups in data instances. + + + + + + (Measured) sample thickness. + + The information is recorded to qualify if the beam used was likely + able to shine through the specimen. For scanning electron microscopy, + in many cases the specimen is typically thicker than what is + illuminatable by the electron beam. + + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. + + + + + + + (Measured) density of the specimen. + + For multi-layered specimens this field should only be used to describe + the density of the excited volume. For scanning electron microscopy + the usage of this field is discouraged and instead an instance of an + :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` + instances can provide a cleaner description of the relevant details + why one may wish to store the density of the specimen. + + + + + Discouraged free-text field to provide further detail although adding + parent_identifier and having a working research data management system + should provide this contextualization. + + + + + + + + + + + + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_ebsd_conventions.nxdl.xml b/contributed_definitions/NXem_conventions.nxdl.xml similarity index 64% rename from contributed_definitions/NXem_ebsd_conventions.nxdl.xml rename to contributed_definitions/NXem_conventions.nxdl.xml index eedbd637d5..e6faa8d54d 100644 --- a/contributed_definitions/NXem_ebsd_conventions.nxdl.xml +++ b/contributed_definitions/NXem_conventions.nxdl.xml @@ -1,9 +1,9 @@ - + - - + + + + + + - Conventions for rotations and coordinate systems to interpret EBSD data. + Conventions for rotations and coordinate systems to interpret crystal orientation + and other data and results collected with electron microscopy research. - This is the main issue which currently is not in all cases documented - and thus limits the interoperability and value of collected EBSD data. - Not communicating EBSD data with such contextual pieces of information - and the use of file formats which do not store this information is the - key unsolved problem. + Documenting explicitly all used conventions and coordinate systems is + the decisive context whereby many results from electron microscopy are + at all interpretable. - + Mathematical conventions and materials-science-specific conventions required for interpreting every collection of orientation data. - + Convention how a positive rotation angle is defined when viewing from the end of the rotation unit vector towards its origin, @@ -54,7 +88,7 @@ assumed reference frame and rotation conventions--> - + How are rotations interpreted into an orientation according to convention 3 of @@ -66,7 +100,7 @@ assumed reference frame and rotation conventions--> - + How are Euler angles interpreted given that there are several choices (e.g. ZXZ, XYZ, etc.) according to convention 4 of @@ -79,7 +113,7 @@ assumed reference frame and rotation conventions--> - + To which angular range is the rotation angle argument of an axis-angle pair parameterization constrained according to @@ -90,7 +124,7 @@ assumed reference frame and rotation conventions--> - + Which sign convention is followed when converting orientations between different parameterizations/representations according @@ -103,25 +137,61 @@ assumed reference frame and rotation conventions--> - + Details about eventually relevant named directions that may give reasons for anisotropies. The classical example is cold-rolling where one has to specify which directions (rolling, transverse, and normal) align how with the direction of the base vectors of the sample_reference_frame. - + Type of coordinate system and reference frame according to convention 1 of DOI: 10.1088/0965-0393/23/8/083501. - - + + + + + + Handedness of coordinate system. + + + + + + + + + Location of the origin of the processing_reference_frame. + This specifies the location Xp = 0, Yp = 0, Zp = 0. + Assume regions-of-interest in this reference frame form a + rectangle or cuboid. + Edges are interpreted by inspecting the direction of their + outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + + + + + + + + + + + - + + + Name or alias assigned to the x-axis base vector, + e.g. rolling direction. + + + Direction of the positively pointing x-axis base vector of the processing_reference_frame. We assume the configuration @@ -138,12 +208,13 @@ assumed reference frame and rotation conventions--> - + - Name or alias assigned to the x-axis base vector, e.g. rolling direction. + Name or alias assigned to the y-axis base vector, + e.g. transverse direction. - + Direction of the positively pointing y-axis base vector of the processing_reference_frame. We assume the configuration @@ -161,12 +232,13 @@ assumed reference frame and rotation conventions--> - + - Name or alias assigned to the y-axis base vector, e.g. transverse direction. + Name or alias assigned to the z-axis base vector, + e.g. normal direction. - + Direction of the positively pointing z-axis base vector of the processing_reference frame. We assume the configuration @@ -184,39 +256,12 @@ assumed reference frame and rotation conventions--> - - - Name or alias assigned to the z-axis base vector, e.g. normal direction. - - - - - Location of the origin of the processing_reference_frame. - This specifies the location Xp = 0, Yp = 0, Zp = 0. - Assume regions-of-interest in this reference frame form a - rectangle or cuboid. - Edges are interpreted by inspecting the direction of their - outer unit normals (which point either parallel or antiparallel) - along respective base vector direction of the reference frame. - - - - - - - - - - - - - - + Details about the sample/specimen reference frame. - + Type of coordinate system and reference frame according to convention 1 of DOI: 10.1088/0965-0393/23/8/083501. @@ -236,71 +281,19 @@ assumed reference frame and rotation conventions--> - - + - + - Direction of the positively pointing x-axis base vector of - the sample surface reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. - - - - - - - - - - - - - - Direction of the positively pointing y-axis base vector of - the sample surface reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. - - - - - - - - - - - - - - Direction of the positively pointing z-axis base vector of - the sample surface reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. + Handedness of the coordinate system if it is a Cartesian. - - - - - - - + + - + Location of the origin of the sample surface reference frame. This specifies the location Xs = 0, Ys = 0, Zs = 0. @@ -322,29 +315,18 @@ assumed reference frame and rotation conventions--> - - - - Details about the detector reference frame. - - + - Type of coordinate system/reference frame used for - identifying positions in detector space Xd, Yd, Zd, - according to DOI: 10.1016/j.matchar.2016.04.008. + Name or alias assigned to the x-axis base vector, + e.g. longest edge. - - - - - - + Direction of the positively pointing x-axis base vector of - the detector space reference frame. We assume the configuration - is inspected by looking towards the sample surface from a - position that is located behind the detector. + the sample surface reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. Different tools assume that different strategies can be used and are perceived as differently convenient to enter details about coordinate system definitions. In this ELN users @@ -363,14 +345,19 @@ assumed reference frame and rotation conventions--> - + + + Name or alias assigned to the y-axis base vector, + e.g. long edge. + + + Direction of the positively pointing y-axis base vector of - the detector space reference frame. We assume the configuration - is inspected by looking towards the sample surface from a - position that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. + the sample surface reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. @@ -382,14 +369,19 @@ assumed reference frame and rotation conventions--> - + + + Name or alias assigned to the z-axis base vector, + e.g. shortest edge. + + + Direction of the positively pointing z-axis base vector of - the detector space reference frame. We assume the configuration - is inspected by looking towards the sample surface from a - position that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. + the sample surface reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. @@ -401,7 +393,39 @@ assumed reference frame and rotation conventions--> - + + + + Details about the detector reference frame for a specific detector. + + + + Reference to the specifically named :ref:`NXdetector` instance + for which these conventions in this :ref:`NXprocess` group apply + (e.g. /entry1/instrument/detector1). + + + + + Type of coordinate system/reference frame used for + identifying positions in detector space Xd, Yd, Zd, + according to DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + Handedness of the coordinate system if it is a Cartesian. + + + + + + + Where is the origin of the detector space reference frame located. This is the location of Xd = 0, Yd = 0, Zd = 0. @@ -423,30 +447,18 @@ assumed reference frame and rotation conventions--> - - - - Details about the gnomonic projection reference frame. - - + - Type of coordinate system/reference frame used for identifying - positions in the gnomonic projection space Xg, Yg, Zg - according to DOI: 10.1016/j.matchar.2016.04.008. + Name or alias assigned to the x-axis base vector, + e.g. longest edge as some landmark on the detector. - - - - - - + - Direction of the positively pointing "gnomomic" x-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. + Direction of the positively pointing x-axis base vector of + the detector space reference frame. We assume the configuration + is inspected by looking towards the sample surface from a + position that is located behind the detector. Different tools assume that different strategies can be used and are perceived as differently convenient to enter details about coordinate system definitions. In this ELN users @@ -465,33 +477,18 @@ assumed reference frame and rotation conventions--> - + - Direction of the positively pointing "gnomomic" y-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. + Name or alias assigned to the x-axis base vector, + e.g. long edge as some landmark on the detector. - - - - - - - - - - + - Direction of the positively pointing "gnomomic" z-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. + Direction of the positively pointing y-axis base vector of + the detector space reference frame. We assume the configuration + is inspected by looking towards the sample surface from a + position that is located behind the detector. For further information consult also the help info for the xaxis_direction field. @@ -505,88 +502,20 @@ assumed reference frame and rotation conventions--> - - - Is the origin of the gnomonic coordinate system located - where we assume the location of the pattern centre. - This is the location Xg = 0, Yg = 0, Zg = 0 according to - reference DOI: 10.1016/j.matchar.2016.04.008. - - - - - - - - - - Details about the definition of the pattern centre - as a special point in the gnomonic projection reference frame. - - + - From which border of the EBSP (in the detector reference frame) - is the pattern centre's x-position (PCx) measured? - Keywords assume the region-of-interest is defined by - a rectangle. We observe this rectangle and inspect the - direction of the outer-unit normals to the edges of - this rectangle. - - - - - - - - - - - - In which direction are positive values for PCx measured from - the specified boundary. Keep in mind that the gnomonic space - is in virtually all cases embedded in the detector space. - Specifically, the XgYg plane is defined such that it is - embedded/laying inside the XdYd plane (of the detector - reference frame). - When the normalization direction is the same as e.g. the - detector x-axis direction, we state that we effectively - normalize in fractions of the width of the detector. - - The issue with terms like width and height is that these - degenerate if the detector region-of-interest is square-shaped. - This is why we should better avoid talking about width and height but - state how we would measure distances practically with a ruler and - how we then measure positive distances. + Name or alias assigned to the x-axis base vector, + e.g. short edge as some landmark on the detector. - - - - - - - - + - From which border of the EBSP (in the detector reference - frame) is the pattern centre's y-position (PCy) measured? - For further details inspect the help button of - xaxis_boundary_convention. - - - - - - - - - - - - In which direction are positive values for PCy measured from - the specified boundary. - For further details inspect the help button of - xaxis_normalization_direction. + Direction of the positively pointing z-axis base vector of + the detector space reference frame. We assume the configuration + is inspected by looking towards the sample surface from a + position that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. @@ -594,17 +523,12 @@ assumed reference frame and rotation conventions--> + + - + + + diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml new file mode 100644 index 0000000000..8a19f1e29b --- /dev/null +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -0,0 +1,230 @@ + + + + + + + Base class for method-specific conventions EBSD. + + This base class is expected to be used with :ref:`NXem_conventions`. + + This is the main issue which currently is not in all cases documented + and thus limits the interoperability and value of collected EBSD data. + Not communicating EBSD data with such contextual pieces of information + and the use of file formats which do not store this information is the + key unsolved problem. + + + + Details about the gnomonic projection reference frame. + + + + Type of coordinate system/reference frame used for identifying + positions in the gnomonic projection space Xg, Yg, Zg + according to DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + Handedness of coordinate system. + + + + + + + + + Is the origin of the gnomonic coordinate system located + where we assume the location of the pattern centre. + This is the location Xg = 0, Yg = 0, Zg = 0 according to + reference DOI: 10.1016/j.matchar.2016.04.008. + + + + + + + + + Direction of the positively pointing "gnomomic" x-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + + + + + + + + + + + + + + Direction of the positively pointing "gnomomic" y-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + Direction of the positively pointing "gnomomic" z-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + + + + + + + + + + + + + + + Details about the definition of the pattern centre + as a special point in the gnomonic projection reference frame. + + + + From which border of the EBSP (in the detector reference frame) + is the pattern centre's x-position (PCx) measured? + Keywords assume the region-of-interest is defined by + a rectangle. We observe this rectangle and inspect the + direction of the outer-unit normals to the edges of + this rectangle. + + + + + + + + + + + + In which direction are positive values for PCx measured from + the specified boundary. Keep in mind that the gnomonic space + is in virtually all cases embedded in the detector space. + Specifically, the XgYg plane is defined such that it is + embedded/laying inside the XdYd plane (of the detector + reference frame). + When the normalization direction is the same as e.g. the + detector x-axis direction, we state that we effectively + normalize in fractions of the width of the detector. + + The issue with terms like width and height is that these + degenerate if the detector region-of-interest is square-shaped. + This is why we should better avoid talking about width and height but + state how we would measure distances practically with a ruler and + how we then measure positive distances. + + + + + + + + + + + + From which border of the EBSP (in the detector reference + frame) is the pattern centre's y-position (PCy) measured? + For further details inspect the help button of + xaxis_boundary_convention. + + + + + + + + + + + + In which direction are positive values for PCy measured from + the specified boundary. + For further details inspect the help button of + xaxis_normalization_direction. + + + + + + + + + + + + diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml new file mode 100644 index 0000000000..58c0f68255 --- /dev/null +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -0,0 +1,245 @@ + + + + + + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. + + + + Details about processing steps. + + + + + + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + + + + + + Descriptor representing the image contrast. + + + + + + Title of the default plot. + + + + + Descriptor values displaying the ROI. + + + + + + + + + + Descriptor values. + + + + + + Calibrated coordinate along the z-axis. + + + + + + + Label for the z axis + + + + + + Calibrated coordinate along the y-axis. + + + + + + + Label for the y axis + + + + + + Calibrated coordinate along the x-axis. + + + + + + + Label for the x axis + + + + + + + diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index 8b1160db3e..5d4250dc54 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -1,9 +1,9 @@ - + - - - + @@ -99,65 +35,90 @@ reducing the total number of ontologies.--> - Number of pixel along the slowest changing dimension for a rediscretized, i.e. - standardized default orientation mapping. + Number of pixel along the slowest changing dimension for a rediscretized, + i.e. standardized default plot orientation mapping. Number of pixel along slow changing dimension for a rediscretized i.e. - standardized default orientation mapping. + standardized default plot orientation mapping. Number of pixel along fast changing dimension for a rediscretized i.e. - standardized default orientation mapping. + standardized default plot orientation mapping. - - Application definition for collecting and indexing Kikuchi pattern into orientation maps. + Base class method-specific for Electron Backscatter Diffraction (EBSD). - This NXem_ebsd application is a proposal how to represent data, metadata, and - connections between these for the research field of electron microscopy. - More specifically, exemplified here for electron backscatter diffraction (EBSD). - The application definition solves two key documentation issues which are missing - so far to document provenance of data and metadata in the field of EBSD. - The application definition can be an example that is relevant for related - workflows in orientation microscopy. + The general procedure of an EBSD experiment is as follows: + Users load the specimen, collect first a coarse image of the surface. + Next, they set an approximate value for the calibrated working distance and + tilt the stage to set the desired diffraction conditions. + + Users then typically configure the microscope for collecting higher quality data + and push in the EBSD detector. Subsequently, they fine tune the illumination + and aberration corrector settings and select one or multiple ROIs for + the microscope to machine off automatically. They configure on-the-fly + indexing parameter and start the measurement queue. + + Nowadays, this is in most cases an automated process. The pattern + collection runs during the allocated microscope session until the + queue finishes or gets interrupted by errors or the next user terminates + sessions which run over time. + + Kikuchi pattern surplus eventually multi-modal detector signals are + collected and usually indexed on-the-fly. Patterns may be stored or not + so one should not assume that raw data are always stored. + + Results are stored in files, which afterwards are typically copied + automatically or manual for archival purposes to certain storage + locations or further consumption. The result of such an EBSD + measurement/experiment is a set of usually proprietary or open files + from technology partners. + + This :ref:`NXem_ebsd` base class is a proposal how to represent method-specific + data, metadata, and connections between these for the research field of + electron microscopy. + + More specifically, exemplified here for electron backscatter diffraction (EBSD) + we show how NeXus can be used to solve two key documentation issues so far + missing in the field of EBSD. Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted - according to the NXem_ebsd application definition) stores the connection between - the microscope session and the key datasets which are considered typically results - of the various processing steps involved when working with EBSD data. + according to NXem_ebsd) stores the connection between the microscope session and + the key datasets which are considered typically results of the various processing + steps involved when working with EBSD data. - Different groups in this application definition make connections to data artifacts - which were collected when working with electron microscopes via the NXem partner - application definition. Using a file which stores information according to the - NXem application definition has the benefit that it connects the sample, references - to the sample processing, the user operating the microscope, details about the - microscope session, and details about the acquistion and eventual indexing of - Kikuchi pattern, associated overview images, like secondary electron or - backscattered electron images of the region-of-interest probed and many - more pieces of information. + Different groups in NXem_ebsd make connections to data artifacts which were collected + when working with electron microscopes via the NXem application definition. + Using a file which stores information according to the NXem application definition + has the benefit that it connects the sample, references to the sample processing, + the user operating the microscope, details about the microscope session, + and details about the acquisition and eventual indexing of Kikuchi pattern, + associated overview images, like secondary electron or backscattered electron + images of the region-of-interest probed and many more pieces of information. - Secondly, this NXem_ebsd application definition connects and stores the conventions - and reference frames which were used and are the key to mathematically correctly - interpret every EBSD result. Otherwise, results would be ripped out of their - context, as it is the situation with many traditional studies where EBSD data were - indexed on-the-fly and shared with the community only via sharing the results file - with some technology-partner-specific file but leaving important conventions out - or relying on the assumptions that colleagues know these even though multiple - definitions are possible. + Secondly, NXem_ebsd connects and stores the conventions and reference frames + which were used and which are the key to a correct mathematical interpretation + of every EBSD result. Otherwise, results would be ripped out of their context, + as it is the current situation with many traditional studies where EBSD data + were indexed on-the-fly and shared with the community only via sharing + the strongly processed results file in some technology-partner-specific file + format but without communicating all conventions or relying on the assumptions + that colleagues likely know these conventions even though multiple definitions + are possible. - This application definition covers experiments with one-, two-dimensional, and - so-called three-dimensional EBSD datasets. The third dimension is either time - (in the case of quasi in-situ experiments) or space (in the case of serial- - sectioning) methods where a combination of mechanical or ion milling is used - repetitively to measure the same region-of-interest at different depth increments. - Material removal can be achieved with electron or ion polishing, using manual + NXem_ebsd covers experiments with one-, two-dimensional, and so-called three- + dimensional EBSD datasets. The third dimension is either time (in the case of + quasi in-situ experiments) or space (in the case of serial-sectioning) methods + where a combination of mechanical or ion milling is used repetitively to measure + the same region-of-interest at different depth increments. Material removal + can be achieved with electron or ion polishing, using manual steps or using automated equipment like a robot system. Three-dimensional experiments require to follow a sequence of specimen, surface @@ -179,1748 +140,412 @@ reducing the total number of ontologies.--> post-processing can be granularized also for such X-ray-based techniques, whether it be 3DXRD or HEDM. - - + + + + + This group documents relevant details about the conditions and the tools + used for measuring a stack of Kikuchi diffraction pattern with an + electron microscope. + + The most frequently collected EBSD data are captured for rectangular + regions-of-interested which are sampled with regular square or + hexagon-shaped pixels. + + + + Physical time since the beginning of a timestamp that is required to be + same for all experiments in the set. The purpose of this marker is + to identify how all experiments in the set have have to be arranged + sequentially based on the time elapsed. + The time is relevant to sort e.g. experiments of consecutive quasi + in-situ experiments where a measurement was e.g. taken after 0 minutes + of annealing, 30 minutes, 6 hours, or 24 hours of annealing. + + + + Timestamp relative to which time was counted to aid + converting between time and timestamp. + + + + + - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. + If available and it is stored in an instance of an application definition + this field gives the path of an :ref:`NXdata` where the pattern are stored. - - + - NeXus NXDL schema to which this file conforms. + Reference (e.g. path and filename) to an existent data artifact which + stores either the measured pattern or input (already processed EBSD data). - - - - - + + + + + This group documents relevant details about the conditions and the tools + used for simulating a stack of Kikuchi diffraction pattern with some + physical model. + + This group should not be confused with a group named simulation that + is however an instance of NXem_sim. Instead, the simulation group here + should be used if (e.g. instead of a measurement) a stack of pattern + were simulated that one wishes to use for indexing patterns. + + In many practical cases where pattern are analyzed on-the-fly and dictionary + indexing strategies are used, so-called master pattern(s) are used to compare + measured or simulated pattern with the master pattern. In this case, + master pattern are the result of a computer simulation and thus should + be stored using an own properly documented entry within a simulation + group as an instance of :ref:`NXem_sim`. + + - Ideally, a (globally) unique persistent identifier - for referring to this workflow. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - workflows/experiments to e.g. proposals. + If available and it is stored in an instance of an application definition + this field gives the path of an :ref:`NXimage_r_set_diff` + where the simulated pattern are stored. - - + + - Free-text description about the workflow. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of the application - definition behind instead of filling in these details into the experiment_description - free-text description field. + Reference (e.g. path and filename) to an existent digital resource which + stores either the pattern or input (already processed EBSD data) + which is now processed further as described by this NXem_ebsd instance. - - + + + + + The EBSD system, including components like the electron gun, pole-piece, + stage tilting, EBSD detector, and the gnomonic projection have to be + calibrated to achieve reliable indexing results. + + Specifically, the gnomonic projection has to be calibrated. + Typically, silicon or quartz crystals are used for this purpose. + + Considering a system is well-calibrated, it is much more frequently the + case in practice that users assume the system is calibrated (and thus usable) + vs. they perform the calibration of the EBSD system. + + In the first case, the user assumes that the principle geometry of the + hardware components and the settings in the control and EBSD pattern + acquisition software has been calibrated. Consequently, users pick from + an existent library of phase candidates, i.e. + :ref:`NXcrystal_structure` instances. Examples are + reflector models as stored in CRY files (HKL/Channel 5/Flamenco). + + In the second case, users calibrate the system during the session + using standards (silicon, quartz, or other common specimens). + There is usually one person in each lab responsible for doing such + calibrations. Often this person or technician is also in charge of + configuring the graphical user interface and software with which most + users control and perform their analyses. + + For EBSD this has key implications: Taking TSL OIM/EDAX as an example, + the conventions how orientations are stored is affected by how the + reference frames are configured and this setup is made at the level + of the GUI software. + + Unfortunately, these pieces of information are not necessarily stored + in the results files. In effect, key conventions become disconnected + from the data so it remains the users' obligation to remember these + settings or write these down in a lab notebook. Otherwise, these metadata + get lost. All these issues are a motivation and problem which + :ref:`NXem_ebsd` solves in that all conventions can be specified explicitly. + + - ISO 8601 time code with local time zone offset to UTC information - included when the processing of the workflow started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - workflow was executed - and the exact duration is not relevant - - this start_time field should be used. + If available and it is stored in an instance of an application definition + this field gives the path of an :ref:`NXem_msr` where the calibration is + stored. + + + + + Reference to a digital resource where the calibration is stored. + + + + + + Indexing is a data processing step performed either after or while + (on-the-fly) the beam scans the specimen. The resulting method is also + known as orientation imaging microscopy (OIM). + + Different algorithms can be used to index EBSD pattern. Common to them + is the computational step where simulated reference pattern are compared + with measured or simulated patterns. These latter patterns are referred + to via the measurement or simulation groups of this base class. + + Quality descriptors are defined based on which an indexing algorithm + yields a quantitative measure of how similar measured and reference + pattern are, and thus if no, one, or multiple so-called solutions + were found. + + Assumed or simulated pattern are simulated using kinematic or dynamical + theory of electron diffraction delivering master pattern. + + The Hough transform is essentially a discretized Radon transform (for details see `M. van Ginkel et al. <https://www.semanticscholar.org/paper/A-short-introduction-to-the-Radon-and-Hough-and-how-Ginkel/fb6226f606cad489a15e38ed961c419037ccc858>`_). + Recently, dictionary-based indexing methods are increasingly becoming used + partly driven by the interest to use artificial intelligence algorithms. + + + + This group enables to establish a logical connection between previous + processing steps or on-the-fly-performed indexing of the EBSD map. + Typically these processing steps are performed with commercial software. + Therefore, in many cases a results file from this indexing is often + all that is communicated and saved. These are typically files in a format + specific to the instrument and its configuration. - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the workflow. + Typical file formats are CPR/CRC, ANG, OSC, HDF5, H5EBSD, EDAXH5. - - + + - ISO 8601 time code with local time zone offset to UTC included - when the processing of the workflow ended. + Principal algorithm used for indexing. + + + + + + + - + - Program which was used for creating the file instance which is - formatted according to the NXem_ebsd application definition. + Details about the background correction applied to each Kikuchi pattern. - - - - + - Contact information and eventually details of at least one person - involved in performing the workflow. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is - recommended. + Binning i.e. downsampling of the pattern. - - - 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + Specific parameter relevant only for certain algorithms used. + - - + - Details about simulations for Kikuchi pattern using kinematic or dynamic - diffraction theory. Usually, the output of such computer simulations are - spherical Kikuchi images which only when projected or observed in some - region-of-interest will represent a set of rectangular Kikuchi pattern - with the same rectangular shape and image size. + Details for each phase used as a model with which the patterns were + indexed. Instances of :ref:`NXcrystal_structure` in this group must + have the group name prefix phase. The identifier in the name is an + integer. We start counting from 1 because the value 0 is reserved for + the special phase that is the null-model, i.e. the null phase, notIndexed. + + + + + Which return value did the indexing algorithm yield for each scan point. + Practically useful is to use an uint8 mask. - Therefore, these pattern should be stored. The spherical diffraction - pattern can be stored as a set of triangulated geodesic meshes. - The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. + * 0 - Not analyzed + * 1 - Too high angular deviation + * 2 - No solution + * 100 - Success + * 255 - Unexpected errors + + + + + + + + How many phases i.e. crystal structure models were used to index each + scan point if any? Let's assume an example to explain how this field + should be used: In the simplest case users collected one pattern for + each scan point and have indexed using one phase, i.e. one instance + of an NXem_ebsd_crystal_structure_model. + + In another example users may have skipped some scan points (not indexed) + them at all) and/or used differing numbers of phases for different scan + points. - Do not store pattern in the simulation group if they - have been measured are not simulated. + The cumulated of this array decodes how phase_identifier and phase_matching + arrays have to be interpreted. In the simplest case (one pattern per scan + point, and all scan points indexed using that same single phase model), + phase_identifier has as many entries as scan points + and phase_matching has also as many entries as scan points. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + - The experiment group captures relevant details about the conditions of - and the tools used for collecting the Kikuchi diffraction pattern. + The array n_phases_per_scan_point details how the phase_identifier + and the phase_matching arrays have to be interpreted. - The most frequently collected EBSD data are captured as rectangular ROIs - composed from square or hexagonally-shaped pixels. Substantially less - frequently, because such experiments are more costly and technically - demanding, correlated experiments are performed. + For the example with a single phase phase_identifier has trivial + values either 0 (no solution) or 1 (solution matching + sufficiently significant with the model for phase 1). - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. Here the same or nearly the same ROI is - analyzed via a cycles of thermomechanical treatment, sample preparation, - measurement, on-the-fly-indexing. Phenomena investigated like this are - recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - features or local ROIs across several orientation maps. + When there are multiple phases, it is possible (although not frequently + needed) that a pattern matches eventually (not equally well) sufficiently + significant with multiple pattern. This can especially happen in cases of + pseudosymmetry and more frequently with an improperly calibrated system + or false or inaccurate phase models e.g. (ferrite, austenite). + Having such field is especially relevant for recent machine learning + or dictionary based indexing schemes because in combination with + phase_matching these fields communicate the results in a model-agnostic + way. - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is repetitively measured - and polished to create a stack of orientation data which can be reconstructed - to a three-dimensional volume ROI. + Depending on the n_phases_per_scan_point value phase_identifier and + phase_matching arrays represent a collection of concatenated tuples, + which are organized in sequence: The solutions for the 0-th scan point, + the 1-th scan point, the n_sc - 1 th scan point and omitting tuples + for those scan points with no phases according to n_phases_per_scan_point + + + + + + + + One-dimensional array, pattern by pattern labelling the solutions found. + The array n_phases_per_scan_point has to be specified because it details + how the phase_identifier and the phase_matching arrays have to be interpreted. + See documentation of phase_identifier for further details. + + + + + + + + Phase_matching is a descriptor for how well the solution matches or not. + Examples can be confidence_index, mean_angular_deviation, some AI-based + matching probability (other), i.e. the details are implementation-specific. + + + + + + + + + + + + + + Calibrated center positions of each scan point + in the sample surface reference system. - + + + + + + + + Fraction of successfully indexed pattern with a phase + not the null-phase vs the number_of_scan_points. + + + + + Number of scan points in the original mapping. + + + + + + + + + An overview of the entire ROI. + + - Physical time since the beginning of a timestamp that is required to be - same for all experiments in the set. The purpose of this marker is - to identify how all experiments in the set have have to be arranged - sequentially based on the time elapsed. - The time is relevant to sort e.g. experiments of consecutive quasi - in-situ experiments where a measurement was e.g. taken after 0 minutes - of annealing, 30 minutes, 6 hours, or 24 hours of annealing. + Descriptor representing the image contrast. + + + + + + - - - Transformation which details where the region-of-interest described under - indexing is located in absolute coordinates and rotation with respect - to which coordinate system. - - - - - - The EBSD system, including components like the electron gun, pole-piece, - stage tilting, EBSD detector, and the gnomonic projection have to be - calibrated to achieve reliable results. Specifically, the gnomonic projection - has to be calibrated. - - In most practical cases, especially in engineering, there is a substantially - larger number of sessions where such a calibrated system is used assuming - that somebody has properly calibrated the system rather than that the user - actively recalibrates it or is even allowed to do so. - Especially the projection geometry has to calibrated which is usually - achieved with measuring silicon, quartz or standards, and comparing - against simulated diffraction pattern. - - In the first case, the user assumes that the principle geometry of the - hardware components and the settings in the control and EBSD pattern - acquisition software are calibrated. Consequently, users pick from an - existent library of phase candidates. One example are the CRY or CIF - files of the classical HKL/Channel 5/Flamenco software products. - Each entry of the library of such phase candidates in this NeXus proposal - is represented by one NXem_ebsd_crystal_structure_model base class. - For each phase an instance of this base class is to be used to store - crystallographic and simulation-relevant data. - - Indexing is a data processing step performed after/during the beam scans - the specimen (depends on configuration). Users load the specimen, and first - collect a coarse image of the surface. Next, an approximate value for the - calibrated working distance is chosen and the stage tilted. - Users then may configure the microscope for collecting higher quality data - and push in the EBSD detector. Subsequently, they fine tune the illumination - and aberration settings and select one or multiple ROIs to machine off. - The on-the-fly indexing parameter are defined and usually the automated - measurement queue started. - - Nowadays, this is usually an automated/unsupervised process. The pattern - collection runs during the allocated session time slot which the user has - booked ends or when the queue finishes prematurely. Kikuchi pattern surplus - eventually multi-modal detector signals are collected and usually indexed - on-the-fly. The Kikuchi patterns may or not be deleted directly after a - solution was found (on-the-fly) so Kikuchi pattern are not always stored. - - Results files are in many labs afterwards copied automatically - for archival purposes to certain storage locations. The result of such an - EBSD measurement/experiment is a set of usually proprietary or open files - from technology partners (microscope and EBSD detector manufacturers). - - In the second case, the system is being calibrated during the session - using standards (silicon, quartz, or other common specimens). - There is usually one person in each lab responsible for doing such - calibrations. Important is that often this person or technician(s) are also - in charge of configuring the graphical user interface and software - with which most users control and perform their analyses. - For EBSD this has key implications because, taking TSL OIM/EDAX as an example, - the conventions how orientations are stored is affected by how reference frames - are set up and this setup is made at the level of the GUI software. - Unfortunately, these pieces of information are not necessarily stored - in the results files. In effect, key conventions become disconnected - from the data so it remains the users personal obligation to remember these - settings, write them down in the lab notebook, or these metadata get lost. - All these issues are a motivation and problem which NXem_ebsd solves. - - - - - A link/cross reference to an existent instance of NXem_ebsd with ideally - an associated instance of NXem detailed under measurement which informs - about the calibration procedures. - - - - Commit identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to the EBSD data (post)-processing workflow - when performing the calibration. - - - - - + + - Relevant result of the session at the microscope for this experiment - which enables to connect the measurement of the Kikuchi pattern and - their processing into orientation microscopy maps. + Title of the default plot. - - - - Name or link to an existent instance of an EBSD raw dataset ideally - as an instance of an NXem application definition which has at least - one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. - The path to this instance in the origin has to be specified under path. - - When NXem is not used or the aim is to rather explore first how - community-specific files with EBSD data, such as ANG, CPR, or HDF5- - based formats can be parsed from, inject here the name of that file. - - The em_om parser will currently not interpret the majority of the - many system- and technique-specific metadata which come with the - files from e.g. technology partners. This is because the current - culture in the EBSD community is that many of the metadata fields - are neither in all cases fully documented nor use a standardized - vocabulary although many people understand terms from different - implementations and how these metadata can likely be compared to - one another. - - In addition, it is common practice in the research field of EBSD that - users transcode their raw data into other (often text-based or HDF5) - files with custom formatting to realize an information transfer - between specific software tools including commercial software from - technology partner, custom scripts in Matlab using tools like MTex, - or Python scripting with tools like hyperspy, pyxem, orix, diffsims, - kikuchipy, or EBSD data stack alignment tools like DREAM.3D. - We have opted that in the first iteration this implementation of a - RDMS-agnostic FAIR data schema for EBSD that we discard these metadata - because these ad hoc file formats are not designed to communicate - also specifically and most importantly the eventually different context - of the metadata. - Another reason for this choice was also to emphasize that in fact such - challenges do exist in the community and thus pointing them out may - support the discussion to arrive at eventually more complete solutions. - As developing these solutions should not be our authority and necessarily - demands feedback from the technology partners, we have opted for this - intermediate approach to stimulate discussion. - - - - Commit or e.g. at least SHA256 checksum identifying this resource. - - - - - - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow. - - - - - - + + - OIM, orientation imaging microscopy. Post-processing of the Kikuchi - patterns to obtain orientation per phase model and scan point. - Fundamentally different algorithms can be used to index EBSD/EBSP pattern. - - Common is that pattern indexing is a computational step of comparing - simulated with measured diffraction pattern. Quality descriptors are defined - based on which an indexing algorithm yields a quantitative measure of - how similar measured and assumed/simulated pattern are, and thus if - no, one, or multiple so-called solutions were found. - - Assumed or simulated pattern use kinematical or dynamical electron - diffraction theory. Hough transform (which is essentially a discretized - Radon transform, for details see e.g A short introduction to the Radon - and Hough transforms and how they relate by M. van Ginkel et al.). - Recently, dictionary-based indexing methods are increasingly becoming used - partly driven by the move to use artificial intelligence algorithms. - - An inspection of publicly available EBSD datasets with an open-source - license which are available on Zenodo was performed prior to implementing - of the associated em_om parser for NXem_ebsd. This analysis revealed that - EBSD data are in most cases stored in two ways: Case one was via a file in - formats from technology partners. Examples are binary formats like OSC, - H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, - CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. - - These files contain some result and metadata to the numerical steps and the - computational workflow which was performed to index Kikuchi pattern - on-the-fly. Examples of metadata include scan point positions, indexing - solutions per scan point, some quality descriptors for the solutions, - as well as crystal structure and phase metadata. - - Case two were raw pattern in some custom format, often text-based with - some but in general no conclusive and interoperable representation of all - relevant metadata. - Often it remains unclear what individual fields and data arrays of these - fields resolve and/or mean conceptually. For some fields, publications were - referred to. However, software tools change over time and thus which specific - data end in a file and which specific conceptual information is behind - these data can change with software versions. - - Other cases were storing results of custom post-processing steps and - associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry - resolving methods, i.e. any sort of prototyping or alternative indexing - strategies so far seem to require some flexibility for implementing - rapid prototypic capabilities. The drawback of this is that such results - come formatted on a case-by-case basis and are thus not interoperable. - - Therefore, we first need to collect how these files have been generated - and which metadata in these files (or database entries) represent - which pieces of information conceptually. Ideally, one would do so by - creating a complete set of information in e.g. an NXem application definition, - such as a log of timestamped events and processing steps, metadata and data. - Eventually even interactions with the graphical user interface of commercial - software during the microscope session should be stored and become a - part of the application definition. - - Such a set of pieces of information could then be used via reading directly - for the NXem application definition. However, in most cases such a data - representation is not available yet. + Descriptor values displaying the ROI. - - - - Therefore, the on_the_fly_indexing group stores which source_file contains - the results of the on-the-fly indexing. For commercial systems these files - can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or - database entry which is referred to under origin is the same as the one - under a given acquisition/origin in one of the experiment groups. - This is because some commercial file formats make no clear distinction - between which metadata are acquisition and/or indexing metadata. - - - - Commercial program which was used to index the EBSD data - incrementally after they have been captured and while the - microscope was capturing (on-the-fly). This is the usual - production workflow how EBSD data are collected in - materials engineering, in industry, and academia. - - - - - - - - Name of the file from which data relevant for creating default plots - were taken in the case that the data in the experiment group were - indexed on-the-fly. - - - - Hash of that file. - - - - - - TBD, path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow - when performing the calibration. - - - - - - Principal algorithm used for indexing. - - - - - - - - - - - - Details about the background correction applied to each Kikuchi pattern. - - - - - - - Binning i.e. downsampling of the pattern. - - - - - - - Specific parameter relevant only for certain algorithms used - - - - - - - - - - - - - - - - - - - - - - - - - - - Which return value did the indexing algorithm yield for each scan point. - Practically useful is to use an uint8 mask. - - * 0 - Not analyzed - * 1 - Too high angular deviation - * 2 - No solution - * 100 - Success - * 255 - Unexpected errors - - - - - - - - - How many phases i.e. crystal structure models were used to index each - scan point if any? Let's assume an example to explain how this field - should be used: In the simplest case users collected one pattern for - each scan point and have indexed using one phase, i.e. one instance - of an NXem_ebsd_crystal_structure_model. - - In another example users may have skipped some scan points (not indexed) - them at all) and/or used differing numbers of phases for different scan - points. - - The cumulated of this array decodes how phase_identifier and phase_matching - arrays have to be interpreted. In the simplest case (one pattern per scan - point, and all scan points indexed using that same single phase model), - phase_identifier has as many entries as scan points - and phase_matching has also as many entries as scan points. - - - - - - - - The array n_phases_per_scan_point details how the phase_identifier - and the phase_matching arrays have to be interpreted. - - For the example with a single phase phase_identifier has trivial - values either 0 (no solution) or 1 (solution matching - sufficiently significant with the model for phase 1). - - When there are multiple phases, it is possible (although not frequently - needed) that a pattern matches eventually (not equally well) sufficiently - significant with multiple pattern. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models e.g. (ferrite, austenite). - Having such field is especially relevant for recent machine learning - or dictionary based indexing schemes because in combination with - phase_matching these fields communicate the results in a model-agnostic - way. - - Depending on the n_phases_per_scan_point value phase_identifier and - phase_matching arrays represent a collection of concatenated tuples, - which are organized in sequence: The solutions for the 0-th scan point, - the 1-th scan point, the n_sc - 1 th scan point and omitting tuples - for those scan points with no phases according to n_phases_per_scan_point - - - - - - - - One-dimensional array, pattern by pattern labelling the solutions found. - The array n_phases_per_scan_point has to be specified because it details - how the phase_identifier and the phase_matching arrays have to be interpreted. - See documentation of phase_identifier for further details. - - - - - - - - Phase_matching is a descriptor for how well the solution matches or not. - Examples can be confidence index (ci), mean angular deviation (mad), - some AI-based matching probability (other), i.e. the details are implementation-specific. - - - - - - - - - - - How are orientations parameterized? Inspect euler_angle_convention - in case of using euler to clarify the sequence of rotations assumed. - - - - - - - - - - - - Matrix of parameterized orientations identified. The slow dimension - iterates of the individual solutions as defined by n_phases_per_scan_point. - Values for phases without a solution should be correctly identified as - IEEE NaN. - - - - - - - - em_lab/ebeam_deflector to retrieve the actual scan positions -although this would be much cleaner--> - - Matrix of calibrated centre positions of each scan point - in the sample surface reference system. - - - - - - - - - - - Fraction of successfully indexed pattern - of the set averaged over entire set. - - - - - - An overview of the entire area which was scanned. - For details about what defines the image contrast - inspect descriptor. - - - - Descriptor representing the image contrast. - - - - - - - - - - Container holding a default plot of the region on the sample - investigated with EBSD. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - + - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - - The IPF mapping is interpolated from the scan point data mapping - onto a rectangular domain with square pixels and the - orientations colored according to the coloring scheme used in the - respective ipf_color_modelID/program. - - The main purpose of the ipf_mapID group is not to keep raw data or - scan point related data but offer a default way how a research data - management system can display a preview of the dataset so that users - working with the RDMS can get an overview of the dataset. - - This matches the first aim of NXem_ebsd which is foremost to bring - colleagues and users of EBSD together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging - data from EBSD between different tools and research data management - systems (RDMS). - - With this design the individual RDMS solutions and tools can still continue - to support specific custom data analyses workflow and routes but at least - there is then one common notation of understanding whereby also users - not necessarily expert in all the details of the EBSD story can understand - better these data and thus eventually this can motivate data reuse and - repurposing. - - It is important to mention that we cannot assume, at least for now, - that the parser which writes to an NXem_ebsd-compliant file is also - responsible or capable at all of computing the inverse pole figure - color keys and maps itself. This cannot be assumed working because - this mapping of orientation data uses involved mathematical algorithms - and functions which not every tools used in the EBSD community is capable - of using or is for sure not using in exactly the same way. - - Currently, we assume it is the responsibilty of the tool used which - generated the data under on_the_fly_indexing to compute these - plots and deliver these to the parser. - - Specific case studies have been explored by the experiment team of - Area B of the FAIRmat project to realize and implement such mapping. - - The first case study uses the H5OINA format and the pyxem/orix library. - As orix is a Python library, the coloring is performed by the em_om parser. - - The second case study uses MTex and its EBSD color coding model. - As MTex is a Matlab tool, an intermediate format is written from MTex - first which stores these pieces of information. The parser then pulls - these data from the intermediate Matlab-agnostic representation and - supplements the file with missing pieces of information as it is - required by NXem_ebsd. - - The third case study shows how a generic set of Kikuchi pattern - can be loaded with the em_om parser. The pattern are loaded directly - from a ZIP file and mapped to an simulation image section for now. - - The fourth case study uses the DREAM.3D package which provides an own - set of EBSD data post-processing procedures. DREAM.3D documents the - processing steps with a pipeline file which is stored inside DREAM.3D - output files. In this case study, the parser reads the DREAM.3D file - and maps data relevant from the perspective of NXem_ebsd plus adds - relevant IPF color maps as they were computed by DREAM.3D. - Given that in this case the origin of the data is the DREAM.3D file - again provenance is kept and more details can be followed upon when - resolving origin. - - These examples offer a first set of suggestions on how to make EBSD - data injectable into research data management system using schemes - which themselves are agnostic to the specific RDMS and interoperable. - Steps of collecting the raw data and post-processing these with custom - scripts like MTex or commercial tools so far are mainly undocumented. - The limitation is that a program which consumes results or dump files - from these tools may not have necessarily all the sufficient information - available to check if the injected orientation data and color models - are matching the conventions which a user or automated system has - injected into an electronic lab notebook from which currently the em_om - parser collects the conventions and stores them into this NXem_ebsd instance. - The immediate benefit of the here presented NXem_ebsd concept though - is that the conventions and reference frame definitions are expected - in an ELN-agnostic representation to make NXem_ebsd a generally useful - data scheme for EBSD. - - Ideally, the em_om parser would load convention-compliant EBSD data - and use subsequently a community library to transcode/convert orientation - conventions and parameterized orientation values. Thereafter, convention- - compliant default plot(s) could be created that would be truely interoperable. - - However, given the variety of post-processing tools available surplus - the fact that these are not usually executed along standardized - post-processing workflows which perform exactly the same algorithmic steps, - this is currently not a practically implementable option. Indeed, first - developers who wish to implement this would first have to create a library - for performing such tasks, mapping generally between conventions, - i.e. map and rotate coordinate systems at the parser level. - - The unfortunate situation in EBSD is that due to historical reasons - and competitive strategies, different players in the field have - implemented (slightly) different approaches each of which misses - some part of a complete workflow description which is behind EBSD analyses: - Sample preparation, measurement, indexing, post-processing, paper... - - The here exemplified default plot do not so far apply relevant rotations - but takes the orientation values as they come from the origin and using - coloring them as they come. It is thus the scientists responsibility to - enter and check if the respective dataset is rotation-conventions-wise - consistent and fit for a particular task. - - Ideally, with all conventions defined it can be possible to develop - a converter which rotates the input data. This application definition - does not assume this and users should be aware of this limitation. - - The key point is that the conventions however are captured and this is - the most important step to the development of such a generic transcoder - for creating interoperable EBSD datasets. - - Currently the conventions remain in the mind or manual lab book of the - respective scientists or technicians instead of getting stored and - communicated with research papers that are written based on - specific dataset, i.e. database entries. - - The default gridded representation of the data should not be - misinterpreted as the only possible way how EBSD data and OIM - maps can be created! - - Indeed, the most general case is that patterns are collected for - scan points. The scan generator of an electron microscope is instructed - to steer the beam in such a way across the specimen surface that the - beam illuminates certain positions for a certain amount time (usually - equally-spaced and spending about the same amount of time at each - position). - - Therefore, scan positions can be due to such regular flight plans and - represent sampling on lines, line stacks, rectangular regions-of- - interests, but also could instruct spiral, random, or adaptive scans - instead of tessellations with square or hexagonal pixels. - - The majority of EBSD maps is though is reporting results for a regular - grid (square, hexagon). What matters though in terms of damage induced - by the electron beam and signal quality is the real electron dose - history, i.e. for how long the beam exposed which location of the - specimen. Especially when electron charging occurs (i.e. an excess - amount of charge accumulates due to e.g. poor conducting away of this - charge or an improper mounting, too high dose, etc. such details are - relevant. - - Specifically, the default visualization is an inverse pole-figure (IPF) - map with the usual RGB color coding. Different strategies and - normalization schemes are in use to define such color coding. - - Finally, we should mention that each ipf_map represents data for - scan points indexed as one phase. The alias/name of this phase should - be stored in phase_name, the phase_identifier give an ID which must - not be zero as this value is reserved for non-indexed / null model scan - points. + Descriptor values. - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - - - Which IPF definition computation according to backend. - - - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the x axis - - - - - - - For each stereographic standard triangle (SST), i.e. a rendering of - the fundamental zone of the crystal-symmetry-reduced orientation space SO3, - it is possible to define a color model which assigns each point in - the fundamental zone a color. - Different mapping models are in use and implement (slightly) different - scaling relations. Differences are which base colors of the RGB - color model are placed in which extremal position of the SST - and where the white point is located. For further details see: - - * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the em_om - parsers takes a rasterized image which is rendered by the backend - tool. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - - - - - - This application definition also enables to describe a workflow where several - EBSD datasets are not only documented but also correlated based on time, - position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - - - - - - - - - + + + - An overview of the entire reconstructed volume. For details about - what defines the image contrast inspect descriptor. + Calibrated coordinate along the y-axis. - + + + + - Descriptor representing the image contrast. + Label for the y axis - - - - - Container holding a default plot of the reconstructed volume. - - - - - - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Signal - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - Calibrated center of mass of the pixel along the fast axis. - - - - - - - Label for the y axis - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - + + + - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - The same comments apply as to the two-dimensional representation. + Calibrated coordinate along the x-axis. - - - Specifying which phase this IPF mapping visualizes. - - - - - Alias/name for the phase whose indexed scan points are displayed. - - - + + + + - Which IPF definition computation according to backend. + Label for the x axis - - - - - Along which axis to project? Typically [0, 0, 1] is chosen. - - - - - - - - Bitdepth used for the RGB color model. Usually 8 bit. - - - - - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - - - - - - - - - The RGB image which represents the IPF map. - - - - - - - - - - RGB array, with resolution per fastest changing value - defined by bitdepth. - - - - - - - - - - - IPF color-coded orientation mapping - - - - - - Calibrated center of mass of the pixel along the slow axis. - - - - - - - Label for the z axis - - - - - - - Calibrated center of mass of the pixel along the faster axis. - - - - - - - Label for the y axis - - - - - - - Calibrated center of mass of the pixel along the fastest axis. - - - - - - - Label for the x axis - - - - - - - Same comments as for the two-dimensional case apply. - - - - - - - - - - RGB array, with resolution per fastest changing value defined by bitdepth. - - - - - - - - - - IPF color key in stereographic standard triangle (SST) - - - - - - Pixel coordinate along the slow axis. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the fast axis. - - - - - - - Label for the x axis - - - - - + + - - diff --git a/contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml b/contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml deleted file mode 100644 index 48a053c833..0000000000 --- a/contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml +++ /dev/null @@ -1,224 +0,0 @@ - - - - - - - - Number of reflectors (Miller crystallographic plane triplets). - - - - - Number of atom positions. - - - - - Crystal structure phase models used for indexing Kikuchi pattern. - - This base class contains key metadata relevant to every physical - kinematic or dynamic diffraction model to be used for simulating - Kikuchi diffraction pattern. - The actual indexing of Kikuchi pattern however maybe use different - algorithms which build on these simulation results but evaluate different - workflows of comparing simulated and measured Kikuchi pattern to make - suggestions which orientation is the most likely (if any) for each - scan point investigated. - - Traditionally Hough transform based indexing has been the most frequently - used algorithm. More and more dictionary based alternatives are used. - Either way both algorithm need a crystal structure model. - - - - - Identifier of an entry from crystallographic_database which was used - for creating this structure model. - - - - - Name of the crystallographic database to resolve - crystallographic_database_identifier e.g. COD or others. - - - - - - Crystallography unit cell parameters a, b, and c. - - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma. - - - - - - - - Volume of the unit cell - - - - - Crystallographic space group - - - - - - True if space group is considered a centrosymmetric one. - False if space group is considered a non-centrosymmetric one. - Centrosymmetric has all types and combinations of symmetry elements - (translation, rotational axis, mirror planes, center of inversion) - Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). - Chiral compared to non-centrosymmetric is constrained (no mirror planes). - - - - - True if space group is considered a chiral one. - False if space group is consider a non-chiral one. - - - - - Laue group - - - - - - Point group using International Notation. - - - - - - Crystal system - - - - - - - - - - - - - - Numeric identifier for each phase. - The value 0 is reserved for the unknown phase essentially representing the - null-model that no phase model was sufficiently significantly confirmed. - Consequently, the value 0 must not be used as a phase_identifier. - - - - - Name of the phase/alias. - - - - - Labels for each atom position - - - - - - - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - Atom positions x, y, z. - - - - - - - - - - Relative occupancy of the atom position. - - - - - - - - How many reflectors are distinguished. Value has to be n_hkl. - - - - - - Miller indices :math:`(hkl)`. - - - - - - - - - D-spacing. - - - - - - - - Relative intensity of the signal for the plane. - - - - - - - diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml new file mode 100644 index 0000000000..735bfe8979 --- /dev/null +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -0,0 +1,144 @@ + + + + + + + + + + Number of pixel along the y direction, the slow direction + + + + + Number of pixel along the x direction, the fast direction + + + + + Number of X-ray photon energy (bins), the fastest direction. + + + + + Number of identified elements + + + + + Number of peaks detected + + + + + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. + + + + + Details about computational steps how peaks were indexed as elements. + + + + The program with which the indexing was performed. + + + + + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + + + + + Associated lower :math:`[e_{min}, e_{max}]` bounds of the + energy which is assumed associated with this peak. + + + + + + + + Theoretical energy of the line according to IUPAC. + + + + + IUPAC notation identifier of the line which the peak represents. + + This can be a list of IUPAC notations for (the seldom) case that + multiple lines are grouped with the same peak. + + + + + + + + + + List of the names of identified elements. + + + + + + + + Individual element-specific EDS/EDX/EDXS/SXES mapping + + A composition map is an image whose intensities for each pixel are the + accumulated X-ray quanta *under the curve(s)* of a set of peaks. + + These element-specific EDS maps are NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + + + + + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + + + + + + + + + + diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml new file mode 100644 index 0000000000..c355f6fd62 --- /dev/null +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -0,0 +1,79 @@ + + + + + + + + Number of electron energy loss bins. + + + + + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). + + + + + NXspectrum_set_em specialized for EELS. + + + + + + + + + + Energy loss. + + + + + + + + + Energy loss. + + + + + + + Energy loss. + + + + + + + diff --git a/contributed_definitions/NXem_img.nxdl.xml b/contributed_definitions/NXem_img.nxdl.xml new file mode 100644 index 0000000000..ebf17380a6 --- /dev/null +++ b/contributed_definitions/NXem_img.nxdl.xml @@ -0,0 +1,63 @@ + + + + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Base class for method-specific generic imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). Examples can be single point aka spot + measurements, line profiles, or (rectangular) surface mappings. + The latter pattern is the most frequently used. + + For now the base class provides for scans for which the settings, + binning, and energy resolution is the same for each scan point. + + + + Which imaging mode was used? + + + + + + + + diff --git a/contributed_definitions/NXem_method.nxdl.xml b/contributed_definitions/NXem_method.nxdl.xml new file mode 100644 index 0000000000..086d4833d2 --- /dev/null +++ b/contributed_definitions/NXem_method.nxdl.xml @@ -0,0 +1,47 @@ + + + + + + + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. + + + + Details about processing steps. + + + + + + + diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml new file mode 100644 index 0000000000..a6442b1e2e --- /dev/null +++ b/contributed_definitions/NXem_msr.nxdl.xml @@ -0,0 +1,96 @@ + + + + + + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. + + + + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + + + + Given name of the microscope at the hosting institution. + This is an alias. Examples could be NionHermes, Titan, JEOL, + Gemini, etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + Description of the type of the detector. + + Electron microscopes have typically multiple detectors. + Different technologies are in use like CCD, scintillator, + direct electron, CMOS, or image plate to name but a few. + + + + Instrument-specific alias/name + + + + + + + + + + diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml new file mode 100644 index 0000000000..f5f10b1b95 --- /dev/null +++ b/contributed_definitions/NXem_sim.nxdl.xml @@ -0,0 +1,60 @@ + + + + + + + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. + + + + Details about the simulation. + + + + + + + diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml index 2127e9b84d..507c588ab4 100644 --- a/contributed_definitions/NXevent_data_em.nxdl.xml +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -1,9 +1,9 @@ - + - + - Metadata and settings of an electron microscope for scans and images. - - The need for such a structuring of data is evident from the fact that - electron microscopes are dynamic. Oftentimes it suffices to calibrate the - instrument at the start of the session. Subsequently, data (images, spectra, etc.) - can be collected. Users may wish to take only a single scan or image and - complete their microscope session; however - - frequently users are working much longer at the microscope, recalibrate and take - multiple data items (scans, images, spectra). Each item comes with own detector - and eventually on-the-fly processing settings and calibrations. - - For the single data item use case one may argue that the need for an additional - grouping is redundant. Instead, the metadata could equally be stored inside - the respective groups of the top-level mandatory NXinstrument group. - On the flip side, even for a session with a single image, it would also not - harm to nest the data. - - In fact, oftentimes scientists feel that there is a need to store details - about eventual drift of the specimen in its holder (if such data is available) - or record changes to the lens excitations or apertures used and/or changed. - Although current microscopes are usually equipped with stabilization - systems for many of the individual components, it can still be useful - to store time-dependent data in detail. - - Another reason if not a need for having more finely granularizable options for - storing time-dependent data, is that over the course of a session one may - reconfigure the microscope. What is a reconfiguration? This could be the - change of an aperture mode because a scientist may first collect an image - with some aperture and then pick a different value and continue. - As the aperture affects the electron beam, it will affect the system. - - Let aside for a moment the technology and business models, an EM could be - monitored (and will likely become so more in the future) for streaming out - spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied - and the specimen repositioned. - - Some snapshot or integrated data from this stream are relevant for understanding - signal genesis and electron/ion-beam-sample interaction (paths). In such a generic - case it might be necessary to sync these streaming data with those intervals - in time when specific measurements are taken (spectra collected, - images taken, diffraction images indexed on-the-fly). - - Therefore, both the instrument and specimen should always be considered as dynamic. - Scientists often report or feel (difficult to quantify) observations that - microscopes *perform differently* across sessions, without sometimes being - able to identify clear root causes. Users of the instrument may consider - such conditions impractical, or *too poor* and thus either abort their session - or try to bring the microscope first into a state where conditions are considered - more stable, better, or of some whatever high enough quality to reuse - data collection. - - In all these cases it is practical to have a mechanism how time-dependent data - of the instrument state can be stored and documented in a interoperable way. - Where should these data be stored? With NeXus these data should not only be - stored in the respective instrument component groups of the top-level NXinstrument. - The reason is that this group should be reserved for as stable as possible - quantities which do not change over the session. Thereby we can avoid to store - repetitively that there is a certain gun or detector available but just store - the changes. This is exactly what the em_lab group is for inside NXevent_data_em. - - Ideally, NXevent_data_em are equipped with a start_time and end_time - to represent a time interval (remind the idea of the instrument state stream) - during which the scientist considered (or practically has to consider) - the microscope (especially ebeam and specimen) as stable enough. + Base class to store state and (meta)data of events with an electron microscopy. + + Electron microscopes are dynamic. Scientists often report that microscopes + *perform differently* across sessions, that they perform differently from + one day or another. In some cases, root causes for performance differences + are unclear. Users of the instrument may consider such conditions impractical, + or *too poor*, and thus abort their session. Alternatively, users may try to + bring the microscope into a state where conditions are considered better + or of whatever high enough quality for continuing the measurement. + + In all these use cases in practice it would be useful to have a mechanism + whereby time-dependent data of the instrument state can be stored and + documented with an interoperable representation. Indeed, how a session on an + electron microscope is spent depends strongly on the research question, + the user, and the imaging modalities used. + + :ref:`NXevent_data_em` represents an instance to describe and serialize flexibly + whatever is considered a time interval during which the instrument is + considered as stable enough for performing a task with the microscope. + Examples of such tasks are the collecting of data (images and spectra) or + the calibrating of some component of the instrument. Users may wish to take + only a single scan or image and complete their microscope session thereafter. + Alternatively, users are working for much longer time at the microscope, + perform recalibrations in between and take several scans (of different + regions-of-interest of the specimen), or they explore the state of the + microscope for service or maintenance tasks. + + :ref:`NXevent_data_em` serves the harmonization and documentation of this situation + with providing three key sections: Firstly, there is a header section whose + purpose is to contextualize and identify the event instance in time. + Secondly, there is a data and metadata section where individual data collections + can be stored using a standardized representation. + Finally, there is a section called em_lab which mirrors the structure of the + em_lab(NXinstrument) section in :ref:`NXem_base`. + + The idea of the first, the event-based em_lab section, is to document the + state of the microscope as it was during the event. The idea of the other, + the NXem application based em_lab(NXinstrument) section is to keep all those + pieces of information which are static in the sense that they are the same + across multiple :ref:`NXevent_data_em` instance. This reduces the amount of pieces of + information that have to be stored repetitively. + + We are aware of the fact that given the variety how an electron microscope + is used, there is a need for a flexible and adaptive documentation system. + At the same time we are also convinced though that just because one has + different requirements for some specific aspect under the umbrella of settings + to an electron microscope, this does not necessarily warrant that one has to + cook up an own schema. + + Instead, the electron microscopy community should work towards reusing schema + components as frequently as possible. This will enable that there is at all + not only a value of harmonizing electron microscopy research content but also + the technical possibility to build services around such harmonized + pieces of information. Arguably it is oftentimes tricky to specify a clear time interval when the - microscope is stable enough. Take for instance the acquisition of an image - or spectra stack. It is not fully possible (technically) to avoid that even - within a single image instabilities of the beam are faced and drift occurs. - Maybe in many cases this these instabilities are irrelevant but does this - warrant to create a data schema where either the microscope state can only - be stored very coarsely or one is forced to store it very finely? + microscope is *stable enough*. Take for instance the acquisition of an image + or a stack of spectra. Having to deal with instabilities is a common theme in + electron microscopy practice. Numerical protocols can be used during data + post-processing to correct for some of the instabilities. + A few exemplar references to provide an overview on the subject is + available in the literature: - This is a question of how one wishes to granularize pieces of information. - A possible solution is to consider each probed position, i.e. point in time - when the beam was not blanked and thus when the beam illuminates a portion of - the material, i.e. the interaction volume, whose signal contributions are then - counted by the one or multiple detector(s) as per pixel- or per voxel signal - in the region-of-interest. - NXevent_data_em in combination with the NXem application definition - allows researchers to document this. Noteworty to mention is that we understand - that in many cases realizing such a fine temporal and logical granularization - and data collection is hard to achieve in practice. - - A frequently made choice, mainly for convenience, is that drift and scan distortions - are considered a feature or inaccuracy of the image and/or spectrum and thus - one de facto accepts that the microscope was not as stable as expected during - the acquisition of the image. We learn that the idea of a time interval - during the microscope session may be interpreted differently by different - users. Here we consider the choice to focus on images and spectra, and eventually - single position measurements as the smallest granularization level. - Which eventually may require to add optional NXprocess instances for respectively - collected data to describe the relevant distortions. Nevertheless, the distortions - are typically corrected for by numerical protocols. This fact warrants to - consider the distortion correction a computational workflow which can be - modelled as a chain of NXprocess instances each with own parameters. an own - A more detailed overview of such computational steps to cope with scan distortions - is available in the literature: - - * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ - * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ - * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ + * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ + * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ + * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ For specific simulation purposes, mainly in an effort to digitally repeat - or simulate the experiment, it is tempting to consider dynamics of the - instrument, implemented as time-dependent functional descriptions of - e.g. lens excitations, beam shape functions, trajectories of groups of - electrons, or detector noise models. - - For now the preferred strategy to handle these cases is through - customizations of the specific fields within NXevent_data_em instances. - - Another alternative could be to sample finer, eventually dissimilarly along - the time axi; however this may cause situations where an NXevent_data_em - instance does not contain specific measurements (i.e. images, spectra of - scientific relevance). - - In this case one should better go for a customized application definition - with a functional property description inside members (fields or groups) - in NXevent_data_em instances; or resort to a specific offspring application - definition of NXem which documents metadata for tracking explicitly electrons - (with ray-tracing based descriptors/computational geometry descriptors) - or tracking of wave bundles. - - This perspective on much more subtle time-dependent considerations of electron - microscopy can be advantageous also for storing details of time-dependent - additional components that are coupled to and/or synced with a microscope. - - Examples include cutting-edge experiments where the electron beam gets - coupled/excited by e.g. lasers. In this case, the laser unit should be - registered under the top-level NXinstrument section. Its spatio-temporal - details could be stored inside respective additional groups of the NXinstrument - though inside instances of here detailed NXevent_data_em. + or simulate the experiment, it is tempting to consider dynamics of the instrument, + implemented as time-dependent functional descriptions of e.g. lens excitations, + beam shape functions, trajectories of groups of electrons and ions, + or detector noise models. This warrants to document the time-dependent + details of individual components of the microscope + as is implemented in :ref:`NXevent_data_em`. @@ -174,53 +114,58 @@ when the snapshot time interval ended. - + - Reference to a specific state and setting of the microscope. + Identifier of a specific state and setting of the microscope. - + Which specific event/measurement type. Examples are: - * In-lens/backscattered electron, usually has quadrants - * Secondary_electron, image, topography, fractography, overview images - * Backscattered_electron, image, Z or channeling contrast (ECCI) - * Bright_field, image, TEM - * Dark_field, image, crystal defects - * Annular dark field, image (medium- or high-angle), TEM - * Diffraction, image, TEM, or a comparable technique in the SEM - * Kikuchi, image, SEM EBSD and TEM diffraction - * X-ray spectra (point, line, surface, volume), composition EDS/EDX(S) - * Electron energy loss spectra for points, lines, surfaces, TEM - * Auger, spectrum, (low Z contrast element composition) - * Cathodoluminescence (optical spectra) - * Ronchigram, image, alignment utility specifically in TEM - * Chamber, e.g. TV camera inside the chamber, education purposes. + * In-lens/backscattered electron, usually has quadrants + * Secondary_electron, image, topography, fractography, overview images + * Backscattered_electron, image, Z or channeling contrast (ECCI) + * Bright_field, image, TEM + * Dark_field, image, crystal defects + * Annular dark field, image (medium- or high-angle), TEM + * Diffraction, image, TEM, or a comparable technique in the SEM + * Kikuchi, image, SEM EBSD and TEM diffraction + * X-ray spectra (point, line, surface, volume), composition EDS/EDX(S) + * Electron energy loss spectra for points, lines, surfaces, TEM + * Auger, spectrum, (low Z contrast element composition) + * Cathodoluminescence (optical spectra) + * Ronchigram, image, alignment utility specifically in TEM + * Chamber, e.g. TV camera inside the chamber, education purposes. + + This field may also be used for storing additional information + about the event. For which there is at the moment no other place. - This field may also be used for storing additional information about the event. + In the long run such free-text field description should be avoided as + they are difficult to machine-interpret. Instead, reference should be given + to refactoring these descriptions into structured metadata. + The reason why in this base class the field event_type is nonetheless kept + is to offer a place whereby practically users may enter data for + follow-up modifications to support arriving at an improved :ref:`NXevent_data_em` base class. - + + + - + + + (Meta)data of the dynamics and changes of the microscope during the event. + + + + + + + + + + - diff --git a/contributed_definitions/NXevent_data_em_set.nxdl.xml b/contributed_definitions/NXevent_data_em_set.nxdl.xml index c722947267..7a32ff1691 100644 --- a/contributed_definitions/NXevent_data_em_set.nxdl.xml +++ b/contributed_definitions/NXevent_data_em_set.nxdl.xml @@ -1,9 +1,9 @@ - + - + - Container to hold NXevent_data_em instances of an electron microscope session. + Base class for a set of :ref:`NXevent_data_em` instances. - An event is a time interval during which the microscope was configured, - considered stable, and used for characterization. + Members of the set are instances of :ref:`NXevent_data_em`. These have an associated + time interval during which the conditions were considered stable and + fit enough for purpose. + + Which temporal granularity is adequate depends on the situation and + research question. Using a model which enables a collection of events offers + the most flexible way to cater for both experiments with controlled electron + beams in a real microscope or the simulation of such experiments or + individual aspects of such experiments. + + diff --git a/contributed_definitions/NXfabrication.nxdl.xml b/contributed_definitions/NXfabrication.nxdl.xml index 169959754a..bde2133910 100644 --- a/contributed_definitions/NXfabrication.nxdl.xml +++ b/contributed_definitions/NXfabrication.nxdl.xml @@ -1,9 +1,9 @@ - + - + - Details about a component as defined by its manufacturer. + Details about a component as it is defined by its manufacturer. - + Company name of the manufacturer. - + Version or model of the component named by the manufacturer. - + Ideally, (globally) unique persistent identifier, i.e. a serial number or hash identifier of the component. - + Free-text list with eventually multiple terms of functionalities which the component offers. - diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 9a0ebfca19..6241bd99bc 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -1,9 +1,9 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -33,9 +33,19 @@ - A set of (eventually directed) edges which connect nodes/vertices of a graph. + A set of (eventually directed) edges which connect nodes of a graph. + + Use as a direct child of an instance of :ref:`NXgraph_root`. + Alternatively, use depends_on to specify which instance + of :ref:`NXgraph_root` is defined by this instance. - + + + Specify which instance of :ref:`NXgraph_root` this :ref:`NXgraph_edge_set` + refers to. + + + Total number of edges, counting eventual bidirectional edges only once. @@ -43,14 +53,13 @@ Integer which specifies the first index to be used for distinguishing - edges. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. + edges. Identifiers are defined either implicitly or explicitly. - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. + For implicit indexing the identifiers are defined on the interval + :math:`[identifier_offset, identifier_offset + c - 1]`. + + For explicit indexing use the field identifier. For implicit indexing, + consult :ref:`NXcg_primitive_set` to get guidance how to set identifier_offset. @@ -61,7 +70,7 @@ - + Specifier whether each edge is non-directional, one-directional, or bidirectional. Use the smallest available binary representation @@ -77,34 +86,33 @@ - Pairs of node/vertex identifier. Each pair represents the connection - between two nodes. + Pairs of node/vertex identifier. Each pair represents the connection + between two nodes. The order in the pair encodes eventual directionality. - In the case that the edge is non- or bi-directional - node identifier should be stored in ascending order is preferred. + In the case that an edge is non- or bi-directional, storing + node identifier in ascending order is preferred. - In the case of one-directional, for each pair the identifier of the source - node is the first entry in the pair. The identifier of the target is the - second entry in the pair, i.e. the pair encodes the information as - if one traverses the edge from the source node walking to the target node. + In the case that an edge is one-directional, node identifier should be + stored such that the identifier of the source node is the first entry + and the identifier of the target is the second entry in the pair. - + A human-readable qualifier which type or e.g. class instance the edge is an instance of. - + - + - A human-readable label/caption/tag for the edge. + A human-readable label/caption/tag of each edge. diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index afd24d2c69..ae11bd09f7 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -1,9 +1,9 @@ - + - - + The symbols used in the schema to specify e.g. dimensions of arrays. - + - The dimensionality of the graph. Eventually use one for categorical. + The cardinality of the set, i.e. the number of nodes of the graph. - + - The cardinality of the set, i.e. the number of nodes/vertices of the graph. + The dimensionality of the graph. Eventually use one for categorical. - A set of nodes/vertices in space representing members of a graph. + A set of nodes representing members of a graph. + + Use as a direct child of an instance of :ref:`NXgraph_root`. + Alternatively, use depends_on to specify which instance + of NXgraph_root is defined by this instance. - - + + + Specify which instance of :ref:`NXgraph_root` this :ref:`NXgraph_node_set` + refers to. + + + + + About which space does the graph make statements. + + + + + + + + + Dimensionality of the space about which the graph makes statements. + Use only when value of the field space is euclidean. + + + + + + + + + + Number of nodes of the graph. + + Integer which specifies the first index to be used for distinguishing - nodes. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. + nodes. Identifiers are defined either implicitly or explicitly. + + For implicit indexing the identifiers are defined on the interval + :math:`[identifier_offset, identifier_offset + c - 1]`. - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. + For explicit indexing use the field identifier. For implicit indexing, + consult :ref:`NXcg_primitive_set` to get guidance how to set identifier_offset. @@ -64,26 +95,24 @@ - + A human-readable qualifier which type or e.g. class instance the - node is an instance of. As e.g. a NeXus application definition is a - graph, more specifically a hierarchical directed labelled property graph, - instances which are groups like NXgraph_node_set could have an is_a - qualifier reading NXgraph_node_set. + node is an instance of. An example: a NeXus application definition is a + graph, more specifically a hierarchical directed labelled property graph. + Instances which are groups like :ref:`NXgraph_node_set` could have an is_a + qualifier reading :ref:`NXgraph_node_set`. - + - A human-readable label/caption/tag of the graph. + A human-readable label/caption/tag of each node. - diff --git a/contributed_definitions/NXgraph_root.nxdl.xml b/contributed_definitions/NXgraph_root.nxdl.xml index 48fd163d8b..479f106753 100644 --- a/contributed_definitions/NXgraph_root.nxdl.xml +++ b/contributed_definitions/NXgraph_root.nxdl.xml @@ -1,9 +1,9 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -32,5 +32,4 @@ - diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml index bbf4f13e06..f5feaa61ae 100644 --- a/contributed_definitions/NXibeam_column.nxdl.xml +++ b/contributed_definitions/NXibeam_column.nxdl.xml @@ -1,9 +1,9 @@ - + - - + + + - Container for components of a focused-ion-beam (FIB) system. + Base class for a set of components equipping an instrument with FIB capabilities. - FIB capabilities turn especially scanning electron microscopes - into specimen preparation labs. FIB is a material preparation - technique whereby portions of the sample are illuminated with a - focused ion beam with controlled intensity intense enough and with - sufficient ion momentum to remove material in a controllable manner. + Focused-ion-beam (FIB) capabilities turn especially scanning electron microscopes + into specimen preparation labs. FIB is a material preparation technique whereby + portions of the sample are illuminated with a focused ion beam with controlled + intensity. The beam is intense enough and with sufficient ion momentum to + remove material in a controlled manner. The fact that an electron microscope with FIB capabilities has needs a - second gun with own relevant control circuits, focusing lenses, and - other components, warrants an own base class to group these components - and distinguish them from the lenses and components for creating and - shaping the electron beam. + second gun with own relevant control circuits, focusing lenses, and other + components, warrants the definition of an own base class to group these + components and distinguish them from the lenses and components for creating + and shaping the electron beam. For more details about the relevant physics and application examples consult the literature, for example: - * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ - * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ - * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ + * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ + * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ + * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ + The source which creates the ion beam. - + Given name/alias for the ion gun. - + Emitter type used to create the ion beam. @@ -71,7 +76,7 @@ - + Ideally, a (globally) unique persistent identifier, link, or text to a resource which gives further details. @@ -80,33 +85,42 @@ Which ionized elements or molecular ions form the beam. - Examples are gallium, helium, neon, argon, krypton, + Examples are gallium, helium, neon, argon, krypton, or xenon, O2+. - - + + + Average/nominal flux + + + Average/nominal brightness - + Charge current - + + + Ion acceleration voltage upon source exit and + entering the vacuum flight path. + + + - Ion acceleration voltage upon source exit and entering the vacuum flight path. + To be defined more specifically. Community suggestions are welcome. - - Affine transformation which detail the arrangement in the microscope relative to - the optical axis and beam path. + Collection of axis-based translations and rotations to describe the + location and geometry of the component in the instrument. @@ -114,31 +128,29 @@ NEW ISSUE: (at which location?).--> relevant from maintenance point of view--> - + Individual characterization results for the position, shape, and characteristics of the ion beam. - NXtransformations should be used to specify the location or position + :ref:`NXtransformations` should be used to specify the location or position at which details about the ion beam are probed. - +doc: | +A right-handed Cartesian coordinate system is used whose positive +z-axis points in the direction of the ion beam, i.e. towards the +sample. For modelling ion milling it is relevant to document the +illumination vector. NXtransformations offers a place to store how the +ion gun coordinate system has to be rotated to align its positive z-axis +with the positive z-axis of e.g. the electron beam and ion beam +respectively.--> diff --git a/contributed_definitions/NXimage_c_set.nxdl.xml b/contributed_definitions/NXimage_c_set.nxdl.xml new file mode 100644 index 0000000000..64c945c99e --- /dev/null +++ b/contributed_definitions/NXimage_c_set.nxdl.xml @@ -0,0 +1,247 @@ + + + + + + + + Number of images in the (hyper)stack. + + + + + Number of pixel per image in the slowest direction. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Specialized base class container for reporting a set of images in reciprocal space. + + In practice, complex numbers are encoded via some formatted pair of real values. + Typically, fast Algorithms for computing Fourier Transformations (FFT) are + used to encode images in reciprocal (frequency) space. FFT libraries are used + for implementing the key functionalities of these mathematical operations. + + Different libraries use different representations and encoding of the + image computed. Details can be found in the respective sections of the + typical FFT libraries: + + * `FFTW by M. Frigo and S. G. Johnson <https://www.fftw.org/fftw3_doc/Tutorial.html#Tutorial>`_ + * `Intel MKL by the Intel Co. <https://www.intel.com/content/www/us/en/docs/onemkl/developer-reference-c/2023-0/fourier-transform-functions.html>`_ + * `cuFFT by the NVidia Co. <https://docs.nvidia.com/cuda/cufft/index.html>`_ + + Users are strongly advised to inspect carefully which specific conventions + their library uses to be able to store and modify the implementation of their + code so that the serialized representations as it is detailed + here for NeXus matches with their intention. + + One- and two-dimensional FFTs should use the stack(NXdata) instances. + Three-dimensional FFTs should use the hyperstack(NXdata) instances. + + + + + Image stack. + + + + Image intensity of the real part. + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + + + Image hyperstack. + + + + Image intensity of the real part. + + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center along k direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + diff --git a/contributed_definitions/NXimage_r_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml new file mode 100644 index 0000000000..3ef371809d --- /dev/null +++ b/contributed_definitions/NXimage_r_set.nxdl.xml @@ -0,0 +1,100 @@ + + + + + + + + Number of images in the stack. + + + + + Number of pixel per image in the slow direction. + + + + + Number of pixel per image in the fast direction. + + + + + Specialized base class container for reporting a set of images in real space. + + + + + Image (stack). + + + + Image intensity values. + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center along y direction. + + + + + + + Coordinate along y direction. + + + + + + Pixel coordinate center along x direction. + + + + + + + Coordinate along x direction. + + + + + diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml new file mode 100644 index 0000000000..c9ff02c0d9 --- /dev/null +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -0,0 +1,179 @@ + + + + + + + + Number of scanned points. Scan point may have none, one, or more pattern. + + + + + Number of diffraction pattern. + + + + + Number of pixel per pattern in the slow direction. + + + + + Number of pixel per pattern in the fast direction. + + + + + Base class specialized for reporting a cuboidal stack of diffraction pattern. + + Diffraction pattern, whether they were simulated or measured are the raw data + for computational workflows to characterize the phase and orientation + of crystalline regions in matter. + + Steps of post-processing the diffraction patterns should be documented using + method-specific specialized base classes. All eventual post-processing of + resulting orientation maps (2D or 3D) should be documented via :ref:`NXms_recon`. + + To implement an example how this base class can be used we focused in FAIRmat + on Kikuchi diffraction pattern here specifically the research community + of Electron Backscatter Diffraction (EBSD). + + For this reason, this base class and related :ref:`NXem_base` classes extend the + work of `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ + (one of the developers of DREAM.3D) and the H5OINA public file format developed by + `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ with Oxford Instruments. + + Kikuchi pattern are typically collected with FIB/SEM microscopes, + for two- and three-dimensional orientation microscopy. + + For a detailed overview of these techniques see e.g. + + * `M. A. Groeber et al. <https://doi.org/10.1186/2193-9772-3-5>`_ + * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ + * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ + + Serial-sectioning demands a recurrent sequence of ion milling and measuring. + This suggests that each serial section is at least an own NXevent_data_em + instance. The three-dimensional characterization as such demands a computational + step where the maps for each serial section get cleaned, aligned, and registered + into an image stack. This image stack represents a digital model of the + inspected microstructural volume. Often this volume is called a (representative) + volume element (RVE). Several software packages exists for performing + these post-processing tasks. + + This example may inspire users of other types of diffraction methods. + + + + Category which type of diffraction pattern is reported. + + + + + + + + Collected diffraction pattern as an image stack. As raw and closest to the + first retrievable measured data as possible, i.e. do not use this + container to store already averaged, filtered or whatever post-processed + pattern unless these are generated unmodifiably in such manner by the + instrument given the way how the instrument and control software + was configured for your microscope session. + + + + Array which resolves the scan point to which each pattern belongs. + + Scan points are evaluated in sequence starting from scan point zero + until scan point n_sc - 1. Evaluating the cumulated of this array + decodes which pattern in intensity belongs to which scan point. + + Take an example with three scan points: The first scan point has one + pattern, the second has three pattern, the last scan point has no + pattern. In this case the scan_point_identifier are 0, 1, 1, 1. + The length of the scan_point_identifier array is four because four + pattern were measured in total. + + In most cases usually one pattern is averaged by the detector for + some amount of time and then reported as one pattern. + + + + + + + + Intensity of the diffraction pattern. + + + + + + + + + + Pattern intensity + + + + + + + Pattern are enumerated starting from 0 to n_p - 1. + + + + + + + Pattern identifier + + + + + + + diff --git a/contributed_definitions/NXimage_set.nxdl.xml b/contributed_definitions/NXimage_set.nxdl.xml index 9643dc936d..9a46bcc64f 100644 --- a/contributed_definitions/NXimage_set.nxdl.xml +++ b/contributed_definitions/NXimage_set.nxdl.xml @@ -1,9 +1,9 @@ - + - + @@ -40,89 +40,36 @@ - Container for reporting a set of images taken. + Base class for reporting a set of images. + + This class provides a base vocabulary to be used for specialized :ref:`NXimage_set` + base classes like :ref:`NXimage_r_set` and :ref:`NXimage_c_set`. - Details how images were processed from the detector readings. + Details how NXdata instance inside instance of (specialized) + :ref:`NXimage_set` were processed from the detector readings/raw data. - + Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXimage_set were loaded during parsing. + the :ref:`NXdata` instances in this :ref:`NXimage_set` were loaded + during parsing. - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - + + Imaging (data collection) mode of the instrument during acquisition - of the data in this NXimage_set instance. + of the data in this :ref:`NXimage_set` instance. - + - Link or name of an NXdetector instance with which the data were collected. + Link or name of an :ref:`NXdetector` instance with which the data were + collected. - - - Image (stack). - - - - Image intensity values. - - - - - - - - - - Image identifier - - - - - - - Image identifier. - - - - - - Pixel coordinate center of mass along y direction. - - - - - - - Coordinate along y direction. - - - - - - Pixel coordinate center of mass along x direction. - - - - - - - Coordinate along x direction. - - - - + diff --git a/contributed_definitions/NXimage_set_em_adf.nxdl.xml b/contributed_definitions/NXimage_set_em_adf.nxdl.xml deleted file mode 100644 index 66e439190c..0000000000 --- a/contributed_definitions/NXimage_set_em_adf.nxdl.xml +++ /dev/null @@ -1,156 +0,0 @@ - - - - - - - - Number of images in the stack. - - - - - Number of pixel per image in the slow direction. - - - - - Number of pixel per image in the fast direction. - - - - - Container for reporting a set of annular dark field images. - - Virtually the most important case is that spectra are collected in - a scanning microscope (SEM or STEM) for a collection of points. - The majority of cases use simple d-dimensional regular scan pattern, - such as single point, line profiles, or (rectangular) surface mappings. - The latter pattern is the most frequently used. - - For now the base class provides for scans for which the settings, - binning, and energy resolution is the same for each scan point. - - - - Details how (HA)ADF images were processed from the detector readings. - - - - Typically the name of the input, (vendor) file from which all - the NXdata instances in this NXimage_set_em_adf were loaded during - parsing to represent them in e.g. databases. - - - - An at least as strong as SHA256 hashvalue of the dataset/file - which represents the source digitally to support provenance tracking. - - - - - - Commercial or otherwise given name to the program which was used - to process detector data into the adf image(s). - - - - Program version plus build number, commit hash, or description - of an ever persistent resource where the source code of the program - and build instructions can be found so that the program - can be configured in such a manner that the result file - is ideally recreatable yielding the same results. - - - - - - Annulus inner half angle - - - - - Annulus outer half angle - - - - - - Annular dark field image stack. - - - - - Image intensity values. - - - - - - - - - - Image identifier - - - - - - - Image ID. - - - - - - Pixel center of mass along y direction. - - - - - - - Coordinate along y direction. - - - - - - Pixel center of mass along x direction. - - - - - - - Coordinate along x direction. - - - - - diff --git a/contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml b/contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml deleted file mode 100644 index 7e395cee64..0000000000 --- a/contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml +++ /dev/null @@ -1,205 +0,0 @@ - - - - - - - - Number of scanned points. Scan point may have none, one, or more pattern. - - - - - Number of diffraction pattern. - - - - - Number of pixel per Kikuchi pattern in the slow direction. - - - - - Number of pixel per Kikuchi pattern in the fast direction. - - - - - Measured set of electron backscatter diffraction data, aka Kikuchi pattern. - Kikuchi pattern are the raw data for computational workflows in the field - of orientation (imaging) microscopy. The technique is especially used in - materials science and materials engineering. - - Based on a fuse of the `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ - of the DREAM.3D community and the open H5OINA format of Oxford Instruments - `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ - - EBSD can be used, usually with FIB/SEM microscopes, for three-dimensional - orientation microscopy. So-called serial section analyses. For a detailed - overview of these techniques see e.g. - - * `M. A. Groeber et al. <https://doi.org/10.1186/2193-9772-3-5>`_ - * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ - * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ - - With serial-sectioning this involves however always a sequence of measuring, - milling. In this regard, each serial section (measuring) and milling - is an own NXevent_data_em instance and thus there such a three-dimensional - characterization should be stored as a set of two-dimensional data, - with as many NXevent_data_em instances as sections were measured. - - These measured serial sectioning images need virtually always post-processing - to arrive at the aligned and cleaned image stack before a respective digital - model of the inspected microstructure can be analyzed. The resulting volume - is often termed a so-called (representative) volume element (RVE). - Several software packages are available for performing this post-processing. - For now we do not consider metadata of these post-processing steps - as a part of this base class because the connection between the large variety - of such post-processing steps and the measured electron microscopy data - is usually very small. - - If we envision a (knowledge) graph for EBSD it consists of individual - sub-graphs which convey information about the specimen preparation, - the measurement of the specimen in the electron microscope, - the indexing of the collected Kikuchi pattern stack, - eventual post-processing of the indexed orientation image - via similarity grouping algorithms to yield (grains, texture). - Conceptually these post-processing steps are most frequently - serving the idea to reconstruct quantitatively so-called - microstructural features (grains, phases, interfaces). Materials scientists - use these features according to the multi-scale materials modeling paradigm - to infer material properties. They do so by quantifying correlations between - the spatial arrangement of the features, their individual properties, - and (macroscopic) properties of materials. - - - - - Details how Kikuchi pattern were processed from the detector readings. - Scientists interested in EBSD should inspect the respective NXem_ebsd - application definition which can be used as a partner application definition - to detail substantially more details to this processing. - - - - - Collected Kikuchi pattern as an image stack. As raw and closest to the - first retrievable measured data as possible, i.e. do not use this - container to store already averaged, filtered or whatever post-processed - pattern unless these are generated unmodifiably by the instrument - given the way how the instrument and control software was configured - for your microscope session. - - - - Array which resolves the scan point to which each pattern belongs. - Scan points are evaluated in sequence starting from scan point zero - until scan point n_sc - 1. Evaluating the cumulated of this array - decodes which pattern in intensity belong to which scan point. - In an example we may assume we collected three scan points. For the first - we measure one pattern, for the second we measure three pattern, - for the last we measure no pattern. - The values of scan_point_identifier will be 0, 1, 1, 1, as we have - measured four pattern in total. - - In most cases usually one pattern is averaged by the detector for - some amount of time and then reported as one pattern. Use compressed - arrays allows to store the scan_point_identifier efficiently. - - - - - - - - Signal intensity. For so-called three-dimensional or serial sectioning - EBSD it is necessary to follow a sequence of specimen surface preparation - and data collection. In this case users should collect the data for each - serial sectioning step in an own instance of NXimage_set_em_kikuchi. - All eventual post-processing of these measured data should be documented - via NXebsd, resulting microstructure representations should be stored - as NXms. - - - - - - - - - - Kikuchi pattern intensity - - - - - - - Pattern are enumerated starting from 0 to n_p - 1. - - - - - - - Kikuchi pattern identifier - - - - - - Pixel coordinate along the y direction. - - - - - - - Label for the y axis - - - - - - Pixel coordinate along the x direction. - - - - - - - Label for the x axis - - - - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml index a6beeb6482..59c71c10ef 100644 --- a/contributed_definitions/NXinteraction_vol_em.nxdl.xml +++ b/contributed_definitions/NXinteraction_vol_em.nxdl.xml @@ -1,36 +1,56 @@ - + - + + - Base class for storing details about a modelled shape of interaction volume. + Base class for describing the interaction volume of particle-matter interaction. - The interaction volume is mainly relevant in scanning electron microscopy - when the sample is thick enough so that the beam is unable to illuminate - through the specimen. - Computer models like Monte Carlo or molecular dynamics / electron beam - interaction simulations can be used to qualify and/or quantify the shape of - the interaction volume. + Computer models like Monte Carlo or molecular dynamics / electron- or ion-beam + interaction simulations can be used to qualify and (or) quantify the shape of + the interaction volume. Results of such simulations can be summary statistics + or single-particle resolved sets of trajectories. Explicit or implicit descriptions are possible. - * An implicit description is via a set of electron/specimen interactions - represented ideally as trajectory data from the computer simulation. - * An explicit description is via an iso-contour surface using either - a simulation grid or a triangulated surface mesh of the approximated - iso-contour surface evaluated at specific threshold values. - Iso-contours could be computed from electron or particle fluxes through - an imaginary control surface (the iso-surface). - Threshold values can be defined by particles passing through a unit control - volume (electrons) or energy-levels (e.g. the case of X-rays). - Details depend on the model. - * Another explicit description is via theoretical models which may - be relevant e.g. for X-ray spectroscopy + * An implicit description is via a set of electron/specimen interactions + represented ideally as trajectory data from the computer simulation. + * An explicit description is via an iso-contour surface using either + a simulation grid or a triangulated surface mesh of the approximated + iso-contour surface evaluated at specific threshold values. + Iso-contours could be computed from electron or particle fluxes through + an imaginary control surface (the iso-surface). + Threshold values can be defined by particles passing through a unit control + volume (electrons) or energy-levels (e.g. the case of X-rays). + Details depend on the model. + * Another explicit description is via theoretical models which may + be relevant e.g. for X-ray spectroscopy Further details on how the interaction volume can be quantified is available in the literature for example: - * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ - * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ + * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ + * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ + * `J. F. Ziegler et al. <https://doi.org/10.1007/978-3-642-68779-2_5>`_ diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index 82cd91a10f..78a9db9e99 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -1,9 +1,9 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -40,13 +40,13 @@ Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. - + A unique identifier whereby such an ion can be referred to via the service offered as described in identifier_type. - + How can the identifier be resolved? @@ -56,16 +56,17 @@ - Ion type (ion species) identifier. The identifier zero - is reserved for the special unknown ion type. + Ion type (ion species) identifier. + + The identifier zero is reserved for the special unknown ion type. - A vector of isotope hash values. - These values have to be stored in an array, sorted in decreasing order. - The array is filled with zero hash values indicating unused places. - The individual hash values are built with the following hash function: + A vector of isotope hash values. These values have to be stored in an array, + sorted in decreasing order. The array is filled with zero hash values + indicating unused places. The individual hash values are built with the + following hash function: The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` the number of protons and :math:`N` the number of neutrons @@ -88,9 +89,9 @@ from the isotope_vector this is :math:`Z + N`. As an example for a carbon-14 isotope the number is 14. The second row specifies the number of protons :math:`Z`, e.g. 6 for the - carbon-14 example. This row matrix is thus a mapping the notation of - using superscribed isotope mass and subscripted number of protons to - identify isotopes. + carbon-14 example. This row matrix is thus mapping the notation of + using superscribed isotope mass and subscripted number of protons + to identify isotopes. Unused places filling up to n_ivecmax need to be filled with zero. @@ -98,12 +99,12 @@ - + Color code used for visualizing such ions. - + Assumed volume of the ion. @@ -113,7 +114,7 @@ dataset. - + Charge of the ion. @@ -132,34 +133,32 @@ These file formats do not document the charge state explicitly. They report the number of atoms of each element per molecular ion surplus the mass-to-charge-state-ratio interval. - With this it is possible to recover the charge state only for - specific molecular ions as the accumulated mass of the molecular ion - is defined by the isotopes, which without knowing the charge leads + With this information it is possible to recover the charge state only + for specific molecular ions as the accumulated mass of the molecular ion + is defined by the isotopes, which without knowing the charge, leads to an underconstrained problem. Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - + Human-readable ion type name (e.g. Al +++) - The string should consists of ASCII UTF-8 characters, - ideally using LaTeX notation to specify the isotopes, ions, and charge - state. Examples are 12C + or Al +++. - Although this name may be human-readable and intuitive, parsing such - names becomes impractical for more complicated cases. Therefore, for the - field of atom probe microscopy the isotope_vector should be the - preferred machine-readable format to use. + The string should consists of UTF-8 characters, ideally using LaTeX + notation to specify the isotopes, ions, and charge state. + Examples are 12C + or Al +++. + + To ease automated parsing isotope_vector should be the + preferred machine-readable information used. - + - Associated lower (mqmin) and upper (mqmax) bounds of + Associated lower (mqmin) and upper (mqmax) bounds of the mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries included) for which the respective ion is one to be labelled - with ion_identifier. The field is primarily of interest to document the - result of indexing a ToF/mass spectrum. + (boundaries inclusive). This field is primarily of interest + for documenting :ref:`NXprocess` steps of indexing a ToF/mass-to-charge + state histogram. - diff --git a/contributed_definitions/NXisocontour.nxdl.xml b/contributed_definitions/NXisocontour.nxdl.xml index bd81dc5f69..a54805a64c 100644 --- a/contributed_definitions/NXisocontour.nxdl.xml +++ b/contributed_definitions/NXisocontour.nxdl.xml @@ -1,9 +1,9 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -50,7 +50,15 @@ data could be described with NeXus, provided base classes such as the this one get further extend according to the liking of the phase-field community. - + + + The dimensionality of the space in which the isocontour is embedded. + + + + + + The discretized grid on which the iso-contour algorithm operates. diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml index 2af323f4d5..4f619c79ef 100644 --- a/contributed_definitions/NXlens_em.nxdl.xml +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -1,9 +1,9 @@ - + - + + - Description of an electro-magnetic lens or a compound lens. + Base class for 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 :ref:`NXtransformations` the origin of the coordinate system is placed + in the center of the lens (its polepiece, pinhole, or another + point of reference). The origin should be specified in the :ref:`NXtransformations`. - For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ + For details of electro-magnetic lenses in the literature + see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ - + Qualitative type of lens with respect to the number of pole pieces. @@ -44,59 +47,64 @@ - + Given name, alias, colloquial, or short name for the lens. For manufacturer names and identifiers use respective manufacturer fields. - - - Name of the manufacturer who built/constructed the lens. - - + - + + - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the lens. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the lens. + Ideally an identifier, persistent link, or free text which + gives further details about the lens. - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. + Excitation voltage of the lens. + + For dipoles it is a single number. + For higher order multipoles, it is an array. - Excitation current of the lens. For dipoles it is a single number. For higher - orders, it is an array. + Excitation current of the lens. + + For dipoles it is a single number. + For higher order multipoles, it is an array. - This field should be used when the exact voltage or current of the lens is not directly controllable - as the control software of the microscope does not enable users/or is was not configured to enable - the user to retrieve these values. In this case this field should be used to specify the value as - read from the control software. Although consumers of the application definition should not expect - this value to represent the exact physical voltage or excitation, it is still useful to know though - as it allows other users to reuse this lens setting, which, provided a properly working instrument - and software should bring the lenses into a similar state. + This field should be used when the exact voltage or current of the lens + is not directly controllable as the control software of the microscope + does not enable or was not configured to display these values. + + In this case this value field should be used and the value + from the control software stored as is. + + Although this value does not document the exact physical voltage or + excitation, it can still give useful context to reproduce the lens setting, + which, provided a properly working instrument and software sets the lens + into a similar state to the technical level possible when no more information + is available physically or accessible legally. - + Specifies the position of the lens by pointing to the last transformation in the transformation chain in the NXtransformations group. - + Collection of axis-based translations and rotations to describe the diff --git a/contributed_definitions/NXms.nxdl.xml b/contributed_definitions/NXms.nxdl.xml index cd506fa214..af4e4ff578 100644 --- a/contributed_definitions/NXms.nxdl.xml +++ b/contributed_definitions/NXms.nxdl.xml @@ -1,9 +1,9 @@ - + - - +several viewpoints how to coarse-grain are equally justified: grains are useful when there are crystallites with adjoining interfaces and # none, or only some statistical populations of defects and/or some spatially-well defined defects inside these +however, if grains are build almost only from defects like dislocation walls, it might no longer be useful to define the grains +as a well identifiable region whose majority volume shows long-range atomic periodicity (so that defining an orientation makes) sense. +one could then rather describe the set of defects. Alternatively one could describe a material volume by sampling individual so-called +material points (e.g. in continuum-scale plasticity models) or describe the material volume really from the atoms up +but there are many terms used in materials engineering which people may want to distinguish which stand however between the scales e.g. +lattice curvature, this is jargon with some truth in it but curvature has to be build from atoms and defects need to build the curvature +dislocations are another good example where different research questions demand differently granularized descriptions e.g. +average density, total line length, per character, per family, line length, curvature, jog, kink density, +coarse-grainable structural motifs in the dislocation core, atomic structure +also different scales one would like to distinguish as this is relevant when defects couple/show spatiotemporal correlations +to specific mechanisms (e.g. phonons) or when defect affect the properties of other defects +ambiguous choices: is the grain boundary part of the grain or is it an own defect? +i.e. can/should we store grains as childs of their grain boundary set vs the interface the childs of the grains? +Depending on the use case we need to have a flexible description which can address a continuum of descriptors: +important is that one can logically map different features +Length scale of homogeneity: With the reality of a multi-parameter space of all possible methods and effects and +different external stimuli applied for real materials, simulations in computational materials science typically focus +their analysis on a few individual, spatiotemporally constrained effects and boundary conditions for which the simulation +is formulated, useful, interpretable, and comparable to experiment. +Data structures for multi-scale materials modeling IMM/ICME are currently diverse because they reflect the above-mentioned needs +and different views which researchers have on their simulations e.g. DFT (time, length-scale, which electronic effects) +RVE annealing phenomena at the micrometer scale (pressure, temperature, length scale, interactions considered or not) +Some regions are well separated spatially (although it can be non-trivial to quantify the distance in a multi-dim parameter space) +Some simulations are cross-scale (classical MD at the cutting edge with micrometer crystal plasticity microsecond and/or annealing at +ns time scale) MD with classical vs abinitio-informed potential for studying evolution of mechanisms and phenomena at different length scales--> + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -103,7 +104,7 @@ so-called microstructural features of interest for which we may store also therm Free-text description about the workflow (experiment/analysis/simulation). - Users are strongly advised to detail the sample history in the + Users are strongly advised to detail the sample history in the respective field and fill rather as completely as possible the fields of this application definition rather than write details about the experiment into this free-text description field. @@ -197,7 +198,7 @@ so-called microstructural features of interest for which we may store also therm - Which role does the user have in the place and at the point + 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. @@ -225,16 +226,16 @@ according to SAMPLE.yaml 0f8df14 2022/06/15--> +doc: | +ISO 8601 time code with local time zone offset to UTC information +when the specimen was prepared.--> Hard link to a location in the hierarchy of the NeXus file @@ -250,7 +251,7 @@ preparation_date(NX_DATE_TIME): - + @@ -277,10 +278,12 @@ preparation_date(NX_DATE_TIME): - +interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -444,7 +447,7 @@ specialize--> TO BE DEFINED - + Collection of texture components commonly referred to. diff --git a/contributed_definitions/NXms_feature_set.nxdl.xml b/contributed_definitions/NXms_feature_set.nxdl.xml index a3ef27cbc6..ba91d50d65 100644 --- a/contributed_definitions/NXms_feature_set.nxdl.xml +++ b/contributed_definitions/NXms_feature_set.nxdl.xml @@ -1,9 +1,9 @@ - + - - - +time_stamp: # simulated, physical +Thea, Joseph, Lauri, Dinga (TJLD) just for comparison for each group and field to what this would map in their model for the MDTutorial 2--> + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -61,12 +62,15 @@ TJLD: one such for atom_groups(NXms_feature_set) TJLD: but not one for every molecule, i.e. all molecules and how their atoms with ids are related to atoms ids is concatenated TJLD: clearly there are two possibilities: either concatenate or make one NXms_feature_set for each molecule or component in the topology hierarchy TJLD: however the here proposed design generalizes the arbitrary (microstructural) features and computational geometry based coarse-grained representations--> - - + + Name (or link?) to another NXms_feature_set which defines features what are assumed as the parents/super_features of all members in this feature set. - If depends_on is set to "." or this attribute is not defined in an instance + If depends_on is set to "." or this attribute is not defined in an instance of this application definition, assume that this feature_set instance represents the root feature_set of the feature tree/graph. @@ -83,34 +87,39 @@ TJLD: the key point we can use NXms_feature_set in the same way as currently TJL but with the additional benefit of a much richer geometrical description and the details about the uncertainty of these descriptions I can also imagine that materials engineers e.g. can reuse NXms_feature_set in an application definition by just then naming their group e.g. grains(NXms_feature_set) and use in the application definition either only the (material point), interface network, or volumetric description--> - - + + What is the best matching description how dimensional the feature is. - - + How many features/members are in this set? - - +TJLD: inherits from NXms_feature_set but would need to have no dimensionality +--> The keywords of the dictionary of human-readable types of features. Using terms from a community-agreed upon controlled vocabulary, e.g. atom, solute, vacancy, monomer, molecule, anti-site, crowd_ion, - quadruple junction, triple line, disconnection, dislocation, + quadruple junction, triple line, disconnection, dislocation, kink, jog, stacking_fault, homo_phase_boundary, hetero_phase_boundary, surface, thermal_groove_root, precipitate, dispersoid, pore, crack is recommended. @@ -119,8 +128,10 @@ TJLD: inherits from NXms_feature_set but would need to have no dimensionality--> - - + + The integer identifier used to resolve of which type each feature is, i.e. the values of the dictionary of human-readable types of features. @@ -129,7 +140,7 @@ TJLD: inherits from NXms_feature_set but would need to have no dimensionality--> - + For each feature in the set specify the associated number of identifier to parent features as are resolvable via depends_on. @@ -141,7 +152,7 @@ TJLD: inherits from NXms_feature_set but would need to have no dimensionality--> - + Concatenated array of parent identifier for each feature (in the sequence) according to identifier and how the identifier of features in the here @@ -179,12 +190,14 @@ end up as links--> - +but here NXms_feature_set instances +--> Assumptions and parameter to arrive at geometric primitives to locate zero-dimensional/point-(like) features which are @@ -199,7 +212,10 @@ but here NXms_feature_set instances--> - + Assumptions and parameters to arrive at geometric primitives to locate one-dimensional/line-like features which are @@ -249,52 +265,52 @@ Sandor suggested it can be useful to also describe how one could transform syste +\@depends_on: <>/atoms +is trivially the same case as was described already for the DDD simulation--> +\@depends_on: <>/triple_lines--> +\@depends_on: <>/dislocations--> +you can use volumes and interfaces to describe explicitly the 3D geometry +alternatively you can--> +alternatively one NXms_feature_set for homophase boundaries--> diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml new file mode 100644 index 0000000000..49568b0ac1 --- /dev/null +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -0,0 +1,383 @@ + + + + + + + + + Number of pixel along the z slowest direction. + + + + + Number of pixel along the y slow direction. + + + + + Number of pixel along the x fast direction. + + + + + Number of RGB values along the fastest direction, always three. + + + + + Dimensionality of the mapping (either 2 or 3). + + + + + Base class to store an inverse pole figure (IPF) mapping (IPF map). + + + + Reference to the coordinate system whereby the projection_direction is defined. + + If the field depends_on is not provided but a parent of the instance + of this base class or its specialization defines an :ref:`NXcoordinate_system_set` + and exactly one :ref:`NXcoordinate_system`, the reference points to this system. + + If nothing is provided and none of the above-mentioned references pointing + in a parent, McStas is assumed. + + + + + The direction along which orientations are projected. + + + + + + + + Details about the original grid. + + Here original grid means the one onto which the IPF map was computed + when exported from the tech partner's file format representation. + + + + + Details about the grid onto which the IPF is recomputed. + + Rescaling the visualization of the IPF map may be needed to enable + visualization in specific software tools like H5Web. + The value specifies the fractional change of the spacing between + the original mapping and the scaled one. + + + + + How where orientation values at the location of the output grid + positions computed. + + Nearest neighbour means the orientation of the closed (Euclidean distance) + grid point of the input_grid was taken. + + + + + + + + Inverse pole figure mapping. + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + Inspect the definition of :ref:`NXcrystal_structure` and its field + phase_identifier for further details. + + Details about possible regridding and associated interpolation + during the computation of the IPF map visualization can be stored + using the input_grid, output_grid, and interpolation fields. + + The main purpose of this map is to offer a normalized default representation + of the IPF map for consumption by a research data management system (RDMS). + This is aligned with the first aim of :ref:`NXms_ipf`, to bring colleagues and + users of IPF maps together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging IPF maps as specific + community-accepted tools to convey orientation maps. + + With this design the individual RDMS solutions and tools can still continue + to support specific custom data analyses workflow and routes but at least + there is one common understanding which enables also those users who are + not necessarily experts in all the details of the underlying techniques + can understand and thus eventually judge if the dataset is worth to be + reused or repurposed. + + + + + + Inverse pole figure color code for each map coordinate. + + + + + + + + + + Pixel center coordinate calibrated for step size along the z axis of the map. + + + + + + + + + Pixel center coordinate calibrated for step size along the y axis of the map. + + + + + + + + + Pixel center coordinate calibrated for step size along the x axis of the map. + + + + + + + + + + The color code which maps colors into orientation into the fundamental zone. + + For each stereographic standard triangle (SST), i.e. a rendering of the + fundamental zone of the crystal-symmetry-reduced orientation space + SO3, it is possible to define a color model which assigns each point in + the fundamental zone a color. + + Different mapping models are used. These implement (slightly) different + scaling relations. Differences exist across representations of tech partners. + + Differences are which base colors of the RGB color model are placed in + which extremal position of the SST and where the white point is located. + + For further details see: + + * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the matrix + of a rasterized image which is rendered by the backend tool gets + copied into an RGB matrix to offer a default plot. + + + + + + Inverse pole figure color code for each map coordinate. + + + + + + + + + + Pixel along the y-axis. + + + + + + + + + Pixel along the x-axis. + + + + + + + + + diff --git a/contributed_definitions/NXms_ipf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml new file mode 100644 index 0000000000..776eb0a6c9 --- /dev/null +++ b/contributed_definitions/NXms_ipf_set.nxdl.xml @@ -0,0 +1,33 @@ + + + + + + + Base class to group multiple :ref:`NXms_ipf` instances. + + A collection of inverse pole figure approximations. + + + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml new file mode 100644 index 0000000000..a810d12b3c --- /dev/null +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -0,0 +1,310 @@ + + + + + + Base class to store the configuration when using the MTex/Matlab software. + + MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. + See `R. Hielscher et al. <https://mtex-toolbox.github.io/publications>`_ and + the `MTex source code <https://github.com/mtex-toolbox>`_ for details. + + + + Reference frame and orientation conventions. + Consult the `MTex docs <https://mtex-toolbox.github.io/EBSDReferenceFrame.html>`_ for details. + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + + + + + + Settings relevant for generating plots. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + True if MTex renders a scale bar with figures. + + + + + True if MTex renders a grid with figures. + + + + + Code for the function handle used for annotating pole figure plots. + + + + + TODO with MTex developers + + + + + + + + + TODO with MTex developers + + + + + + + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Miscellaneous other settings of MTex. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + + Miscellaneous settings relevant for numerics. + + + + Return value of the Matlab eps command. + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Miscellaneous settings relevant of the system where MTex runs. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Collection of paths from where MTex reads information and code. + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + List of file type suffixes for which MTex assumes + texture/pole figure information. + + + + + List of file type suffixes for which MTex assumes EBSD content. + + + + + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml new file mode 100644 index 0000000000..988034557d --- /dev/null +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -0,0 +1,171 @@ + + + + + + + + Number of pixel per varphi section plot along the varphi_one fastest direction. + + + + + Number of pixel per varphi section plot along the capital_phi slow direction. + + + + + Number of pixel per varphi section plot along the varphi_two slowest direction. + + + + + Number of local maxima evaluated in the component analysis. + + + + + Base class to store an orientation distribution function (ODF) computation. + + + + Details about the algorithm used for computing the ODF. + + + + Point group of the crystal structure (International Table of Crystallography) + of the phase for which the here documented phase-dependent ODF was computed. + + + + + Point group assumed for processing-induced *sample symmetries*. + (according to International Table of Crystallography). + + + + + Halfwidth of the kernel. + + + + + Name of the kernel. + + + + + Resolution of the kernel. + + + + + + + Number of local maxima evaluated for the ODF. + + + + + + Euler angle representation of the kth-most maxima of the ODF + in decreasing order of the intensity maximum. + + + + + + + + + Disorientation threshold within which intensity of the ODF + is integrated for the component analysis. + + + + + Integrated ODF intensity within a theta-ball of SO3 about + each location as specified for each location in the order + and reported in the order of these locations. + + + + + + + + + Visualization of the ODF intensity as orthogonal sections through Euler space. + + This is one example of typical default plots used in the texture + community in Materials Engineering. + + Mind that the Euler space is a distorted space. Therefore, equivalent + orientations show intensity contributions in eventually multiple + locations. + + + + + ODF intensity at probed locations relative to + null model of a completely random texture. + + + + + + + + + + Pixel center angular position along the :math:`\varphi_1` direction. + + + + + + + + + Pixel center angular position along the :math:`\varphi_2` direction. + + + + + + + + + Pixel center angular position along the :math:`\Phi` direction. + + + + + + + + diff --git a/contributed_definitions/NXms_odf_set.nxdl.xml b/contributed_definitions/NXms_odf_set.nxdl.xml new file mode 100644 index 0000000000..d41a609a8b --- /dev/null +++ b/contributed_definitions/NXms_odf_set.nxdl.xml @@ -0,0 +1,33 @@ + + + + + + + Base class to group multiple :ref:`NXms_odf` instances. + + A collection of orientation distribution function approximations. + + + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml new file mode 100644 index 0000000000..9a627ac62b --- /dev/null +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + + Number of pixel per pole figure in the slow direction. + + + + + Number of pixel per pole figure in the fast direction. + + + + + Base class to store a pole figure (PF) computation. + + + + Details about the algorithm that was used to compute the pole figure. + + + + Point group of the crystal structure of the phase for which the + here documented phase-dependent pole figure was computed + (according to International Table of Crystallography). + + + + + Point group assumed for processing induced *sample symmetries* + (according to International Table of Crystallography). + + + + + Halfwidth of the kernel. + + + + + Miller indices (:math:`(hkl)[uvw]`) to specify the pole figure. + + + + + Resolution of the kernel. + + + + + + Pole figure. + + + + + Pole figure intensity. + + + + + + + + + Pixel center along y direction in the equatorial plane of + a stereographic projection of the unit sphere. + + + + + + + + + Pixel center along x direction in the equatorial plane of + a stereographic projection of the unit sphere. + + + + + + + + diff --git a/contributed_definitions/NXms_pf_set.nxdl.xml b/contributed_definitions/NXms_pf_set.nxdl.xml new file mode 100644 index 0000000000..3ca5fc0005 --- /dev/null +++ b/contributed_definitions/NXms_pf_set.nxdl.xml @@ -0,0 +1,33 @@ + + + + + + + Base class to group multiple :ref:`NXms_pf` instances. + + A collection of pole figure approximations. + + + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml new file mode 100644 index 0000000000..99e629ba23 --- /dev/null +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -0,0 +1,454 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + + The number of crystal projections. + + + + + The number of interface projections. + + + + + The number of assumed triple junction projections aka triple points. + + + + + + The number of crystals. + + + + + The number of interfaces + + + + + The number of triple lines + + + + + The number of quadruple junctions. + + + + + Base class to describe discretized (micro)structural features of a material. + + One instance of this base class can be used to describe the current configuration + the base class does not include time-dependent descriptions for the sake of + clarity and because of the fact that virtually all simulations or experiments + probe time by sampling. Therefore, time-dependent state descriptions should + be realized with creating a set of :ref:`NXms_snapshot_set` with instances of + :ref:`NXms_snapshot` using e.g. :ref:`NXms_recon` base class instances. + + + + + The configuration and parameterization of the reconstruction algorithm + whereby the microstructural features were identified. + + + + + Dimensionality of the analysis. + + This field can be used e.g. by a research data management system + to identify if the described feature set specifies a + one-, two-, or three-dimensional feature set. + + + + + + + + + + Which algorithm is used to reconstruct the features. + + + + + + + + + + + Threshold to define at which disorientation angle to assume + two crystalline regions have a significant orientation difference + which warrants to argue that there is an interface between the + two regions. + + + + + + + + + + + + + Projections of crystals on the sample surface as typically + characterized with optical or electron microscopy. + + + + Reference to lines(NXcg_polyline_set) which supports the + discretized shape of each cross-sectioned crystal. + + Most microscopy techniques support to generate only a two-dimensional + representation (projection) of the characterized material. + + For true volumetric techniques use the specifically + specialized crystals :ref:`NXms_feature_set` instead. + See stereology literature for more details e.g. + E.E. Underwood's book entitled Quantitative Stereology + + + + + Number of crystals. + + + + + Integer offset whereby the identifier of the first member + of the set differs from zero. + + Identifiers can be defined either implicitly or explicitly. + For implicit indexing identifiers are defined on the interval + :math:`[identifier_offset, identifier_offset + c - 1]`. + + + + + Identifier used for crystals for explicit indexing. + + + + + + + + How many phases are distinguished + + + + + Integer offset whereby the identifier of the first member + of the set differs from zero. + + + + + + Identifier used for phase for explicit indexing. + + + + + + + + + True, if the crystal makes contact with the edge of the ROI, + false otherwise. + + + + + + + + Average disorientation angle between individual orientation of the + crystal at probed positions (weighted by area of that position) versus + the average disorientation of the crystal. + + + + + + + + + Calibrated area of surrounded by the polyline about each crystal. + + + + + + + + + + Projections of grain or phase boundaries as typically sectioned + with optical or electron microscopy characterization. + + + + Reference to lines(NXcg_polyline_set) which supports the + discretized shape of each cross-sectioned crystal. + + Set of tuples of polyline segments which build the interface. + + + + + + Set of pairs of crystal_identifier resolved via depends_on which + are adjacent to each interface. + + + + + + + + The specific crystal_projections(NXms_feature_set) instance + to resolve crystal identifier. + + + + + + + Set of pairs of triple_point_identifier which the interface connects. + For 2D projections of 3D microstructural features a triple point is + physically only the projection of a triple line. + + + + + + + + The specific triple_line_projections(NXms_feature_set) instance + whereby to resolve triple_point identifier. + + + + + + + The length of the interface. + + This is not necessarily the same as the length of the individual + polyline segments whereby the interface is discretized. + + The actual coordinate system whereby the geometry is calibrated + with real physical dimensions is typically documented by the + depends_on attribute of the respective NXcg_primitive_set. + This depends_on attribute should point explicitly to an + instance of a :ref:`NXcoordinate_system` to support users as + much as possible with interpreting how and where the lines are + located in the reference frame. + + + + + + + + Integer offset whereby the identifier of the first member + of the set differs from zero. + + Identifiers can be defined either implicitly or explicitly. + For implicit indexing identifiers are defined on the interval + :math:`[identifier_offset, identifier_offset + c - 1]`. + + + + + Identifier for each interface using explicit indexing. + + + + + + + + + + Projections of triple lines as typically characterized with optical + or electron microscopy. + + Mind that most specimens are thermo-chemo-mechanically treated before + they are characterized. Therefore, the projected crystal defects are + have physically no longer the same structure as in the bulk. + + Examples are manifest as effects such as thermal grooving, or relaxation + effects of an intersection between a triple line that is cut + by the specimen surface as these defects are then exposed typically + to a different atmosphere and hence have different thermodynamic boundary + conditions than of their true volumetric defects in the bulk. + + + + Reference to points(NXcg_point_set) which supports the + locations of these triple points. + + + + + + Number of triple points. + + + + + Integer offset whereby the identifier of the first member + of the set differs from zero. + + Identifiers can be defined either implicitly or explicitly. + For implicit indexing identifiers are defined on the interval + :math:`[identifier_offset, identifier_offset + c - 1]`. + + + + + Identifier for each triple point using explicit indexing. + + + + + + + + Set of triple point identifiers. + + + + + + + The relevant points(NXcg_point_set) instance whereby to + resolve interface identifiers. + + + + + + Set of triplets of identifier of line-like features. + Each triplet resolves which three interface projections + the triple point connects. + + + + + + + + The specific interface_projections(NXms_feature_set) + instance whereby to resolve interface identifiers. + + + + + + + Triplet of identifier of polyline segments. Each triplet resolves + which three segments of polyline segments the triple junction connects. + + + + + + + + The specific lines(NXcg_polyline_set) instance to resolve + polyline segments. + + + + + + diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index 849373a882..224aa030d6 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -1,9 +1,9 @@ - + - - + + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -74,8 +75,8 @@ Specifically the SCORE model can be used to simulate the growth of static recrystallization nuclei. The model is described in the literature: - * `M. Kühbach et al. <https://doi.org/10.1016/j.actamat.2016.01.068>`_ - * `C. Haase et al. <https://doi.org/10.1016/j.actamat.2015.08.057>`_ + * `M. Kühbach et al. <https://doi.org/10.1016/j.actamat.2016.01.068>`_ + * `C. Haase et al. <https://doi.org/10.1016/j.actamat.2015.08.057>`_ * `M. Diehl et al. <https://doi.org/10.1088/1361-651X/ab51bd>`_ @@ -108,7 +109,7 @@ Free-text description about the workflow (analysis/simulation). - Users are strongly advised to detail the sample history in the + Users are strongly advised to detail the sample history in the respective field and fill rather as completely as possible the fields of this application definition rather than write details about the experiment into this free-text description field. @@ -232,7 +233,7 @@ - Which role does the user have in the place and at the point + 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. @@ -260,16 +261,16 @@ according to SAMPLE.yaml 0f8df14 2022/06/15--> +doc: | +ISO 8601 time code with local time zone offset to UTC information +when the specimen was prepared.--> Hard link to a location in the hierarchy of the NeXus file @@ -285,7 +286,7 @@ preparation_date(NX_DATE_TIME): - + @@ -312,9 +313,11 @@ preparation_date(NX_DATE_TIME): - +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -404,17 +407,17 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele +exists: optional--> Evolution of the recrystallized volume fraction over time. @@ -422,7 +425,7 @@ electric_field(NXprocess): @@ -610,7 +613,7 @@ snapshots--> +exists: optional--> @@ -637,11 +640,11 @@ snapshots--> +exists: optional--> @@ -691,21 +694,27 @@ electric_field(NXprocess): - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/contributed_definitions/NXoptical_system_em.nxdl.xml index c925e2b35a..022645efe8 100644 --- a/contributed_definitions/NXoptical_system_em.nxdl.xml +++ b/contributed_definitions/NXoptical_system_em.nxdl.xml @@ -1,9 +1,9 @@ - + - + A container for qualifying an electron optical system. @@ -36,13 +36,14 @@ work of the HMC EM glossary activities--> - The factor of enlargement of the apparent size, not physical size, of an object. + The factor of enlargement of the apparent size, + not the physical size, of an object. - The defocus aberration constant oftentimes taken as the C_1_0 which - is described in more details in NXaberration. + The defocus aberration constant (oftentimes referred to as C_1_0). + See respective details in :ref:`NXaberration` class instances. @@ -58,20 +59,28 @@ work of the HMC EM glossary activities--> magnification and other settings of the instrument. - + Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is *a distance between the specimen and the lower pole piece in SEM system*. - + + Beam current as measured relevant for the illumination of the specimen. - Users should specify further details like how the beam current was measured - using the beam_current_description field. + Users should specify further details like how the beam current + was measured using the beam_current_description field. - + + Specify further details how the beam current was measured or estimated. diff --git a/contributed_definitions/NXorientation_set.nxdl.xml b/contributed_definitions/NXorientation_set.nxdl.xml deleted file mode 100644 index e8056053e0..0000000000 --- a/contributed_definitions/NXorientation_set.nxdl.xml +++ /dev/null @@ -1,133 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the reference space/coordinate system. - - - - - The cardinality of the set, i.e. the number of orientations. - - - - - Number of parameters for the chosen parameterization. - - - - - Details about individual orientations of a set of objects. - - For a more detailed insight into the discussion of parameterizing - orientations in materials science see: - - * https://doi.org/10.1016/j.matchar.2016.04.008 - * https://doi.org/10.1088/0965-0393/23/8/083501 - * https://doi.org/10.1007/978-3-662-09156-2 group-theory of rotations - * https://doi.org/10.1016/C2013-0-11769-2 the classical book of H.-J. Bunge - - - - - Reference to or definition of a coordinate system with - which the definitions are interpretable. - - - - - - - - - - - - A link or reference to the objects whose identifier are referred to in - identifier to resolve which row tuple is the orientation of each object - by reading orientations. - - - - - Integer which specifies which orientation (row of array orientation) matches - to which object.e first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - - - - - Integer used to distinguish how a row in orientation describes a specific - object with an explicit identifier that can be queried via inspecting the - list of available objects in objects. - - The rational behind having such a more complicated pattern is that not - all objects referred when following the link in objects may still exists - or are still tracked when the orientation set was characterized. - - This design enables to also use NXorientation_set in situations where - the orientation of objects change as a function in time. - - - - - - - - Parameterized orientations. - - - - - - - - - diff --git a/contributed_definitions/NXpump.nxdl.xml b/contributed_definitions/NXpump.nxdl.xml index c1951c37f9..328a8cb635 100644 --- a/contributed_definitions/NXpump.nxdl.xml +++ b/contributed_definitions/NXpump.nxdl.xml @@ -1,9 +1,9 @@ - + - + - Device to reduce an atmosphere to a controlled remaining pressure level. + Device to reduce an atmosphere (real or simulated) to a controlled pressure. - + Principle type of the pump. diff --git a/contributed_definitions/NXroi.nxdl.xml b/contributed_definitions/NXroi.nxdl.xml new file mode 100644 index 0000000000..b77834bb69 --- /dev/null +++ b/contributed_definitions/NXroi.nxdl.xml @@ -0,0 +1,34 @@ + + + + + + Base class to describe a region-of-interest analyzed. + + + + Details about processing steps. + + + + diff --git a/contributed_definitions/NXrotation_set.nxdl.xml b/contributed_definitions/NXrotation_set.nxdl.xml index 24e51daff1..bec6d0cc95 100644 --- a/contributed_definitions/NXrotation_set.nxdl.xml +++ b/contributed_definitions/NXrotation_set.nxdl.xml @@ -1,9 +1,9 @@ - + +we should offer here support for d==2, d==3 +several well accepted parameterizations for rotations exists in Materials Science +thus not using NXtransformations, different Materials Science groups follow +different conventions not every reporting of rotations is consistent and correct +having a base class like the one proposed here offers a suggestion to start +discussing at all about how to convert between groups who report using +different conventions--> The symbols used in the schema to specify e.g. dimensions of arrays. @@ -34,6 +40,11 @@ we should offer here support for d==2, d==3--> The cardinality of the set, i.e. the number of value tuples. + + + How many phases with usually different crystal and symmetry are distinguished. + + Base class to detail a set of rotations, orientations, and disorientations. @@ -46,28 +57,28 @@ we should offer here support for d==2, d==3--> * `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_ * `A. Morawiec <https://doi.org/10.1007/978-3-662-09156-2>`_ - Once orientations are defined one can continue to characterize the - misorientation and specifically the disorientation which describes the - rotation that is required to register the lattices of two oriented objects + Once orientations are defined, one can continue to characterize the + misorientation and specifically the disorientation. The misorientation describes + the rotation that is required to register the lattices of two oriented objects (like crystal lattice) into a crystallographic equivalent orientation: * `R. Bonnet <https://doi.org/10.1107/S0567739480000186>`_ - - Based on the idea of this NXorientation_set one could equally formulate - an NXdisorientation_set. - + - Reference to an instance of NXem_conventions which contextualizes + Reference to an instance of :ref:`NXem_conventions` which contextualizes how the here reported parameterized quantities can be interpreted. - + - + Point group which defines the symmetry of the crystal. - This has to be at least a single string. + + This has to be at least a single string. If crystal_symmetry is not + provided point group 1 is assumed. + In the case that misorientation or disorientation fields are used and the two crystal sets resolve for phases with a different crystal symmetry, this field has to encode two string. @@ -75,43 +86,52 @@ just how to rotate the object into the reference frame defined by depends_on--> An example of this most complex case is the description of the disorientation between crystals adjoining a hetero-phase boundary. + + + - - + Point group which defines an assumed symmetry imprinted upon processing the material/sample which could give rise to or may justify to use a simplified description of rotations, orientations, misorientations, - and disorientations via numerical procedures known as symmetrization. + and disorientations via numerical procedures that are known as + symmetrization. + + If sample_symmetry is not provided point group 1 is assumed. The traditionally used symmetrization operations within the texture community in Materials Science, though, are thanks to methodology and software improvements no longer strictly needed. Therefore, users are encouraged to set the sample_symmetry to 1 (triclinic) and thus assume - there is no implied additional processing symmetry imprinted. + there is no justification to assume the imprinting of additional + symmetry because of the processing. In practice one often faces situations where indeed these assumed - symmetries are anyway not fully observed and thus an accepting of + symmetries are anyway not fully observed, and thus an accepting of eventual inaccuracies just for the sake of reporting a simplified - symmetrized description can be avoided. + symmetrized description should be avoided. + + + - + - The set of rotations expressed in quaternion representation. The assumed - crystal and sample symmetry point group is 1, triclinic. Rotations which - should be interpreted as antipodal are not marked as such. + The set of rotations expressed in quaternion parameterization considering + crystal_symmetry and sample_symmetry. Rotations which should be + interpreted as antipodal are not marked as such. - + - The set of rotations expressed in Euler angle representation following - the same applied symmetries as explained for rotation_quaternion. - To interpret Euler angles correctly it is necessary to inspect the + The set of rotations expressed in Euler angle parameterization considering + the same applied symmetries as detailed for the field rotation_quaternion. + To interpret Euler angles correctly, it is necessary to inspect the conventions behind depends_on to resolve which of the many Euler-angle conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. @@ -120,36 +140,36 @@ just how to rotate the object into the reference frame defined by depends_on--> - + - True for all those values which are considered antipodal, - false for those which are not considered antipodal. + True for all those value tuples which have assumed antipodal symmetry. + False for all others. - + - The set of orientations expressed in quaternion representation and + The set of orientations expressed in quaternion parameterization and obeying symmetry for equivalent cases as detailed in crystal_symmetry and sample_symmetry. The supplementary field is_antipodal can be used - to mark orientations which are antipodal. + to mark orientations with the antipodal property. - + - The set of orientations expressed in Euler angle representation following + The set of orientations expressed in Euler angle parameterization following the same assumptions like for orientation_quaternion. - To interpret Euler angles correctly it is necessary to inspect the + To interpret Euler angles correctly, it is necessary to inspect the conventions behind depends_on to resolve which of the many Euler-angle conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. @@ -158,37 +178,16 @@ rotation_axis_angle(NX_FLOAT):--> - - - This will follow the Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - - - - - - - - - UB matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is - the multiplication of the orientation_matrix, given above, - with the :math:`B` matrix which - can be derived from the lattice constants. - - - - - - - - - + + + - The set of misorientations expressed in quaternion representation and + The set of misorientations expressed in quaternion parameterization obeying symmetry operations for equivalent misorientations as defined by crystal_symmetry and sample_symmetry. @@ -197,7 +196,7 @@ is smallest.--> - + Misorientation angular argument (eventually signed) following the same symmetry assumptions as expressed for the field misorientation_quaternion. @@ -206,7 +205,7 @@ is smallest.--> - + Misorientation axis (normalized) and signed following the same symmetry assumptions as expressed for the field misorientation_angle. @@ -218,14 +217,18 @@ is smallest.--> - + - The set of disorientation expressed in quaternion representation and + The set of disorientation expressed in quaternion parameterization obeying symmetry operations for equivalent misorientations as defined by crystal_symmetry and sample_symmetry. + + + + - + Disorientation angular argument (should not be signed, see `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_) @@ -236,10 +239,10 @@ fundamental zone of SO3 for given crystal and sample symmetry--> - + Disorientation axis (normalized) following the same symmetry assumptions - as expressed for the field disorientation_quaternion. + as expressed for the field disorientation_angle. @@ -248,6 +251,6 @@ fundamental zone of SO3 for given crystal and sample symmetry--> - +matrix of Bunge-Euler angles, or of (c := Ngrains, n_p := 4) matrix of quaternions. +the benefit of such a representation is that with a known NXorientation_set base class one can implement a common parameterization transformation library (of which several already exist) in the microstructure modelling communities so that a program can read the information in the (NXorientation_set) instance and automatically transform/compute between different parameterizations. Super relevant for interoperability e.g. in SEM/EBSD, where this was a long standing issue and right now the most frequently accepted consensus is to report either Bunge-Euler angles or quaternions and then use existent transformation libraries (as implemented by e.g. Marc de Graeff for SEM/EBSD and used by many but not yet the majority of people in the computational materials modelling community within crystal plasticity, crystal growth modeling, DREAM.3D)--> diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/contributed_definitions/NXscanbox_em.nxdl.xml index e341f65792..56abc4f47b 100644 --- a/contributed_definitions/NXscanbox_em.nxdl.xml +++ b/contributed_definitions/NXscanbox_em.nxdl.xml @@ -1,9 +1,9 @@ - + - + - Scan box and coils which deflect an electron beam in a controlled manner. + Scan box and coils which deflect a beam of charged particles in a controlled manner. - In electron microscopy, the scan box is instructed by the microscope - control software. This component directs the probe to controlled - locations according to a scan scheme and plan. + The scan box is instructed by an instance of :ref:`NXprogram`, some control software, + which is not necessarily the same program as for all components of a microscope. + + The scanbox directs the probe of charged particles (electrons, ions) + to controlled locations according to a scan scheme and plan. + + To achieve this task, the scanbox typically contains deflection coils, + which should be modelled as instances of :ref:`NXdeflector`. - - - - - + + + TODO discuss with the electron microscopists. + + + + + TODO discuss with the electron microscopists. + + + + + TODO discuss with the electron microscopists. + + + + + TODO discuss with the electron microscopists. + + - - - - - + + + TODO discuss with the electron microscopists. + + + + + TODO discuss with the electron microscopists. + + + + + TODO discuss with the electron microscopists. + + + + + TODO discuss with the electron microscopists. + + + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml index d75ef0778d..aab6324743 100644 --- a/contributed_definitions/NXspectrum_set.nxdl.xml +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -1,9 +1,9 @@ - + - + - + + + Number of scan points. + + Number of pixel in the slow direction. @@ -41,50 +45,56 @@ - Container for reporting a set of spectra. + Base class container for reporting a set of spectra. + Details how spectra were processed from the detector readings. - + Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXspectrum_set were loaded during parsing. + the :ref:`NXdata` instances in this :ref:`NXspectrum_set` were + loaded during parsing. - - - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - - - - + + Imaging (data collection) mode of the instrument during acquisition - of the data in this NXspectrum_set instance. + of the data in this :ref:`NXspectrum_set` instance. - + - Link or name of an NXdetector instance with which the data were collected. + Link or name of an :ref:`NXdetector` instance with which the data were + collected. - + Collected spectra for all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. + + This representation supports rectangular scan pattern with equidistant + energy bins. For randomly or dissimilarly spaced scan points + use collection instead. - + + + Counts + - + Counts @@ -96,30 +106,39 @@ \@xpos_indices: 1 \@energy_indices: 2--> + + Coordinate along y direction. + - + - Coordinate along y direction + Pixel coordinate along y direction + + Coordinate along x direction. + - + - Coordinate along x direction + Pixel coordinate along x direction + + Energy axis + - + Energy @@ -133,13 +152,17 @@ base classes--> Accumulated counts over all pixels of the region-of-interest. - This representation supports rectangular scan pattern. + This representation supports a rectangular scan pattern with + equidistant energy bins. - + + + Accumulated counts + - + Counts @@ -149,10 +172,65 @@ base classes--> \@axes: [energy] \@energy_indices: 0--> + + Energy axis + + + + + + + Energy + + + + + + + Collected spectra for each scan point. + + This representation supports equidistant energy bins. + For rectangular sampling use stack and summary instead. + + + + Counts + + + + + + + + Counts + + + + + + + Scan point identifier + + + + + + + Scan point identifier + + + + + + Energy axis + - + Energy diff --git a/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml b/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml deleted file mode 100644 index 43467f73f2..0000000000 --- a/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml +++ /dev/null @@ -1,188 +0,0 @@ - - - - - - - - - Number of pixel per EELS mapping in the slow direction. - - - - - Number of pixel per EELS mapping in the fast direction. - - - - - Number of electron energy loss bins. - - - - - Container for reporting a set of electron energy loss (EELS) spectra. - - Virtually the most important case is that spectra are collected in - a scanning microscope (SEM or STEM) for a collection of points. - The majority of cases use simple d-dimensional regular scan pattern, - such as single point, line profiles, or (rectangular) surface mappings. - - The latter pattern is the most frequently used. - For now the base class provides for scans for which the settings, - binning, and energy resolution is the same for each scan point. - - - - Details how EELS spectra were processed from the detector readings. - - - - Typically the name of the input, (vendor) file from which all - the NXdata instances in this NXspectrum_set_em_eels were loaded during - parsing to represent them in e.g. databases. - - - - An at least as strong as SHA256 hashvalue of the dataset/file - which represents the source digitally to support provenance tracking. - - - - - - Commercial or otherwise given name to the program which was used - to process detector data into the EELS spectra stack and summary. - - - - Program version plus build number, commit hash, or description - of an ever persistent resource where the source code of the program - and build instructions can be found so that the program - can be configured in such a manner that the result file - is ideally recreatable yielding the same results. - - - - - - - Collected EELS spectra for all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - - - - Counts for one spectrum per each pixel. - - - - - - - - - EELS counts - - - - - - - Pixel center of mass position y-coordinates. - - - - - - - Coordinate along y direction. - - - - - - Pixel center of mass position x-coordinates. - - - - - - - Coordinate along x direction. - - - - - - Pixel center of mass energy loss bins. - - - - - - - Coordinate along energy loss axis. - - - - - - - Accumulated EELS spectrum over all pixels of a rectangular - region-of-interest. This representation supports rectangular scan pattern. - - - - Counts for specific energy losses. - - - - - - - Counts electrons with an energy loss within binned range. - - - - - - - Pixel center of mass energy loss bins. - - - - - - - Coordinate along energy loss axis. - - - - - diff --git a/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml b/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml deleted file mode 100644 index fd19cb1dab..0000000000 --- a/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml +++ /dev/null @@ -1,311 +0,0 @@ - - - - - - - - - - Number of pixel per X-ray mapping in the slow direction - - - - - Number of pixel per X-ray mapping in the fast direction - - - - - Number of X-ray photon energy (bins) - - - - - Number of identified elements - - - - - Number of peaks - - - - - Container for reporting a set of energy-dispersive X-ray spectra. - - Virtually the most important case is that spectra are collected in - a scanning microscope (SEM or STEM) for a collection of points. - The majority of cases use simple d-dimensional regular scan pattern, - such as single point, line profiles, or (rectangular) surface mappings. - The latter pattern is the most frequently used. - - For now the base class provides for scans for which the settings, - binning, and energy resolution is the same for each scan point. - - `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ - should be used. - - - - Details how X-ray spectra were processed from the detector readings. - - - - Typically the name of the input, (vendor) file from which all - the NXdata instances in this NXspectrum_set_em_xray were loaded during - parsing to represent them in e.g. databases. - - - - An at least as strong as SHA256 hashvalue of the dataset/file - which represents the source digitally to support provenance tracking. - - - - - - Commercial or otherwise given name to the program which was used - to process detector data into the X-ray spectra stack and summary. - - - - Program version plus build number, commit hash, or description - of an ever persistent resource where the source code of the program - and build instructions can be found so that the program - can be configured in such a manner that the result file - is ideally recreatable yielding the same results. - - - - - - - - Collected X-ray spectra for all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - - - - - - - - - - X-ray photon counts - - - - - - - - - - - Coordinate along y direction. - - - - - - - - - - Coordinate along x direction. - - - - - - - - - - Photon energy. - - - - - - - Accumulated X-ray spectrum over all pixels of a rectangular - region-of-interest. This representation supports rectangular scan pattern. - - - - - - - - X-ray photon counts - - - - - - - - - - - Photon energy - - - - - - - - Details about computational steps how peaks were indexed as elements. - - - - Given name of the program that was used to perform this computation. - - - - Program version plus build number, commit hash, or description of an - ever persistent resource where the source code of the program and - build instructions can be found so that the program can be configured - in such a manner that the result file is ideally recreatable yielding - the same results. - - - - - - Name and location of each X-ray line which was indexed as a known ion. - For each ion an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - - - - - IUPAC notation identifier of the line which the peak represents. - - This can be a list of IUPAC notations for (the seldom) case that - multiple lines are group with the same peak. - - - - - - - List of the names of identified elements. - - - - - - - - Individual element-specific EDX/EDS/EDXS/SXES mapping - - A composition map is an image whose intensities for each pixel are the - accumulated X-ray quanta *under the curve(s)* of a set of peaks. - - - - Given name of the program that was used to perform this computation. - - - - Program version plus build number, commit hash, or description of an - ever persistent resource where the source code of the program and - build instructions can be found so that the program can be configured - in such a manner that the result file is ideally recreatable yielding - the same results. - - - - - - A list of strings of named instances of NXpeak from indexing - whose X-ray quanta where accumulated for each pixel. - - - - - - - - Human-readable, given name to the image. - - - - - - Individual element-specific maps. Individual maps should - each be a group and be named according to element_names. - - - - - - - - - Accumulated photon counts for observed element. - - - - - - - - - - - Coordinate along y direction. - - - - - - - - - - Coordinate along x direction. - - - - - - - diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index a55571e87b..95159e724c 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -1,9 +1,9 @@ - + - + - A stage lab can be used to hold, align, orient, and prepare a specimen. + Base class for a stage (lab) used to hold, orient, and prepare a specimen. - Modern stages are multi-functional devices. Many of which offer a controlled - environment around (a part) of the specimen. Stages enable experimentalists - to apply stimuli. A stage_lab is a multi-purpose/-functional tools which - can have multiple actuators, sensors, and other components. + Modern stages are multi-functional devices. Stages provide a controlled + environment around the specimen. Stages enable experimentalists to apply + controlled external stimuli on the specimen. A stage_lab is a multi-purpose + /-functional tool that is constructed from multiple actuators, sensors, + and other components. - With such stages comes the need for storing various (meta)data - that are generated while manipulating the sample. + With such stages comes the need for storing various (meta)data + that are generated while working and modifying the sample. - Modern stages realize a hierarchy of components: For example the specimen - might be mounted on a multi-axial tilt rotation holder. This holder is - fixed in the support unit which connects the holder to the rest of the - microscope. + Modern stages realize a hierarchy of components. Two examples are given to help + clarify how :ref:`NXstage_lab` instances should be used: Take a specimen that is + mounted on a multi-axial tilt rotation holder. This holder is fixed in the + support unit which connects the holder to the rest of the instrument. + Evidently different components are all considerable as to represent instances + of stages. - In other examples, taken from atom probe microscopy, researchers may work - with wire samples which are clipped into a larger fixing unit for - convenience and enable for a more careful specimen handling. - This fixture unit is known in atom probe jargon as a stub. - Stubs in turn are positioned onto pucks. - Pucks are then loaded onto carousels. - A carousel is a carrier unit with which eventually entire sets of specimens - can be moved in between parts of the microscope. + In another example, taken from atom probe microscopy, researchers may work + with wire samples which are clipped into a larger fixing unit to enable + careful specimen handling. Alternatively, a microtip is a silicon post + upon which e.g. an atom probe specimen is mounted. + Multiple microtips are grouped into a microtip array to conveniently enable + loading of multiple specimens into the instrument with fewer operations. + That microtip array is fixed on a holder. Fixture units in atom probe are known + as stubs. Stubs in turn are positioned onto pucks. Pucks are then loaded onto + carousels. A carousel is a carrier unit with which eventually entire sets of + specimens can be moved in between parts of the microscope. All of these units + can be considered stage_lab instances. - An NXstage_lab instance reflects this hierarchical design. The stage is the - root of the hierarchy. A stage carries the holder. - In the case that it is not practical to distinguish these two layers, - the holder should be given preference. + The :ref:`NXstage_lab` base class reflects this hierarchy. To cover for an as flexible + design of complex stages as possible, users should nest multiple instances of + :ref:`NXstage_lab` according to their needs to reflect the differences between what + they consider as the holder and what they consider is the stage. + The alias field can be used to specify the community jargon if necessary. - Some examples for stage_labs in applications: - - * A nanoparticle on a copper grid. The copper grid is the holder. - The grid itself is fixed to the stage. - * An atom probe specimen fixed in a stub. In this case the stub can be - considered the holder, while the cryostat temperature control unit is - a component of the stage. - * Samples with arrays of specimens, like a microtip on a microtip array - is an example of a three-layer hierarchy commonly employed for - efficient sequential processing of atom probe experiments. - * With one entry of an application definition only one microtip should be - described. Therefore, the microtip is the specimen, - the array is the holder and the remaining mounting unit - that is attached to the cryo-controller is the stage. - * For in-situ experiments with e.g. chips with read-out electronics - as actuators, the chips are again placed in a larger unit. - * Other examples are (quasi) in-situ experiments where experimentalists - anneal or deform the specimen via e.g. in-situ tensile testing machines - which are mounted on the specimen holder. + However, a much clearer approach to reflect the hierarchy of all :ref:`NXstage_lab` + instances is postfix each instance named stage_lab with integers starting + from 1 as the top level unit. + In the microtip example one could thus use stage_lab1 for the microtip, + stage_lab2 for the microtip array, stage_lab3 holder, etc. + The depends_on keyword should be used to additional clarify the hierarchy + especially when users decide to not follow the above-mentioned postfixing + notation or when is not obvious from the postfixes which stage_lab is at + which level of the stage_lab hierarchy. - To cover for an as flexible design of complex stages, users should nest - multiple instances of NXstage_lab objects according to their needs to reflect - the differences between what they consider as the holder and what - they consider is the stage. + Some examples for stage_labs in applications: - Instances should be named with integers starting from 1 as the top level unit. - In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder - (microtip array), stage_lab_3 for the microtip specimen, respectively. - The depends_on keyword should be used with relative or absolute naming inside - the file to specify how different stage_lab instances build a hierarchy - if this is not obvious from numbered identifiers like the stage_lab_1 to - stage_lab 3 example. The lower it is the number the higher it is the - rank in the hierarchy. + * A nanoparticle on a copper grid. The copper grid is the holder. + The grid itself is fixed to a stage. + * An atom probe specimen fixed in a stub. In this case the stub can be + considered the holder, while the cryostat temperature control unit is + a component of the stage. + * Samples with arrays of specimens, like a microtip on a microtip array + is an example of an at least three-layer hierarchy commonly employed for + efficient sequential processing of atom probe experiments. + * With one entry of an application definition only one microtip should be + described. Therefore, the microtip is the specimen, + the array is the holder and the remaining mounting unit + that is attached to the cryo-controller is the stage. + * For in-situ experiments with e.g. chips with read-out electronics + as actuators, the chips are again placed in a larger unit. A typical + example are in-situ experiments using e.g. the tools of `Protochips <https://www.protochips.com>`_. + * Other examples are (quasi) in-situ experiments where experimentalists + anneal or deform the specimen via e.g. in-situ tensile testing machines + which are mounted on the specimen holder. For specific details and inspiration about stages in electron microscopes: - * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ - * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ + * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ + * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ - * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) + * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ + + We are looking forward to suggestions from the scientists. - + Principal design of the stage. @@ -107,54 +113,46 @@ electrical_biasing_chip, liquid_cell_chip - + - Given name/alias for the components making the stage. + Free-text field to give a term how that a stage_lab at this level of the + stage_lab hierarchy is commonly referred to. Examples could be stub, + puck, carousel, microtip, clip, holder, etc. - - + - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. + The interpretation of this tilt should be specialized + and thus detailed via the application definition. - + - Should be defined by the application definition. + The interpretation of this tilt should be specialized + and thus detailed via the application definition. - + - Should be defined by the application definition. + The interpretation of this tilt should be specialized + and thus detailed via the application definition. - + - Should be defined by the application definition. - - - - - Should be defined by the application definition. + The interpretation of this tilt should be specialized + and thus detailed via the application definition. - + Voltage applied to the stage to decelerate electrons. - - - The rotation, tilt and position of stage components can be specified - either via NXtransformations or via the tilt_1, tilt_2, rotation, - and position fields. - - -# -# -# Quantified aberration coefficient in an aberration_model. -# -# -# -# -# Confidence -# -# -# -# -# How was the uncertainty quantified e.g. via the 95% confidence interval. -# -# -# -# -# Time elapsed since the last measurement. -# -# -# -# -# For the CEOS definitions the C aberrations are radial-symmetric and have no -# angle entry, while the A, B, D, S, or R aberrations are n-fold -# symmetric and have an angle entry. -# For the NION definitions the coordinate system differs to the one -# used in CEOS and instead two aberration coefficients a and b are used. -# -# -# -# -# + unit: NX_ANGLE + name(NX_CHAR): + doc: | + Given name to this aberration. + alias(NX_CHAR): + doc: | + Alias also used to name and refer to this specific type of aberration. diff --git a/contributed_definitions/nyaml/NXaberration_model.yaml b/contributed_definitions/nyaml/NXaberration_model.yaml index ec37d9fdb8..534762555d 100644 --- a/contributed_definitions/nyaml/NXaberration_model.yaml +++ b/contributed_definitions/nyaml/NXaberration_model.yaml @@ -4,170 +4,10 @@ doc: | See `S. J. Pennycock and P. D. Nellist `_ (page 44ff, and page 118ff) for different definitions available and further details. Table 7-2 of Ibid. - publication (page 305ff) documents how to convert from the NION to the + publication (page 305ff) documents how to convert from the Nion to the CEOS definitions. type: group -(NXobject)NXaberration_model: +NXaberration_model(NXobject): model: enumeration: [ceos, nion] (NXaberration): - c_1_0(NX_FLOAT): - unit: NX_LENGTH - doc: | - Defocus - c_1_2_a(NX_FLOAT): - unit: NX_LENGTH - doc: | - Two-fold astigmatism - c_1_2_b(NX_FLOAT): - unit: NX_LENGTH - doc: | - Two-fold astigmatism - c_2_1_a(NX_FLOAT): - unit: NX_LENGTH - doc: | - Second-order axial coma - c_2_1_b(NX_FLOAT): - unit: NX_LENGTH - doc: | - Second-order axial coma - c_2_3_a(NX_FLOAT): - unit: NX_LENGTH - doc: | - Threefold astigmatism - c_2_3_b(NX_FLOAT): - unit: NX_LENGTH - doc: | - Threefold astigmatism - c_3_0(NX_FLOAT): - unit: NX_LENGTH - doc: | - Spherical aberration - c_3_2_a(NX_FLOAT): - unit: NX_LENGTH - doc: | - Star aberration - c_3_2_b(NX_FLOAT): - unit: NX_LENGTH - doc: | - Star aberration - c_3_4_a(NX_FLOAT): - unit: NX_LENGTH - doc: | - Fourfold astigmatism - c_3_4_b(NX_FLOAT): - unit: NX_LENGTH - doc: | - Fourfold astigmatism - c_5_0(NX_FLOAT): - unit: NX_LENGTH - doc: | - Fifth-order spherical aberration - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 33b5274f5d8cccafbe9096d8604ecd849699dbf712b932df259eae3c981a99b4 -# -# -# -# -# -# Models for aberrations of electro-magnetic lenses in electron microscopy. -# -# See `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) -# for different definitions available and further details. Table 7-2 of Ibid. -# publication (page 305ff) documents how to convert from the NION to the -# CEOS definitions. -# -# -# -# -# -# -# -# -# -# -# Defocus -# -# -# -# -# Two-fold astigmatism -# -# -# -# -# Two-fold astigmatism -# -# -# -# -# Second-order axial coma -# -# -# -# -# Second-order axial coma -# -# -# -# -# Threefold astigmatism -# -# -# -# -# Threefold astigmatism -# -# -# -# -# Spherical aberration -# -# -# -# -# Star aberration -# -# -# -# -# Star aberration -# -# -# -# -# Fourfold astigmatism -# -# -# -# -# Fourfold astigmatism -# -# -# -# -# Fifth-order spherical aberration -# -# -# diff --git a/contributed_definitions/nyaml/NXaberration_model_ceos.yaml b/contributed_definitions/nyaml/NXaberration_model_ceos.yaml index 0226b7268e..14f9556140 100644 --- a/contributed_definitions/nyaml/NXaberration_model_ceos.yaml +++ b/contributed_definitions/nyaml/NXaberration_model_ceos.yaml @@ -7,7 +7,7 @@ doc: | publication (page 305ff) documents how to convert from the NION to the CEOS definitions. type: group -(NXobject)NXaberration_model_ceos: +NXaberration_model_ceos(NXaberration_model): model: enumeration: [ceos] c_1(NXaberration): @@ -18,7 +18,8 @@ type: group s_3(NXaberration): a_3(NXaberration): - # based on feedback from Thilo Remmele the following aberrations could be measured (enhanced mode, tilt angle > 30 mrad) but are not corrected + # based on feedback from Thilo Remmele the following aberrations could be measured + # (enhanced mode, tilt angle > 30 mrad) but are not corrected b_4(NXaberration): d_4(NXaberration): a_4(NXaberration): @@ -68,97 +69,3 @@ type: group # It might be useful to collect all the corrector entries in one table, for example to analyse the performance of the corrector. # The corrector entry of the nexus em definition lacks the confidence information and the # parameter settings for the estimation oft the aberrations. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# ebaf08cdad8e660f423345fc69cd868e7abef455184ce0ed4674b987345a7318 -# -# -# -# -# -# CEOS definitions/model for aberrations of electro-magnetic lenses. -# -# See `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) -# for different definitions available and further details. Table 7-2 of Ibid. -# publication (page 305ff) documents how to convert from the NION to the -# CEOS definitions. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXaberration_model_nion.yaml b/contributed_definitions/nyaml/NXaberration_model_nion.yaml index 8afc7f6a9c..2d47ab703f 100644 --- a/contributed_definitions/nyaml/NXaberration_model_nion.yaml +++ b/contributed_definitions/nyaml/NXaberration_model_nion.yaml @@ -1,13 +1,13 @@ category: base doc: | - NION definitions/model for aberrations of electro-magnetic lenses. + Nion definitions/model for aberrations of electro-magnetic lenses. See `S. J. Pennycock and P. D. Nellist `_ (page 44ff, and page 118ff) for different definitions available and further details. Table 7-2 of Ibid. - publication (page 305ff) documents how to convert from the NION to the + publication (page 305ff) documents how to convert from the Nion to the CEOS definitions. type: group -(NXobject)NXaberration_model_nion: +NXaberration_model_nion(NXaberration_model): model: enumeration: [nion] c_1_0(NXaberration): @@ -35,69 +35,3 @@ type: group c_5_4_b(NXaberration): c_5_6_a(NXaberration): c_5_6_b(NXaberration): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 64006294c6d06a1d3736c1f67e7c2c4b72d055966858d441cef8a40261e4157e -# -# -# -# -# -# NION definitions/model for aberrations of electro-magnetic lenses. -# -# See `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) -# for different definitions available and further details. Table 7-2 of Ibid. -# publication (page 305ff) documents how to convert from the NION to the -# CEOS definitions. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXaperture_em.yaml b/contributed_definitions/nyaml/NXaperture_em.yaml index 6fef9f341f..8cbb3fc14c 100644 --- a/contributed_definitions/nyaml/NXaperture_em.yaml +++ b/contributed_definitions/nyaml/NXaperture_em.yaml @@ -1,92 +1,26 @@ category: base - -# extends: NXaperture doc: | - Details of an individual aperture for beams in electron microscopy. + Base class for an individual aperture for beams in electron microscopy. type: group -NXaperture_em(NXobject): - name: - doc: | - Given name/alias of the aperture. +NXaperture_em(NXcomponent_em): value(NX_NUMBER): - unit: NX_ANY doc: | Relevant value from the control software. - This is not always just the diameter of (not even in the case) - of a circular aperture. Usually it is a mode setting value which - is selected in the control software. - Which settings are behind the value should be defined - for now in the description field, if these are known - in more detail. - description: + This is not always just the diameter of the aperture (not even in the case) + of a circular aperture. Usually, it is a value that is set in the control + software whereby a specific configuration of an aperture is selected by the + software. + + The control software of commercial microscope typically offers the user + access at a high abstraction level because of which many details about + the actual settings of the electrical components are typically unknown. + + However, if more details are known or should be documented one should + use the description field for this. + unit: NX_ANY + description(NX_CHAR): doc: | Ideally, a (globally) unique persistent identifier, link, or text to a - resource which gives further details. Alternatively a free-text field. - (NXfabrication): - (NXtransformations): - doc: | - Affine transformation which detail the arrangement in the - microscope relative to the optical axis and beam path. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 831a962f213703ac0899f1f42b75ec460081ef736918a7b73c1cf779af3da589 -# -# -# -# -# -# -# Details of an individual aperture for beams in electron microscopy. -# -# -# -# Given name/alias of the aperture. -# -# -# -# -# Relevant value from the control software. -# -# This is not always just the diameter of (not even in the case) -# of a circular aperture. Usually it is a mode setting value which -# is selected in the control software. -# Which settings are behind the value should be defined -# for now in the description field, if these are known -# in more detail. -# -# -# -# -# Ideally, a (globally) unique persistent identifier, link, or text to a -# resource which gives further details. Alternatively a free-text field. -# -# -# -# -# -# Affine transformation which detail the arrangement in the -# microscope relative to the optical axis and beam path. -# -# -# + resource which gives further details. Alternatively a free-text field to + store details noteworthy for contextualization or more detail. diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml index ef2a8c771b..925aad4569 100644 --- a/contributed_definitions/nyaml/NXapm.yaml +++ b/contributed_definitions/nyaml/NXapm.yaml @@ -993,7 +993,7 @@ NXapm(NXobject): 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. + here is where such spatiotemporally data could be stored. # NEW ISSUE: consider the above comments into new fields when important progress has been made. initial_radius(NX_FLOAT): @@ -2642,7 +2642,7 @@ NXapm(NXobject): # 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. +# here is where such spatiotemporally data could be stored. # # # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml index c88d7e63a7..e04a5c6434 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml @@ -398,7 +398,7 @@ NXapm_paraprobe_results_nanochem(NXobject): Therefore, summating over the number_of_vertices, allows to extract the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. dimensions: rank: 2 dim: [[1, 6], [2, 4]] @@ -707,7 +707,7 @@ NXapm_paraprobe_results_nanochem(NXobject): Therefore, summating over the number_of_vertices, allows to extract the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. + of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. dimensions: rank: 1 dim: [[1, j]] diff --git a/contributed_definitions/nyaml/NXcg_alpha_complex.yaml b/contributed_definitions/nyaml/NXcg_alpha_complex.yaml index c1d9ea91c8..275a5e1065 100644 --- a/contributed_definitions/nyaml/NXcg_alpha_complex.yaml +++ b/contributed_definitions/nyaml/NXcg_alpha_complex.yaml @@ -1,6 +1,6 @@ category: base doc: | - Computational geometry description of alpha shapes or wrappings to primitives. + Computational geometry of alpha shapes or alpha wrappings about primitives. For details see: @@ -8,61 +8,43 @@ doc: | * https://dx.doi.org/10.1145/174462.156635 for 3D, * https://dl.acm.org/doi/10.5555/871114 for weighted, and * https://doc.cgal.org/latest/Alpha_shapes_3 for 3D implementation - * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D wrap + * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D wrappings in CGAL, the Computational Geometry Algorithms Library. As a starting point, we follow the conventions of the CGAL library. - -# weighted alpha shapes -# The so-called spectrum or sets of (weighted) alpha shapes includes the -# convex hull of a point set. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the alpha shape, for now 2 or 3. - - # generalize to d > 3 - n_e: | - The number of edges. - n_f: | - The number of faces. - n_c: | - The number of cells. +# The so-called spectrum or sets of (weighted) alpha shapes includes the convex hull of a point set. type: group -NXcg_alpha_complex(NXobject): - dimensionality(NX_UINT): - unit: NX_UNITLESS - enumeration: [2, 3] +NXcg_alpha_complex(NXcg_primitive_set): type: doc: | - Specify which general type of alpha shape is computed. - Using for now the CGAL terminology. Basic means (unweighted) alpha shapes. - Alpha_wrapping means meshes created using alpha wrapping procedures. + Type of alpha complex following the terminology used by CGAL for now. + + Basic means (unweighted) alpha shapes. Alpha_wrapping means meshes + created using the alpha_wrapping algorithm. enumeration: [convex_hull, alpha_shape, alpha_wrapping] - mode: + regularize_alpha_complex(NX_BOOLEAN): doc: | - Specifically when computed with the CGAL, the mode specifies if singular - faces are removed (regularized) of the alpha complex. - - # CHECK THIS AGAIN CAREFULLY - enumeration: [general, regularized] + Are singular faces removed, i.e. has the alpha complex + been regularized or not. + # R+0 means positive real number including zero which is a super set of NX_FLOAT and a sub-set of NX_NUMBER alpha(NX_NUMBER): - unit: NX_LENGTH doc: | - The alpha, (radius of the alpha-sphere) parameter to be used for alpha - shapes and alpha wrappings. - offset(NX_NUMBER): + The alpha parameter, i.e. the radius of the alpha-sphere that + is used when computing the alpha complex. unit: NX_LENGTH + # the dim: argument can be omitted to indicate that a scalar is expected + # means a length quantity, i.e. m, km, or nm is possible i.e. has to be length but no further constraints + # stating meter is a stronger constraint while m is the strongest constraint, meaning literally the value is m. + offset(NX_NUMBER): doc: | - The offset distance parameter to be used in addition to alpha - in the case of alpha_wrapping. - + The offset distance parameter used when computing alpha_wrappings. + unit: NX_LENGTH # check again carefully the CGAL documentation talks about, for 3D, the square of the radius! - point_set(NXcg_point_set): + point_setID(NXcg_point_set): + # basically just constraints that if you use one or more instances of NXcg_point_set + # inside an instance of NXcg_alpha_complex, name that group with the prefix "point_set" doc: | - Point cloud for which the alpha shape or wrapping should be computed. - + Point cloud for which the alpha shape or wrapping has been computed. # this could also just be implemented as a link but how would this be possible # unfold the NXcg_point_set and add a # weight(NX_NUMBER): @@ -72,182 +54,25 @@ NXcg_alpha_complex(NXobject): # so the number of cells, faces and edges depends on how a specific alpha complex, # i.e. an alpha-shape of S for alpha, is filtrated with respect to k < d-dimensional # simplices. Here we assume that number_of_cells, number_of_faces, number_of_edges - # are reported assuming one filtrates these simplices according to mode. + # are reported assuming one filtrates these simplices according to type. # also using the assumption the base class reports the unique vertices # of the specifically filtrated alpha complex. - triangle_set(NXcg_triangle_set): + triangle_setID(NXcg_triangle_set): doc: | - Triangle soup for which the alpha wrapping should be computed. - triangulation(NXcg_triangle_set): + Triangle soup for which the alpha wrapping has been computed. + triangle_meshID(NXcg_triangle_set): # should be a mesh doc: | - A meshed representation of the resulting shape. - - # should be a mesh + Triangle mesh representing the alpha complex. # add for each triangle if desirable a notation of whether the simplex is # exterior, regular, singular, or interior with respect to the alpha complex - # but a triangulation is more than a triangle (soup)/set because there is - # connectivity information - # customize the NXcg_triangle_set base class members such that connectivity - # information is contained + # a triangulation is more than a triangle (soup)/set because there it has connectivity + # customize the NXcg_triangle_set base class members such that connectivity can be contained naturally # we need to find also a better name for this, what people intutive understand # as the interior, may not even exist for a given alpha value # more specifically it is the set of filtrated cells acknowledging mode # e.g. the interior cells of the regularized alpha complex - interior_cells(NXcg_tetrahedron_set): - + interior_cellsID(NXcg_tetrahedron_set): + doc: | + Set of tetrahedra representing the volume inside the alpha complex. # document the alpha status # https://doc.cgal.org/latest/Alpha_shapes_3/classCGAL_1_1Alpha__status.html - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 9f7873863060d94e12baf1e7de9592761ad41c13677af7af3c0e1f5db6228950 -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality of the alpha shape, for now 2 or 3. -# -# -# -# -# -# The number of edges. -# -# -# -# -# The number of faces. -# -# -# -# -# The number of cells. -# -# -# -# -# Computational geometry description of alpha shapes or wrappings to primitives. -# -# For details see: -# -# * https://dx.doi.org/10.1109/TIT.1983.1056714 for 2D, -# * https://dx.doi.org/10.1145/174462.156635 for 3D, -# * https://dl.acm.org/doi/10.5555/871114 for weighted, and -# * https://doc.cgal.org/latest/Alpha_shapes_3 for 3D implementation -# * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D wrap -# -# in CGAL, the Computational Geometry Algorithms Library. -# As a starting point, we follow the conventions of the CGAL library. -# -# -# -# -# -# -# -# -# -# Specify which general type of alpha shape is computed. -# Using for now the CGAL terminology. Basic means (unweighted) alpha shapes. -# Alpha_wrapping means meshes created using alpha wrapping procedures. -# -# -# -# -# -# -# -# -# -# Specifically when computed with the CGAL, the mode specifies if singular -# faces are removed (regularized) of the alpha complex. -# -# -# -# -# -# -# -# -# -# The alpha, (radius of the alpha-sphere) parameter to be used for alpha -# shapes and alpha wrappings. -# -# -# -# -# The offset distance parameter to be used in addition to alpha -# in the case of alpha_wrapping. -# -# -# -# -# -# Point cloud for which the alpha shape or wrapping should be computed. -# -# -# -# -# -# Triangle soup for which the alpha wrapping should be computed. -# -# -# -# -# A meshed representation of the resulting shape. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_cylinder_set.yaml b/contributed_definitions/nyaml/NXcg_cylinder_set.yaml index 157d0a97d8..65b686032e 100644 --- a/contributed_definitions/nyaml/NXcg_cylinder_set.yaml +++ b/contributed_definitions/nyaml/NXcg_cylinder_set.yaml @@ -1,292 +1,87 @@ category: base doc: | - Computational geometry description of a set of cylinders in Euclidean space. + Computational geometry description of a set of cylinders. - The members of the set can have different size. For each member the position - of the center and the height is mandatory. The radius can either be defined - in the radius field or by filling both the upper and the lower radius field. - The latter case can be used to represent truncated cones. + The radius can either be defined in the radii field or by filling both + the upper_cap_radii or lower_cap_radii field. The latter field case can + thus be used to represent truncated cones. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality of the space in which the members are assumed embedded. c: | - The cardinality of the set, i.e. the number of cylinders or cones. - + The cardinality of the set, i.e. the number of members. # redundant as there is NXcsg, NXquadric, NXsolid_geometry with which # cylinder could be constructed, but NXcylinder is easier to understand type: group -NXcg_cylinder_set(NXobject): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - enumeration: [3] - cardinality(NX_POSINT): - unit: NX_UNITLESS - identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer which specifies the first index to be used for distinguishing - identifiers for cylinders. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - identifier(NX_INT): - doc: | - Integer used to distinguish members for explicit indexing. - dimensions: - rank: 1 - dim: [[1, c]] - center(NX_NUMBER): - unit: NX_LENGTH - doc: | - The geometric center of each member. - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] +NXcg_cylinder_set(NXcg_primitive_set): height(NX_NUMBER): - unit: NX_LENGTH doc: | - A direction vector which is parallel to the cylinder/cone axis and - whose magnitude is the height of the cylinder/cone. - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] - + A direction vector which is parallel to the cylinder/cone axis + and whose magnitude is the height of the cylinder/cone. + unit: NX_LENGTH + dim: (c, d) + # observe that although we claim that d is the dimensionality we have + # currently no strategy to tell it must not be d but the actual value + # equally so the symbol c, currently all we say that in the specialization + # defined here the fields radii, upper_cap_radius, and others are all having + # value arguments of the same shape, i.e. these are arrays of rank one with some length c! + # behind the dimensionality field defined either in the here defined specialization + # of NXcg_primitive_set or otherwise that variable is undefined # alternatively one could store the center of the lower and upper cap but # these are then no longer necessarily on the same axis # maybe a future feature for representing skewed cylinder, but then # one should really better use NXquadric... - radii(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, c]] - upper_cap_radius(NX_NUMBER): + radius(NX_NUMBER): + doc: | + Radius of the cylinder if all have the same radius. unit: NX_LENGTH + radii(NX_NUMBER): doc: | - The radius of the upper circular cap. - This field, combined with lower_cap_radius can be used to - describe (eventually truncated) circular cones. - dimensions: - rank: 1 - dim: [[1, c]] - lower_cap_radius(NX_NUMBER): + Radii of the cylinder. unit: NX_LENGTH + dim: (c,) + upper_cap_radii(NX_NUMBER): doc: | - The radius of the upper circular cap. - This field, combined with lower_cap_radius can be used to - describe (eventually truncated) circular cones. - dimensions: - rank: 1 - dim: [[1, c]] - (NXtransformations): + Radii of the upper circular cap. + + This field, combined with lower_cap_radius can be used to describe + (eventually truncated) circular cones. + unit: NX_LENGTH + dim: (c,) + lower_cap_radii(NX_NUMBER): doc: | - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - + Radii of the upper circular cap. + + This field, combined with upper_cap_radius can be used to describe + (eventually truncated) circular cones. + unit: NX_LENGTH + dim: (c,) # properties of the cylinder - volume(NX_NUMBER): - unit: NX_VOLUME - doc: | - Interior volume of each cylinder - dimensions: - rank: 1 - dim: [[1, c]] lateral_surface_area(NX_NUMBER): - unit: NX_AREA doc: | Lateral surface area - dimensions: - rank: 1 - dim: [[1, c]] - cap_surface_area(NX_NUMBER): unit: NX_AREA + dim: (c,) + upper_cap_surface_area(NX_NUMBER): doc: | - Area of the upper and the lower cap of each cylinder respectively. - dimensions: - rank: 2 - dim: [[1, c], [2, 2]] - surface_area(NX_NUMBER): + Area of the upper cap of each cylinder. unit: NX_AREA + dim: (c,) + lower_cap_surface_area(NX_NUMBER): doc: | - Cap and lateral surface area for each cylinder. - dimensions: - rank: 1 - dim: [[1, c]] - + Area of the lower cap of each cylinder. + unit: NX_AREA + dim: (c,) + total_surface_area(NX_NUMBER): # example for a specialization of surface_area from the NXcg_primitive_set + doc: | + Sum of upper and lower cap areas and lateral surface area + of each cylinder. + unit: NX_AREA + dim: (c,) # again cap, lateral surface area and volume are so trivial to compute # do we need really storage for this or recompute on-the-fly? # similarly to hollow sphere discussion, hollow cylinder, cylinder stack # do wish to define intersections?, if this is the case, one # should use the NXcsg and NXquadric descriptions? - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 815fb407122ebed44d9cdc549536e85234abe1c87ed7bb357cf6eee85bfc8dd9 -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The cardinality of the set, i.e. the number of cylinders or cones. -# -# -# -# -# Computational geometry description of a set of cylinders in Euclidean space. -# -# The members of the set can have different size. For each member the position -# of the center and the height is mandatory. The radius can either be defined -# in the radius field or by filling both the upper and the lower radius field. -# The latter case can be used to represent truncated cones. -# -# -# -# -# -# -# -# -# -# Integer which specifies the first index to be used for distinguishing -# identifiers for cylinders. Identifiers are defined either implicitly -# or explicitly. For implicit indexing the identifiers are defined on the -# interval [identifier_offset, identifier_offset+c-1]. -# For explicit indexing the identifier array has to be defined. -# -# The identifier_offset field can for example be used to communicate if the -# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) -# or from 0 (referred to as C-, Python-style index notation) respectively. -# -# -# -# -# Integer used to distinguish members for explicit indexing. -# -# -# -# -# -# -# -# The geometric center of each member. -# -# -# -# -# -# -# -# -# A direction vector which is parallel to the cylinder/cone axis and -# whose magnitude is the height of the cylinder/cone. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The radius of the upper circular cap. -# This field, combined with lower_cap_radius can be used to -# describe (eventually truncated) circular cones. -# -# -# -# -# -# -# -# The radius of the upper circular cap. -# This field, combined with lower_cap_radius can be used to -# describe (eventually truncated) circular cones. -# -# -# -# -# -# -# -# Reference to or definition of a coordinate system with -# which the positions and directions are interpretable. -# -# -# -# -# -# Interior volume of each cylinder -# -# -# -# -# -# -# -# Lateral surface area -# -# -# -# -# -# -# -# Area of the upper and the lower cap of each cylinder respectively. -# -# -# -# -# -# -# -# -# Cap and lateral surface area for each cylinder. -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml b/contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml index 2fdb47e471..9aab0dffaf 100644 --- a/contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml +++ b/contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml @@ -1,234 +1,26 @@ category: base doc: | - Computational geometry description of a set of ellipsoids in Euclidean space. - - Individual ellipsoids can have different half axes. + Computational geometry description of a set of ellipsoids. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. d: | - The dimensionality, which has to be at least 2. + The dimensionality of the space in which the members are assumed embedded. c: | - The cardinality of the set, i.e. the number of ellipses, or ellipsoids. - + The cardinality of the set, i.e. the number of members. # redundant as there is NXcsg, and NXquadric but easier to understand type: group -NXcg_ellipsoid_set(NXobject): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - cardinality(NX_POSINT): - unit: NX_UNITLESS - identifier_offset(NX_INT): - unit: NX_UNITLESS +NXcg_ellipsoid_set(NXcg_primitive_set): + half_axes_radius(NX_NUMBER): doc: | - Integer which specifies the first index to be used for distinguishing - identifiers for ellipsoids. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. + Radius of the half axes. - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Integer used to distinguish ellipsoids for explicit indexing. - dimensions: - rank: 1 - dim: [[1, c]] - center(NX_NUMBER): - unit: NX_LENGTH - doc: | - Geometric center of the ellipsoids. This can be the center of mass. - Dimensionality and cardinality of the point and ellipsoid set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the ellipsoids. - dimensions: - rank: 2 - dim: [[1, c], [2, d]] - half_axes_radius(NX_NUMBER): + Use if all ellipsoids in the set have the same half-axes. unit: NX_LENGTH - doc: | - If all ellipsoids in the set have the same half-axes. - dimensions: - rank: 1 - dim: [[1, d]] + dim: (d,) half_axes_radii(NX_NUMBER): - unit: NX_LENGTH - doc: | - In the case that ellipsoids have different radii use this field - instead of half_axes_radius. - dimensions: - rank: 2 - dim: [[1, c], [2, d]] - (NXtransformations): doc: | - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - + Half-axes radii of each ellipsoid. + unit: NX_LENGTH + dim: (c, d) # properties of ellipsoids - is_closed(NX_BOOLEAN): - doc: | - Are the ellipsoids closed or hollow? - dimensions: - rank: 1 - dim: [[1, c]] - volume(NX_NUMBER): - unit: NX_ANY - dimensions: - rank: 1 - dim: [[1, c]] - surface_area(NX_NUMBER): - unit: NX_ANY - dimensions: - rank: 1 - dim: [[1, c]] - - # NXcg_orientation_set - orientation(NX_NUMBER): - unit: NX_DIMENSIONLESS - doc: | - Direction unit vector which points along the largest half-axes. - dimensions: - rank: 2 - dim: [[1, c], [2, d]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 62a35f2abe55a465447b99935846b1a3ff9ae13935511d32899a79a49e30c499 -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality, which has to be at least 2. -# -# -# -# -# The cardinality of the set, i.e. the number of ellipses, or ellipsoids. -# -# -# -# -# Computational geometry description of a set of ellipsoids in Euclidean space. -# -# Individual ellipsoids can have different half axes. -# -# -# -# -# -# Integer which specifies the first index to be used for distinguishing -# identifiers for ellipsoids. Identifiers are defined either implicitly -# or explicitly. For implicit indexing the identifiers are defined on the -# interval [identifier_offset, identifier_offset+c-1]. -# For explicit indexing the identifier array has to be defined. -# -# The identifier_offset field can for example be used to communicate if the -# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) -# or from 0 (referred to as C-, Python-style index notation) respectively. -# -# -# -# -# Integer used to distinguish ellipsoids for explicit indexing. -# -# -# -# -# -# -# -# Geometric center of the ellipsoids. This can be the center of mass. -# Dimensionality and cardinality of the point and ellipsoid set have to match. -# The identifier_offset and identifier field of NXcg_point_set do not need -# to be used as they should be same as the identifier_offset and the -# identifier for the ellipsoids. -# -# -# -# -# -# -# -# -# If all ellipsoids in the set have the same half-axes. -# -# -# -# -# -# -# -# In the case that ellipsoids have different radii use this field -# instead of half_axes_radius. -# -# -# -# -# -# -# -# -# Reference to or definition of a coordinate system with -# which the positions and directions are interpretable. -# -# -# -# -# -# Are the ellipsoids closed or hollow? -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction unit vector which points along the largest half-axes. -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml b/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml index 13442c81c9..4f33188c79 100644 --- a/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml +++ b/contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml @@ -1,26 +1,19 @@ category: base doc: | - Computational geometry description of geometric primitives via a face and edge list. + Computational geometry of primitives via a face-and-edge-list data structure. - Primitives must not be degenerated or self-intersect. - Such descriptions of primitives are frequently used for triangles and polyhedra - to store them on disk for visualization purposes. Although storage efficient, - such a description is not well suited for topological and neighborhood queries - of especially meshes that are built from primitives. + Primitives must neither be degenerated nor self-intersect but can differ in + their properties. A face-and-edge-list-based description of primitives is + frequently used for triangles and polyhedra to store them on disk for + visualization purposes (see OFF, PLY, VTK, or STL file formats). - In this case, scientists may need a different view on the primitives which - is better represented for instance with a half_edge_data_structure instance. - The reason to split thus the geometric description of primitives, sets, and - specifically meshes of primitives is to keep the structure simple enough for - users without these computational geometry demands but also enable those more - computational geometry savy users the storing of the additionally relevant - data structure. + Although this description is storage efficient it is not well suited for + topological analyses though. In this case, scientists may need a different + view on the primitives which is better represented with e.g. a + half_edge_data_structure. - This is beneficial and superior over NXoff_geometry because for instance a - half_edge_data_structure instance can be immediately use to reinstantiate - the set without having to recompute the half_edge_structure from the vertex - and face-list based representation and thus offer a more efficient route - to serve applications where topological and graph-based operations are key. + Having an own base class for the data structure how primitives are stored is + useful to embrace both users with small or very detailed specification demands. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -36,116 +29,96 @@ symbols: The total number of vertices of all faces. Faces are polygons. n_weinberg: | The total number of Weinberg vector values of all faces. - # duplicate of an NXoff_geometry ? type: group NXcg_face_list_data_structure(NXobject): + \@depends_on(NX_CHAR): + doc: | + Hint to help resolve in which Euclidean coordinate system + field values vertices are defined. dimensionality(NX_POSINT): - unit: NX_UNITLESS doc: | - Dimensionality. - - # resulting in a design similar to that of NXoff_geometry and the XDMF mixed primitive topology - number_of_vertices(NX_POSINT): + Dimensionality of the primitives described. unit: NX_UNITLESS + # resulting in a design similar to that of NXoff_geometry and the XDMF mixed primitive topology + number_of_vertices(NX_INT): doc: | - Array which specifies of how many vertices each face is built. - Each entry represent the total number of vertices for face, irrespectively - whether vertices are shared among faces/are unique or not. - dimensions: - rank: 1 - dim: [[1, n_f]] - number_of_edges(NX_POSINT): + Number of vertices for each face. + + Each entry represents the total number of vertices for that face, + irrespectively whether vertices are shared among faces or not. unit: NX_UNITLESS + dim: (n_f,) + number_of_edges(NX_INT): doc: | - Number of edges. - number_of_faces(NX_POSINT): + Number of edges for each face. + + Each entry represents the total number of edges for that face, + irrespectively whether edges are shared across faces or not. unit: NX_UNITLESS + dim: (n_e,) + number_of_faces(NX_INT): doc: | - Number of faces. - vertex_identifier_offset(NX_INT): + Number of faces of the primitives. unit: NX_UNITLESS + vertex_identifier_offset(NX_INT): doc: | - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. + Integer offset whereby the identifier of the first member + of the vertices differs from zero. - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - edge_identifier_offset(NX_INT): + Identifier can be defined explicitly or implicitly. + Inspect the definition of NXcg_primitive_set for further details. unit: NX_UNITLESS + edge_identifier_offset(NX_INT): doc: | - Integer which specifies the first index to be used for distinguishing - identifiers for edges. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. + Integer offset whereby the identifier of the first member + of the edges differs from zero. - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - face_identifier_offset(NX_INT): + Identifier can be defined explicitly or implicitly. + Inspect the definition of NXcg_primitive_set for further details. unit: NX_UNITLESS + face_identifier_offset(NX_INT): doc: | - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. + Integer offset whereby the identifier of the first member + of the faces differs from zero. - The identifier_offset field can for example be used to communicate if - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. + Identifier can be defined explicitly or implicitly. + Inspect the definition of NXcg_primitive_set for further details. + unit: NX_UNITLESS vertex_identifier(NX_INT): unit: NX_UNITLESS doc: | - Integer used to distinguish vertices explicitly. - dimensions: - rank: 1 - dim: [[1, n_v]] + Integer identifier to distinguish all vertices explicitly. + dim: (n_v,) edge_identifier(NX_INT): - unit: NX_UNITLESS doc: | - Integer used to distinguish edges explicitly. - dimensions: - rank: 1 - dim: [[1, n_e]] - face_identifier(NX_INT): + Integer used to distinguish all edges explicitly. unit: NX_UNITLESS + dim: (n_e,) + face_identifier(NX_INT): doc: | - Integer used to distinguish faces explicitly. - dimensions: - rank: 1 - dim: [[1, n_f]] + Integer used to distinguish all faces explicitly. + unit: NX_UNITLESS + dim: (n_f,) vertices(NX_NUMBER): - unit: NX_LENGTH doc: | Positions of the vertices. - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. + Users are encouraged to reduce the vertices to a unique set as this may + result in a more efficient storage of the geometry data. It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - dimensions: - rank: 2 - dim: [[1, n_v], [2, d]] + case vertices_are_unique is likely False. Naively here means that each + vertex is stored even though many share the same positions. + unit: NX_ANY + dim: (n_v, d) edges(NX_INT): - unit: NX_UNITLESS doc: | - The edges are stored as a pairs of vertex identifier values. - dimensions: - rank: 2 - dim: [[1, n_e], [2, 2]] - faces(NX_INT): + The edges are stored as pairs of vertex identifier. unit: NX_UNITLESS + dim: (n_e, 2) + faces(NX_INT): doc: | - Array of identifiers from vertices which describe each face. + The faces are stored as a concatenated array of vertex identifier tuples. The first entry is the identifier of the start vertex of the first face, followed by the second vertex of the first face, until the last vertex @@ -154,276 +127,29 @@ NXcg_face_list_data_structure(NXobject): Therefore, summating over the number_of_vertices, allows to extract the vertex identifiers for the i-th face on the following index interval - of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. - dimensions: - rank: 1 - dim: [[1, n_total]] - + of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. + unit: NX_UNITLESS + dim: (n_total,) # properties vertices_are_unique(NX_BOOLEAN): doc: | - If true indicates that the vertices are all placed at different positions - and have different identifiers, i.e. no points overlap or are counted twice. + If true, indicates that the vertices are all placed at different positions + and have different identifiers, i.e. no points overlap or are counted more + than once. edges_are_unique(NX_BOOLEAN): doc: | - If true indicates that no edge is stored twice. Users are encouraged to - consider and use the half_edge_data_structure instead as this will work - towards achieving a cleaner graph-based description if relevant and possible. + If true, indicates that no edge is stored more than once. + + Users are encouraged to consider using a half_edge_data_structure instead. faces_are_unique(NX_BOOLEAN): + doc: | + If true, indicates that no face is stored more than once. winding_order(NX_INT): - unit: NX_UNITLESS doc: | Specifies for each face which winding order was used if any: * 0 - undefined * 1 - counter-clockwise (CCW) * 2 - clock-wise (CW) - dimensions: - rank: 1 - dim: [[1, n_f]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4718c5ea6858b75fb10fcc11ec57c04c5208050e8c7b77fe9177a8f5e4ee7d96 -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality, which has to be at least 2. -# -# -# -# -# The number of vertices. -# -# -# -# -# The number of edges. -# -# -# -# -# The number of faces. -# -# -# -# -# The total number of vertices of all faces. Faces are polygons. -# -# -# -# -# The total number of Weinberg vector values of all faces. -# -# -# -# -# Computational geometry description of geometric primitives via a face and edge list. -# -# Primitives must not be degenerated or self-intersect. -# Such descriptions of primitives are frequently used for triangles and polyhedra -# to store them on disk for visualization purposes. Although storage efficient, -# such a description is not well suited for topological and neighborhood queries -# of especially meshes that are built from primitives. -# -# In this case, scientists may need a different view on the primitives which -# is better represented for instance with a half_edge_data_structure instance. -# The reason to split thus the geometric description of primitives, sets, and -# specifically meshes of primitives is to keep the structure simple enough for -# users without these computational geometry demands but also enable those more -# computational geometry savy users the storing of the additionally relevant -# data structure. -# -# This is beneficial and superior over NXoff_geometry because for instance a -# half_edge_data_structure instance can be immediately use to reinstantiate -# the set without having to recompute the half_edge_structure from the vertex -# and face-list based representation and thus offer a more efficient route -# to serve applications where topological and graph-based operations are key. -# -# -# -# Dimensionality. -# -# -# -# -# -# Array which specifies of how many vertices each face is built. -# Each entry represent the total number of vertices for face, irrespectively -# whether vertices are shared among faces/are unique or not. -# -# -# -# -# -# -# -# Number of edges. -# -# -# -# -# Number of faces. -# -# -# -# -# Integer which specifies the first index to be used for distinguishing -# identifiers for vertices. Identifiers are defined either implicitly -# or explicitly. For implicit indexing the identifiers are defined on the -# interval [identifier_offset, identifier_offset+c-1]. -# For explicit indexing the identifier array has to be defined. -# -# The identifier_offset field can for example be used to communicate if -# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) -# or from 0 (referred to as C-, Python-style index notation) respectively. -# -# -# -# -# Integer which specifies the first index to be used for distinguishing -# identifiers for edges. Identifiers are defined either implicitly -# or explicitly. For implicit indexing the identifiers are defined on the -# interval [identifier_offset, identifier_offset+c-1]. -# For explicit indexing the identifier array has to be defined. -# -# The identifier_offset field can for example be used to communicate if -# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) -# or from 0 (referred to as C-, Python-style index notation) respectively. -# -# -# -# -# Integer which specifies the first index to be used for distinguishing -# identifiers for faces. Identifiers are defined either implicitly -# or explicitly. For implicit indexing the identifiers are defined on the -# interval [identifier_offset, identifier_offset+c-1]. -# For explicit indexing the identifier array has to be defined. -# -# The identifier_offset field can for example be used to communicate if -# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) -# or from 0 (referred to as C-, Python-style index notation) respectively. -# -# -# -# -# Integer used to distinguish vertices explicitly. -# -# -# -# -# -# -# -# Integer used to distinguish edges explicitly. -# -# -# -# -# -# -# -# Integer used to distinguish faces explicitly. -# -# -# -# -# -# -# -# Positions of the vertices. -# -# Users are encouraged to reduce the vertices to unique set of positions -# and vertices as this supports a more efficient storage of the geometry data. -# It is also possible though to store the vertex positions naively in which -# case vertices_are_unique is likely False. -# Naively here means that one for example stores each vertex of a triangle -# mesh even though many vertices are shared between triangles and thus -# the positions of these vertices do not have to be duplicated. -# -# -# -# -# -# -# -# -# The edges are stored as a pairs of vertex identifier values. -# -# -# -# -# -# -# -# -# Array of identifiers from vertices which describe each face. -# -# The first entry is the identifier of the start vertex of the first face, -# followed by the second vertex of the first face, until the last vertex -# of the first face. Thereafter, the start vertex of the second face, the -# second vertex of the second face, and so on and so forth. -# -# Therefore, summating over the number_of_vertices, allows to extract -# the vertex identifiers for the i-th face on the following index interval -# of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. -# -# -# -# -# -# -# -# -# If true indicates that the vertices are all placed at different positions -# and have different identifiers, i.e. no points overlap or are counted twice. -# -# -# -# -# If true indicates that no edge is stored twice. Users are encouraged to -# consider and use the half_edge_data_structure instead as this will work -# towards achieving a cleaner graph-based description if relevant and possible. -# -# -# -# -# -# Specifies for each face which winding order was used if any: -# -# * 0 - undefined -# * 1 - counter-clockwise (CCW) -# * 2 - clock-wise (CW) -# -# -# -# -# -# + unit: NX_UNITLESS + dim: (n_f,) diff --git a/contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml b/contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml index b699a269fb..0f4f9afc64 100644 --- a/contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml +++ b/contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml @@ -2,90 +2,30 @@ category: base doc: | Computational geometry description of a geodesic mesh. - People from geodesic/surveyors will likely have specific demands and - different views about what should be included in such a base class, given - that nested geodesic meshes are a key component of climate modelling tools. - For now we propose to use this base class as a container to organize metadata - and data related to geodesic meshes. + A geodesic surface mesh is a triangulated surface mesh with metadata which + can be used as an approximation to describe the surface of a sphere. + Triangulation of spheres are commonly used in Materials Science + for quantifying texture of materials, i.e. the relative rotation of + crystals to sample directions. - Specifically an instance of this base class should detail the rule set how - how the geodesic (surface) mesh was instantiated as there are many - possibilities. A geodesic surface mesh is in this sense a triangulated - surface mesh with metadata. For additional details as an introduction - into the topic see e.g.: + For additional details or an introduction into the topic of geodesic meshes + see (from which specifically the section on subdivision schemes is relevant). * `E. S. Popko and C. J. Kitrick `_ - Here, especially the section on subdivision schemes is relevant. + Earth scientists have specific demands and different views about what should + be included in such a base class, given that nested geodesic meshes are a key + component of climate modelling software. For now we propose to use this + base class as a container for organizing data related to geodesic meshes. + + Specifically an instance of this base class should detail the rule set how + e.g. a geodesic (surface) mesh was instantiated as there are many + possibilities to do so. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. type: group -NXcg_geodesic_mesh(NXobject): - (NXtransformations): - doc: | - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. +NXcg_geodesic_mesh(NXcg_primitive_set): (NXcg_triangulated_surface_mesh): # Discussions with NFDI-Earth could make this base class more meaty and detailed. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# faf25da56eb05eb830cdd732526a40f09965fa99c410890826ba5a3fc9eb237a -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Computational geometry description of a geodesic mesh. -# -# People from geodesic/surveyors will likely have specific demands and -# different views about what should be included in such a base class, given -# that nested geodesic meshes are a key component of climate modelling tools. -# For now we propose to use this base class as a container to organize metadata -# and data related to geodesic meshes. -# -# Specifically an instance of this base class should detail the rule set how -# how the geodesic (surface) mesh was instantiated as there are many -# possibilities. A geodesic surface mesh is in this sense a triangulated -# surface mesh with metadata. For additional details as an introduction -# into the topic see e.g.: -# -# * `E. S. Popko and C. J. Kitrick <https://doi.org/10.1201/9781003134114>`_ -# -# Here, especially the section on subdivision schemes is relevant. -# -# -# -# Reference to or definition of a coordinate system with -# which the positions and directions are interpretable. -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_grid.yaml b/contributed_definitions/nyaml/NXcg_grid.yaml index ba677dd5bf..de8cf9c8f3 100644 --- a/contributed_definitions/nyaml/NXcg_grid.yaml +++ b/contributed_definitions/nyaml/NXcg_grid.yaml @@ -1,116 +1,81 @@ category: base doc: | - Computational geometry description of a Wigner-Seitz cell grid in Euclidean space. + Computational geometry description of a grid of Wigner-Seitz cells in Euclidean space. - Frequently convenient three-dimensional grids with cubic cells are used. - Exemplar applications are spectral-solver based crystal plasticity - and stencil methods like phase-field or cellular automata. + Three-dimensional grids with cubic cells are if not the most frequently used + example of such grids. Examples of numerical methods where grids are used + are spectral-solver based crystal plasticity or other stencil methods like + phase-field or cellular automata. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. d: | The dimensionality of the grid. c: | - The cardinality or total number of cells/grid points. + The cardinality or total number of cells aka grid points. n_b: | - Number of boundaries of the bounding box or primitive to the grid. + Number of boundaries of the bounding box or primitive housing the grid. type: group -NXcg_grid(NXobject): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - enumeration: [1, 2, 3] - cardinality(NX_POSINT): - unit: NX_UNITLESS +NXcg_grid(NXcg_primitive_set): origin(NX_NUMBER): - dimensions: - rank: 1 - dim: [[1, d]] - symmetry: + doc: | + Location of the origin of the grid. + + Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` + class to specify the coordinate system in which the origin location is defined. + unit: NX_ANY + dim: (d,) + symmetry(NX_CHAR): doc: | The symmetry of the lattice defining the shape of the unit cell. - enumeration: [cubic] + enumeration: [cubic] # enumerate all other possible tilings of R^d cell_dimensions(NX_NUMBER): - unit: NX_LENGTH doc: | The unit cell dimensions using crystallographic notation. - dimensions: - rank: 1 - dim: [[1, d]] - extent(NX_POSINT): - unit: NX_UNITLESS + unit: NX_LENGTH + dim: (d,) + extent(NX_INT): doc: | Number of unit cells along each of the d unit vectors. - The total number of cells, or grid points has to be the cardinality. + + The total number of cells or grid points has to be the cardinality. If the grid has an irregular number of grid positions in each direction, as it could be for instance the case of a grid where all grid points outside some masking primitive are removed, this extent field should - not be used. Instead use the coordinate field. - dimensions: - rank: 1 - dim: [[1, d]] - (NXtransformations): - doc: | - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - + not be used. Instead, use the coordinate field. + unit: NX_UNITLESS + dim: (d,) # number_of_cells(NX_UINT): maybe already too trivial quantities # should constraints on the grid be place here or not - identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer which specifies the first index to be used for distinguishing - identifiers for cells. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Integer used to distinguish cells for explicit indexing. - dimensions: - rank: 1 - dim: [[1, c]] position(NX_NUMBER): - unit: NX_LENGTH doc: | Position of each cell in Euclidean space. - dimensions: - rank: 2 - dim: [[1, c], [2, d]] + unit: NX_ANY + dim: (c, d) coordinate(NX_INT): - unit: NX_DIMENSIONLESS doc: | Coordinate of each cell with respect to the discrete grid. - dimensions: - rank: 2 - dim: [[1, c], [2, d]] - + unit: NX_DIMENSIONLESS + dim: (c, d) # this should be a ROI bounding_box(NXcg_polyhedron_set): doc: | - A tight bounding box or sphere or bounding primitive about the grid. - + A tight bounding box about the grid. + # does it have to be a tight bounding box? # a good example for a general bounding box description for such a grids of triclinic cells # https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallelepiped - number_of_boundaries(NX_POSINT): - unit: NX_UNITLESS + number_of_boundaries(NX_INT): doc: | - How many distinct boundaries are distinguished? + Number of boundaries distinguished + Most grids discretize a cubic or cuboidal region. In this case six sides can be distinguished, each making an own boundary. - boundaries: + unit: NX_UNITLESS + boundaries(NX_CHAR): doc: | - Name of domain boundaries of the simulation box/ROI e.g. left, right, - front, back, bottom, top. - - # The field must have as many entries as there are number_of_boundaries. - dimensions: - rank: 1 - dim: [[1, n_b]] + Name of domain boundaries of the simulation box/ROI + e.g. left, right, front, back, bottom, top. + dim: (n_b,) boundary_conditions(NX_INT): unit: NX_UNITLESS doc: | @@ -122,190 +87,4 @@ NXcg_grid(NXobject): 3 - mirror 4 - von Neumann 5 - Dirichlet - dimensions: - rank: 1 - dim: [[1, n_b]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4886eebe9a97fb5801d8ffb55af96f612ba6d26959398324cf07cde6b5aa7e66 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality of the grid. -# -# -# -# -# The cardinality or total number of cells/grid points. -# -# -# -# -# Number of boundaries of the bounding box or primitive to the grid. -# -# -# -# -# Computational geometry description of a Wigner-Seitz cell grid in Euclidean space. -# -# Frequently convenient three-dimensional grids with cubic cells are used. -# Exemplar applications are spectral-solver based crystal plasticity -# and stencil methods like phase-field or cellular automata. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The symmetry of the lattice defining the shape of the unit cell. -# -# -# -# -# -# -# -# The unit cell dimensions using crystallographic notation. -# -# -# -# -# -# -# -# Number of unit cells along each of the d unit vectors. -# The total number of cells, or grid points has to be the cardinality. -# If the grid has an irregular number of grid positions in each direction, -# as it could be for instance the case of a grid where all grid points -# outside some masking primitive are removed, this extent field should -# not be used. Instead use the coordinate field. -# -# -# -# -# -# -# -# Reference to or definition of a coordinate system with -# which the positions and directions are interpretable. -# -# -# -# -# -# Integer which specifies the first index to be used for distinguishing -# identifiers for cells. Identifiers are defined either implicitly -# or explicitly. For implicit indexing the identifiers are defined on the -# interval [identifier_offset, identifier_offset+c-1]. -# For explicit indexing the identifier array has to be defined. -# -# The identifier_offset field can for example be used to communicate if the -# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) -# or from 0 (referred to as C-, Python-style index notation) respectively. -# -# -# -# -# Integer used to distinguish cells for explicit indexing. -# -# -# -# -# -# -# -# Position of each cell in Euclidean space. -# -# -# -# -# -# -# -# -# Coordinate of each cell with respect to the discrete grid. -# -# -# -# -# -# -# -# -# -# A tight bounding box or sphere or bounding primitive about the grid. -# -# -# -# -# -# How many distinct boundaries are distinguished? -# Most grids discretize a cubic or cuboidal region. In this case -# six sides can be distinguished, each making an own boundary. -# -# -# -# -# Name of domain boundaries of the simulation box/ROI e.g. left, right, -# front, back, bottom, top. -# -# -# -# -# -# -# -# -# The boundary conditions for each boundary: -# -# 0 - undefined -# 1 - open -# 2 - periodic -# 3 - mirror -# 4 - von Neumann -# 5 - Dirichlet -# -# -# -# -# -# + dim: (n_b,) diff --git a/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml b/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml index 0527443d20..de58e12e70 100644 --- a/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml +++ b/contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml @@ -4,7 +4,6 @@ doc: | Such a data structure can be used to efficiently circulate around faces and iterate over vertices of a planar graph. - # holes in the polygon mesh can be handled symbols: doc: | @@ -19,99 +18,100 @@ symbols: The number of half-edges. type: group NXcg_half_edge_data_structure(NXobject): + \@depends_on(NX_CHAR): + doc: | + Hint to help resolve in which Euclidean coordinate system + field values vertices are defined. dimensionality(NX_POSINT): + doc: | + Dimensionality of the primitives described. unit: NX_UNITLESS - number_of_vertices(NX_POSINT): + # resulting in a design similar to that of NXoff_geometry and the XDMF mixed primitive topology + number_of_vertices(NX_INT): + doc: | + Number of vertices for each face. + + Each entry represents the total number of vertices for that face, + irrespectively whether vertices are shared among faces or not. unit: NX_UNITLESS - number_of_faces(NX_POSINT): + dim: (n_f,) + number_of_edges(NX_INT): + doc: | + Number of edges for each face. + + Each entry represents the total number of edges for that face, + irrespectively whether edges are shared across faces or not. unit: NX_UNITLESS - number_of_half_edges(NX_POSINT): + dim: (n_e,) + number_of_faces(NX_INT): + doc: | + Number of faces of the primitives. unit: NX_UNITLESS vertex_identifier_offset(NX_INT): - unit: NX_UNITLESS doc: | - In this half-edge data structure vertex identifiers start at 1. - Vertices are identified with consecutive integers up to number_of_vertices. - This field can be used to document which constant integer has to be - added to another set of vertex_identifier to assure that these other - identifiers also start at 1. - face_identifier_offset(NX_INT): + Integer offset whereby the identifier of the first member + of the vertices differs from zero. + + Identifier can be defined explicitly or implicitly. + Inspect the definition of :ref:`NXcg_primitive_set` for further details. unit: NX_UNITLESS + edge_identifier_offset(NX_INT): doc: | - In this half-edge data structure face identifiers start at 1. - Faces are identified with consecutive integers up to number_of_faces. - This field can be used to document which constant integer has to be - added to another set of face_identifier to assure that these other - identifiers also start at 1. + Integer offset whereby the identifier of the first member + of the edges differs from zero. - The face identifier zero is reserved for the NULL face ! - half_edge_identifier_offset(NX_INT): + Identifier can be defined explicitly or implicitly. + Inspect the definition of :ref:`NXcg_primitive_set` for further details. unit: NX_UNITLESS + face_identifier_offset(NX_INT): doc: | - In this half-edge data structure half-edge identifiers start at 1. - Half-edges are identified with consecutive integers up to number_of_half_edges. - This field can be used to document which constant integer has to be - added to another set of half_edge_identifier to assure that these other - identifiers also start at 1. - + Integer offset whereby the identifier of the first member + of the faces differs from zero. + + Identifier can be defined explicitly or implicitly. + Inspect the definition of :ref:`NXcg_primitive_set` for further details. # therefore, vertex_-, face_-, half_edge_-identifier are implicit position(NX_NUMBER): - unit: NX_LENGTH doc: | The position of the vertices. - dimensions: - rank: 2 - dim: [[1, n_v], [2, d]] - vertex_incident_half_edge(NX_UINT): - unit: NX_UNITLESS + unit: NX_ANY + dim: (n_v, d) + vertex_incident_half_edge(NX_INT): doc: | Identifier of the incident half-edge. - dimensions: - rank: 1 - dim: [[1, n_v]] - face_half_edge(NX_UINT): unit: NX_UNITLESS + dim: (n_v,) + face_half_edge(NX_INT): doc: | Identifier of the (starting)/associated half-edge of the face. - dimensions: - rank: 1 - dim: [[1, n_f]] - half_edge_vertex_origin(NX_UINT): unit: NX_UNITLESS + dim: (n_f,) + half_edge_vertex_origin(NX_INT): doc: | The identifier of the vertex from which this half-edge is outwards pointing. - dimensions: - rank: 1 - dim: [[1, n_he]] - half_edge_twin(NX_UINT): unit: NX_UNITLESS + dim: (n_he,) + half_edge_twin(NX_INT): doc: | Identifier of the associated oppositely pointing half-edge. - dimensions: - rank: 1 - dim: [[1, n_he]] - half_edge_incident_face(NX_UINT): unit: NX_UNITLESS + dim: (n_he,) + half_edge_incident_face(NX_INT): doc: | If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - dimensions: - rank: 1 - dim: [[1, n_he]] - half_edge_next(NX_UINT): unit: NX_UNITLESS + dim: (n_he,) + half_edge_next(NX_INT): doc: | Identifier of the next half-edge. - dimensions: - rank: 1 - dim: [[1, n_he]] - half_edge_prev(NX_UINT): unit: NX_UNITLESS + dim: (n_he,) + half_edge_prev(NX_INT): doc: | Identifier of the previous half-edge. - dimensions: - rank: 1 - dim: [[1, n_he]] + unit: NX_UNITLESS + dim: (n_he,) weinberg_vector: doc: | Users are referred to the literature for the background of L. Weinberg's @@ -128,180 +128,3 @@ NXcg_half_edge_data_structure(NXobject): # which could be more efficient # see https://jerryyin.info/geometry-processing-algorithms/half-edge/ # for an illustrative example of half-edge data structures - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a1e16e466863d2d22ed742e07e4a687882114b34f9aa0fae785f4d4f24577f62 -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality, which has to be at least 2. -# -# -# -# -# The number of vertices. -# -# -# -# -# The number of faces. -# -# -# -# -# The number of half-edges. -# -# -# -# -# Computational geeometry description of a half-edge data structure. -# -# Such a data structure can be used to efficiently circulate around faces -# and iterate over vertices of a planar graph. -# -# -# -# -# -# -# -# In this half-edge data structure vertex identifiers start at 1. -# Vertices are identified with consecutive integers up to number_of_vertices. -# This field can be used to document which constant integer has to be -# added to another set of vertex_identifier to assure that these other -# identifiers also start at 1. -# -# -# -# -# In this half-edge data structure face identifiers start at 1. -# Faces are identified with consecutive integers up to number_of_faces. -# This field can be used to document which constant integer has to be -# added to another set of face_identifier to assure that these other -# identifiers also start at 1. -# -# The face identifier zero is reserved for the NULL face ! -# -# -# -# -# In this half-edge data structure half-edge identifiers start at 1. -# Half-edges are identified with consecutive integers up to number_of_half_edges. -# This field can be used to document which constant integer has to be -# added to another set of half_edge_identifier to assure that these other -# identifiers also start at 1. -# -# -# -# -# -# The position of the vertices. -# -# -# -# -# -# -# -# -# Identifier of the incident half-edge. -# -# -# -# -# -# -# -# Identifier of the (starting)/associated half-edge of the face. -# -# -# -# -# -# -# -# The identifier of the vertex from which this half-edge is outwards pointing. -# -# -# -# -# -# -# -# Identifier of the associated oppositely pointing half-edge. -# -# -# -# -# -# -# -# If the half-edge is a boundary half-edge the -# incident face identifier is NULL, i.e. 0. -# -# -# -# -# -# -# -# Identifier of the next half-edge. -# -# -# -# -# -# -# -# Identifier of the previous half-edge. -# -# -# -# -# -# -# -# Users are referred to the literature for the background of L. Weinberg's -# work about topological characterization of planar graphs: -# -# * `L. Weinberg 1966a, <https://dx.doi.org/10.1109/TCT.1964.1082216>`_ -# * `L. Weinberg, 1966b, <https://dx.doi.org/10.1137/0114062>`_ -# * `E. A. Lazar et al. <https://doi.org/10.1103/PhysRevLett.109.095505>`_ -# -# and how this work can e.g. be applied in space-filling tessellations -# of microstructural objects like crystals/grains. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_hexahedron_set.yaml b/contributed_definitions/nyaml/NXcg_hexahedron_set.yaml index fa57d0ab4a..574895a93b 100644 --- a/contributed_definitions/nyaml/NXcg_hexahedron_set.yaml +++ b/contributed_definitions/nyaml/NXcg_hexahedron_set.yaml @@ -2,434 +2,127 @@ category: base doc: | Computational geometry description of a set of hexahedra in Euclidean space. - The hexahedra do not have to be connected, can have different size, - can intersect, and be rotated. This class can also be used to describe cuboids or cubes, axis-aligned or not. The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: + applied scientists and computational geometry experts an approach whereby + different specific views can be implemented using the same base class: - * Most simple many experimentalists wish to communicate dimensions/the size - of specimens. In this case the alignment with axes is not relevant as - eventually the only relevant information to convey is the volume of the - specimen. - * In many cases, take for instance an experiment where a specimen was taken - from a specifically deformed piece of material, e.g. cold-rolled, - channel-die deformed, the orientation of the specimen edges with the - experiment coordinate system can be of very high relevance. - Examples include to know which specimen edge is parallel to the rolling, - the transverse, or the normal direction. - * Sufficient to pinpoint the sample and laboratory/experiment coordinate - system, the above-mentioned descriptions are not detailed enough though - to create a CAD model of the specimen. + * In the simplest case experimentalists may use this base class to describe + the dimensions or size of a specimen. In this case the alignment with axes + is not relevant as eventually only the volume of the specimen is of interest. + * In many cases, take for example an experiment where a specimen was cut out + from a specifically deformed piece of material, the orientation of the + specimen's edges with the experiment coordinate system is of high relevance. + Examples include knowledge about the specimen edge, whether it is + parallel to the rolling, the transverse, or the normal direction. + * While the above-mentioned use cases are sufficient to pinpoint the sample + within a known laboratory/experiment coordinate system, these descriptions + are not detailed enough to specify e.g. a CAD model of the specimen. * Therefore, groups and fields for an additional, computational-geometry- - based view of the hexahedra is offered which serve different computational + based view of hexahedra is offered to serve additional computational tasks: storage-oriented simple views or detailed topological/graph-based descriptions. Hexahedra are important geometrical primitives, which are among the most frequently used elements in finite element meshing/modeling. - Hexahedra have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. + As a specialization of the :ref:`NXcg_primitive_set` base class hexahedra + are assumed non-degenerated, closed, and built of polygons that are + not self-intersecting. The term hexahedra will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding - box (OBB). + the special cases cuboid, cube, box, axis-aligned bounding box (AABB), + and optimal bounding box (OBB). - An axis-aligned bounding box is a common data object in - computational science and codes to represent a cuboid whose edges - are aligned with a coordinate system. As a part of binary trees these - are important data objects for time as well as space efficient queries + An axis-aligned bounding box is a common data object in computational science + and simulation codes to represent a cuboid whose edges are aligned with the + base vectors of a coordinate system. As a part of binary trees, these data + objects are important for making time- as well as space-efficient queries of geometric primitives in techniques like kd-trees. An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are + tightly fitting box about an arbitrary object. In general, such boxes are rotated. Exact and substantially faster in practice approximate algorithms - exist for computing optimal or near optimal bounding boxes for point sets. + exist to compute optimal or near optimal bounding boxes for sets of points. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. c: | The cardinality of the set, i.e. the number of hexahedra. - # it is useful to define own base classes for frequently used classes # a polyhedron is a specific polytope in 3d, do we need # higher-dimensional polytopes? that could be useful for simplicies though # as they are used in numerics etc. maybe reach out here to our friends # from MarDI, for now let's assume we do not need polytopes for d > 3 type: group -NXcg_hexahedron_set(NXobject): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - enumeration: [3] - cardinality(NX_POSINT): - unit: NX_UNITLESS - +NXcg_hexahedron_set(NXcg_primitive_set): # qualifiers and properties of hexahedra shape(NX_NUMBER): unit: NX_LENGTH doc: | - A qualitative description of each hexahedron/cuboid/cube/box. - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] + Qualifier for the shape of each hexahedron. + dim: (c, 3) length(NX_NUMBER): unit: NX_LENGTH doc: | - Qualifier how one edge is longer than all other edges of the hexahedra. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - dimensions: - rank: 1 - dim: [[1, c]] + Qualifier that is useful in cases when one edge is longer than all other + edges of the hexahedra. Often the term length is associated with the + assumption that one edge is parallel to an axis of the coordinate system. + dim: (c,) width(NX_NUMBER): unit: NX_LENGTH doc: | - Qualifier often used to describe the length of an edge within - a specific coordinate system. - dimensions: - rank: 1 - dim: [[1, c]] + Qualifier often used to describe the extent of an object in the horizontal + direction assuming a specific coordinate system. + + For the sake of explicitness quantities like length, width, and height + should not be reported without specifying also the assumed reference frame. + dim: (c,) height(NX_NUMBER): - unit: NX_LENGTH doc: | - Qualifier often used to describe the length of an edge within - a specific coordinate system. - dimensions: - rank: 1 - dim: [[1, c]] - center(NX_NUMBER): + Qualifier often used to describe the extent of an object in the vertical + direction assuming a specific coordinate system. unit: NX_LENGTH - doc: | - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the hexahedrally-shaped sample/sample part. - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] + dim: (c,) volume(NX_NUMBER): + doc: | + Volume of each hexahedron. unit: NX_VOLUME - dimensions: - rank: 1 - dim: [[1, c]] - surface_area(NX_NUMBER): - unit: NX_AREA + dim: (c,) + area(NX_NUMBER): doc: | - Total area (of all six faces) of each hexahedron. - dimensions: - rank: 1 - dim: [[1, c]] - face_area(NX_NUMBER): + Total (surface) area (of all six faces) of each hexahedron. unit: NX_AREA + dim: (c,) + face_area(NX_NUMBER): doc: | Area of each of the six faces of each hexahedron. - dimensions: - rank: 2 - dim: [[1, c], [2, 6]] + unit: NX_AREA + dim: (c, 6) is_box(NX_BOOLEAN): doc: | Specifies if the hexahedra represent cuboids or cubes eventually rotated ones but at least not too exotic six-faced polyhedra. - dimensions: - rank: 1 - dim: [[1, c]] + dim: (c,) is_axis_aligned(NX_BOOLEAN): doc: | Only to be used if is_box is present. In this case, this field describes whether hexahedra are boxes whose primary edges are parallel to the - axes of the Cartesian coordinate system. - dimensions: - rank: 1 - dim: [[1, c]] - (NXtransformations): - doc: | - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Integer used to distinguish hexahedra for explicit indexing. - dimensions: - rank: 1 - dim: [[1, c]] - + axes of the coordinate system. + dim: (c,) # substantially more detailed descriptors of the shape, the mesh - orientation(NXorientation_set): + # orientation(NXorientation_set): vertex_normal(NXcg_unit_normal_set): edge_normal(NXcg_unit_normal_set): face_normal(NXcg_unit_normal_set): # detailed mesh-based representation hexahedra(NXcg_face_list_data_structure): - - # exists: [min, 0, max, 1] doc: | - A simple approach to describe the entire set of hexahedra when the - main intention is to store the shape of the hexahedra for visualization. - hexahedron(NXcg_face_list_data_structure): - - # exists: [min, 0, max, infty] # can this be max, c? + Combined storage of all primitives of all hexahedra. + hexahedronID(NXcg_face_list_data_structure): doc: | - Disentangled representations of the mesh of specific hexahedra. - hexahedron_half_edge(NXcg_half_edge_data_structure): - - # exists: [min, 0, max, infty] + Individual storage of each hexahedron. + hexahedron_half_edgeID(NXcg_half_edge_data_structure): doc: | - Disentangled representation of the planar graph that each hexahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e7f1ec6a5d54109c7bc0ba78a22fb2728a91bdd88f3cc2aa9bb8b70d37249c35 -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The cardinality of the set, i.e. the number of hexahedra. -# -# -# -# -# Computational geometry description of a set of hexahedra in Euclidean space. -# -# The hexahedra do not have to be connected, can have different size, -# can intersect, and be rotated. -# This class can also be used to describe cuboids or cubes, axis-aligned or not. -# The class represents different access and description levels to offer both -# applied scientists and computational geometry experts to use the same -# base class but rather their specific view on the data: -# -# * Most simple many experimentalists wish to communicate dimensions/the size -# of specimens. In this case the alignment with axes is not relevant as -# eventually the only relevant information to convey is the volume of the -# specimen. -# * In many cases, take for instance an experiment where a specimen was taken -# from a specifically deformed piece of material, e.g. cold-rolled, -# channel-die deformed, the orientation of the specimen edges with the -# experiment coordinate system can be of very high relevance. -# Examples include to know which specimen edge is parallel to the rolling, -# the transverse, or the normal direction. -# * Sufficient to pinpoint the sample and laboratory/experiment coordinate -# system, the above-mentioned descriptions are not detailed enough though -# to create a CAD model of the specimen. -# * Therefore, groups and fields for an additional, computational-geometry- -# based view of the hexahedra is offered which serve different computational -# tasks: storage-oriented simple views or detailed topological/graph-based -# descriptions. -# -# Hexahedra are important geometrical primitives, which are among the most -# frequently used elements in finite element meshing/modeling. -# -# Hexahedra have to be non-degenerated, closed, and built of polygons -# which are not self-intersecting. -# -# The term hexahedra will be used throughout this base class but includes -# the especially in engineering and more commonly used special cases, -# cuboid, cube, box, axis-aligned bounding box (AABB), optimal bounding -# box (OBB). -# -# An axis-aligned bounding box is a common data object in -# computational science and codes to represent a cuboid whose edges -# are aligned with a coordinate system. As a part of binary trees these -# are important data objects for time as well as space efficient queries -# of geometric primitives in techniques like kd-trees. -# -# An optimal bounding box is a common data object which provides the best -# tight fitting box about an arbitrary object. In general such boxes are -# rotated. Exact and substantially faster in practice approximate algorithms -# exist for computing optimal or near optimal bounding boxes for point sets. -# -# -# -# -# -# -# -# -# -# -# A qualitative description of each hexahedron/cuboid/cube/box. -# -# -# -# -# -# -# -# -# Qualifier how one edge is longer than all other edges of the hexahedra. -# Often the term length is associated with one edge being parallel to -# an axis of the coordinate system. -# -# -# -# -# -# -# -# Qualifier often used to describe the length of an edge within -# a specific coordinate system. -# -# -# -# -# -# -# -# Qualifier often used to describe the length of an edge within -# a specific coordinate system. -# -# -# -# -# -# -# -# Position of the geometric center, which often is but not necessarily -# has to be the center_of_mass of the hexahedrally-shaped sample/sample part. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Total area (of all six faces) of each hexahedron. -# -# -# -# -# -# -# -# Area of each of the six faces of each hexahedron. -# -# -# -# -# -# -# -# -# Specifies if the hexahedra represent cuboids or cubes eventually rotated -# ones but at least not too exotic six-faced polyhedra. -# -# -# -# -# -# -# -# Only to be used if is_box is present. In this case, this field describes -# whether hexahedra are boxes whose primary edges are parallel to the -# axes of the Cartesian coordinate system. -# -# -# -# -# -# -# -# Reference to or definition of a coordinate system with -# which the qualifiers and mesh data are interpretable. -# -# -# -# -# Integer which specifies the first index to be used for distinguishing -# hexahedra. Identifiers are defined either implicitly -# or explicitly. For implicit indexing the identifiers are defined on the -# interval [identifier_offset, identifier_offset+c-1]. -# For explicit indexing the identifier array has to be defined. -# -# The identifier_offset field can for example be used to communicate if the -# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) -# or from 0 (referred to as C-, Python-style index notation) respectively. -# -# -# -# -# Integer used to distinguish hexahedra for explicit indexing. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# A simple approach to describe the entire set of hexahedra when the -# main intention is to store the shape of the hexahedra for visualization. -# -# -# -# -# -# Disentangled representations of the mesh of specific hexahedra. -# -# -# -# -# -# Disentangled representation of the planar graph that each hexahedron -# represents. Such a description simplifies topological processing -# or analyses of mesh primitive operations and neighborhood queries. -# -# -# + Individual storage of each hexahedron as a graph. diff --git a/contributed_definitions/nyaml/NXcg_marching_cubes.yaml b/contributed_definitions/nyaml/NXcg_marching_cubes.yaml index 52190a7907..d731f8103b 100644 --- a/contributed_definitions/nyaml/NXcg_marching_cubes.yaml +++ b/contributed_definitions/nyaml/NXcg_marching_cubes.yaml @@ -2,8 +2,8 @@ category: base doc: | Computational geometry description of the marching cubes algorithm. - Documenting which specific version was used can help to understand how robust - the results are with respect to the topology of the triangulation. + Documenting which specific version was used helps with understanding how + robust the results are with respect to the topology of the triangulation. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -13,7 +13,7 @@ NXcg_marching_cubes(NXobject): doc: | Reference/link to and/or details of the grid on which a specific marching cubes algorithm implementation is operating. - implementation: + implementation(NX_CHAR): doc: | Reference to the specific implementation of marching cubes used. @@ -26,94 +26,8 @@ NXcg_marching_cubes(NXobject): The value placed here should be a DOI. If there are no specific DOI or details write not_further_specified, or give at least a free-text description. - program: - doc: | - Commercial or otherwise given name to the program which was used. - \@version: - doc: | - Program version plus build number, commit hash, or description of - an ever persistent resource where the source code of the program - and build instructions can be found so that the program can be - configured in such a manner that the result file is ideally - recreatable yielding the same results. - + (NXprogram): + # we could also think about storing the rule sets in here explicitly including the # coordinate system conventions; however, the problem is that many commercial # tools like Matlab do not expose the rule set. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 3b2f3175033e3606a1be9aa4a65ca8956002ee92cea2600c3c725eb1c3c754eb -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Computational geometry description of the marching cubes algorithm. -# -# Documenting which specific version was used can help to understand how robust -# the results are with respect to the topology of the triangulation. -# -# -# -# Reference/link to and/or details of the grid on which a specific -# marching cubes algorithm implementation is operating. -# -# -# -# -# Reference to the specific implementation of marching cubes used. -# -# See for example the following papers for details about how to identify a -# DOI which specifies the implementation used: -# -# * `W. E. Lorensen <https://doi.org/10.1109/MCG.2020.2971284>`_ -# * `T. S. Newman and H. Yi <https://doi.org/10.1016/j.cag.2006.07.021>`_ -# -# The value placed here should be a DOI. If there are no specific DOI or -# details write not_further_specified, or give at least a free-text -# description. -# -# -# -# -# Commercial or otherwise given name to the program which was used. -# -# -# -# Program version plus build number, commit hash, or description of -# an ever persistent resource where the source code of the program -# and build instructions can be found so that the program can be -# configured in such a manner that the result file is ideally -# recreatable yielding the same results. -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_parallelogram_set.yaml b/contributed_definitions/nyaml/NXcg_parallelogram_set.yaml index 0b3fca5afa..05dc7778f1 100644 --- a/contributed_definitions/nyaml/NXcg_parallelogram_set.yaml +++ b/contributed_definitions/nyaml/NXcg_parallelogram_set.yaml @@ -1,330 +1,65 @@ category: base doc: | - Computational geometry description of a set of parallelograms in Euclidean space. + Computational geometry description of a set of parallelograms. - The parallelograms do not have to be connected, can have different size, - can intersect, and be rotated. - This class can also be used to describe rectangles or squares, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts to use the same - base class but rather their specific view on the data: + This class can also be used to describe rectangles or squares, irrespective + whether these are axis-aligned or not. The class represents different + access and description levels to embrace applied scientists and computational + geometry experts with their different views: - * Most simple many experimentalists wish to communicate dimensions/the size - of e.g. a region of interest in the 2D plane. In this case the alignment - with axes is not relevant as eventually relevant is only the area of the ROI. + * The simplest case is the communication of dimensions aka the size of a + region of interest in the 2D plane. In this case, communicating the + alignment with axes is maybe not as relevant as it is to report the area + of the ROI. * In other cases the extent of the parallelogram is relevant though. - * Finally in CAD models we would like to specify the polygon - which is parallelogram represents. + * Finally, in CAD models it should be possible to specify the polygons + which the parallelograms represent with exact numerical details. - Parallelograms are important geometrical primitives. Not so much because of their - uses in nowadays, thanks to improvements in computing power, not so frequently - any longer performed 2D simulation. Many scanning experiments probe though - parallelogram-shaped ROIs on the surface of samples. + Parallelograms are important geometrical primitives as their usage for + describing many scanning experiments shows where typically parallelogram-shaped + ROIs are scanned across the surface of a sample. - Parallelograms have to be non-degenerated, closed, and built of polygons - which are not self-intersecting. - - The term parallelogram will be used throughout this base class but includes - the especially in engineering and more commonly used special cases, - rectangle, square, 2D box, axis-aligned bounding box (AABB), or - optimal bounding box (OBB) but here the analogous 2D cases. + The term parallelogram will be used throughout this base class thus including + the important special cases rectangle, square, 2D box, axis-aligned bounding box + (AABB), or optimal bounding box (OBB) as analogous 2D variants to their 3D + counterparts. See :ref:`NXcg_hexahedron_set` for the generalization in 3D. An axis-aligned bounding box is a common data object in computational science - and codes to represent a rectangle whose edges are aligned with the axes - of a coordinate system. As a part of binary trees these are important data - objects for time- as well as space-efficient queries + and simulation codes to represent a rectangle whose edges are aligned with the + axes of a coordinate system. As a part of binary trees AABBs are important data + objects for executing time- as well as space-efficient queries of geometric primitives in techniques like kd-trees. - An optimal bounding box is a common data object which provides the best - tight fitting box about an arbitrary object. In general such boxes are - rotated. Other than in 3D dimensions the rotation calipher method offers - a rigorous approach to compute optimal bounding boxes in 2D. + An optimal bounding box is a common data object which provides the best, i.e. + most tightly fitting box about an arbitrary object. In general such boxes are + rotated. Other than in 3D dimensions, the rotation calipher method offers + a rigorous approach to compute an optimal bounding box to a point set in 2D. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. c: | The cardinality of the set, i.e. the number of parallelograms. type: group -NXcg_parallelogram_set(NXobject): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - enumeration: [2] - cardinality(NX_POSINT): - unit: NX_UNITLESS - +NXcg_parallelogram_set(NXcg_primitive_set): # qualifiers and properties of parallelograms - shape(NX_NUMBER): - unit: NX_LENGTH - doc: | - A qualitative description of each parallelogram/rectangle/square/box. - dimensions: - rank: 2 - dim: [[1, c], [2, 2]] - length(NX_NUMBER): - unit: NX_LENGTH + is_rectangle(NX_BOOLEAN): doc: | - Qualifier how one edge is longer than all the other edge of the parallelogam. - Often the term length is associated with one edge being parallel to - an axis of the coordinate system. - dimensions: - rank: 1 - dim: [[1, c]] - width(NX_NUMBER): - unit: NX_LENGTH - doc: | - Qualifier often used to describe the length of an edge within - a specific coordinate system. - dimensions: - rank: 1 - dim: [[1, c]] - center(NX_NUMBER): - unit: NX_LENGTH - doc: | - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the parallelogram. - dimensions: - rank: 2 - dim: [[1, c], [2, 2]] - surface_area(NX_NUMBER): - unit: NX_AREA - dimensions: - rank: 1 - dim: [[1, c]] + To specify which parallelogram is a rectangle. + dim: (c,) is_axis_aligned(NX_BOOLEAN): doc: | - Only to be used if is_box is present. In this case, this field describes - whether parallelograms are rectangles/squares whose primary edges - are parallel to the axes of the Cartesian coordinate system. - dimensions: - rank: 1 - dim: [[1, c]] - (NXtransformations): - doc: | - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer which specifies the first index to be used for distinguishing - parallelograms. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Integer used to distinguish parallelograms for explicit indexing. - dimensions: - rank: 1 - dim: [[1, c]] - - # substantially more detailed descriptors of the shape, the mesh - orientation(NXorientation_set): - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - + Only to be used if is_rectangle is present. In this case, this field + describes whether parallelograms are rectangles whose primary edges + are parallel to the axes of the coordinate system. + dim: (c,) # detailed mesh-based representation parallelograms(NXcg_face_list_data_structure): - # exists: [min, 0, max, 1] doc: | - A simple approach to describe the entire set of parallelograms when the - main intention is to store the shape of the parallelograms for visualization. - parallelogram(NXcg_face_list_data_structure): - - # exists: [min, 0, max, infty] # can this be max, c? + Combined storage of all primitives of all parallelograms. + parallelogramID(NXcg_face_list_data_structure): doc: | - Disentangled representations of the mesh of specific parallelograms. - - ##MK::a half-edge structure would be overkill as this is a simple primitive + Individual storage of each parallelogram. + ##MK::parallelogram_half_edgeID(NXcg_half_edge_data_structure) + # a half-edge structure would be overkill as this is a simple primitive -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 5d1302fcf7b789f052eacff219eeab4f7d7be114f56b4a59ce5a604a8e867099 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The cardinality of the set, i.e. the number of parallelograms. -# -# -# -# -# Computational geometry description of a set of parallelograms in Euclidean space. -# -# The parallelograms do not have to be connected, can have different size, -# can intersect, and be rotated. -# This class can also be used to describe rectangles or squares, axis-aligned or not. -# The class represents different access and description levels to offer both -# applied scientists and computational geometry experts to use the same -# base class but rather their specific view on the data: -# -# * Most simple many experimentalists wish to communicate dimensions/the size -# of e.g. a region of interest in the 2D plane. In this case the alignment -# with axes is not relevant as eventually relevant is only the area of the ROI. -# * In other cases the extent of the parallelogram is relevant though. -# * Finally in CAD models we would like to specify the polygon -# which is parallelogram represents. -# -# Parallelograms are important geometrical primitives. Not so much because of their -# uses in nowadays, thanks to improvements in computing power, not so frequently -# any longer performed 2D simulation. Many scanning experiments probe though -# parallelogram-shaped ROIs on the surface of samples. -# -# Parallelograms have to be non-degenerated, closed, and built of polygons -# which are not self-intersecting. -# -# The term parallelogram will be used throughout this base class but includes -# the especially in engineering and more commonly used special cases, -# rectangle, square, 2D box, axis-aligned bounding box (AABB), or -# optimal bounding box (OBB) but here the analogous 2D cases. -# -# An axis-aligned bounding box is a common data object in computational science -# and codes to represent a rectangle whose edges are aligned with the axes -# of a coordinate system. As a part of binary trees these are important data -# objects for time- as well as space-efficient queries -# of geometric primitives in techniques like kd-trees. -# -# An optimal bounding box is a common data object which provides the best -# tight fitting box about an arbitrary object. In general such boxes are -# rotated. Other than in 3D dimensions the rotation calipher method offers -# a rigorous approach to compute optimal bounding boxes in 2D. -# -# -# -# -# -# -# -# -# -# -# A qualitative description of each parallelogram/rectangle/square/box. -# -# -# -# -# -# -# -# -# Qualifier how one edge is longer than all the other edge of the parallelogam. -# Often the term length is associated with one edge being parallel to -# an axis of the coordinate system. -# -# -# -# -# -# -# -# Qualifier often used to describe the length of an edge within -# a specific coordinate system. -# -# -# -# -# -# -# -# Position of the geometric center, which often is but not necessarily -# has to be the center_of_mass of the parallelogram. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Only to be used if is_box is present. In this case, this field describes -# whether parallelograms are rectangles/squares whose primary edges -# are parallel to the axes of the Cartesian coordinate system. -# -# -# -# -# -# -# -# Reference to or definition of a coordinate system with -# which the qualifiers and mesh data are interpretable. -# -# -# -# -# Integer which specifies the first index to be used for distinguishing -# parallelograms. Identifiers are defined either implicitly -# or explicitly. For implicit indexing the identifiers are defined on the -# interval [identifier_offset, identifier_offset+c-1]. -# For explicit indexing the identifier array has to be defined. -# -# The identifier_offset field can for example be used to communicate if the -# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) -# or from 0 (referred to as C-, Python-style index notation) respectively. -# -# -# -# -# Integer used to distinguish parallelograms for explicit indexing. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# A simple approach to describe the entire set of parallelograms when the -# main intention is to store the shape of the parallelograms for visualization. -# -# -# -# -# -# Disentangled representations of the mesh of specific parallelograms. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_point_set.yaml b/contributed_definitions/nyaml/NXcg_point_set.yaml index d1ab1daab5..673953b0c6 100644 --- a/contributed_definitions/nyaml/NXcg_point_set.yaml +++ b/contributed_definitions/nyaml/NXcg_point_set.yaml @@ -1,163 +1,43 @@ category: base doc: | - Computational geometry description of a set of points in Euclidean space. + Computational geometry description of a set of points. - The relevant coordinate system should be referred to in the NXtransformations - instance. Points may have an associated time value; however users are advised - to store time data of point sets rather as instances of time events, where - for each point in time there is an NXcg_point_set instance which specifies the - points locations. This is a frequent situation in experiments and computer - simulations, where positions of points are taken at the same point in time; - and therefore an additional time array would demand to store redundant pieces - of information for each point. + Points may have an associated time value. Users are advised though to store + time data of point sets rather as instances of time events, where for each + point in time there is an :ref:`NXcg_point_set` instance which specifies the + points' locations. + + This is a frequent situation in experiments and computer simulations, where + positions of points are taken at the same point in time (real time or + simulated physical time). Thereby, the storage of redundant time stamp + information per point is considered as obsolete. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. d: | - The dimensionality, which has to be at least 1. + The dimensionality. c: | The cardinality of the set, i.e. the number of points. type: group -NXcg_point_set(NXobject): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - cardinality(NX_POSINT): - unit: NX_UNITLESS - identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer which specifies the first index to be used for distinguishing - identifiers for points. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Integer used to distinguish points for explicit indexing. - dimensions: - rank: 1 - dim: [[1, c]] +NXcg_point_set(NXcg_primitive_set): position(NX_NUMBER): - unit: NX_LENGTH doc: | - The array of point coordinates. - dimensions: - rank: 2 - dim: [[1, c], [2, d]] + Coordinates of the points. + unit: NX_ANY + dim: (c, d) time(NX_NUMBER): + doc: | + (Elapsed) time for each point. + + If the field time is needed contextualize the time_offset relative to which + time values are defined. Alternative store timestamp. unit: NX_TIME + dim: (c,) + timestamp(NX_DATE_TIME): doc: | - The optional array of time for each vertex. - dimensions: - rank: 1 - dim: [[1, c]] - (NXtransformations): + ISO8601 with local time zone offset for each point. + dim: (c,) + time_offset(NX_DATE_TIME): doc: | - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# ba461c2c50dd1946cfc43481d91672fa5fcb318025c70ac45b767965d960de12 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality, which has to be at least 1. -# -# -# -# -# The cardinality of the set, i.e. the number of points. -# -# -# -# -# Computational geometry description of a set of points in Euclidean space. -# -# The relevant coordinate system should be referred to in the NXtransformations -# instance. Points may have an associated time value; however users are advised -# to store time data of point sets rather as instances of time events, where -# for each point in time there is an NXcg_point_set instance which specifies the -# points locations. This is a frequent situation in experiments and computer -# simulations, where positions of points are taken at the same point in time; -# and therefore an additional time array would demand to store redundant pieces -# of information for each point. -# -# -# -# -# -# Integer which specifies the first index to be used for distinguishing -# identifiers for points. Identifiers are defined either implicitly -# or explicitly. For implicit indexing the identifiers are defined on the -# interval [identifier_offset, identifier_offset+c-1]. -# For explicit indexing the identifier array has to be defined. -# -# The identifier_offset field can for example be used to communicate if the -# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) -# or from 0 (referred to as C-, Python-style index notation) respectively. -# -# -# -# -# Integer used to distinguish points for explicit indexing. -# -# -# -# -# -# -# -# The array of point coordinates. -# -# -# -# -# -# -# -# -# The optional array of time for each vertex. -# -# -# -# -# -# -# -# Reference to or definition of a coordinate system with -# which the positions and directions are interpretable. -# -# -# + ISO8601 with local time zone offset that serves as the reference + for values in the field time. diff --git a/contributed_definitions/nyaml/NXcg_polygon_set.yaml b/contributed_definitions/nyaml/NXcg_polygon_set.yaml index 9ab3ec4446..6f712610ff 100644 --- a/contributed_definitions/nyaml/NXcg_polygon_set.yaml +++ b/contributed_definitions/nyaml/NXcg_polygon_set.yaml @@ -1,10 +1,9 @@ category: base - # somewhat redundant as there is NXoff_geometry but easier to understand doc: | Computational geometry description of a set of polygons in Euclidean space. - Polygons are related are specialized polylines: + Polygons are specialized polylines: * A polygon is a geometric primitive that is bounded by a closed polyline * All vertices of this polyline lay in the d-1 dimensional plane. @@ -17,13 +16,14 @@ doc: | As three-dimensional objects, a set of polygons can be used to define the hull of what is effectively a polyhedron; however users are advised to use - the specific NXcg_polyhedron_set base class if they wish to describe closed - polyhedra. Even more general complexes can be thought, for instance - piecewise-linear complexes, as these can have holes though, polyhedra without - holes are one subclass of such complexes, users should rather design an own + the specific :ref:`NXcg_polyhedron_set` base class if they wish to describe closed + polyhedra. Even more general complexes can be thought of. An example are the + so-called piecewise-linear complexes used in the TetGen library. + + As these complexes can have holes though, polyhedra without holes are one + subclass of such complexes, users should rather design an own base class e.g. NXcg_polytope_set to describe such even more - complex primitives. - + complex primitives instead of abusing this base class for such purposes. # Users can take advantage of NXcg_polygon_set to describe such complexes # when using the defines_plc and related topological and boundary constraint # descriptors. @@ -34,376 +34,46 @@ symbols: The dimensionality, which has to be either 2 or 3. c: | The cardinality of the set, i.e. the number of polygons. - # n_unique: Number of unique points supporting the polygons. n_total: | The total number of vertices when visiting every polygon. type: group -NXcg_polygon_set(NXobject): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - enumeration: [2, 3] - cardinality(NX_POSINT): - unit: NX_UNITLESS - number_of_total_vertices(NX_POSINT): - unit: NX_UNITLESS - identifier_offset(NX_INT): - unit: NX_UNITLESS +NXcg_polygon_set(NXcg_primitive_set): + number_of_total_vertices(NX_INT): doc: | - Integer which specifies the first index to be used for distinguishing - polygons. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - identifier(NX_INT): + The total number of vertices in the set. unit: NX_UNITLESS - doc: | - Integer used to distinguish polygons for explicit indexing. - dimensions: - rank: 1 - dim: [[1, c]] + # detailed mesh-based representation polygons(NXcg_face_list_data_structure): - - # exists: [min, 0, max, 1] doc: | - A simple approach to describe the entire set of polygons when the - main intention is to store the shape of the polygons for visualization. - - # detailed additional information eventually mesh-related data - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - - # triangles_half_edge(NXcg_half_edge_data_structure): + Combined storage of all primitives of all polygons. + polygonID(NXcg_face_list_data_structure): + doc: | + Individual storage of the mesh of each polygon. + polygon_half_edgeID(NXcg_half_edge_data_structure): + doc: | + Individual storage of each polygon as a graph. # properties of the polygon primitives - area(NX_NUMBER): - unit: NX_AREA - dimensions: - rank: 1 - dim: [[1, c]] edge_length(NX_NUMBER): - unit: NX_LENGTH doc: | - The accumulated length of the polygon edge. - dimensions: - rank: 1 - dim: [[1, c]] + For each polygon its accumulated length along its edges. + unit: NX_LENGTH + dim: (c,) interior_angle(NX_NUMBER): - unit: NX_ANGLE doc: | - Array of interior angles. There are many values per polygon as number_of_vertices. + Interior angles for each polygon. There are as many values per polygon + as the are number_of_vertices. The angle is the angle at the specific vertex, i.e. between the adjoining edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - dimensions: - rank: 1 - dim: [[1, n_total]] + unit: NX_ANGLE + dim: (n_total,) shape(NX_INT): - unit: NX_UNITLESS doc: | Curvature type: * 0 - unspecified, * 1 - convex, * 2 - concave - dimensions: - rank: 1 - dim: [[1, c]] - center(NX_NUMBER): - unit: NX_LENGTH - doc: | - The center of mass of each polygon. - dimensions: - rank: 2 - dim: [[1, c], [2, d]] - bounding_box(NXcg_hexahedron_set): - doc: | - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - - ##MK::ROI about the set ? - # a set of polygons can be interpreted as a descriptor for an object - # an, in TetGen terminology, piecewise-linear complex - # defines_plc(NX_BOOLEAN): - # doc: True, if the set describes a piecewise-linear complex. - ##MK::each polygon could be given a role with respect to what the polygon - ##MK::represents of the complex, this would allow to define a complex with - ##MK::holes - # vertices(NXcg_point_set): - # doc: | - # The set of vertices supporting the polygons. - # The dimensionality of the point set and this polygon set are the same. - # The number of vertices is arbitrary because polygons may different in - # their number of edges. - # Like it is the case for NXcg_triangle_set instances, individual - # polygons may make edge contact in which case a lower number of vertices - # suffices than naively expected from a summation of the edges. - # Users are encouraged to reduce the vertex set to a set of unique vertices - # as this can often turn out to allow for a more efficient storage - # of the geometry data. It is also possible though to store - # the vertices naively in which case vertices_are_unique is likely False. - # vertices_are_unique(NX_BOOLEAN): - # doc: | - # If true indicates that the vertices are all placed at different positions - # and have different identifiers, i.e. no points overlap or are counted twice. - # number_of_vertices(NX_POSINT): - # doc: | - # Array which specifies of how many vertices each polygon is built. - # The number of vertices represent the total number of vertices for - # each polygon, irrespectively whether vertices are shared or not. - # See the docstring for polygons for further details about how - # a set with different polyline members should be stored. - # unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dimensions: [[1, c]] - # ##MK::there is nothing like value constraints... or minimum bitdepth - # polygons(NX_INT): - # doc: | - # Array of identifiers from vertices which describe each polygon. - # The first entry is the identifier of the start vertex of the first polyline, - # followed by the second vertex of the first polyline, until the last vertex - # of the polyline. Thereafter, the start vertex of the second polyline, and - # so on and so forth. Using the (cumulated) counts in number_of_vertices, - # the vertices of the n-th polyline can be accessed on the following - # array index interval: - # [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. - # Users are advised to store the vertex identifiers, if possible and - # ideally then for all of them, according to and using winding order. - # If the winding_order field is given, it has to report the specific winding - # order used. - # unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, n_total]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d4221d5954c870bd03fdeca1f3ea6cfacb5ab7ca0647976253c5119e675f4ef7 -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality, which has to be either 2 or 3. -# -# -# -# -# The cardinality of the set, i.e. the number of polygons. -# -# -# -# -# -# The total number of vertices when visiting every polygon. -# -# -# -# -# -# Computational geometry description of a set of polygons in Euclidean space. -# -# Polygons are related are specialized polylines: -# -# * A polygon is a geometric primitive that is bounded by a closed polyline -# * All vertices of this polyline lay in the d-1 dimensional plane. -# whereas vertices of a polyline do not necessarily lay on a plane. -# * A polygon has at least three vertices. -# -# Each polygon is built from a sequence of vertices (points with identifiers). -# The members of a set of polygons may have a different number of vertices. -# Sometimes a collection/set of polygons is referred to as a soup of polygons. -# -# As three-dimensional objects, a set of polygons can be used to define the -# hull of what is effectively a polyhedron; however users are advised to use -# the specific NXcg_polyhedron_set base class if they wish to describe closed -# polyhedra. Even more general complexes can be thought, for instance -# piecewise-linear complexes, as these can have holes though, polyhedra without -# holes are one subclass of such complexes, users should rather design an own -# base class e.g. NXcg_polytope_set to describe such even more -# complex primitives. -# -# -# -# -# -# -# -# -# -# -# -# Integer which specifies the first index to be used for distinguishing -# polygons. Identifiers are defined either implicitly -# or explicitly. For implicit indexing the identifiers are defined on the -# interval [identifier_offset, identifier_offset+c-1]. -# For explicit indexing the identifier array has to be defined. -# -# The identifier_offset field can for example be used to communicate if the -# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) -# or from 0 (referred to as C-, Python-style index notation) respectively. -# -# -# -# -# Integer used to distinguish polygons for explicit indexing. -# -# -# -# -# -# -# -# -# A simple approach to describe the entire set of polygons when the -# main intention is to store the shape of the polygons for visualization. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The accumulated length of the polygon edge. -# -# -# -# -# -# -# -# Array of interior angles. There are many values per polygon as number_of_vertices. -# The angle is the angle at the specific vertex, i.e. between the adjoining -# edges of the vertex according to the sequence in the polygons array. -# Usually, the winding_order field is required to interpret the value. -# -# -# -# -# -# -# -# Curvature type: -# -# * 0 - unspecified, -# * 1 - convex, -# * 2 - concave -# -# -# -# -# -# -# -# The center of mass of each polygon. -# -# -# -# -# -# -# -# -# Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. -# -# -# -# + unit: NX_UNITLESS + dim: (c,) diff --git a/contributed_definitions/nyaml/NXcg_polyhedron_set.yaml b/contributed_definitions/nyaml/NXcg_polyhedron_set.yaml index 893e71fb03..9285618b3b 100644 --- a/contributed_definitions/nyaml/NXcg_polyhedron_set.yaml +++ b/contributed_definitions/nyaml/NXcg_polyhedron_set.yaml @@ -1,16 +1,14 @@ category: base doc: | - Computational geometry description of a polyhedra in Euclidean space. + Computational geometry description of a set of polyhedra in Euclidean space. - Polyhedra, also so-called cells (especially in the convex of tessellations), - here described have to be all non-degenerated, closed, built of and thus - built out of not-self-intersecting polygon meshes. Polyhedra may make contact, - so that this base class can be used for a future description of tessellations. + Polyhedra or so-called cells (especially in the convex of tessellations) are + constructed from polygon meshes. Polyhedra may make contact to allow a usage + of this base class for a description of tessellations. - For more complicated manifolds and especially for polyhedra with holes, users - are advised to check if their particular needs are described by creating - (eventually customized) instances of an NXcg_polygon_set, which can be - extended for the description of piecewise-linear complexes. + For the description of more complicated manifolds and especially for polyhedra + with holes, users are advised to check if their particular needs are described + by creating customized instances of an :ref:`NXcg_polygon_set`. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -20,7 +18,6 @@ symbols: The total number of edges for all polyhedra. n_f_total: | The total number of faces for all polyhedra. - # it is useful to define own base classes for frequently used classes # a polyhedron is a specific polytope in 3d, do we need # higher-dimensional polytopes? that could be useful for simplicies though @@ -31,315 +28,35 @@ symbols: # polyhedra and also half_edge_data_structures that can be useful # for clean graph-based descriptions of polyhedra. type: group -NXcg_polyhedron_set(NXobject): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - enumeration: [3] - cardinality(NX_POSINT): - unit: NX_UNITLESS - +NXcg_polyhedron_set(NXcg_primitive_set): # qualifiers and properties of polyhedra - volume(NX_NUMBER): - unit: NX_VOLUME - doc: | - Interior volume - dimensions: - rank: 1 - dim: [[1, c]] - center(NX_NUMBER): - unit: NX_LENGTH - doc: | - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the polyhedra. - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] - surface_area(NX_NUMBER): - unit: NX_AREA - doc: | - Total surface area as the sum of all faces. - dimensions: - rank: 1 - dim: [[1, c]] - number_of_faces(NX_POSINT): - unit: NX_UNITLESS + number_of_faces(NX_INT): doc: | The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. This field can be used to interpret - the array/field with the individual area values for each face. - dimensions: - rank: 1 - dim: [[1, c]] + are counted for each polyhedron. + unit: NX_UNITLESS + dim: (c,) face_area(NX_NUMBER): - unit: NX_AREA doc: | - Area of each of the four triangular faces of each tetrahedron. - dimensions: - rank: 1 - dim: [[1, n_f_total]] - number_of_edges(NX_POSINT): + Area of each of faces. + unit: NX_AREA + dim: (n_f_total,) + number_of_edges(NX_INT): doc: | The number of edges for each polyhedron. Edges of adjoining polyhedra - are counterd for each polyhedron. This field can be used to interpret - the array/field with the individual length for each edge. + are counterd for each polyhedron. edge_length(NX_NUMBER): - unit: NX_LENGTH - doc: | - Length of each edge of each tetrahedron. - dimensions: - rank: 1 - dim: [[1, n_e_total]] - (NXtransformations): doc: | - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - - # substantially more detailed descriptors of the shape, the mesh - identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer which specifies the first index to be used for distinguishing - polyhedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Integer used to distinguish polyhedra for explicit indexing. - dimensions: - rank: 1 - dim: [[1, c]] - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - + Length of each edge. + unit: NX_LENGTH + dim: (n_e_total,) # detailed mesh-based representation polyhedra(NXcg_face_list_data_structure): - - # exists: [min, 0, max, 1] doc: | - A simple approach to describe the entire set of polyhedra when the - main intention is to store the shape of the polyhedra for visualization. - polyhedron(NXcg_face_list_data_structure): - - # exists: [min, 0, max, infty] # can this be max, c? + Combined storage of all primitives of all polyhedra. + polyhedronID(NXcg_face_list_data_structure): doc: | - Disentangled representations of the mesh of specific polyhedron. - polyhedron_half_edge(NXcg_half_edge_data_structure): - - # exists: [min, 0, max, infty] + Individual storage of each polyhedron. + polyhedron_half_edgeID(NXcg_half_edge_data_structure): doc: | - Disentangled representation of the planar graph that each polyhedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - - # face_type(NX_UINT): #maybe a better name maybe topology, although this is misleading for the above-mentioned reasons - # doc: A concatenated array, for each polygon face the number of vertices. - # unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, nfaces]] - # intersections between members? as a graph - # contact with external primitives like simulation domain etc - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 78849fd106ffb653e79c194e88de9fe74b1e717137b485992c7cde42bf186241 -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The cardinality of the set, i.e. the number of polyhedra. -# -# -# -# -# The total number of edges for all polyhedra. -# -# -# -# -# The total number of faces for all polyhedra. -# -# -# -# -# Computational geometry description of a polyhedra in Euclidean space. -# -# Polyhedra, also so-called cells (especially in the convex of tessellations), -# here described have to be all non-degenerated, closed, built of and thus -# built out of not-self-intersecting polygon meshes. Polyhedra may make contact, -# so that this base class can be used for a future description of tessellations. -# -# For more complicated manifolds and especially for polyhedra with holes, users -# are advised to check if their particular needs are described by creating -# (eventually customized) instances of an NXcg_polygon_set, which can be -# extended for the description of piecewise-linear complexes. -# -# -# -# -# -# -# -# -# -# -# Interior volume -# -# -# -# -# -# -# -# Position of the geometric center, which often is but not necessarily -# has to be the center_of_mass of the polyhedra. -# -# -# -# -# -# -# -# -# Total surface area as the sum of all faces. -# -# -# -# -# -# -# -# The number of faces for each polyhedron. Faces of adjoining polyhedra -# are counted for each polyhedron. This field can be used to interpret -# the array/field with the individual area values for each face. -# -# -# -# -# -# -# -# Area of each of the four triangular faces of each tetrahedron. -# -# -# -# -# -# -# -# The number of edges for each polyhedron. Edges of adjoining polyhedra -# are counterd for each polyhedron. This field can be used to interpret -# the array/field with the individual length for each edge. -# -# -# -# -# Length of each edge of each tetrahedron. -# -# -# -# -# -# -# -# Reference to or definition of a coordinate system with -# which the qualifiers and mesh data are interpretable. -# -# -# -# -# -# Integer which specifies the first index to be used for distinguishing -# polyhedra. Identifiers are defined either implicitly -# or explicitly. For implicit indexing the identifiers are defined on the -# interval [identifier_offset, identifier_offset+c-1]. -# For explicit indexing the identifier array has to be defined. -# -# The identifier_offset field can for example be used to communicate if the -# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) -# or from 0 (referred to as C-, Python-style index notation) respectively. -# -# -# -# -# Integer used to distinguish polyhedra for explicit indexing. -# -# -# -# -# -# -# -# -# -# -# -# -# A simple approach to describe the entire set of polyhedra when the -# main intention is to store the shape of the polyhedra for visualization. -# -# -# -# -# -# Disentangled representations of the mesh of specific polyhedron. -# -# -# -# -# -# Disentangled representation of the planar graph that each polyhedron -# represents. Such a description simplifies topological processing -# or analyses of mesh primitive operations and neighborhood queries. -# -# -# -# + Individual storage of each polygon as a graph. diff --git a/contributed_definitions/nyaml/NXcg_polyline_set.yaml b/contributed_definitions/nyaml/NXcg_polyline_set.yaml index c54258c4cf..bef7167078 100644 --- a/contributed_definitions/nyaml/NXcg_polyline_set.yaml +++ b/contributed_definitions/nyaml/NXcg_polyline_set.yaml @@ -1,11 +1,11 @@ category: base doc: | - Computational geometry description of a set of polylines in Euclidean space. + Computational geometry description of a set of polylines. Each polyline is built from a sequence of vertices (points with identifiers). Each polyline must have a start and an end point. - The sequence describes the positive traversal along the polyline when walking - from the start vertex to the end/last vertex. + The sequence describes the positive traversal along the polyline when + walking from the first to the last vertex. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -13,7 +13,6 @@ symbols: The dimensionality, which has to be at least 1. c: | The cardinality of the set, i.e. the number of polylines. - # n_unique: The number of unique vertices supporting the polyline. # multiple vertices possible with the same point coordinates but different names. n_v: | @@ -21,304 +20,74 @@ symbols: n_total: | The total number of vertices traversed when visiting every polyline. type: group -NXcg_polyline_set(NXobject): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - cardinality(NX_POSINT): - unit: NX_UNITLESS - - # number_of_unique_vertices(NX_POSINT): - # unit: NX_UNITLESS - number_of_total_vertices(NX_POSINT): +NXcg_polyline_set(NXcg_primitive_set): + \@depends_on(NX_CHAR): + doc: | + Reference to an instance of :ref:`NXcg_point_set` which defines + the location of the vertices that are referred to in the + NXcg_polyline_set instance. + number_of_unique_vertices(NX_POSINT): + doc: | + The total number of vertices that have different positions. unit: NX_UNITLESS + number_of_total_vertices(NX_INT): doc: | - The total number of vertices, irrespective of their eventual uniqueness, - i.e. the total number of vertices that have to be visited when walking - along each polyline. - number_of_vertices(NX_POSINT): + The total number of vertices, irrespective of their eventual uniqueness. unit: NX_UNITLESS + number_of_vertices(NX_INT): doc: | - Array which specifies of how many vertices each polyline is built. - The number of vertices represent the total number of vertices for - each polyline, irrespectively whether vertices are shared or not. + The total number of vertices of each polyline, irrespectively + whether vertices are shared by vertices or not. See the docstring for polylines for further details about how a set with different polyline members should be stored. - dimensions: - rank: 1 - dim: [[1, c]] - (NXtransformations): - doc: | - Reference to or definition of a coordinate system with - which the qualifiers and polyline data are interpretable. - identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer which specifies the first index to be used for distinguishing - polylines. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - identifier(NX_INT): unit: NX_UNITLESS - doc: | - Integer used to distinguish polylines for explicit indexing. - dimensions: - rank: 1 - dim: [[1, c]] - + dim: (c,) # Users are encouraged to reduce the vertex set to the unique vertices. # Unique means not necessarily unique in position only but also unique in # identifier. In fact, it is possible to distinguish two vertices as two when # they share the same position in space but have different identifiers. vertices(NX_NUMBER): - unit: NX_LENGTH doc: | Positions of the vertices which support the members of the polyline set. - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - dimensions: - rank: 2 - dim: [[1, n_v], [2, d]] + Users are encouraged to reduce the vertices to unique positions and vertices + as this often supports with storing geometry data more efficiently. + It is also possible though to store the vertex positions naively + in which case vertices_are_unique is likely False. + Naively, here means that one stores each vertex of a triangle mesh + even though many vertices are shared between triangles and thus + storing multiple copies of their positions is redundant. + unit: NX_ANY + dim: (n_v, d) + # alternatively we may store the actual vertices in an instance of + # NXcg_point_set and (e.g. to promote compact storage of information and primitives) + # and then use + vertices_are_unique(NX_BOOLEAN): doc: | If true indicates that the vertices are all placed at different positions and have different identifiers, i.e. no points overlap - or are counted twice. + or are counted several times. polylines(NX_INT): - unit: NX_UNITLESS doc: | - Sequence of vertex identifiers which describe each polyline. + Sequence of identifier for vertices how they build each polyline. A trivial example is a set with two polylines with three vertices each. If the polylines meet in a junction, say the second vertex is shared and marking the junction between the two polylines, it is possible that - there are only five unique positions suggesting five unique vertices. + there are only five unique positions. This suggests to store five + unique vertices. - A non-trivial example is a set with several polylines, each of which with - eventually different number of vertices. The array stores the vertex - identifiers in the order how the polylines are visited: + A non-trivial example is a set with several polylines. Assume that each + has a different number of vertices. The array stores the identifier of + the vertices in the sequence how the polylines are visited: - The first entry is the identifier of the start vertex of the first polyline, + The first entry is the identifier of the first vertex of the first polyline, followed by the second vertex of the first polyline, until the last vertex - of the polyline. Thereafter, the start vertex of the second polyline, and - so on and so forth. Using the (cumulated) counts in number_of_vertices, - the vertices of the n-th polyline can be accessed on the following - array index interval: + of the first polyline. + Thereafter, the first vertex of the second polyline, and so on and so forth. + Using the (cumulated) counts in number_of_vertices, the vertices of the + n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - dimensions: - rank: 1 - dim: [[1, n_total]] - - # properties of the polyline primitives - length(NX_NUMBER): - unit: NX_LENGTH - doc: | - The length of each polyline. - dimensions: - rank: 1 - dim: [[1, c]] - is_closed(NX_BOOLEAN): - doc: | - If true specifies that a polyline is closed, i.e. - its end point is connected to the start point. - dimensions: - rank: 1 - dim: [[1, c]] - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 52bebf6552f880b30a2aaa931230be3a4e1c654b47e00f4f0b6f13d5d9f6c802 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality, which has to be at least 1. -# -# -# -# -# The cardinality of the set, i.e. the number of polylines. -# -# -# -# -# -# The number of vertices, supporting the polylines. -# -# -# -# -# The total number of vertices traversed when visiting every polyline. -# -# -# -# -# Computational geometry description of a set of polylines in Euclidean space. -# -# Each polyline is built from a sequence of vertices (points with identifiers). -# Each polyline must have a start and an end point. -# The sequence describes the positive traversal along the polyline when walking -# from the start vertex to the end/last vertex. -# -# -# -# -# -# -# The total number of vertices, irrespective of their eventual uniqueness, -# i.e. the total number of vertices that have to be visited when walking -# along each polyline. -# -# -# -# -# Array which specifies of how many vertices each polyline is built. -# The number of vertices represent the total number of vertices for -# each polyline, irrespectively whether vertices are shared or not. -# See the docstring for polylines for further details about how -# a set with different polyline members should be stored. -# -# -# -# -# -# -# -# Reference to or definition of a coordinate system with -# which the qualifiers and polyline data are interpretable. -# -# -# -# -# Integer which specifies the first index to be used for distinguishing -# polylines. Identifiers are defined either implicitly -# or explicitly. For implicit indexing the identifiers are defined on the -# interval [identifier_offset, identifier_offset+c-1]. -# For explicit indexing the identifier array has to be defined. -# -# The identifier_offset field can for example be used to communicate if the -# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) -# or from 0 (referred to as C-, Python-style index notation) respectively. -# -# -# -# -# Integer used to distinguish polylines for explicit indexing. -# -# -# -# -# -# -# -# -# Positions of the vertices which support the members of the polyline set. -# -# Users are encouraged to reduce the vertices to unique set of positions -# and vertices as this supports a more efficient storage of the geometry data. -# It is also possible though to store the vertex positions naively in which -# case vertices_are_unique is likely False. -# Naively here means that one for example stores each vertex of a triangle -# mesh even though many vertices are shared between triangles and thus -# the positions of these vertices do not have to be duplicated. -# -# -# -# -# -# -# -# -# If true indicates that the vertices are all placed at different -# positions and have different identifiers, i.e. no points overlap -# or are counted twice. -# -# -# -# -# Sequence of vertex identifiers which describe each polyline. -# -# A trivial example is a set with two polylines with three vertices each. -# If the polylines meet in a junction, say the second vertex is shared -# and marking the junction between the two polylines, it is possible that -# there are only five unique positions suggesting five unique vertices. -# -# A non-trivial example is a set with several polylines, each of which with -# eventually different number of vertices. The array stores the vertex -# identifiers in the order how the polylines are visited: -# -# The first entry is the identifier of the start vertex of the first polyline, -# followed by the second vertex of the first polyline, until the last vertex -# of the polyline. Thereafter, the start vertex of the second polyline, and -# so on and so forth. Using the (cumulated) counts in number_of_vertices, -# the vertices of the n-th polyline can be accessed on the following -# array index interval: -# :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. -# -# -# -# -# -# -# -# -# The length of each polyline. -# -# -# -# -# -# -# -# If true specifies that a polyline is closed, i.e. -# its end point is connected to the start point. -# -# -# -# -# -# -# -# + unit: NX_UNITLESS + dim: (n_total,) diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml new file mode 100644 index 0000000000..586929596f --- /dev/null +++ b/contributed_definitions/nyaml/NXcg_primitive_set.yaml @@ -0,0 +1,136 @@ +category: base +doc: | + Computational geometry description of a set of primitives in Euclidean space. + + Primitives must neither be degenerated nor self-intersect. + Individual primitives can differ in their properties (e.g. size, shape, rotation). +# this base class defines common fields and properties of geometric primitives +# more complex primitive sets like NXcg_cylinder_set are considered specializations +# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set +# defines. This is an action of compositing an information set; an act of inheriting +# TODO:: many properties of non-degenerate primitives are in the number set +# R+ instead of in R+0 but currently NeXus does not allow for such value range +# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT +# but there is no say NX_FLOAT+0 +# MK::but in computational geometry numerical precision matters as it defines +# whether objects numerically intersect or not and thus it can make a real difference +# if one stores triangles with 16, 32, or 64 bit precision, however: +# are two triangle_set instance A and B no longer conceptually triangle sets +# because A stores the positions of vertices using int8 while B stores such using float64 ? +# we here assume that we still conceptually talk that A and B are triangle sets +# but this brings at the level of the application definition the problem that if the +# precision is not properly constrainted a consuming application will not obtain +# the instances of the concept triangle_set with relevant high enough precision +# and thus neither the base class nor the application definition is specific enough +# for what it was designed in the first place - be specific about the requirements +# on your data... +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality of the space. + c: | + The cardinality of the set, i.e. the number of members. +type: group +NXcg_primitive_set(NXobject): + # individual specializations like NXcg_polyline_set typically overwrite + # the meaning of the depends_on concept to build consistent inference chains + # to enable an instantiation of the actual geometric primitives + \@depends_on(NX_CHAR): + doc: | + Hint to help resolve in which Euclidean coordinate system field values + like center or orientation are defined. + dimensionality(NX_POSINT): + doc: | + The dimensionality of the primitive set. + unit: NX_UNITLESS + enumeration: [1, 2, 3] + cardinality(NX_POSINT): + doc: | + The cardinality of the primitive set. + unit: NX_UNITLESS + identifier_offset(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the set differs from zero. + + Identifiers can be defined either implicitly or explicitly. + For implicit indexing identifiers are defined on the interval + :math:`[identifier_offset, identifier_offset + c - 1]`. + + Therefore, implicit identifier are completely defined by the value of + identifier_offset and cardinality. For example if identifier run from + -2 to 3 the value for identifier_offset is -2. + + For explicit indexing the field identifier has to be used. + Fortran-/Matlab- and C-/Python-style indexing have specific implicit + identifier conventions where identifier_offset is 1 and 0 respectively. + unit: NX_UNITLESS + identifier(NX_INT): + doc: | + Identifier of each member for explicit indexing. + dim: (c,) # numpy style indexing + center(NX_NUMBER): + doc: | + The center of mass position of each primitive. + unit: NX_ANY + dim: (c, d) + # a depends_on to define in which coordinate system + is_center_of_mass(NX_BOOLEAN): + doc: | + True if the center is a center of mass. + dim: (c,) + shape(NX_NUMBER): + doc: | + A qualitative description of the shape of each primitive. + unit: NX_LENGTH + dim: (c, d) + length(NX_NUMBER): + doc: | + Qualifier for the length of characteristic features of the primitive. + + Often the term length is associated with the assumption that one + edge is parallel to an axis of the coordinate system. + unit: NX_LENGTH + dim: (c,) + width(NX_NUMBER): + doc: | + Qualifier often used to describe the length of one characteristic edge + within the coordinate system. + unit: NX_LENGTH + dim: (c,) + is_closed(NX_BOOLEAN): + doc: | + True if primitive is closed such that it has properties like area or volume. + dim: (c,) + volume(NX_NUMBER): + doc: | + Volume of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_VOLUME + dim: (c,) + area(NX_NUMBER): + doc: | + Alias for surface_area of each primitive. + + Set to NaN if does not apply for primitives for which is_closed is False. + unit: NX_AREA + dim: (c,) + orientation(NX_NUMBER): + doc: | + Direction unit vector which points along the + longest principal axis of each primitive. + + Use the depends_on attribute to specify in which coordinate system + these direction unit vectors are defined. + unit: NX_DIMENSIONLESS + dim: (c, d) + vertex_normal(NXcg_unit_normal_set): + edge_normal(NXcg_unit_normal_set): + face_normal(NXcg_unit_normal_set): + # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) + # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) + # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) + # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcg_roi_set.yaml b/contributed_definitions/nyaml/NXcg_roi_set.yaml index be7d0e67b8..b10a341fe0 100644 --- a/contributed_definitions/nyaml/NXcg_roi_set.yaml +++ b/contributed_definitions/nyaml/NXcg_roi_set.yaml @@ -1,60 +1,33 @@ category: base doc: | - Base class to hold geometric primitives. + Base class for a region-of-interest (ROI) bound by geometric primitives. + + So-called region-of-interest(s) (ROIs) are typically used to describe a + region in space (and time) where an observation is made or for which + a computer simulation is performed with given boundary conditions. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. - + + Use the depends_on fields of the respective specialized :ref:`NXcg_primitive_set` + base class surplus :ref:`NXcoordinate_system_set` with at least one instance + of :ref:`NXcoordinate_system` to define explicitly the reference frame in + which the primitives are defined. + + Alternatively, although disencouraged, one may use one :ref:`NXcoordinate_system_set` + with with only one :ref:`NXcoordinate_system` in the application definition + to specify implicitly in which reference frame the primitives are defined. + + If none of these two possibilities is used all primitives are assumed + defined in the McStas coordinate system. # eventually redundant NXsolid_geometry? type: group NXcg_roi_set(NXobject): - CG_SPHERE_SET(NXcg_sphere_set): - CG_ELLIPSOID_SET(NXcg_ellipsoid_set): - CG_CYLINDER_SET(NXcg_cylinder_set): - CG_POLYHEDRON_SET(NXcg_polyhedron_set): - - # doc: An eventually redundant container to hold multiple primitives. + (NXcg_sphere_set): + (NXcg_ellipsoid_set): + (NXcg_cylinder_set): + (NXcg_parallelogram_set): + (NXcg_hexahedron_set): + (NXcg_polyhedron_set): # how to handle cases where multiple primitives should be included? - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 0ec7abc70466dfdba796af5579784b92e5add3c645754d0b1701b56a04708c95 -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Base class to hold geometric primitives. -# -# -# -# -# -# -# + # see comment to NXcg_triangle_set roi diff --git a/contributed_definitions/nyaml/NXcg_sphere_set.yaml b/contributed_definitions/nyaml/NXcg_sphere_set.yaml index 6a68132b17..c6b6e1d59b 100644 --- a/contributed_definitions/nyaml/NXcg_sphere_set.yaml +++ b/contributed_definitions/nyaml/NXcg_sphere_set.yaml @@ -1,8 +1,8 @@ category: base doc: | - Computational geometry description of a set of spheres in Euclidean space. + Computational geometry description of a set of spheres. - Each sphere can have a different radius. + Each sphere can have a different radius but all need to have finite volume. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -10,199 +10,16 @@ symbols: The dimensionality, which has to be at least 2. c: | The cardinality of the set, i.e. the number of circles or spheres. - # redundant as there is NXcsg, and NXquadric but easier to understand type: group -NXcg_sphere_set(NXobject): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - cardinality(NX_POSINT): - unit: NX_UNITLESS - identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer which specifies the first index to be used for distinguishing - identifiers for spheres. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Integer used to distinguish spheres for explicit indexing. - dimensions: - rank: 1 - dim: [[1, c]] - center(NX_NUMBER): - unit: NX_LENGTH - doc: | - Geometric center of the spheres. This can be the center of mass. - Dimensionality and cardinality of the point and sphere set have to match. - The identifier_offset and identifier field of NXcg_point_set do not need - to be used as they should be same as the identifier_offset and the - identifier for the spheres. - dimensions: - rank: 2 - dim: [[1, c], [2, d]] +NXcg_sphere_set(NXcg_ellipsoid_set): radius(NX_NUMBER): - unit: NX_LENGTH doc: | In the case that all spheres have the same radius. - radii(NX_NUMBER): unit: NX_LENGTH + radii(NX_NUMBER): doc: | In the case that spheres have different radius use this instead of the radius field. - dimensions: - rank: 1 - dim: [[1, c]] - (NXtransformations): - doc: | - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - # properties of spheres - is_closed(NX_BOOLEAN): - doc: | - Are the spheres closed or hollow? - dimensions: - rank: 1 - dim: [[1, c]] - volume(NX_NUMBER): - unit: NX_ANY - dimensions: - rank: 1 - dim: [[1, c]] - surface_area(NX_NUMBER): - unit: NX_ANY - dimensions: - rank: 1 - dim: [[1, c]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8252d8a3382853f5c129870a6ffd8c8c4c79a16da413f1092367ba600a69c6b6 -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality, which has to be at least 2. -# -# -# -# -# The cardinality of the set, i.e. the number of circles or spheres. -# -# -# -# -# Computational geometry description of a set of spheres in Euclidean space. -# -# Each sphere can have a different radius. -# -# -# -# -# -# Integer which specifies the first index to be used for distinguishing -# identifiers for spheres. Identifiers are defined either implicitly -# or explicitly. For implicit indexing the identifiers are defined on the -# interval [identifier_offset, identifier_offset+c-1]. -# For explicit indexing the identifier array has to be defined. -# -# The identifier_offset field can for example be used to communicate if the -# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) -# or from 0 (referred to as C-, Python-style index notation) respectively. -# -# -# -# -# Integer used to distinguish spheres for explicit indexing. -# -# -# -# -# -# -# -# Geometric center of the spheres. This can be the center of mass. -# Dimensionality and cardinality of the point and sphere set have to match. -# The identifier_offset and identifier field of NXcg_point_set do not need -# to be used as they should be same as the identifier_offset and the -# identifier for the spheres. -# -# -# -# -# -# -# -# -# In the case that all spheres have the same radius. -# -# -# -# -# In the case that spheres have different radius use this -# instead of the radius field. -# -# -# -# -# -# -# -# Reference to or definition of a coordinate system with -# which the positions and directions are interpretable. -# -# -# -# -# -# Are the spheres closed or hollow? -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# + unit: NX_LENGTH + dim: (c,) diff --git a/contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml b/contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml index 9a9335556a..1200fc9e10 100644 --- a/contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml +++ b/contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml @@ -1,313 +1,44 @@ category: base doc: | - Computational geometry description of a set of tetrahedra in Euclidean space. + Computational geometry description of a set of tetrahedra. - The tetrahedra do not have to be connected. - As tetrahedral elements they are among hexahedral elements one of the most + Among hexahedral elements, tetrahedral elements are one of the most frequently used geometric primitive for meshing and describing volumetric - and surface descriptions of objects at the continuum scale. - - A set of tetrahedra in 3D Euclidean space. - - The tetrahedra do not have to be connected, can have different size, - can intersect, and be rotated. - - Tetrahedra are the simplest and thus important geometrical primitive. - They are frequently used as elements in finite element meshing/modeling. - - Tetrahedra have to be non-degenerated, closed, and built of triangles - which are not self-intersecting. + objects in continuum-field simulations. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. c: | The cardinality of the set, i.e. the number of tetrahedra. - -# it is useful to define own base classes for frequently used classes -# a polyhedron is a specific polytope in 3d, do we need -# higher-dimensional polytopes? that could be useful for simplicies though -# as they are used in numerics etc. maybe reach out here to our friends -# from MarDI, for now let's assume we do not need polytopes for d > 3 type: group -NXcg_tetrahedron_set(NXobject): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - enumeration: [3] - cardinality(NX_POSINT): - unit: NX_UNITLESS - +NXcg_tetrahedron_set(NXcg_primitive_set): # qualifiers and properties of tetrahedra - volume(NX_NUMBER): - unit: NX_VOLUME - doc: | - Interior volume - dimensions: - rank: 1 - dim: [[1, c]] - center(NX_NUMBER): - unit: NX_LENGTH - doc: | - Position of the geometric center, which often is but not necessarily - has to be the center_of_mass of the tetrahedra. - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] - surface_area(NX_NUMBER): - unit: NX_AREA - doc: | - Total surface area as the sum of all four triangular faces. - dimensions: - rank: 1 - dim: [[1, c]] face_area(NX_NUMBER): - unit: NX_AREA doc: | Area of each of the four triangular faces of each tetrahedron. - dimensions: - rank: 2 - dim: [[1, c], [2, 4]] + unit: NX_AREA + dim: (c, 4) edge_length(NX_NUMBER): - unit: NX_LENGTH doc: | Length of each edge of each tetrahedron. - dimensions: - rank: 2 - dim: [[1, c], [2, 6]] - (NXtransformations): - doc: | - Reference to or definition of a coordinate system with - which the qualifiers and mesh data are interpretable. - + unit: NX_LENGTH + dim: (c, 6) # substantially more detailed descriptors of the shape, the mesh + # currently not used should be discussed as sequence might not be clear to everybody # interior_angle(NX_NUMBER): - # doc: | - # Array of interior angle values. For each tetrahedron the quadruplet of - # angles is a sequence following the order of the vertices. The angle - # is the angle at the specific vertex. TODO lexiographical order. - # Winding order has to be interpreted to resolve the individual angles - # between edges of adjoining face triangles meeting at each corner/vertex. - # unit: NX_ANGLE - # dimensions: - # rank: 2 - # dim: [[1, c], [2, 12]] - identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer which specifies the first index to be used for distinguishing - tetrahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Integer used to distinguish tetrahedra for explicit indexing. - dimensions: - rank: 1 - dim: [[1, c]] - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - + # doc: | + # Interior angle values for each tetrahedron. + # The quadruplet of angles is a sequence following the order of the vertices. + # The angle is the angle at the specific vertex. + # + # The sequence of the vertices follows their definition in tetrahedra. # detailed mesh-based representation tetrahedra(NXcg_face_list_data_structure): - - # exists: [min, 0, max, 1] doc: | - A simple approach to describe the entire set of tetrahedra when the - main intention is to store the shape of the tetrahedra for visualization. - should take the possibility to describe - tetrahedron(NXcg_face_list_data_structure): - - # exists: [min, 0, max, infty] # can this be max, c? + Combined storage of all primitives of all tetrahedra. + tetrahedronID(NXcg_face_list_data_structure): doc: | - Disentangled representations of the mesh of specific tetrahedra. - tetrahedron_half_edge(NXcg_half_edge_data_structure): - - # exists: [min, 0, max, infty] + Individual storage of each tetrahedron. + tetrahedron_half_edgeID(NXcg_half_edge_data_structure): doc: | - Disentangled representation of the planar graph that each tetrahedron - represents. Such a description simplifies topological processing - or analyses of mesh primitive operations and neighborhood queries. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# b7e4857da33c0b32cad2f9e3ca84f6170ff76bb57e8a392b49ebbbb19b18cef6 -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The cardinality of the set, i.e. the number of tetrahedra. -# -# -# -# -# Computational geometry description of a set of tetrahedra in Euclidean space. -# -# The tetrahedra do not have to be connected. -# As tetrahedral elements they are among hexahedral elements one of the most -# frequently used geometric primitive for meshing and describing volumetric -# and surface descriptions of objects at the continuum scale. -# -# A set of tetrahedra in 3D Euclidean space. -# -# The tetrahedra do not have to be connected, can have different size, -# can intersect, and be rotated. -# -# Tetrahedra are the simplest and thus important geometrical primitive. -# They are frequently used as elements in finite element meshing/modeling. -# -# Tetrahedra have to be non-degenerated, closed, and built of triangles -# which are not self-intersecting. -# -# -# -# -# -# -# -# -# -# -# Interior volume -# -# -# -# -# -# -# -# Position of the geometric center, which often is but not necessarily -# has to be the center_of_mass of the tetrahedra. -# -# -# -# -# -# -# -# -# Total surface area as the sum of all four triangular faces. -# -# -# -# -# -# -# -# Area of each of the four triangular faces of each tetrahedron. -# -# -# -# -# -# -# -# -# Length of each edge of each tetrahedron. -# -# -# -# -# -# -# -# -# Reference to or definition of a coordinate system with -# which the qualifiers and mesh data are interpretable. -# -# -# -# -# -# Integer which specifies the first index to be used for distinguishing -# tetrahedra. Identifiers are defined either implicitly -# or explicitly. For implicit indexing the identifiers are defined on the -# interval [identifier_offset, identifier_offset+c-1]. -# For explicit indexing the identifier array has to be defined. -# -# The identifier_offset field can for example be used to communicate if the -# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) -# or from 0 (referred to as C-, Python-style index notation) respectively. -# -# -# -# -# Integer used to distinguish tetrahedra for explicit indexing. -# -# -# -# -# -# -# -# -# -# -# -# -# A simple approach to describe the entire set of tetrahedra when the -# main intention is to store the shape of the tetrahedra for visualization. -# should take the possibility to describe -# -# -# -# -# -# Disentangled representations of the mesh of specific tetrahedra. -# -# -# -# -# -# Disentangled representation of the planar graph that each tetrahedron -# represents. Such a description simplifies topological processing -# or analyses of mesh primitive operations and neighborhood queries. -# -# -# + Individual storage of each tetrahedron as a graph. diff --git a/contributed_definitions/nyaml/NXcg_triangle_set.yaml b/contributed_definitions/nyaml/NXcg_triangle_set.yaml index 563d271006..5eb5b915eb 100644 --- a/contributed_definitions/nyaml/NXcg_triangle_set.yaml +++ b/contributed_definitions/nyaml/NXcg_triangle_set.yaml @@ -1,6 +1,6 @@ category: base doc: | - Computational geometry description of a set of triangles in Euclidean space. + Computational geometry description of a set of triangles. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -11,215 +11,40 @@ symbols: n_unique: | The number of unique vertices supporting the triangles. type: group -NXcg_triangle_set(NXobject): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - cardinality(NX_POSINT): - unit: NX_UNITLESS - number_of_unique_vertices(NX_POSINT): - unit: NX_UNITLESS - (NXtransformations): +NXcg_triangle_set(NXcg_primitive_set): + number_of_unique_vertices(NX_INT): doc: | - Reference to or definition of a coordinate system with - which the qualifiers and primitive data are interpretable. - identifier_offset(NX_INT): + Number of unique vertices in the triangle set. unit: NX_UNITLESS - doc: | - Integer which specifies the first index to be used for distinguishing - triangles. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Integer used to distinguish triangles for explicit indexing. - dimensions: - rank: 1 - dim: [[1, c]] triangles(NXcg_face_list_data_structure): - - # exists: [min, 0, max, 1] doc: | - A simple approach to describe the entire set of triangles when the - main intention is to store the shape of the triangles for visualization. - - # detailed additional information eventually mesh-related data - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - - # triangles_half_edge(NXcg_half_edge_data_structure): + Combined storage of all primitives of all triangles. + + This description resembles the typical representation of primitives + in file formats such as OFF, PLY, VTK, or STL. + triangleID(NXcg_face_list_data_structure): + doc: | + Individual storage of each triangle. + Users are advised that using such individual storage of primitives + may be less storage efficient than creating a combined storage. + # ##MK::considered too trivial: + # triangle_half_edgeID(NXcg_half_edge_data_structure): + # doc: | + # Individual storage of each triangle as a graph. # properties of triangles - area(NX_NUMBER): - unit: NX_AREA - dimensions: - rank: 1 - dim: [[1, c]] edge_length(NX_NUMBER): - unit: NX_LENGTH doc: | - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] - interior_angle(NX_NUMBER): - unit: NX_ANGLE - doc: | - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] - center(NX_NUMBER): + Length of the edges of each triangle. + + For each triangle values are reported via traversing + the vertices in the sequence as these are defined. unit: NX_LENGTH + dim: (c, 3) + interior_angle(NX_NUMBER): doc: | - The center of mass of each polygon. - dimensions: - rank: 2 - dim: [[1, c], [2, d]] - bounding_box(NXcg_hexahedron_set): - doc: | - Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 574e944e837cb00c15434545fb0d6a976d91f0781fb71e85f1c43577bfda6140 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality, which has to be at least 2. -# -# -# -# -# The cardinality of the set, i.e. the number of triangles. -# -# -# -# -# The number of unique vertices supporting the triangles. -# -# -# -# -# Computational geometry description of a set of triangles in Euclidean space. -# -# -# -# -# -# -# Reference to or definition of a coordinate system with -# which the qualifiers and primitive data are interpretable. -# -# -# -# -# Integer which specifies the first index to be used for distinguishing -# triangles. Identifiers are defined either implicitly -# or explicitly. For implicit indexing the identifiers are defined on the -# interval [identifier_offset, identifier_offset+c-1]. -# For explicit indexing the identifier array has to be defined. -# -# The identifier_offset field can for example be used to communicate if the -# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) -# or from 0 (referred to as C-, Python-style index notation) respectively. -# -# -# -# -# Integer used to distinguish triangles for explicit indexing. -# -# -# -# -# -# -# -# -# A simple approach to describe the entire set of triangles when the -# main intention is to store the shape of the triangles for visualization. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Array of edge length values. For each triangle the edge length is -# reported for the edges traversed according to the sequence -# in which vertices are indexed in triangles. -# -# -# -# -# -# -# -# -# Array of interior angle values. For each triangle the angle is -# reported for the angle opposite to the edges which are traversed -# according to the sequence in which vertices are indexed in triangles. -# -# -# -# -# -# -# -# -# The center of mass of each polygon. -# -# -# -# -# -# -# -# -# Axis-aligned or (approximate) (optimal) bounding boxes to each polygon. -# -# -# + Interior angles of each triangle. + + For each triangle values are reported for the angle opposite + to the respective edges in the sequence how vertices are defined. + unit: NX_ANGLE + dim: (c, 3) diff --git a/contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml b/contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml index 331132a4bf..927134bb85 100644 --- a/contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml +++ b/contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml @@ -3,87 +3,13 @@ doc: | Computational geometry description of a mesh of triangles. The mesh may be self-intersecting and have holes but the - triangles must not be degenerated. + triangles used must not be degenerated. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. type: group -NXcg_triangulated_surface_mesh(NXobject): - - # (NXtransformations): - # doc: | - # Reference to or definition of a coordinate system with - # which the qualifiers and mesh data are interpretable. - # substantially more detailed descriptors of the shape, the mesh - # vertex_normal(NXcg_unit_normal_set): - # edge_normal(NXcg_unit_normal_set): - # face_normal(NXcg_unit_normal_set): - # detailed mesh-based representation - # (NXcg_face_list_data_structure): - # doc: | - # A simple approach to describe the mesh when the main intention is to - # store its triangles for visualization. - (NXcg_triangle_set): +NXcg_triangulated_surface_mesh(NXcg_triangle_set): (NXcg_half_edge_data_structure): doc: | A graph-based approach to describe the mesh when it is also desired to perform topological processing or analyses on the mesh. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f767c4a846ca64e44a4cff7e4b570cc7344eed42484aba4592765cd8709de56c -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Computational geometry description of a mesh of triangles. -# -# The mesh may be self-intersecting and have holes but the -# triangles must not be degenerated. -# -# -# -# -# -# A graph-based approach to describe the mesh when it is also desired -# to perform topological processing or analyses on the mesh. -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_unit_normal_set.yaml b/contributed_definitions/nyaml/NXcg_unit_normal_set.yaml index 2e71ea3ad1..1f293365d8 100644 --- a/contributed_definitions/nyaml/NXcg_unit_normal_set.yaml +++ b/contributed_definitions/nyaml/NXcg_unit_normal_set.yaml @@ -1,6 +1,11 @@ category: base doc: | Computational geometry description of a set of (oriented) unit normal vectors. + + Store normal vector information as properties of primitives. + Use only only as a child of an instance of :ref:`NXcg_primitive_set` + so that this instance acts as the parent to define a context. +# eventually remove this base class and make normal vector a property of the primitive symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -14,99 +19,19 @@ symbols: # rather make this a set of vectors, irrespective whether these are unit or not type: group NXcg_unit_normal_set(NXobject): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - cardinality(NX_POSINT): - unit: NX_UNITLESS - normals(NX_FLOAT): - unit: NX_LENGTH + normals(NX_NUMBER): doc: | - Direction of each normal - dimensions: - rank: 2 - dim: [[1, c], [2, d]] + Direction of each normal - a unit normal. + unit: NX_LENGTH # length is normalized to 1 but it remains a length quantity + dim: (c, d) orientation(NX_INT): - unit: NX_UNITLESS doc: | - Qualifier how which specifically oriented normal to its primitive each - normal represents. + Qualifier which details the orientation of each normal vector + in relation to its primitive, assuming the object is viewed + from a position outside the object. * 0 - undefined - * 1 - outer - * 2 - inner - dimensions: - rank: 1 - dim: [[1, c]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 6cdabb3b71835f738286e56c56d5f2f17727ea0c100c482d78d678383c9291e7 -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality, which has to be at least 2. -# -# -# -# -# The cardinality of the set, i.e. the number of unit normals. -# -# -# -# -# Computational geometry description of a set of (oriented) unit normal vectors. -# -# -# -# -# -# Direction of each normal -# -# -# -# -# -# -# -# -# Qualifier how which specifically oriented normal to its primitive each -# normal represents. -# -# * 0 - undefined -# * 1 - outer -# * 2 - inner -# -# -# -# -# -# + * 1 - outer unit normal vector + * 2 - inner unit normal vector + unit: NX_UNITLESS + dim: (c,) diff --git a/contributed_definitions/nyaml/NXchamber.yaml b/contributed_definitions/nyaml/NXchamber.yaml index d005a94bf4..2a4d2c4495 100644 --- a/contributed_definitions/nyaml/NXchamber.yaml +++ b/contributed_definitions/nyaml/NXchamber.yaml @@ -1,56 +1,14 @@ category: base doc: | - Component of an instrument to store or place objects and specimens. + Base class for a chamber in an instrument that stores real or simulated objects. type: group NXchamber(NXobject): - name: + name(NX_CHAR): doc: | - Given name/alias. - description: + Given name for the chamber of this component e.g. analysis chamber + or buffer chamber, load-lock chamber, microscope column, glove box. + description(NX_CHAR): doc: | Free-text field for describing details about the chamber. For example out of which material was the chamber built. (NXfabrication): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# aac9dc98bb6c764714f7b55ce85e6a46223a6d6d35927540cd47d4a4795cad82 -# -# -# -# -# -# Component of an instrument to store or place objects and specimens. -# -# -# -# Given name/alias. -# -# -# -# -# Free-text field for describing details about the chamber. -# For example out of which material was the chamber built. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcomponent_em.yaml b/contributed_definitions/nyaml/NXcomponent_em.yaml new file mode 100644 index 0000000000..78870cc26b --- /dev/null +++ b/contributed_definitions/nyaml/NXcomponent_em.yaml @@ -0,0 +1,39 @@ +category: base +doc: | + Base class for components used in an electron microscope. + + The electron microscope can be a real one or a simulated microscope. + The key motivation behind this generalization is the observation that in all + cases a controlled electron beam is generated in reality or that beam is simulated + and this beam is then used or modified in a controlled manner for the purpose + of studying physical interaction mechanisms of the beam with matter. + Here it does not matter whether one considers a real specimen or a simulated one. + + Using a common description for the real experiment in the lab and - what is + typically a simplification of it - via a computer simulation, has the benefit + that many pieces of information can be stored in the same way. In effect, + users are guided with finding information and unnecessary descriptive + variety for what are exactly the same concept is avoided to work towards + more interoperability. + + Another motivation to make no fundamental distinction between a scanning and + a transmission electron microscope is that both are electron microscopes whose + components are often very similar. +# `point Electronic GmbH `_ +type: group +NXcomponent_em(NXobject): + name(NX_CHAR): + doc: | + Given name to the component e.g stage, lens C1, etc. + description(NX_CHAR): # NXidentifier + doc: | + Ideally, a (globally) unique persistent identifier, link, or text to a + resource which gives further details to this component. + If such resource does not exist, a free-text field to report + further details about the component is possible. + (NXfabrication): + (NXprogram): + (NXtransformations): + doc: | + Collection of axis-based translations and rotations to describe the + location and geometry of the component in the instrument. diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml new file mode 100644 index 0000000000..b219399001 --- /dev/null +++ b/contributed_definitions/nyaml/NXcoordinate_system.yaml @@ -0,0 +1,86 @@ +category: base +doc: | + Base class to detail a coordinate system (CS). + + Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as + a member in an :ref:`NXcoordinate_system_set` and the name of the instance + should be this alias. This may support a process whereby jargon when talking + about coordinate systems and conventions may become cleaner for users + because it is not evident for people outside a lab that terms like e.g. + tip space or specimen space refer to the same coordinate system. + This is an example of jargon used in e.g. the field of atom + probe tomography. +type: group +NXcoordinate_system(NXobject): + origin(NX_CHAR): + doc: | + Human-readable field telling where the origin of this CS is. + Exemplar values could be *left corner of the lab bench*, *door-handle* + *pinhole through which the electron beam exists the pole piece*. + *barycenter of the triangle*, *center of mass of the stone*. + # implementing a proposal for "a common base table" along thoughts like: + # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations + # similar to a place where all transformations are stored + # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 + alias(NX_CHAR): + doc: | + An alternative name given to that coordinate system. + type(NX_CHAR): + doc: | + Coordinate system type. + enumeration: [cartesian] + handedness(NX_CHAR): + doc: | + Handedness of the coordinate system if it is a Cartesian. + enumeration: [right_handed, left_handed] + x_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the x-axis. + x_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + x(NX_NUMBER): + doc: | + Base unit vector along the first axis which spans the coordinate system. + This axis is frequently referred to as the x-axis in real space and + the i-axis in reciprocal space. + unit: NX_LENGTH + dim: (3,) + y_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the y-axis. + y_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + y(NX_NUMBER): + doc: | + Base unit vector along the second axis which spans the coordinate system. + This axis is frequently referred to as the y-axis in real space and + the j-axis in reciprocal space. + unit: NX_LENGTH + dim: (3,) + z_alias(NX_CHAR): + doc: | + Possibility to define an alias for the name of the z-axis. + z_direction(NX_CHAR): + doc: | + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + z(NX_NUMBER): + doc: | + Base unit vector along the second axis which spans the coordinate system. + This axis is frequently referred to as the z-axis in real space and + the k-axis in reciprocal space. + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXcoordinate_system_set.yaml b/contributed_definitions/nyaml/NXcoordinate_system_set.yaml index c149cc4039..c0b922c928 100644 --- a/contributed_definitions/nyaml/NXcoordinate_system_set.yaml +++ b/contributed_definitions/nyaml/NXcoordinate_system_set.yaml @@ -1,257 +1,98 @@ category: base doc: | - Container to hold different coordinate systems conventions. + Base class to hold different coordinate systems and representation conversions. - It is the purpose of this base class to define these conventions and - offer a place to store mappings between different coordinate systems - which are relevant for the interpretation of the data described - by the application definition and base class instances. + How many nodes of type :ref:`NXcoordinate_system_set` should be used in an appdef? - For each Cartesian coordinate system users should use a set of - NXtransformations: + * 0; if no instance of :ref:`NXcoordinate_system_set` and therein or elsewhere across + the appdef an instance of NXcoordinate_system is defined, + the default NeXus `McStas `_ + coordinate system is assumed. This makes :ref:`NXcoordinate_system_set` and + NXcoordinate_system base classes backwards compatible to older + NeXus conventions and classes. + * 1; if only one :ref:`NXcoordinate_system_set` is defined, it should be placed + as high up in the node hierarchy (ideally right below an instance of NXentry) + of the application definition tree as possible. + This :ref:`NXcoordinate_system_set` should at least define one NXcoordinate_system + instance which should be called mcstas for the sake of improved clarity. + Alternatively, at least one NXcoordinate_system member of the set should be + defined and named such that it is clear how this coordinate system is + typically referred to in a community. Additional NXcoordinate_system instances + should be specified if possible in that same :ref:`NXcoordinate_system_set` instead + of cluttering them across the tree. + + If this is the case, it is assumed that the NXcoordinate_system_members + overwrite the NeXus default McStas coordinate system, i.e. users can thereby + conveniently and explicitly specify the coordinate system(s) that + they wish to use. + + Users are encouraged to write also explicit and clean depends_on fields in + all groups that encode information about where the interpretation of coordinate + systems is relevant. If these depends_on hints are not provided, it is + automatically assumed that all children (to arbitrary depth) + of that branch and sub-branches below the one in which that + :ref:`NXcoordinate_system_set` is defined use either the only NXcoordinate_system_set + instance in that set or the application definition is considered + underconstrained which should at all costs be avoided and in which case + again McStas is assumed. + * 2 and more; as soon as more than one :ref:`NXcoordinate_system_set` is specified + somewhere in the tree, different interpretations are possible as to which + of these coordinate system sets and instances apply or take preference. + We realize that such ambiguities should at all costs be avoided. + However, the opportunity for multiple sets and their instances enables to + have branch-specific coordinate system conventions which could especially + be useful for deep classes where multiple scientific methods are combined or + cases where having a definition of global translation and conversion tables + how to convert between representations in different coordinate systems + is not desired or available for now. + We argue that having 2 or more :ref:`NXcoordinate_system_set` instances and respective + NXcoordinate_system instances makes the interpretation eventually unnecessary + complicated. Instead, developers of application definitions should always try + to work for clarity and thus use only one top-level coordinate system set. - * These should define the three base vectors. - * The location of the origin. - * The affine transformations which bring each axis of this coordinate system - into registration with the McStas coordinate system. - * Equally, affine transformations should be given for the inverse mapping. + For these reasons we conclude that the option with one top-level + :ref:`NXcoordinate_system_set` instance is the preferred choice. - As an example one may take an experiment or computer simulation where - there is a laboratory (lab) coordinate system, a sample/specimen coordinate - system, a crystal coordinate system, and additional coordinate systems, - which are eventually attached to components of the instrument. + McStas is used if neither an instance of :ref:`NXcoordinate_system_set` nor an instance + of NXcoordinate_system is specified. However, even in this case it is better + to be explicit like for every other coordinate system definition to support + users with interpreting the content and logic behind every instance of the tree. - If no additional transformation is specified in this group or if an - instance of an NXcoordinate_system_set is absent it should be assumed - the so-called McStas coordinate system is used. + How to store coordinate systems inside :ref:`NXcoordinate_system_set`? + Individual coordinate systems should be specified as members of the + :ref:`NXcoordinate_system_set` instance using instances of NXcoordinate_system. - Many application definitions in NeXus refer to this `McStas `_ coordinate system. - This is a Cartesian coordinate system whose z axis points along the neutron - propagation axis. The systems y axis is vertical up, while the x axis points - left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. + How many individual instances of NXcoordinate_system to allow within one + instance of :ref:`NXcoordinate_system_set`? - Within each NXtransformations a depends_on section is required. The depends_on - field specifies if the coordinate system is the root/reference - (which is indicated by writing "." in the depends_on section.) + * 0; This case should be avoided for the sake of clarity but this case could + mean the authors of the definition meant that McStas is used. We conclude, + McStas is used in this case. + * 1; Like above-mentioned this case has the advantage that it is explicit + and faces no ambiguities. However, in reality typically multiple + coordinate systems have to be mastered especially for complex + multi-signal modality experiments. + * 2 or more; If this case is realized, the best practice is that in every + case where a coordinate system should be referred to the respective class + has a depends_on field which resolves the possible ambiguities which specific + coordinate systems is referred to. The benefit of this explicit and clear + specifying of the coordinate system used in every case is that especially + in combination with having coordinate systems inside deeper branches + makes up for a very versatile, backwards compatible, but powerful system + to express different types of coordinate systems using NeXus. + + In effect, 1 should be the preferred choice. However, if more than one coordinate + system is defined for practical purposes, explicit depends_on fields should + always guide the user for each group and field which of the coordinate system + one refers to. type: group NXcoordinate_system_set(NXobject): - - # implementing a proposal for "a common base table" along thoughts like: - # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations - # similar to a place where all transformations are stored - # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 - (NXtransformations): - doc: | - A group of transformations which specify: - - * Three base vectors of the coordinate system. - * Origin of the coordinate system. - * A depends_on keyword. Its value can be "." or the name of an - NXtransformations instance which needs to exist in the - NXcoordinate_system_set instance. - * If the coordinate system is the reference one it has to be named - reference. - - In case of having more than one NXtransformations there has to be for - each additional coordinate system, i.e. the one not the reference: - - * A set of translations and rotations which map each base vector to the reference. - * A set of translations and rotations which map each reference base vector - to the coordinate system. - - The NXtransformations for these mappings need to be formatted - according to the descriptions in NXtransformations. - - # NEW ISSUE: add an illustrated example - - # thoughts on how to use this - # these user-defined frames could be the sample surface, the detector, - # individual frames attached to specific instruments, for instance in an - # atom probe experiment we usually have a lab, specimen surface/apex, laser (pinhole), detector, reconstruction frames - # in electron/focused ion beam, lab, e-beam, i-beam, sample surface, individual frames for each detector - - # THE REMAINING TEXT IS NOT PART OF THE BASE CLASS - # An example follows how each field under transformations can look like - # I would like to encourage a description where each coordinate system is defined - # and for each coordinate system a transformation written down which maps each - # user-defined Frame_i onto Frame_McStas (and maybe for convenience purposes also vice versa - # Frame_McStas = T_i * Frame_i - # if there would be a small python tool that takes a collection of frames - # and does the mapping automatically and writing the respective NeXus entries - # this would be very useful. - - # \@transformation_type should not be used - # define frame of reference that is understood as the laboratory coordinate system - # x_axis(NX_NUMBER): - # unit: NX_TRANSFORMATION - # \@depends_on: # "." meaning the root coordinate system, i.e. the McStas - # \@vector(NX_NUMBER): # [1, 0, 0] - # \@offset(NX_NUMBER): - # y_axis(NX_NUMBER): - # unit: NX_TRANSFORMATION - # \@depends_on: # "." - # \@vector(NX_NUMBER): # [0, 1, 0] - # \@offset(NX_NUMBER): - # z_axis(NX_NUMBER): - # unit: NX_TRANSFORMATION - # \@depends_on: # "." - # \@vector(NX_NUMBER): # [0, 0, 1] - # \@offset(NX_NUMBER): # is [0, 0, 0] if the origin of the McStas coordinate system and of the laboratory_frame overlap - # \@offset_units: # should be an NX_LENGTH - # and how it translates into the McStas convention - # lab_mcstas(NX_NUMBER): - # doc: Rotation matrix which maps the x_axis of the laboratory_frame to the x_axis of the McStas system. - # BUT as far as I know you cannot define a 3D rotation matrix, you should rather make a chain of transformations - # each about a single axis and thus building a depends_on chain - # for example a 4x4 translation with a more-than-one-value-non-zero/non-identity rotation matrix - # could be you first rotate about Z by R_Z'/R_1 depends_on is x_axis := X, yielding X', Y', Z' - # second you rotate about the X' by R_X/R_2 depends_on is X', yielding X'', Y'', Z'' - # third you rotate about the Z'' by R_Z''/R_3 depends_on is then Z'', yielding X''', Y''', Z''' matching McStas, - # this is the Bunge-Euler way of doing it, but would it also be possible to just define - # the lab_mcstas(NX_NUMBER) value as an 3x3 array and give the offsets and translations as it is discussed in the manual ? - # unit: NX_ANGLE - # \@depends_on: # x_axis - # 3x3 rotation matrices are decoupled into three successive planar rotations - # see https://manual.nexusformat.org/classes/base_classes/NXtransformations.html - # mcstas_to_lab(NX_NUMBER): - # same story but the inverse affine transformation + (NXcoordinate_system): +# How to interpret "depends_on" calls for NXtransformations instances which live +# within an instance of NXcoordinate_system(_set)? +# Depends on cardinality of NXcoordinate_system_set, i.e. how many NXcoordinate_system are defined? +# - 0, the root of an NXtransformation chain i.e. "." means McStas +# - 1, the root of an NXtransformation chain i.e. "." means "that specific CS" i.e. the one defined by the single instance of NXcoordinate_system in the set +# - > 1, "." becomes ambiguous. My suggestion, spell out the name of the specific NXcoordinate_system instance to be used, using "." +# despite all these, a warning should be raised, like a logic warning (and McStas kick in) or an error (i.e. be forbidden) be raised -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 48ed635c5273f21260f9b713c76f685e529d7f26041bea06ddc43e3566ac7916 -# -# -# -# -# -# Container to hold different coordinate systems conventions. -# -# It is the purpose of this base class to define these conventions and -# offer a place to store mappings between different coordinate systems -# which are relevant for the interpretation of the data described -# by the application definition and base class instances. -# -# For each Cartesian coordinate system users should use a set of -# NXtransformations: -# -# * These should define the three base vectors. -# * The location of the origin. -# * The affine transformations which bring each axis of this coordinate system -# into registration with the McStas coordinate system. -# * Equally, affine transformations should be given for the inverse mapping. -# -# As an example one may take an experiment or computer simulation where -# there is a laboratory (lab) coordinate system, a sample/specimen coordinate -# system, a crystal coordinate system, and additional coordinate systems, -# which are eventually attached to components of the instrument. -# -# If no additional transformation is specified in this group or if an -# instance of an NXcoordinate_system_set is absent it should be assumed -# the so-called McStas coordinate system is used. -# -# Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. -# This is a Cartesian coordinate system whose z axis points along the neutron -# propagation axis. The systems y axis is vertical up, while the x axis points -# left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. -# -# Within each NXtransformations a depends_on section is required. The depends_on -# field specifies if the coordinate system is the root/reference -# (which is indicated by writing "." in the depends_on section.) -# -# -# -# -# A group of transformations which specify: -# -# * Three base vectors of the coordinate system. -# * Origin of the coordinate system. -# * A depends_on keyword. Its value can be "." or the name of an -# NXtransformations instance which needs to exist in the -# NXcoordinate_system_set instance. -# * If the coordinate system is the reference one it has to be named -# reference. -# -# In case of having more than one NXtransformations there has to be for -# each additional coordinate system, i.e. the one not the reference: -# -# * A set of translations and rotations which map each base vector to the reference. -# * A set of translations and rotations which map each reference base vector -# to the coordinate system. -# -# The NXtransformations for these mappings need to be formatted -# according to the descriptions in NXtransformations. -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcorrector_cs.yaml b/contributed_definitions/nyaml/NXcorrector_cs.yaml index 632aaf5c9f..bbe1b033af 100644 --- a/contributed_definitions/nyaml/NXcorrector_cs.yaml +++ b/contributed_definitions/nyaml/NXcorrector_cs.yaml @@ -2,157 +2,67 @@ category: base doc: | Corrector for aberrations in an electron microscope. - Different technology partners use different naming schemes and models - for quantifying the aberration coefficients. + Different technology partners use different naming schemes and + models for quantifying the aberration coefficients. - The corrector in an electron microscope is composed of multiple lenses and - multipole stigmators with vendor-specific details which are often undisclosed. + The corrector in an electron microscope is composed of multiple lenses + and multipole stigmators with details specific for the technology partner + and microscope. Many of their technical details is proprietary knowledge. type: group -NXcorrector_cs(NXobject): +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_img: | + Number of images taken, at least one. +NXcorrector_cs(NXcomponent_em): applied(NX_BOOLEAN): doc: | Was the corrector used? - name: - doc: | - Given name/alias. - (NXfabrication): - description: - doc: | - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. If this does not exist - a free-text field to report further details about the corrector. - # NEW ISSUE: clarify the mathematical details behind the - # NEW ISSUE: following parameters of the these constants and how they are useful ZEMLIN_TABLEAU(NXprocess): doc: | Specific information about the concrete alignment procedure which is a process during which the corrector is configured to enable a calibrated - usage of the microscope. - description: + usage of the instrument. + + This :ref:`NXprocess` group should also be used when one describes in a computer + simulation the specific details about the modelled or assumed aberration + corrections. In effect, this base class can also be used for harmonizing + the description of such simulation details across different computer codes + to enable that a research data management system can find these information + in a common place - formatted in a normalized representation. + This reduces the necessity to include substantial case-dependent verification + code in the research data management system. + description(NX_CHAR): doc: | - Discouraged free-text field to add further details about the alignment - procedure. - tilt_angle(NX_FLOAT): + Discouraged free-text field to add further details about + the alignment procedure. + tilt_angle(NX_NUMBER): + doc: | + The outer tilt angle of the beam in tableau acquisition. + + TODO: The relevant axes which span the tilt_angle need a + cleaner description. unit: NX_ANGLE + dim: (n_img,) + exposure_time(NX_NUMBER): doc: | - The outer tilt angle of the beam in tableau aquisition. - exposure_time(NX_FLOAT): + The exposure time of single tilt images. unit: NX_TIME - doc: | - The exposure time of the single tilt images. + dim: (n_img,) magnification(NX_NUMBER): - unit: NX_DIMENSIONLESS doc: | The factor of enlargement of the apparent size, - not physical size, of an object. + not the physical size, of an object. + unit: NX_DIMENSIONLESS + dim: (n_img,) + (NXimage_set): + doc: | + The images taken during the alignment procedure. (NXprocess): doc: | Place for storing measured or estimated aberrations (for each image or final). ceos(NXaberration_model_ceos): nion(NXaberration_model_nion): - # technical components of the corrector (NXlens_em): - (NXtransformations): - - # NEW ISSUE: add the reference to the conversion table between - # NEW ISSUE: Haider and Krivanek The table [##MK]() is here used for reference. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 34f8ac6822123ec86d01f9aeb8ac349941959381695dba1e7c9f5f55d2e720f1 -# -# -# -# -# -# Corrector for aberrations in an electron microscope. -# -# Different technology partners use different naming schemes and models -# for quantifying the aberration coefficients. -# -# The corrector in an electron microscope is composed of multiple lenses and -# multipole stigmators with vendor-specific details which are often undisclosed. -# -# -# -# Was the corrector used? -# -# -# -# -# Given name/alias. -# -# -# -# -# -# Ideally, a (globally) unique persistent identifier, link, -# or text to a resource which gives further details. If this does not exist -# a free-text field to report further details about the corrector. -# -# -# -# -# -# Specific information about the concrete alignment procedure which is a -# process during which the corrector is configured to enable a calibrated -# usage of the microscope. -# -# -# -# Discouraged free-text field to add further details about the alignment -# procedure. -# -# -# -# -# The outer tilt angle of the beam in tableau aquisition. -# -# -# -# -# The exposure time of the single tilt images. -# -# -# -# -# The factor of enlargement of the apparent size, -# not physical size, of an object. -# -# -# -# -# Place for storing measured or estimated aberrations (for each image or final). -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml new file mode 100644 index 0000000000..796ac83d3c --- /dev/null +++ b/contributed_definitions/nyaml/NXcrystal_structure.yaml @@ -0,0 +1,178 @@ +category: base +doc: | + Base class to describe the atomic crystal structure of a phase. + + This base class contains key metadata that are relevant parameter to every + physics-based model to simulate radiation matter interaction. + + Examples where such base class is useful are kinematic or dynamic + diffraction simulations of e.g. (Kikuchi or other type of) patterns. +# The actual indexing of Kikuchi patterns may use different algorithms. +# Such are used within different workflows where simulated and measured +# Kikuchi pattern are compared to rate which phase and orientation is the most +# likely candidate describing the pattern measured at that each scan point +# respectively. If this evaluation yields scan points without any solutions, +# these are represented using the null-phase model phase0, aka n/a aka notIndexed. +# Traditionally, Hough transformation-based indexing has been the most frequently +# used algorithm. Dictionary-based alternatives are emerging. +symbols: + n_hkl: | + Number of reflectors (Miller crystallographic plane triplets). + n_pos: | + Number of atom positions. + d: | + Dimensionality of the lattice. +type: group +NXcrystal_structure(NXobject): + \@depends_on(NX_CHAR): + doc: | + Detail in which reference frame the unit cell is defined. + dimensionality(NX_POSINT): + doc: | + Dimensionality of the lattice. + enumeration: [1, 2, 3] + reference(NXidentifier): + doc: | + Reference to another resource that was used for + instantiating this structure model. + a_b_c(NX_NUMBER): + doc: | + Crystallography unit cell parameters a, b, and c. + unit: NX_LENGTH + dim: (d,) + # defined using which convention? + alpha_beta_gamma(NX_NUMBER): + doc: | + Crystallography unit cell parameters alpha, beta, and gamma. + unit: NX_ANGLE + dim: (d,) + area(NX_NUMBER): + doc: | + Area of the unit cell considering that d = 2. + unit: NX_AREA + volume(NX_NUMBER): + doc: | + Volume of the unit cell considering that d = 3. + unit: NX_VOLUME + crystal_system(NX_CHAR): + doc: | + Crystal system + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + # 2d + laue_group(NX_CHAR): + doc: | + Laue group using International Table of Crystallography Notation. + # add enumeration of all possible + point_group(NX_CHAR): + doc: | + Point group using International Table of Crystallography Notation. + # add enumeration all possible + # 3d + space_group(NX_CHAR): + doc: | + Space group from the International Table of Crystallography Notation. + # add enumeration of all possible + is_centrosymmetric(NX_BOOLEAN): + doc: | + True if space group is considered a centrosymmetric one. + False if space group is considered a non-centrosymmetric one. + Centrosymmetric has all types and combinations of symmetry elements + (translation, rotational axis, mirror planes, center of inversion) + Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). + Chiral compared to non-centrosymmetric is constrained (no mirror planes). + is_chiral(NX_BOOLEAN): + doc: | + True if space group is considered a chiral one. + False if space group is consider a non-chiral one. + phase_identifier(NX_INT): + doc: | + Identifier for each phase. + + The value 0 is reserved for the unknown phase that represents the + null-model no sufficiently significant confirmation. In other words, + the phase_name is n/a, notIndexed. + + The phase identifier value has to match with the integer postfix of the + group name which represents that instance in a NeXus/HDF5 file, i.e. + if two phases were used e.g. 0 and 1, two instances of an + :ref:`NXcrystal_structure` named phase0 and phase1 + should be stored in the HDF5 file. + unit: NX_UNITLESS + # \@depends_on(NX_CHAR): + # doc: | + # Refers to the specific identifier_offset to consider. + # + # If not provided assume identifier_offset is 0. + phase_name(NX_CHAR): + doc: | + Name of the phase/alias. + + If the phase_identifier is 0 and one would like to use the field + phase_name the value should be n/a. + atom_identifier(NX_CHAR): + doc: | + Label for each atom position. + dim: (n_pos,) + atom_type(NX_UINT): + doc: | + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) `_ + unit: NX_UNITLESS + dim: (n_pos,) + # atom_position(NXcg_point_set): + atom_position(NX_NUMBER): + doc: | + Atom positions. + dim: (n_pos, d) + unit: NX_ANY + \@depends_on(NX_CHAR): + doc: | + Reference to an instance of :ref:`NXcoordinate_system` + whereby the positions can be resolved. + # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory + # to describe the simulated Kikuchi pattern generated from such a model + atom_occupancy(NX_NUMBER): + doc: | + Relative occupancy of the atom position. + unit: NX_DIMENSIONLESS + dim: (n_pos,) + number_of_planes(NX_UINT): + doc: | + How many reflectors are distinguished. + + Value has to match value for symbol n_hkl. + unit: NX_UNITLESS + # Miller indices :math:`(hkl)[uvw]`. + miller(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Miller indices :math:`(hkl)[uvw]` of the planes. + + The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. + Miller indices refer to the Cartesian right-handed coordinate system + of the unit cell. + dim: (n_hkl, 6) + dspacing(NX_NUMBER): + doc: | + Spacing between crystallographic planes as defined by field miller. + unit: NX_LENGTH + dim: (n_hkl,) + relative_intensity(NX_NUMBER): + doc: | + Relative intensity of the signal for the plane. + unit: NX_DIMENSIONLESS + dim: (n_hkl,) + number_of_scan_points(NX_UINT): + doc: | + In case the :ref:`NXcrystal_structure` base class is used + with analyzed orientation maps this field stores how many scan points + of the map were identified as that phase. + unit: NX_UNITLESS + ipfID(NXms_ipf): + pfID(NXms_pf): + odfID(NXms_odf): +# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) +# can give some good suggestions on how to improve and ideally make even +# more general this section diff --git a/contributed_definitions/nyaml/NXcs_computer.yaml b/contributed_definitions/nyaml/NXcs_computer.yaml index 21e3b37b9b..01cf37da32 100644 --- a/contributed_definitions/nyaml/NXcs_computer.yaml +++ b/contributed_definitions/nyaml/NXcs_computer.yaml @@ -6,10 +6,10 @@ symbols: The symbols used in the schema to specify e.g. dimensions of arrays. type: group NXcs_computer(NXobject): - name: + name(NX_CHAR): doc: | Given name/alias to the computing system, e.g. MyDesktop. - operating_system: + operating_system(NX_CHAR): doc: | Name of the operating system, e.g. Windows, Linux, Mac, Android. \@version: @@ -19,106 +19,21 @@ NXcs_computer(NXobject): instructions can be found so that the program can be configured in such a manner that the result file is ideally recreatable yielding the same results. - # difference e.g. in Win11 between hardware ID, UUID, and device ID - uuid: + uuid(NX_CHAR): doc: | Ideally a (globally) unique persistent identifier of the computer, i.e. the Universally Unique Identifier (UUID) of the computing node. - # when it comes to performance monitoring - (NXcs_cpu): + (NXcs_cpu_sys): doc: | - A list of physical processing units (can be multi-core chips). - (NXcs_gpu): + Details about (classical) processing units (CPUs) or a system thereof. + (NXcs_gpu_sys): doc: | - A list of physical coprocessor/graphic cards/accelerator units. + Details about coprocessor/graphic cards/accelerator units or a system thereof. (NXcs_mm_sys): doc: | Details about the memory sub-system. (NXcs_io_sys): doc: | Details about the I/O sub-system. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# beec5bb34324307ff1f1b659caccb0bbf28e67f8280065b68a948bd7e0dc795b -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Computer science description of a set of computing nodes. -# -# -# -# Given name/alias to the computing system, e.g. MyDesktop. -# -# -# -# -# Name of the operating system, e.g. Windows, Linux, Mac, Android. -# -# -# -# Version plus build number, commit hash, or description of an ever -# persistent resource where the source code of the program and build -# instructions can be found so that the program can be configured in -# such a manner that the result file is ideally recreatable yielding -# the same results. -# -# -# -# -# -# -# Ideally a (globally) unique persistent identifier of the computer, i.e. -# the Universally Unique Identifier (UUID) of the computing node. -# -# -# -# -# -# A list of physical processing units (can be multi-core chips). -# -# -# -# -# A list of physical coprocessor/graphic cards/accelerator units. -# -# -# -# -# Details about the memory sub-system. -# -# -# -# -# Details about the I/O sub-system. -# -# -# diff --git a/contributed_definitions/nyaml/NXcs_cpu_obj.yaml b/contributed_definitions/nyaml/NXcs_cpu_obj.yaml new file mode 100644 index 0000000000..73097d5ca5 --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_cpu_obj.yaml @@ -0,0 +1,12 @@ +category: base +doc: | + Computer science description of a (central) processing unit (C)PU of a computer. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXcs_cpu_obj(NXobject): + name(NX_CHAR): + doc: | + Given name of the CPU. Users should be as specific as possible. + (NXfabrication): diff --git a/contributed_definitions/nyaml/NXcs_cpu_sys.yaml b/contributed_definitions/nyaml/NXcs_cpu_sys.yaml new file mode 100644 index 0000000000..5eaf8f0eab --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_cpu_sys.yaml @@ -0,0 +1,21 @@ +category: base +doc: | + Computer science description of a system of classical central processing units. + + For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXcs_cpu_sys(NXobject): + cpuID(NXcs_cpu_obj): + doc: | + Granularizing at the socket level. + + Typical examples follow: A desktop computer with a single CPU one + could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of + :ref:`NXcs_cpu_sys`. + A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` + inside one instance of :ref:`NXcs_cpu_sys`. + A server with two dual-socket server nodes one could describe + with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. diff --git a/contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml b/contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml index 8a2df5e7e5..f6ed55a5a4 100644 --- a/contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml +++ b/contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml @@ -2,30 +2,32 @@ category: base doc: | Computer science base class for packing and unpacking booleans. - One use case is processing of object sets (like point cloud data). - When one applies e.g. a spatial filter to a set of points to define which - points are analyzed and which not, it is useful to document which points were - taken. One can store this information in a compact manner with an array of - boolean values. If the value is True the point is taken, else it is not. + This base class bookkeeps metadata to inform software about necessary modulo + operations to decode e.g. set membership of objects in sets which are encoded + as a packed array of boolean values. - If the points are identified by an array of integer identifiers and an - arbitrary spatial filtering, the boolean array will be filled with True and False - values in an arbitrary manner. Especially when the number of points is large, - for instance several thousands and more, some situations can be more efficiently - stored if one would not store the boolean array but just list the identifiers - of the points taken. For instance if within a set of 1000 points only one point is - taken, it would take (naively) 4000 bits to store the array but only 32 bits - to store e.g. the ID of that taken point. Of course the 4000 bit field is so + One use case is processing of object sets (point cloud data). When one applies + e.g. a spatial filter to a set of points to define which points are analyzed + and which not, one can store this information in a compact manner using an array + of boolean values. If the value is True the point is taken, otherwise the point + is not taken. + + The resulting boolean array will be filled with True and False in a manner + that is often arbitrary and in general case-dependent. + + Especially when the number of points is large, for instance several thousands + or more, some situations can be more efficiently stored if one would not store + the boolean array but just list the identifiers of the points taken. + + For example, if within a set of 1000 points only one point is taken, it would + take (naively) 4000 bits to store the array but only 32 bits to store e.g. the + ID of the single point that is taken. Of course the 4000 bit field is so sparse that it could be compressed resulting also in a substantial reduction - of the storage demands. Therefore boolean masks are useful compact descriptions - to store information about set memberships in a compact manner. - In general it is true, though, that which representation is best, i.e. - most compact (especially when compressed) depends strongly on occupation of - the array. + of the storage demands. Therefore, boolean masks are useful in that + they store compact representation of set memberships. - This base class just bookkeeps metadata to inform software about necessary - modulo operations to decode the set membership of each object. This is useful - because the number of objects not necessarily is an integer multiple of the bit depth. + The number of encoded pieces of information is not necessarily + an integer multiple of the bit depth. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -37,136 +39,32 @@ symbols: Length of mask considering the eventual need for padding. type: group NXcs_filter_boolean_mask(NXobject): - number_of_objects(NX_UINT): - unit: NX_UNITLESS + \@depends_on(NX_CHAR): + doc: | + Possibility to refer to which set this mask applies. + + If depends_on is not provided, it is assumed that the mask + applies to its direct parent. + number_of_objects(NX_INT): doc: | Number of objects represented by the mask. - bitdepth(NX_UINT): unit: NX_UNITLESS + bitdepth(NX_INT): doc: | Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - mask(NX_UINT): + (e.g. 8 bits for a C-style uint8). unit: NX_UNITLESS + mask(NX_UINT): doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits have to be set to 0. - dimensions: - rank: 1 - dim: [[1, n_total]] - identifier(NX_UINT): + The content of the mask. If padding is used, padding bits have to be set to 0. + dim: (n_total,) + unit: NX_UNITLESS + identifier(NX_INT): doc: | Link to/or array of identifiers for the objects. The decoded mask is interpreted consecutively, i.e. the first bit in the mask matches to the first identifier, the second bit in the mask to the second - identifier and so on and so forth. - dimensions: - rank: 1 - dim: [[1, n_object]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 1ec0c27c39c4e904f1d117f958a1fa5c4d70795c7eb7d0579bf2268728651b4a -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of entries (e.g. number of points or objects). -# -# -# -# -# Number of bits assumed for the container datatype used. -# -# -# -# -# Length of mask considering the eventual need for padding. -# -# -# -# -# Computer science base class for packing and unpacking booleans. -# -# One use case is processing of object sets (like point cloud data). -# When one applies e.g. a spatial filter to a set of points to define which -# points are analyzed and which not, it is useful to document which points were -# taken. One can store this information in a compact manner with an array of -# boolean values. If the value is True the point is taken, else it is not. -# -# If the points are identified by an array of integer identifiers and an -# arbitrary spatial filtering, the boolean array will be filled with True and False -# values in an arbitrary manner. Especially when the number of points is large, -# for instance several thousands and more, some situations can be more efficiently -# stored if one would not store the boolean array but just list the identifiers -# of the points taken. For instance if within a set of 1000 points only one point is -# taken, it would take (naively) 4000 bits to store the array but only 32 bits -# to store e.g. the ID of that taken point. Of course the 4000 bit field is so -# sparse that it could be compressed resulting also in a substantial reduction -# of the storage demands. Therefore boolean masks are useful compact descriptions -# to store information about set memberships in a compact manner. -# In general it is true, though, that which representation is best, i.e. -# most compact (especially when compressed) depends strongly on occupation of -# the array. -# -# This base class just bookkeeps metadata to inform software about necessary -# modulo operations to decode the set membership of each object. This is useful -# because the number of objects not necessarily is an integer multiple of the bit depth. -# -# -# -# Number of objects represented by the mask. -# -# -# -# -# Number of bits assumed matching on a default datatype. -# (e.g. 8 bits for a C-style uint8). -# -# -# -# -# The unsigned integer array representing the content of the mask. -# If padding is used the padded bits have to be set to 0. -# -# -# -# -# -# -# -# Link to/or array of identifiers for the objects. The decoded mask is -# interpreted consecutively, i.e. the first bit in the mask matches -# to the first identifier, the second bit in the mask to the second -# identifier and so on and so forth. -# -# -# -# -# -# + identifier and so on and so forth. Resolving of identifier follows + the conventions made for depends_on, so consult the also its description. + unit: NX_UNITLESS + dim: (n_object,) diff --git a/contributed_definitions/nyaml/NXcs_gpu_obj.yaml b/contributed_definitions/nyaml/NXcs_gpu_obj.yaml new file mode 100644 index 0000000000..04468b7b2b --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_gpu_obj.yaml @@ -0,0 +1,12 @@ +category: base +doc: | + Computer science description of a graphic processing unit (GPU) of a computer. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXcs_gpu_obj(NXobject): # NXcircuit_board ? + name(NX_CHAR): + doc: | + Given name of the GPU. Users should be as specific as possible. + (NXfabrication): diff --git a/contributed_definitions/nyaml/NXcs_gpu_sys.yaml b/contributed_definitions/nyaml/NXcs_gpu_sys.yaml new file mode 100644 index 0000000000..dee199330c --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_gpu_sys.yaml @@ -0,0 +1,20 @@ +category: base +doc: | + Computer science description of a system of coprocessor or graphics processors. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXcs_gpu_sys(NXobject): + gpuID(NXcs_gpu_obj): + doc: | + Granularizing at the socket level. + + Typical examples follow: A desktop computer with a single GPU one + could describe using one instance of :ref:`NXcs_gpu_obj` inside one instance of + :ref:`NXcs_gpu_sys`. + A desktop computer with two GPUs one could describe using two instances + of :ref:`NXcs_gpu_obj` inside one instance of :ref:`NXcs_gpu_sys`. + A GPU server like nowadays used for artificial intelligence + one could describe as a system with n instances of :ref:`NXcs_gpu_obj` + in one :ref:`NXcs_gpu_sys` or :ref:`NXcs_cpu_sys`. diff --git a/contributed_definitions/nyaml/NXcs_io_obj.yaml b/contributed_definitions/nyaml/NXcs_io_obj.yaml index 1fd6b1376a..100f0cae41 100644 --- a/contributed_definitions/nyaml/NXcs_io_obj.yaml +++ b/contributed_definitions/nyaml/NXcs_io_obj.yaml @@ -6,77 +6,16 @@ symbols: The symbols used in the schema to specify e.g. dimensions of arrays. type: group NXcs_io_obj(NXobject): - technology: + technology(NX_CHAR): doc: | Qualifier for the type of storage medium used. enumeration: [solid_state_disk, hard_disk, tape] - - # recording technique etc. max_physical_capacity(NX_NUMBER): doc: | Total amount of data which the medium can hold. - - # unit: NX_BIT - name: + unit: NX_ANY + # NX_BIT + name(NX_CHAR): doc: | Given name to the I/O unit. (NXfabrication): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d04482bdb2e7dae35847392cb0040f9cbf17c7539a18bbdb8e74abd68d1b9bac -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Computer science description of a storage object in an input/output system. -# -# -# -# Qualifier for the type of storage medium used. -# -# -# -# -# -# -# -# -# -# -# Total amount of data which the medium can hold. -# -# -# -# -# -# Given name to the I/O unit. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcs_io_sys.yaml b/contributed_definitions/nyaml/NXcs_io_sys.yaml index 46a0989d11..b62768a234 100644 --- a/contributed_definitions/nyaml/NXcs_io_sys.yaml +++ b/contributed_definitions/nyaml/NXcs_io_sys.yaml @@ -1,46 +1,13 @@ category: base doc: | Computer science description of system of a computer. + + In the same way how a hierarchy of instances of :ref:`NXcs_cpu_obj` or :ref:`NXcs_gpu_obj` + can be defined one can also define a hierarchy of :ref:`NXcs_mm_obj` and :ref:`NXcs_io_obj` + instances. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. type: group NXcs_io_sys(NXobject): - (NXcs_io_obj): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4eb7454d7630187a5e90178a64ced543987d62f60368344c81c3ef8652f77f2c -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Computer science description of system of a computer. -# -# -# + ioID(NXcs_io_obj): diff --git a/contributed_definitions/nyaml/NXcs_mm_obj.yaml b/contributed_definitions/nyaml/NXcs_mm_obj.yaml new file mode 100644 index 0000000000..d1fead8c8b --- /dev/null +++ b/contributed_definitions/nyaml/NXcs_mm_obj.yaml @@ -0,0 +1,21 @@ +category: base +doc: | + Computer science description of a memory in a memory system. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXcs_mm_obj(NXobject): + technology(NX_CHAR): + doc: | + Qualifier for the type of random access memory. + # make an enumeration + max_physical_capacity(NX_NUMBER): + doc: | + Total amount of data which the medium can hold. + unit: NX_ANY + # NX_BIT + name(NX_CHAR): + doc: | + Given name to the I/O unit. + (NXfabrication): diff --git a/contributed_definitions/nyaml/NXcs_mm_sys.yaml b/contributed_definitions/nyaml/NXcs_mm_sys.yaml index 376a8ffbf9..60293e362b 100644 --- a/contributed_definitions/nyaml/NXcs_mm_sys.yaml +++ b/contributed_definitions/nyaml/NXcs_mm_sys.yaml @@ -1,6 +1,10 @@ category: base doc: | - Computer science description of a main memory system of a computer. + Computer science description of a memory system of a computer. + + In the same way how a hierarchy of instances of :ref:`NXcs_cpu_obj` or :ref:`NXcs_gpu_obj` + can be defined one can also define a hierarchy of :ref:`NXcs_mm_obj` and :ref:`NXcs_io_obj` + instances. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -9,47 +13,5 @@ NXcs_mm_sys(NXobject): total_physical_memory(NX_NUMBER): doc: | How much physical memory does the system provide. - - # unit: NX_BIT - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 3121e939a6f8764585bdda1ee024eddf80bf37d885af6ee8f5ce1a7d04d791ef -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Computer science description of a main memory system of a computer. -# -# -# -# How much physical memory does the system provide. -# -# -# -# + unit: NX_ANY + # NX_BIT diff --git a/contributed_definitions/nyaml/NXcs_prng.yaml b/contributed_definitions/nyaml/NXcs_prng.yaml index 8e5a642638..114574f691 100644 --- a/contributed_definitions/nyaml/NXcs_prng.yaml +++ b/contributed_definitions/nyaml/NXcs_prng.yaml @@ -2,136 +2,46 @@ category: base doc: | Computer science description of pseudo-random number generator. - The purpose of such metadata is to identify if exactly the same sequence + The purpose of this base class is to identify if exactly the same sequence can be reproduced, like for a PRNG or not (for a true physically random source). symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. type: group NXcs_prng(NXobject): - type: + type(NX_CHAR): doc: | + Physical approach or algorithm whereby random numbers are generated. + Different approaches for generating random numbers with a computer exists. - Some use a dedicated physical device where the state is unpredictable (physically). - Some use a mangling of the system clock (system_clock), where also without - additional pieces of information the sequence is not reproducible. - Some use so-called pseudo-random number generator (PRNG) are used. - These are algorithms which yield a deterministic sequence of practically - randomly appearing numbers. These algorithms different in their quality in - how close the resulting sequences are random. - Nowadays one of the most commonly used algorithm is - the MersenneTwister (mt19937). + Some use a dedicated physical device whose the state is unpredictable + (physically). Some use a strategy of mangling information from the system + clock. Also in this case the sequence is not reproducible without having + additional pieces of information. + + In most cases though so-called pseudo-random number generator (PRNG) + algorithms are used. These yield a deterministic sequence of practically + randomly appearing numbers. These algorithms differ in their quality in + how close the resulting sequences are random, i.e. sequentially + uncorrelated. Nowadays one of the most commonly used algorithm is the + MersenneTwister (mt19937). enumeration: [physical, system_clock, mt19937, other] - program: + (NXprogram): doc: | Name of the PRNG implementation and version. If such information is not available or if the PRNG type was set to other the DOI to the publication or the source code should be given. - \@version: - doc: | - Version and build number, or commit hash. - seed(NX_NUMBER): - unit: NX_UNITLESS + seed(NX_INT): doc: | - Parameter of the PRNG controlling its initialization and thus the specific - sequence of numbers it generates. - - # reformulate last part of the first sentence. - warmup(NX_NUMBER): + Parameter of the PRNG controlling its initialization + and thus controlling the specific sequence generated. unit: NX_UNITLESS + warmup(NX_UINT): doc: | - Number of initial draws from the PRNG which are discarded in an effort - to equilibrate the sequence and make it thus to statistically more random. - If no warmup was performed or if warmup procedures are unclear, + Number of initial draws from the PRNG after its initialized with the seed. + These initial draws are typically discarded in an effort to equilibrate the + sequence. If no warmup was performed or if warmup procedures are unclear, users should set the value to zero. - + unit: NX_UNITLESS # one could add spectral properties but this is usually well documented in the PRNG literature # one could also think about making reference to the NIST PRNG test suite to qualify the PRNG - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 01b28e5d73597c33b6d795d41b35d3b1c4f07caaa3fc58b784789f7f04a59a77 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Computer science description of pseudo-random number generator. -# -# The purpose of such metadata is to identify if exactly the same sequence -# can be reproduced, like for a PRNG or not (for a true physically random source). -# -# -# -# Different approaches for generating random numbers with a computer exists. -# Some use a dedicated physical device where the state is unpredictable (physically). -# Some use a mangling of the system clock (system_clock), where also without -# additional pieces of information the sequence is not reproducible. -# Some use so-called pseudo-random number generator (PRNG) are used. -# These are algorithms which yield a deterministic sequence of practically -# randomly appearing numbers. These algorithms different in their quality in -# how close the resulting sequences are random. -# Nowadays one of the most commonly used algorithm is -# the MersenneTwister (mt19937). -# -# -# -# -# -# -# -# -# -# -# Name of the PRNG implementation and version. If such information is not -# available or if the PRNG type was set to other the DOI to the publication -# or the source code should be given. -# -# -# -# Version and build number, or commit hash. -# -# -# -# -# -# Parameter of the PRNG controlling its initialization and thus the specific -# sequence of numbers it generates. -# -# -# -# -# -# Number of initial draws from the PRNG which are discarded in an effort -# to equilibrate the sequence and make it thus to statistically more random. -# If no warmup was performed or if warmup procedures are unclear, -# users should set the value to zero. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcs_profiling.yaml b/contributed_definitions/nyaml/NXcs_profiling.yaml index 2b869d4a37..cc41151e96 100644 --- a/contributed_definitions/nyaml/NXcs_profiling.yaml +++ b/contributed_definitions/nyaml/NXcs_profiling.yaml @@ -1,6 +1,6 @@ category: base doc: | - Computer science description for summary performance/profiling data of an application. + Computer science description for performance and profiling data of an application. Performance monitoring and benchmarking of software is a task where questions can be asked at various levels of detail. In general, there are three main @@ -10,27 +10,28 @@ doc: | * Software configuration and capabilities * Dynamic effects of the system in operation and the system working together with eventually multiple computers, especially when these have to exchange - information across a network. + information across a network and these are used usually by multiple users. At the most basic level users may wish to document how long e.g. a data - analysis with a scientific software (app). - A frequent idea is here to judge how critical the effect is on the workflow - of the scientists, i.e. is the analysis possible in a few seconds or would it - take days if I were to run this analysis on a comparable machine. In this case, - mainly the order of magnitude is relevant, as well as how this can be achieved - with using parallelization (i.e. reporting the number of CPU and GPU resources - used, the number of processes and/or threads, and basic details about the - computing node/computer. + analysis with a scientific software (app) took. + A frequent idea is here to answer practical questions like how critical is the + effect on the workflow of the scientists, i.e. is the analysis possible in + a few seconds or would it take days if I were to run this analysis on a + comparable machine? + For this more qualitative performance monitoring, mainly the order of + magnitude is relevant, as well as how this was achieved using parallelization + (i.e. reporting the number of CPU and GPU resources used, the number of + processes and threads configured, and providing basic details about the computer). At more advanced levels benchmarks may go as deep as detailed temporal tracking of individual processor instructions, their relation to other instructions, the - state of call stacks, in short eventually the entire app execution history + state of call stacks; in short eventually the entire app execution history and hardware state history. Such analyses are mainly used for performance - optimization as well as for tracking bugs and other development purposes. - Specialized software exists which documents such performance data in - specifically-formatted event log files or databases. + optimization, i.e. by software and hardware developers as well as for + tracking bugs. Specialized software exists which documents such performance + data in specifically-formatted event log files or databases. - This base class cannot and should not replace these specific solutions. + This base class cannot and should not replace these specific solutions for now. Instead, the intention of the base class is to serve scientists at the basic level to enable simple monitoring of performance data and log profiling data of key algorithmic steps or parts of computational workflows, so that @@ -45,12 +46,11 @@ symbols: The symbols used in the schema to specify e.g. dimensions of arrays. type: group NXcs_profiling(NXobject): - # details about queuing systems etc - current_working_directory: + current_working_directory(NX_CHAR): doc: | Path to the directory from which the tool was called. - command_line_call: + command_line_call(NX_CHAR): doc: | Command line call with arguments if applicable. start_time(NX_DATE_TIME): @@ -67,36 +67,34 @@ NXcs_profiling(NXobject): Wall-clock time how long the app execution took. This may be in principle end_time minus start_time; however usage of eventually more precise timers may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. - number_of_processes(NX_POSINT): - unit: NX_UNITLESS + and thus demands a more precise record of the wall-clock time. + number_of_processes(NX_UINT): doc: | Qualifier which specifies with how many nominal processes the app was - invoked. The main idea behind this field, for instance for app using a - Message Passing Interface parallelization is to communicate how many - processes were used. + invoked. The main idea behind this field e.g. for apps which use e.g. MPI + (Message Passing Interface) parallelization is to communicate + how many processes were used. For sequentially running apps number_of_processes and number_of_threads is 1. If the app uses exclusively GPU parallelization number_of_gpus can be larger than 1. If no GPU is used number_of_gpus is 0 even though the hardware may have GPUs installed, thus indicating these were not used though. - number_of_threads(NX_POSINT): unit: NX_UNITLESS + number_of_threads(NX_UINT): doc: | - Qualifier with how many nominal threads were accessible to the app at - runtime. Specifically here the maximum number of threads used for the + Qualifier how many nominal threads were used at runtime. + Specifically here the maximum number of threads used for the high-level threading library used (e.g. OMP_NUM_THREADS), posix. - number_of_gpus(NX_POSINT): unit: NX_UNITLESS + number_of_gpus(NX_UINT): doc: | Qualifier with how many nominal GPUs the app was invoked at runtime. - + unit: NX_UNITLESS # there are more complicated usage models, where GPUs are activated in # between runs etc, but here application definition and base class developers # should feel free to suggest customizations wrt to if and how such more # complicated models should be captured. - # how can you have an empty list? (NXcs_computer): doc: | A collection with one or more computing nodes each with own resources. @@ -106,158 +104,6 @@ NXcs_profiling(NXobject): A collection of individual profiling event data which detail e.g. how much time the app took for certain computational steps and/or how much memory was consumed during these operations. - - # how to retrieve UUID for cloud computing instances - # https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/identify_ec2_instances.html -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4f8f75e03907b18215d89efcc2968066971248a838a1b3e6d3b9727da3cbde78 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Computer science description for summary performance/profiling data of an application. -# -# Performance monitoring and benchmarking of software is a task where questions -# can be asked at various levels of detail. In general, there are three main -# contributions to performance: -# -# * Hardware capabilities and configuration -# * Software configuration and capabilities -# * Dynamic effects of the system in operation and the system working together -# with eventually multiple computers, especially when these have to exchange -# information across a network. -# -# At the most basic level users may wish to document how long e.g. a data -# analysis with a scientific software (app). -# A frequent idea is here to judge how critical the effect is on the workflow -# of the scientists, i.e. is the analysis possible in a few seconds or would it -# take days if I were to run this analysis on a comparable machine. In this case, -# mainly the order of magnitude is relevant, as well as how this can be achieved -# with using parallelization (i.e. reporting the number of CPU and GPU resources -# used, the number of processes and/or threads, and basic details about the -# computing node/computer. -# -# At more advanced levels benchmarks may go as deep as detailed temporal tracking -# of individual processor instructions, their relation to other instructions, the -# state of call stacks, in short eventually the entire app execution history -# and hardware state history. Such analyses are mainly used for performance -# optimization as well as for tracking bugs and other development purposes. -# Specialized software exists which documents such performance data in -# specifically-formatted event log files or databases. -# -# This base class cannot and should not replace these specific solutions. -# Instead, the intention of the base class is to serve scientists at the -# basic level to enable simple monitoring of performance data and log profiling -# data of key algorithmic steps or parts of computational workflows, so that -# these pieces of information can guide users which order of magnitude differences -# should be expected or not. -# -# Developers of application definitions should add additional fields and -# references to e.g. more detailed performance data to which they wish to link -# the metadata in this base class. -# -# -# -# -# Path to the directory from which the tool was called. -# -# -# -# -# Command line call with arguments if applicable. -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC information -# included when the app was started. -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC information -# included when the app terminated or crashed. -# -# -# -# -# Wall-clock time how long the app execution took. This may be in principle -# end_time minus start_time; however usage of eventually more precise timers -# may warrant to use a finer temporal discretization, -# and thus demand a more precise record of the wall-clock time. -# -# -# -# -# Qualifier which specifies with how many nominal processes the app was -# invoked. The main idea behind this field, for instance for app using a -# Message Passing Interface parallelization is to communicate how many -# processes were used. -# -# For sequentially running apps number_of_processes and number_of_threads -# is 1. If the app uses exclusively GPU parallelization number_of_gpus -# can be larger than 1. If no GPU is used number_of_gpus is 0 even though -# the hardware may have GPUs installed, thus indicating these were not -# used though. -# -# -# -# -# Qualifier with how many nominal threads were accessible to the app at -# runtime. Specifically here the maximum number of threads used for the -# high-level threading library used (e.g. OMP_NUM_THREADS), posix. -# -# -# -# -# Qualifier with how many nominal GPUs the app was invoked at runtime. -# -# -# -# -# -# A collection with one or more computing nodes each with own resources. -# This can be as simple as a laptop or the nodes of a cluster computer. -# -# -# -# -# A collection of individual profiling event data which detail e.g. how -# much time the app took for certain computational steps and/or how much -# memory was consumed during these operations. -# -# -# -# +# how to retrieve UUID for cloud computing instances +# https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/identify_ec2_instances.html diff --git a/contributed_definitions/nyaml/NXcs_profiling_event.yaml b/contributed_definitions/nyaml/NXcs_profiling_event.yaml index 6f6f7a5ab8..d92fbe68bb 100644 --- a/contributed_definitions/nyaml/NXcs_profiling_event.yaml +++ b/contributed_definitions/nyaml/NXcs_profiling_event.yaml @@ -16,138 +16,39 @@ NXcs_profiling_event(NXobject): doc: | ISO 8601 time code with local time zone offset to UTC information included when the event tracking ended. - description: + description(NX_CHAR): doc: | Free-text description what was monitored/executed during the event. elapsed_time(NX_NUMBER): - unit: NX_TIME doc: | - Wall-clock time how long the event took. This may be in principle - end_time minus start_time; however usage of eventually more precise timers - may warrant to use a finer temporal discretization, - and thus demand a more precise record of the wall-clock time. + Wall-clock time how long the event took. + + This may be in principle end_time minus start_time; however usage of + eventually more precise timers may warrant to use a finer temporal + discretization, and thus demand for a more precise record of the + wall-clock time. + Elapsed time may contain time portions where resources were idling. - number_of_processes(NX_POSINT): - unit: NX_UNITLESS + unit: NX_TIME + number_of_processes(NX_UINT): doc: | Number of processes used (max) during the execution of this event. - number_of_threads(NX_POSINT): unit: NX_UNITLESS + number_of_threads(NX_UINT): doc: | Number of threads used (max) during the execution of this event. - number_of_gpus(NX_POSINT): unit: NX_UNITLESS + number_of_gpus(NX_UINT): doc: | Number of GPUs used (max) during the execution of this event. + unit: NX_UNITLESS max_virtual_memory_snapshot(NX_NUMBER): - unit: NX_ANY doc: | Maximum amount of virtual memory allocated per process during the event. - dimensions: - rank: 1 - dim: [[1, n_processes]] + unit: NX_ANY # NX_BIT + dim: (n_processes,) max_resident_memory_snapshot(NX_NUMBER): - unit: NX_ANY doc: | Maximum amount of resident memory allocated per process during the event. - dimensions: - rank: 1 - dim: [[1, n_processes]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e8b200086f4231ee711a2a4e13cd93c016c5291518d3a255e0bb9348da3d96b1 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of processes. -# -# -# -# -# Computer science description of a profiling event. -# -# -# -# ISO 8601 time code with local time zone offset to UTC information -# included when the event tracking started. -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC information -# included when the event tracking ended. -# -# -# -# -# Free-text description what was monitored/executed during the event. -# -# -# -# -# Wall-clock time how long the event took. This may be in principle -# end_time minus start_time; however usage of eventually more precise timers -# may warrant to use a finer temporal discretization, -# and thus demand a more precise record of the wall-clock time. -# Elapsed time may contain time portions where resources were idling. -# -# -# -# -# Number of processes used (max) during the execution of this event. -# -# -# -# -# Number of threads used (max) during the execution of this event. -# -# -# -# -# Number of GPUs used (max) during the execution of this event. -# -# -# -# -# Maximum amount of virtual memory allocated per process during the event. -# -# -# -# -# -# -# -# Maximum amount of resident memory allocated per process during the event. -# -# -# -# -# -# + unit: NX_ANY # NX_BIT + dim: (n_processes,) diff --git a/contributed_definitions/nyaml/NXdeflector.yaml b/contributed_definitions/nyaml/NXdeflector.yaml index 48bbdea64f..874dee4304 100644 --- a/contributed_definitions/nyaml/NXdeflector.yaml +++ b/contributed_definitions/nyaml/NXdeflector.yaml @@ -3,141 +3,41 @@ doc: | Deflectors as they are used e.g. in an electron analyser. type: group NXdeflector(NXobject): - type: + type(NX_CHAR): doc: | - Qualitative type of deflector with respect to the number of pole pieces + Qualitative type of deflector with respect to the number of pole pieces. enumeration: [dipole, quadrupole, hexapole, octupole] - name: + name(NX_CHAR): doc: | Colloquial or short name for the deflector. For manufacturer names and identifiers use respective manufacturer fields. - manufacturer_name: + (NXfabrication): + description(NX_CHAR): # NXidentifier doc: | - Name of the manufacturer who built/constructed the deflector. - manufacturer_model: - doc: | - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the deflector. - description: - doc: | - Ideally an identifier, persistent link, or free text which gives further details - about the deflector. + Ideally an identifier, persistent link, or free text which gives + further details about the deflector. voltage(NX_NUMBER): - unit: NX_VOLTAGE doc: | - Excitation voltage of the deflector. For dipoles it is a single number. For - higher orders, it is an array. + Excitation voltage of the deflector. For dipoles it is a single number. + For higher order multipoles, it is an array. + unit: NX_VOLTAGE current(NX_NUMBER): - unit: NX_CURRENT doc: | Excitation current of the deflector. For dipoles it is a single number. For higher orders, it is an array. - depends_on(NX_CHAR): + unit: NX_CURRENT + \@depends_on(NX_CHAR): doc: | Specifies the position of the deflector by pointing to the last transformation in the transformation chain in the NXtransformations group. + # discuss NXcomponent_mpes ? (NXtransformations): doc: | Collection of axis-based translations and rotations to describe the location and geometry of the deflector as a component in the instrument. Conventions from the - NXtransformations base class are used. In principle, the McStas coordinate + :ref:`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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# cc60e5e60fa6b89b66dcf4a780b213a0001d8fba76a73032bdd0f2bdada410a7 -# -# -# -# -# -# Deflectors as they are used e.g. in an electron analyser. -# -# -# -# Qualitative type of deflector with respect to the number of pole pieces -# -# -# -# -# -# -# -# -# -# -# Colloquial or short name for the deflector. For manufacturer names and -# identifiers use respective manufacturer fields. -# -# -# -# -# Name of the manufacturer who built/constructed the deflector. -# -# -# -# -# Hardware name, hash identifier, or serial number that was given by the -# manufacturer to identify the deflector. -# -# -# -# -# Ideally an identifier, persistent link, or free text which gives further details -# about the deflector. -# -# -# -# -# Excitation voltage of the deflector. For dipoles it is a single number. For -# higher orders, it is an array. -# -# -# -# -# Excitation current of the deflector. For dipoles it is a single number. For -# higher orders, it is an array. -# -# -# -# -# Specifies the position of the deflector by pointing to the last transformation -# in the transformation chain in the NXtransformations group. -# -# -# -# -# Collection of axis-based translations and rotations to describe the location and -# geometry of the deflector as a component in the instrument. Conventions from the -# NXtransformations base class are used. In principle, the McStas coordinate -# system is used. The first transformation has to point either to another -# component of the system or . (for pointing to the reference frame) to relate it -# relative to the experimental setup. Typically, the components of a system should -# all be related relative to each other and only one component should relate to -# the reference coordinate system. -# -# -# diff --git a/contributed_definitions/nyaml/NXebeam_column.yaml b/contributed_definitions/nyaml/NXebeam_column.yaml index 4ad5912c90..141250e339 100644 --- a/contributed_definitions/nyaml/NXebeam_column.yaml +++ b/contributed_definitions/nyaml/NXebeam_column.yaml @@ -1,176 +1,60 @@ category: base doc: | - Container for components to form a controlled beam in electron microscopy. - + Base class for a set of components providing a controllable electron beam. # symbols: # doc: The symbols used in the schema to specify e.g. variables. type: group +# NXebeam_column is an NXobject instead of an NXcomponent_em to make that +# part "an electron gun" reusable in other context NXebeam_column(NXobject): + (NXchamber): (NXfabrication): electron_source(NXsource): doc: | The source which creates the electron beam. - name: + name(NX_CHAR): doc: | Given name/alias. (NXfabrication): - voltage(NX_FLOAT): - unit: NX_VOLTAGE + voltage(NX_NUMBER): doc: | Voltage relevant to compute the energy of the electrons immediately after they left the gun. - probe: + unit: NX_VOLTAGE + probe(NX_CHAR): doc: | Type of radiation. enumeration: [electron] - emitter_type: + emitter_type(NX_CHAR): doc: | Emitter type used to create the beam. If the emitter type is other, give further details in the description field. enumeration: [filament, schottky, cold_cathode_field_emitter, other] - emitter_material: + emitter_material(NX_CHAR): doc: | Material of which the emitter is build, e.g. the filament material. - #MK could be made an instance of NXsample - description: + description(NX_CHAR): # NXidentifier doc: | Ideally, a (globally) unique persistent identifier, link, or text to a resource which gives further details. - # NEW ISSUE: details about the life/up-time of the source # relevant from maintenance point of view (NXtransformations): doc: | - Affine transformation which detail the arrangement in the - microscope relative to the optical axis and beam path. + Collection of axis-based translations and rotations to describe the + location and geometry of the component in the instrument. (NXaperture_em): (NXlens_em): (NXcorrector_cs): - - # ebeam_deflector(NXscan_box_em): - (NXstage_lab): + (NXscanbox_em): (NXsensor): - doc: | - A sensor used to monitor an external or internal condition. (NXbeam): doc: | - Individual ocharacterization results for the position, shape, + Individual characterization results for the position, shape, and characteristics of the electron beam. - NXtransformations should be used to specify the location + :ref:`NXtransformations` should be used to specify the location of the position at which the beam was probed. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 57dfa98a20b124029e11cfeaa6706766b0be01360a2157da1e4a60f463330f93 -# -# -# -# -# -# -# Container for components to form a controlled beam in electron microscopy. -# -# -# -# -# The source which creates the electron beam. -# -# -# -# Given name/alias. -# -# -# -# -# -# Voltage relevant to compute the energy of the electrons -# immediately after they left the gun. -# -# -# -# -# Type of radiation. -# -# -# -# -# -# -# -# Emitter type used to create the beam. -# -# If the emitter type is other, give further details -# in the description field. -# -# -# -# -# -# -# -# -# -# -# Material of which the emitter is build, e.g. the filament material. -# -# -# -# -# -# Ideally, a (globally) unique persistent identifier, link, -# or text to a resource which gives further details. -# -# -# -# -# -# Affine transformation which detail the arrangement in the -# microscope relative to the optical axis and beam path. -# -# -# -# -# -# -# -# -# -# -# A sensor used to monitor an external or internal condition. -# -# -# -# -# Individual ocharacterization results for the position, shape, -# and characteristics of the electron beam. -# -# NXtransformations should be used to specify the location -# of the position at which the beam was probed. -# -# -# diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index b3b53b5cb9..7ce0b9b4d9 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -1,4659 +1,384 @@ category: application doc: | - Characterization of a sample during a session on an electron microscope. - - **The idea and aim of NXem**: - Electron microscopy (EM) research, whether it be performed with scanning electron - microscope (SEM) or transmission electron microscope (TEM) instruments, uses - versatile tools for preparing and characterizing samples and specimens. - The term specimen is considered a synonym for sample in this application definition. - A specimen is a physical portion of material that is studied/characterized during - the microscope session, eventually in different places on the specimen surface, - illuminating the surface layers or shining through thin specimens. - These places are named regions of interest (ROIs). - - Fundamentally, an electron microscope is an electron accelerator. - Experimentalists use it in sessions during which they characterize as well as - prepare specimens. This application definition describes data and metadata about - processes and characterization tasks applied to one specimen. - The application definition focuses on the usage of EM in materials research. - The application definition design makes it in principle applicable also in - cryo-EM on biomaterials. - - Multiple specimens have to be described with multiple :ref:`NXentry` instances. - - **Electron microscopes motivate the development of an embracing data schema:** - There are research groups who use an EM in a manner where it is exclusively - operated by a single, instrument-responsible scientists or a team of scientists. - These users may perform analyses for other users as a service task, especially - in large research facility settings. Oftentimes, though, and especially for - cutting-edge instruments, the scientists guide the process maybe even control - the microscope. Instruments are usually controlled on-premises but also more - and more functionalities for remote control have become available. - Scientists oftentimes can ask technicians for support. In all cases, - these people are considered users. Users might have different - roles though. - - The rational behind a common EM schema rather than making separate schemas - for SEM or TEM are primarily the key similarities of SEM and TEM - instruments: - - Both type of instruments have electro-magnetic lenses. These may differ in - design, alignment, number, and level of corrected for aberrations. - As an obvious difference, a TEM is mainly used for measuring the transmitted - electron beam. This calls for using a different lens setup and relative - placement of the specimen in the lens setup. Also TEM specimens are - substantially thinner than specimens characterized with SEM to enable an - illumination through the specimen. This offers capabilities for probing of - additional physical mechanisms of electron-matter interaction which are - unavailable in SEMs. - - Nevertheless, both types of electron microscopes use detector systems which - measure different types of signals that originate from the same set of - radiation/specimen interactions. Often these detectors have a similar design - and technology or are even used both in SEMs and TEMs. - - **An embracing schema instead of specific SEM or TEM schemas**: - Given these physical and technical differences, different instruments have - been developed. This led to a coexistence of two broad interacting - communities: SEM and TEM users. From a data science perspective, we - acknowledge that the more specific a research question is and the narrower it - is the addressed circle of users which develops or uses schemas for research - data management (RDM) with EM, the more understandable it is that scientists - of either community (or sub-community) ask for designing method-specific schemas. - - Researchers who have a single (main) microscope of some vendor in their lab, - may argue they need an NXem_vendor_name schema or an NXem_microscope_name or - an NXem_sem or a NXem_tem schema. - Scientists exclusively working with one technique or type of signal probed - (X-rays, electrons) may argue they wish to be pragmatic and store only - what is immediately relevant for their particular technique and - research questions. In effect, they may advocate for method-specific - schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. - - However, the history of electron microscopy has shown that these activities led - to a zoo of schemas and especially vocabulary in use with implementations of these - into many data and file formats. There is nothing which prevents the communities - to make these schemas open and interoperable. Open here means not that all - data stored according to such schemas have to end up in the open-source domain. - There can be embargo periods first of all. - - Open means that the metadata and associated schemata are documented in a manner - that as many details are open as possible in the sense that others can understand - what the (meta)data mean conceptually. Instead of trying of maintain a zoo - of eventually difficult to make interoperable formats and schema we would like - to advocate that the `FAIR principles `_ - should guide all decisions how data and metadata should be stored. - - EM instruments, software, and research are moving targets. Consequently, - there is a key challenge and inconvenience with having many different schemas - with associated representations of data and metadata: Each combination of - schemas or an interoperable-made handshake between two file formats or software - packages has to be maintained by software developers. This counts especially - when data should be processed interoperably between software packages. - - This brings two problems: Many software tools and parsers for the handshaking - between tools have to be maintained. This can result in usage of different - terminology, which in turn results in representations and connections made - between different data representations and workflows that are not - machine-actionable. - `There are community efforts to harmonize the terminology. `_ - - **The advantage of working towards a common vocabulary and representation**: - A common vocabulary can serve interoperability as developers of schemas and - scientists can reuse for instance these terms, thus supporting interoperability. - Ideally, scientists specialize an application definition only for the few very - specific additional quantities of their instruments and techniques. This is - better than reimplementing the wheel for descriptions of EM instruments. - This route of more standardization can support the EM community in that it - removes the necessity for having to maintain a very large number of schemas. - - Aiming for more standardization, i.e. a lower number of schemas rather than - a single standard for electron microscopy is a compromise that can serve - academia and industry as it enables a focusing of software development - efforts on those schemas, on fixing and discussing them, and on harmonizing - their common vocabulary. These activities can be specifically relevant also - for technology partners building EM hard- and software as it improves the - longevity of certain schemas; and thus can help with incentivizing them to support - the community with implementing support for such schemas into their applications. - - In effect, everybody can gain from this as it will likely reduce the cases - in which scientists have to fix bugs in making their own tools compliant and - interoperable with tools of their colleagues and the wider community. - - The here proposed NXem application definition offers modular components - (EM-research specific base classes) for defining schemas for EM research. - Thereby, NXem can be useful to extends top-level ontologies towards a domain- - and method-specific ontology for electron microscopy as it is used for - materials research. - - Working towards a common vocabulary is a community activity that profits from - everybody reflecting in detail whether certain terms they have used in the past - are not eventually conceptually similar if not the same as what this application - definition and its base classes provide. We are happy for receiving your feedback. - - **Addressing the generality versus specificity challenge**: - It is noteworthy to understand that (not only for NeXus), schemas differ - already if at least one field is required in one version of the schema, - but it is set optional in another schema. If group(s), field(s), or - attributes are removed or added, or even a docstring is changed, schemas can - become inconsistent. It is noteworthy to mention that the idea of a NeXus application - definition serves as a contract between a data provider and a data consumer. - Providers can be the software of a specific microscopes or users with specific - analysis needs. Consumers can be again specific software tools, like vendor - software for controlling the instrument or a scientific software for doing - artificial intelligence analyses on EM data). Such changes of a schema lead - to new versions. Strictly speaking an application definition can only be - fully general if it does not make a single entry required, in which case however - it would also not offer much value as even empty datasets would be compliant - with such a schema. - - **Verification of constraints and conditions**: - Tools like NeXus so far do not avoid or protect against all such possible - inconsistencies; however NeXus offers a mechanism and toolset, through which - schemas can be documented and defined. In effect, having an openly documented - (at a case-specific level of technical detail) schema is a necessary but alone - not a sufficient step to take EM research on a route of machine-actionable - and interoperable FAIR data. - - This stresses again the fundamental and necessary role of working towards - a common vocabulary and, with a longer perspective in mind, a machine-actionable - knowledge representation and verification engine. So far many conditions and - requirements are formulated in the docstrings of the respective entries of - the application definition. - - **NXem takes a key step towards standardization of EM data schemas**. - It offers a controlled vocabulary and set of relations between concepts and - enables the description of the data which are collected for research with - electron microscopes. To be most efficient and offering reusability, the NXem - application definition should be understood as a template that one should - ideally use as is. NXem can be considered a base for designing more specialized - definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). - - **The use of NXem should be as follows:** - Offspring application definitions should not remove groups but leave these - optional or, even better, propose changes to NXem. - - A particular challenge with electron microscopes as physical instruments are - their dynamics. To make EM data understandable, repeatable, and eventually - corresponding experiments reproducible in general requires a documentation - of the spatio-temporal dynamics of the instrument in its environment. - It is questionable to which level such a reproducibility is possible with EM - at all considering beam damage, effects of the environment, and other not - exactly quantifiable influences. - While this points to the physical limitations there are also practical and - economical constraints on how completely EM research can be documented: - For most commercial systems there is a specific accessibility beyond which - detailed settings like lens excitations and low-level hardware settings - may not be retrievable as technology partners have a substantiated interest in - finding a compromise between being open to their users and securing their - business models. - - By design, EM experiments illuminate the specimen with electrons as a - consequence of which the specimen changes if not may get destroyed. - As such, repeatability of numerical processing and clear descriptions of - procedures and system setups should be addressed first. - - If especially a certain simulation package needs a detailed view of the - geometry of the lens system and its excitations during the course of the - experiment, it is difficult to fully abstract the technical details of the - hardware into a set of names for fields and groups that make for a compromise - between clarity but being system-agnostic at the same time. - Settings of apertures are an example where aperture modes are in most cases - aliases behind which there is a set of very detailed settings specific to the - software and control units used. These settings are difficult to retrieve, - are not fully documented by technology partners. This simplification for - users of microscopes makes experiments easier understandable. - On the flipside these subtilities limit the opportunities of especially open- - source developments to make data schemas covering enough for general usage and - specific enough and sufficiently detailed to remain useful for - research by electron microscopy domain experts. - - Instead, currently it is for the docstring to specify what is conceptually - eventually behind such aliases. The design rule we followed while drafting - this NXem application definition and base classes is that there are numerous - (technical) details about an EM which may warrant a very detailed technical - disentangling of settings and reflection of numerous settings as deeply - nested groups, fields and attributes. An application definition can offer a - place to hold these nested representations; however as discussed - at the cost of generality. - - Which specific details matter for answering scientific research questions is - a difficult question to answer by a single team of scientists, especially - if the application definition is to speak for a number of vendors. What makes - it especially challenging is when the application definition is expected to - hold all data that might be of relevance for future questions. - - We are skeptical if there is one such representation that can fulfill all these - aims and interest, while remaining at the same time approachable and executable - by a large number of scientists in a community. However, we are also convinced - that this is not a reason to accept the status quo of having a very large set - of oftentimes strongly overlapping and redundant schemas. - - NXem is our proposal to motivate the EM community to work towards more - standardization and discussion of what constitutes data, i.e. metadata, - numerical and categorical data in research with electron microscopes. We found - that existent terminology can be encoded into a more controlled vocabulary. - - We have concluded that despite all these details of current EM research with - SEM, TEM, and focused-ion beam instruments, there a clearly identifiable - common components and generalizable settings of EM research use cases. - Therefore, - - **This application definition has the following components at the top-level:** - - * Generic experimental details (time-zone-aware timestamp, identifiers, name); - conceptually these are session details. A session at a microscope may - involve the characterization of multiple specimens. For each specimen - an instance of an (NXentry) is created. Details of the instrument have to - be stored at least in an entry. Other entries should refer to these - metadata via links to reduce redundancies. - * Each signal, such as a spectrum or image taken at the microscope, should - have an associated time-zone-aware time stamp and report of the specific - settings of the microscope at that point in time when the image was taken. - This is why instances of :ref:`NXevent_data_em` have an own em_lab section. - The reason is that EMs can be highly dynamic, be used to illuminate the specimen - differently or show drift during signal acquisition, to name but a few effects. - What constitutes a single EM experiment/measurement? - This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), - taking of a secondary electron image for fracture analysis, taking a set of - EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a - specimen in preparation for e.g. an atom probe experiment. - * :ref:`NXmonitor`; - instances to keep track of time-dependent quantities - pertaining to specific components of the instrument. - Alternatively, NXevent_data_em instances can be used to store - time-zone-aware dates of the components, which is - relevant for documenting as exactly as practically possible settings - when images and spectra were taken. - * :ref:`NXinstrument`; - conceptually this is a container to store arbitrary level of detail of the - technical components of the microscope as a device and the lab in which - the microscope is operated. - * :ref:`NXuser`; - conceptually, this is a set with at least one NXuser instance which details - who operated or performed the measurement. Additional NXusers can be - referred to in an NXevent_data_em instance to store - individualized details who executed an event of data acquisition or processing. - * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; - each NXevent_data_em instance is a container to group specific details - about the state of the microscope when a measurement was taken and - relevant data and eventual processing steps were taken (on-the-fly). - * :ref:`NXdata`; at the top-level, conceptually, this is a place for documenting - available default plottable data. A default plottable can be useful for - research data management systems to show a visual representation of some - aspect of the content of the EM session. - Default plottables not intended to serve every possible analysis and - visualization demand but be a preview. We made this choice because what - constitutes a useful default plot is often a matter of interpretation, - somewhat of personal taste, and community standards. In effect, default - plottables are case- and method-specific. - - Usually a session at a microscope is used to collect multiple signals. - Examples for possible default plottables could be arbitrarily taken secondary, - back-scattered, electron image, diffraction pattern, EELS spectra, composition, - or orientation mappings to name but a few. - - **There are a few design choices to consider with sub-ordinate groups:** - - * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` - instances to hold data at the earliest possible step in the computational - processing (which is usually performed with the microscope control and or - integrated analysis software). The formatting of the NXdata groups enables to - display image and spectra with web technology visualization software. - NeXus specifies only the data model, i.e. the terms and their relations. - These descriptions can be implemented and stored in JSON, HDF5, XML, or HSDS, - file storage, or even other formats, although HDF5 is often used. - * When two- and three-dimensional geometric primitive data are stored, it is useful - to write additional optional XDMF fields which support additional plotting of - the data with visualization software like Paraview or Blender. - * Consumable results of EM characterization tasks are usually a sub-set of - data artifacts, as there is not an infinite amount of possible - electron/ion beam-specimen interactions. - * Images of electron counts detected in specific operation modes (bright - field, dark field in TEM, secondary/back-scattered, Kikuchi). - * Spectra (X-ray quanta or Auger electron counts) - * These data are in virtually all cases a result of some numerical processing. - These data and processing steps are modelled as instances of :ref:`NXprocess` - which use terms from a controlled vocabulary e.g. SE (secondary electron), - BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). - - **A key question often asked with EM experiments is how the actual (meta)data - should be stored (in memory or on disk)**. To this end the schema here makes no - specific assumptions, not even that all the fields/group of a schema instance - have to be stored at all into a single file. Instead, the schema specifies the - relations between metadata, some of the constraints and conditions on how the - data should be formatted, what the data conceptually represent, and which terms - (controlled vocabulary) is practical to store to index specific quantities. - - In effect, the application definition is a graph which describes how - numerical data and (meta)data for EM research are related to one another. - - Electron microscopy experiments are usually controlled/performed via - commercial integrated acquisition and instrument control software. - In many cases, an EM dataset is useful only if it gets post-processed - already during the acquisition, i.e. while the scientist is sitting - at the microscope. - Many of these processes are automated, while some demand GUI - interactions with the control software. Examples include collecting - of diffraction pattern and on-the-fly indexing of these. - - It is possible that different types of programs might be used to - perform these processing steps whether on-the-fly or not. If this is - the case the processing should be structured with individual :ref:`NXprocess` - instances. If the program and/or version used for processing referred - to in an NXprocess group is different to the program and version - mentioned in this field, the NXprocess needs - to hold an own program and version. - -# While an important -# step this will still need in the future a mechains -# So far Essentially when the docstrings are no longer needed -# but can be replaced by a connection to an automated tool which understands -# what a specific field represents conceptually, EM data have become more -# generally interoperable EM data. -# NEW ISSUE: see duration and collection time, duty cycle -# NEW ISSUE: duration and collection_time needs a clearer description and -# definition by the community -# NEW ISSUE: should version always be an enumeration? -# NEW ISSUE: filter keywords \(.*?\) -# NEW ISSUE: NXdetector adding only those fields which have changed or not? -# symbols: -# the NeXus default for application definitions wrt to the exists keyword is -# that it is required + Application definition for normalized representation of electron microscopy research. + + In line with the idea of NeXus application definitions, this schema is a + specialized version of NXem_base in that fields and groups are specifically + constrained. This has the effect that some quantities are required, so + that a research data management system (RDMS) can rely on the existence of + these pieces of information without demanding that RDMS to implement further + verification in its own source code or further harmonization or normalization + what each piece of information means conceptually. + + This application definition is thus an example of a general description + with which to normalize specific pieces of information and data collected + within electron microscopy research. + + This application definition is also a blueprint which shows how users + can build specific application definitions by reusing - instead of completely + reimplementing the wheel from scratch - em-specific base classes - and thus + represent electron-microscopy-specific content. + + The constraints of all these application definitions might be different + than for the here exemplified application definition NXem. + + Nevertheless, the key benefit remains: Many pieces of information are still + conceptually the same, named in the same way and found in the same place + in the hierarchy. This supports interoperability of electron microscopy data + and is advantageous compared to having everybody using own formatting and + conceptually not harmonized terms for describing their electron microscopy + research. + + For the detailed rationale and explanation of the concept behind the + NeXus electron microscopy class definitions please consult the preamble + of the NXem_base base class. type: group -NXem(NXobject): - (NXentry): - exists: ['min', '1', 'max', 'unbounded'] - - # NEW ISSUE: the definition field and its version attribute enumeration - # NEW ISSUE: will be added by yaml2nxdl automatically - \@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. +NXem(NXem_base): + # composing from NXem_base should work because NXem_base is composed from NXroot + # just list what is required or recommended or optional + # overwrite which known building blocks should get a different meaning + # and add specific fields for which there is not yet a base class + # this also strenghtens that people write base classes instead of + # highly customized and deeply overwriting application definitions + # other than for base classes the default existentiality constraint is + # exists: required therefore spelling this out is omitted for convenience + # a releasing of this default constraint is possible with writing exists: + \@NX_class: + \@file_time(NX_DATE_TIME): + \@file_name(NX_CHAR): + \@file_update_time(NX_DATE_TIME): + \@NeXus_version(NX_CHAR): + \@HDF5_Version(NX_CHAR): + \@h5py_version(NX_CHAR): + \@default(NX_CHAR): + (NXprogram): # understood by default as PROGRAM(NXprogram), i.e. program1, program2, ... + doc: | + A collection of all programs and libraries which are considered relevant + to understand with which software tools this NeXus file instance was + generated. Ideally, to enable a binary recreation from the input data. + + Examples include the name and version of the libraries used to write the + instance. Ideally, the software which writes these NXprogram instances + also includes the version of the set of NeXus classes i.e. the specific + set of base classes, application definitions, and contributed definitions + with which the here described concepts can be resolved. + + For the `pynxtools library `_ + which is used by the `NOMAD `_ + research data management system, it makes sense to store e.g. the GitHub + repository commit and respective submodule references used. + exists: [min, 0, max, infty] + # each NeXus file instance should have a default plot + # however as there are cases when this cannot be assured we cannot + # make the default required, one example is e.g. a NeXus instance + # where scientists just store conventions without a default plot + cs_profiling(NXcs_profiling): + doc: | + The configuration of the I/O writer software (e.g. `pynxtools `_) + which was used to generate this NeXus file instance. + command_line_call: + (NXentry): # means ENTRY(NXentry) + exists: [min, 1, max, infty] + \@version(NX_CHAR): + definition(NX_CHAR): enumeration: [NXem] - 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 this - application definition rather than write details about the experiment - into this free-text description field. - start_time(NX_DATE_TIME): + experiment_identifier(NXidentifier): exists: recommended + service(NX_CHAR): + identifier(NX_CHAR): + is_persistent(NX_BOOLEAN): + experiment_alias(NX_CHAR): 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 by specifying both - a start_time and an end_time to allow for more detailed bookkeeping and - interpretation of the experiment. The user should be aware that even - with having both time instances specified, it may not be possible - to infer how long the experiment took or for how long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps in NXevent_data_em instances to - provide additional pieces of information. + Either an identifier or an alias that is human-friendly so that + scientist find that experiment again + experiment_description(NX_CHAR): + start_time(NX_DATE_TIME): 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. - (NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program: - \@version: - 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. - 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: + (NXcite): + exists: [min, 0, max, infty] + (NXprogram): # no docstring overwritten means accepting it as it is defined in NXem_base + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + # \@url: + (NXserialized): + exists: [min, 0, max, infty] + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algoritm(NX_CHAR): (NXuser): - exists: ['min', '1', 'max', 'unbounded'] - doc: | - Contact information and eventually details of at least one person - involved in the taking of the microscope session. This can be the - principle investigator who performed this experiment. - Adding multiple users if relevant is recommended. - 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: [min, 1, max, infty] + name(NX_CHAR): + identifier(NXidentifier): 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: + service(NX_CHAR): + identifier(NX_CHAR): + is_persistent(NX_BOOLEAN): + # all other fields are optional but clearly defined in NXem_base + sample(NXsample): + method(NX_CHAR): + identifier(NXidentifier): 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: + service(NX_CHAR): + identifier(NX_CHAR): + is_persistent(NX_BOOLEAN): + parent_identifier(NXidentifier): 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): - - # NEW ISSUE: inject the conclusion from the discussion with Andrea - # according to SAMPLE.yaml 0f8df14 2022/06/15 - # ID: -> maps to name - # name: -> short_title - # user: -> not matched right now - # citation: doi ->why relevant, should be solved by RDMS - doc: | - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - method: - doc: | - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - enumeration: [experiment, simulation] - - # MK:: declared_by_vendor I would rather expect this for a substance - # COMPONENT.yaml - # SUBSTANCE: - # QUANTIFY - name: - doc: | - Ideally (globally) unique persistent identifier. The name distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias of the sample. - Instead, use short_title for this, more convenient alias name. - - In cases where multiple specimens have been loaded into the microscope - the name has to identify the specific one, whose results are stored - by this NXentry, because a single NXentry should be used only for - the characterization of a single specimen. - - Details about the specimen preparation should be stored in the - sample history. - sample_history: - doc: | - Ideally, a reference to a (globally) unique persistent identifier, - representing a data artifact which documents ideally as many details - of the material, its microstructure, and its thermo-chemo-mechanical - processing/preparation history as possible. - - The sample_history is the record what happened before the specimen - was placed into the microscope at the beginning of the session. - - In the case that such a detailed history of the sample/specimen is not - available, use this field as a free-text description to specify a - sub-set of the entire sample history, i.e. what you would consider are - the key steps and relevant information about the specimen, - its material, microstructure, thermo-chemo-mechanical processing state, - and the details of the preparation. - - Specific details about eventual physically-connected material like - embedding resin should be documented ideally also in the sample_history. - If all fails, the description field can be used but it is strongly - discouraged because it leads to eventually non-machine-actionable - data. + service(NX_CHAR): + identifier(NX_CHAR): + is_persistent(NX_BOOLEAN): preparation_date(NX_DATE_TIME): - doc: | - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Usually this should - be a part of the sample history, i.e. the sample is imagined handed over - for analysis. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments - including tracers with a short half time. Further time stamps prior - to preparation_date should better be placed in resources which - describe the sample_history. - short_title: - exists: optional - doc: | - Possibility to give an abbreviation or alias 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. - - # NEW ISSUE: use Andrea and MarkusK groups for describing the geometry of the sample - thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - (Measured) sample thickness. The information is recorded to qualify - if the beam used was likely able to shine through the specimen. - For scanning electron microscopy, in many cases the specimen is much - thicker than what is illuminatable by the electron beam. - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - - # \@units: nm - # NEW ISSUE: error estimates of the thickness and origin, i.e. how the value was obtained would be useful - # NEW ISSUE: error model - # NEW ISSUE: the KIT/SCC SEM, TEM schemata further qualify samples whether they are conductive e/ibeam sensitive - # etc. The problem with this is that beam sensitivity is too vague, spatio-temporal electron dose integral dependent - # KIT/SCC distinguish further conductivity and magnetic properties. While the motivation is clear, making - # simple could be problematic or not decision, it is also these descriptors if remaining vague are also not useful - # what are good or bad properties, it would make sense though to quantify these values - # this includes the description of eventual plasma cleaning steps, - # just knowing that a sample was plasma cleaned is insufficient, maybe it was not cleaned long enough - # if plasma cleaning is done outside the EM than its certainly history, if it happens inside the EM - # are the ibeam description capabilities not sufficient enough? - density(NX_FLOAT): - exists: optional - unit: NX_ANY - doc: | - (Measured) density of the specimen. For multi-layered specimens this - field should only be used to describe the density of the excited - volume. For scanning electron microscopy the usage of this field is - discouraged and instead an instance of an :ref:`NXinteraction_vol_em` - within individual :ref:`NXevent_data_em` instances can provide a much - better description of the relevant details why one may wish to store - the density of the specimen. - - # \@units: g/cm^3 - description: - exists: optional - doc: | - Discouraged free-text field in case properly designed records - for the sample_history are not available. - (NXdata): - exists: optional - doc: | - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. + name: + exists: recommended + atom_types(NX_CHAR): + # again all other fields are optional (NXcoordinate_system_set): - exists: recommended - TRANSFORMATIONS(NXtransformations): - exists: ['min', '0', 'max', 'unbounded'] - - # in what follows each component of the instrument might be equipped with an NXmonitor - (NXmonitor): + exists: [min, 1, max, 1] + (NXcoordinate_system): + exists: [min, 1, max, infty] + origin(NX_CHAR): + alias(NX_CHAR): + type(NX_CHAR): + handedness(NX_CHAR): + x_direction(NX_CHAR): + y_direction(NX_CHAR): + z_direction(NX_CHAR): + # the description can be so lean because we do not need + # to overwrite here s.th. as everything is defined already + # in NXem_base and we also do not wish to overwrite the datatype + # of fields, we just say hey we need the above-mentioned fields + # in the way they are defined in the respective composed base classes + # and they have to be defined + # we also should not need to specify the value type like R, NX_POSINT + # because anyway within a group all field names have to be unique + # so there must not be any name conflict and this we can take to our + # advantage + measurement(NXem_msr): exists: optional - - # NEW ISSUE ADD AS MANY MONITORS AS NEEDED, also for pressure etc. - - # in what follows, an as-detailed as desired collection of components - # making up the instrument follows at this level of the hierarchy - em_lab(NXinstrument): - doc: | - Metadata and numerical data of the microscope and the lab in which it stands. - - The em_lab section contains a description of the instrument and its components. - The component descriptions in this section differ from those inside individual - NXevent_data_em sections. These event instances take the role of time snapshot. - For an NXevent_data_em instance users should store only those settings for a - component which are relevant to understand the current state of the component. - Here, current means at the point in time, i.e. the time interval, - which the event represents. - - For example it is not relevant to store in each event's electron_source - group again the details of the gun type and manufacturer but only the - high-voltage if for that event the high-voltage was different. If for all - events the high-voltage was the same it is not even necessary to include - an electron_source section in the event. - - Individual sections of specific type should have the following names: - - * NXaperture: the name should match with the name of the lens - * NXlens_em: condenser_lens, objective_lens are commonly used names - * NXcorrector_cs: device for correcting spherical aberrations - * NXstage_lab: a collection of component for holding the specimen and - eventual additional component for applying external stimuli on the sample - * NXdetector: several possible names like secondary_electron, - backscattered_electron, direct_electron, ebsd, edx, wds, auger, - cathodoluminescence, camera, ronchigram - instrument_name: - doc: | - Given name of the microscope at the hosting institution. This is an alias. - Examples could be NionHermes, Titan, JEOL, Gemini, etc. - location: - exists: optional - doc: | - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - (NXfabrication): - vendor: + em_lab(NXinstrument): + instrument_name(NX_CHAR): exists: recommended - model: + location(NX_CHAR): exists: recommended - identifier: - exists: recommended - capabilities: - exists: optional - (NXchamber): - exists: optional - (NXebeam_column): - exists: ['min', '1', 'max', '1'] - (NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - (NXchamber): - exists: optional - electron_source(NXsource): - name: - exists: recommended - (NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - voltage(NX_FLOAT): - emitter_type: - exists: recommended - enumeration: [thermionic, schottky, field_emission] - (NXaperture_em): - exists: ['min', '0', 'max', 'unbounded'] - (NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - value(NX_NUMBER): - name: - description: - exists: optional - (NXlens_em): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - If the lens is described at least one of the fields - voltage, current, or value should be defined. - - # a classical case where we want at least one field of multiple to exist - (NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - voltage(NX_NUMBER): - exists: recommended - current(NX_NUMBER): - exists: recommended - value(NX_NUMBER): - exists: recommended - aberration_correction(NXcorrector_cs): - exists: recommended - applied(NX_BOOLEAN): - name: - exists: optional - (NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - ZEMLIN_TABLEAU(NXprocess): - exists: recommended - description: - exists: optional - tilt_angle(NX_FLOAT): - exists: recommended - unit: NX_ANGLE - exposure_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - magnification(NX_NUMBER): - exists: optional - unit: NX_DIMENSIONLESS - (NXprocess): - exists: ['min', '0', 'max', 'unbounded'] - ceos(NXaberration_model_ceos): - exists: optional - c_1(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - a_1(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - b_2(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - a_2(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - c_3(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - s_3(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - a_3(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - - # based on feedback from Thilo Remmele the following aberrations could be measured - b_4(NXaberration): - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - d_4(NXaberration): - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - a_4(NXaberration): - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - c_5(NXaberration): - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - s_5(NXaberration): - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - r_5(NXaberration): - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - a_6(NXaberration): - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - nion(NXaberration_model_nion): - exists: optional - c_1_0(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_1_2_a(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_1_2_b(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_2_1_a(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_2_1_b(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_2_3_a(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_2_3_b(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_3_0(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_3_2_a(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_3_2_b(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_3_4_a(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_3_4_b(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_4_1_a(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_4_1_b(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_4_3_a(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_4_3_b(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_4_5_a(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_4_5_b(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_5_0(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_5_2_a(NXaberration): - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_5_2_b(NXaberration): - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_5_4_a(NXaberration): - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_5_4_b(NXaberration): - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_5_6_a(NXaberration): - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_5_6_b(NXaberration): - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - (NXibeam_column): - exists: ['min', '0', 'max', '2'] (NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - (NXchamber): - exists: optional - ion_source(NXsource): - name: - exists: recommended - (NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - emitter_type: - probe(NXion): - charge_state(NX_INT): - exists: recommended - isotope_vector(NX_UINT): - exists: recommended - name: - exists: recommended - voltage(NX_FLOAT): - current(NX_FLOAT): - (NXaperture_em): - exists: recommended + vendor(NX_CHAR): + model(NX_CHAR): + (NXdetector): + exists: [min, 0, max, infty] (NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - value(NX_NUMBER): - (NXlens_em): - exists: recommended - doc: | - If the lens is described at least one of the fields - voltage, current, or value should be defined. - (NXfabrication): - exists: recommended - identifier: - exists: recommended - voltage(NX_NUMBER): - exists: recommended - current(NX_NUMBER): - exists: recommended - value(NX_NUMBER): - exists: recommended - EBEAM_DEFLECTOR(NXscanbox_em): - exists: ['min', '0', 'max', 'unbounded'] - (NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - pixel_time(NX_FLOAT): - exists: recommended - IBEAM_DEFLECTOR(NXscanbox_em): - exists: ['min', '0', 'max', 'unbounded'] - (NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - (NXoptical_system_em): - exists: recommended - camera_length(NX_NUMBER): - exists: optional - magnification(NX_NUMBER): + vendor(NX_CHAR): + model(NX_CHAR): + (NXebeam_column): + electron_source(NXsource): + emitter_type(NX_CHAR): + probe(NX_CHAR): + (NXibeam_column): exists: optional - defocus(NX_NUMBER): - exists: recommended - - # this is c_1_0 of aberration_correction - semi_convergence_angle(NX_NUMBER): - exists: recommended - working_distance(NX_FLOAT): - exists: recommended - beam_current(NX_FLOAT): - exists: recommended - beam_current_description: - exists: recommended - - # vendor/instrument-specific data currently case-by-case dependent - # e.g. Nion Co. magboard settings - # instances of NXoptical system can be placed here and specific for - # each NXevent_data_em instance if desired - - ##MK::eventually only adding (NXfabrication) and the new docstring - # is needed, will the rest be inferred automatically? - DETECTOR(NXdetector): - exists: ['min', '1', 'max', 'unbounded'] - doc: | - Description of the type of the detector. - - Electron microscopes have typically multiple detectors. - Different technologies are in use like CCD, scintillator, - direct electron, CMOS, or image plate to name but a few. - local_name: - doc: | - Instrument-specific alias/name - - # it is unfortunate that for NXdetector there are already many places - # how one can specify details which could equally end up in fabrications - # we should give better guidance which option to use - (NXfabrication): - exists: recommended - identifier: - exists: recommended - (NXpump): - exists: ['min', '0', 'max', 'unbounded'] - - # NEW ISSUE: do we consider the EELS spectrometer an own detector or an own functional unit i.e. NXeels - stage_lab(NXstage_lab): - name: - (NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - capabilities: - exists: optional - design: - exists: recommended - description: - exists: optional - - # tricky for arbitrary design we cannot enforce all the below to exist at all - position(NX_FLOAT): - exists: recommended - rotation(NX_FLOAT): - exists: recommended - tilt_1(NX_FLOAT): - exists: recommended - tilt_2(NX_FLOAT): - exists: recommended - measurement(NXevent_data_em_set): - exists: ['min', '0', 'max', '1'] - - #MK because it should be possible to use the application definition - #MK to store e.g. just some descriptions about the instrument - #MK:with which then no measurements are attached - # this would enable to use nxs file also for instrument inventory - # system like offer through ELNs/or LIMS - doc: | - A container for storing a set of NXevent_data_em instances. - - An event is a time interval during which the microscope was configured - in a specific way. The microscope is considered as stable enough during - this interval that a measurement with one or multiple detectors is - possible. What constitutes such time interval depends on how the - microscope is used and which measurements the user would like to perform. - - Each NXevent_data_em instance holds one acquisition task with detectors. - Each NXevent_data_em section contains an em_lab group in which specific - settings and states of the microscope during the time interval - can be stored to document the history of states of the microscope over - the course of the session. - - The NXem application definition offers maximal flexibility. - One extreme could be that the only one NXevent_data_em instance is used - and this covers the time interval of the entire session at the microscope. - The other extreme case is that each collection of an image or even - single spot measurement is defined as an NXevent_data_em instance. - In this case the em_lab group inside the NXevent_data_em also holds - the specific time-dependent state of the microscope with which in theory - all dynamics of the system (if measured) can be captured and documented. - - Nowadays microscopes exists for which hard- and software solutions - enable a tracking of the dynamics of the microscope and the actions - of the user (such as with solution like AXONSynchronicity from Protochips). - The NXem application definition can however also be used for less - complex interaction and lower demands wrt to time tracking activities. - - An NXevent_data_em instance holds specific details about how raw data from - a detector were processed. Raw data may already be post-processed as - they are accessible only by the control software with after some internal - processing happened. Nevertheless, these data have to be distinguished from - post-processed data where e.g. raw data are converted to interpreted - spectra, or orientation mappings. - - This post-processing tasks can be performed (on-the-fly, i.e. during - acquisition for sure during the microscope session) or afterwards. - Post-processing is performed with commercial software or various - types and scripts. - - Currently, several specializations of NXimage_set and Nspectrum_set - are used which store some details of this processing. However, as post- - processing tasks can be substantially more advanced and involved it - is clear that data artifacts from the measurement and data artifacts - generated during post-processing are weakly connected only, maybe - exclusively by the fact that a complex numerical post-processing workflow - just takes one raw dataset from an NXevent_data_em instance but generates - multiple derived data artifacts from this. All these should be described - as own application definitions and only weak connections should be made - to an instance of NXem. Instances of NXsubentry is one mechanism in - NeXus how this can be achieved in the future. - (NXevent_data_em): - exists: ['min', '1', 'max', 'unbounded'] - doc: | - A container holding a specific result of the measurement and - eventually metadata how that result was obtained numerically. - - NXevent_data_em instances can hold several specific NXimage_em or - NXspectrum_em instances taken and considered as one event, i.e. - a point in time when the microscope had the settings specified - either in NXinstrument or in this NXevent_data_em instance. - - The application definition is designed without an explicit need for - having an NXevent_data_em instance that contains an NXimage_em or - NXspectra_em instance. Thereby, an NXevent_data_em can also be used - for just documentation about the specific state of the microscope - irrespective whether data have been collected during this time interval. - - In other words the NXinstrument group details primarily the more - static settings and components of the microscope as they are found - by the operator during the session. The NXevent_data_em samples - the dynamics. - - It is not necessary to store data in NXebeam, NXibeam instances - of NXevent_data_em but in this case it is assumed that the settings - were constant over the entire course of the microscope session - and thus all relevant metadata inside the NXinstrument groups - are sufficient to understand the session. - - So far there exists no standard which a majority of the technology - partners and the materials science electron microscopy community - have accepted which could be used for a very generic documentation, - storage and exchange of electron microscope data. Therefore, it is - still a frequent case that specific files have many fields which cannot - safely be mapped or interpreted. - **Therefore, users are always given the advice to keep the vendor files.** - Working however with these vendor files inside specific software, - like materials databases, demands for parsers which extract pieces of - information from the vendor representation (numerical data and metadata) - and map them on a schema with which the database and its associated - software tools can work with. - - Currently, one would loose immediately track of e.g. provenance and - the origin of certain data in NXevent_data_em instances unless really - all data are safely and reliably copied over into an instance of the - schema. Currently, though, this is sadly effectively prevented in many - cases as vendors indeed implemented often sophisticated provenance - and commercial software state tracking tools but these are not yet - documented covering enough in our opinion so that it is safe to assume - all vendor field names are known, logically understood, interpretable, - and thus mappable on a common schema using a controlled common - vocabulary. - - Therefore we encourage user for now to store for each NXimage_set - or NXspectra_set instance to supply the so-called source of the data. - This can for instance be the name and hashvalue of the original - file which was acquired during the microscope session and from which then - certain details like numerical data and metadata were copied into an - instance of this schema for the purpose of working with the data in - e.g. tools offered by research data management (RDM) systems or - materials database. - - During our work on implementing file format/metadata parsers and - developing this application definition, we realized that **several - software tools currently do not consistently format critical metadata - like time-zone-aware timestamps** when events of data collection or - processing happened. - - We would like to encourage the community and especially the vendors - to work towards a standardization, or at least an open documentation - of the way how time-zone-aware time data are collected and stored how - and where during a microscope session and how they end up in files - and databases with which users interact. - This would enable to supplement instances of this schema with specific - time data and assure that these time data can be used to reliably - contextualize individual datasets and processing steps in materials - information systems. - - For the reason that these measures have not yet been fully taken, - the start_time and end_time is a recommended option. - The idea behind these time-zone-aware dates is to identify when - the data were collected at the microscope but NOT when they were - transcoded by some software tool(s) while storing the data in an - instance of this schema. - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - event_identifier: - exists: recommended - event_type: - exists: recommended - - # a collection of images take and group under this event - # NEW ISSUE: should this only be one instance for a given event? - IMAGE_SET(NXimage_set): - exists: optional - (NXprocess): - source: - \@version: - mode: - exists: recommended - detector_identifier: - (NXprogram): - exists: ['min', '0', 'max', 'unbounded'] - program: - \@version: - stack(NXdata): - exists: recommended - \@signal: - \@axes: - \@AXISNAME_indices: - title: - data_counts(NX_NUMBER): - \@long_name: - - # dimensions: - # rank: 3 - # dim: [[1, n_images], [2, n_y], [3, n_x]] - axis_image_identifier(NX_UINT): - \@long_name: - - # dimensions: - # rank: 1 - # dim: [[1, n_images]] - axis_y(NX_NUMBER): - \@long_name: - - # dimensions: - # rank: 1 - # dim: [[1, n_y]] - axis_x(NX_NUMBER): - \@long_name: - - # dimensions: - # rank: 1 - # dim: [[1, n_x]] - SPECTRUM_SET(NXspectrum_set): - exists: optional - (NXprocess): - source: - \@version: - mode: - exists: recommended - detector_identifier: - (NXprogram): - exists: ['min', '0', 'max', 'unbounded'] - program: - \@version: - stack(NXdata): - exists: recommended - data_counts(NX_NUMBER): - unit: NX_UNITLESS - dimensions: - rank: 3 - dim: [[1, n_y], [2, n_x], [3, n_energy]] - \@long_name: - - # \@signal: counts - # \@axes: [ypos, xpos, energy] - # \@ypos_indices: 0 - # \@xpos_indices: 1 - # \@energy_indices: 2 - axis_y(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - axis_x(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - axis_energy(NX_NUMBER): - unit: NX_ENERGY - dimensions: - rank: 1 - dim: [[1, n_energy]] - \@long_name: - summary(NXdata): - exists: recommended - data_counts(NX_NUMBER): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_energy]] - \@long_name: - - # \@signal: counts - # \@axes: [energy] - # \@energy_indices: 0 - axis_energy(NX_NUMBER): - unit: NX_ENERGY - dimensions: - rank: 1 - dim: [[1, n_energy]] - \@long_name: - adf(NXimage_set): - exists: optional - (NXprocess): - source: - \@version: - mode: - exists: recommended - detector_identifier: - (NXprogram): - exists: ['min', '0', 'max', 'unbounded'] - program: - \@version: - inner_half_angle(NX_FLOAT): - exists: recommended - unit: NX_ANGLE - doc: | - Annulus inner half angle - outer_half_angle(NX_FLOAT): - exists: recommended - unit: NX_ANGLE - doc: | - Annulus outer half angle - stack(NXdata): - exists: recommended - \@signal: - \@axes: - \@AXISNAME_indices: - - # \@long_name: - title: - data_counts(NX_NUMBER): - \@long_name: - axis_image_identifier(NX_UINT): - \@long_name: - - # dimensions: - # rank: 3 - # dim: [[1, n_images], [2, n_y], [3, n_x]] - axis_y(NX_NUMBER): - \@long_name: - - # dimensions: - # rank: 1 - # dim: [[1, n_y]] - axis_x(NX_NUMBER): - \@long_name: - - # dimensions: - # rank: 1 - # dim: [[1, n_x]] - xray(NXspectrum_set): - exists: optional - (NXprocess): - source: - \@version: - mode: - exists: recommended - detector_identifier: - (NXprogram): - exists: ['min', '0', 'max', 'unbounded'] - program: - \@version: - stack(NXdata): - \@signal: - \@axes: - \@AXISNAME_indices: - - # \@long_name: - title: - data_counts(NX_NUMBER): - \@long_name: - - # dimensions: - # rank: 3 - # dim: [[1, n_y], [2, n_x], [3, n_photon_energy]] - axis_y(NX_NUMBER): - \@long_name: - - # dimensions: - # rank: 1 - # dim: [[1, n_y]] - axis_x(NX_NUMBER): - \@long_name: - - # dimensions: - # rank: 1 - # dim: [[1, n_x]] - axis_photon_energy(NX_NUMBER): - \@long_name: - - # dimensions: - # rank: 1 - # dim: [[1, n_photon_energy]] - summary(NXdata): - \@signal: - \@axes: - \@AXISNAME_indices: - - # \@long_name: - title: - data_counts(NX_NUMBER): - \@long_name: - - # dimensions: - # rank: 1 - # dim: [[1, n_photon_energy]] - axis_photon_energy(NX_NUMBER): - \@long_name: - - # dimensions: - # rank: 1 - # dim: [[1, n_photon_energy]] - # NEW ISSUE: all of this should be offloaded to NXem_edx -\-> - indexing(NXprocess): - exists: optional - - ##MK:: much content of the base class has not been added although - # should be considered and made recommended at least - ELEMENTNAME(NXprocess): - exists: ['min', '1', 'max', '256'] - summary(NXdata): - \@signal: - \@axes: - \@AXISNAME_indices: - - # \@long_name: - title: - data_counts(NX_NUMBER): - \@long_name: - - # dimensions: - # rank: 2 - # dim: [[1, n_y], [2, n_x]] - axis_y(NX_NUMBER): - \@long_name: - - # dimensions: - # rank: 1 - # dim: [[1, n_y]] - axis_x(NX_NUMBER): - \@long_name: - - # dimensions: - # rank: 1 - # dim: [[1, n_x]] - # NEW ISSUE: all of this should be offloaded to NXem_edx -\-> - eels(NXspectrum_set): - exists: optional - (NXprocess): - source: - \@version: - mode: - exists: recommended - detector_identifier: - (NXprogram): - exists: ['min', '0', 'max', 'unbounded'] - program: - \@version: - stack(NXdata): - \@signal: - \@axes: - \@AXISNAME_indices: - - # \@long_name: - title: - data_counts(NX_NUMBER): - \@long_name: - - # dimensions: - # rank: 3 - # dim: [[1, n_y], [2, n_x], [3, n_energy_loss]] - axis_y(NX_NUMBER): - \@long_name: - - # dimensions: - # rank: 1 - # dim: [[1, n_y]] - axis_x(NX_NUMBER): - \@long_name: - - # dimensions: - # rank: 1 - # dim: [[1, n_x]] - axis_energy_loss(NX_NUMBER): - \@long_name: - - # dimensions: - # rank: 1 - # dim: [[1, n_energy_loss]] - summary(NXdata): - \@signal: - \@axes: - \@AXISNAME_indices: - - # \@long_name: - title: - data_counts(NX_NUMBER): - \@long_name: - - # dimensions: - # rank: 1 - # dim: [[1, n_energy_loss]] - axis_energy_loss(NX_NUMBER): - - # dimensions: - # rank: 1 - # dim: [[1, n_energy_loss]] - \@long_name: - - # base classes for which we have at the moment no example implemented - # consider to replace se, bse, bf, df, chamber, ronchigram, by generic NXimage_set - # NEW ISSUE: all of this should be offloaded to NXem_eels -\-> - kikuchi(NXimage_set): - exists: optional - (NXprocess): - source: - \@version: - mode: - exists: recommended - detector_identifier: - (NXprogram): - exists: ['min', '0', 'max', 'unbounded'] - program: - \@version: - stack(NXdata): - \@signal: - \@axes: - \@AXISNAME_indices: - - # \@long_name: - title: - data_counts(NX_NUMBER): - \@long_name: - - # dimensions: - # rank: 3 - # dim: [[1, n_p], [2, n_y], [3, n_x]] - pattern_identifier(NX_UINT): - \@long_name: - - # dimensions: - # rank: 1 - # dim: [[1, n_p]] - axis_y(NX_NUMBER): - \@long_name: - - # dimensions: - # rank: 1 - # dim: [[1, n_y]] - axis_x(NX_NUMBER): - \@long_name: - - # dimensions: - # rank: 1 - # dim: [[1, n_x]] - scan_point_identifier(NX_UINT): - - # \@long_name: - # dimensions: - # rank: 1 - # dim: [[1, n_p]] - # no summary because this will be handled by EBSD - - # (NXimage_set_em_se): - # exists: optional - # (NXimage_set_em_bse): - # exists: optional - # (NXimage_set_em_bf): - # exists: optional - # (NXimage_set_em_df): - # exists: optional - # (NXspectrum_set_em_auger): - # exists: optional - # (NXspectrum_set_em_cathodolum): - # exists: optional - # (NXimage_set_em_ecci): - # exists: optional - # (NXimage_set_em_diffrac): - # exists: optional - # (NXimage_set_em_ronchigram): - # exists: optional - # (NXimage_set_em_chamber): - # exists: optional - # a collection of specific details about state of the microscope - em_lab(NXinstrument): - exists: optional - (NXchamber): - exists: optional - (NXebeam_column): - exists: ['min', '0', 'max', '1'] - (NXchamber): - exists: optional - electron_source(NXsource): - exists: optional - voltage(NX_FLOAT): - (NXaperture_em): - exists: optional - value(NX_NUMBER): - (NXlens_em): - exists: optional - voltage(NX_NUMBER): - exists: recommended - current(NX_NUMBER): - exists: recommended - value(NX_NUMBER): - exists: recommended - aberration_correction(NXcorrector_cs): - exists: recommended - applied(NX_BOOLEAN): - name: - exists: optional - (NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - ZEMLIN_TABLEAU(NXprocess): + ion_source(NXsource): + probe(NXion): + # voltage(NX_NUMBER): + # does not have to be written out unless that field should be required! + # like all other sub-graphs in the NXibeam_column base class and all + # the fields they can be used + (NXevent_data_em_set): + exists: [min, 0, max, 1] + # an instance must not have an NXevent_data_em_set but if it has one it must not be more than 1 ! + (NXevent_data_em): + exists: [min, 0, max, infty] + start_time(NX_DATE_TIME): + exists: recommended + end_time(NX_DATE_TIME): + exists: recommended + (NXimage_r_set): + exists: [min, 0, max, infty] + (NXprocess): + source(NXserialized): exists: recommended - description: - exists: optional - tilt_angle(NX_FLOAT): - exists: recommended - unit: NX_ANGLE - exposure_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - magnification(NX_NUMBER): - exists: optional - unit: NX_DIMENSIONLESS - (NXprocess): - exists: ['min', '0', 'max', 'unbounded'] - ceos(NXaberration_model_ceos): - exists: optional - c_1(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - a_1(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - b_2(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - a_2(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - c_3(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - s_3(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - a_3(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - - # based on feedback from Thilo Remmele the following aberrations could be measured - b_4(NXaberration): - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - d_4(NXaberration): - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - a_4(NXaberration): - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - c_5(NXaberration): - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - s_5(NXaberration): - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - r_5(NXaberration): - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - a_6(NXaberration): - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - angle(NX_FLOAT): - unit: NX_ANGLE - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: recommended - unit: NX_TIME - nion(NXaberration_model_nion): - exists: optional - c_1_0(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_1_2_a(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_1_2_b(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_2_1_a(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_2_1_b(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_2_3_a(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_2_3_b(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_3_0(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_3_2_a(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_3_2_b(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_3_4_a(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_3_4_b(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_4_1_a(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_4_1_b(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_4_3_a(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_4_3_b(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_4_5_a(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_4_5_b(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_5_0(NXaberration): - exists: recommended - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_5_2_a(NXaberration): - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_5_2_b(NXaberration): - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_5_4_a(NXaberration): - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_5_4_b(NXaberration): - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_5_6_a(NXaberration): - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - c_5_6_b(NXaberration): - exists: optional - magnitude(NX_FLOAT): - unit: NX_LENGTH - uncertainty(NX_FLOAT): - exists: recommended - unit: NX_LENGTH - uncertainty_model: - exists: recommended - delta_time(NX_FLOAT): - exists: optional - unit: NX_TIME - (NXibeam_column): - exists: ['min', '0', 'max', '2'] - (NXchamber): - exists: optional - ion_source(NXsource): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + detector_identifier(NX_CHAR): + stack(NXdata): exists: optional - probe(NXion): - exists: recommended - charge_state(NX_INT): - exists: recommended - isotope_vector(NX_UINT): - exists: recommended - name: - exists: recommended - voltage(NX_FLOAT): - exists: recommended - current(NX_FLOAT): + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_INT): + \@long_name(NX_CHAR): + title(NX_CHAR): + intensity(NX_NUMBER): + \@long_name(NX_CHAR): + axis_image_identifier(NX_INT): + \@long_name(NX_CHAR): + axis_y(NX_NUMBER): + \@long_name(NX_CHAR): + axis_x(NX_NUMBER): + \@long_name(NX_CHAR): + (NXimage_c_set): + exists: [min, 0, max, infty] + (NXprocess): + source(NXserialized): exists: recommended - (NXaperture_em): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + detector_identifier(NX_CHAR): + stack(NXdata): exists: optional - value(NX_NUMBER): - exists: recommended - (NXlens_em): + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_CHAR): + \@long_name(NX_CHAR): + title: + real(NX_NUMBER): + \@long_name(NX_CHAR): + imag(NX_NUMBER): + \@long_name(NX_CHAR): + axis_image_identifier(NX_INT): + \@long_name(NX_CHAR): + axis_j(NX_NUMBER): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + hyperstack(NXdata): exists: optional - voltage(NX_NUMBER): - exists: recommended - current(NX_NUMBER): - exists: recommended - value(NX_NUMBER): + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_CHAR): + \@long_name(NX_CHAR): + title: + real(NX_NUMBER): + \@long_name(NX_CHAR): + imag(NX_NUMBER): + \@long_name(NX_CHAR): + axis_image_identifier(NX_INT): + \@long_name(NX_CHAR): + axis_k(NX_NUMBER): + \@long_name(NX_CHAR): + axis_j(NX_NUMBER): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + (NXspectrum_set): + exists: [min, 0, max, infty] + (NXprocess): + source(NXserialized): exists: recommended - ebeam_deflector(NXscanbox_em): - exists: optional - pixel_time(NX_FLOAT): - exists: recommended - ibeam_deflector(NXscanbox_em): - exists: optional - - # NEW ISSUE: how to handle situations where we wish to describe multiple deflectors? - (NXoptical_system_em): - exists: optional - camera_length(NX_NUMBER): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + detector_identifier(NX_CHAR): + stack(NXdata): exists: optional - magnification(NX_NUMBER): + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_INT): + \@long_name(NX_CHAR): + title(NX_CHAR): + intensity(NX_NUMBER): + \@long_name(NX_CHAR): + axis_y(NX_NUMBER): + \@long_name(NX_CHAR): + axis_x(NX_NUMBER): + \@long_name(NX_CHAR): + axis_energy(NX_NUMBER): + \@long_name(NX_CHAR): + summary(NXdata): + exists: recommended + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_INT): + \@long_name(NX_CHAR): + title(NX_CHAR): + axis_energy(NX_NUMBER): + \@long_name(NX_CHAR): + em_lab(NXinstrument): + (NXebeam_column): + electron_source(NXsource): + voltage(NX_NUMBER): + (NXibeam_column): exists: optional - defocus(NX_NUMBER): - exists: recommended - semi_convergence_angle(NX_NUMBER): - exists: recommended - working_distance(NX_FLOAT): - exists: recommended - beam_current(NX_FLOAT): - exists: recommended - beam_current_description: - exists: recommended - (NXdetector): - exists: optional - - # dynamically changing detector settings uses only during this NXevent_data_em - (NXpump): - exists: optional - (NXstage_lab): - exists: optional - position(NX_FLOAT): - exists: recommended - rotation(NX_FLOAT): - exists: recommended - tilt_1(NX_FLOAT): - exists: recommended - tilt_2(NX_FLOAT): - exists: recommended - (NXuser): - exists: ['min', '0', 'max', 'unbounded'] - name: + ion_source(NXsource): + probe(NXion): + voltage(NX_NUMBER): + # why at all do we need to add here (NXinstrument) ? + # nyaml2nxdl could query the NXem_msr base class definition + # and check if an identifier named em_lab exists in this case + # it assumes it is em_lab(NXinstrument) and continues. + simulation(NXem_sim): + exists: optional + # remains to be discussed based on examples + # relevant research result post-processed for specific community methods + # but normalized in its representation ready to be consumed for a + # research data management system + (NXroi): + exists: [min, 0, max, infty] + doc: | + A region-of-interest analyzed either during or after the session. + For which specific processed data of the measured or simulated + data are available. + # as soon as one entry is here constrained further + # an RDM can be sure to find specific pieces of information in a + # specific way but then every user of this application definition + # is required to provide such information in this way! + se(NXem_img): + exists: optional + # remains to be discussed based on examples + bse(NXem_img): + exists: optional + # remains to be discussed based on examples + ebsd(NXem_ebsd): + exists: optional + # remains to be discussed based on examples + eds(NXem_eds): + exists: optional + # remains to be discussed based on examples + adf(NXem_adf): + exists: optional + # remains to be discussed based on examples + eels(NXem_eels): + exists: optional + # remains to be discussed based on examples + # cl(NXem_cl): + # exists: optional + correlation(NXem_correlation): + exists: optional + # remains to be discussed based on examples -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 14203c50c2c3841dc7955b2b7b911e389f613155078bb310415ec84cd5bf7487 -# -# -# -# -# -# -# Characterization of a sample during a session on an electron microscope. -# -# **The idea and aim of NXem**: -# Electron microscopy (EM) research, whether it be performed with scanning electron -# microscope (SEM) or transmission electron microscope (TEM) instruments, uses -# versatile tools for preparing and characterizing samples and specimens. -# The term specimen is considered a synonym for sample in this application definition. -# A specimen is a physical portion of material that is studied/characterized during -# the microscope session, eventually in different places on the specimen surface, -# illuminating the surface layers or shining through thin specimens. -# These places are named regions of interest (ROIs). -# -# Fundamentally, an electron microscope is an electron accelerator. -# Experimentalists use it in sessions during which they characterize as well as -# prepare specimens. This application definition describes data and metadata about -# processes and characterization tasks applied to one specimen. -# The application definition focuses on the usage of EM in materials research. -# The application definition design makes it in principle applicable also in -# cryo-EM on biomaterials. -# -# Multiple specimens have to be described with multiple :ref:`NXentry` instances. -# -# **Electron microscopes motivate the development of an embracing data schema:** -# There are research groups who use an EM in a manner where it is exclusively -# operated by a single, instrument-responsible scientists or a team of scientists. -# These users may perform analyses for other users as a service task, especially -# in large research facility settings. Oftentimes, though, and especially for -# cutting-edge instruments, the scientists guide the process maybe even control -# the microscope. Instruments are usually controlled on-premises but also more -# and more functionalities for remote control have become available. -# Scientists oftentimes can ask technicians for support. In all cases, -# these people are considered users. Users might have different -# roles though. -# -# The rational behind a common EM schema rather than making separate schemas -# for SEM or TEM are primarily the key similarities of SEM and TEM -# instruments: -# -# Both type of instruments have electro-magnetic lenses. These may differ in -# design, alignment, number, and level of corrected for aberrations. -# As an obvious difference, a TEM is mainly used for measuring the transmitted -# electron beam. This calls for using a different lens setup and relative -# placement of the specimen in the lens setup. Also TEM specimens are -# substantially thinner than specimens characterized with SEM to enable an -# illumination through the specimen. This offers capabilities for probing of -# additional physical mechanisms of electron-matter interaction which are -# unavailable in SEMs. -# -# Nevertheless, both types of electron microscopes use detector systems which -# measure different types of signals that originate from the same set of -# radiation/specimen interactions. Often these detectors have a similar design -# and technology or are even used both in SEMs and TEMs. -# -# **An embracing schema instead of specific SEM or TEM schemas**: -# Given these physical and technical differences, different instruments have -# been developed. This led to a coexistence of two broad interacting -# communities: SEM and TEM users. From a data science perspective, we -# acknowledge that the more specific a research question is and the narrower it -# is the addressed circle of users which develops or uses schemas for research -# data management (RDM) with EM, the more understandable it is that scientists -# of either community (or sub-community) ask for designing method-specific schemas. -# -# Researchers who have a single (main) microscope of some vendor in their lab, -# may argue they need an NXem_vendor_name schema or an NXem_microscope_name or -# an NXem_sem or a NXem_tem schema. -# Scientists exclusively working with one technique or type of signal probed -# (X-rays, electrons) may argue they wish to be pragmatic and store only -# what is immediately relevant for their particular technique and -# research questions. In effect, they may advocate for method-specific -# schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. -# -# However, the history of electron microscopy has shown that these activities led -# to a zoo of schemas and especially vocabulary in use with implementations of these -# into many data and file formats. There is nothing which prevents the communities -# to make these schemas open and interoperable. Open here means not that all -# data stored according to such schemas have to end up in the open-source domain. -# There can be embargo periods first of all. -# -# Open means that the metadata and associated schemata are documented in a manner -# that as many details are open as possible in the sense that others can understand -# what the (meta)data mean conceptually. Instead of trying of maintain a zoo -# of eventually difficult to make interoperable formats and schema we would like -# to advocate that the `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ -# should guide all decisions how data and metadata should be stored. -# -# EM instruments, software, and research are moving targets. Consequently, -# there is a key challenge and inconvenience with having many different schemas -# with associated representations of data and metadata: Each combination of -# schemas or an interoperable-made handshake between two file formats or software -# packages has to be maintained by software developers. This counts especially -# when data should be processed interoperably between software packages. -# -# This brings two problems: Many software tools and parsers for the handshaking -# between tools have to be maintained. This can result in usage of different -# terminology, which in turn results in representations and connections made -# between different data representations and workflows that are not -# machine-actionable. -# `There are community efforts to harmonize the terminology. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ -# -# **The advantage of working towards a common vocabulary and representation**: -# A common vocabulary can serve interoperability as developers of schemas and -# scientists can reuse for instance these terms, thus supporting interoperability. -# Ideally, scientists specialize an application definition only for the few very -# specific additional quantities of their instruments and techniques. This is -# better than reimplementing the wheel for descriptions of EM instruments. -# This route of more standardization can support the EM community in that it -# removes the necessity for having to maintain a very large number of schemas. -# -# Aiming for more standardization, i.e. a lower number of schemas rather than -# a single standard for electron microscopy is a compromise that can serve -# academia and industry as it enables a focusing of software development -# efforts on those schemas, on fixing and discussing them, and on harmonizing -# their common vocabulary. These activities can be specifically relevant also -# for technology partners building EM hard- and software as it improves the -# longevity of certain schemas; and thus can help with incentivizing them to support -# the community with implementing support for such schemas into their applications. -# -# In effect, everybody can gain from this as it will likely reduce the cases -# in which scientists have to fix bugs in making their own tools compliant and -# interoperable with tools of their colleagues and the wider community. -# -# The here proposed NXem application definition offers modular components -# (EM-research specific base classes) for defining schemas for EM research. -# Thereby, NXem can be useful to extends top-level ontologies towards a domain- -# and method-specific ontology for electron microscopy as it is used for -# materials research. -# -# Working towards a common vocabulary is a community activity that profits from -# everybody reflecting in detail whether certain terms they have used in the past -# are not eventually conceptually similar if not the same as what this application -# definition and its base classes provide. We are happy for receiving your feedback. -# -# **Addressing the generality versus specificity challenge**: -# It is noteworthy to understand that (not only for NeXus), schemas differ -# already if at least one field is required in one version of the schema, -# but it is set optional in another schema. If group(s), field(s), or -# attributes are removed or added, or even a docstring is changed, schemas can -# become inconsistent. It is noteworthy to mention that the idea of a NeXus application -# definition serves as a contract between a data provider and a data consumer. -# Providers can be the software of a specific microscopes or users with specific -# analysis needs. Consumers can be again specific software tools, like vendor -# software for controlling the instrument or a scientific software for doing -# artificial intelligence analyses on EM data). Such changes of a schema lead -# to new versions. Strictly speaking an application definition can only be -# fully general if it does not make a single entry required, in which case however -# it would also not offer much value as even empty datasets would be compliant -# with such a schema. -# -# **Verification of constraints and conditions**: -# Tools like NeXus so far do not avoid or protect against all such possible -# inconsistencies; however NeXus offers a mechanism and toolset, through which -# schemas can be documented and defined. In effect, having an openly documented -# (at a case-specific level of technical detail) schema is a necessary but alone -# not a sufficient step to take EM research on a route of machine-actionable -# and interoperable FAIR data. -# -# This stresses again the fundamental and necessary role of working towards -# a common vocabulary and, with a longer perspective in mind, a machine-actionable -# knowledge representation and verification engine. So far many conditions and -# requirements are formulated in the docstrings of the respective entries of -# the application definition. -# -# **NXem takes a key step towards standardization of EM data schemas**. -# It offers a controlled vocabulary and set of relations between concepts and -# enables the description of the data which are collected for research with -# electron microscopes. To be most efficient and offering reusability, the NXem -# application definition should be understood as a template that one should -# ideally use as is. NXem can be considered a base for designing more specialized -# definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd). -# -# **The use of NXem should be as follows:** -# Offspring application definitions should not remove groups but leave these -# optional or, even better, propose changes to NXem. -# -# A particular challenge with electron microscopes as physical instruments are -# their dynamics. To make EM data understandable, repeatable, and eventually -# corresponding experiments reproducible in general requires a documentation -# of the spatio-temporal dynamics of the instrument in its environment. -# It is questionable to which level such a reproducibility is possible with EM -# at all considering beam damage, effects of the environment, and other not -# exactly quantifiable influences. -# While this points to the physical limitations there are also practical and -# economical constraints on how completely EM research can be documented: -# For most commercial systems there is a specific accessibility beyond which -# detailed settings like lens excitations and low-level hardware settings -# may not be retrievable as technology partners have a substantiated interest in -# finding a compromise between being open to their users and securing their -# business models. -# -# By design, EM experiments illuminate the specimen with electrons as a -# consequence of which the specimen changes if not may get destroyed. -# As such, repeatability of numerical processing and clear descriptions of -# procedures and system setups should be addressed first. -# -# If especially a certain simulation package needs a detailed view of the -# geometry of the lens system and its excitations during the course of the -# experiment, it is difficult to fully abstract the technical details of the -# hardware into a set of names for fields and groups that make for a compromise -# between clarity but being system-agnostic at the same time. -# Settings of apertures are an example where aperture modes are in most cases -# aliases behind which there is a set of very detailed settings specific to the -# software and control units used. These settings are difficult to retrieve, -# are not fully documented by technology partners. This simplification for -# users of microscopes makes experiments easier understandable. -# On the flipside these subtilities limit the opportunities of especially open- -# source developments to make data schemas covering enough for general usage and -# specific enough and sufficiently detailed to remain useful for -# research by electron microscopy domain experts. -# -# Instead, currently it is for the docstring to specify what is conceptually -# eventually behind such aliases. The design rule we followed while drafting -# this NXem application definition and base classes is that there are numerous -# (technical) details about an EM which may warrant a very detailed technical -# disentangling of settings and reflection of numerous settings as deeply -# nested groups, fields and attributes. An application definition can offer a -# place to hold these nested representations; however as discussed -# at the cost of generality. -# -# Which specific details matter for answering scientific research questions is -# a difficult question to answer by a single team of scientists, especially -# if the application definition is to speak for a number of vendors. What makes -# it especially challenging is when the application definition is expected to -# hold all data that might be of relevance for future questions. -# -# We are skeptical if there is one such representation that can fulfill all these -# aims and interest, while remaining at the same time approachable and executable -# by a large number of scientists in a community. However, we are also convinced -# that this is not a reason to accept the status quo of having a very large set -# of oftentimes strongly overlapping and redundant schemas. -# -# NXem is our proposal to motivate the EM community to work towards more -# standardization and discussion of what constitutes data, i.e. metadata, -# numerical and categorical data in research with electron microscopes. We found -# that existent terminology can be encoded into a more controlled vocabulary. -# -# We have concluded that despite all these details of current EM research with -# SEM, TEM, and focused-ion beam instruments, there a clearly identifiable -# common components and generalizable settings of EM research use cases. -# Therefore, -# -# **This application definition has the following components at the top-level:** -# -# * Generic experimental details (time-zone-aware timestamp, identifiers, name); -# conceptually these are session details. A session at a microscope may -# involve the characterization of multiple specimens. For each specimen -# an instance of an (NXentry) is created. Details of the instrument have to -# be stored at least in an entry. Other entries should refer to these -# metadata via links to reduce redundancies. -# * Each signal, such as a spectrum or image taken at the microscope, should -# have an associated time-zone-aware time stamp and report of the specific -# settings of the microscope at that point in time when the image was taken. -# This is why instances of :ref:`NXevent_data_em` have an own em_lab section. -# The reason is that EMs can be highly dynamic, be used to illuminate the specimen -# differently or show drift during signal acquisition, to name but a few effects. -# What constitutes a single EM experiment/measurement? -# This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), -# taking of a secondary electron image for fracture analysis, taking a set of -# EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a -# specimen in preparation for e.g. an atom probe experiment. -# * :ref:`NXmonitor`; -# instances to keep track of time-dependent quantities -# pertaining to specific components of the instrument. -# Alternatively, NXevent_data_em instances can be used to store -# time-zone-aware dates of the components, which is -# relevant for documenting as exactly as practically possible settings -# when images and spectra were taken. -# * :ref:`NXinstrument`; -# conceptually this is a container to store arbitrary level of detail of the -# technical components of the microscope as a device and the lab in which -# the microscope is operated. -# * :ref:`NXuser`; -# conceptually, this is a set with at least one NXuser instance which details -# who operated or performed the measurement. Additional NXusers can be -# referred to in an NXevent_data_em instance to store -# individualized details who executed an event of data acquisition or processing. -# * :ref:`NXevent_data_em` instances as an NXevent_data_em_set; -# each NXevent_data_em instance is a container to group specific details -# about the state of the microscope when a measurement was taken and -# relevant data and eventual processing steps were taken (on-the-fly). -# * :ref:`NXdata`; at the top-level, conceptually, this is a place for documenting -# available default plottable data. A default plottable can be useful for -# research data management systems to show a visual representation of some -# aspect of the content of the EM session. -# Default plottables not intended to serve every possible analysis and -# visualization demand but be a preview. We made this choice because what -# constitutes a useful default plot is often a matter of interpretation, -# somewhat of personal taste, and community standards. In effect, default -# plottables are case- and method-specific. -# -# Usually a session at a microscope is used to collect multiple signals. -# Examples for possible default plottables could be arbitrarily taken secondary, -# back-scattered, electron image, diffraction pattern, EELS spectra, composition, -# or orientation mappings to name but a few. -# -# **There are a few design choices to consider with sub-ordinate groups:** -# -# * Images and spectra should be stored as :ref:`NXimage_set` and :ref:`NXspectrum_set` -# instances to hold data at the earliest possible step in the computational -# processing (which is usually performed with the microscope control and or -# integrated analysis software). The formatting of the NXdata groups enables to -# display image and spectra with web technology visualization software. -# NeXus specifies only the data model, i.e. the terms and their relations. -# These descriptions can be implemented and stored in JSON, HDF5, XML, or HSDS, -# file storage, or even other formats, although HDF5 is often used. -# * When two- and three-dimensional geometric primitive data are stored, it is useful -# to write additional optional XDMF fields which support additional plotting of -# the data with visualization software like Paraview or Blender. -# * Consumable results of EM characterization tasks are usually a sub-set of -# data artifacts, as there is not an infinite amount of possible -# electron/ion beam-specimen interactions. -# * Images of electron counts detected in specific operation modes (bright -# field, dark field in TEM, secondary/back-scattered, Kikuchi). -# * Spectra (X-ray quanta or Auger electron counts) -# * These data are in virtually all cases a result of some numerical processing. -# These data and processing steps are modelled as instances of :ref:`NXprocess` -# which use terms from a controlled vocabulary e.g. SE (secondary electron), -# BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence). -# -# **A key question often asked with EM experiments is how the actual (meta)data -# should be stored (in memory or on disk)**. To this end the schema here makes no -# specific assumptions, not even that all the fields/group of a schema instance -# have to be stored at all into a single file. Instead, the schema specifies the -# relations between metadata, some of the constraints and conditions on how the -# data should be formatted, what the data conceptually represent, and which terms -# (controlled vocabulary) is practical to store to index specific quantities. -# -# In effect, the application definition is a graph which describes how -# numerical data and (meta)data for EM research are related to one another. -# -# Electron microscopy experiments are usually controlled/performed via -# commercial integrated acquisition and instrument control software. -# In many cases, an EM dataset is useful only if it gets post-processed -# already during the acquisition, i.e. while the scientist is sitting -# at the microscope. -# Many of these processes are automated, while some demand GUI -# interactions with the control software. Examples include collecting -# of diffraction pattern and on-the-fly indexing of these. -# -# It is possible that different types of programs might be used to -# perform these processing steps whether on-the-fly or not. If this is -# the case the processing should be structured with individual :ref:`NXprocess` -# instances. If the program and/or version used for processing referred -# to in an NXprocess group is different to the program and version -# mentioned in this field, the NXprocess needs -# to hold an own program and version. -# -# -# -# -# -# An at least as strong as SHA256 hashvalue of the file -# that specifies the application definition. -# -# -# -# -# -# NeXus NXDL schema to which this file conforms. -# -# -# -# -# -# -# -# Ideally, a (globally) unique persistent identifier -# for referring to this experiment. -# -# The identifier is usually defined/issued by the facility, -# laboratory, or the principle investigator. -# The identifier enables to link experiments to e.g. proposals. -# -# -# -# -# Free-text description about the experiment. -# -# Users are strongly advised to detail the sample history in the respective -# field and fill rather as completely as possible the fields of this -# application definition rather than write details about the experiment -# into this free-text description field. -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC information included -# when the microscope session started. If the application demands that time -# codes in this section of the application definition should only be used -# for specifying when the experiment was performed - and the exact -# duration is not relevant - this start_time field should be used. -# -# Often though it is useful to specify a time interval by specifying both -# a start_time and an end_time to allow for more detailed bookkeeping and -# interpretation of the experiment. The user should be aware that even -# with having both time instances specified, it may not be possible -# to infer how long the experiment took or for how long data were acquired. -# -# More detailed timing data over the course of the experiment have -# to be collected to compute this. These computations can take -# advantage of individual time stamps in NXevent_data_em instances to -# provide additional pieces of information. -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC included when -# the microscope session ended. -# -# -# -# -# -# -# -# -# -# Binary container for a file or a compressed collection of files which -# can be used to add further descriptions and details to the experiment. -# The container can hold a compressed archive. -# -# -# -# -# A small image that is representative of the entry; this can be an -# image taken from the dataset like a thumbnail of a spectrum. -# A 640 x 480 pixel jpeg image is recommended. -# Adding a scale bar to that image is recommended but not required -# as the main purpose of the thumbnail is to provide e.g. thumbnail -# images for displaying them in data repositories. -# -# -# -# -# -# Contact information and eventually details of at least one person -# involved in the taking of the microscope session. This can be the -# principle investigator who performed this experiment. -# Adding multiple users if relevant is recommended. -# -# -# -# Given (first) name and surname of the user. -# -# -# -# -# Name of the affiliation of the user at the point in time -# when the experiment was performed. -# -# -# -# -# Postal address of the affiliation. -# -# -# -# -# Email address of the user at the point in time when the experiment -# was performed. Writing the most permanently used email is recommended. -# -# -# -# -# Globally unique identifier of the user as offered by services -# like ORCID or ResearcherID. If this field is field the specific service -# should also be written in orcid_platform -# -# -# -# -# Name of the OrcID or ResearcherID where the account -# under orcid is registered. -# -# -# -# -# (Business) (tele)phone number of the user at the point -# in time when the experiment was performed. -# -# -# -# -# Which role does the user have in the place and at the point -# in time when the experiment was performed? Technician operating -# the microscope. Student, postdoc, principle investigator, guest -# are common examples. -# -# -# -# -# Account name that is associated with the user in social media platforms. -# -# -# -# -# Name of the social media platform where the account -# under social_media_name is registered. -# -# -# -# -# -# -# A description of the material characterized in the experiment. -# Sample and specimen are threaded as de facto synonyms. -# -# -# -# A qualifier whether the sample is a real one or a -# virtual one (in a computer simulation) -# -# -# -# -# -# -# -# -# -# Ideally (globally) unique persistent identifier. The name distinguishes -# the specimen from all others and especially the predecessor/origin -# from where the specimen was cut. -# -# This field must not be used for an alias of the sample. -# Instead, use short_title for this, more convenient alias name. -# -# In cases where multiple specimens have been loaded into the microscope -# the name has to identify the specific one, whose results are stored -# by this NXentry, because a single NXentry should be used only for -# the characterization of a single specimen. -# -# Details about the specimen preparation should be stored in the -# sample history. -# -# -# -# -# Ideally, a reference to a (globally) unique persistent identifier, -# representing a data artifact which documents ideally as many details -# of the material, its microstructure, and its thermo-chemo-mechanical -# processing/preparation history as possible. -# -# The sample_history is the record what happened before the specimen -# was placed into the microscope at the beginning of the session. -# -# In the case that such a detailed history of the sample/specimen is not -# available, use this field as a free-text description to specify a -# sub-set of the entire sample history, i.e. what you would consider are -# the key steps and relevant information about the specimen, -# its material, microstructure, thermo-chemo-mechanical processing state, -# and the details of the preparation. -# -# Specific details about eventual physically-connected material like -# embedding resin should be documented ideally also in the sample_history. -# If all fails, the description field can be used but it is strongly -# discouraged because it leads to eventually non-machine-actionable -# data. -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC information -# when the specimen was prepared. -# -# Ideally report the end of the preparation, i.e. the last known time -# the measured specimen surface was actively prepared. Usually this should -# be a part of the sample history, i.e. the sample is imagined handed over -# for analysis. -# -# Knowing when the specimen was exposed to e.g. specific atmosphere is -# especially required for environmentally sensitive material such as -# hydrogen charged specimens or experiments -# including tracers with a short half time. Further time stamps prior -# to preparation_date should better be placed in resources which -# describe the sample_history. -# -# -# -# -# Possibility to give an abbreviation or alias of the specimen name field. -# -# -# -# -# List of comma-separated elements from the periodic table that are -# contained in the sample. If the sample substance has multiple -# components, all elements from each component must be included in -# `atom_types`. -# -# The purpose of the field is to offer materials database systems an -# opportunity to parse the relevant elements without having to interpret -# these from the sample history. -# -# -# -# -# -# (Measured) sample thickness. The information is recorded to qualify -# if the beam used was likely able to shine through the specimen. -# For scanning electron microscopy, in many cases the specimen is much -# thicker than what is illuminatable by the electron beam. -# In this case the value should be set to the actual thickness of -# the specimen viewed for an illumination situation where the nominal -# surface normal of the specimen is parallel to the optical axis. -# -# -# -# -# -# (Measured) density of the specimen. For multi-layered specimens this -# field should only be used to describe the density of the excited -# volume. For scanning electron microscopy the usage of this field is -# discouraged and instead an instance of an :ref:`NXinteraction_vol_em` -# within individual :ref:`NXevent_data_em` instances can provide a much -# better description of the relevant details why one may wish to store -# the density of the specimen. -# -# -# -# -# -# Discouraged free-text field in case properly designed records -# for the sample_history are not available. -# -# -# -# -# -# Hard link to a location in the hierarchy of the NeXus file -# where the data for default plotting are stored. -# -# -# -# -# -# -# -# -# -# -# -# Metadata and numerical data of the microscope and the lab in which it stands. -# -# The em_lab section contains a description of the instrument and its components. -# The component descriptions in this section differ from those inside individual -# NXevent_data_em sections. These event instances take the role of time snapshot. -# For an NXevent_data_em instance users should store only those settings for a -# component which are relevant to understand the current state of the component. -# Here, current means at the point in time, i.e. the time interval, -# which the event represents. -# -# For example it is not relevant to store in each event's electron_source -# group again the details of the gun type and manufacturer but only the -# high-voltage if for that event the high-voltage was different. If for all -# events the high-voltage was the same it is not even necessary to include -# an electron_source section in the event. -# -# Individual sections of specific type should have the following names: -# -# * NXaperture: the name should match with the name of the lens -# * NXlens_em: condenser_lens, objective_lens are commonly used names -# * NXcorrector_cs: device for correcting spherical aberrations -# * NXstage_lab: a collection of component for holding the specimen and -# eventual additional component for applying external stimuli on the sample -# * NXdetector: several possible names like secondary_electron, -# backscattered_electron, direct_electron, ebsd, edx, wds, auger, -# cathodoluminescence, camera, ronchigram -# -# -# -# Given name of the microscope at the hosting institution. This is an alias. -# Examples could be NionHermes, Titan, JEOL, Gemini, etc. -# -# -# -# -# Location of the lab or place where the instrument is installed. -# Using GEOREF is preferred. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If the lens is described at least one of the fields -# voltage, current, or value should be defined. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# If the lens is described at least one of the fields -# voltage, current, or value should be defined. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Description of the type of the detector. -# -# Electron microscopes have typically multiple detectors. -# Different technologies are in use like CCD, scintillator, -# direct electron, CMOS, or image plate to name but a few. -# -# -# -# Instrument-specific alias/name -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# A container for storing a set of NXevent_data_em instances. -# -# An event is a time interval during which the microscope was configured -# in a specific way. The microscope is considered as stable enough during -# this interval that a measurement with one or multiple detectors is -# possible. What constitutes such time interval depends on how the -# microscope is used and which measurements the user would like to perform. -# -# Each NXevent_data_em instance holds one acquisition task with detectors. -# Each NXevent_data_em section contains an em_lab group in which specific -# settings and states of the microscope during the time interval -# can be stored to document the history of states of the microscope over -# the course of the session. -# -# The NXem application definition offers maximal flexibility. -# One extreme could be that the only one NXevent_data_em instance is used -# and this covers the time interval of the entire session at the microscope. -# The other extreme case is that each collection of an image or even -# single spot measurement is defined as an NXevent_data_em instance. -# In this case the em_lab group inside the NXevent_data_em also holds -# the specific time-dependent state of the microscope with which in theory -# all dynamics of the system (if measured) can be captured and documented. -# -# Nowadays microscopes exists for which hard- and software solutions -# enable a tracking of the dynamics of the microscope and the actions -# of the user (such as with solution like AXONSynchronicity from Protochips). -# The NXem application definition can however also be used for less -# complex interaction and lower demands wrt to time tracking activities. -# -# An NXevent_data_em instance holds specific details about how raw data from -# a detector were processed. Raw data may already be post-processed as -# they are accessible only by the control software with after some internal -# processing happened. Nevertheless, these data have to be distinguished from -# post-processed data where e.g. raw data are converted to interpreted -# spectra, or orientation mappings. -# -# This post-processing tasks can be performed (on-the-fly, i.e. during -# acquisition for sure during the microscope session) or afterwards. -# Post-processing is performed with commercial software or various -# types and scripts. -# -# Currently, several specializations of NXimage_set and Nspectrum_set -# are used which store some details of this processing. However, as post- -# processing tasks can be substantially more advanced and involved it -# is clear that data artifacts from the measurement and data artifacts -# generated during post-processing are weakly connected only, maybe -# exclusively by the fact that a complex numerical post-processing workflow -# just takes one raw dataset from an NXevent_data_em instance but generates -# multiple derived data artifacts from this. All these should be described -# as own application definitions and only weak connections should be made -# to an instance of NXem. Instances of NXsubentry is one mechanism in -# NeXus how this can be achieved in the future. -# -# -# -# A container holding a specific result of the measurement and -# eventually metadata how that result was obtained numerically. -# -# NXevent_data_em instances can hold several specific NXimage_em or -# NXspectrum_em instances taken and considered as one event, i.e. -# a point in time when the microscope had the settings specified -# either in NXinstrument or in this NXevent_data_em instance. -# -# The application definition is designed without an explicit need for -# having an NXevent_data_em instance that contains an NXimage_em or -# NXspectra_em instance. Thereby, an NXevent_data_em can also be used -# for just documentation about the specific state of the microscope -# irrespective whether data have been collected during this time interval. -# -# In other words the NXinstrument group details primarily the more -# static settings and components of the microscope as they are found -# by the operator during the session. The NXevent_data_em samples -# the dynamics. -# -# It is not necessary to store data in NXebeam, NXibeam instances -# of NXevent_data_em but in this case it is assumed that the settings -# were constant over the entire course of the microscope session -# and thus all relevant metadata inside the NXinstrument groups -# are sufficient to understand the session. -# -# So far there exists no standard which a majority of the technology -# partners and the materials science electron microscopy community -# have accepted which could be used for a very generic documentation, -# storage and exchange of electron microscope data. Therefore, it is -# still a frequent case that specific files have many fields which cannot -# safely be mapped or interpreted. -# **Therefore, users are always given the advice to keep the vendor files.** -# Working however with these vendor files inside specific software, -# like materials databases, demands for parsers which extract pieces of -# information from the vendor representation (numerical data and metadata) -# and map them on a schema with which the database and its associated -# software tools can work with. -# -# Currently, one would loose immediately track of e.g. provenance and -# the origin of certain data in NXevent_data_em instances unless really -# all data are safely and reliably copied over into an instance of the -# schema. Currently, though, this is sadly effectively prevented in many -# cases as vendors indeed implemented often sophisticated provenance -# and commercial software state tracking tools but these are not yet -# documented covering enough in our opinion so that it is safe to assume -# all vendor field names are known, logically understood, interpretable, -# and thus mappable on a common schema using a controlled common -# vocabulary. -# -# Therefore we encourage user for now to store for each NXimage_set -# or NXspectra_set instance to supply the so-called source of the data. -# This can for instance be the name and hashvalue of the original -# file which was acquired during the microscope session and from which then -# certain details like numerical data and metadata were copied into an -# instance of this schema for the purpose of working with the data in -# e.g. tools offered by research data management (RDM) systems or -# materials database. -# -# During our work on implementing file format/metadata parsers and -# developing this application definition, we realized that **several -# software tools currently do not consistently format critical metadata -# like time-zone-aware timestamps** when events of data collection or -# processing happened. -# -# We would like to encourage the community and especially the vendors -# to work towards a standardization, or at least an open documentation -# of the way how time-zone-aware time data are collected and stored how -# and where during a microscope session and how they end up in files -# and databases with which users interact. -# This would enable to supplement instances of this schema with specific -# time data and assure that these time data can be used to reliably -# contextualize individual datasets and processing steps in materials -# information systems. -# -# For the reason that these measures have not yet been fully taken, -# the start_time and end_time is a recommended option. -# The idea behind these time-zone-aware dates is to identify when -# the data were collected at the microscope but NOT when they were -# transcoded by some software tool(s) while storing the data in an -# instance of this schema. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Annulus inner half angle -# -# -# -# -# Annulus outer half angle -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# +# finally an example how to map e.g. a simple flat schema to NXem: +# https://www.zenodo.org/record/6513745, source path mapped on (->) target path +# for all source paths /SEM/ is the src path prefix +# for all target paths /entry1/ is the trg path prefix +# ID -> experiment_identifier +# External/alias ID -> none +# User -> map on NXuser instances +# Date -> use start_time and end_time respectively +# Affiliation -> map on NXuser instances +# DOIs -> none, map on NXcite instances +# Temperature (of what?) -> be more specific and add as property of group of relevance +# Relative humidity (of what? likely lab like temperature) -> NXsample +# Environmental gas -> NXsample +# Operator -> map on NXuser with specific role +# Instrument ID -> map on best matching field from NXfabrication in em_lab +# Sample ID -> NXsample/identifier +# Parent sample ID -> NXsample/sample_history +# Any dataset to be linked with this experiment (too vague for the I in FAIR) -> none +# Environmental protection during sample processing -> NXsample +# Pre-treatment -> own appdef and connect to NXsample/sample_history +# Measurement position (the example is totally unclear) -> NXstage_lab, coordinate system etc. +# Detector IDs -> NXdetector/identifier +# Accelerating voltage -> electron_source/voltage +# Current -> much more possibilities electron_source and NXoptical_system_em +# Magnification -> use NXoptical_system_em +# Image width -> implicit in roi/NXdata instances +# Image size -> see image width +# Acquisition mode (too vague) -> map on more expressive fields of NXem_base +# Storage tilt (what is this) for tilt see NXstage_lab +# Measurement date (how is it different from Date? +# Comments -> any of the description fields, in both cases not fair +# the respective TEM group has pixel coordinates, which is all much cleaner +# described using NXem_conventions, NXcoordinate_system, etc... \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXem_adf.yaml b/contributed_definitions/nyaml/NXem_adf.yaml new file mode 100644 index 0000000000..b7011639e5 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_adf.yaml @@ -0,0 +1,28 @@ +category: base +doc: | + Base class method-specific for annular dark field imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). Examples can be single point aka spot + measurements, line profiles, or (rectangular) surface mappings. + The latter pattern is the most frequently used. + + For now the base class provides for scans for which the settings, + binning, and energy resolution is the same for each scan point. +symbols: + n_images: | + Number of images in the stack. + n_y: | + Number of pixel per image in the slow direction. + n_x: | + Number of pixel per image in the fast direction. +type: group +NXem_adf(NXem_method): + IMAGE_R_SET(NXimage_r_set): + half_angle_interval(NX_NUMBER): + doc: | + Annulus inner (first value) and outer (second value) half angle. + unit: NX_ANGLE + dim: (2,) + # all information about annular dark field images is composed from + # the NXimage_r_set_em base class diff --git a/contributed_definitions/nyaml/NXem_base.yaml b/contributed_definitions/nyaml/NXem_base.yaml new file mode 100644 index 0000000000..2de8081a8c --- /dev/null +++ b/contributed_definitions/nyaml/NXem_base.yaml @@ -0,0 +1,297 @@ +category: base +# template to be used for an application definition +doc: | + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. + + This base class combines a method-specific and technical-design-level base class + instance to provide a template for storing parameterized descriptions of + pieces of information collected when performing electron microscopy research. + + The base class here shows all possible branches without making any statements + as to which of these have to be used in an instance. Thereby, the base class + provides a template how to name and structure concepts in a hierarchy + to support finding information and reducing the need for renaming and + restructuring information for a research field where many scientists perform + very specific research but who all also share commonalities like usage of + controlled electron beams, a focus on studies of electron beam matter interaction + to explore physical mechanisms and phenomena, or the desire to characterize materials + using electron microscopy. +# flesh out the description of that to read the docs, because currently the +# description on the NeXus front-page is overwhelming +# considering what we learned from the diataxis workshop we write here a +# specification neither a how to nor a tutorial which explains all the context +# because we address here developers of software +type: group +NXem_base(NXroot): + (NXprogram): + doc: | + A collection of all programs and libraries which are considered relevant + to understand with which software tools this NeXus file instance was + generated. Ideally, to enable a binary recreation from the input data. + + Examples include the name and version of the libraries used to write the + instance. Ideally, the software that writes these :ref:`NXprogram` instances + also includes the version of the set of NeXus classes i.e. the specific + set of base classes, application definitions, and contributed definitions + with which the here described concepts can be resolved. + + For the `pynxtools library `_ + which is used by the `NOMAD `_ + research data management system, it makes sense to store e.g. the GitHub + repository commit and respective submodule references used. + # each NeXus file instance should have a default plot + # however as there are cases when this cannot be assured we cannot + # make the default required, one example is e.g. a NeXus instance + # where scientists just store conventions without a default plot + cs_profiling(NXcs_profiling): + doc: | + The configuration of the I/O writer software (e.g. `pynxtools `_) + which was used to generate this NeXus file instance. + (NXentry): # means ENTRY(NXentry) + \@version(NX_CHAR): + doc: | + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + definition(NX_CHAR): + doc: | + NeXus NXDL schema to which this file conforms. + enumeration: [NXem] + experiment_identifier(NXidentifier): + doc: | + Ideally, a (globally) unique persistent identifier + for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an + experiment (see the Cambridge Dictionary experiment: + *a test done in order to find out something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, + or the principle investigator. The identifier enables to link + experiments/simulations to e.g. proposals. + experiment_description(NX_CHAR): + doc: | + Free-text description about the experiment. + + Users are strongly advised to parameterize their description of the + experiment by using the respective base classes instead of writing prose + into this field. + + The reason is that such free-text field is difficult to machine-interpret. + The motivation behind keeping this field for now is to learn through + the information entered in this field in how far the current base + classes are incomplete. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval via setting both + a start_time and an end_time because this enables software tools and + users to collect a more detailed bookkeeping of the experiment. + + The user should be aware that even with having both time instances specified, + it may not be possible to infer how long the experiment took or for how + long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :ref:`NXevent_data_em` instances. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC included when + the microscope session ended. See docstring of the start_time field + to see how the start_time and end_time should be used together. + (NXcite): + (NXprogram): + doc: | + The program and eventual software libraries used with which the + NeXus instance was created. For the NOMAD OASIS research data + management system e.g. pynxtools and eventually all modules + if desired. + # the above-description overwrites the default description of the NXprogram base class + # this is composed from the NXprogram base class + # program: + # \@version: + # \@url: + # NXnote and thumbnail dropped for the reason that these are + # arbitrary binary containers without any clear provenance. + (NXserialized): + doc: | + Possibility to store a collection of data artifacts + associated with the experiment. + # using NXserialized here instead of NXnote as the former is more specific + (NXuser): + doc: | + Contact information and eventually details of at least one person + who performed or was involved in the session. This can be the + principle investigator who performed this experiment or the student + who performed the simulation. + Adding multiple users if relevant is recommended. + name(NX_CHAR): + doc: | + Given (first) name and surname of the user. + affiliation(NX_CHAR): + doc: | + Name of the affiliation of the user at the point in time + when the experiment was performed. + address(NX_CHAR): + doc: | + Postal address of the affiliation. + email(NX_CHAR): + doc: | + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + identifier(NXidentifier): + doc: | + Service as another mean of identification of a user than by the name. + Examples could be details about an ORCID or social media account of + the user. + telephone_number(NX_CHAR): + doc: | + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + role(NX_CHAR): + doc: | + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + sample(NXsample): + # NEW ISSUE: inject the conclusion from the discussion with Andrea + # according to SAMPLE.yaml 0f8df14 2022/06/15 + # ID: -> maps to name + # name: -> short_title + # user: -> not matched right now + # citation: doi ->why relevant, should be solved by RDMS + doc: | + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + method(NX_CHAR): + doc: | + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + enumeration: [experiment, simulation] + # MK:: declared_by_vendor I would rather expect this for a substance + # COMPONENT.yaml + # SUBSTANCE: + # QUANTIFY + identifier(NXidentifier): + doc: | + Ideally, (globally) unique persistent identifier which distinguishes + the specimen from all others and especially the predecessor/origin + from where the specimen was cut. + + This field must not be used for an alias! Instead, use name. + + In cases where multiple specimens were loaded into the microscope, + the identifier has to resolve the specific sample, whose results are + stored by this :ref:`NXentry` instance, because a single NXentry should be + used only for the characterization of a single specimen. + + Details about the specimen preparation should be + stored in resources referring to parent_identifier. + parent_identifier(NXidentifier): + doc: | + Identifier of the sample from which the sample was cut or the string + *None*. The purpose of this field is to support functionalities + for tracking sample provenance via a research data management system. + preparation_date(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Ideally, this + matches the last timestamp that is mentioned in the digital resource + pointed to by parent_identifier. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments including tracers with a + short half time. Additional time stamps prior to preparation_date + should better be placed in resources which describe but which do not pollute + the description here with prose. Resolving these connected pieces of information + is considered within the responsibility of the research data management + system. + name(NX_CHAR): + doc: | + An alias used to refer to the specimen to please readability for humans. + atom_types(NX_CHAR): + doc: | + List of comma-separated elements from the periodic table that are + contained in the sample. If the sample substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer research data management systems an + opportunity to parse the relevant elements without having to interpret + these from the resources pointed to by parent_identifier or walk through + eventually deeply nested groups in data instances. + # NEW ISSUE: use Andrea and MarkusK groups for describing the geometry of the sample + thickness(NX_NUMBER): + doc: | + (Measured) sample thickness. + + The information is recorded to qualify if the beam used was likely + able to shine through the specimen. For scanning electron microscopy, + in many cases the specimen is typically thicker than what is + illuminatable by the electron beam. + + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. + unit: NX_LENGTH + # \@units: nm + # NEW ISSUE: error estimates of the thickness and origin, i.e. how the value was obtained would be useful + # NEW ISSUE: error model + # NEW ISSUE: the KIT/SCC SEM, TEM schemata further qualify samples whether they are conductive e/ibeam sensitive + # etc. The problem with this is that beam sensitivity is too vague but spatiotemporal electron dose integral dependent + # KIT/SCC distinguish further conductivity and magnetic properties. While the motivation is clear, making + # it thus simple is likely problematic when the data entered in such fields remaining qualitative. + # what are good or bad properties, it would make sense though to quantify these values + # this includes the description of eventual plasma cleaning steps, + # just knowing that a sample was plasma cleaned is insufficient, maybe it was not cleaned long enough + # if plasma cleaning is done outside the EM than its certainly history, if it happens inside the EM + # are the ibeam description capabilities not sufficient enough? + density(NX_NUMBER): + # NX_MASS_PER_VOLUME + doc: | + (Measured) density of the specimen. + + For multi-layered specimens this field should only be used to describe + the density of the excited volume. For scanning electron microscopy + the usage of this field is discouraged and instead an instance of an + :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` + instances can provide a cleaner description of the relevant details + why one may wish to store the density of the specimen. + unit: NX_ANY + description: + doc: | + Discouraged free-text field to provide further detail although adding + parent_identifier and having a working research data management system + should provide this contextualization. + # (NXmonitor): + (NXdata): + (NXcoordinate_system_set): + # link to an instance of an NXinstrument but that is anyway specialized for EM + measurement(NXem_msr): + simulation(NXem_sim): + (NXroi): + doc: | + A region-of-interest analyzed either during or after the session + for which specific processed data generated from the measured or the + simulated data are available. + se(NXem_img): + bse(NXem_img): + ebsd(NXem_ebsd): + eds(NXem_eds): + adf(NXem_adf): + eels(NXem_eels): + correlation(NXem_correlation): + # cl(NXem_cl): diff --git a/contributed_definitions/nyaml/NXem_conventions.yaml b/contributed_definitions/nyaml/NXem_conventions.yaml new file mode 100644 index 0000000000..7835d9a654 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_conventions.yaml @@ -0,0 +1,296 @@ +category: base +# symbols: +doc: | + Conventions for rotations and coordinate systems to interpret crystal orientation + and other data and results collected with electron microscopy research. + + Documenting explicitly all used conventions and coordinate systems is + the decisive context whereby many results from electron microscopy are + at all interpretable. + +# This base class provides several sets of such assumptions and conventions. +# Further base classes should be defined when specific techniques and methods +# demand further specifications or have specialized demands. NXem_conventions_ebsd +# is an example for such method-specific base class to summarize key conventions +# for Electron Backscatter Diffraction (EBSD). + +# What is could be a best practice for application definition developers +# who would like to describe an electron microscopy case where multiple +# methods and/or detectors are used. In this case one should define a +# method-specific base class like the template NXem_conventions_ebsd. +# Even though this may come at a cost of some duplicated information where +# the same physical detector is used in different ways, i.e. the signal collect +# from the detector is interpreted in a different way. +# As in most cases established types of signal and thus detectors are used +# (secondary electron, backscattered electron, etc.) one could equally use +# just one NXem_conventions base class instance in an application definition +# and use detector_reference_frame as a template. For each method and detector +# one then creates one NXprocess group named detector_reference_frame1, +# detector_reference_frame2, detector_reference_frame3, and so on and so forth +# and adds inside that NXprocess and use the depends_on field. + +# What is considered best practice in an application definition with multiple +# NXentry instances? In this case each NXentry instance should have an own +# NXspecimen instance and thus the NXem_conventions instance should be place +# inside that NXentry. This enables to group multiple experiments on multiple +# samples together without setting a constraint that in all these instances +# the conventions have to be the same. + +# However, best practice is the conventions should be expressed explicitly +# and they should whenever possible be as simple as possible and as few +# as possible to support users with understanding the content of the application +# definition. +type: group +NXem_conventions(NXobject): + # mandatory information about used or + # assumed reference frame and rotation conventions + rotation_conventions(NXobject): + doc: | + Mathematical conventions and materials-science-specific conventions + required for interpreting every collection of orientation data. + rotation_handedness(NX_CHAR): + doc: | + Convention how a positive rotation angle is defined when viewing + from the end of the rotation unit vector towards its origin, + i.e. in accordance with convention 2 of + DOI: 10.1088/0965-0393/23/8/083501. + Counter_clockwise is equivalent to a right-handed choice. + Clockwise is equivalent to a left-handed choice. + enumeration: [undefined, counter_clockwise, clockwise] + rotation_convention(NX_CHAR): + doc: | + How are rotations interpreted into an orientation + according to convention 3 of + DOI: 10.1088/0965-0393/23/8/083501. + enumeration: [undefined, passive, active] + euler_angle_convention(NX_CHAR): + doc: | + How are Euler angles interpreted given that there are several + choices (e.g. ZXZ, XYZ, etc.) according to convention 4 of + DOI: 10.1088/0965-0393/23/8/083501. + The most frequently used convention is ZXZ which is based on + the work of H.-J. Bunge but other conventions are possible. + enumeration: [undefined, zxz] + axis_angle_convention(NX_CHAR): + doc: | + To which angular range is the rotation angle argument of an + axis-angle pair parameterization constrained according to + convention 5 of DOI: 10.1088/0965-0393/23/8/083501. + enumeration: [undefined, rotation_angle_on_interval_zero_to_pi] + sign_convention(NX_CHAR): + doc: | + Which sign convention is followed when converting orientations + between different parameterizations/representations according + to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. + enumeration: [undefined, p_plus_one, p_minus_one] + processing_reference_frame(NXcoordinate_system): + doc: | + Details about eventually relevant named directions that may + give reasons for anisotropies. The classical example is cold-rolling + where one has to specify which directions (rolling, transverse, and normal) + align how with the direction of the base vectors of the sample_reference_frame. + type(NX_CHAR): + doc: | + Type of coordinate system and reference frame according to + convention 1 of DOI: 10.1088/0965-0393/23/8/083501. + enumeration: [undefined, cartesian] + handedness(NX_CHAR): + doc: | + Handedness of coordinate system. + enumeration: [right_handed, left_handed] + origin(NX_CHAR): + doc: | + Location of the origin of the processing_reference_frame. + This specifies the location Xp = 0, Yp = 0, Zp = 0. + Assume regions-of-interest in this reference frame form a + rectangle or cuboid. + Edges are interpreted by inspecting the direction of their + outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] + x_alias(NX_CHAR): + doc: | + Name or alias assigned to the x-axis base vector, + e.g. rolling direction. + x_direction(NX_CHAR): + doc: | + Direction of the positively pointing x-axis base vector of + the processing_reference_frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. + enumeration: [undefined, north, east, south, west, in, out] + y_alias(NX_CHAR): + doc: | + Name or alias assigned to the y-axis base vector, + e.g. transverse direction. + y_direction(NX_CHAR): + doc: | + Direction of the positively pointing y-axis base vector of + the processing_reference_frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + z_alias(NX_CHAR): + doc: | + Name or alias assigned to the z-axis base vector, + e.g. normal direction. + z_direction(NX_CHAR): + doc: | + Direction of the positively pointing z-axis base vector of + the processing_reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + sample_reference_frame(NXcoordinate_system): + doc: | + Details about the sample/specimen reference frame. + type(NX_CHAR): + doc: | + Type of coordinate system and reference frame according to + convention 1 of DOI: 10.1088/0965-0393/23/8/083501. + The reference frame for the sample surface reference is used for + identifying positions on a (virtual) image which is formed by + information collected from an electron beam scanning the + sample surface. We assume the configuration is inspected by + looking towards the sample surface from a position that is + located behind the detector. + Reference DOI: 10.1016/j.matchar.2016.04.008 + The sample surface reference frame has coordinates Xs, Ys, Zs. + In three dimensions these coordinates are not necessarily + located on the surface of the sample as there are multiple + faces/sides of the sample. Most frequently though the coordinate + system here is used to define the surface which the electron + beam scans. + enumeration: [undefined, cartesian] + handedness(NX_CHAR): + doc: | + Handedness of the coordinate system if it is a Cartesian. + enumeration: [right_handed, left_handed] + origin(NX_CHAR): + doc: | + Location of the origin of the sample surface reference frame. + This specifies the location Xs = 0, Ys = 0, Zs = 0. + Assume regions-of-interest in this reference frame form a + rectangle or cuboid. + Edges are interpreted by inspecting the direction of their + outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] + x_alias(NX_CHAR): + doc: | + Name or alias assigned to the x-axis base vector, + e.g. longest edge. + x_direction(NX_CHAR): + doc: | + Direction of the positively pointing x-axis base vector of + the sample surface reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + enumeration: [undefined, north, east, south, west, in, out] + y_alias(NX_CHAR): + doc: | + Name or alias assigned to the y-axis base vector, + e.g. long edge. + y_direction(NX_CHAR): + doc: | + Direction of the positively pointing y-axis base vector of + the sample surface reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + z_alias(NX_CHAR): + doc: | + Name or alias assigned to the z-axis base vector, + e.g. shortest edge. + z_direction(NX_CHAR): + doc: | + Direction of the positively pointing z-axis base vector of + the sample surface reference frame. We assume the configuration + is inspected by looking towards the sample surface from a position + that is located behind the detector. For further information consult + also the help info for the xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + detector_reference_frameID(NXcoordinate_system): + doc: | + Details about the detector reference frame for a specific detector. + \@depends_on(NX_CHAR): + doc: | + Reference to the specifically named :ref:`NXdetector` instance + for which these conventions in this :ref:`NXprocess` group apply + (e.g. /entry1/instrument/detector1). + type(NX_CHAR): + doc: | + Type of coordinate system/reference frame used for + identifying positions in detector space Xd, Yd, Zd, + according to DOI: 10.1016/j.matchar.2016.04.008. + enumeration: [undefined, cartesian] + handedness(NX_CHAR): + doc: | + Handedness of the coordinate system if it is a Cartesian. + enumeration: [right_handed, left_handed] + origin(NX_CHAR): + doc: | + Where is the origin of the detector space reference + frame located. This is the location of Xd = 0, Yd = 0, Zd = 0. + Assume regions-of-interest in this reference frame form a + rectangle or cuboid. + Edges are interpreted by inspecting the direction of their + outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] + x_alias(NX_CHAR): + doc: | + Name or alias assigned to the x-axis base vector, + e.g. longest edge as some landmark on the detector. + x_direction(NX_CHAR): + doc: | + Direction of the positively pointing x-axis base vector of + the detector space reference frame. We assume the configuration + is inspected by looking towards the sample surface from a + position that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + enumeration: [undefined, north, east, south, west, in, out] + y_alias(NX_CHAR): + doc: | + Name or alias assigned to the x-axis base vector, + e.g. long edge as some landmark on the detector. + y_direction(NX_CHAR): + doc: | + Direction of the positively pointing y-axis base vector of + the detector space reference frame. We assume the configuration + is inspected by looking towards the sample surface from a + position that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + z_alias(NX_CHAR): + doc: | + Name or alias assigned to the x-axis base vector, + e.g. short edge as some landmark on the detector. + z_direction(NX_CHAR): + doc: | + Direction of the positively pointing z-axis base vector of + the detector space reference frame. We assume the configuration + is inspected by looking towards the sample surface from a + position that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + # conventions specific for EBSD + (NXem_conventions_ebsd): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXem_conventions_ebsd.yaml b/contributed_definitions/nyaml/NXem_conventions_ebsd.yaml new file mode 100644 index 0000000000..1ec180e23f --- /dev/null +++ b/contributed_definitions/nyaml/NXem_conventions_ebsd.yaml @@ -0,0 +1,125 @@ +category: base +# symbols: +doc: | + Base class for method-specific conventions EBSD. + + This base class is expected to be used with :ref:`NXem_conventions`. + + This is the main issue which currently is not in all cases documented + and thus limits the interoperability and value of collected EBSD data. + Not communicating EBSD data with such contextual pieces of information + and the use of file formats which do not store this information is the + key unsolved problem. +type: group +NXem_conventions_ebsd(NXem_conventions): + gnomonic_projection_reference_frame(NXcoordinate_system): + doc: | + Details about the gnomonic projection reference frame. + type(NX_CHAR): + doc: | + Type of coordinate system/reference frame used for identifying + positions in the gnomonic projection space Xg, Yg, Zg + according to DOI: 10.1016/j.matchar.2016.04.008. + enumeration: [undefined, cartesian] + handedness(NX_CHAR): + doc: | + Handedness of coordinate system. + enumeration: [right_handed, left_handed] + origin(NX_CHAR): + doc: | + Is the origin of the gnomonic coordinate system located + where we assume the location of the pattern centre. + This is the location Xg = 0, Yg = 0, Zg = 0 according to + reference DOI: 10.1016/j.matchar.2016.04.008. + enumeration: [undefined, in_the_pattern_centre] + x_direction(NX_CHAR): + doc: | + Direction of the positively pointing "gnomomic" x-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + Different tools assume that different strategies can be used + and are perceived as differently convenient to enter + details about coordinate system definitions. In this ELN users + have to possibility to fill in what they assume is sufficient to + define the coordinate system directions unambiguously. + Software which works with this user input needs to offer parsing + capabilities which detect conflicting input and warn accordingly. + enumeration: [undefined, north, east, south, west, in, out] + y_direction(NX_CHAR): + doc: | + Direction of the positively pointing "gnomomic" y-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + z_direction(NX_CHAR): + doc: | + Direction of the positively pointing "gnomomic" z-axis base + vector when viewing how the diffraction pattern looks on the + detector screen. We assume the configuration is inspected by + looking towards the sample surface from a position + that is located behind the detector. + For further information consult also the help info for the + xaxis_direction field. + enumeration: [undefined, north, east, south, west, in, out] + pattern_centre(NXprocess): + doc: | + Details about the definition of the pattern centre + as a special point in the gnomonic projection reference frame. + x_boundary_convention(NX_CHAR): + doc: | + From which border of the EBSP (in the detector reference frame) + is the pattern centre's x-position (PCx) measured? + Keywords assume the region-of-interest is defined by + a rectangle. We observe this rectangle and inspect the + direction of the outer-unit normals to the edges of + this rectangle. + enumeration: [undefined, top, right, bottom, left] + x_normalization_direction(NX_CHAR): + doc: | + In which direction are positive values for PCx measured from + the specified boundary. Keep in mind that the gnomonic space + is in virtually all cases embedded in the detector space. + Specifically, the XgYg plane is defined such that it is + embedded/laying inside the XdYd plane (of the detector + reference frame). + When the normalization direction is the same as e.g. the + detector x-axis direction, we state that we effectively + normalize in fractions of the width of the detector. + + The issue with terms like width and height is that these + degenerate if the detector region-of-interest is square-shaped. + This is why we should better avoid talking about width and height but + state how we would measure distances practically with a ruler and + how we then measure positive distances. + enumeration: [undefined, north, east, south, west] + y_boundary_convention(NX_CHAR): + doc: | + From which border of the EBSP (in the detector reference + frame) is the pattern centre's y-position (PCy) measured? + For further details inspect the help button of + xaxis_boundary_convention. + enumeration: [undefined, top, right, bottom, left] + y_normalization_direction(NX_CHAR): + doc: | + In which direction are positive values for PCy measured from + the specified boundary. + For further details inspect the help button of + xaxis_normalization_direction. + enumeration: [undefined, north, east, south, west] + + # distance_convention: + # doc: | + # How is the third of the three pattern centre parameter values, + # the (distance) parameter DD, normalized. Which convention + # is followed. We are aware that specifying one of the options here + # also implicitly comes with conventions for some of the parameter + # requested in this ELN. For now we would rather like to ask + # the users though to be specific also to learn how such an ELN + # will be used in practice. + # enumeration: [undefined, Bruker, JEOL, FEI, Oxford] diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml new file mode 100644 index 0000000000..2acf65ec86 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_correlation.yaml @@ -0,0 +1,191 @@ +category: base +doc: | + Base class to combine different method-specific data in electron microscopy. + + This base class represent a template for documenting correlations + (spatial, temporal) between different method-specific results. +type: group +NXem_correlation(NXem_method): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + indexing(NXprocess): + doc: | + Details about correlated or logically connected EBSD datasets. + + One important class of such correlated experiments are the so-called + (quasi) in-situ experiments. In this case the same or nearly the same ROI + gets analyzed via a repetitive sequence of thermomechanical treatment, + sample preparation, measurement, on-the-fly-indexing. Phenomena + investigated are recrystallization, strain accumulation, material damage. + Post-processing is required to correlate and reidentify eventual + microstructural features or local ROIs across several orientation maps. + + Another important class of correlated experiments are the so-called + serial-sectioning experiments. Here the same sample is measured + repetitively after polishing each time, to create a stack of + orientation data which can be reconstructed to a + three-dimensional volume ROI. + + Data can be correlated in time, position (spatial), or both (spatiotemporal). + + Spatial correlations between repetitively characterized regions-of-interests + are typically correlated using image registration and alignment algorithms. + For this typically so-called landmarks are used. These can be grains with + a very large size or specific shape, i.e. grains which are qualitatively + different enough to be used as a guide how images are shifted relative to + one another. Other commonly used landmarks are fiducial marks which are + milled into the specimen surface using focus-ion beam milling and/or various + types of indentation methods. + + As far as the same physical region-of-interest is just measured several times, + the additional issue of the depth increment is not a concern. However, correct + assumptions for the depth increment, amount of material removed along the milling + direction is relevant for accurate and precise three-dimensional (serial-sectioning) + correlations. For these studies it can be tricky though to assume or estimate + useful depth increments. Different strategies have been proposed like + calibrations, wedged-shaped landmarks and computer simulation assisted + assumption making. + + Despite the use of landmarks, there are many practical issues which make the + processing of correlations imprecise and inaccurate. Among these are drift + and shift of the specimen, instabilities of the holder, the beam, irrespective + of the source of the drift, charging effects, here specifically causing local + image distortions and rotations which may require special processing algorithms + to reduce such imprecisions. + + Time correlations face all of the above-mentioned issues surplus the challenge + that specific experimental protocols have to be used to ensure the material state + is observed at specific physical time. The example of quasi in-situ characterization + of crystal growth phenomena, a common topic in engineering or modern catalysis research + makes it necessary to consider that e.g. the target value for the desired annealing + temperature is not just gauged based on macroscopic arguments but considers + that transient effects take place. Heating or quenching a sample might thus might + not have been executed under conditions in the interaction volume as they are + documented and/or assumed. + + These issue cause that correlations have an error margin as to how accurately + respective datasets were not only just synced based on the geometry of the + region-of-interests and the time markers but also to asssure which physical + conditions the specimen experienced over the course of the measurements. + + The fourth example of the em_om reference implementation explores the use of the + correlation group with a serial-sectioning datasets that was collected by the + classical Inconel 100 dataset collected by M. D. Uchic and colleagues + (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and + characterization of polycrystalline microstructures using a fib-sem system data set. + Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). + + This dataset was specifically relevant in driving forward the implementation + of the DREAM.3D software. DREAM.3D is an open-source software project for + post-processing and reconstructing, i.e. correlating sets of orientation + microscopy data foremost spatially. One focus of the software is the + (post-)processing of EBSD datasets. Another cutting edge tool with similar + scope but a commercial solution by Bruker is QUBE which was developed by + P. Konijnenberg and coworkers. + + Conceptually, software like DREAM.3D supports users with creating linear + workflows of post-processing tasks. Workflows can be instructed via the + graphical user interface or via so-called pipeline processing via command line + calls. DREAM.3D is especially useful because its internal system documents all + input, output, and parameter of the processing steps. This makes DREAM.3D a + good candidate to interface with tools like em_om parser. Specifically, DREAM.3D + documents numerical results via a customized HDF5 file format called DREAM3D. + Workflow steps and settings are stored as nested dictionaries in JSON syntax + inside a supplementary JSON file or alongside the data in the DREAM3D file. + DREAM.3D has a few hundred algorithms implemented. These are called filters + in DREAM.3D terminology. + + Users configure a workflow which instructs DREAM.3D to send the data through + a chain of predefined and configured filters. Given that for each analysis + the filter is documented via its version tags surplus its parameter and setting + via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file + is possible in an automated manner using a parser. This makes DREAM.3D analyses + repeatable and self-descriptive. A key limitation though is that most frequently + the initial set of input data come from commercial files like ANG. + This missing link between the provenance of these input files, their associated + creation as electron microscope session, is also what NXem_ebsd solves. + + Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that + the DREAM.3D and the em_om parser can work productively together to realize + RDMS-agnostic parsing of serial-section analyses. + + The internal documentation of the DREAM.3D workflow also simplifies the + provenance tracking represented by an instance of NXem_ebsd as not every + intermediate results has to be stored. Therefore, the fourth example + focuses on the key result obtained from DREAM.3D - the reconstructed + and aligned three-dimensional orientation map. + + Usually, this result is the starting point for further post-processing + and characterization of structural features. As here orientation microscopy + is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should + be useful for different characterization methods, such as EBSD, Transmission + Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), + Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) + or open-source implementations of these techniques (such as via pyxem/orix). + + The result of orientation microscopy methods are maps of local orientation + and thermodynamic phase (crystal structure) pieces of information. Virtually + all post-processing of such results for structural features includes again + a workflow of steps which are covered though by the NXms partner application + definition. The respective source of the data in an instance of NXms can + again be a link or reference to an instance of NXem_ebsd to complete the + chain of provenance. + (NXcrystal_structure): + roi(NXdata): + descriptor: + doc: | + Descriptor representing the image contrast. + # \@signal: # data + # \@axes: # [axis_y, axis_x] + # \@axis_x_indices: 0 + # \@axis_y_indices: 1 + # \@signal: + # \@axes: + # \@AXISNAME_indices: + # \@long_name: + title: + doc: | + Title of the default plot. + data(NX_NUMBER): + unit: NX_UNITLESS + doc: | + Descriptor values displaying the ROI. + dim: (n_z, n_y, n_x) + # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name: + doc: | + Descriptor values. + axis_z(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the z-axis. + dim: (n_z,) + \@long_name: + doc: | + Label for the z axis + axis_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the y-axis. + dim: (n_y,) + \@long_name: + doc: | + Label for the y axis + axis_x(NX_NUMBER): + unit: NX_LENGTH + doc: | + Calibrated coordinate along the x-axis. + dim: (n_x,) + \@long_name: + doc: | + Label for the x axis + # NEW ISSUE: implement support for filters eventually many of them + # NEW ISSUE: for now only show that data from DREAM3D can be loaded. + # NEW ISSUE: how to handle landmarks + # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid + # image registration etc. + # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_ebsd.yaml b/contributed_definitions/nyaml/NXem_ebsd.yaml index f2636ed87e..7811a8845d 100644 --- a/contributed_definitions/nyaml/NXem_ebsd.yaml +++ b/contributed_definitions/nyaml/NXem_ebsd.yaml @@ -1,47 +1,71 @@ -category: application - -# what to do when multiple pattern are averaged into one before the beam moves further? +category: base doc: | - Application definition for collecting and indexing Kikuchi pattern into orientation maps. + Base class method-specific for Electron Backscatter Diffraction (EBSD). - This NXem_ebsd application is a proposal how to represent data, metadata, and - connections between these for the research field of electron microscopy. - More specifically, exemplified here for electron backscatter diffraction (EBSD). - The application definition solves two key documentation issues which are missing - so far to document provenance of data and metadata in the field of EBSD. - The application definition can be an example that is relevant for related - workflows in orientation microscopy. + The general procedure of an EBSD experiment is as follows: + Users load the specimen, collect first a coarse image of the surface. + Next, they set an approximate value for the calibrated working distance and + tilt the stage to set the desired diffraction conditions. + + Users then typically configure the microscope for collecting higher quality data + and push in the EBSD detector. Subsequently, they fine tune the illumination + and aberration corrector settings and select one or multiple ROIs for + the microscope to machine off automatically. They configure on-the-fly + indexing parameter and start the measurement queue. + + Nowadays, this is in most cases an automated process. The pattern + collection runs during the allocated microscope session until the + queue finishes or gets interrupted by errors or the next user terminates + sessions which run over time. + + Kikuchi pattern surplus eventually multi-modal detector signals are + collected and usually indexed on-the-fly. Patterns may be stored or not + so one should not assume that raw data are always stored. + + Results are stored in files, which afterwards are typically copied + automatically or manual for archival purposes to certain storage + locations or further consumption. The result of such an EBSD + measurement/experiment is a set of usually proprietary or open files + from technology partners. + + This :ref:`NXem_ebsd` base class is a proposal how to represent method-specific + data, metadata, and connections between these for the research field of + electron microscopy. + + More specifically, exemplified here for electron backscatter diffraction (EBSD) + we show how NeXus can be used to solve two key documentation issues so far + missing in the field of EBSD. Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted - according to the NXem_ebsd application definition) stores the connection between - the microscope session and the key datasets which are considered typically results - of the various processing steps involved when working with EBSD data. + according to NXem_ebsd) stores the connection between the microscope session and + the key datasets which are considered typically results of the various processing + steps involved when working with EBSD data. - Different groups in this application definition make connections to data artifacts - which were collected when working with electron microscopes via the NXem partner - application definition. Using a file which stores information according to the - NXem application definition has the benefit that it connects the sample, references - to the sample processing, the user operating the microscope, details about the - microscope session, and details about the acquistion and eventual indexing of - Kikuchi pattern, associated overview images, like secondary electron or - backscattered electron images of the region-of-interest probed and many - more pieces of information. + Different groups in NXem_ebsd make connections to data artifacts which were collected + when working with electron microscopes via the NXem application definition. + Using a file which stores information according to the NXem application definition + has the benefit that it connects the sample, references to the sample processing, + the user operating the microscope, details about the microscope session, + and details about the acquisition and eventual indexing of Kikuchi pattern, + associated overview images, like secondary electron or backscattered electron + images of the region-of-interest probed and many more pieces of information. - Secondly, this NXem_ebsd application definition connects and stores the conventions - and reference frames which were used and are the key to mathematically correctly - interpret every EBSD result. Otherwise, results would be ripped out of their - context, as it is the situation with many traditional studies where EBSD data were - indexed on-the-fly and shared with the community only via sharing the results file - with some technology-partner-specific file but leaving important conventions out - or relying on the assumptions that colleagues know these even though multiple - definitions are possible. + Secondly, NXem_ebsd connects and stores the conventions and reference frames + which were used and which are the key to a correct mathematical interpretation + of every EBSD result. Otherwise, results would be ripped out of their context, + as it is the current situation with many traditional studies where EBSD data + were indexed on-the-fly and shared with the community only via sharing + the strongly processed results file in some technology-partner-specific file + format but without communicating all conventions or relying on the assumptions + that colleagues likely know these conventions even though multiple definitions + are possible. - This application definition covers experiments with one-, two-dimensional, and - so-called three-dimensional EBSD datasets. The third dimension is either time - (in the case of quasi in-situ experiments) or space (in the case of serial- - sectioning) methods where a combination of mechanical or ion milling is used - repetitively to measure the same region-of-interest at different depth increments. - Material removal can be achieved with electron or ion polishing, using manual + NXem_ebsd covers experiments with one-, two-dimensional, and so-called three- + dimensional EBSD datasets. The third dimension is either time (in the case of + quasi in-situ experiments) or space (in the case of serial-sectioning) methods + where a combination of mechanical or ion milling is used repetitively to measure + the same region-of-interest at different depth increments. Material removal + can be achieved with electron or ion polishing, using manual steps or using automated equipment like a robot system. Three-dimensional experiments require to follow a sequence of specimen, surface @@ -68,3617 +92,324 @@ symbols: n_sc: | Number of scan points. n_z: | - Number of pixel along the slowest changing dimension for a rediscretized, i.e. - standardized default orientation mapping. + Number of pixel along the slowest changing dimension for a rediscretized, + i.e. standardized default plot orientation mapping. n_y: | Number of pixel along slow changing dimension for a rediscretized i.e. - standardized default orientation mapping. + standardized default plot orientation mapping. n_x: | Number of pixel along fast changing dimension for a rediscretized i.e. - standardized default orientation mapping. - -# The respective partner application definition NXxray_fourd -# can be used for storing data and post-processing results of X-ray diffraction -# experiments which can yield also orientation maps in one, two- or three-dimensions. -# These complementary techniques and associated application definitions can be used -# to inform NXms, another partner application definition to NXem_ebsd. NXms describes -# the connection between measured or simulated structural features with a focus of -# the length and time-scale coarser then the atomic scale. The term microstructure -# is used here but is not restricted to features at the micron scale. - -# the IUCr DMI should work on an e.g. NXhedm -# NXem_tkd is not needed as it can be covered by NXem_ebsd as well. -# if we think of the metadata/data graph collected from the microscope session -# documented in NXem there may be only a few relations between nodes of an instance -# of NXem_ebsd and NXem. Key data from NXem which many users would expect to find -# also enumerated in NXem_ebsd could be settings of the microscope, timestamp data -# when tasks were performed at the microscope using which specimen, operated -# and prepared by whom. These latter pieces of information are all available -# in NXem but if we were to make fields in NXem deep inside an instance -# of NXem_event_data required than we factually more and more granularize and -# pull in steps of detailed numerical post-processing which arguably is not -# any longer at all necessarily related to the microscope session. -# We know many cases in EBSD community, see the work of e.g. Marc de Graef's group -# or of Hakon Wiik Anes and Knut Marthinsen who spent much longer with a collected -# dataset in post-processing than collecting it at the microscope. Therefore, we -# need to have the flexibility that documentation of the actual microscope session -# and the post-processing of some of the data therein collected remain coupled -# but not too repetively and with too stiff constraints on the existence of specific -# fields as otherwise there can be contradictions for which NXem_ebsd would no longer -# be applicable when one wishes to remain at the same time conformant with the data -# scheme. -# The idea used here is to use a reference to another NeXus file in the NXem_ebsd -# file instance and the NXem file instance. So far we acknowledge that exporting -# data as an NXem application definition is limited and scientists currently have -# specific file formats from commercial or open-source tools to work with. -# Therefore, we so far model the connections between the application definitions -# as NXprocesses. As soon as NXem is more supported these NXclasses should become -# NXem e.g. though. -# Details about scan positions should not be reproduced unless needed for -# interpolating between results of neighboring scan positions. -# Currently, we suggest to leave the scan positions as closely to where they are -# collected, i.e. inside NXem. -# What this exampe of linking information rather than duplicating shows is that -# somewhat a culture change is needed: Instead of packing everything in one file -# we just need to assure that we have a tool whereby we can follow and inspect a -# set of linked objects if you would like to say so, also having multiple files -# is okay. -# Finally, this application definition makes any assumptions about -# gridding, this enables to handle all sort of scan schemes. -# We follow the argumentation of MTex, in certain cases data will not yield -# fully occupied grids anyway. -# NXem_ebsd could also be useful/used for storing generic simulations of EBSD pattern -# which is one example for simulations of diffractions patterns as they may be observed -# with electron microscopes. In this case, there should be simulation(NXprocess) under this -# the simulation group where one can store the minimum required set of pieces of information -# which comes with every diffraction pattern simulation. -# The main problem is in this case that the simulation group is required but then there must -# either be no measurement group and on_the_fly_indexing group, and eventually calibration ? -# or these groups should be created but remain empty. -# Using the current NeXus appdef design and rules for setting constraints demands that then the -# same appdef should be used for post-processing measured data. So there is a conflict: -# The simulation must not be required and measurement must not be optional. -# Arguably one may call for two application definitions in this case but most constraints and -# concepts would then match those of NXem_ebsd which works again standardization and -# reducing the total number of ontologies. + standardized default plot orientation mapping. type: group -NXem_ebsd(NXobject): - (NXentry): - exists: ['min', '1', 'max', 'unbounded'] - \@version: +NXem_ebsd(NXem_method): + conventions(NXem_conventions): + # either we have simulated data or we have a set of measured data + # in every case data are Kikuchi diffraction pattern and their metadata + measurement(NXprocess): + doc: | + This group documents relevant details about the conditions and the tools + used for measuring a stack of Kikuchi diffraction pattern with an + electron microscope. + + The most frequently collected EBSD data are captured for rectangular + regions-of-interested which are sampled with regular square or + hexagon-shaped pixels. + time(NX_NUMBER): doc: | - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - # NEW ISSUE: FILE or ARTIFACT? - # enumeration: [sha_256_hash] - definition: + Physical time since the beginning of a timestamp that is required to be + same for all experiments in the set. The purpose of this marker is + to identify how all experiments in the set have have to be arranged + sequentially based on the time elapsed. + The time is relevant to sort e.g. experiments of consecutive quasi + in-situ experiments where a measurement was e.g. taken after 0 minutes + of annealing, 30 minutes, 6 hours, or 24 hours of annealing. + unit: NX_TIME + \@depends_on(NX_CHAR): + doc: | + Timestamp relative to which time was counted to aid + converting between time and timestamp. + # (NXtransformations): + # doc: | + # Transformation which details where the region-of-interest described under + # indexing is located in absolute coordinates and rotation with respect + # to which coordinate system. + # pattern_available(NX_BOOLEAN): + # doc: | + # True if pattern were stored and are retrieveable via depends_on or source. + \@depends_on(NX_CHAR): doc: | - NeXus NXDL schema to which this file conforms. - enumeration: [NXem_ebsd] - workflow_identifier: + If available and it is stored in an instance of an application definition + this field gives the path of an :ref:`NXdata` where the pattern are stored. + source(NXserialized): doc: | - Ideally, a (globally) unique persistent identifier - for referring to this workflow. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - workflows/experiments to e.g. proposals. - workflow_description: - exists: optional + Reference (e.g. path and filename) to an existent data artifact which + stores either the measured pattern or input (already processed EBSD data). + simulation(NXprocess): + doc: | + This group documents relevant details about the conditions and the tools + used for simulating a stack of Kikuchi diffraction pattern with some + physical model. + + This group should not be confused with a group named simulation that + is however an instance of NXem_sim. Instead, the simulation group here + should be used if (e.g. instead of a measurement) a stack of pattern + were simulated that one wishes to use for indexing patterns. + + In many practical cases where pattern are analyzed on-the-fly and dictionary + indexing strategies are used, so-called master pattern(s) are used to compare + measured or simulated pattern with the master pattern. In this case, + master pattern are the result of a computer simulation and thus should + be stored using an own properly documented entry within a simulation + group as an instance of :ref:`NXem_sim`. + \@depends_on(NX_CHAR): doc: | - Free-text description about the workflow. - - Users are strongly advised to detail the sample history in the respective - field and fill rather as completely as possible the fields of the application - definition behind instead of filling in these details into the experiment_description - free-text description field. - start_time(NX_DATE_TIME): - exists: recommended + If available and it is stored in an instance of an application definition + this field gives the path of an :ref:`NXimage_r_set_diff` + where the simulated pattern are stored. + source(NXserialized): doc: | - ISO 8601 time code with local time zone offset to UTC information - included when the processing of the workflow started. - If the application demands that time codes in this section of the - application definition should only be used for specifying when the - workflow was executed - and the exact duration is not relevant - - this start_time field should be used. - - Often though it is useful to specify a time interval with specifying - both start_time and end_time to allow for more detailed bookkeeping - and interpretation of the workflow. - end_time(NX_DATE_TIME): - exists: recommended + Reference (e.g. path and filename) to an existent digital resource which + stores either the pattern or input (already processed EBSD data) + which is now processed further as described by this NXem_ebsd instance. + calibration(NXprocess): + doc: | + The EBSD system, including components like the electron gun, pole-piece, + stage tilting, EBSD detector, and the gnomonic projection have to be + calibrated to achieve reliable indexing results. + + Specifically, the gnomonic projection has to be calibrated. + Typically, silicon or quartz crystals are used for this purpose. + + Considering a system is well-calibrated, it is much more frequently the + case in practice that users assume the system is calibrated (and thus usable) + vs. they perform the calibration of the EBSD system. + + In the first case, the user assumes that the principle geometry of the + hardware components and the settings in the control and EBSD pattern + acquisition software has been calibrated. Consequently, users pick from + an existent library of phase candidates, i.e. + :ref:`NXcrystal_structure` instances. Examples are + reflector models as stored in CRY files (HKL/Channel 5/Flamenco). + + In the second case, users calibrate the system during the session + using standards (silicon, quartz, or other common specimens). + There is usually one person in each lab responsible for doing such + calibrations. Often this person or technician is also in charge of + configuring the graphical user interface and software with which most + users control and perform their analyses. + + For EBSD this has key implications: Taking TSL OIM/EDAX as an example, + the conventions how orientations are stored is affected by how the + reference frames are configured and this setup is made at the level + of the GUI software. + + Unfortunately, these pieces of information are not necessarily stored + in the results files. In effect, key conventions become disconnected + from the data so it remains the users' obligation to remember these + settings or write these down in a lab notebook. Otherwise, these metadata + get lost. All these issues are a motivation and problem which + :ref:`NXem_ebsd` solves in that all conventions can be specified explicitly. + \@depends_on(NX_CHAR): doc: | - ISO 8601 time code with local time zone offset to UTC included - when the processing of the workflow ended. - (NXprogram): - exists: ['min', '1', 'max', 'unbounded'] + If available and it is stored in an instance of an application definition + this field gives the path of an :ref:`NXem_msr` where the calibration is + stored. + source(NXserialized): doc: | - Program which was used for creating the file instance which is - formatted according to the NXem_ebsd application definition. - program: - \@version: - (NXuser): - exists: ['min', '0', 'max', 'unbounded'] + Reference to a digital resource where the calibration is stored. + indexing(NXprocess): + doc: | + Indexing is a data processing step performed either after or while + (on-the-fly) the beam scans the specimen. The resulting method is also + known as orientation imaging microscopy (OIM). + + Different algorithms can be used to index EBSD pattern. Common to them + is the computational step where simulated reference pattern are compared + with measured or simulated patterns. These latter patterns are referred + to via the measurement or simulation groups of this base class. + + Quality descriptors are defined based on which an indexing algorithm + yields a quantitative measure of how similar measured and reference + pattern are, and thus if no, one, or multiple so-called solutions + were found. + + Assumed or simulated pattern are simulated using kinematic or dynamical + theory of electron diffraction delivering master pattern. + + The Hough transform is essentially a discretized Radon transform (for details see `M. van Ginkel et al. `_). + Recently, dictionary-based indexing methods are increasingly becoming used + partly driven by the interest to use artificial intelligence algorithms. + source(NXserialized): doc: | - Contact information and eventually details of at least one person - involved in performing the workflow. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is - recommended. - 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. - - # rotation and reference frame conventions - # we assume that the conventions are the same across all experiments and/or - # simulations which this application definition captures - conventions(NXem_ebsd_conventions): - rotation_conventions(NXprocess): - three_dimensional_rotation_handedness: - rotation_convention: - euler_angle_convention: - axis_angle_convention: - orientation_parameterization_sign_convention: - processing_reference_frame(NXprocess): - reference_frame_type: - xaxis_direction: - xaxis_alias: - yaxis_direction: - yaxis_alias: - zaxis_direction: - zaxis_alias: - origin: - sample_reference_frame(NXprocess): - reference_frame_type: - xaxis_direction: - yaxis_direction: - zaxis_direction: - origin: - detector_reference_frame(NXprocess): - reference_frame_type: - xaxis_direction: - yaxis_direction: - zaxis_direction: - origin: - gnomonic_projection_reference_frame(NXprocess): - reference_frame_type: - xaxis_direction: - yaxis_direction: - zaxis_direction: - origin: - pattern_centre(NXprocess): - xaxis_boundary_convention: - xaxis_normalization_direction: - yaxis_boundary_convention: - yaxis_normalization_direction: - - # either we have simulated data or we have a set of measured data - # in every case data are Kikuchi diffraction pattern and their metadata - simulation(NXprocess): - exists: recommended + This group enables to establish a logical connection between previous + processing steps or on-the-fly-performed indexing of the EBSD map. + Typically these processing steps are performed with commercial software. + Therefore, in many cases a results file from this indexing is often + all that is communicated and saved. These are typically files in a format + specific to the instrument and its configuration. + + Typical file formats are CPR/CRC, ANG, OSC, HDF5, H5EBSD, EDAXH5. + method(NX_CHAR): doc: | - Details about simulations for Kikuchi pattern using kinematic or dynamic - diffraction theory. Usually, the output of such computer simulations are - spherical Kikuchi images which only when projected or observed in some - region-of-interest will represent a set of rectangular Kikuchi pattern - with the same rectangular shape and image size. - - Therefore, these pattern should be stored. The spherical diffraction - pattern can be stored as a set of triangulated geodesic meshes. - The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. - - Do not store pattern in the simulation group if they - have been measured are not simulated. - sequence_index(NX_POSINT): - (NXprogram): - exists: ['min', '0', 'max', 'unbounded'] - program: - \@version: - (NXcg_geodesic_mesh): - exists: ['min', '0', 'max', 'unbounded'] - (NXimage_set_em_kikuchi): - stack(NXdata): - \@signal: - \@axes: - \@AXISNAME_indices: - - # \@long_name: - title: - data_counts(NX_NUMBER): - \@long_name: - - # dimensions: - # rank: 3 - # dim: [[1, n_p], [2, n_y], [3, n_x]] - pattern_identifier(NX_UINT): - \@long_name: - - # dimensions: - # rank: 1 - # dim: [[1, n_p]] - axis_y(NX_NUMBER): - \@long_name: - - # dimensions: - # rank: 1 - # dim: [[1, n_y]] - axis_x(NX_NUMBER): - \@long_name: - - # dimensions: - # rank: 1 - # dim: [[1, n_x]] - experiment(NXprocess): - exists: ['min', '0', 'max', 'unbounded'] + Principal algorithm used for indexing. + enumeration: [undefined, hough_transform, dictionary, radon_transform, other] + background_correction(NXprocess): doc: | - The experiment group captures relevant details about the conditions of - and the tools used for collecting the Kikuchi diffraction pattern. - - The most frequently collected EBSD data are captured as rectangular ROIs - composed from square or hexagonally-shaped pixels. Substantially less - frequently, because such experiments are more costly and technically - demanding, correlated experiments are performed. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. Here the same or nearly the same ROI is - analyzed via a cycles of thermomechanical treatment, sample preparation, - measurement, on-the-fly-indexing. Phenomena investigated like this are - recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is repetitively measured - and polished to create a stack of orientation data which can be reconstructed - to a three-dimensional volume ROI. - time(NX_NUMBER): - unit: NX_TIME - exists: optional - doc: | - Physical time since the beginning of a timestamp that is required to be - same for all experiments in the set. The purpose of this marker is - to identify how all experiments in the set have have to be arranged - sequentially based on the time elapsed. - The time is relevant to sort e.g. experiments of consecutive quasi - in-situ experiments where a measurement was e.g. taken after 0 minutes - of annealing, 30 minutes, 6 hours, or 24 hours of annealing. - (NXtransformations): - exists: optional - doc: | - Transformation which details where the region-of-interest described under - indexing is located in absolute coordinates and rotation with respect - to which coordinate system. - calibration(NXprocess): - exists: recommended - - # although one could simulate spherical Kikuchi pattern without modeling the detector system + Details about the background correction applied to each Kikuchi pattern. + binning(NXprocess): + doc: | + Binning i.e. downsampling of the pattern. + parameter(NXprocess): + doc: | + Specific parameter relevant only for certain algorithms used. + phaseID(NXcrystal_structure): + doc: | + Details for each phase used as a model with which the patterns were + indexed. Instances of :ref:`NXcrystal_structure` in this group must + have the group name prefix phase. The identifier in the name is an + integer. We start counting from 1 because the value 0 is reserved for + the special phase that is the null-model, i.e. the null phase, notIndexed. + status(NX_UINT): + doc: | + Which return value did the indexing algorithm yield for each scan point. + Practically useful is to use an uint8 mask. + + * 0 - Not analyzed + * 1 - Too high angular deviation + * 2 - No solution + * 100 - Success + * 255 - Unexpected errors + unit: NX_UNITLESS + dim: (n_sc,) + n_phases_per_scan_point(NX_INT): + doc: | + How many phases i.e. crystal structure models were used to index each + scan point if any? Let's assume an example to explain how this field + should be used: In the simplest case users collected one pattern for + each scan point and have indexed using one phase, i.e. one instance + of an NXem_ebsd_crystal_structure_model. + + In another example users may have skipped some scan points (not indexed) + them at all) and/or used differing numbers of phases for different scan + points. + + The cumulated of this array decodes how phase_identifier and phase_matching + arrays have to be interpreted. In the simplest case (one pattern per scan + point, and all scan points indexed using that same single phase model), + phase_identifier has as many entries as scan points + and phase_matching has also as many entries as scan points. + unit: NX_UNITLESS + dim: (n_sc,) + phase_identifier(NX_INT): + doc: | + The array n_phases_per_scan_point details how the phase_identifier + and the phase_matching arrays have to be interpreted. + + For the example with a single phase phase_identifier has trivial + values either 0 (no solution) or 1 (solution matching + sufficiently significant with the model for phase 1). + + When there are multiple phases, it is possible (although not frequently + needed) that a pattern matches eventually (not equally well) sufficiently + significant with multiple pattern. This can especially happen in cases of + pseudosymmetry and more frequently with an improperly calibrated system + or false or inaccurate phase models e.g. (ferrite, austenite). + Having such field is especially relevant for recent machine learning + or dictionary based indexing schemes because in combination with + phase_matching these fields communicate the results in a model-agnostic + way. + + Depending on the n_phases_per_scan_point value phase_identifier and + phase_matching arrays represent a collection of concatenated tuples, + which are organized in sequence: The solutions for the 0-th scan point, + the 1-th scan point, the n_sc - 1 th scan point and omitting tuples + for those scan points with no phases according to n_phases_per_scan_point + unit: NX_UNITLESS + dim: (i,) + phase_matching(NX_INT): + doc: | + One-dimensional array, pattern by pattern labelling the solutions found. + The array n_phases_per_scan_point has to be specified because it details + how the phase_identifier and the phase_matching arrays have to be interpreted. + See documentation of phase_identifier for further details. + unit: NX_UNITLESS + dim: (i,) + phase_matching_descriptor(NX_CHAR): + doc: | + Phase_matching is a descriptor for how well the solution matches or not. + Examples can be confidence_index, mean_angular_deviation, some AI-based + matching probability (other), i.e. the details are implementation-specific. + enumeration: [undefined, confidence_index, mean_angular_deviation, other] + rotation_set(NXrotation_set): + scan_point_positions(NX_NUMBER): + # we make this only required as people may not yet be so happy with + # having to walk a graph from measurement -> path -> NXevent_data_em + # -> em_lab/ebeam_deflector to retrieve the actual scan positions + # although this would be cleaner, also scan_point_positions could be + # an instance of NXcg_point_set with a depends_on pointing + # to sample_reference_frame + doc: | + Calibrated center positions of each scan point + in the sample surface reference system. + # px is no one of the following two calibrated i) is not px*stepsize or ii) is not px*stepsize + offset + unit: NX_LENGTH + dim: (n_sc, 2) + indexing_rate(NX_NUMBER): + doc: | + Fraction of successfully indexed pattern with a phase + not the null-phase vs the number_of_scan_points. + unit: NX_DIMENSIONLESS + number_of_scan_points(NX_UINT): + doc: | + Number of scan points in the original mapping. + unit: NX_UNITLESS + odf(NXms_odf_set): + pf(NXms_pf_set): + microstructureID(NXms_recon): + # overview over the entire map, rediscretized on a tight aabb + roi(NXdata): + doc: | + An overview of the entire ROI. + descriptor: doc: | - The EBSD system, including components like the electron gun, pole-piece, - stage tilting, EBSD detector, and the gnomonic projection have to be - calibrated to achieve reliable results. Specifically, the gnomonic projection - has to be calibrated. - - In most practical cases, especially in engineering, there is a substantially - larger number of sessions where such a calibrated system is used assuming - that somebody has properly calibrated the system rather than that the user - actively recalibrates it or is even allowed to do so. - Especially the projection geometry has to calibrated which is usually - achieved with measuring silicon, quartz or standards, and comparing - against simulated diffraction pattern. - - In the first case, the user assumes that the principle geometry of the - hardware components and the settings in the control and EBSD pattern - acquisition software are calibrated. Consequently, users pick from an - existent library of phase candidates. One example are the CRY or CIF - files of the classical HKL/Channel 5/Flamenco software products. - Each entry of the library of such phase candidates in this NeXus proposal - is represented by one NXem_ebsd_crystal_structure_model base class. - For each phase an instance of this base class is to be used to store - crystallographic and simulation-relevant data. - - Indexing is a data processing step performed after/during the beam scans - the specimen (depends on configuration). Users load the specimen, and first - collect a coarse image of the surface. Next, an approximate value for the - calibrated working distance is chosen and the stage tilted. - Users then may configure the microscope for collecting higher quality data - and push in the EBSD detector. Subsequently, they fine tune the illumination - and aberration settings and select one or multiple ROIs to machine off. - The on-the-fly indexing parameter are defined and usually the automated - measurement queue started. - - Nowadays, this is usually an automated/unsupervised process. The pattern - collection runs during the allocated session time slot which the user has - booked ends or when the queue finishes prematurely. Kikuchi pattern surplus - eventually multi-modal detector signals are collected and usually indexed - on-the-fly. The Kikuchi patterns may or not be deleted directly after a - solution was found (on-the-fly) so Kikuchi pattern are not always stored. - - Results files are in many labs afterwards copied automatically - for archival purposes to certain storage locations. The result of such an - EBSD measurement/experiment is a set of usually proprietary or open files - from technology partners (microscope and EBSD detector manufacturers). - - In the second case, the system is being calibrated during the session - using standards (silicon, quartz, or other common specimens). - There is usually one person in each lab responsible for doing such - calibrations. Important is that often this person or technician(s) are also - in charge of configuring the graphical user interface and software - with which most users control and perform their analyses. - For EBSD this has key implications because, taking TSL OIM/EDAX as an example, - the conventions how orientations are stored is affected by how reference frames - are set up and this setup is made at the level of the GUI software. - Unfortunately, these pieces of information are not necessarily stored - in the results files. In effect, key conventions become disconnected - from the data so it remains the users personal obligation to remember these - settings, write them down in the lab notebook, or these metadata get lost. - All these issues are a motivation and problem which NXem_ebsd solves. - sequence_index(NX_POSINT): - origin: - doc: | - A link/cross reference to an existent instance of NXem_ebsd with ideally - an associated instance of NXem detailed under measurement which informs - about the calibration procedures. - \@version: - doc: | - Commit identifying this resource. - path: - doc: | - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to the EBSD data (post)-processing workflow - when performing the calibration. - acquisition(NXprocess): - exists: recommended - - # data come from e.g. a Kikuchi pattern simulation! + Descriptor representing the image contrast. + # taking two examples (CTF and H5OINA choked completely of possibility to find s.th. conceptually common to plot + enumeration: [normalized_band_contrast, normalized_confidence_index, normalized_mean_angular_deviation] + # \@signal: # data + # \@axes: # [axis_y, axis_x] + # \@axis_x_indices: 0 + # \@axis_y_indices: 1 + # \@signal: + # \@axes: + # \@AXISNAME_indices: + # \@long_name: + title(NX_CHAR): doc: | - Relevant result of the session at the microscope for this experiment - which enables to connect the measurement of the Kikuchi pattern and - their processing into orientation microscopy maps. - sequence_index(NX_POSINT): - origin: - doc: | - Name or link to an existent instance of an EBSD raw dataset ideally - as an instance of an NXem application definition which has at least - one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. - The path to this instance in the origin has to be specified under path. - - When NXem is not used or the aim is to rather explore first how - community-specific files with EBSD data, such as ANG, CPR, or HDF5- - based formats can be parsed from, inject here the name of that file. - - The em_om parser will currently not interpret the majority of the - many system- and technique-specific metadata which come with the - files from e.g. technology partners. This is because the current - culture in the EBSD community is that many of the metadata fields - are neither in all cases fully documented nor use a standardized - vocabulary although many people understand terms from different - implementations and how these metadata can likely be compared to - one another. - - In addition, it is common practice in the research field of EBSD that - users transcode their raw data into other (often text-based or HDF5) - files with custom formatting to realize an information transfer - between specific software tools including commercial software from - technology partner, custom scripts in Matlab using tools like MTex, - or Python scripting with tools like hyperspy, pyxem, orix, diffsims, - kikuchipy, or EBSD data stack alignment tools like DREAM.3D. - We have opted that in the first iteration this implementation of a - RDMS-agnostic FAIR data schema for EBSD that we discard these metadata - because these ad hoc file formats are not designed to communicate - also specifically and most importantly the eventually different context - of the metadata. - Another reason for this choice was also to emphasize that in fact such - challenges do exist in the community and thus pointing them out may - support the discussion to arrive at eventually more complete solutions. - As developing these solutions should not be our authority and necessarily - demands feedback from the technology partners, we have opted for this - intermediate approach to stimulate discussion. - \@version: - doc: | - Commit or e.g. at least SHA256 checksum identifying this resource. - path: - doc: | - Path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow. - - # base class for indexing methods with relevant vocabulary - indexing(NXprocess): - exists: recommended - - # IPF default plots in this case we need to use simulated Kikuchi pattern as a fallback + Title of the default plot. + data(NX_NUMBER): doc: | - OIM, orientation imaging microscopy. Post-processing of the Kikuchi - patterns to obtain orientation per phase model and scan point. - Fundamentally different algorithms can be used to index EBSD/EBSP pattern. - - Common is that pattern indexing is a computational step of comparing - simulated with measured diffraction pattern. Quality descriptors are defined - based on which an indexing algorithm yields a quantitative measure of - how similar measured and assumed/simulated pattern are, and thus if - no, one, or multiple so-called solutions were found. - - Assumed or simulated pattern use kinematical or dynamical electron - diffraction theory. Hough transform (which is essentially a discretized - Radon transform, for details see e.g A short introduction to the Radon - and Hough transforms and how they relate by M. van Ginkel et al.). - Recently, dictionary-based indexing methods are increasingly becoming used - partly driven by the move to use artificial intelligence algorithms. - - An inspection of publicly available EBSD datasets with an open-source - license which are available on Zenodo was performed prior to implementing - of the associated em_om parser for NXem_ebsd. This analysis revealed that - EBSD data are in most cases stored in two ways: Case one was via a file in - formats from technology partners. Examples are binary formats like OSC, - H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, - CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. - - These files contain some result and metadata to the numerical steps and the - computational workflow which was performed to index Kikuchi pattern - on-the-fly. Examples of metadata include scan point positions, indexing - solutions per scan point, some quality descriptors for the solutions, - as well as crystal structure and phase metadata. - - Case two were raw pattern in some custom format, often text-based with - some but in general no conclusive and interoperable representation of all - relevant metadata. - Often it remains unclear what individual fields and data arrays of these - fields resolve and/or mean conceptually. For some fields, publications were - referred to. However, software tools change over time and thus which specific - data end in a file and which specific conceptual information is behind - these data can change with software versions. - - Other cases were storing results of custom post-processing steps and - associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry - resolving methods, i.e. any sort of prototyping or alternative indexing - strategies so far seem to require some flexibility for implementing - rapid prototypic capabilities. The drawback of this is that such results - come formatted on a case-by-case basis and are thus not interoperable. - - Therefore, we first need to collect how these files have been generated - and which metadata in these files (or database entries) represent - which pieces of information conceptually. Ideally, one would do so by - creating a complete set of information in e.g. an NXem application definition, - such as a log of timestamped events and processing steps, metadata and data. - Eventually even interactions with the graphical user interface of commercial - software during the microscope session should be stored and become a - part of the application definition. - - Such a set of pieces of information could then be used via reading directly - for the NXem application definition. However, in most cases such a data - representation is not available yet. - sequence_index(NX_POSINT): - on_the_fly_indexing(NXprocess): - exists: optional - doc: | - Therefore, the on_the_fly_indexing group stores which source_file contains - the results of the on-the-fly indexing. For commercial systems these files - can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or - database entry which is referred to under origin is the same as the one - under a given acquisition/origin in one of the experiment groups. - This is because some commercial file formats make no clear distinction - between which metadata are acquisition and/or indexing metadata. - (NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - doc: | - Commercial program which was used to index the EBSD data - incrementally after they have been captured and while the - microscope was capturing (on-the-fly). This is the usual - production workflow how EBSD data are collected in - materials engineering, in industry, and academia. - program: - \@version: - origin: - doc: | - Name of the file from which data relevant for creating default plots - were taken in the case that the data in the experiment group were - indexed on-the-fly. - \@version: - doc: | - Hash of that file. - path: - doc: | - TBD, path which resolves which specific NXimage_set_em_kikuchi instance - was used as the raw data to this EBSD data (post)-processing workflow - when performing the calibration. - method: + Descriptor values displaying the ROI. + unit: NX_UNITLESS + dim: (n_y, n_x) + # n_0 slow 2, n_1 fast 1, rgb triplet is fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name(NX_CHAR): doc: | - Principal algorithm used for indexing. - enumeration: [undefined, hough_transform, dictionary, radon_transform, other] - background_correction(NXprocess): - exists: optional - doc: | - Details about the background correction applied to each Kikuchi pattern. - sequence_index(NX_POSINT): - - # for each process the program used - # auto_background_correction: - # static_or_dynamic: - # pattern_averaging(NXprocess): - # doc: | - # Details about how patterns of each scan point are average or how - # pattern from scan points and neighboring scan points are spatially - # averaged (using weighting schemes and e.g. kernels) before these - # patterns are passed to the indexing algorithm. - binning(NXprocess): - exists: optional - doc: | - Binning i.e. downsampling of the pattern. - sequence_index(NX_POSINT): - - # for each process the program used - # mode: - # doc: Free-text description for instrument specific settings - # binning(NX_UINT): ##MK equivalent to pattern height and width? - # doc: | - # How is the camera signal binned. - # First the number of pixel along the slow direction. - # Second the number of pixel along the fast direction. - # unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, 2]] - parameter(NXprocess): - exists: optional - doc: | - Specific parameter relevant only for certain algorithms used - sequence_index(NX_POSINT): - - # mode: - # doc: Which method used to index pattern? - # enumeration: [optimize_bd] # what does optimize_bd mean Oxford? - (NXem_ebsd_crystal_structure_model): - exists: ['min', '1', 'max', 'unbounded'] - crystallographic_database_identifier: - exists: recommended - crystallographic_database: - exists: recommended - unit_cell_abc(NX_FLOAT): - unit_cell_alphabetagamma(NX_FLOAT): - space_group: - exists: recommended - phase_identifier(NX_UINT): - phase_name: - exists: recommended - atom_identifier: - exists: recommended - atom(NX_UINT): - exists: recommended - atom_positions(NX_FLOAT): - exists: recommended - atom_occupancy(NX_FLOAT): - exists: recommended - number_of_planes(NX_UINT): - exists: recommended - plane_miller(NX_NUMBER): - exists: recommended - dspacing(NX_FLOAT): - exists: recommended - relative_intensity(NX_FLOAT): - exists: recommended - - # connection to data collected using kinematic or - # NEW ISSUE: dynamic diffraction theory simulations - - # individual mappings - # (scientists in EBSD consult all sorts of mappings) - # like image_quality map, orientation mapping, ipf mapping, grain mapping - # etc. in fact these could be all the possible mappings which one can - # create with the famous commercial software solutions - # the problem a RDMS cannot understand these mappings unless they - # are standardized in the sense, one has an exchange format whereby - # these mappings can be exported/transcoded from their representation - # in the commercial software, e.g. - # keep in mind, everybody uses the TSL OIM or Bruker AZTec OIM mapping - # but even these two are not directly interoperable, which is why - # they are also not interoperable in some RDMS if one does not come - # up with a way how to go about standardizing their description - # summary(NXdata): - # doc: | - - # data(NX_UINT): - # doc: | - # Status value of each pixel of the orientation mapping. - status(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - Which return value did the indexing algorithm yield for each scan point. - Practically useful is to use an uint8 mask. - - * 0 - Not analyzed - * 1 - Too high angular deviation - * 2 - No solution - * 100 - Success - * 255 - Unexpected errors - dimensions: - rank: 1 - dim: [[1, n_sc]] - - # axis_y(NX_NUMBER): - # doc: | - # Coordinate along the slow direction. - # axis_x(NX_NUMBER): - # doc: | - # Coordinate along the fast direction. - n_phases_per_scan_point(NX_UINT): - exists: recommended - unit: NX_UNITLESS - doc: | - How many phases i.e. crystal structure models were used to index each - scan point if any? Let's assume an example to explain how this field - should be used: In the simplest case users collected one pattern for - each scan point and have indexed using one phase, i.e. one instance - of an NXem_ebsd_crystal_structure_model. - - In another example users may have skipped some scan points (not indexed) - them at all) and/or used differing numbers of phases for different scan - points. - - The cumulated of this array decodes how phase_identifier and phase_matching - arrays have to be interpreted. In the simplest case (one pattern per scan - point, and all scan points indexed using that same single phase model), - phase_identifier has as many entries as scan points - and phase_matching has also as many entries as scan points. - dimensions: - rank: 1 - dim: [[1, n_sc]] - phase_identifier(NX_UINT): - exists: recommended - unit: NX_UNITLESS - doc: | - The array n_phases_per_scan_point details how the phase_identifier - and the phase_matching arrays have to be interpreted. - - For the example with a single phase phase_identifier has trivial - values either 0 (no solution) or 1 (solution matching - sufficiently significant with the model for phase 1). - - When there are multiple phases, it is possible (although not frequently - needed) that a pattern matches eventually (not equally well) sufficiently - significant with multiple pattern. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models e.g. (ferrite, austenite). - Having such field is especially relevant for recent machine learning - or dictionary based indexing schemes because in combination with - phase_matching these fields communicate the results in a model-agnostic - way. - - Depending on the n_phases_per_scan_point value phase_identifier and - phase_matching arrays represent a collection of concatenated tuples, - which are organized in sequence: The solutions for the 0-th scan point, - the 1-th scan point, the n_sc - 1 th scan point and omitting tuples - for those scan points with no phases according to n_phases_per_scan_point - dimensions: - rank: 1 - dim: [[1, i]] - phase_matching(NX_NUMBER): - exists: recommended - unit: NX_UNITLESS - doc: | - One-dimensional array, pattern by pattern labelling the solutions found. - The array n_phases_per_scan_point has to be specified because it details - how the phase_identifier and the phase_matching arrays have to be interpreted. - See documentation of phase_identifier for further details. - dimensions: - rank: 1 - dim: [[1, i]] - phase_matching_descriptor: - exists: recommended - doc: | - Phase_matching is a descriptor for how well the solution matches or not. - Examples can be confidence index (ci), mean angular deviation (mad), - some AI-based matching probability (other), i.e. the details are implementation-specific. - enumeration: [undefined, ci, mad, other] - orientation_parameterization: - exists: recommended - doc: | - How are orientations parameterized? Inspect euler_angle_convention - in case of using euler to clarify the sequence of rotations assumed. - enumeration: [euler, axis_angle, rodrigues, quaternion, homochoric] - orientation(NX_NUMBER): - exists: recommended - unit: NX_ANY - doc: | - Matrix of parameterized orientations identified. The slow dimension - iterates of the individual solutions as defined by n_phases_per_scan_point. - Values for phases without a solution should be correctly identified as - IEEE NaN. - dimensions: - rank: 2 - dim: [[1, i], [2, n_op]] - scan_point_positions(NX_NUMBER): - exists: recommended - unit: NX_LENGTH - - # we make this only required as people may not yet be so happy with - # having to walk a graph from measurement -> path -> NXevent_data_em - # -> em_lab/ebeam_deflector to retrieve the actual scan positions - # although this would be much cleaner - doc: | - Matrix of calibrated centre positions of each scan point - in the sample surface reference system. - dimensions: - rank: 2 - dim: [[1, n_sc], [2, 2]] - - # EW ISSUE: this is in fact a duplicate because if we know th - # path to the measurement we would have available all ebeam_deflector - # settings and thus could identify where the beam was scanning for each - # NXevent_data_em instance, we have even more - - # NEW ISSUE: replace by a more generic pivot table - hit_rate(NX_NUMBER): - exists: optional - unit: NX_DIMENSIONLESS - doc: | - Fraction of successfully indexed pattern - of the set averaged over entire set. - - # candidate for default plot - region_of_interest(NXprocess): - exists: ['min', '1', 'max', '1'] - doc: | - An overview of the entire area which was scanned. - For details about what defines the image contrast - inspect descriptor. - descriptor: - doc: | - Descriptor representing the image contrast. - - # taking two examples (CTF and H5OINA choked completely of possibility to find s.th. conceptually common to plot - enumeration: [normalized_band_contrast, normalized_confidence_index] - roi(NXdata): - doc: | - Container holding a default plot of the region on the sample - investigated with EBSD. - - # \@signal: # data - # \@axes: # [axis_y, axis_x] - # \@axis_x_indices: # 0 - # \@axis_y_indices: # 1 - \@signal: - \@axes: - \@AXISNAME_indices: - - # \@long_name: - title: - data(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Descriptor values displaying the ROI. - dimensions: - rank: 2 - dim: [[1, n_y], [2, n_x]] - - # n_0 slow 2, n_1 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - Signal - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated center of mass of the pixel along the slow axis. - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - doc: | - Label for the y axis - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated center of mass of the pixel along the fast axis. - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - doc: | - Label for the x axis - (NXprocess): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - - The IPF mapping is interpolated from the scan point data mapping - onto a rectangular domain with square pixels and the - orientations colored according to the coloring scheme used in the - respective ipf_color_modelID/program. - - The main purpose of the ipf_mapID group is not to keep raw data or - scan point related data but offer a default way how a research data - management system can display a preview of the dataset so that users - working with the RDMS can get an overview of the dataset. - - This matches the first aim of NXem_ebsd which is foremost to bring - colleagues and users of EBSD together to discuss which pieces of information - need to be stored together. We are convinced a step-by-step design and - community-driven discussion about which pieces of information should - and/or need to be included is a practical strategy to work towards an - interoperable description and data model for exchanging - data from EBSD between different tools and research data management - systems (RDMS). - - With this design the individual RDMS solutions and tools can still continue - to support specific custom data analyses workflow and routes but at least - there is then one common notation of understanding whereby also users - not necessarily expert in all the details of the EBSD story can understand - better these data and thus eventually this can motivate data reuse and - repurposing. - - It is important to mention that we cannot assume, at least for now, - that the parser which writes to an NXem_ebsd-compliant file is also - responsible or capable at all of computing the inverse pole figure - color keys and maps itself. This cannot be assumed working because - this mapping of orientation data uses involved mathematical algorithms - and functions which not every tools used in the EBSD community is capable - of using or is for sure not using in exactly the same way. - - Currently, we assume it is the responsibilty of the tool used which - generated the data under on_the_fly_indexing to compute these - plots and deliver these to the parser. - - Specific case studies have been explored by the experiment team of - Area B of the FAIRmat project to realize and implement such mapping. - - The first case study uses the H5OINA format and the pyxem/orix library. - As orix is a Python library, the coloring is performed by the em_om parser. - - The second case study uses MTex and its EBSD color coding model. - As MTex is a Matlab tool, an intermediate format is written from MTex - first which stores these pieces of information. The parser then pulls - these data from the intermediate Matlab-agnostic representation and - supplements the file with missing pieces of information as it is - required by NXem_ebsd. - - The third case study shows how a generic set of Kikuchi pattern - can be loaded with the em_om parser. The pattern are loaded directly - from a ZIP file and mapped to an simulation image section for now. - - The fourth case study uses the DREAM.3D package which provides an own - set of EBSD data post-processing procedures. DREAM.3D documents the - processing steps with a pipeline file which is stored inside DREAM.3D - output files. In this case study, the parser reads the DREAM.3D file - and maps data relevant from the perspective of NXem_ebsd plus adds - relevant IPF color maps as they were computed by DREAM.3D. - Given that in this case the origin of the data is the DREAM.3D file - again provenance is kept and more details can be followed upon when - resolving origin. - - These examples offer a first set of suggestions on how to make EBSD - data injectable into research data management system using schemes - which themselves are agnostic to the specific RDMS and interoperable. - Steps of collecting the raw data and post-processing these with custom - scripts like MTex or commercial tools so far are mainly undocumented. - The limitation is that a program which consumes results or dump files - from these tools may not have necessarily all the sufficient information - available to check if the injected orientation data and color models - are matching the conventions which a user or automated system has - injected into an electronic lab notebook from which currently the em_om - parser collects the conventions and stores them into this NXem_ebsd instance. - The immediate benefit of the here presented NXem_ebsd concept though - is that the conventions and reference frame definitions are expected - in an ELN-agnostic representation to make NXem_ebsd a generally useful - data scheme for EBSD. - - Ideally, the em_om parser would load convention-compliant EBSD data - and use subsequently a community library to transcode/convert orientation - conventions and parameterized orientation values. Thereafter, convention- - compliant default plot(s) could be created that would be truely interoperable. - - However, given the variety of post-processing tools available surplus - the fact that these are not usually executed along standardized - post-processing workflows which perform exactly the same algorithmic steps, - this is currently not a practically implementable option. Indeed, first - developers who wish to implement this would first have to create a library - for performing such tasks, mapping generally between conventions, - i.e. map and rotate coordinate systems at the parser level. - - The unfortunate situation in EBSD is that due to historical reasons - and competitive strategies, different players in the field have - implemented (slightly) different approaches each of which misses - some part of a complete workflow description which is behind EBSD analyses: - Sample preparation, measurement, indexing, post-processing, paper... - - The here exemplified default plot do not so far apply relevant rotations - but takes the orientation values as they come from the origin and using - coloring them as they come. It is thus the scientists responsibility to - enter and check if the respective dataset is rotation-conventions-wise - consistent and fit for a particular task. - - Ideally, with all conventions defined it can be possible to develop - a converter which rotates the input data. This application definition - does not assume this and users should be aware of this limitation. - - The key point is that the conventions however are captured and this is - the most important step to the development of such a generic transcoder - for creating interoperable EBSD datasets. - - Currently the conventions remain in the mind or manual lab book of the - respective scientists or technicians instead of getting stored and - communicated with research papers that are written based on - specific dataset, i.e. database entries. - - The default gridded representation of the data should not be - misinterpreted as the only possible way how EBSD data and OIM - maps can be created! - - Indeed, the most general case is that patterns are collected for - scan points. The scan generator of an electron microscope is instructed - to steer the beam in such a way across the specimen surface that the - beam illuminates certain positions for a certain amount time (usually - equally-spaced and spending about the same amount of time at each - position). - - Therefore, scan positions can be due to such regular flight plans and - represent sampling on lines, line stacks, rectangular regions-of- - interests, but also could instruct spiral, random, or adaptive scans - instead of tessellations with square or hexagonal pixels. - - The majority of EBSD maps is though is reporting results for a regular - grid (square, hexagon). What matters though in terms of damage induced - by the electron beam and signal quality is the real electron dose - history, i.e. for how long the beam exposed which location of the - specimen. Especially when electron charging occurs (i.e. an excess - amount of charge accumulates due to e.g. poor conducting away of this - charge or an improper mounting, too high dose, etc. such details are - relevant. - - Specifically, the default visualization is an inverse pole-figure (IPF) - map with the usual RGB color coding. Different strategies and - normalization schemes are in use to define such color coding. - - Finally, we should mention that each ipf_map represents data for - scan points indexed as one phase. The alias/name of this phase should - be stored in phase_name, the phase_identifier give an ID which must - not be zero as this value is reserved for non-indexed / null model scan - points. - phase_identifier(NX_UINT): - unit: NX_UNITLESS - doc: | - Specifying which phase this IPF mapping visualizes. - phase_name: - doc: | - Alias/name for the phase whose indexed scan points are displayed. - description: - exists: optional - doc: | - Which IPF definition computation according to backend. - - # AS THE FIRST STEP WE DO NOT IMPLEMENT A GENERIC ORIENTATION AND REFERENCE - # FRAME LIBRARY WHICH CAN TRANSLATE BETWEEN ALL POSSIBLE CONVENTIONS. - # INSTEAD WE TAKE THE RESULTS COMPUTED FROM THE BACKEND THAT IS - # For cpr/crc/ang the pythonEBSD backend - # For other file either MTex or kikuchipy - # For DREAM.3D this is DREAM.3D - # For pyxem following the orix library (which has some, though not yet in - # all details checked links and usage of the orix library because kikuchipy - # is somehow connected to pyxem. NEED TO TALK TO DEVELOPERS HERE! - - # NEW ISSUE: [0, 0, 1] is defined in which coordinate system? - projection_direction(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Along which axis to project? Typically [0, 0, 1] is chosen. - dimensions: - rank: 1 - dim: [[1, 3]] - bitdepth(NX_UINT): - unit: NX_UNITLESS - doc: | - Bitdepth used for the RGB color model. Usually 8 bit. - - # can an NX_UINT have an enumeration? - (NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - doc: | - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - program: - \@version: - - # enumeration: [brinckmann, mtex, kikuchipy, dream3d, orix, tsl] - ipf_rgb_map(NXdata): - doc: | - The RGB image which represents the IPF map. - - # \@signal: # rgb - # \@axes: # [zpos, ypos, xpos] # rgb - # \@rgb_indices: 0 - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - # \@zpos_indices: 2 - \@signal: - \@axes: - \@AXISNAME_indices: - - # \@long_name: - title: - data(NX_UINT): - unit: NX_UNITLESS - doc: | - RGB array, with resolution per fastest changing value - defined by bitdepth. - dimensions: - rank: 3 - dim: [[1, n_y], [2, n_x], [3, 3]] - - # n_p_or_z slow 3, n_y fast 2, n_x faster 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - IPF color-coded orientation mapping - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated center of mass of the pixel along the slow axis. - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - doc: | - Label for the y axis - - # but for h5web RGB we need n_y + 1, was an issue in v6.6.1 - axis_x(NX_NUMBER): - doc: | - Calibrated center of mass of the pixel along the fast axis. - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - doc: | - Label for the x axis - ipf_rgb_color_model(NXdata): - doc: | - For each stereographic standard triangle (SST), i.e. a rendering of - the fundamental zone of the crystal-symmetry-reduced orientation space SO3, - it is possible to define a color model which assigns each point in - the fundamental zone a color. - Different mapping models are in use and implement (slightly) different - scaling relations. Differences are which base colors of the RGB - color model are placed in which extremal position of the SST - and where the white point is located. For further details see: - - * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - * Srikanth Patala and coworkers"'" work and of others. - - Details are implementation-specific and not standardized yet. - Given that the SST has a complicated geometry, it cannot yet be - visualized using tools like H5Web, which is why for now the em_om - parsers takes a rasterized image which is rendered by the backend - tool. - - # \@signal: # rgb - # \@axes: # [ypos, xpos] # rgb - # \@rgb_indices: 0 - # \@axis_x_indices: # 0 - # \@axis_y_indices: # 1 - \@signal: - \@axes: - \@AXISNAME_indices: - - # \@long_name: - title: - data(NX_UINT): - unit: NX_UNITLESS - doc: | - RGB array, with resolution per fastest changing value defined by bitdepth. - dimensions: - rank: 3 - dim: [[1, n_y], [2, n_x], [3, 3]] - - # n_0 slow 2, n_1 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - IPF color key in stereographic standard triangle (SST) - axis_y(NX_NUMBER): - unit: NX_ANY - doc: | - Pixel coordinate along the slow axis. - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - doc: | - Label for the y axis - axis_x(NX_NUMBER): - unit: NX_ANY - doc: | - Pixel coordinate along the fast axis. - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - doc: | - Label for the x axis - correlation(NXprocess): - exists: optional - doc: | - This application definition also enables to describe a workflow where several - EBSD datasets are not only documented but also correlated based on time, - position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - # NEW ISSUE: implement support for filters eventually many of them - # NEW ISSUE: for now only show that data from DREAM3D can be loaded. - # NEW ISSUE: how to handle landmarks - # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid - # image registration etc. - sequence_index(NX_POSINT): - (NXem_ebsd_crystal_structure_model): - exists: ['min', '1', 'max', 'unbounded'] - crystallographic_database_identifier: - exists: recommended - crystallographic_database: - exists: recommended - unit_cell_abc(NX_FLOAT): - unit_cell_alphabetagamma(NX_FLOAT): - space_group: - exists: recommended - phase_identifier(NX_UINT): - phase_name: - exists: recommended - - # candidate for default plot - region_of_interest(NXprocess): - exists: ['min', '1', 'max', '1'] + Descriptor values. + axis_y(NX_NUMBER): doc: | - An overview of the entire reconstructed volume. For details about - what defines the image contrast inspect descriptor. - descriptor: - doc: | - Descriptor representing the image contrast. - - # enumeration: ["normalized_band_contrast", "normalized_confidence_index"] - roi(NXdata): + Calibrated coordinate along the y-axis. + unit: NX_LENGTH + dim: (n_y,) + \@long_name(NX_CHAR): doc: | - Container holding a default plot of the reconstructed volume. - - # \@signal: # data - # \@axes: # [axis_z, axis_y, axis_x] - # \@axis_x_indices: # 0 - # \@axis_y_indices: # 1 - # \@axis_z_indices: # 2 - \@signal: - \@axes: - \@AXISNAME_indices: - - # \@long_name: - title: - data(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Descriptor values displaying the ROI. - dimensions: - rank: 3 - dim: [[1, n_z], [2, n_y], [3, n_x]] - - # n_0 slow 2, n_1 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - Signal - axis_z(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated center of mass of the pixel along the slow axis. - dimensions: - rank: 1 - dim: [[1, n_z]] - \@long_name: - doc: | - Label for the z axis - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated center of mass of the pixel along the fast axis. - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - doc: | - Label for the y axis - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated center of mass of the pixel along the fastest axis. - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - doc: | - Label for the x axis - (NXprocess): - exists: ['min', '0', 'max', 'unbounded'] + Label for the y axis + axis_x(NX_NUMBER): doc: | - Default inverse pole figure (IPF) plot of the data specific for each - phase. No ipf_mapID instances for non-indexed scan points as these are - by definition assigned the null phase with phase_identifier 0. - The same comments apply as to the two-dimensional representation. - phase_identifier(NX_UINT): - unit: NX_UNITLESS - doc: | - Specifying which phase this IPF mapping visualizes. - phase_name: - doc: | - Alias/name for the phase whose indexed scan points are displayed. - description: - exists: optional - doc: | - Which IPF definition computation according to backend. - - # NEW ISSUE: [0, 0, 1] is defined in which coordinate system? - projection_direction(NX_NUMBER): - unit: NX_UNITLESS + Calibrated coordinate along the x-axis. + unit: NX_LENGTH + dim: (n_x,) + \@long_name(NX_CHAR): doc: | - Along which axis to project? Typically [0, 0, 1] is chosen. - dimensions: - rank: 1 - dim: [[1, 3]] - bitdepth(NX_UINT): - unit: NX_UNITLESS - doc: | - Bitdepth used for the RGB color model. Usually 8 bit. - (NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - doc: | - The tool/implementation used for creating the IPF color map from - the orientation data. Effectively, this program is the backend - which performs the computation of the inverse pole figure mappings - which can be for some use cases the parser. - Consider the explanations in the docstring of the ipf_mapID group. - program: - \@version: - - # enumeration: [brinckmann, mtex, kikuchipy, dream3d, orix, tsl] - ipf_rgb_map(NXdata): - doc: | - The RGB image which represents the IPF map. - - # \@signal: # rgb - # \@axes: # [zpos, ypos, xpos] # rgb - # \@rgb_indices: 0 - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - # \@axis_z_indices: 2 - \@signal: - \@axes: - \@AXISNAME_indices: - - # \@long_name: - title: - data(NX_UINT): - unit: NX_UNITLESS - doc: | - RGB array, with resolution per fastest changing value - defined by bitdepth. - dimensions: - rank: 4 - dim: [[1, n_z], [2, n_y], [3, n_x], [4, 3]] - - # n_p_or_z slow 3, n_y fast 2, n_x faster 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - IPF color-coded orientation mapping - axis_z(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated center of mass of the pixel along the slow axis. - dimensions: - rank: 1 - dim: [[1, n_z]] - \@long_name: - doc: | - Label for the z axis - - # but for h5web RGB we need n_z + 1, was an issue in v6.6.1 - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated center of mass of the pixel along the faster axis. - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - doc: | - Label for the y axis - - # but for h5web RGB we need n_y + 1, was an issue in v6.6.1 - axis_x(NX_NUMBER): - doc: | - Calibrated center of mass of the pixel along the fastest axis. - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - doc: | - Label for the x axis - ipf_rgb_color_model(NXdata): - doc: | - Same comments as for the two-dimensional case apply. - - # \@signal: # rgb - # \@axes: # [ypos, xpos] # rgb - # \@rgb_indices: 0 - # \@axis_x_indices: # 0 - # \@axis_y_indices: # 1 - \@signal: - \@axes: - \@AXISNAME_indices: - - # \@long_name: - title: - data(NX_UINT): - unit: NX_UNITLESS - doc: | - RGB array, with resolution per fastest changing value defined by bitdepth. - dimensions: - rank: 3 - dim: [[1, n_y], [2, n_x], [3, 3]] - - # n_0 slow 2, n_1 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - IPF color key in stereographic standard triangle (SST) - axis_y(NX_NUMBER): - unit: NX_ANY - doc: | - Pixel coordinate along the slow axis. - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - doc: | - Label for the y axis - axis_x(NX_NUMBER): - unit: NX_ANY - doc: | - Pixel coordinate along the fast axis. - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - doc: | - Label for the x axis - - # NEW ISSUE: frame averaging - # NEW ISSUE: going towards the level of suggestions what would all be immediately possible - # ebsd_mapping(NXprocess): - # doc: | - # An EBSD mapping is the result of a collecting and indexing of Kikuchi - # pattern, so that for each pattern there is either an associated - # phase_identifier or a status marker stating that no solution was found - # (NXsst_color_model): ##MK - # doc: | - # For each stereographic standard triangle, (fundamental zone) of - # the orientation space, it is possible to define a color model which - # associates an orientation in the fundamental zone to a color. - # For details see: - # * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) - # * Srikanth Patala and coworkers"'" work and of others. - # (NXorientation_set): - # doc: | - # Collection of quaternions in the SO3 fundamental zone with colors and - # rgb(NX_NUMBER): - # doc: RGB colors. - # unit: NX_UNITLESS - # dimensions: [[1, n_oris], [2, 3]] - # hsv and other models - # (NXcg_point_set): - # rgb(NX_NUMBER): - # dimensions: [[1, n_points], [2, 3]] - # mapping(NX_NUMBER): - # doc: | - # The EBSD mapping with colors outlined - # unit: NX_UNITLESS - # dimensions: [[1, n_y], [2, n_x], [3, 3]] - # NEW ISSUE: it would also be possible to define additional color models to overlay - # check n_p vs n_sc vs n_p_or_z - - # confidence_index(NX_FLOAT): - # doc: | - # Is a technology-partner-specific (TSL OIM) AMETEK phase_matching descriptor. - # unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, i]] - # mean_angular_deviation(NX_FLOAT): - # doc: | - # The mean angular deviation is also a technology-partner-specific - # (HKL Channel5) solution-to-reflector matching descriptor. - # unit: NX_ANGLE - # dimensions: - # rank: 1 - # dim: [[1, i]] - # there are many other type of descriptor especially for new machine learning - # type and dictionary type indexing methods - # some descriptors are relevant only for Hough based indexing and technology-partner-specific - # band_count(NX_UINT): - # doc: | - # How many bands were detected in the pattern. - # unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, n_p]] - # band_minimum(NX_UINT): - # doc: | - # Minimum number of bands required to index the pattern - # unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, n_p]] - # band_maximum(NX_UINT): - # doc: | - # Maximum number of bands required to index the pattern - # unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, n_p]] - # resolution(NX_NUMBER): - # doc: | - # Resolution in Hough space. - # unit: NX_ANGLE # or NX_ANY - # band_detection(NXprocess): # for hough_transform - # mode: - # doc: | - # How are Kikuchi bands detected - # enumeration: [center] - # band_contrast(NX_NUMBER): - # doc: | - # Value for band contrast descriptor. - # unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, n_p]] - # band_slope(NX_NUMBER): - # doc: | - # Value for band slope descriptor. - # unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, n_p]] - # centre(NX_FLOAT): - # doc: | - # Pattern centre location used for analyzing each pattern. - # unit: NX_LENGTH - # dimensions: - # rank: 2 - # dim: [[1, n_p], [2, 2]] # what to do when a different one for each pattern seldom but possible - # distance(NX_FLOAT): - # doc: | - # Pattern centre distance used for analyzing each pattern. - # unit: NX_LENGTH - # dimensions: - # rank: 2 - # dim: [[1, n_p], [2, 2]] - # vh_ratio(NX_FLOAT): - # doc: | - # TBD Oxford/HKL Channel 5 CPR files - # unit: NX_DIMENSIONLESS - # how to parameterize a group with value, and descriptor type or a - # field with descriptor type as attribute? - # pattern_quality(NXprocess): - # value(NX_NUMBER): - # doc: | - # Pattern quality descriptor - # unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, n_p]] - # model: - # doc: | - # Model used to describe some aspect of the pattern. - # enumeration: [band_contrast, mean_angular_deviation] - # tilt_angle(NX_FLOAT): - # maybe better make this integrated into the NXtransformations of the stage_lab, a stage_lab event? - # beam_position(NXcg_point_set): - # (NXdetector): - # exposure_time(NX_FLOAT): - # unit: NX_TIME - # gain(NX_FLOAT): - ##MK how does a gain translate mathematically an input signal into an intensity signal? - # insertion_distance(NX_FLOAT): - # unit: NX_LENGTH - ##MK a coordinate system for the detector in the NXcoordinate_system_set - # drift_correction(NX_BOOLEAN): ##MK?? - # move the next two rather to detector - # acquisition_speed(NX_FLOAT): - # doc: | - # Average number of patterns taken per second averaged over entire set. - # unit: NX_FREQUENCY - # acquisition_time(NX_FLOAT): - # doc: Wall-clock time the acquisition took. - # unit: NX_TIME - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 3d31f77ef9a9a8c48c488eef9eb254679ea68be9c7076fec76bc2c700ddfd63b -# -# -# -# -# -# -# -# -# -# Number of arguments per orientation for given parameterization. -# -# -# -# -# Number of scan points. -# -# -# -# -# Number of pixel along the slowest changing dimension for a rediscretized, i.e. -# standardized default orientation mapping. -# -# -# -# -# Number of pixel along slow changing dimension for a rediscretized i.e. -# standardized default orientation mapping. -# -# -# -# -# Number of pixel along fast changing dimension for a rediscretized i.e. -# standardized default orientation mapping. -# -# -# -# -# -# Application definition for collecting and indexing Kikuchi pattern into orientation maps. -# -# This NXem_ebsd application is a proposal how to represent data, metadata, and -# connections between these for the research field of electron microscopy. -# More specifically, exemplified here for electron backscatter diffraction (EBSD). -# The application definition solves two key documentation issues which are missing -# so far to document provenance of data and metadata in the field of EBSD. -# The application definition can be an example that is relevant for related -# workflows in orientation microscopy. -# -# Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted -# according to the NXem_ebsd application definition) stores the connection between -# the microscope session and the key datasets which are considered typically results -# of the various processing steps involved when working with EBSD data. -# -# Different groups in this application definition make connections to data artifacts -# which were collected when working with electron microscopes via the NXem partner -# application definition. Using a file which stores information according to the -# NXem application definition has the benefit that it connects the sample, references -# to the sample processing, the user operating the microscope, details about the -# microscope session, and details about the acquistion and eventual indexing of -# Kikuchi pattern, associated overview images, like secondary electron or -# backscattered electron images of the region-of-interest probed and many -# more pieces of information. -# -# Secondly, this NXem_ebsd application definition connects and stores the conventions -# and reference frames which were used and are the key to mathematically correctly -# interpret every EBSD result. Otherwise, results would be ripped out of their -# context, as it is the situation with many traditional studies where EBSD data were -# indexed on-the-fly and shared with the community only via sharing the results file -# with some technology-partner-specific file but leaving important conventions out -# or relying on the assumptions that colleagues know these even though multiple -# definitions are possible. -# -# This application definition covers experiments with one-, two-dimensional, and -# so-called three-dimensional EBSD datasets. The third dimension is either time -# (in the case of quasi in-situ experiments) or space (in the case of serial- -# sectioning) methods where a combination of mechanical or ion milling is used -# repetitively to measure the same region-of-interest at different depth increments. -# Material removal can be achieved with electron or ion polishing, using manual -# steps or using automated equipment like a robot system. -# -# Three-dimensional experiments require to follow a sequence of specimen, surface -# preparation, and data collection steps. By nature these methods are destructive -# in that they either require the removal of the previously measured material region -# or that the sample surface can degrade due to e.g. contamination or other -# electron-matter interaction. -# -# For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are -# combined into one reconstructed stack. That is serial-sectioning is mainly a -# computational workflow. Users collect data for each serial sectioning step -# via an experiment. This assures that data for associated microscope sessions -# and steps of data processing stay connected and contextualized. -# -# Eventual tomography methods also use such a workflow because first diffraction -# images are collected (e.g. with X-ray) and then these imagres are indexed and -# computed into a 3D orientation mapping. The here proposed NXem_ebsd application -# definition contains conceptual ideas how this splitting between measurement and -# post-processing can be granularized also for such X-ray-based techniques, whether -# it be 3DXRD or HEDM. -# -# -# -# -# An at least as strong as SHA256 hashvalue of the file -# that specifies the application definition. -# -# -# -# -# -# NeXus NXDL schema to which this file conforms. -# -# -# -# -# -# -# -# Ideally, a (globally) unique persistent identifier -# for referring to this workflow. -# -# The identifier is usually defined/issued by the facility, laboratory, -# or the principle investigator. The identifier enables to link -# workflows/experiments to e.g. proposals. -# -# -# -# -# Free-text description about the workflow. -# -# Users are strongly advised to detail the sample history in the respective -# field and fill rather as completely as possible the fields of the application -# definition behind instead of filling in these details into the experiment_description -# free-text description field. -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC information -# included when the processing of the workflow started. -# If the application demands that time codes in this section of the -# application definition should only be used for specifying when the -# workflow was executed - and the exact duration is not relevant -# - this start_time field should be used. -# -# Often though it is useful to specify a time interval with specifying -# both start_time and end_time to allow for more detailed bookkeeping -# and interpretation of the workflow. -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC included -# when the processing of the workflow ended. -# -# -# -# -# Program which was used for creating the file instance which is -# formatted according to the NXem_ebsd application definition. -# -# -# -# -# -# -# -# Contact information and eventually details of at least one person -# involved in performing the workflow. This can be the principle investigator -# who performed this experiment. Adding multiple users if relevant is -# recommended. -# -# -# -# Given (first) name and surname of the user. -# -# -# -# -# Name of the affiliation of the user at the point in time -# when the experiment was performed. -# -# -# -# -# Postal address of the affiliation. -# -# -# -# -# Email address of the user at the point in time when the experiment -# was performed. Writing the most permanently used email is recommended. -# -# -# -# -# Globally unique identifier of the user as offered by services -# like ORCID or ResearcherID. If this field is field the specific -# service should also be written in orcid_platform -# -# -# -# -# Name of the OrcID or ResearcherID where the account -# under orcid is registered. -# -# -# -# -# (Business) (tele)phone number of the user at the point -# in time when the experiment was performed. -# -# -# -# -# Which role does the user have in the place and at the point -# in time when the experiment was performed? Technician operating -# the microscope. Student, postdoc, principle investigator, guest -# are common examples. -# -# -# -# -# Account name that is associated with the user -# in social media platforms. -# -# -# -# -# Name of the social media platform where the account -# under social_media_name is registered. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Details about simulations for Kikuchi pattern using kinematic or dynamic -# diffraction theory. Usually, the output of such computer simulations are -# spherical Kikuchi images which only when projected or observed in some -# region-of-interest will represent a set of rectangular Kikuchi pattern -# with the same rectangular shape and image size. -# -# Therefore, these pattern should be stored. The spherical diffraction -# pattern can be stored as a set of triangulated geodesic meshes. -# The rectangular patterns should be stored as NXimage_set_em_kikuchi stack. -# -# Do not store pattern in the simulation group if they -# have been measured are not simulated. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The experiment group captures relevant details about the conditions of -# and the tools used for collecting the Kikuchi diffraction pattern. -# -# The most frequently collected EBSD data are captured as rectangular ROIs -# composed from square or hexagonally-shaped pixels. Substantially less -# frequently, because such experiments are more costly and technically -# demanding, correlated experiments are performed. -# -# One important class of such correlated experiments are the so-called -# (quasi) in-situ experiments. Here the same or nearly the same ROI is -# analyzed via a cycles of thermomechanical treatment, sample preparation, -# measurement, on-the-fly-indexing. Phenomena investigated like this are -# recrystallization, strain accumulation, material damage. -# Post-processing is required to correlate and reidentify eventual -# features or local ROIs across several orientation maps. -# -# Another important class of correlated experiments are the so-called -# serial-sectioning experiments. Here the same sample is repetitively measured -# and polished to create a stack of orientation data which can be reconstructed -# to a three-dimensional volume ROI. -# -# -# -# Physical time since the beginning of a timestamp that is required to be -# same for all experiments in the set. The purpose of this marker is -# to identify how all experiments in the set have have to be arranged -# sequentially based on the time elapsed. -# The time is relevant to sort e.g. experiments of consecutive quasi -# in-situ experiments where a measurement was e.g. taken after 0 minutes -# of annealing, 30 minutes, 6 hours, or 24 hours of annealing. -# -# -# -# -# Transformation which details where the region-of-interest described under -# indexing is located in absolute coordinates and rotation with respect -# to which coordinate system. -# -# -# -# -# -# The EBSD system, including components like the electron gun, pole-piece, -# stage tilting, EBSD detector, and the gnomonic projection have to be -# calibrated to achieve reliable results. Specifically, the gnomonic projection -# has to be calibrated. -# -# In most practical cases, especially in engineering, there is a substantially -# larger number of sessions where such a calibrated system is used assuming -# that somebody has properly calibrated the system rather than that the user -# actively recalibrates it or is even allowed to do so. -# Especially the projection geometry has to calibrated which is usually -# achieved with measuring silicon, quartz or standards, and comparing -# against simulated diffraction pattern. -# -# In the first case, the user assumes that the principle geometry of the -# hardware components and the settings in the control and EBSD pattern -# acquisition software are calibrated. Consequently, users pick from an -# existent library of phase candidates. One example are the CRY or CIF -# files of the classical HKL/Channel 5/Flamenco software products. -# Each entry of the library of such phase candidates in this NeXus proposal -# is represented by one NXem_ebsd_crystal_structure_model base class. -# For each phase an instance of this base class is to be used to store -# crystallographic and simulation-relevant data. -# -# Indexing is a data processing step performed after/during the beam scans -# the specimen (depends on configuration). Users load the specimen, and first -# collect a coarse image of the surface. Next, an approximate value for the -# calibrated working distance is chosen and the stage tilted. -# Users then may configure the microscope for collecting higher quality data -# and push in the EBSD detector. Subsequently, they fine tune the illumination -# and aberration settings and select one or multiple ROIs to machine off. -# The on-the-fly indexing parameter are defined and usually the automated -# measurement queue started. -# -# Nowadays, this is usually an automated/unsupervised process. The pattern -# collection runs during the allocated session time slot which the user has -# booked ends or when the queue finishes prematurely. Kikuchi pattern surplus -# eventually multi-modal detector signals are collected and usually indexed -# on-the-fly. The Kikuchi patterns may or not be deleted directly after a -# solution was found (on-the-fly) so Kikuchi pattern are not always stored. -# -# Results files are in many labs afterwards copied automatically -# for archival purposes to certain storage locations. The result of such an -# EBSD measurement/experiment is a set of usually proprietary or open files -# from technology partners (microscope and EBSD detector manufacturers). -# -# In the second case, the system is being calibrated during the session -# using standards (silicon, quartz, or other common specimens). -# There is usually one person in each lab responsible for doing such -# calibrations. Important is that often this person or technician(s) are also -# in charge of configuring the graphical user interface and software -# with which most users control and perform their analyses. -# For EBSD this has key implications because, taking TSL OIM/EDAX as an example, -# the conventions how orientations are stored is affected by how reference frames -# are set up and this setup is made at the level of the GUI software. -# Unfortunately, these pieces of information are not necessarily stored -# in the results files. In effect, key conventions become disconnected -# from the data so it remains the users personal obligation to remember these -# settings, write them down in the lab notebook, or these metadata get lost. -# All these issues are a motivation and problem which NXem_ebsd solves. -# -# -# -# -# A link/cross reference to an existent instance of NXem_ebsd with ideally -# an associated instance of NXem detailed under measurement which informs -# about the calibration procedures. -# -# -# -# Commit identifying this resource. -# -# -# -# -# -# Path which resolves which specific NXimage_set_em_kikuchi instance -# was used as the raw data to the EBSD data (post)-processing workflow -# when performing the calibration. -# -# -# -# -# -# -# Relevant result of the session at the microscope for this experiment -# which enables to connect the measurement of the Kikuchi pattern and -# their processing into orientation microscopy maps. -# -# -# -# -# Name or link to an existent instance of an EBSD raw dataset ideally -# as an instance of an NXem application definition which has at least -# one NXimage_set_em_kikuchi instance i.e. one stack of Kikuchi pattern. -# The path to this instance in the origin has to be specified under path. -# -# When NXem is not used or the aim is to rather explore first how -# community-specific files with EBSD data, such as ANG, CPR, or HDF5- -# based formats can be parsed from, inject here the name of that file. -# -# The em_om parser will currently not interpret the majority of the -# many system- and technique-specific metadata which come with the -# files from e.g. technology partners. This is because the current -# culture in the EBSD community is that many of the metadata fields -# are neither in all cases fully documented nor use a standardized -# vocabulary although many people understand terms from different -# implementations and how these metadata can likely be compared to -# one another. -# -# In addition, it is common practice in the research field of EBSD that -# users transcode their raw data into other (often text-based or HDF5) -# files with custom formatting to realize an information transfer -# between specific software tools including commercial software from -# technology partner, custom scripts in Matlab using tools like MTex, -# or Python scripting with tools like hyperspy, pyxem, orix, diffsims, -# kikuchipy, or EBSD data stack alignment tools like DREAM.3D. -# We have opted that in the first iteration this implementation of a -# RDMS-agnostic FAIR data schema for EBSD that we discard these metadata -# because these ad hoc file formats are not designed to communicate -# also specifically and most importantly the eventually different context -# of the metadata. -# Another reason for this choice was also to emphasize that in fact such -# challenges do exist in the community and thus pointing them out may -# support the discussion to arrive at eventually more complete solutions. -# As developing these solutions should not be our authority and necessarily -# demands feedback from the technology partners, we have opted for this -# intermediate approach to stimulate discussion. -# -# -# -# Commit or e.g. at least SHA256 checksum identifying this resource. -# -# -# -# -# -# Path which resolves which specific NXimage_set_em_kikuchi instance -# was used as the raw data to this EBSD data (post)-processing workflow. -# -# -# -# -# -# -# -# OIM, orientation imaging microscopy. Post-processing of the Kikuchi -# patterns to obtain orientation per phase model and scan point. -# Fundamentally different algorithms can be used to index EBSD/EBSP pattern. -# -# Common is that pattern indexing is a computational step of comparing -# simulated with measured diffraction pattern. Quality descriptors are defined -# based on which an indexing algorithm yields a quantitative measure of -# how similar measured and assumed/simulated pattern are, and thus if -# no, one, or multiple so-called solutions were found. -# -# Assumed or simulated pattern use kinematical or dynamical electron -# diffraction theory. Hough transform (which is essentially a discretized -# Radon transform, for details see e.g A short introduction to the Radon -# and Hough transforms and how they relate by M. van Ginkel et al.). -# Recently, dictionary-based indexing methods are increasingly becoming used -# partly driven by the move to use artificial intelligence algorithms. -# -# An inspection of publicly available EBSD datasets with an open-source -# license which are available on Zenodo was performed prior to implementing -# of the associated em_om parser for NXem_ebsd. This analysis revealed that -# EBSD data are in most cases stored in two ways: Case one was via a file in -# formats from technology partners. Examples are binary formats like OSC, -# H5OINA, OIP, EBSP, and many derived text-based formats like CPR, CRC, ANG, -# CTF, HKL and more. Recently, there is trend towards using HDF5-based formats. -# -# These files contain some result and metadata to the numerical steps and the -# computational workflow which was performed to index Kikuchi pattern -# on-the-fly. Examples of metadata include scan point positions, indexing -# solutions per scan point, some quality descriptors for the solutions, -# as well as crystal structure and phase metadata. -# -# Case two were raw pattern in some custom format, often text-based with -# some but in general no conclusive and interoperable representation of all -# relevant metadata. -# Often it remains unclear what individual fields and data arrays of these -# fields resolve and/or mean conceptually. For some fields, publications were -# referred to. However, software tools change over time and thus which specific -# data end in a file and which specific conceptual information is behind -# these data can change with software versions. -# -# Other cases were storing results of custom post-processing steps and -# associated Kikuchi pattern. Testing of advanced indexing, pseudo-symmetry -# resolving methods, i.e. any sort of prototyping or alternative indexing -# strategies so far seem to require some flexibility for implementing -# rapid prototypic capabilities. The drawback of this is that such results -# come formatted on a case-by-case basis and are thus not interoperable. -# -# Therefore, we first need to collect how these files have been generated -# and which metadata in these files (or database entries) represent -# which pieces of information conceptually. Ideally, one would do so by -# creating a complete set of information in e.g. an NXem application definition, -# such as a log of timestamped events and processing steps, metadata and data. -# Eventually even interactions with the graphical user interface of commercial -# software during the microscope session should be stored and become a -# part of the application definition. -# -# Such a set of pieces of information could then be used via reading directly -# for the NXem application definition. However, in most cases such a data -# representation is not available yet. -# -# -# -# -# Therefore, the on_the_fly_indexing group stores which source_file contains -# the results of the on-the-fly indexing. For commercial systems these files -# can be e.g. ANG, CPR/CRC, H5OINA, OSC. It is possible that the file or -# database entry which is referred to under origin is the same as the one -# under a given acquisition/origin in one of the experiment groups. -# This is because some commercial file formats make no clear distinction -# between which metadata are acquisition and/or indexing metadata. -# -# -# -# Commercial program which was used to index the EBSD data -# incrementally after they have been captured and while the -# microscope was capturing (on-the-fly). This is the usual -# production workflow how EBSD data are collected in -# materials engineering, in industry, and academia. -# -# -# -# -# -# -# -# Name of the file from which data relevant for creating default plots -# were taken in the case that the data in the experiment group were -# indexed on-the-fly. -# -# -# -# Hash of that file. -# -# -# -# -# -# TBD, path which resolves which specific NXimage_set_em_kikuchi instance -# was used as the raw data to this EBSD data (post)-processing workflow -# when performing the calibration. -# -# -# -# -# -# Principal algorithm used for indexing. -# -# -# -# -# -# -# -# -# -# -# -# Details about the background correction applied to each Kikuchi pattern. -# -# -# -# -# -# -# Binning i.e. downsampling of the pattern. -# -# -# -# -# -# -# Specific parameter relevant only for certain algorithms used -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Which return value did the indexing algorithm yield for each scan point. -# Practically useful is to use an uint8 mask. -# -# * 0 - Not analyzed -# * 1 - Too high angular deviation -# * 2 - No solution -# * 100 - Success -# * 255 - Unexpected errors -# -# -# -# -# -# -# -# -# How many phases i.e. crystal structure models were used to index each -# scan point if any? Let's assume an example to explain how this field -# should be used: In the simplest case users collected one pattern for -# each scan point and have indexed using one phase, i.e. one instance -# of an NXem_ebsd_crystal_structure_model. -# -# In another example users may have skipped some scan points (not indexed) -# them at all) and/or used differing numbers of phases for different scan -# points. -# -# The cumulated of this array decodes how phase_identifier and phase_matching -# arrays have to be interpreted. In the simplest case (one pattern per scan -# point, and all scan points indexed using that same single phase model), -# phase_identifier has as many entries as scan points -# and phase_matching has also as many entries as scan points. -# -# -# -# -# -# -# -# The array n_phases_per_scan_point details how the phase_identifier -# and the phase_matching arrays have to be interpreted. -# -# For the example with a single phase phase_identifier has trivial -# values either 0 (no solution) or 1 (solution matching -# sufficiently significant with the model for phase 1). -# -# When there are multiple phases, it is possible (although not frequently -# needed) that a pattern matches eventually (not equally well) sufficiently -# significant with multiple pattern. This can especially happen in cases of -# pseudosymmetry and more frequently with an improperly calibrated system -# or false or inaccurate phase models e.g. (ferrite, austenite). -# Having such field is especially relevant for recent machine learning -# or dictionary based indexing schemes because in combination with -# phase_matching these fields communicate the results in a model-agnostic -# way. -# -# Depending on the n_phases_per_scan_point value phase_identifier and -# phase_matching arrays represent a collection of concatenated tuples, -# which are organized in sequence: The solutions for the 0-th scan point, -# the 1-th scan point, the n_sc - 1 th scan point and omitting tuples -# for those scan points with no phases according to n_phases_per_scan_point -# -# -# -# -# -# -# -# One-dimensional array, pattern by pattern labelling the solutions found. -# The array n_phases_per_scan_point has to be specified because it details -# how the phase_identifier and the phase_matching arrays have to be interpreted. -# See documentation of phase_identifier for further details. -# -# -# -# -# -# -# -# Phase_matching is a descriptor for how well the solution matches or not. -# Examples can be confidence index (ci), mean angular deviation (mad), -# some AI-based matching probability (other), i.e. the details are implementation-specific. -# -# -# -# -# -# -# -# -# -# -# How are orientations parameterized? Inspect euler_angle_convention -# in case of using euler to clarify the sequence of rotations assumed. -# -# -# -# -# -# -# -# -# -# -# -# Matrix of parameterized orientations identified. The slow dimension -# iterates of the individual solutions as defined by n_phases_per_scan_point. -# Values for phases without a solution should be correctly identified as -# IEEE NaN. -# -# -# -# -# -# -# -# -# -# Matrix of calibrated centre positions of each scan point -# in the sample surface reference system. -# -# -# -# -# -# -# -# -# -# -# Fraction of successfully indexed pattern -# of the set averaged over entire set. -# -# -# -# -# -# An overview of the entire area which was scanned. -# For details about what defines the image contrast -# inspect descriptor. -# -# -# -# Descriptor representing the image contrast. -# -# -# -# -# -# -# -# -# -# Container holding a default plot of the region on the sample -# investigated with EBSD. -# -# -# -# -# -# -# -# -# -# Descriptor values displaying the ROI. -# -# -# -# -# -# -# -# -# Signal -# -# -# -# -# -# Calibrated center of mass of the pixel along the slow axis. -# -# -# -# -# -# -# Label for the y axis -# -# -# -# -# -# Calibrated center of mass of the pixel along the fast axis. -# -# -# -# -# -# -# Label for the x axis -# -# -# -# -# -# -# -# Default inverse pole figure (IPF) plot of the data specific for each -# phase. No ipf_mapID instances for non-indexed scan points as these are -# by definition assigned the null phase with phase_identifier 0. -# -# The IPF mapping is interpolated from the scan point data mapping -# onto a rectangular domain with square pixels and the -# orientations colored according to the coloring scheme used in the -# respective ipf_color_modelID/program. -# -# The main purpose of the ipf_mapID group is not to keep raw data or -# scan point related data but offer a default way how a research data -# management system can display a preview of the dataset so that users -# working with the RDMS can get an overview of the dataset. -# -# This matches the first aim of NXem_ebsd which is foremost to bring -# colleagues and users of EBSD together to discuss which pieces of information -# need to be stored together. We are convinced a step-by-step design and -# community-driven discussion about which pieces of information should -# and/or need to be included is a practical strategy to work towards an -# interoperable description and data model for exchanging -# data from EBSD between different tools and research data management -# systems (RDMS). -# -# With this design the individual RDMS solutions and tools can still continue -# to support specific custom data analyses workflow and routes but at least -# there is then one common notation of understanding whereby also users -# not necessarily expert in all the details of the EBSD story can understand -# better these data and thus eventually this can motivate data reuse and -# repurposing. -# -# It is important to mention that we cannot assume, at least for now, -# that the parser which writes to an NXem_ebsd-compliant file is also -# responsible or capable at all of computing the inverse pole figure -# color keys and maps itself. This cannot be assumed working because -# this mapping of orientation data uses involved mathematical algorithms -# and functions which not every tools used in the EBSD community is capable -# of using or is for sure not using in exactly the same way. -# -# Currently, we assume it is the responsibilty of the tool used which -# generated the data under on_the_fly_indexing to compute these -# plots and deliver these to the parser. -# -# Specific case studies have been explored by the experiment team of -# Area B of the FAIRmat project to realize and implement such mapping. -# -# The first case study uses the H5OINA format and the pyxem/orix library. -# As orix is a Python library, the coloring is performed by the em_om parser. -# -# The second case study uses MTex and its EBSD color coding model. -# As MTex is a Matlab tool, an intermediate format is written from MTex -# first which stores these pieces of information. The parser then pulls -# these data from the intermediate Matlab-agnostic representation and -# supplements the file with missing pieces of information as it is -# required by NXem_ebsd. -# -# The third case study shows how a generic set of Kikuchi pattern -# can be loaded with the em_om parser. The pattern are loaded directly -# from a ZIP file and mapped to an simulation image section for now. -# -# The fourth case study uses the DREAM.3D package which provides an own -# set of EBSD data post-processing procedures. DREAM.3D documents the -# processing steps with a pipeline file which is stored inside DREAM.3D -# output files. In this case study, the parser reads the DREAM.3D file -# and maps data relevant from the perspective of NXem_ebsd plus adds -# relevant IPF color maps as they were computed by DREAM.3D. -# Given that in this case the origin of the data is the DREAM.3D file -# again provenance is kept and more details can be followed upon when -# resolving origin. -# -# These examples offer a first set of suggestions on how to make EBSD -# data injectable into research data management system using schemes -# which themselves are agnostic to the specific RDMS and interoperable. -# Steps of collecting the raw data and post-processing these with custom -# scripts like MTex or commercial tools so far are mainly undocumented. -# The limitation is that a program which consumes results or dump files -# from these tools may not have necessarily all the sufficient information -# available to check if the injected orientation data and color models -# are matching the conventions which a user or automated system has -# injected into an electronic lab notebook from which currently the em_om -# parser collects the conventions and stores them into this NXem_ebsd instance. -# The immediate benefit of the here presented NXem_ebsd concept though -# is that the conventions and reference frame definitions are expected -# in an ELN-agnostic representation to make NXem_ebsd a generally useful -# data scheme for EBSD. -# -# Ideally, the em_om parser would load convention-compliant EBSD data -# and use subsequently a community library to transcode/convert orientation -# conventions and parameterized orientation values. Thereafter, convention- -# compliant default plot(s) could be created that would be truely interoperable. -# -# However, given the variety of post-processing tools available surplus -# the fact that these are not usually executed along standardized -# post-processing workflows which perform exactly the same algorithmic steps, -# this is currently not a practically implementable option. Indeed, first -# developers who wish to implement this would first have to create a library -# for performing such tasks, mapping generally between conventions, -# i.e. map and rotate coordinate systems at the parser level. -# -# The unfortunate situation in EBSD is that due to historical reasons -# and competitive strategies, different players in the field have -# implemented (slightly) different approaches each of which misses -# some part of a complete workflow description which is behind EBSD analyses: -# Sample preparation, measurement, indexing, post-processing, paper... -# -# The here exemplified default plot do not so far apply relevant rotations -# but takes the orientation values as they come from the origin and using -# coloring them as they come. It is thus the scientists responsibility to -# enter and check if the respective dataset is rotation-conventions-wise -# consistent and fit for a particular task. -# -# Ideally, with all conventions defined it can be possible to develop -# a converter which rotates the input data. This application definition -# does not assume this and users should be aware of this limitation. -# -# The key point is that the conventions however are captured and this is -# the most important step to the development of such a generic transcoder -# for creating interoperable EBSD datasets. -# -# Currently the conventions remain in the mind or manual lab book of the -# respective scientists or technicians instead of getting stored and -# communicated with research papers that are written based on -# specific dataset, i.e. database entries. -# -# The default gridded representation of the data should not be -# misinterpreted as the only possible way how EBSD data and OIM -# maps can be created! -# -# Indeed, the most general case is that patterns are collected for -# scan points. The scan generator of an electron microscope is instructed -# to steer the beam in such a way across the specimen surface that the -# beam illuminates certain positions for a certain amount time (usually -# equally-spaced and spending about the same amount of time at each -# position). -# -# Therefore, scan positions can be due to such regular flight plans and -# represent sampling on lines, line stacks, rectangular regions-of- -# interests, but also could instruct spiral, random, or adaptive scans -# instead of tessellations with square or hexagonal pixels. -# -# The majority of EBSD maps is though is reporting results for a regular -# grid (square, hexagon). What matters though in terms of damage induced -# by the electron beam and signal quality is the real electron dose -# history, i.e. for how long the beam exposed which location of the -# specimen. Especially when electron charging occurs (i.e. an excess -# amount of charge accumulates due to e.g. poor conducting away of this -# charge or an improper mounting, too high dose, etc. such details are -# relevant. -# -# Specifically, the default visualization is an inverse pole-figure (IPF) -# map with the usual RGB color coding. Different strategies and -# normalization schemes are in use to define such color coding. -# -# Finally, we should mention that each ipf_map represents data for -# scan points indexed as one phase. The alias/name of this phase should -# be stored in phase_name, the phase_identifier give an ID which must -# not be zero as this value is reserved for non-indexed / null model scan -# points. -# -# -# -# Specifying which phase this IPF mapping visualizes. -# -# -# -# -# Alias/name for the phase whose indexed scan points are displayed. -# -# -# -# -# Which IPF definition computation according to backend. -# -# -# -# -# -# -# Along which axis to project? Typically [0, 0, 1] is chosen. -# -# -# -# -# -# -# -# Bitdepth used for the RGB color model. Usually 8 bit. -# -# -# -# -# -# The tool/implementation used for creating the IPF color map from -# the orientation data. Effectively, this program is the backend -# which performs the computation of the inverse pole figure mappings -# which can be for some use cases the parser. -# Consider the explanations in the docstring of the ipf_mapID group. -# -# -# -# -# -# -# -# -# The RGB image which represents the IPF map. -# -# -# -# -# -# -# -# -# -# RGB array, with resolution per fastest changing value -# defined by bitdepth. -# -# -# -# -# -# -# -# -# -# IPF color-coded orientation mapping -# -# -# -# -# -# Calibrated center of mass of the pixel along the slow axis. -# -# -# -# -# -# -# Label for the y axis -# -# -# -# -# -# -# Calibrated center of mass of the pixel along the fast axis. -# -# -# -# -# -# -# Label for the x axis -# -# -# -# -# -# -# For each stereographic standard triangle (SST), i.e. a rendering of -# the fundamental zone of the crystal-symmetry-reduced orientation space SO3, -# it is possible to define a color model which assigns each point in -# the fundamental zone a color. -# Different mapping models are in use and implement (slightly) different -# scaling relations. Differences are which base colors of the RGB -# color model are placed in which extremal position of the SST -# and where the white point is located. For further details see: -# -# * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) -# * Srikanth Patala and coworkers"'" work and of others. -# -# Details are implementation-specific and not standardized yet. -# Given that the SST has a complicated geometry, it cannot yet be -# visualized using tools like H5Web, which is why for now the em_om -# parsers takes a rasterized image which is rendered by the backend -# tool. -# -# -# -# -# -# -# -# -# -# RGB array, with resolution per fastest changing value defined by bitdepth. -# -# -# -# -# -# -# -# -# -# IPF color key in stereographic standard triangle (SST) -# -# -# -# -# -# Pixel coordinate along the slow axis. -# -# -# -# -# -# -# Label for the y axis -# -# -# -# -# -# Pixel coordinate along the fast axis. -# -# -# -# -# -# -# Label for the x axis -# -# -# -# -# -# -# -# -# -# This application definition also enables to describe a workflow where several -# EBSD datasets are not only documented but also correlated based on time, -# position (spatial), or both (spatiotemporal). -# -# Spatial correlations between repetitively characterized regions-of-interests -# are typically correlated using image registration and alignment algorithms. -# For this typically so-called landmarks are used. These can be grains with -# a very large size or specific shape, i.e. grains which are qualitatively -# different enough to be used as a guide how images are shifted relative to -# one another. Other commonly used landmarks are fiducial marks which are -# milled into the specimen surface using focus-ion beam milling and/or various -# types of indentation methods. -# -# As far as the same physical region-of-interest is just measured several times, -# the additional issue of the depth increment is not a concern. However, correct -# assumptions for the depth increment, amount of material removed along the milling -# direction is relevant for accurate and precise three-dimensional (serial-sectioning) -# correlations. For these studies it can be tricky though to assume or estimate -# useful depth increments. Different strategies have been proposed like -# calibrations, wedged-shaped landmarks and computer simulation assisted -# assumption making. -# -# Despite the use of landmarks, there are many practical issues which make the -# processing of correlations imprecise and inaccurate. Among these are drift -# and shift of the specimen, instabilities of the holder, the beam, irrespective -# of the source of the drift, charging effects, here specifically causing local -# image distortions and rotations which may require special processing algorithms -# to reduce such imprecisions. -# -# Time correlations face all of the above-mentioned issues surplus the challenge -# that specific experimental protocols have to be used to ensure the material state -# is observed at specific physical time. The example of quasi in-situ characterization -# of crystal growth phenomena, a common topic in engineering or modern catalysis research -# makes it necessary to consider that e.g. the target value for the desired annealing -# temperature is not just gauged based on macroscopic arguments but considers -# that transient effects take place. Heating or quenching a sample might thus might -# not have been executed under conditions in the interaction volume as they are -# documented and/or assumed. -# -# These issue cause that correlations have an error margin as to how accurately -# respective datasets were not only just synced based on the geometry of the -# region-of-interests and the time markers but also to asssure which physical -# conditions the specimen experienced over the course of the measurements. -# -# The fourth example of the em_om reference implementation explores the use of the -# correlation group with a serial-sectioning datasets that was collected by the -# classical Inconel 100 dataset collected by M. D. Uchic and colleagues -# (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and -# characterization of polycrystalline microstructures using a fib-sem system data set. -# Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). -# -# This dataset was specifically relevant in driving forward the implementation -# of the DREAM.3D software. DREAM.3D is an open-source software project for -# post-processing and reconstructing, i.e. correlating sets of orientation -# microscopy data foremost spatially. One focus of the software is the -# (post-)processing of EBSD datasets. Another cutting edge tool with similar -# scope but a commercial solution by Bruker is QUBE which was developed by -# P. Konijnenberg and coworkers. -# -# Conceptually, software like DREAM.3D supports users with creating linear -# workflows of post-processing tasks. Workflows can be instructed via the -# graphical user interface or via so-called pipeline processing via command line -# calls. DREAM.3D is especially useful because its internal system documents all -# input, output, and parameter of the processing steps. This makes DREAM.3D a -# good candidate to interface with tools like em_om parser. Specifically, DREAM.3D -# documents numerical results via a customized HDF5 file format called DREAM3D. -# Workflow steps and settings are stored as nested dictionaries in JSON syntax -# inside a supplementary JSON file or alongside the data in the DREAM3D file. -# DREAM.3D has a few hundred algorithms implemented. These are called filters -# in DREAM.3D terminology. -# -# Users configure a workflow which instructs DREAM.3D to send the data through -# a chain of predefined and configured filters. Given that for each analysis -# the filter is documented via its version tags surplus its parameter and setting -# via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file -# is possible in an automated manner using a parser. This makes DREAM.3D analyses -# repeatable and self-descriptive. A key limitation though is that most frequently -# the initial set of input data come from commercial files like ANG. -# This missing link between the provenance of these input files, their associated -# creation as electron microscope session, is also what NXem_ebsd solves. -# -# Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that -# the DREAM.3D and the em_om parser can work productively together to realize -# RDMS-agnostic parsing of serial-section analyses. -# -# The internal documentation of the DREAM.3D workflow also simplifies the -# provenance tracking represented by an instance of NXem_ebsd as not every -# intermediate results has to be stored. Therefore, the fourth example -# focuses on the key result obtained from DREAM.3D - the reconstructed -# and aligned three-dimensional orientation map. -# -# Usually, this result is the starting point for further post-processing -# and characterization of structural features. As here orientation microscopy -# is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should -# be useful for different characterization methods, such as EBSD, Transmission -# Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), -# Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) -# or open-source implementations of these techniques (such as via pyxem/orix). -# -# The result of orientation microscopy methods are maps of local orientation -# and thermodynamic phase (crystal structure) pieces of information. Virtually -# all post-processing of such results for structural features includes again -# a workflow of steps which are covered though by the NXms partner application -# definition. The respective source of the data in an instance of NXms can -# again be a link or reference to an instance of NXem_ebsd to complete the -# chain of provenance. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# An overview of the entire reconstructed volume. For details about -# what defines the image contrast inspect descriptor. -# -# -# -# Descriptor representing the image contrast. -# -# -# -# -# -# Container holding a default plot of the reconstructed volume. -# -# -# -# -# -# -# -# -# -# Descriptor values displaying the ROI. -# -# -# -# -# -# -# -# -# -# Signal -# -# -# -# -# -# Calibrated center of mass of the pixel along the slow axis. -# -# -# -# -# -# -# Label for the z axis -# -# -# -# -# -# Calibrated center of mass of the pixel along the fast axis. -# -# -# -# -# -# -# Label for the y axis -# -# -# -# -# -# Calibrated center of mass of the pixel along the fastest axis. -# -# -# -# -# -# -# Label for the x axis -# -# -# -# -# -# -# -# Default inverse pole figure (IPF) plot of the data specific for each -# phase. No ipf_mapID instances for non-indexed scan points as these are -# by definition assigned the null phase with phase_identifier 0. -# The same comments apply as to the two-dimensional representation. -# -# -# -# Specifying which phase this IPF mapping visualizes. -# -# -# -# -# Alias/name for the phase whose indexed scan points are displayed. -# -# -# -# -# Which IPF definition computation according to backend. -# -# -# -# -# -# Along which axis to project? Typically [0, 0, 1] is chosen. -# -# -# -# -# -# -# -# Bitdepth used for the RGB color model. Usually 8 bit. -# -# -# -# -# The tool/implementation used for creating the IPF color map from -# the orientation data. Effectively, this program is the backend -# which performs the computation of the inverse pole figure mappings -# which can be for some use cases the parser. -# Consider the explanations in the docstring of the ipf_mapID group. -# -# -# -# -# -# -# -# -# The RGB image which represents the IPF map. -# -# -# -# -# -# -# -# -# -# RGB array, with resolution per fastest changing value -# defined by bitdepth. -# -# -# -# -# -# -# -# -# -# -# IPF color-coded orientation mapping -# -# -# -# -# -# Calibrated center of mass of the pixel along the slow axis. -# -# -# -# -# -# -# Label for the z axis -# -# -# -# -# -# -# Calibrated center of mass of the pixel along the faster axis. -# -# -# -# -# -# -# Label for the y axis -# -# -# -# -# -# -# Calibrated center of mass of the pixel along the fastest axis. -# -# -# -# -# -# -# Label for the x axis -# -# -# -# -# -# -# Same comments as for the two-dimensional case apply. -# -# -# -# -# -# -# -# -# -# RGB array, with resolution per fastest changing value defined by bitdepth. -# -# -# -# -# -# -# -# -# -# IPF color key in stereographic standard triangle (SST) -# -# -# -# -# -# Pixel coordinate along the slow axis. -# -# -# -# -# -# -# Label for the y axis -# -# -# -# -# -# Pixel coordinate along the fast axis. -# -# -# -# -# -# -# Label for the x axis -# -# -# -# -# -# -# -# -# -# + Label for the x axis diff --git a/contributed_definitions/nyaml/NXem_ebsd_conventions.yaml b/contributed_definitions/nyaml/NXem_ebsd_conventions.yaml deleted file mode 100644 index 45696360d2..0000000000 --- a/contributed_definitions/nyaml/NXem_ebsd_conventions.yaml +++ /dev/null @@ -1,940 +0,0 @@ -category: base - -# symbols: -doc: | - Conventions for rotations and coordinate systems to interpret EBSD data. - - This is the main issue which currently is not in all cases documented - and thus limits the interoperability and value of collected EBSD data. - Not communicating EBSD data with such contextual pieces of information - and the use of file formats which do not store this information is the - key unsolved problem. -type: group -NXem_ebsd_conventions(NXobject): - - # mandatory information about used or - # assumed reference frame and rotation conventions - rotation_conventions(NXprocess): - doc: | - Mathematical conventions and materials-science-specific conventions - required for interpreting every collection of orientation data. - three_dimensional_rotation_handedness: - doc: | - Convention how a positive rotation angle is defined when viewing - from the end of the rotation unit vector towards its origin, - i.e. in accordance with convention 2 of - DOI: 10.1088/0965-0393/23/8/083501. - Counter_clockwise is equivalent to a right-handed choice. - Clockwise is equivalent to a left-handed choice. - enumeration: [undefined, counter_clockwise, clockwise] - rotation_convention: - doc: | - How are rotations interpreted into an orientation - according to convention 3 of - DOI: 10.1088/0965-0393/23/8/083501. - enumeration: [undefined, passive, active] - euler_angle_convention: - doc: | - How are Euler angles interpreted given that there are several - choices (e.g. ZXZ, XYZ, etc.) according to convention 4 of - DOI: 10.1088/0965-0393/23/8/083501. - The most frequently used convention is ZXZ which is based on - the work of H.-J. Bunge but other conventions are possible. - enumeration: [undefined, zxz] - axis_angle_convention: - doc: | - To which angular range is the rotation angle argument of an - axis-angle pair parameterization constrained according to - convention 5 of DOI: 10.1088/0965-0393/23/8/083501. - enumeration: [undefined, rotation_angle_on_interval_zero_to_pi] - orientation_parameterization_sign_convention: - doc: | - Which sign convention is followed when converting orientations - between different parameterizations/representations according - to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. - enumeration: [undefined, p_plus_one, p_minus_one] - processing_reference_frame(NXprocess): - doc: | - Details about eventually relevant named directions that may - give reasons for anisotropies. The classical example is cold-rolling - where one has to specify which directions (rolling, transverse, and normal) - align how with the direction of the base vectors of the sample_reference_frame. - reference_frame_type: - doc: | - Type of coordinate system and reference frame according to - convention 1 of DOI: 10.1088/0965-0393/23/8/083501. - enumeration: [undefined, right_handed_cartesian, left_handed_cartesian] - xaxis_direction: - doc: | - Direction of the positively pointing x-axis base vector of - the processing_reference_frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. - enumeration: [undefined, north, east, south, west, in, out] - xaxis_alias: - doc: | - Name or alias assigned to the x-axis base vector, e.g. rolling direction. - yaxis_direction: - doc: | - Direction of the positively pointing y-axis base vector of - the processing_reference_frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. - enumeration: [undefined, north, east, south, west, in, out] - yaxis_alias: - doc: | - Name or alias assigned to the y-axis base vector, e.g. transverse direction. - zaxis_direction: - doc: | - Direction of the positively pointing z-axis base vector of - the processing_reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. - enumeration: [undefined, north, east, south, west, in, out] - zaxis_alias: - doc: | - Name or alias assigned to the z-axis base vector, e.g. normal direction. - origin: - doc: | - Location of the origin of the processing_reference_frame. - This specifies the location Xp = 0, Yp = 0, Zp = 0. - Assume regions-of-interest in this reference frame form a - rectangle or cuboid. - Edges are interpreted by inspecting the direction of their - outer unit normals (which point either parallel or antiparallel) - along respective base vector direction of the reference frame. - enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] - sample_reference_frame(NXprocess): - doc: | - Details about the sample/specimen reference frame. - reference_frame_type: - doc: | - Type of coordinate system and reference frame according to - convention 1 of DOI: 10.1088/0965-0393/23/8/083501. - The reference frame for the sample surface reference is used for - identifying positions on a (virtual) image which is formed by - information collected from an electron beam scanning the - sample surface. We assume the configuration is inspected by - looking towards the sample surface from a position that is - located behind the detector. - Reference DOI: 10.1016/j.matchar.2016.04.008 - The sample surface reference frame has coordinates Xs, Ys, Zs. - In three dimensions these coordinates are not necessarily - located on the surface of the sample as there are multiple - faces/sides of the sample. Most frequently though the coordinate - system here is used to define the surface which the electron - beam scans. - enumeration: [undefined, right_handed_cartesian, left_handed_cartesian] - xaxis_direction: - doc: | - Direction of the positively pointing x-axis base vector of - the sample surface reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. - enumeration: [undefined, north, east, south, west, in, out] - yaxis_direction: - doc: | - Direction of the positively pointing y-axis base vector of - the sample surface reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. - enumeration: [undefined, north, east, south, west, in, out] - zaxis_direction: - doc: | - Direction of the positively pointing z-axis base vector of - the sample surface reference frame. We assume the configuration - is inspected by looking towards the sample surface from a position - that is located behind the detector. For further information consult - also the help info for the xaxis_direction field. - enumeration: [undefined, north, east, south, west, in, out] - origin: - doc: | - Location of the origin of the sample surface reference frame. - This specifies the location Xs = 0, Ys = 0, Zs = 0. - Assume regions-of-interest in this reference frame form a - rectangle or cuboid. - Edges are interpreted by inspecting the direction of their - outer unit normals (which point either parallel or antiparallel) - along respective base vector direction of the reference frame. - enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] - detector_reference_frame(NXprocess): - doc: | - Details about the detector reference frame. - reference_frame_type: - doc: | - Type of coordinate system/reference frame used for - identifying positions in detector space Xd, Yd, Zd, - according to DOI: 10.1016/j.matchar.2016.04.008. - enumeration: [undefined, right_handed_cartesian, left_handed_cartesian] - xaxis_direction: - doc: | - Direction of the positively pointing x-axis base vector of - the detector space reference frame. We assume the configuration - is inspected by looking towards the sample surface from a - position that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. - enumeration: [undefined, north, east, south, west, in, out] - yaxis_direction: - doc: | - Direction of the positively pointing y-axis base vector of - the detector space reference frame. We assume the configuration - is inspected by looking towards the sample surface from a - position that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - enumeration: [undefined, north, east, south, west, in, out] - zaxis_direction: - doc: | - Direction of the positively pointing z-axis base vector of - the detector space reference frame. We assume the configuration - is inspected by looking towards the sample surface from a - position that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - enumeration: [undefined, north, east, south, west, in, out] - origin: - doc: | - Where is the origin of the detector space reference - frame located. This is the location of Xd = 0, Yd = 0, Zd = 0. - Assume regions-of-interest in this reference frame form a - rectangle or cuboid. - Edges are interpreted by inspecting the direction of their - outer unit normals (which point either parallel or antiparallel) - along respective base vector direction of the reference frame. - enumeration: [undefined, front_top_left, front_top_right, front_bottom_right, front_bottom_left, back_top_left, back_top_right, back_bottom_right, back_bottom_left] - gnomonic_projection_reference_frame(NXprocess): - doc: | - Details about the gnomonic projection reference frame. - reference_frame_type: - doc: | - Type of coordinate system/reference frame used for identifying - positions in the gnomonic projection space Xg, Yg, Zg - according to DOI: 10.1016/j.matchar.2016.04.008. - enumeration: [undefined, right_handed_cartesian, left_handed_cartesian] - xaxis_direction: - doc: | - Direction of the positively pointing "gnomomic" x-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - Different tools assume that different strategies can be used - and are perceived as differently convenient to enter - details about coordinate system definitions. In this ELN users - have to possibility to fill in what they assume is sufficient to - define the coordinate system directions unambiguously. - Software which works with this user input needs to offer parsing - capabilities which detect conflicting input and warn accordingly. - enumeration: [undefined, north, east, south, west, in, out] - yaxis_direction: - doc: | - Direction of the positively pointing "gnomomic" y-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - enumeration: [undefined, north, east, south, west, in, out] - zaxis_direction: - doc: | - Direction of the positively pointing "gnomomic" z-axis base - vector when viewing how the diffraction pattern looks on the - detector screen. We assume the configuration is inspected by - looking towards the sample surface from a position - that is located behind the detector. - For further information consult also the help info for the - xaxis_direction field. - enumeration: [undefined, north, east, south, west, in, out] - origin: - doc: | - Is the origin of the gnomonic coordinate system located - where we assume the location of the pattern centre. - This is the location Xg = 0, Yg = 0, Zg = 0 according to - reference DOI: 10.1016/j.matchar.2016.04.008. - enumeration: [undefined, in_the_pattern_centre] - pattern_centre(NXprocess): - doc: | - Details about the definition of the pattern centre - as a special point in the gnomonic projection reference frame. - xaxis_boundary_convention: - doc: | - From which border of the EBSP (in the detector reference frame) - is the pattern centre's x-position (PCx) measured? - Keywords assume the region-of-interest is defined by - a rectangle. We observe this rectangle and inspect the - direction of the outer-unit normals to the edges of - this rectangle. - enumeration: [undefined, top, right, bottom, left] - xaxis_normalization_direction: - doc: | - In which direction are positive values for PCx measured from - the specified boundary. Keep in mind that the gnomonic space - is in virtually all cases embedded in the detector space. - Specifically, the XgYg plane is defined such that it is - embedded/laying inside the XdYd plane (of the detector - reference frame). - When the normalization direction is the same as e.g. the - detector x-axis direction, we state that we effectively - normalize in fractions of the width of the detector. - - The issue with terms like width and height is that these - degenerate if the detector region-of-interest is square-shaped. - This is why we should better avoid talking about width and height but - state how we would measure distances practically with a ruler and - how we then measure positive distances. - enumeration: [undefined, north, east, south, west] - yaxis_boundary_convention: - doc: | - From which border of the EBSP (in the detector reference - frame) is the pattern centre's y-position (PCy) measured? - For further details inspect the help button of - xaxis_boundary_convention. - enumeration: [undefined, top, right, bottom, left] - yaxis_normalization_direction: - doc: | - In which direction are positive values for PCy measured from - the specified boundary. - For further details inspect the help button of - xaxis_normalization_direction. - enumeration: [undefined, north, east, south, west] - - # distance_convention: - # doc: | - # How is the third of the three pattern centre parameter values, - # the (distance) parameter DD, normalized. Which convention - # is followed. We are aware that specifying one of the options here - # also implicitly comes with conventions for some of the parameter - # requested in this ELN. For now we would rather like to ask - # the users though to be specific also to learn how such an ELN - # will be used in practice. - # enumeration: [undefined, Bruker, JEOL, FEI, Oxford] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 619b2761b3b57179eeb33499b763adc93d4074004e936dc4460168d914fe9502 -# -# -# -# -# -# -# Conventions for rotations and coordinate systems to interpret EBSD data. -# -# This is the main issue which currently is not in all cases documented -# and thus limits the interoperability and value of collected EBSD data. -# Not communicating EBSD data with such contextual pieces of information -# and the use of file formats which do not store this information is the -# key unsolved problem. -# -# -# -# -# Mathematical conventions and materials-science-specific conventions -# required for interpreting every collection of orientation data. -# -# -# -# Convention how a positive rotation angle is defined when viewing -# from the end of the rotation unit vector towards its origin, -# i.e. in accordance with convention 2 of -# DOI: 10.1088/0965-0393/23/8/083501. -# Counter_clockwise is equivalent to a right-handed choice. -# Clockwise is equivalent to a left-handed choice. -# -# -# -# -# -# -# -# -# -# How are rotations interpreted into an orientation -# according to convention 3 of -# DOI: 10.1088/0965-0393/23/8/083501. -# -# -# -# -# -# -# -# -# -# How are Euler angles interpreted given that there are several -# choices (e.g. ZXZ, XYZ, etc.) according to convention 4 of -# DOI: 10.1088/0965-0393/23/8/083501. -# The most frequently used convention is ZXZ which is based on -# the work of H.-J. Bunge but other conventions are possible. -# -# -# -# -# -# -# -# -# To which angular range is the rotation angle argument of an -# axis-angle pair parameterization constrained according to -# convention 5 of DOI: 10.1088/0965-0393/23/8/083501. -# -# -# -# -# -# -# -# -# Which sign convention is followed when converting orientations -# between different parameterizations/representations according -# to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. -# -# -# -# -# -# -# -# -# -# -# Details about eventually relevant named directions that may -# give reasons for anisotropies. The classical example is cold-rolling -# where one has to specify which directions (rolling, transverse, and normal) -# align how with the direction of the base vectors of the sample_reference_frame. -# -# -# -# Type of coordinate system and reference frame according to -# convention 1 of DOI: 10.1088/0965-0393/23/8/083501. -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing x-axis base vector of -# the processing_reference_frame. We assume the configuration -# is inspected by looking towards the sample surface from a position -# that is located behind the detector. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Name or alias assigned to the x-axis base vector, e.g. rolling direction. -# -# -# -# -# Direction of the positively pointing y-axis base vector of -# the processing_reference_frame. We assume the configuration -# is inspected by looking towards the sample surface from a position -# that is located behind the detector. For further information consult -# also the help info for the xaxis_direction field. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Name or alias assigned to the y-axis base vector, e.g. transverse direction. -# -# -# -# -# Direction of the positively pointing z-axis base vector of -# the processing_reference frame. We assume the configuration -# is inspected by looking towards the sample surface from a position -# that is located behind the detector. For further information consult -# also the help info for the xaxis_direction field. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Name or alias assigned to the z-axis base vector, e.g. normal direction. -# -# -# -# -# Location of the origin of the processing_reference_frame. -# This specifies the location Xp = 0, Yp = 0, Zp = 0. -# Assume regions-of-interest in this reference frame form a -# rectangle or cuboid. -# Edges are interpreted by inspecting the direction of their -# outer unit normals (which point either parallel or antiparallel) -# along respective base vector direction of the reference frame. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Details about the sample/specimen reference frame. -# -# -# -# Type of coordinate system and reference frame according to -# convention 1 of DOI: 10.1088/0965-0393/23/8/083501. -# The reference frame for the sample surface reference is used for -# identifying positions on a (virtual) image which is formed by -# information collected from an electron beam scanning the -# sample surface. We assume the configuration is inspected by -# looking towards the sample surface from a position that is -# located behind the detector. -# Reference DOI: 10.1016/j.matchar.2016.04.008 -# The sample surface reference frame has coordinates Xs, Ys, Zs. -# In three dimensions these coordinates are not necessarily -# located on the surface of the sample as there are multiple -# faces/sides of the sample. Most frequently though the coordinate -# system here is used to define the surface which the electron -# beam scans. -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing x-axis base vector of -# the sample surface reference frame. We assume the configuration -# is inspected by looking towards the sample surface from a position -# that is located behind the detector. -# Different tools assume that different strategies can be used -# and are perceived as differently convenient to enter -# details about coordinate system definitions. In this ELN users -# have to possibility to fill in what they assume is sufficient to -# define the coordinate system directions unambiguously. -# Software which works with this user input needs to offer parsing -# capabilities which detect conflicting input and warn accordingly. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing y-axis base vector of -# the sample surface reference frame. We assume the configuration -# is inspected by looking towards the sample surface from a position -# that is located behind the detector. For further information consult -# also the help info for the xaxis_direction field. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing z-axis base vector of -# the sample surface reference frame. We assume the configuration -# is inspected by looking towards the sample surface from a position -# that is located behind the detector. For further information consult -# also the help info for the xaxis_direction field. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Location of the origin of the sample surface reference frame. -# This specifies the location Xs = 0, Ys = 0, Zs = 0. -# Assume regions-of-interest in this reference frame form a -# rectangle or cuboid. -# Edges are interpreted by inspecting the direction of their -# outer unit normals (which point either parallel or antiparallel) -# along respective base vector direction of the reference frame. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Details about the detector reference frame. -# -# -# -# Type of coordinate system/reference frame used for -# identifying positions in detector space Xd, Yd, Zd, -# according to DOI: 10.1016/j.matchar.2016.04.008. -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing x-axis base vector of -# the detector space reference frame. We assume the configuration -# is inspected by looking towards the sample surface from a -# position that is located behind the detector. -# Different tools assume that different strategies can be used -# and are perceived as differently convenient to enter -# details about coordinate system definitions. In this ELN users -# have to possibility to fill in what they assume is sufficient to -# define the coordinate system directions unambiguously. -# Software which works with this user input needs to offer parsing -# capabilities which detect conflicting input and warn accordingly. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing y-axis base vector of -# the detector space reference frame. We assume the configuration -# is inspected by looking towards the sample surface from a -# position that is located behind the detector. -# For further information consult also the help info for the -# xaxis_direction field. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing z-axis base vector of -# the detector space reference frame. We assume the configuration -# is inspected by looking towards the sample surface from a -# position that is located behind the detector. -# For further information consult also the help info for the -# xaxis_direction field. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Where is the origin of the detector space reference -# frame located. This is the location of Xd = 0, Yd = 0, Zd = 0. -# Assume regions-of-interest in this reference frame form a -# rectangle or cuboid. -# Edges are interpreted by inspecting the direction of their -# outer unit normals (which point either parallel or antiparallel) -# along respective base vector direction of the reference frame. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Details about the gnomonic projection reference frame. -# -# -# -# Type of coordinate system/reference frame used for identifying -# positions in the gnomonic projection space Xg, Yg, Zg -# according to DOI: 10.1016/j.matchar.2016.04.008. -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing "gnomomic" x-axis base -# vector when viewing how the diffraction pattern looks on the -# detector screen. We assume the configuration is inspected by -# looking towards the sample surface from a position -# that is located behind the detector. -# Different tools assume that different strategies can be used -# and are perceived as differently convenient to enter -# details about coordinate system definitions. In this ELN users -# have to possibility to fill in what they assume is sufficient to -# define the coordinate system directions unambiguously. -# Software which works with this user input needs to offer parsing -# capabilities which detect conflicting input and warn accordingly. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing "gnomomic" y-axis base -# vector when viewing how the diffraction pattern looks on the -# detector screen. We assume the configuration is inspected by -# looking towards the sample surface from a position -# that is located behind the detector. -# For further information consult also the help info for the -# xaxis_direction field. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of the positively pointing "gnomomic" z-axis base -# vector when viewing how the diffraction pattern looks on the -# detector screen. We assume the configuration is inspected by -# looking towards the sample surface from a position -# that is located behind the detector. -# For further information consult also the help info for the -# xaxis_direction field. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Is the origin of the gnomonic coordinate system located -# where we assume the location of the pattern centre. -# This is the location Xg = 0, Yg = 0, Zg = 0 according to -# reference DOI: 10.1016/j.matchar.2016.04.008. -# -# -# -# -# -# -# -# -# -# Details about the definition of the pattern centre -# as a special point in the gnomonic projection reference frame. -# -# -# -# From which border of the EBSP (in the detector reference frame) -# is the pattern centre's x-position (PCx) measured? -# Keywords assume the region-of-interest is defined by -# a rectangle. We observe this rectangle and inspect the -# direction of the outer-unit normals to the edges of -# this rectangle. -# -# -# -# -# -# -# -# -# -# -# -# In which direction are positive values for PCx measured from -# the specified boundary. Keep in mind that the gnomonic space -# is in virtually all cases embedded in the detector space. -# Specifically, the XgYg plane is defined such that it is -# embedded/laying inside the XdYd plane (of the detector -# reference frame). -# When the normalization direction is the same as e.g. the -# detector x-axis direction, we state that we effectively -# normalize in fractions of the width of the detector. -# -# The issue with terms like width and height is that these -# degenerate if the detector region-of-interest is square-shaped. -# This is why we should better avoid talking about width and height but -# state how we would measure distances practically with a ruler and -# how we then measure positive distances. -# -# -# -# -# -# -# -# -# -# -# -# From which border of the EBSP (in the detector reference -# frame) is the pattern centre's y-position (PCy) measured? -# For further details inspect the help button of -# xaxis_boundary_convention. -# -# -# -# -# -# -# -# -# -# -# -# In which direction are positive values for PCy measured from -# the specified boundary. -# For further details inspect the help button of -# xaxis_normalization_direction. -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXem_ebsd_crystal_structure_model.yaml b/contributed_definitions/nyaml/NXem_ebsd_crystal_structure_model.yaml deleted file mode 100644 index 4efc224d88..0000000000 --- a/contributed_definitions/nyaml/NXem_ebsd_crystal_structure_model.yaml +++ /dev/null @@ -1,389 +0,0 @@ -category: base -doc: | - Crystal structure phase models used for indexing Kikuchi pattern. - - This base class contains key metadata relevant to every physical - kinematic or dynamic diffraction model to be used for simulating - Kikuchi diffraction pattern. - The actual indexing of Kikuchi pattern however maybe use different - algorithms which build on these simulation results but evaluate different - workflows of comparing simulated and measured Kikuchi pattern to make - suggestions which orientation is the most likely (if any) for each - scan point investigated. - - Traditionally Hough transform based indexing has been the most frequently - used algorithm. More and more dictionary based alternatives are used. - Either way both algorithm need a crystal structure model. -symbols: - n_hkl: | - Number of reflectors (Miller crystallographic plane triplets). - n_pos: | - Number of atom positions. -type: group -NXem_ebsd_crystal_structure_model(NXobject): - - # for EBSD specifically we need to know the assumed crystal structure - # with assumed statistically distributed atoms, i.e. structure and atom - # positions - crystallographic_database_identifier: - doc: | - Identifier of an entry from crystallographic_database which was used - for creating this structure model. - crystallographic_database: - doc: | - Name of the crystallographic database to resolve - crystallographic_database_identifier e.g. COD or others. - - # defined using which convention? - unit_cell_abc(NX_FLOAT): - unit: NX_LENGTH - doc: | - Crystallography unit cell parameters a, b, and c. - dimensions: - rank: 1 - dim: [[1, 3]] - - # defined using which convention? - unit_cell_alphabetagamma(NX_FLOAT): - unit: NX_ANGLE - doc: | - Crystallography unit cell parameters alpha, beta, and gamma. - dimensions: - rank: 1 - dim: [[1, 3]] - unit_cell_volume(NX_FLOAT): - unit: NX_VOLUME - doc: | - Volume of the unit cell - space_group: - doc: | - Crystallographic space group - - # add enumeration all possible - is_centrosymmetric(NX_BOOLEAN): - doc: | - True if space group is considered a centrosymmetric one. - False if space group is considered a non-centrosymmetric one. - Centrosymmetric has all types and combinations of symmetry elements - (translation, rotational axis, mirror planes, center of inversion) - Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). - Chiral compared to non-centrosymmetric is constrained (no mirror planes). - is_chiral(NX_BOOLEAN): - doc: | - True if space group is considered a chiral one. - False if space group is consider a non-chiral one. - laue_group: - doc: | - Laue group - - # add enumeration all possible - point_group: - doc: | - Point group using International Notation. - - # add enumeration all possible - unit_cell_class: - doc: | - Crystal system - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - phase_identifier(NX_UINT): - unit: NX_UNITLESS - doc: | - Numeric identifier for each phase. - The value 0 is reserved for the unknown phase essentially representing the - null-model that no phase model was sufficiently significantly confirmed. - Consequently, the value 0 must not be used as a phase_identifier. - phase_name: - doc: | - Name of the phase/alias. - atom_identifier: - doc: | - Labels for each atom position - dimensions: - rank: 1 - dim: [[1, n_pos]] - atom(NX_UINT): - unit: NX_UNITLESS - doc: | - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) `_ - dimensions: - rank: 1 - dim: [[1, n_pos]] - atom_positions(NX_FLOAT): - unit: NX_LENGTH - doc: | - Atom positions x, y, z. - dimensions: - rank: 2 - dim: [[1, n_pos], [2, 3]] - - # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory - # to describe the simulated Kikuchi pattern generated from such a model - atom_occupancy(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Relative occupancy of the atom position. - dimensions: - rank: 1 - dim: [[1, n_pos]] - number_of_planes(NX_UINT): - unit: NX_UNITLESS - doc: | - How many reflectors are distinguished. Value has to be n_hkl. - - # Miller indices :math:`(hkl)[uvw]`. - plane_miller(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Miller indices :math:`(hkl)`. - dimensions: - rank: 2 - dim: [[1, n_hkl], [2, 3]] - dspacing(NX_FLOAT): - unit: NX_LENGTH - doc: | - D-spacing. - dimensions: - rank: 1 - dim: [[1, n_hkl]] - relative_intensity(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Relative intensity of the signal for the plane. - dimensions: - rank: 1 - dim: [[1, n_hkl]] - - # here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) - # can give some good suggestions on how to improve and ideally make even - # more general this section - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8e34c264fb504d9b2c1da81927f6e381567238ced8ce6e0ac8a540b33d348599 -# -# -# -# -# -# -# -# Number of reflectors (Miller crystallographic plane triplets). -# -# -# -# -# Number of atom positions. -# -# -# -# -# Crystal structure phase models used for indexing Kikuchi pattern. -# -# This base class contains key metadata relevant to every physical -# kinematic or dynamic diffraction model to be used for simulating -# Kikuchi diffraction pattern. -# The actual indexing of Kikuchi pattern however maybe use different -# algorithms which build on these simulation results but evaluate different -# workflows of comparing simulated and measured Kikuchi pattern to make -# suggestions which orientation is the most likely (if any) for each -# scan point investigated. -# -# Traditionally Hough transform based indexing has been the most frequently -# used algorithm. More and more dictionary based alternatives are used. -# Either way both algorithm need a crystal structure model. -# -# -# -# -# Identifier of an entry from crystallographic_database which was used -# for creating this structure model. -# -# -# -# -# Name of the crystallographic database to resolve -# crystallographic_database_identifier e.g. COD or others. -# -# -# -# -# -# Crystallography unit cell parameters a, b, and c. -# -# -# -# -# -# -# -# -# Crystallography unit cell parameters alpha, beta, and gamma. -# -# -# -# -# -# -# -# Volume of the unit cell -# -# -# -# -# Crystallographic space group -# -# -# -# -# -# True if space group is considered a centrosymmetric one. -# False if space group is considered a non-centrosymmetric one. -# Centrosymmetric has all types and combinations of symmetry elements -# (translation, rotational axis, mirror planes, center of inversion) -# Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). -# Chiral compared to non-centrosymmetric is constrained (no mirror planes). -# -# -# -# -# True if space group is considered a chiral one. -# False if space group is consider a non-chiral one. -# -# -# -# -# Laue group -# -# -# -# -# -# Point group using International Notation. -# -# -# -# -# -# Crystal system -# -# -# -# -# -# -# -# -# -# -# -# -# -# Numeric identifier for each phase. -# The value 0 is reserved for the unknown phase essentially representing the -# null-model that no phase model was sufficiently significantly confirmed. -# Consequently, the value 0 must not be used as a phase_identifier. -# -# -# -# -# Name of the phase/alias. -# -# -# -# -# Labels for each atom position -# -# -# -# -# -# -# -# The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` -# the number of protons and :math:`N` the number of neutrons -# of each isotope respectively. Z and N have to be 8-bit unsigned integers. -# For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ -# -# -# -# -# -# -# -# Atom positions x, y, z. -# -# -# -# -# -# -# -# -# -# Relative occupancy of the atom position. -# -# -# -# -# -# -# -# How many reflectors are distinguished. Value has to be n_hkl. -# -# -# -# -# -# Miller indices :math:`(hkl)`. -# -# -# -# -# -# -# -# -# D-spacing. -# -# -# -# -# -# -# -# Relative intensity of the signal for the plane. -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml new file mode 100644 index 0000000000..9a5a97fcd0 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -0,0 +1,80 @@ +category: base +doc: | + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + + `IUPAC instead of Siegbahn notation `_ should be used. + +# NEW ISSUE: use computational geometry to offer arbitrary scan pattern +# NEW ISSUE: make the binning flexible per scan point +symbols: + # n_p: Number of scan points + n_y: | + Number of pixel along the y direction, the slow direction + n_x: | + Number of pixel along the x direction, the fast direction + n_photon_energy: | + Number of X-ray photon energy (bins), the fastest direction. + n_elements: | + Number of identified elements + n_peaks: | + Number of peaks detected +type: group +NXem_eds(NXem_method): + # NXprocess is composed from NXem_method base class + # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class + # for post-processing of/with the above-defined data entries + # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), + # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), + # and Adrien Teutrie, Cecile Hebert (EPFL) + indexing(NXprocess): + doc: | + Details about computational steps how peaks were indexed as elements. + (NXprogram): + doc: | + The program with which the indexing was performed. + PEAK(NXpeak): + doc: | + Name and location of each X-ray line which was indexed as a known ion. + For each ion, an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + (NXion): + energy_range(NX_NUMBER): + doc: | + Associated lower :math:`[e_{min}, e_{max}]` bounds of the + energy which is assumed associated with this peak. + unit: NX_ENERGY + dim: (2,) + energy(NX_NUMBER): + doc: | + Theoretical energy of the line according to IUPAC. + unit: NX_ENERGY + iupac_line_names(NX_CHAR): + doc: | + IUPAC notation identifier of the line which the peak represents. + + This can be a list of IUPAC notations for (the seldom) case that + multiple lines are grouped with the same peak. + dim: (i,) + element_names(NX_CHAR): + doc: | + List of the names of identified elements. + dim: (n_elements,) + IMAGE_R_SET(NXimage_r_set): + doc: | + Individual element-specific EDS/EDX/EDXS/SXES mapping + + A composition map is an image whose intensities for each pixel are the + accumulated X-ray quanta *under the curve(s)* of a set of peaks. + + These element-specific EDS maps are NXimage_r_set instances + and need to be named with the name of the element from the + element_names field. + (NXprocess): + peaks(NX_CHAR): + doc: | + A list of NXpeak instance names whose X-ray quanta + where accumulated for each pixel which yields an element-specific + EDS map. + dim: (n_peaks,) + # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml new file mode 100644 index 0000000000..4e5c69fe4a --- /dev/null +++ b/contributed_definitions/nyaml/NXem_eels.yaml @@ -0,0 +1,39 @@ +category: base +doc: | + Base class method-specific for Electron Energy Loss Spectroscopy (EELS). +symbols: + n_energy_loss: | + Number of electron energy loss bins. +type: group +NXem_eels(NXem_method): + # NXem_method can offers to keep a SPECTRUM_SET + # NXem_method also has an NXprocess which in this base class can be + # specialized to include EELS-specific post-processing + SPECTRUM_SET(NXspectrum_set): + doc: | + NXspectrum_set_em specialized for EELS. + stack(NXdata): + # \@signal: data_counts + # \@axes: [axis_y, axis_x, axis_energy_loss] + # \@energy_loss_indices: 2 + # \@axis_x_indices: 1 + # \@axis_y_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + summary(NXdata): + # \@signal: data_counts + # \@axes: [axis_energy_loss] + # \@energy_loss_indices: 0 + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + doc: | + Energy loss. + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml new file mode 100644 index 0000000000..8c257d121a --- /dev/null +++ b/contributed_definitions/nyaml/NXem_img.yaml @@ -0,0 +1,25 @@ +category: base +doc: | + Base class for method-specific generic imaging. + + In the majority of cases simple d-dimensional regular scan patterns are used + to probe a region-of-interest (ROI). Examples can be single point aka spot + measurements, line profiles, or (rectangular) surface mappings. + The latter pattern is the most frequently used. + + For now the base class provides for scans for which the settings, + binning, and energy resolution is the same for each scan point. +symbols: + n_images: | + Number of images in the stack. + n_y: | + Number of pixel per image in the slow direction. + n_x: | + Number of pixel per image in the fast direction. +type: group +NXem_img(NXem_method): + imaging_mode(NX_CHAR): + doc: | + Which imaging mode was used? + enumeration: [secondary_electron, backscattered_electron] + IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml new file mode 100644 index 0000000000..afe91de973 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_method.yaml @@ -0,0 +1,21 @@ +category: base +doc: | + Base class to describe specific analysis methods in electron microscopy. + + This base class represent a template how specialized, deep, and method-specific + base classes can be defined with which an (NXem) application + definition gets equipped with specific groups to document method-specific + processing steps and report analyzed quantities. + + The template base class name :ref:`NXem_method` needs to be changed for each + method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. +# :ref:`NXem_se`, :ref:`NXem_bse`. +type: group +NXem_method(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): + IMAGE_R_SET(NXimage_r_set): + IMAGE_C_SET(NXimage_c_set): + SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml new file mode 100644 index 0000000000..16c349ca58 --- /dev/null +++ b/contributed_definitions/nyaml/NXem_msr.yaml @@ -0,0 +1,63 @@ +category: base +doc: | + Base class for collecting a session with a real electron microscope. + + For collecting data and experiments which are simulations of an + electron microscope use the :ref:`NXem_sim` base class. +type: group +NXem_msr(NXem_method): + em_lab(NXinstrument): + doc: | + (Meta)data of the microscope and the lab in which it stands. + + This em_lab group differs from potential em_lab groups inside + :ref:`NXevent_data_em` instances in that here the more static descriptions + are kept while changing, i.e. time-dependent pieces of information are + logged, via the em_lab group inside the desired number of instances + of NXevent_data_em. + + While using an :ref:`NXevent_data_em` instance, users should store only those + settings about a component which are relevant to understand the current + state of the component. Here, current means for the time interval which + the event covers (as it is detailed via start_time and end_time) timestamps. + + For example it is not relevant to store in each :ref:`NXevent_data_em` + electron_source group again the details of the gun type and the manufacturer + but only the high-voltage value and that only if it is different from the value + that is specified in the em_lab section for the static settings. + + In effect, this defines an information inference hierarchy which starts + in an individual :ref:`NXevent_data_em` instance followed by a probing of the + static section. + instrument_name(NX_CHAR): + doc: | + Given name of the microscope at the hosting institution. + This is an alias. Examples could be NionHermes, Titan, JEOL, + Gemini, etc. + location(NX_CHAR): + doc: | + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + (NXfabrication): + (NXchamber): + (NXebeam_column): + (NXibeam_column): + (NXoptical_system_em): + (NXdetector): + doc: | + Description of the type of the detector. + + Electron microscopes have typically multiple detectors. + Different technologies are in use like CCD, scintillator, + direct electron, CMOS, or image plate to name but a few. + local_name(NX_CHAR): + doc: | + Instrument-specific alias/name + # it is unfortunate that for NXdetector there are already many places + # how one can specify details which could equally end up in fabrications + # we should give better guidance which option to use, pr to niac + # (NXfabrication): + (NXpump): + (NXstage_lab): + (NXevent_data_em_set): +# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml new file mode 100644 index 0000000000..81fe20db1b --- /dev/null +++ b/contributed_definitions/nyaml/NXem_sim.yaml @@ -0,0 +1,34 @@ +category: base +doc: | + Base class for simulating electron microscopy relevant beam-matter interaction. + + The concept behind this base class is to keep it as generic as possible + that simulations of electron/ion beam interaction with matter can be + represented. This base class is envisioned as the twin of the :ref:`NXem_msr` + base class. + + It is an attempt to test the idea if at some point one might even use the + same base class template to describe measurements and computer simulations + of electron microscopy. This idea is attractive because the only practical + difference between a description of a measurement with a microscope and a + computer simulation is that the latter is typically a substantially simplified + representation of the real microscope surplus the focus of the research + in such cases on specific questions. + + Such simplification can be with respect to the optical setup, typically the + ignoring of the fact that the electron beam is produced by a complex setup + of lenses while in simulations often single Einzel lenses are considered. + Dynamics of the environment like temperature fluctuation in a lab, vibrations, + users, and multiple detectors are typically either ignored or reduced in + complexity and number and coming with idealizations to keep the simulations + focused on the specific reason questions and efficiently numerically executable. +# abTEM and other simulation packages, TEMgym, etc. +type: group +NXem_sim(NXem_method): + simulation(NXprocess): + doc: | + Details about the simulation. + # sequence_index(N): + (NXprogram): + (NXcg_geodesic_mesh): + (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXevent_data_em.yaml b/contributed_definitions/nyaml/NXevent_data_em.yaml index 3866f3e424..f070c5ceb4 100644 --- a/contributed_definitions/nyaml/NXevent_data_em.yaml +++ b/contributed_definitions/nyaml/NXevent_data_em.yaml @@ -1,139 +1,79 @@ category: base doc: | - Metadata and settings of an electron microscope for scans and images. - - The need for such a structuring of data is evident from the fact that - electron microscopes are dynamic. Oftentimes it suffices to calibrate the - instrument at the start of the session. Subsequently, data (images, spectra, etc.) - can be collected. Users may wish to take only a single scan or image and - complete their microscope session; however - - frequently users are working much longer at the microscope, recalibrate and take - multiple data items (scans, images, spectra). Each item comes with own detector - and eventually on-the-fly processing settings and calibrations. - - For the single data item use case one may argue that the need for an additional - grouping is redundant. Instead, the metadata could equally be stored inside - the respective groups of the top-level mandatory NXinstrument group. - On the flip side, even for a session with a single image, it would also not - harm to nest the data. - - In fact, oftentimes scientists feel that there is a need to store details - about eventual drift of the specimen in its holder (if such data is available) - or record changes to the lens excitations or apertures used and/or changed. - Although current microscopes are usually equipped with stabilization - systems for many of the individual components, it can still be useful - to store time-dependent data in detail. - - Another reason if not a need for having more finely granularizable options for - storing time-dependent data, is that over the course of a session one may - reconfigure the microscope. What is a reconfiguration? This could be the - change of an aperture mode because a scientist may first collect an image - with some aperture and then pick a different value and continue. - As the aperture affects the electron beam, it will affect the system. - - Let aside for a moment the technology and business models, an EM could be - monitored (and will likely become so more in the future) for streaming out - spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied - and the specimen repositioned. - - Some snapshot or integrated data from this stream are relevant for understanding - signal genesis and electron/ion-beam-sample interaction (paths). In such a generic - case it might be necessary to sync these streaming data with those intervals - in time when specific measurements are taken (spectra collected, - images taken, diffraction images indexed on-the-fly). - - Therefore, both the instrument and specimen should always be considered as dynamic. - Scientists often report or feel (difficult to quantify) observations that - microscopes *perform differently* across sessions, without sometimes being - able to identify clear root causes. Users of the instrument may consider - such conditions impractical, or *too poor* and thus either abort their session - or try to bring the microscope first into a state where conditions are considered - more stable, better, or of some whatever high enough quality to reuse - data collection. - - In all these cases it is practical to have a mechanism how time-dependent data - of the instrument state can be stored and documented in a interoperable way. - Where should these data be stored? With NeXus these data should not only be - stored in the respective instrument component groups of the top-level NXinstrument. - The reason is that this group should be reserved for as stable as possible - quantities which do not change over the session. Thereby we can avoid to store - repetitively that there is a certain gun or detector available but just store - the changes. This is exactly what the em_lab group is for inside NXevent_data_em. - - Ideally, NXevent_data_em are equipped with a start_time and end_time - to represent a time interval (remind the idea of the instrument state stream) - during which the scientist considered (or practically has to consider) - the microscope (especially ebeam and specimen) as stable enough. + Base class to store state and (meta)data of events with an electron microscopy. + + Electron microscopes are dynamic. Scientists often report that microscopes + *perform differently* across sessions, that they perform differently from + one day or another. In some cases, root causes for performance differences + are unclear. Users of the instrument may consider such conditions impractical, + or *too poor*, and thus abort their session. Alternatively, users may try to + bring the microscope into a state where conditions are considered better + or of whatever high enough quality for continuing the measurement. + + In all these use cases in practice it would be useful to have a mechanism + whereby time-dependent data of the instrument state can be stored and + documented with an interoperable representation. Indeed, how a session on an + electron microscope is spent depends strongly on the research question, + the user, and the imaging modalities used. + + :ref:`NXevent_data_em` represents an instance to describe and serialize flexibly + whatever is considered a time interval during which the instrument is + considered as stable enough for performing a task with the microscope. + Examples of such tasks are the collecting of data (images and spectra) or + the calibrating of some component of the instrument. Users may wish to take + only a single scan or image and complete their microscope session thereafter. + Alternatively, users are working for much longer time at the microscope, + perform recalibrations in between and take several scans (of different + regions-of-interest of the specimen), or they explore the state of the + microscope for service or maintenance tasks. + + :ref:`NXevent_data_em` serves the harmonization and documentation of this situation + with providing three key sections: Firstly, there is a header section whose + purpose is to contextualize and identify the event instance in time. + Secondly, there is a data and metadata section where individual data collections + can be stored using a standardized representation. + Finally, there is a section called em_lab which mirrors the structure of the + em_lab(NXinstrument) section in :ref:`NXem_base`. + + The idea of the first, the event-based em_lab section, is to document the + state of the microscope as it was during the event. The idea of the other, + the NXem application based em_lab(NXinstrument) section is to keep all those + pieces of information which are static in the sense that they are the same + across multiple :ref:`NXevent_data_em` instance. This reduces the amount of pieces of + information that have to be stored repetitively. + + We are aware of the fact that given the variety how an electron microscope + is used, there is a need for a flexible and adaptive documentation system. + At the same time we are also convinced though that just because one has + different requirements for some specific aspect under the umbrella of settings + to an electron microscope, this does not necessarily warrant that one has to + cook up an own schema. + + Instead, the electron microscopy community should work towards reusing schema + components as frequently as possible. This will enable that there is at all + not only a value of harmonizing electron microscopy research content but also + the technical possibility to build services around such harmonized + pieces of information. Arguably it is oftentimes tricky to specify a clear time interval when the - microscope is stable enough. Take for instance the acquisition of an image - or spectra stack. It is not fully possible (technically) to avoid that even - within a single image instabilities of the beam are faced and drift occurs. - Maybe in many cases this these instabilities are irrelevant but does this - warrant to create a data schema where either the microscope state can only - be stored very coarsely or one is forced to store it very finely? - - This is a question of how one wishes to granularize pieces of information. - A possible solution is to consider each probed position, i.e. point in time - when the beam was not blanked and thus when the beam illuminates a portion of - the material, i.e. the interaction volume, whose signal contributions are then - counted by the one or multiple detector(s) as per pixel- or per voxel signal - in the region-of-interest. - NXevent_data_em in combination with the NXem application definition - allows researchers to document this. Noteworty to mention is that we understand - that in many cases realizing such a fine temporal and logical granularization - and data collection is hard to achieve in practice. - - A frequently made choice, mainly for convenience, is that drift and scan distortions - are considered a feature or inaccuracy of the image and/or spectrum and thus - one de facto accepts that the microscope was not as stable as expected during - the acquisition of the image. We learn that the idea of a time interval - during the microscope session may be interpreted differently by different - users. Here we consider the choice to focus on images and spectra, and eventually - single position measurements as the smallest granularization level. - Which eventually may require to add optional NXprocess instances for respectively - collected data to describe the relevant distortions. Nevertheless, the distortions - are typically corrected for by numerical protocols. This fact warrants to - consider the distortion correction a computational workflow which can be - modelled as a chain of NXprocess instances each with own parameters. an own - A more detailed overview of such computational steps to cope with scan distortions - is available in the literature: + microscope is *stable enough*. Take for instance the acquisition of an image + or a stack of spectra. Having to deal with instabilities is a common theme in + electron microscopy practice. Numerical protocols can be used during data + post-processing to correct for some of the instabilities. + A few exemplar references to provide an overview on the subject is + available in the literature: * `C. Ophus et al. `_ * `B. Berkels et al. `_ * `L. Jones et al. `_ For specific simulation purposes, mainly in an effort to digitally repeat - or simulate the experiment, it is tempting to consider dynamics of the - instrument, implemented as time-dependent functional descriptions of - e.g. lens excitations, beam shape functions, trajectories of groups of - electrons, or detector noise models. - - For now the preferred strategy to handle these cases is through - customizations of the specific fields within NXevent_data_em instances. - - Another alternative could be to sample finer, eventually dissimilarly along - the time axi; however this may cause situations where an NXevent_data_em - instance does not contain specific measurements (i.e. images, spectra of - scientific relevance). - - In this case one should better go for a customized application definition - with a functional property description inside members (fields or groups) - in NXevent_data_em instances; or resort to a specific offspring application - definition of NXem which documents metadata for tracking explicitly electrons - (with ray-tracing based descriptors/computational geometry descriptors) - or tracking of wave bundles. - - This perspective on much more subtle time-dependent considerations of electron - microscopy can be advantageous also for storing details of time-dependent - additional components that are coupled to and/or synced with a microscope. - - Examples include cutting-edge experiments where the electron beam gets - coupled/excited by e.g. lasers. In this case, the laser unit should be - registered under the top-level NXinstrument section. Its spatio-temporal - details could be stored inside respective additional groups of the NXinstrument - though inside instances of here detailed NXevent_data_em. + or simulate the experiment, it is tempting to consider dynamics of the instrument, + implemented as time-dependent functional descriptions of e.g. lens excitations, + beam shape functions, trajectories of groups of electrons and ions, + or detector noise models. This warrants to document the time-dependent + details of individual components of the microscope + as is implemented in :ref:`NXevent_data_em`. type: group NXevent_data_em(NXobject): start_time(NX_DATE_TIME): @@ -148,10 +88,11 @@ NXevent_data_em(NXobject): doc: | ISO 8601 time code with local time zone offset to UTC information included when the snapshot time interval ended. - event_identifier: + event_identifier(NX_INT): doc: | - Reference to a specific state and setting of the microscope. - event_type: + Identifier of a specific state and setting of the microscope. + unit: NX_UNITLESS + event_type(NX_CHAR): doc: | Which specific event/measurement type. Examples are: @@ -170,256 +111,29 @@ NXevent_data_em(NXobject): * Ronchigram, image, alignment utility specifically in TEM * Chamber, e.g. TV camera inside the chamber, education purposes. - This field may also be used for storing additional information about the event. - (NXimage_set): + This field may also be used for storing additional information + about the event. For which there is at the moment no other place. + + In the long run such free-text field description should be avoided as + they are difficult to machine-interpret. Instead, reference should be given + to refactoring these descriptions into structured metadata. + The reason why in this base class the field event_type is nonetheless kept + is to offer a place whereby practically users may enter data for + follow-up modifications to support arriving at an improved :ref:`NXevent_data_em` base class. + (NXimage_r_set_diff): + (NXimage_r_set): + (NXimage_c_set): (NXspectrum_set): - (NXinstrument): + em_lab(NXinstrument): + doc: | + (Meta)data of the dynamics and changes of the microscope during the event. + # no need to duplicate the fabrication because that should remain the + (NXchamber): + (NXebeam_column): + (NXibeam_column): + (NXoptical_system_em): + (NXdetector): + (NXpump): + (NXstage_lab): (NXuser): (NXinteraction_vol_em): - - # a collection of images take and group under this event - # NEW ISSUE: should this only be one instance for a given event? - # (NXimage_set_em_se): - # (NXimage_set_em_bse): - # (NXimage_set_em_ecci): - # (NXimage_set_em_bf): - # (NXimage_set_em_df): - # (NXimage_set_em_adf): - # (NXimage_set_em_kikuchi): - # (NXimage_set_em_diffrac): - # (NXspectrum_set_em_xray): - # (NXspectrum_set_em_eels): - # (NXspectrum_set_em_auger): - # (NXspectrum_set_em_cathodolum): - # (NXimage_set_em_ronchigram): - # (NXimage_set_em_chamber): - # a collection of specific details about state of the microscope - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e1f920846240b7fcddcb72c7ff92d370528612c709b0ca59c2bb0d8df5897dc6 -# -# -# -# -# -# Metadata and settings of an electron microscope for scans and images. -# -# The need for such a structuring of data is evident from the fact that -# electron microscopes are dynamic. Oftentimes it suffices to calibrate the -# instrument at the start of the session. Subsequently, data (images, spectra, etc.) -# can be collected. Users may wish to take only a single scan or image and -# complete their microscope session; however -# -# frequently users are working much longer at the microscope, recalibrate and take -# multiple data items (scans, images, spectra). Each item comes with own detector -# and eventually on-the-fly processing settings and calibrations. -# -# For the single data item use case one may argue that the need for an additional -# grouping is redundant. Instead, the metadata could equally be stored inside -# the respective groups of the top-level mandatory NXinstrument group. -# On the flip side, even for a session with a single image, it would also not -# harm to nest the data. -# -# In fact, oftentimes scientists feel that there is a need to store details -# about eventual drift of the specimen in its holder (if such data is available) -# or record changes to the lens excitations or apertures used and/or changed. -# Although current microscopes are usually equipped with stabilization -# systems for many of the individual components, it can still be useful -# to store time-dependent data in detail. -# -# Another reason if not a need for having more finely granularizable options for -# storing time-dependent data, is that over the course of a session one may -# reconfigure the microscope. What is a reconfiguration? This could be the -# change of an aperture mode because a scientist may first collect an image -# with some aperture and then pick a different value and continue. -# As the aperture affects the electron beam, it will affect the system. -# -# Let aside for a moment the technology and business models, an EM could be -# monitored (and will likely become so more in the future) for streaming out -# spatio-temporal details about its components, locations of (hardware components) and objects within the region-of-interest. Eventually external stimuli are applied -# and the specimen repositioned. -# -# Some snapshot or integrated data from this stream are relevant for understanding -# signal genesis and electron/ion-beam-sample interaction (paths). In such a generic -# case it might be necessary to sync these streaming data with those intervals -# in time when specific measurements are taken (spectra collected, -# images taken, diffraction images indexed on-the-fly). -# -# Therefore, both the instrument and specimen should always be considered as dynamic. -# Scientists often report or feel (difficult to quantify) observations that -# microscopes *perform differently* across sessions, without sometimes being -# able to identify clear root causes. Users of the instrument may consider -# such conditions impractical, or *too poor* and thus either abort their session -# or try to bring the microscope first into a state where conditions are considered -# more stable, better, or of some whatever high enough quality to reuse -# data collection. -# -# In all these cases it is practical to have a mechanism how time-dependent data -# of the instrument state can be stored and documented in a interoperable way. -# Where should these data be stored? With NeXus these data should not only be -# stored in the respective instrument component groups of the top-level NXinstrument. -# The reason is that this group should be reserved for as stable as possible -# quantities which do not change over the session. Thereby we can avoid to store -# repetitively that there is a certain gun or detector available but just store -# the changes. This is exactly what the em_lab group is for inside NXevent_data_em. -# -# Ideally, NXevent_data_em are equipped with a start_time and end_time -# to represent a time interval (remind the idea of the instrument state stream) -# during which the scientist considered (or practically has to consider) -# the microscope (especially ebeam and specimen) as stable enough. -# -# Arguably it is oftentimes tricky to specify a clear time interval when the -# microscope is stable enough. Take for instance the acquisition of an image -# or spectra stack. It is not fully possible (technically) to avoid that even -# within a single image instabilities of the beam are faced and drift occurs. -# Maybe in many cases this these instabilities are irrelevant but does this -# warrant to create a data schema where either the microscope state can only -# be stored very coarsely or one is forced to store it very finely? -# -# This is a question of how one wishes to granularize pieces of information. -# A possible solution is to consider each probed position, i.e. point in time -# when the beam was not blanked and thus when the beam illuminates a portion of -# the material, i.e. the interaction volume, whose signal contributions are then -# counted by the one or multiple detector(s) as per pixel- or per voxel signal -# in the region-of-interest. -# NXevent_data_em in combination with the NXem application definition -# allows researchers to document this. Noteworty to mention is that we understand -# that in many cases realizing such a fine temporal and logical granularization -# and data collection is hard to achieve in practice. -# -# A frequently made choice, mainly for convenience, is that drift and scan distortions -# are considered a feature or inaccuracy of the image and/or spectrum and thus -# one de facto accepts that the microscope was not as stable as expected during -# the acquisition of the image. We learn that the idea of a time interval -# during the microscope session may be interpreted differently by different -# users. Here we consider the choice to focus on images and spectra, and eventually -# single position measurements as the smallest granularization level. -# Which eventually may require to add optional NXprocess instances for respectively -# collected data to describe the relevant distortions. Nevertheless, the distortions -# are typically corrected for by numerical protocols. This fact warrants to -# consider the distortion correction a computational workflow which can be -# modelled as a chain of NXprocess instances each with own parameters. an own -# A more detailed overview of such computational steps to cope with scan distortions -# is available in the literature: -# -# * `C. Ophus et al. <https://dx.doi.org/10.1016/j.ultramic.2015.12.002>`_ -# * `B. Berkels et al. <https://doi.org/10.1016/j.ultramic.2018.12.016>`_ -# * `L. Jones et al. <https://link.springer.com/article/10.1186/s40679-015-0008-4>`_ -# -# For specific simulation purposes, mainly in an effort to digitally repeat -# or simulate the experiment, it is tempting to consider dynamics of the -# instrument, implemented as time-dependent functional descriptions of -# e.g. lens excitations, beam shape functions, trajectories of groups of -# electrons, or detector noise models. -# -# For now the preferred strategy to handle these cases is through -# customizations of the specific fields within NXevent_data_em instances. -# -# Another alternative could be to sample finer, eventually dissimilarly along -# the time axi; however this may cause situations where an NXevent_data_em -# instance does not contain specific measurements (i.e. images, spectra of -# scientific relevance). -# -# In this case one should better go for a customized application definition -# with a functional property description inside members (fields or groups) -# in NXevent_data_em instances; or resort to a specific offspring application -# definition of NXem which documents metadata for tracking explicitly electrons -# (with ray-tracing based descriptors/computational geometry descriptors) -# or tracking of wave bundles. -# -# This perspective on much more subtle time-dependent considerations of electron -# microscopy can be advantageous also for storing details of time-dependent -# additional components that are coupled to and/or synced with a microscope. -# -# Examples include cutting-edge experiments where the electron beam gets -# coupled/excited by e.g. lasers. In this case, the laser unit should be -# registered under the top-level NXinstrument section. Its spatio-temporal -# details could be stored inside respective additional groups of the NXinstrument -# though inside instances of here detailed NXevent_data_em. -# -# -# -# ISO 8601 time code with local time zone offset to UTC information included -# when the snapshot time interval started. If the user wishes to specify an -# interval of time that the snapshot should represent during which the instrument -# was stable and configured using specific settings and calibrations, -# the start_time is the start (left bound of the time interval) while -# the end_time specifies the end (right bound) of the time interval. -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC information included -# when the snapshot time interval ended. -# -# -# -# -# Reference to a specific state and setting of the microscope. -# -# -# -# -# Which specific event/measurement type. Examples are: -# -# * In-lens/backscattered electron, usually has quadrants -# * Secondary_electron, image, topography, fractography, overview images -# * Backscattered_electron, image, Z or channeling contrast (ECCI) -# * Bright_field, image, TEM -# * Dark_field, image, crystal defects -# * Annular dark field, image (medium- or high-angle), TEM -# * Diffraction, image, TEM, or a comparable technique in the SEM -# * Kikuchi, image, SEM EBSD and TEM diffraction -# * X-ray spectra (point, line, surface, volume), composition EDS/EDX(S) -# * Electron energy loss spectra for points, lines, surfaces, TEM -# * Auger, spectrum, (low Z contrast element composition) -# * Cathodoluminescence (optical spectra) -# * Ronchigram, image, alignment utility specifically in TEM -# * Chamber, e.g. TV camera inside the chamber, education purposes. -# -# This field may also be used for storing additional information about the event. -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXevent_data_em_set.yaml b/contributed_definitions/nyaml/NXevent_data_em_set.yaml index 70147d8b36..e6f850f011 100644 --- a/contributed_definitions/nyaml/NXevent_data_em_set.yaml +++ b/contributed_definitions/nyaml/NXevent_data_em_set.yaml @@ -1,44 +1,21 @@ category: base doc: | - Container to hold NXevent_data_em instances of an electron microscope session. + Base class for a set of :ref:`NXevent_data_em` instances. - An event is a time interval during which the microscope was configured, - considered stable, and used for characterization. + Members of the set are instances of :ref:`NXevent_data_em`. These have an associated + time interval during which the conditions were considered stable and + fit enough for purpose. + + Which temporal granularity is adequate depends on the situation and + research question. Using a model which enables a collection of events offers + the most flexible way to cater for both experiments with controlled electron + beams in a real microscope or the simulation of such experiments or + individual aspects of such experiments. type: group NXevent_data_em_set(NXobject): + # because it should be possible to use the application definition + # to store e.g. just some descriptions about the instrument + # to which eventually no measurements are attached + # this would enable to use nxs files also for instrument + # inventory system like offered through ELNs/or LIMS (NXevent_data_em): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 43012f9bcf4070d297318882afa6bb8afb9bd3e3c7c1b847c489bdb73ca7472c -# -# -# -# -# -# Container to hold NXevent_data_em instances of an electron microscope session. -# -# An event is a time interval during which the microscope was configured, -# considered stable, and used for characterization. -# -# -# diff --git a/contributed_definitions/nyaml/NXfabrication.yaml b/contributed_definitions/nyaml/NXfabrication.yaml index 62e2fedcb9..387e4a4649 100644 --- a/contributed_definitions/nyaml/NXfabrication.yaml +++ b/contributed_definitions/nyaml/NXfabrication.yaml @@ -1,75 +1,19 @@ category: base doc: | - Details about a component as defined by its manufacturer. + Details about a component as it is defined by its manufacturer. type: group NXfabrication(NXobject): - vendor: + vendor(NX_CHAR): doc: | Company name of the manufacturer. - model: + model(NX_CHAR): doc: | Version or model of the component named by the manufacturer. - identifier: + identifier(NX_CHAR): doc: | Ideally, (globally) unique persistent identifier, i.e. a serial number or hash identifier of the component. - capability: + capability(NX_CHAR): doc: | Free-text list with eventually multiple terms of functionalities which the component offers. - - # NEW ISSUE: Define a bag of controlled words and use only these. Examples are Feg, Astar, OmegaFilter. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 133eb1373b25af6bd05ca17ceeab4a0de2cf663af86b16420411f38bcedc59ab -# -# -# -# -# -# Details about a component as defined by its manufacturer. -# -# -# -# Company name of the manufacturer. -# -# -# -# -# Version or model of the component named by the manufacturer. -# -# -# -# -# Ideally, (globally) unique persistent identifier, i.e. -# a serial number or hash identifier of the component. -# -# -# -# -# Free-text list with eventually multiple terms of -# functionalities which the component offers. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXgraph_edge_set.yaml b/contributed_definitions/nyaml/NXgraph_edge_set.yaml index 4dacb8e595..09bf0c0a5f 100644 --- a/contributed_definitions/nyaml/NXgraph_edge_set.yaml +++ b/contributed_definitions/nyaml/NXgraph_edge_set.yaml @@ -1,6 +1,10 @@ category: base doc: | - A set of (eventually directed) edges which connect nodes/vertices of a graph. + A set of (eventually directed) edges which connect nodes of a graph. + + Use as a direct child of an instance of :ref:`NXgraph_root`. + Alternatively, use depends_on to specify which instance + of :ref:`NXgraph_root` is defined by this instance. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -8,31 +12,30 @@ symbols: The number of edges. type: group NXgraph_edge_set(NXobject): - number_of_edges(NX_POSINT): - unit: NX_UNITLESS + \@depends_on(NX_CHAR): + doc: | + Specify which instance of :ref:`NXgraph_root` this :ref:`NXgraph_edge_set` refers to. + number_of_edges(NX_UINT): doc: | Total number of edges, counting eventual bidirectional edges only once. - identifier_offset(NX_INT): unit: NX_UNITLESS + identifier_offset(NX_INT): doc: | Integer which specifies the first index to be used for distinguishing - edges. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. + edges. Identifiers are defined either implicitly or explicitly. - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - identifier(NX_INT): + For implicit indexing the identifiers are defined on the interval + :math:`[identifier_offset, identifier_offset + c - 1]`. + + For explicit indexing use the field identifier. For implicit indexing, + consult :ref:`NXcg_primitive_set` to get guidance how to set identifier_offset. unit: NX_UNITLESS + identifier(NX_INT): doc: | Integer used to distinguish edges for explicit indexing. - dimensions: - rank: 1 - dim: [[1, n_edges]] - directionality(NX_INT): unit: NX_UNITLESS + dim: (n_edges,) + directionality(NX_UINT): doc: | Specifier whether each edge is non-directional, one-directional, or bidirectional. Use the smallest available binary representation @@ -41,151 +44,27 @@ NXgraph_edge_set(NXobject): * 0 / state 0x00 is non-directional * 1 / state 0x01 is one-directional * 2 / state 0x02 is bi-directional - dimensions: - rank: 1 - dim: [[1, n_edges]] - node_pair(NX_INT): unit: NX_UNITLESS + dim: (n_edges,) + node_pair(NX_INT): doc: | Pairs of node/vertex identifier. Each pair represents the connection - between two nodes. + between two nodes. The order in the pair encodes eventual directionality. - In the case that the edge is non- or bi-directional - node identifier should be stored in ascending order is preferred. + In the case that an edge is non- or bi-directional, storing + node identifier in ascending order is preferred. - In the case of one-directional, for each pair the identifier of the source - node is the first entry in the pair. The identifier of the target is the - second entry in the pair, i.e. the pair encodes the information as - if one traverses the edge from the source node walking to the target node. - dimensions: - rank: 2 - dim: [[1, n_edges], [2, 2]] - is_a: + In the case that an edge is one-directional, node identifier should be + stored such that the identifier of the source node is the first entry + and the identifier of the target is the second entry in the pair. + unit: NX_UNITLESS + dim: (n_edges, 2) + is_a(NX_CHAR): doc: | A human-readable qualifier which type or e.g. class instance the edge is an instance of. - dimensions: - rank: 1 - dim: [[1, c]] - label: + dim: (n_edges,) + label(NX_CHAR): doc: | - A human-readable label/caption/tag for the edge. - dimensions: - rank: 1 - dim: [[1, n_edges]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 628c4419049ea786aefca290c517b78ee5da3b581ab73c1b4b8052c1184b1fda -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The number of edges. -# -# -# -# -# A set of (eventually directed) edges which connect nodes/vertices of a graph. -# -# -# -# Total number of edges, counting eventual bidirectional edges only once. -# -# -# -# -# Integer which specifies the first index to be used for distinguishing -# edges. Identifiers are defined either implicitly -# or explicitly. For implicit indexing the identifiers are defined on the -# interval [identifier_offset, identifier_offset+c-1]. -# For explicit indexing the identifier array has to be defined. -# -# The identifier_offset field can for example be used to communicate if the -# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) -# or from 0 (referred to as C-, Python-style index notation) respectively. -# -# -# -# -# Integer used to distinguish edges for explicit indexing. -# -# -# -# -# -# -# -# Specifier whether each edge is non-directional, one-directional, -# or bidirectional. Use the smallest available binary representation -# which can store three different states: -# -# * 0 / state 0x00 is non-directional -# * 1 / state 0x01 is one-directional -# * 2 / state 0x02 is bi-directional -# -# -# -# -# -# -# -# Pairs of node/vertex identifier. Each pair represents the connection -# between two nodes. -# -# In the case that the edge is non- or bi-directional -# node identifier should be stored in ascending order is preferred. -# -# In the case of one-directional, for each pair the identifier of the source -# node is the first entry in the pair. The identifier of the target is the -# second entry in the pair, i.e. the pair encodes the information as -# if one traverses the edge from the source node walking to the target node. -# -# -# -# -# -# -# -# -# A human-readable qualifier which type or e.g. class instance the -# edge is an instance of. -# -# -# -# -# -# -# -# A human-readable label/caption/tag for the edge. -# -# -# -# -# -# + A human-readable label/caption/tag of each edge. + dim: (n_edges,) diff --git a/contributed_definitions/nyaml/NXgraph_node_set.yaml b/contributed_definitions/nyaml/NXgraph_node_set.yaml index 3612252002..93e8ac08ba 100644 --- a/contributed_definitions/nyaml/NXgraph_node_set.yaml +++ b/contributed_definitions/nyaml/NXgraph_node_set.yaml @@ -1,148 +1,61 @@ category: base doc: | - A set of nodes/vertices in space representing members of a graph. - -# a graph in which space d-dimensional, categorical, at all a metric one? + A set of nodes representing members of a graph. + + Use as a direct child of an instance of :ref:`NXgraph_root`. + Alternatively, use depends_on to specify which instance + of NXgraph_root is defined by this instance. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. + c: | + The cardinality of the set, i.e. the number of nodes of the graph. d: | The dimensionality of the graph. Eventually use one for categorical. - c: | - The cardinality of the set, i.e. the number of nodes/vertices of the graph. type: group NXgraph_node_set(NXobject): - dimensionality(NX_POSINT): + \@depends_on(NX_CHAR): + doc: | + Specify which instance of :ref:`NXgraph_root` this :ref:`NXgraph_node_set` refers to. + space(NX_CHAR): + doc: | + About which space does the graph make statements. + enumeration: [euclidean, other] + dimensionality(NX_UINT): + doc: | + Dimensionality of the space about which the graph makes statements. + Use only when value of the field space is euclidean. unit: NX_UNITLESS - cardinality(NX_POSINT): + enumeration: [1, 2, 3] + cardinality(NX_UINT): + doc: | + Number of nodes of the graph. unit: NX_UNITLESS identifier_offset(NX_INT): - unit: NX_UNITLESS doc: | Integer which specifies the first index to be used for distinguishing - nodes. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. + nodes. Identifiers are defined either implicitly or explicitly. - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - identifier(NX_INT): + For implicit indexing the identifiers are defined on the interval + :math:`[identifier_offset, identifier_offset + c - 1]`. + + For explicit indexing use the field identifier. For implicit indexing, + consult :ref:`NXcg_primitive_set` to get guidance how to set identifier_offset. unit: NX_UNITLESS + identifier(NX_INT): doc: | Integer used to distinguish nodes for explicit indexing. - dimensions: - rank: 1 - dim: [[1, c]] - is_a: + unit: NX_UNITLESS + dim: (c,) + is_a(NX_CHAR): doc: | A human-readable qualifier which type or e.g. class instance the - node is an instance of. As e.g. a NeXus application definition is a - graph, more specifically a hierarchical directed labelled property graph, - instances which are groups like NXgraph_node_set could have an is_a - qualifier reading NXgraph_node_set. - dimensions: - rank: 1 - dim: [[1, c]] - label: + node is an instance of. An example: a NeXus application definition is a + graph, more specifically a hierarchical directed labelled property graph. + Instances which are groups like :ref:`NXgraph_node_set` could have an is_a + qualifier reading :ref:`NXgraph_node_set`. + dim: (c,) + label(NX_CHAR): doc: | - A human-readable label/caption/tag of the graph. - dimensions: - rank: 1 - dim: [[1, c]] - - # how to handle arrays which are compressed? This can be useful for instance - # if there are substantially fewer disjoint labels than c - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 29e94d3fcf2b74e364c91e7b6b9ee36949726aaf5fb1623e42b3c7a688fda6bc -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality of the graph. Eventually use one for categorical. -# -# -# -# -# The cardinality of the set, i.e. the number of nodes/vertices of the graph. -# -# -# -# -# A set of nodes/vertices in space representing members of a graph. -# -# -# -# -# -# Integer which specifies the first index to be used for distinguishing -# nodes. Identifiers are defined either implicitly -# or explicitly. For implicit indexing the identifiers are defined on the -# interval [identifier_offset, identifier_offset+c-1]. -# For explicit indexing the identifier array has to be defined. -# -# The identifier_offset field can for example be used to communicate if the -# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) -# or from 0 (referred to as C-, Python-style index notation) respectively. -# -# -# -# -# Integer used to distinguish nodes for explicit indexing. -# -# -# -# -# -# -# -# A human-readable qualifier which type or e.g. class instance the -# node is an instance of. As e.g. a NeXus application definition is a -# graph, more specifically a hierarchical directed labelled property graph, -# instances which are groups like NXgraph_node_set could have an is_a -# qualifier reading NXgraph_node_set. -# -# -# -# -# -# -# -# A human-readable label/caption/tag of the graph. -# -# -# -# -# -# -# + A human-readable label/caption/tag of each node. + dim: (c,) diff --git a/contributed_definitions/nyaml/NXgraph_root.yaml b/contributed_definitions/nyaml/NXgraph_root.yaml index 6cce442e79..6fce3503c9 100644 --- a/contributed_definitions/nyaml/NXgraph_root.yaml +++ b/contributed_definitions/nyaml/NXgraph_root.yaml @@ -8,44 +8,3 @@ type: group NXgraph_root(NXobject): nodes(NXgraph_node_set): relation(NXgraph_edge_set): - - # further attributes - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 1ebca361ac2a2c0e291dc0ddcf551de225aa9ac98375468ff58bb0d98ef5542d -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# An instance of a graph. -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXibeam_column.yaml b/contributed_definitions/nyaml/NXibeam_column.yaml index 8532c7ecb5..e02716619b 100644 --- a/contributed_definitions/nyaml/NXibeam_column.yaml +++ b/contributed_definitions/nyaml/NXibeam_column.yaml @@ -1,18 +1,18 @@ category: base doc: | - Container for components of a focused-ion-beam (FIB) system. + Base class for a set of components equipping an instrument with FIB capabilities. - FIB capabilities turn especially scanning electron microscopes - into specimen preparation labs. FIB is a material preparation - technique whereby portions of the sample are illuminated with a - focused ion beam with controlled intensity intense enough and with - sufficient ion momentum to remove material in a controllable manner. + Focused-ion-beam (FIB) capabilities turn especially scanning electron microscopes + into specimen preparation labs. FIB is a material preparation technique whereby + portions of the sample are illuminated with a focused ion beam with controlled + intensity. The beam is intense enough and with sufficient ion momentum to + remove material in a controlled manner. The fact that an electron microscope with FIB capabilities has needs a - second gun with own relevant control circuits, focusing lenses, and - other components, warrants an own base class to group these components - and distinguish them from the lenses and components for creating and - shaping the electron beam. + second gun with own relevant control circuits, focusing lenses, and other + components, warrants the definition of an own base class to group these + components and distinguish them from the lenses and components for creating + and shaping the electron beam. For more details about the relevant physics and application examples consult the literature, for example: @@ -25,22 +25,25 @@ doc: | # symbols: # doc: The symbols used in the schema to specify e.g. variables. type: group +# NXibeam_column is an NXobject instead of an NXcomponent_em to make that +# part "an ion gun" reusable in other context NXibeam_column(NXobject): + (NXchamber): (NXfabrication): ion_source(NXsource): doc: | The source which creates the ion beam. - name: + name(NX_CHAR): doc: | Given name/alias for the ion gun. - emitter_type: + emitter_type(NX_CHAR): doc: | Emitter type used to create the ion beam. If the emitter type is other, give further details in the description field. enumeration: [liquid_metal, plasma, gas_field, other] - description: + description(NX_CHAR): # NXidentifier doc: | Ideally, a (globally) unique persistent identifier, link, or text to a resource which gives further details. @@ -49,47 +52,46 @@ NXibeam_column(NXobject): Which ionized elements or molecular ions form the beam. Examples are gallium, helium, neon, argon, krypton, or xenon, O2+. - - # NEW ISSUE: use NXion instead - brightness(NX_FLOAT): - unit: NX_ANY + flux(NX_NUMBER): + doc: | + Average/nominal flux + unit: NX_ANY # 1/(area*time) + brightness(NX_NUMBER): doc: | Average/nominal brightness - + unit: NX_ANY # 1/steradiant or area # \@units: A/cm*sr # NEW ISSUE: (at which location?). - current(NX_FLOAT): - unit: NX_CURRENT + current(NX_NUMBER): doc: | Charge current - voltage(NX_FLOAT): - unit: NX_VOLTAGE + unit: NX_CURRENT + voltage(NX_NUMBER): doc: | - Ion acceleration voltage upon source exit and entering the vacuum flight path. + Ion acceleration voltage upon source exit and + entering the vacuum flight path. + unit: NX_VOLTAGE ion_energy_profile(NX_NUMBER): + doc: | + To be defined more specifically. Community suggestions are welcome. unit: NX_ENERGY (NXtransformations): doc: | - Affine transformation which detail the arrangement in the microscope relative to - the optical axis and beam path. - + Collection of axis-based translations and rotations to describe the + location and geometry of the component in the instrument. # NEW ISSUE: details about the life/up-time of the source # relevant from maintenance point of view (NXaperture_em): (NXlens_em): - - # ibeam_deflector(NXscanbox_em): + (NXscanbox_em): (NXsensor): (NXbeam): doc: | Individual characterization results for the position, shape, and characteristics of the ion beam. - NXtransformations should be used to specify the location or position + :ref:`NXtransformations` should be used to specify the location or position at which details about the ion beam are probed. - - # all these components of the FIB system are usually controlled via an - # instrment control software that is often part of the e.g. microscope control # software or at least linked to this software. # NEW ISSUE: scan_align(NXprocess): # NEW ISSUE: milling_plan(NXprocess): # doc: Description of the program and sequence of sample positions sputtered. @@ -104,150 +106,3 @@ NXibeam_column(NXobject): # ion gun coordinate system has to be rotated to align its positive z-axis # with the positive z-axis of e.g. the electron beam and ion beam # respectively. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 48d294299188b58b704f5def9752b4f13ada376f461333073b0a6f861066d480 -# -# -# -# -# -# -# Container for components of a focused-ion-beam (FIB) system. -# -# FIB capabilities turn especially scanning electron microscopes -# into specimen preparation labs. FIB is a material preparation -# technique whereby portions of the sample are illuminated with a -# focused ion beam with controlled intensity intense enough and with -# sufficient ion momentum to remove material in a controllable manner. -# -# The fact that an electron microscope with FIB capabilities has needs a -# second gun with own relevant control circuits, focusing lenses, and -# other components, warrants an own base class to group these components -# and distinguish them from the lenses and components for creating and -# shaping the electron beam. -# -# For more details about the relevant physics and application examples -# consult the literature, for example: -# -# * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ -# * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ -# * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ -# * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ -# -# -# -# -# The source which creates the ion beam. -# -# -# -# Given name/alias for the ion gun. -# -# -# -# -# Emitter type used to create the ion beam. -# -# If the emitter type is other, give further -# details in the description field. -# -# -# -# -# -# -# -# -# -# -# Ideally, a (globally) unique persistent identifier, link, -# or text to a resource which gives further details. -# -# -# -# -# Which ionized elements or molecular ions form the beam. -# Examples are gallium, helium, neon, argon, krypton, -# or xenon, O2+. -# -# -# -# -# -# Average/nominal brightness -# -# -# -# -# -# Charge current -# -# -# -# -# Ion acceleration voltage upon source exit and entering the vacuum flight path. -# -# -# -# -# -# Affine transformation which detail the arrangement in the microscope relative to -# the optical axis and beam path. -# -# -# -# -# -# -# -# -# -# -# Individual characterization results for the position, shape, -# and characteristics of the ion beam. -# -# NXtransformations should be used to specify the location or position -# at which details about the ion beam are probed. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXimage_c_set.yaml b/contributed_definitions/nyaml/NXimage_c_set.yaml new file mode 100644 index 0000000000..8dcd85706d --- /dev/null +++ b/contributed_definitions/nyaml/NXimage_c_set.yaml @@ -0,0 +1,140 @@ +category: base +doc: | + Specialized base class container for reporting a set of images in reciprocal space. + + In practice, complex numbers are encoded via some formatted pair of real values. + Typically, fast Algorithms for computing Fourier Transformations (FFT) are + used to encode images in reciprocal (frequency) space. FFT libraries are used + for implementing the key functionalities of these mathematical operations. + + Different libraries use different representations and encoding of the + image computed. Details can be found in the respective sections of the + typical FFT libraries: + + * `FFTW by M. Frigo and S. G. Johnson `_ + * `Intel MKL by the Intel Co. `_ + * `cuFFT by the NVidia Co. `_ + + Users are strongly advised to inspect carefully which specific conventions + their library uses to be able to store and modify the implementation of their + code so that the serialized representations as it is detailed + here for NeXus matches with their intention. + + One- and two-dimensional FFTs should use the stack(NXdata) instances. + Three-dimensional FFTs should use the hyperstack(NXdata) instances. +symbols: + n_images: | + Number of images in the (hyper)stack. + n_k: | + Number of pixel per image in the slowest direction. + n_j: | + Number of pixel per image in the slow direction. + n_i: | + Number of pixel per image in the fast direction. +type: group +NXimage_c_set(NXimage_set): + # details about the FFT library used could for instance be stored in the + # NXprocess group which the NXimage_c_set base class can borrow from its + # NXimage_set parent base class + # process information are composable from the NXimage_set base class + stack(NXdata): + doc: | + Image stack. + real(NX_NUMBER): + doc: | + Image intensity of the real part. + unit: NX_UNITLESS + dim: (n_images, n_j, n_i) + imag(NX_NUMBER): + doc: | + Image intensity of the imaginary part. + unit: NX_UNITLESS + dim: (n_images, n_j, n_i) + magnitude(NX_NUMBER): + doc: | + Magnitude of the image intensity. + unit: NX_UNITLESS + dim: (n_images, n_j, n_i) + axis_image_identifier(NX_INT): + doc: | + Image identifier + unit: NX_UNITLESS + dim: (n_images,) + \@long_name(NX_CHAR): + doc: | + Image identifier. + # axis_k(NX_NUMBER): + # doc: | + # Pixel coordinate center along k direction. + # unit: NX_ANY # NX_RECIPROCAL_LENGTH + # dim: (n_k,) + # \@long_name(NX_CHAR): + # doc: | + # Coordinate along j direction. + axis_j(NX_NUMBER): + doc: | + Pixel coordinate center along j direction. + unit: NX_ANY # NX_RECIPROCAL_LENGTH + dim: (n_j,) + \@long_name(NX_CHAR): + doc: | + Coordinate along j direction. + axis_i(NX_NUMBER): + doc: | + Pixel coordinate center along i direction. + unit: NX_ANY # NX_RECIPROCAL_LENGTH + dim: (n_i,) + \@long_name(NX_CHAR): + doc: | + Coordinate along i direction. + + hyperstack(NXdata): + doc: | + Image hyperstack. + real(NX_NUMBER): + doc: | + Image intensity of the real part. + unit: NX_UNITLESS + dim: (n_images, n_k, n_j, n_i) + imag(NX_NUMBER): + doc: | + Image intensity of the imaginary part. + unit: NX_UNITLESS + dim: (n_images, n_k, n_j, n_i) + magnitude(NX_NUMBER): + doc: | + Magnitude of the image intensity. + unit: NX_UNITLESS + dim: (n_images, n_k, n_j, n_i) + axis_image_identifier(NX_INT): + doc: | + Image identifier + unit: NX_UNITLESS + dim: (n_images,) + \@long_name(NX_CHAR): + doc: | + Image identifier. + axis_k(NX_NUMBER): + doc: | + Pixel coordinate center along k direction. + unit: NX_ANY # NX_RECIPROCAL_LENGTH + dim: (n_k,) + \@long_name(NX_CHAR): + doc: | + Coordinate along j direction. + axis_j(NX_NUMBER): + doc: | + Pixel coordinate center along j direction. + unit: NX_ANY # NX_RECIPROCAL_LENGTH + dim: (n_j,) + \@long_name(NX_CHAR): + doc: | + Coordinate along j direction. + axis_i(NX_NUMBER): + doc: | + Pixel coordinate center along i direction. + unit: NX_ANY # NX_RECIPROCAL_LENGTH + dim: (n_i,) + \@long_name(NX_CHAR): + doc: | + Coordinate along i direction. diff --git a/contributed_definitions/nyaml/NXimage_r_set.yaml b/contributed_definitions/nyaml/NXimage_r_set.yaml new file mode 100644 index 0000000000..f0437e6e6f --- /dev/null +++ b/contributed_definitions/nyaml/NXimage_r_set.yaml @@ -0,0 +1,45 @@ +category: base +doc: | + Specialized base class container for reporting a set of images in real space. +symbols: + n_images: | + Number of images in the stack. + n_y: | + Number of pixel per image in the slow direction. + n_x: | + Number of pixel per image in the fast direction. +type: group +NXimage_r_set(NXimage_set): + # process information are composable from the NXimage_set base class + stack(NXdata): + doc: | + Image (stack). + intensity(NX_NUMBER): + doc: | + Image intensity values. + unit: NX_UNITLESS + dim: (n_images, n_y, n_x) + axis_image_identifier(NX_INT): + doc: | + Image identifier + unit: NX_UNITLESS + dim: (n_images,) + \@long_name(NX_CHAR): + doc: | + Image identifier. + axis_y(NX_NUMBER): + doc: | + Pixel coordinate center along y direction. + unit: NX_LENGTH + dim: (n_y,) + \@long_name(NX_CHAR): + doc: | + Coordinate along y direction. + axis_x(NX_NUMBER): + doc: | + Pixel coordinate center along x direction. + unit: NX_LENGTH + dim: (n_x,) + \@long_name(NX_CHAR): + doc: | + Coordinate along x direction. diff --git a/contributed_definitions/nyaml/NXimage_r_set_diff.yaml b/contributed_definitions/nyaml/NXimage_r_set_diff.yaml new file mode 100644 index 0000000000..79ca31b168 --- /dev/null +++ b/contributed_definitions/nyaml/NXimage_r_set_diff.yaml @@ -0,0 +1,123 @@ +category: base +doc: | + Base class specialized for reporting a cuboidal stack of diffraction pattern. + + Diffraction pattern, whether they were simulated or measured are the raw data + for computational workflows to characterize the phase and orientation + of crystalline regions in matter. + + Steps of post-processing the diffraction patterns should be documented using + method-specific specialized base classes. All eventual post-processing of + resulting orientation maps (2D or 3D) should be documented via :ref:`NXms_recon`. + + To implement an example how this base class can be used we focused in FAIRmat + on Kikuchi diffraction pattern here specifically the research community + of Electron Backscatter Diffraction (EBSD). + + For this reason, this base class and related :ref:`NXem_base` classes extend the + work of `M. A. Jackson et al. `_ + (one of the developers of DREAM.3D) and the H5OINA public file format developed by + `P. Pinard et al. `_ with Oxford Instruments. + + Kikuchi pattern are typically collected with FIB/SEM microscopes, + for two- and three-dimensional orientation microscopy. + + For a detailed overview of these techniques see e.g. + + * `M. A. Groeber et al. `_ + * `A. J. Schwartz et al. `_ + * `P. A. Rottman et al. `_ + + Serial-sectioning demands a recurrent sequence of ion milling and measuring. + This suggests that each serial section is at least an own NXevent_data_em + instance. The three-dimensional characterization as such demands a computational + step where the maps for each serial section get cleaned, aligned, and registered + into an image stack. This image stack represents a digital model of the + inspected microstructural volume. Often this volume is called a (representative) + volume element (RVE). Several software packages exists for performing + these post-processing tasks. + + This example may inspire users of other types of diffraction methods. +symbols: + n_sc: | + Number of scanned points. Scan point may have none, one, or more pattern. + n_p: | + Number of diffraction pattern. + n_y: | + Number of pixel per pattern in the slow direction. + n_x: | + Number of pixel per pattern in the fast direction. +type: group +NXimage_r_set_diff(NXimage_r_set): + pattern_type(NX_CHAR): + doc: | + Category which type of diffraction pattern is reported. + enumeration: [kikuchi] + stack(NXdata): + doc: | + Collected diffraction pattern as an image stack. As raw and closest to the + first retrievable measured data as possible, i.e. do not use this + container to store already averaged, filtered or whatever post-processed + pattern unless these are generated unmodifiably in such manner by the + instrument given the way how the instrument and control software + was configured for your microscope session. + scan_point_identifier(NX_INT): + doc: | + Array which resolves the scan point to which each pattern belongs. + + Scan points are evaluated in sequence starting from scan point zero + until scan point n_sc - 1. Evaluating the cumulated of this array + decodes which pattern in intensity belongs to which scan point. + + Take an example with three scan points: The first scan point has one + pattern, the second has three pattern, the last scan point has no + pattern. In this case the scan_point_identifier are 0, 1, 1, 1. + The length of the scan_point_identifier array is four because four + pattern were measured in total. + + In most cases usually one pattern is averaged by the detector for + some amount of time and then reported as one pattern. + unit: NX_UNITLESS + dim: (n_p,) + intensity(NX_NUMBER): + doc: | + Intensity of the diffraction pattern. + unit: NX_UNITLESS + dim: (n_p, n_y, n_x) + # n_p fast 2, n_y faster 1, n_x fastest 0 + # in axes fast to fastest + # while for _indices fastest to fast + \@long_name(NX_CHAR): + doc: | + Pattern intensity + # \@signal: intensity + # \@axes: [pattern_identifier, ypos, xpos] + # \@xpos_indices: 0 + # \@ypos_indices: 1 + # \@pattern_identifier_indices: 2 + pattern_identifier(NX_INT): + doc: | + Pattern are enumerated starting from 0 to n_p - 1. + unit: NX_UNITLESS + dim: (n_p,) + \@long_name(NX_CHAR): + doc: | + Pattern identifier + # the following fields are taken from the NXimage_r_set base class + # axis_y(R): + # axis_x(R): + +# If we envision a (knowledge) graph for EBSD it consists of individual sub-graphs +# which convey information about the specimen preparation, the measurement of +# the specimen in the electron microscope, the indexing of the collected +# Kikuchi pattern stack, eventual post-processing of the indexed orientation +# images via similarity grouping algorithms to yield (grains, texture). +# Conceptually, these post-processing steps are most frequently serving +# the idea how can one reconstruct so-called microstructural features +# (grains, phases, interfaces) to infer material properties. +# In practice this calls for workflows which quantify correlations between +# the spatial arrangement of the microstructural features, the individual +# (thermodynamic, chemo-mechanical) properties of the features with the +# properties of materials at a coarser scale. +# With NXem and related NXms base classes we propose a covering +# and general solution how to handle such (meta)data with NeXus. diff --git a/contributed_definitions/nyaml/NXimage_set.yaml b/contributed_definitions/nyaml/NXimage_set.yaml index 289682d827..0bedd8d19c 100644 --- a/contributed_definitions/nyaml/NXimage_set.yaml +++ b/contributed_definitions/nyaml/NXimage_set.yaml @@ -1,6 +1,9 @@ category: base doc: | - Container for reporting a set of images taken. + Base class for reporting a set of images. + + This class provides a base vocabulary to be used for specialized :ref:`NXimage_set` + base classes like :ref:`NXimage_r_set` and :ref:`NXimage_c_set`. symbols: n_images: | Number of images in the stack. @@ -12,191 +15,19 @@ type: group NXimage_set(NXobject): (NXprocess): doc: | - Details how images were processed from the detector readings. - source: + Details how NXdata instance inside instance of (specialized) + :ref:`NXimage_set` were processed from the detector readings/raw data. + source(NXserialized): doc: | Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXimage_set were loaded during parsing. - \@version: - doc: | - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - mode: + the :ref:`NXdata` instances in this :ref:`NXimage_set` were loaded + during parsing. + mode(NX_CHAR): doc: | Imaging (data collection) mode of the instrument during acquisition - of the data in this NXimage_set instance. - detector_identifier: + of the data in this :ref:`NXimage_set` instance. + detector_identifier(NX_CHAR): doc: | - Link or name of an NXdetector instance with which the data were collected. + Link or name of an :ref:`NXdetector` instance with which the data were collected. (NXprogram): - stack(NXdata): - doc: | - Image (stack). - data_counts(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Image intensity values. - dimensions: - rank: 3 - dim: [[1, n_images], [2, n_y], [3, n_x]] - axis_image_identifier(NX_UINT): - unit: NX_UNITLESS - doc: | - Image identifier - dimensions: - rank: 1 - dim: [[1, n_images]] - \@long_name: - doc: | - Image identifier. - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Pixel coordinate center of mass along y direction. - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - doc: | - Coordinate along y direction. - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Pixel coordinate center of mass along x direction. - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - doc: | - Coordinate along x direction. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d8a2ad749b0efcaf144af79af9d4ea222dc72b0d946125be13563dd6d5ccb4c2 -# -# -# -# -# -# -# -# Number of images in the stack. -# -# -# -# -# Number of pixel per image in the slow direction. -# -# -# -# -# Number of pixel per image in the fast direction. -# -# -# -# -# Container for reporting a set of images taken. -# -# -# -# Details how images were processed from the detector readings. -# -# -# -# Resolvable data artifact (e.g. filename) from which the all values in -# the NXdata instances in this NXimage_set were loaded during parsing. -# -# -# -# An at least as strong as SHA256 hashvalue of the data artifact which -# source represents digitally to support provenance tracking. -# -# -# -# -# -# Imaging (data collection) mode of the instrument during acquisition -# of the data in this NXimage_set instance. -# -# -# -# -# Link or name of an NXdetector instance with which the data were collected. -# -# -# -# -# -# -# Image (stack). -# -# -# -# Image intensity values. -# -# -# -# -# -# -# -# -# -# Image identifier -# -# -# -# -# -# -# Image identifier. -# -# -# -# -# -# Pixel coordinate center of mass along y direction. -# -# -# -# -# -# -# Coordinate along y direction. -# -# -# -# -# -# Pixel coordinate center of mass along x direction. -# -# -# -# -# -# -# Coordinate along x direction. -# -# -# -# -# + (NXdata): diff --git a/contributed_definitions/nyaml/NXimage_set_em_adf.yaml b/contributed_definitions/nyaml/NXimage_set_em_adf.yaml deleted file mode 100644 index ca8673f6de..0000000000 --- a/contributed_definitions/nyaml/NXimage_set_em_adf.yaml +++ /dev/null @@ -1,257 +0,0 @@ -category: base -doc: | - Container for reporting a set of annular dark field images. - - Virtually the most important case is that spectra are collected in - a scanning microscope (SEM or STEM) for a collection of points. - The majority of cases use simple d-dimensional regular scan pattern, - such as single point, line profiles, or (rectangular) surface mappings. - The latter pattern is the most frequently used. - - For now the base class provides for scans for which the settings, - binning, and energy resolution is the same for each scan point. -symbols: - n_images: | - Number of images in the stack. - n_y: | - Number of pixel per image in the slow direction. - n_x: | - Number of pixel per image in the fast direction. -type: group -NXimage_set_em_adf(NXobject): - (NXprocess): - doc: | - Details how (HA)ADF images were processed from the detector readings. - source: - doc: | - Typically the name of the input, (vendor) file from which all - the NXdata instances in this NXimage_set_em_adf were loaded during - parsing to represent them in e.g. databases. - \@version: - doc: | - An at least as strong as SHA256 hashvalue of the dataset/file - which represents the source digitally to support provenance tracking. - program: - doc: | - Commercial or otherwise given name to the program which was used - to process detector data into the adf image(s). - \@version: - doc: | - Program version plus build number, commit hash, or description - of an ever persistent resource where the source code of the program - and build instructions can be found so that the program - can be configured in such a manner that the result file - is ideally recreatable yielding the same results. - adf_inner_half_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Annulus inner half angle - adf_outer_half_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Annulus outer half angle - stack(NXdata): - doc: | - Annular dark field image stack. - - # \@signal: intensity - # \@axes: [image_id, ypos, xpos] - # \@xpos_indices: 2 - # \@ypos_indices: 1 - # \@image_indices: 0 - data_counts(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Image intensity values. - dimensions: - rank: 3 - dim: [[1, n_images], [2, n_y], [3, n_x]] - axis_image_identifier(NX_UINT): - unit: NX_UNITLESS - doc: | - Image identifier - dimensions: - rank: 1 - dim: [[1, n_images]] - \@long_name: - doc: | - Image ID. - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Pixel center of mass along y direction. - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - doc: | - Coordinate along y direction. - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Pixel center of mass along x direction. - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - doc: | - Coordinate along x direction. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4af28c1f529beba15afbed5d28bccfaecc08b2c46e956fcaa3fe2e08ca4669e9 -# -# -# -# -# -# -# -# Number of images in the stack. -# -# -# -# -# Number of pixel per image in the slow direction. -# -# -# -# -# Number of pixel per image in the fast direction. -# -# -# -# -# Container for reporting a set of annular dark field images. -# -# Virtually the most important case is that spectra are collected in -# a scanning microscope (SEM or STEM) for a collection of points. -# The majority of cases use simple d-dimensional regular scan pattern, -# such as single point, line profiles, or (rectangular) surface mappings. -# The latter pattern is the most frequently used. -# -# For now the base class provides for scans for which the settings, -# binning, and energy resolution is the same for each scan point. -# -# -# -# Details how (HA)ADF images were processed from the detector readings. -# -# -# -# Typically the name of the input, (vendor) file from which all -# the NXdata instances in this NXimage_set_em_adf were loaded during -# parsing to represent them in e.g. databases. -# -# -# -# An at least as strong as SHA256 hashvalue of the dataset/file -# which represents the source digitally to support provenance tracking. -# -# -# -# -# -# Commercial or otherwise given name to the program which was used -# to process detector data into the adf image(s). -# -# -# -# Program version plus build number, commit hash, or description -# of an ever persistent resource where the source code of the program -# and build instructions can be found so that the program -# can be configured in such a manner that the result file -# is ideally recreatable yielding the same results. -# -# -# -# -# -# Annulus inner half angle -# -# -# -# -# Annulus outer half angle -# -# -# -# -# -# Annular dark field image stack. -# -# -# -# -# Image intensity values. -# -# -# -# -# -# -# -# -# -# Image identifier -# -# -# -# -# -# -# Image ID. -# -# -# -# -# -# Pixel center of mass along y direction. -# -# -# -# -# -# -# Coordinate along y direction. -# -# -# -# -# -# Pixel center of mass along x direction. -# -# -# -# -# -# -# Coordinate along x direction. -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXimage_set_em_kikuchi.yaml b/contributed_definitions/nyaml/NXimage_set_em_kikuchi.yaml deleted file mode 100644 index 91fae48349..0000000000 --- a/contributed_definitions/nyaml/NXimage_set_em_kikuchi.yaml +++ /dev/null @@ -1,362 +0,0 @@ -category: base -doc: | - Measured set of electron backscatter diffraction data, aka Kikuchi pattern. - Kikuchi pattern are the raw data for computational workflows in the field - of orientation (imaging) microscopy. The technique is especially used in - materials science and materials engineering. - - Based on a fuse of the `M. A. Jackson et al. `_ - of the DREAM.3D community and the open H5OINA format of Oxford Instruments - `P. Pinard et al. `_ - - EBSD can be used, usually with FIB/SEM microscopes, for three-dimensional - orientation microscopy. So-called serial section analyses. For a detailed - overview of these techniques see e.g. - - * `M. A. Groeber et al. `_ - * `A. J. Schwartz et al. `_ - * `P. A. Rottman et al. `_ - - With serial-sectioning this involves however always a sequence of measuring, - milling. In this regard, each serial section (measuring) and milling - is an own NXevent_data_em instance and thus there such a three-dimensional - characterization should be stored as a set of two-dimensional data, - with as many NXevent_data_em instances as sections were measured. - - These measured serial sectioning images need virtually always post-processing - to arrive at the aligned and cleaned image stack before a respective digital - model of the inspected microstructure can be analyzed. The resulting volume - is often termed a so-called (representative) volume element (RVE). - Several software packages are available for performing this post-processing. - For now we do not consider metadata of these post-processing steps - as a part of this base class because the connection between the large variety - of such post-processing steps and the measured electron microscopy data - is usually very small. - - If we envision a (knowledge) graph for EBSD it consists of individual - sub-graphs which convey information about the specimen preparation, - the measurement of the specimen in the electron microscope, - the indexing of the collected Kikuchi pattern stack, - eventual post-processing of the indexed orientation image - via similarity grouping algorithms to yield (grains, texture). - Conceptually these post-processing steps are most frequently - serving the idea to reconstruct quantitatively so-called - microstructural features (grains, phases, interfaces). Materials scientists - use these features according to the multi-scale materials modeling paradigm - to infer material properties. They do so by quantifying correlations between - the spatial arrangement of the features, their individual properties, - and (macroscopic) properties of materials. -symbols: - n_sc: | - Number of scanned points. Scan point may have none, one, or more pattern. - n_p: | - Number of diffraction pattern. - n_y: | - Number of pixel per Kikuchi pattern in the slow direction. - n_x: | - Number of pixel per Kikuchi pattern in the fast direction. -type: group -NXimage_set_em_kikuchi(NXobject): - - # a collection of pattern-related metadata - (NXprocess): - doc: | - Details how Kikuchi pattern were processed from the detector readings. - Scientists interested in EBSD should inspect the respective NXem_ebsd - application definition which can be used as a partner application definition - to detail substantially more details to this processing. - stack(NXdata): - doc: | - Collected Kikuchi pattern as an image stack. As raw and closest to the - first retrievable measured data as possible, i.e. do not use this - container to store already averaged, filtered or whatever post-processed - pattern unless these are generated unmodifiably by the instrument - given the way how the instrument and control software was configured - for your microscope session. - scan_point_identifier(NX_UINT): - unit: NX_UNITLESS - doc: | - Array which resolves the scan point to which each pattern belongs. - Scan points are evaluated in sequence starting from scan point zero - until scan point n_sc - 1. Evaluating the cumulated of this array - decodes which pattern in intensity belong to which scan point. - In an example we may assume we collected three scan points. For the first - we measure one pattern, for the second we measure three pattern, - for the last we measure no pattern. - The values of scan_point_identifier will be 0, 1, 1, 1, as we have - measured four pattern in total. - - In most cases usually one pattern is averaged by the detector for - some amount of time and then reported as one pattern. Use compressed - arrays allows to store the scan_point_identifier efficiently. - dimensions: - rank: 1 - dim: [[1, n_p]] - data_counts(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Signal intensity. For so-called three-dimensional or serial sectioning - EBSD it is necessary to follow a sequence of specimen surface preparation - and data collection. In this case users should collect the data for each - serial sectioning step in an own instance of NXimage_set_em_kikuchi. - All eventual post-processing of these measured data should be documented - via NXebsd, resulting microstructure representations should be stored - as NXms. - dimensions: - rank: 3 - dim: [[1, n_p], [2, n_y], [3, n_x]] - - # n_p fast 2, n_y faster 1, n_x fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - Kikuchi pattern intensity - - # \@signal: intensity - # \@axes: [pattern_identifier, ypos, xpos] - # \@xpos_indices: 0 - # \@ypos_indices: 1 - # \@pattern_identifier_indices: 2 - pattern_identifier(NX_UINT): - unit: NX_UNITLESS - doc: | - Pattern are enumerated starting from 0 to n_p - 1. - dimensions: - rank: 1 - dim: [[1, n_p]] - \@long_name: - doc: | - Kikuchi pattern identifier - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Pixel coordinate along the y direction. - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - doc: | - Label for the y axis - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Pixel coordinate along the x direction. - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - doc: | - Label for the x axis - - # maybe time code data when the pattern were taken? - # key is it all happened in between the time defined in NXevent_data_em - # optionally link to NXebsd instance? - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 7710451cb8d41d7552e7016a888b69786627788a4659d2928852090ea22d302d -# -# -# -# -# -# -# -# Number of scanned points. Scan point may have none, one, or more pattern. -# -# -# -# -# Number of diffraction pattern. -# -# -# -# -# Number of pixel per Kikuchi pattern in the slow direction. -# -# -# -# -# Number of pixel per Kikuchi pattern in the fast direction. -# -# -# -# -# Measured set of electron backscatter diffraction data, aka Kikuchi pattern. -# Kikuchi pattern are the raw data for computational workflows in the field -# of orientation (imaging) microscopy. The technique is especially used in -# materials science and materials engineering. -# -# Based on a fuse of the `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ -# of the DREAM.3D community and the open H5OINA format of Oxford Instruments -# `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ -# -# EBSD can be used, usually with FIB/SEM microscopes, for three-dimensional -# orientation microscopy. So-called serial section analyses. For a detailed -# overview of these techniques see e.g. -# -# * `M. A. Groeber et al. <https://doi.org/10.1186/2193-9772-3-5>`_ -# * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ -# * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ -# -# With serial-sectioning this involves however always a sequence of measuring, -# milling. In this regard, each serial section (measuring) and milling -# is an own NXevent_data_em instance and thus there such a three-dimensional -# characterization should be stored as a set of two-dimensional data, -# with as many NXevent_data_em instances as sections were measured. -# -# These measured serial sectioning images need virtually always post-processing -# to arrive at the aligned and cleaned image stack before a respective digital -# model of the inspected microstructure can be analyzed. The resulting volume -# is often termed a so-called (representative) volume element (RVE). -# Several software packages are available for performing this post-processing. -# For now we do not consider metadata of these post-processing steps -# as a part of this base class because the connection between the large variety -# of such post-processing steps and the measured electron microscopy data -# is usually very small. -# -# If we envision a (knowledge) graph for EBSD it consists of individual -# sub-graphs which convey information about the specimen preparation, -# the measurement of the specimen in the electron microscope, -# the indexing of the collected Kikuchi pattern stack, -# eventual post-processing of the indexed orientation image -# via similarity grouping algorithms to yield (grains, texture). -# Conceptually these post-processing steps are most frequently -# serving the idea to reconstruct quantitatively so-called -# microstructural features (grains, phases, interfaces). Materials scientists -# use these features according to the multi-scale materials modeling paradigm -# to infer material properties. They do so by quantifying correlations between -# the spatial arrangement of the features, their individual properties, -# and (macroscopic) properties of materials. -# -# -# -# -# Details how Kikuchi pattern were processed from the detector readings. -# Scientists interested in EBSD should inspect the respective NXem_ebsd -# application definition which can be used as a partner application definition -# to detail substantially more details to this processing. -# -# -# -# -# Collected Kikuchi pattern as an image stack. As raw and closest to the -# first retrievable measured data as possible, i.e. do not use this -# container to store already averaged, filtered or whatever post-processed -# pattern unless these are generated unmodifiably by the instrument -# given the way how the instrument and control software was configured -# for your microscope session. -# -# -# -# Array which resolves the scan point to which each pattern belongs. -# Scan points are evaluated in sequence starting from scan point zero -# until scan point n_sc - 1. Evaluating the cumulated of this array -# decodes which pattern in intensity belong to which scan point. -# In an example we may assume we collected three scan points. For the first -# we measure one pattern, for the second we measure three pattern, -# for the last we measure no pattern. -# The values of scan_point_identifier will be 0, 1, 1, 1, as we have -# measured four pattern in total. -# -# In most cases usually one pattern is averaged by the detector for -# some amount of time and then reported as one pattern. Use compressed -# arrays allows to store the scan_point_identifier efficiently. -# -# -# -# -# -# -# -# Signal intensity. For so-called three-dimensional or serial sectioning -# EBSD it is necessary to follow a sequence of specimen surface preparation -# and data collection. In this case users should collect the data for each -# serial sectioning step in an own instance of NXimage_set_em_kikuchi. -# All eventual post-processing of these measured data should be documented -# via NXebsd, resulting microstructure representations should be stored -# as NXms. -# -# -# -# -# -# -# -# -# -# Kikuchi pattern intensity -# -# -# -# -# -# -# Pattern are enumerated starting from 0 to n_p - 1. -# -# -# -# -# -# -# Kikuchi pattern identifier -# -# -# -# -# -# Pixel coordinate along the y direction. -# -# -# -# -# -# -# Label for the y axis -# -# -# -# -# -# Pixel coordinate along the x direction. -# -# -# -# -# -# -# Label for the x axis -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXinteraction_vol_em.yaml b/contributed_definitions/nyaml/NXinteraction_vol_em.yaml index 916ca1dacc..ce752c0dbd 100644 --- a/contributed_definitions/nyaml/NXinteraction_vol_em.yaml +++ b/contributed_definitions/nyaml/NXinteraction_vol_em.yaml @@ -1,13 +1,11 @@ category: base doc: | - Base class for storing details about a modelled shape of interaction volume. + Base class for describing the interaction volume of particle-matter interaction. - The interaction volume is mainly relevant in scanning electron microscopy - when the sample is thick enough so that the beam is unable to illuminate - through the specimen. - Computer models like Monte Carlo or molecular dynamics / electron beam - interaction simulations can be used to qualify and/or quantify the shape of - the interaction volume. + Computer models like Monte Carlo or molecular dynamics / electron- or ion-beam + interaction simulations can be used to qualify and (or) quantify the shape of + the interaction volume. Results of such simulations can be summary statistics + or single-particle resolved sets of trajectories. Explicit or implicit descriptions are possible. @@ -29,47 +27,8 @@ doc: | * `S. Richter et al. `_ * `J. Bünger et al. `_ + * `J. F. Ziegler et al. `_ type: group -(NXobject)NXinteraction_vol_em: +NXinteraction_vol_em(NXobject): (NXdata): (NXprocess): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 29b6daff56a280c88764ab6e66b9b4e67228cd110dbb825726104e01550aeeb7 -# -# -# -# -# Base class for storing details about a modelled shape of interaction volume. -# -# The interaction volume is mainly relevant in scanning electron microscopy -# when the sample is thick enough so that the beam is unable to illuminate -# through the specimen. -# Computer models like Monte Carlo or molecular dynamics / electron beam -# interaction simulations can be used to qualify and/or quantify the shape of -# the interaction volume. -# -# Explicit or implicit descriptions are possible. -# -# * An implicit description is via a set of electron/specimen interactions -# represented ideally as trajectory data from the computer simulation. -# * An explicit description is via an iso-contour surface using either -# a simulation grid or a triangulated surface mesh of the approximated -# iso-contour surface evaluated at specific threshold values. -# Iso-contours could be computed from electron or particle fluxes through -# an imaginary control surface (the iso-surface). -# Threshold values can be defined by particles passing through a unit control -# volume (electrons) or energy-levels (e.g. the case of X-rays). -# Details depend on the model. -# * Another explicit description is via theoretical models which may -# be relevant e.g. for X-ray spectroscopy -# -# Further details on how the interaction volume can be quantified -# is available in the literature for example: -# -# * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ -# * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ -# -# -# -# diff --git a/contributed_definitions/nyaml/NXion.yaml b/contributed_definitions/nyaml/NXion.yaml index c6adffce71..360f925566 100644 --- a/contributed_definitions/nyaml/NXion.yaml +++ b/contributed_definitions/nyaml/NXion.yaml @@ -10,26 +10,26 @@ symbols: Number of mass-to-charge-state-ratio range intervals for ion type. type: group NXion(NXobject): - identifier: + identifier(NX_CHAR): doc: | A unique identifier whereby such an ion can be referred to via the service offered as described in identifier_type. - identifier_type: + identifier_type(NX_CHAR): doc: | How can the identifier be resolved? enumeration: [inchi] ion_type(NX_UINT): - unit: NX_UNITLESS doc: | - Ion type (ion species) identifier. The identifier zero - is reserved for the special unknown ion type. - isotope_vector(NX_UINT): + Ion type (ion species) identifier. + + The identifier zero is reserved for the special unknown ion type. unit: NX_UNITLESS + isotope_vector(NX_UINT): doc: | - A vector of isotope hash values. - These values have to be stored in an array, sorted in decreasing order. - The array is filled with zero hash values indicating unused places. - The individual hash values are built with the following hash function: + A vector of isotope hash values. These values have to be stored in an array, + sorted in decreasing order. The array is filled with zero hash values + indicating unused places. The individual hash values are built with the + following hash function: The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` the number of protons and :math:`N` the number of neutrons @@ -37,11 +37,9 @@ NXion(NXobject): Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) `_ - dimensions: - rank: 2 - dim: [[1, 1], [2, n_ivecmax]] - nuclid_list(NX_UINT): unit: NX_UNITLESS + dim: (1, n_ivecmax) + nuclid_list(NX_UINT): doc: | A supplementary row vector which decodes the isotope_vector into a human-readable matrix of nuclids with the following formatting: @@ -50,18 +48,16 @@ NXion(NXobject): from the isotope_vector this is :math:`Z + N`. As an example for a carbon-14 isotope the number is 14. The second row specifies the number of protons :math:`Z`, e.g. 6 for the - carbon-14 example. This row matrix is thus a mapping the notation of - using superscribed isotope mass and subscripted number of protons to - identify isotopes. + carbon-14 example. This row matrix is thus mapping the notation of + using superscribed isotope mass and subscripted number of protons + to identify isotopes. Unused places filling up to n_ivecmax need to be filled with zero. - dimensions: - rank: 2 - dim: [[1, 2], [2, n_ivecmax]] - color: + unit: NX_UNITLESS + dim: (2, n_ivecmax) + color(NX_CHAR): doc: | Color code used for visualizing such ions. - volume(NX_FLOAT): - unit: NX_VOLUME + volume(NX_NUMBER): doc: | Assumed volume of the ion. @@ -69,12 +65,12 @@ NXion(NXobject): volume per ion (average) which is typically stored in range files and will be used when building a tomographic reconstruction of an atom probe dataset. - charge(NX_FLOAT): - unit: NX_CHARGE + unit: NX_VOLUME + charge(NX_NUMBER): doc: | Charge of the ion. + unit: NX_CHARGE charge_state(NX_INT): - unit: NX_UNITLESS doc: | Signed charge state of the ion in multiples of electron charge. @@ -88,202 +84,27 @@ NXion(NXobject): These file formats do not document the charge state explicitly. They report the number of atoms of each element per molecular ion surplus the mass-to-charge-state-ratio interval. - With this it is possible to recover the charge state only for - specific molecular ions as the accumulated mass of the molecular ion - is defined by the isotopes, which without knowing the charge leads + With this information it is possible to recover the charge state only + for specific molecular ions as the accumulated mass of the molecular ion + is defined by the isotopes, which without knowing the charge, leads to an underconstrained problem. Details on ranging can be found in the literature: `M. K. Miller `_ - name: + unit: NX_UNITLESS + name(NX_CHAR): doc: | Human-readable ion type name (e.g. Al +++) - The string should consists of ASCII UTF-8 characters, - ideally using LaTeX notation to specify the isotopes, ions, and charge - state. Examples are 12C + or Al +++. - Although this name may be human-readable and intuitive, parsing such - names becomes impractical for more complicated cases. Therefore, for the - field of atom probe microscopy the isotope_vector should be the - preferred machine-readable format to use. - mass_to_charge_range(NX_FLOAT): - unit: NX_ANY + The string should consists of UTF-8 characters, ideally using LaTeX + notation to specify the isotopes, ions, and charge state. + Examples are 12C + or Al +++. + + To ease automated parsing isotope_vector should be the + preferred machine-readable information used. + mass_to_charge_range(NX_NUMBER): doc: | - Associated lower (mqmin) and upper (mqmax) bounds of + Associated lower (mqmin) and upper (mqmax) bounds of the mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries included) for which the respective ion is one to be labelled - with ion_identifier. The field is primarily of interest to document the - result of indexing a ToF/mass spectrum. - - # \@units: Da - dimensions: - rank: 2 - dim: [[1, n_ranges], [2, 2]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 46239655be8d46576203e9210fb3529fb5d8490df4826298dbe207b24470ddd7 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). -# -# -# -# -# Number of mass-to-charge-state-ratio range intervals for ion type. -# -# -# -# -# Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. -# -# -# -# A unique identifier whereby such an ion can be referred to -# via the service offered as described in identifier_type. -# -# -# -# -# How can the identifier be resolved? -# -# -# -# -# -# -# -# Ion type (ion species) identifier. The identifier zero -# is reserved for the special unknown ion type. -# -# -# -# -# A vector of isotope hash values. -# These values have to be stored in an array, sorted in decreasing order. -# The array is filled with zero hash values indicating unused places. -# The individual hash values are built with the following hash function: -# -# The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` -# the number of protons and :math:`N` the number of neutrons -# of each isotope respectively. -# -# Z and N have to be 8-bit unsigned integers. -# For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ -# -# -# -# -# -# -# -# -# A supplementary row vector which decodes the isotope_vector into -# a human-readable matrix of nuclids with the following formatting: -# -# The first row specifies the isotope mass number, i.e. using the hashvalues -# from the isotope_vector this is :math:`Z + N`. As an example for a -# carbon-14 isotope the number is 14. -# The second row specifies the number of protons :math:`Z`, e.g. 6 for the -# carbon-14 example. This row matrix is thus a mapping the notation of -# using superscribed isotope mass and subscripted number of protons to -# identify isotopes. -# Unused places filling up to n_ivecmax need to be filled with zero. -# -# -# -# -# -# -# -# -# Color code used for visualizing such ions. -# -# -# -# -# Assumed volume of the ion. -# -# In atom probe microscopy this field can be used to store the reconstructed -# volume per ion (average) which is typically stored in range files and will -# be used when building a tomographic reconstruction of an atom probe -# dataset. -# -# -# -# -# Charge of the ion. -# -# -# -# -# Signed charge state of the ion in multiples of electron charge. -# -# Only positive values will be measured in atom probe microscopy as the -# ions are accelerated by a negatively signed bias electric field. -# In the case that the charge state is not explicitly recoverable, -# the value should be set to zero. -# -# In atom probe microscopy this is for example the case when using -# classical range file formats like RNG, RRNG for atom probe data. -# These file formats do not document the charge state explicitly. -# They report the number of atoms of each element per molecular ion -# surplus the mass-to-charge-state-ratio interval. -# With this it is possible to recover the charge state only for -# specific molecular ions as the accumulated mass of the molecular ion -# is defined by the isotopes, which without knowing the charge leads -# to an underconstrained problem. -# Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ -# -# -# -# -# Human-readable ion type name (e.g. Al +++) -# The string should consists of ASCII UTF-8 characters, -# ideally using LaTeX notation to specify the isotopes, ions, and charge -# state. Examples are 12C + or Al +++. -# Although this name may be human-readable and intuitive, parsing such -# names becomes impractical for more complicated cases. Therefore, for the -# field of atom probe microscopy the isotope_vector should be the -# preferred machine-readable format to use. -# -# -# -# -# Associated lower (mqmin) and upper (mqmax) bounds of -# mass-to-charge-state ratio interval(s) [mqmin, mqmax] -# (boundaries included) for which the respective ion is one to be labelled -# with ion_identifier. The field is primarily of interest to document the -# result of indexing a ToF/mass spectrum. -# -# -# -# -# -# -# -# + (boundaries inclusive). This field is primarily of interest + for documenting :ref:`NXprocess` steps of indexing a ToF/mass-to-charge + state histogram. + unit: NX_ANY # NX_DALTON + dim: (n_ranges, 2) diff --git a/contributed_definitions/nyaml/NXisocontour.yaml b/contributed_definitions/nyaml/NXisocontour.yaml index 7dd7476a71..5f64c3c782 100644 --- a/contributed_definitions/nyaml/NXisocontour.yaml +++ b/contributed_definitions/nyaml/NXisocontour.yaml @@ -24,7 +24,10 @@ symbols: type: group NXisocontour(NXobject): dimensionality(NX_POSINT): + doc: | + The dimensionality of the space in which the isocontour is embedded. unit: NX_UNITLESS + enumeration: [2, 3] grid(NXcg_grid): doc: | The discretized grid on which the iso-contour algorithm operates. diff --git a/contributed_definitions/nyaml/NXlens_em.yaml b/contributed_definitions/nyaml/NXlens_em.yaml index 36a48e9154..b64a786dba 100644 --- a/contributed_definitions/nyaml/NXlens_em.yaml +++ b/contributed_definitions/nyaml/NXlens_em.yaml @@ -1,56 +1,67 @@ category: base doc: | - Description of an electro-magnetic lens or a compound lens. + Base class for 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 :ref:`NXtransformations` the origin of the coordinate system is placed + in the center of the lens (its polepiece, pinhole, or another + point of reference). The origin should be specified in the :ref:`NXtransformations`. - For details of electro-magnetic lenses in the literature see e.g. `L. Reimer `_ + For details of electro-magnetic lenses in the literature + see e.g. `L. Reimer `_ type: group +# more consolidation to harvest from a generic component base class +# with other research fields (MPES, XPS, OPT) could be useful NXlens_em(NXobject): - type: + type(NX_CHAR): doc: | Qualitative type of lens with respect to the number of pole pieces. enumeration: [single, double, quadrupole, hexapole, octupole] - name: + name(NX_CHAR): doc: | Given name, alias, colloquial, or short name for the lens. For manufacturer names and identifiers use respective manufacturer fields. - manufacturer_name: - doc: | - Name of the manufacturer who built/constructed the lens. + # manufacturer_name: + # doc: | + # Name of the manufacturer who built/constructed the lens. (NXfabrication): - model: - doc: | - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the lens. - description: + # model: + # doc: | + # Hardware name, hash identifier, or serial number that was given by the + # manufacturer to identify the lens. + description(NX_CHAR): # NXidentifier doc: | - Ideally an identifier, persistent link, or free text which gives further details - about the lens. + Ideally an identifier, persistent link, or free text which + gives further details about the lens. voltage(NX_NUMBER): - unit: NX_VOLTAGE doc: | - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. + Excitation voltage of the lens. + + For dipoles it is a single number. + For higher order multipoles, it is an array. + unit: NX_VOLTAGE current(NX_NUMBER): - unit: NX_CURRENT doc: | - Excitation current of the lens. For dipoles it is a single number. For higher - orders, it is an array. + Excitation current of the lens. + + For dipoles it is a single number. + For higher order multipoles, it is an array. + unit: NX_CURRENT value(NX_NUMBER): - unit: NX_ANY doc: | - This field should be used when the exact voltage or current of the lens is not directly controllable - as the control software of the microscope does not enable users/or is was not configured to enable - the user to retrieve these values. In this case this field should be used to specify the value as - read from the control software. Although consumers of the application definition should not expect - this value to represent the exact physical voltage or excitation, it is still useful to know though - as it allows other users to reuse this lens setting, which, provided a properly working instrument - and software should bring the lenses into a similar state. - depends_on: + This field should be used when the exact voltage or current of the lens + is not directly controllable as the control software of the microscope + does not enable or was not configured to display these values. + + In this case this value field should be used and the value + from the control software stored as is. + + Although this value does not document the exact physical voltage or + excitation, it can still give useful context to reproduce the lens setting, + which, provided a properly working instrument and software sets the lens + into a similar state to the technical level possible when no more information + is available physically or accessible legally. + unit: NX_ANY + \@depends_on(NX_CHAR): doc: | Specifies the position of the lens by pointing to the last transformation in the transformation chain in the NXtransformations group. @@ -61,115 +72,3 @@ NXlens_em(NXobject): 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8d5e9bc3e4abc9080a281a455f74761c9bdcd71e4d81cb4aaa7b25f182419500 -# -# -# -# -# -# Description of an electro-magnetic lens or a compound lens. -# -# For NXtransformations the origin of the coordinate system is placed -# in the center of the lens -# (its polepiece, pinhole, or another point of reference). -# The origin should be specified in the NXtransformations. -# -# For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ -# -# -# -# Qualitative type of lens with respect to the number of pole pieces. -# -# -# -# -# -# -# -# -# -# -# -# Given name, alias, colloquial, or short name for the lens. -# For manufacturer names and identifiers use respective manufacturer fields. -# -# -# -# -# Name of the manufacturer who built/constructed the lens. -# -# -# -# -# -# Hardware name, hash identifier, or serial number that was given by the -# manufacturer to identify the lens. -# -# -# -# -# Ideally an identifier, persistent link, or free text which gives further details -# about the lens. -# -# -# -# -# Excitation voltage of the lens. For dipoles it is a single number. For higher -# orders, it is an array. -# -# -# -# -# Excitation current of the lens. For dipoles it is a single number. For higher -# orders, it is an array. -# -# -# -# -# This field should be used when the exact voltage or current of the lens is not directly controllable -# as the control software of the microscope does not enable users/or is was not configured to enable -# the user to retrieve these values. In this case this field should be used to specify the value as -# read from the control software. Although consumers of the application definition should not expect -# this value to represent the exact physical voltage or excitation, it is still useful to know though -# as it allows other users to reuse this lens setting, which, provided a properly working instrument -# and software should bring the lenses into a similar state. -# -# -# -# -# Specifies the position of the lens by pointing to the last transformation in the -# transformation chain in the NXtransformations group. -# -# -# -# -# Collection of axis-based translations and rotations to describe the -# location and geometry of the lens as a component in the instrument. -# Typically, the components of a system should all be related relative to -# each other and only one component should relate to the reference -# coordinate system. -# -# -# diff --git a/contributed_definitions/nyaml/NXms.yaml b/contributed_definitions/nyaml/NXms.yaml index d21ed3f3fe..888c6a90c2 100644 --- a/contributed_definitions/nyaml/NXms.yaml +++ b/contributed_definitions/nyaml/NXms.yaml @@ -186,7 +186,7 @@ NXms(NXobject): coordinate system should be described with an NXtransformations instance. TRANSFORMATIONS(NXtransformations): exists: ['min', '3', 'max', 'unbounded'] - conventions(NXem_ebsd_conventions): + conventions(NXem_conventions_ebsd): rotation_conventions(NXprocess): three_dimensional_rotation_handedness: rotation_convention: @@ -385,7 +385,7 @@ NXms(NXobject): unit: NX_ANY doc: | TO BE DEFINED - volume_statistics(NXorientation_set): + volume_statistics(NXcollection): exists: optional doc: | Collection of texture components commonly referred to. @@ -459,535 +459,3 @@ NXms(NXobject): exists: optional recrystallization_front(NXprocess): exists: optional - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 0210bb99907cdf3b9d534b45bd656fa8f6874bb33fbdda923582a60ede380b06 -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of boundaries of the bounding box or primitive to domain. -# -# -# -# -# Number of parameter required for the chosen orientation parameterization. -# -# -# -# -# Number of texture components identified. -# -# -# -# -# Application definition, spatiotemporal characterization of a microstructure. -# -# -# -# -# An at least as strong as SHA256 hashvalue of the file -# that specifies the application definition. -# -# -# -# -# -# NeXus NXDL schema to which this file conforms. -# -# -# -# -# -# -# -# Ideally, a (globally) unique persistent identifier -# for referring to this experiment or computer simulation. -# -# The identifier is usually defined/issued by the facility, laboratory, -# or the principle investigator. The identifier enables to link -# experiments to e.g. proposals. -# -# -# -# -# Free-text description about the workflow (experiment/analysis/simulation). -# -# Users are strongly advised to detail the sample history in the -# respective field and fill rather as completely as possible the fields -# of this application definition rather than write details about the -# experiment into this free-text description field. -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC information -# included when the characterization started. -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC included -# when the characterization ended. -# -# -# -# -# -# -# -# -# -# Specify if the (characterization) results/data of this instance of an -# application definition are based on the results of a simulation or the -# results of a post-processing of measured data to describe -# a microstructure. -# -# The term microstructure is used to describe the spatial arrangement of -# crystal defects inside a sample/specimen without demanding necessarily -# that this structure is mainly at the micron length scale. -# Nanostructure and macrostructure are close synonyms. -# Material architecture is a narrow synonym. -# -# Given that microstructure simulations nowadays more and more consider -# the atomic arrangement, this application definition can also be used -# to describe features at the scale of atoms. -# -# -# -# -# -# -# -# -# Contact information and eventually details of at least one person -# involved in creating this result. This can be the principle investigator -# who performed this experiment. Adding multiple users if relevant is recommended. -# -# -# -# Given (first) name and surname of the user. -# -# -# -# -# Name of the affiliation of the user at the point in time -# when the experiment was performed. -# -# -# -# -# Postal address of the affiliation. -# -# -# -# -# Email address of the user at the point in time when the experiment -# was performed. Writing the most permanently used email is recommended. -# -# -# -# -# Globally unique identifier of the user as offered by services -# like ORCID or ResearcherID. If this field is field the specific service -# should also be written in orcid_platform -# -# -# -# -# Name of the OrcID or ResearcherID where the account -# under orcid is registered. -# -# -# -# -# (Business) (tele)phone number of the user at the point -# in time when the experiment was performed. -# -# -# -# -# Which role does the user have in the place and at the point -# in time when the experiment was performed? Technician operating -# the microscope. Student, postdoc, principle investigator, guest -# are common examples. -# -# -# -# -# Account name that is associated with the user in social media platforms. -# -# -# -# -# Name of the social media platform where the account -# under social_media_name is registered. -# -# -# -# -# -# -# -# Descriptive name or ideally (globally) unique persistent identifier. -# -# -# -# -# -# -# Hard link to a location in the hierarchy of the NeXus file -# where the data for default plotting are stored. -# -# -# -# -# Container to hold different coordinate systems conventions. -# A least a right-handed Cartesian coordinate system with base vectors -# named x, y, and z has to be specified. Each base vector of the -# coordinate system should be described with an NXtransformations instance. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The simulated or characterized material volume element aka domain. -# At least one instance of geometry required either NXcg_grid, -# NXcg_polyhedron_set, or NXcg_point_set. This geometry group needs -# to contain details about the boundary conditions. -# -# -# -# -# -# -# -# A boundary to the volume element. -# Either an instance of NXcg_hexahedron_set or of NXcg_ellipsoid_set. -# -# -# -# -# How many distinct boundaries are distinguished. Value required equal to n_b. -# -# -# -# -# Name of the boundaries. E.g. left, right, front, back, bottom, top, -# -# -# -# -# -# -# -# The boundary conditions for each boundary: -# -# 0 - undefined -# 1 - open -# 2 - periodic -# 3 - mirror -# 4 - von Neumann -# 5 - Dirichlet -# -# -# -# -# -# -# -# -# Collection of microstructural data observed/simulated. -# -# -# -# Integer which specifies the first index to be used for distinguishing -# snapshots. Identifiers are defined either implicitly or explicitly. -# For implicit indexing the identifiers are defined on the -# interval [identifier_offset, identifier_offset+c-1]. -# For explicit indexing the identifier array has to be defined. -# -# The identifier_offset field can for example be used to communicate -# if the identifiers are expected to start from 1 (referred to as -# Fortran-/Matlab-) or from 0 (referred to as C-, Python-style index -# notation) respectively. -# -# -# -# -# -# Summary quantities which are the result of some post-processing of -# the snapshot data (averaging, integrating, interpolating). -# Frequently used descriptors from continuum mechanics and thermodynamics -# can be used here. A few examples are given. Each descriptor is currently -# modelled as an instance of an NXprocess because it is relevant to -# understand how the descriptors are computed. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Measured or simulated physical time stamp for this snapshot. -# Not to be confused with wall-clock timing or profiling data. -# -# -# -# -# Iteration or increment counter. -# -# -# -# -# -# -# -# -# -# Conceptually distinguished object/feature in the ROI/ -# system with some relevance. Instances of NXms_feature_set can -# be nested to build a hierarchy of logically-related objects. -# -# A typical example for MD simulations is to have one -# ms_feature_set for the atoms which is the parent to another -# ms_feature_set for monomers/molecules/proteins which is then the -# parent to another ms_feature_set for the secondary, another feature_set -# for the tertiary, and the parent for another feature_set for the -# quaternary structure. -# -# Another typical example from materials engineering is to have -# one ms_feature_set for crystals (grains/phases) which serves as -# the parent to another ms_feature_set for interfaces between these -# crystals which then is the parent for another ms_feature_set to -# describe the triple junctions which is then the parent for the -# quadruple/higher-order junctions between which connect the -# triple lines. -# -# Another example from discrete dislocation dynamics could be to -# have one ms_feature_set for the dislocations (maybe separate -# sets for each dislocation type or family) which are then -# parents to other ms_feature_set which describe junctions between -# dislocations or features along the dislocation line network. -# -# -# -# -# -# Details about the orientation distribution function -# within the entire domain. -# -# -# -# With which method was the ODF approximated? -# -# -# -# -# -# TO BE DEFINED -# -# -# -# -# TO BE DEFINED -# -# -# -# -# Collection of texture components commonly referred to. -# -# -# -# Reference to or definition of a coordinate system with -# which the definitions are interpretable. -# -# -# -# -# -# -# -# -# -# -# Parameterized orientations. -# -# -# -# -# -# -# -# -# Name of each texture component, e.g. Cube, Dillamore, Y. -# -# -# -# -# -# -# -# The portion of orientation space integrated over -# to compute the volume fraction. -# -# -# -# -# -# -# -# The volume fraction of each texture component. -# -# -# -# -# -# -# -# -# -# -# Details about the disorientation distribution function -# within the entire domain. -# -# -# -# -# Details about the grain boundary character distribution -# within the entire domain. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXms_feature_set.yaml b/contributed_definitions/nyaml/NXms_feature_set.yaml index b44ad17461..cc7aceda67 100644 --- a/contributed_definitions/nyaml/NXms_feature_set.yaml +++ b/contributed_definitions/nyaml/NXms_feature_set.yaml @@ -12,24 +12,20 @@ symbols: Number of types in the dictionary of human-readable types of features. n_parent_ids: | Total number of parent identifier. - # NXms_feature_set can be used e.g. as groups inside instances of NXms_snapshot # for an MD simulation each timestep is such snapshot all snapshot for a set # which is the parent group that has all these NXms_snapshot instances as childs # time_stamp: # simulated, physical - # Thea, Joseph, Lauri, Dinga (TJLD) just for comparison for each group and field to what this would map in their model for the MDTutorial 2 type: group NXms_feature_set(NXobject): - # TJLD: this class represents a generalization of AtomGroups # TJLD: one such for atoms(NXms_feature_set) # TJLD: one such for atom_groups(NXms_feature_set) # TJLD: but not one for every molecule, i.e. all molecules and how their atoms with ids are related to atoms ids is concatenated # TJLD: clearly there are two possibilities: either concatenate or make one NXms_feature_set for each molecule or component in the topology hierarchy # TJLD: however the here proposed design generalizes the arbitrary (microstructural) features and computational geometry based coarse-grained representations - \@depends_on: - + \@depends_on(NX_CHAR): # TJLD: not required it is currently assumed that features are always build from atoms and this relation is shown using their ids, integers on [0, n_atoms-1] doc: | Name (or link?) to another NXms_feature_set which defines features what are @@ -37,7 +33,6 @@ NXms_feature_set(NXobject): If depends_on is set to "." or this attribute is not defined in an instance of this application definition, assume that this feature_set instance represents the root feature_set of the feature tree/graph. - # the design of this base class makes it possible to have Joseph's suggestion # but it has the additional benefit that as it defines the set one also # bundle the description for all features at this hierarchy level into combined @@ -50,20 +45,17 @@ NXms_feature_set(NXobject): # but with the additional benefit of a much richer geometrical description and the details about the uncertainty of these descriptions # I can also imagine that materials engineers e.g. can reuse NXms_feature_set in an application definition by just then naming # their group e.g. grains(NXms_feature_set) and use in the application definition either only the (material point), interface network, or volumetric description - dimensionality(NX_UINT): - + dimensionality(NX_POSINT): # TJLD: not needed because they assume everything is 3d doc: | What is the best matching description how dimensional the feature is. - enumeration: [0, 1, 2, 3] + enumeration: [1, 2, 3] cardinality(NX_UINT): - unit: NX_UNITLESS - # TJLD: equivalent to the number of AtomGroups class instance childs doc: | How many features/members are in this set? - type_dict_keyword: - + unit: NX_UNITLESS + type_dict_keyword(NX_CHAR): # TJLD: equivalent to the controlled vocabulary term monomer or molecule, i.e. label # TJLD: but with the difference that in this NeXus design here different features can take different roles # TJLD: and do not conceptually have to be atoms, alternatively one could also create an NXms_interface_set which @@ -76,48 +68,37 @@ NXms_feature_set(NXobject): kink, jog, stacking_fault, homo_phase_boundary, hetero_phase_boundary, surface, thermal_groove_root, precipitate, dispersoid, pore, crack is recommended. - dimensions: - rank: 1 - dim: [[1, n_type_dict]] - type_dict_value(NX_UINT): - unit: NX_UNITLESS - + dim: (n_type_dict,) + type_dict_value(NX_INT): # TJLD: equivalent to the AtomGroups index doc: | The integer identifier used to resolve of which type each feature is, i.e. the values of the dictionary of human-readable types of features. - dimensions: - rank: 1 - dim: [[1, n_type_dict]] - number_of_parent_identifier(NX_UINT): unit: NX_UNITLESS + dim: (n_type_dict,) + number_of_parent_identifier(NX_INT): doc: | For each feature in the set specify the associated number of identifier to parent features as are resolvable via depends_on. This array enables to compute the array interval from which details for specific features can be extracted as if they would be stored in an own group. - dimensions: - rank: 1 - dim: [[1, c]] - parent_identifier(NX_UINT): unit: NX_UNITLESS + dim: (c,) + parent_identifier(NX_INT): doc: | Concatenated array of parent identifier for each feature (in the sequence) according to identifier and how the identifier of features in the here described feature set are defined (implicitly from 0, to c-1 or via explicit identifier. - dimensions: - rank: 1 - dim: [[1, n_parent_ids]] - + unit: NX_UNITLESS + dim: (n_parent_ids,) # description of the geometry of the features # MK::how can be define that inside lines(NXprocess) we assure that there is either no geometry or only one geometry but then this geometry can be either an NXcg_polyline_set or NXcg_spline_set? # the key problem is that at least for an implementation in HDF5 we are not allowed to have two groups named geometry even if their attributes are different because # HDF5 implements no conceptual understanding of the relations between elements in the underlying graph which holds the data, these elements are either attributes, fields, groups, all of which # end up as links identifier_offset(NX_INT): - unit: NX_UNITLESS doc: | Integer which specifies the first index to be used for distinguishing features. Identifiers are defined either implicitly @@ -128,15 +109,13 @@ NXms_feature_set(NXobject): The identifier_offset field can for example be used to communicate if the identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) or from 0 (referred to as C-, Python-style index notation) respectively. - identifier(NX_INT): unit: NX_UNITLESS + identifier(NX_INT): doc: | Integer used to distinguish features for explicit indexing. - dimensions: - rank: 1 - dim: [[1, c]] + unit: NX_UNITLESS + dim: (c,) points(NXprocess): - # TJLD: this design here is different, TJLD give atom positions only (at least as of now) for the root of an object # TJLD: while all higher-order features that are connected through their assumed topology just refer to the atoms in the root # TJLD: via their IDs, TJLD design is ideal for systems build from atoms but would create unnecessary copies for higher-dimensional-type features @@ -153,13 +132,11 @@ NXms_feature_set(NXobject): Assumptions, parameters, and details how positional uncertainty of the geometry is quantified. lines(NXprocess): - # TJLD: not conceptualized, see comments for points and what the benefit of using NeXus would be doc: | Assumptions and parameters to arrive at geometric primitives to locate one-dimensional/line-like features which are discretized by polylines. - # MK::geometry(NXcg_spline_set) geometry(NXcg_polyline_set): uncertainty(NXprocess): @@ -171,7 +148,6 @@ NXms_feature_set(NXobject): Assumptions and parameters to arrive at geometric primitives to locate two-dimensional/interface features which are discretized by triangulated surface meshes. - # MK::geometry(NXcg_nurbs_set): geometry(NXcg_triangle_set): uncertainty(NXprocess): @@ -183,14 +159,12 @@ NXms_feature_set(NXobject): Assumptions and parameters to arrive at geometric primitives to locate three-dimensional/volumetric features which are discretized by triangulated surface meshes of polyhedra. - # MK::geometry(NXcg_nurbs_set): geometry(NXcg_polyhedron_set): uncertainty(NXprocess): doc: | Assumptions, parameters, and details how positional uncertainty of the geometry is quantified. - # Sandor and Markus agree that how trajectories are extracted should be stored in instances of NXprocess at respective places # Sandor suggested it can be useful to also describe how one could transform system-specific atom positions from the system-focused coordinate system to a molecule- or atom-focused local coordinate system diff --git a/contributed_definitions/nyaml/NXms_ipf.yaml b/contributed_definitions/nyaml/NXms_ipf.yaml new file mode 100644 index 0000000000..11bfc59831 --- /dev/null +++ b/contributed_definitions/nyaml/NXms_ipf.yaml @@ -0,0 +1,299 @@ +category: base +doc: | + Base class to store an inverse pole figure (IPF) mapping (IPF map). +symbols: + # how to make this optional + n_z: | + Number of pixel along the z slowest direction. + n_y: | + Number of pixel along the y slow direction. + n_x: | + Number of pixel along the x fast direction. + n_rgb: | + Number of RGB values along the fastest direction, always three. + d: | + Dimensionality of the mapping (either 2 or 3). +type: group +NXms_ipf(NXprocess): + \@depends_on(NX_CHAR): + doc: | + Reference to the coordinate system whereby the projection_direction is defined. + + If the field depends_on is not provided but a parent of the instance + of this base class or its specialization defines an :ref:`NXcoordinate_system_set` + and exactly one :ref:`NXcoordinate_system`, the reference points to this system. + + If nothing is provided and none of the above-mentioned references pointing + in a parent, McStas is assumed. + projection_direction(NX_NUMBER): + doc: | + The direction along which orientations are projected. + unit: NX_UNITLESS + dim: (3,) + input_grid(NXcg_grid): + doc: | + Details about the original grid. + + Here original grid means the one onto which the IPF map was computed + when exported from the tech partner's file format representation. + output_grid(NXcg_grid): + doc: | + Details about the grid onto which the IPF is recomputed. + + Rescaling the visualization of the IPF map may be needed to enable + visualization in specific software tools like H5Web. + The value specifies the fractional change of the spacing between + the original mapping and the scaled one. + interpolation(NX_CHAR): + doc: | + How where orientation values at the location of the output grid + positions computed. + + Nearest neighbour means the orientation of the closed (Euclidean distance) + grid point of the input_grid was taken. + enumeration: [nearest_neighbour] + map(NXdata): + doc: | + Inverse pole figure mapping. + + Default inverse pole figure (IPF) plot of the data specific for each + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + Inspect the definition of :ref:`NXcrystal_structure` and its field + phase_identifier for further details. + + Details about possible regridding and associated interpolation + during the computation of the IPF map visualization can be stored + using the input_grid, output_grid, and interpolation fields. + + The main purpose of this map is to offer a normalized default representation + of the IPF map for consumption by a research data management system (RDMS). + This is aligned with the first aim of :ref:`NXms_ipf`, to bring colleagues and + users of IPF maps together to discuss which pieces of information + need to be stored together. We are convinced a step-by-step design and + community-driven discussion about which pieces of information should + and/or need to be included is a practical strategy to work towards an + interoperable description and data model for exchanging IPF maps as specific + community-accepted tools to convey orientation maps. + + With this design the individual RDMS solutions and tools can still continue + to support specific custom data analyses workflow and routes but at least + there is one common understanding which enables also those users who are + not necessarily experts in all the details of the underlying techniques + can understand and thus eventually judge if the dataset is worth to be + reused or repurposed. + # \@signal: data + # \@axes: [axis_y, axis_x] + # \@axis_x_indices: 0 + # \@axis_y_indices: 1 + data(NX_NUMBER): + # assume a mapping with step size 0.5 micron + # we need to distinguish + # pixel position, i.e. 0, 1, 2, 3, unit px + # answers in which pixel on the map but map is disconnected from sample surface context + # calibrated pixel position 0., 0.5, 1.0, 1.5, unit micron + # answers in addition physical dimensions (relevant to get crystal extent etc.) but still disconnected from sample surface context + # calibrated pixel position including the offset of the original coordinate system + # answers everything would enable one to point if still in the microscope where on the sample surface each pixel is located + # tech partners oftentimes do not report to more than calibrated pixel position + doc: | + Inverse pole figure color code for each map coordinate. + unit: NX_UNITLESS + dim: (n_y, n_x, 3) # | (n_z, n_y, n_x, 3) + axis_z(NX_NUMBER): + doc: | + Pixel center coordinate calibrated for step size along the z axis of the map. + unit: NX_LENGTH + dim: (n_z,) + # \@long_name(NX_CHAR): + axis_y(NX_NUMBER): + unit: NX_LENGTH + doc: | + Pixel center coordinate calibrated for step size along the y axis of the map. + dim: (n_y,) + # \@long_name(NX_CHAR): + axis_x(NX_NUMBER): + unit: NX_LENGTH + doc: | + Pixel center coordinate calibrated for step size along the x axis of the map. + dim: (n_x,) + # \@long_name(NX_CHAR): + # title: + legend(NXdata): + doc: | + The color code which maps colors into orientation into the fundamental zone. + + For each stereographic standard triangle (SST), i.e. a rendering of the + fundamental zone of the crystal-symmetry-reduced orientation space + SO3, it is possible to define a color model which assigns each point in + the fundamental zone a color. + + Different mapping models are used. These implement (slightly) different + scaling relations. Differences exist across representations of tech partners. + + Differences are which base colors of the RGB color model are placed in + which extremal position of the SST and where the white point is located. + + For further details see: + + * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + * Srikanth Patala and coworkers"'" work and of others. + + Details are implementation-specific and not standardized yet. + + Given that the SST has a complicated geometry, it cannot yet be + visualized using tools like H5Web, which is why for now the matrix + of a rasterized image which is rendered by the backend tool gets + copied into an RGB matrix to offer a default plot. + # \@signal: data + # \@axes: [axis_y, axis_x] + # \@axis_x_indices: 0 + # \@axis_y_indices: 1 + data(NX_NUMBER): + # hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! + doc: | + Inverse pole figure color code for each map coordinate. + unit: NX_UNITLESS + dim: (n_y, n_x, 3) + axis_y(NX_NUMBER): + doc: | + Pixel along the y-axis. + unit: NX_UNITLESS + dim: (n_y,) + # \@long_name(NX_CHAR): + axis_x(NX_NUMBER): + doc: | + Pixel along the x-axis. + unit: NX_UNITLESS + dim: (n_x,) + # \@long_name(NX_CHAR): + # title: + +# keep this for now for FAIRmat internal documentation +# It is important to mention that we cannot assume, at least for now, +# that the parser which writes to an NXem_ebsd-compliant file is also +# responsible or capable at all of computing the inverse pole figure +# color keys and maps itself. This cannot be assumed working because +# this mapping of orientation data uses involved mathematical algorithms +# and functions which not every tools used in the EBSD community is capable +# of using or is for sure not using in exactly the same way. +# +# Currently, we assume it is the responsibilty of the tool used which +# generated the data under on_the_fly_indexing to compute these +# plots and deliver these to the parser. +# +# Specific case studies have been explored by the experiment team of +# Area B of the FAIRmat project to realize and implement such mapping. +# +# The first case study uses the H5OINA format and the pyxem/orix library. +# As orix is a Python library, the coloring is performed by the em_om parser. +# +# The second case study uses MTex and its EBSD color coding model. +# As MTex is a Matlab tool, an intermediate format is written from MTex +# first which stores these pieces of information. The parser then pulls +# these data from the intermediate Matlab-agnostic representation and +# supplements the file with missing pieces of information as it is +# required by NXem_ebsd. +# +# The third case study shows how a generic set of Kikuchi pattern +# can be loaded with the em_om parser. The pattern are loaded directly +# from a ZIP file and mapped to an simulation image section for now. +# +# The fourth case study uses the DREAM.3D package which provides an own +# set of EBSD data post-processing procedures. DREAM.3D documents the +# processing steps with a pipeline file which is stored inside DREAM.3D +# output files. In this case study, the parser reads the DREAM.3D file +# and maps data relevant from the perspective of NXem_ebsd plus adds +# relevant IPF color maps as they were computed by DREAM.3D. +# Given that in this case the origin of the data is the DREAM.3D file +# again provenance is kept and more details can be followed upon when +# resolving origin. +# +# These examples offer a first set of suggestions on how to make EBSD +# data injectable into research data management system using schemes +# which themselves are agnostic to the specific RDMS and interoperable. +# Steps of collecting the raw data and post-processing these with custom +# scripts like MTex or commercial tools so far are mainly undocumented. +# The limitation is that a program which consumes results or dump files +# from these tools may not have necessarily all the sufficient information +# available to check if the injected orientation data and color models +# are matching the conventions which a user or automated system has +# injected into an electronic lab notebook from which currently the em_om +# parser collects the conventions and stores them into this NXem_ebsd instance. +# The immediate benefit of the here presented NXem_ebsd concept though +# is that the conventions and reference frame definitions are expected +# in an ELN-agnostic representation to make NXem_ebsd a generally useful +# data scheme for EBSD. +# +# Ideally, the em_om parser would load convention-compliant EBSD data +# and use subsequently a community library to transcode/convert orientation +# conventions and parameterized orientation values. Thereafter, convention- +# compliant default plot(s) could be created that would be truely interoperable. +# +# However, given the variety of post-processing tools available surplus +# the fact that these are not usually executed along standardized +# post-processing workflows which perform exactly the same algorithmic steps, +# this is currently not a practically implementable option. Indeed, first +# developers who wish to implement this would first have to create a library +# for performing such tasks, mapping generally between conventions, +# i.e. map and rotate coordinate systems at the parser level. +# +# The unfortunate situation in EBSD is that due to historical reasons +# and competitive strategies, different players in the field have +# implemented (slightly) different approaches each of which misses +# some part of a complete workflow description which is behind EBSD analyses: +# Sample preparation, measurement, indexing, post-processing, paper... +# +# The here exemplified default plot do not so far apply relevant rotations +# but takes the orientation values as they come from the origin and using +# coloring them as they come. It is thus the scientists responsibility to +# enter and check if the respective dataset is rotation-conventions-wise +# consistent and fit for a particular task. +# +# Ideally, with all conventions defined it can be possible to develop +# a converter which rotates the input data. This application definition +# does not assume this and users should be aware of this limitation. +# +# The key point is that the conventions however are captured and this is +# the most important step to the development of such a generic transcoder +# for creating interoperable EBSD datasets. +# +# Currently the conventions remain in the mind or manual lab book of the +# respective scientists or technicians instead of getting stored and +# communicated with research papers that are written based on +# specific dataset, i.e. database entries. +# +# The default gridded representation of the data should not be +# misinterpreted as the only possible way how EBSD data and OIM +# maps can be created! +# +# Indeed, the most general case is that patterns are collected for +# scan points. The scan generator of an electron microscope is instructed +# to steer the beam in such a way across the specimen surface that the +# beam illuminates certain positions for a certain amount time (usually +# equally-spaced and spending about the same amount of time at each +# position). +# +# Therefore, scan positions can be due to such regular flight plans and +# represent sampling on lines, line stacks, rectangular regions-of- +# interests, but also could instruct spiral, random, or adaptive scans +# instead of tessellations with square or hexagonal pixels. +# +# The majority of EBSD maps is though is reporting results for a regular +# grid (square, hexagon). What matters though in terms of damage induced +# by the electron beam and signal quality is the real electron dose +# history, i.e. for how long the beam exposed which location of the +# specimen. Especially when electron charging occurs (i.e. an excess +# amount of charge accumulates due to e.g. poor conducting away of this +# charge or an improper mounting, too high dose, etc. such details are +# relevant. +# +# Specifically, the default visualization is an inverse pole-figure (IPF) +# map with the usual RGB color coding. Different strategies and +# normalization schemes are in use to define such color coding. +# +# Finally, we should mention that each ipf_map represents data for +# scan points indexed as one phase. The alias/name of this phase should +# be stored in phase_name, the phase_identifier give an ID which must +# not be zero as this value is reserved for non-indexed / null model scan +# points. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXms_ipf_set.yaml b/contributed_definitions/nyaml/NXms_ipf_set.yaml new file mode 100644 index 0000000000..a783655a24 --- /dev/null +++ b/contributed_definitions/nyaml/NXms_ipf_set.yaml @@ -0,0 +1,9 @@ +category: base +doc: | + Base class to group multiple :ref:`NXms_ipf` instances. + + A collection of inverse pole figure approximations. +# symbols: +type: group +NXms_ipf_set(NXprocess): + (NXms_ipf): diff --git a/contributed_definitions/nyaml/NXms_mtex_config.yaml b/contributed_definitions/nyaml/NXms_mtex_config.yaml new file mode 100644 index 0000000000..b8fee982d5 --- /dev/null +++ b/contributed_definitions/nyaml/NXms_mtex_config.yaml @@ -0,0 +1,187 @@ +category: base +doc: | + Base class to store the configuration when using the MTex/Matlab software. + + MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. + See `R. Hielscher et al. `_ and + the `MTex source code `_ for details. +type: group +NXms_mtex_config(NXobject): + conventions(NXcollection): + doc: | + Reference frame and orientation conventions. + Consult the `MTex docs `_ for details. + x_axis_direction(NX_CHAR): + doc: | + TODO with MTex developers + # enumeration: + # check against v5.12 + z_axis_direction(NX_CHAR): + doc: | + TODO with MTex developers + # enumeration: + a_axis_direction(NX_CHAR): + doc: | + TODO with MTex developers + # enumeration: + b_axis_direction(NX_CHAR): + doc: | + TODO with MTex developers + # enumeration: + euler_angle(NX_CHAR): + doc: | + TODO with MTex developers + enumeration: [unknown, undefined, bunge] + plotting(NXcollection): + doc: | + Settings relevant for generating plots. + font_size(NX_NUMBER): + doc: | + TODO with MTex developers + unit: NX_ANY + inner_plot_spacing(NX_NUMBER): + doc: | + TODO with MTex developers + unit: NX_ANY + outer_plot_spacing(NX_NUMBER): + doc: | + TODO with MTex developers + unit: NX_ANY + marker_size(NX_NUMBER): + doc: | + TODO with MTex developers + unit: NX_ANY + figure_size(NX_NUMBER): + doc: | + TODO with MTex developers + show_micron_bar(NX_BOOLEAN): + doc: | + True if MTex renders a scale bar with figures. + show_coordinates(NX_BOOLEAN): + doc: | + True if MTex renders a grid with figures. + pf_anno_fun_hdl: + doc: | + Code for the function handle used for annotating pole figure plots. + color_map(NX_NUMBER): + doc: | + TODO with MTex developers + unit: NX_UNITLESS + dim: (i, 3) + default_color_map(NX_NUMBER): + doc: | + TODO with MTex developers + unit: NX_UNITLESS + dim: (i, 3) + # phase_color_order: + # doc: | + # TODO with MTex developers + # unit: NX_UNITLESS + # dim: (i,) + color_palette(NX_CHAR): + degree_char(NX_CHAR): + doc: | + TODO with MTex developers + arrow_char(NX_CHAR): + doc: | + TODO with MTex developers + marker(NX_CHAR): + doc: | + TODO with MTex developers + marker_edge_color(NX_CHAR): + doc: | + TODO with MTex developers + marker_face_color(NX_CHAR): + doc: | + TODO with MTex developers + hit_test(NX_BOOLEAN): + doc: | + TODO with MTex developers + miscellaneous(NXcollection): + doc: | + Miscellaneous other settings of MTex. + mosek(NX_BOOLEAN): + doc: | + TODO with MTex developers + generating_help_mode(NX_BOOLEAN): + doc: | + TODO with MTex developers + methods_advise(NX_BOOLEAN): + doc: | + TODO with MTex developers + stop_on_symmetry_mismatch(NX_BOOLEAN): + doc: | + TODO with MTex developers + inside_poly(NX_BOOLEAN): + doc: | + TODO with MTex developers + text_interpreter: + numerics(NXcollection): + doc: | + Miscellaneous settings relevant for numerics. + eps(NX_NUMBER): + doc: | + Return value of the Matlab eps command. + unit: NX_UNITLESS + fft_accuracy(NX_NUMBER): + doc: | + TODO with MTex developers + unit: NX_ANY # NX_LENGTH or NX_RECIPROCAL_LENGTH? + max_stwo_bandwidth(NX_NUMBER): + doc: | + TODO with MTex developers + unit: NX_ANY # radiant? + max_sothree_bandwidth(NX_NUMBER): + doc: | + TODO with MTex developers + unit: NX_ANY # radiant? + system(NXcollection): + doc: | + Miscellaneous settings relevant of the system where MTex runs. + memory(NX_NUMBER): + doc: | + TODO with MTex developers + open_gl_bug(NX_BOOLEAN): + doc: | + TODO with MTex developers + save_to_file(NX_BOOLEAN): + doc: | + TODO with MTex developers + path(NXcollection): + doc: | + Collection of paths from where MTex reads information and code. + mtex(NX_CHAR): + doc: | + Absolute path to specific component of MTex source code. + data(NX_CHAR): + doc: | + Absolute path to specific component of MTex source code. + cif(NX_CHAR): + doc: | + Absolute path to specific component of MTex source code. + ebsd(NX_CHAR): + doc: | + Absolute path to specific component of MTex source code. + pf(NX_CHAR): + doc: | + Absolute path to specific component of MTex source code. + odf(NX_CHAR): + doc: | + Absolute path to specific component of MTex source code. + tensor(NX_CHAR): + doc: | + Absolute path to specific component of MTex source code. + example(NX_CHAR): + doc: | + Absolute path to specific component of MTex source code. + import_wizard(NX_CHAR): + doc: | + Absolute path to specific component of MTex source code. + pf_extensions(NX_CHAR): + doc: | + List of file type suffixes for which MTex assumes + texture/pole figure information. + ebsd_extensions(NX_CHAR): + doc: | + List of file type suffixes for which MTex assumes EBSD content. + # version as an instance of (NXprogram) one for MTex one for Matlab diff --git a/contributed_definitions/nyaml/NXms_odf.yaml b/contributed_definitions/nyaml/NXms_odf.yaml new file mode 100644 index 0000000000..92ad96589a --- /dev/null +++ b/contributed_definitions/nyaml/NXms_odf.yaml @@ -0,0 +1,99 @@ +category: base +doc: | + Base class to store an orientation distribution function (ODF) computation. +symbols: + n_varphi_one: | + Number of pixel per varphi section plot along the varphi_one fastest direction. + n_capital_phi: | + Number of pixel per varphi section plot along the capital_phi slow direction. + n_varphi_two: | + Number of pixel per varphi section plot along the varphi_two slowest direction. + k: | + Number of local maxima evaluated in the component analysis. +type: group +NXms_odf(NXprocess): + configuration(NXobject): + doc: | + Details about the algorithm used for computing the ODF. + crystal_symmetry_point_group(NX_CHAR): + doc: | + Point group of the crystal structure (International Table of Crystallography) + of the phase for which the here documented phase-dependent ODF was computed. + specimen_symmetry_point_group(NX_CHAR): + doc: | + Point group assumed for processing-induced *sample symmetries*. + (according to International Table of Crystallography). + kernel_halfwidth(NX_NUMBER): + doc: | + Halfwidth of the kernel. + unit: NX_ANGLE + kernel_name(NX_CHAR): + doc: | + Name of the kernel. + resolution(NX_NUMBER): + doc: | + Resolution of the kernel. + unit: NX_ANGLE + kth_extrema(NXobject): + kth(NX_UINT): + doc: | + Number of local maxima evaluated for the ODF. + unit: NX_UNITLESS + # value of kth should be k + location(NX_NUMBER): + doc: | + Euler angle representation of the kth-most maxima of the ODF + in decreasing order of the intensity maximum. + unit: NX_ANGLE + dim: (k, 3) + theta(NX_NUMBER): + doc: | + Disorientation threshold within which intensity of the ODF + is integrated for the component analysis. + unit: NX_ANGLE + volume_fraction(NX_NUMBER): + doc: | + Integrated ODF intensity within a theta-ball of SO3 about + each location as specified for each location in the order + and reported in the order of these locations. + unit: NX_ANY + dim: (k,) + phi_two_plot(NXdata): + doc: | + Visualization of the ODF intensity as orthogonal sections through Euler space. + + This is one example of typical default plots used in the texture + community in Materials Engineering. + + Mind that the Euler space is a distorted space. Therefore, equivalent + orientations show intensity contributions in eventually multiple + locations. + # \@signal: intensity + # \@axes: [varphi_two, capital_phi, varphi_one] + # \@varphi_one_indices: 0 + # \@capital_phi: 1 + # \@varphi_two_indices: 2 + intensity(NX_NUMBER): + doc: | + ODF intensity at probed locations relative to + null model of a completely random texture. + unit: NX_DIMENSIONLESS + dim: (n_varphi_two, n_capital_phi, n_varphi_one) + varphi_one(NX_NUMBER): + doc: | + Pixel center angular position along the :math:`\varphi_1` direction. + unit: NX_ANGLE + dim: (n_varphi_one,) + # \@long_name(NX_CHAR): + varphi_two(NX_NUMBER): + doc: | + Pixel center angular position along the :math:`\varphi_2` direction. + unit: NX_ANGLE + dim: (n_varphi_two,) + # \@long_name(NX_CHAR): + capital_phi(NX_NUMBER): + doc: | + Pixel center angular position along the :math:`\Phi` direction. + unit: NX_ANGLE + dim: (n_capital_phi,) + # \@long_name(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXms_odf_set.yaml b/contributed_definitions/nyaml/NXms_odf_set.yaml new file mode 100644 index 0000000000..5ea1c4d6cb --- /dev/null +++ b/contributed_definitions/nyaml/NXms_odf_set.yaml @@ -0,0 +1,9 @@ +category: base +doc: | + Base class to group multiple :ref:`NXms_odf` instances. + + A collection of orientation distribution function approximations. +# symbols: +type: group +NXms_odf_set(NXprocess): + (NXms_odf): diff --git a/contributed_definitions/nyaml/NXms_pf.yaml b/contributed_definitions/nyaml/NXms_pf.yaml new file mode 100644 index 0000000000..09ab12f785 --- /dev/null +++ b/contributed_definitions/nyaml/NXms_pf.yaml @@ -0,0 +1,59 @@ +category: base +doc: | + Base class to store a pole figure (PF) computation. +symbols: + n_y: | + Number of pixel per pole figure in the slow direction. + n_x: | + Number of pixel per pole figure in the fast direction. +type: group +NXms_pf(NXprocess): + configuration(NXobject): + doc: | + Details about the algorithm that was used to compute the pole figure. + crystal_symmetry_point_group(NX_CHAR): + doc: | + Point group of the crystal structure of the phase for which the + here documented phase-dependent pole figure was computed + (according to International Table of Crystallography). + specimen_symmetry_point_group(NX_CHAR): + doc: | + Point group assumed for processing induced *sample symmetries* + (according to International Table of Crystallography). + halfwidth(NX_NUMBER): + doc: | + Halfwidth of the kernel. + unit: NX_ANGLE + miller_indices(NX_CHAR): + doc: | + Miller indices (:math:`(hkl)[uvw]`) to specify the pole figure. + resolution(NX_NUMBER): + doc: | + Resolution of the kernel. + unit: NX_ANGLE + pf(NXdata): + doc: | + Pole figure. + # \@signal: intensity + # \@axes: [axis_y, axis_x] + # \@axis_x_indices: 0 + # \@axis_y_indices: 1 + intensity(NX_NUMBER): + doc: | + Pole figure intensity. + unit: NX_UNITLESS + dim: (n_y, n_x) + axis_y(NX_NUMBER): + doc: | + Pixel center along y direction in the equatorial plane of + a stereographic projection of the unit sphere. + unit: NX_ANY + dim: (n_y,) + # \@long_name(NX_CHAR): + axis_x(NX_NUMBER): + doc: | + Pixel center along x direction in the equatorial plane of + a stereographic projection of the unit sphere. + unit: NX_ANY + dim: (n_x,) + # \@long_name(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXms_pf_set.yaml b/contributed_definitions/nyaml/NXms_pf_set.yaml new file mode 100644 index 0000000000..afd785f157 --- /dev/null +++ b/contributed_definitions/nyaml/NXms_pf_set.yaml @@ -0,0 +1,9 @@ +category: base +doc: | + Base class to group multiple :ref:`NXms_pf` instances. + + A collection of pole figure approximations. +# symbols: +type: group +NXms_pf_set(NXprocess): + (NXms_pf): diff --git a/contributed_definitions/nyaml/NXms_recon.yaml b/contributed_definitions/nyaml/NXms_recon.yaml new file mode 100644 index 0000000000..bd6825bacc --- /dev/null +++ b/contributed_definitions/nyaml/NXms_recon.yaml @@ -0,0 +1,315 @@ +# position would need another depends_on the specific coordinate system used, currently we assume McStas +# roi1/ebsd/microstructure1 +category: base +doc: | + Base class to describe discretized (micro)structural features of a material. + + One instance of this base class can be used to describe the current configuration + the base class does not include time-dependent descriptions for the sake of + clarity and because of the fact that virtually all simulations or experiments + probe time by sampling. Therefore, time-dependent state descriptions should + be realized with creating a set of :ref:`NXms_snapshot_set` with instances of + :ref:`NXms_snapshot` using e.g. :ref:`NXms_recon` base class instances. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + # in so-called linear intercept analysis we observe + # one-dimensional sections of either projections (see below) + # or true one-dimensional cuts across a volume of material + # n_icept: | + # The number of linear intercepts defined. + # n_c_one: | + # The number of crystal projections segmented by crossing (projected or real) interfaces + # n_i_one: | + # The number of crossings + # two-dimensional projections of characterized in reality three-dimensional objects + # using E. E. Underwood notation + # crystals/grains are projections that are delineated by projections of interface, i.e. interface lines which meet at projections of triple lines i.e. triple "points" + n_c_two: | + The number of crystal projections. + n_i_two: | + The number of interface projections. + n_t_two: | + The number of assumed triple junction projections aka triple points. + # three-dimensional real objects, volumetrically characterized + # crystals are delineated by interfaces that are delineated by triple lines that meet at quad junctions + n_c: | + The number of crystals. + n_i: | + The number of interfaces + n_t: | + The number of triple lines + n_q: | + The number of quadruple junctions. +type: group +NXms_recon(NXobject): + # as e.g. a result of one grain reconstruction with MTex or othe + # grain reconstruction software in commercial tools + # the idea is we may wish to run as many grain reconstructions as we want... + # add details about the processing + configuration(NXprocess): + doc: | + The configuration and parameterization of the reconstruction algorithm + whereby the microstructural features were identified. + # maybe a depends_on what was the input however if the group is injected + # in an roi1/ebsd instance isnt this information implicit? + dimensionality(NX_POSINT): + doc: | + Dimensionality of the analysis. + + This field can be used e.g. by a research data management system + to identify if the described feature set specifies a + one-, two-, or three-dimensional feature set. + unit: NX_UNITLESS + enumeration: [1, 2, 3] + algorithm(NX_CHAR): + doc: | + Which algorithm is used to reconstruct the features. + enumeration: [unknown, disorientation_clustering, fast_multiscale_clustering, markov_chain_clustering] + disorientation_threshold(NX_NUMBER): + doc: | + Threshold to define at which disorientation angle to assume + two crystalline regions have a significant orientation difference + which warrants to argue that there is an interface between the + two regions. + unit: NX_ANGLE + # the result of running one grain reconstruction + # ms_feature_set1 + # we could also enumerate instances ms_feature_setID here because configuration + # may specify a range of different parameter resulting in multiple ms_feature_sets + # dimensionality(N) composed from NXms_feature_set base: + # controlled vocabulary of base class instances to be used to inform about the + # discretization of these features instances to discretize the features + # wherever possible the computational geometry specific instances whose + # purpose is only to support/represent the discretization of the features should + # be separated out from the materials engineering interpretation of what these + # features are, i.e. a grain that is measured with a 2d section ends up + # modelled as an projection of that real 3d grain object + # the model is discretized usign a polyline which models the location of the + # interface at the required here coarse-grained continuum picture + points(NXcg_point_set): + lines(NXcg_polyline_set): + surfaces(NXcg_triangle_set): + volumes(NXcg_polyhedron_set): + + # domain-specific, i.e. microstructural features + # ONE DIMENSIONAL FEATURES + + # TWO DIMENSIONAL FEATURES + crystal_projections(NXms_feature_set): + doc: | + Projections of crystals on the sample surface as typically + characterized with optical or electron microscopy. + \@discretization(NX_CHAR): + doc: | + Reference to lines(NXcg_polyline_set) which supports the + discretized shape of each cross-sectioned crystal. + + Most microscopy techniques support to generate only a two-dimensional + representation (projection) of the characterized material. + + For true volumetric techniques use the specifically + specialized crystals :ref:`NXms_feature_set` instead. + See stereology literature for more details e.g. + E.E. Underwood's book entitled Quantitative Stereology + number_of_crystals(NX_UINT): + doc: | + Number of crystals. + unit: NX_UNITLESS + crystal_identifier_offset(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the set differs from zero. + + Identifiers can be defined either implicitly or explicitly. + For implicit indexing identifiers are defined on the interval + :math:`[identifier_offset, identifier_offset + c - 1]`. + unit: NX_UNITLESS + crystal_identifier(NX_INT): + doc: | + Identifier used for crystals for explicit indexing. + unit: NX_UNITLESS + dim: (n_c_two,) + number_of_phases(NX_UINT): + doc: | + How many phases are distinguished + unit: NX_UNITLESS + phase_identifier_offset(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the set differs from zero. + unit: NX_UNITLESS + phase_identifier(NX_INT): + # \@depends_on(NX_CHAR): + doc: | + Identifier used for phase for explicit indexing. + unit: NX_UNITLESS + dim: (n_c_two,) + # properties of crystal_projections aka grain properties + boundary_contact(NX_BOOLEAN): + doc: | + True, if the crystal makes contact with the edge of the ROI, + false otherwise. + dim: (n_c_two,) + orientation_spread(NX_NUMBER): + doc: | + Average disorientation angle between individual orientation of the + crystal at probed positions (weighted by area of that position) versus + the average disorientation of the crystal. + unit: NX_ANGLE + dim: (n_c_two,) + (NXrotation_set): + area(NX_NUMBER): + doc: | + Calibrated area of surrounded by the polyline about each crystal. + unit: NX_AREA + dim: (n_c_two,) + interface_projections(NXms_feature_set): + # grain boundaries have a network of line-like defects, its explicit description + # often generates unnecessary information duplication and cluttering, + # therefore here a compact and suggestion how to store such data + doc: | + Projections of grain or phase boundaries as typically sectioned + with optical or electron microscopy characterization. + \@discretization(NX_CHAR): + doc: | + Reference to lines(NXcg_polyline_set) which supports the + discretized shape of each cross-sectioned crystal. + + Set of tuples of polyline segments which build the interface. + # topology + # i) Set of pair of crystals sharing an interface + crystals(NX_INT): + doc: | + Set of pairs of crystal_identifier resolved via depends_on which + are adjacent to each interface. + unit: NX_UNITLESS + dim: (n_i_two, 2) + \@depends_on(NX_CHAR): + doc: | + The specific crystal_projections(NXms_feature_set) instance + to resolve crystal identifier. + # ii) Set of pair of topologically connected triple points + triple_points(NX_INT): + doc: | + Set of pairs of triple_point_identifier which the interface connects. + For 2D projections of 3D microstructural features a triple point is + physically only the projection of a triple line. + unit: NX_UNITLESS + dim: (n_i_two, 2) + \@depends_on(NX_CHAR): + doc: | + The specific triple_line_projections(NXms_feature_set) instance + whereby to resolve triple_point identifier. + # alternatively which polyline of adjoining interfaces + # properties, descriptors + length(NX_NUMBER): + doc: | + The length of the interface. + + This is not necessarily the same as the length of the individual + polyline segments whereby the interface is discretized. + + The actual coordinate system whereby the geometry is calibrated + with real physical dimensions is typically documented by the + depends_on attribute of the respective NXcg_primitive_set. + This depends_on attribute should point explicitly to an + instance of a :ref:`NXcoordinate_system` to support users as + much as possible with interpreting how and where the lines are + located in the reference frame. + unit: NX_LENGTH + dim: (n_i_two,) + interface_identifier_offset(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the set differs from zero. + + Identifiers can be defined either implicitly or explicitly. + For implicit indexing identifiers are defined on the interval + :math:`[identifier_offset, identifier_offset + c - 1]`. + unit: NX_UNITLESS + interface_identifier(NX_INT): + doc: | + Identifier for each interface using explicit indexing. + unit: NX_UNITLESS + dim: (n_i_two,) + triple_line_projections(NXms_feature_set): + # only for 2D, quad junction is the equivalent for 3D is not a triple_line + # four alternative descriptors with different strength to specify spatial + # or logical information about the triple junction feature set. + # the explicit description often generating unnecessary information duplication + doc: | + Projections of triple lines as typically characterized with optical + or electron microscopy. + + Mind that most specimens are thermo-chemo-mechanically treated before + they are characterized. Therefore, the projected crystal defects are + have physically no longer the same structure as in the bulk. + + Examples are manifest as effects such as thermal grooving, or relaxation + effects of an intersection between a triple line that is cut + by the specimen surface as these defects are then exposed typically + to a different atmosphere and hence have different thermodynamic boundary + conditions than of their true volumetric defects in the bulk. + \@discretization(NX_CHAR): + doc: | + Reference to points(NXcg_point_set) which supports the + locations of these triple points. + # another view to describe a triple junction is via its topology/connection expressed either via + # i) triplet of interface identifier + number_of_triple_points(NX_UINT): + doc: | + Number of triple points. + unit: NX_UNITLESS + triple_point_identifier_offset(NX_INT): + doc: | + Integer offset whereby the identifier of the first member + of the set differs from zero. + + Identifiers can be defined either implicitly or explicitly. + For implicit indexing identifiers are defined on the interval + :math:`[identifier_offset, identifier_offset + c - 1]`. + unit: NX_UNITLESS + triple_point_identifier(NX_INT): + doc: | + Identifier for each triple point using explicit indexing. + unit: NX_UNITLESS + dim: (n_t_two,) + location(NX_INT): + doc: | + Set of triple point identifiers. + unit: NX_UNITLESS + dim: (n_t_two,) + \@depends_on(NX_CHAR): + doc: | + The relevant points(NXcg_point_set) instance whereby to + resolve interface identifiers. + interfaces(NX_INT): # aka topology or interfaces + doc: | + Set of triplets of identifier of line-like features. + Each triplet resolves which three interface projections + the triple point connects. + unit: NX_UNITLESS + dim: (n_t_two, 3) + \@depends_on(NX_CHAR): + doc: | + The specific interface_projections(NXms_feature_set) + instance whereby to resolve interface identifiers. + # ii) a triplet of line segment identifier whereby the point-like features + # is assumed discretized via three polylines representing interfaces + polylines(NX_INT): + doc: | + Triplet of identifier of polyline segments. Each triplet resolves + which three segments of polyline segments the triple junction connects. + unit: NX_UNITLESS + dim: (n_t_two, 3) + \@depends_on(NX_CHAR): + doc: | + The specific lines(NXcg_polyline_set) instance to resolve + polyline segments. + # the difference in the interpretation of interfaces and polylines + # is that the interface resolves interface (e.g. phase boundary names) + # while polylines resolves segments within the set of named geometric primitive + # instances! + # add all sort of other qualitative or quantitive descriptors (triple junction + # energy, volume etc), i.e properties of that triple point diff --git a/contributed_definitions/nyaml/NXms_score_results.yaml b/contributed_definitions/nyaml/NXms_score_results.yaml index 0feed8437a..2996c7d7c7 100644 --- a/contributed_definitions/nyaml/NXms_score_results.yaml +++ b/contributed_definitions/nyaml/NXms_score_results.yaml @@ -199,7 +199,7 @@ NXms_score_results(NXobject): coordinate system should be described with an NXtransformations instance. TRANSFORMATIONS(NXtransformations): exists: ['min', '3', 'max', 'unbounded'] - conventions(NXem_ebsd_conventions): + conventions(NXem_conventions): rotation_conventions(NXprocess): three_dimensional_rotation_handedness: rotation_convention: @@ -610,726 +610,3 @@ NXms_score_results(NXobject): exists: recommended max_resident_memory_snapshot(NX_NUMBER): exists: recommended - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d3f6e7e4ebdd514db8e3fc3047a050c89e77760f7d6642a66e77d4958f71737d -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of boundaries of the bounding box or primitive to domain. -# -# -# -# -# Number of parameter required for chosen orientation parameterization. -# -# -# -# -# Number of texture components identified. -# -# -# -# -# Dimensionality. -# -# -# -# -# Cardinality. -# -# -# -# -# Number of active cells in the (recrystallization) front. -# -# -# -# -# Number of grains in the computer simulation. -# -# -# -# -# Application definition for storing results of the SCORE cellular automaton. -# -# The SCORE cellular automaton model for primary recrystallization is an -# example of typical materials engineering applications used within the field -# of so-called Integral Computational Materials Engineering (ICME) whereby -# one can simulate the evolution of microstructures. -# -# Specifically the SCORE model can be used to simulate the growth of static -# recrystallization nuclei. The model is described in the literature: -# -# * `M. Kühbach et al. <https://doi.org/10.1016/j.actamat.2016.01.068>`_ -# * `C. Haase et al. <https://doi.org/10.1016/j.actamat.2015.08.057>`_ -# * `M. Diehl et al. <https://doi.org/10.1088/1361-651X/ab51bd>`_ -# -# -# -# -# An at least as strong as SHA256 hashvalue of the file -# that specifies the application definition. -# -# -# -# -# -# NeXus NXDL schema to which this file conforms. -# -# -# -# -# -# -# -# Ideally, a (globally) unique persistent identifier -# for referring to this computer simulation. -# -# The identifier is usually defined/issued by the facility, laboratory, -# or the principle investigator. The identifier enables to link -# experiments to e.g. proposals. -# -# -# -# -# Free-text description about the workflow (analysis/simulation). -# -# Users are strongly advised to detail the sample history in the -# respective field and fill rather as completely as possible the fields -# of this application definition rather than write details about the -# experiment into this free-text description field. -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC information -# included when the characterization started. -# -# -# -# -# ISO 8601 time code with local time zone offset to UTC included -# when the characterization ended. -# -# -# -# -# -# -# -# -# -# Specify if the (characterization) results/data of this instance of an -# application definition are based on the results of a simulation or the -# results of a post-processing of measured data to describe a microstructure. -# The term microstructure is used to describe the spatial arrangement of -# crystal defects inside a sample/specimen without demanding necessarily -# that this structure is mainly at the micron length scale. -# Nanostructure and macrostructure are close synonyms. -# Material architecture is a narrow synonym. -# -# -# -# -# -# -# -# -# -# The path and name of the config file for this analysis. -# -# -# -# At least SHA256 strong hash of the specific config_file for -# tracking provenance. -# -# -# -# -# -# Path to the directory where the tool should store NeXus/HDF5 results -# of this analysis. If not specified results will be stored in the -# current working directory. -# -# -# -# -# A statement whether the SCORE executable managed to -# process the analysis or failed prematurely. -# -# This status is written to the results file after the end_time -# at which point the executable must not compute any analysis. -# Only when this status message is present and shows `success`, the -# user should consider the results. In all other cases it might be -# that the executable has terminated prematurely or another error -# occurred. -# -# -# -# -# -# -# -# -# Contact information and eventually details of at least one person -# involved in creating this result. This can be the principle investigator -# who performed this experiment. Adding multiple users if relevant is recommended. -# -# -# -# Given (first) name and surname of the user. -# -# -# -# -# Name of the affiliation of the user at the point in time -# when the experiment was performed. -# -# -# -# -# Postal address of the affiliation. -# -# -# -# -# Email address of the user at the point in time when the experiment -# was performed. Writing the most permanently used email is recommended. -# -# -# -# -# Globally unique identifier of the user as offered by services -# like ORCID or ResearcherID. If this field is field the specific service -# should also be written in orcid_platform -# -# -# -# -# Name of the OrcID or ResearcherID where the account -# under orcid is registered. -# -# -# -# -# (Business) (tele)phone number of the user at the point -# in time when the experiment was performed. -# -# -# -# -# Which role does the user have in the place and at the point -# in time when the experiment was performed? Technician operating -# the microscope. Student, postdoc, principle investigator, guest -# are common examples. -# -# -# -# -# Account name that is associated with the user in social media platforms. -# -# -# -# -# Name of the social media platform where the account -# under social_media_name is registered. -# -# -# -# -# -# -# -# Descriptive name or ideally (globally) unique persistent identifier. -# -# -# -# -# -# -# Hard link to a location in the hierarchy of the NeXus file -# where the data for default plotting are stored. -# -# -# -# -# Container to hold different coordinate systems conventions. -# A least a right-handed Cartesian coordinate system with base vectors -# named x, y, and z has to be specified. Each base vector of the -# coordinate system should be described with an NXtransformations instance. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The simulated or characterized material volume element aka domain. -# At least one instance of geometry required either NXcg_grid, -# NXcg_polyhedron_set, or NXcg_point_set. This geometry group needs -# to contain details about the boundary conditions. -# -# -# -# -# -# -# -# -# -# -# -# -# A tight bounding box or sphere or bounding primitive about the grid. -# -# -# -# -# How many distinct boundaries are distinguished? -# Most grids discretize a cubic or cuboidal region. In this case -# six sides can be distinguished, each making an own boundary. -# -# -# -# -# Name of the boundaries. E.g. left, right, front, back, bottom, top, -# The field must have as many entries as there are number_of_boundaries. -# -# -# -# -# The boundary conditions for each boundary: -# -# 0 - undefined -# 1 - open -# 2 - periodic -# 3 - mirror -# 4 - von Neumann -# 5 - Dirichlet -# -# -# -# -# -# -# -# -# Collection of microstructural data observed/simulated. -# -# -# -# Integer which specifies the first index to be used for distinguishing -# snapshots. Identifiers are defined either implicitly or explicitly. -# For implicit indexing the identifiers are defined on the -# interval [identifier_offset, identifier_offset+c-1]. -# For explicit indexing the identifier array has to be defined. -# -# The identifier_offset field can for example be used to communicate -# if the identifiers are expected to start from 1 (referred to as -# Fortran-/Matlab-) or from 0 (referred to as C-, Python-style index -# notation) respectively. -# -# -# -# -# -# Summary quantities which are the result of some post-processing of -# the snapshot data (averaging, integrating, interpolating). -# Frequently used descriptors from continuum mechanics and thermodynamics -# can be used here. A few examples are given. Each descriptor is currently -# modelled as an instance of an NXprocess because it is relevant to -# understand how the descriptors are computed. -# -# -# -# Evolution of the physical time. -# -# -# -# -# Evolution of the simulated temperature over time. -# -# -# -# -# -# Evolution of the recrystallized volume fraction over time. -# -# -# -# -# -# -# -# Measured or simulated physical time stamp for this snapshot. -# Not to be confused with wall-clock timing or profiling data. -# -# -# -# -# Simulated temperature. -# -# -# -# -# Iteration or increment counter. -# -# -# -# -# -# -# Grain identifier for each cell. -# -# -# -# -# -# -# -# -# -# Identifier of the OpenMP thread which processed this part of the grid. -# -# -# -# -# -# -# -# -# -# -# -# Details about those cells which in this time step represent -# the discretized recrystallization front. -# -# -# -# Which cells are currently in a halo region of threads. -# -# -# -# -# -# -# -# So-called mobility weight which is a scaling factor to -# control the mobility of the grain boundary which is assumed -# to sweep currently this volume. -# -# -# -# -# -# -# -# Grid coordinates of each cell in the recrystallization front. -# -# -# -# -# -# -# -# -# Grain identifier assigned to each cell in the recrystallization front. -# -# -# -# -# -# -# -# Grain identifier assigned to each nucleus which affected that cell in the -# recrystallization front. -# -# -# -# -# -# -# -# Relative volume transformed as a measure of infection progress. -# -# -# -# -# -# -# -# Identifier of the OpenMP thread processing each cell in the recrystallization -# front. -# -# -# -# -# -# -# -# Hint about the direction from which the cell was infected. -# -# -# -# -# -# -# -# -# Current grain-related quantities. -# -# -# -# Bunge-Euler angle triplets for each grain. -# -# -# -# -# -# -# -# -# Discrete volume of each grain accounting also for partially -# transformed cells. -# -# -# -# -# -# -# -# Current value for the dislocation density as a measure of -# the remaining stored energy in assumed crystal defects inside -# each grain. The difference between these values scales the -# driving force of grain boundary migration. -# -# -# -# -# -# -# -# Is the grain deformed. -# -# -# -# -# -# -# -# Is the grain recrystallized. -# -# -# -# -# -# -# -# -# Current recrystallized volume fraction. -# -# -# -# Currently evaluated actual recrystallized volume fraction. -# This takes into account partially recrystallized cells. -# -# -# -# -# Currently desired target recrystallized volume fraction at -# which the user requested to log a snapshot. -# -# -# -# -# -# -# -# Currently assumed globally applied Cauchy stress tensor on the ROI. -# -# -# -# -# -# -# -# -# -# -# Currently assumed globally applied Cauchy strain tensor on the ROI. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Specify if it was different from the number_of_processes -# in the NXcs_profiling super class. -# -# -# -# -# -# Specify if it was different from the number_of_threads -# in the NXcs_profiling super class. -# -# -# -# -# -# Specify if it was different from the number_of_threads -# in the NXcs_profiling super class. -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXoptical_system_em.yaml b/contributed_definitions/nyaml/NXoptical_system_em.yaml index adb28a6bbf..5ed2c4be33 100644 --- a/contributed_definitions/nyaml/NXoptical_system_em.yaml +++ b/contributed_definitions/nyaml/NXoptical_system_em.yaml @@ -3,47 +3,53 @@ doc: | A container for qualifying an electron optical system. type: group NXoptical_system_em(NXobject): - # NEW ISSUE: for now used to store difficult to place entries # NEW ISSUE: all the definitions here should better be backed up by the # work of the HMC EM glossary activities camera_length(NX_NUMBER): - unit: NX_LENGTH doc: | Citing the JEOL TEM glossary this is *an effective distance from a specimen to a plane where an observed diffraction pattern is formed*. - magnification(NX_NUMBER): - unit: NX_DIMENSIONLESS + unit: NX_LENGTH + magnification(NX_NUMBER): # R+ otherwise it is demagnification doc: | - The factor of enlargement of the apparent size, not physical size, of an object. + The factor of enlargement of the apparent size, + not the physical size, of an object. + unit: NX_DIMENSIONLESS defocus(NX_NUMBER): unit: NX_LENGTH doc: | - The defocus aberration constant oftentimes taken as the C_1_0 which - is described in more details in NXaberration. + The defocus aberration constant (oftentimes referred to as C_1_0). + See respective details in :ref:`NXaberration` class instances. semi_convergence_angle(NX_NUMBER): - unit: NX_ANGLE doc: | Citing the JEOL TEM glosssary this is the value *when a cone shaped, convergent electron beam illuminates a specimen, the semi-angle of the cone is termed convergence angle.* + unit: NX_ANGLE field_of_view(NX_NUMBER): - unit: NX_LENGTH doc: | The extent of the observable parts of the specimen given the current magnification and other settings of the instrument. - working_distance(NX_FLOAT): unit: NX_LENGTH + working_distance(NX_NUMBER): doc: | Citing `Globalsino `_ this is *a distance between the specimen and the lower pole piece in SEM system*. - beam_current(NX_FLOAT): - unit: NX_CURRENT + unit: NX_LENGTH + beam_current(NX_NUMBER): + # see AXON Dose monitoring paper doi:10.1017/S1551929522000840 + # this is the nominal dose rate e-/(angstrom^2*s) doc: | Beam current as measured relevant for the illumination of the specimen. - Users should specify further details like how the beam current was measured - using the beam_current_description field. - beam_current_description: + Users should specify further details like how the beam current + was measured using the beam_current_description field. + unit: NX_CURRENT + # replace with a dedicated base class to describe the dose rate, accumulated dose, dose rate history + # based on the AXON Dose monitoring suggestions, for this one could also have an NXdose_monitoring base class + # alternatively as that dose monitoring instrument as it is also described in the paper + # is a modified Faraday cup sensor one could also wrap that detector in this base dose monitoring base class + beam_current_description(NX_CHAR): doc: | Specify further details how the beam current was measured or estimated. @@ -51,89 +57,3 @@ NXoptical_system_em(NXobject): # adding of the image_mode or field mode # imageMode: enum: [normal_image, sad, eds, nbd, cbed] # fieldMode: enum: [dark_field, bright_field] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# c81cab49c10f4d26c4c1c8834c33cc1fbd7e6d4cce5ff838cd22e482d2114a6b -# -# -# -# -# -# A container for qualifying an electron optical system. -# -# -# -# -# Citing the JEOL TEM glossary this is *an effective distance from a specimen -# to a plane where an observed diffraction pattern is formed*. -# -# -# -# -# The factor of enlargement of the apparent size, not physical size, of an object. -# -# -# -# -# The defocus aberration constant oftentimes taken as the C_1_0 which -# is described in more details in NXaberration. -# -# -# -# -# Citing the JEOL TEM glosssary this is the value *when a cone shaped, -# convergent electron beam illuminates a specimen, the semi-angle of the cone -# is termed convergence angle.* -# -# -# -# -# The extent of the observable parts of the specimen given the current -# magnification and other settings of the instrument. -# -# -# -# -# Citing `Globalsino <https://www.globalsino.com/EM/page4586.html>`_ this is -# *a distance between the specimen and the lower pole piece in SEM system*. -# -# -# -# -# Beam current as measured relevant for the illumination of the specimen. -# Users should specify further details like how the beam current was measured -# using the beam_current_description field. -# -# -# -# -# Specify further details how the beam current was measured or estimated. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXorientation_set.yaml b/contributed_definitions/nyaml/NXorientation_set.yaml deleted file mode 100644 index 1973be4684..0000000000 --- a/contributed_definitions/nyaml/NXorientation_set.yaml +++ /dev/null @@ -1,228 +0,0 @@ -category: base -doc: | - Details about individual orientations of a set of objects. - - For a more detailed insight into the discussion of parameterizing - orientations in materials science see: - - * https://doi.org/10.1016/j.matchar.2016.04.008 - * https://doi.org/10.1088/0965-0393/23/8/083501 - * https://doi.org/10.1007/978-3-662-09156-2 group-theory of rotations - * https://doi.org/10.1016/C2013-0-11769-2 the classical book of H.-J. Bunge - -# This class stores a set of specifically parameterized NXtransformations which describe -# how each object is oriented/rotated with respect to a reference coordinate system. -# we should offer here support for d==2, d==3 -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the reference space/coordinate system. - c: | - The cardinality of the set, i.e. the number of orientations. - n_p: | - Number of parameters for the chosen parameterization. -type: group -NXorientation_set(NXobject): - - # depending on the dimensionality n_p is correlated but not necessarily, e.g. for d==3 one can store quaternions (n_p==4) or Bunge-Euler angles (n_p==3) - # clearly one could think about a single best approach that everybody should use, and indeed quaternions could be a candidate but this conflicts with the - # expectations understanding and in fact habit by very many materials engineers who know and report their values in Euler angles so at least one would need to - # have a system in place which converts... - (NXtransformations): - doc: | - Reference to or definition of a coordinate system with - which the definitions are interpretable. - parameterization: - enumeration: [bunge-euler (ZXZ), quaternion] - - # how to take into account the reduction to two-d? just list these cases XY, XZ, ... also in the enumeration? - # an instance of an NXorientation_set is useful as attribute (meta)data to a set of microstructural objects e.g. crystals, grains when the base class is stored as a sub-ordinate of the grain_set - # one may argue we expect that for each grain there is an orientation value, in this case the indexing is implicit and this is often used in computer simulations - # without making a specific statement that e.g. the 0-th value of the array gives the volume of the 0-th grain but that 0-th grain might not necessarily be named as grain 0 but e.g. grain 23 - # because many computer simulations deal with ensemble where the number of objects changes over time, e.g. molecular dynamics simulation treat always the same set of atoms but post-processing - # of the data may reveal these atoms are grouped/labelled as different microstructural features (grains, dislocations, vacancies) and then the names/identifiers of the objects may change over time - # therefore the idea to specify if we use implicit or explicit indexing and listing of the indices because I know of colleagues where even that went havoc! - objects: - doc: | - A link or reference to the objects whose identifier are referred to in - identifier to resolve which row tuple is the orientation of each object - by reading orientations. - identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer which specifies which orientation (row of array orientation) matches - to which object.e first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. - identifier(NX_INT): - unit: NX_UNITLESS - doc: | - Integer used to distinguish how a row in orientation describes a specific - object with an explicit identifier that can be queried via inspecting the - list of available objects in objects. - - The rational behind having such a more complicated pattern is that not - all objects referred when following the link in objects may still exists - or are still tracked when the orientation set was characterized. - - This design enables to also use NXorientation_set in situations where - the orientation of objects change as a function in time. - dimensions: - rank: 1 - dim: [[1, c]] - orientation(NX_NUMBER): - unit: NX_ANY - doc: | - Parameterized orientations. - dimensions: - rank: 2 - dim: [[1, c], [2, n_p]] - - # e.g. in this way one could easily, efficiently, store and map familiar habits of microscopists - # to store e.g. orientations of measurement points or of grains via a (c := Ngrains, n_p := 3) - # matrix of Bunge-Euler angles, or of (c := Ngrains, n_p := 4) matrix of quaternions. - - # the benefit of such a representation is that with a known NXorientation_set base class one can implement a common parameterization transformation library (of which several already exist) in the microstructure modelling communities so that a program can read the information in the (NXorientation_set) instance and automatically transform/compute between different parameterizations. Super relevant for interoperability e.g. in SEM/EBSD, where this was a long standing issue and right now the most frequently accepted consensus is to report either Bunge-Euler angles or quaternions and then use existent transformation libraries (as implemented by e.g. Marc de Graeff for SEM/EBSD and used by many but not yet the majority of people in the computational materials modelling community within crystal plasticity, crystal growth modeling, DREAM.3D) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 7a4adc6ee268ebf58286cf4baf9b25c5b8a808a01404292c31390f4f3f0a0ad0 -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality of the reference space/coordinate system. -# -# -# -# -# The cardinality of the set, i.e. the number of orientations. -# -# -# -# -# Number of parameters for the chosen parameterization. -# -# -# -# -# Details about individual orientations of a set of objects. -# -# For a more detailed insight into the discussion of parameterizing -# orientations in materials science see: -# -# * https://doi.org/10.1016/j.matchar.2016.04.008 -# * https://doi.org/10.1088/0965-0393/23/8/083501 -# * https://doi.org/10.1007/978-3-662-09156-2 group-theory of rotations -# * https://doi.org/10.1016/C2013-0-11769-2 the classical book of H.-J. Bunge -# -# -# -# -# Reference to or definition of a coordinate system with -# which the definitions are interpretable. -# -# -# -# -# -# -# -# -# -# -# -# A link or reference to the objects whose identifier are referred to in -# identifier to resolve which row tuple is the orientation of each object -# by reading orientations. -# -# -# -# -# Integer which specifies which orientation (row of array orientation) matches -# to which object.e first index to be used for distinguishing -# hexahedra. Identifiers are defined either implicitly -# or explicitly. For implicit indexing the identifiers are defined on the -# interval [identifier_offset, identifier_offset+c-1]. -# For explicit indexing the identifier array has to be defined. -# -# The identifier_offset field can for example be used to communicate if the -# identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) -# or from 0 (referred to as C-, Python-style index notation) respectively. -# -# -# -# -# Integer used to distinguish how a row in orientation describes a specific -# object with an explicit identifier that can be queried via inspecting the -# list of available objects in objects. -# -# The rational behind having such a more complicated pattern is that not -# all objects referred when following the link in objects may still exists -# or are still tracked when the orientation set was characterized. -# -# This design enables to also use NXorientation_set in situations where -# the orientation of objects change as a function in time. -# -# -# -# -# -# -# -# Parameterized orientations. -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXpump.yaml b/contributed_definitions/nyaml/NXpump.yaml index 95a28d0ddc..a5a803a64d 100644 --- a/contributed_definitions/nyaml/NXpump.yaml +++ b/contributed_definitions/nyaml/NXpump.yaml @@ -1,10 +1,10 @@ category: base doc: | - Device to reduce an atmosphere to a controlled remaining pressure level. + Device to reduce an atmosphere (real or simulated) to a controlled pressure. type: group NXpump(NXobject): (NXfabrication): - design: + design(NX_CHAR): doc: | Principle type of the pump. enumeration: [membrane, rotary_vane, roots, turbo_molecular] @@ -12,49 +12,3 @@ NXpump(NXobject): # NEW ISSUE: take community input and work further to store what is relevant to report about pumps # NEW ISSUE: see e.g. https://www.youtube.com/watch?v=Nsr_AdTiIIA for a discussion about # NEW ISSUE: the role, pros and cons of pump used for atom probe microscopy - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4a8252499c1361c758a51abb01fb92bead035ff00ce3c67966c7eb63ea4837df -# -# -# -# -# -# Device to reduce an atmosphere to a controlled remaining pressure level. -# -# -# -# -# Principle type of the pump. -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml new file mode 100644 index 0000000000..a8ba2426ad --- /dev/null +++ b/contributed_definitions/nyaml/NXroi.yaml @@ -0,0 +1,9 @@ +category: base +doc: | + Base class to describe a region-of-interest analyzed. +type: group +NXroi(NXobject): + (NXprocess): + doc: | + Details about processing steps. + sequence_index(NX_INT): diff --git a/contributed_definitions/nyaml/NXrotation_set.yaml b/contributed_definitions/nyaml/NXrotation_set.yaml index 2106c935ab..a83f889344 100644 --- a/contributed_definitions/nyaml/NXrotation_set.yaml +++ b/contributed_definitions/nyaml/NXrotation_set.yaml @@ -10,452 +10,168 @@ doc: | * `D. Rowenhorst et al. `_ * `A. Morawiec `_ - Once orientations are defined one can continue to characterize the - misorientation and specifically the disorientation which describes the - rotation that is required to register the lattices of two oriented objects + Once orientations are defined, one can continue to characterize the + misorientation and specifically the disorientation. The misorientation describes + the rotation that is required to register the lattices of two oriented objects (like crystal lattice) into a crystallographic equivalent orientation: * `R. Bonnet `_ - - Based on the idea of this NXorientation_set one could equally formulate - an NXdisorientation_set. # This class stores a set of specifically parameterized NXtransformations which describe # how each object is oriented/rotated with respect to a reference coordinate system. # we should offer here support for d==2, d==3 +# several well accepted parameterizations for rotations exists in Materials Science +# thus not using NXtransformations, different Materials Science groups follow +# different conventions not every reporting of rotations is consistent and correct +# having a base class like the one proposed here offers a suggestion to start +# discussing at all about how to convert between groups who report using +# different conventions symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. c: | The cardinality of the set, i.e. the number of value tuples. + n_phases: | + How many phases with usually different crystal and symmetry are distinguished. type: group NXrotation_set(NXobject): - depends_on: + \@depends_on(NX_CHAR): doc: | - Reference to an instance of NXem_conventions which contextualizes + Reference to an instance of :ref:`NXem_conventions` which contextualizes how the here reported parameterized quantities can be interpreted. - # 2D rotations are a special type of 3D rotations and thus treated in 3D # just how to rotate the object into the reference frame defined by depends_on - crystal_symmetry: + crystal_symmetry(NX_CHAR): doc: | Point group which defines the symmetry of the crystal. - This has to be at least a single string. + + This has to be at least a single string. If crystal_symmetry is not + provided point group 1 is assumed. + In the case that misorientation or disorientation fields are used and the two crystal sets resolve for phases with a different crystal symmetry, this field has to encode two string. In this case the first string is for phase A the second one for phase B. An example of this most complex case is the description of the disorientation between crystals adjoining a hetero-phase boundary. - - # how to encode the above (2,) string array or single string constraint - sample_symmetry: + dim: (n_phases,) + sample_symmetry(NX_CHAR): doc: | Point group which defines an assumed symmetry imprinted upon processing the material/sample which could give rise to or may justify to use a simplified description of rotations, orientations, misorientations, - and disorientations via numerical procedures known as symmetrization. + and disorientations via numerical procedures that are known as + symmetrization. + + If sample_symmetry is not provided point group 1 is assumed. The traditionally used symmetrization operations within the texture community in Materials Science, though, are thanks to methodology and software improvements no longer strictly needed. Therefore, users are encouraged to set the sample_symmetry to 1 (triclinic) and thus assume - there is no implied additional processing symmetry imprinted. + there is no justification to assume the imprinting of additional + symmetry because of the processing. In practice one often faces situations where indeed these assumed - symmetries are anyway not fully observed and thus an accepting of + symmetries are anyway not fully observed, and thus an accepting of eventual inaccuracies just for the sake of reporting a simplified - symmetrized description can be avoided. - rotation_quaternion(NX_FLOAT): - unit: NX_DIMENSIONLESS + symmetrized description should be avoided. + dim: (n_phases,) + rotation_quaternion(NX_NUMBER): # H \in SO3 doc: | - The set of rotations expressed in quaternion representation. The assumed - crystal and sample symmetry point group is 1, triclinic. Rotations which - should be interpreted as antipodal are not marked as such. - dimensions: - rank: 2 - dim: [[1, c], [2, 4]] - rotation_euler(NX_FLOAT): - unit: NX_ANGLE + The set of rotations expressed in quaternion parameterization considering + crystal_symmetry and sample_symmetry. Rotations which should be + interpreted as antipodal are not marked as such. + unit: NX_DIMENSIONLESS + dim: (c, 4) + rotation_euler(NX_NUMBER): doc: | - The set of rotations expressed in Euler angle representation following - the same applied symmetries as explained for rotation_quaternion. - To interpret Euler angles correctly it is necessary to inspect the + The set of rotations expressed in Euler angle parameterization considering + the same applied symmetries as detailed for the field rotation_quaternion. + To interpret Euler angles correctly, it is necessary to inspect the conventions behind depends_on to resolve which of the many Euler-angle conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] - - # rotation_rodrigues(NX_FLOAT): - # rotation_homochoric(NX_FLOAT): - # rotation_axis_angle(NX_FLOAT): - + unit: NX_ANGLE + dim: (c, 3) + # rotation_rodrigues(NX_NUMBER): + # rotation_homochoric(NX_NUMBER): + # rotation_axis_angle(NX_NUMBER): + # orientation how to rotate the crystal into sample and vice versa obeying crystal and sample symmetry is_antipodal(NX_BOOLEAN): doc: | - True for all those values which are considered antipodal, - false for those which are not considered antipodal. - dimensions: - rank: 1 - dim: [[1, c]] - orientation_quaternion(NX_FLOAT): - unit: NX_DIMENSIONLESS + True for all those value tuples which have assumed antipodal symmetry. + False for all others. + dim: (c,) + orientation_quaternion(NX_NUMBER): doc: | - The set of orientations expressed in quaternion representation and + The set of orientations expressed in quaternion parameterization and obeying symmetry for equivalent cases as detailed in crystal_symmetry and sample_symmetry. The supplementary field is_antipodal can be used - to mark orientations which are antipodal. - dimensions: - rank: 2 - dim: [[1, c], [2, 4]] - orientation_euler(NX_FLOAT): + to mark orientations with the antipodal property. + unit: NX_DIMENSIONLESS + dim: (c, 4) + orientation_euler(NX_NUMBER): unit: NX_ANGLE doc: | - The set of orientations expressed in Euler angle representation following + The set of orientations expressed in Euler angle parameterization following the same assumptions like for orientation_quaternion. - To interpret Euler angles correctly it is necessary to inspect the + To interpret Euler angles correctly, it is necessary to inspect the conventions behind depends_on to resolve which of the many Euler-angle conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] - orientation_busing_levy(NX_FLOAT): - unit: NX_ANGLE - doc: | - This will follow the Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - dimensions: - rank: 2 - dim: [[1, 3], [2, 3]] - ub_matrix_busing_levy(NX_FLOAT): - doc: | - UB matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is - the multiplication of the orientation_matrix, given above, - with the :math:`B` matrix which - can be derived from the lattice constants. - dimensions: - rank: 2 - dim: [[1, 3], [2, 3]] - - # orientation_rodrigues(NX_FLOAT): - # orientation_homochoric(NX_FLOAT): - # orientation_axis_angle(NX_FLOAT): - - # misorientation between two orientations, ignoring if the angular argument - # is smallest. - misorientation_quaternion(NX_FLOAT): - unit: NX_DIMENSIONLESS + dim: (c, 3) + # orientation_rodrigues(NX_NUMBER): + # orientation_homochoric(NX_NUMBER): + # orientation_axis_angle(NX_NUMBER): + + # misorientation between two orientations + # not the disorientation because for misorientation we ignore + # if the angular argument may not have the absolute smallest amount, i.e. + # misorientation is not necessarily in the fundamental zone + misorientation_quaternion(NX_NUMBER): doc: | - The set of misorientations expressed in quaternion representation and + The set of misorientations expressed in quaternion parameterization obeying symmetry operations for equivalent misorientations as defined by crystal_symmetry and sample_symmetry. - dimensions: - rank: 2 - dim: [[1, c], [2, 4]] - misorientation_angle(NX_FLOAT): - unit: NX_ANGLE + unit: NX_DIMENSIONLESS + dim: (c, 4) + misorientation_angle(NX_NUMBER): doc: | Misorientation angular argument (eventually signed) following the same symmetry assumptions as expressed for the field misorientation_quaternion. - dimensions: - rank: 1 - dim: [[1, c]] - misorientation_axis(NX_FLOAT): + unit: NX_ANGLE + dim: (c,) + misorientation_axis(NX_NUMBER): unit: NX_DIMENSIONLESS doc: | Misorientation axis (normalized) and signed following the same symmetry assumptions as expressed for the field misorientation_angle. - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] - + dim: (c, 3) + # disorientation, misorientation with smallest angular argument inside # fundamental zone of SO3 for given crystal and sample symmetry - disorientation_quaternion(NX_FLOAT): - unit: NX_DIMENSIONLESS + disorientation_quaternion(NX_NUMBER): doc: | - The set of disorientation expressed in quaternion representation and + The set of disorientation expressed in quaternion parameterization obeying symmetry operations for equivalent misorientations as defined by crystal_symmetry and sample_symmetry. - disorientation_angle(NX_FLOAT): - unit: NX_ANGLE + unit: NX_DIMENSIONLESS + dim: (c, 4) + disorientation_angle(NX_NUMBER): doc: | Disorientation angular argument (should not be signed, see `D. Rowenhorst et al. `_) following the same symmetry assumptions as expressed for the field disorientation_quaternion. - dimensions: - rank: 1 - dim: [[1, c]] - disorientation_axis(NX_FLOAT): - unit: NX_DIMENSIONLESS + unit: NX_ANGLE + dim: (c,) + disorientation_axis(NX_NUMBER): doc: | Disorientation axis (normalized) following the same symmetry assumptions - as expressed for the field disorientation_quaternion. - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] - + as expressed for the field disorientation_angle. + unit: NX_DIMENSIONLESS + dim: (c, 3) # e.g. in this way one could easily, efficiently, store and map familiar habits of microscopists # to store e.g. orientations of measurement points or of grains via a (c := Ngrains, n_p := 3) # matrix of Bunge-Euler angles, or of (c := Ngrains, n_p := 4) matrix of quaternions. - # the benefit of such a representation is that with a known NXorientation_set base class one can implement a common parameterization transformation library (of which several already exist) in the microstructure modelling communities so that a program can read the information in the (NXorientation_set) instance and automatically transform/compute between different parameterizations. Super relevant for interoperability e.g. in SEM/EBSD, where this was a long standing issue and right now the most frequently accepted consensus is to report either Bunge-Euler angles or quaternions and then use existent transformation libraries (as implemented by e.g. Marc de Graeff for SEM/EBSD and used by many but not yet the majority of people in the computational materials modelling community within crystal plasticity, crystal growth modeling, DREAM.3D) - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 39983e83f102efd5c6004455b450a87d7fde97e4c7a2ed00d9b68eae8b0a92d6 -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The cardinality of the set, i.e. the number of value tuples. -# -# -# -# -# Base class to detail a set of rotations, orientations, and disorientations. -# -# For getting a more detailed insight into the discussion of the -# parameterized description of orientations in materials science see: -# -# * `H.-J. Bunge <https://doi.org/10.1016/C2013-0-11769-2>`_ -# * `T. B. Britton et al. <https://doi.org/10.1016/j.matchar.2016.04.008>`_ -# * `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_ -# * `A. Morawiec <https://doi.org/10.1007/978-3-662-09156-2>`_ -# -# Once orientations are defined one can continue to characterize the -# misorientation and specifically the disorientation which describes the -# rotation that is required to register the lattices of two oriented objects -# (like crystal lattice) into a crystallographic equivalent orientation: -# -# * `R. Bonnet <https://doi.org/10.1107/S0567739480000186>`_ -# -# Based on the idea of this NXorientation_set one could equally formulate -# an NXdisorientation_set. -# -# -# -# Reference to an instance of NXem_conventions which contextualizes -# how the here reported parameterized quantities can be interpreted. -# -# -# -# -# -# Point group which defines the symmetry of the crystal. -# This has to be at least a single string. -# In the case that misorientation or disorientation fields are used -# and the two crystal sets resolve for phases with a different -# crystal symmetry, this field has to encode two string. -# In this case the first string is for phase A the second one for phase B. -# An example of this most complex case is the description of the -# disorientation between crystals adjoining a hetero-phase boundary. -# -# -# -# -# -# Point group which defines an assumed symmetry imprinted upon processing -# the material/sample which could give rise to or may justify to use a -# simplified description of rotations, orientations, misorientations, -# and disorientations via numerical procedures known as symmetrization. -# -# The traditionally used symmetrization operations within the texture -# community in Materials Science, though, are thanks to methodology and -# software improvements no longer strictly needed. Therefore, users are -# encouraged to set the sample_symmetry to 1 (triclinic) and thus assume -# there is no implied additional processing symmetry imprinted. -# -# In practice one often faces situations where indeed these assumed -# symmetries are anyway not fully observed and thus an accepting of -# eventual inaccuracies just for the sake of reporting a simplified -# symmetrized description can be avoided. -# -# -# -# -# The set of rotations expressed in quaternion representation. The assumed -# crystal and sample symmetry point group is 1, triclinic. Rotations which -# should be interpreted as antipodal are not marked as such. -# -# -# -# -# -# -# -# -# The set of rotations expressed in Euler angle representation following -# the same applied symmetries as explained for rotation_quaternion. -# To interpret Euler angles correctly it is necessary to inspect the -# conventions behind depends_on to resolve which of the many Euler-angle -# conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. -# -# -# -# -# -# -# -# -# -# -# True for all those values which are considered antipodal, -# false for those which are not considered antipodal. -# -# -# -# -# -# -# -# The set of orientations expressed in quaternion representation and -# obeying symmetry for equivalent cases as detailed in crystal_symmetry -# and sample_symmetry. The supplementary field is_antipodal can be used -# to mark orientations which are antipodal. -# -# -# -# -# -# -# -# -# The set of orientations expressed in Euler angle representation following -# the same assumptions like for orientation_quaternion. -# To interpret Euler angles correctly it is necessary to inspect the -# conventions behind depends_on to resolve which of the many Euler-angle -# conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. -# -# -# -# -# -# -# -# -# This will follow the Busing-Levy convention: -# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 -# -# -# -# -# -# -# -# -# UB matrix of single crystal sample using Busing-Levy convention: -# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is -# the multiplication of the orientation_matrix, given above, -# with the :math:`B` matrix which -# can be derived from the lattice constants. -# -# -# -# -# -# -# -# -# -# -# The set of misorientations expressed in quaternion representation and -# obeying symmetry operations for equivalent misorientations -# as defined by crystal_symmetry and sample_symmetry. -# -# -# -# -# -# -# -# -# Misorientation angular argument (eventually signed) following the same -# symmetry assumptions as expressed for the field misorientation_quaternion. -# -# -# -# -# -# -# -# Misorientation axis (normalized) and signed following the same -# symmetry assumptions as expressed for the field misorientation_angle. -# -# -# -# -# -# -# -# -# -# The set of disorientation expressed in quaternion representation and -# obeying symmetry operations for equivalent misorientations -# as defined by crystal_symmetry and sample_symmetry. -# -# -# -# -# Disorientation angular argument (should not be signed, see -# `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_) -# following the same symmetry assumptions as expressed for the field -# disorientation_quaternion. -# -# -# -# -# -# -# -# Disorientation axis (normalized) following the same symmetry assumptions -# as expressed for the field disorientation_quaternion. -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXscanbox_em.yaml b/contributed_definitions/nyaml/NXscanbox_em.yaml index 000477d7cc..7fa3588434 100644 --- a/contributed_definitions/nyaml/NXscanbox_em.yaml +++ b/contributed_definitions/nyaml/NXscanbox_em.yaml @@ -1,83 +1,50 @@ category: base doc: | - Scan box and coils which deflect an electron beam in a controlled manner. + Scan box and coils which deflect a beam of charged particles in a controlled manner. - In electron microscopy, the scan box is instructed by the microscope - control software. This component directs the probe to controlled - locations according to a scan scheme and plan. + The scan box is instructed by an instance of :ref:`NXprogram`, some control software, + which is not necessarily the same program as for all components of a microscope. + + The scanbox directs the probe of charged particles (electrons, ions) + to controlled locations according to a scan scheme and plan. + + To achieve this task, the scanbox typically contains deflection coils, + which should be modelled as instances of :ref:`NXdeflector`. type: group -NXscanbox_em(NXobject): - calibration_style: +NXscanbox_em(NXcomponent_em): + calibration_style(NX_CHAR): + doc: | + TODO discuss with the electron microscopists. center(NX_NUMBER): + doc: | + TODO discuss with the electron microscopists. unit: NX_ANY - - # \@units: - # enumeration: nm - flyback_time(NX_FLOAT): + flyback_time(NX_NUMBER): + doc: | + TODO discuss with the electron microscopists. unit: NX_TIME - line_time(NX_FLOAT): + line_time(NX_NUMBER): + doc: | + TODO discuss with the electron microscopists. unit: NX_TIME - # pixel_dwell_time? - pixel_time(NX_FLOAT): + pixel_time(NX_NUMBER): + doc: | + TODO discuss with the electron microscopists. unit: NX_TIME - requested_pixel_time(NX_FLOAT): + requested_pixel_time(NX_NUMBER): + doc: | + TODO discuss with the electron microscopists. unit: NX_TIME - rotation(NX_FLOAT): + rotation(NX_NUMBER): + doc: | + TODO discuss with the electron microscopists. unit: NX_ANGLE ac_line_sync(NX_BOOLEAN): - (NXfabrication): - + doc: | + TODO discuss with the electron microscopists. + (NXdeflector): + # (NXcg_point_set): # NEW ISSUE: build on work of EMglossary with HMC and use duty cycle instead # NEW ISSUE: make use of and define duty cycle - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# b0cf038d9e5a98cef1fc709b5ba7eeb0ab97cad439c564353ea7ec522b414727 -# -# -# -# -# -# Scan box and coils which deflect an electron beam in a controlled manner. -# -# In electron microscopy, the scan box is instructed by the microscope -# control software. This component directs the probe to controlled -# locations according to a scan scheme and plan. -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXspectrum_set.yaml b/contributed_definitions/nyaml/NXspectrum_set.yaml index 3b70f6c2c6..5cbc597b61 100644 --- a/contributed_definitions/nyaml/NXspectrum_set.yaml +++ b/contributed_definitions/nyaml/NXspectrum_set.yaml @@ -1,9 +1,9 @@ category: base doc: | - Container for reporting a set of spectra. + Base class container for reporting a set of spectra. symbols: - - # n_p: Number of scan points + n_p: | + Number of scan points. n_y: | Number of pixel in the slow direction. n_x: | @@ -12,67 +12,69 @@ symbols: Number of energy bins. type: group NXspectrum_set(NXobject): + # for EELS we likely need a complex-valued NXspectrum_c_set to this + # NXspectrum_set base class here which should then be splitted into an + # NXspectrum_set to reduce redundant fields and specialized NXspectrum_r/c_set (NXprocess): doc: | Details how spectra were processed from the detector readings. - source: + source(NXserialized): doc: | Resolvable data artifact (e.g. filename) from which the all values in - the NXdata instances in this NXspectrum_set were loaded during parsing. - \@version: - doc: | - An at least as strong as SHA256 hashvalue of the data artifact which - source represents digitally to support provenance tracking. - mode: + the :ref:`NXdata` instances in this :ref:`NXspectrum_set` were + loaded during parsing. + mode(NX_CHAR): doc: | Imaging (data collection) mode of the instrument during acquisition - of the data in this NXspectrum_set instance. - detector_identifier: + of the data in this :ref:`NXspectrum_set` instance. + detector_identifier(NX_CHAR): doc: | - Link or name of an NXdetector instance with which the data were collected. + Link or name of an :ref:`NXdetector` instance with which the data were collected. (NXprogram): - - ##MK::feel free to contact us when you would like to include more complicated scan pattern than rectangular ones. + ##MK::feel free to contact us when you would like to include + # lik omega/q mapping more complicated scan pattern than rectangular ones. stack(NXdata): doc: | Collected spectra for all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - data_counts(NX_NUMBER): + + This representation supports rectangular scan pattern with equidistant + energy bins. For randomly or dissimilarly spaced scan points + use collection instead. + intensity(NX_NUMBER): + doc: | + Counts unit: NX_UNITLESS - dimensions: - rank: 3 - dim: [[1, n_y], [2, n_x], [3, n_energy]] - \@long_name: + dim: (n_y, n_x, n_energy) + \@long_name(NX_CHAR): doc: | Counts - # \@signal: counts # \@axes: [ypos, xpos, energy] # \@ypos_indices: 0 # \@xpos_indices: 1 # \@energy_indices: 2 axis_y(NX_NUMBER): + doc: | + Coordinate along y direction. unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: + dim: (n_y,) + \@long_name(NX_CHAR): doc: | - Coordinate along y direction + Pixel coordinate along y direction axis_x(NX_NUMBER): + doc: | + Coordinate along x direction. unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: + dim: (n_x,) + \@long_name(NX_CHAR): doc: | - Coordinate along x direction + Pixel coordinate along x direction axis_energy(NX_NUMBER): + doc: | + Energy axis unit: NX_ENERGY - dimensions: - rank: 1 - dim: [[1, n_energy]] - \@long_name: + dim: (n_energy,) + \@long_name(NX_CHAR): doc: | Energy @@ -83,189 +85,59 @@ NXspectrum_set(NXobject): summary(NXdata): doc: | Accumulated counts over all pixels of the region-of-interest. - This representation supports rectangular scan pattern. - data_counts(NX_NUMBER): + This representation supports a rectangular scan pattern with + equidistant energy bins. + intensity(NX_NUMBER): + doc: | + Accumulated counts unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_energy]] - \@long_name: + dim: (n_energy,) + \@long_name(NX_CHAR): doc: | Counts - # \@signal: counts # \@axes: [energy] # \@energy_indices: 0 axis_energy(NX_NUMBER): + doc: | + Energy axis unit: NX_ENERGY - dimensions: - rank: 1 - dim: [[1, n_energy]] - \@long_name: + dim: (n_energy,) + \@long_name(NX_CHAR): doc: | Energy -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d3297ed4c9fb7b26cc057812a358e3f143c762535d90c5d5adced47ed949e703 -# -# -# -# -# -# -# -# -# Number of pixel in the slow direction. -# -# -# -# -# Number of pixel in the fast direction. -# -# -# -# -# Number of energy bins. -# -# -# -# -# Container for reporting a set of spectra. -# -# -# -# Details how spectra were processed from the detector readings. -# -# -# -# Resolvable data artifact (e.g. filename) from which the all values in -# the NXdata instances in this NXspectrum_set were loaded during parsing. -# -# -# -# An at least as strong as SHA256 hashvalue of the data artifact which -# source represents digitally to support provenance tracking. -# -# -# -# -# -# Imaging (data collection) mode of the instrument during acquisition -# of the data in this NXspectrum_set instance. -# -# -# -# -# Link or name of an NXdetector instance with which the data were collected. -# -# -# -# -# -# -# -# Collected spectra for all pixels of a rectangular region-of-interest. -# This representation supports rectangular scan pattern. -# -# -# -# -# -# -# -# -# -# Counts -# -# -# -# -# -# -# -# -# -# -# Coordinate along y direction -# -# -# -# -# -# -# -# -# -# Coordinate along x direction -# -# -# -# -# -# -# -# -# -# Energy -# -# -# -# -# -# -# -# Accumulated counts over all pixels of the region-of-interest. -# This representation supports rectangular scan pattern. -# -# -# -# -# -# -# -# Counts -# -# -# -# -# -# -# -# -# -# -# Energy -# -# -# -# -# + collection(NXdata): + doc: | + Collected spectra for each scan point. + + This representation supports equidistant energy bins. + For rectangular sampling use stack and summary instead. + intensity(NX_NUMBER): + doc: | + Counts + unit: NX_UNITLESS + dim: (n_p, n_energy) + \@long_name(NX_CHAR): + doc: | + Counts + # \@signal: counts + # \@axes: [scan_point_id, energy] + # \@scan_point_indices: 1 + # \@energy_indices: 0 + axis_scan_point_id(NX_INT): + doc: | + Scan point identifier + unit: NX_UNITLESS + dim: (n_p,) + \@long_name(NX_CHAR): + doc: | + Scan point identifier + axis_energy(NX_NUMBER): + doc: | + Energy axis + unit: NX_ENERGY + dim: (n_energy,) + \@long_name(NX_CHAR): + doc: | + Energy diff --git a/contributed_definitions/nyaml/NXspectrum_set_em_eels.yaml b/contributed_definitions/nyaml/NXspectrum_set_em_eels.yaml deleted file mode 100644 index 431c1dacd4..0000000000 --- a/contributed_definitions/nyaml/NXspectrum_set_em_eels.yaml +++ /dev/null @@ -1,315 +0,0 @@ -category: base -doc: | - Container for reporting a set of electron energy loss (EELS) spectra. - - Virtually the most important case is that spectra are collected in - a scanning microscope (SEM or STEM) for a collection of points. - The majority of cases use simple d-dimensional regular scan pattern, - such as single point, line profiles, or (rectangular) surface mappings. - - The latter pattern is the most frequently used. - For now the base class provides for scans for which the settings, - binning, and energy resolution is the same for each scan point. -symbols: - - # n_p: Number of scan points - n_y: | - Number of pixel per EELS mapping in the slow direction. - n_x: | - Number of pixel per EELS mapping in the fast direction. - n_energy_loss: | - Number of electron energy loss bins. -type: group -NXspectrum_set_em_eels(NXobject): - (NXprocess): - doc: | - Details how EELS spectra were processed from the detector readings. - source: - doc: | - Typically the name of the input, (vendor) file from which all - the NXdata instances in this NXspectrum_set_em_eels were loaded during - parsing to represent them in e.g. databases. - \@version: - doc: | - An at least as strong as SHA256 hashvalue of the dataset/file - which represents the source digitally to support provenance tracking. - program: - doc: | - Commercial or otherwise given name to the program which was used - to process detector data into the EELS spectra stack and summary. - \@version: - doc: | - Program version plus build number, commit hash, or description - of an ever persistent resource where the source code of the program - and build instructions can be found so that the program - can be configured in such a manner that the result file - is ideally recreatable yielding the same results. - stack(NXdata): - doc: | - Collected EELS spectra for all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - data_counts(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Counts for one spectrum per each pixel. - dimensions: - rank: 3 - dim: [[1, n_y], [2, n_x], [3, n_energy_loss]] - \@long_name: - doc: | - EELS counts - - # \@signal: counts - # \@axes: [ypos, xpos, energy_loss] - # \@energy_loss_indices: 2 - # \@xpos_indices: 1 - # \@ypos_indices: 0 - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Pixel center of mass position y-coordinates. - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - doc: | - Coordinate along y direction. - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Pixel center of mass position x-coordinates. - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - doc: | - Coordinate along x direction. - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - doc: | - Pixel center of mass energy loss bins. - dimensions: - rank: 1 - dim: [[1, n_energy_loss]] - \@long_name: - doc: | - Coordinate along energy loss axis. - summary(NXdata): - doc: | - Accumulated EELS spectrum over all pixels of a rectangular - region-of-interest. This representation supports rectangular scan pattern. - data_counts(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Counts for specific energy losses. - dimensions: - rank: 1 - dim: [[1, n_energy_loss]] - \@long_name: - doc: | - Counts electrons with an energy loss within binned range. - - # \@signal: counts - # \@axes: [energy_loss] - # \@energy_loss_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - doc: | - Pixel center of mass energy loss bins. - dimensions: - rank: 1 - dim: [[1, n_energy_loss]] - \@long_name: - doc: | - Coordinate along energy loss axis. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d8d7b516bc82a0490225a0f879f17753b30a7c182c8d13b7a972a6533847b21f -# -# -# -# -# -# -# -# -# Number of pixel per EELS mapping in the slow direction. -# -# -# -# -# Number of pixel per EELS mapping in the fast direction. -# -# -# -# -# Number of electron energy loss bins. -# -# -# -# -# Container for reporting a set of electron energy loss (EELS) spectra. -# -# Virtually the most important case is that spectra are collected in -# a scanning microscope (SEM or STEM) for a collection of points. -# The majority of cases use simple d-dimensional regular scan pattern, -# such as single point, line profiles, or (rectangular) surface mappings. -# -# The latter pattern is the most frequently used. -# For now the base class provides for scans for which the settings, -# binning, and energy resolution is the same for each scan point. -# -# -# -# Details how EELS spectra were processed from the detector readings. -# -# -# -# Typically the name of the input, (vendor) file from which all -# the NXdata instances in this NXspectrum_set_em_eels were loaded during -# parsing to represent them in e.g. databases. -# -# -# -# An at least as strong as SHA256 hashvalue of the dataset/file -# which represents the source digitally to support provenance tracking. -# -# -# -# -# -# Commercial or otherwise given name to the program which was used -# to process detector data into the EELS spectra stack and summary. -# -# -# -# Program version plus build number, commit hash, or description -# of an ever persistent resource where the source code of the program -# and build instructions can be found so that the program -# can be configured in such a manner that the result file -# is ideally recreatable yielding the same results. -# -# -# -# -# -# -# Collected EELS spectra for all pixels of a rectangular region-of-interest. -# This representation supports rectangular scan pattern. -# -# -# -# Counts for one spectrum per each pixel. -# -# -# -# -# -# -# -# -# EELS counts -# -# -# -# -# -# -# Pixel center of mass position y-coordinates. -# -# -# -# -# -# -# Coordinate along y direction. -# -# -# -# -# -# Pixel center of mass position x-coordinates. -# -# -# -# -# -# -# Coordinate along x direction. -# -# -# -# -# -# Pixel center of mass energy loss bins. -# -# -# -# -# -# -# Coordinate along energy loss axis. -# -# -# -# -# -# -# Accumulated EELS spectrum over all pixels of a rectangular -# region-of-interest. This representation supports rectangular scan pattern. -# -# -# -# Counts for specific energy losses. -# -# -# -# -# -# -# Counts electrons with an energy loss within binned range. -# -# -# -# -# -# -# Pixel center of mass energy loss bins. -# -# -# -# -# -# -# Coordinate along energy loss axis. -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXspectrum_set_em_xray.yaml b/contributed_definitions/nyaml/NXspectrum_set_em_xray.yaml deleted file mode 100644 index 7183b1f975..0000000000 --- a/contributed_definitions/nyaml/NXspectrum_set_em_xray.yaml +++ /dev/null @@ -1,534 +0,0 @@ -category: base -doc: | - Container for reporting a set of energy-dispersive X-ray spectra. - - Virtually the most important case is that spectra are collected in - a scanning microscope (SEM or STEM) for a collection of points. - The majority of cases use simple d-dimensional regular scan pattern, - such as single point, line profiles, or (rectangular) surface mappings. - The latter pattern is the most frequently used. - - For now the base class provides for scans for which the settings, - binning, and energy resolution is the same for each scan point. - - `IUPAC instead of Siegbahn notation `_ - should be used. - -# NEW ISSUE: use computational geometry to offer arbitrary scan pattern -# NEW ISSUE: make the binning flexible per scan point -symbols: - - # n_p: Number of scan points - n_y: | - Number of pixel per X-ray mapping in the slow direction - n_x: | - Number of pixel per X-ray mapping in the fast direction - n_photon_energy: | - Number of X-ray photon energy (bins) - n_elements: | - Number of identified elements - n_peaks: | - Number of peaks -type: group -NXspectrum_set_em_xray(NXobject): - (NXprocess): - doc: | - Details how X-ray spectra were processed from the detector readings. - source: - doc: | - Typically the name of the input, (vendor) file from which all - the NXdata instances in this NXspectrum_set_em_xray were loaded during - parsing to represent them in e.g. databases. - \@version: - doc: | - An at least as strong as SHA256 hashvalue of the dataset/file - which represents the source digitally to support provenance tracking. - program: - doc: | - Commercial or otherwise given name to the program which was used - to process detector data into the X-ray spectra stack and summary. - \@version: - doc: | - Program version plus build number, commit hash, or description - of an ever persistent resource where the source code of the program - and build instructions can be found so that the program - can be configured in such a manner that the result file - is ideally recreatable yielding the same results. - - ##MK::for supporting arbitrary scan pattern we need a good example first - ##MK::feel free to contact us in this regard! - stack(NXdata): - doc: | - Collected X-ray spectra for all pixels of a rectangular region-of-interest. - This representation supports rectangular scan pattern. - data_counts(NX_NUMBER): - unit: NX_UNITLESS - dimensions: - rank: 3 - dim: [[1, n_y], [2, n_x], [3, n_photon_energy]] - \@long_name: - doc: | - X-ray photon counts - - # \@signal: counts - # \@axes: [ypos, xpos, photon_energy] - # \@ypos_indices: 0 - # \@xpos_indices: 1 - # \@photon_energy_indices: 2 - axis_y(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - doc: | - Coordinate along y direction. - axis_x(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - doc: | - Coordinate along x direction. - axis_photon_energy(NX_NUMBER): - unit: NX_ENERGY - dimensions: - rank: 1 - dim: [[1, n_photon_energy]] - \@long_name: - doc: | - Photon energy. - summary(NXdata): - doc: | - Accumulated X-ray spectrum over all pixels of a rectangular - region-of-interest. This representation supports rectangular scan pattern. - data_counts(NX_NUMBER): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_photon_energy]] - \@long_name: - doc: | - X-ray photon counts - - # \@signal: counts - # \@axes: [photon_energy] - # \@photon_energy_indices: 0 - axis_photon_energy(NX_NUMBER): - unit: NX_ENERGY - dimensions: - rank: 1 - dim: [[1, n_photon_energy]] - \@long_name: - doc: | - Photon energy - - # for post-processing of/with the above-defined data entries - indexing(NXprocess): - doc: | - Details about computational steps how peaks were indexed as elements. - program: - doc: | - Given name of the program that was used to perform this computation. - \@version: - doc: | - Program version plus build number, commit hash, or description of an - ever persistent resource where the source code of the program and - build instructions can be found so that the program can be configured - in such a manner that the result file is ideally recreatable yielding - the same results. - (NXpeak): - doc: | - Name and location of each X-ray line which was indexed as a known ion. - For each ion an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - (NXion): - iupac_line_names: - doc: | - IUPAC notation identifier of the line which the peak represents. - - This can be a list of IUPAC notations for (the seldom) case that - multiple lines are group with the same peak. - element_names: - doc: | - List of the names of identified elements. - dimensions: - rank: 1 - dim: [[1, n_elements]] - ELEMENTNAME(NXprocess): - doc: | - Individual element-specific EDX/EDS/EDXS/SXES mapping - - A composition map is an image whose intensities for each pixel are the - accumulated X-ray quanta *under the curve(s)* of a set of peaks. - program: - doc: | - Given name of the program that was used to perform this computation. - \@version: - doc: | - Program version plus build number, commit hash, or description of an - ever persistent resource where the source code of the program and - build instructions can be found so that the program can be configured - in such a manner that the result file is ideally recreatable yielding - the same results. - peaks: - doc: | - A list of strings of named instances of NXpeak from indexing - whose X-ray quanta where accumulated for each pixel. - dimensions: - rank: 1 - dim: [[1, n_peaks]] - name: - doc: | - Human-readable, given name to the image. - - # example how an element-specific pattern could be stored - summary(NXdata): - doc: | - Individual element-specific maps. Individual maps should - each be a group and be named according to element_names. - data_counts(NX_NUMBER): - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_y], [2, n_x]] - \@long_name: - doc: | - Accumulated photon counts for observed element. - - # \@signal: counts - # \@axes: [ypos, xpos] - # \@xpos_indices: 1 - # \@ypos_indices: 0 - axis_y(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - doc: | - Coordinate along y direction. - axis_x(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 1 - dim: [[1, n_x]] - \@long_name: - doc: | - Coordinate along x direction. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 6d33f28eb5adb076b4551f108d8825f9dde6549b8b705d56009b2968c89b9e13 -# -# -# -# -# -# -# -# -# -# Number of pixel per X-ray mapping in the slow direction -# -# -# -# -# Number of pixel per X-ray mapping in the fast direction -# -# -# -# -# Number of X-ray photon energy (bins) -# -# -# -# -# Number of identified elements -# -# -# -# -# Number of peaks -# -# -# -# -# Container for reporting a set of energy-dispersive X-ray spectra. -# -# Virtually the most important case is that spectra are collected in -# a scanning microscope (SEM or STEM) for a collection of points. -# The majority of cases use simple d-dimensional regular scan pattern, -# such as single point, line profiles, or (rectangular) surface mappings. -# The latter pattern is the most frequently used. -# -# For now the base class provides for scans for which the settings, -# binning, and energy resolution is the same for each scan point. -# -# `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ -# should be used. -# -# -# -# Details how X-ray spectra were processed from the detector readings. -# -# -# -# Typically the name of the input, (vendor) file from which all -# the NXdata instances in this NXspectrum_set_em_xray were loaded during -# parsing to represent them in e.g. databases. -# -# -# -# An at least as strong as SHA256 hashvalue of the dataset/file -# which represents the source digitally to support provenance tracking. -# -# -# -# -# -# Commercial or otherwise given name to the program which was used -# to process detector data into the X-ray spectra stack and summary. -# -# -# -# Program version plus build number, commit hash, or description -# of an ever persistent resource where the source code of the program -# and build instructions can be found so that the program -# can be configured in such a manner that the result file -# is ideally recreatable yielding the same results. -# -# -# -# -# -# -# -# Collected X-ray spectra for all pixels of a rectangular region-of-interest. -# This representation supports rectangular scan pattern. -# -# -# -# -# -# -# -# -# -# X-ray photon counts -# -# -# -# -# -# -# -# -# -# -# Coordinate along y direction. -# -# -# -# -# -# -# -# -# -# Coordinate along x direction. -# -# -# -# -# -# -# -# -# -# Photon energy. -# -# -# -# -# -# -# Accumulated X-ray spectrum over all pixels of a rectangular -# region-of-interest. This representation supports rectangular scan pattern. -# -# -# -# -# -# -# -# X-ray photon counts -# -# -# -# -# -# -# -# -# -# -# Photon energy -# -# -# -# -# -# -# -# Details about computational steps how peaks were indexed as elements. -# -# -# -# Given name of the program that was used to perform this computation. -# -# -# -# Program version plus build number, commit hash, or description of an -# ever persistent resource where the source code of the program and -# build instructions can be found so that the program can be configured -# in such a manner that the result file is ideally recreatable yielding -# the same results. -# -# -# -# -# -# Name and location of each X-ray line which was indexed as a known ion. -# For each ion an NXion instance should be created which specifies -# the origin of the signal. For each ion also the relevant IUPAC notation -# X-ray lines should be specified. -# -# -# -# -# IUPAC notation identifier of the line which the peak represents. -# -# This can be a list of IUPAC notations for (the seldom) case that -# multiple lines are group with the same peak. -# -# -# -# -# -# -# List of the names of identified elements. -# -# -# -# -# -# -# -# Individual element-specific EDX/EDS/EDXS/SXES mapping -# -# A composition map is an image whose intensities for each pixel are the -# accumulated X-ray quanta *under the curve(s)* of a set of peaks. -# -# -# -# Given name of the program that was used to perform this computation. -# -# -# -# Program version plus build number, commit hash, or description of an -# ever persistent resource where the source code of the program and -# build instructions can be found so that the program can be configured -# in such a manner that the result file is ideally recreatable yielding -# the same results. -# -# -# -# -# -# A list of strings of named instances of NXpeak from indexing -# whose X-ray quanta where accumulated for each pixel. -# -# -# -# -# -# -# -# Human-readable, given name to the image. -# -# -# -# -# -# Individual element-specific maps. Individual maps should -# each be a group and be named according to element_names. -# -# -# -# -# -# -# -# -# Accumulated photon counts for observed element. -# -# -# -# -# -# -# -# -# -# -# Coordinate along y direction. -# -# -# -# -# -# -# -# -# -# Coordinate along x direction. -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXstage_lab.yaml b/contributed_definitions/nyaml/NXstage_lab.yaml index 2584d06c90..a79ef91524 100644 --- a/contributed_definitions/nyaml/NXstage_lab.yaml +++ b/contributed_definitions/nyaml/NXstage_lab.yaml @@ -1,68 +1,72 @@ category: base doc: | - A stage lab can be used to hold, align, orient, and prepare a specimen. + Base class for a stage (lab) used to hold, orient, and prepare a specimen. - Modern stages are multi-functional devices. Many of which offer a controlled - environment around (a part) of the specimen. Stages enable experimentalists - to apply stimuli. A stage_lab is a multi-purpose/-functional tools which - can have multiple actuators, sensors, and other components. + Modern stages are multi-functional devices. Stages provide a controlled + environment around the specimen. Stages enable experimentalists to apply + controlled external stimuli on the specimen. A stage_lab is a multi-purpose + /-functional tool that is constructed from multiple actuators, sensors, + and other components. With such stages comes the need for storing various (meta)data - that are generated while manipulating the sample. + that are generated while working and modifying the sample. - Modern stages realize a hierarchy of components: For example the specimen - might be mounted on a multi-axial tilt rotation holder. This holder is - fixed in the support unit which connects the holder to the rest of the - microscope. + Modern stages realize a hierarchy of components. Two examples are given to help + clarify how :ref:`NXstage_lab` instances should be used: Take a specimen that is + mounted on a multi-axial tilt rotation holder. This holder is fixed in the + support unit which connects the holder to the rest of the instrument. + Evidently different components are all considerable as to represent instances + of stages. - In other examples, taken from atom probe microscopy, researchers may work - with wire samples which are clipped into a larger fixing unit for - convenience and enable for a more careful specimen handling. - This fixture unit is known in atom probe jargon as a stub. - Stubs in turn are positioned onto pucks. - Pucks are then loaded onto carousels. - A carousel is a carrier unit with which eventually entire sets of specimens - can be moved in between parts of the microscope. + In another example, taken from atom probe microscopy, researchers may work + with wire samples which are clipped into a larger fixing unit to enable + careful specimen handling. Alternatively, a microtip is a silicon post + upon which e.g. an atom probe specimen is mounted. + Multiple microtips are grouped into a microtip array to conveniently enable + loading of multiple specimens into the instrument with fewer operations. + That microtip array is fixed on a holder. Fixture units in atom probe are known + as stubs. Stubs in turn are positioned onto pucks. Pucks are then loaded onto + carousels. A carousel is a carrier unit with which eventually entire sets of + specimens can be moved in between parts of the microscope. All of these units + can be considered stage_lab instances. - An NXstage_lab instance reflects this hierarchical design. The stage is the - root of the hierarchy. A stage carries the holder. - In the case that it is not practical to distinguish these two layers, - the holder should be given preference. + The :ref:`NXstage_lab` base class reflects this hierarchy. To cover for an as flexible + design of complex stages as possible, users should nest multiple instances of + :ref:`NXstage_lab` according to their needs to reflect the differences between what + they consider as the holder and what they consider is the stage. + The alias field can be used to specify the community jargon if necessary. + + However, a much clearer approach to reflect the hierarchy of all :ref:`NXstage_lab` + instances is postfix each instance named stage_lab with integers starting + from 1 as the top level unit. + In the microtip example one could thus use stage_lab1 for the microtip, + stage_lab2 for the microtip array, stage_lab3 holder, etc. + The depends_on keyword should be used to additional clarify the hierarchy + especially when users decide to not follow the above-mentioned postfixing + notation or when is not obvious from the postfixes which stage_lab is at + which level of the stage_lab hierarchy. Some examples for stage_labs in applications: * A nanoparticle on a copper grid. The copper grid is the holder. - The grid itself is fixed to the stage. + The grid itself is fixed to a stage. * An atom probe specimen fixed in a stub. In this case the stub can be considered the holder, while the cryostat temperature control unit is a component of the stage. * Samples with arrays of specimens, like a microtip on a microtip array - is an example of a three-layer hierarchy commonly employed for + is an example of an at least three-layer hierarchy commonly employed for efficient sequential processing of atom probe experiments. * With one entry of an application definition only one microtip should be described. Therefore, the microtip is the specimen, the array is the holder and the remaining mounting unit that is attached to the cryo-controller is the stage. * For in-situ experiments with e.g. chips with read-out electronics - as actuators, the chips are again placed in a larger unit. + as actuators, the chips are again placed in a larger unit. A typical + example are in-situ experiments using e.g. the tools of `Protochips `_. * Other examples are (quasi) in-situ experiments where experimentalists anneal or deform the specimen via e.g. in-situ tensile testing machines which are mounted on the specimen holder. - To cover for an as flexible design of complex stages, users should nest - multiple instances of NXstage_lab objects according to their needs to reflect - the differences between what they consider as the holder and what - they consider is the stage. - - Instances should be named with integers starting from 1 as the top level unit. - In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder - (microtip array), stage_lab_3 for the microtip specimen, respectively. - The depends_on keyword should be used with relative or absolute naming inside - the file to specify how different stage_lab instances build a hierarchy - if this is not obvious from numbered identifiers like the stage_lab_1 to - stage_lab 3 example. The lower it is the number the higher it is the - rank in the hierarchy. - For specific details and inspiration about stages in electron microscopes: * `Holders with multiple axes `_ @@ -72,9 +76,11 @@ doc: | * `Further stages in transmission electron microscopy `_ (page 124ff) * `Specimens in atom probe `_ (page 47ff) * `Exemplar micro-manipulators `_ + + We are looking forward to suggestions from the scientists. type: group -NXstage_lab(NXobject): - design: +NXstage_lab(NXcomponent_em): + design(NX_CHAR): doc: | Principal design of the stage. @@ -83,44 +89,37 @@ NXstage_lab(NXobject): bulk_specimen, double_tilt, tilt_rotate, heating_chip, atmosphere_chip, electrical_biasing_chip, liquid_cell_chip - name: + alias(NX_CHAR): doc: | - Given name/alias for the components making the stage. - (NXfabrication): - description: + Free-text field to give a term how that a stage_lab at this level of the + stage_lab hierarchy is commonly referred to. Examples could be stub, + puck, carousel, microtip, clip, holder, etc. + tilt_1(NX_NUMBER): doc: | - Ideally, a (globally) unique persistent identifier, link, - or text to a resource which gives further details. - tilt_1(NX_FLOAT): + The interpretation of this tilt should be specialized + and thus detailed via the application definition. unit: NX_ANGLE + tilt_2(NX_NUMBER): doc: | - Should be defined by the application definition. - tilt_2(NX_FLOAT): + The interpretation of this tilt should be specialized + and thus detailed via the application definition. unit: NX_ANGLE + rotation(NX_NUMBER): doc: | - Should be defined by the application definition. - rotation(NX_FLOAT): + The interpretation of this tilt should be specialized + and thus detailed via the application definition. unit: NX_ANGLE + position(NX_NUMBER): doc: | - Should be defined by the application definition. - position(NX_FLOAT): + The interpretation of this tilt should be specialized + and thus detailed via the application definition. unit: NX_LENGTH - doc: | - Should be defined by the application definition. - dimensions: - rank: 1 - dim: [[1, 3]] - bias_voltage(NX_FLOAT): - unit: NX_VOLTAGE + dim: (3,) + bias_voltage(NX_NUMBER): doc: | Voltage applied to the stage to decelerate electrons. - + unit: NX_VOLTAGE # NEW ISSUE: rather the field if possible should be specified - (NXtransformations): - doc: | - The rotation, tilt and position of stage components can be specified - either via NXtransformations or via the tilt_1, tilt_2, rotation, - and position fields. (NXpositioner): # see for complicated positioning tools like an eucentric five-axis table stage in an SEM @@ -137,179 +136,3 @@ NXstage_lab(NXobject): # to define an own class NXspecimen_manipulator given this is nothing else than # miniature robot arm essential one could also think about creating an own NXrobotarm class, # below are two examples of such tools as they are used in FIB and SEMs - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 60517924e592d79ca277016453672f5211f31215284fc66cebd97852197ee39a -# -# -# -# -# -# A stage lab can be used to hold, align, orient, and prepare a specimen. -# -# Modern stages are multi-functional devices. Many of which offer a controlled -# environment around (a part) of the specimen. Stages enable experimentalists -# to apply stimuli. A stage_lab is a multi-purpose/-functional tools which -# can have multiple actuators, sensors, and other components. -# -# With such stages comes the need for storing various (meta)data -# that are generated while manipulating the sample. -# -# Modern stages realize a hierarchy of components: For example the specimen -# might be mounted on a multi-axial tilt rotation holder. This holder is -# fixed in the support unit which connects the holder to the rest of the -# microscope. -# -# In other examples, taken from atom probe microscopy, researchers may work -# with wire samples which are clipped into a larger fixing unit for -# convenience and enable for a more careful specimen handling. -# This fixture unit is known in atom probe jargon as a stub. -# Stubs in turn are positioned onto pucks. -# Pucks are then loaded onto carousels. -# A carousel is a carrier unit with which eventually entire sets of specimens -# can be moved in between parts of the microscope. -# -# An NXstage_lab instance reflects this hierarchical design. The stage is the -# root of the hierarchy. A stage carries the holder. -# In the case that it is not practical to distinguish these two layers, -# the holder should be given preference. -# -# Some examples for stage_labs in applications: -# -# * A nanoparticle on a copper grid. The copper grid is the holder. -# The grid itself is fixed to the stage. -# * An atom probe specimen fixed in a stub. In this case the stub can be -# considered the holder, while the cryostat temperature control unit is -# a component of the stage. -# * Samples with arrays of specimens, like a microtip on a microtip array -# is an example of a three-layer hierarchy commonly employed for -# efficient sequential processing of atom probe experiments. -# * With one entry of an application definition only one microtip should be -# described. Therefore, the microtip is the specimen, -# the array is the holder and the remaining mounting unit -# that is attached to the cryo-controller is the stage. -# * For in-situ experiments with e.g. chips with read-out electronics -# as actuators, the chips are again placed in a larger unit. -# * Other examples are (quasi) in-situ experiments where experimentalists -# anneal or deform the specimen via e.g. in-situ tensile testing machines -# which are mounted on the specimen holder. -# -# To cover for an as flexible design of complex stages, users should nest -# multiple instances of NXstage_lab objects according to their needs to reflect -# the differences between what they consider as the holder and what -# they consider is the stage. -# -# Instances should be named with integers starting from 1 as the top level unit. -# In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder -# (microtip array), stage_lab_3 for the microtip specimen, respectively. -# The depends_on keyword should be used with relative or absolute naming inside -# the file to specify how different stage_lab instances build a hierarchy -# if this is not obvious from numbered identifiers like the stage_lab_1 to -# stage_lab 3 example. The lower it is the number the higher it is the -# rank in the hierarchy. -# -# For specific details and inspiration about stages in electron microscopes: -# -# * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ -# * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ -# * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ -# * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) -# * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) -# * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) -# * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ -# -# -# -# Principal design of the stage. -# -# Exemplar terms could be side_entry, top_entry, -# single_tilt, quick_change, multiple_specimen, -# bulk_specimen, double_tilt, tilt_rotate, -# heating_chip, atmosphere_chip, -# electrical_biasing_chip, liquid_cell_chip -# -# -# -# -# Given name/alias for the components making the stage. -# -# -# -# -# -# Ideally, a (globally) unique persistent identifier, link, -# or text to a resource which gives further details. -# -# -# -# -# Should be defined by the application definition. -# -# -# -# -# Should be defined by the application definition. -# -# -# -# -# Should be defined by the application definition. -# -# -# -# -# Should be defined by the application definition. -# -# -# -# -# -# -# -# Voltage applied to the stage to decelerate electrons. -# -# -# -# -# -# The rotation, tilt and position of stage components can be specified -# either via NXtransformations or via the tilt_1, tilt_2, rotation, -# and position fields. -# -# -# -# -# diff --git a/dev_tools/tests/test_nxdl_utils.py b/dev_tools/tests/test_nxdl_utils.py index f49db9db41..07e968cbda 100644 --- a/dev_tools/tests/test_nxdl_utils.py +++ b/dev_tools/tests/test_nxdl_utils.py @@ -70,47 +70,33 @@ def test_get_node_at_nxdl_path(): ) elem = ET.parse(nxdl_file_path).getroot() node = nexus.get_node_at_nxdl_path( - "/ENTRY/measurement/EVENT_DATA_EM/USER/affiliation", elem=elem + "/ENTRY/measurement/EVENT_DATA_EM_SET/EVENT_DATA_EM/end_time", elem=elem ) - assert node.attrib["name"] == "affiliation" + assert node.attrib["name"] == "end_time" node = nexus.get_node_at_nxdl_path("/ENTRY/measurement", elem=elem) - assert node.attrib["type"] == "NXevent_data_em_set" + assert node.attrib["type"] == "NXem_msr" node = nexus.get_node_at_nxdl_path( - "/ENTRY/measurement/EVENT_DATA_EM/SPECTRUM_SET/summary", elem=elem + "/ENTRY/measurement/EVENT_DATA_EM_SET/EVENT_DATA_EM/IMAGE_C_SET/hyperstack", + elem=elem, ) assert node.attrib["type"] == "NXdata" node = nexus.get_node_at_nxdl_path( - "/ENTRY/measurement/EVENT_DATA_EM/SPECTRUM_SET/summary/DATA", elem=elem - ) - assert node.attrib["type"] == "NX_NUMBER" - - node = nexus.get_node_at_nxdl_path( - "/ENTRY/measurement/EVENT_DATA_EM/SPECTRUM_SET/summary/AXISNAME_indices", + "/ENTRY/measurement/EVENT_DATA_EM_SET/EVENT_DATA_EM/IMAGE_C_SET/hyperstack/AXISNAME_indices", elem=elem, ) assert node.attrib["name"] == "AXISNAME_indices" - node = nexus.get_node_at_nxdl_path("/ENTRY/COORDINATE_SYSTEM_SET", elem=elem) - assert node.attrib["type"] == "NXcoordinate_system_set" - node = nexus.get_node_at_nxdl_path( - "/ENTRY/COORDINATE_SYSTEM_SET/TRANSFORMATIONS", elem=elem - ) - assert node.attrib["type"] == "NXtransformations" - - node = nexus.get_node_at_nxdl_path( - "/ENTRY/COORDINATE_SYSTEM_SET/TRANSFORMATIONS/AXISNAME", elem=elem + "/ENTRY/measurement/EVENT_DATA_EM_SET/EVENT_DATA_EM/IMAGE_C_SET/stack/axis_j", + elem=elem, ) assert node.attrib["type"] == "NX_NUMBER" - node = nexus.get_node_at_nxdl_path( - "/ENTRY/COORDINATE_SYSTEM_SET/TRANSFORMATIONS/AXISNAME/transformation_type", - elem=elem, - ) - assert node.attrib["name"] == "transformation_type" + node = nexus.get_node_at_nxdl_path("/ENTRY/COORDINATE_SYSTEM_SET", elem=elem) + assert node.attrib["type"] == "NXcoordinate_system_set" nxdl_file_path = os.path.join( local_dir, "../../contributed_definitions/NXiv_temp.nxdl.xml" diff --git a/manual/source/classes/contributed_definitions/cgms-structure.rst b/manual/source/classes/contributed_definitions/cgms-structure.rst index 61e4a0bb82..ad0872731f 100644 --- a/manual/source/classes/contributed_definitions/cgms-structure.rst +++ b/manual/source/classes/contributed_definitions/cgms-structure.rst @@ -24,8 +24,8 @@ and relations between terms, for computational-geometry-based descriptions of th materials and atomic configurations used when characterizing materials in experiments and computer simulations. -As far as NeXus is concerned, the here proposed distinct sets of geometric primitives offer -a complementary alternative to the already existent base classes in NeXus for +As far as NeXus is concerned, this proposed set of geometric primitives offer +a complementary alternative to the current set of base classes in NeXus for constructive solid geometry (CSG) such as :ref:`NXcsg`, :ref:`NXoff_geometry`, or :ref:`NXquadric`. Second, to explore how terms which are frequently used by materials scientists in the field of @@ -43,7 +43,7 @@ Physics background ################## Microstructural features or crystal defects are spatial arrangements of atoms. Given their specific atomic arrangement and composition, such features have -specific constraints on the degrees of freedom. This equips these defects with specific +specific constraints on the degrees of freedom. This causes these defects to have specific properties (thermodynamic observables/descriptors). Provided well-defined coarse-graining procedures are used and regions-of-interest and/or regions-of-applicability are defined, microstructural features are often characterized and modelled to have associated thermodynamic descriptors. @@ -60,10 +60,9 @@ Maybe this is a historical burden given the large set of technical terms in plac motivated pragmatic solutions that have resulted in many research groups having developed similar formats using similar descriptions. -Defining crystal defects is a question of how to coarse-grain a given spatio-temporal set of atoms, -each having a nuclid type and position/trajectory. In most cases, such a coarse-graining is an ill-posed -task because different mathematical/geometrical methods exists how a point, a line, a surface, or a volumetric -defect can be described and be spatio-temporally constrained through a geometrical model +Defining crystal defects is a question of how to coarse-grain a given spatiotemporal set of atoms, +each having a nuclide type and position/trajectory. Different mathematical/geometrical methods exists +to determine how a point, a line, a surface, or a volumetric defect can be described and be spatiotemporally constrained through a geometrical model with defined primitives and associated observables. The key motivation to such coarse-graining is to reduce the complexity of the description. @@ -179,7 +178,7 @@ not only for stencil-based methods: :ref:`NXclustering`: A base class to describe clustering of objects (such as atoms or features). - :ref:`NXorientation_set`: + :ref:`NXrotation_set`: A base class to describe the relative orientation or rotation members of a set of features/objects. @@ -202,9 +201,8 @@ not only for stencil-based methods: :ref:`NXchemical_composition`: A base class to document (chemical) composition of a sample or a set of things. -Furthermore, it can be useful to have a set of base classes whereby software tools can -documents their state and return summaries for users about the performance -and elapsed time measured while processing data. These utility base classes are: +Finally, the following base classes allow data processing software to document its +input parameters and to summarize its performance statistics: :ref:`NXprogram`: A base class for a specifically named and versioned program or library/component. diff --git a/manual/source/classes/contributed_definitions/em-structure.rst b/manual/source/classes/contributed_definitions/em-structure.rst index 5ead19ffac..61aee37e08 100644 --- a/manual/source/classes/contributed_definitions/em-structure.rst +++ b/manual/source/classes/contributed_definitions/em-structure.rst @@ -8,7 +8,7 @@ Electron microscopy IntroductionEm EmAppDef EmBC - EmPartnerClasses + EmAnalysisClasses .. _IntroductionEm: @@ -21,30 +21,20 @@ We realize that the biology-/bio-materials/omics-branch of electron microscopy i to data management practices. In what follows, the focus is on the usage of electron microscopy in condensed-matter physics, chemical physics of solids, and materials engineering applications. As many of the components of electron microscopes used in the bio-materials communities are the same or at least many components are very similar, it is likely that the here presented schema definitions can also inspire discussion and exchange with the bio-materials community. -International and national projects and consortia including the German National Research Data Infrastructure are addressed NFDI-MatWerk, NFDI-BioImage, MaRDI, -NFDI-Microbiota, NFDI4Health, and e.g. NFDI-Neuro. +Partner consortia in the German National Research Data Infrastructure are here e.g. NFDI-BioImage, NFDI-Microbiota, NFDI4Health, and e.g. NFDI-Neuro. -Electron microscopes are functionally very customizable tools: Examples include multi-signal/-modal analyses which are frequently realized as on-the-fly computational analyses, -regularly switching between GUI-based instrument control, computational steps, and more and more using high-throughput stream-based processing. Also artificial intelligence -methods are increasingly used and become closer interconnected with classical modes of controlling the instrument and perform data processing. A challenge in electron microscopy -is that these steps are often executed within commercial integrated control and analysis software. This makes it difficult to keep track of workflows in a technology-partner-agnostic, -i.e. interdisciplinary manner. +Electron microscopes are functionally very customizable tools: Examples include multi-signal/-modal analyses which are frequently realized as on-the-fly computational analyses, regularly switching between GUI-based instrument control, computational steps, and more and more using high-throughput stream-based processing. Also artificial intelligence methods are increasingly used and are becoming more closely interconnected with classical modes of controlling the instrument and perform data processing. A challenge in electron microscopy is that these steps are often executed within commercial integrated control and analysis software. This makes it difficult to keep track of workflows in a technology-partner-agnostic, i.e. interdisciplinary manner. .. _EmAppDef: Application Definitions ####################### -We acknowledge that it can be difficult to agree on a single application definition which is generally enough applicable but not too complex to remain useful for application across a -variety of instruments, technology partners, and instrument use cases. In what follows, the proposal conceptualizes first the basic components of an electron microscope. Secondly, -the proposal documents the steps of usual workflows how an electron microscope is used when collecting data with detectors via probing radiation-specimen-matter interaction mechanisms. +We acknowledge that it can be difficult to agree on a single application definition which is generally enough applicable yet not unnecessarily complex and useful for applications across a variety of instruments, technology partners, and instrument use cases. In what follows, the proposal conceptualizes first the basic components of an electron microscope and the usual workflow of how an electron microscope is used for collecting data with detectors via probing radiation-specimen-matter interaction mechanisms. -In summary, scientists place a specimen/sample into the microscope, calibrate the instrument, take measurements, may perform experiments, prepare their specimens with a focused ion beam, -calibrate again, and take other measurements, before their session on the instrument ends. In between virtually all of these steps data are collected and stream in from different detectors -probing different physical mechanisms of the interaction between electrons or other types of radiation with the specimen. +In summary, scientists place a specimen/sample into the microscope, calibrate the instrument, take measurements, and may perform experiments, prepare their specimens with a focused ion beam, calibrate again, and take other measurements, before their session on the instrument ends. In between virtually all of these steps data are collected and stream in from different detectors probing different physical mechanisms of the interaction between electrons or other types of radiation with the specimen. -A microscope session ends with the scientist removing the specimen from the instrument or parking it so that the next user can start a session. -Occasionally, service technicians perform calibrations and maintenance which also can be described as a session on the microscope. +A microscope session ends with the scientist removing the specimen from the instrument or parking it so that the next user can start a session. Occasionally, service technicians perform calibrations and maintenance which also can be described as a session on the microscope. We have provided base classes to describe these steps and events and an application definition for electron microscopy: :ref:`NXem`: An application definition which explores the possibilities of electron microscopes. @@ -130,22 +120,21 @@ The following base classes are proposed to support modularizing the storage of p which modern stages of electron microscopes typically offer. -.. _EmPartnerClasses: +.. _EmAnalysisClasses: -Partner application definitions -############################### +We provide specific base classes which granularize frequently collected or analyzed quantities in specific application fields of electron microscopy to deal +with the situation that there are cases were logical connections between generated data artifacts mainly exist for the fact that the data artifacts were +collected during a workflow of electron microscopy research (e.g. taking measurements and then performing method-specific analyses generating new data and conclusions). We see a value in granularizing out these pieces of information into own classes. In fact, one limitation of application definitions in NeXus is currently that they define a set of constraints on their graph of controlled concepts and terms. If we take for example diffraction experiments with an electron microscope, it is usually the case that (diffraction) patterns are collected in the session at the microscope. However, all scientifically relevant conclusions are typically drawn later, i.e. through post-processing the collected diffraction (raw) data. These numerical and algorithmic steps define computational workflows were data from an instance of an application definition such as NXem are used as input but many additional concepts and constraints are applied without these demanding necessarily for changing constraints on fields or groups of NXem. If we were to modify NXem for these cases, NXem would combinatorially diverge as every different combination of required constraints demands having an own but almost similar application definition. For this reason, the concept of partner application definition are currently used which have fields/links whereby specifically relevant sources of information are connected to e.g. NXem. -A partner application definition is considered an application definition which stores data and metadata which are relevant for a given experiment but have usually only few connections to the detailed description of the workflow and experiment which motivates to granularize out these pieces of information into an own application definition. In fact, one limitation of application definitions in NeXus is currently that they define a set of constraints on their graph of controlled concepts and terms. If we take for example diffraction experiments with an electron microscope, it is usually the case that (diffraction) patterns are collected in the session at the microscope. However, all scientifically relevant conclusions are typically drawn later, i.e. through post-processing the collected diffraction (raw) data. These numerical and algorithmic steps define computational workflows were data from an instance of an application definition such as NXem are used as input but many additional concepts and constraints are applied without these demanding necessarily for changing constraints on fields or groups of NXem. If we were to modify NXem for these cases, NXem would combinatorially diverge as every different combination of required constraints demands having an own but almost similar application definition. For this reason, the concept of partner application definition are currently used which have fields/links whereby specifically -relevant sources of information are connected to e.g. NXem. More consolidation through the use of NXsubentry classes should be considered in the future. An alternative solution is to define both NXem and its partner application definitions -are deep base classes for which each field and group is optional. Specific instances of these blue print base classes could then elegantly combine the reuse of vocabulary and hierarchical organization information with specific constraints which are relevant only for specific usage of such data by specific tools used by an eventually smaller circle of users. +More consolidation through the use of NXsubentry classes should be considered in the future. For now we use an approach whereby base classes are combined to reuse vocabulary and a hierarchical organization of pieces of information with specific constraints which are relevant only for specific usage of such data by specific tools used by an eventually smaller circle of users. :ref:`NXem_ebsd`: Application definition for collecting and indexing Kikuchi pattern into orientation maps for the two-dimensional, three- (serial sectioning) and four-dimensional (spatial and time-dependent) case. The definition of several new base classes is motivated by by NXem_ebsd: - :ref:`NXem_ebsd_conventions`: + :ref:`NXem_conventions`, :ref:`NXem_conventions_ebsd`: A base class to store all reference frames and rotation conventions which are necessary to interpret the alignment and conventions used when working with orientation data. - :ref:`NXem_ebsd_crystal_structure_model`: + :ref:`NXcrystal_structure`: A base class to store crystalline phase/structure used for a simulation of diffraction pattern and comparison of these pattern against patterns to support indexin. diff --git a/manual/source/classes/contributed_definitions/icme-structure.rst b/manual/source/classes/contributed_definitions/icme-structure.rst index b21ad199e5..07aa6ee4e1 100644 --- a/manual/source/classes/contributed_definitions/icme-structure.rst +++ b/manual/source/classes/contributed_definitions/icme-structure.rst @@ -19,19 +19,22 @@ a design strategy and workflow whereby physics-based modelling of microstructure evolution is used to understand the relations between the microstructure and its technologically relevant descriptors to understand and tailor properties of materials. -The following application definitions are proposed to support the discussion -how materials engineering-specific data schemas can connect to or be mapped on +The following application definitions are proposed to support the discussion on how +materials-engineering-specific data schemas can connect to or be mapped on concepts which are equally modellable with NeXus: :ref:`NXms`: An application definition for arbitrary spatiotemporally resolved simulations. + :ref:`NXms_recon`: + A base class for documenting results of reconstructed microstructures. + :ref:`NXms_score_config`: - A specific example how :ref:`NXapm_paraprobe_config_ranger` can be + A specific example of how :ref:`NXapm_paraprobe_config_ranger` can be specialized for documenting the configuration of a computer simulation with the static recrystallization cellular automata model SCORE. :ref:`NXms_score_results`: - A specific example how :ref:`NXms` can be specialized for documenting + A specific example of how :ref:`NXms` can be specialized for documenting results of computer simulations with the static recrystallization cellular automata model SCORE. From eba0b2384ff16afbfa61f57201d44638f1f2a68b Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Fri, 6 May 2022 18:23:17 +0000 Subject: [PATCH 0373/1012] start discussing XRD.yaml --- XRD/xrd.yaml.txt | 58 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 XRD/xrd.yaml.txt diff --git a/XRD/xrd.yaml.txt b/XRD/xrd.yaml.txt new file mode 100644 index 0000000000..d226ee31a5 --- /dev/null +++ b/XRD/xrd.yaml.txt @@ -0,0 +1,58 @@ +NXxrd on top of NXmonopd +! : additions +? : could or should be modified? + +NXxrd (Application Definition) + ?entry?: (required) Nxentry + title: (required) NX_CHAR + start_time: (required) NX_DATE_TIME + definition: (required) NX_CHAR + Official NeXus NXDL schema to which this file conforms + Obligatory value: NXxrd + INSTRUMENT: (required) NXinstrument + SOURCE: (required) NXsource + type: (required) NX_CHAR + name: (required) NX_CHAR + probe: (required) NX_CHAR + Any of these values: neutron | x-ray | electron + !BEAM!: (required) NXbeam + incident_energy: (required) NX_FLOAT {units=NX_ENERGY} + CRYSTAL: (?required?) NXcrystal + wavelength[i]: (required) NX_FLOAT{units=NX_WAVELENGTH} + Optimum diffracted wavelength + DETECTOR: (required) NXdetector + raw_data[?nDet?],: (optional) NX_NUMBER {units=NX_ANY} + polar_angle[?nDet?]: (required) NX_FLOAT + data[?nDet?]: (required) NX_INT + detector signal (usually counts) are already + corrected for detector efficiency + SAMPLE: (required) NXsample + name: (required) NX_CHAR + Descriptive name of sample + rotation_angle: (?required?) NX_FLOAT{units=NX_ANGLE} + Optional rotation angle for the case when the powder + diagram has been obtained through an omega-2theta scan + like from a traditional single detector powder + diffractometer + MONITOR: (?required?) NXmonitor + mode: (required) NX_CHAR + Count to a preset value based on either clock time (timer) + or received monitor counts (monitor). + Any of these values: monitor | timer + preset: (required) NX_FLOAT + preset value for time or monitor + integral: (required) NX_FLOAT {units=NX_ANY} + Total integral monitor counts + DATA: (required) NXdata + polar_angle:link(suggested target:/NXentry/NXinstrument/NXdetector/polar_angle) + Link to polar angle in /NXentry/NXinstrument/NXdetector + data: link (suggested target: /NXentry/NXinstrument/NXdetector/data) + Link to data in /Nxentry/Nxinstrument/Nxdetector + !PROCESS!: (optional) NXprocess + Description of a processing or analysis step, such as the + baseline extraction or azimuth integration. + Add additional fields as needed to describe value(s) of + any variable, parameter, or term related to + the NXprocess step. Be sure to include units attributes + for all numerical fields. + From 2346a9d6f43e8c77cb41afe003d74427e2313a27 Mon Sep 17 00:00:00 2001 From: Rubel Date: Wed, 6 Sep 2023 12:30:35 +0200 Subject: [PATCH 0374/1012] converting into yaml file. --- .../nyaml/xrd.yaml | 29 +++++++++++-------- 1 file changed, 17 insertions(+), 12 deletions(-) rename XRD/xrd.yaml.txt => contributed_definitions/nyaml/xrd.yaml (83%) diff --git a/XRD/xrd.yaml.txt b/contributed_definitions/nyaml/xrd.yaml similarity index 83% rename from XRD/xrd.yaml.txt rename to contributed_definitions/nyaml/xrd.yaml index d226ee31a5..e0bfc279ef 100644 --- a/XRD/xrd.yaml.txt +++ b/contributed_definitions/nyaml/xrd.yaml @@ -1,16 +1,21 @@ -NXxrd on top of NXmonopd -! : additions -? : could or should be modified? +category: application +doc: | + NXxrd on top of NXmonopd +# ! : additions +# ? : could or should be modified? -NXxrd (Application Definition) - ?entry?: (required) Nxentry - title: (required) NX_CHAR - start_time: (required) NX_DATE_TIME - definition: (required) NX_CHAR - Official NeXus NXDL schema to which this file conforms - Obligatory value: NXxrd - INSTRUMENT: (required) NXinstrument - SOURCE: (required) NXsource +NXxrd(NXmonopd): + entry(Nxentry): + title: + start_time(NX_DATE_TIME): + exists: optional + definition: + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXxrd] + INSTRUMENT(NXinstrument): + exists: optional + SOURCE(NXsource): type: (required) NX_CHAR name: (required) NX_CHAR probe: (required) NX_CHAR From 3d9baa42eb215cf06218d42a7f52d915f1aad9e3 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Wed, 6 Sep 2023 13:10:11 +0200 Subject: [PATCH 0375/1012] base structure --- contributed_definitions/nyaml/NXxrd.yaml | 83 ++++++++++++++++++++ contributed_definitions/nyaml/NXxrd_pan.yaml | 13 +++ contributed_definitions/nyaml/xrd.yaml | 63 --------------- 3 files changed, 96 insertions(+), 63 deletions(-) create mode 100644 contributed_definitions/nyaml/NXxrd.yaml create mode 100644 contributed_definitions/nyaml/NXxrd_pan.yaml delete mode 100644 contributed_definitions/nyaml/xrd.yaml diff --git a/contributed_definitions/nyaml/NXxrd.yaml b/contributed_definitions/nyaml/NXxrd.yaml new file mode 100644 index 0000000000..f5f8ee53f1 --- /dev/null +++ b/contributed_definitions/nyaml/NXxrd.yaml @@ -0,0 +1,83 @@ +category: application +doc: | + NXxrd on top of NXmonopd +# ! : additions +# ? : could or should be modified? + +NXxrd(NXmonopd): + (Nxentry): + title: + start_time(NX_DATE_TIME): + exists: optional + definition: + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXxrd] + (NXinstrument): + exists: optional + (NXsource): + type: + name: + probe: + enumeration: [neutron, x-ray, electron] + (NXbeam): + incident_energy(NX_FLOAT): + units: NX_ENERGY + (NXcrystal): + exists: optional + wavelength[i](NX_FLOAT): + units: NX_WAVELENGTH + doc: | + Optimum diffracted wavelength + (NXdetector): + raw_data(NX_NUMBER): + units=NX_ANY + exists: optional + polar_angle(NX_FLOAT): + data(NX_INT): + doc: | + detector signal (usually counts) are already + corrected for detector efficiency + (NXsample): + name: + doc: | + Descriptive name of sample + rotation_angle(NX_FLOAT): + units: NX_ANGLE + doc: | + Optional rotation angle for the case when the powder + diagram has been obtained through an omega-2theta scan + like from a traditional single detector powder + diffractometer + (NXmonitor): + mode: + doc: | + Count to a preset value based on either clock time (timer) + or received monitor counts (monitor). + enumeration: [monitor, timer] + preset(NX_FLOAT): + doc: | + preset value for time or monitor + integral(NX_FLOAT): + units: NX_ANY + doc: | + Total integral monitor counts + (NXdata): + polar_angle: + doc: | + link (suggested target:/NXentry/NXinstrument/NXdetector/polar_angle) + Link to ponglar ale in /NXentry/NXinstrument/NXdetector + data: + doc: | + link (suggested target:/NXentry/NXinstrument/NXdetector/data) + Link to data in /Nxentry/Nxinstrument/Nxdetector + (NXprocess)): + exists: optional + doc: | + Description of a processing or analysis step, such as the + baseline extraction or azimuth integration. + Add additional fields as needed to describe value(s) of + any variable, parameter, or term related to + the NXprocess step. Be sure to include units attributes + for all numerical fields. + diff --git a/contributed_definitions/nyaml/NXxrd_pan.yaml b/contributed_definitions/nyaml/NXxrd_pan.yaml new file mode 100644 index 0000000000..eb0cd2482b --- /dev/null +++ b/contributed_definitions/nyaml/NXxrd_pan.yaml @@ -0,0 +1,13 @@ +category: application +doc: | + NXxrd on top of NXmonopd +# ! : additions +# ? : could or should be modified? + +NXxrd_pan(NXxrd): + (Nxentry): + definition: + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXxrd_pan] + diff --git a/contributed_definitions/nyaml/xrd.yaml b/contributed_definitions/nyaml/xrd.yaml deleted file mode 100644 index e0bfc279ef..0000000000 --- a/contributed_definitions/nyaml/xrd.yaml +++ /dev/null @@ -1,63 +0,0 @@ -category: application -doc: | - NXxrd on top of NXmonopd -# ! : additions -# ? : could or should be modified? - -NXxrd(NXmonopd): - entry(Nxentry): - title: - start_time(NX_DATE_TIME): - exists: optional - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXxrd] - INSTRUMENT(NXinstrument): - exists: optional - SOURCE(NXsource): - type: (required) NX_CHAR - name: (required) NX_CHAR - probe: (required) NX_CHAR - Any of these values: neutron | x-ray | electron - !BEAM!: (required) NXbeam - incident_energy: (required) NX_FLOAT {units=NX_ENERGY} - CRYSTAL: (?required?) NXcrystal - wavelength[i]: (required) NX_FLOAT{units=NX_WAVELENGTH} - Optimum diffracted wavelength - DETECTOR: (required) NXdetector - raw_data[?nDet?],: (optional) NX_NUMBER {units=NX_ANY} - polar_angle[?nDet?]: (required) NX_FLOAT - data[?nDet?]: (required) NX_INT - detector signal (usually counts) are already - corrected for detector efficiency - SAMPLE: (required) NXsample - name: (required) NX_CHAR - Descriptive name of sample - rotation_angle: (?required?) NX_FLOAT{units=NX_ANGLE} - Optional rotation angle for the case when the powder - diagram has been obtained through an omega-2theta scan - like from a traditional single detector powder - diffractometer - MONITOR: (?required?) NXmonitor - mode: (required) NX_CHAR - Count to a preset value based on either clock time (timer) - or received monitor counts (monitor). - Any of these values: monitor | timer - preset: (required) NX_FLOAT - preset value for time or monitor - integral: (required) NX_FLOAT {units=NX_ANY} - Total integral monitor counts - DATA: (required) NXdata - polar_angle:link(suggested target:/NXentry/NXinstrument/NXdetector/polar_angle) - Link to polar angle in /NXentry/NXinstrument/NXdetector - data: link (suggested target: /NXentry/NXinstrument/NXdetector/data) - Link to data in /Nxentry/Nxinstrument/Nxdetector - !PROCESS!: (optional) NXprocess - Description of a processing or analysis step, such as the - baseline extraction or azimuth integration. - Add additional fields as needed to describe value(s) of - any variable, parameter, or term related to - the NXprocess step. Be sure to include units attributes - for all numerical fields. - From f3348dcba2e1f6f9c39547aa36c23867ff30d4f5 Mon Sep 17 00:00:00 2001 From: Rubel Date: Wed, 6 Sep 2023 13:38:54 +0200 Subject: [PATCH 0376/1012] yaml is compatible with nyaml2nxdl --- contributed_definitions/nyaml/NXxrd.yaml | 154 +++++++++---------- contributed_definitions/nyaml/NXxrd_pan.yaml | 13 +- 2 files changed, 84 insertions(+), 83 deletions(-) diff --git a/contributed_definitions/nyaml/NXxrd.yaml b/contributed_definitions/nyaml/NXxrd.yaml index f5f8ee53f1..b8ebe90a78 100644 --- a/contributed_definitions/nyaml/NXxrd.yaml +++ b/contributed_definitions/nyaml/NXxrd.yaml @@ -1,83 +1,83 @@ category: application doc: | - NXxrd on top of NXmonopd + NXxrd on top of NXmonopd # ! : additions # ? : could or should be modified? - +type: group NXxrd(NXmonopd): - (Nxentry): - title: - start_time(NX_DATE_TIME): - exists: optional - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXxrd] - (NXinstrument): - exists: optional - (NXsource): - type: - name: - probe: - enumeration: [neutron, x-ray, electron] - (NXbeam): - incident_energy(NX_FLOAT): - units: NX_ENERGY - (NXcrystal): - exists: optional - wavelength[i](NX_FLOAT): - units: NX_WAVELENGTH - doc: | - Optimum diffracted wavelength - (NXdetector): - raw_data(NX_NUMBER): - units=NX_ANY - exists: optional - polar_angle(NX_FLOAT): - data(NX_INT): - doc: | - detector signal (usually counts) are already - corrected for detector efficiency - (NXsample): - name: - doc: | - Descriptive name of sample - rotation_angle(NX_FLOAT): - units: NX_ANGLE - doc: | - Optional rotation angle for the case when the powder - diagram has been obtained through an omega-2theta scan - like from a traditional single detector powder - diffractometer - (NXmonitor): - mode: - doc: | - Count to a preset value based on either clock time (timer) - or received monitor counts (monitor). - enumeration: [monitor, timer] - preset(NX_FLOAT): - doc: | - preset value for time or monitor - integral(NX_FLOAT): - units: NX_ANY - doc: | - Total integral monitor counts - (NXdata): - polar_angle: - doc: | - link (suggested target:/NXentry/NXinstrument/NXdetector/polar_angle) - Link to ponglar ale in /NXentry/NXinstrument/NXdetector - data: - doc: | - link (suggested target:/NXentry/NXinstrument/NXdetector/data) - Link to data in /Nxentry/Nxinstrument/Nxdetector - (NXprocess)): - exists: optional - doc: | - Description of a processing or analysis step, such as the - baseline extraction or azimuth integration. - Add additional fields as needed to describe value(s) of - any variable, parameter, or term related to - the NXprocess step. Be sure to include units attributes - for all numerical fields. + (Nxentry): + title: + start_time(NX_DATE_TIME): + exists: optional + definition: + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXxrd] + (NXinstrument): + exists: optional + (NXsource): + type: + name: + probe: + enumeration: [neutron, x-ray, electron] + (NXbeam): + incident_energy(NX_FLOAT): + unit: NX_ENERGY + (NXcrystal): + exists: optional + wavelength[i](NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + Optimum diffracted wavelength + (NXdetector): + raw_data(NX_NUMBER): + unit: NX_ANY + exists: optional + polar_angle(NX_FLOAT): + data(NX_INT): + doc: | + detector signal (usually counts) are already + corrected for detector efficiency + (NXsample): + name: + doc: | + Descriptive name of sample + rotation_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Optional rotation angle for the case when the powder + diagram has been obtained through an omega-2theta scan + like from a traditional single detector powder + diffractometer + (NXmonitor): + mode: + doc: | + Count to a preset value based on either clock time (timer) + or received monitor counts (monitor). + enumeration: [monitor, timer] + preset(NX_FLOAT): + doc: | + preset value for time or monitor + integral(NX_FLOAT): + unit: NX_ANY + doc: | + Total integral monitor counts + (NXdata): + polar_angle: + doc: | + link (suggested target:/NXentry/NXinstrument/NXdetector/polar_angle) + Link to ponglar ale in /NXentry/NXinstrument/NXdetector + data: + doc: | + link (suggested target:/NXentry/NXinstrument/NXdetector/data) + Link to data in /Nxentry/Nxinstrument/Nxdetector + (NXprocess)): + exists: optional + doc: | + Description of a processing or analysis step, such as the + baseline extraction or azimuth integration. + Add additional fields as needed to describe value(s) of + any variable, parameter, or term related to + the NXprocess step. Be sure to include units attributes + for all numerical fields. diff --git a/contributed_definitions/nyaml/NXxrd_pan.yaml b/contributed_definitions/nyaml/NXxrd_pan.yaml index eb0cd2482b..c3f7b7dbda 100644 --- a/contributed_definitions/nyaml/NXxrd_pan.yaml +++ b/contributed_definitions/nyaml/NXxrd_pan.yaml @@ -1,13 +1,14 @@ category: application doc: | - NXxrd on top of NXmonopd + NXxrd on top of NXmonopd # ! : additions # ? : could or should be modified? +type: "group" NXxrd_pan(NXxrd): - (Nxentry): - definition: - doc: | - Official NeXus NXDL schema to which this file conforms - enumeration: [NXxrd_pan] + (Nxentry): + definition: + doc: | + Official NeXus NXDL schema to which this file conforms + enumeration: [NXxrd_pan] From e73d810b199f0277dd62e584ca8238b60ce33c1b Mon Sep 17 00:00:00 2001 From: Rubel Date: Wed, 6 Sep 2023 15:17:33 +0200 Subject: [PATCH 0377/1012] Including nxdl --- .../nyaml/NXxrd_pan.nxdl.xml | 179 ++++++++++++++++++ contributed_definitions/nyaml/NXxrd_pan.yaml | 92 ++++++++- 2 files changed, 268 insertions(+), 3 deletions(-) create mode 100644 contributed_definitions/nyaml/NXxrd_pan.nxdl.xml diff --git a/contributed_definitions/nyaml/NXxrd_pan.nxdl.xml b/contributed_definitions/nyaml/NXxrd_pan.nxdl.xml new file mode 100644 index 0000000000..9062e0dcc5 --- /dev/null +++ b/contributed_definitions/nyaml/NXxrd_pan.nxdl.xml @@ -0,0 +1,179 @@ + + + + + + + NXxrd on top of NXmonopd + + + + + Official NeXus NXDL schema to which this file conforms. + + + + + + + + Method used to collect the data + default='X-Ray Diffraction (XRD)' + + + + + + The 2-theta range of the difractogram + + + + + + + + + + + + Type of the X-ray tube. + + + + + + + + + + + + + + Current of the X-ray tube. + + + + + Voltage of the X-ray tube. + + + + + + Wavelength of the K\u03b1 2 line. + + + + + + + + + + + K\u03b1 2/K\u03b1 1 intensity ratio. + + + + + Wavelength of the K\u00df line. + + + + + Wavelength of the X-ray source. Used to convert from 2-theta to Q. + + + + + + + Axis scanned. + + + + + Integration time per channel. + + + + + + + Collect user inputs e.g. name or path of the input file. + + + + Name of the data file. + + + + + + Desired plot would be two_theta vs intensity. + + + + Number of ecattered electrons per unit time. + + + + + The 2-theta range of the difractogram. + + + + + + Desired plot would be q_vector vs intensity. + q_vector: + doc: | + Wavevector for scatter energy. + intensity: + doc: | + Number of ecattered electrons per unit time + + + + + + The omega range of the difractogram. + + + + + The phi range of the difractogram + + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXxrd_pan.yaml b/contributed_definitions/nyaml/NXxrd_pan.yaml index c3f7b7dbda..6091894097 100644 --- a/contributed_definitions/nyaml/NXxrd_pan.yaml +++ b/contributed_definitions/nyaml/NXxrd_pan.yaml @@ -1,14 +1,100 @@ category: application doc: | NXxrd on top of NXmonopd +# n_values - symbols # ! : additions # ? : could or should be modified? - type: "group" NXxrd_pan(NXxrd): (Nxentry): definition: doc: | - Official NeXus NXDL schema to which this file conforms + Official NeXus NXDL schema to which this file conforms. enumeration: [NXxrd_pan] - + method: + doc: | + Method used to collect the data + default='X-Ray Diffraction (XRD)' + two_theta(NX_FLOAT): + # dim: + # !!! + unit: NX_ANGLE + \@units: + enumeration: [deg] + doc: | + The 2-theta range of the difractogram + (NXinstrument): + (NXsource): + xray_tube_material: + doc: | + Type of the X-ray tube. + enumeration: [Cu, Cr, Mo, Fe, Ag, In, Ga] + xray_tube_current(NX_FLOAT): + unit: NX_CURRENT + doc: | + Current of the X-ray tube. + xray_tube_voltage: + doc: | + Voltage of the X-ray tube. + # Unicode for alpha : \u03b1 + k_alpha_one(NX_FLOAT): + doc: | + Wavelength of the K\u03b1 1 line. + unit: NX_LENGTH + \@units: + enumeration: [angstrom] + k_alpha_two: + doc: | + Wavelength of the K\u03b1 2 line. + ratio_k_alphatwo_k_alphaone: + doc: | + K\u03b1 2/K\u03b1 1 intensity ratio. + kbeta: + doc: | + Wavelength of the K\u00df line. + source_peak_wavelength: + doc: | + Wavelength of the X-ray source. Used to convert from 2-theta to Q. + (NXdetector): + scan_axis: + doc: | + Axis scanned. + integration_time: + doc: | + Integration time per channel. + (NXcollection): + doc: | + Collect user inputs e.g. name or path of the input file. + data_file: + doc: | + Name of the data file. + 2theta_plot(NXdata): + doc: | + Desired plot would be two_theta vs intensity. + measured_intensity(AXISNAME): + doc: | + Number of ecattered electrons per unit time. + two_theta(DATA): + doc: | + The 2-theta range of the difractogram. + q_plot(NXdata): + doc: | + Desired plot would be q_vector vs intensity. + q_vector: + doc: | + Wavevector for scatter energy. + intensity: + doc: | + Number of ecattered electrons per unit time + (NXdata): + omega: + doc: | + The omega range of the difractogram. + phi: + doc: | + The phi range of the difractogram + chi: + doc: | + The chi range of the difractogram + doc: | + \ No newline at end of file From 72b0c1dbac2136bdd003030e05236ba4c7be79f7 Mon Sep 17 00:00:00 2001 From: sanbrock Date: Thu, 7 Sep 2023 10:53:00 +0200 Subject: [PATCH 0378/1012] fixing xrd definitions --- contributed_definitions/NXxrd.nxdl.xml | 136 ++++++++++++++++++ .../{nyaml => }/NXxrd_pan.nxdl.xml | 60 ++++---- contributed_definitions/nyaml/NXxrd.yaml | 2 +- contributed_definitions/nyaml/NXxrd_pan.yaml | 61 ++++---- 4 files changed, 200 insertions(+), 59 deletions(-) create mode 100644 contributed_definitions/NXxrd.nxdl.xml rename contributed_definitions/{nyaml => }/NXxrd_pan.nxdl.xml (80%) diff --git a/contributed_definitions/NXxrd.nxdl.xml b/contributed_definitions/NXxrd.nxdl.xml new file mode 100644 index 0000000000..6e74b9b7f8 --- /dev/null +++ b/contributed_definitions/NXxrd.nxdl.xml @@ -0,0 +1,136 @@ + + + + + + + NXxrd on top of NXmonopd + + + + + + + Official NeXus NXDL schema to which this file conforms + + + + + + + + + + + + + + + + + + + + + + + + Optimum diffracted wavelength + + + + + + + + + detector signal (usually counts) are already + corrected for detector efficiency + + + + + + + + Descriptive name of sample + + + + + Optional rotation angle for the case when the powder + diagram has been obtained through an omega-2theta scan + like from a traditional single detector powder + diffractometer + + + + + + + Count to a preset value based on either clock time (timer) + or received monitor counts (monitor). + + + + + + + + + preset value for time or monitor + + + + + Total integral monitor counts + + + + + + + link (suggested target:/NXentry/NXinstrument/NXdetector/polar_angle) + Link to ponglar ale in /NXentry/NXinstrument/NXdetector + + + + + link (suggested target:/NXentry/NXinstrument/NXdetector/data) + Link to data in /Nxentry/Nxinstrument/Nxdetector + + + + + + Description of a processing or analysis step, such as the + baseline extraction or azimuth integration. + Add additional fields as needed to describe value(s) of + any variable, parameter, or term related to + the NXprocess step. Be sure to include units attributes + for all numerical fields. + + + + diff --git a/contributed_definitions/nyaml/NXxrd_pan.nxdl.xml b/contributed_definitions/NXxrd_pan.nxdl.xml similarity index 80% rename from contributed_definitions/nyaml/NXxrd_pan.nxdl.xml rename to contributed_definitions/NXxrd_pan.nxdl.xml index 9062e0dcc5..5668a68c6c 100644 --- a/contributed_definitions/nyaml/NXxrd_pan.nxdl.xml +++ b/contributed_definitions/NXxrd_pan.nxdl.xml @@ -26,7 +26,7 @@ ? : could or should be modified?--> - NXxrd on top of NXmonopd + NXxrd_pan is a specialisation of NXxrd with exptra properties @@ -76,13 +76,13 @@ Current of the X-ray tube. - + Voltage of the X-ray tube. - + Wavelength of the K\u03b1 2 line. @@ -91,19 +91,19 @@ - + - + K\u03b1 2/K\u03b1 1 intensity ratio. - + Wavelength of the K\u00df line. - + Wavelength of the X-ray source. Used to convert from 2-theta to Q. @@ -115,7 +115,7 @@ Axis scanned. - + Integration time per channel. @@ -136,42 +136,44 @@ Desired plot would be two_theta vs intensity. - + Number of ecattered electrons per unit time. - - + + The 2-theta range of the difractogram. - - - - - Desired plot would be q_vector vs intensity. - q_vector: - doc: | - Wavevector for scatter energy. - intensity: - doc: | - Number of ecattered electrons per unit time - - - - + + The omega range of the difractogram. - + The phi range of the difractogram - + + + The chi range of the difractogram + + + + + + Desired plot would be q_vector vs intensity. + + + + Wavevector for scatter energy. + + + - + Number of ecattered electrons per unit time diff --git a/contributed_definitions/nyaml/NXxrd.yaml b/contributed_definitions/nyaml/NXxrd.yaml index b8ebe90a78..617b62c494 100644 --- a/contributed_definitions/nyaml/NXxrd.yaml +++ b/contributed_definitions/nyaml/NXxrd.yaml @@ -71,7 +71,7 @@ NXxrd(NXmonopd): doc: | link (suggested target:/NXentry/NXinstrument/NXdetector/data) Link to data in /Nxentry/Nxinstrument/Nxdetector - (NXprocess)): + (NXprocess): exists: optional doc: | Description of a processing or analysis step, such as the diff --git a/contributed_definitions/nyaml/NXxrd_pan.yaml b/contributed_definitions/nyaml/NXxrd_pan.yaml index 6091894097..8820bedd9a 100644 --- a/contributed_definitions/nyaml/NXxrd_pan.yaml +++ b/contributed_definitions/nyaml/NXxrd_pan.yaml @@ -1,6 +1,6 @@ category: application doc: | - NXxrd on top of NXmonopd + NXxrd_pan is a specialisation of NXxrd with exptra properties # n_values - symbols # ! : additions # ? : could or should be modified? @@ -19,10 +19,10 @@ NXxrd_pan(NXxrd): # dim: # !!! unit: NX_ANGLE - \@units: - enumeration: [deg] doc: | The 2-theta range of the difractogram + \@units: + enumeration: [deg] (NXinstrument): (NXsource): xray_tube_material: @@ -33,68 +33,71 @@ NXxrd_pan(NXxrd): unit: NX_CURRENT doc: | Current of the X-ray tube. - xray_tube_voltage: + xray_tube_voltage(NX_FLOAT): + unit: NX_VOLTAGE doc: | Voltage of the X-ray tube. # Unicode for alpha : \u03b1 k_alpha_one(NX_FLOAT): + unit: NX_ENERGY doc: | Wavelength of the K\u03b1 1 line. - unit: NX_LENGTH \@units: enumeration: [angstrom] - k_alpha_two: + k_alpha_two(NX_FLOAT): + unit: NX_ENERGY doc: | Wavelength of the K\u03b1 2 line. - ratio_k_alphatwo_k_alphaone: + ratio_k_alphatwo_k_alphaone(NX_FLOAT): + unit: NX_DIMENSIONLESS doc: | K\u03b1 2/K\u03b1 1 intensity ratio. - kbeta: + kbeta(NX_FLOAT): + unit: NX_ENERGY doc: | Wavelength of the K\u00df line. - source_peak_wavelength: + source_peak_wavelength(NX_FLOAT): + unit: NX_WAVELENGTH doc: | Wavelength of the X-ray source. Used to convert from 2-theta to Q. (NXdetector): scan_axis: doc: | Axis scanned. - integration_time: + integration_time(NX_FLOAT): + unit: NX_TIME doc: | Integration time per channel. (NXcollection): doc: | Collect user inputs e.g. name or path of the input file. data_file: - doc: | - Name of the data file. + doc: | + Name of the data file. 2theta_plot(NXdata): doc: | Desired plot would be two_theta vs intensity. - measured_intensity(AXISNAME): + data_measured_intensity(NX_FLOAT): doc: | Number of ecattered electrons per unit time. - two_theta(DATA): + axis_two_theta(NX_FLOAT): doc: | The 2-theta range of the difractogram. - q_plot(NXdata): - doc: | - Desired plot would be q_vector vs intensity. - q_vector: - doc: | - Wavevector for scatter energy. - intensity: - doc: | - Number of ecattered electrons per unit time - (NXdata): - omega: + omega(NX_FLOAT): doc: | The omega range of the difractogram. - phi: + phi(NX_FLOAT): doc: | The phi range of the difractogram - chi: + chi(NX_FLOAT): doc: | The chi range of the difractogram - doc: | - \ No newline at end of file + q_plot(NXdata): + doc: | + Desired plot would be q_vector vs intensity. + axis_q(NX_FLOAT): + doc: | + Wavevector for scatter energy. + data_intensity(NX_FLOAT): + doc: | + Number of ecattered electrons per unit time From 633a196acd746ff34be26e862ec1992f4cac67fd Mon Sep 17 00:00:00 2001 From: sanbrock Date: Thu, 7 Sep 2023 14:07:40 +0200 Subject: [PATCH 0379/1012] further cleaning of definitions --- contributed_definitions/NXxrd.nxdl.xml | 77 ++++--------------- contributed_definitions/NXxrd_pan.nxdl.xml | 80 ++++++++++++++------ contributed_definitions/nyaml/NXxrd.yaml | 56 +++----------- contributed_definitions/nyaml/NXxrd_pan.yaml | 61 ++++++++++----- 4 files changed, 122 insertions(+), 152 deletions(-) diff --git a/contributed_definitions/NXxrd.nxdl.xml b/contributed_definitions/NXxrd.nxdl.xml index 6e74b9b7f8..db1c3d0ced 100644 --- a/contributed_definitions/NXxrd.nxdl.xml +++ b/contributed_definitions/NXxrd.nxdl.xml @@ -28,8 +28,6 @@ NXxrd on top of NXmonopd - - Official NeXus NXDL schema to which this file conforms @@ -39,87 +37,38 @@ - - - - - - - - - - - - - - - Optimum diffracted wavelength - - - - - - + - detector signal (usually counts) are already - corrected for detector efficiency + raw detector signal (usually counts) as colected + + + - - - - Descriptive name of sample - - - - - Optional rotation angle for the case when the powder - diagram has been obtained through an omega-2theta scan - like from a traditional single detector powder - diffractometer - - - - - - - Count to a preset value based on either clock time (timer) - or received monitor counts (monitor). - - - - - - - - - preset value for time or monitor - - - - - Total integral monitor counts - - - - + link (suggested target:/NXentry/NXinstrument/NXdetector/polar_angle) Link to ponglar ale in /NXentry/NXinstrument/NXdetector + + + - + link (suggested target:/NXentry/NXinstrument/NXdetector/data) Link to data in /Nxentry/Nxinstrument/Nxdetector + + + diff --git a/contributed_definitions/NXxrd_pan.nxdl.xml b/contributed_definitions/NXxrd_pan.nxdl.xml index 5668a68c6c..18cf7bfefc 100644 --- a/contributed_definitions/NXxrd_pan.nxdl.xml +++ b/contributed_definitions/NXxrd_pan.nxdl.xml @@ -43,18 +43,6 @@ default='X-Ray Diffraction (XRD)' - - - - The 2-theta range of the difractogram - - - - - - - @@ -82,7 +70,17 @@ - + + + Wavelength of the K\u03b1 1 line. + + + + + + + + Wavelength of the K\u03b1 2 line. @@ -91,17 +89,21 @@ - K\u03b1 2/K\u03b1 1 intensity ratio. - + Wavelength of the K\u00df line. + + + + + @@ -120,6 +122,19 @@ Integration time per channel. + + + The 2-theta range of the difractogram + + + + + + + + + + @@ -136,42 +151,57 @@ Desired plot would be two_theta vs intensity. - + - Number of ecattered electrons per unit time. + Number of scattered electrons per unit time. + + + - + - The 2-theta range of the difractogram. + Axis scale represeting the 2-theta range of the difractogram. + + + - + The omega range of the difractogram. + + + - + The phi range of the difractogram + + + - + The chi range of the difractogram + + + Desired plot would be q_vector vs intensity. - + - Wavevector for scatter energy. + Axis scale representing wavevector for scatter energy. - + Number of ecattered electrons per unit time diff --git a/contributed_definitions/nyaml/NXxrd.yaml b/contributed_definitions/nyaml/NXxrd.yaml index 617b62c494..9ef8da665a 100644 --- a/contributed_definitions/nyaml/NXxrd.yaml +++ b/contributed_definitions/nyaml/NXxrd.yaml @@ -6,71 +6,39 @@ doc: | type: group NXxrd(NXmonopd): (Nxentry): - title: - start_time(NX_DATE_TIME): - exists: optional definition: doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXxrd] (NXinstrument): exists: optional - (NXsource): - type: - name: - probe: - enumeration: [neutron, x-ray, electron] (NXbeam): incident_energy(NX_FLOAT): unit: NX_ENERGY - (NXcrystal): - exists: optional - wavelength[i](NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - Optimum diffracted wavelength (NXdetector): raw_data(NX_NUMBER): unit: NX_ANY exists: optional - polar_angle(NX_FLOAT): - data(NX_INT): doc: | - detector signal (usually counts) are already - corrected for detector efficiency - (NXsample): - name: - doc: | - Descriptive name of sample - rotation_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Optional rotation angle for the case when the powder - diagram has been obtained through an omega-2theta scan - like from a traditional single detector powder - diffractometer - (NXmonitor): - mode: - doc: | - Count to a preset value based on either clock time (timer) - or received monitor counts (monitor). - enumeration: [monitor, timer] - preset(NX_FLOAT): - doc: | - preset value for time or monitor - integral(NX_FLOAT): - unit: NX_ANY - doc: | - Total integral monitor counts + raw detector signal (usually counts) as colected + dimensions: + rank: 1 + dim: [[1, nDet]] (NXdata): - polar_angle: + polar_angle(NX_FLOAT): doc: | link (suggested target:/NXentry/NXinstrument/NXdetector/polar_angle) Link to ponglar ale in /NXentry/NXinstrument/NXdetector - data: + dimensions: + rank: 1 + dim: [[1, nDet]] + data(NX_NUMBER): doc: | link (suggested target:/NXentry/NXinstrument/NXdetector/data) Link to data in /Nxentry/Nxinstrument/Nxdetector + dimensions: + rank: 1 + dim: [[1, nDet]] (NXprocess): exists: optional doc: | diff --git a/contributed_definitions/nyaml/NXxrd_pan.yaml b/contributed_definitions/nyaml/NXxrd_pan.yaml index 8820bedd9a..8ceb31ad98 100644 --- a/contributed_definitions/nyaml/NXxrd_pan.yaml +++ b/contributed_definitions/nyaml/NXxrd_pan.yaml @@ -15,14 +15,6 @@ NXxrd_pan(NXxrd): doc: | Method used to collect the data default='X-Ray Diffraction (XRD)' - two_theta(NX_FLOAT): - # dim: - # !!! - unit: NX_ANGLE - doc: | - The 2-theta range of the difractogram - \@units: - enumeration: [deg] (NXinstrument): (NXsource): xray_tube_material: @@ -39,23 +31,27 @@ NXxrd_pan(NXxrd): Voltage of the X-ray tube. # Unicode for alpha : \u03b1 k_alpha_one(NX_FLOAT): - unit: NX_ENERGY + unit: NX_WAVELENGTH doc: | Wavelength of the K\u03b1 1 line. \@units: enumeration: [angstrom] - k_alpha_two(NX_FLOAT): - unit: NX_ENERGY + k_alpha_two(NX_FLOAT): + unit: NX_WAVELENGTH doc: | Wavelength of the K\u03b1 2 line. + \@units: + enumeration: [angstrom] ratio_k_alphatwo_k_alphaone(NX_FLOAT): unit: NX_DIMENSIONLESS doc: | K\u03b1 2/K\u03b1 1 intensity ratio. kbeta(NX_FLOAT): - unit: NX_ENERGY + unit: NX_WAVELENGTH doc: | Wavelength of the K\u00df line. + \@units: + enumeration: [angstrom] source_peak_wavelength(NX_FLOAT): unit: NX_WAVELENGTH doc: | @@ -68,6 +64,15 @@ NXxrd_pan(NXxrd): unit: NX_TIME doc: | Integration time per channel. + polar_angle(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, nDet]] + unit: NX_ANGLE + doc: | + The 2-theta range of the difractogram + \@units: + enumeration: [deg] (NXcollection): doc: | Collect user inputs e.g. name or path of the input file. @@ -77,27 +82,45 @@ NXxrd_pan(NXxrd): 2theta_plot(NXdata): doc: | Desired plot would be two_theta vs intensity. - data_measured_intensity(NX_FLOAT): + intensity(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, nDet]] doc: | - Number of ecattered electrons per unit time. - axis_two_theta(NX_FLOAT): + Number of scattered electrons per unit time. + two_theta(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, nDet]] doc: | - The 2-theta range of the difractogram. + Axis scale represeting the 2-theta range of the difractogram. omega(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, nDet]] + exists: optional doc: | The omega range of the difractogram. phi(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, nDet]] + exists: optional doc: | The phi range of the difractogram chi(NX_FLOAT): + dimensions: + rank: 1 + dim: [[1, nDet]] + exists: optional doc: | The chi range of the difractogram q_plot(NXdata): doc: | Desired plot would be q_vector vs intensity. - axis_q(NX_FLOAT): + q(NX_FLOAT): doc: | - Wavevector for scatter energy. - data_intensity(NX_FLOAT): + Axis scale representing wavevector for scatter energy. + intensity(NX_FLOAT): doc: | Number of ecattered electrons per unit time From 5b51cc7be633ede428eeebbef8cc8706f671bf68 Mon Sep 17 00:00:00 2001 From: sanbrock Date: Thu, 7 Sep 2023 14:27:05 +0200 Subject: [PATCH 0380/1012] further cleaning of rw data and polar_angle vs. twotheta definitions --- contributed_definitions/NXxrd.nxdl.xml | 15 ++++++++++++++- contributed_definitions/NXxrd_pan.nxdl.xml | 13 ------------- contributed_definitions/nyaml/NXxrd.yaml | 12 ++++++++++-- contributed_definitions/nyaml/NXxrd_pan.yaml | 9 --------- 4 files changed, 24 insertions(+), 25 deletions(-) diff --git a/contributed_definitions/NXxrd.nxdl.xml b/contributed_definitions/NXxrd.nxdl.xml index db1c3d0ced..688fd144fa 100644 --- a/contributed_definitions/NXxrd.nxdl.xml +++ b/contributed_definitions/NXxrd.nxdl.xml @@ -41,13 +41,26 @@ - + raw detector signal (usually counts) as colected + it can be a multi-dimensional dataset depending on + the detector type (faster axes) and + the scanning method (slower axes) + + + + + The 2-theta range of the difractogram + + + + + diff --git a/contributed_definitions/NXxrd_pan.nxdl.xml b/contributed_definitions/NXxrd_pan.nxdl.xml index 18cf7bfefc..87cd3a826e 100644 --- a/contributed_definitions/NXxrd_pan.nxdl.xml +++ b/contributed_definitions/NXxrd_pan.nxdl.xml @@ -122,19 +122,6 @@ Integration time per channel. - - - The 2-theta range of the difractogram - - - - - - - - - - diff --git a/contributed_definitions/nyaml/NXxrd.yaml b/contributed_definitions/nyaml/NXxrd.yaml index 9ef8da665a..f90b5dc66f 100644 --- a/contributed_definitions/nyaml/NXxrd.yaml +++ b/contributed_definitions/nyaml/NXxrd.yaml @@ -16,14 +16,22 @@ NXxrd(NXmonopd): incident_energy(NX_FLOAT): unit: NX_ENERGY (NXdetector): - raw_data(NX_NUMBER): - unit: NX_ANY + raw_data(NXdata): exists: optional doc: | raw detector signal (usually counts) as colected + it can be a multi-dimensional dataset depending on + the detector type (faster axes) and + the scanning method (slower axes) + polar_angle(NX_FLOAT): dimensions: rank: 1 dim: [[1, nDet]] + unit: NX_ANGLE + doc: | + The 2-theta range of the difractogram + \@units: + enumeration: [deg] (NXdata): polar_angle(NX_FLOAT): doc: | diff --git a/contributed_definitions/nyaml/NXxrd_pan.yaml b/contributed_definitions/nyaml/NXxrd_pan.yaml index 8ceb31ad98..8f48dab54c 100644 --- a/contributed_definitions/nyaml/NXxrd_pan.yaml +++ b/contributed_definitions/nyaml/NXxrd_pan.yaml @@ -64,15 +64,6 @@ NXxrd_pan(NXxrd): unit: NX_TIME doc: | Integration time per channel. - polar_angle(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, nDet]] - unit: NX_ANGLE - doc: | - The 2-theta range of the difractogram - \@units: - enumeration: [deg] (NXcollection): doc: | Collect user inputs e.g. name or path of the input file. From 8d54fcc8f0c8da0aa95625012df239dbc21909a3 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Fri, 8 Sep 2023 11:12:08 +0200 Subject: [PATCH 0381/1012] fixing typos --- contributed_definitions/NXxrd.nxdl.xml | 2 +- contributed_definitions/NXxrd_pan.nxdl.xml | 2 +- contributed_definitions/nyaml/NXxrd.yaml | 2 +- contributed_definitions/nyaml/NXxrd_pan.yaml | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/contributed_definitions/NXxrd.nxdl.xml b/contributed_definitions/NXxrd.nxdl.xml index 688fd144fa..88e4a19b10 100644 --- a/contributed_definitions/NXxrd.nxdl.xml +++ b/contributed_definitions/NXxrd.nxdl.xml @@ -27,7 +27,7 @@ NXxrd on top of NXmonopd - + Official NeXus NXDL schema to which this file conforms diff --git a/contributed_definitions/NXxrd_pan.nxdl.xml b/contributed_definitions/NXxrd_pan.nxdl.xml index 87cd3a826e..895d318714 100644 --- a/contributed_definitions/NXxrd_pan.nxdl.xml +++ b/contributed_definitions/NXxrd_pan.nxdl.xml @@ -28,7 +28,7 @@ NXxrd_pan is a specialisation of NXxrd with exptra properties - + Official NeXus NXDL schema to which this file conforms. diff --git a/contributed_definitions/nyaml/NXxrd.yaml b/contributed_definitions/nyaml/NXxrd.yaml index f90b5dc66f..cee98655d4 100644 --- a/contributed_definitions/nyaml/NXxrd.yaml +++ b/contributed_definitions/nyaml/NXxrd.yaml @@ -5,7 +5,7 @@ doc: | # ? : could or should be modified? type: group NXxrd(NXmonopd): - (Nxentry): + (NXentry): definition: doc: | Official NeXus NXDL schema to which this file conforms diff --git a/contributed_definitions/nyaml/NXxrd_pan.yaml b/contributed_definitions/nyaml/NXxrd_pan.yaml index 8f48dab54c..2913e19fa8 100644 --- a/contributed_definitions/nyaml/NXxrd_pan.yaml +++ b/contributed_definitions/nyaml/NXxrd_pan.yaml @@ -6,7 +6,7 @@ doc: | # ? : could or should be modified? type: "group" NXxrd_pan(NXxrd): - (Nxentry): + (NXentry): definition: doc: | Official NeXus NXDL schema to which this file conforms. From d12c4def809f8fe278d20f5b5cb4a459f7f7e1ec Mon Sep 17 00:00:00 2001 From: Rubel Date: Mon, 11 Sep 2023 12:11:44 +0200 Subject: [PATCH 0382/1012] Updating xrd_pan --- contributed_definitions/NXxrd.nxdl.xml | 2 +- contributed_definitions/NXxrd_pan.nxdl.xml | 112 ++++++++++++++++++- contributed_definitions/nyaml/NXxrd.yaml | 2 +- contributed_definitions/nyaml/NXxrd_pan.yaml | 80 +++++++++++++ 4 files changed, 188 insertions(+), 8 deletions(-) diff --git a/contributed_definitions/NXxrd.nxdl.xml b/contributed_definitions/NXxrd.nxdl.xml index 88e4a19b10..812d4f390e 100644 --- a/contributed_definitions/NXxrd.nxdl.xml +++ b/contributed_definitions/NXxrd.nxdl.xml @@ -23,7 +23,7 @@ --> - + NXxrd on top of NXmonopd diff --git a/contributed_definitions/NXxrd_pan.nxdl.xml b/contributed_definitions/NXxrd_pan.nxdl.xml index 895d318714..e7a68e11f2 100644 --- a/contributed_definitions/NXxrd_pan.nxdl.xml +++ b/contributed_definitions/NXxrd_pan.nxdl.xml @@ -44,6 +44,7 @@ + @@ -95,7 +96,7 @@ K\u03b1 2/K\u03b1 1 intensity ratio. - + Wavelength of the K\u00df line. @@ -105,7 +106,7 @@ - + Wavelength of the X-ray source. Used to convert from 2-theta to Q. @@ -117,22 +118,95 @@ Axis scanned. - + + + Mode of scan. + + + Integration time per channel. - + + Collect user inputs e.g. name or path of the input file. - + + + + Starting value of the diffracted angle. + + + + + Ending value of the diffracted angle. + + + + + Step size in the between two diffracted angles. + + + + + + + Starting value of the incident angle. + + + + + Ending value of the incident angle. + + + + + Step size in the between two incident angles. + + + + Name of the data file. + + + Type of measurement. + + + + + Beam attenuation factors over the path. + + + + + Goniometer position X. + + + + + Goniometer position Y. + + + + + Goniometer position Z + + + + + Total time of count. + + @@ -179,7 +253,7 @@ - + Desired plot would be q_vector vs intensity. @@ -194,5 +268,31 @@ + + + Description on sample. + + + + Mode of sample. + + + + + Id of sample. + + + + + Usually in xrd sample are being analysed, but sample might be identified by + assumed name or given name. + + + + + + + + diff --git a/contributed_definitions/nyaml/NXxrd.yaml b/contributed_definitions/nyaml/NXxrd.yaml index cee98655d4..2b9cbf9c54 100644 --- a/contributed_definitions/nyaml/NXxrd.yaml +++ b/contributed_definitions/nyaml/NXxrd.yaml @@ -1,4 +1,4 @@ -category: application +category: base doc: | NXxrd on top of NXmonopd # ! : additions diff --git a/contributed_definitions/nyaml/NXxrd_pan.yaml b/contributed_definitions/nyaml/NXxrd_pan.yaml index 2913e19fa8..598d4ccd54 100644 --- a/contributed_definitions/nyaml/NXxrd_pan.yaml +++ b/contributed_definitions/nyaml/NXxrd_pan.yaml @@ -16,6 +16,7 @@ NXxrd_pan(NXxrd): Method used to collect the data default='X-Ray Diffraction (XRD)' (NXinstrument): + # Need a group that explain (NXsource): xray_tube_material: doc: | @@ -47,12 +48,14 @@ NXxrd_pan(NXxrd): doc: | K\u03b1 2/K\u03b1 1 intensity ratio. kbeta(NX_FLOAT): + exists: optional unit: NX_WAVELENGTH doc: | Wavelength of the K\u00df line. \@units: enumeration: [angstrom] source_peak_wavelength(NX_FLOAT): + exists: optional unit: NX_WAVELENGTH doc: | Wavelength of the X-ray source. Used to convert from 2-theta to Q. @@ -60,16 +63,77 @@ NXxrd_pan(NXxrd): scan_axis: doc: | Axis scanned. + scan_mode: + doc: | + Mode of scan. integration_time(NX_FLOAT): + exists: optional unit: NX_TIME doc: | Integration time per channel. + # Note: We should need to think about incident and deflected beam (NXbeam). As the data also contains + # beams information about the beam and the object encountered by beam through the path + # incident_beam(NXbeam): + # defracted_beam(NXbeam): (NXcollection): + exists: optional doc: | Collect user inputs e.g. name or path of the input file. + 2theta(NXcollection): + start(NX_FLOAT): + unit: NX_ANGLE + doc: | + Starting value of the diffracted angle. + end(NX_FLOAT): + unit: NX_ANGLE + doc: | + Ending value of the diffracted angle. + step(NX_FLOAT): + unit: NX_ANGLE + doc: | + Step size in the between two diffracted angles. + omega(NXcollection): + start(NX_FLOAT): + unit: NX_ANGLE + doc: | + Starting value of the incident angle. + end(NX_FLOAT): + unit: NX_ANGLE + doc: | + Ending value of the incident angle. + step(NX_FLOAT): + unit: NX_ANGLE + doc: | + Step size in the between two incident angles. data_file: + exists: optional doc: | Name of the data file. + measurement_type: + doc: | + Type of measurement. + beam_attenuation_factors: + doc: | + Beam attenuation factors over the path. + goniometer_x(NX_FLOAT): + exists: optional + unit: NX_LENGTH + doc: | + Goniometer position X. + goniometer_y(NX_FLOAT): + exists: optional + unit: NX_LENGTH + doc: | + Goniometer position Y. + goniometer_z(NX_FLOAT): + exists: optional + unit: NX_LENGTH + doc: | + Goniometer position Z + count_time(NX_FLOAT): + unit: NX_TIME + doc: | + Total time of count. 2theta_plot(NXdata): doc: | Desired plot would be two_theta vs intensity. @@ -107,6 +171,7 @@ NXxrd_pan(NXxrd): doc: | The chi range of the difractogram q_plot(NXdata): + exists: optional doc: | Desired plot would be q_vector vs intensity. q(NX_FLOAT): @@ -115,3 +180,18 @@ NXxrd_pan(NXxrd): intensity(NX_FLOAT): doc: | Number of ecattered electrons per unit time + (NXsample): + exists: optional + doc: | + Description on sample. + sample_mode: + doc: | + Mode of sample. + sample_id: + doc: | + Id of sample. + sample_name: + doc: | + Usually in xrd sample are being analysed, but sample might be identified by assumed name or given name. + prepared_by: + doc: | From 5df5c5ab0f0047ad883e59c1e7800bdb53339081 Mon Sep 17 00:00:00 2001 From: Rubel Date: Thu, 30 Nov 2023 23:11:24 +0100 Subject: [PATCH 0383/1012] modify nxdl. --- contributed_definitions/NXxrd.nxdl.xml | 7 ++++--- contributed_definitions/NXxrd_pan.nxdl.xml | 7 ++++--- 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/contributed_definitions/NXxrd.nxdl.xml b/contributed_definitions/NXxrd.nxdl.xml index 812d4f390e..3c987ba561 100644 --- a/contributed_definitions/NXxrd.nxdl.xml +++ b/contributed_definitions/NXxrd.nxdl.xml @@ -1,9 +1,9 @@ - + - diff --git a/contributed_definitions/NXxrd_pan.nxdl.xml b/contributed_definitions/NXxrd_pan.nxdl.xml index e7a68e11f2..097b2e0d2e 100644 --- a/contributed_definitions/NXxrd_pan.nxdl.xml +++ b/contributed_definitions/NXxrd_pan.nxdl.xml @@ -1,9 +1,9 @@ - + - From d8340a10b4bd920e3a37f2650be946f55e0f0a67 Mon Sep 17 00:00:00 2001 From: Rubel Date: Fri, 1 Dec 2023 11:16:54 +0100 Subject: [PATCH 0384/1012] update --- contributed_definitions/nyaml/NXxrd_pan.yaml | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/contributed_definitions/nyaml/NXxrd_pan.yaml b/contributed_definitions/nyaml/NXxrd_pan.yaml index 598d4ccd54..d45a731f8b 100644 --- a/contributed_definitions/nyaml/NXxrd_pan.yaml +++ b/contributed_definitions/nyaml/NXxrd_pan.yaml @@ -83,15 +83,15 @@ NXxrd_pan(NXxrd): start(NX_FLOAT): unit: NX_ANGLE doc: | - Starting value of the diffracted angle. + Starting value of the diffraction angle. end(NX_FLOAT): unit: NX_ANGLE doc: | - Ending value of the diffracted angle. + Ending value of the diffraction angle. step(NX_FLOAT): unit: NX_ANGLE doc: | - Step size in the between two diffracted angles. + Minimum step size in-between two diffraction angles. omega(NXcollection): start(NX_FLOAT): unit: NX_ANGLE @@ -104,7 +104,7 @@ NXxrd_pan(NXxrd): step(NX_FLOAT): unit: NX_ANGLE doc: | - Step size in the between two incident angles. + Minimum step size in the between two incident angles. data_file: exists: optional doc: | @@ -173,13 +173,13 @@ NXxrd_pan(NXxrd): q_plot(NXdata): exists: optional doc: | - Desired plot would be q_vector vs intensity. + Desired plot would be q_vector vs intensity. q(NX_FLOAT): doc: | Axis scale representing wavevector for scatter energy. intensity(NX_FLOAT): doc: | - Number of ecattered electrons per unit time + Number of scattered electrons per unit time. (NXsample): exists: optional doc: | From 84d0d8fd8f76bff63862c011225c00e6a19854be Mon Sep 17 00:00:00 2001 From: Rubel Date: Fri, 1 Dec 2023 11:22:43 +0100 Subject: [PATCH 0385/1012] mv NXxrd into application. --- .../NXxrd.nxdl.xml | 0 contributed_definitions/NXxrd_pan.nxdl.xml | 10 +++++----- 2 files changed, 5 insertions(+), 5 deletions(-) rename {contributed_definitions => applications}/NXxrd.nxdl.xml (100%) diff --git a/contributed_definitions/NXxrd.nxdl.xml b/applications/NXxrd.nxdl.xml similarity index 100% rename from contributed_definitions/NXxrd.nxdl.xml rename to applications/NXxrd.nxdl.xml diff --git a/contributed_definitions/NXxrd_pan.nxdl.xml b/contributed_definitions/NXxrd_pan.nxdl.xml index 097b2e0d2e..9dae0a1524 100644 --- a/contributed_definitions/NXxrd_pan.nxdl.xml +++ b/contributed_definitions/NXxrd_pan.nxdl.xml @@ -142,17 +142,17 @@ defracted_beam(NXbeam):--> - Starting value of the diffracted angle. + Starting value of the diffraction angle. - Ending value of the diffracted angle. + Ending value of the diffraction angle. - Step size in the between two diffracted angles. + Minimum step size in-between two diffraction angles. @@ -169,7 +169,7 @@ defracted_beam(NXbeam):--> - Step size in the between two incident angles. + Minimum step size in the between two incident angles. @@ -265,7 +265,7 @@ defracted_beam(NXbeam):--> - Number of ecattered electrons per unit time + Number of scattered electrons per unit time. From 85d27509c3db63bb031b93ca124ab4be24013803 Mon Sep 17 00:00:00 2001 From: Rubel Date: Fri, 1 Dec 2023 11:37:11 +0100 Subject: [PATCH 0386/1012] mv NXxrd into application. --- contributed_definitions/NXxrd_pan.nxdl.xml | 3 +++ contributed_definitions/nyaml/NXxrd_pan.yaml | 1 + 2 files changed, 4 insertions(+) diff --git a/contributed_definitions/NXxrd_pan.nxdl.xml b/contributed_definitions/NXxrd_pan.nxdl.xml index 9dae0a1524..9f4f655fa7 100644 --- a/contributed_definitions/NXxrd_pan.nxdl.xml +++ b/contributed_definitions/NXxrd_pan.nxdl.xml @@ -43,6 +43,9 @@ n_values - symbols Method used to collect the data default='X-Ray Diffraction (XRD)' + + + diff --git a/contributed_definitions/nyaml/NXxrd_pan.yaml b/contributed_definitions/nyaml/NXxrd_pan.yaml index d45a731f8b..4224be3b28 100644 --- a/contributed_definitions/nyaml/NXxrd_pan.yaml +++ b/contributed_definitions/nyaml/NXxrd_pan.yaml @@ -12,6 +12,7 @@ NXxrd_pan(NXxrd): Official NeXus NXDL schema to which this file conforms. enumeration: [NXxrd_pan] method: + enumeration: [X-Ray Diffraction (XRD] doc: | Method used to collect the data default='X-Ray Diffraction (XRD)' From 4e0593e684761ed33cee7421033c67898be4dd1a Mon Sep 17 00:00:00 2001 From: Rubel Date: Fri, 1 Dec 2023 11:47:22 +0100 Subject: [PATCH 0387/1012] mv NXxrd into application. --- {applications => contributed_definitions}/NXxrd.nxdl.xml | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename {applications => contributed_definitions}/NXxrd.nxdl.xml (100%) diff --git a/applications/NXxrd.nxdl.xml b/contributed_definitions/NXxrd.nxdl.xml similarity index 100% rename from applications/NXxrd.nxdl.xml rename to contributed_definitions/NXxrd.nxdl.xml From 370f66ced8045d2478e103fca348d0704dee3f14 Mon Sep 17 00:00:00 2001 From: Rubel Date: Fri, 1 Dec 2023 14:46:11 +0100 Subject: [PATCH 0388/1012] minor error. --- contributed_definitions/NXxrd_pan.nxdl.xml | 2 +- contributed_definitions/nyaml/NXxrd_pan.yaml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/NXxrd_pan.nxdl.xml b/contributed_definitions/NXxrd_pan.nxdl.xml index 9f4f655fa7..dfa50f3bc4 100644 --- a/contributed_definitions/NXxrd_pan.nxdl.xml +++ b/contributed_definitions/NXxrd_pan.nxdl.xml @@ -44,7 +44,7 @@ n_values - symbols default='X-Ray Diffraction (XRD)' - + diff --git a/contributed_definitions/nyaml/NXxrd_pan.yaml b/contributed_definitions/nyaml/NXxrd_pan.yaml index 4224be3b28..8314a7f160 100644 --- a/contributed_definitions/nyaml/NXxrd_pan.yaml +++ b/contributed_definitions/nyaml/NXxrd_pan.yaml @@ -12,7 +12,7 @@ NXxrd_pan(NXxrd): Official NeXus NXDL schema to which this file conforms. enumeration: [NXxrd_pan] method: - enumeration: [X-Ray Diffraction (XRD] + enumeration: [X-Ray Diffraction (XRD)] doc: | Method used to collect the data default='X-Ray Diffraction (XRD)' From 615ff37cbafd2ca017fb61c119c0f5c0cf052a34 Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Mon, 4 Dec 2023 09:26:22 +0100 Subject: [PATCH 0389/1012] Fixes typo in NXcalibration (#134) --- contributed_definitions/NXcalibration.nxdl.xml | 4 ++-- contributed_definitions/nyaml/NXcalibration.yaml | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml index 9a99d11165..205c83f7b8 100644 --- a/contributed_definitions/NXcalibration.nxdl.xml +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -157,13 +157,13 @@ For linear calibration. Scaling parameter. - This is should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. + This should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. For linear calibration. Offset parameter. - This is should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. + This should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. diff --git a/contributed_definitions/nyaml/NXcalibration.yaml b/contributed_definitions/nyaml/NXcalibration.yaml index 434cf2eec4..eae1c60c83 100644 --- a/contributed_definitions/nyaml/NXcalibration.yaml +++ b/contributed_definitions/nyaml/NXcalibration.yaml @@ -102,12 +102,12 @@ NXcalibration(NXobject): unit: NX_ANY doc: | For linear calibration. Scaling parameter. - This is should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. + This should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. offset(NX_FLOAT): unit: NX_ANY doc: | For linear calibration. Offset parameter. - This is should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. + This should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. MAPPING(NX_FLOAT): doc: | Mapping data for calibration. From 764093c2352962afac596f2a3138c19070a8d8c6 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 13 Dec 2023 13:20:56 +0100 Subject: [PATCH 0390/1012] Fixed missing references to EM/CGMS/ICME-related base classes in the documentation, adding first round of changes relevant for the implementation of the refactoring of the em-related readers in pynxtools --- contributed_definitions/NXem.nxdl.xml | 70 ++++++++------- contributed_definitions/NXem_base.nxdl.xml | 85 ++++++++++--------- contributed_definitions/NXserialized.nxdl.xml | 8 +- contributed_definitions/nyaml/NXem.yaml | 64 +++++++------- contributed_definitions/nyaml/NXem_base.yaml | 75 ++++++++-------- .../nyaml/NXserialized.yaml | 5 +- manual/source/cgms-structure.rst | 12 ++- .../cgms-structure.rst | 22 ++--- .../contributed_definitions/em-structure.rst | 68 +++++++++++---- 9 files changed, 223 insertions(+), 186 deletions(-) diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 317d5e44a5..7ec3563cec 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -73,35 +73,6 @@ a releasing of this default constraint is possible with writing exists:--> - - - A collection of all programs and libraries which are considered relevant - to understand with which software tools this NeXus file instance was - generated. Ideally, to enable a binary recreation from the input data. - - Examples include the name and version of the libraries used to write the - instance. Ideally, the software which writes these NXprogram instances - also includes the version of the set of NeXus classes i.e. the specific - set of base classes, application definitions, and contributed definitions - with which the here described concepts can be resolved. - - For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ - which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ - research data management system, it makes sense to store e.g. the GitHub - repository commit and respective submodule references used. - - - - - - The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) - which was used to generate this NeXus file instance. - - - @@ -109,6 +80,39 @@ where scientists just store conventions without a default plot--> + + + + The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) + which was used to generate this NeXus file instance. + + + + + A collection of all programs and libraries which are considered relevant + to understand with which software tools this NeXus file instance was + generated. Ideally, to enable a binary recreation from the input data. + + Examples include the name and version of the libraries used to write the + instance. Ideally, the software which writes these NXprogram instances + also includes the version of the set of NeXus classes i.e. the specific + set of base classes, application definitions, and contributed definitions + with which the here described concepts can be resolved. + + For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ + which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ + research data management system, it makes sense to store e.g. the GitHub + repository commit and respective submodule references used. + + + + + + + @@ -124,17 +128,11 @@ where scientists just store conventions without a default plot--> - - - - - - - + diff --git a/contributed_definitions/NXem_base.nxdl.xml b/contributed_definitions/NXem_base.nxdl.xml index 479819893b..e1add30bda 100644 --- a/contributed_definitions/NXem_base.nxdl.xml +++ b/contributed_definitions/NXem_base.nxdl.xml @@ -27,7 +27,7 @@ description on the NeXus front-page is overwhelming considering what we learned from the diataxis workshop we write here a specification neither a how to nor a tutorial which explains all the context because we address here developers of software--> - + @@ -48,34 +48,10 @@ template to be used for an application definition to explore physical mechanisms and phenomena, or the desire to characterize materials using electron microscopy. - - - A collection of all programs and libraries which are considered relevant - to understand with which software tools this NeXus file instance was - generated. Ideally, to enable a binary recreation from the input data. - - Examples include the name and version of the libraries used to write the - instance. Ideally, the software that writes these :ref:`NXprogram` instances - also includes the version of the set of NeXus classes i.e. the specific - set of base classes, application definitions, and contributed definitions - with which the here described concepts can be resolved. - - For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ - which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ - research data management system, it makes sense to store e.g. the GitHub - repository commit and respective submodule references used. - - - - - The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) - which was used to generate this NeXus file instance. - - @@ -91,6 +67,30 @@ where scientists just store conventions without a default plot--> + + + The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) + which was used to generate this NeXus file instance. + + + + A collection of all programs and libraries which are considered relevant + to understand with which software tools this NeXus file instance was + generated. Ideally, to enable a binary recreation from the input data. + + Examples include the name and version of the libraries used to write the + instance. Ideally, the software which writes these NXprogram instances + also includes the version of the set of NeXus classes i.e. the specific + set of base classes, application definitions, and contributed definitions + with which the here described concepts can be resolved. + + For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ + which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ + research data management system, it makes sense to store e.g. the GitHub + repository commit and respective submodule references used. + + + Ideally, a (globally) unique persistent identifier @@ -150,25 +150,26 @@ where scientists just store conventions without a default plot--> - - - The program and eventual software libraries used with which the - NeXus instance was created. For the NOMAD OASIS research data - management system e.g. pynxtools and eventually all modules - if desired. - - - - Possibility to store a collection of data artifacts - associated with the experiment. + Possibility to store a collection of serialized resources + that are associated with the experiment. + + An example how to use this set could be to document + from which files generated by software of technology partners + the information in an instance of NXem was filled. + + If resources from technology partners would also be documented + semantically annotated there would not even be a necessity to + copy over specific information in NeXus files as one could write + a inference and information/fact/knowledge retrieval algorithm whereby + a specific piece of information that is related to an experiment or simulation + is just read directly from the respective file of the technology partner. + + The reason why currently this works convincingly in hardly any research + data management system is the strong heterogeneity of the information contained + in such files and the fact that often context and documentation specifically + rich semantic documentation and contextualization is missing. diff --git a/contributed_definitions/NXserialized.nxdl.xml b/contributed_definitions/NXserialized.nxdl.xml index 50788ed914..2a8bc4697f 100644 --- a/contributed_definitions/NXserialized.nxdl.xml +++ b/contributed_definitions/NXserialized.nxdl.xml @@ -56,18 +56,16 @@ - Value of the checksum obtain when running algorithm on the resource. + Value of the hash that is obtained when running algorithm + on the content of the resource referred to by path. Name of the algorithm whereby the checksum was computed. - - - - + Extracted file containing the serialized information. diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index 7ce0b9b4d9..7aba5bf362 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -51,37 +51,40 @@ NXem(NXem_base): \@HDF5_Version(NX_CHAR): \@h5py_version(NX_CHAR): \@default(NX_CHAR): - (NXprogram): # understood by default as PROGRAM(NXprogram), i.e. program1, program2, ... - doc: | - A collection of all programs and libraries which are considered relevant - to understand with which software tools this NeXus file instance was - generated. Ideally, to enable a binary recreation from the input data. - - Examples include the name and version of the libraries used to write the - instance. Ideally, the software which writes these NXprogram instances - also includes the version of the set of NeXus classes i.e. the specific - set of base classes, application definitions, and contributed definitions - with which the here described concepts can be resolved. - - For the `pynxtools library `_ - which is used by the `NOMAD `_ - research data management system, it makes sense to store e.g. the GitHub - repository commit and respective submodule references used. - exists: [min, 0, max, infty] - # each NeXus file instance should have a default plot - # however as there are cases when this cannot be assured we cannot - # make the default required, one example is e.g. a NeXus instance - # where scientists just store conventions without a default plot - cs_profiling(NXcs_profiling): - doc: | - The configuration of the I/O writer software (e.g. `pynxtools `_) - which was used to generate this NeXus file instance. - command_line_call: (NXentry): # means ENTRY(NXentry) exists: [min, 1, max, infty] \@version(NX_CHAR): definition(NX_CHAR): enumeration: [NXem] + # each NeXus file instance should have a default plot + # however as there are cases when this cannot be assured we cannot + # make the default required, one example is e.g. a NeXus instance + # where scientists just store conventions without a default plot + cs_profiling(NXcs_profiling): + doc: | + The configuration of the I/O writer software (e.g. `pynxtools `_) + which was used to generate this NeXus file instance. + command_line_call(NX_CHAR): + (NXprogram): # understood by default as PROGRAM(NXprogram), i.e. program1, program2, ... + doc: | + A collection of all programs and libraries which are considered relevant + to understand with which software tools this NeXus file instance was + generated. Ideally, to enable a binary recreation from the input data. + + Examples include the name and version of the libraries used to write the + instance. Ideally, the software which writes these NXprogram instances + also includes the version of the set of NeXus classes i.e. the specific + set of base classes, application definitions, and contributed definitions + with which the here described concepts can be resolved. + + For the `pynxtools library `_ + which is used by the `NOMAD `_ + research data management system, it makes sense to store e.g. the GitHub + repository commit and respective submodule references used. + exists: [min, 0, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + # \@url: experiment_identifier(NXidentifier): exists: recommended service(NX_CHAR): @@ -91,23 +94,18 @@ NXem(NXem_base): doc: | Either an identifier or an alias that is human-friendly so that scientist find that experiment again - experiment_description(NX_CHAR): + experiment_description(NX_CHAR): # no docstring overwritten means accepting it as it is defined in NXem_base start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): exists: recommended (NXcite): exists: [min, 0, max, infty] - (NXprogram): # no docstring overwritten means accepting it as it is defined in NXem_base - exists: [min, 1, max, infty] - program(NX_CHAR): - \@version(NX_CHAR): - # \@url: (NXserialized): exists: [min, 0, max, infty] type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): - algoritm(NX_CHAR): + algorithm(NX_CHAR): (NXuser): exists: [min, 1, max, infty] name(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXem_base.yaml b/contributed_definitions/nyaml/NXem_base.yaml index 2de8081a8c..90461471fd 100644 --- a/contributed_definitions/nyaml/NXem_base.yaml +++ b/contributed_definitions/nyaml/NXem_base.yaml @@ -22,31 +22,11 @@ doc: | # specification neither a how to nor a tutorial which explains all the context # because we address here developers of software type: group -NXem_base(NXroot): - (NXprogram): - doc: | - A collection of all programs and libraries which are considered relevant - to understand with which software tools this NeXus file instance was - generated. Ideally, to enable a binary recreation from the input data. - - Examples include the name and version of the libraries used to write the - instance. Ideally, the software that writes these :ref:`NXprogram` instances - also includes the version of the set of NeXus classes i.e. the specific - set of base classes, application definitions, and contributed definitions - with which the here described concepts can be resolved. - - For the `pynxtools library `_ - which is used by the `NOMAD `_ - research data management system, it makes sense to store e.g. the GitHub - repository commit and respective submodule references used. +NXem_base(NXobject): # but should inherit from NXroot # each NeXus file instance should have a default plot # however as there are cases when this cannot be assured we cannot # make the default required, one example is e.g. a NeXus instance # where scientists just store conventions without a default plot - cs_profiling(NXcs_profiling): - doc: | - The configuration of the I/O writer software (e.g. `pynxtools `_) - which was used to generate this NeXus file instance. (NXentry): # means ENTRY(NXentry) \@version(NX_CHAR): doc: | @@ -56,6 +36,26 @@ NXem_base(NXroot): doc: | NeXus NXDL schema to which this file conforms. enumeration: [NXem] + cs_profiling(NXcs_profiling): + doc: | + The configuration of the I/O writer software (e.g. `pynxtools `_) + which was used to generate this NeXus file instance. + (NXprogram): # understood by default as PROGRAM(NXprogram), i.e. program1, program2, ... + doc: | + A collection of all programs and libraries which are considered relevant + to understand with which software tools this NeXus file instance was + generated. Ideally, to enable a binary recreation from the input data. + + Examples include the name and version of the libraries used to write the + instance. Ideally, the software which writes these NXprogram instances + also includes the version of the set of NeXus classes i.e. the specific + set of base classes, application definitions, and contributed definitions + with which the here described concepts can be resolved. + + For the `pynxtools library `_ + which is used by the `NOMAD `_ + research data management system, it makes sense to store e.g. the GitHub + repository commit and respective submodule references used. experiment_identifier(NXidentifier): doc: | Ideally, a (globally) unique persistent identifier @@ -107,23 +107,26 @@ NXem_base(NXroot): the microscope session ended. See docstring of the start_time field to see how the start_time and end_time should be used together. (NXcite): - (NXprogram): - doc: | - The program and eventual software libraries used with which the - NeXus instance was created. For the NOMAD OASIS research data - management system e.g. pynxtools and eventually all modules - if desired. - # the above-description overwrites the default description of the NXprogram base class - # this is composed from the NXprogram base class - # program: - # \@version: - # \@url: - # NXnote and thumbnail dropped for the reason that these are - # arbitrary binary containers without any clear provenance. (NXserialized): doc: | - Possibility to store a collection of data artifacts - associated with the experiment. + Possibility to store a collection of serialized resources + that are associated with the experiment. + + An example how to use this set could be to document + from which files generated by software of technology partners + the information in an instance of NXem was filled. + + If resources from technology partners would also be documented + semantically annotated there would not even be a necessity to + copy over specific information in NeXus files as one could write + a inference and information/fact/knowledge retrieval algorithm whereby + a specific piece of information that is related to an experiment or simulation + is just read directly from the respective file of the technology partner. + + The reason why currently this works convincingly in hardly any research + data management system is the strong heterogeneity of the information contained + in such files and the fact that often context and documentation specifically + rich semantic documentation and contextualization is missing. # using NXserialized here instead of NXnote as the former is more specific (NXuser): doc: | diff --git a/contributed_definitions/nyaml/NXserialized.yaml b/contributed_definitions/nyaml/NXserialized.yaml index 6aa90f4b45..9de627a9ac 100644 --- a/contributed_definitions/nyaml/NXserialized.yaml +++ b/contributed_definitions/nyaml/NXserialized.yaml @@ -27,11 +27,12 @@ NXserialized(NXobject): identifier to a resource in another database. checksum(NX_CHAR): doc: | - Value of the checksum obtain when running algorithm on the resource. + Value of the hash that is obtained when running algorithm + on the content of the resource referred to by path. algorithm(NX_CHAR): doc: | Name of the algorithm whereby the checksum was computed. - enumeration: [md5, sha256] + # enumeration: [md5, sha256] file(NXnote): doc: | Extracted file containing the serialized information. \ No newline at end of file diff --git a/manual/source/cgms-structure.rst b/manual/source/cgms-structure.rst index 4a4950933d..563479b17f 100644 --- a/manual/source/cgms-structure.rst +++ b/manual/source/cgms-structure.rst @@ -1,9 +1,13 @@ .. _Cg-Structure-Fairmat: -====================== -Computational geometry -====================== +============================ +Geometry and microstructures +============================ -Computational geometry is a frequently used tool for describing the shape and geometry of structural features in materials and components of instruments used for materials characterization. NeXus has a long history of base classes which serve these purposes. Upon closer inspection during the first year of the FAIRmat project, we found though that the collection of base classes could profit from an extension to make working with computational geometry data in NeXus simpler and more fine-grained. +Computational geometry is a frequently used tool for describing the shape and geometry of structural features in materials and components of instruments used for materials characterization. +NeXus has a long history of base classes which serve specifically the former tasks. Upon closer inspection during the first year of the FAIRmat project we found though that the collection of +base classes could profit from an extension to make working with computational geometry data in NeXus simpler and more fine-grained. A status report of this ongoing work is available here: :ref:`CgmsFeatures-Structure`. + +A status report of how these definitions can be of value for the field of Integrated Materials Engineering (ICME) is available here: :ref:`Icme-Structure`. diff --git a/manual/source/classes/contributed_definitions/cgms-structure.rst b/manual/source/classes/contributed_definitions/cgms-structure.rst index ad0872731f..7307e0810b 100644 --- a/manual/source/classes/contributed_definitions/cgms-structure.rst +++ b/manual/source/classes/contributed_definitions/cgms-structure.rst @@ -87,6 +87,9 @@ The following base classes are defined to incentivize the use of NeXus for using computational-geometry-based descriptions. In what follows, base classes for frequently used shapes and geometric primitives are proposed: + :ref:`NXcg_primitive_set`: + A base class to inherit from when defining base classes for specific primitives such as these: + :ref:`NXcg_sphere_set`: A base class for a set of possibly dissimilar spheres. @@ -222,17 +225,14 @@ input parameters and to summarize its performance statistics: :ref:`NXcs_computer`: A base class for documenting a computer. - :ref:`NXcs_cpu`: - A base class for documenting a central processing unit. - - :ref:`NXcs_gpu`: - A base class for documenting a graphical processing unit / accelerator. + :ref:`NXcs_cpu_sys`, :ref:`NXcs_cpu_obj`, :ref:`NXcs_cpu`: + Base classes for documenting a central processing unit. - :ref:`NXcs_mm_sys`: - A base class for documenting the (main) memory (sub-)system. + :ref:`NXcs_gpu_sys`, :ref:`NXcs_gpu_obj`, :ref:`NXcs_gpu`: + Base classes for documenting a graphical processing unit / accelerator. - :ref:`NXcs_io_sys`: - A base class for documenting the input/output system. + :ref:`NXcs_mm_sys`, :ref:`NXcs_mm_obj`: + Base classes for documenting the (main) memory (sub-)system. - :ref:`NXcs_io_obj`: - A base class for storing data inside an :ref:`NXcs_io_sys` instance. + :ref:`NXcs_io_sys`, :ref:`NXcs_io_obj`: + Base classes for documenting the input/output system. diff --git a/manual/source/classes/contributed_definitions/em-structure.rst b/manual/source/classes/contributed_definitions/em-structure.rst index 61aee37e08..93ca953da4 100644 --- a/manual/source/classes/contributed_definitions/em-structure.rst +++ b/manual/source/classes/contributed_definitions/em-structure.rst @@ -37,7 +37,10 @@ In summary, scientists place a specimen/sample into the microscope, calibrate th A microscope session ends with the scientist removing the specimen from the instrument or parking it so that the next user can start a session. Occasionally, service technicians perform calibrations and maintenance which also can be described as a session on the microscope. We have provided base classes to describe these steps and events and an application definition for electron microscopy: :ref:`NXem`: - An application definition which explores the possibilities of electron microscopes. + An application definition which explores the possibilities of electron microscopes. This application definition sets constraints on :ref:`NXem_base`. + + :ref:`NXem_base`: + A base class to serve as a blueprint for documenting research with electron microscopy (real microscope or simulated electron beam matter interaction). .. _EmBC: @@ -46,10 +49,23 @@ Base Classes The following base classes are proposed to support modularizing the storage of pieces of information related to electron microscopy research: - :ref:`NXaberration_model`, :ref:`NXaberration_model_ceos`, :ref:`NXaberration_model_nion`, :ref:`NXaberration`: + :ref:`NXem_msr`, :ref:`NXem_sim`: + Base classes to distinguish descriptions relevant for an experiment that is performed with a real microscope or a computer simulation of + electron matter interaction. Through these base classes NeXus supports to serialize details of a measurement and a related computer simulation + into one data artifact. + + :ref:`NXidentifier`, :ref:`NXserialized`: + Base classes to support storage of metadata whereby the source of information stored in a NeXus data artifact or class instances can be + documented especially when one does not store all relevant information using NeXus but one would like to refer to a specific other resource + where these pieces of information are stored. + + :ref:`NXaberration_model`, :ref:`NXaberration_model_ceos`, :ref:`NXaberration_model_nion`, :ref:`NXaberration`, :ref:`NXcorrector_cs`: Base classes to describe procedures and values for the calibration of aberrations based on conventions of different companies active in the field of aberration correction. + :ref:`NXcomponent_em`: + A base class to describe a hardware component for e.g. building a microscope. + :ref:`NXaperture_em`: A base class to describe an aperture. @@ -57,21 +73,24 @@ The following base classes are proposed to support modularizing the storage of p A base class to describe the chamber as a part of the microscope or storage unit for transferring specimens in between or within an instrument. - :ref:`NXcoordinate_system_set`: - A base class to describe different coordinate systems used and/or to be harmonized - or transformed into one another. + :ref:`NXcoordinate_system_set`, :ref:`NXcoordinate_system`, :ref:`NXtransformations`: + Base classes to describe different coordinate systems used and/or to be harmonized + or transformed into one another and respective transformations. :ref:`NXcorrector_cs`: A base class to describe details about corrective lens or compound lens devices which reduce the aberration of an electron beam. + :ref:`NXdeflector`: + A base class to describe a component to deflect a beam of charged particles. + :ref:`NXebeam_column`: A base class serving the possibility to group the components relevant for generating and shaping the electron beam. :ref:`NXevent_data_em`: - A base class representing a container to hold time-stamped and microscope-state- - annotated data during a session at an electron microscope. + A base class representing a container to hold time-stamped and microscope-state-annotated + data during a session at an electron microscope. :ref:`NXevent_data_em_set`: A base class to group all :ref:`NXevent_data_em` instances. @@ -80,8 +99,8 @@ The following base classes are proposed to support modularizing the storage of p A base class serving the possibility to group the components relevant for generating and shaping an ion beam of an instrument to offer focused-ion beam (milling) capabilities. - :ref:`NXimage_set`: - Base classes for storing acquisition details for individual images or stacks of images. Specialized versions can be defined. Each such uses controlled vocabulary terms for group name prefixes like **adf** annular dark field, **bf** bright field, **bse** backscattered electron, **chamber** camera to monitor the stage and chamber, **df** darkfield, **diffrac** diffraction, **ecci** electron channeling contrast imaging, **kikuchi** electron backscatter diffraction, **ronchigram** - convergent beam diffraction pattern, or **se** secondary electron. + :ref:`NXimage_set`, :ref:`NXimage_r_set`, :ref:`NXimage_c_set`, :ref:`NXimage_r_set_diff`: + Base classes for storing acquisition details for individual images or stacks of images. :ref:`NXinteraction_vol_em`: A base class to describe details about e.g. the assumed or simulated volume of interaction of the electrons with the specimen. @@ -110,10 +129,14 @@ The following base classes are proposed to support modularizing the storage of p A base class to represent the component of an electron microscope which realizes a controlled deflection (and eventually shift, blanking, and/or descanning) of the electron beam to illuminate the specimen in a controlled manner This base class can be used to document the scan pattern. The base class focuses mostly on the concept idea that there - is a component in a microscope which controls eventually multiple other components such as beam deflectors to achieve deflection. + is a component in a microscope which controls eventually multiple other components such as beam deflectors to achieve deflection + and thus a controlled scanning of the beam over the sample/specimen surface. + + :ref:`NXcircuit`, :ref:`NXcircuit_board`, :ref:`NXadc`, :ref: `NXdac`: + Base classes to describe integrated circuits (ICs). Further consolidation of these base classes is planned. :ref:`NXspectrum_set`: - A base class and specializations comparable to :ref:`NXimage_set` but for storing spectra. Specialized base classes should use including controlled vocabulary items as prefixes such as **eels** electron energy loss spectroscopy, **xray** X-ray spectroscopy (EDS/STEM, EDX, SEM/EDX, SEM/EDS), **auger** Auger spectroscopy, or **cathodolum** for cathodoluminescence spectra. + A base class and specializations comparable to :ref:`NXimage_set` but for storing spectra. :ref:`NXstage_lab`: A base class to describe the stage/specimen holder which offers place for the documentation of the small-scale laboratory functionalities @@ -124,17 +147,28 @@ The following base classes are proposed to support modularizing the storage of p We provide specific base classes which granularize frequently collected or analyzed quantities in specific application fields of electron microscopy to deal with the situation that there are cases were logical connections between generated data artifacts mainly exist for the fact that the data artifacts were -collected during a workflow of electron microscopy research (e.g. taking measurements and then performing method-specific analyses generating new data and conclusions). We see a value in granularizing out these pieces of information into own classes. In fact, one limitation of application definitions in NeXus is currently that they define a set of constraints on their graph of controlled concepts and terms. If we take for example diffraction experiments with an electron microscope, it is usually the case that (diffraction) patterns are collected in the session at the microscope. However, all scientifically relevant conclusions are typically drawn later, i.e. through post-processing the collected diffraction (raw) data. These numerical and algorithmic steps define computational workflows were data from an instance of an application definition such as NXem are used as input but many additional concepts and constraints are applied without these demanding necessarily for changing constraints on fields or groups of NXem. If we were to modify NXem for these cases, NXem would combinatorially diverge as every different combination of required constraints demands having an own but almost similar application definition. For this reason, the concept of partner application definition are currently used which have fields/links whereby specifically relevant sources of information are connected to e.g. NXem. +collected during a workflow of electron microscopy research (e.g. taking measurements and then performing method-specific analyses generating new data and conclusions). +We see a value in granularizing out these pieces of information into own classes. In fact, one limitation of application definitions in NeXus, exactly as it applies for serialization +of information also more generally, is currently that they define a set of constraints on their graph of controlled concepts and terms. + +If we take for example diffraction experiments performed with an electron microscope, it is usually the case that (diffraction) patterns are collected in the session at the microscope. +However, all scientifically relevant conclusions are typically drawn later, i.e. through post-processing the collected diffraction (raw) data. These numerical and algorithmic steps +define computational workflows were data from an instance of an application definition such as NXem are used as input but many additional concepts, constraints, and assumptions +are applied without that these demand necessarily changes in the constraints on fields or groups of NXem. If we were to modify NXem for these cases, +NXem would combinatorially diverge as every different combination of required constraints demands having an own but almost similar application definition. +For this reason, method-specific base classes are used which granularize out how specific pieces of information are processed further to eventually enable their +storage (i.e. serialization) using NeXus. More consolidation through the use of NXsubentry classes should be considered in the future. For now we use an approach whereby base classes are combined to reuse vocabulary and a hierarchical organization of pieces of information with specific constraints which are relevant only for specific usage of such data by specific tools used by an eventually smaller circle of users. - :ref:`NXem_ebsd`: - Application definition for collecting and indexing Kikuchi pattern into orientation maps for the two-dimensional, three- (serial sectioning) and four-dimensional (spatial and time-dependent) case. - -The definition of several new base classes is motivated by by NXem_ebsd: + :ref:`NXem_method`, :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eds`, :ref:`NXem_eels`, :ref:`NXem_img`, :ref:`NXem_correlation`: + Base classes with method-specific details especially when it comes to reporting post-processed data within electron microscopy. :ref:`NXem_conventions`, :ref:`NXem_conventions_ebsd`: A base class to store all reference frames and rotation conventions which are necessary to interpret the alignment and conventions used when working with orientation data. :ref:`NXcrystal_structure`: - A base class to store crystalline phase/structure used for a simulation of diffraction pattern and comparison of these pattern against patterns to support indexin. + A base class to store crystalline phase/structure used for a simulation of diffraction pattern and comparison of these pattern against patterns to support indexing. + + :ref:`NXroi`: + A base class to granularize information collected and relevant for the characterization of a region-of-interest. From 8a3ae1b95e9cd00853a7c0f5ada56d2694af3620 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 13 Dec 2023 16:38:08 +0100 Subject: [PATCH 0391/1012] Refactoring storage of images and spectra --- contributed_definitions/NXem.nxdl.xml | 204 +++++++++++++- contributed_definitions/NXem_adf.nxdl.xml | 2 +- contributed_definitions/NXem_eds.nxdl.xml | 81 ++++-- contributed_definitions/NXem_eels.nxdl.xml | 13 +- .../NXimage_c_set.nxdl.xml | 250 +++++++++++++++++- .../NXimage_r_set.nxdl.xml | 237 ++++++++++++++++- contributed_definitions/NXimage_set.nxdl.xml | 2 +- .../NXspectrum_set.nxdl.xml | 147 +++++++--- contributed_definitions/nyaml/NXem.yaml | 164 +++++++++++- contributed_definitions/nyaml/NXem_adf.yaml | 2 +- contributed_definitions/nyaml/NXem_eds.yaml | 62 ++++- contributed_definitions/nyaml/NXem_eels.yaml | 19 +- .../nyaml/NXimage_c_set.yaml | 168 ++++++++++-- .../nyaml/NXimage_r_set.yaml | 147 +++++++++- .../nyaml/NXimage_set.yaml | 2 +- .../nyaml/NXspectrum_set.yaml | 110 +++++--- dev_tools/tests/test_nxdl_utils.py | 6 +- 17 files changed, 1450 insertions(+), 166 deletions(-) diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 7ec3563cec..6fb28541bc 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -226,7 +226,55 @@ the fields they can be used--> - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -238,6 +286,44 @@ the fields they can be used--> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -256,7 +342,83 @@ the fields they can be used--> - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -278,7 +440,7 @@ the fields they can be used--> - + @@ -314,7 +476,23 @@ the fields they can be used--> - + + + + + + + + + + + + + + + + + @@ -333,17 +511,30 @@ the fields they can be used--> - + + + + + + + + + + + + + + @@ -390,8 +581,7 @@ is required to provide such information in this way!--> - diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_adf.nxdl.xml index 64534699cd..92e784ee31 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_adf.nxdl.xml @@ -50,7 +50,7 @@ For now the base class provides for scans for which the settings, binning, and energy resolution is the same for each scan point. - + Annulus inner (first value) and outer (second value) half angle. diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml index 735bfe8979..8550cbe816 100644 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -25,17 +25,10 @@ - - - - Number of pixel along the y direction, the slow direction - - - - - Number of pixel along the x direction, the fast direction - - + Number of X-ray photon energy (bins), the fastest direction. @@ -53,12 +46,19 @@ NEW ISSUE: make the binning flexible per scan point--> - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDXS). `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. + + X-ray spectroscopy is a surface-sensitive technique. Therefore, three-dimensional elemental + characterzation requires typically a sequence of characterization and preparation of the + surface to expose a new surface layer that can be characterized in the next acquisition. + In effect, the resulting three-dimensional elemental information mappings are truely the + result of a correlation and post-processing of several measurements which is the field + of correlative tomographic usage of electron microscopy. - The program with which the indexing was performed. + + + Accumulated intensity over all pixels of the region-of-interest. + + + + Accumulated counts + + + + + + + Counts + + + + + + Energy axis + + + + + + + Energy + + + + Name and location of each X-ray line which was indexed as a known ion. @@ -109,13 +140,18 @@ and Adrien Teutrie, Cecile Hebert (EPFL)--> - List of the names of identified elements. + Comma-separated list of names of identified elements. All members of + the list have to be valid chemical_symbols from the periodic table. + + This field can be used when creating instances of NXpeak is not desired. + However, a collection of instances of NXpeak with individual NXion specified + enables also to distinguish isotopic information. - + Individual element-specific EDS/EDX/EDXS/SXES mapping @@ -125,6 +161,12 @@ and Adrien Teutrie, Cecile Hebert (EPFL)--> These element-specific EDS maps are NXimage_r_set instances and need to be named with the name of the element from the element_names field. + + We often observe that signal contributions from several peaks + are summarized and shown together, e.g. the combined signal + under the curve of carbon and oxygen. + + In this case specify the processing details using peaks and weights. @@ -137,6 +179,13 @@ and Adrien Teutrie, Cecile Hebert (EPFL)--> + + + A list of weights by how much the intensity of each peak + under peaks was factorized to display the joint intensity + of the image. + + diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml index c355f6fd62..0b8b756bf9 100644 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -32,19 +32,14 @@ Base class method-specific for Electron Energy Loss Spectroscopy (EELS). - - + NXspectrum_set_em specialized for EELS. - - + + diff --git a/contributed_definitions/NXimage_c_set.nxdl.xml b/contributed_definitions/NXimage_c_set.nxdl.xml index 64c945c99e..ea711bbb89 100644 --- a/contributed_definitions/NXimage_c_set.nxdl.xml +++ b/contributed_definitions/NXimage_c_set.nxdl.xml @@ -72,9 +72,241 @@ NXprocess group which the NXimage_c_set base class can borrow from its NXimage_set parent base class process information are composable from the NXimage_set base class--> - + - Image stack. + One-dimensional image. + + + + Image intensity of the real part. + + + + + + + + Image intensity of the imaginary part. + + + + + + + + Magnitude of the image intensity. + + + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + + + Two-dimensional image. + + + + Image intensity of the real part. + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + + + Three-dimensional image. + + + + Image intensity of the real part. + + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + + Pixel coordinate center along k direction. + + + + + + + Coordinate along k direction. + + + + + + Pixel coordinate center along j direction. + + + + + + + Coordinate along j direction. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + + + Collection of one-dimensional images. + + + + Image intensity of the real part. + + + + + + + + + Image intensity of the imaginary part. + + + + + + + + + Magnitude of the image intensity. + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center along i direction. + + + + + + + Coordinate along i direction. + + + + + + + Collection of two-dimensional images. @@ -119,14 +351,6 @@ process information are composable from the NXimage_set base class--> - Pixel coordinate center along j direction. @@ -154,9 +378,9 @@ process information are composable from the NXimage_set base class--> - + - Image hyperstack. + Collection of three-dimensional images. @@ -213,7 +437,7 @@ process information are composable from the NXimage_set base class--> - Coordinate along j direction. + Coordinate along k direction. diff --git a/contributed_definitions/NXimage_r_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml index 3ef371809d..b57afc774a 100644 --- a/contributed_definitions/NXimage_r_set.nxdl.xml +++ b/contributed_definitions/NXimage_r_set.nxdl.xml @@ -28,6 +28,11 @@ Number of images in the stack. + + + Number of pixel per image in the slowest direction. + + Number of pixel per image in the slow direction. @@ -43,9 +48,169 @@ Specialized base class container for reporting a set of images in real space. - + + + One-dimensional image. + + + + Image intensity values. + + + + + + + + Pixel coordinate center along x direction. + + + + + + + Coordinate along x direction. + + + + + + + Two-dimensional image. + + + + Image intensity values. + + + + + + + + + Pixel coordinate center along y direction. + + + + + + + Coordinate along y direction. + + + + + + Pixel coordinate center along x direction. + + + + + + + Coordinate along x direction. + + + + + + + Three-dimensional image. + + + + Image intensity values. + + + + + + + + + + Pixel coordinate center along z direction. + + + + + + + Coordinate along z direction. + + + + + + Pixel coordinate center along y direction. + + + + + + + Coordinate along y direction. + + + + + + Pixel coordinate center along x direction. + + + + + + + Coordinate along x direction. + + + + + - Image (stack). + Collection of one-dimensional images. + + + + Image intensity values. + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center along x direction. + + + + + + + Coordinate along x direction. + + + + + + + Collection of two-dimensional images. @@ -97,4 +262,72 @@ + + + Collection of three-dimensional images. + + + + Image intensity values. + + + + + + + + + + + Image identifier + + + + + + + Image identifier. + + + + + + Pixel coordinate center along z direction. + + + + + + + Coordinate along z direction. + + + + + + Pixel coordinate center along y direction. + + + + + + + Coordinate along y direction. + + + + + + Pixel coordinate center along x direction. + + + + + + + Coordinate along x direction. + + + + diff --git a/contributed_definitions/NXimage_set.nxdl.xml b/contributed_definitions/NXimage_set.nxdl.xml index 9a46bcc64f..476b24d2ba 100644 --- a/contributed_definitions/NXimage_set.nxdl.xml +++ b/contributed_definitions/NXimage_set.nxdl.xml @@ -71,5 +71,5 @@ - + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml index aab6324743..62a86029ca 100644 --- a/contributed_definitions/NXspectrum_set.nxdl.xml +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -28,6 +28,11 @@ Number of scan points. + + + Number of pixel in the slowest direction. + + Number of pixel in the slow direction. @@ -46,6 +51,11 @@ Base class container for reporting a set of spectra. + + The mostly commonly used scanning methods are supported. + That is one-, two-, three-dimensional regularly sampled ROIs. + + For randomly or dissimilarly spaced scan points use collection instead. - + + + One spectrum for each pixel of an equidistantly + sampled one-dimensional ROI. + + + + Counts + + + + + + + + Counts + + + + + + Coordinate along x direction. + + + + + + + Pixel coordinate along x direction + + + + + + Energy axis + + + + + + + Energy + + + + + - Collected spectra for all pixels of a rectangular region-of-interest. - - This representation supports rectangular scan pattern with equidistant - energy bins. For randomly or dissimilarly spaced scan points - use collection instead. + One spectrum for each pixel of an equidistantly + sampled two-dimensional ROI. @@ -100,11 +153,6 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> - Coordinate along y direction. @@ -145,22 +193,20 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> - - + - Accumulated counts over all pixels of the region-of-interest. - This representation supports a rectangular scan pattern with - equidistant energy bins. + One spectrum for each voxel of an equidistantly + sampled three-dimensional ROI. - Accumulated counts + Counts - - + + + + + @@ -168,9 +214,45 @@ base classes--> - + + + Coordinate along z direction. + + + + + + + Pixel coordinate along z direction + + + + + + Coordinate along y direction. + + + + + + + Pixel coordinate along y direction + + + + + + Coordinate along x direction. + + + + + + + Pixel coordinate along x direction + + + Energy axis @@ -185,12 +267,15 @@ base classes--> + - Collected spectra for each scan point. - - This representation supports equidistant energy bins. - For rectangular sampling use stack and summary instead. + One spectrum for each scan point. This representation supports + equidistant energy bins. For rectangular sampling use respective + one-, two-, and three-dimensional variants instead. @@ -206,10 +291,6 @@ base classes--> - Scan point identifier diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index 7aba5bf362..fbb13db13d 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -199,7 +199,59 @@ NXem(NXem_base): checksum(NX_CHAR): algorithm(NX_CHAR): detector_identifier(NX_CHAR): - stack(NXdata): + image_oned(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_INT): + \@long_name(NX_CHAR): + title(NX_CHAR): + intensity(NX_NUMBER): + \@long_name(NX_CHAR): + axis_x(NX_NUMBER): + \@long_name(NX_CHAR): + image_twod(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_INT): + \@long_name(NX_CHAR): + title(NX_CHAR): + intensity(NX_NUMBER): + \@long_name(NX_CHAR): + axis_y(NX_NUMBER): + \@long_name(NX_CHAR): + axis_x(NX_NUMBER): + \@long_name(NX_CHAR): + image_threed(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_INT): + \@long_name(NX_CHAR): + title(NX_CHAR): + intensity(NX_NUMBER): + \@long_name(NX_CHAR): + axis_z(NX_NUMBER): + \@long_name(NX_CHAR): + axis_y(NX_NUMBER): + \@long_name(NX_CHAR): + axis_x(NX_NUMBER): + \@long_name(NX_CHAR): + stack_oned(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_INT): + \@long_name(NX_CHAR): + title(NX_CHAR): + intensity(NX_NUMBER): + \@long_name(NX_CHAR): + axis_image_identifier(NX_INT): + \@long_name(NX_CHAR): + axis_x(NX_NUMBER): + \@long_name(NX_CHAR): + stack_twod(NXdata): exists: optional \@signal(NX_CHAR): \@axes(NX_CHAR): @@ -214,6 +266,23 @@ NXem(NXem_base): \@long_name(NX_CHAR): axis_x(NX_NUMBER): \@long_name(NX_CHAR): + stack_threed(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_INT): + \@long_name(NX_CHAR): + title(NX_CHAR): + intensity(NX_NUMBER): + \@long_name(NX_CHAR): + axis_image_identifier(NX_INT): + \@long_name(NX_CHAR): + axis_z(NX_NUMBER): + \@long_name(NX_CHAR): + axis_y(NX_NUMBER): + \@long_name(NX_CHAR): + axis_x(NX_NUMBER): + \@long_name(NX_CHAR): (NXimage_c_set): exists: [min, 0, max, infty] (NXprocess): @@ -224,7 +293,67 @@ NXem(NXem_base): checksum(NX_CHAR): algorithm(NX_CHAR): detector_identifier(NX_CHAR): - stack(NXdata): + image_oned(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_CHAR): + \@long_name(NX_CHAR): + title: + real(NX_NUMBER): + \@long_name(NX_CHAR): + imag(NX_NUMBER): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + image_twod(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_CHAR): + \@long_name(NX_CHAR): + title: + real(NX_NUMBER): + \@long_name(NX_CHAR): + imag(NX_NUMBER): + \@long_name(NX_CHAR): + axis_j(NX_NUMBER): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + image_threed(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_CHAR): + \@long_name(NX_CHAR): + title: + real(NX_NUMBER): + \@long_name(NX_CHAR): + imag(NX_NUMBER): + \@long_name(NX_CHAR): + axis_k(NX_NUMBER): + \@long_name(NX_CHAR): + axis_j(NX_NUMBER): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + stack_oned(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_CHAR): + \@long_name(NX_CHAR): + title: + real(NX_NUMBER): + \@long_name(NX_CHAR): + imag(NX_NUMBER): + \@long_name(NX_CHAR): + axis_image_identifier(NX_INT): + \@long_name(NX_CHAR): + axis_i(NX_NUMBER): + \@long_name(NX_CHAR): + stack_twod(NXdata): exists: optional \@signal(NX_CHAR): \@axes(NX_CHAR): @@ -241,7 +370,7 @@ NXem(NXem_base): \@long_name(NX_CHAR): axis_i(NX_NUMBER): \@long_name(NX_CHAR): - hyperstack(NXdata): + stack_threed(NXdata): exists: optional \@signal(NX_CHAR): \@axes(NX_CHAR): @@ -270,7 +399,20 @@ NXem(NXem_base): checksum(NX_CHAR): algorithm(NX_CHAR): detector_identifier(NX_CHAR): - stack(NXdata): + spectrum_oned(NXdata): + exists: optional + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_INT): + \@long_name(NX_CHAR): + title(NX_CHAR): + intensity(NX_NUMBER): + \@long_name(NX_CHAR): + axis_x(NX_NUMBER): + \@long_name(NX_CHAR): + axis_energy(NX_NUMBER): + \@long_name(NX_CHAR): + spectrum_twod(NXdata): exists: optional \@signal(NX_CHAR): \@axes(NX_CHAR): @@ -285,15 +427,24 @@ NXem(NXem_base): \@long_name(NX_CHAR): axis_energy(NX_NUMBER): \@long_name(NX_CHAR): - summary(NXdata): - exists: recommended + spectrum_threed(NXdata): + exists: optional \@signal(NX_CHAR): \@axes(NX_CHAR): \@AXISNAME_indices(NX_INT): \@long_name(NX_CHAR): title(NX_CHAR): + intensity(NX_NUMBER): + \@long_name(NX_CHAR): + axis_z(NX_NUMBER): + \@long_name(NX_CHAR): + axis_y(NX_NUMBER): + \@long_name(NX_CHAR): + axis_x(NX_NUMBER): + \@long_name(NX_CHAR): axis_energy(NX_NUMBER): \@long_name(NX_CHAR): + # collection(NXdata): em_lab(NXinstrument): (NXebeam_column): electron_source(NXsource): @@ -340,7 +491,6 @@ NXem(NXem_base): # remains to be discussed based on examples eels(NXem_eels): exists: optional - # remains to be discussed based on examples # cl(NXem_cl): # exists: optional correlation(NXem_correlation): diff --git a/contributed_definitions/nyaml/NXem_adf.yaml b/contributed_definitions/nyaml/NXem_adf.yaml index b7011639e5..02a21e52cb 100644 --- a/contributed_definitions/nyaml/NXem_adf.yaml +++ b/contributed_definitions/nyaml/NXem_adf.yaml @@ -18,7 +18,7 @@ symbols: Number of pixel per image in the fast direction. type: group NXem_adf(NXem_method): - IMAGE_R_SET(NXimage_r_set): + (NXimage_r_set): half_angle_interval(NX_NUMBER): doc: | Annulus inner (first value) and outer (second value) half angle. diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml index 9a5a97fcd0..06148a0186 100644 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -1,17 +1,22 @@ category: base doc: | - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). + Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDXS). `IUPAC instead of Siegbahn notation `_ should be used. - + + X-ray spectroscopy is a surface-sensitive technique. Therefore, three-dimensional elemental + characterzation requires typically a sequence of characterization and preparation of the + surface to expose a new surface layer that can be characterized in the next acquisition. + In effect, the resulting three-dimensional elemental information mappings are truely the + result of a correlation and post-processing of several measurements which is the field + of correlative tomographic usage of electron microscopy. # NEW ISSUE: use computational geometry to offer arbitrary scan pattern # NEW ISSUE: make the binning flexible per scan point symbols: # n_p: Number of scan points - n_y: | - Number of pixel along the y direction, the slow direction - n_x: | - Number of pixel along the x direction, the fast direction + # n_z: Number of pixel along the z direction, the slowest direction + # n_y: Number of pixel along the y direction, the slow direction + # n_x: Number of pixel along the x direction, the fast direction n_photon_energy: | Number of X-ray photon energy (bins), the fastest direction. n_elements: | @@ -20,8 +25,8 @@ symbols: Number of peaks detected type: group NXem_eds(NXem_method): - # NXprocess is composed from NXem_method base class - # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class + # NXprocess is composed from NXem_method base class instances where the spectra + # are stored as instances of (NXspectrum_set) is composed from NXem_method base class # for post-processing of/with the above-defined data entries # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), @@ -32,6 +37,25 @@ NXem_eds(NXem_method): (NXprogram): doc: | The program with which the indexing was performed. + summary(NXdata): + doc: | + Accumulated intensity over all pixels of the region-of-interest. + intensity(NX_NUMBER): + doc: | + Accumulated counts + unit: NX_UNITLESS + dim: (n_photon_energy,) + \@long_name(NX_CHAR): + doc: | + Counts + axis_energy(NX_NUMBER): + doc: | + Energy axis + unit: NX_ENERGY + dim: (n_photon_energy,) + \@long_name(NX_CHAR): + doc: | + Energy PEAK(NXpeak): doc: | Name and location of each X-ray line which was indexed as a known ion. @@ -58,9 +82,14 @@ NXem_eds(NXem_method): dim: (i,) element_names(NX_CHAR): doc: | - List of the names of identified elements. + Comma-separated list of names of identified elements. All members of + the list have to be valid chemical_symbols from the periodic table. + + This field can be used when creating instances of NXpeak is not desired. + However, a collection of instances of NXpeak with individual NXion specified + enables also to distinguish isotopic information. dim: (n_elements,) - IMAGE_R_SET(NXimage_r_set): + (NXimage_r_set): doc: | Individual element-specific EDS/EDX/EDXS/SXES mapping @@ -70,6 +99,13 @@ NXem_eds(NXem_method): These element-specific EDS maps are NXimage_r_set instances and need to be named with the name of the element from the element_names field. + + We often observe that signal contributions from several peaks + are summarized and shown together, e.g. the combined signal + under the curve of carbon and oxygen. + + In this case specify the processing details using peaks and weights. + (NXprocess): peaks(NX_CHAR): doc: | @@ -77,4 +113,10 @@ NXem_eds(NXem_method): where accumulated for each pixel which yields an element-specific EDS map. dim: (n_peaks,) + weights(NX_NUMBER): + doc: | + A list of weights by how much the intensity of each peak + under peaks was factorized to display the joint intensity + of the image. + unit: NX_UNITLESS # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml index 4e5c69fe4a..89b9109bcb 100644 --- a/contributed_definitions/nyaml/NXem_eels.yaml +++ b/contributed_definitions/nyaml/NXem_eels.yaml @@ -6,24 +6,27 @@ symbols: Number of electron energy loss bins. type: group NXem_eels(NXem_method): - # NXem_method can offers to keep a SPECTRUM_SET # NXem_method also has an NXprocess which in this base class can be # specialized to include EELS-specific post-processing - SPECTRUM_SET(NXspectrum_set): + (NXspectrum_set): doc: | NXspectrum_set_em specialized for EELS. - stack(NXdata): - # \@signal: data_counts - # \@axes: [axis_y, axis_x, axis_energy_loss] - # \@energy_loss_indices: 2 - # \@axis_x_indices: 1 - # \@axis_y_indices: 0 + # \@signal:, \@axes: \@energy_loss_indices \@axis_x_indices: + stack_oned(NXdata): + axis_energy_loss(NX_NUMBER): + unit: NX_ENERGY + dim: (n_energy_loss,) + \@long_name(NX_CHAR): + doc: | + Energy loss. + stack_oned(NXdata): axis_energy_loss(NX_NUMBER): unit: NX_ENERGY dim: (n_energy_loss,) \@long_name(NX_CHAR): doc: | Energy loss. + summary(NXdata): # \@signal: data_counts # \@axes: [axis_energy_loss] diff --git a/contributed_definitions/nyaml/NXimage_c_set.yaml b/contributed_definitions/nyaml/NXimage_c_set.yaml index 8dcd85706d..303017ab1f 100644 --- a/contributed_definitions/nyaml/NXimage_c_set.yaml +++ b/contributed_definitions/nyaml/NXimage_c_set.yaml @@ -37,9 +37,149 @@ NXimage_c_set(NXimage_set): # NXprocess group which the NXimage_c_set base class can borrow from its # NXimage_set parent base class # process information are composable from the NXimage_set base class - stack(NXdata): + image_oned(NXdata): doc: | - Image stack. + One-dimensional image. + real(NX_NUMBER): + doc: | + Image intensity of the real part. + unit: NX_UNITLESS + dim: (n_i,) + imag(NX_NUMBER): + doc: | + Image intensity of the imaginary part. + unit: NX_UNITLESS + dim: (n_i,) + magnitude(NX_NUMBER): + doc: | + Magnitude of the image intensity. + unit: NX_UNITLESS + dim: (n_i) + axis_i(NX_NUMBER): + doc: | + Pixel coordinate center along i direction. + unit: NX_ANY # NX_RECIPROCAL_LENGTH + dim: (n_i,) + \@long_name(NX_CHAR): + doc: | + Coordinate along i direction. + + image_twod(NXdata): + doc: | + Two-dimensional image. + real(NX_NUMBER): + doc: | + Image intensity of the real part. + unit: NX_UNITLESS + dim: (n_j, n_i) + imag(NX_NUMBER): + doc: | + Image intensity of the imaginary part. + unit: NX_UNITLESS + dim: (n_j, n_i) + magnitude(NX_NUMBER): + doc: | + Magnitude of the image intensity. + unit: NX_UNITLESS + dim: (n_j, n_i) + axis_j(NX_NUMBER): + doc: | + Pixel coordinate center along j direction. + unit: NX_ANY # NX_RECIPROCAL_LENGTH + dim: (n_j,) + \@long_name(NX_CHAR): + doc: | + Coordinate along j direction. + axis_i(NX_NUMBER): + doc: | + Pixel coordinate center along i direction. + unit: NX_ANY # NX_RECIPROCAL_LENGTH + dim: (n_i,) + \@long_name(NX_CHAR): + doc: | + Coordinate along i direction. + + image_threed(NXdata): + doc: | + Three-dimensional image. + real(NX_NUMBER): + doc: | + Image intensity of the real part. + unit: NX_UNITLESS + dim: (n_k, n_j, n_i) + imag(NX_NUMBER): + doc: | + Image intensity of the imaginary part. + unit: NX_UNITLESS + dim: (n_k, n_j, n_i) + magnitude(NX_NUMBER): + doc: | + Magnitude of the image intensity. + unit: NX_UNITLESS + dim: (n_k, n_j, n_i) + axis_k(NX_NUMBER): + doc: | + Pixel coordinate center along k direction. + unit: NX_ANY # NX_RECIPROCAL_LENGTH + dim: (n_k,) + \@long_name(NX_CHAR): + doc: | + Coordinate along k direction. + axis_j(NX_NUMBER): + doc: | + Pixel coordinate center along j direction. + unit: NX_ANY + dim: (n_j,) + \@long_name(NX_CHAR): + doc: | + Coordinate along j direction. + axis_i(NX_NUMBER): + doc: | + Pixel coordinate center along i direction. + unit: NX_ANY + dim: (n_i,) + \@long_name(NX_CHAR): + doc: | + Coordinate along i direction. + + stack_oned(NXdata): + doc: | + Collection of one-dimensional images. + real(NX_NUMBER): + doc: | + Image intensity of the real part. + unit: NX_UNITLESS + dim: (n_images, n_i) + imag(NX_NUMBER): + doc: | + Image intensity of the imaginary part. + unit: NX_UNITLESS + dim: (n_images, n_i) + magnitude(NX_NUMBER): + doc: | + Magnitude of the image intensity. + unit: NX_UNITLESS + dim: (n_images, n_i) + axis_image_identifier(NX_INT): + doc: | + Image identifier + unit: NX_UNITLESS + dim: (n_images,) + \@long_name(NX_CHAR): + doc: | + Image identifier. + axis_i(NX_NUMBER): + doc: | + Pixel coordinate center along i direction. + unit: NX_ANY + dim: (n_i,) + \@long_name(NX_CHAR): + doc: | + Coordinate along i direction. + + stack_twod(NXdata): + doc: | + Collection of two-dimensional images. real(NX_NUMBER): doc: | Image intensity of the real part. @@ -63,18 +203,10 @@ NXimage_c_set(NXimage_set): \@long_name(NX_CHAR): doc: | Image identifier. - # axis_k(NX_NUMBER): - # doc: | - # Pixel coordinate center along k direction. - # unit: NX_ANY # NX_RECIPROCAL_LENGTH - # dim: (n_k,) - # \@long_name(NX_CHAR): - # doc: | - # Coordinate along j direction. axis_j(NX_NUMBER): doc: | Pixel coordinate center along j direction. - unit: NX_ANY # NX_RECIPROCAL_LENGTH + unit: NX_ANY dim: (n_j,) \@long_name(NX_CHAR): doc: | @@ -82,15 +214,15 @@ NXimage_c_set(NXimage_set): axis_i(NX_NUMBER): doc: | Pixel coordinate center along i direction. - unit: NX_ANY # NX_RECIPROCAL_LENGTH + unit: NX_ANY dim: (n_i,) \@long_name(NX_CHAR): doc: | Coordinate along i direction. - hyperstack(NXdata): + stack_threed(NXdata): doc: | - Image hyperstack. + Collection of three-dimensional images. real(NX_NUMBER): doc: | Image intensity of the real part. @@ -117,15 +249,15 @@ NXimage_c_set(NXimage_set): axis_k(NX_NUMBER): doc: | Pixel coordinate center along k direction. - unit: NX_ANY # NX_RECIPROCAL_LENGTH + unit: NX_ANY dim: (n_k,) \@long_name(NX_CHAR): doc: | - Coordinate along j direction. + Coordinate along k direction. axis_j(NX_NUMBER): doc: | Pixel coordinate center along j direction. - unit: NX_ANY # NX_RECIPROCAL_LENGTH + unit: NX_ANY dim: (n_j,) \@long_name(NX_CHAR): doc: | @@ -133,7 +265,7 @@ NXimage_c_set(NXimage_set): axis_i(NX_NUMBER): doc: | Pixel coordinate center along i direction. - unit: NX_ANY # NX_RECIPROCAL_LENGTH + unit: NX_ANY dim: (n_i,) \@long_name(NX_CHAR): doc: | diff --git a/contributed_definitions/nyaml/NXimage_r_set.yaml b/contributed_definitions/nyaml/NXimage_r_set.yaml index f0437e6e6f..5c63988c65 100644 --- a/contributed_definitions/nyaml/NXimage_r_set.yaml +++ b/contributed_definitions/nyaml/NXimage_r_set.yaml @@ -4,6 +4,8 @@ doc: | symbols: n_images: | Number of images in the stack. + n_z: | + Number of pixel per image in the slowest direction. n_y: | Number of pixel per image in the slow direction. n_x: | @@ -11,9 +13,109 @@ symbols: type: group NXimage_r_set(NXimage_set): # process information are composable from the NXimage_set base class - stack(NXdata): + image_oned(NXdata): doc: | - Image (stack). + One-dimensional image. + intensity(NX_NUMBER): + doc: | + Image intensity values. + unit: NX_UNITLESS + dim: (n_x,) + axis_x(NX_NUMBER): + doc: | + Pixel coordinate center along x direction. + unit: NX_LENGTH + dim: (n_x,) + \@long_name(NX_CHAR): + doc: | + Coordinate along x direction. + + image_twod(NXdata): + doc: | + Two-dimensional image. + intensity(NX_NUMBER): + doc: | + Image intensity values. + unit: NX_UNITLESS + dim: (n_y, n_x) + axis_y(NX_NUMBER): + doc: | + Pixel coordinate center along y direction. + unit: NX_LENGTH + dim: (n_y,) + \@long_name(NX_CHAR): + doc: | + Coordinate along y direction. + axis_x(NX_NUMBER): + doc: | + Pixel coordinate center along x direction. + unit: NX_LENGTH + dim: (n_x,) + \@long_name(NX_CHAR): + doc: | + Coordinate along x direction. + + image_threed(NXdata): + doc: | + Three-dimensional image. + intensity(NX_NUMBER): + doc: | + Image intensity values. + unit: NX_UNITLESS + dim: (n_z, n_y, n_x) + axis_z(NX_NUMBER): + doc: | + Pixel coordinate center along z direction. + unit: NX_LENGTH + dim: (n_z,) + \@long_name(NX_CHAR): + doc: | + Coordinate along z direction. + axis_y(NX_NUMBER): + doc: | + Pixel coordinate center along y direction. + unit: NX_LENGTH + dim: (n_y,) + \@long_name(NX_CHAR): + doc: | + Coordinate along y direction. + axis_x(NX_NUMBER): + doc: | + Pixel coordinate center along x direction. + unit: NX_LENGTH + dim: (n_x,) + \@long_name(NX_CHAR): + doc: | + Coordinate along x direction. + + stack_oned(NXdata): + doc: | + Collection of one-dimensional images. + intensity(NX_NUMBER): + doc: | + Image intensity values. + unit: NX_UNITLESS + dim: (n_images, n_x) + axis_image_identifier(NX_INT): + doc: | + Image identifier + unit: NX_UNITLESS + dim: (n_images,) + \@long_name(NX_CHAR): + doc: | + Image identifier. + axis_x(NX_NUMBER): + doc: | + Pixel coordinate center along x direction. + unit: NX_LENGTH + dim: (n_x,) + \@long_name(NX_CHAR): + doc: | + Coordinate along x direction. + + stack_twod(NXdata): + doc: | + Collection of two-dimensional images. intensity(NX_NUMBER): doc: | Image intensity values. @@ -43,3 +145,44 @@ NXimage_r_set(NXimage_set): \@long_name(NX_CHAR): doc: | Coordinate along x direction. + + stack_threed(NXdata): + doc: | + Collection of three-dimensional images. + intensity(NX_NUMBER): + doc: | + Image intensity values. + unit: NX_UNITLESS + dim: (n_images, n_z, n_y, n_x) + axis_image_identifier(NX_INT): + doc: | + Image identifier + unit: NX_UNITLESS + dim: (n_images,) + \@long_name(NX_CHAR): + doc: | + Image identifier. + axis_z(NX_NUMBER): + doc: | + Pixel coordinate center along z direction. + unit: NX_LENGTH + dim: (n_z,) + \@long_name(NX_CHAR): + doc: | + Coordinate along z direction. + axis_y(NX_NUMBER): + doc: | + Pixel coordinate center along y direction. + unit: NX_LENGTH + dim: (n_y,) + \@long_name(NX_CHAR): + doc: | + Coordinate along y direction. + axis_x(NX_NUMBER): + doc: | + Pixel coordinate center along x direction. + unit: NX_LENGTH + dim: (n_x,) + \@long_name(NX_CHAR): + doc: | + Coordinate along x direction. diff --git a/contributed_definitions/nyaml/NXimage_set.yaml b/contributed_definitions/nyaml/NXimage_set.yaml index 0bedd8d19c..91e40434d9 100644 --- a/contributed_definitions/nyaml/NXimage_set.yaml +++ b/contributed_definitions/nyaml/NXimage_set.yaml @@ -30,4 +30,4 @@ NXimage_set(NXobject): doc: | Link or name of an :ref:`NXdetector` instance with which the data were collected. (NXprogram): - (NXdata): + # (NXdata): diff --git a/contributed_definitions/nyaml/NXspectrum_set.yaml b/contributed_definitions/nyaml/NXspectrum_set.yaml index 5cbc597b61..b8f94774b2 100644 --- a/contributed_definitions/nyaml/NXspectrum_set.yaml +++ b/contributed_definitions/nyaml/NXspectrum_set.yaml @@ -1,9 +1,16 @@ category: base doc: | Base class container for reporting a set of spectra. + + The mostly commonly used scanning methods are supported. + That is one-, two-, three-dimensional regularly sampled ROIs. + + For randomly or dissimilarly spaced scan points use collection instead. symbols: n_p: | Number of scan points. + n_z: | + Number of pixel in the slowest direction. n_y: | Number of pixel in the slow direction. n_x: | @@ -33,13 +40,39 @@ NXspectrum_set(NXobject): (NXprogram): ##MK::feel free to contact us when you would like to include # lik omega/q mapping more complicated scan pattern than rectangular ones. - stack(NXdata): + spectrum_oned(NXdata): + doc: | + One spectrum for each pixel of an equidistantly + sampled one-dimensional ROI. + intensity(NX_NUMBER): + doc: | + Counts + unit: NX_UNITLESS + dim: (n_x, n_energy) + \@long_name(NX_CHAR): + doc: | + Counts + axis_x(NX_NUMBER): + doc: | + Coordinate along x direction. + unit: NX_LENGTH + dim: (n_x,) + \@long_name(NX_CHAR): + doc: | + Pixel coordinate along x direction + axis_energy(NX_NUMBER): + doc: | + Energy axis + unit: NX_ENERGY + dim: (n_energy,) + \@long_name(NX_CHAR): + doc: | + Energy + + spectrum_twod(NXdata): doc: | - Collected spectra for all pixels of a rectangular region-of-interest. - - This representation supports rectangular scan pattern with equidistant - energy bins. For randomly or dissimilarly spaced scan points - use collection instead. + One spectrum for each pixel of an equidistantly + sampled two-dimensional ROI. intensity(NX_NUMBER): doc: | Counts @@ -48,11 +81,6 @@ NXspectrum_set(NXobject): \@long_name(NX_CHAR): doc: | Counts - # \@signal: counts - # \@axes: [ypos, xpos, energy] - # \@ypos_indices: 0 - # \@xpos_indices: 1 - # \@energy_indices: 2 axis_y(NX_NUMBER): doc: | Coordinate along y direction. @@ -77,27 +105,43 @@ NXspectrum_set(NXobject): \@long_name(NX_CHAR): doc: | Energy - - # in the majority of cases rectangular or line scans are performed - # if there is interest to support arbitrary scan pattern one should use - # scan points and contact us to generalize this base class and related - # base classes - summary(NXdata): + + spectrum_threed(NXdata): doc: | - Accumulated counts over all pixels of the region-of-interest. - This representation supports a rectangular scan pattern with - equidistant energy bins. + One spectrum for each voxel of an equidistantly + sampled three-dimensional ROI. intensity(NX_NUMBER): doc: | - Accumulated counts + Counts unit: NX_UNITLESS - dim: (n_energy,) + dim: (n_z, n_y, n_x, n_energy) \@long_name(NX_CHAR): doc: | Counts - # \@signal: counts - # \@axes: [energy] - # \@energy_indices: 0 + axis_z(NX_NUMBER): + doc: | + Coordinate along z direction. + unit: NX_LENGTH + dim: (n_z,) + \@long_name(NX_CHAR): + doc: | + Pixel coordinate along z direction + axis_y(NX_NUMBER): + doc: | + Coordinate along y direction. + unit: NX_LENGTH + dim: (n_y,) + \@long_name(NX_CHAR): + doc: | + Pixel coordinate along y direction + axis_x(NX_NUMBER): + doc: | + Coordinate along x direction. + unit: NX_LENGTH + dim: (n_x,) + \@long_name(NX_CHAR): + doc: | + Pixel coordinate along x direction axis_energy(NX_NUMBER): doc: | Energy axis @@ -106,13 +150,15 @@ NXspectrum_set(NXobject): \@long_name(NX_CHAR): doc: | Energy - + # in the majority of cases rectangular or line scans are performed + # if there is interest to support arbitrary scan pattern one should use + # scan points and contact us to generalize this base class and related + # base classes collection(NXdata): doc: | - Collected spectra for each scan point. - - This representation supports equidistant energy bins. - For rectangular sampling use stack and summary instead. + One spectrum for each scan point. This representation supports + equidistant energy bins. For rectangular sampling use respective + one-, two-, and three-dimensional variants instead. intensity(NX_NUMBER): doc: | Counts @@ -121,10 +167,6 @@ NXspectrum_set(NXobject): \@long_name(NX_CHAR): doc: | Counts - # \@signal: counts - # \@axes: [scan_point_id, energy] - # \@scan_point_indices: 1 - # \@energy_indices: 0 axis_scan_point_id(NX_INT): doc: | Scan point identifier diff --git a/dev_tools/tests/test_nxdl_utils.py b/dev_tools/tests/test_nxdl_utils.py index 07e968cbda..a643c38e97 100644 --- a/dev_tools/tests/test_nxdl_utils.py +++ b/dev_tools/tests/test_nxdl_utils.py @@ -78,19 +78,19 @@ def test_get_node_at_nxdl_path(): assert node.attrib["type"] == "NXem_msr" node = nexus.get_node_at_nxdl_path( - "/ENTRY/measurement/EVENT_DATA_EM_SET/EVENT_DATA_EM/IMAGE_C_SET/hyperstack", + "/ENTRY/measurement/EVENT_DATA_EM_SET/EVENT_DATA_EM/IMAGE_C_SET/image_threed", elem=elem, ) assert node.attrib["type"] == "NXdata" node = nexus.get_node_at_nxdl_path( - "/ENTRY/measurement/EVENT_DATA_EM_SET/EVENT_DATA_EM/IMAGE_C_SET/hyperstack/AXISNAME_indices", + "/ENTRY/measurement/EVENT_DATA_EM_SET/EVENT_DATA_EM/IMAGE_C_SET/image_threed/AXISNAME_indices", elem=elem, ) assert node.attrib["name"] == "AXISNAME_indices" node = nexus.get_node_at_nxdl_path( - "/ENTRY/measurement/EVENT_DATA_EM_SET/EVENT_DATA_EM/IMAGE_C_SET/stack/axis_j", + "/ENTRY/measurement/EVENT_DATA_EM_SET/EVENT_DATA_EM/IMAGE_C_SET/image_threed/axis_j", elem=elem, ) assert node.attrib["type"] == "NX_NUMBER" From 6663bec4cbe6dd2d9c55be4ae4d9be3f54f13578 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 13 Dec 2023 16:46:49 +0100 Subject: [PATCH 0392/1012] Minor edit --- contributed_definitions/NXem_eds.nxdl.xml | 2 +- contributed_definitions/nyaml/NXem_eds.yaml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml index 8550cbe816..90b9262947 100644 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -103,7 +103,7 @@ and Adrien Teutrie, Cecile Hebert (EPFL)--> - + Name and location of each X-ray line which was indexed as a known ion. For each ion, an NXion instance should be created which specifies diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml index 06148a0186..60f9aa61b4 100644 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ b/contributed_definitions/nyaml/NXem_eds.yaml @@ -56,7 +56,7 @@ NXem_eds(NXem_method): \@long_name(NX_CHAR): doc: | Energy - PEAK(NXpeak): + (NXpeak): doc: | Name and location of each X-ray line which was indexed as a known ion. For each ion, an NXion instance should be created which specifies From f7ed4b04ca8ae540027800d8025e755db2ef51bd Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 19 Dec 2023 14:22:50 +0100 Subject: [PATCH 0393/1012] readd lost fields in NXmpes/NXsample --- contributed_definitions/nyaml/NXmpes.yaml | 106 +++++++++++++++------- 1 file changed, 74 insertions(+), 32 deletions(-) diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 2541df91ec..470a8f1c81 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -337,11 +337,11 @@ NXmpes(NXobject): type: exists: recommended value(NX_FLOAT): - exists: recommended - unit: NX_CURRENT - doc: | - In the case of a fixed current, this is the scalar drain current of the sample - and sample holder. + exists: recommended + unit: NX_CURRENT + doc: | + In the case of a fixed current, this is the scalar drain current of the sample + and sample holder. value_log(NXlog): exists: optional unit: NX_CURRENT @@ -401,8 +401,6 @@ NXmpes(NXobject): enumeration: [current] type: exists: recommended - type: - exists: recommended setpoint_log(NXlog): exists: recommended value: @@ -563,38 +561,82 @@ NXmpes(NXobject): elements from each component must be included in `atom_types`. physical_form: exists: recommended - preparation_date(NX_DATE_TIME): + situation: + exists: optional + enumeration: [vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere] + (NXsample_history): exists: recommended doc: | - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - preparation_description(NXnote): - exists: optional + A set of activities that occurred to the sample prior to/during photoemission experiment. + + Ideally, a full report of the previous operations (or links to a chain of operations). + Alternatively, notes allow for additional descriptors in any format + (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. + sample_preparation(NXphysical_process): + exists: recommended + doc: | + Details about the sample preparation for the MPES experiment (e.g. UHV cleaving, + in-situ growth, sputtering/annealing, etc.). + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + exists: recommended + method: + exists: recommended + doc: | + Details about the method of sample preparation before the MPES experiment. + notes: + exists: optional + temperature(NXenvironment): + exists: recommended + doc: | + Sample temperature (either controlled or just measured). + temperature_sensor(NXsensor): + doc: | + Temperature sensor measuring the sample temperature. + This should be a link to /entry/instrument/manipulator/temperature_sensor. + sample_heater(NXactuator): + exists: optional + doc: | + Device to heat the sample. + This should be a link to /entry/instrument/manipulator/sample_heater. + gas_pressure(NXenvironment): + exists: recommended doc: | - 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. - temperature(NX_FLOAT): - unit: NX_TEMPERATURE + Gas pressure surrounding the sample. + pressure_gauge(NXsensor): + doc: | + Gauge measuring the gas pressure. + + This should be a link to /entry/instrument/pressure_gauge. + bias(NXenvironment): exists: recommended doc: | - 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. - situation: - exists: optional - enumeration: [vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere] - gas_pressure(NX_FLOAT): - unit: NX_PRESSURE - exists: optional - bias(NX_FLOAT): - unit: NX_VOLTAGE + Voltage applied to sample and sample holder. + voltmeter(NXsensor): + doc: | + Sensor setting/measuring the applied voltage. + + This should be a link to /entry/instrument/manipulator/sample_bias_voltmeter. + drain_current(NXenvironment): + exists: recommended + doc: | + Drain current of the sample and sample holder. + amperemeter(NXsensor): + doc: | + Amperemeter measuring the drain current of the sample and sample holder. + + This should be a link to /entry/instrument/manipulator/drain_current_amperemeter. + flood_gun_current(NXenvironment): exists: optional doc: | - Voltage applied to sample and sample holder. + Current of low-energy electrons to the sample for charge neutralization + flood_gun(NXactuator): + doc: | + Flood gun creating a current of low-energy electrons. + + This should be a link to /entry/instrument/flood_gun. (NXdata): \@signal: enumeration: [data] From 32b515ceb58d82f5e583f18850236515d6557d23 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 19 Dec 2023 14:23:40 +0100 Subject: [PATCH 0394/1012] make No field in NXelectron_level a string --- contributed_definitions/nyaml/NXelectron_level.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributed_definitions/nyaml/NXelectron_level.yaml b/contributed_definitions/nyaml/NXelectron_level.yaml index 0b5c8143d0..ed9149e2fd 100644 --- a/contributed_definitions/nyaml/NXelectron_level.yaml +++ b/contributed_definitions/nyaml/NXelectron_level.yaml @@ -312,7 +312,7 @@ NXelectron_level(NXobject): Md: doc: | Z=101, name="mendelevium", standard_atomic_weight=258 - No: + "No": doc: | Z=102, name="nobelium", standard_atomic_weight=259 Lr: From f27191f6a3c4c7cd74257fccf3e71bb280ef7450 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 19 Dec 2023 15:30:30 +0100 Subject: [PATCH 0395/1012] Change value log in actuators in NXmanipulator --- contributed_definitions/NXmpes.nxdl.xml | 975 ++++++++-------------- contributed_definitions/nyaml/NXmpes.yaml | 35 +- 2 files changed, 349 insertions(+), 661 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 4a59a14c3f..11ff556349 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -22,36 +22,63 @@ # For further information, see http://www.nexusformat.org --> - + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of data points in the transmission function. + + + - The symbols used in the schema to specify e.g. dimensions of arrays + This is the most general application definition for multidimensional + photoelectron spectroscopy. + + Groups and fields are named according to the + `ISO 18115-1:2023`_ specification as well as the `IUPAC Recommendations 2020`_. + + .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 + + + + + + Datetime of the start of the measurement. - + Datetime of the end of the measurement. - + - A name of the experimental method according - to the `ISO 18115-1:2023`_ specification. + A name of the experimental method according to `Clause 11`_ of + the `ISO 18115-1:2023`_ specification. + + Examples include: + * X-ray photoelectron spectroscopy (XPS) + * angle-resolved X-ray photoelectron spectroscopy (ARXPS) + * ultraviolet photoelectron spectroscopy (UPS) + * angle-resolved photoelectron spectroscopy (ARPES) + * hard X-ray photoemission spectroscopy (HAXPES) + * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) + * photoelectron emission microscopy (PEEM) + * electron spectroscopy for chemical analysis (ESCA) .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 - - - - - - Contact information of at least the user of the instrument or the investigator @@ -62,35 +89,46 @@ Name of the user. - + Name of the affiliation of the user at the point in time when the experiment was performed. - - - Full address (street, street number, ZIP, city, country) of the user's - affiliation. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - - - - + + MPES spectrometer + + This concept is related to term `12.58`_ of the ISO 18115-1:2023 standard. + .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 + + + + Overall energy resolution of the MPES instrument + + This concept is related to term `10.7 ff.`_ of the ISO 18115-1:2023 standard. + .. _10.7 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 + + This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. + .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 + + + + + + + + + + + + + + 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 @@ -119,30 +157,62 @@ - + Type of probe. In photoemission it's always photons, so the full NIAC list is restricted. - + + + + + + + + + + + + The beam emitted by this source. + Should be named with the same appendix, e.g., + for `source_probe` it should refer to `beam_probe`. + Refers to the same concept as /NXentry/NXinstrument/beam_TYPE + and may be linked. + + - - - + + - Distance of the point of evaluation of the beam from the sample surface. + The beam emitted by this source. + Should be named with the same appendix, e.g., + for `source_probe` it should refer to `beam_probe`. + Refers to the same concept as /NXentry/NXinstrument/source_TYPE + and may be linked. + + + + The source that emitted this beam. + Should be named with the same appendix, e.g., + for `beam_probe` it should refer to `source_probe`. + Refers to the same concept as /NXentry/NXinstrument/source_TYPE + and may be linked. + + - + @@ -152,10 +222,14 @@ Energy resolution of the analyser with the current setting. May be linked from a NXcalibration. + + This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. + .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 - + + + + + Labelling of the lens setting in use. + + @@ -189,6 +267,21 @@ Optional constant settings (like lens focusing parameters on the sample: positio additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + Size, position and shape of the iris inserted in the column. + + The iris is an aperture in the lens with a variable diameter which can reduce the number of + electrons entering the analyzer. + + To add additional or other slits use the APERTURE group of NXcollectioncolumn. + + + + + + + @@ -205,16 +298,23 @@ Optional constant settings (like lens focusing parameters on the sample: positio - Size, position and shape of the entrance slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. + Size, position and shape of the entrance slit in dispersive analyzers. + + To add additional or other slits use the APERTURE group of NXenergydispersion. - Size, position and shape of the exit slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. + Size, position and shape of the exit slit in dispersive analyzers. + + To add additional or other slits use the APERTURE group of NXenergydispersion. + + + + + @@ -239,9 +339,12 @@ Optional constant settings (like lens focusing parameters on the sample: positio + + + + + - @@ -277,11 +380,12 @@ It could be a lot of raw data from a detector. Shpould be optional.--> - - In the case of an experiment in which the temperature is changed and recorded, - this is an array of length m of temperatures. - - + + + In the case of an experiment in which the temperature is changed and recorded, + this is an array of length m of temperatures. + + @@ -319,11 +423,13 @@ It could be a lot of raw data from a detector. Shpould be optional.--> and sample holder. - - - In the case of an experiment in which the current changes and is recorded, - this is an array of length m of drain currents. - + + + + In the case of an experiment in which the current changes and is recorded, + this is an array of length m of drain currents. + + @@ -343,11 +449,13 @@ It could be a lot of raw data from a detector. Shpould be optional.--> sample and sample holder. - - - In the case of an experiment in which the bias is changed and recorded, - this is an array of length m of voltages. - + + + + In the case of an experiment in which the bias is changed and recorded, + this is an array of length m of voltages. + + @@ -368,11 +476,13 @@ It could be a lot of raw data from a detector. Shpould be optional.--> the sample. - - - In the case of an experiment in which the gas pressure is changed and recorded, - this is an array of length m of gas pressures. - + + + + In the case of an experiment in which the gas pressure is changed and recorded, + this is an array of length m of gas pressures. + + @@ -448,20 +558,126 @@ It could be a lot of raw data from a detector. Shpould be optional.--> - - - - + - For samples containing a single pure substances. For mixtures use the - NXsample_component_set and NXsample_component group in NXsample instead. + For energy referencing, the measured energies are corrected for the charging potential + (i.e., the electrical potential of the surface region of an insulating sample, caused by + irradiation) such that those energies correspond to a sample with no surface charge. + Usually, the energy axis is adjusted by shifting all energies uniformally until one + well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. + + This concept is related to term `12.74 ff.`_ of the ISO 18115-1:2023 standard. + .. _12.74 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 - + - The chemical formula of the sample. + Have the energy axes been adjusted (e.g., in cases where samples are not + conductive)? + + + + + Electronic core or valence level that was used for the calibration. + + + + + Reference peak that was used for the calibration. + + For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge + + + + + The binding energy (in units of eV) that the specified emission line appeared at, + after adjusting the binding energy scale. + + This concept is related to term `12.16_ ff.`_ of the ISO 18115-1:2023 standard. + .. _12.16_ ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + + + + + Offset between measured binding energy and calibrated binding energy of the + emission line. + + + + + This is the calibrated energy axis to be used for data plotting. + + This should link to /entry/data/energy. + + + In the transmission correction, each intensity measurement for electrons of a given + kinetic energy is multiplied by the corresponding value in the relative_intensity + field of the transmission_function. This calibration procedure is used to account for + the different tranmsission efficiencies when using different lens modes. + + + + Has an intensity calibration been applied? + + That is, has the transmission function of the analyser been taken into account? + + + + + Transmission function of the electron analyser. + + The transmission function (TF) specifies the detection efficiency for electrons of + different kinetic energy passing through the electron analyser. + This can be a link to /entry/instrument/electronanalyser/transmission_function. + + + + + + + + + + + + + + Kinetic energy values + + + + + + + + Relative transmission efficiency for the given kinetic energies + + + + + + + + + + + + + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + + + + + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + + List of comma-separated elements from the periodic table @@ -470,6 +686,7 @@ It could be a lot of raw data from a detector. Shpould be optional.--> elements from each component must be included in `atom_types`. + @@ -490,8 +707,8 @@ It could be a lot of raw data from a detector. Shpould be optional.--> - Details about the sample preparation for the MPES experiment (i.e. cleaving, last - annealing). + Details about the sample preparation for the MPES experiment (e.g. UHV cleaving, + in-situ growth, sputtering/annealing, etc.). @@ -510,14 +727,12 @@ It could be a lot of raw data from a detector. Shpould be optional.--> Temperature sensor measuring the sample temperature. - This should be a link to /entry/instrument/manipulator/temperature_sensor. Device to heat the sample. - This should be a link to /entry/instrument/manipulator/sample_heater. @@ -560,7 +775,7 @@ It could be a lot of raw data from a detector. Shpould be optional.--> - Current of ow-energy electrons to the sample for charge neutralization + Current of low-energy electrons to the sample for charge neutralization @@ -585,569 +800,39 @@ It could be a lot of raw data from a detector. Shpould be optional.--> actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - MPES spectrometer - - This concept is related to term `12.58`_ of the ISO 18115-1:2023 standard. - .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 - - - - Overall energy resolution of the MPES instrument - - This concept is related to term `10.7 ff.`_ of the ISO 18115-1:2023 standard. - .. _10.7 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 - - This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. - .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 - - - - - - - - - - - - - - - - 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. - - - - - - - - - - - - - - - - - - - - Specification of type, may also go to name. - - - - - - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - - - - - - - - - - - - - - - - The beam emitted by this source. - Should be named with the same appendix, e.g., - for `source_probe` it should refer to `beam_probe`. - Refers to the same concept as /NXentry/NXinstrument/beam_TYPE - and may be linked. - - - - - - - - The beam emitted by this source. - Should be named with the same appendix, e.g., - for `source_probe` it should refer to `beam_probe`. - Refers to the same concept as /NXentry/NXinstrument/source_TYPE - and may be linked. - - - - - - - - - The source that emitted this beam. - Should be named with the same appendix, e.g., - for `beam_probe` it should refer to `source_probe`. - Refers to the same concept as /NXentry/NXinstrument/source_TYPE - and may be linked. - - - - - - - - - - - - - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. - .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 - - - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - - Labelling of the lens setting in use. - - - - - - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - Size, position and shape of the iris inserted in the column. - - The iris is an aperture in the lens with a variable diameter which can reduce the number of - electrons entering the analyzer. - - To add additional or other slits use the APERTURE group of NXcollectioncolumn. - - - - - - - - - - - - - - - - - - - - - - - - Size, position and shape of the entrance slit in dispersive analyzers. - - To add additional or other slits use the APERTURE group of NXenergydispersion. - - - - - Size, position and shape of the exit slit in dispersive analyzers. - - To add additional or other slits use the APERTURE group of NXenergydispersion. - - - - - - - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - - - - - - - - Raw data before calibration. - + + + Calibrated energy axis. + + The calibrated energy axis can be either in binding or kinetic energy. + This should be a link to either + /entry/process/energy_calibration/calibrated_axis or + /entry/process/energy_correction/calibrated_axis. + + + + The energy can be either stored as kinetic or as binding energy. + + + + + Calibrated kinetic energy axis. + + This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. + .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 + + + + + Calibrated binding energy axis. + + This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. + .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + + + + - - - - - - Manipulator for positioning of the sample. - - - - - - Bias of the sample with respect to analyser ground. - - This field may also be found in NXsample if present. - - This concept is related to term `8.41`_ of the ISO 18115-1:2023 standard. - .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 - - - - - - - - - - - - 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 - - - - Calibration event on the energy axis. - - For XPS, the calibration should ideally be performed according to - `ISO 15472:2010`_ specification. - - .. _ISO 15472:2010: https://www.iso.org/standard/74811.html - - - - Has an energy calibration been applied? - - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - - Has an angular calibration been applied? - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - - Has an spatial calibration been applied? - - - - - This is the calibrated spatial axis to be used for data plotting. - - - - - - - Has an momentum calibration been applied? - - - - - This is the momentum axis to be used for data plotting. - - - - - - For energy referencing, the measured energies are corrected for the charging potential - (i.e., the electrical potential of the surface region of an insulating sample, caused by - irradiation) such that those energies correspond to a sample with no surface charge. - Usually, the energy axis is adjusted by shifting all energies uniformally until one - well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. - - This concept is related to term `12.74 ff.`_ of the ISO 18115-1:2023 standard. - .. _12.74 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 - - - - Have the energy axes been adjusted (e.g., in cases where samples are not - conductive)? - - - - - Electronic core or valence level that was used for the calibration. - - - - - Reference peak that was used for the calibration. - - For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge - - - - - The binding energy (in units of eV) that the specified emission line appeared at, - after adjusting the binding energy scale. - - This concept is related to term `12.16_ ff.`_ of the ISO 18115-1:2023 standard. - .. _12.16_ ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - - - - - Offset between measured binding energy and calibrated binding energy of the - emission line. - - - - - This is the calibrated energy axis to be used for data plotting. - - This should link to /entry/data/energy. - - - - - - In the transmission correction, each intensity measurement for electrons of a given - kinetic energy is multiplied by the corresponding value in the relative_intensity - field of the transmission_function. This calibration procedure is used to account for - the different tranmsission efficiencies when using different lens modes. - - - - Has an intensity calibration been applied? - - That is, has the transmission function of the analyser been taken into account? - - - - - Transmission function of the electron analyser. - - The transmission function (TF) specifies the detection efficiency for electrons of - different kinetic energy passing through the electron analyser. - This can be a link to /entry/instrument/electronanalyser/transmission_function. - - - - - - - - - - - - - - Kinetic energy values - - - - - - - - Relative transmission efficiency for the given kinetic energies - - - - - - - - - - - - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - - - - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - - - - - Description of the surface preparation technique for the XPS experiment, i.e. - UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report - of the previous operations, in any format(NXnote allows to add pictures, audio, - movies). Alternatively, a reference to the location or a unique identifier or - other metadata file. In the case these are not available, free-text description. - - - - - In the case of a fixed temperature measurement this is the scalar temperature of - the sample. In the case of an experiment in which the temperature is changed and - recoded, this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. - - - - - - - - - - - - - - Voltage applied to sample and sample holder. - - - - - - - - - - - - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, momentum, spatial coordinate, pump-probe - delay, spin index, temperature, etc. The axes traces should be linked to the - actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - Calibrated energy axis. - - The calibrated energy axis can be either in binding or kinetic energy. - This should be a link to either - /entry/process/energy_calibration/calibrated_axis or - /entry/process/energy_correction/calibrated_axis. - - - - The energy can be either stored as kinetic or as binding energy. - - - - - Calibrated kinetic energy axis. - - This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. - .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 - - - - - Calibrated binding energy axis. - - This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. - .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - - - - - - diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 470a8f1c81..cfa906aefc 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -306,10 +306,10 @@ NXmpes(NXobject): by the sample temperature sensor. value_log(NXlog): exists: optional - doc: | - In the case of an experiment in which the temperature is changed and recorded, - this is an array of length m of temperatures. - value: + value(NX_NUMBER): + doc: | + In the case of an experiment in which the temperature is changed and recorded, + this is an array of length m of temperatures. unit: NX_TEMPERATURE sample_heater(NXactuator): exists: recommended @@ -344,10 +344,11 @@ NXmpes(NXobject): and sample holder. value_log(NXlog): exists: optional - unit: NX_CURRENT - doc: | - In the case of an experiment in which the current changes and is recorded, - this is an array of length m of drain currents. + value(NX_NUMBER): + doc: | + In the case of an experiment in which the current changes and is recorded, + this is an array of length m of drain currents. + unit: NX_CURRENT sample_bias_voltmeter(NXsensor): exists: recommended doc: | @@ -366,10 +367,11 @@ NXmpes(NXobject): sample and sample holder. value_log(NXlog): exists: optional - unit: NX_VOLTAGE - doc: | - In the case of an experiment in which the bias is changed and recorded, - this is an array of length m of voltages. + value(NX_NUMBER): + doc: | + In the case of an experiment in which the bias is changed and recorded, + this is an array of length m of voltages. + unit: NX_VOLTAGE pressure_gauge(NXsensor): exists: recommended doc: | @@ -388,10 +390,11 @@ NXmpes(NXobject): the sample. value_log(NXlog): exists: optional - unit: NX_PRESSURE - doc: | - In the case of an experiment in which the gas pressure is changed and recorded, - this is an array of length m of gas pressures. + value(NX_NUMBER): + doc: | + In the case of an experiment in which the gas pressure is changed and recorded, + this is an array of length m of gas pressures. + unit: NX_PRESSURE flood_gun(NXactuator): exists: recommended doc: Device to bring low-energy electrons to the sample for charge neutralization From dba0e642562557a74d8ce2856c862d89d525356c Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 3 Jan 2024 11:27:09 +0100 Subject: [PATCH 0396/1012] Refactoring apm has three aims: i) extent NXapm appdef to take advantage of more general base classes NXserialized, NXidentifier, and CG base classes, also incorporate feedback from discussions with Cameca and generally allow that NXapm can store different state of LEAP-based analyses, reorganizing constraints is another reason for NXapm refactoring, ii) make the currently paraprobe-specific base classes more generally applicable: an example currently NXapm_paraprobe_nanochem allowed to store only the specific way how delocalization based analyses work and what they mean and generate when using paraprobe, but ideally we would like to use a base class NXdelocalization also store delocalizations done with other tools (foremost) those by cameca to arrive at a suggestion for a description format whereby users can store serialized analysis results from atom probe on zenodo in a pre-harmonized way despite not having an appdef designed for it yet, iii) reduce redundancies and make descriptions like for the em refactoring more succinct --- .../nyaml/NXapm_input_ranging.yaml | 101 ------ .../nyaml/NXapm_input_reconstruction.yaml | 89 ------ .../nyaml/NXcg_marching_cubes.yaml | 33 -- .../nyaml/NXclustering.yaml | 206 ------------- .../nyaml/NXdelocalization.yaml | 242 --------------- .../nyaml/NXisocontour.yaml | 104 ------- .../nyaml/NXmatch_filter.yaml | 95 ------ contributed_definitions/nyaml/NXpeak.yaml | 136 -------- .../nyaml/NXpulser_apm.yaml | 281 ----------------- .../nyaml/NXreflectron.yaml | 87 ------ .../nyaml/NXsimilarity_grouping.yaml | 290 ------------------ .../nyaml/NXspatial_filter.yaml | 134 -------- .../nyaml/NXsubsampling_filter.yaml | 71 ----- .../nyaml/{ => refactor}/NXapm.yaml | 0 .../NXapm_composition_space_results.yaml | 0 .../NXapm_paraprobe_config_clusterer.yaml | 0 .../NXapm_paraprobe_config_distancer.yaml | 0 .../NXapm_paraprobe_config_intersector.yaml | 0 .../NXapm_paraprobe_config_nanochem.yaml | 0 .../NXapm_paraprobe_config_ranger.yaml | 0 .../NXapm_paraprobe_config_selector.yaml | 0 .../NXapm_paraprobe_config_spatstat.yaml | 0 .../NXapm_paraprobe_config_surfacer.yaml | 0 .../NXapm_paraprobe_config_tessellator.yaml | 0 .../NXapm_paraprobe_results_clusterer.yaml | 0 .../NXapm_paraprobe_results_distancer.yaml | 0 .../NXapm_paraprobe_results_intersector.yaml | 0 .../NXapm_paraprobe_results_nanochem.yaml | 0 .../NXapm_paraprobe_results_ranger.yaml | 0 .../NXapm_paraprobe_results_selector.yaml | 0 .../NXapm_paraprobe_results_spatstat.yaml | 0 .../NXapm_paraprobe_results_surfacer.yaml | 0 .../NXapm_paraprobe_results_tessellator.yaml | 0 .../refactor/NXapm_paraprobe_tool_config.yaml | 76 +++++ .../NXapm_paraprobe_tool_results.yaml | 90 ++++++ .../NXapm_paraprobe_transcoder_config.yaml} | 0 .../NXapm_paraprobe_transcoder_results.yaml} | 0 .../nyaml/refactor/NXcg_marching_cubes.yaml | 30 ++ .../nyaml/refactor/NXdelocalization.yaml | 90 ++++++ .../nyaml/{ => refactor}/NXion.yaml | 51 ++- .../nyaml/refactor/NXisocontour.yaml | 39 +++ .../nyaml/refactor/NXmatch_filter.yaml | 26 ++ .../nyaml/refactor/NXpeak.yaml | 42 +++ .../nyaml/refactor/NXpulser_apm.yaml | 105 +++++++ .../nyaml/refactor/NXreflectron.yaml | 32 ++ .../nyaml/refactor/NXsimilarity_grouping.yaml | 123 ++++++++ .../nyaml/refactor/NXspatial_filter.yaml | 47 +++ .../nyaml/refactor/NXsubsampling_filter.yaml | 17 + .../deprecate/NXapm_input_ranging.yaml | 25 ++ .../deprecate/NXapm_input_reconstruction.yaml | 19 ++ 50 files changed, 783 insertions(+), 1898 deletions(-) delete mode 100644 contributed_definitions/nyaml/NXapm_input_ranging.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_input_reconstruction.yaml delete mode 100644 contributed_definitions/nyaml/NXcg_marching_cubes.yaml delete mode 100644 contributed_definitions/nyaml/NXclustering.yaml delete mode 100644 contributed_definitions/nyaml/NXdelocalization.yaml delete mode 100644 contributed_definitions/nyaml/NXisocontour.yaml delete mode 100644 contributed_definitions/nyaml/NXmatch_filter.yaml delete mode 100644 contributed_definitions/nyaml/NXpeak.yaml delete mode 100644 contributed_definitions/nyaml/NXpulser_apm.yaml delete mode 100644 contributed_definitions/nyaml/NXreflectron.yaml delete mode 100644 contributed_definitions/nyaml/NXsimilarity_grouping.yaml delete mode 100644 contributed_definitions/nyaml/NXspatial_filter.yaml delete mode 100644 contributed_definitions/nyaml/NXsubsampling_filter.yaml rename contributed_definitions/nyaml/{ => refactor}/NXapm.yaml (100%) rename contributed_definitions/nyaml/{ => refactor}/NXapm_composition_space_results.yaml (100%) rename contributed_definitions/nyaml/{ => refactor}/NXapm_paraprobe_config_clusterer.yaml (100%) rename contributed_definitions/nyaml/{ => refactor}/NXapm_paraprobe_config_distancer.yaml (100%) rename contributed_definitions/nyaml/{ => refactor}/NXapm_paraprobe_config_intersector.yaml (100%) rename contributed_definitions/nyaml/{ => refactor}/NXapm_paraprobe_config_nanochem.yaml (100%) rename contributed_definitions/nyaml/{ => refactor}/NXapm_paraprobe_config_ranger.yaml (100%) rename contributed_definitions/nyaml/{ => refactor}/NXapm_paraprobe_config_selector.yaml (100%) rename contributed_definitions/nyaml/{ => refactor}/NXapm_paraprobe_config_spatstat.yaml (100%) rename contributed_definitions/nyaml/{ => refactor}/NXapm_paraprobe_config_surfacer.yaml (100%) rename contributed_definitions/nyaml/{ => refactor}/NXapm_paraprobe_config_tessellator.yaml (100%) rename contributed_definitions/nyaml/{ => refactor}/NXapm_paraprobe_results_clusterer.yaml (100%) rename contributed_definitions/nyaml/{ => refactor}/NXapm_paraprobe_results_distancer.yaml (100%) rename contributed_definitions/nyaml/{ => refactor}/NXapm_paraprobe_results_intersector.yaml (100%) rename contributed_definitions/nyaml/{ => refactor}/NXapm_paraprobe_results_nanochem.yaml (100%) rename contributed_definitions/nyaml/{ => refactor}/NXapm_paraprobe_results_ranger.yaml (100%) rename contributed_definitions/nyaml/{ => refactor}/NXapm_paraprobe_results_selector.yaml (100%) rename contributed_definitions/nyaml/{ => refactor}/NXapm_paraprobe_results_spatstat.yaml (100%) rename contributed_definitions/nyaml/{ => refactor}/NXapm_paraprobe_results_surfacer.yaml (100%) rename contributed_definitions/nyaml/{ => refactor}/NXapm_paraprobe_results_tessellator.yaml (100%) create mode 100644 contributed_definitions/nyaml/refactor/NXapm_paraprobe_tool_config.yaml create mode 100644 contributed_definitions/nyaml/refactor/NXapm_paraprobe_tool_results.yaml rename contributed_definitions/nyaml/{NXapm_paraprobe_config_transcoder.yaml => refactor/NXapm_paraprobe_transcoder_config.yaml} (100%) rename contributed_definitions/nyaml/{NXapm_paraprobe_results_transcoder.yaml => refactor/NXapm_paraprobe_transcoder_results.yaml} (100%) create mode 100644 contributed_definitions/nyaml/refactor/NXcg_marching_cubes.yaml create mode 100644 contributed_definitions/nyaml/refactor/NXdelocalization.yaml rename contributed_definitions/nyaml/{ => refactor}/NXion.yaml (65%) create mode 100644 contributed_definitions/nyaml/refactor/NXisocontour.yaml create mode 100644 contributed_definitions/nyaml/refactor/NXmatch_filter.yaml create mode 100644 contributed_definitions/nyaml/refactor/NXpeak.yaml create mode 100644 contributed_definitions/nyaml/refactor/NXpulser_apm.yaml create mode 100644 contributed_definitions/nyaml/refactor/NXreflectron.yaml create mode 100644 contributed_definitions/nyaml/refactor/NXsimilarity_grouping.yaml create mode 100644 contributed_definitions/nyaml/refactor/NXspatial_filter.yaml create mode 100644 contributed_definitions/nyaml/refactor/NXsubsampling_filter.yaml create mode 100644 contributed_definitions/nyaml/refactor/deprecate/NXapm_input_ranging.yaml create mode 100644 contributed_definitions/nyaml/refactor/deprecate/NXapm_input_reconstruction.yaml diff --git a/contributed_definitions/nyaml/NXapm_input_ranging.yaml b/contributed_definitions/nyaml/NXapm_input_ranging.yaml deleted file mode 100644 index 8735f8baa8..0000000000 --- a/contributed_definitions/nyaml/NXapm_input_ranging.yaml +++ /dev/null @@ -1,101 +0,0 @@ -category: base -doc: | - Metadata to ranging definitions made for a dataset in atom probe microscopy. - - Ranging is the process of labeling time-of-flight data with so-called iontypes - which ideally specify the most likely ion/molecular ion evaporated within a - given mass-to-charge-state-ratio value interval. - - The paraprobe-toolbox uses the convention that the so-called UNKNOWNTYPE - iontype (or unranged ions) represents the default iontype. - The ID of this special iontype is always reserved as 0. Each ion - is assigned to the UNKNOWNTYPE by default. Iontypes are assigned - by checking if the mass-to-charge-state-ratio values of an ion matches - to any of the defined mass-to-charge-state-ratio intervals. - -# symbols: -type: group -NXapm_input_ranging(NXobject): - filename: - doc: | - Path and name of the NeXus/HDF5 file which stores ranging definitions. - \@version: - doc: | - Version identifier of the file (representing an at least SHA256 strong) - hash. Such hashes serve reproducibility as they can be used for tracking - provenance metadata in a workflow. - group_name_iontypes: - doc: | - Name of the group (prefix to the individual ranging definitions) inside - the file referred to by filename which points to the specific ranging - definition to use. - An HDF5 file can store multiple ranging definitions. Using an ID is - the mechanism to distinguish which specific ranging (version) will - be processed. Reconstruction and ranging IDs can differ. - They specify different IDs. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 84be754a74580064b6e83b8cc1e513bdcad4ae264f96c9203c5341fc784b2a03 -# -# -# -# -# -# -# Metadata to ranging definitions made for a dataset in atom probe microscopy. -# -# Ranging is the process of labeling time-of-flight data with so-called iontypes -# which ideally specify the most likely ion/molecular ion evaporated within a -# given mass-to-charge-state-ratio value interval. -# -# The paraprobe-toolbox uses the convention that the so-called UNKNOWNTYPE -# iontype (or unranged ions) represents the default iontype. -# The ID of this special iontype is always reserved as 0. Each ion -# is assigned to the UNKNOWNTYPE by default. Iontypes are assigned -# by checking if the mass-to-charge-state-ratio values of an ion matches -# to any of the defined mass-to-charge-state-ratio intervals. -# -# -# -# Path and name of the NeXus/HDF5 file which stores ranging definitions. -# -# -# -# Version identifier of the file (representing an at least SHA256 strong) -# hash. Such hashes serve reproducibility as they can be used for tracking -# provenance metadata in a workflow. -# -# -# -# -# -# Name of the group (prefix to the individual ranging definitions) inside -# the file referred to by filename which points to the specific ranging -# definition to use. -# An HDF5 file can store multiple ranging definitions. Using an ID is -# the mechanism to distinguish which specific ranging (version) will -# be processed. Reconstruction and ranging IDs can differ. -# They specify different IDs. -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_input_reconstruction.yaml b/contributed_definitions/nyaml/NXapm_input_reconstruction.yaml deleted file mode 100644 index 0d3fb996fe..0000000000 --- a/contributed_definitions/nyaml/NXapm_input_reconstruction.yaml +++ /dev/null @@ -1,89 +0,0 @@ -category: base -doc: | - Metadata of a dataset (tomographic reconstruction) in atom probe microscopy. - -# symbols: -type: group -NXapm_input_reconstruction(NXobject): - filename: - doc: | - Name of the (NeXus)/HDF5 file which stores reconstructed ion position - and mass-to-charge-state ratios. Such an HDF5 file can store multiple - reconstructions. Using the information within the dataset_name fields - is the mechanism whereby paraprobe decides which reconstruction to - process. With this design it is possible that the same HDF5 - file can store multiple versions of a reconstruction. - \@version: - doc: | - Version identifier of the file (representing an at least SHA256 strong) - hash. Such hashes serve reproducibility as they can be used for tracking - provenance metadata in a workflow. - dataset_name_reconstruction: - doc: | - Name of the dataset inside the HDF5 file which refers to the - specific reconstructed ion positions to use for this analysis. - dataset_name_mass_to_charge: - doc: | - Name of the dataset inside the HDF5 file which refers to the - specific mass-to-charge-state-ratio values to use for this analysis. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 5f409b194cbe10570c31933903ade8ac14d43cbc05493d52f0494615fe2071d7 -# -# -# -# -# -# -# Metadata of a dataset (tomographic reconstruction) in atom probe microscopy. -# -# -# -# Name of the (NeXus)/HDF5 file which stores reconstructed ion position -# and mass-to-charge-state ratios. Such an HDF5 file can store multiple -# reconstructions. Using the information within the dataset_name fields -# is the mechanism whereby paraprobe decides which reconstruction to -# process. With this design it is possible that the same HDF5 -# file can store multiple versions of a reconstruction. -# -# -# -# Version identifier of the file (representing an at least SHA256 strong) -# hash. Such hashes serve reproducibility as they can be used for tracking -# provenance metadata in a workflow. -# -# -# -# -# -# Name of the dataset inside the HDF5 file which refers to the -# specific reconstructed ion positions to use for this analysis. -# -# -# -# -# Name of the dataset inside the HDF5 file which refers to the -# specific mass-to-charge-state-ratio values to use for this analysis. -# -# -# diff --git a/contributed_definitions/nyaml/NXcg_marching_cubes.yaml b/contributed_definitions/nyaml/NXcg_marching_cubes.yaml deleted file mode 100644 index d731f8103b..0000000000 --- a/contributed_definitions/nyaml/NXcg_marching_cubes.yaml +++ /dev/null @@ -1,33 +0,0 @@ -category: base -doc: | - Computational geometry description of the marching cubes algorithm. - - Documenting which specific version was used helps with understanding how - robust the results are with respect to the topology of the triangulation. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXcg_marching_cubes(NXobject): - grid(NXcg_grid): - doc: | - Reference/link to and/or details of the grid on which a specific - marching cubes algorithm implementation is operating. - implementation(NX_CHAR): - doc: | - Reference to the specific implementation of marching cubes used. - - See for example the following papers for details about how to identify a - DOI which specifies the implementation used: - - * `W. E. Lorensen `_ - * `T. S. Newman and H. Yi `_ - - The value placed here should be a DOI. If there are no specific DOI or - details write not_further_specified, or give at least a free-text - description. - (NXprogram): - - # we could also think about storing the rule sets in here explicitly including the - # coordinate system conventions; however, the problem is that many commercial - # tools like Matlab do not expose the rule set. diff --git a/contributed_definitions/nyaml/NXclustering.yaml b/contributed_definitions/nyaml/NXclustering.yaml deleted file mode 100644 index fe14504583..0000000000 --- a/contributed_definitions/nyaml/NXclustering.yaml +++ /dev/null @@ -1,206 +0,0 @@ -category: base -doc: | - Metadata to the results of a clustering analysis. - - Clustering algorithms are routine tools to segment a set of objects/primitives - into groups, objects of different type. A plethora of algorithms have been - proposed for geometric primitives as objects, such as points, triangles, - or (abstract) objects. - - This base class considers metadata and results of one clustering - applied to a set in which objects are either categorized as noise - or belonging to a cluster, specifically here only one cluster. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_lbl_num: | - Number of numeral labels per object. - n_lbl_cat: | - Number of categorical labels per object. - n_cluster: | - Total number of clusters detected. -type: group -NXclustering(NXobject): - number_of_numeric_labels(NX_UINT): - unit: NX_UNITLESS - doc: | - How many numeric labels does each object have. - number_of_categorical_labels(NX_UINT): - unit: NX_UNITLESS - doc: | - How many categorical labels does each object have. - objects: - doc: | - Reference to a set of objects investigated in a cluster analysis. - Objects must have clear integer identifier. - numeric_label(NX_NUMBER): - doc: | - Reference to numeric attribute data for each object. - categorical_label: - doc: | - Reference to categorical attribute data for each object. - - # list instances of base classes of an applied cluster algorithm - # e.g. (NXclustering_hdbscan): - identifier_offset(NX_UINT): - unit: NX_UNITLESS - doc: | - Which identifier is the first to be used to label a cluster. - - The value should be chosen in such a way that special values can be resolved: - * identifier_offset-1 indicates an object belongs to no cluster. - * identifier_offset-2 indicates an object belongs to the noise category. - Setting for instance identifier_offset to 1 recovers the commonly used - case that objects of the noise category get values to -1 and unassigned points to 0. - unassigned(NX_UINT): - unit: NX_UNITLESS - doc: | - Total number of objects categorized as unassigned. - noise(NX_UINT): - unit: NX_UNITLESS - doc: | - Total number of objects categorized as noise. - number_of_cluster(NX_UINT): - unit: NX_UNITLESS - doc: | - Total number of clusters (excluding noise and unassigned). - size(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Number of objects associated to each cluster. The labels are implicit, - meaning the zeroth/first entry in the array belongs to the first cluster, - the second entry to the second cluster and so on and so forth. - The first cluster has the value of identifier_offset as its identifier. - The second cluster has identifier_offset + 1, and so on and so forth. - dimensions: - rank: 1 - dim: [[1, n_cluster]] - - # should we handle, and if so how fuzzy assignments or similarly probability - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# bbc782a9d72772178ebeebf1b4e9e199de33a4e111361efeba48cb4b169e051c -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of numeral labels per object. -# -# -# -# -# Number of categorical labels per object. -# -# -# -# -# Total number of clusters detected. -# -# -# -# -# Metadata to the results of a clustering analysis. -# -# Clustering algorithms are routine tools to segment a set of objects/primitives -# into groups, objects of different type. A plethora of algorithms have been -# proposed for geometric primitives as objects, such as points, triangles, -# or (abstract) objects. -# -# This base class considers metadata and results of one clustering -# applied to a set in which objects are either categorized as noise -# or belonging to a cluster, specifically here only one cluster. -# -# -# -# How many numeric labels does each object have. -# -# -# -# -# How many categorical labels does each object have. -# -# -# -# -# Reference to a set of objects investigated in a cluster analysis. -# Objects must have clear integer identifier. -# -# -# -# -# Reference to numeric attribute data for each object. -# -# -# -# -# Reference to categorical attribute data for each object. -# -# -# -# -# -# Which identifier is the first to be used to label a cluster. -# -# The value should be chosen in such a way that special values can be resolved: -# * identifier_offset-1 indicates an object belongs to no cluster. -# * identifier_offset-2 indicates an object belongs to the noise category. -# Setting for instance identifier_offset to 1 recovers the commonly used -# case that objects of the noise category get values to -1 and unassigned points to 0. -# -# -# -# -# Total number of objects categorized as unassigned. -# -# -# -# -# Total number of objects categorized as noise. -# -# -# -# -# Total number of clusters (excluding noise and unassigned). -# -# -# -# -# Number of objects associated to each cluster. The labels are implicit, -# meaning the zeroth/first entry in the array belongs to the first cluster, -# the second entry to the second cluster and so on and so forth. -# The first cluster has the value of identifier_offset as its identifier. -# The second cluster has identifier_offset + 1, and so on and so forth. -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXdelocalization.yaml b/contributed_definitions/nyaml/NXdelocalization.yaml deleted file mode 100644 index 77bdadd6ea..0000000000 --- a/contributed_definitions/nyaml/NXdelocalization.yaml +++ /dev/null @@ -1,242 +0,0 @@ -category: base -doc: | - Base class to describe the delocalization of point-like objects on a grid. - - Such a procedure is for instance used in image processing and e.g. atom probe - microscopy (APM) to discretize a point cloud onto a grid to enable e.g. - computing of point density, composition, or concentration values, obtain - scalar fields, and compute gradients of these fields. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_p: | - Number of points/objects. - n_m: | - Number of mark data per point/object. - n_atoms: | - Number of atoms in the whitelist. - n_isotopes: | - Number of isotopes in the whitelist. -type: group -NXdelocalization(NXobject): - grid: - doc: | - Reference or link to the grid on which the delocalization is applied. - objects: - doc: | - Reference or link to the points which are delocalized on the grid. - - # for APM the speciality is nothing but: - # each point marks the location of an ion (object) in the tomographic reconstruction - # there is a boolean mask which filters which ions, i.e. points are considered - # plus there is a weight interpretation model, specifically in atom probe - # if a (molecular) ion is decomposed into its atoms or isotopes - # plus, given there is such a weight interpretation model, there is a weight - # associated, specifically an integer >= 1 with each considered ion and 0 for - # all ions which are not considered, - # this weight is the multiplicity with respect to the interpretation model - # i.e. a C:2 molecular ion has a multiplicity of 2 if the ion is considered - # and the interpretation model that to consider carbon atoms or carbon ions - weighting_model: - doc: | - The weighting model specifies how mark data are mapped to a weight per point. - For atom probe microscopy (APM) as an example, different models are used which - account differently for the multiplicity of an ion/atom: - - * default, points all get the same weight 1.; - for APM this is equivalent to ion species - * atomic_decomposition, points get as much weight as they have atoms - of a type in element_whitelist, - * isotope_decomposition, points get as much weight as they have - isotopes of a type in isotope_whitelist. - - This description shows an example that could be reinterpreted for - similar such data processing steps in other fields of science. - enumeration: [default, atomic_decomposition, isotope_decomposition] - - # other - # can one conditionally set a field required if a weighting_model has a - # specific value, - # i.e. if atomic_decomposition is set element_whitelist t is required - # i.e. if isotope_decomposition is set isotope_whitelist is required? - element_whitelist(NX_UINT): - unit: NX_UNITLESS - doc: | - A list of elements (via proton number) to consider for the atomic_decomposition - weighting model. Elements must exist in the periodic table of elements. - dimensions: - rank: 1 - dim: [[1, n_atoms]] - isotope_whitelist(NX_UINT): - unit: NX_UNITLESS - doc: | - A list of isotopes to consider for the isotope_decomposition weighting model. - Isotopes must exist in the nuclid table. Entries in the fastest changing - dimension should be the pair of proton (first entry) and neutron number - (second entry). - dimensions: - rank: 2 - dim: [[1, n_isotopes], [2, 2]] - mark(NX_NUMBER): - doc: | - Attribute data for each member of the point cloud. For APM these are the - ion species labels generated via ranging. The number of mark data per - point is 1 in the case for atom probe. - dimensions: - rank: 2 - dim: [[1, n_p], [2, n_m]] - weight(NX_NUMBER): - doc: | - Weighting factor with which the integrated intensity per grid cell is - multiplied specifically for each point. For APM the weight are positive - integer values, specifically the multiplicity of the ion, - according to the details of the weighting_model. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 38d91286faad0b8ce9904853bb66690d59cd3f393af678be595bd38812c6845d -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of points/objects. -# -# -# -# -# Number of mark data per point/object. -# -# -# -# -# Number of atoms in the whitelist. -# -# -# -# -# Number of isotopes in the whitelist. -# -# -# -# -# Base class to describe the delocalization of point-like objects on a grid. -# -# Such a procedure is for instance used in image processing and e.g. atom probe -# microscopy (APM) to discretize a point cloud onto a grid to enable e.g. -# computing of point density, composition, or concentration values, obtain -# scalar fields, and compute gradients of these fields. -# -# -# -# Reference or link to the grid on which the delocalization is applied. -# -# -# -# -# Reference or link to the points which are delocalized on the grid. -# -# -# -# -# -# The weighting model specifies how mark data are mapped to a weight per point. -# For atom probe microscopy (APM) as an example, different models are used which -# account differently for the multiplicity of an ion/atom: -# -# * default, points all get the same weight 1.; -# for APM this is equivalent to ion species -# * atomic_decomposition, points get as much weight as they have atoms -# of a type in element_whitelist, -# * isotope_decomposition, points get as much weight as they have -# isotopes of a type in isotope_whitelist. -# -# This description shows an example that could be reinterpreted for -# similar such data processing steps in other fields of science. -# -# -# -# -# -# -# -# -# -# -# A list of elements (via proton number) to consider for the atomic_decomposition -# weighting model. Elements must exist in the periodic table of elements. -# -# -# -# -# -# -# -# A list of isotopes to consider for the isotope_decomposition weighting model. -# Isotopes must exist in the nuclid table. Entries in the fastest changing -# dimension should be the pair of proton (first entry) and neutron number -# (second entry). -# -# -# -# -# -# -# -# -# Attribute data for each member of the point cloud. For APM these are the -# ion species labels generated via ranging. The number of mark data per -# point is 1 in the case for atom probe. -# -# -# -# -# -# -# -# -# Weighting factor with which the integrated intensity per grid cell is -# multiplied specifically for each point. For APM the weight are positive -# integer values, specifically the multiplicity of the ion, -# according to the details of the weighting_model. -# -# -# diff --git a/contributed_definitions/nyaml/NXisocontour.yaml b/contributed_definitions/nyaml/NXisocontour.yaml deleted file mode 100644 index 5f64c3c782..0000000000 --- a/contributed_definitions/nyaml/NXisocontour.yaml +++ /dev/null @@ -1,104 +0,0 @@ -category: base -doc: | - Computational geometry description of isocontouring/phase-fields in Euclidean space. - - Iso-contouring algorithms such as MarchingCubes and others are frequently - used to segment d-dimensional regions into regions where intensities are - lower or higher than a threshold value, the so-called isovalue. - - Frequently in computational materials science phase-field methods are - used which generate data on discretized grids. Isocontour algorithms - are often used in such context to pinpoint the locations of microstructural - features from this implicit phase-field-variable-based description. - - One of the key intentions of this base class is to provide a starting point - for scientists from the phase-field community (condensed matter physicists, - and materials engineers) to incentivize that also phase-field simulation - data could be described with NeXus, provided base classes such as the this one - get further extend according to the liking of the phase-field community. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the description. -type: group -NXisocontour(NXobject): - dimensionality(NX_POSINT): - doc: | - The dimensionality of the space in which the isocontour is embedded. - unit: NX_UNITLESS - enumeration: [2, 3] - grid(NXcg_grid): - doc: | - The discretized grid on which the iso-contour algorithm operates. - isovalue(NX_NUMBER): - unit: NX_ANY - doc: | - The threshold or iso-contour value. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# b300a7c96b0af0dc9017c870a9758dc2c5e0b922c869ae76458457db04fdcb8d -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The dimensionality of the description. -# -# -# -# -# Computational geometry description of isocontouring/phase-fields in Euclidean space. -# -# Iso-contouring algorithms such as MarchingCubes and others are frequently -# used to segment d-dimensional regions into regions where intensities are -# lower or higher than a threshold value, the so-called isovalue. -# -# Frequently in computational materials science phase-field methods are -# used which generate data on discretized grids. Isocontour algorithms -# are often used in such context to pinpoint the locations of microstructural -# features from this implicit phase-field-variable-based description. -# -# One of the key intentions of this base class is to provide a starting point -# for scientists from the phase-field community (condensed matter physicists, -# and materials engineers) to incentivize that also phase-field simulation -# data could be described with NeXus, provided base classes such as the this one -# get further extend according to the liking of the phase-field community. -# -# -# -# -# The discretized grid on which the iso-contour algorithm operates. -# -# -# -# -# The threshold or iso-contour value. -# -# -# diff --git a/contributed_definitions/nyaml/NXmatch_filter.yaml b/contributed_definitions/nyaml/NXmatch_filter.yaml deleted file mode 100644 index d42df74cdc..0000000000 --- a/contributed_definitions/nyaml/NXmatch_filter.yaml +++ /dev/null @@ -1,95 +0,0 @@ -category: base -doc: | - Settings of a filter to select or remove entries based on their value. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_values: | - How many different match values does the filter specify. -type: group -NXmatch_filter(NXobject): - method: - doc: | - Meaning of the filter: - Whitelist specifies which entries with said value to include. - Entries with all other values will be filtered out. - - Blacklist specifies which entries with said value to exclude. - Entries with all other values will be included. - enumeration: [whitelist, blacklist] - match(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Array of values to filter according to method. For example if the filter - specifies [1, 5, 6] and method is whitelist, only entries with values - matching 1, 5 or 6 will be processed. All other entries will be filtered - out. - dimensions: - rank: 1 - dim: [[1, n_values]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 658011327c521407a34c26bfa9eae3d21d763c4d975f4a8d514fcedf8ed18b36 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# How many different match values does the filter specify. -# -# -# -# -# Settings of a filter to select or remove entries based on their value. -# -# -# -# Meaning of the filter: -# Whitelist specifies which entries with said value to include. -# Entries with all other values will be filtered out. -# -# Blacklist specifies which entries with said value to exclude. -# Entries with all other values will be included. -# -# -# -# -# -# -# -# -# Array of values to filter according to method. For example if the filter -# specifies [1, 5, 6] and method is whitelist, only entries with values -# matching 1, 5 or 6 will be processed. All other entries will be filtered -# out. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXpeak.yaml b/contributed_definitions/nyaml/NXpeak.yaml deleted file mode 100644 index 401c3b497d..0000000000 --- a/contributed_definitions/nyaml/NXpeak.yaml +++ /dev/null @@ -1,136 +0,0 @@ -category: base -doc: | - Description of peaks, their functional form or measured support. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_support: | - Number of support points -type: group -NXpeak(NXobject): - label: - doc: | - Human-readable identifier to specify which concept/entity - the peak represents/identifies. - peak_model: - doc: | - Is the peak described analytically via a functional form - or is it empirically defined via measured/reported - intensity/counts as a function of an independent variable. - - If the functional form is not empirical or gaussian, users - should enter other for the peak_model and add relevant details - in the NXcollection. - enumeration: [empirical, gaussian, lorentzian, other] - position(NX_NUMBER): - unit: NX_ANY - doc: | - In the case of an empirical description of the peak and its shoulders, - this array holds the position values for the independent variable. - dimensions: - rank: 1 - dim: [[1, n_support]] - intensity(NX_NUMBER): - unit: NX_ANY - doc: | - In the case of an empirical description of the peak and its shoulders, - this array holds the intensity/count values at each position. - dimensions: - rank: 1 - dim: [[1, n_support]] - (NXcollection): - doc: | - In the case of an analytical description (or if peak_model is other) this - collection holds parameter of (and eventually) the functional form. - For example in the case of Gaussians mu, sigma, cut-off values, - and background intensity are relevant parameter. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 40c5d1ea859b17085a2dacf79ad49f540f43ddf2d8e2374a0adb1ef5cd9434ea -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of support points -# -# -# -# -# Description of peaks, their functional form or measured support. -# -# -# -# Human-readable identifier to specify which concept/entity -# the peak represents/identifies. -# -# -# -# -# Is the peak described analytically via a functional form -# or is it empirically defined via measured/reported -# intensity/counts as a function of an independent variable. -# -# If the functional form is not empirical or gaussian, users -# should enter other for the peak_model and add relevant details -# in the NXcollection. -# -# -# -# -# -# -# -# -# -# -# In the case of an empirical description of the peak and its shoulders, -# this array holds the position values for the independent variable. -# -# -# -# -# -# -# -# In the case of an empirical description of the peak and its shoulders, -# this array holds the intensity/count values at each position. -# -# -# -# -# -# -# -# In the case of an analytical description (or if peak_model is other) this -# collection holds parameter of (and eventually) the functional form. -# For example in the case of Gaussians mu, sigma, cut-off values, -# and background intensity are relevant parameter. -# -# -# diff --git a/contributed_definitions/nyaml/NXpulser_apm.yaml b/contributed_definitions/nyaml/NXpulser_apm.yaml deleted file mode 100644 index 0660ad266b..0000000000 --- a/contributed_definitions/nyaml/NXpulser_apm.yaml +++ /dev/null @@ -1,281 +0,0 @@ -category: base -doc: | - Metadata for laser- and/or voltage-pulsing in atom probe microscopy. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_ions: | - Total number of ions collected. -type: group -NXpulser_apm(NXobject): - (NXfabrication): - pulse_mode: - doc: | - How is field evaporation physically triggered. - enumeration: [laser, voltage, laser_and_voltage] - pulse_frequency(NX_FLOAT): - unit: NX_FREQUENCY - doc: | - Frequency with which the high voltage or laser pulser fires. - - # This can change over the course of the experiment, APT HDF defines it therefore as follows: "PulseFrequency : Real array, 2xn (Hz) This is the frequency of the high voltage or laser pulser. first entry : first pulse number where the spacing between this and all subsequent pulses are considered to be at the selected frequency. Each first entry must be strictly increasing in value. The second entry contains the frequency value" as data can be compressed in this case very efficiently we go for with an array of length 1xn_ions - dimensions: - rank: 1 - dim: [[1, n_ions]] - pulse_fraction(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Fraction of the pulse_voltage that is applied in addition - to the standing_voltage at peak voltage of a pulse. - - If a standing voltage is applied, this gives nominal pulse fraction - (as a function of standing voltage). Otherwise this field should not be - present. - dimensions: - rank: 1 - dim: [[1, n_ions]] - pulsed_voltage(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - In laser pulsing mode the values will be zero so the this field is recommended. - However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. - dimensions: - rank: 1 - dim: [[1, n_ions]] - pulse_number(NX_UINT): - unit: NX_UNITLESS - doc: | - Absolute number of pulses starting from the beginning of the experiment. - dimensions: - rank: 1 - dim: [[1, n_ions]] - standing_voltage(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - Direct current voltage between the specimen and the (local electrode) in - the case of local electrode atom probe (LEAP) instrument. - The standing voltage applied to the sample, relative to system ground. - dimensions: - rank: 1 - dim: [[1, n_ions]] - (NXsource): - 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. - name: - doc: | - Given name/alias. - (NXfabrication): - wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - Nominal wavelength of the laser radiation. - power(NX_FLOAT): - unit: NX_POWER - doc: | - Nominal power of the laser source while illuminating the specimen. - - # NEW ISSUE: needs clearer specification/definition - pulse_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - Average energy of the laser at peak of each pulse. - (NXbeam): - doc: | - Details about specific positions along the focused laser beam - which illuminates the (atom probe) specimen. - incidence_vector(NXcollection): - doc: | - Track time-dependent settings over the course of the - measurement how the laser beam in tip space/reconstruction space - laser impinges on the sample, i.e. the mean vector is parallel to - the laser propagation direction. - pinhole_position(NXcollection): - doc: | - Track time-dependent settings over the course of the - measurement where the laser beam exits the - focusing optics. - spot_position(NXcollection): - doc: | - Track time-dependent settings over the course of the - measurement where the laser hits the specimen. - (NXtransformations): - doc: | - Affine transformations which describe the geometry how the - laser focusing optics/pinhole-attached coordinate system is - defined, how it has to be transformed so that it aligns with - the specimen coordinate system. - A right-handed Cartesian coordinate system, the so-called laser space, - should be assumed, whose positive z-axis points - into the direction of the propagating laser beam. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 84fa67d6c1df34589f01c80d3eb014e43f7ba7a6cdfab06afba597d89f3e8377 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Total number of ions collected. -# -# -# -# -# Metadata for laser- and/or voltage-pulsing in atom probe microscopy. -# -# -# -# -# How is field evaporation physically triggered. -# -# -# -# -# -# -# -# -# -# Frequency with which the high voltage or laser pulser fires. -# -# -# -# -# -# -# -# -# Fraction of the pulse_voltage that is applied in addition -# to the standing_voltage at peak voltage of a pulse. -# -# If a standing voltage is applied, this gives nominal pulse fraction -# (as a function of standing voltage). Otherwise this field should not be -# present. -# -# -# -# -# -# -# -# In laser pulsing mode the values will be zero so the this field is recommended. -# However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. -# -# -# -# -# -# -# -# Absolute number of pulses starting from the beginning of the experiment. -# -# -# -# -# -# -# -# Direct current voltage between the specimen and the (local electrode) in -# the case of local electrode atom probe (LEAP) instrument. -# The standing voltage applied to the sample, relative to system ground. -# -# -# -# -# -# -# -# Atom probe microscopes use controlled laser, voltage, -# or a combination of pulsing strategies to trigger the -# excitation and eventual field evaporation/emission of -# an ion during an experiment. -# -# -# -# Given name/alias. -# -# -# -# -# -# Nominal wavelength of the laser radiation. -# -# -# -# -# Nominal power of the laser source while illuminating the specimen. -# -# -# -# -# -# Average energy of the laser at peak of each pulse. -# -# -# -# -# Details about specific positions along the focused laser beam -# which illuminates the (atom probe) specimen. -# -# -# -# Track time-dependent settings over the course of the -# measurement how the laser beam in tip space/reconstruction space -# laser impinges on the sample, i.e. the mean vector is parallel to -# the laser propagation direction. -# -# -# -# -# Track time-dependent settings over the course of the -# measurement where the laser beam exits the -# focusing optics. -# -# -# -# -# Track time-dependent settings over the course of the -# measurement where the laser hits the specimen. -# -# -# -# -# -# Affine transformations which describe the geometry how the -# laser focusing optics/pinhole-attached coordinate system is -# defined, how it has to be transformed so that it aligns with -# the specimen coordinate system. -# A right-handed Cartesian coordinate system, the so-called laser space, -# should be assumed, whose positive z-axis points -# into the direction of the propagating laser beam. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXreflectron.yaml b/contributed_definitions/nyaml/NXreflectron.yaml deleted file mode 100644 index 85174758ce..0000000000 --- a/contributed_definitions/nyaml/NXreflectron.yaml +++ /dev/null @@ -1,87 +0,0 @@ -category: base -doc: | - Device for reducing flight time differences of ions in ToF experiments. - For atom probe the reflectron can be considered an energy_compensation - device, which can e.g. be realized technically as via a Poschenrieder lens - (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). -type: group -NXreflectron(NXobject): - name: - doc: | - Given name/alias. - (NXfabrication): - description: - doc: | - Free-text field to specify further details about the reflectron. - The field can be used to inform e. g. if the reflectron is flat or curved. - - # IFES_APT_TC "ReflectronVoltage: Real, 1xn array (V) Must be present if ReflectronInfo is not “None” The maximum voltage applied to the reflectron, relative to system ground." - (NXtransformations): - doc: | - Affine transformation(s) which detail where the reflectron - is located relative to e.g. the origin of the specimen space - reference coordinate system. - This group can also be used for specifying how the reflectron - is rotated relative to the specimen axis. - The purpose of these more detailed instrument descriptions - is to support the creation of a digital twin of the instrument - for computational science. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 6f932a14554bc463bc83d9d2da179443e89636ee2de15fce04bcf8c8950669ee -# -# -# -# -# -# Device for reducing flight time differences of ions in ToF experiments. -# For atom probe the reflectron can be considered an energy_compensation -# device, which can e.g. be realized technically as via a Poschenrieder lens -# (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). -# -# -# -# Given name/alias. -# -# -# -# -# -# Free-text field to specify further details about the reflectron. -# The field can be used to inform e. g. if the reflectron is flat or curved. -# -# -# -# -# -# Affine transformation(s) which detail where the reflectron -# is located relative to e.g. the origin of the specimen space -# reference coordinate system. -# This group can also be used for specifying how the reflectron -# is rotated relative to the specimen axis. -# The purpose of these more detailed instrument descriptions -# is to support the creation of a digital twin of the instrument -# for computational science. -# -# -# diff --git a/contributed_definitions/nyaml/NXsimilarity_grouping.yaml b/contributed_definitions/nyaml/NXsimilarity_grouping.yaml deleted file mode 100644 index 36c2607eb5..0000000000 --- a/contributed_definitions/nyaml/NXsimilarity_grouping.yaml +++ /dev/null @@ -1,290 +0,0 @@ -category: base -doc: | - Metadata to the results of a similarity grouping analysis. - - Similarity grouping analyses can be supervised segmentation or machine learning - clustering algorithms. These are routine methods which partition the member of - a set of objects/geometric primitives into (sub-)groups, features of - different type. A plethora of algorithms have been proposed which can be applied - also on geometric primitives like points, triangles, or (abstract) features aka - objects (including categorical sub-groups). - - This base class considers metadata and results of one similarity grouping - analysis applied to a set in which objects are either categorized as noise - or belonging to a cluster. - As the results of the analysis each similarity group, here called feature - aka object can get a number of numerical and/or categorical labels. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - c: | - Cardinality of the set. - n_lbl_num: | - Number of numerical labels per object. - n_lbl_cat: | - Number of categorical labels per object. - n_features: | - Total number of similarity groups aka features, objects, clusters. -type: group -NXsimilarity_grouping(NXobject): - cardinality(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of members in the set which is partitioned into features. - number_of_numeric_labels(NX_UINT): - unit: NX_UNITLESS - doc: | - How many numerical labels does each feature have. - number_of_categorical_labels(NX_UINT): - unit: NX_UNITLESS - doc: | - How many categorical labels does each feature have. - - # features: - # doc: | - # Reference to a set of features investigated in a cluster analysis. - # Features need to have disjoint numeric identifier. - identifier_offset(NX_UINT): - unit: NX_UNITLESS - doc: | - Which identifier is the first to be used to label a cluster. - - The value should be chosen in such a way that special values can be resolved: - * identifier_offset-1 indicates an object belongs to no cluster. - * identifier_offset-2 indicates an object belongs to the noise category. - Setting for instance identifier_offset to 1 recovers the commonly used - case that objects of the noise category get values to -1 and unassigned points to 0. - Numerical identifier have to be strictly increasing. - dimensions: - rank: 1 - dim: [[1, n_lbl_num]] - numerical_label(NX_UINT): - unit: NX_UNITLESS - doc: | - Matrix of numerical label for each member in the set. - For classical clustering algorithms this can for instance - encode the cluster_identifier. - dimensions: - rank: 2 - dim: [[1, c], [2, n_lbl_num]] - categorical_label(NX_CHAR): - doc: | - Matrix of categorical attribute data for each member in the set. - - # list instances of base classes of an applied cluster algorithm - # e.g. (NXclustering_hdbscan): - dimensions: - rank: 2 - dim: [[1, c], [2, n_lbl_cat]] - statistics(NXprocess): - doc: | - In addition to the detailed storage which members was grouped to which - feature/group summary statistics are stored under this group. - - # at the level of the set - number_of_unassigned_members(NX_UINT): - unit: NX_UNITLESS - doc: | - Total number of members in the set which are categorized as unassigned. - dimensions: - rank: 1 - dim: [[1, n_lbl_num]] - noise(NX_UINT): - unit: NX_UNITLESS - doc: | - Total number of members in the set which are categorized as noise. - dimensions: - rank: 1 - dim: [[1, n_lbl_num]] - - # at the level of the feature set - number_of_features(NX_UINT): - unit: NX_UNITLESS - doc: | - Total number of clusters (excluding noise and unassigned). - feature_identifier(NX_UINT): - unit: NX_UNITLESS - doc: | - Array of numerical identifier of each feature (cluster). - dimensions: - rank: 2 - dim: [[1, n_features], [2, n_lbl_num]] - feature_member_count(NX_UINT): - unit: NX_UNITLESS - doc: | - Array of number of members for each feature. - dimensions: - rank: 2 - dim: [[1, n_features], [2, n_lbl_num]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# b6a955e00d978d62e58fa73c93c262a104d7b49152e2a9cf054abbc8eaa1d46b -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Cardinality of the set. -# -# -# -# -# Number of numerical labels per object. -# -# -# -# -# Number of categorical labels per object. -# -# -# -# -# Total number of similarity groups aka features, objects, clusters. -# -# -# -# -# Metadata to the results of a similarity grouping analysis. -# -# Similarity grouping analyses can be supervised segmentation or machine learning -# clustering algorithms. These are routine methods which partition the member of -# a set of objects/geometric primitives into (sub-)groups, features of -# different type. A plethora of algorithms have been proposed which can be applied -# also on geometric primitives like points, triangles, or (abstract) features aka -# objects (including categorical sub-groups). -# -# This base class considers metadata and results of one similarity grouping -# analysis applied to a set in which objects are either categorized as noise -# or belonging to a cluster. -# As the results of the analysis each similarity group, here called feature -# aka object can get a number of numerical and/or categorical labels. -# -# -# -# Number of members in the set which is partitioned into features. -# -# -# -# -# How many numerical labels does each feature have. -# -# -# -# -# How many categorical labels does each feature have. -# -# -# -# -# -# Which identifier is the first to be used to label a cluster. -# -# The value should be chosen in such a way that special values can be resolved: -# * identifier_offset-1 indicates an object belongs to no cluster. -# * identifier_offset-2 indicates an object belongs to the noise category. -# Setting for instance identifier_offset to 1 recovers the commonly used -# case that objects of the noise category get values to -1 and unassigned points to 0. -# Numerical identifier have to be strictly increasing. -# -# -# -# -# -# -# -# Matrix of numerical label for each member in the set. -# For classical clustering algorithms this can for instance -# encode the cluster_identifier. -# -# -# -# -# -# -# -# -# Matrix of categorical attribute data for each member in the set. -# -# -# -# -# -# -# -# -# -# In addition to the detailed storage which members was grouped to which -# feature/group summary statistics are stored under this group. -# -# -# -# -# Total number of members in the set which are categorized as unassigned. -# -# -# -# -# -# -# -# Total number of members in the set which are categorized as noise. -# -# -# -# -# -# -# -# -# Total number of clusters (excluding noise and unassigned). -# -# -# -# -# Array of numerical identifier of each feature (cluster). -# -# -# -# -# -# -# -# -# Array of number of members for each feature. -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXspatial_filter.yaml b/contributed_definitions/nyaml/NXspatial_filter.yaml deleted file mode 100644 index f78214d27f..0000000000 --- a/contributed_definitions/nyaml/NXspatial_filter.yaml +++ /dev/null @@ -1,134 +0,0 @@ -category: base -doc: | - Spatial filter to filter entries within a region-of-interest based on their - position. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_ellipsoids: | - Number of ellipsoids. - n_hexahedra: | - Number of hexahedra. - n_cylinders: | - Number of cylinders. - -# n_polyhedra: Number of polyhedra. -# n_vertices: Number of vertices for polyhedra. -# n_facets: Number of facets for polyhedra. -type: group -NXspatial_filter(NXobject): - windowing_method: - doc: | - Qualitative statement which specifies which spatial filtering with respective - geometric primitives or bitmask is used. These settings are possible: - - * entire_dataset, no filter is applied, the entire dataset is used. - * union_of_primitives, a filter with (rotated) geometric primitives. - All ions in or on the surface of the primitives are considered - while all other ions are ignored. - * bitmasked_points, a boolean array whose bits encode with 1 - which ions should be included. Those ions whose bit is set to 0 - will be excluded. Users of python can use the bitfield operations - of the numpy package to define such bitfields. - - Conditions: - In the case that windowing_method is entire_dataset all entries are processed. - In the case that windowing_method is union_of_primitives, - it is possible to specify none or all types of primitives - (ellipsoids, cylinder, hexahedra). If no primitives are specified - the filter falls back to entire_dataset. - In the case that windowing_method is bitmask, the bitmask has to be defined; - otherwise the filter falls back to entire dataset. - enumeration: [entire_dataset, union_of_primitives, bitmask] - (NXcg_ellipsoid_set): - (NXcg_cylinder_set): - (NXcg_hexahedron_set): - (NXcs_filter_boolean_mask): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 791b662f16e375b77792d796be1d1f955b3d65c46016e3ecde10353845d23079 -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of ellipsoids. -# -# -# -# -# Number of hexahedra. -# -# -# -# -# Number of cylinders. -# -# -# -# -# Spatial filter to filter entries within a region-of-interest based on their -# position. -# -# -# -# Qualitative statement which specifies which spatial filtering with respective -# geometric primitives or bitmask is used. These settings are possible: -# -# * entire_dataset, no filter is applied, the entire dataset is used. -# * union_of_primitives, a filter with (rotated) geometric primitives. -# All ions in or on the surface of the primitives are considered -# while all other ions are ignored. -# * bitmasked_points, a boolean array whose bits encode with 1 -# which ions should be included. Those ions whose bit is set to 0 -# will be excluded. Users of python can use the bitfield operations -# of the numpy package to define such bitfields. -# -# Conditions: -# In the case that windowing_method is entire_dataset all entries are processed. -# In the case that windowing_method is union_of_primitives, -# it is possible to specify none or all types of primitives -# (ellipsoids, cylinder, hexahedra). If no primitives are specified -# the filter falls back to entire_dataset. -# In the case that windowing_method is bitmask, the bitmask has to be defined; -# otherwise the filter falls back to entire dataset. -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXsubsampling_filter.yaml b/contributed_definitions/nyaml/NXsubsampling_filter.yaml deleted file mode 100644 index bd41ca04ff..0000000000 --- a/contributed_definitions/nyaml/NXsubsampling_filter.yaml +++ /dev/null @@ -1,71 +0,0 @@ -category: base -doc: | - Settings of a filter to sample entries based on their value. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXsubsampling_filter(NXobject): - linear_range_min_incr_max(NX_UINT): - unit: NX_UNITLESS - doc: | - Triplet of the minimum, increment, and maximum value which will - be included in the analysis. The increment controls which n-th entry to take. - - Take as an example a dataset with 100 entries (their indices start at zero) - and the filter set to 0, 1, 99. This will process each entry. - 0, 2, 99 will take each second entry. 90, 3, 99 will take only each third - entry beginning from entry 90 up to 99. - dimensions: - rank: 1 - dim: [[1, 3]] - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8b2ae0d8e8fbb65aa0b1e6f7cf5ea78417bf28ad83373f3401b159c41ef7c24c -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Settings of a filter to sample entries based on their value. -# -# -# -# Triplet of the minimum, increment, and maximum value which will -# be included in the analysis. The increment controls which n-th entry to take. -# -# Take as an example a dataset with 100 entries (their indices start at zero) -# and the filter set to 0, 1, 99. This will process each entry. -# 0, 2, 99 will take each second entry. 90, 3, 99 will take only each third -# entry beginning from entry 90 up to 99. -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/refactor/NXapm.yaml similarity index 100% rename from contributed_definitions/nyaml/NXapm.yaml rename to contributed_definitions/nyaml/refactor/NXapm.yaml diff --git a/contributed_definitions/nyaml/NXapm_composition_space_results.yaml b/contributed_definitions/nyaml/refactor/NXapm_composition_space_results.yaml similarity index 100% rename from contributed_definitions/nyaml/NXapm_composition_space_results.yaml rename to contributed_definitions/nyaml/refactor/NXapm_composition_space_results.yaml diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_clusterer.yaml similarity index 100% rename from contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.yaml rename to contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_clusterer.yaml diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_distancer.yaml similarity index 100% rename from contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.yaml rename to contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_distancer.yaml diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_intersector.yaml similarity index 100% rename from contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.yaml rename to contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_intersector.yaml diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_nanochem.yaml similarity index 100% rename from contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml rename to contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_nanochem.yaml diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_ranger.yaml similarity index 100% rename from contributed_definitions/nyaml/NXapm_paraprobe_config_ranger.yaml rename to contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_ranger.yaml diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_selector.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_selector.yaml similarity index 100% rename from contributed_definitions/nyaml/NXapm_paraprobe_config_selector.yaml rename to contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_selector.yaml diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_spatstat.yaml similarity index 100% rename from contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml rename to contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_spatstat.yaml diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_surfacer.yaml similarity index 100% rename from contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml rename to contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_surfacer.yaml diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_tessellator.yaml similarity index 100% rename from contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml rename to contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_tessellator.yaml diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_clusterer.yaml similarity index 100% rename from contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.yaml rename to contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_clusterer.yaml diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_distancer.yaml similarity index 100% rename from contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.yaml rename to contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_distancer.yaml diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_intersector.yaml similarity index 100% rename from contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.yaml rename to contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_intersector.yaml diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_nanochem.yaml similarity index 100% rename from contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml rename to contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_nanochem.yaml diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_ranger.yaml similarity index 100% rename from contributed_definitions/nyaml/NXapm_paraprobe_results_ranger.yaml rename to contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_ranger.yaml diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_selector.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_selector.yaml similarity index 100% rename from contributed_definitions/nyaml/NXapm_paraprobe_results_selector.yaml rename to contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_selector.yaml diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_spatstat.yaml similarity index 100% rename from contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.yaml rename to contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_spatstat.yaml diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_surfacer.yaml similarity index 100% rename from contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.yaml rename to contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_surfacer.yaml diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_tessellator.yaml similarity index 100% rename from contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.yaml rename to contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_tessellator.yaml diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_tool_config.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_tool_config.yaml new file mode 100644 index 0000000000..d19d645bea --- /dev/null +++ b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_tool_config.yaml @@ -0,0 +1,76 @@ +category: base +doc: | + Base class documenting the configuration of a tool from the paraprobe-toolbox. + + The paraprobe-toolbox is a collection of open-source tools for performing + efficient analyses of point cloud data where each point can represent atoms or + (molecular) ions. A key application of the toolbox has been for research in the + field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): + + * `paraprobe-toolbox `_ + * `M. Kühbach et al. `_ + + The toolbox does not replace but complements existent software tools in this + research field. Given its capabilities of handling points as objects with + properties and enabling analyses of the spatial arrangement of and inter- + sections between geometric primitives, the software can equally be used + for analyzing data in materials science and materials engineering. + + The configuration and results of a run of a tool from the toolbox is documented + using binary container formats. Currently, paraprobe-toolbox uses the Hierarchical + Data Format 5 (HDF5) for this purpose. +# container formats typically use graphs - trees to be more specific - to organize +# metadata and data. Information is granularized via labelled property graphs. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXapm_paraprobe_tool_config(NXprocess): + # sequence_id is inherited from NXprocess + (NXidentifier): + analysis_identifier(NX_UINT): + doc: | + Internal identifier by the tool. + unit: NX_UNITLESS + description(NX_CHAR): + doc: | + Possibility for leaving a free-text description about this analysis. + results_path(NX_CHAR): + doc: | + Path to where the tool should store tool-specific results. + If not specified results will be stored in the current working directory. + time_stamp(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when this configuration file was created. + reconstruction(NXserialized): + doc: | + Specification of the tomographic reconstruction to use for this analysis. + + Typically, reconstructions in the field of atom probe tomography are communicated + via files which store reconstructed ion positions and mass-to-charge-state-ratio values. + Container files like HDF5 though can store multiple reconstructions. + Position and mass_to_charge point to specific instances to use for this analysis. + position(NX_CHAR): + doc: | + Name of the node which resolves the reconstructed ion position + values to use for this analysis. + mass_to_charge(NX_CHAR): + doc: | + Name of the node which resolves the mass-to-charge-state-ratio + values to use for this analysis. + iontypes(NXserialized): + doc: | + Specification of the ranging definitions to use for this analysis. + + Ranging is the process of labeling time-of-flight data with so-called iontypes. + Iontypes ideally specify the most likely (molecular) ion that is assumed of having + been evaporated and laying within a mass-to-charge-state-ratio value interval. + + The so-called UNKNOWNTYPE iontype represents the null model of an event/ion + that has not been ranged. The identifier of this special iontype is always 0. + ranging_definitions(NX_CHAR): + doc: | + Name of the (parent) node directly below which (in the hierarchy) + the ranging definition for (molecular) ions are stored. + performance(NXcs_profiling): diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_tool_results.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_tool_results.yaml new file mode 100644 index 0000000000..902587d439 --- /dev/null +++ b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_tool_results.yaml @@ -0,0 +1,90 @@ +category: base +doc: | + Base class documenting the results of a tool from the paraprobe-toolbox. + + The paraprobe-toolbox is a collection of open-source tools for performing + efficient analyses of point cloud data where each point can represent atoms or + (molecular) ions. A key application of the toolbox has been for research in the + field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): + + * `paraprobe-toolbox `_ + * `M. Kühbach et al. `_ + + The toolbox does not replace but complements existent software tools in this + research field. Given its capabilities of handling points as objects with + properties and enabling analyses of the spatial arrangement of and inter- + sections between geometric primitives, the software can equally be used + for analyzing data in materials science and materials engineering. + + The configuration and results of a run of a tool from the toolbox is documented + using binary container formats. Currently, paraprobe-toolbox uses the Hierarchical + Data Format 5 (HDF5) for this purpose. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXapm_paraprobe_tool_results(NXprocess): + (NXidentifier): + analysis_identifier(NX_UINT): + doc: | + Internal identifier by the tool. + unit: NX_UNITLESS + (NXprogram): + performance(NXcs_profiling): + description(NX_CHAR): + doc: | + Possibility for leaving a free-text description about this analysis. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file was + started, i.e. the respective executable of the tool started as a process. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and the respective process of the tool executable + exited. + config(NXserialized): + doc: | + The configuration that was used to parameterize the algorithms + which the tool executes. + results_path(NX_CHAR): + doc: | + Path to where the tool should store tool-specific results. + If not specified results will be stored in the current working directory. + status(NX_CHAR): + doc: | + A statement whether the tool executable managed to process the + analysis or failed prematurely. + + This status is written to the results file after the end_time + at which point the executable must not compute any further analysis + results before exiting as a process. + + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be that + the executable has terminated prematurely or another error occurred. + enumeration: [success, failure] + (NXuser): + (NXcoordinate_system_set): + doc: | + Details about coordinate systems used. In atom probe several coordinate + systems have to be distinguished. Names of instances of :ref:`NXcoordinate_system` + are picked from the following controlled set of names: + + * paraprobe + * lab + * specimen + * laser + * instrument + * detector + * recon + + The aim of this convention is to support users with contextualizing what and + which reference frame each instance (coordinate system) is. If need instances of + :ref:`NXtranslation` are used to transform between different reference frames. + (NXcoordinate_system): + # add further fields coming from using the charge state recovery + # workflow from the ifes_apt_tc_data_modeling library + ##MK::end of the tool-specific section diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_transcoder_config.yaml similarity index 100% rename from contributed_definitions/nyaml/NXapm_paraprobe_config_transcoder.yaml rename to contributed_definitions/nyaml/refactor/NXapm_paraprobe_transcoder_config.yaml diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_transcoder_results.yaml similarity index 100% rename from contributed_definitions/nyaml/NXapm_paraprobe_results_transcoder.yaml rename to contributed_definitions/nyaml/refactor/NXapm_paraprobe_transcoder_results.yaml diff --git a/contributed_definitions/nyaml/refactor/NXcg_marching_cubes.yaml b/contributed_definitions/nyaml/refactor/NXcg_marching_cubes.yaml new file mode 100644 index 0000000000..bf0e5047d2 --- /dev/null +++ b/contributed_definitions/nyaml/refactor/NXcg_marching_cubes.yaml @@ -0,0 +1,30 @@ +category: base +doc: | + Computational geometry description of the marching cubes (MC) algorithm. + + Documenting which specific version was used helps with understanding + how robust the results are with respect to the topology of the triangulation. +# symbols: +type: group +NXcg_marching_cubes(NXobject): + grid(NXcg_grid): + doc: | + Metadata of the grid on which the here specified MC is operating. + (NXidentifier): + doc: | + Reference to the specific implementation of marching cubes used. + + See for example the following papers for details about specific + MC implementations: + + * `W. E. Lorensen `_ + * `T. S. Newman and H. Yi `_ + + description(NX_CHAR): + doc: | + Free text field in case a proper identifier is not available. + (NXprogram): + + # we could also think about storing the rule sets in here explicitly including the + # coordinate system conventions; however, the problem is that many commercial + # tools like Matlab do not expose the rule set. diff --git a/contributed_definitions/nyaml/refactor/NXdelocalization.yaml b/contributed_definitions/nyaml/refactor/NXdelocalization.yaml new file mode 100644 index 0000000000..a25b57b091 --- /dev/null +++ b/contributed_definitions/nyaml/refactor/NXdelocalization.yaml @@ -0,0 +1,90 @@ +category: base +doc: | + Base class to describe settings and results of a delocalization algorithm. + + Delocalization is used to distribute point-like objects on a grid to obtain + e.g. count, composition, or concentration values of scalar fields and + compute gradients of these fields. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_p: | + Number of points/objects. + n_m: | + Number of mark data per point/object. + n_atoms: | + Number of atoms in the whitelist. + n_isotopes: | + Number of isotopes in the whitelist. +type: group +NXdelocalization(NXobject): + (NXcg_grid): + doc: | + Details about the grid on which the delocalization is applied. + # grid(NX_CHAR): + # doc: | + # Reference or link to the grid on which the delocalization is applied. + # objects(NX_CHAR): + # doc: | + # Reference or link to the points which are delocalized on the grid. + + # for APM the speciality is nothing but: + # each point marks the location of an ion (object) in the tomographic reconstruction + # there is a boolean mask which filters which ions, i.e. points are considered + # plus there is a weight interpretation model, specifically in atom probe + # if a (molecular) ion is decomposed into its atoms or isotopes + # plus, given there is such a weight interpretation model, there is a weight + # associated, specifically an integer >= 1 with each considered ion and 0 for + # all ions which are not considered, + # this weight is the multiplicity with respect to the interpretation model + # i.e. a C:2 molecular ion has a multiplicity of 2 if the ion is considered + # and the interpretation model that to consider carbon atoms or carbon ions + weighting_model(NX_CHAR): + doc: | + The weighting model specifies how mark data are mapped to a weight per point/object. + For atom probe microscopy (APM) as an example, different models are used which + account differently for the multiplicity of an ion/atom: + + * default, points all get the same weight 1.; + for APM this is equivalent to ion species based delocalization + * atomic_decomposition, points get as much weight as they have atoms + of a type in element_whitelist, + * isotope_decomposition, points get as much weight as they have + isotopes of a type in isotope_whitelist. + + This description shows an example that could be reinterpreted for + similar such data processing steps in other fields of science. + enumeration: [default, atomic_decomposition, isotope_decomposition] + # other + # can one conditionally set a field required if a weighting_model has a + # specific value, + # i.e. if atomic_decomposition is set element_whitelist t is required + # i.e. if isotope_decomposition is set isotope_whitelist is required? + element_whitelist(NX_UINT): + doc: | + A list of elements (via proton number) to consider for the atomic_decomposition + weighting model. Elements must exist in the periodic table of elements. + unit: NX_UNITLESS + dim: (n_atoms,) + isotope_whitelist(NX_UINT): + doc: | + A list of isotopes to consider for the isotope_decomposition weighting model. + Isotopes must exist in the nuclid table. Entries in the fastest changing + dimension should be the pair of proton (first entry) and neutron number + (second entry). + unit: NX_UNITLESS + dim: (n_isotopes, 2) + mark(NX_NUMBER): + doc: | + Attribute data for each member of the point cloud. For APM these are the + ion species labels generated via ranging. The number of mark data per + point is 1 in the case for atom probe. + unit: NX_UNITLESS + dim: (n_p, n_m) + weight(NX_NUMBER): + doc: | + Weighting factor with which the integrated intensity per grid cell is + multiplied specifically for each point/object. For APM the weight are + positive integer values, specifically the multiplicity of the ion, + according to the details of the weighting_model. + unit: NX_UNITLESS diff --git a/contributed_definitions/nyaml/NXion.yaml b/contributed_definitions/nyaml/refactor/NXion.yaml similarity index 65% rename from contributed_definitions/nyaml/NXion.yaml rename to contributed_definitions/nyaml/refactor/NXion.yaml index 360f925566..bd3cb7b6a9 100644 --- a/contributed_definitions/nyaml/NXion.yaml +++ b/contributed_definitions/nyaml/refactor/NXion.yaml @@ -1,6 +1,6 @@ category: base doc: | - Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. + Set of atoms of a molecular ion or fragment assumed observed. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -26,37 +26,34 @@ NXion(NXobject): unit: NX_UNITLESS isotope_vector(NX_UINT): doc: | - A vector of isotope hash values. These values have to be stored in an array, - sorted in decreasing order. The array is filled with zero hash values - indicating unused places. The individual hash values are built with the - following hash function: + Row vector of isotope hash values. The individual hash values are + built with the following hash function: The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` the number of protons and :math:`N` the number of neutrons - of each isotope respectively. + of each isotope respectively. Z and N have to be 8-bit unsigned integers. - Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) `_ + The array is stored sorted in decreasing order with unused values nullified. + initialized to zero. For the rationale behind this `M. Kühbach et al. (2021) `_ unit: NX_UNITLESS dim: (1, n_ivecmax) nuclid_list(NX_UINT): doc: | - A supplementary row vector which decodes the isotope_vector into - a human-readable matrix of nuclids with the following formatting: - + Table which decodes the isotope_vector into a human-readable matrix of nuclids. The first row specifies the isotope mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N`. As an example for a - carbon-14 isotope the number is 14. - The second row specifies the number of protons :math:`Z`, e.g. 6 for the - carbon-14 example. This row matrix is thus mapping the notation of - using superscribed isotope mass and subscripted number of protons - to identify isotopes. - Unused places filling up to n_ivecmax need to be filled with zero. + from the isotope_vector this is :math:`Z + N`. + Taking a carbon-14 nuclid as an example the number is 14. + The second row specifies the number of protons :math:`Z`, e.g. 6 as + for the carbon-14 example. + This notation is thus mapping the notation of using superscribed + isotope mass and subscripted number of protons to identify nuclids. + + The array is stored matching the order of isotope_vector with unused values nullified. unit: NX_UNITLESS dim: (2, n_ivecmax) - color(NX_CHAR): - doc: | - Color code used for visualizing such ions. + # color(NX_CHAR): + # doc: | + # Color code used for visualizing such ions. volume(NX_NUMBER): doc: | Assumed volume of the ion. @@ -74,8 +71,8 @@ NXion(NXobject): doc: | Signed charge state of the ion in multiples of electron charge. - Only positive values will be measured in atom probe microscopy as the - ions are accelerated by a negatively signed bias electric field. + Only positive values will be measured in atom probe microscopy + as the ions are accelerated by a negatively signed bias electric field. In the case that the charge state is not explicitly recoverable, the value should be set to zero. @@ -84,10 +81,6 @@ NXion(NXobject): These file formats do not document the charge state explicitly. They report the number of atoms of each element per molecular ion surplus the mass-to-charge-state-ratio interval. - With this information it is possible to recover the charge state only - for specific molecular ions as the accumulated mass of the molecular ion - is defined by the isotopes, which without knowing the charge, leads - to an underconstrained problem. Details on ranging can be found in the literature: `M. K. Miller `_ unit: NX_UNITLESS name(NX_CHAR): @@ -104,7 +97,7 @@ NXion(NXobject): Associated lower (mqmin) and upper (mqmax) bounds of the mass-to-charge-state ratio interval(s) [mqmin, mqmax] (boundaries inclusive). This field is primarily of interest - for documenting :ref:`NXprocess` steps of indexing a ToF/mass-to-charge - state histogram. + for documenting :ref:`NXprocess` steps of indexing a + ToF/mass-to-charge state histogram. unit: NX_ANY # NX_DALTON dim: (n_ranges, 2) diff --git a/contributed_definitions/nyaml/refactor/NXisocontour.yaml b/contributed_definitions/nyaml/refactor/NXisocontour.yaml new file mode 100644 index 0000000000..3a222ff8d5 --- /dev/null +++ b/contributed_definitions/nyaml/refactor/NXisocontour.yaml @@ -0,0 +1,39 @@ +category: base +doc: | + Computational geometry description of isocontouring/phase-fields in Euclidean space. + + Iso-contouring algorithms such as MarchingCubes and others are frequently + used to segment d-dimensional regions at crossings of a threshold value, + the so-called isovalue. + + In Computational Materials Science phase-field methods are frequently used. + Many of the implementations of this methods discretize on regular grids. + + Isocontour algorithms are often used in such context to pinpoint the + locations of microstructural features from this implicit phase-field- + variable-based description. + + One of the key intentions of this base class is to provide a starting point + for scientists from the phase-field community (condensed-matter physicists, + and materials engineers) to incentivize that also phase-field (and other) + simulation data can take advantage of NeXus base class to improve + interoperability. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + d: | + The dimensionality of the description. +type: group +NXisocontour(NXobject): + dimensionality(NX_POSINT): + doc: | + The dimensionality of the space in which the isocontour is embedded. + unit: NX_UNITLESS + enumeration: [1, 2, 3] + grid(NXcg_grid): + doc: | + The discretized grid on which the iso-contour algorithm operates. + isovalue(NX_NUMBER): + doc: | + The threshold or iso-contour value. + unit: NX_ANY diff --git a/contributed_definitions/nyaml/refactor/NXmatch_filter.yaml b/contributed_definitions/nyaml/refactor/NXmatch_filter.yaml new file mode 100644 index 0000000000..8e4d019a8a --- /dev/null +++ b/contributed_definitions/nyaml/refactor/NXmatch_filter.yaml @@ -0,0 +1,26 @@ +category: base +doc: | + Settings of a filter to select entries based on their value. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_values: | + How many different match values does the filter specify. +type: group +NXmatch_filter(NXobject): + method: + doc: | + Logical operation of the filter: + Whitelist specifies which entries with said value to include. + Entries with all other values will be excluded. + + Blacklist specifies which entries with said value to exclude. + Entries with all other values will be included. + enumeration: [whitelist, blacklist] + match(NX_NUMBER): + doc: | + Array of values to filter according to method. If the match e.g. specifies + [1, 5, 6] and method is set to whitelist only entries with values matching + 1, 5 or 6 will be processed. All other entries will be excluded. + unit: NX_UNITLESS + dim: (n_values,) diff --git a/contributed_definitions/nyaml/refactor/NXpeak.yaml b/contributed_definitions/nyaml/refactor/NXpeak.yaml new file mode 100644 index 0000000000..7b3dbc313b --- /dev/null +++ b/contributed_definitions/nyaml/refactor/NXpeak.yaml @@ -0,0 +1,42 @@ +category: base +doc: | + Description of peaks, their functional form, and measured support. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_support: | + Number of support points +type: group +NXpeak(NXobject): + label(NX_CHAR): + doc: | + Human-readable label which specifies which concept/entity + the peak represents/identifies. + peak_model(NX_CHAR): + doc: | + Is the peak described analytically via a functional form + or is it empirically defined via measured/reported + intensity/counts as a function of an independent variable. + + If the functional form is not empirical or Gaussians, users + should enter other for the peak_model and add relevant details + in the NXcollection. + enumeration: [empirical, gaussian, lorentzian, other] + position(NX_NUMBER): + doc: | + In the case of an empirical description of the peak and its shoulders, + this array holds the position values for the independent variable. + unit: NX_ANY + dim: (n_support,) + intensity(NX_NUMBER): + doc: | + In the case of an empirical description of the peak and its shoulders, + this array holds the intensity/count values at each position. + unit: NX_ANY + dim: (n_support,) + (NXcollection): + doc: | + In the case of an analytical description (or if peak_model is other) this + collection holds parameter of (and eventually) the functional form. + For example in the case of Gaussians mu, sigma, cut-off values, + and background intensity are relevant parameter. diff --git a/contributed_definitions/nyaml/refactor/NXpulser_apm.yaml b/contributed_definitions/nyaml/refactor/NXpulser_apm.yaml new file mode 100644 index 0000000000..52de0fb26b --- /dev/null +++ b/contributed_definitions/nyaml/refactor/NXpulser_apm.yaml @@ -0,0 +1,105 @@ +category: base +doc: | + Metadata for laser- and/or voltage-pulsing in atom probe microscopy. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_events: | + Total number of events along a time trajectory. + Interpretation depends on details of the specific field. + n_ions: | + Total number of ions collected. +type: group +NXpulser_apm(NXobject): + (NXfabrication): + pulse_mode: + doc: | + How is field evaporation physically triggered. + enumeration: [laser, voltage, laser_and_voltage] + pulse_frequency(NX_FLOAT): + doc: | + Frequency with which the high voltage or laser pulser fires. + + For this and other fields whose dimensions are parameterized + with n_events these values can change over the course of the experiment. + In the simplest case the field stores a scalar value that is ideally + the actual value not the set value. + # APT HDF defines it therefore as follows: "PulseFrequency : Real array, 2xn (Hz) This is the frequency of the high voltage or laser pulser. first entry : first pulse number where the spacing between this and all subsequent pulses are considered to be at the selected frequency. Each first entry must be strictly increasing in value. The second entry contains the frequency value" as data can be compressed in this case very efficiently we go for with an array of length 1xn_ions + dim: (n_events,) + pulse_fraction(NX_FLOAT): + doc: | + Fraction of the pulse_voltage that is applied in addition + to the standing_voltage at peak voltage of a pulse. + + If a standing voltage is applied, this gives nominal pulse fraction + (as a function of standing voltage). Otherwise, + this field should not be present. + unit: NX_DIMENSIONLESS + dim: (n_events,) + pulsed_voltage(NX_FLOAT): + doc: | + In laser pulsing mode the values will be zero so the this field is recommended. + However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. + unit: NX_VOLTAGE + dim: (n_ions,) + pulse_number(NX_UINT): + unit: NX_UNITLESS + doc: | + Absolute number of pulses starting from the beginning of the experiment. + dim: (n_ions,) + standing_voltage(NX_FLOAT): + doc: | + Direct current voltage between the specimen and the (local electrode) in + the case of local electrode atom probe (LEAP) instrument. Otherwise, the + standing voltage applied to the sample, relative to system ground. + unit: NX_VOLTAGE + dim: (n_ions,) + (NXsource): + 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. + name(NX_CHAR): + doc: | + Given name/alias. + (NXfabrication): + wavelength(NX_FLOAT): + doc: | + Nominal wavelength of the laser radiation. + unit: NX_WAVELENGTH + power(NX_FLOAT): + doc: | + Nominal power of the laser source while illuminating the specimen. + unit: NX_POWER + # NEW ISSUE: needs clearer specification/definition + pulse_energy(NX_FLOAT): + doc: | + Average energy of the laser at peak of each pulse. + unit: NX_ENERGY + (NXbeam): + doc: | + Details about specific positions along the focused laser beam + which illuminates the (atom probe) specimen. + incidence_vector(NXcollection): + doc: | + Track time-dependent settings over the course of the + measurement how the laser beam in tip space/reconstruction space + laser impinges on the sample, i.e. the mean vector is parallel to + the laser propagation direction. + pinhole_position(NXcollection): + doc: | + Track time-dependent settings over the course of the + measurement where the laser beam exits the + focusing optics. + spot_position(NXcollection): + doc: | + Track time-dependent settings over the course of the + measurement where the laser hits the specimen. + (NXtransformations): + doc: | + Affine transformations which describe the geometry how the + laser focusing optics/pinhole-attached coordinate system is + defined, how it has to be transformed so that it aligns with + the specimen coordinate system. + A right-handed Cartesian coordinate system, the so-called laser space, + should be assumed, whose positive z-axis points + into the direction of the propagating laser beam. diff --git a/contributed_definitions/nyaml/refactor/NXreflectron.yaml b/contributed_definitions/nyaml/refactor/NXreflectron.yaml new file mode 100644 index 0000000000..2733213c0a --- /dev/null +++ b/contributed_definitions/nyaml/refactor/NXreflectron.yaml @@ -0,0 +1,32 @@ +category: base +doc: | + Device for reducing flight time differences of ions in ToF experiments. + + For atom probe the reflectron can be considered an energy_compensation + device, which can e.g. be realized technically as via a Poschenrieder lens + + Consult the following U.S. patents for further details: + + * 3863068 and 6740872 for the reflectron + * 8134119 for the curved reflectron + +type: group +NXreflectron(NXobject): + name(NX_CHAR): + doc: | + Given name/alias. + (NXfabrication): + description(NX_CHAR): + doc: | + Free-text field to specify further details about the reflectron. + The field can be used to inform e. g. if the reflectron is flat or curved. + # IFES_APT_TC "ReflectronVoltage: Real, 1xn array (V) Must be present if ReflectronInfo is not “None” The maximum voltage applied to the reflectron, relative to system ground." + (NXtransformations): + doc: | + Affine transformation(s) which detail where the reflectron is located relative + to e.g. the origin of the specimen space reference coordinate system. + This group can also be used for specifying how the reflectron + is rotated relative to a given axis in the instrument. + # The purpose of these more detailed instrument descriptions + # is to support the creation of a digital twin of the instrument + # for computational science. diff --git a/contributed_definitions/nyaml/refactor/NXsimilarity_grouping.yaml b/contributed_definitions/nyaml/refactor/NXsimilarity_grouping.yaml new file mode 100644 index 0000000000..d00cf0b627 --- /dev/null +++ b/contributed_definitions/nyaml/refactor/NXsimilarity_grouping.yaml @@ -0,0 +1,123 @@ +category: base +doc: | + Base class to store results obtained from applying a similarity grouping (clustering) algorithm. + + Similarity grouping algorithms are segmentation or machine learning algorithms for + partitioning the members of a set of objects (e.g. geometric primitives) into (sub-)groups + aka features of some but different kind/type. A plethora of algorithms exists. + + This base class considers metadata and results of having a similarity grouping + algorithm applied to a set in which objects are either categorized as noise + or belonging to a cluster, i.e. members of a cluster. + The algorithm assigns each similarity group (feature/cluster) at least one identifier + (numerical or categorical labels) to distinguish different groups. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + c: | + Cardinality of the set. + n_lbl_num: | + Number of numerical labels per object. + n_lbl_cat: | + Number of categorical labels per object. + n_features: | + Total number of similarity groups aka features/clusters. +type: group +NXsimilarity_grouping(NXobject): + cardinality(NX_UINT): + doc: | + Number of members in the set which gets partitioned into features. + unit: NX_UNITLESS + number_of_numeric_labels(NX_UINT): + doc: | + How many numerical labels does each feature have. + unit: NX_UNITLESS + # dim: (i,) + number_of_categorical_labels(NX_UINT): + doc: | + How many categorical labels does each feature have. + unit: NX_UNITLESS + # dim: (i,) + # features: + # doc: | + # Reference to a set of features investigated in a cluster analysis. + # Features need to have disjoint numeric identifier. + identifier_offset(NX_INT): + doc: | + Which numerical identifier is the first to be used to label a feature. + + The value should be chosen in such a way that special values can be resolved: + * identifier_offset-1 indicates that an object belongs to no cluster. + * identifier_offset-2 indicates that an object belongs to the noise category. + Setting for instance identifier_offset to 1 recovers the commonly used + case that objects of the noise category get values to -1 and unassigned points to 0. + Numerical identifier have to be strictly increasing. + unit: NX_UNITLESS + dim: (n_lbl_num,) + numerical_label(NX_INT): + doc: | + Matrix of numerical label for each member in the set. + For classical clustering algorithms this can for instance + encode the cluster_identifier. + unit: NX_UNITLESS + dim: (c, n_lbl_num) + categorical_label(NX_CHAR): + doc: | + Matrix of categorical attribute data for each member in the set. + dim: (c, n_lbl_cat) + statistics(NXprocess): + doc: | + In addition to the detailed storage which objects were grouped to which + feature/group summary statistics are stored under this group. + # at the level of the object set + + # at the level of the feature set + unassigned(NX_UINT): + doc: | + Total number of features categorized as unassigned. + unit: NX_UNITLESS + noise(NX_UINT): + doc: | + Total number of features categorized as noise. + unit: NX_UNITLESS + total(NX_UINT): + doc: | + Total number of features. + unit: NX_UNITLESS +# number_of_unassigned_members(NX_UINT): +# doc: | +# Total number of members in the set which are categorized as unassigned. +# unit: NX_UNITLESS +# dim: (n_lbl_num,) +# number_of_noise_members(NX_UINT): +# doc: | +# Total number of members in the set which are categorized as noise. +# unit: NX_UNITLESS +# dim: (n_lbl_num,) + # at the level of the feature set + number_of_features(NX_UINT): + doc: | + Total number of clusters (excluding noise and unassigned). + unit: NX_UNITLESS + feature_identifier(NX_UINT): + doc: | + Array of numerical identifier of each feature (cluster). + unit: NX_UNITLESS + dim: (n_features, n_lbl_num) + feature_member_count(NX_UINT): + doc: | + Array of number of objects for each feature. + unit: NX_UNITLESS + dim: (n_features, n_lbl_num) +# feature_size(NX_NUMBER): +# doc: | +# unit: NX_UNITLESS +# doc: | +# Number of objects associated to each cluster. The labels are implicit, +# meaning the zeroth/first entry in the array belongs to the first cluster, +# the second entry to the second cluster and so on and so forth. +# The first cluster has the value of identifier_offset as its identifier. +# The second cluster has identifier_offset + 1, and so on and so forth. +# dimensions: +# rank: 1 +# dim: [[1, n_cluster]] diff --git a/contributed_definitions/nyaml/refactor/NXspatial_filter.yaml b/contributed_definitions/nyaml/refactor/NXspatial_filter.yaml new file mode 100644 index 0000000000..023367a9c2 --- /dev/null +++ b/contributed_definitions/nyaml/refactor/NXspatial_filter.yaml @@ -0,0 +1,47 @@ +category: base +doc: | + Spatial filter to filter objects within a region-of-interest (ROI) based position. + + Objects can be points, other geometric primitives or objecs composed from + other geometric primitives. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_hexahedra: | + Number of hexahedra. + n_cylinders: | + Number of cylinders. + n_ellipsoids: | + Number of ellipsoids. + n_polyhedra: | + Number of polyhedra. +# n_vertices: Number of vertices for polyhedra. +# n_facets: Number of facets for polyhedra. +type: group +NXspatial_filter(NXobject): + windowing_method(NX_CHAR): + doc: | + Qualitative statement which describes the logical operations + that define which objects will be included and which excluded: + + * entire_dataset, no filter is applied, all objects are used. + * union_of_primitives, a filter with (rotated) geometric primitives. + Objects in or on the surface of the primitives are considered. + All other objects are excluded. + * bitmask, a boolean array whose bits encode with 1 which objects + are included. Bits set to zero encode which objects + are excluded. Users of python can use the bitfield operations + of the numpy package to define such bitfields. + +# In the case that windowing_method is union_of_primitives, +# it is possible to specify none or all types of primitives +# (ellipsoids, cylinder, hexahedra). If no primitives are specified +# the filter falls back to entire_dataset. +# In the case that windowing_method is bitmask, the bitmask has to be defined; +# otherwise the filter falls back to entire dataset. + enumeration: [entire_dataset, union_of_primitives, bitmask] + (NXcg_hexahedron_set): + (NXcg_cylinder_set): + (NXcg_ellipsoid_set): + (NXcg_polyhedron_set): + (NXcs_filter_boolean_mask): diff --git a/contributed_definitions/nyaml/refactor/NXsubsampling_filter.yaml b/contributed_definitions/nyaml/refactor/NXsubsampling_filter.yaml new file mode 100644 index 0000000000..ea01dd19f5 --- /dev/null +++ b/contributed_definitions/nyaml/refactor/NXsubsampling_filter.yaml @@ -0,0 +1,17 @@ +category: base +doc: | + Settings of a filter to sample entries based on their value. +# symbols: +type: group +NXsubsampling_filter(NXobject): + linear_range_min_incr_max(NX_UINT): + unit: NX_UNITLESS + doc: | + Triplet of the minimum, increment, and maximum value which will + be included in the analysis. The increment controls which n-th entry to take. + + Take as an example a dataset with 100 entries (their indices start at zero) + and the filter set to 0, 1, 99. This will process each entry. + 0, 2, 99 will take each second entry. 90, 3, 99 will take only each third + entry beginning from entry 90 up to 99. + dim: (3,) diff --git a/contributed_definitions/nyaml/refactor/deprecate/NXapm_input_ranging.yaml b/contributed_definitions/nyaml/refactor/deprecate/NXapm_input_ranging.yaml new file mode 100644 index 0000000000..74a555657c --- /dev/null +++ b/contributed_definitions/nyaml/refactor/deprecate/NXapm_input_ranging.yaml @@ -0,0 +1,25 @@ +category: base +doc: | + Metadata to ranging definitions made for a dataset in atom probe microscopy. + + Ranging is the process of labeling time-of-flight data with so-called iontypes. + Iontypes ideally specify the most likely (molecular) ion that is assumed of having + been evaporated and laying within a mass-to-charge-state-ratio value interval. + + The so-called UNKNOWNTYPE iontype represents the null model of an event/ion + that has not been ranged. The identifier of this special iontype is always 0. +# symbols: +type: group +NXapm_input_ranging(NXserialized): + group_name_iontypes(NX_CHAR): + doc: | + Name of the (parent) group (prefix to the individual ranging definitions) + inside the file referred to by path which points to the specific ranging + definition to use. + Container files can store multiple ranging definitions. + Using an identifier allows for a distinction which specific + definitions to apply. + + Remember that the identifier of the reconstruction and ranging definitions + can differ despite the fact that using the same filenames for the reconstruction + and ranging definitions files has become common practice. diff --git a/contributed_definitions/nyaml/refactor/deprecate/NXapm_input_reconstruction.yaml b/contributed_definitions/nyaml/refactor/deprecate/NXapm_input_reconstruction.yaml new file mode 100644 index 0000000000..dc7a90f947 --- /dev/null +++ b/contributed_definitions/nyaml/refactor/deprecate/NXapm_input_reconstruction.yaml @@ -0,0 +1,19 @@ +category: base +doc: | + Data artifact representing a tomographic reconstruction in atom probe microscopy. + + Typically, reconstructions in the field of atom probe tomography are communicated + via files which store reconstructed ion positions and mass-to-charge-state-ratio values. + Container files like HDF5 can store multiple reconstructions. This base class specifies + which specific reconstruction one likes to refer to. +# symbols: +type: group +NXapm_reconstruction(NXserialized): + dataset_name_reconstruction(NX_CHAR): + doc: | + Name of the dataset which refers to the specific reconstructed + ion positions to use for this analysis. + dataset_name_mass_to_charge(NX_CHAR): + doc: | + Name of the dataset which refers to the specific mass-to-charge- + state-ratio values to use for this analysis. From 31096450674b1034e4536c65406c6e1775f14296 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:07:41 +0100 Subject: [PATCH 0397/1012] Multiline docstrings for enumerations are now supported --- dev_tools/docs/nxdl.py | 26 +++++++++++++++++++++++++- 1 file changed, 25 insertions(+), 1 deletion(-) diff --git a/dev_tools/docs/nxdl.py b/dev_tools/docs/nxdl.py index c2dda67988..cd4ec4300e 100755 --- a/dev_tools/docs/nxdl.py +++ b/dev_tools/docs/nxdl.py @@ -303,12 +303,36 @@ def _get_doc_blocks(ns, node): out_blocks.append("\n".join(out_lines)) return out_blocks + def _handle_multiline_docstring(self, blocks): + links = [] + docstring = "" + expanded_blocks = [] + for block in blocks: + expanded_blocks += block.split('\n') + + for block in expanded_blocks: + if not block: + continue + + link_match = re.search(r"\.\. _([^:]+):(.*)", block) + if link_match is not None: + links.append((link_match.group(1), link_match.group(2).strip())) + else: + docstring += " " + re.sub(r"\n", " ", block.strip()) + + for (name, target) in links: + docstring = docstring.replace( + f"`{name}`_", f"`{name} <{target}>`_" + ) + + return docstring + def _get_doc_line(self, ns, node): blocks = self._get_doc_blocks(ns, node) if len(blocks) == 0: return "" if len(blocks) > 1: - raise Exception(f"Unexpected multi-paragraph doc [{'|'.join(blocks)}]") + return self._handle_multiline_docstring(blocks) return re.sub(r"\n", " ", blocks[0]) def _get_minOccurs(self, node): From d7403023b7c8f5e06f6a3851018e08c358b9a7f6 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 3 Jan 2024 16:08:19 +0100 Subject: [PATCH 0398/1012] Make nxdl --- base_classes/NXroot.nxdl.xml | 2 +- contributed_definitions/NXaberration.nxdl.xml | 2 +- .../NXaberration_model.nxdl.xml | 2 +- .../NXaberration_model_ceos.nxdl.xml | 2 +- .../NXaberration_model_nion.nxdl.xml | 2 +- .../NXaperture_em.nxdl.xml | 2 +- contributed_definitions/NXapm.nxdl.xml | 2 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 2 +- .../NXcalibration.nxdl.xml | 2 +- .../NXcg_alpha_complex.nxdl.xml | 2 +- .../NXcg_cylinder_set.nxdl.xml | 2 +- .../NXcg_ellipsoid_set.nxdl.xml | 2 +- .../NXcg_face_list_data_structure.nxdl.xml | 2 +- .../NXcg_geodesic_mesh.nxdl.xml | 2 +- contributed_definitions/NXcg_grid.nxdl.xml | 2 +- .../NXcg_half_edge_data_structure.nxdl.xml | 2 +- .../NXcg_hexahedron_set.nxdl.xml | 2 +- .../NXcg_marching_cubes.nxdl.xml | 2 +- .../NXcg_parallelogram_set.nxdl.xml | 2 +- .../NXcg_point_set.nxdl.xml | 2 +- .../NXcg_polygon_set.nxdl.xml | 2 +- .../NXcg_polyhedron_set.nxdl.xml | 2 +- .../NXcg_polyline_set.nxdl.xml | 2 +- .../NXcg_primitive_set.nxdl.xml | 2 +- contributed_definitions/NXcg_roi_set.nxdl.xml | 2 +- .../NXcg_sphere_set.nxdl.xml | 2 +- .../NXcg_tetrahedron_set.nxdl.xml | 2 +- .../NXcg_triangle_set.nxdl.xml | 2 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 2 +- .../NXcg_unit_normal_set.nxdl.xml | 2 +- contributed_definitions/NXchamber.nxdl.xml | 2 +- .../NXcollectioncolumn.nxdl.xml | 4 +- .../NXcomponent_em.nxdl.xml | 2 +- .../NXcoordinate_system.nxdl.xml | 2 +- .../NXcoordinate_system_set.nxdl.xml | 2 +- .../NXcorrector_cs.nxdl.xml | 2 +- .../NXcrystal_structure.nxdl.xml | 2 +- .../NXcs_computer.nxdl.xml | 2 +- contributed_definitions/NXcs_cpu_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 2 +- .../NXcs_filter_boolean_mask.nxdl.xml | 2 +- contributed_definitions/NXcs_gpu_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_gpu_sys.nxdl.xml | 2 +- contributed_definitions/NXcs_io_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 2 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 2 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 2 +- contributed_definitions/NXcs_prng.nxdl.xml | 2 +- .../NXcs_profiling.nxdl.xml | 2 +- .../NXcs_profiling_event.nxdl.xml | 2 +- contributed_definitions/NXdeflector.nxdl.xml | 2 +- .../NXebeam_column.nxdl.xml | 2 +- .../NXelectronanalyser.nxdl.xml | 420 +++--- contributed_definitions/NXem.nxdl.xml | 2 +- contributed_definitions/NXem_adf.nxdl.xml | 2 +- contributed_definitions/NXem_base.nxdl.xml | 2 +- .../NXem_conventions.nxdl.xml | 2 +- .../NXem_conventions_ebsd.nxdl.xml | 2 +- .../NXem_correlation.nxdl.xml | 2 +- contributed_definitions/NXem_ebsd.nxdl.xml | 2 +- contributed_definitions/NXem_eds.nxdl.xml | 2 +- contributed_definitions/NXem_eels.nxdl.xml | 2 +- contributed_definitions/NXem_img.nxdl.xml | 2 +- contributed_definitions/NXem_method.nxdl.xml | 2 +- contributed_definitions/NXem_msr.nxdl.xml | 2 +- contributed_definitions/NXem_sim.nxdl.xml | 2 +- .../NXenergydispersion.nxdl.xml | 178 +-- .../NXevent_data_em.nxdl.xml | 2 +- .../NXevent_data_em_set.nxdl.xml | 2 +- .../NXfabrication.nxdl.xml | 2 +- .../NXgraph_edge_set.nxdl.xml | 2 +- .../NXgraph_node_set.nxdl.xml | 2 +- contributed_definitions/NXgraph_root.nxdl.xml | 2 +- .../NXibeam_column.nxdl.xml | 2 +- contributed_definitions/NXidentifier.nxdl.xml | 2 +- .../NXimage_c_set.nxdl.xml | 2 +- .../NXimage_r_set.nxdl.xml | 2 +- .../NXimage_r_set_diff.nxdl.xml | 2 +- contributed_definitions/NXimage_set.nxdl.xml | 2 +- .../NXinteraction_vol_em.nxdl.xml | 2 +- contributed_definitions/NXion.nxdl.xml | 2 +- contributed_definitions/NXisocontour.nxdl.xml | 2 +- contributed_definitions/NXlens_em.nxdl.xml | 2 +- contributed_definitions/NXmpes.nxdl.xml | 1231 +++++++++-------- contributed_definitions/NXms.nxdl.xml | 2 +- .../NXms_feature_set.nxdl.xml | 2 +- contributed_definitions/NXms_ipf.nxdl.xml | 2 +- contributed_definitions/NXms_ipf_set.nxdl.xml | 2 +- .../NXms_mtex_config.nxdl.xml | 2 +- contributed_definitions/NXms_odf.nxdl.xml | 2 +- contributed_definitions/NXms_odf_set.nxdl.xml | 2 +- contributed_definitions/NXms_pf.nxdl.xml | 2 +- contributed_definitions/NXms_pf_set.nxdl.xml | 2 +- contributed_definitions/NXms_recon.nxdl.xml | 2 +- .../NXms_score_results.nxdl.xml | 2 +- .../NXoptical_system_em.nxdl.xml | 2 +- contributed_definitions/NXpump.nxdl.xml | 2 +- contributed_definitions/NXroi.nxdl.xml | 2 +- .../NXrotation_set.nxdl.xml | 2 +- contributed_definitions/NXscanbox_em.nxdl.xml | 2 +- contributed_definitions/NXserialized.nxdl.xml | 2 +- .../NXspectrum_set.nxdl.xml | 2 +- contributed_definitions/NXstage_lab.nxdl.xml | 2 +- contributed_definitions/NXxrd.nxdl.xml | 2 +- contributed_definitions/NXxrd_pan.nxdl.xml | 2 +- 105 files changed, 1025 insertions(+), 1010 deletions(-) diff --git a/base_classes/NXroot.nxdl.xml b/base_classes/NXroot.nxdl.xml index 96125cf793..f6a9658537 100644 --- a/base_classes/NXroot.nxdl.xml +++ b/base_classes/NXroot.nxdl.xml @@ -3,7 +3,7 @@ - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of fast axes (axes acquired simultaneously, without scanning a - physical quantity) - - - - - Number of slow axes (axes acquired scanning a physical quantity) - - - - - Number of data points in the transmission function. - - - - - Subclass of NXinstrument to describe a photoelectron analyser. - - This concept is related to term `12.59`_ of the ISO 18115-1:2023 standard. - .. _12.59: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.59 - - - - Free text description of the type of the detector - - - - - Name or model of the equipment - - - - Acronym or other shorthand name - - - - - - Work function of the electron analyser. + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of fast axes (axes acquired simultaneously, without scanning a + physical quantity) + + + + + Number of slow axes (axes acquired scanning a physical quantity) + + + + + Number of data points in the transmission function. + + + + + Subclass of NXinstrument to describe a photoelectron analyser. - The work function of a uniform surface of a conductor is the minimum energy required to remove - an electron from the interior of the solid to a vacuum level immediately outside the solid surface. + This concept is related to term `12.59`_ of the ISO 18115-1:2023 standard. - The kinetic energy :math:`E_K` of a photoelectron emitted from an energy-level with binding energy - :math:`E_B` below the Fermi level is given by :math:`E_K = h\nu - E_B - e \phi_{\mathrm{sample}}`, - where :math:`\phi_{\mathrm{sample}}` is the work function of the sample surface. In PES measurements, - the sample and the spectrometer (with work function :math:`\phi_{\mathrm{spectr.}}`) are electrically - connected and therefore their Fermi levels are aligned. Due to the difference in local vacuum level - between the sample and spectrometer, there exists an electric potential difference (contact potential) - :math:`\Delta\phi = \phi_{\mathrm{sample}} - \phi_{\mathrm{spectr.}}`. The measured kinetic energy of - a photoelectron in PES is therefore given by - :math:`E_K^{\mathrm{meas.}} = h\nu - E_B + \Delta \phi = h\nu - E_B - e \phi_{\mathrm{spectr.}}`. - As a result, the measured kinetic energy :math:`E_K^{\mathrm{meas.}}` of a photoelectron is `independent` - of the sample work function. Nonetheless, the work function :math:`\phi_s` needs to be known to - accurately determine the binding energy scale. - - - - - Energy resolution of the electron analyser (FWHM of gaussian broadening). - - This concept is related to term `10.7`_ of the 18115-1:2023 standard. - .. _10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 - - - - - Momentum resolution of the electron analyser (FWHM) - - - - - Angular resolution of the electron analyser (FWHM) + .. _12.59: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.59 - - - - Spatial resolution of the electron analyser (Airy disk radius) - - This concept is related to term `10.15 ff.`_ of the ISO 18115-1:2023 standard. - .. _10.15 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.15 - - - - - List of the axes that are acquired simultaneously by the detector. - These refer only to the experimental variables recorded by the electron analyser. - Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. - - .. csv-table:: Examples - :header: "Mode", "fast_axes", "slow_axes" - - Hemispherical in ARPES mode, "['energy', 'kx']","" - "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] - "Tof", "['energy', 'kx', 'ky']","" - "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" - - Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. - If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. - - - - - - - - List of the axes that are acquired by scanning a physical parameter, listed in - order of decreasing speed. See fast_axes for examples. - - - - - - - - Transmission function of the electron analyser. - - The transmission function (TF) specifies the detection efficiency per solid angle for electrons of - different kinetic energy passing through the electron analyser. It depends on the spectrometer - geometry as well as operation settings such as lens mode and pass energy. - The transmission function is usually given as kinetic energy vs. relative intensity. - - The TF is used for calibration of the intensity scale in quantitative XPS. Without proper - transmission correction, a comparison of results measured from the same sample using different - operating modes for an instrument would show significant variations in atomic - concentrations. - - This concept is related to term `7.15 ff.`_ of the ISO 18115-1:2023 standard. - .. _7.15 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:7.15 - - - - - - - - - - - - - - Kinetic energy values - - - - + + + Free text description of the type of the detector + - - - Relative transmission efficiency for the given kinetic energies - - - - + + + Name or model of the equipment + + + + Acronym or other shorthand name + + - - - - Refers to the last transformation specifying the position of the manipulator in - the NXtransformations chain. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the electron analyser as a component in the instrument. Conventions - from the NXtransformations base class are used. In principle, the McStas - coordinate system is used. The first transformation has to point either to - another component of the system or . (for pointing to the reference frame) to - relate it relative to the experimental setup. Typically, the components of a - system should all be related relative to each other and only one component - should relate to the reference coordinate system. - - - - - Describes the electron collection (spatial and momentum imaging) column - - - - - Describes the energy dispersion section - - - - - Describes the spin dispersion section - - - - - Describes the electron detector - - - - - Deflectors outside the main optics ensambles described by the subclasses - - - - - Individual lenses outside the main optics ensambles described by the subclasses - - - + + + Work function of the electron analyser. + + The work function of a uniform surface of a conductor is the minimum energy required to remove + an electron from the interior of the solid to a vacuum level immediately outside the solid surface. + + The kinetic energy :math:`E_K` of a photoelectron emitted from an energy-level with binding energy + :math:`E_B` below the Fermi level is given by :math:`E_K = h\nu - E_B - e \phi_{\mathrm{sample}}`, + where :math:`\phi_{\mathrm{sample}}` is the work function of the sample surface. In PES measurements, + the sample and the spectrometer (with work function :math:`\phi_{\mathrm{spectr.}}`) are electrically + connected and therefore their Fermi levels are aligned. Due to the difference in local vacuum level + between the sample and spectrometer, there exists an electric potential difference (contact potential) + :math:`\Delta\phi = \phi_{\mathrm{sample}} - \phi_{\mathrm{spectr.}}`. The measured kinetic energy of + a photoelectron in PES is therefore given by + :math:`E_K^{\mathrm{meas.}} = h\nu - E_B + \Delta \phi = h\nu - E_B - e \phi_{\mathrm{spectr.}}`. + As a result, the measured kinetic energy :math:`E_K^{\mathrm{meas.}}` of a photoelectron is `independent` + of the sample work function. Nonetheless, the work function :math:`\phi_s` needs to be known to + accurately determine the binding energy scale. + + + + + Energy resolution of the electron analyser (FWHM of gaussian broadening). + + This concept is related to term `10.7`_ of the 18115-1:2023 standard. + + .. _10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 + + + + + Momentum resolution of the electron analyser (FWHM) + + + + + Angular resolution of the electron analyser (FWHM) + + + + + Spatial resolution of the electron analyser (Airy disk radius) + + This concept is related to term `10.15 ff.`_ of the ISO 18115-1:2023 standard. + + .. _10.15 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.15 + + + + + List of the axes that are acquired simultaneously by the detector. + These refer only to the experimental variables recorded by the electron analyser. + Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. + + .. csv-table:: Examples + :header: "Mode", "fast_axes", "slow_axes" + + Hemispherical in ARPES mode, "['energy', 'kx']","" + "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] + "Tof", "['energy', 'kx', 'ky']","" + "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" + + Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. + If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. + + + + + + + + List of the axes that are acquired by scanning a physical parameter, listed in + order of decreasing speed. See fast_axes for examples. + + + + + + + + Transmission function of the electron analyser. + + The transmission function (TF) specifies the detection efficiency per solid angle for electrons of + different kinetic energy passing through the electron analyser. It depends on the spectrometer + geometry as well as operation settings such as lens mode and pass energy. + The transmission function is usually given as kinetic energy vs. relative intensity. + + The TF is used for calibration of the intensity scale in quantitative XPS. Without proper + transmission correction, a comparison of results measured from the same sample using different + operating modes for an instrument would show significant variations in atomic + concentrations. + + This concept is related to term `7.15 ff.`_ of the ISO 18115-1:2023 standard. + + .. _7.15 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:7.15 + + + + + + + + + + + + + + Kinetic energy values + + + + + + + + Relative transmission efficiency for the given kinetic energies + + + + + + + + + Refers to the last transformation specifying the position of the manipulator in + the NXtransformations chain. + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the electron analyser as a component in the instrument. Conventions + from the NXtransformations base class are used. In principle, the McStas + coordinate system is used. The first transformation has to point either to + another component of the system or . (for pointing to the reference frame) to + relate it relative to the experimental setup. Typically, the components of a + system should all be related relative to each other and only one component + should relate to the reference coordinate system. + + + + + Describes the electron collection (spatial and momentum imaging) column + + + + + Describes the energy dispersion section + + + + + Describes the spin dispersion section + + + + + Describes the electron detector + + + + + Deflectors outside the main optics ensambles described by the subclasses + + + + + Individual lenses outside the main optics ensambles described by the subclasses + + + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 317d5e44a5..ffdb67e6a9 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -3,7 +3,7 @@ - - Subclass of NXelectronanalyser to describe the energy dispersion section of a - photoelectron analyser. - - - Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, - mirror, retarding grid, etc. + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. - - - - Energy of the electrons on the mean path of the analyser. Pass energy for - hemispherics, drift energy for tofs. - - Refers to Term `12.63`_ of the ISO 18115-1:2023 specification. - - .. _12.63: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.63 - - - - - Center of the energy window - - - - - The interval of transmitted energies. It can be two different things depending - on whether the scan is fixed or swept. With a fixed scan it is a 2 vector - containing the extrema of the transmitted energy window (smaller number first). - With a swept scan of m steps it is a 2xm array of windows one for each - measurement point. - - - - - Size, position and shape of a slit in dispersive analyzer, e.g. entrance and - exit slits. - - - - - Diameter of the dispersive orbit - - - - - Way of scanning the energy axis (fixed or sweep). - - This concept is related to term `12.65`_ of the ISO 18115-1:2023 standard. - .. _12.65: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.65 - - This concept is related to term `12.66`_ of the ISO 18115-1:2023 standard. - .. _12.66: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.66 - - - - - - - - - Length of the tof drift electrode - - - - - Deflectors in the energy dispersive section - - - - - Individual lenses in the energy dispersive section - - - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the energy dispersive element as a component in the instrument. - Conventions from the NXtransformations base class are used. In principle, - the McStas coordinate system is used. The first transformation has to point - either to another component of the system or . (for pointing to the reference frame) - to relate it relative to the experimental setup. Typically, the components of a system - should all be related relative to each other and only one component should relate to - the reference coordinate system. - - + + + Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, + mirror, retarding grid, etc. + + + + + Energy of the electrons on the mean path of the analyser. Pass energy for + hemispherics, drift energy for tofs. + + Refers to Term `12.63`_ of the ISO 18115-1:2023 specification. + + .. _12.63: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.63 + + + + + Center of the energy window + + + + + The interval of transmitted energies. It can be two different things depending + on whether the scan is fixed or swept. With a fixed scan it is a 2 vector + containing the extrema of the transmitted energy window (smaller number first). + With a swept scan of m steps it is a 2xm array of windows one for each + measurement point. + + + + + Size, position and shape of a slit in dispersive analyzer, e.g. entrance and + exit slits. + + + + + Diameter of the dispersive orbit + + + + + Way of scanning the energy axis (fixed or sweep). + + This concept is related to term `12.65`_ of the ISO 18115-1:2023 standard. + + .. _12.65: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.65 + + This concept is related to term `12.66`_ of the ISO 18115-1:2023 standard. + + .. _12.66: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.66 + + + + + + + + + Length of the tof drift electrode + + + + + Deflectors in the energy dispersive section + + + + + Individual lenses in the energy dispersive section + + + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the energy dispersive element as a component in the instrument. + Conventions from the NXtransformations base class are used. In principle, + the McStas coordinate system is used. The first transformation has to point + either to another component of the system or . (for pointing to the reference frame) + to relate it relative to the experimental setup. Typically, the components of a system + should all be related relative to each other and only one component should relate to + the reference coordinate system. + + diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml index 507c588ab4..204e668955 100644 --- a/contributed_definitions/NXevent_data_em.nxdl.xml +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -3,7 +3,7 @@ - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of data points in the transmission function. - - - - - This is the most general application definition for multidimensional - photoelectron spectroscopy. - - Groups and fields are named according to the - `ISO 18115-1:2023`_ specification as well as the `IUPAC Recommendations 2020`_. - - .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html - .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 - - - - - - - - - - - - Datetime of the start of the measurement. - - - - - Datetime of the end of the measurement. - - - - - A name of the experimental method according to `Clause 11`_ of - the `ISO 18115-1:2023`_ specification. - - Examples include: - * X-ray photoelectron spectroscopy (XPS) - * angle-resolved X-ray photoelectron spectroscopy (ARXPS) - * ultraviolet photoelectron spectroscopy (UPS) - * angle-resolved photoelectron spectroscopy (ARPES) - * hard X-ray photoemission spectroscopy (HAXPES) - * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) - * photoelectron emission microscopy (PEEM) - * electron spectroscopy for chemical analysis (ESCA) - - .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html - .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 - - - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - + - Name of the affiliation of the user at the point in time when the experiment was - performed. + The symbols used in the schema to specify e.g. dimensions of arrays - - - - - MPES spectrometer - - This concept is related to term `12.58`_ of the ISO 18115-1:2023 standard. - .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 - - - - Overall energy resolution of the MPES instrument - - This concept is related to term `10.7 ff.`_ of the ISO 18115-1:2023 standard. - .. _10.7 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 - - This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. - .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 - - - - - - - - - - - - - - - - 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. - - - - - - - - - - - - - - - - - - - - Specification of type, may also go to name. - - - - - - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - - - - - - - - - - - - - - - - The beam emitted by this source. - Should be named with the same appendix, e.g., - for `source_probe` it should refer to `beam_probe`. - Refers to the same concept as /NXentry/NXinstrument/beam_TYPE - and may be linked. - - - - - - - - The beam emitted by this source. - Should be named with the same appendix, e.g., - for `source_probe` it should refer to `beam_probe`. - Refers to the same concept as /NXentry/NXinstrument/source_TYPE - and may be linked. - - - - - - - - - The source that emitted this beam. - Should be named with the same appendix, e.g., - for `beam_probe` it should refer to `source_probe`. - Refers to the same concept as /NXentry/NXinstrument/source_TYPE - and may be linked. - - - - - - - - - - - - - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. - .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 - - - - - - - - + - Scheme of the electron collection column. + Number of data points in the transmission function. + + + + This is the most general application definition for multidimensional + photoelectron spectroscopy. + + Groups and fields are named according to the + `ISO 18115-1:2023`_ specification as well as the `IUPAC Recommendations 2020`_. + + .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 + + + + - - - - - - - - + - - - - Labelling of the lens setting in use. - - - - + + + - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. + Datetime of the start of the measurement. - - + + - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. + Datetime of the end of the measurement. - - + + - Size, position and shape of the iris inserted in the column. + A name of the experimental method according to `Clause 11`_ of + the `ISO 18115-1:2023`_ specification. - The iris is an aperture in the lens with a variable diameter which can reduce the number of - electrons entering the analyzer. + Examples include: + * X-ray photoelectron spectroscopy (XPS) + * angle-resolved X-ray photoelectron spectroscopy (ARXPS) + * ultraviolet photoelectron spectroscopy (UPS) + * angle-resolved photoelectron spectroscopy (ARPES) + * hard X-ray photoemission spectroscopy (HAXPES) + * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) + * photoelectron emission microscopy (PEEM) + * electron spectroscopy for chemical analysis (ESCA) - To add additional or other slits use the APERTURE group of NXcollectioncolumn. + .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 - - - - - - - - - - - - - - - - - - - - - + + - Size, position and shape of the entrance slit in dispersive analyzers. - - To add additional or other slits use the APERTURE group of NXenergydispersion. + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. - - + + + Name of the user. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + - Size, position and shape of the exit slit in dispersive analyzers. + MPES spectrometer + + This concept is related to term `12.58`_ of the ISO 18115-1:2023 standard. - To add additional or other slits use the APERTURE group of NXenergydispersion. + .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 - - - - - - + + + Overall energy resolution of the MPES instrument + + This concept is related to term `10.7 ff.`_ of the ISO 18115-1:2023 standard. + + .. _10.7 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 + + This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. + + .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 + + + + + + + + + + + + + + + + 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. + + + + + + + + + + + + + + + + + + + + Specification of type, may also go to name. + + + + + + Type of probe. In photoemission it's always photons, so the full NIAC list is + restricted. + + + + + + + + + + + + + + + + The beam emitted by this source. + Should be named with the same appendix, e.g., + for `source_probe` it should refer to `beam_probe`. + Refers to the same concept as /NXentry/NXinstrument/beam_TYPE + and may be linked. + + + + + + + + The beam emitted by this source. + Should be named with the same appendix, e.g., + for `source_probe` it should refer to `beam_probe`. + Refers to the same concept as /NXentry/NXinstrument/source_TYPE + and may be linked. + + + + + + + + + The source that emitted this beam. + Should be named with the same appendix, e.g., + for `beam_probe` it should refer to `source_probe`. + Refers to the same concept as /NXentry/NXinstrument/source_TYPE + and may be linked. + + + + + + + + + + + + + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. + + This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. + + .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 + + + + + + + + + + Scheme of the electron collection column. + + + + + + + + + + + + + + + Labelling of the lens setting in use. + + + + + + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + Size, position and shape of the iris inserted in the column. + + The iris is an aperture in the lens with a variable diameter which can reduce the number of + electrons entering the analyzer. + + To add additional or other slits use the APERTURE group of NXcollectioncolumn. + + + + + + + + + + + + + + + + + + + + + + + + Size, position and shape of the entrance slit in dispersive analyzers. + + To add additional or other slits use the APERTURE group of NXenergydispersion. + + + + + Size, position and shape of the exit slit in dispersive analyzers. + + To add additional or other slits use the APERTURE group of NXenergydispersion. + + + + + + + + + + + + Type of electron amplifier in the first amplification step. + + + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + + + + + + + + + Raw data before calibration. + + + + + + + + Manipulator for positioning of the sample. + + + + + + Bias of the sample with respect to analyser ground. + + This field may also be found in NXsample if present. + + This concept is related to term `8.41`_ of the ISO 18115-1:2023 standard. + + .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 + + + + + + + + - - - - Type of electron amplifier in the first amplification step. - - - - - - - + - Description of the detector type. + 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 - - - - - - - - - - - - - - - + + + Calibration event on the energy axis. + + For XPS, the calibration should ideally be performed according to + `ISO 15472:2010`_ specification. + + .. _ISO 15472:2010: https://www.iso.org/standard/74811.html + + + + Has an energy calibration been applied? + + + + + This is the calibrated energy axis to be used for data plotting. + + + + + + + Has an angular calibration been applied? + + + + + This is the calibrated angular axis to be used for data plotting. + + + + + + + Has an spatial calibration been applied? + + + + + This is the calibrated spatial axis to be used for data plotting. + + + + + + + Has an momentum calibration been applied? + + + + + This is the momentum axis to be used for data plotting. + + + + + + For energy referencing, the measured energies are corrected for the charging potential + (i.e., the electrical potential of the surface region of an insulating sample, caused by + irradiation) such that those energies correspond to a sample with no surface charge. + Usually, the energy axis is adjusted by shifting all energies uniformally until one + well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. + + This concept is related to term `12.74 ff.`_ of the ISO 18115-1:2023 standard. + + .. _12.74 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 + + + + Have the energy axes been adjusted (e.g., in cases where samples are not + conductive)? + + + + + Electronic core or valence level that was used for the calibration. + + + + + Reference peak that was used for the calibration. + + For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge + + + + + The binding energy (in units of eV) that the specified emission line appeared at, + after adjusting the binding energy scale. + + This concept is related to term `12.16_ ff.`_ of the ISO 18115-1:2023 standard. + + .. _12.16_ ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + + + + + Offset between measured binding energy and calibrated binding energy of the + emission line. + + + + + This is the calibrated energy axis to be used for data plotting. + + This should link to /entry/data/energy. + + + + + + In the transmission correction, each intensity measurement for electrons of a given + kinetic energy is multiplied by the corresponding value in the relative_intensity + field of the transmission_function. This calibration procedure is used to account for + the different tranmsission efficiencies when using different lens modes. + + + + Has an intensity calibration been applied? + + That is, has the transmission function of the analyser been taken into account? + + + + + Transmission function of the electron analyser. + + The transmission function (TF) specifies the detection efficiency for electrons of + different kinetic energy passing through the electron analyser. + This can be a link to /entry/instrument/electronanalyser/transmission_function. + + + + + + + + + + + + + + Kinetic energy values + + + + + + + + Relative transmission efficiency for the given kinetic energies + + + + + + + + + + + + + The chemical formula of the sample. For mixtures use the NXsample_component + group in NXsample instead. + + + + + A descriptor to keep track of the treatment of the sample before entering the + photoemission experiment. Ideally, a full report of the previous operations, in + any format (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + + + + + Date of preparation of the sample for the XPS experiment (i.e. cleaving, last + annealing). + + + + + Description of the surface preparation technique for the XPS experiment, i.e. + UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report + of the previous operations, in any format(NXnote allows to add pictures, audio, + movies). Alternatively, a reference to the location or a unique identifier or + other metadata file. In the case these are not available, free-text description. + + + + + In the case of a fixed temperature measurement this is the scalar temperature of + the sample. In the case of an experiment in which the temperature is changed and + recoded, this is an array of length m of temperatures. This should be a link to + /entry/instrument/manipulator/sample_temperature. + + + + + + + + + + + + + + Voltage applied to sample and sample holder. + + + + - - - + + + - - - Raw data before calibration. - + + + Represents a measure of one- or more-dimensional photoemission counts, where the + varied axis may be for example energy, momentum, spatial coordinate, pump-probe + delay, spin index, temperature, etc. The axes traces should be linked to the + actual encoder position in NXinstrument or calibrated axes in NXprocess. + + + + + Calibrated energy axis. + + The calibrated energy axis can be either in binding or kinetic energy. + This should be a link to either + /entry/process/energy_calibration/calibrated_axis or + /entry/process/energy_correction/calibrated_axis. + + + + The energy can be either stored as kinetic or as binding energy. + + + + + Calibrated kinetic energy axis. + + This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. + + .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 + + + + + Calibrated binding energy axis. + + This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. + + .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + + + + - - - - - - Manipulator for positioning of the sample. - - - - - - Bias of the sample with respect to analyser ground. - - This field may also be found in NXsample if present. - - This concept is related to term `8.41`_ of the ISO 18115-1:2023 standard. - .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 - - - - - - - - - - - - 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 - - - - Calibration event on the energy axis. - - For XPS, the calibration should ideally be performed according to - `ISO 15472:2010`_ specification. - - .. _ISO 15472:2010: https://www.iso.org/standard/74811.html - - - - Has an energy calibration been applied? - - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - - Has an angular calibration been applied? - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - - Has an spatial calibration been applied? - - - - - This is the calibrated spatial axis to be used for data plotting. - - - - - - - Has an momentum calibration been applied? - - - - - This is the momentum axis to be used for data plotting. - - - - - - For energy referencing, the measured energies are corrected for the charging potential - (i.e., the electrical potential of the surface region of an insulating sample, caused by - irradiation) such that those energies correspond to a sample with no surface charge. - Usually, the energy axis is adjusted by shifting all energies uniformally until one - well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. - - This concept is related to term `12.74 ff.`_ of the ISO 18115-1:2023 standard. - .. _12.74 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 - - - - Have the energy axes been adjusted (e.g., in cases where samples are not - conductive)? - - - - - Electronic core or valence level that was used for the calibration. - - - - - Reference peak that was used for the calibration. - - For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge - - - - - The binding energy (in units of eV) that the specified emission line appeared at, - after adjusting the binding energy scale. - - This concept is related to term `12.16_ ff.`_ of the ISO 18115-1:2023 standard. - .. _12.16_ ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - - - - - Offset between measured binding energy and calibrated binding energy of the - emission line. - - - - - This is the calibrated energy axis to be used for data plotting. - - This should link to /entry/data/energy. - - - - - - In the transmission correction, each intensity measurement for electrons of a given - kinetic energy is multiplied by the corresponding value in the relative_intensity - field of the transmission_function. This calibration procedure is used to account for - the different tranmsission efficiencies when using different lens modes. - - - - Has an intensity calibration been applied? - - That is, has the transmission function of the analyser been taken into account? - - - - - Transmission function of the electron analyser. - - The transmission function (TF) specifies the detection efficiency for electrons of - different kinetic energy passing through the electron analyser. - This can be a link to /entry/instrument/electronanalyser/transmission_function. - - - - - - - - - - - - - - Kinetic energy values - - - - - - - - Relative transmission efficiency for the given kinetic energies - - - - - - - - - - - - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - - - - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - - - - - Description of the surface preparation technique for the XPS experiment, i.e. - UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report - of the previous operations, in any format(NXnote allows to add pictures, audio, - movies). Alternatively, a reference to the location or a unique identifier or - other metadata file. In the case these are not available, free-text description. - - - - - In the case of a fixed temperature measurement this is the scalar temperature of - the sample. In the case of an experiment in which the temperature is changed and - recoded, this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. - - - - - - - - - - - - - - Voltage applied to sample and sample holder. - - - - - - - - - - - - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, momentum, spatial coordinate, pump-probe - delay, spin index, temperature, etc. The axes traces should be linked to the - actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - Calibrated energy axis. - - The calibrated energy axis can be either in binding or kinetic energy. - This should be a link to either - /entry/process/energy_calibration/calibrated_axis or - /entry/process/energy_correction/calibrated_axis. - - - - The energy can be either stored as kinetic or as binding energy. - - - - - Calibrated kinetic energy axis. - - This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. - .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 - - - - - Calibrated binding energy axis. - - This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. - .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - - - - - - diff --git a/contributed_definitions/NXms.nxdl.xml b/contributed_definitions/NXms.nxdl.xml index af4e4ff578..3c3b55374b 100644 --- a/contributed_definitions/NXms.nxdl.xml +++ b/contributed_definitions/NXms.nxdl.xml @@ -3,7 +3,7 @@ -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Configurations of a paraprobe-transcoder tool run in atom probe microscopy. -# -# -# -# -# -# Version specifier of this application definition. -# -# -# -# -# Official NeXus NXDL schema with which this file was written. -# -# -# -# -# -# -# -# Given name of the program/software/tool with which this NeXus -# (configuration) file was generated. -# -# -# -# Ideally program version plus build number, or commit hash or description -# of ideally an ever persistent resource where the source code of the -# program and build instructions can be found so that the program can be -# configured ideally in such a manner that the result of this computational -# process is recreatable deterministically. -# -# -# -# -# -# Ideally, a (globally persistent) unique identifier for referring -# to this analysis. -# -# -# -# -# Possibility for leaving a free-text description about this analysis. -# -# -# -# -# Path to the directory where the tool should store NeXus/HDF5 results -# of this analysis. If not specified results will be stored in the -# current working directory. -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when this configuration file was created. -# -# -# -# -# -# -# -# The path and name of the file (technology partner or community format) -# from which to read the reconstructed ion positions. Currently, POS, -# ePOS, APT files from APSuite, and NXS, i.e. NeXus/HDF5 files -# are supported. -# -# -# -# -# -# -# -# The path and name of the file (technology partner or community format -# from which to read the ranging definitions, i.e. how to map mass-to- -# charge-state ratios on iontypes. Currently, RRNG, RNG, and NXS, i.e. -# NeXus/HDF5 files are supported. -# -# -# -# -# -# -# -# -# -# + enumeration: [NXapm_paraprobe_transcoder_config] + config(NXapm_paraprobe_tool_config): + (NXidentifier): + exists: optional + analysis_identifier(NX_UINT): + exists: recommended + reconstruction(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + position(NX_CHAR): + mass_to_charge(NX_CHAR): + iontypes(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + ranging_definitions(NX_CHAR): + # (NXprogram): + profiling(NXcs_profiling): + exists: recommended + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + results_path(NX_CHAR): + exists: recommended + current_working_directory(NX_CHAR): diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_transcoder_results.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_transcoder_results.yaml index 00b4211f2a..f87ad01e0b 100644 --- a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_transcoder_results.yaml +++ b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_transcoder_results.yaml @@ -1,6 +1,29 @@ category: application doc: | - Results of a paraprobe-transcoder tool run. + Application definition for results files of the paraprobe-transcoder tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + The purpose and need of paraprobe-transcoder tool is to create a standardized representation + of reconstructed position and mass-to-charge-state-ratio values surplus other pieces of information + to enable at all to work with atom probe data in reconstruction space. + This includes ranging definitions which map mass-to-charge-state ratio values onto iontypes. + So far the atom probe community has not yet agreed upon a comprehensive standardization for + information exchange especially when it comes to the communication of configurations and results + from analyses of atom probe data. Instead, different simplistic file formats are used, such as POS , ePOS, + APT, or RNG and RRNG. None of these formats document though the provenance of and thus the + sequence in which certain analysis steps were performed on which specific input and using which + specific configuration. + + Paraprobe-transcoder solves this limitation by interpreting the information content in such files + and standardize the representation prior injection into the scientific data analysis tools of the toolbox. + Therefore, the here proposed set of NeXus base classes and application definitions can be a useful + starting point that enable the atom probe community to take advantage of standardized + information exchange and improve the here proposed classes and concepts to become + even more inclusive. + + Paraprobe-transcoder uses a Python library developed based on efforts by members of the + global atom probe community `International Field Emission Society (IFES) Atom Probe Technical Committee (APT TC) `_. This library offers the + actual low-level I/O operations and respective information interpretation. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -14,329 +37,54 @@ symbols: n_topology: | Total number of integers in the supplementary XDMF topology array. n_combinatorics: | - Number of ions probed in the combinatorial analysis of the charge states - -# be careful n_comb can vary for every instance of (NXion) ! + Number of ions probed in the combinatorial analysis of the charge states. +# i be careful n_comb can vary for every instance of (NXion) ! type: group -NXapm_paraprobe_results_transcoder(NXobject): - - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently +NXapm_paraprobe_transcoder_results(NXobject): + # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently (NXentry): exists: ['min', '1', 'max', '1'] \@version: doc: | Version specifier of this application definition. - - ##MK::begin of the tool-specific section definition: doc: | Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_results_transcoder] - - ##MK::end of the tool-specific section - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: | - Possibility for leaving a free-text description about this analysis. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - config_filename: - doc: | - The absolute path and name of the config file for this analysis. - \@version: - doc: | - At least SHA256 strong hash of the specific config_file for - tracking provenance. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - status: - doc: | - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - enumeration: [success, failure] - (NXuser): - exists: recommended - doc: | - If used, contact information and eventually details - of at least the person who performed this analysis. - name: - affiliation: - exists: recommended - address: - exists: optional - email: - exists: recommended - orcid: - exists: recommended - orcid_platform: - exists: recommended - telephone_number: - exists: optional - role: - exists: recommended - social_media_name: - exists: optional - social_media_platform: - exists: optional - (NXcoordinate_system_set): - doc: | - Details about the coordinate system conventions used. - (NXtransformations): - exists: ['min', '1', 'max', 'unbounded'] - doc: | - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - ##MK::begin of the tool-specific section - visualization(NXprocess): - exists: recommended - xdmf_topology(NX_UINT): - unit: NX_UNITLESS - doc: | - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstruction. The XDMF datatype - is here 1, the number of primitives 1 per triplet, the last integer - in each triplet is the identifier of each point starting from zero. - dimensions: - rank: 1 - dim: [[1, n_topology]] - - # n_topology == 3*n_ions - # not in all cases a PARAPROBE.Transcoder.Results.SimID..h5 is required - # namely when an NXapm-compliant NeXus file is directly used for interacting - # with paraprobe tools in all other cases, the PARAPROBE.Transcoder.Results - # file will get an *.nxs file ending - # the original proposal - # results(NXprocess): - # exists: [min, 1, max, 1] - # doc: | - # Paraprobe-transcoder prepares the data in POS, ePOS, APT files from - # APSuite, RRNG, RNG, and NeXus/HDF5 NXapm in such a way that they can - # be used with the tools of the paraprobe-toolbox. - # reconstruction(NXcg_point_set): - # dimensionality(NX_POSINT): - # cardinality(NX_POSINT): - # identifier_offset(NX_INT): - # position(NX_NUMBER): - # ##MK::number_of_ion_types(NX_POSINT): - # ##MK::maximum_number_of_atoms_per_molecular_ion(NX_POSINT): - # ranging(NXcollection): - # exists: [min, 1, max, 256] - # doc: | - # This is the collection of iontypes distinguished. - # The default unknown iontype always has to map to 0. - # Its non-physical mass_to_charge_state_ratio is [0., 0.001] Da. - # ion_type(NX_UINT): - # exists: optional - # isotope_vector(NX_UINT): - # nuclid_list(NX_UINT): - # exists: recommended - # charge_state(NX_INT): - # name: - # exists: optional - # mass_to_charge_range(NX_FLOAT): - # the key problem still for apm is people use different formats - # when people would like to use paraprobe without nomad and pos, epos, apt - # rrng and rng files the data have to be transcoded, this is the main - # reason for having the transcoder however, when you already have an NXapm - # file (like) in nomad, why should we create yet another format here the - # transcoder is not needed - # namely take e.g. paraprobe-nanochem all it needs to know is the place of - # an HDF5 file where the nanochem tool knows there will be groups in this file - # with entry/atom_probe/reconstruction/reconstructed_positions - # and entry/atom_probe/ranging/peak_identification and a set of NXion - # this suggest the need for three fundamental changes: - # if transcoder config gets an nxs file as input it just checks if - # the above-mentioned groups are available, if yes it accepts and - # guides that no transcoding is needed any longer - # if transcoder config gets other files it creates the above-mentioned - # groups in different places than it does currently - # convenience functions of tools have to be changed in the following way: - # you hunt for PARAPROBE.Transcoder.Config.SimID..h5 - # if the references to dataset files there end with nxs you know - # data are in an NXapm so reconstruction will be in - # entry/atom_probe/reconstruction/reconstructed_positions - # ranging will be in - # entry/atom_probe/ranging/peak_identification - # however if the references to dataset files there end with != nxs - # you point the tool to in fact data inside PARAPROBE.Transcoder.Results - # because in this case transcoding was necessary but also then you - # will find the data in entry/atom_probe/.. respectively - # alternatively: - atom_probe(NXinstrument): - doc: | - On a mid term perspective we would like to evolve the paraprobe-toolbox - to an implementation stage where it works exclusively with completely - provenance-tracked formats for both the configuration of the workflow step - and/or analysis with each tool and also for the output of these analyses - in the form of so-called tool-specific results files. - Currently the Hierarchical Data Format 5 (HDF5) is used to store such data. - - Different file formats can be used to inject reconstructed datasets and - ranging definitions into the toolbox. Traditionally, these are the POS, - ePOS, and APT files with the tomographic reconstruction and other metadata - and RNG and RRNG file formats for the ranging definitions how mass-to-charge - state-ratio values map on (molecular) ion types. Such input should be - injected via specific NeXus/HDF5 files which are documented - in compliance with the NXapm application definition. - - So far the paraprobe-toolbox was used as a standalone tool. Therefore, it - was not relevant during the development to focus on interoperability. - Essentially paraprobe-transcoder was used as a parser to transcode data - in the above-mentioned file formats into a paraprobe-specific - representation. This transcoding should become deprecated. - Here we describe steps we have taken into this direction. - - With the work in the FAIRmat project and the desire to make the paraprobe- - toolbox also accessible as a cloud-computing capable service in the Nomad - Remote Tools Hub (NORTH) the topic of interoperability became more important - and eventually the NXapm application definition was proposed. - NORTH is a GUI and related service in a NOMAD OASIS instance which allows - to spawn preconfigured docker containers via JupyterHub. - Currently, NORTH includes the so-called apm container. A container with - tools specific for analyzing data from atom probe microscopy as well as - processing of point cloud and mesh data. - - The NXapm application definition and related implementation work within - NOMAD OASIS enabled users to parse content of POS, ePOS, APT, RNG, and - RRNG files, surplus key metadata from vendor-agnostic electronic lab notebook - solutions directly into NOMAD OASIS via the uploads section. - The process is automated and yields an NXapm-compliant NeXus/HDF5 file - inside the uploads section in return. - - With these improvements made there is no longer a need for - at least the - users of a NOMAD OASIS and NORTH instance to use the deprecated - PARAPROBE.Transcoder.Results.*.h5 files. Ideally, paraprobe should - automatically detect that the input can now be an NXapm-compliant NeXus/HDF5 - file and in response work with this file directly. - To remain compliant with users however who do not have or do not wish - to use a NOMAD OASIS or NXapm or NeXus at all right now, the solution is - as follows: - - Calling the configuration stage of paraprobe-transcoder is always mandatory. - It is always the first step of working with the toolbox. In this process - the user defines the input files. These can either be nxs i.e. the NXapm/NeXus/ - HDF5 file from e.g. the upload section, or such a file that was obtained from - a colleague with a NOMAD OASIS instance. - In all other cases, users can pass the reconstruction and ranging definitions - using the traditional POS, ePOS, or APT and RNG or RRNG file formats respectively. - - Based on which input the user delivers, the parmsetup-transcoder tool then - creates a configuration file PARAPROBE.Transcoder.Config.SimID.*.nxs and - informs the user whether the input was NeXus (and thus if all relevant - input is already available) or whether the paraprobe-transcoder tool needs - to be executed to convert the content of the vendor files first into a - format which paraprobe can provenance track and understand. - In the latter case, the PARAPROBE.Transcoder.Config.SimID.*.nxs file is - used to communicate to all subsequently used tools from which files - the tools can expect to find the reconstruction and ranging definitions. - - All subsequent analysis steps start also with a tool-specific configuration. - This configuration step reads in (among others) the - PARAPROBE.Transcoder.Config.SimID.*.nxs file from which the configuration - tool identifies automatically whether to read the reconstruction and ranging data - from PARAPROBE.Transcoder.Results.SimID.*.h5 or directly the NXapm-compliant - NeXus/HDF5 file that was created upon preparing the upload or the file shared - from a colleague. This design removes the need for unnecessary copies of the data. - Currently still though users should execute the transcoder step as it will - generate a supplementary XDMF topology field with which the data in either - the NeXus/HDF5 or the transcoded vendor files can be displayed using e.g. - Paraview. For this purpose XDMF is used. - - Of course ideally the APT community would at some point converge to use - a common data exchange file format. To this end, AMETEK/Cameca's APT file format - could be a good starting point but so far it is lacking a consistent way of - how to store generalized ranging definitions and post-processing results. - POS, ePOS, Rouen's ATO, as well as other so far used representations of data - like CSV or text files have, to the best of our current knowledge, no - concept of how to marry reconstruction and (optional) ranging data into - one self-descriptive format. - - This summarizes the rationale behind the current choices of the I/O for - paraprobe. Furthermore, this summarizes also why the fundamental design - of splitting an analysis always into steps of configuration (with parmsetup), - task execution (with the respective C/C++ or Python tool of the toolbox), - and post-processing (e.g. with autoreporter) is useful because it offers - a clear description of provenance tracking. This is a necessary step to make - atom probe microscopy data at all better aligned with the aims of the - FAIR principles. - - The internal organization of the data entries in the atom_probe group - in this application definition for paraprobe-transcoder results files - mirror the definitions of the NXapm for consistency reasons. - - # APSuite, RRNG, RNG, and NeXus/HDF5 NXapm in such a way that they can + enumeration: [NXapm_paraprobe_transcoder_results] + atom_probe(NXapm_paraprobe_transcoder_results): + # this is currently a trick but should in the future be renamed to have a one-to-one + # representation equivalence of reconstructed position and mass-to-charge-state-ratio value + # arrays such that + # the doc-string of the concept atom_probe(NXinstrument) should be used for + # supplementary material to a paper but here no longer reported as it is way too specific + # APSuite, RRNG, RNG, and NeXus/HDF5 NXapm in such a way that they can # be used with the tools of the paraprobe-toolbox. mass_to_charge_conversion(NXprocess): mass_to_charge(NX_FLOAT): - unit: NX_ANY + unit: NX_ANY # u doc: | - Mass-to-charge-state ratio values. - - # \@units: Da - dimensions: - rank: 1 - dim: [[1, n_ions]] + Mass-to-charge-state-ratio values. + dim: (n_ions,) reconstruction(NXprocess): - - # number_of_ions(NX_UINT): - # doc: | - # For now still a support field to store the total number of ions in the - # dataset. This field will become deprecated when the new HDF5 I/O routines - # come in place which detect the metadata to an entry automatically. - # For now has to be the same value as n_ions. reconstructed_positions(NX_FLOAT): - unit: NX_LENGTH + \@depends_on(NX_CHAR): + doc: | + Point to the coordinate system in which these positions are defined. doc: | Three-dimensional reconstructed positions of the ions. Interleaved array of x, y, z positions in the specimen space. - dimensions: - rank: 2 - dim: [[1, n_ions], [2, 3]] + unit: NX_LENGTH + dim: (n_ions, 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 reconstruction. The XDMF datatype + is here 1, the number of primitives 1 per triplet, the last integer + in each triplet is the identifier of each point starting from zero. + unit: NX_UNITLESS + dim: (n_topology,) ranging(NXprocess): peak_identification(NXprocess): doc: | @@ -349,732 +97,36 @@ NXapm_paraprobe_results_transcoder(NXobject): exists: recommended charge_state(NX_INT): mass_to_charge_range(NX_FLOAT): - charge_model(NXprocess): - doc: | - Details and results of the combinatorial analyses of this - range definition to identify the charge_state for an ion. - charge_vector(NX_UINT): - unit: NX_UNITLESS - doc: | - Currently charge_state not charge! - dimensions: - rank: 1 - dim: [[1, n_combinatorics]] - isotope_matrix(NX_UINT): - unit: NX_UNITLESS - doc: | - Specific isotopes building each candidate matching the range. - dimensions: - rank: 2 - dim: [[1, n_combinatorics], [2, n_ivec_max]] - mass_vector(NX_FLOAT): - unit: NX_ANY - doc: | - Accumulated mass of the isotopes in each candidate. - Not corrected for quantum effects. - dimensions: - rank: 1 - dim: [[1, n_combinatorics]] - - # min_abundance(NX_FLOAT): - # doc: | - # Minimum natural abundance - # unit: NX_DIMENSIONLESS - natural_abundance_product_vector(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Product of natural abundance of the isotopes per candidate. - dimensions: - rank: 1 - dim: [[1, n_combinatorics]] - min_abundance_product(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Filter criterion on the product of the natural abundances - computed from each isotope building the (molecular) ion. - Such a filter can be used to reduce the number of possible - molecular ions considered when trying to find a unique solution - to the question which charge_state does a molecular ion - within a given range and given combination of elements have. - min_half_life(NX_FLOAT): - unit: NX_TIME - doc: | - Filter criterion on the minimum half life which all isotopes - building the (molecular) ion need to have to consider the - candidate. - Such a filter can be used to reduce the number of possible - molecular ions considered when trying to find a unique solution - to the question which charge_state does a molecular ion - within a given range and given combination of elements have. - - # NEW ISSUE: value can be the string infinity! - # min_half_life_vector(NX_FLOAT): - # doc: | - # Needs to be documented - # unit: NX_TIME - sacrifice_isotopic_uniqueness(NX_BOOLEAN): - doc: | - If the value is zero/false it means that non-unique solutions - are accepted. These are solutions where multiple candidates - differ in their isotopes but have the same charge. - - # add further fields coming from using the charge state recovery - # workflow from the ifes_apt_tc_data_modeling library - ##MK::end of the tool-specific section - performance(NXcs_profiling): - current_working_directory: - command_line_call: - exists: optional + unit: NX_ANY # u + dim: (i, 2) + # (NXcharge_state_model): + (NXprogram): + profiling(NXcs_profiling): start_time(NX_DATE_TIME): - exists: recommended end_time(NX_DATE_TIME): + status(NX_CHAR): + results_path(NX_CHAR): exists: recommended total_elapsed_time(NX_NUMBER): number_of_processes(NX_POSINT): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): - (NXcs_computer): - exists: recommended - name: - exists: recommended - operating_system: - \@version: - uuid: - exists: optional - (NXcs_cpu): - exists: ['min', '0', 'max', 'unbounded'] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_gpu): - exists: ['min', '0', 'max', 'unbounded'] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_mm_sys): - exists: ['min', '0', 'max', '1'] - total_physical_memory(NX_NUMBER): - (NXcs_io_sys): - exists: ['min', '0', 'max', '1'] - (NXcs_io_obj): - exists: ['min', '1', 'max', 'unbounded'] - technology: - max_physical_capacity(NX_NUMBER): - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_profiling_event): - start_time(NX_DATE_TIME): - exists: optional - end_time(NX_DATE_TIME): - exists: optional - description: - elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - number_of_threads(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - number_of_gpus(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - max_virtual_memory_snapshot(NX_NUMBER): - exists: recommended - max_resident_memory_snapshot(NX_NUMBER): - exists: recommended - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# dc03e6cf382ef885356e95ad6889162c3ded9664dea8344499decc097be77690 -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The total number of ions in the reconstruction. -# -# -# -# -# Maximum number of allowed atoms per (molecular) ion (fragment). -# Needs to match maximum_number_of_atoms_per_molecular_ion. -# -# -# -# -# Number of mass-to-charge-state-ratio intervals mapped on this ion type. -# -# -# -# -# Total number of integers in the supplementary XDMF topology array. -# -# -# -# -# Number of ions probed in the combinatorial analysis of the charge states -# -# -# -# -# Results of a paraprobe-transcoder tool run. -# -# -# -# -# -# Version specifier of this application definition. -# -# -# -# -# -# Official NeXus NXDL schema with which this file was written. -# -# -# -# -# -# -# -# -# Given name of the program/software/tool with which this NeXus -# (configuration) file was generated. -# -# -# -# Ideally program version plus build number, or commit hash or description -# of ever persistent resources where the source code of the program and -# build instructions can be found so that the program can be configured -# ideally in such a manner that the result of this computational process -# is recreatable in the same deterministic manner. -# -# -# -# -# -# Ideally, a (globally persistent) unique identifier for referring -# to this analysis. -# -# -# -# -# Possibility for leaving a free-text description about this analysis. -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when the analysis behind this results file -# was started, i.e. the paraprobe-tool executable started as a process. -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when the analysis behind this results file -# were completed and the paraprobe-tool executable exited as a process. -# -# -# -# -# The absolute path and name of the config file for this analysis. -# -# -# -# At least SHA256 strong hash of the specific config_file for -# tracking provenance. -# -# -# -# -# -# Path to the directory where the tool should store NeXus/HDF5 results -# of this analysis. If not specified results will be stored in the -# current working directory. -# -# -# -# -# A statement whether the paraprobe-tool executable managed to -# process the analysis or failed prematurely. -# -# This status is written to the results file after the end_time -# at which point the executable must not compute any analysis. -# Only when this status message is present and shows `success`, the -# user should consider the results. In all other cases it might be -# that the executable has terminated prematurely or another error -# occurred. -# -# -# -# -# -# -# -# -# If used, contact information and eventually details -# of at least the person who performed this analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Details about the coordinate system conventions used. -# -# -# -# The individual coordinate systems which should be used. -# Field names should be prefixed with the following controlled terms -# indicating which individual coordinate system is described: -# -# * paraprobe -# * lab -# * specimen -# * laser -# * leap -# * detector -# * recon -# -# -# -# -# -# -# -# An array of triplets of integers which can serve as a supplementary -# array for Paraview to display the reconstruction. The XDMF datatype -# is here 1, the number of primitives 1 per triplet, the last integer -# in each triplet is the identifier of each point starting from zero. -# -# -# -# -# -# -# -# -# -# On a mid term perspective we would like to evolve the paraprobe-toolbox -# to an implementation stage where it works exclusively with completely -# provenance-tracked formats for both the configuration of the workflow step -# and/or analysis with each tool and also for the output of these analyses -# in the form of so-called tool-specific results files. -# Currently the Hierarchical Data Format 5 (HDF5) is used to store such data. -# -# Different file formats can be used to inject reconstructed datasets and -# ranging definitions into the toolbox. Traditionally, these are the POS, -# ePOS, and APT files with the tomographic reconstruction and other metadata -# and RNG and RRNG file formats for the ranging definitions how mass-to-charge -# state-ratio values map on (molecular) ion types. Such input should be -# injected via specific NeXus/HDF5 files which are documented -# in compliance with the NXapm application definition. -# -# So far the paraprobe-toolbox was used as a standalone tool. Therefore, it -# was not relevant during the development to focus on interoperability. -# Essentially paraprobe-transcoder was used as a parser to transcode data -# in the above-mentioned file formats into a paraprobe-specific -# representation. This transcoding should become deprecated. -# Here we describe steps we have taken into this direction. -# -# With the work in the FAIRmat project and the desire to make the paraprobe- -# toolbox also accessible as a cloud-computing capable service in the Nomad -# Remote Tools Hub (NORTH) the topic of interoperability became more important -# and eventually the NXapm application definition was proposed. -# NORTH is a GUI and related service in a NOMAD OASIS instance which allows -# to spawn preconfigured docker containers via JupyterHub. -# Currently, NORTH includes the so-called apm container. A container with -# tools specific for analyzing data from atom probe microscopy as well as -# processing of point cloud and mesh data. -# -# The NXapm application definition and related implementation work within -# NOMAD OASIS enabled users to parse content of POS, ePOS, APT, RNG, and -# RRNG files, surplus key metadata from vendor-agnostic electronic lab notebook -# solutions directly into NOMAD OASIS via the uploads section. -# The process is automated and yields an NXapm-compliant NeXus/HDF5 file -# inside the uploads section in return. -# -# With these improvements made there is no longer a need for - at least the -# users of a NOMAD OASIS and NORTH instance to use the deprecated -# PARAPROBE.Transcoder.Results.*.h5 files. Ideally, paraprobe should -# automatically detect that the input can now be an NXapm-compliant NeXus/HDF5 -# file and in response work with this file directly. -# To remain compliant with users however who do not have or do not wish -# to use a NOMAD OASIS or NXapm or NeXus at all right now, the solution is -# as follows: -# -# Calling the configuration stage of paraprobe-transcoder is always mandatory. -# It is always the first step of working with the toolbox. In this process -# the user defines the input files. These can either be nxs i.e. the NXapm/NeXus/ -# HDF5 file from e.g. the upload section, or such a file that was obtained from -# a colleague with a NOMAD OASIS instance. -# In all other cases, users can pass the reconstruction and ranging definitions -# using the traditional POS, ePOS, or APT and RNG or RRNG file formats respectively. -# -# Based on which input the user delivers, the parmsetup-transcoder tool then -# creates a configuration file PARAPROBE.Transcoder.Config.SimID.*.nxs and -# informs the user whether the input was NeXus (and thus if all relevant -# input is already available) or whether the paraprobe-transcoder tool needs -# to be executed to convert the content of the vendor files first into a -# format which paraprobe can provenance track and understand. -# In the latter case, the PARAPROBE.Transcoder.Config.SimID.*.nxs file is -# used to communicate to all subsequently used tools from which files -# the tools can expect to find the reconstruction and ranging definitions. -# -# All subsequent analysis steps start also with a tool-specific configuration. -# This configuration step reads in (among others) the -# PARAPROBE.Transcoder.Config.SimID.*.nxs file from which the configuration -# tool identifies automatically whether to read the reconstruction and ranging data -# from PARAPROBE.Transcoder.Results.SimID.*.h5 or directly the NXapm-compliant -# NeXus/HDF5 file that was created upon preparing the upload or the file shared -# from a colleague. This design removes the need for unnecessary copies of the data. -# Currently still though users should execute the transcoder step as it will -# generate a supplementary XDMF topology field with which the data in either -# the NeXus/HDF5 or the transcoded vendor files can be displayed using e.g. -# Paraview. For this purpose XDMF is used. -# -# Of course ideally the APT community would at some point converge to use -# a common data exchange file format. To this end, AMETEK/Cameca's APT file format -# could be a good starting point but so far it is lacking a consistent way of -# how to store generalized ranging definitions and post-processing results. -# POS, ePOS, Rouen's ATO, as well as other so far used representations of data -# like CSV or text files have, to the best of our current knowledge, no -# concept of how to marry reconstruction and (optional) ranging data into -# one self-descriptive format. -# -# This summarizes the rationale behind the current choices of the I/O for -# paraprobe. Furthermore, this summarizes also why the fundamental design -# of splitting an analysis always into steps of configuration (with parmsetup), -# task execution (with the respective C/C++ or Python tool of the toolbox), -# and post-processing (e.g. with autoreporter) is useful because it offers -# a clear description of provenance tracking. This is a necessary step to make -# atom probe microscopy data at all better aligned with the aims of the -# FAIR principles. -# -# The internal organization of the data entries in the atom_probe group -# in this application definition for paraprobe-transcoder results files -# mirror the definitions of the NXapm for consistency reasons. -# -# -# -# -# -# Mass-to-charge-state ratio values. -# -# -# -# -# -# -# -# -# -# -# -# Three-dimensional reconstructed positions of the ions. -# Interleaved array of x, y, z positions in the specimen space. -# -# -# -# -# -# -# -# -# -# -# Details about how peaks, with taking into account -# error models, were interpreted as ion types or not. -# -# -# -# -# -# -# -# -# Details and results of the combinatorial analyses of this -# range definition to identify the charge_state for an ion. -# -# -# -# Currently charge_state not charge! -# -# -# -# -# -# -# -# Specific isotopes building each candidate matching the range. -# -# -# -# -# -# -# -# -# Accumulated mass of the isotopes in each candidate. -# Not corrected for quantum effects. -# -# -# -# -# -# -# -# -# Product of natural abundance of the isotopes per candidate. -# -# -# -# -# -# -# -# Filter criterion on the product of the natural abundances -# computed from each isotope building the (molecular) ion. -# Such a filter can be used to reduce the number of possible -# molecular ions considered when trying to find a unique solution -# to the question which charge_state does a molecular ion -# within a given range and given combination of elements have. -# -# -# -# -# Filter criterion on the minimum half life which all isotopes -# building the (molecular) ion need to have to consider the -# candidate. -# Such a filter can be used to reduce the number of possible -# molecular ions considered when trying to find a unique solution -# to the question which charge_state does a molecular ion -# within a given range and given combination of elements have. -# -# -# -# -# -# If the value is zero/false it means that non-unique solutions -# are accepted. These are solutions where multiple candidates -# differ in their isotopes but have the same charge. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Specify if it was different from the number_of_processes -# in the NXcs_profiling super class. -# -# -# -# -# -# Specify if it was different from the number_of_threads -# in the NXcs_profiling super class. -# -# -# -# -# -# Specify if it was different from the number_of_threads -# in the NXcs_profiling super class. -# -# -# -# -# -# -# -# -# + # use more detailed constraint set to describe a computer + (NXuser): + exists: ['min', '0', 'max', 'unbounded'] + doc: | + If used, metadata of at least the person who performed this analysis. + name(NX_CHAR): + (NXcoordinate_system_set): + paraprobe(NXcoordinate_system): + type(NX_CHAR): + handedness(NX_CHAR): + x(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + y(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + z(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) From 7abeded451a1ea8759e92e684a3d4995d4174284 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 3 Jan 2024 21:57:18 +0100 Subject: [PATCH 0402/1012] Applied to i) --- .../NXapm_paraprobe_ranger_config.yaml | 694 ++++--------- .../NXapm_paraprobe_ranger_results.yaml | 951 ++++-------------- .../NXapm_paraprobe_transcoder_config.yaml | 10 +- .../NXapm_paraprobe_transcoder_results.yaml | 4 +- .../NXcs_filter_boolean_mask.yaml | 6 +- .../nyaml/refactor/NXmatch_filter.yaml | 4 +- .../nyaml/refactor/NXspatial_filter.yaml | 4 +- .../nyaml/refactor/NXsubsampling_filter.yaml | 20 +- 8 files changed, 390 insertions(+), 1303 deletions(-) rename contributed_definitions/nyaml/{ => refactor}/NXcs_filter_boolean_mask.yaml (96%) diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_ranger_config.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_ranger_config.yaml index cbc879b5c8..864d7a1562 100644 --- a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_ranger_config.yaml +++ b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_ranger_config.yaml @@ -1,531 +1,213 @@ category: application doc: | - Configuration of a paraprobe-ranger tool run in atom probe microscopy. + Application definition for a configuration file of the paraprobe-ranger tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. - n_isotopes: | + n_nuclids: | The number of isotopes to consider as building blocks for searching molecular ions. n_composition: | The number of compositions to consider for molecular ion search tasks. type: group -NXapm_paraprobe_config_ranger(NXobject): +NXapm_paraprobe_ranger_config(NXobject): (NXentry): - - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently \@version: doc: | Version specifier of this application definition. definition: doc: | Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_config_ranger] - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - time_stamp(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: | - Possibility for leaving a free-text description about this analysis. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - number_of_processes(NX_UINT): - unit: NX_UNITLESS - doc: | - How many task to perform? - (NXprocess): - exists: ['min', '0', 'max', 'unbounded'] - apply_existent_ranging(NXprocess): - exists: ['min', '0', 'max', '1'] - dataset(NXapm_input_reconstruction): - filename: - \@version: - dataset_name_reconstruction: - dataset_name_mass_to_charge: - iontypes(NXapm_input_ranging): - filename: - \@version: - group_name_iontypes: - spatial_filter(NXspatial_filter): + enumeration: [NXapm_paraprobe_ranger_config] + apply_existent_ranging(NXapm_paraprobe_tool_config): + exists: ['min', '0', 'max', '1'] + (NXidentifier): + exists: optional + analysis_identifier(NX_UINT): + exists: recommended + reconstruction(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + mass_to_charge(NX_CHAR): + ranging(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + ranging_definitions(NX_CHAR): + spatial_filter(NXspatial_filter): + exists: optional + windowing_method(NX_CHAR): + (NXcg_hexahedron_set): exists: optional - windowing_method: - (NXcg_ellipsoid_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - half_axes_radii(NX_NUMBER): - orientation(NX_NUMBER): - (NXcg_cylinder_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - height(NX_NUMBER): - radii(NX_NUMBER): - (NXcg_hexahedron_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - hexahedra(NXcg_face_list_data_structure): - (NXcs_filter_boolean_mask): - exists: optional - number_of_objects(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - identifier(NX_UINT): - evaporation_id_filter(NXsubsampling_filter): + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + hexahedra(NXcg_face_list_data_structure): + (NXcg_cylinder_set): exists: optional - iontype_filter(NXmatch_filter): + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + height(NX_NUMBER): + radii(NX_NUMBER): + (NXcg_ellipsoid_set): exists: optional - hit_multiplicity_filter(NXmatch_filter): + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + half_axes_radii(NX_NUMBER): + orientation(NX_NUMBER): + (NXcg_polyhedron_set): exists: optional - molecular_ion_search(NXprocess): - exists: ['min', '0', 'max', 'unbounded'] - assumed_composition_isotopes(NX_UINT): + # TODO + (NXcs_filter_boolean_mask): exists: optional - unit: NX_UNITLESS - doc: | - A list of pairs of number of protons and either the value 0 (per row) - or the mass number for all those isotopes which are assumed present - in a virtual specimen. - The purpose of this field is to compute also composition-weighted - products to yield a simple estimation which could potentially help - scientists to judge if certain molecular ions are to be expected. - The corresponding setting store_composition_weighted_product should be - activated. - dimensions: - rank: 2 - dim: [[1, n_composition], [2, 2]] - - # assumed_composition_value(NX_FLOAT): + number_of_objects(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + # will this be a scalar if the next line is omitted? + # dim: (i,) + identifier(NX_UINT): + # likewise so this one + # dim: (j,) + evaporation_id_filter(NXsubsampling_filter): + exists: optional + min_incr_max(NX_INT): + iontype_filter(NXmatch_filter): + exists: optional + method(NX_CHAR): + match(NX_NUMBER): + hit_multiplicity_filter(NXmatch_filter): + exists: optional + method(NX_CHAR): + match(NX_NUMBER): + # (NXprogram): + profiling(NXcs_profiling): + exists: recommended + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + results_path(NX_CHAR): + exists: recommended + current_working_directory(NX_CHAR): + # molecular_ion_search(NXapm_paraprobe_tool_config): + # exists: ['min', '0', 'max', 'unbounded'] + # # extent if needed + # assumed_composition_isotopes(NX_UINT): + # exists: optional + # doc: | + # A list of pairs of number of protons and either the value 0 (per row) + # or the mass number for all those isotopes which are assumed present + # in a virtual specimen. + # The purpose of this field is to compute also composition-weighted + # products to yield a simple estimation which could potentially help + # scientists to judge if certain molecular ions are to be expected. + # The corresponding setting store_composition_weighted_product should be + # activated. + # unit: NX_UNITLESS + # dim: (n_composition, 2) + # assumed_composition_value(NX_FLOAT): # doc: | - # A list of atomic (at.-%) ! percent values for the composition of each - # isotope in the virtual specimen following the sequence of - # assumed_composition_isotopes. + # A list of atomic (at.-%) ! percent values for the composition of each + # isotope in the virtual specimen following the sequence of + # assumed_composition_isotopes. # unit: NX_DIMENSIONLESS - # dimensions: - # rank: 1 - # dim: [[1, n_compositions]] - isotope_whitelist(NX_UINT): - unit: NX_UNITLESS - doc: | - A list of pairs of number of protons and mass number for all isotopes - to consider that can be composed into (molecular) ions, during the - recursive molecular_ion_search. - dimensions: - rank: 2 - dim: [[1, n_isotopes], [2, 2]] - mass_to_charge_interval(NX_FLOAT): - unit: NX_ANY - doc: | - The mass-to-charge-state ratio interval in which - all molecular ions are searched. - dimensions: - rank: 1 - dim: [[1, 2]] - maximum_charge(NX_UINT): - unit: NX_UNITLESS - doc: | - The maximum charge that a molecular ion should have. - maximum_number_of_isotopes(NX_UINT): - unit: NX_UNITLESS - doc: | - The maximum number of isotopes of which the molecular ion - should be composed. Currently this must not be larger than 32. - - Users should be warned that the larger the maximum_charge and - especially the larger the maximum_number_of_isotopes is chosen, - the eventually orders of magnitude more costly the search becomes. - - This is because paraprobe-ranger computes really all (at least) - theoretically possible combinations that would have likely a - mass-to-charge-state ratio in the specified mass_to_charge_interval. - It is the challenge in atom probe to judge which of these (molecular) - ions are feasible and also practically possible. This tool does not - answer this question. - - Namely, which specific molecular ion will evaporate, remain stable - during flight and becomes detected is a complicated and in many cases - not yet in detail understood phenomenon. The ab-initio conditions - before and during launch, the local environment, arrangement and field - as well as the flight phase in an evacuated but not analysis chamber - with a complex electrical field, eventual laser pulsing in place, - temperature and remaining atoms or molecules all can have an effect - which iontypes are really physically evaporating and detected. - store_atomic_mass_sum(NX_BOOLEAN): - doc: | - Report the accumulated atomic mass from each isotope building the ion. - Accounts for each identified ion. - Relatistic effects are not accounted for. - store_natural_abundance_product(NX_BOOLEAN): - doc: | - Report the product of the natural abundances from each isotope building - the ion. Accounts for each identified ion. - - The value zero indicates it is not possible to build such molecular ion - from nuclids which are all observationally stable. - Very small values can give an idea/about how likely such a molecular ion - is expected to form assuming equal probabilities. - - However in atom probe experiments this product has to be modified - by the (spatially-correlated) local composition in the region from - which the ions launch because the formation of a molecular ion depends - as summarized under maximum_number_of_isotopes on the specific - quantum-mechanical configuration and field state upon launch - or/and (early state) of flight respectively. - We are aware that this modified product can have a substantially - different value than the natural_abundance_product. - - Natural abundancies folded with the estimated compositions of the - specimen can differ by orders of magnitude. - - # add assumed composition of the specimen - # store_composition_weighted_product(NX_BOOLEAN): + # dim: (n_compositions,) + # isotope_whitelist(NX_UINT): + # doc: | + # A list of pairs of number of protons and mass number for all isotopes + # to consider that can be composed into (molecular) ions, during the + # recursive molecular_ion_search. + # unit: NX_UNITLESS + # dim: (n_nuclids, 2) + # mass_to_charge_interval(NX_FLOAT): + # doc: | + # The mass-to-charge-state ratio interval in which + # all molecular ions are searched. + # unit: NX_ANY # u + # dim: (2,) + # maximum_charge(NX_UINT): + # doc: | + # The maximum charge that a molecular ion should have. + # unit: NX_UNITLESS + # maximum_number_of_isotopes(NX_UINT): + # doc: | + # The maximum number of isotopes of which the molecular ion + # should be composed. Currently this must not be larger than 32. + + # Users should be warned that the larger the maximum_charge and + # especially the larger the maximum_number_of_isotopes is chosen, + # the eventually orders of magnitude more costly the search becomes. + + # This is because paraprobe-ranger computes really all (at least) + # theoretically possible combinations that would have likely a + # mass-to-charge-state ratio in the specified mass_to_charge_interval. + # It is the challenge in atom probe to judge which of these (molecular) + # ions are feasible and also practically possible. This tool does not + # answer this question. + + # Namely, which specific molecular ion will evaporate, remain stable + # during flight and becomes detected is a complicated and in many cases + # not yet in detail understood phenomenon. The ab-initio conditions + # before and during launch, the local environment, arrangement and field + # as well as the flight phase in an evacuated but not analysis chamber + # with a complex electrical field, eventual laser pulsing in place, + # temperature and remaining atoms or molecules all can have an effect + # which iontypes are really physically evaporating and detected. + # unit: NX_UNITLESS + # store_atomic_mass_sum(NX_BOOLEAN): + # doc: | + # Report the accumulated atomic mass from each isotope building the ion. + # Accounts for each identified ion. Relatistic effects are not accounted for. + # store_natural_abundance_product(NX_BOOLEAN): + # doc: | + # Report the product of the natural abundances from each isotope building + # the ion. Accounts for each identified ion. + + # The value zero indicates it is not possible to build such molecular ion + # from nuclids which are all observationally stable. + # Very small values can give an idea/about how likely such a molecular ion + # is expected to form assuming equal probabilities. + + # However in atom probe experiments this product has to be modified + # by the (spatially-correlated) local composition in the region from + # which the ions launch because the formation of a molecular ion depends + # as summarized under maximum_number_of_isotopes on the specific + # quantum-mechanical configuration and field state upon launch + # or/and (early state) of flight respectively. + # We are aware that this modified product can have a substantially + # different value than the natural_abundance_product. + + # Natural abundancies folded with the estimated compositions of the + # specimen can differ by orders of magnitude. + # # add assumed composition of the specimen + # store_composition_weighted_product(NX_BOOLEAN): + # doc: | + # Report the product of the composition from each isotope building the + # ion. This sets strong constraints on the molecular ions which are + # expected to have at all a noteworthy product value. + # It should not be forgotten though the computation relies on assumptions: + + # * The composition is homogeneous within the virtual specimen. + # * It is a priori known which nuclids the specimen is build of. + + # store_charge_state(NX_BOOLEAN): + # doc: | + # Report the charge state of the ions. + # store_disjoint_isotopes(NX_BOOLEAN): # doc: | - # Report the product of the composition from each isotope building the - # ion. This sets strong constraints on the molecular ions which are - # expected to have at all a noteworthy product value. - # It should not be forgotten though the computation relies on assumptions: - # * The composition is homogeneous within the virtual specimen. - # * It is a priori know which nuclids the specimen is build of. - store_charge_state(NX_BOOLEAN): - doc: | - Report the charge state of the ions. - store_disjoint_isotopes(NX_BOOLEAN): - doc: | - Report if identified ions should be characterized - wrt to their number of disjoint isotopes. - check_existent_ranging(NXprocess): - exists: ['min', '0', 'max', '1'] - iontypes(NXapm_input_ranging): - filename: - \@version: - group_name_iontypes: - performance(NXcs_profiling): - current_working_directory: - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e680aa3be81d3132fa6dbff9ae4d44ae7ca8a610b8660af51c3b67c207961ea0 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The number of isotopes to consider as building blocks for searching molecular -# ions. -# -# -# -# -# The number of compositions to consider for molecular ion search tasks. -# -# -# -# -# Configuration of a paraprobe-ranger tool run in atom probe microscopy. -# -# -# -# -# -# Version specifier of this application definition. -# -# -# -# -# Official NeXus NXDL schema with which this file was written. -# -# -# -# -# -# -# -# Given name of the program/software/tool with which this NeXus -# (configuration) file was generated. -# -# -# -# Ideally program version plus build number, or commit hash or description -# of ever persistent resources where the source code of the program and -# build instructions can be found so that the program can be configured -# ideally in such a manner that the result of this computational process -# is recreatable in the same deterministic manner. -# -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when this configuration file was created. -# -# -# -# -# Ideally, a (globally persistent) unique identifier for referring -# to this analysis. -# -# -# -# -# Possibility for leaving a free-text description about this analysis. -# -# -# -# -# Path to the directory where the tool should store NeXus/HDF5 results -# of this analysis. If not specified results will be stored in the -# current working directory. -# -# -# -# -# How many task to perform? -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# A list of pairs of number of protons and either the value 0 (per row) -# or the mass number for all those isotopes which are assumed present -# in a virtual specimen. -# The purpose of this field is to compute also composition-weighted -# products to yield a simple estimation which could potentially help -# scientists to judge if certain molecular ions are to be expected. -# The corresponding setting store_composition_weighted_product should be -# activated. -# -# -# -# -# -# -# -# -# -# A list of pairs of number of protons and mass number for all isotopes -# to consider that can be composed into (molecular) ions, during the -# recursive molecular_ion_search. -# -# -# -# -# -# -# -# -# The mass-to-charge-state ratio interval in which -# all molecular ions are searched. -# -# -# -# -# -# -# -# The maximum charge that a molecular ion should have. -# -# -# -# -# The maximum number of isotopes of which the molecular ion -# should be composed. Currently this must not be larger than 32. -# -# Users should be warned that the larger the maximum_charge and -# especially the larger the maximum_number_of_isotopes is chosen, -# the eventually orders of magnitude more costly the search becomes. -# -# This is because paraprobe-ranger computes really all (at least) -# theoretically possible combinations that would have likely a -# mass-to-charge-state ratio in the specified mass_to_charge_interval. -# It is the challenge in atom probe to judge which of these (molecular) -# ions are feasible and also practically possible. This tool does not -# answer this question. -# -# Namely, which specific molecular ion will evaporate, remain stable -# during flight and becomes detected is a complicated and in many cases -# not yet in detail understood phenomenon. The ab-initio conditions -# before and during launch, the local environment, arrangement and field -# as well as the flight phase in an evacuated but not analysis chamber -# with a complex electrical field, eventual laser pulsing in place, -# temperature and remaining atoms or molecules all can have an effect -# which iontypes are really physically evaporating and detected. -# -# -# -# -# Report the accumulated atomic mass from each isotope building the ion. -# Accounts for each identified ion. -# Relatistic effects are not accounted for. -# -# -# -# -# Report the product of the natural abundances from each isotope building -# the ion. Accounts for each identified ion. -# -# The value zero indicates it is not possible to build such molecular ion -# from nuclids which are all observationally stable. -# Very small values can give an idea/about how likely such a molecular ion -# is expected to form assuming equal probabilities. -# -# However in atom probe experiments this product has to be modified -# by the (spatially-correlated) local composition in the region from -# which the ions launch because the formation of a molecular ion depends -# as summarized under maximum_number_of_isotopes on the specific -# quantum-mechanical configuration and field state upon launch -# or/and (early state) of flight respectively. -# We are aware that this modified product can have a substantially -# different value than the natural_abundance_product. -# -# Natural abundancies folded with the estimated compositions of the -# specimen can differ by orders of magnitude. -# -# -# -# -# -# Report the charge state of the ions. -# -# -# -# -# Report if identified ions should be characterized -# wrt to their number of disjoint isotopes. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# + # Report if identified ions should be characterized wrt to their number of disjoint isotopes. + # check_existent_ranging(NXapm_paraprobe_tool_config): + # exists: ['min', '0', 'max', '1'] + # ranging(NXserialized): + # type(NX_CHAR): + # path(NX_CHAR): + # checksum(NX_CHAR): + # algorithm(NX_CHAR): + # ranging_definitions(NX_CHAR): diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_ranger_results.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_ranger_results.yaml index d953ae989d..da9d985f49 100644 --- a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_ranger_results.yaml +++ b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_ranger_results.yaml @@ -1,809 +1,210 @@ category: application doc: | - Results of a paraprobe-ranger tool run. + Application definition for results files of the paraprobe-transcoder tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + The purpose and need of the paraprobe-ranger tool is to apply a given set of ranging definitions within + a certain (possibly complicated) selection of ions (based on their properties or location in the + reconstructed volume. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. n_ions: | The total number of ions in the reconstruction. - n_ivec_max: | - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. type: group -NXapm_paraprobe_results_ranger(NXobject): - - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently +NXapm_paraprobe_ranger_results(NXobject): (NXentry): exists: ['min', '1', 'max', '1'] \@version: doc: | Version specifier of this application definition. - - ##MK::begin of the tool-specific section definition: doc: | Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_results_ranger] - - ##MK::end of the tool-specific section - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: | - Possibility for leaving a free-text description about this analysis. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - config_filename: + enumeration: [NXapm_paraprobe_ranger_results] + apply_existent_ranging(NXapm_paraprobe_tool_results): + exists: ['min', '0', 'max', '1'] doc: | - The path and name of the config file for this analysis. - \@version: + Paraprobe-ranger loads the iontypes and evaluates for each + ion on which iontype it matches. If it matches on no interval, the + ion is considered of the default unknown type with a 0 as its + respective value in the iontypes array. + ##MK::number_of_ion_types(NX_POSINT): + maximum_number_of_atoms_per_molecular_ion(NX_POSINT): doc: | - At least SHA256 strong hash of the specific config_file for - tracking provenance. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - status: - doc: | - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - enumeration: [success, failure] - (NXuser): - exists: recommended - doc: | - If used, contact information and eventually details - of at least the person who performed this analysis. - name: - affiliation: - exists: recommended - address: - exists: optional - email: - exists: recommended - orcid: - exists: recommended - orcid_platform: - exists: recommended - telephone_number: - exists: optional - role: - exists: recommended - social_media_name: - exists: optional - social_media_platform: - exists: optional - (NXcoordinate_system_set): - exists: optional - doc: | - Details about the coordinate system conventions used. - (NXtransformations): - exists: ['min', '1', 'max', 'unbounded'] + The length of the isotope_vector used to describe molecular ions. + unit: NX_UNITLESS + (NXion): + exists: ['min', '1', 'max', '256'] + isotope_vector(NX_UINT): + nuclid_list(NX_UINT): + exists: recommended + charge_state(NX_INT): + mass_to_charge_range(NX_FLOAT): + iontypes(NX_UINT): doc: | - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - ##MK::begin of the tool-specific section - (NXprocess): - exists: ['min', '0', 'max', '1'] - apply_existent_ranging(NXprocess): - exists: ['min', '0', 'max', '1'] + The iontype ID for each ion that was best matching, stored in the + order of the evaporation sequence ID. The here computed iontypes + do not take into account the charge state of the ion which is + equivalent to interpreting a RNG and RRNG range files for each + ion in such a way that only the elements of which a (molecular) ion + is build are considered. By contrast, charged_iontypes takes + into account also the charge state. + unit: NX_UNITLESS + dim: (n_ions,) + window(NXcs_filter_boolean_mask): doc: | - Paraprobe-ranger loads the iontypes and evaluates for each - ion on which iontype it matches. If it matches on none, the - ion is considered of the default unknown type with a 0 as its - respective value in the iontypes array. - - ##MK::number_of_ion_types(NX_POSINT): - maximum_number_of_atoms_per_molecular_ion(NX_POSINT): - unit: NX_UNITLESS + A bitmask which identifies exactly all those ions ranged + irrespective of the type they ended up with. This information + can be used to numerically recover the ROI selection. + number_of_ions(NX_UINT): doc: | - The length of the isotope_vector used to describe molecular ions. - ION(NXion): - exists: ['min', '1', 'max', '256'] - isotope_vector(NX_UINT): - nuclid_list(NX_UINT): - exists: recommended - charge_state(NX_INT): - mass_to_charge_range(NX_FLOAT): - iontypes(NX_UINT): + Number of ions covered by the mask. + The mask value for most may be 0. unit: NX_UNITLESS + bitdepth(NX_UINT): doc: | - The iontype ID for each ion that was best matching, stored in the - order of the evaporation sequence ID. The here computed iontypes - do not take into account the charge state of the ion which is - equivalent to interpreting a RNG and RRNG range files for each - ion in such a way that only the elements of which a (molecular) ion - is build are considered. By contrast, charged_iontypes takes - into account also the charge state. - dimensions: - rank: 1 - dim: [[1, n_ions]] - window(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies exactly all those ions ranged irrespective - the type they ended up with. - number_of_ions(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of ions covered by the mask. - The mask value for most may be 0. - - # which does paraprobe use - bitdepth(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - mask(NX_UINT): - unit: NX_UNITLESS - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - dimensions: - rank: 1 - dim: [[1, n_ions]] - molecular_ion_search(NXprocess): - exists: ['min', '0', 'max', '1'] - doc: | - Paraprobe-ranger performs a combinatorial search over - all possible or a reduced set of nuclids to identify - into which ions these can be composed. - isotope_vector_matrix(NX_UINT): - unit: NX_UNITLESS - doc: | - The main result is the list of molecular ions, here formatted - according to the definitions of a set of isotope_vectors - as detailed in :ref:`NXion`. - dimensions: - rank: 2 - dim: [[1, i], [2, 32]] - mass_to_charge_state_ratio(NX_FLOAT): - unit: NX_ANY - doc: | - The mass-to-charge-state ratio of each molecular ion - without considering relativistic or quantum effects. - dimensions: - rank: 1 - dim: [[1, i]] - mass(NX_FLOAT): - exists: optional - unit: NX_ANY - doc: | - The mass of each molecular ion without - considering relativistic or quantum effects. - - # \@units: amu - dimensions: - rank: 1 - dim: [[1, i]] - charge_state(NX_UINT): - unit: NX_CHARGE - doc: | - The charge_state of each molecular ion. - dimensions: - rank: 1 - dim: [[1, i]] - natural_abundance_product(NX_FLOAT): - exists: optional - unit: NX_DIMENSIONLESS - doc: | - The product of the natural abundance of the isotopes building - each molecular ion. Further details are available in - :ref:`NXapm_paraprobe_config_ranger`. - dimensions: - rank: 1 - dim: [[1, i]] - composition_product(NX_FLOAT): - exists: optional - unit: NX_DIMENSIONLESS - doc: | - The product of the natural abundance of the isotopes building - each molecular ion. Further details are available in - :ref:`NXapm_paraprobe_config_ranger`. - dimensions: - rank: 1 - dim: [[1, i]] - number_of_disjoint_nuclids(NX_POSINT): - exists: optional + Number of bits assumed matching on a default datatype. unit: NX_UNITLESS + mask(NX_UINT): doc: | - The number of disjoint nuclids for each molecular ion. - dimensions: - rank: 1 - dim: [[1, i]] - number_of_nuclids(NX_POSINT): - exists: optional - unit: NX_UNITLESS - doc: | - The number of nuclids for each molecular ion. - dimensions: - rank: 1 - dim: [[1, i]] - check_existent_ranging(NXprocess): - exists: ['min', '0', 'max', '1'] - doc: | - Paraprobe-ranger loads iontypes and evaluates for each ion on which - iontype it matches. If it matches on none, the ion is considered of - the default unknown type with a 0 as its respective value in the - iontypes array. In contrast to use_existent_ranging this process - does neither needs measured ion position nor mass-to-charge-state - ratio values. - - ##MK::number_of_ion_types(NX_POSINT): - maximum_number_of_atoms_per_molecular_ion(NX_POSINT): + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. unit: NX_UNITLESS - doc: | - The length of the isotope_vector used to describe molecular ions. - charged_ION(NXion): - exists: ['min', '1', 'max', '256'] - isotope_vector(NX_UINT): - nuclid_list(NX_UINT): - exists: recommended - charge_state(NX_INT): - mass_to_charge_range(NX_FLOAT): - - ##MK::end of the tool-specific section - performance(NXcs_profiling): - current_working_directory: - command_line_call: - exists: optional + dim: (i,) + + (NXprogram): + profiling(NXcs_profiling): start_time(NX_DATE_TIME): - exists: recommended end_time(NX_DATE_TIME): + status(NX_CHAR): + results_path(NX_CHAR): exists: recommended total_elapsed_time(NX_NUMBER): number_of_processes(NX_POSINT): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): - (NXcs_computer): - exists: recommended - name: - exists: recommended - operating_system: - \@version: - uuid: - exists: optional - (NXcs_cpu): - exists: ['min', '0', 'max', 'unbounded'] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_gpu): - exists: ['min', '0', 'max', 'unbounded'] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_mm_sys): - exists: ['min', '0', 'max', '1'] - total_physical_memory(NX_NUMBER): - (NXcs_io_sys): - exists: ['min', '0', 'max', '1'] - (NXcs_io_obj): - exists: ['min', '1', 'max', 'unbounded'] - technology: - max_physical_capacity(NX_NUMBER): - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_profiling_event): - start_time(NX_DATE_TIME): - exists: optional - end_time(NX_DATE_TIME): - exists: optional - description: - elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - number_of_threads(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - number_of_gpus(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - max_virtual_memory_snapshot(NX_NUMBER): - exists: recommended - max_resident_memory_snapshot(NX_NUMBER): - exists: recommended + (NXuser): + exists: ['min', '0', 'max', 'unbounded'] + name(NX_CHAR): + (NXcoordinate_system_set): + paraprobe(NXcoordinate_system): + type(NX_CHAR): + handedness(NX_CHAR): + x(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + y(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + z(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d12fb5165f6decda506bf81f54410afba9e54f22e83c0682ba82fe68d7ddbeee -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The total number of ions in the reconstruction. -# -# -# -# -# Maximum number of allowed atoms per (molecular) ion (fragment). -# Needs to match maximum_number_of_atoms_per_molecular_ion. -# -# -# -# -# Results of a paraprobe-ranger tool run. -# -# -# -# -# -# Version specifier of this application definition. -# -# -# -# -# -# Official NeXus NXDL schema with which this file was written. -# -# -# -# -# -# -# -# -# Given name of the program/software/tool with which this NeXus -# (configuration) file was generated. -# -# -# -# Ideally program version plus build number, or commit hash or description -# of ever persistent resources where the source code of the program and -# build instructions can be found so that the program can be configured -# ideally in such a manner that the result of this computational process -# is recreatable in the same deterministic manner. -# -# -# -# -# -# Ideally, a (globally persistent) unique identifier for referring -# to this analysis. -# -# -# -# -# Possibility for leaving a free-text description about this analysis. -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when the analysis behind this results file -# was started, i.e. the paraprobe-tool executable started as a process. -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when the analysis behind this results file -# were completed and the paraprobe-tool executable exited as a process. -# -# -# -# -# The path and name of the config file for this analysis. -# -# -# -# At least SHA256 strong hash of the specific config_file for -# tracking provenance. -# -# -# -# -# -# Path to the directory where the tool should store NeXus/HDF5 results -# of this analysis. If not specified results will be stored in the -# current working directory. -# -# -# -# -# A statement whether the paraprobe-tool executable managed to -# process the analysis or failed prematurely. -# -# This status is written to the results file after the end_time -# at which point the executable must not compute any analysis. -# Only when this status message is present and shows `success`, the -# user should consider the results. In all other cases it might be -# that the executable has terminated prematurely or another error -# occurred. -# -# -# -# -# -# -# -# -# If used, contact information and eventually details -# of at least the person who performed this analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Details about the coordinate system conventions used. -# -# -# -# The individual coordinate systems which should be used. -# Field names should be prefixed with the following controlled terms -# indicating which individual coordinate system is described: -# -# * paraprobe -# * lab -# * specimen -# * laser -# * leap -# * detector -# * recon -# -# -# -# -# -# -# -# Paraprobe-ranger loads the iontypes and evaluates for each -# ion on which iontype it matches. If it matches on none, the -# ion is considered of the default unknown type with a 0 as its -# respective value in the iontypes array. -# -# -# -# -# The length of the isotope_vector used to describe molecular ions. -# -# -# -# -# -# -# -# -# -# -# The iontype ID for each ion that was best matching, stored in the -# order of the evaporation sequence ID. The here computed iontypes -# do not take into account the charge state of the ion which is -# equivalent to interpreting a RNG and RRNG range files for each -# ion in such a way that only the elements of which a (molecular) ion -# is build are considered. By contrast, charged_iontypes takes -# into account also the charge state. -# -# -# -# -# -# -# -# A bitmask which identifies exactly all those ions ranged irrespective -# the type they ended up with. -# -# -# -# Number of ions covered by the mask. -# The mask value for most may be 0. -# -# -# -# -# -# Number of bits assumed matching on a default datatype. -# (e.g. 8 bits for a C-style uint8). -# -# -# -# -# The unsigned integer array representing the content of the mask. -# If padding is used the padded bits are set to 0. The mask is for -# convenience always as large as the entire dataset as it will -# be stored compressed anyway. The convenience feature with this -# is that then the mask can be decoded with numpy and mirrored -# against the evaporation_id array and one immediately can filter -# out all points that were used by the paraprobe. -# The length of the array adds to the next unsigned integer -# if the number of ions in the dataset is not an integer -# multiple of the bitdepth. -# -# -# -# -# -# -# -# -# -# Paraprobe-ranger performs a combinatorial search over -# all possible or a reduced set of nuclids to identify -# into which ions these can be composed. -# -# -# -# The main result is the list of molecular ions, here formatted -# according to the definitions of a set of isotope_vectors -# as detailed in :ref:`NXion`. -# -# -# -# -# -# -# -# -# The mass-to-charge-state ratio of each molecular ion -# without considering relativistic or quantum effects. -# -# -# -# -# -# -# -# The mass of each molecular ion without -# considering relativistic or quantum effects. -# -# -# -# -# -# -# -# -# The charge_state of each molecular ion. -# -# -# -# -# -# -# -# The product of the natural abundance of the isotopes building -# each molecular ion. Further details are available in -# :ref:`NXapm_paraprobe_config_ranger`. -# -# -# -# -# -# -# -# The product of the natural abundance of the isotopes building -# each molecular ion. Further details are available in -# :ref:`NXapm_paraprobe_config_ranger`. -# -# -# -# -# -# -# -# The number of disjoint nuclids for each molecular ion. -# -# -# -# -# -# -# -# The number of nuclids for each molecular ion. -# -# -# -# -# -# -# -# -# Paraprobe-ranger loads iontypes and evaluates for each ion on which -# iontype it matches. If it matches on none, the ion is considered of -# the default unknown type with a 0 as its respective value in the -# iontypes array. In contrast to use_existent_ranging this process -# does neither needs measured ion position nor mass-to-charge-state -# ratio values. -# -# -# -# -# The length of the isotope_vector used to describe molecular ions. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Specify if it was different from the number_of_processes -# in the NXcs_profiling super class. -# -# -# -# -# -# Specify if it was different from the number_of_threads -# in the NXcs_profiling super class. -# -# -# -# -# -# Specify if it was different from the number_of_threads -# in the NXcs_profiling super class. -# -# -# -# -# -# -# -# -# + # molecular_ion_search(NXprocess): + # exists: ['min', '0', 'max', '1'] + # doc: | + # Paraprobe-ranger performs a combinatorial search over + # all possible or a reduced set of nuclids to identify + # into which ions these can be composed. + # isotope_vector_matrix(NX_UINT): + # unit: NX_UNITLESS + # doc: | + # The main result is the list of molecular ions, here formatted + # according to the definitions of a set of isotope_vectors + # as detailed in :ref:`NXion`. + # dimensions: + # rank: 2 + # dim: [[1, i], [2, 32]] + # mass_to_charge_state_ratio(NX_FLOAT): + # unit: NX_ANY + # doc: | + # The mass-to-charge-state ratio of each molecular ion + # without considering relativistic or quantum effects. + # dimensions: + # rank: 1 + # dim: [[1, i]] + # mass(NX_FLOAT): + # exists: optional + # unit: NX_ANY + # doc: | + # The mass of each molecular ion without + # considering relativistic or quantum effects. + + # # \@units: amu + # dimensions: + # rank: 1 + # dim: [[1, i]] + # charge_state(NX_UINT): + # unit: NX_CHARGE + # doc: | + # The charge_state of each molecular ion. + # dimensions: + # rank: 1 + # dim: [[1, i]] + # natural_abundance_product(NX_FLOAT): + # exists: optional + # unit: NX_DIMENSIONLESS + # doc: | + # The product of the natural abundance of the isotopes building + # each molecular ion. Further details are available in + # :ref:`NXapm_paraprobe_config_ranger`. + # dimensions: + # rank: 1 + # dim: [[1, i]] + # composition_product(NX_FLOAT): + # exists: optional + # unit: NX_DIMENSIONLESS + # doc: | + # The product of the natural abundance of the isotopes building + # each molecular ion. Further details are available in + # :ref:`NXapm_paraprobe_config_ranger`. + # dimensions: + # rank: 1 + # dim: [[1, i]] + # number_of_disjoint_nuclids(NX_POSINT): + # exists: optional + # unit: NX_UNITLESS + # doc: | + # The number of disjoint nuclids for each molecular ion. + # dimensions: + # rank: 1 + # dim: [[1, i]] + # number_of_nuclids(NX_POSINT): + # exists: optional + # unit: NX_UNITLESS + # doc: | + # The number of nuclids for each molecular ion. + # dimensions: + # rank: 1 + # dim: [[1, i]] + # check_existent_ranging(NXprocess): + # exists: ['min', '0', 'max', '1'] + # doc: | + # Paraprobe-ranger loads iontypes and evaluates for each ion on which + # iontype it matches. If it matches on none, the ion is considered of + # the default unknown type with a 0 as its respective value in the + # iontypes array. In contrast to use_existent_ranging this process + # does neither needs measured ion position nor mass-to-charge-state + # ratio values. + + # ##MK::number_of_ion_types(NX_POSINT): + # maximum_number_of_atoms_per_molecular_ion(NX_POSINT): + # unit: NX_UNITLESS + # doc: | + # The length of the isotope_vector used to describe molecular ions. + # charged_ION(NXion): + # exists: ['min', '1', 'max', '256'] + # isotope_vector(NX_UINT): + # nuclid_list(NX_UINT): + # exists: recommended + # charge_state(NX_INT): + # mass_to_charge_range(NX_FLOAT): diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_transcoder_config.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_transcoder_config.yaml index a57490abcf..eccde9b25c 100644 --- a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_transcoder_config.yaml +++ b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_transcoder_config.yaml @@ -1,6 +1,6 @@ category: application doc: | - Application definition for configuration files of the paraprobe-transcoder tool. + Application definition for a configuration file of the paraprobe-transcoder tool. This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. symbols: @@ -19,7 +19,8 @@ NXapm_paraprobe_transcoder_config(NXobject): doc: | Official NeXus NXDL schema with which this file was written. enumeration: [NXapm_paraprobe_transcoder_config] - config(NXapm_paraprobe_tool_config): + transcode(NXapm_paraprobe_tool_config): + exists: ['min', 0, 'max', '1'] (NXidentifier): exists: optional analysis_identifier(NX_UINT): @@ -31,13 +32,14 @@ NXapm_paraprobe_transcoder_config(NXobject): algorithm(NX_CHAR): position(NX_CHAR): mass_to_charge(NX_CHAR): - iontypes(NXserialized): + ranging(NXserialized): type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): ranging_definitions(NX_CHAR): - # (NXprogram): + # add spatial and other type of filters + # (NXprogram): profiling(NXcs_profiling): exists: recommended start_time(NX_DATE_TIME): diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_transcoder_results.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_transcoder_results.yaml index f87ad01e0b..a46e5c2cda 100644 --- a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_transcoder_results.yaml +++ b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_transcoder_results.yaml @@ -3,7 +3,7 @@ doc: | Application definition for results files of the paraprobe-transcoder tool. This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. - The purpose and need of paraprobe-transcoder tool is to create a standardized representation + The purpose and need of the paraprobe-transcoder tool is to create a standardized representation of reconstructed position and mass-to-charge-state-ratio values surplus other pieces of information to enable at all to work with atom probe data in reconstruction space. This includes ranging definitions which map mass-to-charge-state ratio values onto iontypes. @@ -51,7 +51,7 @@ NXapm_paraprobe_transcoder_results(NXobject): doc: | Official NeXus NXDL schema with which this file was written. enumeration: [NXapm_paraprobe_transcoder_results] - atom_probe(NXapm_paraprobe_transcoder_results): + atom_probe(NXapm_paraprobe_tool_results): # this is currently a trick but should in the future be renamed to have a one-to-one # representation equivalence of reconstructed position and mass-to-charge-state-ratio value # arrays such that diff --git a/contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml b/contributed_definitions/nyaml/refactor/NXcs_filter_boolean_mask.yaml similarity index 96% rename from contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml rename to contributed_definitions/nyaml/refactor/NXcs_filter_boolean_mask.yaml index f6ed55a5a4..55563e5a1e 100644 --- a/contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml +++ b/contributed_definitions/nyaml/refactor/NXcs_filter_boolean_mask.yaml @@ -1,6 +1,6 @@ category: base doc: | - Computer science base class for packing and unpacking booleans. + Base class for packing and unpacking booleans. This base class bookkeeps metadata to inform software about necessary modulo operations to decode e.g. set membership of objects in sets which are encoded @@ -45,11 +45,11 @@ NXcs_filter_boolean_mask(NXobject): If depends_on is not provided, it is assumed that the mask applies to its direct parent. - number_of_objects(NX_INT): + number_of_objects(NX_UINT): doc: | Number of objects represented by the mask. unit: NX_UNITLESS - bitdepth(NX_INT): + bitdepth(NX_UINT): doc: | Number of bits assumed matching on a default datatype. (e.g. 8 bits for a C-style uint8). diff --git a/contributed_definitions/nyaml/refactor/NXmatch_filter.yaml b/contributed_definitions/nyaml/refactor/NXmatch_filter.yaml index 8e4d019a8a..589fdd65e8 100644 --- a/contributed_definitions/nyaml/refactor/NXmatch_filter.yaml +++ b/contributed_definitions/nyaml/refactor/NXmatch_filter.yaml @@ -1,6 +1,6 @@ category: base doc: | - Settings of a filter to select entries based on their value. + Base class of a filter to select members of a set based on their identifier. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -8,7 +8,7 @@ symbols: How many different match values does the filter specify. type: group NXmatch_filter(NXobject): - method: + method(NX_CHAR): doc: | Logical operation of the filter: Whitelist specifies which entries with said value to include. diff --git a/contributed_definitions/nyaml/refactor/NXspatial_filter.yaml b/contributed_definitions/nyaml/refactor/NXspatial_filter.yaml index 023367a9c2..8d3df6b609 100644 --- a/contributed_definitions/nyaml/refactor/NXspatial_filter.yaml +++ b/contributed_definitions/nyaml/refactor/NXspatial_filter.yaml @@ -25,8 +25,8 @@ NXspatial_filter(NXobject): that define which objects will be included and which excluded: * entire_dataset, no filter is applied, all objects are used. - * union_of_primitives, a filter with (rotated) geometric primitives. - Objects in or on the surface of the primitives are considered. + * union_of_primitives, a filter with (possibly non-axis-aligned) geometric + primitives. Objects in or on the surface of the primitives are considered. All other objects are excluded. * bitmask, a boolean array whose bits encode with 1 which objects are included. Bits set to zero encode which objects diff --git a/contributed_definitions/nyaml/refactor/NXsubsampling_filter.yaml b/contributed_definitions/nyaml/refactor/NXsubsampling_filter.yaml index ea01dd19f5..ffce75716c 100644 --- a/contributed_definitions/nyaml/refactor/NXsubsampling_filter.yaml +++ b/contributed_definitions/nyaml/refactor/NXsubsampling_filter.yaml @@ -1,17 +1,19 @@ category: base doc: | - Settings of a filter to sample entries based on their value. + Base class of a filter to sample members in a set based on their identifier. # symbols: type: group NXsubsampling_filter(NXobject): - linear_range_min_incr_max(NX_UINT): - unit: NX_UNITLESS + min_incr_max(NX_INT): doc: | - Triplet of the minimum, increment, and maximum value which will - be included in the analysis. The increment controls which n-th entry to take. + Triplet of the minimum, increment, and maximum identifier to include + for a linear sequence of identifier. The increment controls which n-th + identifier (value) to take. - Take as an example a dataset with 100 entries (their indices start at zero) - and the filter set to 0, 1, 99. This will process each entry. - 0, 2, 99 will take each second entry. 90, 3, 99 will take only each third - entry beginning from entry 90 up to 99. + Take as an example a dataset with 100 identifier (aka entries provided + their identifier start at zero, i.e. identifier_offset is 0). Assume that linear_range_min_incr_max + is set to [0, 1, 99]. This will process each identifier. 0, 2, 99 will take each second identifier. + 90, 3, 99 will take each third identifier beginning from identifier 90 up to 99. + unit: NX_UNITLESS dim: (3,) + # TODO clarify that identifier are in id_offset, id_offset + 1, idoffset + 2, idoffset + n From d5b5d00f6f20dbdd8c426687dce5ae55b41b13d8 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 4 Jan 2024 09:19:58 +0100 Subject: [PATCH 0403/1012] fix beam_TYPE and distance --- contributed_definitions/NXmpes.nxdl.xml | 14 +++++++++----- contributed_definitions/nyaml/NXmpes.yaml | 13 ++++++++----- 2 files changed, 17 insertions(+), 10 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 460ee47840..e65a3f1cd3 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -191,13 +191,17 @@ Comment from mpes may workshop: we have a subdefinition NXlink to refer to a path. This would also be helpful for NXtransformations--> + + Properties of the photon beam at a given location. + Should be named with the same appendix as source_TYPE, e.g., + for `source_probe` it should refer to `beam_probe`. + - The beam emitted by this source. - Should be named with the same appendix, e.g., - for `source_probe` it should refer to `beam_probe`. - Refers to the same concept as /NXentry/NXinstrument/source_TYPE - and may be linked. + Distance between the point where the current NXbeam instance is evaluating + the beam properties and the point where the beam interacts with the sample. + For photoemission, the latter is the point where the the centre of the beam + touches the sample surface. diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 483e86163e..be72a990c0 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -137,15 +137,18 @@ NXmpes(NXobject): # we have a subdefinition NXlink to refer to a path. # This would also be helpful for NXtransformations beam_TYPE(NXbeam): + doc: | + Properties of the photon beam at a given location. + Should be named with the same appendix as source_TYPE, e.g., + for `source_probe` it should refer to `beam_probe`. distance(NX_NUMBER): unit: NX_LENGTH exists: recommended doc: | - The beam emitted by this source. - Should be named with the same appendix, e.g., - for `source_probe` it should refer to `beam_probe`. - Refers to the same concept as /NXentry/NXinstrument/source_TYPE - and may be linked. + Distance between the point where the current NXbeam instance is evaluating + the beam properties and the point where the beam interacts with the sample. + For photoemission, the latter is the point where the the centre of the beam + touches the sample surface. incident_energy(NX_FLOAT): unit: NX_ENERGY incident_energy_spread(NX_NUMBER): From e8754f603f067add0669ca76a36073c33d7670c7 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 4 Jan 2024 09:23:54 +0100 Subject: [PATCH 0404/1012] remove additional whitespace in NXmpes yaml --- contributed_definitions/nyaml/NXmpes.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index be72a990c0..6557b5cac3 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -145,9 +145,9 @@ NXmpes(NXobject): unit: NX_LENGTH exists: recommended doc: | - Distance between the point where the current NXbeam instance is evaluating + Distance between the point where the current NXbeam instance is evaluating the beam properties and the point where the beam interacts with the sample. - For photoemission, the latter is the point where the the centre of the beam + For photoemission, the latter is the point where the the centre of the beam touches the sample surface. incident_energy(NX_FLOAT): unit: NX_ENERGY From c5f3dc4a4820e399b1be260d9b6e4523a77a8e40 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 4 Jan 2024 09:29:36 +0100 Subject: [PATCH 0405/1012] remove applied fields from calibrations --- contributed_definitions/NXmpes.nxdl.xml | 33 ----------------------- contributed_definitions/nyaml/NXmpes.yaml | 21 --------------- 2 files changed, 54 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index e65a3f1cd3..64f8935259 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -405,11 +405,6 @@ Optional constant settings (like lens focusing parameters on the sample: positio .. _ISO 15472:2010: https://www.iso.org/standard/74811.html - - - Has an energy calibration been applied? - - This is the calibrated energy axis to be used for data plotting. @@ -417,11 +412,6 @@ Optional constant settings (like lens focusing parameters on the sample: positio - - - Has an angular calibration been applied? - - This is the calibrated angular axis to be used for data plotting. @@ -429,11 +419,6 @@ Optional constant settings (like lens focusing parameters on the sample: positio - - - Has an spatial calibration been applied? - - This is the calibrated spatial axis to be used for data plotting. @@ -441,11 +426,6 @@ Optional constant settings (like lens focusing parameters on the sample: positio - - - Has an momentum calibration been applied? - - This is the momentum axis to be used for data plotting. @@ -464,12 +444,6 @@ Optional constant settings (like lens focusing parameters on the sample: positio .. _12.74 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 - - - Have the energy axes been adjusted (e.g., in cases where samples are not - conductive)? - - Electronic core or valence level that was used for the calibration. @@ -513,13 +487,6 @@ Optional constant settings (like lens focusing parameters on the sample: positio field of the transmission_function. This calibration procedure is used to account for the different tranmsission efficiencies when using different lens modes. - - - Has an intensity calibration been applied? - - That is, has the transmission function of the analyser been taken into account? - - Transmission function of the electron analyser. diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 6557b5cac3..6dc70d237c 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -334,36 +334,24 @@ NXmpes(NXobject): `ISO 15472:2010`_ specification. .. _ISO 15472:2010: https://www.iso.org/standard/74811.html - applied(NX_BOOLEAN): - doc: | - Has an energy calibration been applied? calibrated_axis(NX_FLOAT): exists: recommended doc: | This is the calibrated energy axis to be used for data plotting. angular_calibration(NXcalibration): exists: optional - applied(NX_BOOLEAN): - doc: | - Has an angular calibration been applied? calibrated_axis(NX_FLOAT): exists: recommended doc: | This is the calibrated angular axis to be used for data plotting. spatial_calibration(NXcalibration): exists: optional - applied(NX_BOOLEAN): - doc: | - Has an spatial calibration been applied? calibrated_axis(NX_FLOAT): exists: recommended doc: | This is the calibrated spatial axis to be used for data plotting. momentum_calibration(NXcalibration): exists: optional - applied(NX_BOOLEAN): - doc: | - Has an momentum calibration been applied? calibrated_axis(NX_FLOAT): exists: recommended doc: | @@ -382,10 +370,6 @@ NXmpes(NXobject): spec: ISO 18115-1:2023 term: 12.74 ff. url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 - applied(NX_BOOLEAN): - doc: | - Have the energy axes been adjusted (e.g., in cases where samples are not - conductive)? level(NXelectron_level): exists: recommended doc: | @@ -424,11 +408,6 @@ NXmpes(NXobject): kinetic energy is multiplied by the corresponding value in the relative_intensity field of the transmission_function. This calibration procedure is used to account for the different tranmsission efficiencies when using different lens modes. - applied(NX_BOOLEAN): - doc: | - Has an intensity calibration been applied? - - That is, has the transmission function of the analyser been taken into account? mapping(NXdata): exists: recommended doc: | From d89d031352ee962f10bec853413bbb93912973f0 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 4 Jan 2024 09:33:23 +0100 Subject: [PATCH 0406/1012] set situation and gas pressure to recommended in NXsample --- contributed_definitions/NXmpes.nxdl.xml | 4 ++-- contributed_definitions/nyaml/NXmpes.yaml | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 64f8935259..ca1c572d4c 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -573,7 +573,7 @@ Optional constant settings (like lens focusing parameters on the sample: positio /entry/instrument/manipulator/sample_temperature. - + @@ -581,7 +581,7 @@ Optional constant settings (like lens focusing parameters on the sample: positio - + Voltage applied to sample and sample holder. diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 6dc70d237c..008ef05178 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -480,11 +480,11 @@ NXmpes(NXobject): recoded, this is an array of length m of temperatures. This should be a link to /entry/instrument/manipulator/sample_temperature. situation: - exists: optional + exists: recommended enumeration: [vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere] gas_pressure(NX_FLOAT): unit: NX_PRESSURE - exists: optional + exists: recommended bias(NX_FLOAT): unit: NX_VOLTAGE exists: optional From f7fc4d8d33731f27829c0381d2ec0c3b72118e4e Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 4 Jan 2024 09:36:19 +0100 Subject: [PATCH 0407/1012] remove unneeded docstring from NXcollectioncolumn/mode --- contributed_definitions/NXmpes.nxdl.xml | 6 +----- contributed_definitions/nyaml/NXmpes.yaml | 2 -- 2 files changed, 1 insertion(+), 7 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index ca1c572d4c..f66bbef70b 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -257,11 +257,7 @@ Optional constant settings (like lens focusing parameters on the sample: positio - - - Labelling of the lens setting in use. - - + diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 008ef05178..e57adeff83 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -205,8 +205,6 @@ NXmpes(NXobject): enumeration: [Standard, Angular dispersive, Spatial dispersive, Selective area, Deflector, PEEM, Momentum Microscope, Torroidal] mode: exists: recommended - doc: | - Labelling of the lens setting in use. projection: exists: recommended field_aperture(NXaperture): From 3ad739685bf0e7865f387163d869bfd9acc4ff3e Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 4 Jan 2024 10:24:33 +0100 Subject: [PATCH 0408/1012] remove NXinstrument yaml from contributed --- .../nyaml/NXinstrument.yaml | 206 ------------------ 1 file changed, 206 deletions(-) delete mode 100644 contributed_definitions/nyaml/NXinstrument.yaml diff --git a/contributed_definitions/nyaml/NXinstrument.yaml b/contributed_definitions/nyaml/NXinstrument.yaml deleted file mode 100644 index e9f83eeaf7..0000000000 --- a/contributed_definitions/nyaml/NXinstrument.yaml +++ /dev/null @@ -1,206 +0,0 @@ -category: base -doc: | - 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. -type: group -NXinstrument(NXobject): - name: - doc: | - Name of instrument - \@short_name: - doc: | - short name for instrument, perhaps the acronym - energy_resolution(NXresolution): - doc: | - Energy resolution of the experiment (FWHM or gaussian broadening). - physical_quantity: - enumeration: [energy] - resolution(NXdata): - unit: NX_ENERGY - momentum_resolution(NXresolution): - doc: | - Momentum resolution of the experiment (FWHM or gaussian broadening). - physical_quantity: - enumeration: [momentum] - resolution(NXdata): - unit: NX_WAVENUMBER - angular_resolution(NXresolution): - doc: | - Angular resolution of the experiment (FWHM or gaussian broadening). - physical_quantity: - enumeration: [angle] - resolution(NXdata): - unit: NX_ANGLE - spatial_resolution(NXresolution): - doc: | - Spatial resolution of the experiment (Airy disk radius) - physical_quantity: - enumeration: [length] - resolution(NXdata): - unit: NX_LENGTH - temporal_resolution(NXresolution): - doc: | - Temporal resolution of the experiment (FWHM) - physical_quantity: - enumeration: [time] - resolution(NXdata): - unit: NX_TIME - (NXaperture): - (NXattenuator): - (NXbeam): - (NXbeam_stop): - (NXbending_magnet): - (NXcollimator): - (NXcollection): - (NXcapillary): - (NXcrystal): - (NXdetector): - (NXdetector_group): - (NXdisk_chopper): - (NXevent_data): - (NXfabrication): - (NXfermi_chopper): - (NXfilter): - (NXflipper): - (NXguide): - (NXinsertion_device): - (NXmirror): - (NXmoderator): - (NXmonochromator): - (NXpolarizer): - (NXpositioner): - (NXresolution): - (NXsource): - (NXtransformations)DIFFRACTOMETER: - (NXvelocity_selector): - (NXxraylens): - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 331d6037bd4c05402a42cab90e3df4c3115b21231d57ef54b1221e1ed859584d -# -# -# -# -# -# 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. -# -# -# -# Name of instrument -# -# -# -# short name for instrument, perhaps the acronym -# -# -# -# -# -# Energy resolution of the experiment (FWHM or gaussian broadening) -# -# -# -# -# Momentum resolution of the experiment (FWHM) -# -# -# -# -# Angular resolution of the experiment (FWHM) -# -# -# -# -# Spatial resolution of the experiment (Airy disk radius) -# -# -# -# -# Temporal resolution of the experiment (FWHM) -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# From 7dbbb7f9b9602a228a59bf7d2a00767b5a6ab0da Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 4 Jan 2024 10:26:08 +0100 Subject: [PATCH 0409/1012] remove explicit resolution names from NXinstrument --- base_classes/NXinstrument.nxdl.xml | 34 ++++------------------------ base_classes/nyaml/NXinstrument.yaml | 21 +---------------- 2 files changed, 6 insertions(+), 49 deletions(-) diff --git a/base_classes/NXinstrument.nxdl.xml b/base_classes/NXinstrument.nxdl.xml index a7298ce55d..6295d8bbf4 100644 --- a/base_classes/NXinstrument.nxdl.xml +++ b/base_classes/NXinstrument.nxdl.xml @@ -1,10 +1,10 @@ - + - - Subclass of NXelectronanalyser to describe the energy dispersion section of a - photoelectron analyser. - - - Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, - mirror, retarding grid, etc. + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. - - - - Energy of the electrons on the mean path of the analyser. Pass energy for - hemispherics, drift energy for tofs. - - Refers to Term `12.63`_ of the ISO 18115-1:2023 specification. - - .. _12.63: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.63 - - - - - Kinetic energy set for the dispersive analyzer section. Can be either the set - kinetic energy, or the whole calibrated energy axis of a scan. - - - - - Center of the energy window - - - - - The interval of transmitted energies. It can be two different things depending - on whether the scan is fixed or swept. With a fixed scan it is a 2 vector - containing the extrema of the transmitted energy window (smaller number first). - With a swept scan of m steps it is a 2xm array of windows one for each - measurement point. - - - - - Size, position and shape of a slit in dispersive analyzer, e.g. entrance and - exit slits. - - - - - Diameter of the dispersive orbit - - - - - Way of scanning the energy axis (fixed or sweep). - - This concept is related to term `12.65`_ of the ISO 18115-1:2023 standard. - .. _12.65: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.65 - - This concept is related to term `12.66`_ of the ISO 18115-1:2023 standard. - .. _12.66: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.66 - - - - - - - - - Length of the tof drift electrode - - - - - Deflectors in the energy dispersive section - - - - - Individual lenses in the energy dispersive section - - - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the energy dispersive element as a component in the instrument. - Conventions from the NXtransformations base class are used. In principle, - the McStas coordinate system is used. The first transformation has to point - either to another component of the system or . (for pointing to the reference frame) - to relate it relative to the experimental setup. Typically, the components of a system - should all be related relative to each other and only one component should relate to - the reference coordinate system. - - + + + Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, + mirror, retarding grid, etc. + + + + + Energy of the electrons on the mean path of the analyser. Pass energy for + hemispherics, drift energy for tofs. + + Refers to Term `12.63`_ of the ISO 18115-1:2023 specification. + + .. _12.63: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.63 + + + + + Kinetic energy set for the dispersive analyzer section. Can be either the set + kinetic energy, or the whole calibrated energy axis of a scan. + + + + + Center of the energy window + + + + + The interval of transmitted energies. It can be two different things depending + on whether the scan is fixed or swept. With a fixed scan it is a 2 vector + containing the extrema of the transmitted energy window (smaller number first). + With a swept scan of m steps it is a 2xm array of windows one for each + measurement point. + + + + + Size, position and shape of a slit in dispersive analyzer, e.g. entrance and + exit slits. + + + + + Diameter of the dispersive orbit + + + + + Way of scanning the energy axis (fixed or sweep). + + This concept is related to term `12.65`_ of the ISO 18115-1:2023 standard. + + .. _12.65: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.65 + + This concept is related to term `12.66`_ of the ISO 18115-1:2023 standard. + + .. _12.66: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.66 + + + + + + + + + Length of the tof drift electrode + + + + + Deflectors in the energy dispersive section + + + + + Individual lenses in the energy dispersive section + + + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the energy dispersive element as a component in the instrument. + Conventions from the NXtransformations base class are used. In principle, + the McStas coordinate system is used. The first transformation has to point + either to another component of the system or . (for pointing to the reference frame) + to relate it relative to the experimental setup. Typically, the components of a system + should all be related relative to each other and only one component should relate to + the reference coordinate system. + + diff --git a/contributed_definitions/NXmpes_arpes.nxdl.xml b/contributed_definitions/NXmpes_arpes.nxdl.xml index be4fc6a5ac..48bb044f2e 100644 --- a/contributed_definitions/NXmpes_arpes.nxdl.xml +++ b/contributed_definitions/NXmpes_arpes.nxdl.xml @@ -1,10 +1,10 @@ - + - +with higher granularity in the data description. +--> This is an general application definition for angle-resolved multidimensional photoelectron spectroscopy. From ea5051d4ea13638a5cc031101f6fbaa38add62c9 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 4 Jan 2024 12:03:37 +0100 Subject: [PATCH 0413/1012] Make NXDL with nyaml v0.0.4 --- .../NXenergydispersion.nxdl.xml | 244 +++++++++--------- contributed_definitions/NXmpes_arpes.nxdl.xml | 4 +- .../nyaml/NXmpes_arpes.yaml | 4 +- 3 files changed, 126 insertions(+), 126 deletions(-) diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml index 2ea663c51e..819b5bf20f 100644 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ b/contributed_definitions/NXenergydispersion.nxdl.xml @@ -1,122 +1,122 @@ - - - - - - Subclass of NXelectronanalyser to describe the energy dispersion section of a - photoelectron analyser. - - - - Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, - mirror, retarding grid, etc. - - - - - Energy of the electrons on the mean path of the analyser. Pass energy for - hemispherics, drift energy for tofs. - - Refers to Term `12.63`_ of the ISO 18115-1:2023 specification. - - .. _12.63: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.63 - - - - - Kinetic energy set for the dispersive analyzer section. Can be either the set - kinetic energy, or the whole calibrated energy axis of a scan. - - - - - Center of the energy window - - - - - The interval of transmitted energies. It can be two different things depending - on whether the scan is fixed or swept. With a fixed scan it is a 2 vector - containing the extrema of the transmitted energy window (smaller number first). - With a swept scan of m steps it is a 2xm array of windows one for each - measurement point. - - - - - Size, position and shape of a slit in dispersive analyzer, e.g. entrance and - exit slits. - - - - - Diameter of the dispersive orbit - - - - - Way of scanning the energy axis (fixed or sweep). - - This concept is related to term `12.65`_ of the ISO 18115-1:2023 standard. - - .. _12.65: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.65 - - This concept is related to term `12.66`_ of the ISO 18115-1:2023 standard. - - .. _12.66: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.66 - - - - - - - - - Length of the tof drift electrode - - - - - Deflectors in the energy dispersive section - - - - - Individual lenses in the energy dispersive section - - - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the energy dispersive element as a component in the instrument. - Conventions from the NXtransformations base class are used. In principle, - the McStas coordinate system is used. The first transformation has to point - either to another component of the system or . (for pointing to the reference frame) - to relate it relative to the experimental setup. Typically, the components of a system - should all be related relative to each other and only one component should relate to - the reference coordinate system. - - - + + + + + + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. + + + + Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, + mirror, retarding grid, etc. + + + + + Energy of the electrons on the mean path of the analyser. Pass energy for + hemispherics, drift energy for tofs. + + Refers to Term `12.63`_ of the ISO 18115-1:2023 specification. + + .. _12.63: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.63 + + + + + Kinetic energy set for the dispersive analyzer section. Can be either the set + kinetic energy, or the whole calibrated energy axis of a scan. + + + + + Center of the energy window + + + + + The interval of transmitted energies. It can be two different things depending + on whether the scan is fixed or swept. With a fixed scan it is a 2 vector + containing the extrema of the transmitted energy window (smaller number first). + With a swept scan of m steps it is a 2xm array of windows one for each + measurement point. + + + + + Size, position and shape of a slit in dispersive analyzer, e.g. entrance and + exit slits. + + + + + Diameter of the dispersive orbit + + + + + Way of scanning the energy axis (fixed or sweep). + + This concept is related to term `12.65`_ of the ISO 18115-1:2023 standard. + + .. _12.65: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.65 + + This concept is related to term `12.66`_ of the ISO 18115-1:2023 standard. + + .. _12.66: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.66 + + + + + + + + + Length of the tof drift electrode + + + + + Deflectors in the energy dispersive section + + + + + Individual lenses in the energy dispersive section + + + + + + + Collection of axis-based translations and rotations to describe the location and + geometry of the energy dispersive element as a component in the instrument. + Conventions from the NXtransformations base class are used. In principle, + the McStas coordinate system is used. The first transformation has to point + either to another component of the system or . (for pointing to the reference frame) + to relate it relative to the experimental setup. Typically, the components of a system + should all be related relative to each other and only one component should relate to + the reference coordinate system. + + + diff --git a/contributed_definitions/NXmpes_arpes.nxdl.xml b/contributed_definitions/NXmpes_arpes.nxdl.xml index 48bb044f2e..e1b8502532 100644 --- a/contributed_definitions/NXmpes_arpes.nxdl.xml +++ b/contributed_definitions/NXmpes_arpes.nxdl.xml @@ -25,8 +25,8 @@ diff --git a/contributed_definitions/nyaml/NXmpes_arpes.yaml b/contributed_definitions/nyaml/NXmpes_arpes.yaml index 0f06b7697b..bfafa77520 100644 --- a/contributed_definitions/nyaml/NXmpes_arpes.yaml +++ b/contributed_definitions/nyaml/NXmpes_arpes.yaml @@ -1,7 +1,7 @@ #Pincelli, Rettig, Arora at fhi-berlin.mpg.de, Dobener at hu-berlin.de, 06/2022 #Draft version of a NeXus application definition for angle resolved photoemission. -#This appdef aims to describe data produced from hemispherical anlysers, -#with at least an angular coordinate and one an energy coordinate. +#This appdef aims to describe data produced from hemispherical analysers, +#with at least an angular coordinate and one energy coordinate. #It is designed to be extended by other application definitions #with higher granularity in the data description. From cf5322f6ceb8638392128df455adc092c626c9bb Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 4 Jan 2024 12:09:28 +0100 Subject: [PATCH 0414/1012] docstring fix in NXenergydispersion.yaml --- contributed_definitions/NXenergydispersion.nxdl.xml | 4 ++-- contributed_definitions/nyaml/NXenergydispersion.yaml | 3 ++- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml index 819b5bf20f..1e159ac64c 100644 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ b/contributed_definitions/NXenergydispersion.nxdl.xml @@ -44,8 +44,8 @@ - Kinetic energy set for the dispersive analyzer section. Can be either the set - kinetic energy, or the whole calibrated energy axis of a scan. + Kinetic energy set for the dispersive analyzer section. Can be either the set kinetic energy, + or the whole calibrated energy axis of a scan." diff --git a/contributed_definitions/nyaml/NXenergydispersion.yaml b/contributed_definitions/nyaml/NXenergydispersion.yaml index 10ed925c7a..0fee9736db 100644 --- a/contributed_definitions/nyaml/NXenergydispersion.yaml +++ b/contributed_definitions/nyaml/NXenergydispersion.yaml @@ -18,7 +18,8 @@ NXenergydispersion(NXobject): .. _12.63: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.63 kinetic_energy(NX_FLOAT): - doc: "Kinetic energy set for the dispersive analyzer section. Can be either the set kinetic energy, + doc: | + Kinetic energy set for the dispersive analyzer section. Can be either the set kinetic energy, or the whole calibrated energy axis of a scan." unit: NX_ENEGRY center_energy(NX_FLOAT): From c6b5882cabfc082513e5695d383019a94a9bce26 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 4 Jan 2024 14:21:20 +0100 Subject: [PATCH 0415/1012] fix xref in NXenergydispersion --- contributed_definitions/NXenergydispersion.nxdl.xml | 2 +- .../nyaml/NXenergydispersion.yaml | 12 +++++++----- 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml index 803aa8aaae..1add356ff0 100644 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ b/contributed_definitions/NXenergydispersion.nxdl.xml @@ -37,7 +37,7 @@ Energy of the electrons on the mean path of the analyser. Pass energy for hemispherics, drift energy for tofs. - Refers to Term `12.63`_ of the ISO 18115-1:2023 specification. + This concept is related to term `12.63`_ of the ISO 18115-1:2023 standard. .. _12.63: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.63 diff --git a/contributed_definitions/nyaml/NXenergydispersion.yaml b/contributed_definitions/nyaml/NXenergydispersion.yaml index 02c1d1d117..98d86ec307 100644 --- a/contributed_definitions/nyaml/NXenergydispersion.yaml +++ b/contributed_definitions/nyaml/NXenergydispersion.yaml @@ -10,13 +10,15 @@ NXenergydispersion(NXobject): mirror, retarding grid, etc. pass_energy(NX_FLOAT): unit: NX_ENERGY - doc: | + doc: + - | Energy of the electrons on the mean path of the analyser. Pass energy for hemispherics, drift energy for tofs. - - Refers to Term `12.63`_ of the ISO 18115-1:2023 specification. - - .. _12.63: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.63 + - | + xref: + spec: ISO 18115-1:2023 + term: 12.63 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.63 center_energy(NX_FLOAT): unit: NX_ENERGY doc: | From b50f160a37ac684bde10968ca5d3b87d88b8becc Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 4 Jan 2024 18:26:40 +0100 Subject: [PATCH 0416/1012] Working on ii) mirrored concept used for NXem with NXapm_msr and NXapm_sim to enable a description of simulation and measurement the work on NXapm is not yet finished, NXapm_new is the constraint set that then will become NXapm, the current NXapm will be refactored to NXapm_base, then the refactoring of the NXapm is completed, refactoring of paraprobe-specific base classes postpone for the reason of too much uncertainty yet with the here made conceptual changes of rigorously relying on base class inheritance --- .../nyaml/refactor/NXapm_msr.yaml | 128 ++++ .../nyaml/refactor/NXapm_sim.yaml | 17 + .../nyaml/refactor/NXpulser_apm.yaml | 15 +- .../nyaml/refactor/Nxapm_new.yaml | 388 +++++++++++ .../nyaml/refactor/find_a_place_in_nxapm.txt | 643 ++++++++++++++++++ 5 files changed, 1182 insertions(+), 9 deletions(-) create mode 100644 contributed_definitions/nyaml/refactor/NXapm_msr.yaml create mode 100644 contributed_definitions/nyaml/refactor/NXapm_sim.yaml create mode 100644 contributed_definitions/nyaml/refactor/Nxapm_new.yaml create mode 100644 contributed_definitions/nyaml/refactor/find_a_place_in_nxapm.txt diff --git a/contributed_definitions/nyaml/refactor/NXapm_msr.yaml b/contributed_definitions/nyaml/refactor/NXapm_msr.yaml new file mode 100644 index 0000000000..c8471e563c --- /dev/null +++ b/contributed_definitions/nyaml/refactor/NXapm_msr.yaml @@ -0,0 +1,128 @@ +category: base +doc: | + Base class for collecting a session with a real atom probe or field-ion microscope. + + Ideally, we would like to describe the workflow of experiments and simulations of atom probe and + field-evaporation simulation research in more detail and contextualize better descriptions of + experiments and computer simulations. + + The main motivation for this is the ongoing development and tighter becoming connection between atom probe + and other material characterization techniques like electron microscopy as it is documented in the literature in practice + by `T. Kelly et al. `_, `C. Fleischmann et al. `_, + and theory by `W. Windl et al. `_ or `C. Freysoldt et al. https://doi.org/10.1103/PhysRevLett.124.176801>`_ + to mention but a few. To arrive at a design of base classes and an application definition which can be used + for both real and simulated atom probe experiments it is worthwhile to recall first several different concepts + that are related to events and (molecular) ions. The reason is that it is current research practice within that research field + that exploratory research workflows focus on obtaining material-structure-material-property correlations: + + * Pulsing events which are used to trigger ion extraction events. + * Physical events and corresponding signal triggered by an ion hitting the detector. + These events are not necessarily caused directly correlated with an identifiable pulsing event. + * Processed ion hits which are the result of an algorithm that took the physical and pulsing events as input + and qualifies some of these events as to be of sufficiently high quality to substantiate that they + indicate that a (molecular) ion is wortwhile to be considered further and eventually included in the reconstructed volume. + * Calibration and signal filtering steps applied to these processed ion hits as input which results in actually + selected (molecular) ions based on which an instance of a reconstruction is created. + * Correlation of these ions with a statistics and theoretical model of mass-to-charge-state ratio values + and charge states of these to substantiate that some of these ions are can be considered as rangable + and thus an iontype can be associated by running again peak finding algorithms and labeling i.e. ranging + algorithms. + + Not only in AMETEK/Cameca's IVAS/APSuite software, which the majority of atom probers use, these concepts are + well distinguished. However, the algorithms used to transform correlations between pulses and physical events into + actual events i.e. detector hits ions is a proprietary one. Due to this practical inaccessibility of details, + virtually all atom probe studies currently use a reporting scheme where the course of the specimen evaporation + is documented where quantities are a function of evaporation identifier i.e. actual event/ion, i.e. after having the + hits finding algorithm and correlations applied. That is the evaporation_identifier take the role of an implicit + time and course of the experiment. + + There is a number of groups who build own instruments and share different aspects of their technical specifications + and approaches they use for data processing. Despite some of these activities have embraced open source practices + and reporting schemes, they all use essentially the same workflow that has been proposed by AMETEK/Cameca and its + forerunner company Imago which is graphical user interface based analysis of atom probe data. Specifically, + software is used to correlate and interpret pulsing and physical events into processed ion hits. Some of these + after having calibrations and corrections applied are reported as (molecular) ions with ranged iontypes to yield a dataset + based on which scientific conclusions about the characterized material volume can be made. + + By contrast, simulations of field-evaporation have the luxury to document the flight path and allow following the + whereabouts of each ion evaporated if needed. This level of detail is currently not characterizable in experiment + and thus there is an artificial divide between schemas describing simulations of atom probe vs measurements of atom probe. + We argue that this divide can be bridged with realizing the above-mentioned context and the realization that similar concepts + are used in both worlds with many not only being similar but exactly the same. + + A further argument to support this view is that computer simulations of atom probe usually are compared to reconstructed + datasets, either to the input configuration that served as the virtual specimen or to a real world atom probe experiment and its + reconstructions. In both cases, the recorded simulated physical events of simulated ions hitting a simulated detector + is not the end of the research workflow but typically just the input to apply addition algorithms such as (spatial) filtering + and reconstruction algorithms. Only the practical need for making ranging definitions is (at least as of now) not as much needed + in field-evaporation simulations than it is in real world measurements because each ion has a prescribed iontype in the simulation. + Be it a specifically charged nuclid or a molecular ion whose flight path the simulation resolves. + However, the simpler ranging of simulations is we have to consider that this is only because currently many of the + indeed multi-scale (time and space) aspects of the challenge that is the simulating of field-evaporation are simplified + because of demand in computing resources or knowledge gaps in how to deal with these complexities. Molecular ion dissociation + upon flight is one such. Also the complexity of simulation setups is simpler such as assuming a straight flight path, ignoring details + such as local electrodes or physical obstacles and electric fields (controlled or stray fields) which however do have an effect + on an ion's flight path in a measurement. + + To conclude, we thus propose two base classes :ref:`NXapm_msr` and :ref:`NXapm_sim` where the second + one may in the future turn out to become obsolete as people realize that a simulated atom probe is maybe + equivalent in design and function to a real atom probe that is just imagined to be stripped of many components. +# noteworthy the situation is similar to electron microscopy especially transmission electron microscopy where factually +# interpretation without simulations is pointless. The only difference is that in electron microscopy there is a large availability +# of documentation and open-source tools for performing such simulations. +type: group +NXapm_msr(NXobject): # when evolving these ideas further inherit from NXapm_method instead + instrument(NXinstrument): + doc: | + Metadata of the atom probe or field-ion microscope instrument, henceforth called + microscope or instrument, and the lab in which it stands. + (NXcsg): + doc: | + Possibility to include a detailed computational geometry description of the instrument. + instrument_name(NX_CHAR): + doc: | + Given name of the microscope as defined by the hosting lab. This is an alias. + Examples could be LEAP6000, Raptor, Oxcart, one atom at a time, etc. + location(NX_CHAR): + doc: | + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + (NXfabrication): + (NXreflectron): + # decelerate_electrode(NXlens_em): + # counter_electrodes being optional WO2016171675A1 + # see https://en.wikipedia.org/wiki/Einzel_lens for details double einzel lens in the invizo 6000 + # according to A. Breen (UNSW) + local_electrode(NXlens_em): + doc: | + A local electrode guiding the ion flight path. + Also called counter or extraction electrode. + # 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. + pulser(NXpulser_apm): + stage_lab(NXstage_lab): + # 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): + buffer_chamber(NXchamber): + load_lock_chamber(NXchamber): + getter_pump(NXpump): + roughening_pump(NXpump): + turbomolecular_pump(NXpump): + status(NX_CHAR): + doc: | + A statement whether the measurement was successful or failed prematurely. + enumeration: [success, failure, unknown] + (NXevent_data_apm_set): +# (NXevent_data_apm): diff --git a/contributed_definitions/nyaml/refactor/NXapm_sim.yaml b/contributed_definitions/nyaml/refactor/NXapm_sim.yaml new file mode 100644 index 0000000000..37df8ce2ac --- /dev/null +++ b/contributed_definitions/nyaml/refactor/NXapm_sim.yaml @@ -0,0 +1,17 @@ +category: base +doc: | + Base class for simulating ion extraction from matter via laser and/or voltage pulsing. + + Ideally, we would like to describe the workflow of experiments and simulations of atom probe and + field-evaporation simulation research in more detail and contextualize better descriptions of + experiments and computer simulations. The strategy is detailed in the introducing docstring + of :ref:`NXapm_msr`. This base class is envisioned as the twin of the :ref:`NXapm_msr` base class. +# noteworthy the situation is similar to electron microscopy especially transmission electron microscopy where factually +# interpretation without simulations is pointless. The only difference is that in electron microscopy there is a large availability +# of documentation and open-source tools for performing such simulations. +type: group +NXapm_sim(NXobject): # when evolving these ideas further inherit from NXapm_method instead + doc: | + Details about the simulation. + # sequence_index(N): + (NXprogram): diff --git a/contributed_definitions/nyaml/refactor/NXpulser_apm.yaml b/contributed_definitions/nyaml/refactor/NXpulser_apm.yaml index 52de0fb26b..50d57447ab 100644 --- a/contributed_definitions/nyaml/refactor/NXpulser_apm.yaml +++ b/contributed_definitions/nyaml/refactor/NXpulser_apm.yaml @@ -5,16 +5,13 @@ symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. n_events: | - Total number of events along a time trajectory. - Interpretation depends on details of the specific field. - n_ions: | - Total number of ions collected. + Total number of events along a time trajectory, not necessarily the same as ions. type: group NXpulser_apm(NXobject): (NXfabrication): - pulse_mode: + pulse_mode(NX_CHAR): doc: | - How is field evaporation physically triggered. + Detail whereby ion extraction is trigger methodologically. enumeration: [laser, voltage, laser_and_voltage] pulse_frequency(NX_FLOAT): doc: | @@ -41,19 +38,19 @@ NXpulser_apm(NXobject): In laser pulsing mode the values will be zero so the this field is recommended. However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. unit: NX_VOLTAGE - dim: (n_ions,) + dim: (n_events,) pulse_number(NX_UINT): unit: NX_UNITLESS doc: | Absolute number of pulses starting from the beginning of the experiment. - dim: (n_ions,) + dim: (n_events,) standing_voltage(NX_FLOAT): doc: | Direct current voltage between the specimen and the (local electrode) in the case of local electrode atom probe (LEAP) instrument. Otherwise, the standing voltage applied to the sample, relative to system ground. unit: NX_VOLTAGE - dim: (n_ions,) + dim: (n_events,) (NXsource): doc: | Atom probe microscopes use controlled laser, voltage, or a combination of pulsing strategies diff --git a/contributed_definitions/nyaml/refactor/Nxapm_new.yaml b/contributed_definitions/nyaml/refactor/Nxapm_new.yaml new file mode 100644 index 0000000000..0b4163993a --- /dev/null +++ b/contributed_definitions/nyaml/refactor/Nxapm_new.yaml @@ -0,0 +1,388 @@ +category: application +doc: | + Application definition for atom probe and field ion microscopy experiments. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXapm(NXapm_base): + (NXentry): + exists: [min, 1, max, unbounded] + \@version(NX_CHAR): + doc: | + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + definition(NX_CHAR): + enumeration: [NXapm] + profiling(NXcs_profiling): + doc: | + The configuration of the I/O writer software (e.g. `pynxtools `_) + which was used to generate this NeXus file instance. + command_line_call(NX_CHAR): + (NXprogram): # understood by default as PROGRAM(NXprogram), i.e. program1, program2, ... + doc: | + A collection of all programs and libraries which are considered relevant + to understand with which software tools this NeXus file instance was + generated. Ideally, to enable a binary recreation from the input data. + + Examples include the name and version of the libraries used to write the + instance. Ideally, the software which writes these NXprogram instances + also includes the version of the set of NeXus classes i.e. the specific + set of base classes, application definitions, and contributed definitions + with which the here described concepts can be resolved. + + For the `pynxtools library `_ + which is used by the `NOMAD `_ + research data management system, it makes sense to store e.g. the GitHub + repository commit and respective submodule references used. + exists: [min, 0, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + # \@url: + experiment_identifier(NXidentifier): + exists: recommended + service(NX_CHAR): + identifier(NX_CHAR): + is_persistent(NX_BOOLEAN): + run_number(NX_CHAR): # alias experiment_alias + # experiment_description(NX_CHAR): + # if NXapm inherits from NXapm_base having this optional field does not need to be + # mentioned because optional nodes can always be added to a NeXus file instance without + # making it thereby non-compliant to the application definition + # the only difference is that if the consuming application wishes to demand to find that field + # it has to be specified in the appdef for the appdef to be a useful document of the contract + # which pieces of information a software expects to find and which not + # if you think about you being the consuming human (agent) also you would like to know + # if there is a run_number for the atom probe measurement from your colleague i.e. you + # effectively ask your colleague for that information while working off your imagined list of requirements + # the appdef definition here is nothing else then document this for a software + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + exists: recommended + (NXcite): + exists: [min, 0, max, infty] + (NXserialized): + exists: [min, 0, max, infty] + operation_mode(NX_CHAR): + (NXuser): + exists: recommended + name(NX_CHAR): + identifier(NXidentifier): + exists: recommended + service(NX_CHAR): + identifier(NX_CHAR): + is_persistent(NX_BOOLEAN): + sample(NXsample): + exists: optional + # move this doc string to NXapm_base + 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. + + For computer simulations of atom probe one usually works with + specific input configurations which are defined via specific positions + of specific nuclids. In this case identifier can be used to add a reference + to a sample whereby the input configuration was inspired or motivated. + # end of the move + method(NX_CHAR): + identifier(NXidentifier): + exists: optional + service(NX_CHAR): + identifier(NX_CHAR): + is_persistent(NX_BOOLEAN): + specimen(NXsample): + exists: optional + identifier(NXidentifier): + exists: recommended + service(NX_CHAR): + identifier(NX_CHAR): + is_persistent(NX_BOOLEAN): + parent_identifier(NXidentifier): + exists: recommended + service(NX_CHAR): + identifier(NX_CHAR): + is_persistent(NX_BOOLEAN): + preparation_date(NX_DATE_TIME): + name(NX_CHAR): + exists: recommended + atom_types(NX_CHAR): + # describing the geometry of the sample + (NXcoordinate_system_set): + exists: [min, 1, max, 1] + (NXcoordinate_system): + exists: [min, 1, max, infty] + origin(NX_CHAR): + alias(NX_CHAR): + type(NX_CHAR): + handedness(NX_CHAR): + x_direction(NX_CHAR): + y_direction(NX_CHAR): + z_direction(NX_CHAR): + + measurement(NXapm_msr): + exists: optional + simulation(NXapm_sim): + exists: optional + atom_probe(NXroi): + exists: [min, 0, max, infty] + doc: | + A region-of-interest analyzed either during or after the session. + For which specific processed data of the measured or simulated + data are available. + # add a default plot V = f(time/evaporation_id), essentially for each quantity + # NEW ISSUE: check also here the PYCCAPT pipeline from P. Felfer's group + # all other details are instances of NXprocess as steps along the pipeline + + # NEW ISSUE: hit_quality table + # NEW ISSUE: pyccapt + # NEW ISSUE: add section for propagation_delay(NXprocess) ? + # NEW ISSUE: make recon an own subentry NXapm_reconstruction + # NEW ISSUE: different algorithms used one could create a class for each reconstruction method + # NEW ISSUE: make this rather an own subentry NXapm_ranging + + hit_finding(NXprocess): + exists: optional + sequence_index(NX_POSINT): + exists: recommended + (NXprogram): + exists: [min, 1, max, unbounded] + program(NX_CHAR): + \@version(NX_CHAR): + # config of the hit_finding algorithm + (NXserialized): + exists: recommended + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + number_of_dld_wires(NX_UINT): + arrival_time_pairs(NX_NUMBER): + # results of the hit_finding algorithm + hit_positions(NX_NUMBER): + dim: (i, 2) + hit_quality(NX_UINT): + exists: optional + dim: (i,) + pulses_since_last_ion(NX_UINT): + exists: optional + dim: (i,) + pulse_identifier_offset(NX_INT): + exists: optional + pulse_identifier(NX_INT): + exists: optional + dim: (i,) + hit_multiplicity(NX_UINT): + dim: (i,) + # i number of hits after hits finding but prior calibrations + + hit_spatial_filtering(NXprocess): + exists: optional + sequence_index(NX_POSINT): + exists: recommended + (NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + (NXserialized): + exists: optional + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + hit_filter(NXcs_filter_boolean_mask): # use NXcs_filterneeds conditionally an instance of concept ../../hit_finding + number_of_objects(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + identifier(NX_INT): + + voltage_and_bowl_correction(NXprocess): + exists: optional + sequence_index(NX_POSINT): + exists: recommended + (NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + (NXserialized): + exists: optional + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + # config/input to the algorithm + # 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): + dim: (n_ions,) + # result + calibrated_tof(NX_FLOAT): + dim: (n_ions,) + + mass_to_charge_conversion(NXprocess): + exists: recommended + sequence_index(NX_POSINT): + exists: recommended + (NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + (NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + mass_to_charge(NX_FLOAT): + dim: (n_ions,) + + reconstruction(NXprocess): + exists: recommended + sequence_index(NX_POSINT): + exists: recommended + (NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + # config/input + protocol_name(NX_CHAR): + doc: | + Qualitative statement about which reconstruction protocol was used. + enumeration: [bas, geiser, gault, cameca, other] + crystallographic_calibration(NX_CHAR): + reconstructed_positions(NX_FLOAT): + dim: (n_ions, 3) + naive_discretization(NXprocess): + sequence_index(NX_POSINT): + exists: recommended + (NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + # config/input + # results + (NXdata): + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_CHAR): + dim: (i,) + # \@long_name: + title(NX_CHAR): + intensity(NX_NUMBER): + dim: (n_z, n_y, n_x) + axis_z(NX_FLOAT): + dim: (n_z,) + \@long_name(NX_CHAR): + axis_y(NX_FLOAT): + dim: (n_y,) + \@long_name(NX_CHAR): + axis_x(NX_FLOAT): + dim: (n_x,) + \@long_name(NX_CHAR): + + ranging(NXprocess): + exists: recommended + sequence_index(NX_POSINT): + exists: recommended + (NXprogram): + exists: [min, 1, max, infty] + program: + \@version: + number_of_ion_types(NX_UINT): + maximum_number_of_atoms_per_molecular_ion(NX_UINT): + + 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. + sequence_index(NX_POSINT): + exists: recommended + (NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + min_incr_max(NX_FLOAT): + dim: (3,) # u + mass_spectrum(NXdata): + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME_indices(NX_CHAR): + # \@long_name(NX_CHAR): + title(NX_CHAR): + intensity(NX_NUMBER): + dim: (n_bins,) + \@long_name(NX_CHAR): + axis_mass_to_charge(NX_FLOAT): + dim: (n_bins,) + \@long_name(NX_CHAR): + + background_quantification(NXprocess): + exists: recommended + sequence_index(NX_POSINT): + exists: recommended + (NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + # config/input + # results + # NEW ISSUE: add parameters of the background model in an e.g. work of A. London et al. + + peak_search(NXprocess): + exists: recommended + sequence_index(NX_POSINT): + exists: recommended + (NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + (NXpeak): + exists: [min, 0, max, infty] + label(NX_CHAR): + exists: recommended + peak_model(NX_CHAR): + position(NX_NUMBER): + + # peak deconvolution(NXprocess): + + peak_identification(NXprocess): # aka specify ranging definitions i.e. mqmin, mqmax intervals (ranges) and (molecular) ion candidates + exists: recommended + sequence_index(NX_POSINT): + exists: recommended + (NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + (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(NX_CHAR): + exists: recommended diff --git a/contributed_definitions/nyaml/refactor/find_a_place_in_nxapm.txt b/contributed_definitions/nyaml/refactor/find_a_place_in_nxapm.txt new file mode 100644 index 0000000000..946e12ec55 --- /dev/null +++ b/contributed_definitions/nyaml/refactor/find_a_place_in_nxapm.txt @@ -0,0 +1,643 @@ + # https://fairmat-experimental.github.io/nexus-fairmat-proposal/ + # 50433d9039b3f33299bab338998acb5335cd8951/classes/ + + + 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 + + + + + # 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 + + # NEW ISSUE: check also here the PYCCAPT pipeline from P. Felfer's group + ion_impact_positions(NXprocess): + 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', 'unbounded'] + program: + \@version: + + # NEW ISSUE: discuss with Oxcart developers which + # modifications might be necessary here. + arrival_time_pairs(NX_NUMBER): + exists: recommended + unit: NX_TIME + doc: | + Raw readings from the analog-to-digital-converter + timing circuits of the detector wires. + dimensions: + rank: 3 + dim: [[1, n_ions], [2, n_dld_wires], [3, 2]] + hit_positions(NX_NUMBER): + unit: NX_LENGTH + 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. + 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 + + # NEW ISSUE: use symbols to monitor number of pulses + hit_multiplicity(NXprocess): + 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', 'unbounded'] + program: + \@version: + pulses_since_last_ion(NX_UINT): + exists: recommended + unit: NX_UNITLESS + 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]] + + # 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. + pulse_id(NX_UINT): + exists: optional + unit: NX_UNITLESS + doc: | + Number of pulses since the start of the atom probe + run/evaporation sequence. + dimensions: + rank: 1 + dim: [[1, n_ions]] + hit_multiplicity(NX_UINT): + unit: NX_UNITLESS + + # 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]] + 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', 'unbounded'] + program: + \@version: + evaporation_id_included(NX_BOOLEAN): + doc: | + Bitmask which is set to true if the ion + is considered and false otherwise. + dimensions: + rank: 1 + dim: [[1, n_ions]] + + # NEW ISSUE: add section for propagation_delay(NXprocess) ? + voltage_and_bowl_correction(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', 'unbounded'] + 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 + unit: NX_TIME + doc: | + Raw time-of-flight data as read out from the acquisition software + if these data are available and accessible. + dimensions: + rank: 1 + dim: [[1, n_ions]] + calibrated_tof(NX_FLOAT): + unit: NX_TIME + + # 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. + 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', 'unbounded'] + program: + \@version: + parameter(NXcollection): + exists: recommended + doc: | + Store vendor-specific calibration models here (if available). + mass_to_charge(NX_FLOAT): + unit: NX_ANY + doc: | + Mass-to-charge-state ratio values. + + # \@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', 'unbounded'] + 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): + unit: NX_LENGTH + doc: | + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + dimensions: + rank: 2 + dim: [[1, n_ions], [2, 3]] + visualization(NXprocess): + exists: recommended + xdmf_topology(NX_UINT): + unit: NX_UNITLESS + 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. + dimensions: + rank: 1 + dim: [[1, n_topology]] + + # n_topology == 3*n_ions + xdmf_topology(NX_UINT): + unit: NX_UNITLESS + 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. + 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', 'unbounded'] + 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): + unit: NX_UNITLESS + doc: | + Array of counts for each bin. + dimensions: + rank: 3 + dim: [[1, n_z], [2, n_y], [3, n_x]] + axis_z(NX_FLOAT): + unit: NX_LENGTH + doc: | + Bin center of mass position along the z axis. + dimensions: + rank: 1 + dim: [[1, n_z]] + \@long_name: + axis_y(NX_FLOAT): + unit: NX_LENGTH + doc: | + Bin center of mass position along the y axis. + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + axis_x(NX_FLOAT): + unit: NX_LENGTH + doc: | + Bin center of mass position along the x axis. + 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', 'unbounded'] + program: + \@version: + number_of_ion_types(NX_UINT): + unit: NX_UNITLESS + doc: | + How many ion types are distinguished. + If no ranging was performed each ion is of the special unknown type. + The iontype ID of this unknown type is 0 which is a reserve value. + Consequently, iontypes start counting from 1. + maximum_number_of_atoms_per_molecular_ion(NX_UINT): + unit: NX_UNITLESS + doc: | + Assumed maximum value that suffices to store all relevant + molecular ions, even the most complicated ones. + Currently a value of 32 is used. + 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', 'unbounded'] + program: + \@version: + range_minmax(NX_FLOAT): + unit: NX_ANY + doc: | + Smallest and largest mass-to-charge-state ratio value. + + # \@units: Da + # NEW ISSUE: NX_ATOMIC_MASS_UNIT use Tommasso scheme here Da + dimensions: + rank: 1 + dim: [[1, 2]] + range_increment(NX_FLOAT): + unit: NX_ANY + doc: | + Binning width of the mass-to-charge-state ratio values. + + # \@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): + unit: NX_UNITLESS + doc: | + Array of counts for each bin. + dimensions: + rank: 1 + dim: [[1, n_bins]] + \@long_name: + axis_mass_to_charge(NX_FLOAT): + unit: NX_ANY + doc: | + Right boundary of each mass-to-charge-state ratio value bin. + + # \@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', 'unbounded'] + 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', 'unbounded'] + program: + \@version: + (NXpeak): + exists: ['min', '0', 'max', 'unbounded'] + 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', 'unbounded'] + 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 + + flight_path_geometry(NX_CHAR): + doc: | + Qualitative descriptor to distinguish flight_path geometries. + enumeration: [straight, curved] + 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. + unit: NX_LENGTH # mm + + field_of_view(NX_FLOAT): # property of the reconstruction! + 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 + + + + # 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 \ No newline at end of file From 4ec983c275a2acf54e0c0f9d2dd29dc4879a1fd9 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 5 Jan 2024 12:40:20 +0100 Subject: [PATCH 0417/1012] Use NX_FLOAT in NXresolution/resolution, introduce resolution_error --- .../NXelectronanalyser.nxdl.xml | 56 +++++++++++++++---- contributed_definitions/NXmpes.nxdl.xml | 25 ++++----- contributed_definitions/NXresolution.nxdl.xml | 15 +++-- .../nyaml/NXelectronanalyser.yaml | 22 +++++--- contributed_definitions/nyaml/NXmpes.yaml | 6 +- .../nyaml/NXresolution.yaml | 4 ++ 6 files changed, 87 insertions(+), 41 deletions(-) diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml index e82e3086b4..ef4d0c2170 100644 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -86,26 +86,48 @@ accurately determine the binding energy scale. - + - Energy resolution of the electron analyser (FWHM of gaussian broadening). + Energy resolution of the analyser with the current setting. May be linked from a + NXcalibration. - This concept is related to term `10.7`_ of the 18115-1:2023 standard. + This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. - .. _10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 + .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 - - + + + + + + + + + Momentum resolution of the electron analyser (FWHM) - - + + + + + + + + + Angular resolution of the electron analyser (FWHM) - - + + + + + + + + + Spatial resolution of the electron analyser (Airy disk radius) @@ -113,7 +135,14 @@ .. _10.15 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.15 - + + + + + + + + List of the axes that are acquired simultaneously by the detector. @@ -238,4 +267,9 @@ + + + Any other resolution not explictily named in this base class. + + diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index f66bbef70b..372ee1db97 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -116,11 +116,13 @@ .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 - + + + + + - - - + @@ -225,16 +227,11 @@ This would also be helpful for NXtransformations--> - - - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. - - .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 - - + + + + + diff --git a/contributed_definitions/NXresolution.nxdl.xml b/contributed_definitions/NXresolution.nxdl.xml index 70eac45a43..94a1db9c38 100644 --- a/contributed_definitions/NXresolution.nxdl.xml +++ b/contributed_definitions/NXresolution.nxdl.xml @@ -1,10 +1,10 @@ - + -# -# Parameters for controlling external conditions +# +# +# Parameters for controlling external conditions +# # -# Apparatus identification code/model number; e.g. OC100 011 +# +# Apparatus identification code/model number; e.g. OC100 011 +# # # -# Alternative short name, perhaps for dashboard display like a present Seblock name +# +# Alternative short name, perhaps for dashboard display like a present Seblock +# name +# # # -# Type of apparatus. This could be the SE codes in scheduling database; e.g. OC/100 +# +# Type of apparatus. This could be the SE codes in scheduling database; e.g. +# OC/100 +# # # -# Description of the apparatus; e.g. 100mm bore orange cryostat with Roots pump +# +# Description of the apparatus; e.g. 100mm bore orange cryostat with Roots pump +# # # -# Program controlling the apparatus; e.g. LabView VI name +# +# Program controlling the apparatus; e.g. LabView VI name +# # # # @@ -96,25 +108,26 @@ NXenvironment(NXobject): # # # -# 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. # # # # -# 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. # # # -# Additional information, LabView logs, digital photographs, etc +# +# Additional information, LabView logs, digital photographs, etc +# # # # -# From 1b06f56b10df6bb26e31efe48495313cc539c1fc Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 5 Jan 2024 14:15:12 +0100 Subject: [PATCH 0421/1012] change starting data in NXenvironment --- base_classes/NXenvironment.nxdl.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/base_classes/NXenvironment.nxdl.xml b/base_classes/NXenvironment.nxdl.xml index 42017ad26c..9c3e58071d 100644 --- a/base_classes/NXenvironment.nxdl.xml +++ b/base_classes/NXenvironment.nxdl.xml @@ -3,7 +3,7 @@ + - 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. + A source used to generate a beam. Properties refer strictly to parameters of the + source, not of the output beam. For example, the energy of the source is not the + optical power of the beam, but the energy of the electron beam in a synchrotron + and so on. @@ -160,18 +160,7 @@ Comment from mpes may workshop: - - - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - - - - - - - - + diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index e57adeff83..36a2f493a6 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -98,11 +98,12 @@ NXmpes(NXobject): # Comment from mpes may workshop: # - There is much more information which can be provided for NXsource + exists: recommended doc: | - 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. + A source used to generate a beam. Properties refer strictly to parameters of the + source, not of the output beam. For example, the energy of the source is not the + optical power of the beam, but the energy of the electron beam in a synchrotron + and so on. type: enumeration: [Synchrotron X-ray Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, UV Plasma Source, Metal Jet X-ray, HHG laser, UV lamp, Monochromatized electron source, other] type_other: @@ -113,10 +114,6 @@ NXmpes(NXobject): exists: recommended probe: exists: optional - doc: | - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - enumeration: [photon, x-ray, visible light, ultraviolet] device_information(NXfabrication): exists: recommended vendor: From 142df503c28ca92b0047245703a62eb91ba1b75c Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 5 Jan 2024 15:41:05 +0100 Subject: [PATCH 0424/1012] removed unneeded fields in NXactuator --- contributed_definitions/NXactuator.nxdl.xml | 48 +------------------ contributed_definitions/nyaml/NXactuator.yaml | 41 +--------------- 2 files changed, 3 insertions(+), 86 deletions(-) diff --git a/contributed_definitions/NXactuator.nxdl.xml b/contributed_definitions/NXactuator.nxdl.xml index d87e93e0bc..cc3043e4f2 100644 --- a/contributed_definitions/NXactuator.nxdl.xml +++ b/contributed_definitions/NXactuator.nxdl.xml @@ -79,64 +79,17 @@ - - - Nominal/average first derivative of setpoint - e.g. strain rate - - same dimensions as "setpoint" (may be a vector) - - - - - - - - Nominal/average second derivative of setpoint - - same dimensions as "setpoint" (may be a vector) - - - - - Time history of actuator setpoints. - - - Time history of first derivative of actuator setpoints. - - - - - Time history of second derivative of actuator setpoints. - - If the actuator is PID-controlled, the settings of the PID controller can be stored here. - - - This group describes the shape of the actuator when necessary. - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - NeXus positions components by applying a set of translations and rotations @@ -158,4 +111,5 @@ other component groups. + diff --git a/contributed_definitions/nyaml/NXactuator.yaml b/contributed_definitions/nyaml/NXactuator.yaml index edb93bc3ee..3008633d27 100644 --- a/contributed_definitions/nyaml/NXactuator.yaml +++ b/contributed_definitions/nyaml/NXactuator.yaml @@ -43,50 +43,12 @@ NXactuator(NXobject): Can be a scalar or a vector (of [n] actuations). dimensions: dim: [[1, n]] - setpoint_deriv1(NX_FLOAT): - doc: | - Nominal/average first derivative of setpoint - e.g. strain rate - - same dimensions as "setpoint" (may be a vector) - dimensions: - dim: [[1, ]] - dim_parameters: - ref: ['setpoint'] - setpoint_deriv2(NX_FLOAT): - doc: | - Nominal/average second derivative of setpoint - - same dimensions as "setpoint" (may be a vector) - dimensions: - dim: [[1, ]] - dim_parameters: - ref: ['setpoint'] setpoint_log(NXlog): doc: | Time history of actuator setpoints. - setpoint_deriv1_log(NXlog): - doc: | - Time history of first derivative of actuator setpoints. - setpoint_deriv2_log(NXlog): - doc: | - Time history of second derivative of actuator setpoints. (NXpid): doc: | If the actuator is PID-controlled, the settings of the PID controller can be stored here. - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the actuator when necessary. - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. depends_on(NX_CHAR): doc: | NeXus positions components by applying a set of translations and rotations @@ -103,4 +65,5 @@ NXactuator(NXobject): This is the group recommended for holding the chain of translation and rotation operations necessary to position the component within the instrument. The dependency chain may however traverse similar groups in - other component groups. \ No newline at end of file + other component groups. + (NXfabrication): \ No newline at end of file From 77eb4c902e5e81b90dd651358c2584d29f6f5eca Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 5 Jan 2024 16:13:43 +0100 Subject: [PATCH 0425/1012] fix typos, copy-paste errors and accidental deletions --- .../NXmanipulator.nxdl.xml | 34 ++++++++++--------- contributed_definitions/NXmpes.nxdl.xml | 21 ++++++++---- .../nyaml/NXmanipulator.yaml | 32 +++++++++-------- contributed_definitions/nyaml/NXmpes.yaml | 27 +++++++++++---- 4 files changed, 71 insertions(+), 43 deletions(-) diff --git a/contributed_definitions/NXmanipulator.nxdl.xml b/contributed_definitions/NXmanipulator.nxdl.xml index c605198bf2..8e26aacd49 100644 --- a/contributed_definitions/NXmanipulator.nxdl.xml +++ b/contributed_definitions/NXmanipulator.nxdl.xml @@ -52,7 +52,7 @@ - In the case of a fixed cooling temperature, this is the scalar temperature setpoint. + In case of a fixed or averaged cooling temperature, this is the scalar temperature setpoint. It can also be a 1D array of temperature setpoints (without time stamps). @@ -76,7 +76,7 @@ - In the case of a fixed temperature measurement, this is the scalar temperature measured + In case of a single or averaged temperature measurement, this is the scalar temperature measured by the sample temperature sensor. It can also be a 1D array of measured temperatures (without time stamps). @@ -101,7 +101,7 @@ - In the case of a fixed temperature measurement, this is the scalar temperature setpoint. + In case of a fixed or averaged temperature, this is the scalar temperature setpoint. It can also be a 1D array of temperature setpoints (without time stamps). @@ -123,14 +123,14 @@ - + - In the case of a fixed drain current measurement, this is the scalar drain current measured between + In case of a single or averaged drain current measurement, this is the scalar drain current measured between the sample and sample holder. It can also be an 1D array of measured currents (without time stamps). - + In the case of an experiment in which the current changes and is recorded with time stamps, this is an array of length m of currents. @@ -138,23 +138,23 @@ - + - Acutator applying a voltage between sample and sample holder. + Acutator applying a voltage to sample and sample holder. - + - + - In the case of a fixed applied bias, this is the scalar voltage applied between + In case of a fixed or averaged applied bias, this is the scalar voltage applied between sample and sample holder. It can also be an 1D array of voltage setpoints (without time stamps). - + In the case of an experiment in which the bias is changed and the setpoints are recorded with time stamps, this is an array of length m of voltage setpoints. @@ -171,14 +171,14 @@ - + - In the case of a fixed applied bias, this is the scalar voltage measured between + In case of a single or averaged bias measurement, this is the scalar voltage measured between sample and sample holder. It can also be an 1D array of measured voltages (without time stamps). - + In the case of an experiment in which the bias changes and is recorded with time stamps, this is an array of length m of voltages. @@ -188,7 +188,8 @@ - Any additional sensors on the manipulator used to control an external condition. + Any additional actuator on the manipulator used to control an external + condition. @@ -219,4 +220,5 @@ the reference coordinate system. + diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index b2a3e4a2b3..b33fe57d10 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -378,7 +378,7 @@ Optional constant settings (like lens focusing parameters on the sample: positio - + @@ -406,6 +406,11 @@ Optional constant settings (like lens focusing parameters on the sample: positio + + + + + @@ -420,7 +425,7 @@ Optional constant settings (like lens focusing parameters on the sample: positio - In the case of a fixed gas pressure measurement, this is the scalar gas pressure around + In case of a single or averaged gas pressure measurement, this is the scalar gas pressure around the sample. It can also be an 1D array of measured pressures (without time stamps). @@ -444,14 +449,14 @@ Optional constant settings (like lens focusing parameters on the sample: positio - + - In the case of a fixed electron current, this is the scalar current setpoint. + In case of a fixed or averaged electron current, this is the scalar current setpoint. It can also be an 1D array of measured current setpoints (without time stamps). - + In the case of an experiment in which the gas pressure is changed and the setpoints are recorded with time stamps, this is an array of length m of current setpoints. @@ -669,7 +674,11 @@ Optional constant settings (like lens focusing parameters on the sample: positio - Voltage applied to sample and sample holder. + Bias of the sample with respect to analyser ground. + + This concept is related to term `8.41`_ of the ISO 18115-1:2023 standard. + + .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 diff --git a/contributed_definitions/nyaml/NXmanipulator.yaml b/contributed_definitions/nyaml/NXmanipulator.yaml index b90067313c..7aacb8debf 100644 --- a/contributed_definitions/nyaml/NXmanipulator.yaml +++ b/contributed_definitions/nyaml/NXmanipulator.yaml @@ -21,7 +21,7 @@ NXmanipulator(NXobject): setpoint(NX_FLOAT): unit: NX_TEMPERATURE doc: | - In the case of a fixed cooling temperature, this is the scalar temperature setpoint. + In case of a fixed or averaged cooling temperature, this is the scalar temperature setpoint. It can also be a 1D array of temperature setpoints (without time stamps). setpoint_log(NXlog): value(NX_NUMBER): @@ -36,7 +36,7 @@ NXmanipulator(NXobject): value(NX_FLOAT): unit: NX_TEMPERATURE doc: | - In the case of a fixed temperature measurement, this is the scalar temperature measured + In case of a single or averaged temperature measurement, this is the scalar temperature measured by the sample temperature sensor. It can also be a 1D array of measured temperatures (without time stamps). value_log(NXlog): @@ -52,7 +52,7 @@ NXmanipulator(NXobject): setpoint(NX_FLOAT): unit: NX_TEMPERATURE doc: | - In the case of a fixed temperature measurement, this is the scalar temperature setpoint. + In case of a fixed or averaged temperature, this is the scalar temperature setpoint. It can also be a 1D array of temperature setpoints (without time stamps). setpoint_log(NXlog): value(NX_NUMBER): @@ -65,51 +65,54 @@ NXmanipulator(NXobject): measurement: enumeration: [current] value(NX_FLOAT): - unit: NX_TEMPERATURE + unit: NX_CURRENT doc: | - In the case of a fixed drain current measurement, this is the scalar drain current measured between + In case of a single or averaged drain current measurement, this is the scalar drain current measured between the sample and sample holder. It can also be an 1D array of measured currents (without time stamps). value_log(NXlog): value(NX_NUMBER): doc: | In the case of an experiment in which the current changes and is recorded with time stamps, this is an array of length m of currents. - sample_bias_potentiostat(NXsensor): + unit: NX_CURRENT + sample_bias_potentiostat(NXactuator): doc: | - Acutator applying a voltage between sample and sample holder. - measurement: + Acutator applying a voltage to sample and sample holder. + actuation: enumeration: [voltage] setpoint(NX_FLOAT): - unit: NX_TEMPERATURE + unit: NX_VOLTAGE doc: | - In the case of a fixed applied bias, this is the scalar voltage applied between + In case of a fixed or averaged applied bias, this is the scalar voltage applied between sample and sample holder. It can also be an 1D array of voltage setpoints (without time stamps). setpoints_log(NXlog): value(NX_NUMBER): doc: | In the case of an experiment in which the bias is changed and the setpoints are recorded with time stamps, this is an array of length m of voltage setpoints. + unit: NX_VOLTAGE sample_bias_voltmeter(NXsensor): doc: | Sensor measuring the voltage applied to sample and sample holder. measurement: enumeration: [voltage] value(NX_FLOAT): - unit: NX_TEMPERATURE + unit: NX_VOLTAGE doc: | - In the case of a fixed applied bias, this is the scalar voltage measured between + In case of a single or averaged bias measurement, this is the scalar voltage measured between sample and sample holder. It can also be an 1D array of measured voltages (without time stamps). value_log(NXlog): value(NX_NUMBER): doc: | In the case of an experiment in which the bias changes and is recorded with time stamps, this is an array of length m of voltages. + unit: NX_VOLTAGE (NXactuator): doc: | - Any additional sensors on the manipulator used to control an external condition. + Any additional actuator on the manipulator used to control an external condition. (NXsensor): doc: | - Any additional sensors on the manipulator used to monitor an external condition. + Any additional sensors on the manipulator used to monitor an external condition. (NXpositioner): doc: | Class to describe the motors that are used in the manipulator @@ -127,6 +130,7 @@ NXmanipulator(NXobject): 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. + (NXfabrication): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ # 11c191146cd0a327bb603dc2607bfbf4ca12cb629b09821510dbaccc6dde01de diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 745f143960..e5d66da96f 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -304,7 +304,7 @@ NXmpes(NXobject): exists: recommended name: exists: recommended - acutation: + actuation: enumeration: [temperature] type: exists: optional @@ -330,6 +330,13 @@ NXmpes(NXobject): exists: optional value(NX_FLOAT): exists: recommended + device_information(NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: pressure_gauge(NXsensor): exists: recommended doc: | @@ -344,7 +351,7 @@ NXmpes(NXobject): exists: recommended unit: NX_PRESSURE doc: | - In the case of a fixed gas pressure measurement, this is the scalar gas pressure around + In case of a single or averaged gas pressure measurement, this is the scalar gas pressure around the sample. It can also be an 1D array of measured pressures (without time stamps). value_log(NXlog): exists: optional @@ -364,9 +371,9 @@ NXmpes(NXobject): exists: optional setpoint(NX_FLOAT): exists: recommended - unit: NX_PRESSURE + unit: NX_CURRENT doc: | - In the case of a fixed electron current, this is the scalar current setpoint. + In case of a fixed or averaged electron current, this is the scalar current setpoint. It can also be an 1D array of measured current setpoints (without time stamps). setpoint_log(NXlog): exists: optional @@ -374,7 +381,7 @@ NXmpes(NXobject): doc: | In the case of an experiment in which the gas pressure is changed and the setpoints are recorded with time stamps, this is an array of length m of current setpoints. - unit: NX_PRESSURE + unit: NX_CURRENT (NXprocess): exists: recommended doc: | @@ -549,8 +556,14 @@ NXmpes(NXobject): This should be a link to /entry/instrument/pressure_gauge. bias(NXenvironment): exists: recommended - doc: | - Voltage applied to sample and sample holder. + doc: + - | + Bias of the sample with respect to analyser ground. + - | + xref: + spec: ISO 18115-1:2023 + term: 8.41 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 voltmeter(NXsensor): doc: | Sensor setting/measuring the applied voltage. From 55a8d3e41005820b3089977f0e2e23ec637abc18 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 5 Jan 2024 16:20:10 +0100 Subject: [PATCH 0426/1012] address review comments --- contributed_definitions/NXelectronanalyser.nxdl.xml | 2 +- contributed_definitions/NXmpes.nxdl.xml | 10 +++++++--- contributed_definitions/nyaml/NXelectronanalyser.yaml | 2 +- contributed_definitions/nyaml/NXmpes.yaml | 3 +++ 4 files changed, 12 insertions(+), 5 deletions(-) diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml index ef4d0c2170..90c848e1dd 100644 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -88,7 +88,7 @@ - Energy resolution of the analyser with the current setting. May be linked from a + Energy resolution of the analyser with the current setting. May be linked from an NXcalibration. This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 372ee1db97..6a2b02ac6d 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -121,7 +121,7 @@ - + @@ -228,8 +228,12 @@ This would also be helpful for NXtransformations--> - - + + + + + + diff --git a/contributed_definitions/nyaml/NXelectronanalyser.yaml b/contributed_definitions/nyaml/NXelectronanalyser.yaml index 38faaf8b31..a4e320a5fa 100644 --- a/contributed_definitions/nyaml/NXelectronanalyser.yaml +++ b/contributed_definitions/nyaml/NXelectronanalyser.yaml @@ -52,7 +52,7 @@ NXelectronanalyser(NXobject): energy_resolution(NXresolution): doc: - | - Energy resolution of the analyser with the current setting. May be linked from a + Energy resolution of the analyser with the current setting. May be linked from an NXcalibration. - | xref: diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 2837182c32..9c428c705d 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -84,6 +84,7 @@ NXmpes(NXobject): physical_quantity: enumeration: [energy] type: + exists: recommended resolution(NX_FLOAT): unit: NX_ENERGY device_information(NXfabrication): @@ -179,7 +180,9 @@ NXmpes(NXobject): energy_resolution(NXresolution): exists: recommended type: + exists: recommended physical_quantity: + enumeration: [energy] resolution(NX_FLOAT): fast_axes: exists: recommended From 89bfec1e97707901203f537e2ccbcd87bbb4a201 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 5 Jan 2024 16:22:15 +0100 Subject: [PATCH 0427/1012] add vacuum level to energy referencing --- contributed_definitions/NXmpes.nxdl.xml | 2 +- contributed_definitions/nyaml/NXmpes.yaml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 64df78ed6b..7420d5ef74 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -438,7 +438,7 @@ Optional constant settings (like lens focusing parameters on the sample: positio Reference peak that was used for the calibration. - For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge + For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge | vacuum level diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 36a2f493a6..91e0f44e9a 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -373,7 +373,7 @@ NXmpes(NXobject): doc: | Reference peak that was used for the calibration. - For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge + For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge | vacuum level binding_energy(NX_FLOAT): exists: recommended doc: From e9d512c1800ba9009b5a2c4ec6a9c575c211ed53 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 5 Jan 2024 16:33:03 +0100 Subject: [PATCH 0428/1012] add description of dither mode, remove transmission mode --- .../NXenergydispersion.nxdl.xml | 20 ++++++---------- .../nyaml/NXenergydispersion.yaml | 24 +++++-------------- 2 files changed, 13 insertions(+), 31 deletions(-) diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml index 700c98f224..57fb4562b2 100644 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ b/contributed_definitions/NXenergydispersion.nxdl.xml @@ -83,6 +83,7 @@ Synonyms: constant ΔE mode, constant analyser energy mode, CAE mode, FAT mode This concept is related to term `12.64`_ of the ISO 18115-1:2023 standard. + .. _12.64: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.64 @@ -98,6 +99,7 @@ Synonyms: constant ΔE/E mode, constant retardation ratio mode, CRR mode, FRR mode This concept is related to term `12.66`_ of the ISO 18115-1:2023 standard. + .. _12.66: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.66 @@ -126,20 +128,12 @@ measurements, their energy resolution is relatively lower. - + - MISSING DOC. - - This concept is related to term `<term>`_ of the <spec> standard. - .. _<term>: <url> - - - - - MISSING DOC. - - This concept is related to term `<term>`_ of the <spec> standard. - .. _<term>: <url> + In dither acquisition mode, the kinetic energy of the analyzer is randomly varied by a small value + around a central value and at fixed pass energy. This allows reducing or removing inhomogeneities + of the detector efficiency, such as e.g. imposed by a mesh in front of the detector. + Mostly relevant for CCD/DLD type of detectors. diff --git a/contributed_definitions/nyaml/NXenergydispersion.yaml b/contributed_definitions/nyaml/NXenergydispersion.yaml index 97368f62fd..51fe90fa74 100644 --- a/contributed_definitions/nyaml/NXenergydispersion.yaml +++ b/contributed_definitions/nyaml/NXenergydispersion.yaml @@ -94,24 +94,12 @@ NXenergydispersion(NXobject): particularly suitable for CCD and DLD detectors, which have multiple channels and can accurately display the peak shape. While five or nine-channel detectors can also be used for snapshot measurements, their energy resolution is relatively lower. - transmission: - doc: - - | - MISSING DOC. - - | - xref: - spec: - term: - url: - jittered: - doc: - - | - MISSING DOC. - - | - xref: - spec: - term: - url: + dither: + doc: | + In dither acquisition mode, the kinetic energy of the analyzer is randomly varied by a small value + around a central value and at fixed pass energy. This allows reducing or removing inhomogeneities + of the detector efficiency, such as e.g. imposed by a mesh in front of the detector. + Mostly relevant for CCD/DLD type of detectors. tof_distance(NX_FLOAT): unit: NX_LENGTH doc: | From 03c8ca674f5a66d2e70d630f5c32de561218bf7e Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 5 Jan 2024 17:07:50 +0100 Subject: [PATCH 0429/1012] add AXISNAME_depends to NXdata --- base_classes/NXdata.nxdl.xml | 17 +++++++++++++++++ base_classes/nyaml/NXdata.yaml | 15 +++++++++++++++ 2 files changed, 32 insertions(+) diff --git a/base_classes/NXdata.nxdl.xml b/base_classes/NXdata.nxdl.xml index 774c653253..e57fc30b7c 100644 --- a/base_classes/NXdata.nxdl.xml +++ b/base_classes/NXdata.nxdl.xml @@ -273,6 +273,23 @@ but not to describe how the data is to be plotted. (https://www.nexusformat.org/NIAC2018Minutes.html#nxdata-plottype--attribute) + + + Points to the path to a field defining the axis on which the ``AXISNAME`` axis depends. + + This concept allows to store a link to an axis to a respective field the Nexus hierarchy + + Here, *AXISNAME* is to be replaced by the name of each + field described in the ``axes`` attribute. + + Examples: + If a calibration has been performed, ``@AXISNAME_depends`` links to the result of + that calibration: + @AXISNAME_depends: '/entry/process/calibration/calibrated_axis' + If the axis is given in a detecotr, ``@AXISNAME_depends`` links to that detector axis: + @AXISNAME_depends: '/entry/instrument/detector/AXISNAME' for a 2D detector + + Dimension scale defining an axis of the data. diff --git a/base_classes/nyaml/NXdata.yaml b/base_classes/nyaml/NXdata.yaml index cc56a0676b..8e2d7cd2ed 100644 --- a/base_classes/nyaml/NXdata.yaml +++ b/base_classes/nyaml/NXdata.yaml @@ -237,6 +237,21 @@ NXdata(NXobject): .. note:: Attributes potentially containing multiple values (axes and _indices) are to be written as string or integer arrays, to avoid string parsing in reading applications. + \@AXISNAME_depends: + doc: | + Points to the path to a field defining the axis on which the ``AXISNAME`` axis depends. + + This concept allows to store a link to an axis to a respective field the Nexus hierarchy + + Here, *AXISNAME* is to be replaced by the name of each + field described in the ``axes`` attribute. + + Examples: + If a calibration has been performed, ``@AXISNAME_depends`` links to the result of + that calibration: + @AXISNAME_depends: '/entry/process/calibration/calibrated_axis' + If the axis is given in a detecotr, ``@AXISNAME_depends`` links to that detector axis: + @AXISNAME_depends: '/entry/instrument/detector/AXISNAME' for a 2D detector AXISNAME(NX_NUMBER): nameType: any doc: | From c234f174bfa7801f5390c92e8a50aff3e2b41940 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 5 Jan 2024 17:08:39 +0100 Subject: [PATCH 0430/1012] remove name quantities from NXmpes for now --- contributed_definitions/NXmpes.nxdl.xml | 41 +---------------------- contributed_definitions/nyaml/NXmpes.yaml | 41 +---------------------- 2 files changed, 2 insertions(+), 80 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 5715aa163f..769af66f4d 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -660,6 +660,7 @@ there is also x_pixel_offset in NXdetector base class + @@ -708,46 +709,6 @@ there is also x_pixel_offset in NXdetector base class - - - Calibrated x axis in k-space. - Units are 1/Angström. - - - - - Calibrated y axis in k-space. - Units are 1/Angström - - - - - Calibrated k axis in k-space. - Units are 1/Angström. - - - - - Calibrated delay time. - - - - - Linear polarization angle of the incoming or outgoing beam. - - Could be a link to /entry/instrument/beam/incident_polarization_angle or - /entry/instrument/beam/final_polarization_angle if they exist. - - - - - Ellipticity of the incoming or outgoing beam. - - Can be any of linear polarization angle (degrees), ellipticity (arb. units). - Could be a link to /entry/instrument/beam/incident_ellipticity or - /entry/instrument/beam/final_ellipticity if they exist. - - diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 73a295834a..0a7bc39972 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -564,6 +564,7 @@ NXmpes(NXobject): doc: | Voltage applied to sample and sample holder. (NXdata): + # to be replaced by NXdata_mpes with base class inheritance \@signal: enumeration: [data] data(NX_NUMBER): @@ -606,46 +607,6 @@ NXmpes(NXobject): spec: ISO 18115-1:2023 term: 12.16 url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - kx(NX_NUMBER): - exists: optional - unit: NX_ANY - doc: | - Calibrated x axis in k-space. - Units are 1/Angström. - ky(NX_NUMBER): - exists: optional - unit: NX_ANY - doc: | - Calibrated y axis in k-space. - Units are 1/Angström - kz(NX_NUMBER): - exists: optional - unit: NX_ANY - doc: | - Calibrated k axis in k-space. - Units are 1/Angström. - delay(NX_NUMBER): - exists: optional - unit: NX_TIME - doc: | - Calibrated delay time. - polarization_angle(NX_FLOAT): - exists: optional - unit: NX_ANGLE - doc: | - Linear polarization angle of the incoming or outgoing beam. - - Could be a link to /entry/instrument/beam/incident_polarization_angle or - /entry/instrument/beam/final_polarization_angle if they exist. - ellipticity(NX_FLOAT): - exists: optional - unit: NX_ANGLE - doc: | - Ellipticity of the incoming or outgoing beam. - - Can be any of linear polarization angle (degrees), ellipticity (arb. units). - Could be a link to /entry/instrument/beam/incident_ellipticity or - /entry/instrument/beam/final_ellipticity if they exist. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ # 576bc8ae6b6e2395aca8c6297bf482fc68d82068637a9f9c895567547d4794f7 From f1e439c246eee6cc9680f71de291fa1aac1e9ae7 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 5 Jan 2024 17:09:19 +0100 Subject: [PATCH 0431/1012] add a NXdata_mpes class as glossary --- contributed_definitions/NXdata_mpes.nxdl.xml | 120 ++++++++++ .../nyaml/NXdata_mpes.yaml | 217 ++++++++++++++++++ 2 files changed, 337 insertions(+) create mode 100644 contributed_definitions/NXdata_mpes.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXdata_mpes.yaml diff --git a/contributed_definitions/NXdata_mpes.nxdl.xml b/contributed_definitions/NXdata_mpes.nxdl.xml new file mode 100644 index 0000000000..f3db210781 --- /dev/null +++ b/contributed_definitions/NXdata_mpes.nxdl.xml @@ -0,0 +1,120 @@ + + + + + + :ref:`NXdata_mpes` describes the plottable data and related dimension scales in MPES + experiments. + + It extends the NXdata class and provides a glossary of explicitly named axis names + which are typical for MPES data. + + + + Calibrated energy axis. + + This could be a link to either + /entry/process/energy_calibration/calibrated_axis or + /entry/process/energy_correction/calibrated_axis. + + + + The energy can be either stored as kinetic or as binding energy. + + + + + Calibrated kinetic energy axis. + + This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. + + .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 + + + + + Calibrated binding energy axis. + + This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. + + .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + + + + + + + + + + Calibrated x axis in k-space. + Units are 1/Angström. + + + + + + + Calibrated y axis in k-space. + Units are 1/Angström + + + + + + + Calibrated k axis in k-space. + Units are 1/Angström. + + + + + + + Calibrated delay time. + + + + + + + Linear polarization angle of the incoming or outgoing beam. + + Could be a link to /entry/instrument/beam/incident_polarization_angle or + /entry/instrument/beam/final_polarization_angle if they exist. + + + + + + + Ellipticity of the incoming or outgoing beam. + + Can be any of linear polarization angle (degrees), ellipticity (arb. units). + Could be a link to /entry/instrument/beam/incident_ellipticity or + /entry/instrument/beam/final_ellipticity if they exist. + + + + + diff --git a/contributed_definitions/nyaml/NXdata_mpes.yaml b/contributed_definitions/nyaml/NXdata_mpes.yaml new file mode 100644 index 0000000000..75ccb6284d --- /dev/null +++ b/contributed_definitions/nyaml/NXdata_mpes.yaml @@ -0,0 +1,217 @@ +category: base +doc: | + :ref:`NXdata_mpes` describes the plottable data and related dimension scales in MPES + experiments. + + It extends the NXdata class and provides a glossary of explicitly named axis names + which are typical for MPES data. +type: group +NXdata_mpes(NXdata): + energy(NX_NUMBER): + unit: NX_ENERGY + doc: | + Calibrated energy axis. + + This could be a link to either + /entry/process/energy_calibration/calibrated_axis or + /entry/process/energy_correction/calibrated_axis. + \@type: + type: NX_CHAR + doc: | + The energy can be either stored as kinetic or as binding energy. + enumeration: + kinetic: + doc: + - | + Calibrated kinetic energy axis. + - | + xref: + spec: ISO 18115-1:2023 + term: 3.35 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 + binding: + doc: + - | + Calibrated binding energy axis. + - | + xref: + spec: ISO 18115-1:2023 + term: 12.16 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + \@energy_indices: + \@energy_depends: + kx(NX_NUMBER): + exists: optional + unit: NX_ANY + doc: | + Calibrated x axis in k-space. + Units are 1/Angström. + \@kx_indices: + \@kx_depends: + ky(NX_NUMBER): + exists: optional + unit: NX_ANY + doc: | + Calibrated y axis in k-space. + Units are 1/Angström + \@ky_indices: + \@ky_depends: + kz(NX_NUMBER): + exists: optional + unit: NX_ANY + doc: | + Calibrated k axis in k-space. + Units are 1/Angström. + \@kz_indices: + \@kz_depends: + delay(NX_NUMBER): + exists: optional + unit: NX_TIME + doc: | + Calibrated delay time. + \@delay_indices: + \@delay_depends: + polarization_angle(NX_FLOAT): + exists: optional + unit: NX_ANGLE + doc: | + Linear polarization angle of the incoming or outgoing beam. + + Could be a link to /entry/instrument/beam/incident_polarization_angle or + /entry/instrument/beam/final_polarization_angle if they exist. + \@polarization_angle_indices: + \@polarization_angle_depends: + ellipticity(NX_FLOAT): + exists: optional + unit: NX_ANGLE + doc: | + Ellipticity of the incoming or outgoing beam. + + Can be any of linear polarization angle (degrees), ellipticity (arb. units). + Could be a link to /entry/instrument/beam/incident_ellipticity or + /entry/instrument/beam/final_ellipticity if they exist. + \@ellipticity_indices: + \@ellipticity_depends: + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# e8df328730ff1a4ead63d716fd57acd5a3abc1a2632f4b4cd941e9d5eb763bee +# +# +# +# +# +# :ref:`NXdata_mpes` describes the plottable data and related dimension scales in MPES +# experiments. +# +# It extends the NXdata class and provides a glossary of explicitly named axis names +# which are typical for MPES data. +# +# +# +# Calibrated energy axis. +# +# This could be a link to either +# /entry/process/energy_calibration/calibrated_axis or +# /entry/process/energy_correction/calibrated_axis. +# +# +# +# The energy can be either stored as kinetic or as binding energy. +# +# +# +# +# Calibrated kinetic energy axis. +# +# This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. +# +# .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 +# +# +# +# +# Calibrated binding energy axis. +# +# This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. +# +# .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 +# +# +# +# +# +# +# +# +# +# Calibrated x axis in k-space. +# Units are 1/Angström. +# +# +# +# +# +# +# Calibrated y axis in k-space. +# Units are 1/Angström +# +# +# +# +# +# +# Calibrated k axis in k-space. +# Units are 1/Angström. +# +# +# +# +# +# +# Calibrated delay time. +# +# +# +# +# +# +# Linear polarization angle of the incoming or outgoing beam. +# +# Could be a link to /entry/instrument/beam/incident_polarization_angle or +# /entry/instrument/beam/final_polarization_angle if they exist. +# +# +# +# +# +# +# Ellipticity of the incoming or outgoing beam. +# +# Can be any of linear polarization angle (degrees), ellipticity (arb. units). +# Could be a link to /entry/instrument/beam/incident_ellipticity or +# /entry/instrument/beam/final_ellipticity if they exist. +# +# +# +# +# From cdcebea4111a84c9e5b025e1e39d0a535bb8a08f Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 5 Jan 2024 18:52:18 +0100 Subject: [PATCH 0432/1012] Implemented design of event_data_apm, correlated signals with keyword logged_against, and base classes for processing of results --- ...l.yml => NXapm_charge_state_analysis.yaml} | 0 .../nyaml/refactor/NXapm_hit_finding.yaml | 5 + .../nyaml/refactor/NXapm_mass_to_charge.yaml | 5 + .../nyaml/refactor/NXapm_msr.yaml | 95 ++-- .../nyaml/refactor/NXapm_ranging.yaml.yml | 5 + .../nyaml/refactor/NXapm_reconstruction.yaml | 5 + .../nyaml/refactor/NXapm_volt_and_bowl.yaml | 5 + .../nyaml/refactor/NXevent_data_apm.yaml | 196 +++++++ .../nyaml/refactor/NXevent_data_apm_set.yaml | 26 + .../nyaml/refactor/NXpulser_apm.yaml | 86 ++- .../nyaml/refactor/NXreflectron.yaml | 18 +- .../nyaml/refactor/Nxapm_new.yaml | 512 ++++++++++++++++-- 12 files changed, 833 insertions(+), 125 deletions(-) rename contributed_definitions/nyaml/refactor/{NXapm_charge_state_analysis.yaml.yml => NXapm_charge_state_analysis.yaml} (100%) create mode 100644 contributed_definitions/nyaml/refactor/NXapm_hit_finding.yaml create mode 100644 contributed_definitions/nyaml/refactor/NXapm_mass_to_charge.yaml create mode 100644 contributed_definitions/nyaml/refactor/NXapm_ranging.yaml.yml create mode 100644 contributed_definitions/nyaml/refactor/NXapm_reconstruction.yaml create mode 100644 contributed_definitions/nyaml/refactor/NXapm_volt_and_bowl.yaml create mode 100644 contributed_definitions/nyaml/refactor/NXevent_data_apm.yaml create mode 100644 contributed_definitions/nyaml/refactor/NXevent_data_apm_set.yaml diff --git a/contributed_definitions/nyaml/refactor/NXapm_charge_state_analysis.yaml.yml b/contributed_definitions/nyaml/refactor/NXapm_charge_state_analysis.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXapm_charge_state_analysis.yaml.yml rename to contributed_definitions/nyaml/refactor/NXapm_charge_state_analysis.yaml diff --git a/contributed_definitions/nyaml/refactor/NXapm_hit_finding.yaml b/contributed_definitions/nyaml/refactor/NXapm_hit_finding.yaml new file mode 100644 index 0000000000..44904b5cb4 --- /dev/null +++ b/contributed_definitions/nyaml/refactor/NXapm_hit_finding.yaml @@ -0,0 +1,5 @@ +category: base +doc: | + Base class for collecting the configuration and results from a hit finding algorithm. +type: group +NXapm_hit_finding(NXprocess): # when evolving these ideas further inherit from NXapm_method instead diff --git a/contributed_definitions/nyaml/refactor/NXapm_mass_to_charge.yaml b/contributed_definitions/nyaml/refactor/NXapm_mass_to_charge.yaml new file mode 100644 index 0000000000..b6b8e42935 --- /dev/null +++ b/contributed_definitions/nyaml/refactor/NXapm_mass_to_charge.yaml @@ -0,0 +1,5 @@ +category: base +doc: | + Base class for collecting the configuration and results from ToF to mass-to-charge-state ratio algorithm. +type: group +NXapm_mass_to_charge(NXprocess): # when evolving these ideas further inherit from NXapm_method instead diff --git a/contributed_definitions/nyaml/refactor/NXapm_msr.yaml b/contributed_definitions/nyaml/refactor/NXapm_msr.yaml index c8471e563c..6aea40f398 100644 --- a/contributed_definitions/nyaml/refactor/NXapm_msr.yaml +++ b/contributed_definitions/nyaml/refactor/NXapm_msr.yaml @@ -4,51 +4,48 @@ doc: | Ideally, we would like to describe the workflow of experiments and simulations of atom probe and field-evaporation simulation research in more detail and contextualize better descriptions of - experiments and computer simulations. + experiments and computer simulations for atom probe research. The main motivation for this is the ongoing development and tighter becoming connection between atom probe - and other material characterization techniques like electron microscopy as it is documented in the literature in practice - by `T. Kelly et al. `_, `C. Fleischmann et al. `_, - and theory by `W. Windl et al. `_ or `C. Freysoldt et al. https://doi.org/10.1103/PhysRevLett.124.176801>`_ - to mention but a few. To arrive at a design of base classes and an application definition which can be used - for both real and simulated atom probe experiments it is worthwhile to recall first several different concepts - that are related to events and (molecular) ions. The reason is that it is current research practice within that research field - that exploratory research workflows focus on obtaining material-structure-material-property correlations: + and other material characterization techniques foremost electron microscopy (see `T. Kelly et al. `_, `C. Fleischmann et al. `_, and `W. Windl et al. `_ or `C. Freysoldt et al. https://doi.org/10.1103/PhysRevLett.124.176801>`_ to mention but a few). + To arrive at a design of base classes and an application definition which can be used for both real and simulated atom probe experiments it is worthwhile to recall first several different concepts that are related to events and (molecular) ions: * Pulsing events which are used to trigger ion extraction events. * Physical events and corresponding signal triggered by an ion hitting the detector. - These events are not necessarily caused directly correlated with an identifiable pulsing event. + Some of these events are not necessarily caused by or directly correlated with an identifiable pulsing event. * Processed ion hits which are the result of an algorithm that took the physical and pulsing events as input - and qualifies some of these events as to be of sufficiently high quality to substantiate that they - indicate that a (molecular) ion is wortwhile to be considered further and eventually included in the reconstructed volume. + and qualified some of these events as to be of sufficiently high quality to call them (molecular) ions that are + wortwhile to be considered further and eventually included in the reconstructed volume. * Calibration and signal filtering steps applied to these processed ion hits as input which results in actually selected (molecular) ions based on which an instance of a reconstruction is created. * Correlation of these ions with a statistics and theoretical model of mass-to-charge-state ratio values - and charge states of these to substantiate that some of these ions are can be considered as rangable - and thus an iontype can be associated by running again peak finding algorithms and labeling i.e. ranging - algorithms. + and charge states of the (molecular) ions to substantiate that some of these ions are can be considered + as rangable ions and hence an iontype can be associated by running peak finding algorithms and labeling + i.e. algorithms for defining ranging definitions. - Not only in AMETEK/Cameca's IVAS/APSuite software, which the majority of atom probers use, these concepts are - well distinguished. However, the algorithms used to transform correlations between pulses and physical events into - actual events i.e. detector hits ions is a proprietary one. Due to this practical inaccessibility of details, - virtually all atom probe studies currently use a reporting scheme where the course of the specimen evaporation - is documented where quantities are a function of evaporation identifier i.e. actual event/ion, i.e. after having the - hits finding algorithm and correlations applied. That is the evaporation_identifier take the role of an implicit - time and course of the experiment. + Not only in AMETEK/Cameca's IVAS/APSuite software, which the majority of atom probers use, these concepts + are well distinguished. However, the algorithms used to transform correlations between pulses and physical events + into actual events (detector hits) ions is a proprietary one. Due to this practical inaccessibility of details, virtually all + atom probe studies currently use a reporting scheme where the course of the specimen evaporation + is documented that quantities are a function of evaporation identifier i.e. actual event/ion, i.e. after having the + hits finding algorithm and correlations applied. That is evaporation_identifier values take the role of an implicit + time and course of the experiment given that ion extraction is a sequential physical process. - There is a number of groups who build own instruments and share different aspects of their technical specifications - and approaches they use for data processing. Despite some of these activities have embraced open source practices - and reporting schemes, they all use essentially the same workflow that has been proposed by AMETEK/Cameca and its - forerunner company Imago which is graphical user interface based analysis of atom probe data. Specifically, - software is used to correlate and interpret pulsing and physical events into processed ion hits. Some of these - after having calibrations and corrections applied are reported as (molecular) ions with ranged iontypes to yield a dataset - based on which scientific conclusions about the characterized material volume can be made. + There is a number of research groups who build own instruments and share different aspects of their technical + specifications and approaches how they apply data processing (e.g. `M. Monajem et al. `_, `P. Stender et al. `_ , or `I. Dimkou et al. `_). + Despite some of these activities embrace practices of open-source development, they use essentially the same + workflow that has been proposed by AMETEK/Cameca and its forerunner company Imago: A graphical user interface + software is used to explore and thus analyze reconstructed atom probe datasets. + + Specifically, software is used to correlate and interpret pulsing and physical events into processed ion hits. + Some of these ion hits are reported as (molecular) ions with ranged iontypes to yield a dataset based on which + scientific conclusions about the characterized material volume are made. By contrast, simulations of field-evaporation have the luxury to document the flight path and allow following the - whereabouts of each ion evaporated if needed. This level of detail is currently not characterizable in experiment - and thus there is an artificial divide between schemas describing simulations of atom probe vs measurements of atom probe. - We argue that this divide can be bridged with realizing the above-mentioned context and the realization that similar concepts - are used in both worlds with many not only being similar but exactly the same. + whereabouts of each ion evaporated if needed. This level of detail is currently not characterizable in experiment. + Thus, there is an artificial divide between schemas describing simulations of atom probe vs measurements of atom probe. + We argue that this divide can be bridged with realizing the above-mentioned context and the realization that + similar concepts are used in both research realms with many concepts not only being similar but exactly the same. A further argument to support this view is that computer simulations of atom probe usually are compared to reconstructed datasets, either to the input configuration that served as the virtual specimen or to a real world atom probe experiment and its @@ -57,19 +54,24 @@ doc: | and reconstruction algorithms. Only the practical need for making ranging definitions is (at least as of now) not as much needed in field-evaporation simulations than it is in real world measurements because each ion has a prescribed iontype in the simulation. Be it a specifically charged nuclid or a molecular ion whose flight path the simulation resolves. - However, the simpler ranging of simulations is we have to consider that this is only because currently many of the - indeed multi-scale (time and space) aspects of the challenge that is the simulating of field-evaporation are simplified - because of demand in computing resources or knowledge gaps in how to deal with these complexities. Molecular ion dissociation - upon flight is one such. Also the complexity of simulation setups is simpler such as assuming a straight flight path, ignoring details - such as local electrodes or physical obstacles and electric fields (controlled or stray fields) which however do have an effect - on an ion's flight path in a measurement. + Although, in principle simpler though, we have to consider that this is caused by many assumptions made in the simulations. + Indeed, the multi-scale (time and space) aspects of the challenge that is the simulating of field-evaporation are simplified + because of demand in computing resources or knowledge gaps in how to deal with some complexities. Molecular ion dissociation + upon flight is one such complexity. Also the complexity of simulation setups is simpler e.g. the assumption of a straight flight path + instrument is used or details are ignored such as local electrodes or physical obstacles and electric fields (controlled or stray fields). - To conclude, we thus propose two base classes :ref:`NXapm_msr` and :ref:`NXapm_sim` where the second - one may in the future turn out to become obsolete as people realize that a simulated atom probe is maybe - equivalent in design and function to a real atom probe that is just imagined to be stripped of many components. + To conclude, we thus propose two base classes :ref:`NXapm_msr` and :ref:`NXapm_sim` where the second one may become + obsolete in the future as people realize that a simulated atom probe is maybe equivalent in design and function to a + real atom probe if considering that the simulation is just stripped of many components. # noteworthy the situation is similar to electron microscopy especially transmission electron microscopy where factually # interpretation without simulations is pointless. The only difference is that in electron microscopy there is a large availability # of documentation and open-source tools for performing such simulations. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + p: | + Number of pulses collected in between start_time and end_time + resolved by an instance of :ref:`NXevent_data_apm`. type: group NXapm_msr(NXobject): # when evolving these ideas further inherit from NXapm_method instead instrument(NXinstrument): @@ -89,7 +91,9 @@ NXapm_msr(NXobject): # when evolving these ideas further inherit from NXapm_met Using GEOREF is preferred. (NXfabrication): (NXreflectron): - # decelerate_electrode(NXlens_em): + decelerate_electrode(NXlens_em): + doc: | + A counter electrode of the LEAP 6000 series atom probes. # counter_electrodes being optional WO2016171675A1 # see https://en.wikipedia.org/wiki/Einzel_lens for details double einzel lens in the invizo 6000 # according to A. Breen (UNSW) @@ -106,13 +110,9 @@ NXapm_msr(NXobject): # when evolving these ideas further inherit from NXapm_met ion_detector(NXdetector): doc: | Detector for taking raw time-of-flight and ion/hit impact positions data. + # model, serial_number, manufacturer_name all inherited from NXdetector base class pulser(NXpulser_apm): stage_lab(NXstage_lab): - # 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): buffer_chamber(NXchamber): @@ -125,4 +125,3 @@ NXapm_msr(NXobject): # when evolving these ideas further inherit from NXapm_met A statement whether the measurement was successful or failed prematurely. enumeration: [success, failure, unknown] (NXevent_data_apm_set): -# (NXevent_data_apm): diff --git a/contributed_definitions/nyaml/refactor/NXapm_ranging.yaml.yml b/contributed_definitions/nyaml/refactor/NXapm_ranging.yaml.yml new file mode 100644 index 0000000000..e5db027aee --- /dev/null +++ b/contributed_definitions/nyaml/refactor/NXapm_ranging.yaml.yml @@ -0,0 +1,5 @@ +category: base +doc: | + Base class for collecting the configuration and results from tomographic reconstruction algorithm. +type: group +NXapm_ranging(NXprocess): # when evolving these ideas further inherit from NXapm_method instead diff --git a/contributed_definitions/nyaml/refactor/NXapm_reconstruction.yaml b/contributed_definitions/nyaml/refactor/NXapm_reconstruction.yaml new file mode 100644 index 0000000000..44904b5cb4 --- /dev/null +++ b/contributed_definitions/nyaml/refactor/NXapm_reconstruction.yaml @@ -0,0 +1,5 @@ +category: base +doc: | + Base class for collecting the configuration and results from a hit finding algorithm. +type: group +NXapm_hit_finding(NXprocess): # when evolving these ideas further inherit from NXapm_method instead diff --git a/contributed_definitions/nyaml/refactor/NXapm_volt_and_bowl.yaml b/contributed_definitions/nyaml/refactor/NXapm_volt_and_bowl.yaml new file mode 100644 index 0000000000..d35274eb40 --- /dev/null +++ b/contributed_definitions/nyaml/refactor/NXapm_volt_and_bowl.yaml @@ -0,0 +1,5 @@ +category: base +doc: | + Base class for collecting the configuration and results from a voltage and bowl ToF correction algorithm. +type: group +NXapm_volt_and_bowl(NXprocess): # when evolving these ideas further inherit from NXapm_method instead diff --git a/contributed_definitions/nyaml/refactor/NXevent_data_apm.yaml b/contributed_definitions/nyaml/refactor/NXevent_data_apm.yaml new file mode 100644 index 0000000000..542d548e01 --- /dev/null +++ b/contributed_definitions/nyaml/refactor/NXevent_data_apm.yaml @@ -0,0 +1,196 @@ +category: base +doc: | + Base class to store state and (meta)data of events over the course of an atom probe experiment. + + This base class applies the concept of the :ref:`NXevent_data_em` base class to the + specific needs of atom probe research. Against static and dynamic quantities are splitted to + avoid duplication of information. Specifically, the time interval considered is the entire time + starting at start_time until end_time during which we assume the pulser triggered named pulses. + These pulses are identified via the pulse_identifier field. The point in time when each was issued + is specified via the combination of start_time and delta_time. + + Conceptually and technically NeXus currently stores tensorial information as arrays of values + (with each value of the same datatype). For instance, a field temperature(NX_FLOAT) stores + a set of temperature values but that field when used somewhere is a concept. However, that + concept has no information at which point in time these temperatures were taken is there + is some functional relationship. + + However, a correct interpretation of the temperature values demands knowledge about what is + the independent quantity on which temperature depends on or according to which frequency + temperature values were sampled. + In NeXus there are two approaches which cope with these in fact correlated concepts: + One is :ref:`NXdata` where the attribute signal specifies the correlation. + The other one is :ref:`NXlog` which, like NXdata, demands to granularize logged_against + (dependent signal) and independent quantity into an own group. In many cases this additional + grouping is undesired. + + One naive solution typically employed is then to store the independent variable values via a second + vector e.g. time_stamp with the same number of entries (with dimensionality defined through symbols). + + However, there is no independent logical connection between these two concepts, i.e. temperature + and time_stamp! Indeed conceptually reporting temperature as a function of time_stamp is + a correlation between pairs of values one from each of two concepts. + + In the case of atom probe though the time that one would use in NXlog is defined implicitly via pulse_identifier, + which is the independent variable vector against which eventually dozens of channels of data are logged. + Not only are these channels logged they should ideally also be self-descriptive in that these channels have + pulse_identifier as the independent variable but we do not wish to duplicate this information all the time but + reference it. + + Therefore, we here explore the use of an attribute with symbol logged_against. Maybe it is better to use the + symbol depends_on but this is easily to be confused with depends_on that is used for instances of + :ref:`NXtransformations`. Consequently, if depends_on were to be used extra logic is needed by consuming + applications to understand that the here build correlations are conceptually different ones. + + This issue should be discussed further by the NeXus community. +type: group +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + p: | + Number of pulses collected in between start_time and end_time. +NXevent_data_apm(NXobject): + start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval started. If the user wishes to specify an + interval of time that the snapshot should represent during which the instrument + was stable and configured using specific settings and calibrations, + the start_time is the start (left bound of the time interval) while + the end_time specifies the end (right bound) of the time interval. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval ended. + delta_time(NX_NUMBER): + doc: | + Delta time array which resolves for each pulse_identifier the time difference + between when that pulse was issued and start_time. + + In summary, using start_time, end_time, time, pulse_identifier_offset, and + pulse_identifier exactly specifies the connection between when a pulse was + issued relative to start and absolute in UTC. + unit: NX_TIME + dim: (p,) + pulse_identifier_offset(NX_INT): + doc: | + Integer used to name the first pulse to know if there is an + offset of the identifiers to zero. + + Identifiers can be defined either implicitly or explicitly. + For implicit indexing identifiers are defined on the interval + :math:`[identifier_offset, identifier_offset + c - 1]`. + + Therefore, implicit identifier are completely defined by the value of + identifier_offset and cardinality. For example if identifier run from + -2 to 3 the value for identifier_offset is -2. + + For explicit indexing the field identifier has to be used. + Fortran-/Matlab- and C-/Python-style indexing have specific implicit + identifier conventions where identifier_offset is 1 and 0 respectively. + unit: NX_UNITLESS + pulse_identifier(NX_INT): + doc: | + Identifier that contextualizes how the detector and pulser of an atom probe + instrument follow a sequence of pulses to trigger field evaporation. + + The pulse_identifier is used to associate thus an information about time + when the quantities documented in this NXpulser_apm base class have been + collected via sampling. + + In virtually all cases the pulser is a blackbox which users assume does its job. + That is to induce pulses according to given instances in time with target properties. + Depending on how the instrument is configured during a measurement the target + values and thus also the actual values may change. + + Maybe the first part of the experiment is run at a certain pulse fraction but thereafter + the pulse_fraction is changed. In this case the field pulse_fraction is a vector which + collects all measured values of the pulse_fraction, pulse_identifier is then an equally + long vector which stores the set of events (e.g. pulsing events) when that value was + measured. + + This may cause several situation: In the case that e.g. the pulse_fraction is never changed + and also exact details not interesting, one stores the set value for the pulse_fraction + and a single value for the pulse_identifier e.g. 0 to indicate that the pulse_fraction was set + at the beginning and it was maintained constant during the measurement. + If the pulse_fraction was maybe changed after the 100000th pulse pulse_fraction is a + vector with two values one for the first and another one for the value from the 100000-th + pulse onwards. The values of pulse_identifier are then [0, 99999] respectively. + unit: NX_UNITLESS + dim: (p,) + instrument(NXinstrument): + doc: | + (Meta)data of the dynamics and changes of the microscope over the course of pulsing. + (NXreflectron): + local_electrode(NXlens_em): + ion_detector(NXdetector): + signal_amplitude(NX_FLOAT): + 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 + dim: (p,) + # does p only specific the length or does it also convey a logical correlation + # conceptually to another vector which happens to have the same dimensions + # I clear say NO ! + pulser(NXpulser_apm): + stage_lab(NXstage_lab): + average_temperature(NX_FLOAT): + doc: | + Average temperature at the specimen base, i.e. + base_temperature during the measurement. + unit: NX_TEMPERATURE + # normally one would use NXsensor/NXlog but point is that the temperature + # is logged against the pulse_identifier as even in the proprietary file format from + # AMETEK/Cameca nowhere there is the actual time when the pulse was triggered + # just the sampling frequency and I guess but am not 100percent sure which quantity + # from Cameca this is also the time when the first pulse was triggered + # using NXlog does make sense when individual NXsensors have different timing + # but for atom probe if at all the pulse-based implicit time is available + temperature(NX_FLOAT): + 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 + dim: (p,) + \@logged_against(NX_CHAR): + doc: | + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + analysis_chamber(NXchamber): + average_temperature(NX_FLOAT): + doc: | + Average pressure in the analysis chamber during the measurement. + unit: NX_PRESSURE + pressure(NX_FLOAT): + doc: | + Pressure in the analysis chamber. + unit: NX_PRESSURE + dim: (p,) + \@logged_against(NX_CHAR): + doc: | + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + buffer_chamber(NXchamber): + pressure(NX_FLOAT): + doc: | + Pressure in the analysis chamber. + unit: NX_PRESSURE + dim: (p,) + \@logged_against(NX_CHAR): + doc: | + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + load_lock_chamber(NXchamber): + pressure(NX_FLOAT): + doc: | + Pressure in the analysis chamber. + unit: NX_PRESSURE + dim: (p,) + \@logged_against(NX_CHAR): + doc: | + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + # getter_pump(NXpump): + # roughening_pump(NXpump): + # turbomolecular_pump(NXpump): diff --git a/contributed_definitions/nyaml/refactor/NXevent_data_apm_set.yaml b/contributed_definitions/nyaml/refactor/NXevent_data_apm_set.yaml new file mode 100644 index 0000000000..b460526fe9 --- /dev/null +++ b/contributed_definitions/nyaml/refactor/NXevent_data_apm_set.yaml @@ -0,0 +1,26 @@ +category: base +doc: | + Base class for a set of :ref:`NXevent_data_apm` instances. + + Members of the set are instances of :ref:`NXevent_data_apm`. + These have an associated time interval during which the conditions + of the instrument were considered stable and fit enough for purpose. + + Which temporal granularity is adequate depends on the situation and + research question. Using a model which enables a collection of events offers + the most flexible way to cater for both experiments with controlled electron + beams in a real microscope or the simulation of such experiments or + individual aspects of such experiments. + + To monitor the course of an ion extraction experiment (or simulation) + it makes sense to track either time explicitly with time stamps or implicitly + via e.g. a clock inside the instrument, such as the clock of the pulser. + + As set and measured quantities typically change over time and we do not + yet know during the measurement which of the events have associated + molecular ions that will end up in the reconstructed volume we must not + document quantities as a function of the evaporated_identifier but as a + function of the (pulsing)event_identifier. +type: group +NXevent_data_apm_set(NXobject): + (NXevent_data_apm): diff --git a/contributed_definitions/nyaml/refactor/NXpulser_apm.yaml b/contributed_definitions/nyaml/refactor/NXpulser_apm.yaml index 50d57447ab..8a653bf643 100644 --- a/contributed_definitions/nyaml/refactor/NXpulser_apm.yaml +++ b/contributed_definitions/nyaml/refactor/NXpulser_apm.yaml @@ -4,57 +4,73 @@ doc: | symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. - n_events: | - Total number of events along a time trajectory, not necessarily the same as ions. + p: | + Number of pulses collected in between start_time and end_time + resolved by an instance of :ref:`NXevent_data_apm`. type: group NXpulser_apm(NXobject): (NXfabrication): pulse_mode(NX_CHAR): doc: | - Detail whereby ion extraction is trigger methodologically. + Detail whereby ion extraction is triggered methodologically. enumeration: [laser, voltage, laser_and_voltage] pulse_frequency(NX_FLOAT): doc: | - Frequency with which the high voltage or laser pulser fires. - - For this and other fields whose dimensions are parameterized - with n_events these values can change over the course of the experiment. - In the simplest case the field stores a scalar value that is ideally - the actual value not the set value. - # APT HDF defines it therefore as follows: "PulseFrequency : Real array, 2xn (Hz) This is the frequency of the high voltage or laser pulser. first entry : first pulse number where the spacing between this and all subsequent pulses are considered to be at the selected frequency. Each first entry must be strictly increasing in value. The second entry contains the frequency value" as data can be compressed in this case very efficiently we go for with an array of length 1xn_ions - dim: (n_events,) + Frequency with which the voltage or laser pulser fire(s). + # the example of how the IFES APT TC's HDF format deals with such conceptually shows how awkward instance, concepts are mixed to superconcepts: "PulseFrequency : Real array, 2xn (Hz) This is the frequency of the high voltage or laser pulser. first entry : first pulse number where the spacing between this and all subsequent pulses are considered to be at the selected frequency. Each first entry must be strictly increasing in value. The second entry contains the frequency value" as data can be compressed in this case very efficiently we go for with an array of length 1xn_ions + unit: NX_FREQUENCY + dim: (p,) + \@logged_against(NX_CHAR): + doc: | + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. pulse_fraction(NX_FLOAT): doc: | Fraction of the pulse_voltage that is applied in addition to the standing_voltage at peak voltage of a pulse. If a standing voltage is applied, this gives nominal pulse fraction - (as a function of standing voltage). Otherwise, - this field should not be present. + (as a function of standing voltage). Otherwise, this field should + not be present. unit: NX_DIMENSIONLESS - dim: (n_events,) - pulsed_voltage(NX_FLOAT): + dim: (p,) + \@logged_against(NX_CHAR): + doc: | + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + pulse_voltage(NX_FLOAT): doc: | - In laser pulsing mode the values will be zero so the this field is recommended. - However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. + Pulsed voltage, in laser pulsing mode this values can be omitted. + # example of a conditional requirement is done rigorously can be handled by OWL but not by NeXus! + # as either pulse_voltage is required in an appdef but then that existence constraint is independent of + # other values. unit: NX_VOLTAGE - dim: (n_events,) + dim: (p,) + \@logged_against(NX_CHAR): + doc: | + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. pulse_number(NX_UINT): unit: NX_UNITLESS doc: | Absolute number of pulses starting from the beginning of the experiment. - dim: (n_events,) + dim: (p,) + \@logged_against(NX_CHAR): + doc: | + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + # eventually equivalent to pulse_identifier within NXevent_data_apm standing_voltage(NX_FLOAT): doc: | Direct current voltage between the specimen and the (local electrode) in the case of local electrode atom probe (LEAP) instrument. Otherwise, the standing voltage applied to the sample, relative to system ground. unit: NX_VOLTAGE - dim: (n_events,) + dim: (p,) + \@logged_against(NX_CHAR): + doc: | + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. (NXsource): 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. + Atom probe microscopes use controlled laser, voltage, or a combination of + pulsing strategies to trigger ion extraction via exciting and eventual field evaporation + field emission of ion at the specimen surface. name(NX_CHAR): doc: | Given name/alias. @@ -67,30 +83,52 @@ NXpulser_apm(NXobject): doc: | Nominal power of the laser source while illuminating the specimen. unit: NX_POWER - # NEW ISSUE: needs clearer specification/definition pulse_energy(NX_FLOAT): doc: | Average energy of the laser at peak of each pulse. unit: NX_ENERGY + dim: (p,) + \@logged_against(NX_CHAR): + doc: | + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + \@depends_on(NX_CHAR): + doc: | + Path to instance of :ref:`NXcoordinate_system` which specifies + the reference frame in which the laser is shining. (NXbeam): doc: | Details about specific positions along the focused laser beam which illuminates the (atom probe) specimen. - incidence_vector(NXcollection): + incidence_vector(NX_NUMBER): doc: | Track time-dependent settings over the course of the measurement how the laser beam in tip space/reconstruction space laser impinges on the sample, i.e. the mean vector is parallel to the laser propagation direction. + unit: NX_LENGTH + dim: (p, 3) + \@logged_against(NX_CHAR): + doc: | + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. pinhole_position(NXcollection): doc: | Track time-dependent settings over the course of the measurement where the laser beam exits the focusing optics. + unit: NX_LENGTH + dim: (p, 3) + \@logged_against(NX_CHAR): + doc: | + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. spot_position(NXcollection): doc: | Track time-dependent settings over the course of the measurement where the laser hits the specimen. + unit: NX_LENGTH + dim: (p, 3) + \@logged_against(NX_CHAR): + doc: | + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. (NXtransformations): doc: | Affine transformations which describe the geometry how the diff --git a/contributed_definitions/nyaml/refactor/NXreflectron.yaml b/contributed_definitions/nyaml/refactor/NXreflectron.yaml index 2733213c0a..71c3bd380d 100644 --- a/contributed_definitions/nyaml/refactor/NXreflectron.yaml +++ b/contributed_definitions/nyaml/refactor/NXreflectron.yaml @@ -9,9 +9,19 @@ doc: | * 3863068 and 6740872 for the reflectron * 8134119 for the curved reflectron - + +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + p: | + Number of pulses collected in between start_time and end_time + resolved by an instance of :ref:`NXevent_data_apm`. type: group NXreflectron(NXobject): + status(NX_CHAR): + doc: | + Status of eventual existence and potential usage of this reflectron. + enumeration: [none, present, used] name(NX_CHAR): doc: | Given name/alias. @@ -20,7 +30,11 @@ NXreflectron(NXobject): doc: | Free-text field to specify further details about the reflectron. The field can be used to inform e. g. if the reflectron is flat or curved. - # IFES_APT_TC "ReflectronVoltage: Real, 1xn array (V) Must be present if ReflectronInfo is not “None” The maximum voltage applied to the reflectron, relative to system ground." + voltage(NX_FLOAT): + doc: | + The maximum voltage applied to the reflectron, relative to system ground. + unit: NX_VOLTAGE + # dim: (p,) (NXtransformations): doc: | Affine transformation(s) which detail where the reflectron is located relative diff --git a/contributed_definitions/nyaml/refactor/Nxapm_new.yaml b/contributed_definitions/nyaml/refactor/Nxapm_new.yaml index 0b4163993a..74bed3f248 100644 --- a/contributed_definitions/nyaml/refactor/Nxapm_new.yaml +++ b/contributed_definitions/nyaml/refactor/Nxapm_new.yaml @@ -4,15 +4,29 @@ doc: | symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. + p: | + Number of pulses collected in between start_time and end_time + resolved by an instance of :ref:`NXevent_data_apm`. + + If this is not defined, p is the number of ions included in the reconstructed + volume if the application definition is used to store results of already + reconstructed datasets. + n: | + Number of ions spatially filtered from results of the hit_finding algorithm + from which an instance of a reconstructed volume has been generated. + These ions get new identifier assigned in the process, this is the so-called + evaporation_identifier that is not to be confused with the pulse_identifier! type: group -NXapm(NXapm_base): +NXapm(NXobject): (NXentry): exists: [min, 1, max, unbounded] \@version(NX_CHAR): doc: | - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. + An at least as strong as SHA256 hashvalue of the + file which specifies the application definition. definition(NX_CHAR): + doc: | + NeXus NXDL schema to which this file conforms. enumeration: [NXapm] profiling(NXcs_profiling): doc: | @@ -20,6 +34,7 @@ NXapm(NXapm_base): which was used to generate this NeXus file instance. command_line_call(NX_CHAR): (NXprogram): # understood by default as PROGRAM(NXprogram), i.e. program1, program2, ... + exists: [min, 0, max, infty] doc: | A collection of all programs and libraries which are considered relevant to understand with which software tools this NeXus file instance was @@ -35,7 +50,6 @@ NXapm(NXapm_base): which is used by the `NOMAD `_ research data management system, it makes sense to store e.g. the GitHub repository commit and respective submodule references used. - exists: [min, 0, max, infty] program(NX_CHAR): \@version(NX_CHAR): # \@url: @@ -44,8 +58,29 @@ NXapm(NXapm_base): service(NX_CHAR): identifier(NX_CHAR): is_persistent(NX_BOOLEAN): - run_number(NX_CHAR): # alias experiment_alias - # experiment_description(NX_CHAR): + run_number(NX_CHAR): + 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 run_number from IVAS/APSuite. + 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. With NXapm the RHIT or HITS + can be stored as via the NXserialized group in the hit_finding algorithm section. + + As a destructive microscopy technique, a run can be performed only once. + It is possible, however, to interrupt a run and restart data acquisition + while still using the same specimen. In this case, each evaporation run + needs to be distinguished with different run numbers. + We follow this habit of most atom probe groups. + Therefore, interrupted runs should be stored as individual NXentry instances! + # alias experiment_alias + # experiment_description(NX_CHAR): + # optional quantities do not need to be mentioned in an appdef because they can always be added # if NXapm inherits from NXapm_base having this optional field does not need to be # mentioned because optional nodes can always be added to a NeXus file instance without # making it thereby non-compliant to the application definition @@ -57,13 +92,52 @@ NXapm(NXapm_base): # effectively ask your colleague for that information while working off your imagined list of requirements # the appdef definition here is nothing else then document this for a software start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information + included when the 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. 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. (NXcite): exists: [min, 0, max, infty] + doi(NX_CHAR): (NXserialized): exists: [min, 0, max, infty] + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): operation_mode(NX_CHAR): + doc: | + What type of atom probe microscopy experiment is performed? This field is + meant to inform research data management systems to allow filtering: + + * apt are experiments where the analysis_chamber has no imaging gas. + experiment with LEAP instruments are typically performed such. + * fim are experiments where the analysis_chamber has an imaging gas, + which should be specified with the atmosphere in the analysis_chamber group. + * apt_fim should be used for combinations of the two imaging modes. + few experiments of this type have been performed as this can be detrimental + to LEAP systems (see `S. Katnagallu et al. `_). + * other should be used in combination with the user specifying details in the + experiment_documentation field. + enumeration: [apt, fim, apt_fim, other] (NXuser): exists: recommended name(NX_CHAR): @@ -74,45 +148,146 @@ NXapm(NXapm_base): is_persistent(NX_BOOLEAN): sample(NXsample): exists: optional - # move this doc string to NXapm_base 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. + atom probers about other knowledge they have gained about the sample. + There are cases where the specimen is machined further or exposed to + external stimuli during the experiment. In this case, these details should + not be stored under sample here but atom probers should make suggestions + how this application definition can be improved. In the future also details like how the grain_diameter was characterized, how the sample was prepared, how the material was heat-treated etc., should be stored as using specific application definitions/schemas which are then arranged and documented with a description of the workflow so that actionable graphs become instantiatable. - - For computer simulations of atom probe one usually works with - specific input configurations which are defined via specific positions - of specific nuclids. In this case identifier can be used to add a reference - to a sample whereby the input configuration was inspired or motivated. - # end of the move method(NX_CHAR): + exists: recommended + doc: | + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + enumeration: [experiment, simulation] identifier(NXidentifier): exists: optional service(NX_CHAR): identifier(NX_CHAR): is_persistent(NX_BOOLEAN): + 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 material yield strength 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. + + This can be problematic though because when the furnace door was left open + or the ambient temperature in the lab changed, i.e. for a series of + experiments where one is conducted on a hot summer day and the next + during winter this can have an effect on the evolution of the microstructure. + There are many cases where this has been reported to be an QA issue in industry, + e.g. think about aging aluminium samples left on the factory + parking lot on a hot summer day. + unit: NX_ANY # K/s + 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(NX_CHAR): + 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(NX_CHAR): + doc: | + Reporting compositions as atom and weight percent yields both + dimensionless quantities but their conceptual interpretation differs. + A normalization based on atom_percent counts relative to the + total number of atoms which are of a particular type. + By contrast, weight_percent normalization factorizes in the + respective mass of the elements. 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] + chemical_symbol(NX_CHAR): + doc: | + Human-readable name of the element (e.g. Fe). + Name has to be a symbol of an element from the periodic table. + All symbols in the set of NXion instances inside the group + chemical_composition need to be disjoint. + composition(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): + exists: optional + doc: | + Magnitude of the standard deviation of the composition (value). + unit: NX_DIMENSIONLESS specimen(NXsample): exists: optional + method(NX_CHAR): + exists: recommended + doc: | + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + enumeration: [experiment, simulation] identifier(NXidentifier): exists: recommended service(NX_CHAR): @@ -120,16 +295,112 @@ NXapm(NXapm_base): is_persistent(NX_BOOLEAN): parent_identifier(NXidentifier): exists: recommended + doc: | + Identifier of the sample from which the sample was cut or the string + *None*. The purpose of this field is to support functionalities + for tracking sample provenance via a research data management system. service(NX_CHAR): identifier(NX_CHAR): is_persistent(NX_BOOLEAN): preparation_date(NX_DATE_TIME): - name(NX_CHAR): exists: recommended + doc: | + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Ideally, this + matches the last timestamp that is mentioned in the digital resource + pointed to by parent_identifier. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments including tracers with a + short half time. Additional time stamps prior to preparation_date + should better be placed in resources which describe but which do not pollute + the description here with prose. Resolving these connected pieces of information + is considered within the responsibility of the research data management + system. + alias(NX_CHAR): + exists: recommended + doc: | + Given name an alias. Better use identifier and parent_identifier instead. + A single NXentry should be used only for the characterization of a single specimen. atom_types(NX_CHAR): - # describing the geometry of the sample + doc: | + List of comma-separated elements from the periodic table that are + contained in the specimen. If the specimen substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer research data management systems an + opportunity to parse the relevant elements without having to interpret + these from the resources pointed to by parent_identifier or walk through + eventually deeply nested groups in data instances. + description: + exists: optional + doc: | + Discouraged free-text field. + is_polycrystalline(NX_BOOLEAN): + exists: recommended + doc: | + Report if the specimen is polycrystalline, in which case it + contains a grain or phase boundary, or if the specimen is a + single crystal. + is_amorphous(NX_BOOLEAN): + exists: recommended + doc: | + Report if the specimen is amorphous. + # describing the geometry of the sample (NXcoordinate_system_set): exists: [min, 1, max, 1] + doc: | + Set to hold different coordinate systems conventions. + Inspect the description of the :ref:`NXcoordinate_system_set` + and :ref:`NXcoordinate_system` base classes how to define + coordinate systems in NeXus. Specific details for application + in atom probe microscopy follow. + + In this research field scientists usually distinguish several + Euclidean coordinate systems (CS): + + * World space; + a CS specifying a local coordinate system of the planet earth which + identifies into which direction gravity is pointing such that + the laboratory space CS can be rotated into this world CS. + * The laboratory space; + a CS specifying the room where the instrument is located in or + a physical landmark on the instrument, e.g. the direction of the + transfer rod where positive is the direction how the rod + has to be pushed during loading a specimen into the instrument. + In summary, this CS is defined by the chassis of the instrument. + * The specimen space; + a CS affixed to either the base or the initial apex of the specimen, + whose z axis points towards the detector. + * The detector space; + a CS affixed to the detector plane whose xy plane is usually in the + detector and whose z axis points towards the specimen. + This is a distorted space with respect to the reconstructed ion + positions. + * The reconstruction space; + a CS in which the reconstructed ion positions are defined. + The orientation depends on the analysis software used. + * Eventually further coordinate systems attached to the + flight path of individual ions might be defined. + + In atom probe microscopy a frequently used choice for the detector + space (CS) is discussed with the so-called detector space image + (stack). This is a stack of two-dimensional histograms of detected ions + within a predefined evaporation identifier interval. Typically, the set of + ion evaporation sequence IDs is grouped into chunks. + + For each chunk a histogram of the ion hit positions on the detector + is computed. This leaves the possibility for inconsistency between + the so-called detector space and the e.g. specimen space. + + 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. (NXcoordinate_system): exists: [min, 1, max, infty] origin(NX_CHAR): @@ -142,14 +413,121 @@ NXapm(NXapm_base): measurement(NXapm_msr): exists: optional + instrument(NXinstrument): + instrument_name(NX_CHAR): + (NXfabrication): + exists: recommended + vendor(NX_CHAR): + model(NX_CHAR): + identifier(NX_CHAR): + exists: recommended + (NXreflectron): + status(NX_CHAR): + (NXfabrication): + exists: recommended + vendor(NX_CHAR): + model(NX_CHAR): + # decelerate_electrode(NXlens_em): + local_electrode(NXlens_em): + # add flat test status + name(NX_CHAR): + (NXfabrication): + exists: recommended + vendor(NX_CHAR): + model(NX_CHAR): + ion_detector(NXdetector): + exists: [min, 1, max, 1] + (NXfabrication): + exists: recommended # for LEAP systems they come shipped configured + vendor(NX_CHAR): + model(NX_CHAR): + pulser(NXpulser_apm): + (NXfabrication): + exists: recommended + vendor(NX_CHAR): + model(NX_CHAR): + pulse_mode(NX_CHAR): + (NXsource): + exists: recommended # conditionally required if pulse_mode is not voltage! + (NXfabrication): + exists: recommended + vendor(NX_CHAR): + model(NX_CHAR): + wavelength(NX_FLOAT): + # stage_lab(NXstage_lab): + # analysis_chamber(NXchamber): + # buffer_chamber(NXchamber): + # load_lock_chamber(NXchamber): + # getter_pump(NXpump): + # roughening_pump(NXpump): + # turbomolecular_pump(NXpump): + status(NX_CHAR): + (NXevent_data_apm_set): + exists: [min, 0, max, 1] + # the case of allowing to not have event_data but only the above-mentioned instrument + # details can be useful to convey details about an atom probe instrument in general + (NXevent_data_apm): + exists: recommended + # all these cannot be made required because for LEAP only stored in RHIT/HITS + # but for M-TAP and Oxcart these pieces of information are available. + # start_time(NX_DATE_TIME): + # end_time(NX_DATE_TIME): + # delta_time(NX_NUMBER): + # pulse_identifier_offset(NX_INT): + # pulse_identifier(NX_INT): + instrument(NXinstrument): + # (NXreflectron): + # decelerate_electrode(NXlens_em): + # local_electrode(NXlens_em): + ion_detector(NXdetector): + signal_amplitude(NX_FLOAT): + unit: NX_CURRENT + dim: (p,) + pulser(NXpulser_apm): + pulse_frequency(NX_FLOAT): + # unit: NX_FREQUENCY + # dim: (p,) + \@logged_against(NX_CHAR): + pulse_fraction(NX_FLOAT): + # unit: NX_DIMENSIONLESS + # dim: (p,) + \@logged_against(NX_CHAR): + pulse_voltage(NX_FLOAT): + exists: recommended # not required for voltage pulsing + # unit: NX_VOLTAGE + # dim: (p,) + \@logged_against(NX_CHAR): + # pulse_number(NX_UINT): + standing_voltage(NX_FLOAT): + # unit: NX_VOLTAGE + # dim: (p,) + \@logged_against(NX_CHAR): + (NXsource): + exists: [min, 0, max, 2] # not required for voltage pulsing + pulse_energy(NX_FLOAT): + # unit: NX_ENERGY + # dim: (p,) + \@logged_against(NX_CHAR): + # laser geometry at the moment has no example nor any feedback from the community + # but NXpulser_apm base class shows how this could be done, plus examples for NXmpes + stage_lab(NXstage_lab): + average_temperature(NX_FLOAT): + analysis_chamber(NXchamber): + average_pressure(NX_FLOAT): + # buffer_chamber(NXchamber): + # load_lock_chamber(NXchamber): + # getter_pump(NXpump): + # roughening_pump(NXpump): + # turbomolecular_pump(NXpump): + simulation(NXapm_sim): exists: optional + atom_probe(NXroi): exists: [min, 0, max, infty] doc: | - A region-of-interest analyzed either during or after the session. - For which specific processed data of the measured or simulated - data are available. + A region-of-interest analyzed either during or after the session for which + specific processed data of the measured or simulated data are available. # add a default plot V = f(time/evaporation_id), essentially for each quantity # NEW ISSUE: check also here the PYCCAPT pipeline from P. Felfer's group # all other details are instances of NXprocess as steps along the pipeline @@ -161,12 +539,12 @@ NXapm(NXapm_base): # NEW ISSUE: different algorithms used one could create a class for each reconstruction method # NEW ISSUE: make this rather an own subentry NXapm_ranging - hit_finding(NXprocess): + hit_finding(NXapm_hit_finding): exists: optional sequence_index(NX_POSINT): exists: recommended (NXprogram): - exists: [min, 1, max, unbounded] + exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): # config of the hit_finding algorithm @@ -177,6 +555,10 @@ NXapm(NXapm_base): checksum(NX_CHAR): algorithm(NX_CHAR): number_of_dld_wires(NX_UINT): + doc: | + The number of wires in the detected. + unit: NX_UNITLESS + enumeration: [1, 2, 3] arrival_time_pairs(NX_NUMBER): # results of the hit_finding algorithm hit_positions(NX_NUMBER): @@ -184,20 +566,22 @@ NXapm(NXapm_base): hit_quality(NX_UINT): exists: optional dim: (i,) + hit_multiplicity(NX_UINT): + exists: recommended + dim: (i,) + # the following two quantities are relicts from ePOS files used to give some + # insight into the results of the hit_finding algorithm of IVAS/APSuite but typically + # used only in the context to learn about the multiplicity of an ion. pulses_since_last_ion(NX_UINT): exists: optional dim: (i,) - pulse_identifier_offset(NX_INT): + pulse_identifier(NX_INT): # this is the pulse on which they came exists: optional - pulse_identifier(NX_INT): - exists: optional - dim: (i,) - hit_multiplicity(NX_UINT): dim: (i,) # i number of hits after hits finding but prior calibrations hit_spatial_filtering(NXprocess): - exists: optional + exists: recommended sequence_index(NX_POSINT): exists: recommended (NXprogram): @@ -210,13 +594,37 @@ NXapm(NXapm_base): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): - hit_filter(NXcs_filter_boolean_mask): # use NXcs_filterneeds conditionally an instance of concept ../../hit_finding - number_of_objects(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - identifier(NX_INT): + evaporation_identifier_offset(NX_INT): + doc: | + Integer used to name the first pulse to know if there is an + offset of the identifiers to zero. + + Identifiers can be defined either implicitly or explicitly. + For implicit indexing identifiers are defined on the interval + :math:`[identifier_offset, identifier_offset + c - 1]`. + + Therefore, implicit identifier are completely defined by the value of + identifier_offset and cardinality. For example if identifier run from + -2 to 3 the value for identifier_offset is -2. + + For explicit indexing the field identifier has to be used. + Fortran-/Matlab- and C-/Python-style indexing have specific implicit + identifier conventions where identifier_offset is 1 and 0 respectively. + unit: NX_UNITLESS + evaporation_identifier(NX_INT): + doc: | + (Molecular) ion identifier which resolves the sequence in which + the ions were evaporated but taking into account that a hit_finding + and spatial filtering was applied. + unit: NX_UNITLESS + dim: (n,) + # hit_filter(NXcs_filter_boolean_mask): # use NXcs_filterneeds conditionally an instance of concept ../../hit_finding + # number_of_objects(NX_UINT): + # bitdepth(NX_UINT): + # mask(NX_UINT): + # identifier(NX_INT): - voltage_and_bowl_correction(NXprocess): + voltage_and_bowl(NXapm_volt_and_bowl): exists: optional sequence_index(NX_POSINT): exists: recommended @@ -236,12 +644,12 @@ NXapm(NXapm_base): # 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): - dim: (n_ions,) + dim: (n,) # result calibrated_tof(NX_FLOAT): - dim: (n_ions,) + dim: (n,) - mass_to_charge_conversion(NXprocess): + mass_to_charge_conversion(NXapm_mass_to_charge): exists: recommended sequence_index(NX_POSINT): exists: recommended @@ -250,6 +658,7 @@ NXapm(NXapm_base): program(NX_CHAR): \@version(NX_CHAR): (NXserialized): + exists: recommended type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): @@ -257,7 +666,7 @@ NXapm(NXapm_base): mass_to_charge(NX_FLOAT): dim: (n_ions,) - reconstruction(NXprocess): + reconstruction(NXapm_reconstruction): exists: recommended sequence_index(NX_POSINT): exists: recommended @@ -301,7 +710,7 @@ NXapm(NXapm_base): dim: (n_x,) \@long_name(NX_CHAR): - ranging(NXprocess): + ranging(NXapm_ranging): exists: recommended sequence_index(NX_POSINT): exists: recommended @@ -350,7 +759,8 @@ NXapm(NXapm_base): \@version(NX_CHAR): # config/input # results - # NEW ISSUE: add parameters of the background model in an e.g. work of A. London et al. + # NEW ISSUE: add parameters of the background model + # in an e.g. work of A. London et al. peak_search(NXprocess): exists: recommended From 7e4be9b620e6bc7d8805ea29f91980b095a67890 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 5 Jan 2024 22:57:30 +0100 Subject: [PATCH 0433/1012] Editing NXapm_ranging remains and a final check of the NXapm_new, then NXapm can be removed --- .../refactor/NXapm_charge_state_analysis.yaml | 85 +++++++++++-------- .../nyaml/refactor/NXapm_hit_finding.yaml | 70 +++++++++++++++ .../nyaml/refactor/NXapm_reconstruction.yaml | 57 ++++++++++++- .../nyaml/refactor/NXapm_volt_and_bowl.yaml | 30 +++++++ .../nyaml/refactor/Nxapm_new.yaml | 49 +++++------ .../{ => deprecate}/NXapm_mass_to_charge.yaml | 0 6 files changed, 228 insertions(+), 63 deletions(-) rename contributed_definitions/nyaml/refactor/{ => deprecate}/NXapm_mass_to_charge.yaml (100%) diff --git a/contributed_definitions/nyaml/refactor/NXapm_charge_state_analysis.yaml b/contributed_definitions/nyaml/refactor/NXapm_charge_state_analysis.yaml index 8ea0abb3c2..9dceb972bf 100644 --- a/contributed_definitions/nyaml/refactor/NXapm_charge_state_analysis.yaml +++ b/contributed_definitions/nyaml/refactor/NXapm_charge_state_analysis.yaml @@ -2,20 +2,20 @@ category: base doc: | Base class to document an algorithm for recovering charge state and nuclid composition of a (molecular) ion. - Currently used ranging definitions in the field of atom probe tomography face too problems: - These definitions specify what are tags apply for all (molecular) ions with a mass-to-charge-state-ratio - value within a specifed interval. Facing limited mass-resolving-power there are mass-to-charge-state-ratio - values for which not only multiple (molecular) ions are indistinguishable but also the current documentation - practice of classical ranging definitions is incomplete. + Currently ranging definitions in the research field of atom probe face have limitations: - Usually ranging definitions report exclusively the mass-to-charge-state-ratio intervals - surplus for each interval the composition of elements that build the (molecular) ion. - However, nuclid and charge state information is not necessarily reported. + 1. A ranging definition maps all signal within a mass-to-charge-state-ratio value interval + on one iontype. Facing limited mass-resolving-power there are mass-to-charge-state-ratio + values, though, for which not only multiple (molecular) ions are indistinguishable but + also for which the current practice of documenting classical ranging definitions is incomplete. + 2. Usually ranging definitions report exclusively the mass-to-charge-state-ratio intervals + surplus for each interval the composition of elements that build the (molecular) ion. + However, nuclid and charge state information is not necessarily reported. + 3. Therefore, classical ranging definitions demand a post-processing with an algorithm + which can identify the nuclids from which the (molecular) ion is constructed and identify + the charge state. Combinatorial algorithms are used for this purpose. - Therefore, classical ranging definitions demand a post-processing with an algorithm - which can identify the possible nuclid composition and thus the possible charge state - if the (molecular) ion is indeed a candidate. Combinatorial algorithms are used for this - purpose. This base class documents the parameter and results of such an algorithm. + This base class documents the parameter and results of such an algorithm. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -30,59 +30,70 @@ NXapm_charge_state_analysis(NXprocess): to clarify (if possible) the charge_state of an ion and its (not necessarily) unique combination of nuclids contained including their multiplicity. # input/config - # element_vector(NX_UINT): + element_vector(NX_UINT): + doc: | + Input constraint, list of proton numbers for each element of the ranging + definition. The list contains each element as many times as its multiplicity. + As an example a ranging definition H:2 O:1 demands element vector + to be 1, 1, 8. An empty list does not release the constraint. + Instead, for this a list for all elements of the periodic table should be + used. Keep in mind though with such a low constraint the parameter space + is huge and thus the combinatorial analysis can become time consuming. + unit: NX_UNITLESS + dim: (i,) mass_to_charge_range(NX_FLOAT): doc: | - Input constraint, interval within which (molecular) ions need to have their - mass-to-charge-state-ratio such that the ion qualifies as a candidate. + Input constraint, interval within which (molecular) ions need to have the + mass-to-charge-state-ratio such that the a ion qualifies as a candidate. unit: NX_ANY # u dim: (1, 2) min_half_life(NX_FLOAT): doc: | - Input constraint, minimum half life for how long each nuclid of each (molecular) ion - needs to be stable such that the ion qualifies as a candidate. + Input constraint, minimum half life for how long each nuclid of each (molecular) + ion needs to be stable such that the ion qualifies as a candidate. unit: NX_TIME min_abundance(NX_FLOAT): doc: | - Input constraint, minimum natural abundance of each nuclid of each (molecular) ion - such that the ion qualifies as a candidate. + Input constraint, minimum natural abundance of each nuclid of each (molecular) + ion such that the ion qualifies as a candidate. unit: NX_DIMENSIONLESS - dim: (n_combinatorics,) sacrifice_isotopic_uniqueness(NX_BOOLEAN): doc: | If the value is zero/false it means that non-unique solutions are accepted. - These are solutions where multiple candidates may differ in their isotopes but - have the same charge. + These are solutions where multiple candidates may be build from different + nuclids but the charge_state of all of them is the same. + # min_abundance_product(NX_FLOAT): + # doc: | + # For each candidate TO BE DEFINED. + # unit: NX_DIMENSIONLESS + # dim: (n_cand,) # output/results - # the n_combinatorics can be 1 in which case all quantities below are scalar + # the n_cand can be 1 in which case all quantities below are scalar charge_state_vector(NX_INT): doc: | Charge state, i.e. integer multiple of the elementary charge. unit: NX_UNITLESS - dim: (n_combinatorics,) + dim: (n_cand,) isotope_matrix(NX_UINT): doc: | - Specific nuclids building each candidate. + List of nuclids building each candidate. + Each list is sorted in descending order. + Unused values up to n_ivec_max are zero-padded. unit: NX_UNITLESS - dim: (n_combinatorics, n_ivec_max) + dim: (n_cand, n_ivec_max) mass_vector(NX_FLOAT): doc: | - Accumulated mass of the isotopes in each candidate. + Accumulated mass of the nuclids in each candidate. Not corrected for quantum effects. unit: NX_MASS - dim: (n_combinatorics,) + dim: (n_cand,) natural_abundance_product_vector(NX_FLOAT): doc: | - For each candidate the product of the natural abundances over the nuclids. - unit: NX_DIMENSIONLESS - dim: (n_combinatorics,) - min_abundance_product(NX_FLOAT): - doc: | - For each candidate TO BE DEFINED. + The product of the natural abundances of the nuclids for each candidate. unit: NX_DIMENSIONLESS - dim: (n_combinatorics,) + dim: (n_cand,) min_half_life_vector(NX_FLOAT): doc: | - For each candidate the half life of the nuclid with the smallest half_life. + For each candidate the half life of the nuclid with the shortst half life. unit: NX_TIME - dim: (n_combinatorics,) + dim: (n_cand,) diff --git a/contributed_definitions/nyaml/refactor/NXapm_hit_finding.yaml b/contributed_definitions/nyaml/refactor/NXapm_hit_finding.yaml index 44904b5cb4..40a3b154a2 100644 --- a/contributed_definitions/nyaml/refactor/NXapm_hit_finding.yaml +++ b/contributed_definitions/nyaml/refactor/NXapm_hit_finding.yaml @@ -1,5 +1,75 @@ category: base doc: | Base class for collecting the configuration and results from a hit finding algorithm. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_dld: | + Number of delay-line wires of the detector. + p: | + Number of pulses collected in between start_time and end_time + resolved by an instance of :ref:`NXevent_data_apm`. + + If this is not defined, p is the number of ions included in the reconstructed + volume if the application definition is used to store results of already + reconstructed datasets. type: group NXapm_hit_finding(NXprocess): # when evolving these ideas further inherit from NXapm_method instead + (NXprogram): + (NXserialized): + # config/input + number_of_dld_wires(NX_UINT): + doc: | + The number of wires in the detector. + unit: NX_UNITLESS + enumeration: [1, 2, 3] + dld_wire_names(NX_CHAR): + doc: | + Alias tuple (begin, end) of each DLD wire of the detector. + Order follows arrival_time_pairs. + dim: (n_dld, 2) + arrival_time_pairs(NX_NUMBER): + doc: | + Raw readings from the analog-to-digital-converter + timing circuits of the detector wires. + unit: NX_TIME + dim: (p, n_dld, 2) + # results of the hit_finding algorithm + hit_positions(NX_NUMBER): + doc: | + Evaluated ion impact coordinates on the detector. + Use the depends_on field to spec + unit: NX_LENGTH + dim: (p, 2) + \@depends_on(NX_CHAR): + doc: | + The instance of :ref:`NXcoordinate_system` in which + the positions are defined. + hit_quality(NX_UINT): + doc: | + Hit category, AMETEK/Cameca uses golden, partial, incomplete. + unit: NX_UNITLESS + dim: (p,) + hit_multiplicity(NX_UINT): + doc: | + Information if that eventData 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 of the same element + a molecular ion contains (which is instead encoded with the + isotope_vector field of each NXion instance). + unit: NX_UNITLESS + dim: (p,) + # the following two quantities are relicts from ePOS files used to give some + # insight into the results of the hit_finding algorithm of IVAS/APSuite but typically + # used only in the context to learn about the multiplicity of an ion. + # pulses_since_last_ion(NX_UINT): + # dim: (n,) + # pulse_identifier(NX_INT): + # dim: (n,) diff --git a/contributed_definitions/nyaml/refactor/NXapm_reconstruction.yaml b/contributed_definitions/nyaml/refactor/NXapm_reconstruction.yaml index 44904b5cb4..f5ebf48d56 100644 --- a/contributed_definitions/nyaml/refactor/NXapm_reconstruction.yaml +++ b/contributed_definitions/nyaml/refactor/NXapm_reconstruction.yaml @@ -1,5 +1,58 @@ category: base doc: | - Base class for collecting the configuration and results from a hit finding algorithm. + Base class for collecting the configuration and results + from a (static) reconstruction algorithm. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n: | + Number of ions spatially filtered from results of the hit_finding algorithm + from which an instance of a reconstructed volume has been generated. + These ions get new identifier assigned in the process, this is the so-called + evaporation_identifier that is not to be confused with the pulse_identifier! type: group -NXapm_hit_finding(NXprocess): # when evolving these ideas further inherit from NXapm_method instead +NXapm_reconstruction(NXprocess): # when evolving these ideas further inherit from NXapm_method instead + 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 above-mentioned input data. + (NXprogram): + (NXserialized): + # config/input + protocol_name(NX_CHAR): + doc: | + Qualitative statement about which reconstruction protocol was used. + enumeration: [bas, geiser, gault, cameca, other] + crystallographic_calibration(NX_CHAR): + doc: | + Different strategies for crystallographic calibration of the + reconstruction are possible. Therefore, we collect first such + feedback before parameterizing this further. + + If the not crystallographic calibration was performed the field + should be filled with the n/a, meaning not applied. + # results + 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 + dim: (n, 3) + \@depends_on(NX_CHAR): + doc: | + The instance of :ref:`NXcoordinate_system` + in which the positions are defined. + naive_discretization(NXprocess): + (NXprogram): + # config/input + # results + (NXdata): + doc: | + To get a first 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. diff --git a/contributed_definitions/nyaml/refactor/NXapm_volt_and_bowl.yaml b/contributed_definitions/nyaml/refactor/NXapm_volt_and_bowl.yaml index d35274eb40..802753c02e 100644 --- a/contributed_definitions/nyaml/refactor/NXapm_volt_and_bowl.yaml +++ b/contributed_definitions/nyaml/refactor/NXapm_volt_and_bowl.yaml @@ -1,5 +1,35 @@ category: base doc: | Base class for collecting the configuration and results from a voltage and bowl ToF correction algorithm. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n: | + Number of ions spatially filtered from results of the hit_finding algorithm + from which an instance of a reconstructed volume has been generated. + These ions get new identifier assigned in the process, this is the so-called + evaporation_identifier that is not to be confused with the pulse_identifier! type: group NXapm_volt_and_bowl(NXprocess): # when evolving these ideas further inherit from NXapm_method instead + 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. + (NXprogram): + (NXserialized): + # config/input to the algorithm + # 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 + # result + raw_tof(NX_FLOAT): + doc: | + Raw time-of-flight data without corrections. + unit: NX_TIME + dim: (i,) + calibrated_tof(NX_FLOAT): + doc: | + Calibrated time-of-flight. + unit: NX_TIME + dim: (n,) diff --git a/contributed_definitions/nyaml/refactor/Nxapm_new.yaml b/contributed_definitions/nyaml/refactor/Nxapm_new.yaml index 74bed3f248..f4dbbf4838 100644 --- a/contributed_definitions/nyaml/refactor/Nxapm_new.yaml +++ b/contributed_definitions/nyaml/refactor/Nxapm_new.yaml @@ -555,10 +555,6 @@ NXapm(NXobject): checksum(NX_CHAR): algorithm(NX_CHAR): number_of_dld_wires(NX_UINT): - doc: | - The number of wires in the detected. - unit: NX_UNITLESS - enumeration: [1, 2, 3] arrival_time_pairs(NX_NUMBER): # results of the hit_finding algorithm hit_positions(NX_NUMBER): @@ -572,12 +568,12 @@ NXapm(NXobject): # the following two quantities are relicts from ePOS files used to give some # insight into the results of the hit_finding algorithm of IVAS/APSuite but typically # used only in the context to learn about the multiplicity of an ion. - pulses_since_last_ion(NX_UINT): - exists: optional - dim: (i,) - pulse_identifier(NX_INT): # this is the pulse on which they came - exists: optional - dim: (i,) + # pulses_since_last_ion(NX_UINT): + # exists: optional + # dim: (i,) + # pulse_identifier(NX_INT): # this is the pulse on which they came + # exists: optional + # dim: (i,) # i number of hits after hits finding but prior calibrations hit_spatial_filtering(NXprocess): @@ -618,12 +614,14 @@ NXapm(NXobject): and spatial filtering was applied. unit: NX_UNITLESS dim: (n,) - # hit_filter(NXcs_filter_boolean_mask): # use NXcs_filterneeds conditionally an instance of concept ../../hit_finding - # number_of_objects(NX_UINT): - # bitdepth(NX_UINT): - # mask(NX_UINT): - # identifier(NX_INT): + hit_filter(NXcs_filter_boolean_mask): + # use NXcs_filterneeds conditionally an instance of concept ../../hit_finding + number_of_objects(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + identifier(NX_INT): + # at this point the original set of events p has been filtered down to n voltage_and_bowl(NXapm_volt_and_bowl): exists: optional sequence_index(NX_POSINT): @@ -649,7 +647,7 @@ NXapm(NXobject): calibrated_tof(NX_FLOAT): dim: (n,) - mass_to_charge_conversion(NXapm_mass_to_charge): + mass_to_charge_conversion(NXprocess): exists: recommended sequence_index(NX_POSINT): exists: recommended @@ -663,8 +661,10 @@ NXapm(NXobject): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): + # config/input + # results mass_to_charge(NX_FLOAT): - dim: (n_ions,) + dim: (n,) reconstruction(NXapm_reconstruction): exists: recommended @@ -674,17 +674,18 @@ NXapm(NXobject): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): + (NXserialized): + exists: recommended + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): # config/input protocol_name(NX_CHAR): - doc: | - Qualitative statement about which reconstruction protocol was used. - enumeration: [bas, geiser, gault, cameca, other] crystallographic_calibration(NX_CHAR): reconstructed_positions(NX_FLOAT): - dim: (n_ions, 3) + dim: (n, 3) naive_discretization(NXprocess): - sequence_index(NX_POSINT): - exists: recommended (NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): @@ -695,7 +696,7 @@ NXapm(NXobject): \@signal(NX_CHAR): \@axes(NX_CHAR): \@AXISNAME_indices(NX_CHAR): - dim: (i,) + # dim: (3,) # \@long_name: title(NX_CHAR): intensity(NX_NUMBER): diff --git a/contributed_definitions/nyaml/refactor/NXapm_mass_to_charge.yaml b/contributed_definitions/nyaml/refactor/deprecate/NXapm_mass_to_charge.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXapm_mass_to_charge.yaml rename to contributed_definitions/nyaml/refactor/deprecate/NXapm_mass_to_charge.yaml From 373da83df68580df99575beed0d62451c0d018f8 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 5 Jan 2024 23:21:05 +0100 Subject: [PATCH 0434/1012] Refactored NXapm_ranging, renamed NXapm_new, a through and complete check remains, NXsimilarity_grouping to edit --- .../nyaml/refactor/NXapm_ranging.yaml | 66 +++++++++++++++++++ .../nyaml/refactor/NXapm_ranging.yaml.yml | 5 -- .../refactor/{Nxapm_new.yaml => Nxapm.yaml} | 7 +- .../nyaml/refactor/{ => deprecate}/NXapm.yaml | 0 .../{ => deprecate}/find_a_place_in_nxapm.txt | 0 5 files changed, 67 insertions(+), 11 deletions(-) create mode 100644 contributed_definitions/nyaml/refactor/NXapm_ranging.yaml delete mode 100644 contributed_definitions/nyaml/refactor/NXapm_ranging.yaml.yml rename contributed_definitions/nyaml/refactor/{Nxapm_new.yaml => Nxapm.yaml} (99%) rename contributed_definitions/nyaml/refactor/{ => deprecate}/NXapm.yaml (100%) rename contributed_definitions/nyaml/refactor/{ => deprecate}/find_a_place_in_nxapm.txt (100%) diff --git a/contributed_definitions/nyaml/refactor/NXapm_ranging.yaml b/contributed_definitions/nyaml/refactor/NXapm_ranging.yaml new file mode 100644 index 0000000000..890591aea1 --- /dev/null +++ b/contributed_definitions/nyaml/refactor/NXapm_ranging.yaml @@ -0,0 +1,66 @@ +category: base +doc: | + Base class for collecting the configuration and results from tomographic reconstruction algorithm. +type: group +NXapm_ranging(NXprocess): # when evolving these ideas further inherit from NXapm_method instead + doc: | + Data post-processing step in which elemental, isotopic, + and/or molecular identities are assigned to mass-to-charge-state-ratios + within a certain interval. The documentation of these steps is based on + ideas that have been described in the literature: + + * `M. K. Miller `_ + * `D. Haley et al. `_ + * `M. Kühbach et al. `_ + + (NXprogram): + 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 (see M. Kühbach et al. `_). + unit: NX_UNITLESS + + mass_to_charge_distribution(NXprocess): + doc: | + Specifies the mass-to-charge-state-ratio histogram. + (NXprogram): + min_incr_max(NX_FLOAT): + doc: | + Smallest, increment, and largest mass-to-charge-state ratio value. + unit: NX_ANY # u + dim: (3,) + mass_spectrum(NXdata): + doc: | + A default histogram aka mass spectrum of + the mass-to-charge-state ratio values. + + background_quantification(NXprocess): + doc: | + Details of the background model which was used to + correct the total counts per bin into counts. + (NXprogram): + # NEW ISSUE: add parameters of the background model in an e.g. + # NXcollection as these are specific to every background model + # NEW ISSUE: touching upon i.e. research activities by Andrew London et al. + # substantiating the need for a clearer description how peak/signals were + # eventually processed via deconvolution methods + + peak_search_and_deconvolution(NXprocess): + doc: | + How where peaks in the background-corrected in the histogram + of mass-to-charge-state ratio values identified? + (NXprogram): + (NXpeak): + peak_identification(NXprocess): + doc: | + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + (NXprogram): + (NXion): diff --git a/contributed_definitions/nyaml/refactor/NXapm_ranging.yaml.yml b/contributed_definitions/nyaml/refactor/NXapm_ranging.yaml.yml deleted file mode 100644 index e5db027aee..0000000000 --- a/contributed_definitions/nyaml/refactor/NXapm_ranging.yaml.yml +++ /dev/null @@ -1,5 +0,0 @@ -category: base -doc: | - Base class for collecting the configuration and results from tomographic reconstruction algorithm. -type: group -NXapm_ranging(NXprocess): # when evolving these ideas further inherit from NXapm_method instead diff --git a/contributed_definitions/nyaml/refactor/Nxapm_new.yaml b/contributed_definitions/nyaml/refactor/Nxapm.yaml similarity index 99% rename from contributed_definitions/nyaml/refactor/Nxapm_new.yaml rename to contributed_definitions/nyaml/refactor/Nxapm.yaml index f4dbbf4838..74f2e4f9cf 100644 --- a/contributed_definitions/nyaml/refactor/Nxapm_new.yaml +++ b/contributed_definitions/nyaml/refactor/Nxapm.yaml @@ -724,11 +724,6 @@ NXapm(NXobject): 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. sequence_index(NX_POSINT): exists: recommended (NXprogram): @@ -736,7 +731,7 @@ NXapm(NXobject): program(NX_CHAR): \@version(NX_CHAR): min_incr_max(NX_FLOAT): - dim: (3,) # u + # dim: (3,) # u mass_spectrum(NXdata): \@signal(NX_CHAR): \@axes(NX_CHAR): diff --git a/contributed_definitions/nyaml/refactor/NXapm.yaml b/contributed_definitions/nyaml/refactor/deprecate/NXapm.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXapm.yaml rename to contributed_definitions/nyaml/refactor/deprecate/NXapm.yaml diff --git a/contributed_definitions/nyaml/refactor/find_a_place_in_nxapm.txt b/contributed_definitions/nyaml/refactor/deprecate/find_a_place_in_nxapm.txt similarity index 100% rename from contributed_definitions/nyaml/refactor/find_a_place_in_nxapm.txt rename to contributed_definitions/nyaml/refactor/deprecate/find_a_place_in_nxapm.txt From df219e8149fe754f85e735a9ab3b3d38580deef4 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Sat, 6 Jan 2024 19:13:58 +0100 Subject: [PATCH 0435/1012] Reviewing, fixing typos, a minor glitches --- .../nyaml/refactor/{Nxapm.yaml => NXapm.yaml} | 0 .../refactor/NXapm_charge_state_analysis.yaml | 50 +++++++++---------- .../nyaml/refactor/NXapm_hit_finding.yaml | 22 +++----- .../refactor/NXapm_paraprobe_tool_config.yaml | 15 +++--- .../NXapm_paraprobe_tool_results.yaml | 21 ++++---- .../nyaml/refactor/NXapm_ranging.yaml | 23 ++++++--- .../nyaml/refactor/NXapm_reconstruction.yaml | 29 ++++++----- .../nyaml/refactor/NXapm_sim.yaml | 23 +++++---- .../nyaml/refactor/NXapm_volt_and_bowl.yaml | 9 ++-- .../nyaml/refactor/NXcg_marching_cubes.yaml | 31 ++++++------ .../refactor/NXcs_filter_boolean_mask.yaml | 32 ++++++------ .../nyaml/refactor/NXdelocalization.yaml | 16 +++--- .../nyaml/refactor/NXevent_data_apm_set.yaml | 14 +++--- .../nyaml/refactor/NXion.yaml | 33 ++++++------ .../nyaml/refactor/NXisocontour.yaml | 8 +-- .../nyaml/refactor/NXmatch_filter.yaml | 4 +- .../nyaml/refactor/NXpeak.yaml | 2 +- .../nyaml/refactor/NXreflectron.yaml | 12 ++--- .../nyaml/refactor/NXspatial_filter.yaml | 15 +++--- .../nyaml/refactor/NXsubsampling_filter.yaml | 17 ++++--- 20 files changed, 188 insertions(+), 188 deletions(-) rename contributed_definitions/nyaml/refactor/{Nxapm.yaml => NXapm.yaml} (100%) diff --git a/contributed_definitions/nyaml/refactor/Nxapm.yaml b/contributed_definitions/nyaml/refactor/NXapm.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/Nxapm.yaml rename to contributed_definitions/nyaml/refactor/NXapm.yaml diff --git a/contributed_definitions/nyaml/refactor/NXapm_charge_state_analysis.yaml b/contributed_definitions/nyaml/refactor/NXapm_charge_state_analysis.yaml index 9dceb972bf..b8d5ca2717 100644 --- a/contributed_definitions/nyaml/refactor/NXapm_charge_state_analysis.yaml +++ b/contributed_definitions/nyaml/refactor/NXapm_charge_state_analysis.yaml @@ -5,17 +5,18 @@ doc: | Currently ranging definitions in the research field of atom probe face have limitations: 1. A ranging definition maps all signal within a mass-to-charge-state-ratio value interval - on one iontype. Facing limited mass-resolving-power there are mass-to-charge-state-ratio + on one iontype. Facing limited mass-resolving-power, there are mass-to-charge-state-ratio values, though, for which not only multiple (molecular) ions are indistinguishable but also for which the current practice of documenting classical ranging definitions is incomplete. - 2. Usually ranging definitions report exclusively the mass-to-charge-state-ratio intervals - surplus for each interval the composition of elements that build the (molecular) ion. - However, nuclid and charge state information is not necessarily reported. + 2. Indeed, ranging definitions often report only (for each interval) the + mass-to-charge-state-ratio intervals surplus the composition of elements + that build the (molecular) ion. 3. Therefore, classical ranging definitions demand a post-processing with an algorithm - which can identify the nuclids from which the (molecular) ion is constructed and identify - the charge state. Combinatorial algorithms are used for this purpose. + which can identify the nuclids from which the (molecular) ion is constructed + and a charge state possibly recovered. + Combinatorial algorithms are used for this purpose. - This base class documents the parameter and results of such an algorithm. + This base class documents the configuration and results of such an algorithm. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -25,10 +26,9 @@ symbols: Maximum number of allowed atoms per (molecular) ion (fragment). type: group NXapm_charge_state_analysis(NXprocess): - doc: | - Details and results of the combinatorial analyses of a ranging definition - to clarify (if possible) the charge_state of an ion and its (not necessarily) - unique combination of nuclids contained including their multiplicity. + # Details and results of the combinatorial analyses of a ranging definition + # to clarify (if possible) the charge_state of an ion and its (not necessarily) + # unique combination of nuclids contained including their multiplicity. # input/config element_vector(NX_UINT): doc: | @@ -36,32 +36,32 @@ NXapm_charge_state_analysis(NXprocess): definition. The list contains each element as many times as its multiplicity. As an example a ranging definition H:2 O:1 demands element vector to be 1, 1, 8. An empty list does not release the constraint. - Instead, for this a list for all elements of the periodic table should be - used. Keep in mind though with such a low constraint the parameter space - is huge and thus the combinatorial analysis can become time consuming. + Instead, a list with all elements in the periodic table should be + used. Keep in mind though with such a weakly constrained parameter space + the combinatorial analysis may become very time consuming! unit: NX_UNITLESS dim: (i,) mass_to_charge_range(NX_FLOAT): doc: | Input constraint, interval within which (molecular) ions need to have the - mass-to-charge-state-ratio such that the a ion qualifies as a candidate. + mass-to-charge-state-ratio such that an ion qualifies as a candidate. unit: NX_ANY # u dim: (1, 2) min_half_life(NX_FLOAT): doc: | - Input constraint, minimum half life for how long each nuclid of each (molecular) - ion needs to be stable such that the ion qualifies as a candidate. + Input constraint, minimum half life for how long each nuclid of each + (molecular) ion needs to be stable such that the ion qualifies as a candidate. unit: NX_TIME min_abundance(NX_FLOAT): doc: | - Input constraint, minimum natural abundance of each nuclid of each (molecular) - ion such that the ion qualifies as a candidate. + Input constraint, minimum natural abundance of each nuclid of each + (molecular) ion such that the ion qualifies as a candidate. unit: NX_DIMENSIONLESS sacrifice_isotopic_uniqueness(NX_BOOLEAN): doc: | - If the value is zero/false it means that non-unique solutions are accepted. - These are solutions where multiple candidates may be build from different - nuclids but the charge_state of all of them is the same. + If the value is false, it means that non-unique solutions are accepted. + These are solutions where multiple candidates have been built from different + nuclids but the charge_state of all the ions is the same. # min_abundance_product(NX_FLOAT): # doc: | # For each candidate TO BE DEFINED. @@ -71,14 +71,14 @@ NXapm_charge_state_analysis(NXprocess): # the n_cand can be 1 in which case all quantities below are scalar charge_state_vector(NX_INT): doc: | - Charge state, i.e. integer multiple of the elementary charge. + Signed charge, i.e. integer multiple of the elementary charge. unit: NX_UNITLESS dim: (n_cand,) isotope_matrix(NX_UINT): doc: | List of nuclids building each candidate. Each list is sorted in descending order. - Unused values up to n_ivec_max are zero-padded. + Unused values up to n_ivec_max are nullified. unit: NX_UNITLESS dim: (n_cand, n_ivec_max) mass_vector(NX_FLOAT): @@ -94,6 +94,6 @@ NXapm_charge_state_analysis(NXprocess): dim: (n_cand,) min_half_life_vector(NX_FLOAT): doc: | - For each candidate the half life of the nuclid with the shortst half life. + For each candidate the half life of the nuclid with the shortest half life. unit: NX_TIME dim: (n_cand,) diff --git a/contributed_definitions/nyaml/refactor/NXapm_hit_finding.yaml b/contributed_definitions/nyaml/refactor/NXapm_hit_finding.yaml index 40a3b154a2..12cc6ec9e6 100644 --- a/contributed_definitions/nyaml/refactor/NXapm_hit_finding.yaml +++ b/contributed_definitions/nyaml/refactor/NXapm_hit_finding.yaml @@ -1,6 +1,6 @@ category: base doc: | - Base class for collecting the configuration and results from a hit finding algorithm. + Base class for the configuration and results from a hit finding algorithm. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -11,7 +11,7 @@ symbols: resolved by an instance of :ref:`NXevent_data_apm`. If this is not defined, p is the number of ions included in the reconstructed - volume if the application definition is used to store results of already + volume if an application definition is used to store results of already reconstructed datasets. type: group NXapm_hit_finding(NXprocess): # when evolving these ideas further inherit from NXapm_method instead @@ -43,27 +43,21 @@ NXapm_hit_finding(NXprocess): # when evolving these ideas further inherit from dim: (p, 2) \@depends_on(NX_CHAR): doc: | - The instance of :ref:`NXcoordinate_system` in which - the positions are defined. + The instance of :ref:`NXcoordinate_system` in which the positions are defined. hit_quality(NX_UINT): doc: | - Hit category, AMETEK/Cameca uses golden, partial, incomplete. + Hit category, AMETEK/Cameca uses e.g. golden, partial, incomplete. unit: NX_UNITLESS dim: (p,) hit_multiplicity(NX_UINT): doc: | - Information if that eventData 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. + This processing yields for each ion with how many others it evaporated + if these were collected on the same pulse. Extraction of multiple ions + on one pulse on different or even the same pixel of the detector are possible. Multiplicity must not be confused with how many atoms of the same element a molecular ion contains (which is instead encoded with the - isotope_vector field of each NXion instance). + isotope_vector field of each :ref:`NXion` instance). unit: NX_UNITLESS dim: (p,) # the following two quantities are relicts from ePOS files used to give some diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_tool_config.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_tool_config.yaml index cd07535dc7..737ffb2ccf 100644 --- a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_tool_config.yaml +++ b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_tool_config.yaml @@ -44,7 +44,7 @@ NXapm_paraprobe_tool_config(NXprocess): doc: | Metadata of the computational process whereby this configuration was generated. There is a special set of tools called paraprobe-parmsetup which can be used - to conveniently create configuration file instances. + to conveniently create HDF5 configuration files, i.e. instances. results_path(NX_CHAR): doc: | Path where the tool stores tool-specific results. If not specified, @@ -66,8 +66,8 @@ NXapm_paraprobe_tool_config(NXprocess): Typically, reconstructions in the field of atom probe tomography are communicated via files which store at least reconstructed ion positions and mass-to-charge-state-ratio - values. Container files like HDF5 though can store multiple reconstructions. Therefore, - the position and mass_to_charge concepts point to specific instances + values. Container files like HDF5 though can store multiple reconstructions. + Therefore, the position and mass_to_charge concepts point to specific instances to use for this analysis. position(NX_CHAR): doc: | @@ -81,10 +81,10 @@ NXapm_paraprobe_tool_config(NXprocess): doc: | Specification of the ranging definitions to use for this analysis. - Ranging is the process of labeling time-of-flight data with so-called iontypes (aka ion species). - Ideally, iontypes specify the most likely (molecular) ion that is assumed to have - been evaporated given that its mass-to-charge-state ratio lays within the specific - mass-to-charge-state-ratio value interval of the iontype. + Ranging is the process of labeling time-of-flight data with so-called iontypes + (aka ion species). Ideally, iontypes specify the most likely (molecular) ion + that is assumed to have been evaporated given that its mass-to-charge-state ratio + lies within the specific mass-to-charge-state-ratio value interval of the iontype. The so-called UNKNOWNTYPE iontype represents the null model of an ion that has not been ranged (for whatever reasons). @@ -93,4 +93,3 @@ NXapm_paraprobe_tool_config(NXprocess): doc: | Name of the (parent) node directly below which (in the hierarchy) the ranging definition for (molecular) ions are stored. - diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_tool_results.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_tool_results.yaml index 6a2587b998..be8bb3c342 100644 --- a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_tool_results.yaml +++ b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_tool_results.yaml @@ -54,21 +54,21 @@ NXapm_paraprobe_tool_results(NXprocess): completed and the respective process of the tool exited. status(NX_CHAR): doc: | - A statement whether the tool executable managed to process - the analysis or whether this failed. Status is written to the results - file after the end_time beyond which point in time the tool must - no longer compute any further analysis results but exit. + A statement whether the tool executable managed to process the analysis + or whether this failed. Status is written to the results file after the + end_time beyond which point in time the tool must no longer compute + any further analysis results but exit. Only when this status message is present and its value is `success`, - one should consider the results of the tool. In all other cases it might be - that the tool has terminated prematurely or another error occurred. + one should consider the results of the tool. In all other cases it might + b that the tool has terminated prematurely or another error occurred. enumeration: [success, failure] (NXuser): (NXcoordinate_system_set): doc: | Details about coordinate systems (reference frames) used. In atom probe several coordinate systems have to be distinguished. Names of instances of such :ref:`NXcoordinate_system` - should therefore be documented explicitly and doing so by picking from the + should be documented explicitly and doing so by picking from the following controlled set of names: * paraprobe @@ -80,9 +80,10 @@ NXapm_paraprobe_tool_results(NXprocess): * recon The aim of this convention is to support users with contextualizing which reference - frame each instance (coordinate system) is. If needed, instances of :ref:`NXtranslation` - are used to detail the explicit affine transformation matrices whereby one can convert - between different reference frames. Inspect NXtransformations for further details. + frame each instance (coordinate system) is. If needed, instances of :ref:`NXtranslations` + are used to detail the explicit affine transformations whereby one can convert + rpresentations between different reference frames. + Inspect :ref:`NXtransformations` for further details. (NXcoordinate_system): (NXtransformations): # add further fields coming from using the charge state recovery diff --git a/contributed_definitions/nyaml/refactor/NXapm_ranging.yaml b/contributed_definitions/nyaml/refactor/NXapm_ranging.yaml index 890591aea1..15f505f45d 100644 --- a/contributed_definitions/nyaml/refactor/NXapm_ranging.yaml +++ b/contributed_definitions/nyaml/refactor/NXapm_ranging.yaml @@ -1,13 +1,13 @@ category: base doc: | - Base class for collecting the configuration and results from tomographic reconstruction algorithm. + Base class for the configuration and results of ranging definitions. type: group NXapm_ranging(NXprocess): # when evolving these ideas further inherit from NXapm_method instead doc: | - Data post-processing step in which elemental, isotopic, - and/or molecular identities are assigned to mass-to-charge-state-ratios - within a certain interval. The documentation of these steps is based on - ideas that have been described in the literature: + Data post-processing step in which elemental, isotopic, and/or molecular + identities are assigned to mass-to-charge-state-ratios within a certain + interval. The documentation of these steps is based on ideas that + have been described in the literature: * `M. K. Miller `_ * `D. Haley et al. `_ @@ -16,9 +16,10 @@ NXapm_ranging(NXprocess): # when evolving these ideas further inherit from NXap (NXprogram): number_of_ion_types(NX_UINT): doc: | - How many ion types are distinguished. If no ranging was performed each + 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. + is 0 representing a reserve value. Consequently, + iontypes start counting from 1. unit: NX_UNITLESS maximum_number_of_atoms_per_molecular_ion(NX_UINT): doc: | @@ -43,9 +44,15 @@ NXapm_ranging(NXprocess): # when evolving these ideas further inherit from NXap background_quantification(NXprocess): doc: | - Details of the background model which was used to + Details of the background model that was used to correct the total counts per bin into counts. (NXprogram): + description(NX_CHAR): + doc: | + To begin with we use a free-text field to learn how + atom probers define a background model. Future versions + of NXapm_ranging can then use this information to parameterize + these models. # NEW ISSUE: add parameters of the background model in an e.g. # NXcollection as these are specific to every background model # NEW ISSUE: touching upon i.e. research activities by Andrew London et al. diff --git a/contributed_definitions/nyaml/refactor/NXapm_reconstruction.yaml b/contributed_definitions/nyaml/refactor/NXapm_reconstruction.yaml index f5ebf48d56..b875d3630e 100644 --- a/contributed_definitions/nyaml/refactor/NXapm_reconstruction.yaml +++ b/contributed_definitions/nyaml/refactor/NXapm_reconstruction.yaml @@ -1,25 +1,25 @@ category: base doc: | - Base class for collecting the configuration and results - from a (static) reconstruction algorithm. + Base class for the configuration and results of a (static) reconstruction algorithm. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. n: | Number of ions spatially filtered from results of the hit_finding algorithm - from which an instance of a reconstructed volume has been generated. - These ions get new identifier assigned in the process, this is the so-called - evaporation_identifier that is not to be confused with the pulse_identifier! + :ref:`NXapm_hit_finding` from which an instance of a reconstructed volume + has been generated. These ions get new identifier assigned in the process - + the so-called evaporation_identifier, which must not be confused with + the pulse_identifier! type: group -NXapm_reconstruction(NXprocess): # when evolving these ideas further inherit from NXapm_method instead +NXapm_reconstruction(NXprocess): + # when evolving these ideas further inherit from NXapm_method instead 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 above-mentioned input data. + published procedures, so-called reconstruction protocols how to + compute x, y, z atomic positions from the above-mentioned input data. (NXprogram): (NXserialized): # config/input @@ -33,13 +33,12 @@ NXapm_reconstruction(NXprocess): # when evolving these ideas further inherit fr reconstruction are possible. Therefore, we collect first such feedback before parameterizing this further. - If the not crystallographic calibration was performed the field + If no crystallographic calibration was performed, the field should be filled with the n/a, meaning not applied. # results 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 dim: (n, 3) \@depends_on(NX_CHAR): @@ -52,7 +51,7 @@ NXapm_reconstruction(NXprocess): # when evolving these ideas further inherit fr # results (NXdata): 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. + To get a first visual overview of the reconstructed dataset, + here a 3d histogram of the ion is stored. Ion counts are characterized + using one nanometer cubic bins without applying position smoothening + algorithms during the histogram computation. diff --git a/contributed_definitions/nyaml/refactor/NXapm_sim.yaml b/contributed_definitions/nyaml/refactor/NXapm_sim.yaml index 37df8ce2ac..d8741eab06 100644 --- a/contributed_definitions/nyaml/refactor/NXapm_sim.yaml +++ b/contributed_definitions/nyaml/refactor/NXapm_sim.yaml @@ -2,16 +2,17 @@ category: base doc: | Base class for simulating ion extraction from matter via laser and/or voltage pulsing. - Ideally, we would like to describe the workflow of experiments and simulations of atom probe and - field-evaporation simulation research in more detail and contextualize better descriptions of - experiments and computer simulations. The strategy is detailed in the introducing docstring - of :ref:`NXapm_msr`. This base class is envisioned as the twin of the :ref:`NXapm_msr` base class. -# noteworthy the situation is similar to electron microscopy especially transmission electron microscopy where factually -# interpretation without simulations is pointless. The only difference is that in electron microscopy there is a large availability -# of documentation and open-source tools for performing such simulations. + Ideally, we would like to describe the workflow of experiments and simulations of + atom probe and field-evaporation simulation research in more detail and contextualize + better descriptions of experiments and computer simulations. + The strategy to achieve this is detailed in the introducing docstring of + :ref:`NXapm_msr`. This :ref:`NXapm_sim` base class is envisioned as the + twin of the :ref:`NXapm_msr` base class. +# noteworthy the situation is similar to electron microscopy especially TEM where factually +# interpretation without simulations is pointless. The only difference is that in EM there +# is a large availability of documentation and open-source tools for performing such simulations. type: group NXapm_sim(NXobject): # when evolving these ideas further inherit from NXapm_method instead - doc: | - Details about the simulation. - # sequence_index(N): - (NXprogram): + doc: | + Details about the simulation. + (NXprogram): diff --git a/contributed_definitions/nyaml/refactor/NXapm_volt_and_bowl.yaml b/contributed_definitions/nyaml/refactor/NXapm_volt_and_bowl.yaml index 802753c02e..abe7132516 100644 --- a/contributed_definitions/nyaml/refactor/NXapm_volt_and_bowl.yaml +++ b/contributed_definitions/nyaml/refactor/NXapm_volt_and_bowl.yaml @@ -1,14 +1,15 @@ category: base doc: | - Base class for collecting the configuration and results from a voltage and bowl ToF correction algorithm. + Base class for the configuration and results from a voltage-and-bowl ToF correction algorithm. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. n: | Number of ions spatially filtered from results of the hit_finding algorithm - from which an instance of a reconstructed volume has been generated. - These ions get new identifier assigned in the process, this is the so-called - evaporation_identifier that is not to be confused with the pulse_identifier! + :ref:`NXapm_hit_finding` from which an instance of a reconstructed volume + has been generated. These ions get new identifier assigned in the process - + the so-called evaporation_identifier, which must not be confused with + the pulse_identifier! type: group NXapm_volt_and_bowl(NXprocess): # when evolving these ideas further inherit from NXapm_method instead doc: | diff --git a/contributed_definitions/nyaml/refactor/NXcg_marching_cubes.yaml b/contributed_definitions/nyaml/refactor/NXcg_marching_cubes.yaml index bf0e5047d2..8b9385ff28 100644 --- a/contributed_definitions/nyaml/refactor/NXcg_marching_cubes.yaml +++ b/contributed_definitions/nyaml/refactor/NXcg_marching_cubes.yaml @@ -1,8 +1,8 @@ category: base doc: | - Computational geometry description of the marching cubes (MC) algorithm. + Base class to detail the marching cubes (MC) algorithm. - Documenting which specific version was used helps with understanding + Documenting which specific version of MC was used helps with understanding how robust the results are with respect to the topology of the triangulation. # symbols: type: group @@ -10,21 +10,20 @@ NXcg_marching_cubes(NXobject): grid(NXcg_grid): doc: | Metadata of the grid on which the here specified MC is operating. - (NXidentifier): - doc: | - Reference to the specific implementation of marching cubes used. - - See for example the following papers for details about specific - MC implementations: - - * `W. E. Lorensen `_ - * `T. S. Newman and H. Yi `_ - - description(NX_CHAR): - doc: | - Free text field in case a proper identifier is not available. + (NXidentifier): + doc: | + Reference to the specific implementation of marching cubes used. + + See for example the following papers for details about specific + MC implementations: + + * `W. E. Lorensen `_ + * `T. S. Newman and H. Yi `_ + + description(NX_CHAR): + doc: | + Free text field in case a proper identifier is not available. (NXprogram): - # we could also think about storing the rule sets in here explicitly including the # coordinate system conventions; however, the problem is that many commercial # tools like Matlab do not expose the rule set. diff --git a/contributed_definitions/nyaml/refactor/NXcs_filter_boolean_mask.yaml b/contributed_definitions/nyaml/refactor/NXcs_filter_boolean_mask.yaml index 55563e5a1e..135f3c7282 100644 --- a/contributed_definitions/nyaml/refactor/NXcs_filter_boolean_mask.yaml +++ b/contributed_definitions/nyaml/refactor/NXcs_filter_boolean_mask.yaml @@ -6,28 +6,26 @@ doc: | operations to decode e.g. set membership of objects in sets which are encoded as a packed array of boolean values. - One use case is processing of object sets (point cloud data). When one applies - e.g. a spatial filter to a set of points to define which points are analyzed - and which not, one can store this information in a compact manner using an array - of boolean values. If the value is True the point is taken, otherwise the point - is not taken. - - The resulting boolean array will be filled with True and False in a manner - that is often arbitrary and in general case-dependent. + One use case is processing of object sets (e.g. point cloud data). If e.g. a + spatial filter has been applied to a set of points we may wish to store + document efficiently which points were analyzed. Array of boolean values + is one option to achieve this. A value is true if the point is included. + The resulting boolean array will be filled with true and false values + in a manner that is often arbitrary and in general case-dependent. Especially when the number of points is large, for instance several thousands - or more, some situations can be more efficiently stored if one would not store - the boolean array but just list the identifiers of the points taken. + or more, some situations can be more efficiently stored if one does not store + the boolean array but just lists the identifiers of the points taken. - For example, if within a set of 1000 points only one point is taken, it would + For example, if within a set of 1000 points only one point is included, it would take (naively) 4000 bits to store the array but only 32 bits to store e.g. the ID of the single point that is taken. Of course the 4000 bit field is so sparse that it could be compressed resulting also in a substantial reduction of the storage demands. Therefore, boolean masks are useful in that they store compact representation of set memberships. - The number of encoded pieces of information is not necessarily - an integer multiple of the bit depth. + This base class can deal with the situation when the number of objects + is not an integer multiple of the bit depth used for storing the states. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -56,15 +54,17 @@ NXcs_filter_boolean_mask(NXobject): unit: NX_UNITLESS mask(NX_UINT): doc: | - The content of the mask. If padding is used, padding bits have to be set to 0. - dim: (n_total,) + The content of the mask. If padding is used, + padding bits have to be set to 0. unit: NX_UNITLESS + dim: (n_total,) identifier(NX_INT): doc: | Link to/or array of identifiers for the objects. The decoded mask is interpreted consecutively, i.e. the first bit in the mask matches to the first identifier, the second bit in the mask to the second identifier and so on and so forth. Resolving of identifier follows - the conventions made for depends_on, so consult the also its description. + the conventions made for depends_on, so consult also the description + of th content to which depends_on refers. unit: NX_UNITLESS dim: (n_object,) diff --git a/contributed_definitions/nyaml/refactor/NXdelocalization.yaml b/contributed_definitions/nyaml/refactor/NXdelocalization.yaml index a25b57b091..ad7e3abfc6 100644 --- a/contributed_definitions/nyaml/refactor/NXdelocalization.yaml +++ b/contributed_definitions/nyaml/refactor/NXdelocalization.yaml @@ -1,10 +1,10 @@ category: base doc: | - Base class to describe settings and results of a delocalization algorithm. + Base class of the configuration and results of a delocalization algorithm. Delocalization is used to distribute point-like objects on a grid to obtain - e.g. count, composition, or concentration values of scalar fields and - compute gradients of these fields. + e.g. smoother count, composition, or concentration values of scalar fields + and compute gradients of these fields. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -18,7 +18,7 @@ symbols: Number of isotopes in the whitelist. type: group NXdelocalization(NXobject): - (NXcg_grid): + grid(NXcg_grid): doc: | Details about the grid on which the delocalization is applied. # grid(NX_CHAR): @@ -46,11 +46,11 @@ NXdelocalization(NXobject): account differently for the multiplicity of an ion/atom: * default, points all get the same weight 1.; - for APM this is equivalent to ion species based delocalization + for APM this is equivalent to (molecular) iontype-based delocalization * atomic_decomposition, points get as much weight as they have atoms of a type in element_whitelist, * isotope_decomposition, points get as much weight as they have - isotopes of a type in isotope_whitelist. + nuclids of a type in isotope_whitelist. This description shows an example that could be reinterpreted for similar such data processing steps in other fields of science. @@ -77,8 +77,8 @@ NXdelocalization(NXobject): mark(NX_NUMBER): doc: | Attribute data for each member of the point cloud. For APM these are the - ion species labels generated via ranging. The number of mark data per - point is 1 in the case for atom probe. + iontypes generated via ranging. The number of mark data per point is 1 + in the case for atom probe. unit: NX_UNITLESS dim: (n_p, n_m) weight(NX_NUMBER): diff --git a/contributed_definitions/nyaml/refactor/NXevent_data_apm_set.yaml b/contributed_definitions/nyaml/refactor/NXevent_data_apm_set.yaml index b460526fe9..61bf1db4d0 100644 --- a/contributed_definitions/nyaml/refactor/NXevent_data_apm_set.yaml +++ b/contributed_definitions/nyaml/refactor/NXevent_data_apm_set.yaml @@ -8,19 +8,19 @@ doc: | Which temporal granularity is adequate depends on the situation and research question. Using a model which enables a collection of events offers - the most flexible way to cater for both experiments with controlled electron - beams in a real microscope or the simulation of such experiments or - individual aspects of such experiments. + the most flexible way to cater for both atom probe experiments or the + simulation of such experiments. To monitor the course of an ion extraction experiment (or simulation) - it makes sense to track either time explicitly with time stamps or implicitly - via e.g. a clock inside the instrument, such as the clock of the pulser. + it makes sense to track time explicitly via time stamps or implicitly + via e.g. a clock inside the instrument, such as the clock of the pulser + and respective pulsing event identifier. As set and measured quantities typically change over time and we do not yet know during the measurement which of the events have associated - molecular ions that will end up in the reconstructed volume we must not + (molecular) ions that will end up in the reconstructed volume, we must not document quantities as a function of the evaporated_identifier but as a - function of the (pulsing)event_identifier. + function of the (pulsing) event_identifier. type: group NXevent_data_apm_set(NXobject): (NXevent_data_apm): diff --git a/contributed_definitions/nyaml/refactor/NXion.yaml b/contributed_definitions/nyaml/refactor/NXion.yaml index bd3cb7b6a9..0cdee1aa31 100644 --- a/contributed_definitions/nyaml/refactor/NXion.yaml +++ b/contributed_definitions/nyaml/refactor/NXion.yaml @@ -1,6 +1,6 @@ category: base doc: | - Set of atoms of a molecular ion or fragment assumed observed. + Base class for documenting the set of atoms of a (molecular) ion. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -33,22 +33,21 @@ NXion(NXobject): the number of protons and :math:`N` the number of neutrons of each isotope respectively. Z and N have to be 8-bit unsigned integers. - The array is stored sorted in decreasing order with unused values nullified. - initialized to zero. For the rationale behind this `M. Kühbach et al. (2021) `_ + The array is sorted in decreasing order with unused values nullified. + For the rationale behind this `M. Kühbach et al. (2021) `_ unit: NX_UNITLESS dim: (1, n_ivecmax) nuclid_list(NX_UINT): doc: | Table which decodes the isotope_vector into a human-readable matrix of nuclids. - The first row specifies the isotope mass number, i.e. using the hashvalues + The first row specifies the nuclid mass number, i.e. using the hashvalues from the isotope_vector this is :math:`Z + N`. - Taking a carbon-14 nuclid as an example the number is 14. + Taking a carbon-14 nuclid as an example the mass number is 14. The second row specifies the number of protons :math:`Z`, e.g. 6 as for the carbon-14 example. This notation is thus mapping the notation of using superscribed - isotope mass and subscripted number of protons to identify nuclids. - - The array is stored matching the order of isotope_vector with unused values nullified. + nuclid mass and subscripted number of protons. The array is stored + matching the order of isotope_vector with unused values nullified. unit: NX_UNITLESS dim: (2, n_ivecmax) # color(NX_CHAR): @@ -59,9 +58,8 @@ NXion(NXobject): Assumed volume of the ion. In atom probe microscopy this field can be used to store the reconstructed - volume per ion (average) which is typically stored in range files and will - be used when building a tomographic reconstruction of an atom probe - dataset. + volume per ion (average) which is typically stored alongside ranging + definitions. unit: NX_VOLUME charge(NX_NUMBER): doc: | @@ -77,11 +75,12 @@ NXion(NXobject): the value should be set to zero. In atom probe microscopy this is for example the case when using - classical range file formats like RNG, RRNG for atom probe data. - These file formats do not document the charge state explicitly. - They report the number of atoms of each element per molecular ion + classical ranging definition files in formats like RNG, RRNG. + These file formats do not document the charge state explicitly + but the number of atoms of each element per molecular ion surplus the mass-to-charge-state-ratio interval. - Details on ranging can be found in the literature: `M. K. Miller `_ + Details on ranging definition files can be found in the literature: + `M. K. Miller `_ unit: NX_UNITLESS name(NX_CHAR): doc: | @@ -90,7 +89,7 @@ NXion(NXobject): notation to specify the isotopes, ions, and charge state. Examples are 12C + or Al +++. - To ease automated parsing isotope_vector should be the + To ease automated parsing, isotope_vector should be the preferred machine-readable information used. mass_to_charge_range(NX_NUMBER): doc: | @@ -99,5 +98,5 @@ NXion(NXobject): (boundaries inclusive). This field is primarily of interest for documenting :ref:`NXprocess` steps of indexing a ToF/mass-to-charge state histogram. - unit: NX_ANY # NX_DALTON + unit: NX_ANY # u dim: (n_ranges, 2) diff --git a/contributed_definitions/nyaml/refactor/NXisocontour.yaml b/contributed_definitions/nyaml/refactor/NXisocontour.yaml index 3a222ff8d5..0e3171313c 100644 --- a/contributed_definitions/nyaml/refactor/NXisocontour.yaml +++ b/contributed_definitions/nyaml/refactor/NXisocontour.yaml @@ -1,17 +1,17 @@ category: base doc: | - Computational geometry description of isocontouring/phase-fields in Euclidean space. + Base class for describing isocontouring/phase-fields in Euclidean space. - Iso-contouring algorithms such as MarchingCubes and others are frequently + Iso-contouring algorithms such as Marching Cubes and others are frequently used to segment d-dimensional regions at crossings of a threshold value, the so-called isovalue. In Computational Materials Science phase-field methods are frequently used. - Many of the implementations of this methods discretize on regular grids. + Phase-field variables are discretized frequently using regular grids. Isocontour algorithms are often used in such context to pinpoint the locations of microstructural features from this implicit phase-field- - variable-based description. + variable-value-based description. One of the key intentions of this base class is to provide a starting point for scientists from the phase-field community (condensed-matter physicists, diff --git a/contributed_definitions/nyaml/refactor/NXmatch_filter.yaml b/contributed_definitions/nyaml/refactor/NXmatch_filter.yaml index 589fdd65e8..9cb867fcb2 100644 --- a/contributed_definitions/nyaml/refactor/NXmatch_filter.yaml +++ b/contributed_definitions/nyaml/refactor/NXmatch_filter.yaml @@ -10,7 +10,7 @@ type: group NXmatch_filter(NXobject): method(NX_CHAR): doc: | - Logical operation of the filter: + Definition of the logic what the filter yields: Whitelist specifies which entries with said value to include. Entries with all other values will be excluded. @@ -20,7 +20,7 @@ NXmatch_filter(NXobject): match(NX_NUMBER): doc: | Array of values to filter according to method. If the match e.g. specifies - [1, 5, 6] and method is set to whitelist only entries with values matching + [1, 5, 6] and method is set to whitelist, only entries with values matching 1, 5 or 6 will be processed. All other entries will be excluded. unit: NX_UNITLESS dim: (n_values,) diff --git a/contributed_definitions/nyaml/refactor/NXpeak.yaml b/contributed_definitions/nyaml/refactor/NXpeak.yaml index 7b3dbc313b..89d0858e33 100644 --- a/contributed_definitions/nyaml/refactor/NXpeak.yaml +++ b/contributed_definitions/nyaml/refactor/NXpeak.yaml @@ -1,6 +1,6 @@ category: base doc: | - Description of peaks, their functional form, and measured support. + Base class for peaks, their functional form, and measured support. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/refactor/NXreflectron.yaml b/contributed_definitions/nyaml/refactor/NXreflectron.yaml index 71c3bd380d..bb8eb03b54 100644 --- a/contributed_definitions/nyaml/refactor/NXreflectron.yaml +++ b/contributed_definitions/nyaml/refactor/NXreflectron.yaml @@ -1,9 +1,9 @@ category: base doc: | - Device for reducing flight time differences of ions in ToF experiments. + Base class for a device which reduces ToF differences of ions in ToF experiments. - For atom probe the reflectron can be considered an energy_compensation - device, which can e.g. be realized technically as via a Poschenrieder lens + For atom probe the reflectron can be considered an energy compensation device. + Such a device can be realized technically for example with a Poschenrieder lens. Consult the following U.S. patents for further details: @@ -37,9 +37,9 @@ NXreflectron(NXobject): # dim: (p,) (NXtransformations): doc: | - Affine transformation(s) which detail where the reflectron is located relative - to e.g. the origin of the specimen space reference coordinate system. - This group can also be used for specifying how the reflectron + Affine transformation(s) which detail where the reflectron is located + relative to e.g. the origin of the specimen space reference coordinate + system. This group can also be used for specifying how the reflectron is rotated relative to a given axis in the instrument. # The purpose of these more detailed instrument descriptions # is to support the creation of a digital twin of the instrument diff --git a/contributed_definitions/nyaml/refactor/NXspatial_filter.yaml b/contributed_definitions/nyaml/refactor/NXspatial_filter.yaml index 8d3df6b609..dd02f0d841 100644 --- a/contributed_definitions/nyaml/refactor/NXspatial_filter.yaml +++ b/contributed_definitions/nyaml/refactor/NXspatial_filter.yaml @@ -1,9 +1,8 @@ category: base doc: | - Spatial filter to filter objects within a region-of-interest (ROI) based position. + Base class for a spatial filter for objects within a region-of-interest (ROI). - Objects can be points, other geometric primitives or objecs composed from - other geometric primitives. + Objects can be points or objects composed from other geometric primitives. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -24,14 +23,14 @@ NXspatial_filter(NXobject): Qualitative statement which describes the logical operations that define which objects will be included and which excluded: - * entire_dataset, no filter is applied, all objects are used. + * entire_dataset, no filter is applied, all objects are included. * union_of_primitives, a filter with (possibly non-axis-aligned) geometric - primitives. Objects in or on the surface of the primitives are considered. + primitives. Objects in or on the surface of the primitives are included. All other objects are excluded. * bitmask, a boolean array whose bits encode with 1 which objects - are included. Bits set to zero encode which objects - are excluded. Users of python can use the bitfield operations - of the numpy package to define such bitfields. + are included. Bits set to zero encode which objects are excluded. + Users of python can use the bitfield operations + of the numpy package to work with bitfields. # In the case that windowing_method is union_of_primitives, # it is possible to specify none or all types of primitives diff --git a/contributed_definitions/nyaml/refactor/NXsubsampling_filter.yaml b/contributed_definitions/nyaml/refactor/NXsubsampling_filter.yaml index ffce75716c..b7b47a1e15 100644 --- a/contributed_definitions/nyaml/refactor/NXsubsampling_filter.yaml +++ b/contributed_definitions/nyaml/refactor/NXsubsampling_filter.yaml @@ -6,14 +6,15 @@ type: group NXsubsampling_filter(NXobject): min_incr_max(NX_INT): doc: | - Triplet of the minimum, increment, and maximum identifier to include - for a linear sequence of identifier. The increment controls which n-th - identifier (value) to take. + Triplet of the minimum, the increment, and the maximum identifier to + include of a sequence :math:`[i_0, i_0 + 1, i_0 + 2, \ldots, i_0 + \mathcal{N}] with i_0 \in \mathcal{Z}` + of identifier. The increment controls which n-th identifier (value) to take. - Take as an example a dataset with 100 identifier (aka entries provided - their identifier start at zero, i.e. identifier_offset is 0). Assume that linear_range_min_incr_max - is set to [0, 1, 99]. This will process each identifier. 0, 2, 99 will take each second identifier. - 90, 3, 99 will take each third identifier beginning from identifier 90 up to 99. + Take as an example a dataset with 100 identifier (aka entries). Assume that + the identifier start at zero, i.e. identifier_offset is 0). Assume further + that min_incr_max is set to [0, 1, 99]. In this case the filter will + yield all identifier. Setting min_incr_max to [0, 2, 99] will take each + second identifier. Setting min_incr_max to [90, 3, 99] will take each + third identifier beginning from identifier 90 up to 99. unit: NX_UNITLESS dim: (3,) - # TODO clarify that identifier are in id_offset, id_offset + 1, idoffset + 2, idoffset + n From 6b649bce025002732a2f92120d7609c18bda16e6 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Sat, 6 Jan 2024 23:02:05 +0100 Subject: [PATCH 0436/1012] Further reviewing and corrections --- .../nyaml/refactor/NXapm_msr.yaml | 30 ++++----- .../NXapm_paraprobe_ranger_config.yaml | 10 +-- .../NXapm_paraprobe_ranger_results.yaml | 46 ++++++------- .../NXapm_paraprobe_transcoder_config.yaml | 12 ++-- .../NXapm_paraprobe_transcoder_results.yaml | 37 +++++----- .../nyaml/refactor/NXevent_data_apm.yaml | 67 +++++++++---------- .../nyaml/refactor/NXevent_data_apm_set.yaml | 7 +- .../nyaml/refactor/NXpulser_apm.yaml | 44 ++++++------ .../nyaml/refactor/NXsimilarity_grouping.yaml | 25 ++++--- 9 files changed, 135 insertions(+), 143 deletions(-) diff --git a/contributed_definitions/nyaml/refactor/NXapm_msr.yaml b/contributed_definitions/nyaml/refactor/NXapm_msr.yaml index 6aea40f398..8e4734280c 100644 --- a/contributed_definitions/nyaml/refactor/NXapm_msr.yaml +++ b/contributed_definitions/nyaml/refactor/NXapm_msr.yaml @@ -8,7 +8,7 @@ doc: | The main motivation for this is the ongoing development and tighter becoming connection between atom probe and other material characterization techniques foremost electron microscopy (see `T. Kelly et al. `_, `C. Fleischmann et al. `_, and `W. Windl et al. `_ or `C. Freysoldt et al. https://doi.org/10.1103/PhysRevLett.124.176801>`_ to mention but a few). - To arrive at a design of base classes and an application definition which can be used for both real and simulated atom probe experiments it is worthwhile to recall first several different concepts that are related to events and (molecular) ions: + To arrive at a design of base classes and an application definition which can be used for both real and simulated atom probe experiments, it is worthwhile to recall concepts that are related to events and (molecular) ions: * Pulsing events which are used to trigger ion extraction events. * Physical events and corresponding signal triggered by an ion hitting the detector. @@ -25,14 +25,14 @@ doc: | Not only in AMETEK/Cameca's IVAS/APSuite software, which the majority of atom probers use, these concepts are well distinguished. However, the algorithms used to transform correlations between pulses and physical events - into actual events (detector hits) ions is a proprietary one. Due to this practical inaccessibility of details, virtually all - atom probe studies currently use a reporting scheme where the course of the specimen evaporation - is documented that quantities are a function of evaporation identifier i.e. actual event/ion, i.e. after having the - hits finding algorithm and correlations applied. That is evaporation_identifier values take the role of an implicit + into actual events (detector hits) ions is a proprietary one. Due to this practical inaccessibility of details, + virtually all atom probe studies currently use a reporting scheme where the course of the specimen evaporation + is documented such that quantities are a function of evaporation identifier i.e. actual event/ion, i.e. after having + the hits finding algorithm and correlations applied. That is evaporation_identifier values take the role of an implicit time and course of the experiment given that ion extraction is a sequential physical process. There is a number of research groups who build own instruments and share different aspects of their technical - specifications and approaches how they apply data processing (e.g. `M. Monajem et al. `_, `P. Stender et al. `_ , or `I. Dimkou et al. `_). + specifications and approaches how they apply data processing (e.g. `M. Monajem et al. `_, `P. Stender et al. `_ , or `I. Dimkou et al. `_ to name but a few). Despite some of these activities embrace practices of open-source development, they use essentially the same workflow that has been proposed by AMETEK/Cameca and its forerunner company Imago: A graphical user interface software is used to explore and thus analyze reconstructed atom probe datasets. @@ -43,21 +43,21 @@ doc: | By contrast, simulations of field-evaporation have the luxury to document the flight path and allow following the whereabouts of each ion evaporated if needed. This level of detail is currently not characterizable in experiment. - Thus, there is an artificial divide between schemas describing simulations of atom probe vs measurements of atom probe. + Thus, there is a divide between schemas describing simulations of atom probe vs measurements of atom probe. We argue that this divide can be bridged with realizing the above-mentioned context and the realization that similar concepts are used in both research realms with many concepts not only being similar but exactly the same. A further argument to support this view is that computer simulations of atom probe usually are compared to reconstructed - datasets, either to the input configuration that served as the virtual specimen or to a real world atom probe experiment and its - reconstructions. In both cases, the recorded simulated physical events of simulated ions hitting a simulated detector - is not the end of the research workflow but typically just the input to apply addition algorithms such as (spatial) filtering + datasets, either to the input configuration that served as the virtual specimen or to a real world atom probe experiment + and its reconstructions. In both cases, the recorded simulated physical events of simulated ions hitting a simulated detector + is not the end of the research workflow but typically the input to apply addition algorithms such as (spatial) filtering and reconstruction algorithms. Only the practical need for making ranging definitions is (at least as of now) not as much needed in field-evaporation simulations than it is in real world measurements because each ion has a prescribed iontype in the simulation. Be it a specifically charged nuclid or a molecular ion whose flight path the simulation resolves. Although, in principle simpler though, we have to consider that this is caused by many assumptions made in the simulations. Indeed, the multi-scale (time and space) aspects of the challenge that is the simulating of field-evaporation are simplified - because of demand in computing resources or knowledge gaps in how to deal with some complexities. Molecular ion dissociation - upon flight is one such complexity. Also the complexity of simulation setups is simpler e.g. the assumption of a straight flight path + because of otherwise too high computing resource demands and knowledge gaps in how to deal with some complexities. + Molecular ion dissociation upon flight is one such complexity. Also the complexity of simulation setups is simpler e.g. the assumption of a straight flight path instrument is used or details are ignored such as local electrodes or physical obstacles and electric fields (controlled or stray fields). To conclude, we thus propose two base classes :ref:`NXapm_msr` and :ref:`NXapm_sim` where the second one may become @@ -83,8 +83,8 @@ NXapm_msr(NXobject): # when evolving these ideas further inherit from NXapm_met Possibility to include a detailed computational geometry description of the instrument. instrument_name(NX_CHAR): doc: | - Given name of the microscope as defined by the hosting lab. This is an alias. - Examples could be LEAP6000, Raptor, Oxcart, one atom at a time, etc. + Given name of the microscope as defined by the hosting lab. This is an alias. + Examples could be LEAP6000, Raptor, Oxcart, one atom at a time, etc. location(NX_CHAR): doc: | Location of the lab or place where the instrument is installed. @@ -109,7 +109,7 @@ NXapm_msr(NXobject): # when evolving these ideas further inherit from NXapm_met # NEW ISSUE: local electrode, baking strategies, storage ion_detector(NXdetector): doc: | - Detector for taking raw time-of-flight and ion/hit impact positions data. + Detector for taking raw time-of-flight and ion/hit impact positions data. # model, serial_number, manufacturer_name all inherited from NXdetector base class pulser(NXpulser_apm): stage_lab(NXstage_lab): diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_ranger_config.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_ranger_config.yaml index 864d7a1562..b2d45017b7 100644 --- a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_ranger_config.yaml +++ b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_ranger_config.yaml @@ -14,15 +14,16 @@ symbols: type: group NXapm_paraprobe_ranger_config(NXobject): (NXentry): - \@version: + exists: [min, 1, max, 1] + \@version(NX_CHAR): doc: | Version specifier of this application definition. - definition: + definition(NX_CHAR): doc: | - Official NeXus NXDL schema with which this file was written. + NeXus NXDL schema with which this file was written. enumeration: [NXapm_paraprobe_ranger_config] apply_existent_ranging(NXapm_paraprobe_tool_config): - exists: ['min', '0', 'max', '1'] + exists: [min, 0, max, 1] (NXidentifier): exists: optional analysis_identifier(NX_UINT): @@ -88,7 +89,6 @@ NXapm_paraprobe_ranger_config(NXobject): exists: optional method(NX_CHAR): match(NX_NUMBER): - # (NXprogram): profiling(NXcs_profiling): exists: recommended start_time(NX_DATE_TIME): diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_ranger_results.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_ranger_results.yaml index da9d985f49..d138ab527c 100644 --- a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_ranger_results.yaml +++ b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_ranger_results.yaml @@ -1,41 +1,41 @@ category: application doc: | - Application definition for results files of the paraprobe-transcoder tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. - The purpose and need of the paraprobe-ranger tool is to apply a given set of ranging definitions within - a certain (possibly complicated) selection of ions (based on their properties or location in the - reconstructed volume. + Application definition for results files of the paraprobe-transcoder tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + The purpose and need of the paraprobe-ranger tool is to apply a given set of ranging definitions within + a certain (possibly complicated) selection of ions (based on their properties or location in the + reconstructed volume. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. n_ions: | - The total number of ions in the reconstruction. + The total number of ions in the reconstructed volume. type: group NXapm_paraprobe_ranger_results(NXobject): (NXentry): - exists: ['min', '1', 'max', '1'] - \@version: + exists: [min, 1, max, 1] + \@version(NX_CHAR): doc: | Version specifier of this application definition. - definition: + definition(NX_CHAR): doc: | - Official NeXus NXDL schema with which this file was written. + NeXus NXDL schema with which this file was written. enumeration: [NXapm_paraprobe_ranger_results] apply_existent_ranging(NXapm_paraprobe_tool_results): - exists: ['min', '0', 'max', '1'] + exists: [min, 0, max, 1] doc: | Paraprobe-ranger loads the iontypes and evaluates for each - ion on which iontype it matches. If it matches on no interval, the - ion is considered of the default unknown type with a 0 as its - respective value in the iontypes array. + ion on which iontype it matches. If it matches on none, the + ion is considered of the default unknown type with a 0 + as its respective value in the iontypes array. ##MK::number_of_ion_types(NX_POSINT): maximum_number_of_atoms_per_molecular_ion(NX_POSINT): doc: | The length of the isotope_vector used to describe molecular ions. unit: NX_UNITLESS (NXion): - exists: ['min', '1', 'max', '256'] + exists: [min, 1, max, 256] isotope_vector(NX_UINT): nuclid_list(NX_UINT): exists: recommended @@ -43,19 +43,18 @@ NXapm_paraprobe_ranger_results(NXobject): mass_to_charge_range(NX_FLOAT): iontypes(NX_UINT): doc: | - The iontype ID for each ion that was best matching, stored in the - order of the evaporation sequence ID. The here computed iontypes + The iontype (identifier) for each ion that was best matching, stored + in the order of the evaporation sequence ID. The here computed iontypes do not take into account the charge state of the ion which is equivalent to interpreting a RNG and RRNG range files for each ion in such a way that only the elements of which a (molecular) ion - is build are considered. By contrast, charged_iontypes takes - into account also the charge state. + was built are considered. unit: NX_UNITLESS dim: (n_ions,) window(NXcs_filter_boolean_mask): doc: | A bitmask which identifies exactly all those ions ranged - irrespective of the type they ended up with. This information + irrespective of the assigned type. This information can be used to numerically recover the ROI selection. number_of_ions(NX_UINT): doc: | @@ -81,19 +80,20 @@ NXapm_paraprobe_ranger_results(NXobject): unit: NX_UNITLESS dim: (i,) - (NXprogram): + (NXprogram): profiling(NXcs_profiling): start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): status(NX_CHAR): results_path(NX_CHAR): exists: recommended + current_working_directory(NX_CHAR): total_elapsed_time(NX_NUMBER): number_of_processes(NX_POSINT): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): (NXuser): - exists: ['min', '0', 'max', 'unbounded'] + exists: [min, 0, max, infty] name(NX_CHAR): (NXcoordinate_system_set): paraprobe(NXcoordinate_system): diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_transcoder_config.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_transcoder_config.yaml index eccde9b25c..ab5a1998ca 100644 --- a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_transcoder_config.yaml +++ b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_transcoder_config.yaml @@ -3,24 +3,24 @@ doc: | Application definition for a configuration file of the paraprobe-transcoder tool. This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. +# symbols: +# doc: | +# The symbols used in the schema to specify e.g. dimensions of arrays. type: group # official NeXus appdef headers NXapm_paraprobe_transcoder_config(NXobject): (NXentry): - exists: ['min', '1', 'max', '1'] + exists: [min, 1, max, 1] # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently \@version(NX_CHAR): doc: | Version specifier of this application definition. definition(NX_CHAR): doc: | - Official NeXus NXDL schema with which this file was written. + NeXus NXDL schema with which this file was written. enumeration: [NXapm_paraprobe_transcoder_config] transcode(NXapm_paraprobe_tool_config): - exists: ['min', 0, 'max', '1'] + exists: [min, 0, max, 1] (NXidentifier): exists: optional analysis_identifier(NX_UINT): diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_transcoder_results.yaml b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_transcoder_results.yaml index a46e5c2cda..2a7d3c3ea9 100644 --- a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_transcoder_results.yaml +++ b/contributed_definitions/nyaml/refactor/NXapm_paraprobe_transcoder_results.yaml @@ -5,21 +5,20 @@ doc: | This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. The purpose and need of the paraprobe-transcoder tool is to create a standardized representation of reconstructed position and mass-to-charge-state-ratio values surplus other pieces of information - to enable at all to work with atom probe data in reconstruction space. + to enable working with atom probe data in reconstruction space. This includes ranging definitions which map mass-to-charge-state ratio values onto iontypes. So far the atom probe community has not yet agreed upon a comprehensive standardization for information exchange especially when it comes to the communication of configurations and results - from analyses of atom probe data. Instead, different simplistic file formats are used, such as POS , ePOS, - APT, or RNG and RRNG. None of these formats document though the provenance of and thus the - sequence in which certain analysis steps were performed on which specific input and using which - specific configuration. + from analyses of atom probe data. Instead, different simplistic file formats are used, such as POS, + ePOS, APT, or RNG and RRNG. None of these formats, though, document the provenance of, and thus the + sequence in which certain analysis steps were performed or which specific input and + configuration was used. Paraprobe-transcoder solves this limitation by interpreting the information content in such files and standardize the representation prior injection into the scientific data analysis tools of the toolbox. Therefore, the here proposed set of NeXus base classes and application definitions can be a useful - starting point that enable the atom probe community to take advantage of standardized - information exchange and improve the here proposed classes and concepts to become - even more inclusive. + starting point that enable the atom probe community to take advantage of standardized information + exchange and improve the here proposed classes and concepts to become more inclusive. Paraprobe-transcoder uses a Python library developed based on efforts by members of the global atom probe community `International Field Emission Society (IFES) Atom Probe Technical Committee (APT TC) `_. This library offers the @@ -41,15 +40,15 @@ symbols: # i be careful n_comb can vary for every instance of (NXion) ! type: group NXapm_paraprobe_transcoder_results(NXobject): - # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently + # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently (NXentry): - exists: ['min', '1', 'max', '1'] - \@version: + exists: [min, 1, max, 1] + \@version(NX_CHAR): doc: | Version specifier of this application definition. - definition: + definition(NX_CHAR): doc: | - Official NeXus NXDL schema with which this file was written. + NeXus NXDL schema with which this file was written. enumeration: [NXapm_paraprobe_transcoder_results] atom_probe(NXapm_paraprobe_tool_results): # this is currently a trick but should in the future be renamed to have a one-to-one @@ -57,13 +56,13 @@ NXapm_paraprobe_transcoder_results(NXobject): # arrays such that # the doc-string of the concept atom_probe(NXinstrument) should be used for # supplementary material to a paper but here no longer reported as it is way too specific - # APSuite, RRNG, RNG, and NeXus/HDF5 NXapm in such a way that they can + # APSuite, RRNG, RNG, and NeXus/HDF5 NXapm in such a way that they can # be used with the tools of the paraprobe-toolbox. mass_to_charge_conversion(NXprocess): mass_to_charge(NX_FLOAT): - unit: NX_ANY # u doc: | Mass-to-charge-state-ratio values. + unit: NX_ANY # u dim: (n_ions,) reconstruction(NXprocess): reconstructed_positions(NX_FLOAT): @@ -88,10 +87,9 @@ NXapm_paraprobe_transcoder_results(NXobject): ranging(NXprocess): peak_identification(NXprocess): doc: | - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. + Details about how peaks are interpreted as ion types or not. (NXion): - exists: ['min', '1', 'max', '256'] + exists: [min, 1, max, 256] isotope_vector(NX_UINT): nuclid_list(NX_UINT): exists: recommended @@ -107,13 +105,14 @@ NXapm_paraprobe_transcoder_results(NXobject): status(NX_CHAR): results_path(NX_CHAR): exists: recommended + current_working_directory(NX_CHAR): total_elapsed_time(NX_NUMBER): number_of_processes(NX_POSINT): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): # use more detailed constraint set to describe a computer (NXuser): - exists: ['min', '0', 'max', 'unbounded'] + exists: [min, 0, max, infty] doc: | If used, metadata of at least the person who performed this analysis. name(NX_CHAR): diff --git a/contributed_definitions/nyaml/refactor/NXevent_data_apm.yaml b/contributed_definitions/nyaml/refactor/NXevent_data_apm.yaml index 542d548e01..306a3954ff 100644 --- a/contributed_definitions/nyaml/refactor/NXevent_data_apm.yaml +++ b/contributed_definitions/nyaml/refactor/NXevent_data_apm.yaml @@ -2,9 +2,9 @@ category: base doc: | Base class to store state and (meta)data of events over the course of an atom probe experiment. - This base class applies the concept of the :ref:`NXevent_data_em` base class to the - specific needs of atom probe research. Against static and dynamic quantities are splitted to - avoid duplication of information. Specifically, the time interval considered is the entire time + This base class applies the concept of the :ref:`NXevent_data_em` base class to the specific needs + of atom probe research. Against static and dynamic quantities are splitted to avoid a duplication + of information. Specifically, the time interval considered is the entire time starting at start_time until end_time during which we assume the pulser triggered named pulses. These pulses are identified via the pulse_identifier field. The point in time when each was issued is specified via the combination of start_time and delta_time. @@ -12,24 +12,22 @@ doc: | Conceptually and technically NeXus currently stores tensorial information as arrays of values (with each value of the same datatype). For instance, a field temperature(NX_FLOAT) stores a set of temperature values but that field when used somewhere is a concept. However, that - concept has no information at which point in time these temperatures were taken is there - is some functional relationship. + concept has no information at which point in time these temperatures were taken. + An existent functional relationship between the two concepts is not defined. However, a correct interpretation of the temperature values demands knowledge about what is the independent quantity on which temperature depends on or according to which frequency temperature values were sampled. - In NeXus there are two approaches which cope with these in fact correlated concepts: + In NeXus there are two approaches which cope with such correlations: One is :ref:`NXdata` where the attribute signal specifies the correlation. The other one is :ref:`NXlog` which, like NXdata, demands to granularize logged_against - (dependent signal) and independent quantity into an own group. In many cases this additional - grouping is undesired. + (dependent signal) and independent quantities into an own group. + In many cases this additional grouping is not desired though. One naive solution typically employed is then to store the independent variable values via a second vector e.g. time_stamp with the same number of entries (with dimensionality defined through symbols). - However, there is no independent logical connection between these two concepts, i.e. temperature - and time_stamp! Indeed conceptually reporting temperature as a function of time_stamp is - a correlation between pairs of values one from each of two concepts. + and time_stamp. In the case of atom probe though the time that one would use in NXlog is defined implicitly via pulse_identifier, which is the independent variable vector against which eventually dozens of channels of data are logged. @@ -67,8 +65,8 @@ NXevent_data_apm(NXobject): Delta time array which resolves for each pulse_identifier the time difference between when that pulse was issued and start_time. - In summary, using start_time, end_time, time, pulse_identifier_offset, and - pulse_identifier exactly specifies the connection between when a pulse was + In summary, using start_time, end_time, delta_time, pulse_identifier_offset, + and pulse_identifier exactly specifies the connection between when a pulse was issued relative to start and absolute in UTC. unit: NX_TIME dim: (p,) @@ -92,15 +90,14 @@ NXevent_data_apm(NXobject): pulse_identifier(NX_INT): doc: | Identifier that contextualizes how the detector and pulser of an atom probe - instrument follow a sequence of pulses to trigger field evaporation. + instrument follows a sequence of pulses to trigger field evaporation. The pulse_identifier is used to associate thus an information about time when the quantities documented in this NXpulser_apm base class have been collected via sampling. - In virtually all cases the pulser is a blackbox which users assume does its job. - That is to induce pulses according to given instances in time with target properties. - Depending on how the instrument is configured during a measurement the target + In virtually all cases the pulser is a blackbox. Depending on how the + instrument is configured during a measurement the target values and thus also the actual values may change. Maybe the first part of the experiment is run at a certain pulse fraction but thereafter @@ -109,18 +106,18 @@ NXevent_data_apm(NXobject): long vector which stores the set of events (e.g. pulsing events) when that value was measured. - This may cause several situation: In the case that e.g. the pulse_fraction is never changed + This may cause several situations: In the case that e.g. the pulse_fraction is never changed and also exact details not interesting, one stores the set value for the pulse_fraction and a single value for the pulse_identifier e.g. 0 to indicate that the pulse_fraction was set at the beginning and it was maintained constant during the measurement. - If the pulse_fraction was maybe changed after the 100000th pulse pulse_fraction is a + If the pulse_fraction was maybe changed after the 100000th pulse, pulse_fraction is a vector with two values one for the first and another one for the value from the 100000-th pulse onwards. The values of pulse_identifier are then [0, 99999] respectively. unit: NX_UNITLESS dim: (p,) instrument(NXinstrument): doc: | - (Meta)data of the dynamics and changes of the microscope over the course of pulsing. + (Meta)data of the dynamics and changes of the microscope over the course of pulsing. (NXreflectron): local_electrode(NXlens_em): ion_detector(NXdetector): @@ -138,11 +135,11 @@ NXevent_data_apm(NXobject): # I clear say NO ! pulser(NXpulser_apm): stage_lab(NXstage_lab): - average_temperature(NX_FLOAT): - doc: | - Average temperature at the specimen base, i.e. - base_temperature during the measurement. - unit: NX_TEMPERATURE + average_temperature(NX_FLOAT): + doc: | + Average temperature at the specimen base, i.e. + base_temperature during the measurement. + unit: NX_TEMPERATURE # normally one would use NXsensor/NXlog but point is that the temperature # is logged against the pulse_identifier as even in the proprietary file format from # AMETEK/Cameca nowhere there is the actual time when the pulse was triggered @@ -150,20 +147,20 @@ NXevent_data_apm(NXobject): # from Cameca this is also the time when the first pulse was triggered # using NXlog does make sense when individual NXsensors have different timing # but for atom probe if at all the pulse-based implicit time is available - temperature(NX_FLOAT): + temperature(NX_FLOAT): + 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 + dim: (p,) + \@logged_against(NX_CHAR): 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 - dim: (p,) - \@logged_against(NX_CHAR): - doc: | - Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. analysis_chamber(NXchamber): average_temperature(NX_FLOAT): doc: | - Average pressure in the analysis chamber during the measurement. + Average pressure in the analysis chamber during the measurement. unit: NX_PRESSURE pressure(NX_FLOAT): doc: | diff --git a/contributed_definitions/nyaml/refactor/NXevent_data_apm_set.yaml b/contributed_definitions/nyaml/refactor/NXevent_data_apm_set.yaml index 61bf1db4d0..cf5c26323a 100644 --- a/contributed_definitions/nyaml/refactor/NXevent_data_apm_set.yaml +++ b/contributed_definitions/nyaml/refactor/NXevent_data_apm_set.yaml @@ -6,10 +6,9 @@ doc: | These have an associated time interval during which the conditions of the instrument were considered stable and fit enough for purpose. - Which temporal granularity is adequate depends on the situation and - research question. Using a model which enables a collection of events offers - the most flexible way to cater for both atom probe experiments or the - simulation of such experiments. + Which temporal granularity is adequate depends on the situation and research + question. Using a model which enables a collection of events offers the most + flexible way to cater for both atom probe experiments or simulation. To monitor the course of an ion extraction experiment (or simulation) it makes sense to track time explicitly via time stamps or implicitly diff --git a/contributed_definitions/nyaml/refactor/NXpulser_apm.yaml b/contributed_definitions/nyaml/refactor/NXpulser_apm.yaml index 8a653bf643..cc8798d0db 100644 --- a/contributed_definitions/nyaml/refactor/NXpulser_apm.yaml +++ b/contributed_definitions/nyaml/refactor/NXpulser_apm.yaml @@ -1,6 +1,6 @@ category: base doc: | - Metadata for laser- and/or voltage-pulsing in atom probe microscopy. + Base class for a laser- and/or voltage-pulsing device used in atom probe microscopy. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -16,8 +16,8 @@ NXpulser_apm(NXobject): enumeration: [laser, voltage, laser_and_voltage] pulse_frequency(NX_FLOAT): doc: | - Frequency with which the voltage or laser pulser fire(s). - # the example of how the IFES APT TC's HDF format deals with such conceptually shows how awkward instance, concepts are mixed to superconcepts: "PulseFrequency : Real array, 2xn (Hz) This is the frequency of the high voltage or laser pulser. first entry : first pulse number where the spacing between this and all subsequent pulses are considered to be at the selected frequency. Each first entry must be strictly increasing in value. The second entry contains the frequency value" as data can be compressed in this case very efficiently we go for with an array of length 1xn_ions + Frequency with which the pulser fire(s). + # the example of how the IFES APT TC's HDF format deals with such data conceptually, concepts are mixed into superconcepts interleaved tuple with different units: "PulseFrequency : Real array, 2xn (Hz) This is the frequency of the high voltage or laser pulser. first entry : first pulse number where the spacing between this and all subsequent pulses are considered to be at the selected frequency. Each first entry must be strictly increasing in value. The second entry contains the frequency value" as data can be compressed in this case very efficiently we go for with an array of length 1xn_ions unit: NX_FREQUENCY dim: (p,) \@logged_against(NX_CHAR): @@ -38,19 +38,19 @@ NXpulser_apm(NXobject): Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. pulse_voltage(NX_FLOAT): doc: | - Pulsed voltage, in laser pulsing mode this values can be omitted. - # example of a conditional requirement is done rigorously can be handled by OWL but not by NeXus! - # as either pulse_voltage is required in an appdef but then that existence constraint is independent of - # other values. + Pulsed voltage, in laser pulsing mode this field can be omitted. + # example of a conditional requirement that can be dealt with igorously by OWL but not by NeXus! + # as either pulse_voltage is required in an appdef but then that + # existence constraint is independent of other values. unit: NX_VOLTAGE dim: (p,) \@logged_against(NX_CHAR): doc: | Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. pulse_number(NX_UINT): - unit: NX_UNITLESS doc: | Absolute number of pulses starting from the beginning of the experiment. + unit: NX_UNITLESS dim: (p,) \@logged_against(NX_CHAR): doc: | @@ -93,34 +93,32 @@ NXpulser_apm(NXobject): Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. \@depends_on(NX_CHAR): doc: | - Path to instance of :ref:`NXcoordinate_system` which specifies - the reference frame in which the laser is shining. + Path to an instance of :ref:`NXcoordinate_system` which + specifies the reference frame in which the laser is shining. (NXbeam): doc: | - Details about specific positions along the focused laser beam + Details about specific positions along the laser beam which illuminates the (atom probe) specimen. incidence_vector(NX_NUMBER): doc: | - Track time-dependent settings over the course of the - measurement how the laser beam in tip space/reconstruction space - laser impinges on the sample, i.e. the mean vector is parallel to - the laser propagation direction. + Track time-dependent settings over the course of the measurement + how the laser beam shines on the specimen, i.e. the mean vector + is parallel to the laser propagation direction. unit: NX_LENGTH dim: (p, 3) \@logged_against(NX_CHAR): doc: | Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - pinhole_position(NXcollection): + pinhole_position(NX_NUMBER): doc: | - Track time-dependent settings over the course of the - measurement where the laser beam exits the - focusing optics. + Track time-dependent settings over the course of the measurement + where the laser beam exits the focusing optics. unit: NX_LENGTH dim: (p, 3) \@logged_against(NX_CHAR): doc: | Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - spot_position(NXcollection): + spot_position(NX_NUMBER): doc: | Track time-dependent settings over the course of the measurement where the laser hits the specimen. @@ -135,6 +133,6 @@ NXpulser_apm(NXobject): laser focusing optics/pinhole-attached coordinate system is defined, how it has to be transformed so that it aligns with the specimen coordinate system. - A right-handed Cartesian coordinate system, the so-called laser space, - should be assumed, whose positive z-axis points - into the direction of the propagating laser beam. + # A right-handed Cartesian coordinate system, the so-called laser space, + # should be assumed, whose positive z-axis points + # into the direction of the propagating laser beam. diff --git a/contributed_definitions/nyaml/refactor/NXsimilarity_grouping.yaml b/contributed_definitions/nyaml/refactor/NXsimilarity_grouping.yaml index d00cf0b627..6c3fe92bf4 100644 --- a/contributed_definitions/nyaml/refactor/NXsimilarity_grouping.yaml +++ b/contributed_definitions/nyaml/refactor/NXsimilarity_grouping.yaml @@ -3,14 +3,14 @@ doc: | Base class to store results obtained from applying a similarity grouping (clustering) algorithm. Similarity grouping algorithms are segmentation or machine learning algorithms for - partitioning the members of a set of objects (e.g. geometric primitives) into (sub-)groups - aka features of some but different kind/type. A plethora of algorithms exists. + partitioning the members of a set of objects (e.g. geometric primitives) into + (sub-)groups aka features of different kind/type. A plethora of algorithms exists. This base class considers metadata and results of having a similarity grouping algorithm applied to a set in which objects are either categorized as noise or belonging to a cluster, i.e. members of a cluster. - The algorithm assigns each similarity group (feature/cluster) at least one identifier - (numerical or categorical labels) to distinguish different groups. + The algorithm assigns each similarity group (feature/cluster) at least one + identifier (numerical or categorical labels) to distinguish different cluster. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -32,28 +32,27 @@ NXsimilarity_grouping(NXobject): doc: | How many numerical labels does each feature have. unit: NX_UNITLESS - # dim: (i,) number_of_categorical_labels(NX_UINT): doc: | How many categorical labels does each feature have. unit: NX_UNITLESS - # dim: (i,) + # config/input # features: # doc: | # Reference to a set of features investigated in a cluster analysis. # Features need to have disjoint numeric identifier. + # results for the object set identifier_offset(NX_INT): doc: | Which numerical identifier is the first to be used to label a feature. The value should be chosen in such a way that special values can be resolved: - * identifier_offset-1 indicates that an object belongs to no cluster. - * identifier_offset-2 indicates that an object belongs to the noise category. + * identifier_offset - 1 indicates that an object belongs to no cluster. + * identifier_offset - 2 indicates that an object belongs to the noise category. Setting for instance identifier_offset to 1 recovers the commonly used - case that objects of the noise category get values to -1 and unassigned points to 0. - Numerical identifier have to be strictly increasing. + case that objects of the noise category get values to -1 and unassigned + points to 0. Numerical identifier have to be strictly increasing. unit: NX_UNITLESS - dim: (n_lbl_num,) numerical_label(NX_INT): doc: | Matrix of numerical label for each member in the set. @@ -65,7 +64,7 @@ NXsimilarity_grouping(NXobject): doc: | Matrix of categorical attribute data for each member in the set. dim: (c, n_lbl_cat) - statistics(NXprocess): + statistics(NXprocess): # of the clusters/features doc: | In addition to the detailed storage which objects were grouped to which feature/group summary statistics are stored under this group. @@ -97,7 +96,7 @@ NXsimilarity_grouping(NXobject): # at the level of the feature set number_of_features(NX_UINT): doc: | - Total number of clusters (excluding noise and unassigned). + Total number of features (excluding noise and unassigned). unit: NX_UNITLESS feature_identifier(NX_UINT): doc: | From 701f2777f585270016e94ca81483a1772c6e09ba Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Sun, 7 Jan 2024 17:35:48 +0100 Subject: [PATCH 0437/1012] NXapm reviewing and typos --- .../nyaml/refactor/NXapm.yaml | 186 +++++++++--------- 1 file changed, 94 insertions(+), 92 deletions(-) diff --git a/contributed_definitions/nyaml/refactor/NXapm.yaml b/contributed_definitions/nyaml/refactor/NXapm.yaml index 74f2e4f9cf..ae810b2635 100644 --- a/contributed_definitions/nyaml/refactor/NXapm.yaml +++ b/contributed_definitions/nyaml/refactor/NXapm.yaml @@ -9,17 +9,18 @@ symbols: resolved by an instance of :ref:`NXevent_data_apm`. If this is not defined, p is the number of ions included in the reconstructed - volume if the application definition is used to store results of already + volume if the application definition is used to store results of an already reconstructed datasets. n: | Number of ions spatially filtered from results of the hit_finding algorithm from which an instance of a reconstructed volume has been generated. - These ions get new identifier assigned in the process, this is the so-called - evaporation_identifier that is not to be confused with the pulse_identifier! + These ions get new identifier assigned in the process (the so-called + evaporation_identifier). This identifier must not be confused with + the pulse_identifier. type: group NXapm(NXobject): (NXentry): - exists: [min, 1, max, unbounded] + exists: [min, 1, max, infty] \@version(NX_CHAR): doc: | An at least as strong as SHA256 hashvalue of the @@ -61,23 +62,25 @@ NXapm(NXobject): run_number(NX_CHAR): 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 run_number from IVAS/APSuite. + The identifier whereby the experiment is referred to in the control software. + This is neither the specimen_name nor the experiment_identifier. For + Local Electrode Atom Probe (LEAP) instruments, it is recommended to use the + run_number from the proprietary software IVAS/APSuite of AMETEK/Cameca. For other instruments, such as the one from Stuttgart or Oxcart from Erlangen, - or the instruments at GPM in Rouen, use the identifier which is closest in meaning - to the LEAP run number. + or the instruments at GPM in Rouen, use the identifier which matches + best conceptually to the LEAP run number. The field does not have to be required if the information is recoverable - in the dataset which for LEAP instruments is the case when RHIT or HITS - files are also stored alongside a data artifact. With NXapm the RHIT or HITS - can be stored as via the NXserialized group in the hit_finding algorithm section. + in the dataset which for LEAP instruments is the case (provided these + RHIT or HITS files respectively are stored alongside a data artifact). + With NXapm the RHIT or HITS can be stored as via the NXserialized group + in the hit_finding algorithm section. As a destructive microscopy technique, a run can be performed only once. It is possible, however, to interrupt a run and restart data acquisition while still using the same specimen. In this case, each evaporation run needs to be distinguished with different run numbers. - We follow this habit of most atom probe groups. - Therefore, interrupted runs should be stored as individual NXentry instances! + We follow this habit of most atom probe groups. Such interrupted runs + should be stored as individual :ref:`NXentry` instances in one NeXus file. # alias experiment_alias # experiment_description(NX_CHAR): # optional quantities do not need to be mentioned in an appdef because they can always be added @@ -90,30 +93,27 @@ NXapm(NXobject): # if you think about you being the consuming human (agent) also you would like to know # if there is a run_number for the atom probe measurement from your colleague i.e. you # effectively ask your colleague for that information while working off your imagined list of requirements - # the appdef definition here is nothing else then document this for a software + # the appdef definition here is nothing else then the documentation of this for a software start_time(NX_DATE_TIME): doc: | ISO 8601 time code with local time zone offset to UTC information - included when the 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. + included when the atom probe session started. If the exact duration of + the measurement is not relevant start_time only should be used. - Often though it is useful to specify 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 + Often though it is useful to specify both start_time and end_time to + capture more detailed bookkeeping of the experiment. The user should + be aware that even with having both dates specified, it may not be + possible to infer how long the experiment took or for how long data were collected. More detailed timing data over the course of the experiment have to be - collected to compute this event chain during the experiment. + collected to compute this event chain during the experiment. For this + purpose the :ref:`NXevent_data_apm` instance should be used. end_time(NX_DATE_TIME): exists: recommended doc: | ISO 8601 time code with local time zone offset to UTC included - when the microscope session ended. + when the atom probe session ended. (NXcite): exists: [min, 0, max, infty] doi(NX_CHAR): @@ -125,53 +125,57 @@ NXapm(NXobject): algorithm(NX_CHAR): operation_mode(NX_CHAR): doc: | - What type of atom probe microscopy experiment is performed? This field is - meant to inform research data management systems to allow filtering: + What type of atom probe experiment is performed? This field is meant to + inform research data management systems to allow filtering: * apt are experiments where the analysis_chamber has no imaging gas. experiment with LEAP instruments are typically performed such. * fim are experiments where the analysis_chamber has an imaging gas, which should be specified with the atmosphere in the analysis_chamber group. * apt_fim should be used for combinations of the two imaging modes. - few experiments of this type have been performed as this can be detrimental - to LEAP systems (see `S. Katnagallu et al. `_). - * other should be used in combination with the user specifying details in the - experiment_documentation field. + few experiments of this type have been performed as this can be detrimental + to LEAP systems (see `S. Katnagallu et al. `_). + * other should be used in combination with the user specifying details + in the experiment_documentation field. enumeration: [apt, fim, apt_fim, other] (NXuser): exists: recommended name(NX_CHAR): + exists: recommended identifier(NXidentifier): exists: recommended service(NX_CHAR): identifier(NX_CHAR): is_persistent(NX_BOOLEAN): sample(NXsample): - exists: optional + 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. + atom probers about knowledge they have gained about the sample. There are cases where the specimen is machined further or exposed to external stimuli during the experiment. In this case, these details should - not be stored under sample here but atom probers should make suggestions + not be stored under sample but suggestions should be made how this application definition can be improved. In the future also details like how the grain_diameter was characterized, how the sample was prepared, how the material was heat-treated etc., - should be stored as using specific application definitions/schemas - which are then arranged and documented with a description of the workflow - so that actionable graphs become instantiatable. + should be stored. For this specific application definitions/schemas can be + used which are then arranged and documented with a description of the + workflow so that actionable graphs become instantiatable. method(NX_CHAR): exists: recommended doc: | - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) + A qualifier whether the sample is a real one + or a virtual one (in a computer simulation). enumeration: [experiment, simulation] + alias(NX_CHAR): + doc: | + Given name/alias for the sample. identifier(NXidentifier): - exists: optional + exists: recommended service(NX_CHAR): identifier(NX_CHAR): is_persistent(NX_BOOLEAN): @@ -182,15 +186,12 @@ NXapm(NXobject): 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 material yield strength 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. + diameter or radius is often referred to as grain size. - 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 + In atom probe it is possible that the specimen may contain a few + crystals only. In this case the grain_diameter is not a reliable + descriptor. Reporting a grain size may be useful though as it allows + judging if specific features are expected to be found in the detector hit map. unit: NX_LENGTH grain_diameter_error(NX_FLOAT): @@ -203,28 +204,26 @@ NXapm(NXobject): 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. + was heat treated. However, if a documentation of the annealing + treatment as a function of time is available one should better + rely on this information and have it stored alongside the NeXus file. + # schema for 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 + 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 idea how the sample was heat treated. However, there are many + situations where one can imagine that the scalar value for just the + quenching rate is insufficient. - An example is when the specimen was left in the furnace after the - furnace was switched off. In this case the specimen cools down with + An example is when the sample was left in the furnace after the + furnace was switched off. In this case the sample cools down with a specific rate of how this furnace cools down in the lab. Processes which in practice are often not documented. @@ -246,7 +245,7 @@ NXapm(NXobject): (NXchemical_composition): exists: recommended doc: | - The chemical composition of the sample. Typically it is assumed that + 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. @@ -258,10 +257,10 @@ NXapm(NXobject): total number of atoms which are of a particular type. By contrast, weight_percent normalization factorizes in the respective mass of the elements. Python libraries like pint are - challenged by these differences as at.-% and wt.-% both yield + challenged by these differences as at.-% and wt.-% are both fractional quantities. enumeration: [atom_percent, weight_percent] - ION(NXion): + (NXion): exists: [min, 1, max, 118] chemical_symbol(NX_CHAR): doc: | @@ -281,13 +280,18 @@ NXapm(NXobject): Magnitude of the standard deviation of the composition (value). unit: NX_DIMENSIONLESS specimen(NXsample): - exists: optional + exists: recommended method(NX_CHAR): exists: recommended doc: | - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) + A qualifier whether the sample is a real one + or a virtual one (in a computer simulation). enumeration: [experiment, simulation] + alias(NX_CHAR): + exists: recommended + doc: | + Given name an alias. Better use identifier and parent_identifier instead. + A single NXentry should be used only for the characterization of a single specimen. identifier(NXidentifier): exists: recommended service(NX_CHAR): @@ -296,9 +300,9 @@ NXapm(NXobject): parent_identifier(NXidentifier): exists: recommended doc: | - Identifier of the sample from which the sample was cut or the string - *None*. The purpose of this field is to support functionalities - for tracking sample provenance via a research data management system. + Identifier of the sample from which the specimen was cut or the string + n/a. The purpose of this field is to support functionalities for + tracking sample provenance via a research data management system. service(NX_CHAR): identifier(NX_CHAR): is_persistent(NX_BOOLEAN): @@ -317,15 +321,10 @@ NXapm(NXobject): especially required for environmentally sensitive material such as hydrogen charged specimens or experiments including tracers with a short half time. Additional time stamps prior to preparation_date - should better be placed in resources which describe but which do not pollute - the description here with prose. Resolving these connected pieces of information - is considered within the responsibility of the research data management - system. - alias(NX_CHAR): - exists: recommended - doc: | - Given name an alias. Better use identifier and parent_identifier instead. - A single NXentry should be used only for the characterization of a single specimen. + should better be placed in resources which describe but which do not + pollute the description here with prose. Resolving these connected + pieces of information is considered within the responsibility of the + research data management system. atom_types(NX_CHAR): doc: | List of comma-separated elements from the periodic table that are @@ -337,7 +336,7 @@ NXapm(NXobject): opportunity to parse the relevant elements without having to interpret these from the resources pointed to by parent_identifier or walk through eventually deeply nested groups in data instances. - description: + description(NX_CHAR): exists: optional doc: | Discouraged free-text field. @@ -398,9 +397,8 @@ NXapm(NXobject): 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. + To avoid these ambiguities, instances of :ref:`NXtransformations` should + be used. (NXcoordinate_system): exists: [min, 1, max, infty] origin(NX_CHAR): @@ -455,7 +453,8 @@ NXapm(NXobject): model(NX_CHAR): wavelength(NX_FLOAT): # stage_lab(NXstage_lab): - # analysis_chamber(NXchamber): + analysis_chamber(NXchamber): + # atmosphere(NXcollection): # buffer_chamber(NXchamber): # load_lock_chamber(NXchamber): # getter_pump(NXpump): @@ -480,9 +479,8 @@ NXapm(NXobject): # decelerate_electrode(NXlens_em): # local_electrode(NXlens_em): ion_detector(NXdetector): - signal_amplitude(NX_FLOAT): - unit: NX_CURRENT - dim: (p,) + exists: optional + # signal_amplitude(NX_FLOAT): pulser(NXpulser_apm): pulse_frequency(NX_FLOAT): # unit: NX_FREQUENCY @@ -555,7 +553,9 @@ NXapm(NXobject): checksum(NX_CHAR): algorithm(NX_CHAR): number_of_dld_wires(NX_UINT): + exists: recommended arrival_time_pairs(NX_NUMBER): + exists: optional # results of the hit_finding algorithm hit_positions(NX_NUMBER): dim: (i, 2) @@ -593,7 +593,7 @@ NXapm(NXobject): evaporation_identifier_offset(NX_INT): doc: | Integer used to name the first pulse to know if there is an - offset of the identifiers to zero. + offset of the evaporation_identifier to zero. Identifiers can be defined either implicitly or explicitly. For implicit indexing identifiers are defined on the interval @@ -611,11 +611,12 @@ NXapm(NXobject): doc: | (Molecular) ion identifier which resolves the sequence in which the ions were evaporated but taking into account that a hit_finding - and spatial filtering was applied. + and spatial_filtering was applied. unit: NX_UNITLESS dim: (n,) hit_filter(NXcs_filter_boolean_mask): - # use NXcs_filterneeds conditionally an instance of concept ../../hit_finding + exists: recommended + # use NXcs_filter needs conditionally an instance of concept ../../hit_finding number_of_objects(NX_UINT): bitdepth(NX_UINT): mask(NX_UINT): @@ -642,6 +643,7 @@ NXapm(NXobject): # 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 dim: (n,) # result calibrated_tof(NX_FLOAT): @@ -784,7 +786,7 @@ NXapm(NXobject): program(NX_CHAR): \@version(NX_CHAR): (NXion): - exists: [min, 0, max, 256] + exists: [min, 1, max, 256] isotope_vector(NX_UINT): charge_state(NX_INT): mass_to_charge_range(NX_FLOAT): From 8fd635bf96f4dfbdb9f8aa7e3ece7edde0869c01 Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 8 Jan 2024 10:15:44 +0100 Subject: [PATCH 0438/1012] NXdetector/data field names moved to separate file --- base_classes/NXdata.nxdl.xml | 835 +++++++++--------- .../NXdata_mpes_detector.nxdl.xml | 127 +++ contributed_definitions/NXmpes.nxdl.xml | 118 +-- .../nyaml/NXdata_mpes_detector.yaml | 96 ++ contributed_definitions/nyaml/NXmpes.yaml | 107 +-- 5 files changed, 706 insertions(+), 577 deletions(-) create mode 100644 contributed_definitions/NXdata_mpes_detector.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXdata_mpes_detector.yaml diff --git a/base_classes/NXdata.nxdl.xml b/base_classes/NXdata.nxdl.xml index e57fc30b7c..8e6aab572f 100644 --- a/base_classes/NXdata.nxdl.xml +++ b/base_classes/NXdata.nxdl.xml @@ -1,10 +1,10 @@ - - + + - - - - - - These symbols will be used below to coordinate fields with the same shape. - rank of the ``DATA`` field - length of the ``AXISNAME`` field - length of the ``x`` field - length of the ``y`` field - length of the ``z`` field - - - - - .. index:: plotting - - Array of strings holding the :ref:`names <validItemName>` of additional - signals to be plotted with the default :ref:`signal </NXdata@signal-attribute>`. - These fields or links *must* exist and be direct children of this NXdata group. - - Each auxiliary signal needs to be of the same shape as the default signal. - - .. NIAC2018: - https://www.nexusformat.org/NIAC2018Minutes.html - - - - - .. 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 <validItemName>` 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. - - - - - .. index:: plotting - - Array of strings holding the :ref:`names <validItemName>` of - the independent data fields used in the default plot for all of - the dimensions of the :ref:`signal </NXdata@signal-attribute>` - as well as any :ref:`auxiliary signals </NXdata@auxiliary_signals-attribute>`. - - 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. - - - - - - - Each ``AXISNAME_indices`` attribute indicates the dependency - relationship of the ``AXISNAME`` field (where ``AXISNAME`` - is the name of a field that exists in this ``NXdata`` group) - with one or more dimensions of the plottable data. - - Integer array that defines the indices of the *signal* field - (that field will be a multidimensional array) - which need to be used in the *AXISNAME* field in - order to reference the corresponding axis value. - - The first index of an array is ``0`` (zero). - - Here, *AXISNAME* is to be replaced by the name of each - field described in the ``axes`` attribute. - An example with 2-D data, :math:`d(t,P)`, will illustrate:: - - data_2d:NXdata - @signal="data" - @axes=["time", "pressure"] - @time_indices=0 - @pressure_indices=1 - data: float[1000,20] - time: float[1000] - pressure: float[20] - - This attribute is to be provided in all situations. - However, if the indices attributes are missing - (such as for data files written before this specification), - file readers are encouraged to make their best efforts - to plot the data. - Thus the implementation of the - ``AXISNAME_indices`` attribute is based on the model of - "strict writer, liberal reader". - - .. note:: Attributes potentially containing multiple values - (axes and _indices) are to be written as string or integer arrays, - to avoid string parsing in reading applications. - - - - - :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) - + + + + + These symbols will be used below to coordinate fields with the same + shape. + + + + rank of the ``DATA`` field + + + + + length of the ``AXISNAME`` field + + + + + length of the ``x`` field + + + + + length of the ``y`` field + + + + + length of the ``z`` field + + + + + :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) + + + + .. index:: plotting + + Array of strings holding the :ref:`names <validItemName>` of additional + signals to be plotted with the default :ref:`signal </NXdata@signal-attribute>`. + These fields or links *must* exist and be direct children of this NXdata group. + + Each auxiliary signal needs to be of the same shape as the default signal. + + .. NIAC2018: + https://www.nexusformat.org/NIAC2018Minutes.html + + + + + .. 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 <validItemName>` 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. + + + + + .. index:: plotting + + Array of strings holding the :ref:`names <validItemName>` of + the independent data fields used in the default plot for all of + the dimensions of the :ref:`signal </NXdata@signal-attribute>` + as well as any :ref:`auxiliary signals </NXdata@auxiliary_signals-attribute>`. + + 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. + + + + + + + Each ``AXISNAME_indices`` attribute indicates the dependency + relationship of the ``AXISNAME`` field (where ``AXISNAME`` + is the name of a field that exists in this ``NXdata`` group) + with one or more dimensions of the plottable data. + + Integer array that defines the indices of the *signal* field + (that field will be a multidimensional array) + which need to be used in the *AXISNAME* field in + order to reference the corresponding axis value. + + The first index of an array is ``0`` (zero). + + Here, *AXISNAME* is to be replaced by the name of each + field described in the ``axes`` attribute. + An example with 2-D data, :math:`d(t,P)`, will illustrate:: + + data_2d:NXdata + @signal="data" + @axes=["time", "pressure"] + @time_indices=0 + @pressure_indices=1 + data: float[1000,20] + time: float[1000] + pressure: float[20] + + This attribute is to be provided in all situations. + However, if the indices attributes are missing + (such as for data files written before this specification), + file readers are encouraged to make their best efforts + to plot the data. + Thus the implementation of the + ``AXISNAME_indices`` attribute is based on the model of + "strict writer, liberal reader". + + .. note:: Attributes potentially containing multiple values + (axes and _indices) are to be written as string or integer arrays, + to avoid string parsing in reading applications. + + Points to the path to a field defining the axis on which the ``AXISNAME`` axis depends. @@ -290,154 +300,165 @@ @AXISNAME_depends: '/entry/instrument/detector/AXISNAME' for a 2D detector - - - 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. - - - - A *dimension scale* must have a rank of 1 and has length ``n``. - - - - Axis label - - - ``0|false``: single value, - ``1|true``: multiple values - - - Index of first good value - Index of last good value - - - Index (positive integer) identifying this specific set of numbers. - - N.B. The ``axis`` attribute is the old way of designating a link. - Do not use the ``axes`` attribute with the ``axis`` attribute. - The ``axes`` *group* attribute is now preferred. - - - - - - "Errors" (meaning *uncertainties* or *standard deviations*) - associated with any field named ``FIELDNAME`` in this ``NXdata`` - group (e.g. an axis, signal or auxiliary signal). - - The dimensions of the ``FIELDNAME_errors`` field must match - the dimensions of the ``FIELDNAME`` field. - - - - - .. 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. - - - - The rank (``dataRank``) of the ``data`` must satisfy - ``1 <= dataRank <= NX_MAXRANK=32``. - At least one ``dim`` must have length ``n``. - - - - - .. index:: plotting - - Plottable (independent) axis, indicate index number. - Only one field in a :ref:`NXdata` group may have the - ``signal=1`` attribute. - Do not use the ``signal`` attribute with the ``axis`` attribute. - - - - - Defines the names of the dimension scales - (independent axes) for this data set - as a colon-delimited array. - NOTE: The ``axes`` attribute is the preferred - method of designating a link. - Do not use the ``axes`` attribute with the ``axis`` attribute. - - - - data label - - - - - Standard deviations of data values - - the data array is identified by the group attribute ``signal``. - The ``errors`` array must have the same dimensions as ``DATA``. - Client is responsible for defining the dimensions of the data. - - - - The ``errors`` must have - the same rank (``dataRank``) - as the ``data``. - At least one ``dim`` must have length "n". - - - - - - The elements in data are usually float values really. For - efficiency reasons these are usually stored as integers - after scaling with a scale factor. This value is the scale - factor. It is required to get the actual physical value, - when necessary. - - - - - An optional offset to apply to the values in data. - - - - - Title for the plot. - - - - - This is an array holding the values to use for the x-axis of - data. The units must be appropriate for the measurement. - - - - - - - - This is an array holding the values to use for the y-axis of - data. The units must be appropriate for the measurement. - - - - - - - - This is an array holding the values to use for the z-axis of - data. The units must be appropriate for the measurement. - - - - - + + + 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. + + + + A *dimension scale* must have a rank of 1 and has length ``n``. + + + + + + Axis label + + + + + ``0|false``: single value, + ``1|true``: multiple values + + + + + Index of first good value + + + + + Index of last good value + + + + + Index (positive integer) identifying this specific set of numbers. + + N.B. The ``axis`` attribute is the old way of designating a link. + Do not use the ``axes`` attribute with the ``axis`` attribute. + The ``axes`` *group* attribute is now preferred. + + + + + + "Errors" (meaning *uncertainties* or *standard deviations*) + associated with any field named ``FIELDNAME`` in this ``NXdata`` + group (e.g. an axis, signal or auxiliary signal). + + The dimensions of the ``FIELDNAME_errors`` field must match + the dimensions of the ``FIELDNAME`` field. + + + + + .. 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. + + + + The rank (``dataRank``) of the ``data`` must satisfy + ``1 <= dataRank <= NX_MAXRANK=32``. + At least one ``dim`` must have length ``n``. + + + + + .. index:: plotting + + Plottable (independent) axis, indicate index number. + Only one field in a :ref:`NXdata` group may have the + ``signal=1`` attribute. + Do not use the ``signal`` attribute with the ``axis`` attribute. + + + + + Defines the names of the dimension scales + (independent axes) for this data set + as a colon-delimited array. + NOTE: The ``axes`` attribute is the preferred + method of designating a link. + Do not use the ``axes`` attribute with the ``axis`` attribute. + + + + + data label + + + + + + Standard deviations of data values - + the data array is identified by the group attribute ``signal``. + The ``errors`` array must have the same dimensions as ``DATA``. + Client is responsible for defining the dimensions of the data. + + + + The ``errors`` must have + the same rank (``dataRank``) + as the ``data``. + At least one ``dim`` must have length "n". + + + + + + The elements in data are usually float values really. For + efficiency reasons these are usually stored as integers + after scaling with a scale factor. This value is the scale + factor. It is required to get the actual physical value, + when necessary. + + + + + An optional offset to apply to the values in data. + + + + + Title for the plot. + + + + + This is an array holding the values to use for the x-axis of + data. The units must be appropriate for the measurement. + + + + + + + + This is an array holding the values to use for the y-axis of + data. The units must be appropriate for the measurement. + + + + + + + + This is an array holding the values to use for the z-axis of + data. The units must be appropriate for the measurement. + + + + + diff --git a/contributed_definitions/NXdata_mpes_detector.nxdl.xml b/contributed_definitions/NXdata_mpes_detector.nxdl.xml new file mode 100644 index 0000000000..130683c223 --- /dev/null +++ b/contributed_definitions/NXdata_mpes_detector.nxdl.xml @@ -0,0 +1,127 @@ + + + + + + :ref:`NXdata_mpes_detector` describes the plottable data and related dimension scales + for raw detector data in MPES experiments. + + It extends the NXdata class and provides a glossary of explicitly named axis names + which are typical for raw MPES data. + + + + + + + + + Raw data before calibration. + + + + + + Detector pixel in x direction. + + + + + Detector pixel in y direction. + + + + + + In DAQ clock pulses + + + + + + Total time of flight + + + + + Time-of-flight values, analog-to-digital converted. + + + + + Polar rotation angle of the manipulator. + + + + + Azimuthal rotation angle of the manipulator. + + + + + Delay position of delay line detector. + + + + + Delay position of delay line detector, analog-to-digital converted. + + + + + Time delay of delay line detector. + + + + + Time delay of delay line detector. + + + + + Measured detector voltage + + + + + Describes an axis which is coming from outside the detectors scope. + + Think of a detector just being triggered for readout by the rest of the experimental setup - + it would just know that it collected N images, which would flatten the external parameters to one axis, too. + This can then be linked, e.g. with NXcalibration, to the appropriate fields in the instrument and write it to the + top-level NXdata. + + + + + missing + + + + + missing + + + diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 769af66f4d..42ec54fbc5 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -338,7 +338,18 @@ Optional constant settings (like lens focusing parameters on the sample: positio - + + + + Contains the raw data collected by the detector before calibration. + The data which is considered raw might change from experiment to experiment + due to hardware pre-processing of the data. + This field ideally collects the data with the lowest level of processing + possible. + @@ -349,91 +360,6 @@ Optional constant settings (like lens focusing parameters on the sample: positio Raw data before calibration. - - - - Detector pixel in x direction. - - - - - Detector pixel in y direction. - - - - - - In DAQ clock pulses - - - - - - Total time of flight - - - - - Time-of-flight values, analog-to-digital converted. - - - - - Polar rotation angle of the manipulator. - - - - - Azimuthal rotation angle of the manipulator. - - - - - Delay position of delay line detector. - - - - - Delay position of delay line detector, analog-to-digital converted. - - - - - Time delay of delay line detector. - - - - - Time delay of delay line detector. - - - - - Measured detector voltage - - - - - Describes an axis which is coming from outside the detectors scope. - - Think of a detector just being triggered for readout by the rest of the experimental setup - - it would just know that it collected N images, which would flatten the external parameters to one axis, too. - This can then be linked, e.g. with NXcalibration, to the appropriate fields in the instrument and write it to the - top-level NXdata. - - - - - missing - - - - - missing - - @@ -660,7 +586,25 @@ there is also x_pixel_offset in NXdetector base class - + + + An NXdata field containing a view on the measured links. + This data fields contains a collection of the main releveant fields. + The data fields ideally should be named according to conventions + to ensure compatibility. We recommened the following field names + for common data fields: + + - **kx**: Calibrated x axis in k-space. Units should be 1/Angström. + - **ky**: Calibrated y axis in k-space. Units should be 1/Angström. + - **kz**: Calibrated z axis in k-space. Units should be 1/Angström. + - **delay**: Calibrated delay time. The unit category should be NX_TIME. + - **polarization_angle**: Linear polarization angle of the incoming or + outgoing beam. The unit category should be NX_ANGLE. + - **ellipticity**: Ellipticity of the incoming or outgoing beam. Can be + any of linear polarization angle (degrees), ellipticity (arb. units). + diff --git a/contributed_definitions/nyaml/NXdata_mpes_detector.yaml b/contributed_definitions/nyaml/NXdata_mpes_detector.yaml new file mode 100644 index 0000000000..9378d619ef --- /dev/null +++ b/contributed_definitions/nyaml/NXdata_mpes_detector.yaml @@ -0,0 +1,96 @@ +category: base +doc: | + :ref:`NXdata_mpes_detector` describes the plottable data and related dimension scales + for raw detector data in MPES experiments. + + It extends the NXdata class and provides a glossary of explicitly named axis names + which are typical for raw MPES data. +type: group +NXdata_mpes_detector(NXdata): + \@signal: + enumeration: [raw] + raw(NX_NUMBER): + doc: | + Raw data before calibration. + pixel_x(NX_FLOAT): + exists: optional + unit: NX_ANY + + # there is also x_pixel_offset in NXdetector base class + doc: | + Detector pixel in x direction. + pixel_y(NX_FLOAT): + exists: optional + unit: NX_ANY + doc: | + Detector pixel in y direction. + + # exists in NXdetector base class + raw_time_of_flight(NX_INT): + exists: optional + unit: NX_PULSES + doc: | + In DAQ clock pulses + + # exists in NXdetector base class + time_of_flight(NX_FLOAT): + exists: optional + unit: NX_TIME_OF_FLIGHT + doc: | + Total time of flight + time_of_flight_adc(NX_FLOAT): + exists: optional + unit: NX_ANY + doc: | + Time-of-flight values, analog-to-digital converted. + polar_angle_manipulator(NX_FLOAT): + exists: optional + unit: NX_ANGLE + doc: | + Polar rotation angle of the manipulator. + azimuthal_angle_manipulator(NX_FLOAT): + exists: optional + unit: NX_ANGLE + doc: | + Azimuthal rotation angle of the manipulator. + delay_position(NX_FLOAT): + exists: optional + unit: NX_LENGTH + doc: | + Delay position of delay line detector. + delay_position_ADC(NX_FLOAT): + exists: optional + unit: NX_ANY + doc: | + Delay position of delay line detector, analog-to-digital converted. + time_delay_x(NX_FLOAT): + exists: optional + unit: NX_TIME + doc: | + Time delay of delay line detector. + time_delay_y(NX_FLOAT): + exists: optional + unit: NX_TIME + doc: | + Time delay of delay line detector. + voltage(NX_FLOAT): + exists: optional + unit: NX_VOLTAGE + doc: | + Measured detector voltage + external_AXIS(NX_NUMBER): + exists: optional + unit: NX_ANY + doc: | + Describes an axis which is coming from outside the detectors scope. + + Think of a detector just being triggered for readout by the rest of the experimental setup - + it would just know that it collected N images, which would flatten the external parameters to one axis, too. + This can then be linked, e.g. with NXcalibration, to the appropriate fields in the instrument and write it to the + top-level NXdata. + magnetization(NX_CHAR): + doc: | + missing + scattering_direction(NX_CHAR): + doc: | + missing diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 0a7bc39972..6be3a9b96c 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -272,95 +272,21 @@ NXmpes(NXobject): exists: recommended identifier: exists: recommended - (NXdata): + data(NXdata): + # ToDo: With base class inheritance this should be + # a field of type NXdata_mpes_detector + doc: | + Contains the raw data collected by the detector before calibration. + The data which is considered raw might change from experiment to experiment + due to hardware pre-processing of the data. + This field ideally collects the data with the lowest level of processing + possible. exists: recommended \@signal: enumeration: [raw] raw(NX_NUMBER): doc: | Raw data before calibration. - pixel_x(NX_FLOAT): - exists: optional - unit: NX_ANY - - # there is also x_pixel_offset in NXdetector base class - doc: | - Detector pixel in x direction. - pixel_y(NX_FLOAT): - exists: optional - unit: NX_ANY - doc: | - Detector pixel in y direction. - - # exists in NXdetector base class - raw_time_of_flight(NX_INT): - exists: optional - unit: NX_PULSES - doc: | - In DAQ clock pulses - - # exists in NXdetector base class - time_of_flight(NX_FLOAT): - exists: optional - unit: NX_TIME_OF_FLIGHT - doc: | - Total time of flight - time_of_flight_adc(NX_FLOAT): - exists: optional - unit: NX_ANY - doc: | - Time-of-flight values, analog-to-digital converted. - polar_angle_manipulator(NX_FLOAT): - exists: optional - unit: NX_ANGLE - doc: | - Polar rotation angle of the manipulator. - azimuthal_angle_manipulator(NX_FLOAT): - exists: optional - unit: NX_ANGLE - doc: | - Azimuthal rotation angle of the manipulator. - delay_position(NX_FLOAT): - exists: optional - unit: NX_LENGTH - doc: | - Delay position of delay line detector. - delay_position_ADC(NX_FLOAT): - exists: optional - unit: NX_ANY - doc: | - Delay position of delay line detector, analog-to-digital converted. - time_delay_x(NX_FLOAT): - exists: optional - unit: NX_TIME - doc: | - Time delay of delay line detector. - time_delay_y(NX_FLOAT): - exists: optional - unit: NX_TIME - doc: | - Time delay of delay line detector. - voltage(NX_FLOAT): - exists: optional - unit: NX_VOLTAGE - doc: | - Measured detector voltage - external_AXIS(NX_NUMBER): - exists: optional - unit: NX_ANY - doc: | - Describes an axis which is coming from outside the detectors scope. - - Think of a detector just being triggered for readout by the rest of the experimental setup - - it would just know that it collected N images, which would flatten the external parameters to one axis, too. - This can then be linked, e.g. with NXcalibration, to the appropriate fields in the instrument and write it to the - top-level NXdata. - magnetization(NX_CHAR): - doc: | - missing - scattering_direction(NX_CHAR): - doc: | - missing (NXmanipulator): exists: optional doc: | @@ -565,6 +491,21 @@ NXmpes(NXobject): Voltage applied to sample and sample holder. (NXdata): # to be replaced by NXdata_mpes with base class inheritance + doc: | + An NXdata field containing a view on the measured links. + This data fields contains a collection of the main releveant fields. + The data fields ideally should be named according to conventions + to ensure compatibility. We recommened the following field names + for common data fields: + + - **kx**: Calibrated x axis in k-space. Units should be 1/Angström. + - **ky**: Calibrated y axis in k-space. Units should be 1/Angström. + - **kz**: Calibrated z axis in k-space. Units should be 1/Angström. + - **delay**: Calibrated delay time. The unit category should be NX_TIME. + - **polarization_angle**: Linear polarization angle of the incoming or + outgoing beam. The unit category should be NX_ANGLE. + - **ellipticity**: Ellipticity of the incoming or outgoing beam. Can be + any of linear polarization angle (degrees), ellipticity (arb. units). \@signal: enumeration: [data] data(NX_NUMBER): From db7ec3d871749b97a77b947605081362b61dfa86 Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 8 Jan 2024 10:20:46 +0100 Subject: [PATCH 0439/1012] Docstring for detector/data added --- contributed_definitions/NXmpes.nxdl.xml | 17 +++++++++++++++++ contributed_definitions/nyaml/NXmpes.yaml | 17 +++++++++++++++++ 2 files changed, 34 insertions(+) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 42ec54fbc5..725e268c5d 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -349,6 +349,23 @@ a field of type NXdata_mpes_detector due to hardware pre-processing of the data. This field ideally collects the data with the lowest level of processing possible. + + The naming of fields should follow a convention to ensure compatibility. + It is recommend to use the following field names: + + - **pixel_x**: Detector pixel in x direction. + - **pixel_y**: Detector pixel in y direction. + - **raw_time_of_flight**: The raw time of flight in DAQ clock pulses. + - **time_of_flight**: Total time of flight. + - **time_of_flight_adc**: Time-of-flight values, analog-to-digital converted. + - **polar_angle_manipulator**: Polar rotation angle of the manipulator. + - **azimuthal_angle_manipulator**: Azimuthal rotation angle of the manipulator. + - **delay_position**: Delay position of delay line detector. + - **delay_position_ADC**: Delay position of delay line detector, analog-to-digital converted. + - **time_delay_x**: Time delay of delay line detector in x direction. + - **time_delay_y**: Time delay of delay line detector in y direction. + - **voltage**: Voltage applied to sample and sample holder. + - **external_AXIS**: Describes an axis which is coming from outside the detectors scope. diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 6be3a9b96c..ad9b3e731a 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -281,6 +281,23 @@ NXmpes(NXobject): due to hardware pre-processing of the data. This field ideally collects the data with the lowest level of processing possible. + + The naming of fields should follow a convention to ensure compatibility. + It is recommend to use the following field names: + + - **pixel_x**: Detector pixel in x direction. + - **pixel_y**: Detector pixel in y direction. + - **raw_time_of_flight**: The raw time of flight in DAQ clock pulses. + - **time_of_flight**: Total time of flight. + - **time_of_flight_adc**: Time-of-flight values, analog-to-digital converted. + - **polar_angle_manipulator**: Polar rotation angle of the manipulator. + - **azimuthal_angle_manipulator**: Azimuthal rotation angle of the manipulator. + - **delay_position**: Delay position of delay line detector. + - **delay_position_ADC**: Delay position of delay line detector, analog-to-digital converted. + - **time_delay_x**: Time delay of delay line detector in x direction. + - **time_delay_y**: Time delay of delay line detector in y direction. + - **voltage**: Voltage applied to sample and sample holder. + - **external_AXIS**: Describes an axis which is coming from outside the detectors scope. exists: recommended \@signal: enumeration: [raw] From dbfb264101efc8b683828033db2d74e7f0337d61 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 8 Jan 2024 10:50:41 +0100 Subject: [PATCH 0440/1012] change docstring in AXISNAME_depends --- base_classes/NXdata.nxdl.xml | 31 ++++++++++++++++++------------- base_classes/nyaml/NXdata.yaml | 13 +++++++++---- 2 files changed, 27 insertions(+), 17 deletions(-) diff --git a/base_classes/NXdata.nxdl.xml b/base_classes/NXdata.nxdl.xml index 8e6aab572f..d1f82ee7c5 100644 --- a/base_classes/NXdata.nxdl.xml +++ b/base_classes/NXdata.nxdl.xml @@ -285,19 +285,24 @@ AXISNAME_indices documentation copied from datarules.rst - Points to the path to a field defining the axis on which the ``AXISNAME`` axis depends. - - This concept allows to store a link to an axis to a respective field the Nexus hierarchy - - Here, *AXISNAME* is to be replaced by the name of each - field described in the ``axes`` attribute. - - Examples: - If a calibration has been performed, ``@AXISNAME_depends`` links to the result of - that calibration: - @AXISNAME_depends: '/entry/process/calibration/calibrated_axis' - If the axis is given in a detecotr, ``@AXISNAME_depends`` links to that detector axis: - @AXISNAME_depends: '/entry/instrument/detector/AXISNAME' for a 2D detector + Points to the path of a field defining the axis on which the ``AXISNAME`` axis depends. + + This concept allows to link an axis to a respective field in the Nexus hierarchy, thereby + defining the physical quantity it represents. + + Here, *AXISNAME* is to be replaced by the name of each + field described in the ``axes`` attribute. + + Examples: + If a calibration has been performed, ``@AXISNAME_depends`` links to the result of + that calibration: + @AXISNAME_depends: '/entry/process/calibration/calibrated_axis' + If the axis corresponds to a coordinate of a detector, ``@AXISNAME_depends`` links + to that detector axis: + @AXISNAME_depends: '/entry/instrument/detector/axis/AXISNAME' for a 2D detector + If the axis is a scanned motor, ``@AXISNAME_depends`` links to the transformation + describing the respective motion, e.g.: + @AXISNAME_depends: '/entry/instrument/detector/transformations/AXISNAME' for a motion of the detector diff --git a/base_classes/nyaml/NXdata.yaml b/base_classes/nyaml/NXdata.yaml index 8e2d7cd2ed..81774da799 100644 --- a/base_classes/nyaml/NXdata.yaml +++ b/base_classes/nyaml/NXdata.yaml @@ -239,9 +239,10 @@ NXdata(NXobject): to avoid string parsing in reading applications. \@AXISNAME_depends: doc: | - Points to the path to a field defining the axis on which the ``AXISNAME`` axis depends. + Points to the path of a field defining the axis on which the ``AXISNAME`` axis depends. - This concept allows to store a link to an axis to a respective field the Nexus hierarchy + This concept allows to link an axis to a respective field in the Nexus hierarchy, thereby + defining the physical quantity it represents. Here, *AXISNAME* is to be replaced by the name of each field described in the ``axes`` attribute. @@ -250,8 +251,12 @@ NXdata(NXobject): If a calibration has been performed, ``@AXISNAME_depends`` links to the result of that calibration: @AXISNAME_depends: '/entry/process/calibration/calibrated_axis' - If the axis is given in a detecotr, ``@AXISNAME_depends`` links to that detector axis: - @AXISNAME_depends: '/entry/instrument/detector/AXISNAME' for a 2D detector + If the axis corresponds to a coordinate of a detector, ``@AXISNAME_depends`` links + to that detector axis: + @AXISNAME_depends: '/entry/instrument/detector/axis/AXISNAME' for a 2D detector + If the axis is a scanned motor, ``@AXISNAME_depends`` links to the transformation + describing the respective motion, e.g.: + @AXISNAME_depends: '/entry/instrument/detector/transformations/AXISNAME' for a motion of the detector AXISNAME(NX_NUMBER): nameType: any doc: | From 34fc49b46221a94dcce242c56b976759542c2ced Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Mon, 8 Jan 2024 10:55:11 +0100 Subject: [PATCH 0441/1012] Fixed issues detected during make local, manual builds successfully, open issue: appdefs require redefinition of properties from inherited base classes violates single source principle --- Makefile | 2 + contributed_definitions/NXapm.nxdl.xml | 1867 +++------- .../NXapm_charge_state_analysis.nxdl.xml | 157 + .../NXapm_hit_finding.nxdl.xml | 125 + contributed_definitions/NXapm_msr.nxdl.xml | 176 + .../NXapm_paraprobe_ranger_config.nxdl.xml | 240 ++ .../NXapm_paraprobe_ranger_results.nxdl.xml | 259 ++ .../NXapm_paraprobe_tool_config.nxdl.xml | 140 + .../NXapm_paraprobe_tool_results.nxdl.xml | 136 + ...NXapm_paraprobe_transcoder_config.nxdl.xml | 79 + ...Xapm_paraprobe_transcoder_results.nxdl.xml | 197 + .../NXapm_ranging.nxdl.xml | 111 + .../NXapm_reconstruction.nxdl.xml | 102 + contributed_definitions/NXapm_sim.nxdl.xml | 40 + .../NXapm_volt_and_bowl.nxdl.xml | 69 + .../NXcg_marching_cubes.nxdl.xml | 33 +- .../NXcs_filter_boolean_mask.nxdl.xml | 38 +- .../NXdelocalization.nxdl.xml | 52 +- .../NXevent_data_apm.nxdl.xml | 265 ++ .../NXevent_data_apm_set.nxdl.xml | 48 + contributed_definitions/NXion.nxdl.xml | 70 +- contributed_definitions/NXisocontour.nxdl.xml | 29 +- .../NXmatch_filter.nxdl.xml | 21 +- contributed_definitions/NXpeak.nxdl.xml | 18 +- contributed_definitions/NXpulser_apm.nxdl.xml | 162 +- contributed_definitions/NXreflectron.nxdl.xml | 66 +- .../NXsimilarity_grouping.nxdl.xml | 95 +- .../NXspatial_filter.nxdl.xml | 74 +- .../NXsubsampling_filter.nxdl.xml | 32 +- .../nyaml/{refactor => }/NXapm.yaml | 10 +- .../NXapm_charge_state_analysis.yaml | 0 .../NXapm_composition_space_results.yaml | 0 .../{refactor => }/NXapm_hit_finding.yaml | 8 +- .../nyaml/{refactor => }/NXapm_msr.yaml | 2 +- .../NXapm_paraprobe_config_clusterer.yaml | 0 .../NXapm_paraprobe_config_distancer.yaml | 0 .../NXapm_paraprobe_config_intersector.yaml | 0 .../NXapm_paraprobe_config_nanochem.yaml | 0 .../NXapm_paraprobe_config_selector.yaml | 0 .../NXapm_paraprobe_config_spatstat.yaml | 0 .../NXapm_paraprobe_config_surfacer.yaml | 0 .../NXapm_paraprobe_config_tessellator.yaml | 0 .../NXapm_paraprobe_ranger_config.yaml | 0 .../NXapm_paraprobe_ranger_results.yaml | 0 .../NXapm_paraprobe_results_clusterer.yaml | 0 .../NXapm_paraprobe_results_distancer.yaml | 0 .../NXapm_paraprobe_results_intersector.yaml | 0 .../NXapm_paraprobe_results_nanochem.yaml | 0 .../NXapm_paraprobe_results_selector.yaml | 0 .../NXapm_paraprobe_results_spatstat.yaml | 0 .../NXapm_paraprobe_results_surfacer.yaml | 0 .../NXapm_paraprobe_results_tessellator.yaml | 0 .../NXapm_paraprobe_tool_config.yaml | 0 .../NXapm_paraprobe_tool_results.yaml | 2 +- .../NXapm_paraprobe_transcoder_config.yaml | 0 .../NXapm_paraprobe_transcoder_results.yaml | 11 +- .../nyaml/{refactor => }/NXapm_ranging.yaml | 22 +- .../{refactor => }/NXapm_reconstruction.yaml | 32 +- .../nyaml/{refactor => }/NXapm_sim.yaml | 2 - .../{refactor => }/NXapm_volt_and_bowl.yaml | 7 +- .../{refactor => }/NXcg_marching_cubes.yaml | 0 .../NXcs_filter_boolean_mask.yaml | 0 .../{refactor => }/NXdelocalization.yaml | 0 .../{refactor => }/NXevent_data_apm.yaml | 0 .../{refactor => }/NXevent_data_apm_set.yaml | 0 .../nyaml/{refactor => }/NXion.yaml | 0 .../nyaml/{refactor => }/NXisocontour.yaml | 0 .../nyaml/{refactor => }/NXmatch_filter.yaml | 0 .../nyaml/{refactor => }/NXpeak.yaml | 0 .../nyaml/{refactor => }/NXpulser_apm.yaml | 4 - .../nyaml/{refactor => }/NXreflectron.yaml | 0 .../{refactor => }/NXsimilarity_grouping.yaml | 38 +- .../{refactor => }/NXspatial_filter.yaml | 0 .../{refactor => }/NXsubsampling_filter.yaml | 0 .../nyaml/refactor/deprecate/NXapm.yaml | 3303 ----------------- .../deprecate/NXapm_input_ranging.yaml | 25 - .../deprecate/NXapm_input_reconstruction.yaml | 19 - .../deprecate/NXapm_mass_to_charge.yaml | 5 - .../deprecate/find_a_place_in_nxapm.txt | 643 ---- 79 files changed, 3118 insertions(+), 5718 deletions(-) create mode 100644 contributed_definitions/NXapm_charge_state_analysis.nxdl.xml create mode 100644 contributed_definitions/NXapm_hit_finding.nxdl.xml create mode 100644 contributed_definitions/NXapm_msr.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml create mode 100644 contributed_definitions/NXapm_ranging.nxdl.xml create mode 100644 contributed_definitions/NXapm_reconstruction.nxdl.xml create mode 100644 contributed_definitions/NXapm_sim.nxdl.xml create mode 100644 contributed_definitions/NXapm_volt_and_bowl.nxdl.xml create mode 100644 contributed_definitions/NXevent_data_apm.nxdl.xml create mode 100644 contributed_definitions/NXevent_data_apm_set.nxdl.xml rename contributed_definitions/nyaml/{refactor => }/NXapm.yaml (99%) rename contributed_definitions/nyaml/{refactor => }/NXapm_charge_state_analysis.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXapm_composition_space_results.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXapm_hit_finding.yaml (88%) rename contributed_definitions/nyaml/{refactor => }/NXapm_msr.yaml (98%) rename contributed_definitions/nyaml/{refactor => }/NXapm_paraprobe_config_clusterer.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXapm_paraprobe_config_distancer.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXapm_paraprobe_config_intersector.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXapm_paraprobe_config_nanochem.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXapm_paraprobe_config_selector.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXapm_paraprobe_config_spatstat.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXapm_paraprobe_config_surfacer.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXapm_paraprobe_config_tessellator.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXapm_paraprobe_ranger_config.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXapm_paraprobe_ranger_results.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXapm_paraprobe_results_clusterer.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXapm_paraprobe_results_distancer.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXapm_paraprobe_results_intersector.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXapm_paraprobe_results_nanochem.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXapm_paraprobe_results_selector.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXapm_paraprobe_results_spatstat.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXapm_paraprobe_results_surfacer.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXapm_paraprobe_results_tessellator.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXapm_paraprobe_tool_config.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXapm_paraprobe_tool_results.yaml (99%) rename contributed_definitions/nyaml/{refactor => }/NXapm_paraprobe_transcoder_config.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXapm_paraprobe_transcoder_results.yaml (96%) rename contributed_definitions/nyaml/{refactor => }/NXapm_ranging.yaml (79%) rename contributed_definitions/nyaml/{refactor => }/NXapm_reconstruction.yaml (63%) rename contributed_definitions/nyaml/{refactor => }/NXapm_sim.yaml (95%) rename contributed_definitions/nyaml/{refactor => }/NXapm_volt_and_bowl.yaml (85%) rename contributed_definitions/nyaml/{refactor => }/NXcg_marching_cubes.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXcs_filter_boolean_mask.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXdelocalization.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXevent_data_apm.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXevent_data_apm_set.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXion.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXisocontour.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXmatch_filter.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXpeak.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXpulser_apm.yaml (97%) rename contributed_definitions/nyaml/{refactor => }/NXreflectron.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXsimilarity_grouping.yaml (73%) rename contributed_definitions/nyaml/{refactor => }/NXspatial_filter.yaml (100%) rename contributed_definitions/nyaml/{refactor => }/NXsubsampling_filter.yaml (100%) delete mode 100644 contributed_definitions/nyaml/refactor/deprecate/NXapm.yaml delete mode 100644 contributed_definitions/nyaml/refactor/deprecate/NXapm_input_ranging.yaml delete mode 100644 contributed_definitions/nyaml/refactor/deprecate/NXapm_input_reconstruction.yaml delete mode 100644 contributed_definitions/nyaml/refactor/deprecate/NXapm_mass_to_charge.yaml delete mode 100644 contributed_definitions/nyaml/refactor/deprecate/find_a_place_in_nxapm.txt diff --git a/Makefile b/Makefile index dba9b98250..537a44af59 100644 --- a/Makefile +++ b/Makefile @@ -73,6 +73,8 @@ pdf :: $(SPHINX) -M latexpdf $(BUILD_DIR)/manual/source/ $(BUILD_DIR)/manual/build cp $(BUILD_DIR)/manual/build/latex/nexus-fairmat.pdf $(BUILD_DIR)/manual/source/_static/NeXusManual.pdf +# for development purposes switch off the -W flag in the following line to make testing the local +# building of the manual more efficient html :: $(SPHINX) -b html -W $(BUILD_DIR)/manual/source/ $(BUILD_DIR)/manual/build/html diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index fc138d22e9..b95beb4dfc 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -3,7 +3,7 @@ - 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. + Number of pulses collected in between start_time and end_time resolved by an + instance of :ref:`NXevent_data_apm`. If this is not defined, p is the number of + ions included in the reconstructed volume if the application definition is used + to store results of an already reconstructed datasets. - + - Total number of integers in the supplementary XDMF topology array. + Number of ions spatially filtered from results of the hit_finding algorithm + from which an instance of a reconstructed volume has been generated. + These ions get new identifier assigned in the process (the so-called + evaporation_identifier). This identifier must not be confused with + the pulse_identifier. Application definition for atom probe and field ion microscopy experiments. - - 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. + An at least as strong as SHA256 hashvalue of the + file which specifies the application definition. - - + NeXus NXDL schema to which this file conforms. @@ -171,133 +62,122 @@ to describe also the upcoming technique of atomic scale analytical tomography ht - + - 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. + The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) + which was used to generate this NeXus file instance. - - + + + + A collection of all programs and libraries which are considered relevant + to understand with which software tools this NeXus file instance was + generated. Ideally, to enable a binary recreation from the input data. + + Examples include the name and version of the libraries used to write the + instance. Ideally, the software which writes these NXprogram instances + also includes the version of the set of NeXus classes i.e. the specific + set of base classes, application definitions, and contributed definitions + with which the here described concepts can be resolved. + + For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ + which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ + research data management system, it makes sense to store e.g. the GitHub + repository commit and respective submodule references used. + + + + + + + + + + + + + - 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. + The identifier whereby the experiment is referred to in the control software. + This is neither the specimen_name nor the experiment_identifier. For + Local Electrode Atom Probe (LEAP) instruments, it is recommended to use the + run_number from the proprietary software IVAS/APSuite of AMETEK/Cameca. + For other instruments, such as the one from Stuttgart or Oxcart from Erlangen, + or the instruments at GPM in Rouen, use the identifier which matches + best conceptually to the LEAP run number. + The field does not have to be required if the information is recoverable + in the dataset which for LEAP instruments is the case (provided these + RHIT or HITS files respectively are stored alongside a data artifact). + With NXapm the RHIT or HITS can be stored as via the NXserialized group + in the hit_finding algorithm section. - Users are encouraged to add in this field eventual DOIs to papers - which yield further details to the experiment. + As a destructive microscopy technique, a run can be performed only once. + It is possible, however, to interrupt a run and restart data acquisition + while still using the same specimen. In this case, each evaporation run + needs to be distinguished with different run numbers. + We follow this habit of most atom probe groups. Such interrupted runs + should be stored as individual :ref:`NXentry` instances in one NeXus file. + 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. + included when the atom probe session started. If the exact duration of + the measurement is not relevant start_time only should be used. - Often though it is useful to specify 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 + Often though it is useful to specify both start_time and end_time to + capture more detailed bookkeeping of the experiment. The user should + be aware that even with having both dates specified, it may not be + possible to infer how long the experiment took or for how long data were collected. More detailed timing data over the course of the experiment have to be - collected to compute this event chain during the experiment. + collected to compute this event chain during the experiment. For this + purpose the :ref:`NXevent_data_apm` instance should be used. - ISO 8601 time code with local time zone offset to UTC included - when the microscope session ended. + when the atom probe 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: + What type of atom probe experiment is performed? This field is meant to + inform research data management systems to allow filtering: * apt are experiments where the analysis_chamber has no imaging gas. - experiment with LEAP instruments are typically performed as apt. + experiment with LEAP instruments are typically performed such. * fim are experiments where the analysis_chamber has an imaging gas, which should be specified with the atmosphere in the analysis_chamber group. * apt_fim should be used for combinations of the two imaging modes. - * other should be used in combination with the user specifying details in the - experiment_documentation field. + few experiments of this type have been performed as this can be detrimental + to LEAP systems (see `S. Katnagallu et al. <https://doi.org/10.1017/S1431927621012381>`_). + * other should be used in combination with the user specifying details + in the experiment_documentation field. @@ -306,76 +186,13 @@ are required LAS root version camecaroot version analysis software--> - - - - 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. - - + + + + + + + @@ -383,41 +200,51 @@ doc: |--> 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. + atom probers about knowledge they have gained about the sample. + There are cases where the specimen is machined further or exposed to + external stimuli during the experiment. In this case, these details should + not be stored under sample but suggestions should be made + how this application definition can be improved. In the future also details like how the grain_diameter was characterized, how the sample was prepared, how the material was heat-treated etc., - should be stored as using specific application definitions/schemas - which are then arranged and documented with a description of the workflow - so that actionable graphs become instantiatable. + should be stored. For this specific application definitions/schemas can be + used which are then arranged and documented with a description of the + workflow so that actionable graphs become instantiatable. + + + A qualifier whether the sample is a real one + or a virtual one (in a computer simulation). + + + + + + + + + Given name/alias for the sample. + + + + + + + Qualitative information about the grain size, here specifically described as the equivalent spherical diameter of an assumed average grain size for the crystal ensemble. Users of this information should be aware that although the grain - diameter or radius is often referred to as grain size 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. + diameter or radius is often referred to as grain size. - Reporting a grain size is useful though as it allows judging if - specific features are expected to be found in the detector hit map. + In atom probe it is possible that the specimen may contain a few + crystals only. In this case the grain_diameter is not a reliable + descriptor. Reporting a grain size may be useful though as it allows + judging if specific features are expected to be found in the + detector hit map. @@ -425,15 +252,16 @@ doc: |--> 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. + was heat treated. However, if a documentation of the annealing + treatment as a function of time is available one should better + rely on this information and have it stored alongside the NeXus file. @@ -443,25 +271,23 @@ 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. + Rate of the last quenching step. Knowledge about this value can give + an idea how the sample was heat treated. However, there are many + situations where one can imagine that the scalar value for just the + quenching rate is insufficient. + + An example is when the sample was left in the furnace after the + furnace was switched off. In this case the sample cools down with + a specific rate of how this furnace cools down in the lab. + Processes which in practice are often not documented. - This can be problematic 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. + This can be problematic though because when the furnace door was left open + or the ambient temperature in the lab changed, i.e. for a series of + experiments where one is conducted on a hot summer day and the next + during winter this can have an effect on the evolution of the microstructure. + There are many cases where this has been reported to be an QA issue in industry, + e.g. think about aging aluminium samples left on the factory + parking lot on a hot summer day. @@ -469,33 +295,34 @@ doc: |--> Magnitude of the standard deviation of the heat_treatment_quenching_rate. - + - The chemical composition of the sample. Typically it is assumed that + 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. + dimensionless quantities but their conceptual interpretation differs. + A normalization based on atom_percent counts relative to the + total number of atoms which are of a particular type. + By contrast, weight_percent normalization factorizes in the + respective mass of the elements. Python libraries like pint are + challenged by these differences as at.-% and wt.-% are both + fractional quantities. - - + + - Human-readable name of the element/ion (e.g. Fe). + Human-readable name of the element (e.g. Fe). Name has to be a symbol of an element from the periodic table. All symbols in the set of NXion instances inside the group chemical_composition need to be disjoint. @@ -516,95 +343,74 @@ 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. + A qualifier whether the sample is a real one + or a virtual one (in a computer simulation). + + + + - + - 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. + Given name an alias. Better use identifier and parent_identifier instead. + A single NXentry should be used only for the characterization of a single specimen. + + + + + + + + Identifier of the sample from which the specimen was cut or the string + n/a. The purpose of this field is to support functionalities for + tracking sample provenance via a research data management system. + + + + + ISO 8601 time code with local time zone offset to UTC information when the specimen was prepared. Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. 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. + the measured specimen surface was actively prepared. Ideally, this + matches the last timestamp that is mentioned in the digital resource + pointed to by parent_identifier. Knowing when the specimen was exposed to e.g. specific atmosphere is especially required for environmentally sensitive material such as hydrogen charged specimens or experiments including tracers with a - short half time. 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. + short half time. Additional time stamps prior to preparation_date + should better be placed in resources which describe but which do not + pollute the description here with prose. Resolving these connected + pieces of information is considered within the responsibility of the + research data management system. - + - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. + List of comma-separated elements from the periodic table that are + contained in the specimen. If the specimen substance has multiple + components, all elements from each component must be included in + `atom_types`. - The purpose of the field is to offer materials database systems an + The purpose of the field is to offer research data management systems an opportunity to parse the relevant elements without having to interpret - these from the sample history or from other data sources. + these from the resources pointed to by parent_identifier or walk through + eventually deeply nested groups in data instances. - + - Discouraged free-text field in case properly designed records - for the sample_history or sample section are not available. + Discouraged free-text field. @@ -614,26 +420,22 @@ NEW ISSUE: it would be good to have an application definition NXicp for chemical single crystal. + + + Report if the specimen is amorphous. + + - - - - 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 + Set to hold different coordinate systems conventions. + Inspect the description of the :ref:`NXcoordinate_system_set` + and :ref:`NXcoordinate_system` base classes how to define + coordinate systems in NeXus. Specific details for application in atom probe microscopy follow. - In this research field scientists distinguish usually several + In this research field scientists usually distinguish several Euclidean coordinate systems (CS): * World space; @@ -660,1046 +462,449 @@ describing the geometry of the sample--> * 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 + within a predefined evaporation identifier interval. Typically, the set of ion evaporation sequence IDs is grouped into chunks. For each chunk a histogram of the ion hit positions on the detector is computed. This leaves the possibility for inconsistency between the so-called detector space and the e.g. specimen space. - 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. + To avoid these ambiguities, instances of :ref:`NXtransformations` should + be used. - - - - - - - - - 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 spatiotemporally 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. - + + + + + + A region-of-interest analyzed either during or after the session for which + specific processed data of the measured or simulated data are available. + + + + - - + + - - - - 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. + Integer used to name the first pulse to know if there is an + offset of the evaporation_identifier to zero. + + Identifiers can be defined either implicitly or explicitly. + For implicit indexing identifiers are defined on the interval + :math:`[identifier_offset, identifier_offset + c - 1]`. + + Therefore, implicit identifier are completely defined by the value of + identifier_offset and cardinality. For example if identifier run from + -2 to 3 the value for identifier_offset is -2. + + For explicit indexing the field identifier has to be used. + Fortran-/Matlab- and C-/Python-style indexing have specific implicit + identifier conventions where identifier_offset is 1 and 0 respectively. + + + + + (Molecular) ion identifier which resolves the sequence in which + the ions were evaporated but taking into account that a hit_finding + and spatial_filtering was applied. - + + + + + + + + - - - - Data post-processing step to correct for ion impact - position flight path differences, detector biases, - and nonlinearities. This step is usually performed - with commercial software. - + + - - + + - - - - Raw time-of-flight data as read out from the acquisition software - if these data are available and accessible. - + - + - - - - Calibrated time-of-flight. - + + - + - - - The key idea and algorithm of the voltage-and-bowl correction is - qualitatively similar for instruments of different manufacturers - or research groups. - - Specific differences exists though in the form of different - calibration models. For now we do not wish to resolve or - generalize these differences. Rather the purpose of this collection - is to provide a container where model-specific parameters - and calibration models can be stored if users know these - for sure. - - For AMETEK LEAP instruments this should be the place for - storing initial calibration values. These values are - accessible normally only by AMETEK service engineers. - They use these for calibrating the detector and instrument. - - Users can also use this NXcollection for storing the - iteratively identified calibrations which scientists - will see displayed in e.g. APSuite while they execute - the voltage-and-bowl correction as a part of the - reconstruction pipeline in APSuite. - - - - - Data post-processing step in which calibrated time-of-flight data - (ToF) are interpreted into mass-to-charge-state ratios. - - - + + - - - Store vendor-specific calibration models here (if available). - + + + + + - - - Mass-to-charge-state ratio values. - - + + - + - - - - Data post-processing step to create a tomographic reconstruction - of the specimen based on selected calibrated ion hit positions, - the evaporation sequence, and voltage curve data. - Very often scientists use own software scripts according to - published procedures, so-called reconstruction protocols, - i.e. numerical recipes how to compute x, y, z atomic positions - from the input data. - + - - + + - - - Qualitative statement about which reconstruction protocol was used. - - - - - - - - - - - - - Different reconstruction protocols exist. Although these approaches - are qualitatively similar, each protocol uses different parameters - (and interprets these differently). The source code to IVAS/APSuite - is not open. For now users should store reconstruction parameter - in a collection. - - - - - - Different strategies for crystallographic calibration of the - reconstruction are possible. The field is required and details - should be specified in free-text at least. If the not crystallographic - calibration was performed the field should be filled with the n/a, - meaning not applied. - - - - - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - + + + + + + + + + + - + - - - - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstructed dataset. - The XDMF primitive type is here 1, the number of primitives 1 per - triplet, the last integer in each triplet is the identifier of - each point starting from zero. - - - - - - - - - - Six equally formatted sextets chained together. For each - sextett the first entry is an XDMF primitive topology - key (here 5 for polygon), the second entry the XDMF primitive - count value (here 4 because each face is a quad). - The remaining four values are the vertex indices. - - - - - - - - To get a first overview of the reconstructed dataset, - the format conversion computes a simple 3d histogram - of the ion density using one nanometer cubic bins without - applying smoothening algorithms on this histogram. - + - - + + + - - A default three-dimensional histogram of the total - number of ions in each bin obtained via using a rectangular - transfer function. - - - - - - - - - Array of counts for each bin. - + + + + + + - - - Bin center of mass position along the z axis. - + - + - - - Bin center of mass position along the y axis. - + - + - - - Bin center of mass position along the x axis. - + - + - - - - Data post-processing step in which elemental, isotopic, - and/or molecular identities are assigned to the ions. - The documentation of these steps is based on ideas - described in the literature: - - * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ - * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ - + - - - How many ion types are distinguished. - If no ranging was performed each ion is of the special unknown type. - The iontype ID of this unknown type is 0 which is a reserve value. - Consequently, iontypes start counting from 1. - - - - - Assumed maximum value that suffices to store all relevant - molecular ions, even the most complicated ones. - Currently a value of 32 is used. - - + + - - Specifies the computation of the mass-to-charge histogram. - Usually mass-to-charge values are studied as an ensemble quantity, - specifically these values are binned. - This (NXprocess) stores the settings of this binning. - + - - + + - - - Smallest and largest mass-to-charge-state ratio value. - - - - - - - - - Binning width of the mass-to-charge-state ratio values. - - - + + - - A default histogram aka mass spectrum of - the mass-to-charge-state ratio values. - - - - - - - - - Array of counts for each bin. - + + + + + + - + - - - Right boundary of each mass-to-charge-state ratio value bin. - - + - + - - Details of the background model which was used to - correct the total counts per bin into counts. - + - - + + - - - - How where peaks in the background-corrected in the histogram - of mass-to-charge-state ratio values identified? - + + + - - + + - - - - THIS DOCSTRING NEEDS CLARIFICATION. - - + + + + - - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - + - - + + - + - + diff --git a/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml b/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml new file mode 100644 index 0000000000..b8d1bce9cd --- /dev/null +++ b/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml @@ -0,0 +1,157 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The number of also possible but different (molecular) ions. + + + + + Maximum number of allowed atoms per (molecular) ion (fragment). + + + + + Base class to document an algorithm for recovering charge state and nuclid composition of a (molecular) ion. + + Currently ranging definitions in the research field of atom probe face have limitations: + + 1. A ranging definition maps all signal within a mass-to-charge-state-ratio value interval + on one iontype. Facing limited mass-resolving-power, there are mass-to-charge-state-ratio + values, though, for which not only multiple (molecular) ions are indistinguishable but + also for which the current practice of documenting classical ranging definitions is incomplete. + 2. Indeed, ranging definitions often report only (for each interval) the + mass-to-charge-state-ratio intervals surplus the composition of elements + that build the (molecular) ion. + 3. Therefore, classical ranging definitions demand a post-processing with an algorithm + which can identify the nuclids from which the (molecular) ion is constructed + and a charge state possibly recovered. + Combinatorial algorithms are used for this purpose. + + This base class documents the configuration and results of such an algorithm. + + + + + Input constraint, list of proton numbers for each element of the ranging + definition. The list contains each element as many times as its multiplicity. + As an example a ranging definition H:2 O:1 demands element vector + to be 1, 1, 8. An empty list does not release the constraint. + Instead, a list with all elements in the periodic table should be + used. Keep in mind though with such a weakly constrained parameter space + the combinatorial analysis may become very time consuming! + + + + + + + + Input constraint, interval within which (molecular) ions need to have the + mass-to-charge-state-ratio such that an ion qualifies as a candidate. + + + + + + + + + Input constraint, minimum half life for how long each nuclid of each + (molecular) ion needs to be stable such that the ion qualifies as a candidate. + + + + + Input constraint, minimum natural abundance of each nuclid of each + (molecular) ion such that the ion qualifies as a candidate. + + + + + If the value is false, it means that non-unique solutions are accepted. + These are solutions where multiple candidates have been built from different + nuclids but the charge_state of all the ions is the same. + + + + + + Signed charge, i.e. integer multiple of the elementary charge. + + + + + + + + List of nuclids building each candidate. + Each list is sorted in descending order. + Unused values up to n_ivec_max are nullified. + + + + + + + + + Accumulated mass of the nuclids in each candidate. + Not corrected for quantum effects. + + + + + + + + The product of the natural abundances of the nuclids for each candidate. + + + + + + + + For each candidate the half life of the nuclid with the shortest half life. + + + + + + diff --git a/contributed_definitions/NXapm_hit_finding.nxdl.xml b/contributed_definitions/NXapm_hit_finding.nxdl.xml new file mode 100644 index 0000000000..61338a807c --- /dev/null +++ b/contributed_definitions/NXapm_hit_finding.nxdl.xml @@ -0,0 +1,125 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of delay-line wires of the detector. + + + + + Number of pulses collected in between start_time and end_time + resolved by an instance of :ref:`NXevent_data_apm`. If this is not defined, + p is the number of ions included in the reconstructed volume if an application + definition is used to store results of already reconstructed datasets. + + + + + Base class for the configuration and results from a hit finding algorithm. + + + + + + + The number of wires in the detector. + + + + + + + + + + Alias tuple (begin, end) of each DLD wire of the detector. + Order follows arrival_time_pairs. + + + + + + + + + Raw readings from the analog-to-digital-converter + timing circuits of the detector wires. + + + + + + + + + + + Evaluated ion impact coordinates on the detector. + Use the depends_on field to spec + + + + + + + + The instance of :ref:`NXcoordinate_system` in which the positions are defined. + + + + + + Hit category, AMETEK/Cameca uses e.g. golden, partial, incomplete. + + + + + + + + This processing yields for each ion with how many others it evaporated + if these were collected on the same pulse. Extraction of multiple ions + on one pulse on different or even the same pixel of the detector are possible. + + Multiplicity must not be confused with how many atoms of the same element + a molecular ion contains (which is instead encoded with the + isotope_vector field of each :ref:`NXion` instance). + + + + + + + diff --git a/contributed_definitions/NXapm_msr.nxdl.xml b/contributed_definitions/NXapm_msr.nxdl.xml new file mode 100644 index 0000000000..c5ccceff58 --- /dev/null +++ b/contributed_definitions/NXapm_msr.nxdl.xml @@ -0,0 +1,176 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of pulses collected in between start_time and end_time + resolved by an instance of :ref:`NXevent_data_apm`. + + + + + Base class for collecting a session with a real atom probe or field-ion microscope. + + Ideally, we would like to describe the workflow of experiments and simulations of atom probe and + field-evaporation simulation research in more detail and contextualize better descriptions of + experiments and computer simulations for atom probe research. + + The main motivation for this is the ongoing development and tighter becoming connection between atom probe + and other material characterization techniques foremost electron microscopy (see `T. Kelly et al. <https://doi.org/10.1017/S1431927620022205>`_, `C. Fleischmann et al. <https://doi.org/10.1016/j.ultramic.2018.08.010>`_, and `W. Windl et al. <https://doi.org/10.1093/micmic/ozad067.294>`_ or `C. Freysoldt et al. <https://doi.org/10.1103/PhysRevLett.124.176801>`_ to mention but a few). + To arrive at a design of base classes and an application definition which can be used for both real and simulated atom probe experiments, it is worthwhile to recall concepts that are related to events and (molecular) ions: + + * Pulsing events which are used to trigger ion extraction events. + * Physical events and corresponding signal triggered by an ion hitting the detector. + Some of these events are not necessarily caused by or directly correlated with an identifiable pulsing event. + * Processed ion hits which are the result of an algorithm that took the physical and pulsing events as input + and qualified some of these events as to be of sufficiently high quality to call them (molecular) ions that are + wortwhile to be considered further and eventually included in the reconstructed volume. + * Calibration and signal filtering steps applied to these processed ion hits as input which results in actually + selected (molecular) ions based on which an instance of a reconstruction is created. + * Correlation of these ions with a statistics and theoretical model of mass-to-charge-state ratio values + and charge states of the (molecular) ions to substantiate that some of these ions are can be considered + as rangable ions and hence an iontype can be associated by running peak finding algorithms and labeling + i.e. algorithms for defining ranging definitions. + + Not only in AMETEK/Cameca's IVAS/APSuite software, which the majority of atom probers use, these concepts + are well distinguished. However, the algorithms used to transform correlations between pulses and physical events + into actual events (detector hits) ions is a proprietary one. Due to this practical inaccessibility of details, + virtually all atom probe studies currently use a reporting scheme where the course of the specimen evaporation + is documented such that quantities are a function of evaporation identifier i.e. actual event/ion, i.e. after having + the hits finding algorithm and correlations applied. That is evaporation_identifier values take the role of an implicit + time and course of the experiment given that ion extraction is a sequential physical process. + + There is a number of research groups who build own instruments and share different aspects of their technical + specifications and approaches how they apply data processing (e.g. `M. Monajem et al. <https://doi.org/10.1017/S1431927622003397>`_, `P. Stender et al. <https://doi.org/10.1017/S1431927621013982>`_ , or `I. Dimkou et al. <https://doi.org/10.1093/micmic/ozac051>`_ to name but a few). + Despite some of these activities embrace practices of open-source development, they use essentially the same + workflow that has been proposed by AMETEK/Cameca and its forerunner company Imago: A graphical user interface + software is used to explore and thus analyze reconstructed atom probe datasets. + + Specifically, software is used to correlate and interpret pulsing and physical events into processed ion hits. + Some of these ion hits are reported as (molecular) ions with ranged iontypes to yield a dataset based on which + scientific conclusions about the characterized material volume are made. + + By contrast, simulations of field-evaporation have the luxury to document the flight path and allow following the + whereabouts of each ion evaporated if needed. This level of detail is currently not characterizable in experiment. + Thus, there is a divide between schemas describing simulations of atom probe vs measurements of atom probe. + We argue that this divide can be bridged with realizing the above-mentioned context and the realization that + similar concepts are used in both research realms with many concepts not only being similar but exactly the same. + + A further argument to support this view is that computer simulations of atom probe usually are compared to reconstructed + datasets, either to the input configuration that served as the virtual specimen or to a real world atom probe experiment + and its reconstructions. In both cases, the recorded simulated physical events of simulated ions hitting a simulated detector + is not the end of the research workflow but typically the input to apply addition algorithms such as (spatial) filtering + and reconstruction algorithms. Only the practical need for making ranging definitions is (at least as of now) not as much needed + in field-evaporation simulations than it is in real world measurements because each ion has a prescribed iontype in the simulation. + Be it a specifically charged nuclid or a molecular ion whose flight path the simulation resolves. + Although, in principle simpler though, we have to consider that this is caused by many assumptions made in the simulations. + Indeed, the multi-scale (time and space) aspects of the challenge that is the simulating of field-evaporation are simplified + because of otherwise too high computing resource demands and knowledge gaps in how to deal with some complexities. + Molecular ion dissociation upon flight is one such complexity. Also the complexity of simulation setups is simpler e.g. the assumption of a straight flight path + instrument is used or details are ignored such as local electrodes or physical obstacles and electric fields (controlled or stray fields). + + To conclude, we thus propose two base classes :ref:`NXapm_msr` and :ref:`NXapm_sim` where the second one may become + obsolete in the future as people realize that a simulated atom probe is maybe equivalent in design and function to a + real atom probe if considering that the simulation is just stripped of many components. + + + + Metadata of the atom probe or field-ion microscope instrument, henceforth called + microscope or instrument, and the lab in which it stands. + + + + Possibility to include a detailed computational geometry description of the + instrument. + + + + + Given name of the microscope as defined by the hosting lab. This is an alias. + Examples could be LEAP6000, Raptor, Oxcart, one atom at a time, etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + A counter electrode of the LEAP 6000 series atom probes. + + + + + + A local electrode guiding the ion flight path. + Also called counter or extraction electrode. + + + + + + Detector for taking raw time-of-flight and ion/hit impact positions data. + + + + + + + + + + + + + + + A statement whether the measurement was successful or failed prematurely. + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml new file mode 100644 index 0000000000..b722fbd769 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml @@ -0,0 +1,240 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The number of isotopes to consider as building blocks for searching molecular + ions. + + + + + The number of compositions to consider for molecular ion search tasks. + + + + + Application definition for a configuration file of the paraprobe-ranger tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + + + + + Version specifier of this application definition. + + + + + NeXus NXDL schema with which this file was written. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml new file mode 100644 index 0000000000..d31d7d22e2 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml @@ -0,0 +1,259 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstructed volume. + + + + + Application definition for results files of the paraprobe-transcoder tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + The purpose and need of the paraprobe-ranger tool is to apply a given set of ranging definitions within + a certain (possibly complicated) selection of ions (based on their properties or location in the + reconstructed volume. + + + + + Version specifier of this application definition. + + + + + NeXus NXDL schema with which this file was written. + + + + + + + + Paraprobe-ranger loads the iontypes and evaluates for each + ion on which iontype it matches. If it matches on none, the + ion is considered of the default unknown type with a 0 + as its respective value in the iontypes array. + + + + + The length of the isotope_vector used to describe molecular ions. + + + + + + + + + + + The iontype (identifier) for each ion that was best matching, stored + in the order of the evaporation sequence ID. The here computed iontypes + do not take into account the charge state of the ion which is + equivalent to interpreting a RNG and RRNG range files for each + ion in such a way that only the elements of which a (molecular) ion + was built are considered. + + + + + + + + A bitmask which identifies exactly all those ions ranged + irrespective of the assigned type. This information + can be used to numerically recover the ROI selection. + + + + Number of ions covered by the mask. + The mask value for most may be 0. + + + + + Number of bits assumed matching on a default datatype. + + + + + The unsigned integer array representing the content of the mask. + If padding is used the padded bits are set to 0. The mask is for + convenience always as large as the entire dataset as it will + be stored compressed anyway. The convenience feature with this + is that then the mask can be decoded with numpy and mirrored + against the evaporation_id array and one immediately can filter + out all points that were used by the paraprobe. + The length of the array adds to the next unsigned integer + if the number of ions in the dataset is not an integer + multiple of the bitdepth. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml new file mode 100644 index 0000000000..1a08c8b209 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml @@ -0,0 +1,140 @@ + + + + + + + Base class documenting the configuration used for a tool of the paraprobe-toolbox. + + The paraprobe-toolbox is a collection of open-source software tools for performing + efficient analyses of point cloud data where each point can represent atoms or + (molecular) ions. A key application of the toolbox has been for research in the + field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): + + * `paraprobe-toolbox <https://www.gitlab.com/paraprobe/paraprobe-toolbox>`_ + * `M. Kühbach et al. <https://paraprobe-toolbox.readthedocs.io/en/main/>`_ + + The toolbox does not replace but complements existent software tools in this + research field. Given its capabilities of handling points as objects with + properties and enabling analyses of the spatial arrangement of and inter- + sections between geometric primitives, the software can equally be used + for analyzing data in Materials Science and Materials Engineering. + + The configuration and results of a run of a tool from the toolbox is documented + using binary container formats. Currently, paraprobe-toolbox uses the + Hierarchical Data Format 5 (HDF5). + + + + + + Internal identifier used by the tool to refer to an analysis (aka simulation + id). + + + + + Possibility for leaving a free-text description about this analysis. + + Although offered here for convenience we strongly encourage to + parameterize such descriptions as much as possible to support + reusage and clearer communication. + + + + + + Metadata of the computational process whereby this configuration was generated. + There is a special set of tools called paraprobe-parmsetup which can be used + to conveniently create HDF5 configuration files, i.e. instances. + + + + Path where the tool stores tool-specific results. If not specified, + results will be stored in the current working directory. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the creation of the configuration was started, + i.e. when the respective executable/tool was started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the creation of the configuration was + completed and the respective process of the tool exited. + + + + + + Specification of the tomographic reconstruction to use for this analysis. + + Typically, reconstructions in the field of atom probe tomography are communicated + via files which store at least reconstructed ion positions and mass-to-charge-state-ratio + values. Container files like HDF5 though can store multiple reconstructions. + Therefore, the position and mass_to_charge concepts point to specific instances + to use for this analysis. + + + + Name of the node which resolves the reconstructed ion position + values to use for this analysis. + + + + + Name of the node which resolves the mass-to-charge-state-ratio + values to use for this analysis. + + + + + + Specification of the ranging definitions to use for this analysis. + + Ranging is the process of labeling time-of-flight data with so-called iontypes + (aka ion species). Ideally, iontypes specify the most likely (molecular) ion + that is assumed to have been evaporated given that its mass-to-charge-state ratio + lies within the specific mass-to-charge-state-ratio value interval of the iontype. + + The so-called UNKNOWNTYPE iontype represents the null model of an ion + that has not been ranged (for whatever reasons). + The identifier of this special iontype is always the reserved value 0. + + + + Name of the (parent) node directly below which (in the hierarchy) + the ranging definition for (molecular) ions are stored. + + + + diff --git a/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml new file mode 100644 index 0000000000..faa3b608d7 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml @@ -0,0 +1,136 @@ + + + + + + + Base class documenting the results obtained with a tool of the paraprobe-toolbox. + + The paraprobe-toolbox is a collection of open-source tools for performing + efficient analyses of point cloud data where each point can represent atoms or + (molecular) ions. A key application of the toolbox has been for research in the + field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): + + * `paraprobe-toolbox <https://www.gitlab.com/paraprobe/paraprobe-toolbox>`_ + * `M. Kühbach et al. <https://paraprobe-toolbox.readthedocs.io/en/main/>`_ + + The toolbox does not replace but complements existent software tools in this + research field. Given its capabilities of handling points as objects with + properties and enabling analyses of the spatial arrangement of and inter- + sections between geometric primitives, the software can equally be used + for analyzing data in Materials Science and Materials Engineering. + + The configuration and results of a run of a tool from the toolbox is documented + using binary container formats. Currently, paraprobe-toolbox uses the + Hierarchical Data Format 5 (HDF5). + + + + + Internal identifier used by the tool to refer to an analysis (aka simulation + id). + + + + + Possibility for leaving a free-text description about this analysis. + + + + + The configuration file that was used to parameterize the algorithms + which the tool executes. + + + + + + + Path where the tool stores tool-specific results. If not specified, + results will be stored in the current working directory. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis in this results file was started, + i.e. when the respective executable/tool was started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis in this results file were + completed and the respective process of the tool exited. + + + + + A statement whether the tool executable managed to process the analysis + or whether this failed. Status is written to the results file after the + end_time beyond which point in time the tool must no longer compute + any further analysis results but exit. + + Only when this status message is present and its value is `success`, + one should consider the results of the tool. In all other cases it might + b that the tool has terminated prematurely or another error occurred. + + + + + + + + + + + Details about coordinate systems (reference frames) used. In atom probe several coordinate + systems have to be distinguished. Names of instances of such :ref:`NXcoordinate_system` + should be documented explicitly and doing so by picking from the + following controlled set of names: + + * paraprobe + * lab + * specimen + * laser + * instrument + * detector + * recon + + The aim of this convention is to support users with contextualizing which reference + frame each instance (coordinate system) is. If needed, instances of :ref:`NXtransformations` + are used to detail the explicit affine transformations whereby one can convert + rpresentations between different reference frames. + Inspect :ref:`NXtransformations` for further details. + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml new file mode 100644 index 0000000000..f0c133749c --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml @@ -0,0 +1,79 @@ + + + + + + + + Application definition for a configuration file of the paraprobe-transcoder tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + + + + + + Version specifier of this application definition. + + + + + NeXus NXDL schema with which this file was written. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml new file mode 100644 index 0000000000..1534ba86bc --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml @@ -0,0 +1,197 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. + + + + + Total number of integers in the supplementary XDMF topology array. + + + + + Application definition for results files of the paraprobe-transcoder tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + The purpose and need of the paraprobe-transcoder tool is to create a standardized representation + of reconstructed position and mass-to-charge-state-ratio values surplus other pieces of information + to enable working with atom probe data in reconstruction space. + This includes ranging definitions which map mass-to-charge-state ratio values onto iontypes. + So far the atom probe community has not yet agreed upon a comprehensive standardization for + information exchange especially when it comes to the communication of configurations and results + from analyses of atom probe data. Instead, different simplistic file formats are used, such as POS, + ePOS, APT, or RNG and RRNG. None of these formats, though, document the provenance of, and thus the + sequence in which certain analysis steps were performed or which specific input and + configuration was used. + + Paraprobe-transcoder solves this limitation by interpreting the information content in such files + and standardize the representation prior injection into the scientific data analysis tools of the toolbox. + Therefore, the here proposed set of NeXus base classes and application definitions can be a useful + starting point that enable the atom probe community to take advantage of standardized information + exchange and improve the here proposed classes and concepts to become more inclusive. + + Paraprobe-transcoder uses a Python library developed based on efforts by members of the + global atom probe community `International Field Emission Society (IFES) Atom Probe Technical Committee (APT TC) <https://www.github.com/atomprobe-tc/ifes_apt_tc_data_modeling>`_. This library offers the + actual low-level I/O operations and respective information interpretation. + + + + + + Version specifier of this application definition. + + + + + NeXus NXDL schema with which this file was written. + + + + + + + + + + + Mass-to-charge-state-ratio values. + + + + + + + + + + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + + + + + + + + Point to the coordinate system in which these positions are defined. + + + + + + + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstruction. The XDMF datatype + is here 1, the number of primitives 1 per triplet, the last integer + in each triplet is the identifier of each point starting from zero. + + + + + + + + + + + Details about how peaks are interpreted as ion types or not. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If used, metadata of at least the person who performed this analysis. + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_ranging.nxdl.xml b/contributed_definitions/NXapm_ranging.nxdl.xml new file mode 100644 index 0000000000..340a5d0b9b --- /dev/null +++ b/contributed_definitions/NXapm_ranging.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + Base class for the configuration and results of ranging definitions. + + Ranging is a data post-processing step used in the research field of + atom probe during which elemental, isotopic, and/or molecular identities + are assigned to mass-to-charge-state-ratios within a certain interval. + The documentation of these steps is based on ideas that + have been described in the literature: + + * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ + * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + How many ion types are distinguished. If no ranging was performed, each + ion is of the special unknown type. The iontype ID of this unknown type + is 0 representing a reserve value. Consequently, + iontypes start counting from 1. + + + + + Assumed maximum value that suffices to store all relevant + molecular ions, even the most complicated ones. + Currently, a value of 32 is used (see M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_). + + + + + Specifies the mass-to-charge-state-ratio histogram. + + + + + Smallest, increment, and largest mass-to-charge-state ratio value. + + + + + + + + A default histogram aka mass spectrum of + the mass-to-charge-state ratio values. + + + + + + Details of the background model that was used to + correct the total counts per bin into counts. + + + + + To begin with we use a free-text field to learn how + atom probers define a background model. Future versions + of NXapm_ranging can then use this information to parameterize + these models. + + + + + + + How where peaks in the background-corrected in the histogram + of mass-to-charge-state ratio values identified? + + + + + + + Details about how peaks, with taking into account + error models, were interpreted as ion types or not. + + + + + diff --git a/contributed_definitions/NXapm_reconstruction.nxdl.xml b/contributed_definitions/NXapm_reconstruction.nxdl.xml new file mode 100644 index 0000000000..e88e3a91f8 --- /dev/null +++ b/contributed_definitions/NXapm_reconstruction.nxdl.xml @@ -0,0 +1,102 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of ions spatially filtered from results of the hit_finding algorithm + :ref:`NXapm_hit_finding` from which an instance of a reconstructed volume + has been generated. These ions get new identifier assigned in the process - + the so-called evaporation_identifier, which must not be confused with + the pulse_identifier! + + + + + Base class for the configuration and results of a (static) reconstruction algorithm. + + Generating a tomographic reconstruction of the specimen uses selected and + calibrated ion hit positions, the evaporation sequence, and voltage curve data. + Very often scientists use own software scripts according to published procedures, + so-called reconstruction protocols. + + + + + + + + Qualitative statement about which reconstruction protocol was used. + + + + + + + + + + + + Different strategies for crystallographic calibration of the + reconstruction are possible. Therefore, we collect first such + feedback before parameterizing this further. + + If no crystallographic calibration was performed, the field + should be filled with the n/a, meaning not applied. + + + + + + Three-dimensional reconstructed positions of the ions. + + + + + + + + The instance of :ref:`NXcoordinate_system` + in which the positions are defined. + + + + + + + + + To get a first visual overview of the reconstructed dataset, + here a 3d histogram of the ion is stored. Ion counts are characterized + using one nanometer cubic bins without applying position smoothening + algorithms during the histogram computation. + + + + diff --git a/contributed_definitions/NXapm_sim.nxdl.xml b/contributed_definitions/NXapm_sim.nxdl.xml new file mode 100644 index 0000000000..9c4a1d5d62 --- /dev/null +++ b/contributed_definitions/NXapm_sim.nxdl.xml @@ -0,0 +1,40 @@ + + + + + + + Base class for simulating ion extraction from matter via laser and/or voltage pulsing. + + Ideally, we would like to describe the workflow of experiments and simulations of + atom probe and field-evaporation simulation research in more detail and contextualize + better descriptions of experiments and computer simulations. + The strategy to achieve this is detailed in the introducing docstring of + :ref:`NXapm_msr`. This :ref:`NXapm_sim` base class is envisioned as the + twin of the :ref:`NXapm_msr` base class. + + + diff --git a/contributed_definitions/NXapm_volt_and_bowl.nxdl.xml b/contributed_definitions/NXapm_volt_and_bowl.nxdl.xml new file mode 100644 index 0000000000..aa67d8f7ed --- /dev/null +++ b/contributed_definitions/NXapm_volt_and_bowl.nxdl.xml @@ -0,0 +1,69 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of ions spatially filtered from results of the hit_finding algorithm + :ref:`NXapm_hit_finding` from which an instance of a reconstructed volume + has been generated. These ions get new identifier assigned in the process - + the so-called evaporation_identifier, which must not be confused with + the pulse_identifier! + + + + + Base class for the configuration and results from a voltage-and-bowl ToF correction algorithm. + + The voltage-and-bowl correction is a ata post-processing step to correct for ion impact position + flight path differences, detector biases, and nonlinearities. + + + + + + + Raw time-of-flight data without corrections. + + + + + + + + Calibrated time-of-flight. + + + + + + diff --git a/contributed_definitions/NXcg_marching_cubes.nxdl.xml b/contributed_definitions/NXcg_marching_cubes.nxdl.xml index f04bdaad8a..8ab218c717 100644 --- a/contributed_definitions/NXcg_marching_cubes.nxdl.xml +++ b/contributed_definitions/NXcg_marching_cubes.nxdl.xml @@ -3,7 +3,7 @@ + - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - Computational geometry description of the marching cubes algorithm. + Base class to detail the marching cubes (MC) algorithm. - Documenting which specific version was used helps with understanding how - robust the results are with respect to the topology of the triangulation. + Documenting which specific version of MC was used helps with understanding + how robust the results are with respect to the topology of the triangulation. - Reference/link to and/or details of the grid on which a specific - marching cubes algorithm implementation is operating. + Metadata of the grid on which the here specified MC is operating. - + Reference to the specific implementation of marching cubes used. - See for example the following papers for details about how to identify a - DOI which specifies the implementation used: + See for example the following papers for details about specific + MC implementations: * `W. E. Lorensen <https://doi.org/10.1109/MCG.2020.2971284>`_ * `T. S. Newman and H. Yi <https://doi.org/10.1016/j.cag.2006.07.021>`_ - - The value placed here should be a DOI. If there are no specific DOI or - details write not_further_specified, or give at least a free-text - description. + + + + + Free text field in case a proper identifier is not available. diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 60033d7a6b..715e0c8eea 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -3,7 +3,7 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -48,23 +48,23 @@ - Base class to describe the delocalization of point-like objects on a grid. + Base class of the configuration and results of a delocalization algorithm. - Such a procedure is for instance used in image processing and e.g. atom probe - microscopy (APM) to discretize a point cloud onto a grid to enable e.g. - computing of point density, composition, or concentration values, obtain - scalar fields, and compute gradients of these fields. + Delocalization is used to distribute point-like objects on a grid to obtain + e.g. smoother count, composition, or concentration values of scalar fields + and compute gradients of these fields. - + - Reference or link to the grid on which the delocalization is applied. + Details about the grid on which the delocalization is applied. - - - - Reference or link to the points which are delocalized on the grid. - - + + - + - The weighting model specifies how mark data are mapped to a weight per point. + The weighting model specifies how mark data are mapped to a weight per point/object. For atom probe microscopy (APM) as an example, different models are used which account differently for the multiplicity of an ion/atom: * default, points all get the same weight 1.; - for APM this is equivalent to ion species + for APM this is equivalent to (molecular) iontype-based delocalization * atomic_decomposition, points get as much weight as they have atoms of a type in element_whitelist, * isotope_decomposition, points get as much weight as they have - isotopes of a type in isotope_whitelist. + nuclids of a type in isotope_whitelist. This description shows an example that could be reinterpreted for similar such data processing steps in other fields of science. @@ -124,22 +124,22 @@ i.e. if isotope_decomposition is set isotope_whitelist is required?--> - + Attribute data for each member of the point cloud. For APM these are the - ion species labels generated via ranging. The number of mark data per - point is 1 in the case for atom probe. + iontypes generated via ranging. The number of mark data per point is 1 + in the case for atom probe. - + Weighting factor with which the integrated intensity per grid cell is - multiplied specifically for each point. For APM the weight are positive - integer values, specifically the multiplicity of the ion, + multiplied specifically for each point/object. For APM the weight are + positive integer values, specifically the multiplicity of the ion, according to the details of the weighting_model. diff --git a/contributed_definitions/NXevent_data_apm.nxdl.xml b/contributed_definitions/NXevent_data_apm.nxdl.xml new file mode 100644 index 0000000000..66029763b9 --- /dev/null +++ b/contributed_definitions/NXevent_data_apm.nxdl.xml @@ -0,0 +1,265 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of pulses collected in between start_time and end_time. + + + + + Base class to store state and (meta)data of events over the course of an atom probe experiment. + + This base class applies the concept of the :ref:`NXevent_data_em` base class to the specific needs + of atom probe research. Against static and dynamic quantities are splitted to avoid a duplication + of information. Specifically, the time interval considered is the entire time + starting at start_time until end_time during which we assume the pulser triggered named pulses. + These pulses are identified via the pulse_identifier field. The point in time when each was issued + is specified via the combination of start_time and delta_time. + + Conceptually and technically NeXus currently stores tensorial information as arrays of values + (with each value of the same datatype). For instance, a field temperature(NX_FLOAT) stores + a set of temperature values but that field when used somewhere is a concept. However, that + concept has no information at which point in time these temperatures were taken. + An existent functional relationship between the two concepts is not defined. + + However, a correct interpretation of the temperature values demands knowledge about what is + the independent quantity on which temperature depends on or according to which frequency + temperature values were sampled. + In NeXus there are two approaches which cope with such correlations: + One is :ref:`NXdata` where the attribute signal specifies the correlation. + The other one is :ref:`NXlog` which, like NXdata, demands to granularize logged_against + (dependent signal) and independent quantities into an own group. + In many cases this additional grouping is not desired though. + + One naive solution typically employed is then to store the independent variable values via a second + vector e.g. time_stamp with the same number of entries (with dimensionality defined through symbols). + However, there is no independent logical connection between these two concepts, i.e. temperature + and time_stamp. + + In the case of atom probe though the time that one would use in NXlog is defined implicitly via pulse_identifier, + which is the independent variable vector against which eventually dozens of channels of data are logged. + Not only are these channels logged they should ideally also be self-descriptive in that these channels have + pulse_identifier as the independent variable but we do not wish to duplicate this information all the time but + reference it. + + Therefore, we here explore the use of an attribute with symbol logged_against. Maybe it is better to use the + symbol depends_on but this is easily to be confused with depends_on that is used for instances of + :ref:`NXtransformations`. Consequently, if depends_on were to be used extra logic is needed by consuming + applications to understand that the here build correlations are conceptually different ones. + + This issue should be discussed further by the NeXus community. + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval started. If the user wishes to specify an + interval of time that the snapshot should represent during which the instrument + was stable and configured using specific settings and calibrations, + the start_time is the start (left bound of the time interval) while + the end_time specifies the end (right bound) of the time interval. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the snapshot time interval ended. + + + + + Delta time array which resolves for each pulse_identifier the time difference + between when that pulse was issued and start_time. + + In summary, using start_time, end_time, delta_time, pulse_identifier_offset, + and pulse_identifier exactly specifies the connection between when a pulse was + issued relative to start and absolute in UTC. + + + + + + + + Integer used to name the first pulse to know if there is an + offset of the identifiers to zero. + + Identifiers can be defined either implicitly or explicitly. + For implicit indexing identifiers are defined on the interval + :math:`[identifier_offset, identifier_offset + c - 1]`. + + Therefore, implicit identifier are completely defined by the value of + identifier_offset and cardinality. For example if identifier run from + -2 to 3 the value for identifier_offset is -2. + + For explicit indexing the field identifier has to be used. + Fortran-/Matlab- and C-/Python-style indexing have specific implicit + identifier conventions where identifier_offset is 1 and 0 respectively. + + + + + Identifier that contextualizes how the detector and pulser of an atom probe + instrument follows a sequence of pulses to trigger field evaporation. + + The pulse_identifier is used to associate thus an information about time + when the quantities documented in this NXpulser_apm base class have been + collected via sampling. + + In virtually all cases the pulser is a blackbox. Depending on how the + instrument is configured during a measurement the target + values and thus also the actual values may change. + + Maybe the first part of the experiment is run at a certain pulse fraction but thereafter + the pulse_fraction is changed. In this case the field pulse_fraction is a vector which + collects all measured values of the pulse_fraction, pulse_identifier is then an equally + long vector which stores the set of events (e.g. pulsing events) when that value was + measured. + + This may cause several situations: In the case that e.g. the pulse_fraction is never changed + and also exact details not interesting, one stores the set value for the pulse_fraction + and a single value for the pulse_identifier e.g. 0 to indicate that the pulse_fraction was set + at the beginning and it was maintained constant during the measurement. + If the pulse_fraction was maybe changed after the 100000th pulse, pulse_fraction is a + vector with two values one for the first and another one for the value from the 100000-th + pulse onwards. The values of pulse_identifier are then [0, 99999] respectively. + + + + + + + + (Meta)data of the dynamics and changes of the microscope over the course of + pulsing. + + + + + + + Amplitude of the signal detected on the multi-channel plate (MCP). + + This field should be used for storing the signal amplitude quantity + within ATO files. The ATO file format is used primarily by the + atom probe groups of the GPM in Rouen, France. + + + + + + + + + + + + Average temperature at the specimen base, i.e. + base_temperature during the measurement. + + + + + + The best estimate, at experiment time, for the temperature at the + sample base (furthest point along sample apex and holding assembly + that is removable from the sample stage). + + + + + + + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + + + + + + + + Average pressure in the analysis chamber during the measurement. + + + + + Pressure in the analysis chamber. + + + + + + + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + + + + + + + + Pressure in the analysis chamber. + + + + + + + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + + + + + + + + Pressure in the analysis chamber. + + + + + + + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + + + + + + + diff --git a/contributed_definitions/NXevent_data_apm_set.nxdl.xml b/contributed_definitions/NXevent_data_apm_set.nxdl.xml new file mode 100644 index 0000000000..e4e89e920a --- /dev/null +++ b/contributed_definitions/NXevent_data_apm_set.nxdl.xml @@ -0,0 +1,48 @@ + + + + + + Base class for a set of :ref:`NXevent_data_apm` instances. + + Members of the set are instances of :ref:`NXevent_data_apm`. + These have an associated time interval during which the conditions + of the instrument were considered stable and fit enough for purpose. + + Which temporal granularity is adequate depends on the situation and research + question. Using a model which enables a collection of events offers the most + flexible way to cater for both atom probe experiments or simulation. + + To monitor the course of an ion extraction experiment (or simulation) + it makes sense to track time explicitly via time stamps or implicitly + via e.g. a clock inside the instrument, such as the clock of the pulser + and respective pulsing event identifier. + + As set and measured quantities typically change over time and we do not + yet know during the measurement which of the events have associated + (molecular) ions that will end up in the reconstructed volume, we must not + document quantities as a function of the evaporated_identifier but as a + function of the (pulsing) event_identifier. + + + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index 78a9db9e99..475332f45d 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -3,7 +3,7 @@ Assumed volume of the ion. In atom probe microscopy this field can be used to store the reconstructed - volume per ion (average) which is typically stored in range files and will - be used when building a tomographic reconstruction of an atom probe - dataset. + volume per ion (average) which is typically stored alongside ranging + definitions. @@ -123,21 +116,18 @@ Signed charge state of the ion in multiples of electron charge. - Only positive values will be measured in atom probe microscopy as the - ions are accelerated by a negatively signed bias electric field. + Only positive values will be measured in atom probe microscopy + as the ions are accelerated by a negatively signed bias electric field. In the case that the charge state is not explicitly recoverable, the value should be set to zero. In atom probe microscopy this is for example the case when using - classical range file formats like RNG, RRNG for atom probe data. - These file formats do not document the charge state explicitly. - They report the number of atoms of each element per molecular ion + classical ranging definition files in formats like RNG, RRNG. + These file formats do not document the charge state explicitly + but the number of atoms of each element per molecular ion surplus the mass-to-charge-state-ratio interval. - With this information it is possible to recover the charge state only - for specific molecular ions as the accumulated mass of the molecular ion - is defined by the isotopes, which without knowing the charge, leads - to an underconstrained problem. - Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + Details on ranging definition files can be found in the literature: + `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ @@ -147,7 +137,7 @@ notation to specify the isotopes, ions, and charge state. Examples are 12C + or Al +++. - To ease automated parsing isotope_vector should be the + To ease automated parsing, isotope_vector should be the preferred machine-readable information used. @@ -156,8 +146,8 @@ Associated lower (mqmin) and upper (mqmax) bounds of the mass-to-charge-state ratio interval(s) [mqmin, mqmax] (boundaries inclusive). This field is primarily of interest - for documenting :ref:`NXprocess` steps of indexing a ToF/mass-to-charge - state histogram. + for documenting :ref:`NXprocess` steps of indexing a + ToF/mass-to-charge state histogram. diff --git a/contributed_definitions/NXisocontour.nxdl.xml b/contributed_definitions/NXisocontour.nxdl.xml index a54805a64c..182fe98106 100644 --- a/contributed_definitions/NXisocontour.nxdl.xml +++ b/contributed_definitions/NXisocontour.nxdl.xml @@ -3,7 +3,7 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -33,13 +33,13 @@ - Settings of a filter to select or remove entries based on their value. + Base class of a filter to select members of a set based on their identifier. - + - Meaning of the filter: + Definition of the logic what the filter yields: Whitelist specifies which entries with said value to include. - Entries with all other values will be filtered out. + Entries with all other values will be excluded. Blacklist specifies which entries with said value to exclude. Entries with all other values will be included. @@ -51,10 +51,9 @@ - Array of values to filter according to method. For example if the filter - specifies [1, 5, 6] and method is whitelist, only entries with values - matching 1, 5 or 6 will be processed. All other entries will be filtered - out. + Array of values to filter according to method. If the match e.g. specifies + [1, 5, 6] and method is set to whitelist, only entries with values matching + 1, 5 or 6 will be processed. All other entries will be excluded. diff --git a/contributed_definitions/NXpeak.nxdl.xml b/contributed_definitions/NXpeak.nxdl.xml index f39d938c2c..aeec36f244 100644 --- a/contributed_definitions/NXpeak.nxdl.xml +++ b/contributed_definitions/NXpeak.nxdl.xml @@ -1,9 +1,9 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -33,21 +33,21 @@ - Description of peaks, their functional form or measured support. + Base class for peaks, their functional form, and measured support. - + - Human-readable identifier to specify which concept/entity + Human-readable label which specifies which concept/entity the peak represents/identifies. - + Is the peak described analytically via a functional form or is it empirically defined via measured/reported intensity/counts as a function of an independent variable. - If the functional form is not empirical or gaussian, users + If the functional form is not empirical or Gaussians, users should enter other for the peak_model and add relevant details in the NXcollection. @@ -80,7 +80,7 @@ In the case of an analytical description (or if peak_model is other) this collection holds parameter of (and eventually) the functional form. - For example in the case of Gaussians mu, sigma, cut-off values, + For example in the case of Gaussians mu, sigma, cut-off values, and background intensity are relevant parameter. diff --git a/contributed_definitions/NXpulser_apm.nxdl.xml b/contributed_definitions/NXpulser_apm.nxdl.xml index b45230e1ec..9bb6e60798 100644 --- a/contributed_definitions/NXpulser_apm.nxdl.xml +++ b/contributed_definitions/NXpulser_apm.nxdl.xml @@ -1,9 +1,9 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. - + - Total number of ions collected. + Number of pulses collected in between start_time and end_time + resolved by an instance of :ref:`NXevent_data_apm`. - Metadata for laser- and/or voltage-pulsing in atom probe microscopy. + Base class for a laser- and/or voltage-pulsing device used in atom probe + microscopy. - + - How is field evaporation physically triggered. + Detail whereby ion extraction is triggered methodologically. @@ -46,14 +48,28 @@ + - Frequency with which the high voltage or laser pulser fires. + Frequency with which the pulser fire(s). - - + + + + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + + @@ -61,48 +77,72 @@ to the standing_voltage at peak voltage of a pulse. If a standing voltage is applied, this gives nominal pulse fraction - (as a function of standing voltage). Otherwise this field should not be - present. + (as a function of standing voltage). Otherwise, this field should + not be present. - + + + + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + + - + + - In laser pulsing mode the values will be zero so the this field is recommended. - However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. + Pulsed voltage, in laser pulsing mode this field can be omitted. - + + + + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + + Absolute number of pulses starting from the beginning of the experiment. - + + + + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + + + Direct current voltage between the specimen and the (local electrode) in - the case of local electrode atom probe (LEAP) instrument. - The standing voltage applied to the sample, relative to system ground. + the case of local electrode atom probe (LEAP) instrument. Otherwise, the + standing voltage applied to the sample, relative to system ground. - + + + + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + + - Atom probe microscopes use controlled laser, voltage, - or a combination of pulsing strategies to trigger the - excitation and eventual field evaporation/emission of - an ion during an experiment. + Atom probe microscopes use controlled laser, voltage, or a combination of + pulsing strategies to trigger ion extraction via exciting and eventual field evaporation + field emission of ion at the specimen surface. - + Given name/alias. @@ -118,38 +158,70 @@ Nominal power of the laser source while illuminating the specimen. - Average energy of the laser at peak of each pulse. + + + + + + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + + - Details about specific positions along the focused laser beam + Details about specific positions along the laser beam which illuminates the (atom probe) specimen. - + - Track time-dependent settings over the course of the - measurement how the laser beam in tip space/reconstruction space - laser impinges on the sample, i.e. the mean vector is parallel to - the laser propagation direction. + Track time-dependent settings over the course of the measurement + how the laser beam shines on the specimen, i.e. the mean vector + is parallel to the laser propagation direction. - - + + + + + + + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + + + + - Track time-dependent settings over the course of the - measurement where the laser beam exits the - focusing optics. + Track time-dependent settings over the course of the measurement + where the laser beam exits the focusing optics. - - + + + + + + + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + + + + Track time-dependent settings over the course of the measurement where the laser hits the specimen. - + + + + + + + Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. + + + @@ -157,10 +229,10 @@ laser focusing optics/pinhole-attached coordinate system is defined, how it has to be transformed so that it aligns with the specimen coordinate system. - A right-handed Cartesian coordinate system, the so-called laser space, - should be assumed, whose positive z-axis points - into the direction of the propagating laser beam. + diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml index 20d083590e..4bde635a54 100644 --- a/contributed_definitions/NXreflectron.nxdl.xml +++ b/contributed_definitions/NXreflectron.nxdl.xml @@ -1,9 +1,9 @@ - + - + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of pulses collected in between start_time and end_time + resolved by an instance of :ref:`NXevent_data_apm`. + + + - Device for reducing flight time differences of ions in ToF experiments. - For atom probe the reflectron can be considered an energy_compensation - device, which can e.g. be realized technically as via a Poschenrieder lens - (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). + Base class for a device which reduces ToF differences of ions in ToF experiments. + + For atom probe the reflectron can be considered an energy compensation device. + Such a device can be realized technically for example with a Poschenrieder lens. + + Consult the following U.S. patents for further details: + + * 3863068 and 6740872 for the reflectron + * 8134119 for the curved reflectron - + + + Status of eventual existence and potential usage of this reflectron. + + + + + + + + Given name/alias. - + Free-text field to specify further details about the reflectron. The field can be used to inform e. g. if the reflectron is flat or curved. - + + + The maximum voltage applied to the reflectron, relative to system ground. + + + - Affine transformation(s) which detail where the reflectron - is located relative to e.g. the origin of the specimen space - reference coordinate system. - This group can also be used for specifying how the reflectron - is rotated relative to the specimen axis. - The purpose of these more detailed instrument descriptions - is to support the creation of a digital twin of the instrument - for computational science. + Affine transformation(s) which detail where the reflectron is located + relative to e.g. the origin of the specimen space reference coordinate + system. This group can also be used for specifying how the reflectron + is rotated relative to a given axis in the instrument. + diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index 74cd0a1771..de2110b840 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -1,9 +1,9 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -43,29 +43,26 @@ - Total number of similarity groups aka features, objects, clusters. + Total number of similarity groups aka features/clusters. - Metadata to the results of a similarity grouping analysis. + Base class to store results obtained from applying a similarity grouping (clustering) algorithm. - Similarity grouping analyses can be supervised segmentation or machine learning - clustering algorithms. These are routine methods which partition the member of - a set of objects/geometric primitives into (sub-)groups, features of - different type. A plethora of algorithms have been proposed which can be applied - also on geometric primitives like points, triangles, or (abstract) features aka - objects (including categorical sub-groups). + Similarity grouping algorithms are segmentation or machine learning algorithms for + partitioning the members of a set of objects (e.g. geometric primitives) into + (sub-)groups aka features of different kind/type. A plethora of algorithms exists. - This base class considers metadata and results of one similarity grouping - analysis applied to a set in which objects are either categorized as noise - or belonging to a cluster. - As the results of the analysis each similarity group, here called feature - aka object can get a number of numerical and/or categorical labels. + This base class considers metadata and results of having a similarity grouping + algorithm applied to a set in which objects are either categorized as noise + or belonging to a cluster, i.e. members of a cluster. + The algorithm assigns each similarity group (feature/cluster) at least one + identifier (numerical or categorical labels) to distinguish different cluster. - Number of members in the set which is partitioned into features. + Number of members in the set which gets partitioned into features. @@ -78,26 +75,25 @@ How many categorical labels does each feature have. - - + + - Which identifier is the first to be used to label a cluster. + Which numerical identifier is the first to be used to label a feature. The value should be chosen in such a way that special values can be resolved: - * identifier_offset-1 indicates an object belongs to no cluster. - * identifier_offset-2 indicates an object belongs to the noise category. + * identifier_offset - 1 indicates that an object belongs to no cluster. + * identifier_offset - 2 indicates that an object belongs to the noise category. Setting for instance identifier_offset to 1 recovers the commonly used - case that objects of the noise category get values to -1 and unassigned points to 0. - Numerical identifier have to be strictly increasing. + case that objects of the noise category get values to -1 and unassigned + points to 0. Numerical identifier have to be strictly increasing. - - - - + Matrix of numerical label for each member in the set. For classical clustering algorithms this can for instance @@ -112,8 +108,6 @@ Matrix of categorical attribute data for each member in the set. - @@ -121,44 +115,39 @@ e.g. (NXclustering_hdbscan):--> - In addition to the detailed storage which members was grouped to which + In addition to the detailed storage which objects were grouped to which feature/group summary statistics are stored under this group. - - + + - Total number of members in the set which are categorized as unassigned. + Total number of features categorized as unassigned. - - - - Total number of members in the set which are categorized as noise. + Total number of features categorized as noise. - - - - - + - Total number of clusters (excluding noise and unassigned). + Total number of features. - + + - Array of numerical identifier of each feature (cluster). + Array of numerical identifier of each feature. - + - - + - Array of number of members for each feature. + Array of number of objects for each feature. diff --git a/contributed_definitions/NXspatial_filter.nxdl.xml b/contributed_definitions/NXspatial_filter.nxdl.xml index 7a0680911d..a11d63664c 100644 --- a/contributed_definitions/NXspatial_filter.nxdl.xml +++ b/contributed_definitions/NXspatial_filter.nxdl.xml @@ -1,9 +1,9 @@ - + - - + + The symbols used in the schema to specify e.g. dimensions of arrays. - - - Number of ellipsoids. - - Number of hexahedra. @@ -44,42 +39,51 @@ Number of cylinders. + + + Number of ellipsoids. + + + + + Number of polyhedra. + + - Spatial filter to filter entries within a region-of-interest based on their - position. + Base class for a spatial filter for objects within a region-of-interest (ROI). + + Objects can be points or objects composed from other geometric primitives. - + - Qualitative statement which specifies which spatial filtering with respective - geometric primitives or bitmask is used. These settings are possible: - - * entire_dataset, no filter is applied, the entire dataset is used. - * union_of_primitives, a filter with (rotated) geometric primitives. - All ions in or on the surface of the primitives are considered - while all other ions are ignored. - * bitmasked_points, a boolean array whose bits encode with 1 - which ions should be included. Those ions whose bit is set to 0 - will be excluded. Users of python can use the bitfield operations - of the numpy package to define such bitfields. + Qualitative statement which describes the logical operations + that define which objects will be included and which excluded: - Conditions: - In the case that windowing_method is entire_dataset all entries are processed. - In the case that windowing_method is union_of_primitives, - it is possible to specify none or all types of primitives - (ellipsoids, cylinder, hexahedra). If no primitives are specified - the filter falls back to entire_dataset. - In the case that windowing_method is bitmask, the bitmask has to be defined; - otherwise the filter falls back to entire dataset. + * entire_dataset, no filter is applied, all objects are included. + * union_of_primitives, a filter with (possibly non-axis-aligned) geometric + primitives. Objects in or on the surface of the primitives are included. + All other objects are excluded. + * bitmask, a boolean array whose bits encode with 1 which objects + are included. Bits set to zero encode which objects are excluded. + Users of python can use the bitfield operations + of the numpy package to work with bitfields. + - - + + + diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml index 2253cbf9a4..2ecb9877a0 100644 --- a/contributed_definitions/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -1,9 +1,9 @@ - + - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - + + - Settings of a filter to sample entries based on their value. + Base class of a filter to sample members in a set based on their identifier. - + - Triplet of the minimum, increment, and maximum value which will - be included in the analysis. The increment controls which n-th entry to take. + Triplet of the minimum, the increment, and the maximum identifier to + include of a sequence :math:`[i_0, i_0 + 1, i_0 + 2, \ldots, i_0 + \mathcal{N}] with i_0 \in \mathcal{Z}` + of identifier. The increment controls which n-th identifier (value) to take. - Take as an example a dataset with 100 entries (their indices start at zero) - and the filter set to 0, 1, 99. This will process each entry. - 0, 2, 99 will take each second entry. 90, 3, 99 will take only each third - entry beginning from entry 90 up to 99. + Take as an example a dataset with 100 identifier (aka entries). Assume that + the identifier start at zero, i.e. identifier_offset is 0). Assume further + that min_incr_max is set to [0, 1, 99]. In this case the filter will + yield all identifier. Setting min_incr_max to [0, 2, 99] will take each + second identifier. Setting min_incr_max to [90, 3, 99] will take each + third identifier beginning from identifier 90 up to 99. diff --git a/contributed_definitions/nyaml/refactor/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml similarity index 99% rename from contributed_definitions/nyaml/refactor/NXapm.yaml rename to contributed_definitions/nyaml/NXapm.yaml index ae810b2635..80c57bc231 100644 --- a/contributed_definitions/nyaml/refactor/NXapm.yaml +++ b/contributed_definitions/nyaml/NXapm.yaml @@ -5,12 +5,10 @@ symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. p: | - Number of pulses collected in between start_time and end_time - resolved by an instance of :ref:`NXevent_data_apm`. - - If this is not defined, p is the number of ions included in the reconstructed - volume if the application definition is used to store results of an already - reconstructed datasets. + Number of pulses collected in between start_time and end_time resolved by an + instance of :ref:`NXevent_data_apm`. If this is not defined, p is the number of + ions included in the reconstructed volume if the application definition is used + to store results of an already reconstructed datasets. n: | Number of ions spatially filtered from results of the hit_finding algorithm from which an instance of a reconstructed volume has been generated. diff --git a/contributed_definitions/nyaml/refactor/NXapm_charge_state_analysis.yaml b/contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXapm_charge_state_analysis.yaml rename to contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml diff --git a/contributed_definitions/nyaml/refactor/NXapm_composition_space_results.yaml b/contributed_definitions/nyaml/NXapm_composition_space_results.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXapm_composition_space_results.yaml rename to contributed_definitions/nyaml/NXapm_composition_space_results.yaml diff --git a/contributed_definitions/nyaml/refactor/NXapm_hit_finding.yaml b/contributed_definitions/nyaml/NXapm_hit_finding.yaml similarity index 88% rename from contributed_definitions/nyaml/refactor/NXapm_hit_finding.yaml rename to contributed_definitions/nyaml/NXapm_hit_finding.yaml index 12cc6ec9e6..06cfd01cc1 100644 --- a/contributed_definitions/nyaml/refactor/NXapm_hit_finding.yaml +++ b/contributed_definitions/nyaml/NXapm_hit_finding.yaml @@ -8,11 +8,9 @@ symbols: Number of delay-line wires of the detector. p: | Number of pulses collected in between start_time and end_time - resolved by an instance of :ref:`NXevent_data_apm`. - - If this is not defined, p is the number of ions included in the reconstructed - volume if an application definition is used to store results of already - reconstructed datasets. + resolved by an instance of :ref:`NXevent_data_apm`. If this is not defined, + p is the number of ions included in the reconstructed volume if an application + definition is used to store results of already reconstructed datasets. type: group NXapm_hit_finding(NXprocess): # when evolving these ideas further inherit from NXapm_method instead (NXprogram): diff --git a/contributed_definitions/nyaml/refactor/NXapm_msr.yaml b/contributed_definitions/nyaml/NXapm_msr.yaml similarity index 98% rename from contributed_definitions/nyaml/refactor/NXapm_msr.yaml rename to contributed_definitions/nyaml/NXapm_msr.yaml index 8e4734280c..3c0792807a 100644 --- a/contributed_definitions/nyaml/refactor/NXapm_msr.yaml +++ b/contributed_definitions/nyaml/NXapm_msr.yaml @@ -7,7 +7,7 @@ doc: | experiments and computer simulations for atom probe research. The main motivation for this is the ongoing development and tighter becoming connection between atom probe - and other material characterization techniques foremost electron microscopy (see `T. Kelly et al. `_, `C. Fleischmann et al. `_, and `W. Windl et al. `_ or `C. Freysoldt et al. https://doi.org/10.1103/PhysRevLett.124.176801>`_ to mention but a few). + and other material characterization techniques foremost electron microscopy (see `T. Kelly et al. `_, `C. Fleischmann et al. `_, and `W. Windl et al. `_ or `C. Freysoldt et al. `_ to mention but a few). To arrive at a design of base classes and an application definition which can be used for both real and simulated atom probe experiments, it is worthwhile to recall concepts that are related to events and (molecular) ions: * Pulsing events which are used to trigger ion extraction events. diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_clusterer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_clusterer.yaml rename to contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.yaml diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_distancer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_distancer.yaml rename to contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.yaml diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_intersector.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_intersector.yaml rename to contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.yaml diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_nanochem.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_nanochem.yaml rename to contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_selector.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_selector.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_selector.yaml rename to contributed_definitions/nyaml/NXapm_paraprobe_config_selector.yaml diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_spatstat.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_spatstat.yaml rename to contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_surfacer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_surfacer.yaml rename to contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_tessellator.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXapm_paraprobe_config_tessellator.yaml rename to contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_ranger_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXapm_paraprobe_ranger_config.yaml rename to contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_ranger_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXapm_paraprobe_ranger_results.yaml rename to contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_clusterer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_clusterer.yaml rename to contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.yaml diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_distancer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_distancer.yaml rename to contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.yaml diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_intersector.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_intersector.yaml rename to contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.yaml diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_nanochem.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_nanochem.yaml rename to contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_selector.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_selector.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_selector.yaml rename to contributed_definitions/nyaml/NXapm_paraprobe_results_selector.yaml diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_spatstat.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_spatstat.yaml rename to contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.yaml diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_surfacer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_surfacer.yaml rename to contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.yaml diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_tessellator.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXapm_paraprobe_results_tessellator.yaml rename to contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.yaml diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_tool_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXapm_paraprobe_tool_config.yaml rename to contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_tool_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tool_results.yaml similarity index 99% rename from contributed_definitions/nyaml/refactor/NXapm_paraprobe_tool_results.yaml rename to contributed_definitions/nyaml/NXapm_paraprobe_tool_results.yaml index be8bb3c342..79fa60efee 100644 --- a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_tool_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tool_results.yaml @@ -80,7 +80,7 @@ NXapm_paraprobe_tool_results(NXprocess): * recon The aim of this convention is to support users with contextualizing which reference - frame each instance (coordinate system) is. If needed, instances of :ref:`NXtranslations` + frame each instance (coordinate system) is. If needed, instances of :ref:`NXtransformations` are used to detail the explicit affine transformations whereby one can convert rpresentations between different reference frames. Inspect :ref:`NXtransformations` for further details. diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_transcoder_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXapm_paraprobe_transcoder_config.yaml rename to contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml diff --git a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_transcoder_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml similarity index 96% rename from contributed_definitions/nyaml/refactor/NXapm_paraprobe_transcoder_results.yaml rename to contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml index 2a7d3c3ea9..ef57262903 100644 --- a/contributed_definitions/nyaml/refactor/NXapm_paraprobe_transcoder_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml @@ -31,12 +31,8 @@ symbols: 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 mapped on this ion type. n_topology: | Total number of integers in the supplementary XDMF topology array. - n_combinatorics: | - Number of ions probed in the combinatorial analysis of the charge states. # i be careful n_comb can vary for every instance of (NXion) ! type: group NXapm_paraprobe_transcoder_results(NXobject): @@ -66,14 +62,14 @@ NXapm_paraprobe_transcoder_results(NXobject): dim: (n_ions,) reconstruction(NXprocess): reconstructed_positions(NX_FLOAT): - \@depends_on(NX_CHAR): - doc: | - Point to the coordinate system in which these positions are defined. doc: | Three-dimensional reconstructed positions of the ions. Interleaved array of x, y, z positions in the specimen space. unit: NX_LENGTH dim: (n_ions, 3) + \@depends_on(NX_CHAR): + doc: | + Point to the coordinate system in which these positions are defined. visualization(NXprocess): exists: recommended xdmf_topology(NX_UINT): @@ -117,6 +113,7 @@ NXapm_paraprobe_transcoder_results(NXobject): If used, metadata of at least the person who performed this analysis. name(NX_CHAR): (NXcoordinate_system_set): + exists: [min, 1, max, 1] paraprobe(NXcoordinate_system): type(NX_CHAR): handedness(NX_CHAR): diff --git a/contributed_definitions/nyaml/refactor/NXapm_ranging.yaml b/contributed_definitions/nyaml/NXapm_ranging.yaml similarity index 79% rename from contributed_definitions/nyaml/refactor/NXapm_ranging.yaml rename to contributed_definitions/nyaml/NXapm_ranging.yaml index 15f505f45d..e3b93d312d 100644 --- a/contributed_definitions/nyaml/refactor/NXapm_ranging.yaml +++ b/contributed_definitions/nyaml/NXapm_ranging.yaml @@ -1,19 +1,21 @@ category: base doc: | Base class for the configuration and results of ranging definitions. + + Ranging is a data post-processing step used in the research field of + atom probe during which elemental, isotopic, and/or molecular identities + are assigned to mass-to-charge-state-ratios within a certain interval. + The documentation of these steps is based on ideas that + have been described in the literature: + + * `M. K. Miller `_ + * `D. Haley et al. `_ + * `M. Kühbach et al. `_ + type: group NXapm_ranging(NXprocess): # when evolving these ideas further inherit from NXapm_method instead - doc: | - Data post-processing step in which elemental, isotopic, and/or molecular - identities are assigned to mass-to-charge-state-ratios within a certain - interval. The documentation of these steps is based on ideas that - have been described in the literature: - - * `M. K. Miller `_ - * `D. Haley et al. `_ - * `M. Kühbach et al. `_ - (NXprogram): + (NXserialized): number_of_ion_types(NX_UINT): doc: | How many ion types are distinguished. If no ranging was performed, each diff --git a/contributed_definitions/nyaml/refactor/NXapm_reconstruction.yaml b/contributed_definitions/nyaml/NXapm_reconstruction.yaml similarity index 63% rename from contributed_definitions/nyaml/refactor/NXapm_reconstruction.yaml rename to contributed_definitions/nyaml/NXapm_reconstruction.yaml index b875d3630e..684cf19b52 100644 --- a/contributed_definitions/nyaml/refactor/NXapm_reconstruction.yaml +++ b/contributed_definitions/nyaml/NXapm_reconstruction.yaml @@ -1,6 +1,11 @@ category: base doc: | Base class for the configuration and results of a (static) reconstruction algorithm. + + Generating a tomographic reconstruction of the specimen uses selected and + calibrated ion hit positions, the evaporation sequence, and voltage curve data. + Very often scientists use own software scripts according to published procedures, + so-called reconstruction protocols. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -13,13 +18,6 @@ symbols: type: group NXapm_reconstruction(NXprocess): # when evolving these ideas further inherit from NXapm_method instead - 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 how to - compute x, y, z atomic positions from the above-mentioned input data. (NXprogram): (NXserialized): # config/input @@ -45,13 +43,13 @@ NXapm_reconstruction(NXprocess): doc: | The instance of :ref:`NXcoordinate_system` in which the positions are defined. - naive_discretization(NXprocess): - (NXprogram): - # config/input - # results - (NXdata): - doc: | - To get a first visual overview of the reconstructed dataset, - here a 3d histogram of the ion is stored. Ion counts are characterized - using one nanometer cubic bins without applying position smoothening - algorithms during the histogram computation. + naive_discretization(NXprocess): + (NXprogram): + # config/input + # results + (NXdata): + doc: | + To get a first visual overview of the reconstructed dataset, + here a 3d histogram of the ion is stored. Ion counts are characterized + using one nanometer cubic bins without applying position smoothening + algorithms during the histogram computation. diff --git a/contributed_definitions/nyaml/refactor/NXapm_sim.yaml b/contributed_definitions/nyaml/NXapm_sim.yaml similarity index 95% rename from contributed_definitions/nyaml/refactor/NXapm_sim.yaml rename to contributed_definitions/nyaml/NXapm_sim.yaml index d8741eab06..9f584c1019 100644 --- a/contributed_definitions/nyaml/refactor/NXapm_sim.yaml +++ b/contributed_definitions/nyaml/NXapm_sim.yaml @@ -13,6 +13,4 @@ doc: | # is a large availability of documentation and open-source tools for performing such simulations. type: group NXapm_sim(NXobject): # when evolving these ideas further inherit from NXapm_method instead - doc: | - Details about the simulation. (NXprogram): diff --git a/contributed_definitions/nyaml/refactor/NXapm_volt_and_bowl.yaml b/contributed_definitions/nyaml/NXapm_volt_and_bowl.yaml similarity index 85% rename from contributed_definitions/nyaml/refactor/NXapm_volt_and_bowl.yaml rename to contributed_definitions/nyaml/NXapm_volt_and_bowl.yaml index abe7132516..7562a33296 100644 --- a/contributed_definitions/nyaml/refactor/NXapm_volt_and_bowl.yaml +++ b/contributed_definitions/nyaml/NXapm_volt_and_bowl.yaml @@ -1,6 +1,9 @@ category: base doc: | Base class for the configuration and results from a voltage-and-bowl ToF correction algorithm. + + The voltage-and-bowl correction is a ata post-processing step to correct for ion impact position + flight path differences, detector biases, and nonlinearities. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -12,10 +15,6 @@ symbols: the pulse_identifier! type: group NXapm_volt_and_bowl(NXprocess): # when evolving these ideas further inherit from NXapm_method instead - 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. (NXprogram): (NXserialized): # config/input to the algorithm diff --git a/contributed_definitions/nyaml/refactor/NXcg_marching_cubes.yaml b/contributed_definitions/nyaml/NXcg_marching_cubes.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXcg_marching_cubes.yaml rename to contributed_definitions/nyaml/NXcg_marching_cubes.yaml diff --git a/contributed_definitions/nyaml/refactor/NXcs_filter_boolean_mask.yaml b/contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXcs_filter_boolean_mask.yaml rename to contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml diff --git a/contributed_definitions/nyaml/refactor/NXdelocalization.yaml b/contributed_definitions/nyaml/NXdelocalization.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXdelocalization.yaml rename to contributed_definitions/nyaml/NXdelocalization.yaml diff --git a/contributed_definitions/nyaml/refactor/NXevent_data_apm.yaml b/contributed_definitions/nyaml/NXevent_data_apm.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXevent_data_apm.yaml rename to contributed_definitions/nyaml/NXevent_data_apm.yaml diff --git a/contributed_definitions/nyaml/refactor/NXevent_data_apm_set.yaml b/contributed_definitions/nyaml/NXevent_data_apm_set.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXevent_data_apm_set.yaml rename to contributed_definitions/nyaml/NXevent_data_apm_set.yaml diff --git a/contributed_definitions/nyaml/refactor/NXion.yaml b/contributed_definitions/nyaml/NXion.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXion.yaml rename to contributed_definitions/nyaml/NXion.yaml diff --git a/contributed_definitions/nyaml/refactor/NXisocontour.yaml b/contributed_definitions/nyaml/NXisocontour.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXisocontour.yaml rename to contributed_definitions/nyaml/NXisocontour.yaml diff --git a/contributed_definitions/nyaml/refactor/NXmatch_filter.yaml b/contributed_definitions/nyaml/NXmatch_filter.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXmatch_filter.yaml rename to contributed_definitions/nyaml/NXmatch_filter.yaml diff --git a/contributed_definitions/nyaml/refactor/NXpeak.yaml b/contributed_definitions/nyaml/NXpeak.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXpeak.yaml rename to contributed_definitions/nyaml/NXpeak.yaml diff --git a/contributed_definitions/nyaml/refactor/NXpulser_apm.yaml b/contributed_definitions/nyaml/NXpulser_apm.yaml similarity index 97% rename from contributed_definitions/nyaml/refactor/NXpulser_apm.yaml rename to contributed_definitions/nyaml/NXpulser_apm.yaml index cc8798d0db..fbb3a8cf4c 100644 --- a/contributed_definitions/nyaml/refactor/NXpulser_apm.yaml +++ b/contributed_definitions/nyaml/NXpulser_apm.yaml @@ -91,10 +91,6 @@ NXpulser_apm(NXobject): \@logged_against(NX_CHAR): doc: | Path to pulse_identifier in an instance of :ref:`NXevent_data_apm`. - \@depends_on(NX_CHAR): - doc: | - Path to an instance of :ref:`NXcoordinate_system` which - specifies the reference frame in which the laser is shining. (NXbeam): doc: | Details about specific positions along the laser beam diff --git a/contributed_definitions/nyaml/refactor/NXreflectron.yaml b/contributed_definitions/nyaml/NXreflectron.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXreflectron.yaml rename to contributed_definitions/nyaml/NXreflectron.yaml diff --git a/contributed_definitions/nyaml/refactor/NXsimilarity_grouping.yaml b/contributed_definitions/nyaml/NXsimilarity_grouping.yaml similarity index 73% rename from contributed_definitions/nyaml/refactor/NXsimilarity_grouping.yaml rename to contributed_definitions/nyaml/NXsimilarity_grouping.yaml index 6c3fe92bf4..bf8ffab934 100644 --- a/contributed_definitions/nyaml/refactor/NXsimilarity_grouping.yaml +++ b/contributed_definitions/nyaml/NXsimilarity_grouping.yaml @@ -69,7 +69,6 @@ NXsimilarity_grouping(NXobject): In addition to the detailed storage which objects were grouped to which feature/group summary statistics are stored under this group. # at the level of the object set - # at the level of the feature set unassigned(NX_UINT): doc: | @@ -83,40 +82,15 @@ NXsimilarity_grouping(NXobject): doc: | Total number of features. unit: NX_UNITLESS -# number_of_unassigned_members(NX_UINT): -# doc: | -# Total number of members in the set which are categorized as unassigned. -# unit: NX_UNITLESS -# dim: (n_lbl_num,) -# number_of_noise_members(NX_UINT): -# doc: | -# Total number of members in the set which are categorized as noise. -# unit: NX_UNITLESS -# dim: (n_lbl_num,) - # at the level of the feature set - number_of_features(NX_UINT): - doc: | - Total number of features (excluding noise and unassigned). - unit: NX_UNITLESS - feature_identifier(NX_UINT): + # Total number of features (excluding noise and unassigned) can be trivially computed + # when knowing total, noise, and unassigned. + identifier(NX_UINT): doc: | - Array of numerical identifier of each feature (cluster). + Array of numerical identifier of each feature. unit: NX_UNITLESS - dim: (n_features, n_lbl_num) - feature_member_count(NX_UINT): + dim: (n_features,) + member_count(NX_UINT): doc: | Array of number of objects for each feature. unit: NX_UNITLESS dim: (n_features, n_lbl_num) -# feature_size(NX_NUMBER): -# doc: | -# unit: NX_UNITLESS -# doc: | -# Number of objects associated to each cluster. The labels are implicit, -# meaning the zeroth/first entry in the array belongs to the first cluster, -# the second entry to the second cluster and so on and so forth. -# The first cluster has the value of identifier_offset as its identifier. -# The second cluster has identifier_offset + 1, and so on and so forth. -# dimensions: -# rank: 1 -# dim: [[1, n_cluster]] diff --git a/contributed_definitions/nyaml/refactor/NXspatial_filter.yaml b/contributed_definitions/nyaml/NXspatial_filter.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXspatial_filter.yaml rename to contributed_definitions/nyaml/NXspatial_filter.yaml diff --git a/contributed_definitions/nyaml/refactor/NXsubsampling_filter.yaml b/contributed_definitions/nyaml/NXsubsampling_filter.yaml similarity index 100% rename from contributed_definitions/nyaml/refactor/NXsubsampling_filter.yaml rename to contributed_definitions/nyaml/NXsubsampling_filter.yaml diff --git a/contributed_definitions/nyaml/refactor/deprecate/NXapm.yaml b/contributed_definitions/nyaml/refactor/deprecate/NXapm.yaml deleted file mode 100644 index 925aad4569..0000000000 --- a/contributed_definitions/nyaml/refactor/deprecate/NXapm.yaml +++ /dev/null @@ -1,3303 +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 -type: group -NXapm(NXobject): - (NXentry): - exists: ['min', '1', 'max', 'unbounded'] - \@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', 'unbounded'] - 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', 'unbounded'] - 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 - unit: NX_LENGTH - doc: | - Qualitative information about the grain size, here specifically - described as the equivalent spherical diameter of an assumed - average grain size for the crystal ensemble. - Users of this information should be aware that although the grain - diameter or radius is often referred to as grain size 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. - grain_diameter_error(NX_FLOAT): - exists: optional - unit: NX_LENGTH - doc: | - Magnitude of the standard deviation of the grain_diameter. - heat_treatment_temperature(NX_FLOAT): - exists: optional - unit: NX_TEMPERATURE - doc: | - The temperature of the last heat treatment step before quenching. - Knowledge about this value can give an idea how the sample - was heat treated, however if 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. - heat_treatment_temperature_error(NX_FLOAT): - exists: optional - unit: NX_TEMPERATURE - doc: | - Magnitude of the standard deviation of the heat_treatment_temperature. - heat_treatment_quenching_rate(NX_FLOAT): - exists: optional - unit: NX_ANY - doc: | - Rate of the last quenching step. - Knowledge about this value can give an idea how the 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. - heat_treatment_quenching_rate_error(NX_FLOAT): - exists: optional - unit: NX_ANY - doc: | - Magnitude of the standard deviation of the heat_treatment_quenching_rate. - description: - 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): - unit: NX_DIMENSIONLESS - 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. - composition_error(NX_FLOAT): - exists: optional - unit: NX_DIMENSIONLESS - doc: | - Magnitude of the standard deviation of the composition (value). - 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', 'unbounded'] - - # 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', 'unbounded'] - - # 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): - unit: NX_LENGTH - doc: | - The space inside the atom probe along which ions pass nominally - when they leave the specimen and travel to the detector. - - THIS DOCSTRING NEEDS CLARIFICATION. - - # 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 - unit: NX_LENGTH - 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. - (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 - (NXfabrication): - exists: optional - identifier: - exists: recommended - capabilities: - exists: optional - value(NX_NUMBER): - exists: recommended - (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 - unit: NX_CURRENT - doc: | - Amplitude of the signal detected on the multi-channel plate (MCP). - - This field should be used for storing the signal amplitude quantity - within ATO files. The ATO file format is used primarily by the - atom probe groups of the GPM in Rouen, France. - dimensions: - rank: 1 - dim: [[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 - (NXbeam): - exists: ['min', '0', 'max', 'unbounded'] - pinhole_position(NXcollection): - exists: recommended - spot_position(NXcollection): - 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): - unit: NX_TEMPERATURE - doc: | - Average temperature at the specimen base, i.e. - base_temperature during the measurement. - temperature(NX_FLOAT): - exists: optional - unit: NX_TEMPERATURE - 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). - 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): - unit: NX_PRESSURE - doc: | - Average pressure in the analysis chamber. - (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): - unit: NX_PRESSURE - doc: | - Average pressure in the buffer chamber. - (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): - unit: NX_PRESSURE - doc: | - Average pressure in the load_lock_chamber. - (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 spatiotemporally data could be stored. - - # NEW ISSUE: consider the above comments into new fields when important progress has been made. - initial_radius(NX_FLOAT): - unit: NX_LENGTH - doc: | - Ideally measured or best elaborated guess of the - initial radius of the specimen. - shank_angle(NX_FLOAT): - unit: NX_ANGLE - 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. - detection_rate(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Average detection rate over the course of the experiment. - - # 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 - unit: NX_ANY - doc: | - Estimated field at the apex along the evaporation sequence. - 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', 'unbounded'] - 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 - - # NEW ISSUE: check also here the PYCCAPT pipeline from P. Felfer's group - ion_impact_positions(NXprocess): - 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', 'unbounded'] - program: - \@version: - - # NEW ISSUE: discuss with Oxcart developers which - # modifications might be necessary here. - arrival_time_pairs(NX_NUMBER): - exists: recommended - unit: NX_TIME - doc: | - Raw readings from the analog-to-digital-converter - timing circuits of the detector wires. - dimensions: - rank: 3 - dim: [[1, n_ions], [2, n_dld_wires], [3, 2]] - hit_positions(NX_NUMBER): - unit: NX_LENGTH - 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. - 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 - - # NEW ISSUE: use symbols to monitor number of pulses - hit_multiplicity(NXprocess): - 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', 'unbounded'] - program: - \@version: - pulses_since_last_ion(NX_UINT): - exists: recommended - unit: NX_UNITLESS - 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]] - - # 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. - pulse_id(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - Number of pulses since the start of the atom probe - run/evaporation sequence. - dimensions: - rank: 1 - dim: [[1, n_ions]] - hit_multiplicity(NX_UINT): - unit: NX_UNITLESS - - # 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]] - 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', 'unbounded'] - program: - \@version: - evaporation_id_included(NX_BOOLEAN): - doc: | - Bitmask which is set to true if the ion - is considered and false otherwise. - dimensions: - rank: 1 - dim: [[1, n_ions]] - - # NEW ISSUE: add section for propagation_delay(NXprocess) ? - voltage_and_bowl_correction(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', 'unbounded'] - 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 - unit: NX_TIME - doc: | - Raw time-of-flight data as read out from the acquisition software - if these data are available and accessible. - dimensions: - rank: 1 - dim: [[1, n_ions]] - calibrated_tof(NX_FLOAT): - unit: NX_TIME - - # 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. - 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', 'unbounded'] - program: - \@version: - parameter(NXcollection): - exists: recommended - doc: | - Store vendor-specific calibration models here (if available). - mass_to_charge(NX_FLOAT): - unit: NX_ANY - doc: | - Mass-to-charge-state ratio values. - - # \@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', 'unbounded'] - 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): - unit: NX_LENGTH - doc: | - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - dimensions: - rank: 2 - dim: [[1, n_ions], [2, 3]] - visualization(NXprocess): - exists: recommended - xdmf_topology(NX_UINT): - unit: NX_UNITLESS - 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. - dimensions: - rank: 1 - dim: [[1, n_topology]] - - # n_topology == 3*n_ions - xdmf_topology(NX_UINT): - unit: NX_UNITLESS - 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. - 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', 'unbounded'] - 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): - unit: NX_UNITLESS - doc: | - Array of counts for each bin. - dimensions: - rank: 3 - dim: [[1, n_z], [2, n_y], [3, n_x]] - axis_z(NX_FLOAT): - unit: NX_LENGTH - doc: | - Bin center of mass position along the z axis. - dimensions: - rank: 1 - dim: [[1, n_z]] - \@long_name: - axis_y(NX_FLOAT): - unit: NX_LENGTH - doc: | - Bin center of mass position along the y axis. - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - axis_x(NX_FLOAT): - unit: NX_LENGTH - doc: | - Bin center of mass position along the x axis. - 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', 'unbounded'] - program: - \@version: - number_of_ion_types(NX_UINT): - unit: NX_UNITLESS - doc: | - How many ion types are distinguished. - If no ranging was performed each ion is of the special unknown type. - The iontype ID of this unknown type is 0 which is a reserve value. - Consequently, iontypes start counting from 1. - maximum_number_of_atoms_per_molecular_ion(NX_UINT): - unit: NX_UNITLESS - doc: | - Assumed maximum value that suffices to store all relevant - molecular ions, even the most complicated ones. - Currently a value of 32 is used. - 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', 'unbounded'] - program: - \@version: - range_minmax(NX_FLOAT): - unit: NX_ANY - doc: | - Smallest and largest mass-to-charge-state ratio value. - - # \@units: Da - # NEW ISSUE: NX_ATOMIC_MASS_UNIT use Tommasso scheme here Da - dimensions: - rank: 1 - dim: [[1, 2]] - range_increment(NX_FLOAT): - unit: NX_ANY - doc: | - Binning width of the mass-to-charge-state ratio values. - - # \@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): - unit: NX_UNITLESS - doc: | - Array of counts for each bin. - dimensions: - rank: 1 - dim: [[1, n_bins]] - \@long_name: - axis_mass_to_charge(NX_FLOAT): - unit: NX_ANY - doc: | - Right boundary of each mass-to-charge-state ratio value bin. - - # \@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', 'unbounded'] - 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', 'unbounded'] - program: - \@version: - (NXpeak): - exists: ['min', '0', 'max', 'unbounded'] - 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', 'unbounded'] - 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 - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 612ced9157105a0063ebb6500dcdb1852b6094678e7f79eda066ae6b4a8a08ed -# -# -# -# -# -# -# -# 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 spatiotemporally data could be stored. -# -# -# -# -# Ideally measured or best elaborated guess of the -# initial radius of the specimen. -# -# -# -# -# Ideally measured or best elaborated guess of the shank angle. -# This is a measure of the specimen taper. Define it in such a way -# that the base of the specimen is modelled as a conical frustrum so -# that the shank angle is the (shortest) angle between the specimen -# space z-axis and a vector on the lateral surface of the cone. -# -# -# -# -# Average detection rate over the course of the experiment. -# -# -# -# -# -# Estimated field at the apex along the evaporation sequence. -# -# -# -# -# -# -# -# -# The majority of atom probe microscopes come from a -# single commercial manufacturer `AMETEK (formerly Cameca) <https://www.atomprobe.com>`_. -# Their instruments are controlled via an(/a set) of integrated -# instrument control system(s) (APSuite/IVAS/DAVis). -# -# By contrast, instruments which were built by individual -# research groups such as of the French (GPM, Rouen, France), -# the Schmitz (Inspico, Stuttgart, Germany), -# the Felfer (Oxcart, Erlangen, Germany), -# the Northwestern (D. Isheim, Seidman group et al.), -# or the PNNL group (Pacific Northwest National Laborary, -# Portland, Oregon, U.S.) have other solutions -# to control the instrument. -# -# Some of which are modularized and open, -# some of which realize also integrated control units with -# portions of eventually undisclosed source code and -# (so far) lacking (support of)/open APIs. -# -# Currently, there is no accepted/implemented -# community-specific API for getting finely granularized -# access to such control settings. -# -# These considerations motivated the design of the NXapm -# application definition in that it stores quantities in NXcollection. -# groups to begin with. Holding heterogeneous, not yet standardized -# but relevant pieces of information is the purpose of this collection. -# -# -# -# -# -# -# -# -# -# Track time-dependent details over the course of the measurement about the -# buffer_chamber. -# -# -# -# -# Track time-dependent details over the course of the measurement about the -# load_lock_chamber. -# -# -# -# -# Track time-dependent details over the course of the measurement about the -# analysis_chamber. -# -# -# -# -# -# -# -# A statement whether the measurement was successful or failed prematurely. -# -# -# -# -# -# -# -# -# -# -# -# -# Details about where ions hit the ion_detector and data processing -# steps related to analog-to-digital conversion of detector signals -# into ion hit positions. For AMETEK LEAP instruments this processing -# takes place partly in the control unit of the detector partly -# in the software. The process is controlled by the acquisition/ -# instrument control software (IVAS/APSuite/DAVis). -# The exact details are not documented by AMETEK in an open manner. -# For instruments built by individual research groups, -# like the Oxcart instrument, individual timing data from the -# delay-line detector are openly accessible. -# -# -# -# -# -# -# -# -# -# -# Raw readings from the analog-to-digital-converter -# timing circuits of the detector wires. -# -# -# -# -# -# -# -# -# -# Evaluated ion impact coordinates at the detector -# (either as computed from the arrival time data -# or as reported by the control software). -# If the acquisition software enables it one can also store in this -# field the hit_positions, as measured by the detector, without any -# corrections. -# -# -# -# -# -# -# -# -# -# -# This could be a place where currently the publicly undocumented -# algorithmic steps are stored how detected hits are judged for their -# quality. In CamecaRoot this there is something mentioned like -# golden and partial hits, here is where this could be documented. -# -# -# -# -# -# -# Data post-processing step which is, like the impact position analyses, -# usually executed in the integrated control software. This processing -# yields how many ions were detected with each pulse. -# -# It is possible that multiple ions evaporate and hit the same or -# different pixels of the detector on the same pulse. -# These data form the basis to analyses of the so-called -# (hit) multiplicity of an ion. -# -# Multiplicity must not be confused with how many atoms -# f the same element or isotope, respectively, a molecular -# ion contains (which is instead encoded with the -# isotope_vector field of each NXion instance). -# -# -# -# -# -# -# -# -# -# Number of pulses since the last detected ion pulse. -# For multi-hit records, after the first record, this is zero. -# -# -# -# -# -# -# -# -# Number of pulses since the start of the atom probe -# run/evaporation sequence. -# -# -# -# -# -# -# -# -# Hit multiplicity. -# -# -# -# -# -# -# -# -# Like impact position and hit multiplicity computations, -# ion filtering is a data post-processing step with which users -# identify which of the detected ions should be included -# in the voltage-and-bowl correction. -# This post-processing is usually performed via GUI interaction -# in the reconstruction pipeline of IVAS/APSuite. -# -# -# -# -# -# -# -# -# -# Bitmask which is set to true if the ion -# is considered and false otherwise. -# -# -# -# -# -# -# -# -# -# Data post-processing step to correct for ion impact -# position flight path differences, detector biases, -# and nonlinearities. This step is usually performed -# with commercial software. -# -# -# -# -# -# -# -# -# -# -# Raw time-of-flight data as read out from the acquisition software -# if these data are available and accessible. -# -# -# -# -# -# -# -# -# Calibrated time-of-flight. -# -# -# -# -# -# -# -# The key idea and algorithm of the voltage-and-bowl correction is -# qualitatively similar for instruments of different manufacturers -# or research groups. -# -# Specific differences exists though in the form of different -# calibration models. For now we do not wish to resolve or -# generalize these differences. Rather the purpose of this collection -# is to provide a container where model-specific parameters -# and calibration models can be stored if users know these -# for sure. -# -# For AMETEK LEAP instruments this should be the place for -# storing initial calibration values. These values are -# accessible normally only by AMETEK service engineers. -# They use these for calibrating the detector and instrument. -# -# Users can also use this NXcollection for storing the -# iteratively identified calibrations which scientists -# will see displayed in e.g. APSuite while they execute -# the voltage-and-bowl correction as a part of the -# reconstruction pipeline in APSuite. -# -# -# -# -# -# -# Data post-processing step in which calibrated time-of-flight data -# (ToF) are interpreted into mass-to-charge-state ratios. -# -# -# -# -# -# -# -# -# -# Store vendor-specific calibration models here (if available). -# -# -# -# -# Mass-to-charge-state ratio values. -# -# -# -# -# -# -# -# -# -# -# Data post-processing step to create a tomographic reconstruction -# of the specimen based on selected calibrated ion hit positions, -# the evaporation sequence, and voltage curve data. -# Very often scientists use own software scripts according to -# published procedures, so-called reconstruction protocols, -# i.e. numerical recipes how to compute x, y, z atomic positions -# from the input data. -# -# -# -# -# -# -# -# -# -# Qualitative statement about which reconstruction protocol was used. -# -# -# -# -# -# -# -# -# -# -# -# -# Different reconstruction protocols exist. Although these approaches -# are qualitatively similar, each protocol uses different parameters -# (and interprets these differently). The source code to IVAS/APSuite -# is not open. For now users should store reconstruction parameter -# in a collection. -# -# -# -# -# -# Different strategies for crystallographic calibration of the -# reconstruction are possible. The field is required and details -# should be specified in free-text at least. If the not crystallographic -# calibration was performed the field should be filled with the n/a, -# meaning not applied. -# -# -# -# -# Three-dimensional reconstructed positions of the ions. -# Interleaved array of x, y, z positions in the specimen space. -# -# -# -# -# -# -# -# -# -# An array of triplets of integers which can serve as a supplementary -# array for Paraview to display the reconstructed dataset. -# The XDMF primitive type is here 1, the number of primitives 1 per -# triplet, the last integer in each triplet is the identifier of -# each point starting from zero. -# -# -# -# -# -# -# -# -# -# Six equally formatted sextets chained together. For each -# sextett the first entry is an XDMF primitive topology -# key (here 5 for polygon), the second entry the XDMF primitive -# count value (here 4 because each face is a quad). -# The remaining four values are the vertex indices. -# -# -# -# -# -# -# -# To get a first overview of the reconstructed dataset, -# the format conversion computes a simple 3d histogram -# of the ion density using one nanometer cubic bins without -# applying smoothening algorithms on this histogram. -# -# -# -# -# -# -# -# -# A default three-dimensional histogram of the total -# number of ions in each bin obtained via using a rectangular -# transfer function. -# -# -# -# -# -# -# -# -# Array of counts for each bin. -# -# -# -# -# -# -# -# -# -# Bin center of mass position along the z axis. -# -# -# -# -# -# -# -# -# Bin center of mass position along the y axis. -# -# -# -# -# -# -# -# -# Bin center of mass position along the x axis. -# -# -# -# -# -# -# -# -# -# -# -# -# Data post-processing step in which elemental, isotopic, -# and/or molecular identities are assigned to the ions. -# The documentation of these steps is based on ideas -# described in the literature: -# -# * `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ -# * `D. Haley et al. <https://doi.org/10.1017/S1431927620024290>`_ -# * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ -# -# -# -# -# -# -# -# -# -# How many ion types are distinguished. -# If no ranging was performed each ion is of the special unknown type. -# The iontype ID of this unknown type is 0 which is a reserve value. -# Consequently, iontypes start counting from 1. -# -# -# -# -# Assumed maximum value that suffices to store all relevant -# molecular ions, even the most complicated ones. -# Currently a value of 32 is used. -# -# -# -# -# Specifies the computation of the mass-to-charge histogram. -# Usually mass-to-charge values are studied as an ensemble quantity, -# specifically these values are binned. -# This (NXprocess) stores the settings of this binning. -# -# -# -# -# -# -# -# -# Smallest and largest mass-to-charge-state ratio value. -# -# -# -# -# -# -# -# -# Binning width of the mass-to-charge-state ratio values. -# -# -# -# -# -# A default histogram aka mass spectrum of -# the mass-to-charge-state ratio values. -# -# -# -# -# -# -# -# -# Array of counts for each bin. -# -# -# -# -# -# -# -# -# Right boundary of each mass-to-charge-state ratio value bin. -# -# -# -# -# -# -# -# -# -# -# -# Details of the background model which was used to -# correct the total counts per bin into counts. -# -# -# -# -# -# -# -# -# -# -# How where peaks in the background-corrected in the histogram -# of mass-to-charge-state ratio values identified? -# -# -# -# -# -# -# -# -# -# -# THIS DOCSTRING NEEDS CLARIFICATION. -# -# -# -# -# -# -# Details about how peaks, with taking into account -# error models, were interpreted as ion types or not. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/refactor/deprecate/NXapm_input_ranging.yaml b/contributed_definitions/nyaml/refactor/deprecate/NXapm_input_ranging.yaml deleted file mode 100644 index 74a555657c..0000000000 --- a/contributed_definitions/nyaml/refactor/deprecate/NXapm_input_ranging.yaml +++ /dev/null @@ -1,25 +0,0 @@ -category: base -doc: | - Metadata to ranging definitions made for a dataset in atom probe microscopy. - - Ranging is the process of labeling time-of-flight data with so-called iontypes. - Iontypes ideally specify the most likely (molecular) ion that is assumed of having - been evaporated and laying within a mass-to-charge-state-ratio value interval. - - The so-called UNKNOWNTYPE iontype represents the null model of an event/ion - that has not been ranged. The identifier of this special iontype is always 0. -# symbols: -type: group -NXapm_input_ranging(NXserialized): - group_name_iontypes(NX_CHAR): - doc: | - Name of the (parent) group (prefix to the individual ranging definitions) - inside the file referred to by path which points to the specific ranging - definition to use. - Container files can store multiple ranging definitions. - Using an identifier allows for a distinction which specific - definitions to apply. - - Remember that the identifier of the reconstruction and ranging definitions - can differ despite the fact that using the same filenames for the reconstruction - and ranging definitions files has become common practice. diff --git a/contributed_definitions/nyaml/refactor/deprecate/NXapm_input_reconstruction.yaml b/contributed_definitions/nyaml/refactor/deprecate/NXapm_input_reconstruction.yaml deleted file mode 100644 index dc7a90f947..0000000000 --- a/contributed_definitions/nyaml/refactor/deprecate/NXapm_input_reconstruction.yaml +++ /dev/null @@ -1,19 +0,0 @@ -category: base -doc: | - Data artifact representing a tomographic reconstruction in atom probe microscopy. - - Typically, reconstructions in the field of atom probe tomography are communicated - via files which store reconstructed ion positions and mass-to-charge-state-ratio values. - Container files like HDF5 can store multiple reconstructions. This base class specifies - which specific reconstruction one likes to refer to. -# symbols: -type: group -NXapm_reconstruction(NXserialized): - dataset_name_reconstruction(NX_CHAR): - doc: | - Name of the dataset which refers to the specific reconstructed - ion positions to use for this analysis. - dataset_name_mass_to_charge(NX_CHAR): - doc: | - Name of the dataset which refers to the specific mass-to-charge- - state-ratio values to use for this analysis. diff --git a/contributed_definitions/nyaml/refactor/deprecate/NXapm_mass_to_charge.yaml b/contributed_definitions/nyaml/refactor/deprecate/NXapm_mass_to_charge.yaml deleted file mode 100644 index b6b8e42935..0000000000 --- a/contributed_definitions/nyaml/refactor/deprecate/NXapm_mass_to_charge.yaml +++ /dev/null @@ -1,5 +0,0 @@ -category: base -doc: | - Base class for collecting the configuration and results from ToF to mass-to-charge-state ratio algorithm. -type: group -NXapm_mass_to_charge(NXprocess): # when evolving these ideas further inherit from NXapm_method instead diff --git a/contributed_definitions/nyaml/refactor/deprecate/find_a_place_in_nxapm.txt b/contributed_definitions/nyaml/refactor/deprecate/find_a_place_in_nxapm.txt deleted file mode 100644 index 946e12ec55..0000000000 --- a/contributed_definitions/nyaml/refactor/deprecate/find_a_place_in_nxapm.txt +++ /dev/null @@ -1,643 +0,0 @@ - # https://fairmat-experimental.github.io/nexus-fairmat-proposal/ - # 50433d9039b3f33299bab338998acb5335cd8951/classes/ - - - 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 - - - - - # 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 - - # NEW ISSUE: check also here the PYCCAPT pipeline from P. Felfer's group - ion_impact_positions(NXprocess): - 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', 'unbounded'] - program: - \@version: - - # NEW ISSUE: discuss with Oxcart developers which - # modifications might be necessary here. - arrival_time_pairs(NX_NUMBER): - exists: recommended - unit: NX_TIME - doc: | - Raw readings from the analog-to-digital-converter - timing circuits of the detector wires. - dimensions: - rank: 3 - dim: [[1, n_ions], [2, n_dld_wires], [3, 2]] - hit_positions(NX_NUMBER): - unit: NX_LENGTH - 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. - 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 - - # NEW ISSUE: use symbols to monitor number of pulses - hit_multiplicity(NXprocess): - 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', 'unbounded'] - program: - \@version: - pulses_since_last_ion(NX_UINT): - exists: recommended - unit: NX_UNITLESS - 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]] - - # 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. - pulse_id(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - Number of pulses since the start of the atom probe - run/evaporation sequence. - dimensions: - rank: 1 - dim: [[1, n_ions]] - hit_multiplicity(NX_UINT): - unit: NX_UNITLESS - - # 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]] - 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', 'unbounded'] - program: - \@version: - evaporation_id_included(NX_BOOLEAN): - doc: | - Bitmask which is set to true if the ion - is considered and false otherwise. - dimensions: - rank: 1 - dim: [[1, n_ions]] - - # NEW ISSUE: add section for propagation_delay(NXprocess) ? - voltage_and_bowl_correction(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', 'unbounded'] - 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 - unit: NX_TIME - doc: | - Raw time-of-flight data as read out from the acquisition software - if these data are available and accessible. - dimensions: - rank: 1 - dim: [[1, n_ions]] - calibrated_tof(NX_FLOAT): - unit: NX_TIME - - # 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. - 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', 'unbounded'] - program: - \@version: - parameter(NXcollection): - exists: recommended - doc: | - Store vendor-specific calibration models here (if available). - mass_to_charge(NX_FLOAT): - unit: NX_ANY - doc: | - Mass-to-charge-state ratio values. - - # \@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', 'unbounded'] - 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): - unit: NX_LENGTH - doc: | - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - dimensions: - rank: 2 - dim: [[1, n_ions], [2, 3]] - visualization(NXprocess): - exists: recommended - xdmf_topology(NX_UINT): - unit: NX_UNITLESS - 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. - dimensions: - rank: 1 - dim: [[1, n_topology]] - - # n_topology == 3*n_ions - xdmf_topology(NX_UINT): - unit: NX_UNITLESS - 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. - 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', 'unbounded'] - 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): - unit: NX_UNITLESS - doc: | - Array of counts for each bin. - dimensions: - rank: 3 - dim: [[1, n_z], [2, n_y], [3, n_x]] - axis_z(NX_FLOAT): - unit: NX_LENGTH - doc: | - Bin center of mass position along the z axis. - dimensions: - rank: 1 - dim: [[1, n_z]] - \@long_name: - axis_y(NX_FLOAT): - unit: NX_LENGTH - doc: | - Bin center of mass position along the y axis. - dimensions: - rank: 1 - dim: [[1, n_y]] - \@long_name: - axis_x(NX_FLOAT): - unit: NX_LENGTH - doc: | - Bin center of mass position along the x axis. - 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', 'unbounded'] - program: - \@version: - number_of_ion_types(NX_UINT): - unit: NX_UNITLESS - doc: | - How many ion types are distinguished. - If no ranging was performed each ion is of the special unknown type. - The iontype ID of this unknown type is 0 which is a reserve value. - Consequently, iontypes start counting from 1. - maximum_number_of_atoms_per_molecular_ion(NX_UINT): - unit: NX_UNITLESS - doc: | - Assumed maximum value that suffices to store all relevant - molecular ions, even the most complicated ones. - Currently a value of 32 is used. - 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', 'unbounded'] - program: - \@version: - range_minmax(NX_FLOAT): - unit: NX_ANY - doc: | - Smallest and largest mass-to-charge-state ratio value. - - # \@units: Da - # NEW ISSUE: NX_ATOMIC_MASS_UNIT use Tommasso scheme here Da - dimensions: - rank: 1 - dim: [[1, 2]] - range_increment(NX_FLOAT): - unit: NX_ANY - doc: | - Binning width of the mass-to-charge-state ratio values. - - # \@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): - unit: NX_UNITLESS - doc: | - Array of counts for each bin. - dimensions: - rank: 1 - dim: [[1, n_bins]] - \@long_name: - axis_mass_to_charge(NX_FLOAT): - unit: NX_ANY - doc: | - Right boundary of each mass-to-charge-state ratio value bin. - - # \@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', 'unbounded'] - 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', 'unbounded'] - program: - \@version: - (NXpeak): - exists: ['min', '0', 'max', 'unbounded'] - 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', 'unbounded'] - 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 - - flight_path_geometry(NX_CHAR): - doc: | - Qualitative descriptor to distinguish flight_path geometries. - enumeration: [straight, curved] - 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. - unit: NX_LENGTH # mm - - field_of_view(NX_FLOAT): # property of the reconstruction! - 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 - - - - # 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 \ No newline at end of file From 5960792ef5d3ed23ab1fe48da166b4c68bd789b4 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 8 Jan 2024 11:01:31 +0100 Subject: [PATCH 0442/1012] update axis docstring with unit categories --- contributed_definitions/NXmpes.nxdl.xml | 46 ++++++++++++----------- contributed_definitions/nyaml/NXmpes.yaml | 45 +++++++++++----------- 2 files changed, 48 insertions(+), 43 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 725e268c5d..49edb36c36 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -355,16 +355,16 @@ a field of type NXdata_mpes_detector - **pixel_x**: Detector pixel in x direction. - **pixel_y**: Detector pixel in y direction. - - **raw_time_of_flight**: The raw time of flight in DAQ clock pulses. - - **time_of_flight**: Total time of flight. + - **raw_time_of_flight**: The raw time of flight in DAQ clock pulses. Unit category: NX_PULSES + - **time_of_flight**: Total time of flight. Unit category: NX_TIME_OF_FLIGHT - **time_of_flight_adc**: Time-of-flight values, analog-to-digital converted. - - **polar_angle_manipulator**: Polar rotation angle of the manipulator. - - **azimuthal_angle_manipulator**: Azimuthal rotation angle of the manipulator. - - **delay_position**: Delay position of delay line detector. + - **polar_angle_manipulator**: Polar rotation angle of the manipulator. Unit category: NX_ANGLE + - **azimuthal_angle_manipulator**: Azimuthal rotation angle of the manipulator. Unit category: NX_ANGLE + - **delay_position**: Delay position of delay line detector. Unit category: NX_LENGTH - **delay_position_ADC**: Delay position of delay line detector, analog-to-digital converted. - - **time_delay_x**: Time delay of delay line detector in x direction. - - **time_delay_y**: Time delay of delay line detector in y direction. - - **voltage**: Voltage applied to sample and sample holder. + - **time_delay_x**: Time delay of delay line detector in x direction. Unit category: NX_TIME + - **time_delay_y**: Time delay of delay line detector in y direction. Unit category: NX_TIME + - **voltage**: Voltage applied to sample and sample holder. Unit category: NX_VOLTAGE - **external_AXIS**: Describes an axis which is coming from outside the detectors scope. @@ -603,24 +603,27 @@ a field of type NXdata_mpes_detector - - An NXdata field containing a view on the measured links. - This data fields contains a collection of the main releveant fields. - The data fields ideally should be named according to conventions + An NXdata field containing a view on the measured data. + This NXdata field contains a collection of the main relevant fields (axes). + In NXmpes, it is required to provide an energy axis. + The other data fields ideally should be named according to conventions to ensure compatibility. We recommened the following field names for common data fields: - - **kx**: Calibrated x axis in k-space. Units should be 1/Angström. - - **ky**: Calibrated y axis in k-space. Units should be 1/Angström. - - **kz**: Calibrated z axis in k-space. Units should be 1/Angström. - - **delay**: Calibrated delay time. The unit category should be NX_TIME. + - **kx**: Calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). + - **ky**: Calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). + - **kz**: Calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). + - **delay**: Calibrated delay time. Unit category: NX_TIME (s). - **polarization_angle**: Linear polarization angle of the incoming or - outgoing beam. The unit category should be NX_ANGLE. - - **ellipticity**: Ellipticity of the incoming or outgoing beam. Can be - any of linear polarization angle (degrees), ellipticity (arb. units). + outgoing beam. This could be a link to + /entry/instrument/beam/incident_polarization_angle or + /entry/instrument/beam/final_polarization_angle if they exist. + Unit category: NX_ANGLE (° or rad) + - **ellipticity**: Ellipticity of the incoming or outgoing beam. + Could be a link to /entry/instrument/beam/incident_ellipticity or + /entry/instrument/beam/final_ellipticity if they exist. + Unit category: NX_ANGLE (° or rad) @@ -635,7 +638,6 @@ to be replaced by NXdata_mpes with base class inheritance actual encoder position in NXinstrument or calibrated axes in NXprocess. - Calibrated energy axis. diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index ad9b3e731a..9af0a12813 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -287,16 +287,16 @@ NXmpes(NXobject): - **pixel_x**: Detector pixel in x direction. - **pixel_y**: Detector pixel in y direction. - - **raw_time_of_flight**: The raw time of flight in DAQ clock pulses. - - **time_of_flight**: Total time of flight. + - **raw_time_of_flight**: The raw time of flight in DAQ clock pulses. Unit category: NX_PULSES + - **time_of_flight**: Total time of flight. Unit category: NX_TIME_OF_FLIGHT - **time_of_flight_adc**: Time-of-flight values, analog-to-digital converted. - - **polar_angle_manipulator**: Polar rotation angle of the manipulator. - - **azimuthal_angle_manipulator**: Azimuthal rotation angle of the manipulator. - - **delay_position**: Delay position of delay line detector. + - **polar_angle_manipulator**: Polar rotation angle of the manipulator. Unit category: NX_ANGLE + - **azimuthal_angle_manipulator**: Azimuthal rotation angle of the manipulator. Unit category: NX_ANGLE + - **delay_position**: Delay position of delay line detector. Unit category: NX_LENGTH - **delay_position_ADC**: Delay position of delay line detector, analog-to-digital converted. - - **time_delay_x**: Time delay of delay line detector in x direction. - - **time_delay_y**: Time delay of delay line detector in y direction. - - **voltage**: Voltage applied to sample and sample holder. + - **time_delay_x**: Time delay of delay line detector in x direction. Unit category: NX_TIME + - **time_delay_y**: Time delay of delay line detector in y direction. Unit category: NX_TIME + - **voltage**: Voltage applied to sample and sample holder. Unit category: NX_VOLTAGE - **external_AXIS**: Describes an axis which is coming from outside the detectors scope. exists: recommended \@signal: @@ -507,22 +507,27 @@ NXmpes(NXobject): doc: | Voltage applied to sample and sample holder. (NXdata): - # to be replaced by NXdata_mpes with base class inheritance doc: | - An NXdata field containing a view on the measured links. - This data fields contains a collection of the main releveant fields. - The data fields ideally should be named according to conventions + An NXdata field containing a view on the measured data. + This NXdata field contains a collection of the main relevant fields (axes). + In NXmpes, it is required to provide an energy axis. + The other data fields ideally should be named according to conventions to ensure compatibility. We recommened the following field names for common data fields: - - **kx**: Calibrated x axis in k-space. Units should be 1/Angström. - - **ky**: Calibrated y axis in k-space. Units should be 1/Angström. - - **kz**: Calibrated z axis in k-space. Units should be 1/Angström. - - **delay**: Calibrated delay time. The unit category should be NX_TIME. + - **kx**: Calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). + - **ky**: Calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). + - **kz**: Calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). + - **delay**: Calibrated delay time. Unit category: NX_TIME (s). - **polarization_angle**: Linear polarization angle of the incoming or - outgoing beam. The unit category should be NX_ANGLE. - - **ellipticity**: Ellipticity of the incoming or outgoing beam. Can be - any of linear polarization angle (degrees), ellipticity (arb. units). + outgoing beam. This could be a link to + /entry/instrument/beam/incident_polarization_angle or + /entry/instrument/beam/final_polarization_angle if they exist. + Unit category: NX_ANGLE (° or rad) + - **ellipticity**: Ellipticity of the incoming or outgoing beam. + Could be a link to /entry/instrument/beam/incident_ellipticity or + /entry/instrument/beam/final_ellipticity if they exist. + Unit category: NX_ANGLE (° or rad) \@signal: enumeration: [data] data(NX_NUMBER): @@ -532,8 +537,6 @@ NXmpes(NXobject): 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. - - # in NXmpes, we should require an energy axis energy(NX_NUMBER): unit: NX_ENERGY doc: | From 4806e3f0bd32833127cfe010507776cd41834d7b Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 8 Jan 2024 13:33:04 +0100 Subject: [PATCH 0443/1012] Rename detector/data to detector/raw_data --- contributed_definitions/NXmpes.nxdl.xml | 9 ++++++--- contributed_definitions/nyaml/NXmpes.yaml | 9 ++++++--- 2 files changed, 12 insertions(+), 6 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 49edb36c36..8f377f9c94 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -338,10 +338,13 @@ Optional constant settings (like lens focusing parameters on the sample: positio - + Contains the raw data collected by the detector before calibration. diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 9af0a12813..8123393169 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -272,9 +272,12 @@ NXmpes(NXobject): exists: recommended identifier: exists: recommended - data(NXdata): - # ToDo: With base class inheritance this should be - # a field of type NXdata_mpes_detector + raw_data(NXdata): + # ToDo: + # - With base class inheritance this should be + # a field of type NXdata_mpes_detector + # - The field name should be aligned with the `data` field in + # the `NXdetector` base class. But some refinement is necessary there. doc: | Contains the raw data collected by the detector before calibration. The data which is considered raw might change from experiment to experiment From 8f682e8bcb471dd33c8d11dec5adb19e7763e0f3 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 8 Jan 2024 14:12:01 +0100 Subject: [PATCH 0444/1012] rename actuation to physical_quantity --- contributed_definitions/NXactuator.nxdl.xml | 4 ++-- .../NXmanipulator.nxdl.xml | 6 +++--- contributed_definitions/NXmpes.nxdl.xml | 20 +++++++++---------- contributed_definitions/nyaml/NXactuator.yaml | 4 ++-- .../nyaml/NXmanipulator.yaml | 6 +++--- contributed_definitions/nyaml/NXmpes.yaml | 4 ++-- 6 files changed, 22 insertions(+), 22 deletions(-) diff --git a/contributed_definitions/NXactuator.nxdl.xml b/contributed_definitions/NXactuator.nxdl.xml index cc3043e4f2..0e8d0157bb 100644 --- a/contributed_definitions/NXactuator.nxdl.xml +++ b/contributed_definitions/NXactuator.nxdl.xml @@ -47,9 +47,9 @@ where actuator is attached to - + - name for quantity effected by actuation + Name for the physical quantity effected by actuation Examples: temperature | pH | magnetic_field | electric_field | current | conductivity | resistance | voltage | diff --git a/contributed_definitions/NXmanipulator.nxdl.xml b/contributed_definitions/NXmanipulator.nxdl.xml index 8e26aacd49..a0b1b3194c 100644 --- a/contributed_definitions/NXmanipulator.nxdl.xml +++ b/contributed_definitions/NXmanipulator.nxdl.xml @@ -45,7 +45,7 @@ Cryostat for cooling the sample. - + @@ -94,7 +94,7 @@ Device to heat the sample. - + @@ -142,7 +142,7 @@ Acutator applying a voltage to sample and sample holder. - + diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 038ed6297b..b8f83fe9eb 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -100,7 +100,7 @@ MPES spectrometer - This concept is related to term `12.58`_ of the ISO 18115-1:2023 standard. + This concept is related to term `12.58`_ of the ISO 18115-1:2023 standard. .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 @@ -108,11 +108,11 @@ Overall energy resolution of the MPES instrument - This concept is related to term `10.7 ff.`_ of the ISO 18115-1:2023 standard. + This concept is related to term `10.7 ff.`_ of the ISO 18115-1:2023 standard. .. _10.7 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 - This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. + This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 @@ -368,7 +368,7 @@ Optional constant settings (like lens focusing parameters on the sample: positio - + @@ -433,7 +433,7 @@ Optional constant settings (like lens focusing parameters on the sample: positio Device to bring low-energy electrons to the sample for charge neutralization - + @@ -505,7 +505,7 @@ Optional constant settings (like lens focusing parameters on the sample: positio Usually, the energy axis is adjusted by shifting all energies uniformally until one well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. - This concept is related to term `12.74 ff.`_ of the ISO 18115-1:2023 standard. + This concept is related to term `12.74 ff.`_ of the ISO 18115-1:2023 standard. .. _12.74 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 @@ -526,7 +526,7 @@ Optional constant settings (like lens focusing parameters on the sample: positio The binding energy (in units of eV) that the specified emission line appeared at, after adjusting the binding energy scale. - This concept is related to term `12.16_ ff.`_ of the ISO 18115-1:2023 standard. + This concept is related to term `12.16_ ff.`_ of the ISO 18115-1:2023 standard. .. _12.16_ ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 @@ -666,7 +666,7 @@ Optional constant settings (like lens focusing parameters on the sample: positio Bias of the sample with respect to analyser ground. - This concept is related to term `8.41`_ of the ISO 18115-1:2023 standard. + This concept is related to term `8.41`_ of the ISO 18115-1:2023 standard. .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 @@ -735,7 +735,7 @@ Optional constant settings (like lens focusing parameters on the sample: positio Calibrated kinetic energy axis. - This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. + This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 @@ -744,7 +744,7 @@ Optional constant settings (like lens focusing parameters on the sample: positio Calibrated binding energy axis. - This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. + This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 diff --git a/contributed_definitions/nyaml/NXactuator.yaml b/contributed_definitions/nyaml/NXactuator.yaml index 3008633d27..9a964b3102 100644 --- a/contributed_definitions/nyaml/NXactuator.yaml +++ b/contributed_definitions/nyaml/NXactuator.yaml @@ -17,9 +17,9 @@ NXactuator(NXobject): attached_to: doc: | where actuator is attached to - actuation: + physical_quantity: doc: | - name for quantity effected by actuation + Name for the physical quantity effected by actuation Examples: temperature | pH | magnetic_field | electric_field | current | conductivity | resistance | voltage | diff --git a/contributed_definitions/nyaml/NXmanipulator.yaml b/contributed_definitions/nyaml/NXmanipulator.yaml index 7aacb8debf..da09daa814 100644 --- a/contributed_definitions/nyaml/NXmanipulator.yaml +++ b/contributed_definitions/nyaml/NXmanipulator.yaml @@ -16,7 +16,7 @@ NXmanipulator(NXobject): cryostat(NXactuator): doc: | Cryostat for cooling the sample. - actuation: + physical_quantity: enumeration: [temperature] setpoint(NX_FLOAT): unit: NX_TEMPERATURE @@ -47,7 +47,7 @@ NXmanipulator(NXobject): unit: NX_TEMPERATURE sample_heater(NXactuator): doc: Device to heat the sample. - actuation: + physical_quantity: enumeration: [temperature] setpoint(NX_FLOAT): unit: NX_TEMPERATURE @@ -78,7 +78,7 @@ NXmanipulator(NXobject): sample_bias_potentiostat(NXactuator): doc: | Acutator applying a voltage to sample and sample holder. - actuation: + physical_quantity: enumeration: [voltage] setpoint(NX_FLOAT): unit: NX_VOLTAGE diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 3f47570d2f..d061206b5f 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -297,7 +297,7 @@ NXmpes(NXobject): exists: recommended name: exists: recommended - actuation: + physical_quantity: enumeration: [temperature] type: exists: optional @@ -358,7 +358,7 @@ NXmpes(NXobject): doc: Device to bring low-energy electrons to the sample for charge neutralization name: exists: recommended - actuation: + physical_quantity: enumeration: [current] type: exists: optional From fa17d60fba67432d70c4e022bb598ef226fc29f7 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 8 Jan 2024 14:32:37 +0100 Subject: [PATCH 0445/1012] add angular and spatial axis names --- contributed_definitions/NXmpes.nxdl.xml | 24 +++++++++++++++-------- contributed_definitions/nyaml/NXmpes.yaml | 8 ++++++++ 2 files changed, 24 insertions(+), 8 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 8f377f9c94..1784a994cb 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -100,7 +100,7 @@ MPES spectrometer - This concept is related to term `12.58`_ of the ISO 18115-1:2023 standard. + This concept is related to term `12.58`_ of the ISO 18115-1:2023 standard. .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 @@ -108,11 +108,11 @@ Overall energy resolution of the MPES instrument - This concept is related to term `10.7 ff.`_ of the ISO 18115-1:2023 standard. + This concept is related to term `10.7 ff.`_ of the ISO 18115-1:2023 standard. .. _10.7 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 - This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. + This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 @@ -395,7 +395,7 @@ ToDo: This field may also be found in NXsample if present. - This concept is related to term `8.41`_ of the ISO 18115-1:2023 standard. + This concept is related to term `8.41`_ of the ISO 18115-1:2023 standard. .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 @@ -457,7 +457,7 @@ ToDo: Usually, the energy axis is adjusted by shifting all energies uniformally until one well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. - This concept is related to term `12.74 ff.`_ of the ISO 18115-1:2023 standard. + This concept is related to term `12.74 ff.`_ of the ISO 18115-1:2023 standard. .. _12.74 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 @@ -478,7 +478,7 @@ ToDo: The binding energy (in units of eV) that the specified emission line appeared at, after adjusting the binding energy scale. - This concept is related to term `12.16_ ff.`_ of the ISO 18115-1:2023 standard. + This concept is related to term `12.16_ ff.`_ of the ISO 18115-1:2023 standard. .. _12.16_ ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 @@ -617,6 +617,14 @@ ToDo: - **kx**: Calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). - **ky**: Calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). - **kz**: Calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). + - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). + Unit category: NX_ANGLE + - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) + Unit category: NX_ANGLE + - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) + Unit category: NX_LENGTH + - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) + Unit category: NX_LENGTH - **delay**: Calibrated delay time. Unit category: NX_TIME (s). - **polarization_angle**: Linear polarization angle of the incoming or outgoing beam. This could be a link to @@ -658,7 +666,7 @@ ToDo: Calibrated kinetic energy axis. - This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. + This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 @@ -667,7 +675,7 @@ ToDo: Calibrated binding energy axis. - This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. + This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 8123393169..62df105b75 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -521,6 +521,14 @@ NXmpes(NXobject): - **kx**: Calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). - **ky**: Calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). - **kz**: Calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). + - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). + Unit category: NX_ANGLE + - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) + Unit category: NX_ANGLE + - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) + Unit category: NX_LENGTH + - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) + Unit category: NX_LENGTH - **delay**: Calibrated delay time. Unit category: NX_TIME (s). - **polarization_angle**: Linear polarization angle of the incoming or outgoing beam. This could be a link to From e2766328fd10e993deee824c552f774a264caf70 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 8 Jan 2024 14:37:02 +0100 Subject: [PATCH 0446/1012] removed unneeded axes in NXdetector --- contributed_definitions/NXmpes.nxdl.xml | 8 -------- contributed_definitions/nyaml/NXmpes.yaml | 8 -------- 2 files changed, 16 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 1784a994cb..fcbe30881d 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -358,16 +358,8 @@ ToDo: - **pixel_x**: Detector pixel in x direction. - **pixel_y**: Detector pixel in y direction. - - **raw_time_of_flight**: The raw time of flight in DAQ clock pulses. Unit category: NX_PULSES - **time_of_flight**: Total time of flight. Unit category: NX_TIME_OF_FLIGHT - **time_of_flight_adc**: Time-of-flight values, analog-to-digital converted. - - **polar_angle_manipulator**: Polar rotation angle of the manipulator. Unit category: NX_ANGLE - - **azimuthal_angle_manipulator**: Azimuthal rotation angle of the manipulator. Unit category: NX_ANGLE - - **delay_position**: Delay position of delay line detector. Unit category: NX_LENGTH - - **delay_position_ADC**: Delay position of delay line detector, analog-to-digital converted. - - **time_delay_x**: Time delay of delay line detector in x direction. Unit category: NX_TIME - - **time_delay_y**: Time delay of delay line detector in y direction. Unit category: NX_TIME - - **voltage**: Voltage applied to sample and sample holder. Unit category: NX_VOLTAGE - **external_AXIS**: Describes an axis which is coming from outside the detectors scope. diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 62df105b75..a67e8a999d 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -290,16 +290,8 @@ NXmpes(NXobject): - **pixel_x**: Detector pixel in x direction. - **pixel_y**: Detector pixel in y direction. - - **raw_time_of_flight**: The raw time of flight in DAQ clock pulses. Unit category: NX_PULSES - **time_of_flight**: Total time of flight. Unit category: NX_TIME_OF_FLIGHT - **time_of_flight_adc**: Time-of-flight values, analog-to-digital converted. - - **polar_angle_manipulator**: Polar rotation angle of the manipulator. Unit category: NX_ANGLE - - **azimuthal_angle_manipulator**: Azimuthal rotation angle of the manipulator. Unit category: NX_ANGLE - - **delay_position**: Delay position of delay line detector. Unit category: NX_LENGTH - - **delay_position_ADC**: Delay position of delay line detector, analog-to-digital converted. - - **time_delay_x**: Time delay of delay line detector in x direction. Unit category: NX_TIME - - **time_delay_y**: Time delay of delay line detector in y direction. Unit category: NX_TIME - - **voltage**: Voltage applied to sample and sample holder. Unit category: NX_VOLTAGE - **external_AXIS**: Describes an axis which is coming from outside the detectors scope. exists: recommended \@signal: From c0071e1a5e44884227f5e1cbc5b9a280a1094d42 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 8 Jan 2024 15:06:24 +0100 Subject: [PATCH 0447/1012] use new output and setpoints structure in NXactuator --- contributed_definitions/NXactuator.nxdl.xml | 25 +- .../NXmanipulator.nxdl.xml | 82 +++-- contributed_definitions/NXmpes.nxdl.xml | 19 +- contributed_definitions/NXpid.nxdl.xml | 15 +- contributed_definitions/nyaml/NXactuator.yaml | 21 +- .../nyaml/NXmanipulator.yaml | 293 ++++++++++++++---- contributed_definitions/nyaml/NXmpes.yaml | 24 +- contributed_definitions/nyaml/NXpid.yaml | 3 + 8 files changed, 345 insertions(+), 137 deletions(-) diff --git a/contributed_definitions/NXactuator.nxdl.xml b/contributed_definitions/NXactuator.nxdl.xml index 0e8d0157bb..3c98e78187 100644 --- a/contributed_definitions/NXactuator.nxdl.xml +++ b/contributed_definitions/NXactuator.nxdl.xml @@ -69,19 +69,15 @@ potentiostat - + - Nominal setpoint - - Can be a scalar or a vector (of [n] actuations). + Any output that the actuator produces. + For example, a heater can have the field heater_power(NX_FLOAT). - - - - + - Time history of actuator setpoints. + Time history of actuator outputs. @@ -89,6 +85,17 @@ If the actuator is PID-controlled, the settings of the PID controller can be stored here. + + + Nominal actuator setpoint. + Can be a scalar or a vector (of [n] actuations). + + + + + Time history of actuator setpoints. + + diff --git a/contributed_definitions/NXmanipulator.nxdl.xml b/contributed_definitions/NXmanipulator.nxdl.xml index a0b1b3194c..b76ff14250 100644 --- a/contributed_definitions/NXmanipulator.nxdl.xml +++ b/contributed_definitions/NXmanipulator.nxdl.xml @@ -50,19 +50,21 @@ - - - In case of a fixed or averaged cooling temperature, this is the scalar temperature setpoint. - It can also be a 1D array of temperature setpoints (without time stamps). - - - - + + - In the case of an experiment in which the temperature is changed and the setpoints are - recorded with time stamps, this is an array of length m of temperature setpoints. + In case of a fixed or averaged cooling temperature, this is the scalar temperature setpoint. + It can also be a 1D array of temperature setpoints (without time stamps). + + + + In the case of an experiment in which the temperature is changed and the setpoints are + recorded with time stamps, this is an array of length m of temperature setpoints. + + + @@ -82,7 +84,7 @@ - + In the case of an experiment in which the temperature changes and is recorded with time stamps, this is an array of length m of temperatures. @@ -99,19 +101,35 @@ - + - In case of a fixed or averaged temperature, this is the scalar temperature setpoint. - It can also be a 1D array of temperature setpoints (without time stamps). + In case of a fixed or averaged heating power, this is the scalar heater power. + It can also be a 1D array of heater powers (without time stamps). - - + + + + In the case of an experiment in which the heater power is changed and recorded with time stamps, + this is an array of length m of temperature setpoints. + + + + + - In the case of an experiment in which the temperature is changed and the setpoints are - recorded with time stamps, this is an array of length m of temperature setpoints. + In case of a fixed or averaged temperature, this is the scalar temperature setpoint. + It can also be a 1D array of temperature setpoints (without time stamps). + + + + In the case of an experiment in which the temperature is changed and the setpoints are + recorded with time stamps, this is an array of length m of temperature setpoints. + + + @@ -130,7 +148,7 @@ - + In the case of an experiment in which the current changes and is recorded with time stamps, this is an array of length m of currents. @@ -140,26 +158,28 @@ - Acutator applying a voltage to sample and sample holder. + Actuator applying a voltage to sample and sample holder. - - - In case of a fixed or averaged applied bias, this is the scalar voltage applied between - sample and sample holder. It can also be an 1D array of voltage setpoints (without time stamps). - - - - + + - In the case of an experiment in which the bias is changed and the setpoints are - recorded with time stamps, this is an array of length m of voltage setpoints. + In case of a fixed or averaged applied bias, this is the scalar voltage applied between + sample and sample holder. It can also be an 1D array of voltage setpoints (without time stamps). + + + + In the case of an experiment in which the bias is changed and the setpoints are + recorded with time stamps, this is an array of length m of voltage setpoints. + + + @@ -178,7 +198,7 @@ - + In the case of an experiment in which the bias changes and is recorded with time stamps, this is an array of length m of voltages. diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index b8f83fe9eb..7987f1354d 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -374,7 +374,10 @@ Optional constant settings (like lens focusing parameters on the sample: positio - + + + + @@ -428,7 +431,7 @@ Optional constant settings (like lens focusing parameters on the sample: positio - + Device to bring low-energy electrons to the sample for charge neutralization @@ -439,16 +442,16 @@ Optional constant settings (like lens focusing parameters on the sample: positio - + - In case of a fixed or averaged electron current, this is the scalar current setpoint. - It can also be an 1D array of measured current setpoints (without time stamps). + In case of a fixed or averaged electron current, this is the scalar current. + It can also be an 1D array of output current (without time stamps). - + - In the case of an experiment in which the gas pressure is changed and the setpoints are + In the case of an experiment in which the electron current is changed and recorded with time stamps, this is an array of length m of current setpoints. @@ -692,7 +695,7 @@ Optional constant settings (like lens focusing parameters on the sample: positio - Current of low-energy electrons to the sample for charge neutralization + Current of low-energy electrons to the sample for charge neutralization. diff --git a/contributed_definitions/NXpid.nxdl.xml b/contributed_definitions/NXpid.nxdl.xml index 2be21767ed..c93ce7597e 100644 --- a/contributed_definitions/NXpid.nxdl.xml +++ b/contributed_definitions/NXpid.nxdl.xml @@ -1,10 +1,10 @@ - + - + Contains the settings of a PID controller. @@ -53,6 +53,11 @@ It can also be a link to an NXsensor.value field. + + + Time log of the setpoint(s) used as an input for the PID controller. + + Proportional term. The proportional term produces an output value diff --git a/contributed_definitions/nyaml/NXactuator.yaml b/contributed_definitions/nyaml/NXactuator.yaml index 9a964b3102..20706d59a4 100644 --- a/contributed_definitions/nyaml/NXactuator.yaml +++ b/contributed_definitions/nyaml/NXactuator.yaml @@ -35,20 +35,25 @@ NXactuator(NXobject): anvil cell :Voltage: potentiostat - setpoint(NX_FLOAT): + OUTPUT(NX_FLOAT): unit: NX_ANY doc: | - Nominal setpoint - - Can be a scalar or a vector (of [n] actuations). - dimensions: - dim: [[1, n]] - setpoint_log(NXlog): + Any output that the actuator produces. + For example, a heater can have the field heater_power(NX_FLOAT). + OUTPUT_log(NXlog): doc: | - Time history of actuator setpoints. + Time history of actuator outputs. (NXpid): doc: | If the actuator is PID-controlled, the settings of the PID controller can be stored here. + setpoint(NX_FLOAT): + unit: NX_ANY + doc: | + Nominal actuator setpoint. + Can be a scalar or a vector (of [n] actuations). + setpoint_log(NXlog): + doc: | + Time history of actuator setpoints. depends_on(NX_CHAR): doc: | NeXus positions components by applying a set of translations and rotations diff --git a/contributed_definitions/nyaml/NXmanipulator.yaml b/contributed_definitions/nyaml/NXmanipulator.yaml index da09daa814..eea2d55b7e 100644 --- a/contributed_definitions/nyaml/NXmanipulator.yaml +++ b/contributed_definitions/nyaml/NXmanipulator.yaml @@ -18,19 +18,21 @@ NXmanipulator(NXobject): Cryostat for cooling the sample. physical_quantity: enumeration: [temperature] - setpoint(NX_FLOAT): - unit: NX_TEMPERATURE - doc: | - In case of a fixed or averaged cooling temperature, this is the scalar temperature setpoint. - It can also be a 1D array of temperature setpoints (without time stamps). - setpoint_log(NXlog): - value(NX_NUMBER): - doc: | - In the case of an experiment in which the temperature is changed and the setpoints are - recorded with time stamps, this is an array of length m of temperature setpoints. + (NXpid): + setpoint(NX_FLOAT): unit: NX_TEMPERATURE + doc: | + In case of a fixed or averaged cooling temperature, this is the scalar temperature setpoint. + It can also be a 1D array of temperature setpoints (without time stamps). + setpoint_log(NXlog): + value(NX_FLOAT): + unit: NX_TEMPERATURE + doc: | + In the case of an experiment in which the temperature is changed and the setpoints are + recorded with time stamps, this is an array of length m of temperature setpoints. temperature_sensor(NXsensor): - doc: Temperature sensor measuring the sample temperature. + doc: | + Temperature sensor measuring the sample temperature. measurement: enumeration: [temperature] value(NX_FLOAT): @@ -40,28 +42,42 @@ NXmanipulator(NXobject): by the sample temperature sensor. It can also be a 1D array of measured temperatures (without time stamps). value_log(NXlog): - value(NX_NUMBER): + value(NX_FLOAT): + unit: NX_TEMPERATURE doc: | In the case of an experiment in which the temperature changes and is recorded with time stamps, this is an array of length m of temperatures. - unit: NX_TEMPERATURE sample_heater(NXactuator): - doc: Device to heat the sample. + doc: | + Device to heat the sample. physical_quantity: enumeration: [temperature] - setpoint(NX_FLOAT): - unit: NX_TEMPERATURE + heater_power(NX_FLOAT): + unit: NX_POWER doc: | - In case of a fixed or averaged temperature, this is the scalar temperature setpoint. - It can also be a 1D array of temperature setpoints (without time stamps). - setpoint_log(NXlog): - value(NX_NUMBER): + In case of a fixed or averaged heating power, this is the scalar heater power. + It can also be a 1D array of heater powers (without time stamps). + heater_power_log(NXlog): + value(NX_FLOAT): + unit: NX_POWER doc: | - In the case of an experiment in which the temperature is changed and the setpoints are - recorded with time stamps, this is an array of length m of temperature setpoints. + In the case of an experiment in which the heater power is changed and recorded with time stamps, + this is an array of length m of temperature setpoints. + (NXpid): + setpoint(NX_FLOAT): unit: NX_TEMPERATURE + doc: | + In case of a fixed or averaged temperature, this is the scalar temperature setpoint. + It can also be a 1D array of temperature setpoints (without time stamps). + setpoint_log(NXlog): + value(NX_FLOAT): + unit: NX_TEMPERATURE + doc: | + In the case of an experiment in which the temperature is changed and the setpoints are + recorded with time stamps, this is an array of length m of temperature setpoints. drain_current_amperemeter(NXsensor): - doc: Amperemeter measuring the drain current of the sample and sample holder. + doc: | + Amperemeter measuring the drain current of the sample and sample holder. measurement: enumeration: [current] value(NX_FLOAT): @@ -70,27 +86,28 @@ NXmanipulator(NXobject): In case of a single or averaged drain current measurement, this is the scalar drain current measured between the sample and sample holder. It can also be an 1D array of measured currents (without time stamps). value_log(NXlog): - value(NX_NUMBER): + value(NX_FLOAT): + unit: NX_CURRENT doc: | In the case of an experiment in which the current changes and is recorded with time stamps, this is an array of length m of currents. - unit: NX_CURRENT sample_bias_potentiostat(NXactuator): doc: | - Acutator applying a voltage to sample and sample holder. + Actuator applying a voltage to sample and sample holder. physical_quantity: enumeration: [voltage] - setpoint(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - In case of a fixed or averaged applied bias, this is the scalar voltage applied between - sample and sample holder. It can also be an 1D array of voltage setpoints (without time stamps). - setpoints_log(NXlog): - value(NX_NUMBER): - doc: | - In the case of an experiment in which the bias is changed and the setpoints are - recorded with time stamps, this is an array of length m of voltage setpoints. + (NXpid): + setpoint(NX_FLOAT): unit: NX_VOLTAGE + doc: | + In case of a fixed or averaged applied bias, this is the scalar voltage applied between + sample and sample holder. It can also be an 1D array of voltage setpoints (without time stamps). + setpoint_log(NXlog): + value(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + In the case of an experiment in which the bias is changed and the setpoints are + recorded with time stamps, this is an array of length m of voltage setpoints. sample_bias_voltmeter(NXsensor): doc: | Sensor measuring the voltage applied to sample and sample holder. @@ -102,14 +119,15 @@ NXmanipulator(NXobject): In case of a single or averaged bias measurement, this is the scalar voltage measured between sample and sample holder. It can also be an 1D array of measured voltages (without time stamps). value_log(NXlog): - value(NX_NUMBER): + value(NX_FLOAT): + unit: NX_VOLTAGE doc: | In the case of an experiment in which the bias changes and is recorded with time stamps, this is an array of length m of voltages. - unit: NX_VOLTAGE (NXactuator): doc: | - Any additional actuator on the manipulator used to control an external condition. + Any additional actuator on the manipulator used to control an external + condition. (NXsensor): doc: | Any additional sensors on the manipulator used to monitor an external condition. @@ -133,14 +151,14 @@ NXmanipulator(NXobject): (NXfabrication): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 11c191146cd0a327bb603dc2607bfbf4ca12cb629b09821510dbaccc6dde01de -# +# 08d47f40a1d7fee3cd364f477c76cb02e60194cdcd1c00ff53d9b4e24d025ebd +# # # + + + A sensor used to monitor an external condition + + The condition itself is described in :ref:`NXenvironment`. + + + + Sensor identification code/model number + + + + + Name for the sensor + + + + + Short name of sensor used e.g. on monitor display program + + + + + where sensor is attached to ("sample" | "can") + + + + + Defines the axes for logged vector quantities if they are not the global + instrument axes. + + + + + name for measured signal + + + + + + + + + + + + + + + + + + + + The type of hardware used for the measurement. + Examples (suggestions but not restrictions): + + :Temperature: + J | K | T | E | R | S | Pt100 | Rh/Fe + :pH: + Hg/Hg2Cl2 | Ag/AgCl | ISFET + :Ion selective electrode: + specify species; e.g. Ca2+ + :Magnetic field: + Hall + :Surface pressure: + wilhelmy plate + + + + + Is data collection controlled or synchronised to this quantity: + 1=no, 0=to "value", 1=to "value_deriv1", etc. + + + + + Upper control bound of sensor reading if using run_control + + + + + Lower control bound of sensor reading if using run_control + + + + + nominal setpoint or average value + - need [n] as may be a vector + + + + + + + + Nominal/average first derivative of value + e.g. strain rate + - same dimensions as "value" (may be a vector) + + + + + + + + Nominal/average second derivative of value + - same dimensions as "value" (may be a vector) + + + + + + + + Time history of sensor readings + + + + + Time history of first derivative of sensor readings + + + + + Time history of second derivative of sensor readings + + + + + + + + + + + + + + + For complex external fields not satisfied by External_field_brief + + + + + This group describes the shape of the sensor when necessary. + + + + + + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + + + + + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a sensor. + + + + + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. + + + From 75482c4c857f3c432584a7548453ec09a4a48a37 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 8 Jan 2024 16:01:55 +0100 Subject: [PATCH 0456/1012] add angular and spatial acceptance to NXcollectioncolumn --- .../NXcollectioncolumn.nxdl.xml | 22 +++++++++++++++---- contributed_definitions/NXmpes.nxdl.xml | 2 ++ .../nyaml/NXcollectioncolumn.yaml | 13 +++++++++++ contributed_definitions/nyaml/NXmpes.yaml | 4 ++++ 4 files changed, 37 insertions(+), 4 deletions(-) diff --git a/contributed_definitions/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXcollectioncolumn.nxdl.xml index 862b270c95..1c46ad4907 100644 --- a/contributed_definitions/NXcollectioncolumn.nxdl.xml +++ b/contributed_definitions/NXcollectioncolumn.nxdl.xml @@ -1,10 +1,10 @@ - + - - - A sensor used to monitor an external condition - - The condition itself is described in :ref:`NXenvironment`. - - - - Sensor identification code/model number - - - - - Name for the sensor - - - - - Short name of sensor used e.g. on monitor display program - - - - - where sensor is attached to ("sample" | "can") - - - - - Defines the axes for logged vector quantities if they are not the global - instrument axes. - - - - - name for measured signal - - - - - - - - - - - - - - - - - - - - The type of hardware used for the measurement. - Examples (suggestions but not restrictions): - - :Temperature: - J | K | T | E | R | S | Pt100 | Rh/Fe - :pH: - Hg/Hg2Cl2 | Ag/AgCl | ISFET - :Ion selective electrode: - specify species; e.g. Ca2+ - :Magnetic field: - Hall - :Surface pressure: - wilhelmy plate - - - - - Is data collection controlled or synchronised to this quantity: - 1=no, 0=to "value", 1=to "value_deriv1", etc. - - - - - Upper control bound of sensor reading if using run_control - - - - - Lower control bound of sensor reading if using run_control - - - - - nominal setpoint or average value - - need [n] as may be a vector - - - - - - - - Nominal/average first derivative of value - e.g. strain rate - - same dimensions as "value" (may be a vector) - - - - - - - - Nominal/average second derivative of value - - same dimensions as "value" (may be a vector) - - - - - - - - Time history of sensor readings - - - - - Time history of first derivative of sensor readings - - - - - Time history of second derivative of sensor readings - - - - - - - - - - - - - - - For complex external fields not satisfied by External_field_brief - - - - - This group describes the shape of the sensor when necessary. - - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - - - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a sensor. - - - - - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - - - diff --git a/contributed_definitions/nyaml/NXsensor.yaml b/contributed_definitions/nyaml/NXsensor.yaml deleted file mode 100644 index a70f2a533e..0000000000 --- a/contributed_definitions/nyaml/NXsensor.yaml +++ /dev/null @@ -1,324 +0,0 @@ -category: base -doc: | - A sensor used to monitor an external condition - - The condition itself is described in :ref:`NXenvironment`. -type: group -NXsensor(NXobject): - model: - doc: | - Sensor identification code/model number - name: - doc: | - Name for the sensor - short_name: - doc: | - Short name of sensor used e.g. on monitor display program - attached_to: - doc: | - where sensor is attached to ("sample" | "can") - geometry(NXgeometry): - deprecated: | - Use the field `depends_on` and :ref:`NXtransformations` to position the beamstop and NXoff_geometry to describe its shape instead - doc: | - Defines the axes for logged vector quantities if they are not the global instrument axes. - measurement: - doc: | - name for measured signal - enumeration: [temperature, pH, magnetic_field, electric_field, conductivity, resistance, voltage, pressure, flow, stress, strain, shear, surface_pressure] - type: - doc: | - The type of hardware used for the measurement. - Examples (suggestions but not restrictions): - - :Temperature: - J | K | T | E | R | S | Pt100 | Rh/Fe - :pH: - Hg/Hg2Cl2 | Ag/AgCl | ISFET - :Ion selective electrode: - specify species; e.g. Ca2+ - :Magnetic field: - Hall - :Surface pressure: - wilhelmy plate - run_control(NX_BOOLEAN): - doc: | - Is data collection controlled or synchronised to this quantity: - 1=no, 0=to "value", 1=to "value_deriv1", etc. - high_trip_value(NX_FLOAT): - unit: NX_ANY - doc: | - Upper control bound of sensor reading if using run_control - low_trip_value(NX_FLOAT): - unit: NX_ANY - doc: | - Lower control bound of sensor reading if using run_control - value(NX_FLOAT): - unit: NX_ANY - doc: | - nominal setpoint or average value - - need [n] as may be a vector - dimensions: - dim: [[1, n]] - value_deriv1(NX_FLOAT): - unit: NX_ANY - doc: | - Nominal/average first derivative of value - e.g. strain rate - - same dimensions as "value" (may be a vector) - dimensions: - dim: [[1, ]] - dim_parameters: - ref: ['value'] - value_deriv2(NX_FLOAT): - unit: NX_ANY - doc: | - Nominal/average second derivative of value - - same dimensions as "value" (may be a vector) - dimensions: - dim: [[1, ]] - dim_parameters: - ref: ['value'] - value_log(NXlog): - doc: | - Time history of sensor readings - value_deriv1_log(NXlog): - doc: | - Time history of first derivative of sensor readings - value_deriv2_log(NXlog): - doc: | - Time history of second derivative of sensor readings - external_field_brief: - enumeration: [along beam, across beam, transverse, solenoidal, flow shear gradient, flow vorticity] - external_field_full(NXorientation): - doc: | - For complex external fields not satisfied by External_field_brief - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the sensor when necessary. - (NXfabrication): - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - .. todo:: - Add a definition for the reference point of a sensor. - (NXtransformations): - doc: | - 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. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# df8bc397cbcbf114091b84ed357f6312641ca9abbf2d51795c37802450e7e628 -# -# -# -# -# -# A sensor used to monitor an external condition -# -# The condition itself is described in :ref:`NXenvironment`. -# -# -# Sensor identification code/model number -# -# -# Name for the sensor -# -# -# Short name of sensor used e.g. on monitor display program -# -# -# where sensor is attached to ("sample" | "can") -# -# -# -# Defines the axes for logged vector quantities if they are not the global instrument axes. -# -# -# -# name for measured signal -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The type of hardware used for the measurement. -# Examples (suggestions but not restrictions): -# -# :Temperature: -# J | K | T | E | R | S | Pt100 | Rh/Fe -# :pH: -# Hg/Hg2Cl2 | Ag/AgCl | ISFET -# :Ion selective electrode: -# specify species; e.g. Ca2+ -# :Magnetic field: -# Hall -# :Surface pressure: -# wilhelmy plate -# -# -# -# -# Is data collection controlled or synchronised to this quantity: -# 1=no, 0=to "value", 1=to "value_deriv1", etc. -# -# -# -# -# Upper control bound of sensor reading if using run_control -# -# -# -# -# Lower control bound of sensor reading if using run_control -# -# -# -# -# nominal setpoint or average value -# - need [n] as may be a vector -# -# -# -# -# -# -# -# Nominal/average first derivative of value -# e.g. strain rate -# - same dimensions as "value" (may be a vector) -# -# -# -# -# -# -# -# Nominal/average second derivative of value -# - same dimensions as "value" (may be a vector) -# -# -# -# -# -# -# Time history of sensor readings -# -# -# Time history of first derivative of sensor readings -# -# -# Time history of second derivative of sensor readings -# -# -# -# -# -# -# -# -# -# -# -# -# For complex external fields not satisfied by External_field_brief -# -# -# -# This group describes the shape of the sensor when necessary. -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# .. todo:: -# Add a definition for the reference point of a sensor. -# -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -# -# From 3d5f54bd8bd5b6b7cca7af7e6be97fd3712bc609 Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 8 Jan 2024 16:11:50 +0100 Subject: [PATCH 0458/1012] Adds proper inputenc --- impatient-guide/conf.py | 4 +--- manual/source/conf.py | 7 +++++-- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/impatient-guide/conf.py b/impatient-guide/conf.py index 8b16e810c3..aa55e5813a 100644 --- a/impatient-guide/conf.py +++ b/impatient-guide/conf.py @@ -186,6 +186,7 @@ 'preamble': '''% \pagestyle{plain} \pagenumbering{arabic} + \usepackage[utf8]{inputenc} ''', } @@ -216,9 +217,6 @@ # If false, no module index is generated. latex_domain_indices = False -# Use xelatex to properly support unicode characters -latex_engine = "xelatex" - # -- Options for manual page output -------------------------------------------- diff --git a/manual/source/conf.py b/manual/source/conf.py index 00857a04e9..9dcd8a4189 100755 --- a/manual/source/conf.py +++ b/manual/source/conf.py @@ -6,8 +6,9 @@ # -- Path setup -------------------------------------------------------------- -import sys, os, datetime - +import datetime +import os +import sys # If extensions (or modules to document with autodoc) are in another directory, # add these directories to sys.path here. If the directory is relative to the @@ -158,7 +159,9 @@ def setup(app): 'maxlistdepth': 25, # some application definitions are deeply nested 'preamble': r''' \usepackage{amsbsy} + \usepackage[utf8]{inputenc} \listfiles \DeclareUnicodeCharacter{1F517}{X} \DeclareUnicodeCharacter{2906}{<=}''' } +} From 5ac19aa209b3a7f3d43b7e54824da92fb0814dd1 Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 8 Jan 2024 16:17:43 +0100 Subject: [PATCH 0459/1012] Fixes config.py bugs --- impatient-guide/conf.py | 2 +- manual/source/conf.py | 1 - 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/impatient-guide/conf.py b/impatient-guide/conf.py index aa55e5813a..6b8ee2e879 100644 --- a/impatient-guide/conf.py +++ b/impatient-guide/conf.py @@ -183,7 +183,7 @@ # FIXME: roman page numbers in TOC, and no page numbers later # http://osdir.com/ml/sphinx-dev/2011-03/msg00036.html # BUT, latex does not recognize these two lines when in the preamble -'preamble': '''% +'preamble': r'''% \pagestyle{plain} \pagenumbering{arabic} \usepackage[utf8]{inputenc} diff --git a/manual/source/conf.py b/manual/source/conf.py index 9dcd8a4189..7172dc78e6 100755 --- a/manual/source/conf.py +++ b/manual/source/conf.py @@ -164,4 +164,3 @@ def setup(app): \DeclareUnicodeCharacter{1F517}{X} \DeclareUnicodeCharacter{2906}{<=}''' } -} From 50b42958d6ab38cf2af40d7d8c9677deac46e97e Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 8 Jan 2024 16:26:17 +0100 Subject: [PATCH 0460/1012] Use xelatex for unicode support again --- .github/workflows/ci.yaml | 1 + impatient-guide/conf.py | 3 +-- manual/source/conf.py | 3 ++- 3 files changed, 4 insertions(+), 3 deletions(-) diff --git a/.github/workflows/ci.yaml b/.github/workflows/ci.yaml index 09bc967f55..f8ef92b46d 100755 --- a/.github/workflows/ci.yaml +++ b/.github/workflows/ci.yaml @@ -76,6 +76,7 @@ jobs: sudo apt-get update -y && \ sudo apt-get install -y \ latexmk \ + texlive-xetex \ texlive-latex-recommended \ texlive-latex-extra \ texlive-fonts-recommended diff --git a/impatient-guide/conf.py b/impatient-guide/conf.py index 6b8ee2e879..4511b26158 100644 --- a/impatient-guide/conf.py +++ b/impatient-guide/conf.py @@ -183,10 +183,9 @@ # FIXME: roman page numbers in TOC, and no page numbers later # http://osdir.com/ml/sphinx-dev/2011-03/msg00036.html # BUT, latex does not recognize these two lines when in the preamble -'preamble': r'''% +'preamble': '''% \pagestyle{plain} \pagenumbering{arabic} - \usepackage[utf8]{inputenc} ''', } diff --git a/manual/source/conf.py b/manual/source/conf.py index 7172dc78e6..186f8cae89 100755 --- a/manual/source/conf.py +++ b/manual/source/conf.py @@ -159,8 +159,9 @@ def setup(app): 'maxlistdepth': 25, # some application definitions are deeply nested 'preamble': r''' \usepackage{amsbsy} - \usepackage[utf8]{inputenc} \listfiles \DeclareUnicodeCharacter{1F517}{X} \DeclareUnicodeCharacter{2906}{<=}''' } + +latex_engine = 'xelatex' \ No newline at end of file From 15311873dedace545b6940eee44734b4aa285172 Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 8 Jan 2024 16:48:35 +0100 Subject: [PATCH 0461/1012] Add fonts to conf.py --- manual/source/conf.py | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/manual/source/conf.py b/manual/source/conf.py index 186f8cae89..6761b99e54 100755 --- a/manual/source/conf.py +++ b/manual/source/conf.py @@ -161,7 +161,27 @@ def setup(app): \usepackage{amsbsy} \listfiles \DeclareUnicodeCharacter{1F517}{X} - \DeclareUnicodeCharacter{2906}{<=}''' + \DeclareUnicodeCharacter{2906}{<=}''', + 'fontpkg': r''' + \setmainfont{FreeSerif}[ + UprightFont = *, + ItalicFont = *Italic, + BoldFont = *Bold, + BoldItalicFont = *BoldItalic + ] + \setsansfont{FreeSans}[ + UprightFont = *, + ItalicFont = *Oblique, + BoldFont = *Bold, + BoldItalicFont = *BoldOblique, + ] + \setmonofont{FreeMono}[ + UprightFont = *, + ItalicFont = *Oblique, + BoldFont = *Bold, + BoldItalicFont = *BoldOblique, + ] +''', } latex_engine = 'xelatex' \ No newline at end of file From bf1392270a3ea8bb3927b16954173d9e82d190a1 Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 8 Jan 2024 16:56:39 +0100 Subject: [PATCH 0462/1012] Declare delta as additional unicode character --- manual/source/conf.py | 25 ++----------------------- 1 file changed, 2 insertions(+), 23 deletions(-) diff --git a/manual/source/conf.py b/manual/source/conf.py index 6761b99e54..96b99b1245 100755 --- a/manual/source/conf.py +++ b/manual/source/conf.py @@ -161,27 +161,6 @@ def setup(app): \usepackage{amsbsy} \listfiles \DeclareUnicodeCharacter{1F517}{X} - \DeclareUnicodeCharacter{2906}{<=}''', - 'fontpkg': r''' - \setmainfont{FreeSerif}[ - UprightFont = *, - ItalicFont = *Italic, - BoldFont = *Bold, - BoldItalicFont = *BoldItalic - ] - \setsansfont{FreeSans}[ - UprightFont = *, - ItalicFont = *Oblique, - BoldFont = *Bold, - BoldItalicFont = *BoldOblique, - ] - \setmonofont{FreeMono}[ - UprightFont = *, - ItalicFont = *Oblique, - BoldFont = *Bold, - BoldItalicFont = *BoldOblique, - ] -''', + \DeclareUnicodeCharacter{2906}{<=} + \DeclareUnicodeCharacter{394}{$\Delta$}''' } - -latex_engine = 'xelatex' \ No newline at end of file From 128b36eb66f7cffb0a901a62e75b18b8a1c0f7a6 Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 8 Jan 2024 17:02:06 +0100 Subject: [PATCH 0463/1012] Also declare bold delta --- manual/source/conf.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/manual/source/conf.py b/manual/source/conf.py index 96b99b1245..f84671063f 100755 --- a/manual/source/conf.py +++ b/manual/source/conf.py @@ -162,5 +162,6 @@ def setup(app): \listfiles \DeclareUnicodeCharacter{1F517}{X} \DeclareUnicodeCharacter{2906}{<=} - \DeclareUnicodeCharacter{394}{$\Delta$}''' + \DeclareUnicodeCharacter{394}{$\Delta$} + \DeclareUnicodeCharacter{2206}{$\Delta$}''' } From b23a10c7b51c371b1085c2362e66091358d0b509 Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 8 Jan 2024 17:07:53 +0100 Subject: [PATCH 0464/1012] xetex removed from ci install --- .github/workflows/ci.yaml | 1 - 1 file changed, 1 deletion(-) diff --git a/.github/workflows/ci.yaml b/.github/workflows/ci.yaml index f8ef92b46d..09bc967f55 100755 --- a/.github/workflows/ci.yaml +++ b/.github/workflows/ci.yaml @@ -76,7 +76,6 @@ jobs: sudo apt-get update -y && \ sudo apt-get install -y \ latexmk \ - texlive-xetex \ texlive-latex-recommended \ texlive-latex-extra \ texlive-fonts-recommended From 84d3b948a70364817a50a9b2920d6f20f1b16a3d Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 9 Jan 2024 09:13:17 +0100 Subject: [PATCH 0465/1012] update MPES-related inherited NXdata classes --- contributed_definitions/NXdata_mpes.nxdl.xml | 60 ++++++-- .../NXdata_mpes_detector.nxdl.xml | 134 ++++++++++++----- contributed_definitions/NXmpes.nxdl.xml | 5 +- .../nyaml/NXdata_mpes.yaml | 54 +++++-- .../nyaml/NXdata_mpes_detector.yaml | 141 +++++++++++++----- contributed_definitions/nyaml/NXmpes.yaml | 3 +- 6 files changed, 290 insertions(+), 107 deletions(-) diff --git a/contributed_definitions/NXdata_mpes.nxdl.xml b/contributed_definitions/NXdata_mpes.nxdl.xml index f3db210781..b55869844c 100644 --- a/contributed_definitions/NXdata_mpes.nxdl.xml +++ b/contributed_definitions/NXdata_mpes.nxdl.xml @@ -46,7 +46,7 @@ Calibrated kinetic energy axis. - This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. + This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 @@ -55,7 +55,7 @@ Calibrated binding energy axis. - This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. + This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 @@ -63,39 +63,51 @@ - - Calibrated x axis in k-space. Units are 1/Angström. - - Calibrated y axis in k-space. Units are 1/Angström - - - Calibrated k axis in k-space. + Calibrated z axis in k-space. Units are 1/Angström. - - + + + Fast-axis angular coordinate (or second slow axis if angularly integrated). + + + + + Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in + 2 dimensions) + + + + + Fast-axis spatial coordinate (or second slow axis if spatially integrated) + + + + + Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in + 2 dimensions) + + Calibrated delay time. - - Linear polarization angle of the incoming or outgoing beam. @@ -104,8 +116,6 @@ /entry/instrument/beam/final_polarization_angle if they exist. - - Ellipticity of the incoming or outgoing beam. @@ -115,6 +125,26 @@ /entry/instrument/beam/final_ellipticity if they exist. + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXdata_mpes_detector.nxdl.xml b/contributed_definitions/NXdata_mpes_detector.nxdl.xml index 130683c223..0346d4a2ed 100644 --- a/contributed_definitions/NXdata_mpes_detector.nxdl.xml +++ b/contributed_definitions/NXdata_mpes_detector.nxdl.xml @@ -40,9 +40,6 @@ - Detector pixel in x direction. @@ -52,76 +49,141 @@ there is also x_pixel_offset in NXdetector base class Detector pixel in y direction. - - + - In DAQ clock pulses + (Un)calibrated energy axis. + + + The energy can be either stored as kinetic or as binding energy. + + + + + (Un)calibrated kinetic energy axis. + + This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. + + .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 + + + + + (Un)calibrated binding energy axis. + + This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. + + .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + + + + - - + - Total time of flight + (Un)calibrated x axis in k-space. + Units are 1/Angström. - + - Time-of-flight values, analog-to-digital converted. + (Un)calibrated y axis in k-space. + Units are 1/Angström - + - Polar rotation angle of the manipulator. + (Un)calibrated z axis in k-space. + Units are 1/Angström. - + - Azimuthal rotation angle of the manipulator. + Fast-axis angular coordinate (or second slow axis if angularly integrated). - + - Delay position of delay line detector. + Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in two + dimensions) - + - Delay position of delay line detector, analog-to-digital converted. + Fast-axis spatial coordinate (or second slow axis if spatially integrated) - + - Time delay of delay line detector. + Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in two + dimensions) - + + - Time delay of delay line detector. + Total time of flight - + - Measured detector voltage + Time-of-flight values, analog-to-digital converted. - + - Describes an axis which is coming from outside the detectors scope. - - Think of a detector just being triggered for readout by the rest of the experimental setup - - it would just know that it collected N images, which would flatten the external parameters to one axis, too. - This can then be linked, e.g. with NXcalibration, to the appropriate fields in the instrument and write it to the - top-level NXdata. + (Un)calibrated delay time. - + - missing + Linear polarization angle of the incoming or outgoing beam. - + - missing + Ellipticity of the incoming or outgoing beam. + + + Describes an axis which is coming from outside the detectors scope. + + Think of a detector just being triggered for readout by the rest of the experimental + setup - it would just know that it collected N images, which would flatten the external + parameters to one axis, too. + This can then be linked, e.g. with NXcalibration, to the appropriate fields in the instrument + and write it to the top-level NXdata. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 4e21a1a70d..d3d4e0a5be 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -338,14 +338,14 @@ Optional constant settings (like lens focusing parameters on the sample: positio - - + Contains the raw data collected by the detector before calibration. The data which is considered raw might change from experiment to experiment @@ -358,6 +358,7 @@ ToDo: - **pixel_x**: Detector pixel in x direction. - **pixel_y**: Detector pixel in y direction. + - **energy**: (Un)calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). - **kx**: (Un)calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). - **ky**: (Un)calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). - **kz**: (Un)calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). diff --git a/contributed_definitions/nyaml/NXdata_mpes.yaml b/contributed_definitions/nyaml/NXdata_mpes.yaml index 75ccb6284d..4c9b4887c3 100644 --- a/contributed_definitions/nyaml/NXdata_mpes.yaml +++ b/contributed_definitions/nyaml/NXdata_mpes.yaml @@ -38,39 +38,49 @@ NXdata_mpes(NXdata): spec: ISO 18115-1:2023 term: 12.16 url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - \@energy_indices: - \@energy_depends: kx(NX_NUMBER): exists: optional unit: NX_ANY doc: | Calibrated x axis in k-space. Units are 1/Angström. - \@kx_indices: - \@kx_depends: ky(NX_NUMBER): exists: optional unit: NX_ANY doc: | Calibrated y axis in k-space. Units are 1/Angström - \@ky_indices: - \@ky_depends: kz(NX_NUMBER): exists: optional unit: NX_ANY doc: | - Calibrated k axis in k-space. + Calibrated z axis in k-space. Units are 1/Angström. - \@kz_indices: - \@kz_depends: + angular0(NX_NUMBER): + exists: optional + unit: NX_ANGLE + doc: | + Fast-axis angular coordinate (or second slow axis if angularly integrated). + angular1(NX_NUMBER): + exists: optional + unit: NX_ANGLE + doc: | + Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) + spatial0(NX_NUMBER): + exists: optional + unit: NX_LENGTH + doc: | + Fast-axis spatial coordinate (or second slow axis if spatially integrated) + spatial1(NX_NUMBER): + exists: optional + unit: NX_LENGTH + doc: | + Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) delay(NX_NUMBER): exists: optional unit: NX_TIME doc: | Calibrated delay time. - \@delay_indices: - \@delay_depends: polarization_angle(NX_FLOAT): exists: optional unit: NX_ANGLE @@ -79,8 +89,6 @@ NXdata_mpes(NXdata): Could be a link to /entry/instrument/beam/incident_polarization_angle or /entry/instrument/beam/final_polarization_angle if they exist. - \@polarization_angle_indices: - \@polarization_angle_depends: ellipticity(NX_FLOAT): exists: optional unit: NX_ANGLE @@ -90,6 +98,26 @@ NXdata_mpes(NXdata): Can be any of linear polarization angle (degrees), ellipticity (arb. units). Could be a link to /entry/instrument/beam/incident_ellipticity or /entry/instrument/beam/final_ellipticity if they exist. + \@energy_indices: + \@energy_depends: + \@kx_indices: + \@kx_depends: + \@ky_indices: + \@ky_depends: + \@kz_indices: + \@kz_depends: + \@angular0_indices: + \@angular0_depends: + \@angular1_indices: + \@angular1_depends: + \@spatial0_indices: + \@spatial0_depends: + \@spatial1_indices: + \@spatial1_depends: + \@delay_indices: + \@delay_depends: + \@polarization_angle_indices: + \@polarization_angle_depends: \@ellipticity_indices: \@ellipticity_depends: diff --git a/contributed_definitions/nyaml/NXdata_mpes_detector.yaml b/contributed_definitions/nyaml/NXdata_mpes_detector.yaml index 9378d619ef..f3710ef335 100644 --- a/contributed_definitions/nyaml/NXdata_mpes_detector.yaml +++ b/contributed_definitions/nyaml/NXdata_mpes_detector.yaml @@ -15,8 +15,6 @@ NXdata_mpes_detector(NXdata): pixel_x(NX_FLOAT): exists: optional unit: NX_ANY - - # there is also x_pixel_offset in NXdetector base class doc: | Detector pixel in x direction. pixel_y(NX_FLOAT): @@ -24,73 +22,136 @@ NXdata_mpes_detector(NXdata): unit: NX_ANY doc: | Detector pixel in y direction. - - # exists in NXdetector base class - raw_time_of_flight(NX_INT): + energy(NX_NUMBER): + unit: NX_ENERGY + doc: (Un)calibrated energy axis. + \@type: + type: NX_CHAR + doc: | + The energy can be either stored as kinetic or as binding energy. + enumeration: + kinetic: + doc: + - | + (Un)calibrated kinetic energy axis. + - | + xref: + spec: ISO 18115-1:2023 + term: 3.35 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 + binding: + doc: + - | + (Un)calibrated binding energy axis. + - | + xref: + spec: ISO 18115-1:2023 + term: 12.16 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + kx(NX_NUMBER): exists: optional - unit: NX_PULSES + unit: NX_ANY doc: | - In DAQ clock pulses - - # exists in NXdetector base class - time_of_flight(NX_FLOAT): + (Un)calibrated x axis in k-space. + Units are 1/Angström. + ky(NX_NUMBER): exists: optional - unit: NX_TIME_OF_FLIGHT + unit: NX_ANY doc: | - Total time of flight - time_of_flight_adc(NX_FLOAT): + (Un)calibrated y axis in k-space. + Units are 1/Angström + kz(NX_NUMBER): exists: optional unit: NX_ANY doc: | - Time-of-flight values, analog-to-digital converted. - polar_angle_manipulator(NX_FLOAT): + (Un)calibrated z axis in k-space. + Units are 1/Angström. + angular0(NX_NUMBER): exists: optional unit: NX_ANGLE doc: | - Polar rotation angle of the manipulator. - azimuthal_angle_manipulator(NX_FLOAT): + Fast-axis angular coordinate (or second slow axis if angularly integrated). + angular1(NX_NUMBER): exists: optional unit: NX_ANGLE doc: | - Azimuthal rotation angle of the manipulator. - delay_position(NX_FLOAT): + Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in two + dimensions) + spatial0(NX_NUMBER): exists: optional unit: NX_LENGTH doc: | - Delay position of delay line detector. - delay_position_ADC(NX_FLOAT): + Fast-axis spatial coordinate (or second slow axis if spatially integrated) + spatial1(NX_NUMBER): + exists: optional + unit: NX_LENGTH + doc: | + Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in two + dimensions) + # exists in NXdetector base class + time_of_flight(NX_FLOAT): + exists: optional + unit: NX_TIME_OF_FLIGHT + doc: | + Total time of flight + time_of_flight_adc(NX_FLOAT): exists: optional unit: NX_ANY doc: | - Delay position of delay line detector, analog-to-digital converted. - time_delay_x(NX_FLOAT): + Time-of-flight values, analog-to-digital converted. + delay(NX_NUMBER): exists: optional unit: NX_TIME doc: | - Time delay of delay line detector. - time_delay_y(NX_FLOAT): + (Un)calibrated delay time. + polarization_angle(NX_FLOAT): exists: optional - unit: NX_TIME + unit: NX_ANGLE doc: | - Time delay of delay line detector. - voltage(NX_FLOAT): + Linear polarization angle of the incoming or outgoing beam. + ellipticity(NX_FLOAT): exists: optional - unit: NX_VOLTAGE + unit: NX_ANGLE doc: | - Measured detector voltage + Ellipticity of the incoming or outgoing beam. external_AXIS(NX_NUMBER): exists: optional unit: NX_ANY doc: | Describes an axis which is coming from outside the detectors scope. - Think of a detector just being triggered for readout by the rest of the experimental setup - - it would just know that it collected N images, which would flatten the external parameters to one axis, too. - This can then be linked, e.g. with NXcalibration, to the appropriate fields in the instrument and write it to the - top-level NXdata. - magnetization(NX_CHAR): - doc: | - missing - scattering_direction(NX_CHAR): - doc: | - missing + Think of a detector just being triggered for readout by the rest of the experimental + setup - it would just know that it collected N images, which would flatten the external + parameters to one axis, too. + This can then be linked, e.g. with NXcalibration, to the appropriate fields in the instrument + and write it to the top-level NXdata. + \@pixel_x_indices: + \@pixel_x_depends: + \@pixel_y_indices: + \@pixel_y_depends: + \@energy_indices: + \@energy_depends: + \@kx_indices: + \@kx_depends: + \@ky_indices: + \@ky_depends: + \@kz_indices: + \@kz_depends: + \@angular0_indices: + \@angular0_depends: + \@angular1_indices: + \@angular1_depends: + \@spatial0_indices: + \@spatial0_depends: + \@spatial1_indices: + \@spatial1_depends: + \@time_of_flight_indices: + \@time_of_flight_depends: + \@time_of_flight_adc_indices: + \@time_of_flight_adc_depends: + \@delay_indices: + \@delay_depends: + \@polarization_angle_indices: + \@polarization_angle_depends: + \@ellipticity_indices: + \@ellipticity_depends: \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index cc2a0f5c40..376a2ff8e5 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -278,6 +278,7 @@ NXmpes(NXobject): # a field of type NXdata_mpes_detector # - The field name should be aligned with the `data` field in # the `NXdetector` base class. But some refinement is necessary there. + exists: recommended doc: | Contains the raw data collected by the detector before calibration. The data which is considered raw might change from experiment to experiment @@ -290,6 +291,7 @@ NXmpes(NXobject): - **pixel_x**: Detector pixel in x direction. - **pixel_y**: Detector pixel in y direction. + - **energy**: (Un)calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). - **kx**: (Un)calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). - **ky**: (Un)calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). - **kz**: (Un)calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). @@ -310,7 +312,6 @@ NXmpes(NXobject): - **time_of_flight**: Total time of flight. Unit category: NX_TIME_OF_FLIGHT - **time_of_flight_adc**: Time-of-flight values, analog-to-digital converted. - **external_AXIS**: Describes an axis which is coming from outside the detectors scope. - exists: recommended \@signal: enumeration: [raw] raw(NX_NUMBER): From f7915550280a3a456e0504cce2e28dc8b56fbf9a Mon Sep 17 00:00:00 2001 From: domna Date: Tue, 9 Jan 2024 10:11:28 +0100 Subject: [PATCH 0466/1012] NXdata fixed --- base_classes/NXdata.nxdl.xml | 38 ++++++++++++++++++------------------ 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/base_classes/NXdata.nxdl.xml b/base_classes/NXdata.nxdl.xml index d1f82ee7c5..32cec1a570 100644 --- a/base_classes/NXdata.nxdl.xml +++ b/base_classes/NXdata.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays -# -# -# -# Number of data points in the transmission function. -# -# -# +# # # This is the most general application definition for multidimensional # photoelectron spectroscopy. @@ -144,17 +134,6 @@ NXmpes(NXphotoemission): # # # -# -# -# -# Datetime of the start of the measurement. -# -# -# -# -# Datetime of the end of the measurement. -# -# # # # A name of the experimental method according to `Clause 11`_ of @@ -167,644 +146,27 @@ NXmpes(NXphotoemission): # * angle-resolved photoelectron spectroscopy (ARPES) # * hard X-ray photoemission spectroscopy (HAXPES) # * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) -# * photoelectron emission microscopy (PEEM) # * electron spectroscopy for chemical analysis (ESCA) # # .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html # .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 # # -# -# -# Contact information of at least the user of the instrument or the investigator -# who performed this experiment. Adding multiple users if relevant is recommended. -# -# -# -# Name of the user. -# -# -# -# -# Name of the affiliation of the user at the point in time when the experiment was -# performed. -# -# -# # # # MPES spectrometer # -# Refers to Term `12.58`_ of the ISO 18115-1:2023 specification. +# This concept is related to term `12.58`_ of the ISO 18115-1:2023 standard. # # .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 # -# -# -# Overall energy resolution of the MPES instrument -# -# Refers to Terms `10.7`_ ff. and `10.24`_ of the ISO 18115-1:2023 specification. -# -# .. _10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 -# .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# 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. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Specification of type, may also go to name. -# -# -# -# -# -# Type of probe. In photoemission it's always photons, so the full NIAC list is -# restricted. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The beam emitted by this source. -# Should be named with the same appendix, e.g., -# for `source_probe` it should refer to `beam_probe`. -# Refers to the same concept as /NXentry/NXinstrument/beam_TYPE -# and may be linked. -# -# -# -# -# -# -# -# The beam emitted by this source. -# Should be named with the same appendix, e.g., -# for `source_probe` it should refer to `beam_probe`. -# Refers to the same concept as /NXentry/NXinstrument/source_TYPE -# and may be linked. -# -# -# -# -# -# -# -# -# The source that emitted this beam. -# Should be named with the same appendix, e.g., -# for `beam_probe` it should refer to `source_probe`. -# Refers to the same concept as /NXentry/NXinstrument/source_TYPE -# and may be linked. -# -# -# +# # -# -# -# -# -# -# -# -# -# Energy resolution of the analyser with the current setting. May be linked from a -# NXcalibration. -# -# Refers to Term `10.24`_ of the ISO 18115-1:2023 specification. -# -# .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 -# -# -# -# -# -# -# -# -# -# Scheme of the electron collection column. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Labelling of the lens setting in use. -# -# -# -# -# -# The size and position of the field aperture inserted in the column. To add -# additional or other apertures use the APERTURE group of NXcollectioncolumn. -# -# -# -# -# The size and position of the contrast aperture inserted in the column. To add -# additional or other apertures use the APERTURE group of NXcollectioncolumn. -# -# -# -# -# Size, position and shape of the iris inserted in the column. -# -# The iris is an aperture in the lens with a variable diameter which can reduce the number of -# electrons entering the analyzer. -# -# To add additional or other slits use the APERTURE group of NXcollectioncolumn. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Size, position and shape of the entrance slit in dispersive analyzers. -# -# To add additional or other slits use the APERTURE group of NXenergydispersion. -# -# -# -# -# Size, position and shape of the exit slit in dispersive analyzers. -# -# To add additional or other slits use the APERTURE group of NXenergydispersion. -# -# -# -# -# -# -# -# -# -# -# -# Type of electron amplifier in the first amplification step. -# -# -# -# -# -# -# -# -# Description of the detector type. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Raw data before calibration. -# -# -# -# -# -# Detector pixel in x direction. -# -# -# -# -# Detector pixel in y direction. -# -# -# -# -# -# In DAQ clock pulses -# -# -# -# -# -# Total time of flight -# -# -# -# -# Time-of-flight values, analog-to-digital converted. -# -# -# -# -# Polar rotation angle of the manipulator. -# -# -# -# -# Azimuthal rotation angle of the manipulator. -# -# -# -# -# Delay position of delay line detector. -# -# -# -# -# Delay position of delay line detector, analog-to-digital converted. -# -# -# -# -# Time delay of delay line detector. -# -# -# -# -# Time delay of delay line detector. -# -# -# -# -# Measured detector voltage -# -# -# -# -# Describes an axis which is coming from outside the detectors scope. -# -# Think of a detector just being triggered for readout by the rest of the experimental setup - -# it would just know that it collected N images, which would flatten the external parameters to one axis, too. -# This can then be linked, e.g. with NXcalibration, to the appropriate fields in the instrument and write it to the -# top-level NXdata. -# -# -# -# -# missing -# -# -# -# -# missing -# -# -# -# -# -# -# -# Manipulator for positioning of the sample. -# -# -# -# -# -# Bias of the sample with respect to analyser ground. -# -# This field may also be found in NXsample if present. -# -# Refers to Term `8.41`_ of the ISO 18115-1:2023 specification. -# -# .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 -# -# -# -# -# -# -# -# -# -# -# -# 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 -# -# -# -# Calibration event on the energy axis. -# -# For XPS, the calibration should ideally be performed according to -# `ISO 15472:2010`_ specification. -# -# .. _ISO 15472:2010: https://www.iso.org/standard/74811.html -# -# -# -# Has an energy calibration been applied? -# -# -# -# -# This is the calibrated energy axis to be used for data plotting. -# -# -# -# -# -# -# Has an angular calibration been applied? -# -# -# -# -# This is the calibrated angular axis to be used for data plotting. -# -# -# -# -# -# -# Has an spatial calibration been applied? -# -# -# -# -# This is the calibrated spatial axis to be used for data plotting. -# -# -# -# -# -# -# Has an momentum calibration been applied? -# -# -# -# -# This is the momentum axis to be used for data plotting. -# -# -# -# -# -# For energy referencing, the measured energies are corrected for the charging potential -# (i.e., the electrical potential of the surface region of an insulating sample, caused by -# irradiation) such that those energies correspond to a sample with no surface charge. -# Usually, the energy axis is adjusted by shifting all energies uniformally until one -# well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. -# -# Refers to Term `12.74`_ ff. of the ISO 18115-1:2023 specification. -# -# .. _12.74: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 -# -# -# -# Have the energy axes been adjusted (e.g., in cases where samples are not -# conductive)? -# -# -# -# -# Electronic core or valence level that was used for the calibration. -# -# -# -# -# Reference peak that was used for the calibration. -# -# For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge -# -# -# -# -# The binding energy (in units of eV) that the specified emission line appeared at, -# after adjusting the binding energy scale. -# -# Refers to Term `12.16`_ ff. of the ISO 18115-1:2023 specification. -# -# .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 -# -# -# -# -# Offset between measured binding energy and calibrated binding energy of the -# emission line. -# -# -# -# -# This is the calibrated energy axis to be used for data plotting. -# -# This should link to /entry/data/energy. -# -# -# -# -# -# In the transmission correction, each intensity measurement for electrons of a given -# kinetic energy is multiplied by the corresponding value in the relative_intensity -# field of the transmission_function. This calibration procedure is used to account for -# the different tranmsission efficiencies when using different lens modes. -# -# -# -# Has an intensity calibration been applied? -# -# That is, has the transmission function of the analyser been taken into account? -# -# -# -# -# Transmission function of the electron analyser. -# -# The transmission function (TF) specifies the detection efficiency for electrons of -# different kinetic energy passing through the electron analyser. -# This can be a link to /entry/instrument/electronanalyser/transmission_function. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Kinetic energy values -# -# -# -# -# -# -# -# Relative transmission efficiency for the given kinetic energies -# -# -# -# -# -# +# +# # # -# -# -# -# -# The chemical formula of the sample. For mixtures use the NXsample_component -# group in NXsample instead. -# -# -# -# -# A descriptor to keep track of the treatment of the sample before entering the -# photoemission experiment. Ideally, a full report of the previous operations, in -# any format (NXnote allows to add pictures, audio, movies). Alternatively, a -# reference to the location or a unique identifier or other metadata file. In the -# case these are not available, free-text description. -# -# -# -# -# List of comma-separated elements from the periodic table -# that are contained in the sample. -# If the sample substance has multiple components, all -# elements from each component must be included in `atom_types`. -# -# -# -# -# -# Date of preparation of the sample for the XPS experiment (i.e. cleaving, last -# annealing). -# -# -# -# -# Description of the surface preparation technique for the XPS experiment, i.e. -# UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report -# of the previous operations, in any format(NXnote allows to add pictures, audio, -# movies). Alternatively, a reference to the location or a unique identifier or -# other metadata file. In the case these are not available, free-text description. -# -# -# -# -# In the case of a fixed temperature measurement this is the scalar temperature of -# the sample. In the case of an experiment in which the temperature is changed and -# recoded, this is an array of length m of temperatures. This should be a link to -# /entry/instrument/manipulator/sample_temperature. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Voltage applied to sample and sample holder. -# -# -# # -# -# -# -# -# -# -# -# Represents a measure of one- or more-dimensional photoemission counts, where the -# varied axis may be for example energy, momentum, spatial coordinate, pump-probe -# delay, spin index, temperature, etc. The axes traces should be linked to the -# actual encoder position in NXinstrument or calibrated axes in NXprocess. -# -# -# # # # Calibrated energy axis. @@ -815,66 +177,41 @@ NXmpes(NXphotoemission): # # # -# The energy can be either stored as kinetic (Term `3.35`_ of the ISO 18115-1:2023 -# specification) or as binding (Term `12.16`_) energy. -# -# .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 -# .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 +# The energy can be either stored as kinetic or as binding energy. # # # # # Calibrated kinetic energy axis. +# +# This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. +# +# .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 +# +# +# +# +# Calibrated binding energy axis. +# +# This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. +# +# .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 # # # -# -# -# Calibrated binding energy axis. -# -# # # -# -# -# Calibrated x axis in k-space. -# Units are 1/Angström. -# -# -# -# -# Calibrated y axis in k-space. -# Units are 1/Angström -# -# -# +# +# # -# Calibrated k axis in k-space. -# Units are 1/Angström. -# -# -# -# -# Calibrated delay time. -# -# -# -# -# Linear polarization angle of the incoming or outgoing beam. +# The energy can be dispersed according to different strategies. ``energy_depends`` points to +# the path of a field defining the axis on which the energy axis depends. # -# Could be a link to /entry/instrument/beam/incident_polarization_angle or -# /entry/instrument/beam/final_polarization_angle if they exist. +# For example: +# @energy_depends: '/entry/instrument/detector/data/sensor_y' for a 2D detector +# @energy_depends: '/entry/instrument/energydispersion/center_energy' for a swept scan # -# -# -# -# Ellipticity of the incoming or outgoing beam. -# -# Can be any of linear polarization angle (degrees), ellipticity (arb. units). -# Could be a link to /entry/instrument/beam/incident_ellipticity or -# /entry/instrument/beam/final_ellipticity if they exist. -# -# +# # # # diff --git a/contributed_definitions/nyaml/NXphotoemission.yaml b/contributed_definitions/nyaml/NXphotoemission.yaml index 87aae815f6..d5dbe92f23 100644 --- a/contributed_definitions/nyaml/NXphotoemission.yaml +++ b/contributed_definitions/nyaml/NXphotoemission.yaml @@ -62,20 +62,20 @@ NXphotoemission(NXobject): Photoemission instrument energy_resolution(NXresolution): exists: optional - doc: - - | - Overall energy resolution of the instrument in case the energy of the electrons + doc: + - | + Overall energy resolution of the instrument in case the energy of the electrons is resolved. - - | + - | xref: spec: ISO 18115-1:2023 term: 10.7 ff. url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 - - | + - | xref: spec: ISO 18115-1:2023 term: 10.24 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 physical_quantity: enumeration: [energy] type: @@ -90,17 +90,17 @@ NXphotoemission(NXobject): exists: recommended identifier: exists: recommended + + # Comment from mpes may workshop: + # - There is much more information which can be provided for NXsource source_TYPE(NXsource): - - # Comment from mpes may workshop: - # - There is much more information which can be provided for NXsource exists: recommended doc: | A source used to generate a beam. Properties refer strictly to parameters of the source, not of the output beam. For example, the energy of the source is not the optical power of the beam, but the energy of the electron beam in a synchrotron and so on. - + Note that the uppercase notation in source_TYPE means that multiple sources can be provided. For example, in pump-probe experiments, it is possible to have both a `source_probe` and a `source_pump` @@ -193,7 +193,7 @@ NXphotoemission(NXobject): slow_axes: exists: recommended transmission_function(NX_FLOAT): - exists: optional + exists: optional (NXcollectioncolumn): scheme: doc: | @@ -280,12 +280,13 @@ NXphotoemission(NXobject): exists: recommended identifier: exists: recommended + + # ToDo: + # - With base class inheritance this should be + # a field of type NXdata_mpes_detector + # - The field name should be aligned with the `data` field in + # the `NXdetector` base class. But some refinement is necessary there. raw_data(NXdata): - # ToDo: - # - With base class inheritance this should be - # a field of type NXdata_mpes_detector - # - The field name should be aligned with the `data` field in - # the `NXdetector` base class. But some refinement is necessary there. exists: recommended doc: | Contains the raw data collected by the detector before calibration. @@ -293,10 +294,10 @@ NXphotoemission(NXobject): due to hardware pre-processing of the data. This field ideally collects the data with the lowest level of processing possible. - + The naming of fields should follow a convention to ensure compatibility. It is recommend to use the following field names: - + - **pixel_x**: Detector pixel in x direction. - **pixel_y**: Detector pixel in y direction. - **energy**: (Un)calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). @@ -339,11 +340,11 @@ NXphotoemission(NXobject): exists: recommended unit: NX_CURRENT doc: - - | + - | Bias of the sample with respect to analyser ground. - + - | This field may also be found in NXsample if present. - - | + - | xref: spec: ISO 18115-1:2023 term: 8.41 @@ -396,13 +397,13 @@ NXphotoemission(NXobject): energy_referencing(NXcalibration): exists: optional doc: - - | + - | For energy referencing, the measured energies are corrected for the charging potential (i.e., the electrical potential of the surface region of an insulating sample, caused by irradiation) such that those energies correspond to a sample with no surface charge. Usually, the energy axis is adjusted by shifting all energies uniformally until one well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. - - | + - | xref: spec: ISO 18115-1:2023 term: 12.74 ff. @@ -419,10 +420,10 @@ NXphotoemission(NXobject): binding_energy(NX_FLOAT): exists: recommended doc: - - | + - | The binding energy (in units of eV) that the specified emission line appeared at, - after adjusting the binding energy scale. - - | + after adjusting the binding energy scale. + - | xref: spec: ISO 18115-1:2023 term: 12.16_ ff. @@ -535,7 +536,7 @@ NXphotoemission(NXobject): The other data fields ideally should be named according to conventions to ensure compatibility. We recommened the following field names for common data fields: - + - **kx**: Calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). - **ky**: Calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). - **kz**: Calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). @@ -565,4 +566,674 @@ NXphotoemission(NXobject): 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. \ No newline at end of file + actual encoder position in NXinstrument or calibrated axes in NXprocess. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 62c3ef6b393b3fe7b8b4d63da98ea14085f2c995c0cccd81892a2a761adfd4a1 +# +# +# +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays +# +# +# +# Number of data points in the transmission function. +# +# +# +# +# This is the most general application definition for +# photoemission experiments. +# +# Groups and fields are named according to the +# `ISO 18115-1:2023`_ specification as well as the `IUPAC Recommendations 2020`_. +# +# .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html +# .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 +# +# +# +# +# +# +# +# +# +# +# +# Datetime of the start of the measurement. +# +# +# +# +# Datetime of the end of the measurement. +# +# +# +# +# A name of the experimental method according to `Clause 11`_ of +# the `ISO 18115-1:2023`_ specification. +# +# Examples include: +# * X-ray photoelectron spectroscopy (XPS) +# * angle-resolved X-ray photoelectron spectroscopy (ARXPS) +# * ultraviolet photoelectron spectroscopy (UPS) +# * angle-resolved photoelectron spectroscopy (ARPES) +# * hard X-ray photoemission spectroscopy (HAXPES) +# * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) +# * photoelectron emission microscopy (PEEM) +# * electron spectroscopy for chemical analysis (ESCA) +# +# .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html +# .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 +# +# +# +# +# Contact information of at least the user of the instrument or the investigator +# who performed this experiment. Adding multiple users if relevant is recommended. +# +# +# +# Name of the user. +# +# +# +# +# Name of the affiliation of the user at the point in time when the experiment was +# performed. +# +# +# +# +# +# Photoemission instrument +# +# +# +# Overall energy resolution of the instrument in case the energy of the electrons +# is resolved. +# +# This concept is related to term `10.7 ff.`_ of the ISO 18115-1:2023 standard. +# +# .. _10.7 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 +# +# This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. +# +# .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# A source used to generate a beam. Properties refer strictly to parameters of the +# source, not of the output beam. For example, the energy of the source is not the +# optical power of the beam, but the energy of the electron beam in a synchrotron +# and so on. +# +# Note that the uppercase notation in source_TYPE means that multiple sources can +# be provided. For example, in pump-probe experiments, it is possible to have both +# a `source_probe` and a `source_pump` +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Specification of type, may also go to name. +# +# +# +# +# +# +# +# +# +# +# +# The beam emitted by this source. +# Should be named with the same appendix, e.g., +# for `source_probe` it should refer to `beam_probe`. +# Refers to the same concept as /NXentry/NXinstrument/beam_TYPE +# and may be linked. +# +# +# +# +# +# +# Properties of the photon beam at a given location. +# Should be named with the same appendix as source_TYPE, e.g., +# for `source_probe` it should refer to `beam_probe`. +# +# +# +# Distance between the point where the current NXbeam instance is evaluating +# the beam properties and the point where the beam interacts with the sample. +# For photoemission, the latter is the point where the the centre of the beam +# touches the sample surface. +# +# +# +# +# +# +# +# +# The source that emitted this beam. +# Should be named with the same appendix, e.g., +# for `beam_probe` it should refer to `source_probe`. +# Refers to the same concept as /NXentry/NXinstrument/source_TYPE +# and may be linked. +# +# +# +# +# +# +# +# +# +# +# +# +# Energy resolution of the analyser with the current setting. May be linked from a +# NXcalibration. +# +# Refers to Term `10.24`_ of the ISO 18115-1:2023 specification. +# +# .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Scheme of the electron collection column. +# +# +# +# +# +# +# +# +# +# +# +# +# +# The size and position of the field aperture inserted in the column. To add +# additional or other apertures use the APERTURE group of NXcollectioncolumn. +# +# +# +# +# The size and position of the contrast aperture inserted in the column. To add +# additional or other apertures use the APERTURE group of NXcollectioncolumn. +# +# +# +# +# Size, position and shape of the iris inserted in the column. +# +# The iris is an aperture in the lens with a variable diameter which can reduce the number of +# electrons entering the analyzer. +# +# To add additional or other slits use the APERTURE group of NXcollectioncolumn. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Size, position and shape of the entrance slit in dispersive analyzers. +# +# To add additional or other slits use the APERTURE group of NXenergydispersion. +# +# +# +# +# Size, position and shape of the exit slit in dispersive analyzers. +# +# To add additional or other slits use the APERTURE group of NXenergydispersion. +# +# +# +# +# +# +# +# +# +# +# +# Type of electron amplifier in the first amplification step. +# +# +# +# +# +# +# +# +# Description of the detector type. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Contains the raw data collected by the detector before calibration. +# The data which is considered raw might change from experiment to experiment +# due to hardware pre-processing of the data. +# This field ideally collects the data with the lowest level of processing +# possible. +# +# The naming of fields should follow a convention to ensure compatibility. +# It is recommend to use the following field names: +# +# - **pixel_x**: Detector pixel in x direction. +# - **pixel_y**: Detector pixel in y direction. +# - **energy**: (Un)calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). +# - **kx**: (Un)calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). +# - **ky**: (Un)calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). +# - **kz**: (Un)calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). +# - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). +# Unit category: NX_ANGLE +# - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) +# Unit category: NX_ANGLE +# - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) +# Unit category: NX_LENGTH +# - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) +# Unit category: NX_LENGTH +# - **delay**: Calibrated delay time. Unit category: NX_TIME (s). +# - **polarization_angle**: Linear polarization angle of the incoming or +# outgoing beam. +# Unit category: NX_ANGLE (° or rad) +# - **ellipticity**: Ellipticity of the incoming or outgoing beam. +# Unit category: NX_ANGLE (° or rad) +# - **time_of_flight**: Total time of flight. Unit category: NX_TIME_OF_FLIGHT +# - **time_of_flight_adc**: Time-of-flight values, analog-to-digital converted. +# - **external_AXIS**: Describes an axis which is coming from outside the detectors scope. +# +# +# +# +# +# +# +# +# Raw data before calibration. +# +# +# +# +# +# +# +# Manipulator for positioning of the sample. +# +# +# +# +# +# Bias of the sample with respect to analyser ground. +# +# This field may also be found in NXsample if present. +# +# This concept is related to term `8.41`_ of the ISO 18115-1:2023 standard. +# +# .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 +# +# +# +# +# +# +# +# +# +# +# +# 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 +# +# +# +# Calibration event on the energy axis. +# +# For XPS, the calibration should ideally be performed according to +# `ISO 15472:2010`_ specification. +# +# .. _ISO 15472:2010: https://www.iso.org/standard/74811.html +# +# +# +# This is the calibrated energy axis to be used for data plotting. +# +# +# +# +# +# +# This is the calibrated angular axis to be used for data plotting. +# +# +# +# +# +# +# This is the calibrated spatial axis to be used for data plotting. +# +# +# +# +# +# +# This is the momentum axis to be used for data plotting. +# +# +# +# +# +# For energy referencing, the measured energies are corrected for the charging potential +# (i.e., the electrical potential of the surface region of an insulating sample, caused by +# irradiation) such that those energies correspond to a sample with no surface charge. +# Usually, the energy axis is adjusted by shifting all energies uniformally until one +# well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. +# +# This concept is related to term `12.74 ff.`_ of the ISO 18115-1:2023 standard. +# +# .. _12.74 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 +# +# +# +# Electronic core or valence level that was used for the calibration. +# +# +# +# +# Reference peak that was used for the calibration. +# +# For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge | vacuum level +# +# +# +# +# The binding energy (in units of eV) that the specified emission line appeared at, +# after adjusting the binding energy scale. +# +# This concept is related to term `12.16_ ff.`_ of the ISO 18115-1:2023 standard. +# +# .. _12.16_ ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 +# +# +# +# +# Offset between measured binding energy and calibrated binding energy of the +# emission line. +# +# +# +# +# This is the calibrated energy axis to be used for data plotting. +# +# This should link to /entry/data/energy. +# +# +# +# +# +# In the transmission correction, each intensity measurement for electrons of a given +# kinetic energy is multiplied by the corresponding value in the relative_intensity +# field of the transmission_function. This calibration procedure is used to account for +# the different tranmsission efficiencies when using different lens modes. +# +# +# +# Transmission function of the electron analyser. +# +# The transmission function (TF) specifies the detection efficiency for electrons of +# different kinetic energy passing through the electron analyser. +# This can be a link to /entry/instrument/electronanalyser/transmission_function. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Kinetic energy values +# +# +# +# +# +# +# +# Relative transmission efficiency for the given kinetic energies +# +# +# +# +# +# +# +# +# +# +# +# +# The chemical formula of the sample. For mixtures use the NXsample_component +# group in NXsample instead. +# +# +# +# +# A descriptor to keep track of the treatment of the sample before entering the +# photoemission experiment. Ideally, a full report of the previous operations, in +# any format (NXnote allows to add pictures, audio, movies). Alternatively, a +# reference to the location or a unique identifier or other metadata file. In the +# case these are not available, free-text description. +# +# +# +# +# List of comma-separated elements from the periodic table +# that are contained in the sample. +# If the sample substance has multiple components, all +# elements from each component must be included in `atom_types`. +# +# +# +# +# +# Date of preparation of the sample for the XPS experiment (i.e. cleaving, last +# annealing). +# +# +# +# +# Description of the surface preparation technique for the XPS experiment, i.e. +# UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report +# of the previous operations, in any format(NXnote allows to add pictures, audio, +# movies). Alternatively, a reference to the location or a unique identifier or +# other metadata file. In the case these are not available, free-text description. +# +# +# +# +# In the case of a fixed temperature measurement this is the scalar temperature of +# the sample. In the case of an experiment in which the temperature is changed and +# recoded, this is an array of length m of temperatures. This should be a link to +# /entry/instrument/manipulator/sample_temperature. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Voltage applied to sample and sample holder. +# +# +# +# +# +# An NXdata field containing a view on the measured data. +# This NXdata field contains a collection of the main relevant fields (axes). +# In NXmpes, it is required to provide an ``energy`` axis (Unit category: NX_ENERGY). +# The other data fields ideally should be named according to conventions +# to ensure compatibility. We recommened the following field names +# for common data fields: +# +# - **kx**: Calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). +# - **ky**: Calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). +# - **kz**: Calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). +# - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). +# Unit category: NX_ANGLE +# - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) +# Unit category: NX_ANGLE +# - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) +# Unit category: NX_LENGTH +# - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) +# Unit category: NX_LENGTH +# - **delay**: Calibrated delay time. Unit category: NX_TIME (s). +# - **polarization_angle**: Linear polarization angle of the incoming or +# outgoing beam. This could be a link to +# /entry/instrument/beam/incident_polarization_angle or +# /entry/instrument/beam/final_polarization_angle if they exist. +# Unit category: NX_ANGLE (° or rad) +# - **ellipticity**: Ellipticity of the incoming or outgoing beam. +# Could be a link to /entry/instrument/beam/incident_ellipticity or +# /entry/instrument/beam/final_ellipticity if they exist. +# Unit category: NX_ANGLE (° or rad) +# +# +# +# +# +# +# +# +# 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. +# +# +# +# +# From 2479ca172ae78e026f0cd2d3f8f858a5a1c8d6b4 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 10 Jan 2024 11:21:40 +0100 Subject: [PATCH 0471/1012] Fix tabs/spaces in NXdata+NXmpes docstrings --- base_classes/NXdata.nxdl.xml | 77 +++++++++++++------------ base_classes/nyaml/NXdata.yaml | 5 ++ contributed_definitions/NXmpes.nxdl.xml | 16 ++--- 3 files changed, 54 insertions(+), 44 deletions(-) diff --git a/base_classes/NXdata.nxdl.xml b/base_classes/NXdata.nxdl.xml index 32cec1a570..a7ae8b7239 100644 --- a/base_classes/NXdata.nxdl.xml +++ b/base_classes/NXdata.nxdl.xml @@ -87,12 +87,12 @@ without this attribute being set to "true".--> * 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 + 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. @@ -120,15 +120,15 @@ without this attribute being set to "true".--> 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] + @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 @@ -140,11 +140,11 @@ without this attribute being set to "true".--> written with any of these methods. * One method uses the ``axes`` - attribute to specify the names of each *dimension scale*. + 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. + *dimension scale* to identify + with an integer the axis whose value is the number of the dimension. .. index: !plot; axis label plot, axis units @@ -180,7 +180,7 @@ without this attribute being set to "true".--> Each auxiliary signal needs to be of the same shape as the default signal. .. NIAC2018: - https://www.nexusformat.org/NIAC2018Minutes.html + https://www.nexusformat.org/NIAC2018Minutes.html @@ -221,7 +221,7 @@ without this attribute being set to "true".--> of the plottable data, use a "." in that position. Such as:: - @axes=["time", ".", "."] + @axes=["time", ".", "."] Since there are three items in the list, the *signal* field must be a three-dimensional array (rank=3). The first dimension @@ -261,13 +261,13 @@ AXISNAME_indices documentation copied from datarules.rst An example with 2-D data, :math:`d(t,P)`, will illustrate:: data_2d:NXdata - @signal="data" - @axes=["time", "pressure"] - @time_indices=0 - @pressure_indices=1 - data: float[1000,20] - time: float[1000] - pressure: float[20] + @signal="data" + @axes=["time", "pressure"] + @time_indices=0 + @pressure_indices=1 + data: float[1000,20] + time: float[1000] + pressure: float[20] This attribute is to be provided in all situations. However, if the indices attributes are missing @@ -294,15 +294,20 @@ AXISNAME_indices documentation copied from datarules.rst field described in the ``axes`` attribute. Examples: - If a calibration has been performed, ``@AXISNAME_depends`` links to the result of - that calibration: - @AXISNAME_depends: '/entry/process/calibration/calibrated_axis' - If the axis corresponds to a coordinate of a detector, ``@AXISNAME_depends`` links - to that detector axis: - @AXISNAME_depends: '/entry/instrument/detector/axis/AXISNAME' for a 2D detector - If the axis is a scanned motor, ``@AXISNAME_depends`` links to the transformation - describing the respective motion, e.g.: - @AXISNAME_depends: '/entry/instrument/detector/transformations/AXISNAME' for a motion of the detector + If a calibration has been performed, ``@AXISNAME_depends`` links to the result of + that calibration: + + @AXISNAME_depends: '/entry/process/calibration/calibrated_axis' + + If the axis corresponds to a coordinate of a detector, ``@AXISNAME_depends`` links + to that detector axis: + + @AXISNAME_depends: '/entry/instrument/detector/axis/AXISNAME' for a 2D detector + + If the axis is a scanned motor, ``@AXISNAME_depends`` links to the transformation + describing the respective motion, e.g.: + + @AXISNAME_depends: '/entry/instrument/detector/transformations/AXISNAME' for a motion of the detector diff --git a/base_classes/nyaml/NXdata.yaml b/base_classes/nyaml/NXdata.yaml index 81774da799..07e338b836 100644 --- a/base_classes/nyaml/NXdata.yaml +++ b/base_classes/nyaml/NXdata.yaml @@ -250,12 +250,17 @@ NXdata(NXobject): Examples: If a calibration has been performed, ``@AXISNAME_depends`` links to the result of that calibration: + @AXISNAME_depends: '/entry/process/calibration/calibrated_axis' + If the axis corresponds to a coordinate of a detector, ``@AXISNAME_depends`` links to that detector axis: + @AXISNAME_depends: '/entry/instrument/detector/axis/AXISNAME' for a 2D detector + If the axis is a scanned motor, ``@AXISNAME_depends`` links to the transformation describing the respective motion, e.g.: + @AXISNAME_depends: '/entry/instrument/detector/transformations/AXISNAME' for a motion of the detector AXISNAME(NX_NUMBER): nameType: any diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index f1ecbb373d..06ccfb4d16 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -66,14 +66,14 @@ the `ISO 18115-1:2023`_ specification. Examples include: - * X-ray photoelectron spectroscopy (XPS) - * angle-resolved X-ray photoelectron spectroscopy (ARXPS) - * ultraviolet photoelectron spectroscopy (UPS) - * angle-resolved photoelectron spectroscopy (ARPES) - * hard X-ray photoemission spectroscopy (HAXPES) - * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) - * photoelectron emission microscopy (PEEM) - * electron spectroscopy for chemical analysis (ESCA) + * X-ray photoelectron spectroscopy (XPS) + * angle-resolved X-ray photoelectron spectroscopy (ARXPS) + * ultraviolet photoelectron spectroscopy (UPS) + * angle-resolved photoelectron spectroscopy (ARPES) + * hard X-ray photoemission spectroscopy (HAXPES) + * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) + * photoelectron emission microscopy (PEEM) + * electron spectroscopy for chemical analysis (ESCA) .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 From df82fbe16f7944b4af0b989f56c6480f88b8a7ef Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 10 Jan 2024 11:31:43 +0100 Subject: [PATCH 0472/1012] Explicitly name NXdata and extend docstring for generic NXdata group --- contributed_definitions/NXmpes.nxdl.xml | 8 +++++--- contributed_definitions/nyaml/NXmpes.yaml | 8 +++++--- 2 files changed, 10 insertions(+), 6 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 06ccfb4d16..1369ef278d 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -616,12 +616,14 @@ ToDo: - + - An NXdata field containing a view on the measured data. + The default NXdata field containing a view on the measured data. This NXdata field contains a collection of the main relevant fields (axes). In NXmpes, it is required to provide an energy axis. - The other data fields ideally should be named according to conventions + If you want to provide additional views on your data, you can additionally use + the generic NXdata group of NXentry. + The other data fields inside this NXdata group should be named according to conventions to ensure compatibility. We recommened the following field names for common data fields: diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index c694aba2ec..59f1ccde8b 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -527,12 +527,14 @@ NXmpes(NXobject): exists: optional doc: | Voltage applied to sample and sample holder. - (NXdata): + data(NXdata): doc: | - An NXdata field containing a view on the measured data. + The default NXdata field containing a view on the measured data. This NXdata field contains a collection of the main relevant fields (axes). In NXmpes, it is required to provide an energy axis. - The other data fields ideally should be named according to conventions + If you want to provide additional views on your data, you can additionally use + the generic NXdata group of NXentry. + The other data fields inside this NXdata group should be named according to conventions to ensure compatibility. We recommened the following field names for common data fields: From 750db36738053b2a8ae3e616f90754b7e2f608d1 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 10 Jan 2024 12:43:50 +0100 Subject: [PATCH 0473/1012] make nxdls --- contributed_definitions/nyaml/NXmpes.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index ba6c29ddf1..228580c725 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -328,7 +328,7 @@ NXmpes(NXobject): (NXmanipulator): exists: optional doc: | - Manipulator for positioning of the sample. + Manipulator for positioning of the sample. temperature_sensor(NXsensor): exists: recommended name: From d1c16ff5c105f1313d6ac96fc5d8e286a3c2d8dd Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 10 Jan 2024 12:47:59 +0100 Subject: [PATCH 0474/1012] make nyamls --- base_classes/nyaml/NXenvironment.yaml | 2 +- base_classes/nyaml/NXinstrument.yaml | 38 +- base_classes/nyaml/NXsensor.yaml | 24 +- contributed_definitions/nyaml/NXactuator.yaml | 134 +++- contributed_definitions/nyaml/NXmpes.yaml | 720 ++++++++++-------- contributed_definitions/nyaml/NXpid.yaml | 17 +- 6 files changed, 557 insertions(+), 378 deletions(-) diff --git a/base_classes/nyaml/NXenvironment.yaml b/base_classes/nyaml/NXenvironment.yaml index f92d786949..5838c46dc2 100644 --- a/base_classes/nyaml/NXenvironment.yaml +++ b/base_classes/nyaml/NXenvironment.yaml @@ -51,7 +51,7 @@ NXenvironment(NXobject): # +# +# +# An actuator used to control an external condition. +# +# The condition itself is described in :ref:`NXenvironment`. +# +# +# +# Actuator identification code/model number +# +# +# +# +# Name of the actuator +# +# +# +# +# Short name of actuator used e.g. on monitor display program +# +# +# +# +# where actuator is attached to +# +# +# +# +# Name for the physical quantity effected by actuation +# +# Examples: +# temperature | pH | magnetic_field | electric_field | current | conductivity | resistance | voltage | +# pressure | flow | stress | strain | shear | surface_pressure +# +# +# +# +# The type of hardware used for the actuation. +# +# Examples (suggestions but not restrictions): +# :Temperature: +# laser | gas lamp | filament | resistive +# :Pressure: +# anvil cell +# :Voltage: +# potentiostat +# +# +# +# +# Any output that the actuator produces. +# For example, a heater can have the field heater_power(NX_FLOAT). +# +# +# +# +# Time history of actuator outputs. +# +# +# +# +# If the actuator is PID-controlled, the settings of the PID controller can be +# stored here. +# +# +# +# Nominal actuator setpoint. +# Can be a scalar or a vector (of [n] actuations). +# +# +# +# +# Time history of actuator setpoints. +# +# +# +# +# +# NeXus positions components by applying a set of translations and rotations +# to apply to the component starting from 0, 0, 0. The order of these operations +# is critical and forms what NeXus calls a dependency chain. The depends_on +# field defines the path to the top most operation of the dependency chain or the +# string "." if located in the origin. Usually these operations are stored in a +# NXtransformations group. But NeXus allows them to be stored anywhere. +# +# .. todo:: +# Add a definition for the reference point of a actuator. +# +# +# +# +# This is the group recommended for holding the chain of translation +# and rotation operations necessary to position the component within +# the instrument. The dependency chain may however traverse similar groups in +# other component groups. +# +# +# +# diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 228580c725..0b33a9887f 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -58,10 +58,10 @@ NXmpes(NXobject): Name of the affiliation of the user at the point in time when the experiment was performed. (NXinstrument): - doc: - - | + doc: + - | MPES spectrometer - - | + - | xref: spec: ISO 18115-1:2023 term: 12.58 @@ -80,7 +80,7 @@ NXmpes(NXobject): xref: spec: ISO 18115-1:2023 term: 10.24 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 physical_quantity: enumeration: [energy] type: @@ -95,17 +95,17 @@ NXmpes(NXobject): exists: recommended identifier: exists: recommended + + # Comment from mpes may workshop: + # - There is much more information which can be provided for NXsource source_TYPE(NXsource): - - # Comment from mpes may workshop: - # - There is much more information which can be provided for NXsource exists: recommended doc: | A source used to generate a beam. Properties refer strictly to parameters of the source, not of the output beam. For example, the energy of the source is not the optical power of the beam, but the energy of the electron beam in a synchrotron and so on. - + Note that the uppercase notation in source_TYPE means that multiple sources can be provided. For example, in pump-probe experiments, it is possible to have both a `source_probe` and a `source_pump` @@ -280,12 +280,13 @@ NXmpes(NXobject): exists: recommended identifier: exists: recommended + + # ToDo: + # - With base class inheritance this should be + # a field of type NXdata_mpes_detector + # - The field name should be aligned with the `data` field in + # the `NXdetector` base class. But some refinement is necessary there. raw_data(NXdata): - # ToDo: - # - With base class inheritance this should be - # a field of type NXdata_mpes_detector - # - The field name should be aligned with the `data` field in - # the `NXdetector` base class. But some refinement is necessary there. exists: recommended doc: | Contains the raw data collected by the detector before calibration. @@ -293,10 +294,10 @@ NXmpes(NXobject): due to hardware pre-processing of the data. This field ideally collects the data with the lowest level of processing possible. - + The naming of fields should follow a convention to ensure compatibility. It is recommend to use the following field names: - + - **pixel_x**: Detector pixel in x direction. - **pixel_y**: Detector pixel in y direction. - **energy**: (Un)calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). @@ -405,7 +406,8 @@ NXmpes(NXobject): this is an array of length m of gas pressures. flood_gun(NXactuator): exists: optional - doc: Device to bring low-energy electrons to the sample for charge neutralization + doc: | + Device to bring low-energy electrons to the sample for charge neutralization name: exists: recommended physical_quantity: @@ -490,7 +492,7 @@ NXmpes(NXobject): doc: - | The binding energy (in units of eV) that the specified emission line appeared at, - after adjusting the binding energy scale. + after adjusting the binding energy scale. - | xref: spec: ISO 18115-1:2023 @@ -566,7 +568,8 @@ NXmpes(NXobject): (NXsample_history): exists: recommended doc: | - A set of activities that occurred to the sample prior to/during photoemission experiment. + A set of activities that occurred to the sample prior to/during photoemission + experiment. sample_preparation(NXphysical_process): exists: recommended doc: | @@ -599,22 +602,22 @@ NXmpes(NXobject): pressure_gauge(NXsensor): doc: | Gauge measuring the gas pressure. - + This should be a link to /entry/instrument/pressure_gauge. bias(NXenvironment): exists: recommended doc: - - | - Bias of the sample with respect to analyser ground. - - | - xref: - spec: ISO 18115-1:2023 - term: 8.41 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 + - | + Bias of the sample with respect to analyser ground. + - | + xref: + spec: ISO 18115-1:2023 + term: 8.41 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 voltmeter(NXsensor): doc: | Sensor setting/measuring the applied voltage. - + This should be a link to /entry/instrument/manipulator/sample_bias_voltmeter. drain_current(NXenvironment): exists: recommended @@ -623,7 +626,7 @@ NXmpes(NXobject): amperemeter(NXsensor): doc: | Amperemeter measuring the drain current of the sample and sample holder. - + This should be a link to /entry/instrument/manipulator/drain_current_amperemeter. flood_gun_current(NXenvironment): exists: optional @@ -632,7 +635,7 @@ NXmpes(NXobject): flood_gun(NXactuator): doc: | Flood gun creating a current of low-energy electrons. - + This should be a link to /entry/instrument/flood_gun. data(NXdata): doc: | @@ -644,7 +647,7 @@ NXmpes(NXobject): The other data fields inside this NXdata group should be named according to conventions to ensure compatibility. We recommened the following field names for common data fields: - + - **kx**: Calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). - **ky**: Calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). - **kz**: Calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). @@ -708,25 +711,26 @@ NXmpes(NXobject): url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 \@energy_indices: exists: recommended - \@energy_depends(NX_CHAR): + \@energy_depends: + type: NX_CHAR exists: recommended doc: | The energy can be dispersed according to different strategies. ``energy_depends`` points to the path of a field defining the axis on which the energy axis depends. - + For example: @energy_depends: '/entry/instrument/detector/data/sensor_y' for a 2D detector @energy_depends: '/entry/instrument/energydispersion/center_energy' for a swept scan - @energy_depends: '/entry/process/calibration/energy_calibration/calibrated_axis' for a preprocessed axis + # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 576bc8ae6b6e2395aca8c6297bf482fc68d82068637a9f9c895567547d4794f7 -# +# 4566993bd258d86f791dc68ac61dee2a6b239930a4b8a33a2cadb72851de29a7 +# # # +# +# # -# 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. +# A source used to generate a beam. Properties refer strictly to parameters of the +# source, not of the output beam. For example, the energy of the source is not the +# optical power of the beam, but the energy of the electron beam in a synchrotron +# and so on. +# +# Note that the uppercase notation in source_TYPE means that multiple sources can +# be provided. For example, in pump-probe experiments, it is possible to have both +# a `source_probe` and a `source_pump` # # # @@ -877,18 +892,7 @@ NXmpes(NXobject): # # # -# -# -# Type of probe. In photoemission it's always photons, so the full NIAC list is -# restricted. -# -# -# -# -# -# -# -# +# # # # @@ -908,13 +912,17 @@ NXmpes(NXobject): # we have a subdefinition NXlink to refer to a path. # This would also be helpful for NXtransformations--> # +# +# Properties of the photon beam at a given location. +# Should be named with the same appendix as source_TYPE, e.g., +# for `source_probe` it should refer to `beam_probe`. +# # # -# The beam emitted by this source. -# Should be named with the same appendix, e.g., -# for `source_probe` it should refer to `beam_probe`. -# Refers to the same concept as /NXentry/NXinstrument/source_TYPE -# and may be linked. +# Distance between the point where the current NXbeam instance is evaluating +# the beam properties and the point where the beam interacts with the sample. +# For photoemission, the latter is the point where the the centre of the beam +# touches the sample surface. # # # @@ -938,16 +946,15 @@ NXmpes(NXobject): # # # -# -# -# Energy resolution of the analyser with the current setting. May be linked from a -# NXcalibration. -# -# Refers to Term `10.24`_ of the ISO 18115-1:2023 specification. -# -# .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 -# -# +# +# +# +# +# +# +# +# +# # # # @@ -960,22 +967,15 @@ NXmpes(NXobject): # Scheme of the electron collection column. # # -# -# -# -# -# -# -# -# +# +# +# # # -# -# -# Labelling of the lens setting in use. -# -# +# # +# +# # # # The size and position of the field aperture inserted in the column. To add @@ -1065,7 +1065,48 @@ NXmpes(NXobject): # # # -# +# +# +# +# Contains the raw data collected by the detector before calibration. +# The data which is considered raw might change from experiment to experiment +# due to hardware pre-processing of the data. +# This field ideally collects the data with the lowest level of processing +# possible. +# +# The naming of fields should follow a convention to ensure compatibility. +# It is recommend to use the following field names: +# +# - **pixel_x**: Detector pixel in x direction. +# - **pixel_y**: Detector pixel in y direction. +# - **energy**: (Un)calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). +# - **kx**: (Un)calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). +# - **ky**: (Un)calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). +# - **kz**: (Un)calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). +# - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). +# Unit category: NX_ANGLE +# - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) +# Unit category: NX_ANGLE +# - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) +# Unit category: NX_LENGTH +# - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) +# Unit category: NX_LENGTH +# - **delay**: Calibrated delay time. Unit category: NX_TIME (s). +# - **polarization_angle**: Linear polarization angle of the incoming or +# outgoing beam. +# Unit category: NX_ANGLE (° or rad) +# - **ellipticity**: Ellipticity of the incoming or outgoing beam. +# Unit category: NX_ANGLE (° or rad) +# - **time_of_flight**: Total time of flight. Unit category: NX_TIME_OF_FLIGHT +# - **time_of_flight_adc**: Time-of-flight values, analog-to-digital converted. +# - **external_AXIS**: Describes an axis which is coming from outside the detectors scope. +# # # # @@ -1076,89 +1117,6 @@ NXmpes(NXobject): # Raw data before calibration. # # -# -# -# -# Detector pixel in x direction. -# -# -# -# -# Detector pixel in y direction. -# -# -# -# -# -# In DAQ clock pulses -# -# -# -# -# -# Total time of flight -# -# -# -# -# Time-of-flight values, analog-to-digital converted. -# -# -# -# -# Polar rotation angle of the manipulator. -# -# -# -# -# Azimuthal rotation angle of the manipulator. -# -# -# -# -# Delay position of delay line detector. -# -# -# -# -# Delay position of delay line detector, analog-to-digital converted. -# -# -# -# -# Time delay of delay line detector. -# -# -# -# -# Time delay of delay line detector. -# -# -# -# -# Measured detector voltage -# -# -# -# -# Describes an axis which is coming from outside the detectors scope. -# -# Think of a detector just being triggered for readout by the rest of the experimental setup - -# it would just know that it collected N images, which would flatten the external parameters to one axis, too. -# This can then be linked, e.g. with NXcalibration, to the appropriate fields in the instrument and write it to the -# top-level NXdata. -# -# -# -# -# missing -# -# -# -# -# missing -# -# # # # @@ -1166,23 +1124,105 @@ NXmpes(NXobject): # # Manipulator for positioning of the sample. # -# -# -# -# -# Bias of the sample with respect to analyser ground. -# -# This field may also be found in NXsample if present. -# -# Refers to Term `8.41`_ of the ISO 18115-1:2023 specification. -# -# .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 -# -# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# # # # -# +# +# +# +# +# +# Device to measure the gas pressure around the sample. +# +# +# +# +# +# +# +# +# +# +# In case of a single or averaged gas pressure measurement, this is the scalar gas pressure around +# the sample. It can also be an 1D array of measured pressures (without time stamps). +# +# +# +# +# +# In the case of an experiment in which the gas pressure changes and is recorded, +# this is an array of length m of gas pressures. +# +# +# +# +# +# +# Device to bring low-energy electrons to the sample for charge neutralization +# +# +# +# +# +# +# +# +# +# +# In case of a fixed or averaged electron current, this is the scalar current. +# It can also be an 1D array of output current (without time stamps). +# +# +# +# +# +# In the case of an experiment in which the electron current is changed and +# recorded with time stamps, this is an array of length m of current setpoints. +# +# # # # @@ -1201,11 +1241,6 @@ NXmpes(NXobject): # # .. _ISO 15472:2010: https://www.iso.org/standard/74811.html # -# -# -# Has an energy calibration been applied? -# -# # # # This is the calibrated energy axis to be used for data plotting. @@ -1213,11 +1248,6 @@ NXmpes(NXobject): # # # -# -# -# Has an angular calibration been applied? -# -# # # # This is the calibrated angular axis to be used for data plotting. @@ -1225,11 +1255,6 @@ NXmpes(NXobject): # # # -# -# -# Has an spatial calibration been applied? -# -# # # # This is the calibrated spatial axis to be used for data plotting. @@ -1237,11 +1262,6 @@ NXmpes(NXobject): # # # -# -# -# Has an momentum calibration been applied? -# -# # # # This is the momentum axis to be used for data plotting. @@ -1256,16 +1276,10 @@ NXmpes(NXobject): # Usually, the energy axis is adjusted by shifting all energies uniformally until one # well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. # -# Refers to Term `12.74`_ ff. of the ISO 18115-1:2023 specification. +# This concept is related to term `12.74 ff.`_ of the ISO 18115-1:2023 standard. # -# .. _12.74: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 +# .. _12.74 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 # -# -# -# Have the energy axes been adjusted (e.g., in cases where samples are not -# conductive)? -# -# # # # Electronic core or valence level that was used for the calibration. @@ -1275,7 +1289,7 @@ NXmpes(NXobject): # # Reference peak that was used for the calibration. # -# For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge +# For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge | vacuum level # # # @@ -1283,9 +1297,9 @@ NXmpes(NXobject): # The binding energy (in units of eV) that the specified emission line appeared at, # after adjusting the binding energy scale. # -# Refers to Term `12.16`_ ff. of the ISO 18115-1:2023 specification. +# This concept is related to term `12.16_ ff.`_ of the ISO 18115-1:2023 standard. # -# .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 +# .. _12.16_ ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 # # # @@ -1309,13 +1323,6 @@ NXmpes(NXobject): # field of the transmission_function. This calibration procedure is used to account for # the different tranmsission efficiencies when using different lens modes. # -# -# -# Has an intensity calibration been applied? -# -# That is, has the transmission function of the analyser been taken into account? -# -# # # # Transmission function of the electron analyser. @@ -1355,20 +1362,16 @@ NXmpes(NXobject): # # # -# -# -# The chemical formula of the sample. For mixtures use the NXsample_component -# group in NXsample instead. -# -# -# +# # -# A descriptor to keep track of the treatment of the sample before entering the -# photoemission experiment. Ideally, a full report of the previous operations, in -# any format (NXnote allows to add pictures, audio, movies). Alternatively, a -# reference to the location or a unique identifier or other metadata file. In the -# case these are not available, free-text description. +# For samples containing a single pure substances. For mixtures use the +# NXsample_component_set and NXsample_component group in NXsample instead. # +# +# +# The chemical formula of the sample (using CIF conventions). +# +# # # # @@ -1379,30 +1382,7 @@ NXmpes(NXobject): # # # -# -# -# Date of preparation of the sample for the XPS experiment (i.e. cleaving, last -# annealing). -# -# -# -# -# Description of the surface preparation technique for the XPS experiment, i.e. -# UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report -# of the previous operations, in any format(NXnote allows to add pictures, audio, -# movies). Alternatively, a reference to the location or a unique identifier or -# other metadata file. In the case these are not available, free-text description. -# -# -# -# -# In the case of a fixed temperature measurement this is the scalar temperature of -# the sample. In the case of an experiment in which the temperature is changed and -# recoded, this is an array of length m of temperatures. This should be a link to -# /entry/instrument/manipulator/sample_temperature. -# -# -# +# # # # @@ -1410,14 +1390,128 @@ NXmpes(NXobject): # # # -# -# +# # -# Voltage applied to sample and sample holder. +# A set of activities that occurred to the sample prior to/during photoemission +# experiment. # -# +# +# +# Details about the sample preparation for the MPES experiment (e.g. UHV cleaving, +# in-situ growth, sputtering/annealing, etc.). +# +# +# +# +# +# Details about the method of sample preparation before the MPES experiment. +# +# +# +# +# +# +# Sample temperature (either controlled or just measured). +# +# +# +# Temperature sensor measuring the sample temperature. +# This should be a link to /entry/instrument/manipulator/temperature_sensor. +# +# +# +# +# Device to heat the sample. +# This should be a link to /entry/instrument/manipulator/sample_heater. +# +# +# +# +# +# Gas pressure surrounding the sample. +# +# +# +# Gauge measuring the gas pressure. +# +# This should be a link to /entry/instrument/pressure_gauge. +# +# +# +# +# +# Bias of the sample with respect to analyser ground. +# +# This concept is related to term `8.41`_ of the ISO 18115-1:2023 standard. +# +# .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 +# +# +# +# Sensor setting/measuring the applied voltage. +# +# This should be a link to /entry/instrument/manipulator/sample_bias_voltmeter. +# +# +# +# +# +# Drain current of the sample and sample holder. +# +# +# +# Amperemeter measuring the drain current of the sample and sample holder. +# +# This should be a link to /entry/instrument/manipulator/drain_current_amperemeter. +# +# +# +# +# +# Current of low-energy electrons to the sample for charge neutralization. +# +# +# +# Flood gun creating a current of low-energy electrons. +# +# This should be a link to /entry/instrument/flood_gun. +# +# +# # -# +# +# +# The default NXdata field containing a view on the measured data. +# This NXdata field contains a collection of the main relevant fields (axes). +# In NXmpes, it is required to provide an energy axis. +# If you want to provide additional views on your data, you can additionally use +# the generic NXdata group of NXentry. +# The other data fields inside this NXdata group should be named according to conventions +# to ensure compatibility. We recommened the following field names +# for common data fields: +# +# - **kx**: Calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). +# - **ky**: Calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). +# - **kz**: Calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). +# - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). +# Unit category: NX_ANGLE +# - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) +# Unit category: NX_ANGLE +# - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) +# Unit category: NX_LENGTH +# - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) +# Unit category: NX_LENGTH +# - **delay**: Calibrated delay time. Unit category: NX_TIME (s). +# - **polarization_angle**: Linear polarization angle of the incoming or +# outgoing beam. This could be a link to +# /entry/instrument/beam/incident_polarization_angle or +# /entry/instrument/beam/final_polarization_angle if they exist. +# Unit category: NX_ANGLE (° or rad) +# - **ellipticity**: Ellipticity of the incoming or outgoing beam. +# Could be a link to /entry/instrument/beam/incident_ellipticity or +# /entry/instrument/beam/final_ellipticity if they exist. +# Unit category: NX_ANGLE (° or rad) +# # # # @@ -1431,7 +1525,6 @@ NXmpes(NXobject): # actual encoder position in NXinstrument or calibrated axes in NXprocess. # # -# # # # Calibrated energy axis. @@ -1442,66 +1535,41 @@ NXmpes(NXobject): # # # -# The energy can be either stored as kinetic (Term `3.35`_ of the ISO 18115-1:2023 -# specification) or as binding (Term `12.16`_) energy. -# -# .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 -# .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 +# The energy can be either stored as kinetic or as binding energy. # # # # # Calibrated kinetic energy axis. +# +# This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. +# +# .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 +# +# +# +# +# Calibrated binding energy axis. +# +# This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. +# +# .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 # # # -# -# -# Calibrated binding energy axis. -# -# # # -# +# +# # -# Calibrated x axis in k-space. -# Units are 1/Angström. -# -# -# -# -# Calibrated y axis in k-space. -# Units are 1/Angström -# -# -# -# -# Calibrated k axis in k-space. -# Units are 1/Angström. -# -# -# -# -# Calibrated delay time. -# -# -# -# -# Linear polarization angle of the incoming or outgoing beam. -# -# Could be a link to /entry/instrument/beam/incident_polarization_angle or -# /entry/instrument/beam/final_polarization_angle if they exist. -# -# -# -# -# Ellipticity of the incoming or outgoing beam. +# The energy can be dispersed according to different strategies. ``energy_depends`` points to +# the path of a field defining the axis on which the energy axis depends. # -# Can be any of linear polarization angle (degrees), ellipticity (arb. units). -# Could be a link to /entry/instrument/beam/incident_ellipticity or -# /entry/instrument/beam/final_ellipticity if they exist. +# For example: +# @energy_depends: '/entry/instrument/detector/data/sensor_y' for a 2D detector +# @energy_depends: '/entry/instrument/energydispersion/center_energy' for a swept scan # -# +# # # # diff --git a/contributed_definitions/nyaml/NXpid.yaml b/contributed_definitions/nyaml/NXpid.yaml index af27011f66..2804bf46a8 100644 --- a/contributed_definitions/nyaml/NXpid.yaml +++ b/contributed_definitions/nyaml/NXpid.yaml @@ -58,14 +58,14 @@ NXpid(NXobject): time constant are related as follows I = P/T. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4968f689bb36aeb5edc3b4ec8880134bb1d4fb6735709e32b482405c511409d5 -# +# aadcc7fe3aacdc2888a03ae22cc82dc7e65996a3dce2e0af4d6bd0a9fcfcecee +# # # -# +# # # Contains the settings of a PID controller. # @@ -114,6 +114,11 @@ NXpid(NXobject): # It can also be a link to an NXsensor.value field. # # +# +# +# Time log of the setpoint(s) used as an input for the PID controller. +# +# # # # Proportional term. The proportional term produces an output value From aa5c09ed8c47d31f80d2d961d8ec7852e8916998 Mon Sep 17 00:00:00 2001 From: domna Date: Wed, 10 Jan 2024 15:41:54 +0100 Subject: [PATCH 0475/1012] Regenerate nxdls --- base_classes/NXenvironment.nxdl.xml | 2 +- contributed_definitions/NXactuator.nxdl.xml | 10 +- .../NXelectron_level.nxdl.xml | 244 +++++++++--------- contributed_definitions/NXmpes.nxdl.xml | 14 +- contributed_definitions/nyaml/NXactuator.yaml | 10 +- 5 files changed, 136 insertions(+), 144 deletions(-) diff --git a/base_classes/NXenvironment.nxdl.xml b/base_classes/NXenvironment.nxdl.xml index 9c3e58071d..42017ad26c 100644 --- a/base_classes/NXenvironment.nxdl.xml +++ b/base_classes/NXenvironment.nxdl.xml @@ -3,7 +3,7 @@ + A source used to generate a beam. Properties refer strictly to parameters of the @@ -339,13 +337,11 @@ Optional constant settings (like lens focusing parameters on the sample: positio - +the `NXdetector` base class. But some refinement is necessary there.--> Contains the raw data collected by the detector before calibration. diff --git a/contributed_definitions/nyaml/NXactuator.yaml b/contributed_definitions/nyaml/NXactuator.yaml index 1a056b96e4..6426060306 100644 --- a/contributed_definitions/nyaml/NXactuator.yaml +++ b/contributed_definitions/nyaml/NXactuator.yaml @@ -29,12 +29,10 @@ NXactuator(NXobject): The type of hardware used for the actuation. Examples (suggestions but not restrictions): - :Temperature: - laser | gas lamp | filament | resistive - :Pressure: - anvil cell - :Voltage: - potentiostat + + :Temperature: laser | gas lamp | filament | resistive + :Pressure: anvil cell + :Voltage: potentiostat OUTPUT(NX_FLOAT): unit: NX_ANY doc: | From 5c7d197505c425cad1a097d5b783be4c29100e4d Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 10 Jan 2024 21:52:39 +0100 Subject: [PATCH 0476/1012] Added changes relevant to use the refactored NXapm parser of pynxtools 0572bfa9df6f513325024185ed1f1c1901d0758c --- contributed_definitions/NXaberration.nxdl.xml | 6 +- .../NXaberration_model.nxdl.xml | 6 +- .../NXaberration_model_ceos.nxdl.xml | 6 +- .../NXaberration_model_nion.nxdl.xml | 6 +- .../NXaperture_em.nxdl.xml | 6 +- contributed_definitions/NXapm.nxdl.xml | 231 +++++++++++++++--- .../NXapm_charge_state_analysis.nxdl.xml | 4 +- .../NXapm_hit_finding.nxdl.xml | 28 ++- contributed_definitions/NXapm_msr.nxdl.xml | 4 +- .../NXapm_paraprobe_ranger_config.nxdl.xml | 4 +- .../NXapm_paraprobe_ranger_results.nxdl.xml | 4 +- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 6 +- .../NXapm_paraprobe_tool_config.nxdl.xml | 4 +- .../NXapm_paraprobe_tool_results.nxdl.xml | 4 +- ...NXapm_paraprobe_transcoder_config.nxdl.xml | 4 +- ...Xapm_paraprobe_transcoder_results.nxdl.xml | 4 +- .../NXapm_ranging.nxdl.xml | 4 +- .../NXapm_reconstruction.nxdl.xml | 25 +- contributed_definitions/NXapm_sim.nxdl.xml | 4 +- .../NXapm_volt_and_bowl.nxdl.xml | 4 +- .../NXcalibration.nxdl.xml | 6 +- .../NXcg_alpha_complex.nxdl.xml | 6 +- .../NXcg_cylinder_set.nxdl.xml | 6 +- .../NXcg_ellipsoid_set.nxdl.xml | 6 +- .../NXcg_face_list_data_structure.nxdl.xml | 6 +- .../NXcg_geodesic_mesh.nxdl.xml | 6 +- contributed_definitions/NXcg_grid.nxdl.xml | 6 +- .../NXcg_half_edge_data_structure.nxdl.xml | 6 +- .../NXcg_hexahedron_set.nxdl.xml | 6 +- .../NXcg_marching_cubes.nxdl.xml | 4 +- .../NXcg_parallelogram_set.nxdl.xml | 6 +- .../NXcg_point_set.nxdl.xml | 6 +- .../NXcg_polygon_set.nxdl.xml | 6 +- .../NXcg_polyhedron_set.nxdl.xml | 6 +- .../NXcg_polyline_set.nxdl.xml | 6 +- .../NXcg_primitive_set.nxdl.xml | 6 +- contributed_definitions/NXcg_roi_set.nxdl.xml | 6 +- .../NXcg_sphere_set.nxdl.xml | 6 +- .../NXcg_tetrahedron_set.nxdl.xml | 6 +- .../NXcg_triangle_set.nxdl.xml | 6 +- .../NXcg_triangulated_surface_mesh.nxdl.xml | 6 +- .../NXcg_unit_normal_set.nxdl.xml | 6 +- contributed_definitions/NXchamber.nxdl.xml | 6 +- .../NXcomponent_em.nxdl.xml | 6 +- .../NXcoordinate_system.nxdl.xml | 6 +- .../NXcoordinate_system_set.nxdl.xml | 6 +- .../NXcorrector_cs.nxdl.xml | 6 +- .../NXcrystal_structure.nxdl.xml | 6 +- .../NXcs_computer.nxdl.xml | 6 +- contributed_definitions/NXcs_cpu_obj.nxdl.xml | 6 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 6 +- .../NXcs_filter_boolean_mask.nxdl.xml | 4 +- contributed_definitions/NXcs_gpu_obj.nxdl.xml | 6 +- contributed_definitions/NXcs_gpu_sys.nxdl.xml | 6 +- contributed_definitions/NXcs_io_obj.nxdl.xml | 6 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 6 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 6 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 6 +- contributed_definitions/NXcs_prng.nxdl.xml | 6 +- .../NXcs_profiling.nxdl.xml | 6 +- .../NXcs_profiling_event.nxdl.xml | 6 +- contributed_definitions/NXdeflector.nxdl.xml | 6 +- .../NXdelocalization.nxdl.xml | 4 +- .../NXebeam_column.nxdl.xml | 6 +- contributed_definitions/NXem.nxdl.xml | 6 +- contributed_definitions/NXem_adf.nxdl.xml | 6 +- contributed_definitions/NXem_base.nxdl.xml | 6 +- .../NXem_conventions.nxdl.xml | 6 +- .../NXem_conventions_ebsd.nxdl.xml | 6 +- .../NXem_correlation.nxdl.xml | 6 +- contributed_definitions/NXem_ebsd.nxdl.xml | 6 +- contributed_definitions/NXem_eds.nxdl.xml | 6 +- contributed_definitions/NXem_eels.nxdl.xml | 6 +- contributed_definitions/NXem_img.nxdl.xml | 6 +- contributed_definitions/NXem_method.nxdl.xml | 6 +- contributed_definitions/NXem_msr.nxdl.xml | 6 +- contributed_definitions/NXem_sim.nxdl.xml | 6 +- .../NXevent_data_apm.nxdl.xml | 28 ++- .../NXevent_data_apm_set.nxdl.xml | 4 +- .../NXevent_data_em.nxdl.xml | 6 +- .../NXevent_data_em_set.nxdl.xml | 6 +- .../NXfabrication.nxdl.xml | 6 +- .../NXgraph_edge_set.nxdl.xml | 6 +- .../NXgraph_node_set.nxdl.xml | 6 +- contributed_definitions/NXgraph_root.nxdl.xml | 6 +- .../NXibeam_column.nxdl.xml | 6 +- contributed_definitions/NXidentifier.nxdl.xml | 6 +- .../NXimage_c_set.nxdl.xml | 6 +- .../NXimage_r_set.nxdl.xml | 6 +- .../NXimage_r_set_diff.nxdl.xml | 6 +- contributed_definitions/NXimage_set.nxdl.xml | 6 +- .../NXinteraction_vol_em.nxdl.xml | 6 +- contributed_definitions/NXion.nxdl.xml | 4 +- contributed_definitions/NXisocontour.nxdl.xml | 4 +- contributed_definitions/NXlens_em.nxdl.xml | 6 +- .../NXmatch_filter.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 6 +- .../NXms_feature_set.nxdl.xml | 6 +- contributed_definitions/NXms_ipf.nxdl.xml | 6 +- contributed_definitions/NXms_ipf_set.nxdl.xml | 6 +- .../NXms_mtex_config.nxdl.xml | 6 +- contributed_definitions/NXms_odf.nxdl.xml | 6 +- contributed_definitions/NXms_odf_set.nxdl.xml | 6 +- contributed_definitions/NXms_pf.nxdl.xml | 6 +- contributed_definitions/NXms_pf_set.nxdl.xml | 6 +- contributed_definitions/NXms_recon.nxdl.xml | 6 +- .../NXms_score_results.nxdl.xml | 6 +- .../NXoptical_system_em.nxdl.xml | 6 +- contributed_definitions/NXpeak.nxdl.xml | 6 +- contributed_definitions/NXpulser_apm.nxdl.xml | 4 +- contributed_definitions/NXpump.nxdl.xml | 6 +- contributed_definitions/NXreflectron.nxdl.xml | 4 +- contributed_definitions/NXroi.nxdl.xml | 6 +- .../NXrotation_set.nxdl.xml | 6 +- contributed_definitions/NXscanbox_em.nxdl.xml | 6 +- contributed_definitions/NXserialized.nxdl.xml | 6 +- .../NXsimilarity_grouping.nxdl.xml | 4 +- .../NXspatial_filter.nxdl.xml | 4 +- .../NXspectrum_set.nxdl.xml | 6 +- contributed_definitions/NXstage_lab.nxdl.xml | 6 +- .../NXsubsampling_filter.nxdl.xml | 4 +- contributed_definitions/NXxrd.nxdl.xml | 6 +- contributed_definitions/NXxrd_pan.nxdl.xml | 6 +- contributed_definitions/nyaml/NXapm.yaml | 205 ++++++++++++++-- .../nyaml/NXapm_charge_state_analysis.yaml | 198 +++++++-------- .../nyaml/NXapm_hit_finding.yaml | 147 ++++++----- .../nyaml/NXapm_ranging.yaml | 150 ++++++------ .../nyaml/NXapm_reconstruction.yaml | 126 +++++----- .../nyaml/NXapm_volt_and_bowl.yaml | 70 +++--- .../nyaml/NXevent_data_apm.yaml | 19 +- contributed_definitions/nyaml/NXpeak.yaml | 2 +- 131 files changed, 1162 insertions(+), 735 deletions(-) diff --git a/contributed_definitions/NXaberration.nxdl.xml b/contributed_definitions/NXaberration.nxdl.xml index 008fc157aa..da4ea10dee 100644 --- a/contributed_definitions/NXaberration.nxdl.xml +++ b/contributed_definitions/NXaberration.nxdl.xml @@ -2,9 +2,9 @@ A collection of all programs and libraries which are considered relevant @@ -425,9 +425,23 @@ schema for heat treatment Report if the specimen is amorphous. + + + Ideally measured otherwise best elaborated guess of the initial radius of the + specimen. + + + + + Ideally measured otherwise best elaborated guess of the (initial) shank angle. + This is a measure of the specimen taper. Define it in such a way that the base of the specimen + is modelled as a conical frustrum so that the shank angle is the (shortest) angle between + the specimen space z-axis and a vector on the lateral surface of the cone. + + - - + + Set to hold different coordinate systems conventions. Inspect the description of the :ref:`NXcoordinate_system_set` @@ -487,13 +501,13 @@ schema for heat treatment - - + + - + @@ -509,7 +523,7 @@ schema for heat treatment - + @@ -521,7 +535,7 @@ schema for heat treatment - + @@ -530,7 +544,14 @@ schema for heat treatment - + + + + The space inside the atom probe along which ions pass nominally + when they leave the specimen and travel to the detector. + + + - + @@ -550,12 +571,18 @@ end_time(NX_DATE_TIME): delta_time(NX_NUMBER): pulse_identifier_offset(NX_INT): pulse_identifier(NX_INT):--> - - - - +local_electrode(NXlens_em): +ion_detector(NXdetector): +exists: optional +signal_amplitude(NX_FLOAT):--> - + + - + @@ -604,7 +632,7 @@ getter_pump(NXpump): roughening_pump(NXpump): turbomolecular_pump(NXpump):--> - + A region-of-interest analyzed either during or after the session for which specific processed data of the measured or simulated data are available. @@ -618,9 +646,55 @@ NEW ISSUE: add section for propagation_delay(NXprocess) ? NEW ISSUE: make recon an own subentry NXapm_reconstruction NEW ISSUE: different algorithms used one could create a class for each reconstruction method NEW ISSUE: make this rather an own subentry NXapm_ranging--> - + + + SEM or TEM image of the initial specimen i.e. + ideally taken prior to the data acquisition. + + + + + + + + + + + + + + + + + + + + + + - + + + + + + + + + + + + + + + + + @@ -635,7 +709,9 @@ NEW ISSUE: make this rather an own subentry NXapm_ranging--> - + + + @@ -652,7 +728,12 @@ NEW ISSUE: make this rather an own subentry NXapm_ranging--> - - + @@ -770,15 +851,43 @@ results--> - + + + For LEAP and IVAS/APSuite-based analyses root file which stores + the settings whereby an RHIT/HITS file can be used to regenerate the + reconstruction that is here referred to. + + The respective RHIT/HITS file should ideally be specified in the serialized + group of the hit_finding section of this application definition. + + + + + + + + + For LEAP and IVAS/APSuite-based analyses the resulting typically + file with the reconstructed positions and (calibrated) mass-to-charge + state ratio values. + + For other data collection/analysis software the data artifact which comes + closest conceptually to AMETEK/Cameca's typical file formats. + + These are typically exported as a POS, ePOS, APT, ATO, ENV, or HDF5 file, + which should be stored alongside this record in the research data + management system. + - - + + + + @@ -835,7 +944,16 @@ results--> - + + + The respective ranging definitions file RNG/RRNG/ENV/HDF5. + + + + + + + @@ -873,6 +991,23 @@ results--> + + + (Out-of-sync) background levels in ppm/ns + reported by e.g. IVAS/APSuite for LEAP systems. + + + + + MRP, mass-resolving power, `D. Larson et al. + <https://doi.org/10.1007/978-1-4614-8721-0>`_ (p282, Eqs. D.7 and D.8). + + + + + MRP, at which mrp_value was specified. + + - + + + + Category for the peak offering a qualitative statement of the location of the peak + in light of limited mass-resolving power that is relevant for + composition quantification. See `D. Larson et al. <https://doi.org/10.1007/978-1-4614-8721-0>`_ + for examples of each category: + + * 0, well-separated, 10^B +, 28^Si ++ + * 1, close, but typically sufficiently separated with LEAP system, 14^N +, 28^Si ++ + * 2, closely overlapping, demands better than LEAP4000X MRP, 14^N +, 28^Si ++ + * 3, overlapped, multi-charge state, 16^O 16^O ++, 16^O + + * 4, overlapped, same charge state, not discriminatable with a LEAP4000X, 14^N 14^N + 28^Si + + * 5, overlapped, same charge state, any expectation of resolvability, 54^Cr ++, 54^Fe ++ + + + + + + + + + + @@ -902,6 +1060,19 @@ in an e.g. work of A. London et al.--> + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml b/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml index b8d1bce9cd..3b61911514 100644 --- a/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml +++ b/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml @@ -2,9 +2,9 @@ + + + Different reconstruction protocols exist. Although these approaches + are qualitatively similar, each protocol uses different parameters + (and interprets these differently). The source code to IVAS/APSuite + is not open. For now users should store reconstruction parameter + in this free-text field to guide how to parameterize this better in the + future. For LEAP systems and reconstructions performed with IVAS/APSuite + see `T. Blum et al. <https://doi.org/10.1002/9781119227250.ch18>`_ (page 371). + + Qualitative statement about which reconstruction protocol was used. @@ -71,6 +82,16 @@ + + + + The nominal diameter of the specimen ROI which is measured in the + experiment. The physical specimen cannot be measured completely + because ions may launch but hit in locations other than the detector. + + Three-dimensional reconstructed positions of the ions. diff --git a/contributed_definitions/NXapm_sim.nxdl.xml b/contributed_definitions/NXapm_sim.nxdl.xml index 9c4a1d5d62..edc55a2a03 100644 --- a/contributed_definitions/NXapm_sim.nxdl.xml +++ b/contributed_definitions/NXapm_sim.nxdl.xml @@ -2,9 +2,9 @@ - + + + Set point temperature to achieve during the measurement. + + + - Average temperature at the specimen base, i.e. - base_temperature during the measurement. + Average temperature (at the specimen base) during the measurement. - + Average pressure in the analysis chamber during the measurement. diff --git a/contributed_definitions/NXevent_data_apm_set.nxdl.xml b/contributed_definitions/NXevent_data_apm_set.nxdl.xml index e4e89e920a..96670759b5 100644 --- a/contributed_definitions/NXevent_data_apm_set.nxdl.xml +++ b/contributed_definitions/NXevent_data_apm_set.nxdl.xml @@ -2,9 +2,9 @@ - + Total time of flight - + Time-of-flight values, analog-to-digital converted. - + (Un)calibrated delay time. - + Linear polarization angle of the incoming or outgoing beam. - + Ellipticity of the incoming or outgoing beam. - + Describes an axis which is coming from outside the detectors scope. diff --git a/contributed_definitions/nyaml/NXdata_mpes.yaml b/contributed_definitions/nyaml/NXdata_mpes.yaml index 4c9b4887c3..9659df2d6d 100644 --- a/contributed_definitions/nyaml/NXdata_mpes.yaml +++ b/contributed_definitions/nyaml/NXdata_mpes.yaml @@ -39,50 +39,41 @@ NXdata_mpes(NXdata): term: 12.16 url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 kx(NX_NUMBER): - exists: optional unit: NX_ANY doc: | Calibrated x axis in k-space. Units are 1/Angström. ky(NX_NUMBER): - exists: optional unit: NX_ANY doc: | Calibrated y axis in k-space. Units are 1/Angström kz(NX_NUMBER): - exists: optional unit: NX_ANY doc: | Calibrated z axis in k-space. Units are 1/Angström. angular0(NX_NUMBER): - exists: optional unit: NX_ANGLE doc: | Fast-axis angular coordinate (or second slow axis if angularly integrated). angular1(NX_NUMBER): - exists: optional unit: NX_ANGLE doc: | Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) spatial0(NX_NUMBER): - exists: optional unit: NX_LENGTH doc: | Fast-axis spatial coordinate (or second slow axis if spatially integrated) spatial1(NX_NUMBER): - exists: optional unit: NX_LENGTH doc: | Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) delay(NX_NUMBER): - exists: optional unit: NX_TIME doc: | Calibrated delay time. polarization_angle(NX_FLOAT): - exists: optional unit: NX_ANGLE doc: | Linear polarization angle of the incoming or outgoing beam. @@ -90,7 +81,6 @@ NXdata_mpes(NXdata): Could be a link to /entry/instrument/beam/incident_polarization_angle or /entry/instrument/beam/final_polarization_angle if they exist. ellipticity(NX_FLOAT): - exists: optional unit: NX_ANGLE doc: | Ellipticity of the incoming or outgoing beam. diff --git a/contributed_definitions/nyaml/NXdata_mpes_detector.yaml b/contributed_definitions/nyaml/NXdata_mpes_detector.yaml index f3710ef335..e048051b6f 100644 --- a/contributed_definitions/nyaml/NXdata_mpes_detector.yaml +++ b/contributed_definitions/nyaml/NXdata_mpes_detector.yaml @@ -13,12 +13,10 @@ NXdata_mpes_detector(NXdata): doc: | Raw data before calibration. pixel_x(NX_FLOAT): - exists: optional unit: NX_ANY doc: | Detector pixel in x direction. pixel_y(NX_FLOAT): - exists: optional unit: NX_ANY doc: | Detector pixel in y direction. @@ -49,73 +47,60 @@ NXdata_mpes_detector(NXdata): term: 12.16 url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 kx(NX_NUMBER): - exists: optional unit: NX_ANY doc: | (Un)calibrated x axis in k-space. Units are 1/Angström. ky(NX_NUMBER): - exists: optional unit: NX_ANY doc: | (Un)calibrated y axis in k-space. Units are 1/Angström kz(NX_NUMBER): - exists: optional unit: NX_ANY doc: | (Un)calibrated z axis in k-space. Units are 1/Angström. angular0(NX_NUMBER): - exists: optional unit: NX_ANGLE doc: | Fast-axis angular coordinate (or second slow axis if angularly integrated). angular1(NX_NUMBER): - exists: optional unit: NX_ANGLE doc: | Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in two dimensions) spatial0(NX_NUMBER): - exists: optional unit: NX_LENGTH doc: | Fast-axis spatial coordinate (or second slow axis if spatially integrated) spatial1(NX_NUMBER): - exists: optional unit: NX_LENGTH doc: | Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in two dimensions) # exists in NXdetector base class time_of_flight(NX_FLOAT): - exists: optional unit: NX_TIME_OF_FLIGHT doc: | Total time of flight time_of_flight_adc(NX_FLOAT): - exists: optional unit: NX_ANY doc: | Time-of-flight values, analog-to-digital converted. delay(NX_NUMBER): - exists: optional unit: NX_TIME doc: | (Un)calibrated delay time. polarization_angle(NX_FLOAT): - exists: optional unit: NX_ANGLE doc: | Linear polarization angle of the incoming or outgoing beam. ellipticity(NX_FLOAT): - exists: optional unit: NX_ANGLE doc: | Ellipticity of the incoming or outgoing beam. external_AXIS(NX_NUMBER): - exists: optional unit: NX_ANY doc: | Describes an axis which is coming from outside the detectors scope. From 8d4c1e23afa92e11d9812c3c8ab035a61527afdf Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 11 Jan 2024 15:24:17 +0100 Subject: [PATCH 0482/1012] typo and docstring fixes in base classes --- contributed_definitions/NXactuator.nxdl.xml | 17 +++++++++-------- contributed_definitions/NXresolution.nxdl.xml | 2 +- contributed_definitions/NXsubstance.nxdl.xml | 14 +++++++------- contributed_definitions/nyaml/NXactuator.yaml | 17 +++++++++-------- contributed_definitions/nyaml/NXresolution.yaml | 1 - 5 files changed, 26 insertions(+), 25 deletions(-) diff --git a/contributed_definitions/NXactuator.nxdl.xml b/contributed_definitions/NXactuator.nxdl.xml index ae3ee8479e..27e2b7da97 100644 --- a/contributed_definitions/NXactuator.nxdl.xml +++ b/contributed_definitions/NXactuator.nxdl.xml @@ -97,15 +97,16 @@ - 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. + Specifies the position of the actuator by pointing to the last + transformation in the transformation chain in the NXtransformations group. - .. todo:: - Add a definition for the reference point of a actuator. + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0 (in a given coordinate system). + 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. diff --git a/contributed_definitions/NXresolution.nxdl.xml b/contributed_definitions/NXresolution.nxdl.xml index 94a1db9c38..11085a8eea 100644 --- a/contributed_definitions/NXresolution.nxdl.xml +++ b/contributed_definitions/NXresolution.nxdl.xml @@ -25,7 +25,7 @@ Describes the resolution of a physical quantity. - + The physical quantity of the resolution, e.g., energy, momentum, time, etc. diff --git a/contributed_definitions/NXsubstance.nxdl.xml b/contributed_definitions/NXsubstance.nxdl.xml index 7379702133..6d246ca224 100644 --- a/contributed_definitions/NXsubstance.nxdl.xml +++ b/contributed_definitions/NXsubstance.nxdl.xml @@ -1,10 +1,10 @@ - + -# -# -# -# -# -# These symbols will be used below to coordinate fields with the same shape. -# rank of the ``DATA`` field -# length of the ``AXISNAME`` field -# length of the ``x`` field -# length of the ``y`` field -# length of the ``z`` field -# -# -# -# -# .. index:: plotting -# -# Array of strings holding the :ref:`names <validItemName>` of additional -# signals to be plotted with the default :ref:`signal </NXdata@signal-attribute>`. -# These fields or links *must* exist and be direct children of this NXdata group. -# -# Each auxiliary signal needs to be of the same shape as the default signal. -# -# .. NIAC2018: -# https://www.nexusformat.org/NIAC2018Minutes.html -# -# -# -# -# .. 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 <validItemName>` 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. -# -# -# -# -# .. index:: plotting -# -# Array of strings holding the :ref:`names <validItemName>` of -# the independent data fields used in the default plot for all of -# the dimensions of the :ref:`signal </NXdata@signal-attribute>` -# as well as any :ref:`auxiliary signals </NXdata@auxiliary_signals-attribute>`. -# -# 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. -# -# -# -# -# -# -# Each ``AXISNAME_indices`` attribute indicates the dependency -# relationship of the ``AXISNAME`` field (where ``AXISNAME`` -# is the name of a field that exists in this ``NXdata`` group) -# with one or more dimensions of the plottable data. -# -# Integer array that defines the indices of the *signal* field -# (that field will be a multidimensional array) -# which need to be used in the *AXISNAME* field in -# order to reference the corresponding axis value. -# -# The first index of an array is ``0`` (zero). -# -# Here, *AXISNAME* is to be replaced by the name of each -# field described in the ``axes`` attribute. -# An example with 2-D data, :math:`d(t,P)`, will illustrate:: -# -# data_2d:NXdata -# @signal="data" -# @axes=["time", "pressure"] -# @time_indices=0 -# @pressure_indices=1 -# data: float[1000,20] -# time: float[1000] -# pressure: float[20] -# -# This attribute is to be provided in all situations. -# However, if the indices attributes are missing -# (such as for data files written before this specification), -# file readers are encouraged to make their best efforts -# to plot the data. -# Thus the implementation of the -# ``AXISNAME_indices`` attribute is based on the model of -# "strict writer, liberal reader". -# -# .. note:: Attributes potentially containing multiple values -# (axes and _indices) are to be written as string or integer arrays, -# to avoid string parsing in reading applications. -# -# -# -# -# :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) -# -# -# -# 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. -# -# -# -# A *dimension scale* must have a rank of 1 and has length ``n``. -# -# -# -# Axis label -# -# -# ``0|false``: single value, -# ``1|true``: multiple values -# -# -# Index of first good value -# Index of last good value -# -# -# Index (positive integer) identifying this specific set of numbers. -# -# N.B. The ``axis`` attribute is the old way of designating a link. -# Do not use the ``axes`` attribute with the ``axis`` attribute. -# The ``axes`` *group* attribute is now preferred. -# -# -# -# -# -# "Errors" (meaning *uncertainties* or *standard deviations*) -# associated with any field named ``FIELDNAME`` in this ``NXdata`` -# group (e.g. an axis, signal or auxiliary signal). -# -# The dimensions of the ``FIELDNAME_errors`` field must match -# the dimensions of the ``FIELDNAME`` field. -# -# -# -# -# .. 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. -# -# -# -# The rank (``dataRank``) of the ``data`` must satisfy -# ``1 <= dataRank <= NX_MAXRANK=32``. -# At least one ``dim`` must have length ``n``. -# -# -# -# -# .. index:: plotting -# -# Plottable (independent) axis, indicate index number. -# Only one field in a :ref:`NXdata` group may have the -# ``signal=1`` attribute. -# Do not use the ``signal`` attribute with the ``axis`` attribute. -# -# -# -# -# Defines the names of the dimension scales -# (independent axes) for this data set -# as a colon-delimited array. -# NOTE: The ``axes`` attribute is the preferred -# method of designating a link. -# Do not use the ``axes`` attribute with the ``axis`` attribute. -# -# -# -# data label -# -# -# -# -# Standard deviations of data values - -# the data array is identified by the group attribute ``signal``. -# The ``errors`` array must have the same dimensions as ``DATA``. -# Client is responsible for defining the dimensions of the data. -# -# -# -# The ``errors`` must have -# the same rank (``dataRank``) -# as the ``data``. -# At least one ``dim`` must have length "n". -# -# -# -# -# -# The elements in data are usually float values really. For -# efficiency reasons these are usually stored as integers -# after scaling with a scale factor. This value is the scale -# factor. It is required to get the actual physical value, -# when necessary. -# -# -# -# -# An optional offset to apply to the values in data. -# -# -# -# -# Title for the plot. -# -# -# -# -# This is an array holding the values to use for the x-axis of -# data. The units must be appropriate for the measurement. -# -# -# -# -# -# -# -# This is an array holding the values to use for the y-axis of -# data. The units must be appropriate for the measurement. -# -# -# -# -# -# -# -# This is an array holding the values to use for the z-axis of -# data. The units must be appropriate for the measurement. -# -# -# -# -# +# +# +# +# +# These symbols will be used below to coordinate fields with the same +# shape. +# +# +# +# rank of the ``DATA`` field +# +# +# +# +# length of the ``AXISNAME`` field +# +# +# +# +# length of the ``x`` field +# +# +# +# +# length of the ``y`` field +# +# +# +# +# length of the ``z`` field +# +# +# +# +# :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) +# +# +# +# .. index:: plotting +# +# Array of strings holding the :ref:`names <validItemName>` of additional +# signals to be plotted with the default :ref:`signal </NXdata@signal-attribute>`. +# These fields or links *must* exist and be direct children of this NXdata group. +# +# Each auxiliary signal needs to be of the same shape as the default signal. +# +# .. NIAC2018: +# https://www.nexusformat.org/NIAC2018Minutes.html +# +# +# +# +# .. 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 <validItemName>` 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. +# +# +# +# +# .. index:: plotting +# +# Array of strings holding the :ref:`names <validItemName>` of +# the independent data fields used in the default plot for all of +# the dimensions of the :ref:`signal </NXdata@signal-attribute>` +# as well as any :ref:`auxiliary signals </NXdata@auxiliary_signals-attribute>`. +# +# 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. +# +# +# +# +# +# +# Each ``AXISNAME_indices`` attribute indicates the dependency +# relationship of the ``AXISNAME`` field (where ``AXISNAME`` +# is the name of a field that exists in this ``NXdata`` group) +# with one or more dimensions of the plottable data. +# +# Integer array that defines the indices of the *signal* field +# (that field will be a multidimensional array) +# which need to be used in the *AXISNAME* field in +# order to reference the corresponding axis value. +# +# The first index of an array is ``0`` (zero). +# +# Here, *AXISNAME* is to be replaced by the name of each +# field described in the ``axes`` attribute. +# An example with 2-D data, :math:`d(t,P)`, will illustrate:: +# +# data_2d:NXdata +# @signal="data" +# @axes=["time", "pressure"] +# @time_indices=0 +# @pressure_indices=1 +# data: float[1000,20] +# time: float[1000] +# pressure: float[20] +# +# This attribute is to be provided in all situations. +# However, if the indices attributes are missing +# (such as for data files written before this specification), +# file readers are encouraged to make their best efforts +# to plot the data. +# Thus the implementation of the +# ``AXISNAME_indices`` attribute is based on the model of +# "strict writer, liberal reader". +# +# .. note:: Attributes potentially containing multiple values +# (axes and _indices) are to be written as string or integer arrays, +# to avoid string parsing in reading applications. +# +# +# +# +# Points to the path of a field defining the axis on which the ``AXISNAME`` axis depends. +# +# This concept allows to link an axis to a respective field in the NeXus hierarchy, thereby +# defining the physical quantity it represents. +# +# Here, *AXISNAME* is to be replaced by the name of each +# field described in the ``axes`` attribute. +# +# Examples: +# If a calibration has been performed, ``@AXISNAME_depends`` links to the result of +# that calibration: +# +# @AXISNAME_depends: '/entry/process/calibration/calibrated_axis' +# +# If the axis corresponds to a coordinate of a detector, ``@AXISNAME_depends`` links +# to that detector axis: +# +# @AXISNAME_depends: '/entry/instrument/detector/axis/AXISNAME' for a 2D detector +# +# If the axis is a scanned motor, ``@AXISNAME_depends`` links to the transformation +# describing the respective motion, e.g.: +# +# @AXISNAME_depends: '/entry/instrument/detector/transformations/AXISNAME' for a motion of the detector +# +# +# +# +# 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. +# +# +# +# A *dimension scale* must have a rank of 1 and has length ``n``. +# +# +# +# +# +# Axis label +# +# +# +# +# ``0|false``: single value, +# ``1|true``: multiple values +# +# +# +# +# Index of first good value +# +# +# +# +# Index of last good value +# +# +# +# +# Index (positive integer) identifying this specific set of numbers. +# +# N.B. The ``axis`` attribute is the old way of designating a link. +# Do not use the ``axes`` attribute with the ``axis`` attribute. +# The ``axes`` *group* attribute is now preferred. +# +# +# +# +# +# "Errors" (meaning *uncertainties* or *standard deviations*) +# associated with any field named ``FIELDNAME`` in this ``NXdata`` +# group (e.g. an axis, signal or auxiliary signal). +# +# The dimensions of the ``FIELDNAME_errors`` field must match +# the dimensions of the ``FIELDNAME`` field. +# +# +# +# +# .. 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. +# +# +# +# The rank (``dataRank``) of the ``data`` must satisfy +# ``1 <= dataRank <= NX_MAXRANK=32``. +# At least one ``dim`` must have length ``n``. +# +# +# +# +# .. index:: plotting +# +# Plottable (independent) axis, indicate index number. +# Only one field in a :ref:`NXdata` group may have the +# ``signal=1`` attribute. +# Do not use the ``signal`` attribute with the ``axis`` attribute. +# +# +# +# +# Defines the names of the dimension scales +# (independent axes) for this data set +# as a colon-delimited array. +# NOTE: The ``axes`` attribute is the preferred +# method of designating a link. +# Do not use the ``axes`` attribute with the ``axis`` attribute. +# +# +# +# +# data label +# +# +# +# +# +# Standard deviations of data values - +# the data array is identified by the group attribute ``signal``. +# The ``errors`` array must have the same dimensions as ``DATA``. +# Client is responsible for defining the dimensions of the data. +# +# +# +# The ``errors`` must have +# the same rank (``dataRank``) +# as the ``data``. +# At least one ``dim`` must have length "n". +# +# +# +# +# +# The elements in data are usually float values really. For +# efficiency reasons these are usually stored as integers +# after scaling with a scale factor. This value is the scale +# factor. It is required to get the actual physical value, +# when necessary. +# +# +# +# +# An optional offset to apply to the values in data. +# +# +# +# +# Title for the plot. +# +# +# +# +# This is an array holding the values to use for the x-axis of +# data. The units must be appropriate for the measurement. +# +# +# +# +# +# +# +# This is an array holding the values to use for the y-axis of +# data. The units must be appropriate for the measurement. +# +# +# +# +# +# +# +# This is an array holding the values to use for the z-axis of +# data. The units must be appropriate for the measurement. +# +# +# +# +# # diff --git a/base_classes/nyaml/NXsource.yaml b/base_classes/nyaml/NXsource.yaml index a9a6035c4c..96788835f7 100644 --- a/base_classes/nyaml/NXsource.yaml +++ b/base_classes/nyaml/NXsource.yaml @@ -2,7 +2,8 @@ category: base doc: | Radiation source emitting a beam. - Examples include particle sources (electrons, neutrons, protons) or sources for electromagnetic radation (photons). + Examples include particle sources (electrons, neutrons, protons) or sources for electromagnetic radiation (photons). + This base class can also be used to describe neutron or x-ray storage ring/facilities. type: group NXsource(NXobject): distance(NX_FLOAT): @@ -205,14 +206,14 @@ NXsource(NXobject): other component groups. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 81bbad2d2d7f3bbecb78610a117d3a40a45be96101c9d07cbb30d30d58eeaf45 -# +# 0a6a307ccc9631e05a65861861127ee26e09fdb3e8b72eaa99bcc24fb0572d39 +# # # + diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index cf06b70e0a..3fdd109546 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -182,6 +182,9 @@ NXmpes(NXobject): identifier: exists: recommended description: + work_function(NX_FLOAT): + unit: NX_ENERGY + exists: recommended energy_resolution(NXresolution): exists: recommended type: From fdb36ff5b67119267ef93a092fa30f08ba2903a4 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 12 Jan 2024 12:53:01 +0100 Subject: [PATCH 0492/1012] set unicode character for \sim --- manual/source/conf.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/manual/source/conf.py b/manual/source/conf.py index f84671063f..1831cbdbc9 100755 --- a/manual/source/conf.py +++ b/manual/source/conf.py @@ -163,5 +163,6 @@ def setup(app): \DeclareUnicodeCharacter{1F517}{X} \DeclareUnicodeCharacter{2906}{<=} \DeclareUnicodeCharacter{394}{$\Delta$} - \DeclareUnicodeCharacter{2206}{$\Delta$}''' + \DeclareUnicodeCharacter{2206}{$\Delta$} + \DeclareUnicodeCharacter{007E}{$\sim$}''' } From f9867848ef96eb96b8c574267410783450b36723 Mon Sep 17 00:00:00 2001 From: domna Date: Fri, 12 Jan 2024 13:08:38 +0100 Subject: [PATCH 0493/1012] Use \sim instead of ~ in yaml file --- contributed_definitions/NXenergydispersion.nxdl.xml | 2 +- contributed_definitions/nyaml/NXenergydispersion.yaml | 2 +- manual/source/conf.py | 3 +-- 3 files changed, 3 insertions(+), 4 deletions(-) diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml index c7ed49c6bf..6770ce216d 100644 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ b/contributed_definitions/NXenergydispersion.nxdl.xml @@ -87,7 +87,7 @@ ratio is constant. In this mode, electrons of all energies are decelerated with this same fixed factor. Thus, the pass energy is proportional to the kinetic energy. This mode is often used in Auger electron spectroscopy (AES) to improve S/N for high-KE electrons, but this - leads to a changing energy resolution (:math:`ΔE ~ E_p`) at different kinetic energies. + leads to a changing energy resolution (:math:`ΔE \sim E_p`) at different kinetic energies. It can however also be used in XPS. Synonyms: constant :math:`ΔE/E` mode, constant retardation ratio mode, CRR mode, FRR mode diff --git a/contributed_definitions/nyaml/NXenergydispersion.yaml b/contributed_definitions/nyaml/NXenergydispersion.yaml index f24d4e012d..bc0d0c6f37 100644 --- a/contributed_definitions/nyaml/NXenergydispersion.yaml +++ b/contributed_definitions/nyaml/NXenergydispersion.yaml @@ -62,7 +62,7 @@ NXenergydispersion(NXobject): ratio is constant. In this mode, electrons of all energies are decelerated with this same fixed factor. Thus, the pass energy is proportional to the kinetic energy. This mode is often used in Auger electron spectroscopy (AES) to improve S/N for high-KE electrons, but this - leads to a changing energy resolution (:math:`ΔE ~ E_p`) at different kinetic energies. + leads to a changing energy resolution (:math:`ΔE \sim E_p`) at different kinetic energies. It can however also be used in XPS. Synonyms: constant :math:`ΔE/E` mode, constant retardation ratio mode, CRR mode, FRR mode diff --git a/manual/source/conf.py b/manual/source/conf.py index 1831cbdbc9..f84671063f 100755 --- a/manual/source/conf.py +++ b/manual/source/conf.py @@ -163,6 +163,5 @@ def setup(app): \DeclareUnicodeCharacter{1F517}{X} \DeclareUnicodeCharacter{2906}{<=} \DeclareUnicodeCharacter{394}{$\Delta$} - \DeclareUnicodeCharacter{2206}{$\Delta$} - \DeclareUnicodeCharacter{007E}{$\sim$}''' + \DeclareUnicodeCharacter{2206}{$\Delta$}''' } From b401db44e33f6ef9cc1cf35de418d51d08e129ed Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 12 Jan 2024 13:23:18 +0100 Subject: [PATCH 0494/1012] typo fix in NXenergydispersion --- .../NXenergydispersion.nxdl.xml | 14 +++++++------- .../nyaml/NXenergydispersion.yaml | 14 +++++++------- 2 files changed, 14 insertions(+), 14 deletions(-) diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml index 6770ce216d..9589bdad31 100644 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ b/contributed_definitions/NXenergydispersion.nxdl.xml @@ -68,13 +68,13 @@ - constant :math:`ΔE` mode, where the electron retardation (i.e., the fraction of pass energy to - kinetic energy, :math:`R = (E_K - WF/E_p))` is scanned, but the pass energy :math:`E_p` is kept constant. + constant :math:`\Delta E` mode, where the electron retardation (i.e., the fraction of pass energy to + kinetic energy, :math:`R = (E_K - WF/E_p)`, is scanned, but the pass energy :math:`E_p` is kept constant. Here, :math:`WF` is the spectrometer work function. This mode is often used in XPS/UPS because the energy resolution does not change with changing energy (due to the constant pass energy). - Synonyms: constant ΔE mode, constant analyser energy mode, CAE mode, FAT mode + Synonyms: constant :math:`\Delta E` mode, constant analyser energy mode, CAE mode, FAT mode This concept is related to term `12.64`_ of the ISO 18115-1:2023 standard. @@ -83,14 +83,14 @@ - constant :math:`ΔE/E` mode, where the pass energy is scanned such that the electron retardation + constant :math:`\Delta E/E` mode, where the pass energy is scanned such that the electron retardation ratio is constant. In this mode, electrons of all energies are decelerated with this same fixed factor. Thus, the pass energy is proportional to the kinetic energy. This mode is often used in Auger electron spectroscopy (AES) to improve S/N for high-KE electrons, but this - leads to a changing energy resolution (:math:`ΔE \sim E_p`) at different kinetic energies. + leads to a changing energy resolution (:math:`\Delta E \sim E_p`) at different kinetic energies. It can however also be used in XPS. - Synonyms: constant :math:`ΔE/E` mode, constant retardation ratio mode, CRR mode, FRR mode + Synonyms: constant :math:`\Delta E/E` mode, constant retardation ratio mode, CRR mode, FRR mode This concept is related to term `12.66`_ of the ISO 18115-1:2023 standard. @@ -105,7 +105,7 @@ alignment. Since the mode measures intensity as a function of time, the difference in channel signals - is not of interest. Threfore, the signals from all channels are summed. + is not of interest. Therefore, the signals from all channels are summed. Synonyms: FE mode diff --git a/contributed_definitions/nyaml/NXenergydispersion.yaml b/contributed_definitions/nyaml/NXenergydispersion.yaml index bc0d0c6f37..e7c0da250b 100644 --- a/contributed_definitions/nyaml/NXenergydispersion.yaml +++ b/contributed_definitions/nyaml/NXenergydispersion.yaml @@ -43,13 +43,13 @@ NXenergydispersion(NXobject): fixed_analyser_transmission: doc: - | - constant :math:`ΔE` mode, where the electron retardation (i.e., the fraction of pass energy to - kinetic energy, :math:`R = (E_K - WF/E_p))` is scanned, but the pass energy :math:`E_p` is kept constant. + constant :math:`\Delta E` mode, where the electron retardation (i.e., the fraction of pass energy to + kinetic energy, :math:`R = (E_K - WF/E_p)`, is scanned, but the pass energy :math:`E_p` is kept constant. Here, :math:`WF` is the spectrometer work function. This mode is often used in XPS/UPS because the energy resolution does not change with changing energy (due to the constant pass energy). - Synonyms: constant ΔE mode, constant analyser energy mode, CAE mode, FAT mode + Synonyms: constant :math:`\Delta E` mode, constant analyser energy mode, CAE mode, FAT mode - | xref: spec: ISO 18115-1:2023 @@ -58,14 +58,14 @@ NXenergydispersion(NXobject): fixed_retardation_ratio: doc: - | - constant :math:`ΔE/E` mode, where the pass energy is scanned such that the electron retardation + constant :math:`\Delta E/E` mode, where the pass energy is scanned such that the electron retardation ratio is constant. In this mode, electrons of all energies are decelerated with this same fixed factor. Thus, the pass energy is proportional to the kinetic energy. This mode is often used in Auger electron spectroscopy (AES) to improve S/N for high-KE electrons, but this - leads to a changing energy resolution (:math:`ΔE \sim E_p`) at different kinetic energies. + leads to a changing energy resolution (:math:`\Delta E \sim E_p`) at different kinetic energies. It can however also be used in XPS. - Synonyms: constant :math:`ΔE/E` mode, constant retardation ratio mode, CRR mode, FRR mode + Synonyms: constant :math:`\Delta E/E` mode, constant retardation ratio mode, CRR mode, FRR mode - | xref: spec: ISO 18115-1:2023 @@ -79,7 +79,7 @@ NXenergydispersion(NXobject): alignment. Since the mode measures intensity as a function of time, the difference in channel signals - is not of interest. Threfore, the signals from all channels are summed. + is not of interest. Therefore, the signals from all channels are summed. Synonyms: FE mode snapshot: From e487f8792bcac72b5baf5033353d86a004fcb3b1 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 12 Jan 2024 15:20:31 +0100 Subject: [PATCH 0495/1012] make nxmpes nyaml --- contributed_definitions/nyaml/NXmpes.yaml | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 3fdd109546..c43cdcccda 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -730,7 +730,7 @@ NXmpes(NXobject): @energy_depends: '/entry/instrument/energydispersion/center_energy' for a swept scan # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4566993bd258d86f791dc68ac61dee2a6b239930a4b8a33a2cadb72851de29a7 +# 74a4d48340a4440024b23ca7e9375d58b16291bd2dd6a35867c83631aa41b1dd # # # +# # # # A source used to generate a beam. Properties refer strictly to parameters of the @@ -953,6 +955,7 @@ NXmpes(NXobject): # # # +# # # # @@ -1072,13 +1075,11 @@ NXmpes(NXobject): # # # -# +# the `NXdetector` base class. But some refinement is necessary there.--> # # # Contains the raw data collected by the detector before calibration. From 3bc80022ebb0d05de2af18e89722a4e4a1690a2a Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Sat, 13 Jan 2024 13:50:06 +0100 Subject: [PATCH 0496/1012] change MPES base classes after Laurenz' review --- base_classes/NXdata.nxdl.xml | 4 +- base_classes/nyaml/NXdata.yaml | 4 +- contributed_definitions/NXactuator.nxdl.xml | 12 +- contributed_definitions/NXdata_mpes.nxdl.xml | 40 +-- .../NXdata_mpes_detector.nxdl.xml | 60 ++-- .../NXelectronanalyser.nxdl.xml | 4 +- contributed_definitions/NXresolution.nxdl.xml | 9 +- contributed_definitions/nyaml/NXactuator.yaml | 26 +- .../nyaml/NXdata_mpes.yaml | 96 ++++--- .../nyaml/NXdata_mpes_detector.yaml | 258 +++++++++++++++--- .../nyaml/NXelectronanalyser.yaml | 10 +- .../nyaml/NXresolution.yaml | 20 +- 12 files changed, 374 insertions(+), 169 deletions(-) diff --git a/base_classes/NXdata.nxdl.xml b/base_classes/NXdata.nxdl.xml index 6d3f186f3b..408eb3a2e5 100644 --- a/base_classes/NXdata.nxdl.xml +++ b/base_classes/NXdata.nxdl.xml @@ -302,12 +302,12 @@ AXISNAME_indices documentation copied from datarules.rst If the axis corresponds to a coordinate of a detector, ``@AXISNAME_depends`` links to that detector axis: - @AXISNAME_depends: '/entry/instrument/detector/axis/AXISNAME' for a 2D detector + @AXISNAME_depends: '/entry/instrument/detector/axis/some_axis' for a 2D detector If the axis is a scanned motor, ``@AXISNAME_depends`` links to the transformation describing the respective motion, e.g.: - @AXISNAME_depends: '/entry/instrument/detector/transformations/AXISNAME' for a motion of the detector + @AXISNAME_depends: '/entry/instrument/detector/transformations/some_transformation' for a motion of the detector diff --git a/base_classes/nyaml/NXdata.yaml b/base_classes/nyaml/NXdata.yaml index 41aff41957..3bfbf1da82 100644 --- a/base_classes/nyaml/NXdata.yaml +++ b/base_classes/nyaml/NXdata.yaml @@ -257,12 +257,12 @@ NXdata(NXobject): If the axis corresponds to a coordinate of a detector, ``@AXISNAME_depends`` links to that detector axis: - @AXISNAME_depends: '/entry/instrument/detector/axis/AXISNAME' for a 2D detector + @AXISNAME_depends: '/entry/instrument/detector/axis/some_axis' for a 2D detector If the axis is a scanned motor, ``@AXISNAME_depends`` links to the transformation describing the respective motion, e.g.: - @AXISNAME_depends: '/entry/instrument/detector/transformations/AXISNAME' for a motion of the detector + @AXISNAME_depends: '/entry/instrument/detector/transformations/some_transformation' for a motion of the detector AXISNAME(NX_NUMBER): nameType: any doc: | diff --git a/contributed_definitions/NXactuator.nxdl.xml b/contributed_definitions/NXactuator.nxdl.xml index cbb222f558..e647a7fb82 100644 --- a/contributed_definitions/NXactuator.nxdl.xml +++ b/contributed_definitions/NXactuator.nxdl.xml @@ -98,16 +98,8 @@ - Specifies the position of the actuator by pointing to the last - transformation in the transformation chain in the NXtransformations group. - - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0 (in a given coordinate system). - 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. + Refers to the last transformation specifying the position of the actuator + in the NXtransformations chain. diff --git a/contributed_definitions/NXdata_mpes.nxdl.xml b/contributed_definitions/NXdata_mpes.nxdl.xml index c395ce51b5..3649da88c5 100644 --- a/contributed_definitions/NXdata_mpes.nxdl.xml +++ b/contributed_definitions/NXdata_mpes.nxdl.xml @@ -63,51 +63,69 @@ + + Calibrated x axis in k-space. Units are 1/Angström. + + Calibrated y axis in k-space. Units are 1/Angström + + Calibrated z axis in k-space. Units are 1/Angström. + + Fast-axis angular coordinate (or second slow axis if angularly integrated). + + Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) + + Fast-axis spatial coordinate (or second slow axis if spatially integrated) + + Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) + + Calibrated delay time. + + Linear polarization angle of the incoming or outgoing beam. @@ -116,6 +134,8 @@ /entry/instrument/beam/final_polarization_angle if they exist. + + Ellipticity of the incoming or outgoing beam. @@ -125,26 +145,6 @@ /entry/instrument/beam/final_ellipticity if they exist. - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXdata_mpes_detector.nxdl.xml b/contributed_definitions/NXdata_mpes_detector.nxdl.xml index d8fb96e425..826f86925c 100644 --- a/contributed_definitions/NXdata_mpes_detector.nxdl.xml +++ b/contributed_definitions/NXdata_mpes_detector.nxdl.xml @@ -44,11 +44,15 @@ Detector pixel in x direction. + + Detector pixel in y direction. + + (Un)calibrated energy axis. @@ -79,72 +83,98 @@ + + (Un)calibrated x axis in k-space. Units are 1/Angström. + + (Un)calibrated y axis in k-space. Units are 1/Angström + + (Un)calibrated z axis in k-space. Units are 1/Angström. + + Fast-axis angular coordinate (or second slow axis if angularly integrated). + + Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in two dimensions) + + Fast-axis spatial coordinate (or second slow axis if spatially integrated) + + Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in two dimensions) + + Total time of flight + + Time-of-flight values, analog-to-digital converted. + + (Un)calibrated delay time. + + Linear polarization angle of the incoming or outgoing beam. + + Ellipticity of the incoming or outgoing beam. + + Describes an axis which is coming from outside the detectors scope. @@ -156,34 +186,4 @@ and write it to the top-level NXdata. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml index 30bd6162e7..633920ace2 100644 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -44,7 +44,7 @@ - Basic class for describing a photoelectron analyzer. + Basic class for describing a electron analyzer. This concept is related to term `12.59`_ of the ISO 18115-1:2023 standard. @@ -180,7 +180,7 @@ The transmission function (TF) specifies the detection efficiency per solid angle for electrons of different kinetic energy passing through the electron analyser. It depends on the spectrometer geometry as well as operation settings such as lens mode and pass energy. - The transmission function is usually given as kinetic energy vs. relative intensity. + The transmission function is usually given as relative intensity vs. kinetic energy. The TF is used for calibration of the intensity scale in quantitative XPS. Without proper transmission correction, a comparison of results measured from the same sample using different diff --git a/contributed_definitions/NXresolution.nxdl.xml b/contributed_definitions/NXresolution.nxdl.xml index cf273b70c2..6ce2ca2c76 100644 --- a/contributed_definitions/NXresolution.nxdl.xml +++ b/contributed_definitions/NXresolution.nxdl.xml @@ -52,18 +52,19 @@ The resolution of the physical quantity. - + - Standard deviations of the resolution of the physical quantity. + Standard deviation of the resolution of the physical quantity. - The response of the instrument or part to a infinitesimal short input signal + The response of the instrument or part to a infinitesimally sharp input signal along the physical quantity of this group. This is also sometimes called instrument response function for time resolution or point spread function for spatial response. - The resolution is typically determined by taking the FWHM of the response function. + The resolution is typically determined by taking the full width at half maximum (FWHM) + of the response function. diff --git a/contributed_definitions/nyaml/NXactuator.yaml b/contributed_definitions/nyaml/NXactuator.yaml index 4fd10a69aa..ccc15f7ec4 100644 --- a/contributed_definitions/nyaml/NXactuator.yaml +++ b/contributed_definitions/nyaml/NXactuator.yaml @@ -56,16 +56,8 @@ NXactuator(NXobject): Time history of actuator setpoints. depends_on(NX_CHAR): doc: | - Specifies the position of the actuator by pointing to the last - transformation in the transformation chain in the NXtransformations group. - - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0 (in a given coordinate system). - 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. + Refers to the last transformation specifying the position of the actuator + in the NXtransformations chain. (NXtransformations): doc: | This is the group recommended for holding the chain of translation @@ -75,7 +67,7 @@ NXactuator(NXobject): (NXfabrication): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4169a4ab5f38d5f3ad4963da42051a1fc7d560d8e6e537d98c9db7061527667a +# ace4abf5ad9c9c7c3c2127dd7f73de80b4200b40f9a820be62c19c8a0391deb5 # # # +# +# +# :ref:`NXdata_mpes_detector` describes the plottable data and related dimension scales +# for raw detector data in MPES experiments. +# +# It extends the NXdata class and provides a glossary of explicitly named axis names +# which are typical for raw MPES data. +# +# +# +# +# +# +# +# +# Raw data before calibration. +# +# +# +# +# Detector pixel in x direction. +# +# +# +# +# +# +# Detector pixel in y direction. +# +# +# +# +# +# +# (Un)calibrated energy axis. +# +# +# +# The energy can be either stored as kinetic or as binding energy. +# +# +# +# +# (Un)calibrated kinetic energy axis. +# +# This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. +# +# .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 +# +# +# +# +# (Un)calibrated binding energy axis. +# +# This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. +# +# .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 +# +# +# +# +# +# +# +# +# +# (Un)calibrated x axis in k-space. +# Units are 1/Angström. +# +# +# +# +# +# +# (Un)calibrated y axis in k-space. +# Units are 1/Angström +# +# +# +# +# +# +# (Un)calibrated z axis in k-space. +# Units are 1/Angström. +# +# +# +# +# +# +# Fast-axis angular coordinate (or second slow axis if angularly integrated). +# +# +# +# +# +# +# Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in two +# dimensions) +# +# +# +# +# +# +# Fast-axis spatial coordinate (or second slow axis if spatially integrated) +# +# +# +# +# +# +# Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in two +# dimensions) +# +# +# +# +# +# +# +# Total time of flight +# +# +# +# +# +# +# Time-of-flight values, analog-to-digital converted. +# +# +# +# +# +# +# (Un)calibrated delay time. +# +# +# +# +# +# +# Linear polarization angle of the incoming or outgoing beam. +# +# +# +# +# +# +# Ellipticity of the incoming or outgoing beam. +# +# +# +# +# +# +# Describes an axis which is coming from outside the detectors scope. +# +# Think of a detector just being triggered for readout by the rest of the experimental +# setup - it would just know that it collected N images, which would flatten the external +# parameters to one axis, too. +# This can then be linked, e.g. with NXcalibration, to the appropriate fields in the instrument +# and write it to the top-level NXdata. +# +# +# diff --git a/contributed_definitions/nyaml/NXelectronanalyser.yaml b/contributed_definitions/nyaml/NXelectronanalyser.yaml index 299ca0761d..66ed09a20c 100644 --- a/contributed_definitions/nyaml/NXelectronanalyser.yaml +++ b/contributed_definitions/nyaml/NXelectronanalyser.yaml @@ -1,7 +1,7 @@ category: base doc: - | - Basic class for describing a photoelectron analyzer. + Basic class for describing a electron analyzer. - | xref: spec: ISO 18115-1:2023 @@ -132,7 +132,7 @@ NXelectronanalyser(NXobject): The transmission function (TF) specifies the detection efficiency per solid angle for electrons of different kinetic energy passing through the electron analyser. It depends on the spectrometer geometry as well as operation settings such as lens mode and pass energy. - The transmission function is usually given as kinetic energy vs. relative intensity. + The transmission function is usually given as relative intensity vs. kinetic energy. - | The TF is used for calibration of the intensity scale in quantitative XPS. Without proper transmission correction, a comparison of results measured from the same sample using different @@ -199,7 +199,7 @@ NXelectronanalyser(NXobject): Any other resolution not explicitly named in this base class. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 6067865361d1b68db8cd8eb3843a5caff3589c0b3fac908d72ade9b6f5dbb90a +# 77bf48ca5f3c738f3a931e2f55804a586c60b70a3306bd5ad22a5fd8d75e1e89 # # # A source used to generate a beam. Properties refer strictly to parameters of the source, not of the output beam. For example, the energy of the source is not the optical power of the beam, but the energy of the electron beam in a synchrotron - and so on. + or similar. Note that the uppercase notation in source_TYPE means that multiple sources can be provided. For example, in pump-probe experiments, it is possible to have both @@ -184,9 +187,6 @@ - Properties of the photon beam at a given location. @@ -234,11 +234,8 @@ This would also be helpful for NXtransformations--> - + - Scheme of the electron collection column. @@ -342,11 +339,6 @@ Optional constant settings (like lens focusing parameters on the sample: positio - Contains the raw data collected by the detector before calibration. @@ -407,9 +399,9 @@ the `NXdetector` base class. But some refinement is necessary there.--> - + - + @@ -417,11 +409,22 @@ the `NXdetector` base class. But some refinement is necessary there.--> - + + + + + + + + + + + + @@ -430,7 +433,7 @@ the `NXdetector` base class. But some refinement is necessary there.--> - + @@ -440,7 +443,19 @@ the `NXdetector` base class. But some refinement is necessary there.--> - + + + + + + + + + + + + + @@ -459,7 +474,7 @@ the `NXdetector` base class. But some refinement is necessary there.--> - + In case of a single or averaged gas pressure measurement, this is the scalar gas pressure around the sample. It can also be an 1D array of measured pressures (without time stamps). @@ -639,7 +654,7 @@ the `NXdetector` base class. But some refinement is necessary there.--> - For samples containing a single pure substances. For mixtures use the + For samples containing a single pure substance. For mixtures use the NXsample_component_set and NXsample_component group in NXsample instead. @@ -700,6 +715,12 @@ the `NXdetector` base class. But some refinement is necessary there.--> This should be a link to /entry/instrument/manipulator/sample_heater. + + + Cryostat for cooling the sample. + This should be a link to /entry/instrument/manipulator/cryostat. + + @@ -723,7 +744,14 @@ the `NXdetector` base class. But some refinement is necessary there.--> - Sensor setting/measuring the applied voltage. + Sensor measuring the applied voltage. + + This should be a link to /entry/instrument/manipulator/sample_bias_voltmeter. + + + + + Actuator applying a voltage to sample and sample holder.s This should be a link to /entry/instrument/manipulator/sample_bias_voltmeter. @@ -838,11 +866,10 @@ the `NXdetector` base class. But some refinement is necessary there.--> The energy can be dispersed according to different strategies. ``energy_depends`` points to - the path of a field defining the axis on which the energy axis depends. + the path of a field defining the calibrated axis on which the energy axis depends. For example: - @energy_depends: '/entry/instrument/detector/data/sensor_y' for a 2D detector - @energy_depends: '/entry/instrument/energydispersion/center_energy' for a swept scan + @energy_depends: 'entry/process/energy_calibration' diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index c43cdcccda..db81a04c1a 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -34,7 +34,9 @@ NXmpes(NXobject): method: exists: recommended doc: | - A name of the experimental method according to `Clause 11`_ of + Name of the experimental method. + + If applicable, this name should match the terms given by `Clause 11`_ of the `ISO 18115-1:2023`_ specification. Examples include: @@ -46,6 +48,9 @@ NXmpes(NXobject): * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) * photoelectron emission microscopy (PEEM) * electron spectroscopy for chemical analysis (ESCA) + * time-resolved angle-resolved X-ray photoelectron spectroscopy (trARPES) + * spin-resolved angle-resolved X-ray photoelectron spectroscopy (spin-ARPES) + * momentum microscopy .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 @@ -59,12 +64,12 @@ NXmpes(NXobject): Name of the user. affiliation: doc: | - Name of the affiliation of the user at the point in time when the experiment was + Name of the affiliation of the user at the time when the experiment was performed. (NXinstrument): doc: - | - MPES spectrometer + Description of the MPES spectrometer and its individual parts. - | xref: spec: ISO 18115-1:2023 @@ -99,16 +104,13 @@ NXmpes(NXobject): exists: recommended identifier: exists: recommended - - # Comment from mpes may workshop: - # - There is much more information which can be provided for NXsource source_TYPE(NXsource): exists: recommended doc: | A source used to generate a beam. Properties refer strictly to parameters of the source, not of the output beam. For example, the energy of the source is not the optical power of the beam, but the energy of the electron beam in a synchrotron - and so on. + or similar. Note that the uppercase notation in source_TYPE means that multiple sources can be provided. For example, in pump-probe experiments, it is possible to have both @@ -138,10 +140,6 @@ NXmpes(NXobject): for `source_probe` it should refer to `beam_probe`. Refers to the same concept as /NXentry/NXinstrument/beam_TYPE and may be linked. - - # It would be nice if we had the notion of linking in nexus or if - # we have a subdefinition NXlink to refer to a path. - # This would also be helpful for NXtransformations beam_TYPE(NXbeam): doc: | Properties of the photon beam at a given location. @@ -196,13 +194,9 @@ NXmpes(NXobject): exists: recommended slow_axes: exists: recommended - transmission_function(NX_FLOAT): + transmission_function(NXdata): exists: optional (NXcollectioncolumn): - - # TODO: Comment from Anders Frisk on proposal page - # What is the definition of a collection column? - # Optional constant settings (like lens focusing parameters on the sample: position_x, position_y, working_distance) scheme: doc: | Scheme of the electron collection column. @@ -287,12 +281,6 @@ NXmpes(NXobject): exists: recommended identifier: exists: recommended - - # ToDo: - # - With base class inheritance this should be - # a field of type NXdata_mpes_detector - # - The field name should be aligned with the `data` field in - # the `NXdetector` base class. But some refinement is necessary there. raw_data(NXdata): exists: recommended doc: | @@ -346,9 +334,8 @@ NXmpes(NXobject): type: exists: optional value(NX_FLOAT): - exists: recommended sample_heater(NXactuator): - exists: recommended + exists: optional name: exists: recommended physical_quantity: @@ -356,11 +343,19 @@ NXmpes(NXobject): type: exists: optional heater_power(NX_FLOAT): - exists: recommended (NXpid): exists: recommended setpoint(NX_FLOAT): exists: recommended + cryostat(NXactuator): + exists: optional + physical_quantity: + enumeration: [temperature] + type: + exists: optional + (NXpid): + setpoint(NX_FLOAT): + exists: recommended drain_current_amperemeter(NXsensor): exists: recommended name: @@ -370,7 +365,6 @@ NXmpes(NXobject): type: exists: optional value(NX_FLOAT): - exists: recommended sample_bias_voltmeter(NXsensor): exists: recommended name: @@ -380,7 +374,18 @@ NXmpes(NXobject): type: exists: optional value(NX_FLOAT): + sample_bias_potentiostat(NXactuator): + exists: recommended + name: + exists: recommended + physical_quantity: + enumeration: [voltage] + type: + exists: optional + (NXpid): exists: recommended + setpoint(NX_FLOAT): + exists: recommended device_information(NXfabrication): exists: recommended vendor: @@ -399,7 +404,6 @@ NXmpes(NXobject): type: exists: optional value(NX_FLOAT): - exists: recommended unit: NX_PRESSURE doc: | In case of a single or averaged gas pressure measurement, this is the scalar gas pressure around @@ -554,7 +558,7 @@ NXmpes(NXobject): (NXsubstance): exists: recommended doc: | - For samples containing a single pure substances. For mixtures use the + For samples containing a single pure substance. For mixtures use the NXsample_component_set and NXsample_component group in NXsample instead. molecular_formula_hill: exists: recommended @@ -602,6 +606,11 @@ NXmpes(NXobject): doc: | Device to heat the sample. This should be a link to /entry/instrument/manipulator/sample_heater. + cryostat(NXactuator): + exists: optional + doc: | + Cryostat for cooling the sample. + This should be a link to /entry/instrument/manipulator/cryostat. gas_pressure(NXenvironment): exists: recommended doc: | @@ -623,7 +632,12 @@ NXmpes(NXobject): url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 voltmeter(NXsensor): doc: | - Sensor setting/measuring the applied voltage. + Sensor measuring the applied voltage. + + This should be a link to /entry/instrument/manipulator/sample_bias_voltmeter. + sample_bias_potentiostat(NXactuator): + doc: | + Actuator applying a voltage to sample and sample holder.s This should be a link to /entry/instrument/manipulator/sample_bias_voltmeter. drain_current(NXenvironment): @@ -723,14 +737,13 @@ NXmpes(NXobject): exists: recommended doc: | The energy can be dispersed according to different strategies. ``energy_depends`` points to - the path of a field defining the axis on which the energy axis depends. + the path of a field defining the calibrated axis on which the energy axis depends. For example: - @energy_depends: '/entry/instrument/detector/data/sensor_y' for a 2D detector - @energy_depends: '/entry/instrument/energydispersion/center_energy' for a swept scan + @energy_depends: 'entry/process/energy_calibration' # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 74a4d48340a4440024b23ca7e9375d58b16291bd2dd6a35867c83631aa41b1dd +# 082a6ba1fec2f58c80336a5107df04760b9ffd3c56fb1ee4652fd2bfc151a633 # # # # # # A source used to generate a beam. Properties refer strictly to parameters of the # source, not of the output beam. For example, the energy of the source is not the # optical power of the beam, but the energy of the electron beam in a synchrotron -# and so on. +# or similar. # # Note that the uppercase notation in source_TYPE means that multiple sources can # be provided. For example, in pump-probe experiments, it is possible to have both @@ -917,9 +933,6 @@ NXmpes(NXobject): # # # -# # # # Properties of the photon beam at a given location. @@ -967,11 +980,8 @@ NXmpes(NXobject): # # # -# +# # -# # # # Scheme of the electron collection column. @@ -1075,11 +1085,6 @@ NXmpes(NXobject): # # # -# # # # Contains the raw data collected by the detector before calibration. @@ -1140,9 +1145,9 @@ NXmpes(NXobject): # # # -# +# # -# +# # # # @@ -1150,11 +1155,22 @@ NXmpes(NXobject): # # # -# +# # # # # +# +# +# +# +# +# +# +# +# +# +# # # # @@ -1163,7 +1179,7 @@ NXmpes(NXobject): # # # -# +# # # # @@ -1173,7 +1189,19 @@ NXmpes(NXobject): # # # -# +# +# +# +# +# +# +# +# +# +# +# +# +# # # # @@ -1192,7 +1220,7 @@ NXmpes(NXobject): # # # -# +# # # In case of a single or averaged gas pressure measurement, this is the scalar gas pressure around # the sample. It can also be an 1D array of measured pressures (without time stamps). @@ -1372,7 +1400,7 @@ NXmpes(NXobject): # # # -# For samples containing a single pure substances. For mixtures use the +# For samples containing a single pure substance. For mixtures use the # NXsample_component_set and NXsample_component group in NXsample instead. # # @@ -1433,6 +1461,12 @@ NXmpes(NXobject): # This should be a link to /entry/instrument/manipulator/sample_heater. # # +# +# +# Cryostat for cooling the sample. +# This should be a link to /entry/instrument/manipulator/cryostat. +# +# # # # @@ -1456,7 +1490,14 @@ NXmpes(NXobject): # # # -# Sensor setting/measuring the applied voltage. +# Sensor measuring the applied voltage. +# +# This should be a link to /entry/instrument/manipulator/sample_bias_voltmeter. +# +# +# +# +# Actuator applying a voltage to sample and sample holder.s # # This should be a link to /entry/instrument/manipulator/sample_bias_voltmeter. # @@ -1571,11 +1612,10 @@ NXmpes(NXobject): # # # The energy can be dispersed according to different strategies. ``energy_depends`` points to -# the path of a field defining the axis on which the energy axis depends. +# the path of a field defining the calibrated axis on which the energy axis depends. # # For example: -# @energy_depends: '/entry/instrument/detector/data/sensor_y' for a 2D detector -# @energy_depends: '/entry/instrument/energydispersion/center_energy' for a swept scan +# @energy_depends: 'entry/process/energy_calibration' # # # From 9c874ad012d1f0e3245fde61e149bdedbafd9ee2 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Sat, 13 Jan 2024 14:57:12 +0100 Subject: [PATCH 0498/1012] change mapping in NXcalibration --- contributed_definitions/NXcalibration.nxdl.xml | 2 +- contributed_definitions/NXmpes.nxdl.xml | 2 +- contributed_definitions/nyaml/NXcalibration.yaml | 6 +++--- contributed_definitions/nyaml/NXmpes.yaml | 6 +++--- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml index cac4b9418c..46e651eedb 100644 --- a/contributed_definitions/NXcalibration.nxdl.xml +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -160,7 +160,7 @@ This should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. - + Mapping data for calibration. diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index c8185069aa..f388de90d7 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -613,7 +613,7 @@ field of the transmission_function. This calibration procedure is used to account for the different tranmsission efficiencies when using different lens modes. - + Transmission function of the electron analyser. diff --git a/contributed_definitions/nyaml/NXcalibration.yaml b/contributed_definitions/nyaml/NXcalibration.yaml index 2840c990e2..cbb6069f21 100644 --- a/contributed_definitions/nyaml/NXcalibration.yaml +++ b/contributed_definitions/nyaml/NXcalibration.yaml @@ -105,7 +105,7 @@ NXcalibration(NXobject): doc: | For linear calibration. Offset parameter. This should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. - MAPPING(NX_FLOAT): + mapping_MAPPING(NX_FLOAT): doc: | Mapping data for calibration. @@ -124,7 +124,7 @@ NXcalibration(NXobject): Should be a valid NeXus path name, e.g., /entry/data/energy. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 9cd87d2c956c457d9130253e69d3a7f803c3a77b8783dde4833fe0cc7ed414f7 +# 000a4ffe144b6f50a59bbb98cd3a89749cc1c44c119081a929fcad6215bdb2f1 # # # - :ref:`NXdata_mpes_detector` describes the plottable data and related dimension scales + :ref:`NXdata_mpes_detector` describes the plottable data and related dimension scales for raw detector data in MPES experiments. It extends the NXdata class and provides a glossary of explicitly named axis names diff --git a/contributed_definitions/nyaml/NXdata_mpes_detector.yaml b/contributed_definitions/nyaml/NXdata_mpes_detector.yaml index f750f891d4..ccf82e6045 100644 --- a/contributed_definitions/nyaml/NXdata_mpes_detector.yaml +++ b/contributed_definitions/nyaml/NXdata_mpes_detector.yaml @@ -32,8 +32,8 @@ NXdata_mpes_detector(NXdata): type: NX_CHAR doc: | The energy can be either stored as kinetic or as binding energy. - enumeration: - kinetic: + enumeration: + kinetic: doc: - | (Un)calibrated kinetic energy axis. @@ -42,7 +42,7 @@ NXdata_mpes_detector(NXdata): spec: ISO 18115-1:2023 term: 3.35 url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 - binding: + binding: doc: - | (Un)calibrated binding energy axis. @@ -170,7 +170,7 @@ NXdata_mpes_detector(NXdata): # --> # # -# :ref:`NXdata_mpes_detector` describes the plottable data and related dimension scales +# :ref:`NXdata_mpes_detector` describes the plottable data and related dimension scales # for raw detector data in MPES experiments. # # It extends the NXdata class and provides a glossary of explicitly named axis names From 03d8477ffca19e7ce763de5428e23fd0fa35b8c8 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 15 Jan 2024 11:39:15 +0100 Subject: [PATCH 0501/1012] change docstring of spatial acceptance in NXcollectioncolumn --- .../NXcollectioncolumn.nxdl.xml | 2 +- .../nyaml/NXcollectioncolumn.yaml | 27 ++++++++++++++----- 2 files changed, 22 insertions(+), 7 deletions(-) diff --git a/contributed_definitions/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXcollectioncolumn.nxdl.xml index 1c46ad4907..93c6c6ba3e 100644 --- a/contributed_definitions/NXcollectioncolumn.nxdl.xml +++ b/contributed_definitions/NXcollectioncolumn.nxdl.xml @@ -73,7 +73,7 @@ - Acceptance length of the collection column. + Acceptance length or area of the collection column. diff --git a/contributed_definitions/nyaml/NXcollectioncolumn.yaml b/contributed_definitions/nyaml/NXcollectioncolumn.yaml index 865af6e232..64e5714fd2 100644 --- a/contributed_definitions/nyaml/NXcollectioncolumn.yaml +++ b/contributed_definitions/nyaml/NXcollectioncolumn.yaml @@ -40,7 +40,8 @@ NXcollectioncolumn(NXobject): url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:7.4 spatial_acceptance(NX_FLOAT): unit: NX_LENGTH - doc: Acceptance length of the collection column. + doc: | + Acceptance length or area of the collection column. magnification(NX_FLOAT): unit: NX_DIMENSIONLESS doc: | @@ -72,14 +73,14 @@ NXcollectioncolumn(NXobject): (NXfabrication): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# ade39e7ed295bf737ba76d73ecd423510887fbdf2e9e101c2248659c79c057f9 -# +# dadb7b6ffb1466761253f335bf00a73741580668da2e77983b4702847426d506 +# # # + + + :ref:`NXprocess_mpes` describes events of data processing, reconstruction, + or analysis for MPES-related data. + + It extends the NXprocess class and provides a glossary of explicitly named processes + and their metadata which are typical for MPES data. + + + + Calibration event on the energy axis. + + For XPS, the calibration should ideally be performed according to + `ISO 15472:2010`_ specification. + + .. _ISO 15472:2010: https://www.iso.org/standard/74811.html + + + + This is the calibrated energy axis to be used for data plotting. + + + + + + + This is the calibrated angular axis to be used for data plotting. + + + + + + + This is the calibrated spatial axis to be used for data plotting. + + + + + + + This is the momentum axis to be used for data plotting. + + + + + + For energy referencing, the measured energies are corrected for the charging potential + (i.e., the electrical potential of the surface region of an insulating sample, caused by + irradiation) such that those energies correspond to a sample with no surface charge. + Usually, the energy axis is adjusted by shifting all energies uniformally until one + well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. + + This concept is related to term `12.74 ff.`_ of the ISO 18115-1:2023 standard. + + .. _12.74 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 + + + + Electronic core or valence level that was used for the calibration. + + + + + Reference peak that was used for the calibration. + + For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge | vacuum level + + + + + The binding energy (in units of eV) that the specified emission line appeared at, + after adjusting the binding energy scale. + + This concept is related to term `12.16_ ff.`_ of the ISO 18115-1:2023 standard. + + .. _12.16_ ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + + + + + Offset between measured binding energy and calibrated binding energy of the + emission line. + + + + + This is the calibrated energy axis to be used for data plotting. + + This should link to /entry/data/energy. + + + + + + In the transmission correction, each intensity measurement for electrons of a given + kinetic energy is multiplied by the corresponding value in the relative_intensity + field of the transmission_function. This calibration procedure is used to account for + the different tranmsission efficiencies when using different lens modes. + + + + Transmission function of the electron analyser. + + The transmission function (TF) specifies the detection efficiency for electrons of + different kinetic energy passing through the electron analyser. + This can be a link to /entry/instrument/electronanalyser/transmission_function. + + + + + + + + + + + + + + Kinetic energy values + + + + + + + + Relative transmission efficiency for the given kinetic energies + + + + + + + + diff --git a/contributed_definitions/nyaml/NXprocess_mpes.yaml b/contributed_definitions/nyaml/NXprocess_mpes.yaml new file mode 100644 index 0000000000..bf1833a521 --- /dev/null +++ b/contributed_definitions/nyaml/NXprocess_mpes.yaml @@ -0,0 +1,266 @@ +category: base +doc: | + :ref:`NXprocess_mpes` describes events of data processing, reconstruction, + or analysis for MPES-related data. + + It extends the NXprocess class and provides a glossary of explicitly named processes + and their metadata which are typical for MPES data. +type: group +NXprocess_mpes(NXprocess): + energy_calibration(NXcalibration): + doc: | + Calibration event on the energy axis. + + For XPS, the calibration should ideally be performed according to + `ISO 15472:2010`_ specification. + + .. _ISO 15472:2010: https://www.iso.org/standard/74811.html + calibrated_axis(NX_FLOAT): + doc: | + This is the calibrated energy axis to be used for data plotting. + angular_calibration(NXcalibration): + calibrated_axis(NX_FLOAT): + doc: | + This is the calibrated angular axis to be used for data plotting. + spatial_calibration(NXcalibration): + calibrated_axis(NX_FLOAT): + doc: | + This is the calibrated spatial axis to be used for data plotting. + momentum_calibration(NXcalibration): + exists: optional + calibrated_axis(NX_FLOAT): + doc: | + This is the momentum axis to be used for data plotting. + energy_referencing(NXcalibration): + doc: + - | + For energy referencing, the measured energies are corrected for the charging potential + (i.e., the electrical potential of the surface region of an insulating sample, caused by + irradiation) such that those energies correspond to a sample with no surface charge. + Usually, the energy axis is adjusted by shifting all energies uniformally until one + well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. + - | + xref: + spec: ISO 18115-1:2023 + term: 12.74 ff. + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 + level(NXelectron_level): + doc: | + Electronic core or valence level that was used for the calibration. + reference_peak: + doc: | + Reference peak that was used for the calibration. + + For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge | vacuum level + binding_energy(NX_FLOAT): + doc: + - | + The binding energy (in units of eV) that the specified emission line appeared at, + after adjusting the binding energy scale. + - | + xref: + spec: ISO 18115-1:2023 + term: 12.16_ ff. + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + offset(NX_FLOAT): + doc: | + Offset between measured binding energy and calibrated binding energy of the + emission line. + calibrated_axis(NX_FLOAT): + doc: | + This is the calibrated energy axis to be used for data plotting. + + This should link to /entry/data/energy. + transmission_correction(NXcalibration): + doc: | + In the transmission correction, each intensity measurement for electrons of a given + kinetic energy is multiplied by the corresponding value in the relative_intensity + field of the transmission_function. This calibration procedure is used to account for + the different tranmsission efficiencies when using different lens modes. + transmission_function(NXdata): + doc: | + Transmission function of the electron analyser. + + The transmission function (TF) specifies the detection efficiency for electrons of + different kinetic energy passing through the electron analyser. + This can be a link to /entry/instrument/electronanalyser/transmission_function. + \@signal: + enumeration: [relative_intensity] + \@axes: + enumeration: [kinetic_energy] + kinetic_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + Kinetic energy values + dimensions: + rank: 1 + dim: [[1, n_transmission_function]] + relative_intensity(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Relative transmission efficiency for the given kinetic energies + dimensions: + rank: 1 + dim: [[1, n_transmission_function]] + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 8c2be91055cba41fd23b23cc1ec13a132da3afa32a9fb666f8242e34c864aa68 +# +# +# +# +# +# :ref:`NXprocess_mpes` describes events of data processing, reconstruction, +# or analysis for MPES-related data. +# +# It extends the NXprocess class and provides a glossary of explicitly named processes +# and their metadata which are typical for MPES data. +# +# +# +# Calibration event on the energy axis. +# +# For XPS, the calibration should ideally be performed according to +# `ISO 15472:2010`_ specification. +# +# .. _ISO 15472:2010: https://www.iso.org/standard/74811.html +# +# +# +# This is the calibrated energy axis to be used for data plotting. +# +# +# +# +# +# +# This is the calibrated angular axis to be used for data plotting. +# +# +# +# +# +# +# This is the calibrated spatial axis to be used for data plotting. +# +# +# +# +# +# +# This is the momentum axis to be used for data plotting. +# +# +# +# +# +# For energy referencing, the measured energies are corrected for the charging potential +# (i.e., the electrical potential of the surface region of an insulating sample, caused by +# irradiation) such that those energies correspond to a sample with no surface charge. +# Usually, the energy axis is adjusted by shifting all energies uniformally until one +# well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. +# +# This concept is related to term `12.74 ff.`_ of the ISO 18115-1:2023 standard. +# +# .. _12.74 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 +# +# +# +# Electronic core or valence level that was used for the calibration. +# +# +# +# +# Reference peak that was used for the calibration. +# +# For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge | vacuum level +# +# +# +# +# The binding energy (in units of eV) that the specified emission line appeared at, +# after adjusting the binding energy scale. +# +# This concept is related to term `12.16_ ff.`_ of the ISO 18115-1:2023 standard. +# +# .. _12.16_ ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 +# +# +# +# +# Offset between measured binding energy and calibrated binding energy of the +# emission line. +# +# +# +# +# This is the calibrated energy axis to be used for data plotting. +# +# This should link to /entry/data/energy. +# +# +# +# +# +# In the transmission correction, each intensity measurement for electrons of a given +# kinetic energy is multiplied by the corresponding value in the relative_intensity +# field of the transmission_function. This calibration procedure is used to account for +# the different tranmsission efficiencies when using different lens modes. +# +# +# +# Transmission function of the electron analyser. +# +# The transmission function (TF) specifies the detection efficiency for electrons of +# different kinetic energy passing through the electron analyser. +# This can be a link to /entry/instrument/electronanalyser/transmission_function. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Kinetic energy values +# +# +# +# +# +# +# +# Relative transmission efficiency for the given kinetic energies +# +# +# +# +# +# +# +# From 629d530cefd6c18e9d1a5a39bc7e24e0d91a787f Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 15 Jan 2024 12:21:33 +0100 Subject: [PATCH 0505/1012] add generic NXactuator to NXenvironment --- base_classes/NXenvironment.nxdl.xml | 13 ++++++++++++- base_classes/nyaml/NXenvironment.yaml | 24 +++++++++++++++++++++--- 2 files changed, 33 insertions(+), 4 deletions(-) diff --git a/base_classes/NXenvironment.nxdl.xml b/base_classes/NXenvironment.nxdl.xml index 42017ad26c..1dd95974a8 100644 --- a/base_classes/NXenvironment.nxdl.xml +++ b/base_classes/NXenvironment.nxdl.xml @@ -81,5 +81,16 @@ Additional information, LabView logs, digital photographs, etc - + + + Any actuator used to control the environment. This can be linked to an actuator + defined in an NXinstrument instance. + + + + + Any sensor used to monitor the environment. This can be linked to a sensor + defined in an NXinstrument instance. + + diff --git a/base_classes/nyaml/NXenvironment.yaml b/base_classes/nyaml/NXenvironment.yaml index 5838c46dc2..92efc44ec0 100644 --- a/base_classes/nyaml/NXenvironment.yaml +++ b/base_classes/nyaml/NXenvironment.yaml @@ -42,16 +42,23 @@ NXenvironment(NXobject): (NXnote): doc: | Additional information, LabView logs, digital photographs, etc + (NXactuator): + doc: | + Any actuator used to control the environment. This can be linked to an actuator + defined in an NXinstrument instance. (NXsensor): + doc: | + Any sensor used to monitor the environment. This can be linked to a sensor + defined in an NXinstrument instance. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 80f8cc95a36d1cfba899c1ad69098b8b51aec9926f41412d74df090d9c4a2b11 +# edb4357785f3ad2e7c84849c787be220920b9eef3a18ee1c8d251327873c87b7 # # # Base class for a set of components providing a controllable electron beam. + + + Typically tech-partner, microscope-, and control software-specific + name of the specific operation mode how the ebeam_column and its + components are controlled to achieve a specific illumination condition. + + In most cases users do not know, have to care, or are able to disentangle the + details of the spatiotemporal dynamics of the components of the microscope. + Instead, they rely on the assumption that the microscope and control software + work as expected. Selecting then a specific operation_mode assures some level + of reproducibility in the illumination conditions. + + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 6fb28541bc..99aae7951e 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -537,6 +537,7 @@ the fields they can be used--> + @@ -547,6 +548,14 @@ the fields they can be used--> + + + + + + + + diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml index 0b8b756bf9..b4e1928dfe 100644 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -21,54 +21,43 @@ # # For further information, see http://www.nexusformat.org --> + - - - - Number of electron energy loss bins. - - - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). - + + + Details about computational stesp how the zero-loss peak was threaded. + + + + The program with which the zero-loss peak correction was performed. + + + + - NXspectrum_set_em specialized for EELS. + Details about computational steps how peaks were indexed as elements. - - - - - - - - - Energy loss. - - - + + + The program with which the indexing was performed. + + + + + Name and location of each peak in the spectrum considered to be of relevance. + - - - - - Energy loss. - - - - - - - Energy loss. - - - + + + NXspectrum_set_em specialized for EELS. + - diff --git a/contributed_definitions/NXem_method.nxdl.xml b/contributed_definitions/NXem_method.nxdl.xml index 086d4833d2..cdd361f39d 100644 --- a/contributed_definitions/NXem_method.nxdl.xml +++ b/contributed_definitions/NXem_method.nxdl.xml @@ -41,7 +41,8 @@ - - - + + + + diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/contributed_definitions/NXscanbox_em.nxdl.xml index 56abc4f47b..444b2038f2 100644 --- a/contributed_definitions/NXscanbox_em.nxdl.xml +++ b/contributed_definitions/NXscanbox_em.nxdl.xml @@ -34,6 +34,20 @@ To achieve this task, the scanbox typically contains deflection coils, which should be modelled as instances of :ref:`NXdeflector`. + + + Name of the typically tech-partner-specific term that specifies + an automated protocol which controls the details how the components + of the microscope work together to achieve a controlled scanning of the + beam over the sample surface. + + In most cases users do not know, have to care, or are able to disentangle the + details of the spatiotemporal dynamics of the components of the microscope. + Instead, they rely on the assumption that the microscope and control software + work as expected. Selecting then a specific scan_schema assures some level + of reproducibility in the way how the beam is scanned over the surface. + + TODO discuss with the electron microscopists. @@ -54,7 +68,17 @@ TODO discuss with the electron microscopists. - + + + + Time period during which the beam remains at one position. + + TODO discuss with the electron microscopists. diff --git a/contributed_definitions/nyaml/NXebeam_column.yaml b/contributed_definitions/nyaml/NXebeam_column.yaml index 141250e339..adc568eb35 100644 --- a/contributed_definitions/nyaml/NXebeam_column.yaml +++ b/contributed_definitions/nyaml/NXebeam_column.yaml @@ -7,6 +7,17 @@ type: group # NXebeam_column is an NXobject instead of an NXcomponent_em to make that # part "an electron gun" reusable in other context NXebeam_column(NXobject): + operation_mode(NX_CHAR): + doc: | + Typically tech-partner, microscope-, and control software-specific + name of the specific operation mode how the ebeam_column and its + components are controlled to achieve a specific illumination condition. + + In most cases users do not know, have to care, or are able to disentangle the + details of the spatiotemporal dynamics of the components of the microscope. + Instead, they rely on the assumption that the microscope and control software + work as expected. Selecting then a specific operation_mode assures some level + of reproducibility in the illumination conditions. (NXchamber): (NXfabrication): electron_source(NXsource): diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index fbb13db13d..6a5eef662c 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -447,6 +447,7 @@ NXem(NXem_base): # collection(NXdata): em_lab(NXinstrument): (NXebeam_column): + operation_mode(NX_CHAR): electron_source(NXsource): voltage(NX_NUMBER): (NXibeam_column): @@ -454,6 +455,15 @@ NXem(NXem_base): ion_source(NXsource): probe(NXion): voltage(NX_NUMBER): + (NXscanbox_em): + exists: optional + scan_schema(NX_CHAR): + dwell_time(NX_NUMBER): + (NXstage_lab): + exists: optional + (NXdetector): + exists: optional + mode(NX_CHAR): # why at all do we need to add here (NXinstrument) ? # nyaml2nxdl could query the NXem_msr base class definition # and check if an identifier named em_lab exists in this case diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml index 89b9109bcb..77c194a693 100644 --- a/contributed_definitions/nyaml/NXem_eels.yaml +++ b/contributed_definitions/nyaml/NXem_eels.yaml @@ -1,42 +1,27 @@ category: base doc: | Base class method-specific for Electron Energy Loss Spectroscopy (EELS). -symbols: - n_energy_loss: | - Number of electron energy loss bins. +# symbols: + # n_energy_loss: Number of electron energy loss bins. type: group NXem_eels(NXem_method): # NXem_method also has an NXprocess which in this base class can be # specialized to include EELS-specific post-processing - (NXspectrum_set): + zlp_correction(NXprocess): doc: | - NXspectrum_set_em specialized for EELS. - # \@signal:, \@axes: \@energy_loss_indices \@axis_x_indices: - stack_oned(NXdata): - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - stack_oned(NXdata): - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - - summary(NXdata): - # \@signal: data_counts - # \@axes: [axis_energy_loss] - # \@energy_loss_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy loss. - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - # collection if needed can be composed from NXspectrum_set + Details about computational stesp how the zero-loss peak was threaded. + (NXprogram): + doc: | + The program with which the zero-loss peak correction was performed. + indexing(NXprocess): + doc: | + Details about computational steps how peaks were indexed as elements. + (NXprogram): + doc: | + The program with which the indexing was performed. + (NXpeak): + doc: | + Name and location of each peak in the spectrum considered to be of relevance. + (NXspectrum_set): + doc: | + NXspectrum_set_em specialized for EELS. diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml index afe91de973..31ca4520f9 100644 --- a/contributed_definitions/nyaml/NXem_method.yaml +++ b/contributed_definitions/nyaml/NXem_method.yaml @@ -16,6 +16,7 @@ NXem_method(NXobject): doc: | Details about processing steps. sequence_index(NX_INT): - IMAGE_R_SET(NXimage_r_set): - IMAGE_C_SET(NXimage_c_set): - SPECTRUM_SET(NXspectrum_set): + (NXimage_r_set): + (NXimage_c_set): + (NXspectrum_set): + # add links to relevant data diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml index 16c349ca58..3304728d37 100644 --- a/contributed_definitions/nyaml/NXem_msr.yaml +++ b/contributed_definitions/nyaml/NXem_msr.yaml @@ -43,6 +43,7 @@ NXem_msr(NXem_method): (NXebeam_column): (NXibeam_column): (NXoptical_system_em): + (NXscanbox_em): (NXdetector): doc: | Description of the type of the detector. diff --git a/contributed_definitions/nyaml/NXoptical_system_em.yaml b/contributed_definitions/nyaml/NXoptical_system_em.yaml index 5ed2c4be33..08c0152083 100644 --- a/contributed_definitions/nyaml/NXoptical_system_em.yaml +++ b/contributed_definitions/nyaml/NXoptical_system_em.yaml @@ -52,7 +52,6 @@ NXoptical_system_em(NXobject): beam_current_description(NX_CHAR): doc: | Specify further details how the beam current was measured or estimated. - # NEW ISSUE: the KIT/SCC propose: # adding of the image_mode or field mode # imageMode: enum: [normal_image, sad, eds, nbd, cbed] diff --git a/contributed_definitions/nyaml/NXscanbox_em.yaml b/contributed_definitions/nyaml/NXscanbox_em.yaml index 7fa3588434..0c5c2a6f27 100644 --- a/contributed_definitions/nyaml/NXscanbox_em.yaml +++ b/contributed_definitions/nyaml/NXscanbox_em.yaml @@ -12,6 +12,18 @@ doc: | which should be modelled as instances of :ref:`NXdeflector`. type: group NXscanbox_em(NXcomponent_em): + scan_schema(NX_CHAR): + doc: | + Name of the typically tech-partner-specific term that specifies + an automated protocol which controls the details how the components + of the microscope work together to achieve a controlled scanning of the + beam over the sample surface. + + In most cases users do not know, have to care, or are able to disentangle the + details of the spatiotemporal dynamics of the components of the microscope. + Instead, they rely on the assumption that the microscope and control software + work as expected. Selecting then a specific scan_schema assures some level + of reproducibility in the way how the beam is scanned over the surface. calibration_style(NX_CHAR): doc: | TODO discuss with the electron microscopists. @@ -27,7 +39,14 @@ NXscanbox_em(NXcomponent_em): doc: | TODO discuss with the electron microscopists. unit: NX_TIME - # pixel_dwell_time? + dwell_time(NX_NUMBER): + doc: | + Time period during which the beam remains at one position. + # xref: + # spec: EMglossary + # term: Dwell time + # url: https://em-glossary.vercel.app/term/em-dwell-time + unit: NX_TIME pixel_time(NX_NUMBER): doc: | TODO discuss with the electron microscopists. @@ -44,7 +63,6 @@ NXscanbox_em(NXcomponent_em): doc: | TODO discuss with the electron microscopists. (NXdeflector): - # (NXcg_point_set): # NEW ISSUE: build on work of EMglossary with HMC and use duty cycle instead # NEW ISSUE: make use of and define duty cycle From c1aa2e3e5086ae1a6c511b44d1c116f5b96ee381 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 17 Jan 2024 10:33:36 +0100 Subject: [PATCH 0510/1012] Placed version as child of definition --- contributed_definitions/NXapm.nxdl.xml | 12 ++++++------ contributed_definitions/nyaml/NXapm.yaml | 8 ++++---- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index 7f435aeed3..9ac2861e17 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -48,12 +48,6 @@ Application definition for atom probe and field ion microscopy experiments. - - - An at least as strong as SHA256 hashvalue of the - file which specifies the application definition. - - NeXus NXDL schema to which this file conforms. @@ -61,6 +55,12 @@ + + + An at least as strong as SHA256 hashvalue of the + file which specifies the application definition. + + diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml index 394f5386f1..fd1acbac51 100644 --- a/contributed_definitions/nyaml/NXapm.yaml +++ b/contributed_definitions/nyaml/NXapm.yaml @@ -19,14 +19,14 @@ type: group NXapm(NXobject): (NXentry): exists: [min, 1, max, infty] - \@version(NX_CHAR): - doc: | - An at least as strong as SHA256 hashvalue of the - file which specifies the application definition. definition(NX_CHAR): doc: | NeXus NXDL schema to which this file conforms. enumeration: [NXapm] + \@version(NX_CHAR): + doc: | + An at least as strong as SHA256 hashvalue of the + file which specifies the application definition. profiling(NXcs_profiling): doc: | The configuration of the I/O writer software (e.g. `pynxtools `_) From 23d34bc113f9e75504fb7f73a3cda0bd91e67d9f Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 17 Jan 2024 11:03:41 +0100 Subject: [PATCH 0511/1012] Added version as a child of definition, spotted what could be a bug though, if the NXDL contains only field defintion with attribute version, no docstrings for both and an enumeration make local succeeds, if you add docstrings for definition and version make local throws an NXDL logic error although these docstrings should be supported without problems --- contributed_definitions/nyaml/NXapm.yaml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml index fd1acbac51..5285c3bff9 100644 --- a/contributed_definitions/nyaml/NXapm.yaml +++ b/contributed_definitions/nyaml/NXapm.yaml @@ -20,13 +20,13 @@ NXapm(NXobject): (NXentry): exists: [min, 1, max, infty] definition(NX_CHAR): - doc: | - NeXus NXDL schema to which this file conforms. - enumeration: [NXapm] \@version(NX_CHAR): doc: | An at least as strong as SHA256 hashvalue of the file which specifies the application definition. + doc: | + NeXus NXDL schema to which this file conforms. + enumeration: [NXapm] profiling(NXcs_profiling): doc: | The configuration of the I/O writer software (e.g. `pynxtools `_) From 0a2bd84d861a2a3acdd98122798ccc005a7535c3 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 17 Jan 2024 11:04:49 +0100 Subject: [PATCH 0512/1012] Fixes and modifications revealed during implementation of imgs, apex readers --- .../NXebeam_column.nxdl.xml | 5 +- contributed_definitions/NXem.nxdl.xml | 81 ++++++++++--------- contributed_definitions/NXem_base.nxdl.xml | 14 ++-- contributed_definitions/NXem_eds.nxdl.xml | 32 +++++++- .../NXevent_data_em.nxdl.xml | 3 +- contributed_definitions/NXheater.nxdl.xml | 49 +++++++++++ .../NXoptical_system_em.nxdl.xml | 2 +- contributed_definitions/NXscanbox_em.nxdl.xml | 2 +- .../NXspectrum_set.nxdl.xml | 34 +++++++- contributed_definitions/NXstage_lab.nxdl.xml | 3 +- .../nyaml/NXebeam_column.yaml | 3 +- contributed_definitions/nyaml/NXem.yaml | 66 ++++++++------- contributed_definitions/nyaml/NXem_base.yaml | 8 +- contributed_definitions/nyaml/NXem_eds.yaml | 24 +++++- .../nyaml/NXevent_data_em.yaml | 1 + contributed_definitions/nyaml/NXheater.yaml | 22 +++++ .../nyaml/NXspectrum_set.yaml | 20 +++++ .../nyaml/NXstage_lab.yaml | 2 +- 18 files changed, 283 insertions(+), 88 deletions(-) create mode 100644 contributed_definitions/NXheater.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXheater.yaml diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml index b4c049c32c..26c13659a0 100644 --- a/contributed_definitions/NXebeam_column.nxdl.xml +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -3,7 +3,7 @@ - + @@ -119,4 +119,5 @@ relevant from maintenance point of view--> of the position at which the beam was probed. + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 99aae7951e..90dbd8f8ec 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -3,7 +3,7 @@ - - - - - - - - +a releasing of this default constraint is possible with writing exists: +\@NX_class: +\@file_time(NX_DATE_TIME): +\@file_name(NX_CHAR): +\@file_update_time(NX_DATE_TIME): +\@NeXus_version(NX_CHAR): +\@HDF5_Version(NX_CHAR): +\@h5py_version(NX_CHAR): +\@default(NX_CHAR):--> - + - + The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) which was used to generate this NeXus file instance. @@ -120,11 +120,11 @@ where scientists just store conventions without a default plot--> - Either an identifier or an alias that is human-friendly so that - scientist find that experiment again + Either an identifier or an alias that is human-friendly so + that scientists find that experiment again. - + @@ -134,7 +134,7 @@ where scientists just store conventions without a default plot--> - + @@ -144,7 +144,12 @@ where scientists just store conventions without a default plot--> - + + + + + + @@ -201,17 +206,19 @@ advantage--> - + + + - - + @@ -230,7 +237,6 @@ the fields they can be used--> - @@ -243,7 +249,6 @@ the fields they can be used--> - @@ -259,7 +264,6 @@ the fields they can be used--> - @@ -278,7 +282,6 @@ the fields they can be used--> - @@ -294,7 +297,6 @@ the fields they can be used--> - @@ -313,7 +315,6 @@ the fields they can be used--> - @@ -346,7 +347,6 @@ the fields they can be used--> - @@ -362,7 +362,6 @@ the fields they can be used--> - @@ -381,7 +380,6 @@ the fields they can be used--> - @@ -403,7 +401,6 @@ the fields they can be used--> - @@ -422,7 +419,6 @@ the fields they can be used--> - @@ -444,7 +440,6 @@ the fields they can be used--> - @@ -476,11 +471,22 @@ the fields they can be used--> + + + + + + + + + + + + - @@ -496,7 +502,6 @@ the fields they can be used--> - @@ -515,7 +520,6 @@ the fields they can be used--> - @@ -535,7 +539,7 @@ the fields they can be used--> - + @@ -556,6 +560,11 @@ the fields they can be used--> + + + + + diff --git a/contributed_definitions/NXem_base.nxdl.xml b/contributed_definitions/NXem_base.nxdl.xml index e1add30bda..8770ad4f69 100644 --- a/contributed_definitions/NXem_base.nxdl.xml +++ b/contributed_definitions/NXem_base.nxdl.xml @@ -3,7 +3,7 @@ - - - An at least as strong as SHA256 hashvalue of the file - which specifies the application definition. - - NeXus NXDL schema to which this file conforms. @@ -66,6 +60,12 @@ where scientists just store conventions without a default plot--> + + + An at least as strong as SHA256 hashvalue of the file + which specifies the application definition. + + diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml index 90b9262947..68db8267cb 100644 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -3,7 +3,7 @@ + Individual element-specific EDS/EDX/EDXS/SXES mapping @@ -168,6 +177,27 @@ and Adrien Teutrie, Cecile Hebert (EPFL)--> In this case specify the processing details using peaks and weights. + + + Discouraged free-text field to add additional information. + + + + + Comma-separated list of chemical_symbol-IUPAC X-ray (emission) line name that + documents which elements and their specific lines are theoretically located within + the energy_range of the spectrum from which the EDS (element) map has been computed. + + + + + Associated :math:`[e_{min}, e_{max}]` bounds of the energy + range for which spectrum counts have been accumulated. + + + + + diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml index 507c588ab4..c2921fcf28 100644 --- a/contributed_definitions/NXevent_data_em.nxdl.xml +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -3,7 +3,7 @@ + + + A device for heating. + + + + Nominal current of the heater. + + + + + Nominal voltage of the heater. + + + + + Nominal power of the heater. + + + + + Nominal resistance of the heater. + + + + diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/contributed_definitions/NXoptical_system_em.nxdl.xml index 022645efe8..8abc23abfa 100644 --- a/contributed_definitions/NXoptical_system_em.nxdl.xml +++ b/contributed_definitions/NXoptical_system_em.nxdl.xml @@ -3,7 +3,7 @@ + + + One spectrum for one pixel in a ROI aka spot measurement. + + + + Counts + + + + + + + + Counts + + + + + + Energy axis + + + + + + + Energy + + + + One spectrum for each pixel of an equidistantly diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index 95159e724c..1239e2a45c 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -3,7 +3,7 @@ + + + + Details about the control program used for operating the microscope. + + + + + + diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml index 4f619c79ef..e2c61800fb 100644 --- a/contributed_definitions/NXlens_em.nxdl.xml +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -3,7 +3,7 @@ + Given name, alias, colloquial, or short name for the lens. @@ -99,6 +101,16 @@ with other research fields (MPES, XPS, OPT) could be useful--> is available physically or accessible legally. + + + This field should be used when the exact operation mode of the lens + is not directly controllable as the control software of the microscope + does not enable or was not configured to display these values. + + Like value the mode can only be interpreted for a specific microscope + but can still be useful to guide users as to how to repeat the measurement. + + Specifies the position of the lens by pointing to the last transformation in the diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index 634eff229f..85c006ee6d 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -163,9 +163,17 @@ NXem(NXem_base): exists: recommended location(NX_CHAR): exists: recommended + control_program(NXprogram): + exists: recommended + doc: | + Details about the control program used for operating the microscope. + program(NX_CHAR): + \@version(NX_CHAR): (NXfabrication): vendor(NX_CHAR): model(NX_CHAR): + identifier(NX_CHAR): + exists: recommended (NXdetector): exists: [min, 0, max, infty] (NXfabrication): diff --git a/contributed_definitions/nyaml/NXlens_em.yaml b/contributed_definitions/nyaml/NXlens_em.yaml index b64a786dba..fb7c5b99bd 100644 --- a/contributed_definitions/nyaml/NXlens_em.yaml +++ b/contributed_definitions/nyaml/NXlens_em.yaml @@ -16,6 +16,8 @@ NXlens_em(NXobject): doc: | Qualitative type of lens with respect to the number of pole pieces. enumeration: [single, double, quadrupole, hexapole, octupole] + # purpose(NX_CHAR): + # enumeration: [c1, c2, diffraction, etc.] name(NX_CHAR): doc: | Given name, alias, colloquial, or short name for the lens. @@ -61,6 +63,14 @@ NXlens_em(NXobject): into a similar state to the technical level possible when no more information is available physically or accessible legally. unit: NX_ANY + mode(NX_CHAR): + doc: | + This field should be used when the exact operation mode of the lens + is not directly controllable as the control software of the microscope + does not enable or was not configured to display these values. + + Like value the mode can only be interpreted for a specific microscope + but can still be useful to guide users as to how to repeat the measurement. \@depends_on(NX_CHAR): doc: | Specifies the position of the lens by pointing to the last transformation in the From dcf6a9700b3c9004bd355bec422eefd3a2182c04 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 22 Jan 2024 11:00:52 +0100 Subject: [PATCH 0523/1012] add voltage_scan_range to NXenergydispersion --- .../NXenergydispersion.nxdl.xml | 7 +++++ contributed_definitions/NXmpes.nxdl.xml | 1 + .../nyaml/NXenergydispersion.yaml | 31 +++++++++++++------ contributed_definitions/nyaml/NXmpes.yaml | 19 +++++++----- 4 files changed, 42 insertions(+), 16 deletions(-) diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml index 364f0be756..4a0fecdebf 100644 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ b/contributed_definitions/NXenergydispersion.nxdl.xml @@ -142,6 +142,13 @@ Length of the tof drift electrode + + + Maximum/minimum voltage range of the energy dispersion, i.e., the voltage that is set on + the two hemispheres. If this range is set to `k` V, it means that the voltage can be varied + -`k` and `k` V. Influences the energy resolution. + + Size, position and shape of a slit in dispersive analyzer, e.g. entrance and diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index e69adde991..10874efe1c 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -293,6 +293,7 @@ + Size, position and shape of the entrance slit in dispersive analyzers. diff --git a/contributed_definitions/nyaml/NXenergydispersion.yaml b/contributed_definitions/nyaml/NXenergydispersion.yaml index bae609141c..31bac15d2f 100644 --- a/contributed_definitions/nyaml/NXenergydispersion.yaml +++ b/contributed_definitions/nyaml/NXenergydispersion.yaml @@ -38,8 +38,8 @@ NXenergydispersion(NXobject): energy_scan_mode(NX_CHAR): doc: | Way of scanning the energy axis - enumeration: - fixed_analyser_transmission: + enumeration: + fixed_analyser_transmission: doc: - | constant :math:`\Delta E` mode, where the electron retardation (i.e., the fraction of pass energy to @@ -58,7 +58,7 @@ NXenergydispersion(NXobject): spec: ISO 18115-1:2023 term: 12.64 url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.64 - fixed_retardation_ratio: + fixed_retardation_ratio: doc: - | constant :math:`\Delta E/E` mode, where the pass energy is scanned such that the electron retardation @@ -75,7 +75,7 @@ NXenergydispersion(NXobject): spec: ISO 18115-1:2023 term: 12.66 url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.66 - fixed_energy: + fixed_energy: doc: | In the fixed energy (FE) mode, the intensity for one single kinetic energy is measured for a specified time. This mode is particulary useful during setup or alignment of the @@ -86,7 +86,7 @@ NXenergydispersion(NXobject): is not of interest. Therefore, the signals from all channels are summed. Synonyms: FE mode - snapshot: + snapshot: doc: | Snapshot mode does not involve an energy scan and instead collects data from all channels of the detector without averaging. The resulting spectrum reflects the energy distribution of @@ -96,7 +96,7 @@ NXenergydispersion(NXobject): particularly suitable for CCD and DLD detectors, which have multiple channels and can accurately display the peak shape. While five or nine-channel detectors can also be used for snapshot measurements, their energy resolution is relatively lower. - dither: + dither: doc: | In dither acquisition mode, the kinetic energy of the analyzer is randomly varied by a small value around a central value and at fixed pass energy. This allows reducing or removing inhomogeneities @@ -106,6 +106,12 @@ NXenergydispersion(NXobject): unit: NX_LENGTH doc: | Length of the tof drift electrode + voltage_scan_range(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Maximum/minimum voltage range of the energy dispersion, i.e., the voltage that is set on + the two hemispheres. If this range is set to `k` V, it means that the voltage can be varied + -`k` and `k` V. Influences the energy resolution. (NXaperture): doc: | Size, position and shape of a slit in dispersive analyzer, e.g. entrance and @@ -133,7 +139,7 @@ NXenergydispersion(NXobject): the reference coordinate system. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 38a25da8f2f8fed6dff6737f8e320d907f7c1c804b49d151e7dcf526f4c3e110 +# 8085fec6b4fd2c46cfbe73186288cec3345d8383985940f7c417693f901825cd # # # - - - Version specifier of this application definition. - - - - NeXus NXDL schema with which this file was written. - - - - + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml index d227bc52bf..fe730e26b5 100644 --- a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml @@ -2,9 +2,9 @@ - - - Version specifier of this application definition. - - - - NeXus NXDL schema with which this file was written. - - - - + + + + + - - - - + + + + + - - NeXus NXDL schema to which this file conforms. - - - - - - An at least as strong as SHA256 hashvalue of the file - which specifies the application definition. - + + + diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index 85c006ee6d..112f62cfff 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -54,8 +54,8 @@ NXem(NXem_base): (NXentry): # means ENTRY(NXentry) exists: [min, 1, max, infty] definition(NX_CHAR): - enumeration: [NXem] \@version(NX_CHAR): + enumeration: [NXem] # each NeXus file instance should have a default plot # however as there are cases when this cannot be assured we cannot # make the default required, one example is e.g. a NeXus instance diff --git a/contributed_definitions/nyaml/NXem_base.yaml b/contributed_definitions/nyaml/NXem_base.yaml index d17ba24f7b..69c5f4967f 100644 --- a/contributed_definitions/nyaml/NXem_base.yaml +++ b/contributed_definitions/nyaml/NXem_base.yaml @@ -29,13 +29,8 @@ NXem_base(NXobject): # but should inherit from NXroot # where scientists just store conventions without a default plot (NXentry): # means ENTRY(NXentry) definition(NX_CHAR): - doc: | - NeXus NXDL schema to which this file conforms. - enumeration: [NXem] \@version(NX_CHAR): - doc: | - An at least as strong as SHA256 hashvalue of the file - which specifies the application definition. + enumeration: [NXem] cs_profiling(NXcs_profiling): doc: | The configuration of the I/O writer software (e.g. `pynxtools `_) From 3b266bf40af2b3957abd07b5824a592371ac3a7f Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 23 Jan 2024 11:47:30 +0100 Subject: [PATCH 0528/1012] Removed unfortunated row vector style matrix isotope_vector and nuclid list and made clarified that isotope_vector means indeed nuclid hashes and not isotopes (i.e. nuclids of same element) --- contributed_definitions/NXion.nxdl.xml | 47 ++++++++++++------------ contributed_definitions/nyaml/NXion.yaml | 38 ++++++++++--------- 2 files changed, 44 insertions(+), 41 deletions(-) diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index 1412d38fce..01c99f7416 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ - + - + + + - - - - - + + + + + + - + diff --git a/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml b/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml index 3b61911514..67eee6648b 100644 --- a/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml +++ b/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml @@ -2,9 +2,9 @@ - + Input constraint, list of proton numbers for each element of the ranging definition. The list contains each element as many times as its multiplicity. @@ -86,69 +85,70 @@ input/config--> - Input constraint, minimum half life for how long each nuclid of each + Input constraint, minimum half life for how long each nuclide of each (molecular) ion needs to be stable such that the ion qualifies as a candidate. - Input constraint, minimum natural abundance of each nuclid of each + Input constraint, minimum natural abundance of each nuclide of each (molecular) ion such that the ion qualifies as a candidate. If the value is false, it means that non-unique solutions are accepted. - These are solutions where multiple candidates have been built from different - nuclids but the charge_state of all the ions is the same. + These are solutions where multiple candidates have been built from + different nuclide instances but the charge_state of all the ions is the same. + - + - Signed charge, i.e. integer multiple of the elementary charge. + Signed charge, i.e. integer multiple of the elementary + charge of each candidate. - + - List of nuclids building each candidate. - Each list is sorted in descending order. - Unused values up to n_ivec_max are nullified. + Table of nuclide instances of which each candidate is composed. + Each row vector is sorted in descending order. Unused values are nullified. - + - Accumulated mass of the nuclids in each candidate. + Accumulated mass of the nuclides in each candidate. Not corrected for quantum effects. - + - The product of the natural abundances of the nuclids for each candidate. + The product of the natural abundances of the nuclides for each candidate. - + - For each candidate the half life of the nuclid with the shortest half life. + For each candidate the half life of that nuclide which has the shortest half + life. diff --git a/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml deleted file mode 100644 index 903fd73d9b..0000000000 --- a/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml +++ /dev/null @@ -1,297 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The number of isotopes to consider as building blocks for searching molecular - ions. - - - - - The number of compositions to consider for molecular ion search tasks. - - - - - Configuration of a paraprobe-ranger tool run in atom probe microscopy. - - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - How many task to perform? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A list of pairs of number of protons and either the value 0 (per row) - or the mass number for all those isotopes which are assumed present - in a virtual specimen. - The purpose of this field is to compute also composition-weighted - products to yield a simple estimation which could potentially help - scientists to judge if certain molecular ions are to be expected. - The corresponding setting store_composition_weighted_product should be - activated. - - - - - - - - - - A list of pairs of number of protons and mass number for all isotopes - to consider that can be composed into (molecular) ions, during the - recursive molecular_ion_search. - - - - - - - - - The mass-to-charge-state ratio interval in which - all molecular ions are searched. - - - - - - - - The maximum charge that a molecular ion should have. - - - - - The maximum number of isotopes of which the molecular ion - should be composed. Currently this must not be larger than 32. - - Users should be warned that the larger the maximum_charge and - especially the larger the maximum_number_of_isotopes is chosen, - the eventually orders of magnitude more costly the search becomes. - - This is because paraprobe-ranger computes really all (at least) - theoretically possible combinations that would have likely a - mass-to-charge-state ratio in the specified mass_to_charge_interval. - It is the challenge in atom probe to judge which of these (molecular) - ions are feasible and also practically possible. This tool does not - answer this question. - - Namely, which specific molecular ion will evaporate, remain stable - during flight and becomes detected is a complicated and in many cases - not yet in detail understood phenomenon. The ab-initio conditions - before and during launch, the local environment, arrangement and field - as well as the flight phase in an evacuated but not analysis chamber - with a complex electrical field, eventual laser pulsing in place, - temperature and remaining atoms or molecules all can have an effect - which iontypes are really physically evaporating and detected. - - - - - Report the accumulated atomic mass from each isotope building the ion. - Accounts for each identified ion. - Relatistic effects are not accounted for. - - - - - Report the product of the natural abundances from each isotope building - the ion. Accounts for each identified ion. - - The value zero indicates it is not possible to build such molecular ion - from nuclids which are all observationally stable. - Very small values can give an idea/about how likely such a molecular ion - is expected to form assuming equal probabilities. - - However in atom probe experiments this product has to be modified - by the (spatially-correlated) local composition in the region from - which the ions launch because the formation of a molecular ion depends - as summarized under maximum_number_of_isotopes on the specific - quantum-mechanical configuration and field state upon launch - or/and (early state) of flight respectively. - We are aware that this modified product can have a substantially - different value than the natural_abundance_product. - - Natural abundancies folded with the estimated compositions of the - specimen can differ by orders of magnitude. - - - - - - Report the charge state of the ions. - - - - - Report if identified ions should be characterized - wrt to their number of disjoint isotopes. - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml deleted file mode 100644 index fb4973f03b..0000000000 --- a/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml +++ /dev/null @@ -1,119 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Configurations of a paraprobe-transcoder tool run in atom probe microscopy. - - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ideally an ever persistent resource where the source code of the - program and build instructions can be found so that the program can be - configured ideally in such a manner that the result of this computational - process is recreatable deterministically. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - - - - The path and name of the file (technology partner or community format) - from which to read the reconstructed ion positions. Currently, POS, - ePOS, APT files from APSuite, and NXS, i.e. NeXus/HDF5 files - are supported. - - - - - - - - The path and name of the file (technology partner or community format - from which to read the ranging definitions, i.e. how to map mass-to- - charge-state ratios on iontypes. Currently, RRNG, RNG, and NXS, i.e. - NeXus/HDF5 files are supported. - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml index 79ce7b8e8a..0c330f4d69 100644 --- a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml @@ -62,8 +62,8 @@ - - + + diff --git a/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml deleted file mode 100644 index 9840e724c3..0000000000 --- a/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml +++ /dev/null @@ -1,425 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of ions in the reconstruction. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. - - - - - Results of a paraprobe-ranger tool run. - - - - - - Version specifier of this application definition. - - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - - - - - The path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - - - - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - - Paraprobe-ranger loads the iontypes and evaluates for each - ion on which iontype it matches. If it matches on none, the - ion is considered of the default unknown type with a 0 as its - respective value in the iontypes array. - - - - - The length of the isotope_vector used to describe molecular ions. - - - - - - - - - - - The iontype ID for each ion that was best matching, stored in the - order of the evaporation sequence ID. The here computed iontypes - do not take into account the charge state of the ion which is - equivalent to interpreting a RNG and RRNG range files for each - ion in such a way that only the elements of which a (molecular) ion - is build are considered. By contrast, charged_iontypes takes - into account also the charge state. - - - - - - - - A bitmask which identifies exactly all those ions ranged irrespective - the type they ended up with. - - - - Number of ions covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - - Paraprobe-ranger performs a combinatorial search over - all possible or a reduced set of nuclids to identify - into which ions these can be composed. - - - - The main result is the list of molecular ions, here formatted - according to the definitions of a set of isotope_vectors - as detailed in :ref:`NXion`. - - - - - - - - - The mass-to-charge-state ratio of each molecular ion - without considering relativistic or quantum effects. - - - - - - - - The mass of each molecular ion without - considering relativistic or quantum effects. - - - - - - - - - The charge_state of each molecular ion. - - - - - - - - The product of the natural abundance of the isotopes building - each molecular ion. Further details are available in - :ref:`NXapm_paraprobe_config_ranger`. - - - - - - - - The product of the natural abundance of the isotopes building - each molecular ion. Further details are available in - :ref:`NXapm_paraprobe_config_ranger`. - - - - - - - - The number of disjoint nuclids for each molecular ion. - - - - - - - - The number of nuclids for each molecular ion. - - - - - - - - - Paraprobe-ranger loads iontypes and evaluates for each ion on which - iontype it matches. If it matches on none, the ion is considered of - the default unknown type with a 0 as its respective value in the - iontypes array. In contrast to use_existent_ranging this process - does neither needs measured ion position nor mass-to-charge-state - ratio values. - - - - - The length of the isotope_vector used to describe molecular ions. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml deleted file mode 100644 index cdab497064..0000000000 --- a/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml +++ /dev/null @@ -1,568 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of ions in the reconstruction. - - - - - Maximum number of allowed atoms per (molecular) ion (fragment). - Needs to match maximum_number_of_atoms_per_molecular_ion. - - - - - Number of mass-to-charge-state-ratio intervals mapped on this ion type. - - - - - Total number of integers in the supplementary XDMF topology array. - - - - - Number of ions probed in the combinatorial analysis of the charge states - - - - - Results of a paraprobe-transcoder tool run. - - - - - - Version specifier of this application definition. - - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - - - - - The absolute path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - - - - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - - An array of triplets of integers which can serve as a supplementary - array for Paraview to display the reconstruction. The XDMF datatype - is here 1, the number of primitives 1 per triplet, the last integer - in each triplet is the identifier of each point starting from zero. - - - - - - - - - - On a mid term perspective we would like to evolve the paraprobe-toolbox - to an implementation stage where it works exclusively with completely - provenance-tracked formats for both the configuration of the workflow step - and/or analysis with each tool and also for the output of these analyses - in the form of so-called tool-specific results files. - Currently the Hierarchical Data Format 5 (HDF5) is used to store such data. - - Different file formats can be used to inject reconstructed datasets and - ranging definitions into the toolbox. Traditionally, these are the POS, - ePOS, and APT files with the tomographic reconstruction and other metadata - and RNG and RRNG file formats for the ranging definitions how mass-to-charge - state-ratio values map on (molecular) ion types. Such input should be - injected via specific NeXus/HDF5 files which are documented - in compliance with the NXapm application definition. - - So far the paraprobe-toolbox was used as a standalone tool. Therefore, it - was not relevant during the development to focus on interoperability. - Essentially paraprobe-transcoder was used as a parser to transcode data - in the above-mentioned file formats into a paraprobe-specific - representation. This transcoding should become deprecated. - Here we describe steps we have taken into this direction. - - With the work in the FAIRmat project and the desire to make the paraprobe- - toolbox also accessible as a cloud-computing capable service in the Nomad - Remote Tools Hub (NORTH) the topic of interoperability became more important - and eventually the NXapm application definition was proposed. - NORTH is a GUI and related service in a NOMAD OASIS instance which allows - to spawn preconfigured docker containers via JupyterHub. - Currently, NORTH includes the so-called apm container. A container with - tools specific for analyzing data from atom probe microscopy as well as - processing of point cloud and mesh data. - - The NXapm application definition and related implementation work within - NOMAD OASIS enabled users to parse content of POS, ePOS, APT, RNG, and - RRNG files, surplus key metadata from vendor-agnostic electronic lab notebook - solutions directly into NOMAD OASIS via the uploads section. - The process is automated and yields an NXapm-compliant NeXus/HDF5 file - inside the uploads section in return. - - With these improvements made there is no longer a need for - at least the - users of a NOMAD OASIS and NORTH instance to use the deprecated - PARAPROBE.Transcoder.Results.*.h5 files. Ideally, paraprobe should - automatically detect that the input can now be an NXapm-compliant NeXus/HDF5 - file and in response work with this file directly. - To remain compliant with users however who do not have or do not wish - to use a NOMAD OASIS or NXapm or NeXus at all right now, the solution is - as follows: - - Calling the configuration stage of paraprobe-transcoder is always mandatory. - It is always the first step of working with the toolbox. In this process - the user defines the input files. These can either be nxs i.e. the NXapm/NeXus/ - HDF5 file from e.g. the upload section, or such a file that was obtained from - a colleague with a NOMAD OASIS instance. - In all other cases, users can pass the reconstruction and ranging definitions - using the traditional POS, ePOS, or APT and RNG or RRNG file formats respectively. - - Based on which input the user delivers, the parmsetup-transcoder tool then - creates a configuration file PARAPROBE.Transcoder.Config.SimID.*.nxs and - informs the user whether the input was NeXus (and thus if all relevant - input is already available) or whether the paraprobe-transcoder tool needs - to be executed to convert the content of the vendor files first into a - format which paraprobe can provenance track and understand. - In the latter case, the PARAPROBE.Transcoder.Config.SimID.*.nxs file is - used to communicate to all subsequently used tools from which files - the tools can expect to find the reconstruction and ranging definitions. - - All subsequent analysis steps start also with a tool-specific configuration. - This configuration step reads in (among others) the - PARAPROBE.Transcoder.Config.SimID.*.nxs file from which the configuration - tool identifies automatically whether to read the reconstruction and ranging data - from PARAPROBE.Transcoder.Results.SimID.*.h5 or directly the NXapm-compliant - NeXus/HDF5 file that was created upon preparing the upload or the file shared - from a colleague. This design removes the need for unnecessary copies of the data. - Currently still though users should execute the transcoder step as it will - generate a supplementary XDMF topology field with which the data in either - the NeXus/HDF5 or the transcoded vendor files can be displayed using e.g. - Paraview. For this purpose XDMF is used. - - Of course ideally the APT community would at some point converge to use - a common data exchange file format. To this end, AMETEK/Cameca's APT file format - could be a good starting point but so far it is lacking a consistent way of - how to store generalized ranging definitions and post-processing results. - POS, ePOS, Rouen's ATO, as well as other so far used representations of data - like CSV or text files have, to the best of our current knowledge, no - concept of how to marry reconstruction and (optional) ranging data into - one self-descriptive format. - - This summarizes the rationale behind the current choices of the I/O for - paraprobe. Furthermore, this summarizes also why the fundamental design - of splitting an analysis always into steps of configuration (with parmsetup), - task execution (with the respective C/C++ or Python tool of the toolbox), - and post-processing (e.g. with autoreporter) is useful because it offers - a clear description of provenance tracking. This is a necessary step to make - atom probe microscopy data at all better aligned with the aims of the - FAIR principles. - - The internal organization of the data entries in the atom_probe group - in this application definition for paraprobe-transcoder results files - mirror the definitions of the NXapm for consistency reasons. - - - - - - Mass-to-charge-state ratio values. - - - - - - - - - - - - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - - - - - - - - - - - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - - - - - - - - - Details and results of the combinatorial analyses of this - range definition to identify the charge_state for an ion. - - - - Currently charge_state not charge! - - - - - - - - Specific isotopes building each candidate matching the range. - - - - - - - - - Accumulated mass of the isotopes in each candidate. - Not corrected for quantum effects. - - - - - - - - - Product of natural abundance of the isotopes per candidate. - - - - - - - - Filter criterion on the product of the natural abundances - computed from each isotope building the (molecular) ion. - Such a filter can be used to reduce the number of possible - molecular ions considered when trying to find a unique solution - to the question which charge_state does a molecular ion - within a given range and given combination of elements have. - - - - - Filter criterion on the minimum half life which all isotopes - building the (molecular) ion need to have to consider the - candidate. - Such a filter can be used to reduce the number of possible - molecular ions considered when trying to find a unique solution - to the question which charge_state does a molecular ion - within a given range and given combination of elements have. - - - - - - If the value is zero/false it means that non-unique solutions - are accepted. These are solutions where multiple candidates - differ in their isotopes but have the same charge. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml index fe730e26b5..5947c7dee2 100644 --- a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml @@ -133,8 +133,8 @@ be used with the tools of the paraprobe-toolbox.--> Details about how peaks are interpreted as ion types or not. - - + + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index 01c99f7416..62dcc6af57 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -26,7 +26,7 @@ The symbols used in the schema to specify e.g. dimensions of arrays. - + Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). @@ -61,35 +61,35 @@ The identifier zero is reserved for the special unknown ion type. - + - Vector of nuclid hash values. + Vector of nuclide hash values. Individual hash values :math:`H` is :math:`H = Z + N*256` with :math:`Z` encode the number of protons :math:`Z` and the number of neutrons :math:`N` - of each nuclid respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. + of each nuclide respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. The array is sorted in decreasing order. For the rationale behind this see `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + - + - Table which decodes the entries in nuclid_hash into a human-readable matrix of nuclids. - The first column specifies the nuclid mass number, i.e. using the hashvalues + Table which decodes the entries in nuclide_hash into a human-readable matrix of instances. + The first column specifies the nuclide mass number, i.e. using the hashvalues from the isotope_vector this is :math:`Z + N` or 0. The value 0 documents that no isotope-specific information about the element encoded is relevant. The second row specifies the number of protons :math:`Z` or 0. The value 0 in this case documents a placeholder or that no element-specific information is relevant. - Taking a carbon-14 nuclid as an example the mass number is 14. + Taking a carbon-14 nuclide as an example the mass number is 14. That is encoded as a value pair (14, 6) as one row of the table. - Therefore, this notation is the typical superscribed nuclid mass number + Therefore, this notation is the typical superscribed nuclide mass number and subscripted number of protons element notation e.g. :math:`^{14}C`. - The array is stored matching the order of nuclid_hash. + The array is stored matching the order of nuclide_hash. diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml index aaeb13cdf2..acf2ca64b1 100644 --- a/contributed_definitions/nyaml/NXapm.yaml +++ b/contributed_definitions/nyaml/NXapm.yaml @@ -924,23 +924,25 @@ NXapm(NXobject): \@version(NX_CHAR): (NXion): exists: [min, 1, max, 256] - isotope_vector(NX_UINT): + nuclide_hash(NX_UINT): charge_state(NX_INT): charge_state_analysis(NXapm_charge_state_analysis): exists: optional - # element_vector(NX_UINT): - # mass_to_charge_range(NX_FLOAT): + # config + element(NX_UINT): + mass_to_charge_range(NX_FLOAT): min_half_life(NX_FLOAT): min_abundance(NX_FLOAT): min_abundance_product(NX_FLOAT): sacrifice_isotopic_uniqueness(NX_BOOLEAN): - charge_state_vector(NX_INT): - isotope_matrix(NX_UINT): - mass_vector(NX_FLOAT): - natural_abundance_product_vector(NX_FLOAT): - min_half_life_vector(NX_FLOAT): + # results + charge_state(NX_INT): + nuclide_hash(NX_UINT): + mass(NX_FLOAT): + natural_abundance_product(NX_FLOAT): + shortest_half_life(NX_FLOAT): mass_to_charge_range(NX_FLOAT): - nuclid_list(NX_UINT): + nuclide_list(NX_UINT): exists: recommended name(NX_CHAR): exists: recommended diff --git a/contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml b/contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml index 0d8d82c029..584a397a1f 100644 --- a/contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml +++ b/contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml @@ -1,6 +1,6 @@ category: base doc: | - Base class to document an algorithm for recovering charge state and nuclid composition of a (molecular) ion. + Base class to document an algorithm for recovering charge state and nuclide composition of a (molecular) ion. Currently ranging definitions in the research field of atom probe face have limitations: @@ -12,9 +12,8 @@ doc: | mass-to-charge-state-ratio intervals surplus the composition of elements that build the (molecular) ion. 3. Therefore, classical ranging definitions demand a post-processing with an algorithm - which can identify the nuclids from which the (molecular) ion is constructed - and a charge state possibly recovered. - Combinatorial algorithms are used for this purpose. + which can identify nuclides from which the (molecular) ion is constructed + and a charge state possibly recovered. Combinatorial algorithms are used for this purpose. This base class documents the configuration and results of such an algorithm. symbols: @@ -28,9 +27,9 @@ type: group NXapm_charge_state_analysis(NXprocess): # Details and results of the combinatorial analyses of a ranging definition # to clarify (if possible) the charge_state of an ion and its (not necessarily) - # unique combination of nuclids contained including their multiplicity. + # unique combination of nuclides contained including their multiplicity. # input/config - element_vector(NX_UINT): + element(NX_UINT): doc: | Input constraint, list of proton numbers for each element of the ranging definition. The list contains each element as many times as its multiplicity. @@ -49,51 +48,52 @@ NXapm_charge_state_analysis(NXprocess): dim: (1, 2) min_half_life(NX_FLOAT): doc: | - Input constraint, minimum half life for how long each nuclid of each + Input constraint, minimum half life for how long each nuclide of each (molecular) ion needs to be stable such that the ion qualifies as a candidate. unit: NX_TIME min_abundance(NX_FLOAT): doc: | - Input constraint, minimum natural abundance of each nuclid of each + Input constraint, minimum natural abundance of each nuclide of each (molecular) ion such that the ion qualifies as a candidate. unit: NX_DIMENSIONLESS sacrifice_isotopic_uniqueness(NX_BOOLEAN): doc: | If the value is false, it means that non-unique solutions are accepted. - These are solutions where multiple candidates have been built from different - nuclids but the charge_state of all the ions is the same. + These are solutions where multiple candidates have been built from + different nuclide instances but the charge_state of all the ions is the same. # min_abundance_product(NX_FLOAT): # doc: | # For each candidate TO BE DEFINED. # unit: NX_DIMENSIONLESS # dim: (n_cand,) + # output/results # the n_cand can be 1 in which case all quantities below are scalar - charge_state_vector(NX_INT): + charge_state(NX_INT): doc: | - Signed charge, i.e. integer multiple of the elementary charge. + Signed charge, i.e. integer multiple of the elementary + charge of each candidate. unit: NX_UNITLESS dim: (n_cand,) - isotope_matrix(NX_UINT): + nuclide_hash(NX_UINT): doc: | - List of nuclids building each candidate. - Each list is sorted in descending order. - Unused values up to n_ivec_max are nullified. + Table of nuclide instances of which each candidate is composed. + Each row vector is sorted in descending order. Unused values are nullified. unit: NX_UNITLESS dim: (n_cand, n_ivec_max) - mass_vector(NX_FLOAT): + mass(NX_FLOAT): doc: | - Accumulated mass of the nuclids in each candidate. + Accumulated mass of the nuclides in each candidate. Not corrected for quantum effects. unit: NX_MASS dim: (n_cand,) - natural_abundance_product_vector(NX_FLOAT): + natural_abundance_product(NX_FLOAT): doc: | - The product of the natural abundances of the nuclids for each candidate. + The product of the natural abundances of the nuclides for each candidate. unit: NX_DIMENSIONLESS dim: (n_cand,) - min_half_life_vector(NX_FLOAT): + shortest_half_life(NX_FLOAT): doc: | - For each candidate the half life of the nuclid with the shortest half life. + For each candidate the half life of that nuclide which has the shortest half life. unit: NX_TIME dim: (n_cand,) diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml index 22d0ee7456..9eea688493 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml @@ -32,8 +32,8 @@ NXapm_paraprobe_ranger_results(NXobject): unit: NX_UNITLESS (NXion): exists: [min, 1, max, 256] - isotope_vector(NX_UINT): - nuclid_list(NX_UINT): + nuclide_hash(NX_UINT): + nuclide_list(NX_UINT): exists: recommended charge_state(NX_INT): mass_to_charge_range(NX_FLOAT): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml index 1fa7011121..5d4477108e 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml @@ -82,8 +82,8 @@ NXapm_paraprobe_transcoder_results(NXobject): Details about how peaks are interpreted as ion types or not. (NXion): exists: [min, 1, max, 256] - isotope_vector(NX_UINT): - nuclid_list(NX_UINT): + nuclide_hash(NX_UINT): + nuclide_list(NX_UINT): exists: recommended charge_state(NX_INT): mass_to_charge_range(NX_FLOAT): diff --git a/contributed_definitions/nyaml/NXion.yaml b/contributed_definitions/nyaml/NXion.yaml index 03be0bf95f..11daf57e8d 100644 --- a/contributed_definitions/nyaml/NXion.yaml +++ b/contributed_definitions/nyaml/NXion.yaml @@ -4,7 +4,7 @@ doc: | symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. - n_ivecmax: | + n_ivec_max: | Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). n_ranges: | Number of mass-to-charge-state-ratio range intervals for ion type. @@ -24,32 +24,32 @@ NXion(NXobject): The identifier zero is reserved for the special unknown ion type. unit: NX_UNITLESS - nuclid_hash(NX_UINT): + nuclide_hash(NX_UINT): doc: | - Vector of nuclid hash values. + Vector of nuclide hash values. Individual hash values :math:`H` is :math:`H = Z + N*256` with :math:`Z` encode the number of protons :math:`Z` and the number of neutrons :math:`N` - of each nuclid respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. + of each nuclide respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. The array is sorted in decreasing order. For the rationale behind this see `M. Kühbach et al. (2021) `_ unit: NX_UNITLESS - dim: (n_ivecmax,) - nuclid_list(NX_UINT): + dim: (n_ivec_max,) + nuclide_list(NX_UINT): doc: | - Table which decodes the entries in nuclid_hash into a human-readable matrix of nuclids. - The first column specifies the nuclid mass number, i.e. using the hashvalues + Table which decodes the entries in nuclide_hash into a human-readable matrix of instances. + The first column specifies the nuclide mass number, i.e. using the hashvalues from the isotope_vector this is :math:`Z + N` or 0. The value 0 documents that no isotope-specific information about the element encoded is relevant. The second row specifies the number of protons :math:`Z` or 0. The value 0 in this case documents a placeholder or that no element-specific information is relevant. - Taking a carbon-14 nuclid as an example the mass number is 14. + Taking a carbon-14 nuclide as an example the mass number is 14. That is encoded as a value pair (14, 6) as one row of the table. - Therefore, this notation is the typical superscribed nuclid mass number + Therefore, this notation is the typical superscribed nuclide mass number and subscripted number of protons element notation e.g. :math:`^{14}C`. - The array is stored matching the order of nuclid_hash. + The array is stored matching the order of nuclide_hash. unit: NX_UNITLESS dim: (n_ivecmax, 2) # color(NX_CHAR): diff --git a/manual/source/classes/contributed_definitions/apm-structure.rst b/manual/source/classes/contributed_definitions/apm-structure.rst index 1e8b361527..aec8883be3 100644 --- a/manual/source/classes/contributed_definitions/apm-structure.rst +++ b/manual/source/classes/contributed_definitions/apm-structure.rst @@ -10,8 +10,6 @@ Atom-probe tomography ApmBC StatusQuoApm ApmParaprobeAppDef - ApmParaprobeNewBC - .. _IntroductionApm: @@ -19,8 +17,7 @@ Introduction ############ Set of data schemas to describe the acquisition, i.e. measurement side, the extraction of hits from detector raw data, -steps to compute mass-to-charge state ratios from uncorrected time of flight data, the reconstruction, and the ranging, -i.e. identification of peaks in the mass-to-charge-state ratio histogram to detect (molecular) ions. +steps to compute mass-to-charge state ratios from uncorrected time of flight data, the reconstruction, and the ranging, i.e. identification of peaks in the mass-to-charge-state ratio histogram to detect (molecular) ions. The data schemas can be useful to generate data artifacts also for field-ion microscopy experiments. .. _ApmAppDef: @@ -29,7 +26,9 @@ Application Definition ###################### :ref:`NXapm`: - A general application definition with many detailed places for leaving metadata and computational steps described which are commonly used when reporting the measurement of atom probe data including also detector hit data, as well as how to proceed with reconstructing atom positions from these data, and how to store details about definitions made, which describe how mass-to-charge-state ratio values are mapped to iontypes in a process called ranging. + A general application definition with many detailed places for leaving metadata and computational steps described which are commonly used when reporting the measurement of atom probe data including also detector hit data, as well as how to proceed with reconstructing atom positions from these data, and how to store details about definitions made, which describe how mass-to-charge-state ratio values are mapped to iontypes in a process called ranging. The structure of the schema has been designed to also document a simulation of an atom probe + experiment. Having a combined schema for the measurement and the simulation is beneficial to document that + there are many similarities between the measurement and a computer simulation of it. .. _ApmBC: @@ -43,15 +42,15 @@ The following base classes are proposed to support modularizing the storage of p A chamber may offer a controlled atmosphere to execute an experiment and/or offer functionalities for storing and loading specimens. - :ref:`NXcoordinate_system_set` - A base class to describe different coordinate systems used and/or to be harmonized + :ref:`NXcoordinate_system_set`, :ref:`NXcoordinate_system`: + Base classes to describe different coordinate systems used and/or to be harmonized or transformed into one another when interpreting the dataset. :ref:`NXion`: A base class to describe molecular ions with an adjustable number of atoms/isotopes building each ion. For the usage in atom probe research the maximum number of atoms supported building a molecular ion is currently set to a maximum of 32. Suggestions made in reference `DOI: 10.1017/S1431927621012241 `_ are used to map isotope to hash values with - which all possible isotopes (stable, radioactive, or synthetically generated ones) can be described. + which all possible nuclides (stable, radioactive, or synthetically generated ones) can be described. :ref:`NXfabrication`: A base class to bundle manufacturer/technology-partner-specific details about @@ -84,17 +83,53 @@ Microscopy experiments, not only taking into account those performed on commerci data processing steps. Some of them are frequently applied on-the-fly. For now we represent these steps with specifically named instances of the :ref:`NXprocess` base class. -Data processing steps are essential to transform measurements into knowledge. Therefore, these steps -should be documented to enable reproducible research, ideally numerically, and learn how pieces of information are connected. -In what follows, an example is presented how an open-source community software can be modified to use descriptions -of these computational steps. +Several base classes were defined to document processing of atom probe data with established algorithms: + + :ref:`NXapm_hit_finding`: + A base class to describe hit finding algorithm. + + :ref:`NXapm_volt_and_bowl`: + A base class to describe the voltage-and-bowl correction. + + :ref:`NXapm_charge_state_analysis`: + A base class to document the resolving of the charge_state. + + :ref:`NXapm_reconstruction`: + A base class to document the tomographic reconstruction algorithm. + + :ref:`NXapm_ranging`: + A base class to document the ranging process. + + :ref:`NXapm_msr`, :ref:`NXapm_sim`: + Respective base classes that serve as templates to compose the :ref:`NXapm` application definition from. + +These base classes are examples that substantiate that data processing steps are essential to transform atom probe measurements or simulations into knowledge. Therefore, these steps should be documented +to enable reproducible research, if possible even numerical reproducibility of the results, +and learn how pieces of information are connected. In what follows, an example is presented how an +open-source community software can be modified to use descriptions of these computational steps. + +A detailed inspection of spatial and other type of filters frequently used in analysis of atom probe +data revealed that it is better to define atom-probe-agnostic reusable concepts for filters: + + :ref:`NXspatial_filter`: + A base class proposing how a point cloud can be spatially filtered in a specific yet general manner. + This base class takes advantage of :ref:`NXcg_ellipsoid_set`, :ref:`NXcg_cylinder_set`, + and :ref:`NXcg_hexahedron_set` to cater for commonly used geometric primitives in atom probe. + The primitives are used for defining the shape and extent of a region of interest (ROI). + + :ref:`NXsubsampling_filter`: + A base class for a filter that can also be used for specifying how entries + like ions can be filtered via sub-sampling. + + :ref:`NXmatch_filter`: + A base class for a filter that can also be used for specifying how entries + like ions can be filtered based on their type or other descriptors like hit multiplicity. The respective research software here is the `paraprobe-toolbox `_ The software is developed by `M. Kühbach et al. `_. For atom probe research the proposal can also serve as a blue print how computational steps of other software tool including commercial ones could be developed further to benefit from NeXus. - .. _IntroductionApmParaprobe: apmtools @@ -167,7 +202,17 @@ combined to generate new results. We are convinced that defining, documenting, using, and sharing application definitions is useful and future-proof strategy for software development and data analyses as it enables -automated provenance tracking which happens silently in the background +automated provenance tracking which happens silently in the background. + +Base classes have been defined to group common pieces of information for each tool of the +toolbox. These base classes are: + + :ref:`NXapm_paraprobe_tool_config`: + Common parts of configuration settings useful for several tools of the paraprobe-toolbox. + + :ref:`NXapm_paraprobe_tool_results`: + Common parts of results useful for several tools of the paraprobe-toolbox. + .. _ApmParaprobeAppDef: @@ -178,23 +223,17 @@ NXapm_paraprobe application definitions are in fact pairs of application definit One for the configuration (input) side and one for the results (output) side. For each tool one such pair is proposed: - :ref:`NXapm_paraprobe_config_transcoder`: - Configuration of paraprobe-transcoder - Load POS, ePOS, APSuite APT, RRNG, RNG, and NXapm HDF5 files. - - :ref:`NXapm_paraprobe_results_transcoder`: - Results of paraprobe-transcoder + :ref:`NXapm_paraprobe_transcoder_config`, :ref:`NXapm_paraprobe_transcoder_results`: + Configuration and the results respectively of the paraprobe-transcoder tool. + Load POS, ePOS, APSuite APT, RRNG, RNG, and NeXus NXapm files. Store reconstructed positions, ions, and charge states. - - :ref:`NXapm_paraprobe_config_ranger`: - Configuration of paraprobe-ranger + :ref:`NXapm_paraprobe_ranger_config`, :ref:`NXapm_paraprobe_ranger_results`: + Configuration and results respectively of the paraprobe-ranger tool. Apply ranging definitions and explore possible molecular ions. + Store applied ranging definitions and combinatorial analyses of possible iontypes. - :ref:`NXapm_paraprobe_results_ranger`: - Results of paraprobe-ranger - Store applied ranging definitions and combinatorial analyses of all possible iontypes. - +The definitions of the following tools remain to become refactored like those for the above-mentioned tools: :ref:`NXapm_paraprobe_config_selector`: Configuration of paraprobe-selector @@ -272,41 +311,3 @@ tool one such pair is proposed: :ref:`NXapm_paraprobe_results_clusterer`: Results of paraprobe-clusterer Store results of cluster analyses. - -.. _ApmParaprobeNewBC: - -Base Classes -############ - -We envision that the above-mentioned definitions can be useful not only to take -inspiration for other software tools in the field of atom probe but also to support -a discussion towards a stronger standardization of the vocabulary used. This is an -ongoing discussion in the field emission community `IFES `_. -We are happy for taking comments and suggestions. The use of base classes for atom probe -is motivated by the observation that the majority of data analyses in atom probe -use a common set of operations and conditions on the input data: - - :ref:`NXapm_input_reconstruction`: - A base class documenting from where reconstructed ion positions are imported. - - :ref:`NXapm_input_ranging`: - A base class documenting from where ranging definitions are imported. - The design of the ranging definitions is, thanks to :ref:`NXion`, so - general that all possible nuclids can be considered. - -A detailed inspection of spatial and other type of filters frequently used in analysis of atom probe -data revealed that it is better to define atom-probe-agnostic reusable concepts for filters: - - :ref:`NXspatial_filter`: - A base class proposing how a point cloud can be spatially filtered in a specific yet general manner. - This base class takes advantage of :ref:`NXcg_ellipsoid_set`, :ref:`NXcg_cylinder_set`, - and :ref:`NXcg_hexahedron_set` to cater for commonly used geometric primitives in atom probe. - The primitives are used for defining the shape and extent of a region of interest (ROI). - - :ref:`NXsubsampling_filter`: - A base class for a filter that can also be used for specifying how entries - like ions can be filtered via sub-sampling. - - :ref:`NXmatch_filter`: - A base class for a filter that can also be used for specifying how entries - like ions can be filtered based on their type or other descriptors like hit multiplicity. From 97456868946912b7544f741793a27da65388e3da Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 25 Jan 2024 12:40:12 +0100 Subject: [PATCH 0530/1012] Fixes and modifications specifically for paraprobe-toolbox tools: parmsetup-transcoder, parmsetup-ranger, parmsetup-selector, transcoder, ranger, reporter-transcoder, reporter-ranger --- .../NXapm_paraprobe_ranger_config.nxdl.xml | 41 +-- .../NXapm_paraprobe_ranger_results.nxdl.xml | 54 ++-- .../NXapm_paraprobe_selector_config.nxdl.xml | 128 ++++++++++ .../NXapm_paraprobe_tool_config.nxdl.xml | 3 + ...NXapm_paraprobe_transcoder_config.nxdl.xml | 19 +- ...Xapm_paraprobe_transcoder_results.nxdl.xml | 15 +- .../NXapm_paraprobe_config_selector.yaml | 240 ------------------ .../nyaml/NXapm_paraprobe_ranger_config.yaml | 36 +-- .../nyaml/NXapm_paraprobe_ranger_results.yaml | 45 ++-- .../NXapm_paraprobe_selector_config.yaml | 99 ++++++++ ... => NXapm_paraprobe_selector_results.yaml} | 0 .../nyaml/NXapm_paraprobe_tool_config.yaml | 3 + .../NXapm_paraprobe_transcoder_config.yaml | 14 +- .../NXapm_paraprobe_transcoder_results.yaml | 10 + 14 files changed, 376 insertions(+), 331 deletions(-) create mode 100644 contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_selector.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml rename contributed_definitions/nyaml/{NXapm_paraprobe_results_selector.yaml => NXapm_paraprobe_selector_results.yaml} (100%) diff --git a/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml index 3c92ed037f..f34e3b214e 100644 --- a/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml @@ -2,9 +2,9 @@ - + - - @@ -116,12 +117,16 @@ - - - - - - + + + + + + + + + + + + + + + + + Paraprobe-ranger loads the iontypes and evaluates for each @@ -55,31 +63,13 @@ ion is considered of the default unknown type with a 0 as its respective value in the iontypes array. - + The length of the isotope_vector used to describe molecular ions. - - - - - - - - - The iontype (identifier) for each ion that was best matching, stored - in the order of the evaporation sequence ID. The here computed iontypes - do not take into account the charge state of the ion which is - equivalent to interpreting a RNG and RRNG range files for each - ion in such a way that only the elements of which a (molecular) ion - was built are considered. - - - - - A bitmask which identifies exactly all those ions ranged @@ -115,13 +105,31 @@ + + + + + + + + + The iontype (identifier) for each ion that was best matching, stored + in the order of the evaporation sequence ID. The here computed iontypes + do not take into account the charge state of the ion which is + equivalent to interpreting a RNG and RRNG range files for each + ion in such a way that only the elements of which a (molecular) ion + was built are considered. + + + + + - diff --git a/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml new file mode 100644 index 0000000000..69dca9b1ab --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml @@ -0,0 +1,128 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Application definition for a configuration file of the paraprobe-selector tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + + + + + + + + + + + + This process identifies which of the points/ions in the datasets are + inside or on the surface of geometric primitives and meet optionally + specific other filtering constraints. + A typical use case of a roi_selection is to restrict analyses to specific regions + of the dataset, eventually regions with a complicated shape. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml index 097e29b8f4..23188544f5 100644 --- a/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml @@ -137,4 +137,7 @@ symbols: + + + diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml index 6187ba94f7..3f1df122fe 100644 --- a/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml @@ -2,9 +2,9 @@ - + @@ -54,19 +54,24 @@ official NeXus appdef headers--> + + Specification of the ranging definition file to use for this analysis. + - - + + + + + + - diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml index 5947c7dee2..e43fa8e34c 100644 --- a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml @@ -2,9 +2,9 @@ + + + + + + + + +be used with the tools of the paraprobe-toolbox. +results--> diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_selector.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_selector.yaml deleted file mode 100644 index d5c9ac4ed4..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_selector.yaml +++ /dev/null @@ -1,240 +0,0 @@ -category: application -doc: | - Configuration of a paraprobe-selector tool run in atom probe microscopy. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXapm_paraprobe_config_selector(NXobject): - (NXentry): - - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently - \@version: - doc: | - Version specifier of this application definition. - definition: - doc: | - Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_config_selector] - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: | - Possibility for leaving a free-text description about this analysis. - time_stamp(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - number_of_processes(NX_UINT): - unit: NX_UNITLESS - doc: | - How many roi_selection processes should the tool execute. - roi_selection(NXprocess): - exists: ['min', '1', 'max', '1'] - doc: | - This process identifies which of the points/ions in the datasets are - inside or on the surface of geometric primitives and meet optionally - specific other filtering constraints. - A typical use case of a roi_selection is to restrict analyses to - specific regions of the dataset, eventually regions with a complicated - shape. - dataset(NXapm_input_reconstruction): - filename: - \@version: - dataset_name_reconstruction: - dataset_name_mass_to_charge: - iontypes(NXapm_input_ranging): - filename: - \@version: - group_name_iontypes: - spatial_filter(NXspatial_filter): - windowing_method: - (NXcg_ellipsoid_set): - exists: optional - cardinality(NX_POSINT): - center(NX_NUMBER): - half_axes_radii(NX_NUMBER): - - # orientation(NX_NUMBER): - (NXcg_cylinder_set): - exists: optional - cardinality(NX_POSINT): - center(NX_NUMBER): - height(NX_NUMBER): - radii(NX_NUMBER): - (NXcg_hexahedron_set): - exists: optional - cardinality(NX_POSINT): - hexahedra(NXcg_face_list_data_structure): - vertices(NX_FLOAT): - evaporation_id_filter(NXsubsampling_filter): - exists: optional - linear_range_min_incr_max(NX_UINT): - iontype_filter(NXmatch_filter): - exists: optional - method: - match(NX_NUMBER): - hit_multiplicity_filter(NXmatch_filter): - exists: optional - method: - match(NX_NUMBER): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a75891867e7d1bca2385b3439e5cdca146d2036d6ee76fb381c3fac3f0579ecf -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Configuration of a paraprobe-selector tool run in atom probe microscopy. -# -# -# -# -# -# Version specifier of this application definition. -# -# -# -# -# Official NeXus NXDL schema with which this file was written. -# -# -# -# -# -# -# -# Given name of the program/software/tool with which this NeXus -# (configuration) file was generated. -# -# -# -# Ideally program version plus build number, or commit hash or description -# of ever persistent resources where the source code of the program and -# build instructions can be found so that the program can be configured -# ideally in such a manner that the result of this computational process -# is recreatable in the same deterministic manner. -# -# -# -# -# -# Ideally, a (globally persistent) unique identifier for referring -# to this analysis. -# -# -# -# -# Possibility for leaving a free-text description about this analysis. -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when this configuration file was created. -# -# -# -# -# How many roi_selection processes should the tool execute. -# -# -# -# -# This process identifies which of the points/ions in the datasets are -# inside or on the surface of geometric primitives and meet optionally -# specific other filtering constraints. -# A typical use case of a roi_selection is to restrict analyses to -# specific regions of the dataset, eventually regions with a complicated -# shape. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml index 59620b83dc..ff973825de 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml @@ -18,6 +18,7 @@ NXapm_paraprobe_ranger_config(NXobject): definition(NX_CHAR): \@version(NX_CHAR): enumeration: [NXapm_paraprobe_ranger_config] + apply_existent_ranging(NXapm_paraprobe_tool_config): exists: [min, 0, max, 1] (NXidentifier): @@ -29,6 +30,7 @@ NXapm_paraprobe_ranger_config(NXobject): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): + position(NX_CHAR): mass_to_charge(NX_CHAR): ranging(NXserialized): type(NX_CHAR): @@ -37,15 +39,15 @@ NXapm_paraprobe_ranger_config(NXobject): algorithm(NX_CHAR): ranging_definitions(NX_CHAR): spatial_filter(NXspatial_filter): - exists: optional windowing_method(NX_CHAR): - (NXcg_hexahedron_set): + hexahedron_set(NXcg_hexahedron_set): exists: optional dimensionality(NX_POSINT): cardinality(NX_POSINT): identifier_offset(NX_INT): hexahedra(NXcg_face_list_data_structure): - (NXcg_cylinder_set): + vertices(NX_UINT): + cylinder_set(NXcg_cylinder_set): exists: optional dimensionality(NX_POSINT): cardinality(NX_POSINT): @@ -53,7 +55,7 @@ NXapm_paraprobe_ranger_config(NXobject): center(NX_NUMBER): height(NX_NUMBER): radii(NX_NUMBER): - (NXcg_ellipsoid_set): + ellipsoid_set(NXcg_ellipsoid_set): exists: optional dimensionality(NX_POSINT): cardinality(NX_POSINT): @@ -61,19 +63,17 @@ NXapm_paraprobe_ranger_config(NXobject): center(NX_NUMBER): half_axes_radii(NX_NUMBER): orientation(NX_NUMBER): - (NXcg_polyhedron_set): + polyhedron_set(NXcg_polyhedron_set): exists: optional # TODO - (NXcs_filter_boolean_mask): + bitmask(NXcs_filter_boolean_mask): exists: optional number_of_objects(NX_UINT): bitdepth(NX_UINT): mask(NX_UINT): - # will this be a scalar if the next line is omitted? + # leave open if scalar or matrix # dim: (i,) identifier(NX_UINT): - # likewise so this one - # dim: (j,) evaporation_id_filter(NXsubsampling_filter): exists: optional min_incr_max(NX_INT): @@ -85,13 +85,17 @@ NXapm_paraprobe_ranger_config(NXobject): exists: optional method(NX_CHAR): match(NX_NUMBER): - profiling(NXcs_profiling): - exists: recommended - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - results_path(NX_CHAR): - exists: recommended - current_working_directory(NX_CHAR): + + + (NXprogram): + exists: [min, 0, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + profiling(NXcs_profiling): + exists: recommended + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + current_working_directory(NX_CHAR): # molecular_ion_search(NXapm_paraprobe_tool_config): # exists: ['min', '0', 'max', 'unbounded'] # # extent if needed diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml index 9eea688493..4e90291ffe 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml @@ -18,6 +18,14 @@ NXapm_paraprobe_ranger_results(NXobject): definition(NX_CHAR): \@version(NX_CHAR): enumeration: [NXapm_paraprobe_ranger_results] + # config + analysis_identifier(NX_UINT): + config(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + apply_existent_ranging(NXapm_paraprobe_tool_results): exists: [min, 0, max, 1] doc: | @@ -26,27 +34,11 @@ NXapm_paraprobe_ranger_results(NXobject): ion is considered of the default unknown type with a 0 as its respective value in the iontypes array. ##MK::number_of_ion_types(NX_POSINT): + # results maximum_number_of_atoms_per_molecular_ion(NX_POSINT): doc: | The length of the isotope_vector used to describe molecular ions. unit: NX_UNITLESS - (NXion): - exists: [min, 1, max, 256] - nuclide_hash(NX_UINT): - nuclide_list(NX_UINT): - exists: recommended - charge_state(NX_INT): - mass_to_charge_range(NX_FLOAT): - iontypes(NX_UINT): - doc: | - The iontype (identifier) for each ion that was best matching, stored - in the order of the evaporation sequence ID. The here computed iontypes - do not take into account the charge state of the ion which is - equivalent to interpreting a RNG and RRNG range files for each - ion in such a way that only the elements of which a (molecular) ion - was built are considered. - unit: NX_UNITLESS - dim: (n_ions,) window(NXcs_filter_boolean_mask): doc: | A bitmask which identifies exactly all those ions ranged @@ -75,14 +67,29 @@ NXapm_paraprobe_ranger_results(NXobject): multiple of the bitdepth. unit: NX_UNITLESS dim: (i,) + (NXion): + exists: [min, 1, max, 256] + nuclide_hash(NX_UINT): + nuclide_list(NX_UINT): + exists: recommended + charge_state(NX_INT): + mass_to_charge_range(NX_FLOAT): + iontypes(NX_UINT): + doc: | + The iontype (identifier) for each ion that was best matching, stored + in the order of the evaporation sequence ID. The here computed iontypes + do not take into account the charge state of the ion which is + equivalent to interpreting a RNG and RRNG range files for each + ion in such a way that only the elements of which a (molecular) ion + was built are considered. + unit: NX_UNITLESS + dim: (n_ions,) (NXprogram): profiling(NXcs_profiling): start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): status(NX_CHAR): - results_path(NX_CHAR): - exists: recommended current_working_directory(NX_CHAR): total_elapsed_time(NX_NUMBER): number_of_processes(NX_POSINT): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml new file mode 100644 index 0000000000..e7c423468f --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml @@ -0,0 +1,99 @@ +category: application +doc: | + Application definition for a configuration file of the paraprobe-selector tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXapm_paraprobe_selector_config(NXobject): + (NXentry): + exists: [min, 1, max, 1] + definition(NX_CHAR): + \@version(NX_CHAR): + enumeration: [NXapm_paraprobe_selector_config] + + roi_selection(NXapm_paraprobe_tool_config): + exists: [min, 0, max, 1] + doc: | + This process identifies which of the points/ions in the datasets are + inside or on the surface of geometric primitives and meet optionally + specific other filtering constraints. + A typical use case of a roi_selection is to restrict analyses to specific regions + of the dataset, eventually regions with a complicated shape. + (NXidentifier): + exists: optional + analysis_identifier(NX_UINT): + exists: recommended + reconstruction(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + position(NX_CHAR): + mass_to_charge(NX_CHAR): + ranging(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + ranging_definitions(NX_CHAR): + spatial_filter(NXspatial_filter): + windowing_method(NX_CHAR): + hexahedron_set(NXcg_hexahedron_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + hexahedra(NXcg_face_list_data_structure): + vertices(NX_UINT): + cylinder_set(NXcg_cylinder_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + height(NX_NUMBER): + radii(NX_NUMBER): + ellipsoid_set(NXcg_ellipsoid_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + half_axes_radii(NX_NUMBER): + orientation(NX_NUMBER): + polyhedron_set(NXcg_polyhedron_set): + exists: optional + # TODO + bitmask(NXcs_filter_boolean_mask): + exists: optional + number_of_objects(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + # leave open if scalar or matrix + # dim: (i,) + identifier(NX_UINT): + evaporation_id_filter(NXsubsampling_filter): + exists: optional + min_incr_max(NX_INT): + iontype_filter(NXmatch_filter): + exists: optional + method(NX_CHAR): + match(NX_NUMBER): + hit_multiplicity_filter(NXmatch_filter): + exists: optional + method(NX_CHAR): + match(NX_NUMBER): + + + (NXprogram): + exists: [min, 0, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + profiling(NXcs_profiling): + exists: recommended + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + current_working_directory(NX_CHAR): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_selector.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml similarity index 100% rename from contributed_definitions/nyaml/NXapm_paraprobe_results_selector.yaml rename to contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml index 737ffb2ccf..4a03db7dcd 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml @@ -93,3 +93,6 @@ NXapm_paraprobe_tool_config(NXprocess): doc: | Name of the (parent) node directly below which (in the hierarchy) the ranging definition for (molecular) ions are stored. + (NXspatial_filter): + (NXsubsampling_filter): + (NXmatch_filter): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml index 24e864073e..af062d3467 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml @@ -15,8 +15,9 @@ NXapm_paraprobe_transcoder_config(NXobject): definition(NX_CHAR): \@version(NX_CHAR): enumeration: [NXapm_paraprobe_transcoder_config] + transcode(NXapm_paraprobe_tool_config): - exists: [min, 0, max, 1] + exists: [min, 1, max, 1] (NXidentifier): exists: optional analysis_identifier(NX_UINT): @@ -29,17 +30,20 @@ NXapm_paraprobe_transcoder_config(NXobject): position(NX_CHAR): mass_to_charge(NX_CHAR): ranging(NXserialized): + doc: | + Specification of the ranging definition file to use for this analysis. type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): - ranging_definitions(NX_CHAR): # add spatial and other type of filters - # (NXprogram): + + (NXprogram): + exists: [min, 0, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): profiling(NXcs_profiling): exists: recommended start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): - results_path(NX_CHAR): - exists: recommended current_working_directory(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml index 5d4477108e..6ccbcbfdc3 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml @@ -42,6 +42,14 @@ NXapm_paraprobe_transcoder_results(NXobject): definition(NX_CHAR): \@version(NX_CHAR): enumeration: [NXapm_paraprobe_transcoder_results] + # config + analysis_identifier(NX_UINT): + config(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + atom_probe(NXapm_paraprobe_tool_results): # this is currently a trick but should in the future be renamed to have a one-to-one # representation equivalence of reconstructed position and mass-to-charge-state-ratio value @@ -50,6 +58,7 @@ NXapm_paraprobe_transcoder_results(NXobject): # supplementary material to a paper but here no longer reported as it is way too specific # APSuite, RRNG, RNG, and NeXus/HDF5 NXapm in such a way that they can # be used with the tools of the paraprobe-toolbox. + # results mass_to_charge_conversion(NXprocess): mass_to_charge(NX_FLOAT): doc: | @@ -90,6 +99,7 @@ NXapm_paraprobe_transcoder_results(NXobject): unit: NX_ANY # u dim: (i, 2) # (NXcharge_state_model): + (NXprogram): profiling(NXcs_profiling): start_time(NX_DATE_TIME): From 4b84b0862780047b4efce9fc415c5f2dcbf27e5c Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 25 Jan 2024 16:15:24 +0100 Subject: [PATCH 0531/1012] Added appdef for selector_results, reorganized where to place common configuration information to take advantage of base class inheritance in more places, fixed incorrect handling of definition and version --- contributed_definitions/NXapm.nxdl.xml | 13 +- .../NXapm_paraprobe_config_selector.nxdl.xml | 142 ----- .../NXapm_paraprobe_ranger_config.nxdl.xml | 33 +- .../NXapm_paraprobe_ranger_results.nxdl.xml | 210 ++----- .../NXapm_paraprobe_results_selector.nxdl.xml | 274 --------- .../NXapm_paraprobe_selector_config.nxdl.xml | 38 +- .../NXapm_paraprobe_selector_results.nxdl.xml | 108 ++++ .../NXapm_paraprobe_tool_config.nxdl.xml | 66 +-- .../NXapm_paraprobe_tool_results.nxdl.xml | 43 +- ...NXapm_paraprobe_transcoder_config.nxdl.xml | 34 +- ...Xapm_paraprobe_transcoder_results.nxdl.xml | 97 +-- contributed_definitions/NXem.nxdl.xml | 2 +- .../NXms_score_config.nxdl.xml | 18 +- .../NXms_score_results.nxdl.xml | 10 +- contributed_definitions/nyaml/NXapm.yaml | 2 +- .../nyaml/NXapm_paraprobe_ranger_config.yaml | 26 +- .../nyaml/NXapm_paraprobe_ranger_results.yaml | 189 ++---- .../NXapm_paraprobe_selector_config.yaml | 30 +- .../NXapm_paraprobe_selector_results.yaml | 555 ++---------------- .../nyaml/NXapm_paraprobe_tool_config.yaml | 52 +- .../nyaml/NXapm_paraprobe_tool_results.yaml | 36 +- .../NXapm_paraprobe_transcoder_config.yaml | 27 +- .../NXapm_paraprobe_transcoder_results.yaml | 86 +-- contributed_definitions/nyaml/NXem.yaml | 2 +- .../nyaml/NXms_score_config.yaml | 6 +- .../nyaml/NXms_score_results.yaml | 9 +- 26 files changed, 564 insertions(+), 1544 deletions(-) delete mode 100644 contributed_definitions/NXapm_paraprobe_config_selector.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_results_selector.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index d6c1fce871..e08bdd59eb 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Configuration of a paraprobe-selector tool run in atom probe microscopy. - - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - How many roi_selection processes should the tool execute. - - - - - This process identifies which of the points/ions in the datasets are - inside or on the surface of geometric primitives and meet optionally - specific other filtering constraints. - A typical use case of a roi_selection is to restrict analyses to - specific regions of the dataset, eventually regions with a complicated - shape. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml index f34e3b214e..8cc028aaa7 100644 --- a/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml @@ -45,12 +45,12 @@ - - - - - + + + + + @@ -69,6 +69,7 @@ + @@ -117,16 +118,18 @@ - - - - - - - - - - + + + + + + + + + + + - - - - - - - - + + Paraprobe-ranger loads the iontypes and evaluates for each - ion on which iontype it matches. If it matches on none, the - ion is considered of the default unknown type with a 0 - as its respective value in the iontypes array. + ion on which iontype it matches. If it matches on None, the + ion is considered of the default *unknown_type*. This iontype + is marked with a 0 in the iontypes array. - - - - The length of the isotope_vector used to describe molecular ions. - - + + + + + + + + - - A bitmask which identifies exactly all those ions ranged - irrespective of the assigned type. This information - can be used to numerically recover the ROI selection. - - - - Number of ions covered by the mask. - The mask value for most may be 0. - - - - - Number of bits assumed matching on a default datatype. - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - + + + + + @@ -117,25 +82,31 @@ results--> in the order of the evaporation sequence ID. The here computed iontypes do not take into account the charge state of the ion which is equivalent to interpreting a RNG and RRNG range files for each - ion in such a way that only the elements of which a (molecular) ion - was built are considered. + ion in such a way that only the those elements are considered of which + a (molecular) ion is assumed composed according to the NXion instances. + + + + + + + + + + + + + + + + - - - - - - - - - - - + @@ -161,101 +132,4 @@ results--> - - - diff --git a/contributed_definitions/NXapm_paraprobe_results_selector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_selector.nxdl.xml deleted file mode 100644 index 791323a938..0000000000 --- a/contributed_definitions/NXapm_paraprobe_results_selector.nxdl.xml +++ /dev/null @@ -1,274 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of ions in the reconstruction. - - - - - Results of a paraprobe-selector tool run. - - - - - - Version specifier of this application definition. - - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - - - - - The absolute path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - - - - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - - A bitmask which identifies which of the ions in the dataset - were selected to become included in the region-of-interest (ROI). - - - - Number of ions covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml index 69dca9b1ab..eb9ba02231 100644 --- a/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml @@ -34,20 +34,12 @@ - - - - - + + + + - - This process identifies which of the points/ions in the datasets are - inside or on the surface of geometric primitives and meet optionally - specific other filtering constraints. - A typical use case of a roi_selection is to restrict analyses to specific regions - of the dataset, eventually regions with a complicated shape. - @@ -65,6 +57,7 @@ + @@ -113,16 +106,17 @@ - - - - - - - - - - + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml new file mode 100644 index 0000000000..bc80afec93 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml @@ -0,0 +1,108 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + Application definition for results files of the paraprobe-selector tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + The purpose and need of the paraprobe-selector tool is to identify which reconstructed positions + are located inside or on the surface of a (possibly complicated) region-of-interest (ROI). + In addition, the tool allows to filter ions for properties. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml index 23188544f5..b590abf95c 100644 --- a/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml @@ -21,12 +21,6 @@ # # For further information, see http://www.nexusformat.org --> - Base class documenting the configuration used for a tool of the paraprobe-toolbox. @@ -66,34 +60,8 @@ symbols: reusage and clearer communication. - - - - Metadata of the computational process whereby this configuration was generated. - There is a special set of tools called paraprobe-parmsetup which can be used - to conveniently create HDF5 configuration files, i.e. instances. - - - - Path where the tool stores tool-specific results. If not specified, - results will be stored in the current working directory. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the creation of the configuration was started, - i.e. when the respective executable/tool was started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the creation of the configuration was - completed and the respective process of the tool exited. - - - + Specification of the tomographic reconstruction to use for this analysis. @@ -117,7 +85,7 @@ symbols: - + Specification of the ranging definitions to use for this analysis. @@ -137,7 +105,35 @@ symbols: + + + + + + Metadata of the computational process whereby this configuration was generated. + There is a special set of tools called paraprobe-parmsetup which can be used + to conveniently create configuration HDF5 files following the here NeXus appdef. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the creation of the configuration was started, + i.e. when the respective executable/tool was started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the creation of the configuration was + completed and the respective process of the tool exited. + + + diff --git a/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml index 5c2f632be6..1cb1314c9d 100644 --- a/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml @@ -47,6 +47,7 @@ symbols: using binary container formats. Currently, paraprobe-toolbox uses the Hierarchical Data Format 5 (HDF5). + @@ -61,18 +62,43 @@ symbols: - The configuration file that was used to parameterize the algorithms - which the tool executes. + The configuration file that was used to parameterize + the algorithms that this tool has executed. - - - + + + A bitmask which identifies all ions considered in the analysis. + + + + Number of ions covered by the mask. + By default, the total number of ions in the dataset. + + + - Path where the tool stores tool-specific results. If not specified, - results will be stored in the current working directory. + Number of bits assumed matching on a default datatype. + + + The mask. The length of the mask is an integer multiple of bitdepth. + In such case, padded bits are set to 0. + + + + + + + + + + ISO 8601 formatted time code with local time zone offset to UTC @@ -131,6 +157,5 @@ symbols: +workflow from the ifes_apt_tc_data_modeling library--> diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml index 3f1df122fe..5c4eaf6c97 100644 --- a/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml @@ -36,12 +36,12 @@ official NeXus appdef headers--> - - - - - + + + + + @@ -62,17 +62,19 @@ official NeXus appdef headers--> - - - - - - - - - - - + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml index e43fa8e34c..778c85aaa0 100644 --- a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml @@ -51,51 +51,54 @@ i be careful n_comb can vary for every instance of (NXion) !--> This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. The purpose and need of the paraprobe-transcoder tool is to create a standardized representation of reconstructed position and mass-to-charge-state-ratio values surplus other pieces of information - to enable working with atom probe data in reconstruction space. + to enable working with atom probe data in reconstruction space in the paraprobe-toolbox. This includes ranging definitions which map mass-to-charge-state ratio values onto iontypes. - So far the atom probe community has not yet agreed upon a comprehensive standardization for - information exchange especially when it comes to the communication of configurations and results - from analyses of atom probe data. Instead, different simplistic file formats are used, such as POS, - ePOS, APT, or RNG and RRNG. None of these formats, though, document the provenance of, and thus the - sequence in which certain analysis steps were performed or which specific input and - configuration was used. + + So far the atom probe community has not yet agreed upon a comprehensive standardization on how to + exchange information especially when it comes to the communication of configurations and results + from analyses of atom probe data. Instead, different simplistic file formats are used, such as POS, ePOS, + APT, or RNG and RRNG. None of these formats, though, are self-descriptive, standardize, or document + their origin and thus the sequence in which the file was generated during an analysis. Paraprobe-transcoder solves this limitation by interpreting the information content in such files and standardize the representation prior injection into the scientific data analysis tools of the toolbox. Therefore, the here proposed set of NeXus base classes and application definitions can be a useful - starting point that enable the atom probe community to take advantage of standardized information + starting point for the atom probe community to take advantage of standardized information exchange and improve the here proposed classes and concepts to become more inclusive. Paraprobe-transcoder uses a Python library developed based on efforts by members of the global atom probe community `International Field Emission Society (IFES) Atom Probe Technical Committee (APT TC) <https://www.github.com/atomprobe-tc/ifes_apt_tc_data_modeling>`_. This library offers the - actual low-level I/O operations and respective information interpretation. + actual low-level I/O operations and respective information interpretation of above-mentioned file formats. - - - - - - + + + + - - - - - - - - + - + + + + + + + + + + + By default the entire reconstructed volume is processed. + In this case, using window is also equivalent to an + NXspatial_filter that specified a window *entire_dataset*. + + + + + + @@ -154,21 +157,25 @@ results--> + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - + If used, metadata of at least the person who performed this analysis. diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index ed54c1afd5..9e074a9ef1 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -74,8 +74,8 @@ a releasing of this default constraint is possible with writing exists:--> - + diff --git a/contributed_definitions/NXms_score_config.nxdl.xml b/contributed_definitions/NXms_score_config.nxdl.xml index 30573be7e9..ad44095de8 100644 --- a/contributed_definitions/NXms_score_config.nxdl.xml +++ b/contributed_definitions/NXms_score_config.nxdl.xml @@ -1,10 +1,10 @@ - + - + @@ -43,15 +43,11 @@ Application definition to control a simulation with the SCORE model. - - - Version specifier of this application definition. - - - + Official NeXus NXDL schema with which this file was written. + diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index 55c4d0eb98..f1866cf248 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -80,17 +80,11 @@ inspect comments behind NXms--> * `M. Diehl et al. <https://doi.org/10.1088/1361-651X/ab51bd>`_ - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - + NeXus NXDL schema to which this file conforms. + diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml index acf2ca64b1..ef120feedf 100644 --- a/contributed_definitions/nyaml/NXapm.yaml +++ b/contributed_definitions/nyaml/NXapm.yaml @@ -21,7 +21,7 @@ NXapm(NXobject): exists: [min, 1, max, infty] definition(NX_CHAR): \@version(NX_CHAR): - enumeration: [NXapm] + enumeration: [NXapm] profiling(NXcs_profiling): doc: | The configuration of the I/O writer software (e.g. `pynxtools `_) diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml index ff973825de..c149561d0b 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml @@ -17,8 +17,8 @@ NXapm_paraprobe_ranger_config(NXobject): exists: [min, 1, max, 1] definition(NX_CHAR): \@version(NX_CHAR): - enumeration: [NXapm_paraprobe_ranger_config] - + enumeration: [NXapm_paraprobe_ranger_config] + # tool-specific apply_existent_ranging(NXapm_paraprobe_tool_config): exists: [min, 0, max, 1] (NXidentifier): @@ -38,6 +38,7 @@ NXapm_paraprobe_ranger_config(NXobject): checksum(NX_CHAR): algorithm(NX_CHAR): ranging_definitions(NX_CHAR): + # filter spatial_filter(NXspatial_filter): windowing_method(NX_CHAR): hexahedron_set(NXcg_hexahedron_set): @@ -86,16 +87,17 @@ NXapm_paraprobe_ranger_config(NXobject): method(NX_CHAR): match(NX_NUMBER): - - (NXprogram): - exists: [min, 0, max, infty] - program(NX_CHAR): - \@version(NX_CHAR): - profiling(NXcs_profiling): - exists: recommended - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - current_working_directory(NX_CHAR): + # tool-specific parameter + # profiling + (NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + profiling(NXcs_profiling): + exists: recommended + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + current_working_directory(NX_CHAR): # molecular_ion_search(NXapm_paraprobe_tool_config): # exists: ['min', '0', 'max', 'unbounded'] # # extent if needed diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml index 4e90291ffe..87eea152af 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml @@ -1,6 +1,6 @@ category: application doc: | - Application definition for results files of the paraprobe-transcoder tool. + Application definition for results files of the paraprobe-ranger tool. This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. The purpose and need of the paraprobe-ranger tool is to apply a given set of ranging definitions within @@ -17,56 +17,26 @@ NXapm_paraprobe_ranger_results(NXobject): exists: [min, 1, max, 1] definition(NX_CHAR): \@version(NX_CHAR): - enumeration: [NXapm_paraprobe_ranger_results] - # config - analysis_identifier(NX_UINT): - config(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - + enumeration: [NXapm_paraprobe_ranger_results] + # tasks apply_existent_ranging(NXapm_paraprobe_tool_results): - exists: [min, 0, max, 1] doc: | Paraprobe-ranger loads the iontypes and evaluates for each - ion on which iontype it matches. If it matches on none, the - ion is considered of the default unknown type with a 0 - as its respective value in the iontypes array. + ion on which iontype it matches. If it matches on None, the + ion is considered of the default *unknown_type*. This iontype + is marked with a 0 in the iontypes array. ##MK::number_of_ion_types(NX_POSINT): - # results - maximum_number_of_atoms_per_molecular_ion(NX_POSINT): - doc: | - The length of the isotope_vector used to describe molecular ions. - unit: NX_UNITLESS + analysis_identifier(NX_UINT): + config(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): window(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies exactly all those ions ranged - irrespective of the assigned type. This information - can be used to numerically recover the ROI selection. number_of_ions(NX_UINT): - doc: | - Number of ions covered by the mask. - The mask value for most may be 0. - unit: NX_UNITLESS bitdepth(NX_UINT): - doc: | - Number of bits assumed matching on a default datatype. - unit: NX_UNITLESS mask(NX_UINT): - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - unit: NX_UNITLESS - dim: (i,) + # results (NXion): exists: [min, 1, max, 256] nuclide_hash(NX_UINT): @@ -74,27 +44,34 @@ NXapm_paraprobe_ranger_results(NXobject): exists: recommended charge_state(NX_INT): mass_to_charge_range(NX_FLOAT): + name(NX_CHAR): + exists: optional iontypes(NX_UINT): doc: | The iontype (identifier) for each ion that was best matching, stored in the order of the evaporation sequence ID. The here computed iontypes do not take into account the charge state of the ion which is equivalent to interpreting a RNG and RRNG range files for each - ion in such a way that only the elements of which a (molecular) ion - was built are considered. + ion in such a way that only the those elements are considered of which + a (molecular) ion is assumed composed according to the NXion instances. unit: NX_UNITLESS dim: (n_ions,) - - (NXprogram): - profiling(NXcs_profiling): - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - status(NX_CHAR): - current_working_directory(NX_CHAR): - total_elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): + # profiling + (NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + profiling(NXcs_profiling): + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + status(NX_CHAR): + current_working_directory(NX_CHAR): + total_elapsed_time(NX_NUMBER): + exists: optional + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): + # global (NXuser): exists: [min, 0, max, infty] name(NX_CHAR): @@ -111,103 +88,3 @@ NXapm_paraprobe_ranger_results(NXobject): z(NX_NUMBER): unit: NX_LENGTH dim: (3,) - - # molecular_ion_search(NXprocess): - # exists: ['min', '0', 'max', '1'] - # doc: | - # Paraprobe-ranger performs a combinatorial search over - # all possible or a reduced set of nuclids to identify - # into which ions these can be composed. - # isotope_vector_matrix(NX_UINT): - # unit: NX_UNITLESS - # doc: | - # The main result is the list of molecular ions, here formatted - # according to the definitions of a set of isotope_vectors - # as detailed in :ref:`NXion`. - # dimensions: - # rank: 2 - # dim: [[1, i], [2, 32]] - # mass_to_charge_state_ratio(NX_FLOAT): - # unit: NX_ANY - # doc: | - # The mass-to-charge-state ratio of each molecular ion - # without considering relativistic or quantum effects. - # dimensions: - # rank: 1 - # dim: [[1, i]] - # mass(NX_FLOAT): - # exists: optional - # unit: NX_ANY - # doc: | - # The mass of each molecular ion without - # considering relativistic or quantum effects. - - # # \@units: amu - # dimensions: - # rank: 1 - # dim: [[1, i]] - # charge_state(NX_UINT): - # unit: NX_CHARGE - # doc: | - # The charge_state of each molecular ion. - # dimensions: - # rank: 1 - # dim: [[1, i]] - # natural_abundance_product(NX_FLOAT): - # exists: optional - # unit: NX_DIMENSIONLESS - # doc: | - # The product of the natural abundance of the isotopes building - # each molecular ion. Further details are available in - # :ref:`NXapm_paraprobe_config_ranger`. - # dimensions: - # rank: 1 - # dim: [[1, i]] - # composition_product(NX_FLOAT): - # exists: optional - # unit: NX_DIMENSIONLESS - # doc: | - # The product of the natural abundance of the isotopes building - # each molecular ion. Further details are available in - # :ref:`NXapm_paraprobe_config_ranger`. - # dimensions: - # rank: 1 - # dim: [[1, i]] - # number_of_disjoint_nuclids(NX_POSINT): - # exists: optional - # unit: NX_UNITLESS - # doc: | - # The number of disjoint nuclids for each molecular ion. - # dimensions: - # rank: 1 - # dim: [[1, i]] - # number_of_nuclids(NX_POSINT): - # exists: optional - # unit: NX_UNITLESS - # doc: | - # The number of nuclids for each molecular ion. - # dimensions: - # rank: 1 - # dim: [[1, i]] - # check_existent_ranging(NXprocess): - # exists: ['min', '0', 'max', '1'] - # doc: | - # Paraprobe-ranger loads iontypes and evaluates for each ion on which - # iontype it matches. If it matches on none, the ion is considered of - # the default unknown type with a 0 as its respective value in the - # iontypes array. In contrast to use_existent_ranging this process - # does neither needs measured ion position nor mass-to-charge-state - # ratio values. - - # ##MK::number_of_ion_types(NX_POSINT): - # maximum_number_of_atoms_per_molecular_ion(NX_POSINT): - # unit: NX_UNITLESS - # doc: | - # The length of the isotope_vector used to describe molecular ions. - # charged_ION(NXion): - # exists: ['min', '1', 'max', '256'] - # isotope_vector(NX_UINT): - # nuclid_list(NX_UINT): - # exists: recommended - # charge_state(NX_INT): - # mass_to_charge_range(NX_FLOAT): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml index e7c423468f..6a5c090e9b 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml @@ -12,16 +12,9 @@ NXapm_paraprobe_selector_config(NXobject): exists: [min, 1, max, 1] definition(NX_CHAR): \@version(NX_CHAR): - enumeration: [NXapm_paraprobe_selector_config] - + enumeration: [NXapm_paraprobe_selector_config] roi_selection(NXapm_paraprobe_tool_config): exists: [min, 0, max, 1] - doc: | - This process identifies which of the points/ions in the datasets are - inside or on the surface of geometric primitives and meet optionally - specific other filtering constraints. - A typical use case of a roi_selection is to restrict analyses to specific regions - of the dataset, eventually regions with a complicated shape. (NXidentifier): exists: optional analysis_identifier(NX_UINT): @@ -39,6 +32,7 @@ NXapm_paraprobe_selector_config(NXobject): checksum(NX_CHAR): algorithm(NX_CHAR): ranging_definitions(NX_CHAR): + # filter that are here tool-specific parameter spatial_filter(NXspatial_filter): windowing_method(NX_CHAR): hexahedron_set(NXcg_hexahedron_set): @@ -87,13 +81,13 @@ NXapm_paraprobe_selector_config(NXobject): method(NX_CHAR): match(NX_NUMBER): - - (NXprogram): - exists: [min, 0, max, infty] - program(NX_CHAR): - \@version(NX_CHAR): - profiling(NXcs_profiling): - exists: recommended - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - current_working_directory(NX_CHAR): \ No newline at end of file + # profiling + (NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + profiling(NXcs_profiling): + exists: recommended + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + current_working_directory(NX_CHAR): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml index 01e5d7073c..04f7393f3c 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml @@ -1,517 +1,64 @@ category: application doc: | - Results of a paraprobe-selector tool run. + Application definition for results files of the paraprobe-selector tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + The purpose and need of the paraprobe-selector tool is to identify which reconstructed positions + are located inside or on the surface of a (possibly complicated) region-of-interest (ROI). + In addition, the tool allows to filter ions for properties. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. n_ions: | The total number of ions in the reconstruction. type: group -NXapm_paraprobe_results_selector(NXobject): - - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently +NXapm_paraprobe_selector_results(NXobject): (NXentry): - exists: ['min', '1', 'max', '1'] - \@version: - doc: | - Version specifier of this application definition. - - ##MK::begin of the tool-specific section - definition: - doc: | - Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_results_selector] - - ##MK::end of the tool-specific section - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: | - Possibility for leaving a free-text description about this analysis. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - config_filename: - doc: | - The absolute path and name of the config file for this analysis. - \@version: - doc: | - At least SHA256 strong hash of the specific config_file for - tracking provenance. - status: - doc: | - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - enumeration: [success, failure] - (NXuser): - exists: recommended - doc: | - If used, contact information and eventually details - of at least the person who performed this analysis. - name: - affiliation: - exists: recommended - address: - exists: optional - email: - exists: recommended - orcid: - exists: recommended - orcid_platform: - exists: recommended - telephone_number: - exists: optional - role: - exists: recommended - social_media_name: - exists: optional - social_media_platform: - exists: optional - (NXcoordinate_system_set): - exists: optional - doc: | - Details about the coordinate system conventions used. - (NXtransformations): - exists: ['min', '1', 'max', 'unbounded'] - doc: | - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - ##MK::begin of the tool-specific section - (NXprocess): - exists: ['min', '0', 'max', '1'] + exists: [min, 1, max, 1] + definition(NX_CHAR): + \@version(NX_CHAR): + enumeration: [NXapm_paraprobe_selector_results] + # tasks + roi_selection(NXapm_paraprobe_tool_results): + analysis_identifier(NX_UINT): + config(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + # results window(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies which of the ions in the dataset - were selected to become included in the region-of-interest (ROI). number_of_ions(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of ions covered by the mask. - The mask value for most may be 0. - - # which does paraprobe use bitdepth(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). mask(NX_UINT): - unit: NX_UNITLESS - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - dimensions: - rank: 1 - dim: [[1, n_ions]] - - ##MK::end of the tool-specific section - performance(NXcs_profiling): - exists: recommended - command_line_call: - exists: optional - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - total_elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - (NXcs_computer): - exists: recommended - name: - exists: recommended - operating_system: - \@version: - uuid: - exists: optional - (NXcs_cpu): - exists: ['min', '0', 'max', 'unbounded'] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_gpu): - exists: ['min', '0', 'max', 'unbounded'] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_mm_sys): - exists: ['min', '0', 'max', '1'] - total_physical_memory(NX_NUMBER): - (NXcs_io_sys): - exists: ['min', '0', 'max', '1'] - (NXcs_io_obj): - exists: ['min', '1', 'max', 'unbounded'] - technology: - max_physical_capacity(NX_NUMBER): - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_profiling_event): - start_time(NX_DATE_TIME): - exists: optional - end_time(NX_DATE_TIME): - exists: optional - description: - elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - number_of_threads(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - number_of_gpus(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - max_virtual_memory_snapshot(NX_NUMBER): - exists: recommended - max_resident_memory_snapshot(NX_NUMBER): - exists: recommended - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2e31b6b35f88d64a75b245dc46eb1d9fb155c7d641a927710b53367d6395394e -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The total number of ions in the reconstruction. -# -# -# -# -# Results of a paraprobe-selector tool run. -# -# -# -# -# -# Version specifier of this application definition. -# -# -# -# -# -# Official NeXus NXDL schema with which this file was written. -# -# -# -# -# -# -# -# -# Given name of the program/software/tool with which this NeXus -# (configuration) file was generated. -# -# -# -# Ideally program version plus build number, or commit hash or description -# of ever persistent resources where the source code of the program and -# build instructions can be found so that the program can be configured -# ideally in such a manner that the result of this computational process -# is recreatable in the same deterministic manner. -# -# -# -# -# -# Ideally, a (globally persistent) unique identifier for referring -# to this analysis. -# -# -# -# -# Possibility for leaving a free-text description about this analysis. -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when the analysis behind this results file -# was started, i.e. the paraprobe-tool executable started as a process. -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when the analysis behind this results file -# were completed and the paraprobe-tool executable exited as a process. -# -# -# -# -# The absolute path and name of the config file for this analysis. -# -# -# -# At least SHA256 strong hash of the specific config_file for -# tracking provenance. -# -# -# -# -# -# A statement whether the paraprobe-tool executable managed to -# process the analysis or failed prematurely. -# -# This status is written to the results file after the end_time -# at which point the executable must not compute any analysis. -# Only when this status message is present and shows `success`, the -# user should consider the results. In all other cases it might be -# that the executable has terminated prematurely or another error -# occurred. -# -# -# -# -# -# -# -# -# If used, contact information and eventually details -# of at least the person who performed this analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Details about the coordinate system conventions used. -# -# -# -# The individual coordinate systems which should be used. -# Field names should be prefixed with the following controlled terms -# indicating which individual coordinate system is described: -# -# * paraprobe -# * lab -# * specimen -# * laser -# * leap -# * detector -# * recon -# -# -# -# -# -# -# -# A bitmask which identifies which of the ions in the dataset -# were selected to become included in the region-of-interest (ROI). -# -# -# -# Number of ions covered by the mask. -# The mask value for most may be 0. -# -# -# -# -# -# Number of bits assumed matching on a default datatype. -# (e.g. 8 bits for a C-style uint8). -# -# -# -# -# The unsigned integer array representing the content of the mask. -# If padding is used the padded bits are set to 0. The mask is for -# convenience always as large as the entire dataset as it will -# be stored compressed anyway. The convenience feature with this -# is that then the mask can be decoded with numpy and mirrored -# against the evaporation_id array and one immediately can filter -# out all points that were used by the paraprobe. -# The length of the array adds to the next unsigned integer -# if the number of ions in the dataset is not an integer -# multiple of the bitdepth. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Specify if it was different from the number_of_processes -# in the NXcs_profiling super class. -# -# -# -# -# -# Specify if it was different from the number_of_threads -# in the NXcs_profiling super class. -# -# -# -# -# -# Specify if it was different from the number_of_threads -# in the NXcs_profiling super class. -# -# -# -# -# -# -# -# -# + # profiling + (NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + profiling(NXcs_profiling): + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + status(NX_CHAR): + current_working_directory(NX_CHAR): + total_elapsed_time(NX_NUMBER): + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): + # global + (NXuser): + exists: [min, 0, max, infty] + name(NX_CHAR): + (NXcoordinate_system_set): + paraprobe(NXcoordinate_system): + type(NX_CHAR): + handedness(NX_CHAR): + x(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + y(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + z(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml index 4a03db7dcd..b8520eefaf 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml @@ -19,11 +19,6 @@ doc: | The configuration and results of a run of a tool from the toolbox is documented using binary container formats. Currently, paraprobe-toolbox uses the Hierarchical Data Format 5 (HDF5). -# container formats typically use graphs - trees to be more specific - to organize -# metadata and data. Information is granularized via labelled property graphs. -# symbols: -# doc: | -# The symbols used in the schema to specify e.g. dimensions of arrays. type: group NXapm_paraprobe_tool_config(NXprocess): # sequence_id is inherited from NXprocess @@ -39,27 +34,8 @@ NXapm_paraprobe_tool_config(NXprocess): Although offered here for convenience we strongly encourage to parameterize such descriptions as much as possible to support reusage and clearer communication. - (NXprogram): - profiling(NXcs_profiling): - doc: | - Metadata of the computational process whereby this configuration was generated. - There is a special set of tools called paraprobe-parmsetup which can be used - to conveniently create HDF5 configuration files, i.e. instances. - results_path(NX_CHAR): - doc: | - Path where the tool stores tool-specific results. If not specified, - results will be stored in the current working directory. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the creation of the configuration was started, - i.e. when the respective executable/tool was started as a process. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the creation of the configuration was - completed and the respective process of the tool exited. - + # tool-specific input, examples for definitions for common types of input granularized into this + # base class from which tool-specific appdefs inherit reconstruction(NXserialized): doc: | Specification of the tomographic reconstruction to use for this analysis. @@ -77,7 +53,7 @@ NXapm_paraprobe_tool_config(NXprocess): doc: | Name of the node which resolves the mass-to-charge-state-ratio values to use for this analysis. - iontypes(NXserialized): + ranging(NXserialized): doc: | Specification of the ranging definitions to use for this analysis. @@ -93,6 +69,28 @@ NXapm_paraprobe_tool_config(NXprocess): doc: | Name of the (parent) node directly below which (in the hierarchy) the ranging definition for (molecular) ions are stored. + # filters (NXspatial_filter): (NXsubsampling_filter): (NXmatch_filter): + # profiling + (NXprogram): + profiling(NXcs_profiling): + doc: | + Metadata of the computational process whereby this configuration was generated. + There is a special set of tools called paraprobe-parmsetup which can be used + to conveniently create configuration HDF5 files following the here NeXus appdef. + # results_path(NX_CHAR): + # doc: | + # Path where the tool stores tool-specific results. If not specified, + # results will be stored in the current working directory. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the creation of the configuration was started, + i.e. when the respective executable/tool was started as a process. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the creation of the configuration was + completed and the respective process of the tool exited. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tool_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tool_results.yaml index 79fa60efee..29fcc4ad4b 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tool_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tool_results.yaml @@ -24,6 +24,7 @@ doc: | # The symbols used in the schema to specify e.g. dimensions of arrays. type: group NXapm_paraprobe_tool_results(NXprocess): + # config section (NXidentifier): analysis_identifier(NX_UINT): doc: | @@ -34,14 +35,36 @@ NXapm_paraprobe_tool_results(NXprocess): Possibility for leaving a free-text description about this analysis. config(NXserialized): doc: | - The configuration file that was used to parameterize the algorithms - which the tool executes. + The configuration file that was used to parameterize + the algorithms that this tool has executed. + window(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies all ions considered in the analysis. + number_of_ions(NX_UINT): + doc: | + Number of ions covered by the mask. + By default, the total number of ions in the dataset. + unit: NX_UNITLESS + bitdepth(NX_UINT): + doc: | + Number of bits assumed matching on a default datatype. + unit: NX_UNITLESS + mask(NX_UINT): + doc: | + The mask. The length of the mask is an integer multiple of bitdepth. + In such case, padded bits are set to 0. + unit: NX_UNITLESS + dim: (i,) + + + # typically tool-specific section follows + # profiling section (NXprogram): profiling(NXcs_profiling): - results_path(NX_CHAR): - doc: | - Path where the tool stores tool-specific results. If not specified, - results will be stored in the current working directory. + # results_path(NX_CHAR): + # doc: | + # Path where the tool stores tool-specific results. If not specified, + # results will be stored in the current working directory. start_time(NX_DATE_TIME): doc: | ISO 8601 formatted time code with local time zone offset to UTC @@ -88,4 +111,3 @@ NXapm_paraprobe_tool_results(NXprocess): (NXtransformations): # add further fields coming from using the charge state recovery # workflow from the ifes_apt_tc_data_modeling library - ##MK::end of the tool-specific section diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml index af062d3467..cf7a4610f9 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml @@ -14,8 +14,8 @@ NXapm_paraprobe_transcoder_config(NXobject): # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently definition(NX_CHAR): \@version(NX_CHAR): - enumeration: [NXapm_paraprobe_transcoder_config] - + enumeration: [NXapm_paraprobe_transcoder_config] + # tool-specific transcode(NXapm_paraprobe_tool_config): exists: [min, 1, max, 1] (NXidentifier): @@ -36,14 +36,15 @@ NXapm_paraprobe_transcoder_config(NXobject): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): - # add spatial and other type of filters - - (NXprogram): - exists: [min, 0, max, infty] - program(NX_CHAR): - \@version(NX_CHAR): - profiling(NXcs_profiling): - exists: recommended - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - current_working_directory(NX_CHAR): + # tool-specific parameter + # filter + # profiling + (NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + profiling(NXcs_profiling): + exists: recommended + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + current_working_directory(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml index 6ccbcbfdc3..3862b0d4ac 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml @@ -5,24 +5,24 @@ doc: | This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. The purpose and need of the paraprobe-transcoder tool is to create a standardized representation of reconstructed position and mass-to-charge-state-ratio values surplus other pieces of information - to enable working with atom probe data in reconstruction space. + to enable working with atom probe data in reconstruction space in the paraprobe-toolbox. This includes ranging definitions which map mass-to-charge-state ratio values onto iontypes. - So far the atom probe community has not yet agreed upon a comprehensive standardization for - information exchange especially when it comes to the communication of configurations and results - from analyses of atom probe data. Instead, different simplistic file formats are used, such as POS, - ePOS, APT, or RNG and RRNG. None of these formats, though, document the provenance of, and thus the - sequence in which certain analysis steps were performed or which specific input and - configuration was used. + + So far the atom probe community has not yet agreed upon a comprehensive standardization on how to + exchange information especially when it comes to the communication of configurations and results + from analyses of atom probe data. Instead, different simplistic file formats are used, such as POS, ePOS, + APT, or RNG and RRNG. None of these formats, though, are self-descriptive, standardize, or document + their origin and thus the sequence in which the file was generated during an analysis. Paraprobe-transcoder solves this limitation by interpreting the information content in such files and standardize the representation prior injection into the scientific data analysis tools of the toolbox. Therefore, the here proposed set of NeXus base classes and application definitions can be a useful - starting point that enable the atom probe community to take advantage of standardized information + starting point for the atom probe community to take advantage of standardized information exchange and improve the here proposed classes and concepts to become more inclusive. Paraprobe-transcoder uses a Python library developed based on efforts by members of the global atom probe community `International Field Emission Society (IFES) Atom Probe Technical Committee (APT TC) `_. This library offers the - actual low-level I/O operations and respective information interpretation. + actual low-level I/O operations and respective information interpretation of above-mentioned file formats. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -36,28 +36,30 @@ symbols: # i be careful n_comb can vary for every instance of (NXion) ! type: group NXapm_paraprobe_transcoder_results(NXobject): - # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently (NXentry): exists: [min, 1, max, 1] definition(NX_CHAR): \@version(NX_CHAR): - enumeration: [NXapm_paraprobe_transcoder_results] - # config - analysis_identifier(NX_UINT): - config(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - + enumeration: [NXapm_paraprobe_transcoder_results] + # tasks atom_probe(NXapm_paraprobe_tool_results): - # this is currently a trick but should in the future be renamed to have a one-to-one - # representation equivalence of reconstructed position and mass-to-charge-state-ratio value - # arrays such that - # the doc-string of the concept atom_probe(NXinstrument) should be used for - # supplementary material to a paper but here no longer reported as it is way too specific - # APSuite, RRNG, RNG, and NeXus/HDF5 NXapm in such a way that they can - # be used with the tools of the paraprobe-toolbox. + # this group mirrors the NXapm application definition + # config + analysis_identifier(NX_UINT): + config(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + window(NXcs_filter_boolean_mask): + exists: optional + doc: | + By default the entire reconstructed volume is processed. + In this case, using window is also equivalent to an + NXspatial_filter that specified a window *entire_dataset*. + number_of_ions(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): # results mass_to_charge_conversion(NXprocess): mass_to_charge(NX_FLOAT): @@ -98,21 +100,23 @@ NXapm_paraprobe_transcoder_results(NXobject): mass_to_charge_range(NX_FLOAT): unit: NX_ANY # u dim: (i, 2) - # (NXcharge_state_model): - - (NXprogram): - profiling(NXcs_profiling): - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - status(NX_CHAR): - results_path(NX_CHAR): - exists: recommended - current_working_directory(NX_CHAR): - total_elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - # use more detailed constraint set to describe a computer + # (NXapm_charge_state_analysis): + # profiling + (NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + profiling(NXcs_profiling): + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + status(NX_CHAR): + current_working_directory(NX_CHAR): + total_elapsed_time(NX_NUMBER): + exists: optional + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): + # global (NXuser): exists: [min, 0, max, infty] doc: | diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index fbb13db13d..5a41fe87f8 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -53,8 +53,8 @@ NXem(NXem_base): \@default(NX_CHAR): (NXentry): # means ENTRY(NXentry) exists: [min, 1, max, infty] - \@version(NX_CHAR): definition(NX_CHAR): + \@version(NX_CHAR): enumeration: [NXem] # each NeXus file instance should have a default plot # however as there are cases when this cannot be assured we cannot diff --git a/contributed_definitions/nyaml/NXms_score_config.yaml b/contributed_definitions/nyaml/NXms_score_config.yaml index 3e5bbba0e8..6a4d7f731d 100644 --- a/contributed_definitions/nyaml/NXms_score_config.yaml +++ b/contributed_definitions/nyaml/NXms_score_config.yaml @@ -11,12 +11,10 @@ symbols: type: group NXms_score_config(NXobject): (NXentry): - \@version: - doc: | - Version specifier of this application definition. - definition: + definition(NX_CHAR): doc: | Official NeXus NXDL schema with which this file was written. + \@version(NX_CHAR): enumeration: [NXms_score_config] PROGRAM(NXprogram): program_name: diff --git a/contributed_definitions/nyaml/NXms_score_results.yaml b/contributed_definitions/nyaml/NXms_score_results.yaml index 2996c7d7c7..cb591d0b64 100644 --- a/contributed_definitions/nyaml/NXms_score_results.yaml +++ b/contributed_definitions/nyaml/NXms_score_results.yaml @@ -35,15 +35,10 @@ symbols: type: group NXms_score_results(NXobject): (NXentry): - \@version: - doc: | - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - # enumeration: [sha_256_hash] - definition: + definition(NX_CHAR): doc: | NeXus NXDL schema to which this file conforms. + \@version(NX_CHAR): enumeration: [NXms_score_results] analysis_identifier: doc: | From 0d40eceda733aab9712bf7768d3eab3991d1a713 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 26 Jan 2024 01:04:02 +0100 Subject: [PATCH 0532/1012] Reorganized transcoder, ranger, selector --- .../NXapm_paraprobe_ranger_config.nxdl.xml | 2 +- .../NXapm_paraprobe_ranger_results.nxdl.xml | 2 +- .../NXapm_paraprobe_selector_config.nxdl.xml | 2 +- .../NXapm_paraprobe_selector_results.nxdl.xml | 2 +- .../nyaml/NXapm_paraprobe_ranger_config.yaml | 4 ++-- .../nyaml/NXapm_paraprobe_ranger_results.yaml | 2 +- .../nyaml/NXapm_paraprobe_selector_config.yaml | 4 ++-- .../nyaml/NXapm_paraprobe_selector_results.yaml | 2 +- 8 files changed, 10 insertions(+), 10 deletions(-) diff --git a/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml index 8cc028aaa7..c994514b5f 100644 --- a/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml @@ -51,7 +51,7 @@ - + diff --git a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml index ff806249d0..a934d572da 100644 --- a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml @@ -48,7 +48,7 @@ - + Paraprobe-ranger loads the iontypes and evaluates for each ion on which iontype it matches. If it matches on None, the diff --git a/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml index eb9ba02231..3986479ad7 100644 --- a/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml @@ -39,7 +39,7 @@ - + diff --git a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml index bc80afec93..0d2ba23c10 100644 --- a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml @@ -48,7 +48,7 @@ - + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml index c149561d0b..421b0ecdc2 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml @@ -19,8 +19,8 @@ NXapm_paraprobe_ranger_config(NXobject): \@version(NX_CHAR): enumeration: [NXapm_paraprobe_ranger_config] # tool-specific - apply_existent_ranging(NXapm_paraprobe_tool_config): - exists: [min, 0, max, 1] + range(NXapm_paraprobe_tool_config): + exists: [min, 1, max, 1] (NXidentifier): exists: optional analysis_identifier(NX_UINT): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml index 87eea152af..1e53aecd50 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml @@ -19,7 +19,7 @@ NXapm_paraprobe_ranger_results(NXobject): \@version(NX_CHAR): enumeration: [NXapm_paraprobe_ranger_results] # tasks - apply_existent_ranging(NXapm_paraprobe_tool_results): + iontypes(NXapm_paraprobe_tool_results): doc: | Paraprobe-ranger loads the iontypes and evaluates for each ion on which iontype it matches. If it matches on None, the diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml index 6a5c090e9b..2e6ce41079 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml @@ -13,8 +13,8 @@ NXapm_paraprobe_selector_config(NXobject): definition(NX_CHAR): \@version(NX_CHAR): enumeration: [NXapm_paraprobe_selector_config] - roi_selection(NXapm_paraprobe_tool_config): - exists: [min, 0, max, 1] + select(NXapm_paraprobe_tool_config): + exists: [min, 1, max, 1] (NXidentifier): exists: optional analysis_identifier(NX_UINT): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml index 04f7393f3c..d1e1d5712c 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml @@ -19,7 +19,7 @@ NXapm_paraprobe_selector_results(NXobject): \@version(NX_CHAR): enumeration: [NXapm_paraprobe_selector_results] # tasks - roi_selection(NXapm_paraprobe_tool_results): + roi(NXapm_paraprobe_tool_results): analysis_identifier(NX_UINT): config(NXserialized): type(NX_CHAR): From a172c01a921dbf9f5af4b6491ee28c843cb57d05 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 26 Jan 2024 18:13:27 +0100 Subject: [PATCH 0533/1012] Refactored surfacer to use APMv2 --- .../NXapm_paraprobe_ranger_results.nxdl.xml | 3 +- .../NXapm_paraprobe_selector_config.nxdl.xml | 2 +- .../NXapm_paraprobe_surfacer_config.nxdl.xml | 229 +++++ .../NXapm_paraprobe_surfacer_results.nxdl.xml | 270 +++++ .../NXapm_paraprobe_config_surfacer.yaml | 509 ---------- .../nyaml/NXapm_paraprobe_ranger_results.yaml | 1 + .../NXapm_paraprobe_results_surfacer.yaml | 935 ------------------ .../NXapm_paraprobe_selector_config.yaml | 2 +- .../NXapm_paraprobe_surfacer_config.yaml | 167 ++++ .../NXapm_paraprobe_surfacer_results.yaml | 180 ++++ .../contributed_definitions/apm-structure.rst | 10 +- .../icme-structure.rst | 13 +- 12 files changed, 858 insertions(+), 1463 deletions(-) create mode 100644 contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_surfacer_config.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml diff --git a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml index a934d572da..5877720dce 100644 --- a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml @@ -55,7 +55,8 @@ ion is considered of the default *unknown_type*. This iontype is marked with a 0 in the iontypes array. - + diff --git a/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml index 3986479ad7..a9ec6aa570 100644 --- a/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml @@ -57,7 +57,7 @@ - + diff --git a/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml new file mode 100644 index 0000000000..a31d15d6ed --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml @@ -0,0 +1,229 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of alpha values (and offset values) to probe. + + + + + How many different match values does the filter specify. + + + + + Application definition for a configuration file of the paraprobe-surfacer tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specifies the method that is used to preprocess the point cloud + prior to the alpha-shape computation. + + The option *default* specifies that no such filtering is applied. + The option *kuehbach* specifies that a Hoshen-Kopelman + percolation analysis is used to identify points that lie closer + to the edge of the dataset. Details about the methods are reported + in `M. Kühbach et al. <https://doi.org/10.1038/s41524-020-00486-1>`_. + + + + + + + + + When using the kuehbach preprocessing, this is the width of the + kernel for identifying which ions are in voxels close to the + edge of the point cloud. + + + + + + Specifies which method to use to define the alpha value. + + The value *convex_hull_naive* is the default. The setting instructs + the tool to use a fast specialized algorithm for computing only + the convex hull. The resulting triangles can be skinny. + + The value *convex_hull_refine* instructs to tool to refine the + quality of the mesh resulting from *convex_hull_naive* + via triangle flipping and splitting. + + The value *smallest_solid* instructs the CGAL library to choose a + value which realizes an alpha-shape that is the smallest solid. + + The value *cgal_optimal* instructs the CGAL library to choose a + value which the library considers as to be an optimal value. + Details are defined in the respective section of the CGAL library + on 3D alpha shapes. + + The value *set_of_values* instructs the tool to compute a list + collection of alpha-shapes for the specified alpha-values. + + The value *set_of_alpha_wrappings* instructs the tool to generate + a set of so-called alpha wrappings. These are similar to alpha-shapes + but provide additional guarantees (such as watertightness and + proximity constraints) on the resulting wrapping. + + + + + + + + + + + + + Array of alpha values to use when alpha_value_choice is + set_of_values or when alpha_value_choice is set_of_alpha_wrappings. + + + + + + + + Array of offset values to use when alpha_value_choice is set_of_alpha_wrappings. + The array of alpha_values and offset_values define a sequence of (alpha and offset value). + + + + + + + + Specifies if the tool should compute the set of exterior triangle facets + for each alpha complex (for convex hull, alpha shapes, and wrappings). + + + + + Specifies if the tool should check if the alpha complex of + exterior triangular facets is a closed polyhedron. + + + + + Specifies if the tool should compute all interior tetrahedra + of the alpha complex (currently only for alpha shapes). + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml new file mode 100644 index 0000000000..499628aa32 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml @@ -0,0 +1,270 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + The number of vertices of the alpha complex. + + + + + The number of faces of the alpha complex. + + + + + The total number of XDMF values to represent all faces of triangles via XDMF. + + + + + The total number of XDMF values to represent all faces of tetrahedra via XDMF. + + + + + Application definition for results files of the paraprobe-surfacer tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + The purpose and need of the paraprobe-surfacer tool is the generation of meshed + representation of the surface of the the reconstructed volume (or a portion) of it + using different algorithms from the computational geometry community. + + + + + + + + + + + + Paraprobe-surfacer can be used to load a ROI that is the entire or a + sub-set of the ion point cloud. In the point_cloud_wrapping process + the tool computes a triangulated surface mesh which encloses the + ROI/point cloud. This mesh can be seen as a model for the edge of + the dataset. + + Different algorithms can be used with paraprobe-surfacer to create + this mesh such as convex hulls, alpha-shapes as their generalization, + or alpha wrappings. + + Ideally, the resulting mesh should be a watertight polyhedron. + This polyhedron is not necessarily convex. For some algorithms there + is no guarantee that the resulting mesh yields a watertight mesh. + + + + + + + + + + + + + + + + + + + + A bitmask which identifies exactly all those ions whose positions + were considered when defining the filtered point set from which + that alpha_complex instance was computed. + + This window can be different to the window of the *point_set_wrapping* + parent group because irrelevant ions might have been filtered out in addition + to the window defined in *point_set_wrapping* to reduce e.g. computational + costs of the alpha complex computation. + + + + + Number of ions covered by the mask. + + + + + Number of bits assumed matching on a default datatype. + + + + + The bitfield of the mask. See :ref:`NXcs_filter_boolean_mask` for + how this bitfield is to be interpreted. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The set of triangles in the coordinate system paraprobe + which discretizes the exterior surface of the alpha complex. + + + + + + + + + + + + + + + + + + + + + + + A list of as many tuples of XDMF topology key, XDMF number + of vertices and a triple of vertex indices specifying each + triangle. The total number of entries is n_f_tri * (1+1+3). + + + + + + + + Do the triangles define a triangulated surface mesh that is watertight? + + + + + The volume which the triangulated surface mesh + encloses if that mesh is watertight. + + + + + + + The set of tetrahedra which represent the interior volume + of the complex if that is a closed two-manifold. + + + + + The accumulated volume of all interior tetrahedra. + + + + + + + + + + + + + + + + A list of as many tuples of XDMF topology key, XDMF number + of vertices and a triple of vertex indices specifying each + triangle. The total number of entries is n_f_tet * (1+1+4). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml deleted file mode 100644 index 16c2e5a93b..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_surfacer.yaml +++ /dev/null @@ -1,509 +0,0 @@ -category: application -doc: | - Configuration of a paraprobe-surfacer tool run in atom probe microscopy. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_alpha_values: | - Number of alpha values (and offset values) to probe. - n_values: | - How many different match values does the filter specify. -type: group -NXapm_paraprobe_config_surfacer(NXobject): - (NXentry): - - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently - \@version: - doc: | - Version specifier of this application definition. - definition: - doc: | - Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_config_surfacer] - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - time_stamp(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: | - Possibility for leaving a free-text description about this analysis. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - number_of_processes(NX_UINT): - unit: NX_UNITLESS - doc: | - For now a support field for the tool to identify how many individual - analyses the tool should executed as part of the analysis. - (NXprocess): - dataset(NXapm_input_reconstruction): - filename: - \@version: - dataset_name_reconstruction: - dataset_name_mass_to_charge: - iontypes(NXapm_input_ranging): - filename: - \@version: - group_name_iontypes: - spatial_filter(NXspatial_filter): - exists: optional - windowing_method: - (NXcg_ellipsoid_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - half_axes_radii(NX_NUMBER): - orientation(NX_NUMBER): - (NXcg_cylinder_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - height(NX_NUMBER): - radii(NX_NUMBER): - (NXcg_hexahedron_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - hexahedra(NXcg_face_list_data_structure): - (NXcs_filter_boolean_mask): - exists: optional - number_of_objects(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - identifier(NX_UINT): - - ##MK::ion_id_filter(NXcs_filter_boolean_mask): - evaporation_id_filter(NXsubsampling_filter): - exists: optional - linear_range_min_incr_max(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, 3]] - iontype_filter(NXmatch_filter): - exists: optional - method: - match(NX_NUMBER): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_values]] - hit_multiplicity_filter(NXmatch_filter): - exists: optional - method: - match(NX_NUMBER): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, n_values]] - surface_meshing(NXprocess): - preprocessing_method: - doc: | - Specifies the method that is used to preprocess the point cloud. - The main purpose of this setting is to specify whether the point - cloud should be segmented or not during the preprocessing - to identify which points are more likely lying close to the edge - of the point cloud. These points could be more relevant than the - interior points for certain alpha-shape constructions. - - By default no such filtering is used during pre-processing. - By contrast, the option kuehbach activates a preprocessing - during which a Hoshen-Kopelman percolation analysis is used - to identify which points are closer to the edge of the dataset. - This can reduce the number of points in the alpha-shape - computation and thus improve performance substantially. - Details about the methods are reported in - `M. Kühbach et al. `_. - enumeration: [default, kuehbach] - preprocessing_kernel_width(NX_UINT): - unit: NX_UNITLESS - - # the exists is dependant on the value for preprocessing_method - doc: | - When using the kuehbach preprocessing, this is the width of the - kernel for identifying which ions are in voxels close to the - edge of the point cloud. - alpha_value_choice: - doc: | - Specifies which method to use to define the alpha value. - The value convex_hull_naive is the default. This instructs the tool - to use a fast specialized algorithm for computing only the convex - hull. The resulting triangles can be skinny. - - The value convex_hull_refine computes first also a convex_hull_naive - but refines the mesh by triangle flipping and splitting to improve - the quality of the mesh. - - The value smallest_solid instructs the CGAL library to choose a - value which realizes an alpha-shape that is the smallest solid. - - The value cgal_optimal instructs the library to choose a value - which the library considers as an optimal value. Details are - define in the respective section of the CGAL library on 3D alpha - shapes. - - The value set_of_values instructs to compute a list of - alpha-shapes for the specified alpha-values. - - The value set_of_alpha_wrappings instructs the library to generate - a set of so-called alpha wrappings. These are a method - which is similar to alpha shapes but provide additional guarantees - though such as watertightness and proximity constraints on the - resulting wrapping. - - # NEW ISSUE: further details CGAL documentation - enumeration: [convex_hull_naive, convex_hull_refine, smallest_solid, cgal_optimal, set_of_values, set_of_alpha_wrappings] - alpha_values(NX_FLOAT): - unit: NX_ANY - doc: | - Array of alpha values to use when alpha_value_choice is set_of_values - or when alpha_value_choice is set_of_alpha_wrappings. - - # \@units: nm^2 - dimensions: - rank: 1 - dim: [[1, n_alpha_values]] - offset_values(NX_FLOAT): - unit: NX_LENGTH - doc: | - Array of offset values to use when alpha_value_choice is - set_of_alpha_wrappings. The array of alpha_values and offset_values - define a sequence of (alpha and offset value). - - # \@units: nm - dimensions: - rank: 1 - dim: [[1, n_alpha_values]] - has_exterior_facets(NX_BOOLEAN): - doc: | - Specifies if the tool should compute the set of exterior triangle - facets for each alpha complex (for convex hull, alpha shapes, and wrappings) - has_closure(NX_BOOLEAN): - doc: | - Specifies if the tool should check if the alpha complex of exterior - triangular facets is a closed polyhedron. - has_interior_tetrahedra(NX_BOOLEAN): - doc: | - Specifies if the tool should compute all interior tetrahedra - of the alpha complex (currently only for alpha shapes). - - # NEW ISSUE: has_facet_appearance(NX_BOOLEAN): - performance(NXcs_profiling): - current_working_directory: - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 5a9a515d28f8231740dc213b3a0aa41a35e3121275b016be1d7065eb8c0429ec -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of alpha values (and offset values) to probe. -# -# -# -# -# How many different match values does the filter specify. -# -# -# -# -# Configuration of a paraprobe-surfacer tool run in atom probe microscopy. -# -# -# -# -# -# Version specifier of this application definition. -# -# -# -# -# Official NeXus NXDL schema with which this file was written. -# -# -# -# -# -# -# -# Given name of the program/software/tool with which this NeXus -# (configuration) file was generated. -# -# -# -# Ideally program version plus build number, or commit hash or description -# of ever persistent resources where the source code of the program and -# build instructions can be found so that the program can be configured -# ideally in such a manner that the result of this computational process -# is recreatable in the same deterministic manner. -# -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when this configuration file was created. -# -# -# -# -# Ideally, a (globally persistent) unique identifier for referring -# to this analysis. -# -# -# -# -# Possibility for leaving a free-text description about this analysis. -# -# -# -# -# Path to the directory where the tool should store NeXus/HDF5 results -# of this analysis. If not specified results will be stored in the -# current working directory. -# -# -# -# -# For now a support field for the tool to identify how many individual -# analyses the tool should executed as part of the analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Specifies the method that is used to preprocess the point cloud. -# The main purpose of this setting is to specify whether the point -# cloud should be segmented or not during the preprocessing -# to identify which points are more likely lying close to the edge -# of the point cloud. These points could be more relevant than the -# interior points for certain alpha-shape constructions. -# -# By default no such filtering is used during pre-processing. -# By contrast, the option kuehbach activates a preprocessing -# during which a Hoshen-Kopelman percolation analysis is used -# to identify which points are closer to the edge of the dataset. -# This can reduce the number of points in the alpha-shape -# computation and thus improve performance substantially. -# Details about the methods are reported in -# `M. Kühbach et al. <https://doi.org/10.1038/s41524-020-00486-1>`_. -# -# -# -# -# -# -# -# -# -# When using the kuehbach preprocessing, this is the width of the -# kernel for identifying which ions are in voxels close to the -# edge of the point cloud. -# -# -# -# -# Specifies which method to use to define the alpha value. -# The value convex_hull_naive is the default. This instructs the tool -# to use a fast specialized algorithm for computing only the convex -# hull. The resulting triangles can be skinny. -# -# The value convex_hull_refine computes first also a convex_hull_naive -# but refines the mesh by triangle flipping and splitting to improve -# the quality of the mesh. -# -# The value smallest_solid instructs the CGAL library to choose a -# value which realizes an alpha-shape that is the smallest solid. -# -# The value cgal_optimal instructs the library to choose a value -# which the library considers as an optimal value. Details are -# define in the respective section of the CGAL library on 3D alpha -# shapes. -# -# The value set_of_values instructs to compute a list of -# alpha-shapes for the specified alpha-values. -# -# The value set_of_alpha_wrappings instructs the library to generate -# a set of so-called alpha wrappings. These are a method -# which is similar to alpha shapes but provide additional guarantees -# though such as watertightness and proximity constraints on the -# resulting wrapping. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Array of alpha values to use when alpha_value_choice is set_of_values -# or when alpha_value_choice is set_of_alpha_wrappings. -# -# -# -# -# -# -# -# -# Array of offset values to use when alpha_value_choice is -# set_of_alpha_wrappings. The array of alpha_values and offset_values -# define a sequence of (alpha and offset value). -# -# -# -# -# -# -# -# -# Specifies if the tool should compute the set of exterior triangle -# facets for each alpha complex (for convex hull, alpha shapes, and wrappings) -# -# -# -# -# Specifies if the tool should check if the alpha complex of exterior -# triangular facets is a closed polyhedron. -# -# -# -# -# Specifies if the tool should compute all interior tetrahedra -# of the alpha complex (currently only for alpha shapes). -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml index 1e53aecd50..3d0811d529 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml @@ -26,6 +26,7 @@ NXapm_paraprobe_ranger_results(NXobject): ion is considered of the default *unknown_type*. This iontype is marked with a 0 in the iontypes array. ##MK::number_of_ion_types(NX_POSINT): + # config analysis_identifier(NX_UINT): config(NXserialized): type(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.yaml deleted file mode 100644 index f865daed53..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_surfacer.yaml +++ /dev/null @@ -1,935 +0,0 @@ -category: application -doc: | - Results of a paraprobe-surfacer tool run. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_ions: | - The total number of ions in the reconstruction. - n_v_tri: | - The number of vertices of the alpha complex. - n_f_tri: | - The number of faces of the alpha complex. - n_f_tri_xdmf: | - The total number of XDMF values to represent all faces of triangles via XDMF. - n_f_tet_xdmf: | - The total number of XDMF values to represent all faces of tetrahedra via XDMF. -type: group -NXapm_paraprobe_results_surfacer(NXobject): - - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently - (NXentry): - exists: ['min', '1', 'max', '1'] - \@version: - doc: | - Version specifier of this application definition. - - ##MK::begin of the tool-specific section - definition: - doc: | - Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_results_surfacer] - - ##MK::end of the tool-specific section - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: | - Possibility for leaving a free-text description about this analysis. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - config_filename: - doc: | - The absolute path and name of the config file for this analysis. - \@version: - doc: | - At least SHA256 strong hash of the specific config_file for - tracking provenance. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - status: - doc: | - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - enumeration: [success, failure] - (NXuser): - exists: recommended - doc: | - If used, contact information and eventually details - of at least the person who performed this analysis. - name: - affiliation: - exists: recommended - address: - exists: optional - email: - exists: recommended - orcid: - exists: recommended - orcid_platform: - exists: recommended - telephone_number: - exists: optional - role: - exists: recommended - social_media_name: - exists: optional - social_media_platform: - exists: optional - (NXcoordinate_system_set): - doc: | - Details about the coordinate system conventions used. - (NXtransformations): - exists: ['min', '1', 'max', 'unbounded'] - doc: | - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - ##MK::begin of the tool-specific section - (NXprocess): - exists: ['min', '0', 'max', '1'] - window(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies which of the ions in the dataset were - analyzed. Computations of alpha complexes may have filtered this - ion set further but this process is deterministic. - number_of_ions(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of ions covered by the mask. The mask may be 0 for most. - bitdepth(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - mask(NX_UINT): - unit: NX_UNITLESS - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - dimensions: - rank: 1 - dim: [[1, i]] - POINT_SET_WRAPPING(NXprocess): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - Paraprobe-surfacer can be used to load a ROI that is the entire or a - sub-set of the ion point cloud. In the point_cloud_wrapping process - the tool computes a triangulated surface mesh which encloses the - ROI/point cloud. This mesh can be seen as a model for the edge of - the dataset. - Different algorithms can be used with paraprobe-surfacer to create - this mesh such as convex hulls, alpha-shapes as their generalization, - or alpha wrappings. - Ideally, the resulting mesh should be a watertight polyhedron. - This polyhedron is not necessarily convex. For some algorithms there - is no guarantee that the resulting mesh yields a watertight mesh. - - # (NXcg_grid): currently we do not store the underlying grid - # for eventually performed preprocessing - alpha_complex(NXcg_alpha_complex): - exists: ['min', '0', 'max', 'unbounded'] - window(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies exactly all those ions whose positions - were considered when defining the filtered point set from which - the alpha complex was then in fact computed. This window - can be different to the entire window as irrelevant ions might - have been filtered out to reduce the computational costs of the - alpha complex analysis. - - # filtered in addition to the ROI or again the entire dataset - number_of_ions(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of ions covered by the mask. - The mask value for most may be 0. - - # which does paraprobe use - bitdepth(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - mask(NX_UINT): - unit: NX_UNITLESS - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - dimensions: - rank: 1 - dim: [[1, n_ions]] - dimensionality(NX_UINT): - unit: NX_UNITLESS - enumeration: [2, 3] - type: - enumeration: [convex_hull, alpha_shape, alpha_wrapping, other, undefined] - mode: - enumeration: [general, regularized] - alpha(NX_NUMBER): - unit: NX_LENGTH - offset(NX_NUMBER): - exists: optional - unit: NX_LENGTH - triangle_set(NXcg_triangle_set): - exists: optional - doc: | - The set of triangles in the coordinate system paraprobe - which discretizes the exterior surface of the alpha complex. - identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer which specifies the first index to be used for distinguishing - triangles. Identifiers are defined either implicitly or explicitly. - For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - triangles(NXcg_face_list_data_structure): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - number_of_vertices(NX_POSINT): - unit: NX_UNITLESS - doc: | - Number of vertices. - number_of_faces(NX_POSINT): - unit: NX_UNITLESS - doc: | - Number of faces. - vertex_identifier_offset(NX_INT): - unit: NX_UNITLESS - face_identifier_offset(NX_INT): - unit: NX_UNITLESS - vertices(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_v_tri], [2, 3]] - faces(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_f_tri], [2, 3]] - xdmf_topology(NX_UINT): - unit: NX_UNITLESS - doc: | - A list of as many tuples of XDMF topology key, XDMF number - of vertices and a triple of vertex indices specifying each - triangle. The total number of entries is n_f_tri * (1+1+3). - dimensions: - rank: 1 - dim: [[1, n_f_tri_xdmf]] - is_watertight(NX_BOOLEAN): - exists: optional - doc: | - Do the triangles define a triangulated surface mesh which - is watertight? - volume(NX_FLOAT): - exists: optional - unit: NX_VOLUME - doc: | - The volume which the triangulated surface mesh encloses - provided that the mesh is watertight. - interior_tetrahedra(NXcg_tetrahedron_set): - exists: optional - doc: | - The set of tetrahedra which represent the interior volume of the - complex if that is a closed 2-manifold. - identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer which specifies the first index to be used for distin- - guishing tetrahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined - on the interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - volume(NX_FLOAT): - exists: optional - unit: NX_VOLUME - doc: | - The accumulated volume of all interior tetrahedra. - tetrahedra(NXcg_face_list_data_structure): - exists: optional - number_of_vertices(NX_POSINT): - unit: NX_UNITLESS - doc: | - Number of vertices. - number_of_faces(NX_POSINT): - unit: NX_UNITLESS - doc: | - Number of faces. - vertex_identifier_offset(NX_INT): - unit: NX_UNITLESS - face_identifier_offset(NX_INT): - unit: NX_UNITLESS - vertices(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_v_tet], [2, 3]] - xdmf_topology(NX_UINT): - unit: NX_UNITLESS - doc: | - A list of as many tuples of XDMF topology key, XDMF number - of vertices and a triple of vertex indices specifying each - triangle. The total number of entries is n_f_tet * (1+1+4). - dimensions: - rank: 1 - dim: [[1, n_f_tet_xdmf]] - TRIANGLE_SET_WRAPPING(NXprocess): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - In the future we may want to wrap other primitives - like triangles or polylines. - - ##MK::end of the tool-specific section - performance(NXcs_profiling): - exists: recommended - current_working_directory: - command_line_call: - exists: optional - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - total_elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - (NXcs_computer): - exists: recommended - name: - exists: recommended - operating_system: - \@version: - uuid: - exists: optional - (NXcs_cpu): - exists: ['min', '0', 'max', 'unbounded'] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_gpu): - exists: ['min', '0', 'max', 'unbounded'] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_mm_sys): - exists: ['min', '0', 'max', '1'] - total_physical_memory(NX_NUMBER): - (NXcs_io_sys): - exists: ['min', '0', 'max', '1'] - (NXcs_io_obj): - exists: ['min', '1', 'max', 'unbounded'] - technology: - max_physical_capacity(NX_NUMBER): - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_profiling_event): - start_time(NX_DATE_TIME): - exists: optional - end_time(NX_DATE_TIME): - exists: optional - description: - elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - number_of_threads(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - number_of_gpus(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - max_virtual_memory_snapshot(NX_NUMBER): - exists: recommended - max_resident_memory_snapshot(NX_NUMBER): - exists: recommended - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 9d0676f28ebba35d9a70595e9c692a6506d83179dc6cf2b8bb5d9dba669ce196 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The total number of ions in the reconstruction. -# -# -# -# -# The number of vertices of the alpha complex. -# -# -# -# -# The number of faces of the alpha complex. -# -# -# -# -# The total number of XDMF values to represent all faces of triangles via XDMF. -# -# -# -# -# The total number of XDMF values to represent all faces of tetrahedra via XDMF. -# -# -# -# -# Results of a paraprobe-surfacer tool run. -# -# -# -# -# -# Version specifier of this application definition. -# -# -# -# -# -# Official NeXus NXDL schema with which this file was written. -# -# -# -# -# -# -# -# -# Given name of the program/software/tool with which this NeXus -# (configuration) file was generated. -# -# -# -# Ideally program version plus build number, or commit hash or description -# of ever persistent resources where the source code of the program and -# build instructions can be found so that the program can be configured -# ideally in such a manner that the result of this computational process -# is recreatable in the same deterministic manner. -# -# -# -# -# -# Ideally, a (globally persistent) unique identifier for referring -# to this analysis. -# -# -# -# -# Possibility for leaving a free-text description about this analysis. -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when the analysis behind this results file -# was started, i.e. the paraprobe-tool executable started as a process. -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when the analysis behind this results file -# were completed and the paraprobe-tool executable exited as a process. -# -# -# -# -# The absolute path and name of the config file for this analysis. -# -# -# -# At least SHA256 strong hash of the specific config_file for -# tracking provenance. -# -# -# -# -# -# Path to the directory where the tool should store NeXus/HDF5 results -# of this analysis. If not specified results will be stored in the -# current working directory. -# -# -# -# -# A statement whether the paraprobe-tool executable managed to -# process the analysis or failed prematurely. -# -# This status is written to the results file after the end_time -# at which point the executable must not compute any analysis. -# Only when this status message is present and shows `success`, the -# user should consider the results. In all other cases it might be -# that the executable has terminated prematurely or another error -# occurred. -# -# -# -# -# -# -# -# -# If used, contact information and eventually details -# of at least the person who performed this analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Details about the coordinate system conventions used. -# -# -# -# The individual coordinate systems which should be used. -# Field names should be prefixed with the following controlled terms -# indicating which individual coordinate system is described: -# -# * paraprobe -# * lab -# * specimen -# * laser -# * leap -# * detector -# * recon -# -# -# -# -# -# -# -# A bitmask which identifies which of the ions in the dataset were -# analyzed. Computations of alpha complexes may have filtered this -# ion set further but this process is deterministic. -# -# -# -# Number of ions covered by the mask. The mask may be 0 for most. -# -# -# -# -# Number of bits assumed matching on a default datatype. -# (e.g. 8 bits for a C-style uint8). -# -# -# -# -# The unsigned integer array representing the content of the mask. -# If padding is used the padded bits are set to 0. The mask is for -# convenience always as large as the entire dataset as it will -# be stored compressed anyway. The convenience feature with this -# is that then the mask can be decoded with numpy and mirrored -# against the evaporation_id array and one immediately can filter -# out all points that were used by the paraprobe. -# The length of the array adds to the next unsigned integer -# if the number of ions in the dataset is not an integer -# multiple of the bitdepth. -# -# -# -# -# -# -# -# -# Paraprobe-surfacer can be used to load a ROI that is the entire or a -# sub-set of the ion point cloud. In the point_cloud_wrapping process -# the tool computes a triangulated surface mesh which encloses the -# ROI/point cloud. This mesh can be seen as a model for the edge of -# the dataset. -# Different algorithms can be used with paraprobe-surfacer to create -# this mesh such as convex hulls, alpha-shapes as their generalization, -# or alpha wrappings. -# Ideally, the resulting mesh should be a watertight polyhedron. -# This polyhedron is not necessarily convex. For some algorithms there -# is no guarantee that the resulting mesh yields a watertight mesh. -# -# -# -# -# -# A bitmask which identifies exactly all those ions whose positions -# were considered when defining the filtered point set from which -# the alpha complex was then in fact computed. This window -# can be different to the entire window as irrelevant ions might -# have been filtered out to reduce the computational costs of the -# alpha complex analysis. -# -# -# -# -# Number of ions covered by the mask. -# The mask value for most may be 0. -# -# -# -# -# -# Number of bits assumed matching on a default datatype. -# (e.g. 8 bits for a C-style uint8). -# -# -# -# -# The unsigned integer array representing the content of the mask. -# If padding is used the padded bits are set to 0. The mask is for -# convenience always as large as the entire dataset as it will -# be stored compressed anyway. The convenience feature with this -# is that then the mask can be decoded with numpy and mirrored -# against the evaporation_id array and one immediately can filter -# out all points that were used by the paraprobe. -# The length of the array adds to the next unsigned integer -# if the number of ions in the dataset is not an integer -# multiple of the bitdepth. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The set of triangles in the coordinate system paraprobe -# which discretizes the exterior surface of the alpha complex. -# -# -# -# Integer which specifies the first index to be used for distinguishing -# triangles. Identifiers are defined either implicitly or explicitly. -# For implicit indexing the identifiers are defined on the -# interval [identifier_offset, identifier_offset+c-1]. -# -# -# -# -# -# -# Number of vertices. -# -# -# -# -# Number of faces. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# A list of as many tuples of XDMF topology key, XDMF number -# of vertices and a triple of vertex indices specifying each -# triangle. The total number of entries is n_f_tri * (1+1+3). -# -# -# -# -# -# -# -# -# Do the triangles define a triangulated surface mesh which -# is watertight? -# -# -# -# -# The volume which the triangulated surface mesh encloses -# provided that the mesh is watertight. -# -# -# -# -# -# The set of tetrahedra which represent the interior volume of the -# complex if that is a closed 2-manifold. -# -# -# -# Integer which specifies the first index to be used for distin- -# guishing tetrahedra. Identifiers are defined either implicitly -# or explicitly. For implicit indexing the identifiers are defined -# on the interval [identifier_offset, identifier_offset+c-1]. -# For explicit indexing the identifier array has to be defined. -# -# -# -# -# The accumulated volume of all interior tetrahedra. -# -# -# -# -# -# Number of vertices. -# -# -# -# -# Number of faces. -# -# -# -# -# -# -# -# -# -# -# -# -# A list of as many tuples of XDMF topology key, XDMF number -# of vertices and a triple of vertex indices specifying each -# triangle. The total number of entries is n_f_tet * (1+1+4). -# -# -# -# -# -# -# -# -# -# -# -# In the future we may want to wrap other primitives -# like triangles or polylines. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Specify if it was different from the number_of_processes -# in the NXcs_profiling super class. -# -# -# -# -# -# Specify if it was different from the number_of_threads -# in the NXcs_profiling super class. -# -# -# -# -# -# Specify if it was different from the number_of_threads -# in the NXcs_profiling super class. -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml index 2e6ce41079..a5820e7557 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml @@ -32,7 +32,7 @@ NXapm_paraprobe_selector_config(NXobject): checksum(NX_CHAR): algorithm(NX_CHAR): ranging_definitions(NX_CHAR): - # filter that are here tool-specific parameter + # filter that represent here also the tool-specific config spatial_filter(NXspatial_filter): windowing_method(NX_CHAR): hexahedron_set(NXcg_hexahedron_set): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_config.yaml new file mode 100644 index 0000000000..b72b66e520 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_config.yaml @@ -0,0 +1,167 @@ +category: application +doc: | + Application definition for a configuration file of the paraprobe-surfacer tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_alpha_values: | + Number of alpha values (and offset values) to probe. + n_values: | + How many different match values does the filter specify. +type: group +NXapm_paraprobe_surfacer_config(NXobject): + (NXentry): + exists: [min, 1, max, 1] + definition(NX_CHAR): + \@version(NX_CHAR): + enumeration: [NXapm_paraprobe_surfacer_config] + surface_meshing(NXapm_paraprobe_tool_config): + exists: [min, 1, max, 1] + (NXidentifier): + exists: optional + analysis_identifier(NX_UINT): + exists: recommended + reconstruction(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + position(NX_CHAR): + mass_to_charge(NX_CHAR): + ranging(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + ranging_definitions(NX_CHAR): + # filter that are here tool-specific parameter + spatial_filter(NXspatial_filter): + windowing_method(NX_CHAR): + hexahedron_set(NXcg_hexahedron_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + hexahedra(NXcg_face_list_data_structure): + vertices(NX_UINT): + cylinder_set(NXcg_cylinder_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + height(NX_NUMBER): + radii(NX_NUMBER): + ellipsoid_set(NXcg_ellipsoid_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + half_axes_radii(NX_NUMBER): + orientation(NX_NUMBER): + polyhedron_set(NXcg_polyhedron_set): + exists: optional + # TODO + bitmask(NXcs_filter_boolean_mask): + exists: optional + number_of_objects(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + # leave open if scalar or matrix + # dim: (i,) + identifier(NX_UINT): + evaporation_id_filter(NXsubsampling_filter): + exists: optional + min_incr_max(NX_INT): + iontype_filter(NXmatch_filter): + exists: optional + method(NX_CHAR): + match(NX_NUMBER): + hit_multiplicity_filter(NXmatch_filter): + # config + preprocessing(NXprocess): + method(NX_CHAR): + doc: | + Specifies the method that is used to preprocess the point cloud + prior to the alpha-shape computation. + + The option *default* specifies that no such filtering is applied. + The option *kuehbach* specifies that a Hoshen-Kopelman + percolation analysis is used to identify points that lie closer + to the edge of the dataset. Details about the methods are reported + in `M. Kühbach et al. `_. + enumeration: [default, kuehbach] + kernel_width(NX_UINT): + doc: | + When using the kuehbach preprocessing, this is the width of the + kernel for identifying which ions are in voxels close to the + edge of the point cloud. + unit: NX_UNITLESS + alpha_value_choice(NX_CHAR): + doc: | + Specifies which method to use to define the alpha value. + + The value *convex_hull_naive* is the default. The setting instructs + the tool to use a fast specialized algorithm for computing only + the convex hull. The resulting triangles can be skinny. + + The value *convex_hull_refine* instructs to tool to refine the + quality of the mesh resulting from *convex_hull_naive* + via triangle flipping and splitting. + + The value *smallest_solid* instructs the CGAL library to choose a + value which realizes an alpha-shape that is the smallest solid. + + The value *cgal_optimal* instructs the CGAL library to choose a + value which the library considers as to be an optimal value. + Details are defined in the respective section of the CGAL library + on 3D alpha shapes. + + The value *set_of_values* instructs the tool to compute a list + collection of alpha-shapes for the specified alpha-values. + + The value *set_of_alpha_wrappings* instructs the tool to generate + a set of so-called alpha wrappings. These are similar to alpha-shapes + but provide additional guarantees (such as watertightness and + proximity constraints) on the resulting wrapping. + enumeration: [convex_hull_naive, convex_hull_refine, smallest_solid, cgal_optimal, set_of_values, set_of_alpha_wrappings] + alpha_values(NX_FLOAT): + doc: | + Array of alpha values to use when alpha_value_choice is + set_of_values or when alpha_value_choice is set_of_alpha_wrappings. + unit: NX_ANY + # \@units: nm^2 + dim: (n_alpha_values,) + offset_values(NX_FLOAT): + doc: | + Array of offset values to use when alpha_value_choice is set_of_alpha_wrappings. + The array of alpha_values and offset_values define a sequence of (alpha and offset value). + unit: NX_LENGTH + # \@units: nm + dim: (n_alpha_values,) + has_exterior_facets(NX_BOOLEAN): + doc: | + Specifies if the tool should compute the set of exterior triangle facets + for each alpha complex (for convex hull, alpha shapes, and wrappings). + has_closure(NX_BOOLEAN): + doc: | + Specifies if the tool should check if the alpha complex of + exterior triangular facets is a closed polyhedron. + has_interior_tetrahedra(NX_BOOLEAN): + doc: | + Specifies if the tool should compute all interior tetrahedra + of the alpha complex (currently only for alpha shapes). + # NEW ISSUE: has_facet_appearance(NX_BOOLEAN): + # profiling + (NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + profiling(NXcs_profiling): + exists: recommended + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + current_working_directory(NX_CHAR): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml new file mode 100644 index 0000000000..cc4e0c98ac --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml @@ -0,0 +1,180 @@ +category: application +doc: | + Application definition for results files of the paraprobe-surfacer tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + The purpose and need of the paraprobe-surfacer tool is the generation of meshed + representation of the surface of the the reconstructed volume (or a portion) of it + using different algorithms from the computational geometry community. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_ions: | + The total number of ions in the reconstruction. + n_v_tri: | + The number of vertices of the alpha complex. + n_f_tri: | + The number of faces of the alpha complex. + n_f_tri_xdmf: | + The total number of XDMF values to represent all faces of triangles via XDMF. + n_f_tet_xdmf: | + The total number of XDMF values to represent all faces of tetrahedra via XDMF. +type: group +NXapm_paraprobe_surfacer_results(NXobject): + (NXentry): + exists: [min, 1, max, 1] + definition(NX_CHAR): + \@version(NX_CHAR): + enumeration: [NXapm_paraprobe_surfacer_results] + # tasks + point_set_wrapping(NXapm_paraprobe_tool_results): + doc: | + Paraprobe-surfacer can be used to load a ROI that is the entire or a + sub-set of the ion point cloud. In the point_cloud_wrapping process + the tool computes a triangulated surface mesh which encloses the + ROI/point cloud. This mesh can be seen as a model for the edge of + the dataset. + + Different algorithms can be used with paraprobe-surfacer to create + this mesh such as convex hulls, alpha-shapes as their generalization, + or alpha wrappings. + + Ideally, the resulting mesh should be a watertight polyhedron. + This polyhedron is not necessarily convex. For some algorithms there + is no guarantee that the resulting mesh yields a watertight mesh. + # config + analysis_identifier(NX_UINT): + config(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + window(NXcs_filter_boolean_mask): + number_of_ions(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + # results + alpha_complexID(NXcg_alpha_complex): + exists: [min, 0, max, infty] + # (NXcg_grid): currently we do not store the underlying grid + # for eventually performed preprocessing + window(NXcs_filter_boolean_mask): + doc: | + A bitmask which identifies exactly all those ions whose positions + were considered when defining the filtered point set from which + that alpha_complex instance was computed. + + This window can be different to the window of the *point_set_wrapping* + parent group because irrelevant ions might have been filtered out in addition + to the window defined in *point_set_wrapping* to reduce e.g. computational + costs of the alpha complex computation. + # filtered in addition to the ROI or again the entire dataset + number_of_ions(NX_UINT): + doc: | + Number of ions covered by the mask. + unit: NX_UNITLESS + bitdepth(NX_UINT): + doc: | + Number of bits assumed matching on a default datatype. + unit: NX_UNITLESS + mask(NX_UINT): + doc: | + The bitfield of the mask. See :ref:`NXcs_filter_boolean_mask` for + how this bitfield is to be interpreted. + unit: NX_UNITLESS + dim: (n_ions,) + dimensionality(NX_UINT): + enumeration: [2, 3] + unit: NX_UNITLESS + type(NX_CHAR): + enumeration: [convex_hull, alpha_shape, alpha_wrapping, other, undefined] + mode(NX_CHAR): + enumeration: [general, regularized] + alpha(NX_NUMBER): + unit: NX_ANY + offset(NX_NUMBER): + exists: optional + unit: NX_LENGTH + triangle_set(NXcg_triangle_set): + exists: optional + doc: | + The set of triangles in the coordinate system paraprobe + which discretizes the exterior surface of the alpha complex. + identifier_offset(NX_INT): + triangles(NXcg_face_list_data_structure): + dimensionality(NX_POSINT): + number_of_vertices(NX_POSINT): + number_of_faces(NX_POSINT): + vertex_identifier_offset(NX_INT): + face_identifier_offset(NX_INT): + vertices(NX_FLOAT): + unit: NX_LENGTH + dim: (n_v_tri, 3) + faces(NX_UINT): + unit: NX_UNITLESS + dim: (n_f_tri, 3) + xdmf_topology(NX_UINT): + doc: | + A list of as many tuples of XDMF topology key, XDMF number + of vertices and a triple of vertex indices specifying each + triangle. The total number of entries is n_f_tri * (1+1+3). + unit: NX_UNITLESS + dim: (n_f_tri_xdmf,) + is_watertight(NX_BOOLEAN): + exists: optional + doc: | + Do the triangles define a triangulated surface mesh that is watertight? + volume(NX_FLOAT): + exists: optional + doc: | + The volume which the triangulated surface mesh + encloses if that mesh is watertight. + unit: NX_VOLUME + + interior_tetrahedra(NXcg_tetrahedron_set): + exists: optional + doc: | + The set of tetrahedra which represent the interior volume + of the complex if that is a closed two-manifold. + identifier_offset(NX_INT): + unit: NX_UNITLESS + volume(NX_FLOAT): + exists: optional + doc: | + The accumulated volume of all interior tetrahedra. + unit: NX_VOLUME + tetrahedra(NXcg_face_list_data_structure): + exists: optional + number_of_vertices(NX_POSINT): + number_of_faces(NX_POSINT): + vertex_identifier_offset(NX_INT): + face_identifier_offset(NX_INT): + vertices(NX_FLOAT): + unit: NX_LENGTH + dim: (n_v_tet, 3) + xdmf_topology(NX_UINT): + doc: | + A list of as many tuples of XDMF topology key, XDMF number + of vertices and a triple of vertex indices specifying each + triangle. The total number of entries is n_f_tet * (1+1+4). + unit: NX_UNITLESS + dim: (n_f_tet_xdmf,) + # TRIANGLE_SET_WRAPPING(NXprocess): + # For the future as we may wish to wrap primitives other like triangles or polylines. + # global + (NXuser): + exists: [min, 0, max, infty] + name(NX_CHAR): + (NXcoordinate_system_set): + paraprobe(NXcoordinate_system): + type(NX_CHAR): + handedness(NX_CHAR): + x(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + y(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + z(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) diff --git a/manual/source/classes/contributed_definitions/apm-structure.rst b/manual/source/classes/contributed_definitions/apm-structure.rst index aec8883be3..580258ccdc 100644 --- a/manual/source/classes/contributed_definitions/apm-structure.rst +++ b/manual/source/classes/contributed_definitions/apm-structure.rst @@ -233,16 +233,12 @@ tool one such pair is proposed: Apply ranging definitions and explore possible molecular ions. Store applied ranging definitions and combinatorial analyses of possible iontypes. -The definitions of the following tools remain to become refactored like those for the above-mentioned tools: - - :ref:`NXapm_paraprobe_config_selector`: - Configuration of paraprobe-selector + :ref:`NXapm_paraprobe_selector_config`, :ref:`NXapm_paraprobe_selector_results`: + Configuration and results respectively of paraprobe-selector tool. Defining complex spatial regions-of-interest to filter reconstructed datasets. - - :ref:`NXapm_paraprobe_results_selector`: - Results of paraprobe-selector Store which points are inside or on the boundary of complex spatial regions-of-interest. +The definitions of the following tools remain to become refactored like those for the above-mentioned tools: :ref:`NXapm_paraprobe_config_surfacer`: Configuration of paraprobe-surfacer diff --git a/manual/source/classes/contributed_definitions/icme-structure.rst b/manual/source/classes/contributed_definitions/icme-structure.rst index 07aa6ee4e1..8c067978db 100644 --- a/manual/source/classes/contributed_definitions/icme-structure.rst +++ b/manual/source/classes/contributed_definitions/icme-structure.rst @@ -29,12 +29,7 @@ concepts which are equally modellable with NeXus: :ref:`NXms_recon`: A base class for documenting results of reconstructed microstructures. - :ref:`NXms_score_config`: - A specific example of how :ref:`NXapm_paraprobe_config_ranger` can be - specialized for documenting the configuration of a computer simulation - with the static recrystallization cellular automata model SCORE. - - :ref:`NXms_score_results`: - A specific example of how :ref:`NXms` can be specialized for documenting - results of computer simulations with the static recrystallization - cellular automata model SCORE. + :ref:`NXms_score_config`, :ref:`NXms_score_results`: + A specific example of an application definition for documenting the + configuration and results respectively of a computer simulation with + the static recrystallization cellular automata model SCORE. From 8b6ee88a420d09628a8655ed92bbb158e81305d5 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Sat, 27 Jan 2024 22:20:04 +0100 Subject: [PATCH 0534/1012] Refactored appdefs for distancer and tessellator to use APMv2 --- .../NXapm_paraprobe_distancer_config.nxdl.xml | 183 +++ ...NXapm_paraprobe_distancer_results.nxdl.xml | 183 +++ .../NXapm_paraprobe_ranger_config.nxdl.xml | 2 +- .../NXapm_paraprobe_ranger_results.nxdl.xml | 2 +- .../NXapm_paraprobe_selector_config.nxdl.xml | 2 +- .../NXapm_paraprobe_selector_results.nxdl.xml | 2 +- .../NXapm_paraprobe_surfacer_config.nxdl.xml | 7 +- ...Xapm_paraprobe_tessellator_config.nxdl.xml | 180 +++ ...apm_paraprobe_tessellator_results.nxdl.xml | 318 ++++ .../NXapm_paraprobe_tool_results.nxdl.xml | 5 + ...NXapm_paraprobe_transcoder_config.nxdl.xml | 2 +- ...Xapm_paraprobe_transcoder_results.nxdl.xml | 2 +- .../NXapm_paraprobe_config_distancer.yaml | 453 ------ .../NXapm_paraprobe_config_tessellator.yaml | 449 ------ .../NXapm_paraprobe_distancer_config.yaml | 141 ++ .../NXapm_paraprobe_distancer_results.yaml | 123 ++ .../nyaml/NXapm_paraprobe_ranger_config.yaml | 2 +- .../nyaml/NXapm_paraprobe_ranger_results.yaml | 2 +- .../NXapm_paraprobe_results_distancer.yaml | 730 ---------- .../NXapm_paraprobe_results_tessellator.yaml | 1284 ----------------- .../NXapm_paraprobe_selector_config.yaml | 2 +- .../NXapm_paraprobe_selector_results.yaml | 2 +- .../NXapm_paraprobe_surfacer_config.yaml | 5 +- .../NXapm_paraprobe_tessellator_config.yaml | 136 ++ .../NXapm_paraprobe_tessellator_results.yaml | 214 +++ .../nyaml/NXapm_paraprobe_tool_results.yaml | 5 + .../NXapm_paraprobe_transcoder_config.yaml | 2 +- .../NXapm_paraprobe_transcoder_results.yaml | 2 +- 28 files changed, 1509 insertions(+), 2931 deletions(-) create mode 100644 contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml diff --git a/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml new file mode 100644 index 0000000000..b2eb7e7175 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml @@ -0,0 +1,183 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Application definition for a configuration file of the paraprobe-distancer tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specifies for which point the tool will compute distances. + + The value *default* configures that distances are computed for all points. + The value *skin* configures that distances are computed only for those + points which are not farther away located to a triangle than + threshold_distance. + + + + + + + + + Maximum distance for which distances are + computed when *method* is *skin*. + + + + + + How many triangle sets to consider. + Multiple triangle sets can be defined which are + composed into one joint triangle set for the analysis. + + + + + Each triangle_set that is referred to here should be a face_list_data_structure, + i.e. an array of (n_vertices, 3) of NX_FLOAT for vertex coordinates, an (n_facets, 3) + array of NX_UINT incident vertices of each facet. Vertex indices are assumed to + start at zero and must not exceed n_vertices - 1, i.e. the identifier_offset is 0. + Facet normal have to be provided as an array of (n_facets, 3) of NX_FLOAT. + + + + + + + + Absolute path in the (HDF5) file that points to the array + of vertex positions for the triangles in that triangle_set. + + + + + Absolute path in the (HDF5) file that points to the array + of facet indices for the triangles in that triangle_set. + + + + + Absolute path in the (HDF5) file that points to the array + of facet normal vectors for the triangles in that triangle_set. + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml new file mode 100644 index 0000000000..ea20ffcc27 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml @@ -0,0 +1,183 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of points, i.e. ions in the reconstruction. + + + + + The total number of triangles in the set. + + + + + Application definition for results files of the paraprobe-distancer tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + The paraprobe-distancer tool can be used for the computing of the shortest Euclidean distance for each + member of a set of points against a set of triangles. In contrast to most approaches in atom probe where the + distance is computed as the projected distance, this tool evaluates robustly the exact distance between + a point and a triangle. + + Triangles can represent for instance the facets of a triangulated surface mesh like those returned by + paraprobe-surfacer or any other set of triangles. Triangles do not have to be connected. + + Currently, paraprobe-distancer does not check if the respectively specified triangle sets are consistent, + what their topology is, or whether or not these triangles are consistently oriented. + + + + + + + + + + + + + + + + + + + + + + + + + + + The shortest analytical distance of each point to their + respectively closest triangle from the joint triangle set. + + + + + + + + For each point the identifier of the triangle for which the + shortest distance was found + + + + + + + + A support field to enable the visualization of each point + by an explicit identifier on the interval [0, n_ions - 1]. + The field can be used to visualize the points as a function + of their distance to the triangle set (e.g. via XDMF/Paraview). + + + + + + + + A bitmask that identifies which of the distance values is + assumed to have a consistent sign because the closest + triangle had a consistent outer unit normal defined. + + For points whose bit is set to 0 the distance is correct + but the sign is not reliable. + + + + Number of triangles covered by the mask. + + + + + Bitdepth of the elementary datatype that is used to store + the information content of the mask (typically 8 bit, uint8). + + + + + The content of the mask. Like for all masks used in the tools + of the paraprobe-toolbox, padding is used when number_of_objects + is not an integer multiple of bitdepth. If padding is used, + padded bits are set to 0. + + + + + + + + + A bitmask that identifies which of the triangles in the set were + considered when certain triangles have been filtered out. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml index c994514b5f..b24346b7b4 100644 --- a/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml @@ -120,7 +120,7 @@ - + diff --git a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml index 5877720dce..4858a871e4 100644 --- a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml @@ -91,7 +91,7 @@ config--> - + diff --git a/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml index a9ec6aa570..1513ffd6b4 100644 --- a/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml @@ -107,7 +107,7 @@ - + diff --git a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml index 0d2ba23c10..058e1a287f 100644 --- a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml @@ -63,7 +63,7 @@ - + diff --git a/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml index a31d15d6ed..a30c4d5343 100644 --- a/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml @@ -112,7 +112,10 @@ - + + + + @@ -214,7 +217,7 @@ - + diff --git a/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml new file mode 100644 index 0000000000..b1320d76d6 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml @@ -0,0 +1,180 @@ + + + + + + + Application definition for a configuration file of the paraprobe-tessellator tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Absolute in the (HDF5) file that points to the + distance values. The tool assumes that the + values are stored in the same order as the + points. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The method used to compute the tessellation. + The value *default* configures the computation of the Voronoi tessellation. + + + + + + + + + Specifies if the tool should report the volume of each cell. + + + + + Specifies if the tool should report the first-order neighbors of each cell. + + + + + Specifies if the tool should report the facets and vertices of each cell. + + + + + Specifies if the tool should report for each cell if it makes contact with + the tight axis-aligned bounding box about the point cloud. + This can be used to identify if the shape of the cell is likely affected + by the edge of the dataset or if cells are deeply enough embedded + into the point cloud so that the shape of their cells are not affected + anymore by the boundary. This is valuable information to judge + about the significance of finite size effects. + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml new file mode 100644 index 0000000000..e7bbd0d7c9 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml @@ -0,0 +1,318 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + The total number of values required to represent all faces of each cell. + + + + + The total number of values required to represent all faces of each cell + (polyhedron) using XDMF. + + + + + Application definition for results files of the paraprobe-tessellator tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + + + + + + + + + + + + The tool can be used to compute a Voronoi tessellation the entire + or of a sub-set of the reconstructed volume. Each point (ion) is wrapped + in one (Voronoi) cell. The point cloud in the ROI is wrapped into an + axis-aligned bounding box (AABB) that is tight. This means points at + the edge of the point cloud can lay on the surface of the bounding box. + The tool detects if cells make contact with the walls of this bounding box. + The tessellation is computed without periodic boundary conditions. + + + + + + + + + + + + + + + + + + The (tight) axis-aligned bounding box about the point cloud. + + + + Coordinate triplet of the corner that lays closests + to the origin of the *paraprobe* coordinate system. + + + + + + + + Coordinate triplet of the corner that lays farthest away + from the origin of the *paraprobe* coordinate system. + + + + + + + + + + + + + + + The number of points (and thus cells). + + + + + Volume of each Voronoi cell. + + + + + + + + Which MPI process computed which Voronoi cell. + + + + + + + + Which OpenMP thread computed which Voronoi cell. + + + + + + + + The number of faces for each cell. Faces of adjoining polyhedra are counted + for each polyhedron. This field can be used to interpret the concatenated vector + with the individual values for the area of each face. + + + + + + + + + A simple approach to describe the entire set of polyhedra when the main + intention is to store the shape of the polyhedra for visualization purposes. + + + + + + + + + + Sequence of tuples, concatenated in the order of the Voronoi cells. + Each tuple contains encodes information to visualize using XDMF: + Firstly, an XDMF geometric primitive type key. + Secondly, the number of vertices of the polygon. + Third, the sequence of vertex identifier which define the facet. + Tuples encode faces faster than cells. + + + + + + + + Sequence of cell identifier, concatenated such that each face is + associated with its cell. Given that paraprobe-tessellator assigns + each cell the evaporation_id of the ion that the cell wraps this + information enables the segmentation of the tessellation and + thus correlate per-ion properties with the volume that each cell + represents. + + + + + + + + + A bitmask that documents which of the cells are likely truncated because they + share at least one face with the *aabb* of the point cloud. This field encodes the + result of the boolean or operator applied to the value of all six wall_contact groups + that document contact in specific outer unit normal directions of the *aabb*. + + + + + + + + + + + + + In the spirit of wall_contact_global, the left face of *aabb*. + Its outer unit normal points in the opposite direction of the + x-axis of the *paraprobe* coordinate system. + + + + + + + + + + + + In the spirit of wall_contact_global, the right face of *aabb*. + Its outer unit normal points in the direction of the x-axis + of the *paraprobe* coordinate system. + + + + + + + + + + + + In the spirit of wall_contact_global, the front face of *aabb*. + Its outer unit normal points in the opposite direction of the + y-axis of the *paraprobe* coordinate system. + + + + + + + + + + + + In the spirit of wall_contact_global, the rear face of *aabb*. + Its outer unit normal points in the direction of the y-axis + of the *paraprobe* coordinate system. + + + + + + + + + + + + In the spirit of wall_contact_global, the front face of *aabb*. + Its outer unit normal points in the opposite direction of the + z-axis of the *paraprobe* coordinate system. + + + + + + + + + + + + In the spirit of wall_contact_global, the front face of *aabb*. + Its outer unit normal points in the direction of the z-axis of the + *paraprobe* coordinate system. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml index 1cb1314c9d..621d887e02 100644 --- a/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml @@ -22,6 +22,8 @@ # For further information, see http://www.nexusformat.org --> @@ -46,6 +48,9 @@ symbols: The configuration and results of a run of a tool from the toolbox is documented using binary container formats. Currently, paraprobe-toolbox uses the Hierarchical Data Format 5 (HDF5). + + The paraprobe coordinate system is the reference *NXcoordinate_system* + for each geometric primitive. diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml index 5c4eaf6c97..98f80fb126 100644 --- a/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml @@ -65,7 +65,7 @@ official NeXus appdef headers--> - + diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml index 778c85aaa0..3f5a42ece0 100644 --- a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml @@ -159,7 +159,7 @@ config--> - + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.yaml deleted file mode 100644 index 3c19b4f50f..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_distancer.yaml +++ /dev/null @@ -1,453 +0,0 @@ -category: application -doc: | - Configuration/settings of a paraprobe-distancer software tool run. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. -type: group -NXapm_paraprobe_config_distancer(NXobject): - (NXentry): - \@version: - doc: | - Version specifier of this application definition. - definition: - doc: | - Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_config_distancer] - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - time_stamp(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: | - Possibility for leaving a free-text description about this analysis. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - number_of_processes(NX_UINT): - unit: NX_UNITLESS - doc: | - How many individual analyses should the tool execute. - (NXprocess): - dataset(NXapm_input_reconstruction): - filename: - \@version: - dataset_name_reconstruction: - dataset_name_mass_to_charge: - iontypes(NXapm_input_ranging): - filename: - \@version: - group_name_iontypes: - spatial_filter(NXspatial_filter): - exists: optional - windowing_method: - (NXcg_ellipsoid_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - half_axes_radii(NX_NUMBER): - orientation(NX_NUMBER): - (NXcg_cylinder_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - height(NX_NUMBER): - radii(NX_NUMBER): - (NXcg_hexahedron_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - hexahedra(NXcg_face_list_data_structure): - (NXcs_filter_boolean_mask): - exists: optional - number_of_objects(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - identifier(NX_UINT): - evaporation_id_filter(NXsubsampling_filter): - exists: optional - iontype_filter(NXmatch_filter): - exists: optional - hit_multiplicity_filter(NXmatch_filter): - exists: optional - point_to_triangle(NXprocess): - doc: | - Compute for all filtered points, e.g. ions of the point set - the shortest Euclidean distance to the closest triangle of the - set of triangles. The triangles can formed a closed surface mesh. - Distances are not simple distances based on normal projections but - giving an exact solution. - triangle_soup(NXprocess): - - # NEW ISSUE NXtriangle_soup - doc: | - Paraprobe-distancer enables the computation of the Euclidean shortest - distance for each member of a set of points against a set of triangles. - In contrast to comparable methods used in atom probe the here computed - distance is not simply the projected distance to one of the triangles - but the more costly but robust computation of the distance between - a point and a triangle. - - The triangles can represent for instance the facets of a triangulated - surface mesh of a model for the edge of the dataset. Such a model can - be computed with paraprobe-surfacer. Alternatively, the triangles can - be those from the set of all facets for a set of convex hulls, alpha-shapes, - or alpha wrappings about three-dimensional objects like precipitates - (computed with e.g. paraprobe-nanochem). - - Currently, the tool does not check if the respectively specified - triangle sets are consistent, what their topology is, or whether or - not they are consistently oriented. - Each dataset that is referred to in the list_of _dataset_names_vertices - should be an (Nvertices, 3) array of NX_FLOAT. Each dataset referred - to in the list_of_dataset_names_facet_indices should be an - (Nfacets, 3) array of NX_UINT. - Facet indices refer to vertex indices. These need to start at zero - and must not exceed Nvertices - 1, i.e. the identifier_offset is 0 - and vertices are indexed thus implicitly. - Facet normal vectors have to be also an array - of shape (Nfacets, 3) of NX_FLOAT. - number_of_files(NX_UINT): - unit: NX_UNITLESS - doc: | - How many triangle sets to consider. - (NXprocess): - doc: | - List of triangle sets. This design allows users to combine - multiple triangle sets. - filename: - doc: | - Name of the HDF5 file(s) which contain(s) vertex coordinates - and facet indices to describe the desired set of triangles. - \@version: - doc: | - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional - layer of reproducibility. - dataset_name_vertices: - doc: | - Absolute HDF5 path to the dataset which - specifies the array of vertex positions. - dataset_name_facet_indices: - doc: | - Absolute HDF5 path to the dataset which - specifies the array of facet indices. - dataset_name_facet_normals: - exists: optional - doc: | - Absolute HDF5 path to the dataset which - specifies the array of facet normal vectors. - method: - doc: | - Specifies for which ions/points the tool will compute distances. - The purpose of this setting is to avoid unnecessary computations - when the user requests to only compute distances of ions within a - threshold distance to the triangle soup. - - By default the distances are computed for all ions; however - the setting skin enables to compute distances only for those - ions which are not farther away located to a triangle - than threshold_distance. - enumeration: [default, skin] - threshold_distance(NX_FLOAT): - unit: NX_LENGTH - - ##MK::only required when method is skin - doc: | - Maximum distance for which distances are computed when method is skin. - - # \@units: nm - - # point_set_to_polyline_set(NXprocess): - # doc: | - # Compute the shortest Euclidean distance of all filtered points/ions - # of a point set to the closest point on the closest polyline. - # polyhedra_set_to_triangle_set(NXprocess): - # doc: | - # Compute the (shortest Euclidean) distance of all polyhedra of a set - performance(NXcs_profiling): - current_working_directory: - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 0259801d31681cbca8200fa0fc8f653a013001487c419770f15d735970553d91 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Configuration/settings of a paraprobe-distancer software tool run. -# -# -# -# -# Version specifier of this application definition. -# -# -# -# -# Official NeXus NXDL schema with which this file was written. -# -# -# -# -# -# -# -# Given name of the program/software/tool with which this NeXus -# (configuration) file was generated. -# -# -# -# Ideally program version plus build number, or commit hash or description -# of ever persistent resources where the source code of the program and -# build instructions can be found so that the program can be configured -# ideally in such a manner that the result of this computational process -# is recreatable in the same deterministic manner. -# -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when this configuration file was created. -# -# -# -# -# Ideally, a (globally persistent) unique identifier for referring -# to this analysis. -# -# -# -# -# Possibility for leaving a free-text description about this analysis. -# -# -# -# -# Path to the directory where the tool should store NeXus/HDF5 results -# of this analysis. If not specified results will be stored in the -# current working directory. -# -# -# -# -# How many individual analyses should the tool execute. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Compute for all filtered points, e.g. ions of the point set -# the shortest Euclidean distance to the closest triangle of the -# set of triangles. The triangles can formed a closed surface mesh. -# Distances are not simple distances based on normal projections but -# giving an exact solution. -# -# -# -# -# Paraprobe-distancer enables the computation of the Euclidean shortest -# distance for each member of a set of points against a set of triangles. -# In contrast to comparable methods used in atom probe the here computed -# distance is not simply the projected distance to one of the triangles -# but the more costly but robust computation of the distance between -# a point and a triangle. -# -# The triangles can represent for instance the facets of a triangulated -# surface mesh of a model for the edge of the dataset. Such a model can -# be computed with paraprobe-surfacer. Alternatively, the triangles can -# be those from the set of all facets for a set of convex hulls, alpha-shapes, -# or alpha wrappings about three-dimensional objects like precipitates -# (computed with e.g. paraprobe-nanochem). -# -# Currently, the tool does not check if the respectively specified -# triangle sets are consistent, what their topology is, or whether or -# not they are consistently oriented. -# Each dataset that is referred to in the list_of _dataset_names_vertices -# should be an (Nvertices, 3) array of NX_FLOAT. Each dataset referred -# to in the list_of_dataset_names_facet_indices should be an -# (Nfacets, 3) array of NX_UINT. -# Facet indices refer to vertex indices. These need to start at zero -# and must not exceed Nvertices - 1, i.e. the identifier_offset is 0 -# and vertices are indexed thus implicitly. -# Facet normal vectors have to be also an array -# of shape (Nfacets, 3) of NX_FLOAT. -# -# -# -# How many triangle sets to consider. -# -# -# -# -# List of triangle sets. This design allows users to combine -# multiple triangle sets. -# -# -# -# Name of the HDF5 file(s) which contain(s) vertex coordinates -# and facet indices to describe the desired set of triangles. -# -# -# -# Version identifier of the file such as a secure hash which -# documents the binary state of the file to add an additional -# layer of reproducibility. -# -# -# -# -# -# Absolute HDF5 path to the dataset which -# specifies the array of vertex positions. -# -# -# -# -# Absolute HDF5 path to the dataset which -# specifies the array of facet indices. -# -# -# -# -# Absolute HDF5 path to the dataset which -# specifies the array of facet normal vectors. -# -# -# -# -# -# -# Specifies for which ions/points the tool will compute distances. -# The purpose of this setting is to avoid unnecessary computations -# when the user requests to only compute distances of ions within a -# threshold distance to the triangle soup. -# -# By default the distances are computed for all ions; however -# the setting skin enables to compute distances only for those -# ions which are not farther away located to a triangle -# than threshold_distance. -# -# -# -# -# -# -# -# -# -# Maximum distance for which distances are computed when method is skin. -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml deleted file mode 100644 index 659f5f1894..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_tessellator.yaml +++ /dev/null @@ -1,449 +0,0 @@ -category: application -doc: | - Configuration of a paraprobe-tessellator tool run in atom probe microscopy. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - -# n_control_points: The number of control points for tessellating regions instead of tessellating the volume about ion positions. -type: group -NXapm_paraprobe_config_tessellator(NXobject): - (NXentry): - - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently - \@version: - doc: | - Version specifier of this application definition. - definition: - doc: | - Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_config_tessellator] - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: | - Possibility for leaving a free-text description about this analysis. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - time_stamp(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - number_of_processes(NX_UINT): - unit: NX_UNITLESS - doc: | - How many individual analyses should the tool execute. - (NXprocess): - dataset(NXapm_input_reconstruction): - filename: - \@version: - dataset_name_reconstruction: - dataset_name_mass_to_charge: - iontypes(NXapm_input_ranging): - filename: - \@version: - group_name_iontypes: - spatial_filter(NXspatial_filter): - exists: optional - windowing_method: - (NXcg_ellipsoid_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - half_axes_radii(NX_NUMBER): - orientation(NX_NUMBER): - (NXcg_cylinder_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - height(NX_NUMBER): - radii(NX_NUMBER): - (NXcg_hexahedron_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - hexahedra(NXcg_face_list_data_structure): - (NXcs_filter_boolean_mask): - exists: optional - number_of_objects(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - identifier(NX_UINT): - - # a perfect example for limited conditions in NeXus - # if windowing_method is entire_dataset: no constraint on existence of NXcg and NXcs instances - # if windowing_method is union_of_primitives: sum of cardinality of NXcg >= 0 - # if windowing_method is bitmasked_points: sum cardinality of NXcg := 0 and cardinality of NXcs_filter_boolean_mask == 1 - evaporation_id_filter(NXsubsampling_filter): - exists: optional - iontype_filter(NXmatch_filter): - exists: optional - hit_multiplicity_filter(NXmatch_filter): - exists: optional - ion_to_edge_distances(NXprocess): - exists: optional - doc: | - The tool enables to inject precomputed distance information for - each point which can be used for further post-processing and analysis. - filename: - doc: | - Name of an HDF5 file which contains the ion distances. - Users are responsible this file and referred to dataset under - dataset_name have an ion_distance value for each ion. - \@version: - doc: | - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional layer of - reproducibility. - dataset_name: - doc: | - Absolute HDF5 path to the dataset with distance values for each ion. - tessellating(NXprocess): - method: - doc: | - Specifies for which points the tool will compute the tessellation. - By default, a Voronoi tessellation is computed for all ions in the - filtered point cloud. - - # The value control_points will compute the tessellation for the - # provided overlay_control_points irregardless of the ion point cloud. - # This enables for instance computations as proposed by P. Felfer and - # coworkers where, for the purpose of e.g. interfacial excess quantification, - # a tessellation of the dataset into regions about manually-specified - # control points is needed. - # For this option, the overlay_control points. - enumeration: [default] - - # overlay_control_points(NXprocess): - # doc: | - # Overlaying an additional set of control points onto the reconstruction - # can be used as a first step to construct a tessellation of the dataset - # into regions to segment the dataset or construct a model for internal - # structural features in the dataset. Such an approach was suggested - # e.g. by P. Felfer et al. which use a control points to locate - # interfaces (grain/phase boundaries) in atom probe data to perform - # e.g. interfacial excess computations. The control points can be - # imported for example from some manual preprocessing of a dataset - # where the user figured these control points could be of relevance - # for the analysis. - # NEW ISSUE: dislocation lines - # exists: optional - # filename: - # doc: | - # Name of an HDF5 file which contains control point coordinates. - # \@version: - # doc: | - # Version identifier of the file such as a secure hash which - # documents the binary state of the file to add an additional - # layer of reproducibility. - # dataset_name: - # doc: | - # Absolute HDF5 path to the dataset which contains the array of - # control points. This has to be an array of shape - # (n_control_points, 3). - has_cell_volume(NX_BOOLEAN): - doc: | - Specifies if the tool should report the volume of each cell. - has_cell_neighbors(NX_BOOLEAN): - doc: | - Specifies if the tool should report the first-order neighbors of each cell. - has_cell_geometry(NX_BOOLEAN): - doc: | - Specifies if the tool should report the facets and vertices of each cell. - has_cell_edge_detection(NX_BOOLEAN): - doc: | - Specifies if the tool should report if the cell makes contact with - the tight axis-aligned bounding box about the point cloud. - This can be used to identify if the shape of the cell is affected - by the edge of the dataset or if cells are deeply enough embedded - into the point cloud so that the shape of their cells are not affected - by the presence of the boundary. - - # erosion_distance(NX_FLOAT): - # doc: | - # Maximum distance for which cells are eroded. - # unit: NX_LENGTH - # \@units: nm - # minValue: EPSILON - performance(NXcs_profiling): - current_working_directory: - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 7865be535bda4bc76ce207bee2d62dff19d30dcf9c5bb661e5eb5304b271cdfa -# -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Configuration of a paraprobe-tessellator tool run in atom probe microscopy. -# -# -# -# -# -# Version specifier of this application definition. -# -# -# -# -# Official NeXus NXDL schema with which this file was written. -# -# -# -# -# -# -# -# Given name of the program/software/tool with which this NeXus -# (configuration) file was generated. -# -# -# -# Ideally program version plus build number, or commit hash or description -# of ever persistent resources where the source code of the program and -# build instructions can be found so that the program can be configured -# ideally in such a manner that the result of this computational process -# is recreatable in the same deterministic manner. -# -# -# -# -# -# Ideally, a (globally persistent) unique identifier for referring -# to this analysis. -# -# -# -# -# Possibility for leaving a free-text description about this analysis. -# -# -# -# -# Path to the directory where the tool should store NeXus/HDF5 results -# of this analysis. If not specified results will be stored in the -# current working directory. -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when this configuration file was created. -# -# -# -# -# How many individual analyses should the tool execute. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The tool enables to inject precomputed distance information for -# each point which can be used for further post-processing and analysis. -# -# -# -# Name of an HDF5 file which contains the ion distances. -# Users are responsible this file and referred to dataset under -# dataset_name have an ion_distance value for each ion. -# -# -# -# Version identifier of the file such as a secure hash which -# documents the binary state of the file to add an additional layer of -# reproducibility. -# -# -# -# -# -# Absolute HDF5 path to the dataset with distance values for each ion. -# -# -# -# -# -# -# Specifies for which points the tool will compute the tessellation. -# By default, a Voronoi tessellation is computed for all ions in the -# filtered point cloud. -# -# -# -# -# -# -# -# -# -# Specifies if the tool should report the volume of each cell. -# -# -# -# -# Specifies if the tool should report the first-order neighbors of each cell. -# -# -# -# -# Specifies if the tool should report the facets and vertices of each cell. -# -# -# -# -# Specifies if the tool should report if the cell makes contact with -# the tight axis-aligned bounding box about the point cloud. -# This can be used to identify if the shape of the cell is affected -# by the edge of the dataset or if cells are deeply enough embedded -# into the point cloud so that the shape of their cells are not affected -# by the presence of the boundary. -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml new file mode 100644 index 0000000000..1bb9da3422 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml @@ -0,0 +1,141 @@ +category: application +doc: | + Application definition for a configuration file of the paraprobe-distancer tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. +type: group +NXapm_paraprobe_distancer_config(NXobject): + (NXentry): + exists: [min, 1, max, 1] + definition(NX_CHAR): + \@version(NX_CHAR): + enumeration: [NXapm_paraprobe_distancer_config] + point_to_triangle(NXapm_paraprobe_tool_config): + exists: [min, 1, max, 1] + (NXidentifier): + exists: optional + analysis_identifier(NX_UINT): + exists: recommended + reconstruction(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + position(NX_CHAR): + mass_to_charge(NX_CHAR): + ranging(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + ranging_definitions(NX_CHAR): + # filter that are here tool-specific parameter + spatial_filter(NXspatial_filter): + windowing_method(NX_CHAR): + hexahedron_set(NXcg_hexahedron_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + hexahedra(NXcg_face_list_data_structure): + vertices(NX_UINT): + cylinder_set(NXcg_cylinder_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + height(NX_NUMBER): + radii(NX_NUMBER): + ellipsoid_set(NXcg_ellipsoid_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + half_axes_radii(NX_NUMBER): + orientation(NX_NUMBER): + polyhedron_set(NXcg_polyhedron_set): + exists: optional + # TODO + bitmask(NXcs_filter_boolean_mask): + exists: optional + number_of_objects(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + # leave open if scalar or matrix + # dim: (i,) + identifier(NX_UINT): + evaporation_id_filter(NXsubsampling_filter): + exists: optional + min_incr_max(NX_INT): + iontype_filter(NXmatch_filter): + exists: optional + method(NX_CHAR): + match(NX_NUMBER): + hit_multiplicity_filter(NXmatch_filter): + exists: optional + method(NX_CHAR): + match(NX_NUMBER): + # config + method(NX_CHAR): + doc: | + Specifies for which point the tool will compute distances. + + The value *default* configures that distances are computed for all points. + The value *skin* configures that distances are computed only for those + points which are not farther away located to a triangle than + threshold_distance. + enumeration: [default, skin] + threshold_distance(NX_FLOAT): + exists: optional # required when method == skin + doc: | + Maximum distance for which distances are + computed when *method* is *skin*. + unit: NX_LENGTH + # nm + number_of_triangle_sets(NX_UINT): + doc: | + How many triangle sets to consider. + Multiple triangle sets can be defined which are + composed into one joint triangle set for the analysis. + unit: NX_UNITLESS + triangle_setID(NXserialized): + exists: [min, 1, max, infty] + doc: | + Each triangle_set that is referred to here should be a face_list_data_structure, + i.e. an array of (n_vertices, 3) of NX_FLOAT for vertex coordinates, an (n_facets, 3) + array of NX_UINT incident vertices of each facet. Vertex indices are assumed to + start at zero and must not exceed n_vertices - 1, i.e. the identifier_offset is 0. + Facet normal have to be provided as an array of (n_facets, 3) of NX_FLOAT. + type(NX_CHAR): + algorithm(NX_CHAR): + checksum(NX_CHAR): + path(NX_CHAR): + vertices(NX_CHAR): + doc: | + Absolute path in the (HDF5) file that points to the array + of vertex positions for the triangles in that triangle_set. + facet_indices(NX_CHAR): + doc: | + Absolute path in the (HDF5) file that points to the array + of facet indices for the triangles in that triangle_set. + facet_normals(NX_CHAR): + exists: optional + doc: | + Absolute path in the (HDF5) file that points to the array + of facet normal vectors for the triangles in that triangle_set. + # profiling + programID(NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + profiling(NXcs_profiling): + exists: recommended + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + current_working_directory(NX_CHAR): + # point_set_to_polyline_set(NXapm_paraprobe_tool_config): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml new file mode 100644 index 0000000000..5a294aeabd --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml @@ -0,0 +1,123 @@ +category: application +doc: | + Application definition for results files of the paraprobe-distancer tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + The paraprobe-distancer tool can be used for the computing of the shortest Euclidean distance for each + member of a set of points against a set of triangles. In contrast to most approaches in atom probe where the + distance is computed as the projected distance, this tool evaluates robustly the exact distance between + a point and a triangle. + + Triangles can represent for instance the facets of a triangulated surface mesh like those returned by + paraprobe-surfacer or any other set of triangles. Triangles do not have to be connected. + + Currently, paraprobe-distancer does not check if the respectively specified triangle sets are consistent, + what their topology is, or whether or not these triangles are consistently oriented. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_ions: | + The total number of points, i.e. ions in the reconstruction. + n_tri: | + The total number of triangles in the set. +type: group +NXapm_paraprobe_distancer_results(NXobject): + (NXentry): + exists: [min, 1, max, 1] + definition(NX_CHAR): + \@version(NX_CHAR): + enumeration: [NXapm_paraprobe_distancer_results] + # tasks + point_to_triangle(NXapm_paraprobe_tool_results): + exists: [min, 1, max, 1] + # config + analysis_identifier(NX_UINT): + config(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + window(NXcs_filter_boolean_mask): + number_of_ions(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + + # results + distance(NX_FLOAT): + doc: | # absolute value? + The shortest analytical distance of each point to their + respectively closest triangle from the joint triangle set. + unit: NX_LENGTH + dim: (n_ions,) + triangle_identifier(NX_UINT): + exists: optional + doc: | + For each point the identifier of the triangle for which the + shortest distance was found + unit: NX_UNITLESS + dim: (n_ions,) + point_identifier(NX_UINT): + exists: optional + doc: | + A support field to enable the visualization of each point + by an explicit identifier on the interval [0, n_ions - 1]. + The field can be used to visualize the points as a function + of their distance to the triangle set (e.g. via XDMF/Paraview). + unit: NX_UNITLESS + dim: (n_ions,) + sign_valid(NXcs_filter_boolean_mask): + exists: optional + doc: | + A bitmask that identifies which of the distance values is + assumed to have a consistent sign because the closest + triangle had a consistent outer unit normal defined. + + For points whose bit is set to 0 the distance is correct + but the sign is not reliable. + number_of_triangles(NX_UINT): + doc: | + Number of triangles covered by the mask. + unit: NX_UNITLESS + bitdepth(NX_UINT): + doc: | + Bitdepth of the elementary datatype that is used to store + the information content of the mask (typically 8 bit, uint8). + unit: NX_UNITLESS + mask(NX_UINT): + doc: | + The content of the mask. Like for all masks used in the tools + of the paraprobe-toolbox, padding is used when number_of_objects + is not an integer multiple of bitdepth. If padding is used, + padded bits are set to 0. + unit: NX_UNITLESS + dim: (n_ions) # a mask for points or triangles? + window_triangles(NXcs_filter_boolean_mask): + exists: optional + doc: | + A bitmask that identifies which of the triangles in the set were + considered when certain triangles have been filtered out. + number_of_objects(NX_UINT): + bitdepth(NX_UINT): + # the following field shows a good example of base class inheritance used, + # the field mask of the NXcs_filter_boolean_mask is inherited that means its docstring, + # its unit category only the dimensions are constrained strong to match the number of objects + # triangles in this case + mask(NX_UINT): + dim: (n_tri,) + # global + (NXuser): + exists: [min, 0, max, infty] + name(NX_CHAR): + (NXcoordinate_system_set): + paraprobe(NXcoordinate_system): + type(NX_CHAR): + handedness(NX_CHAR): + x(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + y(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + z(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml index 421b0ecdc2..804f851e83 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml @@ -89,7 +89,7 @@ NXapm_paraprobe_ranger_config(NXobject): # tool-specific parameter # profiling - (NXprogram): + programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml index 3d0811d529..c175b67b0d 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml @@ -58,7 +58,7 @@ NXapm_paraprobe_ranger_results(NXobject): unit: NX_UNITLESS dim: (n_ions,) # profiling - (NXprogram): + programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.yaml deleted file mode 100644 index 3ca5378087..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_distancer.yaml +++ /dev/null @@ -1,730 +0,0 @@ -category: application -doc: | - Results of a paraprobe-distancer tool run. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_ions: | - The total number of ions in the reconstruction. - n_tris: | - The total number of triangles in the set. -type: group -NXapm_paraprobe_results_distancer(NXobject): - - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently - (NXentry): - exists: ['min', '1', 'max', '1'] - \@version: - doc: | - Version specifier of this application definition. - - ##MK::begin of the tool-specific section - definition: - doc: | - Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_results_distancer] - - ##MK::end of the tool-specific section - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: | - Possibility for leaving a free-text description about this analysis. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - config_filename: - doc: | - The absolute path and name of the config file for this analysis. - \@version: - doc: | - At least SHA256 strong hash of the specific config_file for - tracking provenance. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - status: - doc: | - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - enumeration: [success, failure] - (NXuser): - exists: recommended - doc: | - If used, contact information and eventually details - of at least the person who performed this analysis. - name: - affiliation: - exists: recommended - address: - exists: optional - email: - exists: recommended - orcid: - exists: recommended - orcid_platform: - exists: recommended - telephone_number: - exists: optional - role: - exists: recommended - social_media_name: - exists: optional - social_media_platform: - exists: optional - (NXcoordinate_system_set): - doc: | - Details about the coordinate system conventions used. - (NXtransformations): - exists: ['min', '1', 'max', 'unbounded'] - doc: | - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - ##MK::begin of the tool-specific section - (NXprocess): - exists: ['min', '0', 'max', '1'] - point_to_triangle_set(NXprocess): - doc: | - The tool can be used to compute the analytical distance of each ion - to a set of triangles. - window(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies which of the ions in the dataset were - analyzed. - number_of_ions(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of ions covered by the mask. - The mask value for most may be 0. - - # which does paraprobe use - bitdepth(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - mask(NX_UINT): - unit: NX_UNITLESS - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - dimensions: - rank: 1 - dim: [[1, n_ions]] - window_triangles(NXcs_filter_boolean_mask): - exists: optional - doc: | - A bitmask which identifies which of the triangles in the set - were considered. Usually these are all but sometimes users may - wish to filter certain portions of the triangles out. - If window_triangles is not provided it means that - all triangles were taken. - number_of_triangles(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of triangles covered by the mask. - The mask value for most may be 0. - bitdepth(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - mask(NX_UINT): - unit: NX_UNITLESS - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - dimensions: - rank: 1 - dim: [[1, n_triangles]] - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - The closest analytical distance of the ions to their respectively - closest triangle from the triangle set. - dimensions: - rank: 1 - dim: [[1, i]] - sign_valid(NXcs_filter_boolean_mask): - exists: optional - doc: | - A bitmask which identifies which of the distance values - can be assumed to have a consistent sign because the closest - triangle had a consistent outer unit normal defined. - For points whose bit is set 0 the distance is correct but the - sign is not reliable. - number_of_points(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of triangles covered by the mask. - The mask value for most may be 0. - - # which does paraprobe use - bitdepth(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - mask(NX_UINT): - unit: NX_UNITLESS - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. - dimensions: - rank: 1 - dim: [[1, i]] - triangle_identifier(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - The identifier of the triangle that is closest for each ion. - dimensions: - rank: 1 - dim: [[1, i]] - xdmf_ion_identifier(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - A support field to visualize each ion and with this the distance - informations using XDMF and e.g. Paraview. - dimensions: - rank: 1 - dim: [[1, i]] - - ##MK::end of the tool-specific section - performance(NXcs_profiling): - exists: recommended - current_working_directory: - command_line_call: - exists: optional - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - total_elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - (NXcs_computer): - exists: recommended - name: - exists: recommended - operating_system: - \@version: - uuid: - exists: optional - (NXcs_cpu): - exists: ['min', '0', 'max', 'unbounded'] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_gpu): - exists: ['min', '0', 'max', 'unbounded'] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_mm_sys): - exists: ['min', '0', 'max', '1'] - total_physical_memory(NX_NUMBER): - (NXcs_io_sys): - exists: ['min', '0', 'max', '1'] - (NXcs_io_obj): - exists: ['min', '1', 'max', 'unbounded'] - technology: - max_physical_capacity(NX_NUMBER): - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_profiling_event): - start_time(NX_DATE_TIME): - exists: optional - end_time(NX_DATE_TIME): - exists: optional - description: - elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - number_of_threads(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - number_of_gpus(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - max_virtual_memory_snapshot(NX_NUMBER): - exists: recommended - max_resident_memory_snapshot(NX_NUMBER): - exists: recommended - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# db9beb02a1f399f796e0d37bfa5d97ad75aba6c4ba62980e392a3e9b517c1442 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The total number of ions in the reconstruction. -# -# -# -# -# The total number of triangles in the set. -# -# -# -# -# Results of a paraprobe-distancer tool run. -# -# -# -# -# -# Version specifier of this application definition. -# -# -# -# -# -# Official NeXus NXDL schema with which this file was written. -# -# -# -# -# -# -# -# -# Given name of the program/software/tool with which this NeXus -# (configuration) file was generated. -# -# -# -# Ideally program version plus build number, or commit hash or description -# of ever persistent resources where the source code of the program and -# build instructions can be found so that the program can be configured -# ideally in such a manner that the result of this computational process -# is recreatable in the same deterministic manner. -# -# -# -# -# -# Ideally, a (globally persistent) unique identifier for referring -# to this analysis. -# -# -# -# -# Possibility for leaving a free-text description about this analysis. -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when the analysis behind this results file -# was started, i.e. the paraprobe-tool executable started as a process. -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when the analysis behind this results file -# were completed and the paraprobe-tool executable exited as a process. -# -# -# -# -# The absolute path and name of the config file for this analysis. -# -# -# -# At least SHA256 strong hash of the specific config_file for -# tracking provenance. -# -# -# -# -# -# Path to the directory where the tool should store NeXus/HDF5 results -# of this analysis. If not specified results will be stored in the -# current working directory. -# -# -# -# -# A statement whether the paraprobe-tool executable managed to -# process the analysis or failed prematurely. -# -# This status is written to the results file after the end_time -# at which point the executable must not compute any analysis. -# Only when this status message is present and shows `success`, the -# user should consider the results. In all other cases it might be -# that the executable has terminated prematurely or another error -# occurred. -# -# -# -# -# -# -# -# -# If used, contact information and eventually details -# of at least the person who performed this analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Details about the coordinate system conventions used. -# -# -# -# The individual coordinate systems which should be used. -# Field names should be prefixed with the following controlled terms -# indicating which individual coordinate system is described: -# -# * paraprobe -# * lab -# * specimen -# * laser -# * leap -# * detector -# * recon -# -# -# -# -# -# -# -# The tool can be used to compute the analytical distance of each ion -# to a set of triangles. -# -# -# -# A bitmask which identifies which of the ions in the dataset were -# analyzed. -# -# -# -# Number of ions covered by the mask. -# The mask value for most may be 0. -# -# -# -# -# -# Number of bits assumed matching on a default datatype. -# (e.g. 8 bits for a C-style uint8). -# -# -# -# -# The unsigned integer array representing the content of the mask. -# If padding is used the padded bits are set to 0. The mask is for -# convenience always as large as the entire dataset as it will -# be stored compressed anyway. The convenience feature with this -# is that then the mask can be decoded with numpy and mirrored -# against the evaporation_id array and one immediately can filter -# out all points that were used by the paraprobe. -# The length of the array adds to the next unsigned integer -# if the number of ions in the dataset is not an integer -# multiple of the bitdepth. -# -# -# -# -# -# -# -# -# A bitmask which identifies which of the triangles in the set -# were considered. Usually these are all but sometimes users may -# wish to filter certain portions of the triangles out. -# If window_triangles is not provided it means that -# all triangles were taken. -# -# -# -# Number of triangles covered by the mask. -# The mask value for most may be 0. -# -# -# -# -# Number of bits assumed matching on a default datatype. -# (e.g. 8 bits for a C-style uint8). -# -# -# -# -# The unsigned integer array representing the content of the mask. -# If padding is used the padded bits are set to 0. The mask is for -# convenience always as large as the entire dataset as it will -# be stored compressed anyway. The convenience feature with this -# is that then the mask can be decoded with numpy and mirrored -# against the evaporation_id array and one immediately can filter -# out all points that were used by the paraprobe. -# The length of the array adds to the next unsigned integer -# if the number of ions in the dataset is not an integer -# multiple of the bitdepth. -# -# -# -# -# -# -# -# -# The closest analytical distance of the ions to their respectively -# closest triangle from the triangle set. -# -# -# -# -# -# -# -# A bitmask which identifies which of the distance values -# can be assumed to have a consistent sign because the closest -# triangle had a consistent outer unit normal defined. -# For points whose bit is set 0 the distance is correct but the -# sign is not reliable. -# -# -# -# Number of triangles covered by the mask. -# The mask value for most may be 0. -# -# -# -# -# -# Number of bits assumed matching on a default datatype. -# (e.g. 8 bits for a C-style uint8). -# -# -# -# -# The unsigned integer array representing the content of the mask. -# If padding is used the padded bits are set to 0. -# -# -# -# -# -# -# -# -# The identifier of the triangle that is closest for each ion. -# -# -# -# -# -# -# -# A support field to visualize each ion and with this the distance -# informations using XDMF and e.g. Paraview. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Specify if it was different from the number_of_processes -# in the NXcs_profiling super class. -# -# -# -# -# -# Specify if it was different from the number_of_threads -# in the NXcs_profiling super class. -# -# -# -# -# -# Specify if it was different from the number_of_threads -# in the NXcs_profiling super class. -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.yaml deleted file mode 100644 index 351fd374a5..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_tessellator.yaml +++ /dev/null @@ -1,1284 +0,0 @@ -category: application -doc: | - Results of a paraprobe-tessellator tool run. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_ions: | - The total number of ions in the reconstruction. - n_f_xdmf: | - The total number of facets/polygons defining the tessellation. -type: group -NXapm_paraprobe_results_tessellator(NXobject): - - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently - (NXentry): - exists: ['min', '1', 'max', '1'] - \@version: - doc: | - Version specifier of this application definition. - - ##MK::begin of the tool-specific section - definition: - doc: | - Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_results_tessellator] - - ##MK::end of the tool-specific section - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: | - Possibility for leaving a free-text description about this analysis. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - config_filename: - doc: | - The absolute path and name of the config file for this analysis. - \@version: - doc: | - At least SHA256 strong hash of the specific config_file for - tracking provenance. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - status: - doc: | - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - enumeration: [success, failure] - (NXuser): - exists: recommended - doc: | - If used, contact information and eventually details - of at least the person who performed this analysis. - name: - affiliation: - exists: recommended - address: - exists: optional - email: - exists: recommended - orcid: - exists: recommended - orcid_platform: - exists: recommended - telephone_number: - exists: optional - role: - exists: recommended - social_media_name: - exists: optional - social_media_platform: - exists: optional - (NXcoordinate_system_set): - doc: | - Details about the coordinate system conventions used. - (NXtransformations): - exists: ['min', '1', 'max', 'unbounded'] - doc: | - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - ##MK::begin of the tool-specific section - (NXprocess): - exists: ['min', '0', 'max', '1'] - voronoi_tessellation(NXprocess): - doc: | - The tool can be used to compute a Voronoi tessellation the entire - or a sub-set of the reconstruction. The point cloud in the ROI is - wrapped into a tight axis-aligned bounding box. The tool detects if - Voronoi cells make contact with the walls of this bounding box. - The tessellation is computed without periodic boundary conditions. - window(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies which of the ions in the dataset were - analyzed. - number_of_ions(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of ions covered by the mask. - The mask value for most may be 0. - - # which does paraprobe use - bitdepth(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - mask(NX_UINT): - unit: NX_UNITLESS - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - dimensions: - rank: 1 - dim: [[1, n_ions]] - wall_contact_global(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies which of points have Voronoi cells that - are truncated by the global axis-aligned bounding box, i.e. boundaries - of the threads are ignored. - number_of_ions(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of points covered by the mask. - The mask value for most may be 0. - - # which does paraprobe use - bitdepth(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - mask(NX_UINT): - unit: NX_UNITLESS - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - dimensions: - rank: 1 - dim: [[1, i]] - - ##MK::optional documenting of touching on thread-local boundaries - wall_contact_left(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies which of points have Voronoi cells that - are truncated by a specific wall of the axis-aligned bounding box. - The left wall has the negative x axis of the paraprobe coordinate - system as the outer unit normal. - number_of_ions(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of points covered by the mask. - The mask value for most may be 0. - - # which does paraprobe use - bitdepth(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - mask(NX_UINT): - unit: NX_UNITLESS - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - dimensions: - rank: 1 - dim: [[1, i]] - wall_contact_right(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies which of points have Voronoi cells that - are truncated by a specific wall of the axis-aligned bounding box. - The right wall has the positive x axis of the paraprobe coordinate - system as the outer unit normal. - number_of_ions(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of points covered by the mask. - The mask value for most may be 0. - - # which does paraprobe use - bitdepth(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - mask(NX_UINT): - unit: NX_UNITLESS - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - dimensions: - rank: 1 - dim: [[1, i]] - wall_contact_front(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies which of points have Voronoi cells that - are truncated by a specific wall of the axis-aligned bounding box. - The front wall has the negative y axis of the paraprobe coordinate - system as the outer unit normal. - number_of_ions(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of points covered by the mask. - The mask value for most may be 0. - - # which does paraprobe use - bitdepth(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - mask(NX_UINT): - unit: NX_UNITLESS - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - dimensions: - rank: 1 - dim: [[1, i]] - wall_contact_rear(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies which of points have Voronoi cells that - are truncated by a specific wall of the axis-aligned bounding box. - The rear wall has the positive y axis of the paraprobe coordinate - system as the outer unit normal. - number_of_ions(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of points covered by the mask. - The mask value for most may be 0. - - # which does paraprobe use - bitdepth(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - mask(NX_UINT): - unit: NX_UNITLESS - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - dimensions: - rank: 1 - dim: [[1, i]] - wall_contact_bottom(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies which of points have Voronoi cells that - are truncated by a specific wall of the axis-aligned bounding box. - The left wall has the negative z axis of the paraprobe coordinate - system as the outer unit normal. - number_of_ions(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of points covered by the mask. - The mask value for most may be 0. - - # which does paraprobe use - bitdepth(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - mask(NX_UINT): - unit: NX_UNITLESS - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - dimensions: - rank: 1 - dim: [[1, i]] - wall_contact_top(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies which of points have Voronoi cells that - are truncated by a specific wall of the axis-aligned bounding box. - The left wall has the positive z axis of the paraprobe coordinate - system as the outer unit normal. - number_of_ions(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of points covered by the mask. - The mask value for most may be 0. - - # which does paraprobe use - bitdepth(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - mask(NX_UINT): - unit: NX_UNITLESS - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - dimensions: - rank: 1 - dim: [[1, i]] - voronoi_cells(NXcg_polyhedron_set): - exists: optional - dimensionality(NX_POSINT): - unit: NX_UNITLESS - enumeration: [3] - cardinality(NX_POSINT): - unit: NX_UNITLESS - volume(NX_NUMBER): - unit: NX_VOLUME - doc: | - Interior volume - dimensions: - rank: 1 - dim: [[1, i]] - process_identifier(NX_POSINT): - exists: optional - unit: NX_UNITLESS - doc: | - By which MPI process was the Voronoi cell computed. - dimensions: - rank: 1 - dim: [[1, i]] - thread_identifier(NX_POSINT): - exists: optional - unit: NX_UNITLESS - doc: | - By which OpenMP thread was the Voronoi cell computed. - dimensions: - rank: 1 - dim: [[1, i]] - number_of_faces(NX_POSINT): - exists: optional - unit: NX_UNITLESS - doc: | - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. This field can be used to interpret - the array/field with the individual area values for each face. - dimensions: - rank: 1 - dim: [[1, i]] - - # (NXtransformations): - # exists: optional - # doc: | - # Reference to or definition of a coordinate system with - # which the qualifiers and mesh data are interpretable. - # substantially more detailed descriptors of the shape, the mesh - identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer which specifies the first index to be used for distinguishing - polyhedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - identifier(NX_INT): - exists: optional - unit: NX_UNITLESS - doc: | - Integer used to distinguish polyhedra for explicit indexing. - dimensions: - rank: 1 - dim: [[1, i]] - polyhedra(NXcg_face_list_data_structure): - exists: ['min', '0', 'max', '1'] - doc: | - A simple approach to describe the entire set of polyhedra when - the main intention is to store the shape of the polyhedra for - visualization. - dimensionality(NX_POSINT): - unit: NX_UNITLESS - number_of_vertices(NX_POSINT): - unit: NX_UNITLESS - doc: | - Number of vertices. - number_of_faces(NX_POSINT): - unit: NX_UNITLESS - doc: | - Number of faces. - vertex_identifier_offset(NX_INT): - unit: NX_UNITLESS - face_identifier_offset(NX_INT): - unit: NX_UNITLESS - vertices(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, i], [2, 3]] - xdmf_topology(NX_UINT): - unit: NX_UNITLESS - doc: | - A sequence of always first an XDMF topology type key, followed - by the XDMF number of vertices of the polygon, followed by - the vertex identifier which define the facet polygon. First - we store the polygon of the first facet of the first cell, then - the second facet of the first cell, until the last facet of the - first cell, followed by the first facet of the second cell, - and so on and so forth. - dimensions: - rank: 1 - dim: [[1, j]] - xdmf_cell_identifier(NX_UINT): - unit: NX_UNITLESS - doc: | - A sequence of cell identifier so that each facet is associated - with its cell because of which it is then possible to segment - out cells three-dimensionally based on cell i.e. evaporation_id. - dimensions: - rank: 1 - dim: [[1, n_f_xdmf]] - - ##MK::end of the tool-specific section - performance(NXcs_profiling): - exists: recommended - current_working_directory: - command_line_call: - exists: optional - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - total_elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - (NXcs_computer): - exists: recommended - name: - exists: recommended - operating_system: - \@version: - uuid: - exists: optional - (NXcs_cpu): - exists: ['min', '0', 'max', 'unbounded'] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_gpu): - exists: ['min', '0', 'max', 'unbounded'] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_mm_sys): - exists: ['min', '0', 'max', '1'] - total_physical_memory(NX_NUMBER): - (NXcs_io_sys): - exists: ['min', '0', 'max', '1'] - (NXcs_io_obj): - exists: ['min', '1', 'max', 'unbounded'] - technology: - max_physical_capacity(NX_NUMBER): - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_profiling_event): - start_time(NX_DATE_TIME): - exists: optional - end_time(NX_DATE_TIME): - exists: optional - description: - elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - number_of_threads(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - number_of_gpus(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - max_virtual_memory_snapshot(NX_NUMBER): - exists: recommended - max_resident_memory_snapshot(NX_NUMBER): - exists: recommended - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8ec5c3b4cc5fa3566c8de12c5be7e9e8690840d962a5ee897b491e67196f1ea0 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The total number of ions in the reconstruction. -# -# -# -# -# The total number of facets/polygons defining the tessellation. -# -# -# -# -# Results of a paraprobe-tessellator tool run. -# -# -# -# -# -# Version specifier of this application definition. -# -# -# -# -# -# Official NeXus NXDL schema with which this file was written. -# -# -# -# -# -# -# -# -# Given name of the program/software/tool with which this NeXus -# (configuration) file was generated. -# -# -# -# Ideally program version plus build number, or commit hash or description -# of ever persistent resources where the source code of the program and -# build instructions can be found so that the program can be configured -# ideally in such a manner that the result of this computational process -# is recreatable in the same deterministic manner. -# -# -# -# -# -# Ideally, a (globally persistent) unique identifier for referring -# to this analysis. -# -# -# -# -# Possibility for leaving a free-text description about this analysis. -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when the analysis behind this results file -# was started, i.e. the paraprobe-tool executable started as a process. -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when the analysis behind this results file -# were completed and the paraprobe-tool executable exited as a process. -# -# -# -# -# The absolute path and name of the config file for this analysis. -# -# -# -# At least SHA256 strong hash of the specific config_file for -# tracking provenance. -# -# -# -# -# -# Path to the directory where the tool should store NeXus/HDF5 results -# of this analysis. If not specified results will be stored in the -# current working directory. -# -# -# -# -# A statement whether the paraprobe-tool executable managed to -# process the analysis or failed prematurely. -# -# This status is written to the results file after the end_time -# at which point the executable must not compute any analysis. -# Only when this status message is present and shows `success`, the -# user should consider the results. In all other cases it might be -# that the executable has terminated prematurely or another error -# occurred. -# -# -# -# -# -# -# -# -# If used, contact information and eventually details -# of at least the person who performed this analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Details about the coordinate system conventions used. -# -# -# -# The individual coordinate systems which should be used. -# Field names should be prefixed with the following controlled terms -# indicating which individual coordinate system is described: -# -# * paraprobe -# * lab -# * specimen -# * laser -# * leap -# * detector -# * recon -# -# -# -# -# -# -# -# The tool can be used to compute a Voronoi tessellation the entire -# or a sub-set of the reconstruction. The point cloud in the ROI is -# wrapped into a tight axis-aligned bounding box. The tool detects if -# Voronoi cells make contact with the walls of this bounding box. -# The tessellation is computed without periodic boundary conditions. -# -# -# -# A bitmask which identifies which of the ions in the dataset were -# analyzed. -# -# -# -# Number of ions covered by the mask. -# The mask value for most may be 0. -# -# -# -# -# -# Number of bits assumed matching on a default datatype. -# (e.g. 8 bits for a C-style uint8). -# -# -# -# -# The unsigned integer array representing the content of the mask. -# If padding is used the padded bits are set to 0. The mask is for -# convenience always as large as the entire dataset as it will -# be stored compressed anyway. The convenience feature with this -# is that then the mask can be decoded with numpy and mirrored -# against the evaporation_id array and one immediately can filter -# out all points that were used by the paraprobe. -# The length of the array adds to the next unsigned integer -# if the number of ions in the dataset is not an integer -# multiple of the bitdepth. -# -# -# -# -# -# -# -# -# A bitmask which identifies which of points have Voronoi cells that -# are truncated by the global axis-aligned bounding box, i.e. boundaries -# of the threads are ignored. -# -# -# -# Number of points covered by the mask. -# The mask value for most may be 0. -# -# -# -# -# -# Number of bits assumed matching on a default datatype. -# (e.g. 8 bits for a C-style uint8). -# -# -# -# -# The unsigned integer array representing the content of the mask. -# If padding is used the padded bits are set to 0. The mask is for -# convenience always as large as the entire dataset as it will -# be stored compressed anyway. The convenience feature with this -# is that then the mask can be decoded with numpy and mirrored -# against the evaporation_id array and one immediately can filter -# out all points that were used by the paraprobe. -# The length of the array adds to the next unsigned integer -# if the number of ions in the dataset is not an integer -# multiple of the bitdepth. -# -# -# -# -# -# -# -# -# -# A bitmask which identifies which of points have Voronoi cells that -# are truncated by a specific wall of the axis-aligned bounding box. -# The left wall has the negative x axis of the paraprobe coordinate -# system as the outer unit normal. -# -# -# -# Number of points covered by the mask. -# The mask value for most may be 0. -# -# -# -# -# -# Number of bits assumed matching on a default datatype. -# (e.g. 8 bits for a C-style uint8). -# -# -# -# -# The unsigned integer array representing the content of the mask. -# If padding is used the padded bits are set to 0. The mask is for -# convenience always as large as the entire dataset as it will -# be stored compressed anyway. The convenience feature with this -# is that then the mask can be decoded with numpy and mirrored -# against the evaporation_id array and one immediately can filter -# out all points that were used by the paraprobe. -# The length of the array adds to the next unsigned integer -# if the number of ions in the dataset is not an integer -# multiple of the bitdepth. -# -# -# -# -# -# -# -# -# A bitmask which identifies which of points have Voronoi cells that -# are truncated by a specific wall of the axis-aligned bounding box. -# The right wall has the positive x axis of the paraprobe coordinate -# system as the outer unit normal. -# -# -# -# Number of points covered by the mask. -# The mask value for most may be 0. -# -# -# -# -# -# Number of bits assumed matching on a default datatype. -# (e.g. 8 bits for a C-style uint8). -# -# -# -# -# The unsigned integer array representing the content of the mask. -# If padding is used the padded bits are set to 0. The mask is for -# convenience always as large as the entire dataset as it will -# be stored compressed anyway. The convenience feature with this -# is that then the mask can be decoded with numpy and mirrored -# against the evaporation_id array and one immediately can filter -# out all points that were used by the paraprobe. -# The length of the array adds to the next unsigned integer -# if the number of ions in the dataset is not an integer -# multiple of the bitdepth. -# -# -# -# -# -# -# -# -# A bitmask which identifies which of points have Voronoi cells that -# are truncated by a specific wall of the axis-aligned bounding box. -# The front wall has the negative y axis of the paraprobe coordinate -# system as the outer unit normal. -# -# -# -# Number of points covered by the mask. -# The mask value for most may be 0. -# -# -# -# -# -# Number of bits assumed matching on a default datatype. -# (e.g. 8 bits for a C-style uint8). -# -# -# -# -# The unsigned integer array representing the content of the mask. -# If padding is used the padded bits are set to 0. The mask is for -# convenience always as large as the entire dataset as it will -# be stored compressed anyway. The convenience feature with this -# is that then the mask can be decoded with numpy and mirrored -# against the evaporation_id array and one immediately can filter -# out all points that were used by the paraprobe. -# The length of the array adds to the next unsigned integer -# if the number of ions in the dataset is not an integer -# multiple of the bitdepth. -# -# -# -# -# -# -# -# -# A bitmask which identifies which of points have Voronoi cells that -# are truncated by a specific wall of the axis-aligned bounding box. -# The rear wall has the positive y axis of the paraprobe coordinate -# system as the outer unit normal. -# -# -# -# Number of points covered by the mask. -# The mask value for most may be 0. -# -# -# -# -# -# Number of bits assumed matching on a default datatype. -# (e.g. 8 bits for a C-style uint8). -# -# -# -# -# The unsigned integer array representing the content of the mask. -# If padding is used the padded bits are set to 0. The mask is for -# convenience always as large as the entire dataset as it will -# be stored compressed anyway. The convenience feature with this -# is that then the mask can be decoded with numpy and mirrored -# against the evaporation_id array and one immediately can filter -# out all points that were used by the paraprobe. -# The length of the array adds to the next unsigned integer -# if the number of ions in the dataset is not an integer -# multiple of the bitdepth. -# -# -# -# -# -# -# -# -# A bitmask which identifies which of points have Voronoi cells that -# are truncated by a specific wall of the axis-aligned bounding box. -# The left wall has the negative z axis of the paraprobe coordinate -# system as the outer unit normal. -# -# -# -# Number of points covered by the mask. -# The mask value for most may be 0. -# -# -# -# -# -# Number of bits assumed matching on a default datatype. -# (e.g. 8 bits for a C-style uint8). -# -# -# -# -# The unsigned integer array representing the content of the mask. -# If padding is used the padded bits are set to 0. The mask is for -# convenience always as large as the entire dataset as it will -# be stored compressed anyway. The convenience feature with this -# is that then the mask can be decoded with numpy and mirrored -# against the evaporation_id array and one immediately can filter -# out all points that were used by the paraprobe. -# The length of the array adds to the next unsigned integer -# if the number of ions in the dataset is not an integer -# multiple of the bitdepth. -# -# -# -# -# -# -# -# -# A bitmask which identifies which of points have Voronoi cells that -# are truncated by a specific wall of the axis-aligned bounding box. -# The left wall has the positive z axis of the paraprobe coordinate -# system as the outer unit normal. -# -# -# -# Number of points covered by the mask. -# The mask value for most may be 0. -# -# -# -# -# -# Number of bits assumed matching on a default datatype. -# (e.g. 8 bits for a C-style uint8). -# -# -# -# -# The unsigned integer array representing the content of the mask. -# If padding is used the padded bits are set to 0. The mask is for -# convenience always as large as the entire dataset as it will -# be stored compressed anyway. The convenience feature with this -# is that then the mask can be decoded with numpy and mirrored -# against the evaporation_id array and one immediately can filter -# out all points that were used by the paraprobe. -# The length of the array adds to the next unsigned integer -# if the number of ions in the dataset is not an integer -# multiple of the bitdepth. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Interior volume -# -# -# -# -# -# -# -# By which MPI process was the Voronoi cell computed. -# -# -# -# -# -# -# -# By which OpenMP thread was the Voronoi cell computed. -# -# -# -# -# -# -# -# The number of faces for each polyhedron. Faces of adjoining polyhedra -# are counted for each polyhedron. This field can be used to interpret -# the array/field with the individual area values for each face. -# -# -# -# -# -# -# -# -# Integer which specifies the first index to be used for distinguishing -# polyhedra. Identifiers are defined either implicitly -# or explicitly. For implicit indexing the identifiers are defined on the -# interval [identifier_offset, identifier_offset+c-1]. -# For explicit indexing the identifier array has to be defined. -# -# -# -# -# Integer used to distinguish polyhedra for explicit indexing. -# -# -# -# -# -# -# -# A simple approach to describe the entire set of polyhedra when -# the main intention is to store the shape of the polyhedra for -# visualization. -# -# -# -# -# Number of vertices. -# -# -# -# -# Number of faces. -# -# -# -# -# -# -# -# -# -# -# -# -# A sequence of always first an XDMF topology type key, followed -# by the XDMF number of vertices of the polygon, followed by -# the vertex identifier which define the facet polygon. First -# we store the polygon of the first facet of the first cell, then -# the second facet of the first cell, until the last facet of the -# first cell, followed by the first facet of the second cell, -# and so on and so forth. -# -# -# -# -# -# -# -# A sequence of cell identifier so that each facet is associated -# with its cell because of which it is then possible to segment -# out cells three-dimensionally based on cell i.e. evaporation_id. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Specify if it was different from the number_of_processes -# in the NXcs_profiling super class. -# -# -# -# -# -# Specify if it was different from the number_of_threads -# in the NXcs_profiling super class. -# -# -# -# -# -# Specify if it was different from the number_of_threads -# in the NXcs_profiling super class. -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml index a5820e7557..765816455a 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml @@ -82,7 +82,7 @@ NXapm_paraprobe_selector_config(NXobject): match(NX_NUMBER): # profiling - (NXprogram): + programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml index d1e1d5712c..d99dd54fd1 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml @@ -32,7 +32,7 @@ NXapm_paraprobe_selector_results(NXobject): bitdepth(NX_UINT): mask(NX_UINT): # profiling - (NXprogram): + programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_config.yaml index b72b66e520..dae62ec5cb 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_config.yaml @@ -81,6 +81,9 @@ NXapm_paraprobe_surfacer_config(NXobject): method(NX_CHAR): match(NX_NUMBER): hit_multiplicity_filter(NXmatch_filter): + exists: optional + method(NX_CHAR): + match(NX_NUMBER): # config preprocessing(NXprocess): method(NX_CHAR): @@ -156,7 +159,7 @@ NXapm_paraprobe_surfacer_config(NXobject): of the alpha complex (currently only for alpha shapes). # NEW ISSUE: has_facet_appearance(NX_BOOLEAN): # profiling - (NXprogram): + programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml new file mode 100644 index 0000000000..96bd70dee2 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml @@ -0,0 +1,136 @@ +category: application +doc: | + Application definition for a configuration file of the paraprobe-tessellator tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. +# n_control_points: The number of control points for tessellating regions instead of tessellating the volume about ion positions. +# an example for limited conditions in NeXus +# if windowing_method is entire_dataset: no constraint on existence of NXcg and NXcs instances +# if windowing_method is union_of_primitives: sum of cardinality of NXcg >= 0 +# if windowing_method is bitmasked_points: sum cardinality of NXcg := 0 and cardinality of NXcs_filter_boolean_mask == 1 +type: group +NXapm_paraprobe_tessellator_config(NXobject): + (NXentry): + exists: [min, 1, max, 1] + definition(NX_CHAR): + \@version(NX_CHAR): + enumeration: [NXapm_paraprobe_tessellator_config] + tessellate(NXapm_paraprobe_tool_config): + exists: [min, 1, max, 1] + (NXidentifier): + exists: optional + analysis_identifier(NX_UINT): + exists: recommended + reconstruction(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + position(NX_CHAR): + mass_to_charge(NX_CHAR): + ranging(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + ranging_definitions(NX_CHAR): + ion_to_edge_distance(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + distance(NX_CHAR): + doc: | + Absolute in the (HDF5) file that points to the + distance values. The tool assumes that the + values are stored in the same order as the + points. + # filter that are here tool-specific parameter + spatial_filter(NXspatial_filter): + windowing_method(NX_CHAR): + hexahedron_set(NXcg_hexahedron_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + hexahedra(NXcg_face_list_data_structure): + vertices(NX_UINT): + cylinder_set(NXcg_cylinder_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + height(NX_NUMBER): + radii(NX_NUMBER): + ellipsoid_set(NXcg_ellipsoid_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + half_axes_radii(NX_NUMBER): + orientation(NX_NUMBER): + polyhedron_set(NXcg_polyhedron_set): + exists: optional + # TODO + bitmask(NXcs_filter_boolean_mask): + exists: optional + number_of_objects(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + # leave open if scalar or matrix + # dim: (i,) + identifier(NX_UINT): + evaporation_id_filter(NXsubsampling_filter): + exists: optional + min_incr_max(NX_INT): + iontype_filter(NXmatch_filter): + exists: optional + method(NX_CHAR): + match(NX_NUMBER): + hit_multiplicity_filter(NXmatch_filter): + exists: optional + method(NX_CHAR): + match(NX_NUMBER): + # config + method(NX_CHAR): + doc: | + The method used to compute the tessellation. + The value *default* configures the computation of the Voronoi tessellation. + # check versions prior paraprobe-toolbox v0.5 for control_point-based method + enumeration: [default] + has_cell_volume(NX_BOOLEAN): + doc: | + Specifies if the tool should report the volume of each cell. + has_cell_neighbors(NX_BOOLEAN): + doc: | + Specifies if the tool should report the first-order neighbors of each cell. + has_cell_geometry(NX_BOOLEAN): + doc: | + Specifies if the tool should report the facets and vertices of each cell. + has_cell_edge_detection(NX_BOOLEAN): + doc: | + Specifies if the tool should report for each cell if it makes contact with + the tight axis-aligned bounding box about the point cloud. + This can be used to identify if the shape of the cell is likely affected + by the edge of the dataset or if cells are deeply enough embedded + into the point cloud so that the shape of their cells are not affected + anymore by the boundary. This is valuable information to judge + about the significance of finite size effects. + # erosion_distance(NX_FLOAT): + # doc: | + # Maximum distance for which cells are eroded. + # unit: NX_LENGTH + # \@units: nm + # minValue: EPSILON + # profiling + programID(NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + profiling(NXcs_profiling): + exists: recommended + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + current_working_directory(NX_CHAR): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml new file mode 100644 index 0000000000..a5185f276b --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml @@ -0,0 +1,214 @@ +category: application +doc: | + Application definition for results files of the paraprobe-tessellator tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_ions: | + The total number of ions in the reconstruction. + n_f: | + The total number of values required to represent all faces of each cell. + n_f_xdmf: | + The total number of values required to represent all faces of each cell (polyhedron) using XDMF. +type: group +NXapm_paraprobe_tessellator_results(NXobject): + (NXentry): + exists: [min, 1, max, 1] + definition(NX_CHAR): + \@version(NX_CHAR): + enumeration: [NXapm_paraprobe_tessellator_results] + # tasks + tessellation(NXapm_paraprobe_tool_results): + exists: [min, 1, max, 1] + doc: | + The tool can be used to compute a Voronoi tessellation the entire + or of a sub-set of the reconstructed volume. Each point (ion) is wrapped + in one (Voronoi) cell. The point cloud in the ROI is wrapped into an + axis-aligned bounding box (AABB) that is tight. This means points at + the edge of the point cloud can lay on the surface of the bounding box. + The tool detects if cells make contact with the walls of this bounding box. + The tessellation is computed without periodic boundary conditions. + # config + analysis_identifier(NX_UINT): + config(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + window(NXcs_filter_boolean_mask): + number_of_ions(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + # results + wall(NXcg_hexahedron_set): + exists: recommended + doc: | + The (tight) axis-aligned bounding box about the point cloud. + closest_corner(NX_FLOAT): + doc: | + Coordinate triplet of the corner that lays closests + to the origin of the *paraprobe* coordinate system. + unit: NX_LENGTH + dim: (3,) + farthest_corner(NX_FLOAT): + doc: | + Coordinate triplet of the corner that lays farthest away + from the origin of the *paraprobe* coordinate system. + unit: NX_LENGTH + dim: (3,) + voronoi_cells(NXcg_polyhedron_set): + exists: optional + dimensionality(NX_POSINT): + unit: NX_UNITLESS + enumeration: [3] + cardinality(NX_POSINT): + doc: | + The number of points (and thus cells). + unit: NX_UNITLESS + volume(NX_FLOAT): + doc: | + Volume of each Voronoi cell. + unit: NX_VOLUME + dim: (n_ions,) + process_identifier(NX_POSINT): + exists: optional + doc: | + Which MPI process computed which Voronoi cell. + unit: NX_UNITLESS + dim: (n_ions,) + thread_identifier(NX_POSINT): + exists: optional + doc: | + Which OpenMP thread computed which Voronoi cell. + unit: NX_UNITLESS + dim: (n_ions,) + number_of_faces(NX_INT): + exists: optional + doc: | + The number of faces for each cell. Faces of adjoining polyhedra are counted + for each polyhedron. This field can be used to interpret the concatenated vector + with the individual values for the area of each face. + unit: NX_UNITLESS + dim: (n_ions,) + identifier_offset(NX_INT): + polyhedra(NXcg_face_list_data_structure): + exists: optional + doc: | + A simple approach to describe the entire set of polyhedra when the main + intention is to store the shape of the polyhedra for visualization purposes. + number_of_vertices(NX_INT): + number_of_faces(NX_INT): + vertex_identifier_offset(NX_INT): + face_identifier_offset(NX_INT): + vertices(NX_FLOAT): + xdmf_topology(NX_UINT): + doc: | + Sequence of tuples, concatenated in the order of the Voronoi cells. + Each tuple contains encodes information to visualize using XDMF: + Firstly, an XDMF geometric primitive type key. + Secondly, the number of vertices of the polygon. + Third, the sequence of vertex identifier which define the facet. + Tuples encode faces faster than cells. + unit: NX_UNITLESS + dim: (n_f_xdmf,) # not n_f because primitive key and number of faces in each tuple! + xdmf_cell_identifier(NX_UINT): + doc: | + Sequence of cell identifier, concatenated such that each face is + associated with its cell. Given that paraprobe-tessellator assigns + each cell the evaporation_id of the ion that the cell wraps this + information enables the segmentation of the tessellation and + thus correlate per-ion properties with the volume that each cell + represents. + unit: NX_UNITLESS + dim: (n_f,) + wall_contact_global(NXcs_filter_boolean_mask): + exists: recommended + doc: | + A bitmask that documents which of the cells are likely truncated because they + share at least one face with the *aabb* of the point cloud. This field encodes the + result of the boolean or operator applied to the value of all six wall_contact groups + that document contact in specific outer unit normal directions of the *aabb*. + number_of_objects(NX_UINT): + dim: (n_ions,) + bitdepth(NX_UINT): + mask(NX_UINT): + # dim: (i,) # not necessarily n_ions because n_ions is not always an integer multiple of bitdepth + # dim: (i,) # one would not need to constrain this but doing so communicates that all six bitfields have the same length + wall_contact_left(NXcs_filter_boolean_mask): + exists: recommended + doc: | + In the spirit of wall_contact_global, the left face of *aabb*. + Its outer unit normal points in the opposite direction of the + x-axis of the *paraprobe* coordinate system. + number_of_objects(NX_UINT): + dim: (n_ions,) + bitdepth(NX_UINT): + mask(NX_UINT): + wall_contact_right(NXcs_filter_boolean_mask): + exists: recommended + doc: | + In the spirit of wall_contact_global, the right face of *aabb*. + Its outer unit normal points in the direction of the x-axis + of the *paraprobe* coordinate system. + number_of_objects(NX_UINT): + dim: (n_ions,) + bitdepth(NX_UINT): + mask(NX_UINT): + wall_contact_front(NXcs_filter_boolean_mask): + exists: recommended + doc: | + In the spirit of wall_contact_global, the front face of *aabb*. + Its outer unit normal points in the opposite direction of the + y-axis of the *paraprobe* coordinate system. + number_of_objects(NX_UINT): + dim: (n_ions,) + bitdepth(NX_UINT): + mask(NX_UINT): + wall_contact_rear(NXcs_filter_boolean_mask): + exists: recommended + doc: | + In the spirit of wall_contact_global, the rear face of *aabb*. + Its outer unit normal points in the direction of the y-axis + of the *paraprobe* coordinate system. + number_of_objects(NX_UINT): + dim: (n_ions,) + bitdepth(NX_UINT): + mask(NX_UINT): + wall_contact_bottom(NXcs_filter_boolean_mask): + exists: recommended + doc: | + In the spirit of wall_contact_global, the front face of *aabb*. + Its outer unit normal points in the opposite direction of the + z-axis of the *paraprobe* coordinate system. + number_of_objects(NX_UINT): + dim: (n_ions,) + bitdepth(NX_UINT): + mask(NX_UINT): + wall_contact_top(NXcs_filter_boolean_mask): + doc: | + In the spirit of wall_contact_global, the front face of *aabb*. + Its outer unit normal points in the direction of the z-axis of the + *paraprobe* coordinate system. + number_of_ions(NX_UINT): + dim: (n_ions,) + bitdepth(NX_UINT): + mask(NX_UINT): + # global + (NXuser): + exists: [min, 0, max, infty] + name(NX_CHAR): + (NXcoordinate_system_set): + paraprobe(NXcoordinate_system): + type(NX_CHAR): + handedness(NX_CHAR): + x(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + y(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + z(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tool_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tool_results.yaml index 29fcc4ad4b..bca0d84fd9 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tool_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tool_results.yaml @@ -19,6 +19,11 @@ doc: | The configuration and results of a run of a tool from the toolbox is documented using binary container formats. Currently, paraprobe-toolbox uses the Hierarchical Data Format 5 (HDF5). + + The paraprobe coordinate system is the reference *NXcoordinate_system* + for each geometric primitive. +# thereby implicitly all \@default attributes for geometric primitives point to the +# single instance ENTRY[entry]/COORDINATE_SYSTEM_SET[coordinate_system_set]/paraprobe # symbols: # doc: | # The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml index cf7a4610f9..4ab9e9094f 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml @@ -39,7 +39,7 @@ NXapm_paraprobe_transcoder_config(NXobject): # tool-specific parameter # filter # profiling - (NXprogram): + programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml index 3862b0d4ac..f33a9b1a8c 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml @@ -102,7 +102,7 @@ NXapm_paraprobe_transcoder_results(NXobject): dim: (i, 2) # (NXapm_charge_state_analysis): # profiling - (NXprogram): + programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): From 8ac38a55d21475fe1e28de17a1cccf33bdb98088 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Sat, 27 Jan 2024 23:58:08 +0100 Subject: [PATCH 0535/1012] Fixes added in the process of refactoring parmsetup-distancer and parmsetup-tessellator --- .../NXapm_paraprobe_distancer_config.nxdl.xml | 18 ++++++++++--- ...Xapm_paraprobe_tessellator_config.nxdl.xml | 11 ++------ .../NXapm_paraprobe_tool_config.nxdl.xml | 27 +++++++++++++++++++ .../NXapm_paraprobe_distancer_config.yaml | 17 +++++++++--- .../NXapm_paraprobe_tessellator_config.yaml | 7 +---- .../nyaml/NXapm_paraprobe_tool_config.yaml | 19 +++++++++++++ 6 files changed, 76 insertions(+), 23 deletions(-) diff --git a/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml index b2eb7e7175..1c87c03da3 100644 --- a/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml @@ -153,18 +153,28 @@ of vertex positions for the triangles in that triangle_set. - + Absolute path in the (HDF5) file that points to the array - of facet indices for the triangles in that triangle_set. + of vertex indices for the triangles in that triangle_set. - + Absolute path in the (HDF5) file that points to the array - of facet normal vectors for the triangles in that triangle_set. + of normal vectors for the triangles in that triangle_set. + + + Absolute path in the (HDF5) file that points to the array + of identifier for the triangles in that triangle_set. + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml index b1320d76d6..47bd858e31 100644 --- a/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml @@ -58,19 +58,12 @@ if windowing_method is bitmasked_points: sum cardinality of NXcg := 0 and cardin - + - - - Absolute in the (HDF5) file that points to the - distance values. The tool assumes that the - values are stored in the same order as the - points. - - + diff --git a/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml index b590abf95c..18a4c3ea80 100644 --- a/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml @@ -105,6 +105,33 @@ base class from which tool-specific appdefs inherit--> + + + Specification of the triangulated surface mesh to use for this analysis. + + Such a surface mesh can be used to define the edge of the reconstructed + volume to account for finite size effects. + + + + Name of the (parent) node directly below which (in the hierarchy) + an instance of :ref:`NXcg_triangle_set` is stored. + + + + + + Specification of the point-to-triangulated-surface-mesh distances to + use for this analysis. + + + + Absolute in the (HDF5) file that points to the distance values. + The tool assumes that the values are stored in the same order as + points (ions). + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml index 1bb9da3422..b4e95eb199 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml @@ -119,15 +119,24 @@ NXapm_paraprobe_distancer_config(NXobject): doc: | Absolute path in the (HDF5) file that points to the array of vertex positions for the triangles in that triangle_set. - facet_indices(NX_CHAR): + indices(NX_CHAR): doc: | Absolute path in the (HDF5) file that points to the array - of facet indices for the triangles in that triangle_set. - facet_normals(NX_CHAR): + of vertex indices for the triangles in that triangle_set. + normals(NX_CHAR): exists: optional doc: | Absolute path in the (HDF5) file that points to the array - of facet normal vectors for the triangles in that triangle_set. + of normal vectors for the triangles in that triangle_set. + patch(NX_CHAR): + exists: optional + doc: | + Absolute path in the (HDF5) file that points to the array + of identifier for the triangles in that triangle_set. + patch_filter(NXmatch_filter): + exists: optional + method(NX_CHAR): + match(NX_NUMBER): # profiling programID(NXprogram): exists: [min, 1, max, infty] diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml index 96bd70dee2..f1ea6d570b 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml @@ -34,17 +34,12 @@ NXapm_paraprobe_tessellator_config(NXobject): checksum(NX_CHAR): algorithm(NX_CHAR): ranging_definitions(NX_CHAR): - ion_to_edge_distance(NXserialized): + surface_distance(NXserialized): type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): distance(NX_CHAR): - doc: | - Absolute in the (HDF5) file that points to the - distance values. The tool assumes that the - values are stored in the same order as the - points. # filter that are here tool-specific parameter spatial_filter(NXspatial_filter): windowing_method(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml index b8520eefaf..87362fab57 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml @@ -69,6 +69,25 @@ NXapm_paraprobe_tool_config(NXprocess): doc: | Name of the (parent) node directly below which (in the hierarchy) the ranging definition for (molecular) ions are stored. + surface_mesh(NXserialized): + doc: | + Specification of the triangulated surface mesh to use for this analysis. + + Such a surface mesh can be used to define the edge of the reconstructed + volume to account for finite size effects. + mesh(NX_CHAR): + doc: | + Name of the (parent) node directly below which (in the hierarchy) + an instance of :ref:`NXcg_triangle_set` is stored. + surface_distance(NXserialized): + doc: | + Specification of the point-to-triangulated-surface-mesh distances to + use for this analysis. + distance(NX_CHAR): + doc: | + Absolute in the (HDF5) file that points to the distance values. + The tool assumes that the values are stored in the same order as + points (ions). # filters (NXspatial_filter): (NXsubsampling_filter): From 7c1f07269764c358fd5cc1c08b8d688e32cb2c95 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Sun, 28 Jan 2024 17:44:21 +0100 Subject: [PATCH 0536/1012] Fixes to complete distancer and tessellator APMv2 refactoring --- .../NXapm_paraprobe_distancer_config.nxdl.xml | 12 ++++-- ...Xapm_paraprobe_tessellator_config.nxdl.xml | 2 +- .../NXapm_paraprobe_distancer_config.yaml | 11 ++++-- .../NXapm_paraprobe_tessellator_config.yaml | 1 + .../contributed_definitions/apm-structure.rst | 37 ++++++------------- 5 files changed, 30 insertions(+), 33 deletions(-) diff --git a/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml index 1c87c03da3..7b78769e6d 100644 --- a/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml @@ -159,13 +159,19 @@ of vertex indices for the triangles in that triangle_set. - + Absolute path in the (HDF5) file that points to the array - of normal vectors for the triangles in that triangle_set. + of vertex normal vectors for the triangles in that triangle_set. - + + + Absolute path in the (HDF5) file that points to the array + of facet normal vectors for the triangles in that triangle_set. + + + Absolute path in the (HDF5) file that points to the array of identifier for the triangles in that triangle_set. diff --git a/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml index 47bd858e31..f9ed857db4 100644 --- a/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml @@ -58,7 +58,7 @@ if windowing_method is bitmasked_points: sum cardinality of NXcg := 0 and cardin - + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml index b4e95eb199..9ffd53a64b 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml @@ -123,12 +123,17 @@ NXapm_paraprobe_distancer_config(NXobject): doc: | Absolute path in the (HDF5) file that points to the array of vertex indices for the triangles in that triangle_set. - normals(NX_CHAR): + vertex_normals(NX_CHAR): exists: optional doc: | Absolute path in the (HDF5) file that points to the array - of normal vectors for the triangles in that triangle_set. - patch(NX_CHAR): + of vertex normal vectors for the triangles in that triangle_set. + face_normals(NX_CHAR): + exists: optional + doc: | + Absolute path in the (HDF5) file that points to the array + of facet normal vectors for the triangles in that triangle_set. + patch_identifier(NX_CHAR): exists: optional doc: | Absolute path in the (HDF5) file that points to the array diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml index f1ea6d570b..e6d85ec953 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml @@ -35,6 +35,7 @@ NXapm_paraprobe_tessellator_config(NXobject): algorithm(NX_CHAR): ranging_definitions(NX_CHAR): surface_distance(NXserialized): + exists: optional type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): diff --git a/manual/source/classes/contributed_definitions/apm-structure.rst b/manual/source/classes/contributed_definitions/apm-structure.rst index 580258ccdc..4cae11b027 100644 --- a/manual/source/classes/contributed_definitions/apm-structure.rst +++ b/manual/source/classes/contributed_definitions/apm-structure.rst @@ -234,38 +234,24 @@ tool one such pair is proposed: Store applied ranging definitions and combinatorial analyses of possible iontypes. :ref:`NXapm_paraprobe_selector_config`, :ref:`NXapm_paraprobe_selector_results`: - Configuration and results respectively of paraprobe-selector tool. + Configuration and results respectively of the paraprobe-selector tool. Defining complex spatial regions-of-interest to filter reconstructed datasets. Store which points are inside or on the boundary of complex spatial regions-of-interest. -The definitions of the following tools remain to become refactored like those for the above-mentioned tools: - - :ref:`NXapm_paraprobe_config_surfacer`: - Configuration of paraprobe-surfacer - Create a model for the edge of a point cloud via convex hulls, alpha shapes. - - :ref:`NXapm_paraprobe_results_surfacer`: - Results of paraprobe-surfacer + :ref:`NXapm_paraprobe_surfacer_config`, :ref:`NXapm_paraprobe_surfacer_results`: + Configuration and results respectively of the paraprobe-surfacer tool. + Create a model for the edge of a point cloud via convex hulls, alpha shapes, or alpha-wrappings. Store triangulated surface meshes of models for the edge of a dataset. + :ref:`NXapm_paraprobe_distancer_config`, :ref:`NXapm_paraprobe_distancer_results`: + Configuration and results respectively of the paraprobe-distancer tool. + Compute and store analytical distances between ions to a set of triangles. - :ref:`NXapm_paraprobe_config_distancer`: - Configuration of paraprobe-distancer - Compute analytical distances between ions to a set of triangles. - - :ref:`NXapm_paraprobe_results_distancer`: - Results of paraprobe-distancer - Store analytical distances between ions to a set of triangles. - - - :ref:`NXapm_paraprobe_config_tessellator`: - Configuration of paraprobe-tessellator - Compute Voronoi cells for if desired all ions in a dataset. - - :ref:`NXapm_paraprobe_results_tessellator`: - Results of paraprobe-tessellator - Store volume of all Voronoi cells about each ion in the dataset. + :ref:`NXapm_paraprobe_tessellator_config`, :ref:`NXapm_paraprobe_tessellator_results`: + Configuration and results respectively of the of paraprobe-tessellator tool. + Compute and store Voronoi cells and properties of these for all ions in a dataset. +The definitions of the following tools remain to become refactored like those for the above-mentioned tools: :ref:`NXapm_paraprobe_config_nanochem`: Configuration of paraprobe-nanochem @@ -277,7 +263,6 @@ The definitions of the following tools remain to become refactored like those fo store all extracted triangulated surface meshes of found microstructural features, store composition profiles and corresponding geometric primitives (ROIs). - :ref:`NXapm_paraprobe_config_intersector`: Configuration of paraprobe-intersector Assess intersections and proximity of 3D triangulated surface meshes in From 13efc84188b6d17e845c9778c207688a6b37b9b5 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Sun, 28 Jan 2024 19:57:42 +0100 Subject: [PATCH 0537/1012] Refactored appdefs for paraprobe-spatstat, specified symbol to use for NXcoordinate_system_set and NXuser --- .../NXapm_paraprobe_config_distancer.nxdl.xml | 257 ------- .../NXapm_paraprobe_config_spatstat.nxdl.xml | 374 ---------- .../NXapm_paraprobe_config_surfacer.nxdl.xml | 289 -------- ...Xapm_paraprobe_config_tessellator.nxdl.xml | 253 ------- ...NXapm_paraprobe_distancer_results.nxdl.xml | 4 +- .../NXapm_paraprobe_ranger_results.nxdl.xml | 4 +- ...NXapm_paraprobe_results_distancer.nxdl.xml | 388 ---------- .../NXapm_paraprobe_results_spatstat.nxdl.xml | 364 ---------- .../NXapm_paraprobe_results_surfacer.nxdl.xml | 503 ------------- ...apm_paraprobe_results_tessellator.nxdl.xml | 677 ----------------- .../NXapm_paraprobe_selector_results.nxdl.xml | 4 +- .../NXapm_paraprobe_surfacer_results.nxdl.xml | 4 +- ...Xapm_paraprobe_tessellator_config.nxdl.xml | 1 - ...apm_paraprobe_tessellator_results.nxdl.xml | 4 +- ...Xapm_paraprobe_transcoder_results.nxdl.xml | 4 +- .../NXapm_paraprobe_config_spatstat.yaml | 662 ----------------- .../NXapm_paraprobe_distancer_results.yaml | 4 +- .../nyaml/NXapm_paraprobe_ranger_results.yaml | 4 +- .../NXapm_paraprobe_results_spatstat.yaml | 687 ------------------ .../NXapm_paraprobe_selector_results.yaml | 4 +- .../NXapm_paraprobe_spatstat_config.yaml | 254 +++++++ .../NXapm_paraprobe_spatstat_results.yaml | 105 +++ .../NXapm_paraprobe_surfacer_results.yaml | 4 +- .../NXapm_paraprobe_tessellator_config.yaml | 1 - .../NXapm_paraprobe_tessellator_results.yaml | 4 +- .../NXapm_paraprobe_transcoder_results.yaml | 4 +- 26 files changed, 383 insertions(+), 4480 deletions(-) delete mode 100644 contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_results_spatstat.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml diff --git a/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml deleted file mode 100644 index 1d7b252085..0000000000 --- a/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml +++ /dev/null @@ -1,257 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Configuration/settings of a paraprobe-distancer software tool run. - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - How many individual analyses should the tool execute. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Compute for all filtered points, e.g. ions of the point set - the shortest Euclidean distance to the closest triangle of the - set of triangles. The triangles can formed a closed surface mesh. - Distances are not simple distances based on normal projections but - giving an exact solution. - - - - - Paraprobe-distancer enables the computation of the Euclidean shortest - distance for each member of a set of points against a set of triangles. - In contrast to comparable methods used in atom probe the here computed - distance is not simply the projected distance to one of the triangles - but the more costly but robust computation of the distance between - a point and a triangle. - - The triangles can represent for instance the facets of a triangulated - surface mesh of a model for the edge of the dataset. Such a model can - be computed with paraprobe-surfacer. Alternatively, the triangles can - be those from the set of all facets for a set of convex hulls, alpha-shapes, - or alpha wrappings about three-dimensional objects like precipitates - (computed with e.g. paraprobe-nanochem). - - Currently, the tool does not check if the respectively specified - triangle sets are consistent, what their topology is, or whether or - not they are consistently oriented. - Each dataset that is referred to in the list_of _dataset_names_vertices - should be an (Nvertices, 3) array of NX_FLOAT. Each dataset referred - to in the list_of_dataset_names_facet_indices should be an - (Nfacets, 3) array of NX_UINT. - Facet indices refer to vertex indices. These need to start at zero - and must not exceed Nvertices - 1, i.e. the identifier_offset is 0 - and vertices are indexed thus implicitly. - Facet normal vectors have to be also an array - of shape (Nfacets, 3) of NX_FLOAT. - - - - How many triangle sets to consider. - - - - - List of triangle sets. This design allows users to combine - multiple triangle sets. - - - - Name of the HDF5 file(s) which contain(s) vertex coordinates - and facet indices to describe the desired set of triangles. - - - - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional - layer of reproducibility. - - - - - - Absolute HDF5 path to the dataset which - specifies the array of vertex positions. - - - - - Absolute HDF5 path to the dataset which - specifies the array of facet indices. - - - - - Absolute HDF5 path to the dataset which - specifies the array of facet normal vectors. - - - - - - - Specifies for which ions/points the tool will compute distances. - The purpose of this setting is to avoid unnecessary computations - when the user requests to only compute distances of ions within a - threshold distance to the triangle soup. - - By default the distances are computed for all ions; however - the setting skin enables to compute distances only for those - ions which are not farther away located to a triangle - than threshold_distance. - - - - - - - - - - Maximum distance for which distances are computed when method is skin. - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml deleted file mode 100644 index d9e2b26f0e..0000000000 --- a/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml +++ /dev/null @@ -1,374 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Maximum number of atoms per molecular ion. Should be 32 for paraprobe. - - - - - Number of different sources iontypes to distinguish. - - - - - Number of different target iontypes to distinguish. - - - - - Configuration of a paraprobe-spatstat tool run in atom probe microscopy. - - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - How many range_with_existent_iontypes processes should - the tool execute as part of the analysis. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The tool enables to inject precomputed distances of each ion to a - representation of the edge of the dataset which can be used to - control and substantially reduce edge effects when computing - spatial statistics. - - - - Name of an HDF5 file which contains ion-to-edge distances. - - - - - Absolute HDF5 path to the dataset with the - ion-to-edge distance values for each ion. - The shape of the distance values has to match the length - of the ion positions array in dataset/dataset_name_reconstruction - and dataset_name_mass_to_charge respectively. - - - - - Threshold to define how large an ion has to lay at least far away - from the edge of the dataset so that the ion can act as a source, - i.e. that an ROI is placed at the location of the ion and its - neighbors are analyzed how they contribute to the computed statistics. - - The ion_to_edge_distances threshold can be combined with a threshold - for the ion_to_feature_distances. - Specifically, if ion_to_feature_distances are loaded an ion only - acts as a source if both threshold criteria are met. - - The threshold is useful to process the dataset such that ROIs do - not protrude out of the dataset as this would add bias. - - - - - - In addition to spatial filtering, and considering how far ions lie - to the edge of the dataset, it is possible to restrict the analyses - to a sub-set of ions within a distance not farther away to a feature than - a threshold value. - - - - Name of an HDF5 file which contains ion-to-feature distances. - - - - - Absolute HDF5 path to the dataset with the - ion-to-feature distance values for each ion. - - - - - Threshold to define how close an ion has to lay to a feature so that - the ion can at all qualify as a source, i.e. that an ROI is placed - at the location of the ion and its neighbors are then analyzed - how they contribute to the computed statistics. - - Recall that the ion_to_feature_distances threshold is combined - with the ion_to_edge_distances threshold. - - - - - - - Specifies if the iontypes are randomized for the point cloud or not. - Internally paraprobe uses a sequentially executed deterministic MT19987 - (MersenneTwister) pseudo-random number generator to shuffle the - iontype labels randomly across the entire set of ions. - - - - - - - - - - How should the iontype be interpreted on the source-side, i.e. - all these ion positions where a regions-of-interest (ROI) around - so-called source ions will be placed. Different options exist - how iontypes are interpreted given an iontype represents - in general a (molecular) ion with different isotopes that have - individually different multiplicity. - - The value resolve_all will set an ion active in the analysis regardless - of which iontype it is. Each active ion is accounted for once. - - The value resolve_unknown will set an ion active when the ion is - of the UNKNOWNTYPE type. Each active ion is accounted for once. - - The value resolve_ion will set an ion active if it is of the specific - iontype, irregardless of its elemental or isotopic details. - Each active ion is counted once. - - The value resolve_element will set an ion active, and most importantly, - account for each as many times as the (molecular) ion contains - atoms of elements in the whitelist ion_query_isotope_vector. - - The value resolve_isotope will set an ion active, and most importantly, - account for each as many times as the (molecular) ion contains - isotopes in the whitelist ion_query_isotope_vector. - - In effect, ion_query_isotope_vector acts as a whitelist to filter - which ions are considered as source ions of the correlation statistics - and how the multiplicity of each ion will be factorized, i.e. how - often it is accounted for. - - - - - - - - - - - - Matrix of isotope vectors, as many as rows as different candidates - for iontypes should be distinguished as possible source iontypes. - In the simplest case, the matrix contains only the proton number - of the element in the row, all other values set to zero. - Combined with ion_query_type_source set to resolve_element this will - recover usual spatial correlation statistics like the 1NN C-C - spatial statistics. - - - - - - - - - Similarly as ion_query_type_source how should iontypes be interpreted - on the target-side, i.e. how many counts will be bookkept for ions - which are neighbors of source ions within or on the surface of each - inspection/ROI about each source ion. - Source ion in the center of the ROI are not accounted for during - counting the summary statistics. - For details about the resolve values consider the explanations in - ion_query_type_source. These account for ion_query_type_target as well. - - - - - - - - - - - - - Matrix of isotope vectors, as many as rows as different candidates for - iontypes to distinguish as possible targets. See additional comments - under ion_query_isotope_vector_source. - - - - - - - - - Specifies which spatial statistics to compute. - - - - Compute k-th nearest neighbour statistics. - - - - Order k. - - - - - Minimum value, increment, and maximum value of the histogram binning. - - - - - - - - - - Compute radial distribution function. - - - - Minimum value, increment, and maximum value of the histogram binning. - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml deleted file mode 100644 index e421eaaaa0..0000000000 --- a/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml +++ /dev/null @@ -1,289 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of alpha values (and offset values) to probe. - - - - - How many different match values does the filter specify. - - - - - Configuration of a paraprobe-surfacer tool run in atom probe microscopy. - - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - For now a support field for the tool to identify how many individual - analyses the tool should executed as part of the analysis. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specifies the method that is used to preprocess the point cloud. - The main purpose of this setting is to specify whether the point - cloud should be segmented or not during the preprocessing - to identify which points are more likely lying close to the edge - of the point cloud. These points could be more relevant than the - interior points for certain alpha-shape constructions. - - By default no such filtering is used during pre-processing. - By contrast, the option kuehbach activates a preprocessing - during which a Hoshen-Kopelman percolation analysis is used - to identify which points are closer to the edge of the dataset. - This can reduce the number of points in the alpha-shape - computation and thus improve performance substantially. - Details about the methods are reported in - `M. Kühbach et al. <https://doi.org/10.1038/s41524-020-00486-1>`_. - - - - - - - - - - When using the kuehbach preprocessing, this is the width of the - kernel for identifying which ions are in voxels close to the - edge of the point cloud. - - - - - Specifies which method to use to define the alpha value. - The value convex_hull_naive is the default. This instructs the tool - to use a fast specialized algorithm for computing only the convex - hull. The resulting triangles can be skinny. - - The value convex_hull_refine computes first also a convex_hull_naive - but refines the mesh by triangle flipping and splitting to improve - the quality of the mesh. - - The value smallest_solid instructs the CGAL library to choose a - value which realizes an alpha-shape that is the smallest solid. - - The value cgal_optimal instructs the library to choose a value - which the library considers as an optimal value. Details are - define in the respective section of the CGAL library on 3D alpha - shapes. - - The value set_of_values instructs to compute a list of - alpha-shapes for the specified alpha-values. - - The value set_of_alpha_wrappings instructs the library to generate - a set of so-called alpha wrappings. These are a method - which is similar to alpha shapes but provide additional guarantees - though such as watertightness and proximity constraints on the - resulting wrapping. - - - - - - - - - - - - - - Array of alpha values to use when alpha_value_choice is set_of_values - or when alpha_value_choice is set_of_alpha_wrappings. - - - - - - - - - Array of offset values to use when alpha_value_choice is - set_of_alpha_wrappings. The array of alpha_values and offset_values - define a sequence of (alpha and offset value). - - - - - - - - - Specifies if the tool should compute the set of exterior triangle - facets for each alpha complex (for convex hull, alpha shapes, and wrappings) - - - - - Specifies if the tool should check if the alpha complex of exterior - triangular facets is a closed polyhedron. - - - - - Specifies if the tool should compute all interior tetrahedra - of the alpha complex (currently only for alpha shapes). - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml deleted file mode 100644 index 24f2202166..0000000000 --- a/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml +++ /dev/null @@ -1,253 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Configuration of a paraprobe-tessellator tool run in atom probe microscopy. - - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - How many individual analyses should the tool execute. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The tool enables to inject precomputed distance information for - each point which can be used for further post-processing and analysis. - - - - Name of an HDF5 file which contains the ion distances. - Users are responsible this file and referred to dataset under - dataset_name have an ion_distance value for each ion. - - - - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional layer of - reproducibility. - - - - - - Absolute HDF5 path to the dataset with distance values for each ion. - - - - - - - Specifies for which points the tool will compute the tessellation. - By default, a Voronoi tessellation is computed for all ions in the - filtered point cloud. - - - - - - - - - - Specifies if the tool should report the volume of each cell. - - - - - Specifies if the tool should report the first-order neighbors of each cell. - - - - - Specifies if the tool should report the facets and vertices of each cell. - - - - - Specifies if the tool should report if the cell makes contact with - the tight axis-aligned bounding box about the point cloud. - This can be used to identify if the shape of the cell is affected - by the edge of the dataset or if cells are deeply enough embedded - into the point cloud so that the shape of their cells are not affected - by the presence of the boundary. - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml index ea20ffcc27..7e1179c231 100644 --- a/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml @@ -155,10 +155,10 @@ triangles in this case--> - + - + diff --git a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml index 4858a871e4..e72b9bf9f7 100644 --- a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml @@ -108,10 +108,10 @@ config--> - + - + diff --git a/contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml deleted file mode 100644 index 5edb36e604..0000000000 --- a/contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml +++ /dev/null @@ -1,388 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of ions in the reconstruction. - - - - - The total number of triangles in the set. - - - - - Results of a paraprobe-distancer tool run. - - - - - - Version specifier of this application definition. - - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - - - - - The absolute path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - - - - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - - The tool can be used to compute the analytical distance of each ion - to a set of triangles. - - - - A bitmask which identifies which of the ions in the dataset were - analyzed. - - - - Number of ions covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - A bitmask which identifies which of the triangles in the set - were considered. Usually these are all but sometimes users may - wish to filter certain portions of the triangles out. - If window_triangles is not provided it means that - all triangles were taken. - - - - Number of triangles covered by the mask. - The mask value for most may be 0. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - The closest analytical distance of the ions to their respectively - closest triangle from the triangle set. - - - - - - - - A bitmask which identifies which of the distance values - can be assumed to have a consistent sign because the closest - triangle had a consistent outer unit normal defined. - For points whose bit is set 0 the distance is correct but the - sign is not reliable. - - - - Number of triangles covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. - - - - - - - - - The identifier of the triangle that is closest for each ion. - - - - - - - - A support field to visualize each ion and with this the distance - informations using XDMF and e.g. Paraview. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_results_spatstat.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_spatstat.nxdl.xml deleted file mode 100644 index 674afbe853..0000000000 --- a/contributed_definitions/NXapm_paraprobe_results_spatstat.nxdl.xml +++ /dev/null @@ -1,364 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of ions in the reconstruction. - - - - - Results of a paraprobe-spatstat tool run. - - - - - - Version specifier of this application definition. - - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - - - - - The absolute path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - - - - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - - A bitmask which identifies which of the ions in the dataset were - analyzed. - - - - Number of ions covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - The iontype ID for each ion that was assigned to each ion during - the randomization of the ionlabels. Iontype labels are just permuted - but the total number of values for each iontype stay the same. - - The order matches the iontypes array from a given ranging results - as is specified in the configuration settings inside the specific - config_filename that was used for this spatstat analysis. - - - - - - - - K-nearest neighbor statistics. - - - - Right boundary of the binning. - - - - - - - - - - - - - Cumulated - - - - - - - - Cumulated and normalized by total counts - - - - - - - - - Radial distribution statistics. - - - - Right boundary of the binning. - - - - - - - - - - - - - Cumulated - - - - - - - - Cumulated and normalized by total counts - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml deleted file mode 100644 index 0e24bccc8b..0000000000 --- a/contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml +++ /dev/null @@ -1,503 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of ions in the reconstruction. - - - - - The number of vertices of the alpha complex. - - - - - The number of faces of the alpha complex. - - - - - The total number of XDMF values to represent all faces of triangles via XDMF. - - - - - The total number of XDMF values to represent all faces of tetrahedra via XDMF. - - - - - Results of a paraprobe-surfacer tool run. - - - - - - Version specifier of this application definition. - - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - - - - - The absolute path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - - - - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - - A bitmask which identifies which of the ions in the dataset were - analyzed. Computations of alpha complexes may have filtered this - ion set further but this process is deterministic. - - - - Number of ions covered by the mask. The mask may be 0 for most. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - Paraprobe-surfacer can be used to load a ROI that is the entire or a - sub-set of the ion point cloud. In the point_cloud_wrapping process - the tool computes a triangulated surface mesh which encloses the - ROI/point cloud. This mesh can be seen as a model for the edge of - the dataset. - Different algorithms can be used with paraprobe-surfacer to create - this mesh such as convex hulls, alpha-shapes as their generalization, - or alpha wrappings. - Ideally, the resulting mesh should be a watertight polyhedron. - This polyhedron is not necessarily convex. For some algorithms there - is no guarantee that the resulting mesh yields a watertight mesh. - - - - - - A bitmask which identifies exactly all those ions whose positions - were considered when defining the filtered point set from which - the alpha complex was then in fact computed. This window - can be different to the entire window as irrelevant ions might - have been filtered out to reduce the computational costs of the - alpha complex analysis. - - - - - Number of ions covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The set of triangles in the coordinate system paraprobe - which discretizes the exterior surface of the alpha complex. - - - - Integer which specifies the first index to be used for distinguishing - triangles. Identifiers are defined either implicitly or explicitly. - For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - - - - - - - Number of vertices. - - - - - Number of faces. - - - - - - - - - - - - - - - - - - - A list of as many tuples of XDMF topology key, XDMF number - of vertices and a triple of vertex indices specifying each - triangle. The total number of entries is n_f_tri * (1+1+3). - - - - - - - - - Do the triangles define a triangulated surface mesh which - is watertight? - - - - - The volume which the triangulated surface mesh encloses - provided that the mesh is watertight. - - - - - - The set of tetrahedra which represent the interior volume of the - complex if that is a closed 2-manifold. - - - - Integer which specifies the first index to be used for distin- - guishing tetrahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined - on the interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - - - - The accumulated volume of all interior tetrahedra. - - - - - - Number of vertices. - - - - - Number of faces. - - - - - - - - - - - - - A list of as many tuples of XDMF topology key, XDMF number - of vertices and a triple of vertex indices specifying each - triangle. The total number of entries is n_f_tet * (1+1+4). - - - - - - - - - - - - In the future we may want to wrap other primitives - like triangles or polylines. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml deleted file mode 100644 index dc2bf91198..0000000000 --- a/contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml +++ /dev/null @@ -1,677 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of ions in the reconstruction. - - - - - The total number of facets/polygons defining the tessellation. - - - - - Results of a paraprobe-tessellator tool run. - - - - - - Version specifier of this application definition. - - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - - - - - The absolute path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - - - - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - - The tool can be used to compute a Voronoi tessellation the entire - or a sub-set of the reconstruction. The point cloud in the ROI is - wrapped into a tight axis-aligned bounding box. The tool detects if - Voronoi cells make contact with the walls of this bounding box. - The tessellation is computed without periodic boundary conditions. - - - - A bitmask which identifies which of the ions in the dataset were - analyzed. - - - - Number of ions covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - A bitmask which identifies which of points have Voronoi cells that - are truncated by the global axis-aligned bounding box, i.e. boundaries - of the threads are ignored. - - - - Number of points covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - - A bitmask which identifies which of points have Voronoi cells that - are truncated by a specific wall of the axis-aligned bounding box. - The left wall has the negative x axis of the paraprobe coordinate - system as the outer unit normal. - - - - Number of points covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - A bitmask which identifies which of points have Voronoi cells that - are truncated by a specific wall of the axis-aligned bounding box. - The right wall has the positive x axis of the paraprobe coordinate - system as the outer unit normal. - - - - Number of points covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - A bitmask which identifies which of points have Voronoi cells that - are truncated by a specific wall of the axis-aligned bounding box. - The front wall has the negative y axis of the paraprobe coordinate - system as the outer unit normal. - - - - Number of points covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - A bitmask which identifies which of points have Voronoi cells that - are truncated by a specific wall of the axis-aligned bounding box. - The rear wall has the positive y axis of the paraprobe coordinate - system as the outer unit normal. - - - - Number of points covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - A bitmask which identifies which of points have Voronoi cells that - are truncated by a specific wall of the axis-aligned bounding box. - The left wall has the negative z axis of the paraprobe coordinate - system as the outer unit normal. - - - - Number of points covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - A bitmask which identifies which of points have Voronoi cells that - are truncated by a specific wall of the axis-aligned bounding box. - The left wall has the positive z axis of the paraprobe coordinate - system as the outer unit normal. - - - - Number of points covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - - - - - - - - Interior volume - - - - - - - - By which MPI process was the Voronoi cell computed. - - - - - - - - By which OpenMP thread was the Voronoi cell computed. - - - - - - - - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. This field can be used to interpret - the array/field with the individual area values for each face. - - - - - - - - - Integer which specifies the first index to be used for distinguishing - polyhedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - - - - Integer used to distinguish polyhedra for explicit indexing. - - - - - - - - A simple approach to describe the entire set of polyhedra when - the main intention is to store the shape of the polyhedra for - visualization. - - - - - Number of vertices. - - - - - Number of faces. - - - - - - - - - - - - - A sequence of always first an XDMF topology type key, followed - by the XDMF number of vertices of the polygon, followed by - the vertex identifier which define the facet polygon. First - we store the polygon of the first facet of the first cell, then - the second facet of the first cell, until the last facet of the - first cell, followed by the first facet of the second cell, - and so on and so forth. - - - - - - - - A sequence of cell identifier so that each facet is associated - with its cell because of which it is then possible to segment - out cells three-dimensionally based on cell i.e. evaporation_id. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml index 058e1a287f..214414f832 100644 --- a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml @@ -80,10 +80,10 @@ - + - + diff --git a/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml index 499628aa32..260eb720a7 100644 --- a/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml @@ -242,10 +242,10 @@ for eventually performed preprocessing--> - + - + diff --git a/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml index f9ed857db4..56b74a8d94 100644 --- a/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml @@ -65,7 +65,6 @@ if windowing_method is bitmasked_points: sum cardinality of NXcg := 0 and cardin - diff --git a/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml index e7bbd0d7c9..21263ce12f 100644 --- a/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml @@ -290,10 +290,10 @@ dim: (i,) # one would not need to constrain this but doing so communicates that - + - + diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml index 3f5a42ece0..dab98c9a52 100644 --- a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml @@ -176,13 +176,13 @@ profiling--> - + If used, metadata of at least the person who performed this analysis. - + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml deleted file mode 100644 index 9bcba92551..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_spatstat.yaml +++ /dev/null @@ -1,662 +0,0 @@ -category: application -doc: | - Configuration of a paraprobe-spatstat tool run in atom probe microscopy. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_ivecmax: | - Maximum number of atoms per molecular ion. Should be 32 for paraprobe. - n_ion_source: | - Number of different sources iontypes to distinguish. - n_ion_target: | - Number of different target iontypes to distinguish. -type: group -NXapm_paraprobe_config_spatstat(NXobject): - (NXentry): - - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently - \@version: - doc: | - Version specifier of this application definition. - definition: - doc: | - Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_config_spatstat] - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: | - Possibility for leaving a free-text description about this analysis. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - time_stamp(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - number_of_processes(NX_UINT): - unit: NX_UNITLESS - doc: | - How many range_with_existent_iontypes processes should - the tool execute as part of the analysis. - (NXprocess): - exists: ['min', '1', 'max', '1'] - spatial_statistics(NXprocess): - exists: ['min', '0', 'max', '1'] - dataset(NXapm_input_reconstruction): - filename: - \@version: - dataset_name_reconstruction: - dataset_name_mass_to_charge: - iontypes(NXapm_input_ranging): - filename: - \@version: - group_name_iontypes: - spatial_filter(NXspatial_filter): - exists: optional - windowing_method: - (NXcg_ellipsoid_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - half_axes_radii(NX_NUMBER): - orientation(NX_NUMBER): - (NXcg_cylinder_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - height(NX_NUMBER): - radii(NX_NUMBER): - (NXcg_hexahedron_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - hexahedra(NXcg_face_list_data_structure): - (NXcs_filter_boolean_mask): - exists: optional - number_of_objects(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - identifier(NX_UINT): - evaporation_id_filter(NXsubsampling_filter): - exists: optional - iontype_filter(NXmatch_filter): - exists: optional - hit_multiplicity_filter(NXmatch_filter): - exists: optional - ion_to_edge_distances(NXprocess): - exists: optional - doc: | - The tool enables to inject precomputed distances of each ion to a - representation of the edge of the dataset which can be used to - control and substantially reduce edge effects when computing - spatial statistics. - filename: - doc: | - Name of an HDF5 file which contains ion-to-edge distances. - dataset_name_distances: - doc: | - Absolute HDF5 path to the dataset with the - ion-to-edge distance values for each ion. - The shape of the distance values has to match the length - of the ion positions array in dataset/dataset_name_reconstruction - and dataset_name_mass_to_charge respectively. - edge_distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Threshold to define how large an ion has to lay at least far away - from the edge of the dataset so that the ion can act as a source, - i.e. that an ROI is placed at the location of the ion and its - neighbors are analyzed how they contribute to the computed statistics. - - The ion_to_edge_distances threshold can be combined with a threshold - for the ion_to_feature_distances. - Specifically, if ion_to_feature_distances are loaded an ion only - acts as a source if both threshold criteria are met. - - The threshold is useful to process the dataset such that ROIs do - not protrude out of the dataset as this would add bias. - ion_to_feature_distances(NXprocess): - exists: optional - doc: | - In addition to spatial filtering, and considering how far ions lie - to the edge of the dataset, it is possible to restrict the analyses - to a sub-set of ions within a distance not farther away to a feature than - a threshold value. - filename: - doc: | - Name of an HDF5 file which contains ion-to-feature distances. - dataset_name_distances: - doc: | - Absolute HDF5 path to the dataset with the - ion-to-feature distance values for each ion. - threshold(NX_FLOAT): - unit: NX_LENGTH - doc: | - Threshold to define how close an ion has to lay to a feature so that - the ion can at all qualify as a source, i.e. that an ROI is placed - at the location of the ion and its neighbors are then analyzed - how they contribute to the computed statistics. - - Recall that the ion_to_feature_distances threshold is combined - with the ion_to_edge_distances threshold. - - ##MK::think about an inversion ruleset for the filter, i.e. - # like discussed in Haley/Stephenson's paper where ions only far enough - # from a feature AND deeply embedded enough in the dataset are chosen. - randomize_ion_types(NX_BOOLEAN): - doc: | - Specifies if the iontypes are randomized for the point cloud or not. - Internally paraprobe uses a sequentially executed deterministic MT19987 - (MersenneTwister) pseudo-random number generator to shuffle the - iontype labels randomly across the entire set of ions. - random_number_generator(NXcs_prng): - exists: recommended - type: - seed(NX_NUMBER): - warmup(NX_NUMBER): - ion_query_type_source: - doc: | - How should the iontype be interpreted on the source-side, i.e. - all these ion positions where a regions-of-interest (ROI) around - so-called source ions will be placed. Different options exist - how iontypes are interpreted given an iontype represents - in general a (molecular) ion with different isotopes that have - individually different multiplicity. - - The value resolve_all will set an ion active in the analysis regardless - of which iontype it is. Each active ion is accounted for once. - - The value resolve_unknown will set an ion active when the ion is - of the UNKNOWNTYPE type. Each active ion is accounted for once. - - The value resolve_ion will set an ion active if it is of the specific - iontype, irregardless of its elemental or isotopic details. - Each active ion is counted once. - - The value resolve_element will set an ion active, and most importantly, - account for each as many times as the (molecular) ion contains - atoms of elements in the whitelist ion_query_isotope_vector. - - The value resolve_isotope will set an ion active, and most importantly, - account for each as many times as the (molecular) ion contains - isotopes in the whitelist ion_query_isotope_vector. - - In effect, ion_query_isotope_vector acts as a whitelist to filter - which ions are considered as source ions of the correlation statistics - and how the multiplicity of each ion will be factorized, i.e. how - often it is accounted for. - enumeration: [resolve_all, resolve_unknown, resolve_ion, resolve_element, resolve_isotope] - ion_query_isotope_vector_source(NX_UINT): - unit: NX_UNITLESS - doc: | - Matrix of isotope vectors, as many as rows as different candidates - for iontypes should be distinguished as possible source iontypes. - In the simplest case, the matrix contains only the proton number - of the element in the row, all other values set to zero. - Combined with ion_query_type_source set to resolve_element this will - recover usual spatial correlation statistics like the 1NN C-C - spatial statistics. - dimensions: - rank: 2 - dim: [[1, n_ion_source], [2, n_ivecmax]] - ion_query_type_target: - doc: | - Similarly as ion_query_type_source how should iontypes be interpreted - on the target-side, i.e. how many counts will be bookkept for ions - which are neighbors of source ions within or on the surface of each - inspection/ROI about each source ion. - Source ion in the center of the ROI are not accounted for during - counting the summary statistics. - For details about the resolve values consider the explanations in - ion_query_type_source. These account for ion_query_type_target as well. - enumeration: [resolve_all, resolve_unknown, resolve_ion, resolve_element, resolve_isotope] - - # NEW ISSUE: conditionally required only when resolve_isotope - ion_query_isotope_vector_target(NX_UINT): - unit: NX_UNITLESS - doc: | - Matrix of isotope vectors, as many as rows as different candidates for - iontypes to distinguish as possible targets. See additional comments - under ion_query_isotope_vector_source. - dimensions: - rank: 2 - dim: [[1, n_ion_target], [2, n_ivecmax]] - statistics(NXprocess): - doc: | - Specifies which spatial statistics to compute. - knn(NXprocess): - exists: optional - doc: | - Compute k-th nearest neighbour statistics. - nth(NX_UINT): - unit: NX_UNITLESS - doc: | - Order k. - histogram_min_incr_max(NX_FLOAT): - unit: NX_LENGTH - doc: | - Minimum value, increment, and maximum value of the histogram binning. - - # \@units: nm - dimensions: - rank: 1 - dim: [[1, 3]] - rdf(NXprocess): - exists: optional - doc: | - Compute radial distribution function. - histogram_min_incr_max(NX_FLOAT): - unit: NX_LENGTH - doc: | - Minimum value, increment, and maximum value of the histogram binning. - - # \@units: nm - dimensions: - rank: 1 - dim: [[1, 3]] - - # NEW ISSUE: ripleyk(NXcollection): - # NEW ISSUE: two_point(NXcollection): - performance(NXcs_profiling): - current_working_directory: - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 58f42334f6d43a13494f1bd0adfd0cac7d533a84f47f47fdd0ba75026a098e1b -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Maximum number of atoms per molecular ion. Should be 32 for paraprobe. -# -# -# -# -# Number of different sources iontypes to distinguish. -# -# -# -# -# Number of different target iontypes to distinguish. -# -# -# -# -# Configuration of a paraprobe-spatstat tool run in atom probe microscopy. -# -# -# -# -# -# Version specifier of this application definition. -# -# -# -# -# Official NeXus NXDL schema with which this file was written. -# -# -# -# -# -# -# -# Given name of the program/software/tool with which this NeXus -# (configuration) file was generated. -# -# -# -# Ideally program version plus build number, or commit hash or description -# of ever persistent resources where the source code of the program and -# build instructions can be found so that the program can be configured -# ideally in such a manner that the result of this computational process -# is recreatable in the same deterministic manner. -# -# -# -# -# -# Ideally, a (globally persistent) unique identifier for referring -# to this analysis. -# -# -# -# -# Possibility for leaving a free-text description about this analysis. -# -# -# -# -# Path to the directory where the tool should store NeXus/HDF5 results -# of this analysis. If not specified results will be stored in the -# current working directory. -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when this configuration file was created. -# -# -# -# -# How many range_with_existent_iontypes processes should -# the tool execute as part of the analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The tool enables to inject precomputed distances of each ion to a -# representation of the edge of the dataset which can be used to -# control and substantially reduce edge effects when computing -# spatial statistics. -# -# -# -# Name of an HDF5 file which contains ion-to-edge distances. -# -# -# -# -# Absolute HDF5 path to the dataset with the -# ion-to-edge distance values for each ion. -# The shape of the distance values has to match the length -# of the ion positions array in dataset/dataset_name_reconstruction -# and dataset_name_mass_to_charge respectively. -# -# -# -# -# Threshold to define how large an ion has to lay at least far away -# from the edge of the dataset so that the ion can act as a source, -# i.e. that an ROI is placed at the location of the ion and its -# neighbors are analyzed how they contribute to the computed statistics. -# -# The ion_to_edge_distances threshold can be combined with a threshold -# for the ion_to_feature_distances. -# Specifically, if ion_to_feature_distances are loaded an ion only -# acts as a source if both threshold criteria are met. -# -# The threshold is useful to process the dataset such that ROIs do -# not protrude out of the dataset as this would add bias. -# -# -# -# -# -# In addition to spatial filtering, and considering how far ions lie -# to the edge of the dataset, it is possible to restrict the analyses -# to a sub-set of ions within a distance not farther away to a feature than -# a threshold value. -# -# -# -# Name of an HDF5 file which contains ion-to-feature distances. -# -# -# -# -# Absolute HDF5 path to the dataset with the -# ion-to-feature distance values for each ion. -# -# -# -# -# Threshold to define how close an ion has to lay to a feature so that -# the ion can at all qualify as a source, i.e. that an ROI is placed -# at the location of the ion and its neighbors are then analyzed -# how they contribute to the computed statistics. -# -# Recall that the ion_to_feature_distances threshold is combined -# with the ion_to_edge_distances threshold. -# -# -# -# -# -# -# Specifies if the iontypes are randomized for the point cloud or not. -# Internally paraprobe uses a sequentially executed deterministic MT19987 -# (MersenneTwister) pseudo-random number generator to shuffle the -# iontype labels randomly across the entire set of ions. -# -# -# -# -# -# -# -# -# -# How should the iontype be interpreted on the source-side, i.e. -# all these ion positions where a regions-of-interest (ROI) around -# so-called source ions will be placed. Different options exist -# how iontypes are interpreted given an iontype represents -# in general a (molecular) ion with different isotopes that have -# individually different multiplicity. -# -# The value resolve_all will set an ion active in the analysis regardless -# of which iontype it is. Each active ion is accounted for once. -# -# The value resolve_unknown will set an ion active when the ion is -# of the UNKNOWNTYPE type. Each active ion is accounted for once. -# -# The value resolve_ion will set an ion active if it is of the specific -# iontype, irregardless of its elemental or isotopic details. -# Each active ion is counted once. -# -# The value resolve_element will set an ion active, and most importantly, -# account for each as many times as the (molecular) ion contains -# atoms of elements in the whitelist ion_query_isotope_vector. -# -# The value resolve_isotope will set an ion active, and most importantly, -# account for each as many times as the (molecular) ion contains -# isotopes in the whitelist ion_query_isotope_vector. -# -# In effect, ion_query_isotope_vector acts as a whitelist to filter -# which ions are considered as source ions of the correlation statistics -# and how the multiplicity of each ion will be factorized, i.e. how -# often it is accounted for. -# -# -# -# -# -# -# -# -# -# -# -# Matrix of isotope vectors, as many as rows as different candidates -# for iontypes should be distinguished as possible source iontypes. -# In the simplest case, the matrix contains only the proton number -# of the element in the row, all other values set to zero. -# Combined with ion_query_type_source set to resolve_element this will -# recover usual spatial correlation statistics like the 1NN C-C -# spatial statistics. -# -# -# -# -# -# -# -# -# Similarly as ion_query_type_source how should iontypes be interpreted -# on the target-side, i.e. how many counts will be bookkept for ions -# which are neighbors of source ions within or on the surface of each -# inspection/ROI about each source ion. -# Source ion in the center of the ROI are not accounted for during -# counting the summary statistics. -# For details about the resolve values consider the explanations in -# ion_query_type_source. These account for ion_query_type_target as well. -# -# -# -# -# -# -# -# -# -# -# -# -# Matrix of isotope vectors, as many as rows as different candidates for -# iontypes to distinguish as possible targets. See additional comments -# under ion_query_isotope_vector_source. -# -# -# -# -# -# -# -# -# Specifies which spatial statistics to compute. -# -# -# -# Compute k-th nearest neighbour statistics. -# -# -# -# Order k. -# -# -# -# -# Minimum value, increment, and maximum value of the histogram binning. -# -# -# -# -# -# -# -# -# -# Compute radial distribution function. -# -# -# -# Minimum value, increment, and maximum value of the histogram binning. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml index 5a294aeabd..522a3872eb 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml @@ -105,10 +105,10 @@ NXapm_paraprobe_distancer_results(NXobject): mask(NX_UINT): dim: (n_tri,) # global - (NXuser): + userID(NXuser): exists: [min, 0, max, infty] name(NX_CHAR): - (NXcoordinate_system_set): + coordinate_system_set(NXcoordinate_system_set): paraprobe(NXcoordinate_system): type(NX_CHAR): handedness(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml index c175b67b0d..ad76e718a2 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml @@ -73,10 +73,10 @@ NXapm_paraprobe_ranger_results(NXobject): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): # global - (NXuser): + userID(NXuser): exists: [min, 0, max, infty] name(NX_CHAR): - (NXcoordinate_system_set): + coordinate_system_set(NXcoordinate_system_set): paraprobe(NXcoordinate_system): type(NX_CHAR): handedness(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.yaml deleted file mode 100644 index 5a8d6e697b..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_spatstat.yaml +++ /dev/null @@ -1,687 +0,0 @@ -category: application -doc: | - Results of a paraprobe-spatstat tool run. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_ions: | - The total number of ions in the reconstruction. -type: group -NXapm_paraprobe_results_spatstat(NXobject): - - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently - (NXentry): - exists: ['min', '1', 'max', '1'] - \@version: - doc: | - Version specifier of this application definition. - - ##MK::begin of the tool-specific section - definition: - doc: | - Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_results_spatstat] - - ##MK::end of the tool-specific section - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: | - Possibility for leaving a free-text description about this analysis. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - config_filename: - doc: | - The absolute path and name of the config file for this analysis. - \@version: - doc: | - At least SHA256 strong hash of the specific config_file for - tracking provenance. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - status: - doc: | - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - enumeration: [success, failure] - (NXuser): - exists: recommended - doc: | - If used, contact information and eventually details - of at least the person who performed this analysis. - name: - affiliation: - exists: recommended - address: - exists: optional - email: - exists: recommended - orcid: - exists: recommended - orcid_platform: - exists: recommended - telephone_number: - exists: optional - role: - exists: recommended - social_media_name: - exists: optional - social_media_platform: - exists: optional - (NXcoordinate_system_set): - exists: optional - doc: | - Details about the coordinate system conventions used. - (NXtransformations): - exists: ['min', '1', 'max', 'unbounded'] - doc: | - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - ##MK::begin of the tool-specific section - (NXprocess): - exists: ['min', '0', 'max', '1'] - window(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies which of the ions in the dataset were - analyzed. - number_of_ions(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of ions covered by the mask. - The mask value for most may be 0. - - # which does paraprobe use - bitdepth(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - mask(NX_UINT): - unit: NX_UNITLESS - doc: | - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - dimensions: - rank: 1 - dim: [[1, n_ions]] - iontypes_randomized(NX_UINT): - unit: NX_UNITLESS - doc: | - The iontype ID for each ion that was assigned to each ion during - the randomization of the ionlabels. Iontype labels are just permuted - but the total number of values for each iontype stay the same. - - The order matches the iontypes array from a given ranging results - as is specified in the configuration settings inside the specific - config_filename that was used for this spatstat analysis. - dimensions: - rank: 1 - dim: [[1, n_ions]] - knn(NXprocess): - exists: optional - doc: | - K-nearest neighbor statistics. - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Right boundary of the binning. - dimensions: - rank: 1 - dim: [[1, i]] - probability_mass(NX_FLOAT): - unit: NX_DIMENSIONLESS - dimensions: - rank: 1 - dim: [[1, i]] - cumulated(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Cumulated - dimensions: - rank: 1 - dim: [[1, i]] - cumulated_normalized(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Cumulated and normalized by total counts - dimensions: - rank: 1 - dim: [[1, i]] - rdf(NXprocess): - exists: optional - doc: | - Radial distribution statistics. - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Right boundary of the binning. - dimensions: - rank: 1 - dim: [[1, i]] - probability_mass(NX_FLOAT): - unit: NX_DIMENSIONLESS - dimensions: - rank: 1 - dim: [[1, i]] - cumulated(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Cumulated - dimensions: - rank: 1 - dim: [[1, i]] - cumulated_normalized(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Cumulated and normalized by total counts - dimensions: - rank: 1 - dim: [[1, i]] - - ##MK::end of the tool-specific section - performance(NXcs_profiling): - exists: recommended - current_working_directory: - command_line_call: - exists: optional - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - total_elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - (NXcs_computer): - exists: recommended - name: - exists: recommended - operating_system: - \@version: - uuid: - exists: optional - (NXcs_cpu): - exists: ['min', '0', 'max', 'unbounded'] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_gpu): - exists: ['min', '0', 'max', 'unbounded'] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_mm_sys): - exists: ['min', '0', 'max', '1'] - total_physical_memory(NX_NUMBER): - (NXcs_io_sys): - exists: ['min', '0', 'max', '1'] - (NXcs_io_obj): - exists: ['min', '1', 'max', 'unbounded'] - technology: - max_physical_capacity(NX_NUMBER): - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_profiling_event): - start_time(NX_DATE_TIME): - exists: optional - end_time(NX_DATE_TIME): - exists: optional - description: - elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - number_of_threads(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - number_of_gpus(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - max_virtual_memory_snapshot(NX_NUMBER): - exists: recommended - max_resident_memory_snapshot(NX_NUMBER): - exists: recommended - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 224c4d79678a47bb6e07b21f6ad8592f7f0cd10f4daac6ccd71127d064185b13 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The total number of ions in the reconstruction. -# -# -# -# -# Results of a paraprobe-spatstat tool run. -# -# -# -# -# -# Version specifier of this application definition. -# -# -# -# -# -# Official NeXus NXDL schema with which this file was written. -# -# -# -# -# -# -# -# -# Given name of the program/software/tool with which this NeXus -# (configuration) file was generated. -# -# -# -# Ideally program version plus build number, or commit hash or description -# of ever persistent resources where the source code of the program and -# build instructions can be found so that the program can be configured -# ideally in such a manner that the result of this computational process -# is recreatable in the same deterministic manner. -# -# -# -# -# -# Ideally, a (globally persistent) unique identifier for referring -# to this analysis. -# -# -# -# -# Possibility for leaving a free-text description about this analysis. -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when the analysis behind this results file -# was started, i.e. the paraprobe-tool executable started as a process. -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when the analysis behind this results file -# were completed and the paraprobe-tool executable exited as a process. -# -# -# -# -# The absolute path and name of the config file for this analysis. -# -# -# -# At least SHA256 strong hash of the specific config_file for -# tracking provenance. -# -# -# -# -# -# Path to the directory where the tool should store NeXus/HDF5 results -# of this analysis. If not specified results will be stored in the -# current working directory. -# -# -# -# -# A statement whether the paraprobe-tool executable managed to -# process the analysis or failed prematurely. -# -# This status is written to the results file after the end_time -# at which point the executable must not compute any analysis. -# Only when this status message is present and shows `success`, the -# user should consider the results. In all other cases it might be -# that the executable has terminated prematurely or another error -# occurred. -# -# -# -# -# -# -# -# -# If used, contact information and eventually details -# of at least the person who performed this analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Details about the coordinate system conventions used. -# -# -# -# The individual coordinate systems which should be used. -# Field names should be prefixed with the following controlled terms -# indicating which individual coordinate system is described: -# -# * paraprobe -# * lab -# * specimen -# * laser -# * leap -# * detector -# * recon -# -# -# -# -# -# -# -# A bitmask which identifies which of the ions in the dataset were -# analyzed. -# -# -# -# Number of ions covered by the mask. -# The mask value for most may be 0. -# -# -# -# -# -# Number of bits assumed matching on a default datatype. -# (e.g. 8 bits for a C-style uint8). -# -# -# -# -# The unsigned integer array representing the content of the mask. -# If padding is used the padded bits are set to 0. The mask is for -# convenience always as large as the entire dataset as it will -# be stored compressed anyway. The convenience feature with this -# is that then the mask can be decoded with numpy and mirrored -# against the evaporation_id array and one immediately can filter -# out all points that were used by the paraprobe. -# The length of the array adds to the next unsigned integer -# if the number of ions in the dataset is not an integer -# multiple of the bitdepth. -# -# -# -# -# -# -# -# -# The iontype ID for each ion that was assigned to each ion during -# the randomization of the ionlabels. Iontype labels are just permuted -# but the total number of values for each iontype stay the same. -# -# The order matches the iontypes array from a given ranging results -# as is specified in the configuration settings inside the specific -# config_filename that was used for this spatstat analysis. -# -# -# -# -# -# -# -# K-nearest neighbor statistics. -# -# -# -# Right boundary of the binning. -# -# -# -# -# -# -# -# -# -# -# -# -# Cumulated -# -# -# -# -# -# -# -# Cumulated and normalized by total counts -# -# -# -# -# -# -# -# -# Radial distribution statistics. -# -# -# -# Right boundary of the binning. -# -# -# -# -# -# -# -# -# -# -# -# -# Cumulated -# -# -# -# -# -# -# -# Cumulated and normalized by total counts -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Specify if it was different from the number_of_processes -# in the NXcs_profiling super class. -# -# -# -# -# -# Specify if it was different from the number_of_threads -# in the NXcs_profiling super class. -# -# -# -# -# -# Specify if it was different from the number_of_threads -# in the NXcs_profiling super class. -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml index d99dd54fd1..28c4cff1e7 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml @@ -46,10 +46,10 @@ NXapm_paraprobe_selector_results(NXobject): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): # global - (NXuser): + userID(NXuser): exists: [min, 0, max, infty] name(NX_CHAR): - (NXcoordinate_system_set): + coordinate_system_set(NXcoordinate_system_set): paraprobe(NXcoordinate_system): type(NX_CHAR): handedness(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml new file mode 100644 index 0000000000..874d78f1a2 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml @@ -0,0 +1,254 @@ +category: application +doc: | + Application definition for a configuration file of the paraprobe-spatstat tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_ivec_max: | + Maximum number of atoms per molecular ion. Should be 32 for paraprobe. + n_ion_source: | + Number of different source iontypes to distinguish. + n_ion_target: | + Number of different target iontypes to distinguish. +type: group +NXapm_paraprobe_spatstat_config(NXobject): + (NXentry): + exists: [min, 1, max, 1] + definition(NX_CHAR): + \@version(NX_CHAR): + enumeration: [NXapm_paraprobe_spatstat_config] + number_of_tasks(NX_UINT): + doc: | + How many spatial_statistics tasks should the tool execute. + unit: NX_UNITLESS + spatial_statisticsID(NXapm_paraprobe_tool_config): + exists: [min, 1, max, infty] + (NXidentifier): + exists: optional + analysis_identifier(NX_UINT): + exists: recommended + reconstruction(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + position(NX_CHAR): + mass_to_charge(NX_CHAR): + ranging(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + ranging_definitions(NX_CHAR): + surface_distance(NXserialized): + exists: optional + doc: | + Distance between each ion and triangulated surface mesh. + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + distance(NX_CHAR): + edge_distance(NX_FLOAT): + doc: | + Threshold to define how far an ion has to lay at least from the edge + of the dataset so that the ion can act as a source. This means that + an ROI is placed at the location of the ion and its neighbors are + analyzed how they contribute to the computed statistics. + + The edge_distance threshold can be combined with the feature_distance threshold. This threshold defines defines up to which distance to a + microstructural feature an ROI is placed. + + The threshold is useful to process the dataset such that ROIs do + not protrude out of the dataset as this would add bias. + unit: NX_LENGTH + feature_distance(NXserialized): + exists: optional + doc: | + Distance between each ion and triangulated mesh of microstructural features. + In addition to spatial filtering and considering how far ions lie to the + edge of the dataset, it is possible to restrict the analyses to a sub-set of + ions within a distance not farther away to a feature than the feature_distance + threshold value. + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + distance(NX_CHAR): + doc: | + Absolute path in the (HDF5) file which points to the distance of each + ion to the closest feature. + feature_distance(NX_FLOAT): + doc: | + Threshold to define how close an ion has to lay to a feature so that + the ion can at all qualify as a source, i.e. that an ROI is placed + at the location of the ion and its neighbors are then analyzed + how they contribute to the computed statistics. + + Recall that this feature_distance threshold is used in combination + with the edge_distance threshold when placing ROI about source ions. + unit: NX_LENGTH + spatial_filter(NXspatial_filter): + windowing_method(NX_CHAR): + hexahedron_set(NXcg_hexahedron_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + hexahedra(NXcg_face_list_data_structure): + vertices(NX_UINT): + cylinder_set(NXcg_cylinder_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + height(NX_NUMBER): + radii(NX_NUMBER): + ellipsoid_set(NXcg_ellipsoid_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + half_axes_radii(NX_NUMBER): + orientation(NX_NUMBER): + polyhedron_set(NXcg_polyhedron_set): + exists: optional + # TODO + bitmask(NXcs_filter_boolean_mask): + exists: optional + number_of_objects(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + # leave open if scalar or matrix + # dim: (i,) + # identifier(NX_UINT): + evaporation_id_filter(NXsubsampling_filter): + exists: optional + min_incr_max(NX_INT): + iontype_filter(NXmatch_filter): + exists: optional + method(NX_CHAR): + match(NX_NUMBER): + hit_multiplicity_filter(NXmatch_filter): + exists: optional + method(NX_CHAR): + match(NX_NUMBER): + # config + randomize_iontypes(NX_BOOLEAN): + doc: | + Specifies, if the iontypes are randomized for the point cloud or not. + Internally, paraprobe uses a sequentially executed deterministic MT19987 + (MersenneTwister) pseudo-random number generator to shuffle the + iontypes randomly across the entire set of ions. That is the total + number of ions of either type remain the same but the information about + their location is randomized. + random_number_generator(NXcs_prng): + exists: recommended + type(NX_CHAR): + seed(NX_NUMBER): + warmup(NX_NUMBER): + ion_query_type_source(NX_CHAR): + doc: | + How should the iontype be interpreted on the source-side, i.e. + all these ion positions where a regions-of-interest (ROI) around + so-called source ions will be placed. Different options exist + how iontypes are interpreted given an iontype represents + in general a (molecular) ion with different isotopes that have + individually different multiplicity. + + The value resolve_all will set an ion active in the analysis regardless + of which iontype it is. Each active ion is accounted for once. + + The value resolve_unknown will set an ion active when the ion is + of the UNKNOWNTYPE type. Each active ion is accounted for once. + + The value resolve_ion will set an ion active if it is of the specific + iontype, irregardless of its elemental or isotopic details. + Each active ion is counted once. + + The value resolve_element will set an ion active, and most importantly, + account for each as many times as the (molecular) ion contains + atoms of elements in the whitelist ion_query_isotope_vector. + + The value resolve_isotope will set an ion active, and most importantly, + account for each as many times as the (molecular) ion contains + isotopes in the whitelist ion_query_isotope_vector. + + In effect, ion_query_isotope_vector acts as a whitelist to filter + which ions are considered as source ions of the correlation statistics + and how the multiplicity of each ion will be factorized, i.e. how + often it is accounted for. + enumeration: [resolve_all, resolve_unknown, resolve_ion, resolve_element, resolve_isotope] + ion_query_nuclide_source(NX_UINT): + doc: | + Matrix of isotope vectors, as many as rows as different candidates + for iontypes should be distinguished as possible source iontypes. + In the simplest case, the matrix contains only the proton number + of the element in the row, all other values set to zero. + Combined with ion_query_type_source set to resolve_element this will + recover usual spatial correlation statistics like the 1NN C-C + spatial statistics. + dim: (n_ion_source, n_ivec_max) + unit: NX_UNITLESS + ion_query_type_target(NX_CHAR): + doc: | + Similarly as ion_query_type_source how should iontypes be interpreted + on the target-side, i.e. how many counts will be bookkept for ions + which are neighbors of source ions within or on the surface of each + inspection/ROI about each source ion. + Source ion in the center of the ROI are not accounted for during + counting the summary statistics. + For details about the resolve values consider the explanations in + ion_query_type_source. These account for ion_query_type_target as well. + enumeration: [resolve_all, resolve_unknown, resolve_ion, resolve_element, resolve_isotope] + # NEW ISSUE: conditionally required only when resolve_isotope + ion_query_nuclide_target(NX_UINT): + doc: | + Matrix of isotope vectors, as many as rows as different candidates for + iontypes to distinguish as possible targets. See additional comments + under ion_query_isotope_vector_source. + dim: (n_ion_target, n_ivec_max) + unit: NX_UNITLESS + statistics(NXprocess): + doc: | + Specifies which spatial statistics to compute. + knn(NXprocess): + exists: optional + doc: | + Compute k-th nearest neighbour statistics. + kth(NX_UINT): + doc: | + Order k. + unit: NX_UNITLESS + histogram_min_incr_max(NX_FLOAT): + doc: | + Minimum value, increment, and maximum value of the histogram binning. + unit: NX_LENGTH + # \@units: nm + dim: (3,) + rdf(NXprocess): + exists: optional + doc: | + Compute radial distribution function. + histogram_min_incr_max(NX_FLOAT): + doc: | + Minimum value, increment, and maximum value of the histogram binning. + unit: NX_LENGTH + # \@units: nm + dim: (3,) + # NEW ISSUE: ripleyk(NXcollection): + # NEW ISSUE: two_point(NXcollection): + # profiling (only for stored in the first instance) + programID(NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + profiling(NXcs_profiling): + exists: recommended + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + current_working_directory(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml new file mode 100644 index 0000000000..985b36194c --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml @@ -0,0 +1,105 @@ +category: application +doc: | + Application definition for results files of the paraprobe-spatstat tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_ions: | + The total number of ions in the reconstruction. + # n_bins_knn: | + # The total number of bins in the histogram for the k-th nearest neighbor +type: group +NXapm_paraprobe_spatstat_results(NXobject): + (NXentry): + exists: [min, 1, max, 1] + definition(NX_CHAR): + \@version(NX_CHAR): + enumeration: [NXapm_paraprobe_spatstat_results] + # tasks + spatial_statisticsID(NXapm_paraprobe_tool_results): + exists: [min, 0, max, infty] + analysis_identifier(NX_UINT): + config(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + window(NXcs_filter_boolean_mask): + number_of_ions(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + # results + iontypes_randomized(NX_UINT): + doc: | + The iontype ID for each ion that was assigned to each ion during + the randomization of the ionlabels. Iontype labels are just permuted + but the total number of values for each iontype remain the same. + + The order matches the iontypes array from a given ranging results + as it is specified in the configuration settings inside the specific + config_filename that was used for this paraprobe-spatstat analysis. + unit: NX_UNITLESS + dim: (n_ions,) + knn(NXprocess): + exists: optional + doc: | + K-nearest neighbor statistics. + distance(NX_FLOAT): + doc: | + Right boundary of the binning. + unit: NX_LENGTH + dim: (i,) + probability_mass(NX_FLOAT): + unit: NX_DIMENSIONLESS + dim: (i,) + cumulated(NX_FLOAT): + doc: | + Cumulated not normalized by total counts. + unit: NX_UNITLESS + dim: (i,) + cumulated_normalized(NX_FLOAT): + doc: | + Cumulated and normalized by total counts. + unit: NX_DIMENSIONLESS + dim: (i,) + rdf(NXprocess): + exists: optional + doc: | + Radial distribution statistics. + distance(NX_FLOAT): + doc: | + Right boundary of the binning. + unit: NX_LENGTH + dim: (j,) + probability_mass(NX_FLOAT): + unit: NX_DIMENSIONLESS + dim: (j,) + cumulated(NX_FLOAT): + doc: | + Cumulated not normalized by total counts. + unit: NX_UNITLESS + dim: (j,) + cumulated_normalized(NX_FLOAT): + doc: | + Cumulated and normalized by total counts. + unit: NX_DIMENSIONLESS + dim: (j,) + # global + userID(NXuser): + exists: [min, 0, max, infty] + name(NX_CHAR): + coordinate_system_set(NXcoordinate_system_set): + paraprobe(NXcoordinate_system): + type(NX_CHAR): + handedness(NX_CHAR): + x(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + y(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + z(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml index cc4e0c98ac..74691ef271 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml @@ -162,10 +162,10 @@ NXapm_paraprobe_surfacer_results(NXobject): # TRIANGLE_SET_WRAPPING(NXprocess): # For the future as we may wish to wrap primitives other like triangles or polylines. # global - (NXuser): + userID(NXuser): exists: [min, 0, max, infty] name(NX_CHAR): - (NXcoordinate_system_set): + coordinate_system_set(NXcoordinate_system_set): paraprobe(NXcoordinate_system): type(NX_CHAR): handedness(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml index e6d85ec953..0819961cb9 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml @@ -41,7 +41,6 @@ NXapm_paraprobe_tessellator_config(NXobject): checksum(NX_CHAR): algorithm(NX_CHAR): distance(NX_CHAR): - # filter that are here tool-specific parameter spatial_filter(NXspatial_filter): windowing_method(NX_CHAR): hexahedron_set(NXcg_hexahedron_set): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml index a5185f276b..752f12a268 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml @@ -196,10 +196,10 @@ NXapm_paraprobe_tessellator_results(NXobject): bitdepth(NX_UINT): mask(NX_UINT): # global - (NXuser): + userID(NXuser): exists: [min, 0, max, infty] name(NX_CHAR): - (NXcoordinate_system_set): + coordinate_system_set(NXcoordinate_system_set): paraprobe(NXcoordinate_system): type(NX_CHAR): handedness(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml index f33a9b1a8c..5748e753ed 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml @@ -117,12 +117,12 @@ NXapm_paraprobe_transcoder_results(NXobject): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): # global - (NXuser): + userID(NXuser): exists: [min, 0, max, infty] doc: | If used, metadata of at least the person who performed this analysis. name(NX_CHAR): - (NXcoordinate_system_set): + coordinate_system_set(NXcoordinate_system_set): exists: [min, 1, max, 1] paraprobe(NXcoordinate_system): type(NX_CHAR): From fc69ce4714993c7331631f2d7b1fa0d189781b52 Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 29 Jan 2024 12:32:29 +0100 Subject: [PATCH 0538/1012] Adds NXmpes_arpes to overview page --- manual/source/mpes-structure.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/manual/source/mpes-structure.rst b/manual/source/mpes-structure.rst index 809dd34018..e13921583f 100644 --- a/manual/source/mpes-structure.rst +++ b/manual/source/mpes-structure.rst @@ -19,3 +19,6 @@ dichroism and many more. :ref:`NXmpes`: A general appdef with minimalistic metadata requirements to describe all photemission experiments. + + :ref:`NXmpes_arpes`: + An appdef for angle-resolved photoemission spectroscopy (ARPES) experiments. \ No newline at end of file From 60500ddc24d177759caf729f446ed476e644c5d4 Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Tue, 30 Jan 2024 11:23:58 +0100 Subject: [PATCH 0539/1012] Fix URLs and formats with black>24 (#152) * Updates URLs * Update ci/cd to deploy on tags * Updates url and reverst ci/cd changes * Reformat according to black>24 * Update black version in requirements --- dev_tools/docs/xsd_units.py | 1 - dev_tools/globals/urls.py | 2 +- dev_tools/tests/test_nxdl_utils.py | 1 + manual/source/conf.py | 4 ++-- requirements.txt | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/dev_tools/docs/xsd_units.py b/dev_tools/docs/xsd_units.py index 63d7714289..8306a6fa9f 100644 --- a/dev_tools/docs/xsd_units.py +++ b/dev_tools/docs/xsd_units.py @@ -5,7 +5,6 @@ the NXDL chapter. """ - from pathlib import Path from typing import List diff --git a/dev_tools/globals/urls.py b/dev_tools/globals/urls.py index 729b7d1028..2929070cc2 100644 --- a/dev_tools/globals/urls.py +++ b/dev_tools/globals/urls.py @@ -1,2 +1,2 @@ -REPO_URL = "https://github.com/nexusformat/definitions/blob/main" +REPO_URL = "https://github.com/FAIRmat-NFDI/nexus_definitions/tree/fairmat" MANUAL_URL = "https://manual.nexusformat.org" diff --git a/dev_tools/tests/test_nxdl_utils.py b/dev_tools/tests/test_nxdl_utils.py index 07e968cbda..82972e6ae4 100644 --- a/dev_tools/tests/test_nxdl_utils.py +++ b/dev_tools/tests/test_nxdl_utils.py @@ -1,6 +1,7 @@ """This is a code that performs several tests on nexus tool """ + # # Copyright The NOMAD Authors. # diff --git a/manual/source/conf.py b/manual/source/conf.py index f84671063f..bebe22b2ae 100755 --- a/manual/source/conf.py +++ b/manual/source/conf.py @@ -112,8 +112,8 @@ def setup(app): 'logo_name': True, 'github_button': True, 'github_type': 'watch', - 'github_repo': 'nexus_definitions/tree/fairmat', - 'github_user': 'FAIRmat-Experimental', + 'github_repo': 'nexus_definitions', + 'github_user': 'FAIRmat-NFDI', 'github_count': 'false', # We don't get the cute counter baloon if we want to point to the branch 'sidebar_width': '300px', 'body_max_width': 'auto', diff --git a/requirements.txt b/requirements.txt index f628ca805f..d27f482456 100644 --- a/requirements.txt +++ b/requirements.txt @@ -13,6 +13,6 @@ sphinx_comments pytest # Code style and auto-formatting -black>=22.3 +black>=24.1.1 flake8>=4 isort>=5.10 From e3abfff5888ed8180aae1723f68bdfd6ea14de74 Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 5 Feb 2024 12:34:49 +0100 Subject: [PATCH 0540/1012] Regenerate nxdls --- contributed_definitions/NXmpes.nxdl.xml | 1 - .../NXphotoemission.nxdl.xml | 32 ++++++++----------- contributed_definitions/nyaml/NXmpes.yaml | 2 +- 3 files changed, 15 insertions(+), 20 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index ed9ccec08f..8f46d4c572 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -68,7 +68,6 @@ * angle-resolved photoelectron spectroscopy (ARPES) * hard X-ray photoemission spectroscopy (HAXPES) * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) - * photoelectron emission microscopy (PEEM) * electron spectroscopy for chemical analysis (ESCA) * time-resolved angle-resolved X-ray photoelectron spectroscopy (trARPES) * spin-resolved angle-resolved X-ray photoelectron spectroscopy (spin-ARPES) diff --git a/contributed_definitions/NXphotoemission.nxdl.xml b/contributed_definitions/NXphotoemission.nxdl.xml index 26e21ce507..9d56f456e2 100644 --- a/contributed_definitions/NXphotoemission.nxdl.xml +++ b/contributed_definitions/NXphotoemission.nxdl.xml @@ -66,14 +66,14 @@ the `ISO 18115-1:2023`_ specification. Examples include: - * X-ray photoelectron spectroscopy (XPS) - * angle-resolved X-ray photoelectron spectroscopy (ARXPS) - * ultraviolet photoelectron spectroscopy (UPS) - * angle-resolved photoelectron spectroscopy (ARPES) - * hard X-ray photoemission spectroscopy (HAXPES) - * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) - * photoelectron emission microscopy (PEEM) - * electron spectroscopy for chemical analysis (ESCA) + * X-ray photoelectron spectroscopy (XPS) + * angle-resolved X-ray photoelectron spectroscopy (ARXPS) + * ultraviolet photoelectron spectroscopy (UPS) + * angle-resolved photoelectron spectroscopy (ARPES) + * hard X-ray photoemission spectroscopy (HAXPES) + * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) + * photoelectron emission microscopy (PEEM) + * electron spectroscopy for chemical analysis (ESCA) .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 @@ -102,7 +102,7 @@ - Overall energy resolution of the instrument in case the energy of the electrons + Overall energy resolution of the instrument in case the energy of the electrons is resolved. This concept is related to term `10.7 ff.`_ of the ISO 18115-1:2023 standard. @@ -126,10 +126,8 @@ - + A source used to generate a beam. Properties refer strictly to parameters of the @@ -341,13 +339,11 @@ This would also be helpful for NXtransformations--> - +the `NXdetector` base class. But some refinement is necessary there.--> Contains the raw data collected by the detector before calibration. diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index ab70f32426..110cc685a8 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -714,7 +714,7 @@ NXmpes(NXphotoemission): enumeration: kinetic: doc: - - | + - | Calibrated kinetic energy axis. - | In case the kinetic energy axis is referenced to the Fermi level :math:`E_F` From 56642903a46317755b9ccf41f0cca870f668703e Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 5 Feb 2024 12:44:56 +0100 Subject: [PATCH 0541/1012] Moves all fields to NXphotoemission --- contributed_definitions/NXmpes.nxdl.xml | 834 +----------------- .../NXphotoemission.nxdl.xml | 398 +++++++-- contributed_definitions/nyaml/NXmpes.yaml | 719 --------------- .../nyaml/NXphotoemission.yaml | 378 ++++++-- 4 files changed, 596 insertions(+), 1733 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 8f46d4c572..28dd988588 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -33,841 +33,19 @@ .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 - - - - - - - - - - Datetime of the start of the measurement. - Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, - otherwise the local time zone is assumed per ISO8601. - - - - - Datetime of the end of the measurement. - Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, - otherwise the local time zone is assumed per ISO8601. - - - - - Name of the experimental method. - - If applicable, this name should match the terms given by `Clause 11`_ of - the `ISO 18115-1:2023`_ specification. - - Examples include: - * X-ray photoelectron spectroscopy (XPS) - * angle-resolved X-ray photoelectron spectroscopy (ARXPS) - * ultraviolet photoelectron spectroscopy (UPS) - * angle-resolved photoelectron spectroscopy (ARPES) - * hard X-ray photoemission spectroscopy (HAXPES) - * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) - * electron spectroscopy for chemical analysis (ESCA) - * time-resolved angle-resolved X-ray photoelectron spectroscopy (trARPES) - * spin-resolved angle-resolved X-ray photoelectron spectroscopy (spin-ARPES) - * momentum microscopy - - .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html - .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 - - - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the time when the experiment was - performed. - - - - - Description of the MPES spectrometer and its individual parts. - - This concept is related to term `12.58`_ of the ISO 18115-1:2023 standard. - - .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 - - - - Overall energy resolution of the MPES instrument - - This concept is related to term `10.7 ff.`_ of the ISO 18115-1:2023 standard. - - .. _10.7 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 - - This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. - - .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 - - - - - - - - - - - - - - - - - A source used to generate a beam. Properties refer strictly to parameters of the - source, not of the output beam. For example, the energy of the source is not the - optical power of the beam, but the energy of the electron beam in a synchrotron - or similar. - - Note that the uppercase notation in source_TYPE means that multiple sources can - be provided. For example, in pump-probe experiments, it is possible to have both - a `source_probe` and a `source_pump` - - - - - - - - - - - - - - - - - - - - Specification of type, may also go to name. - - - - - - - - - - - - The beam emitted by this source. - Should be named with the same appendix, e.g., - for `source_probe` it should refer to `beam_probe`. - Refers to the same concept as /NXentry/NXinstrument/beam_TYPE - and may be linked. - - - - - - Properties of the photon beam at a given location. - Should be named with the same appendix as source_TYPE, e.g., - for `source_probe` it should refer to `beam_probe`. - - - - Distance between the point where the current NXbeam instance is evaluating - the beam properties and the point where the beam interacts with the sample. - For photoemission, the latter is the point where the the centre of the beam - touches the sample surface. - - - - - - - - - The source that emitted this beam. - Should be named with the same appendix, e.g., - for `beam_probe` it should refer to `source_probe`. - Refers to the same concept as /NXentry/NXinstrument/source_TYPE - and may be linked. - Should be specified if an associated source exists. - - - + - - - - - - - - - - - - - - - - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - Size, position and shape of the iris inserted in the column. - - The iris is an aperture in the lens with a variable diameter which can reduce the number of - electrons entering the analyzer. - - To add additional or other slits use the APERTURE group of NXcollectioncolumn. - - - - - - - - - - - - - - - - - - - - - - - - Size, position and shape of the entrance slit in dispersive analyzers. - - To add additional or other slits use the APERTURE group of NXenergydispersion. - - - - - Size, position and shape of the exit slit in dispersive analyzers. - - To add additional or other slits use the APERTURE group of NXenergydispersion. - - - - - - - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - - Contains the raw data collected by the detector before calibration. - The data which is considered raw might change from experiment to experiment - due to hardware pre-processing of the data. - This field ideally collects the data with the lowest level of processing - possible. - - The naming of fields should follow a convention to ensure compatibility. - It is recommend to use the following field names: - - - **pixel_x**: Detector pixel in x direction. - - **pixel_y**: Detector pixel in y direction. - - **energy**: (Un)calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). - - **kx**: (Un)calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). - - **ky**: (Un)calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). - - **kz**: (Un)calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). - - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). - Unit category: NX_ANGLE - - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - Unit category: NX_ANGLE - - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) - Unit category: NX_LENGTH - - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - Unit category: NX_LENGTH - - **delay**: Calibrated delay time. Unit category: NX_TIME (s). - - **polarization_angle**: Linear polarization angle of the incoming or - outgoing beam. - Unit category: NX_ANGLE (° or rad) - - **ellipticity**: Ellipticity of the incoming or outgoing beam. - Unit category: NX_ANGLE (° or rad) - - **time_of_flight**: Total time of flight. Unit category: NX_TIME_OF_FLIGHT - - **time_of_flight_adc**: Time-of-flight values, analog-to-digital converted. - - **external_AXIS**: Describes an axis which is coming from outside the detectors scope. - - - - - - - - - Raw data before calibration. - - - - - - - - Manipulator for positioning of the sample. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Device to measure the gas pressure around the sample. - - - - - - - - - - - In case of a single or averaged gas pressure measurement, this is the scalar gas pressure around - the sample. It can also be an 1D array of measured pressures (without time stamps). - - - - - - In the case of an experiment in which the gas pressure changes and is recorded, - this is an array of length m of gas pressures. - - - - - - - Device to bring low-energy electrons to the sample for charge neutralization - - - - - - - - - - - In case of a fixed or averaged electron current, this is the scalar current. - It can also be an 1D array of output current (without time stamps). - - - - - - In the case of an experiment in which the electron current is changed and - recorded with time stamps, this is an array of length m of current setpoints. - - - - - - - - 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 - - - - Calibration event on the energy axis. - - For XPS, the calibration should ideally be performed according to - `ISO 15472:2010`_ specification. - - .. _ISO 15472:2010: https://www.iso.org/standard/74811.html - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - - This is the calibrated spatial axis to be used for data plotting. - - - - - - - This is the momentum axis to be used for data plotting. - - - - - - For energy referencing, the measured energies are corrected for the charging potential - (i.e., the electrical potential of the surface region of an insulating sample, caused by - irradiation) such that those energies correspond to a sample with no surface charge. - Usually, the energy axis is adjusted by shifting all energies uniformally until one - well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. - - This concept is related to term `12.74 ff.`_ of the ISO 18115-1:2023 standard. - - .. _12.74 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 - - - - Electronic core or valence level that was used for the calibration. - - - - - Reference peak that was used for the calibration. - - For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge | vacuum level - - - - - The binding energy (in units of eV) that the specified emission line appeared at, - after adjusting the binding energy scale. - - This concept is related to term `12.16_ ff.`_ of the ISO 18115-1:2023 standard. - - .. _12.16_ ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - - - - - Offset between measured binding energy and calibrated binding energy of the - emission line. - - - - - This is the calibrated energy axis to be used for data plotting. - - This should link to /entry/data/energy. - - - - - - In the transmission correction, each intensity measurement for electrons of a given - kinetic energy is multiplied by the corresponding value in the relative_intensity - field of the transmission_function. This calibration procedure is used to account for - the different tranmsission efficiencies when using different lens modes. - - - - Transmission function of the electron analyser. - - The transmission function (TF) specifies the detection efficiency for electrons of - different kinetic energy passing through the electron analyser. - This can be a link to /entry/instrument/electronanalyser/transmission_function. - - - - - - - - - - - - - - Kinetic energy values - - - - - - - - Relative transmission efficiency for the given kinetic energies - - - - - - + - - - - - For samples containing a single pure substance. For mixtures use the - NXsample_component_set and NXsample_component group in NXsample instead. - - - - The chemical formula of the sample (using CIF conventions). - - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - - - - - - - - - - - - - A set of activities that occurred to the sample prior to/during photoemission - experiment. - - - - Details about the sample preparation for the MPES experiment (e.g. UHV cleaving, - in-situ growth, sputtering/annealing, etc.). - - - - - - Details about the method of sample preparation before the MPES experiment. - - - - - - - Sample temperature (either controlled or just measured). - - - - Temperature sensor measuring the sample temperature. - This should be a link to /entry/instrument/manipulator/temperature_sensor. - - - - - Device to heat the sample. - This should be a link to /entry/instrument/manipulator/sample_heater. - - - - - Cryostat for cooling the sample. - This should be a link to /entry/instrument/manipulator/cryostat. - - - - - - Gas pressure surrounding the sample. - - - - Gauge measuring the gas pressure. - - This should be a link to /entry/instrument/pressure_gauge. - - - - - - Bias of the sample with respect to analyser ground. - - This concept is related to term `8.41`_ of the ISO 18115-1:2023 standard. - - .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 - - - - Sensor measuring the applied voltage. - - This should be a link to /entry/instrument/manipulator/sample_bias_voltmeter. - - - - - Actuator applying a voltage to sample and sample holder. - - This should be a link to /entry/instrument/manipulator/sample_bias_potentiostat. - - - - - - Drain current of the sample and sample holder. - - - - Amperemeter measuring the drain current of the sample and sample holder. - - This should be a link to /entry/instrument/manipulator/drain_current_amperemeter. - - - - - - Current of low-energy electrons to the sample for charge neutralization. - - - - Flood gun creating a current of low-energy electrons. - - This should be a link to /entry/instrument/flood_gun. - - - + + - - The default NXdata field containing a view on the measured data. - This NXdata field contains a collection of the main relevant fields (axes). - In NXmpes, it is required to provide an energy axis. - If you want to provide additional views on your data, you can additionally use - the generic NXdata group of NXentry. - The other data fields inside this NXdata group should be named according to conventions - to ensure compatibility. We recommened the following field names - for common data fields: - - - **kx**: Calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). - - **ky**: Calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). - - **kz**: Calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). - - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). - Unit category: NX_ANGLE - - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - Unit category: NX_ANGLE - - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) - Unit category: NX_LENGTH - - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - Unit category: NX_LENGTH - - **delay**: Calibrated delay time. Unit category: NX_TIME (s). - - **polarization_angle**: Linear polarization angle of the incoming or - outgoing beam. This could be a link to - /entry/instrument/beam/incident_polarization_angle or - /entry/instrument/beam/final_polarization_angle if they exist. - Unit category: NX_ANGLE (° or rad) - - **ellipticity**: Ellipticity of the incoming or outgoing beam. - Could be a link to /entry/instrument/beam/incident_ellipticity or - /entry/instrument/beam/final_ellipticity if they exist. - Unit category: NX_ANGLE (° or rad) - - - - - - - - - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, momentum, spatial coordinate, pump-probe - delay, spin index, temperature, etc. The axes traces should be linked to the - actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - Calibrated energy axis. - - This could be a link to either - /entry/process/energy_calibration/calibrated_axis or - /entry/process/energy_correction/calibrated_axis. - - - - The energy can be either stored as kinetic or as binding energy. - - - - - Calibrated kinetic energy axis. - - In case the kinetic energy axis is referenced to the Fermi level :math:`E_F` - (e.g., in entry/process/energy_referencing), kinetic energies :math:`E` are - provided as :math:`E-E_F`. - - This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. - - .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 - - - - - Calibrated binding energy axis. - - This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. - - .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - - - - - + - - - The energy can be dispersed according to different strategies. ``energy_depends`` points to - the path of a field defining the calibrated axis on which the energy axis depends. - - For example: - @energy_depends: 'entry/process/energy_calibration' - - + diff --git a/contributed_definitions/NXphotoemission.nxdl.xml b/contributed_definitions/NXphotoemission.nxdl.xml index 9d56f456e2..2e8640d2d0 100644 --- a/contributed_definitions/NXphotoemission.nxdl.xml +++ b/contributed_definitions/NXphotoemission.nxdl.xml @@ -53,16 +53,22 @@ Datetime of the start of the measurement. + Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, + otherwise the local time zone is assumed per ISO8601. Datetime of the end of the measurement. + Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, + otherwise the local time zone is assumed per ISO8601. - A name of the experimental method according to `Clause 11`_ of + Name of the experimental method. + + If applicable, this name should match the terms given by `Clause 11`_ of the `ISO 18115-1:2023`_ specification. Examples include: @@ -72,8 +78,10 @@ * angle-resolved photoelectron spectroscopy (ARPES) * hard X-ray photoemission spectroscopy (HAXPES) * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) - * photoelectron emission microscopy (PEEM) * electron spectroscopy for chemical analysis (ESCA) + * time-resolved angle-resolved X-ray photoelectron spectroscopy (trARPES) + * spin-resolved angle-resolved X-ray photoelectron spectroscopy (spin-ARPES) + * momentum microscopy .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 @@ -91,19 +99,22 @@ - Name of the affiliation of the user at the point in time when the experiment was + Name of the affiliation of the user at the time when the experiment was performed. - Photoemission instrument + Description of the MPES spectrometer and its individual parts. + + This concept is related to term `12.58`_ of the ISO 18115-1:2023 standard. + + .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 - Overall energy resolution of the instrument in case the energy of the electrons - is resolved. + Overall energy resolution of the MPES instrument This concept is related to term `10.7 ff.`_ of the ISO 18115-1:2023 standard. @@ -126,14 +137,12 @@ - A source used to generate a beam. Properties refer strictly to parameters of the source, not of the output beam. For example, the energy of the source is not the optical power of the beam, but the energy of the electron beam in a synchrotron - and so on. + or similar. Note that the uppercase notation in source_TYPE means that multiple sources can be provided. For example, in pump-probe experiments, it is possible to have both @@ -177,9 +186,6 @@ - Properties of the photon beam at a given location. @@ -198,13 +204,14 @@ This would also be helpful for NXtransformations--> - + The source that emitted this beam. Should be named with the same appendix, e.g., for `beam_probe` it should refer to `source_probe`. Refers to the same concept as /NXentry/NXinstrument/source_TYPE and may be linked. + Should be specified if an associated source exists. @@ -215,15 +222,8 @@ This would also be helpful for NXtransformations--> - - - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - Refers to Term `10.24`_ of the ISO 18115-1:2023 specification. - - .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 - + + @@ -231,10 +231,10 @@ This would also be helpful for NXtransformations--> - + - + @@ -243,6 +243,7 @@ This would also be helpful for NXtransformations--> + @@ -278,7 +279,7 @@ This would also be helpful for NXtransformations--> - + @@ -290,7 +291,7 @@ This would also be helpful for NXtransformations--> - + Size, position and shape of the entrance slit in dispersive analyzers. @@ -339,11 +340,6 @@ This would also be helpful for NXtransformations--> - Contains the raw data collected by the detector before calibration. @@ -396,23 +392,129 @@ the `NXdetector` base class. But some refinement is necessary there.--> Manipulator for positioning of the sample. - - - - - Bias of the sample with respect to analyser ground. - - This field may also be found in NXsample if present. - - This concept is related to term `8.41`_ of the ISO 18115-1:2023 standard. - - .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + + + + + + Device to measure the gas pressure around the sample. + + + + + + + + + + + In case of a single or averaged gas pressure measurement, this is the scalar gas pressure around + the sample. It can also be an 1D array of measured pressures (without time stamps). + + + + + + In the case of an experiment in which the gas pressure changes and is recorded, + this is an array of length m of gas pressures. + + + + + + + Device to bring low-energy electrons to the sample for charge neutralization + + + + + + + + + + + In case of a fixed or averaged electron current, this is the scalar current. + It can also be an 1D array of output current (without time stamps). + + + + + + In the case of an experiment in which the electron current is changed and + recorded with time stamps, this is an array of length m of current setpoints. + + @@ -513,7 +615,7 @@ the `NXdetector` base class. But some refinement is necessary there.--> field of the transmission_function. This calibration procedure is used to account for the different tranmsission efficiencies when using different lens modes. - + Transmission function of the electron analyser. @@ -552,20 +654,16 @@ the `NXdetector` base class. But some refinement is necessary there.--> - + - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. + For samples containing a single pure substance. For mixtures use the + NXsample_component_set and NXsample_component group in NXsample instead. + + + The chemical formula of the sample (using CIF conventions). + + @@ -576,29 +674,6 @@ the `NXdetector` base class. But some refinement is necessary there.--> - - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - - - - - Description of the surface preparation technique for the XPS experiment, i.e. - UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report - of the previous operations, in any format(NXnote allows to add pictures, audio, - movies). Alternatively, a reference to the location or a unique identifier or - other metadata file. In the case these are not available, free-text description. - - - - - In the case of a fixed temperature measurement this is the scalar temperature of - the sample. In the case of an experiment in which the temperature is changed and - recoded, this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. - - @@ -607,19 +682,116 @@ the `NXdetector` base class. But some refinement is necessary there.--> - - + - Voltage applied to sample and sample holder. + A set of activities that occurred to the sample prior to/during photoemission + experiment. - + + + Details about the sample preparation for the MPES experiment (e.g. UHV cleaving, + in-situ growth, sputtering/annealing, etc.). + + + + + + Details about the method of sample preparation before the MPES experiment. + + + + + + + Sample temperature (either controlled or just measured). + + + + Temperature sensor measuring the sample temperature. + This should be a link to /entry/instrument/manipulator/temperature_sensor. + + + + + Device to heat the sample. + This should be a link to /entry/instrument/manipulator/sample_heater. + + + + + Cryostat for cooling the sample. + This should be a link to /entry/instrument/manipulator/cryostat. + + + + + + Gas pressure surrounding the sample. + + + + Gauge measuring the gas pressure. + + This should be a link to /entry/instrument/pressure_gauge. + + + + + + Bias of the sample with respect to analyser ground. + + This concept is related to term `8.41`_ of the ISO 18115-1:2023 standard. + + .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 + + + + Sensor measuring the applied voltage. + + This should be a link to /entry/instrument/manipulator/sample_bias_voltmeter. + + + + + Actuator applying a voltage to sample and sample holder. + + This should be a link to /entry/instrument/manipulator/sample_bias_potentiostat. + + + + + + Drain current of the sample and sample holder. + + + + Amperemeter measuring the drain current of the sample and sample holder. + + This should be a link to /entry/instrument/manipulator/drain_current_amperemeter. + + + + + + Current of low-energy electrons to the sample for charge neutralization. + + + + Flood gun creating a current of low-energy electrons. + + This should be a link to /entry/instrument/flood_gun. + + + - + - An NXdata field containing a view on the measured data. + The default NXdata field containing a view on the measured data. This NXdata field contains a collection of the main relevant fields (axes). - In NXmpes, it is required to provide an ``energy`` axis (Unit category: NX_ENERGY). - The other data fields ideally should be named according to conventions + In NXmpes, it is required to provide an energy axis. + If you want to provide additional views on your data, you can additionally use + the generic NXdata group of NXentry. + The other data fields inside this NXdata group should be named according to conventions to ensure compatibility. We recommened the following field names for common data fields: @@ -658,6 +830,54 @@ the `NXdetector` base class. But some refinement is necessary there.--> actual encoder position in NXinstrument or calibrated axes in NXprocess. + + + Calibrated energy axis. + + This could be a link to either + /entry/process/energy_calibration/calibrated_axis or + /entry/process/energy_correction/calibrated_axis. + + + + The energy can be either stored as kinetic or as binding energy. + + + + + Calibrated kinetic energy axis. + + In case the kinetic energy axis is referenced to the Fermi level :math:`E_F` + (e.g., in entry/process/energy_referencing), kinetic energies :math:`E` are + provided as :math:`E-E_F`. + + This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. + + .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 + + + + + Calibrated binding energy axis. + + This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. + + .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + + + + + + + + + The energy can be dispersed according to different strategies. ``energy_depends`` points to + the path of a field defining the calibrated axis on which the energy axis depends. + + For example: + @energy_depends: 'entry/process/energy_calibration' + + diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 110cc685a8..faa07c75df 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -11,740 +11,21 @@ doc: | type: group NXmpes(NXphotoemission): (NXentry): - definition: - \@version: - enumeration: [NXmpes] - title: - start_time(NX_DATE_TIME): - doc: | - Datetime of the start of the measurement. - Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, - otherwise the local time zone is assumed per ISO8601. - end_time(NX_DATE_TIME): - exists: recommended - doc: | - Datetime of the end of the measurement. - Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, - otherwise the local time zone is assumed per ISO8601. - method: - exists: recommended - doc: | - Name of the experimental method. - - If applicable, this name should match the terms given by `Clause 11`_ of - the `ISO 18115-1:2023`_ specification. - - Examples include: - * X-ray photoelectron spectroscopy (XPS) - * angle-resolved X-ray photoelectron spectroscopy (ARXPS) - * ultraviolet photoelectron spectroscopy (UPS) - * angle-resolved photoelectron spectroscopy (ARPES) - * hard X-ray photoemission spectroscopy (HAXPES) - * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) - * electron spectroscopy for chemical analysis (ESCA) - * time-resolved angle-resolved X-ray photoelectron spectroscopy (trARPES) - * spin-resolved angle-resolved X-ray photoelectron spectroscopy (spin-ARPES) - * momentum microscopy - - .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html - .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 - (NXuser): - exists: recommended - doc: | - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - name: - doc: | - Name of the user. - affiliation: - doc: | - Name of the affiliation of the user at the time when the experiment was - performed. (NXinstrument): - doc: - - | - Description of the MPES spectrometer and its individual parts. - - | - xref: - spec: ISO 18115-1:2023 - term: 12.58 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 energy_resolution(NXresolution): exists: recommended - doc: - - | - Overall energy resolution of the MPES instrument - - | - xref: - spec: ISO 18115-1:2023 - term: 10.7 ff. - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 - - | - xref: - spec: ISO 18115-1:2023 - term: 10.24 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 - physical_quantity: - enumeration: [energy] - type: - exists: recommended - resolution(NX_FLOAT): - unit: NX_ENERGY - device_information(NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - source_TYPE(NXsource): - exists: recommended - doc: | - A source used to generate a beam. Properties refer strictly to parameters of the - source, not of the output beam. For example, the energy of the source is not the - optical power of the beam, but the energy of the electron beam in a synchrotron - or similar. - - Note that the uppercase notation in source_TYPE means that multiple sources can - be provided. For example, in pump-probe experiments, it is possible to have both - a `source_probe` and a `source_pump` - type: - enumeration: [Synchrotron X-ray Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, UV Plasma Source, Metal Jet X-ray, HHG laser, UV lamp, Monochromatized electron source, other] - type_other: - exists: optional - doc: | - Specification of type, may also go to name. - name: - exists: recommended - probe: - exists: optional - device_information(NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - associated_beam(NXbeam): - doc: | - The beam emitted by this source. - Should be named with the same appendix, e.g., - for `source_probe` it should refer to `beam_probe`. - Refers to the same concept as /NXentry/NXinstrument/beam_TYPE - and may be linked. - beam_TYPE(NXbeam): - doc: | - Properties of the photon beam at a given location. - Should be named with the same appendix as source_TYPE, e.g., - for `source_probe` it should refer to `beam_probe`. - distance(NX_NUMBER): - unit: NX_LENGTH - exists: recommended - doc: | - Distance between the point where the current NXbeam instance is evaluating - the beam properties and the point where the beam interacts with the sample. - For photoemission, the latter is the point where the the centre of the beam - touches the sample surface. - incident_energy(NX_FLOAT): - unit: NX_ENERGY - incident_energy_spread(NX_NUMBER): - exists: recommended - unit: NX_ENERGY - incident_polarization(NX_NUMBER): - exists: recommended - unit: NX_ANY - extent(NX_FLOAT): - exists: recommended - associated_source(NXsource): - exists: recommended - doc: | - The source that emitted this beam. - Should be named with the same appendix, e.g., - for `beam_probe` it should refer to `source_probe`. - Refers to the same concept as /NXentry/NXinstrument/source_TYPE - and may be linked. - Should be specified if an associated source exists. (NXelectronanalyser): - device_information(NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - description: - work_function(NX_FLOAT): - unit: NX_ENERGY - exists: recommended energy_resolution(NXresolution): exists: recommended - type: - exists: recommended - physical_quantity: - enumeration: [energy] - resolution(NX_FLOAT): - fast_axes: - exists: recommended - slow_axes: - exists: recommended - transmission_function(NXdata): - exists: optional - (NXcollectioncolumn): - scheme: - doc: | - Scheme of the electron collection column. - enumeration: [angular dispersive, spatial dispersive, momentum dispersive, non-dispersive] - mode: - exists: recommended - projection: - exists: recommended - angular_acceptance(NX_FLOAT): - exists: optional - spatial_acceptance(NX_FLOAT): - exists: optional - field_aperture(NXaperture): - exists: optional - doc: | - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - contrast_aperture(NXaperture): - exists: optional - doc: | - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - iris(NXaperture): - exists: optional - doc: | - Size, position and shape of the iris inserted in the column. - - The iris is an aperture in the lens with a variable diameter which can reduce the number of - electrons entering the analyzer. - - To add additional or other slits use the APERTURE group of NXcollectioncolumn. - device_information(NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - (NXenergydispersion): - scheme: - enumeration: [tof, hemispherical, double hemispherical, cylindrical mirror, display mirror, retarding grid] - pass_energy(NX_FLOAT): - unit: NX_ENERGY - energy_scan_mode: - exists: recommended - entrance_slit(NXaperture): - exists: optional - doc: | - Size, position and shape of the entrance slit in dispersive analyzers. - - To add additional or other slits use the APERTURE group of NXenergydispersion. - exit_slit(NXaperture): - exists: optional - doc: | - Size, position and shape of the exit slit in dispersive analyzers. - - To add additional or other slits use the APERTURE group of NXenergydispersion. - device_information(NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - (NXdetector): - amplifier_type: - exists: recommended - doc: | - Type of electron amplifier in the first amplification step. - enumeration: [MCP, channeltron] - detector_type: - exists: recommended - doc: | - Description of the detector type. - enumeration: [DLD, Phosphor+CCD, Phosphor+CMOS, ECMOS, Anode, Multi-anode] - device_information(NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - raw_data(NXdata): - exists: recommended - doc: | - Contains the raw data collected by the detector before calibration. - The data which is considered raw might change from experiment to experiment - due to hardware pre-processing of the data. - This field ideally collects the data with the lowest level of processing - possible. - - The naming of fields should follow a convention to ensure compatibility. - It is recommend to use the following field names: - - - **pixel_x**: Detector pixel in x direction. - - **pixel_y**: Detector pixel in y direction. - - **energy**: (Un)calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). - - **kx**: (Un)calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). - - **ky**: (Un)calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). - - **kz**: (Un)calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). - - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). - Unit category: NX_ANGLE - - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - Unit category: NX_ANGLE - - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) - Unit category: NX_LENGTH - - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - Unit category: NX_LENGTH - - **delay**: Calibrated delay time. Unit category: NX_TIME (s). - - **polarization_angle**: Linear polarization angle of the incoming or - outgoing beam. - Unit category: NX_ANGLE (° or rad) - - **ellipticity**: Ellipticity of the incoming or outgoing beam. - Unit category: NX_ANGLE (° or rad) - - **time_of_flight**: Total time of flight. Unit category: NX_TIME_OF_FLIGHT - - **time_of_flight_adc**: Time-of-flight values, analog-to-digital converted. - - **external_AXIS**: Describes an axis which is coming from outside the detectors scope. - \@signal: - enumeration: [raw] - raw(NX_NUMBER): - doc: | - Raw data before calibration. - (NXmanipulator): - exists: optional - doc: | - Manipulator for positioning of the sample. - temperature_sensor(NXsensor): - exists: recommended - name: - exists: recommended - measurement: - enumeration: [temperature] - type: - exists: optional - value(NX_FLOAT): - sample_heater(NXactuator): - exists: optional - name: - exists: recommended - physical_quantity: - enumeration: [temperature] - type: - exists: optional - heater_power(NX_FLOAT): - (NXpid): - exists: recommended - setpoint(NX_FLOAT): - exists: recommended - cryostat(NXactuator): - exists: optional - name: - exists: recommended - physical_quantity: - enumeration: [temperature] - type: - exists: optional - (NXpid): - setpoint(NX_FLOAT): - exists: recommended - drain_current_amperemeter(NXsensor): - exists: optional - name: - exists: recommended - measurement: - enumeration: [current] - type: - exists: optional - value(NX_FLOAT): - sample_bias_voltmeter(NXsensor): - exists: recommended - name: - exists: recommended - measurement: - enumeration: [voltage] - type: - exists: optional - value(NX_FLOAT): - sample_bias_potentiostat(NXactuator): - exists: recommended - name: - exists: recommended - physical_quantity: - enumeration: [voltage] - type: - exists: optional - (NXpid): - exists: recommended - setpoint(NX_FLOAT): - exists: recommended - device_information(NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - pressure_gauge(NXsensor): - exists: recommended - doc: | - Device to measure the gas pressure around the sample. - name: - exists: recommended - measurement: - enumeration: [pressure] - type: - exists: optional - value(NX_FLOAT): - unit: NX_PRESSURE - doc: | - In case of a single or averaged gas pressure measurement, this is the scalar gas pressure around - the sample. It can also be an 1D array of measured pressures (without time stamps). - value_log(NXlog): - exists: optional - value(NX_NUMBER): - unit: NX_PRESSURE - doc: | - In the case of an experiment in which the gas pressure changes and is recorded, - this is an array of length m of gas pressures. - flood_gun(NXactuator): - exists: optional - doc: | - Device to bring low-energy electrons to the sample for charge neutralization - name: - exists: recommended - physical_quantity: - enumeration: [current] - type: - exists: optional - current(NX_FLOAT): - exists: recommended - unit: NX_CURRENT - doc: | - In case of a fixed or averaged electron current, this is the scalar current. - It can also be an 1D array of output current (without time stamps). - current_log(NXlog): - exists: optional - value(NX_NUMBER): - unit: NX_CURRENT - doc: | - In the case of an experiment in which the electron current is changed and - recorded with time stamps, this is an array of length m of current setpoints. (NXprocess): - exists: recommended - doc: | - 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 energy_calibration(NXcalibration): - exists: optional - doc: | - Calibration event on the energy axis. - - For XPS, the calibration should ideally be performed according to - `ISO 15472:2010`_ specification. - - .. _ISO 15472:2010: https://www.iso.org/standard/74811.html - calibrated_axis(NX_FLOAT): - exists: recommended - doc: | - This is the calibrated energy axis to be used for data plotting. - angular_calibration(NXcalibration): - exists: optional - calibrated_axis(NX_FLOAT): - exists: recommended - doc: | - This is the calibrated angular axis to be used for data plotting. - spatial_calibration(NXcalibration): - exists: optional - calibrated_axis(NX_FLOAT): - exists: recommended - doc: | - This is the calibrated spatial axis to be used for data plotting. - momentum_calibration(NXcalibration): - exists: optional - calibrated_axis(NX_FLOAT): - exists: recommended - doc: | - This is the momentum axis to be used for data plotting. - energy_referencing(NXcalibration): - exists: optional - doc: - - | - For energy referencing, the measured energies are corrected for the charging potential - (i.e., the electrical potential of the surface region of an insulating sample, caused by - irradiation) such that those energies correspond to a sample with no surface charge. - Usually, the energy axis is adjusted by shifting all energies uniformally until one - well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. - - | - xref: - spec: ISO 18115-1:2023 - term: 12.74 ff. - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 - level(NXelectron_level): - exists: recommended - doc: | - Electronic core or valence level that was used for the calibration. - reference_peak: - doc: | - Reference peak that was used for the calibration. - - For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge | vacuum level - binding_energy(NX_FLOAT): - exists: recommended - doc: - - | - The binding energy (in units of eV) that the specified emission line appeared at, - after adjusting the binding energy scale. - - | - xref: - spec: ISO 18115-1:2023 - term: 12.16_ ff. - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - offset(NX_FLOAT): - exists: recommended - doc: | - Offset between measured binding energy and calibrated binding energy of the - emission line. - calibrated_axis(NX_FLOAT): - exists: recommended - doc: | - This is the calibrated energy axis to be used for data plotting. - - This should link to /entry/data/energy. - transmission_correction(NXcalibration): - exists: optional - doc: | - In the transmission correction, each intensity measurement for electrons of a given - kinetic energy is multiplied by the corresponding value in the relative_intensity - field of the transmission_function. This calibration procedure is used to account for - the different tranmsission efficiencies when using different lens modes. - transmission_function(NXdata): - exists: recommended - doc: | - Transmission function of the electron analyser. - - The transmission function (TF) specifies the detection efficiency for electrons of - different kinetic energy passing through the electron analyser. - This can be a link to /entry/instrument/electronanalyser/transmission_function. - \@signal: - enumeration: [relative_intensity] - \@axes: - enumeration: [kinetic_energy] - kinetic_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - Kinetic energy values - dimensions: - rank: 1 - dim: [[1, n_transmission_function]] - relative_intensity(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Relative transmission efficiency for the given kinetic energies - dimensions: - rank: 1 - dim: [[1, n_transmission_function]] - (NXsample): - name: - (NXsubstance): - exists: recommended - doc: | - For samples containing a single pure substance. For mixtures use the - NXsample_component_set and NXsample_component group in NXsample instead. - molecular_formula_hill: - exists: recommended - doc: | - The chemical formula of the sample (using CIF conventions). - atom_types: - exists: recommended - 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`. - physical_form: - exists: recommended - situation: - exists: recommended - enumeration: [vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere] - sample_history(NXsample_history): - exists: recommended - doc: | - A set of activities that occurred to the sample prior to/during photoemission - experiment. - sample_preparation(NXphysical_process): - exists: recommended - doc: | - Details about the sample preparation for the MPES experiment (e.g. UHV cleaving, - in-situ growth, sputtering/annealing, etc.). - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - exists: recommended - method: - exists: recommended - doc: | - Details about the method of sample preparation before the MPES experiment. - temperature(NXenvironment): - exists: recommended - doc: | - Sample temperature (either controlled or just measured). - temperature_sensor(NXsensor): - doc: | - Temperature sensor measuring the sample temperature. - This should be a link to /entry/instrument/manipulator/temperature_sensor. - sample_heater(NXactuator): - exists: optional - doc: | - Device to heat the sample. - This should be a link to /entry/instrument/manipulator/sample_heater. - cryostat(NXactuator): - exists: optional - doc: | - Cryostat for cooling the sample. - This should be a link to /entry/instrument/manipulator/cryostat. - gas_pressure(NXenvironment): - exists: recommended - doc: | - Gas pressure surrounding the sample. - pressure_gauge(NXsensor): - doc: | - Gauge measuring the gas pressure. - - This should be a link to /entry/instrument/pressure_gauge. - bias(NXenvironment): exists: recommended - doc: - - | - Bias of the sample with respect to analyser ground. - - | - xref: - spec: ISO 18115-1:2023 - term: 8.41 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 - voltmeter(NXsensor): - doc: | - Sensor measuring the applied voltage. - - This should be a link to /entry/instrument/manipulator/sample_bias_voltmeter. - potentiostat(NXactuator): - exists: optional - doc: | - Actuator applying a voltage to sample and sample holder. - - This should be a link to /entry/instrument/manipulator/sample_bias_potentiostat. - drain_current(NXenvironment): - exists: optional - doc: | - Drain current of the sample and sample holder. - amperemeter(NXsensor): - doc: | - Amperemeter measuring the drain current of the sample and sample holder. - - This should be a link to /entry/instrument/manipulator/drain_current_amperemeter. - flood_gun_current(NXenvironment): - exists: optional - doc: | - Current of low-energy electrons to the sample for charge neutralization. - flood_gun(NXactuator): - doc: | - Flood gun creating a current of low-energy electrons. - - This should be a link to /entry/instrument/flood_gun. data(NXdata): - doc: | - The default NXdata field containing a view on the measured data. - This NXdata field contains a collection of the main relevant fields (axes). - In NXmpes, it is required to provide an energy axis. - If you want to provide additional views on your data, you can additionally use - the generic NXdata group of NXentry. - The other data fields inside this NXdata group should be named according to conventions - to ensure compatibility. We recommened the following field names - for common data fields: - - - **kx**: Calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). - - **ky**: Calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). - - **kz**: Calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). - - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). - Unit category: NX_ANGLE - - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - Unit category: NX_ANGLE - - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) - Unit category: NX_LENGTH - - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - Unit category: NX_LENGTH - - **delay**: Calibrated delay time. Unit category: NX_TIME (s). - - **polarization_angle**: Linear polarization angle of the incoming or - outgoing beam. This could be a link to - /entry/instrument/beam/incident_polarization_angle or - /entry/instrument/beam/final_polarization_angle if they exist. - Unit category: NX_ANGLE (° or rad) - - **ellipticity**: Ellipticity of the incoming or outgoing beam. - Could be a link to /entry/instrument/beam/incident_ellipticity or - /entry/instrument/beam/final_ellipticity if they exist. - Unit category: NX_ANGLE (° or rad) - \@signal: - enumeration: [data] - data(NX_NUMBER): - unit: NX_ANY - doc: | - 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. energy(NX_NUMBER): - unit: NX_ENERGY - doc: | - Calibrated energy axis. - - This could be a link to either - /entry/process/energy_calibration/calibrated_axis or - /entry/process/energy_correction/calibrated_axis. - \@type: - type: NX_CHAR - doc: | - The energy can be either stored as kinetic or as binding energy. - enumeration: - kinetic: - doc: - - | - Calibrated kinetic energy axis. - - | - In case the kinetic energy axis is referenced to the Fermi level :math:`E_F` - (e.g., in entry/process/energy_referencing), kinetic energies :math:`E` are - provided as :math:`E-E_F`. - - | - xref: - spec: ISO 18115-1:2023 - term: 3.35 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 - binding: - doc: - - | - Calibrated binding energy axis. - - | - xref: - spec: ISO 18115-1:2023 - term: 12.16 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 \@energy_indices: exists: recommended \@energy_depends: - type: NX_CHAR exists: recommended - doc: | - The energy can be dispersed according to different strategies. ``energy_depends`` points to - the path of a field defining the calibrated axis on which the energy axis depends. - - For example: - @energy_depends: 'entry/process/energy_calibration' # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ # 0858e4c498e1d031bbe35e761fdbb30b8db75d6725f7b39b320d53a90ec23587 diff --git a/contributed_definitions/nyaml/NXphotoemission.yaml b/contributed_definitions/nyaml/NXphotoemission.yaml index d5dbe92f23..777eb3544f 100644 --- a/contributed_definitions/nyaml/NXphotoemission.yaml +++ b/contributed_definitions/nyaml/NXphotoemission.yaml @@ -23,14 +23,20 @@ NXphotoemission(NXobject): start_time(NX_DATE_TIME): doc: | Datetime of the start of the measurement. + Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, + otherwise the local time zone is assumed per ISO8601. end_time(NX_DATE_TIME): exists: recommended doc: | Datetime of the end of the measurement. + Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, + otherwise the local time zone is assumed per ISO8601. method: exists: recommended doc: | - A name of the experimental method according to `Clause 11`_ of + Name of the experimental method. + + If applicable, this name should match the terms given by `Clause 11`_ of the `ISO 18115-1:2023`_ specification. Examples include: @@ -40,8 +46,10 @@ NXphotoemission(NXobject): * angle-resolved photoelectron spectroscopy (ARPES) * hard X-ray photoemission spectroscopy (HAXPES) * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) - * photoelectron emission microscopy (PEEM) * electron spectroscopy for chemical analysis (ESCA) + * time-resolved angle-resolved X-ray photoelectron spectroscopy (trARPES) + * spin-resolved angle-resolved X-ray photoelectron spectroscopy (spin-ARPES) + * momentum microscopy .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 @@ -55,23 +63,28 @@ NXphotoemission(NXobject): Name of the user. affiliation: doc: | - Name of the affiliation of the user at the point in time when the experiment was + Name of the affiliation of the user at the time when the experiment was performed. (NXinstrument): - doc: | - Photoemission instrument + doc: + - | + Description of the MPES spectrometer and its individual parts. + - | + xref: + spec: ISO 18115-1:2023 + term: 12.58 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 energy_resolution(NXresolution): exists: optional doc: - - | - Overall energy resolution of the instrument in case the energy of the electrons - is resolved. - - | + - | + Overall energy resolution of the MPES instrument + - | xref: spec: ISO 18115-1:2023 term: 10.7 ff. url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 - - | + - | xref: spec: ISO 18115-1:2023 term: 10.24 @@ -90,16 +103,13 @@ NXphotoemission(NXobject): exists: recommended identifier: exists: recommended - - # Comment from mpes may workshop: - # - There is much more information which can be provided for NXsource source_TYPE(NXsource): exists: recommended doc: | A source used to generate a beam. Properties refer strictly to parameters of the source, not of the output beam. For example, the energy of the source is not the optical power of the beam, but the energy of the electron beam in a synchrotron - and so on. + or similar. Note that the uppercase notation in source_TYPE means that multiple sources can be provided. For example, in pump-probe experiments, it is possible to have both @@ -129,10 +139,6 @@ NXphotoemission(NXobject): for `source_probe` it should refer to `beam_probe`. Refers to the same concept as /NXentry/NXinstrument/beam_TYPE and may be linked. - - # It would be nice if we had the notion of linking in nexus or if - # we have a subdefinition NXlink to refer to a path. - # This would also be helpful for NXtransformations beam_TYPE(NXbeam): doc: | Properties of the photon beam at a given location. @@ -157,12 +163,14 @@ NXphotoemission(NXobject): extent(NX_FLOAT): exists: recommended associated_source(NXsource): + exists: recommended doc: | The source that emitted this beam. Should be named with the same appendix, e.g., for `beam_probe` it should refer to `source_probe`. Refers to the same concept as /NXentry/NXinstrument/source_TYPE and may be linked. + Should be specified if an associated source exists. (NXelectronanalyser): device_information(NXfabrication): exists: recommended @@ -173,16 +181,11 @@ NXphotoemission(NXobject): identifier: exists: recommended description: - energy_resolution(NX_FLOAT): - exists: optional + work_function(NX_FLOAT): unit: NX_ENERGY - doc: | - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - Refers to Term `10.24`_ of the ISO 18115-1:2023 specification. - - .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 + exists: recommended + energy_resolution(NXresolution): + exists: optional type: exists: recommended physical_quantity: @@ -192,13 +195,13 @@ NXphotoemission(NXobject): exists: recommended slow_axes: exists: recommended - transmission_function(NX_FLOAT): + transmission_function(NXdata): exists: optional (NXcollectioncolumn): scheme: doc: | Scheme of the electron collection column. - enumeration: [angular dispersive, spatial dispersive, non-dispersive] + enumeration: [angular dispersive, spatial dispersive, momentum dispersive, non-dispersive] mode: exists: recommended projection: @@ -235,12 +238,12 @@ NXphotoemission(NXobject): identifier: exists: recommended (NXenergydispersion): - exists: optional scheme: enumeration: [tof, hemispherical, double hemispherical, cylindrical mirror, display mirror, retarding grid] pass_energy(NX_FLOAT): unit: NX_ENERGY energy_scan_mode: + exists: recommended entrance_slit(NXaperture): exists: optional doc: | @@ -280,12 +283,6 @@ NXphotoemission(NXobject): exists: recommended identifier: exists: recommended - - # ToDo: - # - With base class inheritance this should be - # a field of type NXdata_mpes_detector - # - The field name should be aligned with the `data` field in - # the `NXdetector` base class. But some refinement is necessary there. raw_data(NXdata): exists: recommended doc: | @@ -330,25 +327,69 @@ NXphotoemission(NXobject): exists: optional doc: | Manipulator for positioning of the sample. - sample_temperature(NX_FLOAT): + temperature_sensor(NXsensor): exists: recommended - unit: NX_TEMPERATURE - drain_current(NX_FLOAT): + name: + exists: recommended + measurement: + enumeration: [temperature] + type: + exists: optional + value(NX_FLOAT): + sample_heater(NXactuator): + exists: optional + name: + exists: recommended + physical_quantity: + enumeration: [temperature] + type: + exists: optional + heater_power(NX_FLOAT): + (NXpid): + exists: recommended + setpoint(NX_FLOAT): + exists: recommended + cryostat(NXactuator): + exists: optional + name: + exists: recommended + physical_quantity: + enumeration: [temperature] + type: + exists: optional + (NXpid): + setpoint(NX_FLOAT): + exists: recommended + drain_current_amperemeter(NXsensor): + exists: optional + name: + exists: recommended + measurement: + enumeration: [current] + type: + exists: optional + value(NX_FLOAT): + sample_bias_voltmeter(NXsensor): exists: recommended - unit: NX_CURRENT - sample_bias(NX_FLOAT): + name: + exists: recommended + measurement: + enumeration: [voltage] + type: + exists: optional + value(NX_FLOAT): + sample_bias_potentiostat(NXactuator): exists: recommended - unit: NX_CURRENT - doc: - - | - Bias of the sample with respect to analyser ground. - - | - This field may also be found in NXsample if present. - - | - xref: - spec: ISO 18115-1:2023 - term: 8.41 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 + name: + exists: recommended + physical_quantity: + enumeration: [voltage] + type: + exists: optional + (NXpid): + exists: recommended + setpoint(NX_FLOAT): + exists: recommended device_information(NXfabrication): exists: recommended vendor: @@ -356,7 +397,51 @@ NXphotoemission(NXobject): model: exists: recommended identifier: - exists: recommended + pressure_gauge(NXsensor): + exists: recommended + doc: | + Device to measure the gas pressure around the sample. + name: + exists: recommended + measurement: + enumeration: [pressure] + type: + exists: optional + value(NX_FLOAT): + unit: NX_PRESSURE + doc: | + In case of a single or averaged gas pressure measurement, this is the scalar gas pressure around + the sample. It can also be an 1D array of measured pressures (without time stamps). + value_log(NXlog): + exists: optional + value(NX_NUMBER): + unit: NX_PRESSURE + doc: | + In the case of an experiment in which the gas pressure changes and is recorded, + this is an array of length m of gas pressures. + flood_gun(NXactuator): + exists: optional + doc: | + Device to bring low-energy electrons to the sample for charge neutralization + name: + exists: recommended + physical_quantity: + enumeration: [current] + type: + exists: optional + current(NX_FLOAT): + exists: recommended + unit: NX_CURRENT + doc: | + In case of a fixed or averaged electron current, this is the scalar current. + It can also be an 1D array of output current (without time stamps). + current_log(NXlog): + exists: optional + value(NX_NUMBER): + unit: NX_CURRENT + doc: | + In the case of an experiment in which the electron current is changed and + recorded with time stamps, this is an array of length m of current setpoints. (NXprocess): exists: recommended doc: | @@ -397,13 +482,13 @@ NXphotoemission(NXobject): energy_referencing(NXcalibration): exists: optional doc: - - | + - | For energy referencing, the measured energies are corrected for the charging potential (i.e., the electrical potential of the surface region of an insulating sample, caused by irradiation) such that those energies correspond to a sample with no surface charge. Usually, the energy axis is adjusted by shifting all energies uniformally until one well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. - - | + - | xref: spec: ISO 18115-1:2023 term: 12.74 ff. @@ -420,10 +505,10 @@ NXphotoemission(NXobject): binding_energy(NX_FLOAT): exists: recommended doc: - - | + - | The binding energy (in units of eV) that the specified emission line appeared at, after adjusting the binding energy scale. - - | + - | xref: spec: ISO 18115-1:2023 term: 12.16_ ff. @@ -446,7 +531,7 @@ NXphotoemission(NXobject): kinetic energy is multiplied by the corresponding value in the relative_intensity field of the transmission_function. This calibration procedure is used to account for the different tranmsission efficiencies when using different lens modes. - mapping(NXdata): + transmission_function(NXdata): exists: recommended doc: | Transmission function of the electron analyser. @@ -474,19 +559,15 @@ NXphotoemission(NXobject): dim: [[1, n_transmission_function]] (NXsample): name: - chemical_formula: + (NXsubstance): exists: recommended doc: | - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - sample_history(NXnote): - exists: recommended - doc: | - 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. + For samples containing a single pure substance. For mixtures use the + NXsample_component_set and NXsample_component group in NXsample instead. + molecular_formula_hill: + exists: recommended + doc: | + The chemical formula of the sample (using CIF conventions). atom_types: exists: recommended doc: | @@ -496,44 +577,100 @@ NXphotoemission(NXobject): elements from each component must be included in `atom_types`. physical_form: exists: recommended - preparation_date(NX_DATE_TIME): + situation: + exists: recommended + enumeration: [vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere] + sample_history(NXsample_history): exists: recommended doc: | - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - preparation_description(NXnote): - exists: optional - doc: | - 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. - temperature(NX_FLOAT): - unit: NX_TEMPERATURE + A set of activities that occurred to the sample prior to/during photoemission + experiment. + sample_preparation(NXphysical_process): + exists: recommended + doc: | + Details about the sample preparation for the MPES experiment (e.g. UHV cleaving, + in-situ growth, sputtering/annealing, etc.). + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + exists: recommended + method: + exists: recommended + doc: | + Details about the method of sample preparation before the MPES experiment. + temperature(NXenvironment): exists: recommended doc: | - 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. - situation: + Sample temperature (either controlled or just measured). + temperature_sensor(NXsensor): + doc: | + Temperature sensor measuring the sample temperature. + This should be a link to /entry/instrument/manipulator/temperature_sensor. + sample_heater(NXactuator): + exists: optional + doc: | + Device to heat the sample. + This should be a link to /entry/instrument/manipulator/sample_heater. + cryostat(NXactuator): + exists: optional + doc: | + Cryostat for cooling the sample. + This should be a link to /entry/instrument/manipulator/cryostat. + gas_pressure(NXenvironment): exists: recommended - enumeration: [vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere] - gas_pressure(NX_FLOAT): - unit: NX_PRESSURE + doc: | + Gas pressure surrounding the sample. + pressure_gauge(NXsensor): + doc: | + Gauge measuring the gas pressure. + + This should be a link to /entry/instrument/pressure_gauge. + bias(NXenvironment): exists: recommended - bias(NX_FLOAT): - unit: NX_VOLTAGE + doc: + - | + Bias of the sample with respect to analyser ground. + - | + xref: + spec: ISO 18115-1:2023 + term: 8.41 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 + voltmeter(NXsensor): + doc: | + Sensor measuring the applied voltage. + + This should be a link to /entry/instrument/manipulator/sample_bias_voltmeter. + potentiostat(NXactuator): + exists: optional + doc: | + Actuator applying a voltage to sample and sample holder. + + This should be a link to /entry/instrument/manipulator/sample_bias_potentiostat. + drain_current(NXenvironment): exists: optional doc: | - Voltage applied to sample and sample holder. - (NXdata): + Drain current of the sample and sample holder. + amperemeter(NXsensor): + doc: | + Amperemeter measuring the drain current of the sample and sample holder. + + This should be a link to /entry/instrument/manipulator/drain_current_amperemeter. + flood_gun_current(NXenvironment): + exists: optional + doc: | + Current of low-energy electrons to the sample for charge neutralization. + flood_gun(NXactuator): + doc: | + Flood gun creating a current of low-energy electrons. + + This should be a link to /entry/instrument/flood_gun. + data(NXdata): doc: | - An NXdata field containing a view on the measured data. + The default NXdata field containing a view on the measured data. This NXdata field contains a collection of the main relevant fields (axes). - In NXmpes, it is required to provide an ``energy`` axis (Unit category: NX_ENERGY). - The other data fields ideally should be named according to conventions + In NXmpes, it is required to provide an energy axis. + If you want to provide additional views on your data, you can additionally use + the generic NXdata group of NXentry. + The other data fields inside this NXdata group should be named according to conventions to ensure compatibility. We recommened the following field names for common data fields: @@ -567,6 +704,53 @@ NXphotoemission(NXobject): 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. + energy(NX_NUMBER): + unit: NX_ENERGY + exists: optional + doc: | + Calibrated energy axis. + + This could be a link to either + /entry/process/energy_calibration/calibrated_axis or + /entry/process/energy_correction/calibrated_axis. + \@type: + type: NX_CHAR + doc: | + The energy can be either stored as kinetic or as binding energy. + enumeration: + kinetic: + doc: + - | + Calibrated kinetic energy axis. + - | + In case the kinetic energy axis is referenced to the Fermi level :math:`E_F` + (e.g., in entry/process/energy_referencing), kinetic energies :math:`E` are + provided as :math:`E-E_F`. + - | + xref: + spec: ISO 18115-1:2023 + term: 3.35 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 + binding: + doc: + - | + Calibrated binding energy axis. + - | + xref: + spec: ISO 18115-1:2023 + term: 12.16 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + \@energy_indices: + exists: optional + \@energy_depends: + type: NX_CHAR + exists: optional + doc: | + The energy can be dispersed according to different strategies. ``energy_depends`` points to + the path of a field defining the calibrated axis on which the energy axis depends. + + For example: + @energy_depends: 'entry/process/energy_calibration' # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ # 62c3ef6b393b3fe7b8b4d63da98ea14085f2c995c0cccd81892a2a761adfd4a1 From df3a4b54293a0fd2daa03d06d74513f4fc02ae54 Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 5 Feb 2024 12:55:40 +0100 Subject: [PATCH 0542/1012] Add PEEM to method examples --- contributed_definitions/NXphotoemission.nxdl.xml | 1 + contributed_definitions/nyaml/NXphotoemission.yaml | 1 + 2 files changed, 2 insertions(+) diff --git a/contributed_definitions/NXphotoemission.nxdl.xml b/contributed_definitions/NXphotoemission.nxdl.xml index 2e8640d2d0..b0cfa109b3 100644 --- a/contributed_definitions/NXphotoemission.nxdl.xml +++ b/contributed_definitions/NXphotoemission.nxdl.xml @@ -78,6 +78,7 @@ * angle-resolved photoelectron spectroscopy (ARPES) * hard X-ray photoemission spectroscopy (HAXPES) * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) + * photoelectron emission microscopy (PEEM) * electron spectroscopy for chemical analysis (ESCA) * time-resolved angle-resolved X-ray photoelectron spectroscopy (trARPES) * spin-resolved angle-resolved X-ray photoelectron spectroscopy (spin-ARPES) diff --git a/contributed_definitions/nyaml/NXphotoemission.yaml b/contributed_definitions/nyaml/NXphotoemission.yaml index 777eb3544f..1f5be09116 100644 --- a/contributed_definitions/nyaml/NXphotoemission.yaml +++ b/contributed_definitions/nyaml/NXphotoemission.yaml @@ -46,6 +46,7 @@ NXphotoemission(NXobject): * angle-resolved photoelectron spectroscopy (ARPES) * hard X-ray photoemission spectroscopy (HAXPES) * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) + * photoelectron emission microscopy (PEEM) * electron spectroscopy for chemical analysis (ESCA) * time-resolved angle-resolved X-ray photoelectron spectroscopy (trARPES) * spin-resolved angle-resolved X-ray photoelectron spectroscopy (spin-ARPES) From 8740efff3912dd584a7333f4e2d1cff5936cce0c Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 5 Feb 2024 12:56:22 +0100 Subject: [PATCH 0543/1012] Remove whitespace --- contributed_definitions/NXphotoemission.nxdl.xml | 2 +- contributed_definitions/nyaml/NXphotoemission.yaml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/NXphotoemission.nxdl.xml b/contributed_definitions/NXphotoemission.nxdl.xml index b0cfa109b3..0da9c99102 100644 --- a/contributed_definitions/NXphotoemission.nxdl.xml +++ b/contributed_definitions/NXphotoemission.nxdl.xml @@ -78,7 +78,7 @@ * angle-resolved photoelectron spectroscopy (ARPES) * hard X-ray photoemission spectroscopy (HAXPES) * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) - * photoelectron emission microscopy (PEEM) + * photoelectron emission microscopy (PEEM) * electron spectroscopy for chemical analysis (ESCA) * time-resolved angle-resolved X-ray photoelectron spectroscopy (trARPES) * spin-resolved angle-resolved X-ray photoelectron spectroscopy (spin-ARPES) diff --git a/contributed_definitions/nyaml/NXphotoemission.yaml b/contributed_definitions/nyaml/NXphotoemission.yaml index 1f5be09116..e9c1edda66 100644 --- a/contributed_definitions/nyaml/NXphotoemission.yaml +++ b/contributed_definitions/nyaml/NXphotoemission.yaml @@ -46,7 +46,7 @@ NXphotoemission(NXobject): * angle-resolved photoelectron spectroscopy (ARPES) * hard X-ray photoemission spectroscopy (HAXPES) * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) - * photoelectron emission microscopy (PEEM) + * photoelectron emission microscopy (PEEM) * electron spectroscopy for chemical analysis (ESCA) * time-resolved angle-resolved X-ray photoelectron spectroscopy (trARPES) * spin-resolved angle-resolved X-ray photoelectron spectroscopy (spin-ARPES) From 497c789d7bfecf8a9e735a114593ac3639a61510 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 5 Feb 2024 14:32:23 +0100 Subject: [PATCH 0544/1012] remake NXphotoemission.yaml --- .../nyaml/NXphotoemission.yaml | 423 +++++++++++++----- 1 file changed, 320 insertions(+), 103 deletions(-) diff --git a/contributed_definitions/nyaml/NXphotoemission.yaml b/contributed_definitions/nyaml/NXphotoemission.yaml index e9c1edda66..fbf06c661d 100644 --- a/contributed_definitions/nyaml/NXphotoemission.yaml +++ b/contributed_definitions/nyaml/NXphotoemission.yaml @@ -734,9 +734,9 @@ NXphotoemission(NXobject): url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 binding: doc: - - | + - | Calibrated binding energy axis. - - | + - | xref: spec: ISO 18115-1:2023 term: 12.16 @@ -754,7 +754,7 @@ NXphotoemission(NXobject): @energy_depends: 'entry/process/energy_calibration' # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 62c3ef6b393b3fe7b8b4d63da98ea14085f2c995c0cccd81892a2a761adfd4a1 +# 4eb29a04a3c61de9ffd016783d74d1c20afc5db2be871c9b441a5c03911987b7 # # # # # # A source used to generate a beam. Properties refer strictly to parameters of the # source, not of the output beam. For example, the energy of the source is not the # optical power of the beam, but the energy of the electron beam in a synchrotron -# and so on. +# or similar. # # Note that the uppercase notation in source_TYPE means that multiple sources can # be provided. For example, in pump-probe experiments, it is possible to have both @@ -936,9 +944,6 @@ NXphotoemission(NXobject): # # # -# # # # Properties of the photon beam at a given location. @@ -957,13 +962,14 @@ NXphotoemission(NXobject): # # # -# +# # # The source that emitted this beam. # Should be named with the same appendix, e.g., # for `beam_probe` it should refer to `source_probe`. # Refers to the same concept as /NXentry/NXinstrument/source_TYPE # and may be linked. +# Should be specified if an associated source exists. # # # @@ -974,15 +980,8 @@ NXphotoemission(NXobject): # # # -# -# -# Energy resolution of the analyser with the current setting. May be linked from a -# NXcalibration. -# -# Refers to Term `10.24`_ of the ISO 18115-1:2023 specification. -# -# .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 -# +# +# # # # @@ -990,10 +989,10 @@ NXphotoemission(NXobject): # # # -# +# # # -# +# # # # @@ -1002,6 +1001,7 @@ NXphotoemission(NXobject): # # # +# # # # @@ -1037,7 +1037,7 @@ NXphotoemission(NXobject): # # # -# +# # # # @@ -1049,7 +1049,7 @@ NXphotoemission(NXobject): # # # -# +# # # # Size, position and shape of the entrance slit in dispersive analyzers. @@ -1098,13 +1098,6 @@ NXphotoemission(NXobject): # # # -# # # # Contains the raw data collected by the detector before calibration. @@ -1157,23 +1150,129 @@ NXphotoemission(NXobject): # # Manipulator for positioning of the sample. # -# -# -# -# -# Bias of the sample with respect to analyser ground. -# -# This field may also be found in NXsample if present. -# -# This concept is related to term `8.41`_ of the ISO 18115-1:2023 standard. -# -# .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 -# -# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# # # # -# +# +# +# +# +# +# Device to measure the gas pressure around the sample. +# +# +# +# +# +# +# +# +# +# +# In case of a single or averaged gas pressure measurement, this is the scalar gas pressure around +# the sample. It can also be an 1D array of measured pressures (without time stamps). +# +# +# +# +# +# In the case of an experiment in which the gas pressure changes and is recorded, +# this is an array of length m of gas pressures. +# +# +# +# +# +# +# Device to bring low-energy electrons to the sample for charge neutralization +# +# +# +# +# +# +# +# +# +# +# In case of a fixed or averaged electron current, this is the scalar current. +# It can also be an 1D array of output current (without time stamps). +# +# +# +# +# +# In the case of an experiment in which the electron current is changed and +# recorded with time stamps, this is an array of length m of current setpoints. +# +# # # # @@ -1274,7 +1373,7 @@ NXphotoemission(NXobject): # field of the transmission_function. This calibration procedure is used to account for # the different tranmsission efficiencies when using different lens modes. # -# +# # # Transmission function of the electron analyser. # @@ -1313,20 +1412,16 @@ NXphotoemission(NXobject): # # # -# -# -# The chemical formula of the sample. For mixtures use the NXsample_component -# group in NXsample instead. -# -# -# +# # -# A descriptor to keep track of the treatment of the sample before entering the -# photoemission experiment. Ideally, a full report of the previous operations, in -# any format (NXnote allows to add pictures, audio, movies). Alternatively, a -# reference to the location or a unique identifier or other metadata file. In the -# case these are not available, free-text description. +# For samples containing a single pure substance. For mixtures use the +# NXsample_component_set and NXsample_component group in NXsample instead. # +# +# +# The chemical formula of the sample (using CIF conventions). +# +# # # # @@ -1337,29 +1432,6 @@ NXphotoemission(NXobject): # # # -# -# -# Date of preparation of the sample for the XPS experiment (i.e. cleaving, last -# annealing). -# -# -# -# -# Description of the surface preparation technique for the XPS experiment, i.e. -# UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report -# of the previous operations, in any format(NXnote allows to add pictures, audio, -# movies). Alternatively, a reference to the location or a unique identifier or -# other metadata file. In the case these are not available, free-text description. -# -# -# -# -# In the case of a fixed temperature measurement this is the scalar temperature of -# the sample. In the case of an experiment in which the temperature is changed and -# recoded, this is an array of length m of temperatures. This should be a link to -# /entry/instrument/manipulator/sample_temperature. -# -# # # # @@ -1368,19 +1440,116 @@ NXphotoemission(NXobject): # # # -# -# +# # -# Voltage applied to sample and sample holder. +# A set of activities that occurred to the sample prior to/during photoemission +# experiment. # -# +# +# +# Details about the sample preparation for the MPES experiment (e.g. UHV cleaving, +# in-situ growth, sputtering/annealing, etc.). +# +# +# +# +# +# Details about the method of sample preparation before the MPES experiment. +# +# +# +# +# +# +# Sample temperature (either controlled or just measured). +# +# +# +# Temperature sensor measuring the sample temperature. +# This should be a link to /entry/instrument/manipulator/temperature_sensor. +# +# +# +# +# Device to heat the sample. +# This should be a link to /entry/instrument/manipulator/sample_heater. +# +# +# +# +# Cryostat for cooling the sample. +# This should be a link to /entry/instrument/manipulator/cryostat. +# +# +# +# +# +# Gas pressure surrounding the sample. +# +# +# +# Gauge measuring the gas pressure. +# +# This should be a link to /entry/instrument/pressure_gauge. +# +# +# +# +# +# Bias of the sample with respect to analyser ground. +# +# This concept is related to term `8.41`_ of the ISO 18115-1:2023 standard. +# +# .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 +# +# +# +# Sensor measuring the applied voltage. +# +# This should be a link to /entry/instrument/manipulator/sample_bias_voltmeter. +# +# +# +# +# Actuator applying a voltage to sample and sample holder. +# +# This should be a link to /entry/instrument/manipulator/sample_bias_potentiostat. +# +# +# +# +# +# Drain current of the sample and sample holder. +# +# +# +# Amperemeter measuring the drain current of the sample and sample holder. +# +# This should be a link to /entry/instrument/manipulator/drain_current_amperemeter. +# +# +# +# +# +# Current of low-energy electrons to the sample for charge neutralization. +# +# +# +# Flood gun creating a current of low-energy electrons. +# +# This should be a link to /entry/instrument/flood_gun. +# +# +# # -# +# # -# An NXdata field containing a view on the measured data. +# The default NXdata field containing a view on the measured data. # This NXdata field contains a collection of the main relevant fields (axes). -# In NXmpes, it is required to provide an ``energy`` axis (Unit category: NX_ENERGY). -# The other data fields ideally should be named according to conventions +# In NXmpes, it is required to provide an energy axis. +# If you want to provide additional views on your data, you can additionally use +# the generic NXdata group of NXentry. +# The other data fields inside this NXdata group should be named according to conventions # to ensure compatibility. We recommened the following field names # for common data fields: # @@ -1419,6 +1588,54 @@ NXphotoemission(NXobject): # actual encoder position in NXinstrument or calibrated axes in NXprocess. # # +# +# +# Calibrated energy axis. +# +# This could be a link to either +# /entry/process/energy_calibration/calibrated_axis or +# /entry/process/energy_correction/calibrated_axis. +# +# +# +# The energy can be either stored as kinetic or as binding energy. +# +# +# +# +# Calibrated kinetic energy axis. +# +# In case the kinetic energy axis is referenced to the Fermi level :math:`E_F` +# (e.g., in entry/process/energy_referencing), kinetic energies :math:`E` are +# provided as :math:`E-E_F`. +# +# This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. +# +# .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 +# +# +# +# +# Calibrated binding energy axis. +# +# This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. +# +# .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 +# +# +# +# +# +# +# +# +# The energy can be dispersed according to different strategies. ``energy_depends`` points to +# the path of a field defining the calibrated axis on which the energy axis depends. +# +# For example: +# @energy_depends: 'entry/process/energy_calibration' +# +# # # # From 72b2909dbe2c9b810e4a4b26c74faaa169531fcf Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 5 Feb 2024 16:38:58 +0100 Subject: [PATCH 0545/1012] Add definition back to NXmpes --- contributed_definitions/NXmpes.nxdl.xml | 5 +++++ contributed_definitions/nyaml/NXmpes.yaml | 2 ++ 2 files changed, 7 insertions(+) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 28dd988588..b46958e5c7 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -33,6 +33,11 @@ .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 + + + + + diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index faa07c75df..9f129eef37 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -11,6 +11,8 @@ doc: | type: group NXmpes(NXphotoemission): (NXentry): + definition: + enumeration: [NXmpes] (NXinstrument): energy_resolution(NXresolution): exists: recommended From 310454edf4716ff78a28adccff3c5551d9f0396b Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 5 Feb 2024 16:55:32 +0100 Subject: [PATCH 0546/1012] Remove energy resolutions from NXphotoemission --- contributed_definitions/NXmpes.nxdl.xml | 82 +++++++++++++++++-- .../NXphotoemission.nxdl.xml | 77 ----------------- contributed_definitions/nyaml/NXmpes.yaml | 72 +++++++++++++++- .../nyaml/NXphotoemission.yaml | 75 ----------------- 4 files changed, 146 insertions(+), 160 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index b46958e5c7..675fca1b2d 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -39,18 +39,90 @@ - + + + Overall energy resolution of the MPES instrument + + This concept is related to term `10.7 ff.`_ of the ISO 18115-1:2023 standard. + + .. _10.7 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 + + This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. + + .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 + + + + + + + + + - + + + + + + + + + - - - + + + Calibrated energy axis. + + This could be a link to either + /entry/process/energy_calibration/calibrated_axis or + /entry/process/energy_correction/calibrated_axis. + + + + The energy can be either stored as kinetic or as binding energy. + + + + + Calibrated kinetic energy axis. + + In case the kinetic energy axis is referenced to the Fermi level :math:`E_F` + (e.g., in entry/process/energy_referencing), kinetic energies :math:`E` are + provided as :math:`E-E_F`. + + This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. + + .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 + + + + + Calibrated binding energy axis. + + This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. + + .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + + + + + + + + + The energy can be dispersed according to different strategies. ``energy_depends`` points to + the path of a field defining the calibrated axis on which the energy axis depends. + + For example: + @energy_depends: 'entry/process/energy_calibration' + + diff --git a/contributed_definitions/NXphotoemission.nxdl.xml b/contributed_definitions/NXphotoemission.nxdl.xml index 0da9c99102..5f017e547d 100644 --- a/contributed_definitions/NXphotoemission.nxdl.xml +++ b/contributed_definitions/NXphotoemission.nxdl.xml @@ -113,26 +113,6 @@ .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 - - - Overall energy resolution of the MPES instrument - - This concept is related to term `10.7 ff.`_ of the ISO 18115-1:2023 standard. - - .. _10.7 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 - - This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. - - .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 - - - - - - - - - @@ -224,15 +204,6 @@ - - - - - - - - - @@ -831,54 +802,6 @@ actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - Calibrated energy axis. - - This could be a link to either - /entry/process/energy_calibration/calibrated_axis or - /entry/process/energy_correction/calibrated_axis. - - - - The energy can be either stored as kinetic or as binding energy. - - - - - Calibrated kinetic energy axis. - - In case the kinetic energy axis is referenced to the Fermi level :math:`E_F` - (e.g., in entry/process/energy_referencing), kinetic energies :math:`E` are - provided as :math:`E-E_F`. - - This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. - - .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 - - - - - Calibrated binding energy axis. - - This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. - - .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - - - - - - - - - The energy can be dispersed according to different strategies. ``energy_depends`` points to - the path of a field defining the calibrated axis on which the energy axis depends. - - For example: - @energy_depends: 'entry/process/energy_calibration' - - diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 9f129eef37..8a2403b185 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -15,19 +15,85 @@ NXmpes(NXphotoemission): enumeration: [NXmpes] (NXinstrument): energy_resolution(NXresolution): - exists: recommended + exists: optional + doc: + - | + Overall energy resolution of the MPES instrument + - | + xref: + spec: ISO 18115-1:2023 + term: 10.7 ff. + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 + - | + xref: + spec: ISO 18115-1:2023 + term: 10.24 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 + physical_quantity: + enumeration: [energy] + type: + exists: recommended + resolution(NX_FLOAT): + unit: NX_ENERGY (NXelectronanalyser): energy_resolution(NXresolution): exists: recommended + type: + exists: recommended + physical_quantity: + enumeration: [energy] + resolution(NX_FLOAT): (NXprocess): energy_calibration(NXcalibration): exists: recommended data(NXdata): energy(NX_NUMBER): + unit: NX_ENERGY + exists: optional + doc: | + Calibrated energy axis. + + This could be a link to either + /entry/process/energy_calibration/calibrated_axis or + /entry/process/energy_correction/calibrated_axis. + \@type: + type: NX_CHAR + doc: | + The energy can be either stored as kinetic or as binding energy. + enumeration: + kinetic: + doc: + - | + Calibrated kinetic energy axis. + - | + In case the kinetic energy axis is referenced to the Fermi level :math:`E_F` + (e.g., in entry/process/energy_referencing), kinetic energies :math:`E` are + provided as :math:`E-E_F`. + - | + xref: + spec: ISO 18115-1:2023 + term: 3.35 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 + binding: + doc: + - | + Calibrated binding energy axis. + - | + xref: + spec: ISO 18115-1:2023 + term: 12.16 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 \@energy_indices: - exists: recommended + exists: optional \@energy_depends: - exists: recommended + type: NX_CHAR + exists: optional + doc: | + The energy can be dispersed according to different strategies. ``energy_depends`` points to + the path of a field defining the calibrated axis on which the energy axis depends. + + For example: + @energy_depends: 'entry/process/energy_calibration' # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ # 0858e4c498e1d031bbe35e761fdbb30b8db75d6725f7b39b320d53a90ec23587 diff --git a/contributed_definitions/nyaml/NXphotoemission.yaml b/contributed_definitions/nyaml/NXphotoemission.yaml index fbf06c661d..de6b69e2d5 100644 --- a/contributed_definitions/nyaml/NXphotoemission.yaml +++ b/contributed_definitions/nyaml/NXphotoemission.yaml @@ -75,27 +75,6 @@ NXphotoemission(NXobject): spec: ISO 18115-1:2023 term: 12.58 url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 - energy_resolution(NXresolution): - exists: optional - doc: - - | - Overall energy resolution of the MPES instrument - - | - xref: - spec: ISO 18115-1:2023 - term: 10.7 ff. - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 - - | - xref: - spec: ISO 18115-1:2023 - term: 10.24 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 - physical_quantity: - enumeration: [energy] - type: - exists: recommended - resolution(NX_FLOAT): - unit: NX_ENERGY device_information(NXfabrication): exists: recommended vendor: @@ -185,13 +164,6 @@ NXphotoemission(NXobject): work_function(NX_FLOAT): unit: NX_ENERGY exists: recommended - energy_resolution(NXresolution): - exists: optional - type: - exists: recommended - physical_quantity: - enumeration: [energy] - resolution(NX_FLOAT): fast_axes: exists: recommended slow_axes: @@ -705,53 +677,6 @@ NXphotoemission(NXobject): 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. - energy(NX_NUMBER): - unit: NX_ENERGY - exists: optional - doc: | - Calibrated energy axis. - - This could be a link to either - /entry/process/energy_calibration/calibrated_axis or - /entry/process/energy_correction/calibrated_axis. - \@type: - type: NX_CHAR - doc: | - The energy can be either stored as kinetic or as binding energy. - enumeration: - kinetic: - doc: - - | - Calibrated kinetic energy axis. - - | - In case the kinetic energy axis is referenced to the Fermi level :math:`E_F` - (e.g., in entry/process/energy_referencing), kinetic energies :math:`E` are - provided as :math:`E-E_F`. - - | - xref: - spec: ISO 18115-1:2023 - term: 3.35 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 - binding: - doc: - - | - Calibrated binding energy axis. - - | - xref: - spec: ISO 18115-1:2023 - term: 12.16 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - \@energy_indices: - exists: optional - \@energy_depends: - type: NX_CHAR - exists: optional - doc: | - The energy can be dispersed according to different strategies. ``energy_depends`` points to - the path of a field defining the calibrated axis on which the energy axis depends. - - For example: - @energy_depends: 'entry/process/energy_calibration' # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ # 4eb29a04a3c61de9ffd016783d74d1c20afc5db2be871c9b441a5c03911987b7 From c867566d11b6ace45fc8b92add0523ca320c0961 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 9 Feb 2024 09:37:03 +0100 Subject: [PATCH 0547/1012] rename lens_mode according to base class --- contributed_definitions/NXmpes.nxdl.xml | 2 +- contributed_definitions/nyaml/NXmpes.yaml | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index e69adde991..c5f5a45ef3 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -248,7 +248,7 @@ - + diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 540b658474..8636d08e62 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -203,7 +203,7 @@ NXmpes(NXobject): doc: | Scheme of the electron collection column. enumeration: [angular dispersive, spatial dispersive, momentum dispersive, non-dispersive] - mode: + lens_mode: exists: recommended projection: exists: recommended @@ -753,7 +753,7 @@ NXmpes(NXobject): @energy_depends: 'entry/process/energy_calibration' # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 0858e4c498e1d031bbe35e761fdbb30b8db75d6725f7b39b320d53a90ec23587 +# a126a001ba56386d0e4cb7731e73e48921961202950cf53ecc142cc30fa79728 # # # + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Maximum number of atoms per molecular ion. Should be 32 for paraprobe. + + + + + Number of different source iontypes to distinguish. + + + + + Number of different target iontypes to distinguish. + + + + + Application definition for a configuration file of the paraprobe-spatstat tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + + + + + + + + + + + How many spatial_statistics tasks should the tool execute. + + + + + + + + + + + + + + + + + + + + + + + Distance between each ion and triangulated surface mesh. + + + + + + + + + Threshold to define how far an ion has to lay at least from the edge + of the dataset so that the ion can act as a source. This means that + an ROI is placed at the location of the ion and its neighbors are + analyzed how they contribute to the computed statistics. + + The edge_distance threshold can be combined with the feature_distance threshold. This threshold defines defines up to which distance to a + microstructural feature an ROI is placed. + + The threshold is useful to process the dataset such that ROIs do + not protrude out of the dataset as this would add bias. + + + + + + Distance between each ion and triangulated mesh of microstructural features. + In addition to spatial filtering and considering how far ions lie to the + edge of the dataset, it is possible to restrict the analyses to a sub-set of + ions within a distance not farther away to a feature than the feature_distance + threshold value. + + + + + + + + Absolute path in the (HDF5) file which points to the distance of each + ion to the closest feature. + + + + + Threshold to define how close an ion has to lay to a feature so that + the ion can at all qualify as a source, i.e. that an ROI is placed + at the location of the ion and its neighbors are then analyzed + how they contribute to the computed statistics. + + Recall that this feature_distance threshold is used in combination + with the edge_distance threshold when placing ROI about source ions. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specifies, if the iontypes are randomized for the point cloud or not. + Internally, paraprobe uses a sequentially executed deterministic MT19987 + (MersenneTwister) pseudo-random number generator to shuffle the + iontypes randomly across the entire set of ions. That is the total + number of ions of either type remain the same but the information about + their location is randomized. + + + + + + + + + + How should the iontype be interpreted on the source-side, i.e. + all these ion positions where a regions-of-interest (ROI) around + so-called source ions will be placed. Different options exist + how iontypes are interpreted given an iontype represents + in general a (molecular) ion with different isotopes that have + individually different multiplicity. + + The value resolve_all will set an ion active in the analysis regardless + of which iontype it is. Each active ion is accounted for once. + + The value resolve_unknown will set an ion active when the ion is + of the UNKNOWNTYPE type. Each active ion is accounted for once. + + The value resolve_ion will set an ion active if it is of the specific + iontype, irregardless of its elemental or isotopic details. + Each active ion is counted once. + + The value resolve_element will set an ion active, and most importantly, + account for each as many times as the (molecular) ion contains + atoms of elements in the whitelist ion_query_isotope_vector. + + The value resolve_isotope will set an ion active, and most importantly, + account for each as many times as the (molecular) ion contains + isotopes in the whitelist ion_query_isotope_vector. + + In effect, ion_query_isotope_vector acts as a whitelist to filter + which ions are considered as source ions of the correlation statistics + and how the multiplicity of each ion will be factorized, i.e. how + often it is accounted for. + + + + + + + + + + + + Matrix of isotope vectors, as many as rows as different candidates + for iontypes should be distinguished as possible source iontypes. + In the simplest case, the matrix contains only the proton number + of the element in the row, all other values set to zero. + Combined with ion_query_type_source set to resolve_element this will + recover usual spatial correlation statistics like the 1NN C-C + spatial statistics. + + + + + + + + + Similarly as ion_query_type_source how should iontypes be interpreted + on the target-side, i.e. how many counts will be bookkept for ions + which are neighbors of source ions within or on the surface of each + inspection/ROI about each source ion. + Source ion in the center of the ROI are not accounted for during + counting the summary statistics. + For details about the resolve values consider the explanations in + ion_query_type_source. These account for ion_query_type_target as well. + + + + + + + + + + + + + Matrix of isotope vectors, as many as rows as different candidates for + iontypes to distinguish as possible targets. See additional comments + under ion_query_isotope_vector_source. + + + + + + + + + Specifies which spatial statistics to compute. + + + + Compute k-th nearest neighbour statistics. + + + + Order k. + + + + + Minimum value, increment, and maximum value of the histogram binning. + + + + + + + + + Compute radial distribution function. + + + + Minimum value, increment, and maximum value of the histogram binning. + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml index 874d78f1a2..3ab78bab32 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml @@ -217,24 +217,24 @@ NXapm_paraprobe_spatstat_config(NXobject): doc: | Specifies which spatial statistics to compute. knn(NXprocess): - exists: optional + exists: [min, 0, max, 1] doc: | Compute k-th nearest neighbour statistics. kth(NX_UINT): doc: | Order k. unit: NX_UNITLESS - histogram_min_incr_max(NX_FLOAT): + min_incr_max(NX_FLOAT): doc: | Minimum value, increment, and maximum value of the histogram binning. unit: NX_LENGTH # \@units: nm dim: (3,) rdf(NXprocess): - exists: optional + exists: [min, 0, max, 1] doc: | Compute radial distribution function. - histogram_min_incr_max(NX_FLOAT): + min_incr_max(NX_FLOAT): doc: | Minimum value, increment, and maximum value of the histogram binning. unit: NX_LENGTH From 5291ffe2e3e0dbbf47686c98fa47073cadfd4f5b Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Sat, 10 Feb 2024 19:47:01 +0100 Subject: [PATCH 0551/1012] Refactored paraprobe-clusterer definitions to use APM v2 --- .../NXapm_paraprobe_clusterer_config.nxdl.xml | 390 +++++++ ...NXapm_paraprobe_clusterer_results.nxdl.xml | 280 +++++ .../NXapm_paraprobe_config_clusterer.nxdl.xml | 477 --------- ...NXapm_paraprobe_results_clusterer.nxdl.xml | 503 --------- .../NXapm_paraprobe_clusterer_config.yaml | 299 ++++++ .../NXapm_paraprobe_clusterer_results.yaml | 192 ++++ .../NXapm_paraprobe_config_clusterer.yaml | 860 ---------------- .../NXapm_paraprobe_results_clusterer.yaml | 960 ------------------ 8 files changed, 1161 insertions(+), 2800 deletions(-) create mode 100644 contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml create mode 100644 contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml delete mode 100644 contributed_definitions/NXapm_paraprobe_results_clusterer.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.yaml delete mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.yaml diff --git a/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml new file mode 100644 index 0000000000..d4703601d7 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml @@ -0,0 +1,390 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + + Maximum number of atoms per molecular ion. Should be 32 for paraprobe. + + + + + Number of clustering algorithms used. + + + + + Number of different iontypes to distinguish during clustering. + + + + + Application definition for a configuration file of the paraprobe-clusterer tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + + + + + + + + + + + How many cluster_analysis tasks should the tool execute. + + + + + This process maps results from a cluster analysis made with IVAS / AP Suite + into an interoperable representation. IVAS / AP Suite usually exports such results + as a list of reconstructed ion positions with one cluster label per position. + These labels are reported via the mass-to-charge-state-ratio column of what is effectively + a binary file that is formatted like a POS file but cluster labels written out using floating + point numbers. + + + + + + + + + + + + File with the results of the cluster analyses that was computed with IVAS / AP suite + (e.g. maximum-separation method clustering algorithm `J. Hyde et al. <https://doi.org/10.1557/PROC-650-R6.6>`_). + The information is stored in an improper (.indexed.) POS file as a matrix of floating + point quadruplets, one quadruplet for each ion. The first three values of each + quadruplet encode the position of the ion. The fourth value is the integer identifier + of the cluster encoded as a floating point number. + + + + + + + + + Specifies if paraprobe-clusterer should use the evaporation_ids from reconstruction + for recovering for each position in the :ref:`NXserialized` results the closest matching position + (within floating point accuracy). This can be useful when users wish to recover the + original evaporation_id, which IVAS /AP Suite drops when writing their *.indexed.* cluster + results POS files that is referred to results. + + + + + + + + + + + + + + + + + This process performs a cluster analysis on a + reconstructed dataset or a ROI within it. + + + + + + + + + + + + + + + + + + + Distance between each ion and triangulated surface mesh. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + How should iontypes be considered during the cluster analysis. + + The value resolve_all will set an ion active + in the analysis regardless of which iontype it is. + + The value resolve_unknown will set an ion active + when it is of the UNKNOWNTYPE. + + The value resolve_ion will set an ion active + if it is of the specific iontype, irregardless of its nuclide structure. + + The value resolve_element will set an ion active and account as many times + for it, as the (molecular) ion contains atoms of elements in the whitelist + ion_query_nuclide_vector. + + The value resolve_isotope will set an ion active and account as many times + for it, as the (molecular) ion contains nuclides in the whitelist + ion_query_nuclide_vector. + + In effect, ion_query_nuclide_vector acts as a whitelist to filter which ions are + considered as source ions of the correlation statistics and how the multiplicity + of each ion will be factorized. + + This is relevant as in atom probe we have the situation that an ion of a molecular + ion with more than one nuclide, say Ti O for example is counted potentially several + times because at that position (reconstructed) position it has been assumed that + there was a Ti and an O atom. This multiplicity affects the size of the feature and its + chemical composition. + + + + + + + + + Matrix of nuclide vectors, as many as rows as different candidates + for iontypes should be distinguished as possible source iontypes. + In the simplest case, the matrix contains only the proton number + of the element in the row, all other values set to zero. + + + + + + + + + + Settings for DBScan clustering algorithm. For original details about the + algorithm and (performance-relevant) details consider: + + * `M. Ester et al. <https://dx.doi.org/10.5555/3001460.3001507>`_ + * `M. Götz et al. <https://dx.doi.org/10.1145/2834892.2834894>`_ + + For details about how the DBScan algorithms is the key behind the + specific modification known as the maximum-separation method in the + atom probe community consider `E. Jägle et al. <https://dx.doi.org/10.1017/S1431927614013294>`_ + + + + Strategy how a set of cluster analyses with different parameter is executed: + + * For tuple as many runs are performed as parameter values have been defined. + * For combinatorics individual parameter arrays are looped over. + + As an example we may provide ten entries for eps and three entries for min_pts. + If high_throughput_method is set to tuple, the analysis is invalid because we have + an insufficient number of min_pts values to pair them with our ten eps values. + By contrast, if high_throughput_method is set to combinatorics, the tool will run three + individual min_pts runs for each eps value, resulting in a total of 30 analyses. + + A typical example from the literature `M. Kühbach et al. <https://dx.doi.org/10.1038/s41524-020-00486-1>`_ + can be instructed via setting eps to an array of values np.linspace(0.2, 5.0, nums=241, endpoint=True), + one min_pts value that is equal to 1, and high_throughput_method set to combinatorics. + + + + + + + + + Array of epsilon (eps) parameter values. + + + + + + + + Array of minimum points (min_pts) parameter values. + + + + + + + + + + Settings for the HPDBScan clustering algorithm. + + * L. McInnes et al. <https://dx.doi.org/10.21105/joss.00205>`_ + * scikit-learn hdbscan library `<https://hdbscan.readthedocs.io/en/latest/how_hdbscan_works.html>`_ + + See also this documentation for details about the parameter. + Here we use the terminology of the hdbscan documentation. + + + + Strategy how runs with different parameter values are composed, + following the explanation for higih_throughput_method of dbscan. + + + + + + + + + Array of min_cluster_size parameter values. + + + + + + + + Array of min_samples parameter values. + + + + + + + + Array of cluster_selection parameter values. + + + + + + + + Array of alpha parameter values. + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml new file mode 100644 index 0000000000..10222f152c --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml @@ -0,0 +1,280 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + Number of clusters found. + + + + + Application definition for results files of the paraprobe-spatstat tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + + + + + + + + + + + + + + + + + + + + + + + + + + + Results of a DBScan clustering analysis. + + + + The epsilon (eps) parameter used. + + + + + The minimum points (min_pts) parameter used. + + + + + Number of members in the set which is partitioned into features. + Specifically, this is the total number of targets filtered from the + dataset, i.e. typically the number of clusters which is usually not and + for sure not necessarily the total number of ions in the dataset. + + + + + Which identifier is the first to be used to label a cluster. + + The value should be chosen in such a way that special values can be resolved: + * identifier_offset - 1 indicates an object belongs to no cluster. + * identifier_offset - 2 indicates an object belongs to the noise category. + + Setting for instance identifier_offset to 1 recovers the commonly used + case that objects of the noise category get the value of -1 and points of the + unassigned category get the value 0. + + + + + The evaporation (sequence) identifier (aka evaporation_id) to figure out + which ions from the reconstruction were considered targets. The length + of this array is not necessarily n_ions. + Instead, it is the value of cardinality. + + + + + + + + + The number of solutions found for each target. Typically, + this value is 1 in which case the field can be omitted. + Otherwise, this array is the concatenated set of values of solution + tuples for each target that can be used to decode model_labels, + core_sample_indices, and weight. + + + + + + + + The raw labels from the DBScan clustering backend process. + The length of this array is not necessarily n_ions. + Instead, it is typically the value of cardinality provided that each + target has only one associated cluster. If targets are assigned to + multiple cluster this array is as long as the total number of solutions + found and + + + + + + + + The raw array of core sample indices which specify which of the + targets are core points. + + + + + + + + Numerical label for each target (member in the set) aka cluster identifier. + + + + + + + + Categorical label(s) for each target (member in the set) aka cluster name(s). + + + + + + + + Weights for each target that specifies how probable the target is assigned to + a specific cluster. + + For the DBScan algorithm and atom probe tomography this value is the + multiplicity of each ion with respect to the cluster. That is how many times + should the position of the ion be accounted for because the ion is e.g. a + molecular ion with several elements or nuclides of requested type. + + + + + + + + + Are targets assigned to the noise category or not. + + + + + + + + + Are targets assumed a core point. + + + + + + + + In addition to the detailed storage which members were grouped to which + feature here summary statistics are stored that communicate e.g. how many + cluster were found. + + + + + Total number of targets in the set, i.e. ions that were filtered + and considered in this cluster analysis. + + + + + Total number of members in the set which are categorized as noise. + + + + + Total number of members in the set which are categorized as a core point. + + + + + Total number of clusters (excluding noise and unassigned). + + + + + + Numerical identifier of each feature aka cluster_identifier. + + + + + + + + Number of members for each feature. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml deleted file mode 100644 index c1a766d5a3..0000000000 --- a/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml +++ /dev/null @@ -1,477 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - - Maximum number of atoms per molecular ion. Should be 32 for paraprobe. - - - - - Number of clustering algorithms used. - - - - - Number of different iontypes to distinguish during clustering. - - - - - Configuration of a paraprobe-clusterer tool run in atom probe microscopy. - - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - How many tasks to perform? - - - - - This process maps results from cluster analyses performed with IVAS/APSuite - into an interoperable representation. Specifically in this process - paraprobe-clusterer takes results from clustering methods from other tools - of the APM community, like IVAS/APSuite. These results are usually reported - in two ways. Either as an explicit list of reconstructed ion positions. - In the case of IVAS these positions are reported through a text file - with a cluster label for each position. - - Alternatively, the list of positions is reported, as it is the case for - AMETEK (IVAS/AP Suite) but the cluster labels are specified implicitly - only in the following way: The mass-to-charge-state ratio column of a - what is effectively a file formatted like POS is used to assign a hypothetical - mass-to-charge value which resolves a floating point representation - of the cluster ID. - - Another case can occur where all disjoint floating point values, - i.e. here cluster labels, are reported and then a dictionary is created - how each value matches to a cluster ID. - - In general the cluster ID zero is reserved for marking the dataset - as to not be assigned to any cluster. Therefore, indices of disjoint - clusters start at 1. - - - - - - - - - AMETEK/Cameca results of cluster analyses, like with the maximum- - separation (MS) method clustering algorithm `J. Hyde et al. <https://doi.org/10.1557/PROC-650-R6.6>`_ - are stored as an improper POS file: This is a matrix of floating - point quadruplets, one for each ion and as many quadruplets as - ions were investigated. The first three values encode the position - of the ion. The fourth value is an improper mass-to-charge-state-ratio - value which encodes the integer identifier of the cluster as a floating - point number. - - - - - - - Specifies if the tool should try to recover for each position the closest - matching position from dataset/dataset_name_reconstruction (within - floating point accuracy). This can be useful for instance when users - wish to recover the original evaporation ID, which IVAS/AP Suite drops - for instance when writing their *.indexed.* cluster results POS files. - - - - - - - This process performs a cluster analysis on a reconstructed dataset - or a portion of the reconstruction. - - - - - - - - - - - - - - - - - The tool enables to inject precomputed distance information for each - point/ion which can be used for further post-processing and analysis. - - - - Name of an HDF5 file which contains the ion distances. - - - - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - - - - - - Absolute HDF5 path to the dataset with distance values for each ion. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - How should iontypes be interpreted/considered during the cluster analysis. - Different options exist how iontypes are interpreted (if considered at all) - given an iontype represents in general a (molecular) ion with different isotopes - that have individually different multiplicity. - - The value resolve_all will set an ion active in the analysis - regardless of which iontype it is. - The value resolve_unknown will set an ion active when it is of the - UNKNOWNTYPE. - The value resolve_ion will set an ion active if it is of the - specific iontype, irregardless of its elemental or isotopic details. - The value resolve_element will set an ion active, and most importantly, - account as many times for it, as the (molecular) ion contains - atoms of elements in the whitelist ion_query_isotope_vector. - The value resolve_isotope will set an ion active, and most importantly, - account as many times for it, as the (molecular) ion contains isotopes - in the whitelist ion_query_isotope_vector. - - In effect, ion_query_isotope_vector acts as a whitelist to filter - which ions are considered as source ions of the correlation statistics - and how the multiplicity of each ion will be factorized. - - This is relevant as in atom probe we have the situation that a ion - of a molecular ion with more than one nuclid, say Ti O for example - is counted such that although there is a single TiO molecular ion - at a position that the cluster has two members. This multiplicity - affects the size of the feature and chemical composition. - - - - - - - - - Matrix of isotope vectors, as many as rows as different candidates - for iontypes should be distinguished as possible source iontypes. - In the simplest case, the matrix contains only the proton number - of the element in the row, all other values set to zero. - Combined with ion_query_type_source set to resolve_element this will - recover usual spatial correlation statistics like the 1NN C-C - spatial statistics. - - - - - - - - - Settings for DBScan clustering algorithm. For original details about the - algorithms and (performance-relevant) details consider: - - * `M. Ester et al. <https://dx.doi.org/10.5555/3001460.3001507>`_ - * `M. Götz et al. <https://dx.doi.org/10.1145/2834892.2834894>`_ - - For details about how the DBScan algorithms is the key behind the - specific modification known as the maximum-separation method in the - atom probe community consider `E. Jägle et al. <https://dx.doi.org/10.1017/S1431927614013294>`_ - - - - Strategy how runs are performed with different parameter: - - * For tuple as many runs are performed as parameter values. - * For combinatorics individual parameter arrays are looped over. - - As an example we may define eps with ten entries and min_pts with - three entries. If high_throughput_method is tuple the analysis is - invalid as we have an insufficient number of min_pts for the ten - eps values. - By contrast, for combinatorics paraprobe-clusterer will run three - individual min_pts runs for each eps value, resulting in a total - of 30 analyses. - As an example the DBScan analysis reported in `M. Kühbach et al. <https://dx.doi.org/10.1038/s41524-020-00486-1>`_ - would have defined an array of values np.linspace(0.2, 5.0, nums=241, endpoint=True) - eps values, min_pts one, and high_throughput_method set to combinatorics. - - - - - - - - - Array of epsilon (eps) parameter values. - - - - - - - - Array of minimum points (min_pts) parameter values. - - - - - - - - - - Settings for the OPTICS clustering algorithm. - - * `M. Ankerest et al. <https://dx.doi.org/10.1145/304181.304187>`_ - - - - Strategy how runs are performed with different parameter: - - * For tuple as many runs are performed as parameter values. - * For combinatorics individual parameter arrays are looped over. - - See the explanation for the corresponding parameter for dbscan - processes above-mentioned for further details. - - - - - - - - - Array of minimum points (min_pts) parameter values. - - - - - - - - Array of maximum epsilon (eps) parameter values. - - - - - - - - - Settings for the HPDBScan clustering algorithm. - - * L. McInnes et al. <https://dx.doi.org/10.21105/joss.00205>`_ - * scikit-learn hdbscan library `<https://hdbscan.readthedocs.io/en/latest/how_hdbscan_works.html>`_ - - See also this documentation for details about the parameter. - Here we use the terminology of the hdbscan documentation. - - - - Strategy how runs are performed with different parameter: - - * For tuple as many runs are performed as parameter values. - * For combinatorics individual parameter arrays are looped over. - - See the explanation for the corresponding parameter for dbscan - processes above-mentioned for further details. - - - - - - - - - Array of min_cluster_size parameter values. - - - - - - - - Array of min_samples parameter values. - - - - - - - - Array of cluster_selection parameter values. - - - - - - - - Array of alpha parameter values. - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_results_clusterer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_clusterer.nxdl.xml deleted file mode 100644 index 74b8a6133d..0000000000 --- a/contributed_definitions/NXapm_paraprobe_results_clusterer.nxdl.xml +++ /dev/null @@ -1,503 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of ions in the reconstruction. - - - - - The total number of entries in the restricted_identifier dictionary. - - - - - Results of a paraprobe-clusterer tool run. - - - - - - Version specifier of this application definition. - - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - - - - - The absolute path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must no longer compute analyses. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases, it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - If nothing else is specified we assume that there - has to be at least one set of NXtransformations named - paraprobe defined, which specifies the coordinate system. - In which all positions are defined. - - - - - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - - A bitmask which identifies which of the ions in the dataset were - analyzed during this process. - - - - Number of ions covered by the mask. - The mask value for most may be 0. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used, padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe-toolbox executable. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth (padding). - - - - - - - - - The result of a cluster analyses. These include typically the label for - each ion/point documenting to which feature (if any) an ion is assigned. - Typically, each analysis/run yields only a single cluster. - In cases of fuzzy clustering it can be possible that an ion is assigned - to multiple cluster (eventually with different) weight/probability. - - - - Results of a DBScan clustering analysis. - - - - The epsilon (eps) parameter. - - - - - The minimum points (min_pts) parameter. - - - - - Number of members in the set which is partitioned into features. - Specifically, this is the total number of targets filtered from the - dataset. Cardinality here is not the total number of ions in the - dataset. - - - - - - Which identifier is the first to be used to label a cluster. - - The value should be chosen in such a way that special values can be resolved: - * identifier_offset-1 indicates an object belongs to no cluster. - * identifier_offset-2 indicates an object belongs to the noise category. - Setting for instance identifier_offset to 1 recovers the commonly used - case that objects of the noise category get values to -1 and unassigned points to 0. - Numerical identifier have to be strictly increasing. - - - - - - The evaporation sequence identifier to figure out which ions - from the reconstruction were considered targets. - - - - - - - - - The raw labels from the DBScan clustering backend process. - - - - - - - - The raw array of core sample indices which specify which of the - targets are core points. - - - - - - - - - Matrix of numerical label for each member in the set. - For classical clustering algorithms this can for instance - encode the cluster_identifier. - - - - - - - - - The array of weight which specifies how surely/likely the - cluster is associated/assigned to a specific identifier as - is specified in the cluster_identifier array. - For the DBScan and atom probe tomography the multiplicity - of each ion with respect to the cluster. That is how many times - should the position of the ion be accounted for because the ion - is e.g. a molecular ion with several elements or isotope of - requested type. - - - - - - - - Optional bitmask encoding if members of the set are assigned to as noise or not. - - - - - - - - Optional bitmask encoding if member of the set are a core point. - For details to which feature/cluster an ion/point is a core point - consider numerical_label. - - - - - - - - In addition to the detailed storage which members was grouped to - which feature/group summary statistics are stored under this group. - - - - - Total number of members in the set which are categorized as noise. - - - - - - Total number of members in the set which are categorized as a core point. - - - - - - Total number of clusters (excluding noise and unassigned). - - - - - Array of numerical identifier of each feature (cluster). - - - - - - - - Array of number of members for each feature. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml new file mode 100644 index 0000000000..a065f8c8cf --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml @@ -0,0 +1,299 @@ +category: application +doc: | + Application definition for a configuration file of the paraprobe-clusterer tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + # n_positions: Number of position values. + # n_disjoint_clusters: Number of disjoint cluster. + n_ivec_max: | + Maximum number of atoms per molecular ion. Should be 32 for paraprobe. + n_clust_algos: | + Number of clustering algorithms used. + n_ions: | + Number of different iontypes to distinguish during clustering. +type: group +NXapm_paraprobe_clusterer_config(NXobject): + (NXentry): + exists: [min, 1, max, 1] + definition(NX_CHAR): + \@version(NX_CHAR): + enumeration: [NXapm_paraprobe_spatstat_config] + number_of_tasks(NX_UINT): + doc: | + How many cluster_analysis tasks should the tool execute. + unit: NX_UNITLESS + cameca_to_nexus(NXapm_paraprobe_tool_config): + exists: [min, 0, max, 1] + doc: | + This process maps results from a cluster analysis made with IVAS / AP Suite + into an interoperable representation. IVAS / AP Suite usually exports such results + as a list of reconstructed ion positions with one cluster label per position. + These labels are reported via the mass-to-charge-state-ratio column of what is effectively + a binary file that is formatted like a POS file but cluster labels written out using floating + point numbers. + reconstruction(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + position(NX_CHAR): + mass_to_charge(NX_CHAR): + results(NXserialized): + doc: | + File with the results of the cluster analyses that was computed with IVAS / AP suite + (e.g. maximum-separation method clustering algorithm `J. Hyde et al. `_). + The information is stored in an improper (.indexed.) POS file as a matrix of floating + point quadruplets, one quadruplet for each ion. The first three values of each + quadruplet encode the position of the ion. The fourth value is the integer identifier + of the cluster encoded as a floating point number. + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + recover_evaporation_id(NX_BOOLEAN): + doc: | + Specifies if paraprobe-clusterer should use the evaporation_ids from reconstruction + for recovering for each position in the :ref:`NXserialized` results the closest matching position + (within floating point accuracy). This can be useful when users wish to recover the + original evaporation_id, which IVAS /AP Suite drops when writing their *.indexed.* cluster + results POS files that is referred to results. + # recover_bitmask(NX_BOOLEAN): + # doc: | + # Specifies if the tool should try to recover, after a recovery of the + # evaporation IDs a bitmask which identifies which of the positions + # in dataset/dataset/dataset_name_reconstruction where covered + # by the IVAS/APSuite cluster analysis. This can be useful to recover + # the region of interest. + programID(NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + profiling(NXcs_profiling): + exists: recommended + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + current_working_directory(NX_CHAR): + cluster_analysisID(NXapm_paraprobe_tool_config): + exists: [min, 0, max, infty] + doc: | + This process performs a cluster analysis on a + reconstructed dataset or a ROI within it. + reconstruction(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + position(NX_CHAR): + mass_to_charge(NX_CHAR): + ranging(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + ranging_definitions(NX_CHAR): + surface_distance(NXserialized): + exists: optional + doc: | + Distance between each ion and triangulated surface mesh. + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + distance(NX_CHAR): + spatial_filter(NXspatial_filter): + windowing_method(NX_CHAR): + hexahedron_set(NXcg_hexahedron_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + hexahedra(NXcg_face_list_data_structure): + vertices(NX_UINT): + cylinder_set(NXcg_cylinder_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + height(NX_NUMBER): + radii(NX_NUMBER): + ellipsoid_set(NXcg_ellipsoid_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + half_axes_radii(NX_NUMBER): + orientation(NX_NUMBER): + polyhedron_set(NXcg_polyhedron_set): + exists: optional + # TODO + bitmask(NXcs_filter_boolean_mask): + exists: optional + number_of_objects(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + # leave open if scalar or matrix + # dim: (i,) + # identifier(NX_UINT): + evaporation_id_filter(NXsubsampling_filter): + exists: optional + min_incr_max(NX_INT): + iontype_filter(NXmatch_filter): + exists: optional + method(NX_CHAR): + match(NX_NUMBER): + hit_multiplicity_filter(NXmatch_filter): + exists: optional + method(NX_CHAR): + match(NX_NUMBER): + # config + ion_type_filter(NX_CHAR): + doc: | + How should iontypes be considered during the cluster analysis. + + The value resolve_all will set an ion active + in the analysis regardless of which iontype it is. + + The value resolve_unknown will set an ion active + when it is of the UNKNOWNTYPE. + + The value resolve_ion will set an ion active + if it is of the specific iontype, irregardless of its nuclide structure. + + The value resolve_element will set an ion active and account as many times + for it, as the (molecular) ion contains atoms of elements in the whitelist + ion_query_nuclide_vector. + + The value resolve_isotope will set an ion active and account as many times + for it, as the (molecular) ion contains nuclides in the whitelist + ion_query_nuclide_vector. + + In effect, ion_query_nuclide_vector acts as a whitelist to filter which ions are + considered as source ions of the correlation statistics and how the multiplicity + of each ion will be factorized. + + This is relevant as in atom probe we have the situation that an ion of a molecular + ion with more than one nuclide, say Ti O for example is counted potentially several + times because at that position (reconstructed) position it has been assumed that + there was a Ti and an O atom. This multiplicity affects the size of the feature and its + chemical composition. + # enumeration: [resolve_all, resolve_unknown, resolve_ion, resolve_element, resolve_isotope] + enumeration: [resolve_element] + ion_query_nuclide_vector(NX_UINT): + doc: | + Matrix of nuclide vectors, as many as rows as different candidates + for iontypes should be distinguished as possible source iontypes. + In the simplest case, the matrix contains only the proton number + of the element in the row, all other values set to zero. + unit: NX_UNITLESS + dim: (n_ions, n_ivec_max) + # which clustering algorithms to execute? + dbscan(NXprocess): + doc: | + Settings for DBScan clustering algorithm. For original details about the + algorithm and (performance-relevant) details consider: + + * `M. Ester et al. `_ + * `M. Götz et al. `_ + + For details about how the DBScan algorithms is the key behind the + specific modification known as the maximum-separation method in the + atom probe community consider `E. Jägle et al. `_ + high_throughput_method(NX_CHAR): + doc: | + Strategy how a set of cluster analyses with different parameter is executed: + + * For tuple as many runs are performed as parameter values have been defined. + * For combinatorics individual parameter arrays are looped over. + + As an example we may provide ten entries for eps and three entries for min_pts. + If high_throughput_method is set to tuple, the analysis is invalid because we have + an insufficient number of min_pts values to pair them with our ten eps values. + By contrast, if high_throughput_method is set to combinatorics, the tool will run three + individual min_pts runs for each eps value, resulting in a total of 30 analyses. + + A typical example from the literature `M. Kühbach et al. `_ + can be instructed via setting eps to an array of values np.linspace(0.2, 5.0, nums=241, endpoint=True), + one min_pts value that is equal to 1, and high_throughput_method set to combinatorics. + enumeration: [tuple, combinatorics] + eps(NX_FLOAT): + doc: | + Array of epsilon (eps) parameter values. + unit: NX_LENGTH + dim: (i,) + min_pts(NX_UINT): + doc: | + Array of minimum points (min_pts) parameter values. + unit: NX_UNITLESS + dim: (j,) + # THE IDEA BEHIND paraprobe-clusterer is that users can run a number of cluster analyses + # on their dataset on exactly the same point cloud and under the same conditions + # optics(NXprocess): + # doc: | + # Settings for the OPTICS clustering algorithm. + # + # * `M. Ankerest et al. `_ + # high_throughput_method(NX_CHAR): + # doc: | + # Strategy how runs with different parameter values are composed, + # following the explanation for higih_throughput_method of dbscan. + # enumeration: [tuple, combinatorics] + # min_pts(NX_UINT): + # doc: | + # Array of minimum points (min_pts) parameter values. + # unit: NX_UNITLESS + # dim: (i,) + # max_eps(NX_FLOAT): + # doc: | + # Array of maximum epsilon (eps) parameter values. + # unit: NX_LENGTH + # dim: (j,) + hdbscan(NXprocess): + doc: | + Settings for the HPDBScan clustering algorithm. + + * L. McInnes et al. `_ + * scikit-learn hdbscan library ``_ + + See also this documentation for details about the parameter. + Here we use the terminology of the hdbscan documentation. + high_throughput_method(NX_CHAR): + doc: | + Strategy how runs with different parameter values are composed, + following the explanation for higih_throughput_method of dbscan. + enumeration: [tuple, combinatorics] + min_cluster_size(NX_NUMBER): + doc: | + Array of min_cluster_size parameter values. + unit: NX_ANY + dim: (i,) + min_samples(NX_NUMBER): + doc: | + Array of min_samples parameter values. + unit: NX_ANY + dim: (j,) + cluster_selection_epsilon(NX_NUMBER): + doc: | + Array of cluster_selection parameter values. + unit: NX_ANY + dim: (k,) + alpha(NX_NUMBER): + doc: | + Array of alpha parameter values. + unit: NX_ANY + dim: (m,) + # ADD FURTHER ALGORITHMS, see L. Stephenson for further details + # e.g. https://doi.org/10.1017/S1431927607070900 + programID(NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + profiling(NXcs_profiling): + exists: recommended + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + current_working_directory(NX_CHAR): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml new file mode 100644 index 0000000000..e3a51e8e3e --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml @@ -0,0 +1,192 @@ +category: application +doc: | + Application definition for results files of the paraprobe-spatstat tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_ions: | + The total number of ions in the reconstruction. + n_feat: | + Number of clusters found. +type: group +NXapm_paraprobe_clusterer_results(NXobject): + (NXentry): + exists: [min, 1, max, 1] + definition(NX_CHAR): + \@version(NX_CHAR): + enumeration: [NXapm_paraprobe_clusterer_results] + # tasks + cameca_to_nexus(NXapm_paraprobe_tool_results): + exists: optional + spatial_statisticsID(NXapm_paraprobe_tool_results): + exists: [min, 0, max, infty] + analysis_identifier(NX_UINT): + config(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + window(NXcs_filter_boolean_mask): + number_of_ions(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + # results + dbscanID(NXsimilarity_grouping): + exists: [min, 0, max, infty] + doc: | + Results of a DBScan clustering analysis. + eps(NX_FLOAT): + doc: | + The epsilon (eps) parameter used. + unit: NX_LENGTH + min_pts(NX_UINT): + doc: | + The minimum points (min_pts) parameter used. + unit: NX_UNITLESS + cardinality(NX_UINT): + doc: | + Number of members in the set which is partitioned into features. + Specifically, this is the total number of targets filtered from the + dataset, i.e. typically the number of clusters which is usually not and + for sure not necessarily the total number of ions in the dataset. + unit: NX_UNITLESS + identifier_offset(NX_INT): + doc: | + Which identifier is the first to be used to label a cluster. + + The value should be chosen in such a way that special values can be resolved: + * identifier_offset - 1 indicates an object belongs to no cluster. + * identifier_offset - 2 indicates an object belongs to the noise category. + + Setting for instance identifier_offset to 1 recovers the commonly used + case that objects of the noise category get the value of -1 and points of the + unassigned category get the value 0. + targets(NX_UINT): + doc: | + The evaporation (sequence) identifier (aka evaporation_id) to figure out + which ions from the reconstruction were considered targets. The length + of this array is not necessarily n_ions. + Instead, it is the value of cardinality. + unit: NX_UNITLESS + dim: (i,) + # quantities for debugging purposes + number_of_solutions(NX_UINT): + exists: optional + doc: | + The number of solutions found for each target. Typically, + this value is 1 in which case the field can be omitted. + Otherwise, this array is the concatenated set of values of solution + tuples for each target that can be used to decode model_labels, + core_sample_indices, and weight. + unit: NX_UNITLESS + dim: (i,) + model_labels(NX_INT): + exists: optional + doc: | + The raw labels from the DBScan clustering backend process. + The length of this array is not necessarily n_ions. + Instead, it is typically the value of cardinality provided that each + target has only one associated cluster. If targets are assigned to + multiple cluster this array is as long as the total number of solutions + found and + unit: NX_UNITLESS + dim: (k,) + core_sample_indices(NX_INT): + exists: optional + doc: | + The raw array of core sample indices which specify which of the + targets are core points. + unit: NX_UNITLESS + dim: (k,) + numerical_labels(NX_UINT): + doc: | + Numerical label for each target (member in the set) aka cluster identifier. + unit: NX_UNITLESS + dim: (k,) + categorical_labels(NX_CHAR): + exists: optional + doc: | + Categorical label(s) for each target (member in the set) aka cluster name(s). + dim: (k,) + weights(NX_NUMBER): + exists: optional + doc: | + Weights for each target that specifies how probable the target is assigned to + a specific cluster. + + For the DBScan algorithm and atom probe tomography this value is the + multiplicity of each ion with respect to the cluster. That is how many times + should the position of the ion be accounted for because the ion is e.g. a + molecular ion with several elements or nuclides of requested type. + unit: NX_UNITLESS + dim: (k,) + is_noise(NX_BOOLEAN): # NXcs_filter_boolean_mask): + # number_of_objects(NX_UINT): + # bitdepth(NX_UINT): + # mask(NX_UINT): + exists: optional + doc: | + Are targets assigned to the noise category or not. + dim: (k,) + is_core(NX_BOOLEAN): # NXcs_filter_boolean_mask): + # number_of_objects(NX_UINT): + # bitdepth(NX_UINT): + # mask(NX_UINT): + exists: optional + doc: | + Are targets assumed a core point. + dim: (k,) + statistics(NXprocess): + exists: recommended + doc: | + In addition to the detailed storage which members were grouped to which + feature here summary statistics are stored that communicate e.g. how many + cluster were found. + # at the level of the set of targets + number_of_targets(NX_UINT): + doc: | + Total number of targets in the set, i.e. ions that were filtered + and considered in this cluster analysis. + number_of_noise(NX_UINT): + doc: | + Total number of members in the set which are categorized as noise. + unit: NX_UNITLESS + number_of_core(NX_UINT): + doc: | + Total number of members in the set which are categorized as a core point. + unit: NX_UNITLESS + number_of_features(NX_UINT): + doc: | + Total number of clusters (excluding noise and unassigned). + unit: NX_UNITLESS + # at the level of the feature set + feature_identifier(NX_UINT): + doc: | + Numerical identifier of each feature aka cluster_identifier. + unit: NX_UNITLESS + dim: (n_feat,) + feature_member_count(NX_UINT): + doc: | + Number of members for each feature. + unit: NX_UNITLESS + dim: (n_feat,) + # ADD FURTHER RESULTS along the same pattern for e.g. OPTICS and HDBSCAN + # global + userID(NXuser): + exists: [min, 0, max, infty] + name(NX_CHAR): + coordinate_system_set(NXcoordinate_system_set): + paraprobe(NXcoordinate_system): + type(NX_CHAR): + handedness(NX_CHAR): + x(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + y(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + z(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.yaml deleted file mode 100644 index 063f13f3a0..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_config_clusterer.yaml +++ /dev/null @@ -1,860 +0,0 @@ -category: application -doc: | - Configuration of a paraprobe-clusterer tool run in atom probe microscopy. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - - # n_positions: Number of position values. - # n_disjoint_clusters: Number of disjoint cluster. - n_ivecmax: | - Maximum number of atoms per molecular ion. Should be 32 for paraprobe. - n_clust_algos: | - Number of clustering algorithms used. - n_ions: | - Number of different iontypes to distinguish during clustering. -type: group -NXapm_paraprobe_config_clusterer(NXobject): - (NXentry): - - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently - \@version: - doc: | - Version specifier of this application definition. - definition: - doc: | - Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_config_clusterer] - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - time_stamp(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: | - Possibility for leaving a free-text description about this analysis. - number_of_processes(NX_UINT): - unit: NX_UNITLESS - doc: | - How many tasks to perform? - cameca_to_nexus(NXprocess): - exists: optional - doc: | - This process maps results from cluster analyses performed with IVAS/APSuite - into an interoperable representation. Specifically in this process - paraprobe-clusterer takes results from clustering methods from other tools - of the APM community, like IVAS/APSuite. These results are usually reported - in two ways. Either as an explicit list of reconstructed ion positions. - In the case of IVAS these positions are reported through a text file - with a cluster label for each position. - - Alternatively, the list of positions is reported, as it is the case for - AMETEK (IVAS/AP Suite) but the cluster labels are specified implicitly - only in the following way: The mass-to-charge-state ratio column of a - what is effectively a file formatted like POS is used to assign a hypothetical - mass-to-charge value which resolves a floating point representation - of the cluster ID. - - Another case can occur where all disjoint floating point values, - i.e. here cluster labels, are reported and then a dictionary is created - how each value matches to a cluster ID. - - In general the cluster ID zero is reserved for marking the dataset - as to not be assigned to any cluster. Therefore, indices of disjoint - clusters start at 1. - dataset(NXapm_input_reconstruction): - filename: - \@version: - dataset_name_reconstruction: - dataset_name_mass_to_charge: - doc: | - AMETEK/Cameca results of cluster analyses, like with the maximum- - separation (MS) method clustering algorithm `J. Hyde et al. `_ - are stored as an improper POS file: This is a matrix of floating - point quadruplets, one for each ion and as many quadruplets as - ions were investigated. The first three values encode the position - of the ion. The fourth value is an improper mass-to-charge-state-ratio - value which encodes the integer identifier of the cluster as a floating - point number. - - # mapping_method: - # doc: | - # How should cluster labels be created from the cluster_labels information - # especially when these areNcluste floating point values. - # enumeration: [take_as_is, use_dictionary] - # mapping_dictionary_keyword(NX_NUMBER): - # doc: | - # The list of all keywords of a dictionary which maps implicit cluster - # indices like those from IVAS/APSuite which were0ass-to-charge-state ratios. - # unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, n_disjoint_clusters]] - # mapping_dictionary_value(NX_UINT): - # doc: | - # The list of all values of a dictionary which maps implicit cluster - # indices like those from IVAS/APSuite which were0ass-to-charge-state ratios. - # The sequences of mapping_dictionary_keyword and mapping_dictionary_value - # have to match. - # unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, n_disjoint_clusters]] - recover_evaporation_id(NX_BOOLEAN): - doc: | - Specifies if the tool should try to recover for each position the closest - matching position from dataset/dataset_name_reconstruction (within - floating point accuracy). This can be useful for instance when users - wish to recover the original evaporation ID, which IVAS/AP Suite drops - for instance when writing their *.indexed.* cluster results POS files. - - # recover_bitmask(NX_BOOLEAN): - # doc: | - # Specifies if the tool should try to recover, after a recovery of the - # evaporation IDs a bitmask which identifies which of the positions - # in dataset/dataset/dataset_name_reconstruction where covered - # by the IVAS/APSuite cluster analysis. This can be useful to recover - # the region of interest. - cluster_analysis(NXprocess): - exists: ['min', '0', 'max', '1'] - doc: | - This process performs a cluster analysis on a reconstructed dataset - or a portion of the reconstruction. - dataset(NXapm_input_reconstruction): - filename: - \@version: - dataset_name_reconstruction: - dataset_name_mass_to_charge: - iontypes(NXapm_input_ranging): - filename: - \@version: - group_name_iontypes: - ion_to_edge_distances(NXprocess): - exists: optional - doc: | - The tool enables to inject precomputed distance information for each - point/ion which can be used for further post-processing and analysis. - filename: - doc: | - Name of an HDF5 file which contains the ion distances. - \@version: - doc: | - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - dataset_name: - doc: | - Absolute HDF5 path to the dataset with distance values for each ion. - spatial_filter(NXspatial_filter): - exists: optional - windowing_method: - enumeration: [entire_dataset] - (NXcg_ellipsoid_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - half_axes_radii(NX_NUMBER): - orientation(NX_NUMBER): - (NXcg_cylinder_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - center(NX_NUMBER): - height(NX_NUMBER): - radii(NX_NUMBER): - (NXcg_hexahedron_set): - exists: optional - dimensionality(NX_POSINT): - cardinality(NX_POSINT): - identifier_offset(NX_INT): - hexahedra(NXcg_face_list_data_structure): - (NXcs_filter_boolean_mask): - exists: optional - number_of_objects(NX_UINT): - bitdepth(NX_UINT): - mask(NX_UINT): - identifier(NX_UINT): - evaporation_id_filter(NXsubsampling_filter): - exists: optional - iontype_filter(NXmatch_filter): - exists: optional - hit_multiplicity_filter(NXmatch_filter): - exists: optional - - # clustering_algorithm: - # doc: | - # Name of the clustering algorithm used. - # enumeration: [dbscan] # , optics, hpdbscan] - # dimensions: - # rank: 1 - # dim: [[1, n_clust_algos]] - ion_type_filter: - doc: | - How should iontypes be interpreted/considered during the cluster analysis. - Different options exist how iontypes are interpreted (if considered at all) - given an iontype represents in general a (molecular) ion with different isotopes - that have individually different multiplicity. - - The value resolve_all will set an ion active in the analysis - regardless of which iontype it is. - The value resolve_unknown will set an ion active when it is of the - UNKNOWNTYPE. - The value resolve_ion will set an ion active if it is of the - specific iontype, irregardless of its elemental or isotopic details. - The value resolve_element will set an ion active, and most importantly, - account as many times for it, as the (molecular) ion contains - atoms of elements in the whitelist ion_query_isotope_vector. - The value resolve_isotope will set an ion active, and most importantly, - account as many times for it, as the (molecular) ion contains isotopes - in the whitelist ion_query_isotope_vector. - - In effect, ion_query_isotope_vector acts as a whitelist to filter - which ions are considered as source ions of the correlation statistics - and how the multiplicity of each ion will be factorized. - - This is relevant as in atom probe we have the situation that a ion - of a molecular ion with more than one nuclid, say Ti O for example - is counted such that although there is a single TiO molecular ion - at a position that the cluster has two members. This multiplicity - affects the size of the feature and chemical composition. - - # enumeration: [resolve_all, resolve_unknown, resolve_ion, resolve_element, resolve_isotope] - enumeration: [resolve_element] - ion_query_isotope_vector(NX_UINT): - unit: NX_UNITLESS - doc: | - Matrix of isotope vectors, as many as rows as different candidates - for iontypes should be distinguished as possible source iontypes. - In the simplest case, the matrix contains only the proton number - of the element in the row, all other values set to zero. - Combined with ion_query_type_source set to resolve_element this will - recover usual spatial correlation statistics like the 1NN C-C - spatial statistics. - dimensions: - rank: 2 - dim: [[1, n_ions], [2, n_ivecmax]] - dbscan(NXprocess): - doc: | - Settings for DBScan clustering algorithm. For original details about the - algorithms and (performance-relevant) details consider: - - * `M. Ester et al. `_ - * `M. Götz et al. `_ - - For details about how the DBScan algorithms is the key behind the - specific modification known as the maximum-separation method in the - atom probe community consider `E. Jägle et al. `_ - high_throughput_method: - doc: | - Strategy how runs are performed with different parameter: - - * For tuple as many runs are performed as parameter values. - * For combinatorics individual parameter arrays are looped over. - - As an example we may define eps with ten entries and min_pts with - three entries. If high_throughput_method is tuple the analysis is - invalid as we have an insufficient number of min_pts for the ten - eps values. - By contrast, for combinatorics paraprobe-clusterer will run three - individual min_pts runs for each eps value, resulting in a total - of 30 analyses. - As an example the DBScan analysis reported in `M. Kühbach et al. `_ - would have defined an array of values np.linspace(0.2, 5.0, nums=241, endpoint=True) - eps values, min_pts one, and high_throughput_method set to combinatorics. - enumeration: [tuple, combinatorics] - eps(NX_FLOAT): - unit: NX_LENGTH - doc: | - Array of epsilon (eps) parameter values. - dimensions: - rank: 1 - dim: [[1, i]] - min_pts(NX_UINT): - unit: NX_UNITLESS - doc: | - Array of minimum points (min_pts) parameter values. - dimensions: - rank: 1 - dim: [[1, j]] - - # THE IDEA BEHIND paraprobe-clusterer is that users can run a number of - # cluster analyses on their dataset on exactly the same point cloud and under - # the same conditions - optics(NXprocess): - doc: | - Settings for the OPTICS clustering algorithm. - - * `M. Ankerest et al. `_ - high_throughput_method: - doc: | - Strategy how runs are performed with different parameter: - - * For tuple as many runs are performed as parameter values. - * For combinatorics individual parameter arrays are looped over. - - See the explanation for the corresponding parameter for dbscan - processes above-mentioned for further details. - enumeration: [tuple, combinatorics] - min_pts(NX_UINT): - unit: NX_UNITLESS - doc: | - Array of minimum points (min_pts) parameter values. - dimensions: - rank: 1 - dim: [[1, i]] - max_eps(NX_FLOAT): - unit: NX_LENGTH - doc: | - Array of maximum epsilon (eps) parameter values. - dimensions: - rank: 1 - dim: [[1, j]] - hdbscan(NXprocess): - doc: | - Settings for the HPDBScan clustering algorithm. - - * L. McInnes et al. `_ - * scikit-learn hdbscan library ``_ - - See also this documentation for details about the parameter. - Here we use the terminology of the hdbscan documentation. - high_throughput_method: - doc: | - Strategy how runs are performed with different parameter: - - * For tuple as many runs are performed as parameter values. - * For combinatorics individual parameter arrays are looped over. - - See the explanation for the corresponding parameter for dbscan - processes above-mentioned for further details. - enumeration: [tuple, combinatorics] - min_cluster_size(NX_NUMBER): - unit: NX_ANY - doc: | - Array of min_cluster_size parameter values. - dimensions: - rank: 1 - dim: [[1, i]] - min_samples(NX_NUMBER): - unit: NX_ANY - doc: | - Array of min_samples parameter values. - dimensions: - rank: 1 - dim: [[1, j]] - cluster_selection_epsilon(NX_NUMBER): - unit: NX_ANY - doc: | - Array of cluster_selection parameter values. - dimensions: - rank: 1 - dim: [[1, k]] - alpha(NX_NUMBER): - unit: NX_ANY - doc: | - Array of alpha parameter values. - dimensions: - rank: 1 - dim: [[1, m]] - - # ADD FURTHER ALGORITHMS, see L. Stephenson for further details - # e.g. https://doi.org/10.1017/S1431927607070900 - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 619a54e03721a20d851c9a68159a0166deaa651651c085d15cfcc2593efdefb2 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# -# Maximum number of atoms per molecular ion. Should be 32 for paraprobe. -# -# -# -# -# Number of clustering algorithms used. -# -# -# -# -# Number of different iontypes to distinguish during clustering. -# -# -# -# -# Configuration of a paraprobe-clusterer tool run in atom probe microscopy. -# -# -# -# -# -# Version specifier of this application definition. -# -# -# -# -# Official NeXus NXDL schema with which this file was written. -# -# -# -# -# -# -# -# Given name of the program/software/tool with which this NeXus -# (configuration) file was generated. -# -# -# -# Ideally program version plus build number, or commit hash or description -# of ever persistent resources where the source code of the program and -# build instructions can be found so that the program can be configured -# ideally in such a manner that the result of this computational process -# is recreatable in the same deterministic manner. -# -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when this configuration file was created. -# -# -# -# -# Ideally, a (globally persistent) unique identifier for referring -# to this analysis. -# -# -# -# -# Possibility for leaving a free-text description about this analysis. -# -# -# -# -# How many tasks to perform? -# -# -# -# -# This process maps results from cluster analyses performed with IVAS/APSuite -# into an interoperable representation. Specifically in this process -# paraprobe-clusterer takes results from clustering methods from other tools -# of the APM community, like IVAS/APSuite. These results are usually reported -# in two ways. Either as an explicit list of reconstructed ion positions. -# In the case of IVAS these positions are reported through a text file -# with a cluster label for each position. -# -# Alternatively, the list of positions is reported, as it is the case for -# AMETEK (IVAS/AP Suite) but the cluster labels are specified implicitly -# only in the following way: The mass-to-charge-state ratio column of a -# what is effectively a file formatted like POS is used to assign a hypothetical -# mass-to-charge value which resolves a floating point representation -# of the cluster ID. -# -# Another case can occur where all disjoint floating point values, -# i.e. here cluster labels, are reported and then a dictionary is created -# how each value matches to a cluster ID. -# -# In general the cluster ID zero is reserved for marking the dataset -# as to not be assigned to any cluster. Therefore, indices of disjoint -# clusters start at 1. -# -# -# -# -# -# -# -# -# AMETEK/Cameca results of cluster analyses, like with the maximum- -# separation (MS) method clustering algorithm `J. Hyde et al. <https://doi.org/10.1557/PROC-650-R6.6>`_ -# are stored as an improper POS file: This is a matrix of floating -# point quadruplets, one for each ion and as many quadruplets as -# ions were investigated. The first three values encode the position -# of the ion. The fourth value is an improper mass-to-charge-state-ratio -# value which encodes the integer identifier of the cluster as a floating -# point number. -# -# -# -# -# -# -# Specifies if the tool should try to recover for each position the closest -# matching position from dataset/dataset_name_reconstruction (within -# floating point accuracy). This can be useful for instance when users -# wish to recover the original evaporation ID, which IVAS/AP Suite drops -# for instance when writing their *.indexed.* cluster results POS files. -# -# -# -# -# -# -# This process performs a cluster analysis on a reconstructed dataset -# or a portion of the reconstruction. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The tool enables to inject precomputed distance information for each -# point/ion which can be used for further post-processing and analysis. -# -# -# -# Name of an HDF5 file which contains the ion distances. -# -# -# -# Version identifier of the file such as a secure hash which documents -# the binary state of the file to add an additional layer of -# reproducibility from which file specifically contains these data. -# -# -# -# -# -# Absolute HDF5 path to the dataset with distance values for each ion. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# How should iontypes be interpreted/considered during the cluster analysis. -# Different options exist how iontypes are interpreted (if considered at all) -# given an iontype represents in general a (molecular) ion with different isotopes -# that have individually different multiplicity. -# -# The value resolve_all will set an ion active in the analysis -# regardless of which iontype it is. -# The value resolve_unknown will set an ion active when it is of the -# UNKNOWNTYPE. -# The value resolve_ion will set an ion active if it is of the -# specific iontype, irregardless of its elemental or isotopic details. -# The value resolve_element will set an ion active, and most importantly, -# account as many times for it, as the (molecular) ion contains -# atoms of elements in the whitelist ion_query_isotope_vector. -# The value resolve_isotope will set an ion active, and most importantly, -# account as many times for it, as the (molecular) ion contains isotopes -# in the whitelist ion_query_isotope_vector. -# -# In effect, ion_query_isotope_vector acts as a whitelist to filter -# which ions are considered as source ions of the correlation statistics -# and how the multiplicity of each ion will be factorized. -# -# This is relevant as in atom probe we have the situation that a ion -# of a molecular ion with more than one nuclid, say Ti O for example -# is counted such that although there is a single TiO molecular ion -# at a position that the cluster has two members. This multiplicity -# affects the size of the feature and chemical composition. -# -# -# -# -# -# -# -# -# Matrix of isotope vectors, as many as rows as different candidates -# for iontypes should be distinguished as possible source iontypes. -# In the simplest case, the matrix contains only the proton number -# of the element in the row, all other values set to zero. -# Combined with ion_query_type_source set to resolve_element this will -# recover usual spatial correlation statistics like the 1NN C-C -# spatial statistics. -# -# -# -# -# -# -# -# -# Settings for DBScan clustering algorithm. For original details about the -# algorithms and (performance-relevant) details consider: -# -# * `M. Ester et al. <https://dx.doi.org/10.5555/3001460.3001507>`_ -# * `M. Götz et al. <https://dx.doi.org/10.1145/2834892.2834894>`_ -# -# For details about how the DBScan algorithms is the key behind the -# specific modification known as the maximum-separation method in the -# atom probe community consider `E. Jägle et al. <https://dx.doi.org/10.1017/S1431927614013294>`_ -# -# -# -# Strategy how runs are performed with different parameter: -# -# * For tuple as many runs are performed as parameter values. -# * For combinatorics individual parameter arrays are looped over. -# -# As an example we may define eps with ten entries and min_pts with -# three entries. If high_throughput_method is tuple the analysis is -# invalid as we have an insufficient number of min_pts for the ten -# eps values. -# By contrast, for combinatorics paraprobe-clusterer will run three -# individual min_pts runs for each eps value, resulting in a total -# of 30 analyses. -# As an example the DBScan analysis reported in `M. Kühbach et al. <https://dx.doi.org/10.1038/s41524-020-00486-1>`_ -# would have defined an array of values np.linspace(0.2, 5.0, nums=241, endpoint=True) -# eps values, min_pts one, and high_throughput_method set to combinatorics. -# -# -# -# -# -# -# -# -# Array of epsilon (eps) parameter values. -# -# -# -# -# -# -# -# Array of minimum points (min_pts) parameter values. -# -# -# -# -# -# -# -# -# -# Settings for the OPTICS clustering algorithm. -# -# * `M. Ankerest et al. <https://dx.doi.org/10.1145/304181.304187>`_ -# -# -# -# Strategy how runs are performed with different parameter: -# -# * For tuple as many runs are performed as parameter values. -# * For combinatorics individual parameter arrays are looped over. -# -# See the explanation for the corresponding parameter for dbscan -# processes above-mentioned for further details. -# -# -# -# -# -# -# -# -# Array of minimum points (min_pts) parameter values. -# -# -# -# -# -# -# -# Array of maximum epsilon (eps) parameter values. -# -# -# -# -# -# -# -# -# Settings for the HPDBScan clustering algorithm. -# -# * L. McInnes et al. <https://dx.doi.org/10.21105/joss.00205>`_ -# * scikit-learn hdbscan library `<https://hdbscan.readthedocs.io/en/latest/how_hdbscan_works.html>`_ -# -# See also this documentation for details about the parameter. -# Here we use the terminology of the hdbscan documentation. -# -# -# -# Strategy how runs are performed with different parameter: -# -# * For tuple as many runs are performed as parameter values. -# * For combinatorics individual parameter arrays are looped over. -# -# See the explanation for the corresponding parameter for dbscan -# processes above-mentioned for further details. -# -# -# -# -# -# -# -# -# Array of min_cluster_size parameter values. -# -# -# -# -# -# -# -# Array of min_samples parameter values. -# -# -# -# -# -# -# -# Array of cluster_selection parameter values. -# -# -# -# -# -# -# -# Array of alpha parameter values. -# -# -# -# -# -# -# -# -# -# diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.yaml deleted file mode 100644 index 08186843e9..0000000000 --- a/contributed_definitions/nyaml/NXapm_paraprobe_results_clusterer.yaml +++ /dev/null @@ -1,960 +0,0 @@ -category: application -doc: | - Results of a paraprobe-clusterer tool run. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - n_ions: | - The total number of ions in the reconstruction. - n_dict: | - The total number of entries in the restricted_identifier dictionary. -type: group -NXapm_paraprobe_results_clusterer(NXobject): - - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently - (NXentry): - exists: ['min', '1', 'max', '1'] - \@version: - doc: | - Version specifier of this application definition. - - ##MK::begin of the tool-specific section - definition: - doc: | - Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_results_clusterer] - - ##MK::end of the tool-specific section - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: | - Possibility for leaving a free-text description about this analysis. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - config_filename: - doc: | - The absolute path and name of the config file for this analysis. - \@version: - doc: | - At least SHA256 strong hash of the specific config_file for - tracking provenance. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - status: - doc: | - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must no longer compute analyses. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases, it might be - that the executable has terminated prematurely or another error - occurred. - enumeration: [success, failure] - (NXuser): - exists: optional - doc: | - If used, contact information and eventually details - of at least the person who performed this analysis. - name: - affiliation: - exists: recommended - address: - exists: optional - email: - exists: recommended - orcid: - exists: recommended - orcid_platform: - exists: recommended - telephone_number: - exists: optional - role: - exists: recommended - social_media_name: - exists: optional - social_media_platform: - exists: optional - (NXcoordinate_system_set): - doc: | - Details about the coordinate system conventions used. - If nothing else is specified we assume that there - has to be at least one set of NXtransformations named - paraprobe defined, which specifies the coordinate system. - In which all positions are defined. - - ##MK::define also reconstruction coordinate system and - ##MK::map between the two - (NXtransformations): - exists: ['min', '1', 'max', 'unbounded'] - doc: | - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - ##MK::begin of the tool-specific section - (NXprocess): - exists: ['min', '0', 'max', '1'] - window(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies which of the ions in the dataset were - analyzed during this process. - number_of_ions(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of ions covered by the mask. - The mask value for most may be 0. - bitdepth(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - mask(NX_UINT): - unit: NX_UNITLESS - doc: | - The unsigned integer array representing the content of the mask. - If padding is used, padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe-toolbox executable. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth (padding). - dimensions: - rank: 1 - dim: [[1, n_ions]] - cluster_analysis(NXprocess): - exists: optional - doc: | - The result of a cluster analyses. These include typically the label for - each ion/point documenting to which feature (if any) an ion is assigned. - Typically, each analysis/run yields only a single cluster. - In cases of fuzzy clustering it can be possible that an ion is assigned - to multiple cluster (eventually with different) weight/probability. - dbscanID(NXsimilarity_grouping): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - Results of a DBScan clustering analysis. - eps(NX_FLOAT): - unit: NX_LENGTH - doc: | - The epsilon (eps) parameter. - min_pts(NX_UINT): - unit: NX_UNITLESS - doc: | - The minimum points (min_pts) parameter. - cardinality(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of members in the set which is partitioned into features. - Specifically, this is the total number of targets filtered from the - dataset. Cardinality here is not the total number of ions in the - dataset. - - # number_of_numeric_labels(NX_UINT): - # doc: | - # How many numerical labels does each feature have. - # unit: NX_UNITLESS - # number_of_categorical_labels(NX_UINT): - # doc: | - # How many categorical labels does each feature have. - # unit: NX_UNITLESS - # features: - # doc: | - # Reference to a set of features investigated in a cluster analysis. - # Features need to have disjoint numeric identifier. - identifier_offset(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Which identifier is the first to be used to label a cluster. - - The value should be chosen in such a way that special values can be resolved: - * identifier_offset-1 indicates an object belongs to no cluster. - * identifier_offset-2 indicates an object belongs to the noise category. - Setting for instance identifier_offset to 1 recovers the commonly used - case that objects of the noise category get values to -1 and unassigned points to 0. - Numerical identifier have to be strictly increasing. - - # dimensions: - # rank: 1 - # dim: [[1, n_lbl_num]] - # reserved_identifier_keyword(NX_UINT): - # doc: | - # By default we assume that cluster identifier 0 is reserved to - # mark that ions are not assigned to a cluster and identifier 1 is - # noise. The reserved_identifier_keyword and reserved_identifier_value - # can be used as a dictionary though to define that users - # which to overwrite this default and define own specific categories. - # In every case though cluster_identifier have to be positive integer - # and be consecutive on $[0, maximum_value]$. - # unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, n_dict]] - # reserved_identifier_value: - # doc: | - # The corresponding value of the reserved_identifier dictionary. - # This can give a free-text description what a specific reserved - # ID specifies e.g. ignored, noise. - # unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, n_dict]] - targets(NX_UINT): - unit: NX_UNITLESS - doc: | - The evaporation sequence identifier to figure out which ions - from the reconstruction were considered targets. - dimensions: - rank: 1 - dim: [[1, c]] - - # quantities for debugging purposes - model_labels(NX_INT): - unit: NX_UNITLESS - doc: | - The raw labels from the DBScan clustering backend process. - dimensions: - rank: 1 - dim: [[1, c]] - core_sample_indices(NX_INT): - unit: NX_UNITLESS - doc: | - The raw array of core sample indices which specify which of the - targets are core points. - dimensions: - rank: 1 - dim: [[1, n]] - - # quantities to which these debugging quantities should be transformed - numerical_label(NX_UINT): - unit: NX_UNITLESS - doc: | - Matrix of numerical label for each member in the set. - For classical clustering algorithms this can for instance - encode the cluster_identifier. - dimensions: - rank: 1 - dim: [[1, c]] - - # categorical_label: - # doc: | - # Matrix of categorical attribute data for each member in the set. - # dimensions: - # rank: 2 - # dim: [[1, c], [2, n_lbl_cat]] - weight(NX_NUMBER): - exists: optional - unit: NX_UNITLESS - doc: | - The array of weight which specifies how surely/likely the - cluster is associated/assigned to a specific identifier as - is specified in the cluster_identifier array. - For the DBScan and atom probe tomography the multiplicity - of each ion with respect to the cluster. That is how many times - should the position of the ion be accounted for because the ion - is e.g. a molecular ion with several elements or isotope of - requested type. - dimensions: - rank: 1 - dim: [[1, c]] - is_noise(NX_BOOLEAN): - exists: optional - doc: | - Optional bitmask encoding if members of the set are assigned to as noise or not. - dimensions: - rank: 1 - dim: [[1, c]] - is_core(NX_BOOLEAN): - exists: optional - doc: | - Optional bitmask encoding if member of the set are a core point. - For details to which feature/cluster an ion/point is a core point - consider numerical_label. - dimensions: - rank: 1 - dim: [[1, c]] - statistics(NXprocess): - doc: | - In addition to the detailed storage which members was grouped to - which feature/group summary statistics are stored under this group. - - # at the level of the set - # number_of_unassigned_members(NX_UINT): - # doc: | - # Total number of members in the set which are categorized as unassigned. - # unit: NX_UNITLESS - # dimensions: - # rank: 1 - # dim: [[1, n_lbl_num]] - number_of_noise(NX_UINT): - unit: NX_UNITLESS - doc: | - Total number of members in the set which are categorized as noise. - - # dimensions: - # rank: 1 - # dim: [[1, n_lbl_num]] - number_of_core(NX_UINT): - unit: NX_UNITLESS - doc: | - Total number of members in the set which are categorized as a core point. - - # dimensions: - # rank: 1 - # dim: [[1, n_lbl_num]] - # at the level of the feature set - number_of_features(NX_UINT): - unit: NX_UNITLESS - doc: | - Total number of clusters (excluding noise and unassigned). - feature_identifier(NX_UINT): - unit: NX_UNITLESS - doc: | - Array of numerical identifier of each feature (cluster). - dimensions: - rank: 1 - dim: [[1, n_features]] - feature_member_count(NX_UINT): - unit: NX_UNITLESS - doc: | - Array of number of members for each feature. - dimensions: - rank: 1 - dim: [[1, n_features]] - - # ADD FURTHER RESULTS along the same pattern for e.g. OPTICS and HDBSCAN - - ##MK::end of the tool-specific section - performance(NXcs_profiling): - exists: recommended - current_working_directory: - command_line_call: - exists: optional - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - total_elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - (NXcs_computer): - exists: recommended - name: - exists: recommended - operating_system: - \@version: - uuid: - exists: optional - (NXcs_cpu): - exists: ['min', '0', 'max', 'unbounded'] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_gpu): - exists: ['min', '0', 'max', 'unbounded'] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_mm_sys): - exists: ['min', '0', 'max', '1'] - total_physical_memory(NX_NUMBER): - (NXcs_io_sys): - exists: ['min', '0', 'max', '1'] - (NXcs_io_obj): - exists: ['min', '1', 'max', 'unbounded'] - technology: - max_physical_capacity(NX_NUMBER): - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_profiling_event): - start_time(NX_DATE_TIME): - exists: optional - end_time(NX_DATE_TIME): - exists: optional - description: - elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - number_of_threads(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - number_of_gpus(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - max_virtual_memory_snapshot(NX_NUMBER): - exists: recommended - max_resident_memory_snapshot(NX_NUMBER): - exists: recommended - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# b3a37df81b97bc33a6f0f18e802898a70c94977a92b2e598360ceb871ee5cd9c -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The total number of ions in the reconstruction. -# -# -# -# -# The total number of entries in the restricted_identifier dictionary. -# -# -# -# -# Results of a paraprobe-clusterer tool run. -# -# -# -# -# -# Version specifier of this application definition. -# -# -# -# -# -# Official NeXus NXDL schema with which this file was written. -# -# -# -# -# -# -# -# -# Given name of the program/software/tool with which this NeXus -# (configuration) file was generated. -# -# -# -# Ideally program version plus build number, or commit hash or description -# of ever persistent resources where the source code of the program and -# build instructions can be found so that the program can be configured -# ideally in such a manner that the result of this computational process -# is recreatable in the same deterministic manner. -# -# -# -# -# -# Ideally, a (globally persistent) unique identifier for referring -# to this analysis. -# -# -# -# -# Possibility for leaving a free-text description about this analysis. -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when the analysis behind this results file -# was started, i.e. the paraprobe-tool executable started as a process. -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when the analysis behind this results file -# were completed and the paraprobe-tool executable exited as a process. -# -# -# -# -# The absolute path and name of the config file for this analysis. -# -# -# -# At least SHA256 strong hash of the specific config_file for -# tracking provenance. -# -# -# -# -# -# Path to the directory where the tool should store NeXus/HDF5 results -# of this analysis. If not specified results will be stored in the -# current working directory. -# -# -# -# -# A statement whether the paraprobe-tool executable managed to -# process the analysis or failed prematurely. -# -# This status is written to the results file after the end_time -# at which point the executable must no longer compute analyses. -# Only when this status message is present and shows `success`, the -# user should consider the results. In all other cases, it might be -# that the executable has terminated prematurely or another error -# occurred. -# -# -# -# -# -# -# -# -# If used, contact information and eventually details -# of at least the person who performed this analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Details about the coordinate system conventions used. -# If nothing else is specified we assume that there -# has to be at least one set of NXtransformations named -# paraprobe defined, which specifies the coordinate system. -# In which all positions are defined. -# -# -# -# -# The individual coordinate systems which should be used. -# Field names should be prefixed with the following controlled terms -# indicating which individual coordinate system is described: -# -# * paraprobe -# * lab -# * specimen -# * laser -# * leap -# * detector -# * recon -# -# -# -# -# -# -# -# A bitmask which identifies which of the ions in the dataset were -# analyzed during this process. -# -# -# -# Number of ions covered by the mask. -# The mask value for most may be 0. -# -# -# -# -# Number of bits assumed matching on a default datatype. -# (e.g. 8 bits for a C-style uint8). -# -# -# -# -# The unsigned integer array representing the content of the mask. -# If padding is used, padded bits are set to 0. The mask is for -# convenience always as large as the entire dataset as it will -# be stored compressed anyway. The convenience feature with this -# is that then the mask can be decoded with numpy and mirrored -# against the evaporation_id array and one immediately can filter -# out all points that were used by the paraprobe-toolbox executable. -# The length of the array adds to the next unsigned integer -# if the number of ions in the dataset is not an integer -# multiple of the bitdepth (padding). -# -# -# -# -# -# -# -# -# The result of a cluster analyses. These include typically the label for -# each ion/point documenting to which feature (if any) an ion is assigned. -# Typically, each analysis/run yields only a single cluster. -# In cases of fuzzy clustering it can be possible that an ion is assigned -# to multiple cluster (eventually with different) weight/probability. -# -# -# -# Results of a DBScan clustering analysis. -# -# -# -# The epsilon (eps) parameter. -# -# -# -# -# The minimum points (min_pts) parameter. -# -# -# -# -# Number of members in the set which is partitioned into features. -# Specifically, this is the total number of targets filtered from the -# dataset. Cardinality here is not the total number of ions in the -# dataset. -# -# -# -# -# -# Which identifier is the first to be used to label a cluster. -# -# The value should be chosen in such a way that special values can be resolved: -# * identifier_offset-1 indicates an object belongs to no cluster. -# * identifier_offset-2 indicates an object belongs to the noise category. -# Setting for instance identifier_offset to 1 recovers the commonly used -# case that objects of the noise category get values to -1 and unassigned points to 0. -# Numerical identifier have to be strictly increasing. -# -# -# -# -# -# The evaporation sequence identifier to figure out which ions -# from the reconstruction were considered targets. -# -# -# -# -# -# -# -# -# The raw labels from the DBScan clustering backend process. -# -# -# -# -# -# -# -# The raw array of core sample indices which specify which of the -# targets are core points. -# -# -# -# -# -# -# -# -# Matrix of numerical label for each member in the set. -# For classical clustering algorithms this can for instance -# encode the cluster_identifier. -# -# -# -# -# -# -# -# -# The array of weight which specifies how surely/likely the -# cluster is associated/assigned to a specific identifier as -# is specified in the cluster_identifier array. -# For the DBScan and atom probe tomography the multiplicity -# of each ion with respect to the cluster. That is how many times -# should the position of the ion be accounted for because the ion -# is e.g. a molecular ion with several elements or isotope of -# requested type. -# -# -# -# -# -# -# -# Optional bitmask encoding if members of the set are assigned to as noise or not. -# -# -# -# -# -# -# -# Optional bitmask encoding if member of the set are a core point. -# For details to which feature/cluster an ion/point is a core point -# consider numerical_label. -# -# -# -# -# -# -# -# In addition to the detailed storage which members was grouped to -# which feature/group summary statistics are stored under this group. -# -# -# -# -# Total number of members in the set which are categorized as noise. -# -# -# -# -# -# Total number of members in the set which are categorized as a core point. -# -# -# -# -# -# Total number of clusters (excluding noise and unassigned). -# -# -# -# -# Array of numerical identifier of each feature (cluster). -# -# -# -# -# -# -# -# Array of number of members for each feature. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Specify if it was different from the number_of_processes -# in the NXcs_profiling super class. -# -# -# -# -# -# Specify if it was different from the number_of_threads -# in the NXcs_profiling super class. -# -# -# -# -# -# Specify if it was different from the number_of_threads -# in the NXcs_profiling super class. -# -# -# -# -# -# -# -# -# From 6122e74cd62a2c9a86a5fef5a8dd6b918caba16a Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Sun, 11 Feb 2024 00:36:07 +0100 Subject: [PATCH 0552/1012] Added missing profiling and program for results appdefs of tools where missing --- ...NXapm_paraprobe_clusterer_results.nxdl.xml | 22 +- ...NXapm_paraprobe_distancer_results.nxdl.xml | 16 ++ .../NXapm_paraprobe_spatstat_config.nxdl.xml | 2 +- .../NXapm_paraprobe_spatstat_results.nxdl.xml | 190 ++++++++++++++++++ .../NXapm_paraprobe_surfacer_results.nxdl.xml | 22 +- ...apm_paraprobe_tessellator_results.nxdl.xml | 16 ++ .../NXapm_paraprobe_clusterer_results.yaml | 17 +- .../NXapm_paraprobe_distancer_results.yaml | 15 ++ .../NXapm_paraprobe_spatstat_config.yaml | 2 +- .../NXapm_paraprobe_spatstat_results.yaml | 15 ++ .../NXapm_paraprobe_surfacer_results.yaml | 15 ++ .../NXapm_paraprobe_tessellator_results.yaml | 15 ++ 12 files changed, 338 insertions(+), 9 deletions(-) create mode 100644 contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml diff --git a/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml index 10222f152c..4c803d14de 100644 --- a/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml @@ -51,7 +51,7 @@ - + @@ -249,9 +249,25 @@ number_of_objects(NX_UINT): + + + + + + + + + + + + + + + + - + diff --git a/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml index 7e1179c231..8b33f799e0 100644 --- a/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml @@ -153,6 +153,22 @@ triangles in this case--> + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml index 86eb43fba4..a7f4198b71 100644 --- a/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml @@ -319,7 +319,7 @@ identifier(NX_UINT):--> +profiling (only stored in the first instance of spatial_statistics)--> diff --git a/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml new file mode 100644 index 0000000000..e06d6f7b2f --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml @@ -0,0 +1,190 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + Application definition for results files of the paraprobe-spatstat tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + + + + + + + + + + + + + + + + + + + + + + + + + + The iontype ID for each ion that was assigned to each ion during + the randomization of the ionlabels. Iontype labels are just permuted + but the total number of values for each iontype remain the same. + + The order matches the iontypes array from a given ranging results + as it is specified in the configuration settings inside the specific + config_filename that was used for this paraprobe-spatstat analysis. + + + + + + + + K-nearest neighbor statistics. + + + + Right boundary of the binning. + + + + + + + + + + + + + Cumulated not normalized by total counts. + + + + + + + + Cumulated and normalized by total counts. + + + + + + + + + Radial distribution statistics. + + + + Right boundary of the binning. + + + + + + + + + + + + + Cumulated not normalized by total counts. + + + + + + + + Cumulated and normalized by total counts. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml index 260eb720a7..4967f33cf3 100644 --- a/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml @@ -238,10 +238,26 @@ for eventually performed preprocessing--> - - +profiling--> + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml index 21263ce12f..bff43a5efd 100644 --- a/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml @@ -288,6 +288,22 @@ dim: (i,) # one would not need to constrain this but doing so communicates that + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml index e3a51e8e3e..118aa0f728 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml @@ -20,7 +20,7 @@ NXapm_paraprobe_clusterer_results(NXobject): # tasks cameca_to_nexus(NXapm_paraprobe_tool_results): exists: optional - spatial_statisticsID(NXapm_paraprobe_tool_results): + cluster_analysisID(NXapm_paraprobe_tool_results): exists: [min, 0, max, infty] analysis_identifier(NX_UINT): config(NXserialized): @@ -173,6 +173,21 @@ NXapm_paraprobe_clusterer_results(NXobject): unit: NX_UNITLESS dim: (n_feat,) # ADD FURTHER RESULTS along the same pattern for e.g. OPTICS and HDBSCAN + # profiling + programID(NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + profiling(NXcs_profiling): + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + status(NX_CHAR): + current_working_directory(NX_CHAR): + total_elapsed_time(NX_NUMBER): + exists: optional + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): # global userID(NXuser): exists: [min, 0, max, infty] diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml index 522a3872eb..b6f3dad0c7 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml @@ -104,6 +104,21 @@ NXapm_paraprobe_distancer_results(NXobject): # triangles in this case mask(NX_UINT): dim: (n_tri,) + # profiling + programID(NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + profiling(NXcs_profiling): + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + status(NX_CHAR): + current_working_directory(NX_CHAR): + total_elapsed_time(NX_NUMBER): + exists: optional + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): # global userID(NXuser): exists: [min, 0, max, infty] diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml index 3ab78bab32..2987dc277d 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml @@ -242,7 +242,7 @@ NXapm_paraprobe_spatstat_config(NXobject): dim: (3,) # NEW ISSUE: ripleyk(NXcollection): # NEW ISSUE: two_point(NXcollection): - # profiling (only for stored in the first instance) + # profiling (only stored in the first instance of spatial_statistics) programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml index 985b36194c..2cb0a284f6 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml @@ -86,6 +86,21 @@ NXapm_paraprobe_spatstat_results(NXobject): Cumulated and normalized by total counts. unit: NX_DIMENSIONLESS dim: (j,) + # profiling + programID(NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + profiling(NXcs_profiling): + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + status(NX_CHAR): + current_working_directory(NX_CHAR): + total_elapsed_time(NX_NUMBER): + exists: optional + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): # global userID(NXuser): exists: [min, 0, max, infty] diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml index 74691ef271..43b001657b 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml @@ -161,6 +161,21 @@ NXapm_paraprobe_surfacer_results(NXobject): dim: (n_f_tet_xdmf,) # TRIANGLE_SET_WRAPPING(NXprocess): # For the future as we may wish to wrap primitives other like triangles or polylines. + # profiling + programID(NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + profiling(NXcs_profiling): + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + status(NX_CHAR): + current_working_directory(NX_CHAR): + total_elapsed_time(NX_NUMBER): + exists: optional + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): # global userID(NXuser): exists: [min, 0, max, infty] diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml index 752f12a268..02e6de963e 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml @@ -195,6 +195,21 @@ NXapm_paraprobe_tessellator_results(NXobject): dim: (n_ions,) bitdepth(NX_UINT): mask(NX_UINT): + # profiling + programID(NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + profiling(NXcs_profiling): + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + status(NX_CHAR): + current_working_directory(NX_CHAR): + total_elapsed_time(NX_NUMBER): + exists: optional + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): # global userID(NXuser): exists: [min, 0, max, infty] From 364a77d1642494ffbd3016e9319083016a97cf0c Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Mon, 12 Feb 2024 14:50:45 +0100 Subject: [PATCH 0553/1012] Makes sensor scan an appdef again (#168) --- contributed_definitions/NXsensor_scan.nxdl.xml | 12 ++++++------ contributed_definitions/nyaml/NXsensor_scan.yaml | 2 +- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/contributed_definitions/NXsensor_scan.nxdl.xml b/contributed_definitions/NXsensor_scan.nxdl.xml index 13aaef6794..00ef3e3300 100644 --- a/contributed_definitions/NXsensor_scan.nxdl.xml +++ b/contributed_definitions/NXsensor_scan.nxdl.xml @@ -1,10 +1,10 @@ - + - + Variables used to set a common size for collected sensor data. @@ -123,7 +123,7 @@ NXsensor groups. Similarly, seperate NXsensor groups are used to store the readings from each measurement sensor. - For example, in a temperature-dependent IV measurement, the temperature and voltage must be + For example, in a temperature-dependent IV measurement, the temperature and voltage must be present as independently scanned controllers and the current sensor must also be present with its readings. diff --git a/contributed_definitions/nyaml/NXsensor_scan.yaml b/contributed_definitions/nyaml/NXsensor_scan.yaml index fd0237e7c7..0eea319826 100644 --- a/contributed_definitions/nyaml/NXsensor_scan.yaml +++ b/contributed_definitions/nyaml/NXsensor_scan.yaml @@ -1,4 +1,4 @@ -category: base +category: application doc: | Application definition for a generic scan using sensors. From 23722e27950dfd64204fe4aad0d0b4217cc84b8e Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 13 Feb 2024 13:32:28 +0100 Subject: [PATCH 0554/1012] Renaming the last two missing appdefs for tools nanochem and intersector in preparation for their refactoring for APM v2 --- ...ector.nxdl.xml => NXapm_paraprobe_intersector_config.nxdl.xml} | 0 ...ctor.nxdl.xml => NXapm_paraprobe_intersector_results.nxdl.xml} | 0 ...nanochem.nxdl.xml => NXapm_paraprobe_nanochem_config.nxdl.xml} | 0 ...anochem.nxdl.xml => NXapm_paraprobe_nanochem_results.nxdl.xml} | 0 ...g_intersector.yaml => NXapm_paraprobe_intersector_config.yaml} | 0 ..._intersector.yaml => NXapm_paraprobe_intersector_results.yaml} | 0 ..._config_nanochem.yaml => NXapm_paraprobe_nanochem_config.yaml} | 0 ...esults_nanochem.yaml => NXapm_paraprobe_nanochem_results.yaml} | 0 8 files changed, 0 insertions(+), 0 deletions(-) rename contributed_definitions/{NXapm_paraprobe_config_intersector.nxdl.xml => NXapm_paraprobe_intersector_config.nxdl.xml} (100%) rename contributed_definitions/{NXapm_paraprobe_results_intersector.nxdl.xml => NXapm_paraprobe_intersector_results.nxdl.xml} (100%) rename contributed_definitions/{NXapm_paraprobe_config_nanochem.nxdl.xml => NXapm_paraprobe_nanochem_config.nxdl.xml} (100%) rename contributed_definitions/{NXapm_paraprobe_results_nanochem.nxdl.xml => NXapm_paraprobe_nanochem_results.nxdl.xml} (100%) rename contributed_definitions/nyaml/{NXapm_paraprobe_config_intersector.yaml => NXapm_paraprobe_intersector_config.yaml} (100%) rename contributed_definitions/nyaml/{NXapm_paraprobe_results_intersector.yaml => NXapm_paraprobe_intersector_results.yaml} (100%) rename contributed_definitions/nyaml/{NXapm_paraprobe_config_nanochem.yaml => NXapm_paraprobe_nanochem_config.yaml} (100%) rename contributed_definitions/nyaml/{NXapm_paraprobe_results_nanochem.yaml => NXapm_paraprobe_nanochem_results.yaml} (100%) diff --git a/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml similarity index 100% rename from contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml rename to contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml diff --git a/contributed_definitions/NXapm_paraprobe_results_intersector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml similarity index 100% rename from contributed_definitions/NXapm_paraprobe_results_intersector.nxdl.xml rename to contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml diff --git a/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml similarity index 100% rename from contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml rename to contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml diff --git a/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml similarity index 100% rename from contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml rename to contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml similarity index 100% rename from contributed_definitions/nyaml/NXapm_paraprobe_config_intersector.yaml rename to contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml similarity index 100% rename from contributed_definitions/nyaml/NXapm_paraprobe_results_intersector.yaml rename to contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml similarity index 100% rename from contributed_definitions/nyaml/NXapm_paraprobe_config_nanochem.yaml rename to contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml similarity index 100% rename from contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml rename to contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml From 7892cf9ce4d06d290a0a9f99ddbe901ee166342d Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 16 Feb 2024 01:06:40 +0100 Subject: [PATCH 0555/1012] Refactored config files for nanochem and intersector to use APMv2 --- .../NXapm_paraprobe_clusterer_config.nxdl.xml | 2 +- ...Xapm_paraprobe_intersector_config.nxdl.xml | 287 +- .../NXapm_paraprobe_nanochem_config.nxdl.xml | 1744 +++++------ .../NXapm_paraprobe_clusterer_config.yaml | 2 +- .../NXapm_paraprobe_intersector_config.yaml | 634 +--- .../NXapm_paraprobe_nanochem_config.yaml | 2681 +++++------------ 6 files changed, 1738 insertions(+), 3612 deletions(-) diff --git a/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml index d4703601d7..2f79008073 100644 --- a/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml @@ -53,7 +53,7 @@ n_disjoint_clusters: Number of disjoint cluster.--> - + diff --git a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml index f8de608ff4..febaa9d769 100644 --- a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. - Configuration of a paraprobe-intersector tool run in atom probe microscopy. + Application definition for a configuration file of the paraprobe-intersector tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - + + + - + - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - + - ISO 8601 formatted time code with local time zone offset to - UTC information included when this configuration file was created. + How many v_v_spatial_correlation tasks should the tool execute. - + - For now a support field for the tool to identify how many individual - analyses the tool should execute as part of the analysis. - - - - - Tracking volume_volume_spatial_correlation is the process of building logical - relations between volumetric features based on meshes, their proximity and - eventual intersections. Volumetric overlap and proximity of volumetric - features is identified for members of sets of features to members of - other sets of volumetric features. - Specifically, for each time step k pairs of sets are compared: + Tracking volume_volume_spatial_correlations (v_v) is the process of building logical + relations between objects, their proximity and eventual volumetric intersections. + Here, objects are assumed to be represented as a set of triangulated surface meshes. + + Volumetric overlap and proximity of volumetric features is identified for members of + sets of features to members of other sets of volumetric features. Specifically, for each time + step :math:`$k$` pairs of sets are compared: Members of a so-called current_set to members of a so-called next_set. Members can be different types of volumetric features. - In the analysis of M. Kuehbach et al. specifically features can be - so-called objects (closed non-degnerated polyhedra representing watertight - parts of an e.g. iso-surface) and/or proxies. Proxies are computed - doppelganger/replacement meshes for parts of an iso-surface which initially - were not resulting in watertight meshes because objects at the edge - of the dataset or incompletely measured or truncated objects. - + + Specifies the method whereby to decide if two objects intersect volumetrically. - For reasons which are detailed in the supplementary material of - `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_, the tool by - default assumes that two objects intersect if they share at least one - ion with the same evaporation ID (shared_ion). - Alternatively, with specifying tetrahedra_intersections, - the tool can perform an intersection analysis which attempts to - tetrahedralize first each polyhedron. If successful, the tool then checks - for at least one pair of intersecting tetrahedra to identify if two objects - intersect or not. + For reasons which are detailed in the supplementary material of `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_, + it is assumed by default that two objects intersect if they share at least one ion with the same evaporation ID (shared_ion). + + Alternatively, with specifying tetrahedra_intersections, the tool can perform an intersection analysis which attempts to + tetrahedralize first each polyhedron. If successful, the tool then checks for at least one pair of intersecting tetrahedra + to identify if two objects intersect or not. However, we found that these geometrical analyses can result in corner + cases which the tetrahedralization library used in the tests (TetGen) was not unable to tetrahedralize successfully. + These cases were virtually always associated with complicated non-convex polyhedra which had portions + of the mesh that were connected by almost point like tubes of triangles. - However, we found that these geometrical analyses can result in corner - cases which the currently used library (TetGen) was not unable to - tetrahedralize successfully. These cases were virtually always - associated with complicated non-convex polyhedra which had portions - of the mesh that were connected by almost point like tubes of triangles. - Finding more robust methods for computing intersections between - not necessarily convex polyhedra might improve the situation in the future. + Finding more robust methods for computing intersections between not necessarily convex polyhedra might improve + the situation in the future. For practical reasons we have thus deactivated the functionality of tetrahedra-tetrahedron + intersections in paraprobe-intersector. @@ -135,47 +80,40 @@ unless it is explicitly specified differently--> - Specifies if the tool evaluates if for each pair the two objects - (and proxies if used) intersect volumetrically. + Specifies if the tool evaluates if objects intersect volumetrically. - Specifies if the tool evaluates if for each pair the two objects - (and proxies if used) lie closer to one another than the + Specifies if the tool evaluates if objects lay closer to one another than threshold_proximity. - Specifies if the tool evaluates, ones all tracking tasks were - successfully completed, how intersecting or proximity related - objects build sub-graphs. This is the feature which enabled - M. Kühbach et al. 2022 the high-throughput analyses of how many - objects are coprecipitates in the sense that they are single, - duplet, triplet, or high-order. For these analyses to work - has_object_volume needs to be activated. + Specifies if the tool evaluates, provided that all (preprocessing tasks were successful), how intersecting + or proximity related objects build sub-graphs. This is the feature that was used in `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_ + for the high-throughput analyses of how many objects are coprecipitates in the sense that they are single, + duplet, triplet, or high-order local groups. + - The maximum Euclidean distance between two objects below which - both objects are still considered within proximity. + The maximum Euclidean distance between two objects below which they are + considered within proximity. - - Specifies if the tool stores the so-called forward relations between - nodes representing members of the current_set to nodes representing - members of the next_set. + Specifies if the tool stores the so-called forward relations between nodes representing members of the + current_set to nodes representing members of the next_set. - Specifies if the tool stores the so-called backward relations between - nodes representing members of the next_set to nodes representing - members of the current_set. + Specifies if the tool stores the so-called backward relations between nodes representing members of the + next_set to nodes representing members of the current_set. @@ -187,20 +125,15 @@ unless it is explicitly specified differently--> - This identifier can be used to label the current set. The label - effectively represents (can be interpreted as) the time/iteration - step when the current set was taken. As it is detailed in `M. Kühbach - et al. 2022 <https://arxiv.org/abs/2205.13510>`_, this identifier - takes the role of the time variable :math:`k`. + This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`$k$`) + step when the current set was taken (see `M. Kühbach et al. 2022 <https://arxiv.org/abs/2205.13510>`_). - + - The total number of distinguished feature sets FEATURE. - It is assumed that the members within all these FEATURE sets + The total number of distinguished feature sets featureID. + It is assumed that the members within all these featureID sets are representing a set together. As an example this set might represent all volumetric_features. However, users might have formed a subset of this set where individuals were regrouped. @@ -210,12 +143,16 @@ unless it is explicitly specified differently--> Similarly, proxies are distinguished further into those far from and those close to the edge of the dataset. So while these four sub-sets contain different so-called types of - features key is that they were all generated for one set, here the + features, key is that they were all generated for one set, here the current_set. - - + + + Name of the (NeXus)/HDF5 file which contains triangulated surface meshes of the + members of the set as instances of NXcg_polyhedron_set. + + Descriptive category explaining what these features are. @@ -226,31 +163,21 @@ unless it is explicitly specified differently--> - + + + + + - Name of the (NeXus)/HDF5 file which contains triangulated - surface meshes of the members of the set as instances of - NXcg_polyhedron_set. - - - - - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - - - - - - String whereby the path to the geometry data can be interferred automatically. - Currently groupname_geometry_prefix/object<ID>/polyhedron. + Absolute path to the group with geometry data in the HDF5 file referred to by + path. + - Array of identifier whereby the path to the geometry data - can be interferred automatically. + Array of identifier whereby the path to the geometry data can be interferred + automatically. @@ -258,7 +185,7 @@ unless it is explicitly specified differently--> - + Next set stores a set of members, meshes of volumetric features, which will be checked for proximity and/or volumetric intersection, @@ -267,20 +194,15 @@ unless it is explicitly specified differently--> - This identifier can be used to label the next_set. The label - effectively represents (can be interpreted as) the time/iteration - step when the current set was taken. As it is detailed in `M. Kühbach - et al. 2022 <https://arxiv.org/abs/2205.13510>`_, this identifier - takes the role of the time variable :math:`k + 1`. + This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`$k+1$`) + step when the current set was taken (see `M. Kühbach et al. 2022 <https://arxiv.org/abs/2205.13510>`_). - + - The total number of distinguished feature sets FEATURE. - It is assumed that the members within all these FEATURE sets + The total number of distinguished feature sets featureID. + It is assumed that the members within all these featureID sets are representing a set together. As an example this set might represent all volumetric_features. However, users might have formed a subset of this set where individuals were regrouped. @@ -294,8 +216,8 @@ unless it is explicitly specified differently--> next_set. - - + + Descriptive category explaining what these features are. @@ -306,43 +228,42 @@ unless it is explicitly specified differently--> - + + + + + - Name of the (NeXus)/HDF5 file which contains triangulated - surface meshes of the members of the set as instances of - NXcg_polyhedron_set. - - - - - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - - - - - - String whereby the path to the geometry data can be interferred automatically. - Currently groupname_geometry_prefix/object<ID>/polyhedron. + Absolute path to the group with geometry data in the HDF5 file referred to by + path. + - Array of identifier whereby the path to the geometry data - can be interferred automatically. + Array of identifier whereby the path to the geometry data can be interferred + automatically. - + - - - - + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml index 9b2564cf71..2c4dbd0e1a 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -46,98 +46,98 @@ How many DCOM iterations. - + Maximum number of atoms per molecular ion. - Configuration of a paraprobe-nanochem tool run in atom probe microscopy. + Application definition for a configuration file of the paraprobe-nanochem tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - + + + - + - + + - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. + Discretization and distributing of the ion point cloud on a 3D grid + to enable continuum-scale analyses. By default the tool computes a full + kernel density estimation of decomposed ions to create one discretized + field for each element. - + + + + + + + + + + + + + + + + + + + - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. + A precomputed triangulated surface mesh representing a model (of the surface) + of the edge of the dataset. This model can be used to detect and control + various sources of bias in the analyses. - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - ISO 8601 formatted time code with local time zone offset to - UTC information included when this configuration file was created. - - - - - How many individual analyses should the tool execute as part of the analysis. - - - - - - + + + + + + + Absolute path in the (HDF5) file that points to the array + of vertex positions for the triangles in that triangle_set. + - - - - - - + + + Absolute path in the (HDF5) file that points to the array + of vertex indices for the triangles in that triangle_set. + - - - - + + + Distance between each ion and triangulated surface mesh. + + + + + + + + + - - - + + + - + @@ -145,970 +145,846 @@ - + - + + + - + + + - - + + + + - + - - + + + + + + - The tool enables to inject a previously computed triangle soup or - triangulated surface mesh representing a model (of the surface) of - the edge of the dataset. This model can be used to detect and control - various sources of bias in the analyses. + Compute delocalization or load an existent one from input. + + + + + + + + + Serialized result of an already computed delocalization which is for performance + reasons here just loaded and not computed again. + type(NX_CHAR): - - + + + + + - Name of the HDF5 file which contains vertex coordinates and facet - indices to describe the desired set of triangles which represents - the edge of the dataset. + Absolute path in the (HDF5) file that points to the group within which + individual delocalization results are stored. - - - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - - - + + + + + Matrix of nuclides representing how iontypes should be accounted for during + the delocalization. This is the most general approach to define if and how many + times an ion is to be counted. The tool performs a so-called atomic decomposition + of all iontypes, i.e. the tool analyses from how many atoms of each nuclide + or element respectively an (molecular) ion is built from. + + Taking the hydroxonium H3O+ molecular ion as an example: + It contains hydrogen and oxygen atoms. The multiplicity of hydrogen + is three whereas that of oxygen is one. Therefore, the respective atomic decomposition + analysis prior to the iso-surface computation adds three hydrogen counts for each + H3O+ ion. + + This is a practical solution which accepts that on the one hand not every bond is + broken during an atom probe experiment but also that ions may react further during + their flight to the detector. The exact details depend on the local field conditions, + quantum mechanics of possible electron transfer and thus the detailed trajectory + of the system and its electronic state. + + The detection of molecular ions instead of always single atom ions only is the + reason that an atom probe experiment tells much about field evaporation physics + but also faces an inherent loss of information with respect to the detailed spatial + arrangement that is independent of other imprecisions such as effect of limited + accuracy of reconstruction protocols and their parameterization. + + Unused values in each row of the matrix are nullified. + Nuclides are identified as hashed nuclide (see :ref:`NXion`) for further details. + + + + + + + + + Edge length of the cubic cells used for discretizing the reconstructed dataset + on a cuboidal 3D grid (:ref:`NXcg_grid`). + + + + + Half the width of a :math:`{(2 \cdot n + 1)}^3` cubic kernel of cubic voxel + beyond which the Gaussian Ansatz function will be truncated. Intensity outside + the kernel is factorized into the kernel via a normalization procedure. + + + + + Variance of the Gaussian Ansatz kernel (:math:`\sigma_x = \sigma_y = 2 \cdot + \sigma_z` holds). + + + + + How should the results of the kernel-density estimation be normalized into quantities. + By default, the tool computes the total number (intensity) of ions or elements. + Alternatively, the tool can compute the total intensity, the composition, + or the concentration of the ions/elements specified by the nuclide_whitelist. + + + + + + + + + + + Specifies if the tool should report the delocalization 3D field values. + + + + + Configuration of the set of iso-surfaces to compute using that delocalization. + Such iso-surfaces are the starting point for a reconstruction of so-called objects or + (microstructual) features. Examples of scientific relevant are (line features e.g. dislocations + poles, surface features such as interfaces, i.e. phase and grain boundaries, or volumetric + features such as precipitates. + Users should be aware that reconstructed datasets in atom probe are a model and may face + inaccuracies and artifacts that can be mistaken incorrectly as microstructural features. + + - Absolute path to the HDF5 dataset in the respectively specified HDF5 - file under filename which details the array of vertex positions. + As it is detailed in `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_, the handling of + triangles at the surface (edge) of the dataset requires special attention especially for + composition-normalized delocalization. Here, it is possible that the composition + increases towards the edge of the dataset because the quotient of two numbers + that are both smaller than one is larger instead of smaller than the counter. + + By default, the tool uses a modified marching cubes algorithm of Lewiner et al. + which detects if voxels face such a situation. In this case, no triangles are generated + for such voxels. + + Alternatively, keep_edge_triangles instructs the tool to not remove triangles at the + edge of the dataset at the cost of bias. When using this keep_edge_triangles users + should understand that all features in contact with the edge of the dataset get usually + artificial enlarged. Consequently, triangulated surface meshes of these objects are + closed during the marching. However, this closure is artificial and can biased shape + analyses for those objects. This also holds for such practices that are offered in + proprietary software like IVAS / AP Suite. The situation is comparable to analyses + of grain shapes via orientation microscopy from electron microscopy or X-ray + diffraction tomography. Features at the edge of the dataset may have not been + captured fully. + + Thanks to collaboration with V. V. Rielli and S. Primig from the Sydney atom probe group, + paraprobe-nanochem implements a complete pipeline to process features at the edge of the + dataset. Specifically, these are modelled and replaced with closed polyhedral objects using + an iterative mesh and hole-filling procedures with fairing operations. + + The tool bookkeeps such objects separately to lead the decision whether or not to + consider these objects to the user. Users should be aware that results from fairing operations + should be compared to results from analyses where all objects at the edge + of the dataset have been removed. Furthermore, users should be careful with overestimating + the statistical significance of their dataset especially when using atom probe when they + use their atom probe result to compare different descriptors. Even though a dataset may + deliver statistically significant results for compositions, this does not necessarily mean that + same dataset will also yield statistically significant and insignificantly biased results for + 3D object analyses! + + Being able to quantify these effects and making atom probers aware of these subtleties + was one of the main reasons why the paraprobe-nanochem tool was implemented. + + + + - + - Absolute path to the HDF5 dataset in the respective specified HDF5 - file under filename which details the array of facet indices. + The ion-to-surface distance that is used in the analyses of features to identify whether + these are laying inside the dataset or close to the surface (edge) of the dataset. + + If an object has at least one ion with an ion-to-surface-distance below this threshold, + the object is considered close to the edge of the dataset. The tool uses a distance-based + approach to solve the in general complicated and involved treatment of computing + volumetric intersections between closed 2-manifolds that are not necessarily convex. + The main practical reason is that such computational geometry analyses face numerical + robustness issues as a consequence of which a mesh can be detected as being completely + inside another mesh although in reality it is only :math:`\epsilon`-close only, i.e. almost + touching only the edge (e.g. from inside). + + Practically, humans would likely still state in such case that the object is close to the + edge of the dataset; however mathematically the object is indeed completely inside. + In short, a distance-based approach is rigorous and flexible. - - - - The tool enables to inject precomputed distance information for each - point/ion which can be used for further post-processing and analysis. - - - + - Name of an HDF5 file which contains the ion distances. + Iso-contour values. For each value, the tool computes an iso-surface and performs + subsequent analyses for each iso-surface. The unit depends on the choice for the + normalization of the accumulated ion intensity values per voxel: + + * total, total number of ions, irrespective their iontype + * candidates, total number of ions with type in the isotope_whitelist. + * composition, candidates but normalized by composition, i.e. at.-% + * concentration, candidates but normalized by voxel volume, i.e. ions/nm^3 - - - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - - - + - Absolute HDF5 path to the dataset with distance values for each ion. + Specifies if the tool should report the triangle soup which represents each triangle of the + iso-surface complex. The resulting set of triangles is colloquially referred to as a soup + because different sub-set may not be connected. + + Each triangle is reported with an ID specifying to which triangle cluster (with IDs starting at zero) + the triangle belongs. The clustering of triangles within the soup is performed with a + modified DBScan algorithm. - - - - - - Discretization of the ion point cloud on a three-dimensional grid. - - + - Delocalization in the field of atom probe microscopy is the process - of discretizing a point cloud. By default the tool computes a full - kernel density estimation of decomposed ions to create one discretized - field for each element. + Specifies if the tool should analyze for each cluster of triangles how they can be combinatorially + processed to describe a closed polyhedron. Such a closed polyhedron (not-necessarily convex!) + can be used to describe objects with relevance in the microstructure. + + Users should be aware that the resulting mesh does not necessarily represent the original precipitate. + In fact, inaccuracies in the reconstructed positions cause inaccuracies in all downstream processing + operations. Especially the effect on one-dimensional spatial statistics like nearest neighbor correlation + functions were discussed in the literature `B. Gault et al. <https://doi.org/10.1017/S1431927621012952>`_. - Although, this uses an efficient multithreaded algorithm, - the computation is costly. Therefore, it can be advantageous for users - to load an already computed delocalization. This can be achieved with - the load_existent option. - When using this option the user is responsible to assure that the - settings which were used for computing this already existent delocalization - are specified in the same manner as they were. + In continuation of these thoughts, this applies also to reconstructed objects. + A well-known example is the discussion of shape deviations of scandium-rich precipitates in aluminium alloys + which in reconstructions may appear as ellipsoids although they should be indeed almost spherical + provided their size is larger than the atomic length scale. - - - - - - - + - Matrix of isotope vectors representing iontypes. - The filter specifies a matrix of isotope_vectors which is the most - general approach to define if and how many times an ion is counted. - Currently, paraprobe_nanochem performs a so-called atomic decomposition - of all iontypes. Specifically, the tool interprets of how many - elements/atoms a molecular ion is composed; and thus determines the - atoms multiplicity with respect to the iontype. + Specifies if the tool should report a triangulated surface mesh for each identified closed polyhedron. + It is common that a marching cubes algorithm creates iso-surfaces with a fraction of tiny sub-complexes + (e.g. small isolated tetrahedra). - Let's take the hydroxonium H3O+ molecular ion as an example: - It contains hydrogen and oxygen as atoms. The multiplicity of hydrogen - is three whereas that of oxygen is one. Therefore in an atomic - decomposition computation of the iso-surface each H3O+ ion adds - three hydrogen counts. This is a practical solution which accepts - the situation that during an atom probe experiment not each bond - of each ion/a group of neighboring atoms is broken but molecular - ions get detected. The exact ab-initio details depend on the local - field conditions and thus also the detailed spatial arrangement - of the atoms and their own electronic state and that of the neighbors - before and upon launch. - Being able to measure the information for such sites only as - molecular ions causes an inherent information loss with respect to the - detailed spatial arrangement. This information loss is more relevant - for local electrode atom probe than for field ion microscopy setting - how precisely the atomic positions can be reconstructed. - Accounting for multiplicities assures that at least the - compositional information is analyzed. + These can be small tetrahedra/polyhedra about the center of a voxel of the support grid + on which marching cubes operates. Such objects may not contain an ion; especially when considering + that delocalization procedures smoothen the positions of the ions. Although these small objects are + interesting from a numerical point of view, scientists may argue they are not worth to be reported because + a microstructural feature should contain at least a few atoms to become relevant. + Therefore, paraprobe-nanochem by default does not report closed objects which bound a volume + that contains no ion. - - - - - + - List of individual grid resolutions to analyse. - Paraprobe discretizes on a cuboidal 3D grid with cubic cells, with - an edge length of values in gridresolutions. + Specifies if the tool should report properties of each closed polyhedron, such + as volume and other details. - - + - Half the width of a :math:`{(2 \cdot n + 1)}^3` cubic kernel of voxel - beyond which the Gaussian Ansatz function will be truncated. - Intensity beyond the kernel is refactored into the kernel via - a normalization procedure. + Specifies if the tool should report for each closed polyhedron an approximately optimal bounding box + fitted to all triangles of the surface mesh of the object and ion positions inside or on the surface of the mesh. + This bounding box informs about the closed object's shape (aspect ratios). + + Users should be aware that the choice of the algorithm to compute the bounding box can have an + effect on aspect ratio statistics. It is known that computing the true optimal bounding box of in 3D + is an :math:`\mathcal{O}^3`-time-complex task. The tool uses well-established approximate algorithms + of the Computational Geometry Algorithms Library (CGAL). - + - Variance of the Gaussian Ansatz kernel :math:`\sigma_x = \sigma_y = 2 \cdot - \sigma_z`. + Specifies if the tool should report for each closed polyhedron all evaporation IDs of those ions which + lay inside or on the boundary of the polyhedron. This information is used by the paraprobe-intersector + tool to infer if two objects share common ions, which is then understood as that the two objects intersect. + + Users should be aware that two arbitrarily closed polyhedra in three-dimensional space can intersect + but not share a common ion. In fact, the volume bounded by the polyhedron has sharp edges and flat + face(t)s. When taking two objects, an edge of one object may for instance pierce into the surface of + another object. In this case the objects partially overlap / intersect volumetrically; however this piercing + might be so small or happening in the volume between two reconstructed ion positions. Consequently, + sharing ions is a sufficient but not a necessary condition for interpreting (volumetric) intersections + between objects. + + Paraprobe-intersector implements a rigorous alternative to handle such intersections using a tetrahedralization + of closed objects. However, in many practical cases, we found through examples that there are polyhedra (especially when they are non-convex and have almost point-like) connected channels, where + tetrahedralization libraries have challenges dealing with. In this case, checking intersections + via shared_ions is a more practical alternative. - - + - How should the results of the kernel-density estimation be computed - into quantities. By default the tool computes the total number - (intensity) of ions or elements. Alternatively the tool can compute - the total intensity, the composition, or the concentration of the - ions/elements specified by the white list of elements in each voxel. + Specifies if the tool should report if a (closed) object has contact with the surface aka edge of the dataset. + For this the tool currently inspects if the shortest distance between the set of triangles of the triangulated + surface mesh and the triangles of the edge model is larger than edge_threshold. + If this is the case, the object is assumed to be deeply embedded in the interior of the dataset. + Otherwise, the object is considered to have an edge contact, i.e. it shape is likely affected by the edge. - - - - - - - + - Specifies if the tool should report the delocalization 3D field values. + Specifies if the tool should analyze a closed polyhedron (aka proxy) for each cluster of triangles whose + combinatorial analysis according to has_object returned that the object is not a closed polyhedron. + Such proxies are closed via iterative hole-filling, mesh refinement, and fairing operations. + + Users should be aware that the resulting mesh does not necessarily represent the original feature. + In most cases objects, precipitates in atom probe end up as open objects because they have been + clipped by the edge of the dataset. Using a proxy is in this case a strategy to still be able to account + for these objects. However, users should make themselves familiar with the consequences and + potential biases which this can introduce into the analysis. - - - + - Optional computation of iso-surfaces after each computed delocalization - to identify for instance objects in the microstructure - (line features, interfaces, precipitates). + Like has_object_geometry but for the proxies. - - - As it is detailed in M. Kühbach et al. 2022 npj Comp. Mat., - the handling of triangles at the edge of the dataset requires - special attention. Especially for composition-normalized - delocalization it is possible that the composition increases - towards the edge of the dataset because the quotient of two numbers - which are both smaller than one is larger instead of smaller than - the counter. By default, the tool uses a modified marching cubes - algorithm of Lewiner et al. which detects if voxels face such a - situation. In this case, no triangles are generated for such voxels. - Alternatively, (via setting keep_edge_triangles) the user can - instruct the tool to not remove these triangles at the cost of bias. - - Specifically, in this case the user should understand that all - objects/microstructural features in contact with the edge of the - dataset get usually artificial enlarged and their surface mesh - often closed during the marching. This closure however is artificial! - It can result in biased shape analyses for those objects. - The reason why this should in general be avoided is a similar - argument as when one analyzes grain shapes in orientation microscopy - via e.g. SEM/EBSD. Namely, these grains, here the objects at the - edge of the dataset, were not fully captured during e.g. limited - field of view. - Therefore, it is questionable if one would like to make - substantiated quantitative statements about them. - - Thanks to collaboration with the V. V. Rielli and S. Primig, though, - paraprobe-nanochem implements a complete pipeline to - process even these objects at the edge of the dataset. Specifically, - the objects are replaced by so-called proxies, i.e. replacement - objects whose holes on the surface mesh have been closed if possible - via iterative mesh and hole-filling procedures with fairing operations. - In the results of each paraprobe-nanochem run, these proxy objects - are listed separately to allow users to quantify and analyze in - detail the differences when accounting for these objects or not. - Especially this is relevant in atom probe microscopy as objects - can contain a few dozen atoms only. - Users should be aware that results from fairing operations should - be compared to results from analyses where all objects at the edge - of the dataset have been removed. - - Also users should be careful with overestimating the statistical - significance of their dataset especially when using atom probe - to compare multiple descriptors: Even though a dataset may give - statistically significant results for compositions, this does not - necessarily mean it will yield also statistically significant - and unbiased results for three-dimensional object analyses. - Being able to quantify these effects and making atom probers - aware of these subtleties was one of the main reasons why the - paraprobe-nanochem tool was implemented. - - - - - - - - - The ion-to-edge-distance that is used in the analyses of objects - (and proxies) to identify whether these are inside the dataset or - close to the edge of the dataset. If an object has at least one ion - with an ion-to-edge-distance below this threshold, the object is - considered as one which lies close to the edge of the dataset. - This implements essentially a distance-based approach to solve - the in general complicated and involved treatment of computing - volumetric intersections between not-necessarily convex - closed 2-manifolds. In fact, such computational geometry analyses - can face numerical robustness issues as a consequence of which a - mesh can be detected as lying completely inside a dataset although - in reality it is epsilon-close only, i.e. almost touching only - the edge (e.g. from inside). - Practically, humans would state in such case that the object is - close to the edge of the dataset; however mathematically the object - is indeed completely inside. - In short, a distance-based approach is rigorous and more flexible. - - - - - - Array of iso-contour values. For each value the tool computes - an iso-surface and performs subsequent analyses. - The unit depends on the choice for the normalization of the - accumulated ion intensity values per voxel: - - * total, total number of ions, irrespective their iontype - * candidates, total number of ions with type in the isotope_whitelist. - * composition, candidates but normalized by composition, i.e. at.-% - * concentration, candidates but normalized by voxel volume, i.e. ions/nm^3 - - - - - - Specifies if the tool should report the triangle soup which represents - each triangle of the iso-surface complex. - Each triangle is reported with an ID specifying to which triangle - cluster (with IDs starting at zero) the triangle belongs. - The clustering is performed with a modified DBScan algorithm. - - - - - Specifies if the tool should analyze for each cluster of triangles - how they can be combinatorially processed to describe a closed - polyhedron. Such a closed polyhedron (not-necessarily convex!) - can be used to describe objects with relevance in the microstructure. - Users should be aware that the resulting mesh does not necessarily - represent the original precipitate. In fact, inaccuracies in the - reconstructed positions cause inaccuracies in all downstream - processing operations. Especially the effect on one-dimensional - spatial statistics like nearest neighbor correlation functions these - effects were discussed in the literature - `B. Gault et al. <https://doi.org/10.1017/S1431927621012952>`_ - In continuation of these thoughts this applies also to reconstructed - objects. A well-known example is the discussion of shape deviations - of Al3Sc precipitates in aluminium alloys which in reconstructions - can appear as ellipsoids although they should be almost spherical, - depending on their size. - - - - - Specifies if the tool should report a triangulated surface mesh - for each identified closed polyhedron. It is common that a - marching cubes algorithm creates iso-surfaces with a fraction of very - small sub-complexes (e.g. small isolated tetrahedra). - - These can be for instance be small tetrahedra/polyhedra about the - center of a voxel of the support grid on which marching cubes operates. - When these objects are small, it is possible that they contain no ion; - especially when considering that delocalization procedures smoothen - the positions of the ions. Although these small objects are interesting - from a numerical point of view, scientists may argue they are not worth - to be reported: - Physically a microstructural feature should contain at least a few - atoms to become relevant. Therefore, paraprobe-nanochem by default - does not report closed objects which bound not at least one ion. - - - - - Specifies if the tool should report properties of each closed - polyhedron, such as volume and other details. - - - - - Specifies if the tool should report for each closed polyhedron an - approximately optimal bounding box fitted to all triangles of the - surface mesh of the object and ion positions inside or on the - surface of the mesh. - This bounding box informs about the closed object's shape - (aspect ratios). - - - - - - Specifies if the tool should report for each closed polyhedron - all evaporation IDs of those ions which lie inside or on the - boundary of the polyhedron. This information can be used e.g. - in the paraprobe-intersector tool to infer if two objects share - common ions, which can be interpreted as an argument to assume - that the two objects intersect. - - Users should be aware that two arbitrarily closed polyhedra - in three-dimensional space can intersect but not share a common ion. - In fact, the volume bounded by the polyhedron has sharp edges. - When taking two objects, an edge of one object may for instance - pierce into the surface of another object. In this case the - objects partially overlap / intersect volumetrically; - however this piercing might be so small or happening in the volume - between two ion positions and thus sharing ions is a sufficient - but not a necessary condition for object intersections. - - Paraprobe-intersector implements a rigorous alternative to handle - such intersections using a tetrahedralization of closed objects. - However, in many practical cases, we found through examples that there - are polyhedra (especially when they are non-convex and have almost - point-like) connected channels, where tetrahedralization libraries - have challenges dealing with. In this case checking intersections - via shared_ions is a more practical alternative. - - - - - Specifies if the tool should report if a (closed) object has - contact with the edge of the dataset. For this the tool currently - inspects if the shortest distance between the set of triangles of the - surface mesh and the triangles of the edge model is larger than the - edge_threshold. If this is the case, the object is assumed to be - deeply embedded in the interior of the dataset. Otherwise, the object - is considered to have an edge contact, i.e. it is likely affected - by the fact that the dataset is finite. - - - - - - Specifies if the tool should analyze a doppelganger/proxy mesh for - each cluster of triangles whose combinatorial analysis according - to has_object showed that the object is not a closed polyhedron. - Such proxies are closed via iterative hole-filling, mesh refinement, - and fairing operations. - Users should be aware that the resulting mesh does not necessarily - represent the original precipitate. In most cases objects, - like precipitates in atom probe end up as open objects because - they have been clipped by the edge of the dataset. Using a proxy is - then a strategy to still be able to account for these objects. - Nevertheless users should make themselves familiar with the - potential consequences and biases which this can introduce - into the analysis. - - - - - Like has_object_geometry but for the proxies. - - - - - Like has_object_properties but for the proxies. - - - - - Like has_object_obb but for the proxies. - - - - - Like has_object_ions but for the proxies. - - - - - Like has_object_edge_contact but for the proxies. - - - - - Specifies if the tool should report for each closed object a - (cylindrical) region of interest placed, centered, and align - with the local normal for each triangle of the object. - - - - - Specifies if the tool should report for each ROI that was placed - at a triangle of each object if this ROI intersects the edge of - the dataset. Currently paraprobe-nanochem supports cylindrical - ROIs. A possible intersection of these with the edge of the - dataset, i.e. the triangulated surface mesh model for the edge - is performed. This test checks if the cylinder intersects with - a triangle of the surface mesh. If this is the case, the ROI is - assumed to make edge contact, else, the ROI is assumed to have - no edge contact. - - This approach does not work if the ROI would be completely - outside the dataset. Also in this case there would be - no intersection. For atom probe this case is practically - irrelevant because for such a ROI there would also be no ion - laying inside the ROI. Clearly it has thus to be assumed that - the edge model culls the entire dataset. Instead, if one would - cut a portion of the dataset, compute an edge model for this - point cloud, it might make sense to place a ROI but in this - case the edge contact detection is not expected to work properly. - - - - - + + - Analyses of interfacial excess. + Like has_object_properties but for the proxies. - - - Interfacial excess computations are performed for local regions-of-interests - (ROIs) at selected facets or interface patch. - For instance many scientist compute the interfacial excess for - selected triangle facets of a created iso-surface. In this case, - computed iso-surfaces of paraprobe could be used. An example are triangle - facet sets about closed polyhedra, for instance to compute interfacial - excess related to phase boundaries of second-phase precipitates. - - Another example are free-standing triangle patches of the iso- - surfaces which paraprobe creates. These could be characterized - for interfacial excess. The sub-routines during iso-surface - computations already include a procedure to automatically align - local triangle normals based on the gradients of e.g. composition - fields. In this case, these triangulated surface patches - could also be used as a source for computing interfacial - excess. - - Often scientists face situations, though, in which there is no - immediately evident composition gradient across the interface - (grain or phase boundary) and orientation information about the - adjoining crystal is neither available nor reliable enough. - - In this case `P. Felfer et al. <https://doi.org/10.1016/j.ultramic.2015.06.002>`_ proposed a method - to manually place control points and run an automated tessellation-based - algorithm to create a triangulated surface patch, i.e. a model of the - location of the interface. In a post-processing step this triangle - set can then be used to compute again interfacial excess in an - automated manner by placing ROIs and aligning them with - consistently precomputed triangle normals. - - A similar use case is conceptually the one proposed by `X. Zhou et al. <https://doi.org/10.1016/j.actamat.2022.117633>`_ - They used first a deep-learning method to locate planar triangulated - grain boundary patches. These are eventually processed further - with manual editing of the mesh via tools like Blender. - Once the user is satisfied with the mesh, the computations of interfacial - excess reduce again to an automated placing of ROIs, computations - of the distributing of ions to respective ROIs and - reporting the findings via plotting. - - Yet another approach for constructing an triangulated surface patch - of an interface is to use point cloud processing methods which have - been proposed in the laser-scanning, geoinformatics, and CAD community. - Different computational geometry methods are available for fitting - a parameterized surface to a set of points, using e.g. non-uniform - rational B-splines (NURBS) and triangulating these according - to prescribed mesh quality demands. - - The advantage of these methods is that they can be automated and - pick up curved interface segments. The disadvantage is their often - strong sensitivity to parameterization. As a result also such methods - can be post-processed to yield a triangulated surface patch, - and thus enable to run again automated ROI placement methods. - For example like these which were explored for the use case of - iso-surfaces with closed objects and free-standing - surface patches that delineate regions of the dataset with a - pronounced composition gradient normal to the interface. - - This summary of the situations which atom probers can face when - requesting for interfacial excess computations, substantiates there - exists a common set of settings which can describe all of these methods - and, specifically, as here exemplified, the automated placing - and alignment functionalities for ROIs that is an important - step all these workflows. - - Specifically, paraprobe-nanochem operates on an already existent - triangle set. - - - - - - - - - - The interface model is the result of a previous (set of) processing - steps as a result of which the user has created a triangulated - surface mesh (or a set of, eventually connected such meshes). - These interface models are useful, if not required, in cases when - there is no other independent approach to locate an interface. - - These are cases when insufficient crystallographic latent - information is available and also no consistent concentration - gradient detectable across the interface. It is then the users' - responsibility to deliver a triangle mesh of the interface model. - - - - Filename to HDF5 file which contain vertex coordinates, facet indices, - facet unit normals. The user is responsible for the triangle - and winding order to be consistent. - Input is expected as a matrix of the coordinates for all disjoint - vertices, a (Nvertices, 3)-shaped array of NX_FLOAT. - Input is expected to include also a matrix of facet indices - referring to these disjoint vertices. This matrix should be a - (Nfacets, 3)-shaped array of NX_UINT. Further required input - is a (Nfacets, 3)-shaped array of NX_FLOAT signed facet unit - normals and a (Nvertices, 3)-shaped array of NX_FLOAT signed - vertex unit normals. Vertex indices need to start at zero and - must not exceed Nvertices - 1, i.e. the identifier_offset is 0 - and facet indices are indexed implicitly, i.e. [0, Nvertices-1]. - - - - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional - layer of reproducibility from which file specifically - contains these data. - - - - - - Absolute HDF5 path to the dataset which specifies the - array of vertex positions. - - - - - Absolute HDF5 path to the dataset which specifies the - array of facet indices. - - - - - Absolute HDF5 path to the dataset which specifies the - array of facet signed unit normals. - - - - - Absolute HDF5 path to the dataset which specifies the - array of vertex signed unit normals. - - Users should be aware that triangulated surface meshes are - only approximations to a given complex, eventually curved shape. - Consequently, computations of normals show differences between - the vertex and facet normals. Vertex normals have to be - interpolated from normals of neighboring facets. Consequently, - these normals are affected by the underlying parameterization - and curvature estimation algorithms, irrespective of how - contributions from neighboring facets are weighted. By contrast, - facet normals are clearly defined by the associated triangle. - Their disadvantage is that they the normal field has discontinuities - at the edges. In general the coarser an object is triangulated - the more significant the difference becomes between computations - based on facet or vertex normals. - Paraprobe-nanochem works with facet normals as it can use - parts of the numerical performance gained by using cutting - edge libraries to work rather with finer meshes. - - - - - - - - Create a simple principle component analysis (PCA) to mesh a - free-standing interface patch through a point cloud of decorating solutes. - These models can be useful for quantification of Gibbsian - interfacial excess for interfaces where iso-surface based methods - may fail or closed objects from iso-surfaces are not desired or - when e.g. there are no substantial or consistently oriented - concentration gradients across the interface patch. - - The interface_meshing functionality of paraprobe-nanochem can be useful - when there is also insufficient latent crystallographic information - available that could otherwise support modelling the interface, - via e.g. ion density traces in field-desorption maps, as were used and - discussed by `Y. Wei et al. <https://doi.org/10.1371/journal.pone.0225041>`_ - or are discussed by `A. Breen et al. <https://github.com/breen-aj/detector>`_ - - It is noteworthy that the method here used is conceptually very similar - in implementation to the work by `Z. Peng et al. <https://doi.org/10.1017/S1431927618016112>`_ - Noteworthy, her team uses the DCOM approach originally proposed by P. Felfer et al. - However, both of these previous works neither discuss in detail - nor implement inspection functionalities which enable a detection of - potential geometric inconsistencies or self-interactions of the - resulting DCOM mesh. This is what paraprobe-nanochem implements - via the Computational Geometry Algorithms Library. - - + + - Method how to initialize the PCA: - - * default, means based on segregated solutes in the ROI - * control_point_file, means based on reading an external list of - control points, currently coming from the Leoben APT_Analyzer. - - The control_point_file is currently expected with a specific format. - The Leoben group lead by L. Romaner has developed a GUI tool `A. Reichmann et al. <https://github.com/areichm/APT_analyzer>`_ - to create a control_point_file which can be parsed by paraprobe-parmsetup - to match the here required formatting in control_points. + Like has_object_obb but for the proxies. - - - - - + - The name of the control point file to use. + Like has_object_ions but for the proxies. - - - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional - layer of reproducibility from which file specifically - contains these data. - - - + - X, Y, Z coordinates of disjoint control point read from - an HDF5 file named according to control_point_file. + Like has_object_edge_contact but for the proxies. - - - - - - + - Method used for identifying and refining the location of the - interface. Currently, paraprobe-nanochem implements a PCA followed - by an iterative loop of isotropic mesh refinement and DCOM step(s), - paired with self-intersection detection in a more robust - implementation. + Specifies if the tool should report for each closed object a (cylindrical) region-of-interest (ROI) that gets + placed, centered, and aligned with the local normal for each triangle of the object. - - - - + - Specify the types of those ions which decorate the interface and - can thus be assumed as markers for locating the interface and - refining its local curvature. + Specifies if the tool should report for each ROI that was placed at a triangle of each object if this ROI intersects + with the edge the dataset. Currently, the tool supports cylindrical ROIs. A computational geometry test is + performed to check for a possible intersection of each ROI with the triangulated surface mesh that is defined + via surface. Results of this cylinder-set-of-triangles intersection are interpreted as follows: + If the cylinder intersects with at least one triangle of the surface (mesh) the ROI is assumed to make edge contact. + Otherwise, the ROI is assumed to make no edge contact. + + Users should note that this approach does not work if the ROI is laying completely outside the dataset as also + in this case the cylinder intersects with any triangle. However, for atom probe this case is practically irrelevant + provided constructions such as alpha shapes or alpha wrappings (such as paraproeb-surfacer does) about the + ions of the entire reconstructed volume are used. - - - Array of iontypes to filter. The list is interpreted as a whitelist, - i.e. ions of these types are considered the decorating species (solutes). - - - - - - - + + + + + + + + + + + + + + + + + Use a principle component analysis (PCA) to mesh a single free-standing interface patch within + the reconstructed volume that is decorated by ions of specific iontypes (e.g. solute atoms). + + Interface_meshing is a typical starting point for the quantification of Gibbsian interfacial excess + in cases when closed objects constructed from patches e.g. iso-surfaces are not available or + when there is no substantial or consistently oriented concentration gradients across an interface + patch. The functionality can also be useful when the amount of latent crystallographic information + within the point cloud is insufficient or when combined with interface_meshing based on ion density + traces in field-desorption maps (see `Y. Wei et al. <https://doi.org/10.1371/journal.pone.0225041>`_ + and `A. Breen et al. <https://github.com/breen-aj/detector>`_ for details). + + Noteworthy to mention is that the method used is conceptually similar to the work of `Z. Peng et al. <https://doi.org/10.1017/S1431927618016112>`_ and related work (DCOM algorithm) by `P. Felfer et al. <https://doi.org/10.1016/j.ultramic.2015.06.002>`_. Compared to these implementations + paraprobe-nanochem uses inspection functionalities which detect potential geometric + inconsistencies or self-interactions of the evolved DCOM mesh. + + + + + + + + + + + + + + + + + + + + + A precomputed triangulated surface mesh representing a model (of the surface) + of the edge of the dataset. This model can be used to detect and control + various sources of bias in the analyses. + + + + + + - How many times should the DCOM and mesh refinement be applied? + Absolute path in the (HDF5) file that points to the array + of vertex positions for the triangles in that triangle_set. - + - Array of decreasing positive not smaller than one nanometer real values - which specify how the initial triangles of the mesh should be iteratively - refined by edge splitting and related mesh refinement operations. + Absolute path in the (HDF5) file that points to the array + of vertex indices for the triangles in that triangle_set. - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + How is the PCA initialized: + + * default, means based on segregated solutes in the ROI + * control_point_file, means based on reading an external list of + control points, currently coming from the Leoben APT_Analyzer. + + The control_point_file is currently expected with a specific format. + The Leoben group lead by L. Romaner has developed a GUI tool `A. Reichmann et al. <https://github.com/areichm/APT_analyzer>`_ creates a control_point_file that + can be parsed by paraprobe-parmsetup-nanochem to match the here required + formatting in control_points. + + + + + + + + + Details about the control point file used. + + + + + + - Array of decreasing positive not smaller than one nanometer real values - which specify the radius of the spherical region of interest within - which the DCOM algorithm decides for each vertex how the vertex will - be eventually relocated. The larger the DCOM radius is relative to - the target_edge_length the more likely it is that vertices will be - relocated so substantially that eventually triangle self-intersections - can occur. If the code detects these it warns and stops in a - controlled manner so that the user can repeat the analyses - with a smaller value. + Absolute path in the HDF5 control point file pointed to by path which contains + the X, Y, Z position matrix of disjoint control points. - - - - - + + + + Method used for identifying and refining the location of the interface. Currently, + paraprobe-nanochem implements a PCA followed by an iterative loop of isotropic + mesh refinement and DCOM step(s), paired with self-intersection detection. + + + + + + + + Specify the types of those ions that decorate the interface and can thus be assumed + to serve as useful markers for locating the interface and refining the interface mesh. + + + + + + + - Array of integers which specify for each DCOM step how many times - the mesh should be iteratively smoothened. - - Users should be aware the three array target_edge_length, - target_dcom_radius, and target_smoothing_step are interpreted in the - same sequence, i.e. the zeroth entry of each array specifies the - values to be used in the first DCOM iteration. The first entry of - each array those for the second DCOM iteration and so on and so forth. + Array of iontypes to filter. - + - + - Functionalities for placing regions-of-interest (ROIs) in the dataset - or at specific microstructural features to characterize composition - profiles and cumulated profiles for quantification of interfacial excess. - Paraprobe-nanochem currently places cylindrical ROIs. ROIs are probed - across the triangulated surface of a user-defined mesh. - ROIs are placed at the barycenter of the triangular facet. - - The tool can be instructed to orient the profile for each ROIs with - the positive normal of the triangle facet normals. Profiles are - computed for each ROI and facet triangle. The code will test which - ROIs are completely embedded in the dataset. - Specifically, in this test the tool evaluates if the ROI cuts at least - one triangle of the triangulated surface mesh of the edge of the dataset. - If this is the case the ROI will be considered close to the edge - (of the dataset) and not analyzed further; else the ROI will be - processed further. - Users should be aware that the latter intersection analysis is strictly - speaking not a volumetric intersection analysis as such one is much - more involved because the edge model can be a closed non-convex polyhedron - in which case one would have to test robustly if the cylinder pierces - or is laying completely inside the polyhedron. For this the polyhedron has - to be tessellated into convex polyhedra as otherwise tests like the - Gilbert-Johnson-Keerthi algorithm would not be applicable. - - Specifically, the tool computes atomically decomposed profiles. - This means molecular ions are split into atoms/isotopes with respective - multiplicity. As an example an H3O+ molecular ion contains three - hydrogen and one oxygen atom respectively. The tool then evaluates - how many ions are located inside the ROI or on the surface of the - ROI respectively. All atom types and the unranged ions are distinguished. - As a result, the analyses yield for each ROI a set of sorted lists of - signed distance values. Currently, the distance is the projected - distance of the ion position to the barycenter of the triangle - and triangle plane. + How many times should the DCOM and mesh refinement be applied? + + + + + Array of decreasing positive not smaller than one nanometer real values + which specify how the initial triangles of the mesh should be iteratively + refined by edge splitting and related mesh refinement operations. + + + + + + + + Array of decreasing positive not smaller than one nanometer real values + which specify the radius of the spherical region of interest within which the + DCOM algorithm decides for each vertex how the vertex might be relocated. - This will return a one-dimensional profile. Post-processing the set - of atom-type-specific profiles into cumulated profiles enable the - classical Krakauer/Seidman-style interfacial excess analyses. - Furthermore, the tool can be instructed to compute for each - (or a selected sub-set of facet) a set of differently oriented profiles. + The larger it is the DCOM radius in relation to the target_edge_length the more + likely it becomes that vertices will be relocated so substantially that triangle + self-intersections may occur. The tool detects these and stops in a controlled + manner so that the user can repeat the analyses with using a different parameterization. + + + + + + + + Array of integers which specify for each DCOM step how many times the mesh + should be iteratively smoothened. Users should be aware that all three arrays + target_edge_length, target_dcom_radius, and target_smoothing_step are interpreted + in the same sequence, i.e. the zeroth entry of each array specifies the respective + parameter values to be used in the first DCOM iteration. The first entry of each array + those for the second DCOM iteration and so on and so forth. + + + + + + + + + + + + + + + + + + + + Analysis of one-dimensional profiles in ROIs placed in the dataset. Such analyses are useful for quantifying + interfacial excess or classical composition analyses. The tool will test for each ROIs if it is completely embedded + in the dataset. Specifically, in each such test the tool evaluates if the ROI cuts at least one triangle of the triangulated surface mesh refered to by surface. If this is the case the ROI is close to the surface and not analyzed further. + Otherwise, the ROI is processed further. + + Users should be aware that the latter intersection analysis is not a volumetric intersection analysis as such one + is much more computationally involved because the edge model can be a closed non-convex polyhedron + in which case one would have to test robustly if the cylinder pierces or is laying completely inside the polyhedron. + For this the polyhedron has to be tessellated first into convex polyhedra, as test for volumetric intersection using + the Gilbert-Johnson-Keerthi algorithm (GJK) are applicable only to convex polyhedra. + + For each ROI the tool computes atomically decomposed profiles. This means, molecular ions are split into + nuclides with respective multiplicity. For each processed ROI a set of a sorted list of signed distance values + is returned to enable classical Krakauer/Seidman-style interfacial excess analyses. + + + + + + + + + + + + + + + + + + + + + A precomputed triangulated surface mesh representing a model (of the surface) + of the edge of the dataset. This model can be used to detect and control + various sources of bias in the analyses. - - + + + + + - The feature mesh enables the injection of previously computed triangle - soup or mesh data. Such a mesh can be the model for a grain- or phase - boundary patch (from e.g. interface_meshing) jobs. + Absolute path in the (HDF5) file that points to the array + of vertex positions for the triangles in that triangle_set. - - - Name of the HDF5 file which contains vertex coordinates and facet - indices to describe the desired set of triangles which represents - the feature. - - - - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - - - - - - Absolute path to the HDF5 dataset in the respectively specified HDF5 - file under filename which details the array of vertex positions. - - - - - Absolute path to the HDF5 dataset in the respective specified HDF5 - file under filename which details the array of facet indices. - - - - - Absolute path to the HDF5 dataset in the respective specified HDF5 - file under filename which details consistently oriented facet - normals of the facets. - - - - - - - - - + + - The tool enables to inject precomputed distance information for each - point which can be used for further post-processing and analysis. + Absolute path in the (HDF5) file that points to the array + of vertex indices for the triangles in that triangle_set. - - - - Name of an HDF5 file which contains ion distances. - - - - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional - layer of reproducibility from which file specifically contains - these data. - - - - - - Absolute HDF5 path to the dataset with distance values for each ion. - - + + + + + Distance between each ion and triangulated surface mesh. + + + + + + + + + + + + + + + + + + + + + + + - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Interfacial excess computations are performed for ROIs at selected facets or a triangulated interface patch + obtained from e.g. a previous interface_mesh processing. + + For instance many scientist compute the interfacial excess for selected triangle facets of an iso-surface. + In this case, computed iso-surfaces of paraprobe could be used. An example are triangle facet sets about + closed polyhedra, for instance to compute interfacial excess related to phase boundaries of second-phase precipitates. + + Another example are free-standing triangle patches of the iso-surfaces which paraprobe creates. + These could be characterized for interfacial excess. The sub-routines during iso-surface computations + already include a procedure to automatically align local triangle normals based on the gradients of + e.g. composition fields. + + Often scientists face situations in which neither a significant composition gradient across an interface + (grain or phase boundary) exists nor latent crystallographic information about the adjoining crystal is + available or reliable enough. + + In this case `P. Felfer et al. <https://doi.org/10.1016/j.ultramic.2015.06.002>`_ proposed a method to manually place control points and run an automated tessellation-based algorithm to create a triangulated surface patch, + i.e. a model of the location of the interface. In a post-processing step, this triangle set can then be used to + compute again interfacial excess in an automated manner by placing ROIs and aligning these with consistently oriented triangle normals. + + A similar use case is conceptually the one proposed by `X. Zhou et al. <https://doi.org/10.1016/j.actamat.2022.117633>`_ who used first a deep-learning method to locate planar triangulated grain boundary patches. These are eventually processed further with manual editing of the mesh via tools like Blender. Once the user is satisfied with the mesh, the computations of interfacial excess reduce again to an automated placing of ROIs, computations of the distributing of ions to respective ROIs, and plotting the results. + + Another approach for constructing an triangulated surface patch of an interface is to use point cloud processing methods that have been proposed in the laser-scanning, geoinformatics, and CAD community. Different computational geometry methods exist for fitting a parameterized surface to a set of points, using e.g. + non-uniform rational B-splines (NURBS) and triangulating these according to prescribed mesh quality demands. + The advantage of these methods is that they are fully automatable and pick up curved interface segments. + The disadvantage is their often strong sensitivity on the parameterization. + + In all aforementioned cases except an interface_mesh is generated on which the here proposed method + can be applied. In summary, a given an interfacial_excess analysis takes an interface_mesh, places ROIs + automatically and evaluates the spatial distribution of ions as a function of the signed distance to the interface + patch. + + + + + + + + + + + + + - Which type of distance should be reported for the profile. + Absolute HDF5 path to the dataset that specifies the array of vertex positions. - - - - - + - In which directions should the tool probe for each ROI. + Absolute HDF5 path to the dataset that specifies the array of facet indices + which refer to vertices. - - - - - + - For each ROI, how high (projected on the cylinder axis) - should the cylindrical ROI be. + Absolute HDF5 path to the dataset that specifies the array of facet signed unit + normals. - - + - For each ROI, how wide (radius) should the cylindrical ROI be. + Absolute HDF5 path to the dataset that specifies the array of vertex signed unit + normals. - - - - + + + + If interface_model is isosurface this filter can be used to restrict the analysis to specific + patches of an iso-surface. + + + + + + + Which type of distance should be reported for the profile. + + + + + + + + In which directions should the tool probe for each ROI. + + + + + + + + For each ROI, how high (projected on the cylinder axis) should the cylindrical + ROI be. + + + + + For each ROI, how wide (radius) should the cylindrical ROI be. + + + + + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml index a065f8c8cf..85f4a47f37 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml @@ -20,7 +20,7 @@ NXapm_paraprobe_clusterer_config(NXobject): exists: [min, 1, max, 1] definition(NX_CHAR): \@version(NX_CHAR): - enumeration: [NXapm_paraprobe_spatstat_config] + enumeration: [NXapm_paraprobe_clusterer_config] number_of_tasks(NX_UINT): doc: | How many cluster_analysis tasks should the tool execute. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml index 1455a60b9b..2adce1f5ae 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml @@ -1,129 +1,77 @@ category: application doc: | - Configuration of a paraprobe-intersector tool run in atom probe microscopy. + Application definition for a configuration file of the paraprobe-intersector tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. type: group -NXapm_paraprobe_config_intersector(NXobject): +NXapm_paraprobe_intersector_config(NXobject): (NXentry): - - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently - \@version: + exists: [min, 1, max, 1] + definition(NX_CHAR): + \@version(NX_CHAR): + enumeration: [NXapm_paraprobe_spatstat_config] + number_of_tasks(NX_UINT): doc: | - Version specifier of this application definition. - definition: - doc: | - Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_config_intersector] - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: | - Possibility for leaving a free-text description about this analysis. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - time_stamp(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to - UTC information included when this configuration file was created. - number_of_processes(NX_UINT): + How many v_v_spatial_correlation tasks should the tool execute. unit: NX_UNITLESS + v_v_spatial_correlationID(NXapm_paraprobe_tool_config): + exists: [min, 1, max, infty] doc: | - For now a support field for the tool to identify how many individual - analyses the tool should execute as part of the analysis. - VOLUME_VOLUME_SPATIAL_CORRELATION(NXprocess): - exists: ['min', '1', 'max', 'unbounded'] - doc: | - Tracking volume_volume_spatial_correlation is the process of building logical - relations between volumetric features based on meshes, their proximity and - eventual intersections. Volumetric overlap and proximity of volumetric - features is identified for members of sets of features to members of - other sets of volumetric features. - Specifically, for each time step k pairs of sets are compared: + Tracking volume_volume_spatial_correlations (v_v) is the process of building logical + relations between objects, their proximity and eventual volumetric intersections. + Here, objects are assumed to be represented as a set of triangulated surface meshes. + + Volumetric overlap and proximity of volumetric features is identified for members of + sets of features to members of other sets of volumetric features. Specifically, for each time + step :math:`$k$` pairs of sets are compared: Members of a so-called current_set to members of a so-called next_set. - Members can be different types of volumetric features. - In the analysis of M. Kuehbach et al. specifically features can be - so-called objects (closed non-degnerated polyhedra representing watertight - parts of an e.g. iso-surface) and/or proxies. Proxies are computed - doppelganger/replacement meshes for parts of an iso-surface which initially - were not resulting in watertight meshes because objects at the edge - of the dataset or incompletely measured or truncated objects. - intersection_detection_method: + Members can be different types of volumetric features. + # config + intersection_detection_method(NX_CHAR): doc: | Specifies the method whereby to decide if two objects intersect volumetrically. - For reasons which are detailed in the supplementary material of - `M. Kühbach et al. `_, the tool by - default assumes that two objects intersect if they share at least one - ion with the same evaporation ID (shared_ion). - Alternatively, with specifying tetrahedra_intersections, - the tool can perform an intersection analysis which attempts to - tetrahedralize first each polyhedron. If successful, the tool then checks - for at least one pair of intersecting tetrahedra to identify if two objects - intersect or not. + For reasons which are detailed in the supplementary material of `M. Kühbach et al. `_, + it is assumed by default that two objects intersect if they share at least one ion with the same evaporation ID (shared_ion). - However, we found that these geometrical analyses can result in corner - cases which the currently used library (TetGen) was not unable to - tetrahedralize successfully. These cases were virtually always - associated with complicated non-convex polyhedra which had portions - of the mesh that were connected by almost point like tubes of triangles. - Finding more robust methods for computing intersections between - not necessarily convex polyhedra might improve the situation in the future. + Alternatively, with specifying tetrahedra_intersections, the tool can perform an intersection analysis which attempts to + tetrahedralize first each polyhedron. If successful, the tool then checks for at least one pair of intersecting tetrahedra + to identify if two objects intersect or not. However, we found that these geometrical analyses can result in corner + cases which the tetrahedralization library used in the tests (TetGen) was not unable to tetrahedralize successfully. + These cases were virtually always associated with complicated non-convex polyhedra which had portions + of the mesh that were connected by almost point like tubes of triangles. + + Finding more robust methods for computing intersections between not necessarily convex polyhedra might improve + the situation in the future. For practical reasons we have thus deactivated the functionality of tetrahedra-tetrahedron + intersections in paraprobe-intersector. enumeration: [shared_ion] analyze_intersection(NX_BOOLEAN): doc: | - Specifies if the tool evaluates if for each pair the two objects - (and proxies if used) intersect volumetrically. + Specifies if the tool evaluates if objects intersect volumetrically. analyze_proximity(NX_BOOLEAN): doc: | - Specifies if the tool evaluates if for each pair the two objects - (and proxies if used) lie closer to one another than the - threshold_proximity. + Specifies if the tool evaluates if objects lay closer to one another than threshold_proximity. analyze_coprecipitation(NX_BOOLEAN): doc: | - Specifies if the tool evaluates, ones all tracking tasks were - successfully completed, how intersecting or proximity related - objects build sub-graphs. This is the feature which enabled - M. Kühbach et al. 2022 the high-throughput analyses of how many - objects are coprecipitates in the sense that they are single, - duplet, triplet, or high-order. For these analyses to work - has_object_volume needs to be activated. + Specifies if the tool evaluates, provided that all (preprocessing tasks were successful), how intersecting + or proximity related objects build sub-graphs. This is the feature that was used in `M. Kühbach et al. `_ + for the high-throughput analyses of how many objects are coprecipitates in the sense that they are single, + duplet, triplet, or high-order local groups. + # For these analyses to work has_object_volume needs to be true. threshold_proximity(NX_FLOAT): - unit: NX_LENGTH doc: | - The maximum Euclidean distance between two objects below which - both objects are still considered within proximity. - - # \@units: nm + The maximum Euclidean distance between two objects below which they are considered within proximity. + unit: NX_LENGTH has_current_to_next_links(NX_BOOLEAN): doc: | - Specifies if the tool stores the so-called forward relations between - nodes representing members of the current_set to nodes representing - members of the next_set. + Specifies if the tool stores the so-called forward relations between nodes representing members of the + current_set to nodes representing members of the next_set. has_next_to_current_links(NX_BOOLEAN): doc: | - Specifies if the tool stores the so-called backward relations between - nodes representing members of the next_set to nodes representing - members of the current_set. + Specifies if the tool stores the so-called backward relations between nodes representing members of the + next_set to nodes representing members of the current_set. current_set(NXprocess): doc: | Current set stores a set of members, meshes of volumetric features, @@ -131,22 +79,15 @@ NXapm_paraprobe_config_intersector(NXobject): to members of the current_set. The meshes were generated as a result of some other meshing process. set_identifier(NX_UINT): - unit: NX_ANY doc: | - This identifier can be used to label the current set. The label - effectively represents (can be interpreted as) the time/iteration - step when the current set was taken. As it is detailed in `M. Kühbach - et al. 2022 `_, this identifier - takes the role of the time variable :math:`k`. - - # number_of_objects(NX_UINT): - # doc: For now a support field to tell the tool how many objects to load. - # unit: NX_UNITLESS + This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`$k$`) + step when the current set was taken (see `M. Kühbach et al. 2022 `_). + unit: NX_ANY + # number_of_objects(NX_UINT) for now a support field to tell the tool how many objects to load. number_of_feature_types(NX_UINT): - unit: NX_UNITLESS doc: | - The total number of distinguished feature sets FEATURE. - It is assumed that the members within all these FEATURE sets + The total number of distinguished feature sets featureID. + It is assumed that the members within all these featureID sets are representing a set together. As an example this set might represent all volumetric_features. However, users might have formed a subset of this set where individuals were regrouped. @@ -156,61 +97,48 @@ NXapm_paraprobe_config_intersector(NXobject): Similarly, proxies are distinguished further into those far from and those close to the edge of the dataset. So while these four sub-sets contain different so-called types of - features key is that they were all generated for one set, here the + features, key is that they were all generated for one set, here the current_set. - FEATURE(NXcollection): - exists: ['min', '1', 'max', '4'] - feature_type: + unit: NX_UNITLESS + featureID(NXserialized): + exists: [min, 1, max, 4] + doc: | + Name of the (NeXus)/HDF5 file which contains triangulated surface meshes of the + members of the set as instances of NXcg_polyhedron_set. + feature_type(NX_CHAR): doc: | Descriptive category explaining what these features are. enumeration: [objects_far_from_edge, objects_close_to_edge, proxies_far_from_edge, proxies_close_to_edge] - filename: - doc: | - Name of the (NeXus)/HDF5 file which contains triangulated - surface meshes of the members of the set as instances of - NXcg_polyhedron_set. - - # NEW ISSUE: make more robust checks wrt to the consistence of the datasets - \@version: - doc: | - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - groupname_geometry_prefix: + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + geometry(NX_CHAR): doc: | - String whereby the path to the geometry data can be interferred automatically. - Currently groupname_geometry_prefix/object/polyhedron. + Absolute path to the group with geometry data in the HDF5 file referred to by path. + # currently groupname_geometry_prefix/object/polyhedron. feature_identifier(NX_UINT): - unit: NX_UNITLESS doc: | - Array of identifier whereby the path to the geometry data - can be interferred automatically. - dimensions: - rank: 1 - dim: [[1, i]] - next_set(NXcollection): + Array of identifier whereby the path to the geometry data can be interferred automatically. + unit: NX_UNITLESS + dim: (i,) + next_set(NXprocess): doc: | Next set stores a set of members, meshes of volumetric features, which will be checked for proximity and/or volumetric intersection, to members of the next_set. The meshes were generated as a result of some other meshing process. set_identifier(NX_UINT): - unit: NX_ANY doc: | - This identifier can be used to label the next_set. The label - effectively represents (can be interpreted as) the time/iteration - step when the current set was taken. As it is detailed in `M. Kühbach - et al. 2022 `_, this identifier - takes the role of the time variable :math:`k + 1`. - - # number_of_objects(NX_UINT): - # doc: For now a support field to tell the tool how many objects to load. - # unit: NX_UNITLESS + This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`$k+1$`) + step when the current set was taken (see `M. Kühbach et al. 2022 `_). + unit: NX_ANY + # number_of_objects(NX_UINT) for now a support field to tell the tool how many objects to load. number_of_feature_types(NX_UINT): unit: NX_UNITLESS doc: | - The total number of distinguished feature sets FEATURE. - It is assumed that the members within all these FEATURE sets + The total number of distinguished feature sets featureID. + It is assumed that the members within all these featureID sets are representing a set together. As an example this set might represent all volumetric_features. However, users might have formed a subset of this set where individuals were regrouped. @@ -222,389 +150,35 @@ NXapm_paraprobe_config_intersector(NXobject): So while these four sub-sets contain different so-called types of features key is that they were all generated for one set, here the next_set. - FEATURE(NXcollection): - exists: ['min', '1', 'max', '4'] - feature_type: + featureID(NXserialized): + exists: [min, 1, max, 4] + feature_type(NX_CHAR): doc: | Descriptive category explaining what these features are. enumeration: [objects_far_from_edge, objects_close_to_edge, proxies_far_from_edge, proxies_close_to_edge] - filename: + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + geometry(NX_CHAR): doc: | - Name of the (NeXus)/HDF5 file which contains triangulated - surface meshes of the members of the set as instances of - NXcg_polyhedron_set. - - # NEW ISSUE: make more robust checks wrt to the consistence of the datasets - \@version: - doc: | - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - groupname_geometry_prefix: - doc: | - String whereby the path to the geometry data can be interferred automatically. - Currently groupname_geometry_prefix/object/polyhedron. + Absolute path to the group with geometry data in the HDF5 file referred to by path. + # currently groupname_geometry_prefix/object/polyhedron. feature_identifier(NX_UINT): - unit: NX_UNITLESS doc: | - Array of identifier whereby the path to the geometry data - can be interferred automatically. - dimensions: - rank: 1 - dim: [[1, j]] - - ##MK::tetrahedra volume intersection and tessellation, and Nef polyhedra intersection - ##MK::are considered guru features and therefore currently supported via modifying the C/C++ source code - performance(NXcs_profiling): - current_working_directory: - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 71b282f148e5f311dd9a3f3e1cc87d973706430edb00a844eb901dd5b8812aba -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Configuration of a paraprobe-intersector tool run in atom probe microscopy. -# -# -# -# -# -# Version specifier of this application definition. -# -# -# -# -# Official NeXus NXDL schema with which this file was written. -# -# -# -# -# -# -# -# Given name of the program/software/tool with which this NeXus -# (configuration) file was generated. -# -# -# -# Ideally program version plus build number, or commit hash or description -# of ever persistent resources where the source code of the program and -# build instructions can be found so that the program can be configured -# ideally in such a manner that the result of this computational process -# is recreatable in the same deterministic manner. -# -# -# -# -# -# Ideally, a (globally persistent) unique identifier for referring -# to this analysis. -# -# -# -# -# Possibility for leaving a free-text description about this analysis. -# -# -# -# -# Path to the directory where the tool should store NeXus/HDF5 results -# of this analysis. If not specified results will be stored in the -# current working directory. -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to -# UTC information included when this configuration file was created. -# -# -# -# -# For now a support field for the tool to identify how many individual -# analyses the tool should execute as part of the analysis. -# -# -# -# -# Tracking volume_volume_spatial_correlation is the process of building logical -# relations between volumetric features based on meshes, their proximity and -# eventual intersections. Volumetric overlap and proximity of volumetric -# features is identified for members of sets of features to members of -# other sets of volumetric features. -# Specifically, for each time step k pairs of sets are compared: -# Members of a so-called current_set to members of a so-called next_set. -# Members can be different types of volumetric features. -# In the analysis of M. Kuehbach et al. specifically features can be -# so-called objects (closed non-degnerated polyhedra representing watertight -# parts of an e.g. iso-surface) and/or proxies. Proxies are computed -# doppelganger/replacement meshes for parts of an iso-surface which initially -# were not resulting in watertight meshes because objects at the edge -# of the dataset or incompletely measured or truncated objects. -# -# -# -# Specifies the method whereby to decide if two objects intersect volumetrically. -# For reasons which are detailed in the supplementary material of -# `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_, the tool by -# default assumes that two objects intersect if they share at least one -# ion with the same evaporation ID (shared_ion). -# Alternatively, with specifying tetrahedra_intersections, -# the tool can perform an intersection analysis which attempts to -# tetrahedralize first each polyhedron. If successful, the tool then checks -# for at least one pair of intersecting tetrahedra to identify if two objects -# intersect or not. -# -# However, we found that these geometrical analyses can result in corner -# cases which the currently used library (TetGen) was not unable to -# tetrahedralize successfully. These cases were virtually always -# associated with complicated non-convex polyhedra which had portions -# of the mesh that were connected by almost point like tubes of triangles. -# Finding more robust methods for computing intersections between -# not necessarily convex polyhedra might improve the situation in the future. -# -# -# -# -# -# -# -# Specifies if the tool evaluates if for each pair the two objects -# (and proxies if used) intersect volumetrically. -# -# -# -# -# Specifies if the tool evaluates if for each pair the two objects -# (and proxies if used) lie closer to one another than the -# threshold_proximity. -# -# -# -# -# Specifies if the tool evaluates, ones all tracking tasks were -# successfully completed, how intersecting or proximity related -# objects build sub-graphs. This is the feature which enabled -# M. Kühbach et al. 2022 the high-throughput analyses of how many -# objects are coprecipitates in the sense that they are single, -# duplet, triplet, or high-order. For these analyses to work -# has_object_volume needs to be activated. -# -# -# -# -# The maximum Euclidean distance between two objects below which -# both objects are still considered within proximity. -# -# -# -# -# -# Specifies if the tool stores the so-called forward relations between -# nodes representing members of the current_set to nodes representing -# members of the next_set. -# -# -# -# -# Specifies if the tool stores the so-called backward relations between -# nodes representing members of the next_set to nodes representing -# members of the current_set. -# -# -# -# -# Current set stores a set of members, meshes of volumetric features, -# which will be checked for proximity and/or volumetric intersection, -# to members of the current_set. -# The meshes were generated as a result of some other meshing process. -# -# -# -# This identifier can be used to label the current set. The label -# effectively represents (can be interpreted as) the time/iteration -# step when the current set was taken. As it is detailed in `M. Kühbach -# et al. 2022 <https://arxiv.org/abs/2205.13510>`_, this identifier -# takes the role of the time variable :math:`k`. -# -# -# -# -# -# The total number of distinguished feature sets FEATURE. -# It is assumed that the members within all these FEATURE sets -# are representing a set together. As an example this set might represent -# all volumetric_features. However, users might have formed -# a subset of this set where individuals were regrouped. -# For paraprobe-nanochem this is the case for objects and proxies. -# Specifically, objects are distinguished further into those far -# from and those close to the edge of the dataset. -# Similarly, proxies are distinguished further into those far -# from and those close to the edge of the dataset. -# So while these four sub-sets contain different so-called types of -# features key is that they were all generated for one set, here the -# current_set. -# -# -# -# -# -# Descriptive category explaining what these features are. -# -# -# -# -# -# -# -# -# -# -# Name of the (NeXus)/HDF5 file which contains triangulated -# surface meshes of the members of the set as instances of -# NXcg_polyhedron_set. -# -# -# -# -# Version identifier of the file such as a secure hash which documents -# the binary state of the file to add an additional layer of -# reproducibility from which file specifically contains these data. -# -# -# -# -# -# String whereby the path to the geometry data can be interferred automatically. -# Currently groupname_geometry_prefix/object<ID>/polyhedron. -# -# -# -# -# Array of identifier whereby the path to the geometry data -# can be interferred automatically. -# -# -# -# -# -# -# -# -# -# Next set stores a set of members, meshes of volumetric features, -# which will be checked for proximity and/or volumetric intersection, -# to members of the next_set. -# The meshes were generated as a result of some other meshing process. -# -# -# -# This identifier can be used to label the next_set. The label -# effectively represents (can be interpreted as) the time/iteration -# step when the current set was taken. As it is detailed in `M. Kühbach -# et al. 2022 <https://arxiv.org/abs/2205.13510>`_, this identifier -# takes the role of the time variable :math:`k + 1`. -# -# -# -# -# -# The total number of distinguished feature sets FEATURE. -# It is assumed that the members within all these FEATURE sets -# are representing a set together. As an example this set might represent -# all volumetric_features. However, users might have formed -# a subset of this set where individuals were regrouped. -# For paraprobe-nanochem this is the case for objects and proxies. -# Specifically, objects are distinguished further into those far -# from and those close to the edge of the dataset. -# Similarly, proxies are distinguished further into those far -# from and those close to the edge of the dataset. -# So while these four sub-sets contain different so-called types of -# features key is that they were all generated for one set, here the -# next_set. -# -# -# -# -# -# Descriptive category explaining what these features are. -# -# -# -# -# -# -# -# -# -# -# Name of the (NeXus)/HDF5 file which contains triangulated -# surface meshes of the members of the set as instances of -# NXcg_polyhedron_set. -# -# -# -# -# Version identifier of the file such as a secure hash which documents -# the binary state of the file to add an additional layer of -# reproducibility from which file specifically contains these data. -# -# -# -# -# -# String whereby the path to the geometry data can be interferred automatically. -# Currently groupname_geometry_prefix/object<ID>/polyhedron. -# -# -# -# -# Array of identifier whereby the path to the geometry data -# can be interferred automatically. -# -# -# -# -# -# -# -# -# -# -# -# -# -# + Array of identifier whereby the path to the geometry data can be interferred automatically. + unit: NX_UNITLESS + dim: (i,) + ##MK::tetrahedra volume intersection and tessellation and Nef polyhedra intersection are considered guru features + # and therefore currently supported only via modifying the C/C++ source code directly as one should know exactly + # what one is doing here before using these functionalities + # profiling (only stored in the first instance of spatial_statistics) + programID(NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + profiling(NXcs_profiling): + exists: recommended + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + current_working_directory(NX_CHAR): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml index 07fab0a79e..77fc33bfc5 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml @@ -1,6 +1,8 @@ category: application doc: | - Configuration of a paraprobe-nanochem tool run in atom probe microscopy. + Application definition for a configuration file of the paraprobe-nanochem tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -12,73 +14,82 @@ symbols: How many iontypes does the interface meshing iontype filter specify. n_fct_iterations: | How many DCOM iterations. - n_ivec: | + n_ivec_max: | Maximum number of atoms per molecular ion. type: group NXapm_paraprobe_config_nanochem(NXobject): (NXentry): - \@version: + exists: [min, 1, max, 1] + definition(NX_CHAR): + \@version(NX_CHAR): + enumeration: [NXapm_paraprobe_nanochem_config] + # number_of_tasks(NX_UINT): + # doc: | + # How many tasks should the tool execute. + # unit: NX_UNITLESS + delocalizationID(NXapm_paraprobe_tool_config): + exists: [min, 1, max, infty] doc: | - Version specifier of this application definition. - definition: - doc: | - Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_config_nanochem] - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: + Discretization and distributing of the ion point cloud on a 3D grid + to enable continuum-scale analyses. By default the tool computes a full + kernel density estimation of decomposed ions to create one discretized + field for each element. + # Although, this uses an efficient multithreaded algorithm the computation is costly. + # Therefore, it can be advantageous for users to load an already computed delocalization. + # This can be achieved with the load_existent option. + (NXidentifier): + exists: optional + analysis_identifier(NX_UINT): + exists: recommended + reconstruction(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + position(NX_CHAR): + mass_to_charge(NX_CHAR): + ranging(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + ranging_definitions(NX_CHAR): + surface(NXserialized): + exists: recommended doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: | - Possibility for leaving a free-text description about this analysis. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - time_stamp(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to - UTC information included when this configuration file was created. - number_of_processes(NX_UINT): - unit: NX_UNITLESS - doc: | - How many individual analyses should the tool execute as part of the analysis. - (NXprocess): - dataset(NXapm_input_reconstruction): - filename: - \@version: - dataset_name_reconstruction: - dataset_name_mass_to_charge: - iontypes(NXapm_input_ranging): - filename: - \@version: - group_name_iontypes: + A precomputed triangulated surface mesh representing a model (of the surface) + of the edge of the dataset. This model can be used to detect and control + various sources of bias in the analyses. + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + vertices(NX_CHAR): + doc: | + Absolute path in the (HDF5) file that points to the array + of vertex positions for the triangles in that triangle_set. + indices(NX_CHAR): + doc: | + Absolute path in the (HDF5) file that points to the array + of vertex indices for the triangles in that triangle_set. + surface_distance(NXserialized): + exists: recommended + doc: | + Distance between each ion and triangulated surface mesh. + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): spatial_filter(NXspatial_filter): - exists: optional - windowing_method: - (NXcg_ellipsoid_set): + windowing_method(NX_CHAR): + hexahedron_set(NXcg_hexahedron_set): exists: optional dimensionality(NX_POSINT): cardinality(NX_POSINT): identifier_offset(NX_INT): - center(NX_NUMBER): - half_axes_radii(NX_NUMBER): - orientation(NX_NUMBER): - (NXcg_cylinder_set): + hexahedra(NXcg_face_list_data_structure): + vertices(NX_UINT): + cylinder_set(NXcg_cylinder_set): exists: optional dimensionality(NX_POSINT): cardinality(NX_POSINT): @@ -86,1963 +97,707 @@ NXapm_paraprobe_config_nanochem(NXobject): center(NX_NUMBER): height(NX_NUMBER): radii(NX_NUMBER): - (NXcg_hexahedron_set): + ellipsoid_set(NXcg_ellipsoid_set): exists: optional dimensionality(NX_POSINT): cardinality(NX_POSINT): identifier_offset(NX_INT): - hexahedra(NXcg_face_list_data_structure): - (NXcs_filter_boolean_mask): + center(NX_NUMBER): + half_axes_radii(NX_NUMBER): + orientation(NX_NUMBER): + polyhedron_set(NXcg_polyhedron_set): + exists: optional + # TODO + bitmask(NXcs_filter_boolean_mask): exists: optional number_of_objects(NX_UINT): bitdepth(NX_UINT): mask(NX_UINT): - identifier(NX_UINT): + # leave open if scalar or matrix + # dim: (i,) + # identifier(NX_UINT): evaporation_id_filter(NXsubsampling_filter): exists: optional + min_incr_max(NX_INT): iontype_filter(NXmatch_filter): exists: optional - method: + method(NX_CHAR): match(NX_NUMBER): hit_multiplicity_filter(NXmatch_filter): exists: optional - edge_of_the_dataset(NXprocess): + method(NX_CHAR): + match(NX_NUMBER): + # config + method(NX_CHAR): doc: | - The tool enables to inject a previously computed triangle soup or - triangulated surface mesh representing a model (of the surface) of - the edge of the dataset. This model can be used to detect and control - various sources of bias in the analyses. - - # NEW ISSUE: exists: optional - filename: - doc: | - Name of the HDF5 file which contains vertex coordinates and facet - indices to describe the desired set of triangles which represents - the edge of the dataset. - \@version: - doc: | - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - dataset_name_vertices: - doc: | - Absolute path to the HDF5 dataset in the respectively specified HDF5 - file under filename which details the array of vertex positions. - dataset_name_facet_indices: - doc: | - Absolute path to the HDF5 dataset in the respective specified HDF5 - file under filename which details the array of facet indices. - ion_to_edge_distances(NXprocess): - exists: optional + Compute delocalization or load an existent one from input. + enumeration: [compute, load_existent] + input(NXserialized): doc: | - The tool enables to inject precomputed distance information for each - point/ion which can be used for further post-processing and analysis. - - # NEW ISSUE: is this optional? - filename: + Serialized result of an already computed delocalization which is for performance + reasons here just loaded and not computed again. + type(NX_CHAR): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + results(NX_CHAR): doc: | - Name of an HDF5 file which contains the ion distances. - \@version: - doc: | - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - dataset_name: - doc: | - Absolute HDF5 path to the dataset with distance values for each ion. - - # number_of_delocalizations(NX_UINT): - # doc: | - # For now a support field for the tool to identify how many individual - # delocalization analyses for the above-mentioned dataset and supplementary - # files are executed as part of the high-throughput analysis. - # unit: NX_UNITLESS - - # NEW ISSUE delocalization is all lower case meaning you cannot have right now multiple of these - # even though paraprobe-nanochem triggers a number of delocalizations for each of which triggering again isosurfaces - # currently the principal idea behind this design is that you normally focus iso-surface-based analyses - # on specific elements and for these you may have different discretization and isosurface computation demands - # for instance you might be super interested in analyzing in find details the iso-surfaces of carbon in a dataset - # but in addition you could be interested also to study chromium iso-surfaces but for completely different iso-contour values - # etc. this is what paraprobe-nanochem allows you to do - # you create one process for all your carbon related delocalizations, isosurfaces etc - # plus another process packing all your chromium delocalization and isosurfaces - delocalization(NXprocess): - exists: ['min', '0', 'max', '1'] + Absolute path in the (HDF5) file that points to the group within which + individual delocalization results are stored. + # TODO: add more descriptions + nuclide_whitelist(NX_UINT): + doc: | + Matrix of nuclides representing how iontypes should be accounted for during + the delocalization. This is the most general approach to define if and how many + times an ion is to be counted. The tool performs a so-called atomic decomposition + of all iontypes, i.e. the tool analyses from how many atoms of each nuclide + or element respectively an (molecular) ion is built from. + + Taking the hydroxonium H3O+ molecular ion as an example: + It contains hydrogen and oxygen atoms. The multiplicity of hydrogen + is three whereas that of oxygen is one. Therefore, the respective atomic decomposition + analysis prior to the iso-surface computation adds three hydrogen counts for each + H3O+ ion. + + This is a practical solution which accepts that on the one hand not every bond is + broken during an atom probe experiment but also that ions may react further during + their flight to the detector. The exact details depend on the local field conditions, + quantum mechanics of possible electron transfer and thus the detailed trajectory + of the system and its electronic state. + + The detection of molecular ions instead of always single atom ions only is the + reason that an atom probe experiment tells much about field evaporation physics + but also faces an inherent loss of information with respect to the detailed spatial + arrangement that is independent of other imprecisions such as effect of limited + accuracy of reconstruction protocols and their parameterization. + + Unused values in each row of the matrix are nullified. + Nuclides are identified as hashed nuclide (see :ref:`NXion`) for further details. + unit: NX_UNITLESS + dim: (n_ityp_deloc_cand, n_ivec_max) + grid_resolution(NX_FLOAT): + doc: | + Edge length of the cubic cells used for discretizing the reconstructed dataset + on a cuboidal 3D grid (:ref:`NXcg_grid`). + unit: NX_LENGTH + kernel_size(NX_UINT): + doc: | + Half the width of a :math:`{(2 \cdot n + 1)}^3` cubic kernel of cubic voxel + beyond which the Gaussian Ansatz function will be truncated. Intensity outside + the kernel is factorized into the kernel via a normalization procedure. + unit: NX_UNITLESS + kernel_variance(NX_FLOAT): + doc: | + Variance of the Gaussian Ansatz kernel (:math:`\sigma_x = \sigma_y = 2 \cdot + \sigma_z` holds). + unit: NX_LENGTH + normalization(NX_CHAR): doc: | - Discretization of the ion point cloud on a three-dimensional grid. - input: + How should the results of the kernel-density estimation be normalized into quantities. + By default, the tool computes the total number (intensity) of ions or elements. + Alternatively, the tool can compute the total intensity, the composition, + or the concentration of the ions/elements specified by the nuclide_whitelist. + enumeration: [total, candidates, composition, concentration] + has_scalar_fields(NX_BOOLEAN): + doc: | + Specifies if the tool should report the delocalization 3D field values. + isosurfacing(NXprocess): + exists: [min, 0, max, 1] + doc: | + Configuration of the set of iso-surfaces to compute using that delocalization. + Such iso-surfaces are the starting point for a reconstruction of so-called objects or + (microstructual) features. Examples of scientific relevant are (line features e.g. dislocations + poles, surface features such as interfaces, i.e. phase and grain boundaries, or volumetric + features such as precipitates. + Users should be aware that reconstructed datasets in atom probe are a model and may face + inaccuracies and artifacts that can be mistaken incorrectly as microstructural features. + edge_method(NX_CHAR): doc: | - Delocalization in the field of atom probe microscopy is the process - of discretizing a point cloud. By default the tool computes a full - kernel density estimation of decomposed ions to create one discretized - field for each element. + As it is detailed in `M. Kühbach et al. `_, the handling of + triangles at the surface (edge) of the dataset requires special attention especially for + composition-normalized delocalization. Here, it is possible that the composition + increases towards the edge of the dataset because the quotient of two numbers + that are both smaller than one is larger instead of smaller than the counter. - Although, this uses an efficient multithreaded algorithm, - the computation is costly. Therefore, it can be advantageous for users - to load an already computed delocalization. This can be achieved with - the load_existent option. - When using this option the user is responsible to assure that the - settings which were used for computing this already existent delocalization - are specified in the same manner as they were. - - # NEW ISSUE: improve UX experience - enumeration: [default, load_existent] - - # NEW ISSUE: base class filter - isotope_whitelist(NX_UINT): - unit: NX_UNITLESS + By default, the tool uses a modified marching cubes algorithm of Lewiner et al. + which detects if voxels face such a situation. In this case, no triangles are generated + for such voxels. + + Alternatively, keep_edge_triangles instructs the tool to not remove triangles at the + edge of the dataset at the cost of bias. When using this keep_edge_triangles users + should understand that all features in contact with the edge of the dataset get usually + artificial enlarged. Consequently, triangulated surface meshes of these objects are + closed during the marching. However, this closure is artificial and can biased shape + analyses for those objects. This also holds for such practices that are offered in + proprietary software like IVAS / AP Suite. The situation is comparable to analyses + of grain shapes via orientation microscopy from electron microscopy or X-ray + diffraction tomography. Features at the edge of the dataset may have not been + captured fully. + + Thanks to collaboration with V. V. Rielli and S. Primig from the Sydney atom probe group, + paraprobe-nanochem implements a complete pipeline to process features at the edge of the + dataset. Specifically, these are modelled and replaced with closed polyhedral objects using + an iterative mesh and hole-filling procedures with fairing operations. + + The tool bookkeeps such objects separately to lead the decision whether or not to + consider these objects to the user. Users should be aware that results from fairing operations + should be compared to results from analyses where all objects at the edge + of the dataset have been removed. Furthermore, users should be careful with overestimating + the statistical significance of their dataset especially when using atom probe when they + use their atom probe result to compare different descriptors. Even though a dataset may + deliver statistically significant results for compositions, this does not necessarily mean that + same dataset will also yield statistically significant and insignificantly biased results for + 3D object analyses! + + Being able to quantify these effects and making atom probers aware of these subtleties + was one of the main reasons why the paraprobe-nanochem tool was implemented. + enumeration: [default, keep_edge_triangles] + edge_threshold(NX_FLOAT): doc: | - Matrix of isotope vectors representing iontypes. - The filter specifies a matrix of isotope_vectors which is the most - general approach to define if and how many times an ion is counted. - Currently, paraprobe_nanochem performs a so-called atomic decomposition - of all iontypes. Specifically, the tool interprets of how many - elements/atoms a molecular ion is composed; and thus determines the - atoms multiplicity with respect to the iontype. + The ion-to-surface distance that is used in the analyses of features to identify whether + these are laying inside the dataset or close to the surface (edge) of the dataset. + + If an object has at least one ion with an ion-to-surface-distance below this threshold, + the object is considered close to the edge of the dataset. The tool uses a distance-based + approach to solve the in general complicated and involved treatment of computing + volumetric intersections between closed 2-manifolds that are not necessarily convex. + The main practical reason is that such computational geometry analyses face numerical + robustness issues as a consequence of which a mesh can be detected as being completely + inside another mesh although in reality it is only :math:`\epsilon`-close only, i.e. almost + touching only the edge (e.g. from inside). - Let's take the hydroxonium H3O+ molecular ion as an example: - It contains hydrogen and oxygen as atoms. The multiplicity of hydrogen - is three whereas that of oxygen is one. Therefore in an atomic - decomposition computation of the iso-surface each H3O+ ion adds - three hydrogen counts. This is a practical solution which accepts - the situation that during an atom probe experiment not each bond - of each ion/a group of neighboring atoms is broken but molecular - ions get detected. The exact ab-initio details depend on the local - field conditions and thus also the detailed spatial arrangement - of the atoms and their own electronic state and that of the neighbors - before and upon launch. - Being able to measure the information for such sites only as - molecular ions causes an inherent information loss with respect to the - detailed spatial arrangement. This information loss is more relevant - for local electrode atom probe than for field ion microscopy setting - how precisely the atomic positions can be reconstructed. - Accounting for multiplicities assures that at least the - compositional information is analyzed. - dimensions: - rank: 2 - dim: [[1, n_ityp_deloc_cand], [2, n_ivec]] - gridresolutions(NX_FLOAT): + Practically, humans would likely still state in such case that the object is close to the + edge of the dataset; however mathematically the object is indeed completely inside. + In short, a distance-based approach is rigorous and flexible. unit: NX_LENGTH + phi(NX_FLOAT): doc: | - List of individual grid resolutions to analyse. - Paraprobe discretizes on a cuboidal 3D grid with cubic cells, with - an edge length of values in gridresolutions. - - # \@units: nm - kernel_size(NX_UINT): - unit: NX_UNITLESS - doc: | - Half the width of a :math:`{(2 \cdot n + 1)}^3` cubic kernel of voxel - beyond which the Gaussian Ansatz function will be truncated. - Intensity beyond the kernel is refactored into the kernel via - a normalization procedure. - kernel_variance(NX_FLOAT): - unit: NX_LENGTH + Iso-contour values. For each value, the tool computes an iso-surface and performs + subsequent analyses for each iso-surface. The unit depends on the choice for the + normalization of the accumulated ion intensity values per voxel: + + * total, total number of ions, irrespective their iontype + * candidates, total number of ions with type in the isotope_whitelist. + * composition, candidates but normalized by composition, i.e. at.-% + * concentration, candidates but normalized by voxel volume, i.e. ions/nm^3 + + unit: NX_ANY + has_triangle_soup(NX_BOOLEAN): doc: | - Variance of the Gaussian Ansatz kernel :math:`\sigma_x = \sigma_y = 2 \cdot - \sigma_z`. - - # \@units: nm - normalization: + Specifies if the tool should report the triangle soup which represents each triangle of the + iso-surface complex. The resulting set of triangles is colloquially referred to as a soup + because different sub-set may not be connected. + + Each triangle is reported with an ID specifying to which triangle cluster (with IDs starting at zero) + the triangle belongs. The clustering of triangles within the soup is performed with a + modified DBScan algorithm. + has_object(NX_BOOLEAN): doc: | - How should the results of the kernel-density estimation be computed - into quantities. By default the tool computes the total number - (intensity) of ions or elements. Alternatively the tool can compute - the total intensity, the composition, or the concentration of the - ions/elements specified by the white list of elements in each voxel. - enumeration: [total, candidates, composition, concentration] - has_scalar_fields(NX_BOOLEAN): + Specifies if the tool should analyze for each cluster of triangles how they can be combinatorially + processed to describe a closed polyhedron. Such a closed polyhedron (not-necessarily convex!) + can be used to describe objects with relevance in the microstructure. + + Users should be aware that the resulting mesh does not necessarily represent the original precipitate. + In fact, inaccuracies in the reconstructed positions cause inaccuracies in all downstream processing + operations. Especially the effect on one-dimensional spatial statistics like nearest neighbor correlation + functions were discussed in the literature `B. Gault et al. `_. + + In continuation of these thoughts, this applies also to reconstructed objects. + A well-known example is the discussion of shape deviations of scandium-rich precipitates in aluminium alloys + which in reconstructions may appear as ellipsoids although they should be indeed almost spherical + provided their size is larger than the atomic length scale. + has_object_geometry(NX_BOOLEAN): doc: | - Specifies if the tool should report the delocalization 3D field values. - - # number_of_isosurfaces: - # doc: For now a support field for the tool to identify how many individual analyses the tool should execute during the analysis run. - # unit: NX_UNITLESS - - # NEW ISSUE: currently isosurface has to be a child of delocalization because otherwise - # you could construct the incorrect situation that you leave delocalization optional do not add sth there but fill isosurface - # and this does not work because without a delocalization/field quantity you cannot compute iso-surfaces - isosurfacing(NXprocess): - exists: ['min', '0', 'max', '1'] + Specifies if the tool should report a triangulated surface mesh for each identified closed polyhedron. + It is common that a marching cubes algorithm creates iso-surfaces with a fraction of tiny sub-complexes + (e.g. small isolated tetrahedra). + + These can be small tetrahedra/polyhedra about the center of a voxel of the support grid + on which marching cubes operates. Such objects may not contain an ion; especially when considering + that delocalization procedures smoothen the positions of the ions. Although these small objects are + interesting from a numerical point of view, scientists may argue they are not worth to be reported because + a microstructural feature should contain at least a few atoms to become relevant. + Therefore, paraprobe-nanochem by default does not report closed objects which bound a volume + that contains no ion. + has_object_properties(NX_BOOLEAN): doc: | - Optional computation of iso-surfaces after each computed delocalization - to identify for instance objects in the microstructure - (line features, interfaces, precipitates). - edge_handling_method: - doc: | - As it is detailed in M. Kühbach et al. 2022 npj Comp. Mat., - the handling of triangles at the edge of the dataset requires - special attention. Especially for composition-normalized - delocalization it is possible that the composition increases - towards the edge of the dataset because the quotient of two numbers - which are both smaller than one is larger instead of smaller than - the counter. By default, the tool uses a modified marching cubes - algorithm of Lewiner et al. which detects if voxels face such a - situation. In this case, no triangles are generated for such voxels. - Alternatively, (via setting keep_edge_triangles) the user can - instruct the tool to not remove these triangles at the cost of bias. - - Specifically, in this case the user should understand that all - objects/microstructural features in contact with the edge of the - dataset get usually artificial enlarged and their surface mesh - often closed during the marching. This closure however is artificial! - It can result in biased shape analyses for those objects. - The reason why this should in general be avoided is a similar - argument as when one analyzes grain shapes in orientation microscopy - via e.g. SEM/EBSD. Namely, these grains, here the objects at the - edge of the dataset, were not fully captured during e.g. limited - field of view. - Therefore, it is questionable if one would like to make - substantiated quantitative statements about them. - - Thanks to collaboration with the V. V. Rielli and S. Primig, though, - paraprobe-nanochem implements a complete pipeline to - process even these objects at the edge of the dataset. Specifically, - the objects are replaced by so-called proxies, i.e. replacement - objects whose holes on the surface mesh have been closed if possible - via iterative mesh and hole-filling procedures with fairing operations. - In the results of each paraprobe-nanochem run, these proxy objects - are listed separately to allow users to quantify and analyze in - detail the differences when accounting for these objects or not. - Especially this is relevant in atom probe microscopy as objects - can contain a few dozen atoms only. - Users should be aware that results from fairing operations should - be compared to results from analyses where all objects at the edge - of the dataset have been removed. - - Also users should be careful with overestimating the statistical - significance of their dataset especially when using atom probe - to compare multiple descriptors: Even though a dataset may give - statistically significant results for compositions, this does not - necessarily mean it will yield also statistically significant - and unbiased results for three-dimensional object analyses. - Being able to quantify these effects and making atom probers - aware of these subtleties was one of the main reasons why the - paraprobe-nanochem tool was implemented. - enumeration: [default, keep_edge_triangles] - edge_threshold(NX_FLOAT): - unit: NX_LENGTH - doc: | - The ion-to-edge-distance that is used in the analyses of objects - (and proxies) to identify whether these are inside the dataset or - close to the edge of the dataset. If an object has at least one ion - with an ion-to-edge-distance below this threshold, the object is - considered as one which lies close to the edge of the dataset. - This implements essentially a distance-based approach to solve - the in general complicated and involved treatment of computing - volumetric intersections between not-necessarily convex - closed 2-manifolds. In fact, such computational geometry analyses - can face numerical robustness issues as a consequence of which a - mesh can be detected as lying completely inside a dataset although - in reality it is epsilon-close only, i.e. almost touching only - the edge (e.g. from inside). - Practically, humans would state in such case that the object is - close to the edge of the dataset; however mathematically the object - is indeed completely inside. - In short, a distance-based approach is rigorous and more flexible. - - # \@units: nm - phi(NX_FLOAT): - unit: NX_ANY - doc: | - Array of iso-contour values. For each value the tool computes - an iso-surface and performs subsequent analyses. - The unit depends on the choice for the normalization of the - accumulated ion intensity values per voxel: - - * total, total number of ions, irrespective their iontype - * candidates, total number of ions with type in the isotope_whitelist. - * composition, candidates but normalized by composition, i.e. at.-% - * concentration, candidates but normalized by voxel volume, i.e. ions/nm^3 - - # NEW ISSUE: details what these options activate need to be described in more detail !!!!! - has_triangle_soup(NX_BOOLEAN): - doc: | - Specifies if the tool should report the triangle soup which represents - each triangle of the iso-surface complex. - Each triangle is reported with an ID specifying to which triangle - cluster (with IDs starting at zero) the triangle belongs. - The clustering is performed with a modified DBScan algorithm. - has_object(NX_BOOLEAN): - doc: | - Specifies if the tool should analyze for each cluster of triangles - how they can be combinatorially processed to describe a closed - polyhedron. Such a closed polyhedron (not-necessarily convex!) - can be used to describe objects with relevance in the microstructure. - Users should be aware that the resulting mesh does not necessarily - represent the original precipitate. In fact, inaccuracies in the - reconstructed positions cause inaccuracies in all downstream - processing operations. Especially the effect on one-dimensional - spatial statistics like nearest neighbor correlation functions these - effects were discussed in the literature - `B. Gault et al. `_ - In continuation of these thoughts this applies also to reconstructed - objects. A well-known example is the discussion of shape deviations - of Al3Sc precipitates in aluminium alloys which in reconstructions - can appear as ellipsoids although they should be almost spherical, - depending on their size. - has_object_geometry(NX_BOOLEAN): - doc: | - Specifies if the tool should report a triangulated surface mesh - for each identified closed polyhedron. It is common that a - marching cubes algorithm creates iso-surfaces with a fraction of very - small sub-complexes (e.g. small isolated tetrahedra). - - These can be for instance be small tetrahedra/polyhedra about the - center of a voxel of the support grid on which marching cubes operates. - When these objects are small, it is possible that they contain no ion; - especially when considering that delocalization procedures smoothen - the positions of the ions. Although these small objects are interesting - from a numerical point of view, scientists may argue they are not worth - to be reported: - Physically a microstructural feature should contain at least a few - atoms to become relevant. Therefore, paraprobe-nanochem by default - does not report closed objects which bound not at least one ion. - has_object_properties(NX_BOOLEAN): - doc: | - Specifies if the tool should report properties of each closed - polyhedron, such as volume and other details. - has_object_obb(NX_BOOLEAN): - doc: | - Specifies if the tool should report for each closed polyhedron an - approximately optimal bounding box fitted to all triangles of the - surface mesh of the object and ion positions inside or on the - surface of the mesh. - This bounding box informs about the closed object's shape - (aspect ratios). - - # NEW ISSUE: Addendum Alternatively it is possible to fit triaxial ellipsoids. - has_object_ions(NX_BOOLEAN): - doc: | - Specifies if the tool should report for each closed polyhedron - all evaporation IDs of those ions which lie inside or on the - boundary of the polyhedron. This information can be used e.g. - in the paraprobe-intersector tool to infer if two objects share - common ions, which can be interpreted as an argument to assume - that the two objects intersect. - - Users should be aware that two arbitrarily closed polyhedra - in three-dimensional space can intersect but not share a common ion. - In fact, the volume bounded by the polyhedron has sharp edges. - When taking two objects, an edge of one object may for instance - pierce into the surface of another object. In this case the - objects partially overlap / intersect volumetrically; - however this piercing might be so small or happening in the volume - between two ion positions and thus sharing ions is a sufficient - but not a necessary condition for object intersections. - - Paraprobe-intersector implements a rigorous alternative to handle - such intersections using a tetrahedralization of closed objects. - However, in many practical cases, we found through examples that there - are polyhedra (especially when they are non-convex and have almost - point-like) connected channels, where tetrahedralization libraries - have challenges dealing with. In this case checking intersections - via shared_ions is a more practical alternative. - has_object_edge_contact(NX_BOOLEAN): - doc: | - Specifies if the tool should report if a (closed) object has - contact with the edge of the dataset. For this the tool currently - inspects if the shortest distance between the set of triangles of the - surface mesh and the triangles of the edge model is larger than the - edge_threshold. If this is the case, the object is assumed to be - deeply embedded in the interior of the dataset. Otherwise, the object - is considered to have an edge contact, i.e. it is likely affected - by the fact that the dataset is finite. - - # the edge_threshold can be decided based on half the length of the diagonal of the delocalization kernel. - # as a consequence of which wider kernels result in larger threshold values causing more objects to become - # qualified as having edge contact. - has_proxy(NX_BOOLEAN): - doc: | - Specifies if the tool should analyze a doppelganger/proxy mesh for - each cluster of triangles whose combinatorial analysis according - to has_object showed that the object is not a closed polyhedron. - Such proxies are closed via iterative hole-filling, mesh refinement, - and fairing operations. - Users should be aware that the resulting mesh does not necessarily - represent the original precipitate. In most cases objects, - like precipitates in atom probe end up as open objects because - they have been clipped by the edge of the dataset. Using a proxy is - then a strategy to still be able to account for these objects. - Nevertheless users should make themselves familiar with the - potential consequences and biases which this can introduce - into the analysis. - has_proxy_geometry(NX_BOOLEAN): - doc: | - Like has_object_geometry but for the proxies. - has_proxy_properties(NX_BOOLEAN): - doc: | - Like has_object_properties but for the proxies. - has_proxy_obb(NX_BOOLEAN): - doc: | - Like has_object_obb but for the proxies. - has_proxy_ions(NX_BOOLEAN): - doc: | - Like has_object_ions but for the proxies. - has_proxy_edge_contact(NX_BOOLEAN): - doc: | - Like has_object_edge_contact but for the proxies. - has_object_auto_proxigram(NX_BOOLEAN): - doc: | - Specifies if the tool should report for each closed object a - (cylindrical) region of interest placed, centered, and align - with the local normal for each triangle of the object. - has_object_auto_proxigram_edge_contact(NX_BOOLEAN): - doc: | - Specifies if the tool should report for each ROI that was placed - at a triangle of each object if this ROI intersects the edge of - the dataset. Currently paraprobe-nanochem supports cylindrical - ROIs. A possible intersection of these with the edge of the - dataset, i.e. the triangulated surface mesh model for the edge - is performed. This test checks if the cylinder intersects with - a triangle of the surface mesh. If this is the case, the ROI is - assumed to make edge contact, else, the ROI is assumed to have - no edge contact. - - This approach does not work if the ROI would be completely - outside the dataset. Also in this case there would be - no intersection. For atom probe this case is practically - irrelevant because for such a ROI there would also be no ion - laying inside the ROI. Clearly it has thus to be assumed that - the edge model culls the entire dataset. Instead, if one would - cut a portion of the dataset, compute an edge model for this - point cloud, it might make sense to place a ROI but in this - case the edge contact detection is not expected to work properly. - - # has_object_mesh_smoothing(NX_BOOLEAN): - # doc: Specifies if the tool should post-process each mesh to improve the mesh quality. - # mesh_smoothing(NXprocess): - # NEW ISSUE: here we need to specify how the meshes were smoothened - ##MK::is this group not at the previous level of the hierarchy? - interfacial_excess(NXprocess): - exists: optional + Specifies if the tool should report properties of each closed polyhedron, such as volume and other details. + has_object_obb(NX_BOOLEAN): doc: | - Analyses of interfacial excess. - interface_model: - doc: | - Interfacial excess computations are performed for local regions-of-interests - (ROIs) at selected facets or interface patch. - For instance many scientist compute the interfacial excess for - selected triangle facets of a created iso-surface. In this case, - computed iso-surfaces of paraprobe could be used. An example are triangle - facet sets about closed polyhedra, for instance to compute interfacial - excess related to phase boundaries of second-phase precipitates. - - Another example are free-standing triangle patches of the iso- - surfaces which paraprobe creates. These could be characterized - for interfacial excess. The sub-routines during iso-surface - computations already include a procedure to automatically align - local triangle normals based on the gradients of e.g. composition - fields. In this case, these triangulated surface patches - could also be used as a source for computing interfacial - excess. - - Often scientists face situations, though, in which there is no - immediately evident composition gradient across the interface - (grain or phase boundary) and orientation information about the - adjoining crystal is neither available nor reliable enough. - - In this case `P. Felfer et al. `_ proposed a method - to manually place control points and run an automated tessellation-based - algorithm to create a triangulated surface patch, i.e. a model of the - location of the interface. In a post-processing step this triangle - set can then be used to compute again interfacial excess in an - automated manner by placing ROIs and aligning them with - consistently precomputed triangle normals. - - A similar use case is conceptually the one proposed by `X. Zhou et al. `_ - They used first a deep-learning method to locate planar triangulated - grain boundary patches. These are eventually processed further - with manual editing of the mesh via tools like Blender. - Once the user is satisfied with the mesh, the computations of interfacial - excess reduce again to an automated placing of ROIs, computations - of the distributing of ions to respective ROIs and - reporting the findings via plotting. - - Yet another approach for constructing an triangulated surface patch - of an interface is to use point cloud processing methods which have - been proposed in the laser-scanning, geoinformatics, and CAD community. - Different computational geometry methods are available for fitting - a parameterized surface to a set of points, using e.g. non-uniform - rational B-splines (NURBS) and triangulating these according - to prescribed mesh quality demands. - - The advantage of these methods is that they can be automated and - pick up curved interface segments. The disadvantage is their often - strong sensitivity to parameterization. As a result also such methods - can be post-processed to yield a triangulated surface patch, - and thus enable to run again automated ROI placement methods. - For example like these which were explored for the use case of - iso-surfaces with closed objects and free-standing - surface patches that delineate regions of the dataset with a - pronounced composition gradient normal to the interface. - - This summary of the situations which atom probers can face when - requesting for interfacial excess computations, substantiates there - exists a common set of settings which can describe all of these methods - and, specifically, as here exemplified, the automated placing - and alignment functionalities for ROIs that is an important - step all these workflows. - - Specifically, paraprobe-nanochem operates on an already existent - triangle set. - enumeration: [isosurface, external] - - # NEW ISSUE: how to implement and also check consistently via NeXus that a - # NEW ISSUE: child group is required only when a field has a certain value? - external(NXprocess): - exists: optional - doc: | - The interface model is the result of a previous (set of) processing - steps as a result of which the user has created a triangulated - surface mesh (or a set of, eventually connected such meshes). - These interface models are useful, if not required, in cases when - there is no other independent approach to locate an interface. - - These are cases when insufficient crystallographic latent - information is available and also no consistent concentration - gradient detectable across the interface. It is then the users' - responsibility to deliver a triangle mesh of the interface model. - file_name: - doc: | - Filename to HDF5 file which contain vertex coordinates, facet indices, - facet unit normals. The user is responsible for the triangle - and winding order to be consistent. - Input is expected as a matrix of the coordinates for all disjoint - vertices, a (Nvertices, 3)-shaped array of NX_FLOAT. - Input is expected to include also a matrix of facet indices - referring to these disjoint vertices. This matrix should be a - (Nfacets, 3)-shaped array of NX_UINT. Further required input - is a (Nfacets, 3)-shaped array of NX_FLOAT signed facet unit - normals and a (Nvertices, 3)-shaped array of NX_FLOAT signed - vertex unit normals. Vertex indices need to start at zero and - must not exceed Nvertices - 1, i.e. the identifier_offset is 0 - and facet indices are indexed implicitly, i.e. [0, Nvertices-1]. - \@version: - doc: | - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional - layer of reproducibility from which file specifically - contains these data. - dataset_name_vertices: - doc: | - Absolute HDF5 path to the dataset which specifies the - array of vertex positions. - dataset_name_facet_indices: - doc: | - Absolute HDF5 path to the dataset which specifies the - array of facet indices. - dataset_name_facet_normals: - doc: | - Absolute HDF5 path to the dataset which specifies the - array of facet signed unit normals. - dataset_name_facet_vertices: - doc: | - Absolute HDF5 path to the dataset which specifies the - array of vertex signed unit normals. - - Users should be aware that triangulated surface meshes are - only approximations to a given complex, eventually curved shape. - Consequently, computations of normals show differences between - the vertex and facet normals. Vertex normals have to be - interpolated from normals of neighboring facets. Consequently, - these normals are affected by the underlying parameterization - and curvature estimation algorithms, irrespective of how - contributions from neighboring facets are weighted. By contrast, - facet normals are clearly defined by the associated triangle. - Their disadvantage is that they the normal field has discontinuities - at the edges. In general the coarser an object is triangulated - the more significant the difference becomes between computations - based on facet or vertex normals. - Paraprobe-nanochem works with facet normals as it can use - parts of the numerical performance gained by using cutting - edge libraries to work rather with finer meshes. - interface_meshing(NXprocess): - exists: ['min', '0', 'max', '1'] - doc: | - Create a simple principle component analysis (PCA) to mesh a - free-standing interface patch through a point cloud of decorating solutes. - These models can be useful for quantification of Gibbsian - interfacial excess for interfaces where iso-surface based methods - may fail or closed objects from iso-surfaces are not desired or - when e.g. there are no substantial or consistently oriented - concentration gradients across the interface patch. - - The interface_meshing functionality of paraprobe-nanochem can be useful - when there is also insufficient latent crystallographic information - available that could otherwise support modelling the interface, - via e.g. ion density traces in field-desorption maps, as were used and - discussed by `Y. Wei et al. `_ - or are discussed by `A. Breen et al. `_ - - It is noteworthy that the method here used is conceptually very similar - in implementation to the work by `Z. Peng et al. `_ - Noteworthy, her team uses the DCOM approach originally proposed by P. Felfer et al. - However, both of these previous works neither discuss in detail - nor implement inspection functionalities which enable a detection of - potential geometric inconsistencies or self-interactions of the - resulting DCOM mesh. This is what paraprobe-nanochem implements - via the Computational Geometry Algorithms Library. - initialization: + Specifies if the tool should report for each closed polyhedron an approximately optimal bounding box + fitted to all triangles of the surface mesh of the object and ion positions inside or on the surface of the mesh. + This bounding box informs about the closed object's shape (aspect ratios). + + Users should be aware that the choice of the algorithm to compute the bounding box can have an + effect on aspect ratio statistics. It is known that computing the true optimal bounding box of in 3D + is an :math:`\mathcal{O}^3`-time-complex task. The tool uses well-established approximate algorithms + of the Computational Geometry Algorithms Library (CGAL). + has_object_ions(NX_BOOLEAN): doc: | - Method how to initialize the PCA: + Specifies if the tool should report for each closed polyhedron all evaporation IDs of those ions which + lay inside or on the boundary of the polyhedron. This information is used by the paraprobe-intersector + tool to infer if two objects share common ions, which is then understood as that the two objects intersect. - * default, means based on segregated solutes in the ROI - * control_point_file, means based on reading an external list of - control points, currently coming from the Leoben APT_Analyzer. + Users should be aware that two arbitrarily closed polyhedra in three-dimensional space can intersect + but not share a common ion. In fact, the volume bounded by the polyhedron has sharp edges and flat + face(t)s. When taking two objects, an edge of one object may for instance pierce into the surface of + another object. In this case the objects partially overlap / intersect volumetrically; however this piercing + might be so small or happening in the volume between two reconstructed ion positions. Consequently, + sharing ions is a sufficient but not a necessary condition for interpreting (volumetric) intersections + between objects. - The control_point_file is currently expected with a specific format. - The Leoben group lead by L. Romaner has developed a GUI tool `A. Reichmann et al. `_ - to create a control_point_file which can be parsed by paraprobe-parmsetup - to match the here required formatting in control_points. - enumeration: [default, control_point_file] - filename: + Paraprobe-intersector implements a rigorous alternative to handle such intersections using a tetrahedralization + of closed objects. However, in many practical cases, we found through examples that there are polyhedra (especially when they are non-convex and have almost point-like) connected channels, where + tetrahedralization libraries have challenges dealing with. In this case, checking intersections + via shared_ions is a more practical alternative. + has_object_edge_contact(NX_BOOLEAN): doc: | - The name of the control point file to use. - \@version: - doc: | - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional - layer of reproducibility from which file specifically - contains these data. - control_points(NX_FLOAT): - unit: NX_LENGTH + Specifies if the tool should report if a (closed) object has contact with the surface aka edge of the dataset. + For this the tool currently inspects if the shortest distance between the set of triangles of the triangulated + surface mesh and the triangles of the edge model is larger than edge_threshold. + If this is the case, the object is assumed to be deeply embedded in the interior of the dataset. + Otherwise, the object is considered to have an edge contact, i.e. it shape is likely affected by the edge. + has_proxy(NX_BOOLEAN): doc: | - X, Y, Z coordinates of disjoint control point read from - an HDF5 file named according to control_point_file. - - # \@units: nm - dimensions: - rank: 2 - dim: [[1, N], [2, n_control_pts]] - method: + Specifies if the tool should analyze a closed polyhedron (aka proxy) for each cluster of triangles whose + combinatorial analysis according to has_object returned that the object is not a closed polyhedron. + Such proxies are closed via iterative hole-filling, mesh refinement, and fairing operations. + + Users should be aware that the resulting mesh does not necessarily represent the original feature. + In most cases objects, precipitates in atom probe end up as open objects because they have been + clipped by the edge of the dataset. Using a proxy is in this case a strategy to still be able to account + for these objects. However, users should make themselves familiar with the consequences and + potential biases which this can introduce into the analysis. + has_proxy_geometry(NX_BOOLEAN): doc: | - Method used for identifying and refining the location of the - interface. Currently, paraprobe-nanochem implements a PCA followed - by an iterative loop of isotropic mesh refinement and DCOM step(s), - paired with self-intersection detection in a more robust - implementation. - enumeration: [pca_plus_dcom] - decorating_iontypes_filter(NXprocess): + Like has_object_geometry but for the proxies. + has_proxy_properties(NX_BOOLEAN): doc: | - Specify the types of those ions which decorate the interface and - can thus be assumed as markers for locating the interface and - refining its local curvature. - candidates(NX_UINT): - unit: NX_UNITLESS - doc: | - Array of iontypes to filter. The list is interpreted as a whitelist, - i.e. ions of these types are considered the decorating species (solutes). - dimensions: - rank: 1 - dim: [[1, n_fct_filter_cand]] - number_of_iterations(NX_UINT): - unit: NX_UNITLESS + Like has_object_properties but for the proxies. + has_proxy_obb(NX_BOOLEAN): doc: | - How many times should the DCOM and mesh refinement be applied? - target_edge_length(NX_FLOAT): - unit: NX_LENGTH + Like has_object_obb but for the proxies. + has_proxy_ions(NX_BOOLEAN): doc: | - Array of decreasing positive not smaller than one nanometer real values - which specify how the initial triangles of the mesh should be iteratively - refined by edge splitting and related mesh refinement operations. - - # \@units: nm - dimensions: - rank: 1 - dim: [[1, n_fct_iterations]] - target_dcom_radius(NX_FLOAT): - unit: NX_LENGTH + Like has_object_ions but for the proxies. + has_proxy_edge_contact(NX_BOOLEAN): doc: | - Array of decreasing positive not smaller than one nanometer real values - which specify the radius of the spherical region of interest within - which the DCOM algorithm decides for each vertex how the vertex will - be eventually relocated. The larger the DCOM radius is relative to - the target_edge_length the more likely it is that vertices will be - relocated so substantially that eventually triangle self-intersections - can occur. If the code detects these it warns and stops in a - controlled manner so that the user can repeat the analyses - with a smaller value. - - # \@units: nm - dimensions: - rank: 1 - dim: [[1, n_fct_iterations]] - target_smoothing_step(NX_UINT): - unit: NX_UNITLESS + Like has_object_edge_contact but for the proxies. + has_object_proxigram(NX_BOOLEAN): doc: | - Array of integers which specify for each DCOM step how many times - the mesh should be iteratively smoothened. + Specifies if the tool should report for each closed object a (cylindrical) region-of-interest (ROI) that gets + placed, centered, and aligned with the local normal for each triangle of the object. + has_object_proxigram_edge_contact(NX_BOOLEAN): + doc: | + Specifies if the tool should report for each ROI that was placed at a triangle of each object if this ROI intersects + with the edge the dataset. Currently, the tool supports cylindrical ROIs. A computational geometry test is + performed to check for a possible intersection of each ROI with the triangulated surface mesh that is defined + via surface. Results of this cylinder-set-of-triangles intersection are interpreted as follows: + If the cylinder intersects with at least one triangle of the surface (mesh) the ROI is assumed to make edge contact. + Otherwise, the ROI is assumed to make no edge contact. - Users should be aware the three array target_edge_length, - target_dcom_radius, and target_smoothing_step are interpreted in the - same sequence, i.e. the zeroth entry of each array specifies the - values to be used in the first DCOM iteration. The first entry of - each array those for the second DCOM iteration and so on and so forth. - dimensions: - rank: 1 - dim: [[1, n_fct_iterations]] - composition_profiling(NXprocess): - exists: ['min', '0', 'max', '1'] + Users should note that this approach does not work if the ROI is laying completely outside the dataset as also + in this case the cylinder intersects with any triangle. However, for atom probe this case is practically irrelevant + provided constructions such as alpha shapes or alpha wrappings (such as paraproeb-surfacer does) about the + ions of the entire reconstructed volume are used. + # has_object_mesh_smoothing(NX_BOOLEAN): + # doc: Specifies if the tool should post-process each mesh to improve the mesh quality. + # mesh_smoothing(NXprocess): + # NEW ISSUE: here we need to specify how the meshes were smoothened + # profiling (only stored in the first instance of spatial_statistics) + programID(NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + profiling(NXcs_profiling): + exists: recommended + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + current_working_directory(NX_CHAR): + + + interface_meshing(NXapm_paraprobe_tool_config): + exists: [min, 0, max, 1] + doc: | + Use a principle component analysis (PCA) to mesh a single free-standing interface patch within + the reconstructed volume that is decorated by ions of specific iontypes (e.g. solute atoms). + + Interface_meshing is a typical starting point for the quantification of Gibbsian interfacial excess + in cases when closed objects constructed from patches e.g. iso-surfaces are not available or + when there is no substantial or consistently oriented concentration gradients across an interface + patch. The functionality can also be useful when the amount of latent crystallographic information + within the point cloud is insufficient or when combined with interface_meshing based on ion density + traces in field-desorption maps (see `Y. Wei et al. `_ + and `A. Breen et al. `_ for details). + + Noteworthy to mention is that the method used is conceptually similar to the work of `Z. Peng et al. `_ and related work (DCOM algorithm) by `P. Felfer et al. `_. Compared to these implementations + paraprobe-nanochem uses inspection functionalities which detect potential geometric + inconsistencies or self-interactions of the evolved DCOM mesh. + (NXidentifier): + exists: optional + analysis_identifier(NX_UINT): + exists: recommended + reconstruction(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + position(NX_CHAR): + mass_to_charge(NX_CHAR): + ranging(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + ranging_definitions(NX_CHAR): + surface(NXserialized): + exists: optional doc: | - Functionalities for placing regions-of-interest (ROIs) in the dataset - or at specific microstructural features to characterize composition - profiles and cumulated profiles for quantification of interfacial excess. - Paraprobe-nanochem currently places cylindrical ROIs. ROIs are probed - across the triangulated surface of a user-defined mesh. - ROIs are placed at the barycenter of the triangular facet. + A precomputed triangulated surface mesh representing a model (of the surface) + of the edge of the dataset. This model can be used to detect and control + various sources of bias in the analyses. + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + vertices(NX_CHAR): + doc: | + Absolute path in the (HDF5) file that points to the array + of vertex positions for the triangles in that triangle_set. + indices(NX_CHAR): + doc: | + Absolute path in the (HDF5) file that points to the array + of vertex indices for the triangles in that triangle_set. + spatial_filter(NXspatial_filter): + windowing_method(NX_CHAR): + hexahedron_set(NXcg_hexahedron_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + hexahedra(NXcg_face_list_data_structure): + vertices(NX_UINT): + cylinder_set(NXcg_cylinder_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + height(NX_NUMBER): + radii(NX_NUMBER): + ellipsoid_set(NXcg_ellipsoid_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + half_axes_radii(NX_NUMBER): + orientation(NX_NUMBER): + polyhedron_set(NXcg_polyhedron_set): + exists: optional + # TODO + bitmask(NXcs_filter_boolean_mask): + exists: optional + number_of_objects(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + # leave open if scalar or matrix + # dim: (i,) + # identifier(NX_UINT): + evaporation_id_filter(NXsubsampling_filter): + exists: optional + min_incr_max(NX_INT): + iontype_filter(NXmatch_filter): + exists: optional + method(NX_CHAR): + match(NX_NUMBER): + hit_multiplicity_filter(NXmatch_filter): + exists: optional + method(NX_CHAR): + match(NX_NUMBER): + # config + initialization(NX_CHAR): + doc: | + How is the PCA initialized: - The tool can be instructed to orient the profile for each ROIs with - the positive normal of the triangle facet normals. Profiles are - computed for each ROI and facet triangle. The code will test which - ROIs are completely embedded in the dataset. - Specifically, in this test the tool evaluates if the ROI cuts at least - one triangle of the triangulated surface mesh of the edge of the dataset. - If this is the case the ROI will be considered close to the edge - (of the dataset) and not analyzed further; else the ROI will be - processed further. - Users should be aware that the latter intersection analysis is strictly - speaking not a volumetric intersection analysis as such one is much - more involved because the edge model can be a closed non-convex polyhedron - in which case one would have to test robustly if the cylinder pierces - or is laying completely inside the polyhedron. For this the polyhedron has - to be tessellated into convex polyhedra as otherwise tests like the - Gilbert-Johnson-Keerthi algorithm would not be applicable. + * default, means based on segregated solutes in the ROI + * control_point_file, means based on reading an external list of + control points, currently coming from the Leoben APT_Analyzer. - Specifically, the tool computes atomically decomposed profiles. - This means molecular ions are split into atoms/isotopes with respective - multiplicity. As an example an H3O+ molecular ion contains three - hydrogen and one oxygen atom respectively. The tool then evaluates - how many ions are located inside the ROI or on the surface of the - ROI respectively. All atom types and the unranged ions are distinguished. - As a result, the analyses yield for each ROI a set of sorted lists of - signed distance values. Currently, the distance is the projected - distance of the ion position to the barycenter of the triangle - and triangle plane. + The control_point_file is currently expected with a specific format. + The Leoben group lead by L. Romaner has developed a GUI tool `A. Reichmann et al. `_ creates a control_point_file that + can be parsed by paraprobe-parmsetup-nanochem to match the here required + formatting in control_points. + enumeration: [default, control_point_file] + control_point(NXserialized): + doc: | + Details about the control point file used. + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + control_points(NX_CHAR): + doc: | + Absolute path in the HDF5 control point file pointed to by path which contains + the X, Y, Z position matrix of disjoint control points. + method(NX_CHAR): + doc: | + Method used for identifying and refining the location of the interface. Currently, + paraprobe-nanochem implements a PCA followed by an iterative loop of isotropic + mesh refinement and DCOM step(s), paired with self-intersection detection. + enumeration: [pca_plus_dcom] + decorating_iontypes_filter(NXmatch_filter): + doc: | + Specify the types of those ions that decorate the interface and can thus be assumed + to serve as useful markers for locating the interface and refining the interface mesh. + method(NX_CHAR): + enumeration: [whitelist] + match(NX_UINT): + doc: | + Array of iontypes to filter. + unit: NX_UNITLESS + dim: (n_fct_filter_cand,) + number_of_iterations(NX_UINT): + doc: | + How many times should the DCOM and mesh refinement be applied? + unit: NX_UNITLESS + target_edge_length(NX_FLOAT): + doc: | + Array of decreasing positive not smaller than one nanometer real values + which specify how the initial triangles of the mesh should be iteratively + refined by edge splitting and related mesh refinement operations. + unit: NX_LENGTH + dim: (n_fct_iterations,) + target_dcom_radius(NX_FLOAT): + doc: | + Array of decreasing positive not smaller than one nanometer real values + which specify the radius of the spherical region of interest within which the + DCOM algorithm decides for each vertex how the vertex might be relocated. - This will return a one-dimensional profile. Post-processing the set - of atom-type-specific profiles into cumulated profiles enable the - classical Krakauer/Seidman-style interfacial excess analyses. - Furthermore, the tool can be instructed to compute for each - (or a selected sub-set of facet) a set of differently oriented profiles. + The larger it is the DCOM radius in relation to the target_edge_length the more + likely it becomes that vertices will be relocated so substantially that triangle + self-intersections may occur. The tool detects these and stops in a controlled + manner so that the user can repeat the analyses with using a different parameterization. + unit: NX_LENGTH + dim: (n_fct_iterations,) + target_smoothing_step(NX_UINT): + doc: | + Array of integers which specify for each DCOM step how many times the mesh + should be iteratively smoothened. Users should be aware that all three arrays + target_edge_length, target_dcom_radius, and target_smoothing_step are interpreted + in the same sequence, i.e. the zeroth entry of each array specifies the respective + parameter values to be used in the first DCOM iteration. The first entry of each array + those for the second DCOM iteration and so on and so forth. + unit: NX_UNITLESS + dim: (n_fct_iterations,) + # profiling (only stored in the first instance of spatial_statistics) + programID(NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + profiling(NXcs_profiling): + exists: recommended + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + current_working_directory(NX_CHAR): + + + oned_profile(NXapm_paraprobe_tool_config): + exists: [min, 0, max, 1] + doc: | + Analysis of one-dimensional profiles in ROIs placed in the dataset. Such analyses are useful for quantifying + interfacial excess or classical composition analyses. The tool will test for each ROIs if it is completely embedded + in the dataset. Specifically, in each such test the tool evaluates if the ROI cuts at least one triangle of the triangulated surface mesh refered to by surface. If this is the case the ROI is close to the surface and not analyzed further. + Otherwise, the ROI is processed further. + + Users should be aware that the latter intersection analysis is not a volumetric intersection analysis as such one + is much more computationally involved because the edge model can be a closed non-convex polyhedron + in which case one would have to test robustly if the cylinder pierces or is laying completely inside the polyhedron. + For this the polyhedron has to be tessellated first into convex polyhedra, as test for volumetric intersection using + the Gilbert-Johnson-Keerthi algorithm (GJK) are applicable only to convex polyhedra. - # In the second case, these profiles will be probed in the direction of - # the outer unit surface normal vectors of a sphere. The sphere is - # discretized via a geodesic sphere (according to ideas of M. Kühbach - # et al. Journal of Applied Crystallography 2021) model with 40962 - # directions, some of which are duplicates (for now). This direction - # sampling enables substantially more detailed analyses of the effect - # of aligning the ROI because alignments of ROI based on triangle - # surface normals of the feature mesh can result in larger direction - # differences between neighboring ROIs when the mesh for rough - # surface meshes. - feature_mesh(NXprocess): + For each ROI the tool computes atomically decomposed profiles. This means, molecular ions are split into + nuclides with respective multiplicity. For each processed ROI a set of a sorted list of signed distance values + is returned to enable classical Krakauer/Seidman-style interfacial excess analyses. + (NXidentifier): + exists: optional + analysis_identifier(NX_UINT): + exists: recommended + reconstruction(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + position(NX_CHAR): + mass_to_charge(NX_CHAR): + ranging(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + ranging_definitions(NX_CHAR): + surface(NXserialized): + exists: optional + doc: | + A precomputed triangulated surface mesh representing a model (of the surface) + of the edge of the dataset. This model can be used to detect and control + various sources of bias in the analyses. + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + vertices(NX_CHAR): doc: | - The feature mesh enables the injection of previously computed triangle - soup or mesh data. Such a mesh can be the model for a grain- or phase - boundary patch (from e.g. interface_meshing) jobs. - filename: - doc: | - Name of the HDF5 file which contains vertex coordinates and facet - indices to describe the desired set of triangles which represents - the feature. - \@version: - doc: | - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - dataset_name_vertices: - doc: | - Absolute path to the HDF5 dataset in the respectively specified HDF5 - file under filename which details the array of vertex positions. - dataset_name_facet_indices: - doc: | - Absolute path to the HDF5 dataset in the respective specified HDF5 - file under filename which details the array of facet indices. - dataset_name_facet_normals: - doc: | - Absolute path to the HDF5 dataset in the respective specified HDF5 - file under filename which details consistently oriented facet - normals of the facets. - - # dataset_name_vertex_normals: - # doc: Absolute path to the HDF5 dataset in the respective specified - # HDF5 file under filename which details consistently oriented - # vertex normals of the facets. - # exists: optional - patch_identifier_filter(NXmatch_filter): - exists: optional - method: - match(NX_NUMBER): - ion_to_feature_distances(NXprocess): - exists: optional + Absolute path in the (HDF5) file that points to the array + of vertex positions for the triangles in that triangle_set. + indices(NX_CHAR): doc: | - The tool enables to inject precomputed distance information for each - point which can be used for further post-processing and analysis. + Absolute path in the (HDF5) file that points to the array + of vertex indices for the triangles in that triangle_set. + surface_distance(NXserialized): + exists: recommended + doc: | + Distance between each ion and triangulated surface mesh. + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + spatial_filter(NXspatial_filter): + windowing_method(NX_CHAR): + hexahedron_set(NXcg_hexahedron_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + hexahedra(NXcg_face_list_data_structure): + vertices(NX_UINT): + cylinder_set(NXcg_cylinder_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + height(NX_NUMBER): + radii(NX_NUMBER): + ellipsoid_set(NXcg_ellipsoid_set): + exists: optional + dimensionality(NX_POSINT): + cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + half_axes_radii(NX_NUMBER): + orientation(NX_NUMBER): + polyhedron_set(NXcg_polyhedron_set): + exists: optional + # TODO + bitmask(NXcs_filter_boolean_mask): + exists: optional + number_of_objects(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + # leave open if scalar or matrix + # dim: (i,) + # identifier(NX_UINT): + evaporation_id_filter(NXsubsampling_filter): + exists: optional + min_incr_max(NX_INT): + iontype_filter(NXmatch_filter): + exists: optional + method(NX_CHAR): + match(NX_NUMBER): + hit_multiplicity_filter(NXmatch_filter): + exists: optional + method(NX_CHAR): + match(NX_NUMBER): + # config + interface_model(NX_CHAR): + doc: | + Interfacial excess computations are performed for ROIs at selected facets or a triangulated interface patch + obtained from e.g. a previous interface_mesh processing. + + For instance many scientist compute the interfacial excess for selected triangle facets of an iso-surface. + In this case, computed iso-surfaces of paraprobe could be used. An example are triangle facet sets about + closed polyhedra, for instance to compute interfacial excess related to phase boundaries of second-phase precipitates. - # NEW ISSUE: is this optional? - filename: - doc: | - Name of an HDF5 file which contains ion distances. - \@version: - doc: | - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional - layer of reproducibility from which file specifically contains - these data. - dataset_name: - doc: | - Absolute HDF5 path to the dataset with distance values for each ion. - distancing_model: + Another example are free-standing triangle patches of the iso-surfaces which paraprobe creates. + These could be characterized for interfacial excess. The sub-routines during iso-surface computations + already include a procedure to automatically align local triangle normals based on the gradients of + e.g. composition fields. + + Often scientists face situations in which neither a significant composition gradient across an interface + (grain or phase boundary) exists nor latent crystallographic information about the adjoining crystal is + available or reliable enough. + + In this case `P. Felfer et al. `_ proposed a method to manually place control points and run an automated tessellation-based algorithm to create a triangulated surface patch, + i.e. a model of the location of the interface. In a post-processing step, this triangle set can then be used to + compute again interfacial excess in an automated manner by placing ROIs and aligning these with consistently oriented triangle normals. + + A similar use case is conceptually the one proposed by `X. Zhou et al. `_ who used first a deep-learning method to locate planar triangulated grain boundary patches. These are eventually processed further with manual editing of the mesh via tools like Blender. Once the user is satisfied with the mesh, the computations of interfacial excess reduce again to an automated placing of ROIs, computations of the distributing of ions to respective ROIs, and plotting the results. + + Another approach for constructing an triangulated surface patch of an interface is to use point cloud processing methods that have been proposed in the laser-scanning, geoinformatics, and CAD community. Different computational geometry methods exist for fitting a parameterized surface to a set of points, using e.g. + non-uniform rational B-splines (NURBS) and triangulating these according to prescribed mesh quality demands. + The advantage of these methods is that they are fully automatable and pick up curved interface segments. + The disadvantage is their often strong sensitivity on the parameterization. + + In all aforementioned cases except an interface_mesh is generated on which the here proposed method + can be applied. In summary, a given an interfacial_excess analysis takes an interface_mesh, places ROIs + automatically and evaluates the spatial distribution of ions as a function of the signed distance to the interface + patch. + enumeration: [isosurface, external] + # NEW ISSUE: how to implement and also check consistently via NeXus that a + # NEW ISSUE: child group is required only when a field has a certain value? + interface_mesh(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + vertices(NX_CHAR): doc: | - Which type of distance should be reported for the profile. - enumeration: [project_to_triangle_plane] - - # NEW ISSUE:, ion_to_feature] - direction_model: + Absolute HDF5 path to the dataset that specifies the array of vertex positions. + indices(NX_CHAR): doc: | - In which directions should the tool probe for each ROI. - enumeration: [triangle_outer_unit_normal] - - # NEW ISSUE:, angularly_geodesic_sphere] - roi_cylinder_height(NX_FLOAT): - unit: NX_LENGTH + Absolute HDF5 path to the dataset that specifies the array of facet indices + which refer to vertices. + facet_normals(NX_CHAR): doc: | - For each ROI, how high (projected on the cylinder axis) - should the cylindrical ROI be. - - # \@units: nm - # all ROIs the same height - # dimensions: - # rank: 1 - # dim: [[1, 1]] - roi_cylinder_radius(NX_FLOAT): - unit: NX_LENGTH + Absolute HDF5 path to the dataset that specifies the array of facet signed unit normals. + vertex_normals(NX_CHAR): doc: | - For each ROI, how wide (radius) should the cylindrical ROI be. - - # \@units: nm - # all ROIs the same radius - # dimensions: - # rank: 1 - # dim: [[1, 1]] - performance(NXcs_profiling): - current_working_directory: - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 1284c5c27884acb07242d7f237e65ab62a417f86051e12e75d536a4656d03f82 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# How many iontypes does the delocalization filter specify. -# -# -# -# -# How many disjoint control points are defined. -# -# -# -# -# How many iontypes does the interface meshing iontype filter specify. -# -# -# -# -# How many DCOM iterations. -# -# -# -# -# Maximum number of atoms per molecular ion. -# -# -# -# -# Configuration of a paraprobe-nanochem tool run in atom probe microscopy. -# -# -# -# -# Version specifier of this application definition. -# -# -# -# -# Official NeXus NXDL schema with which this file was written. -# -# -# -# -# -# -# -# Given name of the program/software/tool with which this NeXus -# (configuration) file was generated. -# -# -# -# Ideally program version plus build number, or commit hash or description -# of ever persistent resources where the source code of the program and -# build instructions can be found so that the program can be configured -# ideally in such a manner that the result of this computational process -# is recreatable in the same deterministic manner. -# -# -# -# -# -# Ideally, a (globally persistent) unique identifier for referring -# to this analysis. -# -# -# -# -# Possibility for leaving a free-text description about this analysis. -# -# -# -# -# Path to the directory where the tool should store NeXus/HDF5 results -# of this analysis. If not specified results will be stored in the -# current working directory. -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to -# UTC information included when this configuration file was created. -# -# -# -# -# How many individual analyses should the tool execute as part of the analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The tool enables to inject a previously computed triangle soup or -# triangulated surface mesh representing a model (of the surface) of -# the edge of the dataset. This model can be used to detect and control -# various sources of bias in the analyses. -# -# -# -# -# Name of the HDF5 file which contains vertex coordinates and facet -# indices to describe the desired set of triangles which represents -# the edge of the dataset. -# -# -# -# Version identifier of the file such as a secure hash which documents -# the binary state of the file to add an additional layer of -# reproducibility from which file specifically contains these data. -# -# -# -# -# -# Absolute path to the HDF5 dataset in the respectively specified HDF5 -# file under filename which details the array of vertex positions. -# -# -# -# -# Absolute path to the HDF5 dataset in the respective specified HDF5 -# file under filename which details the array of facet indices. -# -# -# -# -# -# The tool enables to inject precomputed distance information for each -# point/ion which can be used for further post-processing and analysis. -# -# -# -# -# Name of an HDF5 file which contains the ion distances. -# -# -# -# Version identifier of the file such as a secure hash which documents -# the binary state of the file to add an additional layer of -# reproducibility from which file specifically contains these data. -# -# -# -# -# -# Absolute HDF5 path to the dataset with distance values for each ion. -# -# -# -# -# -# -# -# Discretization of the ion point cloud on a three-dimensional grid. -# -# -# -# Delocalization in the field of atom probe microscopy is the process -# of discretizing a point cloud. By default the tool computes a full -# kernel density estimation of decomposed ions to create one discretized -# field for each element. -# -# Although, this uses an efficient multithreaded algorithm, -# the computation is costly. Therefore, it can be advantageous for users -# to load an already computed delocalization. This can be achieved with -# the load_existent option. -# When using this option the user is responsible to assure that the -# settings which were used for computing this already existent delocalization -# are specified in the same manner as they were. -# -# -# -# -# -# -# -# -# -# -# Matrix of isotope vectors representing iontypes. -# The filter specifies a matrix of isotope_vectors which is the most -# general approach to define if and how many times an ion is counted. -# Currently, paraprobe_nanochem performs a so-called atomic decomposition -# of all iontypes. Specifically, the tool interprets of how many -# elements/atoms a molecular ion is composed; and thus determines the -# atoms multiplicity with respect to the iontype. -# -# Let's take the hydroxonium H3O+ molecular ion as an example: -# It contains hydrogen and oxygen as atoms. The multiplicity of hydrogen -# is three whereas that of oxygen is one. Therefore in an atomic -# decomposition computation of the iso-surface each H3O+ ion adds -# three hydrogen counts. This is a practical solution which accepts -# the situation that during an atom probe experiment not each bond -# of each ion/a group of neighboring atoms is broken but molecular -# ions get detected. The exact ab-initio details depend on the local -# field conditions and thus also the detailed spatial arrangement -# of the atoms and their own electronic state and that of the neighbors -# before and upon launch. -# Being able to measure the information for such sites only as -# molecular ions causes an inherent information loss with respect to the -# detailed spatial arrangement. This information loss is more relevant -# for local electrode atom probe than for field ion microscopy setting -# how precisely the atomic positions can be reconstructed. -# Accounting for multiplicities assures that at least the -# compositional information is analyzed. -# -# -# -# -# -# -# -# -# List of individual grid resolutions to analyse. -# Paraprobe discretizes on a cuboidal 3D grid with cubic cells, with -# an edge length of values in gridresolutions. -# -# -# -# -# -# Half the width of a :math:`{(2 \cdot n + 1)}^3` cubic kernel of voxel -# beyond which the Gaussian Ansatz function will be truncated. -# Intensity beyond the kernel is refactored into the kernel via -# a normalization procedure. -# -# -# -# -# Variance of the Gaussian Ansatz kernel :math:`\sigma_x = \sigma_y = 2 \cdot -# \sigma_z`. -# -# -# -# -# -# How should the results of the kernel-density estimation be computed -# into quantities. By default the tool computes the total number -# (intensity) of ions or elements. Alternatively the tool can compute -# the total intensity, the composition, or the concentration of the -# ions/elements specified by the white list of elements in each voxel. -# -# -# -# -# -# -# -# -# -# -# Specifies if the tool should report the delocalization 3D field values. -# -# -# -# -# -# -# Optional computation of iso-surfaces after each computed delocalization -# to identify for instance objects in the microstructure -# (line features, interfaces, precipitates). -# -# -# -# As it is detailed in M. Kühbach et al. 2022 npj Comp. Mat., -# the handling of triangles at the edge of the dataset requires -# special attention. Especially for composition-normalized -# delocalization it is possible that the composition increases -# towards the edge of the dataset because the quotient of two numbers -# which are both smaller than one is larger instead of smaller than -# the counter. By default, the tool uses a modified marching cubes -# algorithm of Lewiner et al. which detects if voxels face such a -# situation. In this case, no triangles are generated for such voxels. -# Alternatively, (via setting keep_edge_triangles) the user can -# instruct the tool to not remove these triangles at the cost of bias. -# -# Specifically, in this case the user should understand that all -# objects/microstructural features in contact with the edge of the -# dataset get usually artificial enlarged and their surface mesh -# often closed during the marching. This closure however is artificial! -# It can result in biased shape analyses for those objects. -# The reason why this should in general be avoided is a similar -# argument as when one analyzes grain shapes in orientation microscopy -# via e.g. SEM/EBSD. Namely, these grains, here the objects at the -# edge of the dataset, were not fully captured during e.g. limited -# field of view. -# Therefore, it is questionable if one would like to make -# substantiated quantitative statements about them. -# -# Thanks to collaboration with the V. V. Rielli and S. Primig, though, -# paraprobe-nanochem implements a complete pipeline to -# process even these objects at the edge of the dataset. Specifically, -# the objects are replaced by so-called proxies, i.e. replacement -# objects whose holes on the surface mesh have been closed if possible -# via iterative mesh and hole-filling procedures with fairing operations. -# In the results of each paraprobe-nanochem run, these proxy objects -# are listed separately to allow users to quantify and analyze in -# detail the differences when accounting for these objects or not. -# Especially this is relevant in atom probe microscopy as objects -# can contain a few dozen atoms only. -# Users should be aware that results from fairing operations should -# be compared to results from analyses where all objects at the edge -# of the dataset have been removed. -# -# Also users should be careful with overestimating the statistical -# significance of their dataset especially when using atom probe -# to compare multiple descriptors: Even though a dataset may give -# statistically significant results for compositions, this does not -# necessarily mean it will yield also statistically significant -# and unbiased results for three-dimensional object analyses. -# Being able to quantify these effects and making atom probers -# aware of these subtleties was one of the main reasons why the -# paraprobe-nanochem tool was implemented. -# -# -# -# -# -# -# -# -# The ion-to-edge-distance that is used in the analyses of objects -# (and proxies) to identify whether these are inside the dataset or -# close to the edge of the dataset. If an object has at least one ion -# with an ion-to-edge-distance below this threshold, the object is -# considered as one which lies close to the edge of the dataset. -# This implements essentially a distance-based approach to solve -# the in general complicated and involved treatment of computing -# volumetric intersections between not-necessarily convex -# closed 2-manifolds. In fact, such computational geometry analyses -# can face numerical robustness issues as a consequence of which a -# mesh can be detected as lying completely inside a dataset although -# in reality it is epsilon-close only, i.e. almost touching only -# the edge (e.g. from inside). -# Practically, humans would state in such case that the object is -# close to the edge of the dataset; however mathematically the object -# is indeed completely inside. -# In short, a distance-based approach is rigorous and more flexible. -# -# -# -# -# -# Array of iso-contour values. For each value the tool computes -# an iso-surface and performs subsequent analyses. -# The unit depends on the choice for the normalization of the -# accumulated ion intensity values per voxel: -# -# * total, total number of ions, irrespective their iontype -# * candidates, total number of ions with type in the isotope_whitelist. -# * composition, candidates but normalized by composition, i.e. at.-% -# * concentration, candidates but normalized by voxel volume, i.e. ions/nm^3 -# -# -# -# -# -# Specifies if the tool should report the triangle soup which represents -# each triangle of the iso-surface complex. -# Each triangle is reported with an ID specifying to which triangle -# cluster (with IDs starting at zero) the triangle belongs. -# The clustering is performed with a modified DBScan algorithm. -# -# -# -# -# Specifies if the tool should analyze for each cluster of triangles -# how they can be combinatorially processed to describe a closed -# polyhedron. Such a closed polyhedron (not-necessarily convex!) -# can be used to describe objects with relevance in the microstructure. -# Users should be aware that the resulting mesh does not necessarily -# represent the original precipitate. In fact, inaccuracies in the -# reconstructed positions cause inaccuracies in all downstream -# processing operations. Especially the effect on one-dimensional -# spatial statistics like nearest neighbor correlation functions these -# effects were discussed in the literature -# `B. Gault et al. <https://doi.org/10.1017/S1431927621012952>`_ -# In continuation of these thoughts this applies also to reconstructed -# objects. A well-known example is the discussion of shape deviations -# of Al3Sc precipitates in aluminium alloys which in reconstructions -# can appear as ellipsoids although they should be almost spherical, -# depending on their size. -# -# -# -# -# Specifies if the tool should report a triangulated surface mesh -# for each identified closed polyhedron. It is common that a -# marching cubes algorithm creates iso-surfaces with a fraction of very -# small sub-complexes (e.g. small isolated tetrahedra). -# -# These can be for instance be small tetrahedra/polyhedra about the -# center of a voxel of the support grid on which marching cubes operates. -# When these objects are small, it is possible that they contain no ion; -# especially when considering that delocalization procedures smoothen -# the positions of the ions. Although these small objects are interesting -# from a numerical point of view, scientists may argue they are not worth -# to be reported: -# Physically a microstructural feature should contain at least a few -# atoms to become relevant. Therefore, paraprobe-nanochem by default -# does not report closed objects which bound not at least one ion. -# -# -# -# -# Specifies if the tool should report properties of each closed -# polyhedron, such as volume and other details. -# -# -# -# -# Specifies if the tool should report for each closed polyhedron an -# approximately optimal bounding box fitted to all triangles of the -# surface mesh of the object and ion positions inside or on the -# surface of the mesh. -# This bounding box informs about the closed object's shape -# (aspect ratios). -# -# -# -# -# -# Specifies if the tool should report for each closed polyhedron -# all evaporation IDs of those ions which lie inside or on the -# boundary of the polyhedron. This information can be used e.g. -# in the paraprobe-intersector tool to infer if two objects share -# common ions, which can be interpreted as an argument to assume -# that the two objects intersect. -# -# Users should be aware that two arbitrarily closed polyhedra -# in three-dimensional space can intersect but not share a common ion. -# In fact, the volume bounded by the polyhedron has sharp edges. -# When taking two objects, an edge of one object may for instance -# pierce into the surface of another object. In this case the -# objects partially overlap / intersect volumetrically; -# however this piercing might be so small or happening in the volume -# between two ion positions and thus sharing ions is a sufficient -# but not a necessary condition for object intersections. -# -# Paraprobe-intersector implements a rigorous alternative to handle -# such intersections using a tetrahedralization of closed objects. -# However, in many practical cases, we found through examples that there -# are polyhedra (especially when they are non-convex and have almost -# point-like) connected channels, where tetrahedralization libraries -# have challenges dealing with. In this case checking intersections -# via shared_ions is a more practical alternative. -# -# -# -# -# Specifies if the tool should report if a (closed) object has -# contact with the edge of the dataset. For this the tool currently -# inspects if the shortest distance between the set of triangles of the -# surface mesh and the triangles of the edge model is larger than the -# edge_threshold. If this is the case, the object is assumed to be -# deeply embedded in the interior of the dataset. Otherwise, the object -# is considered to have an edge contact, i.e. it is likely affected -# by the fact that the dataset is finite. -# -# -# -# -# -# Specifies if the tool should analyze a doppelganger/proxy mesh for -# each cluster of triangles whose combinatorial analysis according -# to has_object showed that the object is not a closed polyhedron. -# Such proxies are closed via iterative hole-filling, mesh refinement, -# and fairing operations. -# Users should be aware that the resulting mesh does not necessarily -# represent the original precipitate. In most cases objects, -# like precipitates in atom probe end up as open objects because -# they have been clipped by the edge of the dataset. Using a proxy is -# then a strategy to still be able to account for these objects. -# Nevertheless users should make themselves familiar with the -# potential consequences and biases which this can introduce -# into the analysis. -# -# -# -# -# Like has_object_geometry but for the proxies. -# -# -# -# -# Like has_object_properties but for the proxies. -# -# -# -# -# Like has_object_obb but for the proxies. -# -# -# -# -# Like has_object_ions but for the proxies. -# -# -# -# -# Like has_object_edge_contact but for the proxies. -# -# -# -# -# Specifies if the tool should report for each closed object a -# (cylindrical) region of interest placed, centered, and align -# with the local normal for each triangle of the object. -# -# -# -# -# Specifies if the tool should report for each ROI that was placed -# at a triangle of each object if this ROI intersects the edge of -# the dataset. Currently paraprobe-nanochem supports cylindrical -# ROIs. A possible intersection of these with the edge of the -# dataset, i.e. the triangulated surface mesh model for the edge -# is performed. This test checks if the cylinder intersects with -# a triangle of the surface mesh. If this is the case, the ROI is -# assumed to make edge contact, else, the ROI is assumed to have -# no edge contact. -# -# This approach does not work if the ROI would be completely -# outside the dataset. Also in this case there would be -# no intersection. For atom probe this case is practically -# irrelevant because for such a ROI there would also be no ion -# laying inside the ROI. Clearly it has thus to be assumed that -# the edge model culls the entire dataset. Instead, if one would -# cut a portion of the dataset, compute an edge model for this -# point cloud, it might make sense to place a ROI but in this -# case the edge contact detection is not expected to work properly. -# -# -# -# -# -# -# Analyses of interfacial excess. -# -# -# -# Interfacial excess computations are performed for local regions-of-interests -# (ROIs) at selected facets or interface patch. -# For instance many scientist compute the interfacial excess for -# selected triangle facets of a created iso-surface. In this case, -# computed iso-surfaces of paraprobe could be used. An example are triangle -# facet sets about closed polyhedra, for instance to compute interfacial -# excess related to phase boundaries of second-phase precipitates. -# -# Another example are free-standing triangle patches of the iso- -# surfaces which paraprobe creates. These could be characterized -# for interfacial excess. The sub-routines during iso-surface -# computations already include a procedure to automatically align -# local triangle normals based on the gradients of e.g. composition -# fields. In this case, these triangulated surface patches -# could also be used as a source for computing interfacial -# excess. -# -# Often scientists face situations, though, in which there is no -# immediately evident composition gradient across the interface -# (grain or phase boundary) and orientation information about the -# adjoining crystal is neither available nor reliable enough. -# -# In this case `P. Felfer et al. <https://doi.org/10.1016/j.ultramic.2015.06.002>`_ proposed a method -# to manually place control points and run an automated tessellation-based -# algorithm to create a triangulated surface patch, i.e. a model of the -# location of the interface. In a post-processing step this triangle -# set can then be used to compute again interfacial excess in an -# automated manner by placing ROIs and aligning them with -# consistently precomputed triangle normals. -# -# A similar use case is conceptually the one proposed by `X. Zhou et al. <https://doi.org/10.1016/j.actamat.2022.117633>`_ -# They used first a deep-learning method to locate planar triangulated -# grain boundary patches. These are eventually processed further -# with manual editing of the mesh via tools like Blender. -# Once the user is satisfied with the mesh, the computations of interfacial -# excess reduce again to an automated placing of ROIs, computations -# of the distributing of ions to respective ROIs and -# reporting the findings via plotting. -# -# Yet another approach for constructing an triangulated surface patch -# of an interface is to use point cloud processing methods which have -# been proposed in the laser-scanning, geoinformatics, and CAD community. -# Different computational geometry methods are available for fitting -# a parameterized surface to a set of points, using e.g. non-uniform -# rational B-splines (NURBS) and triangulating these according -# to prescribed mesh quality demands. -# -# The advantage of these methods is that they can be automated and -# pick up curved interface segments. The disadvantage is their often -# strong sensitivity to parameterization. As a result also such methods -# can be post-processed to yield a triangulated surface patch, -# and thus enable to run again automated ROI placement methods. -# For example like these which were explored for the use case of -# iso-surfaces with closed objects and free-standing -# surface patches that delineate regions of the dataset with a -# pronounced composition gradient normal to the interface. -# -# This summary of the situations which atom probers can face when -# requesting for interfacial excess computations, substantiates there -# exists a common set of settings which can describe all of these methods -# and, specifically, as here exemplified, the automated placing -# and alignment functionalities for ROIs that is an important -# step all these workflows. -# -# Specifically, paraprobe-nanochem operates on an already existent -# triangle set. -# -# -# -# -# -# -# -# -# -# The interface model is the result of a previous (set of) processing -# steps as a result of which the user has created a triangulated -# surface mesh (or a set of, eventually connected such meshes). -# These interface models are useful, if not required, in cases when -# there is no other independent approach to locate an interface. -# -# These are cases when insufficient crystallographic latent -# information is available and also no consistent concentration -# gradient detectable across the interface. It is then the users' -# responsibility to deliver a triangle mesh of the interface model. -# -# -# -# Filename to HDF5 file which contain vertex coordinates, facet indices, -# facet unit normals. The user is responsible for the triangle -# and winding order to be consistent. -# Input is expected as a matrix of the coordinates for all disjoint -# vertices, a (Nvertices, 3)-shaped array of NX_FLOAT. -# Input is expected to include also a matrix of facet indices -# referring to these disjoint vertices. This matrix should be a -# (Nfacets, 3)-shaped array of NX_UINT. Further required input -# is a (Nfacets, 3)-shaped array of NX_FLOAT signed facet unit -# normals and a (Nvertices, 3)-shaped array of NX_FLOAT signed -# vertex unit normals. Vertex indices need to start at zero and -# must not exceed Nvertices - 1, i.e. the identifier_offset is 0 -# and facet indices are indexed implicitly, i.e. [0, Nvertices-1]. -# -# -# -# Version identifier of the file such as a secure hash which -# documents the binary state of the file to add an additional -# layer of reproducibility from which file specifically -# contains these data. -# -# -# -# -# -# Absolute HDF5 path to the dataset which specifies the -# array of vertex positions. -# -# -# -# -# Absolute HDF5 path to the dataset which specifies the -# array of facet indices. -# -# -# -# -# Absolute HDF5 path to the dataset which specifies the -# array of facet signed unit normals. -# -# -# -# -# Absolute HDF5 path to the dataset which specifies the -# array of vertex signed unit normals. -# -# Users should be aware that triangulated surface meshes are -# only approximations to a given complex, eventually curved shape. -# Consequently, computations of normals show differences between -# the vertex and facet normals. Vertex normals have to be -# interpolated from normals of neighboring facets. Consequently, -# these normals are affected by the underlying parameterization -# and curvature estimation algorithms, irrespective of how -# contributions from neighboring facets are weighted. By contrast, -# facet normals are clearly defined by the associated triangle. -# Their disadvantage is that they the normal field has discontinuities -# at the edges. In general the coarser an object is triangulated -# the more significant the difference becomes between computations -# based on facet or vertex normals. -# Paraprobe-nanochem works with facet normals as it can use -# parts of the numerical performance gained by using cutting -# edge libraries to work rather with finer meshes. -# -# -# -# -# -# -# -# Create a simple principle component analysis (PCA) to mesh a -# free-standing interface patch through a point cloud of decorating solutes. -# These models can be useful for quantification of Gibbsian -# interfacial excess for interfaces where iso-surface based methods -# may fail or closed objects from iso-surfaces are not desired or -# when e.g. there are no substantial or consistently oriented -# concentration gradients across the interface patch. -# -# The interface_meshing functionality of paraprobe-nanochem can be useful -# when there is also insufficient latent crystallographic information -# available that could otherwise support modelling the interface, -# via e.g. ion density traces in field-desorption maps, as were used and -# discussed by `Y. Wei et al. <https://doi.org/10.1371/journal.pone.0225041>`_ -# or are discussed by `A. Breen et al. <https://github.com/breen-aj/detector>`_ -# -# It is noteworthy that the method here used is conceptually very similar -# in implementation to the work by `Z. Peng et al. <https://doi.org/10.1017/S1431927618016112>`_ -# Noteworthy, her team uses the DCOM approach originally proposed by P. Felfer et al. -# However, both of these previous works neither discuss in detail -# nor implement inspection functionalities which enable a detection of -# potential geometric inconsistencies or self-interactions of the -# resulting DCOM mesh. This is what paraprobe-nanochem implements -# via the Computational Geometry Algorithms Library. -# -# -# -# Method how to initialize the PCA: -# -# * default, means based on segregated solutes in the ROI -# * control_point_file, means based on reading an external list of -# control points, currently coming from the Leoben APT_Analyzer. -# -# The control_point_file is currently expected with a specific format. -# The Leoben group lead by L. Romaner has developed a GUI tool `A. Reichmann et al. <https://github.com/areichm/APT_analyzer>`_ -# to create a control_point_file which can be parsed by paraprobe-parmsetup -# to match the here required formatting in control_points. -# -# -# -# -# -# -# -# -# The name of the control point file to use. -# -# -# -# Version identifier of the file such as a secure hash which -# documents the binary state of the file to add an additional -# layer of reproducibility from which file specifically -# contains these data. -# -# -# -# -# -# X, Y, Z coordinates of disjoint control point read from -# an HDF5 file named according to control_point_file. -# -# -# -# -# -# -# -# -# -# Method used for identifying and refining the location of the -# interface. Currently, paraprobe-nanochem implements a PCA followed -# by an iterative loop of isotropic mesh refinement and DCOM step(s), -# paired with self-intersection detection in a more robust -# implementation. -# -# -# -# -# -# -# -# Specify the types of those ions which decorate the interface and -# can thus be assumed as markers for locating the interface and -# refining its local curvature. -# -# -# -# Array of iontypes to filter. The list is interpreted as a whitelist, -# i.e. ions of these types are considered the decorating species (solutes). -# -# -# -# -# -# -# -# -# How many times should the DCOM and mesh refinement be applied? -# -# -# -# -# Array of decreasing positive not smaller than one nanometer real values -# which specify how the initial triangles of the mesh should be iteratively -# refined by edge splitting and related mesh refinement operations. -# -# -# -# -# -# -# -# -# Array of decreasing positive not smaller than one nanometer real values -# which specify the radius of the spherical region of interest within -# which the DCOM algorithm decides for each vertex how the vertex will -# be eventually relocated. The larger the DCOM radius is relative to -# the target_edge_length the more likely it is that vertices will be -# relocated so substantially that eventually triangle self-intersections -# can occur. If the code detects these it warns and stops in a -# controlled manner so that the user can repeat the analyses -# with a smaller value. -# -# -# -# -# -# -# -# -# Array of integers which specify for each DCOM step how many times -# the mesh should be iteratively smoothened. -# -# Users should be aware the three array target_edge_length, -# target_dcom_radius, and target_smoothing_step are interpreted in the -# same sequence, i.e. the zeroth entry of each array specifies the -# values to be used in the first DCOM iteration. The first entry of -# each array those for the second DCOM iteration and so on and so forth. -# -# -# -# -# -# -# -# -# Functionalities for placing regions-of-interest (ROIs) in the dataset -# or at specific microstructural features to characterize composition -# profiles and cumulated profiles for quantification of interfacial excess. -# Paraprobe-nanochem currently places cylindrical ROIs. ROIs are probed -# across the triangulated surface of a user-defined mesh. -# ROIs are placed at the barycenter of the triangular facet. -# -# The tool can be instructed to orient the profile for each ROIs with -# the positive normal of the triangle facet normals. Profiles are -# computed for each ROI and facet triangle. The code will test which -# ROIs are completely embedded in the dataset. -# Specifically, in this test the tool evaluates if the ROI cuts at least -# one triangle of the triangulated surface mesh of the edge of the dataset. -# If this is the case the ROI will be considered close to the edge -# (of the dataset) and not analyzed further; else the ROI will be -# processed further. -# Users should be aware that the latter intersection analysis is strictly -# speaking not a volumetric intersection analysis as such one is much -# more involved because the edge model can be a closed non-convex polyhedron -# in which case one would have to test robustly if the cylinder pierces -# or is laying completely inside the polyhedron. For this the polyhedron has -# to be tessellated into convex polyhedra as otherwise tests like the -# Gilbert-Johnson-Keerthi algorithm would not be applicable. -# -# Specifically, the tool computes atomically decomposed profiles. -# This means molecular ions are split into atoms/isotopes with respective -# multiplicity. As an example an H3O+ molecular ion contains three -# hydrogen and one oxygen atom respectively. The tool then evaluates -# how many ions are located inside the ROI or on the surface of the -# ROI respectively. All atom types and the unranged ions are distinguished. -# As a result, the analyses yield for each ROI a set of sorted lists of -# signed distance values. Currently, the distance is the projected -# distance of the ion position to the barycenter of the triangle -# and triangle plane. -# -# This will return a one-dimensional profile. Post-processing the set -# of atom-type-specific profiles into cumulated profiles enable the -# classical Krakauer/Seidman-style interfacial excess analyses. -# Furthermore, the tool can be instructed to compute for each -# (or a selected sub-set of facet) a set of differently oriented profiles. -# -# -# -# -# The feature mesh enables the injection of previously computed triangle -# soup or mesh data. Such a mesh can be the model for a grain- or phase -# boundary patch (from e.g. interface_meshing) jobs. -# -# -# -# Name of the HDF5 file which contains vertex coordinates and facet -# indices to describe the desired set of triangles which represents -# the feature. -# -# -# -# Version identifier of the file such as a secure hash which documents -# the binary state of the file to add an additional layer of -# reproducibility from which file specifically contains these data. -# -# -# -# -# -# Absolute path to the HDF5 dataset in the respectively specified HDF5 -# file under filename which details the array of vertex positions. -# -# -# -# -# Absolute path to the HDF5 dataset in the respective specified HDF5 -# file under filename which details the array of facet indices. -# -# -# -# -# Absolute path to the HDF5 dataset in the respective specified HDF5 -# file under filename which details consistently oriented facet -# normals of the facets. -# -# -# -# -# -# -# -# -# -# -# The tool enables to inject precomputed distance information for each -# point which can be used for further post-processing and analysis. -# -# -# -# -# Name of an HDF5 file which contains ion distances. -# -# -# -# Version identifier of the file such as a secure hash which -# documents the binary state of the file to add an additional -# layer of reproducibility from which file specifically contains -# these data. -# -# -# -# -# -# Absolute HDF5 path to the dataset with distance values for each ion. -# -# -# -# -# -# Which type of distance should be reported for the profile. -# -# -# -# -# -# -# -# -# In which directions should the tool probe for each ROI. -# -# -# -# -# -# -# -# -# For each ROI, how high (projected on the cylinder axis) -# should the cylindrical ROI be. -# -# -# -# -# -# For each ROI, how wide (radius) should the cylindrical ROI be. -# -# -# -# -# -# -# -# -# -# + Absolute HDF5 path to the dataset that specifies the array of vertex signed unit normals. + # triangulated surface meshes are only approximations to eventually curved shape of objects + # consequently, vertex and facet normals typically differ, the former are typically interpolated + # from normals of neighboring facets, type of weighting schemes can affect results quantitatively + patch_identifier_filter(NXmatch_filter): + exists: optional + doc: | + If interface_model is isosurface this filter can be used to restrict the analysis to specific + patches of an iso-surface. + method(NX_CHAR): + match(NX_NUMBER): + distancing_model(NX_CHAR): + doc: | + Which type of distance should be reported for the profile. + enumeration: [project_to_triangle_plane] # ion_to_feature + roi_orientation(NX_CHAR): + doc: | + In which directions should the tool probe for each ROI. + enumeration: [triangle_outer_unit_normal] # angularly_geodesic_sphere + roi_cylinder_height(NX_FLOAT): + doc: | + For each ROI, how high (projected on the cylinder axis) should the cylindrical ROI be. + unit: NX_LENGTH + roi_cylinder_radius(NX_FLOAT): + doc: | + For each ROI, how wide (radius) should the cylindrical ROI be. + unit: NX_LENGTH + # profiling (only stored in the first instance of spatial_statistics) + programID(NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + profiling(NXcs_profiling): + exists: recommended + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + current_working_directory(NX_CHAR): From 2df16a3194e7ef0bc439e1a80a960126828d2e14 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 16 Feb 2024 01:20:59 +0100 Subject: [PATCH 0556/1012] Updated apm-specific landing page --- .../NXapm_paraprobe_nanochem_config.nxdl.xml | 2 +- .../NXapm_paraprobe_nanochem_config.yaml | 2 +- .../contributed_definitions/apm-structure.rst | 54 ++++++------------- 3 files changed, 17 insertions(+), 41 deletions(-) diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml index 2c4dbd0e1a..5993de3db1 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + The symbols used in the schema to specify e.g. dimensions of arrays. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml index 77fc33bfc5..fe27b0c014 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml @@ -17,7 +17,7 @@ symbols: n_ivec_max: | Maximum number of atoms per molecular ion. type: group -NXapm_paraprobe_config_nanochem(NXobject): +NXapm_paraprobe_nanochem_config(NXobject): (NXentry): exists: [min, 1, max, 1] definition(NX_CHAR): diff --git a/manual/source/classes/contributed_definitions/apm-structure.rst b/manual/source/classes/contributed_definitions/apm-structure.rst index 4cae11b027..be56ed064d 100644 --- a/manual/source/classes/contributed_definitions/apm-structure.rst +++ b/manual/source/classes/contributed_definitions/apm-structure.rst @@ -248,47 +248,23 @@ tool one such pair is proposed: Compute and store analytical distances between ions to a set of triangles. :ref:`NXapm_paraprobe_tessellator_config`, :ref:`NXapm_paraprobe_tessellator_results`: - Configuration and results respectively of the of paraprobe-tessellator tool. + Configuration and results respectively of the paraprobe-tessellator tool. Compute and store Voronoi cells and properties of these for all ions in a dataset. -The definitions of the following tools remain to become refactored like those for the above-mentioned tools: + :ref:`NXapm_paraprobe_spatstat_config`, :ref:`NXapm_paraprobe_spatstat_results`: + Configuration and results respectively of the paraprobe-spatstat tool. + Compute spatial statistics on the entire or selected regions of the reconstructed dataset. - :ref:`NXapm_paraprobe_config_nanochem`: - Configuration of paraprobe-nanochem - Compute delocalization, iso-surfaces, analyze 3D objects, and composition profiles. + :ref:`NXapm_paraprobe_clusterer_config`, :ref:`NXapm_paraprobe_clusterer_results`: + Configuration and results resepctively of the paraprobe-clusterer tool. + Compute cluster analyses with established machine learning algorithms using CPU or GPUs. - :ref:`NXapm_paraprobe_results_nanochem`: - Results of paraprobe-nanochem - Store all results of delocalization, isosurface, and interface detection algorithms, - store all extracted triangulated surface meshes of found microstructural features, - store composition profiles and corresponding geometric primitives (ROIs). + :ref:`NXapm_paraprobe_nanochem_config`, :ref:`NXapm_paraprobe_nanochem_results`: + Configuration and results resepctively of the paraprobe-nanochem tool. + Compute delocalization, iso-surfaces, analyze 3D objects, composition profiles, and mesh interfaces. - :ref:`NXapm_paraprobe_config_intersector`: - Configuration of paraprobe-intersector - Assess intersections and proximity of 3D triangulated surface meshes in - continuum space to study the effect the parameterization of surface - extraction algorithms on the resulting shape, spatial arrangement, - and colocation of 3D objects via graph-based techniques. - - :ref:`NXapm_paraprobe_results_intersector`: - Results of paraprobe-intersector - Store graph of microstructural features and relations/link identified between them. - - - :ref:`NXapm_paraprobe_config_spatstat`: - Configuration of paraprobe-spatstat - Spatial statistics on the entire or selected regions of the reconstructed dataset. - - :ref:`NXapm_paraprobe_results_spatstat`: - Results of paraprobe-spatstat - Store spatial correlation functions. - - - :ref:`NXapm_paraprobe_config_clusterer`: - Configuration of paraprobe-clusterer - Import cluster analysis results of IVAS/APSuite and perform clustering - analyses in a Python ecosystem. - - :ref:`NXapm_paraprobe_results_clusterer`: - Results of paraprobe-clusterer - Store results of cluster analyses. + :ref:`NXapm_paraprobe_intersector_config`, :ref:`NXapm_paraprobe_intersector_results`: + Configuration and results resepctively of the paraprobe-intersector tool. + Analyze volumetric intersections and proximity of 3D objects discretized as triangulated surface meshes + in continuum space to study the effect the parameterization of surface extraction algorithms on the resulting shape, + spatial arrangement, and colocation of 3D objects via graph-based techniques. From 0bd04c7a1aeb2e904fb88c65c34bfa08e356d7fb Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 16 Feb 2024 01:34:34 +0100 Subject: [PATCH 0557/1012] Minor edits and fixes apm-structure --- .../NXapm_paraprobe_nanochem_config.nxdl.xml | 1 - .../nyaml/NXapm_paraprobe_intersector_results.yaml | 2 +- .../nyaml/NXapm_paraprobe_nanochem_config.yaml | 1 - .../nyaml/NXapm_paraprobe_nanochem_results.yaml | 2 +- .../classes/contributed_definitions/apm-structure.rst | 11 ++++------- 5 files changed, 6 insertions(+), 11 deletions(-) diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml index 5993de3db1..c7a1681056 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml @@ -189,7 +189,6 @@ identifier(NX_UINT):--> Serialized result of an already computed delocalization which is for performance reasons here just loaded and not computed again. - type(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml index 7d93939ffe..207f3a9fff 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml @@ -17,7 +17,7 @@ symbols: n_total: | The number of rows in the table/matrix for coprecipitation stats. type: group -NXapm_paraprobe_results_intersector(NXobject): +NXapm_paraprobe_intersector_results(NXobject): (NXentry): # by default for appdefs the value of the exists keyword is required diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml index fe27b0c014..f8e5d7067b 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml @@ -136,7 +136,6 @@ NXapm_paraprobe_nanochem_config(NXobject): doc: | Serialized result of an already computed delocalization which is for performance reasons here just loaded and not computed again. - type(NX_CHAR): type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml index e04a5c6434..b95517c87b 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml @@ -24,7 +24,7 @@ symbols: n_speci: | The total number of member distinguished when reporting composition. type: group -NXapm_paraprobe_results_nanochem(NXobject): +NXapm_paraprobe_nanochem_results(NXobject): # by default for appdefs the value of the exists keyword is required # unless it is explicitly specified differently diff --git a/manual/source/classes/contributed_definitions/apm-structure.rst b/manual/source/classes/contributed_definitions/apm-structure.rst index be56ed064d..a36a94ad72 100644 --- a/manual/source/classes/contributed_definitions/apm-structure.rst +++ b/manual/source/classes/contributed_definitions/apm-structure.rst @@ -205,14 +205,11 @@ is useful and future-proof strategy for software development and data analyses a automated provenance tracking which happens silently in the background. Base classes have been defined to group common pieces of information for each tool of the -toolbox. These base classes are: - - :ref:`NXapm_paraprobe_tool_config`: - Common parts of configuration settings useful for several tools of the paraprobe-toolbox. - - :ref:`NXapm_paraprobe_tool_results`: - Common parts of results useful for several tools of the paraprobe-toolbox. +toolbox. For each tool we define a pair of base classes. One for the configuration (input) side +and one for the results (output) side: + :ref:`NXapm_paraprobe_tool_config`, :ref:`NXapm_paraprobe_tool_results`: + Common parts of configuration settings and results respectively useful for several tools of the paraprobe-toolbox. .. _ApmParaprobeAppDef: From d5fa011fa734fe7b1510ad797bd41f2691bce586 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 16 Feb 2024 01:36:36 +0100 Subject: [PATCH 0558/1012] Fixing a copy-paste error --- .../NXapm_paraprobe_intersector_config.nxdl.xml | 2 +- .../nyaml/NXapm_paraprobe_intersector_config.yaml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml index febaa9d769..35d3006df9 100644 --- a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml @@ -36,7 +36,7 @@ - + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml index 2adce1f5ae..60871e6e99 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml @@ -12,7 +12,7 @@ NXapm_paraprobe_intersector_config(NXobject): exists: [min, 1, max, 1] definition(NX_CHAR): \@version(NX_CHAR): - enumeration: [NXapm_paraprobe_spatstat_config] + enumeration: [NXapm_paraprobe_intersector_config] number_of_tasks(NX_UINT): doc: | How many v_v_spatial_correlation tasks should the tool execute. From 38bb08220e8992bcc59c639fb94928d629181707 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 16 Feb 2024 01:42:46 +0100 Subject: [PATCH 0559/1012] Fixed inconsistence --- .../NXapm_paraprobe_tool_config.nxdl.xml | 14 ++++++-------- .../nyaml/NXapm_paraprobe_tool_config.yaml | 12 ++++++------ 2 files changed, 12 insertions(+), 14 deletions(-) diff --git a/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml index 18a4c3ea80..fc3c16cd88 100644 --- a/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml @@ -105,20 +105,18 @@ base class from which tool-specific appdefs inherit--> - + Specification of the triangulated surface mesh to use for this analysis. Such a surface mesh can be used to define the edge of the reconstructed volume to account for finite size effects. - - - Name of the (parent) node directly below which (in the hierarchy) - an instance of :ref:`NXcg_triangle_set` is stored. - - + Specification of the point-to-triangulated-surface-mesh distances to @@ -126,7 +124,7 @@ base class from which tool-specific appdefs inherit--> - Absolute in the (HDF5) file that points to the distance values. + Absolute path in the (HDF5) file that points to the distance values. The tool assumes that the values are stored in the same order as points (ions). diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml index 87362fab57..8af69a3dd0 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml @@ -69,23 +69,23 @@ NXapm_paraprobe_tool_config(NXprocess): doc: | Name of the (parent) node directly below which (in the hierarchy) the ranging definition for (molecular) ions are stored. - surface_mesh(NXserialized): + surface(NXserialized): doc: | Specification of the triangulated surface mesh to use for this analysis. Such a surface mesh can be used to define the edge of the reconstructed volume to account for finite size effects. - mesh(NX_CHAR): - doc: | - Name of the (parent) node directly below which (in the hierarchy) - an instance of :ref:`NXcg_triangle_set` is stored. + # mesh(NX_CHAR): + # doc: | + # Name of the (parent) node directly below which (in the hierarchy) + # an instance of :ref:`NXcg_triangle_set` is stored. surface_distance(NXserialized): doc: | Specification of the point-to-triangulated-surface-mesh distances to use for this analysis. distance(NX_CHAR): doc: | - Absolute in the (HDF5) file that points to the distance values. + Absolute path in the (HDF5) file that points to the distance values. The tool assumes that the values are stored in the same order as points (ions). # filters From d282d0323a0e87ab0266a08b6e11d6ff112050ab Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 16 Feb 2024 15:10:02 +0100 Subject: [PATCH 0560/1012] add NXcoordinate_system_set --- contributed_definitions/NXphotoemission.nxdl.xml | 6 ++++++ contributed_definitions/nyaml/NXphotoemission.yaml | 12 +++++++++++- 2 files changed, 17 insertions(+), 1 deletion(-) diff --git a/contributed_definitions/NXphotoemission.nxdl.xml b/contributed_definitions/NXphotoemission.nxdl.xml index 0da9c99102..29a7bd7d66 100644 --- a/contributed_definitions/NXphotoemission.nxdl.xml +++ b/contributed_definitions/NXphotoemission.nxdl.xml @@ -88,6 +88,12 @@ .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 + + + Description of one or more coordinate systems that are specific to the setup + and the measurement geometry. + + Contact information of at least the user of the instrument or the investigator diff --git a/contributed_definitions/nyaml/NXphotoemission.yaml b/contributed_definitions/nyaml/NXphotoemission.yaml index fbf06c661d..7aa6765536 100644 --- a/contributed_definitions/nyaml/NXphotoemission.yaml +++ b/contributed_definitions/nyaml/NXphotoemission.yaml @@ -54,6 +54,10 @@ NXphotoemission(NXobject): .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 + geometries(NXcoordinate_system_set): + doc: | + Description of one or more coordinate systems that are specific to the setup + and the measurement geometry. (NXuser): exists: recommended doc: | @@ -754,7 +758,7 @@ NXphotoemission(NXobject): @energy_depends: 'entry/process/energy_calibration' # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4eb29a04a3c61de9ffd016783d74d1c20afc5db2be871c9b441a5c03911987b7 +# 897441915df14276256f541060d56755365af4c1fe504ff559e4bd7d773c58ea # # # - + - A set of activities that occurred to the sample prior/during experiment. + A set of activities that occurred to a physical entity prior/during experiment. Ideally, a full report of the previous operations (or links to a chain of operations). Alternatively, notes allow for additional descriptors in any format. - Any activity that was performed on the sample prior or during the experiment. In + Any activity that was performed on the physical entity prior or during the experiment. In the future, if there is base class inheritance, this can describe any activity, including processes and measurements. +doc: | +Any activity that was performed on the physical entity prior or during the experiment. +definition: ["NXactivity"]--> - Any physical process that was performed on the sample prior or during the + Any physical process that was performed on the physical entity prior or during the experiment. - Any chemical process that was performed on the sample prior or during the + Any chemical process that was performed on the physical entity prior or during the experiment. - A descriptor to keep track of the treatment of the sample before or during the + A descriptor to keep track of the treatment of the physical entity before or during the experiment (NXnote allows to add pictures, audio, movies). Alternatively, a reference to the location or a unique identifier or other metadata file. In the case these are not available, free-text description. diff --git a/contributed_definitions/nyaml/NXsample_history.yaml b/contributed_definitions/nyaml/NXhistory.yaml similarity index 73% rename from contributed_definitions/nyaml/NXsample_history.yaml rename to contributed_definitions/nyaml/NXhistory.yaml index 779dfd02aa..815ff35dad 100644 --- a/contributed_definitions/nyaml/NXsample_history.yaml +++ b/contributed_definitions/nyaml/NXhistory.yaml @@ -1,35 +1,35 @@ category: base doc: | - A set of activities that occurred to the sample prior/during experiment. + A set of activities that occurred to a physical entity prior/during experiment. Ideally, a full report of the previous operations (or links to a chain of operations). Alternatively, notes allow for additional descriptors in any format. type: group -NXsample_history(NXobject): +NXhistory(NXobject): (NXactivity): doc: | - Any activity that was performed on the sample prior or during the experiment. In + Any activity that was performed on the physical entity prior or during the experiment. In the future, if there is base class inheritance, this can describe any activity, including processes and measurements. # For now, one workaround would be to have NXactivity as a application definition with a subentry. # subentry(NXsuxbentry): # doc: | - # Any activity that was performed on the sample prior or during the experiment. + # Any activity that was performed on the physical entity prior or during the experiment. # definition: ["NXactivity"] (NXphysical_process): doc: | - Any physical process that was performed on the sample prior or during the + Any physical process that was performed on the physical entity prior or during the experiment. (NXchemical_process): doc: | - Any chemical process that was performed on the sample prior or during the + Any chemical process that was performed on the physical entity prior or during the experiment. # There should be more activities here, like measurement. notes(NXnote): doc: | - A descriptor to keep track of the treatment of the sample before or during the + A descriptor to keep track of the treatment of the physical entity before or during the experiment (NXnote allows to add pictures, audio, movies). Alternatively, a reference to the location or a unique identifier or other metadata file. In the case these are not available, free-text description. @@ -38,14 +38,14 @@ NXsample_history(NXobject): that are not well described by an existing base class definition. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# bbf87f9c949f2f8af78e20e6f7b447ef3c970fa8d5c142863c3416a5826c4893 -# +# 1b69316c874c12a3f6edf44311cdfa1db5b812af014068217ed20c46754bb90f +# # # -# +# # -# A set of activities that occurred to the sample prior/during experiment. +# A set of activities that occurred to a physical entity prior/during experiment. # # Ideally, a full report of the previous operations (or links to a chain of operations). # Alternatively, notes allow for additional descriptors in any format. # # # -# Any activity that was performed on the sample prior or during the experiment. In +# Any activity that was performed on the physical entity prior or during the experiment. In # the future, if there is base class inheritance, this can describe any activity, # including processes and measurements. # # # +# doc: | +# Any activity that was performed on the physical entity prior or during the experiment. +# definition: ["NXactivity"]--> # # -# Any physical process that was performed on the sample prior or during the +# Any physical process that was performed on the physical entity prior or during the # experiment. # # # # -# Any chemical process that was performed on the sample prior or during the +# Any chemical process that was performed on the physical entity prior or during the # experiment. # # # # # -# A descriptor to keep track of the treatment of the sample before or during the +# A descriptor to keep track of the treatment of the physical entity before or during the # experiment (NXnote allows to add pictures, audio, movies). Alternatively, a # reference to the location or a unique identifier or other metadata file. In the # case these are not available, free-text description. From 3c4eca6a8d31257cebcfd74092a61b38cab40ed9 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 16 Feb 2024 15:35:26 +0100 Subject: [PATCH 0564/1012] add NXhistory to NXinstrument --- base_classes/NXinstrument.nxdl.xml | 1 + base_classes/nyaml/NXinstrument.yaml | 4 +++- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/base_classes/NXinstrument.nxdl.xml b/base_classes/NXinstrument.nxdl.xml index 2e6c8b5f73..43b6314733 100644 --- a/base_classes/NXinstrument.nxdl.xml +++ b/base_classes/NXinstrument.nxdl.xml @@ -61,6 +61,7 @@ + diff --git a/base_classes/nyaml/NXinstrument.yaml b/base_classes/nyaml/NXinstrument.yaml index 55843e9061..5aa98976f7 100644 --- a/base_classes/nyaml/NXinstrument.yaml +++ b/base_classes/nyaml/NXinstrument.yaml @@ -35,6 +35,7 @@ NXinstrument(NXobject): (NXfilter): (NXflipper): (NXguide): + (NXhistory): (NXinsertion_device): (NXmirror): (NXmoderator): @@ -60,7 +61,7 @@ NXinstrument(NXobject): for a summary of the discussion. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e89eac143a0a1145377ca71b55368c7158a95b46f8a784ded37cc17e3c23046a +# fdecdac7e6f3f4cfbdc442355d0be92c315dff9551b943c7492edc8e68fddd10 # # # + This group describes the shape of the sample @@ -518,7 +520,9 @@ - + Any environmental or external stimuli/measurements. These can include, among others: @@ -526,7 +530,7 @@ external electric/magnetic/mechanical fields, temperature, ... - + A set of physical processes that occurred to the sample prior/during experiment. @@ -550,7 +554,7 @@ 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 + string "." if located in the origin. Usually these operations are stored in a NXtransformations group. But NeXus allows them to be stored anywhere. diff --git a/base_classes/NXsample_component.nxdl.xml b/base_classes/NXsample_component.nxdl.xml index b64bc25594..7d1660164d 100644 --- a/base_classes/NXsample_component.nxdl.xml +++ b/base_classes/NXsample_component.nxdl.xml @@ -1,10 +1,10 @@ - + +# # # This group describes the shape of the sample # @@ -901,7 +903,9 @@ NXsample(NXobject): # # # -# +# # # Any environmental or external stimuli/measurements. # These can include, among others: @@ -909,7 +913,7 @@ NXsample(NXobject): # external electric/magnetic/mechanical fields, temperature, ... # # -# +# # # A set of physical processes that occurred to the sample prior/during experiment. # @@ -933,7 +937,7 @@ NXsample(NXobject): # 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 +# string "." if located in the origin. Usually these operations are stored in a # NXtransformations group. But NeXus allows them to be stored anywhere. # # diff --git a/base_classes/nyaml/NXsample_component.yaml b/base_classes/nyaml/NXsample_component.yaml index 15dc89ad20..1b55705e92 100644 --- a/base_classes/nyaml/NXsample_component.yaml +++ b/base_classes/nyaml/NXsample_component.yaml @@ -128,7 +128,7 @@ NXsample_component(NXobject): (NXfabrication): doc: | Details about the sample component vendor (company or research group) - (NXsample_history): + sample_history(NXhistory): doc: | A set of physical processes that occurred to the sample component prior/during experiment. @@ -149,14 +149,14 @@ NXsample_component(NXobject): for a summary of the discussion. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 07c4e31c308138182eef1cdddefda26ba6c879da8df45c3f0b03213996fc8fcb -# +# f9d7d8581fa366621e25b76c1524717e50bfa1c7bddaaa1b3ec7e6ef16a082e4 +# # # - + - :ref:`NXdata_mpes` describes the plottable data and related dimension scales in MPES + :ref:`NXdata_photoemission` describes the plottable data and related dimension scales in photoemission experiments. It extends the NXdata class and provides a glossary of explicitly named axis names - which are typical for MPES data. + which are typical for photoemission data. diff --git a/contributed_definitions/NXdata_mpes_detector.nxdl.xml b/contributed_definitions/NXdata_photoemission_detector.nxdl.xml similarity index 95% rename from contributed_definitions/NXdata_mpes_detector.nxdl.xml rename to contributed_definitions/NXdata_photoemission_detector.nxdl.xml index c681b95425..05a9ab6845 100644 --- a/contributed_definitions/NXdata_mpes_detector.nxdl.xml +++ b/contributed_definitions/NXdata_photoemission_detector.nxdl.xml @@ -21,13 +21,13 @@ # # For further information, see http://www.nexusformat.org --> - + - :ref:`NXdata_mpes_detector` describes the plottable data and related dimension scales - for raw detector data in MPES experiments. + :ref:`NXdata__photoemission_detector` describes the plottable data and related + dimension scales for raw detector data in _photoemission experiments. It extends the NXdata class and provides a glossary of explicitly named axis names - which are typical for raw MPES data. + which are typical for raw _photoemission data. diff --git a/contributed_definitions/NXprocess_mpes.nxdl.xml b/contributed_definitions/NXprocess_photoemission.nxdl.xml similarity index 92% rename from contributed_definitions/NXprocess_mpes.nxdl.xml rename to contributed_definitions/NXprocess_photoemission.nxdl.xml index 585bc972f9..481392162e 100644 --- a/contributed_definitions/NXprocess_mpes.nxdl.xml +++ b/contributed_definitions/NXprocess_photoemission.nxdl.xml @@ -21,13 +21,13 @@ # # For further information, see http://www.nexusformat.org --> - + - :ref:`NXprocess_mpes` describes events of data processing, reconstruction, - or analysis for MPES-related data. + :ref:`NXprocess_photoemission` describes events of data processing, reconstruction, + or analysis for photoemission-related data. It extends the NXprocess class and provides a glossary of explicitly named processes - and their metadata which are typical for MPES data. + and their metadata which are typical for photoemission data. @@ -94,9 +94,9 @@ The binding energy (in units of eV) that the specified emission line appeared at, after adjusting the binding energy scale. - This concept is related to term `12.16_ ff.`_ of the ISO 18115-1:2023 standard. + This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. - .. _12.16_ ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 diff --git a/contributed_definitions/nyaml/NXdata_mpes.yaml b/contributed_definitions/nyaml/NXdata_photoemission.yaml similarity index 98% rename from contributed_definitions/nyaml/NXdata_mpes.yaml rename to contributed_definitions/nyaml/NXdata_photoemission.yaml index 8a66973cd2..121fc918ff 100644 --- a/contributed_definitions/nyaml/NXdata_mpes.yaml +++ b/contributed_definitions/nyaml/NXdata_photoemission.yaml @@ -1,12 +1,12 @@ category: base doc: | - :ref:`NXdata_mpes` describes the plottable data and related dimension scales in MPES + :ref:`NXdata_photoemission` describes the plottable data and related dimension scales in photoemission experiments. It extends the NXdata class and provides a glossary of explicitly named axis names - which are typical for MPES data. + which are typical for photoemission data. type: group -NXdata_mpes(NXdata): +NXdata_photoemission(NXdata): energy(NX_NUMBER): unit: NX_ENERGY doc: | diff --git a/contributed_definitions/nyaml/NXdata_mpes_detector.yaml b/contributed_definitions/nyaml/NXdata_photoemission_detector.yaml similarity index 98% rename from contributed_definitions/nyaml/NXdata_mpes_detector.yaml rename to contributed_definitions/nyaml/NXdata_photoemission_detector.yaml index ccf82e6045..2283bd152a 100644 --- a/contributed_definitions/nyaml/NXdata_mpes_detector.yaml +++ b/contributed_definitions/nyaml/NXdata_photoemission_detector.yaml @@ -1,12 +1,12 @@ category: base doc: | - :ref:`NXdata_mpes_detector` describes the plottable data and related dimension scales - for raw detector data in MPES experiments. + :ref:`NXdata__photoemission_detector` describes the plottable data and related + dimension scales for raw detector data in _photoemission experiments. It extends the NXdata class and provides a glossary of explicitly named axis names - which are typical for raw MPES data. + which are typical for raw _photoemission data. type: group -NXdata_mpes_detector(NXdata): +NXdata_photoemission_detector(NXdata): \@signal: enumeration: [raw] raw(NX_NUMBER): diff --git a/contributed_definitions/nyaml/NXprocess_mpes.yaml b/contributed_definitions/nyaml/NXprocess_photoemission.yaml similarity index 97% rename from contributed_definitions/nyaml/NXprocess_mpes.yaml rename to contributed_definitions/nyaml/NXprocess_photoemission.yaml index bf1833a521..a0d9157ce3 100644 --- a/contributed_definitions/nyaml/NXprocess_mpes.yaml +++ b/contributed_definitions/nyaml/NXprocess_photoemission.yaml @@ -1,12 +1,12 @@ category: base doc: | - :ref:`NXprocess_mpes` describes events of data processing, reconstruction, - or analysis for MPES-related data. + :ref:`NXprocess_photoemission` describes events of data processing, reconstruction, + or analysis for photoemission-related data. It extends the NXprocess class and provides a glossary of explicitly named processes - and their metadata which are typical for MPES data. + and their metadata which are typical for photoemission data. type: group -NXprocess_mpes(NXprocess): +NXprocess_photoemission(NXprocess): energy_calibration(NXcalibration): doc: | Calibration event on the energy axis. @@ -60,7 +60,7 @@ NXprocess_mpes(NXprocess): - | xref: spec: ISO 18115-1:2023 - term: 12.16_ ff. + term: 12.16 url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 offset(NX_FLOAT): doc: | From 60cb6f859338c44379ef2eb9e4d512b8bce30c30 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 16 Feb 2024 16:57:36 +0100 Subject: [PATCH 0571/1012] add calibration for each defined axis in photoemission --- .../NXprocess_photoemission.nxdl.xml | 142 +++++++++- .../nyaml/NXprocess_photoemission.yaml | 260 ++++++++++++++++-- 2 files changed, 372 insertions(+), 30 deletions(-) diff --git a/contributed_definitions/NXprocess_photoemission.nxdl.xml b/contributed_definitions/NXprocess_photoemission.nxdl.xml index 481392162e..6dfde182d2 100644 --- a/contributed_definitions/NXprocess_photoemission.nxdl.xml +++ b/contributed_definitions/NXprocess_photoemission.nxdl.xml @@ -21,14 +21,40 @@ # # For further information, see http://www.nexusformat.org --> - + :ref:`NXprocess_photoemission` describes events of data processing, reconstruction, or analysis for photoemission-related data. It extends the NXprocess class and provides a glossary of explicitly named processes and their metadata which are typical for photoemission data. + + For now, the extension of NXprocess is performed by simply copying all existing groups, fields, + and attibute from NXprocess. In the future, it is envisioned that this extension can be solved by + base class inheritance. + + + Name of the program used + + + + + Sequence index of processing, + for determining the order of multiple **NXprocess** steps. + Starts with 1. + + + + + Version of the program used + + + + + Date and time of processing. + + Calibration event on the energy axis. @@ -38,30 +64,91 @@ .. _ISO 15472:2010: https://www.iso.org/standard/74811.html - + This is the calibrated energy axis to be used for data plotting. - + + + Calibration event of the momentum axis. + + + This is the momentum axis to be used for data plotting. + + + + + + Calibration event on a k-space axis. + + It is envisioned that the individual calibrations for each angle are + stored as kx_calibration, ky_calibration, kz_calibration, in accordance + with the axis name definitions in NXdata_photoemission. + + + + This is the calibrated k-space axis to be used for data plotting. + + + + + + Calibration event of an angular axis. + + It is envisioned that the individual calibrations for each angle are + stored as angular0_calibration, angular1_calibration, etc., in accordance + with the axis name definitions in NXdata_photoemission. + + This is the calibrated angular axis to be used for data plotting. - - + + + Calibration event of a spatial axis. + + It is envisioned that the individual calibrations for each angle are + stored as spatial0_calibration, spatial1_calibration, etc., in accordance + with the axis name definitions in NXdata_photoemission. + + This is the calibrated spatial axis to be used for data plotting. - - + + + Calibration event of the delay time. + + - This is the momentum axis to be used for data plotting. + This is the calibrated delay time axis to be used for data plotting. + + + + + + Calibration event of the beam polarization angle. + + + + This is the calibrated polarization angle axis to be used for data plotting. + + + + + + Calibration event of the ellipticity of the incoming or outgoing beam. + + + + This is the calibrated ellipticity axis to be used for data plotting. @@ -105,7 +192,7 @@ emission line. - + This is the calibrated energy axis to be used for data plotting. @@ -156,4 +243,41 @@ + + + Describes the operations of image registration + + + + + Describes the operations of image distortion correction + + + + + Describes the operations of calibration procedures, e.g. axis calibrations. + + + + + The note will contain information about how the data was processed + or anything about the data provenance. + The contents of the note can be anything that the processing code + can understand, or simple text. + + The name will be numbered to allow for ordering of steps. + + + + + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + + diff --git a/contributed_definitions/nyaml/NXprocess_photoemission.yaml b/contributed_definitions/nyaml/NXprocess_photoemission.yaml index a0d9157ce3..420823c2c0 100644 --- a/contributed_definitions/nyaml/NXprocess_photoemission.yaml +++ b/contributed_definitions/nyaml/NXprocess_photoemission.yaml @@ -5,8 +5,26 @@ doc: | It extends the NXprocess class and provides a glossary of explicitly named processes and their metadata which are typical for photoemission data. + + For now, the extension of NXprocess is performed by simply copying all existing groups, fields, + and attibute from NXprocess. In the future, it is envisioned that this extension can be solved by + base class inheritance. type: group -NXprocess_photoemission(NXprocess): +NXprocess_photoemission(NXobject): + program(NX_CHAR): + doc: | + Name of the program used + sequence_index(NX_POSINT): + doc: | + Sequence index of processing, + for determining the order of multiple **NXprocess** steps. + Starts with 1. + version(NX_CHAR): + doc: | + Version of the program used + date(NX_DATE_TIME): + doc: | + Date and time of processing. energy_calibration(NXcalibration): doc: | Calibration event on the energy axis. @@ -16,21 +34,69 @@ NXprocess_photoemission(NXprocess): .. _ISO 15472:2010: https://www.iso.org/standard/74811.html calibrated_axis(NX_FLOAT): + unit: NX_ENERGY doc: | This is the calibrated energy axis to be used for data plotting. - angular_calibration(NXcalibration): + momentum_calibration(NXcalibration): + doc: | + Calibration event of the momentum axis. calibrated_axis(NX_FLOAT): + doc: | + This is the momentum axis to be used for data plotting. + kK_calibration(NXcalibration): + doc: | + Calibration event on a k-space axis. + + It is envisioned that the individual calibrations for each angle are + stored as kx_calibration, ky_calibration, kz_calibration, in accordance + with the axis name definitions in NXdata_photoemission. + calibrated_axis(NX_FLOAT): + unit: NX_WAVENUMBER + doc: | + This is the calibrated k-space axis to be used for data plotting. + angularANGLE_calibration(NXcalibration): + doc: | + Calibration event of an angular axis. + + It is envisioned that the individual calibrations for each angle are + stored as angular0_calibration, angular1_calibration, etc., in accordance + with the axis name definitions in NXdata_photoemission. + calibrated_axis(NX_FLOAT): + unit: NX_ANGLE doc: | This is the calibrated angular axis to be used for data plotting. - spatial_calibration(NXcalibration): + spatialSPATIAL_calibration(NXcalibration): + doc: | + Calibration event of a spatial axis. + + It is envisioned that the individual calibrations for each angle are + stored as spatial0_calibration, spatial1_calibration, etc., in accordance + with the axis name definitions in NXdata_photoemission. calibrated_axis(NX_FLOAT): + unit: NX_LENGTH doc: | This is the calibrated spatial axis to be used for data plotting. - momentum_calibration(NXcalibration): - exists: optional + delay_calibration(NXcalibration): + doc: | + Calibration event of the delay time. calibrated_axis(NX_FLOAT): + unit: NX_TIME doc: | - This is the momentum axis to be used for data plotting. + This is the calibrated delay time axis to be used for data plotting. + polarization_angle_calibration(NXcalibration): + doc: | + Calibration event of the beam polarization angle. + calibrated_axis(NX_FLOAT): + unit: NX_ANGLE + doc: | + This is the calibrated polarization angle axis to be used for data plotting. + ellipticity_calibration(NXcalibration): + doc: | + Calibration event of the ellipticity of the incoming or outgoing beam. + calibrated_axis(NX_FLOAT): + unit: NX_ANGLE + doc: | + This is the calibrated ellipticity axis to be used for data plotting. energy_referencing(NXcalibration): doc: - | @@ -67,6 +133,7 @@ NXprocess_photoemission(NXprocess): Offset between measured binding energy and calibrated binding energy of the emission line. calibrated_axis(NX_FLOAT): + unit: NX_ENERGY doc: | This is the calibrated energy axis to be used for data plotting. @@ -102,9 +169,36 @@ NXprocess_photoemission(NXprocess): dimensions: rank: 1 dim: [[1, n_transmission_function]] + (NXregistration): + doc: | + Describes the operations of image registration + (NXdistortion): + doc: | + Describes the operations of image distortion correction + (NXcalibration): + doc: | + Describes the operations of calibration procedures, e.g. axis calibrations. + (NXnote): + doc: | + The note will contain information about how the data was processed + or anything about the data provenance. + The contents of the note can be anything that the processing code + can understand, or simple text. + + The name will be numbered to allow for ordering of steps. + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8c2be91055cba41fd23b23cc1ec13a132da3afa32a9fb666f8242e34c864aa68 +# af4a363f3fe84129dc0f4bdd01815acd70e2910cb6b00a760cc3643770ab39a6 # # # -# +# # -# :ref:`NXprocess_mpes` describes events of data processing, reconstruction, -# or analysis for MPES-related data. +# :ref:`NXprocess_photoemission` describes events of data processing, reconstruction, +# or analysis for photoemission-related data. # # It extends the NXprocess class and provides a glossary of explicitly named processes -# and their metadata which are typical for MPES data. +# and their metadata which are typical for photoemission data. +# +# For now, the extension of NXprocess is performed by simply copying all existing groups, fields, +# and attibute from NXprocess. In the future, it is envisioned that this extension can be solved by +# base class inheritance. # +# +# +# Name of the program used +# +# +# +# +# Sequence index of processing, +# for determining the order of multiple **NXprocess** steps. +# Starts with 1. +# +# +# +# +# Version of the program used +# +# +# +# +# Date and time of processing. +# +# # # # Calibration event on the energy axis. @@ -145,30 +265,91 @@ NXprocess_photoemission(NXprocess): # # .. _ISO 15472:2010: https://www.iso.org/standard/74811.html # -# +# # # This is the calibrated energy axis to be used for data plotting. # # # -# +# +# +# Calibration event of the momentum axis. +# # # +# This is the momentum axis to be used for data plotting. +# +# +# +# +# +# Calibration event on a k-space axis. +# +# It is envisioned that the individual calibrations for each angle are +# stored as kx_calibration, ky_calibration, kz_calibration, in accordance +# with the axis name definitions in NXdata_photoemission. +# +# +# +# This is the calibrated k-space axis to be used for data plotting. +# +# +# +# +# +# Calibration event of an angular axis. +# +# It is envisioned that the individual calibrations for each angle are +# stored as angular0_calibration, angular1_calibration, etc., in accordance +# with the axis name definitions in NXdata_photoemission. +# +# +# # This is the calibrated angular axis to be used for data plotting. # # # -# -# +# +# +# Calibration event of a spatial axis. +# +# It is envisioned that the individual calibrations for each angle are +# stored as spatial0_calibration, spatial1_calibration, etc., in accordance +# with the axis name definitions in NXdata_photoemission. +# +# # # This is the calibrated spatial axis to be used for data plotting. # # # -# -# +# +# +# Calibration event of the delay time. +# +# # -# This is the momentum axis to be used for data plotting. +# This is the calibrated delay time axis to be used for data plotting. +# +# +# +# +# +# Calibration event of the beam polarization angle. +# +# +# +# This is the calibrated polarization angle axis to be used for data plotting. +# +# +# +# +# +# Calibration event of the ellipticity of the incoming or outgoing beam. +# +# +# +# This is the calibrated ellipticity axis to be used for data plotting. # # # @@ -201,9 +382,9 @@ NXprocess_photoemission(NXprocess): # The binding energy (in units of eV) that the specified emission line appeared at, # after adjusting the binding energy scale. # -# This concept is related to term `12.16_ ff.`_ of the ISO 18115-1:2023 standard. +# This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. # -# .. _12.16_ ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 +# .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 # # # @@ -212,7 +393,7 @@ NXprocess_photoemission(NXprocess): # emission line. # # -# +# # # This is the calibrated energy axis to be used for data plotting. # @@ -263,4 +444,41 @@ NXprocess_photoemission(NXprocess): # # # +# +# +# Describes the operations of image registration +# +# +# +# +# Describes the operations of image distortion correction +# +# +# +# +# Describes the operations of calibration procedures, e.g. axis calibrations. +# +# +# +# +# The note will contain information about how the data was processed +# or anything about the data provenance. +# The contents of the note can be anything that the processing code +# can understand, or simple text. +# +# The name will be numbered to allow for ordering of steps. +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group. +# +# It is recommended (as of NIAC2014) to use this attribute +# to help define the path to the default dataset to be plotted. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# +# # From 7593919e5bcadb6e8c9e4c72e3903377ab24c42c Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 16 Feb 2024 16:58:00 +0100 Subject: [PATCH 0572/1012] add momentum axis to photoemission data --- .../NXdata_photoemission.nxdl.xml | 8 +++++ .../NXdata_photoemission_detector.nxdl.xml | 8 +++++ .../nyaml/NXdata_photoemission.yaml | 23 +++++++++++--- .../nyaml/NXdata_photoemission_detector.yaml | 31 ++++++++++++++----- 4 files changed, 58 insertions(+), 12 deletions(-) diff --git a/contributed_definitions/NXdata_photoemission.nxdl.xml b/contributed_definitions/NXdata_photoemission.nxdl.xml index 1685771b1f..ead6a0b94b 100644 --- a/contributed_definitions/NXdata_photoemission.nxdl.xml +++ b/contributed_definitions/NXdata_photoemission.nxdl.xml @@ -65,6 +65,14 @@ + + + Calibrated momentum axis. + Units are kg*m/s. + + + + Calibrated x axis in k-space. diff --git a/contributed_definitions/NXdata_photoemission_detector.nxdl.xml b/contributed_definitions/NXdata_photoemission_detector.nxdl.xml index 05a9ab6845..0a081a3248 100644 --- a/contributed_definitions/NXdata_photoemission_detector.nxdl.xml +++ b/contributed_definitions/NXdata_photoemission_detector.nxdl.xml @@ -85,6 +85,14 @@ + + + Calibrated momentum axis. + Units are kg*m/s. + + + + (Un)calibrated x axis in k-space. diff --git a/contributed_definitions/nyaml/NXdata_photoemission.yaml b/contributed_definitions/nyaml/NXdata_photoemission.yaml index 121fc918ff..95034a3b17 100644 --- a/contributed_definitions/nyaml/NXdata_photoemission.yaml +++ b/contributed_definitions/nyaml/NXdata_photoemission.yaml @@ -40,6 +40,13 @@ NXdata_photoemission(NXdata): url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 \@energy_indices: \@energy_depends: + momentum(NX_NUMBER): + unit: NX_ANY + doc: | + Calibrated momentum axis. + Units are kg*m/s. + \@momentum_indices: + \@momentum_depends: kx(NX_NUMBER): unit: NX_WAVENUMBER doc: | @@ -114,7 +121,7 @@ NXdata_photoemission(NXdata): \@ellipticity_depends: # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 139998aac40c149120e327c03095c7a8f4ef4a5891cdbdb6ddc0e7dcfaeca8c9 +# 4e560e6cd492d4f85ec19c22d80ebd5f17f1ac9daa6e8c92df23c99a185f2ff7 # # # -# +# # -# :ref:`NXdata_mpes` describes the plottable data and related dimension scales in MPES +# :ref:`NXdata_photoemission` describes the plottable data and related dimension scales in photoemission # experiments. # # It extends the NXdata class and provides a glossary of explicitly named axis names -# which are typical for MPES data. +# which are typical for photoemission data. # # # @@ -182,6 +189,14 @@ NXdata_photoemission(NXdata): # # # +# +# +# Calibrated momentum axis. +# Units are kg*m/s. +# +# +# +# # # # Calibrated x axis in k-space. diff --git a/contributed_definitions/nyaml/NXdata_photoemission_detector.yaml b/contributed_definitions/nyaml/NXdata_photoemission_detector.yaml index 2283bd152a..133a0888e3 100644 --- a/contributed_definitions/nyaml/NXdata_photoemission_detector.yaml +++ b/contributed_definitions/nyaml/NXdata_photoemission_detector.yaml @@ -32,8 +32,8 @@ NXdata_photoemission_detector(NXdata): type: NX_CHAR doc: | The energy can be either stored as kinetic or as binding energy. - enumeration: - kinetic: + enumeration: + kinetic: doc: - | (Un)calibrated kinetic energy axis. @@ -42,7 +42,7 @@ NXdata_photoemission_detector(NXdata): spec: ISO 18115-1:2023 term: 3.35 url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 - binding: + binding: doc: - | (Un)calibrated binding energy axis. @@ -53,6 +53,13 @@ NXdata_photoemission_detector(NXdata): url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 \@energy_indices: \@energy_depends: + momentum(NX_NUMBER): + unit: NX_ANY + doc: | + Calibrated momentum axis. + Units are kg*m/s. + \@momentum_indices: + \@momentum_depends: kx(NX_NUMBER): unit: NX_WAVENUMBER doc: | @@ -144,7 +151,7 @@ NXdata_photoemission_detector(NXdata): and write it to the top-level NXdata. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 9428309dfa7497a26a3ea053ed9dae2d45a66d718656630be27e13e20611012d +# 6b643f26d0adf60a48956f2db9bcc2dfc6847d0cce47140e6bb2b0d3a775fcd8 # # # -# +# # -# :ref:`NXdata_mpes_detector` describes the plottable data and related dimension scales -# for raw detector data in MPES experiments. +# :ref:`NXdata__photoemission_detector` describes the plottable data and related +# dimension scales for raw detector data in _photoemission experiments. # # It extends the NXdata class and provides a glossary of explicitly named axis names -# which are typical for raw MPES data. +# which are typical for raw _photoemission data. # # # @@ -232,6 +239,14 @@ NXdata_photoemission_detector(NXdata): # # # +# +# +# Calibrated momentum axis. +# Units are kg*m/s. +# +# +# +# # # # (Un)calibrated x axis in k-space. From bafd3ed6daa92272e0002c256d40ace48a970b34 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 16 Feb 2024 17:14:57 +0100 Subject: [PATCH 0573/1012] use specialized photoemission data and process base classes --- .../NXphotoemission.nxdl.xml | 189 +++------- .../nyaml/NXphotoemission.yaml | 337 ++++-------------- 2 files changed, 114 insertions(+), 412 deletions(-) diff --git a/contributed_definitions/NXphotoemission.nxdl.xml b/contributed_definitions/NXphotoemission.nxdl.xml index fe8d1131c3..77d4fc0498 100644 --- a/contributed_definitions/NXphotoemission.nxdl.xml +++ b/contributed_definitions/NXphotoemission.nxdl.xml @@ -358,7 +358,7 @@ - + Contains the raw data collected by the detector before calibration. The data which is considered raw might change from experiment to experiment @@ -366,12 +366,13 @@ This field ideally collects the data with the lowest level of processing possible. - The naming of fields should follow a convention to ensure compatibility. - It is recommend to use the following field names: + The naming of fields should follow the convention defined in the + :ref:`NXdata_photoemission_detector` base class: - **pixel_x**: Detector pixel in x direction. - **pixel_y**: Detector pixel in y direction. - **energy**: (Un)calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). + - **momentum**: Calibrated momentum axis. Unit category: NX_ANY (e.g., kg*m/s). - **kx**: (Un)calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). - **ky**: (Un)calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). - **kz**: (Un)calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). @@ -536,121 +537,48 @@ - + 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 + The appropriate axis calibrations for a given experiment should be described using + one or more of the following NXcalibrations. The individual calibrations for a given + `AXISNAME` in `data` should be called `AXISNAME_calibration`. - - Calibration event on the energy axis. - - For XPS, the calibration should ideally be performed according to - `ISO 15472:2010`_ specification. - - .. _ISO 15472:2010: https://www.iso.org/standard/74811.html - - - - This is the calibrated energy axis to be used for data plotting. - - + - - - - This is the calibrated angular axis to be used for data plotting. - - + + - - - - This is the calibrated spatial axis to be used for data plotting. - - + + - - - - This is the momentum axis to be used for data plotting. - - + + + + + + + + + + + + + + - - For energy referencing, the measured energies are corrected for the charging potential - (i.e., the electrical potential of the surface region of an insulating sample, caused by - irradiation) such that those energies correspond to a sample with no surface charge. - Usually, the energy axis is adjusted by shifting all energies uniformally until one - well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. - - This concept is related to term `12.74 ff.`_ of the ISO 18115-1:2023 standard. - - .. _12.74 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 - - - - Electronic core or valence level that was used for the calibration. - - - - - Reference peak that was used for the calibration. - - For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge | vacuum level - - - - - The binding energy (in units of eV) that the specified emission line appeared at, - after adjusting the binding energy scale. - - This concept is related to term `12.16 ff.`_ of the ISO 18115-1:2023 standard. - - .. _12.16 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - - - - - Offset between measured binding energy and calibrated binding energy of the - emission line. - - - - - This is the calibrated energy axis to be used for data plotting. - - This should link to /entry/data/energy. - - + + + + + - - In the transmission correction, each intensity measurement for electrons of a given - kinetic energy is multiplied by the corresponding value in the relative_intensity - field of the transmission_function. This calibration procedure is used to account for - the different tranmsission efficiencies when using different lens modes. - - - Transmission function of the electron analyser. - - The transmission function (TF) specifies the detection efficiency for electrons of - different kinetic energy passing through the electron analyser. - This can be a link to /entry/instrument/electronanalyser/transmission_function. - - - - - - - - - - - + + Kinetic energy values @@ -803,16 +731,18 @@ - + The default NXdata field containing a view on the measured data. This NXdata field contains a collection of the main relevant fields (axes). If you want to provide additional views on your data, you can additionally use the generic NXdata group of NXentry. - The data fields inside this NXdata group should be named according to conventions - to ensure compatibility. We recommened the following field names - for common data fields: + The naming of fields should follow the convention defined in the + :ref:`NXdata_photoemission` base class: + + - **energy**: Calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). + - **momentum**: Calibrated momentum axis. Unit category: NX_ANY (e.g., kg*m/s). - **kx**: Calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). - **ky**: Calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). - **kz**: Calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). @@ -848,45 +778,6 @@ actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - Calibrated energy axis. - - This could be a link to either - /entry/process/energy_calibration/calibrated_axis or - /entry/process/energy_correction/calibrated_axis. - - - - The energy can be either stored as kinetic or as binding energy. - - - - - Calibrated kinetic energy axis. - - In case the kinetic energy axis is referenced to the Fermi level :math:`E_F` - (e.g., in entry/process/energy_referencing), kinetic energies :math:`E` are - provided as :math:`E-E_F`. - - This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. - - .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 - - - - - Calibrated binding energy axis. - - This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. - - .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - - - - - - The energy can be dispersed according to different strategies. ``energy_depends`` points to diff --git a/contributed_definitions/nyaml/NXphotoemission.yaml b/contributed_definitions/nyaml/NXphotoemission.yaml index 6aaa84287a..810a258bb6 100644 --- a/contributed_definitions/nyaml/NXphotoemission.yaml +++ b/contributed_definitions/nyaml/NXphotoemission.yaml @@ -299,7 +299,7 @@ NXphotoemission(NXobject): exists: recommended identifier: exists: recommended - raw_data(NXdata): + raw_data(NXdata_photoemission_detector): exists: recommended doc: | Contains the raw data collected by the detector before calibration. @@ -308,12 +308,13 @@ NXphotoemission(NXobject): This field ideally collects the data with the lowest level of processing possible. - The naming of fields should follow a convention to ensure compatibility. - It is recommend to use the following field names: + The naming of fields should follow the convention defined in the + :ref:`NXdata_photoemission_detector` base class: - **pixel_x**: Detector pixel in x direction. - **pixel_y**: Detector pixel in y direction. - **energy**: (Un)calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). + - **momentum**: Calibrated momentum axis. Unit category: NX_ANY (e.g., kg*m/s). - **kx**: (Un)calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). - **ky**: (Un)calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). - **kz**: (Un)calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). @@ -458,107 +459,62 @@ NXphotoemission(NXobject): doc: | In the case of an experiment in which the electron current is changed and recorded with time stamps, this is an array of length m of current setpoints. - (NXprocess): + (NXprocess_photoemission): exists: recommended doc: | 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 + The appropriate axis calibrations for a given experiment should be described using + one or more of the following NXcalibrations. The individual calibrations for a given + `AXISNAME` in `data` should be called `AXISNAME_calibration`. energy_calibration(NXcalibration): exists: optional - doc: | - Calibration event on the energy axis. - - For XPS, the calibration should ideally be performed according to - `ISO 15472:2010`_ specification. - - .. _ISO 15472:2010: https://www.iso.org/standard/74811.html calibrated_axis(NX_FLOAT): exists: recommended - doc: | - This is the calibrated energy axis to be used for data plotting. - angular_calibration(NXcalibration): + momentum_calibration(NXcalibration): exists: optional calibrated_axis(NX_FLOAT): exists: recommended - doc: | - This is the calibrated angular axis to be used for data plotting. - spatial_calibration(NXcalibration): + kK_calibration(NXcalibration): exists: optional calibrated_axis(NX_FLOAT): exists: recommended - doc: | - This is the calibrated spatial axis to be used for data plotting. - momentum_calibration(NXcalibration): + angularANGLE_calibration(NXcalibration): + exists: optional + calibrated_axis(NX_FLOAT): + exists: recommended + spatialSPATIAL_calibration(NXcalibration): + exists: optional + calibrated_axis(NX_FLOAT): + exists: recommended + delay_calibration(NXcalibration): + exists: optional + calibrated_axis(NX_FLOAT): + exists: recommended + polarization_angle_calibration(NXcalibration): + exists: optional + calibrated_axis(NX_FLOAT): + exists: recommended + ellipticity_calibration(NXcalibration): exists: optional calibrated_axis(NX_FLOAT): exists: recommended - doc: | - This is the momentum axis to be used for data plotting. energy_referencing(NXcalibration): exists: optional - doc: - - | - For energy referencing, the measured energies are corrected for the charging potential - (i.e., the electrical potential of the surface region of an insulating sample, caused by - irradiation) such that those energies correspond to a sample with no surface charge. - Usually, the energy axis is adjusted by shifting all energies uniformally until one - well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. - - | - xref: - spec: ISO 18115-1:2023 - term: 12.74 ff. - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 level(NXelectron_level): exists: recommended - doc: | - Electronic core or valence level that was used for the calibration. reference_peak: - doc: | - Reference peak that was used for the calibration. - - For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge | vacuum level binding_energy(NX_FLOAT): exists: recommended - doc: - - | - The binding energy (in units of eV) that the specified emission line appeared at, - after adjusting the binding energy scale. - - | - xref: - spec: ISO 18115-1:2023 - term: 12.16 ff. - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 offset(NX_FLOAT): exists: recommended - doc: | - Offset between measured binding energy and calibrated binding energy of the - emission line. calibrated_axis(NX_FLOAT): exists: recommended - doc: | - This is the calibrated energy axis to be used for data plotting. - - This should link to /entry/data/energy. transmission_correction(NXcalibration): exists: optional - doc: | - In the transmission correction, each intensity measurement for electrons of a given - kinetic energy is multiplied by the corresponding value in the relative_intensity - field of the transmission_function. This calibration procedure is used to account for - the different tranmsission efficiencies when using different lens modes. transmission_function(NXdata): exists: recommended - doc: | - Transmission function of the electron analyser. - - The transmission function (TF) specifies the detection efficiency for electrons of - different kinetic energy passing through the electron analyser. - This can be a link to /entry/instrument/electronanalyser/transmission_function. \@signal: - enumeration: [relative_intensity] \@axes: - enumeration: [kinetic_energy] kinetic_energy(NX_FLOAT): unit: NX_ENERGY doc: | @@ -680,16 +636,18 @@ NXphotoemission(NXobject): Flood gun creating a current of low-energy electrons. This should be a link to /entry/instrument/flood_gun. - data(NXdata): + data(NXdata_photoemission): doc: | The default NXdata field containing a view on the measured data. This NXdata field contains a collection of the main relevant fields (axes). If you want to provide additional views on your data, you can additionally use the generic NXdata group of NXentry. - The data fields inside this NXdata group should be named according to conventions - to ensure compatibility. We recommened the following field names - for common data fields: + The naming of fields should follow the convention defined in the + :ref:`NXdata_photoemission` base class: + + - **energy**: Calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). + - **momentum**: Calibrated momentum axis. Unit category: NX_ANY (e.g., kg*m/s). - **kx**: Calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). - **ky**: Calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). - **kz**: Calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). @@ -720,44 +678,6 @@ NXphotoemission(NXobject): 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. - energy(NX_NUMBER): - exists: optional - unit: NX_ENERGY - doc: | - Calibrated energy axis. - - This could be a link to either - /entry/process/energy_calibration/calibrated_axis or - /entry/process/energy_correction/calibrated_axis. - \@type: - type: NX_CHAR - doc: | - The energy can be either stored as kinetic or as binding energy. - enumeration: - kinetic: - doc: - - | - Calibrated kinetic energy axis. - - | - In case the kinetic energy axis is referenced to the Fermi level :math:`E_F` - (e.g., in entry/process/energy_referencing), kinetic energies :math:`E` are - provided as :math:`E-E_F`. - - | - xref: - spec: ISO 18115-1:2023 - term: 3.35 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 - binding: - doc: - - | - Calibrated binding energy axis. - - | - xref: - spec: ISO 18115-1:2023 - term: 12.16 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - \@energy_indices: - exists: optional \@energy_depends: type: NX_CHAR exists: optional @@ -769,7 +689,7 @@ NXphotoemission(NXobject): @energy_depends: 'entry/process/energy_calibration' # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 63abae195ecdd7adca18aa0b53f3e94f6b8f48832d7b99753440ecfc15beb5cd +# 531384150dd33fe81aa169d873245142c7b47d08bb1f4ec3a8d0d846dfb06f8b # # # - + + + + + These symbols will be used below to coordinate fields with the same + shape. + + + + rank of the ``DATA`` field + + + + + length of the ``AXISNAME`` field + + + + + length of the ``x`` field + + + + + length of the ``y`` field + + + + + length of the ``z`` field + + + :ref:`NXdata_photoemission` describes the plottable data and related dimension scales in photoemission experiments. It extends the NXdata class and provides a glossary of explicitly named axis names which are typical for photoemission data. + + For now, the extension of NXdata is performed by simply copying all existing groups, fields, + and attibute from NXdata. In the future, it is envisioned that this extension can be solved by + base class inheritance. + + .. 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) + + + .. index:: plotting + + Array of strings holding the :ref:`names <validItemName>` of additional + signals to be plotted with the default :ref:`signal </NXdata@signal-attribute>`. + These fields or links *must* exist and be direct children of this NXdata group. + + Each auxiliary signal needs to be of the same shape as the default signal. + + .. NIAC2018: + https://www.nexusformat.org/NIAC2018Minutes.html + + + + + .. 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 <validItemName>` 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. + + + + + + + + .. index:: plotting + + Array of strings holding the :ref:`names <validItemName>` of + the independent data fields used in the default plot for all of + the dimensions of the :ref:`signal </NXdata@signal-attribute>` + as well as any :ref:`auxiliary signals </NXdata@auxiliary_signals-attribute>`. + + 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. + + + + + + + Each ``AXISNAME_indices`` attribute indicates the dependency + relationship of the ``AXISNAME`` field (where ``AXISNAME`` + is the name of a field that exists in this ``NXdata`` group) + with one or more dimensions of the plottable data. + + Integer array that defines the indices of the *signal* field + (that field will be a multidimensional array) + which need to be used in the *AXISNAME* field in + order to reference the corresponding axis value. + + The first index of an array is ``0`` (zero). + + Here, *AXISNAME* is to be replaced by the name of each + field described in the ``axes`` attribute. + An example with 2-D data, :math:`d(t,P)`, will illustrate:: + + data_2d:NXdata + @signal="data" + @axes=["time", "pressure"] + @time_indices=0 + @pressure_indices=1 + data: float[1000,20] + time: float[1000] + pressure: float[20] + + This attribute is to be provided in all situations. + However, if the indices attributes are missing + (such as for data files written before this specification), + file readers are encouraged to make their best efforts + to plot the data. + Thus the implementation of the + ``AXISNAME_indices`` attribute is based on the model of + "strict writer, liberal reader". + + .. note:: Attributes potentially containing multiple values + (axes and _indices) are to be written as string or integer arrays, + to avoid string parsing in reading applications. + + + + + Points to the path of a field defining the axis on which the ``AXISNAME`` axis depends. + + This concept allows to link an axis to a respective field in the NeXus hierarchy, thereby + defining the physical quantity it represents. + + Here, *AXISNAME* is to be replaced by the name of each + field described in the ``axes`` attribute. + + Examples: + If a calibration has been performed, ``@AXISNAME_depends`` links to the result of + that calibration: + + @AXISNAME_depends: '/entry/process/calibration/calibrated_axis' + + If the axis corresponds to a coordinate of a detector, ``@AXISNAME_depends`` links + to that detector axis: + + @AXISNAME_depends: '/entry/instrument/detector/axis/some_axis' for a 2D detector + + If the axis is a scanned motor, ``@AXISNAME_depends`` links to the transformation + describing the respective motion, e.g.: + + @AXISNAME_depends: '/entry/instrument/detector/transformations/some_transformation' for a motion of the detector + + + + + 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. + + + + A *dimension scale* must have a rank of 1 and has length ``n``. + + + + + + Axis label + + + + + ``0|false``: single value, + ``1|true``: multiple values + + + + + Index of first good value + + + + + Index of last good value + + + + + Index (positive integer) identifying this specific set of numbers. + + N.B. The ``axis`` attribute is the old way of designating a link. + Do not use the ``axes`` attribute with the ``axis`` attribute. + The ``axes`` *group* attribute is now preferred. + + + + + + "Errors" (meaning *uncertainties* or *standard deviations*) + associated with any field named ``FIELDNAME`` in this ``NXdata`` + group (e.g. an axis, signal or auxiliary signal). + + The dimensions of the ``FIELDNAME_errors`` field must match + the dimensions of the ``FIELDNAME`` field. + + + + + .. 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. + + + + The rank (``dataRank``) of the ``data`` must satisfy + ``1 <= dataRank <= NX_MAXRANK=32``. + At least one ``dim`` must have length ``n``. + + + + + .. index:: plotting + + Plottable (independent) axis, indicate index number. + Only one field in a :ref:`NXdata` group may have the + ``signal=1`` attribute. + Do not use the ``signal`` attribute with the ``axis`` attribute. + + + + + Defines the names of the dimension scales + (independent axes) for this data set + as a colon-delimited array. + NOTE: The ``axes`` attribute is the preferred + method of designating a link. + Do not use the ``axes`` attribute with the ``axis`` attribute. + + + + + data label + + + + + + Standard deviations of data values - + the data array is identified by the group attribute ``signal``. + The ``errors`` array must have the same dimensions as ``DATA``. + Client is responsible for defining the dimensions of the data. + + + + The ``errors`` must have + the same rank (``dataRank``) + as the ``data``. + At least one ``dim`` must have length "n". + + + + + + The elements in data are usually float values really. For + efficiency reasons these are usually stored as integers + after scaling with a scale factor. This value is the scale + factor. It is required to get the actual physical value, + when necessary. + + + + + An optional offset to apply to the values in data. + + + + + Title for the plot. + + + + + This is an array holding the values to use for the x-axis of + data. The units must be appropriate for the measurement. + + + + + + + + This is an array holding the values to use for the y-axis of + data. The units must be appropriate for the measurement. + + + + + + + + This is an array holding the values to use for the z-axis of + data. The units must be appropriate for the measurement. + + + + + Calibrated energy axis. - This could be a link to either + In an application definition, this could be a link to either /entry/process/energy_calibration/calibrated_axis or /entry/process/energy_correction/calibrated_axis. @@ -138,7 +591,8 @@ Linear polarization angle of the incoming or outgoing beam. - Could be a link to /entry/instrument/beam/incident_polarization_angle or + In an application definition, this could be a link to + /entry/instrument/beam/incident_polarization_angle or /entry/instrument/beam/final_polarization_angle if they exist. @@ -149,7 +603,8 @@ Ellipticity of the incoming or outgoing beam. Can be any of linear polarization angle (degrees), ellipticity (arb. units). - Could be a link to /entry/instrument/beam/incident_ellipticity or + In an application definition, this could be a link to + /entry/instrument/beam/incident_ellipticity or /entry/instrument/beam/final_ellipticity if they exist. diff --git a/contributed_definitions/NXdata_photoemission_detector.nxdl.xml b/contributed_definitions/NXdata_photoemission_detector.nxdl.xml index 0a081a3248..760b698b71 100644 --- a/contributed_definitions/NXdata_photoemission_detector.nxdl.xml +++ b/contributed_definitions/NXdata_photoemission_detector.nxdl.xml @@ -21,19 +21,467 @@ # # For further information, see http://www.nexusformat.org --> - + + + + + These symbols will be used below to coordinate fields with the same + shape. + + + + rank of the ``DATA`` field + + + + + length of the ``AXISNAME`` field + + + + + length of the ``x`` field + + + + + length of the ``y`` field + + + + + length of the ``z`` field + + + :ref:`NXdata__photoemission_detector` describes the plottable data and related dimension scales for raw detector data in _photoemission experiments. It extends the NXdata class and provides a glossary of explicitly named axis names which are typical for raw _photoemission data. + + For now, the extension of NXdata is performed by simply copying all existing groups, fields, + and attibute from NXdata. In the future, it is envisioned that this extension can be solved by + base class inheritance. + + .. 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) + + + .. index:: plotting + + Array of strings holding the :ref:`names <validItemName>` of additional + signals to be plotted with the default :ref:`signal </NXdata@signal-attribute>`. + These fields or links *must* exist and be direct children of this NXdata group. + + Each auxiliary signal needs to be of the same shape as the default signal. + + .. NIAC2018: + https://www.nexusformat.org/NIAC2018Minutes.html + + + + .. 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 <validItemName>` 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. + + + + .. index:: plotting + + Array of strings holding the :ref:`names <validItemName>` of + the independent data fields used in the default plot for all of + the dimensions of the :ref:`signal </NXdata@signal-attribute>` + as well as any :ref:`auxiliary signals </NXdata@auxiliary_signals-attribute>`. + + 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. + + + + + + + Each ``AXISNAME_indices`` attribute indicates the dependency + relationship of the ``AXISNAME`` field (where ``AXISNAME`` + is the name of a field that exists in this ``NXdata`` group) + with one or more dimensions of the plottable data. + + Integer array that defines the indices of the *signal* field + (that field will be a multidimensional array) + which need to be used in the *AXISNAME* field in + order to reference the corresponding axis value. + + The first index of an array is ``0`` (zero). + + Here, *AXISNAME* is to be replaced by the name of each + field described in the ``axes`` attribute. + An example with 2-D data, :math:`d(t,P)`, will illustrate:: + + data_2d:NXdata + @signal="data" + @axes=["time", "pressure"] + @time_indices=0 + @pressure_indices=1 + data: float[1000,20] + time: float[1000] + pressure: float[20] + + This attribute is to be provided in all situations. + However, if the indices attributes are missing + (such as for data files written before this specification), + file readers are encouraged to make their best efforts + to plot the data. + Thus the implementation of the + ``AXISNAME_indices`` attribute is based on the model of + "strict writer, liberal reader". + + .. note:: Attributes potentially containing multiple values + (axes and _indices) are to be written as string or integer arrays, + to avoid string parsing in reading applications. + + + + + Points to the path of a field defining the axis on which the ``AXISNAME`` axis depends. + + This concept allows to link an axis to a respective field in the NeXus hierarchy, thereby + defining the physical quantity it represents. + + Here, *AXISNAME* is to be replaced by the name of each + field described in the ``axes`` attribute. + + Examples: + If a calibration has been performed, ``@AXISNAME_depends`` links to the result of + that calibration: + + @AXISNAME_depends: '/entry/process/calibration/calibrated_axis' + + If the axis corresponds to a coordinate of a detector, ``@AXISNAME_depends`` links + to that detector axis: + + @AXISNAME_depends: '/entry/instrument/detector/axis/some_axis' for a 2D detector + + If the axis is a scanned motor, ``@AXISNAME_depends`` links to the transformation + describing the respective motion, e.g.: + + @AXISNAME_depends: '/entry/instrument/detector/transformations/some_transformation' for a motion of the detector + + + + + 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. + + + + A *dimension scale* must have a rank of 1 and has length ``n``. + + + + + + Axis label + + + + + ``0|false``: single value, + ``1|true``: multiple values + + + + + Index of first good value + + + + + Index of last good value + + + + + Index (positive integer) identifying this specific set of numbers. + + N.B. The ``axis`` attribute is the old way of designating a link. + Do not use the ``axes`` attribute with the ``axis`` attribute. + The ``axes`` *group* attribute is now preferred. + + + + + + "Errors" (meaning *uncertainties* or *standard deviations*) + associated with any field named ``FIELDNAME`` in this ``NXdata`` + group (e.g. an axis, signal or auxiliary signal). + + The dimensions of the ``FIELDNAME_errors`` field must match + the dimensions of the ``FIELDNAME`` field. + + + + + .. 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. + + + + The rank (``dataRank``) of the ``data`` must satisfy + ``1 <= dataRank <= NX_MAXRANK=32``. + At least one ``dim`` must have length ``n``. + + + + + .. index:: plotting + + Plottable (independent) axis, indicate index number. + Only one field in a :ref:`NXdata` group may have the + ``signal=1`` attribute. + Do not use the ``signal`` attribute with the ``axis`` attribute. + + + + + Defines the names of the dimension scales + (independent axes) for this data set + as a colon-delimited array. + NOTE: The ``axes`` attribute is the preferred + method of designating a link. + Do not use the ``axes`` attribute with the ``axis`` attribute. + + + + + data label + + + + + + Standard deviations of data values - + the data array is identified by the group attribute ``signal``. + The ``errors`` array must have the same dimensions as ``DATA``. + Client is responsible for defining the dimensions of the data. + + + + The ``errors`` must have + the same rank (``dataRank``) + as the ``data``. + At least one ``dim`` must have length "n". + + + + + + The elements in data are usually float values really. For + efficiency reasons these are usually stored as integers + after scaling with a scale factor. This value is the scale + factor. It is required to get the actual physical value, + when necessary. + + + + + An optional offset to apply to the values in data. + + + + + Title for the plot. + + + + + This is an array holding the values to use for the x-axis of + data. The units must be appropriate for the measurement. + + + + + + + + This is an array holding the values to use for the y-axis of + data. The units must be appropriate for the measurement. + + + + + + + + This is an array holding the values to use for the z-axis of + data. The units must be appropriate for the measurement. + + + + + Raw data before calibration. @@ -191,7 +639,7 @@ setup - it would just know that it collected N images, which would flatten the external parameters to one axis, too. This can then be linked, e.g. with NXcalibration, to the appropriate fields in the instrument - and write it to the top-level NXdata. + and write it to the top-level NXdata_photoemission. diff --git a/contributed_definitions/NXprocess_photoemission.nxdl.xml b/contributed_definitions/NXprocess_photoemission.nxdl.xml index 6dfde182d2..6084adb5f6 100644 --- a/contributed_definitions/NXprocess_photoemission.nxdl.xml +++ b/contributed_definitions/NXprocess_photoemission.nxdl.xml @@ -26,12 +26,12 @@ :ref:`NXprocess_photoemission` describes events of data processing, reconstruction, or analysis for photoemission-related data. - It extends the NXprocess class and provides a glossary of explicitly named processes - and their metadata which are typical for photoemission data. + It extends the NXprocess class and provides a glossary of explicitly named processes + and their metadata which are typical for photoemission data. - For now, the extension of NXprocess is performed by simply copying all existing groups, fields, - and attibute from NXprocess. In the future, it is envisioned that this extension can be solved by - base class inheritance. + For now, the extension of NXprocess is performed by simply copying all existing groups, fields, + and attibute from NXprocess. In the future, it is envisioned that this extension can be solved by + base class inheritance. diff --git a/contributed_definitions/nyaml/NXdata_photoemission.yaml b/contributed_definitions/nyaml/NXdata_photoemission.yaml index 95034a3b17..1cf36ea091 100644 --- a/contributed_definitions/nyaml/NXdata_photoemission.yaml +++ b/contributed_definitions/nyaml/NXdata_photoemission.yaml @@ -5,14 +5,418 @@ doc: | It extends the NXdata class and provides a glossary of explicitly named axis names which are typical for photoemission data. + + For now, the extension of NXdata is performed by simply copying all existing groups, fields, + and attibute from NXdata. In the future, it is envisioned that this extension can be solved by + base class inheritance. + + .. 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) + +# The ignoreExtra* attributes are used in the definition to +# avoid warning messages that would be generated from unexpected fields or attributes. +# Since common use of NXdata indicates field names of any value, _many_ +# instances of this class would generate a warning message during validation +# without this attribute being set to "true". +symbols: + doc: | + These symbols will be used below to coordinate fields with the same + shape. + dataRank: | + rank of the ``DATA`` field + n: | + length of the ``AXISNAME`` field + nx: | + length of the ``x`` field + ny: | + length of the ``y`` field + nz: | + length of the ``z`` field type: group +ignoreExtraFields: true +ignoreExtraAttributes: true NXdata_photoemission(NXdata): + \@auxiliary_signals: + doc: | + .. index:: plotting + + Array of strings holding the :ref:`names ` of additional + signals to be plotted with the default :ref:`signal `. + These fields or links *must* exist and be direct children of this NXdata group. + + Each auxiliary signal needs to be of the same shape as the default signal. + + .. NIAC2018: + https://www.nexusformat.org/NIAC2018Minutes.html + \@signal: + doc: | + .. 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. + enumeration: [raw] + \@axes: + doc: | + .. 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. + \@AXISNAME_indices: + type: NX_INT + + # nxdl.xsd rules do not allow us to show this as a variable name + # - we'll use ALL CAPS (see #562) + + # AXISNAME_indices documentation copied from datarules.rst + doc: | + Each ``AXISNAME_indices`` attribute indicates the dependency + relationship of the ``AXISNAME`` field (where ``AXISNAME`` + is the name of a field that exists in this ``NXdata`` group) + with one or more dimensions of the plottable data. + + Integer array that defines the indices of the *signal* field + (that field will be a multidimensional array) + which need to be used in the *AXISNAME* field in + order to reference the corresponding axis value. + + The first index of an array is ``0`` (zero). + + Here, *AXISNAME* is to be replaced by the name of each + field described in the ``axes`` attribute. + An example with 2-D data, :math:`d(t,P)`, will illustrate:: + + data_2d:NXdata + @signal="data" + @axes=["time", "pressure"] + @time_indices=0 + @pressure_indices=1 + data: float[1000,20] + time: float[1000] + pressure: float[20] + + This attribute is to be provided in all situations. + However, if the indices attributes are missing + (such as for data files written before this specification), + file readers are encouraged to make their best efforts + to plot the data. + Thus the implementation of the + ``AXISNAME_indices`` attribute is based on the model of + "strict writer, liberal reader". + + .. note:: Attributes potentially containing multiple values + (axes and _indices) are to be written as string or integer arrays, + to avoid string parsing in reading applications. + \@AXISNAME_depends: + doc: | + Points to the path of a field defining the axis on which the ``AXISNAME`` axis depends. + + This concept allows to link an axis to a respective field in the NeXus hierarchy, thereby + defining the physical quantity it represents. + + Here, *AXISNAME* is to be replaced by the name of each + field described in the ``axes`` attribute. + + Examples: + If a calibration has been performed, ``@AXISNAME_depends`` links to the result of + that calibration: + + @AXISNAME_depends: '/entry/process/calibration/calibrated_axis' + + If the axis corresponds to a coordinate of a detector, ``@AXISNAME_depends`` links + to that detector axis: + + @AXISNAME_depends: '/entry/instrument/detector/axis/some_axis' for a 2D detector + + If the axis is a scanned motor, ``@AXISNAME_depends`` links to the transformation + describing the respective motion, e.g.: + + @AXISNAME_depends: '/entry/instrument/detector/transformations/some_transformation' for a motion of the detector + AXISNAME(NX_NUMBER): + nameType: any + doc: | + 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. + dimensions: + rank: 1 + doc: | + A *dimension scale* must have a rank of 1 and has length ``n``. + dim: [[1, n]] + \@long_name: + doc: | + Axis label + \@distribution: + type: NX_BOOLEAN + doc: | + ``0|false``: single value, + ``1|true``: multiple values + \@first_good: + type: NX_INT + doc: | + Index of first good value + \@last_good: + type: NX_INT + doc: | + Index of last good value + \@axis: + type: NX_POSINT + deprecated: Use the group ``axes`` attribute (NIAC2014) + doc: | + Index (positive integer) identifying this specific set of numbers. + + N.B. The ``axis`` attribute is the old way of designating a link. + Do not use the ``axes`` attribute with the ``axis`` attribute. + The ``axes`` *group* attribute is now preferred. + FIELDNAME_errors(NX_NUMBER): + nameType: any + doc: | + "Errors" (meaning *uncertainties* or *standard deviations*) + associated with any field named ``FIELDNAME`` in this ``NXdata`` + group (e.g. an axis, signal or auxiliary signal). + + The dimensions of the ``FIELDNAME_errors`` field must match + the dimensions of the ``FIELDNAME`` field. + DATA(NX_NUMBER): + nameType: any + doc: | + .. 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. + dimensions: + rank: dataRank + doc: | + The rank (``dataRank``) of the ``data`` must satisfy + ``1 <= dataRank <= NX_MAXRANK=32``. + At least one ``dim`` must have length ``n``. + dim: [] + \@signal: + type: NX_POSINT + deprecated: Use the group ``signal`` attribute (NIAC2014) + doc: | + .. index:: plotting + + Plottable (independent) axis, indicate index number. + Only one field in a :ref:`NXdata` group may have the + ``signal=1`` attribute. + Do not use the ``signal`` attribute with the ``axis`` attribute. + \@axes: + deprecated: Use the group ``axes`` attribute (NIAC2014) + doc: | + Defines the names of the dimension scales + (independent axes) for this data set + as a colon-delimited array. + NOTE: The ``axes`` attribute is the preferred + method of designating a link. + Do not use the ``axes`` attribute with the ``axis`` attribute. + \@long_name: + doc: | + data label + errors(NX_NUMBER): + deprecated: Use ``DATA_errors`` instead (NIAC2018) + doc: | + Standard deviations of data values - + the data array is identified by the group attribute ``signal``. + The ``errors`` array must have the same dimensions as ``DATA``. + Client is responsible for defining the dimensions of the data. + dimensions: + rank: dataRank + doc: | + The ``errors`` must have + the same rank (``dataRank``) + as the ``data``. + At least one ``dim`` must have length "n". + dim: [] + scaling_factor(NX_FLOAT): + doc: | + The elements in data are usually float values really. For + efficiency reasons these are usually stored as integers + after scaling with a scale factor. This value is the scale + factor. It is required to get the actual physical value, + when necessary. + offset(NX_FLOAT): + doc: | + An optional offset to apply to the values in data. + title: + doc: | + Title for the plot. + x(NX_FLOAT): + unit: NX_ANY + doc: | + This is an array holding the values to use for the x-axis of + data. The units must be appropriate for the measurement. + dimensions: + rank: 1 + dim: [[1, nx]] + y(NX_FLOAT): + unit: NX_ANY + doc: | + This is an array holding the values to use for the y-axis of + data. The units must be appropriate for the measurement. + dimensions: + rank: 1 + dim: [[1, ny]] + z(NX_FLOAT): + unit: NX_ANY + doc: | + This is an array holding the values to use for the z-axis of + data. The units must be appropriate for the measurement. + dimensions: + rank: 1 + dim: [[1, nz]] energy(NX_NUMBER): unit: NX_ENERGY doc: | Calibrated energy axis. - This could be a link to either + In an application definition, this could be a link to either /entry/process/energy_calibration/calibrated_axis or /entry/process/energy_correction/calibrated_axis. \@type: @@ -105,7 +509,8 @@ NXdata_photoemission(NXdata): doc: | Linear polarization angle of the incoming or outgoing beam. - Could be a link to /entry/instrument/beam/incident_polarization_angle or + In an application definition, this could be a link to + /entry/instrument/beam/incident_polarization_angle or /entry/instrument/beam/final_polarization_angle if they exist. \@polarization_angle_indices: \@polarization_angle_depends: @@ -115,13 +520,14 @@ NXdata_photoemission(NXdata): Ellipticity of the incoming or outgoing beam. Can be any of linear polarization angle (degrees), ellipticity (arb. units). - Could be a link to /entry/instrument/beam/incident_ellipticity or + In an application definition, this could be a link to + /entry/instrument/beam/incident_ellipticity or /entry/instrument/beam/final_ellipticity if they exist. \@ellipticity_indices: \@ellipticity_depends: # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4e560e6cd492d4f85ec19c22d80ebd5f17f1ac9daa6e8c92df23c99a185f2ff7 +# cbceca788f184a9407622afe748d03baca7cb08657bc85a99740639235d667a3 # # # -# +# +# +# +# +# These symbols will be used below to coordinate fields with the same +# shape. +# +# +# +# rank of the ``DATA`` field +# +# +# +# +# length of the ``AXISNAME`` field +# +# +# +# +# length of the ``x`` field +# +# +# +# +# length of the ``y`` field +# +# +# +# +# length of the ``z`` field +# +# +# # # :ref:`NXdata_photoemission` describes the plottable data and related dimension scales in photoemission # experiments. # # It extends the NXdata class and provides a glossary of explicitly named axis names # which are typical for photoemission data. +# +# For now, the extension of NXdata is performed by simply copying all existing groups, fields, +# and attibute from NXdata. In the future, it is envisioned that this extension can be solved by +# base class inheritance. +# +# .. 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) # +# +# +# .. index:: plotting +# +# Array of strings holding the :ref:`names <validItemName>` of additional +# signals to be plotted with the default :ref:`signal </NXdata@signal-attribute>`. +# These fields or links *must* exist and be direct children of this NXdata group. +# +# Each auxiliary signal needs to be of the same shape as the default signal. +# +# .. NIAC2018: +# https://www.nexusformat.org/NIAC2018Minutes.html +# +# +# +# +# .. 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 <validItemName>` 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. +# +# +# +# +# +# +# +# .. index:: plotting +# +# Array of strings holding the :ref:`names <validItemName>` of +# the independent data fields used in the default plot for all of +# the dimensions of the :ref:`signal </NXdata@signal-attribute>` +# as well as any :ref:`auxiliary signals </NXdata@auxiliary_signals-attribute>`. +# +# 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. +# +# +# +# +# +# +# Each ``AXISNAME_indices`` attribute indicates the dependency +# relationship of the ``AXISNAME`` field (where ``AXISNAME`` +# is the name of a field that exists in this ``NXdata`` group) +# with one or more dimensions of the plottable data. +# +# Integer array that defines the indices of the *signal* field +# (that field will be a multidimensional array) +# which need to be used in the *AXISNAME* field in +# order to reference the corresponding axis value. +# +# The first index of an array is ``0`` (zero). +# +# Here, *AXISNAME* is to be replaced by the name of each +# field described in the ``axes`` attribute. +# An example with 2-D data, :math:`d(t,P)`, will illustrate:: +# +# data_2d:NXdata +# @signal="data" +# @axes=["time", "pressure"] +# @time_indices=0 +# @pressure_indices=1 +# data: float[1000,20] +# time: float[1000] +# pressure: float[20] +# +# This attribute is to be provided in all situations. +# However, if the indices attributes are missing +# (such as for data files written before this specification), +# file readers are encouraged to make their best efforts +# to plot the data. +# Thus the implementation of the +# ``AXISNAME_indices`` attribute is based on the model of +# "strict writer, liberal reader". +# +# .. note:: Attributes potentially containing multiple values +# (axes and _indices) are to be written as string or integer arrays, +# to avoid string parsing in reading applications. +# +# +# +# +# Points to the path of a field defining the axis on which the ``AXISNAME`` axis depends. +# +# This concept allows to link an axis to a respective field in the NeXus hierarchy, thereby +# defining the physical quantity it represents. +# +# Here, *AXISNAME* is to be replaced by the name of each +# field described in the ``axes`` attribute. +# +# Examples: +# If a calibration has been performed, ``@AXISNAME_depends`` links to the result of +# that calibration: +# +# @AXISNAME_depends: '/entry/process/calibration/calibrated_axis' +# +# If the axis corresponds to a coordinate of a detector, ``@AXISNAME_depends`` links +# to that detector axis: +# +# @AXISNAME_depends: '/entry/instrument/detector/axis/some_axis' for a 2D detector +# +# If the axis is a scanned motor, ``@AXISNAME_depends`` links to the transformation +# describing the respective motion, e.g.: +# +# @AXISNAME_depends: '/entry/instrument/detector/transformations/some_transformation' for a motion of the detector +# +# +# +# +# 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. +# +# +# +# A *dimension scale* must have a rank of 1 and has length ``n``. +# +# +# +# +# +# Axis label +# +# +# +# +# ``0|false``: single value, +# ``1|true``: multiple values +# +# +# +# +# Index of first good value +# +# +# +# +# Index of last good value +# +# +# +# +# Index (positive integer) identifying this specific set of numbers. +# +# N.B. The ``axis`` attribute is the old way of designating a link. +# Do not use the ``axes`` attribute with the ``axis`` attribute. +# The ``axes`` *group* attribute is now preferred. +# +# +# +# +# +# "Errors" (meaning *uncertainties* or *standard deviations*) +# associated with any field named ``FIELDNAME`` in this ``NXdata`` +# group (e.g. an axis, signal or auxiliary signal). +# +# The dimensions of the ``FIELDNAME_errors`` field must match +# the dimensions of the ``FIELDNAME`` field. +# +# +# +# +# .. 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. +# +# +# +# The rank (``dataRank``) of the ``data`` must satisfy +# ``1 <= dataRank <= NX_MAXRANK=32``. +# At least one ``dim`` must have length ``n``. +# +# +# +# +# .. index:: plotting +# +# Plottable (independent) axis, indicate index number. +# Only one field in a :ref:`NXdata` group may have the +# ``signal=1`` attribute. +# Do not use the ``signal`` attribute with the ``axis`` attribute. +# +# +# +# +# Defines the names of the dimension scales +# (independent axes) for this data set +# as a colon-delimited array. +# NOTE: The ``axes`` attribute is the preferred +# method of designating a link. +# Do not use the ``axes`` attribute with the ``axis`` attribute. +# +# +# +# +# data label +# +# +# +# +# +# Standard deviations of data values - +# the data array is identified by the group attribute ``signal``. +# The ``errors`` array must have the same dimensions as ``DATA``. +# Client is responsible for defining the dimensions of the data. +# +# +# +# The ``errors`` must have +# the same rank (``dataRank``) +# as the ``data``. +# At least one ``dim`` must have length "n". +# +# +# +# +# +# The elements in data are usually float values really. For +# efficiency reasons these are usually stored as integers +# after scaling with a scale factor. This value is the scale +# factor. It is required to get the actual physical value, +# when necessary. +# +# +# +# +# An optional offset to apply to the values in data. +# +# +# +# +# Title for the plot. +# +# +# +# +# This is an array holding the values to use for the x-axis of +# data. The units must be appropriate for the measurement. +# +# +# +# +# +# +# +# This is an array holding the values to use for the y-axis of +# data. The units must be appropriate for the measurement. +# +# +# +# +# +# +# +# This is an array holding the values to use for the z-axis of +# data. The units must be appropriate for the measurement. +# +# +# +# +# # # # Calibrated energy axis. # -# This could be a link to either +# In an application definition, this could be a link to either # /entry/process/energy_calibration/calibrated_axis or # /entry/process/energy_correction/calibrated_axis. # @@ -262,7 +1121,8 @@ NXdata_photoemission(NXdata): # # Linear polarization angle of the incoming or outgoing beam. # -# Could be a link to /entry/instrument/beam/incident_polarization_angle or +# In an application definition, this could be a link to +# /entry/instrument/beam/incident_polarization_angle or # /entry/instrument/beam/final_polarization_angle if they exist. # # @@ -273,7 +1133,8 @@ NXdata_photoemission(NXdata): # Ellipticity of the incoming or outgoing beam. # # Can be any of linear polarization angle (degrees), ellipticity (arb. units). -# Could be a link to /entry/instrument/beam/incident_ellipticity or +# In an application definition, this could be a link to +# /entry/instrument/beam/incident_ellipticity or # /entry/instrument/beam/final_ellipticity if they exist. # # diff --git a/contributed_definitions/nyaml/NXdata_photoemission_detector.yaml b/contributed_definitions/nyaml/NXdata_photoemission_detector.yaml index 133a0888e3..389a9ce530 100644 --- a/contributed_definitions/nyaml/NXdata_photoemission_detector.yaml +++ b/contributed_definitions/nyaml/NXdata_photoemission_detector.yaml @@ -5,10 +5,412 @@ doc: | It extends the NXdata class and provides a glossary of explicitly named axis names which are typical for raw _photoemission data. + + For now, the extension of NXdata is performed by simply copying all existing groups, fields, + and attibute from NXdata. In the future, it is envisioned that this extension can be solved by + base class inheritance. + + .. 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) + +# The ignoreExtra* attributes are used in the definition to +# avoid warning messages that would be generated from unexpected fields or attributes. +# Since common use of NXdata indicates field names of any value, _many_ +# instances of this class would generate a warning message during validation +# without this attribute being set to "true". +symbols: + doc: | + These symbols will be used below to coordinate fields with the same + shape. + dataRank: | + rank of the ``DATA`` field + n: | + length of the ``AXISNAME`` field + nx: | + length of the ``x`` field + ny: | + length of the ``y`` field + nz: | + length of the ``z`` field type: group -NXdata_photoemission_detector(NXdata): +ignoreExtraFields: true +ignoreExtraAttributes: true +NXdata_photoemission_detector(NXobject): + \@auxiliary_signals: + doc: | + .. index:: plotting + + Array of strings holding the :ref:`names ` of additional + signals to be plotted with the default :ref:`signal `. + These fields or links *must* exist and be direct children of this NXdata group. + + Each auxiliary signal needs to be of the same shape as the default signal. + + .. NIAC2018: + https://www.nexusformat.org/NIAC2018Minutes.html \@signal: + doc: | + .. 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. enumeration: [raw] + \@axes: + doc: | + .. 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. + \@AXISNAME_indices: + type: NX_INT + + # nxdl.xsd rules do not allow us to show this as a variable name + # - we'll use ALL CAPS (see #562) + + # AXISNAME_indices documentation copied from datarules.rst + doc: | + Each ``AXISNAME_indices`` attribute indicates the dependency + relationship of the ``AXISNAME`` field (where ``AXISNAME`` + is the name of a field that exists in this ``NXdata`` group) + with one or more dimensions of the plottable data. + + Integer array that defines the indices of the *signal* field + (that field will be a multidimensional array) + which need to be used in the *AXISNAME* field in + order to reference the corresponding axis value. + + The first index of an array is ``0`` (zero). + + Here, *AXISNAME* is to be replaced by the name of each + field described in the ``axes`` attribute. + An example with 2-D data, :math:`d(t,P)`, will illustrate:: + + data_2d:NXdata + @signal="data" + @axes=["time", "pressure"] + @time_indices=0 + @pressure_indices=1 + data: float[1000,20] + time: float[1000] + pressure: float[20] + + This attribute is to be provided in all situations. + However, if the indices attributes are missing + (such as for data files written before this specification), + file readers are encouraged to make their best efforts + to plot the data. + Thus the implementation of the + ``AXISNAME_indices`` attribute is based on the model of + "strict writer, liberal reader". + + .. note:: Attributes potentially containing multiple values + (axes and _indices) are to be written as string or integer arrays, + to avoid string parsing in reading applications. + \@AXISNAME_depends: + doc: | + Points to the path of a field defining the axis on which the ``AXISNAME`` axis depends. + + This concept allows to link an axis to a respective field in the NeXus hierarchy, thereby + defining the physical quantity it represents. + + Here, *AXISNAME* is to be replaced by the name of each + field described in the ``axes`` attribute. + + Examples: + If a calibration has been performed, ``@AXISNAME_depends`` links to the result of + that calibration: + + @AXISNAME_depends: '/entry/process/calibration/calibrated_axis' + + If the axis corresponds to a coordinate of a detector, ``@AXISNAME_depends`` links + to that detector axis: + + @AXISNAME_depends: '/entry/instrument/detector/axis/some_axis' for a 2D detector + + If the axis is a scanned motor, ``@AXISNAME_depends`` links to the transformation + describing the respective motion, e.g.: + + @AXISNAME_depends: '/entry/instrument/detector/transformations/some_transformation' for a motion of the detector + AXISNAME(NX_NUMBER): + nameType: any + doc: | + 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. + dimensions: + rank: 1 + doc: | + A *dimension scale* must have a rank of 1 and has length ``n``. + dim: [[1, n]] + \@long_name: + doc: | + Axis label + \@distribution: + type: NX_BOOLEAN + doc: | + ``0|false``: single value, + ``1|true``: multiple values + \@first_good: + type: NX_INT + doc: | + Index of first good value + \@last_good: + type: NX_INT + doc: | + Index of last good value + \@axis: + type: NX_POSINT + deprecated: Use the group ``axes`` attribute (NIAC2014) + doc: | + Index (positive integer) identifying this specific set of numbers. + + N.B. The ``axis`` attribute is the old way of designating a link. + Do not use the ``axes`` attribute with the ``axis`` attribute. + The ``axes`` *group* attribute is now preferred. + FIELDNAME_errors(NX_NUMBER): + nameType: any + doc: | + "Errors" (meaning *uncertainties* or *standard deviations*) + associated with any field named ``FIELDNAME`` in this ``NXdata`` + group (e.g. an axis, signal or auxiliary signal). + + The dimensions of the ``FIELDNAME_errors`` field must match + the dimensions of the ``FIELDNAME`` field. + DATA(NX_NUMBER): + nameType: any + doc: | + .. 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. + dimensions: + rank: dataRank + doc: | + The rank (``dataRank``) of the ``data`` must satisfy + ``1 <= dataRank <= NX_MAXRANK=32``. + At least one ``dim`` must have length ``n``. + dim: [] + \@signal: + type: NX_POSINT + deprecated: Use the group ``signal`` attribute (NIAC2014) + doc: | + .. index:: plotting + + Plottable (independent) axis, indicate index number. + Only one field in a :ref:`NXdata` group may have the + ``signal=1`` attribute. + Do not use the ``signal`` attribute with the ``axis`` attribute. + \@axes: + deprecated: Use the group ``axes`` attribute (NIAC2014) + doc: | + Defines the names of the dimension scales + (independent axes) for this data set + as a colon-delimited array. + NOTE: The ``axes`` attribute is the preferred + method of designating a link. + Do not use the ``axes`` attribute with the ``axis`` attribute. + \@long_name: + doc: | + data label + errors(NX_NUMBER): + deprecated: Use ``DATA_errors`` instead (NIAC2018) + doc: | + Standard deviations of data values - + the data array is identified by the group attribute ``signal``. + The ``errors`` array must have the same dimensions as ``DATA``. + Client is responsible for defining the dimensions of the data. + dimensions: + rank: dataRank + doc: | + The ``errors`` must have + the same rank (``dataRank``) + as the ``data``. + At least one ``dim`` must have length "n". + dim: [] + scaling_factor(NX_FLOAT): + doc: | + The elements in data are usually float values really. For + efficiency reasons these are usually stored as integers + after scaling with a scale factor. This value is the scale + factor. It is required to get the actual physical value, + when necessary. + offset(NX_FLOAT): + doc: | + An optional offset to apply to the values in data. + title: + doc: | + Title for the plot. + x(NX_FLOAT): + unit: NX_ANY + doc: | + This is an array holding the values to use for the x-axis of + data. The units must be appropriate for the measurement. + dimensions: + rank: 1 + dim: [[1, nx]] + y(NX_FLOAT): + unit: NX_ANY + doc: | + This is an array holding the values to use for the y-axis of + data. The units must be appropriate for the measurement. + dimensions: + rank: 1 + dim: [[1, ny]] + z(NX_FLOAT): + unit: NX_ANY + doc: | + This is an array holding the values to use for the z-axis of + data. The units must be appropriate for the measurement. + dimensions: + rank: 1 + dim: [[1, nz]] raw(NX_NUMBER): doc: | Raw data before calibration. @@ -148,10 +550,10 @@ NXdata_photoemission_detector(NXdata): setup - it would just know that it collected N images, which would flatten the external parameters to one axis, too. This can then be linked, e.g. with NXcalibration, to the appropriate fields in the instrument - and write it to the top-level NXdata. + and write it to the top-level NXdata_photoemission. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 6b643f26d0adf60a48956f2db9bcc2dfc6847d0cce47140e6bb2b0d3a775fcd8 +# 66007d49cc376969aff3a597812f8154924a1d881e82c9ff9de1681526ab8a29 # # # -# +# +# +# +# +# These symbols will be used below to coordinate fields with the same +# shape. +# +# +# +# rank of the ``DATA`` field +# +# +# +# +# length of the ``AXISNAME`` field +# +# +# +# +# length of the ``x`` field +# +# +# +# +# length of the ``y`` field +# +# +# +# +# length of the ``z`` field +# +# +# # # :ref:`NXdata__photoemission_detector` describes the plottable data and related # dimension scales for raw detector data in _photoemission experiments. # # It extends the NXdata class and provides a glossary of explicitly named axis names # which are typical for raw _photoemission data. +# +# For now, the extension of NXdata is performed by simply copying all existing groups, fields, +# and attibute from NXdata. In the future, it is envisioned that this extension can be solved by +# base class inheritance. +# +# .. 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) # +# +# +# .. index:: plotting +# +# Array of strings holding the :ref:`names <validItemName>` of additional +# signals to be plotted with the default :ref:`signal </NXdata@signal-attribute>`. +# These fields or links *must* exist and be direct children of this NXdata group. +# +# Each auxiliary signal needs to be of the same shape as the default signal. +# +# .. NIAC2018: +# https://www.nexusformat.org/NIAC2018Minutes.html +# +# # +# +# .. 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 <validItemName>` 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. +# # # # # +# +# +# .. index:: plotting +# +# Array of strings holding the :ref:`names <validItemName>` of +# the independent data fields used in the default plot for all of +# the dimensions of the :ref:`signal </NXdata@signal-attribute>` +# as well as any :ref:`auxiliary signals </NXdata@auxiliary_signals-attribute>`. +# +# 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. +# +# +# +# +# +# +# Each ``AXISNAME_indices`` attribute indicates the dependency +# relationship of the ``AXISNAME`` field (where ``AXISNAME`` +# is the name of a field that exists in this ``NXdata`` group) +# with one or more dimensions of the plottable data. +# +# Integer array that defines the indices of the *signal* field +# (that field will be a multidimensional array) +# which need to be used in the *AXISNAME* field in +# order to reference the corresponding axis value. +# +# The first index of an array is ``0`` (zero). +# +# Here, *AXISNAME* is to be replaced by the name of each +# field described in the ``axes`` attribute. +# An example with 2-D data, :math:`d(t,P)`, will illustrate:: +# +# data_2d:NXdata +# @signal="data" +# @axes=["time", "pressure"] +# @time_indices=0 +# @pressure_indices=1 +# data: float[1000,20] +# time: float[1000] +# pressure: float[20] +# +# This attribute is to be provided in all situations. +# However, if the indices attributes are missing +# (such as for data files written before this specification), +# file readers are encouraged to make their best efforts +# to plot the data. +# Thus the implementation of the +# ``AXISNAME_indices`` attribute is based on the model of +# "strict writer, liberal reader". +# +# .. note:: Attributes potentially containing multiple values +# (axes and _indices) are to be written as string or integer arrays, +# to avoid string parsing in reading applications. +# +# +# +# +# Points to the path of a field defining the axis on which the ``AXISNAME`` axis depends. +# +# This concept allows to link an axis to a respective field in the NeXus hierarchy, thereby +# defining the physical quantity it represents. +# +# Here, *AXISNAME* is to be replaced by the name of each +# field described in the ``axes`` attribute. +# +# Examples: +# If a calibration has been performed, ``@AXISNAME_depends`` links to the result of +# that calibration: +# +# @AXISNAME_depends: '/entry/process/calibration/calibrated_axis' +# +# If the axis corresponds to a coordinate of a detector, ``@AXISNAME_depends`` links +# to that detector axis: +# +# @AXISNAME_depends: '/entry/instrument/detector/axis/some_axis' for a 2D detector +# +# If the axis is a scanned motor, ``@AXISNAME_depends`` links to the transformation +# describing the respective motion, e.g.: +# +# @AXISNAME_depends: '/entry/instrument/detector/transformations/some_transformation' for a motion of the detector +# +# +# +# +# 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. +# +# +# +# A *dimension scale* must have a rank of 1 and has length ``n``. +# +# +# +# +# +# Axis label +# +# +# +# +# ``0|false``: single value, +# ``1|true``: multiple values +# +# +# +# +# Index of first good value +# +# +# +# +# Index of last good value +# +# +# +# +# Index (positive integer) identifying this specific set of numbers. +# +# N.B. The ``axis`` attribute is the old way of designating a link. +# Do not use the ``axes`` attribute with the ``axis`` attribute. +# The ``axes`` *group* attribute is now preferred. +# +# +# +# +# +# "Errors" (meaning *uncertainties* or *standard deviations*) +# associated with any field named ``FIELDNAME`` in this ``NXdata`` +# group (e.g. an axis, signal or auxiliary signal). +# +# The dimensions of the ``FIELDNAME_errors`` field must match +# the dimensions of the ``FIELDNAME`` field. +# +# +# +# +# .. 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. +# +# +# +# The rank (``dataRank``) of the ``data`` must satisfy +# ``1 <= dataRank <= NX_MAXRANK=32``. +# At least one ``dim`` must have length ``n``. +# +# +# +# +# .. index:: plotting +# +# Plottable (independent) axis, indicate index number. +# Only one field in a :ref:`NXdata` group may have the +# ``signal=1`` attribute. +# Do not use the ``signal`` attribute with the ``axis`` attribute. +# +# +# +# +# Defines the names of the dimension scales +# (independent axes) for this data set +# as a colon-delimited array. +# NOTE: The ``axes`` attribute is the preferred +# method of designating a link. +# Do not use the ``axes`` attribute with the ``axis`` attribute. +# +# +# +# +# data label +# +# +# +# +# +# Standard deviations of data values - +# the data array is identified by the group attribute ``signal``. +# The ``errors`` array must have the same dimensions as ``DATA``. +# Client is responsible for defining the dimensions of the data. +# +# +# +# The ``errors`` must have +# the same rank (``dataRank``) +# as the ``data``. +# At least one ``dim`` must have length "n". +# +# +# +# +# +# The elements in data are usually float values really. For +# efficiency reasons these are usually stored as integers +# after scaling with a scale factor. This value is the scale +# factor. It is required to get the actual physical value, +# when necessary. +# +# +# +# +# An optional offset to apply to the values in data. +# +# +# +# +# Title for the plot. +# +# +# +# +# This is an array holding the values to use for the x-axis of +# data. The units must be appropriate for the measurement. +# +# +# +# +# +# +# +# This is an array holding the values to use for the y-axis of +# data. The units must be appropriate for the measurement. +# +# +# +# +# +# +# +# This is an array holding the values to use for the z-axis of +# data. The units must be appropriate for the measurement. +# +# +# +# +# # # # Raw data before calibration. @@ -345,7 +1195,7 @@ NXdata_photoemission_detector(NXdata): # setup - it would just know that it collected N images, which would flatten the external # parameters to one axis, too. # This can then be linked, e.g. with NXcalibration, to the appropriate fields in the instrument -# and write it to the top-level NXdata. +# and write it to the top-level NXdata_photoemission. # # # diff --git a/contributed_definitions/nyaml/NXprocess_photoemission.yaml b/contributed_definitions/nyaml/NXprocess_photoemission.yaml index 420823c2c0..44149bc91e 100644 --- a/contributed_definitions/nyaml/NXprocess_photoemission.yaml +++ b/contributed_definitions/nyaml/NXprocess_photoemission.yaml @@ -3,12 +3,12 @@ doc: | :ref:`NXprocess_photoemission` describes events of data processing, reconstruction, or analysis for photoemission-related data. - It extends the NXprocess class and provides a glossary of explicitly named processes - and their metadata which are typical for photoemission data. + It extends the NXprocess class and provides a glossary of explicitly named processes + and their metadata which are typical for photoemission data. - For now, the extension of NXprocess is performed by simply copying all existing groups, fields, - and attibute from NXprocess. In the future, it is envisioned that this extension can be solved by - base class inheritance. + For now, the extension of NXprocess is performed by simply copying all existing groups, fields, + and attibute from NXprocess. In the future, it is envisioned that this extension can be solved by + base class inheritance. type: group NXprocess_photoemission(NXobject): program(NX_CHAR): @@ -198,7 +198,7 @@ NXprocess_photoemission(NXobject): See https://www.nexusformat.org/2014_How_to_find_default_data.html # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# af4a363f3fe84129dc0f4bdd01815acd70e2910cb6b00a760cc3643770ab39a6 +# c1cc4b770367386bafa967be32191cf3ee3ec684d75f3772890cf4993919196e # # # - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -53,6 +53,11 @@ + + + The total number of faces of triangles. + + The total number of XDMF values to represent all faces of triangles via XDMF. @@ -63,6 +68,11 @@ The cardinality/total number of triangles in the triangle soup.--> The total number of entries in a feature dictionary. + + + The total number of volumetric features. + + The total number of member distinguished when reporting composition. @@ -70,953 +80,661 @@ The cardinality/total number of triangles in the triangle soup.--> - Results of a paraprobe-nanochem tool run. + Application definition for results files of the paraprobe-nanochem tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. - - - - Version specifier of this application definition. - - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - - - - - The absolute path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must no longer compute analyses. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases, it might be - that the executable has terminated prematurely or another error - occurred. - + + - - + - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - If nothing else is specified we assume that there - has to be at least one set of NXtransformations named - paraprobe defined, which specifies the coordinate system. - In which all positions are defined. - - - - - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - + + + + + + + - - - + + + + + + + + + + + + + How were results of the kernel-density estimation normalized: + * total, the total number (intensity) of ions or elements. + * candidates, the total number (intensity) of ions matching weighting_model + * composition, the value for candidates divided by the value for total, + * concentration, the value for candidates divided by the volume of the cell. + + + + + + + + + - A bitmask which identifies which of the ions in the dataset were - analyzed during this process. + The discretized domain/grid on which the delocalization is applied. - + + + + + + + + + + The total number of cells/voxels of the grid. + + + + + + + + - Number of ions covered by the mask. - The mask value for most may be 0. + The symmetry of the lattice defining the shape of the unit cell. + + + - + - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). + The unit cell dimensions according to the coordinate system defined under + coordinate_system. + + + - + - The unsigned integer array representing the content of the mask. - If padding is used, padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe-toolbox executable. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth (padding). + Number of unit cells along each of the d-dimensional base vectors. + The total number of cells, or grid points has to be the cardinality. + If the grid has an irregular number of grid positions in each direction, + as it could be for instance the case of a grid where all grid points + outside some masking primitive are removed, this extent field should + not be used. Instead use the coordinate field. - + - - - - + + + + Integer which specifies the first index to be used for distinguishing identifiers for cells. + Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are + defined on the interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + + + + + A tight axis-aligned bounding box about the grid. + + - The weighting model specifies how mark data are mapped to a weight - per point/ion. For atom probe microscopy (APM) mark data are e.g. - which iontype an ion has. As an example, different models are used - which account differently for the multiplicity of a point/ion - during delocalization: - - * unity, all points/ions get the same weight 1. - * atomic_decomposition, points get as much weight as they - have atoms of a type in atomic_decomposition_rule, - * isotope_decomposition, points get as much weight as they have - isotopes of a type in isotopic_decomposition_rule. + For atom probe should be set to true. - - - - - - - + - A list of elements (via proton number) to consider for the - atomic_decomposition weighting model. - Elements must exist in the periodic table of elements and be - specified by their number of protons. - Values in match are isotope hash values using the following - hashing rule $H = Z + 256*N$ with $Z$ the number of protons - and $N$ the number of neutrons of the isotope. - In the case of elements this hashing rule has the advantage - that for elements the proton number is their hash value because - N is zero. + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly or explicitly. + For implicit indexing the identifiers are defined on the interval + [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. - + + + - Meaning of the filter: - Whitelist specifies which entries with said value to include. - Entries with all other values will be filtered out. - - Blacklist specifies which entries with said value to exclude. - Entries with all other values will be included. + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly or explicitly. + For implicit indexing the identifiers are defined on the interval + [identifier_offset, identifier_offset+c-1]. For explicit indexing the identifier array + has to be defined. - - - - - + - Array of values to filter according to method. For example, - if the filter specifies [1, 5, 6] and method is whitelist, - only entries with values matching 1, 5 or 6 will be processed. - All other entries will be filtered out/not considered. + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly or explicitly. + For implicit indexing the identifiers are defined on the interval + [identifier_offset, identifier_offset+c-1]. For explicit indexing the identifier array + has to be defined. - - - - - - - A list of isotopes (via proton and neutron number) to consider - for the isotopic_decomposition weighting model. - Isotopes must exist in the nuclid table. - Values in match are isotope hash values using the following - hashing rule $H = Z + 256*N$ with $Z$ the number of protons - and $N$ the number of neutrons of the isotope. - - + - Meaning of the filter: - Whitelist specifies which entries with said value to include. - Entries with all other values will be filtered out. - - Blacklist specifies which entries with said value to exclude. - Entries with all other values will be included. + Positions of the vertices. + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. - - - - + + + + - + - Array of values to filter according to method. For example, - if the filter specifies [1, 5, 6] and method is whitelist, - only entries with values matching 1, 5 or 6 will be processed. - All other entries will be filtered out/not considered. + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. - - + + + - - - - How results of the kernel-density estimation were computed - into quantities. By default the tool computes the total number - (intensity) of ions or elements. Alternatively the tool can compute - the total intensity, the composition, or the concentration of the - ions/elements specified by the white list of elements in each voxel. - - - - - - - - - - - Weighting factor, in atom probe, often termed multiplicity. - The weighting factor is the multiplier with which the integrated - intensity contribution from the point/ion gets multiplied. - The delocalization computes the integrated intensity for each - grid cell. Effectively, this is an explicitly evaluated kernel - method where each specific position of an ion is replaced by a - smoothing kernel. For atom probe weights are positive and integer - specifically the multiplicity of the ion, in accordance with the - respective rulesets as defined by weighting_model. - - - - - - - - The discretized domain/grid on which the delocalization is applied. - - - - - - - - - + - The total number of cells/voxels of the grid. + 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. - - - + - + - The symmetry of the lattice defining the shape of the unit cell. + How many distinct boundaries are distinguished? + Most grids discretize a cubic or cuboidal region. In this case + six sides can be distinguished, each making an own boundary. - - - - + - The unit cell dimensions according to the coordinate system - defined under coordinate_system. + Name of the boundaries. E.g. left, right, front, back, bottom, top, + The field must have as many entries as there are number_of_boundaries. - + - + - Number of unit cells along each of the d unit vectors. - The total number of cells, or grid points has to be the cardinality. - If the grid has an irregular number of grid positions in each direction, - as it could be for instance the case of a grid where all grid points - outside some masking primitive are removed, this extent field should - not be used. Instead use the coordinate field. + The boundary conditions for each boundary: + + 0 - undefined + 1 - open + 2 - periodic + 3 - mirror + 4 - von Neumann + 5 - Dirichlet - + - - + + + + + Halfwidth of the kernel about the central voxel. + The shape of the kernel is that of a cuboid + of extent 2*kernel_extent[i] + 1 in each dimension i. + + + + + + + + Functional form of the kernel (Ansatz function). + + + + + + + + Standard deviation :math:`$\sigma_i$` of the kernel in each dimension + in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. + + + + + + + + Expectation value :math:`\mu_i$` of the kernel in each dimension + in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. + + + + + + + + + The result of the delocalization :math:`$\Phi = f(x, y, z)$` based on which subsequent iso-surfaces + will be computed. In commercial software so far there is no possibility to export this information. + + If the intensity for all matches of the weighting_model are summarized name this NXdata instance + scalar_field_magn_total. + + If the intensity is reported for each iontype one can avoid many subsequent + computations as individual intensities can be reinterpreted using a different weighting_model in + down-stream usage of the here reported values (e.g. with Python scripting). + In this case name the individual NXdata instances scalar_field_magn_ionID using the ID of the ion as + per the configuration of the ranging definitions used. + + + + + + + + + + The actual delocalized intensity values. + + + + + + + + + + Cell center of mass positions along x. + + + + + + + + Cell center of mass positions along y. + + + + + + + + Cell center of mass positions along z. + + + + + + + + Intensity of the field at given point + + + + + + + + Center of mass positions of each voxel for rendering the scalar field + via XDMF in e.g. Paraview. + + + + + + + + + XDMF topology for rendering in combination with xdmf_xyz the scalar field + via XDMF in e.g. Paraview. + + + + + + + + + The three-dimensional gradient :math:`$\nabla \Phi$`. + Follow the naming convention of scalar_field_magn_SUFFIX to report parallel structures. + + + + + + + + + + The actual point-wise component values. + + + + + + + + + + + Cell center of mass positions along x. + + + + + + + + Cell center of mass positions along y. + + + + + + + + Cell center of mass positions along z. + + + + + + + + The gradient vector formatted for direct visualization via XDMF in e.g. + Paraview. + + + + + + + + + Center of mass positions of each voxel for rendering the scalar field gradient + via XDMF in e.g. Paraview. + + + + + + + + + XDMF topology for rendering in combination with xdmf_xyz the scalar field + via XDFM in e.g. Paraview. + + + + + + + + + + An iso-surface is the boundary between two regions across which the magnitude of a + scalar field falls below/exceeds a threshold magnitude :math:`$\varphi$`. + + For applications in atom probe microscopy, the location and shape of such a boundary (set) + is typically approximated by discretization - triangulation to be specific. + + This yields a complex of not necessarily connected geometric primitives. + Paraprobe-nanochem approximates this complex with a soup of triangles. + + + + + The threshold or iso-contour value :math:`$\varphi`. + + + + + Details about the specific marching cubes algorithm that was used for computing + the iso-surface. + + - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - If the coordinate system is not specified the paraprobe - coordinate system is used. + Reference to the specific implementation of marching cubes used. + The value placed here should be a DOI. If there are no specific + DOI or details write not_further_specified, or give at least a + free-text description. The program and version used is the + specific paraprobe-nanochem. - + + + + The resulting triangle soup computed via marching cubes. + + + - Integer which specifies the first index to be used for - distinguishing identifiers for cells. Identifiers are defined - either implicitly or explicitly. For implicit indexing the - identifiers are defined on the interval - [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. + Integer which specifies the first index to be used for distinguishing triangles. + Identifiers are defined either implicitly or explicitly. For implicit indexing the + identifiers are defined on the interval [identifier_offset, identifier_offset+c-1]. - - - A tight axis-aligned bounding box about the grid. - - + + + + + + + + Positions of the vertices. + + Users are encouraged to reduce the vertices to a unique set as this may + result in a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. Naively here means that each + vertex is stored even though many share the same positions. + + + + + + + - For atom probe should be set to true. + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. + + + - + - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. + A list of as many tuples of XDMF topology key, XDMF number + of vertices and a triple of vertex indices specifying each + triangle. The total number of entries is n_f_tri * (1+1+3). + + + - - + + - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. + Direction of each normal. + + + + - + - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. + Qualifier how which specifically oriented normal to its + primitive each normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + + + - + + + + - Positions of the vertices. - - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. + Direction of each normal. - + - + - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. + Qualifier how which specifically oriented normal to its + primitive each normal represents. - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. + * 0 - undefined + * 1 - outer + * 2 - inner - - - + + - + - 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. + Triangle normals are oriented in the direction of the + gradient vector of the local delocalized scalar field. + :math:`\sum_{x, y, z} {\nabla{c}_i}^2`. - + - + + - How many distinct boundaries are distinguished? - Most grids discretize a cubic or cuboidal region. In this case - six sides can be distinguished, each making an own boundary. + Triangle normals are oriented in the direction of the + gradient vector of the local delocalized scalar field. + The projection variable here describes the cosine of the + angle between the gradient direction and the normal + direction vector. + This is a descriptor of how parallel the projection is + that is especially useful to document those triangles + for whose the projection is almost perpendicular. + + + - - - Name of the boundaries. E.g. left, right, front, back, bottom, top, - The field must have as many entries as there are number_of_boundaries. - + - + - + - The boundary conditions for each boundary: - - 0 - undefined - 1 - open - 2 - periodic - 3 - mirror - 4 - von Neumann - 5 - Dirichlet - - - - - - - - - - The result of the delocalization based on which subsequent - iso-surfaces will be computed. In commercial software so far - there is not a possibility to export such grid. - - - - - - - - - - - - - - - - - - Cell center of mass positions along x. - - - - - - - - - Cell center of mass positions along y. - - - - - - - - Cell center of mass positions along z. - - - - - - - - Intensity of the field at given point - - - - - - - - Center of mass positions of each voxel for - rendering the scalar field via XDMF in e.g. - Paraview. + Array of edge length values. For each triangle the edge length + is reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. - + - - - XDMF topology for rendering in combination with - xdmf_xyz the scalar field via XDFM in e.g. Paraview. - - - - - - - - - The three-dimensional gradient nabla operator applied to - scalar_field_magnitude. - - - - - - - - - - - - - - - - - - - - Cell center of mass positions along x. - - - - - - - - - Cell center of mass positions along y. - - - - - - + - Cell center of mass positions along z. - - - - - - - - The gradient vector. + Array of interior angle values. For each triangle the angle + is reported for the angle opposite to the edges which are + traversed according to the sequence in which vertices + are indexed in triangles. - - + + - + - Center of mass positions of each voxel for - rendering the scalar field via XDMF in e.g. - Paraview. + The center of mass of each triangle. - + - - - XDMF topology for rendering in combination with - xdmf_xyz the scalar field via XDFM in e.g. Paraview. - - - - - - - - - Halfwidth of the kernel about the central voxel. - The shape of the kernel is that of a cuboid - of extent 2*kernel_extent[i] + 1 in each dimension i. - - - - - - - - - - Sigma of the kernel in each dimension in the paraprobe - coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. - - - - - - - - Expectation value of the kernel in each dimension in the paraprobe - coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. - - - - - - - - - - An iso-surface is the boundary between two regions across which - the magnitude of a scalar field falls below/exceeds a threshold - magnitude phi. - For applications in atom probe microscopy the location and shape - of such a boundary (set) is typically approximated by - discretization. - This yields a complex of not necessarily connected geometric - primitives. Paraprobe-nanochem approximates this complex with - a soup of triangles. - - - - - The threshold or iso-contour value. - - - - - Details about the specific marching cubes algorithm - which was taken to compute the iso-surface. - The grid is the delocalization grid. - - - - Reference to the specific implementation of marching cubes used. - The value placed here should be a DOI. If there are no specific - DOI or details write not_further_specified, or give at least a - free-text description. The program and version used is the - specific paraprobe-nanochem. - - - - - - The resulting triangle soup computed via marching cubes. - - - - - - Integer which specifies the first index to be used for - distinguishing triangles. Identifiers are defined either - implicitly or explicitly. For implicit indexing the - identifiers are defined on the interval - [identifier_offset, identifier_offset+c-1]. - - - - - - Number of vertices. - - - - - Number of faces. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - - - - - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - - - - - Positions of the vertices. - - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - - - - - - - - - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. - - - - - - - - A list of as many tuples of XDMF topology key, XDMF number - of vertices and a triple of vertex indices specifying each - triangle. The total number of entries is n_f_tri * (1+1+3). - - - - - - - - - Direction of each normal. - - - - - - - - - Qualifier how which specifically oriented normal to its - primitive each normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner - - - - - - - - - - - Direction of each normal. - - - - - - - - - Qualifier how which specifically oriented normal to its - primitive each normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner - - - - - - - - Triangle normals are oriented in the direction of the - gradient vector of the local delocalized scalar field. - :math:`\sum_{x, y, z} {\nabla{c}_i}^2`. - - - - - - - - - Triangle normals are oriented in the direction of the - gradient vector of the local delocalized scalar field. - The projection variable here describes the cosine of the - angle between the gradient direction and the normal - direction vector. - This is a descriptor of how parallel the projection is - that is especially useful to document those triangles - for whose projection is almost perpendicular. - - - - - - - - - - - - - - Array of edge length values. For each triangle the edge length - is reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - - - - - - - - - Array of interior angle values. For each triangle the angle - is reported for the angle opposite to the edges which are - traversed according to the sequence in which vertices - are indexed in triangles. - - - - - - - - - The center of mass of each triangle. - - - - - - - - + - Iso-surfaces of arbitrary scalar three-dimensional fields - can show a complicated topology. Paraprobe-nanochem can run - a DBScan-like clustering algorithm which performs a - connectivity analysis on the triangle soup. This yields a - set of connected features with their surfaces discretized - by triangles. Currently, the tool distinguishes at most - three types of features: + Iso-surfaces of arbitrary scalar three-dimensional fields can show a complicated topology. + Paraprobe-nanochem can run a DBScan-like clustering algorithm which performs a + connectivity analysis on the triangle soup representation of such iso-surface. + This may yield a set of connected features whose individual surfaces are discretized + by a triangulated mesh each. Such volumetric features can be processed further using + paraprobe-nanochem using a workflow with at most two steps. - 1. So-called objects, i.e. necessarily watertight features - represented polyhedra. - 2. So-called proxies, i.e. features that were replaced by a - proxy mesh and made watertight. - 3. Remaining triangle surface meshes of arbitrary shape and - cardinality. + In the first step, the tool distinguishes three types of (v) i.e. volumetric features: - These features can be interpreted as microstructural features. - Some of them may be precipitates, some of them may be poles, - some of them may be segments of dislocation lines or other + 1. So-called objects, i.e. necessarily watertight features represented by polyhedra. + These objects were already watertight within the triangulated iso-surface. + 2. So-called proxies, i.e. features that were not necessarily watertight within the triangulated + iso-surface but were subsequently replaced by a watertight mesh using polyhedral mesh + processing operations (hole filling, refinement, fairing operations). + 3. Remaining triangle surface meshes or parts of these of arbitrary shape and cardinality + that are not transformable into proxies or for which no transformation into proxies was + instructed. + + These features can be interpreted as microstructural features. Some of them may be precipitates, + some of them may be poles, some of them may be segments of dislocation lines or other crystal defects which are decorated (or not) with solutes. + + In the second step, the tool can be used to analyze the proximity of these objects to a + model of the surface (edge) of the dataset. - The identifier which the triangle_soup connectivity analysis @@ -1024,7 +742,7 @@ NEW ISSUE: refactor using instances of NXms_feature_set--> volumetric_feature identification process. - + @@ -1044,7 +762,7 @@ NEW ISSUE: refactor using instances of NXms_feature_set--> - + The array of controlled keywords, need to be from feature_type_dict_keyword, which specify which type @@ -1052,7 +770,7 @@ NEW ISSUE: refactor using instances of NXms_feature_set--> Keep in mind that not each feature is an object or proxy. - + @@ -1060,26 +778,35 @@ NEW ISSUE: refactor using instances of NXms_feature_set--> The explicit identifier of features. - + - - + - Details for features which are (closed) objects. - Identifier have to exist in feature_identifier. + In all situations instances of the parent NXprocess group are returned with a very similar + information structuring and thus we here replace the template name FEATURE + with one of the following types feature-specific group names: + + * objects, objects, irrespective their distance to the surface + * objects_close_to_edge, sub-set of v_feature_object close surface + * objects_far_from_edge, sub-set of v_feature_object not close to the surface + * proxies, proxies, irrespective their distance to the surface + * proxies_close_to_edge, sub-set of v_feature_proxies, close to surface + * proxies_far_from_edge, sub-set of v_feature_proxies, not close to surface - + + Explicit identifier of the feature a sub-set of the feature_identifier in the + parent group. + + + Volume of the feature. NaN for non-watertight objects. + @@ -1090,18 +817,17 @@ details about specific features--> - Edge length of the oriented bounding box from largest - to smallest value. + Edge length of the oriented bounding box from largest to smallest value. - - Oriented bounding box aspect ratio. YX versus ZY. + Oriented bounding box aspect ratio. + YX versus ZY or second-largest over largest and smallest over second largest. @@ -1119,16 +845,11 @@ details about specific features--> - - + - A simple approach to describe the entire set of hexahedra - when the main intention is to store the shape of the - hexahedra for visualization. + A simple approach to describe the entire set of hexahedra when the main intention + is to store the shape of the hexahedra for visualization. - @@ -1149,379 +870,75 @@ exists: [min, 0, max, 1] - - - Details for all those objects close to edge, i.e. those which - have at least one ion which lays closer to a modelled edge - of the dataset than threshold. - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - Total (count) relevant for normalization. + Array of evaporation_identifier / ion_identifier which details which ions + lie inside or on the surface of the feature. - + - - - - - - - Count or weight which, when divided by total, - yields the composition of this element, isotope, - molecule or ion. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Array of evaporation_identifier / ion_identifier which - specify ions laying inside or on the surface of the feature. - - - - - - - - - Details for all those objects far from edge, i.e. those - whose ions lay all at least threshold distant from a - modelled edge of the dataset. - - - - - - - + + + + Total (count) of ions inside or on the surface of the feature relevant for normalization. + NaN for non watertight objects. + - - + + + + + + - Total (count) relevant for normalization. + Count or weight which, when divided by total, yields the composition of this element, + nuclide, or (molecular) ion within the volume of the feature/object. - - - - - - - Count or weight which, when divided by total - yields the composition of this element, isotope, - molecule or ion. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Array of evaporation_identifier / ion_identifier which - specify ions laying inside or on the surface of the feature. - - - - - - - - - - - - - Details for features which are so-called proxies, i.e. objects - which have been reconstructed and combinatorially closed with - processing their partial triangulated_surface_mesh - (hole filling, refinement). - Identifier have to exist in feature_identifier. - - - - - - - - - - - - - - - - Details for those proxies close to edge, i.e. those which - have at least one ion which lays closer to a modelled edge - of the dataset than threshold. - Identifier have to exist in feature_identifier. - - - - - - - - - - - - - - - - Total (count) relevant for normalization. - - - - - - - - - - Count or weight which, when divided by total - yields the composition of this element, isotope, - molecule or ion. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Array of evaporation_identifier / ion_identifier which - specify ions laying inside or on the surface of the feature. - - - - - - - - - - - Details for those proxies far from edge, i.e. those whose - ions lay all at least threshold distant from a - modelled edge of the dataset. - - - - - - - - - - - - - - - Total (count) relevant for normalization. - - - - - - - - - - Count or weight which, when divided by total - yields the composition of this element, isotope, - molecule or ion. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Array of evaporation_identifier / ion_identifier which - specify ions laying inside or on the surface of the feature. - - - - - - @@ -1530,321 +947,258 @@ face_identifier_offset(NX_UINT):--> - - - - The multiplicity whereby the ion position is accounted for - irrespective whether the ion is considered as a decorator - of the interface or not. - As an example, with atom probe it is typically not possible - to resolve the positions of the atoms which arrive at the detector - as molecular ions. Therefore, an exemplar molecular ion of two carbon - atoms can be considered to have a multiplicity of two to account that - this molecular ion contributes two carbon atoms at the reconstructed - location considering that the spatial resolution of atom probe - experiments is limited. - - - - + + + + - + + + + + + + + + + + + + + + + + + + + + + + + + + + + The multiplicity whereby the ion position is accounted for + irrespective whether the ion is considered as a decorator + of the interface or not. + As an example, with atom probe it is typically not possible + to resolve the positions of the atoms which arrive at the detector + as molecular ions. Therefore, an exemplar molecular ion of two carbon + atoms can be considered to have a multiplicity of two to account that + this molecular ion contributes two carbon atoms at the reconstructed + location considering that the spatial resolution of atom probe + experiments is limited. + + + + + + + + The multiplicity whereby the ion position is accounted for when + the ion is considered one which is a decorator of the interface. + + + + + + + + The equation of the plane that is fitted initially. + + + + + The four parameter :math:`$ax + by + cz + d = 0$` which define the plane. + + + + + + + + The triangle surface mesh representing the interface model. + Exported at state before or after the next DCOM step. + + - The multiplicity whereby the ion position is accounted for when - the ion is considered one which is a decorator of the interface. + Was this state exported before or after the next DCOM step. - - - + + + + - - - The equation of the plane that is fitted initially. - - - - The four parameter :math:`ax + by + cz + d = 0` which define the plane. - - - - - - - - - The triangle surface mesh representing the interface model. - Exported at some iteration before the next DCOM step. - + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Direction of each normal - - - - - - - - - Qualifier how which specifically oriented normal to its primitive each - normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner - - - - - - - - - - - - Direction of each normal - - - - - - - - - Qualifier how which specifically oriented normal to its primitive each - normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner - - - - - - - + + + + + + - + - - - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - + - + - + - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. + Direction of each vertex normal. - - + + - - - - The triangle surface mesh representing the interface model. - Exported at some iteration after the next DCOM step. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Direction of each normal - - - - - - - - - Qualifier how which specifically oriented normal to its primitive each - normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner - - - - - - - - - - - - Direction of each normal - - - - - - - - - Qualifier how which specifically oriented normal to its primitive each - normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner - - - - - - - + + + Qualifier which details how specifically oriented the + face normal is with respect to its primitive (triangle): + + * 0 - undefined + * 1 - outer + * 2 - inner + - + - - - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - + - + - + - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. + Direction of each face normal. - - + + - - - - - - The ROIs are defined as cylinders for the computations. - To visualize these though we discretize them into regular n-gons. - Using for instance a 360-gon, i.e. a regular n-gon with 360 - edges resolves the lateral surface of each cylinder very finely - so that they are rendered smoothly in visualization software. - - - - + - Position of the geometric center, which often is but not - necessarily has to be the center_of_mass of the polyhedra. + Qualifier which details how specifically oriented the + face normal is with respect to its primitive (triangle): + + * 0 - undefined + * 1 - outer + * 2 - inner - - - + + - - - Integer which specifies the first index to be used for distinguishing - ROI cylinder. Identifiers are defined explicitly. - + - + - + + + + + + + + + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The ROIs are defined as cylinders for the computations. To visualize these we discretize + them into regular n-gons. Using for instance 360-gons, i.e. a regular n-gon with 360 edges, + resolves the lateral surface of each cylinder such that their renditions are smooth in + visualization software like Paraview. + + + + + + Position of the geometric center, which often is but not + necessarily has to be the center_of_mass of the polyhedra. + + + + + + + + + Integer which specifies the first index to be used for distinguishing + ROI cylinder explicitly. + + + + + + - The number of atoms in each ROI. @@ -1871,102 +1225,70 @@ face_identifier_offset(NX_UINT):--> - - + + + EXPLAIN HOW FIELDS SIGNED_DISTANCE AND NUCLIDE + ARE COMPUTED/CONSTRUCTED. + + In the direction of the ROI. + + + - + - Hashvalue + Hashvalue using the following hashing rule :math:`$H = Z + 256 * N$`. + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - diff --git a/contributed_definitions/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index 96ac168279..7f7fbdf77a 100644 --- a/contributed_definitions/NXdelocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -41,7 +41,7 @@ Number of atoms in the whitelist. - + Number of isotopes in the whitelist. @@ -76,71 +76,69 @@ all ions which are not considered, this weight is the multiplicity with respect to the interpretation model i.e. a C:2 molecular ion has a multiplicity of 2 if the ion is considered and the interpretation model that to consider carbon atoms or carbon ions--> - + - The weighting model specifies how mark data are mapped to a weight per point/object. - For atom probe microscopy (APM) as an example, different models are used which - account differently for the multiplicity of an ion/atom: - - * default, points all get the same weight 1.; - for APM this is equivalent to (molecular) iontype-based delocalization - * atomic_decomposition, points get as much weight as they have atoms - of a type in element_whitelist, - * isotope_decomposition, points get as much weight as they have - nuclids of a type in isotope_whitelist. - - This description shows an example that could be reinterpreted for - similar such data processing steps in other fields of science. + The weighting model specifies how mark data are mapped to a weight per + point/object. - - - - - - - - - - A list of elements (via proton number) to consider for the atomic_decomposition - weighting model. Elements must exist in the periodic table of elements. - - - - - - - - A list of isotopes to consider for the isotope_decomposition weighting model. - Isotopes must exist in the nuclid table. Entries in the fastest changing - dimension should be the pair of proton (first entry) and neutron number - (second entry). - - - - - - - - - Attribute data for each member of the point cloud. For APM these are the - iontypes generated via ranging. The number of mark data per point is 1 - in the case for atom probe. - - - - - - - - - Weighting factor with which the integrated intensity per grid cell is - multiplied specifically for each point/object. For APM the weight are - positive integer values, specifically the multiplicity of the ion, - according to the details of the weighting_model. - - + + + As an example from the research field of atom probe points/objects are (molecular) ions. + Different methods are used for weighting ions: + + * default, points get all the same weight 1., which for atom probe is equivalent + to (molecular) iontype-based delocalization. + * element, points get as much weight as they have atoms representing a nuclide + with a proton number that is matching to a respective entry in whitelist. + In atom probe jargon, this means atomic_decomposition. + * isotope, points get as much weight as they have atoms representing a nuclides + from a respective entry in whitelist. + In atom probe jargon, this means isotope_decomposition. + + + + + + + + + + + + + + + + A list of nuclides based on which to evaluate the weight. Nuclides need to exist in the nuclide table. + Values are nuclide (isotope) hash values using the following hashing rule :math:`$H = Z + 256 * N$` + with :math:`$Z$` the number of protons and :math:`$N$` the number of neutrons of the nuclide. + For elements set :math:`$N$` to zero. + + + + + + + + Attribute data for each member of the point cloud. For APM these are the + iontypes generated via ranging. The number of mark data per point is 1 + in the case for atom probe. + + + + + + + + + Weighting factor with which the integrated intensity per grid cell is + multiplied specifically for each point/object. For APM the weight are + positive integer values, specifically the multiplicity of the ion, + according to the details of the weighting_method. + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml index b95517c87b..fc58ce8ba0 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml @@ -1,6 +1,8 @@ category: application doc: | - Results of a paraprobe-nanochem tool run. + Application definition for results files of the paraprobe-nanochem tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -14,3739 +16,926 @@ symbols: The dimensionality of the delocalization grid. c: | The cardinality/total number of cells/grid points in the delocalization grid. - # c_tri_soup: | # The cardinality/total number of triangles in the triangle soup. + n_f_tri: | + The total number of faces of triangles. n_f_tri_xdmf: | The total number of XDMF values to represent all faces of triangles via XDMF. n_feature_dict: | The total number of entries in a feature dictionary. + n_v_feat: | + The total number of volumetric features. n_speci: | The total number of member distinguished when reporting composition. type: group NXapm_paraprobe_nanochem_results(NXobject): - - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently (NXentry): - exists: ['min', '1', 'max', '1'] - \@version: - doc: | - Version specifier of this application definition. - - ##MK::begin of the tool-specific section - definition: - doc: | - Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_results_nanochem] - - ##MK::end of the tool-specific section - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: - doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: | - Possibility for leaving a free-text description about this analysis. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - config_filename: - doc: | - The absolute path and name of the config file for this analysis. - \@version: - doc: | - At least SHA256 strong hash of the specific config_file for - tracking provenance. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - status: - doc: | - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must no longer compute analyses. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases, it might be - that the executable has terminated prematurely or another error - occurred. - enumeration: [success, failure] - (NXuser): - exists: optional - doc: | - If used, contact information and eventually details - of at least the person who performed this analysis. - name: - affiliation: - exists: recommended - address: - exists: optional - email: - exists: recommended - orcid: - exists: recommended - orcid_platform: - exists: recommended - telephone_number: - exists: optional - role: - exists: recommended - social_media_name: - exists: optional - social_media_platform: - exists: optional - (NXcoordinate_system_set): - doc: | - Details about the coordinate system conventions used. - If nothing else is specified we assume that there - has to be at least one set of NXtransformations named - paraprobe defined, which specifies the coordinate system. - In which all positions are defined. - - ##MK::define also reconstruction coordinate system and - ##MK::map between the two - (NXtransformations): - exists: ['min', '1', 'max', 'unbounded'] - doc: | - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - ##MK::begin of the tool-specific section - (NXprocess): - exists: ['min', '0', 'max', '1'] + exists: [min, 1, max, 1] + definition(NX_CHAR): + \@version(NX_CHAR): + enumeration: [NXapm_paraprobe_nanochem_results] + # tasks + delocalizationID(NXdelocalization): + exists: [min, 0, max, infty] + config(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): window(NXcs_filter_boolean_mask): - doc: | - A bitmask which identifies which of the ions in the dataset were - analyzed during this process. number_of_ions(NX_UINT): - unit: NX_UNITLESS - doc: | - Number of ions covered by the mask. - The mask value for most may be 0. bitdepth(NX_UINT): + mask(NX_UINT): + # results + weighting_model(NXmatch_filter): + weighting_method(NX_CHAR): + method(NX_CHAR): + match(NX_UINT): + normalization(NX_CHAR): + doc: | + How were results of the kernel-density estimation normalized: + * total, the total number (intensity) of ions or elements. + * candidates, the total number (intensity) of ions matching weighting_model + * composition, the value for candidates divided by the value for total, + * concentration, the value for candidates divided by the volume of the cell. + enumeration: [total, candidates, composition, concentration] + grid(NXcg_grid): + doc: | + The discretized domain/grid on which the delocalization is applied. + dimensionality(NX_POSINT): + enumeration: [1, 2, 3] unit: NX_UNITLESS + cardinality(NX_POSINT): doc: | - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - mask(NX_UINT): + The total number of cells/voxels of the grid. unit: NX_UNITLESS + origin(NX_NUMBER): + dim: (d,) + symmetry(NX_CHAR): + doc: | + The symmetry of the lattice defining the shape of the unit cell. + enumeration: [cubic] + cell_dimensions(NX_NUMBER): doc: | - The unsigned integer array representing the content of the mask. - If padding is used, padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe-toolbox executable. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth (padding). - dimensions: - rank: 1 - dim: [[1, n_ions]] - iso_surface_analysis(NXprocess): - exists: ['min', '0', 'max', 'unbounded'] - DELOCALIZATION(NXdelocalization): - weighting_model: + The unit cell dimensions according to the coordinate system defined under coordinate_system. + unit: NX_LENGTH + dim: (d,) + extent(NX_POSINT): + doc: | + Number of unit cells along each of the d-dimensional base vectors. + The total number of cells, or grid points has to be the cardinality. + If the grid has an irregular number of grid positions in each direction, + as it could be for instance the case of a grid where all grid points + outside some masking primitive are removed, this extent field should + not be used. Instead use the coordinate field. + dim: (d,) + # coordinate_system implicit + identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for distinguishing identifiers for cells. + Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are + defined on the interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + unit: NX_UNITLESS + bounding_box(NXcg_hexahedron_set): + doc: | + A tight axis-aligned bounding box about the grid. + is_axis_aligned(NX_BOOLEAN): doc: | - The weighting model specifies how mark data are mapped to a weight - per point/ion. For atom probe microscopy (APM) mark data are e.g. - which iontype an ion has. As an example, different models are used - which account differently for the multiplicity of a point/ion - during delocalization: - - * unity, all points/ions get the same weight 1. - * atomic_decomposition, points get as much weight as they - have atoms of a type in atomic_decomposition_rule, - * isotope_decomposition, points get as much weight as they have - isotopes of a type in isotopic_decomposition_rule. - enumeration: [unity, atomic_decomposition, isotopic_decomposition] - - # if weighting_model == atomic_decomposition needs atomic_decomposition_rule - # if weighting_model == isotopic_decomposition needs isotopic_decomposition_rule - atomic_decomposition_rule(NXmatch_filter): - exists: optional + For atom probe should be set to true. + identifier_offset(NX_INT): doc: | - A list of elements (via proton number) to consider for the - atomic_decomposition weighting model. - Elements must exist in the periodic table of elements and be - specified by their number of protons. - Values in match are isotope hash values using the following - hashing rule $H = Z + 256*N$ with $Z$ the number of protons - and $N$ the number of neutrons of the isotope. - In the case of elements this hashing rule has the advantage - that for elements the proton number is their hash value because - N is zero. - method: + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly or explicitly. + For implicit indexing the identifiers are defined on the interval + [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + unit: NX_UNITLESS + hexahedron(NXcg_face_list_data_structure): + vertex_identifier_offset(NX_INT): doc: | - Meaning of the filter: - Whitelist specifies which entries with said value to include. - Entries with all other values will be filtered out. - - Blacklist specifies which entries with said value to exclude. - Entries with all other values will be included. - enumeration: [whitelist, blacklist] - match(NX_NUMBER): + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly or explicitly. + For implicit indexing the identifiers are defined on the interval + [identifier_offset, identifier_offset+c-1]. For explicit indexing the identifier array + has to be defined. + unit: NX_UNITLESS + face_identifier_offset(NX_INT): + doc: | + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly or explicitly. + For implicit indexing the identifiers are defined on the interval + [identifier_offset, identifier_offset+c-1]. For explicit indexing the identifier array + has to be defined. unit: NX_UNITLESS + vertices(NX_NUMBER): doc: | - Array of values to filter according to method. For example, - if the filter specifies [1, 5, 6] and method is whitelist, - only entries with values matching 1, 5 or 6 will be processed. - All other entries will be filtered out/not considered. - dimensions: - rank: 1 - dim: [[1, n_atomic]] - isotopic_decomposition_rule(NXmatch_filter): - exists: optional - doc: | - A list of isotopes (via proton and neutron number) to consider - for the isotopic_decomposition weighting model. - Isotopes must exist in the nuclid table. - Values in match are isotope hash values using the following - hashing rule $H = Z + 256*N$ with $Z$ the number of protons - and $N$ the number of neutrons of the isotope. - method: + Positions of the vertices. + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + unit: NX_LENGTH + dim: (8, 3) + faces(NX_NUMBER): doc: | - Meaning of the filter: - Whitelist specifies which entries with said value to include. - Entries with all other values will be filtered out. + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. - Blacklist specifies which entries with said value to exclude. - Entries with all other values will be included. - enumeration: [whitelist, blacklist] - match(NX_NUMBER): + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. unit: NX_UNITLESS + dim: (6, 4) + 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 + dim: (36,) + number_of_boundaries(NX_POSINT): + exists: optional + doc: | + How many distinct boundaries are distinguished? + Most grids discretize a cubic or cuboidal region. In this case + six sides can be distinguished, each making an own boundary. + unit: NX_UNITLESS + boundaries(NX_CHAR): + exists: optional doc: | - Array of values to filter according to method. For example, - if the filter specifies [1, 5, 6] and method is whitelist, - only entries with values matching 1, 5 or 6 will be processed. - All other entries will be filtered out/not considered. - dimensions: - rank: 1 - dim: [[1, n_isotopic]] - normalization: + Name of the boundaries. E.g. left, right, front, back, bottom, top, + The field must have as many entries as there are number_of_boundaries. + dim: (6,) + boundary_conditions(NX_INT): + exists: optional + doc: | + The boundary conditions for each boundary: + + 0 - undefined + 1 - open + 2 - periodic + 3 - mirror + 4 - von Neumann + 5 - Dirichlet + unit: NX_UNITLESS + dim: (6,) + ##MK::how to avoid storing it for once in NeXus for H5Web and for XDMF in ParaView ? + kernel_size(NX_POSINT): doc: | - How results of the kernel-density estimation were computed - into quantities. By default the tool computes the total number - (intensity) of ions or elements. Alternatively the tool can compute - the total intensity, the composition, or the concentration of the - ions/elements specified by the white list of elements in each voxel. - enumeration: [total, candidates, composition, concentration] - weight(NX_NUMBER): - exists: optional + Halfwidth of the kernel about the central voxel. + The shape of the kernel is that of a cuboid + of extent 2*kernel_extent[i] + 1 in each dimension i. unit: NX_DIMENSIONLESS + dim: (3,) + kernel_type(NX_CHAR): + doc: | + Functional form of the kernel (Ansatz function). + enumeration: [gaussian] + kernel_sigma(NX_FLOAT): + doc: | + Standard deviation :math:`$\sigma_i$` of the kernel in each dimension + in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. + unit: NX_LENGTH + dim: (3,) + kernel_mu(NX_FLOAT): doc: | - Weighting factor, in atom probe, often termed multiplicity. - The weighting factor is the multiplier with which the integrated - intensity contribution from the point/ion gets multiplied. - The delocalization computes the integrated intensity for each - grid cell. Effectively, this is an explicitly evaluated kernel - method where each specific position of an ion is replaced by a - smoothing kernel. For atom probe weights are positive and integer - specifically the multiplicity of the ion, in accordance with the - respective rulesets as defined by weighting_model. - dimensions: - rank: 1 - dim: [[1, n_ions]] - grid(NXcg_grid): + Expectation value :math:`\mu_i$` of the kernel in each dimension + in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. + unit: NX_LENGTH + dim: (3,) + scalar_field_magn_SUFFIX(NXdata): + exists: [min, 0, max, infty] + doc: | + The result of the delocalization :math:`$\Phi = f(x, y, z)$` based on which subsequent iso-surfaces + will be computed. In commercial software so far there is no possibility to export this information. + + If the intensity for all matches of the weighting_model are summarized name this NXdata instance + scalar_field_magn_total. + + If the intensity is reported for each iontype one can avoid many subsequent + computations as individual intensities can be reinterpreted using a different weighting_model in + down-stream usage of the here reported values (e.g. with Python scripting). + In this case name the individual NXdata instances scalar_field_magn_ionID using the ID of the ion as + per the configuration of the ranging definitions used. + \@title(NX_CHAR): + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@xpos_indices(NX_UINT): + \@ypos_indices(NX_UINT): + \@zpos_indices(NX_UINT): + intensity(NX_FLOAT): + doc: | + The actual delocalized intensity values. + unit: NX_ANY + dim: (n_z, n_y, n_x) + xpos(NX_FLOAT): + doc: | + Cell center of mass positions along x. + unit: NX_LENGTH + dim: (n_x,) + ypos(NX_FLOAT): doc: | - The discretized domain/grid on which the delocalization is applied. + Cell center of mass positions along y. + unit: NX_LENGTH + dim: (n_y,) + zpos(NX_FLOAT): + doc: | + Cell center of mass positions along z. + unit: NX_LENGTH + dim: (n_z,) + xdmf_intensity(NX_FLOAT): + exists: optional + doc: | + Intensity of the field at given point + unit: NX_ANY + dim: (n_xyz,) + xdmf_xyz(NX_FLOAT): + exists: optional + doc: | + Center of mass positions of each voxel for rendering the scalar field + via XDMF in e.g. Paraview. + unit: NX_UNITLESS + dim: (n_xyz, 3) + xdmf_topology(NX_NUMBER): + exists: optional + doc: | + XDMF topology for rendering in combination with xdmf_xyz the scalar field + via XDMF in e.g. Paraview. + unit: NX_UNITLESS + dim: (i,) # 3*n_xyz + scalar_field_grad_SUFFIX(NXdata): + exists: [min, 0, max, infty] + doc: | + The three-dimensional gradient :math:`$\nabla \Phi$`. + Follow the naming convention of scalar_field_magn_SUFFIX to report parallel structures. + \@title(NX_CHAR): + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@xpos_indices(NX_CHAR): + \@ypos_indices(NX_CHAR): + \@zpos_indices(NX_CHAR): + intensity(NX_FLOAT): + doc: | + The actual point-wise component values. + unit: NX_ANY + dim: (n_z, n_y, n_x, 3) + xpos(NX_FLOAT): + doc: | + Cell center of mass positions along x. + unit: NX_LENGTH + dim: (n_x,) + ypos(NX_FLOAT): + doc: | + Cell center of mass positions along y. + unit: NX_LENGTH + dim: (n_y,) + zpos(NX_FLOAT): + doc: | + Cell center of mass positions along z. + unit: NX_LENGTH + dim: (n_z,) + xdmf_gradient(NX_FLOAT): + exists: optional + doc: | + The gradient vector formatted for direct visualization via XDMF in e.g. Paraview. + unit: NX_ANY + dim: (n_xyz, 3) + xdmf_xyz(NX_FLOAT): + exists: optional + doc: | + Center of mass positions of each voxel for rendering the scalar field gradient + via XDMF in e.g. Paraview. + unit: NX_LENGTH + dim: (n_xyz, 3) + xdmf_topology(NX_NUMBER): + exists: optional + doc: | + XDMF topology for rendering in combination with xdmf_xyz the scalar field + via XDFM in e.g. Paraview. + unit: NX_UNITLESS + dim: (i,) # 3*n_xyz + ##MK:: + iso_surfaceID(NXisocontour): + exists: [min, 0, max, infty] + doc: | + An iso-surface is the boundary between two regions across which the magnitude of a + scalar field falls below/exceeds a threshold magnitude :math:`$\varphi$`. + + For applications in atom probe microscopy, the location and shape of such a boundary (set) + is typically approximated by discretization - triangulation to be specific. + + This yields a complex of not necessarily connected geometric primitives. + Paraprobe-nanochem approximates this complex with a soup of triangles. + dimensionality(NX_POSINT): + isovalue(NX_NUMBER): + doc: | + The threshold or iso-contour value :math:`$\varphi`. + unit: NX_ANY + marching_cubes(NXcg_marching_cubes): + doc: | + Details about the specific marching cubes algorithm that was used for computing the iso-surface. + implementation(NX_CHAR): + doc: | + Reference to the specific implementation of marching cubes used. + The value placed here should be a DOI. If there are no specific + DOI or details write not_further_specified, or give at least a + free-text description. The program and version used is the + specific paraprobe-nanochem. + triangle_soup(NXcg_triangle_set): + exists: optional + doc: | + The resulting triangle soup computed via marching cubes. dimensionality(NX_POSINT): unit: NX_UNITLESS - enumeration: [1, 2, 3] cardinality(NX_POSINT): unit: NX_UNITLESS - doc: | - The total number of cells/voxels of the grid. - origin(NX_NUMBER): - dimensions: - rank: 1 - dim: [[1, d]] - symmetry: - doc: | - The symmetry of the lattice defining the shape of the unit cell. - enumeration: [cubic] - cell_dimensions(NX_NUMBER): - unit: NX_LENGTH - doc: | - The unit cell dimensions according to the coordinate system - defined under coordinate_system. - dimensions: - rank: 1 - dim: [[1, d]] - extent(NX_POSINT): - unit: NX_UNITLESS - doc: | - Number of unit cells along each of the d unit vectors. - The total number of cells, or grid points has to be the cardinality. - If the grid has an irregular number of grid positions in each direction, - as it could be for instance the case of a grid where all grid points - outside some masking primitive are removed, this extent field should - not be used. Instead use the coordinate field. - dimensions: - rank: 1 - dim: [[1, d]] - - # (NXtransformations): - coordinate_system: - exists: optional - doc: | - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - If the coordinate system is not specified the paraprobe - coordinate system is used. - - # should constraints on the grid be place here or not identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer which specifies the first index to be used for - distinguishing identifiers for cells. Identifiers are defined - either implicitly or explicitly. For implicit indexing the - identifiers are defined on the interval - [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - bounding_box(NXcg_hexahedron_set): doc: | - A tight axis-aligned bounding box about the grid. - is_axis_aligned(NX_BOOLEAN): - unit: NX_UNITLESS + Integer which specifies the first index to be used for distinguishing triangles. + Identifiers are defined either implicitly or explicitly. For implicit indexing the + identifiers are defined on the interval [identifier_offset, identifier_offset+c-1]. + unit: NX_UNITLESS + triangles(NXcg_face_list_data_structure): + number_of_vertices(NX_POSINT): + number_of_faces(NX_POSINT): + vertex_identifier_offset(NX_INT): + face_identifier_offset(NX_INT): + vertices(NX_NUMBER): + doc: | + Positions of the vertices. + + Users are encouraged to reduce the vertices to a unique set as this may + result in a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. Naively here means that each + vertex is stored even though many share the same positions. + unit: NX_LENGTH + dim: (i, 3) + faces(NX_INT): doc: | - For atom probe should be set to true. - identifier_offset(NX_INT): + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. unit: NX_UNITLESS + dim: (j,) + xdmf_topology(NX_UINT): doc: | - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - hexahedron(NXcg_face_list_data_structure): - vertex_identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - face_identifier_offset(NX_INT): - unit: NX_UNITLESS + A list of as many tuples of XDMF topology key, XDMF number + of vertices and a triple of vertex indices specifying each + triangle. The total number of entries is n_f_tri * (1+1+3). + unit: NX_UNITLESS + dim: (n_f_tri_xdmf,) + vertex_normal(NXcg_unit_normal_set): + exists: optional + normals(NX_FLOAT): doc: | - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - vertices(NX_NUMBER): - unit: NX_LENGTH + Direction of each normal. + unit: NX_DIMENSIONLESS + dim: (j, 3) + orientation(NX_UINT): + exists: optional doc: | - Positions of the vertices. + Qualifier how which specifically oriented normal to its + primitive each normal represents. - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - dimensions: - rank: 2 - dim: [[1, 8], [2, 3]] - faces(NX_NUMBER): + * 0 - undefined + * 1 - outer + * 2 - inner unit: NX_UNITLESS + dim: (j,) + # edge_normal(NXcg_unit_normal_set): + # exists: optional + face_normal(NXcg_unit_normal_set): + exists: optional + normals(NX_FLOAT): doc: | - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. + Direction of each normal. + unit: NX_DIMENSIONLESS + dim: (k, 3) + orientation(NX_UINT): + exists: optional + doc: | + Qualifier how which specifically oriented normal to its + primitive each normal represents. - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. - dimensions: - rank: 2 - dim: [[1, 6], [2, 4]] - xdmf_topology(NX_UINT): + * 0 - undefined + * 1 - outer + * 2 - inner unit: NX_UNITLESS + dim: (k,) + gradient_guide_magnitude(NX_FLOAT): 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. - dimensions: - rank: 1 - dim: [[1, 36]] - number_of_boundaries(NX_POSINT): - exists: optional - unit: NX_UNITLESS + Triangle normals are oriented in the direction of the + gradient vector of the local delocalized scalar field. + :math:`\sum_{x, y, z} {\nabla{c}_i}^2`. + unit: NX_ANY + dim: (k,) + # gradient_guide_quality(NX_FLOAT): + # doc: | + # Triangle normals are oriented in the direction of the + # gradient vector of the local delocalized scalar field. + # Sum of squared values of cross product of triangle normal + # construction. + # unit: NX_ANY + # dim: (k,) + gradient_guide_projection(NX_FLOAT): doc: | - How many distinct boundaries are distinguished? - Most grids discretize a cubic or cuboidal region. In this case - six sides can be distinguished, each making an own boundary. - boundaries: - exists: optional - doc: | - Name of the boundaries. E.g. left, right, front, back, bottom, top, - The field must have as many entries as there are number_of_boundaries. - dimensions: - rank: 1 - dim: [[1, 6]] - boundary_conditions(NX_INT): - exists: optional - unit: NX_UNITLESS - doc: | - The boundary conditions for each boundary: - - 0 - undefined - 1 - open - 2 - periodic - 3 - mirror - 4 - von Neumann - 5 - Dirichlet - dimensions: - rank: 1 - dim: [[1, 6]] - - ##MK::how to avoid storing it for once in NeXus for H5Web and - # for XDMF in ParaView ? - scalar_field_magnitude(NXdata): - doc: | - The result of the delocalization based on which subsequent - iso-surfaces will be computed. In commercial software so far - there is not a possibility to export such grid. - - ##MK::math notation - \@long_name: - exists: optional - \@signal: - \@axes: - \@xpos_indices: - \@ypos_indices: - \@zpos_indices: - intensity(NX_FLOAT): - dimensions: - rank: 3 - dim: [[1, n_z], [2, n_y], [3, n_x]] - xpos(NX_FLOAT): - doc: | - Cell center of mass positions along x. - dimensions: - rank: 1 - dim: [[1, n_x]] - - ##MK::how to relate back that this x is paraprobe x? - ypos(NX_FLOAT): - doc: | - Cell center of mass positions along y. - dimensions: - rank: 1 - dim: [[1, n_y]] - zpos(NX_FLOAT): - doc: | - Cell center of mass positions along z. - dimensions: - rank: 1 - dim: [[1, n_z]] - xdmf_intensity(NX_FLOAT): - exists: optional - unit: NX_ANY - doc: | - Intensity of the field at given point - dimensions: - rank: 1 - dim: [[1, n_xyz]] - xdmf_xyz(NX_FLOAT): - exists: optional - unit: NX_UNITLESS - doc: | - Center of mass positions of each voxel for - rendering the scalar field via XDMF in e.g. - Paraview. - dimensions: - rank: 2 - dim: [[1, n_xyz], [2, 3]] - xdmf_topology(NX_NUMBER): + Triangle normals are oriented in the direction of the + gradient vector of the local delocalized scalar field. + The projection variable here describes the cosine of the + angle between the gradient direction and the normal + direction vector. + This is a descriptor of how parallel the projection is + that is especially useful to document those triangles + for whose the projection is almost perpendicular. + unit: NX_ANY + dim: (k,) + area(NX_NUMBER): exists: optional - unit: NX_UNITLESS - doc: | - XDMF topology for rendering in combination with - xdmf_xyz the scalar field via XDFM in e.g. Paraview. - dimensions: - rank: 1 - dim: [[1, 3*n_xyz]] - scalar_field_gradient(NXdata): - doc: | - The three-dimensional gradient nabla operator applied to - scalar_field_magnitude. - - ##MK::boundary conditions which type of accuracy - ##MK::math notation - \@signal: - \@axes: - - ##MK::vector_indices, # ##MK: 3 - \@xpos_indices: - \@ypos_indices: - \@zpos_indices: - \@long_name: + unit: NX_AREA + dim: (j,) + edge_length(NX_NUMBER): exists: optional - intensity(NX_FLOAT): - dimensions: - rank: 4 - dim: [[1, n_z], [2, n_y], [3, n_x], [4, 3]] - xpos(NX_FLOAT): - doc: | - Cell center of mass positions along x. - dimensions: - rank: 1 - dim: [[1, n_x]] - - ##MK::how to relate back that this x is paraprobe x? - ypos(NX_FLOAT): doc: | - Cell center of mass positions along y. - dimensions: - rank: 1 - dim: [[1, n_y]] - zpos(NX_FLOAT): - doc: | - Cell center of mass positions along z. - dimensions: - rank: 1 - dim: [[1, n_z]] - xdmf_gradient(NX_FLOAT): + Array of edge length values. For each triangle the edge length + is reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + unit: NX_LENGTH + dim: (k, 3) + interior_angle(NX_NUMBER): exists: optional - unit: NX_ANY doc: | - The gradient vector. - dimensions: - rank: 2 - dim: [[1, n_xyz], [2, 3]] - xdmf_xyz(NX_FLOAT): + Array of interior angle values. For each triangle the angle + is reported for the angle opposite to the edges which are + traversed according to the sequence in which vertices + are indexed in triangles. + unit: NX_ANGLE + dim: (j, 4) + center(NX_NUMBER): exists: optional - unit: NX_UNITLESS doc: | - Center of mass positions of each voxel for - rendering the scalar field via XDMF in e.g. - Paraview. - dimensions: - rank: 2 - dim: [[1, n_xyz], [2, 3]] - xdmf_topology(NX_NUMBER): - exists: optional - unit: NX_UNITLESS + The center of mass of each triangle. + unit: NX_LENGTH + dim: (j, 3) + + volumetric_features(NXprocess): + exists: [min, 0, max, 1] doc: | - XDMF topology for rendering in combination with - xdmf_xyz the scalar field via XDFM in e.g. Paraview. - dimensions: - rank: 1 - dim: [[1, 3*n_xyz]] - kernel_size(NX_POSINT): - unit: NX_DIMENSIONLESS - doc: | - Halfwidth of the kernel about the central voxel. - The shape of the kernel is that of a cuboid - of extent 2*kernel_extent[i] + 1 in each dimension i. - - # \@units: pixel - dimensions: - rank: 1 - dim: [[1, 3]] - - # kernel_type: - # doc: | - # Functional form of the kernel (Ansatz function). - kernel_sigma(NX_FLOAT): - unit: NX_LENGTH - doc: | - Sigma of the kernel in each dimension in the paraprobe - coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. - dimensions: - rank: 1 - dim: [[1, 3]] - kernel_mu(NX_FLOAT): - unit: NX_LENGTH - doc: | - Expectation value of the kernel in each dimension in the paraprobe - coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. - dimensions: - rank: 1 - dim: [[1, 3]] - - ##MK:: - iso_surface(NXisocontour): - exists: optional - doc: | - An iso-surface is the boundary between two regions across which - the magnitude of a scalar field falls below/exceeds a threshold - magnitude phi. - For applications in atom probe microscopy the location and shape - of such a boundary (set) is typically approximated by - discretization. - This yields a complex of not necessarily connected geometric - primitives. Paraprobe-nanochem approximates this complex with - a soup of triangles. - dimensionality(NX_POSINT): - unit: NX_UNITLESS - isovalue(NX_NUMBER): - unit: NX_ANY - doc: | - The threshold or iso-contour value. - marching_cubes(NXcg_marching_cubes): - doc: | - Details about the specific marching cubes algorithm - which was taken to compute the iso-surface. - The grid is the delocalization grid. - implementation: - doc: | - Reference to the specific implementation of marching cubes used. - The value placed here should be a DOI. If there are no specific - DOI or details write not_further_specified, or give at least a - free-text description. The program and version used is the - specific paraprobe-nanochem. - triangle_soup(NXcg_triangle_set): - exists: optional - doc: | - The resulting triangle soup computed via marching cubes. - dimensionality(NX_POSINT): - unit: NX_UNITLESS - cardinality(NX_POSINT): - unit: NX_UNITLESS - identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer which specifies the first index to be used for - distinguishing triangles. Identifiers are defined either - implicitly or explicitly. For implicit indexing the - identifiers are defined on the interval - [identifier_offset, identifier_offset+c-1]. - triangles(NXcg_face_list_data_structure): - number_of_vertices(NX_POSINT): - unit: NX_UNITLESS - doc: | - Number of vertices. - number_of_faces(NX_POSINT): - unit: NX_UNITLESS - doc: | - Number of faces. - vertex_identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - face_identifier_offset(NX_INT): - unit: NX_UNITLESS - doc: | - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - vertices(NX_NUMBER): - unit: NX_LENGTH - doc: | - Positions of the vertices. - - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. - dimensions: - rank: 2 - dim: [[1, i], [2, 3]] - faces(NX_INT): - unit: NX_UNITLESS - doc: | - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. - dimensions: - rank: 1 - dim: [[1, j]] - xdmf_topology(NX_UINT): - unit: NX_UNITLESS - doc: | - A list of as many tuples of XDMF topology key, XDMF number - of vertices and a triple of vertex indices specifying each - triangle. The total number of entries is n_f_tri * (1+1+3). - dimensions: - rank: 1 - dim: [[1, n_f_tri_xdmf]] - vertex_normal(NXcg_unit_normal_set): - exists: optional - normals(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Direction of each normal. - dimensions: - rank: 2 - dim: [[1, j], [2, 3]] - orientation(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - Qualifier how which specifically oriented normal to its - primitive each normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner - dimensions: - rank: 1 - dim: [[1, j]] - - # edge_normal(NXcg_unit_normal_set): - # exists: optional - face_normal(NXcg_unit_normal_set): - exists: optional - normals(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - Direction of each normal. - dimensions: - rank: 2 - dim: [[1, k], [2, 3]] - orientation(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - Qualifier how which specifically oriented normal to its - primitive each normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner - dimensions: - rank: 1 - dim: [[1, k]] - gradient_guide_magnitude(NX_FLOAT): - unit: NX_ANY - doc: | - Triangle normals are oriented in the direction of the - gradient vector of the local delocalized scalar field. - :math:`\sum_{x, y, z} {\nabla{c}_i}^2`. - dimensions: - rank: 1 - dim: [[1, k]] + Iso-surfaces of arbitrary scalar three-dimensional fields can show a complicated topology. + Paraprobe-nanochem can run a DBScan-like clustering algorithm which performs a + connectivity analysis on the triangle soup representation of such iso-surface. + This may yield a set of connected features whose individual surfaces are discretized + by a triangulated mesh each. Such volumetric features can be processed further using + paraprobe-nanochem using a workflow with at most two steps. - # gradient_guide_quality(NX_FLOAT): - # doc: | - # Triangle normals are oriented in the direction of the - # gradient vector of the local delocalized scalar field. - # Sum of squared values of cross product of triangle normal - # construction. - # unit: NX_ANY - # dimensions: - # rank: 1 - # dim: [[1, k]] - gradient_guide_projection(NX_FLOAT): - unit: NX_ANY - doc: | - Triangle normals are oriented in the direction of the - gradient vector of the local delocalized scalar field. - The projection variable here describes the cosine of the - angle between the gradient direction and the normal - direction vector. - This is a descriptor of how parallel the projection is - that is especially useful to document those triangles - for whose projection is almost perpendicular. - dimensions: - rank: 1 - dim: [[1, k]] - area(NX_NUMBER): - exists: optional - unit: NX_AREA - dimensions: - rank: 1 - dim: [[1, j]] - edge_length(NX_NUMBER): - exists: optional - unit: NX_LENGTH - doc: | - Array of edge length values. For each triangle the edge length - is reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - dimensions: - rank: 2 - dim: [[1, k], [2, 3]] - interior_angle(NX_NUMBER): - exists: optional - unit: NX_ANGLE - doc: | - Array of interior angle values. For each triangle the angle - is reported for the angle opposite to the edges which are - traversed according to the sequence in which vertices - are indexed in triangles. - dimensions: - rank: 2 - dim: [[1, j], [2, 4]] - center(NX_NUMBER): - exists: optional - unit: NX_LENGTH - doc: | - The center of mass of each triangle. - dimensions: - rank: 2 - dim: [[1, j], [2, 3]] - volumetric_feature(NXprocess): - exists: optional - doc: | - Iso-surfaces of arbitrary scalar three-dimensional fields - can show a complicated topology. Paraprobe-nanochem can run - a DBScan-like clustering algorithm which performs a - connectivity analysis on the triangle soup. This yields a - set of connected features with their surfaces discretized - by triangles. Currently, the tool distinguishes at most - three types of features: + In the first step, the tool distinguishes three types of (v) i.e. volumetric features: - 1. So-called objects, i.e. necessarily watertight features - represented polyhedra. - 2. So-called proxies, i.e. features that were replaced by a - proxy mesh and made watertight. - 3. Remaining triangle surface meshes of arbitrary shape and - cardinality. + 1. So-called objects, i.e. necessarily watertight features represented by polyhedra. + These objects were already watertight within the triangulated iso-surface. + 2. So-called proxies, i.e. features that were not necessarily watertight within the triangulated + iso-surface but were subsequently replaced by a watertight mesh using polyhedral mesh + processing operations (hole filling, refinement, fairing operations). + 3. Remaining triangle surface meshes or parts of these of arbitrary shape and cardinality + that are not transformable into proxies or for which no transformation into proxies was + instructed. - These features can be interpreted as microstructural features. - Some of them may be precipitates, some of them may be poles, - some of them may be segments of dislocation lines or other + These features can be interpreted as microstructural features. Some of them may be precipitates, + some of them may be poles, some of them may be segments of dislocation lines or other crystal defects which are decorated (or not) with solutes. - - # Each type of feature needs to be registered in the feature_type - # dictionary. Type identifiers (keywords are integer), values - # are human-readable names like object, proxy, undefined - # NEW ISSUE: refactor using instances of NXms_feature_set + + In the second step, the tool can be used to analyze the proximity of these objects to a + model of the surface (edge) of the dataset. triangle_cluster_identifier(NX_UINT): - unit: NX_UNITLESS doc: | The identifier which the triangle_soup connectivity analysis returned, which constitutes the first step of the volumetric_feature identification process. - dimensions: - rank: 1 - dim: [[1, k]] + unit: NX_UNITLESS + dim: (n_v_feat,) feature_type_dict_keyword(NX_UINT): exists: optional - unit: NX_UNITLESS doc: | The array of keywords of feature_type dictionary. - dimensions: - rank: 1 - dim: [[1, n_feature_dict]] + unit: NX_UNITLESS + dim: (n_feature_dict,) feature_type_dict_value: exists: optional doc: | The array of values for each keyword of the feature_type dictionary. - dimensions: - rank: 1 - dim: [[1, n_feature_dict]] + dim: (n_feature_dict,) feature_type(NX_UINT): - unit: NX_ANY doc: | The array of controlled keywords, need to be from feature_type_dict_keyword, which specify which type each feature triangle cluster belongs to. Keep in mind that not each feature is an object or proxy. - dimensions: - rank: 1 - dim: [[1, j]] - feature_identifier(NX_UINT): unit: NX_UNITLESS + dim: (n_v_feat,) + feature_identifier(NX_UINT): doc: | The explicit identifier of features. - dimensions: - rank: 1 - dim: [[1, j]] - - ##MK::a nice example why we need group-overarching symbols - # a symbol for triangles would not work as the analysis can - # hold multiple instances of iso_surface each with a different - # number of triangles and/or features! - # details about specific features - objects(NXprocess): - exists: optional + unit: NX_UNITLESS + dim: (n_v_feat,) + FEATURE(NXprocess): + exists: [min, 0, max, 6] # because there are at most six different categories of features, see below doc: | - Details for features which are (closed) objects. - Identifier have to exist in feature_identifier. - - ##MK::constraints! + In all situations instances of the parent NXprocess group are returned with a very similar + information structuring and thus we here replace the template name FEATURE + with one of the following types feature-specific group names: + + * objects, objects, irrespective their distance to the surface + * objects_close_to_edge, sub-set of v_feature_object close surface + * objects_far_from_edge, sub-set of v_feature_object not close to the surface + * proxies, proxies, irrespective their distance to the surface + * proxies_close_to_edge, sub-set of v_feature_proxies, close to surface + * proxies_far_from_edge, sub-set of v_feature_proxies, not close to surface + feature_identifier(NX_UINT): + doc: | + Explicit identifier of the feature a sub-set of the feature_identifier in the parent group. unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] + dim: (i,) volume(NX_FLOAT): + doc: | + Volume of the feature. NaN for non-watertight objects. unit: NX_VOLUME - dimensions: - rank: 1 - dim: [[1, i]] + dim: (i,) obb(NXcg_hexahedron_set): exists: optional doc: | An oriented bounding box (OBB) to each object. size(NX_FLOAT): exists: optional - unit: NX_LENGTH doc: | - Edge length of the oriented bounding box from largest - to smallest value. - dimensions: - rank: 2 - dim: [[1, i], [2, 3]] - - ##MK::which is which + Edge length of the oriented bounding box from largest to smallest value. + unit: NX_LENGTH + dim: (i, 3) aspect(NX_FLOAT): exists: optional - unit: NX_DIMENSIONLESS doc: | - Oriented bounding box aspect ratio. YX versus ZY. - dimensions: - rank: 2 - dim: [[1, i], [2, 2]] + Oriented bounding box aspect ratio. + YX versus ZY or second-largest over largest and smallest over second largest. + unit: NX_DIMENSIONLESS + dim: (i, 2) center(NX_NUMBER): exists: optional - unit: NX_LENGTH doc: | Position of the geometric center, which often is but not necessarily has to be the center_of_mass of the hexahedrally-shaped sample/sample part. - dimensions: - rank: 2 - dim: [[1, i], [2, 3]] + unit: NX_LENGTH + dim: (i, 3) hexahedra(NXcg_face_list_data_structure): - - # exists: [min, 0, max, 1] + exists: optional doc: | - A simple approach to describe the entire set of hexahedra - when the main intention is to store the shape of the - hexahedra for visualization. - - ##MK::more details needed here + A simple approach to describe the entire set of hexahedra when the main intention + is to store the shape of the hexahedra for visualization. vertices(NX_NUMBER): unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, k], [2, 3]] - + dim: (k, 3) ##MK::again we have no effective way to pinpoint the n_rows ##MK::namely k != i each OBB has eight vertices xdmf_topology(NX_UINT): unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, k]] + dim: (k,) xdmf_feature_identifier(NX_UINT): unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, k]] - objects_close_to_edge(NXprocess): - exists: optional - doc: | - Details for all those objects close to edge, i.e. those which - have at least one ion which lays closer to a modelled edge - of the dataset than threshold. - feature_identifier(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - volume(NX_FLOAT): - unit: NX_VOLUME - dimensions: - rank: 1 - dim: [[1, i]] - composition(NXchemical_composition): - exists: optional - total(NX_NUMBER): + dim: (k,) + objectID(NXcg_polyhedron_set): + exists: [min, 0, max, infty] # not infty but at most n_v_feat + polyhedron(NXcg_face_list_data_structure): + # number_of_vertices(NX_POSINT): + # number_of_faces(NX_POSINT): + # vertex_identifier_offset(NX_UINT): + # face_identifier_offset(NX_UINT): + vertices(NX_FLOAT): + unit: NX_LENGTH + dim: (n_v, 3) + faces(NX_UINT): unit: NX_UNITLESS - doc: | - Total (count) relevant for normalization. - dimensions: - rank: 1 - dim: [[1, i]] - ION(NXion): - exists: ['min', '0', 'max', 'unbounded'] - charge(NX_INT): - isotope_vector(NX_UINT): - nuclid_list(NX_UINT): - count(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Count or weight which, when divided by total, - yields the composition of this element, isotope, - molecule or ion. - dimensions: - rank: 1 - dim: [[1, i]] - objectID(NXcg_polyhedron_set): - exists: ['min', '0', 'max', 'unbounded'] - polyhedron(NXcg_face_list_data_structure): - - # number_of_vertices(NX_POSINT): - # number_of_faces(NX_POSINT): - # vertex_identifier_offset(NX_UINT): - # face_identifier_offset(NX_UINT): - vertices(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_v], [2, 3]] - faces(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_f], [2, 3]] - - # face_normals(NXcg_unit_normal_set): - face_normals(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_f], [2, 3]] - xdmf_topology(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, k]] - xdmf_feature_identifier(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, k]] - ion_identifier(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - Array of evaporation_identifier / ion_identifier which - specify ions laying inside or on the surface of the feature. - dimensions: - rank: 1 - dim: [[1, i]] - objects_far_from_edge(NXprocess): - exists: optional - doc: | - Details for all those objects far from edge, i.e. those - whose ions lay all at least threshold distant from a - modelled edge of the dataset. - feature_identifier(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - volume(NX_FLOAT): - unit: NX_VOLUME - dimensions: - rank: 1 - dim: [[1, i]] - composition(NXchemical_composition): - exists: optional - total(NX_NUMBER): + dim: (n_f, 3) + face_normals(NX_FLOAT): + unit: NX_LENGTH + dim: (n_f, 3) + xdmf_topology(NX_UINT): + exists: recommended unit: NX_UNITLESS - doc: | - Total (count) relevant for normalization. - dimensions: - rank: 1 - dim: [[1, i]] - ION(NXion): - exists: ['min', '0', 'max', 'unbounded'] - charge(NX_INT): - isotope_vector(NX_UINT): - nuclid_list(NX_UINT): - count(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Count or weight which, when divided by total - yields the composition of this element, isotope, - molecule or ion. - dimensions: - rank: 1 - dim: [[1, i]] - objectID(NXcg_polyhedron_set): - exists: ['min', '0', 'max', 'unbounded'] - polyhedron(NXcg_face_list_data_structure): - - # number_of_vertices(NX_POSINT): - # number_of_faces(NX_POSINT): - # vertex_identifier_offset(NX_UINT): - # face_identifier_offset(NX_UINT): - vertices(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_v], [2, 3]] - faces(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_f], [2, 3]] - - # face_normals(NXcg_unit_normal_set): - face_normals(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_f], [2, 3]] - xdmf_topology(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, k]] - xdmf_feature_identifier(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, k]] - ion_identifier(NX_UINT): - exists: optional + dim: (k,) + xdmf_feature_identifier(NX_UINT): + exists: recommended unit: NX_UNITLESS - doc: | - Array of evaporation_identifier / ion_identifier which - specify ions laying inside or on the surface of the feature. - dimensions: - rank: 1 - dim: [[1, i]] - - # linear_feature_identification(NXprocess): - # these would be polylines etc - proxies(NXprocess): - exists: optional - doc: | - Details for features which are so-called proxies, i.e. objects - which have been reconstructed and combinatorially closed with - processing their partial triangulated_surface_mesh - (hole filling, refinement). - Identifier have to exist in feature_identifier. - - ##MK::constraints feature_identifier are a subset of the parent! - feature_identifier(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - volume(NX_FLOAT): - unit: NX_VOLUME - dimensions: - rank: 1 - dim: [[1, i]] - - # obb ? - proxies_close_to_edge(NXprocess): - exists: optional - doc: | - Details for those proxies close to edge, i.e. those which - have at least one ion which lays closer to a modelled edge - of the dataset than threshold. - Identifier have to exist in feature_identifier. - - ##MK::constraints! - feature_identifier(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - volume(NX_FLOAT): - unit: NX_VOLUME - dimensions: - rank: 1 - dim: [[1, i]] - composition(NXchemical_composition): - exists: optional - total(NX_NUMBER): - unit: NX_UNITLESS + dim: (k,) + ion_identifier(NX_UINT): + exists: optional doc: | - Total (count) relevant for normalization. - dimensions: - rank: 1 - dim: [[1, i]] - ION(NXion): - exists: ['min', '0', 'max', 'unbounded'] - - # charge(NX_INT): - # isotope_vector(NX_UINT): - count(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Count or weight which, when divided by total - yields the composition of this element, isotope, - molecule or ion. - dimensions: - rank: 1 - dim: [[1, i]] - objectID(NXcg_polyhedron_set): - exists: ['min', '0', 'max', 'unbounded'] - polyhedron(NXcg_face_list_data_structure): - - # number_of_vertices(NX_POSINT): - # number_of_faces(NX_POSINT): - # vertex_identifier_offset(NX_UINT): - # face_identifier_offset(NX_UINT): - vertices(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_v], [2, 3]] - faces(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_f], [2, 3]] - - # face_normals(NXcg_unit_normal_set): - face_normals(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_f], [2, 3]] - xdmf_topology(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, k]] - xdmf_feature_identifier(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, k]] - ion_identifier(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - Array of evaporation_identifier / ion_identifier which - specify ions laying inside or on the surface of the feature. - dimensions: - rank: 1 - dim: [[1, i]] - proxies_far_from_edge(NXprocess): + Array of evaporation_identifier / ion_identifier which details which ions + lie inside or on the surface of the feature. + unit: NX_UNITLESS + dim: (m,) + composition(NXchemical_composition): exists: optional - doc: | - Details for those proxies far from edge, i.e. those whose - ions lay all at least threshold distant from a - modelled edge of the dataset. - feature_identifier(NX_UINT): + total(NX_NUMBER): + doc: | + Total (count) of ions inside or on the surface of the feature relevant for normalization. + NaN for non watertight objects. unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - volume(NX_FLOAT): - unit: NX_VOLUME - dimensions: - rank: 1 - dim: [[1, i]] - composition(NXchemical_composition): - exists: optional - total(NX_NUMBER): - unit: NX_UNITLESS + dim: (i,) + ionID(NXion): + exists: [min, 0, max, infty] + charge_state(NX_INT): + # check these two ? + nuclide_hash(NX_UINT): + nuclide_list(NX_UINT): + count(NX_NUMBER): doc: | - Total (count) relevant for normalization. - dimensions: - rank: 1 - dim: [[1, i]] - ION(NXion): - exists: ['min', '0', 'max', 'unbounded'] - - # charge(NX_INT): - # isotope_vector(NX_UINT): - count(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Count or weight which, when divided by total - yields the composition of this element, isotope, - molecule or ion. - dimensions: - rank: 1 - dim: [[1, i]] - objectID(NXcg_polyhedron_set): - exists: ['min', '0', 'max', 'unbounded'] - polyhedron(NXcg_face_list_data_structure): - - # number_of_vertices(NX_POSINT): - # number_of_faces(NX_POSINT): - # vertex_identifier_offset(NX_UINT): - # face_identifier_offset(NX_UINT): - vertices(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_v], [2, 3]] - faces(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, n_f], [2, 3]] - - # face_normals(NXcg_unit_normal_set): - face_normals(NX_FLOAT): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, n_f], [2, 3]] - xdmf_topology(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, k]] - xdmf_feature_identifier(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, k]] - ion_identifier(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - Array of evaporation_identifier / ion_identifier which - specify ions laying inside or on the surface of the feature. - dimensions: - rank: 1 - dim: [[1, i]] - interface_modelling(NXprocess): - exists: optional - ion_multiplicity(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - The multiplicity whereby the ion position is accounted for - irrespective whether the ion is considered as a decorator - of the interface or not. - As an example, with atom probe it is typically not possible - to resolve the positions of the atoms which arrive at the detector - as molecular ions. Therefore, an exemplar molecular ion of two carbon - atoms can be considered to have a multiplicity of two to account that - this molecular ion contributes two carbon atoms at the reconstructed - location considering that the spatial resolution of atom probe - experiments is limited. - dimensions: - rank: 1 - dim: [[1, n_ions]] - decorator_multiplicity(NX_UINT): - exists: optional - unit: NX_UNITLESS - doc: | - The multiplicity whereby the ion position is accounted for when - the ion is considered one which is a decorator of the interface. - dimensions: - rank: 1 - dim: [[1, n_ions]] - initial_interface(NXprocess): + Count or weight which, when divided by total, yields the composition of this element, + nuclide, or (molecular) ion within the volume of the feature/object. + unit: NX_UNITLESS + dim: (i,) + # profiling + programID(NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + profiling(NXcs_profiling): + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + status(NX_CHAR): + current_working_directory(NX_CHAR): + total_elapsed_time(NX_NUMBER): exists: optional + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): + interface_meshing(NXapm_paraprobe_tool_results): + exists: [min, 0, max, 1] + config(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + window(NXcs_filter_boolean_mask): + number_of_ions(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + # results + ion_multiplicity(NX_UINT): + exists: optional + unit: NX_UNITLESS + doc: | + The multiplicity whereby the ion position is accounted for + irrespective whether the ion is considered as a decorator + of the interface or not. + As an example, with atom probe it is typically not possible + to resolve the positions of the atoms which arrive at the detector + as molecular ions. Therefore, an exemplar molecular ion of two carbon + atoms can be considered to have a multiplicity of two to account that + this molecular ion contributes two carbon atoms at the reconstructed + location considering that the spatial resolution of atom probe + experiments is limited. + dim: (n_ions,) + decorator_multiplicity(NX_UINT): + exists: optional + unit: NX_UNITLESS + doc: | + The multiplicity whereby the ion position is accounted for when + the ion is considered one which is a decorator of the interface. + dim: (n_ions,) + initial_interface(NXprocess): + exists: optional + doc: | + The equation of the plane that is fitted initially. + point_normal_form(NX_FLOAT): + unit: NX_LENGTH doc: | - The equation of the plane that is fitted initially. - point_normal_form(NX_FLOAT): - unit: NX_LENGTH - doc: | - The four parameter :math:`ax + by + cz + d = 0` which define the plane. - dimensions: - rank: 1 - dim: [[1, 4]] - MESH_CURR_PRE_DCOM_STEP(NXcg_triangle_set): - exists: ['min', '0', 'max', 'unbounded'] + The four parameter :math:`$ax + by + cz + d = 0$` which define the plane. + dim: (4,) + mesh_stateID(NXcg_triangle_set): + exists: [min, 0, max, infty] # as many as DCOM steps * 2 because one for pre and one for post + doc: | + The triangle surface mesh representing the interface model. + Exported at state before or after the next DCOM step. + state(NX_CHAR): doc: | - The triangle surface mesh representing the interface model. - Exported at some iteration before the next DCOM step. + Was this state exported before or after the next DCOM step. + enumeration: [before, after] + dimensionality(NX_POSINT): + unit: NX_UNITLESS + cardinality(NX_POSINT): + unit: NX_UNITLESS + identifier_offset(NX_INT): + unit: NX_UNITLESS + triangles(NXcg_face_list_data_structure): dimensionality(NX_POSINT): unit: NX_UNITLESS - cardinality(NX_POSINT): + number_of_vertices(NX_POSINT): unit: NX_UNITLESS - identifier_offset(NX_INT): + number_of_faces(NX_POSINT): unit: NX_UNITLESS - triangles(NXcg_face_list_data_structure): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - number_of_vertices(NX_POSINT): - unit: NX_UNITLESS - number_of_faces(NX_POSINT): - unit: NX_UNITLESS - vertex_identifier_offset(NX_INT): - unit: NX_UNITLESS - edge_identifier_offset(NX_INT): - unit: NX_UNITLESS - face_identifier_offset(NX_INT): - unit: NX_UNITLESS - face_identifier(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, j]] - vertices(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, i], [2, 3]] - faces(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, j], [2, 3]] - xdmf_topology(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, k]] - - ##MK::vertex_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - cardinality(NX_POSINT): - unit: NX_UNITLESS - normals(NX_FLOAT): - unit: NX_LENGTH - doc: | - Direction of each normal - dimensions: - rank: 2 - dim: [[1, j], [2, 3]] - orientation(NX_UINT): - unit: NX_UNITLESS - doc: | - Qualifier how which specifically oriented normal to its primitive each - normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner - dimensions: - rank: 1 - dim: [[1, j]] - vertex_normal(NXcg_unit_normal_set): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - cardinality(NX_POSINT): - unit: NX_UNITLESS - normals(NX_FLOAT): - unit: NX_LENGTH - doc: | - Direction of each normal - dimensions: - rank: 2 - dim: [[1, j], [2, 3]] - orientation(NX_UINT): - unit: NX_UNITLESS - doc: | - Qualifier how which specifically oriented normal to its primitive each - normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner - dimensions: - rank: 1 - dim: [[1, j]] - area(NX_NUMBER): - unit: NX_AREA - dimensions: - rank: 1 - dim: [[1, c]] - edge_length(NX_NUMBER): - unit: NX_LENGTH - doc: | - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] - interior_angle(NX_NUMBER): - unit: NX_ANGLE - doc: | - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. - dimensions: - rank: 2 - dim: [[1, c], [2, 4]] - MESH_CURR_POST_DCOM_STEP(NXcg_triangle_set): - exists: ['min', '0', 'max', 'unbounded'] - doc: | - The triangle surface mesh representing the interface model. - Exported at some iteration after the next DCOM step. - dimensionality(NX_POSINT): + vertex_identifier_offset(NX_INT): unit: NX_UNITLESS - cardinality(NX_POSINT): + edge_identifier_offset(NX_INT): unit: NX_UNITLESS - identifier_offset(NX_INT): + face_identifier_offset(NX_INT): unit: NX_UNITLESS - triangles(NXcg_face_list_data_structure): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - number_of_vertices(NX_POSINT): - unit: NX_UNITLESS - number_of_faces(NX_POSINT): - unit: NX_UNITLESS - vertex_identifier_offset(NX_INT): - unit: NX_UNITLESS - face_identifier_offset(NX_INT): - unit: NX_UNITLESS - face_identifier(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, j]] - vertices(NX_NUMBER): - unit: NX_LENGTH - dimensions: - rank: 2 - dim: [[1, i], [2, 3]] - faces(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 2 - dim: [[1, j], [2, 3]] - xdmf_topology(NX_UINT): - unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, k]] - - ##MK::vertex_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - cardinality(NX_POSINT): - unit: NX_UNITLESS - normals(NX_FLOAT): - unit: NX_LENGTH - doc: | - Direction of each normal - dimensions: - rank: 2 - dim: [[1, j], [2, 3]] - orientation(NX_UINT): - unit: NX_UNITLESS - doc: | - Qualifier how which specifically oriented normal to its primitive each - normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner - dimensions: - rank: 1 - dim: [[1, j]] - vertex_normal(NXcg_unit_normal_set): - dimensionality(NX_POSINT): - unit: NX_UNITLESS - cardinality(NX_POSINT): - unit: NX_UNITLESS - normals(NX_FLOAT): - unit: NX_LENGTH - doc: | - Direction of each normal - dimensions: - rank: 2 - dim: [[1, j], [2, 3]] - orientation(NX_UINT): - unit: NX_UNITLESS - doc: | - Qualifier how which specifically oriented normal to its primitive each - normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner - dimensions: - rank: 1 - dim: [[1, j]] - area(NX_NUMBER): - unit: NX_AREA - dimensions: - rank: 1 - dim: [[1, c]] - edge_length(NX_NUMBER): + face_identifier(NX_UINT): + unit: NX_UNITLESS + dim: (j,) + vertices(NX_NUMBER): + unit: NX_LENGTH + dim: (i, 3) + vertex_normal(NX_FLOAT): unit: NX_LENGTH doc: | - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. - dimensions: - rank: 2 - dim: [[1, c], [2, 3]] - interior_angle(NX_NUMBER): - unit: NX_ANGLE - doc: | - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. - dimensions: - rank: 2 - dim: [[1, c], [2, 4]] - composition_analysis(NXprocess): - exists: optional - xdmf_cylinder(NXcg_polyhedron_set): - doc: | - The ROIs are defined as cylinders for the computations. - To visualize these though we discretize them into regular n-gons. - Using for instance a 360-gon, i.e. a regular n-gon with 360 - edges resolves the lateral surface of each cylinder very finely - so that they are rendered smoothly in visualization software. - dimensionality(NX_POSINT): + Direction of each vertex normal. + dim: (i, 3) + vertex_normal_orientation(NX_UINT): unit: NX_UNITLESS - cardinality(NX_POSINT): + doc: | + Qualifier which details how specifically oriented the + face normal is with respect to its primitive (triangle): + + * 0 - undefined + * 1 - outer + * 2 - inner + + dim: (i,) + faces(NX_UINT): unit: NX_UNITLESS - center(NX_NUMBER): - unit: NX_LENGTH + dim: (j, 3) + face_normal(NX_FLOAT): doc: | - Position of the geometric center, which often is but not - necessarily has to be the center_of_mass of the polyhedra. - dimensions: - rank: 2 - dim: [[1, i], [2, 3]] - roi_identifier(NX_UINT): + Direction of each face normal. + unit: NX_LENGTH + dim: (j, 3) + face_normal_orientation(NX_UINT): unit: NX_UNITLESS doc: | - Integer which specifies the first index to be used for distinguishing - ROI cylinder. Identifiers are defined explicitly. - dimensions: - rank: 1 - dim: [[1, i]] - polyhedra(NXcg_face_list_data_structure): - exists: ['min', '0', 'max', '1'] + Qualifier which details how specifically oriented the + face normal is with respect to its primitive (triangle): + + * 0 - undefined + * 1 - outer + * 2 - inner + + dim: (j,) + xdmf_topology(NX_UINT): + unit: NX_UNITLESS + dim: (k,) + area(NX_NUMBER): + unit: NX_AREA + dim: (c,) + edge_length(NX_NUMBER): + unit: NX_LENGTH + doc: | + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + dim: (c, 3) + interior_angle(NX_NUMBER): + unit: NX_ANGLE + doc: | + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + dim: (c, 4) + # profiling + programID(NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + profiling(NXcs_profiling): + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + status(NX_CHAR): + current_working_directory(NX_CHAR): + total_elapsed_time(NX_NUMBER): + exists: optional + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): + + oned_profile(NXapm_paraprobe_tool_results): + exists: [min, 0, max, 1] + config(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + window(NXcs_filter_boolean_mask): + number_of_ions(NX_UINT): + bitdepth(NX_UINT): + mask(NX_UINT): + # results + xdmf_cylinder(NXcg_polyhedron_set): + doc: | + The ROIs are defined as cylinders for the computations. To visualize these we discretize + them into regular n-gons. Using for instance 360-gons, i.e. a regular n-gon with 360 edges, + resolves the lateral surface of each cylinder such that their renditions are smooth in + visualization software like Paraview. + dimensionality(NX_POSINT): + unit: NX_UNITLESS + cardinality(NX_POSINT): + unit: NX_UNITLESS + center(NX_NUMBER): + doc: | + Position of the geometric center, which often is but not + necessarily has to be the center_of_mass of the polyhedra. + unit: NX_LENGTH + dim: (i, 3) + roi_identifier(NX_UINT): + doc: | + Integer which specifies the first index to be used for distinguishing + ROI cylinder explicitly. + unit: NX_UNITLESS + dim: (i,) + polyhedra(NXcg_face_list_data_structure): + exists: [min, 0, max, 1] edge_contact(NX_UINT): exists: optional unit: NX_UNITLESS - dimensions: - rank: 1 - dim: [[1, i]] - - ##MK::decomposed? + dim: (i,) number_of_atoms(NX_UINT): exists: optional - unit: NX_UNITLESS doc: | The number of atoms in each ROI. - dimensions: - rank: 1 - dim: [[1, i]] + unit: NX_UNITLESS + dim: (i,) number_of_ions(NX_UINT): exists: optional - unit: NX_UNITLESS doc: | The number of ions in each ROI. - dimensions: - rank: 1 - dim: [[1, i]] + unit: NX_UNITLESS + dim: (i,) orientation(NX_FLOAT): exists: optional - unit: NX_LENGTH doc: | The orientation of the ROI defined via a vector which points along the cylinder axis and whose length is the height of the cylinder. - dimensions: - rank: 2 - dim: [[1, i], [2, 3]] - ROI(NXcollection): - exists: ['min', '0', 'max', 'unbounded'] + unit: NX_LENGTH + dim: (i, 3) + roiID(NXobject): + exists: [min, 0, max, infty] # no max is := i + doc: | + EXPLAIN HOW FIELDS SIGNED_DISTANCE AND NUCLIDE + ARE COMPUTED/CONSTRUCTED. signed_distance(NX_FLOAT): doc: | In the direction of the ROI. - isotope(NX_UINT): + unit: NX_LENGTH + dim: (k,) + nuclide(NX_UINT): doc: | - Hashvalue - - ##MK::#define MYCHM_DATA_ISRF_TSKS_TSCL_OBJ_ROICYL_ROIID "RoiCylinderID" - ##MK::#define MYCHM_DATA_ISRF_TSKS_TSCL_OBJ_ROICYL_OBJID "RoiCylinderObjectID" - ##MK::end of the tool-specific section - performance(NXcs_profiling): - exists: recommended - current_working_directory: - command_line_call: - exists: optional - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - total_elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - (NXcs_computer): - exists: recommended - name: - exists: recommended - operating_system: - \@version: - uuid: + Hashvalue using the following hashing rule :math:`$H = Z + 256 * N$`. + unit: NX_UNITLESS + dim: (k,) + # profiling + programID(NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + profiling(NXcs_profiling): + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + status(NX_CHAR): + current_working_directory(NX_CHAR): + total_elapsed_time(NX_NUMBER): exists: optional - (NXcs_cpu): - exists: ['min', '0', 'max', 'unbounded'] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_gpu): - exists: ['min', '0', 'max', 'unbounded'] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_mm_sys): - exists: ['min', '0', 'max', '1'] - total_physical_memory(NX_NUMBER): - (NXcs_io_sys): - exists: ['min', '0', 'max', '1'] - (NXcs_io_obj): - exists: ['min', '1', 'max', 'unbounded'] - technology: - max_physical_capacity(NX_NUMBER): - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_profiling_event): - start_time(NX_DATE_TIME): - exists: optional - end_time(NX_DATE_TIME): - exists: optional - description: - elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - number_of_threads(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - number_of_gpus(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - max_virtual_memory_snapshot(NX_NUMBER): - exists: recommended - max_resident_memory_snapshot(NX_NUMBER): - exists: recommended - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 5c784d761ed7d02effea4621da7b23889984c1486546a5e95e76ac3ec9e1bc68 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The total number of ions in the reconstruction. -# -# -# -# -# The total number of atoms in the atomic_decomposition match filter. -# -# -# -# -# The total number of isotopes in the isotopic_decomposition match filter. -# -# -# -# -# The dimensionality of the delocalization grid. -# -# -# -# -# The cardinality/total number of cells/grid points in the delocalization grid. -# -# -# -# -# -# The total number of XDMF values to represent all faces of triangles via XDMF. -# -# -# -# -# The total number of entries in a feature dictionary. -# -# -# -# -# The total number of member distinguished when reporting composition. -# -# -# -# -# Results of a paraprobe-nanochem tool run. -# -# -# -# -# -# Version specifier of this application definition. -# -# -# -# -# -# Official NeXus NXDL schema with which this file was written. -# -# -# -# -# -# -# -# -# Given name of the program/software/tool with which this NeXus -# (configuration) file was generated. -# -# -# -# Ideally program version plus build number, or commit hash or description -# of ever persistent resources where the source code of the program and -# build instructions can be found so that the program can be configured -# ideally in such a manner that the result of this computational process -# is recreatable in the same deterministic manner. -# -# -# -# -# -# Ideally, a (globally persistent) unique identifier for referring -# to this analysis. -# -# -# -# -# Possibility for leaving a free-text description about this analysis. -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when the analysis behind this results file -# was started, i.e. the paraprobe-tool executable started as a process. -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when the analysis behind this results file -# were completed and the paraprobe-tool executable exited as a process. -# -# -# -# -# The absolute path and name of the config file for this analysis. -# -# -# -# At least SHA256 strong hash of the specific config_file for -# tracking provenance. -# -# -# -# -# -# Path to the directory where the tool should store NeXus/HDF5 results -# of this analysis. If not specified results will be stored in the -# current working directory. -# -# -# -# -# A statement whether the paraprobe-tool executable managed to -# process the analysis or failed prematurely. -# -# This status is written to the results file after the end_time -# at which point the executable must no longer compute analyses. -# Only when this status message is present and shows `success`, the -# user should consider the results. In all other cases, it might be -# that the executable has terminated prematurely or another error -# occurred. -# -# -# -# -# -# -# -# -# If used, contact information and eventually details -# of at least the person who performed this analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Details about the coordinate system conventions used. -# If nothing else is specified we assume that there -# has to be at least one set of NXtransformations named -# paraprobe defined, which specifies the coordinate system. -# In which all positions are defined. -# -# -# -# -# The individual coordinate systems which should be used. -# Field names should be prefixed with the following controlled terms -# indicating which individual coordinate system is described: -# -# * paraprobe -# * lab -# * specimen -# * laser -# * leap -# * detector -# * recon -# -# -# -# -# -# -# -# A bitmask which identifies which of the ions in the dataset were -# analyzed during this process. -# -# -# -# Number of ions covered by the mask. -# The mask value for most may be 0. -# -# -# -# -# Number of bits assumed matching on a default datatype. -# (e.g. 8 bits for a C-style uint8). -# -# -# -# -# The unsigned integer array representing the content of the mask. -# If padding is used, padded bits are set to 0. The mask is for -# convenience always as large as the entire dataset as it will -# be stored compressed anyway. The convenience feature with this -# is that then the mask can be decoded with numpy and mirrored -# against the evaporation_id array and one immediately can filter -# out all points that were used by the paraprobe-toolbox executable. -# The length of the array adds to the next unsigned integer -# if the number of ions in the dataset is not an integer -# multiple of the bitdepth (padding). -# -# -# -# -# -# -# -# -# -# -# The weighting model specifies how mark data are mapped to a weight -# per point/ion. For atom probe microscopy (APM) mark data are e.g. -# which iontype an ion has. As an example, different models are used -# which account differently for the multiplicity of a point/ion -# during delocalization: -# -# * unity, all points/ions get the same weight 1. -# * atomic_decomposition, points get as much weight as they -# have atoms of a type in atomic_decomposition_rule, -# * isotope_decomposition, points get as much weight as they have -# isotopes of a type in isotopic_decomposition_rule. -# -# -# -# -# -# -# -# -# -# -# A list of elements (via proton number) to consider for the -# atomic_decomposition weighting model. -# Elements must exist in the periodic table of elements and be -# specified by their number of protons. -# Values in match are isotope hash values using the following -# hashing rule $H = Z + 256*N$ with $Z$ the number of protons -# and $N$ the number of neutrons of the isotope. -# In the case of elements this hashing rule has the advantage -# that for elements the proton number is their hash value because -# N is zero. -# -# -# -# Meaning of the filter: -# Whitelist specifies which entries with said value to include. -# Entries with all other values will be filtered out. -# -# Blacklist specifies which entries with said value to exclude. -# Entries with all other values will be included. -# -# -# -# -# -# -# -# -# Array of values to filter according to method. For example, -# if the filter specifies [1, 5, 6] and method is whitelist, -# only entries with values matching 1, 5 or 6 will be processed. -# All other entries will be filtered out/not considered. -# -# -# -# -# -# -# -# -# A list of isotopes (via proton and neutron number) to consider -# for the isotopic_decomposition weighting model. -# Isotopes must exist in the nuclid table. -# Values in match are isotope hash values using the following -# hashing rule $H = Z + 256*N$ with $Z$ the number of protons -# and $N$ the number of neutrons of the isotope. -# -# -# -# Meaning of the filter: -# Whitelist specifies which entries with said value to include. -# Entries with all other values will be filtered out. -# -# Blacklist specifies which entries with said value to exclude. -# Entries with all other values will be included. -# -# -# -# -# -# -# -# -# Array of values to filter according to method. For example, -# if the filter specifies [1, 5, 6] and method is whitelist, -# only entries with values matching 1, 5 or 6 will be processed. -# All other entries will be filtered out/not considered. -# -# -# -# -# -# -# -# -# How results of the kernel-density estimation were computed -# into quantities. By default the tool computes the total number -# (intensity) of ions or elements. Alternatively the tool can compute -# the total intensity, the composition, or the concentration of the -# ions/elements specified by the white list of elements in each voxel. -# -# -# -# -# -# -# -# -# -# -# Weighting factor, in atom probe, often termed multiplicity. -# The weighting factor is the multiplier with which the integrated -# intensity contribution from the point/ion gets multiplied. -# The delocalization computes the integrated intensity for each -# grid cell. Effectively, this is an explicitly evaluated kernel -# method where each specific position of an ion is replaced by a -# smoothing kernel. For atom probe weights are positive and integer -# specifically the multiplicity of the ion, in accordance with the -# respective rulesets as defined by weighting_model. -# -# -# -# -# -# -# -# The discretized domain/grid on which the delocalization is applied. -# -# -# -# -# -# -# -# -# -# -# The total number of cells/voxels of the grid. -# -# -# -# -# -# -# -# -# -# The symmetry of the lattice defining the shape of the unit cell. -# -# -# -# -# -# -# -# The unit cell dimensions according to the coordinate system -# defined under coordinate_system. -# -# -# -# -# -# -# -# Number of unit cells along each of the d unit vectors. -# The total number of cells, or grid points has to be the cardinality. -# If the grid has an irregular number of grid positions in each direction, -# as it could be for instance the case of a grid where all grid points -# outside some masking primitive are removed, this extent field should -# not be used. Instead use the coordinate field. -# -# -# -# -# -# -# -# -# Reference to or definition of a coordinate system with -# which the positions and directions are interpretable. -# If the coordinate system is not specified the paraprobe -# coordinate system is used. -# -# -# -# -# -# Integer which specifies the first index to be used for -# distinguishing identifiers for cells. Identifiers are defined -# either implicitly or explicitly. For implicit indexing the -# identifiers are defined on the interval -# [identifier_offset, identifier_offset+c-1]. -# For explicit indexing the identifier array has to be defined. -# -# -# -# -# A tight axis-aligned bounding box about the grid. -# -# -# -# For atom probe should be set to true. -# -# -# -# -# Integer which specifies the first index to be used for distinguishing -# hexahedra. Identifiers are defined either implicitly -# or explicitly. For implicit indexing the identifiers are defined on the -# interval [identifier_offset, identifier_offset+c-1]. -# For explicit indexing the identifier array has to be defined. -# -# -# -# -# -# Integer which specifies the first index to be used for distinguishing -# identifiers for vertices. Identifiers are defined either implicitly -# or explicitly. For implicit indexing the identifiers are defined on the -# interval [identifier_offset, identifier_offset+c-1]. -# For explicit indexing the identifier array has to be defined. -# -# -# -# -# Integer which specifies the first index to be used for distinguishing -# identifiers for faces. Identifiers are defined either implicitly -# or explicitly. For implicit indexing the identifiers are defined on the -# interval [identifier_offset, identifier_offset+c-1]. -# For explicit indexing the identifier array has to be defined. -# -# -# -# -# Positions of the vertices. -# -# Users are encouraged to reduce the vertices to unique set of positions -# and vertices as this supports a more efficient storage of the geometry data. -# It is also possible though to store the vertex positions naively in which -# case vertices_are_unique is likely False. -# Naively here means that one for example stores each vertex of a triangle -# mesh even though many vertices are shared between triangles and thus -# the positions of these vertices do not have to be duplicated. -# -# -# -# -# -# -# -# -# Array of identifiers from vertices which describe each face. -# -# The first entry is the identifier of the start vertex of the first face, -# followed by the second vertex of the first face, until the last vertex -# of the first face. Thereafter, the start vertex of the second face, the -# second vertex of the second face, and so on and so forth. -# -# Therefore, summating over the number_of_vertices, allows to extract -# the vertex identifiers for the i-th face on the following index interval -# of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. -# -# -# -# -# -# -# -# -# Six equally formatted sextets chained together. For each -# sextett the first entry is an XDMF primitive topology -# key (here 5 for polygon), the second entry the XDMF primitive -# count value (here 4 because each face is a quad). -# The remaining four values are the vertex indices. -# -# -# -# -# -# -# -# How many distinct boundaries are distinguished? -# Most grids discretize a cubic or cuboidal region. In this case -# six sides can be distinguished, each making an own boundary. -# -# -# -# -# -# Name of the boundaries. E.g. left, right, front, back, bottom, top, -# The field must have as many entries as there are number_of_boundaries. -# -# -# -# -# -# -# -# The boundary conditions for each boundary: -# -# 0 - undefined -# 1 - open -# 2 - periodic -# 3 - mirror -# 4 - von Neumann -# 5 - Dirichlet -# -# -# -# -# -# -# -# -# -# The result of the delocalization based on which subsequent -# iso-surfaces will be computed. In commercial software so far -# there is not a possibility to export such grid. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Cell center of mass positions along x. -# -# -# -# -# -# -# -# -# Cell center of mass positions along y. -# -# -# -# -# -# -# -# Cell center of mass positions along z. -# -# -# -# -# -# -# -# Intensity of the field at given point -# -# -# -# -# -# -# -# Center of mass positions of each voxel for -# rendering the scalar field via XDMF in e.g. -# Paraview. -# -# -# -# -# -# -# -# -# XDMF topology for rendering in combination with -# xdmf_xyz the scalar field via XDFM in e.g. Paraview. -# -# -# -# -# -# -# -# -# The three-dimensional gradient nabla operator applied to -# scalar_field_magnitude. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Cell center of mass positions along x. -# -# -# -# -# -# -# -# -# Cell center of mass positions along y. -# -# -# -# -# -# -# -# Cell center of mass positions along z. -# -# -# -# -# -# -# -# The gradient vector. -# -# -# -# -# -# -# -# -# Center of mass positions of each voxel for -# rendering the scalar field via XDMF in e.g. -# Paraview. -# -# -# -# -# -# -# -# -# XDMF topology for rendering in combination with -# xdmf_xyz the scalar field via XDFM in e.g. Paraview. -# -# -# -# -# -# -# -# -# Halfwidth of the kernel about the central voxel. -# The shape of the kernel is that of a cuboid -# of extent 2*kernel_extent[i] + 1 in each dimension i. -# -# -# -# -# -# -# -# -# -# Sigma of the kernel in each dimension in the paraprobe -# coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. -# -# -# -# -# -# -# -# Expectation value of the kernel in each dimension in the paraprobe -# coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. -# -# -# -# -# -# -# -# -# -# An iso-surface is the boundary between two regions across which -# the magnitude of a scalar field falls below/exceeds a threshold -# magnitude phi. -# For applications in atom probe microscopy the location and shape -# of such a boundary (set) is typically approximated by -# discretization. -# This yields a complex of not necessarily connected geometric -# primitives. Paraprobe-nanochem approximates this complex with -# a soup of triangles. -# -# -# -# -# The threshold or iso-contour value. -# -# -# -# -# Details about the specific marching cubes algorithm -# which was taken to compute the iso-surface. -# The grid is the delocalization grid. -# -# -# -# Reference to the specific implementation of marching cubes used. -# The value placed here should be a DOI. If there are no specific -# DOI or details write not_further_specified, or give at least a -# free-text description. The program and version used is the -# specific paraprobe-nanochem. -# -# -# -# -# -# The resulting triangle soup computed via marching cubes. -# -# -# -# -# -# Integer which specifies the first index to be used for -# distinguishing triangles. Identifiers are defined either -# implicitly or explicitly. For implicit indexing the -# identifiers are defined on the interval -# [identifier_offset, identifier_offset+c-1]. -# -# -# -# -# -# Number of vertices. -# -# -# -# -# Number of faces. -# -# -# -# -# Integer which specifies the first index to be used for distinguishing -# identifiers for vertices. Identifiers are defined either implicitly -# or explicitly. For implicit indexing the identifiers are defined on the -# interval [identifier_offset, identifier_offset+c-1]. -# -# -# -# -# Integer which specifies the first index to be used for distinguishing -# identifiers for faces. Identifiers are defined either implicitly -# or explicitly. For implicit indexing the identifiers are defined on the -# interval [identifier_offset, identifier_offset+c-1]. -# -# -# -# -# Positions of the vertices. -# -# Users are encouraged to reduce the vertices to unique set of positions -# and vertices as this supports a more efficient storage of the geometry data. -# It is also possible though to store the vertex positions naively in which -# case vertices_are_unique is likely False. -# Naively here means that one for example stores each vertex of a triangle -# mesh even though many vertices are shared between triangles and thus -# the positions of these vertices do not have to be duplicated. -# -# -# -# -# -# -# -# -# Array of identifiers from vertices which describe each face. -# -# The first entry is the identifier of the start vertex of the first face, -# followed by the second vertex of the first face, until the last vertex -# of the first face. Thereafter, the start vertex of the second face, the -# second vertex of the second face, and so on and so forth. -# -# Therefore, summating over the number_of_vertices, allows to extract -# the vertex identifiers for the i-th face on the following index interval -# of the faces array: [$\sum_i = 0}^{i = n-1}$, $\sum_{i=0}^{i = n}$]. -# -# -# -# -# -# -# -# A list of as many tuples of XDMF topology key, XDMF number -# of vertices and a triple of vertex indices specifying each -# triangle. The total number of entries is n_f_tri * (1+1+3). -# -# -# -# -# -# -# -# -# Direction of each normal. -# -# -# -# -# -# -# -# -# Qualifier how which specifically oriented normal to its -# primitive each normal represents. -# -# * 0 - undefined -# * 1 - outer -# * 2 - inner -# -# -# -# -# -# -# -# -# -# -# Direction of each normal. -# -# -# -# -# -# -# -# -# Qualifier how which specifically oriented normal to its -# primitive each normal represents. -# -# * 0 - undefined -# * 1 - outer -# * 2 - inner -# -# -# -# -# -# -# -# Triangle normals are oriented in the direction of the -# gradient vector of the local delocalized scalar field. -# :math:`\sum_{x, y, z} {\nabla{c}_i}^2`. -# -# -# -# -# -# -# -# -# Triangle normals are oriented in the direction of the -# gradient vector of the local delocalized scalar field. -# The projection variable here describes the cosine of the -# angle between the gradient direction and the normal -# direction vector. -# This is a descriptor of how parallel the projection is -# that is especially useful to document those triangles -# for whose projection is almost perpendicular. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Array of edge length values. For each triangle the edge length -# is reported for the edges traversed according to the sequence -# in which vertices are indexed in triangles. -# -# -# -# -# -# -# -# -# Array of interior angle values. For each triangle the angle -# is reported for the angle opposite to the edges which are -# traversed according to the sequence in which vertices -# are indexed in triangles. -# -# -# -# -# -# -# -# -# The center of mass of each triangle. -# -# -# -# -# -# -# -# -# -# Iso-surfaces of arbitrary scalar three-dimensional fields -# can show a complicated topology. Paraprobe-nanochem can run -# a DBScan-like clustering algorithm which performs a -# connectivity analysis on the triangle soup. This yields a -# set of connected features with their surfaces discretized -# by triangles. Currently, the tool distinguishes at most -# three types of features: -# -# 1. So-called objects, i.e. necessarily watertight features -# represented polyhedra. -# 2. So-called proxies, i.e. features that were replaced by a -# proxy mesh and made watertight. -# 3. Remaining triangle surface meshes of arbitrary shape and -# cardinality. -# -# These features can be interpreted as microstructural features. -# Some of them may be precipitates, some of them may be poles, -# some of them may be segments of dislocation lines or other -# crystal defects which are decorated (or not) with solutes. -# -# -# -# -# The identifier which the triangle_soup connectivity analysis -# returned, which constitutes the first step of the -# volumetric_feature identification process. -# -# -# -# -# -# -# -# The array of keywords of feature_type dictionary. -# -# -# -# -# -# -# -# The array of values for each keyword of the -# feature_type dictionary. -# -# -# -# -# -# -# -# The array of controlled keywords, need to be from -# feature_type_dict_keyword, which specify which type -# each feature triangle cluster belongs to. -# Keep in mind that not each feature is an object or proxy. -# -# -# -# -# -# -# -# The explicit identifier of features. -# -# -# -# -# -# -# -# -# Details for features which are (closed) objects. -# Identifier have to exist in feature_identifier. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# An oriented bounding box (OBB) to each object. -# -# -# -# Edge length of the oriented bounding box from largest -# to smallest value. -# -# -# -# -# -# -# -# -# -# Oriented bounding box aspect ratio. YX versus ZY. -# -# -# -# -# -# -# -# -# Position of the geometric center, which often is but -# not necessarily has to be the center_of_mass of the -# hexahedrally-shaped sample/sample part. -# -# -# -# -# -# -# -# -# -# A simple approach to describe the entire set of hexahedra -# when the main intention is to store the shape of the -# hexahedra for visualization. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Details for all those objects close to edge, i.e. those which -# have at least one ion which lays closer to a modelled edge -# of the dataset than threshold. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Total (count) relevant for normalization. -# -# -# -# -# -# -# -# -# -# -# -# Count or weight which, when divided by total, -# yields the composition of this element, isotope, -# molecule or ion. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Array of evaporation_identifier / ion_identifier which -# specify ions laying inside or on the surface of the feature. -# -# -# -# -# -# -# -# -# -# -# Details for all those objects far from edge, i.e. those -# whose ions lay all at least threshold distant from a -# modelled edge of the dataset. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Total (count) relevant for normalization. -# -# -# -# -# -# -# -# -# -# -# -# Count or weight which, when divided by total -# yields the composition of this element, isotope, -# molecule or ion. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Array of evaporation_identifier / ion_identifier which -# specify ions laying inside or on the surface of the feature. -# -# -# -# -# -# -# -# -# -# -# -# -# Details for features which are so-called proxies, i.e. objects -# which have been reconstructed and combinatorially closed with -# processing their partial triangulated_surface_mesh -# (hole filling, refinement). -# Identifier have to exist in feature_identifier. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Details for those proxies close to edge, i.e. those which -# have at least one ion which lays closer to a modelled edge -# of the dataset than threshold. -# Identifier have to exist in feature_identifier. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Total (count) relevant for normalization. -# -# -# -# -# -# -# -# -# -# Count or weight which, when divided by total -# yields the composition of this element, isotope, -# molecule or ion. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Array of evaporation_identifier / ion_identifier which -# specify ions laying inside or on the surface of the feature. -# -# -# -# -# -# -# -# -# -# -# Details for those proxies far from edge, i.e. those whose -# ions lay all at least threshold distant from a -# modelled edge of the dataset. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Total (count) relevant for normalization. -# -# -# -# -# -# -# -# -# -# Count or weight which, when divided by total -# yields the composition of this element, isotope, -# molecule or ion. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Array of evaporation_identifier / ion_identifier which -# specify ions laying inside or on the surface of the feature. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The multiplicity whereby the ion position is accounted for -# irrespective whether the ion is considered as a decorator -# of the interface or not. -# As an example, with atom probe it is typically not possible -# to resolve the positions of the atoms which arrive at the detector -# as molecular ions. Therefore, an exemplar molecular ion of two carbon -# atoms can be considered to have a multiplicity of two to account that -# this molecular ion contributes two carbon atoms at the reconstructed -# location considering that the spatial resolution of atom probe -# experiments is limited. -# -# -# -# -# -# -# -# The multiplicity whereby the ion position is accounted for when -# the ion is considered one which is a decorator of the interface. -# -# -# -# -# -# -# -# The equation of the plane that is fitted initially. -# -# -# -# The four parameter :math:`ax + by + cz + d = 0` which define the plane. -# -# -# -# -# -# -# -# -# The triangle surface mesh representing the interface model. -# Exported at some iteration before the next DCOM step. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of each normal -# -# -# -# -# -# -# -# -# Qualifier how which specifically oriented normal to its primitive each -# normal represents. -# -# * 0 - undefined -# * 1 - outer -# * 2 - inner -# -# -# -# -# -# -# -# -# -# -# -# Direction of each normal -# -# -# -# -# -# -# -# -# Qualifier how which specifically oriented normal to its primitive each -# normal represents. -# -# * 0 - undefined -# * 1 - outer -# * 2 - inner -# -# -# -# -# -# -# -# -# -# -# -# -# -# Array of edge length values. For each triangle the edge length is -# reported for the edges traversed according to the sequence -# in which vertices are indexed in triangles. -# -# -# -# -# -# -# -# -# Array of interior angle values. For each triangle the angle is -# reported for the angle opposite to the edges which are traversed -# according to the sequence in which vertices are indexed in triangles. -# -# -# -# -# -# -# -# -# -# The triangle surface mesh representing the interface model. -# Exported at some iteration after the next DCOM step. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Direction of each normal -# -# -# -# -# -# -# -# -# Qualifier how which specifically oriented normal to its primitive each -# normal represents. -# -# * 0 - undefined -# * 1 - outer -# * 2 - inner -# -# -# -# -# -# -# -# -# -# -# -# Direction of each normal -# -# -# -# -# -# -# -# -# Qualifier how which specifically oriented normal to its primitive each -# normal represents. -# -# * 0 - undefined -# * 1 - outer -# * 2 - inner -# -# -# -# -# -# -# -# -# -# -# -# -# -# Array of edge length values. For each triangle the edge length is -# reported for the edges traversed according to the sequence -# in which vertices are indexed in triangles. -# -# -# -# -# -# -# -# -# Array of interior angle values. For each triangle the angle is -# reported for the angle opposite to the edges which are traversed -# according to the sequence in which vertices are indexed in triangles. -# -# -# -# -# -# -# -# -# -# -# -# The ROIs are defined as cylinders for the computations. -# To visualize these though we discretize them into regular n-gons. -# Using for instance a 360-gon, i.e. a regular n-gon with 360 -# edges resolves the lateral surface of each cylinder very finely -# so that they are rendered smoothly in visualization software. -# -# -# -# -# -# Position of the geometric center, which often is but not -# necessarily has to be the center_of_mass of the polyhedra. -# -# -# -# -# -# -# -# -# Integer which specifies the first index to be used for distinguishing -# ROI cylinder. Identifiers are defined explicitly. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The number of atoms in each ROI. -# -# -# -# -# -# -# -# The number of ions in each ROI. -# -# -# -# -# -# -# -# The orientation of the ROI defined via a vector which points along -# the cylinder axis and whose length is the height of the cylinder. -# -# -# -# -# -# -# -# -# -# In the direction of the ROI. -# -# -# -# -# Hashvalue -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Specify if it was different from the number_of_processes -# in the NXcs_profiling super class. -# -# -# -# -# -# Specify if it was different from the number_of_threads -# in the NXcs_profiling super class. -# -# -# -# -# -# Specify if it was different from the number_of_threads -# in the NXcs_profiling super class. -# -# -# -# -# -# -# -# -# + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): + # global + userID(NXuser): + exists: [min, 0, max, infty] + name(NX_CHAR): + coordinate_system_set(NXcoordinate_system_set): + paraprobe(NXcoordinate_system): + type(NX_CHAR): + handedness(NX_CHAR): + x(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + y(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + z(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXdelocalization.yaml b/contributed_definitions/nyaml/NXdelocalization.yaml index ad7e3abfc6..56090f42a7 100644 --- a/contributed_definitions/nyaml/NXdelocalization.yaml +++ b/contributed_definitions/nyaml/NXdelocalization.yaml @@ -14,7 +14,7 @@ symbols: Number of mark data per point/object. n_atoms: | Number of atoms in the whitelist. - n_isotopes: | + n_nuclides: | Number of isotopes in the whitelist. type: group NXdelocalization(NXobject): @@ -39,52 +39,46 @@ NXdelocalization(NXobject): # this weight is the multiplicity with respect to the interpretation model # i.e. a C:2 molecular ion has a multiplicity of 2 if the ion is considered # and the interpretation model that to consider carbon atoms or carbon ions - weighting_model(NX_CHAR): + weighting_model(NXmatch_filter): doc: | The weighting model specifies how mark data are mapped to a weight per point/object. - For atom probe microscopy (APM) as an example, different models are used which - account differently for the multiplicity of an ion/atom: - - * default, points all get the same weight 1.; - for APM this is equivalent to (molecular) iontype-based delocalization - * atomic_decomposition, points get as much weight as they have atoms - of a type in element_whitelist, - * isotope_decomposition, points get as much weight as they have - nuclids of a type in isotope_whitelist. - - This description shows an example that could be reinterpreted for - similar such data processing steps in other fields of science. - enumeration: [default, atomic_decomposition, isotope_decomposition] - # other - # can one conditionally set a field required if a weighting_model has a - # specific value, - # i.e. if atomic_decomposition is set element_whitelist t is required - # i.e. if isotope_decomposition is set isotope_whitelist is required? - element_whitelist(NX_UINT): - doc: | - A list of elements (via proton number) to consider for the atomic_decomposition - weighting model. Elements must exist in the periodic table of elements. - unit: NX_UNITLESS - dim: (n_atoms,) - isotope_whitelist(NX_UINT): - doc: | - A list of isotopes to consider for the isotope_decomposition weighting model. - Isotopes must exist in the nuclid table. Entries in the fastest changing - dimension should be the pair of proton (first entry) and neutron number - (second entry). - unit: NX_UNITLESS - dim: (n_isotopes, 2) - mark(NX_NUMBER): - doc: | - Attribute data for each member of the point cloud. For APM these are the - iontypes generated via ranging. The number of mark data per point is 1 - in the case for atom probe. - unit: NX_UNITLESS - dim: (n_p, n_m) - weight(NX_NUMBER): - doc: | - Weighting factor with which the integrated intensity per grid cell is - multiplied specifically for each point/object. For APM the weight are - positive integer values, specifically the multiplicity of the ion, - according to the details of the weighting_model. - unit: NX_UNITLESS + weighting_method(NX_CHAR): + doc: | + As an example from the research field of atom probe points/objects are (molecular) ions. + Different methods are used for weighting ions: + + * default, points get all the same weight 1., which for atom probe is equivalent + to (molecular) iontype-based delocalization. + * element, points get as much weight as they have atoms representing a nuclide + with a proton number that is matching to a respective entry in whitelist. + In atom probe jargon, this means atomic_decomposition. + * isotope, points get as much weight as they have atoms representing a nuclides + from a respective entry in whitelist. + In atom probe jargon, this means isotope_decomposition. + enumeration: [default, element, isotope] + # method is specialized from NXmatch_filter + method(NX_CHAR): + enumeration: [whitelist] + match(NX_UINT): + doc: | + A list of nuclides based on which to evaluate the weight. Nuclides need to exist in the nuclide table. + Values are nuclide (isotope) hash values using the following hashing rule :math:`$H = Z + 256 * N$` + with :math:`$Z$` the number of protons and :math:`$N$` the number of neutrons of the nuclide. + For elements set :math:`$N$` to zero. + unit: NX_UNITLESS + dim: (n_nuclides,) + mark(NX_NUMBER): + doc: | + Attribute data for each member of the point cloud. For APM these are the + iontypes generated via ranging. The number of mark data per point is 1 + in the case for atom probe. + unit: NX_UNITLESS + dim: (n_p, n_m) + weight(NX_NUMBER): + doc: | + Weighting factor with which the integrated intensity per grid cell is + multiplied specifically for each point/object. For APM the weight are + positive integer values, specifically the multiplicity of the ion, + according to the details of the weighting_method. + unit: NX_UNITLESS + dim: (n_p,) \ No newline at end of file From 7d21589f2875226beb6f629aa243bf204e271ff6 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 16 Feb 2024 23:37:49 +0100 Subject: [PATCH 0578/1012] Refactored NXapm_paraprobe_intersector_results, fixed formatting issues with math envs, removed obsolete FAIRmat Area B numbering schemes --- ...Xapm_paraprobe_intersector_config.nxdl.xml | 4 +- ...apm_paraprobe_intersector_results.nxdl.xml | 466 ++++------ .../NXapm_paraprobe_nanochem_results.nxdl.xml | 20 +- .../NXapm_paraprobe_intersector_config.yaml | 4 +- .../NXapm_paraprobe_intersector_results.yaml | 838 +++--------------- .../NXapm_paraprobe_nanochem_results.yaml | 20 +- manual/source/apm-structure.rst | 6 +- manual/source/ellipsometry-structure.rst | 6 +- manual/source/em-structure.rst | 6 +- manual/source/examples/index.rst | 6 +- manual/source/mpes-structure.rst | 6 +- manual/source/transport-structure.rst | 2 +- 12 files changed, 352 insertions(+), 1032 deletions(-) diff --git a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml index 35d3006df9..d8bcfde6ab 100644 --- a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml @@ -125,7 +125,7 @@ - This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`$k$`) + This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`k`) step when the current set was taken (see `M. Kühbach et al. 2022 <https://arxiv.org/abs/2205.13510>`_). @@ -194,7 +194,7 @@ - This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`$k+1$`) + This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`k + 1`) step when the current set was taken (see `M. Kühbach et al. 2022 <https://arxiv.org/abs/2205.13510>`_). diff --git a/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml index efa4b5baeb..b532602871 100644 --- a/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -53,342 +53,218 @@ - The number of rows in the table/matrix for coprecipitation stats. + The number of rows in the table/matrix for coprecipitation statistics. - Results of a paraprobe-intersector tool run. + Application definition for results files of the paraprobe-intersector tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. - - - - - Version specifier of this application definition. - - - - - - Official NeXus NXDL schema with which this file was written. - + + + - + - - + + - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. + The results of an overlap/intersection analysis. - + + + + + + + + + - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. + A matrix of feature_identifier that specifies which named features + from the current_set have directed link(s) pointing to which named + feature(s) from the next_set. - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - - - - - The absolute path and name of the config file for this analysis. - - + + + + + + - At least SHA256 strong hash of the specific config_file for - tracking provenance. + For each link/pair in current_to_next a characterization whether the + link is due to volumetric overlap (0x00 == 0), proximity (0x01 == 1), + or something else unknown (0xFF == 255). - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - - + + + + + - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon + A matrix of feature_identifier which specifies which named feature(s) + from the next_set have directed link(s) pointing to which named + feature(s) from the current_set. Only if the mapping whereby the + links are defined is symmetric it holds that next_to_current maps + the links for current_to_next in just the opposite direction. - - - - - + + + + + + - The results of an overlap/intersection analysis. + For each link/pair in next_to_current a characterization whether the + link is due to a volumetric overlap (0x00 == 0), proximity (0x01 == 1), + or something else unknown (0xFF == 255). - + + + + + + + For each pair of links in current_to_next the volume of the + intersection, i.e. how much volume do the two features share. + If features do not intersect the volume is zero. + + + + + + + + During coprecipitation analysis the current and next set are analyzed + for links in a special way. Three set comparisons are made. Members + of the set in each comparison are analyzed for overlap and proximity: + + The first comparison is the current_set against the current_set. + The second comparison is the next_set against the next_set. + The third comparison is the current_set against the next_set. + + Once the (forward) links for these comparisons are ready, pair relations + are analyzed with respect to which objects with feature_identifier(s) + cluster in identifier space. Thereby, a logical connection (link) is + established between the features in the current_set and the next_set. + Recall that these two sets typically represent different features + within an observed system for otherwise the same parameterization. + + Examples include two sets of e.g. precipitates with differing + chemical composition that were characterized in the same material + volume representing a snapshot of an e.g. microstructure at the same + point in time. Researchers may have performed two analyses, one to + characterize precipitates A and another one for percipitates B. + + Coprecipitation analysis now logically connects these independent + characterization results to establish spatial correlations of e.g. + the precipitates' spatial arrangement. + + - A matrix of feature_identifier which specifies which named features - from the current set have directed link(s) pointing to which named - feature(s) from the next set. + Matrix of feature_identifier and cluster_identifier pairs which + encodes the cluster to which each feature_identifier was assigned. + Here for features of the current_set. - + - + - For each link/pair in current_to_next a characterization - whether the link is due to a volumetric overlap (0x00 == 0), - proximity (0x01 == 1), or something else unknown (0xFF == 255). - - - - - - - - A matrix of feature_identifier which specifies which named feature(s) - from the next set have directed link(s) pointing to which named - feature(s) from the current set. Only if the mapping whereby the - links is symmetric next_to_current maps the links in current_to_next - in the opposite direction. + Matrix of feature_identifier and cluster_identifier pairs which + encodes the cluster to which each feature_identifier was assigned. + Here for features of the next_set. - + - + - For each link/pair in next_to_current a characterization - whether the link is due to a volumetric overlap (0x00 == 0), - proximity (0x01 == 1), or something else unknown (0xFF == 255). + The identifier (names) of the cluster. - + - + - For each pair of links in current_to_next the volume of the - intersection, i.e. how much volume do the two features share. - If features do not intersect the volume is zero. + Pivot table as a matrix. + The first column encodes how many members from the current_set + are in each cluster, one row per cluster. + + The second column encodes how many members from the next_set + are in each cluster, in the same row per cluster respectively. + + The third column encodes the total number of members in the cluster. - - + + + - + - During coprecipitation analysis the current and next set are analyzed - for links in a special way. Three set comparisons are made. Members - of the set in each comparison are analyzed for overlap and proximity: + Pivot table as a matrix. - The first comparison is the current_set against the current_set. - The second comparison is the next_set against the next_set. - The third comparison is the current_set against the next_set. + The first column encodes the different types of + clusters based on their number of members in the sub-graph. - Once the (forward) links for these comparisons are ready the - pair relations are analyzed with respect to which feature identifier - cluster in identifier space. Thereby a logical connection (link) is - established between the features in the current_set and next_set. - Recall that these two set typically represent different features - within an observed system for otherwise the same parameterization. - Examples include two sets of e.g. precipitates with differing - chemical composition that were characterized in the same material - volume representing a snapshot of an e.g. microstructure at the same - point in time. Researchers may have performed two analyses, one to - characterize precipitates A and another one to characterize percipitates - B. Coprecipitation analysis now logically connects these independent - characterization results to establish spatial correlations of e.g. - precipitates spatial arrangement. + The second column encodes how many clusters with + as many members exist. - - - Matrix of feature_identifier and cluster_identifier pairs which - encodes the cluster to which each feature_identifier was assigned. - Here for features of the current_set. - - - - - - - - - Matrix of feature_identifier and cluster_identifier pairs which - encodes the cluster to which each feature_identifier was assigned. - Here for features of the next_set. - - - - - - - - - The identifier (names) of the cluster. - - - - - - - - Pivot table as a matrix. The first column encodes how many - members from the current_set are in each cluster, one row per cluster. - The second column encodes how many members from the next_set are - in each cluster, in the same row per cluster respectively. - The last column encodes the total number of members in the cluster. - - - - - - - - - Pivot table as a matrix. The first column encodes the different - types of clusters based on their number of members in the sub-graph. - The second column encodes how many clusters with as many members - exist. - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml index a20f45e5ef..e291698c56 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml @@ -320,7 +320,7 @@ The cardinality/total number of triangles in the triangle soup.--> - Standard deviation :math:`$\sigma_i$` of the kernel in each dimension + Standard deviation :math:`\sigma_i` of the kernel in each dimension in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. @@ -329,7 +329,7 @@ The cardinality/total number of triangles in the triangle soup.--> - Expectation value :math:`\mu_i$` of the kernel in each dimension + Expectation value :math:`\mu_i` of the kernel in each dimension in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. @@ -339,7 +339,7 @@ The cardinality/total number of triangles in the triangle soup.--> - The result of the delocalization :math:`$\Phi = f(x, y, z)$` based on which subsequent iso-surfaces + The result of the delocalization :math:`\Phi = f(x, y, z)` based on which subsequent iso-surfaces will be computed. In commercial software so far there is no possibility to export this information. If the intensity for all matches of the weighting_model are summarized name this NXdata instance @@ -351,12 +351,12 @@ The cardinality/total number of triangles in the triangle soup.--> In this case name the individual NXdata instances scalar_field_magn_ionID using the ID of the ion as per the configuration of the ranging definitions used. - + The actual delocalized intensity values. @@ -421,15 +421,15 @@ The cardinality/total number of triangles in the triangle soup.--> - The three-dimensional gradient :math:`$\nabla \Phi$`. + The three-dimensional gradient :math:`\nabla \Phi`. Follow the naming convention of scalar_field_magn_SUFFIX to report parallel structures. - + The actual point-wise component values. @@ -499,7 +499,7 @@ The cardinality/total number of triangles in the triangle soup.--> An iso-surface is the boundary between two regions across which the magnitude of a - scalar field falls below/exceeds a threshold magnitude :math:`$\varphi$`. + scalar field falls below/exceeds a threshold magnitude :math:`\varphi`. For applications in atom probe microscopy, the location and shape of such a boundary (set) is typically approximated by discretization - triangulation to be specific. @@ -510,7 +510,7 @@ The cardinality/total number of triangles in the triangle soup.--> - The threshold or iso-contour value :math:`$\varphi`. + The threshold or iso-contour value :math:`\varphi`. @@ -1010,7 +1010,7 @@ face_identifier_offset(NX_UINT):--> - The four parameter :math:`$ax + by + cz + d = 0$` which define the plane. + The four parameter :math:`ax + by + cz + d = 0` which define the plane. @@ -1240,7 +1240,7 @@ face_identifier_offset(NX_UINT):--> - Hashvalue using the following hashing rule :math:`$H = Z + 256 * N$`. + Hashvalue using the following hashing rule :math:`H = Z + 256 * N`. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml index 60871e6e99..5d5e479cfa 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml @@ -80,7 +80,7 @@ NXapm_paraprobe_intersector_config(NXobject): The meshes were generated as a result of some other meshing process. set_identifier(NX_UINT): doc: | - This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`$k$`) + This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`k`) step when the current set was taken (see `M. Kühbach et al. 2022 `_). unit: NX_ANY # number_of_objects(NX_UINT) for now a support field to tell the tool how many objects to load. @@ -130,7 +130,7 @@ NXapm_paraprobe_intersector_config(NXobject): The meshes were generated as a result of some other meshing process. set_identifier(NX_UINT): doc: | - This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`$k+1$`) + This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`k + 1`) step when the current set was taken (see `M. Kühbach et al. 2022 `_). unit: NX_ANY # number_of_objects(NX_UINT) for now a support field to tell the tool how many objects to load. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml index 207f3a9fff..e94b565274 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml @@ -1,6 +1,8 @@ category: application doc: | - Results of a paraprobe-intersector tool run. + Application definition for results files of the paraprobe-intersector tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -15,722 +17,164 @@ symbols: n_cluster: | The total number of cluster found for coprecipitation analysis. n_total: | - The number of rows in the table/matrix for coprecipitation stats. + The number of rows in the table/matrix for coprecipitation statistics. type: group NXapm_paraprobe_intersector_results(NXobject): (NXentry): - - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently - \@version: + exists: [min, 1, max, 1] + definition(NX_CHAR): + \@version(NX_CHAR): + enumeration: [NXapm_paraprobe_intersector_results] + # tasks + v_v_spatial_correlation(NXapm_paraprobe_tool_results): + exists: [min, 0, max, 1] doc: | - Version specifier of this application definition. - - ##MK::begin of the tool-specific section - definition: - doc: | - Official NeXus NXDL schema with which this file was written. - enumeration: [NXapm_paraprobe_results_intersector] - - ##MK::end of the tool-specific section - program: - doc: | - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - \@version: + The results of an overlap/intersection analysis. + analysis_identifier(NX_UINT): + config(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + # results + current_to_next_link(NX_UINT): doc: | - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - analysis_identifier: - doc: | - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - analysis_description: - exists: optional - doc: | - Possibility for leaving a free-text description about this analysis. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - config_filename: - doc: | - The absolute path and name of the config file for this analysis. - \@version: + A matrix of feature_identifier that specifies which named features + from the current_set have directed link(s) pointing to which named + feature(s) from the next_set. + unit: NX_UNITLESS + dim: (n_c2n, 2) + current_to_next_link_type(NX_UINT): doc: | - At least SHA256 strong hash of the specific config_file for - tracking provenance. - results_path: - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - (NXuser): - exists: recommended - doc: | - If used, contact information and eventually details - of at least the person who performed this analysis. - name: - affiliation: - exists: recommended - address: + For each link/pair in current_to_next a characterization whether the + link is due to volumetric overlap (0x00 == 0), proximity (0x01 == 1), + or something else unknown (0xFF == 255). + unit: NX_UNITLESS + dim: (n_c2n,) + next_to_current_link(NX_UINT): exists: optional - email: - exists: recommended - orcid: - exists: recommended - orcid_platform: - exists: recommended - telephone_number: + unit: NX_UNITLESS + doc: | + A matrix of feature_identifier which specifies which named feature(s) + from the next_set have directed link(s) pointing to which named + feature(s) from the current_set. Only if the mapping whereby the + links are defined is symmetric it holds that next_to_current maps + the links for current_to_next in just the opposite direction. + dim: (n_n2c, 2) + next_to_current_link_type(NX_UINT): exists: optional - role: - exists: recommended - social_media_name: + doc: | + For each link/pair in next_to_current a characterization whether the + link is due to a volumetric overlap (0x00 == 0), proximity (0x01 == 1), + or something else unknown (0xFF == 255). + unit: NX_UNITLESS + dim: (n_n2c,) + intersection_volume(NX_FLOAT): exists: optional - social_media_platform: + doc: | + For each pair of links in current_to_next the volume of the + intersection, i.e. how much volume do the two features share. + If features do not intersect the volume is zero. + unit: NX_VOLUME + dim: (n_c2n,) + coprecipitation_analysis(NXprocess): exists: optional - (NXcoordinate_system_set): - exists: optional - doc: | - Details about the coordinate system conventions used. - (NXtransformations): - exists: ['min', '1', 'max', 'unbounded'] doc: | - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: + During coprecipitation analysis the current and next set are analyzed + for links in a special way. Three set comparisons are made. Members + of the set in each comparison are analyzed for overlap and proximity: - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - ##MK::begin of the tool-specific section - (NXprocess): - VOLUME_VOLUME_SPATIAL_CORRELATION(NXprocess): - exists: ['min', '0', 'max', '1'] - doc: | - The results of an overlap/intersection analysis. - current_to_next_link(NX_UINT): - unit: NX_UNITLESS + The first comparison is the current_set against the current_set. + The second comparison is the next_set against the next_set. + The third comparison is the current_set against the next_set. + + Once the (forward) links for these comparisons are ready, pair relations + are analyzed with respect to which objects with feature_identifier(s) + cluster in identifier space. Thereby, a logical connection (link) is + established between the features in the current_set and the next_set. + Recall that these two sets typically represent different features + within an observed system for otherwise the same parameterization. + + Examples include two sets of e.g. precipitates with differing + chemical composition that were characterized in the same material + volume representing a snapshot of an e.g. microstructure at the same + point in time. Researchers may have performed two analyses, one to + characterize precipitates A and another one for percipitates B. + + Coprecipitation analysis now logically connects these independent + characterization results to establish spatial correlations of e.g. + the precipitates' spatial arrangement. + current_set_feature_to_cluster(NX_UINT): doc: | - A matrix of feature_identifier which specifies which named features - from the current set have directed link(s) pointing to which named - feature(s) from the next set. - dimensions: - rank: 2 - dim: [[1, n_c2n], [2, 2]] - current_to_next_link_type(NX_UINT): + Matrix of feature_identifier and cluster_identifier pairs which + encodes the cluster to which each feature_identifier was assigned. + Here for features of the current_set. unit: NX_UNITLESS + dim: (n_features_curr, 2) + next_set_feature_to_cluster(NX_UINT): doc: | - For each link/pair in current_to_next a characterization - whether the link is due to a volumetric overlap (0x00 == 0), - proximity (0x01 == 1), or something else unknown (0xFF == 255). - dimensions: - rank: 1 - dim: [[1, n_c2n]] - next_to_current_link(NX_UINT): - exists: optional + Matrix of feature_identifier and cluster_identifier pairs which + encodes the cluster to which each feature_identifier was assigned. + Here for features of the next_set. unit: NX_UNITLESS + dim: (n_features_next, 2) + cluster_identifier(NX_UINT): doc: | - A matrix of feature_identifier which specifies which named feature(s) - from the next set have directed link(s) pointing to which named - feature(s) from the current set. Only if the mapping whereby the - links is symmetric next_to_current maps the links in current_to_next - in the opposite direction. - dimensions: - rank: 2 - dim: [[1, n2c], [2, 2]] - next_to_current_link_type(NX_UINT): - exists: optional + The identifier (names) of the cluster. unit: NX_UNITLESS + dim: (n_cluster,) + cluster_composition(NX_UINT): doc: | - For each link/pair in next_to_current a characterization - whether the link is due to a volumetric overlap (0x00 == 0), - proximity (0x01 == 1), or something else unknown (0xFF == 255). - dimensions: - rank: 1 - dim: [[1, n_n2c]] - intersection_volume(NX_FLOAT): - exists: optional - unit: NX_VOLUME - doc: | - For each pair of links in current_to_next the volume of the - intersection, i.e. how much volume do the two features share. - If features do not intersect the volume is zero. - dimensions: - rank: 1 - dim: [[1, c2n]] - coprecipitation_analysis(NXprocess): - exists: optional - doc: | - During coprecipitation analysis the current and next set are analyzed - for links in a special way. Three set comparisons are made. Members - of the set in each comparison are analyzed for overlap and proximity: + Pivot table as a matrix. + The first column encodes how many members from the current_set + are in each cluster, one row per cluster. - The first comparison is the current_set against the current_set. - The second comparison is the next_set against the next_set. - The third comparison is the current_set against the next_set. + The second column encodes how many members from the next_set + are in each cluster, in the same row per cluster respectively. - Once the (forward) links for these comparisons are ready the - pair relations are analyzed with respect to which feature identifier - cluster in identifier space. Thereby a logical connection (link) is - established between the features in the current_set and next_set. - Recall that these two set typically represent different features - within an observed system for otherwise the same parameterization. - Examples include two sets of e.g. precipitates with differing - chemical composition that were characterized in the same material - volume representing a snapshot of an e.g. microstructure at the same - point in time. Researchers may have performed two analyses, one to - characterize precipitates A and another one to characterize percipitates - B. Coprecipitation analysis now logically connects these independent - characterization results to establish spatial correlations of e.g. - precipitates spatial arrangement. - current_set_feature_to_cluster(NX_UINT): - unit: NX_UNITLESS - doc: | - Matrix of feature_identifier and cluster_identifier pairs which - encodes the cluster to which each feature_identifier was assigned. - Here for features of the current_set. - dimensions: - rank: 2 - dim: [[1, n_features_curr], [2, 2]] - next_set_feature_to_cluster(NX_UINT): - unit: NX_UNITLESS - doc: | - Matrix of feature_identifier and cluster_identifier pairs which - encodes the cluster to which each feature_identifier was assigned. - Here for features of the next_set. - dimensions: - rank: 2 - dim: [[1, n_features_next], [2, 2]] - cluster_identifier(NX_UINT): - unit: NX_UNITLESS - doc: | - The identifier (names) of the cluster. - dimensions: - rank: 1 - dim: [[1, n_cluster]] - cluster_composition(NX_UINT): - unit: NX_UNITLESS - doc: | - Pivot table as a matrix. The first column encodes how many - members from the current_set are in each cluster, one row per cluster. - The second column encodes how many members from the next_set are - in each cluster, in the same row per cluster respectively. - The last column encodes the total number of members in the cluster. - dimensions: - rank: 2 - dim: [[1, n_cluster], [2, 3]] - cluster_statistics(NX_UINT): - unit: NX_UNITLESS - doc: | - Pivot table as a matrix. The first column encodes the different - types of clusters based on their number of members in the sub-graph. - The second column encodes how many clusters with as many members - exist. - dimensions: - rank: 2 - dim: [[1, n_total], [2, 2]] - - ##MK::add results from NXapm_paraprobe_results_clusterer - - ##MK::end of the tool-specific section - performance(NXcs_profiling): - exists: recommended - current_working_directory: - command_line_call: - exists: optional - start_time(NX_DATE_TIME): - exists: recommended - end_time(NX_DATE_TIME): - exists: recommended - total_elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - (NXcs_computer): - exists: recommended - name: - exists: recommended - operating_system: - \@version: - uuid: - exists: optional - (NXcs_cpu): - exists: ['min', '0', 'max', 'unbounded'] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_gpu): - exists: ['min', '0', 'max', 'unbounded'] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_mm_sys): - exists: ['min', '0', 'max', '1'] - total_physical_memory(NX_NUMBER): - (NXcs_io_sys): - exists: ['min', '0', 'max', '1'] - (NXcs_io_obj): - exists: ['min', '1', 'max', 'unbounded'] - technology: - max_physical_capacity(NX_NUMBER): - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_profiling_event): - start_time(NX_DATE_TIME): - exists: optional - end_time(NX_DATE_TIME): - exists: optional - description: - elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - number_of_threads(NX_POSINT): + The third column encodes the total number of members in the cluster. + unit: NX_UNITLESS + dim: (n_cluster, 3) + cluster_statistics(NX_UINT): + doc: | + Pivot table as a matrix. - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - number_of_gpus(NX_POSINT): + The first column encodes the different types of + clusters based on their number of members in the sub-graph. - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - max_virtual_memory_snapshot(NX_NUMBER): - exists: recommended - max_resident_memory_snapshot(NX_NUMBER): - exists: recommended - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d2a7c5a6492bf8b6d6196f0b993c4ecefd16301afc3d9924fd1614c05671488d -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# The total number of links pointing from current to next. -# -# -# -# -# The total number of links pointing from next to current. -# -# -# -# -# The total number of members in the current_set. -# -# -# -# -# The total number of members in the next_set. -# -# -# -# -# The total number of cluster found for coprecipitation analysis. -# -# -# -# -# The number of rows in the table/matrix for coprecipitation stats. -# -# -# -# -# Results of a paraprobe-intersector tool run. -# -# -# -# -# -# Version specifier of this application definition. -# -# -# -# -# -# Official NeXus NXDL schema with which this file was written. -# -# -# -# -# -# -# -# -# Given name of the program/software/tool with which this NeXus -# (configuration) file was generated. -# -# -# -# Ideally program version plus build number, or commit hash or description -# of ever persistent resources where the source code of the program and -# build instructions can be found so that the program can be configured -# ideally in such a manner that the result of this computational process -# is recreatable in the same deterministic manner. -# -# -# -# -# -# Ideally, a (globally persistent) unique identifier for referring -# to this analysis. -# -# -# -# -# Possibility for leaving a free-text description about this analysis. -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when the analysis behind this results file -# was started, i.e. the paraprobe-tool executable started as a process. -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when the analysis behind this results file -# were completed and the paraprobe-tool executable exited as a process. -# -# -# -# -# The absolute path and name of the config file for this analysis. -# -# -# -# At least SHA256 strong hash of the specific config_file for -# tracking provenance. -# -# -# -# -# -# Path to the directory where the tool should store NeXus/HDF5 results -# of this analysis. If not specified results will be stored in the -# current working directory. -# -# -# -# -# If used, contact information and eventually details -# of at least the person who performed this analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Details about the coordinate system conventions used. -# -# -# -# The individual coordinate systems which should be used. -# Field names should be prefixed with the following controlled terms -# indicating which individual coordinate system is described: -# -# * paraprobe -# * lab -# * specimen -# * laser -# * leap -# * detector -# * recon -# -# -# -# -# -# -# -# The results of an overlap/intersection analysis. -# -# -# -# A matrix of feature_identifier which specifies which named features -# from the current set have directed link(s) pointing to which named -# feature(s) from the next set. -# -# -# -# -# -# -# -# -# For each link/pair in current_to_next a characterization -# whether the link is due to a volumetric overlap (0x00 == 0), -# proximity (0x01 == 1), or something else unknown (0xFF == 255). -# -# -# -# -# -# -# -# A matrix of feature_identifier which specifies which named feature(s) -# from the next set have directed link(s) pointing to which named -# feature(s) from the current set. Only if the mapping whereby the -# links is symmetric next_to_current maps the links in current_to_next -# in the opposite direction. -# -# -# -# -# -# -# -# -# For each link/pair in next_to_current a characterization -# whether the link is due to a volumetric overlap (0x00 == 0), -# proximity (0x01 == 1), or something else unknown (0xFF == 255). -# -# -# -# -# -# -# -# For each pair of links in current_to_next the volume of the -# intersection, i.e. how much volume do the two features share. -# If features do not intersect the volume is zero. -# -# -# -# -# -# -# -# During coprecipitation analysis the current and next set are analyzed -# for links in a special way. Three set comparisons are made. Members -# of the set in each comparison are analyzed for overlap and proximity: -# -# The first comparison is the current_set against the current_set. -# The second comparison is the next_set against the next_set. -# The third comparison is the current_set against the next_set. -# -# Once the (forward) links for these comparisons are ready the -# pair relations are analyzed with respect to which feature identifier -# cluster in identifier space. Thereby a logical connection (link) is -# established between the features in the current_set and next_set. -# Recall that these two set typically represent different features -# within an observed system for otherwise the same parameterization. -# Examples include two sets of e.g. precipitates with differing -# chemical composition that were characterized in the same material -# volume representing a snapshot of an e.g. microstructure at the same -# point in time. Researchers may have performed two analyses, one to -# characterize precipitates A and another one to characterize percipitates -# B. Coprecipitation analysis now logically connects these independent -# characterization results to establish spatial correlations of e.g. -# precipitates spatial arrangement. -# -# -# -# Matrix of feature_identifier and cluster_identifier pairs which -# encodes the cluster to which each feature_identifier was assigned. -# Here for features of the current_set. -# -# -# -# -# -# -# -# -# Matrix of feature_identifier and cluster_identifier pairs which -# encodes the cluster to which each feature_identifier was assigned. -# Here for features of the next_set. -# -# -# -# -# -# -# -# -# The identifier (names) of the cluster. -# -# -# -# -# -# -# -# Pivot table as a matrix. The first column encodes how many -# members from the current_set are in each cluster, one row per cluster. -# The second column encodes how many members from the next_set are -# in each cluster, in the same row per cluster respectively. -# The last column encodes the total number of members in the cluster. -# -# -# -# -# -# -# -# -# Pivot table as a matrix. The first column encodes the different -# types of clusters based on their number of members in the sub-graph. -# The second column encodes how many clusters with as many members -# exist. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Specify if it was different from the number_of_processes -# in the NXcs_profiling super class. -# -# -# -# -# -# Specify if it was different from the number_of_threads -# in the NXcs_profiling super class. -# -# -# -# -# -# Specify if it was different from the number_of_threads -# in the NXcs_profiling super class. -# -# -# -# -# -# -# -# -# + The second column encodes how many clusters with + as many members exist. + unit: NX_UNITLESS + dim: (n_total, 2) + # profiling + programID(NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + profiling(NXcs_profiling): + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + status(NX_CHAR): + current_working_directory(NX_CHAR): + total_elapsed_time(NX_NUMBER): + exists: optional + number_of_processes(NX_POSINT): + number_of_threads(NX_POSINT): + number_of_gpus(NX_POSINT): + # global + userID(NXuser): + exists: [min, 0, max, infty] + name(NX_CHAR): + coordinate_system_set(NXcoordinate_system_set): + paraprobe(NXcoordinate_system): + type(NX_CHAR): + handedness(NX_CHAR): + x(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + y(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + z(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml index fc58ce8ba0..6d0b1f44cf 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml @@ -203,20 +203,20 @@ NXapm_paraprobe_nanochem_results(NXobject): enumeration: [gaussian] kernel_sigma(NX_FLOAT): doc: | - Standard deviation :math:`$\sigma_i$` of the kernel in each dimension + Standard deviation :math:`\sigma_i` of the kernel in each dimension in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. unit: NX_LENGTH dim: (3,) kernel_mu(NX_FLOAT): doc: | - Expectation value :math:`\mu_i$` of the kernel in each dimension + Expectation value :math:`\mu_i` of the kernel in each dimension in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. unit: NX_LENGTH dim: (3,) scalar_field_magn_SUFFIX(NXdata): exists: [min, 0, max, infty] doc: | - The result of the delocalization :math:`$\Phi = f(x, y, z)$` based on which subsequent iso-surfaces + The result of the delocalization :math:`\Phi = f(x, y, z)` based on which subsequent iso-surfaces will be computed. In commercial software so far there is no possibility to export this information. If the intensity for all matches of the weighting_model are summarized name this NXdata instance @@ -227,12 +227,12 @@ NXapm_paraprobe_nanochem_results(NXobject): down-stream usage of the here reported values (e.g. with Python scripting). In this case name the individual NXdata instances scalar_field_magn_ionID using the ID of the ion as per the configuration of the ranging definitions used. - \@title(NX_CHAR): \@signal(NX_CHAR): \@axes(NX_CHAR): \@xpos_indices(NX_UINT): \@ypos_indices(NX_UINT): \@zpos_indices(NX_UINT): + title(NX_CHAR): intensity(NX_FLOAT): doc: | The actual delocalized intensity values. @@ -276,14 +276,14 @@ NXapm_paraprobe_nanochem_results(NXobject): scalar_field_grad_SUFFIX(NXdata): exists: [min, 0, max, infty] doc: | - The three-dimensional gradient :math:`$\nabla \Phi$`. + The three-dimensional gradient :math:`\nabla \Phi`. Follow the naming convention of scalar_field_magn_SUFFIX to report parallel structures. - \@title(NX_CHAR): \@signal(NX_CHAR): \@axes(NX_CHAR): \@xpos_indices(NX_CHAR): \@ypos_indices(NX_CHAR): \@zpos_indices(NX_CHAR): + title(NX_CHAR): intensity(NX_FLOAT): doc: | The actual point-wise component values. @@ -329,7 +329,7 @@ NXapm_paraprobe_nanochem_results(NXobject): exists: [min, 0, max, infty] doc: | An iso-surface is the boundary between two regions across which the magnitude of a - scalar field falls below/exceeds a threshold magnitude :math:`$\varphi$`. + scalar field falls below/exceeds a threshold magnitude :math:`\varphi`. For applications in atom probe microscopy, the location and shape of such a boundary (set) is typically approximated by discretization - triangulation to be specific. @@ -339,7 +339,7 @@ NXapm_paraprobe_nanochem_results(NXobject): dimensionality(NX_POSINT): isovalue(NX_NUMBER): doc: | - The threshold or iso-contour value :math:`$\varphi`. + The threshold or iso-contour value :math:`\varphi`. unit: NX_ANY marching_cubes(NXcg_marching_cubes): doc: | @@ -726,7 +726,7 @@ NXapm_paraprobe_nanochem_results(NXobject): point_normal_form(NX_FLOAT): unit: NX_LENGTH doc: | - The four parameter :math:`$ax + by + cz + d = 0$` which define the plane. + The four parameter :math:`ax + by + cz + d = 0` which define the plane. dim: (4,) mesh_stateID(NXcg_triangle_set): exists: [min, 0, max, infty] # as many as DCOM steps * 2 because one for pre and one for post @@ -904,7 +904,7 @@ NXapm_paraprobe_nanochem_results(NXobject): dim: (k,) nuclide(NX_UINT): doc: | - Hashvalue using the following hashing rule :math:`$H = Z + 256 * N$`. + Hashvalue using the following hashing rule :math:`H = Z + 256 * N`. unit: NX_UNITLESS dim: (k,) # profiling diff --git a/manual/source/apm-structure.rst b/manual/source/apm-structure.rst index 84ff91a115..581e2ec5b8 100644 --- a/manual/source/apm-structure.rst +++ b/manual/source/apm-structure.rst @@ -1,8 +1,8 @@ .. _Apm-Structure-Fairmat: -========================= -B5: Atom-probe tomography -========================= +===================== +Atom-probe tomography +===================== Atom probe tomography and related field-ion microscopy, aka atom probe microscopy (techniques) cover metrology methods with an origin in the materials science and condensed-matter physics communities. With its maturation and commercialization in the last two decades atom probe is increasingly being used for characterization of bio materials and fundamental science of field evaporation physics. diff --git a/manual/source/ellipsometry-structure.rst b/manual/source/ellipsometry-structure.rst index 223643d685..255c3c5825 100644 --- a/manual/source/ellipsometry-structure.rst +++ b/manual/source/ellipsometry-structure.rst @@ -1,8 +1,8 @@ .. _Ellipsometry-Structure-Fairmat: -======================== -B4: Optical spectroscopy -======================== +==================== +Optical spectroscopy +==================== .. index:: Ellipsometry1 diff --git a/manual/source/em-structure.rst b/manual/source/em-structure.rst index ae9fed2f74..148e513aa2 100644 --- a/manual/source/em-structure.rst +++ b/manual/source/em-structure.rst @@ -1,8 +1,8 @@ .. _Em-Structure-Fairmat: -======================= -B1: Electron microscopy -======================= +=================== +Electron microscopy +=================== Electron microscopy is a cross-cutting characterization technique of key demand and relevance within materials science, materials engineering, and bio-science/omics research communities. diff --git a/manual/source/examples/index.rst b/manual/source/examples/index.rst index dbea811c48..52407feb08 100644 --- a/manual/source/examples/index.rst +++ b/manual/source/examples/index.rst @@ -1,8 +1,8 @@ .. _Examples: -================================================ -Examples of writing and reading NeXus data files -================================================ +============================== +NeXus: Examples data files I/O +============================== .. .. image:: ../img/NeXus.png diff --git a/manual/source/mpes-structure.rst b/manual/source/mpes-structure.rst index 3b0fd8394c..20fb4f9090 100644 --- a/manual/source/mpes-structure.rst +++ b/manual/source/mpes-structure.rst @@ -1,8 +1,8 @@ .. _Mpes-Structure-Fairmat: -============================================== -B2/B3: Photoemission & core-level spectroscopy -============================================== +========================== +Photoemission spectroscopy +========================== .. index:: IntroductionMpes1 diff --git a/manual/source/transport-structure.rst b/manual/source/transport-structure.rst index d75649a1fd..80cbcc1c86 100644 --- a/manual/source/transport-structure.rst +++ b/manual/source/transport-structure.rst @@ -1,7 +1,7 @@ .. _Transport-Structure-Fairmat: =================== -Transport Phenomena +Transport phenomena =================== Work of scientists within FAIRmat how to handshake between instrument control software like EPICS and CAMELS using NeXus resulted in an application definition for exemplar temperature dependent IV curve measurements. From 92afaeecd5ac3f70e8a28263d99aedae469a8973 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Sun, 18 Feb 2024 18:45:49 +0100 Subject: [PATCH 0579/1012] Proposal to move common data nicely out, fixes on nanochem config, next step test properly --- .../NXapm_paraprobe_nanochem_config.nxdl.xml | 114 +++++++++-------- .../NXapm_paraprobe_tool_common.nxdl.xml | 118 ++++++++++++++++++ .../NXapm_paraprobe_nanochem_config.yaml | 95 +++++++------- .../nyaml/NXapm_paraprobe_tool_common.yaml | 82 ++++++++++++ 4 files changed, 303 insertions(+), 106 deletions(-) create mode 100644 contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml index c7a1681056..8f7f720dff 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml @@ -31,6 +31,16 @@ How many iontypes does the delocalization filter specify. + + + How many grid_resolutions values. + + + + + How many kernel_variance values. + + How many disjoint control points are defined. @@ -64,16 +74,19 @@ - - + Discretization and distributing of the ion point cloud on a 3D grid - to enable continuum-scale analyses. By default the tool computes a full - kernel density estimation of decomposed ions to create one discretized - field for each element. + to enable continuum-scale analyses. + + By default, the tool computes a full kernel density estimation of decomposed + ions to create one discretized field for each element. + + One delocalization task configures a parameter sweep with at least one + delocalization. The total number of runs depends on the number of + grid_resolution and kernel_variance values. For example, setting two grid_resolutions + and three kernel_variance will compute six runs. Two sets of three with the first set using + the first grid_resolutions and in sequence the kernel_variance respectively. - + - Edge length of the cubic cells used for discretizing the reconstructed dataset - on a cuboidal 3D grid (:ref:`NXcg_grid`). + Array of edge lengths of the cubic cells used for discretizing the reconstructed dataset + on a cuboidal 3D grid (:ref:`NXcg_grid`). The tool performs as many delocalization + computations as values in are specified in grid_resolutions. + + + @@ -251,9 +268,14 @@ identifier(NX_UINT):--> - Variance of the Gaussian Ansatz kernel (:math:`\sigma_x = \sigma_y = 2 \cdot - \sigma_z` holds). + Array of variance values :math:`\sigma` of the Gaussian Ansatz kernel + (:math:`\sigma_x := \sigma`, :math:`\sigma_x = \sigma_y = 2 \cdot \sigma_z`). + The tool performs as many delocalization computations as values are specified + in kernel_variance. + + + @@ -511,22 +533,11 @@ identifier(NX_UINT):--> - - - - - - - - - - - - +NEW ISSUE: here we need to specify how the meshes were smoothened--> Use a principle component analysis (PCA) to mesh a single free-standing interface patch within @@ -661,8 +672,7 @@ identifier(NX_UINT):--> - Absolute path in the HDF5 control point file pointed to by path which contains - the X, Y, Z position matrix of disjoint control points. + X, Y, Z position matrix of disjoint control points. @@ -676,10 +686,12 @@ identifier(NX_UINT):--> - + - Specify the types of those ions that decorate the interface and can thus be assumed - to serve as useful markers for locating the interface and refining the interface mesh. + Specify those nuclides which the tool should inspect iontypes for if they contain such nuclides. + If this is the case ions of such type are taken with the number of nuclides of this multiplicity found. + The atoms of these ions are assumed to serve as useful markers for locating the interface and + refining the interface mesh. @@ -688,10 +700,11 @@ identifier(NX_UINT):--> - Array of iontypes to filter. + Array of nuclide iontypes to filter. - + + @@ -738,17 +751,6 @@ identifier(NX_UINT):--> - - - - - - - - - - - @@ -934,17 +936,17 @@ NEW ISSUE: child group is required only when a field has a certain value?--> normals. - - - - - If interface_model is isosurface this filter can be used to restrict the analysis to specific - patches of an iso-surface. - - - + + + If interface_model is isosurface this filter can be used to restrict the analysis to specific + patches of an iso-surface. + + + + @@ -973,7 +975,8 @@ from normals of neighboring facets, type of weighting schemes can affect results For each ROI, how wide (radius) should the cylindrical ROI be. - + + @@ -983,6 +986,7 @@ from normals of neighboring facets, type of weighting schemes can affect results + diff --git a/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml new file mode 100644 index 0000000000..eecad3aaac --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml @@ -0,0 +1,118 @@ + + + + + + Base class documenting the information common to tools of the paraprobe-toolbox. + + The paraprobe-toolbox is a collection of open-source tools for performing + efficient analyses of point cloud data where each point can represent atoms or + (molecular) ions. A key application of the toolbox has been for research in the + field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): + + * `paraprobe-toolbox <https://www.gitlab.com/paraprobe/paraprobe-toolbox>`_ + * `M. Kühbach et al. <https://paraprobe-toolbox.readthedocs.io/en/main/>`_ + + The toolbox does not replace but complements existent software tools in this + research field. Given its capabilities of handling points as objects with + properties and enabling analyses of the spatial arrangement of and inter- + sections between geometric primitives, the software can equally be used + for analyzing data in Materials Science and Materials Engineering. + + The common section can be used as a place to store e.g. organizational + metadata and contextualization of that analysis in a research data management + system. + + + + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis in this results file was started, + i.e. when the respective executable/tool was started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis in this results file were + completed and the respective process of the tool exited. + + + + + A statement whether the tool executable managed to process the analysis + or whether this failed. Status is written to the results file after the + end_time beyond which point in time the tool must no longer compute + any further analysis results but exit. + + Only when this status message is present and its value is `success`, + one should consider the results of the tool. In all other cases it might + b that the tool has terminated prematurely or another error occurred. + + + + + + + + + Wall-clock time. + + + + + + + Details about coordinate systems (reference frames) used. In atom probe several coordinate + systems have to be distinguished. Names of instances of such :ref:`NXcoordinate_system` + should be documented explicitly and doing so by picking from the + following controlled set of names: + + * paraprobe + * lab + * specimen + * laser + * instrument + * detector + * recon + + The aim of this convention is to support users with contextualizing which reference + frame each instance (coordinate system) is. If needed, instances of :ref:`NXtransformations` + are used to detail the explicit affine transformations whereby one can convert + rpresentations between different reference frames. + Inspect :ref:`NXtransformations` for further details. + + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml index f8e5d7067b..81e8b485d8 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml @@ -8,6 +8,10 @@ symbols: The symbols used in the schema to specify e.g. dimensions of arrays. n_ityp_deloc_cand: | How many iontypes does the delocalization filter specify. + n_grid: | + How many grid_resolutions values. + n_var: | + How many kernel_variance values. n_control_pts: | How many disjoint control points are defined. n_fct_filter_cand: | @@ -23,17 +27,20 @@ NXapm_paraprobe_nanochem_config(NXobject): definition(NX_CHAR): \@version(NX_CHAR): enumeration: [NXapm_paraprobe_nanochem_config] - # number_of_tasks(NX_UINT): - # doc: | - # How many tasks should the tool execute. - # unit: NX_UNITLESS - delocalizationID(NXapm_paraprobe_tool_config): - exists: [min, 1, max, infty] + delocalization(NXapm_paraprobe_tool_config): + exists: [min, 0, max, 1] doc: | Discretization and distributing of the ion point cloud on a 3D grid - to enable continuum-scale analyses. By default the tool computes a full - kernel density estimation of decomposed ions to create one discretized - field for each element. + to enable continuum-scale analyses. + + By default, the tool computes a full kernel density estimation of decomposed + ions to create one discretized field for each element. + + One delocalization task configures a parameter sweep with at least one + delocalization. The total number of runs depends on the number of + grid_resolution and kernel_variance values. For example, setting two grid_resolutions + and three kernel_variance will compute six runs. Two sets of three with the first set using + the first grid_resolutions and in sequence the kernel_variance respectively. # Although, this uses an efficient multithreaded algorithm the computation is costly. # Therefore, it can be advantageous for users to load an already computed delocalization. # This can be achieved with the load_existent option. @@ -175,11 +182,13 @@ NXapm_paraprobe_nanochem_config(NXobject): Nuclides are identified as hashed nuclide (see :ref:`NXion`) for further details. unit: NX_UNITLESS dim: (n_ityp_deloc_cand, n_ivec_max) - grid_resolution(NX_FLOAT): + grid_resolutions(NX_FLOAT): doc: | - Edge length of the cubic cells used for discretizing the reconstructed dataset - on a cuboidal 3D grid (:ref:`NXcg_grid`). + Array of edge lengths of the cubic cells used for discretizing the reconstructed dataset + on a cuboidal 3D grid (:ref:`NXcg_grid`). The tool performs as many delocalization + computations as values in are specified in grid_resolutions. unit: NX_LENGTH + dim: (n_grid,) kernel_size(NX_UINT): doc: | Half the width of a :math:`{(2 \cdot n + 1)}^3` cubic kernel of cubic voxel @@ -188,9 +197,12 @@ NXapm_paraprobe_nanochem_config(NXobject): unit: NX_UNITLESS kernel_variance(NX_FLOAT): doc: | - Variance of the Gaussian Ansatz kernel (:math:`\sigma_x = \sigma_y = 2 \cdot - \sigma_z` holds). + Array of variance values :math:`\sigma` of the Gaussian Ansatz kernel + (:math:`\sigma_x := \sigma`, :math:`\sigma_x = \sigma_y = 2 \cdot \sigma_z`). + The tool performs as many delocalization computations as values are specified + in kernel_variance. unit: NX_LENGTH + dim: (n_var,) normalization(NX_CHAR): doc: | How should the results of the kernel-density estimation be normalized into quantities. @@ -404,17 +416,6 @@ NXapm_paraprobe_nanochem_config(NXobject): # doc: Specifies if the tool should post-process each mesh to improve the mesh quality. # mesh_smoothing(NXprocess): # NEW ISSUE: here we need to specify how the meshes were smoothened - # profiling (only stored in the first instance of spatial_statistics) - programID(NXprogram): - exists: [min, 1, max, infty] - program(NX_CHAR): - \@version(NX_CHAR): - profiling(NXcs_profiling): - exists: recommended - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - current_working_directory(NX_CHAR): - interface_meshing(NXapm_paraprobe_tool_config): exists: [min, 0, max, 1] @@ -538,25 +539,26 @@ NXapm_paraprobe_nanochem_config(NXobject): algorithm(NX_CHAR): control_points(NX_CHAR): doc: | - Absolute path in the HDF5 control point file pointed to by path which contains - the X, Y, Z position matrix of disjoint control points. + X, Y, Z position matrix of disjoint control points. method(NX_CHAR): doc: | Method used for identifying and refining the location of the interface. Currently, paraprobe-nanochem implements a PCA followed by an iterative loop of isotropic mesh refinement and DCOM step(s), paired with self-intersection detection. enumeration: [pca_plus_dcom] - decorating_iontypes_filter(NXmatch_filter): + decoration_filter(NXmatch_filter): doc: | - Specify the types of those ions that decorate the interface and can thus be assumed - to serve as useful markers for locating the interface and refining the interface mesh. + Specify those nuclides which the tool should inspect iontypes for if they contain such nuclides. + If this is the case ions of such type are taken with the number of nuclides of this multiplicity found. + The atoms of these ions are assumed to serve as useful markers for locating the interface and + refining the interface mesh. method(NX_CHAR): enumeration: [whitelist] match(NX_UINT): doc: | - Array of iontypes to filter. + Array of nuclide iontypes to filter. unit: NX_UNITLESS - dim: (n_fct_filter_cand,) + dim: (n_fct_filter_cand, n_ivec_max) number_of_iterations(NX_UINT): doc: | How many times should the DCOM and mesh refinement be applied? @@ -590,17 +592,6 @@ NXapm_paraprobe_nanochem_config(NXobject): those for the second DCOM iteration and so on and so forth. unit: NX_UNITLESS dim: (n_fct_iterations,) - # profiling (only stored in the first instance of spatial_statistics) - programID(NXprogram): - exists: [min, 1, max, infty] - program(NX_CHAR): - \@version(NX_CHAR): - profiling(NXcs_profiling): - exists: recommended - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - current_working_directory(NX_CHAR): - oned_profile(NXapm_paraprobe_tool_config): exists: [min, 0, max, 1] @@ -767,13 +758,13 @@ NXapm_paraprobe_nanochem_config(NXobject): # triangulated surface meshes are only approximations to eventually curved shape of objects # consequently, vertex and facet normals typically differ, the former are typically interpolated # from normals of neighboring facets, type of weighting schemes can affect results quantitatively - patch_identifier_filter(NXmatch_filter): - exists: optional - doc: | - If interface_model is isosurface this filter can be used to restrict the analysis to specific - patches of an iso-surface. - method(NX_CHAR): - match(NX_NUMBER): + patch_filter(NXmatch_filter): + exists: optional + doc: | + If interface_model is isosurface this filter can be used to restrict the analysis to specific + patches of an iso-surface. + method(NX_CHAR): + match(NX_NUMBER): distancing_model(NX_CHAR): doc: | Which type of distance should be reported for the profile. @@ -790,7 +781,8 @@ NXapm_paraprobe_nanochem_config(NXobject): doc: | For each ROI, how wide (radius) should the cylindrical ROI be. unit: NX_LENGTH - # profiling (only stored in the first instance of spatial_statistics) + + summary(NXapm_paraprobe_tool_common): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): @@ -800,3 +792,4 @@ NXapm_paraprobe_nanochem_config(NXobject): start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): current_working_directory(NX_CHAR): + total_elapsed_time(NX_FLOAT): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml new file mode 100644 index 0000000000..63a410db07 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml @@ -0,0 +1,82 @@ +category: base +doc: | + Base class documenting the information common to tools of the paraprobe-toolbox. + + The paraprobe-toolbox is a collection of open-source tools for performing + efficient analyses of point cloud data where each point can represent atoms or + (molecular) ions. A key application of the toolbox has been for research in the + field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): + + * `paraprobe-toolbox `_ + * `M. Kühbach et al. `_ + + The toolbox does not replace but complements existent software tools in this + research field. Given its capabilities of handling points as objects with + properties and enabling analyses of the spatial arrangement of and inter- + sections between geometric primitives, the software can equally be used + for analyzing data in Materials Science and Materials Engineering. + + The common section can be used as a place to store e.g. organizational + metadata and contextualization of that analysis in a research data management + system. +type: group +NXapm_paraprobe_tool_common(NXprocess): + # typically tool-specific section follows + # profiling section + (NXprogram): + profiling(NXcs_profiling): + # results_path(NX_CHAR): + # doc: | + # Path where the tool stores tool-specific results. If not specified, + # results will be stored in the current working directory. + start_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis in this results file was started, + i.e. when the respective executable/tool was started as a process. + end_time(NX_DATE_TIME): + doc: | + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis in this results file were + completed and the respective process of the tool exited. + status(NX_CHAR): + doc: | + A statement whether the tool executable managed to process the analysis + or whether this failed. Status is written to the results file after the + end_time beyond which point in time the tool must no longer compute + any further analysis results but exit. + + Only when this status message is present and its value is `success`, + one should consider the results of the tool. In all other cases it might + b that the tool has terminated prematurely or another error occurred. + enumeration: [success, failure] + total_elapsed_time(NX_FLOAT): + doc: | + Wall-clock time. + unit: NX_TIME + exists: recommended + (NXuser): + (NXcoordinate_system_set): + doc: | + Details about coordinate systems (reference frames) used. In atom probe several coordinate + systems have to be distinguished. Names of instances of such :ref:`NXcoordinate_system` + should be documented explicitly and doing so by picking from the + following controlled set of names: + + * paraprobe + * lab + * specimen + * laser + * instrument + * detector + * recon + + The aim of this convention is to support users with contextualizing which reference + frame each instance (coordinate system) is. If needed, instances of :ref:`NXtransformations` + are used to detail the explicit affine transformations whereby one can convert + rpresentations between different reference frames. + Inspect :ref:`NXtransformations` for further details. + (NXcoordinate_system): + (NXtransformations): + # add further fields coming from using the charge state recovery + # workflow from the ifes_apt_tc_data_modeling library From bb6597c1c5c0761bdaf037fc72eb8f22e8f0aac8 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 19 Feb 2024 10:56:01 +0100 Subject: [PATCH 0580/1012] add drift energy to NXenergydispersion --- .../NXenergydispersion.nxdl.xml | 9 +++++++-- .../nyaml/NXenergydispersion.yaml | 19 ++++++++++++++----- 2 files changed, 21 insertions(+), 7 deletions(-) diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml index 364f0be756..7bc5f0e55e 100644 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ b/contributed_definitions/NXenergydispersion.nxdl.xml @@ -34,14 +34,19 @@ - Energy of the electrons on the mean path of the analyser. Pass energy for - hemispherics, drift energy for tofs. + Mean kinetic energy of the electrons in the energy-dispersive portion of the analyser. + This term should be used for hemispherical analysers. This concept is related to term `12.63`_ of the ISO 18115-1:2023 standard. .. _12.63: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.63 + + + Drift energy for time-of-flight energy dispersive element.s + + Center of the energy window diff --git a/contributed_definitions/nyaml/NXenergydispersion.yaml b/contributed_definitions/nyaml/NXenergydispersion.yaml index 2a6e317062..e269cdbfb3 100644 --- a/contributed_definitions/nyaml/NXenergydispersion.yaml +++ b/contributed_definitions/nyaml/NXenergydispersion.yaml @@ -12,13 +12,17 @@ NXenergydispersion(NXobject): unit: NX_ENERGY doc: - | - Energy of the electrons on the mean path of the analyser. Pass energy for - hemispherics, drift energy for tofs. + Mean kinetic energy of the electrons in the energy-dispersive portion of the analyser. + This term should be used for hemispherical analysers. - | xref: spec: ISO 18115-1:2023 term: 12.63 url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.63 + drift_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + Drift energy for time-of-flight energy dispersive element.s center_energy(NX_FLOAT): unit: NX_ENERGY doc: | @@ -133,7 +137,7 @@ NXenergydispersion(NXobject): the reference coordinate system. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e084c20fefdccbc249b32694d11fe8411402d9470fd37fb15b410d3af6fa0fd8 +# 90e9d0204c22db3fe4c9fc961a86dfea98c3356b34e4a77f777312835e4c7048 # # # + + + This is the most general application definition for multidimensional + photoelectron spectroscopy. + + Groups and fields are named according to the + `ISO 18115-1:2023`_ specification as well as the `IUPAC Recommendations 2020`_. + + .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 + + + + + + + + + + + Overall energy resolution of the MPES instrument + + This concept is related to term `10.7 ff.`_ of the ISO 18115-1:2023 standard. + + .. _10.7 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 + + This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. + + .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 + + + + + + + + + + + + + + + + + + + + + + + + + + + + Calibrated energy axis. + + This could be a link to either + /entry/process/energy_calibration/calibrated_axis or + /entry/process/energy_correction/calibrated_axis. + + + + The energy can be either stored as kinetic or as binding energy. + + + + + Calibrated kinetic energy axis. + + In case the kinetic energy axis is referenced to the Fermi level :math:`E_F` + (e.g., in entry/process/energy_referencing), kinetic energies :math:`E` are + provided as :math:`E-E_F`. + + This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. + + .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 + + + + + Calibrated binding energy axis. + + This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. + + .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + + + + + + + + + The energy can be dispersed according to different strategies. ``energy_depends`` points to + the path of a field defining the calibrated axis on which the energy axis depends. + + For example: + @energy_depends: 'entry/process/energy_calibration' + + + + + diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml new file mode 100644 index 0000000000..8a2403b185 --- /dev/null +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -0,0 +1,973 @@ +category: application +doc: | + This is the most general application definition for multidimensional + photoelectron spectroscopy. + + Groups and fields are named according to the + `ISO 18115-1:2023`_ specification as well as the `IUPAC Recommendations 2020`_. + + .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 +type: group +NXmpes(NXphotoemission): + (NXentry): + definition: + enumeration: [NXmpes] + (NXinstrument): + energy_resolution(NXresolution): + exists: optional + doc: + - | + Overall energy resolution of the MPES instrument + - | + xref: + spec: ISO 18115-1:2023 + term: 10.7 ff. + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 + - | + xref: + spec: ISO 18115-1:2023 + term: 10.24 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 + physical_quantity: + enumeration: [energy] + type: + exists: recommended + resolution(NX_FLOAT): + unit: NX_ENERGY + (NXelectronanalyser): + energy_resolution(NXresolution): + exists: recommended + type: + exists: recommended + physical_quantity: + enumeration: [energy] + resolution(NX_FLOAT): + (NXprocess): + energy_calibration(NXcalibration): + exists: recommended + data(NXdata): + energy(NX_NUMBER): + unit: NX_ENERGY + exists: optional + doc: | + Calibrated energy axis. + + This could be a link to either + /entry/process/energy_calibration/calibrated_axis or + /entry/process/energy_correction/calibrated_axis. + \@type: + type: NX_CHAR + doc: | + The energy can be either stored as kinetic or as binding energy. + enumeration: + kinetic: + doc: + - | + Calibrated kinetic energy axis. + - | + In case the kinetic energy axis is referenced to the Fermi level :math:`E_F` + (e.g., in entry/process/energy_referencing), kinetic energies :math:`E` are + provided as :math:`E-E_F`. + - | + xref: + spec: ISO 18115-1:2023 + term: 3.35 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 + binding: + doc: + - | + Calibrated binding energy axis. + - | + xref: + spec: ISO 18115-1:2023 + term: 12.16 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + \@energy_indices: + exists: optional + \@energy_depends: + type: NX_CHAR + exists: optional + doc: | + The energy can be dispersed according to different strategies. ``energy_depends`` points to + the path of a field defining the calibrated axis on which the energy axis depends. + + For example: + @energy_depends: 'entry/process/energy_calibration' + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 0858e4c498e1d031bbe35e761fdbb30b8db75d6725f7b39b320d53a90ec23587 +# +# +# +# +# +# This is the most general application definition for multidimensional +# photoelectron spectroscopy. +# +# Groups and fields are named according to the +# `ISO 18115-1:2023`_ specification as well as the `IUPAC Recommendations 2020`_. +# +# .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html +# .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 +# +# +# +# +# +# +# +# +# +# +# +# Datetime of the start of the measurement. +# Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, +# otherwise the local time zone is assumed per ISO8601. +# +# +# +# +# Datetime of the end of the measurement. +# Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, +# otherwise the local time zone is assumed per ISO8601. +# +# +# +# +# Name of the experimental method. +# +# If applicable, this name should match the terms given by `Clause 11`_ of +# the `ISO 18115-1:2023`_ specification. +# +# Examples include: +# * X-ray photoelectron spectroscopy (XPS) +# * angle-resolved X-ray photoelectron spectroscopy (ARXPS) +# * ultraviolet photoelectron spectroscopy (UPS) +# * angle-resolved photoelectron spectroscopy (ARPES) +# * hard X-ray photoemission spectroscopy (HAXPES) +# * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) +# * photoelectron emission microscopy (PEEM) +# * electron spectroscopy for chemical analysis (ESCA) +# * time-resolved angle-resolved X-ray photoelectron spectroscopy (trARPES) +# * spin-resolved angle-resolved X-ray photoelectron spectroscopy (spin-ARPES) +# * momentum microscopy +# +# .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html +# .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 +# +# +# +# +# Contact information of at least the user of the instrument or the investigator +# who performed this experiment. Adding multiple users if relevant is recommended. +# +# +# +# Name of the user. +# +# +# +# +# Name of the affiliation of the user at the time when the experiment was +# performed. +# +# +# +# +# +# Description of the MPES spectrometer and its individual parts. +# +# This concept is related to term `12.58`_ of the ISO 18115-1:2023 standard. +# +# .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 +# +# +# +# Overall energy resolution of the MPES instrument +# +# This concept is related to term `10.7 ff.`_ of the ISO 18115-1:2023 standard. +# +# .. _10.7 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 +# +# This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. +# +# .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# A source used to generate a beam. Properties refer strictly to parameters of the +# source, not of the output beam. For example, the energy of the source is not the +# optical power of the beam, but the energy of the electron beam in a synchrotron +# or similar. +# +# Note that the uppercase notation in source_TYPE means that multiple sources can +# be provided. For example, in pump-probe experiments, it is possible to have both +# a `source_probe` and a `source_pump` +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Specification of type, may also go to name. +# +# +# +# +# +# +# +# +# +# +# +# The beam emitted by this source. +# Should be named with the same appendix, e.g., +# for `source_probe` it should refer to `beam_probe`. +# Refers to the same concept as /NXentry/NXinstrument/beam_TYPE +# and may be linked. +# +# +# +# +# +# Properties of the photon beam at a given location. +# Should be named with the same appendix as source_TYPE, e.g., +# for `source_probe` it should refer to `beam_probe`. +# +# +# +# Distance between the point where the current NXbeam instance is evaluating +# the beam properties and the point where the beam interacts with the sample. +# For photoemission, the latter is the point where the the centre of the beam +# touches the sample surface. +# +# +# +# +# +# +# +# +# The source that emitted this beam. +# Should be named with the same appendix, e.g., +# for `beam_probe` it should refer to `source_probe`. +# Refers to the same concept as /NXentry/NXinstrument/source_TYPE +# and may be linked. +# Should be specified if an associated source exists. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Scheme of the electron collection column. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The size and position of the field aperture inserted in the column. To add +# additional or other apertures use the APERTURE group of NXcollectioncolumn. +# +# +# +# +# The size and position of the contrast aperture inserted in the column. To add +# additional or other apertures use the APERTURE group of NXcollectioncolumn. +# +# +# +# +# Size, position and shape of the iris inserted in the column. +# +# The iris is an aperture in the lens with a variable diameter which can reduce the number of +# electrons entering the analyzer. +# +# To add additional or other slits use the APERTURE group of NXcollectioncolumn. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Size, position and shape of the entrance slit in dispersive analyzers. +# +# To add additional or other slits use the APERTURE group of NXenergydispersion. +# +# +# +# +# Size, position and shape of the exit slit in dispersive analyzers. +# +# To add additional or other slits use the APERTURE group of NXenergydispersion. +# +# +# +# +# +# +# +# +# +# +# +# Type of electron amplifier in the first amplification step. +# +# +# +# +# +# +# +# +# Description of the detector type. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Contains the raw data collected by the detector before calibration. +# The data which is considered raw might change from experiment to experiment +# due to hardware pre-processing of the data. +# This field ideally collects the data with the lowest level of processing +# possible. +# +# The naming of fields should follow a convention to ensure compatibility. +# It is recommend to use the following field names: +# +# - **pixel_x**: Detector pixel in x direction. +# - **pixel_y**: Detector pixel in y direction. +# - **energy**: (Un)calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). +# - **kx**: (Un)calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). +# - **ky**: (Un)calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). +# - **kz**: (Un)calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). +# - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). +# Unit category: NX_ANGLE +# - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) +# Unit category: NX_ANGLE +# - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) +# Unit category: NX_LENGTH +# - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) +# Unit category: NX_LENGTH +# - **delay**: Calibrated delay time. Unit category: NX_TIME (s). +# - **polarization_angle**: Linear polarization angle of the incoming or +# outgoing beam. +# Unit category: NX_ANGLE (° or rad) +# - **ellipticity**: Ellipticity of the incoming or outgoing beam. +# Unit category: NX_ANGLE (° or rad) +# - **time_of_flight**: Total time of flight. Unit category: NX_TIME_OF_FLIGHT +# - **time_of_flight_adc**: Time-of-flight values, analog-to-digital converted. +# - **external_AXIS**: Describes an axis which is coming from outside the detectors scope. +# +# +# +# +# +# +# +# +# Raw data before calibration. +# +# +# +# +# +# +# +# Manipulator for positioning of the sample. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Device to measure the gas pressure around the sample. +# +# +# +# +# +# +# +# +# +# +# In case of a single or averaged gas pressure measurement, this is the scalar gas pressure around +# the sample. It can also be an 1D array of measured pressures (without time stamps). +# +# +# +# +# +# In the case of an experiment in which the gas pressure changes and is recorded, +# this is an array of length m of gas pressures. +# +# +# +# +# +# +# Device to bring low-energy electrons to the sample for charge neutralization +# +# +# +# +# +# +# +# +# +# +# In case of a fixed or averaged electron current, this is the scalar current. +# It can also be an 1D array of output current (without time stamps). +# +# +# +# +# +# In the case of an experiment in which the electron current is changed and +# recorded with time stamps, this is an array of length m of current setpoints. +# +# +# +# +# +# +# +# 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 +# +# +# +# Calibration event on the energy axis. +# +# For XPS, the calibration should ideally be performed according to +# `ISO 15472:2010`_ specification. +# +# .. _ISO 15472:2010: https://www.iso.org/standard/74811.html +# +# +# +# This is the calibrated energy axis to be used for data plotting. +# +# +# +# +# +# +# This is the calibrated angular axis to be used for data plotting. +# +# +# +# +# +# +# This is the calibrated spatial axis to be used for data plotting. +# +# +# +# +# +# +# This is the momentum axis to be used for data plotting. +# +# +# +# +# +# For energy referencing, the measured energies are corrected for the charging potential +# (i.e., the electrical potential of the surface region of an insulating sample, caused by +# irradiation) such that those energies correspond to a sample with no surface charge. +# Usually, the energy axis is adjusted by shifting all energies uniformally until one +# well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. +# +# This concept is related to term `12.74 ff.`_ of the ISO 18115-1:2023 standard. +# +# .. _12.74 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 +# +# +# +# Electronic core or valence level that was used for the calibration. +# +# +# +# +# Reference peak that was used for the calibration. +# +# For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge | vacuum level +# +# +# +# +# The binding energy (in units of eV) that the specified emission line appeared at, +# after adjusting the binding energy scale. +# +# This concept is related to term `12.16_ ff.`_ of the ISO 18115-1:2023 standard. +# +# .. _12.16_ ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 +# +# +# +# +# Offset between measured binding energy and calibrated binding energy of the +# emission line. +# +# +# +# +# This is the calibrated energy axis to be used for data plotting. +# +# This should link to /entry/data/energy. +# +# +# +# +# +# In the transmission correction, each intensity measurement for electrons of a given +# kinetic energy is multiplied by the corresponding value in the relative_intensity +# field of the transmission_function. This calibration procedure is used to account for +# the different tranmsission efficiencies when using different lens modes. +# +# +# +# Transmission function of the electron analyser. +# +# The transmission function (TF) specifies the detection efficiency for electrons of +# different kinetic energy passing through the electron analyser. +# This can be a link to /entry/instrument/electronanalyser/transmission_function. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Kinetic energy values +# +# +# +# +# +# +# +# Relative transmission efficiency for the given kinetic energies +# +# +# +# +# +# +# +# +# +# +# +# +# For samples containing a single pure substance. For mixtures use the +# NXsample_component_set and NXsample_component group in NXsample instead. +# +# +# +# The chemical formula of the sample (using CIF conventions). +# +# +# +# +# +# List of comma-separated elements from the periodic table +# that are contained in the sample. +# If the sample substance has multiple components, all +# elements from each component must be included in `atom_types`. +# +# +# +# +# +# +# +# +# +# +# +# +# +# A set of activities that occurred to the sample prior to/during photoemission +# experiment. +# +# +# +# Details about the sample preparation for the MPES experiment (e.g. UHV cleaving, +# in-situ growth, sputtering/annealing, etc.). +# +# +# +# +# +# Details about the method of sample preparation before the MPES experiment. +# +# +# +# +# +# +# Sample temperature (either controlled or just measured). +# +# +# +# Temperature sensor measuring the sample temperature. +# This should be a link to /entry/instrument/manipulator/temperature_sensor. +# +# +# +# +# Device to heat the sample. +# This should be a link to /entry/instrument/manipulator/sample_heater. +# +# +# +# +# Cryostat for cooling the sample. +# This should be a link to /entry/instrument/manipulator/cryostat. +# +# +# +# +# +# Gas pressure surrounding the sample. +# +# +# +# Gauge measuring the gas pressure. +# +# This should be a link to /entry/instrument/pressure_gauge. +# +# +# +# +# +# Bias of the sample with respect to analyser ground. +# +# This concept is related to term `8.41`_ of the ISO 18115-1:2023 standard. +# +# .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 +# +# +# +# Sensor measuring the applied voltage. +# +# This should be a link to /entry/instrument/manipulator/sample_bias_voltmeter. +# +# +# +# +# Actuator applying a voltage to sample and sample holder. +# +# This should be a link to /entry/instrument/manipulator/sample_bias_potentiostat. +# +# +# +# +# +# Drain current of the sample and sample holder. +# +# +# +# Amperemeter measuring the drain current of the sample and sample holder. +# +# This should be a link to /entry/instrument/manipulator/drain_current_amperemeter. +# +# +# +# +# +# Current of low-energy electrons to the sample for charge neutralization. +# +# +# +# Flood gun creating a current of low-energy electrons. +# +# This should be a link to /entry/instrument/flood_gun. +# +# +# +# +# +# +# The default NXdata field containing a view on the measured data. +# This NXdata field contains a collection of the main relevant fields (axes). +# In NXmpes, it is required to provide an energy axis. +# If you want to provide additional views on your data, you can additionally use +# the generic NXdata group of NXentry. +# The other data fields inside this NXdata group should be named according to conventions +# to ensure compatibility. We recommened the following field names +# for common data fields: +# +# - **kx**: Calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). +# - **ky**: Calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). +# - **kz**: Calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). +# - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). +# Unit category: NX_ANGLE +# - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) +# Unit category: NX_ANGLE +# - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) +# Unit category: NX_LENGTH +# - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) +# Unit category: NX_LENGTH +# - **delay**: Calibrated delay time. Unit category: NX_TIME (s). +# - **polarization_angle**: Linear polarization angle of the incoming or +# outgoing beam. This could be a link to +# /entry/instrument/beam/incident_polarization_angle or +# /entry/instrument/beam/final_polarization_angle if they exist. +# Unit category: NX_ANGLE (° or rad) +# - **ellipticity**: Ellipticity of the incoming or outgoing beam. +# Could be a link to /entry/instrument/beam/incident_ellipticity or +# /entry/instrument/beam/final_ellipticity if they exist. +# Unit category: NX_ANGLE (° or rad) +# +# +# +# +# +# +# +# +# Represents a measure of one- or more-dimensional photoemission counts, where the +# varied axis may be for example energy, momentum, spatial coordinate, pump-probe +# delay, spin index, temperature, etc. The axes traces should be linked to the +# actual encoder position in NXinstrument or calibrated axes in NXprocess. +# +# +# +# +# Calibrated energy axis. +# +# This could be a link to either +# /entry/process/energy_calibration/calibrated_axis or +# /entry/process/energy_correction/calibrated_axis. +# +# +# +# The energy can be either stored as kinetic or as binding energy. +# +# +# +# +# Calibrated kinetic energy axis. +# +# In case the kinetic energy axis is referenced to the Fermi level :math:`E_F` +# (e.g., in entry/process/energy_referencing), kinetic energies :math:`E` are +# provided as :math:`E-E_F`. +# +# This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. +# +# .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 +# +# +# +# +# Calibrated binding energy axis. +# +# This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. +# +# .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 +# +# +# +# +# +# +# +# +# The energy can be dispersed according to different strategies. ``energy_depends`` points to +# the path of a field defining the calibrated axis on which the energy axis depends. +# +# For example: +# @energy_depends: 'entry/process/energy_calibration' +# +# +# +# +# From 33da7e4180b2692d1c9fc4f75d43b02d944feae0 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 19 Feb 2024 11:38:36 +0100 Subject: [PATCH 0585/1012] rename NXcalibration/software to calibration_software --- contributed_definitions/NXcalibration.nxdl.xml | 2 +- contributed_definitions/nyaml/NXcalibration.yaml | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml index bf1842456a..77b8186b0b 100644 --- a/contributed_definitions/NXcalibration.nxdl.xml +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -79,7 +79,7 @@ Has the calibration been applied? - + Name of the software used for this calibration. diff --git a/contributed_definitions/nyaml/NXcalibration.yaml b/contributed_definitions/nyaml/NXcalibration.yaml index 2174e3ee69..ac00588310 100644 --- a/contributed_definitions/nyaml/NXcalibration.yaml +++ b/contributed_definitions/nyaml/NXcalibration.yaml @@ -37,7 +37,7 @@ NXcalibration(NXobject): applied(NX_BOOLEAN): doc: | Has the calibration been applied? - software: + calibration_software: doc: | Name of the software used for this calibration. \@version: @@ -134,7 +134,7 @@ NXcalibration(NXobject): NXdata groups can be used for multidimensional data which are relevant to the calibration # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 276fe9e8157091d2d8094d3c29b3c64125f9893c2ee5a7109ab31ffebc2ec30f +# ac193af828f60af2f3aef31be942edbeb1cca6109451fe130086c56aa74e939d # # # Total time of flight - - Time-of-flight values, analog-to-digital converted. - - (Un)calibrated delay time. - - Linear polarization angle of the incoming or outgoing beam. - - Ellipticity of the incoming or outgoing beam. - - Describes an axis which is coming from outside the detectors scope. diff --git a/contributed_definitions/nyaml/NXdata_photoemission.yaml b/contributed_definitions/nyaml/NXdata_photoemission.yaml index f08fd2446a..4d0992e409 100644 --- a/contributed_definitions/nyaml/NXdata_photoemission.yaml +++ b/contributed_definitions/nyaml/NXdata_photoemission.yaml @@ -462,24 +462,28 @@ NXdata_photoemission(NXdata): doc: | Calibrated z axis in k-space. Units are 1/Angström. - angular0(NX_NUMBER): + angularN(NX_NUMBER): unit: NX_ANGLE doc: | - Fast-axis angular coordinate (or second slow axis if angularly integrated). - angular1(NX_NUMBER): + One calibrated angular coordinate. It is envisioned that the axes are name angular0, angular1, etc., + in accordance with the calibrations defined in NXprocess_photoemission. + + The angular axes should be named in order of decreasing speed, i.e., angular0 should be + the fastest scan axis and angular1 should be the slow-axis angular coordinate. However, + angular0 may also be second slow axis if the measurement is angularly integrated and angular1 + could also be the second fast axis in the case of simultaneous dispersion in two angular + dimensions. + spatialN(NX_NUMBER): unit: NX_ANGLE doc: | - Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in - 2 dimensions) - spatial0(NX_NUMBER): - unit: NX_LENGTH - doc: | - Fast-axis spatial coordinate (or second slow axis if spatially integrated) - spatial1(NX_NUMBER): - unit: NX_LENGTH - doc: | - Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in - 2 dimensions) + One calibrated spatial coordinate. It is envisioned that the axes are name spatial0, spatial1, etc., + in accordance with the calibrations defined in NXprocess_photoemission. + + The spatial axes should be named in order of decreasing speed, i.e., spatial0 should be + the fastest scan axis and spatial1 should be the slow-axis spatial coordinate. However, + spatial0 may also be second slow axis if the measurement is spatially integrated and spatial1 + could also be the second fast axis in the case of simultaneous dispersion in two spatial + dimensions. delay(NX_NUMBER): unit: NX_TIME doc: | @@ -503,7 +507,7 @@ NXdata_photoemission(NXdata): /entry/instrument/beam/final_ellipticity if they exist. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# cbceca788f184a9407622afe748d03baca7cb08657bc85a99740639235d667a3 +# 5faa8ab7cc448fc6785f644924b0ef86e978fc73e8acefc4b549774e13a136af # # # # # # Total time of flight # # -# -# # # # Time-of-flight values, analog-to-digital converted. # # -# -# # # # (Un)calibrated delay time. # # -# -# # # # Linear polarization angle of the incoming or outgoing beam. # # -# -# # # # Ellipticity of the incoming or outgoing beam. # # -# -# # # # Describes an axis which is coming from outside the detectors scope. From 0d61d89de33657699a79f5e60012f48e0605ea50 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 19 Feb 2024 12:27:29 +0100 Subject: [PATCH 0588/1012] change unit category of momentum axis --- .../NXdata_photoemission.nxdl.xml | 2 +- .../NXdata_photoemission_detector.nxdl.xml | 6 +++--- .../nyaml/NXdata_photoemission.yaml | 6 +++--- .../nyaml/NXdata_photoemission_detector.yaml | 14 +++++++------- 4 files changed, 14 insertions(+), 14 deletions(-) diff --git a/contributed_definitions/NXdata_photoemission.nxdl.xml b/contributed_definitions/NXdata_photoemission.nxdl.xml index 1e6e96436f..2f651c1bca 100644 --- a/contributed_definitions/NXdata_photoemission.nxdl.xml +++ b/contributed_definitions/NXdata_photoemission.nxdl.xml @@ -516,7 +516,7 @@ AXISNAME_indices documentation copied from datarules.rst - + Calibrated momentum axis. Units are kg*m/s. diff --git a/contributed_definitions/NXdata_photoemission_detector.nxdl.xml b/contributed_definitions/NXdata_photoemission_detector.nxdl.xml index a59ede2072..f911bc76d8 100644 --- a/contributed_definitions/NXdata_photoemission_detector.nxdl.xml +++ b/contributed_definitions/NXdata_photoemission_detector.nxdl.xml @@ -527,9 +527,9 @@ AXISNAME_indices documentation copied from datarules.rst - + - Calibrated momentum axis. + (Un)calibrated momentum axis. Units are kg*m/s. @@ -578,7 +578,7 @@ AXISNAME_indices documentation copied from datarules.rst - Total time of flight + Total time of flight. diff --git a/contributed_definitions/nyaml/NXdata_photoemission.yaml b/contributed_definitions/nyaml/NXdata_photoemission.yaml index 4d0992e409..5adb0d0a63 100644 --- a/contributed_definitions/nyaml/NXdata_photoemission.yaml +++ b/contributed_definitions/nyaml/NXdata_photoemission.yaml @@ -443,7 +443,7 @@ NXdata_photoemission(NXdata): term: 12.16 url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 momentum(NX_NUMBER): - unit: NX_ANY + unit: NX_WAVENUMBER doc: | Calibrated momentum axis. Units are kg*m/s. @@ -507,7 +507,7 @@ NXdata_photoemission(NXdata): /entry/instrument/beam/final_ellipticity if they exist. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 5faa8ab7cc448fc6785f644924b0ef86e978fc73e8acefc4b549774e13a136af +# 985bc40b413f4e4e3b1c76737a318e7da0b61a9b323f306fd51da4029bbf2c58 # # # # # -# Total time of flight +# Total time of flight. # # # From dd05c1b6b0eaa6da87746a8df522c842afdc8d68 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 19 Feb 2024 12:54:41 +0100 Subject: [PATCH 0589/1012] rename sample_history to history --- base_classes/NXsample.nxdl.xml | 2 +- base_classes/NXsample_component.nxdl.xml | 2 +- base_classes/nyaml/NXsample.yaml | 6 +++--- base_classes/nyaml/NXsample_component.yaml | 6 +++--- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/base_classes/NXsample.nxdl.xml b/base_classes/NXsample.nxdl.xml index dae004c539..b63b9da89f 100644 --- a/base_classes/NXsample.nxdl.xml +++ b/base_classes/NXsample.nxdl.xml @@ -530,7 +530,7 @@ eventually, this should be stored in the application definitions external electric/magnetic/mechanical fields, temperature, ... - + A set of physical processes that occurred to the sample prior/during experiment. diff --git a/base_classes/NXsample_component.nxdl.xml b/base_classes/NXsample_component.nxdl.xml index 7d1660164d..ac9b3a1275 100644 --- a/base_classes/NXsample_component.nxdl.xml +++ b/base_classes/NXsample_component.nxdl.xml @@ -212,7 +212,7 @@ Details about the sample component vendor (company or research group) - + A set of physical processes that occurred to the sample component prior/during experiment. diff --git a/base_classes/nyaml/NXsample.yaml b/base_classes/nyaml/NXsample.yaml index 1a78f7e5db..8fee2dd55d 100644 --- a/base_classes/nyaml/NXsample.yaml +++ b/base_classes/nyaml/NXsample.yaml @@ -350,7 +350,7 @@ NXsample(NXobject): These can include, among others: applied pressure, surrounding gas phase and gas pressure, external electric/magnetic/mechanical fields, temperature, ... - sample_history(NXhistory): + history(NXhistory): doc: | A set of physical processes that occurred to the sample prior/during experiment. \@default: @@ -380,7 +380,7 @@ NXsample(NXobject): other component groups. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 6ebe9386d0a20481d720b753f7d1569df47f8f31306b444975540d3cae411797 +# 9f195b79b2f9b0070e0f571f5b9c5e66898d88630806c4eb1a17de61c9542451 # # # - Rotation about the analyzer axis. This needs to be defined in the transformation - chain. + Rotation about the analyzer lens axis. Its zero reference is defined such that + the angular0 axis is increasing towards the positive y axis (analyzer slit + vertical). + + + + + + + + + + + + + Path to a transformation that places the analyzer origin system into the + arpes_geometry coordinate system. + + @@ -92,12 +127,42 @@ with higher granularity in the data description. deflectors, or as one angle in a TOF detector. If a resolved angle, place the calibrated axis coordinates here. + + + + + + + + + + + + + + + In-plane analyzer coordinate along a dispersive direction, e.g. along an analyzer slit. If a resolved angle, place the calibrated coordinates here. + + + + + + + + + + + + + + + @@ -106,27 +171,19 @@ with higher granularity in the data description. Scheme of the electron collection column. - - - + + + - - - - - - - - @@ -146,39 +203,17 @@ with higher granularity in the data description. Describe the appropriate axis calibrations for your experiment using one or more of the following NXcalibrations - - - - Has an energy calibration been applied? - - + This is the calibrated energy axis to be used for data plotting. - - - - Has an angular calibration been applied to dispersive axis 1? - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - - Has an angular calibration been applied to dispersive axis 2? - - + - This is the calibrated angular axis to be used for data plotting. + This is the Nth calibrated angular axis to be used for data plotting. @@ -189,18 +224,78 @@ with higher granularity in the data description. - - Reference to a transformation describing the orientation of the sample relative - to the beam coordinate system (.). + Reference to a transformation describing the orientation of the sample within + the arpes_geometry coordinate system. - + Set of transformations, describing the relative orientation of the sample with - respect to the beam coordinate system (.). + respect to the arpes_geometry coordinate system. + + + Rotation about the y axis (typically the long manipulator axis). + + + + + + + + + + + + + + Path to a transformation that places the sample surface into the origin of the + arpes_geometry coordinate system. + + + + + + Rotation about the x axis (typically a manipulator tilt). + + + + + + + + + + + + + + + + + + + + Rotation about the z axis (azimuthal rotation within the sample plane). + + + + + + + + + + + + + + + + + @@ -220,11 +315,11 @@ with higher granularity in the data description. Points to the path to a field defining the axis on which the angular axis - depends. For example: @angular1_depends: '/entry/sample/transformations/rot_phi' - for a manipulator angular scan @angular1_depends: - '/entry/instrument/detector/sensor_x' for a 2D detector @angular1_depends: - '/entry/instrument/collectioncolumn/deflector' for a deflector scan - @angular1_depends: + depends. For example: @angular1_depends: + '/entry/sample/transformations/sample_tilt' for a manipulator angular scan + @angular1_depends: '/entry/instrument/detector/sensor_x' for a 2D detector + @angular1_depends: '/entry/instrument/collectioncolumn/deflector' for a + deflector scan @angular1_depends: '/entry/process/calibration/angular1_calibration/calibrated_axis' for a preprocessed axis. @@ -232,11 +327,11 @@ with higher granularity in the data description. Points to the path to a field defining the axis on which the angular axis - depends. For example: @angular2_depends: '/entry/sample/transformations/rot_tht' - for a manipulator angular scan @angular2_depends: - '/entry/instrument/detector/sensor_x' for a 2D detector @angular2_depends: - '/entry/instrument/collectioncolumn/deflector' for a deflector scan - @angular2_depends: + depends. For example: @angular2_depends: + '/entry/sample/transformations/sample_polar' for a manipulator angular scan + @angular2_depends: '/entry/instrument/detector/sensor_x' for a 2D detector + @angular2_depends: '/entry/instrument/collectioncolumn/deflector' for a + deflector scan @angular2_depends: '/entry/process/calibration/angular2_calibration/calibrated_axis' for a preprocessed axis. diff --git a/contributed_definitions/nyaml/NXmpes_arpes.yaml b/contributed_definitions/nyaml/NXmpes_arpes.yaml index bfafa77520..0953b2f190 100644 --- a/contributed_definitions/nyaml/NXmpes_arpes.yaml +++ b/contributed_definitions/nyaml/NXmpes_arpes.yaml @@ -12,53 +12,82 @@ NXmpes_arpes(NXmpes): definition: \@version: enumeration: ["NXmpes_arpes"] - geometries(NXcollection): - arpesgeometry(NXcollection): + geometries(NXcoordinate_system_set): + arpes_geometry(NXcoordinate_system): depends_on(NX_CHAR): doc: "Link to transformations defining an APRES base coordinate system, which is defined such that the positive z-axis points towards the analyzer entry, and the x-axis lies within the beam/analyzer plane." (NXtransformations): doc: "Set of transformations, describing the orientation of the ARPES coordinate system with respect to the beam coordinate system (.)." (NXinstrument): - angular_resolution(NX_FLOAT): + energy_resolution(NXresolution): exists: recommended - unit: NX_ANGLE - (NXelectronanalyser): - description: - angular_resolution(NX_FLOAT): + angular_resolution(NXresolution): + exists: recommended + doc: + - | + Overall angular resolution along the Nth angular axis. Create one such entry per relevant angular axis, corresponding to the angular axes in NXdata. + For hemispherical analyzers, angular0_resolution corresponds to the direction along the analyzer slit, and angular1_resolution to the one perpendicular to it. + physical_quantity: + enumeration: [angle] + type: exists: recommended - doc: "Angular resolution of the electron analyser with the current setting. May be linked from a NXcalibration." + resolution(NX_FLOAT): unit: NX_ANGLE - depends_on(NX_CHAR): + (NXelectronanalyser): + angularN_resolution(NXresolution): exists: recommended - doc: "Reference to the transformation describing the orientation of the analyzer relative to the beam." - (NXtransformations): + doc: + - | + Analyzer angular resolution along the Nth angular axis. Create one such entry per relevant angular axis, corresponding to the angular axes in NXdata. + For hemispherical analyzers, angular0_resolution corresponds to the direction along the analyzer slit, and angular1_resolution to the one perpendicular to it. + physical_quantity: + enumeration: [angle] + type: + exists: recommended + resolution(NX_FLOAT): + unit: NX_ANGLE + depends_on(NX_CHAR): + doc: "Reference to the last transformation describing the orientation of the analyzer relative to the beam, e.g. transformations/analyzer_elevation." + transformations(NXtransformations): doc: "Set of transformations, describing the relative orientation of the analyzer with respect to the beam coordinate system (.)." - # Do we need to require the existence/use of a particular rotation to determine slit orientation? analyzer_rotation(NX_NUMBER): - doc: "Rotation about the analyzer axis. This needs to be defined in the transformation chain." + doc: "Rotation about the analyzer lens axis. Its zero reference is defined such that the angular0 axis is increasing towards the positive y axis (analyzer slit vertical)." unit: NX_ANGLE + transformation_type: + enumeration: ["rotation"] + vector: + enumeration: ["[0, 0, 1]"] + depends_on: + doc: "Path to a transformation that places the analyzer origin system into the arpes_geometry coordinate system." analyzer_elevation(NX_NUMBER): doc: "Elevation of the effective analyzer acceptance area, e.g. realized by deflectors, or as one angle in a TOF detector. If a resolved angle, place the calibrated axis coordinates here." unit: NX_ANGLE + transformation_type: + enumeration: ["rotation"] + vector: + enumeration: ["[0, 1, 0]"] + depends_on: + enumeration: ["analyzer_dispersion"] analyzer_dispersion(NX_NUMBER): doc: "In-plane analyzer coordinate along a dispersive direction, e.g. along an analyzer slit. If a resolved angle, place the calibrated coordinates here." unit: NX_ANGLE + transformation_type: + enumeration: ["rotation"] + vector: + enumeration: ["[1, 0, 0]"] + depends_on: + enumeration: ["analyzer_rotation"] (NXcollectioncolumn): scheme: exists: recommended doc: "Scheme of the electron collection column." enumeration: [ - "Standard", - "Angular dispersive", - "Deflector", + "angular dispersive", + "non-dispersive", ] - (NXenergydispersion): - scheme: + angular_acceptance(NX_FLOAT): exists: recommended - enumeration: ["hemispherical", "tof"] - center_energy(NX_NUMBER): - exists: recommended - unit: NX_ENERGY + (NXenergydispersion): diameter(NX_NUMBER): exists: recommended unit: NX_LENGTH @@ -68,7 +97,6 @@ NXmpes_arpes(NXmpes): enumeration: [ "straight slit", "curved slit", - "open", ] (NXdetector): data(NX_NUMBER): # Raw signal without calibrated axes. @@ -80,34 +108,49 @@ NXmpes_arpes(NXmpes): Describe the appropriate axis calibrations for your experiment using one or more of the following NXcalibrations" energy_calibration(NXcalibration): - exists: optional - applied(NX_BOOLEAN): - doc: "Has an energy calibration been applied?" + exists: recommended calibrated_axis(NX_FLOAT): exists: recommended doc: "This is the calibrated energy axis to be used for data plotting." - angular1_calibration(NXcalibration): - exists: optional - applied(NX_BOOLEAN): - doc: "Has an angular calibration been applied to dispersive axis 1?" - calibrated_axis(NX_FLOAT): - exists: recommended - doc: "This is the calibrated angular axis to be used for data plotting." - angular2_calibration(NXcalibration): + angularN_calibration(NXcalibration): exists: optional - applied(NX_BOOLEAN): - doc: "Has an angular calibration been applied to dispersive axis 2?" calibrated_axis(NX_FLOAT): exists: recommended - doc: "This is the calibrated angular axis to be used for data plotting." + doc: "This is the Nth calibrated angular axis to be used for data plotting." (NXsample): situation: enumeration: ["vacuum"] - # Similar situation here, ca be a single number or a log. depends_on(NX_CHAR): - doc: "Reference to a transformation describing the orientation of the sample relative to the beam coordinate system (.)." - (NXtransformations): - doc: "Set of transformations, describing the relative orientation of the sample with respect to the beam coordinate system (.)." + doc: "Reference to a transformation describing the orientation of the sample within the arpes_geometry coordinate system." + transformations(NXtransformations): + doc: "Set of transformations, describing the relative orientation of the sample with respect to the arpes_geometry coordinate system." + sample_polar(NX_NUMBER): + doc: "Rotation about the y axis (typically the long manipulator axis)." + unit: NX_ANGLE + transformation_type: + enumeration: ["rotation"] + vector: + enumeration: ["[0, 1, 0]"] + depends_on: + doc: "Path to a transformation that places the sample surface into the origin of the arpes_geometry coordinate system." + sample_tilt(NX_NUMBER): + doc: "Rotation about the x axis (typically a manipulator tilt)." + unit: NX_ANGLE + transformation_type: + enumeration: ["rotation"] + vector: + enumeration: ["[1, 0, 0]"] + depends_on: + enumeration: ["sample_polar"] + sample_azimuth(NX_NUMBER): + doc: "Rotation about the z axis (azimuthal rotation within the sample plane)." + unit: NX_ANGLE + transformation_type: + enumeration: ["rotation"] + vector: + enumeration: ["[0, 0, 1]"] + depends_on: + enumeration: ["sample_tilt"] (NXdata): \@signal: enumeration: ["data"] # There is an object named data that contains the signal @@ -119,14 +162,14 @@ NXmpes_arpes(NXmpes): \@angular1_depends(NX_CHAR): doc: "Points to the path to a field defining the axis on which the angular axis depends. For example: - @angular1_depends: '/entry/sample/transformations/rot_phi' for a manipulator angular scan + @angular1_depends: '/entry/sample/transformations/sample_tilt' for a manipulator angular scan @angular1_depends: '/entry/instrument/detector/sensor_x' for a 2D detector @angular1_depends: '/entry/instrument/collectioncolumn/deflector' for a deflector scan @angular1_depends: '/entry/process/calibration/angular1_calibration/calibrated_axis' for a preprocessed axis." \@angular2_depends(NX_CHAR): doc: "Points to the path to a field defining the axis on which the angular axis depends. For example: - @angular2_depends: '/entry/sample/transformations/rot_tht' for a manipulator angular scan + @angular2_depends: '/entry/sample/transformations/sample_polar' for a manipulator angular scan @angular2_depends: '/entry/instrument/detector/sensor_x' for a 2D detector @angular2_depends: '/entry/instrument/collectioncolumn/deflector' for a deflector scan @angular2_depends: '/entry/process/calibration/angular2_calibration/calibrated_axis' for a preprocessed axis." From a67ff1a84d0dbb6e36e208f716df352c25a5db0f Mon Sep 17 00:00:00 2001 From: rettigl Date: Wed, 21 Feb 2024 20:56:22 +0100 Subject: [PATCH 0594/1012] update definition --- contributed_definitions/NXmpes_arpes.nxdl.xml | 73 +++++++++---------- .../nyaml/NXmpes_arpes.yaml | 38 +++++----- 2 files changed, 54 insertions(+), 57 deletions(-) diff --git a/contributed_definitions/NXmpes_arpes.nxdl.xml b/contributed_definitions/NXmpes_arpes.nxdl.xml index a680ce4899..5b60770dfd 100644 --- a/contributed_definitions/NXmpes_arpes.nxdl.xml +++ b/contributed_definitions/NXmpes_arpes.nxdl.xml @@ -59,7 +59,6 @@ with higher granularity in the data description. - Overall angular resolution along the Nth angular axis. Create one such entry per relevant angular axis, corresponding to the angular axes in NXdata. @@ -104,22 +103,22 @@ with higher granularity in the data description. the angular0 axis is increasing towards the positive y axis (analyzer slit vertical). - + - - + + - - + + Path to a transformation that places the analyzer origin system into the arpes_geometry coordinate system. - + @@ -127,42 +126,42 @@ with higher granularity in the data description. deflectors, or as one angle in a TOF detector. If a resolved angle, place the calibrated axis coordinates here. - + - - + + - - + + - + In-plane analyzer coordinate along a dispersive direction, e.g. along an analyzer slit. If a resolved angle, place the calibrated coordinates here. - + - - + + - - + + - + @@ -239,62 +238,62 @@ with higher granularity in the data description. Rotation about the y axis (typically the long manipulator axis). - + - - + + - - + + Path to a transformation that places the sample surface into the origin of the arpes_geometry coordinate system. - + Rotation about the x axis (typically a manipulator tilt). - + - - + + - - + + - + Rotation about the z axis (azimuthal rotation within the sample plane). - + - - + + - - + + - + diff --git a/contributed_definitions/nyaml/NXmpes_arpes.yaml b/contributed_definitions/nyaml/NXmpes_arpes.yaml index 0953b2f190..51a9ac55f2 100644 --- a/contributed_definitions/nyaml/NXmpes_arpes.yaml +++ b/contributed_definitions/nyaml/NXmpes_arpes.yaml @@ -19,8 +19,6 @@ NXmpes_arpes(NXmpes): (NXtransformations): doc: "Set of transformations, describing the orientation of the ARPES coordinate system with respect to the beam coordinate system (.)." (NXinstrument): - energy_resolution(NXresolution): - exists: recommended angular_resolution(NXresolution): exists: recommended doc: @@ -53,29 +51,29 @@ NXmpes_arpes(NXmpes): analyzer_rotation(NX_NUMBER): doc: "Rotation about the analyzer lens axis. Its zero reference is defined such that the angular0 axis is increasing towards the positive y axis (analyzer slit vertical)." unit: NX_ANGLE - transformation_type: + \@transformation_type: enumeration: ["rotation"] - vector: + \@vector: enumeration: ["[0, 0, 1]"] - depends_on: + \@depends_on: doc: "Path to a transformation that places the analyzer origin system into the arpes_geometry coordinate system." analyzer_elevation(NX_NUMBER): doc: "Elevation of the effective analyzer acceptance area, e.g. realized by deflectors, or as one angle in a TOF detector. If a resolved angle, place the calibrated axis coordinates here." unit: NX_ANGLE - transformation_type: + \@transformation_type: enumeration: ["rotation"] - vector: + \@vector: enumeration: ["[0, 1, 0]"] - depends_on: + \@depends_on: enumeration: ["analyzer_dispersion"] analyzer_dispersion(NX_NUMBER): doc: "In-plane analyzer coordinate along a dispersive direction, e.g. along an analyzer slit. If a resolved angle, place the calibrated coordinates here." unit: NX_ANGLE - transformation_type: + \@transformation_type: enumeration: ["rotation"] - vector: + \@vector: enumeration: ["[1, 0, 0]"] - depends_on: + \@depends_on: enumeration: ["analyzer_rotation"] (NXcollectioncolumn): scheme: @@ -127,29 +125,29 @@ NXmpes_arpes(NXmpes): sample_polar(NX_NUMBER): doc: "Rotation about the y axis (typically the long manipulator axis)." unit: NX_ANGLE - transformation_type: + \@transformation_type: enumeration: ["rotation"] - vector: + \@vector: enumeration: ["[0, 1, 0]"] - depends_on: + \@depends_on: doc: "Path to a transformation that places the sample surface into the origin of the arpes_geometry coordinate system." sample_tilt(NX_NUMBER): doc: "Rotation about the x axis (typically a manipulator tilt)." unit: NX_ANGLE - transformation_type: + \@transformation_type: enumeration: ["rotation"] - vector: + \@vector: enumeration: ["[1, 0, 0]"] - depends_on: + \@depends_on: enumeration: ["sample_polar"] sample_azimuth(NX_NUMBER): doc: "Rotation about the z axis (azimuthal rotation within the sample plane)." unit: NX_ANGLE - transformation_type: + \@transformation_type: enumeration: ["rotation"] - vector: + \@vector: enumeration: ["[0, 0, 1]"] - depends_on: + \@depends_on: enumeration: ["sample_tilt"] (NXdata): \@signal: From 70ac95f69e14deff57605b7261bcb72658926e2a Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Mon, 26 Feb 2024 12:12:17 +0100 Subject: [PATCH 0595/1012] Moved profiling and other common information out of task specific groups as this was cumbersome to use. This essentially concludes the refactoring for appdefs for the paraprobe-toolbox, the remaining fixes can be implemented via bugfix PR to enable merging these definitions now from the too long v2 refactoring branches --- .../NXapm_paraprobe_clusterer_config.nxdl.xml | 19 ++-- ...NXapm_paraprobe_clusterer_results.nxdl.xml | 61 +++++++------ .../NXapm_paraprobe_distancer_config.nxdl.xml | 6 +- ...NXapm_paraprobe_distancer_results.nxdl.xml | 59 ++++++------ ...Xapm_paraprobe_intersector_config.nxdl.xml | 8 +- ...apm_paraprobe_intersector_results.nxdl.xml | 59 ++++++------ .../NXapm_paraprobe_nanochem_config.nxdl.xml | 4 +- .../NXapm_paraprobe_nanochem_results.nxdl.xml | 91 +++++++------------ .../NXapm_paraprobe_ranger_config.nxdl.xml | 46 +++++----- .../NXapm_paraprobe_ranger_results.nxdl.xml | 59 ++++++------ .../NXapm_paraprobe_selector_config.nxdl.xml | 4 +- .../NXapm_paraprobe_selector_results.nxdl.xml | 59 ++++++------ .../NXapm_paraprobe_spatstat_config.nxdl.xml | 8 +- .../NXapm_paraprobe_spatstat_results.nxdl.xml | 59 ++++++------ .../NXapm_paraprobe_surfacer_config.nxdl.xml | 6 +- .../NXapm_paraprobe_surfacer_results.nxdl.xml | 63 +++++++------ ...Xapm_paraprobe_tessellator_config.nxdl.xml | 8 +- ...apm_paraprobe_tessellator_results.nxdl.xml | 59 ++++++------ .../NXapm_paraprobe_tool_common.nxdl.xml | 4 +- .../NXapm_paraprobe_tool_config.nxdl.xml | 27 ------ .../NXapm_paraprobe_tool_results.nxdl.xml | 68 +------------- ...NXapm_paraprobe_transcoder_config.nxdl.xml | 8 +- ...Xapm_paraprobe_transcoder_results.nxdl.xml | 64 ++++++------- .../NXapm_paraprobe_clusterer_config.yaml | 13 +-- .../NXapm_paraprobe_clusterer_results.yaml | 45 ++++----- .../NXapm_paraprobe_distancer_config.yaml | 5 +- .../NXapm_paraprobe_distancer_results.yaml | 44 ++++----- .../NXapm_paraprobe_intersector_config.yaml | 5 +- .../NXapm_paraprobe_intersector_results.yaml | 45 ++++----- .../NXapm_paraprobe_nanochem_config.yaml | 4 +- .../NXapm_paraprobe_nanochem_results.yaml | 76 +++++----------- .../nyaml/NXapm_paraprobe_ranger_config.yaml | 21 +++-- .../nyaml/NXapm_paraprobe_ranger_results.yaml | 44 ++++----- .../NXapm_paraprobe_selector_config.yaml | 6 +- .../NXapm_paraprobe_selector_results.yaml | 43 +++++---- .../NXapm_paraprobe_spatstat_config.yaml | 3 +- .../NXapm_paraprobe_spatstat_results.yaml | 44 ++++----- .../NXapm_paraprobe_surfacer_config.yaml | 5 +- .../NXapm_paraprobe_surfacer_results.yaml | 44 ++++----- .../NXapm_paraprobe_tessellator_config.yaml | 5 +- .../NXapm_paraprobe_tessellator_results.yaml | 44 ++++----- .../nyaml/NXapm_paraprobe_tool_common.yaml | 4 +- .../nyaml/NXapm_paraprobe_tool_config.yaml | 21 ----- .../nyaml/NXapm_paraprobe_tool_results.yaml | 55 ----------- .../NXapm_paraprobe_transcoder_config.yaml | 7 +- .../NXapm_paraprobe_transcoder_results.yaml | 47 +++++----- .../contributed_definitions/apm-structure.rst | 4 +- 47 files changed, 657 insertions(+), 826 deletions(-) diff --git a/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml index 2f79008073..77de3ceead 100644 --- a/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml @@ -101,24 +101,14 @@ n_disjoint_clusters: Number of disjoint cluster.--> results POS files that is referred to results. - - - - - - - - - - - - This process performs a cluster analysis on a @@ -373,8 +363,10 @@ optics(NXprocess): - + @@ -384,6 +376,7 @@ e.g. https://doi.org/10.1017/S1431927607070900--> + diff --git a/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml index 4c803d14de..240ac7643d 100644 --- a/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml @@ -249,47 +249,50 @@ number_of_objects(NX_UINT): - + + + - + + - - + - - - - - - - - - - - - - - - - - - - - - - - - + + + If used, metadata of at least the person who performed this analysis. + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml index 7b78769e6d..07af8aabba 100644 --- a/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml @@ -182,7 +182,9 @@ - + + + @@ -192,8 +194,8 @@ + - diff --git a/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml index 8b33f799e0..44ecabca4b 100644 --- a/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml @@ -153,46 +153,49 @@ triangles in this case--> - + + - + + - - + - - - - - - - - - - - - - - - - - - - - - - - - + + + If used, metadata of at least the person who performed this analysis. + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml index d8bcfde6ab..a0ee9a1ab5 100644 --- a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml @@ -250,10 +250,11 @@ - +what one is doing here before using these functionalities--> + @@ -263,6 +264,7 @@ profiling (only stored in the first instance of spatial_statistics)--> + diff --git a/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml index b532602871..0d0f8a497a 100644 --- a/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml @@ -225,46 +225,49 @@ - + + - + + - - + - - - - - - - - - - - - - - - - - - - - - - - - + + + If used, metadata of at least the person who performed this analysis. + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml index 8f7f720dff..5ca97975d2 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml @@ -249,11 +249,11 @@ identifier(NX_UINT):--> - + Array of edge lengths of the cubic cells used for discretizing the reconstructed dataset on a cuboidal 3D grid (:ref:`NXcg_grid`). The tool performs as many delocalization - computations as values in are specified in grid_resolutions. + computations as values are specified in grid_resolution. diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml index e291698c56..23d48e6885 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml @@ -947,22 +947,6 @@ face_identifier_offset(NX_UINT):--> - - - - - - - - - - - - - - - - @@ -1135,22 +1119,6 @@ face_identifier_offset(NX_UINT):--> - - - - - - - - - - - - - - - - @@ -1249,46 +1217,49 @@ face_identifier_offset(NX_UINT):--> - + + - + + - - + - - - - - - - - - - - - - - - - - - - - - - - - + + + If used, metadata of at least the person who performed this analysis. + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml index b24346b7b4..f3efa9aaee 100644 --- a/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml @@ -118,21 +118,9 @@ - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml index e72b9bf9f7..00fad5cf4a 100644 --- a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml @@ -90,46 +90,49 @@ config--> - + + - + + - - + - - - - - - - - - - - - - - - - - - - - - - - - + + + If used, metadata of at least the person who performed this analysis. + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml index 1513ffd6b4..8397ca1dd9 100644 --- a/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml @@ -106,7 +106,8 @@ - + + @@ -116,6 +117,7 @@ + diff --git a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml index 214414f832..bc77420175 100644 --- a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml @@ -62,46 +62,49 @@ - + + - + + - - + - - - - - - - - - - - - - - - - - - - - - - - - + + + If used, metadata of at least the person who performed this analysis. + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml index a7f4198b71..9348913825 100644 --- a/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml @@ -317,9 +317,10 @@ identifier(NX_UINT):--> - + + + @@ -329,6 +330,7 @@ profiling (only stored in the first instance of spatial_statistics)--> + diff --git a/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml index e06d6f7b2f..ff9704aa9e 100644 --- a/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml @@ -144,46 +144,49 @@ n_bins_knn: | - + + - + + - - + - - - - - - - - - - - - - - - - - - - - - - - - + + + If used, metadata of at least the person who performed this analysis. + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml index a30c4d5343..56efd57fb4 100644 --- a/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml @@ -215,8 +215,9 @@ of the alpha complex (currently only for alpha shapes). - + + + @@ -226,6 +227,7 @@ profiling--> + diff --git a/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml index 4967f33cf3..e614e8d931 100644 --- a/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml @@ -238,48 +238,51 @@ for eventually performed preprocessing--> - + + + - + + - - + - - - - - - - - - - - - - - - - - - - - - - - - + + + If used, metadata of at least the person who performed this analysis. + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml index 56b74a8d94..1f9f6dd6ea 100644 --- a/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml @@ -150,13 +150,14 @@ if windowing_method is bitmasked_points: sum cardinality of NXcg := 0 and cardin about the significance of finite size effects. - + minValue: EPSILON--> + @@ -166,6 +167,7 @@ profiling--> + diff --git a/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml index bff43a5efd..5adf8ff54b 100644 --- a/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml @@ -288,46 +288,49 @@ dim: (i,) # one would not need to constrain this but doing so communicates that - + + - + + - - + - - - - - - - - - - - - - - - - - - - - - - - - + + + If used, metadata of at least the person who performed this analysis. + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml index eecad3aaac..57c1362509 100644 --- a/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml @@ -40,8 +40,8 @@ for analyzing data in Materials Science and Materials Engineering. The common section can be used as a place to store e.g. organizational - metadata and contextualization of that analysis in a research data management - system. + metadata and contextualization of that analysis in a research data + management system. diff --git a/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml index fc3c16cd88..91eddca8a2 100644 --- a/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml @@ -134,31 +134,4 @@ base class from which tool-specific appdefs inherit--> - - - - - Metadata of the computational process whereby this configuration was generated. - There is a special set of tools called paraprobe-parmsetup which can be used - to conveniently create configuration HDF5 files following the here NeXus appdef. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the creation of the configuration was started, - i.e. when the respective executable/tool was started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the creation of the configuration was - completed and the respective process of the tool exited. - - - diff --git a/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml index 621d887e02..f2656f66fd 100644 --- a/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml @@ -96,71 +96,5 @@ symbols: - - - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis in this results file was started, - i.e. when the respective executable/tool was started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis in this results file were - completed and the respective process of the tool exited. - - - - - A statement whether the tool executable managed to process the analysis - or whether this failed. Status is written to the results file after the - end_time beyond which point in time the tool must no longer compute - any further analysis results but exit. - - Only when this status message is present and its value is `success`, - one should consider the results of the tool. In all other cases it might - b that the tool has terminated prematurely or another error occurred. - - - - - - - - - - - Details about coordinate systems (reference frames) used. In atom probe several coordinate - systems have to be distinguished. Names of instances of such :ref:`NXcoordinate_system` - should be documented explicitly and doing so by picking from the - following controlled set of names: - - * paraprobe - * lab - * specimen - * laser - * instrument - * detector - * recon - - The aim of this convention is to support users with contextualizing which reference - frame each instance (coordinate system) is. If needed, instances of :ref:`NXtransformations` - are used to detail the explicit affine transformations whereby one can convert - rpresentations between different reference frames. - Inspect :ref:`NXtransformations` for further details. - - - - - - + diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml index 98f80fb126..fa0d485782 100644 --- a/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml @@ -62,9 +62,10 @@ official NeXus appdef headers--> - + + + @@ -74,6 +75,7 @@ profiling--> + diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml index dab98c9a52..96819791a2 100644 --- a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml @@ -157,50 +157,50 @@ config--> - + + + - + + - - + - - - - - If used, metadata of at least the person who performed this analysis. - - - - - - - - - - - - - - - - - - - - - - + + + If used, metadata of at least the person who performed this analysis. + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml index 85f4a47f37..716b44aaa2 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml @@ -67,15 +67,6 @@ NXapm_paraprobe_clusterer_config(NXobject): # in dataset/dataset/dataset_name_reconstruction where covered # by the IVAS/APSuite cluster analysis. This can be useful to recover # the region of interest. - programID(NXprogram): - exists: [min, 1, max, infty] - program(NX_CHAR): - \@version(NX_CHAR): - profiling(NXcs_profiling): - exists: recommended - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - current_working_directory(NX_CHAR): cluster_analysisID(NXapm_paraprobe_tool_config): exists: [min, 0, max, infty] doc: | @@ -288,6 +279,7 @@ NXapm_paraprobe_clusterer_config(NXobject): dim: (m,) # ADD FURTHER ALGORITHMS, see L. Stephenson for further details # e.g. https://doi.org/10.1017/S1431927607070900 + summary(NXapm_paraprobe_tool_common): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): @@ -296,4 +288,5 @@ NXapm_paraprobe_clusterer_config(NXobject): exists: recommended start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): - current_working_directory(NX_CHAR): \ No newline at end of file + current_working_directory(NX_CHAR): + total_elapsed_time(NX_FLOAT): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml index 118aa0f728..1595635ea2 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml @@ -173,35 +173,38 @@ NXapm_paraprobe_clusterer_results(NXobject): unit: NX_UNITLESS dim: (n_feat,) # ADD FURTHER RESULTS along the same pattern for e.g. OPTICS and HDBSCAN - # profiling + + common(NXapm_paraprobe_tool_common): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): profiling(NXcs_profiling): + exists: recommended + status(NX_CHAR): start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): - status(NX_CHAR): current_working_directory(NX_CHAR): - total_elapsed_time(NX_NUMBER): - exists: optional + total_elapsed_time(NX_FLOAT): number_of_processes(NX_POSINT): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): - # global - userID(NXuser): - exists: [min, 0, max, infty] - name(NX_CHAR): - coordinate_system_set(NXcoordinate_system_set): - paraprobe(NXcoordinate_system): - type(NX_CHAR): - handedness(NX_CHAR): - x(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) - y(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) - z(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) + userID(NXuser): + exists: [min, 0, max, infty] + doc: | + If used, metadata of at least the person who performed this analysis. + name(NX_CHAR): + coordinate_system_set(NXcoordinate_system_set): + exists: [min, 1, max, 1] + paraprobe(NXcoordinate_system): + type(NX_CHAR): + handedness(NX_CHAR): + x(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + y(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + z(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml index 9ffd53a64b..dbb93418ae 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml @@ -142,7 +142,8 @@ NXapm_paraprobe_distancer_config(NXobject): exists: optional method(NX_CHAR): match(NX_NUMBER): - # profiling + # point_set_to_polyline_set(NXapm_paraprobe_tool_config): + summary(NXapm_paraprobe_tool_common): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): @@ -152,4 +153,4 @@ NXapm_paraprobe_distancer_config(NXobject): start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): current_working_directory(NX_CHAR): - # point_set_to_polyline_set(NXapm_paraprobe_tool_config): + total_elapsed_time(NX_FLOAT): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml index b6f3dad0c7..a48f619cee 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml @@ -104,35 +104,37 @@ NXapm_paraprobe_distancer_results(NXobject): # triangles in this case mask(NX_UINT): dim: (n_tri,) - # profiling + common(NXapm_paraprobe_tool_common): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): profiling(NXcs_profiling): + exists: recommended + status(NX_CHAR): start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): - status(NX_CHAR): current_working_directory(NX_CHAR): - total_elapsed_time(NX_NUMBER): - exists: optional + total_elapsed_time(NX_FLOAT): number_of_processes(NX_POSINT): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): - # global - userID(NXuser): - exists: [min, 0, max, infty] - name(NX_CHAR): - coordinate_system_set(NXcoordinate_system_set): - paraprobe(NXcoordinate_system): - type(NX_CHAR): - handedness(NX_CHAR): - x(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) - y(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) - z(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) + userID(NXuser): + exists: [min, 0, max, infty] + doc: | + If used, metadata of at least the person who performed this analysis. + name(NX_CHAR): + coordinate_system_set(NXcoordinate_system_set): + exists: [min, 1, max, 1] + paraprobe(NXcoordinate_system): + type(NX_CHAR): + handedness(NX_CHAR): + x(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + y(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + z(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml index 5d5e479cfa..1c0a05e5b3 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml @@ -172,7 +172,7 @@ NXapm_paraprobe_intersector_config(NXobject): ##MK::tetrahedra volume intersection and tessellation and Nef polyhedra intersection are considered guru features # and therefore currently supported only via modifying the C/C++ source code directly as one should know exactly # what one is doing here before using these functionalities - # profiling (only stored in the first instance of spatial_statistics) + summary(NXapm_paraprobe_tool_common): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): @@ -181,4 +181,5 @@ NXapm_paraprobe_intersector_config(NXobject): exists: recommended start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): - current_working_directory(NX_CHAR): \ No newline at end of file + current_working_directory(NX_CHAR): + total_elapsed_time(NX_FLOAT): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml index e94b565274..a0a6033b55 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml @@ -146,35 +146,38 @@ NXapm_paraprobe_intersector_results(NXobject): as many members exist. unit: NX_UNITLESS dim: (n_total, 2) - # profiling + + common(NXapm_paraprobe_tool_common): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): profiling(NXcs_profiling): + exists: recommended + status(NX_CHAR): start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): - status(NX_CHAR): current_working_directory(NX_CHAR): - total_elapsed_time(NX_NUMBER): - exists: optional + total_elapsed_time(NX_FLOAT): number_of_processes(NX_POSINT): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): - # global - userID(NXuser): - exists: [min, 0, max, infty] - name(NX_CHAR): - coordinate_system_set(NXcoordinate_system_set): - paraprobe(NXcoordinate_system): - type(NX_CHAR): - handedness(NX_CHAR): - x(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) - y(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) - z(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) + userID(NXuser): + exists: [min, 0, max, infty] + doc: | + If used, metadata of at least the person who performed this analysis. + name(NX_CHAR): + coordinate_system_set(NXcoordinate_system_set): + exists: [min, 1, max, 1] + paraprobe(NXcoordinate_system): + type(NX_CHAR): + handedness(NX_CHAR): + x(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + y(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + z(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml index 81e8b485d8..d0c29f5c5f 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml @@ -182,11 +182,11 @@ NXapm_paraprobe_nanochem_config(NXobject): Nuclides are identified as hashed nuclide (see :ref:`NXion`) for further details. unit: NX_UNITLESS dim: (n_ityp_deloc_cand, n_ivec_max) - grid_resolutions(NX_FLOAT): + grid_resolution(NX_FLOAT): doc: | Array of edge lengths of the cubic cells used for discretizing the reconstructed dataset on a cuboidal 3D grid (:ref:`NXcg_grid`). The tool performs as many delocalization - computations as values in are specified in grid_resolutions. + computations as values are specified in grid_resolution. unit: NX_LENGTH dim: (n_grid,) kernel_size(NX_UINT): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml index 6d0b1f44cf..461ce77e59 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml @@ -670,21 +670,7 @@ NXapm_paraprobe_nanochem_results(NXobject): nuclide, or (molecular) ion within the volume of the feature/object. unit: NX_UNITLESS dim: (i,) - # profiling - programID(NXprogram): - exists: [min, 1, max, infty] - program(NX_CHAR): - \@version(NX_CHAR): - profiling(NXcs_profiling): - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - status(NX_CHAR): - current_working_directory(NX_CHAR): - total_elapsed_time(NX_NUMBER): - exists: optional - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): + interface_meshing(NXapm_paraprobe_tool_results): exists: [min, 0, max, 1] config(NXserialized): @@ -817,21 +803,6 @@ NXapm_paraprobe_nanochem_results(NXobject): reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. dim: (c, 4) - # profiling - programID(NXprogram): - exists: [min, 1, max, infty] - program(NX_CHAR): - \@version(NX_CHAR): - profiling(NXcs_profiling): - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - status(NX_CHAR): - current_working_directory(NX_CHAR): - total_elapsed_time(NX_NUMBER): - exists: optional - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): oned_profile(NXapm_paraprobe_tool_results): exists: [min, 0, max, 1] @@ -907,35 +878,38 @@ NXapm_paraprobe_nanochem_results(NXobject): Hashvalue using the following hashing rule :math:`H = Z + 256 * N`. unit: NX_UNITLESS dim: (k,) - # profiling + + common(NXapm_paraprobe_tool_common): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): profiling(NXcs_profiling): + exists: recommended + status(NX_CHAR): start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): - status(NX_CHAR): current_working_directory(NX_CHAR): - total_elapsed_time(NX_NUMBER): - exists: optional + total_elapsed_time(NX_FLOAT): number_of_processes(NX_POSINT): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): - # global - userID(NXuser): - exists: [min, 0, max, infty] - name(NX_CHAR): - coordinate_system_set(NXcoordinate_system_set): - paraprobe(NXcoordinate_system): - type(NX_CHAR): - handedness(NX_CHAR): - x(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) - y(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) - z(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) \ No newline at end of file + userID(NXuser): + exists: [min, 0, max, infty] + doc: | + If used, metadata of at least the person who performed this analysis. + name(NX_CHAR): + coordinate_system_set(NXcoordinate_system_set): + exists: [min, 1, max, 1] + paraprobe(NXcoordinate_system): + type(NX_CHAR): + handedness(NX_CHAR): + x(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + y(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + z(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml index 804f851e83..f1c6a26eaa 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml @@ -88,16 +88,6 @@ NXapm_paraprobe_ranger_config(NXobject): match(NX_NUMBER): # tool-specific parameter - # profiling - programID(NXprogram): - exists: [min, 1, max, infty] - program(NX_CHAR): - \@version(NX_CHAR): - profiling(NXcs_profiling): - exists: recommended - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - current_working_directory(NX_CHAR): # molecular_ion_search(NXapm_paraprobe_tool_config): # exists: ['min', '0', 'max', 'unbounded'] # # extent if needed @@ -213,3 +203,14 @@ NXapm_paraprobe_ranger_config(NXobject): # checksum(NX_CHAR): # algorithm(NX_CHAR): # ranging_definitions(NX_CHAR): + summary(NXapm_paraprobe_tool_common): + programID(NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + profiling(NXcs_profiling): + exists: recommended + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + current_working_directory(NX_CHAR): + total_elapsed_time(NX_FLOAT): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml index ad76e718a2..0ae3ba6134 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml @@ -57,35 +57,37 @@ NXapm_paraprobe_ranger_results(NXobject): a (molecular) ion is assumed composed according to the NXion instances. unit: NX_UNITLESS dim: (n_ions,) - # profiling + common(NXapm_paraprobe_tool_common): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): profiling(NXcs_profiling): + exists: recommended + status(NX_CHAR): start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): - status(NX_CHAR): current_working_directory(NX_CHAR): - total_elapsed_time(NX_NUMBER): - exists: optional + total_elapsed_time(NX_FLOAT): number_of_processes(NX_POSINT): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): - # global - userID(NXuser): - exists: [min, 0, max, infty] - name(NX_CHAR): - coordinate_system_set(NXcoordinate_system_set): - paraprobe(NXcoordinate_system): - type(NX_CHAR): - handedness(NX_CHAR): - x(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) - y(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) - z(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) + userID(NXuser): + exists: [min, 0, max, infty] + doc: | + If used, metadata of at least the person who performed this analysis. + name(NX_CHAR): + coordinate_system_set(NXcoordinate_system_set): + exists: [min, 1, max, 1] + paraprobe(NXcoordinate_system): + type(NX_CHAR): + handedness(NX_CHAR): + x(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + y(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + z(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml index 765816455a..459bbe2dcd 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml @@ -80,8 +80,7 @@ NXapm_paraprobe_selector_config(NXobject): exists: optional method(NX_CHAR): match(NX_NUMBER): - - # profiling + summary(NXapm_paraprobe_tool_common): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): @@ -90,4 +89,5 @@ NXapm_paraprobe_selector_config(NXobject): exists: recommended start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): - current_working_directory(NX_CHAR): \ No newline at end of file + current_working_directory(NX_CHAR): + total_elapsed_time(NX_FLOAT): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml index 28c4cff1e7..698a320dde 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml @@ -31,34 +31,37 @@ NXapm_paraprobe_selector_results(NXobject): number_of_ions(NX_UINT): bitdepth(NX_UINT): mask(NX_UINT): - # profiling + common(NXapm_paraprobe_tool_common): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): profiling(NXcs_profiling): + exists: recommended + status(NX_CHAR): start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): - status(NX_CHAR): current_working_directory(NX_CHAR): - total_elapsed_time(NX_NUMBER): + total_elapsed_time(NX_FLOAT): number_of_processes(NX_POSINT): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): - # global - userID(NXuser): - exists: [min, 0, max, infty] - name(NX_CHAR): - coordinate_system_set(NXcoordinate_system_set): - paraprobe(NXcoordinate_system): - type(NX_CHAR): - handedness(NX_CHAR): - x(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) - y(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) - z(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) + userID(NXuser): + exists: [min, 0, max, infty] + doc: | + If used, metadata of at least the person who performed this analysis. + name(NX_CHAR): + coordinate_system_set(NXcoordinate_system_set): + exists: [min, 1, max, 1] + paraprobe(NXcoordinate_system): + type(NX_CHAR): + handedness(NX_CHAR): + x(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + y(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + z(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml index 2987dc277d..35dcbe6be4 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml @@ -242,7 +242,7 @@ NXapm_paraprobe_spatstat_config(NXobject): dim: (3,) # NEW ISSUE: ripleyk(NXcollection): # NEW ISSUE: two_point(NXcollection): - # profiling (only stored in the first instance of spatial_statistics) + summary(NXapm_paraprobe_tool_common): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): @@ -252,3 +252,4 @@ NXapm_paraprobe_spatstat_config(NXobject): start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): current_working_directory(NX_CHAR): + total_elapsed_time(NX_FLOAT): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml index 2cb0a284f6..15cbb76b3c 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml @@ -86,35 +86,37 @@ NXapm_paraprobe_spatstat_results(NXobject): Cumulated and normalized by total counts. unit: NX_DIMENSIONLESS dim: (j,) - # profiling + common(NXapm_paraprobe_tool_common): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): profiling(NXcs_profiling): + exists: recommended + status(NX_CHAR): start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): - status(NX_CHAR): current_working_directory(NX_CHAR): - total_elapsed_time(NX_NUMBER): - exists: optional + total_elapsed_time(NX_FLOAT): number_of_processes(NX_POSINT): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): - # global - userID(NXuser): - exists: [min, 0, max, infty] - name(NX_CHAR): - coordinate_system_set(NXcoordinate_system_set): - paraprobe(NXcoordinate_system): - type(NX_CHAR): - handedness(NX_CHAR): - x(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) - y(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) - z(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) + userID(NXuser): + exists: [min, 0, max, infty] + doc: | + If used, metadata of at least the person who performed this analysis. + name(NX_CHAR): + coordinate_system_set(NXcoordinate_system_set): + exists: [min, 1, max, 1] + paraprobe(NXcoordinate_system): + type(NX_CHAR): + handedness(NX_CHAR): + x(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + y(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + z(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_config.yaml index dae62ec5cb..6f1c3e02ed 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_config.yaml @@ -158,7 +158,7 @@ NXapm_paraprobe_surfacer_config(NXobject): Specifies if the tool should compute all interior tetrahedra of the alpha complex (currently only for alpha shapes). # NEW ISSUE: has_facet_appearance(NX_BOOLEAN): - # profiling + summary(NXapm_paraprobe_tool_common): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): @@ -167,4 +167,5 @@ NXapm_paraprobe_surfacer_config(NXobject): exists: recommended start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): - current_working_directory(NX_CHAR): \ No newline at end of file + current_working_directory(NX_CHAR): + total_elapsed_time(NX_FLOAT): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml index 43b001657b..ba0cd7007e 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml @@ -161,35 +161,37 @@ NXapm_paraprobe_surfacer_results(NXobject): dim: (n_f_tet_xdmf,) # TRIANGLE_SET_WRAPPING(NXprocess): # For the future as we may wish to wrap primitives other like triangles or polylines. - # profiling + common(NXapm_paraprobe_tool_common): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): profiling(NXcs_profiling): + exists: recommended + status(NX_CHAR): start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): - status(NX_CHAR): current_working_directory(NX_CHAR): - total_elapsed_time(NX_NUMBER): - exists: optional + total_elapsed_time(NX_FLOAT): number_of_processes(NX_POSINT): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): - # global - userID(NXuser): - exists: [min, 0, max, infty] - name(NX_CHAR): - coordinate_system_set(NXcoordinate_system_set): - paraprobe(NXcoordinate_system): - type(NX_CHAR): - handedness(NX_CHAR): - x(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) - y(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) - z(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) + userID(NXuser): + exists: [min, 0, max, infty] + doc: | + If used, metadata of at least the person who performed this analysis. + name(NX_CHAR): + coordinate_system_set(NXcoordinate_system_set): + exists: [min, 1, max, 1] + paraprobe(NXcoordinate_system): + type(NX_CHAR): + handedness(NX_CHAR): + x(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + y(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + z(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml index 0819961cb9..81fb0e0a15 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml @@ -119,7 +119,7 @@ NXapm_paraprobe_tessellator_config(NXobject): # unit: NX_LENGTH # \@units: nm # minValue: EPSILON - # profiling + summary(NXapm_paraprobe_tool_common): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): @@ -128,4 +128,5 @@ NXapm_paraprobe_tessellator_config(NXobject): exists: recommended start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): - current_working_directory(NX_CHAR): \ No newline at end of file + current_working_directory(NX_CHAR): + total_elapsed_time(NX_FLOAT): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml index 02e6de963e..fcf97baf83 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml @@ -195,35 +195,37 @@ NXapm_paraprobe_tessellator_results(NXobject): dim: (n_ions,) bitdepth(NX_UINT): mask(NX_UINT): - # profiling + common(NXapm_paraprobe_tool_common): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): profiling(NXcs_profiling): + exists: recommended + status(NX_CHAR): start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): - status(NX_CHAR): current_working_directory(NX_CHAR): - total_elapsed_time(NX_NUMBER): - exists: optional + total_elapsed_time(NX_FLOAT): number_of_processes(NX_POSINT): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): - # global - userID(NXuser): - exists: [min, 0, max, infty] - name(NX_CHAR): - coordinate_system_set(NXcoordinate_system_set): - paraprobe(NXcoordinate_system): - type(NX_CHAR): - handedness(NX_CHAR): - x(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) - y(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) - z(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) + userID(NXuser): + exists: [min, 0, max, infty] + doc: | + If used, metadata of at least the person who performed this analysis. + name(NX_CHAR): + coordinate_system_set(NXcoordinate_system_set): + exists: [min, 1, max, 1] + paraprobe(NXcoordinate_system): + type(NX_CHAR): + handedness(NX_CHAR): + x(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + y(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + z(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml index 63a410db07..95106565d7 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml @@ -17,8 +17,8 @@ doc: | for analyzing data in Materials Science and Materials Engineering. The common section can be used as a place to store e.g. organizational - metadata and contextualization of that analysis in a research data management - system. + metadata and contextualization of that analysis in a research data + management system. type: group NXapm_paraprobe_tool_common(NXprocess): # typically tool-specific section follows diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml index 8af69a3dd0..6b2e1abea3 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml @@ -92,24 +92,3 @@ NXapm_paraprobe_tool_config(NXprocess): (NXspatial_filter): (NXsubsampling_filter): (NXmatch_filter): - # profiling - (NXprogram): - profiling(NXcs_profiling): - doc: | - Metadata of the computational process whereby this configuration was generated. - There is a special set of tools called paraprobe-parmsetup which can be used - to conveniently create configuration HDF5 files following the here NeXus appdef. - # results_path(NX_CHAR): - # doc: | - # Path where the tool stores tool-specific results. If not specified, - # results will be stored in the current working directory. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the creation of the configuration was started, - i.e. when the respective executable/tool was started as a process. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the creation of the configuration was - completed and the respective process of the tool exited. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tool_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tool_results.yaml index bca0d84fd9..bec5bd300f 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tool_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tool_results.yaml @@ -60,59 +60,4 @@ NXapm_paraprobe_tool_results(NXprocess): In such case, padded bits are set to 0. unit: NX_UNITLESS dim: (i,) - - # typically tool-specific section follows - # profiling section - (NXprogram): - profiling(NXcs_profiling): - # results_path(NX_CHAR): - # doc: | - # Path where the tool stores tool-specific results. If not specified, - # results will be stored in the current working directory. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis in this results file was started, - i.e. when the respective executable/tool was started as a process. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis in this results file were - completed and the respective process of the tool exited. - status(NX_CHAR): - doc: | - A statement whether the tool executable managed to process the analysis - or whether this failed. Status is written to the results file after the - end_time beyond which point in time the tool must no longer compute - any further analysis results but exit. - - Only when this status message is present and its value is `success`, - one should consider the results of the tool. In all other cases it might - b that the tool has terminated prematurely or another error occurred. - enumeration: [success, failure] - (NXuser): - (NXcoordinate_system_set): - doc: | - Details about coordinate systems (reference frames) used. In atom probe several coordinate - systems have to be distinguished. Names of instances of such :ref:`NXcoordinate_system` - should be documented explicitly and doing so by picking from the - following controlled set of names: - - * paraprobe - * lab - * specimen - * laser - * instrument - * detector - * recon - - The aim of this convention is to support users with contextualizing which reference - frame each instance (coordinate system) is. If needed, instances of :ref:`NXtransformations` - are used to detail the explicit affine transformations whereby one can convert - rpresentations between different reference frames. - Inspect :ref:`NXtransformations` for further details. - (NXcoordinate_system): - (NXtransformations): - # add further fields coming from using the charge state recovery - # workflow from the ifes_apt_tc_data_modeling library diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml index 4ab9e9094f..5eda75d0c8 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml @@ -38,7 +38,7 @@ NXapm_paraprobe_transcoder_config(NXobject): algorithm(NX_CHAR): # tool-specific parameter # filter - # profiling + summary(NXapm_paraprobe_tool_common): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): @@ -48,3 +48,8 @@ NXapm_paraprobe_transcoder_config(NXobject): start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): current_working_directory(NX_CHAR): + total_elapsed_time(NX_FLOAT): + exists: recommended + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + current_working_directory(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml index 5748e753ed..f4b67b4866 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml @@ -101,38 +101,37 @@ NXapm_paraprobe_transcoder_results(NXobject): unit: NX_ANY # u dim: (i, 2) # (NXapm_charge_state_analysis): - # profiling + common(NXapm_paraprobe_tool_common): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): profiling(NXcs_profiling): + exists: recommended + status(NX_CHAR): start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): - status(NX_CHAR): current_working_directory(NX_CHAR): - total_elapsed_time(NX_NUMBER): - exists: optional + total_elapsed_time(NX_FLOAT): number_of_processes(NX_POSINT): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): - # global - userID(NXuser): - exists: [min, 0, max, infty] - doc: | - If used, metadata of at least the person who performed this analysis. - name(NX_CHAR): - coordinate_system_set(NXcoordinate_system_set): - exists: [min, 1, max, 1] - paraprobe(NXcoordinate_system): - type(NX_CHAR): - handedness(NX_CHAR): - x(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) - y(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) - z(NX_NUMBER): - unit: NX_LENGTH - dim: (3,) + userID(NXuser): + exists: [min, 0, max, infty] + doc: | + If used, metadata of at least the person who performed this analysis. + name(NX_CHAR): + coordinate_system_set(NXcoordinate_system_set): + exists: [min, 1, max, 1] + paraprobe(NXcoordinate_system): + type(NX_CHAR): + handedness(NX_CHAR): + x(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + y(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + z(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) diff --git a/manual/source/classes/contributed_definitions/apm-structure.rst b/manual/source/classes/contributed_definitions/apm-structure.rst index a36a94ad72..a9671b6542 100644 --- a/manual/source/classes/contributed_definitions/apm-structure.rst +++ b/manual/source/classes/contributed_definitions/apm-structure.rst @@ -208,8 +208,8 @@ Base classes have been defined to group common pieces of information for each to toolbox. For each tool we define a pair of base classes. One for the configuration (input) side and one for the results (output) side: - :ref:`NXapm_paraprobe_tool_config`, :ref:`NXapm_paraprobe_tool_results`: - Common parts of configuration settings and results respectively useful for several tools of the paraprobe-toolbox. + :ref:`NXapm_paraprobe_tool_config`, :ref:`NXapm_paraprobe_tool_results`, :ref:`NXapm_paraprobe_tool_common`: + Configuration, results, and common parts respectively useful for the application definitions for tools of the paraprobe-toolbox. .. _ApmParaprobeAppDef: From a2c13f5e5160f0afd789114ce02e8de6f63266c7 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Mon, 26 Feb 2024 12:47:53 +0100 Subject: [PATCH 0596/1012] Resolved logical problem that status was not always present --- .../NXapm_paraprobe_clusterer_config.nxdl.xml | 5 +-- ...NXapm_paraprobe_clusterer_results.nxdl.xml | 4 +-- .../NXapm_paraprobe_distancer_config.nxdl.xml | 5 +-- ...NXapm_paraprobe_distancer_results.nxdl.xml | 4 +-- ...Xapm_paraprobe_intersector_config.nxdl.xml | 5 +-- ...apm_paraprobe_intersector_results.nxdl.xml | 4 +-- .../NXapm_paraprobe_nanochem_config.nxdl.xml | 5 +-- .../NXapm_paraprobe_nanochem_results.nxdl.xml | 4 +-- .../NXapm_paraprobe_ranger_config.nxdl.xml | 5 +-- .../NXapm_paraprobe_ranger_results.nxdl.xml | 4 +-- .../NXapm_paraprobe_selector_config.nxdl.xml | 5 +-- .../NXapm_paraprobe_selector_results.nxdl.xml | 4 +-- .../NXapm_paraprobe_spatstat_config.nxdl.xml | 5 +-- .../NXapm_paraprobe_spatstat_results.nxdl.xml | 4 +-- .../NXapm_paraprobe_surfacer_config.nxdl.xml | 5 +-- .../NXapm_paraprobe_surfacer_results.nxdl.xml | 4 +-- ...Xapm_paraprobe_tessellator_config.nxdl.xml | 5 +-- ...apm_paraprobe_tessellator_results.nxdl.xml | 4 +-- .../NXapm_paraprobe_tool_common.nxdl.xml | 36 +++++++++---------- ...NXapm_paraprobe_transcoder_config.nxdl.xml | 5 +-- ...Xapm_paraprobe_transcoder_results.nxdl.xml | 4 +-- .../NXapm_paraprobe_clusterer_config.yaml | 5 +-- .../NXapm_paraprobe_clusterer_results.yaml | 4 +-- .../NXapm_paraprobe_distancer_config.yaml | 5 +-- .../NXapm_paraprobe_distancer_results.yaml | 4 +-- .../NXapm_paraprobe_intersector_config.yaml | 5 +-- .../NXapm_paraprobe_intersector_results.yaml | 4 +-- .../NXapm_paraprobe_nanochem_config.yaml | 5 +-- .../NXapm_paraprobe_nanochem_results.yaml | 4 +-- .../nyaml/NXapm_paraprobe_ranger_config.yaml | 5 +-- .../nyaml/NXapm_paraprobe_ranger_results.yaml | 4 +-- .../NXapm_paraprobe_selector_config.yaml | 5 +-- .../NXapm_paraprobe_selector_results.yaml | 4 +-- .../NXapm_paraprobe_spatstat_config.yaml | 5 +-- .../NXapm_paraprobe_spatstat_results.yaml | 4 +-- .../NXapm_paraprobe_surfacer_config.yaml | 5 +-- .../NXapm_paraprobe_surfacer_results.yaml | 4 +-- .../NXapm_paraprobe_tessellator_config.yaml | 5 +-- .../NXapm_paraprobe_tessellator_results.yaml | 4 +-- .../nyaml/NXapm_paraprobe_tool_common.yaml | 25 ++++++------- .../NXapm_paraprobe_transcoder_config.yaml | 7 ++-- .../NXapm_paraprobe_transcoder_results.yaml | 4 +-- 42 files changed, 127 insertions(+), 116 deletions(-) diff --git a/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml index 77de3ceead..21897a43b9 100644 --- a/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml @@ -366,7 +366,8 @@ optics(NXprocess): - + + @@ -375,8 +376,8 @@ e.g. https://doi.org/10.1017/S1431927607070900--> - + diff --git a/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml index 240ac7643d..763a37b1c9 100644 --- a/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml @@ -252,17 +252,17 @@ number_of_objects(NX_UINT): + - - + diff --git a/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml index 07af8aabba..e7d6d7917b 100644 --- a/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml @@ -184,7 +184,8 @@ - + + @@ -193,8 +194,8 @@ - + diff --git a/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml index 44ecabca4b..011214db13 100644 --- a/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml @@ -155,17 +155,17 @@ triangles in this case--> + - - + diff --git a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml index a0ee9a1ab5..1fc8cb7666 100644 --- a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml @@ -254,7 +254,8 @@ - + + @@ -263,8 +264,8 @@ what one is doing here before using these functionalities--> - + diff --git a/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml index 0d0f8a497a..91cff8e7b8 100644 --- a/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml @@ -227,17 +227,17 @@ + - - + diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml index 5ca97975d2..72c5bce1af 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml @@ -976,7 +976,8 @@ from normals of neighboring facets, type of weighting schemes can affect results - + + @@ -985,8 +986,8 @@ from normals of neighboring facets, type of weighting schemes can affect results - + diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml index 23d48e6885..5bc27e239a 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml @@ -1219,17 +1219,17 @@ face_identifier_offset(NX_UINT):--> + - - + diff --git a/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml index f3efa9aaee..3282c203db 100644 --- a/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml @@ -227,7 +227,8 @@ path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): ranging_definitions(NX_CHAR):--> - + + @@ -236,8 +237,8 @@ ranging_definitions(NX_CHAR):--> - + diff --git a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml index 00fad5cf4a..33ce11c3c3 100644 --- a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml @@ -92,17 +92,17 @@ config--> + - - + diff --git a/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml index 8397ca1dd9..89484faa9f 100644 --- a/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml @@ -107,7 +107,8 @@ - + + @@ -116,8 +117,8 @@ - + diff --git a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml index bc77420175..702b0e6551 100644 --- a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml @@ -64,17 +64,17 @@ + - - + diff --git a/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml index 9348913825..5f4b26836a 100644 --- a/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml @@ -320,7 +320,8 @@ identifier(NX_UINT):--> - + + @@ -329,8 +330,8 @@ NEW ISSUE: two_point(NXcollection):--> - + diff --git a/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml index ff9704aa9e..d3b0e41426 100644 --- a/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml @@ -146,17 +146,17 @@ n_bins_knn: | + - - + diff --git a/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml index 56efd57fb4..3cb04dac60 100644 --- a/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml @@ -217,7 +217,8 @@ - + + @@ -226,8 +227,8 @@ - + diff --git a/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml index e614e8d931..2d00646571 100644 --- a/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml @@ -242,17 +242,17 @@ for eventually performed preprocessing--> + - - + diff --git a/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml index 1f9f6dd6ea..bf91256517 100644 --- a/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml @@ -157,7 +157,8 @@ if windowing_method is bitmasked_points: sum cardinality of NXcg := 0 and cardin unit: NX_LENGTH \@units: nm minValue: EPSILON--> - + + @@ -166,8 +167,8 @@ if windowing_method is bitmasked_points: sum cardinality of NXcg := 0 and cardin - + diff --git a/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml index 5adf8ff54b..dc8aef4957 100644 --- a/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml @@ -290,17 +290,17 @@ dim: (i,) # one would not need to constrain this but doing so communicates that + - - + diff --git a/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml index 57c1362509..56ce6ef6b8 100644 --- a/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml @@ -43,8 +43,22 @@ metadata and contextualization of that analysis in a research data management system. - + + + A statement whether the tool executable managed to process the analysis + or whether this failed. Status is written to the results file after the + end_time beyond which point in time the tool must no longer compute + any further analysis results but exit. + + Only when this status message is present and its value is `success`, + one should consider the results of the tool. In all other cases it might + be that the tool has terminated prematurely or another error occurred. + + + + + + completed and the respective process of the tool exited. - - - A statement whether the tool executable managed to process the analysis - or whether this failed. Status is written to the results file after the - end_time beyond which point in time the tool must no longer compute - any further analysis results but exit. - - Only when this status message is present and its value is `success`, - one should consider the results of the tool. In all other cases it might - b that the tool has terminated prematurely or another error occurred. - - - - - - - + Wall-clock time. diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml index fa0d485782..21b882cc6c 100644 --- a/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml @@ -65,7 +65,8 @@ official NeXus appdef headers--> - + + @@ -74,8 +75,8 @@ filter--> - + diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml index 96819791a2..df44b28ece 100644 --- a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml @@ -160,17 +160,17 @@ config--> + - - + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml index 716b44aaa2..8e709e89ea 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml @@ -279,7 +279,8 @@ NXapm_paraprobe_clusterer_config(NXobject): dim: (m,) # ADD FURTHER ALGORITHMS, see L. Stephenson for further details # e.g. https://doi.org/10.1017/S1431927607070900 - summary(NXapm_paraprobe_tool_common): + common(NXapm_paraprobe_tool_common): + status(NX_CHAR): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): @@ -288,5 +289,5 @@ NXapm_paraprobe_clusterer_config(NXobject): exists: recommended start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): + total_elapsed_time(NX_FLOAT): current_working_directory(NX_CHAR): - total_elapsed_time(NX_FLOAT): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml index 1595635ea2..32ba9f89fa 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml @@ -175,17 +175,17 @@ NXapm_paraprobe_clusterer_results(NXobject): # ADD FURTHER RESULTS along the same pattern for e.g. OPTICS and HDBSCAN common(NXapm_paraprobe_tool_common): + status(NX_CHAR): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): profiling(NXcs_profiling): exists: recommended - status(NX_CHAR): start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): - current_working_directory(NX_CHAR): total_elapsed_time(NX_FLOAT): + current_working_directory(NX_CHAR): number_of_processes(NX_POSINT): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml index dbb93418ae..3de1558709 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml @@ -143,7 +143,8 @@ NXapm_paraprobe_distancer_config(NXobject): method(NX_CHAR): match(NX_NUMBER): # point_set_to_polyline_set(NXapm_paraprobe_tool_config): - summary(NXapm_paraprobe_tool_common): + common(NXapm_paraprobe_tool_common): + status(NX_CHAR): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): @@ -152,5 +153,5 @@ NXapm_paraprobe_distancer_config(NXobject): exists: recommended start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): + total_elapsed_time(NX_FLOAT): current_working_directory(NX_CHAR): - total_elapsed_time(NX_FLOAT): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml index a48f619cee..8621780ee4 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml @@ -105,17 +105,17 @@ NXapm_paraprobe_distancer_results(NXobject): mask(NX_UINT): dim: (n_tri,) common(NXapm_paraprobe_tool_common): + status(NX_CHAR): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): profiling(NXcs_profiling): exists: recommended - status(NX_CHAR): start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): - current_working_directory(NX_CHAR): total_elapsed_time(NX_FLOAT): + current_working_directory(NX_CHAR): number_of_processes(NX_POSINT): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml index 1c0a05e5b3..0d8414798f 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml @@ -172,7 +172,8 @@ NXapm_paraprobe_intersector_config(NXobject): ##MK::tetrahedra volume intersection and tessellation and Nef polyhedra intersection are considered guru features # and therefore currently supported only via modifying the C/C++ source code directly as one should know exactly # what one is doing here before using these functionalities - summary(NXapm_paraprobe_tool_common): + common(NXapm_paraprobe_tool_common): + status(NX_CHAR): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): @@ -181,5 +182,5 @@ NXapm_paraprobe_intersector_config(NXobject): exists: recommended start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): + total_elapsed_time(NX_FLOAT): current_working_directory(NX_CHAR): - total_elapsed_time(NX_FLOAT): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml index a0a6033b55..510af2132a 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml @@ -148,17 +148,17 @@ NXapm_paraprobe_intersector_results(NXobject): dim: (n_total, 2) common(NXapm_paraprobe_tool_common): + status(NX_CHAR): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): profiling(NXcs_profiling): exists: recommended - status(NX_CHAR): start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): - current_working_directory(NX_CHAR): total_elapsed_time(NX_FLOAT): + current_working_directory(NX_CHAR): number_of_processes(NX_POSINT): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml index d0c29f5c5f..8bb48ce70e 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml @@ -782,7 +782,8 @@ NXapm_paraprobe_nanochem_config(NXobject): For each ROI, how wide (radius) should the cylindrical ROI be. unit: NX_LENGTH - summary(NXapm_paraprobe_tool_common): + common(NXapm_paraprobe_tool_common): + status(NX_CHAR): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): @@ -791,5 +792,5 @@ NXapm_paraprobe_nanochem_config(NXobject): exists: recommended start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): - current_working_directory(NX_CHAR): total_elapsed_time(NX_FLOAT): + current_working_directory(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml index 461ce77e59..ce76996846 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml @@ -880,17 +880,17 @@ NXapm_paraprobe_nanochem_results(NXobject): dim: (k,) common(NXapm_paraprobe_tool_common): + status(NX_CHAR): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): profiling(NXcs_profiling): exists: recommended - status(NX_CHAR): start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): - current_working_directory(NX_CHAR): total_elapsed_time(NX_FLOAT): + current_working_directory(NX_CHAR): number_of_processes(NX_POSINT): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml index f1c6a26eaa..a55de39968 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml @@ -203,7 +203,8 @@ NXapm_paraprobe_ranger_config(NXobject): # checksum(NX_CHAR): # algorithm(NX_CHAR): # ranging_definitions(NX_CHAR): - summary(NXapm_paraprobe_tool_common): + common(NXapm_paraprobe_tool_common): + status(NX_CHAR): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): @@ -212,5 +213,5 @@ NXapm_paraprobe_ranger_config(NXobject): exists: recommended start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): - current_working_directory(NX_CHAR): total_elapsed_time(NX_FLOAT): + current_working_directory(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml index 0ae3ba6134..39767ae503 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml @@ -58,17 +58,17 @@ NXapm_paraprobe_ranger_results(NXobject): unit: NX_UNITLESS dim: (n_ions,) common(NXapm_paraprobe_tool_common): + status(NX_CHAR): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): profiling(NXcs_profiling): exists: recommended - status(NX_CHAR): start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): + total_elapsed_time(NX_FLOAT): current_working_directory(NX_CHAR): - total_elapsed_time(NX_FLOAT): number_of_processes(NX_POSINT): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml index 459bbe2dcd..32c812985d 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_selector_config.yaml @@ -80,7 +80,8 @@ NXapm_paraprobe_selector_config(NXobject): exists: optional method(NX_CHAR): match(NX_NUMBER): - summary(NXapm_paraprobe_tool_common): + common(NXapm_paraprobe_tool_common): + status(NX_CHAR): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): @@ -89,5 +90,5 @@ NXapm_paraprobe_selector_config(NXobject): exists: recommended start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): + total_elapsed_time(NX_FLOAT): current_working_directory(NX_CHAR): - total_elapsed_time(NX_FLOAT): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml index 698a320dde..189e91c5bd 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml @@ -32,17 +32,17 @@ NXapm_paraprobe_selector_results(NXobject): bitdepth(NX_UINT): mask(NX_UINT): common(NXapm_paraprobe_tool_common): + status(NX_CHAR): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): profiling(NXcs_profiling): exists: recommended - status(NX_CHAR): start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): - current_working_directory(NX_CHAR): total_elapsed_time(NX_FLOAT): + current_working_directory(NX_CHAR): number_of_processes(NX_POSINT): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml index 35dcbe6be4..247f87f811 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_config.yaml @@ -242,7 +242,8 @@ NXapm_paraprobe_spatstat_config(NXobject): dim: (3,) # NEW ISSUE: ripleyk(NXcollection): # NEW ISSUE: two_point(NXcollection): - summary(NXapm_paraprobe_tool_common): + common(NXapm_paraprobe_tool_common): + status(NX_CHAR): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): @@ -251,5 +252,5 @@ NXapm_paraprobe_spatstat_config(NXobject): exists: recommended start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): - current_working_directory(NX_CHAR): total_elapsed_time(NX_FLOAT): + current_working_directory(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml index 15cbb76b3c..f7918dc351 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml @@ -87,17 +87,17 @@ NXapm_paraprobe_spatstat_results(NXobject): unit: NX_DIMENSIONLESS dim: (j,) common(NXapm_paraprobe_tool_common): + status(NX_CHAR): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): profiling(NXcs_profiling): exists: recommended - status(NX_CHAR): start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): - current_working_directory(NX_CHAR): total_elapsed_time(NX_FLOAT): + current_working_directory(NX_CHAR): number_of_processes(NX_POSINT): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_config.yaml index 6f1c3e02ed..855783cac1 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_config.yaml @@ -158,7 +158,8 @@ NXapm_paraprobe_surfacer_config(NXobject): Specifies if the tool should compute all interior tetrahedra of the alpha complex (currently only for alpha shapes). # NEW ISSUE: has_facet_appearance(NX_BOOLEAN): - summary(NXapm_paraprobe_tool_common): + common(NXapm_paraprobe_tool_common): + status(NX_CHAR): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): @@ -167,5 +168,5 @@ NXapm_paraprobe_surfacer_config(NXobject): exists: recommended start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): + total_elapsed_time(NX_FLOAT): current_working_directory(NX_CHAR): - total_elapsed_time(NX_FLOAT): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml index ba0cd7007e..8af4e45431 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml @@ -162,17 +162,17 @@ NXapm_paraprobe_surfacer_results(NXobject): # TRIANGLE_SET_WRAPPING(NXprocess): # For the future as we may wish to wrap primitives other like triangles or polylines. common(NXapm_paraprobe_tool_common): + status(NX_CHAR): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): profiling(NXcs_profiling): exists: recommended - status(NX_CHAR): start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): - current_working_directory(NX_CHAR): total_elapsed_time(NX_FLOAT): + current_working_directory(NX_CHAR): number_of_processes(NX_POSINT): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml index 81fb0e0a15..db664973ff 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml @@ -119,7 +119,8 @@ NXapm_paraprobe_tessellator_config(NXobject): # unit: NX_LENGTH # \@units: nm # minValue: EPSILON - summary(NXapm_paraprobe_tool_common): + common(NXapm_paraprobe_tool_common): + status(NX_CHAR): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): @@ -128,5 +129,5 @@ NXapm_paraprobe_tessellator_config(NXobject): exists: recommended start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): + total_elapsed_time(NX_FLOAT): current_working_directory(NX_CHAR): - total_elapsed_time(NX_FLOAT): \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml index fcf97baf83..a88bef10cf 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml @@ -196,17 +196,17 @@ NXapm_paraprobe_tessellator_results(NXobject): bitdepth(NX_UINT): mask(NX_UINT): common(NXapm_paraprobe_tool_common): + status(NX_CHAR): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): profiling(NXcs_profiling): exists: recommended - status(NX_CHAR): start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): - current_working_directory(NX_CHAR): total_elapsed_time(NX_FLOAT): + current_working_directory(NX_CHAR): number_of_processes(NX_POSINT): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml index 95106565d7..1ef4e6460b 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml @@ -21,8 +21,17 @@ doc: | management system. type: group NXapm_paraprobe_tool_common(NXprocess): - # typically tool-specific section follows - # profiling section + status(NX_CHAR): + doc: | + A statement whether the tool executable managed to process the analysis + or whether this failed. Status is written to the results file after the + end_time beyond which point in time the tool must no longer compute + any further analysis results but exit. + + Only when this status message is present and its value is `success`, + one should consider the results of the tool. In all other cases it might + be that the tool has terminated prematurely or another error occurred. + enumeration: [success, failure] (NXprogram): profiling(NXcs_profiling): # results_path(NX_CHAR): @@ -39,22 +48,10 @@ NXapm_paraprobe_tool_common(NXprocess): ISO 8601 formatted time code with local time zone offset to UTC information included when the analysis in this results file were completed and the respective process of the tool exited. - status(NX_CHAR): - doc: | - A statement whether the tool executable managed to process the analysis - or whether this failed. Status is written to the results file after the - end_time beyond which point in time the tool must no longer compute - any further analysis results but exit. - - Only when this status message is present and its value is `success`, - one should consider the results of the tool. In all other cases it might - b that the tool has terminated prematurely or another error occurred. - enumeration: [success, failure] total_elapsed_time(NX_FLOAT): doc: | Wall-clock time. unit: NX_TIME - exists: recommended (NXuser): (NXcoordinate_system_set): doc: | diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml index 5eda75d0c8..0930e7d234 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml @@ -38,7 +38,8 @@ NXapm_paraprobe_transcoder_config(NXobject): algorithm(NX_CHAR): # tool-specific parameter # filter - summary(NXapm_paraprobe_tool_common): + common(NXapm_paraprobe_tool_common): + status(NX_CHAR): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): @@ -47,9 +48,5 @@ NXapm_paraprobe_transcoder_config(NXobject): exists: recommended start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): - current_working_directory(NX_CHAR): total_elapsed_time(NX_FLOAT): - exists: recommended - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): current_working_directory(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml index f4b67b4866..45f189e393 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml @@ -102,17 +102,17 @@ NXapm_paraprobe_transcoder_results(NXobject): dim: (i, 2) # (NXapm_charge_state_analysis): common(NXapm_paraprobe_tool_common): + status(NX_CHAR): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): profiling(NXcs_profiling): exists: recommended - status(NX_CHAR): start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): - current_working_directory(NX_CHAR): total_elapsed_time(NX_FLOAT): + current_working_directory(NX_CHAR): number_of_processes(NX_POSINT): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): From a0de2c40e4ddc78308bee087b54322dcf0ec5662 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Mon, 26 Feb 2024 15:35:41 +0100 Subject: [PATCH 0597/1012] Moving of analysis_identifier and config --- ...apm_paraprobe_intersector_results.nxdl.xml | 14 +++++------ .../NXapm_paraprobe_nanochem_results.nxdl.xml | 25 ++++++------------- .../NXapm_paraprobe_ranger_results.nxdl.xml | 14 +++++------ .../NXapm_paraprobe_selector_results.nxdl.xml | 14 +++++------ .../NXapm_paraprobe_spatstat_results.nxdl.xml | 14 +++++------ .../NXapm_paraprobe_surfacer_results.nxdl.xml | 14 +++++------ ...apm_paraprobe_tessellator_results.nxdl.xml | 14 +++++------ .../NXapm_paraprobe_tool_common.nxdl.xml | 13 ++++++++++ .../NXapm_paraprobe_tool_results.nxdl.xml | 13 ---------- ...Xapm_paraprobe_transcoder_results.nxdl.xml | 7 ++++++ .../NXapm_paraprobe_intersector_results.yaml | 12 ++++----- .../NXapm_paraprobe_nanochem_results.yaml | 21 +++++----------- .../nyaml/NXapm_paraprobe_ranger_results.yaml | 12 ++++----- .../NXapm_paraprobe_selector_results.yaml | 12 ++++----- .../NXapm_paraprobe_spatstat_results.yaml | 12 ++++----- .../NXapm_paraprobe_surfacer_results.yaml | 12 ++++----- .../NXapm_paraprobe_tessellator_results.yaml | 12 ++++----- .../nyaml/NXapm_paraprobe_tool_common.yaml | 9 +++++++ .../nyaml/NXapm_paraprobe_tool_results.yaml | 9 ------- .../NXapm_paraprobe_transcoder_results.yaml | 6 +++++ 20 files changed, 126 insertions(+), 133 deletions(-) diff --git a/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml index 91cff8e7b8..55b2aeea3c 100644 --- a/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml @@ -74,13 +74,6 @@ The results of an overlap/intersection analysis. - - - - - - - @@ -228,6 +221,13 @@ + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml index 5bc27e239a..fa90a67192 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml @@ -93,12 +93,6 @@ The cardinality/total number of triangles in the triangle soup.--> - - - - - - @@ -949,12 +943,6 @@ face_identifier_offset(NX_UINT):--> - - - - - - @@ -1121,12 +1109,6 @@ face_identifier_offset(NX_UINT):--> - - - - - - @@ -1220,6 +1202,13 @@ face_identifier_offset(NX_UINT):--> + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml index 33ce11c3c3..de5680a967 100644 --- a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml @@ -57,13 +57,6 @@ - - - - - - - @@ -93,6 +86,13 @@ config--> + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml index 702b0e6551..5630291783 100644 --- a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml @@ -49,13 +49,6 @@ - - - - - - - @@ -65,6 +58,13 @@ + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml index d3b0e41426..be81d48063 100644 --- a/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml @@ -49,13 +49,6 @@ n_bins_knn: | - - - - - - - @@ -147,6 +140,13 @@ n_bins_knn: | + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml index 2d00646571..fa2bbd8825 100644 --- a/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml @@ -85,13 +85,6 @@ is no guarantee that the resulting mesh yields a watertight mesh. - - - - - - - @@ -243,6 +236,13 @@ for eventually performed preprocessing--> For the future as we may wish to wrap primitives other like triangles or polylines.--> + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml index dc8aef4957..dbfa7dc94c 100644 --- a/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml @@ -67,13 +67,6 @@ The tessellation is computed without periodic boundary conditions. - - - - - - - @@ -291,6 +284,13 @@ dim: (i,) # one would not need to constrain this but doing so communicates that + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml index 56ce6ef6b8..8ee3df1c1c 100644 --- a/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml @@ -60,6 +60,19 @@ + + + + Internal identifier used by the tool to refer to an analysis (aka simulation + id). + + + + + The configuration file that was used to parameterize + the algorithms that this tool has executed. + + - - - - Internal identifier used by the tool to refer to an analysis (aka simulation - id). - - Possibility for leaving a free-text description about this analysis. - - - The configuration file that was used to parameterize - the algorithms that this tool has executed. - - A bitmask which identifies all ions considered in the analysis. diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml index df44b28ece..10609e371d 100644 --- a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml @@ -161,6 +161,13 @@ config--> + + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml index 510af2132a..071453302a 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml @@ -30,12 +30,6 @@ NXapm_paraprobe_intersector_results(NXobject): exists: [min, 0, max, 1] doc: | The results of an overlap/intersection analysis. - analysis_identifier(NX_UINT): - config(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): # results current_to_next_link(NX_UINT): doc: | @@ -149,6 +143,12 @@ NXapm_paraprobe_intersector_results(NXobject): common(NXapm_paraprobe_tool_common): status(NX_CHAR): + analysis_identifier(NX_UINT): + config(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml index ce76996846..e7503c43e0 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml @@ -38,11 +38,6 @@ NXapm_paraprobe_nanochem_results(NXobject): # tasks delocalizationID(NXdelocalization): exists: [min, 0, max, infty] - config(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): window(NXcs_filter_boolean_mask): number_of_ions(NX_UINT): bitdepth(NX_UINT): @@ -673,11 +668,6 @@ NXapm_paraprobe_nanochem_results(NXobject): interface_meshing(NXapm_paraprobe_tool_results): exists: [min, 0, max, 1] - config(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): window(NXcs_filter_boolean_mask): number_of_ions(NX_UINT): bitdepth(NX_UINT): @@ -806,11 +796,6 @@ NXapm_paraprobe_nanochem_results(NXobject): oned_profile(NXapm_paraprobe_tool_results): exists: [min, 0, max, 1] - config(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): window(NXcs_filter_boolean_mask): number_of_ions(NX_UINT): bitdepth(NX_UINT): @@ -881,6 +866,12 @@ NXapm_paraprobe_nanochem_results(NXobject): common(NXapm_paraprobe_tool_common): status(NX_CHAR): + analysis_identifier(NX_UINT): + config(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml index 39767ae503..26653e1ea2 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml @@ -27,12 +27,6 @@ NXapm_paraprobe_ranger_results(NXobject): is marked with a 0 in the iontypes array. ##MK::number_of_ion_types(NX_POSINT): # config - analysis_identifier(NX_UINT): - config(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): window(NXcs_filter_boolean_mask): number_of_ions(NX_UINT): bitdepth(NX_UINT): @@ -59,6 +53,12 @@ NXapm_paraprobe_ranger_results(NXobject): dim: (n_ions,) common(NXapm_paraprobe_tool_common): status(NX_CHAR): + analysis_identifier(NX_UINT): + config(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml index 189e91c5bd..e830ccdd94 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_selector_results.yaml @@ -20,12 +20,6 @@ NXapm_paraprobe_selector_results(NXobject): enumeration: [NXapm_paraprobe_selector_results] # tasks roi(NXapm_paraprobe_tool_results): - analysis_identifier(NX_UINT): - config(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): # results window(NXcs_filter_boolean_mask): number_of_ions(NX_UINT): @@ -33,6 +27,12 @@ NXapm_paraprobe_selector_results(NXobject): mask(NX_UINT): common(NXapm_paraprobe_tool_common): status(NX_CHAR): + analysis_identifier(NX_UINT): + config(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml index f7918dc351..da1164bd61 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml @@ -20,12 +20,6 @@ NXapm_paraprobe_spatstat_results(NXobject): # tasks spatial_statisticsID(NXapm_paraprobe_tool_results): exists: [min, 0, max, infty] - analysis_identifier(NX_UINT): - config(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): window(NXcs_filter_boolean_mask): number_of_ions(NX_UINT): bitdepth(NX_UINT): @@ -88,6 +82,12 @@ NXapm_paraprobe_spatstat_results(NXobject): dim: (j,) common(NXapm_paraprobe_tool_common): status(NX_CHAR): + analysis_identifier(NX_UINT): + config(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml index 8af4e45431..09acc88f67 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml @@ -43,12 +43,6 @@ NXapm_paraprobe_surfacer_results(NXobject): This polyhedron is not necessarily convex. For some algorithms there is no guarantee that the resulting mesh yields a watertight mesh. # config - analysis_identifier(NX_UINT): - config(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): window(NXcs_filter_boolean_mask): number_of_ions(NX_UINT): bitdepth(NX_UINT): @@ -163,6 +157,12 @@ NXapm_paraprobe_surfacer_results(NXobject): # For the future as we may wish to wrap primitives other like triangles or polylines. common(NXapm_paraprobe_tool_common): status(NX_CHAR): + analysis_identifier(NX_UINT): + config(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml index a88bef10cf..9ae8bdfc36 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml @@ -31,12 +31,6 @@ NXapm_paraprobe_tessellator_results(NXobject): The tool detects if cells make contact with the walls of this bounding box. The tessellation is computed without periodic boundary conditions. # config - analysis_identifier(NX_UINT): - config(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): window(NXcs_filter_boolean_mask): number_of_ions(NX_UINT): bitdepth(NX_UINT): @@ -197,6 +191,12 @@ NXapm_paraprobe_tessellator_results(NXobject): mask(NX_UINT): common(NXapm_paraprobe_tool_common): status(NX_CHAR): + analysis_identifier(NX_UINT): + config(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml index 1ef4e6460b..c50af9291b 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml @@ -33,6 +33,15 @@ NXapm_paraprobe_tool_common(NXprocess): be that the tool has terminated prematurely or another error occurred. enumeration: [success, failure] (NXprogram): + (NXidentifier): + analysis_identifier(NX_UINT): + doc: | + Internal identifier used by the tool to refer to an analysis (aka simulation id). + unit: NX_UNITLESS + config(NXserialized): + doc: | + The configuration file that was used to parameterize + the algorithms that this tool has executed. profiling(NXcs_profiling): # results_path(NX_CHAR): # doc: | diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tool_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tool_results.yaml index bec5bd300f..f675ba9e14 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tool_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tool_results.yaml @@ -30,18 +30,9 @@ doc: | type: group NXapm_paraprobe_tool_results(NXprocess): # config section - (NXidentifier): - analysis_identifier(NX_UINT): - doc: | - Internal identifier used by the tool to refer to an analysis (aka simulation id). - unit: NX_UNITLESS description(NX_CHAR): doc: | Possibility for leaving a free-text description about this analysis. - config(NXserialized): - doc: | - The configuration file that was used to parameterize - the algorithms that this tool has executed. window(NXcs_filter_boolean_mask): doc: | A bitmask which identifies all ions considered in the analysis. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml index 45f189e393..e9cd9b04f2 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml @@ -103,6 +103,12 @@ NXapm_paraprobe_transcoder_results(NXobject): # (NXapm_charge_state_analysis): common(NXapm_paraprobe_tool_common): status(NX_CHAR): + analysis_identifier(NX_UINT): + config(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): From 03b15b5b96d0db24f13e7c63a2c80a46ef85dac9 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 27 Feb 2024 16:02:58 +0100 Subject: [PATCH 0598/1012] First round of fixes for appdefs of nanochem tool for delocalization mode --- .../NXapm_paraprobe_nanochem_config.nxdl.xml | 185 ++++++++++-------- .../NXapm_paraprobe_nanochem_results.nxdl.xml | 74 +++---- .../NXapm_paraprobe_nanochem_config.yaml | 131 +++++++------ .../NXapm_paraprobe_nanochem_results.yaml | 59 +++--- 4 files changed, 234 insertions(+), 215 deletions(-) diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml index 72c5bce1af..6334cb3869 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml @@ -61,6 +61,11 @@ Maximum number of atoms per molecular ion. + + + Number of cylinder ROIs to place for oned_profile if no feature mesh is used. + + Application definition for a configuration file of the paraprobe-nanochem tool. @@ -108,7 +113,7 @@ - + A precomputed triangulated surface mesh representing a model (of the surface) of the edge of the dataset. This model can be used to detect and control @@ -139,6 +144,7 @@ + @@ -817,6 +823,70 @@ identifier(NX_UINT):--> + + + Absolute path in the (HDF5) file that points to the distance values. + The tool assumes that the values are stored in the same order as + points (ions). + + + + + + A precomputed triangulated mesh of the feature representing a model of the + interface at which to place ROIs to profile. + + + + + + + + Absolute HDF5 path to the dataset that specifies the array of vertex positions. + + + + + Absolute HDF5 path to the dataset that specifies the array of facet indices + which refer to vertices. + + + + + Absolute HDF5 path to the dataset that specifies the array of facet signed unit + normals. + + + + + Absolute HDF5 path to the dataset that specifies the array of vertex signed unit + normals. + + + + + + If interface_model is isosurface this filter can be used to restrict the analysis to specific + patches of an iso-surface. + + + + + + + + + + + + + Absolute path in the (HDF5) file that points to the distance values. + The tool assumes that the values are stored in the same order as + points (ions). + + @@ -867,87 +937,6 @@ identifier(NX_UINT):--> - - - Interfacial excess computations are performed for ROIs at selected facets or a triangulated interface patch - obtained from e.g. a previous interface_mesh processing. - - For instance many scientist compute the interfacial excess for selected triangle facets of an iso-surface. - In this case, computed iso-surfaces of paraprobe could be used. An example are triangle facet sets about - closed polyhedra, for instance to compute interfacial excess related to phase boundaries of second-phase precipitates. - - Another example are free-standing triangle patches of the iso-surfaces which paraprobe creates. - These could be characterized for interfacial excess. The sub-routines during iso-surface computations - already include a procedure to automatically align local triangle normals based on the gradients of - e.g. composition fields. - - Often scientists face situations in which neither a significant composition gradient across an interface - (grain or phase boundary) exists nor latent crystallographic information about the adjoining crystal is - available or reliable enough. - - In this case `P. Felfer et al. <https://doi.org/10.1016/j.ultramic.2015.06.002>`_ proposed a method to manually place control points and run an automated tessellation-based algorithm to create a triangulated surface patch, - i.e. a model of the location of the interface. In a post-processing step, this triangle set can then be used to - compute again interfacial excess in an automated manner by placing ROIs and aligning these with consistently oriented triangle normals. - - A similar use case is conceptually the one proposed by `X. Zhou et al. <https://doi.org/10.1016/j.actamat.2022.117633>`_ who used first a deep-learning method to locate planar triangulated grain boundary patches. These are eventually processed further with manual editing of the mesh via tools like Blender. Once the user is satisfied with the mesh, the computations of interfacial excess reduce again to an automated placing of ROIs, computations of the distributing of ions to respective ROIs, and plotting the results. - - Another approach for constructing an triangulated surface patch of an interface is to use point cloud processing methods that have been proposed in the laser-scanning, geoinformatics, and CAD community. Different computational geometry methods exist for fitting a parameterized surface to a set of points, using e.g. - non-uniform rational B-splines (NURBS) and triangulating these according to prescribed mesh quality demands. - The advantage of these methods is that they are fully automatable and pick up curved interface segments. - The disadvantage is their often strong sensitivity on the parameterization. - - In all aforementioned cases except an interface_mesh is generated on which the here proposed method - can be applied. In summary, a given an interfacial_excess analysis takes an interface_mesh, places ROIs - automatically and evaluates the spatial distribution of ions as a function of the signed distance to the interface - patch. - - - - - - - - - - - - - - - Absolute HDF5 path to the dataset that specifies the array of vertex positions. - - - - - Absolute HDF5 path to the dataset that specifies the array of facet indices - which refer to vertices. - - - - - Absolute HDF5 path to the dataset that specifies the array of facet signed unit - normals. - - - - - Absolute HDF5 path to the dataset that specifies the array of vertex signed unit - normals. - - - - - - If interface_model is isosurface this filter can be used to restrict the analysis to specific - patches of an iso-surface. - - - - - Which type of distance should be reported for the profile. @@ -964,10 +953,38 @@ from normals of neighboring facets, type of weighting schemes can affect results + + + Explicit x, y, z coordinates (in the paraprobe coordinate system) where ROIs + should be placed if feature is absent. + + + + + + + + + Explicit outer unit normal which explains into which direction each cylinder ROI + is oriented. + + + + + + + - For each ROI, how high (projected on the cylinder axis) should the cylindrical - ROI be. + For each ROI, how high (projected on the cylinder axis) should the cylindrical ROI be. + + If roi_cylinder_center and roi_cylinder_orientation have been defined, roi_cylinder_height + and roi_cylinder_radius can be defined as arrays of size (n_rois,) to instruct the tool to + place a collection of ROIs with different size. + Otherwise, roi_cylinder_height and roi_cylinder_radius have to be a scalars. diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml index fa90a67192..8e4bdaaceb 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml @@ -179,6 +179,42 @@ The cardinality/total number of triangles in the triangle soup.--> For explicit indexing the identifier array has to be defined. + + + Halfwidth of the kernel about the central voxel. + The shape of the kernel is that of a cuboid + of extent 2*kernel_extent[i] + 1 in each dimension i. + + + + + + + + Functional form of the kernel (Ansatz function). + + + + + + + + Standard deviation :math:`\sigma_i` of the kernel in each dimension + in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. + + + + + + + + Expectation value :math:`\mu_i` of the kernel in each dimension + in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. + + + + + A tight axis-aligned bounding box about the grid. @@ -293,44 +329,8 @@ The cardinality/total number of triangles in the triangle soup.--> - - - - Halfwidth of the kernel about the central voxel. - The shape of the kernel is that of a cuboid - of extent 2*kernel_extent[i] + 1 in each dimension i. - - - - - - - - Functional form of the kernel (Ansatz function). - - - - - - - - Standard deviation :math:`\sigma_i` of the kernel in each dimension - in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. - - - - - - - - Expectation value :math:`\mu_i` of the kernel in each dimension - in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. - - - - - + The result of the delocalization :math:`\Phi = f(x, y, z)` based on which subsequent iso-surfaces diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml index 8bb48ce70e..56de80f70b 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml @@ -20,6 +20,8 @@ symbols: How many DCOM iterations. n_ivec_max: | Maximum number of atoms per molecular ion. + n_rois: | + Number of cylinder ROIs to place for oned_profile if no feature mesh is used. type: group NXapm_paraprobe_nanochem_config(NXobject): (NXentry): @@ -62,7 +64,6 @@ NXapm_paraprobe_nanochem_config(NXobject): algorithm(NX_CHAR): ranging_definitions(NX_CHAR): surface(NXserialized): - exists: recommended doc: | A precomputed triangulated surface mesh representing a model (of the surface) of the edge of the dataset. This model can be used to detect and control @@ -87,6 +88,7 @@ NXapm_paraprobe_nanochem_config(NXobject): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): + distance(NX_CHAR): spatial_filter(NXspatial_filter): windowing_method(NX_CHAR): hexahedron_set(NXcg_hexahedron_set): @@ -653,6 +655,53 @@ NXapm_paraprobe_nanochem_config(NXobject): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): + distance(NX_CHAR): + doc: | + Absolute path in the (HDF5) file that points to the distance values. + The tool assumes that the values are stored in the same order as + points (ions). + feature(NXserialized): + doc: | + A precomputed triangulated mesh of the feature representing a model of the + interface at which to place ROIs to profile. + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + vertices(NX_CHAR): + doc: | + Absolute HDF5 path to the dataset that specifies the array of vertex positions. + indices(NX_CHAR): + doc: | + Absolute HDF5 path to the dataset that specifies the array of facet indices + which refer to vertices. + facet_normals(NX_CHAR): + doc: | + Absolute HDF5 path to the dataset that specifies the array of facet signed unit normals. + vertex_normals(NX_CHAR): + doc: | + Absolute HDF5 path to the dataset that specifies the array of vertex signed unit normals. + # triangulated surface meshes are only approximations to eventually curved shape of objects + # consequently, vertex and facet normals typically differ, the former are typically interpolated + # from normals of neighboring facets, type of weighting schemes can affect results quantitatively + patch_filter(NXmatch_filter): + exists: optional + doc: | + If interface_model is isosurface this filter can be used to restrict the analysis to specific + patches of an iso-surface. + method(NX_CHAR): + match(NX_NUMBER): + feature_distance(NXserialized): + exists: recommended + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + distance(NX_CHAR): + doc: | + Absolute path in the (HDF5) file that points to the distance values. + The tool assumes that the values are stored in the same order as + points (ions). spatial_filter(NXspatial_filter): windowing_method(NX_CHAR): hexahedron_set(NXcg_hexahedron_set): @@ -701,70 +750,6 @@ NXapm_paraprobe_nanochem_config(NXobject): method(NX_CHAR): match(NX_NUMBER): # config - interface_model(NX_CHAR): - doc: | - Interfacial excess computations are performed for ROIs at selected facets or a triangulated interface patch - obtained from e.g. a previous interface_mesh processing. - - For instance many scientist compute the interfacial excess for selected triangle facets of an iso-surface. - In this case, computed iso-surfaces of paraprobe could be used. An example are triangle facet sets about - closed polyhedra, for instance to compute interfacial excess related to phase boundaries of second-phase precipitates. - - Another example are free-standing triangle patches of the iso-surfaces which paraprobe creates. - These could be characterized for interfacial excess. The sub-routines during iso-surface computations - already include a procedure to automatically align local triangle normals based on the gradients of - e.g. composition fields. - - Often scientists face situations in which neither a significant composition gradient across an interface - (grain or phase boundary) exists nor latent crystallographic information about the adjoining crystal is - available or reliable enough. - - In this case `P. Felfer et al. `_ proposed a method to manually place control points and run an automated tessellation-based algorithm to create a triangulated surface patch, - i.e. a model of the location of the interface. In a post-processing step, this triangle set can then be used to - compute again interfacial excess in an automated manner by placing ROIs and aligning these with consistently oriented triangle normals. - - A similar use case is conceptually the one proposed by `X. Zhou et al. `_ who used first a deep-learning method to locate planar triangulated grain boundary patches. These are eventually processed further with manual editing of the mesh via tools like Blender. Once the user is satisfied with the mesh, the computations of interfacial excess reduce again to an automated placing of ROIs, computations of the distributing of ions to respective ROIs, and plotting the results. - - Another approach for constructing an triangulated surface patch of an interface is to use point cloud processing methods that have been proposed in the laser-scanning, geoinformatics, and CAD community. Different computational geometry methods exist for fitting a parameterized surface to a set of points, using e.g. - non-uniform rational B-splines (NURBS) and triangulating these according to prescribed mesh quality demands. - The advantage of these methods is that they are fully automatable and pick up curved interface segments. - The disadvantage is their often strong sensitivity on the parameterization. - - In all aforementioned cases except an interface_mesh is generated on which the here proposed method - can be applied. In summary, a given an interfacial_excess analysis takes an interface_mesh, places ROIs - automatically and evaluates the spatial distribution of ions as a function of the signed distance to the interface - patch. - enumeration: [isosurface, external] - # NEW ISSUE: how to implement and also check consistently via NeXus that a - # NEW ISSUE: child group is required only when a field has a certain value? - interface_mesh(NXserialized): - type(NX_CHAR): - path(NX_CHAR): - checksum(NX_CHAR): - algorithm(NX_CHAR): - vertices(NX_CHAR): - doc: | - Absolute HDF5 path to the dataset that specifies the array of vertex positions. - indices(NX_CHAR): - doc: | - Absolute HDF5 path to the dataset that specifies the array of facet indices - which refer to vertices. - facet_normals(NX_CHAR): - doc: | - Absolute HDF5 path to the dataset that specifies the array of facet signed unit normals. - vertex_normals(NX_CHAR): - doc: | - Absolute HDF5 path to the dataset that specifies the array of vertex signed unit normals. - # triangulated surface meshes are only approximations to eventually curved shape of objects - # consequently, vertex and facet normals typically differ, the former are typically interpolated - # from normals of neighboring facets, type of weighting schemes can affect results quantitatively - patch_filter(NXmatch_filter): - exists: optional - doc: | - If interface_model is isosurface this filter can be used to restrict the analysis to specific - patches of an iso-surface. - method(NX_CHAR): - match(NX_NUMBER): distancing_model(NX_CHAR): doc: | Which type of distance should be reported for the profile. @@ -773,9 +758,25 @@ NXapm_paraprobe_nanochem_config(NXobject): doc: | In which directions should the tool probe for each ROI. enumeration: [triangle_outer_unit_normal] # angularly_geodesic_sphere + roi_cylinder_center(NX_FLOAT): + doc: | + Explicit x, y, z coordinates (in the paraprobe coordinate system) where ROIs should be placed if feature is absent. + unit: NX_LENGTH + dim: (n_rois, 3) + roi_cylinder_orientation(NX_FLOAT): + doc: | + Explicit outer unit normal which explains into which direction each cylinder ROI is oriented. + unit: NX_LENGTH + dim: (n_rois, 3) roi_cylinder_height(NX_FLOAT): doc: | For each ROI, how high (projected on the cylinder axis) should the cylindrical ROI be. + + If roi_cylinder_center and roi_cylinder_orientation have been defined, roi_cylinder_height + and roi_cylinder_radius can be defined as arrays of size (n_rois,) to instruct the tool to + place a collection of ROIs with different size. + Otherwise, roi_cylinder_height and roi_cylinder_radius have to be a scalars. + # not yet implemented the case to have ROIs of different size for each triangle of the feature mesh unit: NX_LENGTH roi_cylinder_radius(NX_FLOAT): doc: | diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml index e7503c43e0..190757f29e 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml @@ -87,12 +87,36 @@ NXapm_paraprobe_nanochem_results(NXobject): dim: (d,) # coordinate_system implicit identifier_offset(NX_INT): - doc: | - Integer which specifies the first index to be used for distinguishing identifiers for cells. - Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are - defined on the interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - unit: NX_UNITLESS + doc: | + Integer which specifies the first index to be used for distinguishing identifiers for cells. + Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are + defined on the interval [identifier_offset, identifier_offset+c-1]. + For explicit indexing the identifier array has to be defined. + unit: NX_UNITLESS + kernel_size(NX_POSINT): + doc: | + Halfwidth of the kernel about the central voxel. + The shape of the kernel is that of a cuboid + of extent 2*kernel_extent[i] + 1 in each dimension i. + unit: NX_DIMENSIONLESS + dim: (3,) + kernel_type(NX_CHAR): + doc: | + Functional form of the kernel (Ansatz function). + enumeration: [gaussian] + kernel_sigma(NX_FLOAT): + doc: | + Standard deviation :math:`\sigma_i` of the kernel in each dimension + in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. + unit: NX_LENGTH + dim: (3,) + kernel_mu(NX_FLOAT): + doc: | + Expectation value :math:`\mu_i` of the kernel in each dimension + in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. + unit: NX_LENGTH + dim: (3,) + bounding_box(NXcg_hexahedron_set): doc: | A tight axis-aligned bounding box about the grid. @@ -185,29 +209,6 @@ NXapm_paraprobe_nanochem_results(NXobject): unit: NX_UNITLESS dim: (6,) ##MK::how to avoid storing it for once in NeXus for H5Web and for XDMF in ParaView ? - kernel_size(NX_POSINT): - doc: | - Halfwidth of the kernel about the central voxel. - The shape of the kernel is that of a cuboid - of extent 2*kernel_extent[i] + 1 in each dimension i. - unit: NX_DIMENSIONLESS - dim: (3,) - kernel_type(NX_CHAR): - doc: | - Functional form of the kernel (Ansatz function). - enumeration: [gaussian] - kernel_sigma(NX_FLOAT): - doc: | - Standard deviation :math:`\sigma_i` of the kernel in each dimension - in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. - unit: NX_LENGTH - dim: (3,) - kernel_mu(NX_FLOAT): - doc: | - Expectation value :math:`\mu_i` of the kernel in each dimension - in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. - unit: NX_LENGTH - dim: (3,) scalar_field_magn_SUFFIX(NXdata): exists: [min, 0, max, infty] doc: | From 2b8c3522681a14773efc961e4b8d172fa5cf6584 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 27 Feb 2024 18:55:59 +0100 Subject: [PATCH 0599/1012] Fixes intersector config --- .../NXapm_paraprobe_intersector_config.nxdl.xml | 1 + .../nyaml/NXapm_paraprobe_intersector_config.yaml | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml index 1fc8cb7666..463ede5d5d 100644 --- a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml @@ -161,6 +161,7 @@ + diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml index 0d8414798f..c01dd59ae6 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml @@ -108,7 +108,7 @@ NXapm_paraprobe_intersector_config(NXobject): feature_type(NX_CHAR): doc: | Descriptive category explaining what these features are. - enumeration: [objects_far_from_edge, objects_close_to_edge, proxies_far_from_edge, proxies_close_to_edge] + enumeration: [objects_far_from_edge, objects_close_to_edge, proxies_far_from_edge, proxies_close_to_edge, other] type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): From ca5b4afcc9364dd7faf09306f9324e72c5089762 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 28 Feb 2024 10:44:19 +0100 Subject: [PATCH 0600/1012] Changes due to comments from colleagues --- contributed_definitions/NXapm.nxdl.xml | 18 +++++++++++------- contributed_definitions/NXion.nxdl.xml | 6 +++--- contributed_definitions/NXpeak.nxdl.xml | 6 +++--- contributed_definitions/nyaml/NXapm.yaml | 6 +++++- contributed_definitions/nyaml/NXion.yaml | 6 +++--- contributed_definitions/nyaml/NXpeak.yaml | 2 +- 6 files changed, 26 insertions(+), 18 deletions(-) diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index d6c1fce871..845e0dd836 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -49,11 +49,10 @@ - - - - - + + + + @@ -533,10 +532,15 @@ schema for heat treatment - + + + The wavelength of the radiation emitted by the source. + + - + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index 62dcc6af57..2f770a59a3 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -117,10 +117,10 @@ Signed charge state of the ion in multiples of electron charge. - Only positive values will be measured in atom probe microscopy + In the example of atom probe microscopy, only positive values will be measured as the ions are accelerated by a negatively signed bias electric field. - In the case that the charge state is not explicitly recoverable, - the value should be set to zero. + In the case that the charge state is not explicitly recoverable, the value should + be set to zero. In atom probe microscopy this is for example the case when using classical ranging definition files in formats like RNG, RRNG. diff --git a/contributed_definitions/NXpeak.nxdl.xml b/contributed_definitions/NXpeak.nxdl.xml index 565d2d1e27..2c01e617e1 100644 --- a/contributed_definitions/NXpeak.nxdl.xml +++ b/contributed_definitions/NXpeak.nxdl.xml @@ -2,9 +2,9 @@ - + Base class documenting the information common to tools of the paraprobe-toolbox. diff --git a/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml index 91eddca8a2..c2169cc139 100644 --- a/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + Base class documenting the configuration used for a tool of the paraprobe-toolbox. diff --git a/contributed_definitions/NXms_feature_set.nxdl.xml b/contributed_definitions/NXms_feature_set.nxdl.xml index 9938c3b9c6..2f2010d0e6 100644 --- a/contributed_definitions/NXms_feature_set.nxdl.xml +++ b/contributed_definitions/NXms_feature_set.nxdl.xml @@ -164,7 +164,7 @@ TJLD: equivalent to the AtomGroups index diff --git a/contributed_definitions/NXms_score_config.nxdl.xml b/contributed_definitions/NXms_score_config.nxdl.xml index ad44095de8..93b914d28d 100644 --- a/contributed_definitions/NXms_score_config.nxdl.xml +++ b/contributed_definitions/NXms_score_config.nxdl.xml @@ -44,9 +44,6 @@ - - Official NeXus NXDL schema with which this file was written. - diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index f1866cf248..24243000c5 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -81,9 +81,6 @@ inspect comments behind NXms--> - - NeXus NXDL schema to which this file conforms. - diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml index c01dd59ae6..394e8c1160 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml @@ -72,7 +72,7 @@ NXapm_paraprobe_intersector_config(NXobject): doc: | Specifies if the tool stores the so-called backward relations between nodes representing members of the next_set to nodes representing members of the current_set. - current_set(NXprocess): + current_set(NXobject): doc: | Current set stores a set of members, meshes of volumetric features, which will be checked for proximity and/or volumetric intersection, @@ -122,7 +122,7 @@ NXapm_paraprobe_intersector_config(NXobject): Array of identifier whereby the path to the geometry data can be interferred automatically. unit: NX_UNITLESS dim: (i,) - next_set(NXprocess): + next_set(NXobject): doc: | Next set stores a set of members, meshes of volumetric features, which will be checked for proximity and/or volumetric intersection, diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml index c50af9291b..11d43c91d2 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml @@ -20,7 +20,7 @@ doc: | metadata and contextualization of that analysis in a research data management system. type: group -NXapm_paraprobe_tool_common(NXprocess): +NXapm_paraprobe_tool_common(NXobject): status(NX_CHAR): doc: | A statement whether the tool executable managed to process the analysis diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml index 6b2e1abea3..459faaac0a 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tool_config.yaml @@ -20,7 +20,7 @@ doc: | using binary container formats. Currently, paraprobe-toolbox uses the Hierarchical Data Format 5 (HDF5). type: group -NXapm_paraprobe_tool_config(NXprocess): +NXapm_paraprobe_tool_config(NXobject): # sequence_id is inherited from NXprocess (NXidentifier): analysis_identifier(NX_UINT): diff --git a/contributed_definitions/nyaml/NXms_feature_set.yaml b/contributed_definitions/nyaml/NXms_feature_set.yaml index cc7aceda67..1704bae538 100644 --- a/contributed_definitions/nyaml/NXms_feature_set.yaml +++ b/contributed_definitions/nyaml/NXms_feature_set.yaml @@ -94,7 +94,7 @@ NXms_feature_set(NXobject): unit: NX_UNITLESS dim: (n_parent_ids,) # description of the geometry of the features - # MK::how can be define that inside lines(NXprocess) we assure that there is either no geometry or only one geometry but then this geometry can be either an NXcg_polyline_set or NXcg_spline_set? + # MK::how can be define that inside lines(NXobject) we assure that there is either no geometry or only one geometry but then this geometry can be either an NXcg_polyline_set or NXcg_spline_set? # the key problem is that at least for an implementation in HDF5 we are not allowed to have two groups named geometry even if their attributes are different because # HDF5 implements no conceptual understanding of the relations between elements in the underlying graph which holds the data, these elements are either attributes, fields, groups, all of which # end up as links diff --git a/contributed_definitions/nyaml/NXms_score_config.yaml b/contributed_definitions/nyaml/NXms_score_config.yaml index 6a4d7f731d..4e58e95872 100644 --- a/contributed_definitions/nyaml/NXms_score_config.yaml +++ b/contributed_definitions/nyaml/NXms_score_config.yaml @@ -12,8 +12,6 @@ type: group NXms_score_config(NXobject): (NXentry): definition(NX_CHAR): - doc: | - Official NeXus NXDL schema with which this file was written. \@version(NX_CHAR): enumeration: [NXms_score_config] PROGRAM(NXprogram): diff --git a/contributed_definitions/nyaml/NXms_score_results.yaml b/contributed_definitions/nyaml/NXms_score_results.yaml index cb591d0b64..4612400bc2 100644 --- a/contributed_definitions/nyaml/NXms_score_results.yaml +++ b/contributed_definitions/nyaml/NXms_score_results.yaml @@ -36,8 +36,6 @@ type: group NXms_score_results(NXobject): (NXentry): definition(NX_CHAR): - doc: | - NeXus NXDL schema to which this file conforms. \@version(NX_CHAR): enumeration: [NXms_score_results] analysis_identifier: From b6cf0b261733b9f8829675684cc743bc521a8538 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 28 Feb 2024 15:21:47 +0100 Subject: [PATCH 0603/1012] Round 1, implementation feedback from colleagues --- contributed_definitions/NXem.nxdl.xml | 24 ++++++--- .../NXevent_data_em.nxdl.xml | 6 +-- contributed_definitions/NXheater.nxdl.xml | 49 ------------------- contributed_definitions/NXstage_lab.nxdl.xml | 7 +-- contributed_definitions/nyaml/NXem.yaml | 11 ++++- .../nyaml/NXevent_data_em.yaml | 2 +- contributed_definitions/nyaml/NXheater.yaml | 22 --------- .../nyaml/NXstage_lab.yaml | 1 + 8 files changed, 37 insertions(+), 85 deletions(-) delete mode 100644 contributed_definitions/NXheater.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXheater.yaml diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index d0bfdca89c..a3925591fc 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -2,9 +2,9 @@ - - - - + + + + Nominal current of the heater. + + + + + Nominal voltage of the heater. + + + + + Nominal power of the heater. + + diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml index c2921fcf28..b1a4560038 100644 --- a/contributed_definitions/NXevent_data_em.nxdl.xml +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -2,9 +2,9 @@ - - - A device for heating. - - - - Nominal current of the heater. - - - - - Nominal voltage of the heater. - - - - - Nominal power of the heater. - - - - - Nominal resistance of the heater. - - - - diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index 1239e2a45c..b0a407330f 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -2,9 +2,9 @@ + + The temperature of the last heat treatment step before quenching. @@ -654,13 +652,13 @@ NEW ISSUE: make this rather an own subentry NXapm_ranging--> - + - + @@ -709,18 +707,18 @@ we can only make recommendations--> - + - + - + @@ -777,7 +775,7 @@ i number of hits after hits finding but prior calibrations--> the ions were evaporated but taking into account that a hit_finding and spatial_filtering was applied. - + @@ -809,13 +807,13 @@ but not necessarily unprocessed timing data from the detector (unless individual 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--> - + - + @@ -836,7 +834,7 @@ Relevant for ranging are the calibrated data, thats why only these - + @@ -886,7 +884,7 @@ results--> - + @@ -907,26 +905,26 @@ results--> \@long_name:--> - + - + - + - + @@ -968,13 +966,13 @@ results--> - + - + diff --git a/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml b/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml index 67eee6648b..864ec36205 100644 --- a/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml +++ b/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml @@ -2,9 +2,9 @@ used. Keep in mind though with such a weakly constrained parameter space the combinatorial analysis may become very time consuming! - + @@ -78,7 +78,7 @@ input/config--> Input constraint, interval within which (molecular) ions need to have the mass-to-charge-state-ratio such that an ion qualifies as a candidate. - + @@ -114,7 +114,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Signed charge, i.e. integer multiple of the elementary charge of each candidate. - + @@ -123,7 +123,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Table of nuclide instances of which each candidate is composed. Each row vector is sorted in descending order. Unused values are nullified. - + @@ -133,7 +133,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Accumulated mass of the nuclides in each candidate. Not corrected for quantum effects. - + @@ -141,7 +141,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> The product of the natural abundances of the nuclides for each candidate. - + @@ -150,7 +150,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> For each candidate the half life of that nuclide which has the shortest half life. - + diff --git a/contributed_definitions/NXapm_hit_finding.nxdl.xml b/contributed_definitions/NXapm_hit_finding.nxdl.xml index 7ea1adbfee..f320adda2d 100644 --- a/contributed_definitions/NXapm_hit_finding.nxdl.xml +++ b/contributed_definitions/NXapm_hit_finding.nxdl.xml @@ -66,7 +66,7 @@ Alias tuple (begin, end) of each DLD wire of the detector. Order follows arrival_time_pairs. - + @@ -76,7 +76,7 @@ Raw readings from the analog-to-digital-converter timing circuits of the detector wires. - + @@ -88,7 +88,7 @@ Evaluated ion impact coordinates on the detector. Use the depends_on field to spec - + @@ -104,7 +104,7 @@ AMETEK/Cameca uses e.g. golden, multiple, partial, irrecoverable, and multi-first and multi-late. - + @@ -119,7 +119,7 @@ Hit quality identifier for each pulse. Identifier have to be within hit_quality_identifier. - + @@ -133,7 +133,7 @@ a molecular ion contains (which is instead encoded with the isotope_vector field of each :ref:`NXion` instance). - + diff --git a/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml index 21897a43b9..2803362373 100644 --- a/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml @@ -231,7 +231,7 @@ identifier(NX_UINT):--> In the simplest case, the matrix contains only the proton number of the element in the row, all other values set to zero. - + @@ -275,7 +275,7 @@ identifier(NX_UINT):--> Array of epsilon (eps) parameter values. - + @@ -283,7 +283,7 @@ identifier(NX_UINT):--> Array of minimum points (min_pts) parameter values. - + @@ -334,7 +334,7 @@ optics(NXprocess): Array of min_cluster_size parameter values. - + @@ -342,7 +342,7 @@ optics(NXprocess): Array of min_samples parameter values. - + @@ -350,7 +350,7 @@ optics(NXprocess): Array of cluster_selection parameter values. - + @@ -358,7 +358,7 @@ optics(NXprocess): Array of alpha parameter values. - + diff --git a/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml index 763a37b1c9..237670acdf 100644 --- a/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml @@ -107,7 +107,7 @@ of this array is not necessarily n_ions. Instead, it is the value of cardinality. - + @@ -120,7 +120,7 @@ tuples for each target that can be used to decode model_labels, core_sample_indices, and weight. - + @@ -133,7 +133,7 @@ multiple cluster this array is as long as the total number of solutions found and - + @@ -142,7 +142,7 @@ The raw array of core sample indices which specify which of the targets are core points. - + @@ -150,7 +150,7 @@ Numerical label for each target (member in the set) aka cluster identifier. - + @@ -158,7 +158,7 @@ Categorical label(s) for each target (member in the set) aka cluster name(s). - + @@ -172,33 +172,29 @@ should the position of the ion be accounted for because the ion is e.g. a molecular ion with several elements or nuclides of requested type. - + - + mask(NX_UINT):--> Are targets assigned to the noise category or not. - + - + mask(NX_UINT):--> Are targets assumed a core point. - + @@ -235,7 +231,7 @@ number_of_objects(NX_UINT): Numerical identifier of each feature aka cluster_identifier. - + @@ -243,7 +239,7 @@ number_of_objects(NX_UINT): Number of members for each feature. - + @@ -278,17 +274,17 @@ number_of_objects(NX_UINT): - + - + - + diff --git a/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml index 011214db13..d6f6bd42e1 100644 --- a/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml @@ -80,7 +80,7 @@ The shortest analytical distance of each point to their respectively closest triangle from the joint triangle set. - + @@ -89,7 +89,7 @@ For each point the identifier of the triangle for which the shortest distance was found - + @@ -100,7 +100,7 @@ The field can be used to visualize the points as a function of their distance to the triangle set (e.g. via XDMF/Paraview). - + @@ -131,7 +131,7 @@ is not an integer multiple of bitdepth. If padding is used, padded bits are set to 0. - + @@ -148,7 +148,7 @@ the field mask of the NXcs_filter_boolean_mask is inherited that means its docst its unit category only the dimensions are constrained strong to match the number of objects triangles in this case--> - + @@ -181,17 +181,17 @@ triangles in this case--> - + - + - + diff --git a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml index 6fcd29b4c5..93103b62ee 100644 --- a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml @@ -180,7 +180,7 @@ Array of identifier whereby the path to the geometry data can be interferred automatically. - + @@ -245,7 +245,7 @@ Array of identifier whereby the path to the geometry data can be interferred automatically. - + diff --git a/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml index 55b2aeea3c..0d11cfe57d 100644 --- a/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml @@ -81,7 +81,7 @@ from the current_set have directed link(s) pointing to which named feature(s) from the next_set. - + @@ -92,7 +92,7 @@ link is due to volumetric overlap (0x00 == 0), proximity (0x01 == 1), or something else unknown (0xFF == 255). - + @@ -104,7 +104,7 @@ links are defined is symmetric it holds that next_to_current maps the links for current_to_next in just the opposite direction. - + @@ -115,7 +115,7 @@ link is due to a volumetric overlap (0x00 == 0), proximity (0x01 == 1), or something else unknown (0xFF == 255). - + @@ -125,7 +125,7 @@ intersection, i.e. how much volume do the two features share. If features do not intersect the volume is zero. - + @@ -162,7 +162,7 @@ encodes the cluster to which each feature_identifier was assigned. Here for features of the current_set. - + @@ -173,7 +173,7 @@ encodes the cluster to which each feature_identifier was assigned. Here for features of the next_set. - + @@ -182,7 +182,7 @@ The identifier (names) of the cluster. - + @@ -197,7 +197,7 @@ The third column encodes the total number of members in the cluster. - + @@ -212,7 +212,7 @@ The second column encodes how many clusters with as many members exist. - + @@ -253,17 +253,17 @@ - + - + - + diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml index 6334cb3869..09af95498b 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml @@ -250,7 +250,7 @@ identifier(NX_UINT):--> Unused values in each row of the matrix are nullified. Nuclides are identified as hashed nuclide (see :ref:`NXion`) for further details. - + @@ -261,7 +261,7 @@ identifier(NX_UINT):--> on a cuboidal 3D grid (:ref:`NXcg_grid`). The tool performs as many delocalization computations as values are specified in grid_resolution. - + @@ -279,7 +279,7 @@ identifier(NX_UINT):--> The tool performs as many delocalization computations as values are specified in kernel_variance. - + @@ -708,7 +708,7 @@ identifier(NX_UINT):--> Array of nuclide iontypes to filter. - + @@ -725,7 +725,7 @@ identifier(NX_UINT):--> which specify how the initial triangles of the mesh should be iteratively refined by edge splitting and related mesh refinement operations. - + @@ -740,7 +740,7 @@ identifier(NX_UINT):--> self-intersections may occur. The tool detects these and stops in a controlled manner so that the user can repeat the analyses with using a different parameterization. - + @@ -753,7 +753,7 @@ identifier(NX_UINT):--> parameter values to be used in the first DCOM iteration. The first entry of each array those for the second DCOM iteration and so on and so forth. - + @@ -958,7 +958,7 @@ identifier(NX_UINT):--> Explicit x, y, z coordinates (in the paraprobe coordinate system) where ROIs should be placed if feature is absent. - + @@ -968,15 +968,12 @@ identifier(NX_UINT):--> Explicit outer unit normal which explains into which direction each cylinder ROI is oriented. - + - + For each ROI, how high (projected on the cylinder axis) should the cylindrical ROI be. diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml index 8e4bdaaceb..b7a4d1c398 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml @@ -136,7 +136,7 @@ The cardinality/total number of triangles in the triangle soup.--> - + @@ -153,7 +153,7 @@ The cardinality/total number of triangles in the triangle soup.--> The unit cell dimensions according to the coordinate system defined under coordinate_system. - + @@ -166,7 +166,7 @@ The cardinality/total number of triangles in the triangle soup.--> outside some masking primitive are removed, this extent field should not be used. Instead use the coordinate field. - + @@ -185,7 +185,7 @@ The cardinality/total number of triangles in the triangle soup.--> The shape of the kernel is that of a cuboid of extent 2*kernel_extent[i] + 1 in each dimension i. - + @@ -202,7 +202,7 @@ The cardinality/total number of triangles in the triangle soup.--> Standard deviation :math:`\sigma_i` of the kernel in each dimension in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. - + @@ -211,7 +211,7 @@ The cardinality/total number of triangles in the triangle soup.--> Expectation value :math:`\mu_i` of the kernel in each dimension in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. - + @@ -263,7 +263,7 @@ The cardinality/total number of triangles in the triangle soup.--> mesh even though many vertices are shared between triangles and thus the positions of these vertices do not have to be duplicated. - + @@ -281,7 +281,7 @@ The cardinality/total number of triangles in the triangle soup.--> the vertex identifiers for the i-th face on the following index interval of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. - + @@ -293,7 +293,7 @@ The cardinality/total number of triangles in the triangle soup.--> primitive count value (here 4 because each face is a quad). The remaining four values are the vertex indices. - + @@ -309,7 +309,7 @@ The cardinality/total number of triangles in the triangle soup.--> Name of the boundaries. E.g. left, right, front, back, bottom, top, The field must have as many entries as there are number_of_boundaries. - + @@ -324,7 +324,7 @@ The cardinality/total number of triangles in the triangle soup.--> 4 - von Neumann 5 - Dirichlet - + @@ -355,7 +355,7 @@ The cardinality/total number of triangles in the triangle soup.--> The actual delocalized intensity values. - + @@ -365,7 +365,7 @@ The cardinality/total number of triangles in the triangle soup.--> Cell center of mass positions along x. - + @@ -373,7 +373,7 @@ The cardinality/total number of triangles in the triangle soup.--> Cell center of mass positions along y. - + @@ -381,7 +381,7 @@ The cardinality/total number of triangles in the triangle soup.--> Cell center of mass positions along z. - + @@ -389,7 +389,7 @@ The cardinality/total number of triangles in the triangle soup.--> Intensity of the field at given point - + @@ -398,7 +398,7 @@ The cardinality/total number of triangles in the triangle soup.--> Center of mass positions of each voxel for rendering the scalar field via XDMF in e.g. Paraview. - + @@ -408,7 +408,7 @@ The cardinality/total number of triangles in the triangle soup.--> XDMF topology for rendering in combination with xdmf_xyz the scalar field via XDMF in e.g. Paraview. - + @@ -428,7 +428,7 @@ The cardinality/total number of triangles in the triangle soup.--> The actual point-wise component values. - + @@ -439,7 +439,7 @@ The cardinality/total number of triangles in the triangle soup.--> Cell center of mass positions along x. - + @@ -447,7 +447,7 @@ The cardinality/total number of triangles in the triangle soup.--> Cell center of mass positions along y. - + @@ -455,7 +455,7 @@ The cardinality/total number of triangles in the triangle soup.--> Cell center of mass positions along z. - + @@ -464,7 +464,7 @@ The cardinality/total number of triangles in the triangle soup.--> The gradient vector formatted for direct visualization via XDMF in e.g. Paraview. - + @@ -474,7 +474,7 @@ The cardinality/total number of triangles in the triangle soup.--> Center of mass positions of each voxel for rendering the scalar field gradient via XDMF in e.g. Paraview. - + @@ -484,7 +484,7 @@ The cardinality/total number of triangles in the triangle soup.--> XDMF topology for rendering in combination with xdmf_xyz the scalar field via XDFM in e.g. Paraview. - + @@ -550,7 +550,7 @@ The cardinality/total number of triangles in the triangle soup.--> case vertices_are_unique is likely False. Naively here means that each vertex is stored even though many share the same positions. - + @@ -568,7 +568,7 @@ The cardinality/total number of triangles in the triangle soup.--> the vertex identifiers for the i-th face on the following index interval of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. - + @@ -578,7 +578,7 @@ The cardinality/total number of triangles in the triangle soup.--> of vertices and a triple of vertex indices specifying each triangle. The total number of entries is n_f_tri * (1+1+3). - + @@ -587,7 +587,7 @@ The cardinality/total number of triangles in the triangle soup.--> Direction of each normal. - + @@ -601,7 +601,7 @@ The cardinality/total number of triangles in the triangle soup.--> * 1 - outer * 2 - inner - + @@ -613,7 +613,7 @@ The cardinality/total number of triangles in the triangle soup.--> Direction of each normal. - + @@ -627,7 +627,7 @@ The cardinality/total number of triangles in the triangle soup.--> * 1 - outer * 2 - inner - + @@ -637,7 +637,7 @@ The cardinality/total number of triangles in the triangle soup.--> gradient vector of the local delocalized scalar field. :math:`\sum_{x, y, z} {\nabla{c}_i}^2`. - + @@ -660,13 +660,13 @@ The cardinality/total number of triangles in the triangle soup.--> that is especially useful to document those triangles for whose the projection is almost perpendicular. - + - + @@ -676,7 +676,7 @@ The cardinality/total number of triangles in the triangle soup.--> is reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -688,7 +688,7 @@ The cardinality/total number of triangles in the triangle soup.--> traversed according to the sequence in which vertices are indexed in triangles. - + @@ -697,7 +697,7 @@ The cardinality/total number of triangles in the triangle soup.--> The center of mass of each triangle. - + @@ -735,7 +735,7 @@ The cardinality/total number of triangles in the triangle soup.--> returned, which constitutes the first step of the volumetric_feature identification process. - + @@ -743,7 +743,7 @@ The cardinality/total number of triangles in the triangle soup.--> The array of keywords of feature_type dictionary. - + @@ -752,7 +752,7 @@ The cardinality/total number of triangles in the triangle soup.--> The array of values for each keyword of the feature_type dictionary. - + @@ -763,7 +763,7 @@ The cardinality/total number of triangles in the triangle soup.--> each feature triangle cluster belongs to. Keep in mind that not each feature is an object or proxy. - + @@ -771,7 +771,7 @@ The cardinality/total number of triangles in the triangle soup.--> The explicit identifier of features. - + @@ -793,7 +793,7 @@ The cardinality/total number of triangles in the triangle soup.--> Explicit identifier of the feature a sub-set of the feature_identifier in the parent group. - + @@ -801,7 +801,7 @@ The cardinality/total number of triangles in the triangle soup.--> Volume of the feature. NaN for non-watertight objects. - + @@ -813,7 +813,7 @@ The cardinality/total number of triangles in the triangle soup.--> Edge length of the oriented bounding box from largest to smallest value. - + @@ -823,7 +823,7 @@ The cardinality/total number of triangles in the triangle soup.--> Oriented bounding box aspect ratio. YX versus ZY or second-largest over largest and smallest over second largest. - + @@ -834,7 +834,7 @@ The cardinality/total number of triangles in the triangle soup.--> not necessarily has to be the center_of_mass of the hexahedrally-shaped sample/sample part. - + @@ -845,7 +845,7 @@ The cardinality/total number of triangles in the triangle soup.--> is to store the shape of the hexahedra for visualization. - + @@ -853,12 +853,12 @@ The cardinality/total number of triangles in the triangle soup.--> - + - + @@ -871,30 +871,30 @@ number_of_faces(NX_POSINT): vertex_identifier_offset(NX_UINT): face_identifier_offset(NX_UINT):--> - + - + - + - + - + @@ -903,7 +903,7 @@ face_identifier_offset(NX_UINT):--> Array of evaporation_identifier / ion_identifier which details which ions lie inside or on the surface of the feature. - + @@ -915,7 +915,7 @@ face_identifier_offset(NX_UINT):--> Total (count) of ions inside or on the surface of the feature relevant for normalization. NaN for non watertight objects. - + @@ -929,7 +929,7 @@ face_identifier_offset(NX_UINT):--> Count or weight which, when divided by total, yields the composition of this element, nuclide, or (molecular) ion within the volume of the feature/object. - + @@ -962,7 +962,7 @@ face_identifier_offset(NX_UINT):--> location considering that the spatial resolution of atom probe experiments is limited. - + @@ -971,7 +971,7 @@ face_identifier_offset(NX_UINT):--> The multiplicity whereby the ion position is accounted for when the ion is considered one which is a decorator of the interface. - + @@ -984,7 +984,7 @@ face_identifier_offset(NX_UINT):--> The four parameter :math:`ax + by + cz + d = 0` which define the plane. - + @@ -1013,12 +1013,12 @@ face_identifier_offset(NX_UINT):--> - + - + @@ -1027,7 +1027,7 @@ face_identifier_offset(NX_UINT):--> Direction of each vertex normal. - + @@ -1041,12 +1041,12 @@ face_identifier_offset(NX_UINT):--> * 1 - outer * 2 - inner - + - + @@ -1055,7 +1055,7 @@ face_identifier_offset(NX_UINT):--> Direction of each face normal. - + @@ -1069,18 +1069,18 @@ face_identifier_offset(NX_UINT):--> * 1 - outer * 2 - inner - + - + - + @@ -1090,7 +1090,7 @@ face_identifier_offset(NX_UINT):--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -1101,7 +1101,7 @@ face_identifier_offset(NX_UINT):--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + @@ -1129,7 +1129,7 @@ face_identifier_offset(NX_UINT):--> Position of the geometric center, which often is but not necessarily has to be the center_of_mass of the polyhedra. - + @@ -1139,13 +1139,13 @@ face_identifier_offset(NX_UINT):--> Integer which specifies the first index to be used for distinguishing ROI cylinder explicitly. - + - + @@ -1153,7 +1153,7 @@ face_identifier_offset(NX_UINT):--> The number of atoms in each ROI. - + @@ -1161,7 +1161,7 @@ face_identifier_offset(NX_UINT):--> The number of ions in each ROI. - + @@ -1170,7 +1170,7 @@ face_identifier_offset(NX_UINT):--> The orientation of the ROI defined via a vector which points along the cylinder axis and whose length is the height of the cylinder. - + @@ -1184,7 +1184,7 @@ face_identifier_offset(NX_UINT):--> In the direction of the ROI. - + @@ -1192,7 +1192,7 @@ face_identifier_offset(NX_UINT):--> Hashvalue using the following hashing rule :math:`H = Z + 256 * N`. - + @@ -1234,17 +1234,17 @@ face_identifier_offset(NX_UINT):--> - + - + - + diff --git a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml index de5680a967..f7f00a5dde 100644 --- a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml @@ -79,7 +79,7 @@ config--> ion in such a way that only the those elements are considered of which a (molecular) ion is assumed composed according to the NXion instances. - + @@ -118,17 +118,17 @@ config--> - + - + - + diff --git a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml index 5630291783..bd22c5f762 100644 --- a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml @@ -90,17 +90,17 @@ - + - + - + diff --git a/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml index 5f4b26836a..fde38f7810 100644 --- a/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml @@ -245,7 +245,7 @@ identifier(NX_UINT):--> recover usual spatial correlation statistics like the 1NN C-C spatial statistics. - + @@ -276,7 +276,7 @@ identifier(NX_UINT):--> iontypes to distinguish as possible targets. See additional comments under ion_query_isotope_vector_source. - + @@ -298,7 +298,8 @@ identifier(NX_UINT):--> Minimum value, increment, and maximum value of the histogram binning. - + + @@ -311,7 +312,8 @@ identifier(NX_UINT):--> Minimum value, increment, and maximum value of the histogram binning. - + + diff --git a/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml index be81d48063..7a3613508a 100644 --- a/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml @@ -65,7 +65,7 @@ n_bins_knn: | as it is specified in the configuration settings inside the specific config_filename that was used for this paraprobe-spatstat analysis. - + @@ -77,12 +77,12 @@ n_bins_knn: | Right boundary of the binning. - + - + @@ -90,7 +90,7 @@ n_bins_knn: | Cumulated not normalized by total counts. - + @@ -98,7 +98,7 @@ n_bins_knn: | Cumulated and normalized by total counts. - + @@ -111,12 +111,12 @@ n_bins_knn: | Right boundary of the binning. - + - + @@ -124,7 +124,7 @@ n_bins_knn: | Cumulated not normalized by total counts. - + @@ -132,7 +132,7 @@ n_bins_knn: | Cumulated and normalized by total counts. - + @@ -172,17 +172,17 @@ n_bins_knn: | - + - + - + diff --git a/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml index 3cb04dac60..f11888d77a 100644 --- a/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml @@ -184,7 +184,8 @@ Array of alpha values to use when alpha_value_choice is set_of_values or when alpha_value_choice is set_of_alpha_wrappings. - + + @@ -193,7 +194,8 @@ Array of offset values to use when alpha_value_choice is set_of_alpha_wrappings. The array of alpha_values and offset_values define a sequence of (alpha and offset value). - + + diff --git a/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml index fa2bbd8825..1e2d37f5f9 100644 --- a/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml @@ -121,7 +121,7 @@ for eventually performed preprocessing--> The bitfield of the mask. See :ref:`NXcs_filter_boolean_mask` for how this bitfield is to be interpreted. - + @@ -162,13 +162,13 @@ for eventually performed preprocessing--> - + - + @@ -179,7 +179,7 @@ for eventually performed preprocessing--> of vertices and a triple of vertex indices specifying each triangle. The total number of entries is n_f_tri * (1+1+3). - + @@ -213,7 +213,7 @@ for eventually performed preprocessing--> - + @@ -224,7 +224,7 @@ for eventually performed preprocessing--> of vertices and a triple of vertex indices specifying each triangle. The total number of entries is n_f_tet * (1+1+4). - + @@ -268,17 +268,17 @@ For the future as we may wish to wrap primitives other like triangles or polylin - + - + - + diff --git a/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml index dbfa7dc94c..b7151753c1 100644 --- a/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml @@ -82,7 +82,7 @@ Coordinate triplet of the corner that lays closests to the origin of the *paraprobe* coordinate system. - + @@ -91,7 +91,7 @@ Coordinate triplet of the corner that lays farthest away from the origin of the *paraprobe* coordinate system. - + @@ -111,7 +111,7 @@ Volume of each Voronoi cell. - + @@ -119,7 +119,7 @@ Which MPI process computed which Voronoi cell. - + @@ -127,7 +127,7 @@ Which OpenMP thread computed which Voronoi cell. - + @@ -137,7 +137,7 @@ for each polyhedron. This field can be used to interpret the concatenated vector with the individual values for the area of each face. - + @@ -162,7 +162,7 @@ Third, the sequence of vertex identifier which define the facet. Tuples encode faces faster than cells. - + @@ -175,7 +175,7 @@ thus correlate per-ion properties with the volume that each cell represents. - + @@ -188,7 +188,7 @@ that document contact in specific outer unit normal directions of the *aabb*. - + @@ -204,7 +204,7 @@ dim: (i,) # one would not need to constrain this but doing so communicates that x-axis of the *paraprobe* coordinate system. - + @@ -218,7 +218,7 @@ dim: (i,) # one would not need to constrain this but doing so communicates that of the *paraprobe* coordinate system. - + @@ -232,7 +232,7 @@ dim: (i,) # one would not need to constrain this but doing so communicates that y-axis of the *paraprobe* coordinate system. - + @@ -246,7 +246,7 @@ dim: (i,) # one would not need to constrain this but doing so communicates that of the *paraprobe* coordinate system. - + @@ -260,7 +260,7 @@ dim: (i,) # one would not need to constrain this but doing so communicates that z-axis of the *paraprobe* coordinate system. - + @@ -274,7 +274,7 @@ dim: (i,) # one would not need to constrain this but doing so communicates that *paraprobe* coordinate system. - + @@ -316,17 +316,17 @@ dim: (i,) # one would not need to constrain this but doing so communicates that - + - + - + diff --git a/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml index 2ac82f751a..7ea9f4f4bd 100644 --- a/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml @@ -78,7 +78,7 @@ symbols: The mask. The length of the mask is an integer multiple of bitdepth. In such case, padded bits are set to 0. - + diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml index 10609e371d..42b0fa9c9c 100644 --- a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml @@ -104,7 +104,7 @@ config--> Mass-to-charge-state-ratio values. - + @@ -115,7 +115,7 @@ config--> Three-dimensional reconstructed positions of the ions. Interleaved array of x, y, z positions in the specimen space. - + @@ -133,7 +133,7 @@ config--> 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. - + @@ -149,7 +149,7 @@ config--> - + @@ -193,17 +193,17 @@ config--> - + - + - + diff --git a/contributed_definitions/NXapm_ranging.nxdl.xml b/contributed_definitions/NXapm_ranging.nxdl.xml index ab3a8afafe..acc4bc87d7 100644 --- a/contributed_definitions/NXapm_ranging.nxdl.xml +++ b/contributed_definitions/NXapm_ranging.nxdl.xml @@ -61,7 +61,7 @@ Smallest, increment, and largest mass-to-charge-state ratio value. - + diff --git a/contributed_definitions/NXapm_reconstruction.nxdl.xml b/contributed_definitions/NXapm_reconstruction.nxdl.xml index 03f5ff7091..1de66d16b1 100644 --- a/contributed_definitions/NXapm_reconstruction.nxdl.xml +++ b/contributed_definitions/NXapm_reconstruction.nxdl.xml @@ -83,9 +83,7 @@ - + The nominal diameter of the specimen ROI which is measured in the experiment. The physical specimen cannot be measured completely @@ -96,7 +94,7 @@ typically in nm reconstruction space not detector coordinates Three-dimensional reconstructed positions of the ions. - + diff --git a/contributed_definitions/NXapm_volt_and_bowl.nxdl.xml b/contributed_definitions/NXapm_volt_and_bowl.nxdl.xml index f317e76cbc..df8c1ca1a9 100644 --- a/contributed_definitions/NXapm_volt_and_bowl.nxdl.xml +++ b/contributed_definitions/NXapm_volt_and_bowl.nxdl.xml @@ -54,7 +54,7 @@ result--> Raw time-of-flight data without corrections. - + @@ -62,7 +62,7 @@ result--> Calibrated time-of-flight. - + diff --git a/contributed_definitions/NXcg_alpha_complex.nxdl.xml b/contributed_definitions/NXcg_alpha_complex.nxdl.xml index b6a466bc58..9446cdd8b6 100644 --- a/contributed_definitions/NXcg_alpha_complex.nxdl.xml +++ b/contributed_definitions/NXcg_alpha_complex.nxdl.xml @@ -74,10 +74,8 @@ stating meter is a stronger constraint while m is the strongest constraint, mean - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/contributed_definitions/NXcg_cylinder_set.nxdl.xml b/contributed_definitions/NXcg_cylinder_set.nxdl.xml index e5bb83807a..f87f5f7ac3 100644 --- a/contributed_definitions/NXcg_cylinder_set.nxdl.xml +++ b/contributed_definitions/NXcg_cylinder_set.nxdl.xml @@ -52,7 +52,7 @@ cylinder could be constructed, but NXcylinder is easier to understand--> A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - + @@ -77,7 +77,7 @@ one should really better use NXquadric...--> Radii of the cylinder. - + @@ -88,7 +88,7 @@ one should really better use NXquadric...--> This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -99,7 +99,7 @@ one should really better use NXquadric...--> This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -108,7 +108,7 @@ one should really better use NXquadric...--> Lateral surface area - + @@ -116,7 +116,7 @@ one should really better use NXquadric...--> Area of the upper cap of each cylinder. - + @@ -124,7 +124,7 @@ one should really better use NXquadric...--> Area of the lower cap of each cylinder. - + @@ -133,7 +133,7 @@ one should really better use NXquadric...--> Sum of upper and lower cap areas and lateral surface area of each cylinder. - + diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml index e22a677c11..f613be7ecf 100644 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -48,7 +48,7 @@ redundant as there is NXcsg, and NXquadric but easier to understand--> Use if all ellipsoids in the set have the same half-axes. - + @@ -56,7 +56,7 @@ redundant as there is NXcsg, and NXquadric but easier to understand--> Half-axes radii of each ellipsoid. - + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml index 48610a31d2..a452dc99f5 100644 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -94,7 +94,7 @@ duplicate of an NXoff_geometry ?--> Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -105,7 +105,7 @@ duplicate of an NXoff_geometry ?--> Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -145,7 +145,7 @@ duplicate of an NXoff_geometry ?--> Integer identifier to distinguish all vertices explicitly. - + @@ -153,7 +153,7 @@ duplicate of an NXoff_geometry ?--> Integer used to distinguish all edges explicitly. - + @@ -161,7 +161,7 @@ duplicate of an NXoff_geometry ?--> Integer used to distinguish all faces explicitly. - + @@ -175,7 +175,7 @@ duplicate of an NXoff_geometry ?--> case vertices_are_unique is likely False. Naively here means that each vertex is stored even though many share the same positions. - + @@ -184,7 +184,7 @@ duplicate of an NXoff_geometry ?--> The edges are stored as pairs of vertex identifier. - + @@ -202,7 +202,7 @@ duplicate of an NXoff_geometry ?--> the vertex identifiers for the i-th face on the following index interval of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. - + @@ -234,7 +234,7 @@ duplicate of an NXoff_geometry ?--> * 1 - counter-clockwise (CCW) * 2 - clock-wise (CW) - + diff --git a/contributed_definitions/NXcg_grid.nxdl.xml b/contributed_definitions/NXcg_grid.nxdl.xml index 4d5aced5fe..894250e158 100644 --- a/contributed_definitions/NXcg_grid.nxdl.xml +++ b/contributed_definitions/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml index 40213352e3..26e307d082 100644 --- a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml index 8ea85fb981..e7569c6281 100644 --- a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -89,7 +89,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Qualifier for the shape of each hexahedron. - + @@ -100,7 +100,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> edges of the hexahedra. Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -112,7 +112,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> For the sake of explicitness quantities like length, width, and height should not be reported without specifying also the assumed reference frame. - + @@ -121,7 +121,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Qualifier often used to describe the extent of an object in the vertical direction assuming a specific coordinate system. - + @@ -129,7 +129,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Volume of each hexahedron. - + @@ -137,7 +137,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Total (surface) area (of all six faces) of each hexahedron. - + @@ -145,7 +145,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the six faces of each hexahedron. - + @@ -155,7 +155,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Specifies if the hexahedra represent cuboids or cubes eventually rotated ones but at least not too exotic six-faced polyhedra. - + @@ -165,7 +165,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> whether hexahedra are boxes whose primary edges are parallel to the axes of the coordinate system. - + diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml index bfb868c47d..3709be64d4 100644 --- a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml +++ b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml @@ -73,7 +73,7 @@ To specify which parallelogram is a rectangle. - + @@ -83,15 +83,13 @@ describes whether parallelograms are rectangles whose primary edges are parallel to the axes of the coordinate system. - + - + Combined storage of all primitives of all parallelograms. diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml index c2190590d0..5d8a15310b 100644 --- a/contributed_definitions/NXcg_point_set.nxdl.xml +++ b/contributed_definitions/NXcg_point_set.nxdl.xml @@ -54,7 +54,7 @@ Coordinates of the points. - + @@ -66,7 +66,7 @@ If the field time is needed contextualize the time_offset relative to which time values are defined. Alternative store timestamp. - + @@ -74,7 +74,7 @@ ISO8601 with local time zone offset for each point. - + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 95c157ce1e..c708108320 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -46,9 +46,7 @@ descriptors.--> - + Computational geometry description of a set of polygons in Euclidean space. @@ -100,7 +98,7 @@ somewhat redundant as there is NXoff_geometry but easier to understand For each polygon its accumulated length along its edges. - + @@ -112,7 +110,7 @@ somewhat redundant as there is NXoff_geometry but easier to understand edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -124,7 +122,7 @@ somewhat redundant as there is NXoff_geometry but easier to understand * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index b087b0c790..00eaec95ac 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -69,7 +69,7 @@ for clean graph-based descriptions of polyhedra.--> The number of faces for each polyhedron. Faces of adjoining polyhedra are counted for each polyhedron. - + @@ -77,7 +77,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of faces. - + @@ -91,7 +91,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge. - + diff --git a/contributed_definitions/NXcg_polyline_set.nxdl.xml b/contributed_definitions/NXcg_polyline_set.nxdl.xml index 64a002f86c..d075365882 100644 --- a/contributed_definitions/NXcg_polyline_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index e8cb457bc1..93b35cfefa 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index 8b12834749..58d4d57968 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -54,7 +54,7 @@ redundant as there is NXcsg, and NXquadric but easier to understand--> In the case that spheres have different radius use this instead of the radius field. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index 509347c515..34c5d8ca7c 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -44,7 +44,7 @@ Area of each of the four triangular faces of each tetrahedron. - + @@ -53,7 +53,7 @@ Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index 7d994eb3e9..fe215dd3ee 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -77,7 +77,7 @@ properties of triangles--> For each triangle values are reported via traversing the vertices in the sequence as these are defined. - + @@ -89,7 +89,7 @@ properties of triangles--> For each triangle values are reported for the angle opposite to the respective edges in the sequence how vertices are defined. - + diff --git a/contributed_definitions/NXcg_unit_normal_set.nxdl.xml b/contributed_definitions/NXcg_unit_normal_set.nxdl.xml index 21470b34f0..6da20e5488 100644 --- a/contributed_definitions/NXcg_unit_normal_set.nxdl.xml +++ b/contributed_definitions/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 494b92956e..97f1ebd1a5 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 94c9b891f2..10de965773 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -76,7 +76,7 @@ TODO: The relevant axes which span the tilt_angle need a cleaner description. - + @@ -84,7 +84,7 @@ The exposure time of single tilt images. - + @@ -93,7 +93,7 @@ The factor of enlargement of the apparent size, not the physical size, of an object. - + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 921663cef6..972ed60805 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -81,7 +81,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 46f8774235..01b9b74b55 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -94,7 +94,7 @@ The content of the mask. If padding is used, padding bits have to be set to 0. - + @@ -107,7 +107,7 @@ the conventions made for depends_on, so consult also the description of th content to which depends_on refers. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 9da91f9c04..9be27b32d4 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -83,7 +83,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -91,7 +91,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index 7f7fbdf77a..b339ae40a1 100644 --- a/contributed_definitions/NXdelocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -114,7 +114,7 @@ and the interpretation model that to consider carbon atoms or carbon ions--> with :math:`$Z$` the number of protons and :math:`$N$` the number of neutrons of the nuclide. For elements set :math:`$N$` to zero. - + @@ -124,7 +124,7 @@ and the interpretation model that to consider carbon atoms or carbon ions--> iontypes generated via ranging. The number of mark data per point is 1 in the case for atom probe. - + @@ -136,7 +136,7 @@ and the interpretation model that to consider carbon atoms or carbon ions--> positive integer values, specifically the multiplicity of the ion, according to the details of the weighting_method. - + diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_adf.nxdl.xml index 8d6649fda9..3f6002abcf 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_adf.nxdl.xml @@ -55,7 +55,7 @@ Annulus inner (first value) and outer (second value) half angle. - + diff --git a/contributed_definitions/NXem_base.nxdl.xml b/contributed_definitions/NXem_base.nxdl.xml index 2bbd89636b..7934eb06c1 100644 --- a/contributed_definitions/NXem_base.nxdl.xml +++ b/contributed_definitions/NXem_base.nxdl.xml @@ -28,9 +28,7 @@ considering what we learned from the diataxis workshop we write here a specification neither a how to nor a tutorial which explains all the context because we address here developers of software--> - + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. @@ -226,14 +224,12 @@ where scientists just store conventions without a default plot--> - +citation: doi ->why relevant, should be solved by RDMS--> A description of the material characterized in the experiment. Sample and specimen are threaded as de facto synonyms. @@ -343,9 +339,7 @@ just knowing that a sample was plasma cleaned is insufficient, maybe it was not if plasma cleaning is done outside the EM than its certainly history, if it happens inside the EM are the ibeam description capabilities not sufficient enough?--> - + (Measured) density of the specimen. diff --git a/contributed_definitions/NXem_conventions.nxdl.xml b/contributed_definitions/NXem_conventions.nxdl.xml index 1c948affc4..41321063b7 100644 --- a/contributed_definitions/NXem_conventions.nxdl.xml +++ b/contributed_definitions/NXem_conventions.nxdl.xml @@ -55,9 +55,7 @@ and they should whenever possible be as simple as possible and as few as possible to support users with understanding the content of the application definition.--> - + Conventions for rotations and coordinate systems to interpret crystal orientation and other data and results collected with electron microscopy research. diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml index d2d7456aaa..b00b7ea925 100644 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -22,9 +22,7 @@ # For further information, see http://www.nexusformat.org --> - + Base class for method-specific conventions EBSD. diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index 95a644b519..e9bd12b89a 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index 33c8b9cb3c..685aee0b67 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -358,7 +358,7 @@ pattern_available(NX_BOOLEAN): * 100 - Success * 255 - Unexpected errors - + @@ -380,7 +380,7 @@ pattern_available(NX_BOOLEAN): phase_identifier has as many entries as scan points and phase_matching has also as many entries as scan points. - + @@ -409,7 +409,7 @@ pattern_available(NX_BOOLEAN): the 1-th scan point, the n_sc - 1 th scan point and omitting tuples for those scan points with no phases according to n_phases_per_scan_point - + @@ -420,7 +420,7 @@ pattern_available(NX_BOOLEAN): how the phase_identifier and the phase_matching arrays have to be interpreted. See documentation of phase_identifier for further details. - + @@ -438,24 +438,19 @@ pattern_available(NX_BOOLEAN): - + - +to sample_reference_frame--> Calibrated center positions of each scan point in the sample surface reference system. - + @@ -507,7 +502,7 @@ to sample_reference_frame Descriptor values displaying the ROI. - + @@ -524,7 +519,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -537,7 +532,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml index 566664f845..41c196b8b9 100644 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -80,7 +80,7 @@ and Adrien Teutrie, Cecile Hebert (EPFL)--> Accumulated counts - + @@ -93,7 +93,7 @@ and Adrien Teutrie, Cecile Hebert (EPFL)--> Energy axis - + @@ -116,7 +116,7 @@ and Adrien Teutrie, Cecile Hebert (EPFL)--> Associated lower :math:`[e_{min}, e_{max}]` bounds of the energy which is assumed associated with this peak. - + @@ -132,7 +132,7 @@ and Adrien Teutrie, Cecile Hebert (EPFL)--> This can be a list of IUPAC notations for (the seldom) case that multiple lines are grouped with the same peak. - + @@ -147,7 +147,7 @@ and Adrien Teutrie, Cecile Hebert (EPFL)--> However, a collection of instances of NXpeak with individual NXion specified enables also to distinguish isotopic information. - + @@ -175,7 +175,7 @@ and Adrien Teutrie, Cecile Hebert (EPFL)--> where accumulated for each pixel which yields an element-specific EDS map. - + diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml index 9a9d6fd679..7051d4b0d4 100644 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -41,7 +41,7 @@ specialized to include EELS-specific post-processing--> - + @@ -59,7 +59,7 @@ specialized to include EELS-specific post-processing--> Energy loss. - + diff --git a/contributed_definitions/NXevent_data_apm.nxdl.xml b/contributed_definitions/NXevent_data_apm.nxdl.xml index 878a5c3ff0..002c112f94 100644 --- a/contributed_definitions/NXevent_data_apm.nxdl.xml +++ b/contributed_definitions/NXevent_data_apm.nxdl.xml @@ -100,7 +100,7 @@ and pulse_identifier exactly specifies the connection between when a pulse was issued relative to start and absolute in UTC. - + @@ -149,7 +149,7 @@ vector with two values one for the first and another one for the value from the 100000-th pulse onwards. The values of pulse_identifier are then [0, 99999] respectively. - + @@ -181,7 +181,7 @@ within ATO files. The ATO file format is used primarily by the atom probe groups of the GPM in Rouen, France. - + @@ -214,7 +214,7 @@ but for atom probe if at all the pulse-based implicit time is available--> sample base (furthest point along sample apex and holding assembly that is removable from the sample stage). - + @@ -234,7 +234,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -249,7 +249,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -264,7 +264,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index bd59185528..cd321bd171 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -66,7 +66,7 @@ Integer used to distinguish edges for explicit indexing. - + @@ -80,7 +80,7 @@ * 1 / state 0x01 is one-directional * 2 / state 0x02 is bi-directional - + @@ -96,7 +96,7 @@ stored such that the identifier of the source node is the first entry and the identifier of the target is the second entry in the pair. - + @@ -106,7 +106,7 @@ A human-readable qualifier which type or e.g. class instance the edge is an instance of. - + @@ -114,7 +114,7 @@ A human-readable label/caption/tag of each edge. - + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index d234097946..8cc242220b 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -91,7 +91,7 @@ Integer used to distinguish nodes for explicit indexing. - + @@ -103,7 +103,7 @@ Instances which are groups like :ref:`NXgraph_node_set` could have an is_a qualifier reading :ref:`NXgraph_node_set`. - + @@ -111,7 +111,7 @@ A human-readable label/caption/tag of each node. - + diff --git a/contributed_definitions/NXimage_c_set.nxdl.xml b/contributed_definitions/NXimage_c_set.nxdl.xml index c6837e47ab..5527498a23 100644 --- a/contributed_definitions/NXimage_c_set.nxdl.xml +++ b/contributed_definitions/NXimage_c_set.nxdl.xml @@ -80,7 +80,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the real part. - + @@ -88,7 +88,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the imaginary part. - + @@ -96,7 +96,7 @@ process information are composable from the NXimage_set base class--> Magnitude of the image intensity. - + @@ -104,7 +104,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along i direction. - + @@ -122,7 +122,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the real part. - + @@ -131,7 +131,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the imaginary part. - + @@ -140,7 +140,7 @@ process information are composable from the NXimage_set base class--> Magnitude of the image intensity. - + @@ -149,7 +149,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along j direction. - + @@ -162,7 +162,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along i direction. - + @@ -180,7 +180,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the real part. - + @@ -190,7 +190,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the imaginary part. - + @@ -200,7 +200,7 @@ process information are composable from the NXimage_set base class--> Magnitude of the image intensity. - + @@ -210,7 +210,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along k direction. - + @@ -223,7 +223,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along j direction. - + @@ -236,7 +236,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along i direction. - + @@ -254,7 +254,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the real part. - + @@ -263,7 +263,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the imaginary part. - + @@ -272,7 +272,7 @@ process information are composable from the NXimage_set base class--> Magnitude of the image intensity. - + @@ -281,7 +281,7 @@ process information are composable from the NXimage_set base class--> Image identifier - + @@ -294,7 +294,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along i direction. - + @@ -312,7 +312,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the real part. - + @@ -322,7 +322,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the imaginary part. - + @@ -332,7 +332,7 @@ process information are composable from the NXimage_set base class--> Magnitude of the image intensity. - + @@ -342,7 +342,7 @@ process information are composable from the NXimage_set base class--> Image identifier - + @@ -355,7 +355,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along j direction. - + @@ -368,7 +368,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along i direction. - + @@ -386,7 +386,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the real part. - + @@ -397,7 +397,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the imaginary part. - + @@ -408,7 +408,7 @@ process information are composable from the NXimage_set base class--> Magnitude of the image intensity. - + @@ -419,7 +419,7 @@ process information are composable from the NXimage_set base class--> Image identifier - + @@ -432,7 +432,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along k direction. - + @@ -445,7 +445,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along j direction. - + @@ -458,7 +458,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along i direction. - + diff --git a/contributed_definitions/NXimage_r_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml index 78f01002b7..b9012feea2 100644 --- a/contributed_definitions/NXimage_r_set.nxdl.xml +++ b/contributed_definitions/NXimage_r_set.nxdl.xml @@ -56,7 +56,7 @@ Image intensity values. - + @@ -64,7 +64,7 @@ Pixel coordinate center along x direction. - + @@ -82,7 +82,7 @@ Image intensity values. - + @@ -91,7 +91,7 @@ Pixel coordinate center along y direction. - + @@ -104,7 +104,7 @@ Pixel coordinate center along x direction. - + @@ -122,7 +122,7 @@ Image intensity values. - + @@ -132,7 +132,7 @@ Pixel coordinate center along z direction. - + @@ -145,7 +145,7 @@ Pixel coordinate center along y direction. - + @@ -158,7 +158,7 @@ Pixel coordinate center along x direction. - + @@ -176,7 +176,7 @@ Image intensity values. - + @@ -185,7 +185,7 @@ Image identifier - + @@ -198,7 +198,7 @@ Pixel coordinate center along x direction. - + @@ -216,7 +216,7 @@ Image intensity values. - + @@ -226,7 +226,7 @@ Image identifier - + @@ -239,7 +239,7 @@ Pixel coordinate center along y direction. - + @@ -252,7 +252,7 @@ Pixel coordinate center along x direction. - + @@ -270,7 +270,7 @@ Image intensity values. - + @@ -281,7 +281,7 @@ Image identifier - + @@ -294,7 +294,7 @@ Pixel coordinate center along z direction. - + @@ -307,7 +307,7 @@ Pixel coordinate center along y direction. - + @@ -320,7 +320,7 @@ Pixel coordinate center along x direction. - + diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml index 98919c2ed9..9bb45544f5 100644 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -118,7 +118,7 @@ In most cases usually one pattern is averaged by the detector for some amount of time and then reported as one pattern. - + @@ -126,7 +126,7 @@ Intensity of the diffraction pattern. - + @@ -149,7 +149,7 @@ while for _indices fastest to fast--> Pattern are enumerated starting from 0 to n_p - 1. - + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index 2f770a59a3..2bccedd822 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -2,9 +2,9 @@ - +interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_feature_set.nxdl.xml b/contributed_definitions/NXms_feature_set.nxdl.xml index 2f2010d0e6..90ff9ac3fb 100644 --- a/contributed_definitions/NXms_feature_set.nxdl.xml +++ b/contributed_definitions/NXms_feature_set.nxdl.xml @@ -63,10 +63,7 @@ TJLD: but not one for every molecule, i.e. all molecules and how their atoms wit TJLD: clearly there are two possibilities: either concatenate or make one NXms_feature_set for each molecule or component in the topology hierarchy TJLD: however the here proposed design generalizes the arbitrary (microstructural) features and computational geometry based coarse-grained representations--> - + Name (or link?) to another NXms_feature_set which defines features what are assumed as the parents/super_features of all members in this feature set. @@ -88,9 +85,7 @@ but with the additional benefit of a much richer geometrical description and the I can also imagine that materials engineers e.g. can reuse NXms_feature_set in an application definition by just then naming their group e.g. grains(NXms_feature_set) and use in the application definition either only the (material point), interface network, or volumetric description--> - + What is the best matching description how dimensional the feature is. @@ -101,20 +96,16 @@ TJLD: not needed because they assume everything is 3d - + How many features/members are in this set? - +TJLD: inherits from NXms_feature_set but would need to have no dimensionality--> The keywords of the dictionary of human-readable types of features. Using terms from a community-agreed upon controlled vocabulary, e.g. @@ -124,19 +115,17 @@ TJLD: inherits from NXms_feature_set but would need to have no dimensionality surface, thermal_groove_root, precipitate, dispersoid, pore, crack is recommended. - + - + The integer identifier used to resolve of which type each feature is, i.e. the values of the dictionary of human-readable types of features. - + @@ -148,7 +137,7 @@ TJLD: equivalent to the AtomGroups index specific features can be extracted as if they would be stored in an own group. - + @@ -159,7 +148,7 @@ TJLD: equivalent to the AtomGroups index described feature set are defined (implicitly from 0, to c-1 or via explicit identifier. - + @@ -185,19 +174,17 @@ end up as links--> Integer used to distinguish features for explicit indexing. - + - +but here NXms_feature_set instances--> Assumptions and parameter to arrive at geometric primitives to locate zero-dimensional/point-(like) features which are @@ -212,10 +199,7 @@ but here NXms_feature_set instances - + Assumptions and parameters to arrive at geometric primitives to locate one-dimensional/line-like features which are diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml index 0be3dc81e4..5e0f705959 100644 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -69,7 +69,7 @@ The direction along which orientations are projected. - + @@ -139,8 +139,7 @@ \@axis_x_indices: 0 \@axis_y_indices: 1--> - +tech partners oftentimes do not report to more than calibrated pixel position--> Inverse pole figure color code for each map coordinate. - + @@ -163,7 +161,7 @@ tech partners oftentimes do not report to more than calibrated pixel position Pixel center coordinate calibrated for step size along the z axis of the map. - + @@ -172,7 +170,7 @@ tech partners oftentimes do not report to more than calibrated pixel position Pixel center coordinate calibrated for step size along the y axis of the map. - + @@ -181,7 +179,7 @@ tech partners oftentimes do not report to more than calibrated pixel position Pixel center coordinate calibrated for step size along the x axis of the map. - + @@ -220,13 +218,11 @@ title:--> \@axis_x_indices: 0 \@axis_y_indices: 1--> - + Inverse pole figure color code for each map coordinate. - + @@ -236,7 +232,7 @@ hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! Pixel along the y-axis. - + @@ -245,7 +241,7 @@ hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! Pixel along the x-axis. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml index 90e4132bee..721aeca848 100644 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -118,7 +118,7 @@ check against v5.12--> TODO with MTex developers - + @@ -127,7 +127,7 @@ check against v5.12--> TODO with MTex developers - + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml index 3e9d11dd70..90c9ae1c18 100644 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -91,7 +91,7 @@ Euler angle representation of the kth-most maxima of the ODF in decreasing order of the intensity maximum. - + @@ -108,7 +108,7 @@ each location as specified for each location in the order and reported in the order of these locations. - + @@ -134,7 +134,7 @@ ODF intensity at probed locations relative to null model of a completely random texture. - + @@ -144,7 +144,7 @@ Pixel center angular position along the :math:`\varphi_1` direction. - + @@ -153,7 +153,7 @@ Pixel center angular position along the :math:`\varphi_2` direction. - + @@ -162,7 +162,7 @@ Pixel center angular position along the :math:`\Phi` direction. - + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml index 44db61d7b3..7425c8a829 100644 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -82,7 +82,7 @@ Pole figure intensity. - + @@ -92,7 +92,7 @@ Pixel center along y direction in the equatorial plane of a stereographic projection of the unit sphere. - + @@ -102,7 +102,7 @@ Pixel center along x direction in the equatorial plane of a stereographic projection of the unit sphere. - + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml index f44d34239a..390f039698 100644 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -193,7 +193,7 @@ ONE DIMENSIONAL FEATURES--> Identifier used for crystals for explicit indexing. - + @@ -209,13 +209,11 @@ ONE DIMENSIONAL FEATURES--> - + Identifier used for phase for explicit indexing. - + @@ -225,7 +223,7 @@ ONE DIMENSIONAL FEATURES--> True, if the crystal makes contact with the edge of the ROI, false otherwise. - + @@ -235,7 +233,7 @@ ONE DIMENSIONAL FEATURES--> crystal at probed positions (weighted by area of that position) versus the average disorientation of the crystal. - + @@ -244,17 +242,15 @@ ONE DIMENSIONAL FEATURES--> Calibrated area of surrounded by the polyline about each crystal. - + - +therefore here a compact and suggestion how to store such data--> Projections of grain or phase boundaries as typically sectioned with optical or electron microscopy characterization. @@ -274,7 +270,7 @@ i) Set of pair of crystals sharing an interface--> Set of pairs of crystal_identifier resolved via depends_on which are adjacent to each interface. - + @@ -292,7 +288,7 @@ i) Set of pair of crystals sharing an interface--> For 2D projections of 3D microstructural features a triple point is physically only the projection of a triple line. - + @@ -320,7 +316,7 @@ properties, descriptors--> much as possible with interpreting how and where the lines are located in the reference frame. - + @@ -338,18 +334,16 @@ properties, descriptors--> Identifier for each interface using explicit indexing. - + - +the explicit description often generating unnecessary information duplication--> Projections of triple lines as typically characterized with optical or electron microscopy. @@ -391,7 +385,7 @@ i) triplet of interface identifier--> Identifier for each triple point using explicit indexing. - + @@ -399,7 +393,7 @@ i) triplet of interface identifier--> Set of triple point identifiers. - + @@ -415,7 +409,7 @@ i) triplet of interface identifier--> Each triplet resolves which three interface projections the triple point connects. - + @@ -433,7 +427,7 @@ is assumed discretized via three polylines representing interfaces--> Triplet of identifier of polyline segments. Each triplet resolves which three segments of polyline segments the triple junction connects. - + diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index 24243000c5..9df738e196 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -304,11 +304,9 @@ when the specimen was prepared.--> - +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -685,27 +683,21 @@ exists: optional--> - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/contributed_definitions/NXoptical_system_em.nxdl.xml index 0611984a77..f908d19d42 100644 --- a/contributed_definitions/NXoptical_system_em.nxdl.xml +++ b/contributed_definitions/NXoptical_system_em.nxdl.xml @@ -66,10 +66,8 @@ work of the HMC EM glossary activities--> - + Beam current as measured relevant for the illumination of the specimen. Users should specify further details like how the beam current diff --git a/contributed_definitions/NXpeak.nxdl.xml b/contributed_definitions/NXpeak.nxdl.xml index 2c01e617e1..fd84d26efb 100644 --- a/contributed_definitions/NXpeak.nxdl.xml +++ b/contributed_definitions/NXpeak.nxdl.xml @@ -2,9 +2,9 @@ + Frequency with which the pulser fire(s). - + @@ -80,7 +71,7 @@ case very efficiently we go for with an array of length 1xn_ions (as a function of standing voltage). Otherwise, this field should not be present. - + @@ -89,16 +80,14 @@ case very efficiently we go for with an array of length 1xn_ions - +existence constraint is independent of other values.--> Pulsed voltage, in laser pulsing mode this field can be omitted. - + @@ -111,7 +100,7 @@ existence constraint is independent of other values. Absolute number of pulses starting from the beginning of the experiment. - + @@ -127,7 +116,7 @@ existence constraint is independent of other values. the case of local electrode atom probe (LEAP) instrument. Otherwise, the standing voltage applied to the sample, relative to system ground. - + @@ -162,7 +151,7 @@ existence constraint is independent of other values. Average energy of the laser at peak of each pulse. - + @@ -182,7 +171,7 @@ existence constraint is independent of other values. how the laser beam shines on the specimen, i.e. the mean vector is parallel to the laser propagation direction. - + @@ -197,7 +186,7 @@ existence constraint is independent of other values. Track time-dependent settings over the course of the measurement where the laser beam exits the focusing optics. - + @@ -212,7 +201,7 @@ existence constraint is independent of other values. Track time-dependent settings over the course of the measurement where the laser hits the specimen. - + diff --git a/contributed_definitions/NXrotation_set.nxdl.xml b/contributed_definitions/NXrotation_set.nxdl.xml index dd55e97e76..c29f3e3f8d 100644 --- a/contributed_definitions/NXrotation_set.nxdl.xml +++ b/contributed_definitions/NXrotation_set.nxdl.xml @@ -86,7 +86,7 @@ just how to rotate the object into the reference frame defined by depends_on--> An example of this most complex case is the description of the disorientation between crystals adjoining a hetero-phase boundary. - + @@ -112,7 +112,7 @@ just how to rotate the object into the reference frame defined by depends_on--> eventual inaccuracies just for the sake of reporting a simplified symmetrized description should be avoided. - + @@ -122,7 +122,7 @@ just how to rotate the object into the reference frame defined by depends_on--> crystal_symmetry and sample_symmetry. Rotations which should be interpreted as antipodal are not marked as such. - + @@ -135,7 +135,7 @@ just how to rotate the object into the reference frame defined by depends_on--> conventions behind depends_on to resolve which of the many Euler-angle conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. - + @@ -149,7 +149,7 @@ rotation_axis_angle(NX_NUMBER):--> True for all those value tuples which have assumed antipodal symmetry. False for all others. - + @@ -160,7 +160,7 @@ rotation_axis_angle(NX_NUMBER):--> and sample_symmetry. The supplementary field is_antipodal can be used to mark orientations with the antipodal property. - + @@ -173,7 +173,7 @@ rotation_axis_angle(NX_NUMBER):--> conventions behind depends_on to resolve which of the many Euler-angle conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. - + @@ -191,7 +191,7 @@ misorientation is not necessarily in the fundamental zone--> obeying symmetry operations for equivalent misorientations as defined by crystal_symmetry and sample_symmetry. - + @@ -201,7 +201,7 @@ misorientation is not necessarily in the fundamental zone--> Misorientation angular argument (eventually signed) following the same symmetry assumptions as expressed for the field misorientation_quaternion. - + @@ -210,7 +210,7 @@ misorientation is not necessarily in the fundamental zone--> Misorientation axis (normalized) and signed following the same symmetry assumptions as expressed for the field misorientation_angle. - + @@ -223,7 +223,7 @@ fundamental zone of SO3 for given crystal and sample symmetry--> obeying symmetry operations for equivalent misorientations as defined by crystal_symmetry and sample_symmetry. - + @@ -235,7 +235,7 @@ fundamental zone of SO3 for given crystal and sample symmetry--> following the same symmetry assumptions as expressed for the field disorientation_quaternion. - + @@ -244,7 +244,7 @@ fundamental zone of SO3 for given crystal and sample symmetry--> Disorientation axis (normalized) following the same symmetry assumptions as expressed for the field disorientation_angle. - + diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index e9d893e285..dd5f5246df 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -99,7 +99,7 @@ results for the object set--> For classical clustering algorithms this can for instance encode the cluster_identifier. - + @@ -108,7 +108,7 @@ results for the object set--> Matrix of categorical attribute data for each member in the set. - + @@ -141,7 +141,7 @@ when knowing total, noise, and unassigned.--> Array of numerical identifier of each feature. - + @@ -149,7 +149,7 @@ when knowing total, noise, and unassigned.--> Array of number of objects for each feature. - + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml index e6fee7c090..5b0df5fe90 100644 --- a/contributed_definitions/NXspectrum_set.nxdl.xml +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -96,7 +96,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Counts - + @@ -110,7 +110,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Coordinate along x direction. - + @@ -123,7 +123,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Energy axis - + @@ -142,7 +142,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Counts - + @@ -157,7 +157,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Coordinate along y direction. - + @@ -170,7 +170,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Coordinate along x direction. - + @@ -183,7 +183,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Energy axis - + @@ -202,7 +202,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Counts - + @@ -218,7 +218,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Coordinate along z direction. - + @@ -231,7 +231,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Coordinate along y direction. - + @@ -244,7 +244,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Coordinate along x direction. - + @@ -257,7 +257,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Energy axis - + @@ -281,7 +281,7 @@ base classes--> Counts - + @@ -295,7 +295,7 @@ base classes--> Scan point identifier - + @@ -308,7 +308,7 @@ base classes--> Energy axis - + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index 782a72893c..040adbdba9 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -143,7 +143,7 @@ The interpretation of this tilt should be specialized and thus detailed via the application definition. - + diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml index 0310e9f260..0f7da2bfa6 100644 --- a/contributed_definitions/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -40,7 +40,7 @@ symbols:--> second identifier. Setting min_incr_max to [90, 3, 99] will take each third identifier beginning from identifier 90 up to 99. - + From bb7f17a833bbd9ed2a5768878546fbd4bfa888bf Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 28 Feb 2024 15:42:40 +0100 Subject: [PATCH 0605/1012] Recompiled NXDLs from yaml using nyaml==0.0.9 --- contributed_definitions/NXaberration.nxdl.xml | 6 +- .../NXaberration_model.nxdl.xml | 6 +- .../NXaberration_model_ceos.nxdl.xml | 6 +- .../NXaberration_model_nion.nxdl.xml | 6 +- .../NXaperture_em.nxdl.xml | 6 +- contributed_definitions/NXapm.nxdl.xml | 35 ++++----- .../NXapm_paraprobe_results_nanochem.nxdl.xml | 22 ++---- .../NXcalibration.nxdl.xml | 6 +- .../NXcg_alpha_complex.nxdl.xml | 12 ++-- .../NXcg_cylinder_set.nxdl.xml | 22 +++--- .../NXcg_ellipsoid_set.nxdl.xml | 10 +-- .../NXcg_face_list_data_structure.nxdl.xml | 24 +++---- .../NXcg_geodesic_mesh.nxdl.xml | 6 +- contributed_definitions/NXcg_grid.nxdl.xml | 20 +++--- .../NXcg_half_edge_data_structure.nxdl.xml | 26 +++---- .../NXcg_hexahedron_set.nxdl.xml | 24 +++---- .../NXcg_marching_cubes.nxdl.xml | 6 +- .../NXcg_parallelogram_set.nxdl.xml | 14 ++-- .../NXcg_point_set.nxdl.xml | 12 ++-- .../NXcg_polygon_set.nxdl.xml | 16 ++--- .../NXcg_polyhedron_set.nxdl.xml | 12 ++-- .../NXcg_polyline_set.nxdl.xml | 12 ++-- .../NXcg_primitive_set.nxdl.xml | 26 +++---- contributed_definitions/NXcg_roi_set.nxdl.xml | 6 +- .../NXcg_sphere_set.nxdl.xml | 8 +-- .../NXcg_tetrahedron_set.nxdl.xml | 10 +-- .../NXcg_triangle_set.nxdl.xml | 10 +-- .../NXcg_triangulated_surface_mesh.nxdl.xml | 6 +- .../NXcg_unit_normal_set.nxdl.xml | 10 +-- contributed_definitions/NXchamber.nxdl.xml | 6 +- .../NXcomponent_em.nxdl.xml | 6 +- .../NXcoordinate_system.nxdl.xml | 12 ++-- .../NXcoordinate_system_set.nxdl.xml | 6 +- .../NXcorrector_cs.nxdl.xml | 12 ++-- .../NXcrystal_structure.nxdl.xml | 24 +++---- .../NXcs_computer.nxdl.xml | 6 +- contributed_definitions/NXcs_cpu_obj.nxdl.xml | 6 +- contributed_definitions/NXcs_cpu_sys.nxdl.xml | 6 +- .../NXcs_filter_boolean_mask.nxdl.xml | 10 +-- contributed_definitions/NXcs_gpu_obj.nxdl.xml | 6 +- contributed_definitions/NXcs_gpu_sys.nxdl.xml | 6 +- contributed_definitions/NXcs_io_obj.nxdl.xml | 6 +- contributed_definitions/NXcs_io_sys.nxdl.xml | 6 +- contributed_definitions/NXcs_mm_obj.nxdl.xml | 6 +- contributed_definitions/NXcs_mm_sys.nxdl.xml | 6 +- contributed_definitions/NXcs_prng.nxdl.xml | 6 +- .../NXcs_profiling.nxdl.xml | 6 +- .../NXcs_profiling_event.nxdl.xml | 10 +-- contributed_definitions/NXdeflector.nxdl.xml | 6 +- .../NXebeam_column.nxdl.xml | 4 +- contributed_definitions/NXem.nxdl.xml | 11 ++- contributed_definitions/NXem_adf.nxdl.xml | 8 +-- contributed_definitions/NXem_base.nxdl.xml | 27 +++---- .../NXem_conventions.nxdl.xml | 10 ++- .../NXem_conventions_ebsd.nxdl.xml | 10 ++- .../NXem_correlation.nxdl.xml | 14 ++-- contributed_definitions/NXem_ebsd.nxdl.xml | 33 ++++----- contributed_definitions/NXem_eds.nxdl.xml | 18 ++--- contributed_definitions/NXem_eels.nxdl.xml | 6 +- contributed_definitions/NXem_img.nxdl.xml | 6 +- contributed_definitions/NXem_method.nxdl.xml | 6 +- contributed_definitions/NXem_msr.nxdl.xml | 7 +- contributed_definitions/NXem_sim.nxdl.xml | 6 +- .../NXevent_data_em_set.nxdl.xml | 6 +- .../NXfabrication.nxdl.xml | 6 +- .../NXgraph_edge_set.nxdl.xml | 16 ++--- .../NXgraph_node_set.nxdl.xml | 12 ++-- contributed_definitions/NXgraph_root.nxdl.xml | 6 +- .../NXibeam_column.nxdl.xml | 6 +- contributed_definitions/NXidentifier.nxdl.xml | 6 +- .../NXimage_c_set.nxdl.xml | 72 +++++++++---------- .../NXimage_r_set.nxdl.xml | 48 ++++++------- .../NXimage_r_set_diff.nxdl.xml | 12 ++-- contributed_definitions/NXimage_set.nxdl.xml | 6 +- .../NXinteraction_vol_em.nxdl.xml | 6 +- contributed_definitions/NXion.nxdl.xml | 12 ++-- contributed_definitions/NXisocontour.nxdl.xml | 6 +- contributed_definitions/NXlens_em.nxdl.xml | 4 +- contributed_definitions/NXms.nxdl.xml | 12 ++-- .../NXms_feature_set.nxdl.xml | 50 +++++-------- contributed_definitions/NXms_ipf.nxdl.xml | 32 ++++----- contributed_definitions/NXms_ipf_set.nxdl.xml | 6 +- .../NXms_mtex_config.nxdl.xml | 10 +-- contributed_definitions/NXms_odf.nxdl.xml | 18 ++--- contributed_definitions/NXms_odf_set.nxdl.xml | 6 +- contributed_definitions/NXms_pf.nxdl.xml | 12 ++-- contributed_definitions/NXms_pf_set.nxdl.xml | 6 +- contributed_definitions/NXms_recon.nxdl.xml | 48 ++++++------- .../NXms_score_results.nxdl.xml | 24 +++---- .../NXoptical_system_em.nxdl.xml | 10 ++- contributed_definitions/NXpump.nxdl.xml | 6 +- contributed_definitions/NXroi.nxdl.xml | 6 +- .../NXrotation_set.nxdl.xml | 32 ++++----- contributed_definitions/NXscanbox_em.nxdl.xml | 10 ++- contributed_definitions/NXserialized.nxdl.xml | 6 +- .../NXspectrum_set.nxdl.xml | 38 +++++----- contributed_definitions/NXxrd.nxdl.xml | 6 +- contributed_definitions/NXxrd_pan.nxdl.xml | 6 +- contributed_definitions/nyaml/NXem.yaml | 4 +- contributed_definitions/nyaml/NXem_base.yaml | 2 +- 100 files changed, 601 insertions(+), 682 deletions(-) diff --git a/contributed_definitions/NXaberration.nxdl.xml b/contributed_definitions/NXaberration.nxdl.xml index 008fc157aa..da4ea10dee 100644 --- a/contributed_definitions/NXaberration.nxdl.xml +++ b/contributed_definitions/NXaberration.nxdl.xml @@ -2,9 +2,9 @@ - + Atom probe microscopes use controlled laser, voltage, or a combination of pulsing strategies to trigger the excitation @@ -1016,10 +1014,7 @@ 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)--> - + A place where details about the initial shape of the specimen can be stored. Ideally, here also data about the shape evolution @@ -1259,10 +1254,8 @@ term with epos files.--> - + Hit multiplicity. @@ -1324,10 +1317,8 @@ Relevant for ranging are the calibrated data, thats why only these - + Calibrated time-of-flight. @@ -1420,12 +1411,10 @@ numerically the same voltage-and-bowl correction results are obtained - +is needed how to document the reconstruction parameter.--> Different reconstruction protocols exist. Although these approaches are qualitatively similar, each protocol uses different parameters diff --git a/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml index 09dc6d2f3c..af808dc768 100644 --- a/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml @@ -2,9 +2,9 @@ - + A simple approach to describe the entire set of hexahedra when the main intention is to store the shape of the @@ -1938,27 +1936,21 @@ face_identifier_offset(NX_UINT):--> - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml index 205c83f7b8..2cd3adaf23 100644 --- a/contributed_definitions/NXcalibration.nxdl.xml +++ b/contributed_definitions/NXcalibration.nxdl.xml @@ -2,9 +2,9 @@ - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/contributed_definitions/NXcg_cylinder_set.nxdl.xml b/contributed_definitions/NXcg_cylinder_set.nxdl.xml index acf97b44e7..f87f5f7ac3 100644 --- a/contributed_definitions/NXcg_cylinder_set.nxdl.xml +++ b/contributed_definitions/NXcg_cylinder_set.nxdl.xml @@ -2,9 +2,9 @@ A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - + @@ -77,7 +77,7 @@ one should really better use NXquadric...--> Radii of the cylinder. - + @@ -88,7 +88,7 @@ one should really better use NXquadric...--> This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -99,7 +99,7 @@ one should really better use NXquadric...--> This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -108,7 +108,7 @@ one should really better use NXquadric...--> Lateral surface area - + @@ -116,7 +116,7 @@ one should really better use NXquadric...--> Area of the upper cap of each cylinder. - + @@ -124,7 +124,7 @@ one should really better use NXquadric...--> Area of the lower cap of each cylinder. - + @@ -133,7 +133,7 @@ one should really better use NXquadric...--> Sum of upper and lower cap areas and lateral surface area of each cylinder. - + diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml index 32d2c636be..f613be7ecf 100644 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -2,9 +2,9 @@ Use if all ellipsoids in the set have the same half-axes. - + @@ -56,7 +56,7 @@ redundant as there is NXcsg, and NXquadric but easier to understand--> Half-axes radii of each ellipsoid. - + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml index 54cce12794..a452dc99f5 100644 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -2,9 +2,9 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -105,7 +105,7 @@ duplicate of an NXoff_geometry ?--> Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -145,7 +145,7 @@ duplicate of an NXoff_geometry ?--> Integer identifier to distinguish all vertices explicitly. - + @@ -153,7 +153,7 @@ duplicate of an NXoff_geometry ?--> Integer used to distinguish all edges explicitly. - + @@ -161,7 +161,7 @@ duplicate of an NXoff_geometry ?--> Integer used to distinguish all faces explicitly. - + @@ -175,7 +175,7 @@ duplicate of an NXoff_geometry ?--> case vertices_are_unique is likely False. Naively here means that each vertex is stored even though many share the same positions. - + @@ -184,7 +184,7 @@ duplicate of an NXoff_geometry ?--> The edges are stored as pairs of vertex identifier. - + @@ -202,7 +202,7 @@ duplicate of an NXoff_geometry ?--> the vertex identifiers for the i-th face on the following index interval of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. - + @@ -234,7 +234,7 @@ duplicate of an NXoff_geometry ?--> * 1 - counter-clockwise (CCW) * 2 - clock-wise (CW) - + diff --git a/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml b/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml index 244290a81b..6314db3427 100644 --- a/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml +++ b/contributed_definitions/NXcg_geodesic_mesh.nxdl.xml @@ -2,9 +2,9 @@ Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml index 260f16e1bc..26e307d082 100644 --- a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml @@ -2,9 +2,9 @@ Qualifier for the shape of each hexahedron. - + @@ -100,7 +100,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> edges of the hexahedra. Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -112,7 +112,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> For the sake of explicitness quantities like length, width, and height should not be reported without specifying also the assumed reference frame. - + @@ -121,7 +121,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Qualifier often used to describe the extent of an object in the vertical direction assuming a specific coordinate system. - + @@ -129,7 +129,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Volume of each hexahedron. - + @@ -137,7 +137,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Total (surface) area (of all six faces) of each hexahedron. - + @@ -145,7 +145,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the six faces of each hexahedron. - + @@ -155,7 +155,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Specifies if the hexahedra represent cuboids or cubes eventually rotated ones but at least not too exotic six-faced polyhedra. - + @@ -165,7 +165,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> whether hexahedra are boxes whose primary edges are parallel to the axes of the coordinate system. - + diff --git a/contributed_definitions/NXcg_marching_cubes.nxdl.xml b/contributed_definitions/NXcg_marching_cubes.nxdl.xml index f04bdaad8a..4cc765fd82 100644 --- a/contributed_definitions/NXcg_marching_cubes.nxdl.xml +++ b/contributed_definitions/NXcg_marching_cubes.nxdl.xml @@ -2,9 +2,9 @@ - + Combined storage of all primitives of all parallelograms. diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml index bea36a1a98..5d8a15310b 100644 --- a/contributed_definitions/NXcg_point_set.nxdl.xml +++ b/contributed_definitions/NXcg_point_set.nxdl.xml @@ -2,9 +2,9 @@ - + Computational geometry description of a set of polygons in Euclidean space. @@ -100,7 +98,7 @@ somewhat redundant as there is NXoff_geometry but easier to understand For each polygon its accumulated length along its edges. - + @@ -112,7 +110,7 @@ somewhat redundant as there is NXoff_geometry but easier to understand edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -124,7 +122,7 @@ somewhat redundant as there is NXoff_geometry but easier to understand * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index af373d8212..00eaec95ac 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -2,9 +2,9 @@ The number of faces for each polyhedron. Faces of adjoining polyhedra are counted for each polyhedron. - + @@ -77,7 +77,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of faces. - + @@ -91,7 +91,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge. - + diff --git a/contributed_definitions/NXcg_polyline_set.nxdl.xml b/contributed_definitions/NXcg_polyline_set.nxdl.xml index 898a56acde..d075365882 100644 --- a/contributed_definitions/NXcg_polyline_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyline_set.nxdl.xml @@ -2,9 +2,9 @@ even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index ac451bdc66..93b35cfefa 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -2,9 +2,9 @@ Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_roi_set.nxdl.xml b/contributed_definitions/NXcg_roi_set.nxdl.xml index edbd5b2a53..69bc0042e5 100644 --- a/contributed_definitions/NXcg_roi_set.nxdl.xml +++ b/contributed_definitions/NXcg_roi_set.nxdl.xml @@ -2,9 +2,9 @@ In the case that spheres have different radius use this instead of the radius field. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index bc8b3e301e..34c5d8ca7c 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -2,9 +2,9 @@ For each triangle values are reported via traversing the vertices in the sequence as these are defined. - + @@ -89,7 +89,7 @@ properties of triangles--> For each triangle values are reported for the angle opposite to the respective edges in the sequence how vertices are defined. - + diff --git a/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml b/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml index 5aebe0d789..da55b25306 100644 --- a/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml +++ b/contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml @@ -2,9 +2,9 @@ Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/contributed_definitions/NXchamber.nxdl.xml b/contributed_definitions/NXchamber.nxdl.xml index b0712af128..f6cbac9137 100644 --- a/contributed_definitions/NXchamber.nxdl.xml +++ b/contributed_definitions/NXchamber.nxdl.xml @@ -2,9 +2,9 @@ Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/contributed_definitions/NXcs_computer.nxdl.xml index d9444aaff8..79a8accf15 100644 --- a/contributed_definitions/NXcs_computer.nxdl.xml +++ b/contributed_definitions/NXcs_computer.nxdl.xml @@ -2,9 +2,9 @@ - - - - - + + + + - + The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) which was used to generate this NeXus file instance. diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_adf.nxdl.xml index 92e784ee31..3f6002abcf 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_adf.nxdl.xml @@ -2,9 +2,9 @@ - + Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. @@ -54,11 +52,10 @@ make the default required, one example is e.g. a NeXus instance where scientists just store conventions without a default plot--> - - - - - + + + + @@ -219,14 +216,12 @@ where scientists just store conventions without a default plot--> - +citation: doi ->why relevant, should be solved by RDMS--> A description of the material characterized in the experiment. Sample and specimen are threaded as de facto synonyms. @@ -336,9 +331,7 @@ just knowing that a sample was plasma cleaned is insufficient, maybe it was not if plasma cleaning is done outside the EM than its certainly history, if it happens inside the EM are the ibeam description capabilities not sufficient enough?--> - + (Measured) density of the specimen. diff --git a/contributed_definitions/NXem_conventions.nxdl.xml b/contributed_definitions/NXem_conventions.nxdl.xml index e6faa8d54d..41321063b7 100644 --- a/contributed_definitions/NXem_conventions.nxdl.xml +++ b/contributed_definitions/NXem_conventions.nxdl.xml @@ -2,9 +2,9 @@ - + Conventions for rotations and coordinate systems to interpret crystal orientation and other data and results collected with electron microscopy research. diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml index 8a19f1e29b..b00b7ea925 100644 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -2,9 +2,9 @@ - + Base class for method-specific conventions EBSD. diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index 58c0f68255..e9bd12b89a 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -2,9 +2,9 @@ Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index 5d4250dc54..685aee0b67 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -2,9 +2,9 @@ + - +to sample_reference_frame--> Calibrated center positions of each scan point in the sample surface reference system. - + @@ -507,7 +502,7 @@ to sample_reference_frame Descriptor values displaying the ROI. - + @@ -524,7 +519,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -537,7 +532,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml index 68db8267cb..bd93d61efe 100644 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -2,9 +2,9 @@ Accumulated counts - + @@ -93,7 +93,7 @@ and Adrien Teutrie, Cecile Hebert (EPFL)--> Energy axis - + @@ -116,7 +116,7 @@ and Adrien Teutrie, Cecile Hebert (EPFL)--> Associated lower :math:`[e_{min}, e_{max}]` bounds of the energy which is assumed associated with this peak. - + @@ -132,7 +132,7 @@ and Adrien Teutrie, Cecile Hebert (EPFL)--> This can be a list of IUPAC notations for (the seldom) case that multiple lines are grouped with the same peak. - + @@ -147,7 +147,7 @@ and Adrien Teutrie, Cecile Hebert (EPFL)--> However, a collection of instances of NXpeak with individual NXion specified enables also to distinguish isotopic information. - + @@ -194,7 +194,7 @@ therefore we use for now the--> Associated :math:`[e_{min}, e_{max}]` bounds of the energy range for which spectrum counts have been accumulated. - + @@ -205,7 +205,7 @@ therefore we use for now the--> where accumulated for each pixel which yields an element-specific EDS map. - + diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml index b4e1928dfe..4ddef01176 100644 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ b/contributed_definitions/NXem_eels.nxdl.xml @@ -2,9 +2,9 @@ Image intensity of the real part. - + @@ -88,7 +88,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the imaginary part. - + @@ -96,7 +96,7 @@ process information are composable from the NXimage_set base class--> Magnitude of the image intensity. - + @@ -104,7 +104,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along i direction. - + @@ -122,7 +122,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the real part. - + @@ -131,7 +131,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the imaginary part. - + @@ -140,7 +140,7 @@ process information are composable from the NXimage_set base class--> Magnitude of the image intensity. - + @@ -149,7 +149,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along j direction. - + @@ -162,7 +162,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along i direction. - + @@ -180,7 +180,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the real part. - + @@ -190,7 +190,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the imaginary part. - + @@ -200,7 +200,7 @@ process information are composable from the NXimage_set base class--> Magnitude of the image intensity. - + @@ -210,7 +210,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along k direction. - + @@ -223,7 +223,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along j direction. - + @@ -236,7 +236,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along i direction. - + @@ -254,7 +254,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the real part. - + @@ -263,7 +263,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the imaginary part. - + @@ -272,7 +272,7 @@ process information are composable from the NXimage_set base class--> Magnitude of the image intensity. - + @@ -281,7 +281,7 @@ process information are composable from the NXimage_set base class--> Image identifier - + @@ -294,7 +294,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along i direction. - + @@ -312,7 +312,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the real part. - + @@ -322,7 +322,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the imaginary part. - + @@ -332,7 +332,7 @@ process information are composable from the NXimage_set base class--> Magnitude of the image intensity. - + @@ -342,7 +342,7 @@ process information are composable from the NXimage_set base class--> Image identifier - + @@ -355,7 +355,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along j direction. - + @@ -368,7 +368,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along i direction. - + @@ -386,7 +386,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the real part. - + @@ -397,7 +397,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the imaginary part. - + @@ -408,7 +408,7 @@ process information are composable from the NXimage_set base class--> Magnitude of the image intensity. - + @@ -419,7 +419,7 @@ process information are composable from the NXimage_set base class--> Image identifier - + @@ -432,7 +432,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along k direction. - + @@ -445,7 +445,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along j direction. - + @@ -458,7 +458,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along i direction. - + diff --git a/contributed_definitions/NXimage_r_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml index b57afc774a..b9012feea2 100644 --- a/contributed_definitions/NXimage_r_set.nxdl.xml +++ b/contributed_definitions/NXimage_r_set.nxdl.xml @@ -2,9 +2,9 @@ Pattern are enumerated starting from 0 to n_p - 1. - + diff --git a/contributed_definitions/NXimage_set.nxdl.xml b/contributed_definitions/NXimage_set.nxdl.xml index 476b24d2ba..1aed5116e6 100644 --- a/contributed_definitions/NXimage_set.nxdl.xml +++ b/contributed_definitions/NXimage_set.nxdl.xml @@ -2,9 +2,9 @@ - +interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_feature_set.nxdl.xml b/contributed_definitions/NXms_feature_set.nxdl.xml index ba91d50d65..8217ad80ef 100644 --- a/contributed_definitions/NXms_feature_set.nxdl.xml +++ b/contributed_definitions/NXms_feature_set.nxdl.xml @@ -2,9 +2,9 @@ - + Name (or link?) to another NXms_feature_set which defines features what are assumed as the parents/super_features of all members in this feature set. @@ -88,9 +85,7 @@ but with the additional benefit of a much richer geometrical description and the I can also imagine that materials engineers e.g. can reuse NXms_feature_set in an application definition by just then naming their group e.g. grains(NXms_feature_set) and use in the application definition either only the (material point), interface network, or volumetric description--> - + What is the best matching description how dimensional the feature is. @@ -101,20 +96,16 @@ TJLD: not needed because they assume everything is 3d - + How many features/members are in this set? - +TJLD: inherits from NXms_feature_set but would need to have no dimensionality--> The keywords of the dictionary of human-readable types of features. Using terms from a community-agreed upon controlled vocabulary, e.g. @@ -124,19 +115,17 @@ TJLD: inherits from NXms_feature_set but would need to have no dimensionality surface, thermal_groove_root, precipitate, dispersoid, pore, crack is recommended. - + - + The integer identifier used to resolve of which type each feature is, i.e. the values of the dictionary of human-readable types of features. - + @@ -148,7 +137,7 @@ TJLD: equivalent to the AtomGroups index specific features can be extracted as if they would be stored in an own group. - + @@ -159,7 +148,7 @@ TJLD: equivalent to the AtomGroups index described feature set are defined (implicitly from 0, to c-1 or via explicit identifier. - + @@ -185,19 +174,17 @@ end up as links--> Integer used to distinguish features for explicit indexing. - + - +but here NXms_feature_set instances--> Assumptions and parameter to arrive at geometric primitives to locate zero-dimensional/point-(like) features which are @@ -212,10 +199,7 @@ but here NXms_feature_set instances - + Assumptions and parameters to arrive at geometric primitives to locate one-dimensional/line-like features which are diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml index 49568b0ac1..5e0f705959 100644 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -2,9 +2,9 @@ - +tech partners oftentimes do not report to more than calibrated pixel position--> Inverse pole figure color code for each map coordinate. - + @@ -163,7 +161,7 @@ tech partners oftentimes do not report to more than calibrated pixel position Pixel center coordinate calibrated for step size along the z axis of the map. - + @@ -172,7 +170,7 @@ tech partners oftentimes do not report to more than calibrated pixel position Pixel center coordinate calibrated for step size along the y axis of the map. - + @@ -181,7 +179,7 @@ tech partners oftentimes do not report to more than calibrated pixel position Pixel center coordinate calibrated for step size along the x axis of the map. - + @@ -220,13 +218,11 @@ title:--> \@axis_x_indices: 0 \@axis_y_indices: 1--> - + Inverse pole figure color code for each map coordinate. - + @@ -236,7 +232,7 @@ hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! Pixel along the y-axis. - + @@ -245,7 +241,7 @@ hehe, but can be larger than one but could also be an NX_DIMENSIONLESS ! Pixel along the x-axis. - + diff --git a/contributed_definitions/NXms_ipf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml index 776eb0a6c9..7f490dd84b 100644 --- a/contributed_definitions/NXms_ipf_set.nxdl.xml +++ b/contributed_definitions/NXms_ipf_set.nxdl.xml @@ -2,9 +2,9 @@ TODO with MTex developers - + @@ -127,7 +127,7 @@ check against v5.12--> TODO with MTex developers - + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml index 988034557d..90c9ae1c18 100644 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -2,9 +2,9 @@ Identifier used for crystals for explicit indexing. - + @@ -209,13 +209,11 @@ ONE DIMENSIONAL FEATURES--> - + Identifier used for phase for explicit indexing. - + @@ -225,7 +223,7 @@ ONE DIMENSIONAL FEATURES--> True, if the crystal makes contact with the edge of the ROI, false otherwise. - + @@ -235,7 +233,7 @@ ONE DIMENSIONAL FEATURES--> crystal at probed positions (weighted by area of that position) versus the average disorientation of the crystal. - + @@ -244,17 +242,15 @@ ONE DIMENSIONAL FEATURES--> Calibrated area of surrounded by the polyline about each crystal. - + - +therefore here a compact and suggestion how to store such data--> Projections of grain or phase boundaries as typically sectioned with optical or electron microscopy characterization. @@ -274,7 +270,7 @@ i) Set of pair of crystals sharing an interface--> Set of pairs of crystal_identifier resolved via depends_on which are adjacent to each interface. - + @@ -292,7 +288,7 @@ i) Set of pair of crystals sharing an interface--> For 2D projections of 3D microstructural features a triple point is physically only the projection of a triple line. - + @@ -320,7 +316,7 @@ properties, descriptors--> much as possible with interpreting how and where the lines are located in the reference frame. - + @@ -338,18 +334,16 @@ properties, descriptors--> Identifier for each interface using explicit indexing. - + - +the explicit description often generating unnecessary information duplication--> Projections of triple lines as typically characterized with optical or electron microscopy. @@ -391,7 +385,7 @@ i) triplet of interface identifier--> Identifier for each triple point using explicit indexing. - + @@ -399,7 +393,7 @@ i) triplet of interface identifier--> Set of triple point identifiers. - + @@ -415,7 +409,7 @@ i) triplet of interface identifier--> Each triplet resolves which three interface projections the triple point connects. - + @@ -433,7 +427,7 @@ is assumed discretized via three polylines representing interfaces--> Triplet of identifier of polyline segments. Each triplet resolves which three segments of polyline segments the triple junction connects. - + diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index 224aa030d6..aa7615dda4 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -2,9 +2,9 @@ - +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -694,27 +692,21 @@ exists: optional--> - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/contributed_definitions/NXoptical_system_em.nxdl.xml index 8abc23abfa..f908d19d42 100644 --- a/contributed_definitions/NXoptical_system_em.nxdl.xml +++ b/contributed_definitions/NXoptical_system_em.nxdl.xml @@ -2,9 +2,9 @@ - + Beam current as measured relevant for the illumination of the specimen. Users should specify further details like how the beam current diff --git a/contributed_definitions/NXpump.nxdl.xml b/contributed_definitions/NXpump.nxdl.xml index 328a8cb635..45a86edada 100644 --- a/contributed_definitions/NXpump.nxdl.xml +++ b/contributed_definitions/NXpump.nxdl.xml @@ -2,9 +2,9 @@ An example of this most complex case is the description of the disorientation between crystals adjoining a hetero-phase boundary. - + @@ -112,7 +112,7 @@ just how to rotate the object into the reference frame defined by depends_on--> eventual inaccuracies just for the sake of reporting a simplified symmetrized description should be avoided. - + @@ -122,7 +122,7 @@ just how to rotate the object into the reference frame defined by depends_on--> crystal_symmetry and sample_symmetry. Rotations which should be interpreted as antipodal are not marked as such. - + @@ -135,7 +135,7 @@ just how to rotate the object into the reference frame defined by depends_on--> conventions behind depends_on to resolve which of the many Euler-angle conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. - + @@ -149,7 +149,7 @@ rotation_axis_angle(NX_NUMBER):--> True for all those value tuples which have assumed antipodal symmetry. False for all others. - + @@ -160,7 +160,7 @@ rotation_axis_angle(NX_NUMBER):--> and sample_symmetry. The supplementary field is_antipodal can be used to mark orientations with the antipodal property. - + @@ -173,7 +173,7 @@ rotation_axis_angle(NX_NUMBER):--> conventions behind depends_on to resolve which of the many Euler-angle conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. - + @@ -191,7 +191,7 @@ misorientation is not necessarily in the fundamental zone--> obeying symmetry operations for equivalent misorientations as defined by crystal_symmetry and sample_symmetry. - + @@ -201,7 +201,7 @@ misorientation is not necessarily in the fundamental zone--> Misorientation angular argument (eventually signed) following the same symmetry assumptions as expressed for the field misorientation_quaternion. - + @@ -210,7 +210,7 @@ misorientation is not necessarily in the fundamental zone--> Misorientation axis (normalized) and signed following the same symmetry assumptions as expressed for the field misorientation_angle. - + @@ -223,7 +223,7 @@ fundamental zone of SO3 for given crystal and sample symmetry--> obeying symmetry operations for equivalent misorientations as defined by crystal_symmetry and sample_symmetry. - + @@ -235,7 +235,7 @@ fundamental zone of SO3 for given crystal and sample symmetry--> following the same symmetry assumptions as expressed for the field disorientation_quaternion. - + @@ -244,7 +244,7 @@ fundamental zone of SO3 for given crystal and sample symmetry--> Disorientation axis (normalized) following the same symmetry assumptions as expressed for the field disorientation_angle. - + diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/contributed_definitions/NXscanbox_em.nxdl.xml index f57ca335f6..46377479c2 100644 --- a/contributed_definitions/NXscanbox_em.nxdl.xml +++ b/contributed_definitions/NXscanbox_em.nxdl.xml @@ -2,9 +2,9 @@ + url: https://em-glossary.vercel.app/term/em-dwell-time--> Time period during which the beam remains at one position. diff --git a/contributed_definitions/NXserialized.nxdl.xml b/contributed_definitions/NXserialized.nxdl.xml index 2a8bc4697f..fda0769482 100644 --- a/contributed_definitions/NXserialized.nxdl.xml +++ b/contributed_definitions/NXserialized.nxdl.xml @@ -2,9 +2,9 @@ Counts - + @@ -109,7 +109,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Energy axis - + @@ -128,7 +128,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Counts - + @@ -142,7 +142,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Coordinate along x direction. - + @@ -155,7 +155,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Energy axis - + @@ -174,7 +174,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Counts - + @@ -189,7 +189,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Coordinate along y direction. - + @@ -202,7 +202,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Coordinate along x direction. - + @@ -215,7 +215,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Energy axis - + @@ -234,7 +234,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Counts - + @@ -250,7 +250,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Coordinate along z direction. - + @@ -263,7 +263,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Coordinate along y direction. - + @@ -276,7 +276,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Coordinate along x direction. - + @@ -289,7 +289,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Energy axis - + @@ -313,7 +313,7 @@ base classes--> Counts - + @@ -327,7 +327,7 @@ base classes--> Scan point identifier - + @@ -340,7 +340,7 @@ base classes--> Energy axis - + diff --git a/contributed_definitions/NXxrd.nxdl.xml b/contributed_definitions/NXxrd.nxdl.xml index 3c987ba561..7c55fd9de1 100644 --- a/contributed_definitions/NXxrd.nxdl.xml +++ b/contributed_definitions/NXxrd.nxdl.xml @@ -2,9 +2,9 @@ - + Nominal current of the heater. diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml index b1a4560038..3b30684fd3 100644 --- a/contributed_definitions/NXevent_data_em.nxdl.xml +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -165,8 +165,8 @@ - + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index b0a407330f..f9f537938c 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -155,8 +155,8 @@ - - - + diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml index 3ef114ef49..da744a100c 100644 --- a/contributed_definitions/nyaml/NXapm.yaml +++ b/contributed_definitions/nyaml/NXapm.yaml @@ -926,7 +926,7 @@ NXapm(NXobject): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): - (NXion): + ionID(NXion): exists: [min, 1, max, 256] nuclide_hash(NX_UINT): charge_state(NX_INT): From e31a54b1db66ef90b4d3bb5a0dee10b3196b588b Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 29 Feb 2024 10:20:36 +0100 Subject: [PATCH 0608/1012] readd NXsource/pulse_energy --- base_classes/NXsource.nxdl.xml | 5 +++++ base_classes/nyaml/NXsource.yaml | 11 ++++++++++- 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/base_classes/NXsource.nxdl.xml b/base_classes/NXsource.nxdl.xml index a7d009fe3a..23af0f81ff 100644 --- a/base_classes/NXsource.nxdl.xml +++ b/base_classes/NXsource.nxdl.xml @@ -235,6 +235,11 @@ The wavelength of the radiation emitted by the source. + + + For pulsed sources, the energy of a single pulse. + + For pulsed sources, the pulse energy divided diff --git a/base_classes/nyaml/NXsource.yaml b/base_classes/nyaml/NXsource.yaml index 8ab666eb30..e2775b2491 100644 --- a/base_classes/nyaml/NXsource.yaml +++ b/base_classes/nyaml/NXsource.yaml @@ -138,6 +138,10 @@ NXsource(NXobject): unit: NX_WAVELENGTH doc: | The wavelength of the radiation emitted by the source. + pulse_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + For pulsed sources, the energy of a single pulse. peak_power(NX_FLOAT): unit: NX_POWER doc: | @@ -189,7 +193,7 @@ NXsource(NXobject): other component groups. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 305c1742126ff6c2a4b485ba827159ce8520f1e627abe11af0a738406de3c9b2 +# da3e78fa22a382a03ea3bf35a039da332f7ce5b1590f4b8a1c7419aef89d8ba5 # # # - - + + Each ``AXISNAME_indices`` attribute indicates the dependency relationship of the ``AXISNAME`` field (where ``AXISNAME`` diff --git a/base_classes/NXsensor.nxdl.xml b/base_classes/NXsensor.nxdl.xml index 3e01482037..f1c552fd8f 100644 --- a/base_classes/NXsensor.nxdl.xml +++ b/base_classes/NXsensor.nxdl.xml @@ -123,7 +123,7 @@ - same dimensions as "value" (may be a vector) - + @@ -132,7 +132,7 @@ - same dimensions as "value" (may be a vector) - + From 5740f4f6cb2bce8337933c660d643d64a5073d03 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 29 Feb 2024 13:08:06 +0100 Subject: [PATCH 0610/1012] Clarifying situation with NXem_base --- contributed_definitions/NXem_base.nxdl.xml | 8 ++++---- contributed_definitions/nyaml/NXem.yaml | 8 ++++---- contributed_definitions/nyaml/NXem_base.yaml | 6 ++++-- 3 files changed, 12 insertions(+), 10 deletions(-) diff --git a/contributed_definitions/NXem_base.nxdl.xml b/contributed_definitions/NXem_base.nxdl.xml index 085a03f7a9..34fc41becc 100644 --- a/contributed_definitions/NXem_base.nxdl.xml +++ b/contributed_definitions/NXem_base.nxdl.xml @@ -53,11 +53,11 @@ where scientists just store conventions without a default plot--> - - - - + + The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) which was used to generate this NeXus file instance. diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index 520314c0b0..1575b6f094 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -56,10 +56,10 @@ NXem(NXem_base): definition(NX_CHAR): \@version(NX_CHAR): enumeration: [NXem] - # each NeXus file instance should have a default plot - # however as there are cases when this cannot be assured we cannot - # make the default required, one example is e.g. a NeXus instance - # where scientists just store conventions without a default plot + # each NeXus file instance should have a default plot + # however as there are cases when this cannot be assured we cannot + # make the default required, one example is e.g. a NeXus instance + # where scientists just store conventions without a default plot profiling(NXcs_profiling): exists: recommended doc: | diff --git a/contributed_definitions/nyaml/NXem_base.yaml b/contributed_definitions/nyaml/NXem_base.yaml index 377d894542..44c98f96e0 100644 --- a/contributed_definitions/nyaml/NXem_base.yaml +++ b/contributed_definitions/nyaml/NXem_base.yaml @@ -30,8 +30,10 @@ NXem_base(NXobject): # but should inherit from NXroot (NXentry): # means ENTRY(NXentry) definition(NX_CHAR): \@version(NX_CHAR): - enumeration: [NXem] - cs_profiling(NXcs_profiling): + # enumeration: [NXem] + # as NXem_base is a blue-print for an appdef written as a base class because + # no other place for this in NeXus right now, NXem is the appdef along the lines of this blue-print + profiling(NXcs_profiling): doc: | The configuration of the I/O writer software (e.g. `pynxtools `_) which was used to generate this NeXus file instance. From 5fc31d00849c89e77a8eccf2c50b8fc726a8b57d Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 29 Feb 2024 13:22:54 +0100 Subject: [PATCH 0611/1012] Dropped NXem_base to not immediately be a competitor to NXem, all suggestions and reviews and feedback from community should target NXem first before thinking about offsprings --- contributed_definitions/NXem_base.nxdl.xml | 376 ------------------- contributed_definitions/nyaml/NXem_base.yaml | 297 --------------- 2 files changed, 673 deletions(-) delete mode 100644 contributed_definitions/NXem_base.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXem_base.yaml diff --git a/contributed_definitions/NXem_base.nxdl.xml b/contributed_definitions/NXem_base.nxdl.xml deleted file mode 100644 index 34fc41becc..0000000000 --- a/contributed_definitions/NXem_base.nxdl.xml +++ /dev/null @@ -1,376 +0,0 @@ - - - - - - - - Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. - - This base class combines a method-specific and technical-design-level base class - instance to provide a template for storing parameterized descriptions of - pieces of information collected when performing electron microscopy research. - - The base class here shows all possible branches without making any statements - as to which of these have to be used in an instance. Thereby, the base class - provides a template how to name and structure concepts in a hierarchy - to support finding information and reducing the need for renaming and - restructuring information for a research field where many scientists perform - very specific research but who all also share commonalities like usage of - controlled electron beams, a focus on studies of electron beam matter interaction - to explore physical mechanisms and phenomena, or the desire to characterize materials - using electron microscopy. - - - - - - - - - - The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) - which was used to generate this NeXus file instance. - - - - A collection of all programs and libraries which are considered relevant - to understand with which software tools this NeXus file instance was - generated. Ideally, to enable a binary recreation from the input data. - - Examples include the name and version of the libraries used to write the - instance. Ideally, the software which writes these NXprogram instances - also includes the version of the set of NeXus classes i.e. the specific - set of base classes, application definitions, and contributed definitions - with which the here described concepts can be resolved. - - For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ - which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ - research data management system, it makes sense to store e.g. the GitHub - repository commit and respective submodule references used. - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - An experiment should be understood in that this can be an experiment - in reality or a computer simulation because also the latter is an - experiment (see the Cambridge Dictionary experiment: - *a test done in order to find out something, eg if an idea is correct*). - - The identifier is usually issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments/simulations to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to parameterize their description of the - experiment by using the respective base classes instead of writing prose - into this field. - - The reason is that such free-text field is difficult to machine-interpret. - The motivation behind keeping this field for now is to learn through - the information entered in this field in how far the current base - classes are incomplete. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval via setting both - a start_time and an end_time because this enables software tools and - users to collect a more detailed bookkeeping of the experiment. - - The user should be aware that even with having both time instances specified, - it may not be possible to infer how long the experiment took or for how - long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps start_time and end_time - in :ref:`NXevent_data_em` instances. - - - - - ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. See docstring of the start_time field - to see how the start_time and end_time should be used together. - - - - - - Possibility to store a collection of serialized resources - that are associated with the experiment. - - An example how to use this set could be to document - from which files generated by software of technology partners - the information in an instance of NXem was filled. - - If resources from technology partners would also be documented - semantically annotated there would not even be a necessity to - copy over specific information in NeXus files as one could write - a inference and information/fact/knowledge retrieval algorithm whereby - a specific piece of information that is related to an experiment or simulation - is just read directly from the respective file of the technology partner. - - The reason why currently this works convincingly in hardly any research - data management system is the strong heterogeneity of the information contained - in such files and the fact that often context and documentation specifically - rich semantic documentation and contextualization is missing. - - - - - - Contact information and eventually details of at least one person - who performed or was involved in the session. This can be the - principle investigator who performed this experiment or the student - who performed the simulation. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Service as another mean of identification of a user than by the name. - Examples could be details about an ORCID or social media account of - the user. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope, student, postdoc, principle investigator, or guest - are common examples. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - Samples can be real specimens or virtual (see method). - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally, (globally) unique persistent identifier which distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias! Instead, use name. - - In cases where multiple specimens were loaded into the microscope, - the identifier has to resolve the specific sample, whose results are - stored by this :ref:`NXentry` instance, because a single NXentry should be - used only for the characterization of a single specimen. - - Details about the specimen preparation should be - stored in resources referring to parent_identifier. - - - - - Identifier of the sample from which the sample was cut or the string - *None*. The purpose of this field is to support functionalities - for tracking sample provenance via a research data management system. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Ideally, this - matches the last timestamp that is mentioned in the digital resource - pointed to by parent_identifier. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments including tracers with a - short half time. Additional time stamps prior to preparation_date - should better be placed in resources which describe but which do not pollute - the description here with prose. Resolving these connected pieces of information - is considered within the responsibility of the research data management - system. - - - - - An alias used to refer to the specimen to please readability for humans. - - - - - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer research data management systems an - opportunity to parse the relevant elements without having to interpret - these from the resources pointed to by parent_identifier or walk through - eventually deeply nested groups in data instances. - - - - - - (Measured) sample thickness. - - The information is recorded to qualify if the beam used was likely - able to shine through the specimen. For scanning electron microscopy, - in many cases the specimen is typically thicker than what is - illuminatable by the electron beam. - - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - - - - - - - (Measured) density of the specimen. - - For multi-layered specimens this field should only be used to describe - the density of the excited volume. For scanning electron microscopy - the usage of this field is discouraged and instead an instance of an - :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` - instances can provide a cleaner description of the relevant details - why one may wish to store the density of the specimen. - - - - - Discouraged free-text field to provide further detail although adding - parent_identifier and having a working research data management system - should provide this contextualization. - - - - - - - - - - - - A region-of-interest analyzed either during or after the session - for which specific processed data generated from the measured or the - simulated data are available. - - - - - - - - - - - - diff --git a/contributed_definitions/nyaml/NXem_base.yaml b/contributed_definitions/nyaml/NXem_base.yaml deleted file mode 100644 index 44c98f96e0..0000000000 --- a/contributed_definitions/nyaml/NXem_base.yaml +++ /dev/null @@ -1,297 +0,0 @@ -category: base -# template to be used for an application definition -doc: | - Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. - - This base class combines a method-specific and technical-design-level base class - instance to provide a template for storing parameterized descriptions of - pieces of information collected when performing electron microscopy research. - - The base class here shows all possible branches without making any statements - as to which of these have to be used in an instance. Thereby, the base class - provides a template how to name and structure concepts in a hierarchy - to support finding information and reducing the need for renaming and - restructuring information for a research field where many scientists perform - very specific research but who all also share commonalities like usage of - controlled electron beams, a focus on studies of electron beam matter interaction - to explore physical mechanisms and phenomena, or the desire to characterize materials - using electron microscopy. -# flesh out the description of that to read the docs, because currently the -# description on the NeXus front-page is overwhelming -# considering what we learned from the diataxis workshop we write here a -# specification neither a how to nor a tutorial which explains all the context -# because we address here developers of software -type: group -NXem_base(NXobject): # but should inherit from NXroot - # each NeXus file instance should have a default plot - # however as there are cases when this cannot be assured we cannot - # make the default required, one example is e.g. a NeXus instance - # where scientists just store conventions without a default plot - (NXentry): # means ENTRY(NXentry) - definition(NX_CHAR): - \@version(NX_CHAR): - # enumeration: [NXem] - # as NXem_base is a blue-print for an appdef written as a base class because - # no other place for this in NeXus right now, NXem is the appdef along the lines of this blue-print - profiling(NXcs_profiling): - doc: | - The configuration of the I/O writer software (e.g. `pynxtools `_) - which was used to generate this NeXus file instance. - (NXprogram): # understood by default as PROGRAM(NXprogram), i.e. program1, program2, ... - doc: | - A collection of all programs and libraries which are considered relevant - to understand with which software tools this NeXus file instance was - generated. Ideally, to enable a binary recreation from the input data. - - Examples include the name and version of the libraries used to write the - instance. Ideally, the software which writes these NXprogram instances - also includes the version of the set of NeXus classes i.e. the specific - set of base classes, application definitions, and contributed definitions - with which the here described concepts can be resolved. - - For the `pynxtools library `_ - which is used by the `NOMAD `_ - research data management system, it makes sense to store e.g. the GitHub - repository commit and respective submodule references used. - experiment_identifier(NXidentifier): - doc: | - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - An experiment should be understood in that this can be an experiment - in reality or a computer simulation because also the latter is an - experiment (see the Cambridge Dictionary experiment: - *a test done in order to find out something, eg if an idea is correct*). - - The identifier is usually issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments/simulations to e.g. proposals. - experiment_description(NX_CHAR): - doc: | - Free-text description about the experiment. - - Users are strongly advised to parameterize their description of the - experiment by using the respective base classes instead of writing prose - into this field. - - The reason is that such free-text field is difficult to machine-interpret. - The motivation behind keeping this field for now is to learn through - the information entered in this field in how far the current base - classes are incomplete. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval via setting both - a start_time and an end_time because this enables software tools and - users to collect a more detailed bookkeeping of the experiment. - - The user should be aware that even with having both time instances specified, - it may not be possible to infer how long the experiment took or for how - long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps start_time and end_time - in :ref:`NXevent_data_em` instances. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. See docstring of the start_time field - to see how the start_time and end_time should be used together. - (NXcite): - (NXserialized): - doc: | - Possibility to store a collection of serialized resources - that are associated with the experiment. - - An example how to use this set could be to document - from which files generated by software of technology partners - the information in an instance of NXem was filled. - - If resources from technology partners would also be documented - semantically annotated there would not even be a necessity to - copy over specific information in NeXus files as one could write - a inference and information/fact/knowledge retrieval algorithm whereby - a specific piece of information that is related to an experiment or simulation - is just read directly from the respective file of the technology partner. - - The reason why currently this works convincingly in hardly any research - data management system is the strong heterogeneity of the information contained - in such files and the fact that often context and documentation specifically - rich semantic documentation and contextualization is missing. - # using NXserialized here instead of NXnote as the former is more specific - (NXuser): - doc: | - Contact information and eventually details of at least one person - who performed or was involved in the session. This can be the - principle investigator who performed this experiment or the student - who performed the simulation. - Adding multiple users if relevant is recommended. - name(NX_CHAR): - doc: | - Given (first) name and surname of the user. - affiliation(NX_CHAR): - doc: | - Name of the affiliation of the user at the point in time - when the experiment was performed. - address(NX_CHAR): - doc: | - Postal address of the affiliation. - email(NX_CHAR): - doc: | - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - identifier(NXidentifier): - doc: | - Service as another mean of identification of a user than by the name. - Examples could be details about an ORCID or social media account of - the user. - telephone_number(NX_CHAR): - doc: | - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - role(NX_CHAR): - doc: | - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope, student, postdoc, principle investigator, or guest - are common examples. - sample(NXsample): - # NEW ISSUE: inject the conclusion from the discussion with Andrea - # according to SAMPLE.yaml 0f8df14 2022/06/15 - # ID: -> maps to name - # name: -> short_title - # user: -> not matched right now - # citation: doi ->why relevant, should be solved by RDMS - doc: | - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - Samples can be real specimens or virtual (see method). - method(NX_CHAR): - doc: | - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - enumeration: [experiment, simulation] - # MK:: declared_by_vendor I would rather expect this for a substance - # COMPONENT.yaml - # SUBSTANCE: - # QUANTIFY - identifier(NXidentifier): - doc: | - Ideally, (globally) unique persistent identifier which distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias! Instead, use name. - - In cases where multiple specimens were loaded into the microscope, - the identifier has to resolve the specific sample, whose results are - stored by this :ref:`NXentry` instance, because a single NXentry should be - used only for the characterization of a single specimen. - - Details about the specimen preparation should be - stored in resources referring to parent_identifier. - parent_identifier(NXidentifier): - doc: | - Identifier of the sample from which the sample was cut or the string - *None*. The purpose of this field is to support functionalities - for tracking sample provenance via a research data management system. - preparation_date(NX_DATE_TIME): - doc: | - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Ideally, this - matches the last timestamp that is mentioned in the digital resource - pointed to by parent_identifier. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments including tracers with a - short half time. Additional time stamps prior to preparation_date - should better be placed in resources which describe but which do not pollute - the description here with prose. Resolving these connected pieces of information - is considered within the responsibility of the research data management - system. - name(NX_CHAR): - doc: | - An alias used to refer to the specimen to please readability for humans. - atom_types(NX_CHAR): - doc: | - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer research data management systems an - opportunity to parse the relevant elements without having to interpret - these from the resources pointed to by parent_identifier or walk through - eventually deeply nested groups in data instances. - # NEW ISSUE: use Andrea and MarkusK groups for describing the geometry of the sample - thickness(NX_NUMBER): - doc: | - (Measured) sample thickness. - - The information is recorded to qualify if the beam used was likely - able to shine through the specimen. For scanning electron microscopy, - in many cases the specimen is typically thicker than what is - illuminatable by the electron beam. - - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - unit: NX_LENGTH - # \@units: nm - # NEW ISSUE: error estimates of the thickness and origin, i.e. how the value was obtained would be useful - # NEW ISSUE: error model - # NEW ISSUE: the KIT/SCC SEM, TEM schemata further qualify samples whether they are conductive e/ibeam sensitive - # etc. The problem with this is that beam sensitivity is too vague but spatiotemporal electron dose integral dependent - # KIT/SCC distinguish further conductivity and magnetic properties. While the motivation is clear, making - # it thus simple is likely problematic when the data entered in such fields remaining qualitative. - # what are good or bad properties, it would make sense though to quantify these values - # this includes the description of eventual plasma cleaning steps, - # just knowing that a sample was plasma cleaned is insufficient, maybe it was not cleaned long enough - # if plasma cleaning is done outside the EM than its certainly history, if it happens inside the EM - # are the ibeam description capabilities not sufficient enough? - density(NX_NUMBER): - # NX_MASS_PER_VOLUME - doc: | - (Measured) density of the specimen. - - For multi-layered specimens this field should only be used to describe - the density of the excited volume. For scanning electron microscopy - the usage of this field is discouraged and instead an instance of an - :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` - instances can provide a cleaner description of the relevant details - why one may wish to store the density of the specimen. - unit: NX_ANY - description: - doc: | - Discouraged free-text field to provide further detail although adding - parent_identifier and having a working research data management system - should provide this contextualization. - # (NXmonitor): - (NXdata): - (NXcoordinate_system_set): - # link to an instance of an NXinstrument but that is anyway specialized for EM - measurement(NXem_msr): - simulation(NXem_sim): - (NXroi): - doc: | - A region-of-interest analyzed either during or after the session - for which specific processed data generated from the measured or the - simulated data are available. - se(NXem_img): - bse(NXem_img): - ebsd(NXem_ebsd): - eds(NXem_eds): - adf(NXem_adf): - eels(NXem_eels): - correlation(NXem_correlation): - # cl(NXem_cl): From 0b32c85555252c63a1f6e52358c30c8dfd4e277d Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 29 Feb 2024 17:32:28 +0100 Subject: [PATCH 0612/1012] temporarily use different nyaml commit --- requirements.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/requirements.txt b/requirements.txt index d27f482456..b90904cc68 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1,7 +1,7 @@ # Prepare for Documentation lxml pyyaml -nyaml +nyaml@git+https://github.com/FAIRmat-NFDI/nyaml.git@7a2b92bc2c1c0e69e5878e479c4ea053c00eb5c3 # Documentation building sphinx>=5 From 6961f340a6ac685192515bfe015a9c5549068480 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 29 Feb 2024 22:24:08 +0100 Subject: [PATCH 0613/1012] Cleanly removed NXem_base class --- contributed_definitions/NXem.nxdl.xml | 305 +++++++++++--- contributed_definitions/NXem_base.nxdl.xml | 376 ------------------ .../NXevent_data_em.nxdl.xml | 2 - .../NXimage_r_set_diff.nxdl.xml | 2 +- contributed_definitions/nyaml/NXem.yaml | 263 +++++++++--- contributed_definitions/nyaml/NXem_base.yaml | 297 -------------- .../nyaml/NXevent_data_em.yaml | 2 - .../nyaml/NXimage_r_set_diff.yaml | 2 +- .../contributed_definitions/em-structure.rst | 4 +- 9 files changed, 463 insertions(+), 790 deletions(-) delete mode 100644 contributed_definitions/NXem_base.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXem_base.yaml diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 3763f66331..9529540a22 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -21,51 +21,20 @@ # # For further information, see http://www.nexusformat.org --> - + Application definition for normalized representation of electron microscopy research. - In line with the idea of NeXus application definitions, this schema is a - specialized version of NXem_base in that fields and groups are specifically - constrained. This has the effect that some quantities are required, so - that a research data management system (RDMS) can rely on the existence of - these pieces of information without demanding that RDMS to implement further - verification in its own source code or further harmonization or normalization - what each piece of information means conceptually. + This application definition is a comprehensive example for a general description + with which to normalize specific pieces of information and data collected within + electron microscopy research. - This application definition is thus an example of a general description - with which to normalize specific pieces of information and data collected - within electron microscopy research. - - This application definition is also a blueprint which shows how users - can build specific application definitions by reusing - instead of completely - reimplementing the wheel from scratch - em-specific base classes - and thus - represent electron-microscopy-specific content. - - The constraints of all these application definitions might be different - than for the here exemplified application definition NXem. - - Nevertheless, the key benefit remains: Many pieces of information are still - conceptually the same, named in the same way and found in the same place - in the hierarchy. This supports interoperability of electron microscopy data - and is advantageous compared to having everybody using own formatting and - conceptually not harmonized terms for describing their electron microscopy - research. - - For the detailed rationale and explanation of the concept behind the - NeXus electron microscopy class definitions please consult the preamble - of the NXem_base base class. + NXem is designed to be used for documentation of experiments or computer simulations + of controlled electron beams which are used for studying electron-beam matter interaction + to explore physical mechanisms and phenomena, or to characterize materials with + electron microscopy. - + + Ideally, a (globally) unique persistent identifier for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an experiment + (see the Cambridge Dictionary experiment: *a test done in order to find out + something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, or the principle investigator. + The identifier enables to link experiments/simulations to e.g. proposals. + - Either an identifier or an alias that is human-friendly so - that scientists find that experiment again. + Either an identifier or an alias that is human-friendly so that scientists find + that experiment again. + + + + + Free-text description about the experiment. + + Users are strongly advised to parameterize the description of their experiment + by using respective groups and fields and base classes instead of writing prose + into this field. + + The reason is that such free-text field is difficult to machine-interpret. + The motivation behind keeping this field for now is to learn in how far the + current base classes need extension based on user feedback. + + + + + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval via setting both a start_time + and an end_time because this enables software tools and users to collect a + more detailed bookkeeping of the experiment. + + Users should be aware though that even with having both time instances + specified, it may not be possible to infer how long the experiment took or + for how long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :ref:`NXevent_data_em` instances. + + + + + ISO 8601 time code with local time zone offset to UTC included when + the microscope session ended. See docstring of the start_time field + to see how the start_time and end_time should be used together. - - - + + Possibility to store a collection of serialized resources that are associated + with the experiment. An example how to use this set could be to document + from which files, which have been e.g. generated by software of technology + partners, the information in an instance of NXem was filled with. + + If resources from technology partners would also be documented with semantic + technology there would not even be a necessity to copy over specific information + into other files as one could write inference and information/fact/knowledge retrieval + algorithm(s) whereby a specific piece of information that is related to an experiment + or simulation is read directly from the respective file of the technology partner. + + The reason why currently this works convincingly in hardly any research data + management system (RDMS) is the strong heterogeneity of the information contained + in such files and the fact that often context and documentation, specifically + rich semantic documentation, and contextualization is missing. + + - + + Contact information and eventually details of at least one person + who performed or was involved in the microscope session or simulation run. + This can be the principle investigator who performed this experiment or the + student who performed the simulation. Adding multiple users if relevant + is recommended. + + + + Given (first) name and surname of the user. + + + + + Name of the affiliation of the user at the point in time + when the experiment was performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + + + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + + + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. + + + + Service as another mean of identification of a user other than by its name. + Examples could be an ORCID or social media account of the user. + - + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). + + + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) + + + Ideally, (globally) unique persistent identifier which distinguishes the sample from all others + and especially the predecessor/origin from where that sample was cut. The terms sample + and specimen are here considered as exact synonyms. + + This field must not be used for an alias! Instead, use name. + + In cases where multiple specimens were loaded into the microscope, the identifier has to resolve + the specific sample, whose results are stored by this :ref:`NXentry` instance because a single + NXentry should be used for the characterization of a single specimen. + + Details about the specimen preparation should be stored in resources referring to parent_identifier. + + + Identifier of the sample from which the sample was cut or the string *None*. + + The purpose of this field is to support functionalities for tracking + sample provenance in a research data management system. + - - - + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known timestamp when + the measured specimen surface was actively prepared. Ideally, this matches + the last timestamp that is mentioned in the digital resource pointed to by + parent_identifier. + + Knowing when the specimen was exposed to e.g. specific atmosphere is especially + required for environmentally sensitive material such as specimen charged with hydrogen + or experiments including tracers that have a short halflife. Additional time stamps + prior to preparation_date should better be placed in resources which describe but + which do not pollute the description here with prose. Resolving these connected + pieces of information is considered the responsibility of the + research data management system not of a NeXus file. + + + + + An alias used to refer to the specimen to please readability for humans. + + + + + List of comma-separated elements from the periodic table that are contained in the sample. + If the sample substance has multiple components, all elements from each component + must be included in atom_types. + + The purpose of the field is to offer research data management systems an opportunity + to parse the relevant elements without having to interpret these from the resources + pointed to by parent_identifier or walk through eventually deeply nested groups in + individual data instances. + + + + + (Measured) sample thickness. + + The information is recorded to qualify if the beam used was likely + able to shine through the specimen. For scanning electron microscopy, + in many cases the specimen is typically thicker than what is + illuminatable by the electron beam. + + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. + + + + + + (Measured) density of the specimen. + + For multi-layered specimens this field should only be used to describe + the density of the excited volume. For scanning electron microscopy + the usage of this field is discouraged and instead an instance of an + :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` + instances can provide a cleaner description of the relevant details + why one may wish to store the density of the specimen. + + + + + Discouraged free-text field to provide further detail although adding + parent_identifier and having a working research data management system + should provide this contextualization. + + - @@ -178,8 +371,7 @@ where scientists just store conventions without a default plot--> - A region-of-interest analyzed either during or after the session. - For which specific processed data of the measured or simulated - data are available. + A region-of-interest analyzed either during or after the session for which + specific processed data are available. - - - - - Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. - - This base class combines a method-specific and technical-design-level base class - instance to provide a template for storing parameterized descriptions of - pieces of information collected when performing electron microscopy research. - - The base class here shows all possible branches without making any statements - as to which of these have to be used in an instance. Thereby, the base class - provides a template how to name and structure concepts in a hierarchy - to support finding information and reducing the need for renaming and - restructuring information for a research field where many scientists perform - very specific research but who all also share commonalities like usage of - controlled electron beams, a focus on studies of electron beam matter interaction - to explore physical mechanisms and phenomena, or the desire to characterize materials - using electron microscopy. - - - - - - - - - - The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) - which was used to generate this NeXus file instance. - - - - A collection of all programs and libraries which are considered relevant - to understand with which software tools this NeXus file instance was - generated. Ideally, to enable a binary recreation from the input data. - - Examples include the name and version of the libraries used to write the - instance. Ideally, the software which writes these NXprogram instances - also includes the version of the set of NeXus classes i.e. the specific - set of base classes, application definitions, and contributed definitions - with which the here described concepts can be resolved. - - For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ - which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ - research data management system, it makes sense to store e.g. the GitHub - repository commit and respective submodule references used. - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - An experiment should be understood in that this can be an experiment - in reality or a computer simulation because also the latter is an - experiment (see the Cambridge Dictionary experiment: - *a test done in order to find out something, eg if an idea is correct*). - - The identifier is usually issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments/simulations to e.g. proposals. - - - - - Free-text description about the experiment. - - Users are strongly advised to parameterize their description of the - experiment by using the respective base classes instead of writing prose - into this field. - - The reason is that such free-text field is difficult to machine-interpret. - The motivation behind keeping this field for now is to learn through - the information entered in this field in how far the current base - classes are incomplete. - - - - - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval via setting both - a start_time and an end_time because this enables software tools and - users to collect a more detailed bookkeeping of the experiment. - - The user should be aware that even with having both time instances specified, - it may not be possible to infer how long the experiment took or for how - long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps start_time and end_time - in :ref:`NXevent_data_em` instances. - - - - - ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. See docstring of the start_time field - to see how the start_time and end_time should be used together. - - - - - - Possibility to store a collection of serialized resources - that are associated with the experiment. - - An example how to use this set could be to document - from which files generated by software of technology partners - the information in an instance of NXem was filled. - - If resources from technology partners would also be documented - semantically annotated there would not even be a necessity to - copy over specific information in NeXus files as one could write - a inference and information/fact/knowledge retrieval algorithm whereby - a specific piece of information that is related to an experiment or simulation - is just read directly from the respective file of the technology partner. - - The reason why currently this works convincingly in hardly any research - data management system is the strong heterogeneity of the information contained - in such files and the fact that often context and documentation specifically - rich semantic documentation and contextualization is missing. - - - - - - Contact information and eventually details of at least one person - who performed or was involved in the session. This can be the - principle investigator who performed this experiment or the student - who performed the simulation. - Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Service as another mean of identification of a user than by the name. - Examples could be details about an ORCID or social media account of - the user. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope, student, postdoc, principle investigator, or guest - are common examples. - - - - - - - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - Samples can be real specimens or virtual (see method). - - - - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - - - - - - - - - - Ideally, (globally) unique persistent identifier which distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias! Instead, use name. - - In cases where multiple specimens were loaded into the microscope, - the identifier has to resolve the specific sample, whose results are - stored by this :ref:`NXentry` instance, because a single NXentry should be - used only for the characterization of a single specimen. - - Details about the specimen preparation should be - stored in resources referring to parent_identifier. - - - - - Identifier of the sample from which the sample was cut or the string - *None*. The purpose of this field is to support functionalities - for tracking sample provenance via a research data management system. - - - - - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Ideally, this - matches the last timestamp that is mentioned in the digital resource - pointed to by parent_identifier. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments including tracers with a - short half time. Additional time stamps prior to preparation_date - should better be placed in resources which describe but which do not pollute - the description here with prose. Resolving these connected pieces of information - is considered within the responsibility of the research data management - system. - - - - - An alias used to refer to the specimen to please readability for humans. - - - - - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer research data management systems an - opportunity to parse the relevant elements without having to interpret - these from the resources pointed to by parent_identifier or walk through - eventually deeply nested groups in data instances. - - - - - - (Measured) sample thickness. - - The information is recorded to qualify if the beam used was likely - able to shine through the specimen. For scanning electron microscopy, - in many cases the specimen is typically thicker than what is - illuminatable by the electron beam. - - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - - - - - - - (Measured) density of the specimen. - - For multi-layered specimens this field should only be used to describe - the density of the excited volume. For scanning electron microscopy - the usage of this field is discouraged and instead an instance of an - :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` - instances can provide a cleaner description of the relevant details - why one may wish to store the density of the specimen. - - - - - Discouraged free-text field to provide further detail although adding - parent_identifier and having a working research data management system - should provide this contextualization. - - - - - - - - - - - - A region-of-interest analyzed either during or after the session - for which specific processed data generated from the measured or the - simulated data are available. - - - - - - - - - - - - diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml index 3b30684fd3..16958d8ec9 100644 --- a/contributed_definitions/NXevent_data_em.nxdl.xml +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -55,8 +55,6 @@ purpose is to contextualize and identify the event instance in time. Secondly, there is a data and metadata section where individual data collections can be stored using a standardized representation. - Finally, there is a section called em_lab which mirrors the structure of the - em_lab(NXinstrument) section in :ref:`NXem_base`. The idea of the first, the event-based em_lab section, is to document the state of the microscope as it was during the event. The idea of the other, diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml index 9bb45544f5..495d8756dc 100644 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -59,7 +59,7 @@ on Kikuchi diffraction pattern here specifically the research community of Electron Backscatter Diffraction (EBSD). - For this reason, this base class and related :ref:`NXem_base` classes extend the + For this reason, this base class and the :ref:`NXem_ebsd` base class extend the work of `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ (one of the developers of DREAM.3D) and the H5OINA public file format developed by `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ with Oxford Instruments. diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index 1575b6f094..5c3aef5d7e 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -2,47 +2,16 @@ category: application doc: | Application definition for normalized representation of electron microscopy research. - In line with the idea of NeXus application definitions, this schema is a - specialized version of NXem_base in that fields and groups are specifically - constrained. This has the effect that some quantities are required, so - that a research data management system (RDMS) can rely on the existence of - these pieces of information without demanding that RDMS to implement further - verification in its own source code or further harmonization or normalization - what each piece of information means conceptually. + This application definition is a comprehensive example for a general description + with which to normalize specific pieces of information and data collected within + electron microscopy research. - This application definition is thus an example of a general description - with which to normalize specific pieces of information and data collected - within electron microscopy research. - - This application definition is also a blueprint which shows how users - can build specific application definitions by reusing - instead of completely - reimplementing the wheel from scratch - em-specific base classes - and thus - represent electron-microscopy-specific content. - - The constraints of all these application definitions might be different - than for the here exemplified application definition NXem. - - Nevertheless, the key benefit remains: Many pieces of information are still - conceptually the same, named in the same way and found in the same place - in the hierarchy. This supports interoperability of electron microscopy data - and is advantageous compared to having everybody using own formatting and - conceptually not harmonized terms for describing their electron microscopy - research. - - For the detailed rationale and explanation of the concept behind the - NeXus electron microscopy class definitions please consult the preamble - of the NXem_base base class. + NXem is designed to be used for documentation of experiments or computer simulations + of controlled electron beams which are used for studying electron-beam matter interaction + to explore physical mechanisms and phenomena, or to characterize materials with + electron microscopy. type: group -NXem(NXem_base): - # composing from NXem_base should work because NXem_base is composed from NXroot - # just list what is required or recommended or optional - # overwrite which known building blocks should get a different meaning - # and add specific fields for which there is not yet a base class - # this also strenghtens that people write base classes instead of - # highly customized and deeply overwriting application definitions - # other than for base classes the default existentiality constraint is - # exists: required therefore spelling this out is omitted for convenience - # a releasing of this default constraint is possible with writing exists: +NXem(NXobject): # \@NX_class: # \@file_time(NX_DATE_TIME): # \@file_name(NX_CHAR): @@ -88,53 +57,247 @@ NXem(NXem_base): # \@url: experiment_identifier(NXidentifier): exists: recommended + doc: | + Ideally, a (globally) unique persistent identifier for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an experiment + (see the Cambridge Dictionary experiment: *a test done in order to find out + something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, or the principle investigator. + The identifier enables to link experiments/simulations to e.g. proposals. service(NX_CHAR): identifier(NX_CHAR): is_persistent(NX_BOOLEAN): experiment_alias(NX_CHAR): doc: | - Either an identifier or an alias that is human-friendly so - that scientists find that experiment again. - experiment_description(NX_CHAR): # no docstring overwritten means accepting it as it is defined in NXem_base + Either an identifier or an alias that is human-friendly so that scientists find that experiment again. + experiment_description(NX_CHAR): exists: optional + doc: | + Free-text description about the experiment. + + Users are strongly advised to parameterize the description of their experiment + by using respective groups and fields and base classes instead of writing prose + into this field. + + The reason is that such free-text field is difficult to machine-interpret. + The motivation behind keeping this field for now is to learn in how far the + current base classes need extension based on user feedback. start_time(NX_DATE_TIME): + doc: | + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant - this start_time field should be used. + + Often though it is useful to specify a time interval via setting both a start_time + and an end_time because this enables software tools and users to collect a + more detailed bookkeeping of the experiment. + + Users should be aware though that even with having both time instances + specified, it may not be possible to infer how long the experiment took or + for how long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :ref:`NXevent_data_em` instances. end_time(NX_DATE_TIME): exists: recommended + doc: | + ISO 8601 time code with local time zone offset to UTC included when + the microscope session ended. See docstring of the start_time field + to see how the start_time and end_time should be used together. (NXcite): exists: [min, 0, max, infty] (NXserialized): exists: [min, 0, max, infty] + doc: | + Possibility to store a collection of serialized resources that are associated + with the experiment. An example how to use this set could be to document + from which files, which have been e.g. generated by software of technology + partners, the information in an instance of NXem was filled with. + + If resources from technology partners would also be documented with semantic + technology there would not even be a necessity to copy over specific information + into other files as one could write inference and information/fact/knowledge retrieval + algorithm(s) whereby a specific piece of information that is related to an experiment + or simulation is read directly from the respective file of the technology partner. + + The reason why currently this works convincingly in hardly any research data + management system (RDMS) is the strong heterogeneity of the information contained + in such files and the fact that often context and documentation, specifically + rich semantic documentation, and contextualization is missing. + # using NXserialized here instead of NXnote as the former is more specific type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): (NXuser): exists: [min, 0, max, infty] + doc: | + Contact information and eventually details of at least one person + who performed or was involved in the microscope session or simulation run. + This can be the principle investigator who performed this experiment or the + student who performed the simulation. Adding multiple users if relevant + is recommended. name(NX_CHAR): + exists: optional + doc: | + Given (first) name and surname of the user. + affiliation(NX_CHAR): + exists: optional + doc: | + Name of the affiliation of the user at the point in time + when the experiment was performed. + address(NX_CHAR): + exists: optional + doc: | + Postal address of the affiliation. + email(NX_CHAR): + exists: optional + doc: | + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. + telephone_number(NX_CHAR): + doc: | + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + role(NX_CHAR): + doc: | + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the microscope, student, postdoc, principle investigator, or guest + are common examples. identifier(NXidentifier): exists: recommended + doc: | + Service as another mean of identification of a user other than by its name. + Examples could be an ORCID or social media account of the user. service(NX_CHAR): identifier(NX_CHAR): is_persistent(NX_BOOLEAN): - # all other fields are optional but clearly defined in NXem_base sample(NXsample): + # NEW ISSUE: inject the conclusion from the discussion with Andrea + # according to SAMPLE.yaml 0f8df14 2022/06/15 + # ID: -> maps to name + # name: -> short_title + # user: -> not matched right now + # citation: doi ->why relevant, should be solved by RDMS + doc: | + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + Samples can be real specimens or virtual (see method). method(NX_CHAR): + doc: | + A qualifier whether the sample is a real one or a + virtual one (in a computer simulation) enumeration: [experiment, simulation] identifier(NXidentifier): exists: recommended + doc: | + Ideally, (globally) unique persistent identifier which distinguishes the sample from all others + and especially the predecessor/origin from where that sample was cut. The terms sample + and specimen are here considered as exact synonyms. + + This field must not be used for an alias! Instead, use name. + + In cases where multiple specimens were loaded into the microscope, the identifier has to resolve + the specific sample, whose results are stored by this :ref:`NXentry` instance because a single + NXentry should be used for the characterization of a single specimen. + + Details about the specimen preparation should be stored in resources referring to parent_identifier. service(NX_CHAR): identifier(NX_CHAR): is_persistent(NX_BOOLEAN): parent_identifier(NXidentifier): exists: recommended + doc: | + Identifier of the sample from which the sample was cut or the string *None*. + + The purpose of this field is to support functionalities for tracking + sample provenance in a research data management system. service(NX_CHAR): identifier(NX_CHAR): is_persistent(NX_BOOLEAN): preparation_date(NX_DATE_TIME): - name: + doc: | + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known timestamp when + the measured specimen surface was actively prepared. Ideally, this matches + the last timestamp that is mentioned in the digital resource pointed to by + parent_identifier. + + Knowing when the specimen was exposed to e.g. specific atmosphere is especially + required for environmentally sensitive material such as specimen charged with hydrogen + or experiments including tracers that have a short halflife. Additional time stamps + prior to preparation_date should better be placed in resources which describe but + which do not pollute the description here with prose. Resolving these connected + pieces of information is considered the responsibility of the + research data management system not of a NeXus file. + name(NX_CHAR): exists: recommended + doc: | + An alias used to refer to the specimen to please readability for humans. atom_types(NX_CHAR): - # again all other fields are optional + doc: | + List of comma-separated elements from the periodic table that are contained in the sample. + If the sample substance has multiple components, all elements from each component + must be included in atom_types. + + The purpose of the field is to offer research data management systems an opportunity + to parse the relevant elements without having to interpret these from the resources + pointed to by parent_identifier or walk through eventually deeply nested groups in + individual data instances. + thickness(NX_NUMBER): + exists: optional + doc: | + (Measured) sample thickness. + + The information is recorded to qualify if the beam used was likely + able to shine through the specimen. For scanning electron microscopy, + in many cases the specimen is typically thicker than what is + illuminatable by the electron beam. + + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. + unit: NX_LENGTH + # \@units: nm + # NEW ISSUE: error estimates of the thickness and origin, i.e. how the value was obtained would be useful + # NEW ISSUE: error model + # NEW ISSUE: the KIT/SCC SEM, TEM schemata further qualify samples whether they are conductive e/ibeam sensitive + # etc. The problem with this is that beam sensitivity is too vague but spatiotemporal electron dose integral dependent + # KIT/SCC distinguish further conductivity and magnetic properties. While the motivation is clear, making + # it thus simple is likely problematic when the data entered in such fields remaining qualitative. + # what are good or bad properties, it would make sense though to quantify these values + # this includes the description of eventual plasma cleaning steps, + # just knowing that a sample was plasma cleaned is insufficient, maybe it was not cleaned long enough + # if plasma cleaning is done outside the EM than its certainly history, if it happens inside the EM + # are the ibeam description capabilities not sufficient enough? + density(NX_NUMBER): + exists: optional + doc: | + (Measured) density of the specimen. + + For multi-layered specimens this field should only be used to describe + the density of the excited volume. For scanning electron microscopy + the usage of this field is discouraged and instead an instance of an + :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` + instances can provide a cleaner description of the relevant details + why one may wish to store the density of the specimen. + unit: NX_ANY + description(NX_CHAR): + exists: optional + doc: | + Discouraged free-text field to provide further detail although adding + parent_identifier and having a working research data management system + should provide this contextualization. (NXcoordinate_system_set): exists: [min, 1, max, 1] (NXcoordinate_system): @@ -148,8 +311,7 @@ NXem(NXem_base): z_direction(NX_CHAR): # the description can be so lean because we do not need # to overwrite here s.th. as everything is defined already - # in NXem_base and we also do not wish to overwrite the datatype - # of fields, we just say hey we need the above-mentioned fields + # we just say hey we need the above-mentioned fields # in the way they are defined in the respective composed base classes # and they have to be defined # we also should not need to specify the value type like R, NX_POSINT @@ -500,9 +662,8 @@ NXem(NXem_base): (NXroi): exists: [min, 0, max, infty] doc: | - A region-of-interest analyzed either during or after the session. - For which specific processed data of the measured or simulated - data are available. + A region-of-interest analyzed either during or after the session for which + specific processed data are available. # as soon as one entry is here constrained further # an RDM can be sure to find specific pieces of information in a # specific way but then every user of this application definition @@ -557,7 +718,7 @@ NXem(NXem_base): # Magnification -> use NXoptical_system_em # Image width -> implicit in roi/NXdata instances # Image size -> see image width -# Acquisition mode (too vague) -> map on more expressive fields of NXem_base +# Acquisition mode (too vague) -> map on more expressive fields of NXem # Storage tilt (what is this) for tilt see NXstage_lab # Measurement date (how is it different from Date? # Comments -> any of the description fields, in both cases not fair diff --git a/contributed_definitions/nyaml/NXem_base.yaml b/contributed_definitions/nyaml/NXem_base.yaml deleted file mode 100644 index 44c98f96e0..0000000000 --- a/contributed_definitions/nyaml/NXem_base.yaml +++ /dev/null @@ -1,297 +0,0 @@ -category: base -# template to be used for an application definition -doc: | - Blue-print of a generic appdef for electron microscopy research formulated as a deep base class. - - This base class combines a method-specific and technical-design-level base class - instance to provide a template for storing parameterized descriptions of - pieces of information collected when performing electron microscopy research. - - The base class here shows all possible branches without making any statements - as to which of these have to be used in an instance. Thereby, the base class - provides a template how to name and structure concepts in a hierarchy - to support finding information and reducing the need for renaming and - restructuring information for a research field where many scientists perform - very specific research but who all also share commonalities like usage of - controlled electron beams, a focus on studies of electron beam matter interaction - to explore physical mechanisms and phenomena, or the desire to characterize materials - using electron microscopy. -# flesh out the description of that to read the docs, because currently the -# description on the NeXus front-page is overwhelming -# considering what we learned from the diataxis workshop we write here a -# specification neither a how to nor a tutorial which explains all the context -# because we address here developers of software -type: group -NXem_base(NXobject): # but should inherit from NXroot - # each NeXus file instance should have a default plot - # however as there are cases when this cannot be assured we cannot - # make the default required, one example is e.g. a NeXus instance - # where scientists just store conventions without a default plot - (NXentry): # means ENTRY(NXentry) - definition(NX_CHAR): - \@version(NX_CHAR): - # enumeration: [NXem] - # as NXem_base is a blue-print for an appdef written as a base class because - # no other place for this in NeXus right now, NXem is the appdef along the lines of this blue-print - profiling(NXcs_profiling): - doc: | - The configuration of the I/O writer software (e.g. `pynxtools `_) - which was used to generate this NeXus file instance. - (NXprogram): # understood by default as PROGRAM(NXprogram), i.e. program1, program2, ... - doc: | - A collection of all programs and libraries which are considered relevant - to understand with which software tools this NeXus file instance was - generated. Ideally, to enable a binary recreation from the input data. - - Examples include the name and version of the libraries used to write the - instance. Ideally, the software which writes these NXprogram instances - also includes the version of the set of NeXus classes i.e. the specific - set of base classes, application definitions, and contributed definitions - with which the here described concepts can be resolved. - - For the `pynxtools library `_ - which is used by the `NOMAD `_ - research data management system, it makes sense to store e.g. the GitHub - repository commit and respective submodule references used. - experiment_identifier(NXidentifier): - doc: | - Ideally, a (globally) unique persistent identifier - for referring to this experiment. - - An experiment should be understood in that this can be an experiment - in reality or a computer simulation because also the latter is an - experiment (see the Cambridge Dictionary experiment: - *a test done in order to find out something, eg if an idea is correct*). - - The identifier is usually issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments/simulations to e.g. proposals. - experiment_description(NX_CHAR): - doc: | - Free-text description about the experiment. - - Users are strongly advised to parameterize their description of the - experiment by using the respective base classes instead of writing prose - into this field. - - The reason is that such free-text field is difficult to machine-interpret. - The motivation behind keeping this field for now is to learn through - the information entered in this field in how far the current base - classes are incomplete. - start_time(NX_DATE_TIME): - doc: | - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant - this start_time field should be used. - - Often though it is useful to specify a time interval via setting both - a start_time and an end_time because this enables software tools and - users to collect a more detailed bookkeeping of the experiment. - - The user should be aware that even with having both time instances specified, - it may not be possible to infer how long the experiment took or for how - long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps start_time and end_time - in :ref:`NXevent_data_em` instances. - end_time(NX_DATE_TIME): - doc: | - ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. See docstring of the start_time field - to see how the start_time and end_time should be used together. - (NXcite): - (NXserialized): - doc: | - Possibility to store a collection of serialized resources - that are associated with the experiment. - - An example how to use this set could be to document - from which files generated by software of technology partners - the information in an instance of NXem was filled. - - If resources from technology partners would also be documented - semantically annotated there would not even be a necessity to - copy over specific information in NeXus files as one could write - a inference and information/fact/knowledge retrieval algorithm whereby - a specific piece of information that is related to an experiment or simulation - is just read directly from the respective file of the technology partner. - - The reason why currently this works convincingly in hardly any research - data management system is the strong heterogeneity of the information contained - in such files and the fact that often context and documentation specifically - rich semantic documentation and contextualization is missing. - # using NXserialized here instead of NXnote as the former is more specific - (NXuser): - doc: | - Contact information and eventually details of at least one person - who performed or was involved in the session. This can be the - principle investigator who performed this experiment or the student - who performed the simulation. - Adding multiple users if relevant is recommended. - name(NX_CHAR): - doc: | - Given (first) name and surname of the user. - affiliation(NX_CHAR): - doc: | - Name of the affiliation of the user at the point in time - when the experiment was performed. - address(NX_CHAR): - doc: | - Postal address of the affiliation. - email(NX_CHAR): - doc: | - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - identifier(NXidentifier): - doc: | - Service as another mean of identification of a user than by the name. - Examples could be details about an ORCID or social media account of - the user. - telephone_number(NX_CHAR): - doc: | - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - role(NX_CHAR): - doc: | - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope, student, postdoc, principle investigator, or guest - are common examples. - sample(NXsample): - # NEW ISSUE: inject the conclusion from the discussion with Andrea - # according to SAMPLE.yaml 0f8df14 2022/06/15 - # ID: -> maps to name - # name: -> short_title - # user: -> not matched right now - # citation: doi ->why relevant, should be solved by RDMS - doc: | - A description of the material characterized in the experiment. - Sample and specimen are threaded as de facto synonyms. - Samples can be real specimens or virtual (see method). - method(NX_CHAR): - doc: | - A qualifier whether the sample is a real one or a - virtual one (in a computer simulation) - enumeration: [experiment, simulation] - # MK:: declared_by_vendor I would rather expect this for a substance - # COMPONENT.yaml - # SUBSTANCE: - # QUANTIFY - identifier(NXidentifier): - doc: | - Ideally, (globally) unique persistent identifier which distinguishes - the specimen from all others and especially the predecessor/origin - from where the specimen was cut. - - This field must not be used for an alias! Instead, use name. - - In cases where multiple specimens were loaded into the microscope, - the identifier has to resolve the specific sample, whose results are - stored by this :ref:`NXentry` instance, because a single NXentry should be - used only for the characterization of a single specimen. - - Details about the specimen preparation should be - stored in resources referring to parent_identifier. - parent_identifier(NXidentifier): - doc: | - Identifier of the sample from which the sample was cut or the string - *None*. The purpose of this field is to support functionalities - for tracking sample provenance via a research data management system. - preparation_date(NX_DATE_TIME): - doc: | - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Ideally, this - matches the last timestamp that is mentioned in the digital resource - pointed to by parent_identifier. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments including tracers with a - short half time. Additional time stamps prior to preparation_date - should better be placed in resources which describe but which do not pollute - the description here with prose. Resolving these connected pieces of information - is considered within the responsibility of the research data management - system. - name(NX_CHAR): - doc: | - An alias used to refer to the specimen to please readability for humans. - atom_types(NX_CHAR): - doc: | - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer research data management systems an - opportunity to parse the relevant elements without having to interpret - these from the resources pointed to by parent_identifier or walk through - eventually deeply nested groups in data instances. - # NEW ISSUE: use Andrea and MarkusK groups for describing the geometry of the sample - thickness(NX_NUMBER): - doc: | - (Measured) sample thickness. - - The information is recorded to qualify if the beam used was likely - able to shine through the specimen. For scanning electron microscopy, - in many cases the specimen is typically thicker than what is - illuminatable by the electron beam. - - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. - unit: NX_LENGTH - # \@units: nm - # NEW ISSUE: error estimates of the thickness and origin, i.e. how the value was obtained would be useful - # NEW ISSUE: error model - # NEW ISSUE: the KIT/SCC SEM, TEM schemata further qualify samples whether they are conductive e/ibeam sensitive - # etc. The problem with this is that beam sensitivity is too vague but spatiotemporal electron dose integral dependent - # KIT/SCC distinguish further conductivity and magnetic properties. While the motivation is clear, making - # it thus simple is likely problematic when the data entered in such fields remaining qualitative. - # what are good or bad properties, it would make sense though to quantify these values - # this includes the description of eventual plasma cleaning steps, - # just knowing that a sample was plasma cleaned is insufficient, maybe it was not cleaned long enough - # if plasma cleaning is done outside the EM than its certainly history, if it happens inside the EM - # are the ibeam description capabilities not sufficient enough? - density(NX_NUMBER): - # NX_MASS_PER_VOLUME - doc: | - (Measured) density of the specimen. - - For multi-layered specimens this field should only be used to describe - the density of the excited volume. For scanning electron microscopy - the usage of this field is discouraged and instead an instance of an - :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` - instances can provide a cleaner description of the relevant details - why one may wish to store the density of the specimen. - unit: NX_ANY - description: - doc: | - Discouraged free-text field to provide further detail although adding - parent_identifier and having a working research data management system - should provide this contextualization. - # (NXmonitor): - (NXdata): - (NXcoordinate_system_set): - # link to an instance of an NXinstrument but that is anyway specialized for EM - measurement(NXem_msr): - simulation(NXem_sim): - (NXroi): - doc: | - A region-of-interest analyzed either during or after the session - for which specific processed data generated from the measured or the - simulated data are available. - se(NXem_img): - bse(NXem_img): - ebsd(NXem_ebsd): - eds(NXem_eds): - adf(NXem_adf): - eels(NXem_eels): - correlation(NXem_correlation): - # cl(NXem_cl): diff --git a/contributed_definitions/nyaml/NXevent_data_em.yaml b/contributed_definitions/nyaml/NXevent_data_em.yaml index 1dbd771f9b..71df3c5982 100644 --- a/contributed_definitions/nyaml/NXevent_data_em.yaml +++ b/contributed_definitions/nyaml/NXevent_data_em.yaml @@ -32,8 +32,6 @@ doc: | purpose is to contextualize and identify the event instance in time. Secondly, there is a data and metadata section where individual data collections can be stored using a standardized representation. - Finally, there is a section called em_lab which mirrors the structure of the - em_lab(NXinstrument) section in :ref:`NXem_base`. The idea of the first, the event-based em_lab section, is to document the state of the microscope as it was during the event. The idea of the other, diff --git a/contributed_definitions/nyaml/NXimage_r_set_diff.yaml b/contributed_definitions/nyaml/NXimage_r_set_diff.yaml index 79ca31b168..5a0e27e283 100644 --- a/contributed_definitions/nyaml/NXimage_r_set_diff.yaml +++ b/contributed_definitions/nyaml/NXimage_r_set_diff.yaml @@ -14,7 +14,7 @@ doc: | on Kikuchi diffraction pattern here specifically the research community of Electron Backscatter Diffraction (EBSD). - For this reason, this base class and related :ref:`NXem_base` classes extend the + For this reason, this base class and the :ref:`NXem_ebsd` base class extend the work of `M. A. Jackson et al. `_ (one of the developers of DREAM.3D) and the H5OINA public file format developed by `P. Pinard et al. `_ with Oxford Instruments. diff --git a/manual/source/classes/contributed_definitions/em-structure.rst b/manual/source/classes/contributed_definitions/em-structure.rst index 93ca953da4..86647eccd9 100644 --- a/manual/source/classes/contributed_definitions/em-structure.rst +++ b/manual/source/classes/contributed_definitions/em-structure.rst @@ -37,10 +37,8 @@ In summary, scientists place a specimen/sample into the microscope, calibrate th A microscope session ends with the scientist removing the specimen from the instrument or parking it so that the next user can start a session. Occasionally, service technicians perform calibrations and maintenance which also can be described as a session on the microscope. We have provided base classes to describe these steps and events and an application definition for electron microscopy: :ref:`NXem`: - An application definition which explores the possibilities of electron microscopes. This application definition sets constraints on :ref:`NXem_base`. + An application definition which explores the possibilities of electron microscopes. - :ref:`NXem_base`: - A base class to serve as a blueprint for documenting research with electron microscopy (real microscope or simulated electron beam matter interaction). .. _EmBC: From 3337196b77c5d99cadc2354d3d022cbc71a44a61 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Fri, 1 Mar 2024 10:30:18 +0100 Subject: [PATCH 0614/1012] Changes suggested by @domna --- Makefile | 2 - contributed_definitions/nyaml/batch.sh | 212 ------------------------- 2 files changed, 214 deletions(-) delete mode 100755 contributed_definitions/nyaml/batch.sh diff --git a/Makefile b/Makefile index 6327479aa4..78f3af7719 100644 --- a/Makefile +++ b/Makefile @@ -75,8 +75,6 @@ pdf :: $(SPHINX) -M latexpdf $(BUILD_DIR)/manual/source/ $(BUILD_DIR)/manual/build cp $(BUILD_DIR)/manual/build/latex/nexus-fairmat.pdf $(BUILD_DIR)/manual/source/_static/NeXusManual.pdf -# for development purposes switch off the -W flag in the following line to make testing the local -# building of the manual more efficient html :: $(SPHINX) -b html -W $(BUILD_DIR)/manual/source/ $(BUILD_DIR)/manual/build/html diff --git a/contributed_definitions/nyaml/batch.sh b/contributed_definitions/nyaml/batch.sh deleted file mode 100755 index 415fcd1870..0000000000 --- a/contributed_definitions/nyaml/batch.sh +++ /dev/null @@ -1,212 +0,0 @@ -#!/bin/bash - -nyaml2nxdl NXaberration.yaml -nyaml2nxdl NXaberration_model.yaml -nyaml2nxdl NXaberration_model_ceos.yaml -nyaml2nxdl NXaberration_model_nion.yaml -nyaml2nxdl NXactivity.yaml -nyaml2nxdl NXadc.yaml -nyaml2nxdl NXamplifier.yaml -nyaml2nxdl NXaperture_em.yaml -nyaml2nxdl NXapm.yaml -nyaml2nxdl NXapm_charge_state_analysis.yaml -nyaml2nxdl NXapm_composition_space_results.yaml -nyaml2nxdl NXapm_hit_finding.yaml -nyaml2nxdl NXapm_msr.yaml -nyaml2nxdl NXapm_paraprobe_clusterer_config.yaml -nyaml2nxdl NXapm_paraprobe_clusterer_results.yaml -nyaml2nxdl NXapm_paraprobe_distancer_config.yaml -nyaml2nxdl NXapm_paraprobe_distancer_results.yaml -nyaml2nxdl NXapm_paraprobe_intersector_config.yaml -nyaml2nxdl NXapm_paraprobe_intersector_results.yaml -nyaml2nxdl NXapm_paraprobe_nanochem_config.yaml -nyaml2nxdl NXapm_paraprobe_nanochem_results.yaml -nyaml2nxdl NXapm_paraprobe_ranger_config.yaml -nyaml2nxdl NXapm_paraprobe_ranger_results.yaml -nyaml2nxdl NXapm_paraprobe_selector_config.yaml -nyaml2nxdl NXapm_paraprobe_selector_results.yaml -nyaml2nxdl NXapm_paraprobe_spatstat_config.yaml -nyaml2nxdl NXapm_paraprobe_spatstat_results.yaml -nyaml2nxdl NXapm_paraprobe_surfacer_config.yaml -nyaml2nxdl NXapm_paraprobe_surfacer_results.yaml -nyaml2nxdl NXapm_paraprobe_tessellator_config.yaml -nyaml2nxdl NXapm_paraprobe_tessellator_results.yaml -nyaml2nxdl NXapm_paraprobe_tool_common.yaml -nyaml2nxdl NXapm_paraprobe_tool_config.yaml -nyaml2nxdl NXapm_paraprobe_tool_results.yaml -nyaml2nxdl NXapm_paraprobe_transcoder_config.yaml -nyaml2nxdl NXapm_paraprobe_transcoder_results.yaml -nyaml2nxdl NXapm_ranging.yaml -nyaml2nxdl NXapm_reconstruction.yaml -nyaml2nxdl NXapm_sim.yaml -nyaml2nxdl NXapm_volt_and_bowl.yaml -nyaml2nxdl NXbeam_path.yaml -nyaml2nxdl NXbeam_splitter.yaml -nyaml2nxdl NXbias_spectroscopy.yaml -nyaml2nxdl NXcalibration.yaml -nyaml2nxdl NXcg_alpha_complex.yaml -nyaml2nxdl NXcg_cylinder_set.yaml -nyaml2nxdl NXcg_ellipsoid_set.yaml -nyaml2nxdl NXcg_face_list_data_structure.yaml -nyaml2nxdl NXcg_geodesic_mesh.yaml -nyaml2nxdl NXcg_grid.yaml -nyaml2nxdl NXcg_half_edge_data_structure.yaml -nyaml2nxdl NXcg_hexahedron_set.yaml -nyaml2nxdl NXcg_marching_cubes.yaml -nyaml2nxdl NXcg_parallelogram_set.yaml -nyaml2nxdl NXcg_point_set.yaml -nyaml2nxdl NXcg_polygon_set.yaml -nyaml2nxdl NXcg_polyhedron_set.yaml -nyaml2nxdl NXcg_polyline_set.yaml -nyaml2nxdl NXcg_primitive_set.yaml -nyaml2nxdl NXcg_roi_set.yaml -nyaml2nxdl NXcg_sphere_set.yaml -nyaml2nxdl NXcg_tetrahedron_set.yaml -nyaml2nxdl NXcg_triangle_set.yaml -nyaml2nxdl NXcg_triangulated_surface_mesh.yaml -nyaml2nxdl NXcg_unit_normal_set.yaml -nyaml2nxdl NXchamber.yaml -nyaml2nxdl NXchemical_composition.yaml -nyaml2nxdl NXchemical_process.yaml -nyaml2nxdl NXcircuit.yaml -nyaml2nxdl NXcircuit_board.yaml -nyaml2nxdl NXcollectioncolumn.yaml -nyaml2nxdl NXcomponent_em.yaml -nyaml2nxdl NXcontainer.yaml -nyaml2nxdl NXcoordinate_system.yaml -nyaml2nxdl NXcoordinate_system_set.yaml -nyaml2nxdl NXcorrector_cs.yaml -nyaml2nxdl NXcrystal_structure.yaml -nyaml2nxdl NXcs_computer.yaml -nyaml2nxdl NXcs_cpu.yaml -nyaml2nxdl NXcs_cpu_obj.yaml -nyaml2nxdl NXcs_cpu_sys.yaml -nyaml2nxdl NXcs_filter_boolean_mask.yaml -nyaml2nxdl NXcs_gpu.yaml -nyaml2nxdl NXcs_gpu_obj.yaml -nyaml2nxdl NXcs_gpu_sys.yaml -nyaml2nxdl NXcs_io_obj.yaml -nyaml2nxdl NXcs_io_sys.yaml -nyaml2nxdl NXcs_mm_obj.yaml -nyaml2nxdl NXcs_mm_sys.yaml -nyaml2nxdl NXcs_prng.yaml -nyaml2nxdl NXcs_profiling.yaml -nyaml2nxdl NXcs_profiling_event.yaml -nyaml2nxdl NXcsg.yaml -nyaml2nxdl NXcxi_ptycho.yaml -nyaml2nxdl NXdac.yaml -nyaml2nxdl NXdeflector.yaml -nyaml2nxdl NXdelocalization.yaml -nyaml2nxdl NXdispersion.yaml -nyaml2nxdl NXdispersion_function.yaml -nyaml2nxdl NXdispersion_repeated_parameter.yaml -nyaml2nxdl NXdispersion_single_parameter.yaml -nyaml2nxdl NXdispersion_table.yaml -nyaml2nxdl NXdispersive_material.yaml -nyaml2nxdl NXdistortion.yaml -nyaml2nxdl NXebeam_column.yaml -nyaml2nxdl NXelectronanalyser.yaml -nyaml2nxdl NXelectrostatic_kicker.yaml -nyaml2nxdl NXellipsometry.yaml -nyaml2nxdl NXem.yaml -nyaml2nxdl NXem_adf.yaml -nyaml2nxdl NXem_base.yaml -nyaml2nxdl NXem_conventions.yaml -nyaml2nxdl NXem_conventions_ebsd.yaml -nyaml2nxdl NXem_correlation.yaml -nyaml2nxdl NXem_ebsd.yaml -nyaml2nxdl NXem_eds.yaml -nyaml2nxdl NXem_eels.yaml -nyaml2nxdl NXem_img.yaml -nyaml2nxdl NXem_method.yaml -nyaml2nxdl NXem_msr.yaml -nyaml2nxdl NXem_sim.yaml -nyaml2nxdl NXenergydispersion.yaml -nyaml2nxdl NXevent_data_apm.yaml -nyaml2nxdl NXevent_data_apm_set.yaml -nyaml2nxdl NXevent_data_em.yaml -nyaml2nxdl NXevent_data_em_set.yaml -nyaml2nxdl NXfabrication.yaml -nyaml2nxdl NXfiber.yaml -nyaml2nxdl NXgraph_edge_set.yaml -nyaml2nxdl NXgraph_node_set.yaml -nyaml2nxdl NXgraph_root.yaml -nyaml2nxdl NXibeam_column.yaml -nyaml2nxdl NXidentifier.yaml -nyaml2nxdl NXimage_c_set.yaml -nyaml2nxdl NXimage_r_set.yaml -nyaml2nxdl NXimage_r_set_diff.yaml -nyaml2nxdl NXimage_set.yaml -nyaml2nxdl NXinteraction_vol_em.yaml -nyaml2nxdl NXion.yaml -nyaml2nxdl NXisocontour.yaml -nyaml2nxdl NXiv_bias.yaml -nyaml2nxdl NXiv_temp.yaml -nyaml2nxdl NXlab_electro_chemo_mechanical_preparation.yaml -nyaml2nxdl NXlab_sample_mounting.yaml -nyaml2nxdl NXlens_em.yaml -nyaml2nxdl NXlens_opt.yaml -nyaml2nxdl NXlockin.yaml -nyaml2nxdl NXmagnetic_kicker.yaml -nyaml2nxdl NXmanipulator.yaml -nyaml2nxdl NXmatch_filter.yaml -nyaml2nxdl NXmpes.yaml -nyaml2nxdl NXms.yaml -nyaml2nxdl NXms_feature_set.yaml -nyaml2nxdl NXms_ipf.yaml -nyaml2nxdl NXms_ipf_set.yaml -nyaml2nxdl NXms_mtex_config.yaml -nyaml2nxdl NXms_odf.yaml -nyaml2nxdl NXms_odf_set.yaml -nyaml2nxdl NXms_pf.yaml -nyaml2nxdl NXms_pf_set.yaml -nyaml2nxdl NXms_recon.yaml -nyaml2nxdl NXms_score_config.yaml -nyaml2nxdl NXms_score_results.yaml -nyaml2nxdl NXms_snapshot.yaml -nyaml2nxdl NXms_snapshot_set.yaml -nyaml2nxdl NXopt.yaml -nyaml2nxdl NXoptical_system_em.yaml -nyaml2nxdl NXpeak.yaml -nyaml2nxdl NXphysical_process.yaml -nyaml2nxdl NXpid.yaml -nyaml2nxdl NXpolarizer_opt.yaml -nyaml2nxdl NXpositioner_sts.yaml -nyaml2nxdl NXprogram.yaml -nyaml2nxdl NXpulser_apm.yaml -nyaml2nxdl NXpump.yaml -nyaml2nxdl NXquadric.yaml -nyaml2nxdl NXquadrupole_magnet.yaml -nyaml2nxdl NXreflectron.yaml -nyaml2nxdl NXregion.yaml -nyaml2nxdl NXregistration.yaml -nyaml2nxdl NXroi.yaml -nyaml2nxdl NXrotation_set.yaml -nyaml2nxdl NXsample_component_set.yaml -nyaml2nxdl NXsample_history.yaml -nyaml2nxdl NXscanbox_em.yaml -nyaml2nxdl NXsensor_scan.yaml -nyaml2nxdl NXsensor_sts.yaml -nyaml2nxdl NXseparator.yaml -nyaml2nxdl NXserialized.yaml -nyaml2nxdl NXsimilarity_grouping.yaml -nyaml2nxdl NXsingle_crystal.yaml -nyaml2nxdl NXslip_system_set.yaml -nyaml2nxdl NXsnsevent.yaml -nyaml2nxdl NXsnshisto.yaml -nyaml2nxdl NXsolenoid_magnet.yaml -nyaml2nxdl NXsolid_geometry.yaml -nyaml2nxdl NXspatial_filter.yaml -nyaml2nxdl NXspectrum_set.yaml -nyaml2nxdl NXspin_rotator.yaml -nyaml2nxdl NXspindispersion.yaml -nyaml2nxdl NXstage_lab.yaml -nyaml2nxdl NXsts.yaml -nyaml2nxdl NXsubsampling_filter.yaml -nyaml2nxdl NXsubstance.yaml -nyaml2nxdl NXtransmission.yaml -nyaml2nxdl NXunit_cell.yaml -nyaml2nxdl NXwaveplate.yaml -nyaml2nxdl NXxpcs.yaml -nyaml2nxdl NXxrd.yaml -nyaml2nxdl NXxrd_pan.yaml From 092580d1c61a4fe5f0dd5d528cfe92b35db2a822 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20K=C3=BChbach?= Date: Fri, 1 Mar 2024 17:27:04 +0100 Subject: [PATCH 0615/1012] Reverted unintentional change NXsensor.nxdl.xml --- base_classes/NXsensor.nxdl.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/base_classes/NXsensor.nxdl.xml b/base_classes/NXsensor.nxdl.xml index f1c552fd8f..3e01482037 100644 --- a/base_classes/NXsensor.nxdl.xml +++ b/base_classes/NXsensor.nxdl.xml @@ -123,7 +123,7 @@ - same dimensions as "value" (may be a vector) - + @@ -132,7 +132,7 @@ - same dimensions as "value" (may be a vector) - + From 7ff42ce6dec2632f79cc684743a785c63ada9668 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Markus=20K=C3=BChbach?= Date: Fri, 1 Mar 2024 17:30:56 +0100 Subject: [PATCH 0616/1012] Revert that was unintentionally changed NXdata.nxdl.xml --- base_classes/NXdata.nxdl.xml | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/base_classes/NXdata.nxdl.xml b/base_classes/NXdata.nxdl.xml index 0365e234ec..408eb3a2e5 100644 --- a/base_classes/NXdata.nxdl.xml +++ b/base_classes/NXdata.nxdl.xml @@ -236,9 +236,13 @@ without this attribute being set to "true".--> - - + + Each ``AXISNAME_indices`` attribute indicates the dependency relationship of the ``AXISNAME`` field (where ``AXISNAME`` From 9ae677d4174cfed2d3568703dcd9bd7768ed98ba Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 4 Mar 2024 08:08:11 +0100 Subject: [PATCH 0617/1012] remake NXsource.nxdl.xml --- base_classes/NXsource.nxdl.xml | 1 - base_classes/nyaml/NXsource.yaml | 5 +---- 2 files changed, 1 insertion(+), 5 deletions(-) diff --git a/base_classes/NXsource.nxdl.xml b/base_classes/NXsource.nxdl.xml index 23af0f81ff..2bf30550d3 100644 --- a/base_classes/NXsource.nxdl.xml +++ b/base_classes/NXsource.nxdl.xml @@ -214,7 +214,6 @@ - Is the synchrotron operating in top_up mode? diff --git a/base_classes/nyaml/NXsource.yaml b/base_classes/nyaml/NXsource.yaml index e2775b2491..be5527c006 100644 --- a/base_classes/nyaml/NXsource.yaml +++ b/base_classes/nyaml/NXsource.yaml @@ -120,8 +120,6 @@ NXsource(NXobject): doc: | for storage rings - # other sources could add to this - # other sources could add to this top_up(NX_BOOLEAN): doc: | @@ -193,7 +191,7 @@ NXsource(NXobject): other component groups. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# da3e78fa22a382a03ea3bf35a039da332f7ce5b1590f4b8a1c7419aef89d8ba5 +# 45f1f3aa580c93a57ab6b7b0f301f8e4b91e19c36f63e65109da961f88402285 # # # -# # # # Is the synchrotron operating in top_up mode? From 2140664fcce293a27125b24b166dd8e16b736a8f Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 4 Mar 2024 08:16:40 +0100 Subject: [PATCH 0618/1012] reset nyaml version --- requirements.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/requirements.txt b/requirements.txt index b90904cc68..d27f482456 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1,7 +1,7 @@ # Prepare for Documentation lxml pyyaml -nyaml@git+https://github.com/FAIRmat-NFDI/nyaml.git@7a2b92bc2c1c0e69e5878e479c4ea053c00eb5c3 +nyaml # Documentation building sphinx>=5 From e29a5c3ddfa814a887d45a9e4ef4943d5e946b47 Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 4 Mar 2024 09:20:42 +0100 Subject: [PATCH 0619/1012] Pin nyaml==0.0.8 --- requirements.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/requirements.txt b/requirements.txt index d27f482456..7603f693e9 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1,7 +1,7 @@ # Prepare for Documentation lxml pyyaml -nyaml +nyaml==0.0.8 # Documentation building sphinx>=5 From 9e0bf93a1c43f77120f0f3b957290f2a98bb4536 Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 4 Mar 2024 09:20:49 +0100 Subject: [PATCH 0620/1012] Regenerate nxdls --- contributed_definitions/NXapm.nxdl.xml | 36 ++-- .../NXapm_charge_state_analysis.nxdl.xml | 14 +- .../NXapm_hit_finding.nxdl.xml | 12 +- .../NXapm_paraprobe_clusterer_config.nxdl.xml | 14 +- ...NXapm_paraprobe_clusterer_results.nxdl.xml | 40 +++-- ...NXapm_paraprobe_distancer_results.nxdl.xml | 16 +- ...Xapm_paraprobe_intersector_config.nxdl.xml | 4 +- ...apm_paraprobe_intersector_results.nxdl.xml | 26 +-- .../NXapm_paraprobe_nanochem_config.nxdl.xml | 23 +-- .../NXapm_paraprobe_nanochem_results.nxdl.xml | 168 +++++++++--------- .../NXapm_paraprobe_ranger_results.nxdl.xml | 8 +- .../NXapm_paraprobe_selector_results.nxdl.xml | 6 +- .../NXapm_paraprobe_spatstat_config.nxdl.xml | 10 +- .../NXapm_paraprobe_spatstat_results.nxdl.xml | 24 +-- .../NXapm_paraprobe_surfacer_config.nxdl.xml | 6 +- .../NXapm_paraprobe_surfacer_results.nxdl.xml | 18 +- ...apm_paraprobe_tessellator_results.nxdl.xml | 36 ++-- .../NXapm_paraprobe_tool_results.nxdl.xml | 2 +- ...Xapm_paraprobe_transcoder_results.nxdl.xml | 14 +- .../NXapm_ranging.nxdl.xml | 2 +- .../NXapm_reconstruction.nxdl.xml | 6 +- .../NXapm_volt_and_bowl.nxdl.xml | 4 +- .../NXcg_alpha_complex.nxdl.xml | 6 +- .../NXcg_cylinder_set.nxdl.xml | 16 +- .../NXcg_ellipsoid_set.nxdl.xml | 4 +- .../NXcg_face_list_data_structure.nxdl.xml | 18 +- contributed_definitions/NXcg_grid.nxdl.xml | 14 +- .../NXcg_half_edge_data_structure.nxdl.xml | 20 +-- .../NXcg_hexahedron_set.nxdl.xml | 18 +- .../NXcg_parallelogram_set.nxdl.xml | 8 +- .../NXcg_point_set.nxdl.xml | 6 +- .../NXcg_polygon_set.nxdl.xml | 10 +- .../NXcg_polyhedron_set.nxdl.xml | 6 +- .../NXcg_polyline_set.nxdl.xml | 6 +- .../NXcg_primitive_set.nxdl.xml | 20 +-- .../NXcg_sphere_set.nxdl.xml | 2 +- .../NXcg_tetrahedron_set.nxdl.xml | 4 +- .../NXcg_triangle_set.nxdl.xml | 4 +- .../NXcg_unit_normal_set.nxdl.xml | 4 +- .../NXcoordinate_system.nxdl.xml | 6 +- .../NXcorrector_cs.nxdl.xml | 6 +- .../NXcrystal_structure.nxdl.xml | 18 +- .../NXcs_filter_boolean_mask.nxdl.xml | 4 +- .../NXcs_profiling_event.nxdl.xml | 4 +- .../NXdelocalization.nxdl.xml | 6 +- contributed_definitions/NXem.nxdl.xml | 6 +- contributed_definitions/NXem_adf.nxdl.xml | 2 +- .../NXem_conventions.nxdl.xml | 4 +- .../NXem_conventions_ebsd.nxdl.xml | 4 +- .../NXem_correlation.nxdl.xml | 8 +- contributed_definitions/NXem_ebsd.nxdl.xml | 27 +-- contributed_definitions/NXem_eds.nxdl.xml | 14 +- .../NXevent_data_apm.nxdl.xml | 14 +- .../NXgraph_edge_set.nxdl.xml | 10 +- .../NXgraph_node_set.nxdl.xml | 6 +- .../NXimage_c_set.nxdl.xml | 66 +++---- .../NXimage_r_set.nxdl.xml | 42 ++--- .../NXimage_r_set_diff.nxdl.xml | 6 +- contributed_definitions/NXion.nxdl.xml | 6 +- .../NXmatch_filter.nxdl.xml | 2 +- contributed_definitions/NXms.nxdl.xml | 6 +- .../NXms_feature_set.nxdl.xml | 44 +++-- contributed_definitions/NXms_ipf.nxdl.xml | 26 +-- .../NXms_mtex_config.nxdl.xml | 4 +- contributed_definitions/NXms_odf.nxdl.xml | 12 +- contributed_definitions/NXms_pf.nxdl.xml | 6 +- contributed_definitions/NXms_recon.nxdl.xml | 42 +++-- .../NXms_score_results.nxdl.xml | 18 +- .../NXoptical_system_em.nxdl.xml | 6 +- contributed_definitions/NXpeak.nxdl.xml | 4 +- contributed_definitions/NXpulser_apm.nxdl.xml | 35 ++-- .../NXrotation_set.nxdl.xml | 26 +-- contributed_definitions/NXscanbox_em.nxdl.xml | 6 +- .../NXsimilarity_grouping.nxdl.xml | 8 +- .../NXspectrum_set.nxdl.xml | 34 ++-- contributed_definitions/NXstage_lab.nxdl.xml | 2 +- .../NXsubsampling_filter.nxdl.xml | 2 +- 77 files changed, 636 insertions(+), 561 deletions(-) diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index a7f9e95e54..c6001743eb 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -244,7 +244,9 @@ the appdef definition here is nothing else then the documentation of this for a Magnitude of the standard deviation of the grain_diameter. - + The temperature of the last heat treatment step before quenching. @@ -652,13 +654,13 @@ NEW ISSUE: make this rather an own subentry NXapm_ranging--> - + - + @@ -707,18 +709,18 @@ we can only make recommendations--> - + - + - + @@ -775,7 +777,7 @@ i number of hits after hits finding but prior calibrations--> the ions were evaporated but taking into account that a hit_finding and spatial_filtering was applied. - + @@ -807,13 +809,13 @@ but not necessarily unprocessed timing data from the detector (unless individual 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--> - + - + @@ -834,7 +836,7 @@ Relevant for ranging are the calibrated data, thats why only these - + @@ -884,7 +886,7 @@ results--> - + @@ -905,26 +907,26 @@ results--> \@long_name:--> - + - + - + - + @@ -966,13 +968,13 @@ results--> - + - + diff --git a/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml b/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml index 864ec36205..0ad7d4d6ab 100644 --- a/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml +++ b/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml @@ -69,7 +69,7 @@ input/config--> used. Keep in mind though with such a weakly constrained parameter space the combinatorial analysis may become very time consuming! - + @@ -78,7 +78,7 @@ input/config--> Input constraint, interval within which (molecular) ions need to have the mass-to-charge-state-ratio such that an ion qualifies as a candidate. - + @@ -114,7 +114,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Signed charge, i.e. integer multiple of the elementary charge of each candidate. - + @@ -123,7 +123,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Table of nuclide instances of which each candidate is composed. Each row vector is sorted in descending order. Unused values are nullified. - + @@ -133,7 +133,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Accumulated mass of the nuclides in each candidate. Not corrected for quantum effects. - + @@ -141,7 +141,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> The product of the natural abundances of the nuclides for each candidate. - + @@ -150,7 +150,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> For each candidate the half life of that nuclide which has the shortest half life. - + diff --git a/contributed_definitions/NXapm_hit_finding.nxdl.xml b/contributed_definitions/NXapm_hit_finding.nxdl.xml index f320adda2d..7ea1adbfee 100644 --- a/contributed_definitions/NXapm_hit_finding.nxdl.xml +++ b/contributed_definitions/NXapm_hit_finding.nxdl.xml @@ -66,7 +66,7 @@ Alias tuple (begin, end) of each DLD wire of the detector. Order follows arrival_time_pairs. - + @@ -76,7 +76,7 @@ Raw readings from the analog-to-digital-converter timing circuits of the detector wires. - + @@ -88,7 +88,7 @@ Evaluated ion impact coordinates on the detector. Use the depends_on field to spec - + @@ -104,7 +104,7 @@ AMETEK/Cameca uses e.g. golden, multiple, partial, irrecoverable, and multi-first and multi-late. - + @@ -119,7 +119,7 @@ Hit quality identifier for each pulse. Identifier have to be within hit_quality_identifier. - + @@ -133,7 +133,7 @@ a molecular ion contains (which is instead encoded with the isotope_vector field of each :ref:`NXion` instance). - + diff --git a/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml index 2803362373..21897a43b9 100644 --- a/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml @@ -231,7 +231,7 @@ identifier(NX_UINT):--> In the simplest case, the matrix contains only the proton number of the element in the row, all other values set to zero. - + @@ -275,7 +275,7 @@ identifier(NX_UINT):--> Array of epsilon (eps) parameter values. - + @@ -283,7 +283,7 @@ identifier(NX_UINT):--> Array of minimum points (min_pts) parameter values. - + @@ -334,7 +334,7 @@ optics(NXprocess): Array of min_cluster_size parameter values. - + @@ -342,7 +342,7 @@ optics(NXprocess): Array of min_samples parameter values. - + @@ -350,7 +350,7 @@ optics(NXprocess): Array of cluster_selection parameter values. - + @@ -358,7 +358,7 @@ optics(NXprocess): Array of alpha parameter values. - + diff --git a/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml index 237670acdf..763a37b1c9 100644 --- a/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml @@ -107,7 +107,7 @@ of this array is not necessarily n_ions. Instead, it is the value of cardinality. - + @@ -120,7 +120,7 @@ tuples for each target that can be used to decode model_labels, core_sample_indices, and weight. - + @@ -133,7 +133,7 @@ multiple cluster this array is as long as the total number of solutions found and - + @@ -142,7 +142,7 @@ The raw array of core sample indices which specify which of the targets are core points. - + @@ -150,7 +150,7 @@ Numerical label for each target (member in the set) aka cluster identifier. - + @@ -158,7 +158,7 @@ Categorical label(s) for each target (member in the set) aka cluster name(s). - + @@ -172,29 +172,33 @@ should the position of the ion be accounted for because the ion is e.g. a molecular ion with several elements or nuclides of requested type. - + - + mask(NX_UINT): +--> Are targets assigned to the noise category or not. - + - + mask(NX_UINT): +--> Are targets assumed a core point. - + @@ -231,7 +235,7 @@ Numerical identifier of each feature aka cluster_identifier. - + @@ -239,7 +243,7 @@ Number of members for each feature. - + @@ -274,17 +278,17 @@ - + - + - + diff --git a/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml index d6f6bd42e1..011214db13 100644 --- a/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml @@ -80,7 +80,7 @@ The shortest analytical distance of each point to their respectively closest triangle from the joint triangle set. - + @@ -89,7 +89,7 @@ For each point the identifier of the triangle for which the shortest distance was found - + @@ -100,7 +100,7 @@ The field can be used to visualize the points as a function of their distance to the triangle set (e.g. via XDMF/Paraview). - + @@ -131,7 +131,7 @@ is not an integer multiple of bitdepth. If padding is used, padded bits are set to 0. - + @@ -148,7 +148,7 @@ the field mask of the NXcs_filter_boolean_mask is inherited that means its docst its unit category only the dimensions are constrained strong to match the number of objects triangles in this case--> - + @@ -181,17 +181,17 @@ triangles in this case--> - + - + - + diff --git a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml index 93103b62ee..6fcd29b4c5 100644 --- a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml @@ -180,7 +180,7 @@ Array of identifier whereby the path to the geometry data can be interferred automatically. - + @@ -245,7 +245,7 @@ Array of identifier whereby the path to the geometry data can be interferred automatically. - + diff --git a/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml index 0d11cfe57d..55b2aeea3c 100644 --- a/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml @@ -81,7 +81,7 @@ from the current_set have directed link(s) pointing to which named feature(s) from the next_set. - + @@ -92,7 +92,7 @@ link is due to volumetric overlap (0x00 == 0), proximity (0x01 == 1), or something else unknown (0xFF == 255). - + @@ -104,7 +104,7 @@ links are defined is symmetric it holds that next_to_current maps the links for current_to_next in just the opposite direction. - + @@ -115,7 +115,7 @@ link is due to a volumetric overlap (0x00 == 0), proximity (0x01 == 1), or something else unknown (0xFF == 255). - + @@ -125,7 +125,7 @@ intersection, i.e. how much volume do the two features share. If features do not intersect the volume is zero. - + @@ -162,7 +162,7 @@ encodes the cluster to which each feature_identifier was assigned. Here for features of the current_set. - + @@ -173,7 +173,7 @@ encodes the cluster to which each feature_identifier was assigned. Here for features of the next_set. - + @@ -182,7 +182,7 @@ The identifier (names) of the cluster. - + @@ -197,7 +197,7 @@ The third column encodes the total number of members in the cluster. - + @@ -212,7 +212,7 @@ The second column encodes how many clusters with as many members exist. - + @@ -253,17 +253,17 @@ - + - + - + diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml index 09af95498b..6334cb3869 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml @@ -250,7 +250,7 @@ identifier(NX_UINT):--> Unused values in each row of the matrix are nullified. Nuclides are identified as hashed nuclide (see :ref:`NXion`) for further details. - + @@ -261,7 +261,7 @@ identifier(NX_UINT):--> on a cuboidal 3D grid (:ref:`NXcg_grid`). The tool performs as many delocalization computations as values are specified in grid_resolution. - + @@ -279,7 +279,7 @@ identifier(NX_UINT):--> The tool performs as many delocalization computations as values are specified in kernel_variance. - + @@ -708,7 +708,7 @@ identifier(NX_UINT):--> Array of nuclide iontypes to filter. - + @@ -725,7 +725,7 @@ identifier(NX_UINT):--> which specify how the initial triangles of the mesh should be iteratively refined by edge splitting and related mesh refinement operations. - + @@ -740,7 +740,7 @@ identifier(NX_UINT):--> self-intersections may occur. The tool detects these and stops in a controlled manner so that the user can repeat the analyses with using a different parameterization. - + @@ -753,7 +753,7 @@ identifier(NX_UINT):--> parameter values to be used in the first DCOM iteration. The first entry of each array those for the second DCOM iteration and so on and so forth. - + @@ -958,7 +958,7 @@ identifier(NX_UINT):--> Explicit x, y, z coordinates (in the paraprobe coordinate system) where ROIs should be placed if feature is absent. - + @@ -968,12 +968,15 @@ identifier(NX_UINT):--> Explicit outer unit normal which explains into which direction each cylinder ROI is oriented. - + - + For each ROI, how high (projected on the cylinder axis) should the cylindrical ROI be. diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml index b7a4d1c398..8e4bdaaceb 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml @@ -136,7 +136,7 @@ The cardinality/total number of triangles in the triangle soup.--> - + @@ -153,7 +153,7 @@ The cardinality/total number of triangles in the triangle soup.--> The unit cell dimensions according to the coordinate system defined under coordinate_system. - + @@ -166,7 +166,7 @@ The cardinality/total number of triangles in the triangle soup.--> outside some masking primitive are removed, this extent field should not be used. Instead use the coordinate field. - + @@ -185,7 +185,7 @@ The cardinality/total number of triangles in the triangle soup.--> The shape of the kernel is that of a cuboid of extent 2*kernel_extent[i] + 1 in each dimension i. - + @@ -202,7 +202,7 @@ The cardinality/total number of triangles in the triangle soup.--> Standard deviation :math:`\sigma_i` of the kernel in each dimension in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. - + @@ -211,7 +211,7 @@ The cardinality/total number of triangles in the triangle soup.--> Expectation value :math:`\mu_i` of the kernel in each dimension in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. - + @@ -263,7 +263,7 @@ The cardinality/total number of triangles in the triangle soup.--> mesh even though many vertices are shared between triangles and thus the positions of these vertices do not have to be duplicated. - + @@ -281,7 +281,7 @@ The cardinality/total number of triangles in the triangle soup.--> the vertex identifiers for the i-th face on the following index interval of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. - + @@ -293,7 +293,7 @@ The cardinality/total number of triangles in the triangle soup.--> primitive count value (here 4 because each face is a quad). The remaining four values are the vertex indices. - + @@ -309,7 +309,7 @@ The cardinality/total number of triangles in the triangle soup.--> Name of the boundaries. E.g. left, right, front, back, bottom, top, The field must have as many entries as there are number_of_boundaries. - + @@ -324,7 +324,7 @@ The cardinality/total number of triangles in the triangle soup.--> 4 - von Neumann 5 - Dirichlet - + @@ -355,7 +355,7 @@ The cardinality/total number of triangles in the triangle soup.--> The actual delocalized intensity values. - + @@ -365,7 +365,7 @@ The cardinality/total number of triangles in the triangle soup.--> Cell center of mass positions along x. - + @@ -373,7 +373,7 @@ The cardinality/total number of triangles in the triangle soup.--> Cell center of mass positions along y. - + @@ -381,7 +381,7 @@ The cardinality/total number of triangles in the triangle soup.--> Cell center of mass positions along z. - + @@ -389,7 +389,7 @@ The cardinality/total number of triangles in the triangle soup.--> Intensity of the field at given point - + @@ -398,7 +398,7 @@ The cardinality/total number of triangles in the triangle soup.--> Center of mass positions of each voxel for rendering the scalar field via XDMF in e.g. Paraview. - + @@ -408,7 +408,7 @@ The cardinality/total number of triangles in the triangle soup.--> XDMF topology for rendering in combination with xdmf_xyz the scalar field via XDMF in e.g. Paraview. - + @@ -428,7 +428,7 @@ The cardinality/total number of triangles in the triangle soup.--> The actual point-wise component values. - + @@ -439,7 +439,7 @@ The cardinality/total number of triangles in the triangle soup.--> Cell center of mass positions along x. - + @@ -447,7 +447,7 @@ The cardinality/total number of triangles in the triangle soup.--> Cell center of mass positions along y. - + @@ -455,7 +455,7 @@ The cardinality/total number of triangles in the triangle soup.--> Cell center of mass positions along z. - + @@ -464,7 +464,7 @@ The cardinality/total number of triangles in the triangle soup.--> The gradient vector formatted for direct visualization via XDMF in e.g. Paraview. - + @@ -474,7 +474,7 @@ The cardinality/total number of triangles in the triangle soup.--> Center of mass positions of each voxel for rendering the scalar field gradient via XDMF in e.g. Paraview. - + @@ -484,7 +484,7 @@ The cardinality/total number of triangles in the triangle soup.--> XDMF topology for rendering in combination with xdmf_xyz the scalar field via XDFM in e.g. Paraview. - + @@ -550,7 +550,7 @@ The cardinality/total number of triangles in the triangle soup.--> case vertices_are_unique is likely False. Naively here means that each vertex is stored even though many share the same positions. - + @@ -568,7 +568,7 @@ The cardinality/total number of triangles in the triangle soup.--> the vertex identifiers for the i-th face on the following index interval of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. - + @@ -578,7 +578,7 @@ The cardinality/total number of triangles in the triangle soup.--> of vertices and a triple of vertex indices specifying each triangle. The total number of entries is n_f_tri * (1+1+3). - + @@ -587,7 +587,7 @@ The cardinality/total number of triangles in the triangle soup.--> Direction of each normal. - + @@ -601,7 +601,7 @@ The cardinality/total number of triangles in the triangle soup.--> * 1 - outer * 2 - inner - + @@ -613,7 +613,7 @@ The cardinality/total number of triangles in the triangle soup.--> Direction of each normal. - + @@ -627,7 +627,7 @@ The cardinality/total number of triangles in the triangle soup.--> * 1 - outer * 2 - inner - + @@ -637,7 +637,7 @@ The cardinality/total number of triangles in the triangle soup.--> gradient vector of the local delocalized scalar field. :math:`\sum_{x, y, z} {\nabla{c}_i}^2`. - + @@ -660,13 +660,13 @@ The cardinality/total number of triangles in the triangle soup.--> that is especially useful to document those triangles for whose the projection is almost perpendicular. - + - + @@ -676,7 +676,7 @@ The cardinality/total number of triangles in the triangle soup.--> is reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -688,7 +688,7 @@ The cardinality/total number of triangles in the triangle soup.--> traversed according to the sequence in which vertices are indexed in triangles. - + @@ -697,7 +697,7 @@ The cardinality/total number of triangles in the triangle soup.--> The center of mass of each triangle. - + @@ -735,7 +735,7 @@ The cardinality/total number of triangles in the triangle soup.--> returned, which constitutes the first step of the volumetric_feature identification process. - + @@ -743,7 +743,7 @@ The cardinality/total number of triangles in the triangle soup.--> The array of keywords of feature_type dictionary. - + @@ -752,7 +752,7 @@ The cardinality/total number of triangles in the triangle soup.--> The array of values for each keyword of the feature_type dictionary. - + @@ -763,7 +763,7 @@ The cardinality/total number of triangles in the triangle soup.--> each feature triangle cluster belongs to. Keep in mind that not each feature is an object or proxy. - + @@ -771,7 +771,7 @@ The cardinality/total number of triangles in the triangle soup.--> The explicit identifier of features. - + @@ -793,7 +793,7 @@ The cardinality/total number of triangles in the triangle soup.--> Explicit identifier of the feature a sub-set of the feature_identifier in the parent group. - + @@ -801,7 +801,7 @@ The cardinality/total number of triangles in the triangle soup.--> Volume of the feature. NaN for non-watertight objects. - + @@ -813,7 +813,7 @@ The cardinality/total number of triangles in the triangle soup.--> Edge length of the oriented bounding box from largest to smallest value. - + @@ -823,7 +823,7 @@ The cardinality/total number of triangles in the triangle soup.--> Oriented bounding box aspect ratio. YX versus ZY or second-largest over largest and smallest over second largest. - + @@ -834,7 +834,7 @@ The cardinality/total number of triangles in the triangle soup.--> not necessarily has to be the center_of_mass of the hexahedrally-shaped sample/sample part. - + @@ -845,7 +845,7 @@ The cardinality/total number of triangles in the triangle soup.--> is to store the shape of the hexahedra for visualization. - + @@ -853,12 +853,12 @@ The cardinality/total number of triangles in the triangle soup.--> - + - + @@ -871,30 +871,30 @@ number_of_faces(NX_POSINT): vertex_identifier_offset(NX_UINT): face_identifier_offset(NX_UINT):--> - + - + - + - + - + @@ -903,7 +903,7 @@ face_identifier_offset(NX_UINT):--> Array of evaporation_identifier / ion_identifier which details which ions lie inside or on the surface of the feature. - + @@ -915,7 +915,7 @@ face_identifier_offset(NX_UINT):--> Total (count) of ions inside or on the surface of the feature relevant for normalization. NaN for non watertight objects. - + @@ -929,7 +929,7 @@ face_identifier_offset(NX_UINT):--> Count or weight which, when divided by total, yields the composition of this element, nuclide, or (molecular) ion within the volume of the feature/object. - + @@ -962,7 +962,7 @@ face_identifier_offset(NX_UINT):--> location considering that the spatial resolution of atom probe experiments is limited. - + @@ -971,7 +971,7 @@ face_identifier_offset(NX_UINT):--> The multiplicity whereby the ion position is accounted for when the ion is considered one which is a decorator of the interface. - + @@ -984,7 +984,7 @@ face_identifier_offset(NX_UINT):--> The four parameter :math:`ax + by + cz + d = 0` which define the plane. - + @@ -1013,12 +1013,12 @@ face_identifier_offset(NX_UINT):--> - + - + @@ -1027,7 +1027,7 @@ face_identifier_offset(NX_UINT):--> Direction of each vertex normal. - + @@ -1041,12 +1041,12 @@ face_identifier_offset(NX_UINT):--> * 1 - outer * 2 - inner - + - + @@ -1055,7 +1055,7 @@ face_identifier_offset(NX_UINT):--> Direction of each face normal. - + @@ -1069,18 +1069,18 @@ face_identifier_offset(NX_UINT):--> * 1 - outer * 2 - inner - + - + - + @@ -1090,7 +1090,7 @@ face_identifier_offset(NX_UINT):--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -1101,7 +1101,7 @@ face_identifier_offset(NX_UINT):--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + @@ -1129,7 +1129,7 @@ face_identifier_offset(NX_UINT):--> Position of the geometric center, which often is but not necessarily has to be the center_of_mass of the polyhedra. - + @@ -1139,13 +1139,13 @@ face_identifier_offset(NX_UINT):--> Integer which specifies the first index to be used for distinguishing ROI cylinder explicitly. - + - + @@ -1153,7 +1153,7 @@ face_identifier_offset(NX_UINT):--> The number of atoms in each ROI. - + @@ -1161,7 +1161,7 @@ face_identifier_offset(NX_UINT):--> The number of ions in each ROI. - + @@ -1170,7 +1170,7 @@ face_identifier_offset(NX_UINT):--> The orientation of the ROI defined via a vector which points along the cylinder axis and whose length is the height of the cylinder. - + @@ -1184,7 +1184,7 @@ face_identifier_offset(NX_UINT):--> In the direction of the ROI. - + @@ -1192,7 +1192,7 @@ face_identifier_offset(NX_UINT):--> Hashvalue using the following hashing rule :math:`H = Z + 256 * N`. - + @@ -1234,17 +1234,17 @@ face_identifier_offset(NX_UINT):--> - + - + - + diff --git a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml index f7f00a5dde..de5680a967 100644 --- a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml @@ -79,7 +79,7 @@ config--> ion in such a way that only the those elements are considered of which a (molecular) ion is assumed composed according to the NXion instances. - + @@ -118,17 +118,17 @@ config--> - + - + - + diff --git a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml index bd22c5f762..5630291783 100644 --- a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml @@ -90,17 +90,17 @@ - + - + - + diff --git a/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml index fde38f7810..5f4b26836a 100644 --- a/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml @@ -245,7 +245,7 @@ identifier(NX_UINT):--> recover usual spatial correlation statistics like the 1NN C-C spatial statistics. - + @@ -276,7 +276,7 @@ identifier(NX_UINT):--> iontypes to distinguish as possible targets. See additional comments under ion_query_isotope_vector_source. - + @@ -298,8 +298,7 @@ identifier(NX_UINT):--> Minimum value, increment, and maximum value of the histogram binning. - - + @@ -312,8 +311,7 @@ identifier(NX_UINT):--> Minimum value, increment, and maximum value of the histogram binning. - - + diff --git a/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml index 7a3613508a..be81d48063 100644 --- a/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml @@ -65,7 +65,7 @@ n_bins_knn: | as it is specified in the configuration settings inside the specific config_filename that was used for this paraprobe-spatstat analysis. - + @@ -77,12 +77,12 @@ n_bins_knn: | Right boundary of the binning. - + - + @@ -90,7 +90,7 @@ n_bins_knn: | Cumulated not normalized by total counts. - + @@ -98,7 +98,7 @@ n_bins_knn: | Cumulated and normalized by total counts. - + @@ -111,12 +111,12 @@ n_bins_knn: | Right boundary of the binning. - + - + @@ -124,7 +124,7 @@ n_bins_knn: | Cumulated not normalized by total counts. - + @@ -132,7 +132,7 @@ n_bins_knn: | Cumulated and normalized by total counts. - + @@ -172,17 +172,17 @@ n_bins_knn: | - + - + - + diff --git a/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml index f11888d77a..3cb04dac60 100644 --- a/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml @@ -184,8 +184,7 @@ Array of alpha values to use when alpha_value_choice is set_of_values or when alpha_value_choice is set_of_alpha_wrappings. - - + @@ -194,8 +193,7 @@ Array of offset values to use when alpha_value_choice is set_of_alpha_wrappings. The array of alpha_values and offset_values define a sequence of (alpha and offset value). - - + diff --git a/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml index 1e2d37f5f9..fa2bbd8825 100644 --- a/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml @@ -121,7 +121,7 @@ for eventually performed preprocessing--> The bitfield of the mask. See :ref:`NXcs_filter_boolean_mask` for how this bitfield is to be interpreted. - + @@ -162,13 +162,13 @@ for eventually performed preprocessing--> - + - + @@ -179,7 +179,7 @@ for eventually performed preprocessing--> of vertices and a triple of vertex indices specifying each triangle. The total number of entries is n_f_tri * (1+1+3). - + @@ -213,7 +213,7 @@ for eventually performed preprocessing--> - + @@ -224,7 +224,7 @@ for eventually performed preprocessing--> of vertices and a triple of vertex indices specifying each triangle. The total number of entries is n_f_tet * (1+1+4). - + @@ -268,17 +268,17 @@ For the future as we may wish to wrap primitives other like triangles or polylin - + - + - + diff --git a/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml index b7151753c1..dbfa7dc94c 100644 --- a/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml @@ -82,7 +82,7 @@ Coordinate triplet of the corner that lays closests to the origin of the *paraprobe* coordinate system. - + @@ -91,7 +91,7 @@ Coordinate triplet of the corner that lays farthest away from the origin of the *paraprobe* coordinate system. - + @@ -111,7 +111,7 @@ Volume of each Voronoi cell. - + @@ -119,7 +119,7 @@ Which MPI process computed which Voronoi cell. - + @@ -127,7 +127,7 @@ Which OpenMP thread computed which Voronoi cell. - + @@ -137,7 +137,7 @@ for each polyhedron. This field can be used to interpret the concatenated vector with the individual values for the area of each face. - + @@ -162,7 +162,7 @@ Third, the sequence of vertex identifier which define the facet. Tuples encode faces faster than cells. - + @@ -175,7 +175,7 @@ thus correlate per-ion properties with the volume that each cell represents. - + @@ -188,7 +188,7 @@ that document contact in specific outer unit normal directions of the *aabb*. - + @@ -204,7 +204,7 @@ dim: (i,) # one would not need to constrain this but doing so communicates that x-axis of the *paraprobe* coordinate system. - + @@ -218,7 +218,7 @@ dim: (i,) # one would not need to constrain this but doing so communicates that of the *paraprobe* coordinate system. - + @@ -232,7 +232,7 @@ dim: (i,) # one would not need to constrain this but doing so communicates that y-axis of the *paraprobe* coordinate system. - + @@ -246,7 +246,7 @@ dim: (i,) # one would not need to constrain this but doing so communicates that of the *paraprobe* coordinate system. - + @@ -260,7 +260,7 @@ dim: (i,) # one would not need to constrain this but doing so communicates that z-axis of the *paraprobe* coordinate system. - + @@ -274,7 +274,7 @@ dim: (i,) # one would not need to constrain this but doing so communicates that *paraprobe* coordinate system. - + @@ -316,17 +316,17 @@ dim: (i,) # one would not need to constrain this but doing so communicates that - + - + - + diff --git a/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml index 7ea9f4f4bd..2ac82f751a 100644 --- a/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml @@ -78,7 +78,7 @@ symbols: The mask. The length of the mask is an integer multiple of bitdepth. In such case, padded bits are set to 0. - + diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml index 42b0fa9c9c..10609e371d 100644 --- a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml @@ -104,7 +104,7 @@ config--> Mass-to-charge-state-ratio values. - + @@ -115,7 +115,7 @@ config--> Three-dimensional reconstructed positions of the ions. Interleaved array of x, y, z positions in the specimen space. - + @@ -133,7 +133,7 @@ config--> 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. - + @@ -149,7 +149,7 @@ config--> - + @@ -193,17 +193,17 @@ config--> - + - + - + diff --git a/contributed_definitions/NXapm_ranging.nxdl.xml b/contributed_definitions/NXapm_ranging.nxdl.xml index acc4bc87d7..ab3a8afafe 100644 --- a/contributed_definitions/NXapm_ranging.nxdl.xml +++ b/contributed_definitions/NXapm_ranging.nxdl.xml @@ -61,7 +61,7 @@ Smallest, increment, and largest mass-to-charge-state ratio value. - + diff --git a/contributed_definitions/NXapm_reconstruction.nxdl.xml b/contributed_definitions/NXapm_reconstruction.nxdl.xml index 1de66d16b1..03f5ff7091 100644 --- a/contributed_definitions/NXapm_reconstruction.nxdl.xml +++ b/contributed_definitions/NXapm_reconstruction.nxdl.xml @@ -83,7 +83,9 @@ - + The nominal diameter of the specimen ROI which is measured in the experiment. The physical specimen cannot be measured completely @@ -94,7 +96,7 @@ Three-dimensional reconstructed positions of the ions. - + diff --git a/contributed_definitions/NXapm_volt_and_bowl.nxdl.xml b/contributed_definitions/NXapm_volt_and_bowl.nxdl.xml index df8c1ca1a9..f317e76cbc 100644 --- a/contributed_definitions/NXapm_volt_and_bowl.nxdl.xml +++ b/contributed_definitions/NXapm_volt_and_bowl.nxdl.xml @@ -54,7 +54,7 @@ result--> Raw time-of-flight data without corrections. - + @@ -62,7 +62,7 @@ result--> Calibrated time-of-flight. - + diff --git a/contributed_definitions/NXcg_alpha_complex.nxdl.xml b/contributed_definitions/NXcg_alpha_complex.nxdl.xml index 9446cdd8b6..b6a466bc58 100644 --- a/contributed_definitions/NXcg_alpha_complex.nxdl.xml +++ b/contributed_definitions/NXcg_alpha_complex.nxdl.xml @@ -74,8 +74,10 @@ stating meter is a stronger constraint while m is the strongest constraint, mean - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/contributed_definitions/NXcg_cylinder_set.nxdl.xml b/contributed_definitions/NXcg_cylinder_set.nxdl.xml index f87f5f7ac3..e5bb83807a 100644 --- a/contributed_definitions/NXcg_cylinder_set.nxdl.xml +++ b/contributed_definitions/NXcg_cylinder_set.nxdl.xml @@ -52,7 +52,7 @@ cylinder could be constructed, but NXcylinder is easier to understand--> A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - + @@ -77,7 +77,7 @@ one should really better use NXquadric...--> Radii of the cylinder. - + @@ -88,7 +88,7 @@ one should really better use NXquadric...--> This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -99,7 +99,7 @@ one should really better use NXquadric...--> This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -108,7 +108,7 @@ one should really better use NXquadric...--> Lateral surface area - + @@ -116,7 +116,7 @@ one should really better use NXquadric...--> Area of the upper cap of each cylinder. - + @@ -124,7 +124,7 @@ one should really better use NXquadric...--> Area of the lower cap of each cylinder. - + @@ -133,7 +133,7 @@ one should really better use NXquadric...--> Sum of upper and lower cap areas and lateral surface area of each cylinder. - + diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml index f613be7ecf..e22a677c11 100644 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -48,7 +48,7 @@ redundant as there is NXcsg, and NXquadric but easier to understand--> Use if all ellipsoids in the set have the same half-axes. - + @@ -56,7 +56,7 @@ redundant as there is NXcsg, and NXquadric but easier to understand--> Half-axes radii of each ellipsoid. - + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml index a452dc99f5..48610a31d2 100644 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -94,7 +94,7 @@ duplicate of an NXoff_geometry ?--> Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -105,7 +105,7 @@ duplicate of an NXoff_geometry ?--> Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -145,7 +145,7 @@ duplicate of an NXoff_geometry ?--> Integer identifier to distinguish all vertices explicitly. - + @@ -153,7 +153,7 @@ duplicate of an NXoff_geometry ?--> Integer used to distinguish all edges explicitly. - + @@ -161,7 +161,7 @@ duplicate of an NXoff_geometry ?--> Integer used to distinguish all faces explicitly. - + @@ -175,7 +175,7 @@ duplicate of an NXoff_geometry ?--> case vertices_are_unique is likely False. Naively here means that each vertex is stored even though many share the same positions. - + @@ -184,7 +184,7 @@ duplicate of an NXoff_geometry ?--> The edges are stored as pairs of vertex identifier. - + @@ -202,7 +202,7 @@ duplicate of an NXoff_geometry ?--> the vertex identifiers for the i-th face on the following index interval of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. - + @@ -234,7 +234,7 @@ duplicate of an NXoff_geometry ?--> * 1 - counter-clockwise (CCW) * 2 - clock-wise (CW) - + diff --git a/contributed_definitions/NXcg_grid.nxdl.xml b/contributed_definitions/NXcg_grid.nxdl.xml index 894250e158..4d5aced5fe 100644 --- a/contributed_definitions/NXcg_grid.nxdl.xml +++ b/contributed_definitions/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml index 26e307d082..40213352e3 100644 --- a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml index e7569c6281..8ea85fb981 100644 --- a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -89,7 +89,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Qualifier for the shape of each hexahedron. - + @@ -100,7 +100,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> edges of the hexahedra. Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -112,7 +112,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> For the sake of explicitness quantities like length, width, and height should not be reported without specifying also the assumed reference frame. - + @@ -121,7 +121,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Qualifier often used to describe the extent of an object in the vertical direction assuming a specific coordinate system. - + @@ -129,7 +129,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Volume of each hexahedron. - + @@ -137,7 +137,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Total (surface) area (of all six faces) of each hexahedron. - + @@ -145,7 +145,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the six faces of each hexahedron. - + @@ -155,7 +155,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Specifies if the hexahedra represent cuboids or cubes eventually rotated ones but at least not too exotic six-faced polyhedra. - + @@ -165,7 +165,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> whether hexahedra are boxes whose primary edges are parallel to the axes of the coordinate system. - + diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml index 3709be64d4..bfb868c47d 100644 --- a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml +++ b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml @@ -73,7 +73,7 @@ To specify which parallelogram is a rectangle. - + @@ -83,13 +83,15 @@ describes whether parallelograms are rectangles whose primary edges are parallel to the axes of the coordinate system. - + - + Combined storage of all primitives of all parallelograms. diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml index 5d8a15310b..c2190590d0 100644 --- a/contributed_definitions/NXcg_point_set.nxdl.xml +++ b/contributed_definitions/NXcg_point_set.nxdl.xml @@ -54,7 +54,7 @@ Coordinates of the points. - + @@ -66,7 +66,7 @@ If the field time is needed contextualize the time_offset relative to which time values are defined. Alternative store timestamp. - + @@ -74,7 +74,7 @@ ISO8601 with local time zone offset for each point. - + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index c708108320..95c157ce1e 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -46,7 +46,9 @@ descriptors.--> - + Computational geometry description of a set of polygons in Euclidean space. @@ -98,7 +100,7 @@ descriptors.--> For each polygon its accumulated length along its edges. - + @@ -110,7 +112,7 @@ descriptors.--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -122,7 +124,7 @@ descriptors.--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index 00eaec95ac..b087b0c790 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -69,7 +69,7 @@ for clean graph-based descriptions of polyhedra.--> The number of faces for each polyhedron. Faces of adjoining polyhedra are counted for each polyhedron. - + @@ -77,7 +77,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of faces. - + @@ -91,7 +91,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge. - + diff --git a/contributed_definitions/NXcg_polyline_set.nxdl.xml b/contributed_definitions/NXcg_polyline_set.nxdl.xml index d075365882..64a002f86c 100644 --- a/contributed_definitions/NXcg_polyline_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index 93b35cfefa..e8cb457bc1 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index 58d4d57968..8b12834749 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -54,7 +54,7 @@ redundant as there is NXcsg, and NXquadric but easier to understand--> In the case that spheres have different radius use this instead of the radius field. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index 34c5d8ca7c..509347c515 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -44,7 +44,7 @@ Area of each of the four triangular faces of each tetrahedron. - + @@ -53,7 +53,7 @@ Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index fe215dd3ee..7d994eb3e9 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -77,7 +77,7 @@ properties of triangles--> For each triangle values are reported via traversing the vertices in the sequence as these are defined. - + @@ -89,7 +89,7 @@ properties of triangles--> For each triangle values are reported for the angle opposite to the respective edges in the sequence how vertices are defined. - + diff --git a/contributed_definitions/NXcg_unit_normal_set.nxdl.xml b/contributed_definitions/NXcg_unit_normal_set.nxdl.xml index 6da20e5488..21470b34f0 100644 --- a/contributed_definitions/NXcg_unit_normal_set.nxdl.xml +++ b/contributed_definitions/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 97f1ebd1a5..494b92956e 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 10de965773..94c9b891f2 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -76,7 +76,7 @@ TODO: The relevant axes which span the tilt_angle need a cleaner description. - + @@ -84,7 +84,7 @@ The exposure time of single tilt images. - + @@ -93,7 +93,7 @@ The factor of enlargement of the apparent size, not the physical size, of an object. - + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 972ed60805..921663cef6 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -81,7 +81,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 01b9b74b55..46f8774235 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -94,7 +94,7 @@ The content of the mask. If padding is used, padding bits have to be set to 0. - + @@ -107,7 +107,7 @@ the conventions made for depends_on, so consult also the description of th content to which depends_on refers. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 9be27b32d4..9da91f9c04 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -83,7 +83,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -91,7 +91,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index b339ae40a1..7f7fbdf77a 100644 --- a/contributed_definitions/NXdelocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -114,7 +114,7 @@ and the interpretation model that to consider carbon atoms or carbon ions--> with :math:`$Z$` the number of protons and :math:`$N$` the number of neutrons of the nuclide. For elements set :math:`$N$` to zero. - + @@ -124,7 +124,7 @@ and the interpretation model that to consider carbon atoms or carbon ions--> iontypes generated via ranging. The number of mark data per point is 1 in the case for atom probe. - + @@ -136,7 +136,7 @@ and the interpretation model that to consider carbon atoms or carbon ions--> positive integer values, specifically the multiplicity of the ion, according to the details of the weighting_method. - + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 9529540a22..bb45ab5539 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -226,12 +226,14 @@ where scientists just store conventions without a default plot--> - +citation: doi ->why relevant, should be solved by RDMS +--> A description of the material characterized in the experiment. Sample and specimen are threaded as de facto synonyms. diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_adf.nxdl.xml index 3f6002abcf..8d6649fda9 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_adf.nxdl.xml @@ -55,7 +55,7 @@ Annulus inner (first value) and outer (second value) half angle. - + diff --git a/contributed_definitions/NXem_conventions.nxdl.xml b/contributed_definitions/NXem_conventions.nxdl.xml index 41321063b7..1c948affc4 100644 --- a/contributed_definitions/NXem_conventions.nxdl.xml +++ b/contributed_definitions/NXem_conventions.nxdl.xml @@ -55,7 +55,9 @@ and they should whenever possible be as simple as possible and as few as possible to support users with understanding the content of the application definition.--> - + Conventions for rotations and coordinate systems to interpret crystal orientation and other data and results collected with electron microscopy research. diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml index b00b7ea925..d2d7456aaa 100644 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -22,7 +22,9 @@ # For further information, see http://www.nexusformat.org --> - + Base class for method-specific conventions EBSD. diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index e9bd12b89a..95a644b519 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index 685aee0b67..33c8b9cb3c 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -358,7 +358,7 @@ pattern_available(NX_BOOLEAN): * 100 - Success * 255 - Unexpected errors - + @@ -380,7 +380,7 @@ pattern_available(NX_BOOLEAN): phase_identifier has as many entries as scan points and phase_matching has also as many entries as scan points. - + @@ -409,7 +409,7 @@ pattern_available(NX_BOOLEAN): the 1-th scan point, the n_sc - 1 th scan point and omitting tuples for those scan points with no phases according to n_phases_per_scan_point - + @@ -420,7 +420,7 @@ pattern_available(NX_BOOLEAN): how the phase_identifier and the phase_matching arrays have to be interpreted. See documentation of phase_identifier for further details. - + @@ -438,19 +438,24 @@ pattern_available(NX_BOOLEAN): - + - +to sample_reference_frame +--> Calibrated center positions of each scan point in the sample surface reference system. - + @@ -502,7 +507,7 @@ to sample_reference_frame--> Descriptor values displaying the ROI. - + @@ -519,7 +524,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -532,7 +537,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml index bd93d61efe..43cde1ab9f 100644 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -80,7 +80,7 @@ and Adrien Teutrie, Cecile Hebert (EPFL)--> Accumulated counts - + @@ -93,7 +93,7 @@ and Adrien Teutrie, Cecile Hebert (EPFL)--> Energy axis - + @@ -116,7 +116,7 @@ and Adrien Teutrie, Cecile Hebert (EPFL)--> Associated lower :math:`[e_{min}, e_{max}]` bounds of the energy which is assumed associated with this peak. - + @@ -132,7 +132,7 @@ and Adrien Teutrie, Cecile Hebert (EPFL)--> This can be a list of IUPAC notations for (the seldom) case that multiple lines are grouped with the same peak. - + @@ -147,7 +147,7 @@ and Adrien Teutrie, Cecile Hebert (EPFL)--> However, a collection of instances of NXpeak with individual NXion specified enables also to distinguish isotopic information. - + @@ -194,7 +194,7 @@ therefore we use for now the--> Associated :math:`[e_{min}, e_{max}]` bounds of the energy range for which spectrum counts have been accumulated. - + @@ -205,7 +205,7 @@ therefore we use for now the--> where accumulated for each pixel which yields an element-specific EDS map. - + diff --git a/contributed_definitions/NXevent_data_apm.nxdl.xml b/contributed_definitions/NXevent_data_apm.nxdl.xml index 002c112f94..878a5c3ff0 100644 --- a/contributed_definitions/NXevent_data_apm.nxdl.xml +++ b/contributed_definitions/NXevent_data_apm.nxdl.xml @@ -100,7 +100,7 @@ and pulse_identifier exactly specifies the connection between when a pulse was issued relative to start and absolute in UTC. - + @@ -149,7 +149,7 @@ vector with two values one for the first and another one for the value from the 100000-th pulse onwards. The values of pulse_identifier are then [0, 99999] respectively. - + @@ -181,7 +181,7 @@ within ATO files. The ATO file format is used primarily by the atom probe groups of the GPM in Rouen, France. - + @@ -214,7 +214,7 @@ but for atom probe if at all the pulse-based implicit time is available--> sample base (furthest point along sample apex and holding assembly that is removable from the sample stage). - + @@ -234,7 +234,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -249,7 +249,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -264,7 +264,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index cd321bd171..bd59185528 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -66,7 +66,7 @@ Integer used to distinguish edges for explicit indexing. - + @@ -80,7 +80,7 @@ * 1 / state 0x01 is one-directional * 2 / state 0x02 is bi-directional - + @@ -96,7 +96,7 @@ stored such that the identifier of the source node is the first entry and the identifier of the target is the second entry in the pair. - + @@ -106,7 +106,7 @@ A human-readable qualifier which type or e.g. class instance the edge is an instance of. - + @@ -114,7 +114,7 @@ A human-readable label/caption/tag of each edge. - + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index 8cc242220b..d234097946 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -91,7 +91,7 @@ Integer used to distinguish nodes for explicit indexing. - + @@ -103,7 +103,7 @@ Instances which are groups like :ref:`NXgraph_node_set` could have an is_a qualifier reading :ref:`NXgraph_node_set`. - + @@ -111,7 +111,7 @@ A human-readable label/caption/tag of each node. - + diff --git a/contributed_definitions/NXimage_c_set.nxdl.xml b/contributed_definitions/NXimage_c_set.nxdl.xml index 5527498a23..c6837e47ab 100644 --- a/contributed_definitions/NXimage_c_set.nxdl.xml +++ b/contributed_definitions/NXimage_c_set.nxdl.xml @@ -80,7 +80,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the real part. - + @@ -88,7 +88,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the imaginary part. - + @@ -96,7 +96,7 @@ process information are composable from the NXimage_set base class--> Magnitude of the image intensity. - + @@ -104,7 +104,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along i direction. - + @@ -122,7 +122,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the real part. - + @@ -131,7 +131,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the imaginary part. - + @@ -140,7 +140,7 @@ process information are composable from the NXimage_set base class--> Magnitude of the image intensity. - + @@ -149,7 +149,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along j direction. - + @@ -162,7 +162,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along i direction. - + @@ -180,7 +180,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the real part. - + @@ -190,7 +190,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the imaginary part. - + @@ -200,7 +200,7 @@ process information are composable from the NXimage_set base class--> Magnitude of the image intensity. - + @@ -210,7 +210,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along k direction. - + @@ -223,7 +223,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along j direction. - + @@ -236,7 +236,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along i direction. - + @@ -254,7 +254,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the real part. - + @@ -263,7 +263,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the imaginary part. - + @@ -272,7 +272,7 @@ process information are composable from the NXimage_set base class--> Magnitude of the image intensity. - + @@ -281,7 +281,7 @@ process information are composable from the NXimage_set base class--> Image identifier - + @@ -294,7 +294,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along i direction. - + @@ -312,7 +312,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the real part. - + @@ -322,7 +322,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the imaginary part. - + @@ -332,7 +332,7 @@ process information are composable from the NXimage_set base class--> Magnitude of the image intensity. - + @@ -342,7 +342,7 @@ process information are composable from the NXimage_set base class--> Image identifier - + @@ -355,7 +355,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along j direction. - + @@ -368,7 +368,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along i direction. - + @@ -386,7 +386,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the real part. - + @@ -397,7 +397,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the imaginary part. - + @@ -408,7 +408,7 @@ process information are composable from the NXimage_set base class--> Magnitude of the image intensity. - + @@ -419,7 +419,7 @@ process information are composable from the NXimage_set base class--> Image identifier - + @@ -432,7 +432,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along k direction. - + @@ -445,7 +445,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along j direction. - + @@ -458,7 +458,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along i direction. - + diff --git a/contributed_definitions/NXimage_r_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml index b9012feea2..78f01002b7 100644 --- a/contributed_definitions/NXimage_r_set.nxdl.xml +++ b/contributed_definitions/NXimage_r_set.nxdl.xml @@ -56,7 +56,7 @@ Image intensity values. - + @@ -64,7 +64,7 @@ Pixel coordinate center along x direction. - + @@ -82,7 +82,7 @@ Image intensity values. - + @@ -91,7 +91,7 @@ Pixel coordinate center along y direction. - + @@ -104,7 +104,7 @@ Pixel coordinate center along x direction. - + @@ -122,7 +122,7 @@ Image intensity values. - + @@ -132,7 +132,7 @@ Pixel coordinate center along z direction. - + @@ -145,7 +145,7 @@ Pixel coordinate center along y direction. - + @@ -158,7 +158,7 @@ Pixel coordinate center along x direction. - + @@ -176,7 +176,7 @@ Image intensity values. - + @@ -185,7 +185,7 @@ Image identifier - + @@ -198,7 +198,7 @@ Pixel coordinate center along x direction. - + @@ -216,7 +216,7 @@ Image intensity values. - + @@ -226,7 +226,7 @@ Image identifier - + @@ -239,7 +239,7 @@ Pixel coordinate center along y direction. - + @@ -252,7 +252,7 @@ Pixel coordinate center along x direction. - + @@ -270,7 +270,7 @@ Image intensity values. - + @@ -281,7 +281,7 @@ Image identifier - + @@ -294,7 +294,7 @@ Pixel coordinate center along z direction. - + @@ -307,7 +307,7 @@ Pixel coordinate center along y direction. - + @@ -320,7 +320,7 @@ Pixel coordinate center along x direction. - + diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml index 495d8756dc..d0602017a7 100644 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -118,7 +118,7 @@ In most cases usually one pattern is averaged by the detector for some amount of time and then reported as one pattern. - + @@ -126,7 +126,7 @@ Intensity of the diffraction pattern. - + @@ -149,7 +149,7 @@ while for _indices fastest to fast--> Pattern are enumerated starting from 0 to n_p - 1. - + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index 2bccedd822..169d4c8cbd 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -71,7 +71,7 @@ The array is sorted in decreasing order. For the rationale behind this see `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -91,7 +91,7 @@ and subscripted number of protons element notation e.g. :math:`^{14}C`. The array is stored matching the order of nuclide_hash. - + @@ -150,7 +150,7 @@ for documenting :ref:`NXprocess` steps of indexing a ToF/mass-to-charge state histogram. - + diff --git a/contributed_definitions/NXmatch_filter.nxdl.xml b/contributed_definitions/NXmatch_filter.nxdl.xml index eeee499c0e..fde6b345ab 100644 --- a/contributed_definitions/NXmatch_filter.nxdl.xml +++ b/contributed_definitions/NXmatch_filter.nxdl.xml @@ -55,7 +55,7 @@ [1, 5, 6] and method is set to whitelist, only entries with values matching 1, 5 or 6 will be processed. All other entries will be excluded. - + diff --git a/contributed_definitions/NXms.nxdl.xml b/contributed_definitions/NXms.nxdl.xml index 611c5e1734..32ab2191b7 100644 --- a/contributed_definitions/NXms.nxdl.xml +++ b/contributed_definitions/NXms.nxdl.xml @@ -278,10 +278,12 @@ when the specimen was prepared.--> - +interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_feature_set.nxdl.xml b/contributed_definitions/NXms_feature_set.nxdl.xml index 90ff9ac3fb..2f2010d0e6 100644 --- a/contributed_definitions/NXms_feature_set.nxdl.xml +++ b/contributed_definitions/NXms_feature_set.nxdl.xml @@ -63,7 +63,10 @@ TJLD: but not one for every molecule, i.e. all molecules and how their atoms wit TJLD: clearly there are two possibilities: either concatenate or make one NXms_feature_set for each molecule or component in the topology hierarchy TJLD: however the here proposed design generalizes the arbitrary (microstructural) features and computational geometry based coarse-grained representations--> - + Name (or link?) to another NXms_feature_set which defines features what are assumed as the parents/super_features of all members in this feature set. @@ -85,7 +88,9 @@ but with the additional benefit of a much richer geometrical description and the I can also imagine that materials engineers e.g. can reuse NXms_feature_set in an application definition by just then naming their group e.g. grains(NXms_feature_set) and use in the application definition either only the (material point), interface network, or volumetric description--> - + What is the best matching description how dimensional the feature is. @@ -96,16 +101,20 @@ their group e.g. grains(NXms_feature_set) and use in the application definition - + How many features/members are in this set? - +TJLD: inherits from NXms_feature_set but would need to have no dimensionality +--> The keywords of the dictionary of human-readable types of features. Using terms from a community-agreed upon controlled vocabulary, e.g. @@ -115,17 +124,19 @@ TJLD: inherits from NXms_feature_set but would need to have no dimensionality--> surface, thermal_groove_root, precipitate, dispersoid, pore, crack is recommended. - + - + The integer identifier used to resolve of which type each feature is, i.e. the values of the dictionary of human-readable types of features. - + @@ -137,7 +148,7 @@ TJLD: inherits from NXms_feature_set but would need to have no dimensionality--> specific features can be extracted as if they would be stored in an own group. - + @@ -148,7 +159,7 @@ TJLD: inherits from NXms_feature_set but would need to have no dimensionality--> described feature set are defined (implicitly from 0, to c-1 or via explicit identifier. - + @@ -174,17 +185,19 @@ end up as links--> Integer used to distinguish features for explicit indexing. - + - +but here NXms_feature_set instances +--> Assumptions and parameter to arrive at geometric primitives to locate zero-dimensional/point-(like) features which are @@ -199,7 +212,10 @@ but here NXms_feature_set instances--> - + Assumptions and parameters to arrive at geometric primitives to locate one-dimensional/line-like features which are diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml index 5e0f705959..0be3dc81e4 100644 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -69,7 +69,7 @@ The direction along which orientations are projected. - + @@ -139,7 +139,8 @@ \@axis_x_indices: 0 \@axis_y_indices: 1--> - +tech partners oftentimes do not report to more than calibrated pixel position +--> Inverse pole figure color code for each map coordinate. - + @@ -161,7 +163,7 @@ tech partners oftentimes do not report to more than calibrated pixel position--> Pixel center coordinate calibrated for step size along the z axis of the map. - + @@ -170,7 +172,7 @@ tech partners oftentimes do not report to more than calibrated pixel position--> Pixel center coordinate calibrated for step size along the y axis of the map. - + @@ -179,7 +181,7 @@ tech partners oftentimes do not report to more than calibrated pixel position--> Pixel center coordinate calibrated for step size along the x axis of the map. - + @@ -218,11 +220,13 @@ title:--> \@axis_x_indices: 0 \@axis_y_indices: 1--> - + Inverse pole figure color code for each map coordinate. - + @@ -232,7 +236,7 @@ title:--> Pixel along the y-axis. - + @@ -241,7 +245,7 @@ title:--> Pixel along the x-axis. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml index 721aeca848..90e4132bee 100644 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -118,7 +118,7 @@ check against v5.12--> TODO with MTex developers - + @@ -127,7 +127,7 @@ check against v5.12--> TODO with MTex developers - + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml index 90c9ae1c18..3e9d11dd70 100644 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -91,7 +91,7 @@ Euler angle representation of the kth-most maxima of the ODF in decreasing order of the intensity maximum. - + @@ -108,7 +108,7 @@ each location as specified for each location in the order and reported in the order of these locations. - + @@ -134,7 +134,7 @@ ODF intensity at probed locations relative to null model of a completely random texture. - + @@ -144,7 +144,7 @@ Pixel center angular position along the :math:`\varphi_1` direction. - + @@ -153,7 +153,7 @@ Pixel center angular position along the :math:`\varphi_2` direction. - + @@ -162,7 +162,7 @@ Pixel center angular position along the :math:`\Phi` direction. - + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml index 7425c8a829..44db61d7b3 100644 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -82,7 +82,7 @@ Pole figure intensity. - + @@ -92,7 +92,7 @@ Pixel center along y direction in the equatorial plane of a stereographic projection of the unit sphere. - + @@ -102,7 +102,7 @@ Pixel center along x direction in the equatorial plane of a stereographic projection of the unit sphere. - + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml index 390f039698..f44d34239a 100644 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -193,7 +193,7 @@ ONE DIMENSIONAL FEATURES--> Identifier used for crystals for explicit indexing. - + @@ -209,11 +209,13 @@ ONE DIMENSIONAL FEATURES--> - + Identifier used for phase for explicit indexing. - + @@ -223,7 +225,7 @@ ONE DIMENSIONAL FEATURES--> True, if the crystal makes contact with the edge of the ROI, false otherwise. - + @@ -233,7 +235,7 @@ ONE DIMENSIONAL FEATURES--> crystal at probed positions (weighted by area of that position) versus the average disorientation of the crystal. - + @@ -242,15 +244,17 @@ ONE DIMENSIONAL FEATURES--> Calibrated area of surrounded by the polyline about each crystal. - + - +therefore here a compact and suggestion how to store such data +--> Projections of grain or phase boundaries as typically sectioned with optical or electron microscopy characterization. @@ -270,7 +274,7 @@ i) Set of pair of crystals sharing an interface--> Set of pairs of crystal_identifier resolved via depends_on which are adjacent to each interface. - + @@ -288,7 +292,7 @@ i) Set of pair of crystals sharing an interface--> For 2D projections of 3D microstructural features a triple point is physically only the projection of a triple line. - + @@ -316,7 +320,7 @@ properties, descriptors--> much as possible with interpreting how and where the lines are located in the reference frame. - + @@ -334,16 +338,18 @@ properties, descriptors--> Identifier for each interface using explicit indexing. - + - +the explicit description often generating unnecessary information duplication +--> Projections of triple lines as typically characterized with optical or electron microscopy. @@ -385,7 +391,7 @@ i) triplet of interface identifier--> Identifier for each triple point using explicit indexing. - + @@ -393,7 +399,7 @@ i) triplet of interface identifier--> Set of triple point identifiers. - + @@ -409,7 +415,7 @@ i) triplet of interface identifier--> Each triplet resolves which three interface projections the triple point connects. - + @@ -427,7 +433,7 @@ is assumed discretized via three polylines representing interfaces--> Triplet of identifier of polyline segments. Each triplet resolves which three segments of polyline segments the triple junction connects. - + diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index 9df738e196..24243000c5 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -304,9 +304,11 @@ when the specimen was prepared.--> - +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -683,21 +685,27 @@ exists: optional--> - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/contributed_definitions/NXoptical_system_em.nxdl.xml index f908d19d42..0611984a77 100644 --- a/contributed_definitions/NXoptical_system_em.nxdl.xml +++ b/contributed_definitions/NXoptical_system_em.nxdl.xml @@ -66,8 +66,10 @@ work of the HMC EM glossary activities--> - + Beam current as measured relevant for the illumination of the specimen. Users should specify further details like how the beam current diff --git a/contributed_definitions/NXpeak.nxdl.xml b/contributed_definitions/NXpeak.nxdl.xml index fd84d26efb..0eea9cbe3f 100644 --- a/contributed_definitions/NXpeak.nxdl.xml +++ b/contributed_definitions/NXpeak.nxdl.xml @@ -64,7 +64,7 @@ In the case of an empirical description of the peak and its shoulders, this array holds the position values for the independent variable. - + @@ -73,7 +73,7 @@ In the case of an empirical description of the peak and its shoulders, this array holds the intensity/count values at each position. - + diff --git a/contributed_definitions/NXpulser_apm.nxdl.xml b/contributed_definitions/NXpulser_apm.nxdl.xml index 301192ac12..3a856635b9 100644 --- a/contributed_definitions/NXpulser_apm.nxdl.xml +++ b/contributed_definitions/NXpulser_apm.nxdl.xml @@ -48,12 +48,21 @@ - + Frequency with which the pulser fire(s). - + @@ -71,7 +80,7 @@ (as a function of standing voltage). Otherwise, this field should not be present. - + @@ -80,14 +89,16 @@ - +existence constraint is independent of other values. +--> Pulsed voltage, in laser pulsing mode this field can be omitted. - + @@ -100,7 +111,7 @@ existence constraint is independent of other values.--> Absolute number of pulses starting from the beginning of the experiment. - + @@ -116,7 +127,7 @@ existence constraint is independent of other values.--> the case of local electrode atom probe (LEAP) instrument. Otherwise, the standing voltage applied to the sample, relative to system ground. - + @@ -151,7 +162,7 @@ existence constraint is independent of other values.--> Average energy of the laser at peak of each pulse. - + @@ -171,7 +182,7 @@ existence constraint is independent of other values.--> how the laser beam shines on the specimen, i.e. the mean vector is parallel to the laser propagation direction. - + @@ -186,7 +197,7 @@ existence constraint is independent of other values.--> Track time-dependent settings over the course of the measurement where the laser beam exits the focusing optics. - + @@ -201,7 +212,7 @@ existence constraint is independent of other values.--> Track time-dependent settings over the course of the measurement where the laser hits the specimen. - + diff --git a/contributed_definitions/NXrotation_set.nxdl.xml b/contributed_definitions/NXrotation_set.nxdl.xml index c29f3e3f8d..dd55e97e76 100644 --- a/contributed_definitions/NXrotation_set.nxdl.xml +++ b/contributed_definitions/NXrotation_set.nxdl.xml @@ -86,7 +86,7 @@ just how to rotate the object into the reference frame defined by depends_on--> An example of this most complex case is the description of the disorientation between crystals adjoining a hetero-phase boundary. - + @@ -112,7 +112,7 @@ just how to rotate the object into the reference frame defined by depends_on--> eventual inaccuracies just for the sake of reporting a simplified symmetrized description should be avoided. - + @@ -122,7 +122,7 @@ just how to rotate the object into the reference frame defined by depends_on--> crystal_symmetry and sample_symmetry. Rotations which should be interpreted as antipodal are not marked as such. - + @@ -135,7 +135,7 @@ just how to rotate the object into the reference frame defined by depends_on--> conventions behind depends_on to resolve which of the many Euler-angle conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. - + @@ -149,7 +149,7 @@ rotation_axis_angle(NX_NUMBER):--> True for all those value tuples which have assumed antipodal symmetry. False for all others. - + @@ -160,7 +160,7 @@ rotation_axis_angle(NX_NUMBER):--> and sample_symmetry. The supplementary field is_antipodal can be used to mark orientations with the antipodal property. - + @@ -173,7 +173,7 @@ rotation_axis_angle(NX_NUMBER):--> conventions behind depends_on to resolve which of the many Euler-angle conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. - + @@ -191,7 +191,7 @@ misorientation is not necessarily in the fundamental zone--> obeying symmetry operations for equivalent misorientations as defined by crystal_symmetry and sample_symmetry. - + @@ -201,7 +201,7 @@ misorientation is not necessarily in the fundamental zone--> Misorientation angular argument (eventually signed) following the same symmetry assumptions as expressed for the field misorientation_quaternion. - + @@ -210,7 +210,7 @@ misorientation is not necessarily in the fundamental zone--> Misorientation axis (normalized) and signed following the same symmetry assumptions as expressed for the field misorientation_angle. - + @@ -223,7 +223,7 @@ fundamental zone of SO3 for given crystal and sample symmetry--> obeying symmetry operations for equivalent misorientations as defined by crystal_symmetry and sample_symmetry. - + @@ -235,7 +235,7 @@ fundamental zone of SO3 for given crystal and sample symmetry--> following the same symmetry assumptions as expressed for the field disorientation_quaternion. - + @@ -244,7 +244,7 @@ fundamental zone of SO3 for given crystal and sample symmetry--> Disorientation axis (normalized) following the same symmetry assumptions as expressed for the field disorientation_angle. - + diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/contributed_definitions/NXscanbox_em.nxdl.xml index 46377479c2..56fe3ec6c7 100644 --- a/contributed_definitions/NXscanbox_em.nxdl.xml +++ b/contributed_definitions/NXscanbox_em.nxdl.xml @@ -68,10 +68,12 @@ TODO discuss with the electron microscopists. - + url: https://em-glossary.vercel.app/term/em-dwell-time +--> Time period during which the beam remains at one position. diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index dd5f5246df..e9d893e285 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -99,7 +99,7 @@ results for the object set--> For classical clustering algorithms this can for instance encode the cluster_identifier. - + @@ -108,7 +108,7 @@ results for the object set--> Matrix of categorical attribute data for each member in the set. - + @@ -141,7 +141,7 @@ when knowing total, noise, and unassigned.--> Array of numerical identifier of each feature. - + @@ -149,7 +149,7 @@ when knowing total, noise, and unassigned.--> Array of number of objects for each feature. - + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml index b743f33885..b8ee62d737 100644 --- a/contributed_definitions/NXspectrum_set.nxdl.xml +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -95,7 +95,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Counts - + @@ -109,7 +109,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Energy axis - + @@ -128,7 +128,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Counts - + @@ -142,7 +142,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Coordinate along x direction. - + @@ -155,7 +155,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Energy axis - + @@ -174,7 +174,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Counts - + @@ -189,7 +189,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Coordinate along y direction. - + @@ -202,7 +202,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Coordinate along x direction. - + @@ -215,7 +215,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Energy axis - + @@ -234,7 +234,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Counts - + @@ -250,7 +250,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Coordinate along z direction. - + @@ -263,7 +263,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Coordinate along y direction. - + @@ -276,7 +276,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Coordinate along x direction. - + @@ -289,7 +289,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Energy axis - + @@ -313,7 +313,7 @@ base classes--> Counts - + @@ -327,7 +327,7 @@ base classes--> Scan point identifier - + @@ -340,7 +340,7 @@ base classes--> Energy axis - + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index f9f537938c..422bba19f5 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -143,7 +143,7 @@ The interpretation of this tilt should be specialized and thus detailed via the application definition. - + diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml index 0f7da2bfa6..0310e9f260 100644 --- a/contributed_definitions/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -40,7 +40,7 @@ symbols:--> second identifier. Setting min_incr_max to [90, 3, 99] will take each third identifier beginning from identifier 90 up to 99. - + From 1cb305687c9ab6d5e3e38c9b058b021edccf24b0 Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Tue, 5 Mar 2024 09:52:47 +0100 Subject: [PATCH 0621/1012] Regenerate nxdls with nyaml==0.0.8 (#190) * Pin nyaml==0.0.8 * Regenerate nxdls --- contributed_definitions/NXapm.nxdl.xml | 36 ++-- .../NXapm_charge_state_analysis.nxdl.xml | 14 +- .../NXapm_hit_finding.nxdl.xml | 12 +- .../NXapm_paraprobe_clusterer_config.nxdl.xml | 14 +- ...NXapm_paraprobe_clusterer_results.nxdl.xml | 40 +++-- ...NXapm_paraprobe_distancer_results.nxdl.xml | 16 +- ...Xapm_paraprobe_intersector_config.nxdl.xml | 4 +- ...apm_paraprobe_intersector_results.nxdl.xml | 26 +-- .../NXapm_paraprobe_nanochem_config.nxdl.xml | 23 +-- .../NXapm_paraprobe_nanochem_results.nxdl.xml | 168 +++++++++--------- .../NXapm_paraprobe_ranger_results.nxdl.xml | 8 +- .../NXapm_paraprobe_selector_results.nxdl.xml | 6 +- .../NXapm_paraprobe_spatstat_config.nxdl.xml | 10 +- .../NXapm_paraprobe_spatstat_results.nxdl.xml | 24 +-- .../NXapm_paraprobe_surfacer_config.nxdl.xml | 6 +- .../NXapm_paraprobe_surfacer_results.nxdl.xml | 18 +- ...apm_paraprobe_tessellator_results.nxdl.xml | 36 ++-- .../NXapm_paraprobe_tool_results.nxdl.xml | 2 +- ...Xapm_paraprobe_transcoder_results.nxdl.xml | 14 +- .../NXapm_ranging.nxdl.xml | 2 +- .../NXapm_reconstruction.nxdl.xml | 6 +- .../NXapm_volt_and_bowl.nxdl.xml | 4 +- .../NXcg_alpha_complex.nxdl.xml | 6 +- .../NXcg_cylinder_set.nxdl.xml | 16 +- .../NXcg_ellipsoid_set.nxdl.xml | 4 +- .../NXcg_face_list_data_structure.nxdl.xml | 18 +- contributed_definitions/NXcg_grid.nxdl.xml | 14 +- .../NXcg_half_edge_data_structure.nxdl.xml | 20 +-- .../NXcg_hexahedron_set.nxdl.xml | 18 +- .../NXcg_parallelogram_set.nxdl.xml | 8 +- .../NXcg_point_set.nxdl.xml | 6 +- .../NXcg_polygon_set.nxdl.xml | 10 +- .../NXcg_polyhedron_set.nxdl.xml | 6 +- .../NXcg_polyline_set.nxdl.xml | 6 +- .../NXcg_primitive_set.nxdl.xml | 20 +-- .../NXcg_sphere_set.nxdl.xml | 2 +- .../NXcg_tetrahedron_set.nxdl.xml | 4 +- .../NXcg_triangle_set.nxdl.xml | 4 +- .../NXcg_unit_normal_set.nxdl.xml | 4 +- .../NXcoordinate_system.nxdl.xml | 6 +- .../NXcorrector_cs.nxdl.xml | 6 +- .../NXcrystal_structure.nxdl.xml | 18 +- .../NXcs_filter_boolean_mask.nxdl.xml | 4 +- .../NXcs_profiling_event.nxdl.xml | 4 +- .../NXdelocalization.nxdl.xml | 6 +- contributed_definitions/NXem.nxdl.xml | 6 +- contributed_definitions/NXem_adf.nxdl.xml | 2 +- .../NXem_conventions.nxdl.xml | 4 +- .../NXem_conventions_ebsd.nxdl.xml | 4 +- .../NXem_correlation.nxdl.xml | 8 +- contributed_definitions/NXem_ebsd.nxdl.xml | 27 +-- contributed_definitions/NXem_eds.nxdl.xml | 14 +- .../NXevent_data_apm.nxdl.xml | 14 +- .../NXgraph_edge_set.nxdl.xml | 10 +- .../NXgraph_node_set.nxdl.xml | 6 +- .../NXimage_c_set.nxdl.xml | 66 +++---- .../NXimage_r_set.nxdl.xml | 42 ++--- .../NXimage_r_set_diff.nxdl.xml | 6 +- contributed_definitions/NXion.nxdl.xml | 6 +- .../NXmatch_filter.nxdl.xml | 2 +- contributed_definitions/NXms.nxdl.xml | 6 +- .../NXms_feature_set.nxdl.xml | 44 +++-- contributed_definitions/NXms_ipf.nxdl.xml | 26 +-- .../NXms_mtex_config.nxdl.xml | 4 +- contributed_definitions/NXms_odf.nxdl.xml | 12 +- contributed_definitions/NXms_pf.nxdl.xml | 6 +- contributed_definitions/NXms_recon.nxdl.xml | 42 +++-- .../NXms_score_results.nxdl.xml | 18 +- .../NXoptical_system_em.nxdl.xml | 6 +- contributed_definitions/NXpeak.nxdl.xml | 4 +- contributed_definitions/NXpulser_apm.nxdl.xml | 35 ++-- .../NXrotation_set.nxdl.xml | 26 +-- contributed_definitions/NXscanbox_em.nxdl.xml | 6 +- .../NXsimilarity_grouping.nxdl.xml | 8 +- .../NXspectrum_set.nxdl.xml | 34 ++-- contributed_definitions/NXstage_lab.nxdl.xml | 2 +- .../NXsubsampling_filter.nxdl.xml | 2 +- requirements.txt | 2 +- 78 files changed, 637 insertions(+), 562 deletions(-) diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index a7f9e95e54..c6001743eb 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -244,7 +244,9 @@ the appdef definition here is nothing else then the documentation of this for a Magnitude of the standard deviation of the grain_diameter. - + The temperature of the last heat treatment step before quenching. @@ -652,13 +654,13 @@ NEW ISSUE: make this rather an own subentry NXapm_ranging--> - + - + @@ -707,18 +709,18 @@ we can only make recommendations--> - + - + - + @@ -775,7 +777,7 @@ i number of hits after hits finding but prior calibrations--> the ions were evaporated but taking into account that a hit_finding and spatial_filtering was applied. - + @@ -807,13 +809,13 @@ but not necessarily unprocessed timing data from the detector (unless individual 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--> - + - + @@ -834,7 +836,7 @@ Relevant for ranging are the calibrated data, thats why only these - + @@ -884,7 +886,7 @@ results--> - + @@ -905,26 +907,26 @@ results--> \@long_name:--> - + - + - + - + @@ -966,13 +968,13 @@ results--> - + - + diff --git a/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml b/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml index 864ec36205..0ad7d4d6ab 100644 --- a/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml +++ b/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml @@ -69,7 +69,7 @@ input/config--> used. Keep in mind though with such a weakly constrained parameter space the combinatorial analysis may become very time consuming! - + @@ -78,7 +78,7 @@ input/config--> Input constraint, interval within which (molecular) ions need to have the mass-to-charge-state-ratio such that an ion qualifies as a candidate. - + @@ -114,7 +114,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Signed charge, i.e. integer multiple of the elementary charge of each candidate. - + @@ -123,7 +123,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Table of nuclide instances of which each candidate is composed. Each row vector is sorted in descending order. Unused values are nullified. - + @@ -133,7 +133,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> Accumulated mass of the nuclides in each candidate. Not corrected for quantum effects. - + @@ -141,7 +141,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> The product of the natural abundances of the nuclides for each candidate. - + @@ -150,7 +150,7 @@ the n_cand can be 1 in which case all quantities below are scalar--> For each candidate the half life of that nuclide which has the shortest half life. - + diff --git a/contributed_definitions/NXapm_hit_finding.nxdl.xml b/contributed_definitions/NXapm_hit_finding.nxdl.xml index f320adda2d..7ea1adbfee 100644 --- a/contributed_definitions/NXapm_hit_finding.nxdl.xml +++ b/contributed_definitions/NXapm_hit_finding.nxdl.xml @@ -66,7 +66,7 @@ Alias tuple (begin, end) of each DLD wire of the detector. Order follows arrival_time_pairs. - + @@ -76,7 +76,7 @@ Raw readings from the analog-to-digital-converter timing circuits of the detector wires. - + @@ -88,7 +88,7 @@ Evaluated ion impact coordinates on the detector. Use the depends_on field to spec - + @@ -104,7 +104,7 @@ AMETEK/Cameca uses e.g. golden, multiple, partial, irrecoverable, and multi-first and multi-late. - + @@ -119,7 +119,7 @@ Hit quality identifier for each pulse. Identifier have to be within hit_quality_identifier. - + @@ -133,7 +133,7 @@ a molecular ion contains (which is instead encoded with the isotope_vector field of each :ref:`NXion` instance). - + diff --git a/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml index 2803362373..21897a43b9 100644 --- a/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml @@ -231,7 +231,7 @@ identifier(NX_UINT):--> In the simplest case, the matrix contains only the proton number of the element in the row, all other values set to zero. - + @@ -275,7 +275,7 @@ identifier(NX_UINT):--> Array of epsilon (eps) parameter values. - + @@ -283,7 +283,7 @@ identifier(NX_UINT):--> Array of minimum points (min_pts) parameter values. - + @@ -334,7 +334,7 @@ optics(NXprocess): Array of min_cluster_size parameter values. - + @@ -342,7 +342,7 @@ optics(NXprocess): Array of min_samples parameter values. - + @@ -350,7 +350,7 @@ optics(NXprocess): Array of cluster_selection parameter values. - + @@ -358,7 +358,7 @@ optics(NXprocess): Array of alpha parameter values. - + diff --git a/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml index 237670acdf..763a37b1c9 100644 --- a/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml @@ -107,7 +107,7 @@ of this array is not necessarily n_ions. Instead, it is the value of cardinality. - + @@ -120,7 +120,7 @@ tuples for each target that can be used to decode model_labels, core_sample_indices, and weight. - + @@ -133,7 +133,7 @@ multiple cluster this array is as long as the total number of solutions found and - + @@ -142,7 +142,7 @@ The raw array of core sample indices which specify which of the targets are core points. - + @@ -150,7 +150,7 @@ Numerical label for each target (member in the set) aka cluster identifier. - + @@ -158,7 +158,7 @@ Categorical label(s) for each target (member in the set) aka cluster name(s). - + @@ -172,29 +172,33 @@ should the position of the ion be accounted for because the ion is e.g. a molecular ion with several elements or nuclides of requested type. - + - + mask(NX_UINT): +--> Are targets assigned to the noise category or not. - + - + mask(NX_UINT): +--> Are targets assumed a core point. - + @@ -231,7 +235,7 @@ Numerical identifier of each feature aka cluster_identifier. - + @@ -239,7 +243,7 @@ Number of members for each feature. - + @@ -274,17 +278,17 @@ - + - + - + diff --git a/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml index d6f6bd42e1..011214db13 100644 --- a/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml @@ -80,7 +80,7 @@ The shortest analytical distance of each point to their respectively closest triangle from the joint triangle set. - + @@ -89,7 +89,7 @@ For each point the identifier of the triangle for which the shortest distance was found - + @@ -100,7 +100,7 @@ The field can be used to visualize the points as a function of their distance to the triangle set (e.g. via XDMF/Paraview). - + @@ -131,7 +131,7 @@ is not an integer multiple of bitdepth. If padding is used, padded bits are set to 0. - + @@ -148,7 +148,7 @@ the field mask of the NXcs_filter_boolean_mask is inherited that means its docst its unit category only the dimensions are constrained strong to match the number of objects triangles in this case--> - + @@ -181,17 +181,17 @@ triangles in this case--> - + - + - + diff --git a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml index 93103b62ee..6fcd29b4c5 100644 --- a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml @@ -180,7 +180,7 @@ Array of identifier whereby the path to the geometry data can be interferred automatically. - + @@ -245,7 +245,7 @@ Array of identifier whereby the path to the geometry data can be interferred automatically. - + diff --git a/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml index 0d11cfe57d..55b2aeea3c 100644 --- a/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml @@ -81,7 +81,7 @@ from the current_set have directed link(s) pointing to which named feature(s) from the next_set. - + @@ -92,7 +92,7 @@ link is due to volumetric overlap (0x00 == 0), proximity (0x01 == 1), or something else unknown (0xFF == 255). - + @@ -104,7 +104,7 @@ links are defined is symmetric it holds that next_to_current maps the links for current_to_next in just the opposite direction. - + @@ -115,7 +115,7 @@ link is due to a volumetric overlap (0x00 == 0), proximity (0x01 == 1), or something else unknown (0xFF == 255). - + @@ -125,7 +125,7 @@ intersection, i.e. how much volume do the two features share. If features do not intersect the volume is zero. - + @@ -162,7 +162,7 @@ encodes the cluster to which each feature_identifier was assigned. Here for features of the current_set. - + @@ -173,7 +173,7 @@ encodes the cluster to which each feature_identifier was assigned. Here for features of the next_set. - + @@ -182,7 +182,7 @@ The identifier (names) of the cluster. - + @@ -197,7 +197,7 @@ The third column encodes the total number of members in the cluster. - + @@ -212,7 +212,7 @@ The second column encodes how many clusters with as many members exist. - + @@ -253,17 +253,17 @@ - + - + - + diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml index 09af95498b..6334cb3869 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml @@ -250,7 +250,7 @@ identifier(NX_UINT):--> Unused values in each row of the matrix are nullified. Nuclides are identified as hashed nuclide (see :ref:`NXion`) for further details. - + @@ -261,7 +261,7 @@ identifier(NX_UINT):--> on a cuboidal 3D grid (:ref:`NXcg_grid`). The tool performs as many delocalization computations as values are specified in grid_resolution. - + @@ -279,7 +279,7 @@ identifier(NX_UINT):--> The tool performs as many delocalization computations as values are specified in kernel_variance. - + @@ -708,7 +708,7 @@ identifier(NX_UINT):--> Array of nuclide iontypes to filter. - + @@ -725,7 +725,7 @@ identifier(NX_UINT):--> which specify how the initial triangles of the mesh should be iteratively refined by edge splitting and related mesh refinement operations. - + @@ -740,7 +740,7 @@ identifier(NX_UINT):--> self-intersections may occur. The tool detects these and stops in a controlled manner so that the user can repeat the analyses with using a different parameterization. - + @@ -753,7 +753,7 @@ identifier(NX_UINT):--> parameter values to be used in the first DCOM iteration. The first entry of each array those for the second DCOM iteration and so on and so forth. - + @@ -958,7 +958,7 @@ identifier(NX_UINT):--> Explicit x, y, z coordinates (in the paraprobe coordinate system) where ROIs should be placed if feature is absent. - + @@ -968,12 +968,15 @@ identifier(NX_UINT):--> Explicit outer unit normal which explains into which direction each cylinder ROI is oriented. - + - + For each ROI, how high (projected on the cylinder axis) should the cylindrical ROI be. diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml index b7a4d1c398..8e4bdaaceb 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml @@ -136,7 +136,7 @@ The cardinality/total number of triangles in the triangle soup.--> - + @@ -153,7 +153,7 @@ The cardinality/total number of triangles in the triangle soup.--> The unit cell dimensions according to the coordinate system defined under coordinate_system. - + @@ -166,7 +166,7 @@ The cardinality/total number of triangles in the triangle soup.--> outside some masking primitive are removed, this extent field should not be used. Instead use the coordinate field. - + @@ -185,7 +185,7 @@ The cardinality/total number of triangles in the triangle soup.--> The shape of the kernel is that of a cuboid of extent 2*kernel_extent[i] + 1 in each dimension i. - + @@ -202,7 +202,7 @@ The cardinality/total number of triangles in the triangle soup.--> Standard deviation :math:`\sigma_i` of the kernel in each dimension in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. - + @@ -211,7 +211,7 @@ The cardinality/total number of triangles in the triangle soup.--> Expectation value :math:`\mu_i` of the kernel in each dimension in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. - + @@ -263,7 +263,7 @@ The cardinality/total number of triangles in the triangle soup.--> mesh even though many vertices are shared between triangles and thus the positions of these vertices do not have to be duplicated. - + @@ -281,7 +281,7 @@ The cardinality/total number of triangles in the triangle soup.--> the vertex identifiers for the i-th face on the following index interval of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. - + @@ -293,7 +293,7 @@ The cardinality/total number of triangles in the triangle soup.--> primitive count value (here 4 because each face is a quad). The remaining four values are the vertex indices. - + @@ -309,7 +309,7 @@ The cardinality/total number of triangles in the triangle soup.--> Name of the boundaries. E.g. left, right, front, back, bottom, top, The field must have as many entries as there are number_of_boundaries. - + @@ -324,7 +324,7 @@ The cardinality/total number of triangles in the triangle soup.--> 4 - von Neumann 5 - Dirichlet - + @@ -355,7 +355,7 @@ The cardinality/total number of triangles in the triangle soup.--> The actual delocalized intensity values. - + @@ -365,7 +365,7 @@ The cardinality/total number of triangles in the triangle soup.--> Cell center of mass positions along x. - + @@ -373,7 +373,7 @@ The cardinality/total number of triangles in the triangle soup.--> Cell center of mass positions along y. - + @@ -381,7 +381,7 @@ The cardinality/total number of triangles in the triangle soup.--> Cell center of mass positions along z. - + @@ -389,7 +389,7 @@ The cardinality/total number of triangles in the triangle soup.--> Intensity of the field at given point - + @@ -398,7 +398,7 @@ The cardinality/total number of triangles in the triangle soup.--> Center of mass positions of each voxel for rendering the scalar field via XDMF in e.g. Paraview. - + @@ -408,7 +408,7 @@ The cardinality/total number of triangles in the triangle soup.--> XDMF topology for rendering in combination with xdmf_xyz the scalar field via XDMF in e.g. Paraview. - + @@ -428,7 +428,7 @@ The cardinality/total number of triangles in the triangle soup.--> The actual point-wise component values. - + @@ -439,7 +439,7 @@ The cardinality/total number of triangles in the triangle soup.--> Cell center of mass positions along x. - + @@ -447,7 +447,7 @@ The cardinality/total number of triangles in the triangle soup.--> Cell center of mass positions along y. - + @@ -455,7 +455,7 @@ The cardinality/total number of triangles in the triangle soup.--> Cell center of mass positions along z. - + @@ -464,7 +464,7 @@ The cardinality/total number of triangles in the triangle soup.--> The gradient vector formatted for direct visualization via XDMF in e.g. Paraview. - + @@ -474,7 +474,7 @@ The cardinality/total number of triangles in the triangle soup.--> Center of mass positions of each voxel for rendering the scalar field gradient via XDMF in e.g. Paraview. - + @@ -484,7 +484,7 @@ The cardinality/total number of triangles in the triangle soup.--> XDMF topology for rendering in combination with xdmf_xyz the scalar field via XDFM in e.g. Paraview. - + @@ -550,7 +550,7 @@ The cardinality/total number of triangles in the triangle soup.--> case vertices_are_unique is likely False. Naively here means that each vertex is stored even though many share the same positions. - + @@ -568,7 +568,7 @@ The cardinality/total number of triangles in the triangle soup.--> the vertex identifiers for the i-th face on the following index interval of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. - + @@ -578,7 +578,7 @@ The cardinality/total number of triangles in the triangle soup.--> of vertices and a triple of vertex indices specifying each triangle. The total number of entries is n_f_tri * (1+1+3). - + @@ -587,7 +587,7 @@ The cardinality/total number of triangles in the triangle soup.--> Direction of each normal. - + @@ -601,7 +601,7 @@ The cardinality/total number of triangles in the triangle soup.--> * 1 - outer * 2 - inner - + @@ -613,7 +613,7 @@ The cardinality/total number of triangles in the triangle soup.--> Direction of each normal. - + @@ -627,7 +627,7 @@ The cardinality/total number of triangles in the triangle soup.--> * 1 - outer * 2 - inner - + @@ -637,7 +637,7 @@ The cardinality/total number of triangles in the triangle soup.--> gradient vector of the local delocalized scalar field. :math:`\sum_{x, y, z} {\nabla{c}_i}^2`. - + @@ -660,13 +660,13 @@ The cardinality/total number of triangles in the triangle soup.--> that is especially useful to document those triangles for whose the projection is almost perpendicular. - + - + @@ -676,7 +676,7 @@ The cardinality/total number of triangles in the triangle soup.--> is reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -688,7 +688,7 @@ The cardinality/total number of triangles in the triangle soup.--> traversed according to the sequence in which vertices are indexed in triangles. - + @@ -697,7 +697,7 @@ The cardinality/total number of triangles in the triangle soup.--> The center of mass of each triangle. - + @@ -735,7 +735,7 @@ The cardinality/total number of triangles in the triangle soup.--> returned, which constitutes the first step of the volumetric_feature identification process. - + @@ -743,7 +743,7 @@ The cardinality/total number of triangles in the triangle soup.--> The array of keywords of feature_type dictionary. - + @@ -752,7 +752,7 @@ The cardinality/total number of triangles in the triangle soup.--> The array of values for each keyword of the feature_type dictionary. - + @@ -763,7 +763,7 @@ The cardinality/total number of triangles in the triangle soup.--> each feature triangle cluster belongs to. Keep in mind that not each feature is an object or proxy. - + @@ -771,7 +771,7 @@ The cardinality/total number of triangles in the triangle soup.--> The explicit identifier of features. - + @@ -793,7 +793,7 @@ The cardinality/total number of triangles in the triangle soup.--> Explicit identifier of the feature a sub-set of the feature_identifier in the parent group. - + @@ -801,7 +801,7 @@ The cardinality/total number of triangles in the triangle soup.--> Volume of the feature. NaN for non-watertight objects. - + @@ -813,7 +813,7 @@ The cardinality/total number of triangles in the triangle soup.--> Edge length of the oriented bounding box from largest to smallest value. - + @@ -823,7 +823,7 @@ The cardinality/total number of triangles in the triangle soup.--> Oriented bounding box aspect ratio. YX versus ZY or second-largest over largest and smallest over second largest. - + @@ -834,7 +834,7 @@ The cardinality/total number of triangles in the triangle soup.--> not necessarily has to be the center_of_mass of the hexahedrally-shaped sample/sample part. - + @@ -845,7 +845,7 @@ The cardinality/total number of triangles in the triangle soup.--> is to store the shape of the hexahedra for visualization. - + @@ -853,12 +853,12 @@ The cardinality/total number of triangles in the triangle soup.--> - + - + @@ -871,30 +871,30 @@ number_of_faces(NX_POSINT): vertex_identifier_offset(NX_UINT): face_identifier_offset(NX_UINT):--> - + - + - + - + - + @@ -903,7 +903,7 @@ face_identifier_offset(NX_UINT):--> Array of evaporation_identifier / ion_identifier which details which ions lie inside or on the surface of the feature. - + @@ -915,7 +915,7 @@ face_identifier_offset(NX_UINT):--> Total (count) of ions inside or on the surface of the feature relevant for normalization. NaN for non watertight objects. - + @@ -929,7 +929,7 @@ face_identifier_offset(NX_UINT):--> Count or weight which, when divided by total, yields the composition of this element, nuclide, or (molecular) ion within the volume of the feature/object. - + @@ -962,7 +962,7 @@ face_identifier_offset(NX_UINT):--> location considering that the spatial resolution of atom probe experiments is limited. - + @@ -971,7 +971,7 @@ face_identifier_offset(NX_UINT):--> The multiplicity whereby the ion position is accounted for when the ion is considered one which is a decorator of the interface. - + @@ -984,7 +984,7 @@ face_identifier_offset(NX_UINT):--> The four parameter :math:`ax + by + cz + d = 0` which define the plane. - + @@ -1013,12 +1013,12 @@ face_identifier_offset(NX_UINT):--> - + - + @@ -1027,7 +1027,7 @@ face_identifier_offset(NX_UINT):--> Direction of each vertex normal. - + @@ -1041,12 +1041,12 @@ face_identifier_offset(NX_UINT):--> * 1 - outer * 2 - inner - + - + @@ -1055,7 +1055,7 @@ face_identifier_offset(NX_UINT):--> Direction of each face normal. - + @@ -1069,18 +1069,18 @@ face_identifier_offset(NX_UINT):--> * 1 - outer * 2 - inner - + - + - + @@ -1090,7 +1090,7 @@ face_identifier_offset(NX_UINT):--> reported for the edges traversed according to the sequence in which vertices are indexed in triangles. - + @@ -1101,7 +1101,7 @@ face_identifier_offset(NX_UINT):--> reported for the angle opposite to the edges which are traversed according to the sequence in which vertices are indexed in triangles. - + @@ -1129,7 +1129,7 @@ face_identifier_offset(NX_UINT):--> Position of the geometric center, which often is but not necessarily has to be the center_of_mass of the polyhedra. - + @@ -1139,13 +1139,13 @@ face_identifier_offset(NX_UINT):--> Integer which specifies the first index to be used for distinguishing ROI cylinder explicitly. - + - + @@ -1153,7 +1153,7 @@ face_identifier_offset(NX_UINT):--> The number of atoms in each ROI. - + @@ -1161,7 +1161,7 @@ face_identifier_offset(NX_UINT):--> The number of ions in each ROI. - + @@ -1170,7 +1170,7 @@ face_identifier_offset(NX_UINT):--> The orientation of the ROI defined via a vector which points along the cylinder axis and whose length is the height of the cylinder. - + @@ -1184,7 +1184,7 @@ face_identifier_offset(NX_UINT):--> In the direction of the ROI. - + @@ -1192,7 +1192,7 @@ face_identifier_offset(NX_UINT):--> Hashvalue using the following hashing rule :math:`H = Z + 256 * N`. - + @@ -1234,17 +1234,17 @@ face_identifier_offset(NX_UINT):--> - + - + - + diff --git a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml index f7f00a5dde..de5680a967 100644 --- a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml @@ -79,7 +79,7 @@ config--> ion in such a way that only the those elements are considered of which a (molecular) ion is assumed composed according to the NXion instances. - + @@ -118,17 +118,17 @@ config--> - + - + - + diff --git a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml index bd22c5f762..5630291783 100644 --- a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml @@ -90,17 +90,17 @@ - + - + - + diff --git a/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml index fde38f7810..5f4b26836a 100644 --- a/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml @@ -245,7 +245,7 @@ identifier(NX_UINT):--> recover usual spatial correlation statistics like the 1NN C-C spatial statistics. - + @@ -276,7 +276,7 @@ identifier(NX_UINT):--> iontypes to distinguish as possible targets. See additional comments under ion_query_isotope_vector_source. - + @@ -298,8 +298,7 @@ identifier(NX_UINT):--> Minimum value, increment, and maximum value of the histogram binning. - - + @@ -312,8 +311,7 @@ identifier(NX_UINT):--> Minimum value, increment, and maximum value of the histogram binning. - - + diff --git a/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml index 7a3613508a..be81d48063 100644 --- a/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml @@ -65,7 +65,7 @@ n_bins_knn: | as it is specified in the configuration settings inside the specific config_filename that was used for this paraprobe-spatstat analysis. - + @@ -77,12 +77,12 @@ n_bins_knn: | Right boundary of the binning. - + - + @@ -90,7 +90,7 @@ n_bins_knn: | Cumulated not normalized by total counts. - + @@ -98,7 +98,7 @@ n_bins_knn: | Cumulated and normalized by total counts. - + @@ -111,12 +111,12 @@ n_bins_knn: | Right boundary of the binning. - + - + @@ -124,7 +124,7 @@ n_bins_knn: | Cumulated not normalized by total counts. - + @@ -132,7 +132,7 @@ n_bins_knn: | Cumulated and normalized by total counts. - + @@ -172,17 +172,17 @@ n_bins_knn: | - + - + - + diff --git a/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml index f11888d77a..3cb04dac60 100644 --- a/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml @@ -184,8 +184,7 @@ Array of alpha values to use when alpha_value_choice is set_of_values or when alpha_value_choice is set_of_alpha_wrappings. - - + @@ -194,8 +193,7 @@ Array of offset values to use when alpha_value_choice is set_of_alpha_wrappings. The array of alpha_values and offset_values define a sequence of (alpha and offset value). - - + diff --git a/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml index 1e2d37f5f9..fa2bbd8825 100644 --- a/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml @@ -121,7 +121,7 @@ for eventually performed preprocessing--> The bitfield of the mask. See :ref:`NXcs_filter_boolean_mask` for how this bitfield is to be interpreted. - + @@ -162,13 +162,13 @@ for eventually performed preprocessing--> - + - + @@ -179,7 +179,7 @@ for eventually performed preprocessing--> of vertices and a triple of vertex indices specifying each triangle. The total number of entries is n_f_tri * (1+1+3). - + @@ -213,7 +213,7 @@ for eventually performed preprocessing--> - + @@ -224,7 +224,7 @@ for eventually performed preprocessing--> of vertices and a triple of vertex indices specifying each triangle. The total number of entries is n_f_tet * (1+1+4). - + @@ -268,17 +268,17 @@ For the future as we may wish to wrap primitives other like triangles or polylin - + - + - + diff --git a/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml index b7151753c1..dbfa7dc94c 100644 --- a/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml @@ -82,7 +82,7 @@ Coordinate triplet of the corner that lays closests to the origin of the *paraprobe* coordinate system. - + @@ -91,7 +91,7 @@ Coordinate triplet of the corner that lays farthest away from the origin of the *paraprobe* coordinate system. - + @@ -111,7 +111,7 @@ Volume of each Voronoi cell. - + @@ -119,7 +119,7 @@ Which MPI process computed which Voronoi cell. - + @@ -127,7 +127,7 @@ Which OpenMP thread computed which Voronoi cell. - + @@ -137,7 +137,7 @@ for each polyhedron. This field can be used to interpret the concatenated vector with the individual values for the area of each face. - + @@ -162,7 +162,7 @@ Third, the sequence of vertex identifier which define the facet. Tuples encode faces faster than cells. - + @@ -175,7 +175,7 @@ thus correlate per-ion properties with the volume that each cell represents. - + @@ -188,7 +188,7 @@ that document contact in specific outer unit normal directions of the *aabb*. - + @@ -204,7 +204,7 @@ dim: (i,) # one would not need to constrain this but doing so communicates that x-axis of the *paraprobe* coordinate system. - + @@ -218,7 +218,7 @@ dim: (i,) # one would not need to constrain this but doing so communicates that of the *paraprobe* coordinate system. - + @@ -232,7 +232,7 @@ dim: (i,) # one would not need to constrain this but doing so communicates that y-axis of the *paraprobe* coordinate system. - + @@ -246,7 +246,7 @@ dim: (i,) # one would not need to constrain this but doing so communicates that of the *paraprobe* coordinate system. - + @@ -260,7 +260,7 @@ dim: (i,) # one would not need to constrain this but doing so communicates that z-axis of the *paraprobe* coordinate system. - + @@ -274,7 +274,7 @@ dim: (i,) # one would not need to constrain this but doing so communicates that *paraprobe* coordinate system. - + @@ -316,17 +316,17 @@ dim: (i,) # one would not need to constrain this but doing so communicates that - + - + - + diff --git a/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml index 7ea9f4f4bd..2ac82f751a 100644 --- a/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml @@ -78,7 +78,7 @@ symbols: The mask. The length of the mask is an integer multiple of bitdepth. In such case, padded bits are set to 0. - + diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml index 42b0fa9c9c..10609e371d 100644 --- a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml @@ -104,7 +104,7 @@ config--> Mass-to-charge-state-ratio values. - + @@ -115,7 +115,7 @@ config--> Three-dimensional reconstructed positions of the ions. Interleaved array of x, y, z positions in the specimen space. - + @@ -133,7 +133,7 @@ config--> 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. - + @@ -149,7 +149,7 @@ config--> - + @@ -193,17 +193,17 @@ config--> - + - + - + diff --git a/contributed_definitions/NXapm_ranging.nxdl.xml b/contributed_definitions/NXapm_ranging.nxdl.xml index acc4bc87d7..ab3a8afafe 100644 --- a/contributed_definitions/NXapm_ranging.nxdl.xml +++ b/contributed_definitions/NXapm_ranging.nxdl.xml @@ -61,7 +61,7 @@ Smallest, increment, and largest mass-to-charge-state ratio value. - + diff --git a/contributed_definitions/NXapm_reconstruction.nxdl.xml b/contributed_definitions/NXapm_reconstruction.nxdl.xml index 1de66d16b1..03f5ff7091 100644 --- a/contributed_definitions/NXapm_reconstruction.nxdl.xml +++ b/contributed_definitions/NXapm_reconstruction.nxdl.xml @@ -83,7 +83,9 @@ - + The nominal diameter of the specimen ROI which is measured in the experiment. The physical specimen cannot be measured completely @@ -94,7 +96,7 @@ Three-dimensional reconstructed positions of the ions. - + diff --git a/contributed_definitions/NXapm_volt_and_bowl.nxdl.xml b/contributed_definitions/NXapm_volt_and_bowl.nxdl.xml index df8c1ca1a9..f317e76cbc 100644 --- a/contributed_definitions/NXapm_volt_and_bowl.nxdl.xml +++ b/contributed_definitions/NXapm_volt_and_bowl.nxdl.xml @@ -54,7 +54,7 @@ result--> Raw time-of-flight data without corrections. - + @@ -62,7 +62,7 @@ result--> Calibrated time-of-flight. - + diff --git a/contributed_definitions/NXcg_alpha_complex.nxdl.xml b/contributed_definitions/NXcg_alpha_complex.nxdl.xml index 9446cdd8b6..b6a466bc58 100644 --- a/contributed_definitions/NXcg_alpha_complex.nxdl.xml +++ b/contributed_definitions/NXcg_alpha_complex.nxdl.xml @@ -74,8 +74,10 @@ stating meter is a stronger constraint while m is the strongest constraint, mean - + Point cloud for which the alpha shape or wrapping has been computed. diff --git a/contributed_definitions/NXcg_cylinder_set.nxdl.xml b/contributed_definitions/NXcg_cylinder_set.nxdl.xml index f87f5f7ac3..e5bb83807a 100644 --- a/contributed_definitions/NXcg_cylinder_set.nxdl.xml +++ b/contributed_definitions/NXcg_cylinder_set.nxdl.xml @@ -52,7 +52,7 @@ cylinder could be constructed, but NXcylinder is easier to understand--> A direction vector which is parallel to the cylinder/cone axis and whose magnitude is the height of the cylinder/cone. - + @@ -77,7 +77,7 @@ one should really better use NXquadric...--> Radii of the cylinder. - + @@ -88,7 +88,7 @@ one should really better use NXquadric...--> This field, combined with lower_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -99,7 +99,7 @@ one should really better use NXquadric...--> This field, combined with upper_cap_radius can be used to describe (eventually truncated) circular cones. - + @@ -108,7 +108,7 @@ one should really better use NXquadric...--> Lateral surface area - + @@ -116,7 +116,7 @@ one should really better use NXquadric...--> Area of the upper cap of each cylinder. - + @@ -124,7 +124,7 @@ one should really better use NXquadric...--> Area of the lower cap of each cylinder. - + @@ -133,7 +133,7 @@ one should really better use NXquadric...--> Sum of upper and lower cap areas and lateral surface area of each cylinder. - + diff --git a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml index f613be7ecf..e22a677c11 100644 --- a/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml +++ b/contributed_definitions/NXcg_ellipsoid_set.nxdl.xml @@ -48,7 +48,7 @@ redundant as there is NXcsg, and NXquadric but easier to understand--> Use if all ellipsoids in the set have the same half-axes. - + @@ -56,7 +56,7 @@ redundant as there is NXcsg, and NXquadric but easier to understand--> Half-axes radii of each ellipsoid. - + diff --git a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml index a452dc99f5..48610a31d2 100644 --- a/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_face_list_data_structure.nxdl.xml @@ -94,7 +94,7 @@ duplicate of an NXoff_geometry ?--> Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -105,7 +105,7 @@ duplicate of an NXoff_geometry ?--> Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -145,7 +145,7 @@ duplicate of an NXoff_geometry ?--> Integer identifier to distinguish all vertices explicitly. - + @@ -153,7 +153,7 @@ duplicate of an NXoff_geometry ?--> Integer used to distinguish all edges explicitly. - + @@ -161,7 +161,7 @@ duplicate of an NXoff_geometry ?--> Integer used to distinguish all faces explicitly. - + @@ -175,7 +175,7 @@ duplicate of an NXoff_geometry ?--> case vertices_are_unique is likely False. Naively here means that each vertex is stored even though many share the same positions. - + @@ -184,7 +184,7 @@ duplicate of an NXoff_geometry ?--> The edges are stored as pairs of vertex identifier. - + @@ -202,7 +202,7 @@ duplicate of an NXoff_geometry ?--> the vertex identifiers for the i-th face on the following index interval of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. - + @@ -234,7 +234,7 @@ duplicate of an NXoff_geometry ?--> * 1 - counter-clockwise (CCW) * 2 - clock-wise (CW) - + diff --git a/contributed_definitions/NXcg_grid.nxdl.xml b/contributed_definitions/NXcg_grid.nxdl.xml index 894250e158..4d5aced5fe 100644 --- a/contributed_definitions/NXcg_grid.nxdl.xml +++ b/contributed_definitions/NXcg_grid.nxdl.xml @@ -57,7 +57,7 @@ Use the depends_on field that is inherited from the :ref:`NXcg_primitive_set` class to specify the coordinate system in which the origin location is defined. - + @@ -73,7 +73,7 @@ The unit cell dimensions using crystallographic notation. - + @@ -87,7 +87,7 @@ outside some masking primitive are removed, this extent field should not be used. Instead, use the coordinate field. - + @@ -97,7 +97,7 @@ should constraints on the grid be place here or not--> Position of each cell in Euclidean space. - + @@ -106,7 +106,7 @@ should constraints on the grid be place here or not--> Coordinate of each cell with respect to the discrete grid. - + @@ -133,7 +133,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Name of domain boundaries of the simulation box/ROI e.g. left, right, front, back, bottom, top. - + @@ -148,7 +148,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele 4 - von Neumann 5 - Dirichlet - + diff --git a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml index 26e307d082..40213352e3 100644 --- a/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml +++ b/contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml @@ -73,7 +73,7 @@ Each entry represents the total number of vertices for that face, irrespectively whether vertices are shared among faces or not. - + @@ -84,7 +84,7 @@ Each entry represents the total number of edges for that face, irrespectively whether edges are shared across faces or not. - + @@ -125,7 +125,7 @@ The position of the vertices. - + @@ -134,7 +134,7 @@ Identifier of the incident half-edge. - + @@ -142,7 +142,7 @@ Identifier of the (starting)/associated half-edge of the face. - + @@ -150,7 +150,7 @@ The identifier of the vertex from which this half-edge is outwards pointing. - + @@ -158,7 +158,7 @@ Identifier of the associated oppositely pointing half-edge. - + @@ -167,7 +167,7 @@ If the half-edge is a boundary half-edge the incident face identifier is NULL, i.e. 0. - + @@ -175,7 +175,7 @@ Identifier of the next half-edge. - + @@ -183,7 +183,7 @@ Identifier of the previous half-edge. - + diff --git a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml index e7569c6281..8ea85fb981 100644 --- a/contributed_definitions/NXcg_hexahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_hexahedron_set.nxdl.xml @@ -89,7 +89,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Qualifier for the shape of each hexahedron. - + @@ -100,7 +100,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> edges of the hexahedra. Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -112,7 +112,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> For the sake of explicitness quantities like length, width, and height should not be reported without specifying also the assumed reference frame. - + @@ -121,7 +121,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Qualifier often used to describe the extent of an object in the vertical direction assuming a specific coordinate system. - + @@ -129,7 +129,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Volume of each hexahedron. - + @@ -137,7 +137,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Total (surface) area (of all six faces) of each hexahedron. - + @@ -145,7 +145,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Area of each of the six faces of each hexahedron. - + @@ -155,7 +155,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> Specifies if the hexahedra represent cuboids or cubes eventually rotated ones but at least not too exotic six-faced polyhedra. - + @@ -165,7 +165,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> whether hexahedra are boxes whose primary edges are parallel to the axes of the coordinate system. - + diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml index 3709be64d4..bfb868c47d 100644 --- a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml +++ b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml @@ -73,7 +73,7 @@ To specify which parallelogram is a rectangle. - + @@ -83,13 +83,15 @@ describes whether parallelograms are rectangles whose primary edges are parallel to the axes of the coordinate system. - + - + Combined storage of all primitives of all parallelograms. diff --git a/contributed_definitions/NXcg_point_set.nxdl.xml b/contributed_definitions/NXcg_point_set.nxdl.xml index 5d8a15310b..c2190590d0 100644 --- a/contributed_definitions/NXcg_point_set.nxdl.xml +++ b/contributed_definitions/NXcg_point_set.nxdl.xml @@ -54,7 +54,7 @@ Coordinates of the points. - + @@ -66,7 +66,7 @@ If the field time is needed contextualize the time_offset relative to which time values are defined. Alternative store timestamp. - + @@ -74,7 +74,7 @@ ISO8601 with local time zone offset for each point. - + diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index c708108320..95c157ce1e 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -46,7 +46,9 @@ descriptors.--> - + Computational geometry description of a set of polygons in Euclidean space. @@ -98,7 +100,7 @@ descriptors.--> For each polygon its accumulated length along its edges. - + @@ -110,7 +112,7 @@ descriptors.--> edges of the vertex according to the sequence in the polygons array. Usually, the winding_order field is required to interpret the value. - + @@ -122,7 +124,7 @@ descriptors.--> * 1 - convex, * 2 - concave - + diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index 00eaec95ac..b087b0c790 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -69,7 +69,7 @@ for clean graph-based descriptions of polyhedra.--> The number of faces for each polyhedron. Faces of adjoining polyhedra are counted for each polyhedron. - + @@ -77,7 +77,7 @@ for clean graph-based descriptions of polyhedra.--> Area of each of faces. - + @@ -91,7 +91,7 @@ for clean graph-based descriptions of polyhedra.--> Length of each edge. - + diff --git a/contributed_definitions/NXcg_polyline_set.nxdl.xml b/contributed_definitions/NXcg_polyline_set.nxdl.xml index d075365882..64a002f86c 100644 --- a/contributed_definitions/NXcg_polyline_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyline_set.nxdl.xml @@ -81,7 +81,7 @@ multiple vertices possible with the same point coordinates but different names.- See the docstring for polylines for further details about how a set with different polyline members should be stored. - + @@ -101,7 +101,7 @@ they share the same position in space but have different identifiers.--> even though many vertices are shared between triangles and thus storing multiple copies of their positions is redundant. - + @@ -138,7 +138,7 @@ and then use--> n-th polyline can be accessed on the following array index interval: :math:`[\sum_{i=0}^{i=N-1}, \sum_{i=0}^{i=N}]`. - + diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index 93b35cfefa..e8cb457bc1 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -109,7 +109,7 @@ to enable an instantiation of the actual geometric primitives--> Identifier of each member for explicit indexing. - + @@ -117,7 +117,7 @@ to enable an instantiation of the actual geometric primitives--> The center of mass position of each primitive. - + @@ -127,7 +127,7 @@ to enable an instantiation of the actual geometric primitives--> True if the center is a center of mass. - + @@ -135,7 +135,7 @@ to enable an instantiation of the actual geometric primitives--> A qualitative description of the shape of each primitive. - + @@ -147,7 +147,7 @@ to enable an instantiation of the actual geometric primitives--> Often the term length is associated with the assumption that one edge is parallel to an axis of the coordinate system. - + @@ -156,7 +156,7 @@ to enable an instantiation of the actual geometric primitives--> Qualifier often used to describe the length of one characteristic edge within the coordinate system. - + @@ -164,7 +164,7 @@ to enable an instantiation of the actual geometric primitives--> True if primitive is closed such that it has properties like area or volume. - + @@ -174,7 +174,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -184,7 +184,7 @@ to enable an instantiation of the actual geometric primitives--> Set to NaN if does not apply for primitives for which is_closed is False. - + @@ -196,7 +196,7 @@ to enable an instantiation of the actual geometric primitives--> Use the depends_on attribute to specify in which coordinate system these direction unit vectors are defined. - + diff --git a/contributed_definitions/NXcg_sphere_set.nxdl.xml b/contributed_definitions/NXcg_sphere_set.nxdl.xml index 58d4d57968..8b12834749 100644 --- a/contributed_definitions/NXcg_sphere_set.nxdl.xml +++ b/contributed_definitions/NXcg_sphere_set.nxdl.xml @@ -54,7 +54,7 @@ redundant as there is NXcsg, and NXquadric but easier to understand--> In the case that spheres have different radius use this instead of the radius field. - + diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index 34c5d8ca7c..509347c515 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -44,7 +44,7 @@ Area of each of the four triangular faces of each tetrahedron. - + @@ -53,7 +53,7 @@ Length of each edge of each tetrahedron. - + diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index fe215dd3ee..7d994eb3e9 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -77,7 +77,7 @@ properties of triangles--> For each triangle values are reported via traversing the vertices in the sequence as these are defined. - + @@ -89,7 +89,7 @@ properties of triangles--> For each triangle values are reported for the angle opposite to the respective edges in the sequence how vertices are defined. - + diff --git a/contributed_definitions/NXcg_unit_normal_set.nxdl.xml b/contributed_definitions/NXcg_unit_normal_set.nxdl.xml index 6da20e5488..21470b34f0 100644 --- a/contributed_definitions/NXcg_unit_normal_set.nxdl.xml +++ b/contributed_definitions/NXcg_unit_normal_set.nxdl.xml @@ -53,7 +53,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> Direction of each normal - a unit normal. - + @@ -68,7 +68,7 @@ rather make this a set of vectors, irrespective whether these are unit or not--> * 1 - outer unit normal vector * 2 - inner unit normal vector - + diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml index 97f1ebd1a5..494b92956e 100644 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ b/contributed_definitions/NXcoordinate_system.nxdl.xml @@ -88,7 +88,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the x-axis in real space and the i-axis in reciprocal space. - + @@ -112,7 +112,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the y-axis in real space and the j-axis in reciprocal space. - + @@ -136,7 +136,7 @@ https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?d This axis is frequently referred to as the z-axis in real space and the k-axis in reciprocal space. - + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 10de965773..94c9b891f2 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -76,7 +76,7 @@ TODO: The relevant axes which span the tilt_angle need a cleaner description. - + @@ -84,7 +84,7 @@ The exposure time of single tilt images. - + @@ -93,7 +93,7 @@ The factor of enlargement of the apparent size, not the physical size, of an object. - + diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 972ed60805..921663cef6 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -81,7 +81,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters a, b, and c. - + @@ -90,7 +90,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Crystallography unit cell parameters alpha, beta, and gamma. - + @@ -186,7 +186,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Label for each atom position. - + @@ -197,7 +197,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> of each isotope respectively. Z and N have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -206,7 +206,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> Atom positions. - + @@ -223,7 +223,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative occupancy of the atom position. - + @@ -243,7 +243,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Miller indices refer to the Cartesian right-handed coordinate system of the unit cell. - + @@ -252,7 +252,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Spacing between crystallographic planes as defined by field miller. - + @@ -260,7 +260,7 @@ to describe the simulated Kikuchi pattern generated from such a model--> Relative intensity of the signal for the plane. - + diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml index 01b9b74b55..46f8774235 100644 --- a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml +++ b/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml @@ -94,7 +94,7 @@ The content of the mask. If padding is used, padding bits have to be set to 0. - + @@ -107,7 +107,7 @@ the conventions made for depends_on, so consult also the description of th content to which depends_on refers. - + diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/contributed_definitions/NXcs_profiling_event.nxdl.xml index 9be27b32d4..9da91f9c04 100644 --- a/contributed_definitions/NXcs_profiling_event.nxdl.xml +++ b/contributed_definitions/NXcs_profiling_event.nxdl.xml @@ -83,7 +83,7 @@ Maximum amount of virtual memory allocated per process during the event. - + @@ -91,7 +91,7 @@ Maximum amount of resident memory allocated per process during the event. - + diff --git a/contributed_definitions/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index b339ae40a1..7f7fbdf77a 100644 --- a/contributed_definitions/NXdelocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -114,7 +114,7 @@ and the interpretation model that to consider carbon atoms or carbon ions--> with :math:`$Z$` the number of protons and :math:`$N$` the number of neutrons of the nuclide. For elements set :math:`$N$` to zero. - + @@ -124,7 +124,7 @@ and the interpretation model that to consider carbon atoms or carbon ions--> iontypes generated via ranging. The number of mark data per point is 1 in the case for atom probe. - + @@ -136,7 +136,7 @@ and the interpretation model that to consider carbon atoms or carbon ions--> positive integer values, specifically the multiplicity of the ion, according to the details of the weighting_method. - + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 9529540a22..bb45ab5539 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -226,12 +226,14 @@ where scientists just store conventions without a default plot--> - +citation: doi ->why relevant, should be solved by RDMS +--> A description of the material characterized in the experiment. Sample and specimen are threaded as de facto synonyms. diff --git a/contributed_definitions/NXem_adf.nxdl.xml b/contributed_definitions/NXem_adf.nxdl.xml index 3f6002abcf..8d6649fda9 100644 --- a/contributed_definitions/NXem_adf.nxdl.xml +++ b/contributed_definitions/NXem_adf.nxdl.xml @@ -55,7 +55,7 @@ Annulus inner (first value) and outer (second value) half angle. - + diff --git a/contributed_definitions/NXem_conventions.nxdl.xml b/contributed_definitions/NXem_conventions.nxdl.xml index 41321063b7..1c948affc4 100644 --- a/contributed_definitions/NXem_conventions.nxdl.xml +++ b/contributed_definitions/NXem_conventions.nxdl.xml @@ -55,7 +55,9 @@ and they should whenever possible be as simple as possible and as few as possible to support users with understanding the content of the application definition.--> - + Conventions for rotations and coordinate systems to interpret crystal orientation and other data and results collected with electron microscopy research. diff --git a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml index b00b7ea925..d2d7456aaa 100644 --- a/contributed_definitions/NXem_conventions_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_conventions_ebsd.nxdl.xml @@ -22,7 +22,9 @@ # For further information, see http://www.nexusformat.org --> - + Base class for method-specific conventions EBSD. diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml index e9bd12b89a..95a644b519 100644 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ b/contributed_definitions/NXem_correlation.nxdl.xml @@ -181,7 +181,7 @@ Descriptor values displaying the ROI. - + @@ -199,7 +199,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the z-axis. - + @@ -212,7 +212,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -225,7 +225,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index 685aee0b67..33c8b9cb3c 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -358,7 +358,7 @@ pattern_available(NX_BOOLEAN): * 100 - Success * 255 - Unexpected errors - + @@ -380,7 +380,7 @@ pattern_available(NX_BOOLEAN): phase_identifier has as many entries as scan points and phase_matching has also as many entries as scan points. - + @@ -409,7 +409,7 @@ pattern_available(NX_BOOLEAN): the 1-th scan point, the n_sc - 1 th scan point and omitting tuples for those scan points with no phases according to n_phases_per_scan_point - + @@ -420,7 +420,7 @@ pattern_available(NX_BOOLEAN): how the phase_identifier and the phase_matching arrays have to be interpreted. See documentation of phase_identifier for further details. - + @@ -438,19 +438,24 @@ pattern_available(NX_BOOLEAN): - + - +to sample_reference_frame +--> Calibrated center positions of each scan point in the sample surface reference system. - + @@ -502,7 +507,7 @@ to sample_reference_frame--> Descriptor values displaying the ROI. - + @@ -519,7 +524,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the y-axis. - + @@ -532,7 +537,7 @@ while for _indices fastest to fast--> Calibrated coordinate along the x-axis. - + diff --git a/contributed_definitions/NXem_eds.nxdl.xml b/contributed_definitions/NXem_eds.nxdl.xml index bd93d61efe..43cde1ab9f 100644 --- a/contributed_definitions/NXem_eds.nxdl.xml +++ b/contributed_definitions/NXem_eds.nxdl.xml @@ -80,7 +80,7 @@ and Adrien Teutrie, Cecile Hebert (EPFL)--> Accumulated counts - + @@ -93,7 +93,7 @@ and Adrien Teutrie, Cecile Hebert (EPFL)--> Energy axis - + @@ -116,7 +116,7 @@ and Adrien Teutrie, Cecile Hebert (EPFL)--> Associated lower :math:`[e_{min}, e_{max}]` bounds of the energy which is assumed associated with this peak. - + @@ -132,7 +132,7 @@ and Adrien Teutrie, Cecile Hebert (EPFL)--> This can be a list of IUPAC notations for (the seldom) case that multiple lines are grouped with the same peak. - + @@ -147,7 +147,7 @@ and Adrien Teutrie, Cecile Hebert (EPFL)--> However, a collection of instances of NXpeak with individual NXion specified enables also to distinguish isotopic information. - + @@ -194,7 +194,7 @@ therefore we use for now the--> Associated :math:`[e_{min}, e_{max}]` bounds of the energy range for which spectrum counts have been accumulated. - + @@ -205,7 +205,7 @@ therefore we use for now the--> where accumulated for each pixel which yields an element-specific EDS map. - + diff --git a/contributed_definitions/NXevent_data_apm.nxdl.xml b/contributed_definitions/NXevent_data_apm.nxdl.xml index 002c112f94..878a5c3ff0 100644 --- a/contributed_definitions/NXevent_data_apm.nxdl.xml +++ b/contributed_definitions/NXevent_data_apm.nxdl.xml @@ -100,7 +100,7 @@ and pulse_identifier exactly specifies the connection between when a pulse was issued relative to start and absolute in UTC. - + @@ -149,7 +149,7 @@ vector with two values one for the first and another one for the value from the 100000-th pulse onwards. The values of pulse_identifier are then [0, 99999] respectively. - + @@ -181,7 +181,7 @@ within ATO files. The ATO file format is used primarily by the atom probe groups of the GPM in Rouen, France. - + @@ -214,7 +214,7 @@ but for atom probe if at all the pulse-based implicit time is available--> sample base (furthest point along sample apex and holding assembly that is removable from the sample stage). - + @@ -234,7 +234,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -249,7 +249,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + @@ -264,7 +264,7 @@ but for atom probe if at all the pulse-based implicit time is available--> Pressure in the analysis chamber. - + diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index cd321bd171..bd59185528 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -66,7 +66,7 @@ Integer used to distinguish edges for explicit indexing. - + @@ -80,7 +80,7 @@ * 1 / state 0x01 is one-directional * 2 / state 0x02 is bi-directional - + @@ -96,7 +96,7 @@ stored such that the identifier of the source node is the first entry and the identifier of the target is the second entry in the pair. - + @@ -106,7 +106,7 @@ A human-readable qualifier which type or e.g. class instance the edge is an instance of. - + @@ -114,7 +114,7 @@ A human-readable label/caption/tag of each edge. - + diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index 8cc242220b..d234097946 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -91,7 +91,7 @@ Integer used to distinguish nodes for explicit indexing. - + @@ -103,7 +103,7 @@ Instances which are groups like :ref:`NXgraph_node_set` could have an is_a qualifier reading :ref:`NXgraph_node_set`. - + @@ -111,7 +111,7 @@ A human-readable label/caption/tag of each node. - + diff --git a/contributed_definitions/NXimage_c_set.nxdl.xml b/contributed_definitions/NXimage_c_set.nxdl.xml index 5527498a23..c6837e47ab 100644 --- a/contributed_definitions/NXimage_c_set.nxdl.xml +++ b/contributed_definitions/NXimage_c_set.nxdl.xml @@ -80,7 +80,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the real part. - + @@ -88,7 +88,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the imaginary part. - + @@ -96,7 +96,7 @@ process information are composable from the NXimage_set base class--> Magnitude of the image intensity. - + @@ -104,7 +104,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along i direction. - + @@ -122,7 +122,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the real part. - + @@ -131,7 +131,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the imaginary part. - + @@ -140,7 +140,7 @@ process information are composable from the NXimage_set base class--> Magnitude of the image intensity. - + @@ -149,7 +149,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along j direction. - + @@ -162,7 +162,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along i direction. - + @@ -180,7 +180,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the real part. - + @@ -190,7 +190,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the imaginary part. - + @@ -200,7 +200,7 @@ process information are composable from the NXimage_set base class--> Magnitude of the image intensity. - + @@ -210,7 +210,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along k direction. - + @@ -223,7 +223,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along j direction. - + @@ -236,7 +236,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along i direction. - + @@ -254,7 +254,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the real part. - + @@ -263,7 +263,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the imaginary part. - + @@ -272,7 +272,7 @@ process information are composable from the NXimage_set base class--> Magnitude of the image intensity. - + @@ -281,7 +281,7 @@ process information are composable from the NXimage_set base class--> Image identifier - + @@ -294,7 +294,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along i direction. - + @@ -312,7 +312,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the real part. - + @@ -322,7 +322,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the imaginary part. - + @@ -332,7 +332,7 @@ process information are composable from the NXimage_set base class--> Magnitude of the image intensity. - + @@ -342,7 +342,7 @@ process information are composable from the NXimage_set base class--> Image identifier - + @@ -355,7 +355,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along j direction. - + @@ -368,7 +368,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along i direction. - + @@ -386,7 +386,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the real part. - + @@ -397,7 +397,7 @@ process information are composable from the NXimage_set base class--> Image intensity of the imaginary part. - + @@ -408,7 +408,7 @@ process information are composable from the NXimage_set base class--> Magnitude of the image intensity. - + @@ -419,7 +419,7 @@ process information are composable from the NXimage_set base class--> Image identifier - + @@ -432,7 +432,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along k direction. - + @@ -445,7 +445,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along j direction. - + @@ -458,7 +458,7 @@ process information are composable from the NXimage_set base class--> Pixel coordinate center along i direction. - + diff --git a/contributed_definitions/NXimage_r_set.nxdl.xml b/contributed_definitions/NXimage_r_set.nxdl.xml index b9012feea2..78f01002b7 100644 --- a/contributed_definitions/NXimage_r_set.nxdl.xml +++ b/contributed_definitions/NXimage_r_set.nxdl.xml @@ -56,7 +56,7 @@ Image intensity values. - + @@ -64,7 +64,7 @@ Pixel coordinate center along x direction. - + @@ -82,7 +82,7 @@ Image intensity values. - + @@ -91,7 +91,7 @@ Pixel coordinate center along y direction. - + @@ -104,7 +104,7 @@ Pixel coordinate center along x direction. - + @@ -122,7 +122,7 @@ Image intensity values. - + @@ -132,7 +132,7 @@ Pixel coordinate center along z direction. - + @@ -145,7 +145,7 @@ Pixel coordinate center along y direction. - + @@ -158,7 +158,7 @@ Pixel coordinate center along x direction. - + @@ -176,7 +176,7 @@ Image intensity values. - + @@ -185,7 +185,7 @@ Image identifier - + @@ -198,7 +198,7 @@ Pixel coordinate center along x direction. - + @@ -216,7 +216,7 @@ Image intensity values. - + @@ -226,7 +226,7 @@ Image identifier - + @@ -239,7 +239,7 @@ Pixel coordinate center along y direction. - + @@ -252,7 +252,7 @@ Pixel coordinate center along x direction. - + @@ -270,7 +270,7 @@ Image intensity values. - + @@ -281,7 +281,7 @@ Image identifier - + @@ -294,7 +294,7 @@ Pixel coordinate center along z direction. - + @@ -307,7 +307,7 @@ Pixel coordinate center along y direction. - + @@ -320,7 +320,7 @@ Pixel coordinate center along x direction. - + diff --git a/contributed_definitions/NXimage_r_set_diff.nxdl.xml b/contributed_definitions/NXimage_r_set_diff.nxdl.xml index 495d8756dc..d0602017a7 100644 --- a/contributed_definitions/NXimage_r_set_diff.nxdl.xml +++ b/contributed_definitions/NXimage_r_set_diff.nxdl.xml @@ -118,7 +118,7 @@ In most cases usually one pattern is averaged by the detector for some amount of time and then reported as one pattern. - + @@ -126,7 +126,7 @@ Intensity of the diffraction pattern. - + @@ -149,7 +149,7 @@ while for _indices fastest to fast--> Pattern are enumerated starting from 0 to n_p - 1. - + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index 2bccedd822..169d4c8cbd 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -71,7 +71,7 @@ The array is sorted in decreasing order. For the rationale behind this see `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - + @@ -91,7 +91,7 @@ and subscripted number of protons element notation e.g. :math:`^{14}C`. The array is stored matching the order of nuclide_hash. - + @@ -150,7 +150,7 @@ for documenting :ref:`NXprocess` steps of indexing a ToF/mass-to-charge state histogram. - + diff --git a/contributed_definitions/NXmatch_filter.nxdl.xml b/contributed_definitions/NXmatch_filter.nxdl.xml index eeee499c0e..fde6b345ab 100644 --- a/contributed_definitions/NXmatch_filter.nxdl.xml +++ b/contributed_definitions/NXmatch_filter.nxdl.xml @@ -55,7 +55,7 @@ [1, 5, 6] and method is set to whitelist, only entries with values matching 1, 5 or 6 will be processed. All other entries will be excluded. - + diff --git a/contributed_definitions/NXms.nxdl.xml b/contributed_definitions/NXms.nxdl.xml index 611c5e1734..32ab2191b7 100644 --- a/contributed_definitions/NXms.nxdl.xml +++ b/contributed_definitions/NXms.nxdl.xml @@ -278,10 +278,12 @@ when the specimen was prepared.--> - +interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, diff --git a/contributed_definitions/NXms_feature_set.nxdl.xml b/contributed_definitions/NXms_feature_set.nxdl.xml index 90ff9ac3fb..2f2010d0e6 100644 --- a/contributed_definitions/NXms_feature_set.nxdl.xml +++ b/contributed_definitions/NXms_feature_set.nxdl.xml @@ -63,7 +63,10 @@ TJLD: but not one for every molecule, i.e. all molecules and how their atoms wit TJLD: clearly there are two possibilities: either concatenate or make one NXms_feature_set for each molecule or component in the topology hierarchy TJLD: however the here proposed design generalizes the arbitrary (microstructural) features and computational geometry based coarse-grained representations--> - + Name (or link?) to another NXms_feature_set which defines features what are assumed as the parents/super_features of all members in this feature set. @@ -85,7 +88,9 @@ but with the additional benefit of a much richer geometrical description and the I can also imagine that materials engineers e.g. can reuse NXms_feature_set in an application definition by just then naming their group e.g. grains(NXms_feature_set) and use in the application definition either only the (material point), interface network, or volumetric description--> - + What is the best matching description how dimensional the feature is. @@ -96,16 +101,20 @@ their group e.g. grains(NXms_feature_set) and use in the application definition - + How many features/members are in this set? - +TJLD: inherits from NXms_feature_set but would need to have no dimensionality +--> The keywords of the dictionary of human-readable types of features. Using terms from a community-agreed upon controlled vocabulary, e.g. @@ -115,17 +124,19 @@ TJLD: inherits from NXms_feature_set but would need to have no dimensionality--> surface, thermal_groove_root, precipitate, dispersoid, pore, crack is recommended. - + - + The integer identifier used to resolve of which type each feature is, i.e. the values of the dictionary of human-readable types of features. - + @@ -137,7 +148,7 @@ TJLD: inherits from NXms_feature_set but would need to have no dimensionality--> specific features can be extracted as if they would be stored in an own group. - + @@ -148,7 +159,7 @@ TJLD: inherits from NXms_feature_set but would need to have no dimensionality--> described feature set are defined (implicitly from 0, to c-1 or via explicit identifier. - + @@ -174,17 +185,19 @@ end up as links--> Integer used to distinguish features for explicit indexing. - + - +but here NXms_feature_set instances +--> Assumptions and parameter to arrive at geometric primitives to locate zero-dimensional/point-(like) features which are @@ -199,7 +212,10 @@ but here NXms_feature_set instances--> - + Assumptions and parameters to arrive at geometric primitives to locate one-dimensional/line-like features which are diff --git a/contributed_definitions/NXms_ipf.nxdl.xml b/contributed_definitions/NXms_ipf.nxdl.xml index 5e0f705959..0be3dc81e4 100644 --- a/contributed_definitions/NXms_ipf.nxdl.xml +++ b/contributed_definitions/NXms_ipf.nxdl.xml @@ -69,7 +69,7 @@ The direction along which orientations are projected. - + @@ -139,7 +139,8 @@ \@axis_x_indices: 0 \@axis_y_indices: 1--> - +tech partners oftentimes do not report to more than calibrated pixel position +--> Inverse pole figure color code for each map coordinate. - + @@ -161,7 +163,7 @@ tech partners oftentimes do not report to more than calibrated pixel position--> Pixel center coordinate calibrated for step size along the z axis of the map. - + @@ -170,7 +172,7 @@ tech partners oftentimes do not report to more than calibrated pixel position--> Pixel center coordinate calibrated for step size along the y axis of the map. - + @@ -179,7 +181,7 @@ tech partners oftentimes do not report to more than calibrated pixel position--> Pixel center coordinate calibrated for step size along the x axis of the map. - + @@ -218,11 +220,13 @@ title:--> \@axis_x_indices: 0 \@axis_y_indices: 1--> - + Inverse pole figure color code for each map coordinate. - + @@ -232,7 +236,7 @@ title:--> Pixel along the y-axis. - + @@ -241,7 +245,7 @@ title:--> Pixel along the x-axis. - + diff --git a/contributed_definitions/NXms_mtex_config.nxdl.xml b/contributed_definitions/NXms_mtex_config.nxdl.xml index 721aeca848..90e4132bee 100644 --- a/contributed_definitions/NXms_mtex_config.nxdl.xml +++ b/contributed_definitions/NXms_mtex_config.nxdl.xml @@ -118,7 +118,7 @@ check against v5.12--> TODO with MTex developers - + @@ -127,7 +127,7 @@ check against v5.12--> TODO with MTex developers - + diff --git a/contributed_definitions/NXms_odf.nxdl.xml b/contributed_definitions/NXms_odf.nxdl.xml index 90c9ae1c18..3e9d11dd70 100644 --- a/contributed_definitions/NXms_odf.nxdl.xml +++ b/contributed_definitions/NXms_odf.nxdl.xml @@ -91,7 +91,7 @@ Euler angle representation of the kth-most maxima of the ODF in decreasing order of the intensity maximum. - + @@ -108,7 +108,7 @@ each location as specified for each location in the order and reported in the order of these locations. - + @@ -134,7 +134,7 @@ ODF intensity at probed locations relative to null model of a completely random texture. - + @@ -144,7 +144,7 @@ Pixel center angular position along the :math:`\varphi_1` direction. - + @@ -153,7 +153,7 @@ Pixel center angular position along the :math:`\varphi_2` direction. - + @@ -162,7 +162,7 @@ Pixel center angular position along the :math:`\Phi` direction. - + diff --git a/contributed_definitions/NXms_pf.nxdl.xml b/contributed_definitions/NXms_pf.nxdl.xml index 7425c8a829..44db61d7b3 100644 --- a/contributed_definitions/NXms_pf.nxdl.xml +++ b/contributed_definitions/NXms_pf.nxdl.xml @@ -82,7 +82,7 @@ Pole figure intensity. - + @@ -92,7 +92,7 @@ Pixel center along y direction in the equatorial plane of a stereographic projection of the unit sphere. - + @@ -102,7 +102,7 @@ Pixel center along x direction in the equatorial plane of a stereographic projection of the unit sphere. - + diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml index 390f039698..f44d34239a 100644 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -193,7 +193,7 @@ ONE DIMENSIONAL FEATURES--> Identifier used for crystals for explicit indexing. - + @@ -209,11 +209,13 @@ ONE DIMENSIONAL FEATURES--> - + Identifier used for phase for explicit indexing. - + @@ -223,7 +225,7 @@ ONE DIMENSIONAL FEATURES--> True, if the crystal makes contact with the edge of the ROI, false otherwise. - + @@ -233,7 +235,7 @@ ONE DIMENSIONAL FEATURES--> crystal at probed positions (weighted by area of that position) versus the average disorientation of the crystal. - + @@ -242,15 +244,17 @@ ONE DIMENSIONAL FEATURES--> Calibrated area of surrounded by the polyline about each crystal. - + - +therefore here a compact and suggestion how to store such data +--> Projections of grain or phase boundaries as typically sectioned with optical or electron microscopy characterization. @@ -270,7 +274,7 @@ i) Set of pair of crystals sharing an interface--> Set of pairs of crystal_identifier resolved via depends_on which are adjacent to each interface. - + @@ -288,7 +292,7 @@ i) Set of pair of crystals sharing an interface--> For 2D projections of 3D microstructural features a triple point is physically only the projection of a triple line. - + @@ -316,7 +320,7 @@ properties, descriptors--> much as possible with interpreting how and where the lines are located in the reference frame. - + @@ -334,16 +338,18 @@ properties, descriptors--> Identifier for each interface using explicit indexing. - + - +the explicit description often generating unnecessary information duplication +--> Projections of triple lines as typically characterized with optical or electron microscopy. @@ -385,7 +391,7 @@ i) triplet of interface identifier--> Identifier for each triple point using explicit indexing. - + @@ -393,7 +399,7 @@ i) triplet of interface identifier--> Set of triple point identifiers. - + @@ -409,7 +415,7 @@ i) triplet of interface identifier--> Each triplet resolves which three interface projections the triple point connects. - + @@ -427,7 +433,7 @@ is assumed discretized via three polylines representing interfaces--> Triplet of identifier of polyline segments. Each triplet resolves which three segments of polyline segments the triple junction connects. - + diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index 9df738e196..24243000c5 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -304,9 +304,11 @@ when the specimen was prepared.--> - +for is a matter of interpretation (fundamentally this is an assumption) and can differ for different descriptors +--> The simulated or characterized material volume element aka domain. At least one instance of geometry required either NXcg_grid, @@ -683,21 +685,27 @@ exists: optional--> - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/contributed_definitions/NXoptical_system_em.nxdl.xml index f908d19d42..0611984a77 100644 --- a/contributed_definitions/NXoptical_system_em.nxdl.xml +++ b/contributed_definitions/NXoptical_system_em.nxdl.xml @@ -66,8 +66,10 @@ work of the HMC EM glossary activities--> - + Beam current as measured relevant for the illumination of the specimen. Users should specify further details like how the beam current diff --git a/contributed_definitions/NXpeak.nxdl.xml b/contributed_definitions/NXpeak.nxdl.xml index fd84d26efb..0eea9cbe3f 100644 --- a/contributed_definitions/NXpeak.nxdl.xml +++ b/contributed_definitions/NXpeak.nxdl.xml @@ -64,7 +64,7 @@ In the case of an empirical description of the peak and its shoulders, this array holds the position values for the independent variable. - + @@ -73,7 +73,7 @@ In the case of an empirical description of the peak and its shoulders, this array holds the intensity/count values at each position. - + diff --git a/contributed_definitions/NXpulser_apm.nxdl.xml b/contributed_definitions/NXpulser_apm.nxdl.xml index 301192ac12..3a856635b9 100644 --- a/contributed_definitions/NXpulser_apm.nxdl.xml +++ b/contributed_definitions/NXpulser_apm.nxdl.xml @@ -48,12 +48,21 @@ - + Frequency with which the pulser fire(s). - + @@ -71,7 +80,7 @@ (as a function of standing voltage). Otherwise, this field should not be present. - + @@ -80,14 +89,16 @@ - +existence constraint is independent of other values. +--> Pulsed voltage, in laser pulsing mode this field can be omitted. - + @@ -100,7 +111,7 @@ existence constraint is independent of other values.--> Absolute number of pulses starting from the beginning of the experiment. - + @@ -116,7 +127,7 @@ existence constraint is independent of other values.--> the case of local electrode atom probe (LEAP) instrument. Otherwise, the standing voltage applied to the sample, relative to system ground. - + @@ -151,7 +162,7 @@ existence constraint is independent of other values.--> Average energy of the laser at peak of each pulse. - + @@ -171,7 +182,7 @@ existence constraint is independent of other values.--> how the laser beam shines on the specimen, i.e. the mean vector is parallel to the laser propagation direction. - + @@ -186,7 +197,7 @@ existence constraint is independent of other values.--> Track time-dependent settings over the course of the measurement where the laser beam exits the focusing optics. - + @@ -201,7 +212,7 @@ existence constraint is independent of other values.--> Track time-dependent settings over the course of the measurement where the laser hits the specimen. - + diff --git a/contributed_definitions/NXrotation_set.nxdl.xml b/contributed_definitions/NXrotation_set.nxdl.xml index c29f3e3f8d..dd55e97e76 100644 --- a/contributed_definitions/NXrotation_set.nxdl.xml +++ b/contributed_definitions/NXrotation_set.nxdl.xml @@ -86,7 +86,7 @@ just how to rotate the object into the reference frame defined by depends_on--> An example of this most complex case is the description of the disorientation between crystals adjoining a hetero-phase boundary. - + @@ -112,7 +112,7 @@ just how to rotate the object into the reference frame defined by depends_on--> eventual inaccuracies just for the sake of reporting a simplified symmetrized description should be avoided. - + @@ -122,7 +122,7 @@ just how to rotate the object into the reference frame defined by depends_on--> crystal_symmetry and sample_symmetry. Rotations which should be interpreted as antipodal are not marked as such. - + @@ -135,7 +135,7 @@ just how to rotate the object into the reference frame defined by depends_on--> conventions behind depends_on to resolve which of the many Euler-angle conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. - + @@ -149,7 +149,7 @@ rotation_axis_angle(NX_NUMBER):--> True for all those value tuples which have assumed antipodal symmetry. False for all others. - + @@ -160,7 +160,7 @@ rotation_axis_angle(NX_NUMBER):--> and sample_symmetry. The supplementary field is_antipodal can be used to mark orientations with the antipodal property. - + @@ -173,7 +173,7 @@ rotation_axis_angle(NX_NUMBER):--> conventions behind depends_on to resolve which of the many Euler-angle conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. - + @@ -191,7 +191,7 @@ misorientation is not necessarily in the fundamental zone--> obeying symmetry operations for equivalent misorientations as defined by crystal_symmetry and sample_symmetry. - + @@ -201,7 +201,7 @@ misorientation is not necessarily in the fundamental zone--> Misorientation angular argument (eventually signed) following the same symmetry assumptions as expressed for the field misorientation_quaternion. - + @@ -210,7 +210,7 @@ misorientation is not necessarily in the fundamental zone--> Misorientation axis (normalized) and signed following the same symmetry assumptions as expressed for the field misorientation_angle. - + @@ -223,7 +223,7 @@ fundamental zone of SO3 for given crystal and sample symmetry--> obeying symmetry operations for equivalent misorientations as defined by crystal_symmetry and sample_symmetry. - + @@ -235,7 +235,7 @@ fundamental zone of SO3 for given crystal and sample symmetry--> following the same symmetry assumptions as expressed for the field disorientation_quaternion. - + @@ -244,7 +244,7 @@ fundamental zone of SO3 for given crystal and sample symmetry--> Disorientation axis (normalized) following the same symmetry assumptions as expressed for the field disorientation_angle. - + diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/contributed_definitions/NXscanbox_em.nxdl.xml index 46377479c2..56fe3ec6c7 100644 --- a/contributed_definitions/NXscanbox_em.nxdl.xml +++ b/contributed_definitions/NXscanbox_em.nxdl.xml @@ -68,10 +68,12 @@ TODO discuss with the electron microscopists. - + url: https://em-glossary.vercel.app/term/em-dwell-time +--> Time period during which the beam remains at one position. diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index dd5f5246df..e9d893e285 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -99,7 +99,7 @@ results for the object set--> For classical clustering algorithms this can for instance encode the cluster_identifier. - + @@ -108,7 +108,7 @@ results for the object set--> Matrix of categorical attribute data for each member in the set. - + @@ -141,7 +141,7 @@ when knowing total, noise, and unassigned.--> Array of numerical identifier of each feature. - + @@ -149,7 +149,7 @@ when knowing total, noise, and unassigned.--> Array of number of objects for each feature. - + diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/contributed_definitions/NXspectrum_set.nxdl.xml index b743f33885..b8ee62d737 100644 --- a/contributed_definitions/NXspectrum_set.nxdl.xml +++ b/contributed_definitions/NXspectrum_set.nxdl.xml @@ -95,7 +95,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Counts - + @@ -109,7 +109,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Energy axis - + @@ -128,7 +128,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Counts - + @@ -142,7 +142,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Coordinate along x direction. - + @@ -155,7 +155,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Energy axis - + @@ -174,7 +174,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Counts - + @@ -189,7 +189,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Coordinate along y direction. - + @@ -202,7 +202,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Coordinate along x direction. - + @@ -215,7 +215,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Energy axis - + @@ -234,7 +234,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Counts - + @@ -250,7 +250,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Coordinate along z direction. - + @@ -263,7 +263,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Coordinate along y direction. - + @@ -276,7 +276,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Coordinate along x direction. - + @@ -289,7 +289,7 @@ lik omega/q mapping more complicated scan pattern than rectangular ones.--> Energy axis - + @@ -313,7 +313,7 @@ base classes--> Counts - + @@ -327,7 +327,7 @@ base classes--> Scan point identifier - + @@ -340,7 +340,7 @@ base classes--> Energy axis - + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index f9f537938c..422bba19f5 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -143,7 +143,7 @@ The interpretation of this tilt should be specialized and thus detailed via the application definition. - + diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml index 0f7da2bfa6..0310e9f260 100644 --- a/contributed_definitions/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -40,7 +40,7 @@ symbols:--> second identifier. Setting min_incr_max to [90, 3, 99] will take each third identifier beginning from identifier 90 up to 99. - + diff --git a/requirements.txt b/requirements.txt index d27f482456..7603f693e9 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1,7 +1,7 @@ # Prepare for Documentation lxml pyyaml -nyaml +nyaml==0.0.8 # Documentation building sphinx>=5 From 09a962f17e6bd579990692f18fd4b6869f538ab2 Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Tue, 5 Mar 2024 12:16:11 +0100 Subject: [PATCH 0622/1012] Adds tabs to nyaml.mk to work under Windows (#189) --- nyaml.mk | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/nyaml.mk b/nyaml.mk index baf000b560..5a475dedb6 100644 --- a/nyaml.mk +++ b/nyaml.mk @@ -9,16 +9,16 @@ NXDL_CONTRIB_TARGETS = $(addprefix $(CONTRIB_DIR)/nyaml/,$(notdir $(patsubst %.n .PHONY: all nyaml $(BASE_CLASS_DIR)/$(NYAML_SUBDIR)/%.yaml : $(BASE_CLASS_DIR)/%.nxdl.xml -@mkdir -p $(@D) -nyaml2nxdl $< --output-file $@ + @mkdir -p $(@D) + nyaml2nxdl $< --output-file $@ $(CONTRIB_DIR)/$(NYAML_SUBDIR)/%.yaml : $(CONTRIB_DIR)/%.nxdl.xml -@mkdir -p $(@D) -nyaml2nxdl $< --output-file $@ + @mkdir -p $(@D) + nyaml2nxdl $< --output-file $@ $(APPDEF_DIR)/$(NYAML_SUBDIR)/%.yaml : $(APPDEF_DIR)/%.nxdl.xml -@mkdir -p $(@D) -nyaml2nxdl $< --output-file $@ + @mkdir -p $(@D) + nyaml2nxdl $< --output-file $@ nyaml: $(NXDL_BC_TARGETS) $(NXDL_APPDEF_TARGETS) $(NXDL_CONTRIB_TARGETS) From ffc719677c5199270264c381e9bebe4bd65035c3 Mon Sep 17 00:00:00 2001 From: Ron <139139971+RonHildebrandt@users.noreply.github.com> Date: Wed, 6 Mar 2024 12:51:36 +0100 Subject: [PATCH 0623/1012] Add nexus definitions/files for beam path description (#183) * Add nexus definitions/files for beam path description * Update base_classes/nyaml/NXopt_assembly.yaml Co-authored-by: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> * Update base_classes/nyaml/NXopt_assembly.yaml Co-authored-by: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> * Apply suggestions from code review Co-authored-by: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> * Apply suggestions from code review Co-authored-by: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> * Apply suggestions from code review Co-authored-by: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> * Apply suggestions from code review Co-authored-by: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> * Apply suggestions from code review Co-authored-by: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> * Apply suggestions from code review Co-authored-by: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> * Apply suggestions from code review Co-authored-by: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> * add_NX_defs_for_beam_path * modifying_yaml_files * fixing_nyaml_make_file * Adjusted files with Sandor together according to earlier hardcoded .nxs file * Added the missing nxdl.xml files via nyaml2nxdl Version=0.0.8 was used for nyaml. * moved created nxdl.xml files to correct directory * Suggestions to fix ci/cd by in NXtransfer_matrix_table.yaml Co-authored-by: Florian Dobener * renaming transfer_matrix_table to beam_transfermatrix_table and opt_element to beam_device; also merging NXopt_beam to NXbeam * remove old nxdl files --------- Co-authored-by: Ron Hildebrandt Co-authored-by: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Co-authored-by: Florian Dobener --- base_classes/NXbeam.nxdl.xml | 23 +++- base_classes/nyaml/NXbeam.yaml | 8 +- .../NXbeam_device.nxdl.xml | 67 ++++++++++ .../NXbeam_transfer_matrix_table.nxdl.xml | 120 ++++++++++++++++++ .../nyaml/NXbeam_device.yaml | 41 ++++++ .../nyaml/NXbeam_transfer_matrix_table.yaml | 85 +++++++++++++ nyaml.mk | 2 +- 7 files changed, 338 insertions(+), 8 deletions(-) create mode 100644 contributed_definitions/NXbeam_device.nxdl.xml create mode 100644 contributed_definitions/NXbeam_transfer_matrix_table.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXbeam_device.yaml create mode 100644 contributed_definitions/nyaml/NXbeam_transfer_matrix_table.yaml diff --git a/base_classes/NXbeam.nxdl.xml b/base_classes/NXbeam.nxdl.xml index 9bf36c06be..67c6dc4b26 100644 --- a/base_classes/NXbeam.nxdl.xml +++ b/base_classes/NXbeam.nxdl.xml @@ -1,10 +1,10 @@ - + + + + Properties of generic beam device in an experimental setup. + + Any beam related devices like source, detector, filter, mirror, + beamsplitter, ... which may modifies a beam in an experimental setup + can be described here with its experimental position and relationship + to the other beam devices in the setup. + + + + Single device or list of devices pointing to the devices from which an + beam originated to reach this device. + This is used to describe a logical order of devices and for the whole setup. + In this way, a "beam path" can be described (i.e., with starting point (light source) + and end point (photo detector)). + + Example: /entry/instrument/detector. + + + + + Description of the intended purpose of this device for + the experimental setup. + + + + + Name of the group with which this device can be associated. + For example, if a group of devices is used for second harmonic generation, + all these devices have the group name "second harmonic generation". + Is used for simplified setup vizualization (or description?). + + + + + Location and orientation of the device. Note that even a + simple distance can be given as a translation. + + You can use the @depends_on to describe from which device + the transformation needs to be applied. + + + diff --git a/contributed_definitions/NXbeam_transfer_matrix_table.nxdl.xml b/contributed_definitions/NXbeam_transfer_matrix_table.nxdl.xml new file mode 100644 index 0000000000..570ac74dbd --- /dev/null +++ b/contributed_definitions/NXbeam_transfer_matrix_table.nxdl.xml @@ -0,0 +1,120 @@ + + + + + + + Variables used throughout the document, e.g. dimensions or parameters. + + + + Length of the array associated to the data type. + + + + + Contains datastructures of an experimental optical setup (i.e., multiple + transfermatrix tables). These datastructures are used to relate physical + properties of two beams (NXbeam) which have one common optical element + (NXopt_element) (one specific transfermatrix). + One of these beams in an input beam and the other one is an output beam. + + The data describes the change of beam properties, e.g. the intensity of a + beam is reduced because the transmission coefficient of the beam device is + lower than 1. + + + + Select which type of data was recorded, for example aperture and + focal length. + It is possible to have multiple selections. This selection defines + how many columns (N_variables) are stored in the data array. + N in the name, is the index number in which order the given + property is listed. + + + + + + + + + + + Please list in this array the column and row names used in your actual data. + That is in the case of aperture ['diameter'] or focal length ['focal_length_value'] + and for orientation matrix ['OM1', 'OM2', 'OM3'] or for jones matrix + ['JM1','JM2'] + + + + + + + + Contains the datastructure which relates beam properties of an + input and output beam as result of the input beam interaction + with the beam device. + + Transfermatrix relationship between N input beams and M output beams. + It contains a table with the relevant matricis to be used for different + transmissitted properties (such as polarization, intensity, phase). + + Data structure for all transfermatrices of an beam device in a setup. + For each combination of N input and M output beams and for L physical + concept (i.e. beam intensity), one matrix can be defined. + + In this way, the transfermatrix table has the dimension NxM. + + For each entry, in this transfermatrix, there are L formalisms. + Each formalism has the dimension math:`dim(L_i)xdim(L_i)`, + whereby math:`L_i` is the specific physical concept (Intensity, polarization, direction). + + A beamsplitter with two input laser beams can have a total of + four transfermatrices (2 Input x 2 Output). + + The dimension of the transfermatrix depends on the parameters. + Examples are: + 1x1 for intensity/power + 2x2 for jones formalism + 3x3 for direction + + + + Specific name of input beam which the transfermatrix table is related to. + + + + + Specific name of output beam which the transfermatrix table is related to. + + + + + Square matrix with dimension N_variables x N_variables + + + + + + diff --git a/contributed_definitions/nyaml/NXbeam_device.yaml b/contributed_definitions/nyaml/NXbeam_device.yaml new file mode 100644 index 0000000000..3af998a41e --- /dev/null +++ b/contributed_definitions/nyaml/NXbeam_device.yaml @@ -0,0 +1,41 @@ +category: base +doc: | + Properties of generic beam device in an experimental setup. + + Any beam related devices like source, detector, filter, mirror, + beamsplitter, ... which may modifies a beam in an experimental setup + can be described here with its experimental position and relationship + to the other beam devices in the setup. + + +NXbeam_device(NXobject): + + previous_devices: + doc: | + Single device or list of devices pointing to the devices from which an + beam originated to reach this device. + This is used to describe a logical order of devices and for the whole setup. + In this way, a "beam path" can be described (i.e., with starting point (light source) + and end point (photo detector)). + + Example: /entry/instrument/detector. + purpose(NX_CHAR): + doc: | + Description of the intended purpose of this device for + the experimental setup. + + group(NX_CHAR): + doc: | + Name of the group with which this device can be associated. + For example, if a group of devices is used for second harmonic generation, + all these devices have the group name "second harmonic generation". + Is used for simplified setup vizualization (or description?). + + + (NXtransformations): + doc: | + Location and orientation of the device. Note that even a + simple distance can be given as a translation. + + You can use the @depends_on to describe from which device + the transformation needs to be applied. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXbeam_transfer_matrix_table.yaml b/contributed_definitions/nyaml/NXbeam_transfer_matrix_table.yaml new file mode 100644 index 0000000000..60df03907c --- /dev/null +++ b/contributed_definitions/nyaml/NXbeam_transfer_matrix_table.yaml @@ -0,0 +1,85 @@ +category: base +doc: | + Contains datastructures of an experimental optical setup (i.e., multiple + transfermatrix tables). These datastructures are used to relate physical + properties of two beams (NXbeam) which have one common optical element + (NXopt_element) (one specific transfermatrix). + One of these beams in an input beam and the other one is an output beam. + + The data describes the change of beam properties, e.g. the intensity of a + beam is reduced because the transmission coefficient of the beam device is + lower than 1. +symbols: + doc: | + Variables used throughout the document, e.g. dimensions or parameters. + N_variables: | + Length of the array associated to the data type. +NXbeam_transfer_matrix_table(NXobject): + datatype_N: + doc: | + Select which type of data was recorded, for example aperture and + focal length. + It is possible to have multiple selections. This selection defines + how many columns (N_variables) are stored in the data array. + N in the name, is the index number in which order the given + property is listed. + enumeration: + [ + aperture, + focallength, + orientation, + jones matrix, + ] + matrix_elements: + doc: | + Please list in this array the column and row names used in your actual data. + That is in the case of aperture ['diameter'] or focal length ['focal_length_value'] + and for orientation matrix ['OM1', 'OM2', 'OM3'] or for jones matrix + ['JM1','JM2'] + dimensions: + rank: 1 + dim: [[1, N_variables]] + + TRANSFER_MATRIX(NX_NUMBER): + doc: | + Contains the datastructure which relates beam properties of an + input and output beam as result of the input beam interaction + with the beam device. + + Transfermatrix relationship between N input beams and M output beams. + It contains a table with the relevant matricis to be used for different + transmissitted properties (such as polarization, intensity, phase). + + Data structure for all transfermatrices of an beam device in a setup. + For each combination of N input and M output beams and for L physical + concept (i.e. beam intensity), one matrix can be defined. + + In this way, the transfermatrix table has the dimension NxM. + + For each entry, in this transfermatrix, there are L formalisms. + Each formalism has the dimension math:`dim(L_i)xdim(L_i)`, + whereby math:`L_i` is the specific physical concept (Intensity, polarization, direction). + + A beamsplitter with two input laser beams can have a total of + four transfermatrices (2 Input x 2 Output). + + The dimension of the transfermatrix depends on the parameters. + Examples are: + 1x1 for intensity/power + 2x2 for jones formalism + 3x3 for direction + \@input: + doc: | + Specific name of input beam which the transfermatrix table is related to. + \@output: + doc: | + Specific name of output beam which the transfermatrix table is related to. + dimensions: + doc: | + Square matrix with dimension N_variables x N_variables + rank: 2 + dim: + [ + [1, N_variables], + [2, N_variables], + ] \ No newline at end of file diff --git a/nyaml.mk b/nyaml.mk index 5a475dedb6..898ebd6cc5 100644 --- a/nyaml.mk +++ b/nyaml.mk @@ -22,4 +22,4 @@ $(APPDEF_DIR)/$(NYAML_SUBDIR)/%.yaml : $(APPDEF_DIR)/%.nxdl.xml nyaml: $(NXDL_BC_TARGETS) $(NXDL_APPDEF_TARGETS) $(NXDL_CONTRIB_TARGETS) -all: nyaml \ No newline at end of file +all: nyaml From a048e9f2a207d61c1be5429bad23648d5cf88b39 Mon Sep 17 00:00:00 2001 From: sanbrock <45483558+sanbrock@users.noreply.github.com> Date: Wed, 6 Mar 2024 14:57:11 +0100 Subject: [PATCH 0624/1012] fix for NXbeam... (#191) * replace block dimensions * pinning lxml, because old versions fail --- .../NXbeam_transfer_matrix_table.nxdl.xml | 14 +++++++------- .../nyaml/NXbeam_transfer_matrix_table.yaml | 14 +++++++------- requirements.txt | 2 +- 3 files changed, 15 insertions(+), 15 deletions(-) diff --git a/contributed_definitions/NXbeam_transfer_matrix_table.nxdl.xml b/contributed_definitions/NXbeam_transfer_matrix_table.nxdl.xml index 570ac74dbd..d61f275566 100644 --- a/contributed_definitions/NXbeam_transfer_matrix_table.nxdl.xml +++ b/contributed_definitions/NXbeam_transfer_matrix_table.nxdl.xml @@ -99,6 +99,13 @@ 2x2 for jones formalism 3x3 for direction + + + Square matrix with dimension N_variables x N_variables + + + + Specific name of input beam which the transfermatrix table is related to. @@ -109,12 +116,5 @@ Specific name of output beam which the transfermatrix table is related to. - - - Square matrix with dimension N_variables x N_variables - - - - diff --git a/contributed_definitions/nyaml/NXbeam_transfer_matrix_table.yaml b/contributed_definitions/nyaml/NXbeam_transfer_matrix_table.yaml index 60df03907c..1c75fe05a2 100644 --- a/contributed_definitions/nyaml/NXbeam_transfer_matrix_table.yaml +++ b/contributed_definitions/nyaml/NXbeam_transfer_matrix_table.yaml @@ -68,12 +68,6 @@ NXbeam_transfer_matrix_table(NXobject): 1x1 for intensity/power 2x2 for jones formalism 3x3 for direction - \@input: - doc: | - Specific name of input beam which the transfermatrix table is related to. - \@output: - doc: | - Specific name of output beam which the transfermatrix table is related to. dimensions: doc: | Square matrix with dimension N_variables x N_variables @@ -82,4 +76,10 @@ NXbeam_transfer_matrix_table(NXobject): [ [1, N_variables], [2, N_variables], - ] \ No newline at end of file + ] + \@input: + doc: | + Specific name of input beam which the transfermatrix table is related to. + \@output: + doc: | + Specific name of output beam which the transfermatrix table is related to. diff --git a/requirements.txt b/requirements.txt index 7603f693e9..74294d9b26 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1,5 +1,5 @@ # Prepare for Documentation -lxml +lxml>=4.9.1 pyyaml nyaml==0.0.8 From 4ca4a1577da0cfee38459030e1bed1fdc9d59ec9 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 15 Mar 2024 11:52:15 +0100 Subject: [PATCH 0625/1012] rename NXphotoemission back to NXmpes --- contributed_definitions/NXmpes.nxdl.xml | 786 ++++++++- .../NXphotoemission.nxdl.xml | 811 --------- contributed_definitions/nyaml/NXmpes.yaml | 1496 +++++++++++++++- .../nyaml/NXphotoemission.yaml | 1520 ----------------- 4 files changed, 2165 insertions(+), 2448 deletions(-) delete mode 100644 contributed_definitions/NXphotoemission.nxdl.xml delete mode 100644 contributed_definitions/nyaml/NXphotoemission.yaml diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index d642df82cb..24db440d0d 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -21,10 +21,10 @@ # # For further information, see http://www.nexusformat.org --> - + - This is the most general application definition for multidimensional - photoelectron spectroscopy. + This is the most general application definition for + photoemission experiments. Groups and fields are named according to the `ISO 18115-1:2023`_ specification as well as the `IUPAC Recommendations 2020`_. @@ -34,25 +34,760 @@ + + + + + Datetime of the start of the measurement. + Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, + otherwise the local time zone is assumed per ISO8601. + + + + + Datetime of the end of the measurement. + Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, + otherwise the local time zone is assumed per ISO8601. + + + + + Name of the experimental method. + + If applicable, this name should match the terms given by `Clause 11`_ of + the `ISO 18115-1:2023`_ specification. + + Examples include: + * X-ray photoelectron spectroscopy (XPS) + * angle-resolved X-ray photoelectron spectroscopy (ARXPS) + * ultraviolet photoelectron spectroscopy (UPS) + * angle-resolved photoelectron spectroscopy (ARPES) + * hard X-ray photoemission spectroscopy (HAXPES) + * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) + * photoelectron emission microscopy (PEEM) + * electron spectroscopy for chemical analysis (ESCA) + * time-resolved angle-resolved X-ray photoelectron spectroscopy (trARPES) + * spin-resolved angle-resolved X-ray photoelectron spectroscopy (spin-ARPES) + * momentum microscopy + + .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 + + + + + Description of one or more coordinate systems that are specific to the setup + and the measurement geometry. + + + + + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + + + + Name of the user. + + + + + Name of the affiliation of the user at the time when the experiment was + performed. + + + - + + Description of the photoemission spectrometer and its individual parts. + + This concept is related to term `12.58`_ of the ISO 18115-1:2023 standard. + + .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 + + + + + + + + + Overall energy resolution of the photoemission instrument. + + + + + + + + + + Minimum distinguishable energy separation in the energy spectra. + + This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. + + .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 + + + + + + Ratio of the energy resolution of the photoemission spectrometer at a specified energy + value to that energy value. + + This concept is related to term `10.7 ff.`_ of the ISO 18115-1:2023 standard. + + .. _10.7 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 + + + + + + A source used to generate a beam. Properties refer strictly to parameters of the + source, not of the output beam. For example, the energy of the source is not the + optical power of the beam, but the energy of the electron beam in a synchrotron + or similar. + + Note that the uppercase notation in sourceTYPE means that multiple sources can + be provided. For example, in pump-probe experiments, it is possible to have both + a `source_probe` and a `source_pump` + + + + + + + + + + + + + + + + + + + + Specification of type, may also go to name. + + + + + + + + + + + + The beam emitted by this source. + Should be named with the same appendix, e.g., + for `source_probe` it should refer to `beam_probe`. + Refers to the same concept as /NXentry/NXinstrument/beamTYPE + and may be linked. + + + + - Overall energy resolution of the MPES instrument. + Properties of the photon beam at a given location. + Should be named with the same appendix as sourceTYPE, e.g., + for `source_probe` it should refer to `beam_probe`. + + + Distance between the point where the current NXbeam instance is evaluating + the beam properties and the point where the beam interacts with the sample. + For photoemission, the latter is the point where the the centre of the beam + touches the sample surface. + + + + + + + + + The source that emitted this beam. + Should be named with the same appendix, e.g., + for `beam_probe` it should refer to `source_probe`. + Refers to the same concept as /NXentry/NXinstrument/sourceTYPE + and may be linked. + Should be specified if an associated source exists. + + - + + + + + + + + + + + + + + + + + + + + + + + Scheme of the electron collection column. + + + + + + + + + + + + + + + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + + + + + Size, position and shape of the iris inserted in the column. + + The iris is an aperture in the lens with a variable diameter which can reduce the number of + electrons entering the analyzer. + + To add additional or other slits use the APERTURE group of NXcollectioncolumn. + + + + + + + + + + + + + + + + + + + + + + Either `pass_energy` or `drift_energy` must be supplied. `pass_energy` should be used when working + with hemispherical analysers. + + + + + Either `pass_energy` or `drift_energy` must be supplied. `drift_energy` should be used if a TOF is used in the + energy dispersive part of the electron analyzer. + + + + + + Size, position and shape of the entrance slit in dispersive analyzers. + + To add additional or other slits use the APERTURE group of NXenergydispersion. + + + + + Size, position and shape of the exit slit in dispersive analyzers. + + To add additional or other slits use the APERTURE group of NXenergydispersion. + + + + + + + + + + + + Type of electron amplifier in the first amplification step. + + + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + + + Contains the raw data collected by the detector before calibration. + The data which is considered raw might change from experiment to experiment + due to hardware pre-processing of the data. + This field ideally collects the data with the lowest level of processing + possible. + + The naming of fields should follow the convention defined in the + :ref:`NXdata_mpes_detector` base class: + + - **pixel_x**: Detector pixel in x direction. + - **pixel_y**: Detector pixel in y direction. + - **energy**: (Un)calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). + - **momentum**: Calibrated momentum axis. Unit category: NX_ANY (e.g., kg*m/s). + - **kx**: (Un)calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). + - **ky**: (Un)calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). + - **kz**: (Un)calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). + - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). + Unit category: NX_ANGLE + - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) + Unit category: NX_ANGLE + - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) + Unit category: NX_LENGTH + - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) + Unit category: NX_LENGTH + - **delay**: Calibrated delay time. Unit category: NX_TIME (s). + - **polarization_angle**: Linear polarization angle of the incoming or + outgoing beam. + Unit category: NX_ANGLE (° or rad) + - **ellipticity**: Ellipticity of the incoming or outgoing beam. + Unit category: NX_ANGLE (° or rad) + - **time_of_flight**: Total time of flight. Unit category: NX_TIME_OF_FLIGHT + - **time_of_flight_adc**: Time-of-flight values, analog-to-digital converted. + - **external_AXIS**: Describes an axis which is coming from outside the detectors scope. + + + + + + + + + Raw data before calibration. + + + + + + + + Manipulator for positioning of the sample. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Device to measure the gas pressure around the sample. + + + + + + + + + + + In case of a single or averaged gas pressure measurement, this is the scalar gas pressure around + the sample. It can also be an 1D array of measured pressures (without time stamps). + + + + + + In the case of an experiment in which the gas pressure changes and is recorded, + this is an array of length m of gas pressures. + + + + + + + Device to bring low-energy electrons to the sample for charge neutralization + + + + + + + + + + + In case of a fixed or averaged electron current, this is the scalar current. + It can also be an 1D array of output current (without time stamps). + + + + + + In the case of an experiment in which the electron current is changed and + recorded with time stamps, this is an array of length m of current setpoints. + + + + + + + A set of activities that occurred to the instrument prior to/during the photoemission + experiment, including any activities performed on the individual instrument parts. + This group can be used to describe the preparation of the instrument prior to the + experiment, e.g. the cleaning procedure for a spin filter crystal. + - - + + + Document an event of data processing, reconstruction, or analysis for this data. + The appropriate axis calibrations for a given experiment should be described using + one or more of the following NXcalibrations. The individual calibrations for a given + `AXISNAME` in `data` should be called `AXISNAME_calibration`. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Kinetic energy values + + + + + + + + Relative transmission efficiency for the given kinetic energies + + + + + + + - - + + + + + For samples containing a single pure substance. For mixtures use the + NXsample_component_set and NXsample_component group in NXsample instead. + + + + The chemical formula of the sample (using CIF conventions). + + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + + + + + + + + + + + + + A set of activities that occurred to the sample prior to/during photoemission + experiment. + + + + Details about the sample preparation for the photoemission experiment (e.g. UHV cleaving, + in-situ growth, sputtering/annealing, etc.). + + + + + + Details about the method of sample preparation before the photoemission + experiment. + + + + + + + Sample temperature (either controlled or just measured). + + + + Temperature sensor measuring the sample temperature. + This should be a link to /entry/instrument/manipulator/temperature_sensor. + + + + + Device to heat the sample. + This should be a link to /entry/instrument/manipulator/sample_heater. + + + + + Cryostat for cooling the sample. + This should be a link to /entry/instrument/manipulator/cryostat. + + + + + + Gas pressure surrounding the sample. + + + + Gauge measuring the gas pressure. + + This should be a link to /entry/instrument/pressure_gauge. + + + + + + Bias of the sample with respect to analyser ground. + + This concept is related to term `8.41`_ of the ISO 18115-1:2023 standard. + + .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 + + + + Sensor measuring the applied voltage. + + This should be a link to /entry/instrument/manipulator/sample_bias_voltmeter. + + + + + Actuator applying a voltage to sample and sample holder. + + This should be a link to /entry/instrument/manipulator/sample_bias_potentiostat. + + + + + + Drain current of the sample and sample holder. + + + + Amperemeter measuring the drain current of the sample and sample holder. + + This should be a link to /entry/instrument/manipulator/drain_current_amperemeter. + + + + + + Current of low-energy electrons to the sample for charge neutralization. + + + + Flood gun creating a current of low-energy electrons. + + This should be a link to /entry/instrument/flood_gun. + + + + + + + The default NXdata field containing a view on the measured data. + This NXdata field contains a collection of the main relevant fields (axes). + If you want to provide additional views on your data, you can additionally use + the generic NXdata group of NXentry. + + The naming of fields should follow the convention defined in the + :ref:`NXdata_mpes` base class: + + - **energy**: Calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). + - **momentum**: Calibrated momentum axis. Unit category: NX_ANY (e.g., kg*m/s). + - **kx**: Calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). + - **ky**: Calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). + - **kz**: Calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). + - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). + Unit category: NX_ANGLE + - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) + Unit category: NX_ANGLE + - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) + Unit category: NX_LENGTH + - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) + Unit category: NX_LENGTH + - **delay**: Calibrated delay time. Unit category: NX_TIME (s). + - **polarization_angle**: Linear polarization angle of the incoming or + outgoing beam. This could be a link to + /entry/instrument/beam/incident_polarization_angle or + /entry/instrument/beam/final_polarization_angle if they exist. + Unit category: NX_ANGLE (° or rad) + - **ellipticity**: Ellipticity of the incoming or outgoing beam. + Could be a link to /entry/instrument/beam/incident_ellipticity or + /entry/instrument/beam/final_ellipticity if they exist. + Unit category: NX_ANGLE (° or rad) + + + + + + + + + Represents a measure of one- or more-dimensional photoemission counts, where the + varied axis may be for example energy, momentum, spatial coordinate, pump-probe + delay, spin index, temperature, etc. The axes traces should be linked to the + actual encoder position in NXinstrument or calibrated axes in NXprocess. + + + Calibrated energy axis. @@ -60,37 +795,8 @@ /entry/process/energy_calibration/calibrated_axis or /entry/process/energy_correction/calibrated_axis. - - - The energy can be either stored as kinetic or as binding energy. - - - - - Calibrated kinetic energy axis. - - In case the kinetic energy axis is referenced to the Fermi level :math:`E_F` - (e.g., in entry/process/energy_referencing), kinetic energies :math:`E` are - provided as :math:`E-E_F`. - - This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. - - .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 - - - - - Calibrated binding energy axis. - - This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. - - .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - - - - + - The energy can be dispersed according to different strategies. ``energy_depends`` points to diff --git a/contributed_definitions/NXphotoemission.nxdl.xml b/contributed_definitions/NXphotoemission.nxdl.xml deleted file mode 100644 index b4ce651e35..0000000000 --- a/contributed_definitions/NXphotoemission.nxdl.xml +++ /dev/null @@ -1,811 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of data points in the transmission function. - - - - - This is the most general application definition for - photoemission experiments. - - Groups and fields are named according to the - `ISO 18115-1:2023`_ specification as well as the `IUPAC Recommendations 2020`_. - - .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html - .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 - - - - - - - - - - - - Datetime of the start of the measurement. - Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, - otherwise the local time zone is assumed per ISO8601. - - - - - Datetime of the end of the measurement. - Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, - otherwise the local time zone is assumed per ISO8601. - - - - - Name of the experimental method. - - If applicable, this name should match the terms given by `Clause 11`_ of - the `ISO 18115-1:2023`_ specification. - - Examples include: - * X-ray photoelectron spectroscopy (XPS) - * angle-resolved X-ray photoelectron spectroscopy (ARXPS) - * ultraviolet photoelectron spectroscopy (UPS) - * angle-resolved photoelectron spectroscopy (ARPES) - * hard X-ray photoemission spectroscopy (HAXPES) - * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) - * photoelectron emission microscopy (PEEM) - * electron spectroscopy for chemical analysis (ESCA) - * time-resolved angle-resolved X-ray photoelectron spectroscopy (trARPES) - * spin-resolved angle-resolved X-ray photoelectron spectroscopy (spin-ARPES) - * momentum microscopy - - .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html - .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 - - - - - Description of one or more coordinate systems that are specific to the setup - and the measurement geometry. - - - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the time when the experiment was - performed. - - - - - - Description of the photoemission spectrometer and its individual parts. - - This concept is related to term `12.58`_ of the ISO 18115-1:2023 standard. - - .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 - - - - - - - - - Overall energy resolution of the photoemission instrument. - - - - - - - - - - Minimum distinguishable energy separation in the energy spectra. - - This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. - - .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 - - - - - - Ratio of the energy resolution of the photoemission spectrometer at a specified energy - value to that energy value. - - This concept is related to term `10.7 ff.`_ of the ISO 18115-1:2023 standard. - - .. _10.7 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 - - - - - - A source used to generate a beam. Properties refer strictly to parameters of the - source, not of the output beam. For example, the energy of the source is not the - optical power of the beam, but the energy of the electron beam in a synchrotron - or similar. - - Note that the uppercase notation in sourceTYPE means that multiple sources can - be provided. For example, in pump-probe experiments, it is possible to have both - a `source_probe` and a `source_pump` - - - - - - - - - - - - - - - - - - - - Specification of type, may also go to name. - - - - - - - - - - - - The beam emitted by this source. - Should be named with the same appendix, e.g., - for `source_probe` it should refer to `beam_probe`. - Refers to the same concept as /NXentry/NXinstrument/beamTYPE - and may be linked. - - - - - - Properties of the photon beam at a given location. - Should be named with the same appendix as sourceTYPE, e.g., - for `source_probe` it should refer to `beam_probe`. - - - - Distance between the point where the current NXbeam instance is evaluating - the beam properties and the point where the beam interacts with the sample. - For photoemission, the latter is the point where the the centre of the beam - touches the sample surface. - - - - - - - - - The source that emitted this beam. - Should be named with the same appendix, e.g., - for `beam_probe` it should refer to `source_probe`. - Refers to the same concept as /NXentry/NXinstrument/sourceTYPE - and may be linked. - Should be specified if an associated source exists. - - - - - - - - - - - - - - - - - - - - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - Size, position and shape of the iris inserted in the column. - - The iris is an aperture in the lens with a variable diameter which can reduce the number of - electrons entering the analyzer. - - To add additional or other slits use the APERTURE group of NXcollectioncolumn. - - - - - - - - - - - - - - - - - - - - - - Either `pass_energy` or `drift_energy` must be supplied. `pass_energy` should be used when working - with hemispherical analysers. - - - - - Either `pass_energy` or `drift_energy` must be supplied. `drift_energy` should be used if a TOF is used in the - energy dispersive part of the electron analyzer. - - - - - - Size, position and shape of the entrance slit in dispersive analyzers. - - To add additional or other slits use the APERTURE group of NXenergydispersion. - - - - - Size, position and shape of the exit slit in dispersive analyzers. - - To add additional or other slits use the APERTURE group of NXenergydispersion. - - - - - - - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - - Contains the raw data collected by the detector before calibration. - The data which is considered raw might change from experiment to experiment - due to hardware pre-processing of the data. - This field ideally collects the data with the lowest level of processing - possible. - - The naming of fields should follow the convention defined in the - :ref:`NXdata_photoemission_detector` base class: - - - **pixel_x**: Detector pixel in x direction. - - **pixel_y**: Detector pixel in y direction. - - **energy**: (Un)calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). - - **momentum**: Calibrated momentum axis. Unit category: NX_ANY (e.g., kg*m/s). - - **kx**: (Un)calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). - - **ky**: (Un)calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). - - **kz**: (Un)calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). - - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). - Unit category: NX_ANGLE - - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - Unit category: NX_ANGLE - - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) - Unit category: NX_LENGTH - - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - Unit category: NX_LENGTH - - **delay**: Calibrated delay time. Unit category: NX_TIME (s). - - **polarization_angle**: Linear polarization angle of the incoming or - outgoing beam. - Unit category: NX_ANGLE (° or rad) - - **ellipticity**: Ellipticity of the incoming or outgoing beam. - Unit category: NX_ANGLE (° or rad) - - **time_of_flight**: Total time of flight. Unit category: NX_TIME_OF_FLIGHT - - **time_of_flight_adc**: Time-of-flight values, analog-to-digital converted. - - **external_AXIS**: Describes an axis which is coming from outside the detectors scope. - - - - - - - - - Raw data before calibration. - - - - - - - - Manipulator for positioning of the sample. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Device to measure the gas pressure around the sample. - - - - - - - - - - - In case of a single or averaged gas pressure measurement, this is the scalar gas pressure around - the sample. It can also be an 1D array of measured pressures (without time stamps). - - - - - - In the case of an experiment in which the gas pressure changes and is recorded, - this is an array of length m of gas pressures. - - - - - - - Device to bring low-energy electrons to the sample for charge neutralization - - - - - - - - - - - In case of a fixed or averaged electron current, this is the scalar current. - It can also be an 1D array of output current (without time stamps). - - - - - - In the case of an experiment in which the electron current is changed and - recorded with time stamps, this is an array of length m of current setpoints. - - - - - - - A set of activities that occurred to the instrument prior to/during the photoemission - experiment, including any activities performed on the individual instrument parts. - This group can be used to describe the preparation of the instrument prior to the - experiment, e.g. the cleaning procedure for a spin filter crystal. - - - - - - Document an event of data processing, reconstruction, or analysis for this data. - The appropriate axis calibrations for a given experiment should be described using - one or more of the following NXcalibrations. The individual calibrations for a given - `AXISNAME` in `data` should be called `AXISNAME_calibration`. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Kinetic energy values - - - - - - - - Relative transmission efficiency for the given kinetic energies - - - - - - - - - - - - - For samples containing a single pure substance. For mixtures use the - NXsample_component_set and NXsample_component group in NXsample instead. - - - - The chemical formula of the sample (using CIF conventions). - - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - - - - - - - - - - - - - A set of activities that occurred to the sample prior to/during photoemission - experiment. - - - - Details about the sample preparation for the photoemission experiment (e.g. UHV cleaving, - in-situ growth, sputtering/annealing, etc.). - - - - - - Details about the method of sample preparation before the photoemission - experiment. - - - - - - - Sample temperature (either controlled or just measured). - - - - Temperature sensor measuring the sample temperature. - This should be a link to /entry/instrument/manipulator/temperature_sensor. - - - - - Device to heat the sample. - This should be a link to /entry/instrument/manipulator/sample_heater. - - - - - Cryostat for cooling the sample. - This should be a link to /entry/instrument/manipulator/cryostat. - - - - - - Gas pressure surrounding the sample. - - - - Gauge measuring the gas pressure. - - This should be a link to /entry/instrument/pressure_gauge. - - - - - - Bias of the sample with respect to analyser ground. - - This concept is related to term `8.41`_ of the ISO 18115-1:2023 standard. - - .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 - - - - Sensor measuring the applied voltage. - - This should be a link to /entry/instrument/manipulator/sample_bias_voltmeter. - - - - - Actuator applying a voltage to sample and sample holder. - - This should be a link to /entry/instrument/manipulator/sample_bias_potentiostat. - - - - - - Drain current of the sample and sample holder. - - - - Amperemeter measuring the drain current of the sample and sample holder. - - This should be a link to /entry/instrument/manipulator/drain_current_amperemeter. - - - - - - Current of low-energy electrons to the sample for charge neutralization. - - - - Flood gun creating a current of low-energy electrons. - - This should be a link to /entry/instrument/flood_gun. - - - - - - - The default NXdata field containing a view on the measured data. - This NXdata field contains a collection of the main relevant fields (axes). - If you want to provide additional views on your data, you can additionally use - the generic NXdata group of NXentry. - - The naming of fields should follow the convention defined in the - :ref:`NXdata_photoemission` base class: - - - **energy**: Calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). - - **momentum**: Calibrated momentum axis. Unit category: NX_ANY (e.g., kg*m/s). - - **kx**: Calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). - - **ky**: Calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). - - **kz**: Calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). - - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). - Unit category: NX_ANGLE - - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - Unit category: NX_ANGLE - - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) - Unit category: NX_LENGTH - - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - Unit category: NX_LENGTH - - **delay**: Calibrated delay time. Unit category: NX_TIME (s). - - **polarization_angle**: Linear polarization angle of the incoming or - outgoing beam. This could be a link to - /entry/instrument/beam/incident_polarization_angle or - /entry/instrument/beam/final_polarization_angle if they exist. - Unit category: NX_ANGLE (° or rad) - - **ellipticity**: Ellipticity of the incoming or outgoing beam. - Could be a link to /entry/instrument/beam/incident_ellipticity or - /entry/instrument/beam/final_ellipticity if they exist. - Unit category: NX_ANGLE (° or rad) - - - - - - - - - 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. - - - - - The energy can be dispersed according to different strategies. ``energy_depends`` points to - the path of a field defining the calibrated axis on which the energy axis depends. - - For example: - @energy_depends: 'entry/process/energy_calibration' - - - - - diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 7e8ae5042f..9614c472a7 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -1,7 +1,7 @@ category: application doc: | - This is the most general application definition for multidimensional - photoelectron spectroscopy. + This is the most general application definition for + photoemission experiments. Groups and fields are named according to the `ISO 18115-1:2023`_ specification as well as the `IUPAC Recommendations 2020`_. @@ -9,25 +9,688 @@ doc: | .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 type: group -NXmpes(NXphotoemission): +NXmpes(NXobject): (NXentry): definition: + \@version: enumeration: [NXmpes] + title: + start_time(NX_DATE_TIME): + doc: | + Datetime of the start of the measurement. + Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, + otherwise the local time zone is assumed per ISO8601. + end_time(NX_DATE_TIME): + exists: recommended + doc: | + Datetime of the end of the measurement. + Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, + otherwise the local time zone is assumed per ISO8601. + method: + exists: recommended + doc: | + Name of the experimental method. + + If applicable, this name should match the terms given by `Clause 11`_ of + the `ISO 18115-1:2023`_ specification. + + Examples include: + * X-ray photoelectron spectroscopy (XPS) + * angle-resolved X-ray photoelectron spectroscopy (ARXPS) + * ultraviolet photoelectron spectroscopy (UPS) + * angle-resolved photoelectron spectroscopy (ARPES) + * hard X-ray photoemission spectroscopy (HAXPES) + * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) + * photoelectron emission microscopy (PEEM) + * electron spectroscopy for chemical analysis (ESCA) + * time-resolved angle-resolved X-ray photoelectron spectroscopy (trARPES) + * spin-resolved angle-resolved X-ray photoelectron spectroscopy (spin-ARPES) + * momentum microscopy + + .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 + geometries(NXcoordinate_system_set): + doc: | + Description of one or more coordinate systems that are specific to the setup + and the measurement geometry. + (NXuser): + exists: recommended + doc: | + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. + name: + doc: | + Name of the user. + affiliation: + doc: | + Name of the affiliation of the user at the time when the experiment was + performed. (NXinstrument): + doc: + - | + Description of the photoemission spectrometer and its individual parts. + - | + xref: + spec: ISO 18115-1:2023 + term: 12.58 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 + device_information(NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended energy_resolution(NXresolution): + exists: optional + doc: | + Overall energy resolution of the photoemission instrument. + physical_quantity: + enumeration: [energy] + type: + exists: recommended + resolution(NX_FLOAT): + unit: NX_ENERGY + doc: + - | + Minimum distinguishable energy separation in the energy spectra. + - | + xref: + spec: ISO 18115-1:2023 + term: 10.24 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 + resolution_errors(NX_FLOAT): + exists: optional + unit: NX_ENERGY + relative_resolution(NX_FLOAT): + exists: optional + doc: + - | + Ratio of the energy resolution of the photoemission spectrometer at a specified energy + value to that energy value. + - | + xref: + spec: ISO 18115-1:2023 + term: 10.7 ff. + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 + sourceTYPE(NXsource): exists: recommended doc: | - Overall energy resolution of the MPES instrument. + A source used to generate a beam. Properties refer strictly to parameters of the + source, not of the output beam. For example, the energy of the source is not the + optical power of the beam, but the energy of the electron beam in a synchrotron + or similar. + + Note that the uppercase notation in sourceTYPE means that multiple sources can + be provided. For example, in pump-probe experiments, it is possible to have both + a `source_probe` and a `source_pump` + type: + enumeration: [Synchrotron X-ray Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, UV Plasma Source, Metal Jet X-ray, HHG laser, UV lamp, Monochromatized electron source, other] + type_other: + exists: optional + doc: | + Specification of type, may also go to name. + name: + exists: recommended + probe: + exists: optional + device_information(NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + associated_beam(NXbeam): + doc: | + The beam emitted by this source. + Should be named with the same appendix, e.g., + for `source_probe` it should refer to `beam_probe`. + Refers to the same concept as /NXentry/NXinstrument/beamTYPE + and may be linked. + beamTYPE(NXbeam): + doc: | + Properties of the photon beam at a given location. + Should be named with the same appendix as sourceTYPE, e.g., + for `source_probe` it should refer to `beam_probe`. + distance(NX_NUMBER): + unit: NX_LENGTH + exists: recommended + doc: | + Distance between the point where the current NXbeam instance is evaluating + the beam properties and the point where the beam interacts with the sample. + For photoemission, the latter is the point where the the centre of the beam + touches the sample surface. + incident_energy(NX_FLOAT): + unit: NX_ENERGY + incident_energy_spread(NX_NUMBER): + exists: recommended + unit: NX_ENERGY + incident_polarization(NX_NUMBER): + exists: recommended + unit: NX_ANY + extent(NX_FLOAT): + exists: recommended + associated_source(NXsource): + exists: recommended + doc: | + The source that emitted this beam. + Should be named with the same appendix, e.g., + for `beam_probe` it should refer to `source_probe`. + Refers to the same concept as /NXentry/NXinstrument/sourceTYPE + and may be linked. + Should be specified if an associated source exists. (NXelectronanalyser): + device_information(NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + description: energy_resolution(NXresolution): + exists: optional + type: + exists: recommended + physical_quantity: + enumeration: [energy] + resolution(NX_FLOAT): + work_function(NX_FLOAT): + unit: NX_ENERGY + exists: recommended + fast_axes: + exists: recommended + slow_axes: + exists: recommended + transmission_function(NXdata): + exists: optional + (NXcollectioncolumn): + scheme: + doc: | + Scheme of the electron collection column. + enumeration: [angular dispersive, spatial dispersive, momentum dispersive, non-dispersive] + lens_mode: + exists: recommended + projection: + exists: recommended + angular_acceptance(NX_FLOAT): + exists: optional + spatial_acceptance(NX_FLOAT): + exists: optional + field_aperture(NXaperture): + exists: optional + doc: | + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + contrast_aperture(NXaperture): + exists: optional + doc: | + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. + iris(NXaperture): + exists: optional + doc: | + Size, position and shape of the iris inserted in the column. + + The iris is an aperture in the lens with a variable diameter which can reduce the number of + electrons entering the analyzer. + + To add additional or other slits use the APERTURE group of NXcollectioncolumn. + device_information(NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + (NXenergydispersion): + scheme: + enumeration: [tof, hemispherical, double hemispherical, cylindrical mirror, display mirror, retarding grid] + pass_energy(NX_FLOAT): + exists: recommended + unit: NX_ENERGY + doc: | + Either `pass_energy` or `drift_energy` must be supplied. `pass_energy` should be used when working + with hemispherical analysers. + drift_energy(NX_FLOAT): + exists: recommended + unit: NX_ENERGY + doc: | + Either `pass_energy` or `drift_energy` must be supplied. `drift_energy` should be used if a TOF is used in the + energy dispersive part of the electron analyzer. + energy_scan_mode: + exists: recommended + entrance_slit(NXaperture): + exists: optional + doc: | + Size, position and shape of the entrance slit in dispersive analyzers. + + To add additional or other slits use the APERTURE group of NXenergydispersion. + exit_slit(NXaperture): + exists: optional + doc: | + Size, position and shape of the exit slit in dispersive analyzers. + + To add additional or other slits use the APERTURE group of NXenergydispersion. + device_information(NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + (NXdetector): + amplifier_type: + exists: recommended + doc: | + Type of electron amplifier in the first amplification step. + enumeration: [MCP, channeltron] + detector_type: + exists: recommended + doc: | + Description of the detector type. + enumeration: [DLD, Phosphor+CCD, Phosphor+CMOS, ECMOS, Anode, Multi-anode] + device_information(NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + raw_data(NXdata_mpes_detector): + exists: recommended + doc: | + Contains the raw data collected by the detector before calibration. + The data which is considered raw might change from experiment to experiment + due to hardware pre-processing of the data. + This field ideally collects the data with the lowest level of processing + possible. + + The naming of fields should follow the convention defined in the + :ref:`NXdata_mpes_detector` base class: + + - **pixel_x**: Detector pixel in x direction. + - **pixel_y**: Detector pixel in y direction. + - **energy**: (Un)calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). + - **momentum**: Calibrated momentum axis. Unit category: NX_ANY (e.g., kg*m/s). + - **kx**: (Un)calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). + - **ky**: (Un)calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). + - **kz**: (Un)calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). + - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). + Unit category: NX_ANGLE + - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) + Unit category: NX_ANGLE + - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) + Unit category: NX_LENGTH + - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) + Unit category: NX_LENGTH + - **delay**: Calibrated delay time. Unit category: NX_TIME (s). + - **polarization_angle**: Linear polarization angle of the incoming or + outgoing beam. + Unit category: NX_ANGLE (° or rad) + - **ellipticity**: Ellipticity of the incoming or outgoing beam. + Unit category: NX_ANGLE (° or rad) + - **time_of_flight**: Total time of flight. Unit category: NX_TIME_OF_FLIGHT + - **time_of_flight_adc**: Time-of-flight values, analog-to-digital converted. + - **external_AXIS**: Describes an axis which is coming from outside the detectors scope. + \@signal: + enumeration: [raw] + raw(NX_NUMBER): + doc: | + Raw data before calibration. + (NXmanipulator): + exists: optional + doc: | + Manipulator for positioning of the sample. + temperature_sensor(NXsensor): exists: recommended - (NXprocess): + name: + exists: recommended + measurement: + enumeration: [temperature] + type: + exists: optional + value(NX_FLOAT): + sample_heater(NXactuator): + exists: optional + name: + exists: recommended + physical_quantity: + enumeration: [temperature] + type: + exists: optional + heater_power(NX_FLOAT): + (NXpid): + exists: recommended + setpoint(NX_FLOAT): + exists: recommended + cryostat(NXactuator): + exists: optional + name: + exists: recommended + physical_quantity: + enumeration: [temperature] + type: + exists: optional + (NXpid): + setpoint(NX_FLOAT): + exists: recommended + drain_current_amperemeter(NXsensor): + exists: optional + name: + exists: recommended + measurement: + enumeration: [current] + type: + exists: optional + value(NX_FLOAT): + sample_bias_voltmeter(NXsensor): + exists: recommended + name: + exists: recommended + measurement: + enumeration: [voltage] + type: + exists: optional + value(NX_FLOAT): + sample_bias_potentiostat(NXactuator): + exists: recommended + name: + exists: recommended + physical_quantity: + enumeration: [voltage] + type: + exists: optional + (NXpid): + exists: recommended + setpoint(NX_FLOAT): + exists: recommended + device_information(NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + pressure_gauge(NXsensor): + exists: recommended + doc: | + Device to measure the gas pressure around the sample. + name: + exists: recommended + measurement: + enumeration: [pressure] + type: + exists: optional + value(NX_FLOAT): + unit: NX_PRESSURE + doc: | + In case of a single or averaged gas pressure measurement, this is the scalar gas pressure around + the sample. It can also be an 1D array of measured pressures (without time stamps). + value_log(NXlog): + exists: optional + value(NX_NUMBER): + unit: NX_PRESSURE + doc: | + In the case of an experiment in which the gas pressure changes and is recorded, + this is an array of length m of gas pressures. + flood_gun(NXactuator): + exists: optional + doc: | + Device to bring low-energy electrons to the sample for charge neutralization + name: + exists: recommended + physical_quantity: + enumeration: [current] + type: + exists: optional + current(NX_FLOAT): + exists: recommended + unit: NX_CURRENT + doc: | + In case of a fixed or averaged electron current, this is the scalar current. + It can also be an 1D array of output current (without time stamps). + current_log(NXlog): + exists: optional + value(NX_NUMBER): + unit: NX_CURRENT + doc: | + In the case of an experiment in which the electron current is changed and + recorded with time stamps, this is an array of length m of current setpoints. + history(NXhistory): + exists: optional + doc: | + A set of activities that occurred to the instrument prior to/during the photoemission + experiment, including any activities performed on the individual instrument parts. + This group can be used to describe the preparation of the instrument prior to the + experiment, e.g. the cleaning procedure for a spin filter crystal. + (NXprocess_mpes): + exists: recommended + doc: | + Document an event of data processing, reconstruction, or analysis for this data. + The appropriate axis calibrations for a given experiment should be described using + one or more of the following NXcalibrations. The individual calibrations for a given + `AXISNAME` in `data` should be called `AXISNAME_calibration`. energy_calibration(NXcalibration): + exists: optional + calibrated_axis(NX_FLOAT): + exists: recommended + momentum_calibration(NXcalibration): + exists: optional + calibrated_axis(NX_FLOAT): + exists: recommended + kK_calibration(NXcalibration): + exists: optional + calibrated_axis(NX_FLOAT): + exists: recommended + angularANGLE_calibration(NXcalibration): + exists: optional + calibrated_axis(NX_FLOAT): + exists: recommended + spatialSPATIAL_calibration(NXcalibration): + exists: optional + calibrated_axis(NX_FLOAT): + exists: recommended + delay_calibration(NXcalibration): + exists: optional + calibrated_axis(NX_FLOAT): + exists: recommended + polarization_angle_calibration(NXcalibration): + exists: optional + calibrated_axis(NX_FLOAT): + exists: recommended + ellipticity_calibration(NXcalibration): + exists: optional + calibrated_axis(NX_FLOAT): + exists: recommended + energy_referencing(NXcalibration): + exists: optional + level(NXelectron_level): + exists: recommended + reference_peak: + binding_energy(NX_FLOAT): + exists: recommended + offset(NX_FLOAT): + exists: recommended + calibrated_axis(NX_FLOAT): + exists: recommended + transmission_correction(NXcalibration): + exists: optional + transmission_function(NXdata): + exists: recommended + \@signal: + \@axes: + kinetic_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + Kinetic energy values + dimensions: + rank: 1 + dim: [[1, n_transmission_function]] + relative_intensity(NX_FLOAT): + unit: NX_UNITLESS + doc: | + Relative transmission efficiency for the given kinetic energies + dimensions: + rank: 1 + dim: [[1, n_transmission_function]] + (NXsample): + name: + (NXsubstance): exists: recommended - data(NXdata): - energy(NX_NUMBER): - unit: NX_ENERGY + doc: | + For samples containing a single pure substance. For mixtures use the + NXsample_component_set and NXsample_component group in NXsample instead. + molecular_formula_hill: + exists: recommended + doc: | + The chemical formula of the sample (using CIF conventions). + atom_types: + exists: recommended + 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`. + physical_form: + exists: recommended + situation: + exists: recommended + enumeration: [vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere] + history(NXhistory): + exists: recommended + doc: | + A set of activities that occurred to the sample prior to/during photoemission + experiment. + sample_preparation(NXphysical_process): + exists: recommended + doc: | + Details about the sample preparation for the photoemission experiment (e.g. UHV cleaving, + in-situ growth, sputtering/annealing, etc.). + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + exists: recommended + method: + exists: recommended + doc: | + Details about the method of sample preparation before the photoemission + experiment. + temperature(NXenvironment): + exists: recommended + doc: | + Sample temperature (either controlled or just measured). + temperature_sensor(NXsensor): + doc: | + Temperature sensor measuring the sample temperature. + This should be a link to /entry/instrument/manipulator/temperature_sensor. + sample_heater(NXactuator): + exists: optional + doc: | + Device to heat the sample. + This should be a link to /entry/instrument/manipulator/sample_heater. + cryostat(NXactuator): + exists: optional + doc: | + Cryostat for cooling the sample. + This should be a link to /entry/instrument/manipulator/cryostat. + gas_pressure(NXenvironment): + exists: recommended + doc: | + Gas pressure surrounding the sample. + pressure_gauge(NXsensor): + doc: | + Gauge measuring the gas pressure. + + This should be a link to /entry/instrument/pressure_gauge. + bias(NXenvironment): + exists: recommended + doc: + - | + Bias of the sample with respect to analyser ground. + - | + xref: + spec: ISO 18115-1:2023 + term: 8.41 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 + voltmeter(NXsensor): + doc: | + Sensor measuring the applied voltage. + + This should be a link to /entry/instrument/manipulator/sample_bias_voltmeter. + potentiostat(NXactuator): + exists: optional + doc: | + Actuator applying a voltage to sample and sample holder. + + This should be a link to /entry/instrument/manipulator/sample_bias_potentiostat. + drain_current(NXenvironment): + exists: optional + doc: | + Drain current of the sample and sample holder. + amperemeter(NXsensor): + doc: | + Amperemeter measuring the drain current of the sample and sample holder. + + This should be a link to /entry/instrument/manipulator/drain_current_amperemeter. + flood_gun_current(NXenvironment): exists: optional + doc: | + Current of low-energy electrons to the sample for charge neutralization. + flood_gun(NXactuator): + doc: | + Flood gun creating a current of low-energy electrons. + + This should be a link to /entry/instrument/flood_gun. + data(NXdata_mpes): + doc: | + The default NXdata field containing a view on the measured data. + This NXdata field contains a collection of the main relevant fields (axes). + If you want to provide additional views on your data, you can additionally use + the generic NXdata group of NXentry. + + The naming of fields should follow the convention defined in the + :ref:`NXdata_mpes` base class: + + - **energy**: Calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). + - **momentum**: Calibrated momentum axis. Unit category: NX_ANY (e.g., kg*m/s). + - **kx**: Calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). + - **ky**: Calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). + - **kz**: Calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). + - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). + Unit category: NX_ANGLE + - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) + Unit category: NX_ANGLE + - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) + Unit category: NX_LENGTH + - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) + Unit category: NX_LENGTH + - **delay**: Calibrated delay time. Unit category: NX_TIME (s). + - **polarization_angle**: Linear polarization angle of the incoming or + outgoing beam. This could be a link to + /entry/instrument/beam/incident_polarization_angle or + /entry/instrument/beam/final_polarization_angle if they exist. + Unit category: NX_ANGLE (° or rad) + - **ellipticity**: Ellipticity of the incoming or outgoing beam. + Could be a link to /entry/instrument/beam/incident_ellipticity or + /entry/instrument/beam/final_ellipticity if they exist. + Unit category: NX_ANGLE (° or rad) + \@signal: + enumeration: [data] + data(NX_NUMBER): + unit: NX_ANY + doc: | + 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. + energy(NX_NUMBER): doc: | Calibrated energy axis. @@ -35,34 +698,7 @@ NXmpes(NXphotoemission): /entry/process/energy_calibration/calibrated_axis or /entry/process/energy_correction/calibrated_axis. \@type: - type: NX_CHAR - doc: | - The energy can be either stored as kinetic or as binding energy. - enumeration: - kinetic: - doc: - - | - Calibrated kinetic energy axis. - - | - In case the kinetic energy axis is referenced to the Fermi level :math:`E_F` - (e.g., in entry/process/energy_referencing), kinetic energies :math:`E` are - provided as :math:`E-E_F`. - - | - xref: - spec: ISO 18115-1:2023 - term: 3.35 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 - binding: - doc: - - | - Calibrated binding energy axis. - - | - xref: - spec: ISO 18115-1:2023 - term: 12.16 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - \@energy_indices: - exists: optional + exists: recommended \@energy_depends: type: NX_CHAR exists: optional @@ -74,7 +710,7 @@ NXmpes(NXphotoemission): @energy_depends: 'entry/process/energy_calibration' # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# b6a9c38c1506de6011a35e1e891b419e8cf2820882c7eeed77ce4ab187344b54 +# 9092a8da392c0e68b6936a9670c405812e0efff35411bc0cdf645246acb796df # # # -# +# # -# This is the most general application definition for multidimensional -# photoelectron spectroscopy. +# This is the most general application definition for +# photoemission experiments. # # Groups and fields are named according to the # `ISO 18115-1:2023`_ specification as well as the `IUPAC Recommendations 2020`_. @@ -111,25 +747,760 @@ NXmpes(NXphotoemission): # # # +# # # # # +# +# +# +# Datetime of the start of the measurement. +# Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, +# otherwise the local time zone is assumed per ISO8601. +# +# +# +# +# Datetime of the end of the measurement. +# Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, +# otherwise the local time zone is assumed per ISO8601. +# +# +# +# +# Name of the experimental method. +# +# If applicable, this name should match the terms given by `Clause 11`_ of +# the `ISO 18115-1:2023`_ specification. +# +# Examples include: +# * X-ray photoelectron spectroscopy (XPS) +# * angle-resolved X-ray photoelectron spectroscopy (ARXPS) +# * ultraviolet photoelectron spectroscopy (UPS) +# * angle-resolved photoelectron spectroscopy (ARPES) +# * hard X-ray photoemission spectroscopy (HAXPES) +# * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) +# * photoelectron emission microscopy (PEEM) +# * electron spectroscopy for chemical analysis (ESCA) +# * time-resolved angle-resolved X-ray photoelectron spectroscopy (trARPES) +# * spin-resolved angle-resolved X-ray photoelectron spectroscopy (spin-ARPES) +# * momentum microscopy +# +# .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html +# .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 +# +# +# +# +# Description of one or more coordinate systems that are specific to the setup +# and the measurement geometry. +# +# +# +# +# Contact information of at least the user of the instrument or the investigator +# who performed this experiment. Adding multiple users if relevant is recommended. +# +# +# +# Name of the user. +# +# +# +# +# Name of the affiliation of the user at the time when the experiment was +# performed. +# +# +# # -# +# +# Description of the photoemission spectrometer and its individual parts. +# +# This concept is related to term `12.58`_ of the ISO 18115-1:2023 standard. +# +# .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 +# +# +# +# +# +# +# +# +# Overall energy resolution of the photoemission instrument. +# +# +# +# +# +# +# +# +# +# Minimum distinguishable energy separation in the energy spectra. +# +# This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. +# +# .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 +# +# +# +# +# +# Ratio of the energy resolution of the photoemission spectrometer at a specified energy +# value to that energy value. +# +# This concept is related to term `10.7 ff.`_ of the ISO 18115-1:2023 standard. +# +# .. _10.7 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 +# +# +# +# +# +# A source used to generate a beam. Properties refer strictly to parameters of the +# source, not of the output beam. For example, the energy of the source is not the +# optical power of the beam, but the energy of the electron beam in a synchrotron +# or similar. +# +# Note that the uppercase notation in sourceTYPE means that multiple sources can +# be provided. For example, in pump-probe experiments, it is possible to have both +# a `source_probe` and a `source_pump` +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Specification of type, may also go to name. +# +# +# +# +# +# +# +# +# +# +# +# The beam emitted by this source. +# Should be named with the same appendix, e.g., +# for `source_probe` it should refer to `beam_probe`. +# Refers to the same concept as /NXentry/NXinstrument/beamTYPE +# and may be linked. +# +# +# +# # -# Overall energy resolution of the MPES instrument. +# Properties of the photon beam at a given location. +# Should be named with the same appendix as sourceTYPE, e.g., +# for `source_probe` it should refer to `beam_probe`. # +# +# +# Distance between the point where the current NXbeam instance is evaluating +# the beam properties and the point where the beam interacts with the sample. +# For photoemission, the latter is the point where the the centre of the beam +# touches the sample surface. +# +# +# +# +# +# +# +# +# The source that emitted this beam. +# Should be named with the same appendix, e.g., +# for `beam_probe` it should refer to `source_probe`. +# Refers to the same concept as /NXentry/NXinstrument/sourceTYPE +# and may be linked. +# Should be specified if an associated source exists. +# +# # # -# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Scheme of the electron collection column. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The size and position of the field aperture inserted in the column. To add +# additional or other apertures use the APERTURE group of NXcollectioncolumn. +# +# +# +# +# The size and position of the contrast aperture inserted in the column. To add +# additional or other apertures use the APERTURE group of NXcollectioncolumn. +# +# +# +# +# Size, position and shape of the iris inserted in the column. +# +# The iris is an aperture in the lens with a variable diameter which can reduce the number of +# electrons entering the analyzer. +# +# To add additional or other slits use the APERTURE group of NXcollectioncolumn. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Either `pass_energy` or `drift_energy` must be supplied. `pass_energy` should be used when working +# with hemispherical analysers. +# +# +# +# +# Either `pass_energy` or `drift_energy` must be supplied. `drift_energy` should be used if a TOF is used in the +# energy dispersive part of the electron analyzer. +# +# +# +# +# +# Size, position and shape of the entrance slit in dispersive analyzers. +# +# To add additional or other slits use the APERTURE group of NXenergydispersion. +# +# +# +# +# Size, position and shape of the exit slit in dispersive analyzers. +# +# To add additional or other slits use the APERTURE group of NXenergydispersion. +# +# +# +# +# +# +# +# +# +# +# +# Type of electron amplifier in the first amplification step. +# +# +# +# +# +# +# +# +# Description of the detector type. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Contains the raw data collected by the detector before calibration. +# The data which is considered raw might change from experiment to experiment +# due to hardware pre-processing of the data. +# This field ideally collects the data with the lowest level of processing +# possible. +# +# The naming of fields should follow the convention defined in the +# :ref:`NXdata_mpes_detector` base class: +# +# - **pixel_x**: Detector pixel in x direction. +# - **pixel_y**: Detector pixel in y direction. +# - **energy**: (Un)calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). +# - **momentum**: Calibrated momentum axis. Unit category: NX_ANY (e.g., kg*m/s). +# - **kx**: (Un)calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). +# - **ky**: (Un)calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). +# - **kz**: (Un)calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). +# - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). +# Unit category: NX_ANGLE +# - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) +# Unit category: NX_ANGLE +# - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) +# Unit category: NX_LENGTH +# - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) +# Unit category: NX_LENGTH +# - **delay**: Calibrated delay time. Unit category: NX_TIME (s). +# - **polarization_angle**: Linear polarization angle of the incoming or +# outgoing beam. +# Unit category: NX_ANGLE (° or rad) +# - **ellipticity**: Ellipticity of the incoming or outgoing beam. +# Unit category: NX_ANGLE (° or rad) +# - **time_of_flight**: Total time of flight. Unit category: NX_TIME_OF_FLIGHT +# - **time_of_flight_adc**: Time-of-flight values, analog-to-digital converted. +# - **external_AXIS**: Describes an axis which is coming from outside the detectors scope. +# +# +# +# +# +# +# +# +# Raw data before calibration. +# +# +# +# +# +# +# +# Manipulator for positioning of the sample. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Device to measure the gas pressure around the sample. +# +# +# +# +# +# +# +# +# +# +# In case of a single or averaged gas pressure measurement, this is the scalar gas pressure around +# the sample. It can also be an 1D array of measured pressures (without time stamps). +# +# +# +# +# +# In the case of an experiment in which the gas pressure changes and is recorded, +# this is an array of length m of gas pressures. +# +# +# +# +# +# +# Device to bring low-energy electrons to the sample for charge neutralization +# +# +# +# +# +# +# +# +# +# +# In case of a fixed or averaged electron current, this is the scalar current. +# It can also be an 1D array of output current (without time stamps). +# +# +# +# +# +# In the case of an experiment in which the electron current is changed and +# recorded with time stamps, this is an array of length m of current setpoints. +# +# +# +# +# +# +# A set of activities that occurred to the instrument prior to/during the photoemission +# experiment, including any activities performed on the individual instrument parts. +# This group can be used to describe the preparation of the instrument prior to the +# experiment, e.g. the cleaning procedure for a spin filter crystal. +# # # -# -# +# +# +# Document an event of data processing, reconstruction, or analysis for this data. +# The appropriate axis calibrations for a given experiment should be described using +# one or more of the following NXcalibrations. The individual calibrations for a given +# `AXISNAME` in `data` should be called `AXISNAME_calibration`. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Kinetic energy values +# +# +# +# +# +# +# +# Relative transmission efficiency for the given kinetic energies +# +# +# +# +# +# +# +# +# +# +# +# +# For samples containing a single pure substance. For mixtures use the +# NXsample_component_set and NXsample_component group in NXsample instead. +# +# +# +# The chemical formula of the sample (using CIF conventions). +# +# +# +# +# +# List of comma-separated elements from the periodic table +# that are contained in the sample. +# If the sample substance has multiple components, all +# elements from each component must be included in `atom_types`. +# +# +# +# +# +# +# +# +# +# +# +# +# +# A set of activities that occurred to the sample prior to/during photoemission +# experiment. +# +# +# +# Details about the sample preparation for the photoemission experiment (e.g. UHV cleaving, +# in-situ growth, sputtering/annealing, etc.). +# +# +# +# +# +# Details about the method of sample preparation before the photoemission +# experiment. +# +# +# +# +# +# +# Sample temperature (either controlled or just measured). +# +# +# +# Temperature sensor measuring the sample temperature. +# This should be a link to /entry/instrument/manipulator/temperature_sensor. +# +# +# +# +# Device to heat the sample. +# This should be a link to /entry/instrument/manipulator/sample_heater. +# +# +# +# +# Cryostat for cooling the sample. +# This should be a link to /entry/instrument/manipulator/cryostat. +# +# +# +# +# +# Gas pressure surrounding the sample. +# +# +# +# Gauge measuring the gas pressure. +# +# This should be a link to /entry/instrument/pressure_gauge. +# +# +# +# +# +# Bias of the sample with respect to analyser ground. +# +# This concept is related to term `8.41`_ of the ISO 18115-1:2023 standard. +# +# .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 +# +# +# +# Sensor measuring the applied voltage. +# +# This should be a link to /entry/instrument/manipulator/sample_bias_voltmeter. +# +# +# +# +# Actuator applying a voltage to sample and sample holder. +# +# This should be a link to /entry/instrument/manipulator/sample_bias_potentiostat. +# +# +# +# +# +# Drain current of the sample and sample holder. +# +# +# +# Amperemeter measuring the drain current of the sample and sample holder. +# +# This should be a link to /entry/instrument/manipulator/drain_current_amperemeter. +# +# +# +# +# +# Current of low-energy electrons to the sample for charge neutralization. +# +# +# +# Flood gun creating a current of low-energy electrons. +# +# This should be a link to /entry/instrument/flood_gun. +# +# +# # -# -# +# +# +# The default NXdata field containing a view on the measured data. +# This NXdata field contains a collection of the main relevant fields (axes). +# If you want to provide additional views on your data, you can additionally use +# the generic NXdata group of NXentry. +# +# The naming of fields should follow the convention defined in the +# :ref:`NXdata_mpes` base class: +# +# - **energy**: Calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). +# - **momentum**: Calibrated momentum axis. Unit category: NX_ANY (e.g., kg*m/s). +# - **kx**: Calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). +# - **ky**: Calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). +# - **kz**: Calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). +# - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). +# Unit category: NX_ANGLE +# - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) +# Unit category: NX_ANGLE +# - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) +# Unit category: NX_LENGTH +# - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) +# Unit category: NX_LENGTH +# - **delay**: Calibrated delay time. Unit category: NX_TIME (s). +# - **polarization_angle**: Linear polarization angle of the incoming or +# outgoing beam. This could be a link to +# /entry/instrument/beam/incident_polarization_angle or +# /entry/instrument/beam/final_polarization_angle if they exist. +# Unit category: NX_ANGLE (° or rad) +# - **ellipticity**: Ellipticity of the incoming or outgoing beam. +# Could be a link to /entry/instrument/beam/incident_ellipticity or +# /entry/instrument/beam/final_ellipticity if they exist. +# Unit category: NX_ANGLE (° or rad) +# +# +# +# +# +# +# +# +# Represents a measure of one- or more-dimensional photoemission counts, where the +# varied axis may be for example energy, momentum, spatial coordinate, pump-probe +# delay, spin index, temperature, etc. The axes traces should be linked to the +# actual encoder position in NXinstrument or calibrated axes in NXprocess. +# +# +# # # Calibrated energy axis. # @@ -137,37 +1508,8 @@ NXmpes(NXphotoemission): # /entry/process/energy_calibration/calibrated_axis or # /entry/process/energy_correction/calibrated_axis. # -# -# -# The energy can be either stored as kinetic or as binding energy. -# -# -# -# -# Calibrated kinetic energy axis. -# -# In case the kinetic energy axis is referenced to the Fermi level :math:`E_F` -# (e.g., in entry/process/energy_referencing), kinetic energies :math:`E` are -# provided as :math:`E-E_F`. -# -# This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. -# -# .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 -# -# -# -# -# Calibrated binding energy axis. -# -# This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. -# -# .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 -# -# -# -# +# # -# # # # The energy can be dispersed according to different strategies. ``energy_depends`` points to diff --git a/contributed_definitions/nyaml/NXphotoemission.yaml b/contributed_definitions/nyaml/NXphotoemission.yaml deleted file mode 100644 index ced7a0f06b..0000000000 --- a/contributed_definitions/nyaml/NXphotoemission.yaml +++ /dev/null @@ -1,1520 +0,0 @@ -category: application -doc: | - This is the most general application definition for - photoemission experiments. - - Groups and fields are named according to the - `ISO 18115-1:2023`_ specification as well as the `IUPAC Recommendations 2020`_. - - .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html - .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays - n_transmission_function: | - Number of data points in the transmission function. -type: group -NXphotoemission(NXobject): - (NXentry): - definition: - \@version: - enumeration: [NXphotoemission] - title: - start_time(NX_DATE_TIME): - doc: | - Datetime of the start of the measurement. - Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, - otherwise the local time zone is assumed per ISO8601. - end_time(NX_DATE_TIME): - exists: recommended - doc: | - Datetime of the end of the measurement. - Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, - otherwise the local time zone is assumed per ISO8601. - method: - exists: recommended - doc: | - Name of the experimental method. - - If applicable, this name should match the terms given by `Clause 11`_ of - the `ISO 18115-1:2023`_ specification. - - Examples include: - * X-ray photoelectron spectroscopy (XPS) - * angle-resolved X-ray photoelectron spectroscopy (ARXPS) - * ultraviolet photoelectron spectroscopy (UPS) - * angle-resolved photoelectron spectroscopy (ARPES) - * hard X-ray photoemission spectroscopy (HAXPES) - * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) - * photoelectron emission microscopy (PEEM) - * electron spectroscopy for chemical analysis (ESCA) - * time-resolved angle-resolved X-ray photoelectron spectroscopy (trARPES) - * spin-resolved angle-resolved X-ray photoelectron spectroscopy (spin-ARPES) - * momentum microscopy - - .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html - .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 - geometries(NXcoordinate_system_set): - doc: | - Description of one or more coordinate systems that are specific to the setup - and the measurement geometry. - (NXuser): - exists: recommended - doc: | - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - name: - doc: | - Name of the user. - affiliation: - doc: | - Name of the affiliation of the user at the time when the experiment was - performed. - (NXinstrument): - doc: - - | - Description of the photoemission spectrometer and its individual parts. - - | - xref: - spec: ISO 18115-1:2023 - term: 12.58 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 - device_information(NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - energy_resolution(NXresolution): - exists: optional - doc: | - Overall energy resolution of the photoemission instrument. - physical_quantity: - enumeration: [energy] - type: - exists: recommended - resolution(NX_FLOAT): - unit: NX_ENERGY - doc: - - | - Minimum distinguishable energy separation in the energy spectra. - - | - xref: - spec: ISO 18115-1:2023 - term: 10.24 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 - resolution_errors(NX_FLOAT): - exists: optional - unit: NX_ENERGY - relative_resolution(NX_FLOAT): - exists: optional - doc: - - | - Ratio of the energy resolution of the photoemission spectrometer at a specified energy - value to that energy value. - - | - xref: - spec: ISO 18115-1:2023 - term: 10.7 ff. - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 - sourceTYPE(NXsource): - exists: recommended - doc: | - A source used to generate a beam. Properties refer strictly to parameters of the - source, not of the output beam. For example, the energy of the source is not the - optical power of the beam, but the energy of the electron beam in a synchrotron - or similar. - - Note that the uppercase notation in sourceTYPE means that multiple sources can - be provided. For example, in pump-probe experiments, it is possible to have both - a `source_probe` and a `source_pump` - type: - enumeration: [Synchrotron X-ray Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, UV Plasma Source, Metal Jet X-ray, HHG laser, UV lamp, Monochromatized electron source, other] - type_other: - exists: optional - doc: | - Specification of type, may also go to name. - name: - exists: recommended - probe: - exists: optional - device_information(NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - associated_beam(NXbeam): - doc: | - The beam emitted by this source. - Should be named with the same appendix, e.g., - for `source_probe` it should refer to `beam_probe`. - Refers to the same concept as /NXentry/NXinstrument/beamTYPE - and may be linked. - beamTYPE(NXbeam): - doc: | - Properties of the photon beam at a given location. - Should be named with the same appendix as sourceTYPE, e.g., - for `source_probe` it should refer to `beam_probe`. - distance(NX_NUMBER): - unit: NX_LENGTH - exists: recommended - doc: | - Distance between the point where the current NXbeam instance is evaluating - the beam properties and the point where the beam interacts with the sample. - For photoemission, the latter is the point where the the centre of the beam - touches the sample surface. - incident_energy(NX_FLOAT): - unit: NX_ENERGY - incident_energy_spread(NX_NUMBER): - exists: recommended - unit: NX_ENERGY - incident_polarization(NX_NUMBER): - exists: recommended - unit: NX_ANY - extent(NX_FLOAT): - exists: recommended - associated_source(NXsource): - exists: recommended - doc: | - The source that emitted this beam. - Should be named with the same appendix, e.g., - for `beam_probe` it should refer to `source_probe`. - Refers to the same concept as /NXentry/NXinstrument/sourceTYPE - and may be linked. - Should be specified if an associated source exists. - (NXelectronanalyser): - device_information(NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - description: - energy_resolution(NXresolution): - exists: optional - type: - exists: recommended - physical_quantity: - enumeration: [energy] - resolution(NX_FLOAT): - work_function(NX_FLOAT): - unit: NX_ENERGY - exists: recommended - fast_axes: - exists: recommended - slow_axes: - exists: recommended - transmission_function(NXdata): - exists: optional - (NXcollectioncolumn): - scheme: - doc: | - Scheme of the electron collection column. - enumeration: [angular dispersive, spatial dispersive, momentum dispersive, non-dispersive] - lens_mode: - exists: recommended - projection: - exists: recommended - angular_acceptance(NX_FLOAT): - exists: optional - spatial_acceptance(NX_FLOAT): - exists: optional - field_aperture(NXaperture): - exists: optional - doc: | - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - contrast_aperture(NXaperture): - exists: optional - doc: | - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - iris(NXaperture): - exists: optional - doc: | - Size, position and shape of the iris inserted in the column. - - The iris is an aperture in the lens with a variable diameter which can reduce the number of - electrons entering the analyzer. - - To add additional or other slits use the APERTURE group of NXcollectioncolumn. - device_information(NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - (NXenergydispersion): - scheme: - enumeration: [tof, hemispherical, double hemispherical, cylindrical mirror, display mirror, retarding grid] - pass_energy(NX_FLOAT): - exists: recommended - unit: NX_ENERGY - doc: | - Either `pass_energy` or `drift_energy` must be supplied. `pass_energy` should be used when working - with hemispherical analysers. - drift_energy(NX_FLOAT): - exists: recommended - unit: NX_ENERGY - doc: | - Either `pass_energy` or `drift_energy` must be supplied. `drift_energy` should be used if a TOF is used in the - energy dispersive part of the electron analyzer. - energy_scan_mode: - exists: recommended - entrance_slit(NXaperture): - exists: optional - doc: | - Size, position and shape of the entrance slit in dispersive analyzers. - - To add additional or other slits use the APERTURE group of NXenergydispersion. - exit_slit(NXaperture): - exists: optional - doc: | - Size, position and shape of the exit slit in dispersive analyzers. - - To add additional or other slits use the APERTURE group of NXenergydispersion. - device_information(NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - (NXdetector): - amplifier_type: - exists: recommended - doc: | - Type of electron amplifier in the first amplification step. - enumeration: [MCP, channeltron] - detector_type: - exists: recommended - doc: | - Description of the detector type. - enumeration: [DLD, Phosphor+CCD, Phosphor+CMOS, ECMOS, Anode, Multi-anode] - device_information(NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - raw_data(NXdata_photoemission_detector): - exists: recommended - doc: | - Contains the raw data collected by the detector before calibration. - The data which is considered raw might change from experiment to experiment - due to hardware pre-processing of the data. - This field ideally collects the data with the lowest level of processing - possible. - - The naming of fields should follow the convention defined in the - :ref:`NXdata_photoemission_detector` base class: - - - **pixel_x**: Detector pixel in x direction. - - **pixel_y**: Detector pixel in y direction. - - **energy**: (Un)calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). - - **momentum**: Calibrated momentum axis. Unit category: NX_ANY (e.g., kg*m/s). - - **kx**: (Un)calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). - - **ky**: (Un)calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). - - **kz**: (Un)calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). - - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). - Unit category: NX_ANGLE - - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - Unit category: NX_ANGLE - - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) - Unit category: NX_LENGTH - - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - Unit category: NX_LENGTH - - **delay**: Calibrated delay time. Unit category: NX_TIME (s). - - **polarization_angle**: Linear polarization angle of the incoming or - outgoing beam. - Unit category: NX_ANGLE (° or rad) - - **ellipticity**: Ellipticity of the incoming or outgoing beam. - Unit category: NX_ANGLE (° or rad) - - **time_of_flight**: Total time of flight. Unit category: NX_TIME_OF_FLIGHT - - **time_of_flight_adc**: Time-of-flight values, analog-to-digital converted. - - **external_AXIS**: Describes an axis which is coming from outside the detectors scope. - \@signal: - enumeration: [raw] - raw(NX_NUMBER): - doc: | - Raw data before calibration. - (NXmanipulator): - exists: optional - doc: | - Manipulator for positioning of the sample. - temperature_sensor(NXsensor): - exists: recommended - name: - exists: recommended - measurement: - enumeration: [temperature] - type: - exists: optional - value(NX_FLOAT): - sample_heater(NXactuator): - exists: optional - name: - exists: recommended - physical_quantity: - enumeration: [temperature] - type: - exists: optional - heater_power(NX_FLOAT): - (NXpid): - exists: recommended - setpoint(NX_FLOAT): - exists: recommended - cryostat(NXactuator): - exists: optional - name: - exists: recommended - physical_quantity: - enumeration: [temperature] - type: - exists: optional - (NXpid): - setpoint(NX_FLOAT): - exists: recommended - drain_current_amperemeter(NXsensor): - exists: optional - name: - exists: recommended - measurement: - enumeration: [current] - type: - exists: optional - value(NX_FLOAT): - sample_bias_voltmeter(NXsensor): - exists: recommended - name: - exists: recommended - measurement: - enumeration: [voltage] - type: - exists: optional - value(NX_FLOAT): - sample_bias_potentiostat(NXactuator): - exists: recommended - name: - exists: recommended - physical_quantity: - enumeration: [voltage] - type: - exists: optional - (NXpid): - exists: recommended - setpoint(NX_FLOAT): - exists: recommended - device_information(NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - pressure_gauge(NXsensor): - exists: recommended - doc: | - Device to measure the gas pressure around the sample. - name: - exists: recommended - measurement: - enumeration: [pressure] - type: - exists: optional - value(NX_FLOAT): - unit: NX_PRESSURE - doc: | - In case of a single or averaged gas pressure measurement, this is the scalar gas pressure around - the sample. It can also be an 1D array of measured pressures (without time stamps). - value_log(NXlog): - exists: optional - value(NX_NUMBER): - unit: NX_PRESSURE - doc: | - In the case of an experiment in which the gas pressure changes and is recorded, - this is an array of length m of gas pressures. - flood_gun(NXactuator): - exists: optional - doc: | - Device to bring low-energy electrons to the sample for charge neutralization - name: - exists: recommended - physical_quantity: - enumeration: [current] - type: - exists: optional - current(NX_FLOAT): - exists: recommended - unit: NX_CURRENT - doc: | - In case of a fixed or averaged electron current, this is the scalar current. - It can also be an 1D array of output current (without time stamps). - current_log(NXlog): - exists: optional - value(NX_NUMBER): - unit: NX_CURRENT - doc: | - In the case of an experiment in which the electron current is changed and - recorded with time stamps, this is an array of length m of current setpoints. - history(NXhistory): - exists: optional - doc: | - A set of activities that occurred to the instrument prior to/during the photoemission - experiment, including any activities performed on the individual instrument parts. - This group can be used to describe the preparation of the instrument prior to the - experiment, e.g. the cleaning procedure for a spin filter crystal. - (NXprocess_photoemission): - exists: recommended - doc: | - Document an event of data processing, reconstruction, or analysis for this data. - The appropriate axis calibrations for a given experiment should be described using - one or more of the following NXcalibrations. The individual calibrations for a given - `AXISNAME` in `data` should be called `AXISNAME_calibration`. - energy_calibration(NXcalibration): - exists: optional - calibrated_axis(NX_FLOAT): - exists: recommended - momentum_calibration(NXcalibration): - exists: optional - calibrated_axis(NX_FLOAT): - exists: recommended - kK_calibration(NXcalibration): - exists: optional - calibrated_axis(NX_FLOAT): - exists: recommended - angularANGLE_calibration(NXcalibration): - exists: optional - calibrated_axis(NX_FLOAT): - exists: recommended - spatialSPATIAL_calibration(NXcalibration): - exists: optional - calibrated_axis(NX_FLOAT): - exists: recommended - delay_calibration(NXcalibration): - exists: optional - calibrated_axis(NX_FLOAT): - exists: recommended - polarization_angle_calibration(NXcalibration): - exists: optional - calibrated_axis(NX_FLOAT): - exists: recommended - ellipticity_calibration(NXcalibration): - exists: optional - calibrated_axis(NX_FLOAT): - exists: recommended - energy_referencing(NXcalibration): - exists: optional - level(NXelectron_level): - exists: recommended - reference_peak: - binding_energy(NX_FLOAT): - exists: recommended - offset(NX_FLOAT): - exists: recommended - calibrated_axis(NX_FLOAT): - exists: recommended - transmission_correction(NXcalibration): - exists: optional - transmission_function(NXdata): - exists: recommended - \@signal: - \@axes: - kinetic_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - Kinetic energy values - dimensions: - rank: 1 - dim: (n_transmission_function,) - relative_intensity(NX_FLOAT): - unit: NX_UNITLESS - doc: | - Relative transmission efficiency for the given kinetic energies - dimensions: - rank: 1 - dim: (n_transmission_function,) - (NXsample): - name: - (NXsubstance): - exists: recommended - doc: | - For samples containing a single pure substance. For mixtures use the - NXsample_component_set and NXsample_component group in NXsample instead. - molecular_formula_hill: - exists: recommended - doc: | - The chemical formula of the sample (using CIF conventions). - atom_types: - exists: recommended - 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`. - physical_form: - exists: recommended - situation: - exists: recommended - enumeration: [vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere] - history(NXhistory): - exists: recommended - doc: | - A set of activities that occurred to the sample prior to/during photoemission - experiment. - sample_preparation(NXphysical_process): - exists: recommended - doc: | - Details about the sample preparation for the photoemission experiment (e.g. UHV cleaving, - in-situ growth, sputtering/annealing, etc.). - start_time(NX_DATE_TIME): - end_time(NX_DATE_TIME): - exists: recommended - method: - exists: recommended - doc: | - Details about the method of sample preparation before the photoemission - experiment. - temperature(NXenvironment): - exists: recommended - doc: | - Sample temperature (either controlled or just measured). - temperature_sensor(NXsensor): - doc: | - Temperature sensor measuring the sample temperature. - This should be a link to /entry/instrument/manipulator/temperature_sensor. - sample_heater(NXactuator): - exists: optional - doc: | - Device to heat the sample. - This should be a link to /entry/instrument/manipulator/sample_heater. - cryostat(NXactuator): - exists: optional - doc: | - Cryostat for cooling the sample. - This should be a link to /entry/instrument/manipulator/cryostat. - gas_pressure(NXenvironment): - exists: recommended - doc: | - Gas pressure surrounding the sample. - pressure_gauge(NXsensor): - doc: | - Gauge measuring the gas pressure. - - This should be a link to /entry/instrument/pressure_gauge. - bias(NXenvironment): - exists: recommended - doc: - - | - Bias of the sample with respect to analyser ground. - - | - xref: - spec: ISO 18115-1:2023 - term: 8.41 - url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 - voltmeter(NXsensor): - doc: | - Sensor measuring the applied voltage. - - This should be a link to /entry/instrument/manipulator/sample_bias_voltmeter. - potentiostat(NXactuator): - exists: optional - doc: | - Actuator applying a voltage to sample and sample holder. - - This should be a link to /entry/instrument/manipulator/sample_bias_potentiostat. - drain_current(NXenvironment): - exists: optional - doc: | - Drain current of the sample and sample holder. - amperemeter(NXsensor): - doc: | - Amperemeter measuring the drain current of the sample and sample holder. - - This should be a link to /entry/instrument/manipulator/drain_current_amperemeter. - flood_gun_current(NXenvironment): - exists: optional - doc: | - Current of low-energy electrons to the sample for charge neutralization. - flood_gun(NXactuator): - doc: | - Flood gun creating a current of low-energy electrons. - - This should be a link to /entry/instrument/flood_gun. - data(NXdata_photoemission): - doc: | - The default NXdata field containing a view on the measured data. - This NXdata field contains a collection of the main relevant fields (axes). - If you want to provide additional views on your data, you can additionally use - the generic NXdata group of NXentry. - - The naming of fields should follow the convention defined in the - :ref:`NXdata_photoemission` base class: - - - **energy**: Calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). - - **momentum**: Calibrated momentum axis. Unit category: NX_ANY (e.g., kg*m/s). - - **kx**: Calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). - - **ky**: Calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). - - **kz**: Calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). - - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). - Unit category: NX_ANGLE - - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - Unit category: NX_ANGLE - - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) - Unit category: NX_LENGTH - - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - Unit category: NX_LENGTH - - **delay**: Calibrated delay time. Unit category: NX_TIME (s). - - **polarization_angle**: Linear polarization angle of the incoming or - outgoing beam. This could be a link to - /entry/instrument/beam/incident_polarization_angle or - /entry/instrument/beam/final_polarization_angle if they exist. - Unit category: NX_ANGLE (° or rad) - - **ellipticity**: Ellipticity of the incoming or outgoing beam. - Could be a link to /entry/instrument/beam/incident_ellipticity or - /entry/instrument/beam/final_ellipticity if they exist. - Unit category: NX_ANGLE (° or rad) - \@signal: - enumeration: [data] - data(NX_NUMBER): - unit: NX_ANY - doc: | - 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. - \@energy_depends: - type: NX_CHAR - exists: optional - doc: | - The energy can be dispersed according to different strategies. ``energy_depends`` points to - the path of a field defining the calibrated axis on which the energy axis depends. - - For example: - @energy_depends: 'entry/process/energy_calibration' - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 17fbac435b8cf0ad33a206575986ac5118b6b272740e17cad5b34978ede7ce23 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays -# -# -# -# Number of data points in the transmission function. -# -# -# -# -# This is the most general application definition for -# photoemission experiments. -# -# Groups and fields are named according to the -# `ISO 18115-1:2023`_ specification as well as the `IUPAC Recommendations 2020`_. -# -# .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html -# .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 -# -# -# -# -# -# -# -# -# -# -# -# Datetime of the start of the measurement. -# Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, -# otherwise the local time zone is assumed per ISO8601. -# -# -# -# -# Datetime of the end of the measurement. -# Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, -# otherwise the local time zone is assumed per ISO8601. -# -# -# -# -# Name of the experimental method. -# -# If applicable, this name should match the terms given by `Clause 11`_ of -# the `ISO 18115-1:2023`_ specification. -# -# Examples include: -# * X-ray photoelectron spectroscopy (XPS) -# * angle-resolved X-ray photoelectron spectroscopy (ARXPS) -# * ultraviolet photoelectron spectroscopy (UPS) -# * angle-resolved photoelectron spectroscopy (ARPES) -# * hard X-ray photoemission spectroscopy (HAXPES) -# * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) -# * photoelectron emission microscopy (PEEM) -# * electron spectroscopy for chemical analysis (ESCA) -# * time-resolved angle-resolved X-ray photoelectron spectroscopy (trARPES) -# * spin-resolved angle-resolved X-ray photoelectron spectroscopy (spin-ARPES) -# * momentum microscopy -# -# .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html -# .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 -# -# -# -# -# Description of one or more coordinate systems that are specific to the setup -# and the measurement geometry. -# -# -# -# -# Contact information of at least the user of the instrument or the investigator -# who performed this experiment. Adding multiple users if relevant is recommended. -# -# -# -# Name of the user. -# -# -# -# -# Name of the affiliation of the user at the time when the experiment was -# performed. -# -# -# -# -# -# Description of the photoemission spectrometer and its individual parts. -# -# This concept is related to term `12.58`_ of the ISO 18115-1:2023 standard. -# -# .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 -# -# -# -# -# -# -# -# -# Overall energy resolution of the photoemission instrument. -# -# -# -# -# -# -# -# -# -# Minimum distinguishable energy separation in the energy spectra. -# -# This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. -# -# .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 -# -# -# -# -# -# Ratio of the energy resolution of the photoemission spectrometer at a specified energy -# value to that energy value. -# -# This concept is related to term `10.7 ff.`_ of the ISO 18115-1:2023 standard. -# -# .. _10.7 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 -# -# -# -# -# -# A source used to generate a beam. Properties refer strictly to parameters of the -# source, not of the output beam. For example, the energy of the source is not the -# optical power of the beam, but the energy of the electron beam in a synchrotron -# or similar. -# -# Note that the uppercase notation in sourceTYPE means that multiple sources can -# be provided. For example, in pump-probe experiments, it is possible to have both -# a `source_probe` and a `source_pump` -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Specification of type, may also go to name. -# -# -# -# -# -# -# -# -# -# -# -# The beam emitted by this source. -# Should be named with the same appendix, e.g., -# for `source_probe` it should refer to `beam_probe`. -# Refers to the same concept as /NXentry/NXinstrument/beamTYPE -# and may be linked. -# -# -# -# -# -# Properties of the photon beam at a given location. -# Should be named with the same appendix as sourceTYPE, e.g., -# for `source_probe` it should refer to `beam_probe`. -# -# -# -# Distance between the point where the current NXbeam instance is evaluating -# the beam properties and the point where the beam interacts with the sample. -# For photoemission, the latter is the point where the the centre of the beam -# touches the sample surface. -# -# -# -# -# -# -# -# -# The source that emitted this beam. -# Should be named with the same appendix, e.g., -# for `beam_probe` it should refer to `source_probe`. -# Refers to the same concept as /NXentry/NXinstrument/sourceTYPE -# and may be linked. -# Should be specified if an associated source exists. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Scheme of the electron collection column. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The size and position of the field aperture inserted in the column. To add -# additional or other apertures use the APERTURE group of NXcollectioncolumn. -# -# -# -# -# The size and position of the contrast aperture inserted in the column. To add -# additional or other apertures use the APERTURE group of NXcollectioncolumn. -# -# -# -# -# Size, position and shape of the iris inserted in the column. -# -# The iris is an aperture in the lens with a variable diameter which can reduce the number of -# electrons entering the analyzer. -# -# To add additional or other slits use the APERTURE group of NXcollectioncolumn. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Either `pass_energy` or `drift_energy` must be supplied. `pass_energy` should be used when working -# with hemispherical analysers. -# -# -# -# -# Either `pass_energy` or `drift_energy` must be supplied. `drift_energy` should be used if a TOF is used in the -# energy dispersive part of the electron analyzer. -# -# -# -# -# -# Size, position and shape of the entrance slit in dispersive analyzers. -# -# To add additional or other slits use the APERTURE group of NXenergydispersion. -# -# -# -# -# Size, position and shape of the exit slit in dispersive analyzers. -# -# To add additional or other slits use the APERTURE group of NXenergydispersion. -# -# -# -# -# -# -# -# -# -# -# -# Type of electron amplifier in the first amplification step. -# -# -# -# -# -# -# -# -# Description of the detector type. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Contains the raw data collected by the detector before calibration. -# The data which is considered raw might change from experiment to experiment -# due to hardware pre-processing of the data. -# This field ideally collects the data with the lowest level of processing -# possible. -# -# The naming of fields should follow the convention defined in the -# :ref:`NXdata_photoemission_detector` base class: -# -# - **pixel_x**: Detector pixel in x direction. -# - **pixel_y**: Detector pixel in y direction. -# - **energy**: (Un)calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). -# - **momentum**: Calibrated momentum axis. Unit category: NX_ANY (e.g., kg*m/s). -# - **kx**: (Un)calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). -# - **ky**: (Un)calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). -# - **kz**: (Un)calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). -# - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). -# Unit category: NX_ANGLE -# - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) -# Unit category: NX_ANGLE -# - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) -# Unit category: NX_LENGTH -# - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) -# Unit category: NX_LENGTH -# - **delay**: Calibrated delay time. Unit category: NX_TIME (s). -# - **polarization_angle**: Linear polarization angle of the incoming or -# outgoing beam. -# Unit category: NX_ANGLE (° or rad) -# - **ellipticity**: Ellipticity of the incoming or outgoing beam. -# Unit category: NX_ANGLE (° or rad) -# - **time_of_flight**: Total time of flight. Unit category: NX_TIME_OF_FLIGHT -# - **time_of_flight_adc**: Time-of-flight values, analog-to-digital converted. -# - **external_AXIS**: Describes an axis which is coming from outside the detectors scope. -# -# -# -# -# -# -# -# -# Raw data before calibration. -# -# -# -# -# -# -# -# Manipulator for positioning of the sample. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Device to measure the gas pressure around the sample. -# -# -# -# -# -# -# -# -# -# -# In case of a single or averaged gas pressure measurement, this is the scalar gas pressure around -# the sample. It can also be an 1D array of measured pressures (without time stamps). -# -# -# -# -# -# In the case of an experiment in which the gas pressure changes and is recorded, -# this is an array of length m of gas pressures. -# -# -# -# -# -# -# Device to bring low-energy electrons to the sample for charge neutralization -# -# -# -# -# -# -# -# -# -# -# In case of a fixed or averaged electron current, this is the scalar current. -# It can also be an 1D array of output current (without time stamps). -# -# -# -# -# -# In the case of an experiment in which the electron current is changed and -# recorded with time stamps, this is an array of length m of current setpoints. -# -# -# -# -# -# -# A set of activities that occurred to the instrument prior to/during the photoemission -# experiment, including any activities performed on the individual instrument parts. -# This group can be used to describe the preparation of the instrument prior to the -# experiment, e.g. the cleaning procedure for a spin filter crystal. -# -# -# -# -# -# Document an event of data processing, reconstruction, or analysis for this data. -# The appropriate axis calibrations for a given experiment should be described using -# one or more of the following NXcalibrations. The individual calibrations for a given -# `AXISNAME` in `data` should be called `AXISNAME_calibration`. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Kinetic energy values -# -# -# -# -# -# -# -# Relative transmission efficiency for the given kinetic energies -# -# -# -# -# -# -# -# -# -# -# -# -# For samples containing a single pure substance. For mixtures use the -# NXsample_component_set and NXsample_component group in NXsample instead. -# -# -# -# The chemical formula of the sample (using CIF conventions). -# -# -# -# -# -# List of comma-separated elements from the periodic table -# that are contained in the sample. -# If the sample substance has multiple components, all -# elements from each component must be included in `atom_types`. -# -# -# -# -# -# -# -# -# -# -# -# -# -# A set of activities that occurred to the sample prior to/during photoemission -# experiment. -# -# -# -# Details about the sample preparation for the photoemission experiment (e.g. UHV cleaving, -# in-situ growth, sputtering/annealing, etc.). -# -# -# -# -# -# Details about the method of sample preparation before the photoemission -# experiment. -# -# -# -# -# -# -# Sample temperature (either controlled or just measured). -# -# -# -# Temperature sensor measuring the sample temperature. -# This should be a link to /entry/instrument/manipulator/temperature_sensor. -# -# -# -# -# Device to heat the sample. -# This should be a link to /entry/instrument/manipulator/sample_heater. -# -# -# -# -# Cryostat for cooling the sample. -# This should be a link to /entry/instrument/manipulator/cryostat. -# -# -# -# -# -# Gas pressure surrounding the sample. -# -# -# -# Gauge measuring the gas pressure. -# -# This should be a link to /entry/instrument/pressure_gauge. -# -# -# -# -# -# Bias of the sample with respect to analyser ground. -# -# This concept is related to term `8.41`_ of the ISO 18115-1:2023 standard. -# -# .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 -# -# -# -# Sensor measuring the applied voltage. -# -# This should be a link to /entry/instrument/manipulator/sample_bias_voltmeter. -# -# -# -# -# Actuator applying a voltage to sample and sample holder. -# -# This should be a link to /entry/instrument/manipulator/sample_bias_potentiostat. -# -# -# -# -# -# Drain current of the sample and sample holder. -# -# -# -# Amperemeter measuring the drain current of the sample and sample holder. -# -# This should be a link to /entry/instrument/manipulator/drain_current_amperemeter. -# -# -# -# -# -# Current of low-energy electrons to the sample for charge neutralization. -# -# -# -# Flood gun creating a current of low-energy electrons. -# -# This should be a link to /entry/instrument/flood_gun. -# -# -# -# -# -# -# The default NXdata field containing a view on the measured data. -# This NXdata field contains a collection of the main relevant fields (axes). -# If you want to provide additional views on your data, you can additionally use -# the generic NXdata group of NXentry. -# -# The naming of fields should follow the convention defined in the -# :ref:`NXdata_photoemission` base class: -# -# - **energy**: Calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). -# - **momentum**: Calibrated momentum axis. Unit category: NX_ANY (e.g., kg*m/s). -# - **kx**: Calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). -# - **ky**: Calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). -# - **kz**: Calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). -# - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). -# Unit category: NX_ANGLE -# - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) -# Unit category: NX_ANGLE -# - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) -# Unit category: NX_LENGTH -# - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) -# Unit category: NX_LENGTH -# - **delay**: Calibrated delay time. Unit category: NX_TIME (s). -# - **polarization_angle**: Linear polarization angle of the incoming or -# outgoing beam. This could be a link to -# /entry/instrument/beam/incident_polarization_angle or -# /entry/instrument/beam/final_polarization_angle if they exist. -# Unit category: NX_ANGLE (° or rad) -# - **ellipticity**: Ellipticity of the incoming or outgoing beam. -# Could be a link to /entry/instrument/beam/incident_ellipticity or -# /entry/instrument/beam/final_ellipticity if they exist. -# Unit category: NX_ANGLE (° or rad) -# -# -# -# -# -# -# -# -# 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. -# -# -# -# -# The energy can be dispersed according to different strategies. ``energy_depends`` points to -# the path of a field defining the calibrated axis on which the energy axis depends. -# -# For example: -# @energy_depends: 'entry/process/energy_calibration' -# -# -# -# -# From d577dfde2f22950266ffbcf73ef54fe75c452be6 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 15 Mar 2024 11:58:07 +0100 Subject: [PATCH 0626/1012] rename and rebuild mpes-related base classes --- ...emission.nxdl.xml => NXdata_mpes.nxdl.xml} | 10 ++++----- ...nxdl.xml => NXdata_mpes_detector.nxdl.xml} | 10 ++++----- ...ssion.nxdl.xml => NXprocess_mpes.nxdl.xml} | 10 ++++----- ...ta_photoemission.yaml => NXdata_mpes.yaml} | 22 +++++++++---------- ...etector.yaml => NXdata_mpes_detector.yaml} | 22 +++++++++---------- ...photoemission.yaml => NXprocess_mpes.yaml} | 22 +++++++++---------- 6 files changed, 48 insertions(+), 48 deletions(-) rename contributed_definitions/{NXdata_photoemission.nxdl.xml => NXdata_mpes.nxdl.xml} (98%) rename contributed_definitions/{NXdata_photoemission_detector.nxdl.xml => NXdata_mpes_detector.nxdl.xml} (98%) rename contributed_definitions/{NXprocess_photoemission.nxdl.xml => NXprocess_mpes.nxdl.xml} (96%) rename contributed_definitions/nyaml/{NXdata_photoemission.yaml => NXdata_mpes.yaml} (98%) rename contributed_definitions/nyaml/{NXdata_photoemission_detector.yaml => NXdata_mpes_detector.yaml} (98%) rename contributed_definitions/nyaml/{NXprocess_photoemission.yaml => NXprocess_mpes.yaml} (96%) diff --git a/contributed_definitions/NXdata_photoemission.nxdl.xml b/contributed_definitions/NXdata_mpes.nxdl.xml similarity index 98% rename from contributed_definitions/NXdata_photoemission.nxdl.xml rename to contributed_definitions/NXdata_mpes.nxdl.xml index 096e8efbdc..abfbaf77b1 100644 --- a/contributed_definitions/NXdata_photoemission.nxdl.xml +++ b/contributed_definitions/NXdata_mpes.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + - :ref:`NXdata_photoemission` describes the plottable data and related dimension scales in photoemission + :ref:`NXdata_mpes` describes the plottable data and related dimension scales in photoemission experiments. It extends the NXdata class and provides a glossary of explicitly named axis names @@ -519,7 +519,7 @@ AXISNAME_indices documentation copied from datarules.rst One calibrated k-space coordinate. It is envisioned that the axes are named kx, ky, and kz, - in accordance with the calibrations defined in NXprocess_photoemission. + in accordance with the calibrations defined in NXprocess_mpes. Typically, the vectors in momentum space are defined such that kx and ky comprise the parallel component, while kz is taken as the perpendicular component. @@ -531,7 +531,7 @@ AXISNAME_indices documentation copied from datarules.rst One calibrated angular coordinate. It is envisioned that the axes are name angular0, angular1, etc., - in accordance with the calibrations defined in NXprocess_photoemission. + in accordance with the calibrations defined in NXprocess_mpes. The angular axes should be named in order of decreasing speed, i.e., angular0 should be the fastest scan axis and angular1 should be the slow-axis angular coordinate. However, @@ -543,7 +543,7 @@ AXISNAME_indices documentation copied from datarules.rst One calibrated spatial coordinate. It is envisioned that the axes are name spatial0, spatial1, etc., - in accordance with the calibrations defined in NXprocess_photoemission. + in accordance with the calibrations defined in NXprocess_mpes. The spatial axes should be named in order of decreasing speed, i.e., spatial0 should be the fastest scan axis and spatial1 should be the slow-axis spatial coordinate. However, diff --git a/contributed_definitions/NXdata_photoemission_detector.nxdl.xml b/contributed_definitions/NXdata_mpes_detector.nxdl.xml similarity index 98% rename from contributed_definitions/NXdata_photoemission_detector.nxdl.xml rename to contributed_definitions/NXdata_mpes_detector.nxdl.xml index a1fa705a4f..4cbcb6efe9 100644 --- a/contributed_definitions/NXdata_photoemission_detector.nxdl.xml +++ b/contributed_definitions/NXdata_mpes_detector.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + - :ref:`NXdata__photoemission_detector` describes the plottable data and related - dimension scales for raw detector data in _photoemission experiments. + :ref:`NXdata_mpes_detector` describes the plottable data and related + dimension scales for raw detector data in photoemission experiments. It extends the NXdata class and provides a glossary of explicitly named axis names - which are typical for raw _photoemission data. + which are typical for raw photoemission data. For now, the extension of NXdata is performed by simply copying all existing groups, fields, and attibute from NXdata. In the future, it is envisioned that this extension can be solved by @@ -594,7 +594,7 @@ AXISNAME_indices documentation copied from datarules.rst setup - it would just know that it collected N images, which would flatten the external parameters to one axis, too. This can then be linked, e.g. with NXcalibration, to the appropriate fields in the instrument - and write it to the top-level NXdata_photoemission. + and write it to the top-level NXdata_mpes. diff --git a/contributed_definitions/NXprocess_photoemission.nxdl.xml b/contributed_definitions/NXprocess_mpes.nxdl.xml similarity index 96% rename from contributed_definitions/NXprocess_photoemission.nxdl.xml rename to contributed_definitions/NXprocess_mpes.nxdl.xml index b9e0db8499..6d95429413 100644 --- a/contributed_definitions/NXprocess_photoemission.nxdl.xml +++ b/contributed_definitions/NXprocess_mpes.nxdl.xml @@ -21,9 +21,9 @@ # # For further information, see http://www.nexusformat.org --> - + - :ref:`NXprocess_photoemission` describes events of data processing, reconstruction, + :ref:`NXprocess_mpes` describes events of data processing, reconstruction, or analysis for photoemission-related data. It extends the NXprocess class and provides a glossary of explicitly named processes @@ -81,7 +81,7 @@ It is envisioned that the individual calibrations for each coordinate are stored as kx_calibration, ky_calibration, kz_calibration, in accordance - with the axis name definitions in NXdata_photoemission. + with the axis name definitions in NXdata_mpes. It is also possible to have k_parallel_calibration and k_perp_calibration if the momentum axes are defined as k_parallel and k_perp for the parallel and @@ -104,7 +104,7 @@ It is envisioned that the individual calibrations for each angle are stored as angular0_calibration, angular1_calibration, etc., in accordance - with the axis name definitions in NXdata_photoemission. + with the axis name definitions in NXdata_mpes. @@ -123,7 +123,7 @@ It is envisioned that the individual calibrations for each angle are stored as spatial0_calibration, spatial1_calibration, etc., in accordance - with the axis name definitions in NXdata_photoemission. + with the axis name definitions in NXdata_mpes. diff --git a/contributed_definitions/nyaml/NXdata_photoemission.yaml b/contributed_definitions/nyaml/NXdata_mpes.yaml similarity index 98% rename from contributed_definitions/nyaml/NXdata_photoemission.yaml rename to contributed_definitions/nyaml/NXdata_mpes.yaml index 5c29bf208d..35bc7f5d09 100644 --- a/contributed_definitions/nyaml/NXdata_photoemission.yaml +++ b/contributed_definitions/nyaml/NXdata_mpes.yaml @@ -1,6 +1,6 @@ category: base doc: | - :ref:`NXdata_photoemission` describes the plottable data and related dimension scales in photoemission + :ref:`NXdata_mpes` describes the plottable data and related dimension scales in photoemission experiments. It extends the NXdata class and provides a glossary of explicitly named axis names @@ -140,7 +140,7 @@ symbols: type: group ignoreExtraFields: true ignoreExtraAttributes: true -NXdata_photoemission(NXdata): +NXdata_mpes(NXdata): \@auxiliary_signals: doc: | .. index:: plotting @@ -446,7 +446,7 @@ NXdata_photoemission(NXdata): unit: NX_WAVENUMBER doc: | One calibrated k-space coordinate. It is envisioned that the axes are named kx, ky, and kz, - in accordance with the calibrations defined in NXprocess_photoemission. + in accordance with the calibrations defined in NXprocess_mpes. Typically, the vectors in momentum space are defined such that kx and ky comprise the parallel component, while kz is taken as the perpendicular component. @@ -457,7 +457,7 @@ NXdata_photoemission(NXdata): unit: NX_ANGLE doc: | One calibrated angular coordinate. It is envisioned that the axes are name angular0, angular1, etc., - in accordance with the calibrations defined in NXprocess_photoemission. + in accordance with the calibrations defined in NXprocess_mpes. The angular axes should be named in order of decreasing speed, i.e., angular0 should be the fastest scan axis and angular1 should be the slow-axis angular coordinate. However, @@ -468,7 +468,7 @@ NXdata_photoemission(NXdata): unit: NX_ANGLE doc: | One calibrated spatial coordinate. It is envisioned that the axes are name spatial0, spatial1, etc., - in accordance with the calibrations defined in NXprocess_photoemission. + in accordance with the calibrations defined in NXprocess_mpes. The spatial axes should be named in order of decreasing speed, i.e., spatial0 should be the fastest scan axis and spatial1 should be the slow-axis spatial coordinate. However, @@ -498,7 +498,7 @@ NXdata_photoemission(NXdata): /entry/instrument/beam/final_ellipticity if they exist. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 5c41a3ea6b92bad96022fe6260ef12ccd1dd81ed177fdf8ef4345419e0e7ad62 +# 8c857972d4d2406b9793e2e5979764f79a8b1ffe0a5eda3addb975c07d33c3bc # # # -# +# # -# +# # -# +# # -# :ref:`NXprocess_photoemission` describes events of data processing, reconstruction, +# :ref:`NXprocess_mpes` describes events of data processing, reconstruction, # or analysis for photoemission-related data. # # It extends the NXprocess class and provides a glossary of explicitly named processes @@ -297,7 +297,7 @@ NXprocess_photoemission(NXobject): # # It is envisioned that the individual calibrations for each coordinate are # stored as kx_calibration, ky_calibration, kz_calibration, in accordance -# with the axis name definitions in NXdata_photoemission. +# with the axis name definitions in NXdata_mpes. # # It is also possible to have k_parallel_calibration and k_perp_calibration if # the momentum axes are defined as k_parallel and k_perp for the parallel and @@ -320,7 +320,7 @@ NXprocess_photoemission(NXobject): # # It is envisioned that the individual calibrations for each angle are # stored as angular0_calibration, angular1_calibration, etc., in accordance -# with the axis name definitions in NXdata_photoemission. +# with the axis name definitions in NXdata_mpes. # # # @@ -339,7 +339,7 @@ NXprocess_photoemission(NXobject): # # It is envisioned that the individual calibrations for each angle are # stored as spatial0_calibration, spatial1_calibration, etc., in accordance -# with the axis name definitions in NXdata_photoemission. +# with the axis name definitions in NXdata_mpes. # # # From 04a0fbdc06bf2771f3becbe0f9268c41ade87ce5 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 15 Mar 2024 12:15:56 +0100 Subject: [PATCH 0627/1012] use old dim notation again --- contributed_definitions/nyaml/NXcalibration.yaml | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/contributed_definitions/nyaml/NXcalibration.yaml b/contributed_definitions/nyaml/NXcalibration.yaml index 0909b351d1..32cfcdf7cc 100644 --- a/contributed_definitions/nyaml/NXcalibration.yaml +++ b/contributed_definitions/nyaml/NXcalibration.yaml @@ -53,7 +53,7 @@ NXcalibration(NXobject): Vector containing the data coordinates in the original uncalibrated axis dimensions: rank: 1 - dim: (ncal,) + dim: [[1, ncal]] \@symbol: doc: | The symbol of the axis to be used in the fit_function, e.g., `energy`, `E`. @@ -75,7 +75,7 @@ NXcalibration(NXobject): if the field name is `input_my_field` you should refer to this axis by `my_field` in the `fit_function`. dimensions: rank: 1 - dim: (ncal,) + dim: [[1, ncal]] \@input_path: doc: | The path from which this data is derived, e.g., raw detector axis. @@ -88,7 +88,7 @@ NXcalibration(NXobject): E(TOF). Here we can store the array of fit coefficients. dimensions: rank: 1 - dim: (ncoeff,) + dim: [[1, ncoeff]] fit_function(NX_CHAR): doc: | For non-linear energy calibrations. Here we can store the formula of the @@ -127,7 +127,7 @@ NXcalibration(NXobject): A vector representing the axis after calibration, matching the data length dimensions: rank: 1 - dim: (ncal,) + dim: [[1, ncal]] \@output_path: doc: | The path to which this data is written, e.g., the calibrated energy. @@ -138,7 +138,7 @@ NXcalibration(NXobject): NXdata groups can be used for multidimensional data which are relevant to the calibration # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d9ed6b631af1678d0925f81a459d0cbf94aad026ed61e3f4587ed26f38e1e9bd +# d3cce510d0f123defa65e89965cce313e56f0e4696d9c28e54a253439539156c # # # - :ref:`NXdata__photoemission_detector` describes the plottable data and related + :ref:`NXdata_photoemission_detector` describes the plottable data and related dimension scales for raw detector data in _photoemission experiments. It extends the NXdata class and provides a glossary of explicitly named axis names - which are typical for raw _photoemission data. + which are typical for raw photoemission data. For now, the extension of NXdata is performed by simply copying all existing groups, fields, and attibute from NXdata. In the future, it is envisioned that this extension can be solved by diff --git a/contributed_definitions/nyaml/NXdata_photoemission_detector.yaml b/contributed_definitions/nyaml/NXdata_photoemission_detector.yaml index 48e40bd2dd..e6acfb6fef 100644 --- a/contributed_definitions/nyaml/NXdata_photoemission_detector.yaml +++ b/contributed_definitions/nyaml/NXdata_photoemission_detector.yaml @@ -1,10 +1,10 @@ category: base doc: | - :ref:`NXdata__photoemission_detector` describes the plottable data and related + :ref:`NXdata_photoemission_detector` describes the plottable data and related dimension scales for raw detector data in _photoemission experiments. It extends the NXdata class and provides a glossary of explicitly named axis names - which are typical for raw _photoemission data. + which are typical for raw photoemission data. For now, the extension of NXdata is performed by simply copying all existing groups, fields, and attibute from NXdata. In the future, it is envisioned that this extension can be solved by @@ -513,7 +513,7 @@ NXdata_photoemission_detector(NXobject): and write it to the top-level NXdata_photoemission. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4a8696034792a74233b10ba2cbe6ba4d959297ad7ff7bd8d6d968a706d69d2d4 +# b35ab3a0de6d878027104277fe9070b32fc948e9c13b95b49d86457e9087470b # # # - - - 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. - - - Name of user responsible for this entry - - - - Role of user responsible for this entry. - Suggested roles are "local_contact", - "principal_investigator", and "proposer" - - - - Affiliation of user - - - Address of user - - - Telephone number of user - - - Fax number of user - - - Email of user - - - - facility based unique identifier for this person - e.g. their identification code on the facility - address/contact database - - - - - an author code, Open Researcher and Contributor ID, - defined by https://orcid.org and expressed as a URI - - + + + 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. + + + + Name of user responsible for this entry + + + + + Role of user responsible for this entry. + Suggested roles are "local_contact", + "principal_investigator", and "proposer" + + + + + Affiliation of user + + + + + Address of user + + + + + Telephone number of user + + + + + Fax number of user + + + + + Email of user + + + + + facility based unique identifier for this person + e.g. their identification code on the facility + address/contact database + + + + + Details about an author code, open researcher, or contributor + (persistent) identifier, defined by https://orcid.org and expressed + as a URI. + + - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. - diff --git a/base_classes/nyaml/NXuser.yaml b/base_classes/nyaml/NXuser.yaml index 383a8e9d17..7f3f9db117 100644 --- a/base_classes/nyaml/NXuser.yaml +++ b/base_classes/nyaml/NXuser.yaml @@ -36,10 +36,11 @@ NXuser(NXobject): facility based unique identifier for this person e.g. their identification code on the facility address/contact database - ORCID: + (NXidentifier): doc: | - an author code, Open Researcher and Contributor ID, - defined by https://orcid.org and expressed as a URI + Details about an author code, open researcher, or contributor + (persistent) identifier, defined by https://orcid.org and expressed + as a URI. \@default: doc: | .. index:: plotting diff --git a/contributed_definitions/NXapm_composition_space_results.nxdl.xml b/contributed_definitions/NXapm_composition_space_results.nxdl.xml index 72dbb28419..d1902801e1 100644 --- a/contributed_definitions/NXapm_composition_space_results.nxdl.xml +++ b/contributed_definitions/NXapm_composition_space_results.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -57,30 +57,14 @@ This is an initial draft application definition for the common NFDI-MatWerk, FAIRmat infrastructure use case IUC09 how to improve the organization and - results storage of the composition space tool and make these data at the same - time directly understandable for NOMAD. - - This draft does no contain yet the annotations for how to also store - in the HDF5 file a default visualization whereby the composition grid - could directly be explored using H5Web. I am happy to add this ones the - data have been mapped on this schema, i.e. more discussion needed. - - Also iso-surfaces can be described, for paraprobe, this is a solved problem, - check the respective group in the NXapm_paraprobe_results_nanochem data - schema/application definition. + results storage of the composition space tool and make these data at the + same time directly understandable for research data management systems + like NOMAD Oasis. - + - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - + + @@ -88,16 +72,16 @@ unless it is explicitly specified differently--> - - + + - + - TBD, maybe how to link between pyiron state tracking and app state tracking + TBD, maybe how to link between pyiron state tracking and app state tracking. - + Disencouraged place for free-text for e.g. comments. @@ -116,55 +100,51 @@ for if desired all the dependencies and libraries--> were completed and composition space tool exited as a process. - + + - The path and name of the config file for this analysis. + The path and name of the config file that was used for this analysis. TBD, this can be e.g. Alaukik's YAML file for composition space. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - - The path and name of the file (technology partner or community format) - from which reconstructed ion positions were loaded. - - - + + + + - - - - The path and name of the file (technology partner or community format - from which ranging definitions, i.e. how to map mass-to- - charge-state ratios on iontypes were loaded. - - - + + + Details about the file (technology partner or community format) + from which reconstructed ion positions were loaded. + + + + + + + + + Details about the file (technology partner or community format) + from which ranging definitions were loaded which detail how to + map mass-to-charge-state ratios on iontypes. + + + + + - + + Path to the directory where the tool should store NeXus/HDF5 results of this analysis. If not specified results will be stored in the current working directory. - + A statement whether the executable managed to process the analysis - or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. + or failed prematurely. This status is written to the results file after the + end_time at which point the executable must not compute any analysis. Only when this status message is present and shows `success`, the user should consider the results. In all other cases it might be that the executable has terminated prematurely or another error @@ -180,39 +160,38 @@ runs as desired...--> If used, contact information and eventually details of at least the person who performed this analysis. - - - - - - - - - - + + + + - + - Details about the coordinate system conventions used. + Details about coordinate systems (reference frames) used. In atom probe several coordinate + systems have to be distinguished. Names of instances of such :ref:`NXcoordinate_system` + should be documented explicitly and doing so by picking from the + following controlled set of names: + + * composition_space + * lab + * specimen + * laser + * instrument + * detector + * recon + + The aim of this convention is to support users with contextualizing which reference + frame each instance (coordinate system) is. If needed, instances of :ref:`NXtransformations` + are used to detail the explicit affine transformations whereby one can convert + representations between different reference frames. + Inspect :ref:`NXtransformations` for further details. - - - The individual coordinate systems which should be used. - Some suggestions follow, e.g. that field names should be prefixed - with the following controlled terms indicating which individual - coordinate system is described: - - * world - * composition_space - * lab - * specimen - * laser - * leap - * detector - * recon - - + + + + @@ -459,21 +438,27 @@ output will collapse substantially--> - + Specify if it was different from the number_of_processes in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. - + Specify if it was different from the number_of_threads in the NXcs_profiling super class. diff --git a/contributed_definitions/NXapm_input_ranging.nxdl.xml b/contributed_definitions/NXapm_input_ranging.nxdl.xml deleted file mode 100644 index b8561c5589..0000000000 --- a/contributed_definitions/NXapm_input_ranging.nxdl.xml +++ /dev/null @@ -1,63 +0,0 @@ - - - - - - - Metadata to ranging definitions made for a dataset in atom probe microscopy. - - Ranging is the process of labeling time-of-flight data with so-called iontypes - which ideally specify the most likely ion/molecular ion evaporated within a - given mass-to-charge-state-ratio value interval. - - The paraprobe-toolbox uses the convention that the so-called UNKNOWNTYPE - iontype (or unranged ions) represents the default iontype. - The ID of this special iontype is always reserved as 0. Each ion - is assigned to the UNKNOWNTYPE by default. Iontypes are assigned - by checking if the mass-to-charge-state-ratio values of an ion matches - to any of the defined mass-to-charge-state-ratio intervals. - - - - Path and name of the NeXus/HDF5 file which stores ranging definitions. - - - - Version identifier of the file (representing an at least SHA256 strong) - hash. Such hashes serve reproducibility as they can be used for tracking - provenance metadata in a workflow. - - - - - - Name of the group (prefix to the individual ranging definitions) inside - the file referred to by filename which points to the specific ranging - definition to use. - An HDF5 file can store multiple ranging definitions. Using an ID is - the mechanism to distinguish which specific ranging (version) will - be processed. Reconstruction and ranging IDs can differ. - They specify different IDs. - - - diff --git a/contributed_definitions/NXapm_input_reconstruction.nxdl.xml b/contributed_definitions/NXapm_input_reconstruction.nxdl.xml deleted file mode 100644 index 07275cd254..0000000000 --- a/contributed_definitions/NXapm_input_reconstruction.nxdl.xml +++ /dev/null @@ -1,58 +0,0 @@ - - - - - - - Metadata of a dataset (tomographic reconstruction) in atom probe microscopy. - - - - Name of the (NeXus)/HDF5 file which stores reconstructed ion position - and mass-to-charge-state ratios. Such an HDF5 file can store multiple - reconstructions. Using the information within the dataset_name fields - is the mechanism whereby paraprobe decides which reconstruction to - process. With this design it is possible that the same HDF5 - file can store multiple versions of a reconstruction. - - - - Version identifier of the file (representing an at least SHA256 strong) - hash. Such hashes serve reproducibility as they can be used for tracking - provenance metadata in a workflow. - - - - - - Name of the dataset inside the HDF5 file which refers to the - specific reconstructed ion positions to use for this analysis. - - - - - Name of the dataset inside the HDF5 file which refers to the - specific mass-to-charge-state-ratio values to use for this analysis. - - - diff --git a/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml index df43af9f79..541a059a7d 100644 --- a/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml @@ -114,10 +114,10 @@ * detector * recon - The aim of this convention is to support users with contextualizing which reference - frame each instance (coordinate system) is. If needed, instances of :ref:`NXtransformations` + The aim of this convention is to support users with contextualizing which reference frame + each instance (coordinate system) is. If needed, instances of :ref:`NXtransformations` are used to detail the explicit affine transformations whereby one can convert - rpresentations between different reference frames. + representations between different reference frames. Inspect :ref:`NXtransformations` for further details. diff --git a/contributed_definitions/NXclustering.nxdl.xml b/contributed_definitions/NXclustering.nxdl.xml deleted file mode 100644 index 147c4baa1b..0000000000 --- a/contributed_definitions/NXclustering.nxdl.xml +++ /dev/null @@ -1,124 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of numeral labels per object. - - - - - Number of categorical labels per object. - - - - - Total number of clusters detected. - - - - - Metadata to the results of a clustering analysis. - - Clustering algorithms are routine tools to segment a set of objects/primitives - into groups, objects of different type. A plethora of algorithms have been - proposed for geometric primitives as objects, such as points, triangles, - or (abstract) objects. - - This base class considers metadata and results of one clustering - applied to a set in which objects are either categorized as noise - or belonging to a cluster, specifically here only one cluster. - - - - How many numeric labels does each object have. - - - - - How many categorical labels does each object have. - - - - - Reference to a set of objects investigated in a cluster analysis. - Objects must have clear integer identifier. - - - - - Reference to numeric attribute data for each object. - - - - - Reference to categorical attribute data for each object. - - - - - - Which identifier is the first to be used to label a cluster. - - The value should be chosen in such a way that special values can be resolved: - * identifier_offset-1 indicates an object belongs to no cluster. - * identifier_offset-2 indicates an object belongs to the noise category. - Setting for instance identifier_offset to 1 recovers the commonly used - case that objects of the noise category get values to -1 and unassigned points to 0. - - - - - Total number of objects categorized as unassigned. - - - - - Total number of objects categorized as noise. - - - - - Total number of clusters (excluding noise and unassigned). - - - - - Number of objects associated to each cluster. The labels are implicit, - meaning the zeroth/first entry in the array belongs to the first cluster, - the second entry to the second cluster and so on and so forth. - The first cluster has the value of identifier_offset as its identifier. - The second cluster has identifier_offset + 1, and so on and so forth. - - - - - - - diff --git a/contributed_definitions/nyaml/NXapm_composition_space_results.yaml b/contributed_definitions/nyaml/NXapm_composition_space_results.yaml index 30fae546b6..c0cfe8a224 100644 --- a/contributed_definitions/nyaml/NXapm_composition_space_results.yaml +++ b/contributed_definitions/nyaml/NXapm_composition_space_results.yaml @@ -4,17 +4,9 @@ doc: | This is an initial draft application definition for the common NFDI-MatWerk, FAIRmat infrastructure use case IUC09 how to improve the organization and - results storage of the composition space tool and make these data at the same - time directly understandable for NOMAD. - - This draft does no contain yet the annotations for how to also store - in the HDF5 file a default visualization whereby the composition grid - could directly be explored using H5Web. I am happy to add this ones the - data have been mapped on this schema, i.e. more discussion needed. - - Also iso-surfaces can be described, for paraprobe, this is a solved problem, - check the respective group in the NXapm_paraprobe_results_nanochem data - schema/application definition. + results storage of the composition space tool and make these data at the + same time directly understandable for research data management systems + like NOMAD Oasis. symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. @@ -30,30 +22,23 @@ symbols: Number of terms in the position clustering dictionary type: group NXapm_composition_space_results(NXobject): - - # by default for appdefs the value of the exists keyword is required - # unless it is explicitly specified differently + # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently (NXentry): - exists: ['min', '1', 'max', '1'] - \@version: - doc: | - Version specifier of this application definition. - definition: - doc: | - Official NeXus NXDL schema with which this file was written. + exists: [min, 1, max, 1] + definition(NX_CHAR): + \@version(NX_CHAR): enumeration: [NXapm_composition_space_results] - # can be used for the name of the tool and version but also # for if desired all the dependencies and libraries (NXprogram): - exists: ['min', '1', 'max', 'unbounded'] - program: - \@version: - job_pyiron_identifier: + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + job_pyiron_identifier(NX_CHAR): exists: recommended doc: | - TBD, maybe how to link between pyiron state tracking and app state tracking - description: + TBD, maybe how to link between pyiron state tracking and app state tracking. + description(NX_CHAR): exists: optional doc: | Disencouraged place for free-text for e.g. comments. @@ -67,45 +52,44 @@ NXapm_composition_space_results(NXobject): ISO 8601 formatted time code with local time zone offset to UTC information included when the analysis behind this results file were completed and composition space tool exited as a process. - config_filename: + # config + config(NXserialized): doc: | - The path and name of the config file for this analysis. + The path and name of the config file that was used for this analysis. TBD, this can be e.g. Alaukik's YAML file for composition space. - - # one could also wrap the entire triple of NXprocess (voxelization, gmm, real space) - # by a parent NXprocess whereby one could store the results of multiple analyses - # runs of the tool in the same individually documented way for as many parameter - # runs as desired... - \@version: - doc: | - At least SHA256 strong hash of the specific config_file for - tracking provenance. - dataset(NXapm_input_reconstruction): - filename: - doc: | - The path and name of the file (technology partner or community format) - from which reconstructed ion positions were loaded. - \@version: - iontypes(NXapm_input_ranging): - filename: - doc: | - The path and name of the file (technology partner or community format - from which ranging definitions, i.e. how to map mass-to- - charge-state ratios on iontypes were loaded. - \@version: - results_path: + type(NX_CHAR): + path(NX_CHAR): + algorithm(NX_CHAR): + checksum(NX_CHAR): + reconstruction(NXserialized): + doc: | + Details about the file (technology partner or community format) + from which reconstructed ion positions were loaded. + type(NX_CHAR): + path(NX_CHAR): + algorithm(NX_CHAR): + checksum(NX_CHAR): + ranging(NXserialized): + doc: | + Details about the file (technology partner or community format) + from which ranging definitions were loaded which detail how to + map mass-to-charge-state ratios on iontypes. + type(NX_CHAR): + path(NX_CHAR): + algorithm(NX_CHAR): + checksum(NX_CHAR): + # results + results_path(NX_CHAR): exists: optional doc: | Path to the directory where the tool should store NeXus/HDF5 results of this analysis. If not specified results will be stored in the current working directory. - status: + status(NX_CHAR): doc: | A statement whether the executable managed to process the analysis - or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. + or failed prematurely. This status is written to the results file after the + end_time at which point the executable must not compute any analysis. Only when this status message is present and shows `success`, the user should consider the results. In all other cases it might be that the executable has terminated prematurely or another error @@ -116,49 +100,41 @@ NXapm_composition_space_results(NXobject): doc: | If used, contact information and eventually details of at least the person who performed this analysis. - name: - affiliation: - exists: recommended - address: - exists: optional - email: + name(NX_CHAR): exists: recommended - orcid: - exists: recommended - orcid_platform: - exists: recommended - telephone_number: + affiliation(NX_CHAR): exists: optional - role: - exists: recommended - social_media_name: + (NXidentifier): exists: optional - social_media_platform: + role(NX_CHAR): exists: optional (NXcoordinate_system_set): - exists: optional doc: | - Details about the coordinate system conventions used. + Details about coordinate systems (reference frames) used. In atom probe several coordinate + systems have to be distinguished. Names of instances of such :ref:`NXcoordinate_system` + should be documented explicitly and doing so by picking from the + following controlled set of names: + + * composition_space + * lab + * specimen + * laser + * instrument + * detector + * recon + + The aim of this convention is to support users with contextualizing which reference + frame each instance (coordinate system) is. If needed, instances of :ref:`NXtransformations` + are used to detail the explicit affine transformations whereby one can convert + representations between different reference frames. + Inspect :ref:`NXtransformations` for further details. + (NXcoordinate_system): (NXtransformations): - exists: ['min', '1', 'max', 'unbounded'] - doc: | - The individual coordinate systems which should be used. - Some suggestions follow, e.g. that field names should be prefixed - with the following controlled terms indicating which individual - coordinate system is described: - - * world - * composition_space - * lab - * specimen - * laser - * leap - * detector - * recon + # add further fields coming from using the charge state recovery + # workflow from the ifes_apt_tc_data_modeling library voxelization(NXprocess): sequence_index(NX_POSINT): enumeration: [1] - # specify the grid your using and for each ion in which cell i.e. voxel it is # one could also have a more sophisticated data model where there is some # fuzziness i.e. if an ML/AI model returns multiple values or a probability diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml index 11d43c91d2..732305a416 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml @@ -77,10 +77,10 @@ NXapm_paraprobe_tool_common(NXobject): * detector * recon - The aim of this convention is to support users with contextualizing which reference - frame each instance (coordinate system) is. If needed, instances of :ref:`NXtransformations` + The aim of this convention is to support users with contextualizing which reference frame + each instance (coordinate system) is. If needed, instances of :ref:`NXtransformations` are used to detail the explicit affine transformations whereby one can convert - rpresentations between different reference frames. + representations between different reference frames. Inspect :ref:`NXtransformations` for further details. (NXcoordinate_system): (NXtransformations): diff --git a/manual/source/classes/contributed_definitions/cgms-structure.rst b/manual/source/classes/contributed_definitions/cgms-structure.rst index 7307e0810b..f7a4629fe0 100644 --- a/manual/source/classes/contributed_definitions/cgms-structure.rst +++ b/manual/source/classes/contributed_definitions/cgms-structure.rst @@ -176,9 +176,6 @@ not only for stencil-based methods: is smoothened in a controlled manner (typically using kernel methods). :ref:`NXsimilarity_grouping`: - A base class defining an alias for NXclustering. - - :ref:`NXclustering`: A base class to describe clustering of objects (such as atoms or features). :ref:`NXrotation_set`: From b88b4dadaac0f178c777f455baa24e0fcc6de351 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 20 Mar 2024 14:19:45 +0100 Subject: [PATCH 0632/1012] NeXus bugs fixed that were spotted with the combination pos+env ErMnO example --- contributed_definitions/NXapm.nxdl.xml | 82 ++++++++++++------------ contributed_definitions/nyaml/NXapm.yaml | 76 +++++++++++----------- 2 files changed, 80 insertions(+), 78 deletions(-) diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index c6001743eb..f2813092bf 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -47,20 +47,20 @@ Application definition for atom probe and field ion microscopy experiments. - + - + - + The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) which was used to generate this NeXus file instance. - + A collection of all programs and libraries which are considered relevant to understand with which software tools this NeXus file instance was @@ -89,6 +89,9 @@ + The identifier whereby the experiment is referred to in the control software. This is neither the specimen_name nor the experiment_identifier. For @@ -150,7 +153,7 @@ the appdef definition here is nothing else then the documentation of this for a - + @@ -204,7 +207,7 @@ the appdef definition here is nothing else then the documentation of this for a used which are then arranged and documented with a description of the workflow so that actionable graphs become instantiatable. - + A qualifier whether the sample is a real one or a virtual one (in a computer simulation). @@ -288,7 +291,7 @@ schema for heat treatment - + The chemical composition of the sample. Typically, it is assumed that this more macroscopic composition is representative for the material @@ -336,17 +339,16 @@ schema for heat treatment - + - A qualifier whether the sample is a real one - or a virtual one (in a computer simulation). + A qualifier whether the specimen is a real one or a virtual one. - + Given name an alias. Better use identifier and parent_identifier instead. A single NXentry should be used only for the characterization of a single specimen. @@ -423,7 +425,7 @@ schema for heat treatment specimen. - + Ideally measured otherwise best elaborated guess of the (initial) shank angle. This is a measure of the specimen taper. Define it in such a way that the base of the specimen @@ -494,14 +496,14 @@ schema for heat treatment - + - + @@ -510,25 +512,25 @@ schema for heat treatment - + - + - + - - + + @@ -560,7 +562,7 @@ turbomolecular_pump(NXpump):--> - + a time series of the specimen shape evolution--> - + - + @@ -691,13 +693,13 @@ does not have to be exposed (although this clearly is against FAIR principles bu is does not have the authority to decide which portions of proprietary code have to be public we can only make recommendations--> - + - + @@ -742,12 +744,12 @@ pulse_identifier(NX_INT): # this is the pulse on which they came i number of hits after hits finding but prior calibrations--> - + - + @@ -792,12 +794,12 @@ i number of hits after hits finding but prior calibrations--> - + - + @@ -822,12 +824,12 @@ Relevant for ranging are the calibrated data, thats why only these - + - + @@ -843,7 +845,7 @@ results--> - + @@ -936,12 +938,12 @@ results--> - - - + + + - + The respective ranging definitions file RNG/RRNG/ENV/HDF5. @@ -954,7 +956,7 @@ results--> - + @@ -983,7 +985,7 @@ results--> - + @@ -1012,12 +1014,12 @@ NEW ISSUE: add parameters of the background model in an e.g. work of A. London et al.--> - + - + @@ -1049,7 +1051,7 @@ in an e.g. work of A. London et al.--> - + diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml index da744a100c..87773339eb 100644 --- a/contributed_definitions/nyaml/NXapm.yaml +++ b/contributed_definitions/nyaml/NXapm.yaml @@ -17,17 +17,19 @@ symbols: the pulse_identifier. type: group NXapm(NXobject): - (NXentry): + entryID(NXentry): exists: [min, 1, max, infty] definition(NX_CHAR): \@version(NX_CHAR): + exists: optional enumeration: [NXapm] profiling(NXcs_profiling): + exists: optional doc: | The configuration of the I/O writer software (e.g. `pynxtools `_) which was used to generate this NeXus file instance. # command_line_call(NX_CHAR): - (NXprogram): # understood by default as PROGRAM(NXprogram), i.e. program1, program2, ... + programID(NXprogram): # understood by default as PROGRAM(NXprogram), i.e. program1, program2, ... exists: [min, 0, max, infty] doc: | A collection of all programs and libraries which are considered relevant @@ -54,6 +56,7 @@ NXapm(NXobject): is_persistent(NX_BOOLEAN): run_number(NX_CHAR): exists: recommended + # cannot be made required as for simulations you do not have a run number! doc: | The identifier whereby the experiment is referred to in the control software. This is neither the specimen_name nor the experiment_identifier. For @@ -110,7 +113,7 @@ NXapm(NXobject): (NXcite): exists: [min, 0, max, infty] doi(NX_CHAR): - (NXserialized): + serializedID(NXserialized): exists: [min, 0, max, infty] type(NX_CHAR): path(NX_CHAR): @@ -159,7 +162,6 @@ NXapm(NXobject): used which are then arranged and documented with a description of the workflow so that actionable graphs become instantiatable. method(NX_CHAR): - exists: recommended doc: | A qualifier whether the sample is a real one or a virtual one (in a computer simulation). @@ -235,7 +237,7 @@ NXapm(NXobject): unit: NX_ANY description(NX_CHAR): exists: optional - (NXchemical_composition): + chemical_composition(NXchemical_composition): exists: recommended doc: | The chemical composition of the sample. Typically, it is assumed that @@ -275,13 +277,10 @@ NXapm(NXobject): specimen(NXsample): exists: recommended method(NX_CHAR): - exists: recommended doc: | - A qualifier whether the sample is a real one - or a virtual one (in a computer simulation). + A qualifier whether the specimen is a real one or a virtual one. enumeration: [experiment, simulation] alias(NX_CHAR): - exists: recommended doc: | Given name an alias. Better use identifier and parent_identifier instead. A single NXentry should be used only for the characterization of a single specimen. @@ -349,6 +348,7 @@ NXapm(NXobject): Ideally measured otherwise best elaborated guess of the initial radius of the specimen. unit: NX_LENGTH shank_angle(NX_FLOAT): + exists: recommended doc: | Ideally measured otherwise best elaborated guess of the (initial) shank angle. This is a measure of the specimen taper. Define it in such a way that the base of the specimen @@ -419,14 +419,14 @@ NXapm(NXobject): instrument(NXinstrument): instrument_name(NX_CHAR): exists: optional - (NXfabrication): + fabrication(NXfabrication): vendor(NX_CHAR): model(NX_CHAR): identifier(NX_CHAR): exists: recommended reflectron(NXreflectron): status(NX_CHAR): - (NXfabrication): + fabrication(NXfabrication): exists: recommended vendor(NX_CHAR): model(NX_CHAR): @@ -434,25 +434,25 @@ NXapm(NXobject): local_electrode(NXlens_em): # add flat test status name(NX_CHAR): - (NXfabrication): + fabrication(NXfabrication): exists: recommended vendor(NX_CHAR): model(NX_CHAR): ion_detector(NXdetector): exists: recommended - (NXfabrication): + fabrication(NXfabrication): exists: recommended # for LEAP systems they come shipped configured vendor(NX_CHAR): model(NX_CHAR): pulser(NXpulser_apm): - (NXfabrication): + fabrication(NXfabrication): exists: recommended vendor(NX_CHAR): model(NX_CHAR): pulse_mode(NX_CHAR): - (NXsource): + sourceID(NXsource): exists: [min, 0, max, 2] # conditionally required if pulse_mode is not voltage! - (NXfabrication): + fabrication(NXfabrication): exists: recommended vendor(NX_CHAR): model(NX_CHAR): @@ -460,7 +460,7 @@ NXapm(NXobject): doc: | The wavelength of the radiation emitted by the source. unit: NX_WAVELENGTH - # use NXbeam in the future + # use NXbeam in the future # stage_lab(NXstage_lab): analysis_chamber(NXchamber): exists: recommended @@ -481,7 +481,7 @@ NXapm(NXobject): exists: optional # the case of allowing to not have event_data but only the above-mentioned instrument # details can be useful to convey details about an atom probe instrument in general - (NXevent_data_apm): + event_data_apm(NXevent_data_apm): exists: recommended # all these cannot be made required because for LEAP only stored in RHIT/HITS # but for M-TAP and Oxcart these pieces of information are available. @@ -582,12 +582,12 @@ NXapm(NXobject): exists: recommended sequence_index(NX_POSINT): exists: recommended - (NXprogram): + programID(NXprogram): exists: [min, 0, max, infty] program(NX_CHAR): \@version(NX_CHAR): # point at least to the proprietary artifact - (NXserialized): + serialized(NXserialized): exists: recommended type(NX_CHAR): path(NX_CHAR): @@ -603,12 +603,12 @@ NXapm(NXobject): # we can only make recommendations sequence_index(NX_POSINT): exists: recommended - (NXprogram): + programID(NXprogram): exists: [min, 0, max, infty] program(NX_CHAR): \@version(NX_CHAR): # config of the hit_finding algorithm - (NXserialized): + serialized(NXserialized): exists: recommended type(NX_CHAR): path(NX_CHAR): @@ -652,11 +652,11 @@ NXapm(NXobject): exists: recommended sequence_index(NX_POSINT): exists: recommended - (NXprogram): + programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): - (NXserialized): + serialized(NXserialized): exists: optional type(NX_CHAR): path(NX_CHAR): @@ -699,11 +699,11 @@ NXapm(NXobject): exists: recommended sequence_index(NX_POSINT): exists: recommended - (NXprogram): + programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): - (NXserialized): + serialized(NXserialized): exists: optional type(NX_CHAR): path(NX_CHAR): @@ -725,11 +725,11 @@ NXapm(NXobject): exists: recommended sequence_index(NX_POSINT): exists: recommended - (NXprogram): + programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): - (NXserialized): + serialized(NXserialized): exists: recommended type(NX_CHAR): path(NX_CHAR): @@ -744,7 +744,7 @@ NXapm(NXobject): exists: recommended sequence_index(NX_POSINT): exists: recommended - (NXprogram): + programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): @@ -818,11 +818,11 @@ NXapm(NXobject): exists: recommended sequence_index(NX_POSINT): exists: recommended - (NXprogram): + programID(NXprogram): exists: [min, 1, max, infty] - program: - \@version: - (NXserialized): + program(NX_CHAR): + \@version(NX_CHAR): + definitions(NXserialized): exists: recommended doc: | The respective ranging definitions file RNG/RRNG/ENV/HDF5. @@ -837,7 +837,7 @@ NXapm(NXobject): exists: recommended sequence_index(NX_POSINT): exists: recommended - (NXprogram): + programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): @@ -860,7 +860,7 @@ NXapm(NXobject): exists: recommended sequence_index(NX_POSINT): exists: recommended - (NXprogram): + programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): @@ -889,11 +889,11 @@ NXapm(NXobject): exists: recommended sequence_index(NX_POSINT): exists: recommended - (NXprogram): + programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): - (NXpeak): + peakID(NXpeak): exists: [min, 0, max, infty] label(NX_CHAR): exists: recommended @@ -922,7 +922,7 @@ NXapm(NXobject): exists: recommended sequence_index(NX_POSINT): exists: recommended - (NXprogram): + programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): From 5a57246fb1ca0e8841ae677962e0b06c645363b2 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 20 Mar 2024 22:10:10 +0100 Subject: [PATCH 0633/1012] Minor modification charge_state_analysis --- .../NXapm_charge_state_analysis.nxdl.xml | 8 ++++---- .../nyaml/NXapm_charge_state_analysis.yaml | 8 ++++---- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml b/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml index 0ad7d4d6ab..6c8799d655 100644 --- a/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml +++ b/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml @@ -64,10 +64,10 @@ input/config--> Input constraint, list of proton numbers for each element of the ranging definition. The list contains each element as many times as its multiplicity. As an example a ranging definition H:2 O:1 demands element vector - to be 1, 1, 8. An empty list does not release the constraint. - Instead, a list with all elements in the periodic table should be - used. Keep in mind though with such a weakly constrained parameter space - the combinatorial analysis may become very time consuming! + to be 1, 1, 8. An empty list does not release the constraint. Instead, a list + with all elements in the periodic table should be used. Keep in mind though + that with such a weakly constrained parameter space the combinatorial + analysis may become very time consuming! diff --git a/contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml b/contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml index 584a397a1f..8bf62a6995 100644 --- a/contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml +++ b/contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml @@ -34,10 +34,10 @@ NXapm_charge_state_analysis(NXprocess): Input constraint, list of proton numbers for each element of the ranging definition. The list contains each element as many times as its multiplicity. As an example a ranging definition H:2 O:1 demands element vector - to be 1, 1, 8. An empty list does not release the constraint. - Instead, a list with all elements in the periodic table should be - used. Keep in mind though with such a weakly constrained parameter space - the combinatorial analysis may become very time consuming! + to be 1, 1, 8. An empty list does not release the constraint. Instead, a list + with all elements in the periodic table should be used. Keep in mind though + that with such a weakly constrained parameter space the combinatorial + analysis may become very time consuming! unit: NX_UNITLESS dim: (i,) mass_to_charge_range(NX_FLOAT): From c72643416ca2a90b674d61a6f76c0ac5371cd842 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Mon, 25 Mar 2024 19:10:17 +0100 Subject: [PATCH 0634/1012] support UPPER anywhere; fix get_hdf_info_parent and get_xml_root --- dev_tools/utils/nxdl_utils.py | 69 ++++++++++++++++++++++------------- 1 file changed, 44 insertions(+), 25 deletions(-) diff --git a/dev_tools/utils/nxdl_utils.py b/dev_tools/utils/nxdl_utils.py index be8262fdfc..6e8691d373 100644 --- a/dev_tools/utils/nxdl_utils.py +++ b/dev_tools/utils/nxdl_utils.py @@ -3,6 +3,7 @@ """ import os +import re import textwrap from functools import lru_cache from glob import glob @@ -56,7 +57,7 @@ def get_app_defs_names(): def get_xml_root(file_path): """Reducing I/O time by caching technique""" - return ET.parse(file_path).getroot() + return ET.parse(str(file_path)).getroot() def get_hdf_root(hdf_node): @@ -90,7 +91,13 @@ def get_hdf_info_parent(hdf_info): """Get the hdf_info for the parent of an hdf_node in an hdf_info""" if "hdf_path" not in hdf_info: return {"hdf_node": hdf_info["hdf_node"].parent} - node = get_hdf_parent(hdf_info) + node = ( + get_hdf_root(hdf_info["hdf_node"]) + if "hdf_root" not in hdf_info + else hdf_info["hdf_root"] + ) + for child_name in hdf_info["hdf_path"].split("/")[1:-1]: + node = node[child_name] return {"hdf_node": node, "hdf_path": get_parent_path(hdf_info["hdf_path"])} @@ -102,32 +109,41 @@ def get_nx_class(nxdl_elem): def get_nx_namefit(hdf_name, name, name_any=False): - """Checks if an HDF5 node name corresponds to a child of the NXDL element - uppercase letters in front can be replaced by arbitrary name, but - uppercase to lowercase match is preferred, - so such match is counted as a measure of the fit""" + """ + Checks if an HDF5 node name corresponds to a child of the NXDL element. + A group of uppercase letters anywhere can be replaced by an arbitrary name. + + Args: + hdf_name (str): The hdf_name, containing uppercase parts. + name (str): The string to match against hdf_name. + name_any (bool, optional): + Accept any name and just return the matching characters. + Defaults to False. + + Returns: + int: + -1 if no match is found or the number of matching + characters (case insensitive) between for all uppercase groups. + """ if name == hdf_name: return len(name) * 2 - # count leading capitals - counting = 0 - while counting < len(name) and name[counting].isupper(): - counting += 1 - if ( - name_any - or counting == len(name) - or (counting > 0 and hdf_name.endswith(name[counting:])) - ): # if potential fit - # count the matching chars - fit = 0 - for i in range(min(counting, len(hdf_name))): - if hdf_name[i].upper() == name[i]: + + uppercase_parts = re.findall("[A-Z]+(?:_[A-Z]+)*", name) + + for up in uppercase_parts: + name = name.replace(up, r"([a-zA-Z0-9_]+)") + + name_match = re.search(rf"^{name}$", hdf_name) + if name_match is None: + return 0 if name_any else -1 + + fit = 0 + for up, low in zip(uppercase_parts, name_match.groups()): + for i in range(min(len(up), len(low))): + if up[i].lower() == low[i]: fit += 1 - else: - break - if fit == min(counting, len(hdf_name)): # accept only full fits as better fits - return fit - return 0 - return -1 # no fit + + return fit def get_nx_classes(): @@ -819,6 +835,9 @@ def get_node_at_nxdl_path( we are looking for or the root elem from a previously loaded NXDL file and finds the corresponding XML element with the needed attributes.""" try: + if nxdl_path.count("/") == 1 and not nxdl_path.upper().startswith("/ENTRY"): + elem = None + nx_name = "NXroot" (class_path, nxdlpath, elist) = get_inherited_nodes(nxdl_path, nx_name, elem) except ValueError as value_error: if exc: From c880e390ddd62ef92a09dcb307681d357e6bb913 Mon Sep 17 00:00:00 2001 From: Sandor Brockhauser Date: Mon, 25 Mar 2024 20:05:55 +0100 Subject: [PATCH 0635/1012] revert unnecessary change in get_xml_root --- dev_tools/utils/nxdl_utils.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dev_tools/utils/nxdl_utils.py b/dev_tools/utils/nxdl_utils.py index 6e8691d373..632ba37225 100644 --- a/dev_tools/utils/nxdl_utils.py +++ b/dev_tools/utils/nxdl_utils.py @@ -57,7 +57,7 @@ def get_app_defs_names(): def get_xml_root(file_path): """Reducing I/O time by caching technique""" - return ET.parse(str(file_path)).getroot() + return ET.parse(file_path).getroot() def get_hdf_root(hdf_node): From 177e48668301f0c3992e54256399befead5a86a1 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 27 Mar 2024 13:54:53 +0100 Subject: [PATCH 0636/1012] Fix #203, #204 --- .../NXapm_paraprobe_nanochem_config.nxdl.xml | 3 +-- .../NXapm_paraprobe_nanochem_results.nxdl.xml | 16 ++++++++-------- .../nyaml/NXapm_paraprobe_nanochem_config.yaml | 2 +- .../nyaml/NXapm_paraprobe_nanochem_results.yaml | 2 +- 4 files changed, 11 insertions(+), 12 deletions(-) diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml index 6334cb3869..02a508b03a 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml @@ -291,8 +291,7 @@ identifier(NX_UINT):--> or the concentration of the ions/elements specified by the nuclide_whitelist. - - + diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml index 8e4bdaaceb..64ebdf5501 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml @@ -979,15 +979,15 @@ face_identifier_offset(NX_UINT):--> The equation of the plane that is fitted initially. + + + The four parameter :math:`ax + by + cz + d = 0` which define the plane. + + + + + - - - The four parameter :math:`ax + by + cz + d = 0` which define the plane. - - - - - The triangle surface mesh representing the interface model. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml index 56de80f70b..cd2ae20fe4 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml @@ -211,7 +211,7 @@ NXapm_paraprobe_nanochem_config(NXobject): By default, the tool computes the total number (intensity) of ions or elements. Alternatively, the tool can compute the total intensity, the composition, or the concentration of the ions/elements specified by the nuclide_whitelist. - enumeration: [total, candidates, composition, concentration] + enumeration: [none, composition, concentration] has_scalar_fields(NX_BOOLEAN): doc: | Specifies if the tool should report the delocalization 3D field values. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml index 190757f29e..f17638297c 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml @@ -700,7 +700,7 @@ NXapm_paraprobe_nanochem_results(NXobject): exists: optional doc: | The equation of the plane that is fitted initially. - point_normal_form(NX_FLOAT): + point_normal_form(NX_FLOAT): unit: NX_LENGTH doc: | The four parameter :math:`ax + by + cz + d = 0` which define the plane. From 17f71693e6ee5614d371a530b20e538e2c98b86d Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 27 Mar 2024 14:28:15 +0100 Subject: [PATCH 0637/1012] Reverted entryID in NXapm because of which NXentry instances were not autodecorated --- contributed_definitions/NXapm.nxdl.xml | 37 ++++++++++++++----- .../NXapm_charge_state_analysis.nxdl.xml | 20 ++++++---- contributed_definitions/NXem.nxdl.xml | 16 +++++--- contributed_definitions/nyaml/NXapm.yaml | 29 +++++++++++---- .../nyaml/NXapm_charge_state_analysis.yaml | 20 ++++++---- contributed_definitions/nyaml/NXem.yaml | 14 +++++-- dev_tools/tests/test_nxdl_utils.py | 2 +- 7 files changed, 98 insertions(+), 40 deletions(-) diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index f2813092bf..8213a54912 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -47,7 +47,7 @@ Application definition for atom probe and field ion microscopy experiments. - + @@ -56,7 +56,7 @@ - The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) + The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_ or its plugins) which was used to generate this NeXus file instance. @@ -114,9 +114,26 @@ cannot be made required as for simulations you do not have a run number! should be stored as individual :ref:`NXentry` instances in one NeXus file. - - + Set to hold different coordinate systems conventions. Inspect the description of the :ref:`NXcoordinate_system_set` @@ -1061,7 +1080,7 @@ in an e.g. work of A. London et al.--> - + diff --git a/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml b/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml index 6c8799d655..e942c37b21 100644 --- a/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml +++ b/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml @@ -59,14 +59,20 @@ to clarify (if possible) the charge_state of an ion and its (not necessarily) unique combination of nuclides contained including their multiplicity. input/config--> - + - Input constraint, list of proton numbers for each element of the ranging - definition. The list contains each element as many times as its multiplicity. - As an example a ranging definition H:2 O:1 demands element vector - to be 1, 1, 8. An empty list does not release the constraint. Instead, a list - with all elements in the periodic table should be used. Keep in mind though - that with such a weakly constrained parameter space the combinatorial + Input constraint, list of nuclide_hash for typically elements used for the + ranging definition of the ion whose charge state the analyses covered. + The list contains each hash as many times as its multiplicity. + Nuclides are encoded using the hashing rule that is defined in :ref:`NXion`. + + As an example, a ranging definition H:2 O:1 is configured by setting nuclides to + a list with entries :math:`1 + 256 * 0`, :math:`1 + 256 * 0`, :math:`8 + 256 * 0`. + An empty list does not release the constraint. Instead, a list with all elements + in the periodic table (encoded as nuclide_hash values) should be used, i.e. + :math:`1 + 256 * 0`, :math:`2 + 256 * 0`, and so on and so forth. + + Keep in mind that with a weakly constrained parameter space the combinatorial analysis may become very time consuming! diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index bb45ab5539..63dbd6f626 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -44,7 +44,7 @@ \@default(NX_CHAR):--> - + @@ -53,12 +53,12 @@ however as there are cases when this cannot be assured we cannot make the default required, one example is e.g. a NeXus instance where scientists just store conventions without a default plot--> - + - The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_) + The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_ or its plugins) which was used to generate this NeXus file instance. - + A collection of all programs and libraries which are considered relevant @@ -360,7 +360,13 @@ are the ibeam description capabilities not sufficient enough?--> - + + + Set to hold different coordinate systems conventions. + Inspect the description of the :ref:`NXcoordinate_system_set` + and :ref:`NXcoordinate_system` base classes how to define + coordinate systems in NeXus. + diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml index 87773339eb..39c6ecb4a9 100644 --- a/contributed_definitions/nyaml/NXapm.yaml +++ b/contributed_definitions/nyaml/NXapm.yaml @@ -17,7 +17,7 @@ symbols: the pulse_identifier. type: group NXapm(NXobject): - entryID(NXentry): + (NXentry): # entryID exists: [min, 1, max, infty] definition(NX_CHAR): \@version(NX_CHAR): @@ -26,7 +26,7 @@ NXapm(NXobject): profiling(NXcs_profiling): exists: optional doc: | - The configuration of the I/O writer software (e.g. `pynxtools `_) + The configuration of the I/O writer software (e.g. `pynxtools `_ or its plugins) which was used to generate this NeXus file instance. # command_line_call(NX_CHAR): programID(NXprogram): # understood by default as PROGRAM(NXprogram), i.e. program1, program2, ... @@ -77,8 +77,22 @@ NXapm(NXobject): needs to be distinguished with different run numbers. We follow this habit of most atom probe groups. Such interrupted runs should be stored as individual :ref:`NXentry` instances in one NeXus file. - # alias experiment_alias - # experiment_description(NX_CHAR): + experiment_alias(NX_CHAR): + doc: | + Either an identifier or an alias that is human-friendly so that scientists find that experiment again. + For experiments usually this is the run_number but for simulation typically no run_numbers are issued. + experiment_description(NX_CHAR): + exists: optional + doc: | + Free-text description about the experiment. + + Users are strongly advised to parameterize the description of their experiment + by using respective groups and fields and base classes instead of writing prose + into this field. + + The reason is that such free-text field is difficult to machine-interpret. + The motivation behind keeping this field for now is to learn in how far the + current base classes need extension based on user feedback. # optional quantities do not need to be mentioned in an appdef because they can always be added # if NXapm inherits from NXapm_base having this optional field does not need to be # mentioned because optional nodes can always be added to a NeXus file instance without @@ -133,6 +147,8 @@ NXapm(NXobject): to LEAP systems (see `S. Katnagallu et al. `_). * other should be used in combination with the user specifying details in the experiment_documentation field. + + If NXapm is used for storing details about a simulation use other for now. enumeration: [apt, fim, apt_fim, other] (NXuser): exists: recommended @@ -275,12 +291,12 @@ NXapm(NXobject): Magnitude of the standard deviation of the composition (value). unit: NX_DIMENSIONLESS specimen(NXsample): - exists: recommended method(NX_CHAR): doc: | A qualifier whether the specimen is a real one or a virtual one. enumeration: [experiment, simulation] alias(NX_CHAR): + exists: recommended doc: | Given name an alias. Better use identifier and parent_identifier instead. A single NXentry should be used only for the characterization of a single specimen. @@ -357,7 +373,6 @@ NXapm(NXobject): unit: NX_ANGLE # describing the geometry of the specimen coordinate_system_set(NXcoordinate_system_set): - exists: recommended doc: | Set to hold different coordinate systems conventions. Inspect the description of the :ref:`NXcoordinate_system_set` @@ -933,7 +948,7 @@ NXapm(NXobject): charge_state_analysis(NXapm_charge_state_analysis): exists: optional # config - element(NX_UINT): + nuclides(NX_UINT): mass_to_charge_range(NX_FLOAT): min_half_life(NX_FLOAT): min_abundance(NX_FLOAT): diff --git a/contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml b/contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml index 8bf62a6995..1d98d9c6f7 100644 --- a/contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml +++ b/contributed_definitions/nyaml/NXapm_charge_state_analysis.yaml @@ -29,14 +29,20 @@ NXapm_charge_state_analysis(NXprocess): # to clarify (if possible) the charge_state of an ion and its (not necessarily) # unique combination of nuclides contained including their multiplicity. # input/config - element(NX_UINT): + nuclides(NX_UINT): doc: | - Input constraint, list of proton numbers for each element of the ranging - definition. The list contains each element as many times as its multiplicity. - As an example a ranging definition H:2 O:1 demands element vector - to be 1, 1, 8. An empty list does not release the constraint. Instead, a list - with all elements in the periodic table should be used. Keep in mind though - that with such a weakly constrained parameter space the combinatorial + Input constraint, list of nuclide_hash for typically elements used for the + ranging definition of the ion whose charge state the analyses covered. + The list contains each hash as many times as its multiplicity. + Nuclides are encoded using the hashing rule that is defined in :ref:`NXion`. + + As an example, a ranging definition H:2 O:1 is configured by setting nuclides to + a list with entries :math:`1 + 256 * 0`, :math:`1 + 256 * 0`, :math:`8 + 256 * 0`. + An empty list does not release the constraint. Instead, a list with all elements + in the periodic table (encoded as nuclide_hash values) should be used, i.e. + :math:`1 + 256 * 0`, :math:`2 + 256 * 0`, and so on and so forth. + + Keep in mind that with a weakly constrained parameter space the combinatorial analysis may become very time consuming! unit: NX_UNITLESS dim: (i,) diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index 5c3aef5d7e..b71dcbe06d 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -24,17 +24,18 @@ NXem(NXobject): exists: [min, 1, max, infty] definition(NX_CHAR): \@version(NX_CHAR): + exists: optional enumeration: [NXem] # each NeXus file instance should have a default plot # however as there are cases when this cannot be assured we cannot # make the default required, one example is e.g. a NeXus instance # where scientists just store conventions without a default plot profiling(NXcs_profiling): - exists: recommended + exists: optional doc: | - The configuration of the I/O writer software (e.g. `pynxtools `_) + The configuration of the I/O writer software (e.g. `pynxtools `_ or its plugins) which was used to generate this NeXus file instance. - command_line_call(NX_CHAR): + # command_line_call(NX_CHAR): (NXprogram): # understood by default as PROGRAM(NXprogram), i.e. program1, program2, ... doc: | A collection of all programs and libraries which are considered relevant @@ -298,8 +299,13 @@ NXem(NXobject): Discouraged free-text field to provide further detail although adding parent_identifier and having a working research data management system should provide this contextualization. - (NXcoordinate_system_set): + coordinate_system_set(NXcoordinate_system_set): exists: [min, 1, max, 1] + doc: | + Set to hold different coordinate systems conventions. + Inspect the description of the :ref:`NXcoordinate_system_set` + and :ref:`NXcoordinate_system` base classes how to define + coordinate systems in NeXus. (NXcoordinate_system): exists: [min, 1, max, infty] origin(NX_CHAR): diff --git a/dev_tools/tests/test_nxdl_utils.py b/dev_tools/tests/test_nxdl_utils.py index 69559d52fb..3ca12e36e1 100644 --- a/dev_tools/tests/test_nxdl_utils.py +++ b/dev_tools/tests/test_nxdl_utils.py @@ -96,7 +96,7 @@ def test_get_node_at_nxdl_path(): ) assert node.attrib["type"] == "NX_NUMBER" - node = nexus.get_node_at_nxdl_path("/ENTRY/COORDINATE_SYSTEM_SET", elem=elem) + node = nexus.get_node_at_nxdl_path("/ENTRY/coordinate_system_set", elem=elem) assert node.attrib["type"] == "NXcoordinate_system_set" nxdl_file_path = os.path.join( From 6d03133490d7a853b9dda783bc38453319ee34eb Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 2 Apr 2024 10:56:16 +0200 Subject: [PATCH 0638/1012] additions to NXsource and NXdeflector --- base_classes/NXsource.nxdl.xml | 41 +++++- base_classes/nyaml/NXsource.yaml | 70 +++++++++-- contributed_definitions/NXdeflector.nxdl.xml | 12 ++ .../nyaml/NXdeflector.yaml | 118 +++++++++++++++++- 4 files changed, 227 insertions(+), 14 deletions(-) diff --git a/base_classes/NXsource.nxdl.xml b/base_classes/NXsource.nxdl.xml index 2bf30550d3..5a2077298b 100644 --- a/base_classes/NXsource.nxdl.xml +++ b/base_classes/NXsource.nxdl.xml @@ -113,9 +113,9 @@ - Source energy. - For storage rings, this would be the particle beam energy. - For X-ray tubes, this would be the excitation voltage. + Source energy. Typically, this would be the energy of + the emitted beam. For storage rings, this would be + the particle beam energy. @@ -245,11 +245,46 @@ by the pulse duration + + + Material of the anode (for X-ray tubes). + + + + + Filament current (for X-ray tubes). + + + + + Emission current of the generated beam. + + + + + Gas pressure inside ionization source. + + "Engineering" location of source. + + + The size and position of an aperture inside the source. + + + + + Deflectors inside the source. + + + + + Individual electromagnetic lenses inside the source. + + diff --git a/base_classes/nyaml/NXsource.yaml b/base_classes/nyaml/NXsource.yaml index be5527c006..a15ad5e7e4 100644 --- a/base_classes/nyaml/NXsource.yaml +++ b/base_classes/nyaml/NXsource.yaml @@ -53,9 +53,9 @@ NXsource(NXobject): energy(NX_FLOAT): unit: NX_ENERGY doc: | - Source energy. - For storage rings, this would be the particle beam energy. - For X-ray tubes, this would be the excitation voltage. + Source energy. Typically, this would be the energy of + the emitted beam. For storage rings, this would be + the particle beam energy. current(NX_FLOAT): unit: NX_CURRENT doc: | @@ -145,11 +145,32 @@ NXsource(NXobject): doc: | For pulsed sources, the pulse energy divided by the pulse duration + anode_material: + doc: | + Material of the anode (for X-ray tubes). + filament_current(NX_FLOAT): + doc: | + Filament current (for X-ray tubes). + emission_current(NX_FLOAT): + doc: | + Emission current of the generated beam. + gas_pressure(NX_FLOAT): + doc: | + Gas pressure inside ionization source. geometry(NXgeometry): deprecated: | Use the field `depends_on` and :ref:`NXtransformations` to position the source and NXoff_geometry to describe its shape instead doc: | "Engineering" location of source. + (NXaperture): + doc: | + The size and position of an aperture inside the source. + (NXdeflector): + doc: | + Deflectors inside the source. + (NXlens_em): + doc: | + Individual electromagnetic lenses inside the source. (NXfabrication): (NXoff_geometry): exists: ['min', '0'] @@ -191,7 +212,7 @@ NXsource(NXobject): other component groups. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 45f1f3aa580c93a57ab6b7b0f301f8e4b91e19c36f63e65109da961f88402285 +# adecbe1ee83c23125e44451d029bbe1b3437f6cd840150ced711f13a74478b92 # # # +# +# +# Deflectors as they are used e.g. in an electron analyser. +# +# +# +# Qualitative type of deflector with respect to the number of pole pieces. +# +# +# +# +# +# +# +# +# +# +# Colloquial or short name for the deflector. For manufacturer names and +# identifiers use respective manufacturer fields. +# +# +# +# +# +# Ideally an identifier, persistent link, or free text which gives +# further details about the deflector. +# +# +# +# +# Excitation voltage of the deflector. For dipoles it is a single number. +# For higher order multipoles, it is an array. +# +# +# +# +# Excitation current of the deflector. For dipoles it is a single number. For +# higher orders, it is an array. +# +# +# +# +# Spatial offset of the deflector in x direction (perpendicular to +# ```offset_y```). +# +# +# +# +# Spatial offset of the deflector in y direction (perpendicular to +# ```offset_x```). +# +# +# +# +# Specifies the position of the deflector by pointing to the last transformation +# in the transformation chain in the NXtransformations group. +# +# +# +# +# +# Collection of axis-based translations and rotations to describe the location and +# geometry of the deflector as a component in the instrument. Conventions from the +# :ref:`NXtransformations` base class are used. In principle, the McStas coordinate +# 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. +# +# +# From e4196987cc915b41dfaf4c9bc6f6e057b73d936b Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 2 Apr 2024 14:27:30 +0200 Subject: [PATCH 0639/1012] make some fields in NXmpes recommended instead of required --- contributed_definitions/NXmpes.nxdl.xml | 12 ++--------- contributed_definitions/nyaml/NXmpes.yaml | 25 +++++------------------ 2 files changed, 7 insertions(+), 30 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 24db440d0d..0b0472fc06 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -78,7 +78,7 @@ .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 - + Description of one or more coordinate systems that are specific to the setup and the measurement geometry. @@ -133,7 +133,6 @@ .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 - Ratio of the energy resolution of the photoemission spectrometer at a specified energy @@ -229,7 +228,7 @@ - + @@ -788,13 +787,6 @@ - - Calibrated energy axis. - - This could be a link to either - /entry/process/energy_calibration/calibrated_axis or - /entry/process/energy_correction/calibrated_axis. - diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 9614c472a7..601a53a9da 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -50,6 +50,7 @@ NXmpes(NXobject): .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 geometries(NXcoordinate_system_set): + exists: optional doc: | Description of one or more coordinate systems that are specific to the setup and the measurement geometry. @@ -100,9 +101,6 @@ NXmpes(NXobject): spec: ISO 18115-1:2023 term: 10.24 url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 - resolution_errors(NX_FLOAT): - exists: optional - unit: NX_ENERGY relative_resolution(NX_FLOAT): exists: optional doc: @@ -192,6 +190,7 @@ NXmpes(NXobject): identifier: exists: recommended description: + exists: recommended energy_resolution(NXresolution): exists: optional type: @@ -691,12 +690,6 @@ NXmpes(NXobject): delay, spin index, temperature, etc. The axes traces should be linked to the actual encoder position in NXinstrument or calibrated axes in NXprocess. energy(NX_NUMBER): - doc: | - Calibrated energy axis. - - This could be a link to either - /entry/process/energy_calibration/calibrated_axis or - /entry/process/energy_correction/calibrated_axis. \@type: exists: recommended \@energy_depends: @@ -710,7 +703,7 @@ NXmpes(NXobject): @energy_depends: 'entry/process/energy_calibration' # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 9092a8da392c0e68b6936a9670c405812e0efff35411bc0cdf645246acb796df +# 204be34db7933cefb131e639aa03ef71a29477a058fd289b4fc3964903a44e04 # # # - Analysis of one-dimensional profiles in ROIs placed in the dataset. Such analyses are useful for quantifying - interfacial excess or classical composition analyses. The tool will test for each ROIs if it is completely embedded - in the dataset. Specifically, in each such test the tool evaluates if the ROI cuts at least one triangle of the triangulated surface mesh refered to by surface. If this is the case the ROI is close to the surface and not analyzed further. - Otherwise, the ROI is processed further. + Analysis of one-dimensional profiles in ROIs placed in the dataset. + Such analyses are useful for quantifying interfacial excess or for + performing classical composition analyses. - Users should be aware that the latter intersection analysis is not a volumetric intersection analysis as such one - is much more computationally involved because the edge model can be a closed non-convex polyhedron - in which case one would have to test robustly if the cylinder pierces or is laying completely inside the polyhedron. - For this the polyhedron has to be tessellated first into convex polyhedra, as test for volumetric intersection using - the Gilbert-Johnson-Keerthi algorithm (GJK) are applicable only to convex polyhedra. + The tool will test for each ROIs if it is completely embedded in the dataset. + Specifically, each such test evaluates if the ROI cuts at least one triangle + of the triangulated surface mesh that is referred to by surface. + If this is the case the ROI is marked as one close to the surface + and not analyzed further. Otherwise, the ROI is marked as one far + from the surface and processed further. - For each ROI the tool computes atomically decomposed profiles. This means, molecular ions are split into - nuclides with respective multiplicity. For each processed ROI a set of a sorted list of signed distance values - is returned to enable classical Krakauer/Seidman-style interfacial excess analyses. + For each ROI the tool computes atomically decomposed profiles. + This means, molecular ions are splitted into nuclides as many times as + their respective multiplicity. For each processed ROI the tool stores + a sorted list of signed distance values to enable post-processing with + other software like e.g. reporter to perform classical + Krakauer/Seidman-style interfacial excess analyses. + + Users should be aware that the latter intersection analysis is not + a volumetric intersection analysis. Given that the triangulated mesh + referred to in surface is not required to mesh neither a watertight + nor convex polyhedron a rigorous testing of volumetric intersection + is much more involved. If the mesh is watertight one could use split + the task in first tessellating the mesh into convex polyhedra (e.g. + tetrahedra and apply a volumetric intersection method like the + Gilbert-Johnson-Keerthi algorithm (GJK). In cases when the mesh is not + even watertight distance-based segmentation in combination with again + intersection of triangles and convex polyhedra is a robust but currently + not implemented method to quantify intersections. @@ -833,7 +848,9 @@ identifier(NX_UINT):--> A precomputed triangulated mesh of the feature representing a model of the - interface at which to place ROIs to profile. + interface at which to place ROIs to profile. This can be the mesh of an + interface as returned e.g. by a previous interface_meshing task or the + mesh of an iso-surface from a previous delocalization task. @@ -875,6 +892,11 @@ from normals of neighboring facets, type of weighting schemes can affect results + + To enable an additional filtration of specific parts of the feature + mesh it is recommended to feed precomputed distances of each ion to + the triangles of the feature mesh. + @@ -936,6 +958,39 @@ identifier(NX_UINT):--> + + + As an alternative mode the tool can be instructed to place ROIs + at specific locations into the dataset. This is the programmatic + equivalent to the classical approach in atom probe to place ROIs + for composition analyses via positioning and rotating them via + a graphical user interface (such as in IVAS / AP Suite). + + + + + + + + + + + + + + + + + + + + + + + + Which type of distance should be reported for the profile. @@ -946,49 +1001,24 @@ identifier(NX_UINT):--> - In which directions should the tool probe for each ROI. + For each ROI, along which direction should the cylindrical ROI + be oriented if ROIs are placed at triangles of the feature mesh. - - - Explicit x, y, z coordinates (in the paraprobe coordinate system) where ROIs - should be placed if feature is absent. - - - - - - - - - Explicit outer unit normal which explains into which direction each cylinder ROI - is oriented. - - - - - - - - For each ROI, how high (projected on the cylinder axis) should the cylindrical ROI be. - - If roi_cylinder_center and roi_cylinder_orientation have been defined, roi_cylinder_height - and roi_cylinder_radius can be defined as arrays of size (n_rois,) to instruct the tool to - place a collection of ROIs with different size. - Otherwise, roi_cylinder_height and roi_cylinder_radius have to be a scalars. + For each ROI, how high (projected onto the cylinder axis) should + the cylindrical ROI be if ROIs are placed at triangles + of the feature mesh. - For each ROI, how wide (radius) should the cylindrical ROI be. + For each ROI, how wide (in radius) should the cylindrical ROI + be if ROIs are placed at triangles of the feature mesh. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml index cd2ae20fe4..5992f224a0 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml @@ -598,20 +598,35 @@ NXapm_paraprobe_nanochem_config(NXobject): oned_profile(NXapm_paraprobe_tool_config): exists: [min, 0, max, 1] doc: | - Analysis of one-dimensional profiles in ROIs placed in the dataset. Such analyses are useful for quantifying - interfacial excess or classical composition analyses. The tool will test for each ROIs if it is completely embedded - in the dataset. Specifically, in each such test the tool evaluates if the ROI cuts at least one triangle of the triangulated surface mesh refered to by surface. If this is the case the ROI is close to the surface and not analyzed further. - Otherwise, the ROI is processed further. + Analysis of one-dimensional profiles in ROIs placed in the dataset. + Such analyses are useful for quantifying interfacial excess or for + performing classical composition analyses. - Users should be aware that the latter intersection analysis is not a volumetric intersection analysis as such one - is much more computationally involved because the edge model can be a closed non-convex polyhedron - in which case one would have to test robustly if the cylinder pierces or is laying completely inside the polyhedron. - For this the polyhedron has to be tessellated first into convex polyhedra, as test for volumetric intersection using - the Gilbert-Johnson-Keerthi algorithm (GJK) are applicable only to convex polyhedra. + The tool will test for each ROIs if it is completely embedded in the dataset. + Specifically, each such test evaluates if the ROI cuts at least one triangle + of the triangulated surface mesh that is referred to by surface. + If this is the case the ROI is marked as one close to the surface + and not analyzed further. Otherwise, the ROI is marked as one far + from the surface and processed further. - For each ROI the tool computes atomically decomposed profiles. This means, molecular ions are split into - nuclides with respective multiplicity. For each processed ROI a set of a sorted list of signed distance values - is returned to enable classical Krakauer/Seidman-style interfacial excess analyses. + For each ROI the tool computes atomically decomposed profiles. + This means, molecular ions are splitted into nuclides as many times as + their respective multiplicity. For each processed ROI the tool stores + a sorted list of signed distance values to enable post-processing with + other software like e.g. reporter to perform classical + Krakauer/Seidman-style interfacial excess analyses. + + Users should be aware that the latter intersection analysis is not + a volumetric intersection analysis. Given that the triangulated mesh + referred to in surface is not required to mesh neither a watertight + nor convex polyhedron a rigorous testing of volumetric intersection + is much more involved. If the mesh is watertight one could use split + the task in first tessellating the mesh into convex polyhedra (e.g. + tetrahedra and apply a volumetric intersection method like the + Gilbert-Johnson-Keerthi algorithm (GJK). In cases when the mesh is not + even watertight distance-based segmentation in combination with again + intersection of triangles and convex polyhedra is a robust but currently + not implemented method to quantify intersections. (NXidentifier): exists: optional analysis_identifier(NX_UINT): @@ -663,7 +678,9 @@ NXapm_paraprobe_nanochem_config(NXobject): feature(NXserialized): doc: | A precomputed triangulated mesh of the feature representing a model of the - interface at which to place ROIs to profile. + interface at which to place ROIs to profile. This can be the mesh of an + interface as returned e.g. by a previous interface_meshing task or the + mesh of an iso-surface from a previous delocalization task. type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): @@ -693,6 +710,10 @@ NXapm_paraprobe_nanochem_config(NXobject): match(NX_NUMBER): feature_distance(NXserialized): exists: recommended + doc: | + To enable an additional filtration of specific parts of the feature + mesh it is recommended to feed precomputed distances of each ion to + the triangles of the feature mesh. type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): @@ -750,37 +771,45 @@ NXapm_paraprobe_nanochem_config(NXobject): method(NX_CHAR): match(NX_NUMBER): # config + user_defined_roi(NXobject): + exists: optional + doc: | + As an alternative mode the tool can be instructed to place ROIs + at specific locations into the dataset. This is the programmatic + equivalent to the classical approach in atom probe to place ROIs + for composition analyses via positioning and rotating them via + a graphical user interface (such as in IVAS / AP Suite). + cylinder_set(NXcg_cylinder_set): + # dimensionality(NX_POSINT): + # cardinality(NX_POSINT): + identifier_offset(NX_INT): + center(NX_NUMBER): + dim: (n_rois, 3) + height(NX_NUMBER): + dim: (n_rois, 3) + radii(NX_NUMBER): + dim: (n_rois,) + # could add other shapes in the future if necessary + # but cylinders are most frequently used distancing_model(NX_CHAR): doc: | Which type of distance should be reported for the profile. enumeration: [project_to_triangle_plane] # ion_to_feature roi_orientation(NX_CHAR): doc: | - In which directions should the tool probe for each ROI. + For each ROI, along which direction should the cylindrical ROI + be oriented if ROIs are placed at triangles of the feature mesh. enumeration: [triangle_outer_unit_normal] # angularly_geodesic_sphere - roi_cylinder_center(NX_FLOAT): - doc: | - Explicit x, y, z coordinates (in the paraprobe coordinate system) where ROIs should be placed if feature is absent. - unit: NX_LENGTH - dim: (n_rois, 3) - roi_cylinder_orientation(NX_FLOAT): - doc: | - Explicit outer unit normal which explains into which direction each cylinder ROI is oriented. - unit: NX_LENGTH - dim: (n_rois, 3) roi_cylinder_height(NX_FLOAT): doc: | - For each ROI, how high (projected on the cylinder axis) should the cylindrical ROI be. - - If roi_cylinder_center and roi_cylinder_orientation have been defined, roi_cylinder_height - and roi_cylinder_radius can be defined as arrays of size (n_rois,) to instruct the tool to - place a collection of ROIs with different size. - Otherwise, roi_cylinder_height and roi_cylinder_radius have to be a scalars. - # not yet implemented the case to have ROIs of different size for each triangle of the feature mesh + For each ROI, how high (projected onto the cylinder axis) should + the cylindrical ROI be if ROIs are placed at triangles + of the feature mesh. unit: NX_LENGTH roi_cylinder_radius(NX_FLOAT): doc: | - For each ROI, how wide (radius) should the cylindrical ROI be. + For each ROI, how wide (in radius) should the cylindrical ROI + be if ROIs are placed at triangles of the feature mesh. unit: NX_LENGTH common(NXapm_paraprobe_tool_common): From ecead6a4ebb1fa6b9fd90d7212e89ff48f35954e Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Wed, 3 Apr 2024 21:53:02 +0200 Subject: [PATCH 0641/1012] Slight modification of configuration to reflect the decisions made during the implementation of this functionality --- .../NXapm_paraprobe_nanochem_config.nxdl.xml | 4 ++-- .../nyaml/NXapm_paraprobe_nanochem_config.yaml | 3 ++- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml index 07b3e14ca6..08a2b878ba 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml @@ -845,7 +845,7 @@ identifier(NX_UINT):--> - + A precomputed triangulated mesh of the feature representing a model of the interface at which to place ROIs to profile. This can be the mesh of an @@ -891,7 +891,7 @@ from normals of neighboring facets, type of weighting schemes can affect results - + To enable an additional filtration of specific parts of the feature mesh it is recommended to feed precomputed distances of each ion to diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml index 5992f224a0..793c0c7114 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_config.yaml @@ -676,6 +676,7 @@ NXapm_paraprobe_nanochem_config(NXobject): The tool assumes that the values are stored in the same order as points (ions). feature(NXserialized): + exists: optional doc: | A precomputed triangulated mesh of the feature representing a model of the interface at which to place ROIs to profile. This can be the mesh of an @@ -709,7 +710,7 @@ NXapm_paraprobe_nanochem_config(NXobject): method(NX_CHAR): match(NX_NUMBER): feature_distance(NXserialized): - exists: recommended + exists: optional doc: | To enable an additional filtration of specific parts of the feature mesh it is recommended to feed precomputed distances of each ion to From 1736cd031e968b5772b5416545b7eeab6efcf596 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 4 Apr 2024 11:40:53 +0200 Subject: [PATCH 0642/1012] small fixes to NXmpes --- contributed_definitions/NXmpes.nxdl.xml | 29 ++++++---- contributed_definitions/nyaml/NXmpes.yaml | 66 +++++++++++++---------- 2 files changed, 55 insertions(+), 40 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 0b0472fc06..572ab83b17 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -22,6 +22,16 @@ # For further information, see http://www.nexusformat.org --> + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of data points in the transmission function. + + + This is the most general application definition for photoemission experiments. @@ -109,11 +119,6 @@ .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 - - - - - Overall energy resolution of the photoemission instrument. @@ -144,6 +149,11 @@ + + + + + A source used to generate a beam. Properties refer strictly to parameters of the @@ -229,6 +239,7 @@ + @@ -238,7 +249,6 @@ - @@ -372,7 +382,6 @@ - **pixel_x**: Detector pixel in x direction. - **pixel_y**: Detector pixel in y direction. - **energy**: (Un)calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). - - **momentum**: Calibrated momentum axis. Unit category: NX_ANY (e.g., kg*m/s). - **kx**: (Un)calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). - **ky**: (Un)calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). - **kz**: (Un)calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). @@ -555,9 +564,6 @@ - - - @@ -746,11 +752,12 @@ If you want to provide additional views on your data, you can additionally use the generic NXdata group of NXentry. + In NXmpes, it is required to provide an energy axis. + The naming of fields should follow the convention defined in the :ref:`NXdata_mpes` base class: - **energy**: Calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). - - **momentum**: Calibrated momentum axis. Unit category: NX_ANY (e.g., kg*m/s). - **kx**: Calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). - **ky**: Calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). - **kz**: Calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 601a53a9da..440a31e230 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -8,6 +8,11 @@ doc: | .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays + n_transmission_function: | + Number of data points in the transmission function. type: group NXmpes(NXobject): (NXentry): @@ -75,14 +80,6 @@ NXmpes(NXobject): spec: ISO 18115-1:2023 term: 12.58 url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 - device_information(NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended energy_resolution(NXresolution): exists: optional doc: | @@ -112,6 +109,14 @@ NXmpes(NXobject): spec: ISO 18115-1:2023 term: 10.7 ff. url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 + device_information(NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended sourceTYPE(NXsource): exists: recommended doc: | @@ -191,6 +196,9 @@ NXmpes(NXobject): exists: recommended description: exists: recommended + work_function(NX_FLOAT): + unit: NX_ENERGY + exists: recommended energy_resolution(NXresolution): exists: optional type: @@ -198,9 +206,6 @@ NXmpes(NXobject): physical_quantity: enumeration: [energy] resolution(NX_FLOAT): - work_function(NX_FLOAT): - unit: NX_ENERGY - exists: recommended fast_axes: exists: recommended slow_axes: @@ -318,7 +323,6 @@ NXmpes(NXobject): - **pixel_x**: Detector pixel in x direction. - **pixel_y**: Detector pixel in y direction. - **energy**: (Un)calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). - - **momentum**: Calibrated momentum axis. Unit category: NX_ANY (e.g., kg*m/s). - **kx**: (Un)calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). - **ky**: (Un)calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). - **kz**: (Un)calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). @@ -481,10 +485,6 @@ NXmpes(NXobject): exists: optional calibrated_axis(NX_FLOAT): exists: recommended - momentum_calibration(NXcalibration): - exists: optional - calibrated_axis(NX_FLOAT): - exists: recommended kK_calibration(NXcalibration): exists: optional calibrated_axis(NX_FLOAT): @@ -654,11 +654,12 @@ NXmpes(NXobject): If you want to provide additional views on your data, you can additionally use the generic NXdata group of NXentry. + In NXmpes, it is required to provide an energy axis. + The naming of fields should follow the convention defined in the :ref:`NXdata_mpes` base class: - **energy**: Calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). - - **momentum**: Calibrated momentum axis. Unit category: NX_ANY (e.g., kg*m/s). - **kx**: Calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). - **ky**: Calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). - **kz**: Calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). @@ -703,7 +704,7 @@ NXmpes(NXobject): @energy_depends: 'entry/process/energy_calibration' # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 204be34db7933cefb131e639aa03ef71a29477a058fd289b4fc3964903a44e04 +# fa26c4429dc7a25632f7092b51b429c9c4ba1b0547cfbdfb9e1a649c57fbefc4 # # # # +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays +# +# +# +# Number of data points in the transmission function. +# +# +# # # This is the most general application definition for # photoemission experiments. @@ -815,11 +826,6 @@ NXmpes(NXobject): # # .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 # -# -# -# -# -# # # # Overall energy resolution of the photoemission instrument. @@ -850,6 +856,11 @@ NXmpes(NXobject): # # # +# +# +# +# +# # # # A source used to generate a beam. Properties refer strictly to parameters of the @@ -935,6 +946,7 @@ NXmpes(NXobject): # # # +# # # # @@ -944,7 +956,6 @@ NXmpes(NXobject): # # # -# # # # @@ -1078,7 +1089,6 @@ NXmpes(NXobject): # - **pixel_x**: Detector pixel in x direction. # - **pixel_y**: Detector pixel in y direction. # - **energy**: (Un)calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). -# - **momentum**: Calibrated momentum axis. Unit category: NX_ANY (e.g., kg*m/s). # - **kx**: (Un)calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). # - **ky**: (Un)calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). # - **kz**: (Un)calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). @@ -1261,9 +1271,6 @@ NXmpes(NXobject): # # # -# -# -# # # # @@ -1452,11 +1459,12 @@ NXmpes(NXobject): # If you want to provide additional views on your data, you can additionally use # the generic NXdata group of NXentry. # +# In NXmpes, it is required to provide an energy axis. +# # The naming of fields should follow the convention defined in the # :ref:`NXdata_mpes` base class: # # - **energy**: Calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). -# - **momentum**: Calibrated momentum axis. Unit category: NX_ANY (e.g., kg*m/s). # - **kx**: Calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). # - **ky**: Calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). # - **kz**: Calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). From 7607d476f325b3e2968ee48e417f5c88128dd2d5 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 4 Apr 2024 11:43:47 +0200 Subject: [PATCH 0643/1012] revert style changes to NXsample --- base_classes/NXsample.nxdl.xml | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/base_classes/NXsample.nxdl.xml b/base_classes/NXsample.nxdl.xml index b63b9da89f..87c585a530 100644 --- a/base_classes/NXsample.nxdl.xml +++ b/base_classes/NXsample.nxdl.xml @@ -481,9 +481,7 @@ - + This group describes the shape of the sample @@ -520,9 +518,7 @@ exists: ['min', '0'] - + Any environmental or external stimuli/measurements. These can include, among others: From 96a5da09a17b1658089274f5af4b794e2303da03 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 4 Apr 2024 11:47:01 +0200 Subject: [PATCH 0644/1012] regenerate NXsample yaml --- base_classes/nyaml/NXsample.yaml | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/base_classes/nyaml/NXsample.yaml b/base_classes/nyaml/NXsample.yaml index 8fee2dd55d..e36eb87188 100644 --- a/base_classes/nyaml/NXsample.yaml +++ b/base_classes/nyaml/NXsample.yaml @@ -864,9 +864,7 @@ NXsample(NXobject): # # # -# +# # # This group describes the shape of the sample # @@ -903,9 +901,7 @@ NXsample(NXobject): # # # -# +# # # Any environmental or external stimuli/measurements. # These can include, among others: From e12aa3bae6234e6bc9334c502b5a4cef381f9fa0 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 4 Apr 2024 11:51:57 +0200 Subject: [PATCH 0645/1012] revert NXsample comment changes that break CI --- base_classes/NXsample.nxdl.xml | 8 ++++++-- base_classes/nyaml/NXsample.yaml | 8 ++++++-- 2 files changed, 12 insertions(+), 4 deletions(-) diff --git a/base_classes/NXsample.nxdl.xml b/base_classes/NXsample.nxdl.xml index 87c585a530..b63b9da89f 100644 --- a/base_classes/NXsample.nxdl.xml +++ b/base_classes/NXsample.nxdl.xml @@ -481,7 +481,9 @@ - + This group describes the shape of the sample @@ -518,7 +520,9 @@ - + Any environmental or external stimuli/measurements. These can include, among others: diff --git a/base_classes/nyaml/NXsample.yaml b/base_classes/nyaml/NXsample.yaml index e36eb87188..8fee2dd55d 100644 --- a/base_classes/nyaml/NXsample.yaml +++ b/base_classes/nyaml/NXsample.yaml @@ -864,7 +864,9 @@ NXsample(NXobject): # # # -# +# # # This group describes the shape of the sample # @@ -901,7 +903,9 @@ NXsample(NXobject): # # # -# +# # # Any environmental or external stimuli/measurements. # These can include, among others: From 6de7529e637719639d49d18ec5c88602779f4669 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 4 Apr 2024 17:27:04 +0200 Subject: [PATCH 0646/1012] Completed the last piece that was missing for the NXapm_paraprobe_nanochem_results - reporting of oned_profile numerical data for each roi and respective XDMF cylinder geometries for visualization in paraview --- .../NXapm_paraprobe_nanochem_results.nxdl.xml | 105 ++++++++++-------- .../NXapm_paraprobe_nanochem_results.yaml | 83 ++++++++------ 2 files changed, 109 insertions(+), 79 deletions(-) diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml index 64ebdf5501..b95f0df993 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml @@ -78,6 +78,11 @@ The cardinality/total number of triangles in the triangle soup.--> The total number of member distinguished when reporting composition. + + + The total number of ROIs placed in an oned_profile task. + + Application definition for results files of the paraprobe-nanochem tool. @@ -1109,7 +1114,7 @@ face_identifier_offset(NX_UINT):--> - + @@ -1134,63 +1139,75 @@ face_identifier_offset(NX_UINT):--> - + - Integer which specifies the first index to be used for distinguishing - ROI cylinder explicitly. + The orientation of the ROI defined via a vector which points along + the cylinder axis and whose length is the height of the cylinder. - + + - - - - - - - - - The number of atoms in each ROI. - - - - - - - - The number of ions in each ROI. - - - - - - - - The orientation of the ROI defined via a vector which points along - the cylinder axis and whose length is the height of the cylinder. - - - - - - + + + + XDMF support to enable colouring each ROI by its identifier. + + + + + + + + XDMF support to enable colouring each ROI whether it has edge contact or not. + + + + + + + + XDMF support to enable colouring each ROI by its number of atoms. + + + + + + + + XDMF support to enable colouring each ROI by its number of ions. + + + + + + + + Distance and iontype-specific processed data for each ROI. + Arrays signed_distance and nuclide_hash are sorted by increasing + distance. + Array nuclide_hash reports one hash for each atom of each isotope. + Effectively, this can yield to groups of values on signed_distance + with the same distance value as molecular ions are reported decomposed + into their atoms. + Therefore, the XDMF support fields number_of_atoms and number_of_ions + are only expected to display pairwise the same values respectively, + if all ions are built from a single atom only. + - - EXPLAIN HOW FIELDS SIGNED_DISTANCE AND NUCLIDE - ARE COMPUTED/CONSTRUCTED. - - In the direction of the ROI. + Sorted in increasing order projected along the positive direction + of the ROI as defined by orientation in the parent group. - + - Hashvalue using the following hashing rule :math:`H = Z + 256 * N`. + Hashvalue as defined in :ref:`NXion`. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml index f17638297c..9ab419db9d 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml @@ -28,6 +28,8 @@ symbols: The total number of volumetric features. n_speci: | The total number of member distinguished when reporting composition. + n_rois: | + The total number of ROIs placed in an oned_profile task. type: group NXapm_paraprobe_nanochem_results(NXobject): (NXentry): @@ -798,6 +800,7 @@ NXapm_paraprobe_nanochem_results(NXobject): oned_profile(NXapm_paraprobe_tool_results): exists: [min, 0, max, 1] window(NXcs_filter_boolean_mask): + exists: optional number_of_ions(NX_UINT): bitdepth(NX_UINT): mask(NX_UINT): @@ -818,50 +821,60 @@ NXapm_paraprobe_nanochem_results(NXobject): necessarily has to be the center_of_mass of the polyhedra. unit: NX_LENGTH dim: (i, 3) - roi_identifier(NX_UINT): + orientation(NX_FLOAT): + doc: | + The orientation of the ROI defined via a vector which points along + the cylinder axis and whose length is the height of the cylinder. + unit: NX_LENGTH + dim: (i, 3) + # XDMF support + identifier(NX_UINT): + exists: optional doc: | - Integer which specifies the first index to be used for distinguishing - ROI cylinder explicitly. + XDMF support to enable colouring each ROI by its identifier. unit: NX_UNITLESS - dim: (i,) - polyhedra(NXcg_face_list_data_structure): - exists: [min, 0, max, 1] - edge_contact(NX_UINT): - exists: optional - unit: NX_UNITLESS - dim: (i,) - number_of_atoms(NX_UINT): - exists: optional - doc: | - The number of atoms in each ROI. - unit: NX_UNITLESS - dim: (i,) - number_of_ions(NX_UINT): - exists: optional - doc: | - The number of ions in each ROI. - unit: NX_UNITLESS - dim: (i,) - orientation(NX_FLOAT): - exists: optional - doc: | - The orientation of the ROI defined via a vector which points along - the cylinder axis and whose length is the height of the cylinder. - unit: NX_LENGTH - dim: (i, 3) + dim: (j,) + edge_contact(NX_UINT): + exists: optional + doc: | + XDMF support to enable colouring each ROI whether it has edge contact or not. + unit: NX_UNITLESS + dim: (j,) + number_of_atoms(NX_UINT): + exists: optional + doc: | + XDMF support to enable colouring each ROI by its number of atoms. + unit: NX_UNITLESS + dim: (j,) + number_of_ions(NX_UINT): + exists: optional + doc: | + XDMF support to enable colouring each ROI by its number of ions. + unit: NX_UNITLESS + dim: (j,) + rois_far_from_edge(NXprocess): + doc: | + Distance and iontype-specific processed data for each ROI. + Arrays signed_distance and nuclide_hash are sorted by increasing + distance. + Array nuclide_hash reports one hash for each atom of each isotope. + Effectively, this can yield to groups of values on signed_distance + with the same distance value as molecular ions are reported decomposed + into their atoms. + Therefore, the XDMF support fields number_of_atoms and number_of_ions + are only expected to display pairwise the same values respectively, + if all ions are built from a single atom only. roiID(NXobject): exists: [min, 0, max, infty] # no max is := i - doc: | - EXPLAIN HOW FIELDS SIGNED_DISTANCE AND NUCLIDE - ARE COMPUTED/CONSTRUCTED. signed_distance(NX_FLOAT): doc: | - In the direction of the ROI. + Sorted in increasing order projected along the positive direction + of the ROI as defined by orientation in the parent group. unit: NX_LENGTH dim: (k,) - nuclide(NX_UINT): + nuclide_hash(NX_UINT): doc: | - Hashvalue using the following hashing rule :math:`H = Z + 256 * N`. + Hashvalue as defined in :ref:`NXion`. unit: NX_UNITLESS dim: (k,) From 4cd79ab308001bf3c7d0a5d26410f1d5d9c17c8a Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 5 Apr 2024 16:50:01 +0200 Subject: [PATCH 0647/1012] typo fixes, make uppercase notation more verbose --- .../NXenergydispersion.nxdl.xml | 2 +- contributed_definitions/NXmpes.nxdl.xml | 6 ++++-- contributed_definitions/NXprocess_mpes.nxdl.xml | 1 - .../nyaml/NXenergydispersion.yaml | 6 +++--- contributed_definitions/nyaml/NXmpes.yaml | 14 +++++++++----- contributed_definitions/nyaml/NXprocess_mpes.yaml | 4 +--- 6 files changed, 18 insertions(+), 15 deletions(-) diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml index 7bc5f0e55e..4987bff700 100644 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ b/contributed_definitions/NXenergydispersion.nxdl.xml @@ -44,7 +44,7 @@ - Drift energy for time-of-flight energy dispersive element.s + Drift energy for time-of-flight energy dispersive elements. diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 572ab83b17..86e2b2067b 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -162,8 +162,10 @@ or similar. Note that the uppercase notation in sourceTYPE means that multiple sources can - be provided. For example, in pump-probe experiments, it is possible to have both - a `source_probe` and a `source_pump` + be provided. The uppercase part can be substituted with any string that consists + of alphanumeric characters, including both uppercase and lowercase letters from A to Z + and numerical digits from 0 to 9. For example, in pump-probe experiments, it is possible + to have both a `source_probe` and a `source_pump`. diff --git a/contributed_definitions/NXprocess_mpes.nxdl.xml b/contributed_definitions/NXprocess_mpes.nxdl.xml index 6d95429413..6fdba78463 100644 --- a/contributed_definitions/NXprocess_mpes.nxdl.xml +++ b/contributed_definitions/NXprocess_mpes.nxdl.xml @@ -154,7 +154,6 @@ Calibration event of the beam polarization angle. - physical_quantity: diff --git a/contributed_definitions/nyaml/NXenergydispersion.yaml b/contributed_definitions/nyaml/NXenergydispersion.yaml index e269cdbfb3..60633a1f8a 100644 --- a/contributed_definitions/nyaml/NXenergydispersion.yaml +++ b/contributed_definitions/nyaml/NXenergydispersion.yaml @@ -22,7 +22,7 @@ NXenergydispersion(NXobject): drift_energy(NX_FLOAT): unit: NX_ENERGY doc: | - Drift energy for time-of-flight energy dispersive element.s + Drift energy for time-of-flight energy dispersive elements. center_energy(NX_FLOAT): unit: NX_ENERGY doc: | @@ -137,7 +137,7 @@ NXenergydispersion(NXobject): the reference coordinate system. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 90e9d0204c22db3fe4c9fc961a86dfea98c3356b34e4a77f777312835e4c7048 +# 731460d96b884c5a34ca39f81fcde2fbde397b23fe36bbbddc1ddf0c051c5fdf # # # - +with higher granularity in the data description.--> This is an general application definition for angle-resolved multidimensional photoelectron spectroscopy. From 79fda3ce3724e407d5b41fd1a9b786b24874c2ca Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 8 Apr 2024 12:46:01 +0200 Subject: [PATCH 0654/1012] Remake nxmpes_arpes with nyaml==0.0.8 --- contributed_definitions/NXmpes_arpes.nxdl.xml | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/NXmpes_arpes.nxdl.xml b/contributed_definitions/NXmpes_arpes.nxdl.xml index dac1c71a61..f964096fae 100644 --- a/contributed_definitions/NXmpes_arpes.nxdl.xml +++ b/contributed_definitions/NXmpes_arpes.nxdl.xml @@ -22,12 +22,14 @@ # For further information, see http://www.nexusformat.org --> - +with higher granularity in the data description. +--> This is an general application definition for angle-resolved multidimensional photoelectron spectroscopy. From 0fd7d533135c1f5446071cc76b57122cfb5b3c7b Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 8 Apr 2024 14:22:07 +0200 Subject: [PATCH 0655/1012] Align NXmpes_arpes with NXmpes --- contributed_definitions/NXmpes_arpes.nxdl.xml | 129 +++++++----------- .../nyaml/NXmpes_arpes.yaml | 104 ++++++++------ 2 files changed, 109 insertions(+), 124 deletions(-) diff --git a/contributed_definitions/NXmpes_arpes.nxdl.xml b/contributed_definitions/NXmpes_arpes.nxdl.xml index f964096fae..3ce0a76f57 100644 --- a/contributed_definitions/NXmpes_arpes.nxdl.xml +++ b/contributed_definitions/NXmpes_arpes.nxdl.xml @@ -38,6 +38,7 @@ with higher granularity in the data description. + @@ -45,15 +46,15 @@ with higher granularity in the data description. - Link to transformations defining an APRES base coordinate system, which is - defined such that the positive z-axis points towards the analyzer entry, and the - x-axis lies within the beam/analyzer plane. + Link to transformations defining an APRES base coordinate system, + which is defined such that the positive z-axis points towards the analyzer entry, + and the x-axis lies within the beam/analyzer plane. - Set of transformations, describing the orientation of the ARPES coordinate - system with respect to the beam coordinate system (.). + Set of transformations, describing the orientation of the ARPES coordinate system + with respect to the beam coordinate system (.). @@ -61,8 +62,10 @@ with higher granularity in the data description. - Overall angular resolution along the Nth angular axis. Create one such entry per relevant angular axis, corresponding to the angular axes in NXdata. - For hemispherical analyzers, angular0_resolution corresponds to the direction along the analyzer slit, and angular1_resolution to the one perpendicular to it. + Overall angular resolution along the Nth angular axis. Create one such entry per relevant angular axis, + corresponding to the angular axes in NXdata. + For hemispherical analyzers, angular0_resolution corresponds to the direction along the analyzer slit, + and angular1_resolution to the one perpendicular to it. @@ -75,8 +78,10 @@ with higher granularity in the data description. - Analyzer angular resolution along the Nth angular axis. Create one such entry per relevant angular axis, corresponding to the angular axes in NXdata. - For hemispherical analyzers, angular0_resolution corresponds to the direction along the analyzer slit, and angular1_resolution to the one perpendicular to it. + Analyzer angular resolution along the Nth angular axis. + Create one such entry per relevant angular axis, corresponding to the angular axes in NXdata. + For hemispherical analyzers, angular0_resolution corresponds to the direction along the analyzer slit, + and angular1_resolution to the one perpendicular to it. @@ -88,20 +93,20 @@ with higher granularity in the data description. - Reference to the last transformation describing the orientation of the analyzer - relative to the beam, e.g. transformations/analyzer_elevation. + Reference to the last transformation describing the orientation of the analyzer relative to the beam, + e.g. transformations/analyzer_elevation. - Set of transformations, describing the relative orientation of the analyzer with - respect to the beam coordinate system (.). + Set of transformations, describing the relative orientation of the analyzer + with respect to the beam coordinate system (.). - Rotation about the analyzer lens axis. Its zero reference is defined such that - the angular0 axis is increasing towards the positive y axis (analyzer slit - vertical). + Rotation about the analyzer lens axis. + Its zero reference is defined such that the angular0 axis is + increasing towards the positive y axis (analyzer slit vertical). @@ -144,8 +149,8 @@ with higher granularity in the data description. - In-plane analyzer coordinate along a dispersive direction, e.g. along an - analyzer slit. If a resolved angle, place the calibrated coordinates here. + In-plane analyzer coordinate along a dispersive direction, + e.g. along an analyzer slit. If a resolved angle, place the calibrated coordinates here. @@ -187,34 +192,6 @@ with higher granularity in the data description. - - - - Raw data before calibration. - - - - - - - - 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 - - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - - This is the Nth calibrated angular axis to be used for data plotting. - - @@ -225,15 +202,15 @@ with higher granularity in the data description. - Reference to the end of the transformation chain, orienting the sample surface - within the arpes_geometry coordinate system (sample_azimuth or anything - depending on it). + Reference to the end of the transformation chain, + orienting the sample surface within the arpes_geometry coordinate system + (sample_azimuth or anything depending on it). - Set of transformations, describing the relative orientation of the sample with - respect to the arpes_geometry coordinate system. + Set of transformations, describing the relative orientation of the sample + with respect to the arpes_geometry coordinate system. @@ -251,8 +228,8 @@ with higher granularity in the data description. - Path to a transformation that places the sample surface into the origin of the - arpes_geometry coordinate system. + Path to a transformation that places the sample surface + into the origin of the arpes_geometry coordinate system. @@ -358,7 +335,7 @@ with higher granularity in the data description. - + @@ -366,7 +343,7 @@ with higher granularity in the data description. - + @@ -374,36 +351,31 @@ with higher granularity in the data description. - Points to the path to a field defining the axis on which the angular axis - depends. For example: @angular1_depends: - '/entry/sample/transformations/sample_tilt' for a manipulator angular scan + Points to the path to a field defining the axis on which the angular axis depends. + For example: + @angular1_depends: '/entry/sample/transformations/sample_tilt' for a manipulator angular scan @angular1_depends: '/entry/instrument/detector/sensor_x' for a 2D detector - @angular1_depends: '/entry/instrument/collectioncolumn/deflector' for a - deflector scan @angular1_depends: - '/entry/process/calibration/angular1_calibration/calibrated_axis' for a - preprocessed axis. + @angular1_depends: '/entry/instrument/collectioncolumn/deflector' for a deflector scan + @angular1_depends: '/entry/process/calibration/angular1_calibration/calibrated_axis' for a preprocessed axis. - Points to the path to a field defining the axis on which the angular axis - depends. For example: @angular2_depends: - '/entry/sample/transformations/sample_polar' for a manipulator angular scan + Points to the path to a field defining the axis on which the angular axis depends. + For example: + @angular2_depends: '/entry/sample/transformations/sample_polar' for a manipulator angular scan @angular2_depends: '/entry/instrument/detector/sensor_x' for a 2D detector - @angular2_depends: '/entry/instrument/collectioncolumn/deflector' for a - deflector scan @angular2_depends: - '/entry/process/calibration/angular2_calibration/calibrated_axis' for a - preprocessed axis. + @angular2_depends: '/entry/instrument/collectioncolumn/deflector' for a deflector scan + @angular2_depends: '/entry/process/calibration/angular2_calibration/calibrated_axis' for a preprocessed axis. - Points to the path to a field defining the axis on which the energy axis - depends. For example: @energy_depends: '/entry/instrument/detector/sensor_y' for - a 2D detector @energy_depends: - '/entry/instrument/energydispersion/center_kinetic_energy' for a swept scan - @energy_depends: '/entry/process/calibration/energy_calibration/calibrated_axis' - for a preprocessed axis. + Points to the path to a field defining the axis on which the energy axis depends. + For example: + @energy_depends: '/entry/instrument/detector/sensor_y' for a 2D detector + @energy_depends: '/entry/instrument/energydispersion/center_kinetic_energy' for a swept scan + @energy_depends: '/entry/process/calibration/energy_calibration/calibrated_axis' for a preprocessed axis. @@ -426,10 +398,9 @@ with higher granularity in the data description. - Represents a measure of three-dimensional photoemission counts, where the varied - axes are energy, and one or more angular coordinates. Axes traces should be - linked to the actual encoder position in NXinstrument or calibrated axes in - NXprocess. + Represents a measure of three-dimensional photoemission counts, where + the varied axes are energy, and one or more angular coordinates. Axes traces + should be linked to the actual encoder position in NXinstrument or calibrated axes in NXprocess. diff --git a/contributed_definitions/nyaml/NXmpes_arpes.yaml b/contributed_definitions/nyaml/NXmpes_arpes.yaml index 085015fce0..d768a90a74 100644 --- a/contributed_definitions/nyaml/NXmpes_arpes.yaml +++ b/contributed_definitions/nyaml/NXmpes_arpes.yaml @@ -11,20 +11,27 @@ NXmpes_arpes(NXmpes): (NXentry): definition: \@version: - enumeration: ["NXmpes_arpes"] + enumeration: ["NXmpes", "NXmpes_arpes"] geometries(NXcoordinate_system_set): arpes_geometry(NXcoordinate_system): depends_on(NX_CHAR): - doc: "Link to transformations defining an APRES base coordinate system, which is defined such that the positive z-axis points towards the analyzer entry, and the x-axis lies within the beam/analyzer plane." + doc: | + Link to transformations defining an APRES base coordinate system, + which is defined such that the positive z-axis points towards the analyzer entry, + and the x-axis lies within the beam/analyzer plane. (NXtransformations): - doc: "Set of transformations, describing the orientation of the ARPES coordinate system with respect to the beam coordinate system (.)." + doc: | + Set of transformations, describing the orientation of the ARPES coordinate system + with respect to the beam coordinate system (.). (NXinstrument): angularN_resolution(NXresolution): exists: recommended doc: - | - Overall angular resolution along the Nth angular axis. Create one such entry per relevant angular axis, corresponding to the angular axes in NXdata. - For hemispherical analyzers, angular0_resolution corresponds to the direction along the analyzer slit, and angular1_resolution to the one perpendicular to it. + Overall angular resolution along the Nth angular axis. Create one such entry per relevant angular axis, + corresponding to the angular axes in NXdata. + For hemispherical analyzers, angular0_resolution corresponds to the direction along the analyzer slit, + and angular1_resolution to the one perpendicular to it. physical_quantity: enumeration: [angle] type: @@ -36,8 +43,10 @@ NXmpes_arpes(NXmpes): exists: recommended doc: - | - Analyzer angular resolution along the Nth angular axis. Create one such entry per relevant angular axis, corresponding to the angular axes in NXdata. - For hemispherical analyzers, angular0_resolution corresponds to the direction along the analyzer slit, and angular1_resolution to the one perpendicular to it. + Analyzer angular resolution along the Nth angular axis. + Create one such entry per relevant angular axis, corresponding to the angular axes in NXdata. + For hemispherical analyzers, angular0_resolution corresponds to the direction along the analyzer slit, + and angular1_resolution to the one perpendicular to it. physical_quantity: enumeration: [angle] type: @@ -45,20 +54,31 @@ NXmpes_arpes(NXmpes): resolution(NX_FLOAT): unit: NX_ANGLE depends_on(NX_CHAR): - doc: "Reference to the last transformation describing the orientation of the analyzer relative to the beam, e.g. transformations/analyzer_elevation." + doc: | + Reference to the last transformation describing the orientation of the analyzer relative to the beam, + e.g. transformations/analyzer_elevation. transformations(NXtransformations): - doc: "Set of transformations, describing the relative orientation of the analyzer with respect to the beam coordinate system (.)." + doc: | + Set of transformations, describing the relative orientation of the analyzer + with respect to the beam coordinate system (.). analyzer_rotation(NX_NUMBER): - doc: "Rotation about the analyzer lens axis. Its zero reference is defined such that the angular0 axis is increasing towards the positive y axis (analyzer slit vertical)." + doc: | + Rotation about the analyzer lens axis. + Its zero reference is defined such that the angular0 axis is + increasing towards the positive y axis (analyzer slit vertical). unit: NX_ANGLE \@transformation_type: enumeration: ["rotation"] \@vector: enumeration: ["[0, 0, 1]"] \@depends_on: - doc: "Path to a transformation that places the analyzer origin system into the arpes_geometry coordinate system." + doc: | + Path to a transformation that places the analyzer origin system into the arpes_geometry coordinate system. analyzer_elevation(NX_NUMBER): - doc: "Elevation of the effective analyzer acceptance area, e.g. realized by deflectors, or as one angle in a TOF detector. If a resolved angle, place the calibrated axis coordinates here." + doc: + Elevation of the effective analyzer acceptance area, + e.g. realized by deflectors, or as one angle in a TOF detector. + If a resolved angle, place the calibrated axis coordinates here. unit: NX_ANGLE \@transformation_type: enumeration: ["rotation"] @@ -67,7 +87,9 @@ NXmpes_arpes(NXmpes): \@depends_on: enumeration: ["analyzer_dispersion"] analyzer_dispersion(NX_NUMBER): - doc: "In-plane analyzer coordinate along a dispersive direction, e.g. along an analyzer slit. If a resolved angle, place the calibrated coordinates here." + doc: | + In-plane analyzer coordinate along a dispersive direction, + e.g. along an analyzer slit. If a resolved angle, place the calibrated coordinates here. unit: NX_ANGLE \@transformation_type: enumeration: ["rotation"] @@ -96,32 +118,18 @@ NXmpes_arpes(NXmpes): "straight slit", "curved slit", ] - (NXdetector): - data(NX_NUMBER): # Raw signal without calibrated axes. - exists: recommended - doc: "Raw data before calibration." - (NXprocess): - exists: optional - doc: "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" - energy_calibration(NXcalibration): - exists: recommended - calibrated_axis(NX_FLOAT): - exists: recommended - doc: "This is the calibrated energy axis to be used for data plotting." - angularN_calibration(NXcalibration): - exists: optional - calibrated_axis(NX_FLOAT): - exists: recommended - doc: "This is the Nth calibrated angular axis to be used for data plotting." (NXsample): situation: enumeration: ["vacuum"] depends_on(NX_CHAR): - doc: "Reference to the end of the transformation chain, orienting the sample surface within the arpes_geometry coordinate system (sample_azimuth or anything depending on it)." + doc: | + Reference to the end of the transformation chain, + orienting the sample surface within the arpes_geometry coordinate system + (sample_azimuth or anything depending on it). transformations(NXtransformations): - doc: "Set of transformations, describing the relative orientation of the sample with respect to the arpes_geometry coordinate system." + doc: | + Set of transformations, describing the relative orientation of the sample + with respect to the arpes_geometry coordinate system. sample_polar(NX_NUMBER): doc: "Rotation about the y axis (typically the long manipulator axis)." unit: NX_ANGLE @@ -130,7 +138,9 @@ NXmpes_arpes(NXmpes): \@vector: enumeration: ["[0, 1, 0]"] \@depends_on: - doc: "Path to a transformation that places the sample surface into the origin of the arpes_geometry coordinate system." + doc: | + Path to a transformation that places the sample surface + into the origin of the arpes_geometry coordinate system. offset_polar(NX_NUMBER): doc: "Offset of polar rotation." unit: NX_ANGLE @@ -176,34 +186,37 @@ NXmpes_arpes(NXmpes): enumeration: ["[0, 0, 1]"] \@depends_on: enumeration: ["sample_azimuth"] - (NXdata): + data(NXdata_mpes): \@signal: enumeration: ["data"] # There is an object named data that contains the signal \@axes: # There are three dimensions, one energy & two angular coordinates. Any coordinates that do not move, are represented by one point. - enumeration: ["[angular1, angluar2, energy]"] + enumeration: ["[angular1, angular2, energy]"] \@energy_indices: # energy indices have to be provided \@angular1_indices: # angular1 indices have to be provided \@angular2_indices: # angular2 indices have to be provided \@angular1_depends(NX_CHAR): - doc: "Points to the path to a field defining the axis on which the angular axis depends. + doc: | + Points to the path to a field defining the axis on which the angular axis depends. For example: @angular1_depends: '/entry/sample/transformations/sample_tilt' for a manipulator angular scan @angular1_depends: '/entry/instrument/detector/sensor_x' for a 2D detector @angular1_depends: '/entry/instrument/collectioncolumn/deflector' for a deflector scan - @angular1_depends: '/entry/process/calibration/angular1_calibration/calibrated_axis' for a preprocessed axis." + @angular1_depends: '/entry/process/calibration/angular1_calibration/calibrated_axis' for a preprocessed axis. \@angular2_depends(NX_CHAR): - doc: "Points to the path to a field defining the axis on which the angular axis depends. + doc: | + Points to the path to a field defining the axis on which the angular axis depends. For example: @angular2_depends: '/entry/sample/transformations/sample_polar' for a manipulator angular scan @angular2_depends: '/entry/instrument/detector/sensor_x' for a 2D detector @angular2_depends: '/entry/instrument/collectioncolumn/deflector' for a deflector scan - @angular2_depends: '/entry/process/calibration/angular2_calibration/calibrated_axis' for a preprocessed axis." + @angular2_depends: '/entry/process/calibration/angular2_calibration/calibrated_axis' for a preprocessed axis. \@energy_depends(NX_CHAR): # Similarly, energy can be dispersed according to different strategies - doc: "Points to the path to a field defining the axis on which the energy axis depends. + doc: | + Points to the path to a field defining the axis on which the energy axis depends. For example: @energy_depends: '/entry/instrument/detector/sensor_y' for a 2D detector @energy_depends: '/entry/instrument/energydispersion/center_kinetic_energy' for a swept scan - @energy_depends: '/entry/process/calibration/energy_calibration/calibrated_axis' for a preprocessed axis." + @energy_depends: '/entry/process/calibration/energy_calibration/calibrated_axis' for a preprocessed axis. energy(NX_NUMBER): doc: "Trace of the energy axis. Could be linked from the respective 'AXISNAME_depends' field." unit: NY_ENERGY @@ -214,7 +227,8 @@ NXmpes_arpes(NXmpes): doc: "Trace of the second axis. Could be linked from the respective 'AXISNAME_depends' field." unit: ANX_ANGLE data(NX_NUMBER): # There is a block of numbers named data. - doc: "Represents a measure of three-dimensional photoemission counts, where + doc: | + Represents a measure of three-dimensional photoemission counts, where the varied axes are energy, and one or more angular coordinates. Axes traces - should be linked to the actual encoder position in NXinstrument or calibrated axes in NXprocess." + should be linked to the actual encoder position in NXinstrument or calibrated axes in NXprocess. unit: NX_ANY From a5bb330a3bae2ec4f4ae3bf8cd75f37039c4bcad Mon Sep 17 00:00:00 2001 From: domna Date: Mon, 8 Apr 2024 16:46:21 +0200 Subject: [PATCH 0656/1012] Updates to angular0,1; removes NXmpes as possible definition --- contributed_definitions/NXmpes_arpes.nxdl.xml | 29 +++++++++---------- .../nyaml/NXmpes_arpes.yaml | 28 +++++++++--------- 2 files changed, 28 insertions(+), 29 deletions(-) diff --git a/contributed_definitions/NXmpes_arpes.nxdl.xml b/contributed_definitions/NXmpes_arpes.nxdl.xml index 3ce0a76f57..9051531d2b 100644 --- a/contributed_definitions/NXmpes_arpes.nxdl.xml +++ b/contributed_definitions/NXmpes_arpes.nxdl.xml @@ -38,7 +38,6 @@ with higher granularity in the data description. - @@ -343,30 +342,30 @@ with higher granularity in the data description. - + + - - + Points to the path to a field defining the axis on which the angular axis depends. For example: - @angular1_depends: '/entry/sample/transformations/sample_tilt' for a manipulator angular scan - @angular1_depends: '/entry/instrument/detector/sensor_x' for a 2D detector - @angular1_depends: '/entry/instrument/collectioncolumn/deflector' for a deflector scan - @angular1_depends: '/entry/process/calibration/angular1_calibration/calibrated_axis' for a preprocessed axis. + @angular0_depends: '/entry/sample/transformations/sample_tilt' for a manipulator angular scan + @angular0_depends: '/entry/instrument/detector/sensor_x' for a 2D detector + @angular0_depends: '/entry/instrument/collectioncolumn/deflector' for a deflector scan + @angular0_depends: '/entry/process/calibration/angular0_calibration/calibrated_axis' for a preprocessed axis. - + Points to the path to a field defining the axis on which the angular axis depends. For example: - @angular2_depends: '/entry/sample/transformations/sample_polar' for a manipulator angular scan - @angular2_depends: '/entry/instrument/detector/sensor_x' for a 2D detector - @angular2_depends: '/entry/instrument/collectioncolumn/deflector' for a deflector scan - @angular2_depends: '/entry/process/calibration/angular2_calibration/calibrated_axis' for a preprocessed axis. + @angular1_depends: '/entry/sample/transformations/sample_polar' for a manipulator angular scan + @angular1_depends: '/entry/instrument/detector/sensor_x' for a 2D detector + @angular1_depends: '/entry/instrument/collectioncolumn/deflector' for a deflector scan + @angular1_depends: '/entry/process/calibration/angular1_calibration/calibrated_axis' for a preprocessed axis. @@ -384,13 +383,13 @@ with higher granularity in the data description. field. - + Trace of the first angular axis. Could be linked from the respective 'AXISNAME_depends' field. - + Trace of the second axis. Could be linked from the respective 'AXISNAME_depends' field. diff --git a/contributed_definitions/nyaml/NXmpes_arpes.yaml b/contributed_definitions/nyaml/NXmpes_arpes.yaml index d768a90a74..f88fa7c814 100644 --- a/contributed_definitions/nyaml/NXmpes_arpes.yaml +++ b/contributed_definitions/nyaml/NXmpes_arpes.yaml @@ -11,7 +11,7 @@ NXmpes_arpes(NXmpes): (NXentry): definition: \@version: - enumeration: ["NXmpes", "NXmpes_arpes"] + enumeration: ["NXmpes_arpes"] geometries(NXcoordinate_system_set): arpes_geometry(NXcoordinate_system): depends_on(NX_CHAR): @@ -190,26 +190,26 @@ NXmpes_arpes(NXmpes): \@signal: enumeration: ["data"] # There is an object named data that contains the signal \@axes: # There are three dimensions, one energy & two angular coordinates. Any coordinates that do not move, are represented by one point. - enumeration: ["[angular1, angular2, energy]"] + enumeration: ["[angular0, angular1, energy]"] \@energy_indices: # energy indices have to be provided + \@angular0_indices: # angular0 indices have to be provided \@angular1_indices: # angular1 indices have to be provided - \@angular2_indices: # angular2 indices have to be provided + \@angular0_depends(NX_CHAR): + doc: | + Points to the path to a field defining the axis on which the angular axis depends. + For example: + @angular0_depends: '/entry/sample/transformations/sample_tilt' for a manipulator angular scan + @angular0_depends: '/entry/instrument/detector/sensor_x' for a 2D detector + @angular0_depends: '/entry/instrument/collectioncolumn/deflector' for a deflector scan + @angular0_depends: '/entry/process/calibration/angular0_calibration/calibrated_axis' for a preprocessed axis. \@angular1_depends(NX_CHAR): doc: | Points to the path to a field defining the axis on which the angular axis depends. For example: - @angular1_depends: '/entry/sample/transformations/sample_tilt' for a manipulator angular scan + @angular1_depends: '/entry/sample/transformations/sample_polar' for a manipulator angular scan @angular1_depends: '/entry/instrument/detector/sensor_x' for a 2D detector @angular1_depends: '/entry/instrument/collectioncolumn/deflector' for a deflector scan @angular1_depends: '/entry/process/calibration/angular1_calibration/calibrated_axis' for a preprocessed axis. - \@angular2_depends(NX_CHAR): - doc: | - Points to the path to a field defining the axis on which the angular axis depends. - For example: - @angular2_depends: '/entry/sample/transformations/sample_polar' for a manipulator angular scan - @angular2_depends: '/entry/instrument/detector/sensor_x' for a 2D detector - @angular2_depends: '/entry/instrument/collectioncolumn/deflector' for a deflector scan - @angular2_depends: '/entry/process/calibration/angular2_calibration/calibrated_axis' for a preprocessed axis. \@energy_depends(NX_CHAR): # Similarly, energy can be dispersed according to different strategies doc: | Points to the path to a field defining the axis on which the energy axis depends. @@ -220,10 +220,10 @@ NXmpes_arpes(NXmpes): energy(NX_NUMBER): doc: "Trace of the energy axis. Could be linked from the respective 'AXISNAME_depends' field." unit: NY_ENERGY - angular1(NX_NUMBER): + angular0(NX_NUMBER): doc: "Trace of the first angular axis. Could be linked from the respective 'AXISNAME_depends' field." unit: NX_ANGLE - angular2(NX_NUMBER): + angular1(NX_NUMBER): doc: "Trace of the second axis. Could be linked from the respective 'AXISNAME_depends' field." unit: ANX_ANGLE data(NX_NUMBER): # There is a block of numbers named data. From 90c42f1ef2bebfc4770e0852ed52f4f10cdcddbd Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 9 Apr 2024 12:11:49 +0200 Subject: [PATCH 0657/1012] Fixes for NXem --- .../NXapm_compositionspace_config.nxdl.xml | 73 +++ .../NXapm_compositionspace_results.nxdl.xml | 473 ++++++++++++++++++ .../NXebeam_column.nxdl.xml | 7 +- contributed_definitions/NXlens_em.nxdl.xml | 12 +- .../NXoptical_system_em.nxdl.xml | 2 +- .../nyaml/NXapm_compositionspace_config.yaml | 30 ++ .../nyaml/NXapm_compositionspace_results.yaml | 2 +- .../nyaml/NXebeam_column.yaml | 2 +- contributed_definitions/nyaml/NXlens_em.yaml | 12 +- .../nyaml/NXoptical_system_em.yaml | 2 +- 10 files changed, 593 insertions(+), 22 deletions(-) create mode 100644 contributed_definitions/NXapm_compositionspace_config.nxdl.xml create mode 100644 contributed_definitions/NXapm_compositionspace_results.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXapm_compositionspace_config.yaml diff --git a/contributed_definitions/NXapm_compositionspace_config.nxdl.xml b/contributed_definitions/NXapm_compositionspace_config.nxdl.xml new file mode 100644 index 0000000000..ca8bb05171 --- /dev/null +++ b/contributed_definitions/NXapm_compositionspace_config.nxdl.xml @@ -0,0 +1,73 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of voxel of discretized domain for analyzed part of the dataset. + + + + + The dimensionality of the grid. + + + + + The cardinality or total number of cells/grid points. + + + + + Number of terms in the composition clustering dictionary + + + + + Number of terms in the position clustering dictionary + + + + + Config for a run with Alaukik Saxena's composition space tool. + + This is an initial draft application definition for the common NFDI-MatWerk, + FAIRmat infrastructure use case IUC09 how to improve the organization and + results storage of the composition space tool and make these data at the + same time directly understandable for research data management systems + like NOMAD Oasis. + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml new file mode 100644 index 0000000000..b3d0fcd2ab --- /dev/null +++ b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml @@ -0,0 +1,473 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of voxel of discretized domain for analyzed part of the dataset. + + + + + The dimensionality of the grid. + + + + + The cardinality or total number of cells/grid points. + + + + + Number of terms in the composition clustering dictionary + + + + + Number of terms in the position clustering dictionary + + + + + Results of a run with Alaukik Saxena's composition space tool. + + This is an initial draft application definition for the common NFDI-MatWerk, + FAIRmat infrastructure use case IUC09 how to improve the organization and + results storage of the composition space tool and make these data at the + same time directly understandable for research data management systems + like NOMAD Oasis. + + + + + + + + + + + + + + + + + + TBD, maybe how to link between pyiron state tracking and app state tracking. + + + + + Disencouraged place for free-text for e.g. comments. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + was started, i.e. when composition space tool was started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis behind this results file + were completed and composition space tool exited as a process. + + + + + + The path and name of the config file that was used for this analysis. + TBD, this can be e.g. Alaukik's YAML file for composition space. + + + + + + + + + Details about the file (technology partner or community format) + from which reconstructed ion positions were loaded. + + + + + + + + + Details about the file (technology partner or community format) + from which ranging definitions were loaded which detail how to + map mass-to-charge-state ratios on iontypes. + + + + + + + + + + Path to the directory where the tool should store NeXus/HDF5 results + of this analysis. If not specified results will be stored in the + current working directory. + + + + + A statement whether the executable managed to process the analysis + or failed prematurely. This status is written to the results file after the + end_time at which point the executable must not compute any analysis. + Only when this status message is present and shows `success`, the + user should consider the results. In all other cases it might be + that the executable has terminated prematurely or another error + occurred. + + + + + + + + + If used, contact information and eventually details + of at least the person who performed this analysis. + + + + + + + + + Details about coordinate systems (reference frames) used. In atom probe several coordinate + systems have to be distinguished. Names of instances of such :ref:`NXcoordinate_system` + should be documented explicitly and doing so by picking from the + following controlled set of names: + + * composition_space + * lab + * specimen + * laser + * instrument + * detector + * recon + + The aim of this convention is to support users with contextualizing which reference + frame each instance (coordinate system) is. If needed, instances of :ref:`NXtransformations` + are used to detail the explicit affine transformations whereby one can convert + representations between different reference frames. + Inspect :ref:`NXtransformations` for further details. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Reference to or definition of a coordinate system with + which the positions and directions are interpretable. + + + + + + + + + + Position of each cell in Euclidean space. + + + + + + + + + + + + + + + + For each ion, the identifier of the voxel in which the ion is located. + + + + + + + + + + + + + + + + + + In Alaukik's tool the GMM step. + + + + + + + + + The keywords of the dictionary of distinguished compositionally- + defined cluster, e.g. the phases. Examples for keywords could be + phase1, phase2, and so one and so forth. + + + + + + + + Resolves for each keyword in cluster_dict which integer is used to + label something that it belongs or is assumed to represent this + cluster. + + + + + + + + + For example if the voxel grid is used to report that there + are voxels which are assumed to represent volume of either phase1 + or phase2, the cluster_dict_keyword would be a list with two names + phase1 and phase2, respectively. The cluster_dict_value would be a + list of e.g. integers 1 and 2. These could be used to build an + array with as many entries as there are voxel and store in this array + the respective value to encode which phase is assumed for each voxel. + + + + + + + + + + In Alaukik's tool the DBScan step after the GMM step. + + + + + + + + + The keywords of the dictionary of distinguished spatially-contiguous + clusters. Examples for keywords could be precipitate1, precipitate2, + and so one and so forth. + + + + + + + + Resolves for each keyword in cluster_dict which integer is used to + label something that it belongs or is assumed to represent this + cluster. + + + + + + + + + For example if the voxel grid is used to report that there + are voxels which are assumed to represent volume of certain precipitates, + say we found ten precipitates and consider the rest as matrix. + We could make a list of say matrix, precipitate1, precipitate2, ..., + precipitate10. With cluster_dict_value then running from 0 to 10, + i.e. matrix is flagged special as 0 and the remaining particles + are indexed conveniently as 1, 2, ..., 10 like end users expect. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specify if it was different from the number_of_processes + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + Specify if it was different from the number_of_threads + in the NXcs_profiling super class. + + + + + + + + + diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml index 140a844ed1..f91ae3ac7c 100644 --- a/contributed_definitions/NXebeam_column.nxdl.xml +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -77,13 +77,8 @@ part "an electron gun" reusable in other context--> If the emitter type is other, give further details in the description field. - - - - - - + Material of which the emitter is build, e.g. the filament material. diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml index 88dbc1e624..675a1b1ef4 100644 --- a/contributed_definitions/NXlens_em.nxdl.xml +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -87,18 +87,18 @@ with other research fields (MPES, XPS, OPT) could be useful--> - This field should be used when the exact voltage or current of the lens - is not directly controllable as the control software of the microscope - does not enable or was not configured to display these values. + This field should be used when the exact voltage or current of the lens is not + directly controllable as the control software of the microscope does not enable + or was not configured to display these values (for end users). In this case this value field should be used and the value from the control software stored as is. Although this value does not document the exact physical voltage or excitation, it can still give useful context to reproduce the lens setting, - which, provided a properly working instrument and software sets the lens - into a similar state to the technical level possible when no more information - is available physically or accessible legally. + provided a properly working instrument and software sets the lens + into a similar state to the technical level possible when no more + information is available physically or accessible legally. diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/contributed_definitions/NXoptical_system_em.nxdl.xml index 0611984a77..abd689d83f 100644 --- a/contributed_definitions/NXoptical_system_em.nxdl.xml +++ b/contributed_definitions/NXoptical_system_em.nxdl.xml @@ -48,7 +48,7 @@ work of the HMC EM glossary activities--> - Citing the JEOL TEM glosssary this is the value *when a cone shaped, + Citing the JEOL TEM glossary this is the value *when a cone shaped, convergent electron beam illuminates a specimen, the semi-angle of the cone is termed convergence angle.* diff --git a/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml b/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml new file mode 100644 index 0000000000..9cd6d87515 --- /dev/null +++ b/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml @@ -0,0 +1,30 @@ +category: application +doc: | + Config for a run with Alaukik Saxena's composition space tool. + + This is an initial draft application definition for the common NFDI-MatWerk, + FAIRmat infrastructure use case IUC09 how to improve the organization and + results storage of the composition space tool and make these data at the + same time directly understandable for research data management systems + like NOMAD Oasis. +symbols: + doc: | + The symbols used in the schema to specify e.g. dimensions of arrays. + n_voxel: | + Number of voxel of discretized domain for analyzed part of the dataset. + d: | + The dimensionality of the grid. + c: | + The cardinality or total number of cells/grid points. + n_clst_dict: | + Number of terms in the composition clustering dictionary + n_spat_dict: | + Number of terms in the position clustering dictionary +type: group +NXapm_compositionspace_config(NXobject): + # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently + (NXentry): + exists: [min, 1, max, 1] + definition(NX_CHAR): + \@version(NX_CHAR): + enumeration: [NXapm_compositionspace_config] diff --git a/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml b/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml index c0cfe8a224..e37fb54fd2 100644 --- a/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml +++ b/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml @@ -21,7 +21,7 @@ symbols: n_spat_dict: | Number of terms in the position clustering dictionary type: group -NXapm_composition_space_results(NXobject): +NXapm_compositionspace_results(NXobject): # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently (NXentry): exists: [min, 1, max, 1] diff --git a/contributed_definitions/nyaml/NXebeam_column.yaml b/contributed_definitions/nyaml/NXebeam_column.yaml index 2f56343305..119b375a30 100644 --- a/contributed_definitions/nyaml/NXebeam_column.yaml +++ b/contributed_definitions/nyaml/NXebeam_column.yaml @@ -42,7 +42,7 @@ NXebeam_column(NXobject): If the emitter type is other, give further details in the description field. - enumeration: [filament, schottky, cold_cathode_field_emitter, other] + # enumeration: [filament, schottky, cold_cathode_field_emitter, other] emitter_material(NX_CHAR): doc: | Material of which the emitter is build, e.g. the filament material. diff --git a/contributed_definitions/nyaml/NXlens_em.yaml b/contributed_definitions/nyaml/NXlens_em.yaml index fb7c5b99bd..7c9fba6b00 100644 --- a/contributed_definitions/nyaml/NXlens_em.yaml +++ b/contributed_definitions/nyaml/NXlens_em.yaml @@ -50,18 +50,18 @@ NXlens_em(NXobject): unit: NX_CURRENT value(NX_NUMBER): doc: | - This field should be used when the exact voltage or current of the lens - is not directly controllable as the control software of the microscope - does not enable or was not configured to display these values. + This field should be used when the exact voltage or current of the lens is not + directly controllable as the control software of the microscope does not enable + or was not configured to display these values (for end users). In this case this value field should be used and the value from the control software stored as is. Although this value does not document the exact physical voltage or excitation, it can still give useful context to reproduce the lens setting, - which, provided a properly working instrument and software sets the lens - into a similar state to the technical level possible when no more information - is available physically or accessible legally. + provided a properly working instrument and software sets the lens + into a similar state to the technical level possible when no more + information is available physically or accessible legally. unit: NX_ANY mode(NX_CHAR): doc: | diff --git a/contributed_definitions/nyaml/NXoptical_system_em.yaml b/contributed_definitions/nyaml/NXoptical_system_em.yaml index 08c0152083..f98fbaa4b7 100644 --- a/contributed_definitions/nyaml/NXoptical_system_em.yaml +++ b/contributed_definitions/nyaml/NXoptical_system_em.yaml @@ -23,7 +23,7 @@ NXoptical_system_em(NXobject): See respective details in :ref:`NXaberration` class instances. semi_convergence_angle(NX_NUMBER): doc: | - Citing the JEOL TEM glosssary this is the value *when a cone shaped, + Citing the JEOL TEM glossary this is the value *when a cone shaped, convergent electron beam illuminates a specimen, the semi-angle of the cone is termed convergence angle.* unit: NX_ANGLE From 27aea67967a5885ab353d0727ed1e8a32986f1b7 Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Tue, 9 Apr 2024 12:39:09 +0200 Subject: [PATCH 0658/1012] Fixed definition error --- contributed_definitions/NXapm_compositionspace_results.nxdl.xml | 2 +- .../nyaml/NXapm_compositionspace_results.yaml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml index b3d0fcd2ab..f3b68b6a43 100644 --- a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml +++ b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml @@ -66,7 +66,7 @@ - + Collection of axis-based translations and rotations to describe the location and diff --git a/contributed_definitions/nyaml/NXdeflector.yaml b/contributed_definitions/nyaml/NXdeflector.yaml index 933798809e..2f32bc8caa 100644 --- a/contributed_definitions/nyaml/NXdeflector.yaml +++ b/contributed_definitions/nyaml/NXdeflector.yaml @@ -41,8 +41,6 @@ NXdeflector(NXobject): doc: | Specifies the position of the deflector by pointing to the last transformation in the transformation chain in the NXtransformations group. - - # discuss NXcomponent_mpes ? (NXtransformations): doc: | Collection of axis-based translations and rotations to describe the location and @@ -55,7 +53,7 @@ NXdeflector(NXobject): the reference coordinate system. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 0a4b2319a9b964e563adfe3b7206dae2a9667bb19228346d3c3d011d74c1166c +# e16416dcbac006d9e2a7fff7c0ed1d61a6bed2d1f6254a419f10f6ab36922cc5 # # # # # # Collection of axis-based translations and rotations to describe the location and From 4b7cd35e16845cc7d355e41874e8f2ea8a588fad Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 10 Apr 2024 15:55:12 +0200 Subject: [PATCH 0660/1012] unix line endings for NXbeam* yaml files --- .../nyaml/NXbeam_device.yaml | 80 ++++----- .../nyaml/NXbeam_transfer_matrix_table.yaml | 170 +++++++++--------- 2 files changed, 125 insertions(+), 125 deletions(-) diff --git a/contributed_definitions/nyaml/NXbeam_device.yaml b/contributed_definitions/nyaml/NXbeam_device.yaml index 3af998a41e..3e1a236b6b 100644 --- a/contributed_definitions/nyaml/NXbeam_device.yaml +++ b/contributed_definitions/nyaml/NXbeam_device.yaml @@ -1,41 +1,41 @@ -category: base -doc: | - Properties of generic beam device in an experimental setup. - - Any beam related devices like source, detector, filter, mirror, - beamsplitter, ... which may modifies a beam in an experimental setup - can be described here with its experimental position and relationship - to the other beam devices in the setup. - - -NXbeam_device(NXobject): - - previous_devices: - doc: | - Single device or list of devices pointing to the devices from which an - beam originated to reach this device. - This is used to describe a logical order of devices and for the whole setup. - In this way, a "beam path" can be described (i.e., with starting point (light source) - and end point (photo detector)). - - Example: /entry/instrument/detector. - purpose(NX_CHAR): - doc: | - Description of the intended purpose of this device for - the experimental setup. - - group(NX_CHAR): - doc: | - Name of the group with which this device can be associated. - For example, if a group of devices is used for second harmonic generation, - all these devices have the group name "second harmonic generation". - Is used for simplified setup vizualization (or description?). - - - (NXtransformations): - doc: | - Location and orientation of the device. Note that even a - simple distance can be given as a translation. - - You can use the @depends_on to describe from which device +category: base +doc: | + Properties of generic beam device in an experimental setup. + + Any beam related devices like source, detector, filter, mirror, + beamsplitter, ... which may modifies a beam in an experimental setup + can be described here with its experimental position and relationship + to the other beam devices in the setup. + + +NXbeam_device(NXobject): + + previous_devices: + doc: | + Single device or list of devices pointing to the devices from which an + beam originated to reach this device. + This is used to describe a logical order of devices and for the whole setup. + In this way, a "beam path" can be described (i.e., with starting point (light source) + and end point (photo detector)). + + Example: /entry/instrument/detector. + purpose(NX_CHAR): + doc: | + Description of the intended purpose of this device for + the experimental setup. + + group(NX_CHAR): + doc: | + Name of the group with which this device can be associated. + For example, if a group of devices is used for second harmonic generation, + all these devices have the group name "second harmonic generation". + Is used for simplified setup vizualization (or description?). + + + (NXtransformations): + doc: | + Location and orientation of the device. Note that even a + simple distance can be given as a translation. + + You can use the @depends_on to describe from which device the transformation needs to be applied. \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXbeam_transfer_matrix_table.yaml b/contributed_definitions/nyaml/NXbeam_transfer_matrix_table.yaml index 1c75fe05a2..fd9304c606 100644 --- a/contributed_definitions/nyaml/NXbeam_transfer_matrix_table.yaml +++ b/contributed_definitions/nyaml/NXbeam_transfer_matrix_table.yaml @@ -1,85 +1,85 @@ -category: base -doc: | - Contains datastructures of an experimental optical setup (i.e., multiple - transfermatrix tables). These datastructures are used to relate physical - properties of two beams (NXbeam) which have one common optical element - (NXopt_element) (one specific transfermatrix). - One of these beams in an input beam and the other one is an output beam. - - The data describes the change of beam properties, e.g. the intensity of a - beam is reduced because the transmission coefficient of the beam device is - lower than 1. -symbols: - doc: | - Variables used throughout the document, e.g. dimensions or parameters. - N_variables: | - Length of the array associated to the data type. -NXbeam_transfer_matrix_table(NXobject): - datatype_N: - doc: | - Select which type of data was recorded, for example aperture and - focal length. - It is possible to have multiple selections. This selection defines - how many columns (N_variables) are stored in the data array. - N in the name, is the index number in which order the given - property is listed. - enumeration: - [ - aperture, - focallength, - orientation, - jones matrix, - ] - matrix_elements: - doc: | - Please list in this array the column and row names used in your actual data. - That is in the case of aperture ['diameter'] or focal length ['focal_length_value'] - and for orientation matrix ['OM1', 'OM2', 'OM3'] or for jones matrix - ['JM1','JM2'] - dimensions: - rank: 1 - dim: [[1, N_variables]] - - TRANSFER_MATRIX(NX_NUMBER): - doc: | - Contains the datastructure which relates beam properties of an - input and output beam as result of the input beam interaction - with the beam device. - - Transfermatrix relationship between N input beams and M output beams. - It contains a table with the relevant matricis to be used for different - transmissitted properties (such as polarization, intensity, phase). - - Data structure for all transfermatrices of an beam device in a setup. - For each combination of N input and M output beams and for L physical - concept (i.e. beam intensity), one matrix can be defined. - - In this way, the transfermatrix table has the dimension NxM. - - For each entry, in this transfermatrix, there are L formalisms. - Each formalism has the dimension math:`dim(L_i)xdim(L_i)`, - whereby math:`L_i` is the specific physical concept (Intensity, polarization, direction). - - A beamsplitter with two input laser beams can have a total of - four transfermatrices (2 Input x 2 Output). - - The dimension of the transfermatrix depends on the parameters. - Examples are: - 1x1 for intensity/power - 2x2 for jones formalism - 3x3 for direction - dimensions: - doc: | - Square matrix with dimension N_variables x N_variables - rank: 2 - dim: - [ - [1, N_variables], - [2, N_variables], - ] - \@input: - doc: | - Specific name of input beam which the transfermatrix table is related to. - \@output: - doc: | - Specific name of output beam which the transfermatrix table is related to. +category: base +doc: | + Contains datastructures of an experimental optical setup (i.e., multiple + transfermatrix tables). These datastructures are used to relate physical + properties of two beams (NXbeam) which have one common optical element + (NXopt_element) (one specific transfermatrix). + One of these beams in an input beam and the other one is an output beam. + + The data describes the change of beam properties, e.g. the intensity of a + beam is reduced because the transmission coefficient of the beam device is + lower than 1. +symbols: + doc: | + Variables used throughout the document, e.g. dimensions or parameters. + N_variables: | + Length of the array associated to the data type. +NXbeam_transfer_matrix_table(NXobject): + datatype_N: + doc: | + Select which type of data was recorded, for example aperture and + focal length. + It is possible to have multiple selections. This selection defines + how many columns (N_variables) are stored in the data array. + N in the name, is the index number in which order the given + property is listed. + enumeration: + [ + aperture, + focallength, + orientation, + jones matrix, + ] + matrix_elements: + doc: | + Please list in this array the column and row names used in your actual data. + That is in the case of aperture ['diameter'] or focal length ['focal_length_value'] + and for orientation matrix ['OM1', 'OM2', 'OM3'] or for jones matrix + ['JM1','JM2'] + dimensions: + rank: 1 + dim: [[1, N_variables]] + + TRANSFER_MATRIX(NX_NUMBER): + doc: | + Contains the datastructure which relates beam properties of an + input and output beam as result of the input beam interaction + with the beam device. + + Transfermatrix relationship between N input beams and M output beams. + It contains a table with the relevant matricis to be used for different + transmissitted properties (such as polarization, intensity, phase). + + Data structure for all transfermatrices of an beam device in a setup. + For each combination of N input and M output beams and for L physical + concept (i.e. beam intensity), one matrix can be defined. + + In this way, the transfermatrix table has the dimension NxM. + + For each entry, in this transfermatrix, there are L formalisms. + Each formalism has the dimension math:`dim(L_i)xdim(L_i)`, + whereby math:`L_i` is the specific physical concept (Intensity, polarization, direction). + + A beamsplitter with two input laser beams can have a total of + four transfermatrices (2 Input x 2 Output). + + The dimension of the transfermatrix depends on the parameters. + Examples are: + 1x1 for intensity/power + 2x2 for jones formalism + 3x3 for direction + dimensions: + doc: | + Square matrix with dimension N_variables x N_variables + rank: 2 + dim: + [ + [1, N_variables], + [2, N_variables], + ] + \@input: + doc: | + Specific name of input beam which the transfermatrix table is related to. + \@output: + doc: | + Specific name of output beam which the transfermatrix table is related to. From 13110f24d3fdb0b58055cab26eb444e2985f9e19 Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Wed, 10 Apr 2024 16:43:23 +0200 Subject: [PATCH 0661/1012] Show git diff on consistency check failure (#211) * Show git diff on constitency check failure * Revert NXmpes test change * Reintroduce whitespace --- .github/workflows/fairmat-nxdl-yaml-consistency.yaml | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/.github/workflows/fairmat-nxdl-yaml-consistency.yaml b/.github/workflows/fairmat-nxdl-yaml-consistency.yaml index 64a78fc19e..5234937c6d 100644 --- a/.github/workflows/fairmat-nxdl-yaml-consistency.yaml +++ b/.github/workflows/fairmat-nxdl-yaml-consistency.yaml @@ -26,4 +26,7 @@ jobs: with: fail-if-not-clean: true request-changes-if-not-clean: false - push-if-not-clean: false \ No newline at end of file + push-if-not-clean: false + - name: git diff + if: failure() + run: git diff \ No newline at end of file From 6540c3b634d70c7f5d1a4c346cb3da375e792d4d Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Thu, 11 Apr 2024 09:53:10 +0200 Subject: [PATCH 0662/1012] Change associated_beam and _source to NX_CHAR (#212) --- contributed_definitions/NXmpes.nxdl.xml | 22 ++++++++++++---------- contributed_definitions/nyaml/NXmpes.yaml | 18 ++++++++++-------- 2 files changed, 22 insertions(+), 18 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 238e5c3b8c..79f50167f8 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -195,15 +195,16 @@ - + - The beam emitted by this source. + A reference to a beam emitted by this source. Should be named with the same appendix, e.g., for `source_probe` it should refer to `beam_probe`. - Refers to the same concept as /NXentry/NXinstrument/beamTYPE - and may be linked. + + Example: + * /entry/instrument/source_probe = /entry/instrument/beam_probe - + @@ -223,16 +224,17 @@ - + The source that emitted this beam. Should be named with the same appendix, e.g., for `beam_probe` it should refer to `source_probe`. - Refers to the same concept as /NXentry/NXinstrument/sourceTYPE - and may be linked. - Should be specified if an associated source exists. + This should be specified if an associated source exists. + + Example: + * /entry/instrument/beam_probe = /entry/instrument/source_probe - + diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 3660047c15..3e4525615e 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -148,13 +148,14 @@ NXmpes(NXobject): exists: recommended identifier: exists: recommended - associated_beam(NXbeam): + associated_beam(NX_CHAR): doc: | - The beam emitted by this source. + A reference to a beam emitted by this source. Should be named with the same appendix, e.g., for `source_probe` it should refer to `beam_probe`. - Refers to the same concept as /NXentry/NXinstrument/beamTYPE - and may be linked. + + Example: + * /entry/instrument/source_probe = /entry/instrument/beam_probe beamTYPE(NXbeam): doc: | Properties of the photon beam at a given location. @@ -178,15 +179,16 @@ NXmpes(NXobject): unit: NX_ANY extent(NX_FLOAT): exists: recommended - associated_source(NXsource): + associated_source(NX_CHAR): exists: recommended doc: | The source that emitted this beam. Should be named with the same appendix, e.g., for `beam_probe` it should refer to `source_probe`. - Refers to the same concept as /NXentry/NXinstrument/sourceTYPE - and may be linked. - Should be specified if an associated source exists. + This should be specified if an associated source exists. + + Example: + * /entry/instrument/beam_probe = /entry/instrument/source_probe (NXelectronanalyser): device_information(NXfabrication): exists: recommended From fae3742c04b615bcfd833e70005d0e30aab157cb Mon Sep 17 00:00:00 2001 From: mkuehbach Date: Thu, 11 Apr 2024 13:22:56 +0200 Subject: [PATCH 0663/1012] Updated version of NXapm_compositionspace_* appdefs and documentation of the context that is to this work between NFDI-MatWerk and FAIRmat --- .../NXapm_compositionspace_config.nxdl.xml | 109 +++ .../NXapm_compositionspace_results.nxdl.xml | 402 ++++----- .../nyaml/NXapm_compositionspace_config.yaml | 84 ++ .../nyaml/NXapm_compositionspace_results.yaml | 852 +++--------------- .../contributed_definitions/apm-structure.rst | 17 + 5 files changed, 486 insertions(+), 978 deletions(-) diff --git a/contributed_definitions/NXapm_compositionspace_config.nxdl.xml b/contributed_definitions/NXapm_compositionspace_config.nxdl.xml index ca8bb05171..fe14ad5f23 100644 --- a/contributed_definitions/NXapm_compositionspace_config.nxdl.xml +++ b/contributed_definitions/NXapm_compositionspace_config.nxdl.xml @@ -69,5 +69,114 @@ + + + + + + + + + + + + + + + + + + + + + Edge length of the grid that is used to discretize the point cloud in the + voxelization step. + + + + + TODO + + + + + TODO + + + + + The configuration of the machine learning model used in the segmentation step. + + + + Name of the model to be used. + + + + + Configuration for the Gaussian mixture model. + + + + TODO + + + + + TODO + + + + + Report debug information yes or no. + + + + + + Configuration for the random forest model. + + + + TODO + + + + + TODO + + + + + + Configuration for the DBScan used in the clustering step. + + + + TODO + + + + + TODO + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml index f3b68b6a43..42f650503d 100644 --- a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml +++ b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml @@ -26,11 +26,6 @@ The symbols used in the schema to specify e.g. dimensions of arrays. - - - Number of voxel of discretized domain for analyzed part of the dataset. - - The dimensionality of the grid. @@ -41,16 +36,6 @@ The cardinality or total number of cells/grid points. - - - Number of terms in the composition clustering dictionary - - - - - Number of terms in the position clustering dictionary - - Results of a run with Alaukik Saxena's composition space tool. @@ -71,7 +56,7 @@ - + @@ -86,14 +71,14 @@ for if desired all the dependencies and libraries--> Disencouraged place for free-text for e.g. comments. - + ISO 8601 formatted time code with local time zone offset to UTC information included when the analysis behind this results file was started, i.e. when composition space tool was started as a process. - + ISO 8601 formatted time code with local time zone offset to UTC information included when the analysis behind this results file @@ -111,61 +96,9 @@ for if desired all the dependencies and libraries--> - - - Details about the file (technology partner or community format) - from which reconstructed ion positions were loaded. - - - - - - - - - Details about the file (technology partner or community format) - from which ranging definitions were loaded which detail how to - map mass-to-charge-state ratios on iontypes. - - - - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the executable managed to process the analysis - or failed prematurely. This status is written to the results file after the - end_time at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - + + Details about coordinate systems (reference frames) used. In atom probe several coordinate systems have to be distinguished. Names of instances of such :ref:`NXcoordinate_system` @@ -186,13 +119,38 @@ for if desired all the dependencies and libraries--> representations between different reference frames. Inspect :ref:`NXtransformations` for further details. + + + + + + + + + + + + + + + + + + + - - - - + + Voxelization is the first step of the algorithmic chain that the + CompositionSpace tool implements. In this step all ion positions are + discretized using a rectangular transfer function to identify the number + of ions/atoms in the dataset of each iontype. + + Using a discretization grid that is larger than the average distance + between reconstructed ion position reduces the computational costs. + This is the key idea of the CompositionSpace tool over other methods + traditionally used in atom probe (e.g. isosurfaces). + @@ -206,8 +164,6 @@ inspect the example of the NXem_ebsd application definition--> - - @@ -270,204 +226,150 @@ if one coordinate system is defined the origin is defined in this cs--> - + - + + + TODO + - + - - - - In Alaukik's tool the GMM step. - - - - - - - + - The keywords of the dictionary of distinguished compositionally- - defined cluster, e.g. the phases. Examples for keywords could be - phase1, phase2, and so one and so forth. + TODO - - - - - - Resolves for each keyword in cluster_dict which integer is used to - label something that it belongs or is assumed to represent this - cluster. - - - - - - - - - For example if the voxel grid is used to report that there - are voxels which are assumed to represent volume of either phase1 - or phase2, the cluster_dict_keyword would be a list with two names - phase1 and phase2, respectively. The cluster_dict_value would be a - list of e.g. integers 1 and 2. These could be used to build an - array with as many entries as there are voxel and store in this array - the respective value to encode which phase is assumed for each voxel. - - - + - - + - In Alaukik's tool the DBScan step after the GMM step. + Segmentation is the second step of the algorithmic chain that the + CompositionSpace tool implements. In this step a machine learning model + is used to identify how voxels cluster in composition space to identify + which chemically disjoint phases exists in the atom probe dataset. - - - - - - - - The keywords of the dictionary of distinguished spatially-contiguous - clusters. Examples for keywords could be precipitate1, precipitate2, - and so one and so forth. - - - - - - - - Resolves for each keyword in cluster_dict which integer is used to - label something that it belongs or is assumed to represent this - cluster. - - - - - - - + - For example if the voxel grid is used to report that there - are voxels which are assumed to represent volume of certain precipitates, - say we found ten precipitates and consider the rest as matrix. - We could make a list of say matrix, precipitate1, precipitate2, ..., - precipitate10. With cluster_dict_value then running from 0 to 10, - i.e. matrix is flagged special as 0 and the remaining particles - are indexed conveniently as 1, 2, ..., 10 like end users expect. + PCA in the parameter space of iontypes/phases of different chemical nature. - - - - - - - - - - - - - - - - - - - + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. + TODO + + + - - + - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. + TODO + + + - - + + + + + Information criterion minimization. + + + + + + + + + TODO + + - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. + TODO - - + + + TODO + + + + + + + + Clustering is the third step of the algorithmic chain that the CompositionSpace + tool implements. In this step the different voxelized regions in the dataset with + eventually different chemical nature are analyzed if they are distributed in + connected groups of voxels with the same chemical nature. + Using the discretization grid from the first step as the support, this enables + to prepare for the fourth step. In the fourth step the interfaces between + identified groups of different chemical nature are triangulated. + + These triangulated network of interfaces between regions of different chemical + nature is the final data structure that the CompositionSpace tool yields. + Subsequently, this mesh can be post-processed, similarly like meshes that are + obtained from isosurface-based approaches, to perform line profile analyses. + + + + + + + + + + TODO + + + + + TODO + + + + + TODO total number of (phases) distinguished. + + + + + TODO raw labels output of the DBScan clustering algorithm. Length of array varies depending on how + many voxels of the grid were identified of the targetted + phase/chemical nature. + + + + + + + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml b/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml index 9cd6d87515..49b989240b 100644 --- a/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml +++ b/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml @@ -28,3 +28,87 @@ NXapm_compositionspace_config(NXobject): definition(NX_CHAR): \@version(NX_CHAR): enumeration: [NXapm_compositionspace_config] + config(NXobject): + (NXidentifier): + exists: optional + analysis_identifier(NX_UINT): + exists: recommended + reconstruction(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + position(NX_CHAR): + mass_to_charge(NX_CHAR): + ranging(NXserialized): + type(NX_CHAR): + path(NX_CHAR): + checksum(NX_CHAR): + algorithm(NX_CHAR): + ranging_definitions(NX_CHAR): + voxel_size(NX_FLOAT): + doc: | + Edge length of the grid that is used to discretize the point cloud in the voxelization step. + unit: NX_LENGTH + bics_clusters(NX_UINT): + doc: | + TODO + unit: NX_UNITLESS + n_phases(NX_UINT): + doc: | + TODO + unit: NX_UNITLESS + ml_models(NXobject): + doc: | + The configuration of the machine learning model used in the segmentation step. + name(NX_CHAR): + doc: | + Name of the model to be used. + gaussian_mixture(NXobject): + doc: | + Configuration for the Gaussian mixture model. + n_components(NX_UINT): + doc: | + TODO + unit: NX_UNITLESS + max_iter(NX_UINT): + doc: | + TODO + unit: NX_UNITLESS + verbose(NX_BOOLEAN): + doc: | + Report debug information yes or no. + random_forest(NXobject): + doc: | + Configuration for the random forest model. + max_depth(NX_UINT): + doc: | + TODO + unit: NX_UNITLESS + n_estimators(NX_UINT): + doc: | + TODO + unit: NX_UNITLESS + dbscan(NXobject): + doc: | + Configuration for the DBScan used in the clustering step. + eps(NX_FLOAT): + doc: | + TODO + unit: NX_LENGTH + min_samples(NX_UINT): + doc: | + TODO + unit: NX_UNITLESS + common(NXobject): + status(NX_CHAR): + programID(NXprogram): + exists: [min, 1, max, infty] + program(NX_CHAR): + \@version(NX_CHAR): + profiling(NXcs_profiling): + exists: recommended + start_time(NX_DATE_TIME): + end_time(NX_DATE_TIME): + total_elapsed_time(NX_FLOAT): + current_working_directory(NX_CHAR): diff --git a/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml b/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml index d327365be1..abf0329bca 100644 --- a/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml +++ b/contributed_definitions/nyaml/NXapm_compositionspace_results.yaml @@ -10,16 +10,10 @@ doc: | symbols: doc: | The symbols used in the schema to specify e.g. dimensions of arrays. - n_voxel: | - Number of voxel of discretized domain for analyzed part of the dataset. d: | The dimensionality of the grid. c: | The cardinality or total number of cells/grid points. - n_clst_dict: | - Number of terms in the composition clustering dictionary - n_spat_dict: | - Number of terms in the position clustering dictionary type: group NXapm_compositionspace_results(NXobject): # by default for appdefs the value of the exists keyword is required unless it is explicitly specified differently @@ -30,8 +24,8 @@ NXapm_compositionspace_results(NXobject): enumeration: [NXapm_compositionspace_results] # can be used for the name of the tool and version but also # for if desired all the dependencies and libraries - (NXprogram): - exists: [min, 1, max, infty] + program(NXprogram): + exists: [min, 1, max, 1] program(NX_CHAR): \@version(NX_CHAR): job_pyiron_identifier(NX_CHAR): @@ -43,11 +37,13 @@ NXapm_compositionspace_results(NXobject): doc: | Disencouraged place for free-text for e.g. comments. start_time(NX_DATE_TIME): + exists: recommended doc: | ISO 8601 formatted time code with local time zone offset to UTC information included when the analysis behind this results file was started, i.e. when composition space tool was started as a process. end_time(NX_DATE_TIME): + exists: recommended doc: | ISO 8601 formatted time code with local time zone offset to UTC information included when the analysis behind this results file @@ -61,54 +57,11 @@ NXapm_compositionspace_results(NXobject): path(NX_CHAR): algorithm(NX_CHAR): checksum(NX_CHAR): - reconstruction(NXserialized): - doc: | - Details about the file (technology partner or community format) - from which reconstructed ion positions were loaded. - type(NX_CHAR): - path(NX_CHAR): - algorithm(NX_CHAR): - checksum(NX_CHAR): - ranging(NXserialized): - doc: | - Details about the file (technology partner or community format) - from which ranging definitions were loaded which detail how to - map mass-to-charge-state ratios on iontypes. - type(NX_CHAR): - path(NX_CHAR): - algorithm(NX_CHAR): - checksum(NX_CHAR): # results - results_path(NX_CHAR): - exists: optional - doc: | - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - status(NX_CHAR): - doc: | - A statement whether the executable managed to process the analysis - or failed prematurely. This status is written to the results file after the - end_time at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - enumeration: [success, failure] (NXuser): - exists: recommended - doc: | - If used, contact information and eventually details - of at least the person who performed this analysis. - name(NX_CHAR): - exists: recommended - affiliation(NX_CHAR): - exists: optional - (NXidentifier): - exists: optional - role(NX_CHAR): - exists: optional - (NXcoordinate_system_set): + exists: optional + coordinate_system_set(NXcoordinate_system_set): + exists: [min, 1, max, 1] doc: | Details about coordinate systems (reference frames) used. In atom probe several coordinate systems have to be distinguished. Names of instances of such :ref:`NXcoordinate_system` @@ -128,11 +81,29 @@ NXapm_compositionspace_results(NXobject): are used to detail the explicit affine transformations whereby one can convert representations between different reference frames. Inspect :ref:`NXtransformations` for further details. - (NXcoordinate_system): - (NXtransformations): - # add further fields coming from using the charge state recovery - # workflow from the ifes_apt_tc_data_modeling library + compositionspace(NXcoordinate_system): + type(NX_CHAR): + handedness(NX_CHAR): + x(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + y(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) + z(NX_NUMBER): + unit: NX_LENGTH + dim: (3,) voxelization(NXprocess): + doc: | + Voxelization is the first step of the algorithmic chain that the + CompositionSpace tool implements. In this step all ion positions are + discretized using a rectangular transfer function to identify the number + of ions/atoms in the dataset of each iontype. + + Using a discretization grid that is larger than the average distance + between reconstructed ion position reduces the computational costs. + This is the key idea of the CompositionSpace tool over other methods + traditionally used in atom probe (e.g. isosurfaces). sequence_index(NX_POSINT): enumeration: [1] # specify the grid your using and for each ion in which cell i.e. voxel it is @@ -143,10 +114,9 @@ NXapm_compositionspace_results(NXobject): (NXcg_grid): dimensionality(NX_POSINT): unit: NX_UNITLESS - enumeration: [1, 2, 3] + enumeration: [3] cardinality(NX_POSINT): unit: NX_UNITLESS - # default behaviour, if no coordinate system defined, unclear # if one coordinate system is defined the origin is defined in this cs origin(NX_NUMBER): @@ -188,7 +158,6 @@ NXapm_compositionspace_results(NXobject): dimensions: rank: 2 dim: [[1, c], [2, d]] - # bounding box if needed voxel_identifier(NX_UINT): unit: NX_UNITLESS @@ -197,683 +166,110 @@ NXapm_compositionspace_results(NXobject): dimensions: rank: 1 dim: [[1, n_ions]] - (NXion): - exists: ['min', '0', 'max', 'unbounded'] + ionID(NXion): + exists: [min, 0, max, infty] name: - composition(NX_FLOAT): - dimensions: - rank: 1 - dim: [[1, n_voxel]] - clustering_composition_space(NXprocess): - doc: | - In Alaukik's tool the GMM step. - sequence_index(NX_POSINT): - enumeration: [2] - cluster_dict_keyword: + weight(NX_FLOAT): + doc: | + TODO + dim: (c,) + unit: NX_UNITLESS + total(NX_FLOAT): doc: | - The keywords of the dictionary of distinguished compositionally- - defined cluster, e.g. the phases. Examples for keywords could be - phase1, phase2, and so one and so forth. - dimensions: - rank: 1 - dim: [[1, n_clst_dict]] - cluster_dict_value(NX_UINT): + TODO + dim: (c,) unit: NX_UNITLESS + segmentation(NXprocess): + exists: [min, 1, max, 1] + doc: | + Segmentation is the second step of the algorithmic chain that the + CompositionSpace tool implements. In this step a machine learning model + is used to identify how voxels cluster in composition space to identify + which chemically disjoint phases exists in the atom probe dataset. + pca(NXprocess): doc: | - Resolves for each keyword in cluster_dict which integer is used to - label something that it belongs or is assumed to represent this - cluster. - dimensions: - rank: 1 - dim: [[1, n_clst_dict]] - - # again for fuzzy or probabilistic multi solution approaches see NXem_ebsd - cluster_identifier(NX_UINT): - unit: NX_UNITLESS + PCA in the parameter space of iontypes/phases of different chemical nature. + sequence_index(NX_POSINT): + enumeration: [2] + results(NXdata): + \@signal(NX_CHAR): + \@axes(NX_CHAR): + \@AXISNAME(NX_CHAR): + axis_explained_variance(NX_FLOAT): + doc: | + TODO + unit: NX_DIMENSIONLESS + dim: (i,) + axis_pca_dimension(NX_UINT): + doc: | + TODO + unit: NX_UNITLESS + dim: (i,) + ic_opt(NXprocess): doc: | - For example if the voxel grid is used to report that there - are voxels which are assumed to represent volume of either phase1 - or phase2, the cluster_dict_keyword would be a list with two names - phase1 and phase2, respectively. The cluster_dict_value would be a - list of e.g. integers 1 and 2. These could be used to build an - array with as many entries as there are voxel and store in this array - the respective value to encode which phase is assumed for each voxel. - dimensions: - rank: 1 - dim: [[1, n_voxel]] - - # use the fact that with e.g. XDMF one can on-the-fly reinterpret - # a 1d array to represent an explicit 3d grid - # default plots would be nice could directly be integrated in the results file - clustering_real_space(NXprocess): + Information criterion minimization. + sequence_index(NX_POSINT): + enumeration: [3] + cluster_analysisID(NXobject): + doc: | + TODO + n_cluster(NX_UINT): + doc: | + TODO + unit: NX_UNITLESS + y_pred(NX_UINT): + doc: | + TODO + unit: NX_UNITLESS + dim: (c,) + clustering(NXprocess): + exists: [min, 1, max, 1] doc: | - In Alaukik's tool the DBScan step after the GMM step. + Clustering is the third step of the algorithmic chain that the CompositionSpace + tool implements. In this step the different voxelized regions in the dataset with + eventually different chemical nature are analyzed if they are distributed in + connected groups of voxels with the same chemical nature. + Using the discretization grid from the first step as the support, this enables + to prepare for the fourth step. In the fourth step the interfaces between + identified groups of different chemical nature are triangulated. + + These triangulated network of interfaces between regions of different chemical + nature is the final data structure that the CompositionSpace tool yields. + Subsequently, this mesh can be post-processed, similarly like meshes that are + obtained from isosurface-based approaches, to perform line profile analyses. sequence_index(NX_POSINT): enumeration: [3] - cluster_dict_keyword: - doc: | - The keywords of the dictionary of distinguished spatially-contiguous - clusters. Examples for keywords could be precipitate1, precipitate2, - and so one and so forth. - dimensions: - rank: 1 - dim: [[1, n_spat_dict]] - cluster_dict_value(NX_UINT): - unit: NX_UNITLESS - doc: | - Resolves for each keyword in cluster_dict which integer is used to - label something that it belongs or is assumed to represent this - cluster. - dimensions: - rank: 1 - dim: [[1, n_spat_dict]] - - # again for fuzzy or probabilistic multi solution approaches see NXem_ebsd - cluster_identifier(NX_UINT): - unit: NX_UNITLESS - doc: | - For example if the voxel grid is used to report that there - are voxels which are assumed to represent volume of certain precipitates, - say we found ten precipitates and consider the rest as matrix. - We could make a list of say matrix, precipitate1, precipitate2, ..., - precipitate10. With cluster_dict_value then running from 0 to 10, - i.e. matrix is flagged special as 0 and the remaining particles - are indexed conveniently as 1, 2, ..., 10 like end users expect. - dimensions: - rank: 1 - dim: [[1, n_voxel]] - - # use the fact that with e.g. XDMF one can on-the-fly reinterpret - # a 1d array to represent an explicit 3d grid - # then the entire visualization just needs a smart XDMF file with - # one section with the coordinates of the voxel center of masses - # one section with the voxel identifier - # one section with the "phase" identifier referring to the clustering_composition_space NXprocess group - # one section with the "precipitate" identifier referring to the clustering_real_space NXprocess group - # technically one should get rid of the unnecessary chunks - # instead define an (nx, ny, nz) C-style array which whose data space - # is reserved by the h5py library upon first call and then (if desired) - # filled incrementally - # the array should be chunked not with an auto-chunking but with a nx, ny, >=1 chunking - # which will make visualization of nx, ny slices naturally fast, making the z-dimension - # chunking as fast as large as possible (needs compromise to remain within chunk cache size) - # will also make the orthogonal section a good compromise fast - # data should be gzip, level 1 compressed and all the redundant parts of the current - # output will collapse substantially - performance(NXcs_profiling): - current_working_directory: - command_line_call: - exists: optional + cluster_analysisID(NXobject): + exists: [min, 0, max, infty] + epsilon(NX_FLOAT): + doc: | + TODO + unit: NX_LENGTH + min_samples(NX_UINT): + doc: | + TODO + unit: NX_UNITLESS + target(NX_UINT): + doc: | + TODO total number of (phases) distinguished. + unit: NX_UNITLESS + labels(NX_UINT): + doc: | + TODO raw labels output of the DBScan clustering algorithm. Length of array varies depending on how + many voxels of the grid were identified of the targetted + phase/chemical nature. + dim: (k,) + unit: NX_UNITLESS + # the section above needs refactoring by MatWerk colleagues + profiling(NXcs_profiling): + exists: optional + current_working_directory(NX_CHAR): + exists: recommended start_time(NX_DATE_TIME): exists: recommended end_time(NX_DATE_TIME): exists: recommended total_elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - number_of_threads(NX_POSINT): - number_of_gpus(NX_POSINT): - (NXcs_computer): - exists: recommended - name: - exists: recommended - operating_system: - \@version: - uuid: - exists: optional - (NXcs_cpu): - exists: ['min', '0', 'max', 'unbounded'] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_gpu): - exists: ['min', '0', 'max', 'unbounded'] - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_mm_sys): - exists: ['min', '0', 'max', '1'] - total_physical_memory(NX_NUMBER): - (NXcs_io_sys): - exists: ['min', '0', 'max', '1'] - (NXcs_io_obj): - exists: ['min', '1', 'max', 'unbounded'] - technology: - max_physical_capacity(NX_NUMBER): - name: - exists: optional - (NXfabrication): - exists: recommended - identifier: - exists: optional - capabilities: - exists: optional - (NXcs_profiling_event): - start_time(NX_DATE_TIME): - exists: optional - end_time(NX_DATE_TIME): - exists: optional - description: - elapsed_time(NX_NUMBER): - number_of_processes(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - number_of_threads(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - number_of_gpus(NX_POSINT): - - # exists: recommended - doc: | - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - max_virtual_memory_snapshot(NX_NUMBER): - exists: recommended - max_resident_memory_snapshot(NX_NUMBER): - exists: recommended - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# fe3315d020167a5d984295fad8ed2070693508cd60801e40acaac2a61f21f1b4 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays. -# -# -# -# Number of voxel of discretized domain for analyzed part of the dataset. -# -# -# -# -# The dimensionality of the grid. -# -# -# -# -# The cardinality or total number of cells/grid points. -# -# -# -# -# Number of terms in the composition clustering dictionary -# -# -# -# -# Number of terms in the position clustering dictionary -# -# -# -# -# Results of a run with Alaukik Saxena's composition space tool. -# -# This is an initial draft application definition for the common NFDI-MatWerk, -# FAIRmat infrastructure use case IUC09 how to improve the organization and -# results storage of the composition space tool and make these data at the same -# time directly understandable for NOMAD. -# -# This draft does no contain yet the annotations for how to also store -# in the HDF5 file a default visualization whereby the composition grid -# could directly be explored using H5Web. I am happy to add this ones the -# data have been mapped on this schema, i.e. more discussion needed. -# -# Also iso-surfaces can be described, for paraprobe, this is a solved problem, -# check the respective group in the NXapm_paraprobe_results_nanochem data -# schema/application definition. -# -# -# -# -# -# Version specifier of this application definition. -# -# -# -# -# Official NeXus NXDL schema with which this file was written. -# -# -# -# -# -# -# -# -# -# -# -# -# -# TBD, maybe how to link between pyiron state tracking and app state tracking -# -# -# -# -# Disencouraged place for free-text for e.g. comments. -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when the analysis behind this results file -# was started, i.e. when composition space tool was started as a process. -# -# -# -# -# ISO 8601 formatted time code with local time zone offset to UTC -# information included when the analysis behind this results file -# were completed and composition space tool exited as a process. -# -# -# -# -# The path and name of the config file for this analysis. -# TBD, this can be e.g. Alaukik's YAML file for composition space. -# -# -# -# -# At least SHA256 strong hash of the specific config_file for -# tracking provenance. -# -# -# -# -# -# -# The path and name of the file (technology partner or community format) -# from which reconstructed ion positions were loaded. -# -# -# -# -# -# -# -# The path and name of the file (technology partner or community format -# from which ranging definitions, i.e. how to map mass-to- -# charge-state ratios on iontypes were loaded. -# -# -# -# -# -# -# Path to the directory where the tool should store NeXus/HDF5 results -# of this analysis. If not specified results will be stored in the -# current working directory. -# -# -# -# -# A statement whether the executable managed to process the analysis -# or failed prematurely. -# -# This status is written to the results file after the end_time -# at which point the executable must not compute any analysis. -# Only when this status message is present and shows `success`, the -# user should consider the results. In all other cases it might be -# that the executable has terminated prematurely or another error -# occurred. -# -# -# -# -# -# -# -# -# If used, contact information and eventually details -# of at least the person who performed this analysis. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Details about the coordinate system conventions used. -# -# -# -# The individual coordinate systems which should be used. -# Some suggestions follow, e.g. that field names should be prefixed -# with the following controlled terms indicating which individual -# coordinate system is described: -# -# * world -# * composition_space -# * lab -# * specimen -# * laser -# * leap -# * detector -# * recon -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Reference to or definition of a coordinate system with -# which the positions and directions are interpretable. -# -# -# -# -# -# -# -# -# -# Position of each cell in Euclidean space. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# For each ion, the identifier of the voxel in which the ion is located. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# In Alaukik's tool the GMM step. -# -# -# -# -# -# -# -# -# The keywords of the dictionary of distinguished compositionally- -# defined cluster, e.g. the phases. Examples for keywords could be -# phase1, phase2, and so one and so forth. -# -# -# -# -# -# -# -# Resolves for each keyword in cluster_dict which integer is used to -# label something that it belongs or is assumed to represent this -# cluster. -# -# -# -# -# -# -# -# -# For example if the voxel grid is used to report that there -# are voxels which are assumed to represent volume of either phase1 -# or phase2, the cluster_dict_keyword would be a list with two names -# phase1 and phase2, respectively. The cluster_dict_value would be a -# list of e.g. integers 1 and 2. These could be used to build an -# array with as many entries as there are voxel and store in this array -# the respective value to encode which phase is assumed for each voxel. -# -# -# -# -# -# -# -# -# -# In Alaukik's tool the DBScan step after the GMM step. -# -# -# -# -# -# -# -# -# The keywords of the dictionary of distinguished spatially-contiguous -# clusters. Examples for keywords could be precipitate1, precipitate2, -# and so one and so forth. -# -# -# -# -# -# -# -# Resolves for each keyword in cluster_dict which integer is used to -# label something that it belongs or is assumed to represent this -# cluster. -# -# -# -# -# -# -# -# -# For example if the voxel grid is used to report that there -# are voxels which are assumed to represent volume of certain precipitates, -# say we found ten precipitates and consider the rest as matrix. -# We could make a list of say matrix, precipitate1, precipitate2, ..., -# precipitate10. With cluster_dict_value then running from 0 to 10, -# i.e. matrix is flagged special as 0 and the remaining particles -# are indexed conveniently as 1, 2, ..., 10 like end users expect. -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Specify if it was different from the number_of_processes -# in the NXcs_profiling super class. -# -# -# -# -# -# Specify if it was different from the number_of_threads -# in the NXcs_profiling super class. -# -# -# -# -# -# Specify if it was different from the number_of_threads -# in the NXcs_profiling super class. -# -# -# -# -# -# -# -# -# + # number_of_processes(NX_POSINT): + # number_of_threads(NX_POSINT): + # number_of_gpus(NX_POSINT): diff --git a/manual/source/classes/contributed_definitions/apm-structure.rst b/manual/source/classes/contributed_definitions/apm-structure.rst index a9671b6542..ba275045ce 100644 --- a/manual/source/classes/contributed_definitions/apm-structure.rst +++ b/manual/source/classes/contributed_definitions/apm-structure.rst @@ -10,6 +10,7 @@ Atom-probe tomography ApmBC StatusQuoApm ApmParaprobeAppDef + ApmGermanNfdi .. _IntroductionApm: @@ -265,3 +266,19 @@ tool one such pair is proposed: Analyze volumetric intersections and proximity of 3D objects discretized as triangulated surface meshes in continuum space to study the effect the parameterization of surface extraction algorithms on the resulting shape, spatial arrangement, and colocation of 3D objects via graph-based techniques. + +.. _ApmGermanNfdi: + +Joint work German NFDI consortia NFDI-MatWerk and FAIRmat +####################################################################### + +Members of the NFDI-MatWerk and the FAIRmat consortium of the German National Research Data Infrastructure +are working together within the Infrastructure Use Case IUC09 of the NFDI-MatWerk project to work on examples +how software tools in both consortia become better documented and interoperable to use. Within this project, +we have also added the `CompositionSpace tool that has been developed at the Max-Planck-Institut für Eisenforschung +GmbH in Düsseldorf `_ by A. Saxena et al. + +Specifically, within the IUC09 we refactored the code base behind the publication `A. Saxena et al. `_ to better document its configuration, here as an example implemented like for the above-mentioned paraprobe-toolbox using NeXus: + + :ref:`NXapm_compositionspace_config`, :ref:`NXapm_compositionspace_results`: + Configuration and the results respectively of the CompositionSpace tool. From 39972c900a1c2a5d7936a2e507fd20084e475790 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 11 Apr 2024 13:57:53 +0200 Subject: [PATCH 0664/1012] temporarily disable NXdata_mpes* classes --- contributed_definitions/NXdata_mpes.nxdl.xml | 453 --------- .../NXdata_mpes_detector.nxdl.xml | 455 +-------- contributed_definitions/NXmpes.nxdl.xml | 14 +- .../nyaml/NXdata_mpes.yaml | 857 +---------------- .../nyaml/NXdata_mpes_detector.yaml | 861 +----------------- contributed_definitions/nyaml/NXmpes.yaml | 56 +- 6 files changed, 38 insertions(+), 2658 deletions(-) diff --git a/contributed_definitions/NXdata_mpes.nxdl.xml b/contributed_definitions/NXdata_mpes.nxdl.xml index abfbaf77b1..5cfeee719c 100644 --- a/contributed_definitions/NXdata_mpes.nxdl.xml +++ b/contributed_definitions/NXdata_mpes.nxdl.xml @@ -22,466 +22,13 @@ # For further information, see http://www.nexusformat.org --> - - - - These symbols will be used below to coordinate fields with the same - shape. - - - - rank of the ``DATA`` field - - - - - length of the ``AXISNAME`` field - - - - - length of the ``x`` field - - - - - length of the ``y`` field - - - - - length of the ``z`` field - - - :ref:`NXdata_mpes` describes the plottable data and related dimension scales in photoemission experiments. It extends the NXdata class and provides a glossary of explicitly named axis names which are typical for photoemission data. - - For now, the extension of NXdata is performed by simply copying all existing groups, fields, - and attibute from NXdata. In the future, it is envisioned that this extension can be solved by - base class inheritance. - - .. 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) - - - .. index:: plotting - - Array of strings holding the :ref:`names <validItemName>` of additional - signals to be plotted with the default :ref:`signal </NXdata@signal-attribute>`. - These fields or links *must* exist and be direct children of this NXdata group. - - Each auxiliary signal needs to be of the same shape as the default signal. - - .. NIAC2018: - https://www.nexusformat.org/NIAC2018Minutes.html - - - - - .. 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 <validItemName>` 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. - - - - - - - - .. index:: plotting - - Array of strings holding the :ref:`names <validItemName>` of - the independent data fields used in the default plot for all of - the dimensions of the :ref:`signal </NXdata@signal-attribute>` - as well as any :ref:`auxiliary signals </NXdata@auxiliary_signals-attribute>`. - - 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. - - - - - - - Each ``AXISNAME_indices`` attribute indicates the dependency - relationship of the ``AXISNAME`` field (where ``AXISNAME`` - is the name of a field that exists in this ``NXdata`` group) - with one or more dimensions of the plottable data. - - Integer array that defines the indices of the *signal* field - (that field will be a multidimensional array) - which need to be used in the *AXISNAME* field in - order to reference the corresponding axis value. - - The first index of an array is ``0`` (zero). - - Here, *AXISNAME* is to be replaced by the name of each - field described in the ``axes`` attribute. - An example with 2-D data, :math:`d(t,P)`, will illustrate:: - - data_2d:NXdata - @signal="data" - @axes=["time", "pressure"] - @time_indices=0 - @pressure_indices=1 - data: float[1000,20] - time: float[1000] - pressure: float[20] - - This attribute is to be provided in all situations. - However, if the indices attributes are missing - (such as for data files written before this specification), - file readers are encouraged to make their best efforts - to plot the data. - Thus the implementation of the - ``AXISNAME_indices`` attribute is based on the model of - "strict writer, liberal reader". - - .. note:: Attributes potentially containing multiple values - (axes and _indices) are to be written as string or integer arrays, - to avoid string parsing in reading applications. - - - - - Points to the path of a field defining the axis on which the ``AXISNAME`` axis depends. - - This concept allows to link an axis to a respective field in the NeXus hierarchy, thereby - defining the physical quantity it represents. - - Here, *AXISNAME* is to be replaced by the name of each - field described in the ``axes`` attribute. - - Examples: - If a calibration has been performed, ``@AXISNAME_depends`` links to the result of - that calibration: - - @AXISNAME_depends: '/entry/process/calibration/calibrated_axis' - - If the axis corresponds to a coordinate of a detector, ``@AXISNAME_depends`` links - to that detector axis: - - @AXISNAME_depends: '/entry/instrument/detector/axis/some_axis' for a 2D detector - - If the axis is a scanned motor, ``@AXISNAME_depends`` links to the transformation - describing the respective motion, e.g.: - - @AXISNAME_depends: '/entry/instrument/detector/transformations/some_transformation' for a motion of the detector - - - - - 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. - - - - A *dimension scale* must have a rank of 1 and has length ``n``. - - - - - - Axis label - - - - - ``0|false``: single value, - ``1|true``: multiple values - - - - - Index of first good value - - - - - Index of last good value - - - - - Index (positive integer) identifying this specific set of numbers. - - N.B. The ``axis`` attribute is the old way of designating a link. - Do not use the ``axes`` attribute with the ``axis`` attribute. - The ``axes`` *group* attribute is now preferred. - - - - - - "Errors" (meaning *uncertainties* or *standard deviations*) - associated with any field named ``FIELDNAME`` in this ``NXdata`` - group (e.g. an axis, signal or auxiliary signal). - - The dimensions of the ``FIELDNAME_errors`` field must match - the dimensions of the ``FIELDNAME`` field. - - - - - .. 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. - - - - The rank (``dataRank``) of the ``data`` must satisfy - ``1 <= dataRank <= NX_MAXRANK=32``. - At least one ``dim`` must have length ``n``. - - - - - .. index:: plotting - - Plottable (independent) axis, indicate index number. - Only one field in a :ref:`NXdata` group may have the - ``signal=1`` attribute. - Do not use the ``signal`` attribute with the ``axis`` attribute. - - - - - Defines the names of the dimension scales - (independent axes) for this data set - as a colon-delimited array. - NOTE: The ``axes`` attribute is the preferred - method of designating a link. - Do not use the ``axes`` attribute with the ``axis`` attribute. - - - - - data label - - - - - - Standard deviations of data values - - the data array is identified by the group attribute ``signal``. - The ``errors`` array must have the same dimensions as ``DATA``. - Client is responsible for defining the dimensions of the data. - - - - The ``errors`` must have - the same rank (``dataRank``) - as the ``data``. - At least one ``dim`` must have length "n". - - - - - - The elements in data are usually float values really. For - efficiency reasons these are usually stored as integers - after scaling with a scale factor. This value is the scale - factor. It is required to get the actual physical value, - when necessary. - - - - - An optional offset to apply to the values in data. - - - - - Title for the plot. - - - - - This is an array holding the values to use for the x-axis of - data. The units must be appropriate for the measurement. - - - - - - - - This is an array holding the values to use for the y-axis of - data. The units must be appropriate for the measurement. - - - - - - - - This is an array holding the values to use for the z-axis of - data. The units must be appropriate for the measurement. - - - - - Calibrated energy axis. diff --git a/contributed_definitions/NXdata_mpes_detector.nxdl.xml b/contributed_definitions/NXdata_mpes_detector.nxdl.xml index 4cbcb6efe9..3faebab2f6 100644 --- a/contributed_definitions/NXdata_mpes_detector.nxdl.xml +++ b/contributed_definitions/NXdata_mpes_detector.nxdl.xml @@ -21,467 +21,14 @@ # # For further information, see http://www.nexusformat.org --> - - - - - These symbols will be used below to coordinate fields with the same - shape. - - - - rank of the ``DATA`` field - - - - - length of the ``AXISNAME`` field - - - - - length of the ``x`` field - - - - - length of the ``y`` field - - - - - length of the ``z`` field - - - + :ref:`NXdata_mpes_detector` describes the plottable data and related dimension scales for raw detector data in photoemission experiments. It extends the NXdata class and provides a glossary of explicitly named axis names which are typical for raw photoemission data. - - For now, the extension of NXdata is performed by simply copying all existing groups, fields, - and attibute from NXdata. In the future, it is envisioned that this extension can be solved by - base class inheritance. - - .. 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) - - - .. index:: plotting - - Array of strings holding the :ref:`names <validItemName>` of additional - signals to be plotted with the default :ref:`signal </NXdata@signal-attribute>`. - These fields or links *must* exist and be direct children of this NXdata group. - - Each auxiliary signal needs to be of the same shape as the default signal. - - .. NIAC2018: - https://www.nexusformat.org/NIAC2018Minutes.html - - - - - .. 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 <validItemName>` 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. - - - - - - - - .. index:: plotting - - Array of strings holding the :ref:`names <validItemName>` of - the independent data fields used in the default plot for all of - the dimensions of the :ref:`signal </NXdata@signal-attribute>` - as well as any :ref:`auxiliary signals </NXdata@auxiliary_signals-attribute>`. - - 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. - - - - - - - Each ``AXISNAME_indices`` attribute indicates the dependency - relationship of the ``AXISNAME`` field (where ``AXISNAME`` - is the name of a field that exists in this ``NXdata`` group) - with one or more dimensions of the plottable data. - - Integer array that defines the indices of the *signal* field - (that field will be a multidimensional array) - which need to be used in the *AXISNAME* field in - order to reference the corresponding axis value. - - The first index of an array is ``0`` (zero). - - Here, *AXISNAME* is to be replaced by the name of each - field described in the ``axes`` attribute. - An example with 2-D data, :math:`d(t,P)`, will illustrate:: - - data_2d:NXdata - @signal="data" - @axes=["time", "pressure"] - @time_indices=0 - @pressure_indices=1 - data: float[1000,20] - time: float[1000] - pressure: float[20] - - This attribute is to be provided in all situations. - However, if the indices attributes are missing - (such as for data files written before this specification), - file readers are encouraged to make their best efforts - to plot the data. - Thus the implementation of the - ``AXISNAME_indices`` attribute is based on the model of - "strict writer, liberal reader". - - .. note:: Attributes potentially containing multiple values - (axes and _indices) are to be written as string or integer arrays, - to avoid string parsing in reading applications. - - - - - Points to the path of a field defining the axis on which the ``AXISNAME`` axis depends. - - This concept allows to link an axis to a respective field in the NeXus hierarchy, thereby - defining the physical quantity it represents. - - Here, *AXISNAME* is to be replaced by the name of each - field described in the ``axes`` attribute. - - Examples: - If a calibration has been performed, ``@AXISNAME_depends`` links to the result of - that calibration: - - @AXISNAME_depends: '/entry/process/calibration/calibrated_axis' - - If the axis corresponds to a coordinate of a detector, ``@AXISNAME_depends`` links - to that detector axis: - - @AXISNAME_depends: '/entry/instrument/detector/axis/some_axis' for a 2D detector - - If the axis is a scanned motor, ``@AXISNAME_depends`` links to the transformation - describing the respective motion, e.g.: - - @AXISNAME_depends: '/entry/instrument/detector/transformations/some_transformation' for a motion of the detector - - - - - 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. - - - - A *dimension scale* must have a rank of 1 and has length ``n``. - - - - - - Axis label - - - - - ``0|false``: single value, - ``1|true``: multiple values - - - - - Index of first good value - - - - - Index of last good value - - - - - Index (positive integer) identifying this specific set of numbers. - - N.B. The ``axis`` attribute is the old way of designating a link. - Do not use the ``axes`` attribute with the ``axis`` attribute. - The ``axes`` *group* attribute is now preferred. - - - - - - "Errors" (meaning *uncertainties* or *standard deviations*) - associated with any field named ``FIELDNAME`` in this ``NXdata`` - group (e.g. an axis, signal or auxiliary signal). - - The dimensions of the ``FIELDNAME_errors`` field must match - the dimensions of the ``FIELDNAME`` field. - - - - - .. 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. - - - - The rank (``dataRank``) of the ``data`` must satisfy - ``1 <= dataRank <= NX_MAXRANK=32``. - At least one ``dim`` must have length ``n``. - - - - - .. index:: plotting - - Plottable (independent) axis, indicate index number. - Only one field in a :ref:`NXdata` group may have the - ``signal=1`` attribute. - Do not use the ``signal`` attribute with the ``axis`` attribute. - - - - - Defines the names of the dimension scales - (independent axes) for this data set - as a colon-delimited array. - NOTE: The ``axes`` attribute is the preferred - method of designating a link. - Do not use the ``axes`` attribute with the ``axis`` attribute. - - - - - data label - - - - - - Standard deviations of data values - - the data array is identified by the group attribute ``signal``. - The ``errors`` array must have the same dimensions as ``DATA``. - Client is responsible for defining the dimensions of the data. - - - - The ``errors`` must have - the same rank (``dataRank``) - as the ``data``. - At least one ``dim`` must have length "n". - - - - - - The elements in data are usually float values really. For - efficiency reasons these are usually stored as integers - after scaling with a scale factor. This value is the scale - factor. It is required to get the actual physical value, - when necessary. - - - - - An optional offset to apply to the values in data. - - - - - Title for the plot. - - - - - This is an array holding the values to use for the x-axis of - data. The units must be appropriate for the measurement. - - - - - - - - This is an array holding the values to use for the y-axis of - data. The units must be appropriate for the measurement. - - - - - - - - This is an array holding the values to use for the z-axis of - data. The units must be appropriate for the measurement. - - - - - Raw data before calibration. diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 79f50167f8..ecfa8ba97b 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -372,7 +372,7 @@ - + Contains the raw data collected by the detector before calibration. The data which is considered raw might change from experiment to experiment @@ -380,8 +380,7 @@ This field ideally collects the data with the lowest level of processing possible. - The naming of fields should follow the convention defined in the - :ref:`NXdata_mpes_detector` base class: + Fields should be named according to new following convention: - **pixel_x**: Detector pixel in x direction. - **pixel_y**: Detector pixel in y direction. @@ -749,17 +748,16 @@ - + The default NXdata field containing a view on the measured data. This NXdata field contains a collection of the main relevant fields (axes). If you want to provide additional views on your data, you can additionally use the generic NXdata group of NXentry. - In NXmpes, it is required to provide an energy axis. - - The naming of fields should follow the convention defined in the - :ref:`NXdata_mpes` base class: + In NXmpes, it is recommended to provide an energy axis. + + Fields should be named according to the following convention: - **energy**: Calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). - **kx**: Calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). diff --git a/contributed_definitions/nyaml/NXdata_mpes.yaml b/contributed_definitions/nyaml/NXdata_mpes.yaml index 35bc7f5d09..ded865d1b8 100644 --- a/contributed_definitions/nyaml/NXdata_mpes.yaml +++ b/contributed_definitions/nyaml/NXdata_mpes.yaml @@ -5,412 +5,10 @@ doc: | It extends the NXdata class and provides a glossary of explicitly named axis names which are typical for photoemission data. - - For now, the extension of NXdata is performed by simply copying all existing groups, fields, - and attibute from NXdata. In the future, it is envisioned that this extension can be solved by - base class inheritance. - - .. 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) - -# The ignoreExtra* attributes are used in the definition to -# avoid warning messages that would be generated from unexpected fields or attributes. -# Since common use of NXdata indicates field names of any value, _many_ -# instances of this class would generate a warning message during validation -# without this attribute being set to "true". -symbols: - doc: | - These symbols will be used below to coordinate fields with the same - shape. - dataRank: | - rank of the ``DATA`` field - n: | - length of the ``AXISNAME`` field - nx: | - length of the ``x`` field - ny: | - length of the ``y`` field - nz: | - length of the ``z`` field type: group ignoreExtraFields: true ignoreExtraAttributes: true NXdata_mpes(NXdata): - \@auxiliary_signals: - doc: | - .. index:: plotting - - Array of strings holding the :ref:`names ` of additional - signals to be plotted with the default :ref:`signal `. - These fields or links *must* exist and be direct children of this NXdata group. - - Each auxiliary signal needs to be of the same shape as the default signal. - - .. NIAC2018: - https://www.nexusformat.org/NIAC2018Minutes.html - \@signal: - doc: | - .. 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. - enumeration: [raw] - \@axes: - doc: | - .. 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. - \@AXISNAME_indices: - type: NX_INT - - # nxdl.xsd rules do not allow us to show this as a variable name - # - we'll use ALL CAPS (see #562) - - # AXISNAME_indices documentation copied from datarules.rst - doc: | - Each ``AXISNAME_indices`` attribute indicates the dependency - relationship of the ``AXISNAME`` field (where ``AXISNAME`` - is the name of a field that exists in this ``NXdata`` group) - with one or more dimensions of the plottable data. - - Integer array that defines the indices of the *signal* field - (that field will be a multidimensional array) - which need to be used in the *AXISNAME* field in - order to reference the corresponding axis value. - - The first index of an array is ``0`` (zero). - - Here, *AXISNAME* is to be replaced by the name of each - field described in the ``axes`` attribute. - An example with 2-D data, :math:`d(t,P)`, will illustrate:: - - data_2d:NXdata - @signal="data" - @axes=["time", "pressure"] - @time_indices=0 - @pressure_indices=1 - data: float[1000,20] - time: float[1000] - pressure: float[20] - - This attribute is to be provided in all situations. - However, if the indices attributes are missing - (such as for data files written before this specification), - file readers are encouraged to make their best efforts - to plot the data. - Thus the implementation of the - ``AXISNAME_indices`` attribute is based on the model of - "strict writer, liberal reader". - - .. note:: Attributes potentially containing multiple values - (axes and _indices) are to be written as string or integer arrays, - to avoid string parsing in reading applications. - \@AXISNAME_depends: - doc: | - Points to the path of a field defining the axis on which the ``AXISNAME`` axis depends. - - This concept allows to link an axis to a respective field in the NeXus hierarchy, thereby - defining the physical quantity it represents. - - Here, *AXISNAME* is to be replaced by the name of each - field described in the ``axes`` attribute. - - Examples: - If a calibration has been performed, ``@AXISNAME_depends`` links to the result of - that calibration: - - @AXISNAME_depends: '/entry/process/calibration/calibrated_axis' - - If the axis corresponds to a coordinate of a detector, ``@AXISNAME_depends`` links - to that detector axis: - - @AXISNAME_depends: '/entry/instrument/detector/axis/some_axis' for a 2D detector - - If the axis is a scanned motor, ``@AXISNAME_depends`` links to the transformation - describing the respective motion, e.g.: - - @AXISNAME_depends: '/entry/instrument/detector/transformations/some_transformation' for a motion of the detector - AXISNAME(NX_NUMBER): - nameType: any - doc: | - 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. - dimensions: - rank: 1 - doc: | - A *dimension scale* must have a rank of 1 and has length ``n``. - dim: [[1, n]] - \@long_name: - doc: | - Axis label - \@distribution: - type: NX_BOOLEAN - doc: | - ``0|false``: single value, - ``1|true``: multiple values - \@first_good: - type: NX_INT - doc: | - Index of first good value - \@last_good: - type: NX_INT - doc: | - Index of last good value - \@axis: - type: NX_POSINT - deprecated: Use the group ``axes`` attribute (NIAC2014) - doc: | - Index (positive integer) identifying this specific set of numbers. - - N.B. The ``axis`` attribute is the old way of designating a link. - Do not use the ``axes`` attribute with the ``axis`` attribute. - The ``axes`` *group* attribute is now preferred. - FIELDNAME_errors(NX_NUMBER): - nameType: any - doc: | - "Errors" (meaning *uncertainties* or *standard deviations*) - associated with any field named ``FIELDNAME`` in this ``NXdata`` - group (e.g. an axis, signal or auxiliary signal). - - The dimensions of the ``FIELDNAME_errors`` field must match - the dimensions of the ``FIELDNAME`` field. - DATA(NX_NUMBER): - nameType: any - doc: | - .. 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. - dimensions: - rank: dataRank - doc: | - The rank (``dataRank``) of the ``data`` must satisfy - ``1 <= dataRank <= NX_MAXRANK=32``. - At least one ``dim`` must have length ``n``. - dim: [] - \@signal: - type: NX_POSINT - deprecated: Use the group ``signal`` attribute (NIAC2014) - doc: | - .. index:: plotting - - Plottable (independent) axis, indicate index number. - Only one field in a :ref:`NXdata` group may have the - ``signal=1`` attribute. - Do not use the ``signal`` attribute with the ``axis`` attribute. - \@axes: - deprecated: Use the group ``axes`` attribute (NIAC2014) - doc: | - Defines the names of the dimension scales - (independent axes) for this data set - as a colon-delimited array. - NOTE: The ``axes`` attribute is the preferred - method of designating a link. - Do not use the ``axes`` attribute with the ``axis`` attribute. - \@long_name: - doc: | - data label - errors(NX_NUMBER): - deprecated: Use ``DATA_errors`` instead (NIAC2018) - doc: | - Standard deviations of data values - - the data array is identified by the group attribute ``signal``. - The ``errors`` array must have the same dimensions as ``DATA``. - Client is responsible for defining the dimensions of the data. - dimensions: - rank: dataRank - doc: | - The ``errors`` must have - the same rank (``dataRank``) - as the ``data``. - At least one ``dim`` must have length "n". - dim: [] - scaling_factor(NX_FLOAT): - doc: | - The elements in data are usually float values really. For - efficiency reasons these are usually stored as integers - after scaling with a scale factor. This value is the scale - factor. It is required to get the actual physical value, - when necessary. - offset(NX_FLOAT): - doc: | - An optional offset to apply to the values in data. - title: - doc: | - Title for the plot. - x(NX_FLOAT): - unit: NX_ANY - doc: | - This is an array holding the values to use for the x-axis of - data. The units must be appropriate for the measurement. - dimensions: - rank: 1 - dim: [[1, nx]] - y(NX_FLOAT): - unit: NX_ANY - doc: | - This is an array holding the values to use for the y-axis of - data. The units must be appropriate for the measurement. - dimensions: - rank: 1 - dim: [[1, ny]] - z(NX_FLOAT): - unit: NX_ANY - doc: | - This is an array holding the values to use for the z-axis of - data. The units must be appropriate for the measurement. - dimensions: - rank: 1 - dim: [[1, nz]] energy(NX_NUMBER): unit: NX_ENERGY doc: | @@ -498,7 +96,7 @@ NXdata_mpes(NXdata): /entry/instrument/beam/final_ellipticity if they exist. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8c857972d4d2406b9793e2e5979764f79a8b1ffe0a5eda3addb975c07d33c3bc +# 4b087c0544eec9b6d7a621779cae0cc23b754cbccc06a07e88f59398346cf5fe # # # # -# -# -# -# These symbols will be used below to coordinate fields with the same -# shape. -# -# -# -# rank of the ``DATA`` field -# -# -# -# -# length of the ``AXISNAME`` field -# -# -# -# -# length of the ``x`` field -# -# -# -# -# length of the ``y`` field -# -# -# -# -# length of the ``z`` field -# -# -# # # :ref:`NXdata_mpes` describes the plottable data and related dimension scales in photoemission # experiments. # # It extends the NXdata class and provides a glossary of explicitly named axis names # which are typical for photoemission data. -# -# For now, the extension of NXdata is performed by simply copying all existing groups, fields, -# and attibute from NXdata. In the future, it is envisioned that this extension can be solved by -# base class inheritance. -# -# .. 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) # -# -# -# .. index:: plotting -# -# Array of strings holding the :ref:`names <validItemName>` of additional -# signals to be plotted with the default :ref:`signal </NXdata@signal-attribute>`. -# These fields or links *must* exist and be direct children of this NXdata group. -# -# Each auxiliary signal needs to be of the same shape as the default signal. -# -# .. NIAC2018: -# https://www.nexusformat.org/NIAC2018Minutes.html -# -# -# -# -# .. 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 <validItemName>` 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. -# -# -# -# -# -# -# -# .. index:: plotting -# -# Array of strings holding the :ref:`names <validItemName>` of -# the independent data fields used in the default plot for all of -# the dimensions of the :ref:`signal </NXdata@signal-attribute>` -# as well as any :ref:`auxiliary signals </NXdata@auxiliary_signals-attribute>`. -# -# 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. -# -# -# -# -# -# -# Each ``AXISNAME_indices`` attribute indicates the dependency -# relationship of the ``AXISNAME`` field (where ``AXISNAME`` -# is the name of a field that exists in this ``NXdata`` group) -# with one or more dimensions of the plottable data. -# -# Integer array that defines the indices of the *signal* field -# (that field will be a multidimensional array) -# which need to be used in the *AXISNAME* field in -# order to reference the corresponding axis value. -# -# The first index of an array is ``0`` (zero). -# -# Here, *AXISNAME* is to be replaced by the name of each -# field described in the ``axes`` attribute. -# An example with 2-D data, :math:`d(t,P)`, will illustrate:: -# -# data_2d:NXdata -# @signal="data" -# @axes=["time", "pressure"] -# @time_indices=0 -# @pressure_indices=1 -# data: float[1000,20] -# time: float[1000] -# pressure: float[20] -# -# This attribute is to be provided in all situations. -# However, if the indices attributes are missing -# (such as for data files written before this specification), -# file readers are encouraged to make their best efforts -# to plot the data. -# Thus the implementation of the -# ``AXISNAME_indices`` attribute is based on the model of -# "strict writer, liberal reader". -# -# .. note:: Attributes potentially containing multiple values -# (axes and _indices) are to be written as string or integer arrays, -# to avoid string parsing in reading applications. -# -# -# -# -# Points to the path of a field defining the axis on which the ``AXISNAME`` axis depends. -# -# This concept allows to link an axis to a respective field in the NeXus hierarchy, thereby -# defining the physical quantity it represents. -# -# Here, *AXISNAME* is to be replaced by the name of each -# field described in the ``axes`` attribute. -# -# Examples: -# If a calibration has been performed, ``@AXISNAME_depends`` links to the result of -# that calibration: -# -# @AXISNAME_depends: '/entry/process/calibration/calibrated_axis' -# -# If the axis corresponds to a coordinate of a detector, ``@AXISNAME_depends`` links -# to that detector axis: -# -# @AXISNAME_depends: '/entry/instrument/detector/axis/some_axis' for a 2D detector -# -# If the axis is a scanned motor, ``@AXISNAME_depends`` links to the transformation -# describing the respective motion, e.g.: -# -# @AXISNAME_depends: '/entry/instrument/detector/transformations/some_transformation' for a motion of the detector -# -# -# -# -# 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. -# -# -# -# A *dimension scale* must have a rank of 1 and has length ``n``. -# -# -# -# -# -# Axis label -# -# -# -# -# ``0|false``: single value, -# ``1|true``: multiple values -# -# -# -# -# Index of first good value -# -# -# -# -# Index of last good value -# -# -# -# -# Index (positive integer) identifying this specific set of numbers. -# -# N.B. The ``axis`` attribute is the old way of designating a link. -# Do not use the ``axes`` attribute with the ``axis`` attribute. -# The ``axes`` *group* attribute is now preferred. -# -# -# -# -# -# "Errors" (meaning *uncertainties* or *standard deviations*) -# associated with any field named ``FIELDNAME`` in this ``NXdata`` -# group (e.g. an axis, signal or auxiliary signal). -# -# The dimensions of the ``FIELDNAME_errors`` field must match -# the dimensions of the ``FIELDNAME`` field. -# -# -# -# -# .. 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. -# -# -# -# The rank (``dataRank``) of the ``data`` must satisfy -# ``1 <= dataRank <= NX_MAXRANK=32``. -# At least one ``dim`` must have length ``n``. -# -# -# -# -# .. index:: plotting -# -# Plottable (independent) axis, indicate index number. -# Only one field in a :ref:`NXdata` group may have the -# ``signal=1`` attribute. -# Do not use the ``signal`` attribute with the ``axis`` attribute. -# -# -# -# -# Defines the names of the dimension scales -# (independent axes) for this data set -# as a colon-delimited array. -# NOTE: The ``axes`` attribute is the preferred -# method of designating a link. -# Do not use the ``axes`` attribute with the ``axis`` attribute. -# -# -# -# -# data label -# -# -# -# -# -# Standard deviations of data values - -# the data array is identified by the group attribute ``signal``. -# The ``errors`` array must have the same dimensions as ``DATA``. -# Client is responsible for defining the dimensions of the data. -# -# -# -# The ``errors`` must have -# the same rank (``dataRank``) -# as the ``data``. -# At least one ``dim`` must have length "n". -# -# -# -# -# -# The elements in data are usually float values really. For -# efficiency reasons these are usually stored as integers -# after scaling with a scale factor. This value is the scale -# factor. It is required to get the actual physical value, -# when necessary. -# -# -# -# -# An optional offset to apply to the values in data. -# -# -# -# -# Title for the plot. -# -# -# -# -# This is an array holding the values to use for the x-axis of -# data. The units must be appropriate for the measurement. -# -# -# -# -# -# -# -# This is an array holding the values to use for the y-axis of -# data. The units must be appropriate for the measurement. -# -# -# -# -# -# -# -# This is an array holding the values to use for the z-axis of -# data. The units must be appropriate for the measurement. -# -# -# -# -# # # # Calibrated energy axis. diff --git a/contributed_definitions/nyaml/NXdata_mpes_detector.yaml b/contributed_definitions/nyaml/NXdata_mpes_detector.yaml index c48f181f10..86236dbc74 100644 --- a/contributed_definitions/nyaml/NXdata_mpes_detector.yaml +++ b/contributed_definitions/nyaml/NXdata_mpes_detector.yaml @@ -5,412 +5,10 @@ doc: | It extends the NXdata class and provides a glossary of explicitly named axis names which are typical for raw photoemission data. - - For now, the extension of NXdata is performed by simply copying all existing groups, fields, - and attibute from NXdata. In the future, it is envisioned that this extension can be solved by - base class inheritance. - - .. 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) - -# The ignoreExtra* attributes are used in the definition to -# avoid warning messages that would be generated from unexpected fields or attributes. -# Since common use of NXdata indicates field names of any value, _many_ -# instances of this class would generate a warning message during validation -# without this attribute being set to "true". -symbols: - doc: | - These symbols will be used below to coordinate fields with the same - shape. - dataRank: | - rank of the ``DATA`` field - n: | - length of the ``AXISNAME`` field - nx: | - length of the ``x`` field - ny: | - length of the ``y`` field - nz: | - length of the ``z`` field type: group ignoreExtraFields: true ignoreExtraAttributes: true -NXdata_mpes_detector(NXobject): - \@auxiliary_signals: - doc: | - .. index:: plotting - - Array of strings holding the :ref:`names ` of additional - signals to be plotted with the default :ref:`signal `. - These fields or links *must* exist and be direct children of this NXdata group. - - Each auxiliary signal needs to be of the same shape as the default signal. - - .. NIAC2018: - https://www.nexusformat.org/NIAC2018Minutes.html - \@signal: - doc: | - .. 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. - enumeration: [raw] - \@axes: - doc: | - .. 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. - \@AXISNAME_indices: - type: NX_INT - - # nxdl.xsd rules do not allow us to show this as a variable name - # - we'll use ALL CAPS (see #562) - - # AXISNAME_indices documentation copied from datarules.rst - doc: | - Each ``AXISNAME_indices`` attribute indicates the dependency - relationship of the ``AXISNAME`` field (where ``AXISNAME`` - is the name of a field that exists in this ``NXdata`` group) - with one or more dimensions of the plottable data. - - Integer array that defines the indices of the *signal* field - (that field will be a multidimensional array) - which need to be used in the *AXISNAME* field in - order to reference the corresponding axis value. - - The first index of an array is ``0`` (zero). - - Here, *AXISNAME* is to be replaced by the name of each - field described in the ``axes`` attribute. - An example with 2-D data, :math:`d(t,P)`, will illustrate:: - - data_2d:NXdata - @signal="data" - @axes=["time", "pressure"] - @time_indices=0 - @pressure_indices=1 - data: float[1000,20] - time: float[1000] - pressure: float[20] - - This attribute is to be provided in all situations. - However, if the indices attributes are missing - (such as for data files written before this specification), - file readers are encouraged to make their best efforts - to plot the data. - Thus the implementation of the - ``AXISNAME_indices`` attribute is based on the model of - "strict writer, liberal reader". - - .. note:: Attributes potentially containing multiple values - (axes and _indices) are to be written as string or integer arrays, - to avoid string parsing in reading applications. - \@AXISNAME_depends: - doc: | - Points to the path of a field defining the axis on which the ``AXISNAME`` axis depends. - - This concept allows to link an axis to a respective field in the NeXus hierarchy, thereby - defining the physical quantity it represents. - - Here, *AXISNAME* is to be replaced by the name of each - field described in the ``axes`` attribute. - - Examples: - If a calibration has been performed, ``@AXISNAME_depends`` links to the result of - that calibration: - - @AXISNAME_depends: '/entry/process/calibration/calibrated_axis' - - If the axis corresponds to a coordinate of a detector, ``@AXISNAME_depends`` links - to that detector axis: - - @AXISNAME_depends: '/entry/instrument/detector/axis/some_axis' for a 2D detector - - If the axis is a scanned motor, ``@AXISNAME_depends`` links to the transformation - describing the respective motion, e.g.: - - @AXISNAME_depends: '/entry/instrument/detector/transformations/some_transformation' for a motion of the detector - AXISNAME(NX_NUMBER): - nameType: any - doc: | - 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. - dimensions: - rank: 1 - doc: | - A *dimension scale* must have a rank of 1 and has length ``n``. - dim: [[1, n]] - \@long_name: - doc: | - Axis label - \@distribution: - type: NX_BOOLEAN - doc: | - ``0|false``: single value, - ``1|true``: multiple values - \@first_good: - type: NX_INT - doc: | - Index of first good value - \@last_good: - type: NX_INT - doc: | - Index of last good value - \@axis: - type: NX_POSINT - deprecated: Use the group ``axes`` attribute (NIAC2014) - doc: | - Index (positive integer) identifying this specific set of numbers. - - N.B. The ``axis`` attribute is the old way of designating a link. - Do not use the ``axes`` attribute with the ``axis`` attribute. - The ``axes`` *group* attribute is now preferred. - FIELDNAME_errors(NX_NUMBER): - nameType: any - doc: | - "Errors" (meaning *uncertainties* or *standard deviations*) - associated with any field named ``FIELDNAME`` in this ``NXdata`` - group (e.g. an axis, signal or auxiliary signal). - - The dimensions of the ``FIELDNAME_errors`` field must match - the dimensions of the ``FIELDNAME`` field. - DATA(NX_NUMBER): - nameType: any - doc: | - .. 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. - dimensions: - rank: dataRank - doc: | - The rank (``dataRank``) of the ``data`` must satisfy - ``1 <= dataRank <= NX_MAXRANK=32``. - At least one ``dim`` must have length ``n``. - dim: [] - \@signal: - type: NX_POSINT - deprecated: Use the group ``signal`` attribute (NIAC2014) - doc: | - .. index:: plotting - - Plottable (independent) axis, indicate index number. - Only one field in a :ref:`NXdata` group may have the - ``signal=1`` attribute. - Do not use the ``signal`` attribute with the ``axis`` attribute. - \@axes: - deprecated: Use the group ``axes`` attribute (NIAC2014) - doc: | - Defines the names of the dimension scales - (independent axes) for this data set - as a colon-delimited array. - NOTE: The ``axes`` attribute is the preferred - method of designating a link. - Do not use the ``axes`` attribute with the ``axis`` attribute. - \@long_name: - doc: | - data label - errors(NX_NUMBER): - deprecated: Use ``DATA_errors`` instead (NIAC2018) - doc: | - Standard deviations of data values - - the data array is identified by the group attribute ``signal``. - The ``errors`` array must have the same dimensions as ``DATA``. - Client is responsible for defining the dimensions of the data. - dimensions: - rank: dataRank - doc: | - The ``errors`` must have - the same rank (``dataRank``) - as the ``data``. - At least one ``dim`` must have length "n". - dim: [] - scaling_factor(NX_FLOAT): - doc: | - The elements in data are usually float values really. For - efficiency reasons these are usually stored as integers - after scaling with a scale factor. This value is the scale - factor. It is required to get the actual physical value, - when necessary. - offset(NX_FLOAT): - doc: | - An optional offset to apply to the values in data. - title: - doc: | - Title for the plot. - x(NX_FLOAT): - unit: NX_ANY - doc: | - This is an array holding the values to use for the x-axis of - data. The units must be appropriate for the measurement. - dimensions: - rank: 1 - dim: [[1, nx]] - y(NX_FLOAT): - unit: NX_ANY - doc: | - This is an array holding the values to use for the y-axis of - data. The units must be appropriate for the measurement. - dimensions: - rank: 1 - dim: [[1, ny]] - z(NX_FLOAT): - unit: NX_ANY - doc: | - This is an array holding the values to use for the z-axis of - data. The units must be appropriate for the measurement. - dimensions: - rank: 1 - dim: [[1, nz]] +NXdata_mpes_detector(NXdata): raw(NX_NUMBER): doc: | Raw data before calibration. @@ -513,7 +111,7 @@ NXdata_mpes_detector(NXobject): and write it to the top-level NXdata_mpes. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 75f02d5e8f52c53a48d2d0cb777c9641f3767de5ea6f7921e3581ac52d83c6d3 +# 859f68ddc5c8198cdef216da02ea6316d9a28439fb57da2321a289c8a966d669 # # # -# -# -# -# -# These symbols will be used below to coordinate fields with the same -# shape. -# -# -# -# rank of the ``DATA`` field -# -# -# -# -# length of the ``AXISNAME`` field -# -# -# -# -# length of the ``x`` field -# -# -# -# -# length of the ``y`` field -# -# -# -# -# length of the ``z`` field -# -# -# +# # # :ref:`NXdata_mpes_detector` describes the plottable data and related # dimension scales for raw detector data in photoemission experiments. # # It extends the NXdata class and provides a glossary of explicitly named axis names # which are typical for raw photoemission data. -# -# For now, the extension of NXdata is performed by simply copying all existing groups, fields, -# and attibute from NXdata. In the future, it is envisioned that this extension can be solved by -# base class inheritance. -# -# .. 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) # -# -# -# .. index:: plotting -# -# Array of strings holding the :ref:`names <validItemName>` of additional -# signals to be plotted with the default :ref:`signal </NXdata@signal-attribute>`. -# These fields or links *must* exist and be direct children of this NXdata group. -# -# Each auxiliary signal needs to be of the same shape as the default signal. -# -# .. NIAC2018: -# https://www.nexusformat.org/NIAC2018Minutes.html -# -# -# -# -# .. 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 <validItemName>` 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. -# -# -# -# -# -# -# -# .. index:: plotting -# -# Array of strings holding the :ref:`names <validItemName>` of -# the independent data fields used in the default plot for all of -# the dimensions of the :ref:`signal </NXdata@signal-attribute>` -# as well as any :ref:`auxiliary signals </NXdata@auxiliary_signals-attribute>`. -# -# 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. -# -# -# -# -# -# -# Each ``AXISNAME_indices`` attribute indicates the dependency -# relationship of the ``AXISNAME`` field (where ``AXISNAME`` -# is the name of a field that exists in this ``NXdata`` group) -# with one or more dimensions of the plottable data. -# -# Integer array that defines the indices of the *signal* field -# (that field will be a multidimensional array) -# which need to be used in the *AXISNAME* field in -# order to reference the corresponding axis value. -# -# The first index of an array is ``0`` (zero). -# -# Here, *AXISNAME* is to be replaced by the name of each -# field described in the ``axes`` attribute. -# An example with 2-D data, :math:`d(t,P)`, will illustrate:: -# -# data_2d:NXdata -# @signal="data" -# @axes=["time", "pressure"] -# @time_indices=0 -# @pressure_indices=1 -# data: float[1000,20] -# time: float[1000] -# pressure: float[20] -# -# This attribute is to be provided in all situations. -# However, if the indices attributes are missing -# (such as for data files written before this specification), -# file readers are encouraged to make their best efforts -# to plot the data. -# Thus the implementation of the -# ``AXISNAME_indices`` attribute is based on the model of -# "strict writer, liberal reader". -# -# .. note:: Attributes potentially containing multiple values -# (axes and _indices) are to be written as string or integer arrays, -# to avoid string parsing in reading applications. -# -# -# -# -# Points to the path of a field defining the axis on which the ``AXISNAME`` axis depends. -# -# This concept allows to link an axis to a respective field in the NeXus hierarchy, thereby -# defining the physical quantity it represents. -# -# Here, *AXISNAME* is to be replaced by the name of each -# field described in the ``axes`` attribute. -# -# Examples: -# If a calibration has been performed, ``@AXISNAME_depends`` links to the result of -# that calibration: -# -# @AXISNAME_depends: '/entry/process/calibration/calibrated_axis' -# -# If the axis corresponds to a coordinate of a detector, ``@AXISNAME_depends`` links -# to that detector axis: -# -# @AXISNAME_depends: '/entry/instrument/detector/axis/some_axis' for a 2D detector -# -# If the axis is a scanned motor, ``@AXISNAME_depends`` links to the transformation -# describing the respective motion, e.g.: -# -# @AXISNAME_depends: '/entry/instrument/detector/transformations/some_transformation' for a motion of the detector -# -# -# -# -# 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. -# -# -# -# A *dimension scale* must have a rank of 1 and has length ``n``. -# -# -# -# -# -# Axis label -# -# -# -# -# ``0|false``: single value, -# ``1|true``: multiple values -# -# -# -# -# Index of first good value -# -# -# -# -# Index of last good value -# -# -# -# -# Index (positive integer) identifying this specific set of numbers. -# -# N.B. The ``axis`` attribute is the old way of designating a link. -# Do not use the ``axes`` attribute with the ``axis`` attribute. -# The ``axes`` *group* attribute is now preferred. -# -# -# -# -# -# "Errors" (meaning *uncertainties* or *standard deviations*) -# associated with any field named ``FIELDNAME`` in this ``NXdata`` -# group (e.g. an axis, signal or auxiliary signal). -# -# The dimensions of the ``FIELDNAME_errors`` field must match -# the dimensions of the ``FIELDNAME`` field. -# -# -# -# -# .. 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. -# -# -# -# The rank (``dataRank``) of the ``data`` must satisfy -# ``1 <= dataRank <= NX_MAXRANK=32``. -# At least one ``dim`` must have length ``n``. -# -# -# -# -# .. index:: plotting -# -# Plottable (independent) axis, indicate index number. -# Only one field in a :ref:`NXdata` group may have the -# ``signal=1`` attribute. -# Do not use the ``signal`` attribute with the ``axis`` attribute. -# -# -# -# -# Defines the names of the dimension scales -# (independent axes) for this data set -# as a colon-delimited array. -# NOTE: The ``axes`` attribute is the preferred -# method of designating a link. -# Do not use the ``axes`` attribute with the ``axis`` attribute. -# -# -# -# -# data label -# -# -# -# -# -# Standard deviations of data values - -# the data array is identified by the group attribute ``signal``. -# The ``errors`` array must have the same dimensions as ``DATA``. -# Client is responsible for defining the dimensions of the data. -# -# -# -# The ``errors`` must have -# the same rank (``dataRank``) -# as the ``data``. -# At least one ``dim`` must have length "n". -# -# -# -# -# -# The elements in data are usually float values really. For -# efficiency reasons these are usually stored as integers -# after scaling with a scale factor. This value is the scale -# factor. It is required to get the actual physical value, -# when necessary. -# -# -# -# -# An optional offset to apply to the values in data. -# -# -# -# -# Title for the plot. -# -# -# -# -# This is an array holding the values to use for the x-axis of -# data. The units must be appropriate for the measurement. -# -# -# -# -# -# -# -# This is an array holding the values to use for the y-axis of -# data. The units must be appropriate for the measurement. -# -# -# -# -# -# -# -# This is an array holding the values to use for the z-axis of -# data. The units must be appropriate for the measurement. -# -# -# -# -# # # # Raw data before calibration. diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 3e4525615e..c24f19a245 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -153,7 +153,7 @@ NXmpes(NXobject): A reference to a beam emitted by this source. Should be named with the same appendix, e.g., for `source_probe` it should refer to `beam_probe`. - + Example: * /entry/instrument/source_probe = /entry/instrument/beam_probe beamTYPE(NXbeam): @@ -186,7 +186,7 @@ NXmpes(NXobject): Should be named with the same appendix, e.g., for `beam_probe` it should refer to `source_probe`. This should be specified if an associated source exists. - + Example: * /entry/instrument/beam_probe = /entry/instrument/source_probe (NXelectronanalyser): @@ -312,7 +312,7 @@ NXmpes(NXobject): exists: recommended identifier: exists: recommended - raw_data(NXdata_mpes_detector): + raw_data(NXdata): exists: recommended doc: | Contains the raw data collected by the detector before calibration. @@ -321,8 +321,7 @@ NXmpes(NXobject): This field ideally collects the data with the lowest level of processing possible. - The naming of fields should follow the convention defined in the - :ref:`NXdata_mpes_detector` base class: + Fields should be named according to new following convention: - **pixel_x**: Detector pixel in x direction. - **pixel_y**: Detector pixel in y direction. @@ -651,17 +650,16 @@ NXmpes(NXobject): Flood gun creating a current of low-energy electrons. This should be a link to /entry/instrument/flood_gun. - data(NXdata_mpes): + data(NXdata): doc: | The default NXdata field containing a view on the measured data. This NXdata field contains a collection of the main relevant fields (axes). If you want to provide additional views on your data, you can additionally use the generic NXdata group of NXentry. - In NXmpes, it is required to provide an energy axis. - - The naming of fields should follow the convention defined in the - :ref:`NXdata_mpes` base class: + In NXmpes, it is recommended to provide an energy axis. + + Fields should be named according to the following convention: - **energy**: Calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). - **kx**: Calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). @@ -709,7 +707,7 @@ NXmpes(NXobject): @energy_depends: 'entry/process/energy_calibration' # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f0c42cd7a99b56711a1a70d6fb23d4d88d3127506389681d53d317f45f06dbb5 +# 9ea347ed6f3c68df8cb769ded6664f6a28521356ec4a8cf7585bca6c6318e727 # # # Identifiers can be defined either implicitly or explicitly. For implicit indexing identifiers are defined on the interval - :math:`[identifier_offset, identifier_offset + c - 1]`. + :math:`[identifier\_offset, identifier\_offset + c - 1]`. Therefore, implicit identifier are completely defined by the value of identifier_offset and cardinality. For example if identifier run from diff --git a/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml b/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml index e942c37b21..9441eb0369 100644 --- a/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml +++ b/contributed_definitions/NXapm_charge_state_analysis.nxdl.xml @@ -67,10 +67,10 @@ input/config--> Nuclides are encoded using the hashing rule that is defined in :ref:`NXion`. As an example, a ranging definition H:2 O:1 is configured by setting nuclides to - a list with entries :math:`1 + 256 * 0`, :math:`1 + 256 * 0`, :math:`8 + 256 * 0`. + a list with entries :math:`1 + 0 \cdot 256`, :math:`1 + 0 \cdot 256`, :math:`8 + 0 \cdot 256`. An empty list does not release the constraint. Instead, a list with all elements in the periodic table (encoded as nuclide_hash values) should be used, i.e. - :math:`1 + 256 * 0`, :math:`2 + 256 * 0`, and so on and so forth. + :math:`1 + 0 \cdot 256`, :math:`2 + 0 \cdot 256`, and so on and so forth. Keep in mind that with a weakly constrained parameter space the combinatorial analysis may become very time consuming! diff --git a/contributed_definitions/NXapm_compositionspace_config.nxdl.xml b/contributed_definitions/NXapm_compositionspace_config.nxdl.xml index fe14ad5f23..ef78b66862 100644 --- a/contributed_definitions/NXapm_compositionspace_config.nxdl.xml +++ b/contributed_definitions/NXapm_compositionspace_config.nxdl.xml @@ -87,78 +87,48 @@ - + - Edge length of the grid that is used to discretize the point cloud in the - voxelization step. + Edge length of the cubic voxels that is used for discretizing the point cloud in + the voxelization step. - TODO - - - - - TODO + The maximum number of components configured for the segmentation of the voxel + set into a mixture of voxels with that many different chemical compositions. The configuration of the machine learning model used in the segmentation step. - - - Name of the model to be used. - - + - Configuration for the Gaussian mixture model. - - - - TODO - - - - - TODO - - - - - Report debug information yes or no. - - - - - - Configuration for the random forest model. + Configuration for the Gaussian mixture model that is used in the segmentation + step. - - - TODO - - - - - TODO - - + - Configuration for the DBScan used in the clustering step. + Configuration for the DBScan algorithm that is used in the clustering step. - TODO + The maximum distance between two samples for one to + be considered as in the neighborhood of the other. - TODO + The number of samples (or total weight) in a neighborhood + for a point to be considered as a core point. diff --git a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml index 42f650503d..b6536254d0 100644 --- a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml +++ b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml @@ -227,7 +227,7 @@ if one coordinate system is defined the origin is defined in this cs--> - + TODO @@ -297,7 +297,7 @@ if one coordinate system is defined the origin is defined in this cs--> TODO - + TODO diff --git a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml index 6fcd29b4c5..db520494fe 100644 --- a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml @@ -52,7 +52,7 @@ Volumetric overlap and proximity of volumetric features is identified for members of sets of features to members of other sets of volumetric features. Specifically, for each time - step :math:`$k$` pairs of sets are compared: + step :math:`k` pairs of sets are compared: Members of a so-called current_set to members of a so-called next_set. Members can be different types of volumetric features. diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml index b95f0df993..4b8e2d3a55 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml @@ -180,7 +180,7 @@ The cardinality/total number of triangles in the triangle soup.--> Integer which specifies the first index to be used for distinguishing identifiers for cells. Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are - defined on the interval [identifier_offset, identifier_offset+c-1]. + defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array has to be defined. @@ -234,7 +234,7 @@ The cardinality/total number of triangles in the triangle soup.--> Integer which specifies the first index to be used for distinguishing hexahedra. Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are defined on the interval - [identifier_offset, identifier_offset+c-1]. + :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array has to be defined. @@ -244,7 +244,7 @@ The cardinality/total number of triangles in the triangle soup.--> Integer which specifies the first index to be used for distinguishing identifiers for vertices. Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are defined on the interval - [identifier_offset, identifier_offset+c-1]. For explicit indexing the identifier array + :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array has to be defined. @@ -253,7 +253,7 @@ The cardinality/total number of triangles in the triangle soup.--> Integer which specifies the first index to be used for distinguishing identifiers for faces. Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are defined on the interval - [identifier_offset, identifier_offset+c-1]. For explicit indexing the identifier array + :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array has to be defined. @@ -537,7 +537,7 @@ The cardinality/total number of triangles in the triangle soup.--> Integer which specifies the first index to be used for distinguishing triangles. Identifiers are defined either implicitly or explicitly. For implicit indexing the - identifiers are defined on the interval [identifier_offset, identifier_offset+c-1]. + identifiers are defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml index e8cb457bc1..bcdbab8a67 100644 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ b/contributed_definitions/NXcg_primitive_set.nxdl.xml @@ -94,7 +94,7 @@ to enable an instantiation of the actual geometric primitives--> Identifiers can be defined either implicitly or explicitly. For implicit indexing identifiers are defined on the interval - :math:`[identifier_offset, identifier_offset + c - 1]`. + :math:`[identifier\_offset, identifier\_offset + c - 1]`. Therefore, implicit identifier are completely defined by the value of identifier_offset and cardinality. For example if identifier run from diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index 921663cef6..21ccde1670 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -192,9 +192,9 @@ used algorithm. Dictionary-based alternatives are emerging.--> - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + The hash value :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. + of each isotope respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ diff --git a/contributed_definitions/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index 7f7fbdf77a..8fd3685a1a 100644 --- a/contributed_definitions/NXdelocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -110,9 +110,9 @@ and the interpretation model that to consider carbon atoms or carbon ions--> A list of nuclides based on which to evaluate the weight. Nuclides need to exist in the nuclide table. - Values are nuclide (isotope) hash values using the following hashing rule :math:`$H = Z + 256 * N$` - with :math:`$Z$` the number of protons and :math:`$N$` the number of neutrons of the nuclide. - For elements set :math:`$N$` to zero. + Values are nuclide (isotope) hash values using the following hashing rule :math:`H = Z + N \cdot 256` + with :math:`Z` the number of protons and :math:`N` the number of neutrons of the nuclide. + For elements set :math:`N` to zero. diff --git a/contributed_definitions/NXevent_data_apm.nxdl.xml b/contributed_definitions/NXevent_data_apm.nxdl.xml index 878a5c3ff0..6c287de045 100644 --- a/contributed_definitions/NXevent_data_apm.nxdl.xml +++ b/contributed_definitions/NXevent_data_apm.nxdl.xml @@ -111,7 +111,7 @@ Identifiers can be defined either implicitly or explicitly. For implicit indexing identifiers are defined on the interval - :math:`[identifier_offset, identifier_offset + c - 1]`. + :math:`[identifier\_offset, identifier\_offset + c - 1]`. Therefore, implicit identifier are completely defined by the value of identifier_offset and cardinality. For example if identifier run from diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index bd59185528..899da7a1a4 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -56,7 +56,7 @@ edges. Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are defined on the interval - :math:`[identifier_offset, identifier_offset + c - 1]`. + :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing use the field identifier. For implicit indexing, consult :ref:`NXcg_primitive_set` to get guidance how to set identifier_offset. diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index d234097946..8b6be77af8 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -81,7 +81,7 @@ nodes. Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are defined on the interval - :math:`[identifier_offset, identifier_offset + c - 1]`. + :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing use the field identifier. For implicit indexing, consult :ref:`NXcg_primitive_set` to get guidance how to set identifier_offset. diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml index 169d4c8cbd..048eb5d336 100644 --- a/contributed_definitions/NXion.nxdl.xml +++ b/contributed_definitions/NXion.nxdl.xml @@ -65,7 +65,7 @@ Vector of nuclide hash values. - Individual hash values :math:`H` is :math:`H = Z + N*256` with :math:`Z` + Individual hash values :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` encode the number of protons :math:`Z` and the number of neutrons :math:`N` of each nuclide respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. diff --git a/contributed_definitions/NXms.nxdl.xml b/contributed_definitions/NXms.nxdl.xml index 32ab2191b7..c529de418e 100644 --- a/contributed_definitions/NXms.nxdl.xml +++ b/contributed_definitions/NXms.nxdl.xml @@ -339,7 +339,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_hexahedron_set because can be Integer which specifies the first index to be used for distinguishing snapshots. Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. + interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array has to be defined. The identifier_offset field can for example be used to communicate diff --git a/contributed_definitions/NXms_feature_set.nxdl.xml b/contributed_definitions/NXms_feature_set.nxdl.xml index 2f2010d0e6..13cba91083 100644 --- a/contributed_definitions/NXms_feature_set.nxdl.xml +++ b/contributed_definitions/NXms_feature_set.nxdl.xml @@ -173,7 +173,7 @@ end up as links--> Integer which specifies the first index to be used for distinguishing features. Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. + interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array has to be defined. The identifier_offset field can for example be used to communicate if the diff --git a/contributed_definitions/NXms_recon.nxdl.xml b/contributed_definitions/NXms_recon.nxdl.xml index f44d34239a..ae4014c48b 100644 --- a/contributed_definitions/NXms_recon.nxdl.xml +++ b/contributed_definitions/NXms_recon.nxdl.xml @@ -186,7 +186,7 @@ ONE DIMENSIONAL FEATURES--> Identifiers can be defined either implicitly or explicitly. For implicit indexing identifiers are defined on the interval - :math:`[identifier_offset, identifier_offset + c - 1]`. + :math:`[identifier\_offset, identifier\_offset + c - 1]`. @@ -331,7 +331,7 @@ properties, descriptors--> Identifiers can be defined either implicitly or explicitly. For implicit indexing identifiers are defined on the interval - :math:`[identifier_offset, identifier_offset + c - 1]`. + :math:`[identifier\_offset, identifier\_offset + c - 1]`. @@ -384,7 +384,7 @@ i) triplet of interface identifier--> Identifiers can be defined either implicitly or explicitly. For implicit indexing identifiers are defined on the interval - :math:`[identifier_offset, identifier_offset + c - 1]`. + :math:`[identifier\_offset, identifier\_offset + c - 1]`. diff --git a/contributed_definitions/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml index 24243000c5..fa7e9c20e9 100644 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ b/contributed_definitions/NXms_score_results.nxdl.xml @@ -368,7 +368,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele Integer which specifies the first index to be used for distinguishing snapshots. Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. + interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array has to be defined. The identifier_offset field can for example be used to communicate diff --git a/contributed_definitions/NXms_snapshot_set.nxdl.xml b/contributed_definitions/NXms_snapshot_set.nxdl.xml index 4bc9269763..03395113ca 100644 --- a/contributed_definitions/NXms_snapshot_set.nxdl.xml +++ b/contributed_definitions/NXms_snapshot_set.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -44,7 +44,7 @@ Integer which specifies the first index to be used for distinguishing snapshots. Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. + interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array has to be defined. The identifier_offset field can for example be used to communicate if the diff --git a/contributed_definitions/NXunit_cell.nxdl.xml b/contributed_definitions/NXunit_cell.nxdl.xml index 7222cfc620..4dcc5af26d 100644 --- a/contributed_definitions/NXunit_cell.nxdl.xml +++ b/contributed_definitions/NXunit_cell.nxdl.xml @@ -1,10 +1,10 @@ - + - + @@ -1045,15 +1045,15 @@ in an e.g. work of A. London et al.--> Category for the peak offering a qualitative statement of the location of the peak in light of limited mass-resolving power that is relevant for - composition quantification. See `D. Larson et al. <https://doi.org/10.1007/978-1-4614-8721-0>`_ + composition quantification. See `D. Larson et al. (p172) <https://doi.org/10.1007/978-1-4614-8721-0>`_ for examples of each category: - * 0, well-separated, 10^B +, 28^Si ++ - * 1, close, but typically sufficiently separated with LEAP system, 14^N +, 28^Si ++ - * 2, closely overlapping, demands better than LEAP4000X MRP, 14^N +, 28^Si ++ - * 3, overlapped, multi-charge state, 16^O 16^O ++, 16^O + - * 4, overlapped, same charge state, not discriminatable with a LEAP4000X, 14^N 14^N + 28^Si + - * 5, overlapped, same charge state, any expectation of resolvability, 54^Cr ++, 54^Fe ++ + * 0, well-separated, :math:`^{10}B^{+}`, :math:`^{28}Si^{2+}` + * 1, close, but can be sufficiently separated for quantification in a LEAP system, :math:`^{94}Mo^{3+}`, :math:`^{63}Cu^{2+}` + * 2, closely overlapping, demands better than LEAP4000X MRP can provide :math:`^{14}N^{+}`, :math:`^{28}Si^{2+}` at different charge states + * 3, overlapped exactly due to multi-charge molecular species, :math:`^{16}{O_{2}}^{2+}`, :math:`^{16}O^{+}` + * 4, overlapped, same charge state, cannot as of 2013 be discriminated with a LEAP4000X, :math:`^{14}{N_{2}}^{+}`, :math:`^{28}Si^{+}` + * 5, overlapped, same charge state, any expectation of resolvability, :math:`^{54}Cr^{2+}`, :math:`^{54}Fe^{2+}` diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml index 61729c3a25..3cf277d03a 100644 --- a/contributed_definitions/nyaml/NXapm.yaml +++ b/contributed_definitions/nyaml/NXapm.yaml @@ -29,7 +29,7 @@ NXapm(NXobject): The configuration of the I/O writer software (e.g. `pynxtools `_ or its plugins) which was used to generate this NeXus file instance. # command_line_call(NX_CHAR): - programID(NXprogram): # understood by default as PROGRAM(NXprogram), i.e. program1, program2, ... + programID(NXprogram): # program1, program2, ... exists: [min, 0, max, infty] doc: | A collection of all programs and libraries which are considered relevant @@ -271,7 +271,7 @@ NXapm(NXobject): challenged by these differences as at.-% and wt.-% are both fractional quantities. enumeration: [atom_percent, weight_percent] - (NXion): + ionID(NXion): exists: [min, 1, max, 118] chemical_symbol(NX_CHAR): doc: | @@ -804,7 +804,7 @@ NXapm(NXobject): reconstructed_positions(NX_FLOAT): dim: (n, 3) naive_discretization(NXprocess): - (NXprogram): + programID(NXprogram): exists: [min, 1, max, infty] program(NX_CHAR): \@version(NX_CHAR): @@ -918,15 +918,15 @@ NXapm(NXobject): doc: | Category for the peak offering a qualitative statement of the location of the peak in light of limited mass-resolving power that is relevant for - composition quantification. See `D. Larson et al. `_ + composition quantification. See `D. Larson et al. (p172) `_ for examples of each category: - * 0, well-separated, 10^B +, 28^Si ++ - * 1, close, but typically sufficiently separated with LEAP system, 14^N +, 28^Si ++ - * 2, closely overlapping, demands better than LEAP4000X MRP, 14^N +, 28^Si ++ - * 3, overlapped, multi-charge state, 16^O 16^O ++, 16^O + - * 4, overlapped, same charge state, not discriminatable with a LEAP4000X, 14^N 14^N + 28^Si + - * 5, overlapped, same charge state, any expectation of resolvability, 54^Cr ++, 54^Fe ++ + * 0, well-separated, :math:`^{10}B^{+}`, :math:`^{28}Si^{2+}` + * 1, close, but can be sufficiently separated for quantification in a LEAP system, :math:`^{94}Mo^{3+}`, :math:`^{63}Cu^{2+}` + * 2, closely overlapping, demands better than LEAP4000X MRP can provide :math:`^{14}N^{+}`, :math:`^{28}Si^{2+}` at different charge states + * 3, overlapped exactly due to multi-charge molecular species, :math:`^{16}{O_{2}}^{2+}`, :math:`^{16}O^{+}` + * 4, overlapped, same charge state, cannot as of 2013 be discriminated with a LEAP4000X, :math:`^{14}{N_{2}}^{+}`, :math:`^{28}Si^{+}` + * 5, overlapped, same charge state, any expectation of resolvability, :math:`^{54}Cr^{2+}`, :math:`^{54}Fe^{2+}` enumeration: [0, 1, 2, 3, 4, 5] position(NX_NUMBER): From 2fc2e555dde237a1c273bd6e5a19e52dd795539c Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Thu, 18 Apr 2024 09:45:38 +0200 Subject: [PATCH 0668/1012] Improve nexus namefitting + add tests (#213) * Allow whitespace in namefitting * Adds tests for namefitting * Adds test for namefitting precedence * Add additional test for namefitting precedence * Black reformatting * Use sequence matcher * isort * Remove similiarity match function * Fix namefit function * Use NIAC regex * Fix number in the beginning in namefitting * Format with black * Update namefitting with new algorithm * Improve regex --- dev_tools/tests/test_nxdl_utils.py | 62 +++++++++++++++++++++++++++-- dev_tools/utils/nxdl_utils.py | 64 +++++++++++++++++++++--------- 2 files changed, 104 insertions(+), 22 deletions(-) diff --git a/dev_tools/tests/test_nxdl_utils.py b/dev_tools/tests/test_nxdl_utils.py index 3ca12e36e1..8618271d31 100644 --- a/dev_tools/tests/test_nxdl_utils.py +++ b/dev_tools/tests/test_nxdl_utils.py @@ -1,6 +1,4 @@ -"""This is a code that performs several tests on nexus tool - -""" +"""This is a code that performs several tests on nexus tool""" # # Copyright The NOMAD Authors. @@ -23,6 +21,7 @@ import os import lxml.etree as ET +import pytest from ..utils import nxdl_utils as nexus @@ -136,3 +135,60 @@ def test_get_inherited_nodes(): nx_name="NXiv_temp", ) assert len(elist) == 4 + + +@pytest.mark.parametrize( + "hdf_name,concept_name,should_fit", + [ + ("source_pump", "sourceType", False), + ("source_pump", "sourceTYPE", True), + ("source pump", "sourceTYPE", False), + ("source", "sourceTYPE", False), + ("source123", "SOURCE", True), + ("1source", "SOURCE", True), + ("_source", "SOURCE", True), + ("same_name", "same_name", True), + ("angular_energy_resolution", "angularNresolution", True), + ("angularresolution", "angularNresolution", False), + ("Name with some whitespaces in it", "ENTRY", False), + ("simple_name", "TEST", True), + (".test", "TEST", False), + ], +) +def test_namefitting(hdf_name, concept_name, should_fit): + """Test namefitting of nexus concept names""" + if should_fit: + assert nexus.get_nx_namefit(hdf_name, concept_name) > -1 + else: + assert nexus.get_nx_namefit(hdf_name, concept_name) == -1 + + +@pytest.mark.parametrize( + "hdf_name,concept_name, score", + [ + ("test_name", "TEST_name", 9), + ("te_name", "TEST_name", 7), + ("my_other_name", "TEST_name", 5), + ("test_name", "test_name", 18), + ("test_other", "test_name", -1), + ("my_fancy_yet_long_name", "my_SOME_name", 8), + ], +) +def test_namefitting_scores(hdf_name, concept_name, score): + """Test namefitting of nexus concept names""" + assert nexus.get_nx_namefit(hdf_name, concept_name) == score + + +@pytest.mark.parametrize( + "better_fit,better_ref,worse_fit,worse_ref", + [ + ("sourcetype", "sourceTYPE", "source_pump", "sourceTYPE"), + ("source_pump", "sourceTYPE", "source_pump", "TEST"), + ], +) +def test_namefitting_precedence(better_fit, better_ref, worse_fit, worse_ref): + """Test if namefitting follows proper precedence rules""" + + assert nexus.get_nx_namefit(better_fit, better_ref) > nexus.get_nx_namefit( + worse_fit, worse_ref + ) diff --git a/dev_tools/utils/nxdl_utils.py b/dev_tools/utils/nxdl_utils.py index 436f678ab4..7a29f0d86a 100644 --- a/dev_tools/utils/nxdl_utils.py +++ b/dev_tools/utils/nxdl_utils.py @@ -1,6 +1,5 @@ # pylint: disable=too-many-lines -"""Parse NeXus definition files -""" +"""Parse NeXus definition files""" import os import re @@ -108,42 +107,69 @@ def get_nx_class(nxdl_elem): return nxdl_elem.attrib.get("type", "NX_CHAR") -def get_nx_namefit(hdf_name, name, name_any=False): +def get_nx_namefit(hdf_name: str, name: str, name_any: bool = False) -> int: """ Checks if an HDF5 node name corresponds to a child of the NXDL element. - A group of uppercase letters anywhere can be replaced by an arbitrary name. + A group of uppercase letters anywhere in the name is treated as freely choosable + part of this name. + If a match is found this function returns twice the length for an exact match, + otherwise the number of matching characters (case insensitive) or zero, if + `name_any` is set to True, is returned. + All uppercase groups are considered independently. + Lowercase matches are independent of uppercase group lengths, e.g., + an hdf_name `get_nx_namefit("my_fancy_yet_long_name", "my_SOME_name")` would + return a score of 8 for the lowercase matches `my_..._name`. + All characters in `[a-zA-Z0-9_.]` are considered for matching to an uppercase letter. + If you use any other letter in the name, it will not match and return -1. + Periods at the beginning or end of the hdf_name are not allowed, only exact + matches will be considered. + + Examples: + + * `get_nx_namefit("test_name", "TEST_name")` returns 9 + * `get_nx_namefit("te_name", "TEST_name")` returns 7 + * `get_nx_namefit("my_other_name", "TEST_name")` returns 5 + * `get_nx_namefit("test_name", "test_name")` returns 18 + * `get_nx_namefit("test_other", "test_name")` returns -1 Args: - hdf_name (str): The hdf_name, containing uppercase parts. - name (str): The string to match against hdf_name. + hdf_name (str): The hdf_name, containing the name of the HDF5 node. + name (str): The concept name to match against. name_any (bool, optional): - Accept any name and just return the matching characters. + Accept any name and return either 0 (match) or -1 (no match). Defaults to False. Returns: - int: - -1 if no match is found or the number of matching - characters (case insensitive) between for all uppercase groups. + int: -1 if no match is found or the number of matching + characters (case insensitive). """ + path_regex = r"([a-zA-Z0-9_.]+)" + if name == hdf_name: return len(name) * 2 + if hdf_name.startswith(".") or hdf_name.endswith("."): + # Don't match anything with a dot at the beginning or end + return -1 - uppercase_parts = re.findall("[A-Z]+(?:_[A-Z]+)*", name) + uppercase_parts = re.findall(r"[A-Z]+(?:_[A-Z]+)*", name) + regex_name = name + uppercase_count = 0 for up in uppercase_parts: - name = name.replace(up, r"([a-zA-Z0-9_]+)") + uppercase_count += len(up) + regex_name = regex_name.replace(up, path_regex) - name_match = re.search(rf"^{name}$", hdf_name) + name_match = re.search(rf"^{regex_name}$", hdf_name) if name_match is None: return 0 if name_any else -1 - fit = 0 - for up, low in zip(uppercase_parts, name_match.groups()): - for i in range(min(len(up), len(low))): - if up[i].lower() == low[i]: - fit += 1 + match_count = 0 + for uppercase, match in zip(uppercase_parts, name_match.groups()): + for s1, s2 in zip(uppercase.upper(), match.upper()): + if s1 == s2: + match_count += 1 - return fit + return len(name) + match_count - uppercase_count def get_nx_classes(): From 88ff215394769fdcd2e15c74c20adec2ae10cbf7 Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Thu, 18 Apr 2024 18:22:12 +0200 Subject: [PATCH 0669/1012] Change `get_enums` to return a list (#218) * Change `get_enums` to return a list * Update get_enums to return whether an enum was found * Fix use of get_enums function * isorting * Use None instead of true/false tuple * Update docstring --- dev_tools/utils/nxdl_utils.py | 36 ++++++++++++++++++++++------------- 1 file changed, 23 insertions(+), 13 deletions(-) diff --git a/dev_tools/utils/nxdl_utils.py b/dev_tools/utils/nxdl_utils.py index 7a29f0d86a..5764e0ae9c 100644 --- a/dev_tools/utils/nxdl_utils.py +++ b/dev_tools/utils/nxdl_utils.py @@ -7,6 +7,8 @@ from functools import lru_cache from glob import glob from pathlib import Path +from typing import List +from typing import Optional import lxml.etree as ET from lxml.etree import ParseError as xmlER @@ -593,13 +595,15 @@ def get_doc(node, ntype, nxhtml, nxpath): doc_field = node.find("doc") if doc_field is not None: doc = doc_field.text - (index, enums) = get_enums(node) # enums - if index: + enums = get_enums(node) # enums + if enums is not None: enum_str = ( "\n " - + ("Possible values:" if enums.count(",") else "Obligatory value:") + + ("Possible values:" if len(enums) > 1 else "Obligatory value:") + "\n " - + enums + + "[" + + ",".join(enums) + + "]" + "\n" ) else: @@ -629,20 +633,26 @@ def get_namespace(element): return element.tag[element.tag.index("{") : element.tag.rindex("}") + 1] -def get_enums(node): - """Makes list of enumerations, if node contains any. - Returns comma separated STRING of enumeration values, if there are enum tag, - otherwise empty string.""" - # collect item values from enumeration tag, if any +def get_enums(node: ET._Element) -> Optional[List[str]]: + """ + Makes list of enumerations, if node contains any. + + Args: + node (ET._Element): The node to check for enumerations. + + Returns: + Optional[List[str]]: + Returns a list of the enumeration values if an enumeration was found. + If no enumeration was found it returns None. + """ namespace = get_namespace(node) enums = [] for enumeration in node.findall(f"{namespace}enumeration"): for item in enumeration.findall(f"{namespace}item"): enums.append(item.attrib["value"]) - enums = ",".join(enums) - if enums != "": - return (True, "[" + enums + "]") - return (False, "") # if there is no enumeration tag, returns empty string + if enums: + return enums + return None def add_base_classes(elist, nx_name=None, elem: ET.Element = None): From 717627aa0bf2e95a239e5046f9600f254f786ff6 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 19 Apr 2024 18:20:02 +0200 Subject: [PATCH 0670/1012] readd lost energy units in MPES --- contributed_definitions/NXmpes.nxdl.xml | 2 +- contributed_definitions/nyaml/NXmpes.yaml | 5 +++-- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index ecfa8ba97b..4fb6ca1896 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -795,7 +795,7 @@ actual encoder position in NXinstrument or calibrated axes in NXprocess. - + diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index c24f19a245..d36151fbed 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -693,6 +693,7 @@ NXmpes(NXobject): delay, spin index, temperature, etc. The axes traces should be linked to the actual encoder position in NXinstrument or calibrated axes in NXprocess. energy(NX_NUMBER): + unit: NX_ENERGY exists: recommended \@type: exists: recommended @@ -707,7 +708,7 @@ NXmpes(NXobject): @energy_depends: 'entry/process/energy_calibration' # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 9ea347ed6f3c68df8cb769ded6664f6a28521356ec4a8cf7585bca6c6318e727 +# 4430ade5ec149642cf7641eb5dfef7fbb8f4762bed1a59ced9a42c63ecfb70af # # # - - - + + Variables used throughout the document, e.g. dimensions or parameters. @@ -39,12 +36,6 @@ optical spectroscopy experiments--> data. - - - Number of sensors used to measure parameters that influence the sample, - such as temperature or pressure. - - Number of measurements (1st dimension of measured_data array). This is @@ -64,27 +55,18 @@ optical spectroscopy experiments--> Number of angles of incidence of the incident beam. - - - Number of observables that are saved in a measurement. e.g. one for - intensity, reflectivity or transmittance, two for Psi and Delta etc. This - is equal to the second dimension of the data array 'measured_data' and the - number of column names. - - - An application definition for optical spectroscopy experiments. + A general application definition of optical spectroscopy elements, which may + be used as a template to derive specialized optical spectroscopy experiments. + + Possible specializations are ellipsometry, Raman spectroscopy, photoluminescence, + reflectivity/transmission spectroscopy. + + A general optical experiment consists of (i) a light/photon source, (ii) a sample, + (iii) a detector. - - An application definition template for optical spectroscopy experiments. - - A general optical experiment consists of a light or excitation source, a - beam path, a sample + its stage + its environment, and a detection unit. - Examples are reflection or transmission measurements, photoluminescence, - Raman spectroscopy, ellipsometry etc. - An application definition describing a general optical experiment. @@ -105,58 +87,112 @@ optical spectroscopy experiments--> - + + + + Datetime of the start of the measurement. + Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, + otherwise, the local time zone is assumed per ISO8601. + + + + + Datetime of the end of the measurement. + Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, + otherwise the local time zone is assumed per ISO8601. + + + A (globally persistent) unique identifier of the experiment. - (i) The identifier is usually defined by the facility or principle - investigator. + (i) The identifier is usually defined by the facility, laboratory or + principal investigator. (ii) The identifier enables to link experiments to e.g. proposals. - + + + + An optional free-text description of the experiment. - However, details of the experiment should be defined in the specific - fields of this application definition rather than in this experiment - description. + Users are strongly advised to parameterize the description of their experiment + by using respective groups and fields and base classes instead of writing prose + into this field. + + The reason is that such a free-text field is difficult to machine-interpret. + The motivation behind keeping this field for now is to learn how far the + current base classes need extension based on user feedback. Specify the type of the optical experiment. + + Chose other if non of these methods are suitable. You may specify + fundamental characteristics or properties in the experimental sub-type. + + + + + + + + - + + + Specify a special property or characteristic of the experiment, which specifies + the generic experiment type. + + + + + + + + + + - Start time of the experiment. UTC offset should be specified. + If "other" was selected in "experiment_type", specify the experiment here + with a free text name, which is knwon in the respective community of interest. - + - Contact information of at least the user of the instrument or the - investigator who performed this experiment. - Adding multiple users, if relevant, is recommended. + Contact information and eventually details of at persons who + performed the measurements. This can be for example the principal + investigator or student. + It is recommended to add multiple users if relevant. + + Due to data privacy concerns, there is no minimum requirement. - + - Name of the user. + 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. + Name of the affiliation of the user at the point in time + when the experiment was performed. - + - Street address of the user's affiliation. + Postal address of the user's affiliation. - + - Email address of the user. + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. @@ -164,106 +200,194 @@ optical spectroscopy experiments--> Author ID defined by https://orcid.org/. - + + + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + + + - Telephone number of the user. + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the setup, student, PhD-student, postdoc, principle investigator, or guest + are common examples. + + + Service as another mean of identification of a user other than by its name. + Examples could be an ORCID or social media account of the user. + + + + + - Properties of the experimental setup. This includes general information - about the instrument (such as model, company etc.), information about - the calibration of the instrument, elements of the beam path including - the excitation or light source and the detector unit, the sample stage - (plus the sample environment, which also includes sensors used to - monitor external conditions) and elements of the beam path. + Devices or elements of the optical spectroscopy setup described with its + properties and general information. - Meta data describing the sample should be specified in ENTRY/SAMPLE - outside of ENTRY/INSTRUMENT. + This includes for example: + - The beam device's or instrument's model, company, serial number, construction year, etc. + - Used software or code + - Experiment descriptive parameters as reference frames, resolution, calibration + - Photon beams with their respective properties such as angles and polarization + - Various optical beam path devices, which interact, manipulate or measure optical beams + - Characteristics of the medium surrounding the sample + - "Beam devices" for a beam path description + - Stages(NXmanipulator) + - Sensors and actuators to control or measure sample or beam properties - + - The name of the instrument. + General device information of the optical spectroscopy setup, if + suitable (e.g. for a tabletop spectrometer or other non-custom build setups). + For custom build setups, this may be limited to the construction year. - + + + + - The used version of the hardware if available. If not a commercial - instrument use date of completion of the hardware. + Datetime of setup's initial construction. This refers to the date of + first measurement after new construction or relocation of the setup. + Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, + otherwise the local time zone is assumed per ISO8601. - - - + + + + + + Commercial or otherwise defined given name of the program that was + used to control any parts of the optical spectroscopy setup. + The uppercase TYPE should be replaced by a specification name, i.e. + "software_detector" or "software_stage" to specify the respective + program or software components. + + + + Either version with build number, commit hash, or description of a + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + + + + + Description of the software by persistent resource, where the program, + code, script etc. can be found. + + + + + + + - Name of the company which build the instrument. + Description of one or more coordinate systems that are specific to the + experiment. - - + + - ISO8601 date when the instrument was constructed. - UTC offset should be specified. + Defines the reference frame which is used to describe the sample orientation + with respect to the beam directions. + + A beam centered description is the default and uses 4 angles(similar to XRD): + - Omega (angle between sample surface and incident beam) + - 2Theta (angle between the transmitted beam and the detection beam) + - Chi (sample tilt angle, angle between plane#1 and the surface normal, + plane#1 = spanned by incidence beam and detection + and detection. If Chi=0°, then plane#1 is the plane of + incidence in reflection setups) + - Phi (inplane rotation of sample, rotation axis is the samples + surface normal) + + + A sample normal centered description is as well possible(similar to XX): + - angle of incidence (angle between incident beam and sample surface) + - angle of detection (angle between detection beam and sample surface) + - angle of incident and detection beam (angle between the incident and scattering beam) + - angle of in-plane sample rotation (direction along the sample's surface normal) + + + + + - - + + + The overall resolution of the optical instrument. + + + + + + + + - Commercial or otherwise defined given name of the program that was - used to measure the data, i.e. the software used to start and - record the measured data and/or metadata. - If home written, one can provide the actual steps in the NOTE - subfield here. + Minimum distinguishable wavelength separation of peaks in spectra. - + + + + Pre-calibration of an arbitrary device of the instrumental setup, which + has the name DEVICE. You can specify here at which point + + - Either version with build number, commit hash, or description of a - (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner. + Path to the device, which was calibrated. + Example: entry/instrument/DEVICE - + - Website of the software. + Describe here the approach or method, used to perform the calibration, by a free + text. - - - - - Commercial or otherwise defined name of the firmware that was used - for the measurement - if available. - - + + - Version and build number or commit hash of the software source code. + Provide data about the determined accuracy of the device, this may + may be a single value or a dataset like wavelength error vs. wavelength etc. - - + + - Website of the software. + Was a calibration performed? If yes, when was it done? If the + calibration time is provided, it should be specified in + ENTRY/INSTRUMENT/calibration/calibration_time. - - - - - Was a calibration performed? If yes, when was it done? If the - calibration time is provided, it should be specified in - ENTRY/INSTRUMENT/calibration/calibration_time. - - - - - - - - - - - - The calibration data and metadata should be described in a separate NeXus file - with the link provided in 'calibration_link'. - + + + + + + + + If calibtration status is 'calibration time provided', specify the @@ -271,293 +395,503 @@ optical spectroscopy experiments--> measurement. UTC offset should be specified. - + Link to the NeXus file containing the calibration data and metadata. - + - + + + - Describes an arrangement of optical or other elements, e.g. the beam - path between the light source and the sample, or between the sample - and the detector unit (including the sources and detectors - themselves). + Beam characteristics between two beam_devices. - If a beam splitter (i.e. a device that splits the incoming beam into - two or more beams) is part of the beam path, two or more NXbeam_path - fields may be needed to fully describe the beam paths and the correct - sequence of the beam path elements. - Use as many beam paths as needed to describe the setup. + It is recommended, to at least define one incident and one detection beam. + If this beam is directly connected to an source, chose here the same + name appendix as for the NXsource (e.g. TYPE=532nm) + + + + + + + The path to a the source, which emitted this beam. + Should be named with the same appendix as the source, e.g., + for TYPE=532nmlaser, there should as well be + a NXsource named "source_532nmlaser" aside of this Beam + instance named "beam_532nmlaser" + + Example: /entry/instrument/source_532nmlaser + + + + + + + + + + + + + + Description of the light polarization of the respective beam and the beam-sample-normal. + This is only well defined, if the beam direclty hits the sample (either indicent + beam or detection beam) and if the samples needs to have a clearly + defined sample surface. The beam-sample-normal plane is spanned by + the beam and the samples surface normal. + + If the electric field in in this plane, this value is 0° (P-pol) + If the electric field is perpendicular to this plane, this value is 90° (S-pol) + If the surface normal is parallel to the beam direction, then only the + relation between different polarizations has to be consistent + (i.e. parallel polarized 0° and cross polarized 90°) + + - + + + Angle(s) of the incident beam vs. the normal of the bottom reflective - (substrate) surface in the sample. + (substrate) surface in the sample. These two directions span the plane + of incidence. - + Detection angle(s) of the beam reflected or scattered off the sample vs. the normal of the bottom reflective (substrate) surface in the sample if not equal to the angle(s) of incidence. + These two directions span the plane of detection. - + + + Angle between the incident and detection beam. + If angle_of_detection + angle_of_incidence = angle_of_incident_and_detection_beam, + then the setup is a reflection setup. + If angle_of_detection + angle_of_incidence != angle_of_incident_and_detection_beam + then the setup may be a light scattering setup. + (i.e. 90° + 90° != 90°, i.e. incident and detection beam in the sample surface, but + the angle source-sample-detector is 90°) + + + + + + + - Sample stage, holding the sample at a specific position in X,Y,Z - (Cartesian) coordinate system and at an orientation defined - by three Euler angles (alpha, beta, gamma). + Angle of the inplane orientation of the sample. This might be an arbitrary, + angle without specific relation to the sample symmetry, + of the angle to a specific sample property (i.e. crystallographic axis or sample + shape such as wafer flat) - + + + + + + + Specify if there is a lateral offset on the sample surface, between the focal + points of the incident beam and the detection beam. + + + + + + + + + + + + + + - Specify the type of the sample stage. + Specification of type, may also go to name. + + + + + + The type of light polarization produced by the source. - - - - - + + + + + - + - If there is no motorized stage, we should at least qualify where - the beam hits the sample and in what direction the sample stands - in a free-text description, e.g. 'center of sample, long edge - parallel to the plane of incidence'. + Details about the device information. + + + + The path to a beam emitted by this source. + Should be named with the same appendix, e.g., + for TYPE=532nmlaser, there should as well be + a NXbeam named "beam_532nmlaser" aside of this source + instance named "source_532nmlaser" + + Example: /entry/instrument/beam_532nmlaser + + + + + + + + + + - + - Specify external parameters that have influenced the sample, such - as the surrounding medium, and varied parameters e.g. temperature, - pressure, pH value, optical excitation etc. + Description of the detector type. - - - Describe what was the medium above or around the sample. The - common model is built up from the substrate to the medium on the - other side. Both boundaries are assumed infinite in the model. - Here, define the name of the medium (e.g. water, air, UHV, etc.). - - - - - Array of pairs of complex refractive indices n + ik of the medium - for every measured spectral point/wavelength/energy. - Only necessary if the measurement was performed not in air, or - something very well known, e.g. high purity water. - - - - - - - - - A sensor used to monitor an external condition influencing the - sample, such as temperature or pressure. It is suggested to - replace 'PARAMETER' by the type of the varied parameter defined - in 'parameter_type'. - The measured parameter values should be provided in 'values'. - For each parameter, a 'PARAMETER(NXsensor)' field needs to exist. - In other words, there are N_sensors 'PARAMETER(NXsensor)' fields. - - - - Indicates which parameter was changed. Its definition must exist - below. The specified variable has to be N_measurements long, - providing the parameters for each data set. If you vary more than - one parameter simultaneously. - If the measured parameter is not contained in the list `other` - should be specified and the `parameter_type_name` should be provided. - - - - - - - - - - - - - - - - - - - - - - - - - If the parameter_type is `other` a name should be specified here. - - - - - Number of different parameter values at which the measurement - was performed. For example, if the measurement was performed at - temperatures of 4, 77 and 300 K, then number_of_parameters = 3. - - - - - Vector containing the values of the varied parameter. Its - length is equal to N_measurements. The order of the values - should be as follows: - - * Order the sensors according to number_of_parameters starting - with the lowest number. If number_of_parameters is equal for - two sensors order them alphabetically (sensor/parameter name). - * The first sensor's j parameters should be ordered in the - following way. The first N_measurements/number_of_parameters - entries of the vector contain the first parameter (a1), the - second N_measurements/number_of_parameters contain the second - parameter (a2) etc., so the vector looks like: - [ - a1,a1,...,a1, - a2,a2,...,a2, - ... - aj,aj,...aj - ] - * The kth sensor's m parameters should be ordered in the - following way: - [ - p1,...p1,p2,...,p2,...pm,...,pm, - p1,...p1,p2,...,p2,...pm,...,pm, - ... - p1,...p1,p2,...,p2,...pm,...,pm - ] - * The last sensor's n parameters should be ordered in the - following way: - [ - z1,z2,...,zn, - z1,z2,...,zn, - ... - z1,z2,...,zn] - - For example, if the experiment was performed at three different - temperatures (T1, T2, T3), two different pressures (p1, p2) and - two different angles of incidence (a1, a2), then - N_measurements = 12 and the order of the values for the various - parameter vectors is: - - * angle_of_incidence: [a1,a1,a1,a1,a1,a1,a2,a2,a2,a2,a2,a2] - * pressure: [p1,p1,p1,p2,p2,p2,p1,p1,p1,p2,p2,p2] - * temperature: [T1,T2,T3,T1,T2,T3,T1,T2,T3,T1,T2,T3] - - - - - - + + + + + + + + + + + + + + + - - - For environmental measurements, the environment (liquid, vapor - etc.) is enclosed in a cell, which has windows both in the - direction of the source (entry window) and the detector (exit - window) (looking from the sample). In case that the entry and exit - windows are not the same type and do not have the same properties, - use a second 'WINDOW(MXaperture)' field. - - The windows also add a phase shift to the light altering the - measured signal. This shift has to be corrected based on measuring - a known sample (reference sample) or the actual sample of interest - in the environmental cell. State if a window correction has been - performed in 'window_effects_corrected'. Reference data should be - considered as a separate experiment, and a link to the NeXus file - should be added in reference_data_link in measured_data. - - The window is considered to be a part of the sample stage but also - beam path. Hence, its position within the beam path should be - defined by the 'depends_on' field. + + + Contains the raw data collected by the detector before calibration. + The data which is considered raw might change from experiment to experiment + due to hardware pre-processing of the data. + This field ideally collects the data with the lowest level of processing + possible. - - - Specify the position of the window in the beam path by pointing - to the preceding element in the sequence of beam path elements. - - - - - Was a window correction performed? If 'True' describe the window - correction procedure in 'window_correction/procedure'. - - - - - Was a window correction performed? If 'True' describe the - window correction procedure in '' - - - - Describe when (before or after the main measurement + time - stamp in 'date') and how the window effects have been - corrected, i.e. either mathematically or by performing a - reference measurement. In the latter case, provide the link to - to the reference data in 'reference_data_link'. - - - - - Link to the NeXus file which describes the reference data if a - reference measurement for window correction was performed. - Ideally, the reference measurement was performed on a reference - sample and on the same sample, and using the same conditions as - for the actual measurement with and without windows. It should - have been conducted as close in time to the actual measurement - as possible. - - - - - - The material of the window. - + + - - - - - - - - + - - + + - If you specified 'other' as material, decsribe here what it is. + Raw data before calibration. - + + + + + + + + + + + + + + For environmental measurements, the environment (liquid, vapor + etc.) is enclosed in a cell, which has windows both in the + direction of the source (entry window) and the detector (exit + window) (looking from the sample). In case that the entry and exit + windows are not the same type and do not have the same properties, + use a second 'WINDOW(MXaperture)' field. + + The windows also add a phase shift to the light altering the + measured signal. This shift has to be corrected based on measuring + a known sample (reference sample) or the actual sample of interest + in the environmental cell. State if a window correction has been + performed in 'window_effects_corrected'. Reference data should be + considered as a separate experiment, and a link to the NeXus file + should be added in reference_data_link in measured_data. + + The window is considered to be a part of the sample stage but also + beam path. Hence, its position within the beam path should be + defined by the 'depends_on' field. + + + + Was a window correction performed? If 'True' describe the window + correction procedure in 'window_correction/procedure'. + + + + + Was a window correction performed? If 'True' describe the + window correction procedure in '' + + - Thickness of the window. + Describe when (before or after the main measurement + time + stamp in 'date') and how the window effects have been + corrected, i.e. either mathematically or by performing a + reference measurement. In the latter case, provide the link to + to the reference data in 'reference_data_link'. - + - Angle of the window normal (outer) vs. the substrate normal - (similar to the angle of incidence). + Link to the NeXus file which describes the reference data if a + reference measurement for window correction was performed. + Ideally, the reference measurement was performed on a reference + sample and on the same sample, and using the same conditions as + for the actual measurement with and without windows. It should + have been conducted as close in time to the actual measurement + as possible. + + + The material of the window. + + + + + + + + + + + + + + + If you specified 'other' as material, decsribe here what it is. + + + + + Thickness of the window. + + + + + Angle of the window normal (outer) vs. the substrate normal + (similar to the angle of incidence). + + + + + + Array of pairs of complex refractive indices n + ik of the medium + for every measured spectral point/wavelength/energy. + Only necessary if the measurement was performed not in air, or + something very well known, e.g. high purity water. + + + + + + + + + + Describes the order of respective beam devices in the optical beam + path. + + Everything object which interacts or modifies optical beam properties, + may be an beam device, e.g. Filter, Window, Beamsplitter, Photon Source, + Detector, etc, + + It is intended, to include this functionality later to "older" beam + components, such as NXsource, NXdetector, NXlens, etc. + Until this is possbible, auxillary beam devices have to be created, + for each "older" beam component instead, to allow a beam path description. + To link the auxillary beam device to the real device properties, the + attribute \@device should be used. + + + + Reference to beam device, which is described by a NeXus concept + (e.g. for NXsource, entry/instrument/source_TYPE). + + + + + Reference to the previous beam device, from which the photon beam came + to reach this beam device. A photon source is related as origin by ".". + This enables a logical order description of the optical setup. + + + + + + + Sample stage (or manipulator) for positioning of the sample. This should + only contain the spatial orientation of movement. + + + + Specify the type of the sample stage. + + + + + + + + + + + + + + If "other" was chosen in stage_type, enter here a free text description + of the stage type. + + + + + This is a placeholder, to describe the relation between the samples + coordinate system, laboratory coordinate system and the stage coordinate + system. Up to now, use the "beam_sample_relation" to give supporting + information. + + + + + Description of relation of the beam with the sample. How dit the + sample hit the beam, e.g. 'center of sample, long edge parallel + to the plane of incidence'. + + + + + + + + + + + + + + + + + + Type of control for the sample temperature. Replace TYPE by "cryostat" or + "heater" to specify it. + + + + + + + + + + + + + + + + Hardware used for actuation, i.e. laser, gas lamp, filament, resistive + + + + + + + + + + + + + + + + + Control of arbitrary parameter - compare to temperature above. + + + + + + Hardware used for actuation + + + + + + @@ -569,30 +903,40 @@ optical spectroscopy experiments--> - Descriptive name of the sample + Name of the sample, which is uaually pleases human readability. + This may be, but does not have to be identical to the sample_id. - + - Specify the type of sample, e.g. thin film, single crystal etc. + Uniquely identifying name of the sample. - - - - - - - - + - Qualitative description of the layer structure for the sample, - starting with the top layer (i.e. the one on the front surface, on - which the light incident), e.g. native oxide/bulk substrate, or - Si/native oxide/thermal oxide/polymer/peptide. + State the form of the sample, examples are: + thin film, single crystal, poly crystal, amorphous, single layer, + multi layer, liquid, gas, pellet, powder. - + + + Free text description of the sample. + + + + + + + + + + + + + + + Chemical formula of the sample. Use the Hill system (explained here: https://en.wikipedia.org/wiki/Chemical_formula#Hill_system) to write @@ -603,7 +947,7 @@ optical spectroscopy experiments--> The order must be consistent with layer_structure - + List of comma-separated elements from the periodic table that are contained in the sample. If the sample substance has multiple @@ -611,185 +955,134 @@ optical spectroscopy experiments--> 'atom_types'. - - - Ideally, a reference to the location or a unique (globally - persistent) identifier (e.g.) of e.g. another file which gives - as many as possible details of the material, its microstructure, - and its thermo-chemo-mechanical processing/preparation history. - In the case that such a detailed history of the sample is not - available, use this field as a free-text description to specify - details of the sample and its preparation. - - - ISO8601 date with time zone (UTC offset) specified. + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known timestamp when + the measured specimen surface was actively prepared. - + - Description of the substrate. + A set of activities that occurred to the sample prior to/during the experiment. - - + + + A reference to the location or a unique (globally + persistent) identifier (e.g.) of e.g. another file which gives + as many as possible details of the material, its microstructure, + and its thermo-chemo-mechanical processing/preparation history. + + + + - Specify the sample orientation. + Sample temperature (either controlled or just measured). - - - - - Measured data, data errors, and varied parameters. If reference data - were measured they should be considered a separate experiment and a - link to its NeXus file should be added in reference_data_link. - - + + + Temperature sensor measuring the sample temperature. + This should be a link to /entry/instrument/manipulator/temperature_sensor. + + + + + Device to heat the sample. + This should be a link to /entry/instrument/manipulator/sample_heater. + + + + + Cryostat for cooling the sample. + This should be a link to /entry/instrument/manipulator/cryostat. + + + + - An identifier to correlate data to the experimental conditions, - if several were used in this measurement; typically an index of 0-N. + Arbirary sample property which may be varied during the experiment + and controlled by a device. Examples are pressure, voltage, magnetic field etc. + Similar to the temperautre description of the sample. - - + + + + - Select which type of data was recorded, for example intensity, - reflectivity, transmittance, Psi and Delta etc. - It is possible to have multiple selections. The enumeration list - depends on the type of experiment and may differ for different - application definitions. + (Measured) sample thickness. + + The information is recorded to qualify if the light used was likely + able to shine through the sample. + + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. - - - - - - - - - - - - - + - Spectral values (e.g. wavelength or energy) used for the measurement. - An array of 1 or more elements. Length defines N_spectrum. Replace - 'SPECTRUM' by the physical quantity that is used, e.g. wavelength. + If a thickness if given, please specify how this thickness was estimated or + determined. - - - - - - If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. - If the unit of the measured data is not covered by NXDL units state - here which unit was used. - - - + - Resulting data from the measurement, described by 'data_type'. - - The first dimension is defined by the number of measurements taken, - (N_measurements). The instructions on how to order the values - contained in the parameter vectors given in the doc string of - INSTRUMENT/sample_stage/environment_conditions/PARAMETER/values, - define the N_measurements parameter sets. For example, if the - experiment was performed at three different temperatures - (T1, T2, T3), two different pressures (p1, p2) and two different - angles of incidence (a1, a2), the first measurement was taken at the - parameters {a1,p1,T1}, the second measurement at {a1,p1,T2} etc. + Qualitative description of the layer structure for the sample, + starting with the top layer (i.e. the one on the front surface, on + which the light incident), e.g. native oxide/bulk substrate, or + Si/native oxide/thermal oxide/polymer/peptide. - - - - - - - - If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. - If the unit of the measured data is not covered by NXDL units state - here which unit was used. - - - + - Specified uncertainties (errors) of the data described by 'data_type' - and provided in 'measured_data'. + Specify the sample orientation, how is its sample normal oriented + relative in the laboratory reference frame, incident beam reference + frame. - - - - - - - - If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. - If the unit of the measured data is not covered by NXDL units state - here which unit was used. - - - + - List of links to the values of the sensors. Add a link for each - varied parameter (i.e. for each sensor). + If the sample is grown or fixed on a substrate, specify this here by + a free text description. - - - - + + + + A default view of the data provided in ENTRY/data_collection/measured_data. This + should be the part of the data set which provides the most suitable + representation of the data. + + You may provide multiple instances of NXdata + + - Link to the NeXus file which describes the reference data if a - reference measurement was performed. Ideally, the reference - measurement was performed using the same conditions as the actual - measurement and should be as close in time to the actual measurement - as possible. + Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) - - - - - Commercial or otherwise defined given name of the program that was - used to generate the result file(s) with measured data and/or - metadata (in most cases, this is the same as INSTRUMENT/software). - If home written, one can provide the actual steps in the NOTE - subfield here. - - - - - Either version with build number, commit hash, or description of a - (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner. - - - - - Website of the software. - - - - + + - A plot of the multi-dimensional data array provided in - ENTRY/data/measured_data. + Spectrum, i.e. y-axis of the data (e.g. counts, intensity) - + + + + + - Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) + Location to save the calibrated wavelength data. - + + + >>>This section is transfered from the first NXopt version and might + require a reqwork.<<< Parameters that are derived from the measured data. @@ -852,17 +1145,5 @@ optical spectroscopy experiments--> - - - A default view of the data provided in ENTRY/data_collection/measured_data. This - should be the part of the data set which provides the most suitable - representation of the data. - - - - Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) - - - diff --git a/contributed_definitions/nyaml/NXopt.yaml b/contributed_definitions/nyaml/NXopt.yaml index 777076ff78..8ba2483769 100644 --- a/contributed_definitions/nyaml/NXopt.yaml +++ b/contributed_definitions/nyaml/NXopt.yaml @@ -1,15 +1,19 @@ category: application doc: | - An application definition for optical spectroscopy experiments. + A general application definition of optical spectroscopy elements, which may + be used as a template to derive specialized optical spectroscopy experiments. + + Possible specializations are ellipsometry, Raman spectroscopy, photoluminescence, + reflectivity/transmission spectroscopy. + + A general optical experiment consists of (i) a light/photon source, (ii) a sample, + (iii) a detector. symbols: doc: | Variables used throughout the document, e.g. dimensions or parameters. N_spectrum: | Length of the spectrum array (e.g. wavelength or energy) of the measured data. - N_sensors: | - Number of sensors used to measure parameters that influence the sample, - such as temperature or pressure. N_measurements: | Number of measurements (1st dimension of measured_data array). This is equal to the number of parameters scanned. For example, if the experiment @@ -20,30 +24,13 @@ symbols: sample. N_incident_angles: | Number of angles of incidence of the incident beam. - N_observables: | - Number of observables that are saved in a measurement. e.g. one for - intensity, reflectivity or transmittance, two for Psi and Delta etc. This - is equal to the second dimension of the data array 'measured_data' and the - number of column names. - -# 05/2023 -# Draft of a NeXus application definition which serves as a template for various -# optical spectroscopy experiments -# To do: -# [ ] Check base classes (NXbeam_path + base classes used by it) -# [ ] Harmonize NXopt and NXellipsometry -# [ ] Fix dimensions and ranks +# 04/2024 +# Extension of the Draft Version (05/2023) of a NeXus application definition which +# serves as a template for various optical spectroscopy experiments type: group NXopt(NXobject): (NXentry): - doc: | - An application definition template for optical spectroscopy experiments. - - A general optical experiment consists of a light or excitation source, a - beam path, a sample + its stage + its environment, and a detection unit. - Examples are reflection or transmission measurements, photoluminescence, - Raman spectroscopy, ellipsometry etc. definition: doc: | An application definition describing a general optical experiment. @@ -56,348 +43,675 @@ NXopt(NXobject): URL where to find further material (documentation, examples) relevant to the application definition. enumeration: [NXopt] - experiment_identifier: + title: + start_time(NX_DATE_TIME): + doc: | + Datetime of the start of the measurement. + Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, + otherwise, the local time zone is assumed per ISO8601. + end_time(NX_DATE_TIME): + exists: recommended + doc: | + Datetime of the end of the measurement. + Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, + otherwise the local time zone is assumed per ISO8601. + experiment_identifier(NXidentifier): + exists: recommended doc: | A (globally persistent) unique identifier of the experiment. - (i) The identifier is usually defined by the facility or principle - investigator. + (i) The identifier is usually defined by the facility, laboratory or + principal investigator. (ii) The identifier enables to link experiments to e.g. proposals. + service(NX_CHAR): + identifier(NX_CHAR): + is_persistent(NX_BOOLEAN): experiment_description: exists: optional doc: | An optional free-text description of the experiment. - However, details of the experiment should be defined in the specific - fields of this application definition rather than in this experiment - description. + Users are strongly advised to parameterize the description of their experiment + by using respective groups and fields and base classes instead of writing prose + into this field. + + The reason is that such a free-text field is difficult to machine-interpret. + The motivation behind keeping this field for now is to learn how far the + current base classes need extension based on user feedback. experiment_type: doc: | Specify the type of the optical experiment. - start_time(NX_DATE_TIME): + + Chose other if non of these methods are suitable. You may specify + fundamental characteristics or properties in the experimental sub-type. + enumeration: [ellipsometry, Raman spectroscopy, photoluminescence, transmission spectroscopy, reflection spectroscopy, other] + experiment_sub_type: + doc: | + Specify a special property or characteristic of the experiment, which specifies + the generic experiment type. + enumeration: [time resolved, imaging, pump-probe, other] + # Replace maybe sub_type with exp_technique? + #experimental technique --> pump-probe, parameters seperated (i.e. time, space)? + # The above listed things are related to beam properties? This is different + # compared to temperature or pressure. Is this a useful distinction? + experiment_type_other: doc: | - Start time of the experiment. UTC offset should be specified. + If "other" was selected in "experiment_type", specify the experiment here + with a free text name, which is knwon in the respective community of interest. (NXuser): + exists: [min, 0, max, infty] doc: | - Contact information of at least the user of the instrument or the - investigator who performed this experiment. - Adding multiple users, if relevant, is recommended. + Contact information and eventually details of at persons who + performed the measurements. This can be for example the principal + investigator or student. + It is recommended to add multiple users if relevant. + + Due to data privacy concerns, there is no minimum requirement. name(NX_CHAR): + exists: recommended doc: | - Name of the user. + Given (first) name and surname of the user. affiliation(NX_CHAR): - exists: recommended + exists: optional doc: | - Name of the affiliation of the user at the point in time when the - experiment was performed. + Name of the affiliation of the user at the point in time + when the experiment was performed. address(NX_CHAR): - exists: recommended + exists: optional doc: | - Street address of the user's affiliation. + Postal address of the user's affiliation. email(NX_CHAR): + exists: optional doc: | - Email address of the user. + Email address of the user at the point in time when the experiment + was performed. Writing the most permanently used email is recommended. orcid(NX_CHAR): exists: recommended doc: | Author ID defined by https://orcid.org/. telephone_number(NX_CHAR): + exists: optional + doc: | + (Business) (tele)phone number of the user at the point + in time when the experiment was performed. + role(NX_CHAR): + exists: optional + doc: | + Which role does the user have in the place and at the point + in time when the experiment was performed? Technician operating + the setup, student, PhD-student, postdoc, principle investigator, or guest + are common examples. + identifier(NXidentifier): exists: recommended doc: | - Telephone number of the user. + Service as another mean of identification of a user other than by its name. + Examples could be an ORCID or social media account of the user. + service(NX_CHAR): + identifier(NX_CHAR): + is_persistent(NX_BOOLEAN): (NXinstrument): doc: | - Properties of the experimental setup. This includes general information - about the instrument (such as model, company etc.), information about - the calibration of the instrument, elements of the beam path including - the excitation or light source and the detector unit, the sample stage - (plus the sample environment, which also includes sensors used to - monitor external conditions) and elements of the beam path. + Devices or elements of the optical spectroscopy setup described with its + properties and general information. - Meta data describing the sample should be specified in ENTRY/SAMPLE - outside of ENTRY/INSTRUMENT. - model: + This includes for example: + - The beam device's or instrument's model, company, serial number, construction year, etc. + - Used software or code + - Experiment descriptive parameters as reference frames, resolution, calibration + - Photon beams with their respective properties such as angles and polarization + - Various optical beam path devices, which interact, manipulate or measure optical beams + - Characteristics of the medium surrounding the sample + - "Beam devices" for a beam path description + - Stages(NXmanipulator) + - Sensors and actuators to control or measure sample or beam properties + device_information(NXfabrication): doc: | - The name of the instrument. - \@version: + General device information of the optical spectroscopy setup, if + suitable (e.g. for a tabletop spectrometer or other non-custom build setups). + For custom build setups, this may be limited to the construction year. + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + construction_year(NX_DATE_TIME): + exists: recommended doc: | - The used version of the hardware if available. If not a commercial - instrument use date of completion of the hardware. - company: + Datetime of setup's initial construction. This refers to the date of + first measurement after new construction or relocation of the setup. + Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, + otherwise the local time zone is assumed per ISO8601. + software_TYPE(NXprogram): + exists: recommended + program: + doc: | + Commercial or otherwise defined given name of the program that was + used to control any parts of the optical spectroscopy setup. + The uppercase TYPE should be replaced by a specification name, i.e. + "software_detector" or "software_stage" to specify the respective + program or software components. + \@version: + doc: | + Either version with build number, commit hash, or description of a + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + \@url: + exists: optional + doc: | + Description of the software by persistent resource, where the program, + code, script etc. can be found. + # general properties and reference frames + reference_frames(NXcoordinate_system_set): + # This should be extended later and hopefully replace angle_reference_frame + # and sample_normal_direction. + # Required reference frames: + # Sample normal, beam_z_axis, sample_stage exists: optional doc: | - Name of the company which build the instrument. - construction_year(NX_DATE_TIME): + Description of one or more coordinate systems that are specific to the + experiment. + angle_reference_frame: + doc: | + Defines the reference frame which is used to describe the sample orientation + with respect to the beam directions. + + A beam centered description is the default and uses 4 angles(similar to XRD): + - Omega (angle between sample surface and incident beam) + - 2Theta (angle between the transmitted beam and the detection beam) + - Chi (sample tilt angle, angle between plane#1 and the surface normal, + plane#1 = spanned by incidence beam and detection + and detection. If Chi=0°, then plane#1 is the plane of + incidence in reflection setups) + - Phi (inplane rotation of sample, rotation axis is the samples + surface normal) + + + A sample normal centered description is as well possible(similar to XX): + - angle of incidence (angle between incident beam and sample surface) + - angle of detection (angle between detection beam and sample surface) + - angle of incident and detection beam (angle between the incident and scattering beam) + - angle of in-plane sample rotation (direction along the sample's surface normal) + + # For the sample centered approach, it has to be avoided, that the detection beam, + # incident beam or surface normal beam are parallel to each other + # (Is this a problem for Raman backscattering?) + # For beam centered approach (as done for beamlines), the grativation and beam direction are used to define + # the coordinate system. As beamlines are usually built flat - there is no case + # in which these two vectors can be parallel to each other + # This is different with the surface normal. Aside of the surface normal, + # at least one further additional natural direction is required. + # This could be the magnetic/geographic north pole + # magnetic north pole: easy to determine, but time depenent (long term) + # geographic north pole: harder to determine? (What about GPS?), but constant with time + + enumeration: [beam centered, sample normal centered] + wavelength_resolution(NXresolution): exists: optional doc: | - ISO8601 date when the instrument was constructed. - UTC offset should be specified. - software(NXprocess): - program: + The overall resolution of the optical instrument. + physical_quantity: + enumeration: [wavelength] + type: + exists: recommended + resolution(NX_FLOAT): + unit: NX_WAVELENGTH doc: | - Commercial or otherwise defined given name of the program that was - used to measure the data, i.e. the software used to start and - record the measured data and/or metadata. - If home written, one can provide the actual steps in the NOTE - subfield here. - version: - doc: | - Either version with build number, commit hash, or description of a - (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner. - \@url: - exists: optional - doc: | - Website of the software. - firmware(NXprogram): + Minimum distinguishable wavelength separation of peaks in spectra. + instrument_calibration_DEVICE(NXsubentry): exists: recommended doc: | - Commercial or otherwise defined name of the firmware that was used - for the measurement - if available. - \@version: + Pre-calibration of an arbitrary device of the instrumental setup, which + has the name DEVICE. You can specify here at which point + device_path: + exists: recommended doc: | - Version and build number or commit hash of the software source code. - \@url: + Path to the device, which was calibrated. + Example: entry/instrument/DEVICE + calibration_method: + exists: optional + doc: + Describe here the approach or method, used to perform the calibration, + by a free text. + calibration_accuracy(NXdata): exists: optional doc: | - Website of the software. - calibration_status(NX_CHAR): - doc: | - Was a calibration performed? If yes, when was it done? If the - calibration time is provided, it should be specified in - ENTRY/INSTRUMENT/calibration/calibration_time. - enumeration: [calibration time provided, no calibration, within 1 hour, within 1 day, within 1 week] - calibration(NXsubentry): - exists: recommended - doc: | - The calibration data and metadata should be described in a separate NeXus file - with the link provided in 'calibration_link'. + Provide data about the determined accuracy of the device, this may + may be a single value or a dataset like wavelength error vs. wavelength etc. + calibration_status(NX_CHAR): + exists: recommended + doc: | + Was a calibration performed? If yes, when was it done? If the + calibration time is provided, it should be specified in + ENTRY/INSTRUMENT/calibration/calibration_time. + enumeration: [calibration time provided, no calibration, within 1 hour, within 1 day, within 1 week] calibration_time(NX_DATE_TIME): exists: optional doc: | If calibtration status is 'calibration time provided', specify the ISO8601 date when calibration was last performed before this measurement. UTC offset should be specified. - calibration_data_link: + calibration_data_link(NXidentifier): + exists: recommended doc: | Link to the NeXus file containing the calibration data and metadata. - (NXbeam_path): + # Discussion + # ########## + # The basic idea was: You have always an incident source and a detector. + # Therefore, you always have an incident beam and a "detection beam". + # These beams can be assigned clear incident and detection angles. + # + # This information is always of relevance for ellipsometry, + # but for Raman experiments, the state of polarization is as well of relevance + # Additonally, this is limited for incident, detection and sample normal + # to be in one plane. This does not have to be the case for Raman scattering + # experiments. Therefore, this is not general enough and may be moved to + # NXellipsometry. + # This information may be as well stored in an incident and detection beam + + # beam properties + beam_TYPE(NXbeam): + exists: [min, 0, max, infty] doc: | - Describes an arrangement of optical or other elements, e.g. the beam - path between the light source and the sample, or between the sample - and the detector unit (including the sources and detectors - themselves). - - If a beam splitter (i.e. a device that splits the incoming beam into - two or more beams) is part of the beam path, two or more NXbeam_path - fields may be needed to fully describe the beam paths and the correct - sequence of the beam path elements. - Use as many beam paths as needed to describe the setup. + Beam characteristics between two beam_devices. + + It is recommended, to at least define one incident and one detection beam. + If this beam is directly connected to an source, chose here the same + name appendix as for the NXsource (e.g. TYPE=532nm) + incident_wavelength(NX_FLOAT): + unit: NX_WAVELENGTH + incident_wavelength_spread(NX_NUMBER): + exists: recommended + unit: NX_WAVELENGTH + incident_polarization(NX_NUMBER): + exists: recommended + unit: NX_ANY + extent(NX_FLOAT): + exists: recommended + associated_source(NX_CHAR): + exists: recommended + doc: | + The path to a the source, which emitted this beam. + Should be named with the same appendix as the source, e.g., + for TYPE=532nmlaser, there should as well be + a NXsource named "source_532nmlaser" aside of this Beam + instance named "beam_532nmlaser" + + Example: /entry/instrument/source_532nmlaser + # The two polarization descriptions may be completely replaced by + # incident_polarization + beam_polarization_type: + exists: optional + enumeration: [linear, circular, ellipically, unpolarized] + linear_beam_sample_polarization(NX_NUMBER): + exists: optional + doc: | + Description of the light polarization of the respective beam and the beam-sample-normal. + This is only well defined, if the beam direclty hits the sample (either indicent + beam or detection beam) and if the samples needs to have a clearly + defined sample surface. The beam-sample-normal plane is spanned by + the beam and the samples surface normal. + + If the electric field in in this plane, this value is 0° (P-pol) + If the electric field is perpendicular to this plane, this value is 90° (S-pol) + If the surface normal is parallel to the beam direction, then only the + relation between different polarizations has to be consistent + (i.e. parallel polarized 0° and cross polarized 90°) + unit: NX_ANGLE + # Discussion with florian: + # The user wants to use simple parameters, which they are used to. + # Though, via NXtransformations in principle maximum flexibility can be provided, + # even for unusual and complex experimental setups. + # The solution from mpes was: simple "front end" by only stating one angle + # with the "backend" to be customizable via NXtransformations. + # + # fundamental orientation of incident and detection beam angle_of_incidence(NX_NUMBER): + # relation beam directions (incident and detection) with sample orientation + # these angles are quite simple. They might be extended similar to + # NXmpes_liquid with leaf_normal to allow arbitrary description. + # this might require a different reference frame. + exists: optional unit: NX_ANGLE doc: | Angle(s) of the incident beam vs. the normal of the bottom reflective - (substrate) surface in the sample. + (substrate) surface in the sample. These two directions span the plane + of incidence. dimensions: rank: 1 dim: [[1, N_incident_angles]] \@units: - detection_angle(NX_NUMBER): + angle_of_detection(NX_NUMBER): exists: optional unit: NX_ANGLE doc: | Detection angle(s) of the beam reflected or scattered off the sample vs. the normal of the bottom reflective (substrate) surface in the sample if not equal to the angle(s) of incidence. + These two directions span the plane of detection. dimensions: rank: 1 dim: [[1, N_detection_angles]] - sample_stage(NXsubentry): + angle_of_incident_and_detection_beam(NX_NUMBER): + exists: optional + unit: NX_ANGLE doc: | - Sample stage, holding the sample at a specific position in X,Y,Z - (Cartesian) coordinate system and at an orientation defined - by three Euler angles (alpha, beta, gamma). - stage_type: - doc: | - Specify the type of the sample stage. - enumeration: [manual stage, scanning stage, liquid stage, gas cell, cryostat] - alternative: + Angle between the incident and detection beam. + If angle_of_detection + angle_of_incidence = angle_of_incident_and_detection_beam, + then the setup is a reflection setup. + If angle_of_detection + angle_of_incidence != angle_of_incident_and_detection_beam + then the setup may be a light scattering setup. + (i.e. 90° + 90° != 90°, i.e. incident and detection beam in the sample surface, but + the angle source-sample-detector is 90°) + + dimensions: + rank: 1 + dim: [[1, XX]] + \@units: + angle_of_in_plane_sample_rotation(NX_NUMBER): + exists: optional + unit: NX_ANGLE + doc: | + Angle of the inplane orientation of the sample. This might be an arbitrary, + angle without specific relation to the sample symmetry, + of the angle to a specific sample property (i.e. crystallographic axis or sample + shape such as wafer flat) + dimensions: + rank: 1 + dim: [[1, XX]] + lateral_focal_point_offset(NX_NUMBER): + exists: optional + unit: NX_LENGTH + doc: | + Specify if there is a lateral offset on the sample surface, between the focal + points of the incident beam and the detection beam. + # beam path elements + source_TYPE(NXsource): + exists: [min, 1, max, infty] + type: + exists: recommended + enumeration: [laser, dye-laser, broadband tunable light source, X-ray Source, other] + type_other: exists: optional doc: | - If there is no motorized stage, we should at least qualify where - the beam hits the sample and in what direction the sample stands - in a free-text description, e.g. 'center of sample, long edge - parallel to the plane of incidence'. - environment_conditions(NXenvironment): + Specification of type, may also go to name. + name: + exists: recommended + source_polarization: + exists: recommended doc: | - Specify external parameters that have influenced the sample, such - as the surrounding medium, and varied parameters e.g. temperature, - pressure, pH value, optical excitation etc. - medium: - doc: | - Describe what was the medium above or around the sample. The - common model is built up from the substrate to the medium on the - other side. Both boundaries are assumed infinite in the model. - Here, define the name of the medium (e.g. water, air, UHV, etc.). - medium_refractive_indices(NX_FLOAT): - exists: optional - unit: NX_UNITLESS - doc: | - Array of pairs of complex refractive indices n + ik of the medium - for every measured spectral point/wavelength/energy. - Only necessary if the measurement was performed not in air, or - something very well known, e.g. high purity water. - dimensions: - rank: 2 - dim: [[1, 2], [2, N_spectrum]] - PARAMETER(NXsensor): - exists: optional - doc: | - A sensor used to monitor an external condition influencing the - sample, such as temperature or pressure. It is suggested to - replace 'PARAMETER' by the type of the varied parameter defined - in 'parameter_type'. - The measured parameter values should be provided in 'values'. - For each parameter, a 'PARAMETER(NXsensor)' field needs to exist. - In other words, there are N_sensors 'PARAMETER(NXsensor)' fields. - parameter_type: - doc: | - Indicates which parameter was changed. Its definition must exist - below. The specified variable has to be N_measurements long, - providing the parameters for each data set. If you vary more than - one parameter simultaneously. - If the measured parameter is not contained in the list `other` - should be specified and the `parameter_type_name` should be provided. - enumeration: [conductivity, detection_angle, electric_field, flow, incident_angle, magnetic_field, optical_excitation, pH, pressure, resistance, shear, stage_positions, strain, stress, surface_pressure, temperature, voltage, other] - parameter_type_name: - exists: optional - doc: | - If the parameter_type is `other` a name should be specified here. - number_of_parameters(NX_POSINT): - unit: NX_UNITLESS - doc: | - Number of different parameter values at which the measurement - was performed. For example, if the measurement was performed at - temperatures of 4, 77 and 300 K, then number_of_parameters = 3. - values(NX_FLOAT): - unit: NX_ANY - doc: | - Vector containing the values of the varied parameter. Its - length is equal to N_measurements. The order of the values - should be as follows: - - * Order the sensors according to number_of_parameters starting - with the lowest number. If number_of_parameters is equal for - two sensors order them alphabetically (sensor/parameter name). - * The first sensor's j parameters should be ordered in the - following way. The first N_measurements/number_of_parameters - entries of the vector contain the first parameter (a1), the - second N_measurements/number_of_parameters contain the second - parameter (a2) etc., so the vector looks like: - [ - a1,a1,...,a1, - a2,a2,...,a2, - ... - aj,aj,...aj - ] - * The kth sensor's m parameters should be ordered in the - following way: - [ - p1,...p1,p2,...,p2,...pm,...,pm, - p1,...p1,p2,...,p2,...pm,...,pm, - ... - p1,...p1,p2,...,p2,...pm,...,pm - ] - * The last sensor's n parameters should be ordered in the - following way: - [ - z1,z2,...,zn, - z1,z2,...,zn, - ... - z1,z2,...,zn] - - For example, if the experiment was performed at three different - temperatures (T1, T2, T3), two different pressures (p1, p2) and - two different angles of incidence (a1, a2), then - N_measurements = 12 and the order of the values for the various - parameter vectors is: - - * angle_of_incidence: [a1,a1,a1,a1,a1,a1,a2,a2,a2,a2,a2,a2] - * pressure: [p1,p1,p1,p2,p2,p2,p1,p1,p1,p2,p2,p2] - * temperature: [T1,T2,T3,T1,T2,T3,T1,T2,T3,T1,T2,T3] - dimensions: - rank: 1 - dim: [[1, N_measurements]] - WINDOW(NXaperture): - exists: optional + The type of light polarization produced by the source. + enumeration: [linear, unpolarized, circular, elliptically, other] + device_information(NXfabrication): doc: | - For environmental measurements, the environment (liquid, vapor - etc.) is enclosed in a cell, which has windows both in the - direction of the source (entry window) and the detector (exit - window) (looking from the sample). In case that the entry and exit - windows are not the same type and do not have the same properties, - use a second 'WINDOW(MXaperture)' field. - - The windows also add a phase shift to the light altering the - measured signal. This shift has to be corrected based on measuring - a known sample (reference sample) or the actual sample of interest - in the environmental cell. State if a window correction has been - performed in 'window_effects_corrected'. Reference data should be - considered as a separate experiment, and a link to the NeXus file - should be added in reference_data_link in measured_data. + Details about the device information. + associated_beam(NX_CHAR): + doc: | + The path to a beam emitted by this source. + Should be named with the same appendix, e.g., + for TYPE=532nmlaser, there should as well be + a NXbeam named "beam_532nmlaser" aside of this source + instance named "source_532nmlaser" - The window is considered to be a part of the sample stage but also - beam path. Hence, its position within the beam path should be - defined by the 'depends_on' field. - depends_on: + Example: /entry/instrument/beam_532nmlaser + device_characteristics(NXdata): + detector_TYPE(NXdetector): + exists: [min, 1, max, infty] + detector_channel_type: + exists: recommended + enumeration: [single-channel, multichannel] + detector_type: + exists: recommended + doc: | + Description of the detector type. + enumeration: [CCD, Photomultiplier, Photodiode, Avalanche-Photodiode, Bolometer, Golay Detectors, Pyroelectric Detector] + device_characteristics(NXdata): + device_information(NXfabrication): + exists: recommended + vendor: exists: recommended + model: + exists: recommended + identifier: + exists: recommended + raw_data(NXdata): + exists: recommended + doc: | + Contains the raw data collected by the detector before calibration. + The data which is considered raw might change from experiment to experiment + due to hardware pre-processing of the data. + This field ideally collects the data with the lowest level of processing + possible. + + # Define a similar convention for NXopt? Or only for NXraman, NXellipsometry and NXphotoluminescence? + # Fields should be named according to new following convention: + # + # - **pixel_x**: Detector pixel in x direction. + # - **pixel_y**: Detector pixel in y direction. + # - **energy**: (Un)calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). + # - **kx**: (Un)calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). + # - **ky**: (Un)calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). + # - **kz**: (Un)calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). + # - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). + # Unit category: NX_ANGLE + # - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) + # Unit category: NX_ANGLE + # - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) + # Unit category: NX_LENGTH + # - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) + # Unit category: NX_LENGTH + # - **delay**: Calibrated delay time. Unit category: NX_TIME (s). + # - **polarization_angle**: Linear polarization angle of the incoming or + # outgoing beam. + # Unit category: NX_ANGLE (° or rad) + # - **ellipticity**: Ellipticity of the incoming or outgoing beam. + # Unit category: NX_ANGLE (° or rad) + # - **time_of_flight**: Total time of flight. Unit category: NX_TIME_OF_FLIGHT + # - **time_of_flight_adc**: Time-of-flight values, analog-to-digital converted. + # - **external_AXIS**: Describes an axis which is coming from outside the detectors scope. + \@signal: + enumeration: [raw] + raw(NX_NUMBER): doc: | - Specify the position of the window in the beam path by pointing - to the preceding element in the sequence of beam path elements. - window_effects_corrected(NX_BOOLEAN): - doc: | - Was a window correction performed? If 'True' describe the window - correction procedure in 'window_correction/procedure'. - window_correction(NXprocess): - exists: optional - doc: | - Was a window correction performed? If 'True' describe the - window correction procedure in '' - procedure: - doc: | - Describe when (before or after the main measurement + time - stamp in 'date') and how the window effects have been - corrected, i.e. either mathematically or by performing a - reference measurement. In the latter case, provide the link to - to the reference data in 'reference_data_link'. - reference_data_link: - exists: optional - doc: | - Link to the NeXus file which describes the reference data if a - reference measurement for window correction was performed. - Ideally, the reference measurement was performed on a reference - sample and on the same sample, and using the same conditions as - for the actual measurement with and without windows. It should - have been conducted as close in time to the actual measurement - as possible. - material(NX_CHAR): + Raw data before calibration. + (NXmonochromator): + exists: optional + device_characteristics(NXdata): + (NXlens_opt): + exists: optional + device_characteristics(NXdata): + (NXwaveplate): + exists: optional + device_characteristics(NXdata): + WINDOW(NXaperture): + exists: optional + doc: | + For environmental measurements, the environment (liquid, vapor + etc.) is enclosed in a cell, which has windows both in the + direction of the source (entry window) and the detector (exit + window) (looking from the sample). In case that the entry and exit + windows are not the same type and do not have the same properties, + use a second 'WINDOW(MXaperture)' field. + + The windows also add a phase shift to the light altering the + measured signal. This shift has to be corrected based on measuring + a known sample (reference sample) or the actual sample of interest + in the environmental cell. State if a window correction has been + performed in 'window_effects_corrected'. Reference data should be + considered as a separate experiment, and a link to the NeXus file + should be added in reference_data_link in measured_data. + + The window is considered to be a part of the sample stage but also + beam path. Hence, its position within the beam path should be + defined by the 'depends_on' field. + window_effects_corrected(NX_BOOLEAN): + doc: | + Was a window correction performed? If 'True' describe the window + correction procedure in 'window_correction/procedure'. + window_correction(NXprocess): + exists: optional + doc: | + Was a window correction performed? If 'True' describe the + window correction procedure in '' + procedure: doc: | - The material of the window. - enumeration: [quartz, diamond, calcium fluoride, zinc selenide, thallium bromoiodide, alkali halide compound, Mylar, other] - other_material(NX_CHAR): + Describe when (before or after the main measurement + time + stamp in 'date') and how the window effects have been + corrected, i.e. either mathematically or by performing a + reference measurement. In the latter case, provide the link to + to the reference data in 'reference_data_link'. + reference_data_link: exists: optional doc: | - If you specified 'other' as material, decsribe here what it is. - thickness(NX_FLOAT): - unit: NX_LENGTH - doc: | - Thickness of the window. - orientation_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - Angle of the window normal (outer) vs. the substrate normal - (similar to the angle of incidence). + Link to the NeXus file which describes the reference data if a + reference measurement for window correction was performed. + Ideally, the reference measurement was performed on a reference + sample and on the same sample, and using the same conditions as + for the actual measurement with and without windows. It should + have been conducted as close in time to the actual measurement + as possible. + material(NX_CHAR): + doc: | + The material of the window. + enumeration: [quartz, diamond, calcium fluoride, zinc selenide, thallium bromoiodide, alkali halide compound, Mylar, other] + material_other(NX_CHAR): + exists: optional + doc: | + If you specified 'other' as material, decsribe here what it is. + thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + Thickness of the window. + orientation_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Angle of the window normal (outer) vs. the substrate normal + (similar to the angle of incidence). + sample_medium_refractive_indices(NX_FLOAT): + exists: optional + unit: NX_UNITLESS + doc: | + Array of pairs of complex refractive indices n + ik of the medium + for every measured spectral point/wavelength/energy. + Only necessary if the measurement was performed not in air, or + something very well known, e.g. high purity water. + dimensions: + rank: 2 + dim: [[1, 2], [2, N_spectrum]] + # beam devices for beam path description + (NXbeam_device): + exists: [min, 0, max, infty] + doc: | + Describes the order of respective beam devices in the optical beam + path. + + Everything object which interacts or modifies optical beam properties, + may be an beam device, e.g. Filter, Window, Beamsplitter, Photon Source, + Detector, etc, + + It is intended, to include this functionality later to "older" beam + components, such as NXsource, NXdetector, NXlens, etc. + Until this is possbible, auxillary beam devices have to be created, + for each "older" beam component instead, to allow a beam path description. + To link the auxillary beam device to the real device properties, the + attribute \@device should be used. + \@device: + exists: recommended + doc: | + Reference to beam device, which is described by a NeXus concept + (e.g. for NXsource, entry/instrument/source_TYPE). + previous_device: + exists: recommended + doc: | + Reference to the previous beam device, from which the photon beam came + to reach this beam device. A photon source is related as origin by ".". + This enables a logical order description of the optical setup. + # non-beam path elements + sample_stage(NXmanipulator): + exists: optional + doc: | + Sample stage (or manipulator) for positioning of the sample. This should + only contain the spatial orientation of movement. + stage_type: + exists: optional + doc: | + Specify the type of the sample stage. + enumeration: [manual stage, scanning stage, liquid stage, gas cell, cryostat, heater, other] + stage_type_other: + exists: optional + doc: | + If "other" was chosen in stage_type, enter here a free text description + of the stage type. + reference_frame: + exists: optional + doc: | + This is a placeholder, to describe the relation between the samples + coordinate system, laboratory coordinate system and the stage coordinate + system. Up to now, use the "beam_sample_relation" to give supporting + information. + beam_sample_relation: + exists: optional + doc: | + Description of relation of the beam with the sample. How dit the + sample hit the beam, e.g. 'center of sample, long edge parallel + to the plane of incidence'. + device_information(NXfabrication): + temperature_sensor(NXsensor): + exists: recommended + name: + exists: recommended + measurement: + enumeration: [temperature] + type: + exists: optional + value(NX_FLOAT): + device_information(NXfabrication): + temp_control_TYPE(NXactuator): + doc: + Type of control for the sample temperature. Replace TYPE by + "cryostat" or "heater" to specify it. + exists: optional + name: + exists: recommended + physical_quantity: + enumeration: [temperature] + cryo_or_heater: + exists: recommended + enumeration: [cryostat, heater] + type: + exists: optional + doc: | + Hardware used for actuation, i.e. laser, gas lamp, filament, resistive + (NXpid): + setpoint(NX_FLOAT): + exists: recommended + device_information(NXfabrication): + PARAMETER_SENSOR(NXsensor): + exists: recommended + name: + exists: recommended + measurement: + type: + exists: optional + value(NX_FLOAT): + device_information(NXfabrication): + PARAMETER_ACTUATOR(NXactuator): + doc: + Control of arbitrary parameter - compare to temperature above. + exists: optional + name: + exists: recommended + physical_quantity: + type: + exists: optional + doc: | + Hardware used for actuation + (NXpid): + setpoint(NX_FLOAT): + exists: recommended + device_information(NXfabrication): (NXsample): doc: | Properties of the sample, such as sample type, layer structure, @@ -406,18 +720,27 @@ NXopt(NXobject): described in ENTRY/INSTRUMENT/sample_stage. sample_name: doc: | - Descriptive name of the sample - sample_type: + Name of the sample, which is uaually pleases human readability. + This may be, but does not have to be identical to the sample_id. + sample_id: + exists: recommended doc: | - Specify the type of sample, e.g. thin film, single crystal etc. - enumeration: [thin film, single crystal, poly crystal, single layer, multi layer] - layer_structure: + Uniquely identifying name of the sample. + physical_form: + exists: recommended doc: | - Qualitative description of the layer structure for the sample, - starting with the top layer (i.e. the one on the front surface, on - which the light incident), e.g. native oxide/bulk substrate, or - Si/native oxide/thermal oxide/polymer/peptide. + State the form of the sample, examples are: + thin film, single crystal, poly crystal, amorphous, single layer, + multi layer, liquid, gas, pellet, powder. + description: + exists: optional + doc: | + Free text description of the sample. + situation: + exists: recommended + enumeration: [air, vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere, sealed can, water, other] chemical_formula: + exists: recommended doc: | Chemical formula of the sample. Use the Hill system (explained here: https://en.wikipedia.org/wiki/Chemical_formula#Hill_system) to write @@ -427,152 +750,119 @@ NXopt(NXobject): layer (the one on the front surface, on which the light incident). The order must be consistent with layer_structure atom_types: + exists: optional doc: | List of comma-separated elements from the periodic table that are contained in the sample. If the sample substance has multiple components, all elements from each component must be included in 'atom_types'. - sample_history: - doc: | - Ideally, a reference to the location or a unique (globally - persistent) identifier (e.g.) of e.g. another file which gives - as many as possible details of the material, its microstructure, - and its thermo-chemo-mechanical processing/preparation history. - In the case that such a detailed history of the sample is not - available, use this field as a free-text description to specify - details of the sample and its preparation. preparation_date(NX_DATE_TIME): exists: recommended doc: | - ISO8601 date with time zone (UTC offset) specified. - substrate: + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known timestamp when + the measured specimen surface was actively prepared. + history(NXhistory): exists: recommended doc: | - Description of the substrate. - sample_orientation: - exists: optional - doc: | - Specify the sample orientation. - data_collection(NXprocess): - doc: | - Measured data, data errors, and varied parameters. If reference data - were measured they should be considered a separate experiment and a - link to its NeXus file should be added in reference_data_link. - data_identifier(NX_NUMBER): - doc: | - An identifier to correlate data to the experimental conditions, - if several were used in this measurement; typically an index of 0-N. - data_type: - doc: | - Select which type of data was recorded, for example intensity, - reflectivity, transmittance, Psi and Delta etc. - It is possible to have multiple selections. The enumeration list - depends on the type of experiment and may differ for different - application definitions. - enumeration: [intensity, reflectivity, transmittance, Psi/Delta, tan(Psi)/cos(Delta), Mueller matrix, Jones matrix, N/C/S, raw data] - - # This should be a required field, but is set to 'optional' for the moment - NAME_spectrum(NX_FLOAT): - exists: optional - unit: NX_ANY + A set of activities that occurred to the sample prior to/during the experiment. + history_id(NXidentifier): + doc: | + A reference to the location or a unique (globally + persistent) identifier (e.g.) of e.g. another file which gives + as many as possible details of the material, its microstructure, + and its thermo-chemo-mechanical processing/preparation history. + temperature(NXenvironment): + exists: recommended doc: | - Spectral values (e.g. wavelength or energy) used for the measurement. - An array of 1 or more elements. Length defines N_spectrum. Replace - 'SPECTRUM' by the physical quantity that is used, e.g. wavelength. - dimensions: - rank: 1 - dim: [[1, N_spectrum]] - \@units: + Sample temperature (either controlled or just measured). + temperature_sensor(NXsensor): + doc: | + Temperature sensor measuring the sample temperature. + This should be a link to /entry/instrument/manipulator/temperature_sensor. + sample_heater(NXactuator): exists: optional doc: | - If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. - If the unit of the measured data is not covered by NXDL units state - here which unit was used. - measured_data(NX_FLOAT): - unit: NX_ANY - doc: | - Resulting data from the measurement, described by 'data_type'. - - The first dimension is defined by the number of measurements taken, - (N_measurements). The instructions on how to order the values - contained in the parameter vectors given in the doc string of - INSTRUMENT/sample_stage/environment_conditions/PARAMETER/values, - define the N_measurements parameter sets. For example, if the - experiment was performed at three different temperatures - (T1, T2, T3), two different pressures (p1, p2) and two different - angles of incidence (a1, a2), the first measurement was taken at the - parameters {a1,p1,T1}, the second measurement at {a1,p1,T2} etc. - dimensions: - rank: 3 - dim: [[1, N_measurements], [2, N_observables], [3, N_spectrum]] - \@units: + Device to heat the sample. + This should be a link to /entry/instrument/manipulator/sample_heater. + cryostat(NXactuator): exists: optional doc: | - If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. - If the unit of the measured data is not covered by NXDL units state - here which unit was used. - measured_data_errors(NX_FLOAT): + Cryostat for cooling the sample. + This should be a link to /entry/instrument/manipulator/cryostat. + (NXenvironment): exists: optional - unit: NX_ANY doc: | - Specified uncertainties (errors) of the data described by 'data_type' - and provided in 'measured_data'. - dimensions: - rank: 3 - dim: [[1, N_measurements], [2, N_observables], [3, N_spectrum]] - \@units: + Arbirary sample property which may be varied during the experiment + and controlled by a device. Examples are pressure, voltage, magnetic field etc. + Similar to the temperautre description of the sample. + (NXsensor): exists: optional - doc: | - If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. - If the unit of the measured data is not covered by NXDL units state - here which unit was used. - varied_parameter_link: + (NXactuator): + exists: optional + thickness(NX_NUMBER): exists: optional doc: | - List of links to the values of the sensors. Add a link for each - varied parameter (i.e. for each sensor). - dimensions: - rank: 1 - dim: [[1, N_sensors]] - reference_data_link: + (Measured) sample thickness. + + The information is recorded to qualify if the light used was likely + able to shine through the sample. + + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. + unit: NX_LENGTH + thickness_determination: exists: optional doc: | - Link to the NeXus file which describes the reference data if a - reference measurement was performed. Ideally, the reference - measurement was performed using the same conditions as the actual - measurement and should be as close in time to the actual measurement - as possible. - data_software(NXprocess): + If a thickness if given, please specify how this thickness was estimated or determined. + layer_structure: exists: optional - program: - doc: | - Commercial or otherwise defined given name of the program that was - used to generate the result file(s) with measured data and/or - metadata (in most cases, this is the same as INSTRUMENT/software). - If home written, one can provide the actual steps in the NOTE - subfield here. - version: - doc: | - Either version with build number, commit hash, or description of a - (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner. - \@url: - exists: optional - doc: | - Website of the software. - (NXdata): + doc: | + Qualitative description of the layer structure for the sample, + starting with the top layer (i.e. the one on the front surface, on + which the light incident), e.g. native oxide/bulk substrate, or + Si/native oxide/thermal oxide/polymer/peptide. + sample_orientation: exists: optional doc: | - A plot of the multi-dimensional data array provided in - ENTRY/data/measured_data. - \@axes: + Specify the sample orientation, how is its sample normal oriented + relative in the laboratory reference frame, incident beam reference + frame. + substrate: + exists: recommended + doc: | + If the sample is grown or fixed on a substrate, specify this here by + a free text description. + (NXdata): + doc: | + A default view of the data provided in ENTRY/data_collection/measured_data. This + should be the part of the data set which provides the most suitable + representation of the data. + + You may provide multiple instances of NXdata + \@axes: + doc: | + Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) + \@signal: + doc: | + Spectrum, i.e. y-axis of the data (e.g. counts, intensity) + measurement_data_calibration(NXprocess): + wavelength_calibration(NXcalibration): + exists: optional + calibrated_axis(NX_FLOAT): + exists: recommended doc: | - Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) + Location to save the calibrated wavelength data. + # The old "data_collection(NXprocess)" is now replaced by more flexbile + # NXdata. A detailed rework of this has to be done after the NXopt workshop derived_parameters(NXprocess): exists: optional doc: | + >>>This section is transfered from the first NXopt version and might + require a reqwork.<<< Parameters that are derived from the measured data. depolarization(NX_NUMBER): exists: optional @@ -621,14 +911,6 @@ NXopt(NXobject): instructions can be found so that the program can be configured in such a way that result files can be created ideally in a deterministic manner. - plot(NXdata): - doc: | - A default view of the data provided in ENTRY/data_collection/measured_data. This - should be the part of the data set which provides the most suitable - representation of the data. - \@axes: - doc: | - Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ # 7d68d553b6c55f5cdd8fe8d92c325b137c71c875c2bd742f5cf2150df56f4398 From 4ef8770bc60f507669b6d62fac1c5f911cba5a9b Mon Sep 17 00:00:00 2001 From: Florian Dobener Date: Tue, 30 Apr 2024 11:11:36 +0200 Subject: [PATCH 0673/1012] Make attr logging an f-string (#221) * Make attr logging an f-string * Linting * isorting --- dev_tools/utils/nxdl_utils.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dev_tools/utils/nxdl_utils.py b/dev_tools/utils/nxdl_utils.py index 5764e0ae9c..4ecb0700e0 100644 --- a/dev_tools/utils/nxdl_utils.py +++ b/dev_tools/utils/nxdl_utils.py @@ -443,7 +443,7 @@ def get_required_string(nxdl_elem): def write_doc_string(logger, doc, attr): """Simple function that prints a line in the logger if doc exists""" if doc: - logger.debug("@%s [NX_CHAR]", attr) + logger.debug(f"@{attr} [NX_CHAR]") return logger, doc, attr From 08f4529d914c60874624f67084b87cb414c0a755 Mon Sep 17 00:00:00 2001 From: Ron Hildebrandt Date: Tue, 30 Apr 2024 13:30:51 +0200 Subject: [PATCH 0674/1012] extend NXhistory and NXfabrication --- contributed_definitions/NXfabrication.nxdl.xml | 9 +++++++++ contributed_definitions/NXhistory.nxdl.xml | 7 +++++++ contributed_definitions/nyaml/NXfabrication.yaml | 8 ++++++++ contributed_definitions/nyaml/NXhistory.yaml | 6 ++++++ 4 files changed, 30 insertions(+) diff --git a/contributed_definitions/NXfabrication.nxdl.xml b/contributed_definitions/NXfabrication.nxdl.xml index dd1f7f5dce..2db98c41cf 100644 --- a/contributed_definitions/NXfabrication.nxdl.xml +++ b/contributed_definitions/NXfabrication.nxdl.xml @@ -41,6 +41,15 @@ a serial number or hash identifier of the component. + + + Datetime of components initial construction. This refers to the date of + first measurement after new construction or to the relocation date, + if it describes a multicomponent/custom-build setup. + Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, + otherwise the local time zone is assumed per ISO8601. + + Free-text list with eventually multiple terms of diff --git a/contributed_definitions/NXhistory.nxdl.xml b/contributed_definitions/NXhistory.nxdl.xml index 4aafaf7693..9dfa25d722 100644 --- a/contributed_definitions/NXhistory.nxdl.xml +++ b/contributed_definitions/NXhistory.nxdl.xml @@ -52,6 +52,13 @@ definition: ["NXactivity"]--> experiment. + + + An ID or reference to the location or a unique (globally + persistent) identifier of e.g. another file which gives + as many as possible details of the history event. + + diff --git a/contributed_definitions/nyaml/NXfabrication.yaml b/contributed_definitions/nyaml/NXfabrication.yaml index 387e4a4649..8e785f7537 100644 --- a/contributed_definitions/nyaml/NXfabrication.yaml +++ b/contributed_definitions/nyaml/NXfabrication.yaml @@ -13,7 +13,15 @@ NXfabrication(NXobject): doc: | Ideally, (globally) unique persistent identifier, i.e. a serial number or hash identifier of the component. + construction_year(NX_DATE_TIME): + doc: | + Datetime of components initial construction. This refers to the date of + first measurement after new construction or to the relocation date, + if it describes a multicomponent/custom-build setup. + Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, + otherwise the local time zone is assumed per ISO8601. capability(NX_CHAR): doc: | Free-text list with eventually multiple terms of functionalities which the component offers. + diff --git a/contributed_definitions/nyaml/NXhistory.yaml b/contributed_definitions/nyaml/NXhistory.yaml index 815ff35dad..80185ebf47 100644 --- a/contributed_definitions/nyaml/NXhistory.yaml +++ b/contributed_definitions/nyaml/NXhistory.yaml @@ -26,6 +26,12 @@ NXhistory(NXobject): Any chemical process that was performed on the physical entity prior or during the experiment. + (NXidentifier): + doc: | + An ID or reference to the location or a unique (globally + persistent) identifier of e.g. another file which gives + as many as possible details of the history event. + # There should be more activities here, like measurement. notes(NXnote): doc: | From 38744b0efb30499005841add781652b04f17354e Mon Sep 17 00:00:00 2001 From: Ron Hildebrandt Date: Tue, 30 Apr 2024 13:32:01 +0200 Subject: [PATCH 0675/1012] Adjust NXopt with suggestions from Lukas and add NXopt-ToDo --- contributed_definitions/NXopt.nxdl.xml | 460 +++++++++--------- contributed_definitions/NXopt_window.nxdl.xml | 117 +++++ contributed_definitions/nyaml/NXopt.yaml | 369 +++++++------- .../nyaml/NXopt_window.yaml | 69 +++ 4 files changed, 575 insertions(+), 440 deletions(-) create mode 100644 contributed_definitions/NXopt_window.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXopt_window.yaml diff --git a/contributed_definitions/NXopt.nxdl.xml b/contributed_definitions/NXopt.nxdl.xml index 563da7b63f..84b1be1259 100644 --- a/contributed_definitions/NXopt.nxdl.xml +++ b/contributed_definitions/NXopt.nxdl.xml @@ -24,7 +24,19 @@ +serves as a template for various optical spectroscopy experiments + +TODO: +- Merge reference_frames with angle_reference_frame +- Rework instrument_calibration_DEVICE - use NXcalibration? +- Beam polarizations: Own Polarization concept with angle or from NXbeam via beam coordinates? (solve reference frame problem first) +- Describe angle_of_detection by NXtransformations +- remove NXmonchromator? as it is already in NXinstrument +- Add NXlens_opt and NXwaveplate to NXinstrument? +- Make sample stage_stage(NXmanipulator)/reference_frame via NXtransformations +- Add properties from NXlens_opt from NXopt to NXlens_opt base class +- Make polfilter_TYPE(NXbeam_device) own base class -\-> rework NXpolarizer_opt. and add them to NXinstrument. +- Make spectralfilter_TYPE(NXbeam_device) own base class -\-> extend NXfilter? and add them to NXinstrument.--> @@ -109,9 +121,9 @@ serves as a template for various optical spectroscopy experiments--> principal investigator. (ii) The identifier enables to link experiments to e.g. proposals. - - - + + + @@ -130,7 +142,7 @@ serves as a template for various optical spectroscopy experiments--> Specify the type of the optical experiment. - Chose other if non of these methods are suitable. You may specify + Chose other if none of these methods are suitable. You may specify fundamental characteristics or properties in the experimental sub-type. @@ -142,7 +154,7 @@ serves as a template for various optical spectroscopy experiments--> - + Specify a special property or characteristic of the experiment, which specifies the generic experiment type. @@ -158,71 +170,35 @@ serves as a template for various optical spectroscopy experiments--> experimental technique -\-> pump-probe, parameters seperated (i.e. time, space)? The above listed things are related to beam properties? This is different compared to temperature or pressure. Is this a useful distinction?--> - + - If "other" was selected in "experiment_type", specify the experiment here - with a free text name, which is knwon in the respective community of interest. + If "other" was selected in "experiment_type" and/or in "experiment_sub_type", + specify the experiment here with a free text name, which is knwon in the + respective community of interest. + + + + Description of one or more coordinate systems that are specific to the + experiment. + + Contact information and eventually details of at persons who performed the measurements. This can be for example the principal - investigator or student. + investigator or student. Examples are: name, affiliation, address, telephone + number, email, role as well as identifiers such as orcid or similar. It is recommended to add multiple users if relevant. Due to data privacy concerns, there is no minimum requirement. - - - 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 user's affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Author ID defined by https://orcid.org/. - - - - - (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 setup, student, PhD-student, postdoc, principle investigator, or guest - are common examples. - - - - - Service as another mean of identification of a user other than by its name. - Examples could be an ORCID or social media account of the user. - - - - - @@ -249,14 +225,7 @@ compared to temperature or pressure. Is this a useful distinction?--> - - - Datetime of setup's initial construction. This refers to the date of - first measurement after new construction or relocation of the setup. - Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, - otherwise the local time zone is assumed per ISO8601. - - + @@ -267,7 +236,7 @@ compared to temperature or pressure. Is this a useful distinction?--> "software_detector" or "software_stage" to specify the respective program or software components. - + Either version with build number, commit hash, or description of a (online) repository where the source code of the program and build @@ -284,19 +253,9 @@ compared to temperature or pressure. Is this a useful distinction?--> - - - - - Description of one or more coordinate systems that are specific to the - experiment. - - + Defines the reference frame which is used to describe the sample orientation @@ -354,7 +313,9 @@ geographic north pole: harder to determine? (What about GPS?), but constant with Pre-calibration of an arbitrary device of the instrumental setup, which - has the name DEVICE. You can specify here at which point + has the name DEVICE. You can specify here how, at which time by which method + the calibration was done. As well the accuracy and a link to the calibration + dataset. @@ -419,27 +380,29 @@ This information may be as well stored in an incident and detection beam--> Beam characteristics between two beam_devices. - It is recommended, to at least define one incident and one detection beam. - If this beam is directly connected to an source, chose here the same + It is recommended to at least define one incident and one detection beam. + If this beam is directly connected to a source, chose here the same name appendix as for the NXsource (e.g. TYPE=532nm) - - - + + + - + - The path to a the source, which emitted this beam. - Should be named with the same appendix as the source, e.g., - for TYPE=532nmlaser, there should as well be - a NXsource named "source_532nmlaser" aside of this Beam - instance named "beam_532nmlaser" + The path to the source which emitted this beam. + + Is recommended, if the previous optical element is a photon source. + In this way, the properties of the laser or light souce can be described + and associated. + The beam should be named with the same appendix as the source, e.g., + for TYPE=532nmlaser, there should be both a NXsource named + "source_532nmlaser" and a NXbeam named "beam_532nmlaser". Example: /entry/instrument/source_532nmlaser - + @@ -464,12 +427,8 @@ incident_polarization--> - @@ -815,6 +821,7 @@ this might require a different reference frame. of the stage type. + This is a placeholder, to describe the relation between the samples @@ -854,9 +861,9 @@ this might require a different reference frame. - + - + @@ -870,29 +877,6 @@ this might require a different reference frame. - - - - - - - - - - Control of arbitrary parameter - compare to temperature above. - - - - - - Hardware used for actuation - - - - - - - @@ -909,7 +893,7 @@ this might require a different reference frame. - Uniquely identifying name of the sample. + Uniquely identifying ID of the sample. @@ -924,18 +908,6 @@ this might require a different reference frame. Free text description of the sample. - - - - - - - - - - - - Chemical formula of the sample. Use the Hill system (explained here: @@ -968,14 +940,6 @@ this might require a different reference frame. A set of activities that occurred to the sample prior to/during the experiment. - - - A reference to the location or a unique (globally - persistent) identifier (e.g.) of e.g. another file which gives - as many as possible details of the material, its microstructure, - and its thermo-chemo-mechanical processing/preparation history. - - @@ -993,9 +957,9 @@ this might require a different reference frame. This should be a link to /entry/instrument/manipulator/sample_heater. - + - Cryostat for cooling the sample. + Device for cooling the sample (Cryostat, Airflow cooler, etc.). This should be a link to /entry/instrument/manipulator/cryostat. @@ -1006,8 +970,18 @@ this might require a different reference frame. and controlled by a device. Examples are pressure, voltage, magnetic field etc. Similar to the temperautre description of the sample. - - + + + + + + + + + + + + diff --git a/contributed_definitions/NXopt_window.nxdl.xml b/contributed_definitions/NXopt_window.nxdl.xml new file mode 100644 index 0000000000..bdc29f6110 --- /dev/null +++ b/contributed_definitions/NXopt_window.nxdl.xml @@ -0,0 +1,117 @@ + + + + + + + A window of a cryostat, heater, vacuum chamber or a simple glass slide. + + This first verion originates from NXopt to describe cryostate windows + and possible influences for ellipsometry measurements. + + For environmental measurements, the environment (liquid, vapor + etc.) is enclosed in a cell, which has windows both in the + direction of the source (entry window) and the detector (exit + window) (looking from the sample). In case that the entry and exit + windows are not the same type and do not have the same properties, + use a second 'WINDOW(NXaperture)' field. + + The windows also add a phase shift to the light altering the + measured signal. This shift has to be corrected based on measuring + a known sample (reference sample) or the actual sample of interest + in the environmental cell. State if a window correction has been + performed in 'window_effects_corrected'. Reference data should be + considered as a separate experiment, and a link to the NeXus file + should be added in reference_data_link in measured_data. + + The window is considered to be a part of the sample stage but also + beam path. Hence, its position within the beam path should be + defined by the 'depends_on' field. + + + + + Was a window correction performed? If 'True' describe the window + correction procedure in 'window_correction/procedure'. + + + + + Was a window correction performed? If 'True' describe the + window correction procedure in '' + + + + Describe when (before or after the main measurement + time + stamp in 'date') and how the window effects have been + corrected, i.e. either mathematically or by performing a + reference measurement. In the latter case, provide the link to + to the reference data in 'reference_data_link'. + + + + + Link to the NeXus file which describes the reference data if a + reference measurement for window correction was performed. + Ideally, the reference measurement was performed on a reference + sample and on the same sample, and using the same conditions as + for the actual measurement with and without windows. It should + have been conducted as close in time to the actual measurement + as possible. + + + + + + The material of the window. + + + + + + + + + + + + + + + If you specified 'other' as material, decsribe here what it is. + + + + + Thickness of the window. + + + + + Angle of the window normal (outer) vs. the substrate normal + (similar to the angle of incidence). + + + + diff --git a/contributed_definitions/nyaml/NXopt.yaml b/contributed_definitions/nyaml/NXopt.yaml index 8ba2483769..f79655ef34 100644 --- a/contributed_definitions/nyaml/NXopt.yaml +++ b/contributed_definitions/nyaml/NXopt.yaml @@ -28,6 +28,18 @@ symbols: # 04/2024 # Extension of the Draft Version (05/2023) of a NeXus application definition which # serves as a template for various optical spectroscopy experiments +# +# TODO: +# - Merge reference_frames with angle_reference_frame +# - Rework instrument_calibration_DEVICE - use NXcalibration? +# - Beam polarizations: Own Polarization concept with angle or from NXbeam via beam coordinates? (solve reference frame problem first) +# - Describe angle_of_detection by NXtransformations +# - remove NXmonchromator? as it is already in NXinstrument +# - Add NXlens_opt and NXwaveplate to NXinstrument? +# - Make sample stage_stage(NXmanipulator)/reference_frame via NXtransformations +# - Add properties from NXlens_opt from NXopt to NXlens_opt base class +# - Make polfilter_TYPE(NXbeam_device) own base class --> rework NXpolarizer_opt. and add them to NXinstrument. +# - Make spectralfilter_TYPE(NXbeam_device) own base class --> extend NXfilter? and add them to NXinstrument. type: group NXopt(NXobject): (NXentry): @@ -63,8 +75,11 @@ NXopt(NXobject): principal investigator. (ii) The identifier enables to link experiments to e.g. proposals. service(NX_CHAR): + exists: optional identifier(NX_CHAR): + exists: recommended is_persistent(NX_BOOLEAN): + exists: optional experiment_description: exists: optional doc: | @@ -81,10 +96,11 @@ NXopt(NXobject): doc: | Specify the type of the optical experiment. - Chose other if non of these methods are suitable. You may specify + Chose other if none of these methods are suitable. You may specify fundamental characteristics or properties in the experimental sub-type. enumeration: [ellipsometry, Raman spectroscopy, photoluminescence, transmission spectroscopy, reflection spectroscopy, other] experiment_sub_type: + exists: optional doc: | Specify a special property or characteristic of the experiment, which specifies the generic experiment type. @@ -94,60 +110,30 @@ NXopt(NXobject): # The above listed things are related to beam properties? This is different # compared to temperature or pressure. Is this a useful distinction? experiment_type_other: + exists: optional + doc: | + If "other" was selected in "experiment_type" and/or in "experiment_sub_type", + specify the experiment here with a free text name, which is knwon in the + respective community of interest. + reference_frames(NXcoordinate_system_set): + # This should be extended later and hopefully replace angle_reference_frame + # and sample_normal_direction. + # Required reference frames: + # Sample normal, beam_z_axis, sample_stage + exists: optional doc: | - If "other" was selected in "experiment_type", specify the experiment here - with a free text name, which is knwon in the respective community of interest. + Description of one or more coordinate systems that are specific to the + experiment. (NXuser): exists: [min, 0, max, infty] doc: | Contact information and eventually details of at persons who performed the measurements. This can be for example the principal - investigator or student. + investigator or student. Examples are: name, affiliation, address, telephone + number, email, role as well as identifiers such as orcid or similar. It is recommended to add multiple users if relevant. Due to data privacy concerns, there is no minimum requirement. - name(NX_CHAR): - exists: recommended - doc: | - Given (first) name and surname of the user. - affiliation(NX_CHAR): - exists: optional - doc: | - Name of the affiliation of the user at the point in time - when the experiment was performed. - address(NX_CHAR): - exists: optional - doc: | - Postal address of the user's affiliation. - email(NX_CHAR): - exists: optional - 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(NX_CHAR): - exists: recommended - doc: | - Author ID defined by https://orcid.org/. - telephone_number(NX_CHAR): - exists: optional - doc: | - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - role(NX_CHAR): - exists: optional - doc: | - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the setup, student, PhD-student, postdoc, principle investigator, or guest - are common examples. - identifier(NXidentifier): - exists: recommended - doc: | - Service as another mean of identification of a user other than by its name. - Examples could be an ORCID or social media account of the user. - service(NX_CHAR): - identifier(NX_CHAR): - is_persistent(NX_BOOLEAN): (NXinstrument): doc: | Devices or elements of the optical spectroscopy setup described with its @@ -176,12 +162,7 @@ NXopt(NXobject): identifier: exists: recommended construction_year(NX_DATE_TIME): - exists: recommended - doc: | - Datetime of setup's initial construction. This refers to the date of - first measurement after new construction or relocation of the setup. - Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, - otherwise the local time zone is assumed per ISO8601. + exists: optional software_TYPE(NXprogram): exists: recommended program: @@ -192,6 +173,7 @@ NXopt(NXobject): "software_detector" or "software_stage" to specify the respective program or software components. \@version: + exists: recommended doc: | Either version with build number, commit hash, or description of a (online) repository where the source code of the program and build @@ -203,16 +185,9 @@ NXopt(NXobject): doc: | Description of the software by persistent resource, where the program, code, script etc. can be found. - # general properties and reference frames - reference_frames(NXcoordinate_system_set): - # This should be extended later and hopefully replace angle_reference_frame - # and sample_normal_direction. - # Required reference frames: - # Sample normal, beam_z_axis, sample_stage - exists: optional - doc: | - Description of one or more coordinate systems that are specific to the - experiment. + # The angle_reference_frame will be connected later to general reference frames + # For this this solution enables the description of the beam relations for + # different optical spectroscopy methods in the reference frame they are used to angle_reference_frame: doc: | Defines the reference frame which is used to describe the sample orientation @@ -264,7 +239,9 @@ NXopt(NXobject): exists: recommended doc: | Pre-calibration of an arbitrary device of the instrumental setup, which - has the name DEVICE. You can specify here at which point + has the name DEVICE. You can specify here how, at which time by which method + the calibration was done. As well the accuracy and a link to the calibration + dataset. device_path: exists: recommended doc: | @@ -317,31 +294,31 @@ NXopt(NXobject): doc: | Beam characteristics between two beam_devices. - It is recommended, to at least define one incident and one detection beam. - If this beam is directly connected to an source, chose here the same + It is recommended to at least define one incident and one detection beam. + If this beam is directly connected to a source, chose here the same name appendix as for the NXsource (e.g. TYPE=532nm) - incident_wavelength(NX_FLOAT): - unit: NX_WAVELENGTH + incident_wavelength(NX_NUMBER): + exists: recommended incident_wavelength_spread(NX_NUMBER): exists: recommended - unit: NX_WAVELENGTH incident_polarization(NX_NUMBER): exists: recommended - unit: NX_ANY extent(NX_FLOAT): exists: recommended associated_source(NX_CHAR): - exists: recommended + exists: optional doc: | - The path to a the source, which emitted this beam. - Should be named with the same appendix as the source, e.g., - for TYPE=532nmlaser, there should as well be - a NXsource named "source_532nmlaser" aside of this Beam - instance named "beam_532nmlaser" + The path to the source which emitted this beam. + + Is recommended, if the previous optical element is a photon source. + In this way, the properties of the laser or light souce can be described + and associated. + The beam should be named with the same appendix as the source, e.g., + for TYPE=532nmlaser, there should be both a NXsource named + "source_532nmlaser" and a NXbeam named "beam_532nmlaser". Example: /entry/instrument/source_532nmlaser - # The two polarization descriptions may be completely replaced by - # incident_polarization + # The two polarization descriptions may be completely replaced by polarization beam_polarization_type: exists: optional enumeration: [linear, circular, ellipically, unpolarized] @@ -360,12 +337,8 @@ NXopt(NXobject): relation between different polarizations has to be consistent (i.e. parallel polarized 0° and cross polarized 90°) unit: NX_ANGLE - # Discussion with florian: - # The user wants to use simple parameters, which they are used to. - # Though, via NXtransformations in principle maximum flexibility can be provided, - # even for unusual and complex experimental setups. - # The solution from mpes was: simple "front end" by only stating one angle - # with the "backend" to be customizable via NXtransformations. + # The given angles may be extended similar to NXmpes, to allow a simple + # as well as an arbitrary description via NXtransformations # # fundamental orientation of incident and detection beam angle_of_incidence(NX_NUMBER): @@ -432,18 +405,13 @@ NXopt(NXobject): exists: [min, 1, max, infty] type: exists: recommended - enumeration: [laser, dye-laser, broadband tunable light source, X-ray Source, other] + enumeration: [laser, dye-laser, broadband tunable light source, X-ray Source, arc lamp, halogen lamp, LED, other] type_other: exists: optional doc: | Specification of type, may also go to name. name: exists: recommended - source_polarization: - exists: recommended - doc: | - The type of light polarization produced by the source. - enumeration: [linear, unpolarized, circular, elliptically, other] device_information(NXfabrication): doc: | Details about the device information. @@ -452,11 +420,16 @@ NXopt(NXobject): The path to a beam emitted by this source. Should be named with the same appendix, e.g., for TYPE=532nmlaser, there should as well be - a NXbeam named "beam_532nmlaser" aside of this source + a NXbeam named "beam_532nmlaser" together with this source instance named "source_532nmlaser" Example: /entry/instrument/beam_532nmlaser device_characteristics(NXdata): + exists: optional + doc: | + You may add here data which characterises the source in more detail, + such as spectral power density, power dependency on line width, line-shape + of the laser line, etc. detector_TYPE(NXdetector): exists: [min, 1, max, infty] detector_channel_type: @@ -466,8 +439,17 @@ NXopt(NXobject): exists: recommended doc: | Description of the detector type. - enumeration: [CCD, Photomultiplier, Photodiode, Avalanche-Photodiode, Bolometer, Golay Detectors, Pyroelectric Detector] + enumeration: [CCD, Photomultiplier, Photodiode, Avalanche-Photodiode, Bolometer, Golay Detectors, Pyroelectric Detector, other] + detector_type_other: + exists: optional + doc: | + Type of detector, if "other" was selected in "detector_type". device_characteristics(NXdata): + exists: optional + doc: | + You may add here data which characterizes the detector, such as quantum + efficiency as function of wavelength or angular dependency of intenty. + device_information(NXfabrication): exists: recommended vendor: @@ -519,76 +501,42 @@ NXopt(NXobject): (NXmonochromator): exists: optional device_characteristics(NXdata): + exists: optional + doc: | + Characteristics of the monochromator as diffraction efficiency as + wavelength and polarization dependence + device_information(NXfabrication): + exists: recommended + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended (NXlens_opt): - exists: optional - device_characteristics(NXdata): - (NXwaveplate): - exists: optional - device_characteristics(NXdata): - WINDOW(NXaperture): exists: optional doc: | - For environmental measurements, the environment (liquid, vapor - etc.) is enclosed in a cell, which has windows both in the - direction of the source (entry window) and the detector (exit - window) (looking from the sample). In case that the entry and exit - windows are not the same type and do not have the same properties, - use a second 'WINDOW(MXaperture)' field. - - The windows also add a phase shift to the light altering the - measured signal. This shift has to be corrected based on measuring - a known sample (reference sample) or the actual sample of interest - in the environmental cell. State if a window correction has been - performed in 'window_effects_corrected'. Reference data should be - considered as a separate experiment, and a link to the NeXus file - should be added in reference_data_link in measured_data. - - The window is considered to be a part of the sample stage but also - beam path. Hence, its position within the beam path should be - defined by the 'depends_on' field. - window_effects_corrected(NX_BOOLEAN): - doc: | - Was a window correction performed? If 'True' describe the window - correction procedure in 'window_correction/procedure'. - window_correction(NXprocess): - exists: optional - doc: | - Was a window correction performed? If 'True' describe the - window correction procedure in '' - procedure: - doc: | - Describe when (before or after the main measurement + time - stamp in 'date') and how the window effects have been - corrected, i.e. either mathematically or by performing a - reference measurement. In the latter case, provide the link to - to the reference data in 'reference_data_link'. - reference_data_link: - exists: optional - doc: | - Link to the NeXus file which describes the reference data if a - reference measurement for window correction was performed. - Ideally, the reference measurement was performed on a reference - sample and on the same sample, and using the same conditions as - for the actual measurement with and without windows. It should - have been conducted as close in time to the actual measurement - as possible. - material(NX_CHAR): - doc: | - The material of the window. - enumeration: [quartz, diamond, calcium fluoride, zinc selenide, thallium bromoiodide, alkali halide compound, Mylar, other] - material_other(NX_CHAR): - exists: optional + This is the optical element used to focus or collect light. This may + be a genereic lens or microcope objectives which are used for the + Raman scattering process. + type: + enumeration: [objective, lens, glass fiber, none, other] + numerical_aperture(NX_NUMBER): doc: | - If you specified 'other' as material, decsribe here what it is. - thickness(NX_FLOAT): - unit: NX_LENGTH + The numerical aperture of the used incident light optics. + magnification(NX_FLOAT): doc: | - Thickness of the window. - orientation_angle(NX_FLOAT): - unit: NX_ANGLE + Magnification of the lens. + device_information(NXfabrication): + exists: recommended doc: | - Angle of the window normal (outer) vs. the substrate normal - (similar to the angle of incidence). + Details about the optical component, if available. + device_characteristics(NXdata): + (NXwaveplate): + exists: optional + device_characteristics(NXdata): + (NXopt_window): + sample_medium_refractive_indices(NX_FLOAT): exists: optional unit: NX_UNITLESS @@ -600,6 +548,66 @@ NXopt(NXobject): dimensions: rank: 2 dim: [[1, 2], [2, N_spectrum]] + + polfilter_TYPE(NXbeam_device): + exists: optional + doc: | + polarization filter to prepare light to be measured or to be incident + on the sample. + Genereric polarization filter porperties may be implemented via NXfilter_pol + at a later stage. + filter_mechanism(NX_CHAR): + exists: optional + doc: | + Physical principle of the polarization filter used to create a + defined incident or scattered light state. + enumeration: [Polarization by Fresnel reflection, Birefringent polarizers, Thin film polarizers, Wire-grid polarizers, other] + specific_polarization_filter_type(NX_CHAR): + exists: optional + doc: | + Specific name or type of the polarizer used. + + Free text, for example: Glan-Thompson, Glan-Taylor, Rochon Prism, Wollaston + Polarizer... + device_information(NXfabrication): + spectralfilter_TYPE(NXbeam_device): + exists: optional + doc: | + Spectral filter used to modify properties of the scattered or incident light. + Genereric spectral filter porperties may be implemented via NXfilter_spec + at a later stage. + filter_type: + exists: optional + doc: | + Type of laserline filter used to supress the laser, if measurements + close to the laserline are performed. + enumeration: [long-pass filter, short-pass filter, Notch filter, reflection filter, neutral density filter, other] + intended_use: + exists: optional + doc: | + Type of laserline filter used to supress the laser, if measurements + close to the laserline are performed. + enumeration: [laser line cleanup, raylight line removal, spectral filtering, intensity manipulation, other] + filter_characteristics(NXdata): + exists: optional + doc: | + Properties of the spectral filter such as wavelength dependent Transmission + or reflectivity. + \@characteristics_type: + exists: optional + doc: | + Which property is used to form the spectral properties of light, + i.e. transmission or reflection properties. + enumeration: [transmission, reflection] + device_information(NXfabrication): + + + # In the following - Auxillary NXbeam_devices are defined, to enable a + # beam path description of the setup, while using the up now available + # Nexus definitions for source, detector, monochromator, ... + + + # beam devices for beam path description (NXbeam_device): exists: [min, 0, max, infty] @@ -644,6 +652,7 @@ NXopt(NXobject): doc: | If "other" was chosen in stage_type, enter here a free text description of the stage type. + # This is for now a placeholder and should be specified with NXtransformation reference_frame: exists: optional doc: | @@ -677,9 +686,9 @@ NXopt(NXobject): exists: recommended physical_quantity: enumeration: [temperature] - cryo_or_heater: + cooler_or_heater: exists: recommended - enumeration: [cryostat, heater] + enumeration: [cooler, heater] type: exists: optional doc: | @@ -688,30 +697,6 @@ NXopt(NXobject): setpoint(NX_FLOAT): exists: recommended device_information(NXfabrication): - PARAMETER_SENSOR(NXsensor): - exists: recommended - name: - exists: recommended - measurement: - type: - exists: optional - value(NX_FLOAT): - device_information(NXfabrication): - PARAMETER_ACTUATOR(NXactuator): - doc: - Control of arbitrary parameter - compare to temperature above. - exists: optional - name: - exists: recommended - physical_quantity: - type: - exists: optional - doc: | - Hardware used for actuation - (NXpid): - setpoint(NX_FLOAT): - exists: recommended - device_information(NXfabrication): (NXsample): doc: | Properties of the sample, such as sample type, layer structure, @@ -725,7 +710,7 @@ NXopt(NXobject): sample_id: exists: recommended doc: | - Uniquely identifying name of the sample. + Uniquely identifying ID of the sample. physical_form: exists: recommended doc: | @@ -736,9 +721,6 @@ NXopt(NXobject): exists: optional doc: | Free text description of the sample. - situation: - exists: recommended - enumeration: [air, vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere, sealed can, water, other] chemical_formula: exists: recommended doc: | @@ -768,12 +750,6 @@ NXopt(NXobject): exists: recommended doc: | A set of activities that occurred to the sample prior to/during the experiment. - history_id(NXidentifier): - doc: | - A reference to the location or a unique (globally - persistent) identifier (e.g.) of e.g. another file which gives - as many as possible details of the material, its microstructure, - and its thermo-chemo-mechanical processing/preparation history. temperature(NXenvironment): exists: recommended doc: | @@ -787,10 +763,10 @@ NXopt(NXobject): doc: | Device to heat the sample. This should be a link to /entry/instrument/manipulator/sample_heater. - cryostat(NXactuator): + sample_cooler(NXactuator): exists: optional doc: | - Cryostat for cooling the sample. + Device for cooling the sample (Cryostat, Airflow cooler, etc.). This should be a link to /entry/instrument/manipulator/cryostat. (NXenvironment): exists: optional @@ -798,10 +774,9 @@ NXopt(NXobject): Arbirary sample property which may be varied during the experiment and controlled by a device. Examples are pressure, voltage, magnetic field etc. Similar to the temperautre description of the sample. - (NXsensor): - exists: optional - (NXactuator): - exists: optional + sample_medium: + exists: recommended + enumeration: [air, vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere, sealed can, water, other] thickness(NX_NUMBER): exists: optional doc: | diff --git a/contributed_definitions/nyaml/NXopt_window.yaml b/contributed_definitions/nyaml/NXopt_window.yaml new file mode 100644 index 0000000000..7ca0ae0a76 --- /dev/null +++ b/contributed_definitions/nyaml/NXopt_window.yaml @@ -0,0 +1,69 @@ +category: base +doc: | + A window of a cryostat, heater, vacuum chamber or a simple glass slide. + + This first verion originates from NXopt to describe cryostate windows + and possible influences for ellipsometry measurements. + + For environmental measurements, the environment (liquid, vapor + etc.) is enclosed in a cell, which has windows both in the + direction of the source (entry window) and the detector (exit + window) (looking from the sample). In case that the entry and exit + windows are not the same type and do not have the same properties, + use a second 'WINDOW(NXaperture)' field. + + The windows also add a phase shift to the light altering the + measured signal. This shift has to be corrected based on measuring + a known sample (reference sample) or the actual sample of interest + in the environmental cell. State if a window correction has been + performed in 'window_effects_corrected'. Reference data should be + considered as a separate experiment, and a link to the NeXus file + should be added in reference_data_link in measured_data. + + The window is considered to be a part of the sample stage but also + beam path. Hence, its position within the beam path should be + defined by the 'depends_on' field. +# A draft of a new base class to describe a window in a optical setup or device +type: group +NXopt_window(NXaperture): + (NXentry): + window_effects_corrected(NX_BOOLEAN): + doc: | + Was a window correction performed? If 'True' describe the window + correction procedure in 'window_correction/procedure'. + window_correction(NXprocess): + doc: | + Was a window correction performed? If 'True' describe the + window correction procedure in '' + procedure: + doc: | + Describe when (before or after the main measurement + time + stamp in 'date') and how the window effects have been + corrected, i.e. either mathematically or by performing a + reference measurement. In the latter case, provide the link to + to the reference data in 'reference_data_link'. + reference_data_link: + doc: | + Link to the NeXus file which describes the reference data if a + reference measurement for window correction was performed. + Ideally, the reference measurement was performed on a reference + sample and on the same sample, and using the same conditions as + for the actual measurement with and without windows. It should + have been conducted as close in time to the actual measurement + as possible. + material(NX_CHAR): + doc: | + The material of the window. + enumeration: [quartz, diamond, calcium fluoride, zinc selenide, thallium bromoiodide, alkali halide compound, Mylar, other] + material_other(NX_CHAR): + doc: | + If you specified 'other' as material, decsribe here what it is. + thickness(NX_FLOAT): + unit: NX_LENGTH + doc: | + Thickness of the window. + orientation_angle(NX_FLOAT): + unit: NX_ANGLE + doc: | + Angle of the window normal (outer) vs. the substrate normal + (similar to the angle of incidence). \ No newline at end of file From 2811f38f8fab23a267c4868ec3820e334e7a1199 Mon Sep 17 00:00:00 2001 From: Ron Hildebrandt Date: Tue, 30 Apr 2024 13:33:18 +0200 Subject: [PATCH 0676/1012] Update NXraman and NXellipsometry to match NXopt overhaul --- .../NXellipsometry.nxdl.xml | 179 ++---- contributed_definitions/NXraman.nxdl.xml | 247 ++++++++ .../nyaml/NXellipsometry.yaml | 133 +--- contributed_definitions/nyaml/NXraman.yaml | 592 ++++++++++++++++++ 4 files changed, 917 insertions(+), 234 deletions(-) create mode 100644 contributed_definitions/NXraman.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXraman.yaml diff --git a/contributed_definitions/NXellipsometry.nxdl.xml b/contributed_definitions/NXellipsometry.nxdl.xml index 2af9c29691..3578d76102 100644 --- a/contributed_definitions/NXellipsometry.nxdl.xml +++ b/contributed_definitions/NXellipsometry.nxdl.xml @@ -1,10 +1,10 @@ - + - - - - - + + Variables used throughout the document, e.g. dimensions or parameters. @@ -53,12 +35,6 @@ A draft version of a NeXus application definition for ellipsometry.--> data. - - - Number of sensors used to measure parameters that influence the sample, - such as temperature or pressure. - - Number of measurements (1st dimension of measured_data array). This is @@ -78,22 +54,16 @@ A draft version of a NeXus application definition for ellipsometry.--> Number of angles of incidence of the incident beam. - - - Number of observables that are saved in a measurement. e.g. one for - intensity, reflectivity or transmittance, two for Psi and Delta etc. This - is equal to the second dimension of the data array 'measured_data' and the - number of column names. - - - - - Number of time points measured, the length of NXsample/time_points - - - Ellipsometry, complex systems, up to variable angle spectroscopy. + This is the application definition describing ellipsometry experiments. + + Such experiments may be as simple as identifying how a reflected + beam of light with a single wavelength changes its polarization state, + to a variable angle spectroscopic ellipsometry experiment. + + The application definition specifies optical spectroscopy (NXopt), by extending + the terms and setting specific requirements. Information on ellipsometry is provided, e.g. in: @@ -111,38 +81,24 @@ A draft version of a NeXus application definition for ellipsometry.--> Review articles: - * T. E. Jenkins, "Multiple-angle-of-incidence ellipsometry", + * T. E. Jenkins, "Multiple-angle-of-incidence ellipsometry", J. Phys. D: Appl. Phys. 32, R45 (1999), https://doi.org/10.1088/0022-3727/32/9/201 - * D. E. Aspnes, "Spectroscopic ellipsometry - Past, present, and future", + * D. E. Aspnes, "Spectroscopic ellipsometry - Past, present, and future", Thin Solid Films 571, 334-344 (2014), https://doi.org/10.1016/j.tsf.2014.03.056 - * R. M. A. Azzam, "Mueller-matrix ellipsometry: a review", + * R. M. A. Azzam, "Mueller-matrix ellipsometry: a review", Proc. SPIE 3121, Polarization: Measurement, Analysis, and Remote Sensing, (3 October 1997), https://doi.org/10.1117/12.283870 - * E. A. Irene, "Applications of spectroscopic ellipsometry to microelectronics", + * E. A. Irene, "Applications of spectroscopic ellipsometry to microelectronics", Thin Solid Films 233, 96-111 (1993), https://doi.org/10.1016/0040-6090(93)90069-2 - * S. Zollner et al., "Spectroscopic ellipsometry from 10 to 700 K", + * S. Zollner et al., "Spectroscopic ellipsometry from 10 to 700 K", Adv. Opt. Techn., (2022), https://doi.org/10.1515/aot-2022-0016 - - This is the application definition describing ellipsometry experiments. - - Such experiments may be as simple as identifying how a reflected - beam of light with a single wavelength changes its polarization state, - to a variable angle spectroscopic ellipsometry experiment. - - The application definition defines: - - * elements of the experimental instrument - * calibration information if available - * parameters used to tune the state of the sample - * sample description - An application definition for ellipsometry. @@ -163,16 +119,18 @@ A draft version of a NeXus application definition for ellipsometry.--> - + + - An optional free-text description of the experiment. + Specify the type of the optical experiment. - However, details of the experiment should be defined in the specific - fields of this application definition rather than in this experiment - description. + You may specify fundamental characteristics or properties in the experimental sub-type. + + + - + Specify the type of ellipsometry. @@ -183,35 +141,18 @@ A draft version of a NeXus application definition for ellipsometry.--> - + + + + If the ellipsometry_experiment_type is `other`, a name should be specified here. + + Properties of the ellipsometry equipment. - - - Name of the company which build the instrument. - - - - - ISO8601 date when the instrument was constructed. - UTC offset should be specified. - - - - - - Commercial or otherwise defined given name of the program that was - used to generate the result file(s) with measured data and metadata. - This program converts the measured signals to ellipsometry data. If - home written, one can provide the actual steps in the NOTE subfield - here. - - - What type of ellipsometry was used? See Fujiwara Table 4.2. @@ -243,24 +184,17 @@ A draft version of a NeXus application definition for ellipsometry.--> - - - Specify the used light source. Multiple selection possible. - - - - - - - - - - + If focussing probes (lenses) were used, please state if the data were corrected for the window effects. + Were the recorded data corrected by the window effects of the @@ -273,12 +207,6 @@ A draft version of a NeXus application definition for ellipsometry.--> - - - Properties of the detector used. Integration time is the count time - field, or the real time field. See their definition. - - Properties of the rotating element defined in @@ -305,35 +233,24 @@ A draft version of a NeXus application definition for ellipsometry.--> - - - The spectroscope element of the ellipsometer before the detector, - but often integrated to form one closed unit. Information on the - dispersive element can be specified in the subfield GRATING. Note - that different gratings might be used for different wavelength - ranges. The dispersion of the grating for each wavelength range can - be stored in grating_dispersion. - - - + Was the backside of the sample roughened? Relevant for infrared ellipsometry. - + Select which type of data was recorded, for example Psi and Delta (see: https://en.wikipedia.org/wiki/Ellipsometry#Data_acquisition). It is possible to have multiple selections. Data types may also be converted to each other, e.g. a Mueller matrix contains N,C,S data - as well. This selection defines how many columns (N_observables) are - stored in the data array. + as well. @@ -346,12 +263,4 @@ A draft version of a NeXus application definition for ellipsometry.--> - diff --git a/contributed_definitions/NXraman.nxdl.xml b/contributed_definitions/NXraman.nxdl.xml new file mode 100644 index 0000000000..79576265f8 --- /dev/null +++ b/contributed_definitions/NXraman.nxdl.xml @@ -0,0 +1,247 @@ + + + + + + + + + Variables used throughout the document, e.g. dimensions or parameters. + + + + Length of the spectrum array (e.g. wavelength or energy) of the measured + data. + + + + + Number of measurements (1st dimension of measured_data array). This is + equal to the number of parameters scanned. For example, if the experiment + was performed at three different temperatures and two different pressures + N_measurements = 2*3 = 6. + + + + + Number of detection angles of the beam reflected or scattered off the + sample. + + + + + Number of angles of incidence of the incident beam. + + + + + Number of scattering configurations used in the measurement. + It is 1 for only parallel polarization meausement, 2 for parallel and cross + polarization measurement or larger, if i.e. the incident and scattered photon + direction is varied. + + + + + An application definition for Raman spectrocopy experiments. + + Such experiments may be as simple a single Raman spectrum from spontanous + Raman scattering and range to Raman imaging Raman spectrometer, + surface- and tip-enhanced Raman techniques, x-Ray Raman scattering, as well + as resonant Raman scattering phenomena or multidimenional Raman spectra (i.e. + varying temperature, pressure, electric field, ....) + + The application definition contains two things: + 1. The structures in the application definition of NXopt: + * Instrument and data calibrations + * Sensors for sample or beam conditions + + AND + + 2. The strucutres specified and extended in NXraman: + * description of the experiment type + * descroption of the setup's meta data and optical elements (source, monochromator, detector, waveplate, lens, etc.) + * description of beam properties and their relations to the sample + * sample information + + Information on Raman spectroscopy are provided in: + + General + + * Lewis, Ian R.; Edwards, Howell G. M. + Handbook of Raman Spectroscopy + ISBN 0-8247-0557-2 + + Raman scattering selection rules + + * Dresselhaus, M. S.; Dresselhaus, G.; Jorio, A. + Group Theory - Application to the Physics ofCondensed Matter + ISBN 3540328971 + + Semiconductors + + * Manuel Cardona + Light Scattering in Solids I + eBook ISBN: 978-3-540-37568-5 + DOI: https://doi.org/10.1007/978-3-540-37568-5 + + * Manuel Cardona, Gernot Güntherodt + Light Scattering in Solids II + eBook ISBN: 978-3-540-39075-6 + DOI: https://doi.org/10.1007/3-540-11380-0 + + * See as well other Books from the "Light Scattering in Solids" series: + III: Recent Results + IV: Electronic Scattering, Spin Effects, SERS, and Morphic Effects + V: Superlattices and Other Microstructures + VI: Recent Results, Including High-Tc Superconductivity + VII: Crystal-Field and Magnetic Excitations + VIII: Fullerenes, Semiconductor Surfaces, Coherent Phonons + IX: Novel Materials and Techniques + + Glasses, Liquids, Gasses, ... + + Review articles: + Stimulated Raman scattering, Coherent anti-Stokes Raman scattering, + Surface-enhanced Raman scattering, Tip-enhanced Raman scattering + * https://doi.org/10.1186/s11671-019-3039-2 + + + + + An application definition for Raman spectrsocopy. + + + + Version number to identify which definition of this application + definition was used for this entry/data. + + + + + URL where to find further material (documentation, examples) relevant + to the application definition. + + + + + + + + + + Specify the type of the optical experiment. + + You may specify fundamental characteristics or properties in the experimental sub-type. + + + + + + + + Specify the type of Raman experiment. + + + + + + + + + + + + + + + + + + + If the raman_experiment_type is `other`, a name should be specified here. + + + + + Metadata of the setup, its optical elements and physical properites which + defines the Raman measurement. + + + + Scattering configuration as defined by the porto notation by three + states, which are othogonal to each other. Example: z(xx)z for + parallel polarized backscattering configuration. + + See: + https://www.cryst.ehu.es/cgi-bin/cryst/programs/nph-doc-raman + + A(BC)D + + A = The propagation direction of the incident light (k_i) + B = The polarization direction of the incident light (E_i) + C = The polarization direction of the scattered light (E_s) + D = The propagation direction of the scattered light (k_s) + + An orthogonal base is assumed. + Linear polarized light is displayed by e.g. "x","y" or "z" + Unpolarized light is displayed by "." + For non-orthogonal vectors, use the attribute porto_notation_vectors. + + + + + Scattering configuration as defined by the porto notation given by + respective vectors. + + Vectors in the porto notation are defined as for A, B, C, D above. + Linear light polarization is assumed. + + + + 3 x 4 Matrix, which lists the porto notation vectors A, B, C, D. + A has to be perpendicular to B and C perpendicular to D. + + + + + + + + + + Beam which is incident to the sample. + + + + + + diff --git a/contributed_definitions/nyaml/NXellipsometry.yaml b/contributed_definitions/nyaml/NXellipsometry.yaml index 9e6d9d0c10..852a62a5b2 100644 --- a/contributed_definitions/nyaml/NXellipsometry.yaml +++ b/contributed_definitions/nyaml/NXellipsometry.yaml @@ -1,7 +1,15 @@ category: application + doc: | - Ellipsometry, complex systems, up to variable angle spectroscopy. + This is the application definition describing ellipsometry experiments. + + Such experiments may be as simple as identifying how a reflected + beam of light with a single wavelength changes its polarization state, + to a variable angle spectroscopic ellipsometry experiment. + The application definition specifies optical spectroscopy (NXopt), by extending + the terms and setting specific requirements. + Information on ellipsometry is provided, e.g. in: * H. Fujiwara, Spectroscopic ellipsometry: principles and applications, @@ -35,20 +43,12 @@ doc: | Adv. Opt. Techn., (2022), https://doi.org/10.1515/aot-2022-0016 -# N_p1: -# "Number of sample parameters scanned, if you varied any of the parameters -# such as temperature, pressure, or pH, the maximal length of the arrays -# specified by NXsample/environment_conditions/SENSOR/value if it exists." -# N_time: "Number of time points measured, the length of NXsample/time_points" symbols: doc: | Variables used throughout the document, e.g. dimensions or parameters. N_spectrum: | Length of the spectrum array (e.g. wavelength or energy) of the measured data. - N_sensors: | - Number of sensors used to measure parameters that influence the sample, - such as temperature or pressure. N_measurements: | Number of measurements (1st dimension of measured_data array). This is equal to the number of parameters scanned. For example, if the experiment @@ -59,48 +59,13 @@ symbols: sample. N_incident_angles: | Number of angles of incidence of the incident beam. - N_observables: | - Number of observables that are saved in a measurement. e.g. one for - intensity, reflectivity or transmittance, two for Psi and Delta etc. This - is equal to the second dimension of the data array 'measured_data' and the - number of column names. - N_time: | - Number of time points measured, the length of NXsample/time_points -# 06/2022 -# A draft version of a NeXus application definition for ellipsometry. +# 04/2024 +# A rework of the draft version(06/2022) of a NeXus application definition for ellipsometry. -# The document has the following main elements: -# - Instrument used and is characteristics -# - Sample: Properties of the sample -# - Data: measured data, data errors -# - Derived parameters: e.g. extra parameters derived in the measurement software type: group NXellipsometry(NXopt): - - # symbols: - # doc: "Variables used throughout the document, e.g. dimensions and important parameters" - # N_wavelength: "Size of the energy or wavelength vector used, the length of - # NXinstrument/spectrometer/wavelength array" - # N_variables: "How many variables are saved in a measurement. e.g. 2 for Psi - # and Delta, 16 for Mueller matrix elements, 15 for normalized - # Mueller matrix, 3 for NCS, the length of NXsample/column_names" - # N_angles: "Number of incident angles used, the length of - # NXinstrument/angle_of_incidence array" (NXentry): - doc: | - This is the application definition describing ellipsometry experiments. - - Such experiments may be as simple as identifying how a reflected - beam of light with a single wavelength changes its polarization state, - to a variable angle spectroscopic ellipsometry experiment. - - The application definition defines: - - * elements of the experimental instrument - * calibration information if available - * parameters used to tune the state of the sample - * sample description definition: doc: | An application definition for ellipsometry. @@ -113,37 +78,24 @@ NXellipsometry(NXopt): URL where to find further material (documentation, examples) relevant to the application definition. enumeration: [NXellipsometry] - experiment_description: + title: + experiment_type: doc: | - An optional free-text description of the experiment. + Specify the type of the optical experiment. - However, details of the experiment should be defined in the specific - fields of this application definition rather than in this experiment - description. - experiment_type: + You may specify fundamental characteristics or properties in the experimental sub-type. + enumeration: [ellipsometry] + ellipsometry_experiment_type: doc: | Specify the type of ellipsometry. - enumeration: [in situ spectroscopic ellipsometry, THz spectroscopic ellipsometry, infrared spectroscopic ellipsometry, ultraviolet spectroscopic ellipsometry, uv-vis spectroscopic ellipsometry, NIR-Vis-UV spectroscopic ellipsometry, imaging ellipsometry] + enumeration: [in situ spectroscopic ellipsometry, THz spectroscopic ellipsometry, infrared spectroscopic ellipsometry, ultraviolet spectroscopic ellipsometry, uv-vis spectroscopic ellipsometry, NIR-Vis-UV spectroscopic ellipsometry, other] + ellipsometry_experiment_type_other: + exists: optional + doc: | + If the ellipsometry_experiment_type is `other`, a name should be specified here. (NXinstrument): doc: | Properties of the ellipsometry equipment. - company: - exists: optional - doc: | - Name of the company which build the instrument. - construction_year(NX_DATE_TIME): - exists: optional - doc: | - ISO8601 date when the instrument was constructed. - UTC offset should be specified. - software(NXprocess): - program: - doc: | - Commercial or otherwise defined given name of the program that was - used to generate the result file(s) with measured data and metadata. - This program converts the measured signals to ellipsometry data. If - home written, one can provide the actual steps in the NOTE subfield - here. ellipsometer_type: doc: | What type of ellipsometry was used? See Fujiwara Table 4.2. @@ -153,16 +105,17 @@ NXellipsometry(NXopt): Define which element rotates, e.g. polarizer or analyzer. enumeration: [polarizer (source side), analyzer (detector side), compensator (source side), compensator (detector side)] (NXbeam_path): - light_source(NXsource): - doc: | - Specify the used light source. Multiple selection possible. - source_type: - enumeration: [arc lamp, halogen lamp, LED, other] + #light_source(NXsource): + # doc: | + # Specify the used light source. Multiple selection possible. + # source_type: + # enumeration: [arc lamp, halogen lamp, LED, other] focussing_probes(NXlens_opt): exists: optional doc: | If focussing probes (lenses) were used, please state if the data were corrected for the window effects. + # This as well can be stated in window/aperture data_correction(NX_BOOLEAN): doc: | Were the recorded data corrected by the window effects of the @@ -172,10 +125,6 @@ NXellipsometry(NXopt): unit: NX_ANGLE doc: | Specify the angular spread caused by the focussing probes. - (NXdetector): - doc: | - Properties of the detector used. Integration time is the count time - field, or the real time field. See their definition. rotating_element(NXwaveplate): exists: optional doc: | @@ -201,39 +150,25 @@ NXellipsometry(NXopt): doc: | Specify the maximum value of revolutions of the rotating element for each measurement. - spectrometer(NXmonochromator): - exists: optional - doc: | - The spectroscope element of the ellipsometer before the detector, - but often integrated to form one closed unit. Information on the - dispersive element can be specified in the subfield GRATING. Note - that different gratings might be used for different wavelength - ranges. The dispersion of the grating for each wavelength range can - be stored in grating_dispersion. (NXsample): backside_roughness(NX_BOOLEAN): + exists: recommended doc: | Was the backside of the sample roughened? Relevant for infrared ellipsometry. - data_collection(NXprocess): + (NXdata): data_type: doc: | Select which type of data was recorded, for example Psi and Delta (see: https://en.wikipedia.org/wiki/Ellipsometry#Data_acquisition). It is possible to have multiple selections. Data types may also be converted to each other, e.g. a Mueller matrix contains N,C,S data - as well. This selection defines how many columns (N_observables) are - stored in the data array. + as well. enumeration: [Psi/Delta, tan(Psi)/cos(Delta), Mueller matrix, Jones matrix, N/C/S, raw data] - # column_names: - # doc: | - # Please list in this array the column names used in your actual data. - # That is ['Psi', 'Delta'] or ['MM1', 'MM2', 'MM3', ..., 'MM16] for - # a full Mueller matrix, etc. - # dimensions: - # rank: 1 - # dim: [[1, N_observables]] + + + # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ # e5c086ad7e50f420614c5465adc29a57a2b25cc1be09659435b3f1592c0f941a diff --git a/contributed_definitions/nyaml/NXraman.yaml b/contributed_definitions/nyaml/NXraman.yaml new file mode 100644 index 0000000000..f155d34739 --- /dev/null +++ b/contributed_definitions/nyaml/NXraman.yaml @@ -0,0 +1,592 @@ +category: application +doc: | + An application definition for Raman spectrocopy experiments. + + Such experiments may be as simple a single Raman spectrum from spontanous + Raman scattering and range to Raman imaging Raman spectrometer, + surface- and tip-enhanced Raman techniques, x-Ray Raman scattering, as well + as resonant Raman scattering phenomena or multidimenional Raman spectra (i.e. + varying temperature, pressure, electric field, ....) + + The application definition contains two things: + 1. The structures in the application definition of NXopt: + * Instrument and data calibrations + * Sensors for sample or beam conditions + + AND + + 2. The strucutres specified and extended in NXraman: + * description of the experiment type + * descroption of the setup's meta data and optical elements (source, monochromator, detector, waveplate, lens, etc.) + * description of beam properties and their relations to the sample + * sample information + + Information on Raman spectroscopy are provided in: + + General + + * Lewis, Ian R.; Edwards, Howell G. M. + Handbook of Raman Spectroscopy + ISBN 0-8247-0557-2 + + Raman scattering selection rules + + * Dresselhaus, M. S.; Dresselhaus, G.; Jorio, A. + Group Theory - Application to the Physics ofCondensed Matter + ISBN 3540328971 + + Semiconductors + + * Manuel Cardona + Light Scattering in Solids I + eBook ISBN: 978-3-540-37568-5 + DOI: https://doi.org/10.1007/978-3-540-37568-5 + + * Manuel Cardona, Gernot Güntherodt + Light Scattering in Solids II + eBook ISBN: 978-3-540-39075-6 + DOI: https://doi.org/10.1007/3-540-11380-0 + + * See as well other Books from the "Light Scattering in Solids" series: + III: Recent Results + IV: Electronic Scattering, Spin Effects, SERS, and Morphic Effects + V: Superlattices and Other Microstructures + VI: Recent Results, Including High-Tc Superconductivity + VII: Crystal-Field and Magnetic Excitations + VIII: Fullerenes, Semiconductor Surfaces, Coherent Phonons + IX: Novel Materials and Techniques + + Glasses, Liquids, Gasses, ... + + Review articles: + Stimulated Raman scattering, Coherent anti-Stokes Raman scattering, + Surface-enhanced Raman scattering, Tip-enhanced Raman scattering + * https://doi.org/10.1186/s11671-019-3039-2 +symbols: + doc: | + Variables used throughout the document, e.g. dimensions or parameters. + N_spectrum: | + Length of the spectrum array (e.g. wavelength or energy) of the measured + data. + N_measurements: | + Number of measurements (1st dimension of measured_data array). This is + equal to the number of parameters scanned. For example, if the experiment + was performed at three different temperatures and two different pressures + N_measurements = 2*3 = 6. + N_detection_angles: | + Number of detection angles of the beam reflected or scattered off the + sample. + N_incident_angles: | + Number of angles of incidence of the incident beam. + N_scattering_configurations: | + Number of scattering configurations used in the measurement. + It is 1 for only parallel polarization meausement, 2 for parallel and cross + polarization measurement or larger, if i.e. the incident and scattered photon + direction is varied. + #N_incident_wavelengths: | + # Number of the incident wavelen + #N_incident_beams: | + # to be done.... + +# 04/2024 +# A draft version of a NeXus application definition for Raman spectroscopy. + +type: group +NXraman(NXopt): + (NXentry): + definition: + doc: | + An application definition for Raman spectrsocopy. + \@version: + doc: | + Version number to identify which definition of this application + definition was used for this entry/data. + \@url: + doc: | + URL where to find further material (documentation, examples) relevant + to the application definition. + enumeration: [NXraman] + title: + experiment_type: + doc: | + Specify the type of the optical experiment. + + You may specify fundamental characteristics or properties in the experimental sub-type. + enumeration: [Raman spectroscopy] + raman_experiment_type: + doc: | + Specify the type of Raman experiment. + enumeration: [in situ Raman spectroscopy, resonant Raman spectroscopy, non-resonant Raman spectroscopy, Raman imaging, Tip-enhanced Raman spectroscopy (TERS), Surface-enhanced Raman spectroscopy (SERS), Surface plasmon polariton enhanced Raman scattering (SPPERS), Hyper Raman spectroscopy (HRS), Stimulated Raman spectroscopy (SRS), Inverse Raman spectroscopy (IRS), Coherent anti-Stokes Raman spectroscopy (CARS), other] + raman_experiment_type_other: + exists: optional + doc: | + If the raman_experiment_type is `other`, a name should be specified here. + (NXinstrument): + doc: | + Metadata of the setup, its optical elements and physical properites which + defines the Raman measurement. + scattering_configuration(NX_CHAR): + doc: | + Scattering configuration as defined by the porto notation by three + states, which are othogonal to each other. Example: z(xx)z for + parallel polarized backscattering configuration. + + See: + https://www.cryst.ehu.es/cgi-bin/cryst/programs/nph-doc-raman + + A(BC)D + + A = The propagation direction of the incident light (k_i) + B = The polarization direction of the incident light (E_i) + C = The polarization direction of the scattered light (E_s) + D = The propagation direction of the scattered light (k_s) + + An orthogonal base is assumed. + Linear polarized light is displayed by e.g. "x","y" or "z" + Unpolarized light is displayed by "." + For non-orthogonal vectors, use the attribute porto_notation_vectors. + \@porto_notation_vectors(NX_NUMBER): + # unit: NX_LENGTH + doc: | + Scattering configuration as defined by the porto notation given by + respective vectors. + + Vectors in the porto notation are defined as for A, B, C, D above. + Linear light polarization is assumed. + dimensions: + rank: 3 + doc: | + 3 x 4 Matrix, which lists the porto notation vectors A, B, C, D. + A has to be perpendicular to B and C perpendicular to D. + dim: [[1, 4], [2, 3], [3, N_scattering_configurations]] + beam_incident(NXbeam): + doc: | + Beam which is incident to the sample. + wavelength(NX_NUMBER): + + + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 80b03b96b60b3c124d11d834654b3e57e09716088e8dca121f7903148c7b06e3 +# +# +# +# +# +# +# +# +# Variables used throughout the document, e.g. dimensions or parameters. +# +# +# +# An application definition for Raman spectrocopy experiments. +# +# Information on Raman spectroscopy are provided in: +# +# General +# * Lewis, Ian R.; Edwards, Howell G. M. +# Handbook of Raman Spectroscopy +# ISBN 0-8247-0557-2 +# +# Raman scattering selection rules +# * Dresselhaus, M. S.; Dresselhaus, G.; Jorio, A. +# Group Theory - Application to the Physics ofCondensed Matter +# ISBN 3540328971 +# +# Semiconductors +# * Manuel Cardona +# Light Scattering in Solids I +# eBook ISBN: 978-3-540-37568-5 +# DOI: https://doi.org/10.1007/978-3-540-37568-5 +# +# * Manuel Cardona, Gernot Güntherodt +# Light Scattering in Solids II +# eBook ISBN: 978-3-540-39075-6 +# DOI: https://doi.org/10.1007/3-540-11380-0 +# +# * See as well other Books from the "Light Scattering in Solids" series: +# III: Recent Results +# IV: Electronic Scattering, Spin Effects, SERS, and Morphic Effects +# V: Superlattices and Other Microstructures +# VI: Recent Results, Including High-Tc Superconductivity +# VII: Crystal-Field and Magnetic Excitations +# VIII: Fullerenes, Semiconductor Surfaces, Coherent Phonons +# IX: Novel Materials and Techniques +# +# Glasses, Liquids, Gasses, ... +# +# Review articles: +# Stimulated Raman scattering, Coherent anti-Stokes Raman scattering, +# Surface-enhanced Raman scattering, Tip-enhanced Raman scattering +# * https://doi.org/10.1186/s11671-019-3039-2 +# +# +# +# This is the application definition describing Raman spectroscopy experiments. +# +# Such experiments may be as simple a single Raman spectrum from spontanous +# Raman scattering and range to Raman imaging Raman spectrometer, +# surface- and tip-enhanced Raman techniques, x-Ray Raman scattering, as well +# as resonant Raman scattering phenomena or multidimenional Raman spectra (i.e. +# varying temperature, pressure, electric field, ....) +# +# The application definition defines: +# +# * elements of the experimental instrument +# * calibration information if available +# * parameters used to tune the state of the sample +# * sample description +# +# +# +# An application definition for ellipsometry. +# +# +# +# Version number to identify which definition of this application +# definition was used for this entry/data. +# +# +# +# +# URL where to find further material (documentation, examples) relevant +# to the application definition. +# +# +# +# +# +# +# +# +# An optional free-text description of the experiment. +# +# However, details of the experiment should be defined in the specific +# fields of this application definition rather than in this experiment +# description. +# +# +# +# +# Specify the type of Raman measurement. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Properties of the Instruments used for Raman instrumeasurements. +# +# +# +# Name of the company which build the instrument. +# +# +# +# +# ISO8601 date when the instrument was constructed. +# UTC offset should be specified. +# +# +# +# +# +# Commercial or otherwise defined given name of the program that was +# used to generate the result file(s) with measured data and metadata. +# This program converts the measured signals to Raman data. If +# home written, one can provide the actual steps in the NOTE subfield +# here. +# +# +# +# +# +# Which indicent wavelength was used for e.g. a laser source. +# For multiple excitation wavelengths, please state the specific discret +# wavelengths (i.e. for dye laser) or the specific contnious range +# (i.e for white light laser source) +# +# +# +# +# +# Scattering configuration as defined by the porto notation by three +# states, which are othogonal to each other. Example: z(xx)z for +# parallel polarized backscattering configuration. +# +# See: +# https://www.cryst.ehu.es/cgi-bin/cryst/programs/nph-doc-raman +# +# A(BC)D +# +# A = The propagation direction of the incident light (k_i) +# B = The polarization direction of the incident light (E_i) +# C = The polarization direction of the scattered light (E_s) +# D = The propagation direction of the scattered light (k_s) +# +# An orthogonal base is assumed. +# Linear polarized light is displayed by e.g. "x","y" or "z" +# Unpolarized light is displayed by "." +# +# +# +# +# Scattering configuration as defined by the porto notation given by +# respective vectors. +# +# Vectors in the porto notation are defined as for A, B, C, D above. +# Linear light polarization is assumed. +# +# +# +# 3 x 4 Matrix, which lists the porto notation vectors A, B, C, D. +# A has to be perpendicular to B and C perpendicular to D. +# +# +# +# +# +# +# +# +# +# Specify the used light source. Multiple selection possible. +# +# +# +# +# +# +# +# +# +# +# +# +# This is the optical element used for the incident light in the Raman +# scattering process. +# +# This can be for example a simple lens or microscope +# objective. +# +# +# +# +# +# +# +# +# +# +# +# +# The numerical aperture of the used incident light optics. +# +# +# +# +# +# This is the optical element used for the incident light in the Raman +# scattering process. +# +# This can be for example a simple lens or microscope +# objective. +# +# +# +# +# +# +# +# +# +# +# +# +# +# The numerical aperture of the used incident light optics. +# +# +# +# +# +# Properties of the detector used. Integration time is the count time +# field, or the real time field. See their definition. +# +# +# +# +# Device for the manipulation of the state of light which is a half wave +# plate. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Physical principle of the polarization filter used to create a +# defined incident or scattered light state. +# +# +# +# +# +# +# +# +# +# +# +# Specific name or type of the polarizer used. +# +# For example: Glan-Thompson, Glan-Taylor, Rochon Prism, Wollaston +# Polarizer... +# +# +# +# +# +# Type of laserline filter used to supress the laser, if measurements +# close to the laserline are performed. +# +# +# +# +# +# +# +# +# +# +# Design wavelength for the laser line filter. +# +# +# +# +# Steepness of the filter by normal incidence of the light as defined +# by 10% - 90% transmittance of the respective filter. +# +# +# +# +# +# Designed supression strength of the laserline at optimal condition +# given in orders of magnitude. +# +# +# +# +# +# Properties of the rotating element defined in +# 'instrument/rotating_element_type'. +# +# +# +# Define how many revolutions of the rotating element were averaged +# for each measurement. If the number of revolutions was fixed to a +# certain value use the field 'fixed_revolutions' instead. +# +# +# +# +# Define how many revolutions of the rotating element were taken +# into account for each measurement (if number of revolutions was +# fixed to a certain value, i.e. not averaged). +# +# +# +# +# Specify the maximum value of revolutions of the rotating element +# for each measurement. +# +# +# +# +# +# The spectroscope element of the ellipsometer before the detector, +# but often integrated to form one closed unit. Information on the +# dispersive element can be specified in the subfield GRATING. Note +# that different gratings might be used for different wavelength +# ranges. The dispersion of the grating for each wavelength range can +# be stored in grating_dispersion. +# +# +# +# +# +# +# +# Was the backside of the sample roughened? Relevant for infrared +# ellipsometry. +# +# +# +# +# +# +# Select which type of data was recorded, for example a simple spectrum +# with intensity vs. Raman shift, CCD image or a set of spectra with +# probe, reference and background signals for pump beam on and off. +# +# +# +# +# +# +# +# +# +# From 229774c56fb710bb1d9008afb49e00be402c7578 Mon Sep 17 00:00:00 2001 From: RubelMozumder <32923026+RubelMozumder@users.noreply.github.com> Date: Fri, 3 May 2024 10:15:45 +0200 Subject: [PATCH 0677/1012] Update appdef for nxsts (#182) * Repositioning the several NXdata and including analytical_data NXdata. * update NXsts. * current_gain data type in NXsts and Name in NXfabrication * ci/cd * fix opt. * fix opt. * Doc for NXdata * Fixing error coming from nexus parser in nomad. * Version in NXfabrication. * Resolve conundrum between name and version. * regen NXsts.yaml. * docs. * update docs in NXfabrication. * update docs in NXfabrication. * Updating the NXenviroment docs. * update NXenvironment docs. --- .../NXfabrication.nxdl.xml | 8 +- contributed_definitions/NXlockin.nxdl.xml | 16 +- contributed_definitions/NXsts.nxdl.xml | 318 +++++----- .../nyaml/NXfabrication.yaml | 63 ++ contributed_definitions/nyaml/NXlockin.yaml | 2 +- contributed_definitions/nyaml/NXsts.yaml | 545 ++++++++++-------- 6 files changed, 572 insertions(+), 380 deletions(-) diff --git a/contributed_definitions/NXfabrication.nxdl.xml b/contributed_definitions/NXfabrication.nxdl.xml index dd1f7f5dce..d0f5c0f0e9 100644 --- a/contributed_definitions/NXfabrication.nxdl.xml +++ b/contributed_definitions/NXfabrication.nxdl.xml @@ -32,8 +32,14 @@ - Version or model of the component named by the manufacturer. + Version or model of the component named by the manufacturer. + + + If different versions exist are possible, the value in this field should be made specific enough to resolve the version. + + + diff --git a/contributed_definitions/NXlockin.nxdl.xml b/contributed_definitions/NXlockin.nxdl.xml index 2484b5007c..f72a279d4c 100644 --- a/contributed_definitions/NXlockin.nxdl.xml +++ b/contributed_definitions/NXlockin.nxdl.xml @@ -1,10 +1,10 @@ - + - + Base classes definition for lock in devices. @@ -70,8 +70,8 @@ - The input signal (STS signal) will be demodulated, in order to determine the amplitude - and phase at the frequency set in the Frequency field or harmonics, such as current, + The input signal (STS signal) will be demodulated, in order to determine the amplitude + and phase at the frequency set in the Frequency field or harmonics, such as current, bias, et.al. @@ -126,7 +126,7 @@ (foreach DemodulatorChannels) - + Reference phase for the sine on the demodulated signal with respect to the modulation signal. (foreach DemodulatorChannels) diff --git a/contributed_definitions/NXsts.nxdl.xml b/contributed_definitions/NXsts.nxdl.xml index 01f14143b6..5f778c9c35 100644 --- a/contributed_definitions/NXsts.nxdl.xml +++ b/contributed_definitions/NXsts.nxdl.xml @@ -1,10 +1,10 @@ - + - - + + + Application definition for temperature-dependent IV curve measurements - #2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the + #2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the STM image mode in the future with a focus on bias spectroscopy in Scanning Tunneling Microscopy. In this application definition, times should be specified always together with a UTC offset. @@ -34,10 +37,10 @@ measurements. For this, a temperature is set. After reaching the temperature, a voltage sweep is performed. For each voltage, a current is measured. Then, the next desired temperature is set and an IV measurement is performed. - The data can be visualized in a tensor with: + The data can be visualized in a tensor with: I (NXsensor_C, NXsoftware_Read_offset, NXcircuit) - parameters: - V has (NXsource+offset, NXsoftware_Scan_offset, NXsensor_V, NXcircuit) + parameters: + V has (NXsource+offset, NXsoftware_Scan_offset, NXsensor_V, NXcircuit) T has (NXsource, NXsoftware_Scan_offset, NXsensor_T) x has (NXsoftware_Scan_offset) y has (NXsoftware_Scan_offset) @@ -51,16 +54,16 @@ - Name of the experiment where the application is applicable. + Name of the experiment where the application is applicable. - - + + - The equipments and techniques as well as the parameter settings and reference signals + The equipments and techniques as well as the parameter settings and reference signals are used during the experiments used in Scanning Tunneling Microscopy (STM). - Path to storage of output files. + Path to storage of output files. (e.g. Path C:\Users\SPM-PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis-Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711) - Descriptive comments for this experiment, added by the experimenter, coming from the - output file. (e.g. Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, locked Au(111), + Descriptive comments for this experiment, added by the experimenter, coming from the + output file. (e.g. Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, locked Au(111), 50pA, 100 mV set point, 1mV DCA, 973Hz,138 1st H, -84 2nd H) @@ -110,17 +113,12 @@ any or specifique 'harware' and 'software'?--> Type of software used in SPM experiments, such as software version serial number, UI and RT probe release method. (e.g. SW Version Generic 5e -- RT Release 10771) - - - Version of the software. - - - The Amplifier description that improves or helps to determine tunnel current (current + The Amplifier description that improves or helps to determine tunnel current (current between tip and bias). @@ -133,8 +131,8 @@ crosstalk_compensation: Current amplifier> Capacitive cross-talk compensation: Y @@ -145,12 +143,12 @@ hardware: Lock-in Amplifier>Hardware: Nanonis--> - The signal is modulated by adding the frequency of the sine modulation. The - modulation frequency spans can be from 10 mHz to 40 kHz, corresponding to the output filter - cut-off range. When dealing with harmonics, it's essential to ensure that the - harmonic frequencies remain below ~100 kHz, which aligns with the input filter cut-off. - Be mindful that hardware filters might impact the amplitude as the signal approaches - their cut-off frequencies." (e.g. 973E+0) + The signal is modulated by adding the frequency of the sine modulation. The + modulation frequency spans can be from 10 mHz to 40 kHz, corresponding to the output filter + cut-off range. When dealing with harmonics, it's essential to ensure that the + harmonic frequencies remain below ~100 kHz, which aligns with the input filter cut-off. + Be mindful that hardware filters might impact the amplitude as the signal approaches + their cut-off frequencies." (e.g. 973E+0) @@ -164,24 +162,24 @@ hardware: Lock-in Amplifier>Hardware: Nanonis--> will be demodulated, in order to determine the amplitude and phase at the frequency set in the Frequency field (“4”) or harmonics.--> - The input signal (STS signal) will be demodulated, in order to determine the amplitude - and phase at the frequency set in the Frequency field or harmonics, such as current, + The input signal (STS signal) will be demodulated, in order to determine the amplitude + and phase at the frequency set in the Frequency field or harmonics, such as current, bias, et.al. - + N denotes 1 or 2. The order of the harmonic oscillation to be detected in the demodulated - signal should be considered relative to the modulation frequency. When dealing with + signal should be considered relative to the modulation frequency. When dealing with higher harmonics, it's essential to ensure that their frequencies do not surpass the analogue signal bandwidth (e.g. harmonic_order_1). - + Reference phase for the sine on the demodulated signal with respect to the modulation signal. The determined phase is displayed with respect to the @@ -192,27 +190,30 @@ set in the Frequency field (“4”) or harmonics.--> +doc: Bias Spectroscopy>Lock-In run FALSE # Select whether to set the Lock-In to run +during the measurement. When using this feature, make sure the Lock-In is configured +correctly and settling times are set to twice the Lock-In period at least. This +option is ignored when Lock-In is already running. This option is disabled if the +Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline +segment editor is set.--> + + Bias voltage applied to the sample. + Applied a voltage between tip and sample. @@ -236,13 +237,13 @@ doc: Same directional representation as bias. (e.g. 1E-3)--> - Temperature of liquid helium cryostat. Note: At least one field from + Temperature of liquid helium cryostat. Note: At least one field from stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp must be provided. - Temperature of liquid nitrogen shield. Temperature 3 (K) (e.g 78.00000E+0). Note: At + Temperature of liquid nitrogen shield. Temperature 3 (K) (e.g 78.00000E+0). Note: At least one field from stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp must be provided. @@ -259,8 +260,8 @@ output_slew_rate(NX_NUMBER): doc: The rate at which the one of the signal changes when ramping to the starting point. (V/s) (e.g. Inf)--> - Configuration for piezoelectric scanner used to move tip along X and Y direction. The - material of the Piezoelectric scanner composed of polycrystalline solids and sensitive to + Configuration for piezoelectric scanner used to move tip along X and Y direction. The + material of the Piezoelectric scanner composed of polycrystalline solids and sensitive to applied voltage. @@ -270,9 +271,9 @@ doc: The rate at which the one of the signal changes when ramping to the startin - N denotes X or Y or Z. There are three parameters in the X, Y, and Z directions, - along with three available controls: Calibration (m/V), Range (m), and HV gain. Only - two of these parameters are required to define the calibration. Consequently, when any + N denotes X or Y or Z. There are three parameters in the X, Y, and Z directions, + along with three available controls: Calibration (m/V), Range (m), and HV gain. Only + two of these parameters are required to define the calibration. Consequently, when any value is changed, one of the other values will be automatically updated. (e.g. calib_X = 3.8E-9) @@ -286,7 +287,7 @@ doc: The rate at which the one of the signal changes when ramping to the startin - N denotes X or Y. There are 2 parameters in X and Y directions, and tilt needs to be + N denotes X or Y. There are 2 parameters in X and Y directions, and tilt needs to be adjusted according to the actual surface. (in degrees, first order correction). @@ -299,17 +300,17 @@ doc: The rate at which the one of the signal changes when ramping to the startin - N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, - you can enter the 2nd order piezo characteristics to compensate for it. The - following equation shows the interpretation of the 2nd order correction parameter: - For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: + N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, + you can enter the 2nd order piezo characteristics to compensate for it. The + following equation shows the interpretation of the 2nd order correction parameter: + For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx is the 2nd order correction. (V/m^2). (e.g. 0E+0) - N denotes X, Y or Z. There are 3 parameters in X, Y and Z directions. Define the + N denotes X, Y or Z. There are 3 parameters in X, Y and Z directions. Define the drift speed for all three axes. When the compensation is on, the piezos will start to move at that speed. (e.g. 0E+0) @@ -320,16 +321,14 @@ doc: The rate at which the one of the signal changes when ramping to the startin - + - Describes an environment setup for a temperature-dependent IV measurement experiment. - The temperature and voltage must be present as independently scanned controllers and - the current sensor must also be present with its readings. + An environmental setup to measure the tunneling current due to different tip-sample biases. - This is set-point of tip current (in the constant current mode should be equal to set-point, + This is set-point of tip current (in the constant current mode should be equal to set-point, in the constant height mode means the real tunnelling current between tip and sample). @@ -339,7 +338,7 @@ doc: The rate at which the one of the signal changes when ramping to the startin - + @@ -365,7 +364,7 @@ doc: The rate at which the one of the signal changes when ramping to the startin - Indicate the relative tip position z between tip and sample. The tip position can also + Indicate the relative tip position z between tip and sample. The tip position can also be varied when the z_controller is not running. (e.g. 130.5E-9) @@ -405,8 +404,8 @@ parameters for a measurement at a single location during the scan--> - The Z position is recorded and averaged for a certain duration both before and - after the sweep. After the initial Z averaging time, if "Z-Controller to Hold" + The Z position is recorded and averaged for a certain duration both before and + after the sweep. After the initial Z averaging time, if "Z-Controller to Hold" is selected, the Z-Controller is set to hold mode, and the tip is positioned at the previously averaged Z position (adjusted by the Z offset). (e.g. 100E-3) @@ -415,15 +414,15 @@ parameters for a measurement at a single location during the scan--> - The bandwidth of the Hardware and/or Software is instrument specific. + The bandwidth of the Hardware and/or Software is instrument specific. For example, Nanonis Generic 5 has 'RT Frequency' (e.g. 20E+3). - The Signals Period represents the rate at which signals are transferred to - the host computer, which operates the control software. This rate may - be 10 times lower than the sampling rate, as the real-time engine internally + The Signals Period represents the rate at which signals are transferred to + the host computer, which operates the control software. This rate may + be 10 times lower than the sampling rate, as the real-time engine internally oversamples the signal. If desired, you may have the option to reduce the oversampling to 1, enabling higher frequency resolution in the Spectrum Analyzer. (e.g. 10) @@ -475,7 +474,7 @@ parameters for a measurement at a single location during the scan--> - Also clarify the frame for the ROI of the scan in lab frame, the middle of the lab + Also clarify the frame for the ROI of the scan in lab frame, the middle of the lab frame is (0, 0), and positive in x means right and in y means up. @@ -527,56 +526,61 @@ should be NXcollection not NXprocess--> - Link to target:/NXentry/NXinstrument/stm_head_temp + Link to target: /NXentry/NXinstrument/stm_head_temp - Link to target:/NXentry/NXinstrument/cryo_bottom_temp + Link to target: /NXentry/NXinstrument/cryo_bottom_temp - Link to target:/NXentry/NXinstrument/temp_cryo_shield + Link to target: /NXentry/NXinstrument/temp_cryo_shield - Link to target:/NXentry/NXinstrument/NXlock_in/modulation_signal + Link to target: /NXentry/NXinstrument/NXlock_in/modulation_signal - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/NXintegration_time + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/NXintegration_time - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/number_of_sweeps + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/number_of_sweeps - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/sweep_start + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/sweep_start - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/sweep_end + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/sweep_end - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/num_pixel + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/num_pixel - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_avg_time + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_avg_time - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/rt_frequency + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/rt_frequency - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/signals_oversampling + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/signals_oversampling - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/acquisition_period + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/acquisition_period - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/animations_period + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/animations_period - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/indicators_period + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/indicators_period - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/measurements_period + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/measurements_period @@ -654,25 +665,25 @@ as all of the bellow are linked--> - Link to target:/NXentry/NXinstrument/NXsample_bias/bias + Link to target: /NXentry/NXinstrument/NXsample_bias/bias - Link to target:/NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current + Link to target: /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current - Link to target:/NXentry/NXnstrument/NXsample_bias/bias_calibration + Link to target: /NXentry/NXnstrument/NXsample_bias/bias_calibration - Link to target:/NXentry/NXinstrument/NXsample_bias/bias_offset + Link to target: /NXentry/NXinstrument/NXsample_bias/bias_offset - Link to target:/NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_calibration + Link to target: + /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_calibration - Link to target:/NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_offset + Link to target: + /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_offset - Link to target:/NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_gain + Link to target: + /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_gain - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_offset + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_offset - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/settling_time + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/settling_time - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_ccontroller_hold + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_ccontroller_hold - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/record_final_z + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/record_final_z - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/first_settling_time + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/first_settling_time - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/end_settling_time + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/end_settling_time - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_control_time + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_control_time - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/max_slew_rate + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/max_slew_rate - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/backward_sweep + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/backward_sweep - + - Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/controller_name + Link to target: + /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/controller_name - Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/controller_status + Link to target: + /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/controller_status - Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/set_point + Link to target: + /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/set_point - Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/p_gain + Link to target: + /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/p_gain - Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/i_gain + Link to target: + /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/i_gain - + - Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/time_const + Link to target: + /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/time_const - Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/tip_lift + Link to target: + /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/tip_lift - - Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/switchoff_delay + Link to target: + /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/switchoff_delay @@ -857,11 +887,9 @@ is switched off, it doesn't switch off immediately but continues to run for the li_demod_[1;2]_[X/Y]_[-;bwd;filt;bwd_filt] current_[-;bwd;filt;bwd_filt] temperature - x - y - z - - - - - - - - + + + Plot for a single point (x,y) with I vs. V curve. + + + + + + Line scan with multiple I vs. V curves for different single (x,y) co-ordinates. + + + + + + Plot for current(I) curve in the 2D space of (position(x), bias(V)) which can be + derived from the `line_scan` plot. + + + + + + Mesh scan with 2D slices of the above alternative plot for other y co-ordinates. + diff --git a/contributed_definitions/nyaml/NXfabrication.yaml b/contributed_definitions/nyaml/NXfabrication.yaml index 387e4a4649..8e30efd6c3 100644 --- a/contributed_definitions/nyaml/NXfabrication.yaml +++ b/contributed_definitions/nyaml/NXfabrication.yaml @@ -9,6 +9,10 @@ NXfabrication(NXobject): model(NX_CHAR): doc: | Version or model of the component named by the manufacturer. + \@version: + type: NX_CHAR + doc: | + If different versions exist are possible, the value in this field should be made specific enough to resolve the version. identifier(NX_CHAR): doc: | Ideally, (globally) unique persistent identifier, i.e. @@ -17,3 +21,62 @@ NXfabrication(NXobject): doc: | Free-text list with eventually multiple terms of functionalities which the component offers. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 6b41658298bdab15f08057e91686e6853e1c1adf0460309bc82194cf30151ac1 +# +# +# +# +# +# Details about a component as it is defined by its manufacturer. +# +# +# +# Company name of the manufacturer. +# +# +# +# +# Version or model of the component named by the manufacturer. +# +# +# +# If different versions exist are possible, the value in this field should be made specific enough to resolve the version. +# +# +# +# +# +# +# Ideally, (globally) unique persistent identifier, i.e. +# a serial number or hash identifier of the component. +# +# +# +# +# Free-text list with eventually multiple terms of +# functionalities which the component offers. +# +# +# diff --git a/contributed_definitions/nyaml/NXlockin.yaml b/contributed_definitions/nyaml/NXlockin.yaml index b59b69a916..f06cdc0654 100644 --- a/contributed_definitions/nyaml/NXlockin.yaml +++ b/contributed_definitions/nyaml/NXlockin.yaml @@ -81,7 +81,7 @@ NXlockin(NXobject): Switch on/off the Sync filter on the demodulated signals (X,Y) on or off. (foreach DemodulatorChannels) ref_phase_N(NX_NUMBER): - unit: NX_FREQUENCY + unit: NX_ANGLE doc: | Reference phase for the sine on the demodulated signal with respect to the modulation signal. (foreach DemodulatorChannels) diff --git a/contributed_definitions/nyaml/NXsts.yaml b/contributed_definitions/nyaml/NXsts.yaml index 03e16760e9..ee58feebfd 100644 --- a/contributed_definitions/nyaml/NXsts.yaml +++ b/contributed_definitions/nyaml/NXsts.yaml @@ -19,6 +19,8 @@ doc: | y has (NXsoftware_Scan_offset) z has (NXsoftware_Scan_offset) +# 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the + # 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the type: group NXsts(NXsensor_scan): @@ -71,10 +73,6 @@ NXsts(NXsensor_scan): doc: | Type of software used in SPM experiments, such as software version serial number, UI and RT probe release method. (e.g. SW Version Generic 5e -- RT Release 10771) - version: - exists: optional - doc: | - Version of the software. # amplification: Current amplifier> factor (V/V): 1E-10 # crosstalk_compensation: Current amplifier> Capacitive cross-talk compensation: Yes/No @@ -173,6 +171,8 @@ NXsts(NXsensor_scan): # Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline # segment editor is set. sample_bias(NXiv_bias): + doc: | + Bias voltage applied to the sample. bias(NX_NUMBER): unit: NX_VOLTAGE doc: | @@ -276,11 +276,8 @@ NXsts(NXsensor_scan): doc: | Use the button to enable or disable the drift compensation. (e.g. FALSE) (NXenvironment): - exists: optional doc: | - Describes an environment setup for a temperature-dependent IV measurement experiment. - The temperature and voltage must be present as independently scanned controllers and - the current sensor must also be present with its readings. + An environmental setup to measure the tunneling current due to different tip-sample biases. current_sensor(NXsensor): exists: optional current(NX_NUMBER): @@ -294,7 +291,7 @@ NXsts(NXsensor_scan): Value of calibration that comes as A/V. current_offset(NX_NUMBER): unit: NX_CURRENT - current_gain: + current_gain(NX_NUMBER): unit: NX_UNITLESS calibration_time(NX_DATE_TIME): exists: optional @@ -455,59 +452,64 @@ NXsts(NXsensor_scan): exists: optional unit: NX_TEMPERATURE doc: | - Link to target:/NXentry/NXinstrument/stm_head_temp + Link to target: /NXentry/NXinstrument/stm_head_temp # Temperature 2>link to Temperature 2 (K) - # Temperature of bottom of LHe helium cryostat. cryo_bottom_temp(NX_NUMBER): exists: optional unit: NX_TEMPERATURE doc: | - Link to target:/NXentry/NXinstrument/cryo_bottom_temp + Link to target: /NXentry/NXinstrument/cryo_bottom_temp # Temperature 3>link to Temperature 3 (K) - # Temperature of LN2 nitrogen shield. cryo_shield_temp(NX_NUMBER): exists: optional unit: NX_TEMPERATURE doc: | - Link to target:/NXentry/NXinstrument/temp_cryo_shield + Link to target: /NXentry/NXinstrument/temp_cryo_shield # Lock-in>link to Modulated signal Bias (V) (e.g. 1E-3) # Applied modulation to the bias voltage. modulation_signal: exists: optional unit: NX_VOLTAGE doc: | - Link to target:/NXentry/NXinstrument/NXlock_in/modulation_signal + Link to target: /NXentry/NXinstrument/NXlock_in/modulation_signal # link to Integration time (s) (e.g. 150E-6) # Time during which the spectroscopy data are acquired and averaged. integration_time(NX_NUMBER): unit: NX_TIME doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/NXintegration_time + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/NXintegration_time # link to Bias Spectroscopy>Number of sweeps (e.g. 100) Number of sweeps to measure and average. number_of_sweeps(NX_NUMBER): unit: NX_UNITLESS exists: optional doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/number_of_sweeps + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/number_of_sweeps # link to Bias Spectroscopy>Sweep Start (V) (e.g. -300E-3) # The first bias values of the sweep. sweep_start(NX_NUMBER): unit: NX_VOLTAGE doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/sweep_start + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/sweep_start # link to Bias Spectroscopy>Sweep End (V) (e.g. 300E-3) # The last bias values of the sweep. sweep_end(NX_NUMBER): unit: NX_VOLTAGE doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/sweep_end + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/sweep_end # link to Bias Spectroscopy>Num Pixel (e.g. 4096) # Define the sweep number of points, that is, the maximum spectrum resolution eq. Bias window divide by Num Pixel. num_pixel(NX_NUMBER): doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/num_pixel + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/num_pixel # link to Bias Spectroscopy>Z Avg time (s) (e.g. 100E-3) # Duration over which the Z # position is recorded and averaged before and after the sweep (the latter only if Record @@ -517,14 +519,16 @@ NXsts(NXsensor_scan): z_avg_time(NX_NUMBER): unit: NX_TIME doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_avg_time + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_avg_time # link to SoftwareMain>RT Frequency (Hz) (e.g. 20E+3) # The bandwitdh of the # Hardware and/or Software rt_frequency(NX_NUMBER): unit: NX_FREQUENCY doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/rt_frequency + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/rt_frequency # link to SoftwareMain>Signals Oversampling (e.g. 10) # (Signals Periods) # The Signals Period is the rate at which the signals are transferred to the host computer @@ -534,7 +538,8 @@ NXsts(NXsensor_scan): # Spectrum Analyzer. signals_oversampling(NX_NUMBER): doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/signals_oversampling + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/signals_oversampling # link to SoftwareMain>Acquisition Period (s) (e.g. 20E-3) # Update rate for several # processes like History Graph, Auto-Approach, and for many Programming Interface functions. @@ -545,7 +550,8 @@ NXsts(NXsensor_scan): unit: NX_TIME exists: optional doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/acquisition_period + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/acquisition_period # link to SoftwareMain>Animations Period (s) (e.g. 20E-3) # Update rate of animated # graphical indicators. These are e.g. some graphs & sliders. A reasonable value is @@ -556,7 +562,8 @@ NXsts(NXsensor_scan): unit: NX_TIME exists: optional doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/animations_period + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/animations_period # link to SoftwareMain>Indicators Period (s) (e.g. 300E-3) # Update rate of digital # indicators, e.g. the numbers displayed besides each slider. Here, 3 updates per @@ -565,7 +572,8 @@ NXsts(NXsensor_scan): indicators_period(NX_NUMBER): unit: NX_TIME doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/indicators_period + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/indicators_period # link to SoftwareMain>Measurements Period (s) (e.g. 500E-3) # The Measurements # period is the integration time for precise measurements (averaging over specified period), @@ -577,7 +585,8 @@ NXsts(NXsensor_scan): exists: optional unit: NX_TIME doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/measurements_period + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/measurements_period # TODO: Later fix REPRODUCIBILITY_indicator # as all of the bellow are linked @@ -588,24 +597,24 @@ NXsts(NXsensor_scan): bias(NX_NUMBER): unit: NX_VOLTAGE doc: | - Link to target:/NXentry/NXinstrument/NXsample_bias/bias + Link to target: /NXentry/NXinstrument/NXsample_bias/bias # Current>Current(NXcircuit) (A) (e.g. -5.3429E-15) # The tunneling current is displayed here. current(NX_NUMBER): unit: NX_CURRENT doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current + Link to target: /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current # Bias>Calibration(NXbias) (V/V) (e.g. 1E+0) Calibration of the Bias output. If you have # a Range switch the calibration is stored per range setting. bias_calibration(NX_NUMBER): unit: NX_UNITLESS doc: | - Link to target:/NXentry/NXnstrument/NXsample_bias/bias_calibration + Link to target: /NXentry/NXnstrument/NXsample_bias/bias_calibration bias_offset(NX_NUMBER): unit: NX_VOLTAGE doc: | - Link to target:/NXentry/NXinstrument/NXsample_bias/bias_offset + Link to target: /NXentry/NXinstrument/NXsample_bias/bias_offset # Current>Calibration(NXcircuit) (A/V) (e.g. 100E-12) # The signals voltages are converted to real world physical values according to the calibration & offset parameters: @@ -613,19 +622,22 @@ NXsts(NXsensor_scan): current_calibration(NX_NUMBER): unit: NX_CURRENT doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_calibration + Link to target: + /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_calibration # Current>Offset(NXcircuit) (A) (e.g. 16.2897E-15) # The same as "Current>Calibration (A/V)" tag current_offset(NX_NUMBER): unit: NX_CURRENT doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_offset + Link to target: + /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_offset # Current>Gain(NXcircuit) (e.g. Not switchable) # None current_gain(NX_NUMBER): unit: NX_UNITLESS doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_gain + Link to target: + /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_gain # Z offset(NXpositioner_sts) (m) (e.g. 0E+0) # Offset added to the initial averaged position # Zaver before starting to sweep. This parameter is disabled when Z-Controller to Hold is @@ -639,26 +651,30 @@ NXsts(NXsensor_scan): z_offset(NX_NUMBER): unit: NX_LENGTH doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_offset + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_offset settling_time(NX_NUMBER): unit: NX_TIME exists: optional doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/settling_time + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/settling_time # Z-Ctrl hold(NXpositioner_sts) (e.g. TRUE) # When selected, the Z-Controller is set to hold # during the pulse. This means that the controller doesn't control the Z position during the pulse. z_control_hold(NX_BOOLEAN): exists: optional doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_ccontroller_hold + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_ccontroller_hold # Final Z(NXpositioner_sts) (m) (e.g. N/A) final_z(NX_NUMBER): unit: NX_LENGTH exists: optional doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/record_final_z + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/record_final_z # Start time(NXlog) (e.g.23.11.2022 18:55:16) # Timestamp of the moment # when the acquisition starts by pressing the Start button. @@ -671,7 +687,8 @@ NXsts(NXsensor_scan): unit: NX_TIME exists: optional doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/first_settling_time + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/first_settling_time # Bias Spectroscopy>Integration time(NXbias) (s) (e.g.150E-6) # Time during which the data # are acquired and averaged. @@ -682,7 +699,8 @@ NXsts(NXsensor_scan): unit: NX_TIME exists: optional doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/end_settling_time + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/end_settling_time # Bias Spectroscopy>Z control time(NXbias) (s) (e.g.200E-3) # Time during which the # Z-Controller is enabled once a sweep has finished. When averaging multiple sweeps @@ -694,7 +712,8 @@ NXsts(NXsensor_scan): unit: NX_TIME exists: optional doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_control_time + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_control_time # Bias Spectroscopy>Max Slew rate(NXbias) (V/s) (e.g.1E+0) # Maximum rate at which # the bias changes (before, during and after sweeping). @@ -702,7 +721,8 @@ NXsts(NXsensor_scan): unit: NX_ANY exists: optional doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/max_slew_rate + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/max_slew_rate # Bias Spectroscopy>backward sweep(NXbias) (e.g.TRUE) # Select whether to measure # the backward (return) sweep or the forward only. @@ -710,20 +730,23 @@ NXsts(NXsensor_scan): unit: NX_ANY exists: optional doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/backward_sweep + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/backward_sweep # Z-Controller>Controller name(NXpositioner_sts) (e.g.log Current) # Controller name. # This name which will be displayed at places where you can select a controller. z_controller_name: exists: optional doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/controller_name + Link to target: + /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/controller_name # Z-Controller>Controller status(NXpositioner_sts) (e.g.OFF) # ON/OFF z_controller_status(NX_BOOLEAN): exists: optional doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/controller_status + Link to target: + /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/controller_status # Z-Controller>Setpoint(NXpositioner_sts) (e.g.50E-12) # Set Point is the desired value # of the control signal. It can be set by editing the number or using the slider bar. @@ -733,7 +756,8 @@ NXsts(NXsensor_scan): unit: NX_CURRENT exists: optional doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/set_point + Link to target: + /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/set_point # Z-Controller>P gain(NXpid) (e.g.6E-12) # The Type switches controller parameters # between P/I (proportional gain/integral gain) and P/T (proportional gain/time constant). @@ -742,20 +766,23 @@ NXsts(NXsensor_scan): y_control_p_gain(NX_NUMBER): exists: optional doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/p_gain + Link to target: + /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/p_gain # Z-Controller>I gain(NXpid) (e.g.39.8241E-9) # See "Z-Controller>P gain" below. z_control_i_gain(NX_NUMBER): exists: optional doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/i_gain + Link to target: + /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/i_gain # Z-Controller>Time const(NXpid) (s) (e.g.150.662E-6) # See "Z-Controller>P gain" below. z_control_time_const(NX_NUMBER): unit: NX_TIME exists: optional doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/time_const + Link to target: + /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/time_const # Z-Controller>TipLift(NXpositioner_sts) (m) (e.g.0E+0) # Lifts the tip by the specified # amount when then controller is switched off. This can be a positive or a negative number, @@ -765,7 +792,8 @@ NXsts(NXsensor_scan): unit: NX_LENGTH exists: optional doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/tip_lift + Link to target: + /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/tip_lift # Z-Controller>Switch off delay(NXpositioner_sts) (s) (e.g.0E+0) # Use this parameter for # a reproducible position when switching off the Z-controller. When >0 and the Z-controller @@ -774,7 +802,8 @@ NXsts(NXsensor_scan): unit: NX_TIME exists: optional doc: | - Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/switchoff_delay + Link to target: + /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/switchoff_delay sample(NXsample): exists: optional doc: | @@ -795,62 +824,68 @@ NXsts(NXsensor_scan): li_demod_[1;2]_[X/Y]_[-;bwd;filt;bwd_filt] current_[-;bwd;filt;bwd_filt] temperature - x - y - z - - # DATA # multi dimensional array: multi I-V array per scan point; - # doc: The format of the data here is similar to a column matrix. - # Bias calc (V) #scanning parameter - # Current (A) # current during forward direction scanning of bias - original NXsensor - # LI Demod 2 X (A) lockin (NXsensor+lockin) - # LI Demod 2 Y (A) lockin - # LI Demod 1 X (A) lockin - # LI Demod 1 Y (A) lockin - # Current [bwd] (A) #bwd - backward (the positive direction shall be clarified by the reference bias scanning frame. Fwd means from left(neg) to right(pos). In the scannig image, the bottom(neg) to top(pos), the left(neg) to right(pos) - # LI Demod 2 X [bwd] (A) lockin - # LI Demod 2 Y [bwd] (A) lockin - # LI Demod 1 X [bwd] (A) lockin - # LI Demod 1 Y [bwd] (A) lockin - # Current (A) [filt] # forward direction (maybe from lockin#2?) - # LI Demod 2 X (A) [filt] lockin - # LI Demod 2 Y (A) [filt] lockin - # LI Demod 1 X (A) [filt] lockin - # LI Demod 1 Y (A) [filt] lockin - # Current (A) [bwd] [filt] - # LI Demod 2 X (A) [bwd] [filt] lockin - # LI Demod 2 Y (A) [bwd] [filt] lockin - # LI Demod 1 X (A) [bwd] [filt] lockin - # LI Demod 1 Y (A) [bwd] [filt] lockin - # Temperature - # x - # y - # z - # single point default plot # current(I) vs bias(V) - single_point(NXdata): - exists: optional - - # line scan default plot # multi I vs. V curves - line_scan(NXdata): - exists: optional - - # alternative plot # current(I) curve in the 2D space of (position(x), bias(V)) - alternative_plot(NXdata): - exists: optional - - # mesh scan default plot # 2D slices of the above alternative plot - mesh_scan(NXdata): - exists: optional + + # DATA # multi dimensional array: multi I-V array per scan point; + # doc: The format of the data here is similar to a column matrix. + # Bias calc (V) #scanning parameter + # Current (A) # current during forward direction scanning of bias - original NXsensor + # LI Demod 2 X (A) lockin (NXsensor+lockin) + # LI Demod 2 Y (A) lockin + # LI Demod 1 X (A) lockin + # LI Demod 1 Y (A) lockin + # Current [bwd] (A) #bwd - backward (the positive direction shall be clarified by the reference bias scanning frame. Fwd means from left(neg) to right(pos). In the scannig image, the bottom(neg) to top(pos), the left(neg) to right(pos) + # LI Demod 2 X [bwd] (A) lockin + # LI Demod 2 Y [bwd] (A) lockin + # LI Demod 1 X [bwd] (A) lockin + # LI Demod 1 Y [bwd] (A) lockin + # Current (A) [filt] # forward direction (maybe from lockin#2?) + # LI Demod 2 X (A) [filt] lockin + # LI Demod 2 Y (A) [filt] lockin + # LI Demod 1 X (A) [filt] lockin + # LI Demod 1 Y (A) [filt] lockin + # Current (A) [bwd] [filt] + # LI Demod 2 X (A) [bwd] [filt] lockin + # LI Demod 2 Y (A) [bwd] [filt] lockin + # LI Demod 1 X (A) [bwd] [filt] lockin + # LI Demod 1 Y (A) [bwd] [filt] lockin + # Temperature + # x + # y + # z + # single point default plot # current(I) vs bias(V) + single_point(NXdata): + exists: optional + doc: | + Plot for a single point (x,y) with I vs. V curve. + + # line scan default plot # multi I vs. V curves + line_scan(NXdata): + exists: optional + doc: | + Line scan with multiple I vs. V curves for different single (x,y) co-ordinates. + + # alternative plot # current(I) curve in the 2D space of (position(x), bias(V)) + alternative_plot(NXdata): + exists: optional + doc: | + Plot for current(I) curve in the 2D space of (position(x), bias(V)) which can be + derived from the `line_scan` plot. + + # mesh scan default plot # 2D slices of the above alternative plot + mesh_scan(NXdata): + exists: optional + doc: | + Mesh scan with 2D slices of the above alternative plot for other y co-ordinates. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 39a08f3d1a71d0ce3410e2ed1aed76a7250f94c8681a93d063c95f5966f79b9d -# +# 73b9167972d2988b8c75a60e04a9c2db349cf2fbe052958f3908c632f8d8eba1 +# # # -# -# +# +# +# # # Application definition for temperature-dependent IV curve measurements -# #2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the +# #2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the # STM image mode in the future with a focus on bias spectroscopy in Scanning Tunneling Microscopy. # # In this application definition, times should be specified always together with a UTC offset. @@ -880,10 +918,10 @@ NXsts(NXsensor_scan): # measurements. For this, a temperature is set. After reaching the temperature, a voltage sweep # is performed. For each voltage, a current is measured. # Then, the next desired temperature is set and an IV measurement is performed. -# The data can be visualized in a tensor with: +# The data can be visualized in a tensor with: # I (NXsensor_C, NXsoftware_Read_offset, NXcircuit) -# parameters: -# V has (NXsource+offset, NXsoftware_Scan_offset, NXsensor_V, NXcircuit) +# parameters: +# V has (NXsource+offset, NXsoftware_Scan_offset, NXsensor_V, NXcircuit) # T has (NXsource, NXsoftware_Scan_offset, NXsensor_T) # x has (NXsoftware_Scan_offset) # y has (NXsoftware_Scan_offset) @@ -897,16 +935,16 @@ NXsts(NXsensor_scan): # # # -# Name of the experiment where the application is applicable. +# Name of the experiment where the application is applicable. # # -# -# +# +# # # # # -# The equipments and techniques as well as the parameter settings and reference signals +# The equipments and techniques as well as the parameter settings and reference signals # are used during the experiments used in Scanning Tunneling Microscopy (STM). # # # # -# The Amplifier description that improves or helps to determine tunnel current (current +# The Amplifier description that improves or helps to determine tunnel current (current # between tip and bias). # # @@ -979,8 +1012,8 @@ NXsts(NXsensor_scan): # # # # @@ -991,12 +1024,12 @@ NXsts(NXsensor_scan): # # # -# The signal is modulated by adding the frequency of the sine modulation. The -# modulation frequency spans can be from 10 mHz to 40 kHz, corresponding to the output filter -# cut-off range. When dealing with harmonics, it's essential to ensure that the -# harmonic frequencies remain below ~100 kHz, which aligns with the input filter cut-off. -# Be mindful that hardware filters might impact the amplitude as the signal approaches -# their cut-off frequencies." (e.g. 973E+0) +# The signal is modulated by adding the frequency of the sine modulation. The +# modulation frequency spans can be from 10 mHz to 40 kHz, corresponding to the output filter +# cut-off range. When dealing with harmonics, it's essential to ensure that the +# harmonic frequencies remain below ~100 kHz, which aligns with the input filter cut-off. +# Be mindful that hardware filters might impact the amplitude as the signal approaches +# their cut-off frequencies." (e.g. 973E+0) # # # @@ -1010,24 +1043,24 @@ NXsts(NXsensor_scan): # will be demodulated, in order to determine the amplitude and phase at the frequency # set in the Frequency field (“4”) or harmonics.--> # -# The input signal (STS signal) will be demodulated, in order to determine the amplitude -# and phase at the frequency set in the Frequency field or harmonics, such as current, +# The input signal (STS signal) will be demodulated, in order to determine the amplitude +# and phase at the frequency set in the Frequency field or harmonics, such as current, # bias, et.al. # # # -# +# # # N denotes 1 or 2. The order of the harmonic oscillation to be detected in the demodulated -# signal should be considered relative to the modulation frequency. When dealing with +# signal should be considered relative to the modulation frequency. When dealing with # higher harmonics, it's essential to ensure that their frequencies do not surpass # the analogue signal bandwidth (e.g. harmonic_order_1). # # # -# +# # # Reference phase for the sine on the demodulated signal with respect to the # modulation signal. The determined phase is displayed with respect to the @@ -1038,27 +1071,30 @@ NXsts(NXsensor_scan): # # +# doc: Bias Spectroscopy>Lock-In run FALSE # Select whether to set the Lock-In to run +# during the measurement. When using this feature, make sure the Lock-In is configured +# correctly and settling times are set to twice the Lock-In period at least. This +# option is ignored when Lock-In is already running. This option is disabled if the +# Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline +# segment editor is set.--> # +# +# Bias voltage applied to the sample. +# # # # Applied a voltage between tip and sample. @@ -1082,13 +1118,13 @@ NXsts(NXsensor_scan): # # # -# Temperature of liquid helium cryostat. Note: At least one field from +# Temperature of liquid helium cryostat. Note: At least one field from # stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp must be provided. # # # # -# Temperature of liquid nitrogen shield. Temperature 3 (K) (e.g 78.00000E+0). Note: At +# Temperature of liquid nitrogen shield. Temperature 3 (K) (e.g 78.00000E+0). Note: At # least one field from stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp # must be provided. # @@ -1105,8 +1141,8 @@ NXsts(NXsensor_scan): # doc: The rate at which the one of the signal changes when ramping to the starting point. (V/s) (e.g. Inf)--> # # -# Configuration for piezoelectric scanner used to move tip along X and Y direction. The -# material of the Piezoelectric scanner composed of polycrystalline solids and sensitive to +# Configuration for piezoelectric scanner used to move tip along X and Y direction. The +# material of the Piezoelectric scanner composed of polycrystalline solids and sensitive to # applied voltage. # # @@ -1116,9 +1152,9 @@ NXsts(NXsensor_scan): # # # -# N denotes X or Y or Z. There are three parameters in the X, Y, and Z directions, -# along with three available controls: Calibration (m/V), Range (m), and HV gain. Only -# two of these parameters are required to define the calibration. Consequently, when any +# N denotes X or Y or Z. There are three parameters in the X, Y, and Z directions, +# along with three available controls: Calibration (m/V), Range (m), and HV gain. Only +# two of these parameters are required to define the calibration. Consequently, when any # value is changed, one of the other values will be automatically updated. (e.g. calib_X = 3.8E-9) # # @@ -1132,7 +1168,7 @@ NXsts(NXsensor_scan): # # # -# N denotes X or Y. There are 2 parameters in X and Y directions, and tilt needs to be +# N denotes X or Y. There are 2 parameters in X and Y directions, and tilt needs to be # adjusted according to the actual surface. (in degrees, first order correction). # # @@ -1145,17 +1181,17 @@ NXsts(NXsensor_scan): # # # -# N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, -# you can enter the 2nd order piezo characteristics to compensate for it. The -# following equation shows the interpretation of the 2nd order correction parameter: -# For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: +# N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, +# you can enter the 2nd order piezo characteristics to compensate for it. The +# following equation shows the interpretation of the 2nd order correction parameter: +# For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: # [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx # is the 2nd order correction. (V/m^2). (e.g. 0E+0) # # # # -# N denotes X, Y or Z. There are 3 parameters in X, Y and Z directions. Define the +# N denotes X, Y or Z. There are 3 parameters in X, Y and Z directions. Define the # drift speed for all three axes. When the compensation is on, the piezos will start to # move at that speed. (e.g. 0E+0) # @@ -1166,16 +1202,14 @@ NXsts(NXsensor_scan): # # # -# +# # -# Describes an environment setup for a temperature-dependent IV measurement experiment. -# The temperature and voltage must be present as independently scanned controllers and -# the current sensor must also be present with its readings. +# An environmental setup to measure the tunneling current due to different tip-sample biases. # # # # -# This is set-point of tip current (in the constant current mode should be equal to set-point, +# This is set-point of tip current (in the constant current mode should be equal to set-point, # in the constant height mode means the real tunnelling current between tip and sample). # # @@ -1185,7 +1219,7 @@ NXsts(NXsensor_scan): # # # -# +# # # # @@ -1211,7 +1245,7 @@ NXsts(NXsensor_scan): # # # -# Indicate the relative tip position z between tip and sample. The tip position can also +# Indicate the relative tip position z between tip and sample. The tip position can also # be varied when the z_controller is not running. (e.g. 130.5E-9) # # @@ -1251,8 +1285,8 @@ NXsts(NXsensor_scan): # # # -# The Z position is recorded and averaged for a certain duration both before and -# after the sweep. After the initial Z averaging time, if "Z-Controller to Hold" +# The Z position is recorded and averaged for a certain duration both before and +# after the sweep. After the initial Z averaging time, if "Z-Controller to Hold" # is selected, the Z-Controller is set to hold mode, and the tip is positioned at # the previously averaged Z position (adjusted by the Z offset). (e.g. 100E-3) # @@ -1261,15 +1295,15 @@ NXsts(NXsensor_scan): # # # -# The bandwidth of the Hardware and/or Software is instrument specific. +# The bandwidth of the Hardware and/or Software is instrument specific. # For example, Nanonis Generic 5 has 'RT Frequency' (e.g. 20E+3). # # # # -# The Signals Period represents the rate at which signals are transferred to -# the host computer, which operates the control software. This rate may -# be 10 times lower than the sampling rate, as the real-time engine internally +# The Signals Period represents the rate at which signals are transferred to +# the host computer, which operates the control software. This rate may +# be 10 times lower than the sampling rate, as the real-time engine internally # oversamples the signal. If desired, you may have the option to reduce the oversampling # to 1, enabling higher frequency resolution in the Spectrum Analyzer. (e.g. 10) # @@ -1321,7 +1355,7 @@ NXsts(NXsensor_scan): # # # -# Also clarify the frame for the ROI of the scan in lab frame, the middle of the lab +# Also clarify the frame for the ROI of the scan in lab frame, the middle of the lab # frame is (0, 0), and positive in x means right and in y means up. # # @@ -1373,56 +1407,61 @@ NXsts(NXsensor_scan): # # # -# Link to target:/NXentry/NXinstrument/stm_head_temp +# Link to target: /NXentry/NXinstrument/stm_head_temp # # # # # -# Link to target:/NXentry/NXinstrument/cryo_bottom_temp +# Link to target: /NXentry/NXinstrument/cryo_bottom_temp # # # # # -# Link to target:/NXentry/NXinstrument/temp_cryo_shield +# Link to target: /NXentry/NXinstrument/temp_cryo_shield # # # # # -# Link to target:/NXentry/NXinstrument/NXlock_in/modulation_signal +# Link to target: /NXentry/NXinstrument/NXlock_in/modulation_signal # # # # # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/NXintegration_time +# Link to target: +# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/NXintegration_time # # # # # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/number_of_sweeps +# Link to target: +# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/number_of_sweeps # # # # # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/sweep_start +# Link to target: +# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/sweep_start # # # # # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/sweep_end +# Link to target: +# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/sweep_end # # # # # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/num_pixel +# Link to target: +# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/num_pixel # # # # # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_avg_time +# Link to target: +# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_avg_time # # # # # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/rt_frequency +# Link to target: +# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/rt_frequency # # # # # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/signals_oversampling +# Link to target: +# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/signals_oversampling # # # # # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/acquisition_period +# Link to target: +# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/acquisition_period # # # # # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/animations_period +# Link to target: +# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/animations_period # # # # # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/indicators_period +# Link to target: +# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/indicators_period # # # # # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/measurements_period +# Link to target: +# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/measurements_period # # # @@ -1500,25 +1546,25 @@ NXsts(NXsensor_scan): # # # -# Link to target:/NXentry/NXinstrument/NXsample_bias/bias +# Link to target: /NXentry/NXinstrument/NXsample_bias/bias # # # # # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current +# Link to target: /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current # # # # # -# Link to target:/NXentry/NXnstrument/NXsample_bias/bias_calibration +# Link to target: /NXentry/NXnstrument/NXsample_bias/bias_calibration # # # # -# Link to target:/NXentry/NXinstrument/NXsample_bias/bias_offset +# Link to target: /NXentry/NXinstrument/NXsample_bias/bias_offset # # # # # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_calibration +# Link to target: +# /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_calibration # # # # # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_offset +# Link to target: +# /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_offset # # # # # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_gain +# Link to target: +# /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_gain # # # # # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_offset +# Link to target: +# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_offset # # # # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/settling_time +# Link to target: +# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/settling_time # # # # # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_ccontroller_hold +# Link to target: +# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_ccontroller_hold # # # # # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/record_final_z +# Link to target: +# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/record_final_z # # # # # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/first_settling_time +# Link to target: +# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/first_settling_time # # # # # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/end_settling_time +# Link to target: +# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/end_settling_time # # # # # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_control_time +# Link to target: +# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_control_time # # # # # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/max_slew_rate +# Link to target: +# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/max_slew_rate # # # # # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/backward_sweep +# Link to target: +# /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/backward_sweep # # # -# +# # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/controller_name +# Link to target: +# /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/controller_name # # # # # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/controller_status +# Link to target: +# /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/controller_status # # # # # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/set_point +# Link to target: +# /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/set_point # # # # # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/p_gain +# Link to target: +# /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/p_gain # # # # # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/i_gain +# Link to target: +# /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/i_gain # # # -# +# # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/time_const +# Link to target: +# /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/time_const # # # # # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/tip_lift +# Link to target: +# /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/tip_lift # # -# # # # -# Link to target:/NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/switchoff_delay +# Link to target: +# /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/switchoff_delay # # # @@ -1703,11 +1768,9 @@ NXsts(NXsensor_scan): # li_demod_[1;2]_[X/Y]_[-;bwd;filt;bwd_filt] # current_[-;bwd;filt;bwd_filt] # temperature -# x -# y -# z # -# -# -# -# -# -# -# -# +# +# +# Plot for a single point (x,y) with I vs. V curve. +# +# +# +# +# +# Line scan with multiple I vs. V curves for different single (x,y) co-ordinates. +# +# +# +# +# +# Plot for current(I) curve in the 2D space of (position(x), bias(V)) which can be +# derived from the `line_scan` plot. +# +# +# +# +# +# Mesh scan with 2D slices of the above alternative plot for other y co-ordinates. +# # # # From 05d8b8d7d7eb63bcddef9b72cfe9689e2a2949a0 Mon Sep 17 00:00:00 2001 From: Ron Hildebrandt Date: Wed, 8 May 2024 09:02:09 +0200 Subject: [PATCH 0678/1012] =?UTF-8?q?Review=20Tam=C3=A1s,=20Beam=20Path=20?= =?UTF-8?q?remnannts=20removal,=20data=5Fcollection=20for=20ellipsometry?= =?UTF-8?q?=20to=20avoid=20large=20pynxtools-ellips=20adjustments?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../NXellipsometry.nxdl.xml | 232 ++++++++++++++---- contributed_definitions/NXopt.nxdl.xml | 21 +- .../nyaml/NXellipsometry.yaml | 208 ++++++++++++---- contributed_definitions/nyaml/NXopt.yaml | 17 +- 4 files changed, 365 insertions(+), 113 deletions(-) diff --git a/contributed_definitions/NXellipsometry.nxdl.xml b/contributed_definitions/NXellipsometry.nxdl.xml index 3578d76102..1f1934eb45 100644 --- a/contributed_definitions/NXellipsometry.nxdl.xml +++ b/contributed_definitions/NXellipsometry.nxdl.xml @@ -183,76 +183,97 @@ A rework of the draft version(06/2022) of a NeXus application definition for ell - - - + + + If focussing probes (lenses) were used, please state if the data + were corrected for the window effects. + + + + + Were the recorded data corrected by the window effects of the + focussing probes (lenses)? + + + + + Specify the angular spread caused by the focussing probes. + + + + + + Properties of the rotating element defined in + 'instrument/rotating_element_type'. + + - If focussing probes (lenses) were used, please state if the data - were corrected for the window effects. + Define how many revolutions of the rotating element were averaged + for each measurement. If the number of revolutions was fixed to a + certain value use the field 'fixed_revolutions' instead. - - - - Were the recorded data corrected by the window effects of the - focussing probes (lenses)? - - - - - Specify the angular spread caused by the focussing probes. - - - - + + - Properties of the rotating element defined in - 'instrument/rotating_element_type'. + Define how many revolutions of the rotating element were taken + into account for each measurement (if number of revolutions was + fixed to a certain value, i.e. not averaged). - - - Define how many revolutions of the rotating element were averaged - for each measurement. If the number of revolutions was fixed to a - certain value use the field 'fixed_revolutions' instead. - - - - - Define how many revolutions of the rotating element were taken - into account for each measurement (if number of revolutions was - fixed to a certain value, i.e. not averaged). - - - - - Specify the maximum value of revolutions of the rotating element - for each measurement. - - - + + + + Specify the maximum value of revolutions of the rotating element + for each measurement. + + - + Was the backside of the sample roughened? Relevant for infrared ellipsometry. - + + + + Measured data, data errors, and varied parameters. This may be used to describe + indirectly derived data or data transformed between different descriptions, + such as: + Raw Data --> Psi + Delta Psi, Delta --> N,C,S + Mueller matrix --> N,C,S + Mueller matrix --> Psi, Delta + etc. + + Other types of data, such as temperature or sample location, may be saved + in a generic (NXdata) concept from NXopt, or better directly in the + location of the sample positioner or temperature sensor. + + + + An identifier to correlate data to the experimental conditions, + if several were used in this measurement; typically an index of 0-N. + + - Select which type of data was recorded, for example Psi and Delta - (see: https://en.wikipedia.org/wiki/Ellipsometry#Data_acquisition). - It is possible to have multiple selections. Data types may also be - converted to each other, e.g. a Mueller matrix contains N,C,S data - as well. + Select which type of data was recorded, for example intensity, + reflectivity, transmittance, Psi and Delta etc. + It is possible to have multiple selections. The enumeration list + depends on the type of experiment and may differ for different + application definitions. + + + @@ -261,6 +282,111 @@ A rework of the draft version(06/2022) of a NeXus application definition for ell + + + Spectral values (e.g. wavelength or energy) used for the measurement. + An array of 1 or more elements. Length defines N_spectrum. Replace + 'SPECTRUM' by the physical quantity that is used, e.g. wavelength. + + + + + + + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. + + + + + + Resulting data from the measurement, described by 'data_type'. + + The first dimension is defined by the number of measurements taken, + (N_measurements). The instructions on how to order the values + contained in the parameter vectors given in the doc string of + INSTRUMENT/sample_stage/environment_conditions/PARAMETER/values, + define the N_measurements parameter sets. For example, if the + experiment was performed at three different temperatures + (T1, T2, T3), two different pressures (p1, p2) and two different + angles of incidence (a1, a2), the first measurement was taken at the + parameters {a1,p1,T1}, the second measurement at {a1,p1,T2} etc. + + + + + + + + + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. + + + + + + Specified uncertainties (errors) of the data described by 'data_type' + and provided in 'measured_data'. + + + + + + + + + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. + + + + + + List of links to the values of the sensors. Add a link for each + varied parameter (i.e. for each sensor). + + + + + + + + Link to the NeXus file which describes the reference data if a + reference measurement was performed. Ideally, the reference + measurement was performed using the same conditions as the actual + measurement and should be as close in time to the actual measurement + as possible. + + + + + + Commercial or otherwise defined given name of the program that was + used to generate the result file(s) with measured data and/or + metadata (in most cases, this is the same as INSTRUMENT/software). + If home written, one can provide the actual steps in the NOTE + subfield here. + + + + + Either version with build number, commit hash, or description of a + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + + + + + Website of the software. + + + diff --git a/contributed_definitions/NXopt.nxdl.xml b/contributed_definitions/NXopt.nxdl.xml index 84b1be1259..6875940030 100644 --- a/contributed_definitions/NXopt.nxdl.xml +++ b/contributed_definitions/NXopt.nxdl.xml @@ -983,6 +983,9 @@ Nexus definitions for source, detector, monochromator, ...--> + (Measured) sample thickness. @@ -1001,6 +1004,9 @@ Nexus definitions for source, detector, monochromator, ...--> determined. + Qualitative description of the layer structure for the sample, @@ -1025,9 +1031,12 @@ Nexus definitions for source, detector, monochromator, ...--> - A default view of the data provided in ENTRY/data_collection/measured_data. This - should be the part of the data set which provides the most suitable - representation of the data. + Here generic types of data may be saved.. This may refer to data derived + from single or multiple raw measurements (i.e. several intensities are + evaluated for different parameters: ellipsometry -> psi and delta) - + i.e. non-raw data. + As well plotable data may be stored/linked here, which provides the most suitable + representation of the data (for the respective community). You may provide multiple instances of NXdata @@ -1052,7 +1061,9 @@ Nexus definitions for source, detector, monochromator, ...--> +NXdata. The detailed inclusion of a data collection description (i.e. +raw data from ellipsometry as polarization values to the usually used +psi and delta values), will be done later after the NXopt workshop.--> >>>This section is transfered from the first NXopt version and might @@ -1069,7 +1080,7 @@ NXdata. A detailed rework of this has to be done after the NXopt workshop--> - + Jones quality factor. diff --git a/contributed_definitions/nyaml/NXellipsometry.yaml b/contributed_definitions/nyaml/NXellipsometry.yaml index 852a62a5b2..cabb04c8d1 100644 --- a/contributed_definitions/nyaml/NXellipsometry.yaml +++ b/contributed_definitions/nyaml/NXellipsometry.yaml @@ -104,67 +104,175 @@ NXellipsometry(NXopt): doc: | Define which element rotates, e.g. polarizer or analyzer. enumeration: [polarizer (source side), analyzer (detector side), compensator (source side), compensator (detector side)] - (NXbeam_path): - #light_source(NXsource): - # doc: | - # Specify the used light source. Multiple selection possible. - # source_type: - # enumeration: [arc lamp, halogen lamp, LED, other] - focussing_probes(NXlens_opt): + focussing_probes(NXlens_opt): + exists: optional + doc: | + If focussing probes (lenses) were used, please state if the data + were corrected for the window effects. + # This as well can be stated in window/aperture + data_correction(NX_BOOLEAN): + doc: | + Were the recorded data corrected by the window effects of the + focussing probes (lenses)? + angular_spread(NX_NUMBER): + exists: recommended + unit: NX_ANGLE + doc: | + Specify the angular spread caused by the focussing probes. + rotating_element(NXwaveplate): + exists: optional + doc: | + Properties of the rotating element defined in + 'instrument/rotating_element_type'. + revolutions(NX_NUMBER): exists: optional + unit: NX_COUNT doc: | - If focussing probes (lenses) were used, please state if the data - were corrected for the window effects. - # This as well can be stated in window/aperture - data_correction(NX_BOOLEAN): - doc: | - Were the recorded data corrected by the window effects of the - focussing probes (lenses)? - angular_spread(NX_NUMBER): - exists: recommended - unit: NX_ANGLE - doc: | - Specify the angular spread caused by the focussing probes. - rotating_element(NXwaveplate): + Define how many revolutions of the rotating element were averaged + for each measurement. If the number of revolutions was fixed to a + certain value use the field 'fixed_revolutions' instead. + fixed_revolutions(NX_NUMBER): exists: optional + unit: NX_COUNT doc: | - Properties of the rotating element defined in - 'instrument/rotating_element_type'. - revolutions(NX_NUMBER): - exists: optional - unit: NX_COUNT - doc: | - Define how many revolutions of the rotating element were averaged - for each measurement. If the number of revolutions was fixed to a - certain value use the field 'fixed_revolutions' instead. - fixed_revolutions(NX_NUMBER): - exists: optional - unit: NX_COUNT - doc: | - Define how many revolutions of the rotating element were taken - into account for each measurement (if number of revolutions was - fixed to a certain value, i.e. not averaged). - max_revolutions(NX_NUMBER): - exists: optional - unit: NX_COUNT - doc: | - Specify the maximum value of revolutions of the rotating element - for each measurement. + Define how many revolutions of the rotating element were taken + into account for each measurement (if number of revolutions was + fixed to a certain value, i.e. not averaged). + max_revolutions(NX_NUMBER): + exists: optional + unit: NX_COUNT + doc: | + Specify the maximum value of revolutions of the rotating element + for each measurement. (NXsample): backside_roughness(NX_BOOLEAN): - exists: recommended + exists: optional doc: | Was the backside of the sample roughened? Relevant for infrared ellipsometry. - (NXdata): + # The following NXdata setction called data_collection, is specialization + # from the old (NXopt and NXellipsometry) for the new NXellipometry. + # The generic description of the data collection will in future be + # included in the generic NXopt, but is now keept limited to + # NXellipsometry. + data_collection(NXdata): + doc: | + Measured data, data errors, and varied parameters. This may be used to describe + indirectly derived data or data transformed between different descriptions, + such as: + Raw Data --> Psi + Delta Psi, Delta --> N,C,S + Mueller matrix --> N,C,S + Mueller matrix --> Psi, Delta + etc. + + Other types of data, such as temperature or sample location, may be saved + in a generic (NXdata) concept from NXopt, or better directly in the + location of the sample positioner or temperature sensor. + data_identifier(NX_NUMBER): + doc: | + An identifier to correlate data to the experimental conditions, + if several were used in this measurement; typically an index of 0-N. data_type: doc: | - Select which type of data was recorded, for example Psi and Delta - (see: https://en.wikipedia.org/wiki/Ellipsometry#Data_acquisition). - It is possible to have multiple selections. Data types may also be - converted to each other, e.g. a Mueller matrix contains N,C,S data - as well. - enumeration: [Psi/Delta, tan(Psi)/cos(Delta), Mueller matrix, Jones matrix, N/C/S, raw data] + Select which type of data was recorded, for example intensity, + reflectivity, transmittance, Psi and Delta etc. + It is possible to have multiple selections. The enumeration list + depends on the type of experiment and may differ for different + application definitions. + enumeration: [intensity, reflectivity, transmittance, Psi/Delta, tan(Psi)/cos(Delta), Mueller matrix, Jones matrix, N/C/S, raw data] + + NAME_spectrum(NX_FLOAT): + exists: optional + unit: NX_ANY + doc: | + Spectral values (e.g. wavelength or energy) used for the measurement. + An array of 1 or more elements. Length defines N_spectrum. Replace + 'SPECTRUM' by the physical quantity that is used, e.g. wavelength. + dimensions: + rank: 1 + dim: [[1, N_spectrum]] + \@units: + exists: optional + doc: | + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. + measured_data(NX_FLOAT): + unit: NX_ANY + doc: | + Resulting data from the measurement, described by 'data_type'. + + The first dimension is defined by the number of measurements taken, + (N_measurements). The instructions on how to order the values + contained in the parameter vectors given in the doc string of + INSTRUMENT/sample_stage/environment_conditions/PARAMETER/values, + define the N_measurements parameter sets. For example, if the + experiment was performed at three different temperatures + (T1, T2, T3), two different pressures (p1, p2) and two different + angles of incidence (a1, a2), the first measurement was taken at the + parameters {a1,p1,T1}, the second measurement at {a1,p1,T2} etc. + dimensions: + rank: 3 + dim: [[1, N_measurements], [2, N_observables], [3, N_spectrum]] + \@units: + exists: optional + doc: | + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. + measured_data_errors(NX_FLOAT): + exists: optional + unit: NX_ANY + doc: | + Specified uncertainties (errors) of the data described by 'data_type' + and provided in 'measured_data'. + dimensions: + rank: 3 + dim: [[1, N_measurements], [2, N_observables], [3, N_spectrum]] + \@units: + exists: optional + doc: | + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. + varied_parameter_link: + exists: optional + doc: | + List of links to the values of the sensors. Add a link for each + varied parameter (i.e. for each sensor). + dimensions: + rank: 1 + dim: [[1, N_sensors]] + reference_data_link: + exists: optional + doc: | + Link to the NeXus file which describes the reference data if a + reference measurement was performed. Ideally, the reference + measurement was performed using the same conditions as the actual + measurement and should be as close in time to the actual measurement + as possible. + data_software(NXprogram): + exists: optional + program: + doc: | + Commercial or otherwise defined given name of the program that was + used to generate the result file(s) with measured data and/or + metadata (in most cases, this is the same as INSTRUMENT/software). + If home written, one can provide the actual steps in the NOTE + subfield here. + version: + doc: | + Either version with build number, commit hash, or description of a + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + \@url: + exists: optional + doc: | + Website of the software. + diff --git a/contributed_definitions/nyaml/NXopt.yaml b/contributed_definitions/nyaml/NXopt.yaml index f79655ef34..a592610114 100644 --- a/contributed_definitions/nyaml/NXopt.yaml +++ b/contributed_definitions/nyaml/NXopt.yaml @@ -778,6 +778,7 @@ NXopt(NXobject): exists: recommended enumeration: [air, vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere, sealed can, water, other] thickness(NX_NUMBER): + # Make something like NXlayer_structure_sample? exists: optional doc: | (Measured) sample thickness. @@ -794,6 +795,7 @@ NXopt(NXobject): doc: | If a thickness if given, please specify how this thickness was estimated or determined. layer_structure: + # Maybe consider here to include NXsample_component_set. exists: optional doc: | Qualitative description of the layer structure for the sample, @@ -813,9 +815,12 @@ NXopt(NXobject): a free text description. (NXdata): doc: | - A default view of the data provided in ENTRY/data_collection/measured_data. This - should be the part of the data set which provides the most suitable - representation of the data. + Here generic types of data may be saved.. This may refer to data derived + from single or multiple raw measurements (i.e. several intensities are + evaluated for different parameters: ellipsometry -> psi and delta) - + i.e. non-raw data. + As well plotable data may be stored/linked here, which provides the most suitable + representation of the data (for the respective community). You may provide multiple instances of NXdata \@axes: @@ -832,7 +837,9 @@ NXopt(NXobject): doc: | Location to save the calibrated wavelength data. # The old "data_collection(NXprocess)" is now replaced by more flexbile - # NXdata. A detailed rework of this has to be done after the NXopt workshop + # NXdata. The detailed inclusion of a data collection description (i.e. + # raw data from ellipsometry as polarization values to the usually used + # psi and delta values), will be done later after the NXopt workshop. derived_parameters(NXprocess): exists: optional doc: | @@ -847,7 +854,7 @@ NXopt(NXobject): dimensions: rank: 3 dim: [[1, N_measurements], [2, 1], [3, N_spectrum]] - Jones_quality_factor(NX_NUMBER): + jones_quality_factor(NX_NUMBER): exists: optional unit: NX_UNITLESS doc: | From 9aa7d9e8dbf022a1a98d9f6ae6f68890036cfd33 Mon Sep 17 00:00:00 2001 From: domna Date: Thu, 9 May 2024 23:14:40 +0200 Subject: [PATCH 0679/1012] Add edge cases to namefit documentation --- dev_tools/tests/test_nxdl_utils.py | 2 ++ dev_tools/utils/nxdl_utils.py | 2 ++ 2 files changed, 4 insertions(+) diff --git a/dev_tools/tests/test_nxdl_utils.py b/dev_tools/tests/test_nxdl_utils.py index 8618271d31..faf6f52a02 100644 --- a/dev_tools/tests/test_nxdl_utils.py +++ b/dev_tools/tests/test_nxdl_utils.py @@ -172,6 +172,8 @@ def test_namefitting(hdf_name, concept_name, should_fit): ("test_name", "test_name", 18), ("test_other", "test_name", -1), ("my_fancy_yet_long_name", "my_SOME_name", 8), + ("something", "XXXX", 0), + ("something", "OTHER", 1) ], ) def test_namefitting_scores(hdf_name, concept_name, score): diff --git a/dev_tools/utils/nxdl_utils.py b/dev_tools/utils/nxdl_utils.py index 4ecb0700e0..5a9f8f8f66 100644 --- a/dev_tools/utils/nxdl_utils.py +++ b/dev_tools/utils/nxdl_utils.py @@ -133,6 +133,8 @@ def get_nx_namefit(hdf_name: str, name: str, name_any: bool = False) -> int: * `get_nx_namefit("my_other_name", "TEST_name")` returns 5 * `get_nx_namefit("test_name", "test_name")` returns 18 * `get_nx_namefit("test_other", "test_name")` returns -1 + * `get_nx_namefit("something", "XXXX")` returns 0 + * `get_nx_namefit("something", "OTHER")` returns 1 Args: hdf_name (str): The hdf_name, containing the name of the HDF5 node. From cc046e03c6fc2b2b8561a2cce381cda7b4a9cd7d Mon Sep 17 00:00:00 2001 From: domna Date: Fri, 10 May 2024 06:58:53 +0200 Subject: [PATCH 0680/1012] Formatting --- dev_tools/tests/test_nxdl_utils.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dev_tools/tests/test_nxdl_utils.py b/dev_tools/tests/test_nxdl_utils.py index faf6f52a02..4d8c77f54f 100644 --- a/dev_tools/tests/test_nxdl_utils.py +++ b/dev_tools/tests/test_nxdl_utils.py @@ -173,7 +173,7 @@ def test_namefitting(hdf_name, concept_name, should_fit): ("test_other", "test_name", -1), ("my_fancy_yet_long_name", "my_SOME_name", 8), ("something", "XXXX", 0), - ("something", "OTHER", 1) + ("something", "OTHER", 1), ], ) def test_namefitting_scores(hdf_name, concept_name, score): From b742d934c71dd386f1295f22c5b2e3649ddfaa71 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 13 May 2024 15:51:06 +0200 Subject: [PATCH 0681/1012] add default attribute to MPES-related base classes --- base_classes/NXenvironment.nxdl.xml | 13 ++++++ base_classes/nyaml/NXenvironment.yaml | 26 +++++++++++- contributed_definitions/NXactuator.nxdl.xml | 13 ++++++ .../NXcalibration.nxdl.xml | 13 ++++++ .../NXcollectioncolumn.nxdl.xml | 13 ++++++ .../NXelectronanalyser.nxdl.xml | 13 ++++++ .../NXenergydispersion.nxdl.xml | 13 ++++++ .../NXmanipulator.nxdl.xml | 13 ++++++ contributed_definitions/NXpid.nxdl.xml | 13 ++++++ contributed_definitions/NXresolution.nxdl.xml | 13 ++++++ contributed_definitions/nyaml/NXactuator.yaml | 26 +++++++++++- .../nyaml/NXcalibration.yaml | 26 +++++++++++- .../nyaml/NXcollectioncolumn.yaml | 28 ++++++++++++- .../nyaml/NXelectronanalyser.yaml | 42 ++++++++++++++----- .../nyaml/NXenergydispersion.yaml | 26 +++++++++++- .../nyaml/NXmanipulator.yaml | 26 +++++++++++- contributed_definitions/nyaml/NXpid.yaml | 26 +++++++++++- .../nyaml/NXresolution.yaml | 26 +++++++++++- 18 files changed, 349 insertions(+), 20 deletions(-) diff --git a/base_classes/NXenvironment.nxdl.xml b/base_classes/NXenvironment.nxdl.xml index 1dd95974a8..a0c050781d 100644 --- a/base_classes/NXenvironment.nxdl.xml +++ b/base_classes/NXenvironment.nxdl.xml @@ -93,4 +93,17 @@ defined in an NXinstrument instance. + + + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + + diff --git a/base_classes/nyaml/NXenvironment.yaml b/base_classes/nyaml/NXenvironment.yaml index 92efc44ec0..3b1cd7fb58 100644 --- a/base_classes/nyaml/NXenvironment.yaml +++ b/base_classes/nyaml/NXenvironment.yaml @@ -50,9 +50,20 @@ NXenvironment(NXobject): doc: | Any sensor used to monitor the environment. This can be linked to a sensor defined in an NXinstrument instance. + \@default: + doc: | + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# edb4357785f3ad2e7c84849c787be220920b9eef3a18ee1c8d251327873c87b7 +# 4e4bd4fe380d78389677def141557774db0580c77850b6cfe755ba06e7b57cef # # # - + + + If focussing probes (lenses) were used, please state if the data + were corrected for the window effects. + + + + + Were the recorded data corrected by the window effects of the + focussing probes (lenses)? + + + + + Specify the angular spread caused by the focussing probes. + + + + + + Properties of the rotating element defined in + 'instrument/rotating_element_type'. + + - If focussing probes (lenses) were used, please state if the data - were corrected for the window effects. + Define how many revolutions of the rotating element were averaged + for each measurement. If the number of revolutions was fixed to a + certain value use the field 'fixed_revolutions' instead. - - - - Were the recorded data corrected by the window effects of the - focussing probes (lenses)? - - - - - Specify the angular spread caused by the focussing probes. - - - - + + - Properties of the rotating element defined in - 'instrument/rotating_element_type'. + Define how many revolutions of the rotating element were taken + into account for each measurement (if number of revolutions was + fixed to a certain value, i.e. not averaged). - - - Define how many revolutions of the rotating element were averaged - for each measurement. If the number of revolutions was fixed to a - certain value use the field 'fixed_revolutions' instead. - - - - - Define how many revolutions of the rotating element were taken - into account for each measurement (if number of revolutions was - fixed to a certain value, i.e. not averaged). - - - - - Specify the maximum value of revolutions of the rotating element - for each measurement. - - - + + + + Specify the maximum value of revolutions of the rotating element + for each measurement. + + - + Was the backside of the sample roughened? Relevant for infrared ellipsometry. - + + + + Measured data, data errors, and varied parameters. This may be used to describe + indirectly derived data or data transformed between different descriptions, + such as: + Raw Data --> Psi + Delta Psi, Delta --> N,C,S + Mueller matrix --> N,C,S + Mueller matrix --> Psi, Delta + etc. + + Other types of data, such as temperature or sample location, may be saved + in a generic (NXdata) concept from NXopt, or better directly in the + location of the sample positioner or temperature sensor. + + + + An identifier to correlate data to the experimental conditions, + if several were used in this measurement; typically an index of 0-N. + + - Select which type of data was recorded, for example Psi and Delta - (see: https://en.wikipedia.org/wiki/Ellipsometry#Data_acquisition). - It is possible to have multiple selections. Data types may also be - converted to each other, e.g. a Mueller matrix contains N,C,S data - as well. + Select which type of data was recorded, for example intensity, + reflectivity, transmittance, Psi and Delta etc. + It is possible to have multiple selections. The enumeration list + depends on the type of experiment and may differ for different + application definitions. + + + @@ -261,6 +282,111 @@ A rework of the draft version(06/2022) of a NeXus application definition for ell + + + Spectral values (e.g. wavelength or energy) used for the measurement. + An array of 1 or more elements. Length defines N_spectrum. Replace + 'SPECTRUM' by the physical quantity that is used, e.g. wavelength. + + + + + + + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. + + + + + + Resulting data from the measurement, described by 'data_type'. + + The first dimension is defined by the number of measurements taken, + (N_measurements). The instructions on how to order the values + contained in the parameter vectors given in the doc string of + INSTRUMENT/sample_stage/environment_conditions/PARAMETER/values, + define the N_measurements parameter sets. For example, if the + experiment was performed at three different temperatures + (T1, T2, T3), two different pressures (p1, p2) and two different + angles of incidence (a1, a2), the first measurement was taken at the + parameters {a1,p1,T1}, the second measurement at {a1,p1,T2} etc. + + + + + + + + + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. + + + + + + Specified uncertainties (errors) of the data described by 'data_type' + and provided in 'measured_data'. + + + + + + + + + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. + + + + + + List of links to the values of the sensors. Add a link for each + varied parameter (i.e. for each sensor). + + + + + + + + Link to the NeXus file which describes the reference data if a + reference measurement was performed. Ideally, the reference + measurement was performed using the same conditions as the actual + measurement and should be as close in time to the actual measurement + as possible. + + + + + + Commercial or otherwise defined given name of the program that was + used to generate the result file(s) with measured data and/or + metadata (in most cases, this is the same as INSTRUMENT/software). + If home written, one can provide the actual steps in the NOTE + subfield here. + + + + + Either version with build number, commit hash, or description of a + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + + + + + Website of the software. + + + diff --git a/contributed_definitions/NXopt.nxdl.xml b/contributed_definitions/NXopt.nxdl.xml index 84b1be1259..6875940030 100644 --- a/contributed_definitions/NXopt.nxdl.xml +++ b/contributed_definitions/NXopt.nxdl.xml @@ -983,6 +983,9 @@ Nexus definitions for source, detector, monochromator, ...--> + (Measured) sample thickness. @@ -1001,6 +1004,9 @@ Nexus definitions for source, detector, monochromator, ...--> determined. + Qualitative description of the layer structure for the sample, @@ -1025,9 +1031,12 @@ Nexus definitions for source, detector, monochromator, ...--> - A default view of the data provided in ENTRY/data_collection/measured_data. This - should be the part of the data set which provides the most suitable - representation of the data. + Here generic types of data may be saved.. This may refer to data derived + from single or multiple raw measurements (i.e. several intensities are + evaluated for different parameters: ellipsometry -> psi and delta) - + i.e. non-raw data. + As well plotable data may be stored/linked here, which provides the most suitable + representation of the data (for the respective community). You may provide multiple instances of NXdata @@ -1052,7 +1061,9 @@ Nexus definitions for source, detector, monochromator, ...--> +NXdata. The detailed inclusion of a data collection description (i.e. +raw data from ellipsometry as polarization values to the usually used +psi and delta values), will be done later after the NXopt workshop.--> >>>This section is transfered from the first NXopt version and might @@ -1069,7 +1080,7 @@ NXdata. A detailed rework of this has to be done after the NXopt workshop--> - + Jones quality factor. diff --git a/contributed_definitions/nyaml/NXellipsometry.yaml b/contributed_definitions/nyaml/NXellipsometry.yaml index 852a62a5b2..cabb04c8d1 100644 --- a/contributed_definitions/nyaml/NXellipsometry.yaml +++ b/contributed_definitions/nyaml/NXellipsometry.yaml @@ -104,67 +104,175 @@ NXellipsometry(NXopt): doc: | Define which element rotates, e.g. polarizer or analyzer. enumeration: [polarizer (source side), analyzer (detector side), compensator (source side), compensator (detector side)] - (NXbeam_path): - #light_source(NXsource): - # doc: | - # Specify the used light source. Multiple selection possible. - # source_type: - # enumeration: [arc lamp, halogen lamp, LED, other] - focussing_probes(NXlens_opt): + focussing_probes(NXlens_opt): + exists: optional + doc: | + If focussing probes (lenses) were used, please state if the data + were corrected for the window effects. + # This as well can be stated in window/aperture + data_correction(NX_BOOLEAN): + doc: | + Were the recorded data corrected by the window effects of the + focussing probes (lenses)? + angular_spread(NX_NUMBER): + exists: recommended + unit: NX_ANGLE + doc: | + Specify the angular spread caused by the focussing probes. + rotating_element(NXwaveplate): + exists: optional + doc: | + Properties of the rotating element defined in + 'instrument/rotating_element_type'. + revolutions(NX_NUMBER): exists: optional + unit: NX_COUNT doc: | - If focussing probes (lenses) were used, please state if the data - were corrected for the window effects. - # This as well can be stated in window/aperture - data_correction(NX_BOOLEAN): - doc: | - Were the recorded data corrected by the window effects of the - focussing probes (lenses)? - angular_spread(NX_NUMBER): - exists: recommended - unit: NX_ANGLE - doc: | - Specify the angular spread caused by the focussing probes. - rotating_element(NXwaveplate): + Define how many revolutions of the rotating element were averaged + for each measurement. If the number of revolutions was fixed to a + certain value use the field 'fixed_revolutions' instead. + fixed_revolutions(NX_NUMBER): exists: optional + unit: NX_COUNT doc: | - Properties of the rotating element defined in - 'instrument/rotating_element_type'. - revolutions(NX_NUMBER): - exists: optional - unit: NX_COUNT - doc: | - Define how many revolutions of the rotating element were averaged - for each measurement. If the number of revolutions was fixed to a - certain value use the field 'fixed_revolutions' instead. - fixed_revolutions(NX_NUMBER): - exists: optional - unit: NX_COUNT - doc: | - Define how many revolutions of the rotating element were taken - into account for each measurement (if number of revolutions was - fixed to a certain value, i.e. not averaged). - max_revolutions(NX_NUMBER): - exists: optional - unit: NX_COUNT - doc: | - Specify the maximum value of revolutions of the rotating element - for each measurement. + Define how many revolutions of the rotating element were taken + into account for each measurement (if number of revolutions was + fixed to a certain value, i.e. not averaged). + max_revolutions(NX_NUMBER): + exists: optional + unit: NX_COUNT + doc: | + Specify the maximum value of revolutions of the rotating element + for each measurement. (NXsample): backside_roughness(NX_BOOLEAN): - exists: recommended + exists: optional doc: | Was the backside of the sample roughened? Relevant for infrared ellipsometry. - (NXdata): + # The following NXdata setction called data_collection, is specialization + # from the old (NXopt and NXellipsometry) for the new NXellipometry. + # The generic description of the data collection will in future be + # included in the generic NXopt, but is now keept limited to + # NXellipsometry. + data_collection(NXdata): + doc: | + Measured data, data errors, and varied parameters. This may be used to describe + indirectly derived data or data transformed between different descriptions, + such as: + Raw Data --> Psi + Delta Psi, Delta --> N,C,S + Mueller matrix --> N,C,S + Mueller matrix --> Psi, Delta + etc. + + Other types of data, such as temperature or sample location, may be saved + in a generic (NXdata) concept from NXopt, or better directly in the + location of the sample positioner or temperature sensor. + data_identifier(NX_NUMBER): + doc: | + An identifier to correlate data to the experimental conditions, + if several were used in this measurement; typically an index of 0-N. data_type: doc: | - Select which type of data was recorded, for example Psi and Delta - (see: https://en.wikipedia.org/wiki/Ellipsometry#Data_acquisition). - It is possible to have multiple selections. Data types may also be - converted to each other, e.g. a Mueller matrix contains N,C,S data - as well. - enumeration: [Psi/Delta, tan(Psi)/cos(Delta), Mueller matrix, Jones matrix, N/C/S, raw data] + Select which type of data was recorded, for example intensity, + reflectivity, transmittance, Psi and Delta etc. + It is possible to have multiple selections. The enumeration list + depends on the type of experiment and may differ for different + application definitions. + enumeration: [intensity, reflectivity, transmittance, Psi/Delta, tan(Psi)/cos(Delta), Mueller matrix, Jones matrix, N/C/S, raw data] + + NAME_spectrum(NX_FLOAT): + exists: optional + unit: NX_ANY + doc: | + Spectral values (e.g. wavelength or energy) used for the measurement. + An array of 1 or more elements. Length defines N_spectrum. Replace + 'SPECTRUM' by the physical quantity that is used, e.g. wavelength. + dimensions: + rank: 1 + dim: [[1, N_spectrum]] + \@units: + exists: optional + doc: | + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. + measured_data(NX_FLOAT): + unit: NX_ANY + doc: | + Resulting data from the measurement, described by 'data_type'. + + The first dimension is defined by the number of measurements taken, + (N_measurements). The instructions on how to order the values + contained in the parameter vectors given in the doc string of + INSTRUMENT/sample_stage/environment_conditions/PARAMETER/values, + define the N_measurements parameter sets. For example, if the + experiment was performed at three different temperatures + (T1, T2, T3), two different pressures (p1, p2) and two different + angles of incidence (a1, a2), the first measurement was taken at the + parameters {a1,p1,T1}, the second measurement at {a1,p1,T2} etc. + dimensions: + rank: 3 + dim: [[1, N_measurements], [2, N_observables], [3, N_spectrum]] + \@units: + exists: optional + doc: | + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. + measured_data_errors(NX_FLOAT): + exists: optional + unit: NX_ANY + doc: | + Specified uncertainties (errors) of the data described by 'data_type' + and provided in 'measured_data'. + dimensions: + rank: 3 + dim: [[1, N_measurements], [2, N_observables], [3, N_spectrum]] + \@units: + exists: optional + doc: | + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. + varied_parameter_link: + exists: optional + doc: | + List of links to the values of the sensors. Add a link for each + varied parameter (i.e. for each sensor). + dimensions: + rank: 1 + dim: [[1, N_sensors]] + reference_data_link: + exists: optional + doc: | + Link to the NeXus file which describes the reference data if a + reference measurement was performed. Ideally, the reference + measurement was performed using the same conditions as the actual + measurement and should be as close in time to the actual measurement + as possible. + data_software(NXprogram): + exists: optional + program: + doc: | + Commercial or otherwise defined given name of the program that was + used to generate the result file(s) with measured data and/or + metadata (in most cases, this is the same as INSTRUMENT/software). + If home written, one can provide the actual steps in the NOTE + subfield here. + version: + doc: | + Either version with build number, commit hash, or description of a + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + \@url: + exists: optional + doc: | + Website of the software. + diff --git a/contributed_definitions/nyaml/NXopt.yaml b/contributed_definitions/nyaml/NXopt.yaml index f79655ef34..a592610114 100644 --- a/contributed_definitions/nyaml/NXopt.yaml +++ b/contributed_definitions/nyaml/NXopt.yaml @@ -778,6 +778,7 @@ NXopt(NXobject): exists: recommended enumeration: [air, vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere, sealed can, water, other] thickness(NX_NUMBER): + # Make something like NXlayer_structure_sample? exists: optional doc: | (Measured) sample thickness. @@ -794,6 +795,7 @@ NXopt(NXobject): doc: | If a thickness if given, please specify how this thickness was estimated or determined. layer_structure: + # Maybe consider here to include NXsample_component_set. exists: optional doc: | Qualitative description of the layer structure for the sample, @@ -813,9 +815,12 @@ NXopt(NXobject): a free text description. (NXdata): doc: | - A default view of the data provided in ENTRY/data_collection/measured_data. This - should be the part of the data set which provides the most suitable - representation of the data. + Here generic types of data may be saved.. This may refer to data derived + from single or multiple raw measurements (i.e. several intensities are + evaluated for different parameters: ellipsometry -> psi and delta) - + i.e. non-raw data. + As well plotable data may be stored/linked here, which provides the most suitable + representation of the data (for the respective community). You may provide multiple instances of NXdata \@axes: @@ -832,7 +837,9 @@ NXopt(NXobject): doc: | Location to save the calibrated wavelength data. # The old "data_collection(NXprocess)" is now replaced by more flexbile - # NXdata. A detailed rework of this has to be done after the NXopt workshop + # NXdata. The detailed inclusion of a data collection description (i.e. + # raw data from ellipsometry as polarization values to the usually used + # psi and delta values), will be done later after the NXopt workshop. derived_parameters(NXprocess): exists: optional doc: | @@ -847,7 +854,7 @@ NXopt(NXobject): dimensions: rank: 3 dim: [[1, N_measurements], [2, 1], [3, N_spectrum]] - Jones_quality_factor(NX_NUMBER): + jones_quality_factor(NX_NUMBER): exists: optional unit: NX_UNITLESS doc: | From 69c30318b06c29e8d85df5310f20acc5a6384e65 Mon Sep 17 00:00:00 2001 From: Rubel Date: Thu, 16 May 2024 13:00:24 +0200 Subject: [PATCH 0689/1012] Fix current_calibration, current_gain, setteling_time in NXsts. --- contributed_definitions/NXsts.nxdl.xml | 9 ++++++--- contributed_definitions/nyaml/NXsts.yaml | 19 +++++++++++++------ 2 files changed, 19 insertions(+), 9 deletions(-) diff --git a/contributed_definitions/NXsts.nxdl.xml b/contributed_definitions/NXsts.nxdl.xml index 5f778c9c35..16d7ef0894 100644 --- a/contributed_definitions/NXsts.nxdl.xml +++ b/contributed_definitions/NXsts.nxdl.xml @@ -25,6 +25,8 @@ 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the--> + Application definition for temperature-dependent IV curve measurements @@ -323,7 +325,8 @@ doc: The rate at which the one of the signal changes when ramping to the startin - An environmental setup to measure the tunneling current due to different tip-sample biases. + An environmental setup to measure the tunneling current due to different tip- + sample biases. @@ -332,13 +335,13 @@ doc: The rate at which the one of the signal changes when ramping to the startin in the constant height mode means the real tunnelling current between tip and sample). - + Value of calibration that comes as A/V. - + diff --git a/contributed_definitions/nyaml/NXsts.yaml b/contributed_definitions/nyaml/NXsts.yaml index ee58feebfd..fa29e127e8 100644 --- a/contributed_definitions/nyaml/NXsts.yaml +++ b/contributed_definitions/nyaml/NXsts.yaml @@ -21,6 +21,8 @@ doc: | # 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the +# 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the + # 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the type: group NXsts(NXsensor_scan): @@ -277,7 +279,8 @@ NXsts(NXsensor_scan): Use the button to enable or disable the drift compensation. (e.g. FALSE) (NXenvironment): doc: | - An environmental setup to measure the tunneling current due to different tip-sample biases. + An environmental setup to measure the tunneling current due to different tip- + sample biases. current_sensor(NXsensor): exists: optional current(NX_NUMBER): @@ -286,13 +289,14 @@ NXsts(NXsensor_scan): This is set-point of tip current (in the constant current mode should be equal to set-point, in the constant height mode means the real tunnelling current between tip and sample). current_calibration(NX_NUMBER): - unit: NX_CURRENT + unit: NX_ANY doc: | Value of calibration that comes as A/V. current_offset(NX_NUMBER): unit: NX_CURRENT current_gain(NX_NUMBER): unit: NX_UNITLESS + exists: optional calibration_time(NX_DATE_TIME): exists: optional value(NX_NUMBER): @@ -878,7 +882,7 @@ NXsts(NXsensor_scan): Mesh scan with 2D slices of the above alternative plot for other y co-ordinates. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 73b9167972d2988b8c75a60e04a9c2db349cf2fbe052958f3908c632f8d8eba1 +# 9df72436401554d5eee6c52834eaac976332fbef5105b592123bf655e34bc1bd # # # # +# # # # Application definition for temperature-dependent IV curve measurements @@ -1204,7 +1210,8 @@ NXsts(NXsensor_scan): # # # -# An environmental setup to measure the tunneling current due to different tip-sample biases. +# An environmental setup to measure the tunneling current due to different tip- +# sample biases. # # # @@ -1213,13 +1220,13 @@ NXsts(NXsensor_scan): # in the constant height mode means the real tunnelling current between tip and sample). # # -# +# # # Value of calibration that comes as A/V. # # # -# +# # # # From 39b7c20479c913fead3793019f9a9a3d4b507989 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 16 May 2024 13:47:12 +0200 Subject: [PATCH 0690/1012] add explicit units in NXmpes proces --- contributed_definitions/NXmpes.nxdl.xml | 6 +++--- contributed_definitions/nyaml/NXmpes.yaml | 11 +++++++---- 2 files changed, 10 insertions(+), 7 deletions(-) diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index 42d0c08240..75165724ed 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -588,9 +588,9 @@ - - - + + + diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index a1732140e1..7364bf7e25 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -519,10 +519,13 @@ NXmpes(NXobject): exists: recommended reference_peak: binding_energy(NX_FLOAT): + unit: NX_ENERGY exists: recommended offset(NX_FLOAT): + unit: NX_ENERGY exists: recommended calibrated_axis(NX_FLOAT): + unit: NX_ENERGY exists: recommended transmission_correction(NXcalibration): exists: optional @@ -715,7 +718,7 @@ NXmpes(NXobject): @energy_depends: 'entry/process/energy_calibration' # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# db4a4cfbfbe89a1209cbbd2877617af97ee64d240a15dc498c5c3f65b52e77ad +# 7f45ab08c78a105a15e2c6f5ddbcdcab4002929bf8d19e8ec2987bd507525680 # # # + Application definition for temperature-dependent IV curve measurements @@ -131,6 +133,15 @@ crosstalk_compensation: Current amplifier> Capacitive cross-talk compensation: Y Status of Lock-in device whether while performing the experiment + + + Select whether to set the Lock-In to run during the measurement. When using this + feature, make sure the Lock-In is configured correctly and settling times are + set to twice the Lock-In period at least. This option is ignored when Lock-In is + already running. This option is disabled if the Sweep Mode is MLS and the flag + to configure the Lock-In per segment in the Multiline segment editor is set. + + +when saving. Using this option increases the sweep time by Z averaging time. (e.g. FALSE)--> Bias voltage applied to the sample. diff --git a/contributed_definitions/nyaml/NXsts.yaml b/contributed_definitions/nyaml/NXsts.yaml index fa29e127e8..b7b1528622 100644 --- a/contributed_definitions/nyaml/NXsts.yaml +++ b/contributed_definitions/nyaml/NXsts.yaml @@ -23,6 +23,8 @@ doc: | # 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the +# 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the + # 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the type: group NXsts(NXsensor_scan): @@ -91,6 +93,14 @@ NXsts(NXsensor_scan): # status: Lock-in>Lock-in status ON # ON/OFF of Lock-in amplifier doc: | Status of Lock-in device whether while performing the experiment + run: + exists: optional + doc: | + Select whether to set the Lock-In to run during the measurement. When using this + feature, make sure the Lock-In is configured correctly and settling times are + set to twice the Lock-In period at least. This option is ignored when Lock-In is + already running. This option is disabled if the Sweep Mode is MLS and the flag + to configure the Lock-In per segment in the Multiline segment editor is set. # amplifier_status: -> amplifier/active_channels # Lock-in Amplifier>Yes/No @@ -165,13 +175,6 @@ NXsts(NXsensor_scan): # doc: Select whether to record the Z position during Z averaging time at the end of the # sweep (after Z control time) and store the average value in the header of the file # when saving. Using this option increases the sweep time by Z averaging time. (e.g. FALSE) - # run: - # doc: Bias Spectroscopy>Lock-In run FALSE # Select whether to set the Lock-In to run - # during the measurement. When using this feature, make sure the Lock-In is configured - # correctly and settling times are set to twice the Lock-In period at least. This - # option is ignored when Lock-In is already running. This option is disabled if the - # Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline - # segment editor is set. sample_bias(NXiv_bias): doc: | Bias voltage applied to the sample. @@ -882,7 +885,7 @@ NXsts(NXsensor_scan): Mesh scan with 2D slices of the above alternative plot for other y co-ordinates. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 9df72436401554d5eee6c52834eaac976332fbef5105b592123bf655e34bc1bd +# f8791239d512dee3324d81260123aead0021f6201d6947f100eddbf2c7cf4beb # # # # +# # # # Application definition for temperature-dependent IV curve measurements @@ -1016,6 +1021,15 @@ NXsts(NXsensor_scan): # Status of Lock-in device whether while performing the experiment # # +# +# +# Select whether to set the Lock-In to run during the measurement. When using this +# feature, make sure the Lock-In is configured correctly and settling times are +# set to twice the Lock-In period at least. This option is ignored when Lock-In is +# already running. This option is disabled if the Sweep Mode is MLS and the flag +# to configure the Lock-In per segment in the Multiline segment editor is set. +# +# # +# when saving. Using this option increases the sweep time by Z averaging time. (e.g. FALSE)--> # # # Bias voltage applied to the sample. From c27887976671e91258d2b362d3c7aea2fb6ec6dc Mon Sep 17 00:00:00 2001 From: Rubel Date: Fri, 17 May 2024 10:55:53 +0200 Subject: [PATCH 0692/1012] make some groups and fields optional that do not get data from raw data file. --- contributed_definitions/nyaml/NXsts.nxdl.xml | 954 +++++++++++++++++++ contributed_definitions/nyaml/NXsts.yaml | 3 + 2 files changed, 957 insertions(+) create mode 100644 contributed_definitions/nyaml/NXsts.nxdl.xml diff --git a/contributed_definitions/nyaml/NXsts.nxdl.xml b/contributed_definitions/nyaml/NXsts.nxdl.xml new file mode 100644 index 0000000000..bb3488eca5 --- /dev/null +++ b/contributed_definitions/nyaml/NXsts.nxdl.xml @@ -0,0 +1,954 @@ + + + + + + + + + + + Application definition for temperature-dependent IV curve measurements + #2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the + STM image mode in the future with a focus on bias spectroscopy in Scanning Tunneling Microscopy. + + In this application definition, times should be specified always together with a UTC offset. + + This is the application definition describing temperature (T) dependent current voltage (IV) curve + measurements. For this, a temperature is set. After reaching the temperature, a voltage sweep + is performed. For each voltage, a current is measured. + Then, the next desired temperature is set and an IV measurement is performed. + The data can be visualized in a tensor with: + I (NXsensor_C, NXsoftware_Read_offset, NXcircuit) + parameters: + V has (NXsource+offset, NXsoftware_Scan_offset, NXsensor_V, NXcircuit) + T has (NXsource, NXsoftware_Scan_offset, NXsensor_T) + x has (NXsoftware_Scan_offset) + y has (NXsoftware_Scan_offset) + z has (NXsoftware_Scan_offset) + + + + + + + + + + Name of the experiment where the application is applicable. + + + + + + + + + The equipments and techniques as well as the parameter settings and reference signals + are used during the experiments used in Scanning Tunneling Microscopy (STM). + + + + + + + + + + + The name of the output file, with the number of scans at the end. (e.g. + 221122_Au_5K00014) + + + + + The name of the series output file, which represents only the public part of the + output file. (e.g. 221122_Au_5K) + + + + + Path to storage of output files. + (e.g. Path C:\Users\SPM-PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis-Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711) + + + + + Descriptive comments for this experiment, added by the experimenter, coming from the + output file. (e.g. Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, locked Au(111), + 50pA, 100 mV set point, 1mV DCA, 973Hz,138 1st H, -84 2nd H) + + + + + + Hardware type used in SPM experiment, includes hardware manufacturers and type. + (e.g. Nanonis BP5e) + + + + + + Type of software used in SPM experiments, such as software version serial number, UI and + RT probe release method. (e.g. SW Version Generic 5e -- RT Release 10771) + + + + + + The Amplifier description that improves or helps to determine tunnel current (current + between tip and bias). + + + + + + + Status of Lock-in device whether while performing the experiment + + + + + Select whether to set the Lock-In to run during the measurement. When using this + feature, make sure the Lock-In is configured correctly and settling times are + set to twice the Lock-In period at least. This option is ignored when Lock-In is + already running. This option is disabled if the Sweep Mode is MLS and the flag + to configure the Lock-In per segment in the Multiline segment editor is set. + + + + + + This is the signal on which the modulation (sine) will be added. + + + + + + + The signal is modulated by adding the frequency of the sine modulation. The + modulation frequency spans can be from 10 mHz to 40 kHz, corresponding to the output filter + cut-off range. When dealing with harmonics, it's essential to ensure that the + harmonic frequencies remain below ~100 kHz, which aligns with the input filter cut-off. + Be mindful that hardware filters might impact the amplitude as the signal approaches + their cut-off frequencies." (e.g. 973E+0) + + + + + + The amplitude (in physical units of modulated signal) of the sine modulation. + + + + + + The input signal (STS signal) will be demodulated, in order to determine the amplitude + and phase at the frequency set in the Frequency field or harmonics, such as current, + bias, et.al. + + + + + + N denotes 1 or 2. The order of the harmonic oscillation to be detected in the demodulated + signal should be considered relative to the modulation frequency. When dealing with + higher harmonics, it's essential to ensure that their frequencies do not surpass + the analogue signal bandwidth (e.g. harmonic_order_1). + + + + + + Reference phase for the sine on the demodulated signal with respect to the + modulation signal. The determined phase is displayed with respect to the + reference phase. + + + + + + + + Bias voltage applied to the sample. + + + + Applied a voltage between tip and sample. + + + + + + + + + Temperature of STM head. Note: At least one field from stm_head_temperature, + cryo_bottom_temp and cryo_sheild_temp must be provided. + + + + + Temperature of liquid helium cryostat. Note: At least one field from + stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp must be provided. + + + + + Temperature of liquid nitrogen shield. Temperature 3 (K) (e.g 78.00000E+0). Note: At + least one field from stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp + must be provided. + + + + + + + Configuration for piezoelectric scanner used to move tip along X and Y direction. The + material of the Piezoelectric scanner composed of polycrystalline solids and sensitive to + applied voltage. + + + + The name of calibration type. (e.g. LHe) + + + + + N denotes X or Y or Z. There are three parameters in the X, Y, and Z directions, + along with three available controls: Calibration (m/V), Range (m), and HV gain. Only + two of these parameters are required to define the calibration. Consequently, when any + value is changed, one of the other values will be automatically updated. (e.g. calib_X = 3.8E-9) + + + + + N denotes X or Y or Z. In some systems, there is an HV gain readout feature. For + these systems, the HV gain should be automatically adjusted whenever the gain is + changed at the high voltage amplifier. (e.g. 14.5) + + + + + + N denotes X or Y. There are 2 parameters in X and Y directions, and tilt needs to be + adjusted according to the actual surface. (in degrees, first order correction). + + + + + + N denotes X or Y. There are 2 parameters in X and Y directions. (can be set + approximately to the length of the piezotube). + + + + + N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, + you can enter the 2nd order piezo characteristics to compensate for it. The + following equation shows the interpretation of the 2nd order correction parameter: + For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: + [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx + is the 2nd order correction. (V/m^2). (e.g. 0E+0) + + + + + N denotes X, Y or Z. There are 3 parameters in X, Y and Z directions. Define the + drift speed for all three axes. When the compensation is on, the piezos will start to + move at that speed. (e.g. 0E+0) + + + + + Use the button to enable or disable the drift compensation. (e.g. FALSE) + + + + + + An environmental setup to measure the tunneling current due to different tip- + sample biases. + + + + + This is set-point of tip current (in the constant current mode should be equal to set-point, + in the constant height mode means the real tunnelling current between tip and sample). + + + + + Value of calibration that comes as A/V. + + + + + + + + + + Clarify the frame laboratory frame. + + + + The scanning area in x position in the frame. (e.g. -890.53E-12) + + + + + The scanning area in y position in the frame. (e.g. 29.6968E-9) + + + + + The scanning area in z position in the frame. (e.g. 130.5E-9) + + + + + + Indicate the relative tip position z between tip and sample. The tip position can also + be varied when the z_controller is not running. (e.g. 130.5E-9) + + + + + + + + + + Time during which the spectroscopy data are acquired and averaged. (e.g. 150E-6) + + + + + Number of sweeps to measure and average. (e.g. 100) + + + + + The start bias values of the sweep. (e.g. -300E-3) + + + + + The end bias values of the sweep. (e.g. 300E-3) + + + + + The sweep number of points is defined as the maximum spectrum resolution, which + is equal to the bias sweep window divided by the number of pixels. (e.g. 4096) + + + + + The Z position is recorded and averaged for a certain duration both before and + after the sweep. After the initial Z averaging time, if "Z-Controller to Hold" + is selected, the Z-Controller is set to hold mode, and the tip is positioned at + the previously averaged Z position (adjusted by the Z offset). (e.g. 100E-3) + + + + + + + The bandwidth of the Hardware and/or Software is instrument specific. + For example, Nanonis Generic 5 has 'RT Frequency' (e.g. 20E+3). + + + + + The Signals Period represents the rate at which signals are transferred to + the host computer, which operates the control software. This rate may + be 10 times lower than the sampling rate, as the real-time engine internally + oversamples the signal. If desired, you may have the option to reduce the oversampling + to 1, enabling higher frequency resolution in the Spectrum Analyzer. (e.g. 10) + + + + + The update rate is utilized in various processes, including the History Graph, + Auto-Approach, and multiple Programming Interface functions. It may be + configured to a 20 ms interval. Any additional timings must strictly be integer + multiples of this base value. While it is possible to set these additional + timings to different values, the actual timing value will automatically be + adjusted to become a multiple of the Acquisition Period. (e.g. 20E-3) + + + + + The update rate of animated graphical indicators, such as graphs and sliders, + can be adjusted. A normal value may be 40 ms, which corresponds to 25 updates + per second. Increasing this period can help reduce the processor load on the + graphical user interface, particularly on slower computers. It is important to + note that this update rate solely impacts the user interface and does not affect + measurements in any manner. (e.g. 20E-3) + + + + + The update rate of digital indicators, such as the numbers displayed, can be set + to 3 updates per second, equivalent to 300 ms. This interval is sufficient for + the user interface and does not impact measurements in any manner. (e.g. 300E-3) + + + + + The Measurements period determines the integration time required for precise + measurements, primarily utilized in sweep modules. It is particularly useful for + tasks such as recording force-distance curves or cantilever resonances. For + swift measurements with small steps, a value of 40 ms is often adequate. For + regular use, a range of 300-500 ms may be recommended, but when capturing the + resonance of a high-Q cantilever, longer values in the range of several seconds + might be necessary. Usually, this parameter does not require manual adjustment + within this module, as the sweep modules automatically set this value according + to the sweep timings. (e.g. 500E-3) + + + + + + + + + + Also clarify the frame for the ROI of the scan in lab frame, the middle of the lab + frame is (0, 0), and positive in x means right and in y means up. + + + + + + + The scan channels are selected by users. (e.g. (A);Bias (V);Z (m);LI Demod 2 X + (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A)) + + + + + + + Configure the scan frame like x position; y position; width; height. (e.g. + 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0) + + + + + Scan resolution by setting the Lines equal to Pixels. (e.g. 512) + + + + + Define the image resolution. (e.g. 512) + + + + + Define the scan forward speed in the forward direction. (m/s) (e.g. 11.7187E-9) + + + + + Define the scan backward speed in the forward direction. (m/s) (e.g. 11.7187E-9) + + + + + + + + + + + + Link to target: /NXentry/NXinstrument/stm_head_temp + + + + + + Link to target: /NXentry/NXinstrument/cryo_bottom_temp + + + + + + Link to target: /NXentry/NXinstrument/temp_cryo_shield + + + + + + Link to target: /NXentry/NXinstrument/NXlock_in/modulation_signal + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/NXintegration_time + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/number_of_sweeps + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/sweep_start + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/sweep_end + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/num_pixel + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_avg_time + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/rt_frequency + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/signals_oversampling + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/acquisition_period + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/animations_period + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/indicators_period + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/measurements_period + + + + + + + + + Link to target: /NXentry/NXinstrument/NXsample_bias/bias + + + + + + Link to target: /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current + + + + + + Link to target: /NXentry/NXnstrument/NXsample_bias/bias_calibration + + + + + Link to target: /NXentry/NXinstrument/NXsample_bias/bias_offset + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_calibration + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_offset + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_gain + + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_offset + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/settling_time + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_ccontroller_hold + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/record_final_z + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/first_settling_time + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/end_settling_time + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_control_time + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/max_slew_rate + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/backward_sweep + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/controller_name + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/controller_status + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/set_point + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/p_gain + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/i_gain + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/time_const + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/tip_lift + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/switchoff_delay + + + + + + To describe sample and other constaints that applied on sample before scanning. + + + + At this moment no base class available that can track entire sample preparation. + + + + + + + This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. + There should also be two more fields called temperature and voltage containing the setpoint values. + There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension + equal to the number of voltage setpoints. + axes: bias_calc + signals: + li_demod_[1;2]_[X/Y]_[-;bwd;filt;bwd_filt] + current_[-;bwd;filt;bwd_filt] + temperature + + + + + + Plot for a single point (x,y) with I vs. V curve. + + + + + + Line scan with multiple I vs. V curves for different single (x,y) co-ordinates. + + + + + + Plot for current(I) curve in the 2D space of (position(x), bias(V)) which can be + derived from the `line_scan` plot. + + + + + + Mesh scan with 2D slices of the above alternative plot for other y co-ordinates. + + + + diff --git a/contributed_definitions/nyaml/NXsts.yaml b/contributed_definitions/nyaml/NXsts.yaml index b7b1528622..70685118c1 100644 --- a/contributed_definitions/nyaml/NXsts.yaml +++ b/contributed_definitions/nyaml/NXsts.yaml @@ -420,11 +420,13 @@ NXsts(NXsensor_scan): scan_control(NXcollection): exists: optional roi(NXtransformations): + exists: optional frame: doc: | Also clarify the frame for the ROI of the scan in lab frame, the middle of the lab frame is (0, 0), and positive in x means right and in y means up. circuit(NXcollection): + exists: optional channels_current: doc: | The scan channels are selected by users. (e.g. (A);Bias (V);Z (m);LI Demod 2 X @@ -816,6 +818,7 @@ NXsts(NXsensor_scan): doc: | To describe sample and other constaints that applied on sample before scanning. sample_prep_descripton: + exists: optional doc: | At this moment no base class available that can track entire sample preparation. From 71147f60ff16d68ced0d9c1ecc0710a2c31ab4a9 Mon Sep 17 00:00:00 2001 From: Rubel Date: Fri, 17 May 2024 11:10:32 +0200 Subject: [PATCH 0693/1012] make some groups and fields optional that do not get data from raw data file. --- contributed_definitions/NXsts.nxdl.xml | 8 +- contributed_definitions/nyaml/NXsts.nxdl.xml | 954 ------------------- contributed_definitions/nyaml/NXsts.yaml | 4 +- 3 files changed, 7 insertions(+), 959 deletions(-) delete mode 100644 contributed_definitions/nyaml/NXsts.nxdl.xml diff --git a/contributed_definitions/NXsts.nxdl.xml b/contributed_definitions/NXsts.nxdl.xml index a4ed3bfec2..bb3488eca5 100644 --- a/contributed_definitions/NXsts.nxdl.xml +++ b/contributed_definitions/NXsts.nxdl.xml @@ -29,6 +29,8 @@ 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the--> + Application definition for temperature-dependent IV curve measurements @@ -478,7 +480,7 @@ parameters for a measurement at a single location during the scan--> - + Also clarify the frame for the ROI of the scan in lab frame, the middle of the lab @@ -486,7 +488,7 @@ parameters for a measurement at a single location during the scan--> - + The scan channels are selected by users. (e.g. (A);Bias (V);Z (m);LI Demod 2 X @@ -876,7 +878,7 @@ is switched off, it doesn't switch off immediately but continues to run for the To describe sample and other constaints that applied on sample before scanning. - + At this moment no base class available that can track entire sample preparation. diff --git a/contributed_definitions/nyaml/NXsts.nxdl.xml b/contributed_definitions/nyaml/NXsts.nxdl.xml deleted file mode 100644 index bb3488eca5..0000000000 --- a/contributed_definitions/nyaml/NXsts.nxdl.xml +++ /dev/null @@ -1,954 +0,0 @@ - - - - - - - - - - - Application definition for temperature-dependent IV curve measurements - #2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the - STM image mode in the future with a focus on bias spectroscopy in Scanning Tunneling Microscopy. - - In this application definition, times should be specified always together with a UTC offset. - - This is the application definition describing temperature (T) dependent current voltage (IV) curve - measurements. For this, a temperature is set. After reaching the temperature, a voltage sweep - is performed. For each voltage, a current is measured. - Then, the next desired temperature is set and an IV measurement is performed. - The data can be visualized in a tensor with: - I (NXsensor_C, NXsoftware_Read_offset, NXcircuit) - parameters: - V has (NXsource+offset, NXsoftware_Scan_offset, NXsensor_V, NXcircuit) - T has (NXsource, NXsoftware_Scan_offset, NXsensor_T) - x has (NXsoftware_Scan_offset) - y has (NXsoftware_Scan_offset) - z has (NXsoftware_Scan_offset) - - - - - - - - - - Name of the experiment where the application is applicable. - - - - - - - - - The equipments and techniques as well as the parameter settings and reference signals - are used during the experiments used in Scanning Tunneling Microscopy (STM). - - - - - - - - - - - The name of the output file, with the number of scans at the end. (e.g. - 221122_Au_5K00014) - - - - - The name of the series output file, which represents only the public part of the - output file. (e.g. 221122_Au_5K) - - - - - Path to storage of output files. - (e.g. Path C:\Users\SPM-PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis-Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711) - - - - - Descriptive comments for this experiment, added by the experimenter, coming from the - output file. (e.g. Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, locked Au(111), - 50pA, 100 mV set point, 1mV DCA, 973Hz,138 1st H, -84 2nd H) - - - - - - Hardware type used in SPM experiment, includes hardware manufacturers and type. - (e.g. Nanonis BP5e) - - - - - - Type of software used in SPM experiments, such as software version serial number, UI and - RT probe release method. (e.g. SW Version Generic 5e -- RT Release 10771) - - - - - - The Amplifier description that improves or helps to determine tunnel current (current - between tip and bias). - - - - - - - Status of Lock-in device whether while performing the experiment - - - - - Select whether to set the Lock-In to run during the measurement. When using this - feature, make sure the Lock-In is configured correctly and settling times are - set to twice the Lock-In period at least. This option is ignored when Lock-In is - already running. This option is disabled if the Sweep Mode is MLS and the flag - to configure the Lock-In per segment in the Multiline segment editor is set. - - - - - - This is the signal on which the modulation (sine) will be added. - - - - - - - The signal is modulated by adding the frequency of the sine modulation. The - modulation frequency spans can be from 10 mHz to 40 kHz, corresponding to the output filter - cut-off range. When dealing with harmonics, it's essential to ensure that the - harmonic frequencies remain below ~100 kHz, which aligns with the input filter cut-off. - Be mindful that hardware filters might impact the amplitude as the signal approaches - their cut-off frequencies." (e.g. 973E+0) - - - - - - The amplitude (in physical units of modulated signal) of the sine modulation. - - - - - - The input signal (STS signal) will be demodulated, in order to determine the amplitude - and phase at the frequency set in the Frequency field or harmonics, such as current, - bias, et.al. - - - - - - N denotes 1 or 2. The order of the harmonic oscillation to be detected in the demodulated - signal should be considered relative to the modulation frequency. When dealing with - higher harmonics, it's essential to ensure that their frequencies do not surpass - the analogue signal bandwidth (e.g. harmonic_order_1). - - - - - - Reference phase for the sine on the demodulated signal with respect to the - modulation signal. The determined phase is displayed with respect to the - reference phase. - - - - - - - - Bias voltage applied to the sample. - - - - Applied a voltage between tip and sample. - - - - - - - - - Temperature of STM head. Note: At least one field from stm_head_temperature, - cryo_bottom_temp and cryo_sheild_temp must be provided. - - - - - Temperature of liquid helium cryostat. Note: At least one field from - stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp must be provided. - - - - - Temperature of liquid nitrogen shield. Temperature 3 (K) (e.g 78.00000E+0). Note: At - least one field from stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp - must be provided. - - - - - - - Configuration for piezoelectric scanner used to move tip along X and Y direction. The - material of the Piezoelectric scanner composed of polycrystalline solids and sensitive to - applied voltage. - - - - The name of calibration type. (e.g. LHe) - - - - - N denotes X or Y or Z. There are three parameters in the X, Y, and Z directions, - along with three available controls: Calibration (m/V), Range (m), and HV gain. Only - two of these parameters are required to define the calibration. Consequently, when any - value is changed, one of the other values will be automatically updated. (e.g. calib_X = 3.8E-9) - - - - - N denotes X or Y or Z. In some systems, there is an HV gain readout feature. For - these systems, the HV gain should be automatically adjusted whenever the gain is - changed at the high voltage amplifier. (e.g. 14.5) - - - - - - N denotes X or Y. There are 2 parameters in X and Y directions, and tilt needs to be - adjusted according to the actual surface. (in degrees, first order correction). - - - - - - N denotes X or Y. There are 2 parameters in X and Y directions. (can be set - approximately to the length of the piezotube). - - - - - N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, - you can enter the 2nd order piezo characteristics to compensate for it. The - following equation shows the interpretation of the 2nd order correction parameter: - For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: - [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx - is the 2nd order correction. (V/m^2). (e.g. 0E+0) - - - - - N denotes X, Y or Z. There are 3 parameters in X, Y and Z directions. Define the - drift speed for all three axes. When the compensation is on, the piezos will start to - move at that speed. (e.g. 0E+0) - - - - - Use the button to enable or disable the drift compensation. (e.g. FALSE) - - - - - - An environmental setup to measure the tunneling current due to different tip- - sample biases. - - - - - This is set-point of tip current (in the constant current mode should be equal to set-point, - in the constant height mode means the real tunnelling current between tip and sample). - - - - - Value of calibration that comes as A/V. - - - - - - - - - - Clarify the frame laboratory frame. - - - - The scanning area in x position in the frame. (e.g. -890.53E-12) - - - - - The scanning area in y position in the frame. (e.g. 29.6968E-9) - - - - - The scanning area in z position in the frame. (e.g. 130.5E-9) - - - - - - Indicate the relative tip position z between tip and sample. The tip position can also - be varied when the z_controller is not running. (e.g. 130.5E-9) - - - - - - - - - - Time during which the spectroscopy data are acquired and averaged. (e.g. 150E-6) - - - - - Number of sweeps to measure and average. (e.g. 100) - - - - - The start bias values of the sweep. (e.g. -300E-3) - - - - - The end bias values of the sweep. (e.g. 300E-3) - - - - - The sweep number of points is defined as the maximum spectrum resolution, which - is equal to the bias sweep window divided by the number of pixels. (e.g. 4096) - - - - - The Z position is recorded and averaged for a certain duration both before and - after the sweep. After the initial Z averaging time, if "Z-Controller to Hold" - is selected, the Z-Controller is set to hold mode, and the tip is positioned at - the previously averaged Z position (adjusted by the Z offset). (e.g. 100E-3) - - - - - - - The bandwidth of the Hardware and/or Software is instrument specific. - For example, Nanonis Generic 5 has 'RT Frequency' (e.g. 20E+3). - - - - - The Signals Period represents the rate at which signals are transferred to - the host computer, which operates the control software. This rate may - be 10 times lower than the sampling rate, as the real-time engine internally - oversamples the signal. If desired, you may have the option to reduce the oversampling - to 1, enabling higher frequency resolution in the Spectrum Analyzer. (e.g. 10) - - - - - The update rate is utilized in various processes, including the History Graph, - Auto-Approach, and multiple Programming Interface functions. It may be - configured to a 20 ms interval. Any additional timings must strictly be integer - multiples of this base value. While it is possible to set these additional - timings to different values, the actual timing value will automatically be - adjusted to become a multiple of the Acquisition Period. (e.g. 20E-3) - - - - - The update rate of animated graphical indicators, such as graphs and sliders, - can be adjusted. A normal value may be 40 ms, which corresponds to 25 updates - per second. Increasing this period can help reduce the processor load on the - graphical user interface, particularly on slower computers. It is important to - note that this update rate solely impacts the user interface and does not affect - measurements in any manner. (e.g. 20E-3) - - - - - The update rate of digital indicators, such as the numbers displayed, can be set - to 3 updates per second, equivalent to 300 ms. This interval is sufficient for - the user interface and does not impact measurements in any manner. (e.g. 300E-3) - - - - - The Measurements period determines the integration time required for precise - measurements, primarily utilized in sweep modules. It is particularly useful for - tasks such as recording force-distance curves or cantilever resonances. For - swift measurements with small steps, a value of 40 ms is often adequate. For - regular use, a range of 300-500 ms may be recommended, but when capturing the - resonance of a high-Q cantilever, longer values in the range of several seconds - might be necessary. Usually, this parameter does not require manual adjustment - within this module, as the sweep modules automatically set this value according - to the sweep timings. (e.g. 500E-3) - - - - - - - - - - Also clarify the frame for the ROI of the scan in lab frame, the middle of the lab - frame is (0, 0), and positive in x means right and in y means up. - - - - - - - The scan channels are selected by users. (e.g. (A);Bias (V);Z (m);LI Demod 2 X - (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A)) - - - - - - - Configure the scan frame like x position; y position; width; height. (e.g. - 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0) - - - - - Scan resolution by setting the Lines equal to Pixels. (e.g. 512) - - - - - Define the image resolution. (e.g. 512) - - - - - Define the scan forward speed in the forward direction. (m/s) (e.g. 11.7187E-9) - - - - - Define the scan backward speed in the forward direction. (m/s) (e.g. 11.7187E-9) - - - - - - - - - - - - Link to target: /NXentry/NXinstrument/stm_head_temp - - - - - - Link to target: /NXentry/NXinstrument/cryo_bottom_temp - - - - - - Link to target: /NXentry/NXinstrument/temp_cryo_shield - - - - - - Link to target: /NXentry/NXinstrument/NXlock_in/modulation_signal - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/NXintegration_time - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/number_of_sweeps - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/sweep_start - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/sweep_end - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/num_pixel - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_avg_time - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/rt_frequency - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/signals_oversampling - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/acquisition_period - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/animations_period - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/indicators_period - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/measurements_period - - - - - - - - - Link to target: /NXentry/NXinstrument/NXsample_bias/bias - - - - - - Link to target: /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current - - - - - - Link to target: /NXentry/NXnstrument/NXsample_bias/bias_calibration - - - - - Link to target: /NXentry/NXinstrument/NXsample_bias/bias_offset - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_calibration - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_offset - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_gain - - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_offset - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/settling_time - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_ccontroller_hold - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/record_final_z - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/first_settling_time - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/end_settling_time - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_control_time - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/max_slew_rate - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/backward_sweep - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/controller_name - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/controller_status - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/set_point - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/p_gain - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/i_gain - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/time_const - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/tip_lift - - - - - - Link to target: - /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/switchoff_delay - - - - - - To describe sample and other constaints that applied on sample before scanning. - - - - At this moment no base class available that can track entire sample preparation. - - - - - - - This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. - There should also be two more fields called temperature and voltage containing the setpoint values. - There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension - equal to the number of voltage setpoints. - axes: bias_calc - signals: - li_demod_[1;2]_[X/Y]_[-;bwd;filt;bwd_filt] - current_[-;bwd;filt;bwd_filt] - temperature - - - - - - Plot for a single point (x,y) with I vs. V curve. - - - - - - Line scan with multiple I vs. V curves for different single (x,y) co-ordinates. - - - - - - Plot for current(I) curve in the 2D space of (position(x), bias(V)) which can be - derived from the `line_scan` plot. - - - - - - Mesh scan with 2D slices of the above alternative plot for other y co-ordinates. - - - - diff --git a/contributed_definitions/nyaml/NXsts.yaml b/contributed_definitions/nyaml/NXsts.yaml index 70685118c1..227ac33506 100644 --- a/contributed_definitions/nyaml/NXsts.yaml +++ b/contributed_definitions/nyaml/NXsts.yaml @@ -816,11 +816,11 @@ NXsts(NXsensor_scan): sample(NXsample): exists: optional doc: | - To describe sample and other constaints that applied on sample before scanning. + To describe the sample and other constraints that are applied to that sample before scanning. sample_prep_descripton: exists: optional doc: | - At this moment no base class available that can track entire sample preparation. + At this moment no base class is available that can track entire sample preparation. # TODO: discuss convertion data to DATA (NXdata): From d149bb759d3e8f901c614b3ae99d8f4164c2ea15 Mon Sep 17 00:00:00 2001 From: Rubel Date: Fri, 17 May 2024 11:15:51 +0200 Subject: [PATCH 0694/1012] make some groups and fields optional that do not get data from raw data file. --- contributed_definitions/NXsts.nxdl.xml | 6 ++++-- contributed_definitions/nyaml/NXsts.yaml | 26 ++++++++++++++++-------- 2 files changed, 21 insertions(+), 11 deletions(-) diff --git a/contributed_definitions/NXsts.nxdl.xml b/contributed_definitions/NXsts.nxdl.xml index bb3488eca5..b00b88e23e 100644 --- a/contributed_definitions/NXsts.nxdl.xml +++ b/contributed_definitions/NXsts.nxdl.xml @@ -876,11 +876,13 @@ is switched off, it doesn't switch off immediately but continues to run for the - To describe sample and other constaints that applied on sample before scanning. + To describe the sample and other constraints that are applied to that sample + before scanning. - At this moment no base class available that can track entire sample preparation. + At this moment no base class is available that can track entire sample + preparation. diff --git a/contributed_definitions/nyaml/NXsts.yaml b/contributed_definitions/nyaml/NXsts.yaml index 227ac33506..232d5c9f09 100644 --- a/contributed_definitions/nyaml/NXsts.yaml +++ b/contributed_definitions/nyaml/NXsts.yaml @@ -25,6 +25,8 @@ doc: | # 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the +# 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the + # 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the type: group NXsts(NXsensor_scan): @@ -420,7 +422,7 @@ NXsts(NXsensor_scan): scan_control(NXcollection): exists: optional roi(NXtransformations): - exists: optional + exists: optional frame: doc: | Also clarify the frame for the ROI of the scan in lab frame, the middle of the lab @@ -816,11 +818,13 @@ NXsts(NXsensor_scan): sample(NXsample): exists: optional doc: | - To describe the sample and other constraints that are applied to that sample before scanning. + To describe the sample and other constraints that are applied to that sample + before scanning. sample_prep_descripton: exists: optional doc: | - At this moment no base class is available that can track entire sample preparation. + At this moment no base class is available that can track entire sample + preparation. # TODO: discuss convertion data to DATA (NXdata): @@ -888,7 +892,7 @@ NXsts(NXsensor_scan): Mesh scan with 2D slices of the above alternative plot for other y co-ordinates. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f8791239d512dee3324d81260123aead0021f6201d6947f100eddbf2c7cf4beb +# 6623ef24981cdfc84c0c1c449fa1febec5ccc29e9116c9c38d49c0378c710f2e # # # # +# # # # Application definition for temperature-dependent IV curve measurements @@ -1369,7 +1375,7 @@ NXsts(NXsensor_scan): # # # -# +# # # # Also clarify the frame for the ROI of the scan in lab frame, the middle of the lab @@ -1377,7 +1383,7 @@ NXsts(NXsensor_scan): # # # -# +# # # # The scan channels are selected by users. (e.g. (A);Bias (V);Z (m);LI Demod 2 X @@ -1765,11 +1771,13 @@ NXsts(NXsensor_scan): # # # -# To describe sample and other constaints that applied on sample before scanning. +# To describe the sample and other constraints that are applied to that sample +# before scanning. # -# +# # -# At this moment no base class available that can track entire sample preparation. +# At this moment no base class is available that can track entire sample +# preparation. # # # From 666fd97f30c762e30f4934205f84b52e3ba66ac0 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 17 May 2024 12:33:55 +0200 Subject: [PATCH 0695/1012] remake NXfabrication nyaml and nxdl --- .../NXfabrication.nxdl.xml | 6 +++--- .../nyaml/NXfabrication.yaml | 20 ++++++++++++++----- 2 files changed, 18 insertions(+), 8 deletions(-) diff --git a/contributed_definitions/NXfabrication.nxdl.xml b/contributed_definitions/NXfabrication.nxdl.xml index 6f6c48d349..c8390a7ffe 100644 --- a/contributed_definitions/NXfabrication.nxdl.xml +++ b/contributed_definitions/NXfabrication.nxdl.xml @@ -32,12 +32,12 @@ - Version or model of the component named by the manufacturer. + Version or model of the component named by the manufacturer. - If different versions exist are possible, the value in this field should be made specific enough to resolve the version. - + If different versions exist are possible, the value in this field should be made + specific enough to resolve the version. diff --git a/contributed_definitions/nyaml/NXfabrication.yaml b/contributed_definitions/nyaml/NXfabrication.yaml index db15391774..3a5199898b 100644 --- a/contributed_definitions/nyaml/NXfabrication.yaml +++ b/contributed_definitions/nyaml/NXfabrication.yaml @@ -12,7 +12,8 @@ NXfabrication(NXobject): \@version: type: NX_CHAR doc: | - If different versions exist are possible, the value in this field should be made specific enough to resolve the version. + If different versions exist are possible, the value in this field should be made + specific enough to resolve the version. identifier(NX_CHAR): doc: | Ideally, (globally) unique persistent identifier, i.e. @@ -30,7 +31,7 @@ NXfabrication(NXobject): functionalities which the component offers. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 6b41658298bdab15f08057e91686e6853e1c1adf0460309bc82194cf30151ac1 +# 1bd65ca97f104626d51743277a21d0f909b560fd3fbdbc8e4f46f5d1fba3dc5c # # # - + +# +# +# +# This is an general application definition for angle-resolved multidimensional +# photoelectron spectroscopy. +# +# +# +# +# +# +# +# +# +# +# +# +# Link to transformations defining an APRES base coordinate system, +# which is defined such that the positive z-axis points towards the analyzer entry, +# and the x-axis lies within the beam/analyzer plane. +# +# +# +# +# Set of transformations, describing the orientation of the ARPES coordinate system +# with respect to the beam coordinate system (.). +# +# +# +# +# +# +# +# Overall angular resolution along the Nth angular axis. Create one such entry per relevant angular axis, +# corresponding to the angular axes in NXdata. +# For hemispherical analyzers, angular0_resolution corresponds to the direction along the analyzer slit, +# and angular1_resolution to the one perpendicular to it. +# +# +# +# +# +# +# +# +# +# +# +# +# Analyzer angular resolution along the Nth angular axis. +# Create one such entry per relevant angular axis, corresponding to the angular axes in NXdata. +# For hemispherical analyzers, angular0_resolution corresponds to the direction along the analyzer slit, +# and angular1_resolution to the one perpendicular to it. +# +# +# +# +# +# +# +# +# +# +# +# Reference to the last transformation describing the orientation of the analyzer relative to the beam, +# e.g. transformations/analyzer_elevation. +# +# +# +# +# Set of transformations, describing the relative orientation of the analyzer +# with respect to the beam coordinate system (.). +# +# +# +# Rotation about the analyzer lens axis. +# Its zero reference is defined such that the angular0 axis is +# increasing towards the positive y axis (analyzer slit vertical). +# +# +# +# +# +# +# +# +# +# +# +# +# +# Path to a transformation that places the analyzer origin system into the +# arpes_geometry coordinate system. +# +# +# +# +# +# Elevation of the effective analyzer acceptance area, e.g. realized by +# deflectors, or as one angle in a TOF detector. If a resolved angle, place the +# calibrated axis coordinates here. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# In-plane analyzer coordinate along a dispersive direction, +# e.g. along an analyzer slit. If a resolved angle, place the calibrated coordinates here. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Scheme of the electron collection column. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Reference to the end of the transformation chain, +# orienting the sample surface within the arpes_geometry coordinate system +# (sample_azimuth or anything depending on it). +# +# +# +# +# Set of transformations, describing the relative orientation of the sample +# with respect to the arpes_geometry coordinate system. +# +# +# +# Rotation about the y axis (typically the long manipulator axis). +# +# +# +# +# +# +# +# +# +# +# +# +# +# Path to a transformation that places the sample surface +# into the origin of the arpes_geometry coordinate system. +# +# +# +# +# +# Offset of polar rotation. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Rotation about the x axis (typically a manipulator tilt). +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Offset of tilt rotation. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Rotation about the z axis (azimuthal rotation within the sample plane). +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Offset of azimuthal rotation. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# There is an object named data that contains the signal. +# +# +# +# +# +# +# +# There are three dimensions, one energy and two angular coordinates. Any coordinates that do not move, +# are represented by one point. +# +# +# +# +# +# +# +# +# +# +# Points to the path to a field defining the axis on which the angular axis depends. +# For example: +# @angular0_depends: '/entry/sample/transformations/sample_tilt' for a manipulator angular scan +# @angular0_depends: '/entry/instrument/detector/sensor_x' for a 2D detector +# @angular0_depends: '/entry/instrument/collectioncolumn/deflector' for a deflector scan +# @angular0_depends: '/entry/process/calibration/angular0_calibration/calibrated_axis' for a preprocessed axis. +# +# +# +# +# Points to the path to a field defining the axis on which the angular axis depends. +# For example: +# @angular1_depends: '/entry/sample/transformations/sample_polar' for a manipulator angular scan +# @angular1_depends: '/entry/instrument/detector/sensor_x' for a 2D detector +# @angular1_depends: '/entry/instrument/collectioncolumn/deflector' for a deflector scan +# @angular1_depends: '/entry/process/calibration/angular1_calibration/calibrated_axis' for a preprocessed axis. +# +# +# +# +# Points to the path to a field defining the axis on which the energy axis depends. +# For example: +# @energy_depends: '/entry/instrument/detector/sensor_y' for a 2D detector +# @energy_depends: '/entry/instrument/energydispersion/center_kinetic_energy' for a swept scan +# @energy_depends: '/entry/process/calibration/energy_calibration/calibrated_axis' for a preprocessed axis. +# +# +# +# +# Trace of the energy axis. Could be linked from the respective 'AXISNAME_depends' +# field. +# +# +# +# +# Trace of the first angular axis. Could be linked from the respective +# 'AXISNAME_depends' field. +# +# +# +# +# Trace of the second axis. Could be linked from the respective 'AXISNAME_depends' +# field. +# +# +# +# +# Represents a measure of three-dimensional photoemission counts, where +# the varied axes are energy, and one or more angular coordinates. Axes traces +# should be linked to the actual encoder position in NXinstrument or calibrated axes in NXprocess. +# +# +# +# +# From a1815c22a5418a7d3f780d78909e32fc244aa57f Mon Sep 17 00:00:00 2001 From: RubelMozumder <32923026+RubelMozumder@users.noreply.github.com> Date: Fri, 17 May 2024 11:57:04 +0200 Subject: [PATCH 0697/1012] Revert "Clean up NXsts to fit stm reader with new dataconverter validation process." --- contributed_definitions/NXsts.nxdl.xml | 43 +++++-------- contributed_definitions/nyaml/NXsts.yaml | 81 ++++++++---------------- 2 files changed, 44 insertions(+), 80 deletions(-) diff --git a/contributed_definitions/NXsts.nxdl.xml b/contributed_definitions/NXsts.nxdl.xml index b00b88e23e..5f778c9c35 100644 --- a/contributed_definitions/NXsts.nxdl.xml +++ b/contributed_definitions/NXsts.nxdl.xml @@ -25,12 +25,6 @@ 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the--> - - - Application definition for temperature-dependent IV curve measurements @@ -135,15 +129,6 @@ crosstalk_compensation: Current amplifier> Capacitive cross-talk compensation: Y Status of Lock-in device whether while performing the experiment - - - Select whether to set the Lock-In to run during the measurement. When using this - feature, make sure the Lock-In is configured correctly and settling times are - set to twice the Lock-In period at least. This option is ignored when Lock-In is - already running. This option is disabled if the Sweep Mode is MLS and the flag - to configure the Lock-In per segment in the Multiline segment editor is set. - - +when saving. Using this option increases the sweep time by Z averaging time. (e.g. FALSE) +run: +doc: Bias Spectroscopy>Lock-In run FALSE # Select whether to set the Lock-In to run +during the measurement. When using this feature, make sure the Lock-In is configured +correctly and settling times are set to twice the Lock-In period at least. This +option is ignored when Lock-In is already running. This option is disabled if the +Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline +segment editor is set.--> Bias voltage applied to the sample. @@ -331,8 +323,7 @@ doc: The rate at which the one of the signal changes when ramping to the startin - An environmental setup to measure the tunneling current due to different tip- - sample biases. + An environmental setup to measure the tunneling current due to different tip-sample biases. @@ -341,13 +332,13 @@ doc: The rate at which the one of the signal changes when ramping to the startin in the constant height mode means the real tunnelling current between tip and sample). - + Value of calibration that comes as A/V. - + @@ -480,7 +471,7 @@ parameters for a measurement at a single location during the scan--> - + Also clarify the frame for the ROI of the scan in lab frame, the middle of the lab @@ -488,7 +479,7 @@ parameters for a measurement at a single location during the scan--> - + The scan channels are selected by users. (e.g. (A);Bias (V);Z (m);LI Demod 2 X @@ -876,13 +867,11 @@ is switched off, it doesn't switch off immediately but continues to run for the - To describe the sample and other constraints that are applied to that sample - before scanning. + To describe sample and other constaints that applied on sample before scanning. - + - At this moment no base class is available that can track entire sample - preparation. + At this moment no base class available that can track entire sample preparation. diff --git a/contributed_definitions/nyaml/NXsts.yaml b/contributed_definitions/nyaml/NXsts.yaml index 232d5c9f09..ee58feebfd 100644 --- a/contributed_definitions/nyaml/NXsts.yaml +++ b/contributed_definitions/nyaml/NXsts.yaml @@ -21,12 +21,6 @@ doc: | # 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the -# 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the - -# 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the - -# 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the - # 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the type: group NXsts(NXsensor_scan): @@ -95,14 +89,6 @@ NXsts(NXsensor_scan): # status: Lock-in>Lock-in status ON # ON/OFF of Lock-in amplifier doc: | Status of Lock-in device whether while performing the experiment - run: - exists: optional - doc: | - Select whether to set the Lock-In to run during the measurement. When using this - feature, make sure the Lock-In is configured correctly and settling times are - set to twice the Lock-In period at least. This option is ignored when Lock-In is - already running. This option is disabled if the Sweep Mode is MLS and the flag - to configure the Lock-In per segment in the Multiline segment editor is set. # amplifier_status: -> amplifier/active_channels # Lock-in Amplifier>Yes/No @@ -177,6 +163,13 @@ NXsts(NXsensor_scan): # doc: Select whether to record the Z position during Z averaging time at the end of the # sweep (after Z control time) and store the average value in the header of the file # when saving. Using this option increases the sweep time by Z averaging time. (e.g. FALSE) + # run: + # doc: Bias Spectroscopy>Lock-In run FALSE # Select whether to set the Lock-In to run + # during the measurement. When using this feature, make sure the Lock-In is configured + # correctly and settling times are set to twice the Lock-In period at least. This + # option is ignored when Lock-In is already running. This option is disabled if the + # Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline + # segment editor is set. sample_bias(NXiv_bias): doc: | Bias voltage applied to the sample. @@ -284,8 +277,7 @@ NXsts(NXsensor_scan): Use the button to enable or disable the drift compensation. (e.g. FALSE) (NXenvironment): doc: | - An environmental setup to measure the tunneling current due to different tip- - sample biases. + An environmental setup to measure the tunneling current due to different tip-sample biases. current_sensor(NXsensor): exists: optional current(NX_NUMBER): @@ -294,14 +286,13 @@ NXsts(NXsensor_scan): This is set-point of tip current (in the constant current mode should be equal to set-point, in the constant height mode means the real tunnelling current between tip and sample). current_calibration(NX_NUMBER): - unit: NX_ANY + unit: NX_CURRENT doc: | Value of calibration that comes as A/V. current_offset(NX_NUMBER): unit: NX_CURRENT current_gain(NX_NUMBER): unit: NX_UNITLESS - exists: optional calibration_time(NX_DATE_TIME): exists: optional value(NX_NUMBER): @@ -422,13 +413,11 @@ NXsts(NXsensor_scan): scan_control(NXcollection): exists: optional roi(NXtransformations): - exists: optional frame: doc: | Also clarify the frame for the ROI of the scan in lab frame, the middle of the lab frame is (0, 0), and positive in x means right and in y means up. circuit(NXcollection): - exists: optional channels_current: doc: | The scan channels are selected by users. (e.g. (A);Bias (V);Z (m);LI Demod 2 X @@ -818,13 +807,10 @@ NXsts(NXsensor_scan): sample(NXsample): exists: optional doc: | - To describe the sample and other constraints that are applied to that sample - before scanning. + To describe sample and other constaints that applied on sample before scanning. sample_prep_descripton: - exists: optional doc: | - At this moment no base class is available that can track entire sample - preparation. + At this moment no base class available that can track entire sample preparation. # TODO: discuss convertion data to DATA (NXdata): @@ -892,7 +878,7 @@ NXsts(NXsensor_scan): Mesh scan with 2D slices of the above alternative plot for other y co-ordinates. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 6623ef24981cdfc84c0c1c449fa1febec5ccc29e9116c9c38d49c0378c710f2e +# 73b9167972d2988b8c75a60e04a9c2db349cf2fbe052958f3908c632f8d8eba1 # # # # -# -# -# # # # Application definition for temperature-dependent IV curve measurements @@ -1030,15 +1010,6 @@ NXsts(NXsensor_scan): # Status of Lock-in device whether while performing the experiment # # -# -# -# Select whether to set the Lock-In to run during the measurement. When using this -# feature, make sure the Lock-In is configured correctly and settling times are -# set to twice the Lock-In period at least. This option is ignored when Lock-In is -# already running. This option is disabled if the Sweep Mode is MLS and the flag -# to configure the Lock-In per segment in the Multiline segment editor is set. -# -# # +# when saving. Using this option increases the sweep time by Z averaging time. (e.g. FALSE) +# run: +# doc: Bias Spectroscopy>Lock-In run FALSE # Select whether to set the Lock-In to run +# during the measurement. When using this feature, make sure the Lock-In is configured +# correctly and settling times are set to twice the Lock-In period at least. This +# option is ignored when Lock-In is already running. This option is disabled if the +# Sweep Mode is MLS and the flag to configure the Lock-In per segment in the Multiline +# segment editor is set.--> # # # Bias voltage applied to the sample. @@ -1226,8 +1204,7 @@ NXsts(NXsensor_scan): # # # -# An environmental setup to measure the tunneling current due to different tip- -# sample biases. +# An environmental setup to measure the tunneling current due to different tip-sample biases. # # # @@ -1236,13 +1213,13 @@ NXsts(NXsensor_scan): # in the constant height mode means the real tunnelling current between tip and sample). # # -# +# # # Value of calibration that comes as A/V. # # # -# +# # # # @@ -1375,7 +1352,7 @@ NXsts(NXsensor_scan): # # # -# +# # # # Also clarify the frame for the ROI of the scan in lab frame, the middle of the lab @@ -1383,7 +1360,7 @@ NXsts(NXsensor_scan): # # # -# +# # # # The scan channels are selected by users. (e.g. (A);Bias (V);Z (m);LI Demod 2 X @@ -1771,13 +1748,11 @@ NXsts(NXsensor_scan): # # # -# To describe the sample and other constraints that are applied to that sample -# before scanning. +# To describe sample and other constaints that applied on sample before scanning. # -# +# # -# At this moment no base class is available that can track entire sample -# preparation. +# At this moment no base class available that can track entire sample preparation. # # # From b2f80a58771693125329b9771c9c6c909c9383f6 Mon Sep 17 00:00:00 2001 From: Rubel Date: Fri, 31 May 2024 14:43:49 +0200 Subject: [PATCH 0698/1012] include scan_range. --- contributed_definitions/NXsts.nxdl.xml | 17 ++++++++++++++++- contributed_definitions/nyaml/NXsts.yaml | 10 ++++++++++ 2 files changed, 26 insertions(+), 1 deletion(-) diff --git a/contributed_definitions/NXsts.nxdl.xml b/contributed_definitions/NXsts.nxdl.xml index 5f778c9c35..049a920707 100644 --- a/contributed_definitions/NXsts.nxdl.xml +++ b/contributed_definitions/NXsts.nxdl.xml @@ -25,6 +25,8 @@ 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the--> + Application definition for temperature-dependent IV curve measurements @@ -323,7 +325,8 @@ doc: The rate at which the one of the signal changes when ramping to the startin - An environmental setup to measure the tunneling current due to different tip-sample biases. + An environmental setup to measure the tunneling current due to different tip- + sample biases. @@ -471,6 +474,18 @@ parameters for a measurement at a single location during the scan--> + + + The scan range (in STM experiment) is the area that the tip will scan. (e.g. + 5.000000E-9 5.000000E-9) + + + + + The scan offset (in STM experiment) is the position of the tip in the scan area. + (e.g. -2.354637E-7 1.267476E-) + + diff --git a/contributed_definitions/nyaml/NXsts.yaml b/contributed_definitions/nyaml/NXsts.yaml index ee58feebfd..ca3cf98bff 100644 --- a/contributed_definitions/nyaml/NXsts.yaml +++ b/contributed_definitions/nyaml/NXsts.yaml @@ -412,6 +412,16 @@ NXsts(NXsensor_scan): # parameters how to change the location from measurement to measurement during the scan scan_control(NXcollection): exists: optional + scan_range(NX_NUMBER): + unit: NX_LENGTH + exists: optional + doc: | + The scan range (in STM experiment) is the area that the tip will scan. (e.g. 5.000000E-9 5.000000E-9) + scan_offset(NX_NUMBER): + unit: NX_LENGTH + exists: optional + doc: | + The scan offset (in STM experiment) is the position of the tip in the scan area. (e.g. -2.354637E-7 1.267476E-) roi(NXtransformations): frame: doc: | From 140bfc8bd61741aa69b382dd9071bd43c66b5dec Mon Sep 17 00:00:00 2001 From: Rubel Date: Thu, 6 Jun 2024 17:39:15 +0200 Subject: [PATCH 0699/1012] inlcude scan_direction. --- contributed_definitions/NXsts.nxdl.xml | 12 ++++++ contributed_definitions/nyaml/NXsts.yaml | 48 +++++++++++++++++++++--- 2 files changed, 55 insertions(+), 5 deletions(-) diff --git a/contributed_definitions/NXsts.nxdl.xml b/contributed_definitions/NXsts.nxdl.xml index 049a920707..274a7090c3 100644 --- a/contributed_definitions/NXsts.nxdl.xml +++ b/contributed_definitions/NXsts.nxdl.xml @@ -486,6 +486,18 @@ parameters for a measurement at a single location during the scan--> (e.g. -2.354637E-7 1.267476E-) + + + The scan direction (in STM experiment) is the direction from which side of the + sample the tip starts scanning. + + + + + + + + diff --git a/contributed_definitions/nyaml/NXsts.yaml b/contributed_definitions/nyaml/NXsts.yaml index ca3cf98bff..0d5f31739b 100644 --- a/contributed_definitions/nyaml/NXsts.yaml +++ b/contributed_definitions/nyaml/NXsts.yaml @@ -21,6 +21,8 @@ doc: | # 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the +# 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the + # 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the type: group NXsts(NXsensor_scan): @@ -277,7 +279,8 @@ NXsts(NXsensor_scan): Use the button to enable or disable the drift compensation. (e.g. FALSE) (NXenvironment): doc: | - An environmental setup to measure the tunneling current due to different tip-sample biases. + An environmental setup to measure the tunneling current due to different tip- + sample biases. current_sensor(NXsensor): exists: optional current(NX_NUMBER): @@ -416,12 +419,20 @@ NXsts(NXsensor_scan): unit: NX_LENGTH exists: optional doc: | - The scan range (in STM experiment) is the area that the tip will scan. (e.g. 5.000000E-9 5.000000E-9) + The scan range (in STM experiment) is the area that the tip will scan. (e.g. + 5.000000E-9 5.000000E-9) scan_offset(NX_NUMBER): unit: NX_LENGTH exists: optional doc: | - The scan offset (in STM experiment) is the position of the tip in the scan area. (e.g. -2.354637E-7 1.267476E-) + The scan offset (in STM experiment) is the position of the tip in the scan area. + (e.g. -2.354637E-7 1.267476E-) + scan_direction: + exists: optional + doc: | + The scan direction (in STM experiment) is the direction from which side of the + sample the tip starts scanning. + enumeration: [down, up, top, bottom] roi(NXtransformations): frame: doc: | @@ -888,7 +899,7 @@ NXsts(NXsensor_scan): Mesh scan with 2D slices of the above alternative plot for other y co-ordinates. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 73b9167972d2988b8c75a60e04a9c2db349cf2fbe052958f3908c632f8d8eba1 +# f4eeaa0d36c4170f930c7a2d477760c74b4138589f6a21addfaf8e6f23e35a56 # # # # +# # # # Application definition for temperature-dependent IV curve measurements @@ -1214,7 +1227,8 @@ NXsts(NXsensor_scan): # # # -# An environmental setup to measure the tunneling current due to different tip-sample biases. +# An environmental setup to measure the tunneling current due to different tip- +# sample biases. # # # @@ -1362,6 +1376,30 @@ NXsts(NXsensor_scan): # # # +# +# +# The scan range (in STM experiment) is the area that the tip will scan. (e.g. +# 5.000000E-9 5.000000E-9) +# +# +# +# +# The scan offset (in STM experiment) is the position of the tip in the scan area. +# (e.g. -2.354637E-7 1.267476E-) +# +# +# +# +# The scan direction (in STM experiment) is the direction from which side of the +# sample the tip starts scanning. +# +# +# +# +# +# +# +# # # # From 015e3d09888c5aed302310914c1aecee25bcdf00 Mon Sep 17 00:00:00 2001 From: Rubel Date: Mon, 17 Jun 2024 08:20:54 +0200 Subject: [PATCH 0700/1012] Make optional scanfield from positioner group. --- contributed_definitions/NXsts.nxdl.xml | 9 +++------ contributed_definitions/nyaml/NXsts.yaml | 19 +++++++------------ 2 files changed, 10 insertions(+), 18 deletions(-) diff --git a/contributed_definitions/NXsts.nxdl.xml b/contributed_definitions/NXsts.nxdl.xml index 274a7090c3..186d015d8e 100644 --- a/contributed_definitions/NXsts.nxdl.xml +++ b/contributed_definitions/NXsts.nxdl.xml @@ -23,10 +23,6 @@ --> - - Application definition for temperature-dependent IV curve measurements @@ -515,10 +511,11 @@ parameters for a measurement at a single location during the scan--> - + Configure the scan frame like x position; y position; width; height. (e.g. - 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0) + 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0). If the 'scanfield' is not considered, use + the 'scan_range' and 'scan_offset' from 'scan_control' group diff --git a/contributed_definitions/nyaml/NXsts.yaml b/contributed_definitions/nyaml/NXsts.yaml index 0d5f31739b..51f9366de1 100644 --- a/contributed_definitions/nyaml/NXsts.yaml +++ b/contributed_definitions/nyaml/NXsts.yaml @@ -19,10 +19,6 @@ doc: | y has (NXsoftware_Scan_offset) z has (NXsoftware_Scan_offset) -# 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the - -# 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the - # 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the type: group NXsts(NXsensor_scan): @@ -445,9 +441,11 @@ NXsts(NXsensor_scan): (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A)) positioner(NXcollection): scanfield(NX_NUMBER): + exists: optional doc: | Configure the scan frame like x position; y position; width; height. (e.g. - 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0) + 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0). If the 'scanfield' is not considered, use + the 'scan_range' and 'scan_offset' from 'scan_control' group pixels_line(NX_NUMBER): doc: | Scan resolution by setting the Lines equal to Pixels. (e.g. 512) @@ -899,7 +897,7 @@ NXsts(NXsensor_scan): Mesh scan with 2D slices of the above alternative plot for other y co-ordinates. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f4eeaa0d36c4170f930c7a2d477760c74b4138589f6a21addfaf8e6f23e35a56 +# 40814e1bec4f77182e2f632f35a9f157756ee337ac3c5277fd1651842f62cf34 # # # # -# -# # # # Application definition for temperature-dependent IV curve measurements @@ -1417,10 +1411,11 @@ NXsts(NXsensor_scan): # # # -# +# # # Configure the scan frame like x position; y position; width; height. (e.g. -# 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0) +# 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0). If the 'scanfield' is not considered, use +# the 'scan_range' and 'scan_offset' from 'scan_control' group # # # From f3ccf13f547ac226789567a19b190d1125719d22 Mon Sep 17 00:00:00 2001 From: Rubel Date: Mon, 17 Jun 2024 09:31:09 +0200 Subject: [PATCH 0701/1012] Include scan direction. --- contributed_definitions/NXsts.nxdl.xml | 8 ++++++++ contributed_definitions/nyaml/NXsts.yaml | 18 +++++++++++++++++- 2 files changed, 25 insertions(+), 1 deletion(-) diff --git a/contributed_definitions/NXsts.nxdl.xml b/contributed_definitions/NXsts.nxdl.xml index 186d015d8e..6d0876b98c 100644 --- a/contributed_definitions/NXsts.nxdl.xml +++ b/contributed_definitions/NXsts.nxdl.xml @@ -23,6 +23,8 @@ --> + Application definition for temperature-dependent IV curve measurements @@ -494,6 +496,12 @@ parameters for a measurement at a single location during the scan--> + + + The angle of scan with the bottom or top side (depends on the scan_direction + field) of the sample. (e.g. 0.000E+0). + + diff --git a/contributed_definitions/nyaml/NXsts.yaml b/contributed_definitions/nyaml/NXsts.yaml index 51f9366de1..8a6eb44225 100644 --- a/contributed_definitions/nyaml/NXsts.yaml +++ b/contributed_definitions/nyaml/NXsts.yaml @@ -19,6 +19,8 @@ doc: | y has (NXsoftware_Scan_offset) z has (NXsoftware_Scan_offset) +# 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the + # 2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the type: group NXsts(NXsensor_scan): @@ -429,6 +431,12 @@ NXsts(NXsensor_scan): The scan direction (in STM experiment) is the direction from which side of the sample the tip starts scanning. enumeration: [down, up, top, bottom] + scan_angle(NX_NUMBER): + unit: NX_ANGLE + exists: optional + doc: | + The angle of scan with the bottom or top side (depends on the scan_direction + field) of the sample. (e.g. 0.000E+0). roi(NXtransformations): frame: doc: | @@ -897,7 +905,7 @@ NXsts(NXsensor_scan): Mesh scan with 2D slices of the above alternative plot for other y co-ordinates. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 40814e1bec4f77182e2f632f35a9f157756ee337ac3c5277fd1651842f62cf34 +# 9ca3ac1a82c4164b4e143e595d65f73925ae05cc5df5ff2510156686c0a751a3 # # # # +# # # # Application definition for temperature-dependent IV curve measurements @@ -1394,6 +1404,12 @@ NXsts(NXsensor_scan): # # # +# +# +# The angle of scan with the bottom or top side (depends on the scan_direction +# field) of the sample. (e.g. 0.000E+0). +# +# # # # From d5ada23724652f6c84c0edd175844adb65bca9e3 Mon Sep 17 00:00:00 2001 From: Ron Hildebrandt Date: Tue, 18 Jun 2024 09:11:39 +0200 Subject: [PATCH 0702/1012] Finalize NXopt from Workshop feedback --- .../NXellipsometry.nxdl.xml | 16 +- contributed_definitions/NXlens_opt.nxdl.xml | 29 +- contributed_definitions/NXopt.nxdl.xml | 928 ++++++++++-------- contributed_definitions/NXopt_window.nxdl.xml | 11 + contributed_definitions/NXraman.nxdl.xml | 9 +- contributed_definitions/NXwaveplate.nxdl.xml | 18 +- .../nyaml/NXellipsometry.yaml | 9 +- contributed_definitions/nyaml/NXlens_opt.yaml | 7 +- contributed_definitions/nyaml/NXopt.yaml | 794 ++++++++------- .../nyaml/NXopt_window.yaml | 6 +- contributed_definitions/nyaml/NXraman.yaml | 5 +- .../nyaml/NXwaveplate.yaml | 4 + 12 files changed, 1000 insertions(+), 836 deletions(-) diff --git a/contributed_definitions/NXellipsometry.nxdl.xml b/contributed_definitions/NXellipsometry.nxdl.xml index 1f1934eb45..87e6f6d06f 100644 --- a/contributed_definitions/NXellipsometry.nxdl.xml +++ b/contributed_definitions/NXellipsometry.nxdl.xml @@ -24,7 +24,7 @@ - + Variables used throughout the document, e.g. dimensions or parameters. @@ -119,7 +119,7 @@ A rework of the draft version(06/2022) of a NeXus application definition for ell - + Specify the type of the optical experiment. @@ -189,7 +189,7 @@ A rework of the draft version(06/2022) of a NeXus application definition for ell were corrected for the window effects. - + Were the recorded data corrected by the window effects of the focussing probes (lenses)? @@ -241,7 +241,7 @@ from the old (NXopt and NXellipsometry) for the new NXellipometry. The generic description of the data collection will in future be included in the generic NXopt, but is now keept limited to NXellipsometry.--> - + Measured data, data errors, and varied parameters. This may be used to describe indirectly derived data or data transformed between different descriptions, @@ -256,13 +256,13 @@ NXellipsometry.--> in a generic (NXdata) concept from NXopt, or better directly in the location of the sample positioner or temperature sensor. - + An identifier to correlate data to the experimental conditions, if several were used in this measurement; typically an index of 0-N. - + Select which type of data was recorded, for example intensity, reflectivity, transmittance, Psi and Delta etc. @@ -363,7 +363,7 @@ NXellipsometry.--> - + Commercial or otherwise defined given name of the program that was used to generate the result file(s) with measured data and/or @@ -372,7 +372,7 @@ NXellipsometry.--> subfield here. - + Either version with build number, commit hash, or description of a (online) repository where the source code of the program and build diff --git a/contributed_definitions/NXlens_opt.nxdl.xml b/contributed_definitions/NXlens_opt.nxdl.xml index e3bf121dac..6a6bb9be64 100644 --- a/contributed_definitions/NXlens_opt.nxdl.xml +++ b/contributed_definitions/NXlens_opt.nxdl.xml @@ -1,10 +1,10 @@ - + - - + @@ -104,8 +105,10 @@ - + If the lens has a coating describe the material and its properties. Some basic information can be found e.g. [here] @@ -182,4 +185,14 @@ the lens has different coatings on the front and back side.--> Abbe number (or V-number) of the lens. + + + The numerical aperture of the used incident light optics. + + + + + + + diff --git a/contributed_definitions/NXopt.nxdl.xml b/contributed_definitions/NXopt.nxdl.xml index 6875940030..7f7d447644 100644 --- a/contributed_definitions/NXopt.nxdl.xml +++ b/contributed_definitions/NXopt.nxdl.xml @@ -27,17 +27,12 @@ Extension of the Draft Version (05/2023) of a NeXus application definition which serves as a template for various optical spectroscopy experiments TODO: -- Merge reference_frames with angle_reference_frame -- Rework instrument_calibration_DEVICE - use NXcalibration? -- Beam polarizations: Own Polarization concept with angle or from NXbeam via beam coordinates? (solve reference frame problem first) -- Describe angle_of_detection by NXtransformations -- remove NXmonchromator? as it is already in NXinstrument - Add NXlens_opt and NXwaveplate to NXinstrument? -- Make sample stage_stage(NXmanipulator)/reference_frame via NXtransformations -- Add properties from NXlens_opt from NXopt to NXlens_opt base class - Make polfilter_TYPE(NXbeam_device) own base class -\-> rework NXpolarizer_opt. and add them to NXinstrument. -- Make spectralfilter_TYPE(NXbeam_device) own base class -\-> extend NXfilter? and add them to NXinstrument.--> - +- Make spectralfilter_TYPE(NXbeam_device) own base class -\-> extend NXfilter? and add them to NXinstrument. +- Make offset angles for polar and azimutal? +- Can angle_reference_frame be replaced later by only using reference_frames and generic angle description?--> + Variables used throughout the document, e.g. dimensions or parameters. @@ -56,17 +51,6 @@ TODO: N_measurements = 2*3 = 6. - - - Number of detection angles of the beam reflected or scattered off the - sample. - - - - - Number of angles of incidence of the incident beam. - - A general application definition of optical spectroscopy elements, which may @@ -77,6 +61,9 @@ TODO: A general optical experiment consists of (i) a light/photon source, (ii) a sample, (iii) a detector. + + For any free text descriptions, it is recommended to enter data in english + language, as this is the most FAIR representation. @@ -96,15 +83,17 @@ TODO: - + - - + + Datetime of the start of the measurement. Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, otherwise, the local time zone is assumed per ISO8601. + + It is required to enter at least one of both measurement times, either "start_time" or "end_time". @@ -112,6 +101,8 @@ TODO: Datetime of the end of the measurement. Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, otherwise the local time zone is assumed per ISO8601. + + It is required to enter at least one of both measurement times, either "start_time" or "end_time". @@ -123,6 +114,18 @@ TODO: + + + Select the range of validity of this identier. + Local: Setup#1 at Institute building #2 in Room #3 + Global: Unique identification of with by unique location and unique + globally persistent time stamp. + + + + + + @@ -144,10 +147,11 @@ TODO: Chose other if none of these methods are suitable. You may specify fundamental characteristics or properties in the experimental sub-type. + + For Raman spectroscopy or ellipsometry use the respective specializations + of NXoptical_spectroscopy. - - @@ -166,10 +170,6 @@ TODO: - If "other" was selected in "experiment_type" and/or in "experiment_sub_type", @@ -177,17 +177,45 @@ compared to temperature or pressure. Is this a useful distinction?--> respective community of interest. - Description of one or more coordinate systems that are specific to the - experiment. + experiment. Examples are beam centered, sample-normal centered, + laboratory-system centered, sample-stage centered, crystal-symmetry centered. + + + + This refers to the coordinate system along the beam path. The origin and + base is defined at z=0, where the incident beam hits the sample at the surface. + + + + + This is the default NeXus coordinate system (McStas), if the transformation + does not change the coordinate system at all - i.e. it is unity. + Otherwise, by this a respective transformation of the beam + reference frame to the default reference frame could be made. i.e. + exchange of x and z coordinate, rotation of respective coordinates + towards each other. + + + + + + + Link to transformations defining the sample-normal base coordinate system, + which is defined such that the positive z-axis is parallel to the sample normal, + and the x-y-plane lies inside the sample surface. + + + + + Set of transformations, describing the orientation of the sample-normal coordinate system + with respect to the beam coordinate system (.). + + + @@ -198,6 +226,8 @@ Sample normal, beam_z_axis, sample_stage It is recommended to add multiple users if relevant. Due to data privacy concerns, there is no minimum requirement. + If no user with specific name is allowed to be given, it is required to + assign at least an affiliation @@ -216,183 +246,38 @@ Sample normal, beam_z_axis, sample_stage - Stages(NXmanipulator) - Sensors and actuators to control or measure sample or beam properties - - - General device information of the optical spectroscopy setup, if - suitable (e.g. for a tabletop spectrometer or other non-custom build setups). - For custom build setups, this may be limited to the construction year. - - - - - - - - - - Commercial or otherwise defined given name of the program that was - used to control any parts of the optical spectroscopy setup. - The uppercase TYPE should be replaced by a specification name, i.e. - "software_detector" or "software_stage" to specify the respective - program or software components. - - - - Either version with build number, commit hash, or description of a - (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner. - - - - - Description of the software by persistent resource, where the program, - code, script etc. can be found. - - - - - - + - Defines the reference frame which is used to describe the sample orientation - with respect to the beam directions. - - A beam centered description is the default and uses 4 angles(similar to XRD): - - Omega (angle between sample surface and incident beam) - - 2Theta (angle between the transmitted beam and the detection beam) - - Chi (sample tilt angle, angle between plane#1 and the surface normal, - plane#1 = spanned by incidence beam and detection - and detection. If Chi=0°, then plane#1 is the plane of - incidence in reflection setups) - - Phi (inplane rotation of sample, rotation axis is the samples - surface normal) - + This can be used to describe properties of a photon beam. + A beam is always defined between two beam_devices, via + "previous_device" and "next_device". - A sample normal centered description is as well possible(similar to XX): - - angle of incidence (angle between incident beam and sample surface) - - angle of detection (angle between detection beam and sample surface) - - angle of incident and detection beam (angle between the incident and scattering beam) - - angle of in-plane sample rotation (direction along the sample's surface normal) + It is required to define at least one incident beam which is incident + to the sample. You may specify if this beam parameters are acutally measured + or just nominal. + If this beam is the output of a source, chose the same + name appendix as for the NXsource instance (e.g. TYPE=532nm) - - - - - - - - - The overall resolution of the optical instrument. - - - - - - - - - - Minimum distinguishable wavelength separation of peaks in spectra. - - - - - - Pre-calibration of an arbitrary device of the instrumental setup, which - has the name DEVICE. You can specify here how, at which time by which method - the calibration was done. As well the accuracy and a link to the calibration - dataset. - - + - Path to the device, which was calibrated. - Example: entry/instrument/DEVICE - - - - - Describe here the approach or method, used to perform the calibration, by a free - text. - - - - - Provide data about the determined accuracy of the device, this may - may be a single value or a dataset like wavelength error vs. wavelength etc. - - - - - Was a calibration performed? If yes, when was it done? If the - calibration time is provided, it should be specified in - ENTRY/INSTRUMENT/calibration/calibration_time. + Select the reliability of the respective beam characteristics. Either, + the parameters are measured via another device or method or just given + nominally via the properties of a light source properties (532nm, 100mW). - - - - - + + - - - If calibtration status is 'calibration time provided', specify the - ISO8601 date when calibration was last performed before this - measurement. UTC offset should be specified. - - - - - Link to the NeXus file containing the calibration data and metadata. - - - - - - - - Beam characteristics between two beam_devices. - - It is recommended to at least define one incident and one detection beam. - If this beam is directly connected to a source, chose here the same - name appendix as for the NXsource (e.g. TYPE=532nm) - - The path to the source which emitted this beam. + The path to the device which emitted this beam (light source or frequency doubler). - Is recommended, if the previous optical element is a photon source. + This parameter is recommended, if the previous optical element is a photon source. In this way, the properties of the laser or light souce can be described and associated. The beam should be named with the same appendix as the source, e.g., @@ -413,130 +298,15 @@ This information may be as well stored in an incident and detection beam--> - Description of the light polarization of the respective beam and the beam-sample-normal. - This is only well defined, if the beam direclty hits the sample (either indicent - beam or detection beam) and if the samples needs to have a clearly - defined sample surface. The beam-sample-normal plane is spanned by - the beam and the samples surface normal. - - If the electric field in in this plane, this value is 0° (P-pol) - If the electric field is perpendicular to this plane, this value is 90° (S-pol) - If the surface normal is parallel to the beam direction, then only the - relation between different polarizations has to be consistent - (i.e. parallel polarized 0° and cross polarized 90°) + Angle of the linear polarized light, with respect to a fixed arbitrary + defined 0° position. This can be used if no definition of respective + cooridnate systems for beam and sample normal is done. If coordinate systems + are - - - - - Angle(s) of the incident beam vs. the normal of the bottom reflective - (substrate) surface in the sample. These two directions span the plane - of incidence. - - - - - - - - - Detection angle(s) of the beam reflected or scattered off the sample - vs. the normal of the bottom reflective (substrate) surface in the - sample if not equal to the angle(s) of incidence. - These two directions span the plane of detection. - - - - - - - - Angle between the incident and detection beam. - If angle_of_detection + angle_of_incidence = angle_of_incident_and_detection_beam, - then the setup is a reflection setup. - If angle_of_detection + angle_of_incidence != angle_of_incident_and_detection_beam - then the setup may be a light scattering setup. - (i.e. 90° + 90° != 90°, i.e. incident and detection beam in the sample surface, but - the angle source-sample-detector is 90°) - - - - - - - - - Angle of the inplane orientation of the sample. This might be an arbitrary, - angle without specific relation to the sample symmetry, - of the angle to a specific sample property (i.e. crystallographic axis or sample - shape such as wafer flat) - - - - - - - - Specify if there is a lateral offset on the sample surface, between the focal - points of the incident beam and the detection beam. - - - - - - - - - - - - - - - - - - - Specification of type, may also go to name. - - - - - - Details about the device information. - - - - - The path to a beam emitted by this source. - Should be named with the same appendix, e.g., - for TYPE=532nmlaser, there should as well be - a NXbeam named "beam_532nmlaser" together with this source - instance named "source_532nmlaser" - - Example: /entry/instrument/beam_532nmlaser - - - - - You may add here data which characterises the source in more detail, - such as spectral power density, power dependency on line width, line-shape - of the laser line, etc. - - - - + @@ -551,9 +321,11 @@ this might require a different reference frame. + + @@ -562,17 +334,6 @@ this might require a different reference frame. Type of detector, if "other" was selected in "detector_type". - - - You may add here data which characterizes the detector, such as quantum - efficiency as function of wavelength or angular dependency of intenty. - - - - - - - Contains the raw data collected by the detector before calibration. @@ -581,7 +342,7 @@ this might require a different reference frame. This field ideally collects the data with the lowest level of processing possible. - - + + + + + + Raw data before calibration. + + + + + + Specify respective hardware which was used to for the detector. For + example special electronics required for time-correlated single photon + counting (TCSPC). + + + + + + + + + + + + + + + + + + + + + Specification of type, may also go to name. + + + + + + If available, name/ID/norm of the light source standard. + + + + + Details about the device information. + + + + + The path to a beam emitted by this source. + Should be named with the same appendix, e.g., + for TYPE=532nmlaser, there should as well be + a NXbeam named "beam_532nmlaser" together with this source + instance named "source_532nmlaser" + + Example: /entry/instrument/beam_532nmlaser + + + + + + + + + Defines the reference frame which is used to describe the sample orientation + with respect to the beam directions. + + A beam centered description is the default and uses 4 angles(similar to XRD): + - Omega (angle between sample surface and incident beam) + - 2Theta (angle between the transmitted beam and the detection beam) + - Chi (sample tilt angle, angle between plane#1 and the surface normal, + plane#1 = spanned by incidence beam and detection + and detection. If Chi=0°, then plane#1 is the plane of + incidence in reflection setups) + - Phi (inplane rotation of sample, rotation axis is the samples + surface normal) + + + A sample normal centered description is as well possible: + - angle of incidence (angle between incident beam and sample surface) + - angle of detection (angle between detection beam and sample surface) + - angle of incident and detection beam + - angle of in-plane sample rotation (direction along the sample's surface normal) + + An arbitrary reference frame can be defined by "reference_frames" + and used via "instrument/angle_sample_and_beam_TYPE" + + + + + + + + + Angle between sample incident beam and sample surface. + + + + + Angle between incident and detection beam + + + + + Sample tilt between sample normal, and the plane spanned by detection and + incident beam. + + + + + Inplane rotation of the sample, with rotation axis along sample normal. + + + + + Angle(s) of the incident beam vs. the normal of the bottom reflective + (substrate) surface in the sample. These two directions span the plane + of incidence. + + + + + Detection angle(s) of the beam reflected or scattered off the sample + vs. the normal of the bottom reflective (substrate) surface in the + sample if not equal to the angle(s) of incidence. + These two directions span the plane of detection. + + + + + Angle between the incident and detection beam. + If angle_of_detection + angle_of_incidence = angle_of_incident_and_detection_beam, + then the setup is a reflection setup. + If angle_of_detection + angle_of_incidence != angle_of_incident_and_detection_beam + then the setup may be a light scattering setup. + (i.e. 90° + 90° != 90°, i.e. incident and detection beam in the sample surface, but + the angle source-sample-detector is 90°) + + + + + Angle of the inplane orientation of the sample. This might be an arbitrary, + angle without specific relation to the sample symmetry, + of the angle to a specific sample property (i.e. crystallographic axis or sample + shape such as wafer flat) + + + + + Set of transformations, describing the relative orientation of different + parts of the experiment (beams or sample). You may select one of the specified + angles for incident and detection beam or sample, and then use polar and azimuthal + angles to define the direction via sperical coordinates. + This allows consistent defintion between different coordinate system. + You may refer to self defined coordinate system as well. + + + If "angle_reference_frame = beam centered", then this coordinate system is used: + McStas system (NeXus default) + (https://manual.nexusformat.org/design.html#mcstas-and-nxgeometry-system) + + i.e. the z-coordinate math:`[0,0,1]` is along the incident beam direction and + the x-coordinate math:`[1,0,0]` is in the horizontal plane. Hence, usually math:`[0,1,0]` + is vertically oriented. + + If "angle_reference_frame = sample-normal centered", then this coordinate + system is used + z - math:`[0,0,1]` along sample surface normal + x - math:`[1,0,0]` defined by sample surface projected incident beam. + y - math:`[0,1,0]` in the sample surface, orthogonal to z and x. + For this case, x may be ill defined, if the incident beam is perpendicular + to the sample surface. In this case, use the beam centered description. + + + + + + + + + + + R + + + + - + + + + + + - Raw data before calibration. + Path to a transformation that places the sample surface + into the origin of the arpes_geometry coordinate system. - - + + + + + Rotation about the z axis (azimuthal rotation within the sample plane). + + + + + + + + + + + + + + + + + - - + + + Specify if there is a lateral offset on the sample surface, between the focal + points of the incident beam and the detection beam. + + + + + Describes the order of respective beam devices in the optical beam + path. + + Everything object which interacts or modifies optical beam properties, + may be an beam device, e.g. Filter, Window, Beamsplitter, Photon Source, + Detector, etc, + + It is intended, to include this functionality later to "older" beam + components, such as NXsource, NXdetector, NXlens, etc. + Until this is possbible, auxillary beam devices have to be created, + for each "older" beam component instead, to allow a beam path description. + To link the auxillary beam device to the real device properties, the + attribute \@device should be used. + + - Characteristics of the monochromator as diffraction efficiency as - wavelength and polarization dependence + Reference to beam device, which is described by a NeXus concept + (e.g. for NXsource, entry/instrument/source_TYPE). - - - - - - + + + + Reference to the previous beam device, from which the photon beam came + to reach this beam device. A photon source is related as origin by ".". + This enables a logical order description of the optical setup. + + @@ -647,39 +644,10 @@ this might require a different reference frame. - - - The numerical aperture of the used incident light optics. - - - - - Magnification of the lens. - - - - - Details about the optical component, if available. - - - + - - - - - - - Array of pairs of complex refractive indices n + ik of the medium - for every measured spectral point/wavelength/energy. - Only necessary if the measurement was performed not in air, or - something very well known, e.g. high purity water. - - - - - - + + polarization filter to prepare light to be measured or to be incident @@ -708,7 +676,7 @@ this might require a different reference frame. Polarizer... - + @@ -759,43 +727,9 @@ this might require a different reference frame. - - - - - - - Describes the order of respective beam devices in the optical beam - path. - - Everything object which interacts or modifies optical beam properties, - may be an beam device, e.g. Filter, Window, Beamsplitter, Photon Source, - Detector, etc, - - It is intended, to include this functionality later to "older" beam - components, such as NXsource, NXdetector, NXlens, etc. - Until this is possbible, auxillary beam devices have to be created, - for each "older" beam component instead, to allow a beam path description. - To link the auxillary beam device to the real device properties, the - attribute \@device should be used. - - - - Reference to beam device, which is described by a NeXus concept - (e.g. for NXsource, entry/instrument/source_TYPE). - - - - - Reference to the previous beam device, from which the photon beam came - to reach this beam device. A photon source is related as origin by ".". - This enables a logical order description of the optical setup. - - + - + Sample stage (or manipulator) for positioning of the sample. This should @@ -821,23 +755,23 @@ Nexus definitions for source, detector, monochromator, ...--> of the stage type. - - + - This is a placeholder, to describe the relation between the samples - coordinate system, laboratory coordinate system and the stage coordinate - system. Up to now, use the "beam_sample_relation" to give supporting - information. + This allows a description of the stages relation or orientation and + position with respect to the sample or beam, if an laboratory or + an stage coordinate system is defined. - + Description of relation of the beam with the sample. How dit the sample hit the beam, e.g. 'center of sample, long edge parallel to the plane of incidence'. + Is redundent, if a full orientation description is done via the + stages "transformations" entry. - + @@ -848,7 +782,7 @@ Nexus definitions for source, detector, monochromator, ...--> - + @@ -872,11 +806,123 @@ Nexus definitions for source, detector, monochromator, ...--> Hardware used for actuation, i.e. laser, gas lamp, filament, resistive - + - + + + + + General device information of the optical spectroscopy setup, if + suitable (e.g. for a tabletop spectrometer or other non-custom build setups). + For custom build setups, this may be limited to the construction year. + + + + + + + + + + Commercial or otherwise defined given name of the program that was + used to control any parts of the optical spectroscopy setup. + The uppercase TYPE should be replaced by a specification name, i.e. + "software_detector" or "software_stage" to specify the respective + program or software components. + + + + Either version with build number, commit hash, or description of a + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + + + + + Description of the software by persistent resource, where the program, + code, script etc. can be found. + + + + + + + Pre-calibration of an arbitrary device of the instrumental setup, which + has the name DEVICE. You can specify here how, at which time by which method + the calibration was done. As well the accuracy and a link to the calibration + dataset. + + + + Path to the device, which was calibrated. + Example: entry/instrument/DEVICE + + + + + Provide data about the determined accuracy of the device, this may + may be a single value or a dataset like wavelength error vs. wavelength etc. + + + + + Was a calibration performed? If yes, when was it done? If the + calibration time is provided, it should be specified in + ENTRY/INSTRUMENT/calibration/calibration_time. + + + + + + + + + + + + If calibtration status is 'calibration time provided', specify the + ISO8601 date when calibration was last performed before this + measurement. UTC offset should be specified. + + + + + Generic data which does not fit to the 'NX_FLOAT' fields in NXproces. + This can be for example the instrument response function. + + + + + + The overall resolution of the optical instrument. + + + + + + + + + + Minimum distinguishable wavelength separation of peaks in spectra. + + + + + Array of pairs of complex refractive indices n + ik of the medium + for every measured spectral point/wavelength/energy. + Only necessary if the measurement was performed not in air, or + something very well known, e.g. high purity water. + + + + + + @@ -893,14 +939,16 @@ Nexus definitions for source, detector, monochromator, ...--> - Uniquely identifying ID of the sample. + Locally unique ID of the sample, used in the reasearch institute or group. + State the form of the sample, examples are: thin film, single crystal, poly crystal, amorphous, single layer, multi layer, liquid, gas, pellet, powder. + Generic properties of liquids or gases see NXsample properties. @@ -945,7 +993,25 @@ Nexus definitions for source, detector, monochromator, ...--> Sample temperature (either controlled or just measured). - + + + If no sensor was available for the determination of temperature, selected + a nominal value which represents approximately the situation of sample temperature. + + + + + + + + + + + If temperature_nominal is "other", enter here a nominal/assumed/estimated + sample temperature. + + + Temperature sensor measuring the sample temperature. This should be a link to /entry/instrument/manipulator/temperature_sensor. @@ -1051,7 +1117,7 @@ Maybe consider here to include NXsample_component_set. - + @@ -1065,9 +1131,11 @@ NXdata. The detailed inclusion of a data collection description (i.e. raw data from ellipsometry as polarization values to the usually used psi and delta values), will be done later after the NXopt workshop.--> + - >>>This section is transfered from the first NXopt version and might - require a reqwork.<<< Parameters that are derived from the measured data. diff --git a/contributed_definitions/NXopt_window.nxdl.xml b/contributed_definitions/NXopt_window.nxdl.xml index bdc29f6110..f1fc90e670 100644 --- a/contributed_definitions/NXopt_window.nxdl.xml +++ b/contributed_definitions/NXopt_window.nxdl.xml @@ -56,6 +56,17 @@ A draft of a new base class to describe a window in a optical setup or device--> correction procedure in 'window_correction/procedure'. + + + Type of effects due to this window on the measurement. + + + + + + + + Was a window correction performed? If 'True' describe the diff --git a/contributed_definitions/NXraman.nxdl.xml b/contributed_definitions/NXraman.nxdl.xml index 79576265f8..18d9caa6f1 100644 --- a/contributed_definitions/NXraman.nxdl.xml +++ b/contributed_definitions/NXraman.nxdl.xml @@ -29,7 +29,7 @@ N_incident_beams: | - + Variables used throughout the document, e.g. dimensions or parameters. @@ -153,7 +153,7 @@ A draft version of a NeXus application definition for Raman spectroscopy.--> - + Specify the type of the optical experiment. @@ -214,10 +214,7 @@ A draft version of a NeXus application definition for Raman spectroscopy.--> Unpolarized light is displayed by "." For non-orthogonal vectors, use the attribute porto_notation_vectors. - - + Scattering configuration as defined by the porto notation given by respective vectors. diff --git a/contributed_definitions/NXwaveplate.nxdl.xml b/contributed_definitions/NXwaveplate.nxdl.xml index e5c76dbfca..2d04aa9412 100644 --- a/contributed_definitions/NXwaveplate.nxdl.xml +++ b/contributed_definitions/NXwaveplate.nxdl.xml @@ -1,10 +1,10 @@ - + - - + + @@ -83,6 +84,11 @@ + + + Wavelength resolved retardence of the waveplate. + + Diameter of the waveplate. diff --git a/contributed_definitions/nyaml/NXellipsometry.yaml b/contributed_definitions/nyaml/NXellipsometry.yaml index cabb04c8d1..84093ac00c 100644 --- a/contributed_definitions/nyaml/NXellipsometry.yaml +++ b/contributed_definitions/nyaml/NXellipsometry.yaml @@ -64,7 +64,7 @@ symbols: # A rework of the draft version(06/2022) of a NeXus application definition for ellipsometry. type: group -NXellipsometry(NXopt): +NXellipsometry(NXoptical_spectroscopy): (NXentry): definition: doc: | @@ -79,6 +79,7 @@ NXellipsometry(NXopt): to the application definition. enumeration: [NXellipsometry] title: + exists: recommended experiment_type: doc: | Specify the type of the optical experiment. @@ -111,6 +112,7 @@ NXellipsometry(NXopt): were corrected for the window effects. # This as well can be stated in window/aperture data_correction(NX_BOOLEAN): + exists: recommended doc: | Were the recorded data corrected by the window effects of the focussing probes (lenses)? @@ -156,6 +158,7 @@ NXellipsometry(NXopt): # included in the generic NXopt, but is now keept limited to # NXellipsometry. data_collection(NXdata): + exists: optional doc: | Measured data, data errors, and varied parameters. This may be used to describe indirectly derived data or data transformed between different descriptions, @@ -170,10 +173,12 @@ NXellipsometry(NXopt): in a generic (NXdata) concept from NXopt, or better directly in the location of the sample positioner or temperature sensor. data_identifier(NX_NUMBER): + exists: recommended doc: | An identifier to correlate data to the experimental conditions, if several were used in this measurement; typically an index of 0-N. data_type: + exists: recommended doc: | Select which type of data was recorded, for example intensity, reflectivity, transmittance, Psi and Delta etc. @@ -255,6 +260,7 @@ NXellipsometry(NXopt): data_software(NXprogram): exists: optional program: + exists: recommended doc: | Commercial or otherwise defined given name of the program that was used to generate the result file(s) with measured data and/or @@ -262,6 +268,7 @@ NXellipsometry(NXopt): If home written, one can provide the actual steps in the NOTE subfield here. version: + exists: recommended doc: | Either version with build number, commit hash, or description of a (online) repository where the source code of the program and build diff --git a/contributed_definitions/nyaml/NXlens_opt.yaml b/contributed_definitions/nyaml/NXlens_opt.yaml index 625aa9c40b..43b93190c1 100644 --- a/contributed_definitions/nyaml/NXlens_opt.yaml +++ b/contributed_definitions/nyaml/NXlens_opt.yaml @@ -117,7 +117,12 @@ NXlens_opt(NXobject): unit: NX_UNITLESS doc: | Abbe number (or V-number) of the lens. - + numerical_aperture(NX_NUMBER): + doc: | + The numerical aperture of the used incident light optics. + magnification(NX_FLOAT): + doc: | + Magnification of the lens. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ # 691e29df6cdccccbeb03000ebbd435adb2c77135939ffb1d329d7da9d11c6539 # diff --git a/contributed_definitions/nyaml/NXopt.yaml b/contributed_definitions/nyaml/NXopt.yaml index a592610114..0875bfad83 100644 --- a/contributed_definitions/nyaml/NXopt.yaml +++ b/contributed_definitions/nyaml/NXopt.yaml @@ -8,6 +8,9 @@ doc: | A general optical experiment consists of (i) a light/photon source, (ii) a sample, (iii) a detector. + + For any free text descriptions, it is recommended to enter data in english + language, as this is the most FAIR representation. symbols: doc: | Variables used throughout the document, e.g. dimensions or parameters. @@ -19,29 +22,19 @@ symbols: equal to the number of parameters scanned. For example, if the experiment was performed at three different temperatures and two different pressures N_measurements = 2*3 = 6. - N_detection_angles: | - Number of detection angles of the beam reflected or scattered off the - sample. - N_incident_angles: | - Number of angles of incidence of the incident beam. # 04/2024 # Extension of the Draft Version (05/2023) of a NeXus application definition which # serves as a template for various optical spectroscopy experiments # # TODO: -# - Merge reference_frames with angle_reference_frame -# - Rework instrument_calibration_DEVICE - use NXcalibration? -# - Beam polarizations: Own Polarization concept with angle or from NXbeam via beam coordinates? (solve reference frame problem first) -# - Describe angle_of_detection by NXtransformations -# - remove NXmonchromator? as it is already in NXinstrument # - Add NXlens_opt and NXwaveplate to NXinstrument? -# - Make sample stage_stage(NXmanipulator)/reference_frame via NXtransformations -# - Add properties from NXlens_opt from NXopt to NXlens_opt base class # - Make polfilter_TYPE(NXbeam_device) own base class --> rework NXpolarizer_opt. and add them to NXinstrument. # - Make spectralfilter_TYPE(NXbeam_device) own base class --> extend NXfilter? and add them to NXinstrument. +# - Make offset angles for polar and azimutal? +# - Can angle_reference_frame be replaced later by only using reference_frames and generic angle description? type: group -NXopt(NXobject): +NXoptical_spectroscopy(NXobject): (NXentry): definition: doc: | @@ -54,19 +47,25 @@ NXopt(NXobject): doc: | URL where to find further material (documentation, examples) relevant to the application definition. - enumeration: [NXopt] + enumeration: [NXoptical_spectroscopy] title: + exists: recommended start_time(NX_DATE_TIME): + exists: recommended doc: | Datetime of the start of the measurement. Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, otherwise, the local time zone is assumed per ISO8601. + + It is required to enter at least one of both measurement times, either "start_time" or "end_time". end_time(NX_DATE_TIME): exists: recommended doc: | Datetime of the end of the measurement. Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, otherwise the local time zone is assumed per ISO8601. + + It is required to enter at least one of both measurement times, either "start_time" or "end_time". experiment_identifier(NXidentifier): exists: recommended doc: | @@ -78,6 +77,14 @@ NXopt(NXobject): exists: optional identifier(NX_CHAR): exists: recommended + identifier_type: + exists: recommended + doc: | + Select the range of validity of this identier. + Local: Setup#1 at Institute building #2 in Room #3 + Global: Unique identification of with by unique location and unique + globally persistent time stamp. + enumeration: [local, global] is_persistent(NX_BOOLEAN): exists: optional experiment_description: @@ -98,17 +105,16 @@ NXopt(NXobject): Chose other if none of these methods are suitable. You may specify fundamental characteristics or properties in the experimental sub-type. - enumeration: [ellipsometry, Raman spectroscopy, photoluminescence, transmission spectroscopy, reflection spectroscopy, other] + + For Raman spectroscopy or ellipsometry use the respective specializations + of NXoptical_spectroscopy. + enumeration: [photoluminescence, transmission spectroscopy, reflection spectroscopy, other] experiment_sub_type: exists: optional doc: | Specify a special property or characteristic of the experiment, which specifies the generic experiment type. enumeration: [time resolved, imaging, pump-probe, other] - # Replace maybe sub_type with exp_technique? - #experimental technique --> pump-probe, parameters seperated (i.e. time, space)? - # The above listed things are related to beam properties? This is different - # compared to temperature or pressure. Is this a useful distinction? experiment_type_other: exists: optional doc: | @@ -116,14 +122,36 @@ NXopt(NXobject): specify the experiment here with a free text name, which is knwon in the respective community of interest. reference_frames(NXcoordinate_system_set): - # This should be extended later and hopefully replace angle_reference_frame - # and sample_normal_direction. - # Required reference frames: - # Sample normal, beam_z_axis, sample_stage exists: optional doc: | Description of one or more coordinate systems that are specific to the - experiment. + experiment. Examples are beam centered, sample-normal centered, + laboratory-system centered, sample-stage centered, crystal-symmetry centered. + beam_ref_frame(NXcoordinate_system): + exists: optional + depends_on(NX_CHAR): + doc: | + This refers to the coordinate system along the beam path. The origin and + base is defined at z=0, where the incident beam hits the sample at the surface. + (NXtransformations): + doc: | + This is the default NeXus coordinate system (McStas), if the transformation + does not change the coordinate system at all - i.e. it is unity. + Otherwise, by this a respective transformation of the beam + reference frame to the default reference frame could be made. i.e. + exchange of x and z coordinate, rotation of respective coordinates + towards each other. + sample_normal_ref_frame(NXcoordinate_system): + exists: optional + depends_on(NX_CHAR): + doc: | + Link to transformations defining the sample-normal base coordinate system, + which is defined such that the positive z-axis is parallel to the sample normal, + and the x-y-plane lies inside the sample surface. + (NXtransformations): + doc: | + Set of transformations, describing the orientation of the sample-normal coordinate system + with respect to the beam coordinate system (.). (NXuser): exists: [min, 0, max, infty] doc: | @@ -134,6 +162,8 @@ NXopt(NXobject): It is recommended to add multiple users if relevant. Due to data privacy concerns, there is no minimum requirement. + If no user with specific name is allowed to be given, it is required to + assign at least an affiliation (NXinstrument): doc: | Devices or elements of the optical spectroscopy setup described with its @@ -149,154 +179,25 @@ NXopt(NXobject): - "Beam devices" for a beam path description - Stages(NXmanipulator) - Sensors and actuators to control or measure sample or beam properties - device_information(NXfabrication): - doc: | - General device information of the optical spectroscopy setup, if - suitable (e.g. for a tabletop spectrometer or other non-custom build setups). - For custom build setups, this may be limited to the construction year. - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended - construction_year(NX_DATE_TIME): - exists: optional - software_TYPE(NXprogram): - exists: recommended - program: - doc: | - Commercial or otherwise defined given name of the program that was - used to control any parts of the optical spectroscopy setup. - The uppercase TYPE should be replaced by a specification name, i.e. - "software_detector" or "software_stage" to specify the respective - program or software components. - \@version: - exists: recommended - doc: | - Either version with build number, commit hash, or description of a - (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner. - \@url: - exists: optional - doc: | - Description of the software by persistent resource, where the program, - code, script etc. can be found. - # The angle_reference_frame will be connected later to general reference frames - # For this this solution enables the description of the beam relations for - # different optical spectroscopy methods in the reference frame they are used to - angle_reference_frame: - doc: | - Defines the reference frame which is used to describe the sample orientation - with respect to the beam directions. - - A beam centered description is the default and uses 4 angles(similar to XRD): - - Omega (angle between sample surface and incident beam) - - 2Theta (angle between the transmitted beam and the detection beam) - - Chi (sample tilt angle, angle between plane#1 and the surface normal, - plane#1 = spanned by incidence beam and detection - and detection. If Chi=0°, then plane#1 is the plane of - incidence in reflection setups) - - Phi (inplane rotation of sample, rotation axis is the samples - surface normal) - - - A sample normal centered description is as well possible(similar to XX): - - angle of incidence (angle between incident beam and sample surface) - - angle of detection (angle between detection beam and sample surface) - - angle of incident and detection beam (angle between the incident and scattering beam) - - angle of in-plane sample rotation (direction along the sample's surface normal) - - # For the sample centered approach, it has to be avoided, that the detection beam, - # incident beam or surface normal beam are parallel to each other - # (Is this a problem for Raman backscattering?) - # For beam centered approach (as done for beamlines), the grativation and beam direction are used to define - # the coordinate system. As beamlines are usually built flat - there is no case - # in which these two vectors can be parallel to each other - # This is different with the surface normal. Aside of the surface normal, - # at least one further additional natural direction is required. - # This could be the magnetic/geographic north pole - # magnetic north pole: easy to determine, but time depenent (long term) - # geographic north pole: harder to determine? (What about GPS?), but constant with time - - enumeration: [beam centered, sample normal centered] - wavelength_resolution(NXresolution): - exists: optional - doc: | - The overall resolution of the optical instrument. - physical_quantity: - enumeration: [wavelength] - type: - exists: recommended - resolution(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - Minimum distinguishable wavelength separation of peaks in spectra. - instrument_calibration_DEVICE(NXsubentry): - exists: recommended - doc: | - Pre-calibration of an arbitrary device of the instrumental setup, which - has the name DEVICE. You can specify here how, at which time by which method - the calibration was done. As well the accuracy and a link to the calibration - dataset. - device_path: - exists: recommended - doc: | - Path to the device, which was calibrated. - Example: entry/instrument/DEVICE - calibration_method: - exists: optional - doc: - Describe here the approach or method, used to perform the calibration, - by a free text. - calibration_accuracy(NXdata): - exists: optional - doc: | - Provide data about the determined accuracy of the device, this may - may be a single value or a dataset like wavelength error vs. wavelength etc. - calibration_status(NX_CHAR): - exists: recommended - doc: | - Was a calibration performed? If yes, when was it done? If the - calibration time is provided, it should be specified in - ENTRY/INSTRUMENT/calibration/calibration_time. - enumeration: [calibration time provided, no calibration, within 1 hour, within 1 day, within 1 week] - calibration_time(NX_DATE_TIME): - exists: optional - doc: | - If calibtration status is 'calibration time provided', specify the - ISO8601 date when calibration was last performed before this - measurement. UTC offset should be specified. - calibration_data_link(NXidentifier): - exists: recommended - doc: | - Link to the NeXus file containing the calibration data and metadata. - # Discussion - # ########## - # The basic idea was: You have always an incident source and a detector. - # Therefore, you always have an incident beam and a "detection beam". - # These beams can be assigned clear incident and detection angles. - # - # This information is always of relevance for ellipsometry, - # but for Raman experiments, the state of polarization is as well of relevance - # Additonally, this is limited for incident, detection and sample normal - # to be in one plane. This does not have to be the case for Raman scattering - # experiments. Therefore, this is not general enough and may be moved to - # NXellipsometry. - # This information may be as well stored in an incident and detection beam - - # beam properties beam_TYPE(NXbeam): - exists: [min, 0, max, infty] + exists: [min, 1, max, infty] doc: | - Beam characteristics between two beam_devices. + This can be used to describe properties of a photon beam. + A beam is always defined between two beam_devices, via + "previous_device" and "next_device". - It is recommended to at least define one incident and one detection beam. - If this beam is directly connected to a source, chose here the same - name appendix as for the NXsource (e.g. TYPE=532nm) + It is required to define at least one incident beam which is incident + to the sample. You may specify if this beam parameters are acutally measured + or just nominal. + If this beam is the output of a source, chose the same + name appendix as for the NXsource instance (e.g. TYPE=532nm) + parameter_reliability: + exists: required + doc: | + Select the reliability of the respective beam characteristics. Either, + the parameters are measured via another device or method or just given + nominally via the properties of a light source properties (532nm, 100mW). + enumeration: [measured, nominal] incident_wavelength(NX_NUMBER): exists: recommended incident_wavelength_spread(NX_NUMBER): @@ -308,9 +209,9 @@ NXopt(NXobject): associated_source(NX_CHAR): exists: optional doc: | - The path to the source which emitted this beam. + The path to the device which emitted this beam (light source or frequency doubler). - Is recommended, if the previous optical element is a photon source. + This parameter is recommended, if the previous optical element is a photon source. In this way, the properties of the laser or light souce can be described and associated. The beam should be named with the same appendix as the source, e.g., @@ -325,139 +226,24 @@ NXopt(NXobject): linear_beam_sample_polarization(NX_NUMBER): exists: optional doc: | - Description of the light polarization of the respective beam and the beam-sample-normal. - This is only well defined, if the beam direclty hits the sample (either indicent - beam or detection beam) and if the samples needs to have a clearly - defined sample surface. The beam-sample-normal plane is spanned by - the beam and the samples surface normal. - - If the electric field in in this plane, this value is 0° (P-pol) - If the electric field is perpendicular to this plane, this value is 90° (S-pol) - If the surface normal is parallel to the beam direction, then only the - relation between different polarizations has to be consistent - (i.e. parallel polarized 0° and cross polarized 90°) + Angle of the linear polarized light, with respect to a fixed arbitrary + defined 0° position. This can be used if no definition of respective + cooridnate systems for beam and sample normal is done. If coordinate systems + are unit: NX_ANGLE - # The given angles may be extended similar to NXmpes, to allow a simple - # as well as an arbitrary description via NXtransformations - # - # fundamental orientation of incident and detection beam - angle_of_incidence(NX_NUMBER): - # relation beam directions (incident and detection) with sample orientation - # these angles are quite simple. They might be extended similar to - # NXmpes_liquid with leaf_normal to allow arbitrary description. - # this might require a different reference frame. - exists: optional - unit: NX_ANGLE - doc: | - Angle(s) of the incident beam vs. the normal of the bottom reflective - (substrate) surface in the sample. These two directions span the plane - of incidence. - dimensions: - rank: 1 - dim: [[1, N_incident_angles]] - \@units: - angle_of_detection(NX_NUMBER): - exists: optional - unit: NX_ANGLE - doc: | - Detection angle(s) of the beam reflected or scattered off the sample - vs. the normal of the bottom reflective (substrate) surface in the - sample if not equal to the angle(s) of incidence. - These two directions span the plane of detection. - dimensions: - rank: 1 - dim: [[1, N_detection_angles]] - angle_of_incident_and_detection_beam(NX_NUMBER): - exists: optional - unit: NX_ANGLE - doc: | - Angle between the incident and detection beam. - If angle_of_detection + angle_of_incidence = angle_of_incident_and_detection_beam, - then the setup is a reflection setup. - If angle_of_detection + angle_of_incidence != angle_of_incident_and_detection_beam - then the setup may be a light scattering setup. - (i.e. 90° + 90° != 90°, i.e. incident and detection beam in the sample surface, but - the angle source-sample-detector is 90°) - - dimensions: - rank: 1 - dim: [[1, XX]] - \@units: - angle_of_in_plane_sample_rotation(NX_NUMBER): - exists: optional - unit: NX_ANGLE - doc: | - Angle of the inplane orientation of the sample. This might be an arbitrary, - angle without specific relation to the sample symmetry, - of the angle to a specific sample property (i.e. crystallographic axis or sample - shape such as wafer flat) - dimensions: - rank: 1 - dim: [[1, XX]] - lateral_focal_point_offset(NX_NUMBER): - exists: optional - unit: NX_LENGTH - doc: | - Specify if there is a lateral offset on the sample surface, between the focal - points of the incident beam and the detection beam. - # beam path elements - source_TYPE(NXsource): - exists: [min, 1, max, infty] - type: - exists: recommended - enumeration: [laser, dye-laser, broadband tunable light source, X-ray Source, arc lamp, halogen lamp, LED, other] - type_other: - exists: optional - doc: | - Specification of type, may also go to name. - name: - exists: recommended - device_information(NXfabrication): - doc: | - Details about the device information. - associated_beam(NX_CHAR): - doc: | - The path to a beam emitted by this source. - Should be named with the same appendix, e.g., - for TYPE=532nmlaser, there should as well be - a NXbeam named "beam_532nmlaser" together with this source - instance named "source_532nmlaser" - - Example: /entry/instrument/beam_532nmlaser - device_characteristics(NXdata): - exists: optional - doc: | - You may add here data which characterises the source in more detail, - such as spectral power density, power dependency on line width, line-shape - of the laser line, etc. detector_TYPE(NXdetector): exists: [min, 1, max, infty] detector_channel_type: - exists: recommended enumeration: [single-channel, multichannel] detector_type: exists: recommended doc: | Description of the detector type. - enumeration: [CCD, Photomultiplier, Photodiode, Avalanche-Photodiode, Bolometer, Golay Detectors, Pyroelectric Detector, other] + enumeration: [CCD, Photomultiplier, Photodiode, Avalanche-Photodiode, Streak Camera, Bolometer, Golay Detectors, Pyroelectric Detector, Deuterated Triglycine Sulphate, other] detector_type_other: exists: optional doc: | Type of detector, if "other" was selected in "detector_type". - device_characteristics(NXdata): - exists: optional - doc: | - You may add here data which characterizes the detector, such as quantum - efficiency as function of wavelength or angular dependency of intenty. - - device_information(NXfabrication): - exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended raw_data(NXdata): exists: recommended doc: | @@ -467,7 +253,7 @@ NXopt(NXobject): This field ideally collects the data with the lowest level of processing possible. - # Define a similar convention for NXopt? Or only for NXraman, NXellipsometry and NXphotoluminescence? + # Define a similar convention for NXoptical_spectroscopy? Or only for NXraman, NXellipsometry and NXphotoluminescence? # Fields should be named according to new following convention: # # - **pixel_x**: Detector pixel in x direction. @@ -498,21 +284,217 @@ NXopt(NXobject): raw(NX_NUMBER): doc: | Raw data before calibration. - (NXmonochromator): - exists: optional - device_characteristics(NXdata): + additional_detector_hardware: + doc: | + Specify respective hardware which was used to for the detector. For + example special electronics required for time-correlated single photon + counting (TCSPC). + device_information(NXfabrication): + exists: recommended + source_TYPE(NXsource): + exists: recommended + type: + exists: recommended + enumeration: [laser, dye-laser, broadband tunable light source, X-ray Source, arc lamp, halogen lamp, LED, mercury cadmium telluride, other] + type_other: + exists: optional + doc: | + Specification of type, may also go to name. + name: + exists: recommended + standard: exists: optional doc: | - Characteristics of the monochromator as diffraction efficiency as - wavelength and polarization dependence + If available, name/ID/norm of the light source standard. device_information(NXfabrication): exists: recommended - vendor: - exists: recommended - model: - exists: recommended - identifier: - exists: recommended + doc: | + Details about the device information. + associated_beam(NX_CHAR): + doc: | + The path to a beam emitted by this source. + Should be named with the same appendix, e.g., + for TYPE=532nmlaser, there should as well be + a NXbeam named "beam_532nmlaser" together with this source + instance named "source_532nmlaser" + + Example: /entry/instrument/beam_532nmlaser + (NXmonochromator): + exists: recommended + device_information(NXfabrication): + exists: recommended + + angle_reference_frame: + exists: recommended + doc: | + Defines the reference frame which is used to describe the sample orientation + with respect to the beam directions. + + A beam centered description is the default and uses 4 angles(similar to XRD): + - Omega (angle between sample surface and incident beam) + - 2Theta (angle between the transmitted beam and the detection beam) + - Chi (sample tilt angle, angle between plane#1 and the surface normal, + plane#1 = spanned by incidence beam and detection + and detection. If Chi=0°, then plane#1 is the plane of + incidence in reflection setups) + - Phi (inplane rotation of sample, rotation axis is the samples + surface normal) + + + A sample normal centered description is as well possible: + - angle of incidence (angle between incident beam and sample surface) + - angle of detection (angle between detection beam and sample surface) + - angle of incident and detection beam + - angle of in-plane sample rotation (direction along the sample's surface normal) + + An arbitrary reference frame can be defined by "reference_frames" + and used via "instrument/angle_sample_and_beam_TYPE" + + enumeration: [beam centered, sample-normal centered] + + omega(NX_NUMBER): + exists: optional + unit: NX_ANGLE + doc: | + Angle between sample incident beam and sample surface. + twotheta(NX_NUMBER): + exists: optional + unit: NX_ANGLE + doc: | + Angle between incident and detection beam + chi(NX_NUMBER): + exists: optional + unit: NX_ANGLE + doc: | + Sample tilt between sample normal, and the plane spanned by detection and + incident beam. + phi(NX_NUMBER): + exists: optional + unit: NX_ANGLE + doc: | + Inplane rotation of the sample, with rotation axis along sample normal. + + angle_of_incidence(NX_NUMBER): + exists: optional + unit: NX_ANGLE + doc: | + Angle(s) of the incident beam vs. the normal of the bottom reflective + (substrate) surface in the sample. These two directions span the plane + of incidence. + angle_of_detection(NX_NUMBER): + exists: optional + unit: NX_ANGLE + doc: | + Detection angle(s) of the beam reflected or scattered off the sample + vs. the normal of the bottom reflective (substrate) surface in the + sample if not equal to the angle(s) of incidence. + These two directions span the plane of detection. + angle_of_incident_and_detection_beam(NX_NUMBER): + exists: optional + unit: NX_ANGLE + doc: | + Angle between the incident and detection beam. + If angle_of_detection + angle_of_incidence = angle_of_incident_and_detection_beam, + then the setup is a reflection setup. + If angle_of_detection + angle_of_incidence != angle_of_incident_and_detection_beam + then the setup may be a light scattering setup. + (i.e. 90° + 90° != 90°, i.e. incident and detection beam in the sample surface, but + the angle source-sample-detector is 90°) + angle_of_in_plane_sample_rotation(NX_NUMBER): + exists: optional + unit: NX_ANGLE + doc: | + Angle of the inplane orientation of the sample. This might be an arbitrary, + angle without specific relation to the sample symmetry, + of the angle to a specific sample property (i.e. crystallographic axis or sample + shape such as wafer flat) + + generic_beam_sample_angle_TYPE(NXtransformations): + exists: recommended + doc: | + Set of transformations, describing the relative orientation of different + parts of the experiment (beams or sample). You may select one of the specified + angles for incident and detection beam or sample, and then use polar and azimuthal + angles to define the direction via sperical coordinates. + This allows consistent defintion between different coordinate system. + You may refer to self defined coordinate system as well. + + + If "angle_reference_frame = beam centered", then this coordinate system is used: + McStas system (NeXus default) + (https://manual.nexusformat.org/design.html#mcstas-and-nxgeometry-system) + + i.e. the z-coordinate math:`[0,0,1]` is along the incident beam direction and + the x-coordinate math:`[1,0,0]` is in the horizontal plane. Hence, usually math:`[0,1,0]` + is vertically oriented. + + If "angle_reference_frame = sample-normal centered", then this coordinate + system is used + z - math:`[0,0,1]` along sample surface normal + x - math:`[1,0,0]` defined by sample surface projected incident beam. + y - math:`[0,1,0]` in the sample surface, orthogonal to z and x. + For this case, x may be ill defined, if the incident beam is perpendicular + to the sample surface. In this case, use the beam centered description. + type: + enumeration: [incident beam, detection beam, sample] + polar(NX_NUMBER): + unit: NX_ANGLE + doc: | + R + \@transformation_type: + enumeration: [rotation] + \@vector: + enumeration: [[0, 1, 0]] + \@depends_on: + doc: | + Path to a transformation that places the sample surface + into the origin of the arpes_geometry coordinate system. + azimuth(NX_NUMBER): + unit: NX_ANGLE + doc: | + Rotation about the z axis (azimuthal rotation within the sample plane). + \@transformation_type: + enumeration: [rotation] + \@vector: + enumeration: [[0, 0, 1]] + \@depends_on: + enumeration: [offset_tilt] + + + lateral_focal_point_offset(NX_NUMBER): + exists: optional + unit: NX_LENGTH + doc: | + Specify if there is a lateral offset on the sample surface, between the focal + points of the incident beam and the detection beam. + + (NXbeam_device): + exists: [min, 0, max, infty] + doc: | + Describes the order of respective beam devices in the optical beam + path. + + Everything object which interacts or modifies optical beam properties, + may be an beam device, e.g. Filter, Window, Beamsplitter, Photon Source, + Detector, etc, + + It is intended, to include this functionality later to "older" beam + components, such as NXsource, NXdetector, NXlens, etc. + Until this is possbible, auxillary beam devices have to be created, + for each "older" beam component instead, to allow a beam path description. + To link the auxillary beam device to the real device properties, the + attribute \@device should be used. + \@device: + exists: recommended + doc: | + Reference to beam device, which is described by a NeXus concept + (e.g. for NXsource, entry/instrument/source_TYPE). + previous_device: + exists: recommended + doc: | + Reference to the previous beam device, from which the photon beam came + to reach this beam device. A photon source is related as origin by ".". + This enables a logical order description of the optical setup. (NXlens_opt): exists: optional doc: | @@ -521,34 +503,12 @@ NXopt(NXobject): Raman scattering process. type: enumeration: [objective, lens, glass fiber, none, other] - numerical_aperture(NX_NUMBER): - doc: | - The numerical aperture of the used incident light optics. - magnification(NX_FLOAT): - doc: | - Magnification of the lens. device_information(NXfabrication): - exists: recommended - doc: | - Details about the optical component, if available. - device_characteristics(NXdata): + exists: optional (NXwaveplate): exists: optional - device_characteristics(NXdata): (NXopt_window): - - sample_medium_refractive_indices(NX_FLOAT): exists: optional - unit: NX_UNITLESS - doc: | - Array of pairs of complex refractive indices n + ik of the medium - for every measured spectral point/wavelength/energy. - Only necessary if the measurement was performed not in air, or - something very well known, e.g. high purity water. - dimensions: - rank: 2 - dim: [[1, 2], [2, N_spectrum]] - polfilter_TYPE(NXbeam_device): exists: optional doc: | @@ -570,6 +530,7 @@ NXopt(NXobject): Free text, for example: Glan-Thompson, Glan-Taylor, Rochon Prism, Wollaston Polarizer... device_information(NXfabrication): + exists: optional spectralfilter_TYPE(NXbeam_device): exists: optional doc: | @@ -600,43 +561,9 @@ NXopt(NXobject): i.e. transmission or reflection properties. enumeration: [transmission, reflection] device_information(NXfabrication): + exists: optional - - # In the following - Auxillary NXbeam_devices are defined, to enable a - # beam path description of the setup, while using the up now available - # Nexus definitions for source, detector, monochromator, ... - - - - # beam devices for beam path description - (NXbeam_device): - exists: [min, 0, max, infty] - doc: | - Describes the order of respective beam devices in the optical beam - path. - - Everything object which interacts or modifies optical beam properties, - may be an beam device, e.g. Filter, Window, Beamsplitter, Photon Source, - Detector, etc, - - It is intended, to include this functionality later to "older" beam - components, such as NXsource, NXdetector, NXlens, etc. - Until this is possbible, auxillary beam devices have to be created, - for each "older" beam component instead, to allow a beam path description. - To link the auxillary beam device to the real device properties, the - attribute \@device should be used. - \@device: - exists: recommended - doc: | - Reference to beam device, which is described by a NeXus concept - (e.g. for NXsource, entry/instrument/source_TYPE). - previous_device: - exists: recommended - doc: | - Reference to the previous beam device, from which the photon beam came - to reach this beam device. A photon source is related as origin by ".". - This enables a logical order description of the optical setup. - # non-beam path elements + (NXbeam_transfer_matrix_table): sample_stage(NXmanipulator): exists: optional doc: | @@ -652,21 +579,22 @@ NXopt(NXobject): doc: | If "other" was chosen in stage_type, enter here a free text description of the stage type. - # This is for now a placeholder and should be specified with NXtransformation - reference_frame: + transformations(NXtransformations): exists: optional doc: | - This is a placeholder, to describe the relation between the samples - coordinate system, laboratory coordinate system and the stage coordinate - system. Up to now, use the "beam_sample_relation" to give supporting - information. + This allows a description of the stages relation or orientation and + position with respect to the sample or beam, if an laboratory or + an stage coordinate system is defined. beam_sample_relation: exists: optional doc: | Description of relation of the beam with the sample. How dit the sample hit the beam, e.g. 'center of sample, long edge parallel to the plane of incidence'. + Is redundent, if a full orientation description is done via the + stages "transformations" entry. device_information(NXfabrication): + exists: optional temperature_sensor(NXsensor): exists: recommended name: @@ -677,6 +605,7 @@ NXopt(NXobject): exists: optional value(NX_FLOAT): device_information(NXfabrication): + exists: optional temp_control_TYPE(NXactuator): doc: Type of control for the sample temperature. Replace TYPE by @@ -694,9 +623,111 @@ NXopt(NXobject): doc: | Hardware used for actuation, i.e. laser, gas lamp, filament, resistive (NXpid): + exists: recommended setpoint(NX_FLOAT): exists: recommended - device_information(NXfabrication): + device_information(NXfabrication): + exists: optional + + device_information(NXfabrication): + exists: recommended + doc: | + General device information of the optical spectroscopy setup, if + suitable (e.g. for a tabletop spectrometer or other non-custom build setups). + For custom build setups, this may be limited to the construction year. + vendor: + exists: recommended + model: + exists: recommended + identifier: + exists: recommended + construction_year(NX_DATE_TIME): + exists: optional + software_TYPE(NXprogram): + exists: recommended + program: + doc: | + Commercial or otherwise defined given name of the program that was + used to control any parts of the optical spectroscopy setup. + The uppercase TYPE should be replaced by a specification name, i.e. + "software_detector" or "software_stage" to specify the respective + program or software components. + \@version: + exists: recommended + doc: | + Either version with build number, commit hash, or description of a + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + \@url: + exists: optional + doc: | + Description of the software by persistent resource, where the program, + code, script etc. can be found. + + instrument_calibration_DEVICE(NXcalibration): + exists: recommended + doc: | + Pre-calibration of an arbitrary device of the instrumental setup, which + has the name DEVICE. You can specify here how, at which time by which method + the calibration was done. As well the accuracy and a link to the calibration + dataset. + device_path: + exists: recommended + doc: | + Path to the device, which was calibrated. + Example: entry/instrument/DEVICE + calibration_accuracy(NXdata): + exists: optional + doc: | + Provide data about the determined accuracy of the device, this may + may be a single value or a dataset like wavelength error vs. wavelength etc. + calibration_status(NX_CHAR): + exists: recommended + doc: | + Was a calibration performed? If yes, when was it done? If the + calibration time is provided, it should be specified in + ENTRY/INSTRUMENT/calibration/calibration_time. + enumeration: [calibration time provided, no calibration, within 1 hour, within 1 day, within 1 week] + calibration_time(NX_DATE_TIME): + exists: optional + doc: | + If calibtration status is 'calibration time provided', specify the + ISO8601 date when calibration was last performed before this + measurement. UTC offset should be specified. + (NXdata): + exists: optional + doc: | + Generic data which does not fit to the 'NX_FLOAT' fields in NXproces. + This can be for example the instrument response function. + + + wavelength_resolution(NXresolution): + exists: optional + doc: | + The overall resolution of the optical instrument. + physical_quantity: + enumeration: [wavelength] + type: + exists: recommended + resolution(NX_FLOAT): + unit: NX_WAVELENGTH + doc: | + Minimum distinguishable wavelength separation of peaks in spectra. + sample_medium_refractive_indices(NX_FLOAT): + exists: optional + unit: NX_UNITLESS + doc: | + Array of pairs of complex refractive indices n + ik of the medium + for every measured spectral point/wavelength/energy. + Only necessary if the measurement was performed not in air, or + something very well known, e.g. high purity water. + dimensions: + rank: 2 + dim: [[1, 2], [2, N_spectrum]] + + (NXsample): doc: | Properties of the sample, such as sample type, layer structure, @@ -710,13 +741,16 @@ NXopt(NXobject): sample_id: exists: recommended doc: | - Uniquely identifying ID of the sample. + Locally unique ID of the sample, used in the reasearch institute or group. + sample_id_global(NXidentifier): + exists: optional physical_form: exists: recommended doc: | State the form of the sample, examples are: thin film, single crystal, poly crystal, amorphous, single layer, multi layer, liquid, gas, pellet, powder. + Generic properties of liquids or gases see NXsample properties. description: exists: optional doc: | @@ -754,7 +788,20 @@ NXopt(NXobject): exists: recommended doc: | Sample temperature (either controlled or just measured). + temperature_nominal: + exists: optional + doc: | + If no sensor was available for the determination of temperature, selected + a nominal value which represents approximately the situation of sample temperature. + enumeration: [room temperature, liquid helium temperature, liquid nitrogen temperature, other] + temperature_nominal_other(NX_NUMBER): + exists: optional + unit: NX_TEMPERATURE + doc: | + If temperature_nominal is "other", enter here a nominal/assumed/estimated + sample temperature. temperature_sensor(NXsensor): + exists: recommended doc: | Temperature sensor measuring the sample temperature. This should be a link to /entry/instrument/manipulator/temperature_sensor. @@ -829,7 +876,8 @@ NXopt(NXobject): \@signal: doc: | Spectrum, i.e. y-axis of the data (e.g. counts, intensity) - measurement_data_calibration(NXprocess): + measurement_data_calibration_TYPE(NXprocess): + exists: recommended wavelength_calibration(NXcalibration): exists: optional calibrated_axis(NX_FLOAT): @@ -842,9 +890,9 @@ NXopt(NXobject): # psi and delta values), will be done later after the NXopt workshop. derived_parameters(NXprocess): exists: optional + # >>>This section is transfered from the first NXoptical_spectroscopy version and might + # require a reqwork.<<< doc: | - >>>This section is transfered from the first NXopt version and might - require a reqwork.<<< Parameters that are derived from the measured data. depolarization(NX_NUMBER): exists: optional diff --git a/contributed_definitions/nyaml/NXopt_window.yaml b/contributed_definitions/nyaml/NXopt_window.yaml index 7ca0ae0a76..ef0fa19ce4 100644 --- a/contributed_definitions/nyaml/NXopt_window.yaml +++ b/contributed_definitions/nyaml/NXopt_window.yaml @@ -31,6 +31,10 @@ NXopt_window(NXaperture): doc: | Was a window correction performed? If 'True' describe the window correction procedure in 'window_correction/procedure'. + window_effects_type: + doc: | + Type of effects due to this window on the measurement. + enumeration: [interference effects, light absorption, light scattering, other] window_correction(NXprocess): doc: | Was a window correction performed? If 'True' describe the @@ -66,4 +70,4 @@ NXopt_window(NXaperture): unit: NX_ANGLE doc: | Angle of the window normal (outer) vs. the substrate normal - (similar to the angle of incidence). \ No newline at end of file + (similar to the angle of incidence). diff --git a/contributed_definitions/nyaml/NXraman.yaml b/contributed_definitions/nyaml/NXraman.yaml index f155d34739..a9672b0e7b 100644 --- a/contributed_definitions/nyaml/NXraman.yaml +++ b/contributed_definitions/nyaml/NXraman.yaml @@ -92,7 +92,7 @@ symbols: # A draft version of a NeXus application definition for Raman spectroscopy. type: group -NXraman(NXopt): +NXraman(NXoptical_spectroscopy): (NXentry): definition: doc: | @@ -107,6 +107,7 @@ NXraman(NXopt): to the application definition. enumeration: [NXraman] title: + exists: recommended experiment_type: doc: | Specify the type of the optical experiment. @@ -146,7 +147,7 @@ NXraman(NXopt): Unpolarized light is displayed by "." For non-orthogonal vectors, use the attribute porto_notation_vectors. \@porto_notation_vectors(NX_NUMBER): - # unit: NX_LENGTH + exists: recommended doc: | Scattering configuration as defined by the porto notation given by respective vectors. diff --git a/contributed_definitions/nyaml/NXwaveplate.yaml b/contributed_definitions/nyaml/NXwaveplate.yaml index b23d9de71f..253c7dd7e5 100644 --- a/contributed_definitions/nyaml/NXwaveplate.yaml +++ b/contributed_definitions/nyaml/NXwaveplate.yaml @@ -40,6 +40,10 @@ NXwaveplate(NXobject): dimensions: rank: 1 dim: [[1, N_wavelengths]] + retardance_distribution(NXdata): + exists: optional + doc: | + Wavelength resolved retardence of the waveplate. diameter(NX_FLOAT): unit: NX_LENGTH doc: | From 21d503ed2a6271516581cbf9790c87f1696389d2 Mon Sep 17 00:00:00 2001 From: Ron Hildebrandt Date: Tue, 18 Jun 2024 09:13:14 +0200 Subject: [PATCH 0703/1012] Renaming NXopt to NXoptical_spectroscopy --- .../nyaml/{NXopt.yaml => NXoptical_spectroscopy.yaml} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename contributed_definitions/nyaml/{NXopt.yaml => NXoptical_spectroscopy.yaml} (100%) diff --git a/contributed_definitions/nyaml/NXopt.yaml b/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml similarity index 100% rename from contributed_definitions/nyaml/NXopt.yaml rename to contributed_definitions/nyaml/NXoptical_spectroscopy.yaml From 76cb34cae854cf495b6c4160ec304caa57fe3a19 Mon Sep 17 00:00:00 2001 From: Ron Hildebrandt Date: Tue, 18 Jun 2024 10:19:22 +0200 Subject: [PATCH 0704/1012] fixed make local errors after renaming NXopt --- .../{NXopt.nxdl.xml => NXoptical_spectroscopy.nxdl.xml} | 0 .../classes/contributed_definitions/ellipsometry-structure.rst | 2 +- 2 files changed, 1 insertion(+), 1 deletion(-) rename contributed_definitions/{NXopt.nxdl.xml => NXoptical_spectroscopy.nxdl.xml} (100%) diff --git a/contributed_definitions/NXopt.nxdl.xml b/contributed_definitions/NXoptical_spectroscopy.nxdl.xml similarity index 100% rename from contributed_definitions/NXopt.nxdl.xml rename to contributed_definitions/NXoptical_spectroscopy.nxdl.xml diff --git a/manual/source/classes/contributed_definitions/ellipsometry-structure.rst b/manual/source/classes/contributed_definitions/ellipsometry-structure.rst index 35f0420a23..cfe93e1f1f 100644 --- a/manual/source/classes/contributed_definitions/ellipsometry-structure.rst +++ b/manual/source/classes/contributed_definitions/ellipsometry-structure.rst @@ -24,7 +24,7 @@ In the application definition we provide a minimum set of description elements a Application Definitions ----------------------- - :ref:`NXopt`: + :ref:`NXoptical_spectroscopy`: A generic application definition for optial spectorscopy measurements, including complex systems up to variable angle spectroscopic ellipsometry. :ref:`NXellipsometry`: From c693f76fd9373ff13475ad9b608b65e9b5d78f29 Mon Sep 17 00:00:00 2001 From: Ron Hildebrandt Date: Tue, 18 Jun 2024 12:41:23 +0200 Subject: [PATCH 0705/1012] Adjustments due to errors from ellipsreader --- .../NXoptical_spectroscopy.nxdl.xml | 12 ++++++++++-- .../nyaml/NXoptical_spectroscopy.yaml | 7 +++++++ 2 files changed, 17 insertions(+), 2 deletions(-) diff --git a/contributed_definitions/NXoptical_spectroscopy.nxdl.xml b/contributed_definitions/NXoptical_spectroscopy.nxdl.xml index 7f7d447644..171126e6cd 100644 --- a/contributed_definitions/NXoptical_spectroscopy.nxdl.xml +++ b/contributed_definitions/NXoptical_spectroscopy.nxdl.xml @@ -418,7 +418,7 @@ TODO: Details about the device information. - + The path to a beam emitted by this source. Should be named with the same appendix, e.g., @@ -729,7 +729,12 @@ TODO: - + + + Allows description of beam properties via matrices, which relate ingoing with + outgoing beam properties. + + Sample stage (or manipulator) for positioning of the sample. This should @@ -1037,6 +1042,9 @@ TODO: Similar to the temperautre description of the sample. + + Medium, in which the sample is placed. + diff --git a/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml b/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml index 0875bfad83..d949d0c815 100644 --- a/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml +++ b/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml @@ -311,6 +311,7 @@ NXoptical_spectroscopy(NXobject): doc: | Details about the device information. associated_beam(NX_CHAR): + exists: recommended doc: | The path to a beam emitted by this source. Should be named with the same appendix, e.g., @@ -564,6 +565,10 @@ NXoptical_spectroscopy(NXobject): exists: optional (NXbeam_transfer_matrix_table): + exists: optional + doc: | + Allows description of beam properties via matrices, which relate ingoing with + outgoing beam properties. sample_stage(NXmanipulator): exists: optional doc: | @@ -823,6 +828,8 @@ NXoptical_spectroscopy(NXobject): Similar to the temperautre description of the sample. sample_medium: exists: recommended + doc: | + Medium, in which the sample is placed. enumeration: [air, vacuum, inert atmosphere, oxidising atmosphere, reducing atmosphere, sealed can, water, other] thickness(NX_NUMBER): # Make something like NXlayer_structure_sample? From 96c8f6945c72f844517639daa5e48626d6bbd3aa Mon Sep 17 00:00:00 2001 From: Ron Hildebrandt Date: Tue, 18 Jun 2024 14:36:21 +0200 Subject: [PATCH 0706/1012] additional detector hardware requirement change due to ellipsreader --- contributed_definitions/NXoptical_spectroscopy.nxdl.xml | 2 +- contributed_definitions/nyaml/NXoptical_spectroscopy.yaml | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/contributed_definitions/NXoptical_spectroscopy.nxdl.xml b/contributed_definitions/NXoptical_spectroscopy.nxdl.xml index 171126e6cd..4fedcab033 100644 --- a/contributed_definitions/NXoptical_spectroscopy.nxdl.xml +++ b/contributed_definitions/NXoptical_spectroscopy.nxdl.xml @@ -379,7 +379,7 @@ TODO: - + Specify respective hardware which was used to for the detector. For example special electronics required for time-correlated single photon diff --git a/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml b/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml index d949d0c815..ee534e8289 100644 --- a/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml +++ b/contributed_definitions/nyaml/NXoptical_spectroscopy.yaml @@ -285,6 +285,7 @@ NXoptical_spectroscopy(NXobject): doc: | Raw data before calibration. additional_detector_hardware: + exists: optional doc: | Specify respective hardware which was used to for the detector. For example special electronics required for time-correlated single photon From ba40f33d3c2140b9df783d421b27a5c4d63dcbd9 Mon Sep 17 00:00:00 2001 From: RubelMozumder <32923026+RubelMozumder@users.noreply.github.com> Date: Tue, 18 Jun 2024 17:33:30 +0200 Subject: [PATCH 0707/1012] Update contributed_definitions/nyaml/NXsts.yaml Co-authored-by: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> --- contributed_definitions/nyaml/NXsts.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributed_definitions/nyaml/NXsts.yaml b/contributed_definitions/nyaml/NXsts.yaml index 8a6eb44225..a61b5e5715 100644 --- a/contributed_definitions/nyaml/NXsts.yaml +++ b/contributed_definitions/nyaml/NXsts.yaml @@ -834,7 +834,7 @@ NXsts(NXsensor_scan): sample(NXsample): exists: optional doc: | - To describe sample and other constaints that applied on sample before scanning. + This describes the sample and its properties, as well as constraints that are applied to the sample before scanning. sample_prep_descripton: doc: | At this moment no base class available that can track entire sample preparation. From d303ed64aeb8cd02417108952e4d6c217821c660 Mon Sep 17 00:00:00 2001 From: Rubel Date: Tue, 18 Jun 2024 17:37:41 +0200 Subject: [PATCH 0708/1012] PR request fix. --- contributed_definitions/nyaml/NXsts.yaml | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/contributed_definitions/nyaml/NXsts.yaml b/contributed_definitions/nyaml/NXsts.yaml index a61b5e5715..1add11a652 100644 --- a/contributed_definitions/nyaml/NXsts.yaml +++ b/contributed_definitions/nyaml/NXsts.yaml @@ -409,7 +409,6 @@ NXsts(NXsensor_scan): might be necessary. Usually, this parameter does not require manual adjustment within this module, as the sweep modules automatically set this value according to the sweep timings. (e.g. 500E-3) - # parameters how to change the location from measurement to measurement during the scan scan_control(NXcollection): exists: optional @@ -417,18 +416,18 @@ NXsts(NXsensor_scan): unit: NX_LENGTH exists: optional doc: | - The scan range (in STM experiment) is the area that the tip will scan. (e.g. - 5.000000E-9 5.000000E-9) + In STM experiment The scan range is the coordinate along the X and Y axis from the origin of + the scan area (scan_offset) (e.g. 5.000000E-9 5.000000E-9) scan_offset(NX_NUMBER): unit: NX_LENGTH exists: optional doc: | - The scan offset (in STM experiment) is the position of the tip in the scan area. + In STM experiment, the scan offset is the position of the tip at the starting point of scan area. (e.g. -2.354637E-7 1.267476E-) scan_direction: exists: optional doc: | - The scan direction (in STM experiment) is the direction from which side of the + In STM experiment, the scan direction is the direction from which side of the sample the tip starts scanning. enumeration: [down, up, top, bottom] scan_angle(NX_NUMBER): From 4d8cffb0adc84f9f6c61dff8d64fa0064ae73a17 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 19 Jun 2024 12:09:01 +0200 Subject: [PATCH 0709/1012] draft for NXxps --- contributed_definitions/NXxps.nxdl.xml | 287 ++++++++++++++ contributed_definitions/nyaml/NXxps.yaml | 464 +++++++++++++++++++++++ 2 files changed, 751 insertions(+) create mode 100644 contributed_definitions/NXxps.nxdl.xml create mode 100644 contributed_definitions/nyaml/NXxps.yaml diff --git a/contributed_definitions/NXxps.nxdl.xml b/contributed_definitions/NXxps.nxdl.xml new file mode 100644 index 0000000000..bf1e32663d --- /dev/null +++ b/contributed_definitions/NXxps.nxdl.xml @@ -0,0 +1,287 @@ + + + + + + This is the application definition for X-ray photoelectron spectroscopy. + + + + + + + + + + A name of the experimental method according to `Clause 11`_ of + the `ISO 18115-1:2023`_ specification. + + Examples for XPS-related experiments include: + * X-ray photoelectron spectroscopy (XPS) + * angle-resolved X-ray photoelectron spectroscopy (ARXPS) + * ultraviolet photoelectron spectroscopy (UPS) + * hard X-ray photoemission spectroscopy (HAXPES) + * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) + * electron spectroscopy for chemical analysis (ESCA) + + .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 + + + + + + In traditional surface science, the coordinate system is defined such that the positive z-axis + points along the normal of the sample stage, and the x- and y-axes lie in the plane of the sample stage. + However, in NeXus, a coordinate system that is the same as `McStas`_ is used. `xps_coordinate_system` + gives the user the opportunity to work in the traditional base coordinate system. .. _McStas: http://mcstas.org/ + + + + + + + + + + + + + + + + + + + Link to transformations defining the XPS base coordinate system, + which is defined such that the positive z-axis points along the sample stage normal, and the + x- and y-axes lie in the plane of the sample stage. + + + + + Set of transformations, describing the orientation of the XPS coordinate system + with respect to the beam coordinate system (.). + + + + + + + Description of the XPS spectrometer and its individual parts. + + This concept is related to term `12.58`_ of the ISO 18115-1:2023 standard. + + .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 + + + + + + + Incidence angle + + + + + + + + + + + + + + + + + + + + Azimuthal tilt of the source from the y-direction towards the operator, defined + by the sample stage. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Reference to the transformation describing the orientation of the analyzer + relative to a defined coordinate system. + + + + + + Polar tilt of the analyser with respect to the upward z-direction, defined by + the sample stage. + + + + + + + + + + + + + + + + + + + + Azimuthal tilt of the analyser from the y-direction towards the operator, + defined by the sample stage. + + + + + + + + + + + + + + + + + + + + + + + + + + + + Reference to the transformation describing the orientation of the sample + relative to a defined coordinate system. + + + + + + Clockwise rotation about the sample normal. + + + + + + + + + + + + + + + + + + + + Polar tilt of the sample with respect to the upward z-direction, defined by the + sample stage. + + + + + + + + + + + + + + + + + + + + Azimuthal tilt of the sample from the y-direction towards the operator, defined + by the sample stage. + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/nyaml/NXxps.yaml b/contributed_definitions/nyaml/NXxps.yaml new file mode 100644 index 0000000000..9ce530944b --- /dev/null +++ b/contributed_definitions/nyaml/NXxps.yaml @@ -0,0 +1,464 @@ +category: application +doc: | + This is the application definition for X-ray photoelectron spectroscopy. +type: group +NXxps(NXmpes): + (NXentry): + definition(NX_CHAR): + enumeration: [NXxps] + method: + doc: | + A name of the experimental method according to `Clause 11`_ of + the `ISO 18115-1:2023`_ specification. + + Examples for XPS-related experiments include: + * X-ray photoelectron spectroscopy (XPS) + * angle-resolved X-ray photoelectron spectroscopy (ARXPS) + * ultraviolet photoelectron spectroscopy (UPS) + * hard X-ray photoemission spectroscopy (HAXPES) + * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) + * electron spectroscopy for chemical analysis (ESCA) + + .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 + geometries(NXcoordinate_system_set): + xps_coordinate_system(NXcoordinate_system): + exists: optional + doc: | + In traditional surface science, the coordinate system is defined such that the positive z-axis + points along the normal of the sample stage, and the x- and y-axes lie in the plane of the sample stage. + However, in NeXus, a coordinate system that is the same as `McStas`_ is used. `xps_coordinate_system` + gives the user the opportunity to work in the traditional base coordinate system. .. _McStas: http://mcstas.org/ + origin: + enumeration: [sample stage] + handedness: + enumeration: [right_handed] + z_direction: + enumeration: [sample stage normal] + depends_on(NX_CHAR): + doc: | + Link to transformations defining the XPS base coordinate system, + which is defined such that the positive z-axis points along the sample stage normal, and the + x- and y-axes lie in the plane of the sample stage. + (NXtransformations): + doc: | + Set of transformations, describing the orientation of the XPS coordinate system + with respect to the beam coordinate system (.). + (NXinstrument): + doc: + - | + Description of the XPS spectrometer and its individual parts. + - | + xref: + spec: ISO 18115-1:2023 + term: 12.58 + url: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 + sourceTYPE(NXsource): + power(NX_FLOAT): + unit: NX_POWER + exists: recommended + transformations(NXtransformations): + exists: recommended + source_polar_angle_of_incidence(NX_NUMBER): + unit: NX_ANGLE + doc: | + Incidence angle + \@transformation_type: + enumeration: [rotation] + \@vector: + enumeration: [[1, 0, 0]] + \@depends_on: + enumeration: [source_azimuth_angle] + source_azimuth_angle(NX_NUMBER): + unit: NX_ANGLE + doc: | + Azimuthal tilt of the source from the y-direction towards the operator, defined + by the sample stage. + \@transformation_type: + enumeration: [rotation] + \@vector: + enumeration: [[0, 0, -1]] + \@depends_on: + enumeration: [/entry/sample_stage_cs_transformations/vamas_sample_stage_coordinate_system] + (NXelectronanalyser): + work_function(NX_FLOAT): + transmission_function(NXdata): + exists: recommended + (NXcollectioncolumn): + magnification(NX_FLOAT): + exists: recommended + unit: NX_DIMENSIONLESS + (NXenergydispersion): + diameter(NX_NUMBER): + exists: recommended + unit: NX_LENGTH + energy_scan_mode: + depends_on: + exists: recommended + doc: | + Reference to the transformation describing the orientation of the analyzer + relative to a defined coordinate system. + transformations(NXtransformations): + exists: recommended + analyser_take_off_polar_angle(NX_NUMBER): + unit: NX_ANGLE + doc: | + Polar tilt of the analyser with respect to the upward z-direction, defined by + the sample stage. + \@transformation_type: + enumeration: [rotation] + \@vector: + enumeration: [[1, 0, 0]] + \@depends_on: + enumeration: [analyser_take_off_azimuth_angle] + analyser_take_off_azimuth_angle(NX_NUMBER): + unit: NX_ANGLE + doc: | + Azimuthal tilt of the analyser from the y-direction towards the operator, + defined by the sample stage. + \@transformation_type: + enumeration: [rotation] + \@vector: + enumeration: [[0, 0, -1]] + \@depends_on: + enumeration: [/entry/sample_stage_cs_transformations/vamas_sample_stage_coordinate_system] + (NXprocess_mpes): + energy_referencing(NXcalibration): + exists: recommended + transmission_correction(NXcalibration): + exists: recommended + (NXsample): + depends_on: + exists: recommended + doc: | + Reference to the transformation describing the orientation of the sample + relative to a defined coordinate system. + transformations(NXtransformations): + exists: recommended + sample_rotation_angle(NX_NUMBER): + unit: NX_ANGLE + doc: | + Clockwise rotation about the sample normal. + \@transformation_type: + enumeration: [rotation] + \@vector: + enumeration: [[0, 0, -1]] + \@depends_on: + enumeration: [sample_normal_polar_angle] + sample_normal_polar_angle_of_tilt(NX_NUMBER): + unit: NX_ANGLE + doc: | + Polar tilt of the sample with respect to the upward z-direction, defined by the + sample stage. + \@transformation_type: + enumeration: [rotation] + \@vector: + enumeration: [[1, 0, 0]] + \@depends_on: + enumeration: [sample_normal_tilt_azimuth_angle] + sample_normal_tilt_azimuth_angle(NX_NUMBER): + unit: NX_ANGLE + doc: | + Azimuthal tilt of the sample from the y-direction towards the operator, defined + by the sample stage. + \@transformation_type: + enumeration: [rotation] + \@vector: + enumeration: [[0, 0, -1]] + \@depends_on: + enumeration: [/entry/sample_stage_cs_transformations/vamas_sample_stage_coordinate_system] + data(NXdata): + energy(NX_NUMBER): + \@energy_indices: + \@energy_depends: + exists: recommended + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 1c1892972d1967576919cfdd52a0bc1d58a36fce48b57adf4913839e68fd3d77 +# +# +# +# +# +# This is the application definition for X-ray photoelectron spectroscopy. +# +# +# +# +# +# +# +# +# +# A name of the experimental method according to `Clause 11`_ of +# the `ISO 18115-1:2023`_ specification. +# +# Examples for XPS-related experiments include: +# * X-ray photoelectron spectroscopy (XPS) +# * angle-resolved X-ray photoelectron spectroscopy (ARXPS) +# * ultraviolet photoelectron spectroscopy (UPS) +# * hard X-ray photoemission spectroscopy (HAXPES) +# * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) +# * electron spectroscopy for chemical analysis (ESCA) +# +# .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html +# .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 +# +# +# +# +# +# In traditional surface science, the coordinate system is defined such that the positive z-axis +# points along the normal of the sample stage, and the x- and y-axes lie in the plane of the sample stage. +# However, in NeXus, a coordinate system that is the same as `McStas`_ is used. `xps_coordinate_system` +# gives the user the opportunity to work in the traditional base coordinate system. .. _McStas: http://mcstas.org/ +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Link to transformations defining the XPS base coordinate system, +# which is defined such that the positive z-axis points along the sample stage normal, and the +# x- and y-axes lie in the plane of the sample stage. +# +# +# +# +# Set of transformations, describing the orientation of the XPS coordinate system +# with respect to the beam coordinate system (.). +# +# +# +# +# +# +# Description of the XPS spectrometer and its individual parts. +# +# This concept is related to term `12.58`_ of the ISO 18115-1:2023 standard. +# +# .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 +# +# +# +# +# +# +# Incidence angle +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Azimuthal tilt of the source from the y-direction towards the operator, defined +# by the sample stage. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Reference to the transformation describing the orientation of the analyzer +# relative to a defined coordinate system. +# +# +# +# +# +# Polar tilt of the analyser with respect to the upward z-direction, defined by +# the sample stage. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Azimuthal tilt of the analyser from the y-direction towards the operator, +# defined by the sample stage. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Reference to the transformation describing the orientation of the sample +# relative to a defined coordinate system. +# +# +# +# +# +# Clockwise rotation about the sample normal. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Polar tilt of the sample with respect to the upward z-direction, defined by the +# sample stage. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Azimuthal tilt of the sample from the y-direction towards the operator, defined +# by the sample stage. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# From 84165046d2efd2efdc3a95bad8c583a4f93a9f42 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 19 Jun 2024 12:19:06 +0200 Subject: [PATCH 0710/1012] add image of XPS CS --- contributed_definitions/NXxps.nxdl.xml | 9 +++++++-- contributed_definitions/nyaml/NXxps.yaml | 20 +++++++++++++++----- contributed_definitions/xps/xps_cs.png | Bin 0 -> 114535 bytes 3 files changed, 22 insertions(+), 7 deletions(-) create mode 100644 contributed_definitions/xps/xps_cs.png diff --git a/contributed_definitions/NXxps.nxdl.xml b/contributed_definitions/NXxps.nxdl.xml index bf1e32663d..b6b1ae2dc4 100644 --- a/contributed_definitions/NXxps.nxdl.xml +++ b/contributed_definitions/NXxps.nxdl.xml @@ -54,7 +54,12 @@ In traditional surface science, the coordinate system is defined such that the positive z-axis points along the normal of the sample stage, and the x- and y-axes lie in the plane of the sample stage. However, in NeXus, a coordinate system that is the same as `McStas`_ is used. `xps_coordinate_system` - gives the user the opportunity to work in the traditional base coordinate system. .. _McStas: http://mcstas.org/ + gives the user the opportunity to work in the traditional base coordinate system. + + .. _McStas: http://mcstas.org/ + + .. image:: xps/xps_cs.png + :width: 40% @@ -63,7 +68,7 @@ - + diff --git a/contributed_definitions/nyaml/NXxps.yaml b/contributed_definitions/nyaml/NXxps.yaml index 9ce530944b..7be2ff1a0f 100644 --- a/contributed_definitions/nyaml/NXxps.yaml +++ b/contributed_definitions/nyaml/NXxps.yaml @@ -28,11 +28,16 @@ NXxps(NXmpes): In traditional surface science, the coordinate system is defined such that the positive z-axis points along the normal of the sample stage, and the x- and y-axes lie in the plane of the sample stage. However, in NeXus, a coordinate system that is the same as `McStas`_ is used. `xps_coordinate_system` - gives the user the opportunity to work in the traditional base coordinate system. .. _McStas: http://mcstas.org/ + gives the user the opportunity to work in the traditional base coordinate system. + + .. _McStas: http://mcstas.org/ + + .. image:: xps/xps_cs.png + :width: 40% origin: enumeration: [sample stage] handedness: - enumeration: [right_handed] + enumeration: [left_handed] z_direction: enumeration: [sample stage normal] depends_on(NX_CHAR): @@ -174,7 +179,7 @@ NXxps(NXmpes): exists: recommended # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 1c1892972d1967576919cfdd52a0bc1d58a36fce48b57adf4913839e68fd3d77 +# 69aadc9c28afafd97a512c66335d639a3cf3895838fd6d6d8c2e5aa29b26f494 # # # tIdpPk0 ztFL99+A>TQ*$IbQcPsw*Q%@wvC(lgPOdY3Yq1X6+`S|yU&P3b#pL&0|5`RY9m33T2@gtvNp zNXNOJF%Y4`bOc@=0a`Olk&kIr=^HD)YM^EPv(EL#PhoY0QI9_q`+ompMF~!40)_{l zze$SYx5BU0+B1s*)`}oe?u}A8@mo1Q8mBC?r(o(KXTiv*aMmDxejSiZ;MK;qmDU_0)%*v9-Tf8H06*aq+5HXj5}Momvh;Oh7L$Ln)|iI~tD?PP z%CQP1w1kk7`^vdRPy7KfuAvDVE|W<3 z&LO}+tHkHBz1AivGg~&(E$dnpor*8Zd64Bi+E3tTbn;~_B0NCYZ0b1D9v`hoZ&e1X zG>-?=%^hdU-ffP}&7lQH$PFL2D%ZRiKDP4NVL9KHh-IHq!M5E;pO3v8BA3LxwP}G) zUz>ts<7*G-v)8z0cSM=Nqlv?>SNaHpgsXIXcbepQlFq=f>fXEBre)wag5woxS-=L6 zj$CVHSsC1BDWR!hqFo)gWthA9Yg0_o!YfJZcneBFJp&^@9B;!D+kS33#O4Q@`py3i zhefa>nqWilq)TRMSJTLlx!V5@_RtT3!SE1;B82>dCsutGk1>L7c~uNp=rnWgEMHp$ zl^4|4>#Qcb`M%u8{J!4mN~J~4m|PT{B(t2YI6a4i{EP@qy{@D@=A=CKPDNEqT)l}1_BR9PPhAzmJoJ!QC-7u7+JDU4CINIII6tQ)o6rS3p60 zfP+@b^%Q}2i8AIL^vzh~Djz&AR9D4~dD#U{F@ncSc`*7sa{2ra7WT~PT_-T29Qg0Y z8rd84Q(HTpI16>ipdi!nhut()*oId0R57GSrvKM3o$Z*fvm_$_EX!-ZsN*dX!2>g7 z()@!f>5ufIf8wWd83>EXI>t`fTJ{3R$s(23CeY?A%hm74nah~UT1{QQ=IKzBGtGKT z6duEY;$N)*41$atK+XF=N*ZE1@~CxN{}9F=G?I;b%gEqBX&o3C`{8t-d{;))WKs%RVdG-V3#V9n;glzX$vszMX;ugq;iOK(e1l zB?$aSu;MfQjJa_+9-PQj=|wI|Zi(+phSmP6#5lj}T)q)@3#z%I)yCXe!3R>px78tp zYly5>+g}M{yGn6~^Cd_=B03ld-b*~WxRQUxOwDPq#taWMg39u+YkY`jihS}cdl8AL z@AaLum*5J1?d)*ReD^E%&5Mmj_r=JwjsZ2@cD@wBc6>Z+=FMV#)A0A{0vB78EH| zVaX+?fSs1Xgmm8TTq5XN&BbwTf~Ew(htDVOLAdRIO5qUTC7)K21AN7kTd+e0BetD}3AHtuyU5W=FTlzN`BuX{@;U?nx+Zm&)t!13Dt;#vihe%zIMOjB-4i8fE#E^eilaTB+E&8HddhKx>r|nTvm_Y(zDioLHWoyO9fl ze@}i+jqwPf3>$BEOriv?AT9fu#+gKx@T5)>Ih!Oadf5iP7p`hfm7lTM7-J zUCk+0hF<))Or@cs);lv~>+X*TKe`INah-!}ZY_xwp)mnltWECA<{4qvwm61kJ4eVEyC-*I3axjWO@y9|{YEcv>9LHx)Yj z-G2Qe+80l@kc4%OIQ=Vi0UU5b*VkFM@xkgog08;->C+pl5ns@D^OK$7^PWw{Ak;&% zxAI>j&`J@0PGwJtPIJ?7a-WxJa(lEW=_<}#u= z)evEcR-dx9z*=Dh-NT%zkcIHQZvpuK16V!6g{uYavU*Fl)AURT{GLI$A}*a6Le$Qe zG=qQ7gZk|&o&~BXYD?#IAv?Ge zzzDy&J49In5qFo(B&FQn{ZLu?xVs5>K-F^DuDS*(yQy$6tjV~M+>o0jFq>|o9IIqRJF^82adG77B!ur$AJlcu#5~3*LXB@_xSSn{ zwR5DBI9jxl?Lp@ilFa33#fLOWpp-S#w%TlI3jD?}kE?H+Kq8z9%6;NNHOKbB>~}